> Am 12.04.2018 um 10:37 schrieb Marek Vasut <ma...@denx.de>: > >> On 04/12/2018 10:01 AM, Alexander Graf wrote: >> >> >>> On 11.04.18 16:43, Dinh Nguyen wrote: >>>> On Wed, Apr 11, 2018 at 7:55 AM, Alexander Graf <ag...@suse.de> wrote: >>>>> On 04/11/2018 02:37 PM, Marek Vasut wrote: >>>>> >>>>>> On 04/11/2018 02:26 PM, Tom Rini wrote: >>>>>> >>>>>>> On Wed, Apr 11, 2018 at 10:12:42AM +0200, Marek Vasut wrote: >>>>>>> >>>>>>> On 04/11/2018 04:52 AM, Dinh Nguyen wrote: >>>>>>> [...] >>>>>>> >>>>>>>>>>> u-boot$ git reset --hard v2018.01 ; bu socfpga_cyclone5 ; ls -la >>>>>>>>>>> spl/u-boot-spl.bin >>>>>>>>>>> HEAD is now at f3dd87e0b9 Prepare v2018.01 >>>>>>>>>>> -rw-r--r-- 1 marex marex 52902 Apr 11 00:34 spl/u-boot-spl.bin >>>>>>>>>>> >>>>>>>>>>> u-boot$ git reset --hard v2018.03 ; bu socfpga_cyclone5 ; ls -la >>>>>>>>>>> spl/u-boot-spl.bin >>>>>>>>>>> HEAD is now at f95ab1fb6e Prepare v2018.03 >>>>>>>>>>> -rw-r--r-- 1 marex marex 59706 Apr 11 00:34 spl/u-boot-spl.bin >>>>>>>>>>> >>>>>>>>>>> Try bisecting out the commit which caused this 7 kiB growth between >>>>>>>>>>> 2018.01 and 2018.03 . Even those 53 kiB are quite borderline, but it >>>>>>>>>>> was >>>>>>>>>>> at 53 kiB for a while (2017.05 is also ~53 kiB) >>>>>> >>>>>> Do you have a size constraint and are not setting the correct CONFIG >>>>>> options so that it becomes a build failure? >>>>>> >>>>>>>>>> Doing the bisect points me to this commit: >>>>>>>>>> >>>>>>>>>> commit fa2c14676c7c6f3115dd4d9b2a4cc3b35c3ad2a2 >>>>>>>>>> Author: Tom Rini <tr...@konsulko.com> >>>>>>>>>> Date: Sat Feb 10 16:54:38 2018 -0500 >>>>>>>>>> >>>>>>>>>> configs: Re-sync with CONFIG_DISTRO_DEFAULTS >>>>>>>>>> >>>>>>>>>> A number of platforms include config_distro_defaults.h but do >>>>>>>>>> not enable >>>>>>>>>> CONFIG_DISTRO_DEFAULTS. As they plainly intended to, set that >>>>>>>>>> flag and >>>>>>>>>> re-sync config files. >>>>>>>>>> >>>>>>>>>> Signed-off-by: Tom Rini <tr...@konsulko.com> >>>>>>>>>> >>>>>>>>>> Doing a revert of the above commit shrinks the SPL back down to ~7 >>>>>>>>>> kiB. >>>>>>>>>> >>>>>>>>>> Dinh >>>>>>>>>> >>>>>>>>> It looks like the enablement of CONFIG_DISTRO_DEFAULTS, enables these >>>>>>>>> configs: >>>>>>>>> >>>>>>>>> CONFIG_ISO_PARTITION=y >>>>>>>>> CONFIG_SPL_ISO_PARTITION=y >>>>>>>>> # CONFIG_AMIGA_PARTITION is not set >>>>>>>>> # CONFIG_SPL_AMIGA_PARTITION is not set >>>>>>>>> CONFIG_EFI_PARTITION=y >>>>>>>>> CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=128 >>>>>>>>> CONFIG_EFI_PARTITION_ENTRIES_OFF=0 >>>>>>>>> CONFIG_SPL_EFI_PARTITION=y >>>>>>>>> CONFIG_PARTITION_UUIDS=y >>>>>>>>> CONFIG_SPL_PARTITION_UUIDS=y >>>>>>>>> # CONFIG_PARTITION_TYPE_GUID is not set >>>>>>>>> >>>>>>>>> Which is contributing to the SPL growth. >>>>>>>>> >>>>>>>> Turning the following config options off subtracts 7k from the SPL: >>>>>>>> >>>>>>>> +# CONFIG_SPL_ISO_PARTITION is not set >>>>>>>> +# CONFIG_SPL_EFI_PARTITION is not set >>>>>>>> >>>>>>>> Not sure if these are needed? >>>>>>> >>>>>>> IMO not on SoCFPGA. Also CCing Tom. >>>>>> >>>>>> Yes, all of those options are part of CONFIG_DISTRO_DEFAULTS and are >>>>>> needed so that booting from various distro media works. >>>>> >>>>> In SPL on boards which usually boot from SDMMC or QSPI NOR ? How is EFI >>>>> or ISO partition needed there ? >>>> >>>> >>>> >>>> I don't think ISO partitioning is needed in SPL. However, for GPT I'm not >>>> 100% sure. People tend to go with GPT more often than not these days - and >>>> to be able to fetch U-Boot proper from a GPT partition may make sense. >>>> >>>> How much reduction do you get when you only disable >>>> CONFIG_SPL_ISO_PARTITION? >>>> >>> >>> ~3 kiB >> >> Ok, so that's not enough to get us back to reasonable space, but it's at >> least a step in the right direction. I sent a patch to disable >> CONFIG_SPL_ISO_PARTITION for everyone by default ;). >> >> If we remove all printfs from part_efi.c we could for example gain >> another 1.5kb. But I'm not sure that's worth it - and if feels like >> we're shaving on the wrong end at this point. >> >> Is there any other big chunk in there that wastes space? > > The entire EFI support, which is never used on SoCFPGA to my knowledge, > esp. in SPL .
None of it is enabled in SPL :). The „efi partition“ option is a misnomer - it really just enables GPT partition table support which are widely in use with Android for example. Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
