Hi Philipp,

On 14 April 2017 at 04:51, Dr. Philipp Tomsich
<philipp.toms...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Reply via email to