Active threads

With modifications to lightdm.conf I got lightdm working with your tutorial, however lightdm and labwc don't seem to use the SPI display. I verified the setup works on an HDMI screen (with some weird artifacts on the right quarter side but thats a later problem). Do i need to specify lightdm / labwc to use the /sys/class/drm/card0-SPI-1? The only difference between your guide and my setup is I am running kernel 6.18, as I can't seem to find how to compile or install kernel 6.13. I only have 6.12, 6.14, and 6.18 available to install, and can only compile current and edge (6.12 and 6.18), but the compile script failed with a not found error when I attempted to specify 6.13. Not sure if that is relavent, since my setup seems to be working otherwise.

Thank you very much for your reply. That's exactly what I did. I have a custom Armbian image. When compiling, I selected my board for the 618 processor, as I couldn't find it in the standard section. I also found the panel-mipi-dbi parameter in the module selection menu. However, after compiling, writing the image to the flash card, and checking the module, the system didn't find it. I was able to build the image and include the module after correcting the boardconfig. It may have mistakenly listed the 616 processor, but I changed it to 618, and the image built successfully. After writing it to a flash drive and checking it in the system, I was finally able to find the required module. It was also displayed in the /boot/config(uname) configuration file.

Update: I was right, it is an allwinner system U-Boot 2014.07 (Aug 28 2020 - 08:44:29) Allwinner Technology Mali: ERR: /home/work/share/akrd6/custom_relese/H3_ANDROID7.0_BOX_SDK_V1.0_20190702_eng/lichee/linux-4.4/modules/gpu/mali-utgard/kernel_mode/driver/src/devicedrv/mali/linux/mali_platform.c These where the smoking guns that caught my eye, i will likely install Armbian in this anyhow.

I get this on a Debian Trixie VM allocated only 4x Cortex-A76 on ROCK5B 1048576+0 records in 1048576+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.5407 s, 236 MB/s 2097152+0 records in 2097152+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.24198 s, 253 MB/s Numbers are lower on RPi4B and ROCK3A. However, since in-place upgrade from Bookworm to Trixie, this slow ssh login is very noticeable and also rather annoying. So this is a Debian issue as far as I can see. I had the same Debian VM running on ROCK3A and was all nice with Bookworm, although only 1GB allocated and of course is 4x Cortex-A55, so slow for crypto and compression (real-time Zstd). Just after upgrade and reboot into Trixie I spent a lot of time trying to figure out why ssh login was so delayed/slow. Also noticeable that it was random, sometimes it was OK, mostly took multiple seconds. I did strace sshd and I saw just delay, waiting time in the process. More I could not figure out, would take me too much time and I had no clue where to look. The plan was anyway to move the VM (and NVME and HDD, the whole NAS setup) to ROCK5B so that is what I did then the next day or so. On the ROCK5B, I do not notice the delay that much, but it seems still to be there. I have no clue why. I use quite a lot ssh unattended, so that I don't care and notice. So I basically still do not know what this is, I have not searched for It, I just see this topic and I recognise it.

