All Activity

It is possible that broken patch removal is already a solution.

No need to disassemble anything. Given your device has the same configuration as hk1-x3, you should rather use the corresponding device tree definition: make hk1-x3.dtb cp release/hk1-x3.dtb /boot/dtb/{YOUR_DTB_PATH}.dtb reboot

@Angel Luis Pérez Your image save my life! I just got the Radxa Cubie A5E and surprisingly found that this two eth ports board factory image doesn't include tun.ko I dig some other same T527/A527 boards image but none of them has tun.ko from 5.15 kernel, except yours! I am about to export the tun.ko to Cubie A5E's factory image to see if it works.

@Lucas Gomes you should force it go in maskrom ( if no phisical damage occurred) finding the appropriate pins on the board

@Tavares R if you read the 1st post you will see that this box is a half-miracle, in the meaning that it work under some intergalactic forces 🤣😎 since it's harware is quite limited For use such as headless server is fantastic but when it comes to net browsing it shows all it's limits In the first post also is detaiiled a way to install full hw acceleration I tested many many many rootfs and many combinations but with XORG almost any browser is quite unusable. I dont have experience with wayland thought Different approach with playing video and music under libreelec with a reasonable frame rate and hw acceleration , but on this side @ilmich could be more specific

Will disassembling the TV box help get this display working? The TV box looks like it's glued together, but if that helps, I can open it.

I consider the btrfs issue 'solved', from past experience I know sometimes explicit balancing is needed for certain blockdevice level or lowlevel operations, like conversion of profiles, for example single into raid1, there must be enough unallocated space so new 1GB chunks can be created, especially on the originating device as it is all fundamentally copy-on-write so at least extra/double space for 1 system, meta, data chunk shall be available and I simply forgot to check/realize that. Further enhancements to Btrfs that this is done automatically somehow means likely that I first need to browse the kernel mailing list and see what people like David Sterba are doing nowadays. The CMA issue I suspect maybe it is related to power supply. Because of testing, I needed to take the NanoPi-R6C to another room where i used a 65W 'white-label branded' USB-C PD PSU that I got delivered with a refurbished laptop. That PSU has once shown under-voltage on an RPi4, so I expect too much ripple (when 5V). Besides the CMA issue, lateron also sudden hard reset of the NanoPi-R6C when I was doing networked backup, was 2x ethernet + HDMI + NVMe + eMMC active and that could mean >3A when only 5V. When I also took my RPI5 27W USB-C PD PSU to that room and used that, no strange issues anymore, so running fine at least with EDK2-UEFI and Armbian kernel 6.15.2-edge-rockchip64 and Bookworm or Tumbleweed userspace (and KDE Wayland). I have never seen PD working on the NanoPi-R6C and the powering circuit looks a lot like ROCK3A w.r.t. staged DC-DC conversion. And I use Armbian mainline based U-Boot or EDK2-UEFI, not the original FriendlyWrt installation with some 2017 based U-Boot. Also for that original one, I doubt that it does USB-C PD to request 9V or higher. I assume not, looking at: https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R6C#PD_Power_Adapters_We_Tested https://wiki.friendlyelec.com/wiki/index.php/Template:PDPowerWeTested There is also nothing about USB-C PD under https://www.friendlyelec.com/Forum/viewforum.php?f=81 so I assume: Great HW but SW/OS support is abandoned and DIY. That also means, same as for ROCK3A and ROCK5B, solder some 12V wire to a male USB-C connector and use that in order to be sure power won't drop too much when e.g. some USB3 HDD/SSD is inserted. Or limit cables to only RPI5 PSU and WAN/1GB ethernet (and still Samsung 970 NVMe, that works OK, even when 800% CPUload). Or check/see if PD handling is available in denx.de/mainline U-Boot.

