Integration Guide

How to integrate GraphLab Boot into your BSP, configure the display handover, and deploy to production.

---

4.1 — Boot sequence overview

Power On
  │
  ├── M7 Core starts immediately
  │     ├── Initialize display controller
  │     ├── Render splash to framebuffer
  │     ├── Read license from shared RAM
  │     └── Validate license
  │
  ├── U-Boot SPL
  │     ├── Load initstub.bin from boot FAT partition
  │     ├── Load license.bin into shared RAM slot
  │     └── Jump to init-stub → main U-Boot → Kernel
  │
  ├── Linux Kernel
  │     ├── DRM/KMS driver initializes
  │     ├── Takes over display WITHOUT reset
  │     └── Framebuffer content persists
  │
  └── Userspace
        ├── Application renders to DRM plane
        └── Smooth visual transition from splash

Responsibility split

Component	Responsibility
Realtime core firmware	First pixel, splash rendering, license verification
U-Boot SPL	Loading initstub + license from storage
Linux kernel DRM	Taking over display plane without reinit
Userspace app	Rendering final UI to the same DRM plane

Display ownership model

The display controller is initialized exactly once by the realtime core firmware. Every subsequent stage (U-Boot, kernel, userspace) inherits the existing display state. No component reinitializes the display pipeline — this is what eliminates flicker.

---

4.2 — BSP integration

Required configuration changes

1. Reserve realtime core memory regions in the device tree
2. Configure the shared RAM region for license/display state exchange

Kernel configuration

# Required
CONFIG_DRM=y
CONFIG_DRM_ATOMIC=y
CONFIG_DRM_GRAPHLAB_DRM=y
CONFIG_DRM_GRAPHLAB_DRM_RPMSG=y

Device tree considerations

Reserve the memory regions used by RPMsg, M7, and framebuffer handover (example from Verdin iMX8MP overlay):

reserved-memory {
    #address-cells = <2>;
    #size-cells = <2>;
    ranges;

    m7_reserved: m7@80000000 {
        reg = <0 0x80000000 0 0x01000000>;
        no-map;
    };

    vdev0vring0: vdev0vring0@55000000 {
        reg = <0 0x55000000 0 0x8000>;
        no-map;
    };

    vdev0vring1: vdev0vring1@55008000 {
        reg = <0 0x55008000 0 0x8000>;
        no-map;
    };

    vdevbuffer: vdevbuffer@55400000 {
        compatible = "shared-dma-pool";
        reg = <0 0x55400000 0 0x100000>;
        no-map;
    };

    rsc_table: rsc-table@550ff000 {
        reg = <0 0x550ff000 0 0x1000>;
        no-map;
    };

    fb_reserved: framebuffer@be000000 {
        reg = <0 0xBE000000 0 0x01000000>;
        no-map;
    };
};

Build integration

For Yocto-based builds, add the GraphLab Boot layer to your bblayers.conf:

BBLAYERS += "${BSPDIR}/sources/meta-graphlab"

---

DRM handover modes

GraphLab Boot supports two display handover modes that control when the Linux graphics stack takes ownership of the display pipeline. The mode is configured through the GraphLab DRM device tree node.

Mode	Behavior	Typical use case
manual	The display remains owned by the GraphLab runtime until the userspace application explicitly switches to Linux display mode. The application triggers the handover through the GraphLab control interface.	Systems where the application needs full control over the transition, e.g. custom HMI startup animations.
auto	The system automatically switches display ownership to Linux as soon as the DRM driver registers and initializes the display pipeline.	Systems using standard Linux boot visuals such as Plymouth or simple splash-to-UI transitions.

Device tree configuration example

graphlab_drm: graphlab-drm {
        compatible = "graphlab,drm";

        /* Handover mode */
        handover-mode = "manual";   /* or "auto" */
    };
    

4.4 — Build & deployment

Build steps

1. Integrate the GraphLab Boot layer into your BSP (Yocto/custom)
2. Configure the device tree with reserved memory regions
3. Build the Linux image with the correct kernel configuration
4. Generate and deploy a device license via the Portal

Deployment steps

1. Flash the Linux image to eMMC (via UUU or other method)
2. Deploy initstub.bin and license.bin to the boot FAT partition
3. Optionally deploy a custom splash.bin
4. Power-cycle and verify the boot experience