All Activity

# make -j 4 make -C /lib/modules/6.12.33-current-meson64/build M=/home/INSTALKI/linux_openvfd/driver modules make[1]: Enter the directory '/usr/src/linux-headers-6.12.33-current-meson64' CC [M] /home/INSTALKI/linux_openvfd/driver/protocols/i2c_sw.o CC [M] /home/INSTALKI/linux_openvfd/driver/protocols/i2c_hw.o CC [M] /home/INSTALKI/linux_openvfd/driver/protocols/spi_sw.o CC [M] /home/INSTALKI/linux_openvfd/driver/controllers/dummy.o CC [M] /home/INSTALKI/linux_openvfd/driver/controllers/seg7_ctrl.o /home/INSTALKI/linux_openvfd/driver/controllers/seg7_ctrl.c:11:6: warning: no previous prototype for ‘transpose8rS64’ [-Wmissing-prototypes] 11 | void transpose8rS64(unsigned char* A, unsigned char* B) { | ^~~~~~~~~~~~~~ /home/INSTALKI/linux_openvfd/driver/controllers/seg7_ctrl.c:40:8: warning: no previous prototype for ‘seg7_write_display_data’ [-Wmissing-prototypes] 40 | size_t seg7_write_display_data(const struct vfd_display_data *data, unsigned short *raw_wdata, size_t sz) | ^~~~~~~~~~~~~~~~~~~~~~~ CC [M] /home/INSTALKI/linux_openvfd/driver/controllers/fd628.o CC [M] /home/INSTALKI/linux_openvfd/driver/controllers/fd650.o CC [M] /home/INSTALKI/linux_openvfd/driver/controllers/hd44780.o CC [M] /home/INSTALKI/linux_openvfd/driver/controllers/gfx_mono_ctrl.o CC [M] /home/INSTALKI/linux_openvfd/driver/controllers/ssd1306.o CC [M] /home/INSTALKI/linux_openvfd/driver/controllers/pcd8544.o /home/INSTALKI/linux_openvfd/driver/controllers/gfx_mono_ctrl.c:239:6: warning: no previous prototype for ‘transpose_buffer’ [-Wmissing-prototypes] 239 | void transpose_buffer(unsigned char *buffer, const struct rect *rect) | ^~~~~~~~~~~~~~~~ CC [M] /home/INSTALKI/linux_openvfd/driver/controllers/il3829.o CC [M] /home/INSTALKI/linux_openvfd/driver/openvfd_drv.o /home/INSTALKI/linux_openvfd/driver/openvfd_drv.c:44:7: warning: "CONFIG_AMLOGIC_LEGACY_EARLY_SUSPEND" is not defined, evaluates to 0 [-Wundef] 44 | #elif CONFIG_AMLOGIC_LEGACY_EARLY_SUSPEND | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/INSTALKI/linux_openvfd/driver/openvfd_drv.c: In function ‘register_openvfd_driver’: /home/INSTALKI/linux_openvfd/driver/openvfd_drv.c:400:75: warning: suggest braces around empty body in an ‘else’ statement [-Wempty-body] 400 | pr_dbg("%s: Succeeded to add openvfd module \n", __func__); | ^ /home/INSTALKI/linux_openvfd/driver/openvfd_drv.c: At top level: /home/INSTALKI/linux_openvfd/driver/openvfd_drv.c:622:19: warning: no previous prototype for ‘gpiochip_find’ [-Wmissing-prototypes] 622 | struct gpio_chip *gpiochip_find(void *data, | ^~~~~~~~~~~~~ /home/INSTALKI/linux_openvfd/driver/openvfd_drv.c:669:5: warning: no previous prototype for ‘evaluate_pin’ [-Wmissing-prototypes] 669 | int evaluate_pin(const char *name, const unsigned int *vfd_arg, struct vfd_pin *pin, unsigned char enable_skip_evaluation) | ^~~~~~~~~~~~ /home/INSTALKI/linux_openvfd/driver/openvfd_drv.c:752:6: warning: no previous prototype for ‘get_pin_from_dt’ [-Wmissing-prototypes] 752 | void get_pin_from_dt(const char *name, const struct platform_device *pdev, struct vfd_pin *pin) | ^~~~~~~~~~~~~~~ /home/INSTALKI/linux_openvfd/driver/openvfd_drv.c:763:5: warning: no previous prototype for ‘request_pin’ [-Wmissing-prototypes] 763 | int request_pin(const char *name, struct vfd_pin *pin, unsigned char enable_skip) | ^~~~~~~~~~~ /home/INSTALKI/linux_openvfd/driver/openvfd_drv.c:1034:19: error: initialization of ‘void (*)(struct platform_device *)’ from incompatible pointer type ‘int (*)(struct platform_device *)’ [-Werror=incompatible-pointer-types] 1034 | .remove = openvfd_driver_remove, | ^~~~~~~~~~~~~~~~~~~~~ /home/INSTALKI/linux_openvfd/driver/openvfd_drv.c:1034:19: note: (near initialization for ‘openvfd_driver.<anonymous>.remove’) /home/INSTALKI/linux_openvfd/driver/openvfd_drv.c: In function ‘print_param_debug’: /home/INSTALKI/linux_openvfd/driver/openvfd_drv.c:611:1: warning: the frame size of 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=] 611 | } | ^ cc1: some warnings being treated as errors make[3]: *** [scripts/Makefile.build:229: /home/INSTALKI/linux_openvfd/driver/openvfd_drv.o] Error 1 make[2]: *** [/usr/src/linux-headers-6.12.33-current-meson64/Makefile:1945: /home/INSTALKI/linux_openvfd/driver] Error 2 make[1]: *** [Makefile:224: __sub-make] Error 2 make[1]: Leaving the directory '/usr/src/linux-headers-6.12.33-current-meson64' make: *** [Makefile:5: modules] Error 2 I'm trying to compile the "openvfd" driver but the compilation ends with an error. I'm a complete noob at these things and I really want this driver so I'd be very grateful for any help.

