[U-Boot] ARM64 Allwinner Binary Size

[Andre Przywara]

Hi,

On 19/12/17 13:51, Mark Kettenis wrote:
>> From: Andre Przywara <andre.przywara at arm.com>
>> Date: Tue, 19 Dec 2017 13:38:59 +0000
>>
>> 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.
>>
>>>  - 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.
>>
>>> 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?
> 
> For me/us (OpenBSD) the environment is still important.  I have many
> setups where U-Boot lives on a uSD card but the installed OS lives on
> a USB device.  In that scenario I set boot_targets to boot the EFI
> bootloader and OS off the USB disk.  This is very helpfull for testing
> new versions of U-Boot as I can simply swap the uSD card.  But for
> some setups this is essential as OpenBSD doesn't support the SD/MCC
> controller on all ARM hardware yet (but we do support it on
> Allwinner).

I see, but I wasn't arguing for dropping the environment altogether,
more for supporting FAT environments *only*.
So how important is preserving existing environments over a firmware
update in your scenario? I think this is the killer question here, isn't
it? I'm inclined to just drop raw MMC environment support from sunxi64
boards and then enjoy the ~450KB more worth of code, until we hit the
first MB boundary.
I have builds with all (DDR3) A64 board DTs in the binary [1], which
would be larger than 504K anyway.

Cheers,
Andre.

[1] https://github.com/apritzel/pine64/commit/ee12bea43