Context: new Banana Pi M4 zero (rev 2) is using Wifi/BT over SDIO, which requires an sdio overlay. Thanks to Armbian team for providing it. Editing armbianEnv.txt to add "overlays=bananapi-m4-sdio-wifi-bt" did the trick for Wifi but BT is still not available (neither in standard or rolling builds)... @c0rnelius I know you tried to figure out why, I'm missing technical knowledge to help... Digging the Internet I saw similar bluetooth issue for radxa zero 3w with aic8800, resolved using hciattach / hci up, but needing an available /dev/ttyS1 (UART1) we are missing here... Do you know why? Could it be the problem for banana pi m4 zero and if yes could an overlay activate it? Denis

Recreated hdmi patches under kernels 6.12 and kernels 6.15 in pcduino-boards-fixes branch. When attempting to build with current kernel 6.12.30, with drm patches for sun4i_hdmi_enc.c to use drm_hdmi_connector_mode_valid and drm_atomic_helper_connector_hdmi_check fails to compile. when just applying drm_atomic_helper_connector_hdmi_check patch build compilation is successful. Just need to verify this build works. For kernel 6.15, with just the hdmi patches, we get a working HDMI display output:

Yes exactly

New topic created:

Thank you for the reply ! I see — is there any version of Armbian or another distro that has working HDMI output and graphics drivers ?

