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
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
