X1Plus-RU

Инструкции по установке

Добро пожаловать в X1Plus! Если вы пользователь, вы, вероятно, захотите сразу перейти на вики , где рассказывается все, что вам нужно знать об установке и использовании X1Plus на вашем принтере. Остальная часть этого файла содержит скучные вещи для действительно больших ботаников, которые хотят разработать X1Plus. The rest of this file has boring stuff for really big nerds who want to develop X1Plus.

Инструкции по разработке

Хорошо, не говорите, что я вас не предупреждал. В любом случае, привет! Рад, что вы заинтересованы в участии в X1Plus! Вот куча информации о том, как его построить, как он структурирован внутри, а также различные вещи, которые вам, возможно, понадобится знать о том, как вносить изменения и как вносить свой вклад. X1Plus — результат года или около того нечетко структурированной работы; он начал свою жизнь как довольно грубый хак, и в течение последних нескольких месяцев мы усердно работали, пытаясь очистить его и выпустить во внешний мир. Тем не менее, некоторые детали все еще находятся в беспорядке, и нам очень жаль! Мы надеемся, что вы все равно поиграетесь с этим. Нам предстоит сделать много интересного, и мы пока лишь слегка коснулись поверхности.

Как мне начать?

Вероятно, самый простой способ начать сборку X1Plus — использовать контейнер Docker. Если вы любите приключения, вы, вероятно, сможете собрать X1Plus на любой старой машине с Linux (я так и делаю), но если вы сделаете это, и он сломается, мы действительно не хотим об этом слышать, поэтому вам действительно следует просто собрать его в Docker. . Для сборки X1Plus вам понадобится ключ дешифрования файловой системы от работающего принтера (на котором работает X1Plus или официальная корневая прошивка); попробуйте что-то вроде:

$ git clone ...
$ cd X1Plus
$ docker build -t x1plusbuild scripts/docker/
$ docker run -u `id -u` -v `pwd`:/work x1plusbuild bash -c 'git config --global --add safe.directory /work'
$ docker run -u `id -u` -v `pwd`:/work x1plusbuild make scripts
$ scp scripts/getkey root@bambu:/tmp
$ ssh root@bambu /tmp/getkey >> localconfig.mk
$ docker run -u `id -u` -v `pwd`:/work x1plusbuild make

Если повезет, вы должны получить .x1p файл в своем рабочем каталоге! Вы можете скопировать это на свою SD-карту ( scp она поверх — никогда не извлекайте SD-карту из работающей системы X1Plus, дурак), перезагрузить принтер и установить ее из меню.

Если вы собираетесь внести изменения в какой-либо файл пользовательского интерфейса, вам обязательно следует прочитать остальную часть этого документа... иначе в следующий раз вас может ожидать неприятный сюрприз git pull.

Как работает X1Plus с точки зрения принтера?

Основная концепция X1Plus заключается в том, что мы создаем оверлей поверх прошивки Bambu Lab и заменяем только те части, которые нам нужны для запуска X1Plus. Мы очень осторожны и не распространяем напрямую какую-либо интеллектуальную собственность Bambu Lab; когда необходимо использовать или исправлять двоичные файлы Bambu Lab, мы загружаем их непосредственно с серверов Bambu Lab, а затем исправляем их на принтере. Мы также стараемся быть очень осторожными и оставлять принтер в «отказоустойчивом» состоянии, изменяя как можно меньше флэш-памяти принтера. Ниже приведен пример работы X1Plus: от установки до обычной загрузки.

Установщик на стороне хоста. Установщик на стороне хоста — это приложение Electron, в котором реализована вся логика проверки того, работает ли на принтере поддерживаемая версия базовой прошивки, а также механизм входа в принтер через MQTT, FTP и SSH. (В разрабатываемых версиях X1Plus, для установки которых требовались эксплойты, установщик на стороне ПК был несколько сложнее!) Примерно это реализовано в installer-clientside/install-gui/src/index.ts.

Установщик копирует .x1p образ на SD-карту, а также небольшой архив, содержащий заглушку графического интерфейса установки на принтере. Он подключается к принтеру по SSH, распаковывает архив /userdata на принтере и запускает сценарий запуска установщика первого этапа, который он (надеюсь) распаковал; затем он ожидает сообщений MQTT, указывающих ход установки.

Скрипты установки первого этапа. Программа установки первого этапа (реализованная в installer-clientside/stage1/x1plus/launch.sh) сначала отключает программу проверки обслуживания принтера (в противном случае графический интерфейс будет перезапущен!), а затем закрывает графический интерфейс. Он добавляет маркер для установщика на стороне хоста, чтобы указать, что он запустился, а затем перезапускает механизм графического интерфейса принтера с внедренным в него графическим интерфейсом настройки X1Plus, чтобы заменить обычный графический интерфейс принтера.

