[meta-xilinx] u-boot/UBIFS

[Joe Hershberger]

Hi Ed,

On Mon, Sep 21, 2015 at 5:30 PM, Edward Wingate <edwingate8 at gmail.com> wrote:
> On Mon, Sep 21, 2015 at 2:41 PM, Joe Hershberger
> <joe.hershberger at gmail.com> wrote:
>> Depending on the flash technology, it can be a bad idea to use raw
>> flash. Based on the names of your MTD partitions I'll guess that you
>> have qspi NOR, maybe?
>
> Yes, I have qspi NOR flash.  Is it a bad idea to use raw flash with
> this technology?

You do miss out on wear leveling, but it is not likely to be an issue.
You should be free to use raw or UBI.

>> Is your QSPI flash viewed as flash or SPI flash?
>
> I haven't a clue.  How do I find out?
> Linux does report "5 ofpart partitions found on MTD device spi32764.0"
> Does that "spi" in spi32764.0 indicate SPI flash?

It depends on how the Zynq is configured to expose the QSPI. It can
operate in I/O mode or legacy SPI mode and still write. If it were in
linear mode (CONFIG_ENV_IS_IN_FLASH), the flash would be read-only, so
you couldn't save your environment. I'm not sure about the U-Boot
driver for it. Chances are you need to use CONFIG_ENV_IS_IN_SPI_FLASH.

>>> My ultimate goal is to boot Linux on a custom Zynq 7020 board with
>>> these flash partitions:
>>> mtd0: "qspi-fsbl-bitstream-uboot" (8M)
>>> mtd1: "qspi-uboot-env" (256K)
>>> mtd2: "qspi-device-tree" (256K)
>>> mtd3: "qspi-linux" (4M)
>>> mtd4: "qspi-rootfs" (96M)
>>
>> Is there a reason you want to use all these raw partitions instead of
>> just dropping the files on the file system and reading them from
>> there?
>
> Reasons are ignorance and inexperience, and having read many documents
> on the old non-UBIFS way to do things, probably.

Sure - I guess it's not too well adopted, but quite a bit better IMO.
I think it may be hard because most people tell the process to make a
dev board function (and it's fine for that), but there are many other
things to consider if the configuration is running in a product
instead of a developer's playground.

> I had planned on doing the following:
> - FSBL loads bitstream, then runs uboot (FSBL/bitstream/uboot.elf all in mtd0).
> - uboot gets its environment from mtd1 (or now, maybe I'll just
> compile in what I need and do away with mtd1).
> - uboot loads the kernel and DTB from mtd2/3.
> - uboot boots Linux and point it at the UBIFS RFS at mtd4.
>
> I figure this way, I can handle firmware updates like so:
> 1) The most frequent updates will be to the application and I can do
> so in the UBIFS file system (e.g., via a package manager).

Sounds good.

> 2) The kernel and device tree will be less frequently updated, but
> when I need to, I can use flashcp to do so.

For me, it's simpler to just copy a file. I would do that - meaning
load all things from UBIFS (ITB).

> 3) FSBL and uboot will hopefully need even less frequent updates, but
> I can also use flashcp to do so if needed.

Certainly. In our products we don't support updating FSBL or U-Boot
outside of development. Though I must say we do have ideas to replace
FSBL with U-Boot SPL (still not upgradable) and then probably even
provide an upgradable U-Boot as part of our ITB as a CYA - so 3
U-Boots. Not committed yet, though.

> 4) I am now considering placing the bitstream in the RFS and letting
> Linux load the FPGA on boot up instead of having the FSBL load it.
> Then any updates to the bitstream can just be a file operation as
> well.

We never load the bitstream from the boot.bin. It's just too
inflexible. We just move out one step, though - not waiting for Linux
to load it. We have U-Boot (and its "fpga" command) configure the PL.
Not much later in the boot process than the FSBL, but far more
flexibility, since it can be loaded directly from UBIFS, so it can be
updated easily while booted and boot script logic can decide which to
load.

> Is everything I mentioned feasible? I'd be interested to know what
> would you do differently?

It certainly sounds feasible. It just doesn't sound very convenient to
update IMO.

> But one reason I had wanted go the route of keeping the uboot-env in
> flash is to have a duplicate set of the partitions for kernel and DTB.

I think that's an important thing to do, but it shouldn't require an
env (though the env is useful for many other things).

> I was kicking around the idea of updating one set of partitions during
> firmware updates and the uboot-env in mtd1 will determine which set of
> partitions to boot from. If an update goes bad, then I can use uboot
> to update uboot-env in mtd1 and go back to the old working kernel.

In one of our products, we use UBIFS to hold the ITB (kernel + dtb +
boot script + bitfile); we have 2 copies of the ITB... and when
updating firmware, we replace the one that is not active, test the
hashes, then just write a marker file next to them to indicate which
is active. It's safe for updates and simple to choose which to load
from U-Boot and the backup is still there if U-Boot detects a problem
(through any number of approaches to balance boot time with
reliability) or just during the update.

> I'm still on the fence about this though.  Does this sound like
> overkill?  I think (hope) UBIFS and flashcp should be reliable enough
> to do updates in place.

I would say that's generally not overkill no matter what the
underlying technology is unless you are hard-wired to a power plant.

>> I do recommend a separate file system for files needed by U-Boot vs
>> not - it drastically cuts down on the mount time in U-Boot if your
>> flash is large.
>
> Am I following this paradigm above, even though I'm using raw
> partitions rather than a file system for kernel/DTB?

Yes, to the extreme. Completely independent and no mounting even
involved in your process.

I simply meant that if you use UBIFS to store your boot files (any
that U-Boot will access) and you just drop them on your rootfs, you
may see mount performance issues in U-Boot. A separate MTD partition
for the UBI will resolve that. Remember that if the partition is too
small, the UBI will not have enough blocks to work with and the
wear-leveling and disturb avoidance mechanisms won't work effectively.

>> So you don't want a ramdisk. You want to install the generated rootfs
>> as a R/W UBIFS, right?
>
> This is correct.
>
>> In that case you just make bootargs include "root=ubi1:rootfs
>> rootfstype=ubifs" or whatever.
>>
>>> My confusion lies in how to create the image for mtd1 and then how to
>>> tell u-boot that its environment can be found there.
>>
>> As I said in the last message, it's not typically generated... you
>> save the default and that is the starting point.
>
> Is "the default" whatever is in the u-boot source code
> (CONFIG_EXTRA_ENV_SETTINGS)?

Yes, the default is what is compiled into the U-Boot binary and what
is used if a valid (passes CRC and magic number) cannot be loaded or
if you run the "env default" U-Boot command.

> When you save the default, where does it save it to?

It saves it to whatever is configured as the env when U-Boot was
compiled... i.e. the same place that it loaded from (or failed to, on
the first try). Naturally if you enable a redundant env, then it will
the the inactive env store that gets saved to.  If you are making a
critical system that needs redundant firmware updates, then you
probably need redundant environments as well. Of course if it's built
in, no need for redundancy. :D

> Thanks, Joe, for your kind assistance.

No problem.

-Joe