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?