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