[U-Boot] ARM64 Allwinner Binary Size

Andre Przywara
2017-12-19T14:22:59Z

Hi,

On 19/12/17 14:20, Tom Rini wrote:
> On Tue, Dec 19, 2017 at 03:09:52PM +0100, Maxime Ripard wrote:
>> On Tue, Dec 19, 2017 at 08:30:31AM -0500, Tom Rini wrote:
>>> On Tue, Dec 19, 2017 at 02:26:40PM +0100, Maxime Ripard wrote:
>>>> 1;5002;0c
>>>> On Tue, Dec 19, 2017 at 08:15:31AM -0500, Tom Rini wrote:
>>>>> On Tue, Dec 19, 2017 at 02:12:02PM +0100, 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.)
>>>>>> - VIDEO_BPP8, VIDEO_BPP16
>>>>>> - VIDEO_ANSI
>>>>>> - SHA256
>>>>>> - LZMA
>>>>>>
>>>>>> 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).
>>>>>
>>>>> You want to keep sha256 support in FIT images, we only have dropping
>>>>> that allowed for some very odd use-cases. And while I don't have a
>>>>> strong opinion about unzip, lzma is one of the valid/likelu compressions
>>>>> for an Image (and aside, I, or someone, needs to look into having
>>>>> 'booti' recognize various compression algorithms and automatically
>>>>> decompress them) so I don't think we should get rid of that.
>>>>
>>>> So, adding back CMD_LZMADEC and FIT_ENABLE_SHA256_SUPPORT, we're at
>>>> 499kB. Still tight, but it fits.
>>>
>>> Looking over myself, perhaps drop CMD_BOOTD and move LOGLEVEL to 3?
>>
>> And we're at 498kB now! :)
>>
>> Is CMD_ELF useful as well?
>
> That's a good question. In 32bit land, that's how you're going to
> launch FreeRTOS and proprietary apps and so forth. I don't know if for
> aarch64 people will still be doing ELF applications or UEFI applications
> for all of this.

Eventually we will be, but for now (and the *defconfig*) I think it's
fine to drop it. If we stick to Maxime's plan, we can get it back in 6
months or so.

Cheers,
Andre.
>