On 12/11/2012 12:35, Andreas Bießmann wrote:
Hi Andreas,
+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.
+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.
+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
+Function that a board must implement +------------------------------------
+void spl_board_prepare_for_linux(void) : optional
- Called from SPL before starting the kernel
+spl_start_uboot() : required
Returns "0" if SPL starts the kernel, "1" if U-Bootmust be started.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?
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).
+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.
+init_addr : optional for atags - the address where the parameters area is generated into RAM
how about the initrd_addr mentioned 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