All Activity

FYI. HDMI out is broken on those board at the moment. Try to access the board remotely. We don't have people to maintain those old boards.

I've noticed some other threads about Banana Pi builds not booting. I tried the 6.12v built on Jun 19 and that's when my device stopped booting. It won't even power on. I suspect the firmware update is corrupting the MicroSD card. I originally had an older build running and ran an update/upgrade and my system wouldn't boot (won't power on) after that. I purchased a new MicroSD card, and my system booted with an older build. Not realizing my MicroSD would get corrupted, I tried updating/upgrading again and I'm back to not booting. I don't have enough MicroSD cards to pinpoint the exact package. My working build is from 6.6.17, 24.5.0-trunk.58. It appears the archive is even older than that! Is there any way to revive a MicroSD card? I'm using SDFormatter to prep the card and Win32DiskImager to write the image.

Your commands looks ok, but you need to use hk1-x3, not hk1-box Your runtime device-tree do contains the display-controller under /proc/device-tree/i2c-display. So your correctly copying your dtb, but device-tree/i2c-display/sda-gpios and device-tree/i2c-display/scl-gpios shows pin of hk1-box, not hk1-x3. You also need to remove any references to OpenVFD from your device tree. This will create conflicts if you have multiple nodes using the same pins. Your dmesg also has some messages about the i2c bus on which is connected your display controller: [ 3.787786] gpio-576 (sda): enforced open drain please flag it properly in DT/ACPI DSDT/board file [ 3.792897] gpio-577 (scl): enforced open drain please flag it properly in DT/ACPI DSDT/board file [ 3.802509] i2c-gpio i2c-display: using lines 576 (SDA) and 577 (SCL) If course, you need to first configure the right pins by using hk1-x3 (and removing openvfd). Then you can investigate remaining i2c issues, if any.

Here are the actions I take with the dtb file. Maybe I'm doing something wrong here? # cd /home/INSTALKI # git clone https://github.com/jefflessard/tm16xx-display.git # cd tm16xx-display # cp /boot/dtb/amlogic/meson-sm1-x96-air-gbit.dtb original.dtb # make hk1-box.dtb ORIGINAL_DTB=original.dtb # cp release/hk1-box.dtb /boot/dtb/amlogic/meson-sm1-x96-air-gbit.dtb # reboot

In the /proc/device-tree directory I do not see any "tm16xx" entry but there is an "openvfd" entry. Attached is the /proc/device-tree directory and the dmesg output. device-tree.tar.gz dmseg.txt

looks like a kernel oops does the unit run properly afterwards?

Thank you for that information. From a cursory look, it seems as if that is only binary images, no source (violating GPL).

I will try to make that easier and more automatic with APA, eventually.

Thank you for letting us know as it allows an interested party to more easily bisect the regression.

download all files attenmented . sudo cp *.dtbo /boot/dtb/allwinner/overlay open /boot/armbianEnv.txt , add this line: overlays=spi-spidev spidev1_1 and reboot, you should find and use /dev/spidev1.1 sun50i-h616-spidev1_0.dtbo sun50i-h616-spidev1_0.dtso sun50i-h616-spidev1_1.dtbo sun50i-h616-spidev1_1.dtso

what is this? [code] [ 20.585289] ------------[ cut here ]------------ [ 20.585313] memcpy: detected field-spanning write (size 16) of single field "vif->key[pairwise][key_index]" at drivers/net/wireless/uwe5622/unisocwifi/cfg80211.c:714 (size 0) [ 20.585442] WARNING: CPU: 0 PID: 863 at drivers/net/wireless/uwe5622/unisocwifi/cfg80211.c:714 sprdwl_cfg80211_add_key+0x124/0x138 [sprdwl_ng] [ 20.585498] Modules linked in: overlay sprdwl_ng sunxi_addr cfg80211 sunrpc zram snd_soc_hdmi_codec sunxi_cedrus(C) v4l2_mem2mem videobuf2_dma_contig polyval_ce videobuf2_memops videobuf2_v4l2 polyval_generic binfmt_misc videodev snd_soc_sunxi_machine dw_hdmi_i2s_audio panfrost dw_hdmi_cec sun50i_h6_prcm_ppu snd_soc_sunxi_ahub videobuf2_common gpu_sched snd_soc_sunxi_ahub_dam mc drm_shmem_helper display_connector dump_reg cpufreq_dt sch_fq_codel sprdbt_tty uwe5622_bsp_sdio rfkill fuse motorcomm dwmac_sun8i mdio_mux sun6i_rtc_ccu [ 20.585645] CPU: 0 UID: 0 PID: 863 Comm: wpa_supplicant Tainted: G C 6.15.0-edge-sunxi64 #1 NONE [ 20.585657] Tainted: [C]=CRAP [ 20.585661] Hardware name: OrangePi Zero3 (DT) [ 20.585667] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 20.585675] pc : sprdwl_cfg80211_add_key+0x124/0x138 [sprdwl_ng] [ 20.585701] lr : sprdwl_cfg80211_add_key+0x124/0x138 [sprdwl_ng] [ 20.585725] sp : ffff80008494b740 [ 20.585730] x29: ffff80008494b740 x28: ffff0000c1d32180 x27: ffff0000c08fb080 [ 20.585745] x26: 0000000000000000 x25: ffff0000c4600a40 x24: ffff0000c4600000 [ 20.585758] x23: 0000000000000004 x22: 0000000000000004 x21: 0000000000000010 [ 20.585772] x20: 0000000000000000 x19: ffff80008494b790 x18: 00000000ffffffff [ 20.585785] x17: 0000000000000000 x16: 0000000000000000 x15: 7269772f74656e2f [ 20.585799] x14: 7372657669726420 x13: 30386766632f6966 x12: ffff8000823482d0 [ 20.585813] x11: 0000000000000001 x10: 0000000000000001 x9 : ffff8000800df178 [ 20.585826] x8 : c0000000ffffefff x7 : ffff8000822f00e8 x6 : 0000000000000001 [ 20.585840] x5 : ffff0000ff734708 x4 : 0000000000000000 x3 : 0000000000000027 [ 20.585853] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c1d32180 [ 20.585868] Call trace: [ 20.585874] sprdwl_cfg80211_add_key+0x124/0x138 [sprdwl_ng] (P) [ 20.585901] nl80211_new_key+0x1c4/0x320 [cfg80211] [ 20.586017] genl_family_rcv_msg_doit+0xe8/0x160 [ 20.586032] genl_rcv_msg+0x218/0x298 [ 20.586040] netlink_rcv_skb+0x68/0x140 [ 20.586053] genl_rcv+0x40/0x60 [ 20.586060] netlink_unicast+0x2f4/0x358 [ 20.586071] netlink_sendmsg+0x1b0/0x408 [ 20.586082] __sock_sendmsg+0x64/0xc0 [ 20.586093] ____sys_sendmsg+0x24c/0x2c0 [ 20.586101] ___sys_sendmsg+0xb8/0x118 [ 20.586110] __sys_sendmsg+0xa4/0x110 [ 20.586119] __arm64_sys_sendmsg+0x2c/0x40 [ 20.586128] invoke_syscall+0x50/0x120 [ 20.586142] el0_svc_common.constprop.0+0x48/0xf0 [ 20.586153] do_el0_svc+0x24/0x38 [ 20.586163] el0_svc+0x30/0xd0 [ 20.586175] el0t_64_sync_handler+0x10c/0x138 [ 20.586185] el0t_64_sync+0x198/0x1a0 [ 20.586195] ---[ end trace 0000000000000000 ]--- [/code]

You have checked that neither

@KrzyPacu your Android DTS confirms the pinout of hk1-x3 fd628_dev { compatible = "amlogic,fd628_dev"; fd628_gpio_clk = <0x12 0x41 0x00>; fd628_gpio_dat = <0x12 0x40 0x00>; status = "okay"; }; 0x40 is data pin 64 0x41 is clock pin 65 So there must be something wrong with how you are copying the dtb to boot. Maybe to the wrong location. Ensure you have the proper dtb loaded at runtime by inspecting /proc/device-tree

Moved to Community supported forum as this isn't a standard support board.

OrangePi 4A Bluetooth Mouse Keyboard connectivity issue Solved The solution to the problem when mouse pairs / connects with BT but doesnt work Prebuilt kernel files are available https://github.com/defencedog/orangepi4A/blob/main/Bluetooth%20Mouse%20Not%20Working%20Solved.md

Yes it worked fine on the other Armbian OS. Unfortunately it still doesn't work. android-vontar-x3.dts

While searching the forum and the documentation, I found the list of mirrors. On some of them, it's possible to find an older version of Armbian (23.11.1). I installed that version and it seems the drivers are working — I was able to use HDMI. This is the mirror I used: https://armbian.atomonetworks.com/archive/cubieboard/archive/

Please, I need an img of Armbian compatible with the following: RK3399T and with HDMI. I have tried all versions of Armbian and they do not work. Some do, but the problem is that it does not display an image. I believe it could be the HDMI. The most preferable versions for me are Armbian Noble or Bookworm. The problem also occurs during updates. After updating, the wireless does not work. If there is a version with this fixed, I would be grateful if someone could post a version for me, as up-to-date as possible. My Radxa is a Rock Pi 4Plus v1.73. With a 256GB microSD, I need an img of Armbian that is compatible with wireless and HDMI. If anyone can send me the link, I would be grateful!

True. Also on most computers we have eth0 Not just eth Devices naming is a cosmetic thing from the outside / user perspection, while it has consistency issue from the inside and currently breaks initial (default netplan) configuration. Our job is not to tell user how to configure his network, but that network devices gets up at first boot. Now they do. Job done.

I am not sure if this line in the yaml file makes sense: all-wan-interfaces: # include interfaces that are renamed to 'wanX' by udev, e.g. nanopi-r1 There is usually only 1 WAN interface on routers. The print on my R6C is "WAN" and "LAN1". WAN is clearly the Rockchip GMAC. Actually I use it as 'LAN', as the only RJ45 cable. Only temporary I also use the PCI-E / 2.5GbE port while bridging with the GMAC, so I have a real 2.5GbE port as peer for my ROCK5B (just for speedtests). For the R5C, the Rockchip GMAC is not used. A rename from WAN to WAN1 I would refuse, but I do not use netplan.io, so not affected. I have the R6C now flashed with EDK2-UEFI and running Tumbleweed. 70-persistent-net.rules is empty, but Armbian 6.15.2-edge-rockchip64 kernel. I am not sure why the naming is still OK (wan and lan1, so my .nmconnection files keep working). With other kernel it gets end0 and enP3p49s0, I might use those eventually, ignoring what is printed on the case, depends how often I am going to unplug/plug network cables. For the R5C, the ports in the schematics are named "LAN1" and "LAN2", not sure how they map to what is printed on the case. They are each 1 lane of the PCIE3x2, that might be a problem for some kernel and/or bootloader.

Hi Loeriver, Where is the other end of your USB serial dongle connected to? Can you check there if the dongle had disappeard from the USB bus and re-appeared around the same time? In my "professional" life we have had workstations mysteriously reboot whenever we would power cycle the device hosting the USB to serial device. Even though you say it's not related, if this is still mysterious, best to check under each stone... Groetjes,

Thank you for this very helpful hint. I have installed auditd, I thought I have to systemctl (start, enable) auditd also to have it watching: but this seems to have been done by the install cmd already, as it is running. As I saw a burst of 7225 (!) sysrq messages in the log for 2025-06-18, between 08:55 and 09:50 again I am rather nervous about this topic. Since then no new messages again. Mysterious ... Greetings.

I just found one weird setting on R6S. Can you provide what is in this file: cat /etc/udev/rules.d/70-persistent-net.rules Reference for what to do: https://github.com/armbian/build/pull/8325

From the picture - I can only guess that kernel package was somehow not upgraded properly as kernel image files are missing. Perhaps they were removed by accident or there was some disk / file system troubles involved. @Chris007 Try hints from here: https://docs.armbian.com/User-Guide_Troubleshooting/