# How to enable 7inch LCD on Pine64 **URL:** \ **Category:** Troubleshooting\ **Created:** [26 December 2024 20:35 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328 "2024-12-26T20:35:15Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![ngmacha](https://dietpi.com/forum/user_avatar/dietpi.com/ngmacha/32/7082_2.png) [@ngmacha](https://dietpi.com/forum/u/ngmacha)\ **Post date:** [26 December 2024 20:35 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328/1 "2024-12-26T20:35:15Z")
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? ---
**Author:** ![Jappe](https://dietpi.com/forum/user_avatar/dietpi.com/jappe/32/1788_2.png) [@Jappe](https://dietpi.com/forum/u/Jappe)\ **Post date:** [27 December 2024 12:25 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328/2 "2024-12-27T12:25:28Z")
What exactly have you tried? ---
**Author:** ![ngmacha](https://dietpi.com/forum/user_avatar/dietpi.com/ngmacha/32/7082_2.png) [@ngmacha](https://dietpi.com/forum/u/ngmacha)\ **Post date:** [30 December 2024 13:32 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328/3 "2024-12-30T13:32:54Z")
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?.. ---
**Author:** ![HL3D](https://dietpi.com/forum/letter_avatar_proxy/v4/letter/h/58f4c7/32.png) [@HL3D](https://dietpi.com/forum/u/HL3D)\ **Post date:** [17 January 2025 13:20 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328/4 "2025-01-17T13:20:21Z")
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. ---
**Author:** ![ngmacha](https://dietpi.com/forum/user_avatar/dietpi.com/ngmacha/32/7082_2.png) [@ngmacha](https://dietpi.com/forum/u/ngmacha)\ **Post date:** [8 July 2025 15:44 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328/5 "2025-07-08T15:44:59Z")
Were you able to make it work? I am still struggling, nothing works… ---
**Author:** ![Jappe](https://dietpi.com/forum/user_avatar/dietpi.com/jappe/32/1788_2.png) [@Jappe](https://dietpi.com/forum/u/Jappe)\ **Post date:** [8 July 2025 19:49 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328/6 "2025-07-08T19:49:20Z")
@MichaIng has maybe an idea ---
**Author:** ![MichaIng](https://dietpi.com/forum/user_avatar/dietpi.com/michaing/32/7_2.png) [@MichaIng](https://dietpi.com/forum/u/MichaIng)\ **Post date:** [8 July 2025 21:07 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328/7 "2025-07-08T21:07:46Z")
> [@ngmacha](#): > > It worked without problem on Armbian (just adding pine64\_lcd=on to configEnv.txt and gt9xxf\_ts to /etc/modules 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: ```ini 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: ```sh 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. ---
**Author:** ![ngmacha](https://dietpi.com/forum/user_avatar/dietpi.com/ngmacha/32/7082_2.png) [@ngmacha](https://dietpi.com/forum/u/ngmacha)\ **Post date:** [9 July 2025 20:07 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328/8 "2025-07-09T20:07:35Z")
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: ```auto panel_feyyang_fy07024di26a30d ``` and ```auto 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!! ---
**Author:** ![MichaIng](https://dietpi.com/forum/user_avatar/dietpi.com/michaing/32/7_2.png) [@MichaIng](https://dietpi.com/forum/u/MichaIng)\ **Post date:** [10 July 2025 15:08 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328/9 "2025-07-10T15:08:24Z")
I am sorry to hear that. I hope there was nothing important you used the LCD for. ---
**Author:** ![micklen](https://dietpi.com/forum/user_avatar/dietpi.com/micklen/32/8165_2.png) [@micklen](https://dietpi.com/forum/u/micklen)\ **Post date:** [11 August 2025 07:51 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328/10 "2025-08-11T07:51:18Z")
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!! ---
**Author:** ![SHadowX](https://dietpi.com/forum/user_avatar/dietpi.com/shadowx/32/8308_2.png) [@SHadowX](https://dietpi.com/forum/u/SHadowX)\ **Post date:** [27 September 2025 14:27 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328/11 "2025-09-27T14:27:59Z")
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? ---
**Author:** ![MichaIng](https://dietpi.com/forum/user_avatar/dietpi.com/michaing/32/7_2.png) [@MichaIng](https://dietpi.com/forum/u/MichaIng)\ **Post date:** [28 September 2025 09:31 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328/12 "2025-09-28T09:31:09Z")
Maybe persistent system logging can reveal what is going on right before the reboot: ```sh 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: ```sh 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: ```sh systemctl stop systemd-journald rm -R /var/log/journal dietpi-software install 103 ``` ---
**Author:** ![SHadowX](https://dietpi.com/forum/user_avatar/dietpi.com/shadowx/32/8308_2.png) [@SHadowX](https://dietpi.com/forum/u/SHadowX)\ **Post date:** [2 October 2025 00:00 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328/13 "2025-10-02T00:00:26Z")
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: ```auto 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? ---
**Author:** ![MichaIng](https://dietpi.com/forum/user_avatar/dietpi.com/michaing/32/7_2.png) [@MichaIng](https://dietpi.com/forum/u/MichaIng)\ **Post date:** [2 October 2025 19:07 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328/14 "2025-10-02T19:07:40Z")
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 ```x -- 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? ```sh ls -l /dev/fb* ``` And do both provide a DRM interface? ```sh ls -l /sys/class/drm ``` ---
**Author:** ![SHadowX](https://dietpi.com/forum/user_avatar/dietpi.com/shadowx/32/8308_2.png) [@SHadowX](https://dietpi.com/forum/u/SHadowX)\ **Post date:** [2 October 2025 20:38 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328/15 "2025-10-02T20:38:17Z")
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. ---
**Author:** ![MichaIng](https://dietpi.com/forum/user_avatar/dietpi.com/michaing/32/7_2.png) [@MichaIng](https://dietpi.com/forum/u/MichaIng)\ **Post date:** [3 October 2025 20:06 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328/16 "2025-10-03T20:06:13Z")
Btw, did you add the device tree overlay? ```sh G_CONFIG_INJECT 'overlays=' 'overlays=pine64-7inch-lcd' /boot/dietpiEnv.txt ``` And the check whether it has been loaded: ```sh 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: ```sh cat /sys/class/drm/card0-DSI-1/modes ``` > [@SHadowX](#): > > 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. Yeah I thought the same. A driver issue can freeze the system would usually throws a kernel panic. ---
**Author:** ![SHadowX](https://dietpi.com/forum/user_avatar/dietpi.com/shadowx/32/8308_2.png) [@SHadowX](https://dietpi.com/forum/u/SHadowX)\ **Post date:** [3 October 2025 23:25 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328/17 "2025-10-03T23:25:34Z")
Yes, I did add the device overlay and it seems to be loaded: ```bash 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: 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. ---
**Author:** ![MichaIng](https://dietpi.com/forum/user_avatar/dietpi.com/michaing/32/7_2.png) [@MichaIng](https://dietpi.com/forum/u/MichaIng)\ **Post date:** [5 October 2025 21:55 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328/18 "2025-10-05T21:55:51Z")
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? ---
**Author:** ![SHadowX](https://dietpi.com/forum/user_avatar/dietpi.com/shadowx/32/8308_2.png) [@SHadowX](https://dietpi.com/forum/u/SHadowX)\ **Post date:** [20 October 2025 14:16 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328/19 "2025-10-20T14:16:40Z")
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. 🙂 ---
**Author:** ![Learnincurve1](https://dietpi.com/forum/letter_avatar_proxy/v4/letter/l/d9b06d/32.png) [@Learnincurve1](https://dietpi.com/forum/u/Learnincurve1)\ **Post date:** [29 November 2025 10:40 UTC](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328/20 "2025-11-29T10:40:10Z")
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](https://dietpi.com/forum/t/rock-pro-64-wont-boot-with-linux-6-12/23426) 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](https://forum.pine64.org/showthread.php?tid=3482) 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. ```auto # 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 ``` * * * ```auto 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 ``` * * * ```auto 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 ``` ```auto 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 ``` ```auto # 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… ``` ```auto 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. ``` ```auto # 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: ```auto 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 ```auto 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 [Next page](https://dietpi.com/forum/t/how-to-enable-7inch-lcd-on-pine64/22328.md?page=2)