September 5, 20242 yr 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
September 5, 20242 yr Make sure that /boot/armbianEnv.txt is the same from the time it was working, to what it is today (the line “overlays=“)
September 5, 20242 yr 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.
September 6, 20242 yr Author 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
September 6, 20242 yr 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
September 6, 20242 yr Author 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.
September 6, 20242 yr Author 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 ....
September 6, 20242 yr 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
September 6, 20242 yr Author 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?
September 6, 20242 yr 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.
December 22, 20241 yr 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, 20241 yr by nickycakes
December 26, 20241 yr 👍🏽 check that there are no uboot errors related to loading that dtbo (right before loading the kernel).
December 28, 20241 yr 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 December 28, 20241 yr by nickycakes
December 28, 20241 yr Author Wow! Great job @nickycakes! I'm eager to test.... maybe is there compiled img available? Or I should just compile it myself?
December 28, 20241 yr 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
December 28, 20241 yr Solution 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
January 9, 20251 yr Author Ufffffff after one week battle (many enemies against me ..... wsl2/wrong kernel/Hyper-V/docker) I was able to compile Armbian. I can confirm that 'edge' version of noble and oracular are working fine. We can close the topic IMHO. Thanks guys.
January 10, 20251 yr Author Before I'll open new topic @nickycakes can you reboot system from command line with 'edge' kernel option (6.12.6 atm)? Mine behave like shutdown - I have to unplug/plug the board 🤥
January 11, 20251 yr 19 hours ago, Slawek said: can you reboot system from command line with 'edge' kernel option (6.12.6 atm) no, i think there are individual patches for the stable kernels that do this that wouldnt be automatically applied to the edge kernel, see /patch/kernel/archive/sunxi-6.11/patches.armbian/ARM-dts-sun8i-nanopiduo2-Use-key-0-as-power-button.patch in the armbian build repo
January 15, 20251 yr Author Hi @nickycakes this patch is related to hardware button I have a problem with console reboot now command. I make some investigation which kernel version from edge branch has boot and serialUSB. Here are the results: but I have no idea what is source of problem. For the moment will play with 6.10.9 ver. Maybe I should open new topic on the forum?
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.