From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Tue, 19 Dec 2017 09:20:44 -0500 Subject: [U-Boot] ARM64 Allwinner Binary Size In-Reply-To: <20171219140952.3alsrguxn6jo6k2y@flea.lan> References: <11d6d712-610b-f972-1d5b-6ab062c07695@arm.com> <20171219131202.dkk4p4m27fv7jvdr@flea.lan> <20171219131531.GX14220@bill-the-cat> <20171219132640.vdagmsb3qrgmjrii@flea.lan> <20171219133031.GY14220@bill-the-cat> <20171219140952.3alsrguxn6jo6k2y@flea.lan> Message-ID: <20171219142044.GA14220@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: