<yann>
Does it sound familiar to anyone, that booting an upstream kernel (5.4 to 5.10) on rk3399 nanopi-m4 (using armbian defconfig and unpatched), blocks shortly after boot, with "failed to set idle on domain 'pd_vopl'" causing "Failed to enable vop" ? Full error at https://pastebin.com/n2xtfvDA
<uis>
It seems crypto engines in 3328 and 3399 are same, are they?
<macromorgan>
think the 3399 doesn't do hardware AES192
<macromorgan>
at least if it's the same as the PX30 which doesn't
kaspter has quit [Read error: Connection reset by peer]
<uis>
Hmm
<uis>
3328 ds: AES 128/192/256
<uis>
3399 trm p3: AES 128/192/256
<uis>
It do
<uis>
*does
<uis>
3288 too
<uis>
3288 crypto implemented in mainline kernel
matthias_bgg has quit [Ping timeout: 245 seconds]
<macromorgan>
I'll have to double check then, I knew there was some difference, and when I tried to bind the PX30 (which I think uses the same implementation as the RK3399) then test it in userspace it would freeze
<rtp>
yann: oh, mainline unpatched uboot or rk uboot ? I've seen that while testing stuff on my platform. always thought it was related to my patches or platform
<uis>
Difference between 3288 and 3399 cryptos: first max clk is 150m whereas second is 200m
<robmur01>
yann, rtp: looks like RPM getting out of sync to me - possibly everything's assuming the power domain is initially on but for some reason it isn't?
<DuClare>
uis: Which version is 3288 crypto implemented in?
<yann>
rtp: mainline uboot (from yocto 3.2), though the boot process is rather convoluted for my taste (fitImage loaded by uboot's "sysboot" via extlinux.conf)
tlwoerner has quit [Ping timeout: 260 seconds]
tlwoerner has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
<rtp>
yann: so, no patch applied on uboot ? (too lazy to check in git)
<yann>
rtp: none, straight from denx.org
<yann>
well, denx.de it is :)
<rtp>
robmur01: hm. possible, even if surprising. In my case, I'm booting with the edp enabled in linux and uboot so having the pm domain off is unlikely (but possible)
<robmur01>
TBH I'm somewhat suspicious of pd_vopl and pv_vopb given that there's only one physical power domain - possibly that allows the refcounting to get messed up?
<rtp>
yann: oh, cool. It doesn't help you but at least it means this bug on my platform is not a result of my local patches....
<rtp>
robmur01: are you sure that there's only 1 power domain ? I seem to remember that there was one per vop
<robmur01>
I've never seen any problems just using a single display, so trying to actually activate both VOPs at once seems a likely culprit
<yann>
at least uboot does turn the (HDMI) screen on - doesn't mean sbd messes up the pd afterwards but eh
<robmur01>
rtp the manual says it's just PD_VO, although there are separate idle/wakeup bits for each VOP's bus interface
<robmur01>
the modelling in the pm_domains driver looks correspondingly funky at a glance, but I haven't unpicked it completely
<robmur01>
if you're loading the relevant drivers as modules after init, does "pd_ignore_unused" on the command line make any difference?
<yann>
what really stumps me is that last week I did get to boot that board with a yocto build, could even play with xrandr a bit. And armbian does boot fine (that one does use a patched kernel, and I have only tried to pick select patches for now without any success -- and a slightly-patched uboot with nothing that could apparently hit a 3399 board)
<uis>
Are CLK periph clock, SCLK bus slave clock and MCLK - bus master clock?
<rtp>
robmur01: oh, you're probably right. I may be mixing power domains with idle/wakeup bits. I don't remember. Last time I've looked at the rk pd stuff, I got hard time to understand it...
<rtp>
I think I tried pd_ignore_unused but not sure.
azend has joined #linux-rockchip
<yann>
tried with pd_ignore_unused: I do see "PM: genpd: Not disabling unused power domains" and still get the same problem
<robmur01>
OK, so it's probably something more involved than just being in the wrong initial state :(
<rtp>
yes... :(
kevery1 has joined #linux-rockchip
<yann>
OK so I took that armbian kernel that properly boots on armbian, together with the matching dtb; put the matching kernel modes in rootfs (luckily no path clash), and booted that manually from uboot prompt with load's and booti : I still hit the same crash
kevery has quit [Ping timeout: 246 seconds]
kevery1 is now known as kevery
<yann>
really seems to point to uboot...
<rtp>
maybe you can try bisecting ?
<rtp>
or at least send a mail to uboot ml ?
<narmstrong>
hi guys, I'm trying to run mainline u-boot on the Rock960, and I tried from 2020.10 to master, SPL gets stuck at "Trying to boot from MMC1" when u-boot-rockchip.bin is DD'ed on an SDCard, any ideas ?
superherointj has joined #linux-rockchip
<yann>
rtp: first I'll get the yocto build to use the same uboot as armbian - there can be so many other differences in the boot step. If I understand correctly the yocto meta-rockchip layer (NOT the rockchip one on github) is not using a single binary blob for the boot. That's very commendable but adds more to be checked...
<yann>
and then compiler versions, with armbian building the kernel with gcc-8.3 and yocto with gcc-10.2, which triggers new config options to appear in the kernel case: there could be differences here (not to mention toolchain bugs, let's cross fingers)
<rtp>
before blaming the compilers, check the other things before. Chasing compiler bug is not fun
<rtp>
narmstrong: did you try using the different files (something like idbloader / uboot.bin ?) instead of u-boot-rockchip.bin ? I think I've read somewhere some people complaining about some offsets inside the file
<macromorgan>
what's your txt set to? On the PX30 I mess with the default is 0x400, but it should be 0x4000. Not sure why the default value is wrong but it is.
<macromorgan>
to my knowledge it should always be trying to load u-boot from 0x4000 for rockchip boards
<macromorgan>
(maybe it's 0x200 as default. either way it's wrong)
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 260 seconds]
kevery1 is now known as kevery
<narmstrong>
hmm, rtp u-boot-rockchip.bin is the idbloader.bin catted with u-boot.itb
<narmstrong>
the idbloader is padded up to 8355840 and the itb is catted after
<rtp>
I'm not sure what's the purpose of u-boot-rockchip.bin but I guess it's something like having one file to flash instead of several. dunno. I've always used idbloader.img and u-uboot.itb
<narmstrong>
weird, if I dd u-boot-rockchip.bin, it gets stuck on `Trying to boot from MMC1`, even if I dd u-boot.itb at 0x4000, but if I dd only idbloader.bin, I get `mmc_load_image_raw_sector: mmc block read error`on all MMCs and error...
<narmstrong>
macromorgan: looking at rk3399-u-boot.dtsi it seems to be 0x4000
<macromorgan>
dumb question, but you're skipping 64 sectors right?