bsrobot Posted September 24 Posted September 24 Hello everyone, I'm trying to get an ST7735S LCD display working with my Orange Pi Zero 2 (H616). This setup was working correctly with older Armbian kernels, but after a recent update, I can no longer get the SPI device to appear. I have already tried a couple of different configuration methods without success. System Information: Board: Orange Pi Zero 2 (H616) Display: ST7735S (SPI) Kernel Version: Linux orangepizero2 6.12.43-current-sunxi64 #2 SMP Wed Aug 20 16:30:58 UTC 2025 aarch64 GNU/Linux I have recently updated armbian-config by running the update from the script itself. Attempt 1: Using armbianEnv.txt My first attempt was to edit /boot/armbianEnv.txt and add the required overlays. Here is my configuration: verbosity=1 bootlogo=false console=both disp_mode=1920x1080p60 rootdev=UUID=aef396b8-ac79-477c-b797-466fc4d881a6 rootfstype=ext4 overlays=sun50ih616spidev1_0 sun50ih616spidev1_1 sun50ih616spispidev sun50ih616tft35_spi usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u After rebooting with this configuration, the device nodes are not created. The output of ls /dev/spidev* is empty. Attempt 2: Using a custom user overlay Next, I tried creating a custom Device Tree Overlay. I created the file /boot/overlay-user/sp1-spidev.dts with the following content: /dts-v1/; /plugin/; / { compatible = "allwinner,sun50i-h616"; fragment@0 { target = <&spi1>; __overlay__ { status = "okay"; pinctrl-names = "default"; #address-cells = <1>; #size-cells = <0>; spidev@0 { compatible = "spidev"; reg = <0>; spi-max-frequency = <50000000>; }; }; }; }; I then added sp1-spidev to the overlays line in armbianEnv.txt. This method seems to be partially working. After a reboot, I can see the SPI master controller: $ ls /sys/class/spi_master/ spi0 spi1 However, the spidev device is still missing. ls /dev/spidev* is still empty. Diagnostic Information Here is the output of dmesg filtered for "spi". It seems to refer to spi0, not spi1 which I am trying to configure, but I'm including it for completeness. $ dmesg | grep -i spi [ 2.821043] spi-nor spi0.0: supply vdd not found, using dummy regulator My Question I don't understand why the /dev/spidev* device is not being created, even when the spi1 master appears to be correctly enabled via the overlay. It seems like the spidev driver is not binding to the device. Since this worked on older kernels, has the method for enabling SPI devices changed? What is the correct procedure now? Is there something I'm missing in my overlay file or configuration? Thank you for your help 0 Quote
robertoj Posted September 25 Posted September 25 Is it the 128x160 1.8" red screen? Combine the knowledge of https://forums.raspberrypi.com/viewtopic.php?t=380704&hilit=ST7735S#p2275556 and https://forum.armbian.com/topic/47971-driving-the-ili9488-lcd-40-inch-cheap-chinese-clone/ To use the panel-mipi-dbi-spi driver, which is more universal for SPI screens Warning: you will not get the spidev, and the linux OS will handle all the rendering. Also, X11 may have a problem with Linux 6.14, unless someone fixes a bug 0 Quote
bsrobot Posted September 28 Author Posted September 28 Hello, and thank you for the suggestions. Just to clarify, I am not using an ILI9341 or ST7789 display. My display is a ST7735S (1.8", 128x160), a generic model purchased from AliExpress. The main issue is that while this setup worked perfectly on older Armbian kernels, it's no longer working with the current Kernel 6.12.x. It seems like the necessary module might have been removed or changed in the newer versions. I am not using a desktop environment; my goal is to use the display directly from the console/framebuffer (no X11). I’ve made some progress, but now I’m stuck. Here’s what I'm observing: The system does create a framebuffer device at /dev/fb0. When I use a tool like fbi to show an image, it runs without any errors. If I try to dump the framebuffer device (e.g., cat /dev/fb0), it outputs data, which suggests something is being written to the buffer. The problem is on the physical display itself: the screen's backlight turns on, but it remains completely blank (white). No image is ever displayed. I'm unfortunately not sure how to proceed from here. It feels like the display is being initialized enough to turn on the backlight, but the actual image data isn't being displayed correctly. I suspect the driver is not sending the right commands. Does anyone have an idea what I could try next? Thank you! 0 Quote
robertoj Posted September 29 Posted September 29 Describe what you did before to make it work. Show the DTS, the wiring you connected and the linux version that worked. If you used spidev before, I don't have experience in that. I only have experience with these drivers: panel-mipi-dbi-spi, ili9431 and adafrui-xy... The threads I showed you require you to stop using spidev, since the Linux kernel will communicate directly to the LCD, without a user program. Using both will just make them interfere with each other. If the LCD remains white and doesn't even flicker, and you made it work in an older kernel, then keep that wiring. If the /dev/fb0 exists, it means that linux has taken one SPI output port for display, but you need to make sure that: * and SPI parameters in the DTS are correct, * the gpio to handle the command/data, reset parameters are pointing to valid orange pi pins which are not used by anything else * the high/low polarity of those gpio * the wiring is correct, * the initialization bytes are correct 0 Quote
bsrobot Posted 5 hours ago Author Posted 5 hours ago Hello everyone, I followed the configuration steps for the st7735s LCD driver, and here are the details of my setup and observations so far: Configuration Files and Commands /boot/overlay-user/st7735s-fb5.dts Quote /dts-v1/; /plugin/; / { compatible = "allwinner,sun50i-h616"; fragment@0 { target = <&spi0>; __overlay__ { status = "okay"; #address-cells = <1>; #size-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&spi0_pins &spi0_cs0_pin>; }; }; /* Disable the on-board SPI flash on CS0 */ fragment@1 { target = <&spi0>; __overlay__ { flash@0 { status = "disabled"; }; }; }; fragment@2 { target = <&spi0>; __overlay__ { st7735s: fb_st7735s@0 { compatible = "sitronix,st7735r"; reg = <0>; spi-max-frequency = <32000000>; rotate = <90>; /* adjust based on actual orientation */ bgr; /* use typical ST7735S BGR order */ fps = <30>; width = <128>; height = <160>; buswidth = <8>; debug = <7>; dc-gpios = <&pio 2 6 1>; /* PC6 / D/C */ reset-gpios = <&pio 2 9 1>;/* PC9 / RESET */ cs-gpios = <&pio 7 9 0>; /* PH9 / CS */ /* Optional if BLK is on a GPIO led-gpios = <&pio 2 11 GPIO_ACTIVE_HIGH>; */ /* Init sequence word-aligned with padding */ fbtft,init-sequence = < 0x01 0 /* SWRESET */ 0x11 0 /* SLPOUT */ 0xB1 3 0x01 0x2C 0x2D /* FRMCTR1 */ 0xB2 3 0x01 0x2C 0x2D /* FRMCTR2 */ 0xB3 6 0x01 0x2C 0x2D 0x01 0x2C 0x2D /* FRMCTR3 */ 0xB4 1 0x07 /* INVCTR */ 0xC0 3 0xA2 0x02 0x84 /* PWCTR1 */ 0xC1 1 0xC5 /* PWCTR2 */ 0xC2 2 0x0A 0x00 /* PWCTR3 */ 0xC3 2 0x8A 0x2A /* PWCTR4 */ 0xC4 2 0x8A 0xEE /* PWCTR5 */ 0xC5 1 0x0E /* VMCTR1 */ 0x36 1 0x68 /* MADCTL: MX, MY, RGB -> adjust if needed */ 0x3A 1 0x05 /* COLMOD: 16bpp */ 0xE0 16 0x02 0x1C 0x07 0x12 0x37 0x32 0x29 0x2D 0x29 0x25 0x2B 0x39 0x00 0x01 0x03 0x10 0xE1 16 0x03 0x1D 0x07 0x06 0x2E 0x2C 0x29 0x2D 0x2E 0x2E 0x37 0x3F 0x00 0x00 0x02 0x10 0x13 0 /* NORON */ 0x29 0 /* DISPON */ >; }; }; }; /* Optional: define a dummy backlight regulator on GPIO if needed fragment@3 { target-path = "/"; __overlay__ { backlight: backlight { compatible = "gpio-backlight"; gpios = <&pio 2 11 GPIO_ACTIVE_HIGH>; default-on; }; }; }; */ }; Command used: armbian-add-overlay /boot/overlay-user/st7735s-fb5.dts Quote verbosity=1 bootlogo=false console=both disp_mode=1920x1080p60 rootdev=UUID=aef396b8-ac79-477c-b797-466fc4d881a6 rootfstype=ext4 overlay_prefix=sun50i-h616 user_overlays=st7735s-fb5 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u dmesg Output Filtered dmesg output related to framebuffer or SPI: Quote [ 141.351779] fb_st7735r spi0.0: fbtft_write_spi(len=1024): 00 00 00 00 ... [ 141.352102] fb_st7735r spi0.0: Display update: ... [ 168.697052] fb_st7735r spi0.0: Display update: 2050 kB/s, fps=4 [ 168.899058] fb_st7735r spi0.0: fbtft_update_display(start_line=112, end_line=127) [ 168.899108] fb_st7735r spi0.0: fbtft_write_reg8_bus8: 2a ... ... Observations Based on dmesg, the driver and display appear to be detected. Relevant messages are logged during updates. The command fbi works correctly, and running cat /dev/fb0 reveals some data. However, the display remains bright white, and nothing is visible on the screen. I attempted to test various initialization sequences (the commented-out sections in the overlay file) but without success. Next Steps Before writing this post, I wanted to conduct more testing, particularly with the LCD initialization parameters, but I'm unsure how to proceed further in debugging this issue. I'd appreciate any advice or suggestions to resolve the display issue! Thanks in advance for your help. 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.