Included
What Splash delivers
- Project configuration from known timings
- Approved early branding
- Persistent real-time display authority
- Controlled selection of the accepted Linux frame
GraphLab Splash · Branded startup
Your product, visible from the first moment.
Provide the known display timings in the GraphLab Portal. It creates the project-specific configuration, including the required device-tree settings, while GraphLab Splash keeps your branding visible as Linux starts.
Defined scope
Know exactly what Splash includes.
Every engagement is assessed and accepted against the target hardware, firmware, display path, Linux stack, and readiness contract.
4 included
Operating sequence
One controlled path from power-on to Linux UI.
Power on
Bootloader loads and starts GraphLab Core on the real-time core.
Brand visible
The real-time core initializes the display and presents approved branding.
Linux joins
Linux renders in parallel into the already active display path.
UI selected
The accepted Linux-rendered framebuffer becomes visible at the agreed readiness point.
Real hardware proof
The published reference makes the boundary visible.
The GraphLab Boot reference on Toradex Verdin iMX8M Plus reaches its first visible pixel in approximately 800 ms. That result belongs to the validated Boot setup and is not a performance promise for Splash on another configuration.
Read the platform proofCompare visible output continuity, not Linux application boot duration.
Product comparison
Move up only when the visible requirement demands it.
| Capability | SplashBranded startup | BootStatus and fallback | ProBespoke early GUI |
|---|---|---|---|
| Project configuration from known timings | Yes | Yes | Yes |
| Persistent display authority | Yes | Yes | Yes |
| Approved branding | Yes | Yes | Yes |
| Observed status and progress | No | Yes | Yes |
| Defined fallback | No | Yes | Yes |
| Functional early GUI with peripheral I/O | No | No | Yes |
GraphLab Splash Technical Articles
Understand the architecture behind this product path.
Why Embedded Linux Displays Flicker During Boot
Diagnose black frames, flicker, and visible resets across the bootloader, Linux DRM, compositor, and embedded application startup path.
Read articleWhy a Boot Splash Does Not Solve Display Handover
A boot splash can cover waiting time, but it does not by itself preserve panel and display-controller state through the Linux graphics transition.
Read articleSeamless Boot-to-Qt Without Display Reinitialization
Keep early display output stable until the Qt application has a complete frame, without confusing visual continuity with faster application startup.
Read articleGraphLab Splash Product Studies
See where this product path can fit.
Add a persistent splash to your Torizon product
Enter the known display timings in the GraphLab Portal, add the generated GraphLab Splash configuration to your Torizon build, and keep a branded screen visible until the Linux UI is ready.
Read product study
Visible OTA update status
Keep an operator-facing status visible while Linux or the main system applies an update.
Read product study
Low-power display operation
Let the real-time core maintain a controlled display while application cores sleep, then request a wake-up when needed.
Read product study
Charging status while application cores sleep
Keep charging progress and battery warnings visible from the real-time side, then allow an A-core start only after the agreed power conditions are met.
Read product studyFree project fit check
Tell us what the display must do before Linux is ready.
A GraphLab engineer will review your NXP i.MX display path and identify whether Splash, Boot, or Pro is the practical next step.
- No confidential design files required
- Product-focused technical review
- Reply within one business day