Sander de Leeuw

It was caching. I cleared the `cache/initrd/` folder and rebuilt Armbian, then it worked fine.
 
@Igor I created a Pull Request go get this change into main.
https://github.com/armbian/build/pull/5901
 

Hi again @NicoD,
 
I tested this with a Full HD monitor and that works just fine!!!
Mistery solved, kind off ...
 
When booting Armbian with my Full HD monitor attached, the Simple DRM / "None-1" output is not present.
The `simpledrm.ko` kernel module is not detected or loaded, so only the /dev/card0 and /dev/card1 devices exists.
Both X.org and Wayland are working as expected.
 
When booting Armbian with my QHD monitor attached, the `simpledrm.ko` kernel module is (automatically) loaded.
(And therefore the None-1 output exists and that is selected as output instead of the HDMI-1-1 output.)
For some reason, the attached monitor causes the Simple DRM feature to be activated in the Linux kernel (or not).
 
I also installed sway / Wayland, while having the QHD monitor attached. Same issue there.
The monitor appears frozen, but when pressing CTRL-ALT-F2, another tty appears and I can kill sway and the first tty becomes responsive again.
Executing the `modprobe -r simpledrm` module fixes the issue and sway can be started normally.
 
@Walter Zambotti blacklisting the simpledrm kernel module (as described in my original post) might be a solution for you as well.
 
Well, issue closed, I guess. It would be nice if Armbian could somehow detect this situation and adapt to it.
But I have no clue where to start, to be honest.

Hi,
 
I just wanted to report how I got Armbian 23.8.1 working on my Khadas VIM3 Pro board.
It was not an out-of-the-box success story, but after a few nights of debugging, I found the cause and fix of the issue.
Hopefully this post will save debugging time of somebody else and maybe this can be fixed in future Armbian releases.
 
The issue is as follows: After flashing the Armbian 23.8.1 image to the VIM3's internal EMMC storage, the SBC boots fine initially.
I walk through the setup-process of users/passwords/network/locale, etc...
After the set-up completes, I reboot the SBC. It starts booting as usual, but when X.org starts, my monitor stops receiving any signal and goes to sleep.
 
I tried these images:
1. Armbian_23.8.1_Khadas-vim3_bookworm_current_6.1.50_cinnamon_desktop.oowow.img.xz
2. Armbian_23.8.1_Khadas-vim3_bookworm_current_6.1.50.oowow.img.xz (installed X.org and XFCE manually afterwards)
3. Pretty sure I had the same problem with Jammy based images, however I saw @NicoD using them without issues on Youtube.
 
Eventually, I found out from the X.org logs that it was displaying to another output device:
[ 37.633] (II) xfree86: Adding drm device (/dev/dri/card1) [ 37.633] (II) Platform probe for /sys/devices/platform/f4e5b000.framebuffer/drm/card1 [ 37.634] (II) xfree86: Adding drm device (/dev/dri/card0) [ 37.634] (II) Platform probe for /sys/devices/platform/soc/ff900000.vpu/drm/card0 [ 37.643] (II) xfree86: Adding drm device (/dev/dri/card2) [ 37.643] (II) Platform probe for /sys/devices/platform/soc/ffe40000.gpu/drm/card2 [ 37.647] (II) no primary bus or device found [ 37.647] falling back to /sys/devices/platform/f4e5b000.framebuffer/drm/card1 ... [ 37.665] (II) modeset(0): using drv /dev/dri/card1 [ 37.676] (II) modeset(G0): using drv /dev/dri/card0 [ 37.676] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 [ 37.676] (**) modeset(0): Option "AccelMethod" "glamor"  
It defaulted to /dev/dri/card1 which is the simpledrm framebuffer output introduced in recent kernel versions.
By updating the X.org config file, I was able to force it selecting /dev/dri/card0 instead, however, according to the modeset man page this should be the default.
Section "Device" Identifier "DRM Graphics Acclerated" ## Use modesetting and glamor Driver "modesetting" Option "AccelMethod" "glamor" ### "glamor" to enable 3D acceleration, "none" to disable. Option "DRI" "2" Option "Dri2Vsync" "true" Option "TripleBuffer" "True" ## End glamor configuration Option "kmsdev" "/dev/dri/card0" EndSection ...  
I still found the performance of the desktop a bit sluggish. Maybe this is because the second Glamor/DRM enabled output still exists.
I was able to completely get rid of the SimpleDRM output using the following commands and reboot:
 
echo "blacklist simpledrm" | sudo tee /etc/modprobe.d/simpledrm.conf sudo update-initramfs -u  
Now, X.org works as expected.
 
I also disabled the XFCE Compositor, which made de desktop perform much better.
Firefox (with GPU enabled) shows some graphics artifacts which are gone after disabling hardware acceleration.
 
Hope that this will help somebody.
 

Motivated by Igor's "no crew" argument, I gave it a shot myself, but without much success yet.
 
I have removed "panic=10" from /boot/boot.cmd and ran mkimage.
This allowed me to enter the busybox shell from u-boot.
 
$ cat /proc/partitions
1 0 4096 ram0
 
So the eMMC modules does not seem to be recognized by the kernel.
When I plugin a SD-card, it's immediately detected and available for use.
 
***
 
It seems to me that eMMC support is not (completely) functional in the kernel.
Checked the kernel configuration files, but in both versions, MMC/eMMC support is enabled:
 
[sander@thinkpad-t480 Work]$ grep EMMC config-4.4.190-rockchip
CONFIG_PWRSEQ_EMMC=y
CONFIG_PHY_ROCKCHIP_EMMC=y
[sander@thinkpad-t480 Work]$ grep EMMC config-5.3.11-rockchip
CONFIG_PWRSEQ_EMMC=y
CONFIG_PHY_ROCKCHIP_EMMC=y
[sander@thinkpad-t480 Work]$ grep MMC= config-4.4.190-rockchip
CONFIG_MMC=y
CONFIG_PWRSEQ_EMMC=y
CONFIG_PHY_ROCKCHIP_EMMC=y
[sander@thinkpad-t480 Work]$ grep MMC= config-5.3.11-rockchip
CONFIG_MMC=y
CONFIG_PWRSEQ_EMMC=y
CONFIG_PHY_ROCKCHIP_EMMC=y
 
I noticed a bunch of new kernel modules (configured as modules) in the u-boot initrd of 5.3.11-rockchip.
Tried to load them, but that didn't change a thing. For reference, here's a list of modules I tried/loaded:
 
/usr/lib/modules/5.3.11-rockchip/kernel/drivers/mmc/
 * core/pwrseq_sd8787.ko,
 * host/dw_mmc-bluefield.ko,
 * host/rtsx_usb_sdmmc.ko,
 * host/sdhci-cadence.ko,
 * host/sdhci-of-dwcmshc.ko
 
***
 
Also compared the init and other scripts under /scripts in the u-boot initramfs between Armbian_5.95 (ok) and Armbian_19.11.3 (not booting).
Did not find a significant difference there.
 
So far no good ;-) Will give it another try later on.