[meta-xilinx] u-boot/UBIFS

[Joe Hershberger]

Hi Ed,

On Mon, Sep 21, 2015 at 3:17 PM, Edward Wingate <edwingate8 at gmail.com> wrote:
> On Mon, Sep 21, 2015 at 12:39 PM, Joe Hershberger
> <joe.hershberger at gmail.com> wrote:
>> Generally the env will either already there or created at runtime from
>> the default environment.
>>
>>> And how do I tell u-boot that this flash partition contains the
>>> environment for it (e.g., set another config item and re-compile
>>> u-boot)?
>>
>> You say "flash partition" here, but it seems like you are trying to
>> use UBI to store the env, so I'm assuming that.
>
> No, that's not what I'm trying to do, I don't think.
> As I understand it, the u-boot environment can come from these places:
> 1) It is hard-coded and compiled, so the environment is contained in
> the u-boot.elf binary.
> 2) Specified in text file uEnv.txt when booting from SD card
> 3) A raw flash partition
>
> I was trying to do #3, flash the u-boot environment to a flash
> partition, but am not understanding how to create the flash image and,
> once flashed, how to tell u-boot about it.

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?

Is your QSPI flash viewed as flash or SPI flash?

If flash, then you need CONFIG_ENV_IS_IN_FLASH

To tell U-Boot about it, you #define CONFIG_ENV_ADDR with the flash address.

If you end up needing CONFIG_ENV_IS_IN_SPI_FLASH, then you will
#define CONFIG_ENV_OFFSET instead of CONFIG_ENV_ADDR.

You also need CONFIG_ENV_SECT_SIZE.

> Now, it seems you're giving me a 4th option: saving the u-boot
> environment to a UBI partition.

You do indeed. Well UBI volume, actually. I added support for doing
that several years back. It's highly desirable (actually required IMO)
on systems with raw NAND 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?

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.

> The FSBL, bitstream and uboot would be in mtd0.  This would the
> BOOT.BIN that Xilinx SDK generates.
> The uboot environment would be in mtd1 (the erase block size for my
> flash device is 256K, so that's why the unnecessarily large size).
> mtd2-4 are the Linux DTB, kernel and RFS that Yocto generates.
> The only UBIFS partition would be mtd4 containing the ubifs RFS from Yocto.

So you don't want a ramdisk. You want to install the generated rootfs
as a R/W UBIFS, right?

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.

If you want to generate it you can just create a text file with
name=value pairs and import it with the "env import" command in
U-Boot.

If you really want to make an "image" that you can install with a JTAG
or flash programmer or something, then the format is just '\0'
delimited name=value pairs with a terminating "\0\0". You also need a
CRC. There is a tool in tools/envcrc.c that can do that for you.