Графический интерфейс настройки X1Plus. Точный механизм, с помощью которого мы внедряем код в графический интерфейс, интересен, но обсуждать его именно сейчас мы несколько забегаем вперед :) Я расскажу об этом через минуту. На данный момент все, что вам действительно нужно знать, это то, что это реализовано в QML в bbl_screen-patch/kexec_ui/printerui/qml/Screen.qml качестве начального элемента (родные компоненты C++ находятся в файлах bbl_screen-patch/interpose.cpp). Как можно догадаться по названию, этот графический интерфейс также является частью процесса загрузки X1Plus, но установщик первого этапа запускает его таким образом, что графический интерфейс переходит прямо на экран установщика. Механизм установки SelectX1pPage ищет .x1p изображения на SD-карте и спрашивает пользователя, какое из них x1pустановить. (An x1p — это просто zip-файл, в котором есть символы info.jsonи payload.tar.gz.) Как только пользователь выбирает x1p файл, InstallingPageраспаковывает его payload.tar.gz в /userdata, вызывает серверную часть установки на основе Python и начинает прослушивать сообщения DDS с обновлениями статуса. (DDS — это внутренняя шина сообщений pubsub.)

Серверная часть установки Python. Механизм работы установщика Python, вероятно, лучше понять, прочитав его код, который находится в формате installer/install.py. Мы помещаем предварительно скомпилированную версию Python в систему /userdata и для связи с шиной сообщений DDS используем ctypes системные библиотеки DDS. Грубо говоря, установщик Python:

• проверяет, известно ли и совместимо ли дерево устройств принтера;
• резервное копирование нескольких объектов конфигурации принтера на SD-карту;
• скачивает оригинальную прошивку с сайта Bambu Lab;
• расшифровывает и распаковывает его, распаковывает образ файловой системы ext2, а затем переупаковывает эту файловую систему как squshfs на SD-карте;
• создает файл обратной связи ext4 на SD-карте;
• копирует оверлей sqashfs и ядро ​​на SD-карту;
• записывает заглушку загрузчика во внутреннюю файловую систему принтера;
• и сообщает об успехе, и предлагает перезагрузиться.

(Подробную информацию о каждом из них можно прочитать в самом установщике Python.) По завершении установки принтер перезагружается в слегка измененную внутреннюю файловую систему.

При загрузке: проверка SD-карты и отображение графического интерфейса. Когда принтер включается, он сначала загружается со встроенной установкой eMMC, как обычно. Мы внедряем в него скрипт оболочки /etc/init.d/S75kexec, который впоследствии запускает /opt/kexec/check_kexec. (Оба этих сценария находятся в internal-fs/этом дереве.) Этот сценарий проверяет «аварийное отключение» (включается нажатием и удержанием кнопок POWER и ESTOP при включении принтера), и если эти кнопки нажаты, он завершает работу так же быстро, как возможно вернуть управление внутренней прошивке принтера. В противном случае он запускает тот же графический интерфейс, который использовался в процессе установки X1Plus выше, и предлагает либо загрузить прошивку SD-карты, либо запустить дополнительные параметры. (Поскольку он был запущен в ходе фактического процесса загрузки, dialog/KexecDialog вместо него отображается SelectX1pPage.) Если пользователь выбирает загрузку с SD-карты, /opt/kexec/boot запускается сценарий оболочки и готовится загрузить принтер в новое ядро.

Переход в новый мир. Здесь все начинает становиться странным, и очень быстро. Конечным результатом этого этапа является то, что мы собираемся перезагрузить принтер в специально скомпилированное ядро. Процесс этого довольно необычен; поскольку мы не можем убедить загрузчик первого этапа системы выполнить наши указания (ядро подписано с этой точки зрения), нам необходимо выполнить горячую перезагрузку. Для этого мы выполняем следующие шаги.

