All Activity

Additional Tip: The sync command: Btw - an additional tip, whenever you're copying files or images, it's a good idea to finish it off with the sync command. When using cp or dd, the prompt returns when the CPU portion of the copying is done, but that doesn't necessarily mean that the final data buffer has finished transferring its data to the drive or device. The sync command holds and only returns the prompt once the buffer has finished copying to the drive or device. Note that if you're copying a batch of files, the sync command will return only when the current file has finished, not necessarily the entire batch.

"if you have ever booted a different distribution then your box will be incompatible with the Armbian build" are you serious? No matter after all this linux on arm shit problems i had last week, i really must say that a windows 10 + kodi.exe on a thin client is really the best in quality (dxva) and stability. And it only eats 1-2w more power than this u1 thingie. So, i just keep my moonlight on windows and put tvheadend together with the wintv solohd into a vmware player. bye bye.

Great!! I'm glad you got it working!

SteeMan - OK - so as a total non-developer, I will steer clear of 'mainline kernels (at least until I can learn some more😀 TallMan - I only wish everyone online was as helpful as you have been. I actually got the thing to work using your instructions, which is a first for me using online 'help'. I no longer have a useless brick. I have a red/blue flashing LED, a working desktop, and (now) a need to learn something about Armbian - this being my first sight of it. Some of it looks familiar from Mint due to the Debian heritage I also want to learn how to make the OPi boot from either the EMMC or the SDD, as I understand this is much faster - although it works, booting from the SD card clearly doesn't do justice to the OPi hardware (and life is too short😀. Thanks to all who responded - you all helped. Keith

You should also be updating your /etc/apt/sources.list.d/armbian.list as well (otherwise you will be mixing bookworm armbian packages with trixie debian packages)

First off, why do you want to? As the name 'edge' should imply, edge kernels are development kernels that are for testing purposes and may or may not work, and may break at any time. 'current' 6.12 in your case are LTS kernels that should be stable and more suited for non-development/testing use cases. If you do want edge kernels then you can use armbian-config to switch.

Lack of feature implementation, not a bug. 6.1 is the vendor supplied kernel where most things will work, but the vendor doesn't provide support. 6.12 is linux mainline kernel, where much functionality may be missing (as the vendor doesn't work to get their features into mainline linux, but relies on others (volunteer opensource developers) to do their work for them).

Per the install instructions on this site, if you have ever booted a different distribution then your box will be incompatible with the Armbian build. Although it is generally using coreelec builds that will do this. I don't know about the libreelec builds. Also you need to provide a lot more information about what you are doing. There are a number of steps in installing armbian on a TV box and you haven't specified any of the steps you performed. Finally debugging boot issues often requires that you find the debug serial console connection on the board and hook up a usb uart reader to get at the boot messages.

I recently updated from bookworm to trixie, here's how i did it: commands: sudo apt update sudo apt upgrade -y sudo cp -p /etc/apt/sources.list /etc/apt/sources.list.bak sudo sed -i 's,bookworm,trixie,g' /etc/apt/sources.list sudo apt dist-upgrade /etc/apt/sources.list : deb http://deb.debian.org/debian trixie main contrib non-free non-free-firmware # deb-src http://deb.debian.org/debian trixie main contrib non-free non-free-firmware deb http://deb.debian.org/debian trixie-updates main contrib non-free non-free-firmware # deb-src http://deb.debian.org/debian trixie-updates main contrib non-free non-free-firmware deb http://deb.debian.org/debian trixie-backports main contrib non-free non-free-firmware # deb-src http://deb.debian.org/debian trixie-backports main contrib non-free non-free-firmware deb http://security.debian.org/ trixie-security main contrib non-free non-free-firmware # deb-src http://security.debian.org/ trixie-security main contrib non-free non-free-firmware

My setup is still running, yay! I even updated to Trixie and all worked out fine. But I'm stuck on edge kernel 6.12.x, I saw that rolling had 6.16.x. So how do I install/convert to the rolling 6.16.x edge kernel ?

