Dont panic - XpressReal T3 and radxa E54C

Requests
1

Hi, i am new here and i already have request. at my search for a low power board with 12v and m.2 slot , i just ordered the XpressReal T3 and the radxa E54C board and would like to run dietpi. right now these boards are not supported and so i would like to know how i could help that both boards are getting support in the future.

once i did read the galaxy hitchhiker book and because i do understand the warning of the 5th book, i beliefe now is the time to do that. the internet will get instable and overfloated, there are not much years left i believe.

2

you could try the Armbian image XpressReal T3 - Armbian
and run DietPi conversion script afterwards. Supported hardware - DietPi.com Docs

3

thank you.
what i like about dietpi is, that after microsd flash, i can copy my config files and script and it just do. because i believe every “dont panic” book owner have different boards and the final “dont panic book” will not have a keyboard, only voice and screen, i am asking, how i can help to provide a dietpi iso for the boards

4

:+1: :laughing:

5

to create official supported images, you would need to integrate the board into our build script DietPi/.build/images/dietpi-build at 4471bf892e57845714b820f4f0df238f8a8f4392 · MichaIng/DietPi · GitHub

Best to ask @MichaIng in this case

6

Generally, if Armbian has it implemented into their build system, it is relatively easy to implement it into DietPi. The following PR can be used as reference: Orange Pi 3: add support by MichaIng · Pull Request #7615 · MichaIng/DietPi · GitHub

Checking the config, the XpressReal T3 has community support only at Armbian, and it is a completely own SoC, which is unlikely to ever get mainline Linux support, but is based on vendor sources, same with U-Boot: build/config/sources/families/realtek-rtd1619b.conf at 8325404b2502a1fedbb8dc074ec94ef623286c0d · armbian/build · GitHub

I did not check back, but based on this first view, to me it looks like a dead end, the board I mean. Linux 6.6, which will likely never be updated, and never be supported by mainline Linux or U-Boot. … although, at least the SoC itself is in Linux already, but no XpressReal board: Making sure you're not a bot!

But mainline U-Boot neither supports this SoC nor any board from XpressReal. As long as you or someone else do not have other information that this board will get proper Linux and U-Boot support, I would strongly recommend against buying it, as long as you do not plan to bin it anyway in max 2 years. And as such, I would also vote against support in DietPi. We already have a backlog of bugs and requests around supported boards, and a number of more boards in the pipeline from better known vendors with SoCs that have or will get mainline support. So I would focus on these.

There is always the way to migrate an Armbian system as “Generic Device” with the dietpi-installer.

Other thing with Radxa E54C. It is not supported by Armbian yet, but as far as I can see, it should be possible to moreless copy&paste the config from the E52C: build/config/boards/radxa-e52c.conf at 8325404b2502a1fedbb8dc074ec94ef623286c0d · armbian/build · GitHub
The device tree would need to be patched from Radxa sources, but those will be surely added to the Armbian Rockchip Linux sources earlier or later: kernel/arch/arm64/boot/dts/rockchip/rk3588s-radxa-e54c.dts at 3f671654064b5efa8538748356d2c9bd3b754462 · radxa/kernel · GitHub

Someone else could implement support right into Armbian upstream, otherwise on our soft fork: GitHub - MichaIng/build: Armbian Linux Build Framework

The way of implementing support into Armbian build system can be seen here on the Orange Pi CM5 example: orangepicm5: add support · MichaIng/build@befc844 · GitHub
Device tree overlays do not exist in the Radxa sources, which makes it easier. And since Armbian uses Radxa U-Boot sources for RK358x boards, neither U-Boot device tree nor config needs to be patched. So it is only the board config and Linux device tree.

2 Likes
7

Thx for clarification @MichaIng

8

that arguments and links are an eye opener to me.

i am new to compiling linux systems and i did not know how or where to start.

it looks like the xpressReal T3 is a dead brick i ordered, it probably will never fit because of a lack of working software with that. so i will use it as a data storage and not more, sad, but its not made for the book.

the Radxa E54C i will keep for testing and as soon i am able to port the .dts with a build fork and have a running system i will share my settings. otherwise i may just use the after-installer for my project.

to the project. i will continue with raspberry pi 5 and orange pi 5 ultra for development.

the idea of the “dont panic book” is simple right now, put wikipedia and stupidpedia and some clever books on that device and search it for keywords by the ask from the user, than take a very small LLM to read whats found, start to read out the user and present generated pictures to that. this needs some AI but the aim is to not need an big LLM.

however, right now its looks like the AI stuff (rekllama) only works with the latest debian bookwork version and not with debian trixie. on the orange pi 5 ultra the iso from dietpi with debian bookworm just simply won’t start, because something is missing.

PCIe Link Fail, LTSSM is0x3
…
Gave up waiting for root file system diveice. Common problems:
boot args → check rootdelay

* missing modules (cat /proc/modules: ls /dev)
  ALERT! UUID=f44d65e2-3938-403a-b208-555626c7a5ab does not exist Dropping to a shell!

i tried to add a M5Stack LLM accelerator M.2 board with an Axera chip (20+ TOPS, nice for picture diffusion), but even that needs the latest debian bookworm version and nothing else. radxa will bring out AICore AX-M1, they already got there first batch but somehow they dont send it out, looks like they have unsupported external software issues too.
EDIT: radxa just released the AX-M1 , looks like less than 200 sticks, we will test it out…

a friend sayed, on the end it will be just an emergency device with some info and no ai, but so far i do not accept

i will post as soon, i have something that could help the dietpi project.

thank you all for the time, esspaccially to MichaIng, thats something i can work with and now i know where to start to support the E54C.

2 Likes
9

Right now, Linux 6.6 is fine. A bit old but fully supports all relevant software. We currently ship RK3588 SoC images with a Linux 6.1 vendor kernel, so … However, for RK3588 mainline Linux support is there and becomes better, so at some point we can move to latest mainline Linux or latest LTS. If the XpressReal T3 gets no vendor kernel upgrades and no mainline support, in 2 years or so, Linux 6.6 will likely start to get issues with recent software that makes use of particular new kernel features.

So right now, you can use it perfectly fine with e.g. the Armbian image, optionally tuning it into DietPi. But based on the rough look at the sources, I guess chances are high that its kernel stays at 6.6, which is why I wouldn’t recommend to buy it. We have seen similar in some other cases, Sparky SBC (stuck at Linux 3.16), NanoPi 2 series (stuck at 4.4) and NanoPi 3 series (stuck at 4.14, actually 4.4 but Armbian invested efforts to rebase it onto 4.14 at least). All those cannot even run the oldstable Debian 12 Bookworm properly, which is why we need to drop support for them next year when we drop Debian 11 Bullseye support. And container engines like Docker + other such software which makes use of recent kernel features (including modern filters/firewalls) stopped working long before. And this is so sad, since especially the NanoPi 3 SBCs are pretty fast with their octa-core SoC. But if vendors contribute nothing to mainline support, making it extra hard for volunteer developers or interest is too low, I’d even vote for explicitly not buying such hardware for the possible market power effect :sweat_smile:.

Because their builds do not support recent libraries or something like that? The kernel is the same for SBCs on all Debian versions, so when compiling it yourself on Trixie it should work.

From which boot media did you try it? SD card, eMMC, M.2 NVMe SSD, USB? I have one here and will test. Since you mention the Bookworm image only, you did not test the Trixie one, did you? No need to do, same kernel same bootloader etc, hence I would be surprised instead if the Trixie image from same boot media boots, but the Bookworm one does not.

Allo USBridge Sparky nor GUI