All Activity

@Gwainer try these images https://github.com/NickAlilovic/build/releases/tag/20250306

@SecLyzer You can find everything you need here

@Nick A Is it possible that you can make a secure boot version of the X96Q V1.3 debian minimal or tell me, how I can build it myself on MX Linux (Debian based)? Never done this before yet and sadly, my X96Q (plus) is based on Allwinner H616 with a single MMC (1.5GB DDR3 RAM and 8GB ROM)

@jamesharton the Armbian images have been refreshed with the new DDR binary. Also thanks for sharing the pic.

I created this account just to thank you, man. Thank you so much, it worked perfectly here. Finally, my old TV box has another use besides collecting dust.

I wouldn't mind open source but the problem is their prices got bumped up because of the ram and storage shortages. It's why I'm asking if someone has managed to get armbian running on this specific Tv box model or a similar one that has an allwiner H618 chip at the very least.

Bump to uboot 2026.04 tested with kernel 7.0.5 no mods, just pure mainline Boot Logs: https://paste.armbian.com/ujumalanuc Github Pull request: https://github.com/armbian/build/pull/9807 Tested with kernel 7.0.6 Boot Logs: https://paste.armbian.com/jabokoqusa

extraargs=nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off to /boot/armbianEnv.txt fixes nvme detection the temperature is echo "$(( $(cat /sys/class/hwmon/hwmon0/temp1_input) / 1000 )) °C" if you copy the system to nvme and wanna boot with microsd (spi doesn't work for now): 1) it will actually boot but without boot mountpoint 2) mount /boot and /media/mmcboot manually 3) fix fstab

Wrote a PR to remedy the situation https://github.com/armbian/build/pull/9800

@humanus I took a second look at the log, I think it's probably due to the enabled eMMC. EDIT: I added the emmc part to my A7Z dts, it also crashes... So that's definitely the root cause. I disable it for A7S in my repo for now, you can compile it yourself with a Linux 6.18 kernel or wait for Nick. By the way A733 eMMC seems to use the same eMMC driver as A523, so probably mainline already supports it.

Wait for a few hours and see if it appears. My other theory, is that I removed the BCMHD DKMS driver and now the wifi is in a wrong state and hassling the CPU.

@meco hopefully this is clear enough for you.

I have no eMMC and the card isn't UHS-II (I use WD Purple cards, they are UHS-I). I don't think I have any UHS-II cards at the moment... Could try a different one though.

@rm_ On my RV2, there's no such load. Mine waits at the GDM3 login screen (Wayland), it's booted via NVME, no Wifi nor BT configured, and I have a shell via Ethernet. I see a difference in IPI4 dubbed "IRQ work interrupts" which may cause this but I have no clue about the real root cause. There's a patch with comments on that: https://patchew.org/linux/25833c44051f02ea2fd95309652628e2b1607a1e.camel@lenze.com/ , however I have not investigated which of the patches / corrections are in the actual 6.18.26-current-spacemit. I have 53/57° C temp with cat $(find /sys -name temp), I presume yours is higher... interrupts

@humanus Thanks, just noticed the log. Interestingly looks like it's the mmc part. A few things I can think of: 1. emmc is only presented on A7A/S, so if you are using emmc or your board has an emmc, it might be a problem. You can try to disable sdc2 on device tree and see if it works. 1. sd card part is the same on A7A/S/Z, but I don't think my card is a UHS-II card. Looking at the log, it might be doing something with UHS-II, so it might be worth trying a different SD card to see if it behaves differently. If it does turn out to be related to UHS-II handling, I can look into a proper fix later. on.

ok my findings root@rk3318-box:/boot# cat *Env.txt verbosity=1 bootlogo=true console=both overlay_prefix=rockchip fdtfile=rockchip/rk3318-box.dtb rootdev=UUID=a3e848f3-8d54-412d-9184-5bc40ab76686 rootfstype=ext4 overlays=hdmi-audio rk3318-box-cpu-hs rk3318-box-led-conf1 rk3318-box-wlan-ap6334 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u root@rk3318-box:/boot# sudo ln -s /usr/lib/firmware/brcm/brcmfmac4334-sdio.bin /usr/lib/firmware/brcm/brcmfmac4334-sdio.rockchip,rk3318-box.bin ### it was missing according the log sudo rm /usr/lib/firmware/brcm/brcmfmac4334-sdio.rockchip,rk3318-box.txt ### this one did not do the job , you could ofcourse backup ... sudo wget -O /usr/lib/firmware/brcm/brcmfmac4334-sdio.rockchip,rk3318-box.txt https://pastebin.com/raw/00gLSkKS ### the nvram hosted in this topic after the reboot the wifi worked fine for me

@alexc @qq20739111 I would be very surprised if the UART log showed anything other than mine. You can find it attached above.

Hi @qq20739111, Thanks for testing! It looks like your system may be getting stuck during boot. The SHA256 hash will change every time you rebuild the image. The best way to debug this is by connecting to the UART console, since it should show exactly where the boot process is failing. That said, I’ve also made some updates to the 6.18 kernel, including changes for the A7A and A7S device trees, along with enabling the Ethernet port. Unfortunately I don’t have either an A7A or A7S on hand, so I haven’t been able to test those changes myself. Nick hasn’t updated the Armbian build yet, but you can also try building the kernel yourself and manually replacing the kernel image and DTBs in the /boot directory for testing.

@Nick A I compiled the image for version 6.18.19 using the parameters you preset, but the system fails to boot correctly on the A7S. Upon power-up, the green LED stays solid for about 15 seconds. Then, the green LED flashes once, and the blue LED turns solid (unlike the official system where the blue LED blinks). After that, the system becomes unresponsive. There is no signal output on the DP interface, and the Ethernet port indicator light does not turn on even when a cable is connected. Here is the hash value of the compiled file. I'm not sure if there was an issue with my compilation process, as the network connection dropped several times, and it took a few attempts to finally complete the build. Image: Armbian-unofficial_26.02.0-trunk_Radxa-cubie-a7s_trixie_edge_6.18.19_xfce_desktop.img sha256: a7c6baf463b233bad0abb08d2fcfde7ac107509d69fada77ebaafc2bd00979c5

perhaps the patch is no longer necessary once this lands upstream. We will see once we get there

It is not that one. The 2.0 load was just cosmetic, the CPU was actually idle. But with this one it is actually doing something, which is also increasing heat (if no fan). With the expanded core list, you can see the CPU5 and CPU7 have "system" load of 49% and 36%. On a fully idle system. Interrupts file attached. It seems pretty normal to me. interrupts

If i recall correctly this patch is causing problems: patch/kernel/archive/rockchip64-7.0/rk3588-1221-arm64-fix-typec-for-orangepi-5-5b.patch After split the code it wants to patch has will be moved from arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi to arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi Anyway I'm not sure what this patch meant to fix. Can't find much info on it but it looks like the altmodes block is advertising DP mode over USB-C so enables port to transmit direct video and audio signals. Please someone correct me on this one if I'm wrong. If so it adds future to the system rather then fixing it. I think its better to leave it at default source - host mode.

Why should they?

I was just giving heads up. Basically patch is ready with only few "naming disagreements" and reviewers wants to push it upstream soon probably still within 7.1 release candidate. Once it will happen all the builds for orange pi 5/5b/pro and so on will fail so its worth to be prepared.

Hi Werner. I have done so already around half an hour ago.