On Wed, Apr 04, 2018 at 01:53:17AM +0800, Simon Glass wrote: > Hi Andre, > > On 2 April 2018 at 19:00, André Przywara <andre.przyw...@arm.com> wrote: > > Hi, > > > > On 02/04/18 03:30, Simon Glass wrote: > >> > >> 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, > > > > Yes, but this is merely different compiler *flags*, to the same (cross) > > compiler binary. ARM32 and ARM64 are different architectures to GCC, so > > require different compiler binaries with different prefixes. > > Last time I checked this wasn't easy to integrate into the U-Boot build > > system. > > One hack could be a "switching script", which filters for, say -m32", > > and calls the respective binary. But still we need to somehow set *two* > > CROSS_COMPILE prefixes. CROSS_COMPILE_SPL, maybe? > > But still it would require to install *two* cross compilers, and would > > spoil a completely native build by still requiring a cross compiler. > > That seems like a good idea to me.
I've lamented before (and I think others have too) that it's really a shame that gcc treats arm32 and arm64 as totally distinct builds (and where clang is a win). But I don't think we can require people to have both an arm and an aarch64 compiler available in order to build U-Boot for some aarch64. > > > > >>> 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. Here, my preference would be to again look at (4) then (3). I think a (5) TPL here would be enough of a something to get DDR available so that SPL can run there and not be subject to the tiny limits. But I have no idea how feasible that is here. -- Tom -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature