# Контракт: железо и board-support

> Целевой таргет, топология питания, периферия — и **HAL/BSP** для портирования под
> другое железо/авто (то самое «API для автопроизводителей/автолюбителей» из vision).

Статус: **v1 (на ревью).**
Связано с: [architecture.md](../architecture.md) · [dev-environment.md](../dev-environment.md) · [data-model.md](data-model.md) (§7 DBC) · [security-privacy.md](security-privacy.md) (якорь доверия) · домены A/B/E/J/K

---

## 1. Целевой SoC

**RK3588 / RK3588S класс, 8–16 ГБ RAM.** Почему: приличная mainline-Linux-поддержка,
Panfrost GPU, мощности хватает на плавный UI и **локальную мелкую LLM**; это же класс
реальных автоголов.

## 2. Хранилище

- **eMMC** — rootfs, **read-only**.
- **Раздел `/data`** (SD/eMMC) — read-write, **журналируемый**.
- Прямое следствие power-safe (принцип #5): запись только в `/data`.

## 3. Питание (критично) — power-safe by design

- **Управляемый power-path:** питание устройства коммутируется по зажиганию.
- **Детект ACC/зажигания** — через GPIO (12 В → level-shift).
- **Автомобильная защита входа:** широкодиапазонный DC-DC + защита от **load-dump,
  транзиентов и переплюсовки** (бортовые 12 В грязные — скачки до 40+ В).
- **Hold-up энергия** для graceful shutdown при резком пропадании 12 В.
- **Secure boot** (verified boot RK3588) — **якорь доверия first-party** (из
  [security-privacy.md](security-privacy.md): first-party = вшит в подписанный образ).
  Подпись OTA — домен A.

🟡 **Выбор hold-up механизма:**
- **(рек.) MCU-копилот** — маленький always-on МК: мониторит зажигание, сигналит SoC
  «выключайся» по ACC-off, держит watchdog, управляет power-sequencing и sleep/wake.
  + конденсатор/supercap на пару секунд для флаша и размонтирования.
- **(проще)** только supercap — буфер энергии без логики (детект ACC — на SoC-GPIO).

Рекомендую MCU-копилот: он же закрывает watchdog и пробуждение. (Прошивка МК — домен B.)

## 4. Периферия

| Узел | Старт | Прод / позже |
|------|-------|--------------|
| **Дисплей** | HDMI + USB-тачскрин | MIPI-DSI / LVDS панель |
| **CAN/OBD** | ELM327 (USB/BT) | нативный CAN-трансивер → **SocketCAN** |
| **GPS** | USB/UART, NMEA | — |
| **Связь** | USB-модем (ModemManager) / Wi-Fi | — |
| **Аудио** | I2S codec + усилитель | — |
| **Микрофон** | USB **mic-массив** (wake-word, шумоподавление) | — |
| **Камеры** | задняя (CVBS capture-чип + драйвер, фаза 2) | dashcam / surround (задел, домен J) |
| **Мультируль** | кнопки руля: чтение с CAN **или** ADC (резистивная лесенка) | — |

**Два пути чтения и точный смысл «read-only»:**
- **Пассивный сниффинг (listen-only):** CAN-контроллер в silent-режиме — физически
  не передаёт и не шлёт ACK; читаем broadcast-кадры машины (нужен DBC). Ноль TX.
- **OBD-II поллинг:** чтобы прочитать DTC и PID, протокол **требует отправить
  кадр-запрос** (Mode 01/03/07/09). Это НЕ listen-only — мы передаём, но **только
  стандартные диагностические read-запросы**.

**Red-line (принцип #2):** запрещены **управляющие/actuator-команды, запись в ECU,
сброс DTC (Mode 04), UDS-write** — любые *state-changing* передачи. Безобидные
read-запросы OBD-II разрешены (без них не прочитать ошибки). Чистый listen-only —
только для пассивного пути.

## 5. HAL / board-support (портирование)

**HAL абстрагирует железо-специфичное**, чтобы платформа переносилась на другие
платы/авто:

- Power/зажигание (карта GPIO + протокол MCU-копилота).
- CAN (контроллер + listen-only).
- Дисплей (тип панели + тач), аудио (codec/усилитель/маршрутизация).
- GPS-источник, захват камер, карта ввода мультируля.

**BSP (board-support package)** = device tree (overlay) + конфиг HAL + **per-vehicle
DBC/маппинг сигналов** (см. [data-model.md](data-model.md) §7).

**Порт = новый BSP.** Это и есть «API под конкретное железо/авто» из vision:
автопроизводитель/энтузиаст поставляет BSP, ядро не трогается.

## 6. Первый таргет vs портируемость

- **Один reference-таргет доводим end-to-end** (vision: не «любое железо из коробки»).
  Портируемость — силами других через BSP/HAL.
- 🟡 **Выбор конкретной платы — отложен** (решение по доступности/цене). Кандидаты:
  Radxa Rock 5B / 5B+, Orange Pi 5 / 5 Plus, Khadas Edge2 — критерии: mainline-поддержка,
  доступность (в т.ч. в РФ), цена, IO (CAN-способные пины).

---

## Открытые вопросы (→ роутинг)

- 🟡 **Выбор reference-платы** — procurement-решение (доступность/цена в РФ). → отдельно.
- ◻️ **Прошивка MCU-копилота** (детект ACC, sequencing, watchdog, протокол к SoC). → домен B.
- ◻️ **Ранний путь задней камеры** (Stage 0 boot) — аппаратная сторона. → домен J + B.
- 🟡 **Подписанные OTA** (вторая половина цепочки доверия; secure boot закрыт здесь). → домен A.
- ◻️ **Тепловой режим:** RK3588 в горячем салоне/закрытом корпусе — радиатор, throttling. → домен A.
- ◻️ **Износ eMMC/SD** при записи (логи/трипы/телеметрия) — минимизация записи, особенно на SD. → домен A/B.

---

## Журнал решений (hardware)

| Решение | Выбор | Дата |
|---------|-------|------|
| SoC | RK3588/RK3588S класс, 8–16 ГБ | 2026-06-16 |
| Хранилище | eMMC RO rootfs + журналируемый `/data` | 2026-06-16 |
| Hold-up питания | MCU-копилот + cap (🟡); supercap-only — проще | 2026-06-16 |
| CAN | пассивный listen-only + OBD read-запросы (без state-changing TX); ELM327 на старте | 2026-06-16 |
| Доверие | secure boot анкорит first-party; подпись OTA — домен A | 2026-06-16 |
| Портируемость | HAL + BSP; один reference-таргет first-party | 2026-06-16 |