usual user

EXIT to the U-Boot console and report the output of the following command: bootflow scan -l nvme I don't know what the armbian-install does, but does it make a difference if you dd the same unmodified image to the NVME as you do to the microSD?

This one.

Ok, moved on to 6.14-rc1. No regressions were observed, only current fixes were applied, and new features were enabled. It may take some time for some of the fixes to trickle into new stable releases, but the new features are never officially backported.

Ok, judging by your information, the regression takes place during the transition from U-Boot 2024.04 to 2024.07. Since mainline U-Boot works perfect for me up to until 2025.01, it must be because of how it's built or what additional patches are applied. Since it cannot be ruled out that it is due to a incompatible bootflow, it may be interesting to try it with my build. If this also fails, it is possible to get more information from the HDMI output, even if access to the serial console is not available. For the test it is perfectly sufficient to start the firmware from a prepared microSD card via RCY button. The existing setup can stay completely unchanged.

For me USB works as expected: I don't have any usbstoragequirks in place because my storage devices have controllers with properly working UAS support. I'm currently at 6.13-rc1 and will stay there at least for another two weeks.

But I'm grateful that it also works for me with pure U-boot:

I'm currently at: # uname -a Linux micro-015 6.13.0-0.rc1.20241204gitfeffde684ac2.17.fc42.aarch64 #1 SMP PREEMPT_DYNAMIC Sat Dec 7 11:18:10 CET 2024 aarch64 GNU/Linux And with better wired up in DTB I get:

Works for me as for @rmrf. iperf3 -c ... [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 0 sender [ 5] 0.00-10.01 sec 1.09 GBytes 938 Mbits/sec receiver iperf3 -R -c ... [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 412 MBytes 345 Mbits/sec 485 sender [ 5] 0.00-10.00 sec 410 MBytes 344 Mbits/sec receiver

Ok, then no further action needs to be taken and your solution can be used by others in the future. I also don't need any other firmware because my current one works according to my needs. And for an update, I know how to build and debug it if necessary. In the meantime, I've moved to 2025.01 with HDMI support enabled, so I no longer need the serial console to interact with the firmware. And boot menus easily allow the free choice of which option should currently be booted.

To get help, you have to provide proper logs. In case of boot problems, these are serial console logs. https://debug.armbian.de

Out of curiosity, I played around a bit with the sources offered. The overlay compiled from the spi-ili9341-tft.dts source cannot be applied statically to the base DTB. It seems to have something to do with the externally used labels. Unfortunately, my DTC package is currently in FTBFS condition and I can't investigate the cause further at the moment. I have therefore rewritten the overlay in absolute path notation. I used the given properties for this. I can't make a statement about their correctness, because I don't have a complete circuit diagram or any necessary data sheets at hand. I'm not particularly familiar with the Allwinner devicetree binding documentation, but as far as I can tell, the properties, when applied to the base DTB statically, are compliant. If you want, you can run the attached DTB with your device. All components are already statically applied, so you should disable any other dynamically applied overlays. I would be interested in the "/sys/kernel/debug/gpio" content. sun4i-a10-pcduino2.dtb

Allready landed in mainline, you get the fix out-of-the-box since v6.11-rc3.

This says that the necessary short circuit was not present when the MaskRom code scanned for boot devices. The short circuit must be ensured before the power supply is switched on, and must be maintained until a few seconds later. The procedure is a three-handed job. One hand fixes the PCB, one hand holds the tweezers, and one hand switches on the power supply. This can only be reliably ensured with a shelf holder who uses Pogo pinns. IMHO a bad board design for a tinker device. A push button or at least holes for a plug contact to connect a proper switch if necessary would be the better solution. Be grateful to your board designer.

Since the "upgrade button" is only software readable, and the firmware (U-Boot) that does it is corrupt, only this method remains. In MaskRom_mode I would first delete the corrupt firmware in the eMMC, so that the firmware loading falls back to the microSD card. This allows different firmware variants to be tested without having to use the clunky method to get into the MaskRom_mode. Then I would prepare a microSD card with supposedly suitable firmware and boot the device with it. The function can be verified looking at the serial console output. Once a suitable firmware has been identified, I would add an OS image to the microSD card to evaluate the full functionality. It may be possible to speed up the procedure if a complete image with suitable integrated firmware is already available. Finally, if necessary, the firmware can be placed in the eMMC again.

Since I don't even know which system component the supposed GPIO line is connected to, I could only speculate wildly. The appearance is certainly due to the wiring in the DT, but this is also a speculation to which I do not want to comment further, but leave it to qualified people. Alternatively, you could look in the exact DT sources from which the DTBs used at runtime were assembled, but I don't have access to that. You could also add the line to the output with: gpioset --consumer=reset -c0 234=on but it certainly won't give the same functionality as in the original case, as it's a completely different use case.