[meta-xilinx] u-boot/UBIFS

[Edward Wingate]

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?

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?

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?

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
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?).
- 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

Did I get the gist of it?

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