On Thu, Feb 19, 2015 at 5:50 PM, Tom Rini trini@ti.com wrote:
On Thu, Feb 19, 2015 at 05:19:54PM +0100, Linus Walleij wrote:
This modifies the vexpress64 Juno configuration so that it will by default load and boot a kernel and a device tree from the pre-defined location in the NOR flash. When we are at it, also define the proper command line for the Juno and indicate that the USB stick (/dev/sda1) is the default root file system.
Signed-off-by: Linus Walleij linus.walleij@linaro.org
Is there a reason to not enable mtdparts and define + pass in the partition map on NOR?
I've looked closer at this, and the ARM reference designs actually have a special "partition" format and does not rely on fixed offsets that e.g the bootloader hardcodes and pass to the kernel.
The format is implemented in the Linux kernel in drivers/mtd/afs.c
I also made a stand-alone implementation at one point to create these flash images: http://www.df.lth.se/~triad/krad/integrator/arm-header.c
It involves scanning over the eraseblocks of the flash, reading out the last 20 bytes of each, scanning for a magic number indicating a footer. So this footer is added to the last erase block for the "partition", not preceding of the flash image, instead following it. Meaning XIP &c will still work fine.
By scanning all erase blocks, all images in the flash can be identified.
The proper implementation for U-Boot interaction with the flash would be to copy over/implement this as AFS partitions instead of MTD partitions, and select that exclusively for the ARM Reference designs.
This image format has been used by ARM reference since the first ARM Integrator in ~2001 and is still used in the latest Juno design from last year, so it's likely not going away.
Shall I just go ahead and implement this for U-boot?
It can be incremental on top of this patch.
I don't know if it even needs the MTD layer. Possibly this "partition" type lives better on top of the raw flash info, as a separate cmd file to read/write/load such images.
Yours, Linus Walleij