[PATCH 01/15] vbe: Split out some VBE code into a common file

[Simon Glass]

Hi Tom,

On Tue, 14 Jan 2025 at 05:58, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Tom,
>
> On Mon, 13 Jan 2025 at 18:22, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Thu, Jan 09, 2025 at 05:29:56AM -0700, Simon Glass wrote:
> >
> > > Loading a FIT is useful for other VBE methods, such as ABrec, so start
> > > a new common file. Add functions for reading the version and nvdata.
> > > Also add a function to get the block device.
> >
> > This is not a good commit message when you're also introducing
> > functional changes (blk_dread -> blk_read).
>
> Yes, I did not actually notice this size change at all, as mentioned,
> as I only built for a few boards (firefly rk3399/rk3288 and a few
> sandbox ones). The blk_dread() function is the old API for reading
> from a block. It didn't occur to me that blk_dread() would bypass the
> cache.
>
> > Further, this functional
> > change seems to introduce some other code being pulled in very
> > unexpectedly, and that needs to be explained. For example,
> > phycore_am62x_r5_usbdfu is another case and that has
> > CONFIG_BLOCK_CACHE=y but CONFIG_SPL_BLOCK_CACHE=n, and yet the size
> > growth is in full U-Boot.
>
> This board currently uses blk_dread(), but not blk_read(), so the
> addition of a blk_read() call in non-SPL causes the BLK cache to be
> pulled in.
>
> > Just moving code should not result in
> > unexpected size change.
>
> That's correct, so long as 'expected' size changes includes the normal
> function-call overhead and loss of intra-module optimisation.
>
> So, what to do here? I certainly don't want to use the old blk API.
> But I can perhaps do a patch which changes VBE to use the new one,
> first, so the size growth is within that commit. I looked up
> BLOCK_CACHE and it is used by 90% of boards.
>
> Another thing I could do (down the track) is a separate series to
> remove blk_d...() functions.

Further to this I've created a v2 series which splits the first commit
into more pieces, so we can more clearly see the code-size increase.
I'll hold off sending it for now, in case something else comes up in
this discussion.

Regards,
Simon