[U-Boot] SPL loading multiple binaries from FIT image?
Simon Glass
sjg at chromium.org
Fri Aug 12 19:21:14 CEST 2016
Hi Andre,
On 1 July 2016 at 04:03, Andre Przywara <andre.przywara at arm.com> wrote:
> Hi,
>
> (sorry if this has been discussed before, feel free to point me to any
> existing thread then)
>
> for the Pine64 I am looking into letting the SPL load multiple images
> from a FIT image.
> Looking at common/spl/spl-fit.c I see that the current SPL FIT support
> just loads the first image from the "loadables" list as the U-Boot image
> and then selects and loads the matching FDT right after it.
> Feature-wise that seems to match what a legacy U-Boot image provides,
> but I was wondering if anyone uses the multiple images feature that FIT
> adds to the game?
>
> I need to at least load another image (ARM Trusted Firmware(ATF)),
> possibly the management controller firmware in the future as well.
> This has to be done before the actual U-Boot starts, so from the SPL.
>
> So I hacked the code to iterate over all images enumerated in the
> "loadables" property and load them to their load addresses. That somehow
> seems to work, but now I was wondering how to make this as flexible as
> possible:
> 1) How do we know what image is for U-Boot? Shall there be a separate
> "uboot" property (next to kernel, loadables, etc)? Or do we stay with
> the current assumption that it's the first from the loadables list?
That assumption seems reasonable and it is documented in
source_file_format.txt. If it causes problems we could adjust this
later.
> 2) At the moment we don't honour the entry point. Is there any reason
> for that?
Probably because the first user was an FPGA or extra kernel image,
which the CPU just has to load.
> 3) Would it be feasible to load all images listed in the loadables
> property and then branch to the only one (or the first) that has an
> entry point property? In my case this would be ATF (which then later
> drops to U-Boot at its well known load address).
Yes that seems reasonable. Another option would be to add a new entry
type instead of using 'firmware'.
>
> I wonder if this has been discussed before and would be grateful if
> people would share their opinion on the best approach. I will be happy
> to post patches once we agreed on something.
There has been some discussion recently on ATF with rockchip I think.
Also I've been working on a 'binman' tool which handles the task of
actually building firmware images from the build output.
https://www.mail-archive.com/u-boot@lists.denx.de/msg219798.html
>
> Cheers,
> Andre.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
Regards,
Simon
More information about the U-Boot
mailing list