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