Skip to main content

lvgl-dashboard-x-evk

:::warning [UNTESTED] on silicon CMake parses cleanly and the LVGL 9.1 API is verified against the upstream v9.1.0 tag. Real-hardware bring-up is gated on the display-pipeline patches landing in the Yocto layer. :::

A minimal LVGL 9 dashboard on the E1M-X V2N MIPI-DSI panel (RK055HDMIPI4MA0, 720×1280 @ 60 Hz).

Source: examples/display/lvgl-dashboard-x-evk/.

What makes it different​

This is the SDK's first Linux-side display example, and it deliberately sits outside the <alp/display.h> migration that the Zephyr LVGL examples went through.

On the Renesas RZ/V2N family the display pipeline is owned by the A55 Linux cluster, so the app talks to DRM/KMS directly:

lv_init();
lv_display_t *disp = lv_linux_drm_create();
lv_linux_drm_set_file(disp, "/dev/dri/card0", -1);   /* -1 = first connected connector */

There is no alp_display_* indirection on Linux — the OS-provided DRM stack is the portable surface. Contrast with lvgl-widgets-demo, which runs on Zephyr and therefore opens its panel via alp_display_open() + alp_gui_lvgl_attach().

The panel is a platform device (DRM/KMS via the carrier device tree), not an SDK chip driver — so there is no chips: entry. LVGL 9 comes from the Yocto distro (meta-oe lvgl package, DRM backend), not the Zephyr libraries: loader.

board.yaml​

First example with this shape: no libraries:, no chips:, no pins:.

som:
  sku: E1M-V2N101            # any V2x SKU works -- same PCB, same panel path

preset: e1m-x-evk

cores:
  a55_cluster:
    app: ./src               # Linux userspace app (DRM/KMS + evdev)
    recipe: alp-lvgl-dashboard   # the recipe that packages `app:` above --
                                  # `app:` alone is a source path, never a
                                  # valid bitbake target

  m33_sm:
    os: "off"                # display is wholly A55-owned

diagnostics:
  log_level: info

The recipe: key names the bitbake target that packages the app: source path. A Yocto app-only slice needs it — app: alone is a source path, not a buildable target.

Hardware​

  • E1M-X EVK with a V2x SoM.
  • RK055HDMIPI4MA0 panel on the carrier's Display 1 connector (J6).
  • Backlight enable on GPT1 CH2.

Build and run​

Two consumer paths:

  • Recommended — the Yocto recipe at meta-alp-sdk/recipes-examples/alp-lvgl-dashboard/ packages the app into alp-image-edge. Boot the image and run alp-lvgl-dashboard.
  • Standalone — cross-compile against the SDK sysroot with plain CMake.

Either way, stop the compositor first — DRM allows a single master:

systemctl stop weston
alp-lvgl-dashboard

What's on screen​

A title label, a 360×360 arc at 62 %, and a "Touch me" button.

:::note Touch is not wired yet The app creates an evdev pointer if /dev/input/event0 is readable, but the GT911 touch controller's I²C bus has no Linux master today on V2N-family SoMs, so there is no Linux-visible input adapter until the bridge I²C-proxy follow-up lands. The dashboard is display-only in the meantime. :::

See also​

Questions about this page? Discuss in Community Forum