[U-Boot] [PATCH v5 1/3] Add README for the "Falcon" mode
Simple howto to add support to a board for booting the kernel from SPL ("Falcon" mode).
Signed-off-by: Stefano Babic sbabic@denx.de --- Changes in v5: - several fixes for the language, rephrasing some unclear parts (Vikram Narayanan)
Changes in v4: - fix capitalization, styling, in spl help (Andreas Biessmann) - move CONFIG_SPL_OS_BOOT before function in doc (Andreas Biessmann)
Changes in v3: - parameter initrd_addr was removed in V2 (Andreas Biessmann) - added patch to fix help usage for spl export (Andreas Biessmann) - Added empty lines (Otavio Salvador) - add a more exhaustive description explaining that spl export does not save into media (Lukasz Majewski).
Changes in v2: - spelling, language fixes (Andreas Biessman) - rewrite some unclear sentences - drop CONFIG_SPL_OS_BOOT_KEY - make example with twister more exhaustive
doc/README.falcon | 169 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 169 insertions(+) create mode 100644 doc/README.falcon
diff --git a/doc/README.falcon b/doc/README.falcon new file mode 100644 index 0000000..72fe04a --- /dev/null +++ b/doc/README.falcon @@ -0,0 +1,169 @@ +U-Boot Falcon Mode +==================== + +Introduction +------------ + +This document provides an overview of how to add support for Falcon Mode +to a board. +Falcon Mode is introduced to speed up the booting process, allowing +to boot a Linux kernel (or whatever image) without a full blown U-Boot. + +Falcon Mode relies on the SPL framework. In fact, to make booting faster, +U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot +image. In most implementations, SPL is used to start U-Boot when booting from +a mass storage, such as NAND or SD-Card. SPL has now support for other media, +and can generally be seen as a way to start an image performing the minimum +required initialization. SPL mainly initializes the RAM controller, and then +copies U-Boot image into the memory. The Falcon Mode extends this way +allowing to start the Linux kernel directly from SPL. A new command is added +to U-Boot to prepare the parameters that SPL must pass to the kernel, using +ATAGS or Device Tree. + +In usual U-Boot systems, these parameters are generated each time before +loading the kernel, passing to Linux the address in memory where +the parameters can be read. +With Falcon Mode, this snapshot can be saved into persistent storage and SPL is +informed to load it before running the kernel. + +To boot the kernel, these steps under a Falcon-aware U-Boot are required: + +1. Boot the board into U-Boot. +Use the "spl export" command to generate the kernel parameters area or the DT. +U-Boot runs as when it boots the kernel, but stops before passing the control +to the kernel. + +2. Save the prepared snapshot into persistent media. +The address where to save it must be configured into board configuration +file (CONFIG_CMD_SPL_NAND_OFS for NAND). + +3. Boot the board into Falcon Mode. SPL will load the kernel and copy +the parameters which are saved in the persistent area area to the required address. + +It is required to implement a custom mechanism to select if SPL loads U-Boot +or another image. + +The value of a GPIO is a simple way to operate the selection, as well as +reading a character from the SPL console if CONFIG_SPL_CONSOLE is set. + +Falcon Mode is generally activated by setting CONFIG_SPL_OS_BOOT. This tells +SPL that U-Boot is not the only available image that SPL is able to start. + +Configuration +---------------------------- +CONFIG_CMD_SPL Enable the "spl export" command. + The command "spl export" is then available in U-Boot + mode +CONFIG_SYS_SPL_ARGS_ADDR Address in RAM where the parameters must be + copied by SPL. + In most cases, it is <start_of_ram> + 0x100 + +CONFIG_SYS_NAND_SPL_KERNEL_OFFS Offset in NAND where the kernel is stored + +CONFIG_CMD_SPL_NAND_OFS Offset in NAND where the parameters area was saved. + +CONFIG_CMD_SPL_WRITE_SIZE Size of the parameters area to be copied + +CONFIG_SPL_OS_BOOT Activate Falcon Mode. + +Function that a board must implement +------------------------------------ + +void spl_board_prepare_for_linux(void) : optional + Called from SPL before starting the kernel + +spl_start_uboot() : required + Returns "0" if SPL starts the kernel, "1" if U-Boot + must be started. + + +Using spl command +----------------- + +spl - SPL configuration + +Usage: + +spl export <img=atags|fdt> [kernel_addr] [initrd_addr] [fdt_addr ] + +img : "atags" or "fdt" +kernel_addr : kernel is loaded as part of the boot process, but it is not started. + This is the address where a kernel image is stored. +initrd_addr : Address of initial ramdisk + can be set to "-" if fdt_addr without initrd img is used +fdt_addr : in case of fdt, the address of the device tree. + +The spl puts its result at a self gained position. The position is defined at compile +time or when generating the uImage but not at command line for 'spl export' +(see spl_export(): gd->bd->bi_boot_params vs. images.ft_addr). + +spl export' does not write directly to a storage media. This command is intended to save +the prepared information in RAM. +The user is responsible to save the data into the required media, as described +on the following example, at the offset set at compile time +(CONFIG_CMD_SPL_NAND_OFS in case of NAND). + +Usage on the twister board: +-------------------------------- + +Using mtd names with the following (default) configuration +for mtdparts: + +device nand0 <omap2-nand.0>, # parts = 9 + #: name size offset mask_flags + 0: MLO 0x00080000 0x00000000 0 + 1: u-boot 0x00100000 0x00080000 0 + 2: env1 0x00040000 0x00180000 0 + 3: env2 0x00040000 0x001c0000 0 + 4: kernel 0x00600000 0x00200000 0 + 5: bootparms 0x00040000 0x00800000 0 + 6: splashimg 0x00200000 0x00840000 0 + 7: mini 0x02800000 0x00a40000 0 + 8: rootfs 0x1cdc0000 0x03240000 0 + + +twister => nand read 82000000 kernel + +NAND read: device 0 offset 0x200000, size 0x600000 + 6291456 bytes read: OK + +Now the kernel is in RAM at address 0x82000000 + +twister => spl export atags 0x82000000 +## Booting kernel from Legacy Image at 82000000 ... + Image Name: Linux-3.5.0-rc4-14089-gda0b7f4 + Image Type: ARM Linux Kernel Image (uncompressed) + Data Size: 3654808 Bytes = 3.5 MiB + Load Address: 80008000 + Entry Point: 80008000 + Verifying Checksum ... OK + Loading Kernel Image ... OK +OK +cmdline subcommand not supported +bdt subcommand not supported +Argument image is now in RAM at: 0x80000100 + +The result can be checked at address 0x80000100: + +twister => md 0x80000100 +80000100: 00000005 54410001 00000000 00000000 ......AT........ +80000110: 00000000 00000067 54410009 746f6f72 ....g.....ATroot +80000120: 65642f3d 666e2f76 77722073 73666e20 =/dev/nfs rw nfs + +The parameters generated with this step can be saved into NAND at the offset +0x800000 (value for twister for CONFIG_CMD_SPL_NAND_OFS) + +nand erase.part bootparms +nand write 0x80000100 bootparms 0x4000 + +Now the parameters are stored into the NAND flash at the address +CONFIG_CMD_SPL_NAND_OFS (=0x800000). + +Next time, the board can be started into Falcon Mode moving the +setting the gpio (on twister gpio 55 is used) to kernel mode. + +The kernel is loaded directly by the SPL without passing through U-Boot. + +Falcon Mode was presented at the RMLL 2012. Slides are available at: + +http://schedule2012.rmll.info/IMG/pdf/LSM2012_UbootFalconMode_Babic.pdf
CONFIG_SPL_OS_BOOT_KEY is used only in board files. It is not required to have a general CONFIG_ option. Rename it and define it in board directory.
Signed-off-by: Stefano Babic sbabic@denx.de --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None
board/technexion/twister/twister.c | 8 ++++---- board/technexion/twister/twister.h | 2 ++ board/timll/devkit8000/devkit8000.c | 8 ++++---- board/timll/devkit8000/devkit8000.h | 3 +++ include/configs/devkit8000.h | 1 - include/configs/twister.h | 1 - 6 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/board/technexion/twister/twister.c b/board/technexion/twister/twister.c index c9eea9b..fa0ace0 100644 --- a/board/technexion/twister/twister.c +++ b/board/technexion/twister/twister.c @@ -165,10 +165,10 @@ void spl_board_prepare_for_linux(void) int spl_start_uboot(void) { int val = 0; - if (!gpio_request(CONFIG_SPL_OS_BOOT_KEY, "U-Boot key")) { - gpio_direction_input(CONFIG_SPL_OS_BOOT_KEY); - val = gpio_get_value(CONFIG_SPL_OS_BOOT_KEY); - gpio_free(CONFIG_SPL_OS_BOOT_KEY); + if (!gpio_request(SPL_OS_BOOT_KEY, "U-Boot key")) { + gpio_direction_input(SPL_OS_BOOT_KEY); + val = gpio_get_value(SPL_OS_BOOT_KEY); + gpio_free(SPL_OS_BOOT_KEY); } return val; } diff --git a/board/technexion/twister/twister.h b/board/technexion/twister/twister.h index a2051c0..cff479c 100644 --- a/board/technexion/twister/twister.h +++ b/board/technexion/twister/twister.h @@ -38,6 +38,8 @@ const omap3_sysinfo sysinfo = { #define XR16L2751_UART1_BASE 0x21000000 #define XR16L2751_UART2_BASE 0x23000000
+/* GPIO used to select between U-Boot and kernel */ +#define SPL_OS_BOOT_KEY 55
/* * IEN - Input Enable diff --git a/board/timll/devkit8000/devkit8000.c b/board/timll/devkit8000/devkit8000.c index 85685ee..b88d978 100644 --- a/board/timll/devkit8000/devkit8000.c +++ b/board/timll/devkit8000/devkit8000.c @@ -172,10 +172,10 @@ void spl_board_prepare_for_linux(void) int spl_start_uboot(void) { int val = 0; - if (!gpio_request(CONFIG_SPL_OS_BOOT_KEY, "U-Boot key")) { - gpio_direction_input(CONFIG_SPL_OS_BOOT_KEY); - val = gpio_get_value(CONFIG_SPL_OS_BOOT_KEY); - gpio_free(CONFIG_SPL_OS_BOOT_KEY); + if (!gpio_request(SPL_OS_BOOT_KEY, "U-Boot key")) { + gpio_direction_input(SPL_OS_BOOT_KEY); + val = gpio_get_value(SPL_OS_BOOT_KEY); + gpio_free(SPL_OS_BOOT_KEY); } return !val; } diff --git a/board/timll/devkit8000/devkit8000.h b/board/timll/devkit8000/devkit8000.h index aa69e6c..c1965e2 100644 --- a/board/timll/devkit8000/devkit8000.h +++ b/board/timll/devkit8000/devkit8000.h @@ -32,6 +32,9 @@ const omap3_sysinfo sysinfo = { "NAND", };
+/* GPIO used to select between U-Boot and kernel */ +#define SPL_OS_BOOT_KEY 26 + /* * IEN - Input Enable * IDIS - Input Disable diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h index d926f74..788227d 100644 --- a/include/configs/devkit8000.h +++ b/include/configs/devkit8000.h @@ -354,7 +354,6 @@
/* SPL OS boot options */ #define CONFIG_SPL_OS_BOOT -#define CONFIG_SPL_OS_BOOT_KEY 26
#define CONFIG_CMD_SPL #define CONFIG_CMD_SPL_WRITE_SIZE 0x400 /* 1024 byte */ diff --git a/include/configs/twister.h b/include/configs/twister.h index a852481..4205a11 100644 --- a/include/configs/twister.h +++ b/include/configs/twister.h @@ -58,7 +58,6 @@ #define CONFIG_CMD_SPL_NAND_OFS (CONFIG_SYS_NAND_SPL_KERNEL_OFFS+\ 0x600000) #define CONFIG_SPL_OS_BOOT -#define CONFIG_SPL_OS_BOOT_KEY 55
#define CONFIG_SYS_SPL_ARGS_ADDR (PHYS_SDRAM_1 + 0x100) #define CONFIG_SPL_BOARD_INIT
Add a more descriptive text to the help of the spl command.
Signed-off-by: Stefano Babic sbabic@denx.de --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None
common/cmd_spl.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/common/cmd_spl.c b/common/cmd_spl.c index e3c543b..94b0a17 100644 --- a/common/cmd_spl.c +++ b/common/cmd_spl.c @@ -184,7 +184,11 @@ static int do_spl(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
U_BOOT_CMD( spl, 6 , 1, do_spl, "SPL configuration", - "export <img=atags|fdt> [kernel_addr] [initrd_addr] " - "[fdt_addr if <img> = fdt] - export a kernel parameter image\n" - "\t initrd_img can be set to "-" if fdt_addr without initrd img is" - "used"); + "export <img=atags|fdt> [kernel_addr] [initrd_addr] [fdt_addr]\n" + "\timg\t\t"atags" or "fdt"\n" + "\tkernel_addr\taddress where a kernel image is stored.\n" + "\t\t\tkernel is loaded as part of the boot process, but it is not started.\n" + "\tinitrd_addr\taddress of initial ramdisk\n" + "\t\t\tcan be set to "-" if fdt_addr without initrd_addr is used.\n" + "\tfdt_addr\tin case of fdt, the address of the device tree.\n" + );
Dear Stefano Babic,
On 02/12/2013 09:38 AM, Stefano Babic wrote:
Add a more descriptive text to the help of the spl command.
Signed-off-by: Stefano Babic sbabic@denx.de
Changes in v5: None Changes in v4: None Changes in v3: None
That is not correct, there where changes since v3, this patch was introduced in v2.
Changes in v2: None
However, no complaints on the patch content.
Acked-by: Andreas Bießmann andreas.devel@googlemail.com
Best regards
Andreas Bießmann
Dear Stefano Babic,
On 02/12/2013 09:38 AM, Stefano Babic wrote:
Simple howto to add support to a board for booting the kernel from SPL ("Falcon" mode).
Signed-off-by: Stefano Babic sbabic@denx.de
Changes in v5:
- several fixes for the language, rephrasing some unclear parts (Vikram Narayanan)
Changes in v4:
- fix capitalization, styling, in spl help (Andreas Biessmann)
- move CONFIG_SPL_OS_BOOT before function in doc (Andreas Biessmann)
Changes in v3:
- parameter initrd_addr was removed in V2 (Andreas Biessmann)
- added patch to fix help usage for spl export (Andreas Biessmann)
- Added empty lines (Otavio Salvador)
- add a more exhaustive description explaining that spl export does not save into media (Lukasz Majewski).
Changes in v2:
- spelling, language fixes (Andreas Biessman)
- rewrite some unclear sentences
- drop CONFIG_SPL_OS_BOOT_KEY
- make example with twister more exhaustive
doc/README.falcon | 169 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 169 insertions(+) create mode 100644 doc/README.falcon
diff --git a/doc/README.falcon b/doc/README.falcon new file mode 100644 index 0000000..72fe04a --- /dev/null +++ b/doc/README.falcon @@ -0,0 +1,169 @@ +U-Boot Falcon Mode +====================
+Introduction +------------
+This document provides an overview of how to add support for Falcon Mode +to a board. +Falcon Mode is introduced to speed up the booting process, allowing +to boot a Linux kernel (or whatever image) without a full blown U-Boot.
+Falcon Mode relies on the SPL framework. In fact, to make booting faster, +U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot +image. In most implementations, SPL is used to start U-Boot when booting from +a mass storage, such as NAND or SD-Card. SPL has now support for other media, +and can generally be seen as a way to start an image performing the minimum +required initialization. SPL mainly initializes the RAM controller, and then +copies U-Boot image into the memory. The Falcon Mode extends this way +allowing to start the Linux kernel directly from SPL. A new command is added +to U-Boot to prepare the parameters that SPL must pass to the kernel, using +ATAGS or Device Tree.
+In usual U-Boot systems, these parameters are generated each time before +loading the kernel, passing to Linux the address in memory where +the parameters can be read. +With Falcon Mode, this snapshot can be saved into persistent storage and SPL is +informed to load it before running the kernel.
+To boot the kernel, these steps under a Falcon-aware U-Boot are required:
+1. Boot the board into U-Boot. +Use the "spl export" command to generate the kernel parameters area or the DT. +U-Boot runs as when it boots the kernel, but stops before passing the control +to the kernel.
+2. Save the prepared snapshot into persistent media. +The address where to save it must be configured into board configuration +file (CONFIG_CMD_SPL_NAND_OFS for NAND).
+3. Boot the board into Falcon Mode. SPL will load the kernel and copy +the parameters which are saved in the persistent area area to the required address.
double 'area'
+It is required to implement a custom mechanism to select if SPL loads U-Boot +or another image.
+The value of a GPIO is a simple way to operate the selection, as well as +reading a character from the SPL console if CONFIG_SPL_CONSOLE is set.
+Falcon Mode is generally activated by setting CONFIG_SPL_OS_BOOT. This tells +SPL that U-Boot is not the only available image that SPL is able to start.
+Configuration +---------------------------- +CONFIG_CMD_SPL Enable the "spl export" command.
The command "spl export" is then available in U-Bootmode+CONFIG_SYS_SPL_ARGS_ADDR Address in RAM where the parameters must be
copied by SPL.In most cases, it is <start_of_ram> + 0x100+CONFIG_SYS_NAND_SPL_KERNEL_OFFS Offset in NAND where the kernel is stored
+CONFIG_CMD_SPL_NAND_OFS Offset in NAND where the parameters area was saved.
+CONFIG_CMD_SPL_WRITE_SIZE Size of the parameters area to be copied
+CONFIG_SPL_OS_BOOT Activate Falcon Mode.
+Function that a board must implement +------------------------------------
+void spl_board_prepare_for_linux(void) : optional
- Called from SPL before starting the kernel
+spl_start_uboot() : required
Returns "0" if SPL starts the kernel, "1" if U-Boot
minor complaint:
Returns "0" if SPL should start the kernel, ...
must be started.+Using spl command +-----------------
+spl - SPL configuration
+Usage:
+spl export <img=atags|fdt> [kernel_addr] [initrd_addr] [fdt_addr ]
-------------------------------------------------------------------^
This comes from 'spl export' v3 ;) Can you update this part with the v5 version of 'spl export' to make the README documentation the same as the command help?
+img : "atags" or "fdt" +kernel_addr : kernel is loaded as part of the boot process, but it is not started.
This is the address where a kernel image is stored.+initrd_addr : Address of initial ramdisk
can be set to "-" if fdt_addr without initrd img is used+fdt_addr : in case of fdt, the address of the device tree.
+The spl puts its result at a self gained position. The position is defined at compile +time or when generating the uImage but not at command line for 'spl export' +(see spl_export(): gd->bd->bi_boot_params vs. images.ft_addr).
+spl export' does not write directly to a storage media. This command is intended to save +the prepared information in RAM. +The user is responsible to save the data into the required media, as described +on the following example, at the offset set at compile time +(CONFIG_CMD_SPL_NAND_OFS in case of NAND).
The two paragraphs above say nearly the same, I think we should merge them. How about:
---8<--- The spl export command does not write to a storage media. The user is responsible to transfer the gathered information (assembled ATAGS list or prepared FDT) from temporary storage in RAM into persistant storage after each run of 'spl export'. Unfortunately the position of temporary storage can not be predicted nor provided at commandline, it depends highly on your system setup and your provided data (ATAGS or FDT). However at the end of an succesful 'spl export' run it will print the RAM address of temporary storage. Now the user have to save the generated BLOB from that printed address to the pre-defined address in persistent storage (CONFIG_CMD_SPL_NAND_OFS in case of NAND). The following example shows how to prepare the data for Falcon Mode on twister board with ATAGS BLOB. --->8---
Would be nice to have some FDT example too (in future).
+Usage on the twister board: +--------------------------------
+Using mtd names with the following (default) configuration +for mtdparts:
+device nand0 <omap2-nand.0>, # parts = 9
- #: name size offset mask_flags
- 0: MLO 0x00080000 0x00000000 0
- 1: u-boot 0x00100000 0x00080000 0
- 2: env1 0x00040000 0x00180000 0
- 3: env2 0x00040000 0x001c0000 0
- 4: kernel 0x00600000 0x00200000 0
- 5: bootparms 0x00040000 0x00800000 0
- 6: splashimg 0x00200000 0x00840000 0
- 7: mini 0x02800000 0x00a40000 0
- 8: rootfs 0x1cdc0000 0x03240000 0
+twister => nand read 82000000 kernel
+NAND read: device 0 offset 0x200000, size 0x600000
- 6291456 bytes read: OK
+Now the kernel is in RAM at address 0x82000000
+twister => spl export atags 0x82000000 +## Booting kernel from Legacy Image at 82000000 ...
- Image Name: Linux-3.5.0-rc4-14089-gda0b7f4
- Image Type: ARM Linux Kernel Image (uncompressed)
- Data Size: 3654808 Bytes = 3.5 MiB
- Load Address: 80008000
- Entry Point: 80008000
- Verifying Checksum ... OK
- Loading Kernel Image ... OK
+OK +cmdline subcommand not supported +bdt subcommand not supported +Argument image is now in RAM at: 0x80000100
+The result can be checked at address 0x80000100:
+twister => md 0x80000100 +80000100: 00000005 54410001 00000000 00000000 ......AT........ +80000110: 00000000 00000067 54410009 746f6f72 ....g.....ATroot +80000120: 65642f3d 666e2f76 77722073 73666e20 =/dev/nfs rw nfs
+The parameters generated with this step can be saved into NAND at the offset +0x800000 (value for twister for CONFIG_CMD_SPL_NAND_OFS)
+nand erase.part bootparms +nand write 0x80000100 bootparms 0x4000
+Now the parameters are stored into the NAND flash at the address +CONFIG_CMD_SPL_NAND_OFS (=0x800000).
+Next time, the board can be started into Falcon Mode moving the +setting the gpio (on twister gpio 55 is used) to kernel mode.
+The kernel is loaded directly by the SPL without passing through U-Boot.
+Falcon Mode was presented at the RMLL 2012. Slides are available at:
+http://schedule2012.rmll.info/IMG/pdf/LSM2012_UbootFalconMode_Babic.pdf
Best regards
Andreas Bießmann
On 12.02.2013 12:48, Andreas Bießmann wrote:
<big snip>
The spl export command does not write to a storage media. The user is responsible to transfer the gathered information (assembled ATAGS list or prepared FDT) from temporary storage in RAM into persistant storage after each run of 'spl export'. Unfortunately the position of temporary storage can not be predicted nor provided at commandline, it depends highly on your system setup and your provided data (ATAGS or FDT). However at the end of an succesful 'spl export' run it will print the RAM address of temporary storage. Now the user have to save the generated BLOB from that printed address to the pre-defined address in persistent storage (CONFIG_CMD_SPL_NAND_OFS in case of NAND). The following example shows how to prepare the data for Falcon Mode on twister board with ATAGS BLOB. --->8---
Would be nice to have some FDT example too (in future).
I used FDT with SPL already on the a3m071 board. Please take a look at the README (board/a3m071/README):
... Preparing Linux image(s) for booting from SPL U-Boot: ----------------------------------------------------- To boot the Linux kernel from the SPL, the DT blob (fdt) needs to get prepard/patched first. U-Boot usually inserts some dynamic values into the DT binary (blob), e.g. autodetected memory size, MAC addresses, clocks speeds etc. To generate this patched DT blob, you can use the following command:
1. Load fdt blob to SDRAM: => tftp 1800000 a3m071/a3m071.dtb
2. Set bootargs as desired for Linux booting (e.g. flash_mtd): => run mtdargs addip2 addtty
3. Use "fdt" commands to patch the DT blob: => fdt addr 1800000 => fdt boardsetup => fdt chosen
4. Display patched DT blob (optional): => fdt print
5. Save fdt to NOR flash: => erase fc060000 fc07ffff => cp.b 1800000 fc060000 10000 ...
So all we need for DT based booting (compared to ATAG booting) is the "fdt" command.
Stefano, perhaps you could integrate this into this README as well.
Thanks, Stefan
Dear Stefan Roese,
On 02/12/2013 01:09 PM, Stefan Roese wrote:
On 12.02.2013 12:48, Andreas Bießmann wrote:
<snip>
- Use "fdt" commands to patch the DT blob:
=> fdt addr 1800000 => fdt boardsetup => fdt chosen
- Display patched DT blob (optional):
=> fdt print
- Save fdt to NOR flash:
=> erase fc060000 fc07ffff => cp.b 1800000 fc060000 10000 ...
So all we need for DT based booting (compared to ATAG booting) is the "fdt" command.
As I understand this guide there is no 'spl export' required for 'Falcon Mode' with FDT, is that correct?
Stefano, perhaps you could integrate this into this README as well.
+1
Best regards
Andreas Bießmann
On 12.02.2013 13:44, Andreas Bießmann wrote:
- Use "fdt" commands to patch the DT blob:
=> fdt addr 1800000 => fdt boardsetup => fdt chosen
- Display patched DT blob (optional):
=> fdt print
- Save fdt to NOR flash:
=> erase fc060000 fc07ffff => cp.b 1800000 fc060000 10000 ...
So all we need for DT based booting (compared to ATAG booting) is the "fdt" command.
As I understand this guide there is no 'spl export' required for 'Falcon Mode' with FDT, is that correct?
Correct. At least thats how it works on PowerPC. It should work that way on ARM as well. No need for any "spl export" commands here.
Thanks, Stefan
On 02/12/2013 01:52 PM, Stefan Roese wrote:
On 12.02.2013 13:44, Andreas Bießmann wrote:
- Use "fdt" commands to patch the DT blob:
=> fdt addr 1800000 => fdt boardsetup => fdt chosen
- Display patched DT blob (optional):
=> fdt print
- Save fdt to NOR flash:
=> erase fc060000 fc07ffff => cp.b 1800000 fc060000 10000 ...
So all we need for DT based booting (compared to ATAG booting) is the "fdt" command.
As I understand this guide there is no 'spl export' required for 'Falcon Mode' with FDT, is that correct?
Correct. At least thats how it works on PowerPC. It should work that way on ARM as well. No need for any "spl export" commands here.
Well, Ok, this changes things a bit. The'spl export' command was prepared for 'bootm with fdt' to gather the same information as in ATAGS mode, honestly this was never tested cause Simon Schwarz worked with ATAGS too. If this is not required to prepare the fdt blob it was a misunderstanding from the very beginning of that command. However the README should reflect that the 'spl export' with fdt is untested and that ppc prepares the fdt blob with the fdt command instead.
Best regards
Andreas Bießmann
On 12/02/2013 13:44, Andreas Bießmann wrote:
Stefano, perhaps you could integrate this into this README as well.
+1
Right, I will push V6 with changes you suggested and integrating Stefan's part.
Regards, Stefano Babic
On Tue, Feb 12, 2013 at 6:38 AM, Stefano Babic sbabic@denx.de wrote:
Simple howto to add support to a board for booting the kernel from SPL ("Falcon" mode).
Signed-off-by: Stefano Babic sbabic@denx.de
Changes in v5:
- several fixes for the language, rephrasing some unclear parts (Vikram Narayanan)
Changes in v4:
- fix capitalization, styling, in spl help (Andreas Biessmann)
- move CONFIG_SPL_OS_BOOT before function in doc (Andreas Biessmann)
Changes in v3:
- parameter initrd_addr was removed in V2 (Andreas Biessmann)
- added patch to fix help usage for spl export (Andreas Biessmann)
- Added empty lines (Otavio Salvador)
- add a more exhaustive description explaining that spl export does not save into media (Lukasz Majewski).
Changes in v2:
- spelling, language fixes (Andreas Biessman)
- rewrite some unclear sentences
- drop CONFIG_SPL_OS_BOOT_KEY
- make example with twister more exhaustive
doc/README.falcon | 169 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 169 insertions(+) create mode 100644 doc/README.falcon
diff --git a/doc/README.falcon b/doc/README.falcon new file mode 100644 index 0000000..72fe04a --- /dev/null +++ b/doc/README.falcon @@ -0,0 +1,169 @@ +U-Boot Falcon Mode +====================
+Introduction +------------
+This document provides an overview of how to add support for Falcon Mode +to a board. +Falcon Mode is introduced to speed up the booting process, allowing +to boot a Linux kernel (or whatever image) without a full blown U-Boot.
Add a newline after board or move Falcon Mode to same phrase.
+Falcon Mode relies on the SPL framework. In fact, to make booting faster, +U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot +image. In most implementations, SPL is used to start U-Boot when booting from +a mass storage, such as NAND or SD-Card. SPL has now support for other media, +and can generally be seen as a way to start an image performing the minimum +required initialization. SPL mainly initializes the RAM controller, and then +copies U-Boot image into the memory.
New line.
The Falcon Mode extends this way +allowing to start the Linux kernel directly from SPL. A new command is added +to U-Boot to prepare the parameters that SPL must pass to the kernel, using +ATAGS or Device Tree.
+In usual U-Boot systems, these parameters are generated each time before
"In usual U-Boot systems"
Together with previous phrase and might be clear as: "In normal mode, these ..."
+loading the kernel, passing to Linux the address in memory where +the parameters can be read. +With Falcon Mode, this snapshot can be saved into persistent storage and SPL is +informed to load it before running the kernel.
+To boot the kernel, these steps under a Falcon-aware U-Boot are required:
+1. Boot the board into U-Boot. +Use the "spl export" command to generate the kernel parameters area or the DT. +U-Boot runs as when it boots the kernel, but stops before passing the control +to the kernel.
+2. Save the prepared snapshot into persistent media. +The address where to save it must be configured into board configuration +file (CONFIG_CMD_SPL_NAND_OFS for NAND).
+3. Boot the board into Falcon Mode. SPL will load the kernel and copy +the parameters which are saved in the persistent area area to the required address.
+It is required to implement a custom mechanism to select if SPL loads U-Boot +or another image.
+The value of a GPIO is a simple way to operate the selection, as well as +reading a character from the SPL console if CONFIG_SPL_CONSOLE is set.
+Falcon Mode is generally activated by setting CONFIG_SPL_OS_BOOT. This tells +SPL that U-Boot is not the only available image that SPL is able to start.
+Configuration +---------------------------- +CONFIG_CMD_SPL Enable the "spl export" command.
The command "spl export" is then available in U-Bootmode+CONFIG_SYS_SPL_ARGS_ADDR Address in RAM where the parameters must be
copied by SPL.In most cases, it is <start_of_ram> + 0x100+CONFIG_SYS_NAND_SPL_KERNEL_OFFS Offset in NAND where the kernel is stored
+CONFIG_CMD_SPL_NAND_OFS Offset in NAND where the parameters area was saved.
+CONFIG_CMD_SPL_WRITE_SIZE Size of the parameters area to be copied
+CONFIG_SPL_OS_BOOT Activate Falcon Mode.
+Function that a board must implement +------------------------------------
+void spl_board_prepare_for_linux(void) : optional
Called from SPL before starting the kernel+spl_start_uboot() : required
Returns "0" if SPL starts the kernel, "1" if U-Bootmust be started.+Using spl command +-----------------
+spl - SPL configuration
+Usage:
+spl export <img=atags|fdt> [kernel_addr] [initrd_addr] [fdt_addr ]
+img : "atags" or "fdt" +kernel_addr : kernel is loaded as part of the boot process, but it is not started.
This is the address where a kernel image is stored.+initrd_addr : Address of initial ramdisk
can be set to "-" if fdt_addr without initrd img is used+fdt_addr : in case of fdt, the address of the device tree.
+The spl puts its result at a self gained position. The position is defined at compile +time or when generating the uImage but not at command line for 'spl export' +(see spl_export(): gd->bd->bi_boot_params vs. images.ft_addr).
+spl export' does not write directly to a storage media. This command is intended to save +the prepared information in RAM. +The user is responsible to save the data into the required media, as described +on the following example, at the offset set at compile time +(CONFIG_CMD_SPL_NAND_OFS in case of NAND).
+Usage on the twister board: +--------------------------------
+Using mtd names with the following (default) configuration +for mtdparts:
+device nand0 <omap2-nand.0>, # parts = 9
- #: name size offset mask_flags
- 0: MLO 0x00080000 0x00000000 0
- 1: u-boot 0x00100000 0x00080000 0
- 2: env1 0x00040000 0x00180000 0
- 3: env2 0x00040000 0x001c0000 0
- 4: kernel 0x00600000 0x00200000 0
- 5: bootparms 0x00040000 0x00800000 0
- 6: splashimg 0x00200000 0x00840000 0
- 7: mini 0x02800000 0x00a40000 0
- 8: rootfs 0x1cdc0000 0x03240000 0
+twister => nand read 82000000 kernel
+NAND read: device 0 offset 0x200000, size 0x600000
- 6291456 bytes read: OK
+Now the kernel is in RAM at address 0x82000000
+twister => spl export atags 0x82000000 +## Booting kernel from Legacy Image at 82000000 ...
- Image Name: Linux-3.5.0-rc4-14089-gda0b7f4
- Image Type: ARM Linux Kernel Image (uncompressed)
- Data Size: 3654808 Bytes = 3.5 MiB
- Load Address: 80008000
- Entry Point: 80008000
- Verifying Checksum ... OK
- Loading Kernel Image ... OK
+OK +cmdline subcommand not supported +bdt subcommand not supported +Argument image is now in RAM at: 0x80000100
+The result can be checked at address 0x80000100:
+twister => md 0x80000100 +80000100: 00000005 54410001 00000000 00000000 ......AT........ +80000110: 00000000 00000067 54410009 746f6f72 ....g.....ATroot +80000120: 65642f3d 666e2f76 77722073 73666e20 =/dev/nfs rw nfs
+The parameters generated with this step can be saved into NAND at the offset +0x800000 (value for twister for CONFIG_CMD_SPL_NAND_OFS)
+nand erase.part bootparms +nand write 0x80000100 bootparms 0x4000
+Now the parameters are stored into the NAND flash at the address +CONFIG_CMD_SPL_NAND_OFS (=0x800000).
+Next time, the board can be started into Falcon Mode moving the +setting the gpio (on twister gpio 55 is used) to kernel mode.
+The kernel is loaded directly by the SPL without passing through U-Boot.
+Falcon Mode was presented at the RMLL 2012. Slides are available at:
+http://schedule2012.rmll.info/IMG/pdf/LSM2012_UbootFalconMode_Babic.pdf
1.7.9.5
participants (5)
-
Andreas Bießmann -
Otavio Salvador -
Stefan Roese -
Stefan Roese -
Stefano Babic