[U-Boot] ARM64 Allwinner Binary Size

[Jagan Teki]

On Tue, Dec 19, 2017 at 7:57 PM, Andre Przywara <andre.przywara at 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?
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!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.