From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kever Yang Date: Mon, 23 Jan 2017 10:49:05 +0800 Subject: [U-Boot] [RFC PATCH 04/11] SPL: FIT: allow loading multiple images In-Reply-To: References: <1484877211-19332-1-git-send-email-andre.przywara@arm.com> <1484877211-19332-5-git-send-email-andre.przywara@arm.com> <58845A62.60408@rock-chips.com> Message-ID: <58856F21.1010409@rock-chips.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 Andre, On 01/22/2017 06:58 PM, Andr? Przywara wrote: > On 22/01/17 07:08, Kever Yang wrote: >> Hi Andre, >> >> Thanks for your patches, this is great help for enable ATF on U-Boot >> SPL. >> For ATF use case, we would like to identify which one is bl31 for we >> need to >> get entry point for it while we only need load address for other image. >> Any idea on get this information from different "loadables"? > So I thought this use case is covered by the current scheme? > > See below ... > >> On 01/20/2017 09:53 AM, Andre Przywara wrote: >>> So far we were not using the FIT image format to its full potential: >>> The SPL FIT loader was just loading the first image from the /images >>> node plus one of the listed DTBs. >>> Now with the refactored loader code it's easy to load an arbitrary >>> number of images in addition to the two mentioned above. >>> As described in the FIT image source file format description, iterate >>> over all images listed at the "loadables" property in the configuration >>> node and load every image at its desired location. >>> This allows to load any kind of images: >>> - firmware images to execute before U-Boot proper (for instance >>> ARM Trusted Firmware (ATF)) >>> - firmware images for management processors (SCP, arisc, ...) >>> - firmware images for devices like WiFi controllers >>> - bit files for FPGAs >>> - additional configuration data >>> - kernels and/or ramdisks >>> The actual usage of this feature would be platform and/or board specific. >>> >>> Signed-off-by: Andre Przywara >>> --- >>> common/spl/spl_fit.c | 27 +++++++++++++++++++++++++++ >>> 1 file changed, 27 insertions(+) >>> >>> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c >>> index d4149c5..18269f7 100644 >>> --- a/common/spl/spl_fit.c >>> +++ b/common/spl/spl_fit.c >>> @@ -190,6 +190,7 @@ int spl_load_simple_fit(struct spl_image_info >>> *spl_image, >>> struct spl_image_info image_info; >>> int node, images; >>> int base_offset, align_len = ARCH_DMA_MINALIGN - 1; >>> + int index = 0; >>> /* >>> * Figure out where the external images start. This is the base >>> for the >>> @@ -234,6 +235,11 @@ int spl_load_simple_fit(struct spl_image_info >>> *spl_image, >>> if (node < 0) { >>> debug("could not find firmware image, trying loadables...\n"); >>> node = spl_fit_get_image_node(fit, images, "loadables", 0); >>> + /* >>> + * If we pick the U-Boot image from "loadables", start at >>> + * the second image when later loading additional images. >>> + */ >>> + index = 1; >>> } >>> if (node < 0) { >>> debug("%s: Cannot find u-boot image node: %d\n", >>> @@ -259,5 +265,26 @@ int spl_load_simple_fit(struct spl_image_info >>> *spl_image, >>> image_info.load_addr = spl_image->load_addr + spl_image->size; >>> spl_load_fit_image(info, sector, fit, base_offset, node, >>> &image_info); >>> + /* Now check if there are more images for us to load */ >>> + for (; ; index++) { >>> + node = spl_fit_get_image_node(fit, images, "loadables", index); >>> + if (node < 0) >>> + break; >>> + >>> + spl_load_fit_image(info, sector, fit, base_offset, node, >>> + &image_info); >>> + >>> + /* >>> + * If the "firmware" image did not provide an entry point, >>> + * use the first valid entry point from the loadables. >>> + */ >>> + if (spl_image->entry_point == -1U && >>> + image_info.entry_point != -1U) >>> + spl_image->entry_point = image_info.entry_point; > So this part here saves the entry point from the first image which > provides an "entry" property in the loadables section, given that > "firmware" didn't provide (a legal) one. > > So depending on what you want, these are the options: > a) You want to branch to U-Boot (default case if mkimage -f auto is > used): You either don't specify an explicit entry point at all or > provide an "entry" property for the U-Boot "firmware" image. > The code below at the end of this function takes care of this. > b) You want to branch to something else (bl31.bin): You make sure there > is no explicit entry point in "firmware", instead put one "entry" > property in the bl31 image description you want to boot. This will then > branch to that instead of U-Boot. > Check the example .its in patch 10/11 for an example of this. > > So does this fit for you? Or is there a problem with this? So that means only one 'entry' can be present even if there are more than one image, right? I think every "firmware" image is possible to have both "load" and "entry" node, for example if we have bl31, bl32 and bl33(U-Boot) in one FIT image, then we need to fill the bl31_params_t structure with bl32 entry point and U-Boot entry point, so that bl31 able to call bl32 and bl33. That's why I think we need to identify each of the "firmware", but not only know they are "loadables". Thanks, - Kever >>> + } >>> + >>> + if (spl_image->entry_point == -1U || spl_image->entry_point == 0) >>> + spl_image->entry_point = spl_image->load_addr; > This statement here takes the load address of the "firmware" image as an > entry point if none is provided explicitly. > > Cheers, > Andre. > >>> + >>> return 0; >>> } > > > > >