Add a persistent splash to your Torizon product

Intended outcome

Move from known display timings to a generated project configuration

For a product team, the intended path is deliberately simple. Create a workspace and enter the known timing values for the assessed display. The GraphLab Portal generates the project-specific output, including the required device-tree settings, and provides the Torizon or Yocto integration guide. GraphLab Splash then provides the branded controlled screen from power-on while the normal Linux application starts in parallel.

For the integration owner, the same workflow remains explicit rather than hidden. The generated output is specific to the selected system configuration and connects the real-time display path, boot artifacts, Linux DRM integration, and chosen presentation-switch behavior without replacing the existing application. GraphLab Boot builds on the same path when the product also needs observed status, custom text, or defined fallback. Its standard early experience can map observed boot, display, and DRM milestones to approved status text.

GraphLab Splash and GraphLab Boot integrate with the Torizon BSP and Yocto layer model, independent of the Torizon container runtime. A configured target receives target-specific output; it is not one interchangeable binary for every module, carrier, panel, or BSP release.

Proposed behavior

A project-defined operating sequence

1. Enter the known display timings

   Create a GraphLab workspace and provide the timing values for the assessed display, plus the splash artwork and presentation behavior for the target product.

2. Generate the project output

   The portal provides the GraphLab Splash or GraphLab Boot configuration, project artifacts, license material, and the integration guidance associated with that configuration.

3. Add it to the Torizon build

   Add the meta-graphlab layer and supplied artifacts to the Torizon or Yocto build, then apply the documented target settings.

4. Start with controlled output

   After the image is built and flashed, GraphLab Core presents the approved early screen while Linux renders in parallel. The accepted Linux frame is selected at the configured readiness point.

Architecture

Responsibilities stay explicit

Project inputs

Integration points to define and validate

• Portal generation applies to the assessed display when the customer supplies the required timing values. It does not infer missing timings or imply automatic compatibility for unassessed or unsupported display hardware.
• A GraphLab portal workspace, target system configuration, and the relevant project license.
• Approved splash artwork, display mode and timing, and the desired automatic or application-controlled presentation switch.
• The chosen Linux-frame policy: automatic detection of a valid continuous frame or an explicit sysfs switch when the application declares itself ready.
• The Torizon or Yocto BSP release, meta-graphlab layer, Bootloader SPL integration, kernel configuration, and GraphLab DRM support.
• Reserved device-tree memory for the real-time core, shared state exchange, and framebuffer handover.
• Deployment of the generated boot artifacts, including initstub.bin and license.bin, with splash.bin when the selected configuration uses a custom early image.
• A filmed power-on check that verifies the early screen, selected Linux frame, warm reset behavior, and the unchanged Linux application-ready milestone.
• For the published Verdin reference, validation with familiar Toradex Demo Gallery applications such as Qt, Embedded Wizard, and Crank Storyboard. A richer early GUI with animations, primitives, or live peripheral data remains GraphLab-delivered project work rather than a self-service portal feature.
• The published approximately 800 ms first-pixel result applies only to the validated Toradex Verdin iMX8M Plus, LVDS, and Torizon reference. It is not a timing promise for another configuration and GraphLab Boot does not reduce Linux application readiness time.