Patrick Georgi has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/33068 )
Change subject: soc/rockchip/rk3288: Disable bootblock console ......................................................................
Patch Set 1:
Patch Set 1: I'm missing some context here, are you saying that the tree is already broken right now?
Depending on what you're looking for it's broken for about a week, or for about an hour: The jenkins build continued to work (until ~1h ago) because it does "timeless" builds which came with a shorter version string: just enough to make the build pass.
CrOS downstreaming or manual builds weren't as lucky and failed about a week ago.
Does it help if you select CONFIG_NO_POST instead? How many bytes added / over the limit are we talking about?
After taking out all the asserts, I get the following lines in bootblock.map: ff708e88 T _etext ff708ec0 D _data ff708ec0 d mdev ff708ee0 d rockchip_spi_slaves ff708eec D gpio_port ff708f10 B _bss ff708f10 B maskrom_param ff708f10 D _edata ff708f18 B exception_stack ff709000 A _ebootblock ff709000 B _preram_cbmem_console ff709018 b console_inited ff70901c b spi_flash_info ff709048 b spi_flash_init_done ff70904c b cbmem_console_p ff709050 B vboot_executed ff709058 B _ebss ff709058 B _eprogram
Of note (the ones that normally break the build) are _ebootblock (end of region) and _eprogram (end of code section that should be <= _ebootblock). NO_POST has no effect on these, interestingly enough.
If adding post codes caused this, maybe we should see this as a canary that the added patches were badly optimized? Arm devices shouldn't use POST codes anyway.
We don't use LTO in coreboot (yet) which would probably solve the issue by eliminating the code. The compiler lacks the visibility to know that it can optimize away the post code and call to post_code() and hence the extra function. #define die_with_post_code(val, msg) die((msg)) _nearly_ helps, but not quite: ff708e68 T _etext ff708e80 D _data ... ff709018 B _eprogram