[PATCH v5 00/11] spl: Use common function for loading/parsing images

[Tom Rini]

On Mon, Jul 31, 2023 at 06:42:52PM -0400, Sean Anderson wrote:

> This series adds support for loading all image types (Legacy, FIT (with
> and without LOAD_FIT_FULL), and i.MX) to the MMC, SPI, NOR, NET, FAT,
> and EXT load methods. It does this by introducing a helper function
> which handles the minutiae of invoking the proper parsing function, and
> reading the rest of the image.
> 
> Hopefully, this will make it easier for load methods to support all
> image types that U-Boot supports, without having undocumented
> unsupported image types. I applied this to several loaders which were
> invoking spl_load_simple_fit and/or spl_parse_image_header, but I did
> not use it with others (e.g. DFU/RAM) which had complications in the
> mix.
> 
> In order to meet size requirements for some boards, the first two
> patches of this series are general size-reduction changes. The ffs/fls
> change in particular should reduce code size across the board. The
> malloc change also has the potential to reduce code size. I've left it
> disabled by default, but maybe we can reverse that in the future.
> 
> Here's some bloat-o-meter for j7200_evm_a72_defconfig with ext4 support
> enabed:
> 
> add/remove: 2/1 grow/shrink: 1/5 up/down: 444/-584 (-140)
> Function                                     old     new   delta
> spl_load                                       -     216    +216
> spl_simple_read                                -     184    +184
> spl_fit_read                                  60     104     +44
> file_fat_read                                 40       -     -40
> spl_nor_load_image                           120      76     -44
> spl_load_image_ext                           364     296     -68
> spl_load_image_fat                           320     200    -120
> spl_spi_load_image                           304     176    -128
> spl_mmc_load                                 716     532    -184
> Total: Before=233618, After=233478, chg -0.06%
> 
> For most boards with a few load methods, this series should break even.
> However, in the worst case this series will add around 100 bytes.
> 
> I have only tested a few loaders. Please try booting your favorite board
> with NOR/SPI flash or SPI falcon mode.
> 
> On sama5d27_wlsom1_ek_mmc_defconfig, 100 bytes is too much, so this
> series depends on [1] to fit everything in. CI run at [2].
> 
> [1] https://lore.kernel.org/u-boot/20230731223327.109865-1-sean.anderson@seco.com/
> [2] https://source.denx.de/u-boot/custodians/u-boot-clk/-/pipelines/17116

I've boot-tested this on my lab and a handful of SD+FAT or SD+raw boot
devices, and it's all worked.  I also did my usual world build
before/after to check out the size changes and well, I don't know.  The
size wins come on platforms where there's both FAT+EXT support.  And
then on mips with say mt7620_rfb I wonder if we're loosing
functionality. But most platforms grow a bit, especially if they're just
a single load type (which is the most common case). Maybe this problem
needs to be approached another way? I've put the whole log over at
https://gist.github.com/trini/e6772b2134e0eb44393364ea98729e06 and maybe
something will jump out to you.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230802/d0da2975/attachment.sig>