Hi Andre, On 2 April 2018 at 09:43, André Przywara <andre.przyw...@arm.com> wrote: > Hi, > > On 01/04/18 14:19, Tom Rini wrote: >> On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote: >>> On Mon, Sep 4, 2017 at 9:57 PM, <s...@google.com> wrote: >>>> Hi Tom, >>>> >>>> On 7 August 2017 at 09:39, Tom Rini <tr...@konsulko.com> wrote: >>>>> On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote: >>>>> >>>>>> The CONFIG_BLK conversion involves quite invasive changes in the U-Boot >>>>>> code, with #ifdefs and different code paths. We should try to move over >>>>>> to >>>>>> this soon so we can drop the old code. >>> >>> I hope this will applicable to SPL too? >>> >>> If so, we are having SPL size issues with few Allwinner families, if >>> enable SPL_DM any suggestions? >> >> How close, and have you looked at the u-boot-spl.map to see what you can >> maybe trim? Or areas to look at reducing in code complexity? > > The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64 > SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map > and picked most low hanging fruits already. > So far we discussed several mitigations, but mostly to cover the > "natural" SPL code size grow over time: > 1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of > padding (for a 2KB architectural alignment). Given that the vectors are > used only for debugging purposes, we could scrap them entirely or > construct them on the fly in some other SRAM. So would free about 2.5KB, > ideally. Lowest hanging fruit so far. > 2) We can compile the SPL in AArch32 mode, which can use the Thumb2 > encoding. This reduces the size significantly, to about 20KB. The > disadvantage is using a second cross-compiler or even a additional > cross-compiler for native builds, complicating the build process. > I maintain a branch for enabling FEL booting here [1], which provides > two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper). > There are no technical disadvantages in running the SPL in 32-bit, so > this is mostly a build issue.
FYI 32-bit tegra compiles SPL with ARMv4T and U-Boot proper with ARMv7. It should be fairly easy to do, > 3) Try to use ILP32 for the AArch64 SPL build. This reduces the pointer > size and sizeof(long) to be 32-bit and should help, though I haven't > been able to successfully compile it yet (relocation types problems). > Despite lacking mainline support for AArch64 ILP32 in Linux and > glibc(?), GCC supports it for quite a while already. Unknown saving effect. > 4) Use runtime decompression. Most SoCs have larger or more SRAM than > the 32KB, so we could leverage this. Siarhei knows more about this. > 5) Use a TPL. Haven't looked at this in detail yet. > > So 1) would be the easiest to pursue, but 2.5KB are not enough to offset > the >10 KB toll the DM_SPL support actually takes. Is this the cost on 64-bit? I wonder if CONFIG_OF_PLATDATA might be an option? Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
