Not sure if this counts as an SBC: Firefly ITX-3588J (Rockchip RK3588) - how far can we go with it?

I have recently gotten this rather nice, spiffy Chinese borderline PC-sized board with a Rockchip RK3588 ARM SoC from Firefly (www.t-firefly.com, also "Zhongshan Tianqi Intelligent Technology Corp."). This apparently is a newfangled board that was just released earlier this year. The company offers a stock Ubuntu 20.04 and Android 12 as operating system images, as well as a software development kit available on request by the buyer. Both OS images load to the embedded MultiMediaCard (MMC) chip, however the board also features 4 SATA ports on it, and I've added a 250 GB SSD to mine.

What I am interested in is the possibility for loading other versions of Linux and/or alternative boot arrangements - particularly, it'd be great to get a system image loaded to the hard drive and/or have a dual-boot between Android and Linux. Yet after quite a fair bit of digging, I am both finding a significant paucity of information and moreover some indications that the obstacles toward this may be great, and thus am wondering what your thoughts are on the matter:

1. First off, the board does not boot in the usual way an x86 type machine would. It uses a special boot loader called "U-Boot", which seems to be common for embedded low power boards (hence why I am posting this here because this and the SoC design of the core unit make it have affinity with that space, but it also has so many other features that I feel it's on a weird borderline). This boot loader requires serial debug access and is very technical to use. I've looked at a variety of documentation about it, but haven't had any luck booting the an Ubuntu ARM image from their website (https://cdimage.ubuntu.com/jammy/daily-live/current/, it's the jammy-desktop-arm64.iso image). In particular, that image seems to contain EFI files and doesn't appear to have an "obvious" way to induce U-Boot to boot it. I suspect though this is a lack of knowledge problem on my part, but I have no idea where to start.

2. Perhaps more seriously, though, is that I've been reading some suggestions that due to the fragmentary state of the ARM ecosystem, loading a new kernel at least, other than the stock kernel (a 5.10) they supply you with, might not work and/or it will require substantial further development in the mainline Linux kernels to support the board(*). That said, I've also heard other, earlier (and smaller) Rockchip boards seem to have support here. That said, given that, I'd still be happy for the time being with somehow getting a hard drive dual-boot arrangement between the earlier Ubuntu 20.04 and Android 12, if loading the latest Ubuntu kernels are not possible because of this - perhaps stripping out the stock kernel and transplanting it into a hard drive-installable Ubuntu image somehow might work?

Up to this point, the only ARM devices I've used to date have been smartphones with Android, and I found this board when looking for a decently-powerful but still affordable x86 alternative for a lightweight desktop system - I'd thought about RISC-V, but felt it was not yet strong enough due to its youth and wanted to give it longer. So I am quite inexperienced in this domain.

Is what I'm seeking to do even possible at all? What should I look at with regards to doing it (esp. the Ubuntu 20.04/kernel 5.10 _with Android 12 dual-boot_ option if kernel upgrades are not possible)?

---

(*) Might want to suggest any prospective developers to take note of what I said earlier - the vendor provides an SDK free of charge containing the Linux kernel source code, and based on my cursory investigation at least some RK3588-specific stuff is there and under GPL, so it's not necessarily just an opaque "blob".

use a serial console to connect, and you can hit a key during the first three seconds, and it will take you to the u-boot console prompt; there, after some study, you can modify boot parameters.

I've already done that. The trick is that I don't know how or even if it's possible for this U-Boot to load the Ubuntu installation disc image - for one thing the vmlinuz file with it appears to be an MZ executable and thus a UEFI image, but this u-boot has no bootefi command.

Not everybody follows manufacturers recommendations to the tee... for example, slackware-arm will use mbr partition table instead of gpt...

I don't know firefly's exact setup, however, without damaging that setup at all, you can get your own microsd card for the mmc drive, and build your custom dual boot image, burn it to the mmc, insert and test.

But rockchip wiki recommends GPT layout and has example partition table.

this layout has u-boot starting at sector 16384... so you can dd a u-boot image to start there with seek=16384 at end of dd command. There's some examples for firefly boards here... probably just have to update the exmples for rk3588.

I haven't tried to dual boot with an android kernel, and was considering running android in virtual machine...

If you have /boot/extlinux/extlinux.conf, this file will let you configure alternatives as well... you can also customize kernel append line there.