• Во-первых, мы хешируем дерево устройств работающего ядра (или, по крайней мере, его ключи, которые нас интересуют), чтобы убедиться, что у нас есть подходящее дерево устройств для ядра, к которому мы собираемся перейти. У нас есть несколько измененное дерево устройств; поскольку мы хотим внести исправления в серийный номер принтера и тому подобные вещи, мы компилируем его во время выполнения, используя файл, dtc который есть на принтере. (При этом также выбираются правильные включения, чтобы убедиться, что мы освещаем правильную одну из четырех возможных ЖК-панелей, которые могут быть в комплекте с принтером.)
• Мы подготавливаем несколько других параметров для нового ядра и его пользовательского пространства, включая то, что, по нашему мнению, представляет собой серийный номер принтера, и какие файловые системы мы хотим смонтировать, когда снова запустимся.
• Теперь мы начинаем проявлять немного творчества. Мы хотим использовать , но в kexecядре Bambu Lab его нет ; kexec Хуже того, kexecноминально он доступен только в виде скомпилированной опции, поэтому мы не можем скомпилировать для него модуль из исходников ядра. К счастью для нас, была серия попыток осуществить эту работу — сначала Амонакова kexec-module , а затем Фабианишера kexec-mod-arm64 ! Мы развиваем эту работу в kexec-mod/, где портируем этот модуль ядра на ARM32. Большая часть SoC Rockchip ужасно злится при горячей перезагрузке; мы очень тщательно сбрасываем большие фрагменты состояния SoC в kexec-mod/kernel/arch/arm/machine_kexec_drv.c. Чтобы получить доступ ко многим нужным нам символам, даже если они не являются EXPORT_SYMBOL, мы загружаемся с ними kallsyms_lookup_name(которые мы, хм, получаем из /proc/kallsyms).
• Мы загружаем ядро ​​с SD-карты, загружаем наше скомпилированное дерево устройств, загружаем initramfs с SD-карты и затем делаем kexecсвое дело; мы уходим, плывя в Новый Свет.

Настройка оверлеев в initramfs. После загрузки нового ядра первым выполняемым кодом пользовательского пространства является initramfs, причем init представляет собой сценарий оболочки, который, как ни странно, находится в initramfs/init. Мы начнем с рисования симпатичного логотипа и установки более крупного шрифта на экране. Тогда, грубо говоря, мы:

• Подключите SD-карту. Это должна быть FAT32; с особенно медленными SD-картами перечисление может занять некоторое время.
• Смонтируйте каждый из базовых слоев. Во время компиляции и установки мы создаем несколько сквош-файлов: базовый образ Bambu Lab, наложение пользовательской прошивки и наложение патча графического интерфейса.
• Подключите постоянный слой оверлейного хранилища, который представляет собой ext4fs, который находится в файле в разделе FAT32.
• Создайте наложение, которое объединит каждый из них в один корневой раздел. Прикрепите накладку по мере необходимости, а затем...
• Перенесите управление на «реальный» init процесс.

На момент init получения управления файловая система выглядит так:

/             # Combined root filesystem, including all layers.
/mnt/sdcard   # SD card mount moved to be a subtree of the new root.
/mnt/rootfs   # Access to the "real" root filesystem, so that kernel drivers can see it if needed.
/mnt/overlay  # tmpfs containing individual overlay layers, including:
/mnt/overlay/00.00.28.55.squashfs    # Repacked Bambu base filesystem
/mnt/overlay/1.0.squashfs            # Precompiled X1Plus filesystem
/mnt/overlay/bbl_screen-1.0.squashfs # Patched bbl_screen image

**Загрузка ОС. Загрузка ОС в основном ничем не примечательна, но мы переопределяем некоторые компоненты базовой системы. Посмотрите images/cfw/etc/init.d/ на фрагменты, которые мы переопределяем.

**Запускаем исправленный GUI. Вот еще одна «интересная и креативная» часть X1Plus: как мы исправляем графический интерфейс. Наша общая цель состоит в том, чтобы распространять как можно меньше интеллектуальной собственности Bambu Lab и вместо этого распространять только наши собственные модификации. Механика всего этого обрабатывается bbl_screen-patch/, который в конечном итоге выдает файл printer_ui.so , который попадает LD_PRELOAD в bbl_screen. Вот приблизительный процесс от начала до конца того, как это происходит; большая часть этого происходит во время сборки:

