DietPi-Config | tft35a LCD display support

[SteveJohnsson]

G_DIETPI_VERSION_CORE=6
G_DIETPI_VERSION_SUB=21
G_DIETPI_VERSION_RC=1
G_GITBRANCH=master
G_GITOWNER=Fourdee
G_DISTRO_NAME=stretch

Kernel=Linux pi 4.14.98-v7+ #1200 SMP Feb 12 2019 armv7l
Device=RPi 3 model B
Power supply=USB from the router
SDcard: SanDisk ultra

• Can this issue be replicated on a fresh installation of DietPi?
  > Yes

Steps to reproduce

1. Download and unpack drivers: https://github.com/goodtft/LCD-show
2. Install ./LCD35-show

Expected behaviour

• The script is kinda messy, it has been discussed earlier, but the solution provided here (https://github.com/Fourdee/DietPi/issues/1598) is not working. Expected behavior is that TFT LCD screen goes from white to present the output from the console.

Actual behaviour

Installation fails (Yes, the script is messy)

Extra details

• The script works fine on latest Raspbian. After the installation LCD screen turns on and works as it should. However, this is not the case with DietPi. I'm suspecting that the script cannot complete because of this statement:

if test "$nodeplatform" = "raspberrypi";then echo "this is raspberrypi kernel" version=${version%% *} version=${version#*#} echo $version if test $version -lt 970;then echo "reboot" else echo "need to update touch configuration" sudo apt-get install xserver-xorg-input-evdev sudo cp -rf /usr/share/X11/xorg.conf.d/10-evdev.conf /usr/share/X11/xorg.conf.d/45-evdev.conf echo "reboot" fi else echo "this is not raspberrypi kernel, no need to update touch configure, reboot" fi

[MichaIng]

@SteveJohnsson
Thanks for your report.

Yeah indeed the script is out of style, but this is no big issue, it is small enough to easily allow an overview.

The problem is more, that it simply overrides several RPi core config files completely, thus overwriting any other required or manually made changes. This is easier from the scripts/drivers dev point of view, but breaks any custom use cases and requirements. So lets try to find the essential settings that are required to run this LCD.

First thing of course the driver itself is required:

cd /tmp
wget https://github.com/goodtft/LCD-show/archive/master.zip
unzip master.zip
rm master.zip
cd LCD-show-master
cp usr/tft35a-overlay.dtb /boot/overlays/
mv usr/tft35a-overlay.dtb /boot/overlays/tft35a.dtbo

Next is the X.org calibrations:

mkdir -p /etc/X11/xorg.conf.d
cp usr/99-calibration.conf-35-90  /etc/X11/xorg.conf.d/99-calibration.conf
mkdir -p  /usr/share/X11/xorg.conf.d
cp usr/99-fbturbo.conf  /usr/share/X11/xorg.conf.d/

Next is the kernel command line file cmdline.txt. Instead of overwriting the whole file, lets try to add only the required additions, although not sure if they are even required:

sed -i 's/[[:blank:]]logo.nologo//' /boot/cmdline.txt
sed -i 's/[[:blank:]]fbcon=[^[:blank:]]*//g' /boot/cmdline.txt
echo "$(sed -n 1p /boot/cmdline.txt) fbcon=map:10 fbcon=font:ProFont6x11 logo.nologo" > /boot/cmdline_new.txt
mv /boot/cmdline_new.txt /boot/cmdline.txt

The inittab file can be skipped with systemd. There is nothing LCD specific inside, only default getty spawn and runlevel settings.

Next is the config.txt, same as above lets find and add/set the really required settings. Hmm looks like the LCD driver overlay is the only thing, the remaining looks like an old default file, so:

G_CONFIG_INJECT 'dtoverlay=tft35a' 'dtoverlay=tft35a:rotate=90' /DietPi/config.txt
G_CONFIG_INJECT 'dtparam=i2c_arm=' 'dtparam=i2c_arm=on' /DietPi/config.txt
G_CONFIG_INJECT 'dtparam=spi=' 'dtparam=spi=on' /DietPi/config.txt
G_CONFIG_INJECT 'enable_uart=' 'enable_uart=1' /DietPi/config.txt
G_CONFIG_INJECT 'hdmi_force_hotplug=' 'hdmi_force_hotplug=1' /DietPi/config.txt

The nodeplatform thing is a bid confusing and as you said most likely is the issue why enabling the LCD fails. uname -n prints the hostname, which is in very most cases not raspberrypi, actually not even by default on fresh Raspbian, I think? And of course hostname and kernel are totally independent from each other. And the current kernel version that is compared in the script is 1200 >= 970:

2019-02-25 22:15:21 root@micha:/tmp# uname -v
#1200 SMP Tue Feb 12 20:27:48 GMT 2019

So lets do the touch configuration updates:

G_AGI xserver-xorg-input-evdev

• This installs the whole xserver package tail, so can take a while, if you didn't install the xserver yet, AFAIK.

I don't get the last command. This simply doubles one config file installed by the above packages. It raises its "priority" but as long as those settings are not overridden by another one (with priority between 10 and 45), this should have no effect. And even if wanted, then the file should not be copied, but moved, to not have doubled settings 🤔. I would just skip this...
~cp /usr/share/X11/xorg.conf.d/10-evdev.conf /usr/share/X11/xorg.conf.d/45-evdev.conf~

Finally:

[MichaIng]

@SteveJohnsson
Ah one more thing, since this is no HDMI display? I don't know too much about this, but do you know if the display uses I2C, SPI and/or UART interface?

If it does not work or as failsafe, we better enable those overlays as well:

G_CONFIG_INJECT 'dtparam=i2c_arm=' 'dtparam=i2c_arm=on' /DietPi/config.txt
G_CONFIG_INJECT 'dtparam=spi=' 'dtparam=spi=on' /DietPi/config.txt
G_CONFIG_INJECT 'enable_uart=' 'enable_uart=1' /DietPi/config.txt

EDIT

This one: http://www.lcdwiki.com/zh/3.5inch_RPi_Display ?
I see an SPI in one table, so the second command above should be sufficient.

[SteveJohnsson]

Hi @MichaIng!

I have tested your solution and it worked a charm! The only "issue" I found with this setup is that the font that is sent to the LCD is quite small. It is not a big issue however.

BIG thanks for quick response and the help you provided mate! :)

[MichaIng]

@SteveJohnsson
Thanks for feedback. Did you check which interface is actually required, I²C, SPI and/or UART?

I reopen this issue as a request to add this LCD to our dietpi-config selection.

[SteveJohnsson]

Hi @MichaIng!

Sorry for the late response.

As there are no mention about I2C or UART, so I guess it is the SPI interface. Unfortunately, there is no documentation that comes with the display either.

[MichaIng]

@SteveJohnsson
If you want you can test it:

sed -i '/dtparam=i2c_arm=/d' /DietPi/config.txt
sed -i '/enable_uart=/d' /DietPi/config.txt

Then reboot and see if the display still works.

[rzmichel]

Hi @MichaIng

If you want you can test it:

sed -i '/dtparam=i2c_arm=/d' /DietPi/config.txt
sed -i '/enable_uart=/d' /DietPi/config.txt

Then reboot and see if the display still works.

I did try it on fresh install image. And the unit working until displaying (ask to hit return for login) same as without that two command.

I follow every step from your guidance in this thread. With some modification because of the changed source file or uncompleted path:

cp usr/99-calibration.conf-35 /etc/X11/xorg.conf.d/99-calibration.conf
I changed to
cp usr/**99-calibration.conf-35-0** /etc/X11/xorg.conf.d/99-calibration.conf

mv cmdline_new.txt cmdline.txt
changed to
mv /boot/cmdline_new.txt /boot/cmdline.txt
(this one because I did inside /tmp/LCD-show-master path)

execute dtoverlay tft35a
with result
DTOVERLAY[error]: Failed to open '/boot/overlays/tft35a.dtbo'

• Failed to read '/boot/overlays/tft35a.dtbo'

But yes... the console running replacing white screen

sorry for my lack knowledge, I just master on following step :-)

on device github page, I found this page showed some info for other raspberry image.
http://www.lcdwiki.com/3.5inch_RPi_Display

But yes, I still prefer using DietPi
Thank you for DietPi.

[MichaIng]

@rzmichel
I just updated my steps above by going through the script again which contains some changes: https://github.com/goodtft/LCD-show/blob/master/LCD35-show

• Somehow it contains now enabling everything: SPI, I2C, forced HDMI, UART
• It uses the 99-calibration.conf-35-90 file and adds the dtoverlay with :rotate=90 as well. Not sure whether this is wanted or not 😉, simply landscape vs portrait format?
• > mv /boot/cmdline_new.txt /boot/cmdline.txt
  
  
  
  • Good spot, makes sense 👍.
  
  

Checking your error and re-checking the script, this actually seems strange to me:

https://github.com/goodtft/LCD-show/blob/master/LCD35-show#L12

cp ./usr/tft35a-overlay.dtb /boot/overlays/
cp ./usr/tft35a-overlay.dtb /boot/overlays/tft35a.dtbo

The .dtb file is first copied over as dtb, which like this AFAIK is completely unused like this. Then is is again copied but but changed name + file type. AFAIK dtb and dtbo are quite similar, but dtbo (overlays) are meant to be leaded to runtime as well while dtb are not. This is maybe the reason why "dtoverlay tft35a" command fails. But I am not sure how to verify if the overlay has been loaded successfully on boot (via config.txt entry) since AFAIK they can fail silently, at least outside of usual boot logs.

However if it is finally working, it seems to works, then obviously it worked, hence dtoverlay tft35a should be simply skipped/its error ignored.

[rzmichel]

Hi @MichaIng
Thank you for the update.

From the guidance above, TFT LCD 3.5" is working on console mode. But not on KIOSK mode or whatever Desktop application. Xorg showed me no screen found(EE)

First I want to fill information what I use on this thread.

G_DIETPI_VERSION_CORE=6
G_DIETPI_VERSION_SUB=26
G_DIETPI_VERSION_RC=3
G_GITBRANCH='master'
G_GITOWNER='MichaIng'
G_DISTRO_NAME='buster'
kernel=#1270 SMP Tue Sep 24 18:45:11 BST 2019
device=RPi 3 Model B (armv7l)

After fresh install, software installed is:

SSH Server=OpenSSH
Desktop=Chromium
TextEditor=Vim
Hardware Project= Node-Red
and screen

I using 3.5inch TFT LCD attached on RPi 3 Model B
During installation, TFT showing white screen. To make it work, is about to copy driver on the correct place and tweak configuration file.

Follow the guidance
after reboot, TFT screen showing the console process.
after login, execute dietpi-autostart and choose option 11, running Chromium without Desktop.

edit resolution screen for chromium option on /Dietpi/dietpi.txt
SOFTWARE_CHROMIUM_RES_X=480
SOFTWARE_CHROMIUM_RES_Y=320
otherwise the display will showing default on 1280x720 resolution.

If we reboot now, the display will showing console process and failed to start Desktop.
Xorg will showing no screen found(EE) as I mentioned previously.

I found the solution on this post.
Add the solution to /etc/X11/xorg.conf.d/99-calibration.conf
and reboot

Display and touch WORKING! finally.
but.. need calibration for placing the touch... I'm not found yet the way to calibrate..
at least I know the display working properly.
Thank you

[MichaIng]

@rzmichel
If I get it right, 99-calibration.conf is for the touchscreen: https://github.com/goodtft/LCD-show/blob/master/usr/99-calibration.conf-32-90
Option "Calibration" "3700 115 155 3865"+ "SwapAxes" is what you need to play around to have the touch input and screen output match. There also seems to be a tool, that is hosted on "goodtft" but not part of the script:

apt install xinput-calibrator
xinput_calibrator

The solution you found makes sense. The script installs the fbturbo driver with Allwinner identifier: https://github.com/goodtft/LCD-show/blob/master/usr/99-fbturbo.conf
I was already thinking that this most likely does not work on RPi. But then again Option "fbdev" 🤔.
The xorg.conf you linked uses fbdev driver with fbdev options, which looks correct to me, especially for RPi. Just to reference here:

Section "Device"
# WaveShare SpotPear 3.5", framebuffer 1
Identifier "uga"
driver "fbdev"
Option "fbdev" "/dev/fb1"
Option "ShadowFB" "off"
EndSection

Section "Monitor"
# Primary monitor. WaveShare SpotPear 480x320
Identifier "WSSP"
EndSection

Section "Screen"
Identifier "primary"
Device "uga"
Monitor "WSSP"
EndSection

Section "ServerLayout"
Identifier "default"
Screen 0 "primary" 0 0
EndSection

Also to link the actual source which contains some other differences: https://www.raspberrypi.org/forums/viewtopic.php?p=712958#p712958

Btw the thread again verifies that it is an SPI display, hence the three /DietPi/config.txt entries:

dtparam=i2c_arm=on
enable_uart=1
hdmi_force_hotplug=1

are not required.

Btw, what I was not understanding from the beginning... Are these drivers for a specific display or generic for many similar SPI display, as the thread above obviously was about WaveShare SpotPear. There is a build-in overlay on RPi:

Name:   pitft35-resistive

Info:   Adafruit PiTFT 3.5" resistive touch screen

Usage:  dtoverlay=pitft35-resistive,<param>=<val>

Params: speed                   Display SPI bus speed

        rotate                  Display rotation {0,90,180,270}

        fps                     Delay between frame updates

        debug                   Debug output level {0-7}

• Same resolution, SPI, could be tested at least instead of dtoverlay=tft35a.

[rzmichel]

Hello,

I did comparing fresh install latest image between dietpi and raspbian lite with desktop.
On raspbian lite with desktop, after running script for the driver from https://github.com/goodtft/LCD-show/ device running well with no issue. No calibration needed.

I continue checking on installed file.
Below files is identical

/usr/share/X11/xorg.conf.d/99-fbturbo.conf
/boot/overlays/tft35a.dtbo
/boot/overlays/tft35a-overlay.dtb

The rest files have some difference.
Inside file config.txt (on DietPi, file on /boot and /Dietpi is identical):

# DietPi having additional 14 configuration:
hdmi_force_hotplug=1
disable_overscan=1
display_hdmi_rotate=0
lcd_rotate=0
disable_camera_led=0
gpu_mem_256=128
gpu_mem_512=128
gpu_mem_1024=128
max_usb_current=1
disable_splash=1
dtparam=audio=on
dtparam=i2c_arm=on
dtparam=i2c1=off
dtparam=spi=on
enable_uart=1
temp_limit=75
initial_turbo=20
force_turbo=0
dtoverlay=disable-bt
dtoverlay=tft35a:rotate=270

# Raspbian only 6 configuration:
dtparam=audio=on
hdmi_force_hotplug=1
dtparam=i2c_arm=on
dtparam=spi=on
enable_uart=1
dtoverlay=tft35a:rotate=270

At file cmdline.txt:

# DietPi `dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=cb7b86f7-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait fbcon=map:10 fbcon=font:ProFont6x11`
# Raspbian `dwc_otg.lpm_enable=0 console=tty1 console=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait fbcon=map:10 fbcon=font:ProFont6x11 logo.nologo`

At file /etc/X11/xorg.conf.d/99-calibration.conf
The different only on Option Calibration value.

# DietPi is "3936 227 268 3880" 
# Raspbian Lite is "227 3936 3880 268"

Tried to put same value configuration, DietPi still stop starting Desktop. After add configuration fbdev driver above, it's start desktop but with wrong match of touch and screen input still.

Are these drivers for a specific display or generic for many similar SPI display, as the thread above obviously was about WaveShare SpotPear.

The display coming with no manual paper, inside box with bubble warp and the plastic stylus. I got the info for installing driver on description product. From the market place, they had SPI and HDMI choice of display with various size. The display with me is SPI 3.5" coming without any brand. Just chipset code (maybe), XPT2046

I just curious, how come DietPi need option fbdev when on Raspbian don't.

[MichaIng]

@rzmichel
Thanks for your comparison details.

From cmdline.txt and 99-calibration.conf content it looks like you used a slightly different script than I used as basis. Which script did you run?

• cmdline.txt contains logo.nologo, this only hides the raspberries at the top of boot screen.
• DietPi config.txt contains some rotation related entries, which you could try to comment. Rotation "0" should be default, however probably this conflicts with the overlay and/or xorg.conf settings.
• 99-calibration.conf simply is 90° rotated between DietPi and Raspbian. If on Raspbian this is the correct rotation to have screen output and touch input align correctly, then this is obviously the output rotation you use: https://github.com/goodtft/LCD-show/blob/master/usr/99-calibration.conf-35-270

[rzmichel]

Hi @MichaIng

First sorry not responded in time.
Always glad reading your reply. You put some explanation for the "what's going on" 😍

Actually I follow step on this thread, combine with what I found and what I need for the device.
Final result is device is running as I expected. THANK YOU!

I did rotate the device since the power port is on the bottom of display when following default configuration walk through.

Below is my final configuration on the device (DietPi on RPi3 with 3.5" TFT LCD) :
/usr/share/X11/xorg.conf.d/99-fbturbo.conf

Section "Device"
        Identifier      "Allwinner A10/A13/A20 FBDEV"
        Driver          "fbturbo"
        Option          "fbdev" "/dev/fb1"

        Option          "SwapbuffersWait" "true"

/boot/config.txt = /DietPi/config.txt

hdmi_force_hotplug=1
disable_overscan=1
display_hdmi_rotate=0
lcd_rotate=0
disable_camera_led=0
gpu_mem_256=128
gpu_mem_512=128
gpu_mem_1024=128
max_usb_current=1
disable_splash=1
dtparam=audio=on
dtparam=i2c_arm=on
dtparam=i2c1=off
dtparam=spi=on
enable_uart=1
temp_limit=75
force_turbo=0
dtoverlay=disable-bt
dtoverlay=tft35a:rotate=270

/boot/cmdline.txt

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=cb7b86f7-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait console=ttyAMA0,115200 fbcon=map:10 fbcon=font:ProFont6x11

/etc/X11/xorg.conf.d/99-calibration.conf
Touchscreen is correct now. I copied the Calibration option same as Raspbian after rotating.

Section "InputClass"
        Identifier      "calibration"
        MatchProduct    "ADS7846 Touchscreen"  
    Option  "Calibration"   "227 3936 3880 268"
    Option  "SwapAxes"      "1"
EndSection

Section "Device"
    # WaveShare SpotPear 3.5", framebuffer 1
    Identifier "uga"
    driver "fbdev"
    Option "fbdev" "/dev/fb1"
    Option "ShadowFB" "off"
    EndSection
    #
Section "Monitor"
    # # Primary monitor. WaveShare SpotPear 480x320
    Identifier "WSSP"
    EndSection
    #
Section "Screen"
    Identifier "primary"
    Device "uga"
    Monitor "WSSP"
    EndSection
    #
Section "ServerLayout"
    Identifier "default"
    Screen 0 "primary" 0 0
    EndSection

That's all. It's running well. But start up takes some time than Raspbian Lite with Desktop image.
But I'll live with it since love too much to DietPi 😂

[MichaIng]

@rzmichel
Glad it finally worked. Note that you currently have two conflicting xorg sections in theory:

        Identifier      "Allwinner A10/A13/A20 FBDEV"
        Driver          "fbturbo"
        Option          "fbdev" "/dev/fb1"

and

    Identifier "uga"
    driver "fbdev"
    Option "fbdev" "/dev/fb1"

Two configs attached to the same framebuffer device fb1. Not sure how this is solved, I guess due to alphabetical order one overwrites the other, hence one should be without effect.
Or: Device "uga" in the screen section leads to the "uga" device taking priority. Not sure about details there 😉. My guess is that 99-fbturbo.conf is useless here, also since it looks wired with fbturbo driver but fbdev option, this does not fit together... But I am no expert.

[rzmichel]

I did try comment in one by one:

        Identifier      "Allwinner A10/A13/A20 FBDEV"
        Driver          "fbturbo"
        Option          "fbdev" "/dev/fb1"

and

    Identifier "uga"
    driver "fbdev"
    Option "fbdev" "/dev/fb1"

and comment in both.
All gave result Error, giving up.
So stick with this step, second thread comment. Plus add below configuration on /etc/X11/xorg.conf.d/99-calibration.conf

Section "Device"
# WaveShare SpotPear 3.5", framebuffer 1
Identifier "uga"
driver "fbdev"
Option "fbdev" "/dev/fb1"
Option "ShadowFB" "off"
EndSection

Section "Monitor"
# Primary monitor. WaveShare SpotPear 480x320
Identifier "WSSP"
EndSection

Section "Screen"
Identifier "primary"
Device "uga"
Monitor "WSSP"
EndSection

Section "ServerLayout"
Identifier "default"
Screen 0 "primary" 0 0
EndSection

Screen and touch input will running.
Just do calibration if you rotating the screen.

[MichaIng]

@rzmichel
Okay thanks for testing. Commenting the "uga" device of course causes an error since this is used by the "Screen" section 😉. However good to know that the fbturbo device is required as well, for some reason.

[ilyasst]

Hello hello :)

I got a "MHS35" LCD screen from the https://github.com/goodtft/LCD-show repository, this one here http://www.lcdwiki.com/MHS-3.5inch_RPi_Display. I was wondering if the LCD35 was eventually added to dietpi-config ?
Might be able to rely on that to make the MHS35 work too.

Scripts for Ubuntu, Raspbian and Kali Linux are available, but for a Raspberry Pi, I also still prefer using DietPi
Thank you for DietPi.