All Activity

@KV1 I'm happy I'm able to help. I got a lot of help originally from @Pali and by the time we sorted out that the bootloader was the problem it seems that people have largely given up on these devices. It is a shame because they are actually quite good routers (except the wifi). You are actually the first person with an Ultra to reach out. OK, that's looking good. It means the bootloader image works for you and you should be safe to flash it if you want. The messages you posted above are indeed kernel output. To be clear, you don't have to have a more recent kernel to get the device to boot, but DVFS (frequency scaling) may not work without the patch to enable 1.2Ghz clock speed. If you run a kernel without that patch, everything will still work it will just run at full speed all the time which isn't very energy efficient. You are now at the stage where you have to consider how Armbian configures and packages the kernel for this device and ensure that your U-Boot configuration is using a supported boot flow. For example, U-Boot can support loading the kernel as an UEFI image directly (EFISTUB) among many other variations. The messages you posted above suggest that the device tree that is getting loaded may be incorrect/old and I would probably start by examining that. I don't know much about Armbian, but @Igor may also be able to point you in the right direction. Feel free to post your u-boot configuration here too as that could provide some insight into the boot process being used.

Thanks @bschnei! Yes, using the prebuilt image from your release worked -- the base mmc installation boots fine. And i do have the Espressobin-Ultra model. I still end up stuck in the Armbian (from SATA) build at: [ 1.580359] PM: genpd: Disabling unused power domains [ 1.585946] Waiting for root device /dev/sda1... [ 1.606664] usb 1-1: New USB device found, idVendor=1a40, idProduct=0101, bcdDevice= 1.11 [ 1.614861] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 1.621998] usb 1-1: Product: USB 2.0 Hub [ 1.626711] hub 1-1:1.0: USB hub found [ 1.630668] hub 1-1:1.0: 4 ports detected [ 11.622348] platform d0070000.pcie: deferred probe pending: platform: wait for supplier /soc/internal-regs@d0000000/phy@18300/phy@1 [ 11.634188] platform d00e0000.sata: deferred probe pending: platform: wait for supplier /soc/internal-regs@d0000000/phy@18300/phy@2 [ 11.645998] platform d0058000.usb: deferred probe pending: platform: wait for supplier /soc/internal-regs@d0000000/phy@18300/phy@0 However, putting it together, i'm guessing this is back to your mention of needing 6.15 or later kernel. Which Debian/Armbian hasn't folded in yet? I'll have to look into whether i can fork the Armbian, back-port the kernel patch. The fact that my build environment ended up with the initial issue makes me wonder if that's going to run into similar issues though. Either way, really appreciate all the work you've done in this space, and the help you're providing!

I've been an apt/Debian user long enough to have a reasonable idea how mirrors work, what I don't understand is why you have a mirror still listed that a few days ago had a copy of all packages and now it's an empty directory. Perhaps more to the point, is this a temporary technical glitch or permanent removal of Armbian packages? In any case I posted the next best option for those in Australia.

PSP emulation with PPSSPP should work for a lot of games. It's a pity we never got a fully working Vulkan driver. God of War is probably too much. At least it was when I tested it many years ago.

@Octavio Cuatrochio I just noticed your link in the first post. The board in the link is a FAKE Allwinner H313. If your board does not have a small AXP### chip then it's not an Allwinner H313.

The last update installed a broken firmware package which prevents the system from rebooting and there is no heartbeat. This is the tail end of the upgrade: Preparing to unpack .../40-libnss-myhostname_255.4-1ubuntu8.14_arm64.deb ... Unpacking libnss-myhostname:arm64 (255.4-1ubuntu8.14) over (255.4-1ubuntu8.12) ... Errors were encountered while processing: /tmp/apt-dpkg-install-QRewUS/02-armbian-firmware_26.2.1_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Since the install is on the internal eMMc that pretty much prevents any recovery So just retested. Brand new download and reburnt image to eMMc. Booted completed install setup. Performed a sudo apt update and sudo apt upgrade and it immediately breaks and becomes non bootable.

closed for off-topic

LLM has most likely read the patch I merged into Armbian

Is it possible to make a Bodhi Linux version that works on x98h

We don't deal with OpenWRT. I suggest to ask at some place where OpenWRT is distributed/supported.

No, I let LLM poking at the problem.

Does this come from the patch I recently submitted to the maillist? I think it should work there too; the issue is present on all boards with the RK3588 chip.

I need an OpenWrt system on X98H

For lazy people like me clapper from flathub is a solution.