Originally Posted by slac-in-the-box Not everybody follows manufacturers recommendations to the tee... for example, slackware-arm will use mbr partition table instead of gpt... I don't know firefly's exact setup, however, without damaging that setup at all, you can get your own microsd card for the mmc drive, and build your custom dual boot image, burn it to the mmc, insert and test. But rockchip wiki recommends GPT layout and has example partition table. this layout has u-boot starting at sector 16384... so you can dd a u-boot image to start there with seek=16384 at end of dd command. There's some examples for firefly boards here... probably just have to update the exmples for rk3588. I haven't tried to dual boot with an android kernel, and was considering running android in virtual machine... If you have /boot/extlinux/extlinux.conf, this file will let you configure alternatives as well... you can also customize kernel append line there.

Thanks regarding the addressing. I found a lot about the RK3568, but not about the RK3588 because it's so new. I did try actually and recompile the U-Boot from the SDK with bootefi support but upon loading the "u-boot.img" file to the flash at what I thought was the boot partition the system failed to boot. It hung at "Starting U-Boot at 0x00200000" or something similar to that, though that last address number may not be exact but it definitely had only 0s with a single 2. Had to reflash the MMC again with the Linux image after that.

VM might be an interesting option for running Android, but doesn't that incur a significant emulation penalty? Or is it possible to have it run the Android code directly on the processor as much as possible given that it is an ARM system? I don't need Android for a lot but I definitely want it for ZOOM as I need that for comms/meetings, which doesn't have an arm64/AArch64 version for Linux (unless there's a libre alternative to the client that is 100% compatible with senders). And ZOOM, of course, needs to run without noticeable lag. What Linux software could boot an Android in a VM while maximizing performance (say not worse than 80% of fully native speed which, given that this board already has at least that much of an edge on my older x86 box which runs Zoom just fine, should be plenty enough)?

According to this

The ARMv8-A architecture permits virtualization using either AArch32 or AArch64 execution states.

I think that means that on armv8-a and later, qemu can run 32-bit android sufficiently for gaming and zoom... not as fast as bare-metal hypervisor... but still sufficiently fast.

I just tried copying my newly-built u-boot to the flash - here taking u-boot.img and dding it to the partition where the original resided - and it still fails with:

DDR Version V1.07 20220412                                                   
LPDDR4X, 2112MHz                                                             
channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB
channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB
channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB
channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB
change to F1: 528MHz                                        
change to F2: 1068MHz                                       
change to F3: 1560MHz                                       
change to F0: 2112MHz                                       
out                                                         
U-Boot SPL board init
U-Boot SPL 2017.09-gc060f28d70-220414 #zyf (Apr 18 2022 - 18:13:34)
Failed to set cpub01
Failed to set cpub23                                                            
unknown raw ID phN                                                              
unrecognized JEDEC id bytes: 00, 00, 00                                         
Trying to boot from MMC2                                                        
MMC: no card present                                                            
mmc_init: -123, time 0                                                          
spl: mmc init failed with error: -123                                           
Trying to boot from MMC1                                                        
Trying fit image at 0x4000 sector                                               
## Verified-boot: 0                                                             
## Checking firmware@1 0x00200000 ... OK                                        
## Checking fdt@1 0x003478b0 ... OK                                             
Total: 102.843 ms                                                               
                                                                                
Jumping to U-Boot(0x00200000)

freezing at the last line. Looks like I'll have to revert again. I note u-boot's build also creates a number of other files like u-boot.dtb, u-boot.bin, u-boot-dtb.img and so forth - what do you do with those, especially the .bin ones? There's also a "u-boot.map", not sure what to do with that one either.

ADD: Aha, I see - it says

Note 1: If preloader is miniloader, loader2 partition available for uboot.img and trust partition available for trust.img; if preloader is SPL without trust support, loader2 partition is available for u-boot.bin and trust partition not available; If preloader is SPL with trust support(ATF or OPTEE), loader2 is available for u-boot.itb(including u-boot.bin and trust binary) and trust partition not available.

Since the output showed "U-Boot SPL board init" that suggests the preloader is SPL, right? Then uploading u-boot.img was not correct. So how do I determine if it has "trust support" so I know whether to load u-boot.bin or u-boot.itb? I suppose I could just cycle through both to find out by trial and error though.