<qschulz>
I am not sure they store the Rockchip version anywhere in the binary blob
<qschulz>
they do for the DDR init blob, not sure for BL31
<qschulz>
you can simply run `strings` on the v1.47 and check if the number after v2.3- is higher than 589
<montjoie>
let see what will do the revert-cutdown, I re-enabled sound/video
warpme has joined #linux-rockchip
ldevulder has quit [Remote host closed the connection]
ldevulder has joined #linux-rockchip
<qschulz>
sre: I have the following message on next-20250319:
<qschulz>
rockchip-pm-domain fd8d8000.power-management:power-controller: Failed to create device link (0x180) with supplier spi2.0 for /power-management@fd8d8000/power-controller/power-domain@12
<qschulz>
it seems like there are some commits attempting to fix similar issues with other drivers, c.f. 74ffe43bad3af3e2a786ca017c205555ba87ebad
<qschulz>
I assume spi2.0 is the internal name for the pmic (CS0 on SPI2)
<qschulz>
on RK3588 Tiger, forgot to mention it
Daanct12 has quit [Ping timeout: 244 seconds]
Daanct12 has joined #linux-rockchip
<montjoie>
ok it is kernel size related
<montjoie>
removed some useless pltform, or just wireless give the same result
<qschulz>
montjoie: check your load addresses in U-Boot
<qschulz>
maybe do a checksum after loading it from the storage as well
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<montjoie>
qschulz: checked, no possible overwrite
<qschulz>
montjoie: also doesn't overwrite the FDT?
<montjoie>
yes
<qschulz>
not sure if/how we handled memory holes on RK3588 in that very old U-Boot
<qschulz>
not adding the reserved nodes and telling the kernel everything is fine
<montjoie>
and why it fail only at userspace and not while booting ? strange
<qschulz>
the kernel typically uses the top GB in DRAM or something like that
<qschulz>
and we know there aren't holes in there aside from TF-A (first 2MiB)
<qschulz>
or OP-TEE maybe
warpme has joined #linux-rockchip
<qschulz>
but userspace would try to use anything else, at any location
<qschulz>
random thoughts, nothing to prove that though
<montjoie>
I try to change load address then upgrade uboot just in case
<qschulz>
as to why it is size related, not sure it actually is, could simply be that random addresses allocated by the kernel for userspace are not reproducible (as they should with ASAN or whatever), then it's just "luck"
<qschulz>
maybe if you use the stripped down kernel that doesn't seem to be crashing and load it with IO/allocations in userspace, it may still crash eventually?
<qschulz>
0xa100000 - 0x0400000 is 157MiB, so not impossible to reach with a full kernel with most drivers built in
<montjoie>
let see if it boots with 0x0300000
<qschulz>
just check the size of the binary you're loading :D
<qschulz>
(could be also relocated, especially if compressed, but I know too little there)
<montjoie>
checked it was 32619008 (1f1ba00 hex)
<montjoie>
so far from 0xa100000
<qschulz>
maybe try a recent U-Boot with a recent BL31 (upstream TF-A even :) ) to see if you can reproduce?
<qschulz>
we have changed some addresses though, so probably not an easy conclusion if it works on recent U-Boot
<qschulz>
(but maybe we don't care if it works on a recent U-Boot :) )
<montjoie>
yeah uboot upgrade is planned, I upgrade all uboot in lava lab
<montjoie>
no more 201x-vendor-shit
<qschulz>
2023.10 isn't a vendor (at least not from Rockchip :) ) U-Boot
<montjoie>
for this one, yes it is alreacy quite recent
<qschulz>
Rockchip is stuck on 2017.09 AFAIR
<montjoie>
no change with 0x0300000
raster has joined #linux-rockchip
darfo_ has joined #linux-rockchip
darfo has quit [Ping timeout: 252 seconds]
<Daanct12>
can you boot downstream kernel with mainline uboot?
<Daanct12>
at least on the rk3588
darfo_ has quit [Ping timeout: 252 seconds]
<qschulz>
we do
<qschulz>
what would be the issue?
darfo has joined #linux-rockchip
<sre>
naoki: yes, I have one of those now and plan to send a series to add support in the next few days after doing more testing to verify everything works as expected and avoid any regressions
<sre>
qschulz: That message is due to the GPU supply regulator. The device link framework sees a circular dependency between the PMIC (which requires SPI, which requires power domains) and the power domain controller.
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sre>
This message is totally correct of course (there is a circular dependency). That's why the regulator is only resolved once the domain is actually being enabled.
<qschulz>
sre: scary message is scary though
<sre>
The message itself is harmless, though. The device link framework basically gives up trying to optimize the probe order and relies on -EPROBE_DEFER once it happens.
<sre>
Ideally I would like to get rid of it, but it's not trivial.
<qschulz>
if I understood mmind00 properly (in private), we have this because the PMIC checks for the devices using its regulators but find that the PM domain is already probed, and thus give up with that error message?
<sre>
No. Nowadays we have the device link framework, which tries to reorder the driver probe order based on links described in DT to avoid -EPROBE_DEFER as much as possible.
<sre>
Which obviously runs into problems if there is a cycle - i.e. device A needs device B and device B needs device A.
<sre>
To probe the PMIC driver we need SPI and for SPI we need power domains. But the power domain references a regulator from the PMIC.
<mmind00>
sre: essentially device-link saying, this is a state-tracking device-link, but the thing I'm waiting to probe, has already probed, so nothing to do ;-)
<mmind00>
sre: which is of course coming from the same cycling thing of course :)
<mmind00>
sre: but as you said, the message is harmless, though scary
Daanct12 has quit [Quit: WeeChat 4.5.2]
warpme has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ldevulder has quit [Remote host closed the connection]
ldevulder has joined #linux-rockchip
darfo has quit [Ping timeout: 252 seconds]
darfo has joined #linux-rockchip
warpme has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ungeskriptet has quit [Remote host closed the connection]
chewitt has quit [Quit: Zzz..]
ungeskriptet has joined #linux-rockchip
raster has quit [Quit: Gettin' stinky!]
<CounterPillow>
harmless though scary sounds like a reason to either reword the message or change its loglevel, but that's for the driver core people to decide. I don't think anything else needs changing or is worth the time investment to change here, the thing it's doing right now is arguably already the best solution to the situation it's encountering.
ldevulder has quit [Ping timeout: 252 seconds]
<montjoie>
normal to not have ethernet on rock5b ?
<linkmauve>
It works fine on mine, which kernel are you using?
<montjoie>
6.13.7
<linkmauve>
With the standard arm64 defconfig?
<linkmauve>
Do you have errors in dmesg?
<montjoie>
It worked on 6.10.14
<linkmauve>
If this seems like a regression to you maybe bisect?
<linkmauve>
Or try mainline to check whether it’s already been fixed.
<sre>
I'm not aware of any regression in 6.13.
<sre>
Apart from checking for errors in dmesg I suggest checking lspci as the Rock 5B uses a PCIe based network card.
<montjoie>
it seems pcie is probed at 19s instead of 2s
<montjoie>
sorry it is not that, but pcie do not came
<montjoie>
this message is not in 6.10.14 where gmac is ok
<sre>
check if you have CONFIG_REGULATOR_FIXED_VOLTAGE in your kernel config.
<montjoie>
it have, retryed 6.10.14, no eth, perhaps a timing issue, I add some sleep to wait for ethernet
<montjoie>
no change
ldevulder has joined #linux-rockchip
<montjoie>
perhaps the problem is removing all CONFIG_DRM..., this is the only removal
<montjoie>
lol this is it
montjoie has quit [Ping timeout: 248 seconds]
montjoie has joined #linux-rockchip
ldevulder has quit [Ping timeout: 248 seconds]
<montjoie>
really fun, not having DRM break ethernet
ldevulder has joined #linux-rockchip
<montjoie>
ouch, mainline uboot of rock5b, do not have ethernet....
<montjoie>
what is this shitty platform
<CounterPillow>
? works for me
<CounterPillow>
you need to start pcie first
<CounterPillow>
only then does it show up to u-boot
<CounterPillow>
`pci start && pci enum && dhcp && wget 0x0a000000 http://192.168.0.115:8000/rock5.itb && bootm 0x0a000000` is how I automatically boot kernels over HTTP on my ROCK5B, with mainline u-boot. So I am 100% certain that mainline uboot has ethernet on rock5b
<montjoie>
according to config it have
<montjoie>
ok pci enum did the trick thanks
<montjoie>
healcheck passed, now retry full v6.13.7
<montjoie>
still fail
stikonas has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]