@KV1 nice work! Looks like it made it to U-Boot before it died. Instead of building your own, have you tried to see if it boots using a release image built with a github runner here: https://github.com/bschnei/ebu-bootloader/releases/tag/2026.02.24. Even if you want to eventually build it yourself, you could just test to see if the image built at github works. If it does, and you know the source code is the same (it looks like you are building an -rc of U-Boot) then you can narrow it down to the compiler tools you are using. Just to confirm: this is for an EspressoBIN Ultra right? Not the V7/V5 or some other variant?

At the begginging of the page https://docs.armbian.com/Mirrors/#introduction it is written how the system works. What we don't provide on that list is current status of which are live in in sync. However you can check this at any moment: curl http://apt.armbian.com/mirrors | jq

Hi, Is it appropriate to raise this at https://github.com/armbian/build/issues, since the Headphone Jack audio is available on older version of the kernels and not available in the latest kernels? Thanks for your guidance.

Thanks @bschnei. I tried for a while to figure out what to do, but couldn't really understand.. not sure if i should be trying to set it to thumb or arm mode at that point, even. I did fallback to earlier binutils, and the build went fine. However, trying to boot from the flash-image.bin with mox-imager results in incomplete load and reset back to mmc/spinor ... any ideas? -- /mox-imager/mox-imager -D /dev/ttyUSB0 -t -E /srv/development/espressobin-ultra/2026-03-bschnei/built-on-old-bb/flash-image-20260401-bb.bin TIM version 3.6.00, issue date 2026-04-01, non-trusted, 3 images, 0 keys, boot flash sign SPI NOR Reserved area packages: CRV2 (size 20) CIDP (size 32) Consumer TBRI, packages: GPP1 GPP2 DDR3 GPP1 (size 852) Ignore timeouts in instructions: 0 GPP2 (size 456) Ignore timeouts in instructions: 0 DDR3 (size 2024) Initialize DDR memory: 1 Term (size 8) Found TIMH, hash sha-256, encryption none, size 3780, load 0x20006000, flash 0x00000000 Found WTMI, hash sha-256, encryption none, size 24336, load 0x1fff0000, flash 0x00004000 Found OBMI, hash sha-256, encryption none, size 1140712, load 0x64100000, flash 0x00015000 Going to send images to the device Sending escape sequence, please power up the device Received sync reply Sending escape sequence with delay Detected BootROM command prompt Sending wtp sequence Received ack reply Sending clearbuf sequence Initialized UART download mode GetVersion response: version 3.4.01, date 2016-05-15, CPU ARMA Sending image type TIMH 100% sent in 00:00 TIM-1.0 mv_ddr-devel-g7bcb9dc DDR4 16b 1GB 1CS Sending image type WTMI 100% sent in 00:02 Sending image type OBMI 100% sent in 01:40 [Type Ctrl-\ + c to quit] WTMI-devel-18.12.1-a3e1c67 WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.213V Setting clocks: CPU 1200 MHz, DDR 750 MHz CZ.NIC's Armada 3720 Secure Firmware v2024.04.15-6-gd6d9646 (Apr 1 2026 16:32:36) Running on ESPRESSObin Ultra NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.14.0(release):sandbox/v2.14-774-g8dae0862c NOTICE: BL1: Built : 16:32:41, Apr 1 2026 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.14.0(release):sandbox/v2.14-774-g8dae0862c NOTICE: BL2: Built : 16:32:51, Apr 1 2026 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.14.0(release):sandbox/v2.14-774-g8dae0862c NOTICE: BL31: Built : 16:32:56, Apr 1 2026 U-Boot 2026.04-rc5-00019-gc704af3c8b0f (Apr 01 2026 - 17:08:14 -0400) DRAM: 1 GiB "Synchronous Abort" handler, esr 0x96000044, far 0xd5380000aa1e03fd elr: 0000000000036a08 lr : 0000000000036a64 (reloc) elr: 000000003ff4aa08 lr : 000000003ff4aa64 x0 : 0000000000000098 x1 : d5380000aa1e03fd x2 : 0000000000000000 x3 : 000000003fb07b00 x4 : 0000000000000000 x5 : 0000000000000000 x6 : 0000000000000000 x7 : 000000003fb07b20 x8 : 000000003faff64c x9 : 000000003fb00034 x10: 0000000000000000 x11: 0000000000000600 x12: 000000003faff70c x13: 000000003faff9b0 x14: 000000003faff9b0 x15: 0000000000000000 x16: 0000000000000000 x17: 0000000000000000 x18: 000000003fb03e10 x19: 0000000000000000 x20: 000000003fb07780 x21: 000000003fb077a0 x22: 0000000000000000 x23: 0000000000000000 x24: 0000000000000000 x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 0000000000000000 x29: 000000003faff7a0 Code: f9405261 f9005274 f81e02a0 f9000681 (f9000034) Resetting CPU ... resetting ... TIM-1.0 WTMI-devel-18.12.1-1a13f2f WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.213V NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.5(release):e65dc63 (Marvell-devel-18.12.2) NOTICE: BL1: Built : 22:43:22, Mar 4 2026 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.5(release):e65dc63 (Marvell-devel-18.12.2) NOTICE: BL2: Built : 22:43:25, Mar 4 2026 NOTICE: BL1: Booting BL31 NOTICE: BL31: v1.5(release):e65dc63 (Marvell-devel-18.12.2) NOTICE: BL31: Built : 22 U-Boot 2020.10-6.0.0-g29a6ea5c-dirty (Mar 28 2026 - 21:49:54 -0400) Model: gti cellular cpe board DRAM: 1 GiB Comphy chip #0: Comphy-0: USB3_HOST0 Comphy-1: PEX0 2.5 Gbps Comphy-2: SATA0 6 Gbps Target spinup took 0 ms. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIE-0: Link up MMC: sdhci@d8000: 0 Loading Environment from SPIFlash... unrecognized JEDEC id bytes: 61, 12, 9b *** Warning - spi_flash_probe_bus_cs() failed, using default environment Net: Error: neta@30000 address not set. mdio_register: non unique device name 'neta@30000' No ethernet found. starting USB... Bus usb@58000: Register 2000104 NbrPorts 2 Starting the controller USB XHCI 1.00 Bus usb@5e000: USB EHCI 1.00 scanning bus usb@58000 for devices... 1 USB Device(s) found scanning bus usb@5e000 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 Marvell>>

