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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
