All Activity

Sorry if i wasn't clear - that's two separate boot profiles... one with a USB drive plugged in, but just left it in after `bubt'ing. The real drive I'm trying to boot from is the SATA nVME 2280 (M+B Key). Once i take the USB drive out, no SDA devices are identified by the kernel. The 6.12.x kernel is on the 2280 drive (SATA/SCSI)... basically `uboot' is able to ext4load the kernel, but once the kernel drops in, it must not be initializing scsi/SATA support, only USB support. Thus, it can't find rootfs, because it hasn't initialized it... but i'm not sure why it hasn't initialized support. All the discussions / AI results suggest it's either a power issue -- which doesn't make sense if it *booted* from the drive itself already?! -- or a device tree issue. I don't know enough about device trees to know, but the above snippet looked like it had support. I reflashed/updated the NVMe via armbian-imager -- looks like a monthly release update, but no change. Are you booting from the emmc or USB then? You're not using the internal SATA/NVMe 2280 connector for boot? Presumably i COULD put root/boot fs on the emmc, but i like to have the fallback option if something goes wrong. This is what i did with my old one -- a DreamPlug, where i just have an SD Card drive everything. If i screw something up, I just take the SD Card out, and it boots off the good-but-old emmc.

@KV1 nice! So I think the kernel is saying it can "see" /dev/sda1 but that whatever filesystem you've got on that partition it does not recognize and could not mount after trying fat, ext4, and xfs. Are you sure /dev/sda1 has been formatted/imaged correctly? That looks like it's a USB thumb drive, right? If so, I would plug it into another working host and check that it is properly formatted and does indeed contain the intended root file system you'd like to boot. Where is /boot? /dev/mmcblk0p1?

Collabora presents "Bringing BitNet to ExecuTorch via Vulkan" at PyTorch Conference Europe in Paris (April 7-8) and attends ICLR in Rio de Janeiro (April 23-27). Connect with our team to discuss machine learning and open source innovation! View the full article

