| Message ID | 1490999491-14899-6-git-send-email-andre.przywara@arm.com |
|---|---|
| State | Superseded |
| Delegated to: | Jagannadha Sutradharudu Teki |
| Headers | show |
Hi Andre , > 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 Would it be possible to adopt this code to also load SDRAM controller configuration data? The issue here is that we need to do it really "early" in SPL, before SDRAM configuration code (on TI for example). Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
On 03/04/17 10:40, Lukasz Majewski wrote: > Hi Andre , > >> 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 > > Would it be possible to adopt this code to also load SDRAM controller > configuration data? As it stands at the moment, this code is run when the SPL is finished with initialising the platform and is about to load and hand over to U-Boot proper. It would need to be investigated if the device driver required to actually load the FIT image works without DRAM being available (as in: do we have enough heap and stack, for instance). Also I am not sure the FIT (fdt) parsing code is really tuned for low memory, since normally it runs with DRAM already available. So while this doesn't sound impossible, it's probably some work ahead, depending on the resource limitation you have in SPL on your platform. > The issue here is that we need to do it really "early" in SPL, before > SDRAM configuration code (on TI for example). Yeah, I agree that this sounds tempting and I was thinking about this as well already. It would be nice to use the board detection code to select the right DRAM parameters, we have this use case on sunxi boards as well (some newer A64 based boards use LPDDR3, others use DDR3L). So far I was thinking about introducing some auto-detection feature in the DRAM init code to address this. Cheers, Andre.
> On 03 Apr 2017, at 12:05, Andre Przywara <andre.przywara@arm.com> wrote: > > On 03/04/17 10:40, Lukasz Majewski wrote: >> Hi Andre , >> >>> 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 >> >> Would it be possible to adopt this code to also load SDRAM controller >> configuration data? > > As it stands at the moment, this code is run when the SPL is finished > with initialising the platform and is about to load and hand over to > U-Boot proper. > It would need to be investigated if the device driver required to > actually load the FIT image works without DRAM being available (as in: > do we have enough heap and stack, for instance). > Also I am not sure the FIT (fdt) parsing code is really tuned for low > memory, since normally it runs with DRAM already available. > > So while this doesn't sound impossible, it's probably some work ahead, > depending on the resource limitation you have in SPL on your platform. The more general solution would be to move towards having a TPL in addition to the SPL… Regards, Philipp.
Hi Andre, > > > On 03/04/17 10:40, Lukasz Majewski wrote: > > Hi Andre , > > > >> 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 > > > > Would it be possible to adopt this code to also load SDRAM > > controller configuration data? > > As it stands at the moment, this code is run when the SPL is finished > with initialising the platform and is about to load and hand over to > U-Boot proper. > It would need to be investigated if the device driver required to > actually load the FIT image works without DRAM being available (as in: > do we have enough heap and stack, for instance). It all must be done with "simple malloc" enabled, since access to the config data requires SPI. However, the I2C works without the need to use "malloc" (as it is done with TI devices). > Also I am not sure the FIT (fdt) parsing code is really tuned for low > memory, since normally it runs with DRAM already available. > > So while this doesn't sound impossible, it's probably some work ahead, > depending on the resource limitation you have in SPL on your platform. This is doable - I'm sure :-) I'm just wondering if this could be added to this framework (to avoid double FIT parsing) - but (please correct me if I'm wrong) it seems conceptually different (@ different point in time we parse FIT and in your case DRAM is a must have). > > > The issue here is that we need to do it really "early" in SPL, > > before SDRAM configuration code (on TI for example). > > Yeah, I agree that this sounds tempting and I was thinking about this > as well already. > It would be nice to use the board detection code to select the right > DRAM parameters, we have this use case on sunxi boards as well (some > newer A64 based boards use LPDDR3, others use DDR3L). Ok. So such facility would be needed sooner or latter. > So far I was thinking about introducing some auto-detection feature in > the DRAM init code to address this. I can provide example from TI's playground (am57xx). They provide excel sheet to calculate values for DRAM controller's registers -> the output can be converted to binary blobs. > > Cheers, > Andre. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
On 31 March 2017 at 16:31, Andre Przywara <andre.przywara@arm.com> 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. > > Also update the FIT documentation to mention the new SPL feature. > > Signed-off-by: Andre Przywara <andre.przywara@arm.com> > Reviewed-by: Lokesh Vutla <lokeshvuta@ti.com> > --- > common/spl/spl_fit.c | 42 ++++++++++++++++++++++++++++++++++++++++-- > doc/uImage.FIT/howto.txt | 21 +++++++++++++++++++++ > 2 files changed, 61 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass <sjg@chromium.org> It would be useful to have an example .its file showing how to use this, in addition to the README change you did.
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c index cfcb1fe..edf4a43 100644 --- a/common/spl/spl_fit.c +++ b/common/spl/spl_fit.c @@ -231,6 +231,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image, struct spl_image_info image_info; int node, images, ret; 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 @@ -275,6 +276,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", @@ -302,6 +308,38 @@ int spl_load_simple_fit(struct spl_image_info *spl_image, * Align the destination address to ARCH_DMA_MINALIGN. */ image_info.load_addr = spl_image->load_addr + spl_image->size; - return spl_load_fit_image(info, sector, fit, base_offset, node, - &image_info); + ret = spl_load_fit_image(info, sector, fit, base_offset, node, + &image_info); + if (ret < 0) + return ret; + + /* 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; + + ret = spl_load_fit_image(info, sector, fit, base_offset, node, + &image_info); + if (ret < 0) + continue; + + /* + * If the "firmware" image did not provide an entry point, + * use the first valid entry point from the loadables. + */ + if (spl_image->entry_point == FDT_ERROR && + image_info.entry_point != FDT_ERROR) + spl_image->entry_point = image_info.entry_point; + } + + /* + * If a platform does not provide CONFIG_SYS_UBOOT_START, U-Boot's + * Makefile will set it to 0 and it will end up as the entry point + * here. What it actually means is: use the load address. + */ + if (spl_image->entry_point == FDT_ERROR || spl_image->entry_point == 0) + spl_image->entry_point = spl_image->load_addr; + + return 0; } diff --git a/doc/uImage.FIT/howto.txt b/doc/uImage.FIT/howto.txt index 14e316f..2988a52 100644 --- a/doc/uImage.FIT/howto.txt +++ b/doc/uImage.FIT/howto.txt @@ -44,6 +44,27 @@ image source file mkimage + dtc transfer to target + ---------------> image file --------------------> bootm image data file(s) +SPL usage +--------- + +The SPL can make use of the new image format as well, this traditionally +is used to ship multiple device tree files within one image. Code in the SPL +will choose the one matching the current board and append this to the +U-Boot proper binary to be automatically used up by it. +Aside from U-Boot proper and one device tree blob the SPL can load multiple, +arbitrary image files as well. These binaries should be specified in their +own subnode under the /images node, which should then be referenced from one or +multiple /configurations subnodes. The required images must be enumerated in +the "loadables" property as a list of strings. + +If a platform specific image source file (.its) is shipped with the U-Boot +source, it can be specified using the CONFIG_SPL_FIT_SOURCE Kconfig symbol. +In this case it will be automatically used by U-Boot's Makefile to generate +the image. +If a static source file is not flexible enough, CONFIG_SPL_FIT_GENERATOR +can point to a script which generates this image source file during +the build process. It gets passed a list of device tree files (taken from the +CONFIG_OF_LIST symbol). Example 1 -- old-style (non-FDT) kernel booting -----------------------------------------------