Thank you for letting us know, much appreciated. Have you tried to reach out to the Michael Hawkins, the maintainer?

Hello all Is anybody having success with spidev with orange pi zero 3 and Linux 6.12? I want to test my LCD panel's touch, but I need spidev working first

I did everything again, as you wrote and it still doesn't work. So it looks like my TVbox has a different LED controller?

Those use systemd-network and it is called 'minimal' so it might be that only 1 port is handled by default (the LAN only). Rest you need to figure out yourself. What do you want to do with the NanoPi-R5C ? I have replaced systemd-network with NetworkManager as is the default in Debian Bookworm once for a newly downloaded image (was for ROCK3A AFAIR). The Ubuntu based images use netplan.io, that is nice for Canonical, not for me. I do not want to waste my time on yet another configuring/scripting/layering. It made me just clone an existing Armbian/Debian/RPi Bookworm rootfs as I use NetworkManager for almost all Linux computers and is easy copying of .nmconnection files between platforms (x86, arm, etc).

You could try to install auditd and check what it says when the event appears. Maybe it will tell you which process is sending the event: $ sudo apt install auditd $ sudo auditctl -w /proc/sysrq-trigger -p w -k sysrq_watch The second command is creating a watch on sysrq-trigger for write events, called sysrq_watch. You can query check this watch with: $ sudo ausearch -k sysrq_watch See what you can find when you detect another trigger of the sysrq key.

Hi, Just received my Nanopi R5C. Flashed the Debian 12 (Bookworm) Minimal/IOT images with Armbian Linux v6.12 from here https://www.armbian.com/nanopi-r5c/. Everything works well except that I could not get the WAN port working. Anyone has any idea? BTW, the Nanopi R5C looks different from the image showed on https://www.armbian.com/nanopi-r5c/. Mine has only 2 x 2.5Gb ports instead of the 3 port. The image on the page looks like a NanoPi R5S... Just a side note. Cheers.

