[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