> From: Andre Przywara <andre.przyw...@arm.com> > Date: Tue, 19 Dec 2017 14:17:37 +0000 > > Hi, > > On 19/12/17 13:51, Mark Kettenis wrote: > >> From: Andre Przywara <andre.przyw...@arm.com> > >> Date: Tue, 19 Dec 2017 13:38:59 +0000 > >> > >> 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? > > > > For me/us (OpenBSD) the environment is still important. I have many > > setups where U-Boot lives on a uSD card but the installed OS lives on > > a USB device. In that scenario I set boot_targets to boot the EFI > > bootloader and OS off the USB disk. This is very helpfull for testing > > new versions of U-Boot as I can simply swap the uSD card. But for > > some setups this is essential as OpenBSD doesn't support the SD/MCC > > controller on all ARM hardware yet (but we do support it on > > Allwinner). > > I see, but I wasn't arguing for dropping the environment altogether, > more for supporting FAT environments *only*. > So how important is preserving existing environments over a firmware > update in your scenario? I think this is the killer question here, isn't > it? I'm inclined to just drop raw MMC environment support from sunxi64 > boards and then enjoy the ~450KB more worth of code, until we hit the > first MB boundary.
I wouldn't consider preserving the environment as crucial. > I have builds with all (DDR3) A64 board DTs in the binary [1], which > would be larger than 504K anyway. Oh, that's some cool work on the ATF side. Need to check that out. > Cheers, > Andre. > > [1] https://github.com/apritzel/pine64/commit/ee12bea43 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
