[U-Boot] [PATCH] rockchip: reserve memory for rk3399 ATF data

[Simon Glass]

Hi Philipp,

On 14 April 2017 at 04:51, Dr. Philipp Tomsich
<philipp.tomsich at theobroma-systems.com> wrote:
> Kever,
>
> Do we really need to change the SPL layout (i.e. BL2) for this?
>
> The SPL code should remain independent of later stages. This change would tie the
> U-Boot SPL (BL2) to a specific implementation/memory layout of the later BL31 stage.
> It should rather remain the responsibility of the BL31 stage to properly relocate itself
> as needed upon startup...
>
> Our (yet unreleased) development tree (for ATF) uses a much less intrusive approach
> to achieve the same result (using the knowledge that the ATF will not return to SPL and
> thus allowing the ATF to overwrite memory areas previously used by SPL):
> 1.      ATF (BL31), the M0-firmware and the second-stage U-Boot are loaded as
>         separate firmware blobs into DRAM using Andre's FIT image loader patches
> 2.      SPL transfers control to ATF (with a vendor-specific parameter payload, which
>         contains the location of the M0 firmware in DRAM)
> 3.      ATF installs the M0 firmware into its final location
>
> Note that we’ve split the M0 firmware off the ATF build (and into a separate repository),
> as we’d otherwise end up with ELF files that has data/code/etc in the first MB of the
> address space and the M0 binary at 0xff8c0000 — if you convert such an ELF to a binary,
> you’d end up with a file size of approx. 4GB.  In other words: we don’t include the M0
> binary into the ATF, but load it separately through the FIT image loader...
>
> I’ll try to get our Cortex-M0 and ATF repositories pushed to our public GIT by early
> next week, so you can review…
>

So should we take this patch in the meantime, or is it a backwards step?

- Simon