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. Regards, Simon