Here is an example of an overlay for adding an RTC to the radxa zero /dts-v1/; /plugin/; / { compatible = "radxa,zero", "amlogic,g12a"; fragment@0 { target-path = "/"; __overlay__ { aliases { rtc0 = &rtc; }; }; }; fragment@1 { target = <&i2c3>; __overlay__ { #address-cells = <1>; #size-cells = <0>; rtc: rtc@68 { compatible = "dallas,ds1307"; reg = <0x68>; wakeup-source; }; }; }; __overrides__ { rtc = <0>,"+0"; addr = <&rtc>, "reg:0"; }; }; Key bits here: * aliases (some of these AML units have vrtc on rtc0, so it may need to be set to rtc1) * i2c# (this should be obvious) * compatible string * wakeup-source The i2c-dev module must be force loaded in some cases. If it isn't hard coded into the kernel, you can add it to /etc/modules

Open source projects like ours operate with very limited resources, and infrastructure such as mirrors is maintained on a best-effort basis. We’re aware that things are not always perfect, but addressing this properly requires dedicated maintainers - something we never had. If you’d like to help improve the situation, we’d genuinely welcome someone stepping in to take ownership of this part of the infrastructure. Improving scripts to make this information correct and other things that are missing ... Perhaps contanting mirror owner would already be a solution. I understand - but our mirror system isn’t a standard Debian-style setup. The “empty mirrors” you’re seeing are a cosmetic problem. Only status isn’t automatically pruned yet, so entries can remain listed after they’re no longer active. This does not affect users: traffic is routed through apt.armbian.com and dl.armbian.com, which only serve from working mirrors. What’s missing is automation to keep the public listing in sync - not mirror functionality itself. One of those https://actions.armbian.com/?repo=armbian.github.io needs further development. Our rsync server works: rsync -av rsync://rsync.armbian.com/dl/ I have no clue as this mirror is not under our direct control. Edit: I sent email to administrator of AARNet.

You need to provide a lot more information. Lets start with logs/screenshots of what you are experiencing. What Box, what uboot, what dtb are you using? What armbian image are you using?

Thanks for your help. Unfortunatly there are few progress. I change in the global dts of the board the state of all the i2c descriptor from disable to okay and the device i2c-0 to 3 appear in linux, unfortunatly i2cdetect does'nt see the device on address 68 i2c@1c000 { compatible = "amlogic,meson-axg-i2c"; status = "disabled"; reg = <0x00 0x1c000 0x00 0x20>; interrupts = <0x00 0x27 0x01>; #address-cells = <0x01>; #size-cells = <0x00>; clocks = <0x02 0x18>; phandle = <0x12d>; }; I try a lot of tracks with the overlay but nothing change. And it's very difficult to debug and understand what is missing dtoverlay is not available nothing in syslog during boot and quite frankly I have'nt experience in dts design. the only information is the schematic of the board which describe pin3(40pins connector) =GPIOX_17 and pin5 =GPIOX_18 of the processor. inside the processor the route between the ports and the software is a mystery for me (mux adress of register ...) and how to link all that in the dtbo. Thanks if you can give me some direction ?

OK, I'm getting somewhere, I think -- with your help. I went ahead and flashed the image, which took fine: TIM-1.0 mv_ddr-devel-g4a3dc09 DDR4 16b 1GB 1CS 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 14f39dd (Feb 24 2026 19:59:06) Running on ESPRESSObin Ultra NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.14.0(release):1d5aa93 NOTICE: BL1: Built : 19:59:08, Feb 24 2026 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.14.0(release):1d5aa93 NOTICE: BL2: Built : 19:59:11, Feb 24 2026 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.14.0(release):1d5aa93 NOTICE: BL31: Built : 19:59:12, Feb 24 2026 U-Boot 2026.01-g127a42c7257a (Feb 24 2026 - 19:57:59 +0000) DRAM: 1 GiB Core: 59 devices, 27 uclasses, devicetree: separate WDT: Not starting watchdog@8300 Comphy chip #0: Comphy-0: USB3_HOST0 5 Gbps Comphy-1: PEX0 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: Link up MMC: mmc@d8000: 0 Loading Environment from SPIFlash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Globalscale Marvell ESPRESSOBin Ultra Board MMC Device 1 not found Net: eth0: ethernet@30000 [PRIME] Hit any key to stop autoboot: 0 My attempt to target the drive for boot was using scsi via so: => scsi scan scanning bus for devices... Device 0: (0:0) Vendor: ATA Prod.: ORICO Rev: Y090 Type: Hard Disk Capacity: 976762.3 MB = 953.8 GB (2000409265 x 512) => setenv scsi_fdt_name "/boot/dtb/marvell/armada-3720-espressobin-ultra.dtb" => setenv scsiboot "scsi dev 0; ext4load scsi 0:1 $kernel_addr_r $image_name;ext4load scsi 0:1 $fdt_addr_r $scsi_fdt_name;setenv bootargs $console root=/dev/sda1 rw rootwait net.ifn" => scsi info Device 0: (0:0) Vendor: ATA Prod.: ORICO Rev: Y090 Type: Hard Disk Capacity: 976762.3 MB = 953.8 GB (2000409265 x 512) => run scsiboot Device 0: (0:0) Vendor: ATA Prod.: ORICO Rev: Y090 Type: Hard Disk Capacity: 976762.3 MB = 953.8 GB (2000409265 x 512) ... is now current device 36991488 bytes read in 580 ms (60.8 MiB/s) 13472 bytes read in 6 ms (2.1 MiB/s) ## Flattened Device Tree blob at 06f00000 Booting using the fdt blob at 0x6f00000 Working FDT set to 6f00000 Using Device Tree in place at 0000000006f00000, end 0000000006f0649f Working FDT set to 6f00000 Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 6.12.68-current-mvebu64 (build@armbian) (aarch64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #5 SMP PREE6 [ 0.000000] KASLR enabled Trying again to load from the SATA M/B-key drive, via SCSI, perhaps I'm confusing myself or the SATA is not properly initializing? It looks as if we get pretty far -- if i leave the USB drive plugged in.. but i'm assuming that is taking /dev/sda1, which is why we're not finding a rootfs... but i'm obviously missing how to engage and/or reference the SATA drive, then? [ 3.098515] usb-storage 1-1.1:1.0: USB Mass Storage device detected [ 3.105468] scsi host0: usb-storage 1-1.1:1.0 [ 4.132658] scsi 0:0:0:0: Direct-Access Generic- SD/MMC 1.00 PQ: 0 ANSI: 0 CCS [ 4.484329] sd 0:0:0:0: [sda] 3907584 512-byte logical blocks: (2.00 GB/1.86 GiB) [ 4.492568] sd 0:0:0:0: [sda] Write Protect is off [ 4.498058] sd 0:0:0:0: [sda] No Caching mode page found [ 4.503387] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 4.532225] sda: sda1 [ 4.535092] sd 0:0:0:0: [sda] Attached SCSI removable disk [ 4.549528] FAT-fs (sda1): IO charset iso8859-1 not found [ 4.564748] FAT-fs (sda1): IO charset iso8859-1 not found [ 4.572867] List of all partitions: [ 4.576509] 0100 48000 ram0 [ 4.576522] (driver?) [ 4.582715] 1f00 3968 mtdblock0 [ 4.582724] (driver?) [ 4.589256] 1f01 64 mtdblock1 [ 4.589262] (driver?) [ 4.595906] 1f02 64 mtdblock2 [ 4.595912] (driver?) [ 4.602444] b300 7636800 mmcblk0 [ 4.602450] driver: mmcblk [ 4.609231] b301 7635776 mmcblk0p1 89708921-01 [ 4.609238] [ 4.616022] b308 4096 mmcblk0boot0 [ 4.616027] (driver?) [ 4.622811] b310 4096 mmcblk0boot1 [ 4.622817] (driver?) [ 4.629596] 0800 1953792 sda [ 4.629602] driver: sd [ 4.635695] 0801 1953761 sda1 169d3094-01 [ 4.635701] [ 4.642048] No filesystem could mount root, tried: [ 4.642051] ext3 [ 4.646922] ext4 [ 4.648837] ext2 [ 4.650757] vfat [ 4.652672] xfs [ 4.654592] [ 4.657900] Kernel panic - not syncing: VFS: Unable to mount root fs on "/dev/sda1" or unknown-block(8,1) Pulling the DTB from the drive, and decompiling, i do see SATA references: dtc -I dtb -O dts armada-3720-espressobin-ultra.dtb > armada-3720-espressobin-ultra.dts ... phy@18300 { compatible = "marvell,comphy-a3700"; reg = <0x18300 0x300 0x1f000 0x400 0x5c000 0x400 0xe0178 0x08>; reg-names = "comphy", "lane1_pcie_gbe", "lane0_usb3_gbe", "lane2_sata_usb3"; #address-cells = <0x01>; #size-cells = <0x00>; clocks = <0x04>; clock-names = "xtal"; ... sata@e0000 { compatible = "marvell,armada-3700-ahci"; reg = <0xe0000 0x178>; interrupts = <0x00 0x1b 0x04>; clocks = <0x02 0x01>; phys = <0x1e 0x00>; phy-names = "sata-phy"; status = "okay"; }; But i don't know enough to know why it's not initializing. the 2GB SDA above is clearly the USB drive.

Hi i have done a few boxes with armbian installed, some boxes wifi do not work but that is to be expected.But i got a amlogic box now that is giving me intrm error,It seems i can boot armbian and it loads up but after the loading it just get stuck at intrims.This has somethnig to do with the boot process from sd card.When i boot it form usb stick it works fine but the same setup from sd card gives me that error. I suspect the second part to boot the os is controlled by the box,I need to have first boot all the time What can i do to modify the sd card.

@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