lanefu changed the topic of #armbian-rockchip to: Armbian - Linux for ARM development boards | Rockchip SoC | www.armbian.com | This channel is relayed to the equivalent Discord channel | this channel is logged
<DC-IRC>
[Discord] <amazingfate> Here is a patch to devocetree of vendor uboot fixing a npu power domain issue of npu: https://github.com/radxa/u-boot/pull/19
<DC-IRC>
[Discord] <amazingfate> I don't know if property `u-boot,dm-pre-reloc` also works with mainline uboot.
<DC-IRC>
[Discord] <kwiboo> Hum, that sound like a strange fix, and that prop only tell u-boot to treat that dt node valid during pre-relocation phase, after that phase all drivers are re-probed and all dt nodes is valid, so any affect by props in that node should have been auto-corrected a few ms later
<DC-IRC>
[Discord] <kwiboo> bootph-some-ram is the new name for that prop
<DC-IRC>
[Discord] <kwiboo> Also v2024.07-rc5 added a fix related to suspend for rk8xx
<DC-IRC>
[Discord] <kwiboo> Ahh, vdd_npu supply the npu power domain and must be enabled for power domain contoller to work, will add always-on to that supply for mainline opi3b u-boot series
<DC-IRC>
[Discord] <amazingfate> I just created a pr using vendor uboot for vendor kernel. But if always-on fixes mainline uboot with vendor kernel, I will revert the vendor uboot commit.
<DC-IRC>
[Discord] <kwiboo> Great, will look over pending u-boot mainline board additions series and add similar override
<DC-IRC>
[Discord] <kwiboo> For mainline linux a domain-supply should probably be added to power domains, should be a better description of hw
<DC-IRC>
[Discord] <amazingfate> I'm going to double check with a clean image.
<DC-IRC>
[Discord] <amazingfate> @kwiboo After poweroff the board and plug in power I can still get `fdd90000.power-management:power-controller: failed to get ack on domain 'npu', target_idle = 0, target_ack = 0,
<DC-IRC>
[Discord] <amazingfate> val=0x1ee`. That always-on patch did not fix the issue. I did a warm reboot from without last time and there is no kernel panic, but a cold boot from mainline uboot still has the issue.
<DC-IRC>
[Discord] <kwiboo> Interesting, will try to build the vendor kernel an take a closer look little bit later
<DC-IRC>
[Discord] <kwiboo> Adding following to the `rk3566-orangepi-3b-u-boot.dtsi` should probably fix it, seemed to not crash for my quick test:```&vdd_npu {
<DC-IRC>
[Discord] <kwiboo> default voltage is 0.5 and that is to low, opp table show 0.85 as lowest
<DC-IRC>
[Discord] <kwiboo> Also to quickly test in u-boot you can run `regulator dev vdd_npu; regulator enable; regulator value 850000;` in u-boot cli before running `boot` to validate
<DC-IRC>
[Discord] <amazingfate> thanks, I will check it
<DC-IRC>
[Discord] <amazingfate> I build a vendor image with this uboot patch for opi3b and there is still kernel panic with npu. Here is build log: https://paste.armbian.com/ajidavotav I'm using uboot branch rk3xxx-2024.04.
katerX_ has joined #armbian-rockchip
katerX has quit [*.net *.split]
Ark74 has quit [*.net *.split]
Ark74 has joined #armbian-rockchip
<DC-IRC>
[Discord] <xmort> Does anyone know how I can get a NanoPi R6C (rk3588) to _reliably_ boot from SD card?
<DC-IRC>
[Discord] <xmort> It seems like uboot (either on the SD card or the eMMC, not sure) finds the armbianEnv.txt on the eMMC and loads that
<DC-IRC>
[Discord] <xmort> Which means that if I ever have, say, an armbianEnv.txt on the eMMC which loads a broken devicetree overlay, the device is seemingly bricked
<DC-IRC>
[Discord] <monkablyat> don't know this device hower it should have a maskrom button so put in maskrom mode and erase emmc with rkdevtool then it should boot again from sd card
<DC-IRC>
[Discord] <monkablyat> don't know this device hower it should have a maskrom button so put it in maskrom mode and erase emmc with rkdevtool then it should boot again from sd card