[U-Boot] ARM64 Allwinner Binary Size

[Tom Rini]

On Tue, Dec 19, 2017 at 02:22:59PM +0000, Andre Przywara wrote:
> 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.

If we have to, we have to.  But I am weary of dropping and then
re-adding functionality like that as you never know what version some
company/vendor/etc is going to pick up and run with.  If we can't keep
the limit without dropping ELF, well, then we can't.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171219/fee2b129/attachment.sig>