[U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK

[Jagan Teki]

On Mon, Apr 2, 2018 at 7:13 AM, André Przywara <andre.przywara at 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 at google.com> wrote:
>>>> Hi Tom,
>>>>
>>>> On 7 August 2017 at 09:39, Tom Rini <trini at 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.

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

> 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.

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.