Igor

Probably its 3.14.y since this was a kernel supported by NXP. We dropped all old kernels because modern kernel have good support for boards that make it to the mainline. If you only have this old kernel, forget about. Its not worth the trouble. There are no many ways how to wire imx6 together which is why you could perhaps try with modern u-boot kernel combo or at least stock u-boot / modern kernel. If you make it usable to some degree, its already a success. We needed years to bring Udoo and Cubox to the modern kernel and even today, not all functions works or they work, they stop working, they start again. Sometimes this is done upstream, sometimes some adjustment is needed.

Images are actually up to date, just lack of device for testing ... well, it can be enabled back. It's well supported A20 hw.

That would be to start with a different SD card. It is a combination of pure vendor, messy chip maker and limitation we have to provide support - this is amateur backed project. AFAIK there are some known problems @TonyMac32 (can't find reference) that affects some(?) SD cards. Try both kernels, stock 4.4.y and 5.4.y and see if there are differences. They should be.

Banal reason. No samples in the lab / no official board maintainer even I am sure most if not all features works ...

It seems you did the right things ... Module is enabled and it should be loaded after overlay is enabled. Try loading it manually perhaps? https://github.com/armbian/build/blob/master/config/kernel/linux-sunxi-current.config#L1540 ATM low of ideas why this doesn't work. Try legacy kernel - where people indeed reported success: armbian-config -> system -> alternative kernels and pick one with 4.19.y

Providing logs with armbianmonitor -u significantly raises chances that issue is getting addressed. What do you have here: lsmod | grep can

Release process bug ... which has to be fixed by 20.05. https://github.com/armbian/documentation/blob/master/docs/Process_Release-Model.md#2-release-candidate-branch-management

https://amzn.to/2VHxOaQ

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