Armbian 23.8.1 on the Khadas VIM3

[Sander de Leeuw]

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.

 

[NicoD]

That's a weird issue. I tested the latest images, but not sure if I tried an x11 desktop.
I'll try the images you mentioned on my VIM3 and see what happens.

 

[NicoD]

@Sander de LeeuwI'm unable to recreate this issue.
It boots right into the desktop as it should. Tried "Armbian_23.8.1_Khadas-vim3_bookworm_current_6.1.50_cinnamon_desktop.oowow"
Not sure what would cause this for you.

[Sander de Leeuw]

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.

 

 

 

Edited November 6, 2023 by Sander de Leeuw

[Sander de Leeuw]

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.

[yannbouteiller]

Hello,

 

I am trying the same with a VIM3 Pro right now.

 

First I flashed Armbian_23.8.1_Khadas-vim3_bookworm_current_6.1.50_cinnamon_desktop.oowow to an SD card and booted from that, which worked, including the display.

 

Then I installed it on the EMMC (using armbian-install), which still boots (I can connect via the linux serial console), but I confirm the HDMI display doesn't work anymore when booting from the EMMC.

Edited November 6, 2023 by yannbouteiller

[NicoD]

Now I can confirm the issue.
I also have a Philips 4K monitor and nothing shows on it. I tried first with my 13" 1080p display.

Weird problem. I wonder if it is the same with other SBCs like N2+ and if it's the display resolution or something with brand/type display?

I'll see if I can find out more tomorrow.

[NicoD]

2 minutes ago, yannbouteiller said:

Then I installed it on the EMMC (using armbian-install), which still boots (I can connect via the linux serial console), but I confirm the HDMI display doesn't work anymore when booting from the EMMC.

What display are you using? And bit weird that it would work from sd and not from eMMC. I tested on sd-card only.

Can you try Jammy to see if it also has this behaviour?

[yannbouteiller]

My monitor is a Dell 27 Monitor - S2721DS (2560 x 1440, 59.95 Hz)

 

With Bookworm, I could use the display once when booting from the SD card, but then after installing on EMMC and rebooting the system the screen would only display the Armbian loading screen, and then go black (I had to login via the linux serial console). I tried to plug the SD card back in and reboot, but screen still black.

 

Then I tried with Jammy on the SD card, and directly after setting up username/password/etc I got the same issue: Armbian loading screen, then black screen.

 

As a matter of fact I don't need the display so I'll try the CLI version for now.

Edited November 6, 2023 by yannbouteiller

[Sander de Leeuw]

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.

 

Quote

And bit weird that it would work from sd and not from eMMC. 

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.

 

Quote

I wonder if it is the same with other SBCs like N2+ and if it's the display resolution or something with brand/type display?

 

If the above is true, this might be the case with other board with CONFIG_VIDEO_MESON=y and CONFIG_VIDEO_DT_SIMPLEFB=y

 

[Sander de Leeuw]

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

[NicoD]

Seems it is. I created a bug report for this. Thank you all the valuable info.

[Sander de Leeuw]

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

 

Edited November 10, 2023 by Sander de Leeuw

[Sander de Leeuw]

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.

[Sander de Leeuw]

Perhaps `simpledrm` should be disabled in the Linux kernel?

I also noticed another bug report and related forum thread about this kernel module.

[Igor]

10 hours ago, Sander de Leeuw said:

Perhaps `simpledrm` should be disabled in the Linux kernel?

You mean generally? On all config files https://github.com/armbian/build/tree/main/config/kernel

 

 CONFIG_DRM_BOCHS=m
 CONFIG_DRM_CIRRUS_QEMU=m
 CONFIG_DRM_GM12U320=m
-CONFIG_DRM_SIMPLEDRM=m
+# CONFIG_DRM_SIMPLEDRM is not set
 CONFIG_TINYDRM_HX8357D=m
 CONFIG_TINYDRM_ILI9225=m
 CONFIG_TINYDRM_ILI9341=m

BTW. If we want to block module per board:
https://github.com/armbian/build/blob/main/config/boards/rk3318-box.tvb#L8

This automatically creates blacklist file ...

[Sander de Leeuw]

3 hours ago, Igor said:

You mean generally?

 

@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.

 

3 hours ago, Igor said:

BTW. If we want to block module per board:

 

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?

 

Edited November 12, 2023 by Sander de Leeuw

[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

 

[rpardini]

On 11/12/2023 at 10:16 PM, Sander de Leeuw said:

It was caching. I cleared the `cache/initrd/` folder and rebuilt Armbian, then it worked fine.

 

Thanks for reporting this, should be fixed in https://github.com/armbian/build/pull/5914