also cant get my ultrawide running with 5120x1440, changing Kernel parameters doesn’t fix it
Orion O6 Debug Party Invitation
In case that helps people who want to try mainline kernel:
KVER=6.13.4
sudo mkdir -p /boot/efi
sudo mount /dev/nvme0n1p1 /boot/efi
sudo apt -y install dracut build-essential bison flex libssl-dev firmware-linux firmware-linux-nonfree
wget "https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-${KVER}.tar.xz"
tar -xf linux-${KVER}.tar.xz
pushd linux-${KVER}
wget "https://gist.githubusercontent.com/Civil/8bf3259974136b05df9642139b7a60ae/raw/01a17d45a85494483a1f41dfb1243aceaf9937a6/.config"
make -j12
sudo make modules_install
sudo cp arch/arm64/boot/Image.gz /boot/vmlinuz-${KVER}
sudo dracut --force --kver ${KVER}
sudo cp arch/arm64/boot/Image.gz /boot/efi/vmlinuz-${KVER}
sudo cp /boot/initrd.img-${KVER} /boot/efi/
NUM=$(grep '^set default' /boot/efi/GRUB/GRUB.CFG | cut -d '"' -f 2)
NUM=$((NUM+1))
echo -e "\n\nmenuentry '${NUM} Mainline ${KVER}' {\n linux /vmlinuz-${KVER} root=/dev/nvme0n1p2 rootwait rw\n initrd /initrd.img-${KVER}\n}\n" | sudo tee -a /boot/efi/GRUB/GRUB.CFG
sudo sed -i 's/default=.*/default="'"${NUM}"'"/;s/timeout=.*/timeout=10/' /boot/efi/GRUB/GRUB.CFG
The kernel config is not perfect; I’ve used defconfig and changed a bunch of drivers to be compiled in because initramfs-tools were slightly broken and did not include the NVMe module, for example. But I haven’t paid too much attention to removing unneeded drivers.
Vanilla kernel OOPS on boot if I plug USB-C ethernet adapter (I had it for debugging purposes) and hangs at boot if I have Radeon RX6400 installed, but boots just fine with rx550.
Also, for newer GPUs, more recent firmware might be required, so something like that would help:
git clone --depth 1 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
cd linux-firmware
sudo apt -y install rdfind
sudo make install
sudo make dedup
It would be better though to
1 Like
Mainline linux upstream status updated from mailing list:
- Mainline linux will begin with devicetree, after most of IPs are supported then cix will start ACPI upstreaming work
- CIX will find a open place for mainline linux upstream plan/status.
https://lore.kernel.org/linux-arm-kernel/Z8AcFq9bDuW0oiD5@nchen-desktop/
3 Likes
This response from Peter already seems more reflected than anything I’ve seen in the last years from some other SoC manufacturers. I wonder how far along we’re gonna be in a year
1 Like
If they don’t have to change the device tree format to accommodate the new chip’s power sequencing I expect this one to go along much faster than recent Rockchip stuff did. No waiting on RTC clock sequencing or having to wait over a year for a gpu driver this time around before adding video ports. Panfrost driver testing on some V12 Mali HW has already begun and the first merge requests for V11/V12 have started coming in.
At least I don’t understand the rationale of upstreaming DT support since the BIOS supports ACPI. It would be much simpler to simply skip DT and focus on stuff that will allow modern distros to boot out of the box. They’re just postponing decent support for no perceivable reason. Also, delaying the access to the kernel tree only makes the situation more complicated for them since nobody can help them.
For example at this point I’ve tested all I could reasonably test, provided feedback. Now I have this board running on my desk, I cannot even try to fix anything nor even hack the ACPI stuff since no access is given. That’s strange :-/
2 Likes
ACPI today is really not flexible enough to cover such SoC designs, which is why you see vendors like Qualcomm still doing DT for Linux despite having ACPI for Windows (it isn’t actually full ACPI - half of the logic is buried in extension drivers).
You will have basic stuff working, but beyond that many changes need to happen to core Linux infrastructure and perhaps even the ACPI specification. I expect this will take a long time to implement in an upstream-friendly way. In the meantime, DT is the path of least resistance to get better upstream support.
I too would love to not see DT at all for such a system, but we have to be realistic. They’re essentially the first vendor doing this sort of thing. Yes, ACPI already exists on platforms like Ampere, but that is more similar to an x86 system and isn’t nearly as complex in terms of platform devices. So generally they can get away with existing bindings.
4 Likes
Actually SolidRun started it first with LX2K that was full EFI+ACPI and doesn’t come with a DT at all. I trust you if you say that it’s not as flexible as we’d like, but why does x86 manage to use it ?
1 Like
I recall SolidRun folks have also had lots of pain getting networking supported in Linux with ACPI for their platform (which took a year or more?). And that only required Linux changes; touching the spec is even more tedious 
In the end I believe they switched to U-Boot and DT for the LX2.
On x86, most peripherals get enumerated by PCIe and are fairly self-contained. On Arm SoCs, however, you have lots of platform devices with dependencies on other devices. The problem lies in describing some of these dependencies.
Let me give you an example:
On x86 systems, a GPU / iGPU appears to the host as a single device (except audio) handling everything from rendering to physical display output.
On Arm SoCs, a “GPU” generally only contains the rendering hardware block. Display controllers, output interfaces (HDMI/DP/etc.), PHYs are separate devices, each with its own dependencies and drivers.
Take RK3588 for instance. The display controller (VOP2) depends on pixel clocks exposed by the global clock & reset unit (CRU). VOP2 needs to be able to enable this particular clock and set its frequency based on whatever video mode is used for the corresponding output port.
This is a fairly straightforward relationship to describe in DT and is nicely abstracted by the Linux clock framework.
ACPI, however, lacks any (standard) means to support this. One of the things that need to be figured out is: should ACPI abstract clock providers (like it does power and other things), or should the OS have a hardware-specific driver like DT? The former is the only valid option in my opinion, but others disagree due to the high complexity.
That’s one of the biggest issues now, but there are others to tackle as well.
7 Likes
Thanks for providing these examples. Regarding LX2 I can assure you it ships with UEFI+ACPI, that was in fact my first encounter with those on an ARM machine 
It looks like this at boot:
willy@lx2b:~$ dmesg|grep -i 'efi\|acpi'
[ 0.000000] efi: EFI v2.70 by EDK II
[ 0.000000] efi: ACPI 2.0=0xef8d0018 SMBIOS 3.0=0xfacb0000 MEMATTR=0xeeda6018 RNG=0xfaccb098 MEMRESERVE=0xeedaed98
[ 0.000000] efi: seeding entropy pool
[ 0.000000] ACPI: Early table checksum verification disabled
[ 0.000000] ACPI: RSDP 0x00000000EF8D0018 000024 (v02 NXP )
[ 0.000000] ACPI: XSDT 0x00000000EF8DFE98 000064 (v01 NXP LX2160 00000000 01000013)
[ 0.000000] ACPI: FACP 0x00000000EF8DFB98 000114 (v06 NXP LX2160 00000000 INTL 20151124)
[ 0.000000] ACPI: DSDT 0x00000000EF8D0098 004A64 (v02 NXP LX2160 00000000 INTL 20181213)
[ 0.000000] ACPI: DBG2 0x00000000EF8DFA98 000062 (v00 NXP LX2160 00000000 INTL 20151124)
[ 0.000000] ACPI: GTDT 0x00000000EF8DE998 000130 (v02 NXP LX2160 00000000 INTL 20151124)
[ 0.000000] ACPI: APIC 0x00000000EF8DEB18 000568 (v04 NXP LX2160 00000000 INTL 20151124)
[ 0.000000] ACPI: MCFG 0x00000000EF8DFE18 00004C (v01 NXP LX2160 000000FF INTL 20151124)
[ 0.000000] ACPI: PPTT 0x00000000EF8D7518 000694 (v01 NXP LX2160 00000000 INTL 20151124)
[ 0.000000] ACPI: SPCR 0x00000000EF8DFF98 000050 (v02 NXP LX2160 00000000 INTL 20151124)
[ 0.000000] ACPI: IORT 0x00000000EF8DC798 001109 (v03 NXP LX2160 00000000 INTL 20151124)
[ 0.000000] ACPI: SPCR: console: pl011,mmio32,0x21c0000,115200
[ 0.000000] psci: probing for conduit method from ACPI.
[ 0.000000] ACPI GTDT: found 1 memory-mapped timer block(s).
[ 0.000072] ACPI: Core revision 20200925
[ 0.001537] Remapping and enabling EFI services.
[ 0.035730] ACPI: bus type PCI registered
...
and it works pretty well out of the box. The only thing that requires to be added is the 10G ethernet ports that you need to configure because they arrive on a 40/100G internal switch and you have to associate physical ports with internal ones.
1 Like
Oh I know it does work reasonably well with ACPI. What I meant is that they no longer appear to offer support for that path and instead suggest you use U-Boot + DT. From what I remember, the reasoning was that they had too much trouble upstreaming the ACPI side, while DT was fully working and so there wasn’t much incentive to continue. No clue how big of a difference there is between those two nowadays, though. LX2 is one of the “simpler” platforms with few custom hardware blocks.
So yeah, it’s certainly going to be interesting watching upstream efforts for the O6 . If it’s done right, it will benefit the whole ecosystem and hopefully more vendors start seeing value in adopting standards.
Interesting because I remember one of their engineers writing about the fact they didn’t want to reproduce the mcbin mess and went uefi first to support standard boots. The main problem with DT is that the user has to download one of the limited (and rarely supported) images provided by the board’s vendor. In a sane world, the device tree projects would be maintained outside of the kernel, would be backwards compatible and would always be shipped combined with u-boot on every board (i.e. just like a BIOS). But we’re not in this world and the most recent version of the device tree is needed to boot the most recent version of a kernel. The ext2linux stuff has improved things quite a bit by standardizing the distribution of files arranged as a file system and boards being named by the boot loader to compose the device tree path. But that’s still far from being reasonably portable; it just works when you properly configure the boards you have at home to boot the same kernel.
1 Like
Slightly off topic, but I just remembered Linaro’s Client PC project:
https://linaro.atlassian.net/wiki/spaces/CLIENTPC/overview
that was supposed to look into UEFI + ACPI firmware. Unfortunately it looks like not much has happened since July 2023 
1 Like
Did you notice the names of the active members at the bottom ? We might not be in bad hands
3 Likes
Can’t boot ACPI off USB yet it seems. Bit of a bummer.
Looking like there’s a little wait for them to release the dts with pcie(usb/net?) support. Is it possible to build u-boot with the latest arm trusted firmware so we don’t have to worry about spectre stuff ?
Fixed that one a couple of days ago:
https://lore.kernel.org/lkml/20250227194529.2288718-1-maz@kernel.org/
4 Likes
whoa lets go, I gotta try this
Armbian 25.2.1 Bookworm ttyAMA2
uefi-arm64 login:
yay
Quick Benchmark using openssl:
Rock5b (rk3588)
OPENSSL_armcap=0x0 openssl speed aes-128-cbc
The ‘numbers’ are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 104289.42k 127246.49k 133658.97k 136392.36k 137090.39k 137314.30k
Orion O6
OPENSSL_armcap=0x0 openssl speed aes-128-cbc
The ‘numbers’ are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 208104.03k 240319.70k 249169.51k 251895.13k 252949.85k 253034.50k
To be fair the Rock5b doesn’t idle at 10w tho
I have this enabled in my config (the same that runs on all my machines).
An SError is a prety serious matter, and is unlikely to be caused by the scheduler, unless there is a real HW problem. Try to disable the EFI runtime services to see if that helps.
So far everything is fine as far as running headless / data serving. I bring up a couple of openwrt containers and they run fine and a container for testing stuff. Ran some x265 10 bit encoding @1080p ‘slow’ preset, it got about 3.5 fps for each ffmpeg I was running ‘-threads 8’, and I was running two but i’m not sure if I got the best compiled x265. So 7-8 fps or so pretty good at 24-25 watts.
3 Likes
Cool, you ran OpenWRT on it? Which version? Bare-metal or visualized?
Device-Tree or via UEFI / ACPI?
How did you get the 5Gb ETH to work on OpenWRT?
Thank you!