14:36 <qschulz> Kwiboo: git bisect tells me one of your changes make U-Boot SPL unhappy on PX30 :(

14:36 <qschulz> https://source.denx.de/u-boot/u-boot/-/commit/1d01440b3f14f6648cd672da619489f635cb209c

14:37 <qschulz> (recursive pinctrl stuff)

14:37 <qschulz> I get "alloc space exhausted" in SPL then

14:40 <qschulz> actually... since I see BL31 starting, it's probably U-Boot proper pre-reloc?

15:57 <Kwiboo> qschulz: ohh :/, and yes it is probably u-boot proper pre-reloc, can you try to drop "# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set" and related spl stack size/addr props?

15:57 <Kwiboo> similar to https://source.denx.de/u-boot/u-boot/-/commit/32f8a88a8c931787e247019f52da4aec972f9f5a

15:58 <Kwiboo> that should hopefuly extend stack size and avoid possible overlapped addresses etc, have not looked close enough yet

16:00 <Kwiboo> px30/Kconfig may also need to be adjusted, or adding CONFIG_ROCKCHIP_COMMON_STACK_ADDR=y in defconfig

16:01 <Kwiboo> https://source.denx.de/u-boot/u-boot/-/commit/5e7cd8a119953dc2f466fea81e230d683ee03493 was the commit that moved most rk3399 boards

16:20 <qschulz> CONFIG_SPL_SHARES_INIT_SP_ADDR=y is not enough :/

16:21 <qschulz> Kwiboo: what are the "related spl stack size/addr" options you're talking about?

16:58 <Kwiboo> qschulz: looks like a quick fix could be to increse CONFIG_SYS_MALLOC_F_LEN to e.g. CONFIG_SYS_MALLOC_F_LEN=0x10000, will look closer at what options that may need to change

16:59 <Kwiboo> I was refering to the options that was dropped in the referenced commits, but looks like px30/Kconfig must be changed for it to work as intended

17:01 <Kwiboo> and TPL is using special px30 tpl.c, will look closer and possible try running u-boot on my rk3326 odroid go super

17:48 <qschulz> Kwiboo: I'm OoO til next week, so will likely not spend any time on it until then

17:48 <qschulz> but looking forward to understand a bit more of this thing because this is way too obscure to me for now :)

19:21 <helene> hello again, i'm getting a bunch of cpu hard lockups on boot with sometimes perfectly fine boots on a rk3588 board, is this a known thing for some boards/improper configurations or how should i go to debug it?

19:24 <helene> (unplugging the ethernet cable made the board boot... huh)

19:32 <helene> it still fails randomly however, so i'm guessing that just changed probabilities a bit