[U-Boot] [PATCH 2/2] vexpress64: juno: add default NOR flash boot
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 --- include/configs/vexpress_aemv8a.h | 33 ++++++++++++++++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index bcfcb63d81d8..7a6ac9bb9b3a 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -190,7 +190,38 @@ #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1
/* Initial environment variables */ -#ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP +#ifdef CONFIG_TARGET_VEXPRESS64_JUNO +/* + * Defines where the kernel and FDT exist in NOR flash and where it will + * be copied into DRAM + */ +#define CONFIG_EXTRA_ENV_SETTINGS \ + "kernel_name=Image\0" \ + "kernel_addr=0x8500000\0" \ + "kernel_addr_r=0x80000000\0" \ + "max_kernel=0xa00000\0" \ + "fdt_name=juno.dtb\0" \ + "fdt_addr=0x8f00000\0" \ + "fdt_addr_r=0x83000000\0" \ + "max_fdt=0x100000\0" \ + "fdt_high=0xffffffffffffffff\0" \ + "initrd_high=0xffffffffffffffff\0" \ + +/* Assume we boot with root on the first partition of a USB stick */ +#define CONFIG_BOOTARGS "console=ttyAMA0,115200n8 " \ + "root=/dev/sda1 rw " \ + "earlyprintk=pl011,0x7ff80000 debug user_debug=31 "\ + "loglevel=9" + +/* Copy the kernel and FDT to DRAM memory and boot */ +#define CONFIG_BOOTCOMMAND "cp ${kernel_addr} ${kernel_addr_r} ${max_kernel} ; " \ + "cp ${fdt_addr} ${fdt_addr_r} ${max_fdt}; " \ + "fdt addr $fdt_addr_r; fdt resize; " \ + "booti $kernel_addr_r - $fdt_addr_r" + +#define CONFIG_BOOTDELAY 1 + +#elif CONFIG_TARGET_VEXPRESS64_BASE_FVP #define CONFIG_EXTRA_ENV_SETTINGS \ "kernel_name=uImage\0" \ "kernel_addr_r=0x80000000\0" \
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?
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?
None other than that the existing Vexpress board configs didn't do it.
I realize it's a good point because I think the ARM partition table contains the size of the binaries so we can copy just the stuff we need before booting, I'll take a look at this.
Thanks! Linus Walleij
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
On Mon, Feb 23, 2015 at 04:12:47PM +0100, Linus Walleij wrote:
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.
Sounds like a plan to me, thanks!
participants (2)
-
Linus Walleij -
Tom Rini