Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
raster has joined #linux-rockchip
Stat_headcrabbed has joined #linux-rockchip
naoki has quit [Quit: naoki]
stikonas has joined #linux-rockchip
<mmind00>
Kwiboo: u-boot seems to work nicely - ethernet even ... thanks for pointing that that branch :-)
sekurin has joined #linux-rockchip
raster has quit [Quit: Gettin' stinky!]
Daanct12 has quit [Quit: WeeChat 4.7.1]
Daanct12 has joined #linux-rockchip
Daanct12 has quit [Quit: WeeChat 4.7.1]
dsimic has quit [Ping timeout: 252 seconds]
dsimic has joined #linux-rockchip
psydroid has joined #linux-rockchip
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-rockchip
psydroid2 has joined #linux-rockchip
walter has joined #linux-rockchip
<walter>
Wow, I wasn't expecting such a big crowd here. Hello, all!
<CounterPillow>
Hi!
<CounterPillow>
Do keep in mind that most people on IRC are idling, i.e. not actively talking very often. Conversation happens whenever there's a reason for it.
<walter>
I know, but still, wow. In the android-root channel there are fewer people then in here. So I'm impressed.
Stat_headcrabbed has quit [Remote host closed the connection]
<walter>
Does anyone know if there is a difference between how the proprietary flashing tool works and the opensource one (rkdeveloptool)? The opensource one hangs while downloading a bootloader onto the device, should I try and find a way to run the proprietary tools?
<clarity>
which chip?
<walter>
RK3399
<walter>
I have 2 different board types with that SoC. One of them accepts every bootloader I've prepared, the other one nothing, and I can't figure out why. I've used strace on rkdeveloptool and it seems to just time out after a while.
<CounterPillow>
by the proprietary one, do you mean also rkdeveloptool but included as a binary in rkbin, or do you mean the Windows one?
<CounterPillow>
rkdeveloptool as a binary in rkbin is afaik an older version of the open rkdeveloptool
<walter>
I mean the windows one.
<CounterPillow>
I've never used that so can't comment on that aspect, but at this point I'd check with the rkbin DDR init binary instead of u-boot's own dram init for that SoC.
<walter>
I've built rkdeveloptool myself, and also tried the one included in Fedora, and had the same results, one works on one of the devices, and not on the other board that I've broken by writing a wrong bootloader using rkdeveloptool.
<walter>
I see. The thing is, I'll have to figure out the full process of building the bootloader image, because it's not properly documented in that broken English from the wiki. Though, I've managed to build one that works on the other devices. so...
<walter>
What do you mean "check with the rkbin DDR init binary"? I've built a bootloader using the RKBOOT from rkbin, is that what you mean?
<CounterPillow>
walter: okay let me ask a more important question: when you power on your board, does it show up in `rkdeveloptool ld` is "MaskRom" or "Loader"?
<CounterPillow>
oh, built as in packed them, yeah the RKBOOT uses the rkbin ddr init, so you should be good on that front
<CounterPillow>
if the board comes up in "Loader" mode, then the problem is that you're not in maskrom mode at all, but a remnant of a possibly broken loader flashed to the board has booted. On RK3399, this means you'll have to either pull eMMC D0 or eMMC CLK to ground while powering on, or SPI flash data and SPI flash clock to ground, depending on what your board uses for storing the loader.
<walter>
`rkdeveloptool ld` shows maskrom. It used to show "loader" automatically, without me having to run `db loader.bin`, but that was before I flashed the wrong thing.
<CounterPillow>
Okay, so it is in maskrom mode, that's good at least. And just to make sure: you are checking UART2 (3.3V, 1.5mbaud) for debug output, right?
Stat_headcrabbed has joined #linux-rockchip
<CounterPillow>
during maskrom, there should be nothing there
<CounterPillow>
then, when you run `db`, you should see something on there
<CounterPillow>
if you don't see anything, something is either seriously wrong, your or USB-to-UART is misconfigured (try swapping RX and TX in that case), or your board uses different UART lines for debug output and the rkbin scripts for adjusting that in the loader binaries needs to be run (check the schematics of the board if you have them).
<walter>
I have nothing on UART2 during maskrom, but I did see stuff when I booted into maskrom in the past (which showed "loader").
<walter>
So, I used to login using UART2 into the OS, so that part should still work.
<CounterPillow>
Alright
<CounterPillow>
Another possibility is that the broken loader you flashed was in fact an attempt at enabling secure boot by blowing the efuses, in which case, it's dead unless you have that key :D
<walter>
I see.
<CounterPillow>
Is... is that what you did?
<walter>
not intentionally, no
<CounterPillow>
Okay, then probably not
<CounterPillow>
but basically, `db` with a loader binary should give you serial output even if something like DRAM training fails.
<walter>
And that's not the case if secureboot is enabled?
<CounterPillow>
As far as I know, no, secureboot will error out quite early because it's supposed to not run any untrusted code (and the uart output part is part of the loader binary's code)
<walter>
and what about rkdeveloptool, shouldn't it complain about this? Cause right now, I just get "Downloading bootloader..." and with strace I see a timeout every other minute, and nothing really happens after I see the print log.
<CounterPillow>
if you've ever looked at the rkdeveloptool code, it does not evoke a lot of trust in the tool.
<CounterPillow>
One alternative is https://github.com/collabora/rockchiprs but I assume in this case it will also fail (but probably with some timeout instead of a hang)
<walter>
No, I didn't look at it. and I've compiled it inside a docker container and I'm running it without sudo on an expandable laptop :)
<CounterPillow>
It's a case of "C++ is just C with classes, right?" last time I looked at it, but that was a few years ago admittedly.
<walter>
From my understanding, the diagram here is incomplete, right? http://opensource.rock-chips.com/wiki_Boot_option -- It should have some info about the fact that you can get into the MaskROM+loader via the emmc path.
<CounterPillow>
Do you mean that you can pull those pins to ground and drop to "firmware update via USB"? Yeah, though basically that was always just a lucky coincidence sorta, since what that does is make the maskrom code not find the eMMC/SPI to load anything from there, and the default fallback is to drop into maskrom mode waiting for usb. It was made more official starting with RK3588, where it now checks an ADC input for this behaviour.
<walter>
the board has a button that used to bring me to "maskrom+loader" directly, and I saw lots of output in UART2, so my thinking that it still used the emmc for loading the loader in maskrom.
<CounterPillow>
Yeah, that's the recovery button that tells a vendor u-boot loader from internal storage to enter rockusb loader mode
<CounterPillow>
it doesn't actually help you recover from that loader no longer being there, as that is a software function of that vendor loader, so it's not my favourite thing
<CounterPillow>
basically in that case, maskrom execution finished as normal and found an idblock on eMMC, which it then executes. This vendor loader it executes then looks at some ADC values (not to be confused with the maskrom ADC in later SoCs) to see if it should enter rockusb mode, letting you skip the `db` step but also being kinda useless if that loader is hosed
<walter>
Thanks a lot for all the info!
<CounterPillow>
Out of curiosity, if you have the schematic of the board that you have trouble with, what BGA balls does the debug UART go to? AK2 and AJ4 should be the default choice iirc
<CounterPillow>
aka GPIO4_C3 and GPIO4_C4 respectively, or UART2C_RX and UART2C_TX respectively
<walter>
I have a ton of stuff for this, but I'm missing the schematic. But I have a hunch it's what ever is in the EVB, there isn't much on this board, and the old OS tried to discover PCIe stuff, HDMI and all sort of things, my hunch is that it's using an "example" DTS. I'm now looking at this.
<CounterPillow>
Then yeah it should be those pins, so no easy answer as to why we don't see anything :(
<walter>
I have one more question, how would secureboot work with this maskrom mode? Since the bootloader is generic, right? Or can it be signed?
<CounterPillow>
it can be signed, but I've never done it myself and don't know what kind of process it uses
<CounterPillow>
but basically, the loader binary is just a stripped down vendor U-Boot SPL that jumps into rockusb mode afaik
<walter>
You are right, I'm looking at Rockchip_Developer_Guide_Linux_Secure_Boot_EN.pdf and it mentiones that the maskrom verifies the loader if the efuses for the key hash are burned.
<walter>
And... mistery solved. It's secure boot. It's good that I've kept old logs to look into. CounterPillow, thanks for the info and all the explenations. It really helped a lot to understand what's happening.
<CounterPillow>
\o/ glad I could help you get to the bottom of it
sekurin has quit [Quit: Client closed]
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]