[U-Boot] [PATCH] Add README for the "Falcon" mode

[Stefano Babic]

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-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?

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

-- 
=====================================================================
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
=====================================================================