I don't think I forgot anything. I was just curious about the conditions for the current version, since these sentences are relative generic and don't list issues, before I layout the details that I noticed. I flashed the image to a SanDisk Ultra, A1, Class 10 sdcard. System booted fine, but was relative slow which seemed to be related to constant sdcard speed switching issues. The following was constantly going on in the logs. [Wed Dec 3 13:30:34 2025] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) [Wed Dec 3 13:30:34 2025] mmc_host mmc1: Bus speed (slot 0) = 198000000Hz (slot req 200000000Hz, actual 198000000HZ div = 0) [Wed Dec 3 13:30:34 2025] dwmmc_rockchip 2a310000.mmc: Successfully tuned phase to 235 The workaround for this was changing power control from auto to on. Messages stopped after executing the following. cat /sys/devices/platform/soc/2a310000.mmc/power/control auto echo on > /sys/devices/platform/soc/2a310000.mmc/power/control cat /sys/devices/platform/soc/2a310000.mmc/power/control on My permanent workaround was this, to avoid manual intervention after a reboot. # /usr/local/sbin/fix‑sd‑pm.sh #!/bin/sh # Disable runtime PM for SD controller (fixes repeated re-init) echo on > /sys/devices/platform/soc/2a310000.mmc/power/control # /etc/systemd/system/fix-sd-pm.service [Unit] Description=Disable runtime‑PM for SD controller After=multi-user.target [Service] Type=oneshot ExecStart=/usr/local/sbin/fix‑sd‑pm.sh RemainAfterExit=yes [Install] WantedBy=multi-user.target # Enable chmod +x /usr/local/sbin/fix‑sd‑pm.sh systemctl daemon-reload systemctl enable --now fix-sd-pm.service systemctl status fix-sd-pm.service Without the workaround the mmc1 switched between 2 states. root@nanopir76s ~# cat /sys/class/mmc_host/mmc1/mmc1:*/name SD128 root@nanopir76s ~# grep . /sys/kernel/debug/mmc1/ios clock: 400000 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 0 (1 bits) timing spec: 0 (legacy) signal voltage: 0 (3.30 V) driver type: 0 (driver type B) # OR clock: 200000000 Hz actual clock: 198000000 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 2 (4 bits) timing spec: 6 (sd uhs SDR104) signal voltage: 1 (1.80 V) driver type: 0 (driver type B) With the workaround it always showed this and system felt also snappy. root@nanopir76s ~# cat /sys/class/mmc_host/mmc1/mmc1:*/name SD128 root@nanopir76s ~# grep . /sys/kernel/debug/mmc1/ios clock: 200000000 Hz actual clock: 198000000 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 2 (4 bits) timing spec: 6 (sd uhs SDR104) signal voltage: 1 (1.80 V) driver type: 0 (driver type B) root@nanopir76s ~# --- EMMC was visible under Linux. But the emmc problem I noticed is related to u-boot. When I flashed the image to emmc and started from sdcard nothing at all happened. If I boot from sdcard and interrupt the u-boot prompt, the emmc card was not really visible. or accessible. I do not have the full serial output anymore when the Armbian image was flashed to emmc. => mmc list mmc@2a310000: 0 (SD) mmc@2a320000: 2 => # switching to emmc gives this => mmc dev 2 Card did not respond to voltage select! : -110 mmc_init: -95, time 22 => To debug this better, I build my own u-boot and image based on Armbians dts and defconfig. Here is what it looks like when booted from emmc with no sdcard inserted. U-Boot SPL 2026.01-msc-1 (Dec 02 2025 - 23:42:14 +0100) Trying to boot from MMC1 Card did not respond to voltage select! : -110 mmc_init: -95, time 21 spl: mmc init failed with error: -95 Error: -95 SPL: Unsupported Boot Device! SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### I created a patch for the dts, which modifies the sdmmc and sdhci nodes in the dts file. The patch is in my u-boot repo. https://github.com/mschirrmeister/PKGBUILDs/blob/f02af83ae5e0180ae1fd50706624dee348b820d7/core/uboot-rk3576-nanopi-r76s/arm64-dts-rockchip-rk3576-nanopi-r76s-fix-sdmmc-sdhci-coexistence.patch I added also the following Kconfig options to the u-boot defconfig. CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ROCKCHIP=y CONFIG_MMC_HS200_SUPPORT=y CONFIG_MMC_HS400_SUPPORT=y CONFIG_MMC_HS400_ES_SUPPORT=y Here is the raw patch data. From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 From: Marco Schirrmeister <mschirrmeister@gmail.com> Date: Sat, 6 Dec 2025 23:56:46 +0100 Subject: [PATCH] arm64: dts: rockchip: rk3576-nanopi-r76s: fix sdmmc/sdhci coexistence The NanoPi R76S (RK3576) features both a DW‑MMC controller for the microSD socket (sdmmc) and an Arasan SDHCI controller for the on‑board eMMC (sdhci). When both were enabled, the shared I/O voltage rail caused initialisation conflicts: the eMMC required 1.8 V signalling while the SD card logic expected 3.3 V. This patch aligns the DTS and U‑Boot configuration so that both storage controllers operate correctly: - Enable CONFIG_MMC_SDHCI and CONFIG_MMC_SDHCI_ROCKCHIP in U‑Boot. - Add explicit `vmmc-supply` and `vqmmc-supply` properties to the eMMC (sdhci) node. - Add `no-1-8-v;` to the SDMMC node to keep the µSD socket fixed at 3.3 V. With these adjustments the board can access both the microSD and eMMC devices simultaneously, and U‑Boot can boot directly from either medium. Signed-off-by: Marco Schirrmeister <mschirrmeister@gmail.com> --- diff --git a/dts/upstream/src/arm64/rockchip/rk3576-nanopi-r76s.dts b/dts/upstream/src/arm64/rockchip/rk3576-nanopi-r76s.dts index 11111111111..22222222222 100644 +++ a/dts/upstream/src/arm64/rockchip/rk3576-nanopi-r76s.dts 2025-12-06 23:33:40.013947291 +0100 +++ b/dts/upstream/src/arm64/rockchip/rk3576-nanopi-r76s.dts 2025-12-06 23:56:46.961392491 +0100 @@ -772,6 +772,7 @@ status = "okay"; }; +/* eMMC on the Arasan/SDHCI host */ &sdhci { bus-width = <8>; full-pwr-cycle-in-suspend; @@ -781,9 +782,13 @@ no-sdio; no-sd; non-removable; + /* add the supply rails for completeness */ + vmmc-supply = <&vcc_3v3_s3>; /* main VCC rail */ + vqmmc-supply = <&vcc_1v8_s3>; /* I/O rail */ status = "okay"; }; +/* µSD socket on the DW‑MMC host */ &sdmmc { max-frequency = <200000000>; no-sdio; @@ -795,6 +800,8 @@ sd-uhs-sdr104; vmmc-supply = <&vcc_3v3_s3>; vqmmc-supply = <&vccio_sd_s0>; + /* keep this host at 3.3 V so it works when eMMC uses 1.8 V */ + no-1-8-v; pinctrl-names = "default"; status = "okay"; }; With this patch and config changes u-boot detects emmc fine and I can boot from either emmc or sdcard. If this changes are good or bad, I have absolutely no idea.

