Q: Is there an easy way to just build an image for teres without all the armbian bits that is mergable?

[Kreyren]

Task description

Point is that armbian always does bunch of weird things that break teres and it's really flustrating to always going on a wild geese chase figuring out what broke it this time.

Ideally i just want the armbian framework to build the teres image as:

1. Mainline kernel (sunxi kernel often breaks things, i am focusing on mainline only and treat sunxi kernel as playground for new features that are yet to mature there)
2. No Firmware blobs[*] (it has 16GB of internal storage and that makes it basically unusable)
3. Separate u-boot binary with and without crust to flash on the SPI

* with the exception of wifi unless we do the linux-libre hack to make the wireless to run without the blob, but that's kinda difficult to perform reliably.

As it doesn't really make sense from a development point of view and only wastes time for something that shouldn't be done in the first place.. i currently put together a very hacked up way to handle request from #7099 and making that into something that can be merged seems like a nightmare rn with teres users just using the images from debian and having no issues there (there are minor issues that i work on for kernel 6.11, but that's besides the point rn) .

[github-actions]

Jira ticket: AR-2486

[igorpecovnik]

• Armbian framework is certainly not responsible that Teres is broken. There are too many proofs against.
• bugs in framework exist, its a software, so there are bugs, but it is close to impossible that problems are exposed only for this device
• mainline kernel is breaking all the time, especially with Allwinner. sunxi is pre-mainline, just maintained better (Debian has no maintenance of arm hardware, similar to other generic distros) and has more recent fixes and fixes that won't ever make it to the mainline. There is a generic unpatched uefi arm64 kernel, which would be close to Debian's. Enable Allwinner support if there is missing by some random act and use that if you like. Or just disable all patches and build image for Teres.
• without crust is a serious step back.
• "just using the images from debian and having no issues there" = act of randomness. Teres (or any other board) works fine, until something breaks it. You will always find a distribution that didn't build images with currently bad code.

Start taking hardware maintenance more seriously? You simply need to invest more time, you need to understand why its broken, "weird things" is not an answer to this. Either you don't know, or you don't have motivation / interest to deal with this. Which is all legit in best effort support case. If you take this responsibility, it is yours.

Features are more important then fully blob-less experience. This is nice to have, a luxury. We provide open source drivers if this is possible and if provided features are on pair with closed ones. Open source is a lot more expensive, while in both cases, users care & contribute the same.

[Kreyren]

Armbian framework is certainly not responsible that Teres is broken. There are too many proofs against.

There are issues with running on NixOS that i don't want to get into and tried to report them, i consider it won't fix as fixing that seems more effort than reasonable and developing armbian in a debian box since that's what the automation is expecting.

mainline kernel is breaking all the time, especially with Allwinner.

That doesn't seem to no longer apply to the A64 chip, it used to be the case until the clocks were refactored and now it's rather the opposite as sunxi currently focuses on new chips where some contributions might interfiere with A64 which is outside of my control as the QA is handled by other developer for the chip there and i would have been a 3rd wheel there.

without crust is a serious step back.

meant to aid development on other distros to figure out if the power management is broken in the OS or in the firmware as it would help the other maintainers (as requested from them where currently i just send out built binaries from my nix) to have quick reference for it that can be noted in the sunxi wiki.

you need to understand why its broken, "weird things" is not an answer to this

I know why exactly it's broken, but trying to simplify it to not overcomplicate the issue.

You simply need to invest more time,

Reminder that i maintain all mainstream distros for the device (minus anything redhat touches), my development is oriented for mainline to make it resource efficient for it to work on all these distros and i coordinate it with other kernel devs so that we don't need downstream patches + FreeBSD

FWIW: Additionally i was gifted OlinuXino-A20-LIME2 yesterday that i work on being able to maintain in armbian.

[igorpecovnik]

There are issues with running on NixOS that i don't want to get into and tried to report them

Our aim is to provide build system and ready to run Debian like OS which one can recreate with their changes. Official supported host is Ubuntu Jammy, not even on Noble everything works (yet). This is already complex enough (somewhere line has to be made) and already exceeds what we are able to accomplish. You can open tickets if you will deal with them properly. I will not deal with them. Not that I would not want, I need to stay sane. Supporting problems is very limited and this won't be changed without someone investing millions :) to hire help. Which we both know it won't happen.

That doesn't seem to no longer apply to the A64 chip

This chip is 1st 64b from Allwinner. It is already considered as a retro hardware.

QA is handled by other developer for the chip there and i would have been a 3rd wheel there.

QA doesn't help if you don't have resources to fix problems QA finds. Look on forums. Many troubles are reported, some are addressed most not, some never will. All we can do is trying our best. This is sad reality of such projects.

focuses on new chips where some contributions might interfiere with A64 which is outside of my control as the QA is handled by other developer for the chip there and i would have been a 3rd wheel there.

Yes, that is true, most people are focused to more recent hardware. We have little to fight this.

meant to aid development on other distros

Supporting other distros while we struggle to support ours? And most of other distros doesn't help. They are not like you. You try, most don't even think to. Shipping our work is a lot cheaper then dealing with problems and again there is nothing we can do.

but trying to simplify it to not overcomplicate the issue.

This is exactly what Armbian does. Framework might went over this simplicity, but to keep it simple, to not allow to eat us = work.

Reminder that i maintain all mainstream distros for the device

Make sure to not shuffle that burden to Armbian. This is already happening at too big extend.