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
