How to enable 7inch LCD on Pine64

Troubleshooting
1

I seem can’t enable the LCD with touch screen on my Pine A64 (both are from their first Kickstarter run) running DietPi latest 9.9.0 version. It worked without problem on Armbian (just adding pine64_lcd=on to configEnv.txt and gt9xxf_ts to /etc/modules), but this seem not working in DietPi. Any advise?

2

What exactly have you tried?

3

Hi @Jappe , thanks for your response.
In no particular order and with different combinations here are what I’ve tried:

  • added pine_lcd=on to dietpiEnv.txt
  • added gt9xxf_ts to /etc/modules (this should be a touchscreen driver?)
  • overlays=sun50i-a64-pine64-7inch-lcd.dtbo in dietpiEnv.txt, with and without dtbo at the end
  • dtoverlay=sun50i-a64-pine64-7inch-lcd.dtbo in ditepiEnv, with and without dtbo at the end

For the two last: I’ve found the sun50i-a64-pine64-7inch-lcd.dtbo file under /boot/dtb-6.6.44-current-sunxi64/allwinner/overlay folder - should I copy it somewhere?..

4

I try to add pine_lcd=on on dietpiEnv.txt but nothing happens, insert the module @ngmacha write in reply but nothing. Do you have some news because I need to configure this on 3 pine.

5

Were you able to make it work? I am still struggling, nothing works…

6

@MichaIng has maybe an idea

7

Probably this was working with the vendor kernel images from PINE64 themselves. Please carefully revert everything you tried, also remove gt9xxf_ts from /etc/modules.

On Armbian and DietPi, there is a device tree overlay for this indeed, here is how to enable them in general:

  • Find the overlay /boot/dtb/allwinner/overlay/sun50i-a64-pine64-7inch-lcd.dtbo, and generally overlays in this directory.
  • On PINE A64, in /boot/dietpiEnv.txt, you will find overlay_prefix=sun50i-a64, which means that you can use overlays whose file names start with this prefix.
  • Add them to the overlays= line, which exists already, without the prefix, and without the file extension. In this case:
    overlays=pine64-7inch-lcd
    Multiple overlays can be added, separated by space, no comma, no quotation or anything.

Generally, to check whether a driver even exists, use modinfo, in this case:

modinfo gt9xxf_ts

It will probably tell you that it could not be found, since it is a vendor kernel module. In any case, even if it does exist, it is almost never needed to manually load kernel modules/drivers: the device tree, including overlays you may have added, imply this. They contain nodes for each device, which contain compatible properties like in this case compatible = "goodix,gt911"; in the node for the touchscreen, and compatible = "feiyang,fy07024di26a30d"; in the one for the LCD. Those tell the kernel which drivers to load. You can check back with lsmod which one was used in particular.

There is also a backlight node. Hence check back dietpi-config > display options > brightness where you should be able to control the backlight panel brightness of the LCD.

8

Hello @MichaIng

I was looking for the solution, unsuccessfully, for so long, that the display has been removed and thrown to the drawer long time ago. Yesterday I’ve taken it out and tried to strap to the Pine running my Home Assistant, unfortunately it slipped out of my hand, tearing off the flex-connector :frowning: (from the very beginning the way to connect this LCD felt very flimsy and not reliable).
Sadly, this was the only LCD I have left, I can’t know now if your solution works. Maybe @HL3D may test and let us know… But I can confirm that lsmod shows two drivers loaded:

panel_feyyang_fy07024di26a30d

and

goodix_ts

The bright side of all this is now I have no reason not to run DietPi on my Pines!!
Anyway, thank you very much!!

9

I am sorry to hear that. I hope there was nothing important you used the LCD for.

10

Hi @ngmacha Just curious as I have the same issue. Picked up my Kickstarter Pine64+display and installed DietPi to discover that it shuts down as soon I connect the DSI cable.

Is that what you experienced as well?
Happy to get any hint or advice to get it running with HA and Octoprint with a touch display!!

11

Hi I seem to have the same issue. If I have HDMI and the LCD connected at the same time it randomly reboots. It shouldn’t be a power issue as I’ve got it connected through the pins on the Euler bus directly to a regulated PSU.

The DSI-1 display is detected by the kernel and Xserver and if I disconnect the HDMI I can start the X server using an SSH connection but there is no picture on the LCD. Not in the console or when the X server starts.

