All Activity

@GBEM , Hi are you sure wifi is attached to sdmmc1 ? here is my log: root@h96-tvbox-3566:~# dmesg | grep -i sdio [ 2.961741] mmc2: new UHS-I speed SDR50 SDIO card at address 390b [ 12.974586] aicbsp: aicbsp_sdio_probe:1 vid:0xC8A1 did:0x0082 [ 12.977567] aicbsp: aicbsp_sdio_probe:2 vid:0xC8A1 did:0x0182 [ 12.977586] aicbsp: aicbsp_sdio_probe after replace:1 [ 12.977595] aicbsp: aicbsp_get_feature, set FEATURE_SDIO_CLOCK 150 MHz [ 12.977600] aicbsp: aicwf_sdio_reg_init [ 12.993394] rwnx_load_firmware :firmware path = /lib/firmware/aic8800_fw/SDIO/aic8800D80/fw_patch_table_8800d80_u02.bin [ 13.093862] rwnx_load_firmware :firmware path = /lib/firmware/aic8800_fw/SDIO/aic8800D80/fw_adid_8800d80_u02.bin [ 13.127689] rwnx_load_firmware :firmware path = /lib/firmware/aic8800_fw/SDIO/aic8800D80/fw_patch_8800d80_u02.bin [ 13.143887] rwnx_load_firmware :firmware path = /lib/firmware/aic8800_fw/SDIO/aic8800D80/fw_patch_8800d80_u02_ext0.bin [ 13.400664] rwnx_load_firmware :firmware path = /lib/firmware/aic8800_fw/SDIO/aic8800D80/fmacfw_8800d80_u02.bin [ 14.275914] aicbsp: aicbsp_get_feature, set FEATURE_SDIO_CLOCK 150 MHz [ 14.275939] aicsdio: aicwf_sdio_reg_init [ 14.284873] aicbsp: aicbsp_get_feature, set FEATURE_SDIO_CLOCK 150 MHz [ 14.305375] aicbsp: sdio_err:<aicwf_sdio_bus_pwrctl,1404>: bus down [ 439.182900] aicwf_sdio mmc2:390b:1 wlan0: CLOSE [ 520.391280] aicwf_sdio mmc2:390b:1 wlan0: CLOSE [ 683.043492] aicwf_sdio mmc2:390b:1 wlan0: CLOSE It seems attached to sdmmc2, then in case there is a need a possible device tree could be (73 is 2 B1 as in your file): &sdmmc2 { bus-width = <4>; non-removable; cap-sdio-irq; keep-power-in-suspend; reset-gpios = <&gpio2 9 GPIO_ACTIVE_HIGH>; /* gpio-73 */ status = "okay"; };

UPDATE for Multitool Finally I managed to let the Opensource OP-TEE work with the rockchip miniloader! This means that the Multitool should now work on any board, without freezes and booting issues! The new version can be downloaded from the first page of this thread. Please report if it works for you, thanks!

I updated to Armbian 26.2.1 on OPi5, and it can't boot from MTD (rootfs at NVMe), and I have to use SD card to boot to NVMe as workaround. After looking into this issue, I found rkspi_loader.img is no longer available for current (6.18.8 kernel) u-boot pkg and armbian-config flashes u-boot-rockchip-spi.bin ( or similar sata version) to /dev/mtdblock0 and I think this is wrong image for MTD bootloader. If I use older vendor image, which u-boot pkg has rkspi_loader.img, system can boot to NVMe rootfs and I notice that /dev/mtdblock0 has several gpt partitions including u-boot one, and flashing u-boot-rockchip-spi.bin erases partitions in SPI flash. I noticed that several related changes were introduced since 25.11, such as https://github.com/armbian/build/commit/e5b845f9432abb0408287599bba5889a86e6d068 , but I couldn't do quick fix to bring back working rkspi_loader.img because I am not familiar with whole armbian build. One thing to note that if board was flashed with old rkspi_loader.img and not updated with 26.2 MTD image, it still boots to NVMe rootfs, but I have other issues such as video playback not working with 6.18 kernel likely due to mismatch u-boot and kernel version leading to wrong HW initialization. BTW, I checked 26.2 u-boot pkg for Rock 5B (similar rk3588 board), and rkspi_loader.img is still included.

