Igor

That is strange. Can you tell which image exactly you are trying?

HW features are kernel related and here (Rockchip RK3588) there is no other option but to use this prehistoric kernel 5.10.y where HW functions works well, while general functions like support for 3rd party USB does not. Armbian never supported what users are plugging to the board via USB/I2C and other connetions since supporting boards is already excessive expensive / technically difficult and 99% of users doesn't care that developers also need to consume food. By quick check on kernel config it seems it might help to enable others: https://github.com/armbian/build/blob/main/config/kernel/linux-rockchip-rk3588-legacy.config#L2817-L2823 but its also possible that ID of your USB is not in the driver table. This can be workarounded / hacked - Google! Forcing id is the same on all Linux distros.

Explained here: https://www.armbian.com/newsflash/armbian-leaflet-8/

@Contributor/Maintainer - added missing Rockpi 4C plus - enabled Mekotronic boards https://www.armbian.com/download/?device_support=Supported&tx_maker=mekotronics - added Orangepi 5 Plus In case there is another missing or broken images, please report, here or to Jira directly https://armbian.atlassian.net/browse/AR-1765

We support VIM3L, just download page was disabled by mistake. Enabled now https://www.armbian.com/khadas-vim3l/

I don't know. I suspected you didn't notice that hint with overlays that is valid for revision 1.3 Mount SD card on some Linux computer, edit files in /boot/ and try. I don't know if this will work or not, don't have this revision. Mine works.

Video 1. Checking Jira and GitHub tickets 2. Warming up for Khadas support 3. Changes on Allwinner group management

Duo2 was tested with 23.5.2 image that was uploaded yesterday.

v1.3 needs some special treatment, mainline based kernel needs special treatment - UART on legacy (4.4.y kernel) is on different pins then on modern kernel. Did you read and follow instructions on the download pages https://www.armbian.com/rockpi-s/ ?

./compile.sh kernel SHARE_LOG=yes ARTIFACT_IGNORE_CACHE='yes' BOARD=odroidxu4 BRANCH=current This https://www.google.com/search?q=one+bite+at+the+time

Just to add a though. We would like to provide rt kernels but this is from current situation everything but simple. Check https://github.com/armbian/build/pull/5166

I am running it on my ryzen 3950x, on i5 Lenovo laptop, on Threadripper 3990x build server, supermicro NAS and many virtual machines. Almost everywhere and tweaks that are generated into Armbian comes handy also on big irons. ZRAM helps also on machine with a 256Gb of memory Armbian is live system with few things to set at first run, so installation is a bit different. However, armbian-install knows how to handle UEFI install too, so install from live USB/eMMC to SSD/eMMC goes the same way.

Thank you!

Most recent boards have different memory chips. And this hasn't landed to the boot loader yet.

My recommendation is to use SD card, or stick to smelly factory OS, which supports this. https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one It is nothing unusual that different internal NAND chips never came to modern software especially also because we are trying to maintain this cheap hardware with absolutely no budget. If boot scenarios for this chip is closed source (possible), than things are hard also for those that are very familiar with embedded Linux. If you are new, it will be hard and will take time. Nobody can do the homework instead ... https://opensource.rock-chips.com/wiki_Main_Page https://github.com/armbian/build/blob/main/config/sources/families/include/rockchip64_common.inc

There is one bug related to UEFI installer which you might have luck to bump into I hope we will soon fix this. If not before, next time I am reinstalling OS on my x86 hardware. I use Armbian x86 almost exclusively.

Images from here https://github.com/armbian/os/releases/tag/23.5.1 should have fix

I already lost a day on this problem and I will never return to it as my next availability for pro bono action for this case is in several years. There are thousands of other issues https://armbian.atlassian.net/jira/dashboards/10103 (average resolving time is 450 days, because there are just a few of people that donates their time and we can't expand because of no support from your side) not just the one that hurts you. If you didn't resolve and submit a fix, then bug is probably still there but it is possible (miracle) that this problem was solved outside of this ecosystem, by Rockchip engineers that are also dealing with this particular kernel. Most of other Linux projects are nothing better then our end users. They just re-sell our work under different name and also complaining on bugs. Just like you. They are very well aware how expensive fixing bugs is. Try working for community projects full time. Then do this for several months straight ...

This you will need to ask him. I am afraid, but I can't give you that answer without spending a day / hours on the problem. You will need to invest your own time to satisfy curiosity or just enjoy working WiFi.

Why would you want to compile? This wireless chip should just work out of the box (on latest images). Perhaps you have some weird ID that is not recognised? Module info: Google or forum search can reveal things https://forum.armbian.com/search/?q=vdso.lds&quick=1

https://forum.armbian.com/topic/27323-http-error-404-for-sha-hashes-banana-pi-m1/#comment-165132 SSH & serial login is enabled by default. I don't think allowing blank password would be a good idea under such circumstance. Yes, its users call, but we have to prevent at least most stupid actions. One can always override this later in case he knows what he is doing. We even used to have password complexity check error, which was perhaps too hard and a while back was downgraded to a warning. IMO there are enough of safety compromises. Making it work on Ubuntu packages base represented months of work in exchange for virtually nothing. Rare people is able to understand that and most people are just used to consume without compensation, complaining and asking for more. If you / people would understand what they are asking for ... it would already be a great step forward. No, this is not easy to make. Especially because everyone expects from developers to pay for everything. Join, do your part. But not with requests and demands. Project would hire several developers to make it better for you ... As it is impossible to satisfy everyone in this aspect, we don't even try. Armbian provides clean base images with minimum set of applications. Additional applications can be installed classical APT way, via armbian-config or you start making your own images - build framework https://github.com/armbian/build is a masterpiece. You can do your own Armbian based image and adding your own applications in no time.

You don't read our news, newsletters or Linux media sites? We are making as huge bang as possible when time is right.

tl;dr; difference between generations is usually huge, between private old and mainline new, only bigger. https://github.com/armbian/build/blob/main/config/sources/families/odroidxu4.conf#L19-L32 5.4.y is private vendor kernel that is getting generic bug-fix patches from mainline 6.1.y is pure mainline Without code analysis and understanding of related (CEC) mechanisms it is usually hard to tell anything. Its a complex question that could require extensive study on top of general kernel know-how. Theoretical / I didn't look into the code or commits ... it could be more simple answer too. Probably features names changed. boot.ini is Harkernel proprietary way of setting kernel / hw parameters, tailored for their kernel. Bookworm "current" will still come with 5.4 so you need to switch to edge 6.1 kernel manually or via armbian-config. We will keep 5.4 at least for next release as dropping it ain't a simple binary decision.

Video Subtitles What we did? This: 1. Check remaining from Jira tickets https://www.armbian.com/participate/ 2. Review issues https://github.com/armbian/build/issues 3. Review pull requests https://github.com/armbian/build/pulls