[U-Boot] ARM64 Allwinner Binary Size

Chen-Yu Tsai
2017-12-19T14:41:23Z

On Tue, Dec 19, 2017 at 10:38 PM, Jagan Teki <jagannadh.teki@gmail.com> 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?
> 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?

That is a really big if, given no one is actively working on it.
I reckon we deal with it when someone starts having patches merged. :)

ChenYu