• Начнем с извлечения всех ресурсов Qt из исходного файла bbl_screen. Мы делаем это, статически просматривая все сайты вызовов qInitResources, а затем используя Unicorn Engine для эмуляции инструкций, ведущих к ним. Как только мы узнаем аргументы для каждого вызова qInitResources, мы узнаем расположение каждого пакета ресурсов в памяти и проходим по иерархии пакетов ресурсов Qt, чтобы извлечь каждый пакет в составляющие его файлы, а root.qrcзатем можно использовать его для перекомпиляции ресурса. пучок. Все это происходит в extract_qrc.py.
• Распаковав пакет ресурсов в printer_ui-orig каталог, мы копируем его в новый каталог и применяем все исправления в папке patches/, используя patcher.py. Это создаст printer_ui/ наш новый пакет графического интерфейса.
• Затем мы компилируем пакет ресурсов с помощью rcc. Мы также скомпилируем интерпозер, который перехватит соответствующий вызов qInitResources и заменит его нашим пакетом ресурсов, а также добавим несколько других полезных классов C++; это живет в interpose.cpp, что, по крайней мере, слегка комментируется. Все это объединяется в файл printer_ui.so.
• Поскольку printer_ui.so в нем содержится значительное количество оригинальной IP-адреса Bambu Lab, мы не хотим распространять его напрямую; вместо этого мы распространяем xdeltaзакодированный патч из исходного файла bbl_screen, который мы собираем printer_ui.so во время установки.

Наконец-то у вас есть красивая заставка X1Plus!

Как работает система сборки X1Plus?

Это, вероятно, требует более подробного обсуждения, но, короче говоря, вы должны быть в состоянии просто make. Я бы описал это лучше, но это действительно очень неловко. Приложение-установщик Electron на самом деле еще не интегрировано в систему сборки, и если вы собираетесь взломать его, вам, вероятно, следует спросить об этом, если вы уже не можете его расшифровать.

Следует подумать о том, что по умолчанию каталог bbl_screen-patch/Makefile будет перезаписан , printer_ui если он считает, что patches каталог изменился. Это здорово, если вы просто создаете код из git, но если вы на самом деле пытаетесь внести изменения в файл printer_ui, это довольно удивительное поведение. Чтобы избежать этого, вы можете добавить NO_AUTO_PATCH=yes свой localconfig.mk.

Вы почти наверняка захотите создать Docker.

Как я могу внести свой вклад?

К лучшему или к худшему, большую часть обсуждения разработки мы проводим в Discord. Из-за того, что объединять патчи очень сложно printer_ui, пожалуйста, сообщите другим людям, над чем вы работаете!

Мы работаем с запросами на включение и отчетами об ошибках на GitHub. Пожалуйста, зарезервируйте отчеты об ошибках для фактически отсортированных (или, если не отсортированных, то поддающихся сортировке) ошибок; Если у вас есть вопросы по использованию, задавайте их в «Обсуждениях»!

Пожалуйста, будьте разумными людьми друг к другу. Это всего лишь 3D-принтер. Если у вас возникла проблема, поговорите с кем-нибудь из сопровождающих, и мы постараемся помочь вам ее решить.

Кто такой X1Plus?

X1Plus был написан небольшим количеством людей, не все из которых хотели бы быть публично идентифицированы. В коде вы можете увидеть несколько имен людей, которые не против поделиться своей личностью, но за кулисами было гораздо больше людей, которые со временем внесли свой вклад!

Разные вещи

Наверное, это следовало бы разместить на вики-странице, но, знаете, мы здесь.

Сборка ядра

На момент написания статьи нет необходимости собирать образ ядра самостоятельно, поскольку он присутствует в формате prebuilt. Но вы можете! Это может быть желательно для включения других функций ядра для разработки или для сборки модуля ядра.

• Установите предварительные требования, в том числе lz4для сжатия конечного образа.
• Установите соответствующую цепочку инструментов.
• Загрузите последний исходный код ядра из нашего репозитория .
• Убедитесь, что цепочка инструментов находится в вашем PATH, и добавьте LDFLAGS/CCFLAGS, чтобы указать на цепочку инструментов (не уверен, насколько это необходимо):

  export LDFLAGS="-L$TOOLCHAIN/gcc/linux-x86/arm/gcc-linaro-6.3.1-2017.05-x86_64_arm-linux-gnueabihf \
  -Larm-linux-gnueabihf/libc/usr/lib/ -L/usr/arm-linux-gnueabihf/lib/"
  export CCFLAGS="-I$TOOLCHAIN/include -I/usr/include"
  

• Из корня папки ядра запуститеmake ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build x1plus_defconfig
• Пеереходим make mrproper
• диск build
• Переходим sed -i 's/YYLTYPE yylloc/extern YYLTYPE yylloc/'./scripts/dtc/dtc-lexer.lex.c
• Запускаем make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- zImage сборку ядра.
  • Вероятно, вы захотите добавить -jn количество nдоступных вам потоков (логических ядер), чтобы значительно ускорить сборку (использование всех потоков может замедлить работу ОС).
  • Создайте выходной файл: arch/arm/boot/zImage вы можете скопировать его prebuilt/kernel, чтобы использовать с этим репозиторием.