nsaenz has quit [Read error: Connection reset by peer]
nsaenz has joined #linux-rockchip
nsaenz has quit [Read error: Connection reset by peer]
nsaenz has joined #linux-rockchip
nsaenz has quit [Read error: Connection reset by peer]
indy has quit [Ping timeout: 240 seconds]
jaganteki has joined #linux-rockchip
imsherlock has joined #linux-rockchip
matthias_bgg has quit [Quit: Leaving]
<imsherlock>
hi all! I'm attempting to use the U-Boot TPL/SPL for loading the Linux 5.4 kernel on the Rockchip RK3399 SoC, but I'm running into issues booting the kernel
indy has joined #linux-rockchip
<imsherlock>
I've traced down through print statements all the way to armv8_switch_to_el2_m, right before the exception return (eret)
<imsherlock>
if I use the Rockchip DDR binary + SPL the kernel boots
<imsherlock>
and if I use the Rockchip idbloader.img + U-Boot.img, the kernel boots
<imsherlock>
but using TPL+SPL doesn't seem to work
<imsherlock>
any ideas as to why the combination of TPL+SPL would prevent the board from booting?
<jaganteki>
where exactly it hang?
<imsherlock>
right after the exception return in armv8_switch_to_el2_m
<imsherlock>
so it's attempting to jump into the kernel, but nothing happens
<jaganteki>
board config?
<anarsoul>
imsherlock: works for me. Check whether you have CPU regulators enabled
vicencb has joined #linux-rockchip
<robmur01>
yeah, which board (and thus which particular kind of RAM) is probably most critical
<anarsoul>
lpddr4 works :)
<jaganteki>
and also better use latest ATF from mainline, if you didn't use it before.
<anarsoul>
I think TPL+SPL just won't work with rockchip's ATF
<robmur01>
hang on a minute, let me go back and question the premise that "idbloader.img" and "TPL+SPL" are different things... :/
<imsherlock>
yeah, so let me provide some clarification
<imsherlock>
the board is 9tripods X3399 SoM
<imsherlock>
the RAM is LPDDR4
<imsherlock>
using ATF mainline
<imsherlock>
using U-Boot tag v2019.10
<imsherlock>
anarsoul: which board are you using? How would the CPU regulators change or be affected by using TPL versus the Rockchip DDR binary?
<anarsoul>
rockpro64
<anarsoul>
imsherlock: IIRC rockchip's SPL sets lower frequency for both CPU clusters
<anarsoul>
I mean rockchip's blob
<anarsoul>
so if you don't have regulators enabled in linux you have better chances to boot
<anarsoul>
I mean regulator drivers
<imsherlock>
robmur01: isn't the idbloader.img just some combination of images to produce a tertiary and secondary loader?
<imsherlock>
so you are saying to disable the regulator drivers in Linux?
<anarsoul>
no
<anarsoul>
I'm saying to check whether they're enabled
<robmur01>
AIUI idbloader contains the TPL and SPL, which then expect to load ATF and U-Boot main stage from u-boot.itb
<robmur01>
anarsoul: the RK miniloader doesn't touch CPU clocks - the downstream flow does that in the main EL2 stage
<anarsoul>
oh, OK
<robmur01>
that's how you end up booting at 12MHz if you *don't* use SPL ;)
stikonas has joined #linux-rockchip
<anarsoul>
mmm, 12mhz
<imsherlock>
anarsoul: do I need to have the regulators enabled in SPL?
<anarsoul>
imsherlock: no, and likely they're not here
<robmur01>
so what exactly do you flash where for the "TPL+SPL" config
<imsherlock>
i'm flashing TPL+SPL to 0x40, the u-boot.itb to 0x4000 and the Linux kernel to 0x8000
<robmur01>
I'm starting to wonder if it's just not finding the U-Boot main stage correctly
<robmur01>
(but I should probably go look at source code before making any more guesses)
<imsherlock>
well, wouldn't it have already executed the u-boot main stage if it's reached armv8_switch_to_el2_m
<imsherlock>
anarsoul: regulators are disabled in u-boot, and enabled in Linux. Should I just disable the regulator driver altogether? or something specific in the device tree?
<anarsoul>
imsherlock: no, I don't understand why you're asking about disabling regulator drivers
<robmur01>
but the main stage should run at EL2 - I was guessing that that's the jump out of the SPL
<anarsoul>
you need regulator drivers to set correct voltage
<anarsoul>
you'll get weird freezes if you attempt to raise CPU frequency without raising voltage
<imsherlock>
I think I misunderstood the original comment, but then yes, the regulator drivers are there and the voltages are being. The kernel does boot, just not when I use the TPL+SPL
<anarsoul>
are you using mainline ATF?
<robmur01>
oh, and FWIW beware writing directly to emmc/sd with dd vs. flashing over usb with rkdeveloptool or similar, since the latter skews your offsets
<imsherlock>
anarsoul: yes, using mainline ATF
<anarsoul>
OK
<imsherlock>
robmur01: skews my offsets how?
<robmur01>
IIRC at least one of the tools treats addresses to the "write" command as offsets from 0x2000 (hence you can't address the miniloader/SPL/TPL region and need the magic other command to update that)
<mraynal>
mmind00: Hello, I'm trying to make LVDS work (still on PX30). Do you also need the BSP "video_phy" for DSI?
<mraynal>
I wonder if you already worked on it?
<mmind00>
mraynal: yes on both :-D
<mmind00>
aka the dsi-phy also does lvds and that is partially in 5.5-rc1 with a some series' still pending
<mraynal>
is dsi-phy and video_phy the same ?
<mmind00>
mraynal: I think so ... if it's the phy that gets linked from the dsi host
<mraynal>
let me check
<mmind00>
but yeah, the dsi phy provides a lvds mode, so I'm pretty sure :-)
<mraynal>
you're right!
<mraynal>
Ok great, so this is very likely a missing peace
<mmind00>
mraynal: I can look up the patches that are still sitting on the lists, 1sec
<mraynal>
mmind00: great! I'll be able to test with LVDS then (if not already done by someone else)
<mmind00>
mraynal: caveat, I did only look at the dsi part, so you'll need to hook up the lvds parts yourself ;-)
<imsherlock>
robmur01: do you happen to know what that magic command might be?
<mraynal>
mmind00: oh crap I felt so happy during ten seconds :)
<mraynal>
mmind00: I'll fill the blanks
<mmind00>
mraynal: hehe ... in any case my current patches regarding dsi (phy and general dsi) are:
<mmind00>
so I guess you will only need to look at the first one, if you're only interested in lvds
<mraynal>
Indeed
<mraynal>
thank you very much, I'll build on top of it
<robmur01>
imsherlock: I think it was "ul" with the old binary upgrade_tool (where the image may have had to be packed in some magic format as well) - http://opensource.rock-chips.com/wiki_Boot_option implies that rkdeveloptool might actually be more reasonable
<mmind00>
mraynal: very cool :-)
nsaenz has joined #linux-rockchip
nsaenz has quit [Remote host closed the connection]
<imsherlock>
meh, no luck robmur01, rkdeveloptool didn't seem to change much
<robmur01>
hmm, well I'm all out of ideas :(
<imsherlock>
I think you might be on to something, but I'll continue looking into it and see what I find
<robmur01>
other than the SPL refusing to load the main stage from eMMC such that I had to move U-Boot to an SD card, I had no problems
<robmur01>
(and I've yet to try anarsoul's 25MHz eMMC hack)
nsaenz has joined #linux-rockchip
nsaenz has quit [Remote host closed the connection]
<imsherlock>
so the U-Boot mainstage loads
<imsherlock>
it's the Linux kernel that doesn't
<imsherlock>
one of the differences I see is where the device tree is loaded, although this could be just the difference in memory allocation
nashpa has quit [Ping timeout: 268 seconds]
nsaenz has joined #linux-rockchip
nsaenz has quit [Client Quit]
nashpa has joined #linux-rockchip
jaganteki has quit [Remote host closed the connection]