<mmind00>
paulk-leonov: j9400 connector in the pdf doc, pins 6,8,10
DuClare has joined #linux-rockchip
warpme_ has joined #linux-rockchip
DuClare has quit [Ping timeout: 240 seconds]
nsaenz has quit [Read error: Connection reset by peer]
nsaenz has joined #linux-rockchip
DuClare has joined #linux-rockchip
DuClare has quit [Ping timeout: 276 seconds]
DuClare has joined #linux-rockchip
DuClare has quit [Ping timeout: 240 seconds]
<paulk-leonov>
mmind00: thanks a lot :)
matthias_bgg has quit [Ping timeout: 240 seconds]
<mmind00>
paulk-leonov: did it help?
<paulk-leonov>
mmind00: didn't try yet, but I'll let you know in a bit
<paulk-leonov>
but sounds quite plausible, I was indeed booting from mmc
DuClare has joined #linux-rockchip
kaspter has quit [Quit: kaspter]
matthias_bgg has joined #linux-rockchip
matthias_bgg has quit [Ping timeout: 252 seconds]
indy_ is now known as indy
<mickenx>
is there a reference guide somewhere which cru registers i need to poke for a72?
<mickenx>
searched for core b but only fo7nd one reg
<mickenx>
i tried to select gpll in it and clocked that pll
<mickenx>
with default divs
<robmur01>
take a look at u-boot's rkclk_init()
<robmur01>
even better, fix your u-boot to actually run it ;)
levd has quit [Ping timeout: 245 seconds]
<mickenx>
hmm uboot only clocks 53
<mickenx>
to somthing like 600mhz
<robmur01>
it sets both cluster PLLs to 600
<mickenx>
oh
<mickenx>
but not connecting to 72?
levd has joined #linux-rockchip
<robmur01>
As far as I'm aware both clusters are parented to the appropriate PLLs by default, it's just that those PLLs need initialising to something sane
<micken>
clksel_con2?
<micken>
k
<micken>
u-boot pokes:
tuxd3v has joined #linux-rockchip
<micken>
clksel_con0 and 1
<micken>
which is for the 53 if I can read right
<micken>
and 2 and 3 for 72
<micken>
if they work the same I could just duplicate
<micken>
yes they seem identic
return0__ has quit [Read error: Connection reset by peer]
<paulk-leonov>
mmind00: so for some reason, it only works if I press the "maskrom" button of the evb
<mmind00>
paulk-leonov: aka boot-order is spi, emmc, sdmmc ... maskrom cuts the emmc out (and there is no spi there)
<paulk-leonov>
mmind00: okay, just understood that looking at the schematics :)
<paulk-leonov>
makes sense, thanks
<micken>
interesting that usb dies
<micken>
for me
<micken>
what relation it might have with cpu change
<micken>
it dies when I probe devices in my driver
<micken>
u-boot likes it
lkcl has joined #linux-rockchip
wadim_ has quit [Quit: Leaving.]
field^Mop has quit [Ping timeout: 252 seconds]
return0e has quit [Read error: Connection reset by peer]
field^Mop has joined #linux-rockchip
return0e has joined #linux-rockchip
<paulk-leonov>
mmind00: last question for the day: do you happen to know if we can load u-boot via usb through the bootrom protocol?
<paulk-leonov>
(without touching the emmc)
<paulk-leonov>
turns out the custom px30 board I have is already using uart5 to interface a mcu
<mmind00>
paulk-leonov: interesting question ... I don't think the protocol itself changed since years ago and in the past it was possible to load the loader via maskrom mode ... but I don't really know details
<mmind00>
paulk-leonov: does you board maybe expose some other free uart?
<mmind00>
(there are 6 if I counted correctly ;-) )
field^Mop has quit [Ping timeout: 240 seconds]
<paulk-leonov>
mmind00: sadly not, it only has uart2 and 5 exposed :(
<paulk-leonov>
I'll investigate the usb boot thing then
<mmind00>
paulk-leonov: the rockchip wiki says "rkdeveloptool db rkxx_loader_vx.xx.bin" and that .bin is created from stuff in the rkbin repo https://github.com/rockchip-linux/rkbin
<mmind00>
paulk-leonov: maybe you can inject uboot parts into that
<mmind00>
paulk-leonov: hmm, but I think that depends on bootrom support, and I think after loading spl uboot depends on its own device model
drrrty has quit [Remote host closed the connection]
ldevulder has joined #linux-rockchip
ldevulder has quit [Ping timeout: 240 seconds]
<anarsoul>
flacks: there're reports on u-boot mailing list that 'memtester 3584M' can cause SError (system error) interrupt when using SPL to initialize LPDDR4
<anarsoul>
so I guess there could be issues with memory init on mainline u-boot
<anarsoul>
I'll try memtester myself tonight to see whether I get the same issue
ldevulder has joined #linux-rockchip
vicencb has joined #linux-rockchip
pcbBob has joined #linux-rockchip
vicencb has quit [Quit: Leaving.]
BenG83 has quit [Remote host closed the connection]
<robmur01_>
that's down to using the rktrust binaries
<robmur01_>
upstream u-boot doesn't carve out the secure DRAM reserved by the TEE, so Linux gets SError trying to touch it
<anarsoul>
I see
<robmur01_>
mmind00 has u-boot patches in-flight
<anarsoul>
"fdtdec: protect against another NULL phandlep in fdtdec_add_reserved_memory()" and rest of the series?
<robmur01_>
I think so - the key patch is the one that propagates OP-TEE's revervation to the kernel DT
<anarsoul>
is mainline ATF also affected?
<robmur01_>
not unless you build it with some kind of TEE (i.e. BL32), AFAIK
<anarsoul>
I'm not sure if reboot issue I'm seeing is the same since I don't get SError
<robmur01_>
the cheap hack is to just add a reserved-memory node for 0x8400000-0x9600000 directly
<anarsoul>
I can try that
<anarsoul>
any other ideas how to debug why kernel hangs on subsequent boots after reboot?
<robmur01_>
but yeah, if you're not getting SError from touching that PA range it's likely something else
<robmur01_>
how about the supposed vdd_logic issues? Is the first boot touching pwm2 at all?
<anarsoul>
I'm not sure, I guess I can add some extra prints to pwm-regulator
<anarsoul>
u-boot initializes it for sure
<stikonas>
btw, I think ocasionally I saw kernel booting on subsequent boots, although more often than not it hanged
<anarsoul>
yeah, sometimes it works
<anarsoul>
robmur01_: I doubt linux initializes it since vdd_log is not referenced anywhere
<anarsoul>
anyway that wouldn't explain why it boots fine on cold boot
<robmur01_>
on cold boot the PWM pin is hi-z so vdd_logic is set purely by voltage divider feedback (0.91V on my board)
matthias_bgg has quit [Quit: Leaving]
<anarsoul>
robmur01_: u-boot initializes it right away
<robmur01_>
hmm, fair enough - although there are a couple more patches floating about to fix the min/max and bump the init up from 0.9 to 0.95. Might be worth a go.
<anarsoul>
tried that
<anarsoul>
didn't help
<robmur01_>
:(
<anarsoul>
yeah
<robmur01_>
hopefully I'll have time this weekend to try upstream ATF and see if I get the same thing on nanopc-t4
<anarsoul>
do you have rockpro64?
<robmur01_>
nope, just nanopc
field^Mop has joined #linux-rockchip
ldevulder has quit [Quit: Leaving]
robmur01_ has quit [Remote host closed the connection]
<micken>
so cool
<micken>
running code on A53 outputing "A53" to serial in intervals , while riscos is on A72 unaffected
<micken>
I wonder if I could make it draw a anination to VOP win1 (the dsp part is setup by riscos and win 0 )
tuxd3v has quit [Remote host closed the connection]
stikonas has quit [Remote host closed the connection]
pcbBob has quit [Remote host closed the connection]
<micken>
did a small test now , just drawing to framebuffer from A53