On Mon, Apr 2, 2018 at 7:13 AM, André Przywara andre.przywara@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, sjg@google.com wrote:
Hi Tom,
On 7 August 2017 at 09:39, Tom Rini trini@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:
- 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.
May be this can be a good option and it has verified with board. As Simon pointed tegra for this matter about building two arch's I think we can try this out. I made some know change in arm/Makefile but unable to export armv7 and armv8 compilers so-that build can pick based on SPL and U-Boot?
--- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -24,6 +24,8 @@ arch-$(CONFIG_ARM64) =-march=armv8-a # but otherwise we can use the value in CONFIG_SYS_ARM_ARCH ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TEGRA),yy) arch-y += -D__LINUX_ARM_ARCH__=4 +else ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_MACH_SUN50I),yy) +arch-y += -D__LINUX_ARM_ARCH__=7 else arch-y += -D__LINUX_ARM_ARCH__=$(CONFIG_SYS_ARM_ARCH) endif
- 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.
I think it's difficult to implement TPL here because, we should require same SPL code for TPL like cpu, clock, DRAM and MMC(for boot mode) butif we have a way to return from BootROM once TPL loaded(like rockchip does) so-that we can skip MMC code from TPL.
Jagan.