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

@Igor No, specifically for the VIM3, at least for now. Topics that relate to SimpleDRM (here and here) always refer to Panfrost as well. I think that there is a conflict between SimpleDRM and Panfrost. I can imagine that SimpleDRM does work out well for other boards, where an accelerated 3D driver is not available. Thanks for that suggestion. I think that blacklisting the module is preferred over not building/including it in the image, so that advanced users have can still have access to SimpleDRM if they require. I just gave it a try: https://github.com/armbian/build/compare/main...sdeleeuw:armbian-build:fix/khadas-vim3-blacklist-simpledrm The resulting image does contain the blacklist file in /etc/modprobe.d, but the simpledrm is still loaded (early) in the initramfs. Just executing `update-initramfs -u` and rebooting fixes the issue. I noticed that there is some caching mechanism inside the Armbian build scripts. Perhaps the initramfs is taken from cache rather that being re-build with the blacklist file in place?

Perhaps `simpledrm` should be disabled in the Linux kernel? I also noticed another bug report and related forum thread about this kernel module.

I have also tried to completely disable the simplefb: https://github.com/armbian/build/compare/main...sdeleeuw:armbian-build:fix/khadas-vim3-meson64-disable-framebuffer But again, I don't see any difference in the resulting image. I don't feel confident anymore about this having anything to do with U-Boot now.

The patch mentioned above can still be applied to U-Boot 2023.10, but it doesn't seem to make any difference. I forked the Armbian GitHub repo and refreshed the patch using "./compile.sh BOARD=khadas-vim3 BRANCH=current uboot-patch". After which I applied the original patch and fixed some typo's. The result is here: https://github.com/armbian/build/compare/main...sdeleeuw:armbian-build:fix/khadas-vim3-hdmi-fail-safe So I build a desktop image with this patch applied. The first time after finishing the Armbian initial boot script, I got to the desktop in a super low resolution. After rebooting, my monitor went to sleep after launching X.org, just as it does on the current images. Blacklisting the simpledrm kernel module does solve the problem, as mentioned above: echo "blacklist simpledrm" | sudo tee /etc/modprobe.d/simpledrm.conf sudo update-initramfs -u

Maybe this patch from Khadas' version of UBoot is related: https://github.com/khadas/khadas-uboot/blob/master/packages/u-boot-mainline/patches/v2021.10/meson64.patches/0029-video-meson-add-HDMI-fail-save-FullHD-option.patch

A couple of research notes: Armbian uses UBoot 2023.10 for Khadas VIM3 (source) UBoot config sets CONFIG_VIDEO_MESON=y and CONFIG_VIDEO_DT_SIMPLEFB=y (source) UBoot Meson driver probes the HDMI display (and calls `meson_vpu_setup_mode` with the probe result) (source) meson_vpu_setup_mode function configures the `meson_fb` struct (source) meson_vpu_setup_simplefb utilizes the `meson_fb` struct (source) There is also code in the Meson driver that processes the HDMI EDID meta data; not sure if this impacts SIMPLE_FB (source) The SimpleDRM driver in the Linux kernel probably gets activated if SIMPLE_FB is prepared by UBoot The summary of this is that UBoot probes the display early in the boot process and sets up a framebuffer device if the attached HDMI device has certain capabilities. If this framebuffer device is available, then the Linux kernel loads the SimpleDRM driver against it. I am not very familiar with this topic, so perhaps somebody else can review/challenge the notes above. Maybe the power cord was plugged in before the HDMI-cable. UBoot doesn't setup the framebuffer in that case. After installing to EMMC and rebooting, UBoot runs again, but then the HDMI-cable is already plugged in. If the above is true, this might be the case with other board with CONFIG_VIDEO_MESON=y and CONFIG_VIDEO_DT_SIMPLEFB=y

@Walter Zambotti If this is still an issue for you, you might want to look into this:

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 @NicoD, Thank you for taking the to time to look into this. And I am happy to hear that it is just me having this problem. I just flashed the "Armbian_23.8.1_Khadas-vim3_bookworm_current_6.1.50_cinnamon_desktop.oowow" to a SD-card once more. Same problem. I made a video recording with my smartphone, you can watch it here: https://s3.eu-west-1.amazonaws.com/s.deleeuw/NicoD/PXL_20231106_191106440.TS.mp4 Some more thoughts: 1. Maybe there is a difference between the VIM3 Basic and Pro. I think I remember from one of your video's that you own the Basic/2GB model. 2. Maybe it is related to the monitor. I have a Philips QHD display. I have a Full HD monitor somewhere else in the house, will give that a try. 3. I will also check if installing Sway / Wayland and running that does work out of the box. 4. In X.org the Simple DRM output presents itself as "None-1". Here is another dude that faced the same issue: Edit: @NicoD Do you have the "None-1" output listed in your display settings (or xrandr output)? I have some time to experiment with this tomorrow evening. Will let you know the results.

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.

Thanks a lot @Igor !!

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.

@kknickkk: you can find the older builds on the download page under the "old" link; I used 5.95 and apt-get upgraded to the latest version. edit: also useful to read/know that it does boot from SD, just not from eMMC. @igor: good to see that this issue is being worked on. Let me know if I can do some testing.

I can confirm that the latest images for Thinker Board do not boot on a Tinker Board S / eMMC. I do not own a Tinker Board (no S) and did not try booting from a SD-card. The message "Begin: Running /scripts/local-block ... done." is shown repeatedly. I have already checked that the UUID in /boot/armbianEnv.txt /etc/fstab are equal to the actual partition UUID. I also noticed that "usbstoragequirks=..." has been removed from /boot/armbianEnv.txt, but adding it didn't help. The following images DO NOT boot: - Armbian_19.11.3_Tinkerboard_buster_current_5.3.11_minimal.img - Armbian_19.11.3_Tinkerboard_buster_legacy_4.4.199_desktop.img - Armbian_19.11.3_Tinkerboard_buster_legacy_4.4.199.img The following images DO boot properly: - Armbian_5.95_Tinkerboard_Debian_buster_default_4.4.190.img - 20190821-tinker-board-linaro-stretch-alip-v2.0.11.img