Skip to content
GraphLabProduct studiesCheck project fit
Product studyGraphLab Boot

Visible OTA update status

An update can temporarily remove the normal Linux UI at exactly the moment an operator needs reassurance. This study explores keeping a controlled status view on the real-time side while the update system reports agreed, observable milestones.

Panel-mounted industrial HMI showing a staged OTA update state on an automated production line.

Intended outcome

Keep the update understandable while the main system changes

The visible experience would remain available while Linux services stop, system partitions change, or the device prepares to reboot. The displayed text and states would come from events that the update integration can actually observe.

The result would be a small, bounded state model such as preparing, installing, verifying, restarting, completed, or attention required. It would not invent a percentage or predict how long the update will take.

Proposed behavior

A project-defined operating sequence

  1. Update accepted

    Linux validates the update request and publishes an agreed start state before disruptive work begins.

  2. Observed milestones

    The update service sends durable state transitions through the project-defined interface.

  3. Real-time presentation

    GraphLab Core keeps the current approved update state visible, including while the normal application is unavailable.

  4. Restart and completion

    Boot and application readiness signals determine when the final Linux UI may replace the update view.

Architecture

Responsibilities stay explicit

Update owner

The Linux update service remains responsible for package validation, installation, rollback, and the authoritative update state.

State contract

A small versioned interface carries only approved milestone identifiers, optional bounded text, and recovery information.

Display owner

The real-time side renders the last accepted state and follows the project policy for restart, timeout, or missing status.

Project inputs

Integration points to define and validate

  • Update framework and its authoritative lifecycle events.
  • Message transport, persistence, versioning, and behavior across reboot.
  • Approved status vocabulary, localization, and bounded custom text.
  • Failure, rollback, power-loss, and interrupted-update states.
  • Boot readiness and Linux UI readiness signals after the update.
  • Acceptance tests for every supported update and recovery path.

Assess the concept

Could this fit your platform?

Share the target SoC, display path, BSP, Linux UI stack, and the state or failure you need to make visible.

Check project fit

Continue exploring

Related product studies