Igor

https://www.armbian.com/newsflash/code-freeze-and-moving-to-new-framework/

Just additional measure to divide kernel and user land packages update. If you want to update kernel packages go to armbian-config -> system -> unfreeze (freeze back after) ... do update & upgrade.

We are trying to put together an automated test system for various (WiFi) USB devices. Hardware is in place, but software part is in early design phase:

Oh, you want to take care of this?

Thank you! BTW. We are just about to switch to a completely reworked version of it: https://www.armbian.com/newsflash/code-freeze-and-moving-to-new-framework/ This should also help dealing with RT patches. If we had someone around to deal with RT patch discrepancy, we could also generate RT kernels.

I am sure there will be! We even played with idea to present armbian-next build framework, but I guess next year or at another conference. I'll have to skip it this year. Somehow too busy.

1. Checking the progress of Armbian-next Video: https://us06web.zoom.us/rec/share/vq04OFykxpw7nGp8wJxKME7w8uNf1kMrwHRLldQLTCLJCT-zsZY8KP76aCknhBfN.JyvzRmfR9qulexM2 Slides: https://github.com/rpardini/armbian-build/blob/extensions/README.armbian-next.slides.md#update-feb-1st-armbian-next---general-changes Armbian Next Jira: https://armbian.atlassian.net/browse/AR-1451 2. Moving development related topics to GitHub Summed here: https://armbian.atlassian.net/browse/AR-1529 3. Questions around upcoming release Today is the code freeze. Actions: notify maintainers and prepare them to be ready on testings in two weeks from now notify developers: their code gets into release log only if exists in Jira. Minimum requirement is Jira issue or Jira story with Name, short description and field "Fix versions" set to 23.02 that code freeze is a milestone when we change our focus into code stabilisation and fixing bugs. It is not expected to drop existing work in progress at once but gradually close it. in the code freeze period, there is additional restriction on code merge: pull requests approval from 1 person to 2 persons @Contributor/Maintainer

We have DTS, I even tested it few days ago, but don't have the energy nor time to open PR ...

Kernel headers on this particular kernel are not in good shape as kernel is not in good shape RK3588 is using changed Linux kernel fork used by Rockchip to bring the hardware up - focus is their hardware functions only. More or less only they maintain it without general purpose fixes. Many standard functions are broken or unmaintained. Volunteers and people at board vendors can only try to fix most critical things to make hardware usable ... until this is not working decently (1Y+), there will be many strange problems to find. Both is good I guess, but can't say how vendor takes care on PR. With Armbian - if its clear what it is about, tested, came from trustful author, ... its merged pretty fast https://github.com/armbian/build/pulls

Not familiar with. You mean you have tried, but it didn't work? So far, booting from USB key always worked, but am not familiar much how Ventoy is combining distributions. If it doesn't work, we must be missing some small details in this UEFI structure or Ventoy is too rigid. I have recently found a bug which could affect UEFI booting, but this is related to the install part. https://github.com/armbian/build/pull/4758/files

That is a great resource regarding wireless modules. This is not that easy as drivers build into the kernel can still have such problems. In fact, those drivers are build into, just by Armbian. TBH i didn't look closely enough to see which drivers are actually in use. It is also possible to have different drivers for the same device and then you block one or another. Where is "at the end" ? I am exploring Unix / Linux systems and hardware for 30 years. And the more you know, the more you are aware how little that is. There are many things that can go wrong. Stay open minded.