5 hours ago, mfreudenberg said:

this solution didn't work out on my Rock-PI

This is quite possible because your uboot is built with other features. E.g. you have no usbkbd support as can be seen from the coninfo output. You could have used nulldev, but bootdelay is even the better solution for your situation.

 

5 hours ago, mfreudenberg said:

Interestingly, after reflashing a different U-Boot without the bootdelay mod, i wasn't able get back to the u-boot console.

Saved uboot environment is usually not cleared by a firmware update and yours is even maintained in SPI flash as can be seen by:

Saving Environment to SPIFlash... Erasing SPI flash...Writing to SPI flash...done

To reach the console again, I would use a completely deleted SD card (dd if=/dev/zero of=/dev/${entire-card-device-to-be-used}) and then install a firmware (dd bs=512 seek=64 conv=notrunc,fsync if=u-boot-rockchip.bin of=/dev/${entire-card-device-to-be-used}). If you boot with this prepared SD card and removed eMMC module, you should finally reach the console after all unsuccessful boot attempts. Be patient, there will be some. If you had used nulldev, this would not work, but deleting the SPI flash should definitely let the environment fall back to the uboot built-in default.

Am 19.9.2022 um 14:11 schrieb Igor:

It would be worth to clean / rework this properly following by opening a merge request

 

I'd love to do that. But at this point I'm afraid i still lack deeper knowledge of the armbian build framework. I might think of providing some documentation on that. When i look into some other merge requests, it seems to be a regular thing to use these files to configure the u-boot.

 

https://github.com/armbian/build/pull/2086/commits/174fcf76db573886ac6bd5310be8c593dfec37dd