On Fri, Jul 04, 2025 at 01:40:40PM -0300, Fabio Estevam wrote: > On Fri, Jul 4, 2025 at 12:56 PM Tom Rini <[email protected]> wrote: > > > > On Fri, Jul 04, 2025 at 11:40:22AM -0300, Fabio Estevam wrote: > > > > > The mx6sabresd U-Boot proper binary size has grown beyond the > > > CONFIG_BOARD_SIZE_LIMIT. > > > > So, is CONFIG_BOARD_SIZE_LIMIT set incorrectly then and needs to be > > lowered? > > The current CONFIG_BOARD_SIZE_LIMIT is 715766. > > This value is CONFIG_ENV_OFFSET (0xC0000) - the offset for U-Boot > proper (69k) = 786432 − 69×1024 = 715776. > > The calculation itself is correct. > > The first issue: CI does not report a build failure. However, my local > build reports: > > u-boot.img exceeds file size limit: > limit: 0xaebf6 bytes > actual: 0xaed70 bytes > excess: 0x17a bytes > make: *** [Makefile:1501: u-boot.img] Error 1 > make: *** Deleting file 'u-boot.img' > make: *** Waiting for unfinished jobs.... > u-boot-dtb.img exceeds file size limit: > limit: 0xaebf6 bytes > actual: 0xaed70 bytes > excess: 0x17a bytes > make: *** [Makefile:1501: u-boot-dtb.img] Error 1 > make: *** Deleting file 'u-boot-dtb.img' > > The second issue is that even if I remove the > CONFIG_HAS_BOARD_SIZE_LIMIT/CONFIG_BOARD_SIZE_LIMIT, it builds, but > fails to boot like this:
Ah, so toolchain mismatch problems. Newer GCC optimizes better. > U-Boot SPL 2025.07-rc5-00012-g7027b445cc0b-dirty (Jul 04 2025 - 13:22:16 > -0300) > Trying to boot from MMC1 > > This boot failure is related to the initcall series. > > To avoid the mx6abresd boot regression and play safe for the upcoming > 2025.07, I'm more inclined to go with the previous patch version that > increases CONFIG_BOARD_SIZE_LIMIT. > > Jerome said he is working on a better fix, which reduces the size by > 1702 bytes for sabresd. > > Having CONFIG_BOARD_SIZE_LIMIT with too low a headroom may cause a > problem where, on some build systems, such as U-Boot CI, the build > succeeds, while others, like my local build, fail. > > Let's provide more CONFIG_BOARD_SIZE_LIMIT headroom to avoid this > situation from happening again. > > If you agree, feel free to pick v1. I think Jerome has the wrong idea here. The previous problem was on armv5 CPUs, armv7 CPUs are thumb2 and aren't tripping this problem. I suspect that if you used gcc-14.2.0 from kernel.org to build, current top of tree mainline would work. I think we should still take this patch as it's both correct and saves much more space so that we aren't quite so close and so dependent on gcc optimizations. -- Tom
signature.asc
Description: PGP signature
