Igor

Just keep it on community level - you are a peer at best, not a customer. If you want that someone do your homework, trade, provide a compensation. Keeping this project alive, without helping you, costs. Developers are fully aware of troubles, but the problem is that resources are 1/1000 of needed. We are shooting monsters with slingshots, while you remain blind and ignorant no matter what is sent your way. Your startup dug lets say 5M EUR of starting capital which you waste to develop software that anyone can download for free and you also support it for free until you ran out money? I am sure you were not that stupid. This is automated test report from a few days ago: It is called "smoke test". It power boards on, checks basic functions following by reboot and powers off when done. And record few things ... We can run this at any moment and the plan is that it runs automatically at every code change. If end users refuse to fund software development and you do, perhaps rather help where project is asking for help? We are also asking for help developing this test system, which saves us a lot of time, or armbian-configurator, which saves you a lot of time, for several years now. Nice way or with applying a pressure (as now). Nothing. Cash to code with pros? Nothing. At least for things you want and need (problem from this topic) and you can't just steal from someone / download for free? Nothing. Back to topic? Who will spent several weeks digging into this driver? Biggest frustration is that I can't give that person anything, not even a comfort: "Its a hard work, there is a big possibility of failure and you will get no compensation because users do not respect this work or you". While our competitors will tell: "Dear John, we are working hard to solve this problem for you. You are important to us. It will probably take several months", while they will be opening a bug to us and applying a constant pressure. Welcome to the dark side of the FOSS projects.

I usually start this way: https://www.google.com/search?q=wifi+recognized+as+cd+rom then integrate it into our kernel or share on forums. Its not a problem specific to M1 nor Armbian.

My test device is now pretty stable: ____ _ _ ____ | _ \ ___ ___| | ___ __ (_) / ___| | |_) / _ \ / __| |/ / '_ \| | \___ \ | _ < (_) | (__| <| |_) | | ___) | |_| \_\___/ \___|_|\_\ .__/|_| |____/ |_| Welcome to Armbian 23.02.0-trunk.0118 Jammy with Linux 5.15.86-rockchip64 No end-user support: untested automated build System load: 2% Up time: 48 min Memory usage: 23% of 473M IP: 10.0.30.152 CPU temp: 36°C Usage of /: 7% of 29G RX today: 100.7 KiB [ General system configuration (beta): armbian-config ] Last login: Sun Jan 1 14:03:19 2023 from 10.0.10.12

Elsewhere you won't get much. Boot loader waits 1 or 2 seconds for input. This you can disable. Other services all together are close to nothing ... you can get down by shrinking kernel to support your use case only and use busy-box https://busybox.net/ and completely shrink OS functions, but its some work - if you can afford according to your use case. DHCP will sadly remain bottleneck, its also dependant on DHCP server ... this doesn't look like a hobby project?

Setting fixed IP address might get you some savings.

Bulk is recommended 😎

It is difficult to go back but staying on the same kernel branch. Which patches might not work properly. I could point you what to fix, but its pointless going that way. Lets try to stabilise M5 on K6.1 / latest (best working) u-boot. Which is the cause of this: SD card / eMMC initialisation is failing. This problem we are fighting with Amlogic for years.

I can understand you have good intentions, so thank you, but do you really think you (and community at large) are supporting this project in any way or it is perhaps the other way around? https://liberapay.com/armbian If you report a bug in software that you have downloaded for free, developers (you don't support), maintainers (you don't support) and support staff (you don't support) just looses more of their precious time and more of their private money. Development and fixing of those things is hard and time consuming work. Vendors that sold you hardware together are also unable to provide you quality software with their small sales margin and competition. FYI.

Event -> Video (with transcripts and comments) 1. Checking the progress of Armbian-next. most of open bugs has been fixed. How to help? users? continue to test various variants -> open a ticket developers? focus on cleaning rockchip64 / media patches, focus into config/ section -> moving family and board hacks into extensions 2. Armbian short description We are still not unified. Most sane idea is to better divide Armbian as OS for end users and Armbian as a build system for developers / integrator / business users and name those two more appropriate. We couldn't unite on a name to fit it all. 3. Mainlining of patches We generally agree and encourage this but we can deal with this gradually. Cleaning and squashing patches first, then move on. While doing this perhaps mark what could be good candidate to mainline so we don't press on people to proceed right on the spot.

We provide / have minimal images for software deployment purposes, where "nothing" comes preinstalled. Standard CLI image provides more things including possibility to recompile kernel, build armbian image, drivers, ... This was since ever, only default headers install was included recently.

