From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Andreas_Bie=DFmann?= Date: Mon, 12 Nov 2012 14:33:12 +0100 Subject: [U-Boot] [PATCH] Add README for the "Falcon" mode In-Reply-To: <50A0F357.1080407@denx.de> References: <1352717979-6284-1-git-send-email-sbabic@denx.de> <50A0DF04.6040102@gmail.com> <50A0F357.1080407@denx.de> Message-ID: <50A0FA98.1050507@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Stefano, On 12.11.2012 14:02, Stefano Babic wrote: > On 12/11/2012 12:35, Andreas Bie?mann wrote: >>> +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 [kernel_addr] [initrd_addr] [fdt_addr if = 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