[U-Boot] [PATCH v3 05/19] SPL: FIT: allow loading multiple images

[Lukasz Majewski]

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 at denx.de