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

[Simon Glass]

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.

Regards,
Simon