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

[Andreas Bießmann]

Hi Stefano,

On 12.11.2012 14:02, Stefano Babic wrote:
> On 12/11/2012 12:35, Andreas Bießmann wrote:

<snip>

>>> +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).

sounds good to me.

>>> +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.

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.

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

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