<pnill>
Is building a bootloader that can be used from rkdevtool/rkdeveloptool possible or does it need to be signed by rockchip themselves? I was previously told it had to be signed by rockchip...
<pnill>
But in researching it I saw on the rockchip-linux git, there's bin files that make up what would be the bootloader file.
<pnill>
Trying to build one for rk3308h and rk3126c that supports NAND/SPI, no luck in finding existing ones.
System_Error has joined #linux-rockchip
jmabsd has joined #linux-rockchip
<jmabsd>
Hi all, for the Radxa Rock5B, what is the most recent URL to Debian download images? I know Radxa changed URL more times
jmabsd has quit [Ping timeout: 240 seconds]
Daanct12 has joined #linux-rockchip
hexdump0815 has quit [Ping timeout: 265 seconds]
hexdump0815 has joined #linux-rockchip
<Daanct12>
no new linux-next updates. i guess everyone is on a break
<jmabsd72>
CounterPillow: At the bottom of that Wiki page is shown the RKDevTool tool on Windows.
<jmabsd72>
Is that the tool to install the newest SPL?
<jmabsd72>
Is there some other better simpler clearer documentation page than this one
<jmabsd72>
Aha so the steps are as shown on this screenshot https://wiki.radxa.com/mw/images/c/c8/Eraseall_new.png : click the "Advanced function" tab, specify the filename of the SPL loader file, click "Download", click "Erase all" and click "Reset device"?
jmabsd has quit [Ping timeout: 240 seconds]
pnill has quit [Ping timeout: 276 seconds]
<CounterPillow>
I'm not familiar with the precise ins and outs of the downstream tooling and binaries, as I only use mainline stuff. "SPL" can mean both a stage of u-boot (so it would be part of your SPI flash's u-boot) or it can also refer to the u-boot that gets loaded over USB into memory temporarily just to actually do any other operations on the board while flashing.
<jmabsd72>
Hm ok
pnill has joined #linux-rockchip
<jmabsd72>
CounterPillow: Do you have any best guess
<jmabsd72>
I would guess because the WIKI page does describe separately how to install the SPL via USB, then, wlel,
<jmabsd72>
wel
<jmabsd72>
well
<jmabsd72>
Could it be that the SPI overrides the SPL???
<CounterPillow>
it doesn't get "installed"
<jmabsd72>
Or is there a boot sequence that SPL runs first and then SPI
<CounterPillow>
the SPL is just memory-resident, it's gone after a reboot.
<jmabsd72>
Perhaps their SPL installation instructions are some kind of failover for cases where you don't have any SPI ?????
<CounterPillow>
it's a temporary in-memory piece of code to make the board able to write to SPI.
<jmabsd72>
CounterPillow: Well it's "installed" in the sense that it resides on some flash memory
<jmabsd72>
(or NVMe disk)
<CounterPillow>
no it's not flash memory
<CounterPillow>
it's not in non-volatile memory
<CounterPillow>
it's in RAM
<jmabsd72>
Where is it then
<jmabsd72>
EEPROM?
<jmabsd72>
well, it reaches RAM from where - the Rock5B/RK3588 can be totally powered off so the RAM is off then
<CounterPillow>
RAM.
<CounterPillow>
It's just for that one flash operation
<CounterPillow>
it does not stay around
<jmabsd72>
Which is the 'flash operation'? Does it take place on each boot?
<CounterPillow>
No
<CounterPillow>
the "flash operation" is installing the bootloader to SPI
<jmabsd72>
CounterPillow: After you installed the SPI via MaskRom USB using RKDevTool GUI, where does it go?
<jmabsd72>
What is its function - so it's not stored somewhere and used in the RK3588/Rock5B's boot sequence??
<CounterPillow>
your SPI bootloader goes onto the SPI flash. It's called that because the flash is connected to the SPI bus
<pnill>
jmabsd72, SPL inits ram, bootloader is copied into ram, MASKROM jumps to that.
<pnill>
or SPL does
<pnill>
But it never lives on the storage
<pnill>
if you're using rkdevtool/rkdeveloptool whatever that is to "boot" it
<CounterPillow>
the SoC on power on looks on either the SD, eMMC or SPI flash for a suitable bootloader. If none is found or the maskrom button is held, it enters USB maskrom mode, where it awaits being given a bootloader over USB.
<pnill>
Can anyone clarify on whether or not the bootloaders delivered over rockusb while in maskrom are signed or can be packaged/what binary tool does it?
<CounterPillow>
they're not signed
<CounterPillow>
the tool that packages them is in the rkbin repo
<pnill>
Yeah, I just don't know which one it is it's not the one with "loader" in the name from the last test I did, that one takes in uboot as a param but I think it makes the 'loader' that goes into the uboot partition.
<CounterPillow>
it's tools/boot_merger I think? I might be misremembering though
<pnill>
I'll check that one out thanks.
<pnill>
My attempts at getting chatgpt to do my research for me on that one has just been met with it hallucinating like everything else I ask it to do.
<CounterPillow>
the RK3588MINIALL.ini will contain the baths to the different parts of the loader, e.g. TPL etc
jmabsd72 has quit [Ping timeout: 240 seconds]
Daanct12 has quit [Quit: WeeChat 4.6.1]
Daanct12 has joined #linux-rockchip
<pnill>
Yeah, I usually rely on pre-compiled (packaged/merged?) ones but I ran into boards where I wasn't able to find compatible ones that were built by others (RK3216c and RK3308h)
<pnill>
The rk3216c there's one out there but any attempts to read data resulted in garbage.. almost as if the storage was encrypted as the garbage was 1:1 each read.
<pnill>
Basically just trying to get a backup of what's there before trying to get some form of a basic mainline kernel booting on em
<pnill>
The rk3308h I screwed up and overwrote the uboot on it and got stuck in maskrom
<CounterPillow>
for dumping all the vendor stuff on eMMC for later I've used rockusb (from <https://github.com/collabora/rockchiprs/tree/main/rockusb>) with its nbd mode before, that way I could just do a block copy from the nbd device to a file.
<pnill>
This one is a NAND, but you still gotta get to loader for rockusb too right? can't do that from maskrom
<CounterPillow>
Yeah, still needs a loader
<pnill>
I can't read rust dammit... I wanted to read through that.
<pnill>
Rust confuses the hell out of me the way it's written.
<CounterPillow>
oh the documentation is real bad, basically it's a command line tool when you install it with `cargo install rockusb --example rockusb --features=libusb`
jmabsd has joined #linux-rockchip
<jmabsd>
pnill,CounterPillow: Are you saying the SPL is only relevant as a bootstrap measure in MaskRom mode???
<CounterPillow>
in the way Rockchip uses the term "SPL" here, yes.
<jmabsd>
So when you do a normal boot of the system, there is never any SPL whatsoever involved. all is SPI
<jmabsd>
As CounterPillow pointed out: > the SoC on power on looks on either the SD, eMMC or SPI flash for a suitable bootloader. I
<jmabsd>
The ROM in the RK3588 will walk SD, eMMC, SPI
<jmabsd>
They say hey mate you know what, the SPL is at version 1.15 now. If you didn't flash it into your system you're missing out.
<pnill>
Most of these devices do the same crap other brands or this, there's a first stage that inits storage (main bootloader baked into SoC) and searches for a next stage...
<CounterPillow>
There's no such thing as an "SPI version number", what you flash to SPI is u-boot.
<pnill>
the next stage is intended to properly init storage, ram, and etc... then jump to uboot or kernel
<jmabsd>
But, in actuality, you go to the directory of that SPL file and there's an SPI file - and *that's* what you flash, and you do so according to the instructions at the SPI wikipedia page
<pnill>
usually uboot->kernel
<jmabsd>
SPI is just the name of the flash chip for boot flash, and the SPI contains u-boot?
<pnill>
in a general sense not the radxa board I mean
<jmabsd>
yepyep. in the case of Rock5B, the SPI is empty when you buy it - they tell you to flash the SPI chip with the "spi-image.bin" to get NVMe boot support.
<jmabsd>
So SPL is the boot code, which is transient, when the RK3588 boots in MaskRom mode - got it.
<pnill>
What exactly are you trying to figure out here?
<jmabsd>
pnill: right but that one will accept additional boot code via USB, and that would be where the SPL comes into the picture?
<jmabsd>
pnill: just why they wrote the SPL version on the download page
<jmabsd>
Oooh I see they show SPI above SPL, but the formatting is broken
<jmabsd>
"Summary of resource downloads
<jmabsd>
System Image
<jmabsd>
Official Image
<jmabsd>
SPI Image: spi_image.img
<jmabsd>
Linux：
<jmabsd>
Loader： RK3588_SPL_Loader_v1.15.113.bin
<jmabsd>
ROCK 5B Debian (kernel 5.10): rock-5b_debian_bullseye_kde_b39"
<jmabsd>
Truly confusing
<pnill>
In the case of what you're looking at, on their wiki they state the maskrom is unable to boot from nvme, USB etc.
<pnill>
So the reason they use the SPI is so the maskrom has storage it can find the SPL on and use that to init the others
<jmabsd>
yepyep icic.
<pnill>
If the SPL was stored on nvme/usb3 mask rom can't init/search there, but SPI, NOR, Emmc, NAND what have you it could and the SPI wouldn't be necessary
<jmabsd>
this is a pure expert usecase, it's not anyone's normal boot process
<pnill>
The maskrom/bootloader usually 'brute-forces' the initialization from my understanding (at least on allwinner)
<pnill>
Because it doesn't have the necessary parameters to properly init the storage, which is why the SPL needs to re-init it
<pnill>
even if it's a 'supported' media
<pnill>
Versioning likely came from rockchip, and there are change logs of those bins that go into the SPL
<pnill>
Like bug fixes or whatever, maybe it inited ram wrong but it was only causing problems for some applications or etc.
<jmabsd>
Cool OK. Please feel free to copy anything you said into that Radxa forum thread, so others can get it too
<jmabsd>
I know how to use Linux generally. These "this binary image or that" was a bit more under the hood ARM/Rockchip specific matter than i had a clue of yet
raster has joined #linux-rockchip
Jmabsd59 has joined #linux-rockchip
<Jmabsd59>
Hi, how do you quickly boot the Rock5B (RK3588) off microSD or USB