====== Instrument cluster (IP) ====== 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|Architecture]] for where it sits. {{ :ip_cluster.png?900 |Instrument cluster — internal architecture }} ===== System ===== The cluster is a small **embedded Linux computer** paired with a safety microcontroller — the same "big SoC + guardian MCU" split used by the [[:hardware|head unit]] and the [[hardware:tbox|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. ===== How it connects ===== 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). ===== Firmware & updates ===== Cluster firmware reaches the module two ways, and **neither is over the internet directly** — the cluster has no network: * **Over-the-air (field):** the [[hardware:tbox|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 [[:obd2|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. ===== Access surfaces ===== 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. 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. ===== Firmware versions seen ===== ^ Part number ^ Region ^ Vehicle SW ^ | ''861921104C'' | EU | 1.3.0 | | ''861821104B'' | CH | 1.3.0 | | ''861921104B'' | CH | 1.6.1 | | ''861921104D'' | CH | 1.7.1 / 1.7.2 | //What's understood so far. To be continued.//