Framebuffer Copy SPI issues since kernel update on Jan 4

[makermelissa]

Describe the bug Since the firmware update on Jan 4 and including the subsequent update on Jan 8, using Framebuffer copy does not work anymore. I get the following messages looping over and over in dmesg:

[    6.051273] fb_st7789v spi0.0: SPI transfer timed out
[    6.051352] spi_master spi0: failed to transfer one message from queue
[    6.051374] fb_st7789v spi0.0: fbtft_update_display: write_vmem failed to update display buffer

The bug appears to only affect the Raspberry Pi Model 4 and not the 3B. We have a bug report filed on Adafruit at https://github.com/adafruit/Raspberry-Pi-Installer-Scripts/issues/138 with some more info/photos.

To reproduce Follow this guide and setup the display: https://learn.adafruit.com/adafruit-braincraft-hat-easy-machine-learning-for-raspberry-pi focusing particularly on the Display Module Install section, except use the Raspberry Pi OS full version.

Expected behaviour The display shows a clear image on the display of what would normally be output to the HDMI port and updating is smooth.

Actual behaviour The display shows a garbled image on the display, and display updates are extremely infrequent.

System Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions: https://pastebin.com/Eu5TZvk2

Logs If applicable, add the relevant output from dmesg or similar. https://pastebin.com/sw4Cb4ka

Additional context Add any other relevant context for the problem.

[makermelissa]

Any word on this?

Also, tagging @ladyada.

[pelwell]

If I'm following your installation instructions correctly you appear to be running a custom st7789v driver. I understand that upstream stripped out some of @notro's Device-Tree-defined driver support, but in September last year I restored support for some boards but in a more conventional fashion. Can we not expand that to cover your other devices?

Can't you lay your hands on a logic analyser to look at the SPI bus traffic? It would make diagnosis a lot easier.

[ladyada]

@pelwell hihi we'd love to have native support for this display. particularly as we're starting to see a lot more vendors use the st7789v - we used to be able to the generic framebuffer but yeah that was ripped out.

that said, we think there was something else going on here that was causing issue, which we're currently working around by pinning to kernel/firmware 5.4 @makermelissa did we see the corrupted data with non-ST7789v displays?

[makermelissa]

I think only the ST7789v displays were affected.

[makermelissa]

