Add README for the "Falcon" mode
PATCH 1/1 Add README for the "Falcon" mode
Simple howto to add support to a board
for booting the kernel from SPL ("Falcon" mode).
--- doc/README.falcon | 124 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 124 insertions(+) create mode 100644 doc/README.falcon
doc/README.falcon new file +124 -0
@@ -0,0 +1,124 @@ +U-Boot "Falcon" Mode +==================== + +Introduction +------------ + +This documents provides an overview 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 mostly 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 be generalized seen as a way to start an image performing the minimum +required initialization. SPL initializes mainly the RAM controller, and after +that copies U-Boot image into the memory. The "Falcon" mode extends this way +allowing to start any kind of image, an in particular a Linux kernel, preparing +a snapshot of the parameters (ATAG or DT) required by the kernel to boot. + +Falcon adds a command under U-Boot to reuse all code responsible to prepare +the interface with the kernel. 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, 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. Saves 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 area to the address 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_SPL_OS_BOOT Activate Falcon mode. + A board should implement the following functions: + +CONFIG_SPL_OS_BOOT_KEY Common name for GPIO used to select between U-Boot + and kernel image. Optional. + +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 + +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 +----------------- + +twister => spl +spl - SPL configuration + +Usage: +spl export <img=atags|fdt> [kernel_addr] [initrd_addr] [fdt_addr if <img> = fdt] - export a kernel parameter image + initrd_img can be set to "-" if fdt_addr without initrd img isused + +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. +init_addr : optional for atags - the address where the parameters area is generated into RAM +fdt_addr : in case of fdt, the address of the device tree. + +Example (for the twister board): + +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 parameters generated with this step can be saved into NAND at the offset +0x800000 (value for twister for CONFIG_CMD_SPL_NAND_OFS) + +Next time, the board can be started into "Falcon mode" moving the +CONFIG_SPL_OS_BOOT_KEY GPIO. +The kernel is loaded directly by the SPL without passing through U-Boot. + +Falcon mode was presented at the RMLL 2011. Slides are available at: + +http://schedule2012.rmll.info/IMG/pdf/LSM2012_UbootFalconMode_Babic.pdf
Signature · 1 line
1.7.9.5
PATCH 1/1 Add README for the "Falcon" mode
Dear Stefano Babic,
Quoted 22 lines · Stefano Babic
Simple howto to add support to a board
for booting the kernel from SPL ("Falcon" mode).Signed-off-by Stefano Babic <[email protected]>CC Marek Vasut <[email protected]>CC Otavio Salvador <[email protected]>CC Tom Rini <[email protected]>--- doc/README.falcon | 124 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 124 insertions(+) create mode 100644 doc/README.falcondoc/README.falcon new file +4
-0@@ -0,0 +1,124 @@ +U-Boot "Falcon" Mode +==================== + +Introduction
doc/README.falcon line 14
Quoted 10 lines
doc/README.falcon new file +10
-0+------------ + +This documents provides an overview 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 mostly implementations, SPL is used to start U-Boot when booting from
-----------------^
In most implementations?
doc/README.falcon line 19
Quoted 5 lines
doc/README.falcon new file +5
-0+a mass storage, such as NAND or SD-Card. SPL has now support for other media, +and can be generalized seen as a way to start an image performing the minimum +required initialization. SPL initializes mainly the RAM controller, and after +that copies U-Boot image into the memory. The "Falcon" mode extends this way +allowing to start any kind of image, an in particular a Linux kernel, preparing
------------------------------------------^
and in particular? ------------------------------------------------------------------------^ to achieve that, to be able to boot linux, ... ?
The 'preparing a snapshot...' part of this sentence sounds weird to me.
Quoted 12 lines
doc/README.falcon new file +12
-0+a snapshot of the parameters (ATAG or DT) required by the kernel to boot. + +Falcon adds a command under U-Boot to reuse all code responsible to prepare +the interface with the kernel. 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, 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.
doc/README.falcon line 41
Quoted 10 lines
doc/README.falcon new file +10
-0+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. Saves 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 area to the address required address.
--------------------------------^
first address is not necessary here
Quoted 29 lines
doc/README.falcon new file +29
-0+ +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_SPL_OS_BOOT Activate Falcon mode. + A board should implement the following functions: + +CONFIG_SPL_OS_BOOT_KEY Common name for GPIO used to select between U-Boot + and kernel image. Optional. + +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
doc/README.falcon line 80
Quoted 10 lines
doc/README.falcon new file +10
-0+ +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.
In which way interact the CONFIG_SPL_OS_BOOT_KEY with the spl_start_uboot()? Is both required, can one use one or the other?
Quoted 5 lines
doc/README.falcon new file +5
-0+ + +Using spl command +----------------- +
doc/README.falcon line 95
Quoted 10 lines
doc/README.falcon new file +10
-0+twister => spl +spl - SPL configuration + +Usage: +spl export <img=atags|fdt> [kernel_addr] [initrd_addr] [fdt_addr if <img> = fdt] - export a kernel parameter image + initrd_img can be set to "-" if fdt_addr without initrd img isused + +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.
-------------------------------------------------------------^ persistently?
This is the place in mass storage, right?
doc/README.falcon line 96
Quoted 1 line
doc/README.falcon new file +1
-0+init_addr : optional for atags - the address where the parameters area is generated into RAM
how about the initrd_addr mentioned above?
Quoted 19 lines
doc/README.falcon new file +18
-0+fdt_addr : in case of fdt, the address of the device tree. + +Example (for the twister board): + +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 +
doc/README.falcon line 124
Quoted 10 lines
doc/README.falcon new file +10
-0+The parameters generated with this step can be saved into NAND at the offset +0x800000 (value for twister for CONFIG_CMD_SPL_NAND_OFS) + +Next time, the board can be started into "Falcon mode" moving the +CONFIG_SPL_OS_BOOT_KEY GPIO. +The kernel is loaded directly by the SPL without passing through U-Boot. + +Falcon mode was presented at the RMLL 2011. Slides are available at: + +http://schedule2012.rmll.info/IMG/pdf/LSM2012_UbootFalconMode_Babic.pdf
Best regards
Andreas Bie?mann
PATCH 1/1 Add README for the "Falcon" mode
On 12/11/2012 12:35, Andreas Bie?mann wrote:
Hi Andreas,
Quoted 5 lines
doc/README.falcon line 14
Quoted 3 lines
doc/README.falcon new file +3
-0+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 mostly implementations, SPL is used to start U-Boot when booting from-----------------^
In most implementations?
Thanks, I fix it.
Quoted 11 lines
doc/README.falcon line 19
Quoted 6 lines
doc/README.falcon new file +5
-0+a mass storage, such as NAND or SD-Card. SPL has now support for other media, +and can be generalized seen as a way to start an image performing the minimum +required initialization. SPL initializes mainly the RAM controller, and after +that copies U-Boot image into the memory. The "Falcon" mode extends this way +allowing to start any kind of image, an in particular a Linux kernel, preparing------------------------------------------^
and in particular? ------------------------------------------------------------------------^ to achieve that, to be able to boot linux, ... ?
The 'preparing a snapshot...' part of this sentence sounds weird to me.
I am a specialist to write weird sentences. I rewrite this part for V2, hoping to clarify what I like to explain.
Quoted 4 lines
Quoted 2 lines
+3. Boot the board into "Falcon" mode. SPL will load the kernel and copy +the parameters area to the address required address.
--------------------------------^
first address is not necessary here
Right
Quoted 4 lines
Quoted 4 lines
doc/README.falcon new file +4
-0+Function that a board must implement +------------------------------------ + +void spl_board_prepare_for_linux(void) : optional
Quoted 8 lines
doc/README.falcon line 80
Quoted 5 lines
doc/README.falcon new file +5
-0+ 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.In which way interact the
CONFIG_SPL_OS_BOOT_KEYwith thespl_start_uboot()? Is both required, can one use one or the other?
Really checking the implementation, it should be better to remove CONFIG_SPL_OS_BOOT_KEY. There is not a weak function for spl_start_uboot(), and I think it is better so. But CONFIG_SPL_OS_BOOT_KEY is used only inside spl_start_uboot() in the board's implementation. IMHO it will be better to use a local define for the GPIOs inside board files, and drop CONFIG_SPL_OS_BOOT_KEY (in another patch, I mean).
Quoted 6 lines
doc/README.falcon line 95
Quoted 3 lines
doc/README.falcon new file +3
-0+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.-------------------------------------------------------------^ persistently?
This is the place in mass storage, right?
No, but it could be (for NOR flash, for example). It is the address where a uImage can be found. It could be in RAM after loading it with tftp, or in a NOR flash.
In any case, the spl command does not call itself utilities to copy the kernel from mass storage - such as "nand read" or "fatload", for example.
Quoted 3 lines
Quoted 2 lines
+init_addr : optional for atags - the address where the parameters area is generated into RAM
how about the
initrd_addrmentioned above?
What is not clear ? init_addr is the destination address, where spl puts its result. Is it not clear from the description ?
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH 1/1 Add README for the "Falcon" mode
Hi Stefano,
Quoted 1 line · Stefano Babic
On 12/11/2012 12:35, Andreas Bie?mann wrote:
<snip>
Quoted 13 lines
Quoted 4 lines
Quoted 4 lines
doc/README.falcon new file +4
-0+Function that a board must implement +------------------------------------ + +void spl_board_prepare_for_linux(void) : optionalQuoted 8 lines
doc/README.falcon line 80
Quoted 5 lines
doc/README.falcon new file +5
-0+ 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.In which way interact the
CONFIG_SPL_OS_BOOT_KEYwith thespl_start_uboot()? Is both required, can one use one or the other?
Quoted 7 lines
Really checking the implementation, it should be better to remove
CONFIG_SPL_OS_BOOT_KEY. There is not a weak function forspl_start_uboot(), and I think it is better so. ButCONFIG_SPL_OS_BOOT_KEYis used only insidespl_start_uboot()in the board's implementation. IMHO it will be better to use a local define for the GPIOs inside board files, and dropCONFIG_SPL_OS_BOOT_KEY(in another patch, I mean).
sounds good to me.
Quoted 7 lines
Quoted 6 lines
doc/README.falcon line 95
Quoted 3 lines
doc/README.falcon new file +3
-0+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.-------------------------------------------------------------^ persistently?
This is the place in mass storage, right?
Quoted 6 lines
No, but it could be (for NOR flash, for example). It is the address where a uImage can be found. It could be in RAM after loading it with tftp, or in a NOR flash.
In any case, the spl command does not call itself utilities to copy the kernel from mass storage - such as "nand read" or "fatload", for example.
Ok, thats what I thought. But on first read of this README it was not clear to me which address I should write there. The step by step example should have some 'nand read' in it to clarify.
Quoted 5 lines
Quoted 2 lines
Quoted 1 line
+init_addr : optional for atags - the address where the parameters area is generated into RAM
how about the
initrd_addrmentioned above?What is not clear ?
init_addris the destination address, where spl puts its result. Is it not clear from the description ?
Well, the usage() for spl does not have a 'init_addr' but an 'initrd_addr'. Also your example line states:
---8<---
Usage:
spl export <img=atags|fdt> [kernel_addr] [initrd_addr] [fdt_addr if <img> = fdt] - export a kernel parameter image
initrd_img can be set to "-" if fdt_addr without initrd img isused
--->8---
So for me it is not clear where the 'init_addr' come from.
BTW: I find your detailed description way better than current usage() of spl command. Would IMHO be useful to add it there in another patch. another BTW: is there a typo in usage() for spl cmd? One line states 'initrd_addr' but some later it says 'initrd_img'.
And last: 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).
Best regards
Andreas Bie?mann
PATCH v2 1/2 Add README for the "Falcon" mode
In reply to Stefano BabicSimple howto to add support to a board
for booting the kernel from SPL ("Falcon" mode).
---
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 | 163 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 163 insertions(+) create mode 100644 doc/README.falcon
doc/README.falcon new file +163 -0
@@ -0,0 +1,163 @@ +U-Boot "Falcon" Mode +==================== + +Introduction +------------ + +This documents provides an overview 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 be generalized seen as a way to start an image performing the minimum +required initialization. SPL initializes mainly the RAM controller, and after +that 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. + +Falcon adds a command under U-Boot to reuse all code responsible to prepare +the interface with the kernel. 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, 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. Saves 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 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_SPL_OS_BOOT Activate Falcon mode. + A board should implement the following functions: + +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 + +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] [fdt_addr if <img> = fdt] - export a kernel parameter image + +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. +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). + +Example (for the twister board): +-------------------------------- + +Using mtd names and 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 2011. Slides are available at: + +http://schedule2012.rmll.info/IMG/pdf/LSM2012_UbootFalconMode_Babic.pdf
Signature · 1 line
1.7.9.5
PATCH v2 2/2 OMAP3: drop CONFIG_SPL_OS_BOOT_KEY and use local define
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.
---
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(-)
board/technexion/twister/twister.c +4 -4
@@ -161,10 +161,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; }
board/technexion/twister/twister.h +2 -0
@@ -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
board/timll/devkit8000/devkit8000.c +4 -4
@@ -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; }
board/timll/devkit8000/devkit8000.h +3 -0
@@ -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
include/configs/devkit8000.h +0 -1
@@ -353,7 +353,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 */
include/configs/twister.h +0 -1
@@ -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
Signature · 1 line
1.7.9.5
PATCH v2 2/2 OMAP3: drop CONFIG_SPL_OS_BOOT_KEY and use local define
Quoted 6 lines · Stefano Babic
CONFIG_SPL_OS_BOOT_KEYis used only in board files. It is not required to have a generalCONFIG_option. Rename it and define it in board directory.Signed-off-by Stefano Babic <[email protected]>
Tested on Devkit8000.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thomas_weber.vcf
Type: text/x-vcard
Size: 260 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121113/57bcf9bd/attachment.vcf>
PATCH v2 1/2 Add README for the "Falcon" mode
In reply to Stefano BabicHello Stefano,
there are some inconsistency for the writing of the Falcon mode:
"Falcon" mode, Falcon mode, Falcon, falcon, "Falcon mode"
Quoted 21 lines · Stefano Babic
Simple howto to add support to a board
for booting the kernel from SPL ("Falcon" mode).Signed-off-by Stefano Babic <[email protected]>---
Changes in v2:
- spelling, language fixes (Andreas Biessman)
- rewrite some unclear sentences
- dropCONFIG_SPL_OS_BOOT_KEY
- make example with twister more exhaustivedoc/README.falcon | 163 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 163 insertions(+) create mode 100644 doc/README.falcondoc/README.falcon new file +0
-0
doc/README.falcon line 7
Quoted 7 lines
doc/README.falcon new file +7
-0@@ -0,0 +1,163 @@ +U-Boot "Falcon" Mode +==================== + +Introduction +------------ + +This documents provides an overview how to add support for "Falcon" mode
This document provides ...
Quoted 7 lines
doc/README.falcon new file +7
-0+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
doc/README.falcon line 24
Quoted 10 lines
doc/README.falcon new file +10
-0+a mass storage, such as NAND or SD-Card. SPL has now support for other media, +and can be generalized seen as a way to start an image performing the minimum +required initialization. SPL initializes mainly the RAM controller, and after +that 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. + +Falcon adds a command under U-Boot to reuse all code responsible to prepare +the interface with the kernel. In usual U-boot systems, these parameters are
U-boot => U-Boot
doc/README.falcon line 37
Quoted 13 lines
doc/README.falcon new file +13
-0+generated each time before loading the kernel, passing to Linux the address +in memory where the parameters can be read. +With falcon, 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. Saves the prepared snapshot into persistent media.
Saves => Save
Quoted 114 lines
doc/README.falcon new file +114
-0+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 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_SPL_OS_BOOT Activate Falcon mode. + A board should implement the following functions: + +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 + +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] [fdt_addr if <img> = fdt] - export a kernel parameter image + +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. +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). + +Example (for the twister board): +-------------------------------- + +Using mtd names and 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
doc/README.falcon line 161
Quoted 10 lines
doc/README.falcon new file +10
-0+ +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 2011. Slides are available at:
I think it was in 2012.
doc/README.falcon line 163
Quoted 2 lines
doc/README.falcon new file +2
-0+ +http://schedule2012.rmll.info/IMG/pdf/LSM2012_UbootFalconMode_Babic.pdf
Regards,
Thomas
PATCH v2 1/2 Add README for the "Falcon" mode
In reply to Stefano BabicDear Stefano Babic,
Quoted 15 lines · Stefano Babic
Simple howto to add support to a board
for booting the kernel from SPL ("Falcon" mode).Signed-off-by Stefano Babic <[email protected]>---
Changes in v2:
- spelling, language fixes (Andreas Biessman)
- rewrite some unclear sentences
- dropCONFIG_SPL_OS_BOOT_KEY
- make example with twister more exhaustivedoc/README.falcon | 163 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 163 insertions(+) create mode 100644 doc/README.falcon
<snip>
doc/README.falcon line 58
Quoted 7 lines
doc/README.falcon new file +7
-0+Configuration +---------------------------- +CONFIG_CMD_SPL Enable the "spl export" command. + The command "spl export" is then available in U-Boot + mode +CONFIG_SPL_OS_BOOT Activate Falcon mode. + A board should implement the following functions:
I think reordering this list to have the required functions directly after the colon would be helpful. Alternatively add a pointer to the list of functions after the list of defines.
Quoted 30 lines
doc/README.falcon new file +30
-0+ +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 + +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] [fdt_addr if <img> = fdt] - export a kernel parameter image
doc/README.falcon line 98
Quoted 10 lines
doc/README.falcon new file +10
-0+ +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. +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).
I think you got me wrong by my last remarks about the usage() of 'spl export'.
First of all there is presumably a typo in the descriptive text.
The current code has this usage():
---8<---
"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")
--->8---
The arguments say something about 'initrd_addr' but the descriptive text has 'initrd_img'. I think (but do not know since I have not used the spl command so often) that the 'initrd_img' should be written 'initrd_addr' (cc Simon Schwarz for that).
The second thing in my last review of your patch was maybe shortly described. You did write there the correct usage() of 'spl export' but later on add a more descriptive text about the parameters of 'spl export'. In these descriptive text you did write 'init_addr' instead of 'initrd_addr' - that was my comment about.
Additionally I thought your descriptive text is way better than the current descriptive text of 'spl export', so I asked to add your description to the command.
Now the main reason for my writing here ;)
Your usage() of 'spl export' some lines above is wrong cause it is missing the 'initrd_addr' parameter.
<snip example>
Best regards
Andreas Bie?mann
PATCH v2 1/2 Add README for the "Falcon" mode
Quoted 6 lines · Andreas Bie?mann
doc/README.falcon line 58
Quoted 2 lines
doc/README.falcon new file +2
-0+CONFIG_SPL_OS_BOOT Activate Falcon mode. + A board should implement the following functions:I think reordering this list to have the required functions directly after the colon would be helpful. Alternatively add a pointer to the list of functions after the list of defines.
Yes, it is what I wanted to do. In fact, the phrase now before the colon seems incomplete, because the functions are missing. I will this entry at the end of the define, so that the functions will follow after it.
Quoted 11 lines
Quoted 11 lines
doc/README.falcon new file +10
-0+spl - SPL configuration + +Usage: + +spl export <img=atags|fdt> [kernel_addr] [fdt_addr if <img> = fdt] - export a kernel parameter image + +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. +fdt_addr : in case of fdt, the address of the device tree.
Quoted 8 lines
doc/README.falcon line 98
Quoted 5 lines
doc/README.falcon new file +5
-0+ + +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).I think you got me wrong by my last remarks about the
usage()of 'spl export'.
Probably...
Quoted 4 lines
First of all there is presumably a typo in the descriptive text.
Quoted 11 lines
The current code has this
usage():
---8<---
"export <img=atags|fdt> [kernel_addr] [initrd_addr] " "[fdt_addrif <img> = fdt] - export a kernel parameter image\n" "\tinitrd_imgcan be set to \"-\" iffdt_addrwithout initrd img is" "used")
--->8---
The arguments say something about 'initrd_addr' but the descriptive text has 'initrd_img'. I think (but do not know since I have not used the spl command so often) that the 'initrd_img' should be written 'initrd_addr' (cc Simon Schwarz for that).
Ok, I cannot avoid to fix this typo the command with a separate patch. Else documentation and code remain inconsistent.
Quoted 6 lines
The second thing in my last review of your patch was maybe shortly described. You did write there the correct
usage()of 'spl export' but later on add a more descriptive text about the parameters of 'spl export'. In these descriptive text you did write 'init_addr' instead of 'initrd_addr' - that was my comment about.
Ok, it seems I misunderstood. But I think your comment about where spl stores the result is helpful, even if the address is printed by the command itself.
Quoted 3 lines
Additionally I thought your descriptive text is way better than the current descriptive text of 'spl export', so I asked to add your description to the command.
Ok - I will put it into the spl help as well.
Quoted 4 lines
Now the main reason for my writing here ;)
Yourusage()of 'spl export' some lines above is wrong cause it is missing the 'initrd_addr' parameter.
Correct - to be fixed ;-)
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH v2 1/2 Add README for the "Falcon" mode
In reply to Stefano BabicQuoted 35 lines · Stefano Babic
Simple howto to add support to a board
for booting the kernel from SPL ("Falcon" mode).Signed-off-by Stefano Babic <[email protected]>---
Changes in v2:
- spelling, language fixes (Andreas Biessman)
- rewrite some unclear sentences
- dropCONFIG_SPL_OS_BOOT_KEY
- make example with twister more exhaustivedoc/README.falcon | 163 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 163 insertions(+) create mode 100644 doc/README.falcondoc/README.falcon new file +13
-0@@ -0,0 +1,163 @@ +U-Boot "Falcon" Mode +==================== + +Introduction +------------ + +This documents provides an overview 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
Quoted 6 lines
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,
In the text you have the offset to save the image onto a NAND offset so I fail to see how it'd be used for SD-Card.
Can you elaborate it a bit?
Quoted 19 lines
+and can be generalized seen as a way to start an image performing the minimum
+required initialization. SPL initializes mainly the RAM controller, and after
+that 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, usingdoc/README.falcon new file +3
-0+ATAGS or Device Tree. + +Falcon adds a command under U-Boot to reuse all code responsible toprepare
+the interface with the kernel. In usual U-boot systems, these parameters are
+generated each time before loading the kernel, passing to Linux the address
doc/README.falcon line 28
Quoted 3 lines
doc/README.falcon new file +3
-0+in memory where the parameters can be read. +With falcon, this snapshot can be saved into persistent storage and SPL is +informed to load it before running the kernel.
You mix Falcon and falcon. I'd say you always use Falcon as it is the name of the feature so it ought to be in upper case. Another thing, 'With falcon, ' ought to be move to the previous line or have an empty line before it.
doc/README.falcon line 39
Quoted 13 lines
doc/README.falcon new file +4
-0+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 orthe DT.
+U-boot runs as when it boots the kernel, but stops before passing the controldoc/README.falcon new file +5
-0+to the kernel. + +2. Saves 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).
And for others?
doc/README.falcon line 47
Quoted 9 lines
+3. Boot the board into "Falcon" mode. SPL will load the kernel and copy
doc/README.falcon new file +3
-0+the parameters area to the required address. + +It is required to implement a custom mechanism to select if SPL loadsU-Boot
doc/README.falcon new file +3
-0+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.
An empty line before "The value"?
Quoted 18 lines
+Falcon mode is generally activated by setting
CONFIG_SPL_OS_BOOT. This tellsdoc/README.falcon new file +6
-0+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 inU-Boot
doc/README.falcon new file +9
-0+ mode +CONFIG_SPL_OS_BOOT Activate Falcon mode. + A board should implement the following functions: + +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
Quoted 2 lines
stored
And other media?
doc/README.falcon line 71
Quoted 8 lines
+CONFIG_CMD_SPL_NAND_OFS Offset in NAND where the parameters area
was saved.doc/README.falcon new file +5
-0+ +CONFIG_CMD_SPL_WRITE_SIZE Size of the parameters area to be copied + +Function that a board must implement +------------------------------------
Is there others optional? Otherwise you could call it as:
Adding Falcon mode support for a board
+void spl_board_prepare_for_linux(void) : optional
Quoted 96 lines
doc/README.falcon new file +15
-0+ 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] [fdt_addr if <img> = fdt] -export a kernel parameter image
doc/README.falcon new file +3
-0+ +img : "atags" or "fdt" +kernel_addr : kernel is loaded as part of the boot process, but it isnot started.
doc/README.falcon new file +5
-0+ This is the address where a kernel image is stored. +fdt_addr : in case of fdt, the address of the device tree. + + +The spl puts its result at a self gained position. The position isdefined at compile
+time or when generating the uImage but not at command line for 'spl export'doc/README.falcon new file +50
-0+(see spl_export(): gd->bd->bi_boot_params vs. images.ft_addr). + +Example (for the twister board): +-------------------------------- + +Using mtd names and 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 theoffset
+0x800000 (value for twister forCONFIG_CMD_SPL_NAND_OFS)doc/README.falcon new file +15
-1+ +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 2011. Slides are available at: + +http://schedule2012.rmll.info/IMG/pdf/LSM2012_UbootFalconMode_Babic.pdf --
Quoted 3 lines
1.7.9.5
Regards,
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: otavio at ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
PATCH v2 1/2 Add README for the "Falcon" mode
Quoted 2 lines · Otavio Salvador
Hi Otavio,
Quoted 5 lines
In the text you have the offset to save the image onto a NAND offset so I fail to see how it'd be used for SD-Card.
Can you elaborate it a bit?
No, I can't without introducing errors. Current code supports Falcon only booting from NAND - I do not think that it is a big thing to use another media, but it is not yet done. This document must
Quoted 24 lines
+and can be generalized seen as a way to start an image performing the minimum
+required initialization. SPL initializes mainly the RAM controller, and after
+that 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.
+
+Falcon adds a command under U-Boot to reuse all code responsible to prepare
+the interface with the kernel. 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, this snapshot can be saved into persistent storage and SPL is
+informed to load it before running the kernel.
Quoted 1 line
You mix Falcon and falcon.
You're right, there are already comments about this. This will be fixed globally in V3 (I will use Falcon Mode consistently).
Quoted 4 lines
I'd say you always use Falcon as it is the
name of the feature so it ought to be in upper case. Another thing, 'With falcon, ' ought to be move to the previous line or have an empty line before it.
Ok
Quoted 18 lines
+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. Saves the prepared snapshot into persistent media. +The address where to save it must be configured into board configuration
+file (CONFIG_CMD_SPL_NAND_OFSfor NAND).
Quoted 1 line
And for others?
Not yet implemented, patches welcome ! But you are right, there is already a patch to use a NOR flash that should flow soon into mainline. I will check and add documentation for it. For the orher media, the document must be updated together when they will be full supported.
Quoted 13 lines
+3. Boot the board into "Falcon" mode. SPL will load the kernel and copy +the parameters 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 ifCONFIG_SPL_CONSOLEis set.
Quoted 1 line
An empty line before "The value"?
Ok
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH v2 1/2 Add README for the "Falcon" mode
Quoted 6 lines · Stefano Babic
Quoted 1 line · Otavio Salvador
Hi Otavio,
Quoted 1 line
Quoted 8 lines
Quoted 4 lines
In the text you have the offset to save the image onto a NAND offset so I fail to see how it'd be used for SD-Card.
Can you elaborate it a bit?
No, I can't without introducing errors. Current code supports Falcon only booting from NAND - I do not think that it is a big thing to use another media, but it is not yet done. This document must
So I'd say to drop the SD-Card from the document.
Quoted 91 lines
Quoted 24 lines
+and can be generalized seen as a way to start an image performing the minimum
+required initialization. SPL initializes mainly the RAM controller, and after
+that 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.
+
+Falcon adds a command under U-Boot to reuse all code responsible to prepare
+the interface with the kernel. 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, this snapshot can be saved into persistent storage and SPL is
+informed to load it before running the kernel.Quoted 1 line
You mix Falcon and falcon.
You're right, there are already comments about this. This will be fixed globally in V3 (I will use Falcon Mode consistently).
Quoted 4 lines
I'd say you always use Falcon as it is the
name of the feature so it ought to be in upper case. Another thing, 'With falcon, ' ought to be move to the previous line or have an empty line before it.Ok
Quoted 18 lines
+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. Saves the prepared snapshot into persistent media. +The address where to save it must be configured into board configuration
+file (CONFIG_CMD_SPL_NAND_OFSfor NAND).Quoted 1 line
And for others?
Not yet implemented, patches welcome ! But you are right, there is already a patch to use a NOR flash that should flow soon into mainline. I will check and add documentation for it. For the orher media, the document must be updated together when they will be full supported.
Quoted 3 lines
+3. Boot the board into "Falcon" mode. SPL will load the kernel and
copy
Quoted 8 lines
+the parameters 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 ifCONFIG_SPL_CONSOLEisset.
Quoted 3 lines
An empty line before "The value"?
Ok
Best regards,
Stefano Babic--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: otavio at ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
PATCH v3 1/3 Add README for the "Falcon" mode
In reply to Stefano BabicSimple howto to add support to a board
for booting the kernel from SPL ("Falcon" mode).
---
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 | 173 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 173 insertions(+) create mode 100644 doc/README.falcon
doc/README.falcon new file +173 -0
@@ -0,0 +1,173 @@ +U-Boot Falcon Mode +==================== + +Introduction +------------ + +This document provides an overview 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 be generalized seen as a way to start an image performing the minimum +required initialization. SPL initializes mainly the RAM controller, and after +that 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. + +Falcon Mode adds a command under U-Boot to reuse all code responsible to prepare +the interface with the kernel. 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 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_SPL_OS_BOOT Activate Falcon Mode. + A board should implement the following functions: + +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 + +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. This information must then be transferred to a final destination +where the SPL will load it, that is defined at compile time +(CONFIG_CMD_SPL_NAND_OFS in case of NAND). + +The user is responsible to save the data into the required media, as described +on the following example. + +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
Signature · 1 line
1.7.9.5
PATCH v3 2/3 OMAP3: drop CONFIG_SPL_OS_BOOT_KEY and use local define
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.
---
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(-)
board/technexion/twister/twister.c +4 -4
@@ -161,10 +161,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; }
board/technexion/twister/twister.h +2 -0
@@ -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
board/timll/devkit8000/devkit8000.c +4 -4
@@ -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; }
board/timll/devkit8000/devkit8000.h +3 -0
@@ -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
include/configs/devkit8000.h +0 -1
@@ -353,7 +353,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 */
include/configs/twister.h +0 -1
@@ -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
Signature · 1 line
1.7.9.5
PATCH v3 3/3 SPL: Change description for spl command
In reply to Stefano BabicAdd a more descriptive text to the help of the spl command.
---
common/cmd_spl.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
common/cmd_spl.c +8 -4
@@ -182,7 +182,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 img is used\n" +"\tfdt_addr\tin case of fdt, the address of the device tree.\n" + );
Signature · 1 line
1.7.9.5
PATCH v3 3/3 SPL: Change description for spl command
Dear Stefano Babic,
Quoted 14 lines · Stefano Babic
Add a more descriptive text to the help of the spl command.
Signed-off-by Stefano Babic <[email protected]>---
common/cmd_spl.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)common/cmd_spl.c +0
-0
common/cmd_spl.c static int do_spl(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) · line 185
Quoted 8 lines
common/cmd_spl.c +1
-4@@ -182,7 +182,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"
---------------------------------------------------------------------^ unnecessary blank
common/cmd_spl.c static int do_spl(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) · line 189
Quoted 4 lines
common/cmd_spl.c +4
-0+"\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"
------------------------^
Capitalization should be uniform. Either change all other places to capital beginning or start here with small letters.
common/cmd_spl.c static int do_spl(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) · line 190
Quoted 1 line
common/cmd_spl.c +1
-0+"\t\t\tcan be set to \"-\" if fdt_addr without initrd img is used\n"
--------------------------------------------------------------^ I think we should write here either 'initrd image'/'initial ramdisk image' or 'initrd_addr'. I know img is a well known abbreviation for image, but in a descriptive text we should IMHO not abbreviate. Additionally the sentence should stop with a full stop like the others do.
common/cmd_spl.c static int do_spl(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) · line 192
Quoted 3 lines
common/cmd_spl.c +2
-0+"\tfdt_addr\tin case of fdt, the address of the device tree.\n" + );
Best regards
Andreas Bie?mann
PATCH v3 1/3 Add README for the "Falcon" mode
In reply to Stefano BabicQuoted 2 lines · Stefano Babic
...
+Falcon Mode relies on the SPL framework. In fact, to make booting faster,
Quoted 17 lines
+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 be generalized seen as a way to start an image performing the minimum
+required initialization. SPL initializes mainly the RAM controller, and after(quoted diff) +2
-0+that 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 isadded
+to U-Boot to prepare the parameters that SPL must pass to the kernel, using
+ATAGS or Device Tree.
PATCH v3 1/3 Add README for the "Falcon" mode
Quoted 26 lines · Otavio Salvador
On Mon, Nov 19, 2012 at 7:11 AM, Stefano Babic <[email protected] <mailto:[email protected]>> wrote:
...
+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 be generalized seen as a way to start an image performing the minimum
+required initialization. SPL initializes mainly the RAM controller, and after
+that 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.
Quoted 3 lines
From the above text it seems the Falcon Mode is already available in SD-Card however this is not truth. Please rework this so it is clear what is already working and what needs to be done.
I reread the sentence, and I am really describing what SPL alone does, not Falcon mode. SPL is already available for different storage and there are some boards booting from SD. Check for CONFIG_SPL_MMC_SUPPORT in include/configs, there are plenty of boards using it.
On the other side, Falcon Mode (SPL + CONFIG_SPL_OS_BOOT) is set only for two boards, twister and devkit8000, bpth booting from NAND.
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH v3 1/3 Add README for the "Falcon" mode
In reply to Stefano BabicDear Stefano Babic,
Quoted 4 lines · Stefano Babic
Simple howto to add support to a board
for booting the kernel from SPL ("Falcon" mode).Signed-off-by Stefano Babic <[email protected]>
despite a small change
Quoted 14 lines
---
Changes in v3:
- parameterinitrd_addrwas 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
- dropCONFIG_SPL_OS_BOOT_KEY
- make example with twister more exhaustive
<snip>
Quoted 19 lines
doc/README.falcon new file +19
-0+Configuration +---------------------------- +CONFIG_CMD_SPL Enable the "spl export" command. + The command "spl export" is then available in U-Boot + mode +CONFIG_SPL_OS_BOOT Activate Falcon Mode. + A board should implement the following functions: + +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 + +Function that a board must implement
doc/README.falcon line 81
Quoted 10 lines
doc/README.falcon new file +10
-0+------------------------------------ + +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. + +
shouldn't we reorder that thing here (move CONFIG_SPL_OS_BOOT down to the functions)?
Best regards
Andreas Bie?mann
PATCH v3 1/3 Add README for the "Falcon" mode
Quoted 53 lines · Andreas Bie?mann
Dear Stefano Babic,
Quoted 4 lines · Stefano Babic
Simple howto to add support to a board
for booting the kernel from SPL ("Falcon" mode).Signed-off-by Stefano Babic <[email protected]>despite a small change
Acked-by Andreas Bie?mann <[email protected]>Quoted 14 lines
---
Changes in v3:
- parameterinitrd_addrwas 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
- dropCONFIG_SPL_OS_BOOT_KEY
- make example with twister more exhaustive<snip>
Quoted 24 lines
doc/README.falcon new file +24
-0+Configuration +---------------------------- +CONFIG_CMD_SPL Enable the "spl export" command. + The command "spl export" is then available in U-Boot + mode +CONFIG_SPL_OS_BOOT Activate Falcon Mode. + A board should implement the following functions: + +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 + +Function that a board must implement +------------------------------------ + +void spl_board_prepare_for_linux(void) : optional + Called from SPL before starting the kernel +
Quoted 9 lines
doc/README.falcon line 81
Quoted 5 lines
doc/README.falcon new file +5
-0+spl_start_uboot() : required + Returns "0" if SPL starts the kernel, "1" if U-Boot + must be started. + +shouldn't we reorder that thing here (move
CONFIG_SPL_OS_BOOTdown to the functions)?
arghh..right, I missed this change - I will do in V4.
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH v4 1/3 Add README for the "Falcon" mode
In reply to Stefano BabicSimple howto to add support to a board
for booting the kernel from SPL ("Falcon" mode).
---
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 | 173 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 173 insertions(+) create mode 100644 doc/README.falcon
doc/README.falcon new file +173 -0
@@ -0,0 +1,173 @@ +U-Boot Falcon Mode +==================== + +Introduction +------------ + +This document provides an overview 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 be generalized seen as a way to start an image performing the minimum +required initialization. SPL initializes mainly the RAM controller, and after +that 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. + +Falcon Mode adds a command under U-Boot to reuse all code responsible to prepare +the interface with the kernel. 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 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. + A board should implement the following functions: + +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. This information must then be transferred to a final destination +where the SPL will load it, that is defined at compile time +(CONFIG_CMD_SPL_NAND_OFS in case of NAND). + +The user is responsible to save the data into the required media, as described +on the following example. + +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
Signature · 1 line
1.7.9.5
PATCH v4 2/3 OMAP3: drop CONFIG_SPL_OS_BOOT_KEY and use local define
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.
---
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(-)
board/technexion/twister/twister.c +4 -4
@@ -161,10 +161,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; }
board/technexion/twister/twister.h +2 -0
@@ -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
board/timll/devkit8000/devkit8000.c +4 -4
@@ -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; }
board/timll/devkit8000/devkit8000.h +3 -0
@@ -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
include/configs/devkit8000.h +0 -1
@@ -353,7 +353,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 */
include/configs/twister.h +0 -1
@@ -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
Signature · 1 line
1.7.9.5
PATCH v4 3/3 SPL: Change description for spl command
In reply to Stefano BabicAdd a more descriptive text to the help of the spl command.
---
common/cmd_spl.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
common/cmd_spl.c +8 -4
@@ -182,7 +182,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" + );
Signature · 1 line
1.7.9.5
PATCH v4 1/3 Add README for the "Falcon" mode
In reply to Stefano BabicHi Stefano,
Sorry for bumping in at v4. Below are some of my comments.
Quoted 9 lines · Stefano Babic
Simple howto to add support to a board
for booting the kernel from SPL ("Falcon" mode).Signed-off-by Stefano Babic<[email protected]>---
Changes in v4:
- fix capitalization, styling, in spl help (Andreas Biessmann)
- moveCONFIG_SPL_OS_BOOTbefore function in doc (Andreas Biessmann)
<snip>
doc/README.falcon line 7
Quoted 13 lines
doc/README.falcon new file +7
-0@@ -0,0 +1,173 @@ +U-Boot Falcon Mode +==================== + +Introduction +------------ + +This document provides an overview how to add support for Falcon Mode
s/an overview/an overview of/
doc/README.falcon line 16
Quoted 9 lines
doc/README.falcon new file +9
-0+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 be generalized seen as a way to start an image performing the minimum
Rephrase the above line as,
and can generally be seen ....
doc/README.falcon line 18
Quoted 2 lines
doc/README.falcon new file +2
-0+required initialization. SPL initializes mainly the RAM controller, and after +that copies U-Boot image into the memory. The Falcon Mode extends this way
Rephrase ..
SPL mainly initializes the RAM controller, and then copies U-boot image to the main memory.
doc/README.falcon line 23
Quoted 5 lines
doc/README.falcon new file +5
-0+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. + +Falcon Mode adds a command under U-Boot to reuse all code responsible to prepare
Already it is mentioned that 'a new command is added'. The above line is redundant then. Please rephrase it.
Quoted 9 lines
doc/README.falcon new file +9
-0+the interface with the kernel. 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.
doc/README.falcon line 42
Quoted 10 lines
doc/README.falcon new file +10
-0+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 area to the required address.
copy the parameters which is saved in the persistent media to the ....
Quoted 8 lines
doc/README.falcon new file +8
-0+ +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
doc/README.falcon
Quoted 10 lines
doc/README.falcon new file +10
-0+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
A space in between is and '<'
doc/README.falcon line 64
Quoted 4 lines
doc/README.falcon new file +4
-0+ +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.
Can the above be renamed to include the word 'PARAMS'? But becomes lengthy. Any suggestions?
doc/README.falcon line 69
Quoted 5 lines
doc/README.falcon new file +5
-0+ +CONFIG_CMD_SPL_WRITE_SIZE Size of the parameters area to be copied + +CONFIG_SPL_OS_BOOT Activate Falcon Mode. + A board should implement the following functions:
Is there a big difference between the line above and the one below?
Quoted 23 lines
doc/README.falcon new file +23
-0+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.
doc/README.falcon line 103
Quoted 10 lines
doc/README.falcon new file +10
-0+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. This information must then be transferred to a final destination
^ [1]
Final destination? How is it getting transferred?
Shall lines/content [1] and [2] merged?
doc/README.falcon line 108
Quoted 5 lines
doc/README.falcon new file +5
-0+where the SPL will load it, that is defined at compile time +(CONFIG_CMD_SPL_NAND_OFS in case of NAND). + +The user is responsible to save the data into the required media, as described +on the following example.
^ [2]
Quoted 42 lines
doc/README.falcon new file +42
-0+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: +
doc/README.falcon line 161
Quoted 10 lines
doc/README.falcon new file +10
-0+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
If the offset is known at compile time, why should the end user use the above commands to write it? Can't it be automated? Just an idea.
doc/README.falcon line 173
Quoted 11 lines
doc/README.falcon new file +11
-0+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
Regards,
Vikram
PATCH v4 1/3 Add README for the "Falcon" mode
Dear Vikram Narayanan,
On 23.11.12 19:10, Vikram Narayanan wrote:
<snip>
Quoted 9 lines
doc/README.falcon line 161
Quoted 6 lines
+The parameters generated with this step can be saved into NAND at the offset
+0x800000 (value for twister forCONFIG_CMD_SPL_NAND_OFS)doc/README.falcon new file +3
-0+ +nand erase.part bootparms +nand write 0x80000100 bootparms 0x4000If the offset is known at compile time, why should the end user use the above commands to write it? Can't it be automated? Just an idea.
No, please read
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/102326
or
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/147205
Best regards
Andreas Bie?mann
PATCH v4 1/3 Add README for the "Falcon" mode
Hello Andreas,
Quoted 16 lines · Andreas Bie?mann
Dear Vikram Narayanan,
On 23.11.12 19:10, Vikram Narayanan wrote:
<snip>
Quoted 9 lines
doc/README.falcon line 161
Quoted 6 lines
+The parameters generated with this step can be saved into NAND at the offset
+0x800000 (value for twister forCONFIG_CMD_SPL_NAND_OFS)doc/README.falcon new file +3
-0+ +nand erase.part bootparms +nand write 0x80000100 bootparms 0x4000If the offset is known at compile time, why should the end user use the above commands to write it? Can't it be automated? Just an idea.
Quoted 5 lines
No, please read
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/102326
or
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/147205
Thanks. Clarified.
Regards,
Vikram
PATCH v4 1/3 Add README for the "Falcon" mode
In reply to Vikram NarayananQuoted 4 lines · Vikram Narayanan
Hi Stefano,
Sorry for bumping in at v4. Below are some of my comments.
No problems, all reviews are welcome ! I fix your comments in V5.
Quoted 3 lines
If the offset is known at compile time, why should the end user use the above commands to write it? Can't it be automated? Just an idea.
No, it's not - Andreas have already given links to previous threads where this issue was discussed.
Best regards,
Stefano
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH 1/1 Add README for the "Falcon" mode
In reply to Stefano BabicQuoted 4 lines · Stefano Babic
Simple howto to add support to a board
for booting the kernel from SPL ("Falcon" mode).Signed-off-by Stefano Babic <[email protected]>
Could this be updated and resend? This is an interesting feature which lacks documentation currently.
Regards,
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: otavio at ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
PATCH 1/1 Add README for the "Falcon" mode
Quoted 8 lines · Otavio Salvador
Quoted 4 lines · Stefano Babic
Simple howto to add support to a board
for booting the kernel from SPL ("Falcon" mode).Signed-off-by Stefano Babic <[email protected]>Could this be updated and resend? This is an interesting feature which lacks documentation currently.
Hi Otavio,
you are right, and thanks to point out that the documentation is not yet merged. I will push a V5 as I promised with fixes for the last comments.
Regards,
Stefano
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================