@jock Hi, I have updated the build source for the leds overlay files (leds 6 and 7) for both the the rockchip64 H50 tvbox and the T9 tvbox, for kernels 6.12 (old non scrolling driver) and 6.18 (new scrolling driver) the version for 6.18 is also fine for 6.19. Have a look at my fork in https://github.com/gpaesano/build. Some modifications are just refinements other are functional. I have built all the images and variants on a ubuntu linux and are running well. I am not familiar with pull requests and do not want to be impolite, so If you think there is some added value please support it. All the best @GmP

If anyone is still interested, I have a Helios 64 that I assembled, looked at, but never got around to using for more than a couple hours. Works fine, does not yet have the 2.5GB fix but I have the instructions for same. No idea what to ask for it but it certainly isn't doing me any good sitting on my shelf. Have the manual, SATA drive bay adapters for 2.5" drives and the like. Make me an offer and pay shipping from Oregon. Let's talk!

https://github.com/armbian/community/releases/download/26.2.0-trunk.385/Armbian_community_26.2.0-trunk.385_Rk3318-box_trixie_current_6.18.8_minimal.img.xz this is the latest console build compatible with T9. You will need to configure a little bit the environment after booting to enable all the features via ssh and wired lan. If the device is still on android the best is to follow the tutorial from @jock in

@rafman pmic is axp1530 via device info HW app

I am not sure what have you implemented to make armbian supports rk3288. And it make me unsure if "apt update && apt upgrade" if safe. Are there system packages I shouldn't upgrade (maybe kernel or hardware-specific tools...)?

This is the official armbian page with nightly images for all targets (supported and community)

Have a look here: https://k-space.ee.armbian.com/archive/xt-q8l-v10/archive/

Hi, jock! Just have installed Armbian_24.2.5_Xt-q8l-v10_bookworm_current_6.6.22.img.xz on my old cs928 tvbox. I have found the image in armbian archives. And it works fine for me. I just need linux headless server. Can I ask you 2 questions? 1. How can I create Multitool compatible backup using dd (or other cmdline commands)? I want to automate backup'ing through cron or systemd timers. 2. I am not sure what have you implemented to make armbian supports rk3288. And it make me unsure if "apt update && apt upgrade" if safe. Are there system packages I shouldn't upgrade (maybe kernel or hardware-specific tools...)?

burn20260208.LOG

