Igor

Trixie ... let me check and fix this. I only tested Bookworm.

This is around 10 years old (!) demo / beta image that was deprecated cca. 8-9 years ago. If automated builds doesn't work (we can't cover for endless software support for endless ultra-cheap hardware), IMO your best (only) way is digging into https://docs.armbian.com/Developer-Guide_Build-Preparation/ and fixing reasons which are preventing latest kernel / boot loader to work. It might be trivial, it might be hard. Probably nobody knows without research. This will help you http://debug.armbian.de/

This should be fixed, but there might be an error with firmware package. Fix is uninstalling armbian-bsp*, updating all packages, installing bsp againg.

Struggling with repo management for past few days. It would be nice to write it from scratch, but time is an issue

That is wrong approach as we follow kernel source / standards: and this (boot script) contains the mechanism for loading it: https://github.com/armbian/build/blob/main/config/bootscripts/boot-rk35xx.cmd It should work: https://github.com/armbian/build/blob/main/config/bootscripts/boot-rk35xx.cmd#L51-L52 Is your image an upgrade from some old one? As we indeed have issues with this at some point.

Was fixed already.

We provide mainline based kernels via repository. They are up2date with what exists, but support is not complete and also not tested on this particular hardware.

There is another feature of framework, "armbian-kernel", sections that applies on top of (basic) configs: https://github.com/armbian/build/blob/main/lib/functions/compilation/armbian-kernel.sh#L205-L336 (Docker as example)

Armbian needs user space development too Examples: https://github.com/armbian/configng https://github.com/armbian/apa ... We have to deal with that. There is a lot of automation, infrastructure, ... everything has to be done in order that this machinery works. Ain't just kernel / low level stuff. Not to mention that project also needs (HTML) front-end developers and other profiles. As by the end of the day, that works falls to the people who knows kernel stuff, but if website is broken, kernel fixing has to wait ...

Understand, likewise & most of people that knows this stuff, are very busy. Hardware donation was a thing years ago, today not so much. I can add hw donation (something else) and offer tools: https://forum.armbian.com/crowdfunding/ (example) This can be prepared by anyone and nothing is expected to happen over the night.

Those older devices are patiently waiting for a dedicated enthusiast with plenty of free time and a passion for tinkering. Sadly, the current Armbian maintainers are already stretched to the limit, and expanding our support efforts just isn’t feasible right now. I had a wish, still have, to find and encourage a dedicated person to take a lead on maintaining those old devices (retro Armbian section) as we have to move them out of primary focus in order to survive. Reaching mainline is not enough. Most of our work is dealing with problems that are originating from there. Mainline is just common work, but its often in not very good state. And when problems are found, it takes months before they are fixed. And someday they are not fixed anymore as critical mass of developers, interested in this devices, is just too small or too inexperienced.

tl;dr; It a business support / donation deal between Armbian and SBC maker. We have some budget, we aim on at least positive zero, and we have some people behind those boards. This doesn't mean we will be able to resolve all problems and in real-time as budget is still too small and resources remain limited. Support is better https://docs.armbian.com/User-Guide_Board-Support-Rules/ then on boards without.

The software used by the Orange Pi "team" is, to a very large extent (estimates go as high as 99.9%), based on the work of developers from the Armbian project (and beyond). Their contribution mainly includes adding basic support for new boards, but unfortunately, without further maintenance or long-term support – which practically means that the entire burden of maintenance and support falls on the community. It should be noted that systems such as Orange OS Ubuntu and Debian on ARM architecture are the result of years of work by more than 500 people gathered around the Armbian project. Orange Pi only makes minor adjustments. In the past ten years, we have not seen a single contribution from any member of the Orange Pi team to the development of these key components. Absolutely nothing, while they keep signing under our work (even changed to some degree) ... on top of stealing software support. Which they don't provide in any way. The work of the Orange Pi team (which appears to be just one individual), on top of some old Armbian, can be tracked here: https://github.com/orangepi-xunlong/orangepi-build/commits/next (they removed other board configs)

IIRC this was never integrated but was supported via community initiative:

I assume you have a GitHub account (if not, make it)? Click "Subscribe" on that issue and you will get a notification when its closed down. 4 hours later, still not fixed. No, there is no cheap and quick solution to patch this problem. I would like to see that too.

Aha, its probably this: https://github.com/armbian/build/issues/8052 Working on it.

build with SHARE_LOG=yes SHOW_DEBUG=yes and provide full log. This tells noting.

This is everyone's problem. Buy boards that are supported and maintained. We have not received any support from Orange Pi, contrary, their business model is very damaging to us and donations only pays coffee and beer. We do not maintain or officially support hardware you have, and AFAIK it is not maintained by anyone else - but if it is, it will get to Armbian too. However, given the similarities across these boards and the nature of open source, it’s difficult to prevent Orangepi and their customers (you) from abusing open source development. This is everyone's problem. Stop buying hardware that we don't and won't support as making a pressure to open source developers is worse thing you can do. Hardware dealer abuse is already big enough. Just a polite reminder that you are not a customer, so adjust your over-expectations.

As predicted. Vendor kernel - I am working on establishing better cooperation with Rockchip. Without that, its difficult to "fix everything" in that kernel.

Thank you for reporting this problem and Welcome to forums! Looks-like issues with HDMI driver / edid readout, perhaps forcing resolution might be a workaround? But how-to, you need to look into the kernel code. Also make sure to try daily builds from time to time to see if things are fixed. https://docs.armbian.com/User-Guide_Armbian-Config/System/#switch-system-to-rolling-packages-repository I hope the general difference between vendor and mainline derived kernel (and u-boot) is understandable? https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one Depends on your technical understanding - look into the code, compile kernel with additional debug, understand how it works ... I am not familiar with HDMI subsystem, so you need to hope from attention from someone that is. Or just dig into the code and share findings. Telling that it fails / errors out, is just a very first step from a possible long journey. This is community support, we all have this problem. Helping others is helping yourself. You are welcome to help the project anywhere you can. That helps too. The amount of issues in open source code (not Armbian problem per se) that are waiting to be fixed is already enormous and we fight this without your help and without help from company that should be around actively (Rockchip). Whenever I spoke to them, they brag how good they are and how many engineers they have and how well their products are ... while I know state of their products better then themselves. Functional regressions you experienced are totally normal, expected and will happen in the future. No matter how much time goes into the code, Linux is maintained and developed by many people, overall complexity is quite extreme. This problem is not yours, but from everyone. So it is approach for solving it.

Try modern kernel, 6.12.y

Updated test (including some onboard wireless chips):

Can you provide more detailed info - last images were not tested as there were very little changes from previous one (check lastest from archive https://imola.armbian.com/archive/inovato-quadra/archive/)... Which images did you try and can you try daily images that are at the bottom of the page: https://www.armbian.com/inovato-quadra/ Also we are just about to merge big changes on Allwinner, so stay tuned. https://github.com/armbian/build/pull/8004

Enabling remaining with https://github.com/armbian/build/pull/8051

Should be fixed in Armbian repo for some time now: https://github.com/armbian/os/pull/299/files But for kernel 6.14.y this wont be enough anyway. https://github.com/openzfs/zfs/releases/tag/zfs-2.2.7 "Linux: compatible with 4.18 - 6.12 kernels"