Hello, another Odroid M1S owner and user here. I tried the Ubuntu image because I was curious about video acceleration in particular. So I installed Kodi and played a few videos. There is no acceleration. This means that this image is not usable as a player. However, it will probably be usable as an SMB/NFS server (I'll try using it that way for a while). A few comments: - Gnome is relatively slower, but not unusably slow (I personally don't mind, because I don't intend to use the M1S as a desktop) - Gnome sometimes has problems rendering windows, there are strange stripes, only in certain parts of the windows, and at times it is so annoying that it becomes unusable - Personally, I would love it if someone experienced could take a working GPU driver and put it into this image. That would solve everything, and we could all use the M1S to our full satisfaction (however, it's probably not that easy, because otherwise the guys at Odroid would have already done it). - I will add relevant links to a functional accelerated solution that makes the M1S a fully functional driver, but based on the very old and not very usable 5.10 kernel - https://forum.odroid.com/viewtopic.php?f=217&t=47621 here is a functional Odroid based image solution for media player. - By the way, I managed to upgrade the image mentioned here to Ubuntu 24.04, using the Kodi build for Odroid M2 ( https://forum.odroid.com/ viewtopic.php?f=235&t=49005 ), but I had to stay on kernel 5.10, and even this version works relatively well as a functional player with accelerated videos (the old kernel is a prerequisite) I hope that I have contributed at least a little to making this Armbian image gradually become the standard for M1S, because this computer deserves it.

