Четырёхслойная модель#
Любой Sovol в этой базе знаний проще всего понимать как четыре независимых слоя. Каждый можно заменить, не трогая остальные, у каждого своя история бэкапа и отката, и ломается каждый по-своему. Почти каждый болезненный урок здесь ложится ровно на одну границу между слоями — поэтому по слоям же и разложены доки.
| Слой | Что там живёт | Вендорское состояние | Цель на mainline |
|---|---|---|---|
| 1. Железо | Плата хоста, MCU мейнборда, MCU тулхеда, модуль eMMC, проба, камера, экран | как с завода | без изменений — надо только знать причуды |
| 2. Прошивка MCU | Bootloader-ы Katapult + приложения Klipper на MCU | вендорский форк, разнобой версий | один запиненный upstream-коммит везде |
| 3. ОС | то, что грузится с eMMC | переклеенный образ CB1, старый Debian + старое ядро | ванильный Armbian + один dtb-оверлей |
| 4. Приклад | Хост Klipper, Moonraker, UI, crowsnest, экстра — и набор конфигов | вендорский форк + вендорские скрипты | сток upstream через KIAUH + твой конфиг в git |
Три свойства стоит усвоить до того, как что-то трогать.
Слой 2 переживает слой 3. Прошивка MCU живёт в самих MCU, а не на eMMC. Стёртая или заменённая ОС её не касается, а CAN-UUID выводятся из аппаратных ID, так что они стабильны через что угодно. Машина с умершей ОС грузит свежую ОС и находит свои MCU ровно такими, какими они были.
Конфиг слоя 4 — самый волатильный артефакт во всей машине. Блоки калибровки, макросы и saved variables меняются с каждой сессией тюнинга, и живут они на eMMC — слое, который чаще всего перепрошивают. Держи набор конфигов в git-репозитории и пересохраняй после каждой сессии. Это единственный слой, где «восстановить из бэкапа месячной давности» реально больно.
Слой 1 фиксирован, но не молчит. Мёртвый вендорский порт, отсутствующий на поздних юнитах датчик, камера без аппаратного переворота — факты железа ограничивают каждый слой выше. Читай страницы про железо, прежде чем закладываться на фичу, которой у платы может физически не быть.
Какая версия Klipper#
Собирай из текущего Klipper master, а не из релизного тега. Klipper тегается редко — примерно раз в год — а фичи, которые тебе тут реально нужны, прежде всего eddy-проба tap, живут на master уже после последнего тега. Отслеживать master (channel: dev у Moonraker) — нормальная практика Klipper; пин старого тега в основном стоит тебе tap и свежих фиксов. Какой коммит ни возьми — собирай хост и приложение каждого MCU из одного коммита, чтобы совпали словари команд.
Почему такой подход#
Выборы во всех этих доках следуют из нескольких принципов, по порядку:
- Воспроизводимость — всё собрано из запиненных upstream-исходников, так что точную прошивку на машине может пересобрать с нуля кто угодно. Никаких бинарников-загадок.
- Чистый upstream — трекать mainline Klipper без вендорского кода и без тащимых патчей. Целевое состояние — «то, что работает, это чистый upstream», и ребейзить нечего.
- Гигиена цепочки поставки — прошивай только ту прошивку, что собрал из исходников, которые можешь прочитать. Сторонним готовым бинарникам — особенно bootloader-ам — доверия нет; они появляются только как аварийный откат, и то с оговоркой, что ты не знаешь, что внутри.
- Восстанавливаемость — сними свои бэкапы (SWD-дамп, git bundle) до того, как что-то трогать, чтобы твой откат был тем, что ты собрал, а не тем, что скачал.
Бэкап-матрица, которая делает любой путь дешёвым#
| Артефакт | Слой | Меняется | Где хранить |
|---|---|---|---|
Набор конфигов (printer.cfg, saved_variables.cfg, moonraker.conf) | 4 | каждую сессию тюнинга | git, коммит после каждой сессии |
| Пин коммита Klipper + список пакетов venv | 4 | редко | одна строка в заметках |
| Полный образ eMMC | 3 | редко | один dd до любых работ с ОС — не после |
| Бинарники прошивки MCU + SWD-дамп | 2 | редко | вместе с артефактами сборки |
| Ничего | 1 | — | факты железа живут в доках |
Асимметрия — вот урок. Три слоя из четырёх меняются редко и бэкапятся тривиально, а конфиг меняется постоянно и именно его теряют. Положи его в git первым, до любого другого шага любого пути.