Четырёхслойная модель#

Любой Sovol в этой базе знаний проще всего понимать как четыре независимых слоя. Каждый можно заменить, не трогая остальные, у каждого своя история бэкапа и отката, и ломается каждый по-своему. Почти каждый болезненный урок здесь ложится ровно на одну границу между слоями — поэтому по слоям же и разложены доки.

СлойЧто там живётВендорское состояниеЦель на mainline
1. ЖелезоПлата хоста, MCU мейнборда, MCU тулхеда, модуль eMMC, проба, камера, экранкак с заводабез изменений — надо только знать причуды
2. Прошивка MCUBootloader-ы 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 + список пакетов venv4редкоодна строка в заметках
Полный образ eMMC3редкоодин dd до любых работ с ОС — не после
Бинарники прошивки MCU + SWD-дамп2редковместе с артефактами сборки
Ничего1факты железа живут в доках

Асимметрия — вот урок. Три слоя из четырёх меняются редко и бэкапятся тривиально, а конфиг меняется постоянно и именно его теряют. Положи его в git первым, до любого другого шага любого пути.