Hi again, one quick question -- I previously made the mistake of running apt upgrade of the system packages and had installed armbian-configNG over the included armbian-config, so I basically nuked the SD card and reinstalled the image to roll back to the old config. This likely has been covered, but is there a way to reinstall armbian-config or is this a known issue and "DON'T UPGRADE" ? Cheers!

Hi everyone, I hope you're all doing well. A couple of days ago, I got interested in installing Linux on one of these Chinese TV boxes to use it with a 3D printer. I've been trying to follow the tutorial step by step, but I'm having a problem. The box boots into Multitool correctly, and at first, it let me burn the image to the flash, but it didn't work. Now I'm trying again, but it's giving me an error saying there is no eMMC. I'm not sure what’s going on — could someone please help me? Thanks in advance!

Hi there, just created an account to say thanks ! I randomly bought a clearance media player on tuesday thinking "there must be something I can do with this and need a project" https://www.jaycar.co.nz/4k-android-media-player/p/XC6012 A bit of DuckDuckgoing later and found this forum, and well, it's all been done! Good work guys, this device has nand flash and rk3228a so after a few nand reflashes and general messing about etc I decided to flash the latest image to SD card and well, it runs really well. As previously noted this board has horrible thermal design so active cooling is basically mandatory - anyone experiencing "freezes" or crashes during system updates, note the board temp, it heats rapidly and appears to thermal shutdown at around 80 degrees C. Have since added a USB wifi dongle which works fine as the onboard wifi isn't driver compat (as previously noted) So this board appears to have comparable performance to a Raspberry Pi 2b, so as long as you temper your expectations this is a fun system to mess around with. Thanks !

It's a progress! This or similar problem was seen / reported on H3 too.

The good news is that we get a working display. The bad news is that it creates a new problem. when Either shutting down or rebooting a kernel panic is triggered. After a bit more digging I found the reason that the drm_hdmi_connector_mode_valid patch failed is because the function does not exist under kernel 6.12. I dont know yet if it may be necessary to include it yet or if drm_atomic_helper_connector_hdmi_check needs some further tweaks. Thanks Ryzer

Here is a more vanilla build of the kernel. patrick@bananapim4zero:~$ ls /dev/ttyS* /dev/ttyS0 /dev/ttyS3 /dev/ttyS5 /dev/ttyS7 /dev/ttyS2 /dev/ttyS4 /dev/ttyS6 patrick@bananapim4zero:~$ sudo rfkill ID TYPE DEVICE SOFT HARD 0 bluetooth hci0 unblocked unblocked 1 wlan phy0 unblocked unblocked patrick@bananapim4zero:~$ bluetoothctl hci0 new_settings: powered bondable ssp br/edr le secure-conn Agent registered [CHG] Controller AC:6A:A3:3B:D9:D6 Pairable: yes [bluetoothctl]> exit patrick@bananapim4zero:~$ uname -a Linux bananapim4zero 6.12.32 #1 SMP Sat Jun 7 17:23:51 EDT 2025 aarch64 GNU/Linux patrick@bananapim4zero:~$ dmesg | grep brcm [ 9.007064] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 9.007614] usbcore: registered new interface driver brcmfmac [ 9.303238] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2) [ 9.303576] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Aug 29 2023 01:47:08 version 7.45.265 (28bca26 CY) FWID 01-b677b91b [ 9.430799] Bluetooth: hci0: BCM4345C0 'brcm/BCM4345C0.sinovoip,bpi-m4-zero.hcd' Patch As you can see the Bluetooth works fine. If I add these two patches it breaks bluetooth on this kernel build. drv-rtc-sun6i-support-RTCs-without-external-LOSCs.patch drv-rtc-sun6i-Add-Allwinner-H616-support.patch I'm still investigating in my spare time, but I'm not 100% on anything. Could be I need to take another approach to the bluetooth node in Armbian? So this is where am at. If anyone has any thoughts I'm all ears.

@IronIgel @ketzercat so, i also bought one of these have you launched somehow?

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

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