[U-Boot] ARM64 Allwinner Binary Size

[Andre Przywara <andre.przywara@arm.com>]

Hi,

On 19/12/17 14:38, Jagan Teki wrote:
> On Tue, Dec 19, 2017 at 7:57 PM, Andre Przywara <andre.przywara@arm.com> wrote:
>> 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.
> 
> All these trimming(if it fits) seems to be nice for now, but what if
> once driver-model MMC, reset, pinctrl, clk, regulator are IN?

But that is what all of this is about? At the moment we can't go beyond
504K because the raw MMC U-Boot environment lives there on the SD card.
But with Maxime's plan for 2018.05, this will be gone and we should have
about 984KB (1MB - 40K).

Cheers,
Andre.

> of-course we can't do anything with SPL size because of SRAM
> constraints, but U-Boot proper size? why can't we increase the u-boot
> partition size?
> 
> thanks!
>