After "apt upgrade", generic DSI display doesn't work in RPi5 #6341
Comments
|
#5784 was the display locking up and holding SDA low - #5784 (comment) If an older Pi5 bootloader works, then @timg236 for some weird bootloader change. |
|
We have a hunch that it's related to the clone of the Pi display not handling reading other registers, which is totally valid on our display. Simplest test is to add Running I believe we have a workaround, but would like to confirm that it's going to work before deploying it. |
|
Current kernels should be better at getting out of RP1 I2C error states, but there isn't much that can be done if CLK is being held low by a device. |
|
I insist in that it seems firmware-related. It's totally consistent with the firmware version used.
I don't know if the device is behaving badly or not regarding the I2C buses, but for sure this display works without issues in RPi4 (more than 200 x V5 units and nobody reported issues), and it has been working in RPi5 for months, until a recent firmware update broke things. By restoring the old firmware (but keeping the latest kernel!!!) the display works perfectly OK. Anyway, let me do the tests you suggest with i2ctransfer and so. I want to give you all the details you need. Regards, |
|
Yes the firmware has changed to read one additional register from I2C address 0x45. This is a legitimate thing to do on a Pi display, however we believe your clone display doesn't like it and locks up the bus. You can't modify the firmware, so my steps above are to confirm that it is this additional read that is causing your panel to lock up. |
|
Understood! Thanks for clarifying the issue. |
|
They're not "generic" displays, they are intentionally made to look like one of our displays - clones, as 6by9 said. |
|
Not mine. It doesn't look as a Pi display, simply try to "clone" or "implement" the Raspberry Pi DSI interface. It's called "5" TFT MODULE MIPI DSI". My provider doesn't sell the display as a "Pi Display", and of course i never thought it was a "Pi Display". |
|
For "look like" read "behave like" - I wasn't claiming it was a fake. |
|
This is believed to be related to the autodetection of the displays. Auto detect is there for genuine Raspberry Pi devices, but as these 800x480 panels pretend to the Pi to be the Pi 7" panel, the configuration for the Pi panel is loaded. There already is the option to manually configure these by setting Most I2C devices work by having addressed registers, so eg writing The 7" DSI panel has always been detected by reading register 0x80. (That is the key bit that these displays have cloned, and then they have to be prepared to accept the same video signal that is configured for the Pi display). For "reasons" we are now also reading register 0x01 during the auto detect. However most of these panels use microcontrollers (MCUs) to implement the I2C peripheral, and there it is down to how the MCU firmware has been written as to what it does under any condition. Mess that firmware up and you can lock up the I2C bus - that is what we believe is happening here. |
But this is legitimate. They tried to make them compatible with the RPi DSI interface, and i suppose they did their best, but probably they failed because of different reasons, but not willfully. Perhaps these details were not clear enough in the DSI technical documentation (BTW, i couldn't find it!), perhaps they didn't understand or perhaps they were simply lazy ... ;-) |
|
I forgot to say that before opening this issue, i already tried to disable autodetection (display_auto_detect=0) and loading different overlays like these:
When i did, then i can launch X11 and the display seems to work: But nothing is displayed in the LCD. I tried to toggle the backlight, but no luck Thanks |
It's not a generic display (for which the overlay needs configuring) and it's not a Waveshare panel (for which the overlay needs telling which display variant it is). Throwing in random garbage around rarely works.
So the display works but nothing is displayed?!?! I wanted to know about the I2C status and whether you can get it to lock up using the I have made a test bootloader that should work around the issue as we understand it.
|
|
Ups!! I missed the "dsi0" parameter! My fault! Now it's working with this config: For me, autodetection is not high priority so from my POV, the issue is "kind of solved". Perhaps you want to close or keep it open until you make the autodetection to work again. Thanks a lot for sharing your knowledge and give me support so fast!! Really!! |
|
Anyway, tell me if you still want extended info about I2C status using the i2ctransfer commands. I will do my best to help you to fully solve the issue. |
If you buy a third party exhaust for your car that looks the same as the original. Do you complain to the car manufacturer if something inside of the exhaust causes the car to go wrong? The Pi display is not open hardware, so they have reverse engineered it to look like the Pi display as they see it at the time. We haven't deliberately gone out of our way to break it, but due to what most engineers would consider quite a serious error in their MCU firmware, it appears to have a way to fairly seriously screw the system up. |
Yes, I would like you to confirm whether you can lock up their display controller, and tell me if the above test bootloader works. |
I understand and you are right, specially regarding the manufacturer lazyness when implementing the i2c firmware. They should have been made a more robust implementation, more I2C-complaint, but we all know "how relaxed" can be I2C interfaces of many chips and small devices, not only chinese ones ;-) Anyway, i personally dislike the foundation's policy about the DSI interface. It's not just a question of money and nobody is asking you to release the Pi-Display schematics/PCBs, but you could open the DSI specification and allow manufacturers to be compliant instead of having to reverse engineering the interface. IMHO, closing a hardware interface and using this to monopolize a market segment is not very nice, specially when you are the Pi Foundation and "spreads" the word of open source. But the more important thing is that this harms the ecosystem by imposing limitations and creating troubles to legitimate players that want to make it grow. (of course this is just MHO and i don't want to give moral lessons or so ... please excuse my "big mouth" ;-)) For instance, in my case, we needed an integrated display solution for our zynthian V5 design. Before walking the DSI path, we prototyped a custom HDMI display with a specific 24-pin FPC connector, that included HDMI and I2C for the touch. This allowed to make a integrated design, slim-enough, but it was suboptimal and resulted too expensive and hard to maintain. HDMI is not thought for this! So we decided to go DSI because this interface offered just what we needed (quite obvious! DSI is designed for integration). The only problem is that RBPi's DSI is not open. But we needed customized DSI displays and i doubt the RPi foundation is going to manufacture 500 custom 5inch Pi-display units for us (i must admit we don't even tried), so we walked the "clonic DSI" way because of the increasing availability of these generic DSI displays, and of course, because of the affordable price. We tested a few units and we didn't detect any issue so we were confident enough to go forward and reached a deal with a chinese manufacturer that customized 500 units that fitted our V5 design. That's all and V5 has been a real success!! What a beautiful device!! ;-) All the best. |
|
DSI has been fully open since Bullseye came out over 3 years ago, and was an option even before that if you selected vc4-kms-v3d manually. It's the 3rd party clones that piggy-back on our panel's configuration that causes these problems as we can't predict how they'll (mis)behave. You do have to manually edit config.txt to add the relevant dtoverlay line, but that's largely as there is no one generic way to autodetect a DSI panel, and there needs to be a line drawn as to how complex the firmware gets for these things. Enough debate and discussion - please test the bootloader and report back. |
Please, note that the first transfer ran OK and all the rest failed. The I2C bus seems locked. |
|
I repeated the test with the register 0x1. Same result. |
|
I apologize for my comment above. It's clear that i was badly informed about the DSI and deserve some hard punishment to my silly words. |
|
I just tested the firmware you attached and autodetection works again. Is it safe to use for production? Thanks! |
It's safe, but please don't. We will get this merged and released through apt as quickly as we can. |
|
Not in a hurry ;-) |
|
I've realised I made an error within the first test firmware, which would have issues under certain conditions (not yours). |
* Fix lockup regression with some 3rd party 7" DSI panels See: raspberrypi/linux#6341
* Fix lockup regression with some 3rd party 7" DSI panels See: raspberrypi/linux#6341
|
Now released via rpi-update. |
|
Big thanks @6by9! Do we have an aprox. date for having this in the mainstream firmware? Regards |
+ Update recovery firmware. + Unmask "rpi_eeprom_update" service and rpi-update to get fixed firmware that solves the issues with DSI display detection (raspberrypi/linux#6341).
|
We have started prepping a full image update, so I would expect it to get merged to apt in the next few weeks. |
Describe the bug
After an update, my generic DSI 5 inch display stopped working. It's a generic display that i've been using with more than 200 devices with RPi4 + display (zynthian V5) without known issues. It has been working with the RPi5 for months, but suddenly, after an update, it stopped to work.
The issue seems to be firmware-related and also it seems related to this thread and others. I found this lines in the logs:
I did:
It seems that the I2C lines behave as described in #5784 and others, preventing the touch controller to be initialized, what seems to break the DSI overlay.
After reflashing an older firmware, the issue vanishes and the display works normally. Then i do:
Steps to reproduce the behaviour
I can reproduce the issue consistently by simply reflashing the recent firmware.
In the other hand, by flashing an older firmware, the issue gets "fixed".
Device (s)
Raspberry Pi 5
System
I'm using latest RaspberryPiOS Bookworm aarch64, updated to the last official kernel and packages. No rpi-updates.
Logs
This is the log whe booting with the recent firmware, that causes the error:
After recovering an old firmware version, it works normally:
Additional context
Please, note that it's the same SD image with the same kernel and configuration. The only difference between the 2 boots is the firmware.
Also note that the display works flawlessly with RPi4 and it has been working with RPi5 for months.
I've "patched" the system with:
$ sudo systemctl mask rpi-eeprom-updatebut this is highly sub-optimal!
The text was updated successfully, but these errors were encountered: