-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Display is broken on OLIMEX Teres-I #6630
Comments
Jira ticket: AR-2318 |
Its not a problem if you are busy, but non working display is pretty critical problem for laptop ... as there is no time, I can only disable "supported" tag on download until this is not resolved as providing known broken images for supported hardware is bad for reputation. |
Teres users are different userbase from the generic consumer base and generally know how to manage this problem + are in talks with me on them (all known problems explained in detail on https://linux-sunxi.org/Olimex_Teres-A64#Known_issues), So keep the supported tag and instead i will add notes about these issues to the armbian page with links until i track down the cause of this issue in armbian (not known to happen on other distros, the display was broken in non-lts kernels until 6.8 so i assume that someone's applying obsolete patches to the armbian kernel atm) |
Its better that its community supported until problems are not resolved as those images are auto-created once per week, one desktop, one CLI image. If someone else fixes this upstream it will just start working ... Once you confirm they work, status is changed back and new stable kernel is pushed to repo + stable images are recreated. This is exception that can be made.
You are free to add comments what users need to do to get going, but it might be less work just fixing it. I understand you are busy, everyone is, this is not a critical problem => when you find time.
Nobody is deliberately doing anything. I don't know what is the status, nobody knows "at Armbian", which is the reason why we have maintainers. They know. You know. I only know for few boards that I am dealing with and things we have on automated testings. |
I am not saying that someone's doing that deliberately rather that there were a lot of relevant changes in the kernel that required downstream patches for other boards that might be interfiering with the device at the current very rushed hypothesis of mine. |
Should be fixed now, tested and the display worked each time for me using the images from armbian download and diagnosed as issues in the kernel as sunxi and others were touching a lot of teres-relevant parts so the device basically had issues each release that shouldn't be a problem anymore. Heads-up: @igorpecovnik mark as supported plz |
FWIW: If the issue shows up again then it will likely have to be fixed in u-boot to do proper display initialization sequence for the display |
What happened?
On kernels past 6.1 there have been few reworks of the relevant components that cause the display to not get initialized correctly
I fixed that by adding:
to
/etc/initramfs-tools/modules
and then ranupdate-initramfs -u
Self-Assigning.. Currently very busy will fix it when i find a time frame for it.
How to reproduce?
Run the pre-built image on the device
Branch
main (main development branch)
On which host OS are you running the build script and observing this problem?
Debian 13 Trixie
Are you building on Windows WSL2?
Relevant log URL
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: