Slawek Posted September 5 Posted September 5 Hi, I'm using Nanopi DUO2 for few IoT projects. Using the microUSB serial console connection is very convenient and fast method to manage this SBC. Unfortunately with latest version of Armbian (tested with v24.11.0) it not working any more. Version 23.11.1 works fine out from the box, but after sudo apt update && sudo apt full-upgrade the microUSB serial console is not available. Any suggestion how to switch it back will be very appreciated. Slawek 0 Quote
robertoj Posted September 5 Posted September 5 Make sure that /boot/armbianEnv.txt is the same from the time it was working, to what it is today (the line “overlays=“) 0 Quote
Slawek Posted September 5 Author Posted September 5 OK I will check and return back with update. 0 Quote
robertoj Posted September 5 Posted September 5 If still not working, install the newest OS image in a different microSD card, verify that you have the USB-serial function. Then check the differences in armbianEnv.txt, and the result of "lsmod", against your old microSD. If you succeed or not, post your results here, because that's how we build up the knowledge base. 0 Quote
Slawek Posted September 6 Author Posted September 6 Hi I did following steps: install fresh Armbian_23.11.1_Nanopiduo2_jammy_current_6.1.63.img.xz. After boot the COM19 is available: root@nanopiduo2:~# cat /boot/armbianEnv.txt verbosity=1 bootlogo=false console=serial disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=usbhost0 usbhost2 usbhost3 fdtfile=sun8i-h3-nanopi-duo2.dtb rootdev=UUID=0cff826e-57ba-4014-a11e-8827efd9a1a0 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u root@nanopiduo2:~# lsmod Module Size Used by sunrpc 339968 1 hci_uart 61440 0 btbcm 16384 1 hci_uart bluetooth 540672 3 hci_uart,btbcm lz4hc 16384 0 lz4hc_compress 24576 1 lz4hc brcmfmac 188416 0 ecdh_generic 16384 1 bluetooth ecc 28672 1 ecdh_generic brcmutil 16384 1 brcmfmac lz4 16384 0 lz4_compress 32768 1 lz4 sunxi_cedrus 40960 0 sun4i_gpadc_iio 16384 0 industrialio 61440 1 sun4i_gpadc_iio cfg80211 573440 1 brcmfmac v4l2_mem2mem 20480 1 sunxi_cedrus videobuf2_dma_contig 20480 1 sunxi_cedrus videobuf2_memops 20480 1 videobuf2_dma_contig videobuf2_v4l2 20480 2 sunxi_cedrus,v4l2_mem2mem sun8i_thermal 16384 0 videobuf2_common 45056 5 sunxi_cedrus,videobuf2_dma_contig,videobuf2_memops,v4l2_mem2mem,videobuf2_v4l2 rfkill 20480 5 bluetooth,cfg80211 videodev 167936 4 sunxi_cedrus,videobuf2_common,v4l2_mem2mem,videobuf2_v4l2 mc 40960 5 sunxi_cedrus,videobuf2_common,videodev,v4l2_mem2mem,videobuf2_v4l2 evdev 20480 1 cpufreq_dt 20480 0 uio_pdrv_genirq 20480 0 uio 16384 1 uio_pdrv_genirq zram 24576 3 binfmt_misc 20480 1 sch_fq_codel 20480 3 usb_f_acm 20480 1 u_serial 24576 3 usb_f_acm g_serial 16384 0 libcomposite 45056 2 g_serial,usb_f_acm ip_tables 24576 0 x_tables 28672 1 ip_tables autofs4 36864 2 ac200_phy 16384 1 pwrseq_simple 16384 1 dwmac_sun8i 28672 0 stmmac_platform 24576 1 dwmac_sun8i stmmac 172032 2 stmmac_platform,dwmac_sun8i pcs_xpcs 20480 1 stmmac phylink 36864 2 pcs_xpcs,stmmac mdio_mux 16384 2 dwmac_sun8i sunxi 16384 0 phy_generic 20480 2 sunxi gpio_keys 20480 0 then I run: apt update && apt full-upgrade and reboot the COM19 is gone from my Windows PC root@nanopiduo2:~# cat /boot/armbianEnv.txt verbosity=1 bootlogo=false console=serial disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=usbhost0 usbhost2 usbhost3 fdtfile=sun8i-h3-nanopi-duo2.dtb rootdev=UUID=0cff826e-57ba-4014-a11e-8827efd9a1a0 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u no difference to previous one and root@nanopiduo2:~# lsmod Module Size Used by sunrpc 339968 1 hci_uart 61440 0 btbcm 16384 1 hci_uart bluetooth 540672 3 hci_uart,btbcm lz4hc 16384 0 lz4hc_compress 24576 1 lz4hc brcmfmac 188416 0 ecdh_generic 16384 1 bluetooth ecc 28672 1 ecdh_generic brcmutil 16384 1 brcmfmac lz4 16384 0 lz4_compress 32768 1 lz4 sunxi_cedrus 40960 0 sun4i_gpadc_iio 16384 0 industrialio 61440 1 sun4i_gpadc_iio cfg80211 573440 1 brcmfmac v4l2_mem2mem 20480 1 sunxi_cedrus videobuf2_dma_contig 20480 1 sunxi_cedrus videobuf2_memops 20480 1 videobuf2_dma_contig videobuf2_v4l2 20480 2 sunxi_cedrus,v4l2_mem2mem sun8i_thermal 16384 0 videobuf2_common 45056 5 sunxi_cedrus,videobuf2_dma_contig,videobuf2_memops,v4l2_mem2mem,videobuf2_v4l2 rfkill 20480 5 bluetooth,cfg80211 videodev 167936 4 sunxi_cedrus,videobuf2_common,v4l2_mem2mem,videobuf2_v4l2 mc 40960 5 sunxi_cedrus,videobuf2_common,videodev,v4l2_mem2mem,videobuf2_v4l2 evdev 20480 1 cpufreq_dt 20480 0 uio_pdrv_genirq 20480 0 uio 16384 1 uio_pdrv_genirq zram 24576 3 binfmt_misc 20480 1 sch_fq_codel 20480 3 usb_f_acm 20480 1 u_serial 24576 3 usb_f_acm g_serial 16384 0 libcomposite 45056 2 g_serial,usb_f_acm ip_tables 24576 0 x_tables 28672 1 ip_tables autofs4 36864 2 ac200_phy 16384 1 pwrseq_simple 16384 1 dwmac_sun8i 28672 0 stmmac_platform 24576 1 dwmac_sun8i stmmac 172032 2 stmmac_platform,dwmac_sun8i pcs_xpcs 20480 1 stmmac phylink 36864 2 pcs_xpcs,stmmac mdio_mux 16384 2 dwmac_sun8i sunxi 16384 0 phy_generic 20480 2 sunxi gpio_keys 20480 0 Should I test also installation of latest Armbian_community_24.11.0-trunk.66_Nanopiduo2_noble_current_6.6.44.img.xz before_upgrade.txt after_upgrade.txt 0 Quote
robertoj Posted September 6 Posted September 6 I cant see the problem XD In this latest-working setup, run "armbianmonitor -u" to get a snapshot of the boot execution, and copy the resulting link here. Also, show the result of "dmesg | grep g_serial" (the ko driver that enables the USB-serial-device function in the CPU. Try again with the Armbian_community_24.11.0-trunk.66_Nanopiduo2_noble_current_6.6.44.img.xz. Verify that the USB-serial-device function is working. Don't update, and run the 2 tests as above: armbianmonitor and dmesg|grep g_serial 0 Quote
Slawek Posted September 6 Author Posted September 6 Sir Yes Sir 😉 .... but not until a few hours later, I have to do some urgent work now. Thank you very much for your effort. Will be back with reports soon. 0 Quote
Slawek Posted September 6 Author Posted September 6 Voila: Armbian_23.11.1_Nanopiduo2_jammy_current_6.1.63.img.xz root@nanopiduo2:~# armbianmonitor -u Collecting info and sending to paste.armbian.com, wait... https://paste.armbian.com/jareyilapa root@nanopiduo2:~# dmesg | grep g_serial [ 7.735341] g_serial gadget.0: Gadget Serial v2.4 [ 7.735366] g_serial gadget.0: g_serial ready Armbian_community_24.11.0-trunk.66_Nanopiduo2_noble_current_6.6.44.img.xz root@nanopiduo2:~# armbianmonitor -u Collecting info and sending to paste.armbian.com, wait... /usr/bin/armbianmonitor: line 976: iostat: command not found https://paste.armbian.com/hogapesowi root@nanopiduo2:~# dmesg | grep g_serial [ 6.003420] UDC core: g_serial: couldn't find an available UDC [ 8.984241] g_serial gadget.0: Gadget Serial v2.4 [ 8.984274] g_serial gadget.0: g_serial ready first line above looks suspicious IMHO .... 0 Quote
robertoj Posted September 6 Posted September 6 Looks like UDC is a part of the g_serial that fails to load. Not an easy problem for me. Just revert to working OS, and reinstall your applications Similar problems: https://support.xilinx.com/s/question/0D52E00006iHmGwSAK/usb-udccore-couldnt-find-an-available-udc-added-gmassstorage-to-list-of-pendi?language=en_US https://stackoverflow.com/questions/65012555/how-to-enable-usb-gadget-mode-from-menuconfig https://github.com/gokrazy/kernel/issues/418 I hope i didnt lose this functionality in my orange pi zero 0 Quote
Slawek Posted September 6 Author Posted September 6 When the SBC is connected to the WiFi network I can ssh - not a problem, but in my setup I'm using most of the pins of NanoPi duo2 including debug uart. So in case of maintenence the mini-usb serial was only option. So I have to be very careful and at any cost avoid upgrading my system. Do you have spare opi zero "on the drawer" to run the test? 0 Quote
robertoj Posted September 6 Posted September 6 I use USB-serial adapters. In my experience they have worked better than the Arm CPU UARTS. The debug UART is the most trusty serial port for maintenance. 0 Quote
nickycakes Posted December 22 Posted December 22 (edited) I spent the better part of the last 2 days taking a crash course in arm device trees and armbian to fix this for myself because I don't want to solder pin headers on every new board and I think I have found the problem. The device tree between 23.11.1 and 24.2.1 changed from what appears to be this commit: ARM: dts: sunxi: H3/H5: Add phys property to USB HCI0 In the most recent bookworm minimal image (Armbian_community_25.2.0-trunk.195_Nanopiduo2_bookworm_current_6.6.62_minimal.img) I decompiled/edited/compiled the device tree via: cd /boot/dtb dtc -I dtb sun8i-h3-nanopi-duo2.dtb -O dts -o sun8i-h3-nanopi-duo2.dts nano sun8i-h3-nanopi-duo2.dts #remove those 4 lines dtc -I dts -O dtb sun8i-h3-nanopi-duo2.dts -o sun8i-h3-nanopi-duo2.dtb reboot After reboot the OTG serial shows up on boot and can be used as normal. I'm not experienced enough yet to know what other implications this has on other things, but someone with more experience can probably read that commit message and figure it out. My next step I think is figuring out how to turn this into a device tree overlay to use in my custom build or figure out how to submit this as some sort of fix for armbian. Edited December 22 by nickycakes 0 Quote
robertoj Posted Thursday at 11:31 AM Posted Thursday at 11:31 AM 👍🏽 check that there are no uboot errors related to loading that dtbo (right before loading the kernel). 0 Quote
nickycakes Posted Saturday at 06:37 AM Posted Saturday at 06:37 AM (edited) On 12/26/2024 at 6:31 PM, robertoj said: 👍🏽 check that there are no uboot errors related to loading that dtbo (right before loading the kernel). i didn't use an overlay because apparently overlays cannot remove lines, only add or modify. I used a patch file on the kernel dtsi and recompiled. uboot logs are identical. here is the fixed version: U-Boot SPL 2024.01-armbian-2024.01-S866c-Pe31d-Ha5c2-Vb835-Bdacf-R448a (Dec 13 2024 - 09:33:36 +0000) DRAM: 512 MiB Trying to boot from MMC1 U-Boot 2024.01-armbian-2024.01-S866c-Pe31d-Ha5c2-Vb835-Bdacf-R448a (Dec 13 2024 - 09:33:36 +0000) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: FriendlyARM NanoPi NEO DRAM: 512 MiB Core: 64 devices, 19 uclasses, devicetree: separate WDT: Not starting watchdog@1c20ca0 MMC: mmc@1c0f000: 0 Loading Environment from FAT... Unable to use mmc 0:1... In: serial,usbkbd Out: serial Err: serial Starting SCP... Net: SCP/INF: Crust v0.6.10000 eth0: ethernet@1c30000 starting USB... Bus usb@1c1a000: sun4i_usb_phy phy@1c19400: External vbus detected, not enabling our own vbus USB EHCI 1.00 Bus usb@1c1a400: USB OHCI 1.0 Bus usb@1c1d000: USB EHCI 1.00 Bus usb@1c1d400: USB OHCI 1.0 scanning bus usb@1c1a000 for devices... 1 USB Device(s) found scanning bus usb@1c1a400 for devices... 1 USB Device(s) found scanning bus usb@1c1d000 for devices... 1 USB Device(s) found scanning bus usb@1c1d400 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 5475 bytes read in 2 ms (2.6 MiB/s) ## Executing script at 43100000 U-boot loaded from SD 273 bytes read in 1 ms (266.6 KiB/s) Load fdt: /boot/dtb/sun8i-h3-nanopi-duo2.dtb 10758303 bytes read in 442 ms (23.2 MiB/s) 8995680 bytes read in 385 ms (22.3 MiB/s) Found mainline kernel configuration 35930 bytes read in 6 ms (5.7 MiB/s) Working FDT set to 43000000 504 bytes read in 3 ms (164.1 KiB/s) Applying kernel provided DT overlay sun8i-h3-usbhost0.dtbo 504 bytes read in 3 ms (164.1 KiB/s) Applying kernel provided DT overlay sun8i-h3-usbhost2.dtbo 504 bytes read in 3 ms (164.1 KiB/s) Applying kernel provided DT overlay sun8i-h3-usbhost3.dtbo 4185 bytes read in 4 ms (1021.5 KiB/s) Applying kernel provided DT fixup script (sun8i-h3-fixup.scr) ## Executing script at 45000000 Kernel image @ 0x42000000 [ 0x000000 - 0x894360 ] ## Loading init Ramdisk from Legacy Image at 43400000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 10758239 Bytes = 10.3 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 Working FDT set to 43000000 Loading Ramdisk to 495bd000, end 49fff85f ... OK Loading Device Tree to 4954b000, end 495bcfff ... OK Working FDT set to 4954b000 Starting kernel ... here is the patch: From 8e3bdad04af35210a4f4b694212351b2c94b119d Mon Sep 17 00:00:00 2001 From: nickycakes <nickycakes@gmail.com> Date: Fri, 27 Dec 2024 04:58:02 +0000 Subject: [PATCH] fix nanopi duo2 otg serial --- arch/arm/boot/dts/allwinner/sunxi-h3-h5.dtsi | 4 ---- 1 file changed, 4 deletions(-) diff --git a/arch/arm/boot/dts/allwinner/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/allwinner/sunxi-h3-h5.dtsi index ade1cd50e445..fef6f6de097b 100644 --- a/arch/arm/boot/dts/allwinner/sunxi-h3-h5.dtsi +++ b/arch/arm/boot/dts/allwinner/sunxi-h3-h5.dtsi @@ -302,8 +302,6 @@ ehci0: usb@1c1a000 { interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_BUS_EHCI0>, <&ccu CLK_BUS_OHCI0>; resets = <&ccu RST_BUS_EHCI0>, <&ccu RST_BUS_OHCI0>; - phys = <&usbphy 0>; - phy-names = "usb"; status = "disabled"; }; @@ -314,8 +312,6 @@ ohci0: usb@1c1a400 { clocks = <&ccu CLK_BUS_EHCI0>, <&ccu CLK_BUS_OHCI0>, <&ccu CLK_USB_OHCI0>; resets = <&ccu RST_BUS_EHCI0>, <&ccu RST_BUS_OHCI0>; - phys = <&usbphy 0>; - phy-names = "usb"; status = "disabled"; }; -- 2.34.1 Edited Saturday at 06:43 AM by nickycakes 0 Quote
Slawek Posted Saturday at 08:02 AM Author Posted Saturday at 08:02 AM Wow! Great job @nickycakes! I'm eager to test.... maybe is there compiled img available? Or I should just compile it myself? 0 Quote
nickycakes Posted Saturday at 08:30 AM Posted Saturday at 08:30 AM 23 minutes ago, Slawek said: is there compiled img available? Or I should just compile it myself? you can compile it yourself by putting the patch i posted above into something like /userpatches/kernel/archive/sunxi-6.6/fix-nanopiduo2-otg-serial.patch and then building, but that will force a recompile of the kernel which takes a while. i would first test it out by editing your device tree in a live system like i did here 0 Quote
nickycakes Posted Saturday at 08:57 AM Posted Saturday at 08:57 AM ok, i'm also happy to report that if you simply build with the 'edge' kernel option (6.11.9 atm) instead of 'current' that it is fixed without having to go through all this trouble. tested on debian 12 and 13. apparently they've fixed it since linux 6.6.65 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.