Hi Tom, On Fri, 13 Dec 2024 at 07:05, Tom Rini <[email protected]> wrote: > > On Thu, Dec 12, 2024 at 08:24:06PM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 12 Dec 2024 at 20:09, Tom Rini <[email protected]> wrote: > > > > > > On Thu, Dec 12, 2024 at 07:11:55PM -0600, Tom Rini wrote: > > > > On Sat, 07 Dec 2024 10:23:53 -0700, Simon Glass wrote: > > > > > > > > > This includes various patches towards implementing the VBE abrec > > > > > bootmeth in U-Boot. It mostly focuses on SPL tweaks and adjusting what > > > > > fatures are available in VPL. > > > > > > > > > > Changes in v3: > > > > > - Add new patch to avoid size growth in spl_mmc_find_device() debug > > > > > - Use strlcpy() instead of strncpy() > > > > > - Rebase to master > > > > > > > > > > [...] > > > > > > > > Applied to u-boot/next, thanks! > > > > > > And, ugh, I missed that CI was failing for real. This causes > > > rcar3_salvator-x to fail to link due to size growth, so I'm reverting > > > this for now, sorry. I thought the CI failure I saw was due to something > > > else at the time. > > > > Hmm, sorry about that...it passed CI when I sent it! > > > > The growth is quite alarming and I am not sure how to make sense of > > it. Here is the last patch: > > > > 21: hash: Plumb crc8 into the hash functions > > aarch64: + rcar3_salvator-x > > aarch64: (for 1/1 boards) all +2109.0 bss -48.0 data +56.0 rodata > > +5.0 text +2096.0 > > rcar3_salvator-x: all +2109 bss -48 data +56 rodata +5 text > > +2096 > > u-boot: add: 1/0, grow: 1/0 bytes: 136/0 (136) > > function old new > > delta > > crc8_wd_buf - 80 > > +80 > > hash_algo 280 336 > > +56 > > > > So perhaps apply all but the final patch? Then I can sort out things from > > there. > > I tried that before going off for the night without remembering that the > problem is: > +(rcar3_salvator-x) u-boot.img exceeds file size limit: > +(rcar3_salvator-x) limit: 0x100000 bytes > +(rcar3_salvator-x) actual: 0x100392 bytes > +(rcar3_salvator-x) excess: 0x392 bytes > > So no, just the last patch alone is not enough. You need to sync up with > Marek about what can/can't be disabled on the platform (or more likely > really, r-car gen3 platforms overall0.
I don't really like the size growth and I think it might be better to put my hash addition behind a Kconfig. While these boards are inconvenient, they do keep us honest, on code size. Regards, Simon
