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