[U-Boot] ARM64 Allwinner Binary Size

[Andre Przywara]

Hi Maxime,

On 19/12/17 14:20, Maxime Ripard wrote:
> 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.

Phew! ;-)

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

That sounds very reasonable to me, thanks for writing this down!

This gives us an only intermediate shortage of features for defconfig.

We should encourage everyone who builds (and ships) firmware right now
to drop MMC env support already, if they tinker with the .config anyway.
That is, if there is no legacy usage to be concerned about.

Cheers,
Andre.