[U-Boot] ARM64 Allwinner Binary Size

[Maxime Ripard]

On Tue, Dec 19, 2017 at 01:38:59PM +0000, Andre Przywara wrote:
> Hi Maxime,
> 
> thanks for having a look!
> 
> On 19/12/17 13:12, Maxime Ripard wrote:
> > On Tue, Dec 05, 2017 at 10:28:20AM +0000, Andre Przywara wrote:
> >> So even though the actual u-boot.bin for 64-bit boards is still somewhat
> >> below the limit (~480KB), adding the ATF image (~32KB) pushes it over
> >> the edge. So since v2017.11 u-boot.itb is already too big for the
> >> traditional MMC env location.
> > 
> > So I've had a quick look about what could go possibly go away in our
> > current armv8 config (using the pine64+ defconfig). Let me know if
> > some are actually vitals:
> > 
> >  - FIT_ENABLE_SHA256_SUPPORT
> >  - CONSOLE_MUX
> >  - CMD_CRC32
> >  - CMD_LZMADEC
> >  - CMD_UNZIP
> >  - CMD_LOADB
> >  - CMD_LOADS
> >  - CMD_MISC (actually implementing the command sleep)
> >  - ISO_PARTITION (yes. For CDROMs.)
> 
> As Alex mentioned, this is needed for some installer images, which come
> as ISOs. So if possible, we should keep this in.

So, with FIT_ENABLE_SHA256_SUPPORT, LZMADEC, ISO_PARTITION and the
overlay support, we're at 500kB.

Again, tight, but under the limit.

> >  - VIDEO_BPP8, VIDEO_BPP16
> >  - VIDEO_ANSI
> >  - SHA256
> >  - LZMA
> 
> From just looking at the names I am fine with the rest gone. But let me
> test tonight if there are any side effects.
> 
> Some of them seem useful, but I would leave enabling them to the actual
> users. If someone needs it, they can enable them and loose the raw MMC
> environment. I think this is a fair trade-off.

Yes, that's my view too.

> > Removing those options make the u-boot.itb binary size going from
> > 516kB to 478kB, making it functional again *and* allowing us to enable
> > the DT overlays that seem way more important than any feature
> > mentionned above (and bumps the size to 483kB).
> 
> How important is the raw MMC environment for the ARM64 boards, actually?
> Most of the rationale for the 32-bit side seemed to apply to legacy use
> cases only. Do we have reports/complaints from 64-bit users?

Pretty much as important as it is on arm I guess. We just have less
history, but the same use cases.

I'd really like to give at least one release for transition, which
would mean having a schedule like this:

  - in 2018.01, merge those config removals so that we have least have
    something that works quite fast

  - in 2018.03, merge the multiple environment patches. We seem to
    have reached a consensus here, so I'm not really concerned that we
    will have it merged.

  - in 2018.05, if needed, remove the raw MMC options and complete the
    transition to FAT.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com