I came to this topic with the same issue on a pair of Orange Pi 3's (with 1 GB RAM) running PiHole - /var/log would fill up. Thank you for the help on how to solve this! For now, I've set /dev/zram1 to be 256MB instead of 50, to hopefully allow more time for the logs to properly rotate / clean themselves up. The larger question I have is, what is the intent of having this configured? Is it to prevent wear & tear on the SD card with all of the log writing? (I'd like to disable it if I can so I can use the full storage of my SD card instead of limited RAM, but if it's going to potentially kill my storage, I probably shouldn't.)

Hi, Then the only other difference would be that your device has a pin tied to usb0-vbus. The topwise dts does not have the display nodes included in the cubieboard. Now as you are currently kernel 6.1, it is possible to enable the display via overlays or compile a version of the topwise dts that includes the display nodes. So the internal display does not work under 6.1? Are there any kind of errors or does it not appear to intialise at all? Cubieboard nodes (*Note - Nodes other than hdmi and usb related have been removed): /dts-v1/; #include "sun4i-a10.dtsi" #include "sunxi-common-regulators.dtsi" #include <dt-bindings/gpio/gpio.h> / { model = "Cubietech Cubieboard"; compatible = "cubietech,a10-cubieboard", "allwinner,sun4i-a10"; hdmi-connector { compatible = "hdmi-connector"; type = "a"; port { hdmi_con_in: endpoint { remote-endpoint = <&hdmi_out_con>; }; }; }; }; &de { status = "okay"; }; &hdmi { status = "okay"; }; &hdmi_out { hdmi_out_con: endpoint { remote-endpoint = <&hdmi_con_in>; }; }; &reg_usb1_vbus { status = "okay"; }; &reg_usb2_vbus { status = "okay"; }; &usb_otg { dr_mode = "otg"; status = "okay"; }; &usbphy { usb0_id_det-gpios = <&pio 7 4 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>; /* PH4 */ usb1_vbus-supply = <&reg_usb1_vbus>; usb2_vbus-supply = <&reg_usb2_vbus>; status = "okay"; }; Topwise a721: /dts-v1/; #include "sun4i-a10.dtsi" #include "sunxi-common-regulators.dtsi" #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/input/input.h> #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/pwm/pwm.h> / { model = "Topwise A721"; compatible = "topwise,a721", "allwinner,sun4i-a10"; panel { compatible = "starry,kr070pe2t"; backlight = <&backlight>; power-supply = <&reg_lcd_power>; port { panel_input: endpoint { remote-endpoint = <&tcon0_out_panel>; }; }; }; reg_lcd_power: reg-lcd-power { compatible = "regulator-fixed"; regulator-name = "reg-lcd-power"; gpio = <&pio 7 8 GPIO_ACTIVE_HIGH>; /* PH8 */ enable-active-high; }; }; &de { status = "okay"; }; &reg_usb0_vbus { status = "okay"; }; &reg_usb1_vbus { status = "okay"; }; &reg_usb2_vbus { status = "okay"; }; &tcon0_out { tcon0_out_panel: endpoint@0 { reg = <0>; remote-endpoint = <&panel_input>; }; }; &usb_otg { dr_mode = "otg"; status = "okay"; }; &usb_power_supply { status = "okay"; }; &usbphy { usb0_id_det-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */ usb0_vbus_det-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */ usb0_vbus-supply = <&reg_usb0_vbus>; usb1_vbus-supply = <&reg_usb1_vbus>; usb2_vbus-supply = <&reg_usb2_vbus>; status = "okay"; }; It is possible to build just uboot using the BUILD_ONLY=uboot option. Again here you could face potential issues as newer uboot might not work well with an old kernel. All the best Ryzer

hk1-x3.conf I haven't opened my TV box but I saw a picture and it seems to me that the controller is "FD6551"

Vontar X3 is the same as hk1-x3 and I used the one from hk1-x3. Here are the pictures because I didn't open mine: https://github.com/ophub/amlogic-s9xxx-armbian/issues/1006

What is your Android TV device model? What is the led controller model? Then what is your DTS configuration for the display client?

# dmesg | grep tm16xx [ 21.189046] tm16xx: loading out-of-tree module taints kernel. [ 21.190997] tm16xx 1-0024: Failed to set brightness: -6 [ 21.194407] tm16xx 1-0024: Failed to initialize display: -6

There should have been an exception on first load that now prevent removing the module. You can force removal of the module but that can create unstable kernel side effects. You are better to reboot the device (you may need to unplug power if kernel refuses to reboot). Then after boot, check dmesg kernel messages (do not clear them first!) something like dmesg | grep tm16xx

You can build an armbian image with these instructions:https://docs.armbian.com/Developer-Guide_Build-Preparation/ You can configure it: https://docs.armbian.com/ When you have a setup you like, use this to backup as an image: https://forum.armbian.com/topic/29427-shrink-backup-a-tool-for-backing-up-sbcs/ I still suggest only armbian... but please share if you can use buildroot for opiz2w

# modprobe -r tm16xx modprobe: ERROR: ../libkmod/libkmod-module.c:856 kmod_module_remove_module() could not remove 'tm16xx': Device or resource busy # dmesg # modprobe tm16xx # modprobe -r tm16xx modprobe: ERROR: ../libkmod/libkmod-module.c:856 kmod_module_remove_module() could not remove 'tm16xx': Device or resource busy

Have you looked for dmesg output about tm16xx after probing the driver? dmesg -c # clear kernel messages modprobe -r tm16xx # unload driver modprobe tm16xx # load driver dmesg # check for new kernel messages

I managed to install it but the display doesn't work. # display-utils -c cat: /sys/class/leds/display/num_digits: There is no such file or directory # display-utils -a cat: /sys/class/leds/display/num_digits: There is no such file or directory

Restarted with vendor kernel, then same actions: [ 580.015977] BTRFS info (device loop0p2): dev_replace from /dev/loop0p2 (devid 1) to /dev/loop1p2 started [ 599.501402] cma: cma_alloc: cma: alloc failed, req-size: 1024 pages, ret: -12 [ 599.502431] kworker/6:4: page allocation failure: order:10, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 [ 599.502452] CPU: 6 PID: 239 Comm: kworker/6:4 Tainted: G W 6.1.115-vendor-rk35xx #1 [ 599.502457] Hardware name: FriendlyElec NanoPi R6C/NanoPi R6C, BIOS v1.1 04/09/2025 [ 599.502461] Workqueue: events atomic_pool_work_fn [ 599.502471] Call trace: [ 599.502474] dump_backtrace+0xf0/0x12c [ 599.502480] show_stack+0x20/0x30 [ 599.502484] dump_stack_lvl+0x7c/0xa0 [ 599.502489] dump_stack+0x18/0x34 [ 599.502493] warn_alloc+0xe0/0x17c [ 599.502498] __alloc_pages+0x524/0x854 [ 599.502501] atomic_pool_expand+0x8c/0x268 [ 599.502506] atomic_pool_resize+0x50/0x64 [ 599.502510] atomic_pool_work_fn+0x44/0x54 [ 599.502515] process_one_work+0x1c0/0x274 [ 599.502521] worker_thread+0x1dc/0x274 [ 599.502525] kthread+0xc4/0xd4 [ 599.502529] ret_from_fork+0x10/0x20 [ 599.502534] Mem-Info: [ 599.502537] active_anon:465 inactive_anon:13222 isolated_anon:0 active_file:37602 inactive_file:1830958 isolated_file:0 unevictable:4 dirty:1679 writeback:166667 slab_reclaimable:15924 slab_unreclaimable:27052 mapped:16566 shmem:499 pagetables:621 sec_pagetables:0 bounce:0 kernel_misc_reclaimable:0 free:12582 free_pcp:127 free_cma:0 [ 599.502546] Node 0 active_anon:1860kB inactive_anon:52888kB active_file:150408kB inactive_file:7323832kB unevictable:16kB isolated(anon):0kB isolated(file):0kB mapped:66264kB dirty:6716kB writeback:666668kB shmem:1996kB writeback_tmp:0kB kernel_stack:4416kB pagetables:2484kB sec_pagetables:0kB all_unreclaimable? no [ 599.502554] DMA free:24920kB boost:0kB min:5448kB low:9248kB high:13048kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:956kB inactive_file:3784292kB unevictable:0kB writepending:29608kB present:3929344kB managed:3825428kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [ 599.502561] lowmem_reserve[]: 0 0 3902 3902 [ 599.502567] Normal free:25408kB boost:0kB min:5712kB low:9696kB high:13680kB reserved_highatomic:2048KB active_anon:1860kB inactive_anon:52888kB active_file:149060kB inactive_file:3539556kB unevictable:16kB writepending:643228kB present:4194304kB managed:3996056kB mlocked:16kB bounce:0kB free_pcp:556kB local_pcp:0kB free_cma:0kB [ 599.502574] lowmem_reserve[]: 0 0 0 0 [ 599.502580] DMA: 97*4kB (UM) 103*8kB (UM) 95*16kB (UME) 101*32kB (UME) 61*64kB (UME) 22*128kB (UME) 7*256kB (U) 7*512kB (UME) 5*1024kB (UME) 1*2048kB (U) 0*4096kB = 25228kB [ 599.502601] Normal: 962*4kB (UME) 377*8kB (UME) 140*16kB (UMEH) 43*32kB (UMEH) 22*64kB (UME) 25*128kB (UME) 17*256kB (UM) 4*512kB (ME) 5*1024kB (UME) 0*2048kB 0*4096kB = 26608kB [ 599.502621] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB [ 599.502624] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=32768kB [ 599.502628] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [ 599.502631] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=64kB [ 599.502634] 1869148 total pagecache pages [ 599.502636] 0 pages in swap cache [ 599.502639] Free swap = 10873596kB [ 599.502641] Total swap = 10873852kB [ 599.502643] 2030912 pages RAM [ 599.502645] 0 pages HighMem/MovableOnly [ 599.502648] 75541 pages reserved [ 599.502650] 2048 pages cma reserved [ 624.681251] BTRFS info (device loop0p2): dev_replace from /dev/loop0p2 (devid 1) to /dev/loop1p2 finished So although it works, a rather strange side effect with CMA makes me feel that the system could be unstable now. I have seen CMA related errors before on RK35xx, but that was with U-Boot, this is with UEFI firmware, where I maybe forgot to change a setting or so. At least HDMI display is blank, serial console and ssh works.

Looking back at your previous output, I've just noticed something wrong. I've should have seen it first instead of pointing you to kernel headers issue. Here M should be pointing to your path to the tm16xx-display folder. I think the PWD environment variable is affected by sudo. You can specify the PWD variable explicitly when calling make: sudo make PWD=$(pwd) module-install That should make it.