Alex ThreeD

Maybe I'm not right, but I think emmc here has a priority over sdcard. AFAIC hardware BootROM first tries to load TPL/SPL from emmc and then if it is failed BootROM tries to load TPL/SPL from sdcard. Proprietary SPL found on stock emmc first tries to load trustos/uboot-proper from sdcard and then from emmc (the opposite priorities here). The good news is that proprietary SPL doesn't use fixed sdcard locations, but tries a few locations in range 8-16 MB at the start of sdcard (backups in case of broken flash memory?). So we could use (currently unused) area near the end of first 16MB block to place additional trust/uboot in a format suitable for proprietary SPL - it won't be used during "normal" boot after emmc wipe, but it would allow to check Armbian loaded from sdcard in "live" mode before wipe. Ok, I understand your concerns with proprietary blobs, wont push it further.

@jock What do you think about plug-and-play Armbian image that can boot from SD on stock STB without original firmware wipe from eMMC, just like multitool? From your previous messages in this thread it looks you have concerns with rk blob bootloader security, and want to wipe original bootloader ASAP I’ve made some experiments and managed to make SD layout with dual u-boot: first u-boot is the same as it is now (with upstream opensource ATF, etc), second u-boot is blob-only that is used only to boot on STB with stock bootloader on eMMC. Will you accept such a PR?

@Matt H. have you tried to boot X88 from this sd-card? NTFS partition probably will be resized on the first boot. Burning tools just write image file as-is, it is not intelligent enough to resize partitions for different SD sizes

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.

Hi! I'd like to share my findings on running UxPlay AirPlay Mirror server on rk3328 box. Default setup with x11 works quite bad on Armbian 23.05 (Armbian_23.5.1_Rk3318-box_bookworm_current_6.1.30_xfce_desktop.img). Video playback falls behind of realtime both for default video output method (autovideosink) and for -vs xvimagesink/glimagesink. At the same time uxplay with kmssink or waylandsink video output works without issues: # chvt 2 # uxplay -vs kmssink In all these cases CPU usage are far from 400% and even lower than 100%, so I assume that 1080p h264 video stream are HW-decoded but there are some stalls happening in x11 graphic stack (xorg config 40-serverflags.conf doesn't help). I've also ran glmark2 tests to confirm a problems with x11. OpenGL/GLES are 3-5 times less performant under x11 than under wayland/drm. rk3318-box:~:# glmark2 --fullscreen glmark2 2023.01 ======================================================= OpenGL Information GL_VENDOR: lima GL_RENDERER: Mali450 GL_VERSION: 2.1 Mesa 22.3.6 Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0 samples=0 Surface Size: 1920x1080 fullscreen ======================================================= [build] use-vbo=false: FPS: 41 FrameTime: 24.919 ms ... ======================================================= glmark2 Score: 29 ======================================================= rk3318-box:~:# glmark2-wayland --fullscreen ======================================================= OpenGL Information GL_VENDOR: lima GL_RENDERER: Mali450 GL_VERSION: 2.1 Mesa 22.3.6 Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0 samples=0 Surface Size: 1920x1080 fullscreen ======================================================= [build] use-vbo=false: FPS: 207 FrameTime: 4.832 ms ... ======================================================= glmark2 Score: 98 =======================================================