I experimented with using the st7789vw driver from (https://github.com/notro/tinydrm) and experienced the same issue with the text. In both cases it appears to work immediately after installing, but after another rebbot or two, it just seems to sporadically draw in various places. I can hook up a logic analyzer to view SPI data, but I'm not exactly sure what I should be expecting to see.

[pelwell]

OK, which is the best display to buy to debug the problem?

[ladyada]

https://www.adafruit.com/product/4484 or https://www.adafruit.com/product/4393 they both use ST7789V as a bonus, almost all pimoroni devices with screens use the same chipset so they'd probably also be chuffed (that's the right word? :)

[pelwell]

Chuffed is absolutely the right word.

Time to blow half the R&D budget...

[JamesH65]

Been trying to get one of these working on a Pico, got to the point I think the display might be broken....so careful where you get it from, mine was an Ebay special at £5.99. Some of the soldering does look a bit shonky.

[pelwell]

I've ordered a genuine AdaFruit 4484 from Pimoroni, so I'm expecting minimal shonkiness (otherwise I'll be dischuffed).

[ladyada]

takes notes on emergent language of the native Pi People

[leeyunjai82]

The oled using the ssd1306 chip has the same symptoms. Whenever I boot, there are times when the symptoms appear, and sometimes the symptoms do not appear.

[pelwell]

The 1.3" 4484 display arrived today, and It works for me. Full disclosure: I didn't run the Adafruit installer.

This is what I did:

$ wget https://raw.githubusercontent.com/adafruit/Raspberry-Pi-Installer-Scripts/master/overlays/minipitft13-overlay.dts
$ dtc -@ -I dts -O dtb -o minipitft13.dtbo minipitft13-overlay.dts 
$ sudo cp minipitft13.dtbo /boot/overlays/
$ echo dtoverlay=minipitft13 | sudo tee -a /boot/config.txt
$ sudo reboot
$ git clone https://github.com/adafruit/rpi-fbcp
$ cd rpi-fbcp
$ mkdir build
$ cd build
$ sudo apt install -y cmake
$ cmake ..
$ make
$ sudo cp fbcp /usr/bin
$ fbcp

At this point the main display is mirrored onto the 1.3" mini-display.

[pelwell]

In case it wasn't obvious, this is using the off-the-shelf fb_st7789 driver in rpi-5.10.y. If it's lacking some crucial setup, it isn't obvious from the display - contrast looks OK, and colours are correct.

[makermelissa]

Did it still work even with rebooting a couple of times?

[pelwell]

It's at 5 for 5 and counting.

[makermelissa]

Excellent, I will give this a try in the next couple of days and see if I can adapt it. Thank you.

[ladyada]

i thiiiiink one of the things we'd still need to do is add rotation and offset support to that fb_st7789. i dont remember why i didnt use it back then. its been so looong :D

[pelwell]

rotate=270 appears to work perfectly, but 90 and 180 have an offset.

[notro]

One of the lessons I learned after making fbtft is that rotation is display/panel specific and not controller specific. So one set of rotation values may or may not work with a panel of the same resolution using the same controller.

[pelwell]

I'm sure there's just a small amount of configuration required. We can add a specific compatible string for the display if needed.

[pelwell]

https://github.com/raspberrypi/linux/pull/4156 includes the minipitft13 overlay and fbtft driver support with corrected offsets for rotation. It's tested on 4484, but might also work on 4393 (which I don't have).

[ladyada]

@makermelissa wanna try it?

[makermelissa]

Yep

[pelwell]

You can either add and fetch my personal github repo - call it pelwell, then checkout my branch as pelwell/minipiftf13 - or (and this might be simpler) - download my commits as raw patches and apply them with git am <patch-file>:

$ curl https://github.com/raspberrypi/linux/commit/a95a5ba4aeb76514f453434d9d276fa4d85745fa.patch > patch1
$ curl https://github.com/raspberrypi/linux/commit/42097884b80cd75c1aedebef69aed4324b1b227b.patch > patch2
$ git am patch1
$ git am patch2

[pelwell]

[ That second URL got a bit mangled, but it should be OK now ]

[makermelissa]

Ok, so I got to testing and here are some of my findings. I ended up downloading the fbtft folder with the files as well as your .dts file. So it looks like the primary issue in this repo was fixed with the new device tree overlay, but onto my testing of the driver. I wasn't sure of the exact commands to compile, so I made my own Makefile and was able to get it compiled. I replaced the file at /usr/lib/modules/5.10.11-v7l+/kernel/drivers/staging/fbtft/fb_st7789v.ko and it boots fine.

Rotation wasn't working with offsets and I figured out that is because it's not detecting the variant for whatever reason (maybe the way I compiled it). So for testing purposes I forced the variant by adding it to .fbtftops where the display struct is created. Rotation worked fine at that point.

I tested out the 1.14" which has its own set of offsets, so I'm going to work on the init logic tomorrow for a bit so that it'll work with 1.14" (135x240), 1.3" (240x240), and 2.0" (320x240) displays. I was wondering if it would be better to create additional variants since the offsets are pretty weird for the 1.14" display and then we could create another DTS file for the 1.14" display to make swapping in and out easier. You can see how we do it in Arduino here: https://github.com/adafruit/Adafruit-ST7735-Library/blob/master/Adafruit_ST7789.cpp. Another option might be allowing the x and y offsets to be specified in the DTO rather than hard coding so they're easier to override.

[pelwell]

That's great news. I'm happy with the creation of additional variants - there isn't a big overhead in module size, and I think they are more likely to be upstreamable (the rejection of @notro's DT-based approach for "religious" reasons is a shame), not that that's an absolute requirement.

[darrenliew96]

i have a gamepi20 and its using st7789v 2inch lcd, those who are using LCD like this can benefit from it.

https://github.com/darrenliew96/gamepi20_drivers

[makermelissa]

So I have been working on this driver for the past few days. I could not get variants working still, so I ended up sticking with a single compatible string and am adjusting the offsets based on the passed width and height. You can grab the updated fb_st7789v.c file from here: https://github.com/adafruit/Raspberry-Pi-Installer-Scripts/blob/master/st7789_module/fb_st7789v.c The overlays (which all use this driver now) are available at https://github.com/adafruit/Raspberry-Pi-Installer-Scripts/tree/master/overlays and only vary by screen dimensions and default rotation.

Now, I am getting some strange results in portrait orientation on the 1.14" display:

I can confirm that this is reproducible on the 240x240 display if the dimensions and rotation are configured the same:

To reproduce it on that display, if you use the minipitft114.dts overlay and using the following settings in your /boot/config.txt file:

hdmi_cvt=270 480 60 3 0 0 0
dtoverlay=drm-minipitft114,rotate=0

What I can figure is that despite setting it to a width of 135, it is trying to draw out 240 lines wide anyways and then wrapping around, so I'm not sure if it's related to something else. Adjusting the width over 135 makes it less wrappy, but it still does this until you hit 240.

Some other odd things I have noticed related to this mode: If you swap width and height in the hdmi_cvt setting and use default rotation it looks fine. setting display_rotate=1 or display_rotate=3 causes the pi to not boot. It never writes to syslog, so I don't have details on exactly why, but I assume it's trying to write to some memory outside of what it should be having.

Currently we are working around this by not allowing users to specify this combination in our installer script.