Armbian 25.8.2 Noble XFCE (BSD Kernel: 6.1.115) + PanVk - mesa 26.0 (https://launchpad.net/~ernstp/+archive/ubuntu/mesaaco) + FEX-Emu 2510 + hangover-10.18 (https://github.com/AndreRH/hangover/releases/tag/hangover-10.18) + Dxvk 1.10.3 (stripped) 30~60fps@720p (mixed settings) Tomb Raider (2013) Definitive Edition

OK good that is works now. I did not really read all history. I have a build running now (mainline/edge), but I will again need to dig into overlay/dts, hopefully I understand it now a bit better.

suggested solution is to move to kernel 6.18

https://github.com/armbian/build/pull/9094

As a follow up: got my board yesterday. 2GB RAM as announced, no obvious bringup probs. The Ubuntu image runs from SD, UART ok, got 80mb/s from SD and around ~300mb/s from an 128GB 2230 NVME. No boot from upper m.2, only lower m.2 boots (works as announced). The SBC starts via uboot stored on the 16mbyte SPI flash, so I think it should be possible to also boot from upper m.2 since the uboot recognizes media both m.2 slots. Currently unclear how to recover from damaged SPI flash, so I need to proceed carefully. Uboot env is closed (bootdelay=0), so first task is to open up uboot cmd line. Theres a boot switch that seems to trigger some USB boot from ROM but thats undocumented AFAICT. Plenty to investigate for my 50 bucks 😉

What kernel version are you using?

I just registered here to say thanks to @bAL, your solution works on my Odroid HC4. I was bashing my head against the wall because I couldn't find what was constantly changing the fan PWM value even after disabling the fancontrol service. Now I finally have full control over the fan PWM (and thus the noise levels). Thanks again! So yeah, this issue is still relevant in 2025. `lsb_release -a` output for the interested: Distributor ID: Debian Description: Armbian 25.11.2 trixie Release: 13 Codename: trixie

Odd. Should more look like this. Also the first time I hear there is an issue like this. Perhaps retry now since your group is no longer validation but members. https://x.na4.eu/KOTu3/PACoFIsE81.jpg

Try the X11 windowing manager or the Wayland compositor without lightdm (or another display manager).

@JuanEsf sunxi-edge is now on 6.18. You can add your patches for t527 there.

Hello, i have a screen thats bigger than what I could see (frame). on a raspberry, i change the config with overlay adjustment. But i dont know how to do this for the banana pi.. Someone Here could redirect me the rijgt pad where to fix it?

@PH Ph You need to find the correct GPIO# for your emmc. Extract the boot.bin from your original Android to get the device tree (DTS). Follow the steps in this link. https://forum.armbian.com/topic/29794-how-to-install-armbian-in-h618/#findComment-187672

Hi @tmb Helios64 and Armbian are still very relevant in 2025! Thanks to this amazing community! I used mine with OpenMediaVault until a couple of MOSFETs failed and some drives stopped to spin up. Unfortunately, the original components were quite cheap. Even though I found better replacements, I didn’t want to pay for micro-soldering services, which can be pricey compared to the parts themselves (just a few euros). Instead, I built my own NAS using an Intel N100. It’s now a low-power device running a dozen Docker containers, using Home Assistant image as base. I’m totally in unsupported territory, but it works great! With this setup, OpenMediaVault can go into sleep mode when needed, and so far, it’s been working really well for me.

If you learn yourself a strategy not to wipe existing installation, but dist-upgrade it and also have a flexible backup and restore for yourself, you don't need lists or so as the same set of software keeps being there. I clone installations from 1 computer to the other, so do not use new images. With tasksel you can remove and add Desktop Environments, sudo systemctl set-default <target> to changes from GUI to CLI and vice-versa. Make sure you have a serial console cable working (for CLI and no HDMI/kbd/mouse connected). But you can use 'sudo apt list --installed' on Debian systems. Cloning on x86 is easy, for ARM, you need change bootloader and kernel and some other packages. Until also all ARM computers come with UEFI bootloader/firmware. https://www.debian.org/releases/trixie/release-notes/upgrading.en.html#preparing-apt-sources-files https://digint.ch/btrbk/doc/readme.html https://btrfs.readthedocs.io/en/latest/Send-receive.html

Posting this interesting event, in case someone can see why it worked: Banana Pi M4 zero (H618) gained HDMI audio when upgrading to Linux 6.12.30 https://forum.armbian.com/topic/50773-bpi-m4-zero-hdmi-audio/ But in this thread, there's a report that upgrading to 6.16.8 (from 6.15.4) lost HDMI audio

Here the workaround to get a "gdm" login screen: root@ password: _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| v25.11.2 for Khadas VIM3 running Armbian Linux 6.12.58-current-meson64 Performance: Load: 25% Uptime: 4 minutes Local users: 3 Memory usage: 8% of 3.68G CPU temp: 38°C Usage of /: 11% of 58G RX today: 920 MiB Tips: Armbian config utility https://tinyurl.com/yc39n6m3 Commands: Configuration : armbian-config Monitoring : htop root@khadas-vim3:~# systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION 0 loaded units listed. Issue #1: No login screen on HDMI: root@khadas-vim3:~# systemctl status gdm.service ● gdm.service - GNOME Display Manager Loaded: loaded (/usr/lib/systemd/system/gdm.service; static) Active: active (running) since Mon 2025-12-15 17:25:25 CET; 4min 28s ago Process: 2684 ExecStartPre=/usr/share/gdm/generate-config (code=exited, status=0/SUCCESS) Main PID: 2699 (gdm3) Tasks: 4 (limit: 4215) Memory: 8.9M (peak: 10.4M) CPU: 414ms CGroup: /system.slice/gdm.service └─2699 /usr/sbin/gdm3 Dec 15 17:27:04 khadas-vim3 gdm3[2699]: Gdm: on_display_added: assertion 'GDM_IS_REMOTE_DISPLAY (display)' failed Dec 15 17:27:04 khadas-vim3 gdm3[2699]: Gdm: on_display_removed: assertion 'GDM_IS_REMOTE_DISPLAY (display)' failed Dec 15 17:28:40 khadas-vim3 gdm3[2699]: Gdm: GdmDisplay: Session never registered, failing Dec 15 17:28:40 khadas-vim3 gdm3[2699]: Gdm: on_display_added: assertion 'GDM_IS_REMOTE_DISPLAY (display)' failed Dec 15 17:28:40 khadas-vim3 gdm3[2699]: Gdm: on_display_removed: assertion 'GDM_IS_REMOTE_DISPLAY (display)' failed Dec 15 17:28:40 khadas-vim3 gdm-autologin][3881]: PAM unable to dlopen(pam_gnome_keyring.so): /usr/lib/security/pam_gnome_keyring.so: cannot open shared object file: No > Dec 15 17:28:40 khadas-vim3 gdm-autologin][3881]: PAM adding faulty module: pam_gnome_keyring.so Dec 15 17:28:40 khadas-vim3 gdm-autologin][3881]: pam_unix(gdm-autologin:session): session opened for user amach(uid=1000) by amach(uid=0) Dec 15 17:28:41 khadas-vim3 gdm3[2699]: Gdm: on_display_added: assertion 'GDM_IS_REMOTE_DISPLAY (display)' failed Dec 15 17:28:41 khadas-vim3 gdm3[2699]: Gdm: on_display_removed: assertion 'GDM_IS_REMOTE_DISPLAY (display)' failed root@khadas-vim3:~# ll /dev/dri/ total 0 drwxr-xr-x 2 root root 140 Dec 15 17:25 by-path crw-rw----+ 1 root video 226, 0 Dec 15 17:25 card0 crw-rw----+ 1 root video 226, 1 Dec 15 17:25 card1 crw-rw----+ 1 root video 226, 2 Dec 15 17:25 card2 crw-rw----+ 1 root render 226, 128 Dec 15 17:25 renderD128 crw-rw----+ 1 root render 226, 129 Dec 15 17:25 renderD129 root@khadas-vim3:~# udevadm info /dev/dri/card0 P: /devices/platform/soc/ff900000.vpu/drm/card0 M: card0 R: 0 U: drm T: drm_minor 😧 c 226:0 N: dri/card0 L: 0 S: dri/by-path/platform-ff900000.vpu-card E: DEVPATH=/devices/platform/soc/ff900000.vpu/drm/card0 E: DEVNAME=/dev/dri/card0 E: DEVTYPE=drm_minor E: MAJOR=226 E: MINOR=0 E: SUBSYSTEM=drm E: USEC_INITIALIZED=2805131 E: ID_PATH=platform-ff900000.vpu E: ID_PATH_TAG=platform-ff900000_vpu E: ID_FOR_SEAT=drm-platform-ff900000_vpu E: DEVLINKS=/dev/dri/by-path/platform-ff900000.vpu-card E: TAGS=:master-of-seat:uaccess:seat: E: CURRENT_TAGS=:master-of-seat:uaccess:seat: root@khadas-vim3:~# udevadm info /dev/dri/card1 P: /devices/platform/soc/ffe40000.gpu/drm/card1 M: card1 R: 1 U: drm T: drm_minor 😧 c 226:1 N: dri/card1 L: 0 S: dri/by-path/platform-ffe40000.gpu-card E: DEVPATH=/devices/platform/soc/ffe40000.gpu/drm/card1 E: DEVNAME=/dev/dri/card1 E: DEVTYPE=drm_minor E: MAJOR=226 E: MINOR=1 E: SUBSYSTEM=drm E: USEC_INITIALIZED=7219633 E: ID_PATH=platform-ffe40000.gpu E: ID_PATH_TAG=platform-ffe40000_gpu E: GDM_NUMBER_OF_GRAPHICS_CARDS=3 E: ID_FOR_SEAT=drm-platform-ffe40000_gpu E: DEVLINKS=/dev/dri/by-path/platform-ffe40000.gpu-card E: TAGS=:seat:master-of-seat:uaccess: E: CURRENT_TAGS=:seat:master-of-seat:uaccess: root@khadas-vim3:~# udevadm info /dev/dri/card2 P: /devices/platform/etnaviv/drm/card2 M: card2 R: 2 U: drm T: drm_minor 😧 c 226:2 N: dri/card2 L: 0 S: dri/by-path/platform-etnaviv-card E: DEVPATH=/devices/platform/etnaviv/drm/card2 E: DEVNAME=/dev/dri/card2 E: DEVTYPE=drm_minor E: MAJOR=226 E: MINOR=2 E: SUBSYSTEM=drm E: USEC_INITIALIZED=7215211 E: ID_PATH=platform-etnaviv E: ID_PATH_TAG=platform-etnaviv E: GDM_NUMBER_OF_GRAPHICS_CARDS=3 E: ID_FOR_SEAT=drm-platform-etnaviv E: DEVLINKS=/dev/dri/by-path/platform-etnaviv-card E: TAGS=:master-of-seat:uaccess:seat: E: CURRENT_TAGS=:master-of-seat:uaccess:seat: WORKAROUND - Issue #1: root@khadas-vim3:/dev/dri# mv card2 card2out root@khadas-vim3:/dev/dri# ll total 0 drwxr-xr-x 2 root root 140 Dec 15 17:33 by-path crw-rw----+ 1 root video 226, 0 Dec 15 17:35 card0 crw-rw----+ 1 root video 226, 1 Dec 15 17:25 card1 crw-rw----+ 1 root video 226, 2 Dec 15 17:25 card2out crw-rw----+ 1 root render 226, 128 Dec 15 17:25 renderD128 crw-rw----+ 1 root render 226, 129 Dec 15 17:25 renderD129 root@khadas-vim3:/dev/dri# systemctl restart gdm.service root@khadas-vim3:/dev/dri# systemctl status gdm.service ● gdm.service - GNOME Display Manager Loaded: loaded (/usr/lib/systemd/system/gdm.service; static) Active: active (running) since Mon 2025-12-15 17:38:56 CET; 7s ago Process: 8999 ExecStartPre=/usr/share/gdm/generate-config (code=exited, status=0/SUCCESS) Main PID: 9006 (gdm3) Tasks: 5 (limit: 4215) Memory: 6.2M (peak: 7.2M) CPU: 172ms CGroup: /system.slice/gdm.service └─9006 /usr/sbin/gdm3 Dec 15 17:38:56 khadas-vim3 systemd[1]: Starting gdm.service - GNOME Display Manager... Dec 15 17:38:56 khadas-vim3 systemd[1]: Started gdm.service - GNOME Display Manager. Dec 15 17:38:56 khadas-vim3 gdm-autologin][9011]: PAM unable to dlopen(pam_gnome_keyring.so): /usr/lib/security/pam_gnome_keyring.so: cannot open shared object file: No > Dec 15 17:38:56 khadas-vim3 gdm-autologin][9011]: PAM adding faulty module: pam_gnome_keyring.so Dec 15 17:38:56 khadas-vim3 gdm-autologin][9011]: pam_unix(gdm-autologin:session): session opened for user amach(uid=1000) by amach(uid=0) Dec 15 17:38:56 khadas-vim3 gdm3[9006]: Gdm: on_display_added: assertion 'GDM_IS_REMOTE_DISPLAY (display)' failed Dec 15 17:38:56 khadas-vim3 gdm3[9006]: Gdm: on_display_removed: assertion 'GDM_IS_REMOTE_DISPLAY (display)' failed --- Issue #2: Missing Display resolution 3440x1440 for Display Dell U3415W connected to HDMI: root@khadas-vim3:/home/amach# cat xrandr.txt Screen 0: minimum 16 x 16, current 2560 x 1440, maximum 32767 x 32767 HDMI-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 800mm x 330mm 2560x1440 59.91*+ 1920x1440 59.90 1600x1200 59.87 1440x1080 59.87 1400x1050 59.86 1280x1024 59.76 1280x960 59.94 1152x864 59.78 1024x768 59.68 800x600 59.86 640x480 59.38 320x240 59.52 1920x1200 59.88 1680x1050 59.85 1440x900 59.89 1280x800 59.81 1152x720 59.75 960x600 59.63 928x580 59.88 800x500 59.50 768x480 59.38 720x480 59.71 640x400 59.20 320x200 58.96 2048x1152 59.90 1920x1080 59.88 1600x900 59.82 1368x768 59.88 1280x720 59.86 1024x576 59.90 864x486 59.45 720x400 59.55 640x350 59.77 root@khadas-vim3:/dev/dri# inxi -Gxx Graphics: Device-1: meson-g12a-vpu driver: meson_drm v: N/A bus-ID: N/A chip-ID: amlogic:ff900000 Device-2: meson-g12a-mali driver: panfrost v: kernel bus-ID: N/A chip-ID: amlogic:ffe40000 Device-3: meson-g12a-dw-hdmi driver: meson_dw_hdmi v: N/A bus-ID: N/A chip-ID: amlogic:ff600000 Display: server: X.org v: 1.21.1.11 with: Xwayland v: 23.2.6 compositor: gnome-shell v: 46.0 driver: X: loaded: modesetting gpu: meson_drm,panfrost,meson_dw_hdmi tty: 170x62 Monitor-1: HDMI-A-1 model: Dell U3415W res: 3440x1440 dpi: 109 diag: 865mm (34.1") API: EGL v: 1.5 platforms: gbm: drv: etnaviv surfaceless: drv: panfrost inactive: wayland,x11 API: OpenGL v: 3.1 compat-v: 2.1 vendor: mesa v: 25.0.7-0ubuntu0.24.04.2 note: console (EGL sourced) renderer: Vivante GC8000 rev 7120, Mali-G52 (Panfrost) Please let me know or test to set the display resolution to 3440x1440 - Thank you

BOOTFS_TYPE=fat is part of the aml-s9xx-box.tvb config file and has always been. So I'm not sure what your comment is referring to, but it seems to be off topic for this thread which is about instructions for using the aml-s9xx-box Armbian builds.

@Trinom I know this post is really old but I have to chime in on this. The instructions that @Igor gave you says to use Armbian to boot the device with then use the commands given to install Armbian. Raspbian is not Armbian. Just sayin' Just trying to figure out what or where you were reading.

With the following options configured as a built-in module, the issue does not happen anymore on a poweron. CONFIG_TYPEC=y CONFIG_TYPEC_TCPM=y CONFIG_TYPEC_TCPCI=y CONFIG_TYPEC_FUSB302=y CONFIG_PHY_ROCKCHIP_USBDP=y I can create a pull request for the linux-rockchip64-edge.config file. But not sure what the general consensus on the kernel options for Armbian kernels is. Maybe it is also fixable via some code change, but that would be something for a real kernel developer.