01:13 <sjg1> Tartarus: I would need to take a look, but it seems unlikely to me

11:21 <dormito> I'm running into some clock related issues: so I "#define DEBUG" at the top of drivers/clk/clk-uclass.c, however now my i.mxrt1170 dies on boot. Because it appears to be trying to write to the uart... (about clocking changinge) while reconfiguring the UARTs clock. obviously this won't work, but does u-boot already have any approach for resolving this sort of paradox?

11:26 <dormito> I was thinking, mabye change the debug() macro to feed debug_cond() a function call instead of the const _DEBUG... Maybe by making log.h's _DEBUG define only if it's not already defined...

11:42 <marex> dormito: is that on next ? does it happen on 2025.04 ?

11:45 <sjg1> Tartarus: It seems to work without the header and I don't immediately see any need for avoiding U-Boot's malloc() in that file

11:48 <dormito> marex: the clocking problem I am trying to debug is related to changes I made. But I'm wonder if u-boots framework has a way to both "enable a verbose debug block" and prevent it from killing the system when it would print at an inopertune time

11:48 <marex> dormito: if the UART driver did not resolve clock yet, then the UART driver is not probed at all and not used at all

11:50 <dormito> Hmmm. that's strange

11:52 <dormito> https://bpa.st/DRZQ

11:52 <dormito> that's the output where it dies

11:53 <dormito> specifically you can see it's trying to mess with 'lpuart1_sel' ... which is the very uart it's printing out of.

11:54 <dormito> my changes are currently based off: 32c9a6518dcef9b4250461e70b2c719101a305ef (which is a stupid place for them, but I think I was checking if upstream had effected my code, and forgot to go back to a saner commit base)

11:57 <marex> dormito: I did some changes to the imx clock code, they are in next and current master, so try 2025.04 and see if that unbreaks things

11:58 <dormito> oh nice. did you change imxrt1170_clk_probe ? that code block looked suspicous to me, but I'm not familiar enough with u-boots clocking to know how it should be done (though it feels like much of that function should be represented in the device tree)

11:59 <marex> dormito: maybe a bit

12:05 <dormito> hmmm. may take a while to test that. will either need to wait till I got back to where the device is located, or figure out how to inject u-boot live over a openocd/gdb session

13:23 <soxrok2212> marex: not slotted. the SPD is hardcoded afaik

15:37 <marex> soxrok2212: then maybe just write the SPD EEPROM blob content (there might be some generator for that) and extract timing parameters from the DRAM chip datasheet

15:39 <soxrok2212> im stuck creating the odt config... its ddr3 whereas the odt_config struct expects params2, which is apparently only used for ddr4

15:39 <soxrok2212> https://github.com/u-boot/u-boot/blob/5b4ae0f3f040908602c80908c3023b5454883d4a/arch/mips/mach-octeon/include/mach/octeon_ddr.h#L375C8-L383

15:42 <soxrok2212> https://github.com/disdi/u-boot-cavium/blob/master/include/configs/octeon_evb7000_sff_shared.h here's the SPD values im using, for reference

21:32 <soxrok2212> marex: so theres an option to disable dram and run u-boot in l2 cache; i tried this just to get around the ddr config for now. it starts and prints "U-Boot <version/build>" but that's it. im not very familiar with the process here/.. do you have any places where i should look to start debugging?

21:33 <soxrok2212> s/have/know

21:35 <marex> er ... how big is your L2 ?

21:36 <soxrok2212> according to one of the commits adding octeon support, 4mb

21:37 <soxrok2212> https://github.com/u-boot/u-boot/commit/5fef24c912a44a08ab644aa16ceb5a435491f9d9

21:37 <soxrok2212> its a guess... soc in this board is cn7030. that commit was 73xx

21:43 <marex> soxrok2212: ha ... common/board_{r,f}.c ... add printf("%s[%d]\n", __func__, __LINE__); ... that automatically prints function name and line number for you

21:43 <marex> spam these files and see how far it gets

21:43 <marex> also ... do you use u-boot/master for this ?

21:43 <soxrok2212> master, yep

21:50 <soxrok2212> checkcpu[883]

21:50 <soxrok2212> is where it looks stuck :)

22:47 <marex> soxrok2212: look into the function