From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Date: Tue, 19 Dec 2017 13:38:59 +0000 Subject: [U-Boot] ARM64 Allwinner Binary Size In-Reply-To: <20171219131202.dkk4p4m27fv7jvdr@flea.lan> References: <11d6d712-610b-f972-1d5b-6ab062c07695@arm.com> <20171219131202.dkk4p4m27fv7jvdr@flea.lan> Message-ID: <7fea3496-99a5-cb94-256b-9b518d8be892@arm.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. > - 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. > 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? Cheers, Andre.