[PATCH 00/49] image: Reduce #ifdefs and ad-hoc defines in image code
Sean Anderson
seanga2 at gmail.com
Wed May 5 01:24:25 CEST 2021
Hi Tom,
On 5/4/21 5:40 PM, Tom Rini wrote:
> On Mon, May 03, 2021 at 05:10:47PM -0600, Simon Glass wrote:
>
>> Much of the image-handling code predates the introduction of Kconfig and
>> has quite a few #ifdefs in it. It also uses its own IMAGE_... defines to
>> help reduce the #ifdefs, which is unnecessary now that we can use
>> IS_ENABLED() et al.
>>
>> The image code is also where quite a bit of code is shared with the host
>> tools. At present this uses a lot of checks of USE_HOSTCC.
>>
>> This series introduces 'host' Kconfig options and a way to use
>> CONFIG_IS_ENABLED() to check them. This works in a similar way to SPL, so
>>
>> CONFIG_IS_ENABLED(FIT)
>>
>> will evaluate to true on the host build (USE_HOSTCC) if CONFIG_HOST_FIT is
>> enabled. This allows quite a bit of clean-up of the image.h header file
>> and many of the image C files.
>>
>> The 'host' Kconfig options should help to solve a more general problem in
>> that we mostly want the host tools to build with all features enabled, no
>> matter which features the 'target' build actually uses. This is a pain to
>> arrange at present, but with 'host' Kconfigs, we can just define them all
>> to y.
>>
>> There are cases where the host tools do not have features which are
>> present on the target, for example environment and physical addressing.
>> To help with this, some of the core image code is split out into
>> image-board.c and image-host.c files.
>>
>> Even with these changes, some #ifdefs remain (101 down to 42 in
>> common/image*). But the code is somewhat easier to follow and there are
>> fewer build paths.
>>
>> In service of the above, this series includes a patch to add an API function
>> for zstd, so the code can be dropped from bootm.c
>>
>> It also introduces a function to handle manual relocation.
>
> I like this idea overall. The good news is this reduces the size in a
> few places. The bad news, but I can live with if we can't restructure
> the changes more, is a few functions grow a bit. This shows the good
> and the bad (something like sama5d2_ptc_ek_mmc shows only growth, to be
> clear):
What tool do you use to generate this output? Thanks.
--Sean
> px30-core-edimm2.2-px30: all -36 rodata -24 text -12
> u-boot: add: 0/0, grow: 3/-4 bytes: 36/-48 (-12)
> function old new delta
> boot_get_fdt 896 924 +28
> image_decomp 372 376 +4
> boot_get_ramdisk 868 872 +4
> do_bootm_vxworks 552 540 -12
> do_bootm_rtems 124 112 -12
> do_bootm_plan9 228 216 -12
> do_bootm_netbsd 324 312 -12
> odroid-c2 : all -105 bss +128 rodata -65 text -168
> u-boot: add: 0/0, grow: 2/-3 bytes: 108/-172 (-64)
> function old new delta
> images 504 608 +104
> image_decomp 372 376 +4
> image_setup_linux 108 96 -12
> boot_get_ramdisk 620 580 -40
> boot_get_fdt 660 540 -120
> origen : all +47 bss +96 rodata -57 text +8
> u-boot: add: 0/0, grow: 15/-2 bytes: 180/-104 (76)
> function old new delta
> images 288 340 +52
> do_bootm_states 1304 1348 +44
> do_bootz 164 176 +12
> do_bootm_vxworks 332 344 +12
> image_setup_libfdt 168 176 +8
> image_decomp 156 164 +8
> bootm_find_images 212 220 +8
> boot_prep_linux 276 284 +8
> image_setup_linux 54 58 +4
> do_bootm_standalone 60 64 +4
> do_bootm_plan9 104 108 +4
> do_bootm_netbsd 168 172 +4
> boot_prep_vxworks 48 52 +4
> boot_jump_vxworks 6 10 +4
> boot_jump_linux 148 152 +4
> boot_get_ramdisk 420 392 -28
> boot_get_fdt 420 344 -76
>
> And looking at ls1088ardb_sdcard_qspi_SECURE_BOOT I think there might be
> something wrong as that looks to drop all crypto algos from SPL. Other
> layerscape SECURE_BOOT configs show this as well. It does however seem
> to clear up some other issues around unused code, so a deeper dive on
> which patch is dropping stuff is needed. I see a huge drop on
> am65x_evm_a53 / j721e_evm_a72 SPL as well but I can test those and at
> least the basic case is fine. socfpga_agilex_atf is one I don't know
> about being right or wrong. socfpga_agilex_vab dropping hashing code
> does look worrying however, but maybe it's a configuration issue in the
> end?
>
More information about the U-Boot
mailing list