MaxT

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

Probably worth just googling for hostapd and wpa2 and/or wpa3, no?

I guess you actually have not properly configured AP security mode wpa2 and/or wpa3 (not just wpa !!!)

If the AP mode is really just wpa-psk, it might be not supported by modern OSes (iOS, MacOS, etc). Eg: https://discussions.apple.com/thread/254452739?sortBy=rank You might need to find an appropriate security mode for the AP and configure it right, but here you are on your own.

Why not search forum first? There was smth similar few days ago

https://github.com/NicoD-SBC/armbian-gaming/issues/13 Probably worth googling and asking in the gaming GitHub repo. AFIAK gaming audience on this forum is rather small if any.

FYI ... rockchip: - Improve DP sink-capability reporting - Cleanups - dw_hdmi: Support 4k@60Hz; Cleanups - vop: Support RGB display on Rockchip RK3066; Support 4096px width ... https://lore.kernel.org/dri-devel/20240816084109.GA229316@localhost.localdomain/T/#u

I second the question- some workflow description for novices would be highly appreciated!

AFAIR, windows tool sometimes just stops working - had smth similar. Flash over usb with Linux - search radxa's wiki for how to do this.

Can't really help with meson, but if this will make you feel not alone - rockchip also has issues with HDMI IMHO worth trying search in aml section of this forum. If patches are required, you might want to look into libreelec and minimyth2 GitHub repos. Since both are TV oriented, they might have necessary patches.

I've played with TBS drivers a while ago for tinkerboard https://forum.armbian.com/topic/10464-how-to-add-a-kernel-module-for-usb-dvb-t-tuner/?do=findComment&comment=79667. At that time I thought that there were smth in vendor's code of 4.4 in dvb-core that prevented TBS drivers loading, though later I've found that TBS is also patching dvb-core and some other modules like CEC, frontends, etc. So may be solution would be to build all modules required for TBS drivers (stating from dvb-core? ) and use them instead of mainline/vendor or extract TBS drivers and other TBS changes from its repo as patches series to apply in armbian. Though I don't know how to compare the whole trees to extract TBS drivers as patches. Any hints will be appreciated.

Just curious- what make/model is this reader?

https://lwn.net/Articles/394702/ https://lwn.net/Articles/821817/

Someone always should be liable that you are not happy with smth, and must do smth here and/or there to make you happy, right? Just a few thoughts (I'm also not young): Suggest you direct claims to Linux devs and enjoy having reply there (just find an appropriate mail list at lore.kernel.org, probably in the MAINTAINERS file in Linux sources). If the board isn't supported in mainline, that's another reason to complain and ask why the hell they are there. Will appreciate if you share reply here when you get one. I guess armbian people are here because they enjoy playing with SBC and to the extent acceptable for them help others, but obviously (for me at least) without any sort of guarantees or promises As to the community, suggest you think of yourself as the only member of the Community currently having interest in this particular board, facing this particular issue and having enough time. Probably an answer why you have not got any reply will be clear. So you also might what to blame other owners of the board who are not on this site and dropping all their current affairs just to do what you need. You also might want to find the person fixing the bug in question 9 years (?) ago and raise complaints on why that asshole have not fixed the bug for all boards to him and change him your time invested so far, otherwise that time is your time, no one got any value (now you know more than before ) out of that investment except yourself, so that's your R&D. At to usefulness, seems there are quite many people finding this project useful, probably not all their expectations are met, but still, and I guess they are happy that there are knowledgeable people that might have will/time to help. Even if not, no one has any right to try insulting the team. Some people become wiser as they get older, some not, where are you with this?

With 5.15.75 I've posted everything - there were nothing after the end of trace

Though I see pci timeout in 5.15.76 and timing is more or less consistent with the hang of 5.15.75: root@rockpi-4b:~# dmesg | grep PCI [ 0.008978] PCI/MSI: /interrupt-controller@fee00000/interrupt-controller@fee20000 domain created [ 1.335872] PCI: CLS 0 bytes, default 64 [ 2.660682] ehci-pci: EHCI PCI platform driver [ 2.696246] ohci-pci: OHCI PCI platform driver [ 3.582653] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout! root@rockpi-4b:~#