@alexc Thanks for all your hard work! I’ve put together an Armbian build using your kernel—you can check it out here: https://github.com/NickAlilovic/build/tree/Radxa-mainline-WIP

So, I went through this recently on an NVidia device, and device tree overlays really aren't that hard. But there's a few things you'll need to get set up first, and not having an M5 to check, you'll probably have to do some reading / verification. I make no claim this will work out of the box for you. But I imagine this will save you a lot of reading. There's an example .dtbo at https://github.com/KF0ARE/i2c0-rtc.dtbo/blob/main/i2c0-rtc.dtbo you should look at, and you can decompile it with the following: dtc -O dts -o i2c0-rtc.dts i2c0-rtc.dtbo Which contains a fragment you'll be interested in, explicitly for the DS3231 ... /dts-v1/; / { compatible = "brcm,bcm2708"; ... snip ... fragment@3 { target = <0xffffffff>; __dormant__ { #address-cells = <0x01>; #size-cells = <0x00>; status = "okay"; ds3231@68 { compatible = "maxim,ds3231"; reg = <0x68>; status = "okay"; phandle = <0x04>; }; }; }; ... snip ... }; But you can't use this directly, because "compatible" doesn't include your M5, and "target" doesn't point anywhere useful in your DT. But it does call out the ds3231, and that it's at I2C address 0x68, so you can use that to find where the kernel thinks your RTC is. Take a look at where your I2C buses are (/dev/i2c-*) and just scan each of them like this to see if you can find it: tparys@pebble:~$ sudo i2cdetect -y -r 0 # NOTE: I2C bus #0 is /dev/i2c-0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- In the above, address 0x10 is unusable as there's something else bound at that register. But check your buses to see if you can find 0x68. If you see something other than "--" or "UU" there, that's probably it. If you can't find it, double check that it's connected, powered on, and that your I2C bus has been enabled (might need to enable via DTB). Once you find it, you should be able to register it by doing something similar to the below as root (driver and I2C bus may be different): echo ds3231 0x68 > /sys/bus/i2c/devices/i2c-0/new_device If that works, and creates a /dev/rtc0 device, test that it's working with "hwclock". Once it's working, it's time to make your .dtbo. You'll probably want to dump your main .dtb with the same dtc command above, and look for i2c-0 (or whatever other bus you found), as well as a .dtbo or two for your M5 to find text to enter for "compatible". And you'll end up with something like this, saved as "m5-ds3231.dts" (or whatever): /dts-v1/; /plugin/; / { compatible = "brcm,bcm2708"; // <---- Change this fragment@0 { target = "i2c-0"; // <---- Change this __overlay__ { #address-cells = <0x01>; #size-cells = <0x00>; status = "okay"; ds3231@68 { compatible = "maxim,ds3231"; reg = <0x68>; status = "okay"; phandle = <0x04>; }; }; }; }; And you'll compile it like this: dtc -@ -O dtb -o m5-ds3231.dtbo m5-ds3231.dts And check it against your M5's DTB like below. Note that "target" or "target-path" has some odd syntax requirements. Quotes with a leading slash is a full path to your I2C device. Quotes without a leading slash is an alias. And angle brackets with an ampersand is a label (not everything has an explicit label). Worst case scenariou, call out the whole path in "target-path" with a leading slash, and call it a day. I beat my head against a wall for a while here before I realized I could test this without rebooting ... fdtoverlay -i /path/to/your/used.dtb -o modified.dtb m5-ds3231.dtbo And then add it to your overlay directory (/boot/dtb/CHIPNAME/overlays), enable it armbianEnv.txt, and give it a go? There's also two kernel build configs that may be of interest as well: CONFIG_RTC_HCTOSYS_DEVICE="rtc0" CONFIG_RTC_SYSTOHC_DEVICE="rtc0" The first triggers the kernel to load time from a given RTC when it first shows up. The second will tell the system to update RTC when locked against NTP. FYI, it seems that you can change these only with a new kernel build.

I am glad that it's possible to use a different ffmpeg version than what the distribution expects. (it gives me hope of installing it in Trixie, instead of changing over to the newest Ubuntu) Did you install the locally compiled ffmpeg at OS level, or did you keep it in a folder within your /home/username/...?

@andrey.lobov try to upgrade the kernel or pick a fresh image from the github repository. The tm16xx driver has been reenabled recently after having being disabled due to partial kernel upstream.

@Mohammad Adel AW869A and AIC8800 are the same WiFI chips. You should have WiFi working.

After I closed the lid of my chromebook Armbian decided to die even across reboots. https://drive.google.com/file/d/1gkEzVoY5QkNcWq3MOKYUSc8nkFYg91p-/view?usp=sharing Video of what I see https://drive.google.com/file/d/17yhnIjzkiYkkVohFrLf7MKDtYyb0xfOL/view?usp=sharing

I finally successfully got Armbian installed on my Pinebook Pro's eMMC. That should be giving it its best possible performance. I thought you may all be interested in compiling a list of games that work at least reasonably well on it given its restrictions of being ARM64 architecture, 1.8GHz CPU & 4GBs RAM. So to start here is a list of the ones I currently have on mine. I may try more later but for now I'm limited by the stock 64GB eMMC that the PCP came with... 0AD - 3D RTS Cave Story - Pixel Art Metroidvania Dr Robotnik's Ring Racers - Kart Racer Dune Legacy - RTS Endless Sky - Space Sandbox Flare - Fantasy RPG Freeciv - Strategy Freecol - Strategy GZDoom - Doom Engine for Mods & Total Conversions Hedgewars - Worms "Homage" Neverball - Monkeyball "Homage" Neverputt - Miniputt Golf Game Open Fodder - FOSS Engine for "Cannon Fodder" OpenRA - FOSS RTS Engine for "Tiberian Dawn", "Red Alert" & "Dune 2000" Open TTD - Transit Management Sim OpenTyrian - FOSS Engine for Top-Down Shmup "Tyrian" Perfect Dark - PC Port of N64 Game with Keyboard/Mouse Support Pico-8 - Indie Pixel Art Gaming & Development Platform Pingus - Lemmings "Homage" ScummVM - FOSS Engine for Classic Point & Click Games Sonic Robo Blast 2 - 3D Platformer The Ur-Quan Masters - FOSS Port of Space Sandbox "Star Control II" Xonotic - Arena Shooter FPS There are other games I have not yet personally tried like OpenHV, SuperTuxKart, other emulators etc but if anyone can confirm they work reasonably well on the Pinebook Pro then please let the rest of us know. All ScummVM games I've tried from King's Quest I to Grim Fandango work perfectly. However GZDoom will struggle with especially demanding modern Doom mods like Trenchfoot, Auger Zenith, Inquisitor III, Godless Nite etc. but most like Aliens: Eradication, Ashes 2063/Afterglow, Brutal Doom, Castlevania: Simon's Destiny, Irontusk's Diablo 3D, Revenge of the Triad etc run just fine.