Orion O6 Debug Party Invitation

willy · February 21, 2025, 7:12am

yep, I noticed it yesterday

dominik · February 21, 2025, 9:18am

Great news
I have question regarding pcie slot, it was said that no bifurcation support at this time, is that hardware limitation or just no plans on software for that now?

jack · February 21, 2025, 9:25am

Hardware limitation

DualTachyon · February 21, 2025, 9:52am

Is JTAG/SWD available on easy-access pin/header and is it unlocked/unlockable on the SoC? (Secure boot seems present, if so this might disable it).

Vladimir_Smirnov · February 24, 2025, 12:13pm

That is a good thing, but that should be done in parallel with publishing source code for the current kernel.

jack · February 24, 2025, 12:56pm

It’s already on the schedule, next week we will publish the 6.1 kernel source code, EDK2 source code and the Debian image build scripts.

neggles · February 25, 2025, 4:29am

no source for the vendor 6.6 (ACPI) kernel?

chalkin · February 26, 2025, 3:01am

The UEFI GOP of the o6 does not work on some high-resolution, high-refresh-rate monitors (e.g., my display defaults to 2880×1800 @90Hz), resulting in a black screen, but it functions properly at 1080p resolution on my Rock5B UEFI.

NOTICE:  BL2: v2.7(debug):Beta_2.0.3_release
NOTICE:  BL2: Built : 20:04:34, Jan 15 2025
CRYPTO_LITE  TOP_STAT_CFG0_STAT:0x70018c63
CRYPTO_LITE  Wait SW initialization done!
CRYPTO_LITE  Software initialization done!
CRYPTO_LITE  Current host ID: 1
CRYPTO_LITE      RN_POOL is: Secure
CRYPTO_LITE      ACA is: Secure
CRYPTO_LITE      HASH is: Secure
CRYPTO_LITE      SCA is: Secure
CRYPTO_LITE      ACA SRAM size:          8192 Bytes
CRYPTO_LITE      ACA CQ depth:           8
CRYPTO_LITE      HASH CQ depth:          8
CRYPTO_LITE      SCA CQ depth:           8
CRYPTO_LITE      HASH long ctx number:   4
CRYPTO_LITE      HASH short ctx number:  4
CRYPTO_LITE      SCA long ctx number:   4
CRYPTO_LITE      SCA short ctx number:  4
CRYPTO_LITE      OTP device initial value:  1
CRYPTO_LITE      OTP shadow registers save to AO
CRYPTO_LITE      OTP device: NOT exist
CRYPTO_LITE      TRNG internal source: Exist
CRYPTO_LITE  CE Version: EAC REL r3p1
INFO:    Using crypto library 'CIX SEC'
INFO:    BL2: Doing platform setup
INFO:    Configuring TrustZone Controller
INFO:    Total 2 regions set.
INFO:    Configuring TrustZone Controller
INFO:    Total 2 regions set.
INFO:    Configuring TrustZone Controller
INFO:    Total 2 regions set.
INFO:    Configuring TrustZone Controller
INFO:    Total 2 regions set.
INFO:    BL2: Loading image id 3
INFO:    Loading image id=7 at address 0x80200000
INFO:    pb.tfabde:0
INFO:    Flash load BL3X!
INFO:    Image id=7 loaded: 0x80200000 - 0x80200650
INFO:    SE lc: 7, sec: 1, img_id: 7
INFO:    copy ROTPK from DDR
INFO:    copy done
INFO:    rsa len: 384
padding_type:3
rsa bits:5
CRYPTO_LITE  RSA verify pass, pkcs2v1
INFO:    md_alg: 6
INFO:    hash_len: 32
INFO:    Loading image id=9 at address 0x80200000
INFO:    pb.tfabde:0
INFO:    Flash load BL3X!
INFO:    Image id=9 loaded: 0x80200000 - 0x8020065a
INFO:    SE lc: 7, sec: 1, img_id: 9
INFO:    rsa len: 384
padding_type:3
rsa bits:5
CRYPTO_LITE  RSA verify pass, pkcs2v1
INFO:    Loading image id=13 at address 0x80200000
INFO:    pb.tfabde:0
INFO:    Flash load BL3X!
INFO:    Image id=13 loaded: 0x80200000 - 0x80200530
INFO:    SE lc: 7, sec: 1, img_id: 13
INFO:    rsa len: 384
padding_type:3
rsa bits:5
CRYPTO_LITE  RSA verify pass, pkcs2v1
INFO:    Loading image id=3 at address 0x80200000
INFO:    pb.tfabde:0
INFO:    Flash load BL3X!
INFO:    Image id=3 loaded: 0x80200000 - 0x8021961d
INFO:    SE lc: 7, sec: 1, img_id: 3
INFO:    BL2: Loading image id 4
INFO:    Loading image id=10 at address 0x80500000
INFO:    pb.tfabde:0
INFO:    Flash load BL3X!
INFO:    Image id=10 loaded: 0x80500000 - 0x80500668
INFO:    SE lc: 7, sec: 1, img_id: 10
INFO:    rsa len: 384
padding_type:3
rsa bits:5
CRYPTO_LITE  RSA verify pass, pkcs2v1
INFO:    Loading image id=14 at address 0x80500000
INFO:    pb.tfabde:0
INFO:    Flash load BL3X!
INFO:    Image id=14 loaded: 0x80500000 - 0x805005ce
INFO:    SE lc: 7, sec: 1, img_id: 14
INFO:    rsa len: 384
padding_type:3
rsa bits:5
CRYPTO_LITE  RSA verify pass, pkcs2v1
INFO:    Loading image id=4 at address 0x80500000
INFO:    pb.tfabde:0
INFO:    Flash load BL3X!
INFO:    Image id=4 loaded: 0x80500000 - 0x805cd8d8
INFO:    SE lc: 7, sec: 1, img_id: 4
INFO:    BL2: Loading image id 5
INFO:    Loading image id=36 at address 0x84400000
INFO:    pb.tfabde:0
INFO:    Flash load BL3X!
INFO:    Image id=36 loaded: 0x84400000 - 0x8440063a
INFO:    SE lc: 7, sec: 1, img_id: 36
INFO:    copy ROTPK from DDR
INFO:    copy done
INFO:    rsa len: 384
padding_type:3
rsa bits:5
CRYPTO_LITE  RSA verify pass, pkcs2v1
INFO:    md_alg: 6
INFO:    hash_len: 32
INFO:    Loading image id=11 at address 0x84400000
INFO:    pb.tfabde:0
INFO:    Flash load BL3X!
INFO:    Image id=11 loaded: 0x84400000 - 0x8440066b
INFO:    SE lc: 7, sec: 1, img_id: 11
INFO:    rsa len: 384
padding_type:3
rsa bits:5
CRYPTO_LITE  RSA verify pass, pkcs2v1
INFO:    Loading image id=15 at address 0x84400000
INFO:    pb.tfabde:0
INFO:    Flash load BL3X!
INFO:    Image id=15 loaded: 0x84400000 - 0x84400541
INFO:    SE lc: 7, sec: 1, img_id: 15
INFO:    rsa len: 384
padding_type:3
rsa bits:5
CRYPTO_LITE  RSA verify pass, pkcs2v1
INFO:    Loading image id=5 at address 0x84400000
INFO:    pb.tfabde:0
INFO:    Flash load BL3X!
INFO:    Image id=5 loaded: 0x84400000 - 0x84600000
INFO:    SE lc: 7, sec: 1, img_id: 5
NOTICE:  BL2: Booting BL31
INFO:    Entry point address = 0x80200000
INFO:    SPSR = 0x3cd
INFO:    Start sky1 scmi server!
NOTICE:  BL31: v2.7(debug):Beta_2.0.3_release
NOTICE:  BL31: Built : 20:04:34, Jan 15 2025
INFO:    boot_core_index 10 
INFO:    cpu mask 0xa000
INFO:    GICv4 without legacy support detected.
INFO:    ARM GICv4 driver initialized in EL3
INFO:    Maximum SPI INTID supported: 543
INFO:    drv_mbox_init
INFO:    Send CMD: ECHO Request
NOTICE:  Send CMD: 0x82000001
INFO:    Got Echo RSP, Mbox channel is ready...
INFO:    plat_cix_scmi_setup
INFO:    SCMI driver initialized
INFO:    ###########ni700-qos setting###########################
INFO:    [MMHUB_CSI_SLV0]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_CSI_SLV1]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_CSI_SLV0]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_CSI_SLV0]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_DPU0_AFBC_SLV]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_DPU0_SLV0]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_DPU0_SLV1]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_DPU1_AFBC_SLV]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_DPU1_SLV0]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_DPU1_SLV1]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_DPU2_AFBC_SLV]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_DPU2_SLV0]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_DPU2_SLV1]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_DPU3_AFBC_SLV]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_DPU3_SLV0]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_DPU3_SLV1]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_DPU4_AFBC_SLV]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_DPU4_SLV0]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_DPU4_SLV1]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_ISP_AFBC_SLV]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_ISP_SLV0]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_ISP_SLV1]:override--1 read_qos--0f write_qos--0f 
INFO:    [MMHUB_NPU_SLV0]:override--1 read_qos--0d write_qos--0d 
INFO:    [MMHUB_NPU_SLV1]:override--1 read_qos--0d write_qos--0d 
INFO:    [MMHUB_VPU_SLV0]:override--1 read_qos--0d write_qos--0d 
INFO:    [MMHUB_VPU_SLV1]:override--1 read_qos--0d write_qos--0d 
INFO:    [SYSHUB_AUIDO_SLV]:override--1 read_qos--0f write_qos--0f 
INFO:    [SYSHUB_USB2_0_SLV]:override--1 read_qos--08 write_qos--08 
INFO:    [SYSHUB_USB2_1_SLV]:override--1 read_qos--08 write_qos--08 
INFO:    [SYSHUB_USB2_2_SLV]:override--1 read_qos--08 write_qos--08 
INFO:    [SYSHUB_USB2_3_SLV]:override--1 read_qos--0f write_qos--0f 
INFO:    [SYSHUB_USB3_0_SLV]:override--1 read_qos--08 write_qos--08 
INFO:    [SYSHUB_USB3_1_SLV]:override--1 read_qos--08 write_qos--08 
INFO:    [SYSHUB_USBC_0_SLV]:override--1 read_qos--08 write_qos--08 
INFO:    [SYSHUB_USBC_1_SLV]:override--1 read_qos--08 write_qos--08 
INFO:    [SYSHUB_USBC_2_SLV]:override--1 read_qos--08 write_qos--08 
INFO:    [SYSHUB_USBC_DRD_SLV]:override--1 read_qos--08 write_qos--08 
INFO:    ######################################################
INFO:    ###########ci700-qos setting###########################
INFO:    [CI700_RNF0]:override--1 read_qos--0d write_qos--0d 
INFO:    [CI700_RNF1]:override--1 read_qos--0d write_qos--0d 
INFO:    [CI700_RNF2]:override--1 read_qos--0d write_qos--0d 
INFO:    [CI700_RNF3]:override--1 read_qos--0d write_qos--0d 
INFO:    [CI700_GPU_RNI64_S0]:override[r-w]--[1-1] read_qos--0b write_qos--0b 
INFO:    [CI700_GPU_RNI64_S1]:override[r-w]--[1-1] read_qos--0b write_qos--0b 
INFO:    [CI700_GPU_RNI72_S0]:override[r-w]--[1-1] read_qos--0b write_qos--0b 
INFO:    [CI700_GPU_RNI72_S1]:override[r-w]--[1-1] read_qos--0b write_qos--0b 
INFO:    [CI700_PCIE]:override[r-w]--[1-1] read_qos--08 write_qos--08 
INFO:    [CI700_SYSHUB_SMMU]:override[r-w]--[1-1] read_qos--0f write_qos--0f 
INFO:    [CI700_DFD_TMC]:override[r-w]--[1-1] read_qos--0f write_qos--0f 
INFO:    [CI700_MMHUB_SMMU]:override[r-w]--[1-1] read_qos--0f write_qos--0f 
INFO:    [CI700_PCIEHUB_SMMU]:override[r-w]--[1-1] read_qos--0f write_qos--0f 
INFO:    ######################################################
INFO:    cix_qspi_init start...
INFO:    cix_qspi_init end...
INFO:    BL31: Initialising Exception Handling Framework
INFO:    BL31: Initializing runtime services
INFO:    last reboot reason:0x10 
INFO:    BL31: cortex_hunter: CPU workaround for cve_2022_23960 was applied
INFO:    SDEI platform setup
INFO:    BL31: Initializing BL32
E/TC:10    console_init:108 Cix uart register successful
E/TC:10    console_init:108 Cix uart register successful
I/TC: 
I/TC: OP-TEE version: Beta_2.0.3_release #1 Wed, 15 Jan 2025 20:08:15 +0800 aarch64
I/TC: OP-TEE cix version: Beta_2.0.3_release-3.17-0af95526e956
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
MBEDTLS_CORE  host[1] waits sw_init_done...MBEDTLS_CORE  [DONE]
MBEDTLS_CORE   HASH driver init success!
MBEDTLS_CORE   SCA driver init success!
MBEDTLS_CORE  SRAM Pool Base: 0x80000000, size: 0x2000, alignment: 0x10
MBEDTLS_CORE   ACA driver init success!
E/TC:10 00 tee_otp_get_hw_unique_key:123 Get hw key:
I/TC: Primary CPU switching to normal world boot
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x84400000
INFO:    SPSR = 0x3c9
[65.387] [UEFI] E3C1 XspiInitDxeStart
[65.388] [UEFI] E400 XspiInitDxeEnd
[65.476] [UEFI] E2C1 PcieInitDxeStart

Root Port 0 Link up fail

Root Port 1 Link up fail

Root Port 2 Link up fail
[65.850] [UEFI] E300 PcieInitDxeEnd
One display device is found on typec port1!
Update Platform Config Param GopDisplayPort=0x1
total 6 modes (current pixel clock 50671, width 2880, height 1800)

Mad_ad · February 26, 2025, 7:29pm

also cant get my ultrawide running with 5120x1440, changing Kernel parameters doesn’t fix it

Vladimir_Smirnov · February 26, 2025, 8:01pm

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

amazingfate · February 27, 2025, 9:59am

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/

meco · February 27, 2025, 10:23am

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

Bill_Fleming · February 27, 2025, 11:17am

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.

willy · February 27, 2025, 3:20pm

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 :-/

Mario · February 27, 2025, 8:08pm

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.

willy · February 27, 2025, 8:15pm

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 ?

Mario · February 27, 2025, 9:37pm

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.

willy · February 28, 2025, 4:13am

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.

Mario · February 28, 2025, 6:20am

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.

willy · February 28, 2025, 7:47am

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.