To make it easier for installing drivers via DKMS is the only reason. But I guess its better to disable?

Welcome to Armbian forums! I have to be honest with you. We have no interest - it just bring more expenses & stress to the people that work on project. If we provide images that doesn't fully work, and they never do, we are loosing money which is very troublesome when having no income. There were never any support budget for this hardware. Not a single cent. Vendor is unfriendly and not "community driven" as they advertise. Pine64 also rather supports commercial Linux projects that are focused in taking advantage of other FOSS projects. Including ours. Most of their ARM section was ported from Armbian, PostmarketOS ... We were officially not notified about any hardware changes even they recommend our work. If LTS does not boot, is IMO expected. The problem officially does not exits. Our images were made for hardware called "Pine64+": https://github.com/armbian/build/blob/master/config/boards/pine64.conf#L4 LTS (probably) needs different boot loader config / settings. Towboot is just a fork of the same thing, a different UI with not enough people / activity to be taken seriously. Primary reason is anyway unrelated to low level hardware support, but to boot different kernels / user lands with the same boot image. Something that is not very important for Armbian.

Stable, weekly and CI builds https://www.armbian.com/orangepi-5/

The reasons why we don't officially deal with this HW is lack of people / resources / time. We would like to hire few developers to offload, but nobody wants to finance consumer needs and competition. If few dollars is to much, you are welcome to use builds with random support status and fix problems on your own. This hardware is even in automated testing setup, but equipment for checking HDMI output is limited. Not even sure why we have this HW in test system.

Giving us more work is pointless as we are years behind. Scope of desired changes from users side exceeds developers capacity for quite a lot. This is all what we can do in order to start moving this project (improving this application in all aspects, including UX) forward:

This download function certainly needs to be addressed in some way. On a side note - with upgrading to NEXT, all external compilers are go away. We would like to keep those things in Jira (invite was sent to your email, feel free to tackle/improve info on any other issue)

Doesn't boot with 3A images?

Event -> Video (with transcripts and comments) 1. Merging NEXT (updated slides) We discussed progress made in past week (Jira Epic) and set limited expectations for following week due to holidays season. We will try to enable rootfs caching CI at first (which has to be compatible with master) and Docker image creation next (which probably isn't?) 2. Unifying boot process Most single board computers needs good overlay handling so moving them to complete generic image is likely / in short term not possible. We still can not count on DTBless or DT from u-boot only, well support from vendor SPI. If we want to move like everything to UEFI and keep things operation / loose no feature, its a lot of work. Sorting out u-boots and going extlinux way with support for multiple kernels (NEXT/CURRENT) might be the best mid-way. 3. When 6.2 and 6.1, current / edge Keeping and stabilising 6.1 at EDGE for few months, waiting that it will be tagged as LTS for sure. Keeping new things like 3588 / 3568 at their own kernel branches, CURRENT = 6.1, EDGE = 6.2 (at once) @rpardini @JetHomeDid I forget to mention something important?

Event | Recording This weeks meeting topics: Merging of next generation build framework Primary goal is to understand benefits it is bringing as we all will need to sacrifice some time in order to review it, then merge and fix remaining bug. Despite our current system produces images, we have many bugs and dirty workarounds that this upgrade is addressing. The future of rockchip64 family Main goal is to make it maintainable again. GitHub development and review process Main goal is to motivate people to take more responsibility for reviewing and merging. Define clear rules. Conclusions: Everyone interested should watch a recording (~1h) and place a comment below. Comments will be discussed here and / or at next meeting. Before we can do anything in real regarding merging NEXT, we need to clean patches but also address several things, starting with those: Making a tool / module for patch generation (@rpardini) Preparing guidelines for review and contribution (@giddy) Move repo management from the build system (@igor) How to help? Cleaning the patches! (helper is here) armbian-next_-_meeting_21.dec.2022.pdf

Donations are very rare so I am happy, but they don't give you any service. This is your free willing contribution to cover small % of things that we already fixed for you. Remember that you are not paying for software in any way. If you want that research is done you need to become at least a gold partner. For your 5$ I can't hire anyone to look into your problem. Especially not myself. Welcome to the custom hardware world. Trick that works with Allwinner devices, doesn't work with Amlogic ... just wait, perhaps someone knows, I don't.

Workaround? yes (armbian-config, alternative kernels, choose previous one - 5.10.something), fix? With this, there is nothing we can do but wait like you that Hardkernel fix it.