<hanetzer>
hey folks. you may find this fun. I've implemented rk3288's ability to reroute uart2 to a usb port in u-boot :)
jakllsch has quit [Ping timeout: 255 seconds]
jakllsch has joined #linux-rockchip
Daaanct12 has joined #linux-rockchip
Daanct12 has quit [Ping timeout: 252 seconds]
psydroid3 has quit [Remote host closed the connection]
<robmur01>
Booting 5.19.5 on RK3399 falls over seemingly trying to run a NULL timer callback... anyone have any clues?
<hanetzer>
robmur01: fails in kernel?
lorenzb_ has joined #linux-rockchip
<lorenzb_>
I just got U-Boot on SPI to work for the Rock64 (RK3328). But when I have another copy of U-Boot on the eMMC, after the second bootrom stage it jumps into the eMMC SPL. It works fine if there is no SPL on the eMMC. Does anyone here have experience with this?
<robmur01>
hanetzer: Yes, so it's particularly awkward to debug since that's the machine I build kernels on (at home)
<hanetzer>
ah
<hanetzer>
robmur01: share kernel? I may be able to tinker it.
<hanetzer>
lorenzb_: boot prefs in your (u-boot, specifically) dtb? I seem to recall same-as-spl as being a valid option
<CounterPillow>
he just said it's 5.19.5
<hanetzer>
true, but .config and such.
<robmur01>
yup, just the regular Arch linux-aarch64 package. 5.19 RCs were fine on my dev boards for day job development, so I'm guessing it's something Rockchip-specific and/or some stable backport gone wrong
<lorenzb_>
hanetzer: Doesn't that only cover the transition from SPL to U-Boot proper? It's jumping away when coming from BROM
<lorenzb_>
hanetzer: after TPL (memory init)
<hanetzer>
lorenzb_: not sure tbh. I'm about to submit some patches to upstream u-boot
<lorenzb_>
hanetzer: One other question which might be related to this: I have the rkspi image at 0x8000, same as the legacy vendor u-boot. This boots, but I attached a logic analyzer and it first tries to read from 0x000000 and 0x001000, can the BROM boot from them?
<hanetzer>
I believe that it tries a few spots. this rk3-what?
<lorenzb_>
hanetzer: RK3328
<lorenzb_>
I have not found any documentation regarding the exact behavior of the BROM on RK3328 / RK32
<hanetzer>
ah. well, for reference, my rk3288's flash has the RK32 signature at 0x1000, and is spread out every 0x1000 thereafter
<hanetzer>
(there's a bit of data before the RK32 sig as well)
<hanetzer>
that said, I *just* dumped the bootrom on rk3288, so if you want you can poke around in that :P
<lorenzb_>
So RK3288 also has the BROM quirk with the half-full 4K blocks? I needed to disable that for my RK3328.
<hanetzer>
yeah, guess so.
<lorenzb_>
hanetzer: It works at zero image offset (signature at 0x800), nice! So one patch less.