Hi all,
Not sure how to word this better so here goes nothing.
I recently wanted to debug some issues possibly related to DM which had a bunch of debug() log messages I wanted to see. To see those, one needs to define DEBUG. Once that's done, assert() calls are now built in.
It turns out that this means I cannot boot my board anymore because (at least) one of the assert() fails (specifically an ofnode_valid()).
I've for now narrowed the one in SPL to dev_read_u32(protocol, "arm,smc-id", &func_id) in smccc_agent.c, c.f. https://elixir.bootlin.com/u-boot/v2024.10/source/drivers/firmware/scmi/smcc... If I change ofnode_null() with ofnode_root() in the device_bind() creating the scmi-base.0 device from the SCMI UCLASS, then it goes further, c.f. https://elixir.bootlin.com/u-boot/v2024.10/source/drivers/firmware/scmi/scmi....
However, I then get another assert() being tripped later in U-Boot proper (right after the Ethernet has been initialized and before I get to the shell, no idea if it actually is related to Ethernet), which makes it reset again.
So... I basically have no clue how to go forward with this. We've started to discuss to decouple debug() log messages from assert() (meaning they don't share the same knob) but that wouldn't fix the issue. Should this assert() really be tripping? If not, how should we handle that instead?
Cheers, Quentin