Hi Tom,
On Mon, 13 Jan 2025 at 18:22, Tom Rini trini@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