Hi Tom, On Tue, 14 Jan 2025 at 05:58, Simon Glass <[email protected]> wrote: > > Hi Tom, > > On Mon, 13 Jan 2025 at 18:22, Tom Rini <[email protected]> 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
