Hi, On 2 April 2018 at 11:07, Peter Robinson <pbrobin...@gmail.com> wrote: > On Mon, Apr 2, 2018 at 3:56 AM, Simon Glass <s...@chromium.org> wrote: >> Hi Peter, >> >> On 2 April 2018 at 10:45, Peter Robinson <pbrobin...@gmail.com> wrote: >>> On Mon, Apr 2, 2018 at 3:28 AM, Simon Glass <s...@google.com> 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, >>> >>> ARMv4 and ARMv7 are both 32 bit though, as opposed to 32 and 64 bit in >>> the case of Allwinner A64 >> >> Yes, but that is just a matter of compiler or compiler flags. My point >> was we should be able to use different build for each without too much >> work. > > It's a lot more work for the way most distros build u-boot, but TBH > the sooner I don't need to the better ;-)
I don't understand the last part of that sentence. But getting back to the original question, DM does add size, DT adds more. There is CONFIG_OF_PLATDATA which essentially removes the DT cost, but DM remains (perhaps 5KB at a guess on 64-bit). So we will have pressure to avoid using DM in SPL for some time to come, I think. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot