On Tue, Dec 19, 2017 at 10:38 PM, Jagan Teki <jagannadh.t...@gmail.com> wrote: > On Tue, Dec 19, 2017 at 7:57 PM, Andre Przywara <andre.przyw...@arm.com> > wrote: >> Hi Maxime, >> >> On 19/12/17 14:20, Maxime Ripard wrote: >>> On Tue, Dec 19, 2017 at 01:38:59PM +0000, Andre Przywara wrote: >>>> 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. >>> >>> So, with FIT_ENABLE_SHA256_SUPPORT, LZMADEC, ISO_PARTITION and the >>> overlay support, we're at 500kB. >>> >>> Again, tight, but under the limit. >> >> Phew! ;-) >> >>> >>>>> - 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. >>> >>> Yes, that's my view too. >>> >>>>> 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? >>> >>> Pretty much as important as it is on arm I guess. We just have less >>> history, but the same use cases. >>> >>> I'd really like to give at least one release for transition, which >>> would mean having a schedule like this: >>> >>> - in 2018.01, merge those config removals so that we have least have >>> something that works quite fast >>> >>> - in 2018.03, merge the multiple environment patches. We seem to >>> have reached a consensus here, so I'm not really concerned that we >>> will have it merged. >>> >>> - in 2018.05, if needed, remove the raw MMC options and complete the >>> transition to FAT. >> >> That sounds very reasonable to me, thanks for writing this down! >> >> This gives us an only intermediate shortage of features for defconfig. >> >> We should encourage everyone who builds (and ships) firmware right now >> to drop MMC env support already, if they tinker with the .config anyway. >> That is, if there is no legacy usage to be concerned about. > > All these trimming(if it fits) seems to be nice for now, but what if > once driver-model MMC, reset, pinctrl, clk, regulator are IN? > of-course we can't do anything with SPL size because of SRAM > constraints, but U-Boot proper size? why can't we increase the u-boot > partition size?
That is a really big if, given no one is actively working on it. I reckon we deal with it when someone starts having patches merged. :) ChenYu _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
