The driver's dashboard — the instrument panel behind the steering wheel — is its own self-contained computer, separate from the head unit. It is the module that shows speed, range, state-of-charge, drive mode and the warning lamps. Unlike the centre touchscreen, the head unit cannot draw on the main cluster: the cluster renders its own screen and only reads values that other modules broadcast on the CAN bus. See Architecture for where it sits.

The cluster is a small embedded Linux computer paired with a safety microcontroller — the same “big SoC + guardian MCU” split used by the head unit and the TBox.

• SoC — an NXP i.MX6 (Dual) application processor.
• OS — a lightweight Buildroot Linux (kernel 4.1.15) on eMMC, booted by U-Boot. Not Android.
• UI — a custom ARM graphics application (vendor “xtd”) that renders to the panel's framebuffers; all the gauges, lamps, drive-mode artwork and start-up animation are image assets shipped with it.
• Companion MCU — a separate safety microcontroller carries the legally-mandatory tell-tales. This is deliberate: the warning lamps must keep working even if the Linux UI hangs, so the safety-critical layer does not depend on the application processor. Practically, the “fancy” graphics live on Linux; the mandatory warnings live on the MCU.

The cluster is unusually isolated for a networked-looking device:

• No general network. It has no Ethernet and no Wi-Fi of its own — there is no IP address to reach it on.
• Vehicle data arrives over CAN, but the Linux side never touches the bus directly; its companion MCU does, and hands the values up. Same one-hop-from-CAN pattern as the other modules.
• Display link to the head unit — the head unit feeds one of the cluster's panels over a serialised video link (FPD-Link). Importantly this link is bidirectional: besides carrying video, its back-channel is what the head unit uses to deliver cluster firmware updates (below).

Cluster firmware reaches the module two ways, and neither is over the internet directly — the cluster has no network:

• Over-the-air (field): the TBox pulls the update bundle over cellular, the head unit receives the cluster's part, and pushes it into the cluster over the FPD-Link back-channel as a simple framed, checksummed block transfer. A small updater service on the cluster receives it, verifies it, and installs both the Linux UI part and the companion-MCU part.
• Workshop: the dealer diagnostic tool flashes it the standard way — UDS over CAN through the gateway, behind Security Access. See OBD-II diagnostics.

The update packages are encrypted archives that the cluster unpacks and self-installs at boot. The integrity check inside them is a plain checksum rather than a cryptographic signature.

Because the cluster is a normal (if small) Linux box, it has the usual embedded-Linux entry points — a serial console, a USB interface used by the factory flashing tool, the firmware-update channel described above, and the UDS diagnostic path. Each has been examined and is understood well enough to characterise how the module boots, updates and could be serviced. Details are kept off this page.

<WRAP center round important 60%> This is the driver's instrument cluster — it shows speed, range and safety-critical warning lamps. Anything done here is own-vehicle only and must be validated off-vehicle first; a bad image can leave the cluster with no working UI. </WRAP>

What's understood so far. To be continued.