All Activity

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?

@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, If I get some more time tomorrow I will start by comparing whether the cards resolve consistently between 6.6 to 6.12 (thus eliminating DTB issues), and then drill into changes to the mmc/core and clk/meson drivers

@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.

Thanks for the reply @hexdump , the thing I don't understand is that in the thread I mentioned in my first message to this thread : the person claims to have successfully installed the OS on the internal eMMC on my very same box. Why running from eMMC wouldn't be possible on mine? What I am afraid of is that maybe there is some information / log which might be important in the outputs I provided in my pictures in the first message which I fail to recognize. About the message from @SteeMan I don't understand what he means by "and patch and apply it to a newer u-boot and build a newer u-boot"... In the /boot/build-u-boot/readme.txt file the instructions only have 3 different u-boots possible (s905x, s905x2 and s905x3) and all of them are like "git clone, run make" and that's it. Could you please be more explicit in what I should do or point me to some useful documentation? Thanks a lot for your help.

Sounds to me like a bad SD card. If you get a splash screen there must be some sort of bootloader. Another possibility is an inadequate power supply. Try one with more amps.

This build has disabled ffmpeg, I don't know it is possible to build with it for wayland client. I recommend x11 client because it is the most usable client with the most features. FreeRDP developers is developing a new sdl client for all platforms: linux, mac, wayland, x11, but that is still at an early stage. If you run xfreerdp, make sure to use gfx:AVC444 so that server sends h264 stream to you, then freerdp will use ffmpeg to decode it. You can check /proc/mpp_service/ to see if mpp hardware decoder is used. But don't expect the cpu will be extremely low, freerdp is decoding two avc420 streams and then combine them into one yuv444 frame, and then use cpu to convert yuv444 to rgb, then render it to x11, hardware decoder can only off-load few of the cpu load.

Not sure whether is specific to Opi5-Plus, on Arch Linux mpv-0.40.0 somehow also did not support --hwdec=v4l2request as such had to resort to the mpv-full-git which supports --hwdec=v4l2request. Debian-Trixie's repo mpv-0.40.0 also doesn't seems to support --hwdec=v4l2request.

