Display Issues w/ iMX8MPlus on Classic Reform

MNT Reform
1

Just got an iMX8MPlus, used from someone who had it in a pocket reform. Made sure to update the uboot so that it uses the one for the Classic Reform. It will boot up, and if I change the kernel commandline parameters to get it to use serial I can see that it actually fully boots and I can log in. The backlight for the display comes on, but it stays black. I never see anything. This is all on the latest version of the reform system image.

I am able to get it to work if I go back to the 6.8.12 image. The initial log prints from the kernel show the screen rotated 90 degrees (got an audible laugh from me when I saw that) but when sway boots up it’s fine.

This is the image that works for me.
https://reform.mister-muffin.de/images/2024-06-05/reform-system-imx8mp.img.gz

2

The very next published image, 6.12.6, does not work.
https://reform.mister-muffin.de/images/2025-01-09/reform-system-imx8mp.img.gz

3

Progress! Got the display to work on 6.12.6.

Took a lot of debugging and reading out the registers on the display bridge. The PLL was locking, and I could get the bridge to show a colorbar pattern on the screen by writing to the 0x3C register. Issue seemed to be between the iMX and the bridge, on the DSI link. I read out the error registers, and on 0xF6 I saw 0x40, or LOSS_OF_DP_SYNC_LOCK_ERR. 0xF0 was clean of errors, which means that PHY was clean. 0xF1 only set CHA_DSI_PROTOCOL_ERR, which makes sense if it lost sync. The packets are good, the link is good, but it’s losing sync. Seemed like a clocking issue.

Bisecting the changes between these releases showed me this change to how the pixel clock is generated. This was made upstream.

--- a/drivers/clk/imx/clk-imx8mp.c
+++ b/drivers/clk/imx/clk-imx8mp.c
-     hws[IMX8MP_CLK_MEDIA_DISP1_PIX] = imx8m_clk_hw_composite_bus_flags("media_disp1_pix", imx8mp_media_disp_pix_sels, ccm_base + 0xbe00,CLK_SET_RATE_PARENT);
+     hws[IMX8MP_CLK_MEDIA_DISP1_PIX] = imx8m_clk_hw_composite("media_disp1_pix", imx8mp_media_disp_pix_sels, ccm_base + 0xbe00);

Reverting that, rebuilding (and applying all the MNT patches) brought the display back.

This change seems to make the pixel clock go from 148.5MHz to 162MHz. Maybe this is too fast for the DSI link to handle?

stock 6.12.6 and 7.1.7:
video_pll1                     162000000
   video_pll1_out              162000000
      media_disp1_pix          162000000
         media_disp1_pix_root_clk  162000000   32e80000.display-controller  pix

6.8.12, and the patched build:
video_pll1                    1039500000
   video_pll1_out             1039500000
      media_disp1_pix          148500000
         media_disp1_pix_root_clk  148500000   32e80000.display-controller  pix
4 Likes
Want To Buy: An Old iMX Module (USA)
4

Confirmed the same patch works on 7.1.7 as well. I think this is the problem. Not sure why it is the problem, but it works when reverted.

2 Likes
5

Amazing, thank you for doing that work!

Do you have an account on source.mnt.re? Do you want to create one and submit your reverted patch against the reform-debian-packages repository?

You can also send me a git-format-patch so that I can apply it for you if you don’t want to set up an account.

6

Cool debugging work! It’s weird that the upstreamed patch loses clock precision there. I’m wondering if there’s any cross reaction with https://source.mnt.re/reform/reform-debian-packages/-/blob/main/linux/patches7.1/imx8mp-mnt-reform2/0002-lcdif-dont-exceed-desired-pixel-clock.patch?ref_type=heads though, which I did at one point when upstream was breaking clocks. Maybe my patch is now detrimental, or doesn’t make a difference?

7

I will make an account. I have admired MNT for a long time and it would make me very happy to have my name in the commit history. I’ll also see if there is a better fix for this. Changes are made upstream for a reason, maybe we just need to reconfigure the clock to be slower and have it coexist with the upstream patch. Just reverting upstream is not always the right solution.

Now that the display works, I want to look at suspend/resume. This is the last thing I need before the reform classic can truly replace my framework 13". Minute said this was working a long time ago but upstream broke something. I did some pm_test work, but the display bridge was not come back to life and the test dies at devices. Will keep digging.

2 Likes
8

IRC history says that it wasn’t working with 6.10.

And an even older message by Lucie said that it was broken around 2023-05-09 already (no mention of kernel version).

1 Like
9

Thank you, that narrows my timeline down by a lot