What else could I check?

12

Maybe persistent system logging can reveal what is going on right before the reboot:

dietpi-software uninstall 103
mkdir /var/log/journal
reboot

After that reboot, the system journal logs to /var/log/journal which is no tmpfs anymore then, hence journalctl content then survives reboots.

If wanted for long-term, it makes sense to reduce the amount of kept logs, like 2 files a 7 days, i.e. 7-14 days of logs at any time:

mkdir -p /etc/systemd/journald.conf.d
cat << '_EOF_' > /etc/systemd/journald.conf.d/99-custom.conf
[Journal]
SystemMaxFiles=2
MaxFileSec=7day
_EOF_

Or to revert:

systemctl stop systemd-journald
rm -R /var/log/journal
dietpi-software install 103
13

Thanks for the info about logging. I tried setting it to persistent but not much sensible output was saved. I then tried running a journalctl -f in an ssh session and the last lines before a reboot are:

Oct 02 01:47:11 DietPi systemd[687]: Reached target default.target - Main User Target.
Oct 02 01:47:11 DietPi systemd[687]: Startup finished in 1.565s.
Oct 02 01:47:14 DietPi dbus-daemon[710]: [session uid=1000 pid=710 pidfd=5] Activating via systemd: service name=‘org.xfce.Xfconf’ unit=‘xfconfd.service’ requested by ‘:1.6’ (uid=1000 pid=738 comm=“/usr/bin/xfwm4”)
Oct 02 01:47:14 DietPi systemd[687]: Starting xfconfd.service - Xfce configuration service…
Oct 02 01:47:14 DietPi dbus-daemon[710]: [session uid=1000 pid=710 pidfd=5] Successfully activated service ‘org.xfce.Xfconf’
Oct 02 01:47:14 DietPi systemd[687]: Started xfconfd.service - Xfce configuration service.

I kept an eye on the temperature and it doen’t seem to be an overheating issue. This issue only seems to happen if I have both the HDMI and DSI screens connected and is not really a deal-breaker for my use case.

The greatest issue I have is that the DSI screen never shows anything. The backlight adjustments work fine, but no matter what the setting is I can’t get it to display anything. I’ve tried starting X11 and I’ve compiled a framebuffer test utility which works on the HDMI output but does nothing on DSI.

Is there a way to test if the display is working at all or I should just forget about it?

14

Hmm, the journalctl -f output only shows the X11 related unit starts, nothing from any crash. I guess those messages where already there (or timestamps are from) long before the crash, right? In journalctl there should be boot session separator lines like

-- boot bd0f37aef0124f0d86241d0eb50d662c

or similar with a respective boot ID, so you know which ones belong to the session from before the crash and which ones to the next boot. But possible that the crash happens to abruptly that no related log entry is done.

Generally, the Linux console as well as X11 choose one screen, and it makes sense that they use the HDMI screen if there is one, so one needs to configure TTY to framebuffer mapping and tell X11 to use another display respectively. Do both HDMI and DSI display have respective framebuffer device nodes?

ls -l /dev/fb*

And do both provide a DRM interface?

ls -l /sys/class/drm
15

Actually they are from the moment of the crash as the system was in multi-user.target and I started X11 with “startx" moments before. I do check between boot tags to be sure not to confuse with previous boots.

When both displays are connected there is on fb device and both drm interfaces:

root@DietPi:~# ls -l /dev/fb*

crw-rw---- 1 root video 29, 0 Oct 2 01:44 /dev/fb0

root@DietPi:~# ls -l /sys/class/drm/
total 0
lrwxrwxrwx 1 root root 0 Jan 1 1970 card0 → ../../devices/platform/display-engine/drm/card0
lrwxrwxrwx 1 root root 0 Jan 1 1970 card0-DSI-1 → ../../devices/platform/display-engine/drm/card0/card0-DSI-1
lrwxrwxrwx 1 root root 0 Jan 1 1970 card0-HDMI-A-1 → ../../devices/platform/display-engine/drm/card0/card0-HDMI-A-1
lrwxrwxrwx 1 root root 0 Oct 2 22:04 card1 → ../../devices/platform/soc/1c40000.gpu/drm/card1
lrwxrwxrwx 1 root root 0 Oct 2 22:05 renderD128 → ../../devices/platform/soc/1c40000.gpu/drm/renderD128
-r–r–r-- 1 root root 4096 Oct 2 22:06 version

