Alex ThreeD

I can confirm DWC2 usb2 does not see keyboard/flash-drive in u-boot 2024.07. (usb3 port doesn't work either on my board, but the same was in uboot 2024.01 and 2022.07). Also DWC2 init takes significantly longer in 2024.07 (~10 sec, whereas in 2024.01 it took about 1 sec). uboot 2024.01: => usb start starting USB... Bus usb@ff5c0000: USB EHCI 1.00 Bus usb@ff5d0000: USB OHCI 1.0 Bus usb@ff580000: USB DWC2 scanning bus usb@ff5c0000 for devices... 1 USB Device(s) found scanning bus usb@ff5d0000 for devices... 1 USB Device(s) found scanning bus usb@ff580000 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found uboot 2024.07: => usb start starting USB... Bus usb@ff580000: USB DWC2 Bus usb@ff5c0000: USB EHCI 1.00 Bus usb@ff5d0000: USB OHCI 1.0 scanning bus usb@ff580000 for devices... 1 USB Device(s) found scanning bus usb@ff5c0000 for devices... 1 USB Device(s) found scanning bus usb@ff5d0000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found

Hi, @jock Do you have functional ethernet in uboot? At first it was not work at all with eth probe error: No PHY reset control found: ret=-61 Then I've replaced reset handle location in u-boot/drivers/net/gmac_rockchip.c: - ret = reset_get_by_name(dev, "mac-phy", &pdata->phy_reset); + ret = reset_get_by_index_nodev(args.node, 0, &pdata->phy_reset); Now, eth probes without errors but has 50% packet loss (uboot's netconsole is unusable), negotiate at 10Mbit, and every second boot or so it doesn't work at all.

I've finally managed to boot from btrfs in uboot 2024.01. The problem was not a new bug (there was only a few small btrfs related changes since previously used uboot 2022.10), but some old limitations/bugs uncovered by uboot's switch from distroboot to bootflow. One bug has already been fixed in 2024.04 and another (out of bounds write) is not fixed yet. I have sent PR to armbian and will try to push it uboot upstream (ohhh, good ol maillists)

👍

