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?
What exactly have you tried?
Hi @Jappe , thanks for your response.
In no particular order and with different combinations here are what I’ve tried:
- added
pine_lcd=onto dietpiEnv.txt - added
gt9xxf_tsto /etc/modules (this should be a touchscreen driver?) overlays=sun50i-a64-pine64-7inch-lcd.dtboin dietpiEnv.txt, with and without dtbo at the enddtoverlay=sun50i-a64-pine64-7inch-lcd.dtboin 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?..
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.
Were you able to make it work? I am still struggling, nothing works…
@MichaIng has maybe an idea
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 findoverlay_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:
Multiple overlays can be added, separated by space, no comma, no quotation or anything.overlays=pine64-7inch-lcd
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.
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 
(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!!
I am sorry to hear that. I hope there was nothing important you used the LCD for.
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!!
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?
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
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?
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
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.
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:
- In case disable desktop autostart:
dietpi-autostart 0 - Detach the HDMI screen or disable it via
dietpi-display - 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/fb0or none at all. - 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 - 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.
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:
-
Disabled autostart - switched to multi-user.target
-
Physicaly detached HDMI.
-
The linux console doesn’t show up, only the backlight turns on, there is a /dev/fb0 device.
-
I’ve started the qterminal as suggested, the process runs and Xorg.0.log shows no errors. The screen remains blank/black.
-
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.
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?
Yes, I tried changing the brightness of the backlight and I can see the change even if I set it from the dietpi-config to various levels. The screen however remains blank at all times.
So if anyone at all wants to have a go at it I’ll donate the SBC and screen to anyone that drops me a DM. 
Hi,
Sorry to hijack an existing thread, but I think this is a generic, uboot issue that is hitting at least some allwinner boards, and is related to ROCK(Pro)64 won't boot with Linux 6.12
Some history:
I’m new to the forum, having just migrated to DietPi from Armbian on a Pine64+ (A64 2GB).
The board has been running Armbian since 2017, first on the original “longsleep” kernel, then from 2021 on mainline (Ubuntu Focal), using a reduced footprint. I have been using it as a dedicated squeezebox touch replacement, running squeezelite and jivelite, with fb output to the lcd touchscreen. ref: Pine64 as squeezebox touch replacement
This was working fine, with regular apt updates until some time after kernel v. 6.x broke the display and some other bits of the squeezelite implementation, which I didn’t investigate.
The device did continue to boot, so I tried sporadic updates, hoping they might fix the issue, until last week.
I tried various Armbian releases, and found that somewhere between around 6.6.x and 6.12.x, the 7” lcd goes blank and there are other weird issues including network connectivity and DHCP problems. The latest Arbmian releases and updates also fail to load the 7" screen overlay, no matter what armbianEnv settings I tried. So I found DietPi and can successfully load the dtbo.
Status is that the lcd monitor is picked up at boot, and the backlight works and can be controlled, but neither console, nor random output to /dev/fb0 will display anything.
# dmesg | grep dsi
\[ 0.046701\] /soc/lcd-controller@1c0c000: Fixed dependency cycle(s) with /soc/dsi@1ca0000
\[ 0.047496\] /soc/dsi@1ca0000: Fixed dependency cycle(s) with /soc/lcd-controller@1c0c000
\[ 0.049015\] /soc/lcd-controller@1c0c000: Fixed dependency cycle(s) with /soc/dsi@1ca0000
\[ 0.055945\] /soc/lcd-controller@1c0c000: Fixed dependency cycle(s) with /soc/dsi@1ca0000
\[ 0.056092\] /soc/dsi@1ca0000: Fixed dependency cycle(s) with /soc/lcd-controller@1c0c000
\[ 2.299473\] sun4i-drm display-engine: bound 1ca0000.dsi (ops 0xffff8000811eaaa0)
\[ 9.540165\] sun6i-mipi-dsi 1ca0000.dsi: Attached device fy07024di26a30d
ls /proc/device-tree
‘#address-cells’ aliases compatible hdmi-connector model opp-table-gpu pmu soc thermal-zones
‘#size-cells’ backlight cpus interrupt-parent name osc24M-clk psci sound timer
**symbols** chosen display-engine memory opp-table-cpu osc32k-clk serial-number sound_hdmi wifi_pwrseq
lsmod
Module Size Used by
hci_uart 139264 0
btqca 24576 1 hci_uart
btrtl 28672 1 hci_uart
snd_usb_audio 344064 0
btintel 53248 1 hci_uart
snd_hwdep 16384 1 snd_usb_audio
snd_soc_hdmi_codec 20480 1
axp20x_adc 24576 0
snd_usbmidi_lib 36864 1 snd_usb_audio
r8723bs 487424 0
joydev 28672 0
btbcm 16384 1 hci_uart
polyval_ce 12288 0
snd_rawmidi 40960 1 snd_usbmidi_lib
snd_soc_simple_card 20480 0
bluetooth 737280 6 btrtl,btqca,btintel,hci_uart,btbcm
snd_seq_device 12288 1 snd_rawmidi
snd_soc_simple_card_utils 24576 1 snd_soc_simple_card
polyval_generic 12288 1 polyval_ce
sun9i_hdmi_audio 12288 0
cfg80211 847872 1 r8723bs
ecdh_generic 12288 1 bluetooth
sunxi_cedrus 49152 0
ecc 32768 1 ecdh_generic
dw_hdmi_i2s_audio 12288 0
dw_hdmi_cec 12288 0
lima 65536 0
v4l2_mem2mem 28672 1 sunxi_cedrus
panel_feiyang_fy07024di26a30d 12288 0
rfkill 28672 3 bluetooth,cfg80211
goodix_ts 28672 0
gpu_sched 49152 1 lima
videobuf2_dma_contig 20480 1 sunxi_cedrus
drm_shmem_helper 24576 1 lima
videobuf2_memops 16384 1 videobuf2_dma_contig
videobuf2_v4l2 20480 2 sunxi_cedrus,v4l2_mem2mem
sun4i_i2s 20480 4
libarc4 12288 1 r8723bs
videodev 253952 3 sunxi_cedrus,videobuf2_v4l2,v4l2_mem2mem
videobuf2_common 53248 5 sunxi_cedrus,videobuf2_dma_contig,videobuf2_v4l2,v4l2_mem2mem,videobuf2_memops
mc 53248 6 sunxi_cedrus,videodev,snd_usb_audio,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem
display_connector 16384 0
cpufreq_dt 16384 0
fuse 155648 1
nfnetlink 16384 1
ip_tables 28672 0
axp20x_ac_power 12288 0
axp20x_battery 16384 0
industrialio 86016 3 axp20x_battery,axp20x_ac_power,axp20x_adc
pinctrl_axp209 12288 0
pwm_sun4i 12288 1
realtek 40960 1
sun8i_a33_mbus 16384 0
dwmac_sun8i 24576 0
mdio_mux 12288 1 dwmac_sun8i
pwm_bl 20480 0
cat /boot/dietpiEnv.txt
rootdev=UUID=3f264847-38ca-436a-9941-7a5fb1b49b4b
rootfstype=ext4
# The init system logs to the console defined last.
consoleargs=console=tty1
extraargs=fsck.repair=yes net.ifnames=0
docker_optimizations=off
overlay_path=allwinner
# Multiple prefixes are supported separated by space
overlay_prefix=sun50i-a64
overlays=pine64-7inch-lcd
user_overlay
# dmesg | grep console
\[ 0.000000\] Kernel command line: root=UUID=3f264847-38ca-436a-9941-7a5fb1b49b4b rootfstype=ext4 rootwait console=tty1 consoleblank=0 coherent_pool=2M ubootpart=16714d40-01 fsck.repair=yes net.ifnames=0
\[ 0.000993\] printk: legacy console \[tty1\] enabled
\[ 6.315213\] systemd\[1\]: Started systemd-ask-password-console.path - Dispatch Password Requests to Console Directory Watch.
\[ 6.408450\] systemd\[1\]: Starting keyboard-setup.service - Set the console keyboard layout…
root@Squeezebox:\~# dmesg | grep tty
\[ 0.000000\] Kernel command line: root=UUID=3f264847-38ca-436a-9941-7a5fb1b49b4b rootfstype=ext4 rootwait console=tty1 consoleblank=0 coherent_pool=2M ubootpart=16714d40-01 fsck.repair=yes net.ifnames=0
\[ 0.000993\] printk: legacy console \[tty1\] enabled
\[ 1.886997\] 1c28000.serial: ttyS0 at MMIO 0x1c28000 (irq = 155, base_baud = 1500000) is a 16550A
\[ 1.888996\] 1c28400.serial: ttyS1 at MMIO 0x1c28400 (irq = 156, base_baud = 1500000) is a 16550A
\[ 1.889257\] serial serial0: tty port ttyS1 registered
\[ 6.310995\] systemd\[1\]: Created slice system-getty.slice - Slice /system/getty.
# dmesg | grep display
\[ 2.296544\] sun4i-drm display-engine: bound 1100000.mixer (ops 0xffff8000811ebfc8)
\[ 2.298400\] sun4i-drm display-engine: bound 1200000.mixer (ops 0xffff8000811ebfc8)
\[ 2.299033\] sun4i-drm display-engine: No panel or bridge found… RGB output disabled
\[ 2.299063\] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops 0xffff8000811e8be8)
\[ 2.299416\] sun4i-drm display-engine: bound 1c0d000.lcd-controller (ops 0xffff8000811e8be8)
\[ 2.299473\] sun4i-drm display-engine: bound 1ca0000.dsi (ops 0xffff8000811eaaa0)
\[ 2.301772\] sun4i-drm display-engine: bound 1ee0000.hdmi (ops 0xffff8000811eb090)
\[ 2.302754\] \[drm\] Initialized sun4i-drm 1.0.0 for display-engine on minor 0
\[ 2.302867\] sun4i-drm display-engine: \[drm\] Cannot find any crtc or sizes
\[ 2.304974\] sun4i-drm display-engine: \[drm\] Cannot find any crtc or sizes
\[ 9.496709\] sun4i-drm display-engine: \[drm\] fb0: sun4i-drmdrmfb frame buffer device
Unfortunately I don’t have a serial console cable to debug the boot loader process.
If this looks like part of the memory space issue that was discussed in the ROCK(Pro)64 won’t boot with Linux 6.12 thread, was there an experimental uboot patch that I might try for the Pine64?
Update:
More info:
DietPi v9.19.2 : 08:31 - Sat 11/29/25
─────────────────────────────────────────────────────
* Device model : PINE A64 (aarch64)
* CPU temp : 34 °C / 93 °F
I have nothing connected to hdmi, so if this can be completely disabled as part of the debugging process, that would be fine for me
uname -a
Linux Squeezebox 6.12.57-current-sunxi64 #1 SMP Sun Nov 2 13:15:23 UTC 2025 aarch64 GNU/Linux
Powered via the Euler GPIO header