I've asked about this thing on a range of forums now, often with little luck in getting responses, so I've had to slog and fiddle my way through it mostly by trial and error, but this last problem really has me stumped - it's been really hard going because while I've used Linux a lot, virtually all my experience has been on standard x86 PCs where things mostly "just work", but this interesting little bit of Chinese hardware is quite a different story.
What I have, folks, is a "Firefly ITX-3588J" board, which has been given a home in a small form desktop case. It's a very interesting little thing: it's got the form factor of a small PC board, but it uses a "Rockchip RK3588" ARM processor and is built in many ways like a smartphone or mobile tablet would be: it runs Android as well as Linux natively, it has a flash memory chip (embedded MultiMediaCard or eMMC), and an "M.2" port onboard that one could actually use to affix a network card for xG (3G/4G/5G) phone network access, among other possible devices. I got it because I wanted to try something different to the long-standing x86 monopoly, because it has low power usage thanks to the ARM processor, and because I do, indeed, at some point want to actually try to see if it will work as an honest phone, ideally as a land-line replacement for a home phone.
The trouble is, and as I've discovered after much digging around how things work in the ARM world which is typified by many compact and low-power devices (not surprising) like this, that you can't just set up OSes on these things like you do on a PC. Instead the process looks to be much more like loading ROMs to an Android phone, and what I am trying to doing is, in effect, what would be called in smartphone land "creating a custom ROM". For you see, unlike a smartphone, the board does feature a rather generous 4 (yes!) SATA ports, and when I saw those I realized what I wanted: loading an OS to an attached hard drive. I naturally bought a 250 GB SSD along with the board and hooked it up. Trouble is, the vendor ROMs for both Android 12 and Ubuntu 20.04, are mutually exclusive as they are made: you can only have one on the eMMC at a time, they're cohesive flash packs. So to make this work, I had to create my own flash pack ("custom ROM") and fortunately the vendors (Firefly, and Rockchip) provide a generous SDK full of open source code (including for the modified 5.10.66 kernel with the RK3588 support) and tools to do this. And that's what I've done. I have a pack now where the kernels are on the eMMC and have gotten it so the Android user data and Ubuntu 20.04 root file system are both loaded onto the SSD.
And yet there's a problem. First off (and it was a lot of trial-and-error work in its own right!), Android works beautifully (though unfortunately shows some design quirks when it comes to being driven with a mouse instead of a touch screen), but Ubuntu 20.04, sadly, does not. In particular, one big thing: graphics. You see, when you load the Ubuntu 20.04 stock ROM, it goes just fine - the desktop comes up without a hitch. But in my custom ROM, after loading the kernels I then used Android via ADB to push a primitive Ubuntu rootfs (generated via "debootstrap" with suitable --arch and --foreign options) to the SSD and then was able to log in via serial console to it and pull the rest of the system via APT from the Internet (i.e. "apt-get install ubuntu-desktop"). And after that: no graphics. X doesn't come up. All I have is serial debug. Neither on boot, nor when giving a "startx", "xinit" or the like via the serial debug console (fwiw, that's listed by the system as /dev/ttyFIQ0 - there is also no framebuffer console apparently [also there doesn't look to be in the stock image either so not sure that is even supported at all], but there are still devices like /dev/tty0, /dev/tty1, etc. as though there were. Hardware wise, it's a 3-prong UART terminal on the board that requires a converter to be wired to it to get USB access on a hosting computer.).
Looking at my /var/log/Xorg.0.log isn't too helpful - on my latest try and yet another reconfiguration of the kernel, I am getting "glamor initialization failed", and when I look further into /var/log/syslog, I find "systemd-logind: failed to take device /dev/dri/card0 [and card2]: Device or resource busy", "glamor initialization failed", and "modeset(0): drmSetMaster failed: Device or resource busy". It does seem like it is sensing my monitor though because it gives a bunch of modelines that look right and it identifies it by name - just can't bring up the screen. FWIW, apparently the RK3588 has an integrated ARM Mali G610 "Valhall" GPU, and this does not appear to have mainstream kernel support as of yet (nor does the RK3588 itself even), but since I'm using the vendor-supplied kernel which is what I believe they use in the Ubuntu stock ROM, it should work, no? Can Ubuntu be gotten working on this thing, or what?
Of course, there may be one more option here: the board also has one PCI Express x4 slot. I could theoretically get a breakout GPU card and screw the on-chip Mali. The trouble is, I rather not shell out money on hardware if software can do somehow. Not to mention finding a suitably low-profile and x4 (instead of x16) GPU card is a tricky matter in its own right.
What I have, folks, is a "Firefly ITX-3588J" board, which has been given a home in a small form desktop case. It's a very interesting little thing: it's got the form factor of a small PC board, but it uses a "Rockchip RK3588" ARM processor and is built in many ways like a smartphone or mobile tablet would be: it runs Android as well as Linux natively, it has a flash memory chip (embedded MultiMediaCard or eMMC), and an "M.2" port onboard that one could actually use to affix a network card for xG (3G/4G/5G) phone network access, among other possible devices. I got it because I wanted to try something different to the long-standing x86 monopoly, because it has low power usage thanks to the ARM processor, and because I do, indeed, at some point want to actually try to see if it will work as an honest phone, ideally as a land-line replacement for a home phone.
The trouble is, and as I've discovered after much digging around how things work in the ARM world which is typified by many compact and low-power devices (not surprising) like this, that you can't just set up OSes on these things like you do on a PC. Instead the process looks to be much more like loading ROMs to an Android phone, and what I am trying to doing is, in effect, what would be called in smartphone land "creating a custom ROM". For you see, unlike a smartphone, the board does feature a rather generous 4 (yes!) SATA ports, and when I saw those I realized what I wanted: loading an OS to an attached hard drive. I naturally bought a 250 GB SSD along with the board and hooked it up. Trouble is, the vendor ROMs for both Android 12 and Ubuntu 20.04, are mutually exclusive as they are made: you can only have one on the eMMC at a time, they're cohesive flash packs. So to make this work, I had to create my own flash pack ("custom ROM") and fortunately the vendors (Firefly, and Rockchip) provide a generous SDK full of open source code (including for the modified 5.10.66 kernel with the RK3588 support) and tools to do this. And that's what I've done. I have a pack now where the kernels are on the eMMC and have gotten it so the Android user data and Ubuntu 20.04 root file system are both loaded onto the SSD.
And yet there's a problem. First off (and it was a lot of trial-and-error work in its own right!), Android works beautifully (though unfortunately shows some design quirks when it comes to being driven with a mouse instead of a touch screen), but Ubuntu 20.04, sadly, does not. In particular, one big thing: graphics. You see, when you load the Ubuntu 20.04 stock ROM, it goes just fine - the desktop comes up without a hitch. But in my custom ROM, after loading the kernels I then used Android via ADB to push a primitive Ubuntu rootfs (generated via "debootstrap" with suitable --arch and --foreign options) to the SSD and then was able to log in via serial console to it and pull the rest of the system via APT from the Internet (i.e. "apt-get install ubuntu-desktop"). And after that: no graphics. X doesn't come up. All I have is serial debug. Neither on boot, nor when giving a "startx", "xinit" or the like via the serial debug console (fwiw, that's listed by the system as /dev/ttyFIQ0 - there is also no framebuffer console apparently [also there doesn't look to be in the stock image either so not sure that is even supported at all], but there are still devices like /dev/tty0, /dev/tty1, etc. as though there were. Hardware wise, it's a 3-prong UART terminal on the board that requires a converter to be wired to it to get USB access on a hosting computer.).
Looking at my /var/log/Xorg.0.log isn't too helpful - on my latest try and yet another reconfiguration of the kernel, I am getting "glamor initialization failed", and when I look further into /var/log/syslog, I find "systemd-logind: failed to take device /dev/dri/card0 [and card2]: Device or resource busy", "glamor initialization failed", and "modeset(0): drmSetMaster failed: Device or resource busy". It does seem like it is sensing my monitor though because it gives a bunch of modelines that look right and it identifies it by name - just can't bring up the screen. FWIW, apparently the RK3588 has an integrated ARM Mali G610 "Valhall" GPU, and this does not appear to have mainstream kernel support as of yet (nor does the RK3588 itself even), but since I'm using the vendor-supplied kernel which is what I believe they use in the Ubuntu stock ROM, it should work, no? Can Ubuntu be gotten working on this thing, or what?
Of course, there may be one more option here: the board also has one PCI Express x4 slot. I could theoretically get a breakout GPU card and screw the on-chip Mali. The trouble is, I rather not shell out money on hardware if software can do somehow. Not to mention finding a suitably low-profile and x4 (instead of x16) GPU card is a tricky matter in its own right.
