All Activity

Is it enough to remove these entries from the dts file and recompile it to dtb? 3535-3540 openvfd { compatible = "open,vfd"; dev_name = "openvfd"; status = "okay"; phandle = <0x143>; }; 4031 openvfd = "/openvfd"; meson-sm1-x96-air-gbit.dts

But how do I do that? These are the original Armbian .dtb entries. I didn't add anything and I don't know how to remove it.

Armbian_25.2.2_Rock-5-itx_noble_vendor_6.1.99_gnome_desktop.img.xz I first tried this, as it was the first version offered at the top of the page. No matter what I tried, sound would *not* work. Not speakers, not HDMI, nada, zip. I then started trying earlier versions further down the page. Armbian_25.2.2_Rock-5-itx_bookworm_vendor_6.1.99_cinnamon-backported-mesa_desktop.img.xz And this one, sound *did* work, at least through the speaker jack anyway, but I suspect HDMI would too. I'm really suspecting something kernel related is going here (that "Rockchip BSP" note right above it makes me suspect that). In any case, I'd like to use the kernel where sound is working and put a gnome shell in front of it. Which I take means digging into the build system for armbian? I can figure that out on my own but before I get started on that, what I'm looking for from the forumistas, is an indication of which specific kernel I need to use to make sure sound works. What do I need to make sure to specify so I get the behavior of that second install that worked? And Cinnamon may be better or something, but gnome is what I'm used to.

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,