[U-Boot] [PATCH 00/15] spl: atf: update booting images via ATF to use info from FIT images
Michal Simek
michal.simek at xilinx.com
Mon Sep 25 09:05:05 UTC 2017
Hi Philipp,
On 13.9.2017 21:29, Philipp Tomsich wrote:
>
> A number of things about how we boot the RK3368 and RK3399 through ATF
> are less than ideal today, especially when considering future
> platforms that will follow a similar boot concept:
> - the auto-detection of images from the FIT images was limited (i.e.
> the start address of the BL33 image could not automatically retrieved)
> - no implementation for the platform-specific parameters exists (and
> there is a danger that we'll end up with highly different, proprietary
> platform parameters for different SOCs and boards, even though the
> ATF code base already has FDT support)
>
> This series tries to put us into a better position to support various
> boot scenarios (e.g. loading an OPTEE from the FIT image; and: booting
> a Linux kernel via ATF) in the future... and it establishes the FDT as
> a mechanism to pass boot-info to later stages.
>
> For a practical example, refer to how we use this on the RK3399-Q7:
> * the ATF can read the full U-Boot's FDT to determine how to best issue
> a cold-reset for the board
> * we inject information on where we loaded the M0 firmware into the
> same FDT that is now visible to the ATF, so the ATF can relocate it
> to its final destination---and we no longer need to overwrite parts
> of the SPL binary during bootup
>
> Note that there are still some limitations (e.g. the support for
> passing OPTEE as a BL3-2, is not in this version ... and there isn't
> support for booting Linux directly via ATF yet, either), but these can
> now be plugged cleanly into this infrastructure.
can you please send also sent your bootlogs?
I would like to see your flow also with pmu-firmware loading.
Thanks,
Michal
More information about the U-Boot
mailing list