With this configuration if I start the system in graphical.target I get a login prompt on the HDMI screen. After I login and the desktop starts loading the system reboots without a warning. Sometimes it can’t boot without a power cycle.

Sometimes I can boot into multi-user.target and start an LXQt session which somewhat works if the HDMI is set as the extended secondary display and DSI as primary (it however still displays nothing). If I use lxqt-config-monitor to change the primary monitor and positions the system again reboots.

The reboots are abrupt (I can see the supply current going to 0A for a moment) and after every start the fs needs to replay the journal.

I’m starting to think this is either a HW issue, while a driver for the DSI screen could be the culprit I suspect at least a kernel panic could be recorded from time to time.

16

Btw, did you add the device tree overlay?

G_CONFIG_INJECT 'overlays=' 'overlays=pine64-7inch-lcd' /boot/dietpiEnv.txt

And the check whether it has been loaded:

ls -l /proc/device-tree/backlight

Any other primary/secondary screen setup via lxqt-config-monitor does not work? The default was HDMI only as primary and DSI not used, I guess? That did work without reboot?

Seems like X11 has some issues with the display, or maybe just LXQt?

Few things to test whether the DSI alone works at all for console output and/or X11 output:

  1. In case disable desktop autostart: dietpi-autostart 0
  2. Detach the HDMI screen or disable it via dietpi-display
  3. Reboot and check whether the plain Linux console shows up on the DSI display then. Also check whether in this case there is still a /dev/fb0 or none at all.
  4. If not, test to start X11, but not the full desktop, just a single application to bypass all possible LXQt setup, e.g. sudo startx /usr/bin/qterminal
  5. If neither console nor X11 displays anything on the DSI, is there a list of supported modes/resolutions shown in dietpi-display? Could be also checked with:
    cat /sys/class/drm/card0-DSI-1/modes

Yeah I thought the same. A driver issue can freeze the system would usually throws a kernel panic.

17

Yes, I did add the device overlay and it seems to be loaded:

root@DietPi:~# grep -e ^overlays= /boot/dietpiEnv.txt
overlays=pine64-7inch-lcd
root@DietPi:~# ls -l /proc/device-tree/backlight
total 0
-r--r--r-- 1 root root 36 Oct  4 01:00 brightness-levels
-r--r--r-- 1 root root 14 Oct  4 01:00 compatible
-r--r--r-- 1 root root  4 Oct  4 01:00 default-brightness-level
-r--r--r-- 1 root root 16 Oct  4 01:00 enable-gpios
-r--r--r-- 1 root root 10 Oct  4 01:00 name
-r--r--r-- 1 root root  4 Oct  4 01:00 phandle
-r--r--r-- 1 root root 16 Oct  4 01:00 pwms

If the HDMI is used as a primary monitor it works as expected, but when the DSI is added it causes a reboot.
If however there is only HDMI or DSI connected a reboot does not occur.
When only the DSI is connected no video output is shown on it, neither X11, fb test or console. The only thing that responds is the backlight. I also suspect the touch portion might be working because I can se little power draw changes when in X11 and when I touch the screen.

I’ve performed the steps you suggested:

  1. Disabled autostart - switched to multi-user.target

  2. Physicaly detached HDMI.

  3. The linux console doesn’t show up, only the backlight turns on, there is a /dev/fb0 device.

  4. I’ve started the qterminal as suggested, the process runs and Xorg.0.log shows no errors. The screen remains blank/black.

  5. I’ve checked for the supported resolution and the only one (1024x600) is already set in dietpi-display and in the dietpiEnv.txt:

    extraargs=net.ifnames=0 video=DSI-1:1024x600 video=HDMI-A-1:1920x1200

So I guess there are two issues, one where the SBC reboots if both screens are used and the other one where the DSI screen just doesn’t seem to show anything.

I thought there might be an issue with the cable connection to the screen, but if I had connected it wrong it probably wouldn’t have been detected at all.

18

One thing I recognized in the device tree overlay: the default brightness level is very low, or at least it appears to be, although the levels are given in powers of two and must probably not be interpreted as linear integers:

Just to rule it out, did you try to raise/max out the brightness?