Well, boot completes without problems on ext4. The problem was in btrfs root-/boot-fs. It is broken again in uboot 24.01 (I'll try to look into it later)

Boot process stops after these lines: Cannot lookup file /extlinux/extlinux.conf Cannot lookup file /boot/extlinux/extlinux.conf Cannot lookup file /boot.scr.uimg Cannot lookup file /boot.scr Cannot lookup file /boot/boot.scr.uimg Cannot lookup file efi/boot/bootaa64.efi Card did not respond to voltage select! : -110 No ethernet found. No ethernet found. => It seems that my /boot/boot.scr is silently ignored (at first i was thought it is not even looked for because there is no "Cannot lookup file /boot/boot.scr"). I'll try to enable more logs somehow. File definitely could be loaded by uboot, when I do it manually: => load mmc 1 $loadaddr /boot/boot.scr 5143 bytes read in 14 ms (358.4 KiB/s) => md.b $loadaddr 80 00800800: 27 05 19 56 ad 25 ac 5b 66 65 49 4f 00 00 13 d7 '..V.%.[feIO.... 00800810: 00 00 00 00 00 00 00 00 6d 84 bc 01 05 02 06 00 ........m....... 00800820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00800830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00800840: 00 00 13 cf 00 00 00 00 23 20 44 4f 20 4e 4f 54 ........# DO NOT 00800850: 20 45 44 49 54 20 54 48 49 53 20 46 49 4c 45 0a EDIT THIS FILE. 00800860: 23 0a 23 20 50 6c 65 61 73 65 20 65 64 69 74 20 #.# Please edit 00800870: 2f 62 6f 6f 74 2f 61 72 6d 62 69 61 6e 45 6e 76 /boot/armbianEnv

Hi @jock. Main branch with new uboot 2024.1 is not ready to boot yet, right? (It seems new uboot doesn't even look for /boot/boot.scr) Nice HDMI output in uboot, btw, thanks!

@shellless USB as GND source sound legit. Just to double check that you are correctly wired UART - have you tried to swap RX/TX? I have a board that looks exactly the same as yours: GND is a last drill hole on a board corner (probably there is nothing to afraid of soldering), then board's TX, board's RX, and VCC (next to the IR receiver). Baudrate 1500000. Also, be aware that sometimes board does not fully reset with board's RX pin connected to PC (it seems some components still powered up by RX pin). So I have to temporary disconnect RX pin. AFAIK Armbian does not need bootloader on emmc. So emmc could be cleared, masked or unsoldered.

from the photos it seem you didn't connect GND uart pin

@suser try to set another "display type" values in openvfd config: https://github.com/arthur-liberman/vfd-configurations

Fixed https://github.com/armbian/build/pull/5723 Here is (probably not so interesting) list of modelines that available with and without this patch on FullHD monitor: Modelines enabled by rk356x-vop2-support.patch: Modeline "1920x1080": 60 148352 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5 Modeline "1920x1080i": 60 74176 1920 2008 2052 2200 1080 1084 1094 1125 0x40 0x15 Modeline "1680x1050": 60 119000 1680 1728 1760 1840 1050 1053 1059 1080 0x40 0x9 Modeline "1280x1024": 75 135000 1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5 Modeline "1280x800": 60 71000 1280 1328 1360 1440 800 803 809 823 0x40 0x9 Modeline "1280x720": 60 74176 1280 1390 1430 1650 720 725 730 750 0x40 0x5 Modeline "1024x768": 75 78750 1024 1040 1136 1312 768 769 772 800 0x40 0x5 Modeline "832x624": 75 57284 832 864 928 1152 624 625 628 667 0x40 0xa Modeline "800x600": 75 49500 800 816 896 1056 600 601 604 625 0x40 0x5 Modeline "720x480": 60 27027 720 736 798 858 480 489 495 525 0x40 0xa Modeline "720x480": 60 27027 720 736 798 858 480 489 495 525 0x40 0xa Modeline "640x480": 75 31500 640 656 720 840 480 481 484 500 0x40 0xa Modeline "640x480": 60 25200 640 656 752 800 480 490 492 525 0x40 0xa Modeline "640x480": 60 25175 640 656 752 800 480 490 492 525 0x40 0xa Modeline "640x480": 60 25175 640 656 752 800 480 490 492 525 0x40 0xa Modeline "720x400": 70 28320 720 738 846 900 400 412 414 449 0x40 0x6 Modelines available both with and without this patch: Modeline "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5 Modeline "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5 Modeline "1920x1080i": 60 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x40 0x15 Modeline "1920x1080i": 60 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x40 0x15 Modeline "1920x1080": 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5 Modeline "1920x1080i": 50 74250 1920 2448 2492 2640 1080 1084 1094 1125 0x40 0x15 Modeline "1600x900": 60 108000 1600 1624 1704 1800 900 901 904 1000 0x40 0x5 Modeline "1280x1024": 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x40 0x5 Modeline "1152x864": 75 108000 1152 1216 1344 1600 864 865 868 900 0x40 0x5 Modeline "1280x720": 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5 Modeline "1280x720": 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5 Modeline "1280x720": 50 74250 1280 1720 1760 1980 720 725 730 750 0x40 0x5 Modeline "1024x768": 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa Modeline "800x600": 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5 Modeline "720x576": 50 27000 720 732 796 864 576 581 586 625 0x40 0xa Modeline "720x576": 50 27000 720 732 796 864 576 581 586 625 0x40 0xa Modeline "720x480": 60 27000 720 736 798 858 480 489 495 525 0x40 0xa Modeline "720x480": 60 27000 720 736 798 858 480 489 495 525 0x40 0xa Modeline "720x480": 60 27000 720 736 798 858 480 489 495 525 0x40 0xa

@jock good news! I have finally found a root cause: rk356x-vop2-support.patch Without this patch HDMI is OK. Apparently this happend due to one hunk of rk356x-vop2-support.patch lost in transition 6.3 -> 6.4: - if (pclk == mpll_cfg[i].mpixelclock) { + if (pclk <= mpll_cfg[i].mpixelclock) { I can fix this patch and check everything is ok, but I'm not sure whether this patch is still needed given that 4k resolution already added to mainline 6.4. What to you think?

@jock Hi, I've seen your comment on HDMI not working with 6.5 egde kernel: https://github.com/armbian/build/pull/5657#issuecomment-1703880889 Have you had time to investigate it since then? At first I've tried to revert one suspicious drm fbdev commit, but it doesn't help. Then I've enabled kernel drm debug (drm.debug=0x1bf in kernel command line) and it shed some light on a problem. 6.5 kernel rejected to use all modelines available (the same modelines was not rejected by 6.1): > [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5 > [drm:drm_mode_prune_invalid] Not using 1920x1080 mode: BAD > ... Can you suggest a direction for further diagnostics? dmesg-6.1.txtdmesg-6.5.txt PS I'm not sure where is best place to discuss it - here or on github.

Yeah, I've seen suggestions to lock cpufreq here on forum and checked it before starting voltage experiments. Here are my observations (on RK3328 box): 1) I have not seen stability issues with stock rk3318-box install with default 1.1 GHz limit 2) Stability issues appear after enabling "RK3328 (max 1.3GHz)" option in rk3318-config 3) Locking cpufreq to 1.3GHz in armbian-config does not help to mitigate issues (I've verified that cpu frequency are actually locked in `htop` output) 4) I've changed boot dtb to rk3318-a95x-z2.dtb and disabled rockchip-rk3318-box-cpu-hs.dtbo overlay. With this setup there was no issues. 5) Finally I've changed back boot dtb to rk3318-box.dtb and activated a patched rockchip-rk3318-box-cpu-hs.dtbo overlay with increased voltages only for 1.2-1.3GHz. No stability issues both for a few hours of stress test and for a few weeks of common use. Here is my patched rockchip-rk3318-box-cpu-hs.dtbo source: /dts-v1/; / { fragment@0 { target-path = "/opp_table0/opp-1200000000"; __overlay__ { opp-microvolt = <0x12b128>; status = "okay"; }; }; fragment@1 { target-path = "/opp_table0/opp-1296000000"; __overlay__ { opp-microvolt = <0x13d620>; status = "okay"; }; }; fragment@2 { target-path = "/opp_table0"; __overlay__ { opp-408000000 { opp-hz = <0x00 0x18519600>; opp-microvolt = <0xe7ef0>; clock-latency-ns = <0x9c40>; opp-suspend; }; }; }; }; As you see I've also added 408MHz setting, but it is probably not needed. I've seen no measurable difference in power consumption at 400MHz vs 600MHz. I haven't tried it yet. I could check it if you find it useful

Hi @jock. I've found my rk3328 box have stability issues on 1.2-1.3 GHz with default voltage in rk3318-box.dtb. It hangs out every few days with kernel oops or something alike. It works fine with opp-microvolt values for 1.2-1.3 GHz taken from rk3318-a95x-z2.dtb (i.e +0.025V). I'm not sure whether such increase are bad for other boards, probably you could consider making it a default in rk3318-box.dtb. I've found a simple way to trigger stability issues: connect a display, run `glmark2`/`glmark2-wayland`/`glmark2-drm` and `armbianmonitor -z` in infinite loop simultaneously. With `rk3318-box.dtb` voltages system hangs up in 5-10 minutes. With `rk3318-a95x-z2.dtb` voltages it runs for hours without issues.