MaxT

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.

You might also be interested in tkaiser (who is sbc-bench author) thoughts: https://github.com/ThomasKaiser/Knowledge Not sure if there is smth specific re rk35xx frequencies, temps and energy, but definitely there is some interesting stuff re ARM overall and rk3399 in particular, which might be helpful.

I guess some insights might come from the relevant CPU opp-table evolution in mainline and rockchip mailing list on lore.kernel.org There might be some discussion. Also you might want to create an overlay and test how it works. Just note that some existing frequency overlays do not work since use single opp-microvolt value , eg opp-microvolt = 1000000, which is target microvolt value for given frequency. But at least in some opp-tables triplets approach is used eg. opp-microvolt = 1000000 1000000 1000000 ; which are target, min and max. Per bindings, both approaches seem legit, but they cannot be used simultaneously.

There is a topic on the forum re script to back up and shrink partition https://forum.armbian.com/index.php?/topic/29427-shrink-backup---a-tool-for-backing-up-sbc

AFIR, usb boot requires u-boot supporting a) usb initialization at boot time and loading kernel from USB in priority to other devices, though u-boot anyway should be on eMMC or SD (or spi flash when exists). Priority of these is hardcoded in CPU's BootROM, which looks for loader (say u-boot, for simplicity), which in turn does all the job. Setting up usb in armbian-install might only point u-boot to partition guid on usb rather than eMMC or SD (in armbianEnv.txt), but this is not the same as prioritizing USB over SD and eMMC. To achieve USB load if USB flash is present, one needs to ensure that u-boot supports this. Further setup has nothing to do with armbian-install, just flashing image to USB is sufficient. Although USB boot looks attractive, it actually requires enabling features, which slow down boot for several seconds and it will not help if u-boot at eMMC/SD/spi flash is damaged. So in fact it is just a toy

Had a very same issue just recently. Guess there is no check in armbian-config whether package was downloaded before removing an old one and in case of multiple packages this is done one by one package rather than downloading all required before processing further. Failure to download might relate to mirror availability - seems that every new download might be from a different mirror- in my case dtbs were installed, but kernel only removed. Ad-hoc solution- keep bootable usb or sd to chroot and fix.

It does work. The issue I referred to relates to the rsync bug. Seems solution is to update rsync and update for 22.04 was just released: https://bugs.launchpad.net/bugs/2095004

Pls have a look, isn't it is the same issue? https://github.com/armbian/build/issues/7708

Search for the word overlay - it's in the u-boot part of the log, before starting kernel...

You mentioned that overlay name shouldn't contain prefix and that's right, but I see that armbian-config adds overlay name with prefix included and to make it work, one has to remove prefix, so not sure that it works as intended. AFIAK since overlays modify DT nodes, you can only see modified data in relevant nodes, rather than an overlay itself. Another consideration is that overlay itself might not work. Don't remember which exactly, but some overlay for eg rk3399 is not working.

It seems that new armbian config adds full overlay file name into armbianEnv.txt, in the same time there exists overlay_prefix variable, eg: overlay_prefix=rockchip overlays=rockchip-rk3399-spi-jedec-nor AFAIU, to get a full file name of an overlay, boot script joins overlay_prefix and, in this case, a full overlay name (from overlays variable as added by armbian config), adding "-" in between and obviously cannot find the resulting file name since overlay_prefix + "-" are effectively doubled: rockchip-rockchip-rk3399-spi-jedec-nor For me practical solution was to remove "rockchip-" from overlay name. Removal of overlay_prefix variable is not working, I guess this is because boot script anyway adds leading "-" making file name wrong. Boot scripts are black boxes for me, but may be @Igor will be able to have a look whether scripts or armbian config need any changes in logic.

The above linked GitHub repo contains exactly what was asked - brief overview of the build system with links to documentation. Have you read those?

It is better to avoid outdated releases, otherwise googling for those quite common errors or searching Debian forums might be more efficient but still not give desired comfort.

Search forum- AFIAR @Igor wrote re wiringpi recently.

AFAIR armbian creates swap in RAM

Guess conflicted packages should be removed first. These are quite basic Linux matters, probably worth googling first for alike.

cd to debs before running dpkg

See last two lines https://openwrt.org/toh/views/toh_single-board-computers Seems snapshots are available

If a feature works on the board under OS A and does not under OS B, given both are Linux based, one can rule our HW issue. By comparing kernel patches, one can rule out drivers, same with kernel configs/build options and lastly userland SW That's all I meant. Remember, OpenWRT, DDWRT, etc. are built with networking/AP functionality in mind, have large user base using exactly feature in question and there might be hints on their forums, wiki, etc.

Maybe worth trying OpenWRT - it is built with AP functionality in mind and if it works, assess whether config(s)/build options can be applied to Armbian