Thanks again for the inputs - I'm slowly working through the instructions, and hopefully learning. TallMan is right - I meant 1 TB, not 1 GB - (it was tiring day!) I'm not really bothered at this stage with which OS Image I use - My original intention was to get the thing going, then eventually try each available OS until I found something I could live with. Normally I use Linux Mint on my desktop computer (user - not nerd!), so this was why Ubuntu came to the top of the pile for testing because of the common Debian background, but not necessarily as the 'finished' job. I more or less did as suggested above (using the Orange Ubuntu 'Official' download. As noted, I seem to have had a dead SD card, and did not have the error reported after validation after I got a new card - but the odd thing now is that although the old 'faulty' SD card at least produced a 'splash' screen, the new card does nothing - the OPi just does a good imitation of a warm brick. I did the SHA check, and the Etcher validation was OK, so presumably the burnt image was OK (?). I'll work through Tall Mans instructions, and see what happens, and report back - thanks for the detailed description - its more useful than many people realise to someone who doesn't do this sort of thing every day. Just out of curiosity - is the 'no-video output' of Armbian 6.12 a bug (as I suspect) or deliberate - and if so why? Thanks again for the help. Keith

To maintain changes between different kernel versions, you can use overlays. I did this by following some dts changes from @ebin-dev. Add this line user_overlays=rockchip-rk3399-op1-opp rockchip-rk3399-l2-cache to /boot/armbianEnv.txt Copy the dtbo files to /boot/overlay-user (mkdir -p /boot/overlay-user if the folder does not exist). rockchip-rk3399-l2-cache.dtborockchip-rk3399-op1-opp.dtborockchip-rk3399-op1-opp.dtsrockchip-rk3399-l2-cache.dts

@ebin-dev not sure with your cpufreq settings as it should be 40000 otherwise the regulator cannot ramp-up the voltage so quickly. regulator@40 { compatible = "silergy,syr827"; reg = <0x40>; fcs,suspend-voltage-selector = <0x01>; pinctrl-names = "default"; pinctrl-0 = <0x83>; regulator-name = "vdd_cpu_b"; regulator-min-microvolt = <0xadf34>; regulator-max-microvolt = <0x16e360>; regulator-ramp-delay = <0x9c40>; regulator-always-on; regulator-boot-on; vin-supply = <0x82>; phandle = <0x0e>; regulator-state-mem { regulator-off-in-suspend; }; }; I have been using Helios64 for few years without any issues (four years ago, when I detected instability, I disabled the a72 cluster and continue only with updates, without any problems). Now that I have upgraded my network to 10 Gbits, I am experiencing problems with the 2.5 Gbits network card, which I did not use previously (link https://forum.armbian.com/topic/43858-helios-64-network-issues-with-armbian-2453-on-kernel-6639-frequent-disconnects/#findComment-225220 ). My theory is that the instability also affects USB 3.0 and RTL8156, causing crashes and triggering the watchdog. I also tried connecting an active switch to type C with an external RTL8156BG, and the watchdog was also triggered (some transmission errors, not many, but some). So I can confirm that with the a72 cluster and the 2.5 Gbit network card disabled, you have an extremely stable NAS (now with kernel 6.12.44). Does anyone have a damaged or non-functioning helios64 motherboard they can send?

Hello, i tried "Armbian_community_25.11.0-trunk.208_Aml-s9xx-box_plucky_edge_6.16.7_xfce_desktop.img" booting from a usb stick. First it looked, that it loads (the minix logo disappeared for some 100ms) which indicates that it loads, but then at the end the internal android booted. For comparison "LibreELEC-AMLGX.aarch64-13.0-nightly-20250926-2f25ce3-box.img.gz" booted fine, even from the sdcard slot. My final goal is, to run "tvheadend" as server with a "Hauppauge WinTV-soloHD" Usb STick and "Moonlight" client for "sunshine" on a 1280x1024@60hz nec display. Can anybody pls tell me what i must download? Thx.

@JaydenWithaWhy I rebuilt and uploaded again a new copy of the multittol. Please download and try again, I tested successfully on a tvbox of mine and worked fine.

Hello, and thank you for the suggestions. Just to clarify, I am not using an ILI9341 or ST7789 display. My display is a ST7735S (1.8", 128x160), a generic model purchased from AliExpress. The main issue is that while this setup worked perfectly on older Armbian kernels, it's no longer working with the current Kernel 6.12.x. It seems like the necessary module might have been removed or changed in the newer versions. I am not using a desktop environment; my goal is to use the display directly from the console/framebuffer (no X11). I’ve made some progress, but now I’m stuck. Here’s what I'm observing: The system does create a framebuffer device at /dev/fb0. When I use a tool like fbi to show an image, it runs without any errors. If I try to dump the framebuffer device (e.g., cat /dev/fb0), it outputs data, which suggests something is being written to the buffer. The problem is on the physical display itself: the screen's backlight turns on, but it remains completely blank (white). No image is ever displayed. I'm unfortunately not sure how to proceed from here. It feels like the display is being initialized enough to turn on the backlight, but the actual image data isn't being displayed correctly. I suspect the driver is not sending the right commands. Does anyone have an idea what I could try next? Thank you!

@FucusMeDeep don't throw yourself into this, I'm not the best example to be messing with junk, but times have changed, if it were really interesting I would recommend it. with that time and money I buy a board https://www.banana-pi.org/ anything that involves reinventing the wheel there is already ready, don't use material discarded by someone else. develop something on top of these boards, go further create something at a higher level than what you want to create. do this project with a more documented and healthy board: CH573F from Nanjing Qinheng Microelectronics Part of the document's included below: WCH 官方网站 www.wch.cn(zh-CN) / www.wch-ic.com(en) 时钟和电源 时钟： 32Mhz HSE 高速无源晶体输入 32.768k LSE 低速无源晶体输入 电源： 3.3V-5.5V电源输入，3.3V LDO最大100mA额外输出 USB电源串有二极管，防止电流倒灌 同时二极管可以通过短路焊盘旁路 5V带有TVS二极管 接口和按键 接口： 12Pin 2.54mm间距 I/O接口 * 2 按键： 复位/B23按键 * 1 Boot/B22按键 * 1

@RealAn DTS for Kernel 6.1: // SPDX-License-Identifier: (GPL-2.0+ OR MIT) /* * Copyright (c) 2024 Rockchip Electronics Co., Ltd. * Copyright (c) 2024 Radxa Computer (Shenzhen) Co., Ltd. * */ /dts-v1/; #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/pinctrl/rockchip.h> #include <dt-bindings/input/rk-input.h> #include <dt-bindings/display/rockchip_vop.h> #include "rk3576.dtsi" #include "rk3576-android.dtsi" #include "rk3576-rk806.dtsi" #include "rk3576-virtual-poweroff.dtsi" / { model = "Rockchip RK3576 EVB1 V10 Board"; compatible = "rockchip,rk3576-evb1-v10", "rockchip,rk3576"; vcc_sys: vcc5v0-sys { compatible = "regulator-fixed"; regulator-name = "vcc_sys"; regulator-always-on; regulator-boot-on; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; }; vcc_2v0_pldo_s3: vcc-2v0-pldo-s3 { compatible = "regulator-fixed"; regulator-name = "vcc_2v0_pldo_s3"; regulator-boot-on; regulator-always-on; regulator-min-microvolt = <2000000>; regulator-max-microvolt = <2000000>; vin-supply = <&vcc_sys>; }; vcc_1v1_nldo_s3: vcc-1v1-nldo-s3 { compatible = "regulator-fixed"; regulator-name = "vcc_1v1_nldo_s3"; regulator-boot-on; regulator-always-on; regulator-min-microvolt = <1100000>; regulator-max-microvolt = <1100000>; vin-supply = <&vcc_sys>; }; vcc_1v8_s0: vcc-1v8-s0 { compatible = "regulator-fixed"; regulator-name = "vcc_1v8_s0"; regulator-boot-on; regulator-always-on; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; vin-supply = <&vcc_1v8_s3>; }; vcc_3v3_s0: vcc-3v3-s0 { compatible = "regulator-fixed"; regulator-name = "vcc_3v3_s0"; regulator-boot-on; regulator-always-on; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; vin-supply = <&vcc_3v3_s3>; }; vcc5v0_host: vcc5v0-host { compatible = "regulator-fixed"; regulator-name = "vcc5v0_host"; regulator-boot-on; regulator-always-on; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; enable-active-high; gpio = <&gpio0 RK_PC7 GPIO_ACTIVE_HIGH>; pinctrl-names = "default"; pinctrl-0 = <&usb_host_pwren>; vin-supply = <&vcc_sys>; }; vcc5v0_otg: vcc5v0-otg { compatible = "regulator-fixed"; regulator-name = "vcc5v0_otg"; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; enable-active-high; gpio = <&gpio2 RK_PD2 GPIO_ACTIVE_HIGH>; pinctrl-names = "default"; pinctrl-0 = <&usb_otg_pwren>; vin-supply = <&vcc_sys>; }; hdmi_sound: hdmi-sound { compatible = "rockchip,hdmi"; rockchip,mclk-fs = <128>; rockchip,card-name = "rockchip-hdmi"; rockchip,cpu = <&sai6>; rockchip,codec = <&hdmi>; rockchip,jack-det; }; gpio-keys { compatible = "gpio-keys"; autorepeat; power { debounce-interval = <100>; gpios = <&gpio0 RK_PD3 GPIO_ACTIVE_LOW>; label = "GPIO Key Power"; linux,code = <KEY_POWER>; wakeup-source; }; }; leds: leds { compatible = "gpio-leds"; work-green { gpios = <&gpio0 RK_PD1 GPIO_ACTIVE_LOW>; linux,default-trigger = "backlight"; default-state = "on"; retain-state-suspended; retain-state-shutdown; }; work-red { gpios = <&gpio0 RK_PD0 GPIO_ACTIVE_HIGH>; linux,default-trigger = "backlight"; default-state = "on"; retain-state-suspended; retain-state-shutdown; }; pwr-wifi { gpios = <&gpio1 RK_PC6 GPIO_ACTIVE_HIGH>; linux,default-trigger = "none"; default-state = "on"; retain-state-suspended; }; }; sdio_pwrseq: sdio-pwrseq { compatible = "mmc-pwrseq-simple"; pinctrl-names = "default"; pinctrl-0 = <&wifi_poweren_gpio>; /* * On the module itself this is one of these (depending * on the actual card populated): * - SDIO_RESET_L_WL_REG_ON * - PDN (power down when low) */ post-power-on-delay-ms = <200>; reset-gpios = <&gpio0 RK_PD2 GPIO_ACTIVE_LOW>; status = "okay"; }; wireless_bluetooth: wireless-bluetooth { compatible = "bluetooth-platdata"; uart_rts_gpios = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>; pinctrl-names = "default", "rts_gpio"; pinctrl-0 = <&uart4m1_rtsn>; pinctrl-1 = <&uart4m1_rts_gpio>; BT,wake_gpio = <&gpio1 RK_PD4 GPIO_ACTIVE_HIGH>; // BT,reset_gpio = <&gpio1 RK_PC7 GPIO_ACTIVE_HIGH>; BT,wake_host_irq = <&gpio0 RK_PB1 GPIO_ACTIVE_HIGH>; status = "okay"; }; wireless_wlan: wireless-wlan { compatible = "wlan-platdata"; pinctrl-names = "default"; pinctrl-0 = <&wifi_host_wake_irq>; WIFI,host_wake_irq = <&gpio0 RK_PB0 GPIO_ACTIVE_HIGH>; status = "okay"; }; ht5010_sound_out: ht5010_sound-out { compatible = "rockchip,dummy-codec"; clocks = <&mclkout_sai1>; clock-names = "mclk"; pinctrl-names = "default"; pinctrl-0 = <&sai1m0_mclk>; #sound-dai-cells = <0x00>; status = "okay"; }; ht5010-sound { compatible = "simple-audio-card"; simple-audio-card,mclk-fs = <256>; simple-audio-card,name = "rockchip,es8388"; simple-audio-card,format = "i2s"; status = "okay"; simple-audio-card,cpu { sound-dai = <&sai1>; }; simple-audio-card,codec { sound-dai = <&ht5010_sound_out>; }; }; spdif_tx0_dc: spdif-tx0-dc { compatible = "linux,spdif-dit"; #sound-dai-cells = <0x00>; status = "okay"; }; spdif-tx0-sound { compatible = "simple-audio-card"; simple-audio-card,mclk-fs = <128>; simple-audio-card,name = "rockchip,spdif-tx1"; status = "okay"; simple-audio-card,dai-link@0 { cpu { sound-dai = <&spdif_tx1>; }; codec { sound-dai = <&spdif_tx0_dc>; }; }; }; }; &cpu_l0 { cpu-supply = <&vdd_cpu_lit_s0>; }; &cpu_b0 { cpu-supply = <&vdd_cpu_big_s0>; }; &crypto { status = "okay"; }; &gpu { mali-supply = <&vdd_gpu_s0>; status = "okay"; }; &iep { status = "okay"; }; &iep_mmu { status = "okay"; }; &jpegd { status = "okay"; }; &jpege { status = "okay"; }; &jpeg_mmu { status = "okay"; }; &mpp_srv { status = "okay"; }; &rga2_core0 { status = "okay"; }; &rga2_core0_mmu { status = "okay"; }; &rga2_core1 { status = "okay"; }; &rga2_core1_mmu { status = "okay"; }; &rknpu { rknpu-supply = <&vdd_npu_s0>; status = "okay"; }; &rknpu_mmu { status = "okay"; }; &rkvenc_ccu { status = "okay"; }; &rkvenc0 { status = "okay"; }; &rkvenc0_mmu { status = "okay"; }; &rkvenc1 { status = "okay"; }; &rkvenc1_mmu { status = "okay"; }; &rkvdec { status = "okay"; }; &rkvdec_mmu { status = "okay"; }; &saradc { status = "okay"; vref-supply = <&vcca_1v8_s0>; }; &tsadc { status = "okay"; }; &vdpp { status = "okay"; }; &vop { status = "okay"; disable-win-move; vop-supply = <&vdd_logic_s0>; }; &vop_mmu { status = "okay"; }; &vp0 { rockchip,plane-mask = <(1 << ROCKCHIP_VOP2_CLUSTER0 | 1 << ROCKCHIP_VOP2_ESMART0 | 1 << ROCKCHIP_VOP2_CLUSTER1 | 1 << ROCKCHIP_VOP2_ESMART1)>; rockchip,primary-plane = <ROCKCHIP_VOP2_ESMART0>; cursor-win-id = <ROCKCHIP_VOP2_ESMART1>; }; &vp1 { status = "disabled"; }; &vp2 { status = "disabled"; }; &display_subsystem { clocks = <&hdptxphy_hdmi>; clock-names = "hdmi0_phy_pll"; }; &hdmi { status = "okay"; cec-enable = <1>; audio-no-capture; enable-gpios = <&gpio2 RK_PB0 GPIO_ACTIVE_HIGH>; }; &hdmi_in_vp0 { status = "okay"; }; &hdmi_in_vp1 { status = "disabled"; }; &hdmi_in_vp2 { status = "disabled"; }; &hdptxphy_hdmi { status = "okay"; }; &route_hdmi { status = "okay"; connect = <&vp0_out_hdmi>; }; &gmac0 { /* Use rgmii-rxid mode to disable rx delay inside Soc */ phy-mode = "rgmii-rxid"; clock_in_out = "output"; snps,reset-gpio = <&gpio2 RK_PB3 GPIO_ACTIVE_LOW>; snps,reset-active-low; snps,reset-delays-us = <0 20000 100000>; pinctrl-names = "default"; pinctrl-0 = <&eth0m0_miim &eth0m0_tx_bus2 &eth0m0_rx_bus2 &eth0m0_rgmii_clk &eth0m0_rgmii_bus &ethm0_clk0_25m_out>; tx_delay = <0x1b>; /* rx_delay = <0x3f>; */ phy-handle = <&rgmii_phy0>; status = "okay"; }; &mdio0 { rgmii_phy0: phy@1 { compatible = "ethernet-phy-ieee802.3-c22"; reg = <0x1>; clocks = <&cru REFCLKO25M_GMAC0_OUT>; }; }; &sai1 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&sai1m0_lrck &sai1m0_sclk &sai1m0_sdi0 &sai1m0_sdo2>; }; &sai6 { status = "okay"; }; &sdmmc { max-frequency = <200000000>; no-sdio; no-mmc; bus-width = <4>; cap-mmc-highspeed; cap-sd-highspeed; disable-wp; sd-uhs-sdr104; vqmmc-supply = <&vccio_sd_s0>; status = "okay"; }; &combphy0_ps { status = "okay"; }; &combphy1_psu { status = "okay"; }; &u2phy0 { status = "okay"; }; &u2phy0_otg { phy-supply = <&vcc5v0_otg>; status = "okay"; }; &usb_drd0_dwc3 { extcon = <&u2phy0>; dr_mode = "otg"; status = "okay"; }; &usbdp_phy { rockchip,dp-lane-mux = <2 3>; status = "okay"; }; &usbdp_phy_dp { status = "disabled"; }; &usbdp_phy_u3 { status = "okay"; }; &u2phy1 { status = "okay"; }; &u2phy1_otg { phy-supply = <&vcc5v0_host>; status = "okay"; }; &usb_drd1_dwc3 { dr_mode = "host"; status = "okay"; }; &pinctrl { usb { usb_host_pwren: usb-host-pwren { rockchip,pins = <0 RK_PC7 RK_FUNC_GPIO &pcfg_pull_none>; }; usb_otg_pwren: usb-otg-pwren { rockchip,pins = <0 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>; }; }; wireless-bluetooth { uart4m1_rts_gpio: uart4m1-rts-gpio { rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>; }; }; wireless-wlan { wifi_host_wake_irq: wifi-host-wake-irq { rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_down>; }; wifi_poweren_gpio: wifi-poweren-gpio { rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_up>; }; }; }; &sdhci { bus-width = <8>; no-sdio; no-sd; non-removable; max-frequency = <200000000>; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe; full-pwr-cycle-in-suspend; status = "okay"; }; &sdio { max-frequency = <200000000>; no-sd; no-mmc; bus-width = <4>; disable-wp; cap-sd-highspeed; cap-sdio-irq; keep-power-in-suspend; mmc-pwrseq = <&sdio_pwrseq>; non-removable; pinctrl-names = "default"; pinctrl-0 = <&sdmmc1m0_bus4 &sdmmc1m0_clk &sdmmc1m0_cmd>; sd-uhs-sdr104; status = "okay"; }; &spdif_tx1 { pinctrl-names = "default"; pinctrl-0 = <&spdifm1_tx1>; status = "okay"; }; &uart4 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&uart4m1_xfer &uart4m1_ctsn>; }; &pwm0_2ch_0 { compatible = "rockchip,remotectl-pwm-v4"; pinctrl-names = "default"; pinctrl-0 = <&pwm0m0_ch0>; remote_pwm_id = <0>; handle_cpu_id = <1>; remote_support_psci = <0>; wakeup-source; status = "okay"; ir_key1 { rockchip,usercode = <0xfeaa>; rockchip,key_table = <0xec 0xe8 0xe6 0x9e 0xe9 0x67 0xe5 0x6c 0xae 0x69 0xaf 0x6a 0xee 0x66 0xe7 0x73 0xef 0x72 0xbf 0x74 0xbe 0x71 0xb3 0x8b 0xff 0x184 0xb1 0x18e 0xf2 0x18f 0xf3 0x04 0xb5 0x05 0xf6 0x06 0xf7 0x07 0xb9 0x190 0xfa 0x191 0xfb 0x0a 0xfe 0x0b 0xbd 0x0e 0xbc 0xb7 0xf0 0xba 0xb4 0x19c 0xb8 0x1e 0xb0 0x197>; }; ir_key2 { rockchip,usercode = <0xff00>; rockchip,key_table = <0xf1 0x69 0xe5 0x6a 0xfc 0x67 0xfd 0x6c 0xf8 0xe8 0xf9 0xb8>; }; ir_key3 { rockchip,usercode = <0x1dcc>; rockchip,key_table = <0xee 0xe8 0xf0 0x9e 0xf8 0x67 0xbb 0x6c 0xef 0x69 0xed 0x6a 0xfc 0x66 0xf1 0x73 0xfd 0x72 0xb7 0xd9 0xff 0x74 0xf3 0x71 0xbf 0x8b 0xf9 0x191 0xf5 0x192 0xb3 0x184 0xbe 0x02 0xba 0x03 0xb2 0x04 0xbd 0x05 0xf9 0x06 0xb1 0x07 0xfc 0x08 0xf8 0x09 0xb0 0x0a 0xb6 0x0b 0xb5 0x0e>; }; ir_key4 { rockchip,usercode = <0x7f80>; rockchip,key_table = <0xec 0xe8 0xd8 0x9e 0xc7 0x67 0xbf 0x6c 0xc8 0x69 0xc6 0x6a 0x8c 0x66 0x78 0x73 0x76 0x72 0x7e 0x74 0x7c 0x8b 0xb7 0x184>; }; ir_key5 { rockchip,usercode = <0xfe01>; rockchip,key_table = <0xec 0xe8 0xe6 0x9e 0xe9 0x67 0xe5 0x6c 0xae 0x69 0xaf 0x6a 0xee 0x66 0xe7 0x73 0xef 0x72 0xbf 0x74 0xbe 0x71 0xb3 0x8b 0xff 0x184 0xb1 0x02 0xf2 0x03 0xf3 0x04 0xb5 0x05 0xf6 0x06 0xf7 0x07 0xb9 0x08 0xfa 0x09 0xfb 0x0a 0xfe 0x0b 0xbd 0x0e 0xbc 0xb7 0xf0 0xba 0xb4 0x19c 0xb8 0x1e 0xb0 0x197>; }; ir_key6 { rockchip,usercode = <0xfd01>; rockchip,key_table = <0x31 0xe8 0x2f 0x9e 0x35 0x67 0x2d 0x6c 0x66 0x69 0x3e 0x6a 0x6a 0x66 0x5e 0x73 0x47 0x72 0x23 0x74 0x3a 0x184 0x0d 0x40>; }; ir_key6 { rockchip,usercode = <0xfb04>; rockchip,key_table = <0xf7 0x74 0xd0 0x184 0xb5 0x8b 0x5b 0xb8 0x4d 0xb7 0xba 0x67 0xb9 0x6c 0xb8 0x69 0xb7 0x6a 0xbb 0xe8 0xe5 0x9e 0xe4 0x0e 0xd2 0x66 0xfd 0x73 0xfc 0x72 0xf6 0x71 0xff 0x192 0xfe 0x193 0x04 0x40 0x14 0x41 0x4c 0x42 0x4b 0x43>; }; ir_key8 { rockchip,usercode = <0xe619>; rockchip,key_table = <0x8b KEY_POWER>, <0x98 KEY_UP>, <0x93 KEY_DOWN>, <0x96 KEY_LEFT>, <0x95 KEY_RIGHT>, <0x9e KEY_ENTER>, <0x61 KEY_BACK>; }; };

I have had a bit of time to do some testing (re: MMC disconnects) This bug does not appear in kernel 6.6 A version of this bug appears in 6.10, but without the full trace. Output at the point of disconnect is: [ 1082.901830] EXT4-fs error (device mmcblk0p2): __ext4_get_inode_loc_noinmem:4512: inode #25776: block 1769: comm cron: unable to read itable block [ 1082.914822] EXT4-fs (mmcblk0p2): Remounting filesystem read-only or [ 8235.333023] EXT4-fs (mmcblk0p2): shut down requested (2) It is worth noting that the device is noticeably more sluggish on this kernel (not measured, and may or may not be related) On kernel 6.12 The bug manifests with a full trace: [ 1956.200890] I/O error, dev mmcblk0, sector 9337968 op 0x1:(WRITE) flags 0xc800 phys_seg 1 prio class 2 [ 1965.163111] rcu: INFO: rcu_sched self-detected stall on CPU [ 1965.165764] rcu: 0-....: (57 ticks this GP) idle=9194/1/0x40000004 softirq=13082/13083 fqs=48 [ 1965.173801] rcu: (t=2142 jiffies g=20165 q=305 ncpus=4) [ 1965.179160] CPU: 0 UID: 0 PID: 78 Comm: kworker/0:3 Not tainted 6.12.49-current-meson #1 [ 1965.179720] Hardware name: Amlogic Meson platform [ 1965.179991] Workqueue: events dbs_work_handler [ 1965.180753] PC is at __netif_receive_skb_core.constprop.0+0x4/0x10a4 [ 1965.181411] LR is at __netif_receive_skb_list_core+0xf0/0x1f4 [ 1965.181948] pc : [<c10f55bc>] lr : [<c10f674c>] psr: 80030113 [ 1965.182280] sp : f0801d14 ip : 00000000 fp : c4000000 [ 1965.182583] r10: c211a108 r9 : 00000000 r8 : c4000000 [ 1965.182874] r7 : f0801d48 r6 : c400148c r5 : c211a108 r4 : c4e09900 [ 1965.183225] r3 : c2abbd80 r2 : f0801d44 r1 : 00000000 r0 : f0801d40 [ 1965.183585] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 1965.184017] Control: 10c5387d Table: 05ad004a DAC: 00000051 [ 1965.184260] Call trace: [ 1965.184552] __netif_receive_skb_core.constprop.0 from 0xc4003640 [ 1965.262719] sched: DL replenish lagged too much [ 1990.096714] mmc0: card 0002 removed [ 1990.100368] Aborting journal on device mmcblk0p2-8. [ 1990.100590] JBD2: I/O error when updating journal superblock for mmcblk0p2-8. [ 1990.102743] ------------[ cut here ]------------ [ 1990.111672] WARNING: CPU: 0 PID: 131 at drivers/mmc/host/meson-mx-sdio.c:446 meson_mx_mmc_irq_thread+0x168/0x174 [ 1990.121734] Modules linked in: zram zsmalloc binfmt_misc snd_soc_meson_gx_sound_card snd_soc_meson_aiu snd_soc_hdmi_codec snd_soc_meson_card_utils snd_soc_meson_codec_glue snd_soc_core evdev snd_pcm snd_timer meson_ir snd rc_core soundcore meson_saradc thermal_generic_adc cfg80211 rfkill efi_pstore pstore [ 1990.148744] CPU: 0 UID: 0 PID: 131 Comm: irq/35-c1108c20 Not tainted 6.12.49-current-meson #1 [ 1990.148779] Hardware name: Amlogic Meson platform [ 1990.148791] Call trace: [ 1990.148807] unwind_backtrace from show_stack+0x10/0x14 [ 1990.148865] show_stack from dump_stack_lvl+0x54/0x68 [ 1990.148921] dump_stack_lvl from __warn+0x80/0x114 [ 1990.148980] __warn from warn_slowpath_fmt+0x184/0x18c [ 1990.149030] warn_slowpath_fmt from meson_mx_mmc_irq_thread+0x168/0x174 [ 1990.149088] meson_mx_mmc_irq_thread from irq_thread_fn+0x1c/0x7c [ 1990.149150] irq_thread_fn from irq_thread+0x138/0x21c [ 1990.149207] irq_thread from kthread+0xdc/0xf8 [ 1990.149270] kthread from ret_from_fork+0x14/0x28 [ 1990.149314] Exception stack(0xf106dfb0 to 0xf106dff8) [ 1990.149339] dfa0: 00000000 00000000 00000000 00000000 [ 1990.149365] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1990.149388] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 1990.149420] ---[ end trace 0000000000000000 ]--- [ 1990.574529] EXT4-fs (mmcblk0p2): shut down requested (2) [ 1991.000606] mmc0: new high speed SDHC card at address 0002 [ 1991.001627] mmcblk0: mmc0:0002 00000 7.32 GiB [ 1991.006695] mmcblk0: p1 p2 [ 2041.955601] EXT4-fs warning (device mmcblk0p2): dx_probe:823: inode #593: lblock 0: comm bash: error -5 reading directory block [ 2041.961894] EXT4-fs warning (device mmcblk0p2): dx_probe:823: inode #593: lblock 0: comm bash: error -5 reading directory block [ 2041.974376] EXT4-fs warning (device mmcblk0p2): dx_probe:823: inode #593: lblock 0: comm bash: error -5 reading directory block If I were to speculate it looks like: initial bug introduced kernel 6.7 to 6.10 Bug was identified and the "fix"/"work around" has lead to the more verbose failure somewhere in 6.11 - 6.12 I went for the low hanging fruit first and can confirm the driver meson-mx-sdio.c is unchanged across all versions. I have also compared the DTBs: 6.6 -> 6.10 Significant changes 6.10 -> 6.12 Identical The changes looks to be the USB fix. I suspect that the issue is not with the DTB files, as the significant changes will be down to shifting phandle references by +1, I have now completely ruled out changes to the DTB. I loaded up the 6.12 kernel with the 6.6 DTB and hit the bug fairly quickly (wish I'd done this to start with, to be honest!) When I next get some time I will start diffing changes to the mmc/core and clk/meson drivers between 6.6 -> 6.10. If anyone else wants to have a crack at this in the meantime, based on the above information, then please, have at it!

@jock, I ran Multitool again and got the same error. This time, however, I got the log dmesg.multitool.log

https://github.com/radxa-pkg/aic8800/releases/tag/4.0+git20250410.b99ca8b6-2 The above should get you to a useable page. Download the USB version of the .deb package. I stored mine in the /root but had to copy it to the /tmp directory and install it from there. I installed the .deb package after the apt upgrade process, then rebooted. There may be a more recent version of the package. If I find it, I'll post a link Hope this helps, let me know if you run into trouble.

i can say that linux-image-6.12.43+deb12-arm64 works

Don't concern yourself with the LED light color and whether it flashes or not. It will flash with some kernels and say red with others. And FYI, kernel 6.12 seems to boot, but it has no video output. This is why I suggest starting with 6.1 (vendor).

A 1 GB SSD... don't you mean a 1 TB? I wouldn't start with questioning your bootloader. From what you said, that makes no sense to me. It sounds like that part of your system is already working. From what you said, I would begin with an Armbian image instead of Xunlong (official Orange PI) image - as Xunlong really doesn't do a good job with OS support. https://www.armbian.com/orange-pi-5-plus/ Don't download a 6.12 image because they don't work. 6.1 is does work. Here is a specific Armbian Ubuntu Gnome image for the Orange PI 5 Plus 0 click on this and the download will begin: https://dl.armbian.com/orangepi5-plus/Noble_vendor_gnome You were right to use dd in Linux instead of some fancy piece of software. The images from Armbian are compressed to .xz. To decompress the image, after you download it: unxz [FILENAME] After you decompress it, dd the. .img file to your uSD. Remember to dd it to the device itself, not to a partition on it. This assumes there's nothing on the drive you want to keep, because this will overwrite its GPT (partition) table if it has one. Then verify your image: cmp -l [FILENAME] [DEVICE] If the verification is a success, it will not list any differences between the two files. It will just say EOF on your FILENAME. If it lists differences, it's a failure. Then simply dd again and verify again. I've had occasional instances where I've had to dd something twice from another computer. Then place the uSD in the Orange PI 5 Plus, and power it up. Everything should go well. It'll ask you a few easy questions. Then take you to your (Gnome) desktop. Then of course, do an update and reboot. Then run armbian-config. They have an installer program I've never really used so I can't speak to it. But it's supposed to let you install it on another device (i.e. your SSD). Whenever the uSD card is present in the Orange PI 5 Plus, it will take precedence in boot. So after you do the install onto your SSD drive, shut down and power off the Orange PI 5 Plus, then remove the uSD .Then power it on. Hopefully it will boot from your SSD.

Thanks for the input, CryBaby. First off - I'm a total dummy when it comes to the OrangePi - no idea where to start, so any help is appreciated. I think my PSU is OK - it (apparently) was supplied with the OPi (I was given it as well), and it is rated at 4 amperes. I measured the voltage when loaded, and it is 5.12 volts, so I guess it is OK. After the problems with the SD card, - I tried again installing Balena Etcher on my Linux Mint PC, but when I tried to burn an image (I tried several, not just Ubuntu), it appears to do this, then fails just as the verification process ends. I then tried the AppImage version of Etcher from the OrangePi downloads, and this did the same thing - failure at the end of verification. So, as you suggest, I suspected a dud SD card, but I had no spare, so just tried what I had (I know ....sorry!), and this is when I get the splash image and nothing further. I now have a new SD card, and the image burn/verification appears to be OK - no errors. But now the OPi board does not appear to switch on - The LED remains red, and I can feel that the components on the board are getting warm, but no video output. If there is a bootloader, where is it located? and can I reload it it to be sure it is there (I understand your comment about getting a flash screen, but I have my doubts about the integrity of any of the software after what I was told about the OPi) Thanks for your help, Keith.