[meta-xilinx] u-boot/UBIFS

[Joe Hershberger]

Hi Ed,

On Tue, Sep 22, 2015 at 12:58 AM, Edward Wingate <edwingate8 at gmail.com> wrote:
> On Mon, Sep 21, 2015 at 6:56 PM, Joe Hershberger
> <joe.hershberger at gmail.com> wrote:
>>> 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).
>>
>> 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.
>
> Ah, I didn't think of doing it this way, storing 2 copies in one UBIFS
> partition, rather than having separate partitions for each. This does
> sound much easier to update and simpler to work with than in my plan.
> Thanks for this idea!  Do you also use a ping-pong mechanism when you
> update your application?

Generally no because the application is not responsible for updating
itself. If the update fails, you just try again. The update service is
not impaired by a failed app update.

> Is the boot script you talk about above the script/commands in the
> u-boot environment that gets the kernel/DTB and boots Linux?  Is that
> something you'd be able and willing to share?  I'd like to see how you
> read the marker files and decide which to load.  I guess it might be
> as simple as the marker files containing the name of the active
> kernel/bitstream/dtb and ping-ponging between two filenames?

It is just a script of U-Boot commands. In fact the "source" command
in U-Boot supports reading the script to run directly from the ITB.
E.g.:  "source $loadaddr:bootscript" after loading the ITB.

We just check the existence of the marker file to select one or the
other. Create the marker file to select the second image, delete it to
select the first image. Given it's that simple, I'll pass on
distilling that from our other stuff.

> And in your first email, you mentioned that "Our system packages
> everything into a U-Boot ITB
> (image tree blob) so we just have to load one file from the ubifs."
> So you don't have separate files for kernel, DTB and bitstream; they
> are combined into one blob that u-boot understands? This is the first
> time I've heard of this capability.  Where can I find out more about
> how this works?  What are the relevant u-boot commands?

It's fairly well integrated into U-Boot since it is the preferred
format for U-Boot images for the last number of years (5 or 6?). So
obviously bootm supports it, but so does the "fpga" command and the
"source" command for instance. Command for manipulating and navigating
are also already familiar since the ITB is the same binary format as a
DTB. That means U-Boot's "fdt" command can be used to explore and
manipulate the contents. "iminfo" knows how to print out the relevant
details about the image.

The "bootm" command also supports configs, which are just groupings of
kernel, device tree, optional ramdisk, etc. A number of our products
ship the same binary for the kernel and all of the device trees for
all of that family. U-Boot then looks for a config that is compatible
with device's identity and just loads the config. E.g.: "bootm
${loadaddr}#config_${DeviceCode}"

You can read all about it in the U-Boot source at doc/uImage.FIT/*

> So if I were to do things using your methods, I'd have these
> partitions (with approx. sizes; I have 128MB total flash):
> mtd0: qspi-fsbl-uboot (8M)
> mtd1: qspi-itb (20M)
> mtd2: qspi-rootfs (100M)
>
> - mtd0 would be raw flash partition containing FSBL and u-boot.elf.
> - mtd1 would be UBIFS partition containing the u-boot environment and

One note here, you will need one MTD partition with UBI 3 volumes. 2
UBI volumes for the env and the redundant env, and a 3rd for the UBIFS
that holds the ITBs.

> 2 copies of the kernel, DTB and bitstream (does u-boot use the .bit
> file directly or does it need to be converted due to endian-ness?).

We package the .bit.bin file that is optionally exported by Xilinx's
bootgen tool. The U-Boot "fpga" command will accept this file directly
or inside of an ITB.

> - mtd2 would be UBIFS partition containing the RFS.
>
> On boot, FSBL would just load u-boot.
> u-boot would mount mtd1 and
> 1) access the u-boot environment
> 2) load the appropriate FPGA bitstream based on marker file
> 3) load the appropriate kernel and DTB based on marker files, and
> boot, pointing the kernel to the RFS in mtd2

If these updates would come together (they do on some of our products,
not on others) then a single ITB can hold the entire update. You
simply generate it with the mkimage tool in the U-Boot tools dir. It
expects to find the dtc (device tree compiler) in the path since it
uses that to create the ITB (same format for real!).

> Did I get the gist of it?

Yes - minor adjustments above.

> Thanks for these great ideas, Joe.  I can see how life would be much
> easier doing it this way.

My pleasure. Great to see people using the newer, more powerful approaches.

Cheers,
-Joe