[meta-xilinx] u-boot/UBIFS

[Edward Wingate]

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?

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

>> 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.
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).
2) The kernel and device tree will be less frequently updated, but
when I need to, I can use flashcp to do so.
3) FSBL and uboot will hopefully need even less frequent updates, but
I can also use flashcp to do so if needed.
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.

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

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

> 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)? When you save the default, where does it
save it to?

Thanks, Joe, for your kind assistance.