LCD has no stable picture

The boot shows vertical bars where the penguins are but and there's no login prompt after boot.

changed title from LCD has not stable picture to LCD has no stable picture

added critical label

To summarize the state a bit more:

• panel's self diagnostic result (0x0F) report's success
• turning on all pixels via MIPI DSI (0x23) works

We're looking at the panel init sequence with the vendor.

Does this occur on the images we distribute?

Not without changing the device tree (librem5-evk-lcdonly has it enabled).

The one we ship by default (librem5-evk) has the LCD disabled (although not the backlight). I've adjusted current kernels to also disable the backlight to avoid confusion.

Since this came up on matrix. This is the panel driver

https://source.puri.sm/Librem5/linux-emcraft/blob/imx8-4.18-wip/drivers/gpu/drm/panel/panel-jh057n00900.c

and you need the -lcdonly dtb.

We just confirmed that the issue comes from the init sequence sent to the panel being corrupted (notably the SETGIP1 and SETGIP2 parts) and we are looking into a workaround.

So it's confirmed to be a software only issue?

Just to show that the devkit's MIPI DSI hardware and the panel hardware are sane: This is the devkit's panel where we OTPed (one time programmed) the exact same init sequence that is in the current kernel driver:

We're now looking into doing the same without OTPing the panel first but letting the driver do the work.

Did this OTP init sequence also run the driver code? Essentially, Does it get the init sequence twice?

Also, I am unfamiliar with the DSI protocol. Does the panel send a response signal on command completion?

Did this OTP init sequence also run the driver code?

No, it doesn't use the driver code. It runs of a totally separate device using a different DSI host chip and dphy. The OTP process uses the very same DSI commands though (plus the ones needed to persist the settings).

Essentially, Does it get the init sequence twice?

I'm not sure I understand the question but with the current driver layout even OTPed panels get the init sequence on each boot but it does nothing since it's OTPed.

Also, I am unfamiliar with the DSI protocol. Does the panel send a response signal on command completion?

There's no "I'm ready display a picture now" kind of command but you can query internal self test status (which you can see in earlier versions of the panel driver). We used that early on to check that

• we can communicate in LP mode both ways
• the panel indeed passes it's internal test

Hey all,

I've been looking into this issue for a bit but unfortunately due to other time requirements and the missing Datasheet i can't purse it further.

I found two other driver for what seems to be the ST7703 IC, those looks similar but are slightly different to yours.

One is part of the orangepi-4g-iot-bootloader and the other seems to be part of an Android Kernel for the MediaTek Helio P23 (MT6763T) Processor.

The biggest difference seem to be the dsi write function and it's usage, but the content is to similar in my opinion to be coincidence. Maybe those values combined with the Datasheet of the ST7703 you've got access to might help you figure out what's different.

If you've already done that I'm sorry for wasting your time reading this but i've been sitting on this idea for 2 weeks without finding the time to try it out.

With best regards

@sittkuma Thanks for the links. I see some differences in the initialization commands/data but, like you, I can't draw any conclusions. Hopefully those links will bring new insights into the problem.

Is the "one-time-programming" something we can do ourselves? Or would it be helpful to have some unprogrammed devices around to be able to test the upcoming fix?

@yogo1212 I don't think this is something you can do yourself unless the programmer is commodity hardware. It will be useful to have an unprogrammed device to test the fix but I think there are quite a few of those out there, so there isn't a shortage of potential testers.

Is there an oppurtunity for me (and others) to send in the devkit to have the display OTP'd and sent back?

@craftyguy can you check with support@puri.sm ?

I personally don't know anything about DSI/DRM but tweaked the driver to use similar init as the one given above without any succeed.

probably a long shot: But would it be possible move the init sequence to uboot? To see if it works? Less other stuff involved in uboot? And isolate that it is not kernel driver thingy?

I think it would be interesting to try adding panel initialization to U-Boot, though I'm not sure how it would be done exactly. The drivers/video directory contains code for setting up other panels that also look like they are initialized in a similar way, at least from my limited understanding.

Using a logic analyzer and https://github.com/stawiski/Saleae-MIPI-DSI-LP-Analyzer we were able to verify that SETGIP1 and SETGIP2 are not being sent correctly to the panel due to i.MX8MQ's errata "e11418: MIPI DSI: Incorrect CRC and payload corruption reported with DCS long write command". Working around that using HS mode does not work for this panel so we're looking at a different parameter set.

@guido.gunther Thanks for letting us know :-) If I understand correctly, the phone is planned to use the same platform (and suffer from the same errata) but some one-time-programming could solve the issue without having to create a software workaround (driving up the cost per unit). Correct?

I'll switch to HDMI for the moment.