MaxT

If you have uboot on emmc, to boot purely from SD, you have to either erase emmc or mask it. Try booting with maskrom pressed and having SD cards in the slot, if in the maskrom mode SD slot is not masked, bootrom will pick up uboot of SD since will not find emmc.

I'm not armbian team member, though feel that alike notes might be not welcomed at best. Kind advice- if someone doesn't like smth or believe smth should be improved, someone is advised to send a PR, otherwise keep silent. Re booting from SD - if you have uboot on the emmc it will be picked up by SoC's bootrom even if you manage to put several SD cards into the slot . Boot order starts from bootrom which is hardcoded in the SoC and it has its strict order to search for loader(s) - u-boot in this case (actually comprising of several loaders/firmwares). Uboot in turn has its own, though configurable, order of scanning media for kernel image. So if you have uboot on emmc AND uboot on SD with kernel, uboot on SD is ignored by bootrom.

Seems to be innovative way to get positive attention of the team to issues you face. Good luck with that.

@renard If you have u-boot on emmc, there might be incompatibility between u-boot on emmc and u-boot required to load kernel from SD. IIRC bootrom is looking on fixed storage first (SPI flash, emmc) before going to SD and if uboot is found on a fixed storage, this one is used. Uboot, however, is configured to look for kernel on removable storage first (USB, SD card) and load kernel from one of these if found.

Even if the SPI chip is burned/shortened, this does not explain why the board doesn't boot from SD. Maskrom mode is just the state of RK CPU which boot room didn't find bootable system on any of SPI/eMMC/SD, so it just goes to this mode, but AFIAK CPU cannot be stuck in this mode, it is only a matter of providing a bootable system to it. I don't know whether SD card should be accessible by rkdeveloptool in the same was as SPI chip or emmc usually are, but you might search whether this is the case and check in practice - if it should be accessible but it is not, then there might be smth wrong with either SD slot or card itself.

I don't think there is smth more/else to ground. Try burning to SD card some guaranteed to work image (there were some issues with armbian images - some were not working) - quick glance on form showed me that someone wrote that his OPi5 was running 5.10.110 kernel, so take minimal image (just to speed up) from armbian old archive http://fi.mirror.armbian.de/oldarchive/orangepi5/archive/. Image/kernel version doesn't matter at this stage. If after powering up the board with sd card, pc will not detect it as being in mask rom, then it probably is working in this or that way. Also remember that first time boot takes some time due to partition resizing, but your test is maskrom mode state. If not, I'm out of ideas and help from someone really knowledgeable is needed. Hope @going will be able to give you more help. Just keep in mind that he is using translation to write here and probably to read.

Clock, but make sure it is the same SPI as SPI flash is wired to. Otherwise you might want to try just solder a wire to SPI flash clock pin and ground it in that way and while at it touch SPI flash pins which a soldering iron to exclude soldering defects.

I would then find pin on the 40 pin connector to short SPI flash to ground (if such pin is exposed) and then tried to boot from SD card. It hard to guess why the board could not boot from SD previously, but guess it's worth trying with SPI flash grounded. Maybe there is some way to load uboot into memory but without usb-ttl it would be difficult to proceed further. If you will be replacing SPI flash, I would recommend either finding same chip or make sure that alternative works on the same or higher max frequency - just to avoid any potential mismatch with dts re SPI max frequency.

Yes, usb A which is rare since, if I remember correctly, USB standard does not mention OTG functionality for it. OTG is for eg micro USB. AFAIK usb-A to usb-C + adapter (if needed) might also do the job, but it is possible that not every cable and/or adapter will work, just remember there were discussions on this a few years ago. Can't comment on which usb port you have to use on your board - I did that on a different one. Just realized- if you already can interface with the board in the mask rom mode from windows PC, that's it. Now you have to try the same connection under Linux with Linux tools and blobs for your board. When I did my exercise, I just opened Ubuntu VM on my ESXi server and passed through USB to that VM. So you might want to try doing similar with Virtualbox or VMware Workstation.

You might want to try communicating with the board over USB (male to male USB is needed) under Linux rather than windows. In mask rom mode it allows loading blobs into memory, flashing device, etc. I've used that a while ago and with a different board, but AFIAK this works across all RK based boards

It seems there is smth on the flash preventing boot, so I would remove SD card, enter mask rom, release button or other contact used to enter maskrom (it is necessary only to "tell" to bootrom that no internal flash is available for boot) and format/erase flash. After that disconnect the device from PC and power, and then reconnect/power on device, it should enter maskrom by itself since internal flash is empty. Then just boot from SD card with appropriate armbian image.

As stated in the post you referred to, technically Rockchip devices cannot be bricked. Since you flashed a wrong image, it probably not right to say internal flash doesn't contain bootable system. Rather that system is wrong and cannot compete boot hanging somewhere, eg ddr init. So I guess you have to go by the mask room path to recover (flash correct image or erase internal flash to enable SD card boot, which might be easier to experiment with).

You might want to try image with 6.13 (even some rc), AFAIR there are hdmi related patches for rockchip

I would have a look at u-boot version prior to apt upgrade. Without catching whether/when uboot version changed, anything would be just a wild guess, eg image with 6.6.y kernel might have older uboot than image with 6.12.y, etc. One needs to compare apples with apples.

As @SteeMan mentioned, apt install does not install u-boot to boot media, it only downloads package and unpacks it. One needs to run armbian-install (not armbian-config) to actually install u-boot to boot media, or do it with dd manually.