Me neither have any clue about. Surely the problem lays in the closed source proprietary binary Trust OS. It does or expects something and then locks the system with that typical string [2accGZ3... which is probably known only to rockchip engineers. Unfortunately I don't have any board here that exhibit the same behaviour, so the issue is hard to study. To avoid issues with updates, you may want to put the u-boot package on hold using apt-mark hold, so in case of updates, the bootloader won't get updated and you'll be fine.

@macros muniz try this: https://www.123865.com/s/96P8Vv-KmR0H Code: cNU2

Thank you. I couldn't even think of such a thing. Lord, why is it necessary to preserve the state of indicators that are needed precisely to show the state of something?

@Nick A No problem. Thanks for your Armbian build as well! I am also looking forward to mainline. Currently I still didn't find open source Mesa driver for Allwinner BSP, GLES is only available as pre-compiled binary for Debian (haven't tested it but it's in the Radxa images). There already are mainline Mesa/Linux IMG GPU supports so I hope things can be ported to mainline soon. Please let me know if anyone finds the source code for Mesa BSP.

The second time I built it, the image deb worked and the bcmdhd dkms loaded. > dkms status bcmdhd-spacemit-sdio/101.10.591.84.37-4, 6.18.9-edge-spacemit, riscv64: installed

@jock THAT WORKED!!! I have no idea why, or how, but that worked. Thanks for all the help. Do you think I'll have any problems in the future when updating the OS?

@alexc Thanks for your patch and suggestions. It turns out the DRM heap isn't strictly required for DisplayPort Alt mode, but I'm sure it resolved other issues within the 6.6 kernel. I assumed it was the DRM heap because it was the only missing kernel configuration option. I suppose the kernel doesn't report missing source code drivers, or I simply didn't notice. It’s great to have your help getting this Armbian BSP build function. At least until a mainline version is released

There's an Armbian provided SystemD service named armbian-led-state with the following description: # Armbian led state save and restore # Stores the current led state at shutdown and restores # it during bootstrap Maybe that's it? If so, you could disable it if it bothers you? Or adjust the script it calls at /usr/lib/armbian/armbian-led-state-save.sh?

All things are possible. The question is who's interested in doing (or funding) the work, and if technical data is available to do it. The build system is at https://github.com/armbian/build. If you know how to build a kernel, device tree, and bootloader, you can define how to do those steps there.

Bookworm. But my point was the version 35.1 is what got installed when I ran the scripts in the first post. If the script installed 37 for you because you're on Ubuntu then I probably am on the wrong track. Yes I believe it does this. I was just pointing out that drm_prime works for me but I guess that could just be due to different hardware on the device. I'm not using an Orange Pi.

The issues are definitely related to the Trust OS, as you already noticed in your experiments. You need a build with a different bootloader that contains a different Trust OS or the Opensource TEE, which has no issues so far. An old rk322x_tee.bin file can be found in this old commit, if you want to build an armbian image/bootloader by yourself: substitute it with the existing rk322x_tee.bin and try building an image.

Hi, @jock, thanks for the suggestion. I changed the baud rate to 115200bps and indeed it is sending things. This is what I got: DDR Version V1.11 20200910_dbg In ID:0xFFF 333MHz LPDDR3 Bus Width=32 Col=11 Bank=8 Row=14 CS=1 Die Bus-Width=32 Size=1024MB mach:4 OUT U-Boot SPL 2025.10-rc5_armbian-2025.10-rc5-S2f2a-P4b2d-Hcd62-Vd309-B2eb2-R448a (Jan 28 2026 - 04:12:44 +0000) Trying to boot from MMC2 INF [0x0] TEE-CORE:init_primary_helper:377: Initializing (1.1.0-333-gc9d95d1 #2 2018年 08月 17日 星期五 03:32:22 UTC arm) INF [0x0] TEE-CORE:init_primary_helper:378: Release version: 2.0 INF [0x0] TEE-CORE:init_primary_helper:379: Next entry point address: 0x61000000 [2accGZ3G��غ��ؾeػؼ Since the SPL is alive, it proves the internal flash is readable. Does this specific freeze point suggest a DTB issue or something related to the op-tee/trust partition? Should I try a different v_sel (voltage selector) or a specific u-boot branch for this board?

@Brow Mosh AI is wrong. Mainline supports - Your PMIC - Your DRAM timing - Your HDMI (Patches have been around for years but not accepted in mainline yet. I included it in my builds.) - Your regulators Supported in mainline but might need some dts changes. - Your weird SD wiring - Your eMMC layout ( Could be a gpio# issue) If you are booting into the kernel then I believe your SD is somewhat working. Maybe you need few tweaks to your dts or your DRAM settings are off. A failing or cheap SD card could also be your issue. Kernel boots Reaches userspace Shows login banner Without a DTS I can’t help you much. Also, can you post some boot logs. FEL over USB is your last option. It is possible. But I don't think your AI model will help much. I noticed with some AI models they will encourage you to quit when they can't find the correct information. The owner of the AI model wants you to pay for their deep learning version.