Active threads
Showing topics posted in for the last 365 days.
- Today
-
For a few weeks I've been using the latest official release from May 26, 2025, running just fine from my NVME drive. But then I turned it on and at the screen where you get the Amrbian grey/red logo in the middle of the screen and the spinning circle, it went no further. The spinning circle would either stop rotating or disappear after a minute or so. I can SSH into the device. But when I use remote desktop from a Windows PC, the full and functioning desktop is there. It's just not on my TV screen any more. I've done the usual HDMI cable testing and powering off the TV completely, but no change. The fact that the desktop is accessible remotely does indicate that it must be loading in some fashion. Took a log here: https://paste.next.armbian.com/qococumoga
-
# 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.
-
Kernel 6.12.20 Banana Pi M2 zero USB doesn't work
laibsch replied to Bernd's topic in Allwinner sunxi
Thank you for letting us know, much appreciated. Have you tried to reach out to 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
-
Help wanted to test a new OpenVFD alternative
KrzyPacu replied to Jean-Francois Lessard's topic in Amlogic meson
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 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!
- Yesterday
-
It's a progress! This or similar problem was seen / reported on H3 too.
-
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.
-
Armbian for H313 X96-Q LPDDR3 TV-Box
Abay Kalenov replied to sicxnull's topic in Allwinner CPU Boxes
@IronIgel @ketzercat so, i also bought one of these have you launched somehow? -
@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.
-
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.
- Last week
-
Yes exactly
-
Cubieboard 1 - No display output when booting Debian 12 image
Shakai2 replied to Shakai2's topic in Allwinner sunxi
Thank you for the reply ! I see — is there any version of Armbian or another distro that has working HDMI output and graphics drivers ? -
Armbian for an old Allwinner A10 tablet
Ryzer replied to thewiseguyshivam's topic in Allwinner sunxi
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>; }; }; ®_usb1_vbus { status = "okay"; }; ®_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 = <®_usb1_vbus>; usb2_vbus-supply = <®_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 = <®_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"; }; ®_usb0_vbus { status = "okay"; }; ®_usb1_vbus { status = "okay"; }; ®_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 = <®_usb0_vbus>; usb1_vbus-supply = <®_usb1_vbus>; usb2_vbus-supply = <®_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 -
Orangepi Zero 2W wrong color display on MPI3501
robertoj replied to Minh Tiến Nguyễn's topic in Allwinner sunxi
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 -
It is Allwinner H618, Quad-core ARM Cortex™-A53 processor. I meant which Eth chip is used in your case Bananapi-m4-berry: h618 ==> Eth chip rtl8211f ==> connecting socket Bananapi-m4-zero: h618 ==> Eth chip ???? ==> connecting socket As far as I understand, this is some kind of expansion card for the 26 pin connector. Can you post a diagram of this expansion board here. The brand of the Ethernet chip matters.
-
Hello everyone, I'm currently working on a custom firmware project for the Allwinner V851S/V851SS SoC (e.g., dash cam or smart camera). I've reached the stage where I need to modify and re-sign the firmware images (TOC0/TOC1) for use with tools like PhoenixCard. Unfortunately, the tools found on GitHub (e.g., dragonsecboot, pack_tools, boot0, etc.) are often incomplete or fail to build due to missing references (e.g., rsa_sign_main, GetFullPath, etc.). 🔍 I'm looking for a complete and working version of the following tools: dragonsecboot pack boot0 sunxi_tools Full config files such as dragon_toc.cfg, sys_config.fex Working pack_tools with all required source files Full Tina SDK for V851S or V851SS 🎯 My goal is to properly sign and rebuild TOC0/TOC1 and PACKAGE images, and build a customized embedded Linux system. 📤 If anyone has the official SDK or a working toolchain, I’d really appreciate it if you could share it via Google Drive, Mega, Transfer.sh, or any other file host. Thank you in advance to anyone who can help 🙏
-
It sounds like you're in a tough spot with your x88 box, but there are definitely a few things you can try to unbrick it. Check Power Supply: As you mentioned, the power supply might be outputting 13V, which is not ideal. It's crucial to have a stable 5V supply for the device to boot properly. If you can, try using a different power adapter (5V, 2A) and see if that helps stabilize the boot process. Use a Correct Recovery Image: Make sure you're using the correct image for the box. It seems like you were trying to burn the image directly, but if the process was interrupted, it could leave your internal storage in an inconsistent state. Try downloading the official firmware for your box model from the manufacturer's site (if available) or from trusted forums where users with similar devices share their files. Try the USB Burning Tool: Some boxes like this one can be recovered using a tool like the USB Burning Tool (if it's based on Rockchip). You can try flashing the firmware through USB using the tool while the box is in recovery mode. Here’s a general approach: Download and install the USB Burning Tool. Put your box into MaskROM Mode (this usually involves shorting specific pins or pressing a button while plugging the box into your computer via USB). Connect your device to the PC and use the USB Burning Tool to flash the firmware. Serial Console Output: If you're comfortable with it, connecting a serial console to the box can give you a lot of insight into where things are failing. This could help identify whether it's a hardware or software issue. The serial output could give you error messages that could point to a specific issue (e.g., faulty bootloader or file system corruption). SD Card Recovery: If you can't get it to boot from the internal flash, continue using the SD card with a stable Armbian image. If the internal storage is corrupt, you might still be able to boot and recover your box through the SD card by reinstalling the firmware on the internal storage via the system running off the SD card. If you haven't already, you could also try reaching out to the manufacturer or seller for support, as they might be able to help you with the recovery process. But if that’s not an option, digging into the serial console is definitely your best bet. Good luck! Hopefully, you'll be able to get your device back up and running soon.
-
Good day, respected Balbes150. Please advise an Armbian build for the Roc-rk3588s-pc v1.1, with support for an M.2 NVMe SSD, intended to be used as a "smart home" server. The image will be installed on an SD card. The single-board computer is connected to the home router via Ethernet cable. HDMI is only used temporarily to connect to a TV for initial setup (further configuration will be done via SSH). The board will run Docker containers. Thank you so much in advance!
-
No Audio on Kernel: 6.12.15 and Armbian 25.2.2 Bookworm Minimal
Truenox replied to Truenox's topic in Radxa Rock Pi S
Hello, Any update of this? -
What is the latest version of the RTL8189FS driver?
Igor replied to Kevin Hoang's topic in Beginners
They will provide you new drivers only if you will pay them to do that for you. End users, including this project, can do nothing about - we have negative budget and can only do best-effort work to keep those drivers at least operational with recent kernels: https://github.com/armbian/build/tree/main/patch/misc while bulk of the patches goes directly to the Git of specific driver. What you are hoping exceeds ability of amateur maintainers, those few people that are actually looking into the code and fix bugs that are made by kernel API changes. HW vendor is usually long gone from there - their development capacity is also limited and they are focused into current products. FYI