Igor

What is not working? Edit: USB port are working on image made from trunk http://ix.io/2aQn

We fixed problems with a modern 5.4.y kernel only 4 days ago - images were not updated yet. Wait for new images or build image on your own. If you can't wait for modern kernel or you are unable to DIY ... and you want to install OMV, this will be the best image: https://dl.armbian.com/odroidxu4/Stretch_legacy Most recent OMV, that runs on Buster, is not ready (out of our power to fix) for beginners.

Attitude? You care for your money, but you don't care for our time ... which I would rather spent with my family. This project is backed by volunteers. ... support is extreme expense in a project that generate no income. It was told to you where images are. We don't claim they work (I know they don't) which is why they were removed. We don't want to waste your time and it would be nice from you to return the same. Or at least understand. Accept. I don't expect from you to do our job. There are many things you can do https://www.armbian.com/get-involved to learn things and earn respect in the community. Only that can trigger an interest from doer to do something about this issue. If you just rant and do nothing ... Resources are tiny and support is not a cheap copy / paste / re-brand operation.

But you expect we will waste our time / money for you?

Works fine: http://ix.io/2aPh

False alarm. Everything is alright.

Then at least add it here below, this way: https://docs.armbian.com/Process_Contribute/

BTW. I tried to build two Buster images with 5.4.17 today - Orangepiwin and Orangepiplus2-h3 and both are without wireless It seems some troubles with the driver ... will try to debug in the evening.

Because most of people just believe (BS) they will get opensource stuff this way But we know this won't happen Well supported Android is also opensource on the level those guys operate ... I have no intention to change to X crap OS unless it will be build on top of free firmware. Which its no way it will be. Not so quick and cheap. And all others. They are just cashing in.

Added a small new feature - submenu on "Forum -> Moderators" to display moderators: https://forum.armbian.com/members/2-moderators/

I am (very) sceptical about when its about radio. Any kind. Perhaps its another marketing idea - if it runs on Linux = "opensource"? Patches are out there and I was already trying to bring this feature to the 5.4.y ...

Yeah, this is the main issue.

I share concerns which @TRS-80 pointed out while on the other hand we shall not prohibit anyone to maintain any hardware as CSC target if he wishes. Until he does not bother for implementation, maintenance and if this does not break the build system or other images. Anyway we can't really assist on implementation of boards and RPi is not any exception. It also has to be generally approved, but it seems its not. So @legogris IMO you are without "official" support, but if you get it working ... I guess we shell merge it. I think I already told this to few people and nobody take it serious enough. Leaving CSC target in the dark should not change anything, or?

My default PSU is 5A which is why I didn't notice. Experiments tells that 2.5A is already good enough

Thank you, but answer is still the same. This problem is outside our power to fix. Armbian has zero employees which can't cover work of 1000+ people that works on the Linux kernel. They created this problem and they will fix it.

Yes, we use the same kernel sources, just a few more patches and a different kernel config. There are also additional drivers, which can't have affects on this. Try this: Remove all patches from patch/kernel/rockchip64-legacy Use a kernel config from ayufan image Place that config to userpatches/linux-rockchip64-legacy.config Rebuild kernel with additional parameters: WIREGUARD="no" EXTRAWIFI="no" and report back. This will narrow down the scope where to look for the troubles.

Yes, most likely - your process seems alright, especially if you get it working somewhere. Bleeding edge kernels always have issues which is why we maintain older kernels. Simply use 4.19.y and check here and there if this is fixed. I don't know for any better way. It helps to know that bug exists and that most likely has nothing to do with our work. Fixing the bug is something completly different since its 100% our cost and its yet another non critical issue on the huge list. Linux kernel is a work of thausands of people, big corporation, while our resorces are only this https://github.com/armbian/build/graphs/contributors?from=2019-12-01&to=2020-01-29&type=c

Thank you for informing us, will be noted. I am not sure we will be able to fix this in a time frame we have for a next release. In a mean time you can use a kernel 4.19.y images which should work without issues. Those drivers are mainly maintained upstream. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/MAINTAINERS?h=v5.4.15 or by 3rd party.

With what? This script https://github.com/armbian/config needs serious long term (co)maintainer. It's not a heavy job, but you need to be around on a daily basis. Once you will create trust that you will carry on, I will restart C1 maintanace. If you don't have time for that, you know the answer.

As far as for the boot loader. We pack it with a process to burn it into the SD/eMMC. For examle, this board, is within repository: https://apt.armbian.com/pool/main/l/linux-u-boot-rockpi-4b-legacy/linux-u-boot-legacy-rockpi-4b_19.11.3_arm64.deb boot loader in binary form script for flashing to correct location You can extract the content of DEB package and DIY.

Write down exact (copy/paste) procedure and I will try to see if I can fix it.

That's expected. Realtek version is for some old driver implementation and its probably deprecated. What you have to try is this: But also its possible that driver does not support AP at all. I am not familiar if the one you use works in AP mode or not.

Raspbian is an OS and RPi is a (proprietary boot) hardware that must have FAT partition. It can't boot without ... The main problem we have with Armbian is that every hardware (family) has different method of booting. Only from the user perspective it looks (almost) the same. Because we cover more than one (simple) device, things are not simple. In general you have boot loader(s) outside, below filesystem and stuff in the /boot + (optional) /lib/modules. Which device you are actually talking about?

https://github.com/ThomasKaiser/sbc-bench

Providing logs with armbianmonitor -u significantly raises chances that issue is getting addressed.