##O#O## OS: Armbian 25.8.1 noble aarch64 ####### Host: Orange Pi 5 Plus ########### Kernel: 6.1.115-vendor-rk35xx ############# Uptime: 1 day, 8 hours, 17 mins ############### Packages: 1852 (dpkg), 5 (snap) ################ Shell: bash 5.2.21 ################# Resolution: 3840x2160 ##################### DE: GNOME 46.0 ##################### WM: Mutter ################# WM Theme: Adwaita Theme: Adwaita [GTK2/3] Icons: Adwaita [GTK2/3] Terminal: x-terminal-emul CPU: (8) @ 1.800GHz Memory: 7245MiB / 15957MiB FreeRDP client: freerdp2-wayland: Инсталирана: 2.11.5+dfsg1-1build2 Кандидат: 2.11.5+dfsg1-1build2 Таблица с версиите: *** 2.11.5+dfsg1-1build2 500 500 http://ports.ubuntu.com noble/universe arm64 Packages 100 /var/lib/dpkg/status --------------------------------------------------------------------------------------------------------- This is Build configuration: BUILD_TESTING=OFF BUILTIN_CHANNELS=ON HAVE_AIO_H=1 HAVE_EXECINFO_BACKTRACE=1 HAVE_EXECINFO_BACKTRACE_SYMBOLS=1 HAVE_EXECINFO_BACKTRACE_SYMBOLS_FD=1 HAVE_EXECINFO_H=ON HAVE_EXECINFO_HEADER=1 HAVE_FCNTL_H=1 HAVE_GETLOGIN_R=1 HAVE_GETPWUID_R=1 HAVE_INTTYPES_H=1 HAVE_JOURNALD_H=TRUE HAVE_MATH_C99_LONG_DOUBLE=1 HAVE_PIXMAN_REGION=OFF HAVE_POLL_H=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK=ON HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIBS= HAVE_PTHREAD_MUTEX_TIMEDLOCK_SYMBOL=1 HAVE_SYSLOG_H=1 HAVE_SYS_EVENTFD_H=1 HAVE_SYS_FILIO_H= HAVE_SYS_MODEM_H= HAVE_SYS_SELECT_H=1 HAVE_SYS_SOCKIO_H= HAVE_SYS_STRTIO_H= HAVE_SYS_TIMERFD_H=1 HAVE_TM_GMTOFF=1 HAVE_UNISTD_H=1 HAVE_XI_TOUCH_CLASS=1 WITH_ALSA=ON WITH_CAIRO=ON WITH_CCACHE=ON WITH_CHANNELS=ON WITH_CLANG_FORMAT=ON WITH_CLIENT=ON WITH_CLIENT_AVAILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CUPS=ON WITH_DEBUG_ALL=OFF WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_RAIL=OFF WITH_DEBUG_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_RDPGFX=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DEBUG_SCARD=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF_AVAILABLE=0 WITH_DEBUG_URBDRC=OFF WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_CLIPRDR=OFF WITH_DEBUG_X11_LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DSP_EXPERIMENTAL=OFF WITH_EVENTFD_READ_WRITE=1 WITH_FAAC=OFF WITH_FAAD2=OFF WITH_FFMPEG=OFF WITH_GFX_H264=OFF WITH_GPROF=OFF WITH_GSM=OFF WITH_GSSAPI=OFF WITH_ICU=ON WITH_INTERNAL_MD4=OFF WITH_INTERNAL_MD5=OFF WITH_IPP=OFF WITH_JPEG=ON WITH_KERBEROS=ON WITH_LAME=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBSYSTEMD=ON WITH_MACAUDIO=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO_AVAILABLE=0 WITH_MANPAGES=ON WITH_MBEDTLS=OFF WITH_OPENCL=OFF WITH_OPENH264=OFF WITH_OPENSLES=OFF WITH_OPENSSL=ON WITH_OSS=ON WITH_PAM=ON WITH_PCSC=ON WITH_PROFILER=OFF WITH_PROXY=OFF WITH_PULSE=ON WITH_SAMPLE=OFF WITH_SANITIZE_ADDRESS=OFF WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAILABLE=1 WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD_AVAILABLE=1 WITH_SERVER=ON WITH_SERVER_CHANNELS=ON WITH_SERVER_INTERFACE=ON WITH_SHADOW=ON WITH_SMARTCARD_INSPECT=OFF WITH_SOXR=OFF WITH_SSE2=OFF WITH_SWSCALE=OFF WITH_THIRD_PARTY=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=1 WITH_VERBOSE_WINPR_ASSERT=ON WITH_WAYLAND=ON WITH_WINPR_TOOLS=ON WITH_X11=ON WITH_XCURSOR=ON WITH_XDAMAGE=ON WITH_XEXT=ON WITH_XFIXES=ON WITH_XI=ON WITH_XINERAMA=ON WITH_XKBFILE=ON WITH_XRANDR=ON WITH_XRENDER=ON WITH_XSHM=ON WITH_XTEST=ON WITH_XV=ON WITH_ZLIB=ON Hi guys, I am using `wlfreerdp` to access remote Win 11 but the client I have installed does not support hwacc and is laggy on 4K monitor. Network is 1G LAN. I have already built Moonlight with ffmpeg/rkmpp hwacc and it works amazing. Can anyone advice if I can do the same, building the FreeRDP client with hwacc? CC:@amazingfate (I know u know how to do it ;) )

I had the same problem when trying this directly on my Banana PI M5. But when I connected from my notebook via ssh everything worked fine and I could create the root and user password. Afterwards login was also possible directly on the machine.

Hi, I guess this happens because of the "-x" option in rsync which tells rsync to not cross the filesystem hierarchy. /var/log is typically a mount (/dev/zram1) so it will not be synced.

I suggest booting from µSD and then making a copy of eMMC to somewhere and reinstall after that. You can then restore whatever you need from your eMMC backup. Most likely that will be vastly less headache and much higher chances of success.

@pochopsp - as you contacted me via message directly, let me respond here: i can only repeat what @SteeMan already said - you can either do your own research and experiments if you get some newer u-boot built and working (which will be a lot of learning and effort and can also fail in the end) or you accept that running from emmc will not work on your box and continue to use an sd card (which should work nearly as good as running from internal storage) - there is no easy tutorial to get it working, either it works out of the box (as the box is closer to one of the supported and tested ones) or you have to find your own way to get it working with those tv boxes ...

Can I just follow the Debian rescue chroot tutorial ? (with appropriate partitions) https://wiki.debian.org/RescueLive