Files

T

kk0t9 231a64300d docs(domain A): v2 после adversarial-ревью (24 находки) + кросс-док

Существенная переработка base-system по итогам multi-agent ревью:
- A/B-единица = весь boot-юнит (kernel+dtb+initramfs+rootfs) на слот; загрузчик вне A/B
- bootcount/bootlimit + mark-good (Shell-кадр) — иначе откат не срабатывает
- overlay upper/work на tmpfs; персист только через /data
- ФС /data: f2fs(рек)/ext4 + power-safe mount + durable-write (fsync/rename)
- at-rest шифрование /data (fscrypt, eFuse-bound, v4)
- watchdog: SoC+MCU разведены, вооружён в boot-окне, единственный владелец
- boot-порядок исправлен под architecture §6 (splash в Stage 0, ядро в Stage 1)
- secure boot = OTP-eFuse необратим + key-mgmt (не «мягкий переключатель»)
- НОВОЕ: время (RTC/NTP/GPS, TLS-gating), память (zram/OOM/cgroup), логи
  (journald volatile + критичное в /data + pstore), first-boot, factory-reset, локаль
- OTA: A=механизм/подпись, L=канал; verified-boot в бюджете boot; SD-тир; образ v0≠v4

Кросс-док: roadmap (образ v4 = флешируемый релиз), hardware (тепло/eMMC ✅ резолв),
security-privacy (at-rest шифрование как открытый→направлен в A §3).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-20 21:12:35 +03:00

7.8 KiB

Raw Blame History

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

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

Статус: v1 (на ревью). Связано с: architecture.md · dev-environment.md · data-model.md (§7 DBC) · 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: 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 §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.
✅ Тепловой режим → резолв в a-base-system.md §10 (мониторинг SoC + throttling; радиатор/корпус — hardware).
✅ Износ eMMC/SD → резолв в a-base-system.md §9–§10 (journald volatile, tmpfs, zram вместо swap, write-minimization).

Журнал решений (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

7.8 KiB Raw Blame History Unescape Escape