Збирання Core із залежностями Scheduler і LLiMa

Core збирається з двома залежностями: Scheduler і LLiMa. Виконайте build.sh зі своєї робочої копії Core в Palette SDK:

./build.sh --all --no-doc

Типово build.sh:

1. Завантажує з Vulcan опублікований набір Scheduler і пакети LLiMa.
2. Розпаковує набір Scheduler у теку deps/ робочої копії та встановлює LLiMa в sysroot SDK.
3. Збирає Core.

build.sh не встановлює набір Scheduler у sysroot SDK, тому кілька робочих копій Core можуть одночасно збиратися з різними наборами Scheduler в одному контейнері SDK. Вони спільно використовують LLiMa із sysroot: build.sh пропускає встановлення LLiMa, якщо sysroot уже містить ті самі пакети.

Узгодження sysroot SDK з набором Scheduler

Кожен набір Scheduler фіксує версію sysroot, для якої його зібрано. build.sh порівнює її з виводом sysroot status і, якщо вони відрізняються, друкує попередження з точною командою sysroot update. Щоб оновити sysroot у межах збирання, передайте --update-sysroot:

./build.sh --all --no-doc --update-sysroot

Це запускає sudo sysroot update <version> разом з пакетами платформи, з якими компілюється Core. CI завжди передає цей параметр.

Використання локальних пакетів Scheduler або LLiMa

Щоб зібрати Core із власною збіркою Scheduler або LLiMa, передайте теку з її DEB-пакетами:

./build.sh --scheduler ../scheduler-debs --llima ../llima/dist/debs

Кожен параметр працює окремо; іншу залежність build.sh усе одно завантажує. Переданий набір Scheduler замінює опублікований у теці deps/ цієї робочої копії, а передані пакети LLiMa замінюють LLiMa в sysroot SDK.

Тека Scheduler містить повний набір, з яким збирався Scheduler:

• simaai-scheduler
• пакети simaai-runner і simaai-kernels-dev, з якими його зібрано
• відповідний пакет simaai-kernels-firmware для збирань з увімкненим EV
• пару neat-codecs і neat-codecs-dev, якщо Scheduler використовує Codecs
• за потреби simaai-runtime і, для збирань із тестами, simaai-scheduler-client-test-dev

Core не вибирає Kernels, Runner чи Codecs. Щоб перевірити зміну в одному з них, зберіть Scheduler із цією зміною за посібником зі збирання Scheduler, помістіть отримані пакети в одну теку й передайте її через --scheduler. Координатор Scheduler перевіряє, що пакети узгоджені між собою, і зупиняє збирання, якщо це не так.

build.sh завершується помилкою, якщо задано змінну джерела або пакета NEAT_KERNELS_*, NEAT_RUNNER_*, NEAT_SCHEDULER_* чи NEAT_CODECS_*. Щоб зібрати без LLiMa, використайте --no-llima.

Залежності від платформи

Збирайте Kernels, Runner, Scheduler і Core з тим самим SDK і набором інструментів Platform 3.0. Задайте CMAKE_TOOLCHAIN_FILE, якщо вибираєте нестандартний набір інструментів. Записи Kernels і Runner мають узгоджуватися за ціллю, компілятором, контрактами ядер та використаною конфігурацією збирання. Канонічний процес пакування також потребує точної ідентичності використаного вмісту Kernels. Після зміни пакета Kernels перебудуйте пакет Runner із вибраним SDK, навіть якщо джерела Runner не змінилися. Потім Core повторно компонується з відповідною реалізацією клієнта Scheduler; нижчі числові пакети споживає Scheduler. DEB-пакети Core, зібрані насамперед із джерел, фіксують вибрані версії Scheduler і числового SDK. Runner фіксує Kernels; Scheduler — Runner, Kernels і ввімкнений бекенд кодеків. Збирання Core з тестами також потребують окремого пакета Scheduler simaai-scheduler-client-test-dev від того самого виробника, у тій самій теці Scheduler. Координатор перевіряє його запис виробничого збирання, джерела, вміст та архів, перш ніж надати тестовий компонент CMake. Збирання лише середовища виконання не потребують його. Процес формує сумісність simaai-runtime, що містить лише метадані, з точними залежностями Runner і Scheduler. Канонічні пакети володіють файлами без дублювання; лише Runner володіє наявною конфігурацією завантажувача. Завжди встановлюйте повний узгоджений дистрибутив замість заміни одного пакета.

Перенесення володіння заголовками GStreamer

У версії Core 0.6.0 володіння /usr/include/gst/SimaaiGstErrors.h переходить до Scheduler. Шлях включення не змінюється. Core більше не містить власної реалізації й не встановлює цей файл; споживачі використовують встановлені заголовки Scheduler і ціль SimaScheduler::Headers.

Оновлюйте Core і Scheduler разом із повного узгодженого дистрибутива. Scheduler оголошує перенесення заголовка для лінійки пакетів 0.6.0, не позначаючи виправлені пакети Core 0.6.0 як несумісні. Перед зміною файлів через APT інсталятор використовує автентифіковану перевірку володіння Scheduler: попередній пакет-власник має бути замінений у тому самому наборі пакетом без цього файла або підпадати під явно оголошене й схвалене виведення з використання. Дублювання власників у вхідних пакетах і сторонні конфлікти володіння відхиляються.

На Platform 3.0 повний набір розділених пакетів також виводить із використання монолітні neat-runtime, neat-gst-plugins і neat-internals-dev лінійок 0.4, 0.5 та 0.6.0, включно зі збірками для розробки. Для цього нові пакети-власники мають оголосити відповідні Breaks і Replaces з обмеженим діапазоном версій; версії від 0.6.1~ і вище не охоплюються. Це не дозволяє видаляти сторонні пакети й не означає сумісності з виведеними з використання API. Scheduler оголошує передавання файлів середовища виконання та плагінів; повне середовище виконання також потребує відповідного Runner як залежності для виконання. Окреме встановлення Runner не виводить із використання монолітні пакети 0.6.0.

Дистрибутиви Modalix з увімкненим EV потребують відповідного пакета simaai-kernels-firmware, вибраного Scheduler. Відсутня або невідповідна прошивка спричиняє помилку перевірки допуску. Для заміни старого пакета neat-ev74-firmware саме вибраний пакет прошивки має оголосити Replaces та Breaks або Conflicts, що відповідають його версії; звичайні перевірки транзакції та видалення також застосовуються. Для активації прошивки використовується лише єдиний вхідний пакет, який постачає допоміжний засіб активації. Ідентичність установленого пакета, власник допоміжного засобу, права виконання та байти мають відповідати вибраному пакету. Невідповідність вибраного засобу спричиняє помилку інсталяції. Для дистрибутивів, які не потребують прошивки EV74, відсутність такого засобу не змінює наявну прошивку. Інсталятор ніколи не використовує засіб, залишений попередньою інсталяцією.

Якщо встановлення на DevKit перервалося, повторно запустіть повний перевірений дистрибутив. Інсталятор може відновити незавершені пакети лише тоді, коли вони належать до вхідного набору й мають відповідну архітектуру. Відновлення має встановити точні вибрані версії без зміни сторонніх пакетів. Можна видалити лише налаштовані попередні пакети без утримання, виведення яких із використання явно оголошене вхідним набором і схвалене наявними перевірками видалення. Відновлення спочатку завершує схвалений перехід, перевіряє стан пакетів, а потім повторно встановлює кожен вибраний пакет із забороною видалення. Інсталяція вважається успішною лише після цього остаточного перевстановлення. Сторонні порушення стану бази пакетів потребують окремого виправлення: інсталятор не виконує загального відновлення APT і не гарантує відкату.

Не встановлюйте лише DEB Scheduler поверх наявного пакета розробки Core, не використовуйте --force-overwrite і не видаляйте файли, що належать dpkg. Окремий тестовий образ Scheduler не потребує встановленого Core; наявне встановлення Core потребує узгодженого оновлення.

Інкрементне збирання та встановлення

Кожне збирання оновлює вибраний набір Scheduler у deps/scheduler/ і розміщує його пакети в deps/backend/. CMake збирає Core інкрементно; --clean також видаляє збирання Core.

Перед компонуванням координатор залежностей Scheduler звіряє встановлені заголовки ядер із їхнім записом і перевіряє використаний Runner контракт та точний вхід Runner для Scheduler. Перед підготовкою пакетів розгортання він перевіряє відповідність вмісту /usr кожного пакета Debian вибраному встановленому дереву. Старі пакети Internals не вибираються й не завантажуються.

Core використовує встановлений клієнтський компонент SimaScheduler, а не заголовки сусідніх джерел чи нижчі інтерфейси розробки. Ідентичності нижчих компонентів середовища виконання зберігаються в перевіреному наборі залежностей. Згенерований вибір залежностей записується в build/resolved_manifest.json і build/buildinfo.json. Лише повністю завершене збирання переходить до кінцевого встановлення; це не гарантує транзакційного відкату встановлення в SDK чи на пристрій.

Інформація про збирання пакета до налаштування CMake є попередньою. Після компіляції build.sh оновлює її з кешу CMake цього збирання, налаштованого компілятора, цільових заголовків Python і зібраного розширення, перш ніж перевіряти встановлення чи пакувати. Прапорці ABI цільового Python мають відповідати суфіксу розширення; версія Python хоста не використовується. Збирання без Python записують цей профіль без ABI Python.

compatibility.host_sdk описує спостережений випуск SDK хоста збирання; compatibility.target_sdk — вибрані sysroot і компілятор. Відсутній випуск цільового SDK залишається недоступним, навіть якщо випуск SDK хоста відомий. Версія платформи в маніфесті є окремою вимогою сумісності, а не заміною неспостереженої версії SDK. ELXR_SDK_RELEASE_FILE вибирає файл випуску хоста. NEAT_TARGET_SDK_RELEASE_FILE може явно задати файл випуску цілі, але він має узгоджуватися з файлом випуску вибраного sysroot. NEAT_BUILDINFO_TOOLCHAIN зберігає явну відображувану мітку поряд з ідентичністю налаштованого компілятора, а не замість неї.

Перевірка метаданих відхиляє суперечливі sysroot компіляції, заголовки й мітки ABI розширення. Окремі sysroot компіляції та компонування, а також додаткові контексти аргументів, цілі або набору інструментів компілятора CMake цим шляхом метаданих не підтримуються; він завершується помилкою замість повідомлення неперевіреної ідентичності цілі. Вимоги NumPy з маркерами зберігаються дослівно з pyproject.toml, а не зводяться до одного безумовного мінімуму.

Запис джерел використовує фактичний коміт робочої копії та стан її зміненості. Він окремо записує відстежувані зміни та ідентичності неігнорованих невідстежуваних файлів і символічних посилань; ігноровані продукти збирання не є знімком джерел. Сам вихідний файл метаданих виключається з дайджесту невідстежуваного вмісту, щоб уникнути самопосилання. Змінений локальний кандидат не ідентифікується як чистий опублікований артефакт.

Для підготовки лише заголовків залежностей --install-deps-only використовує теку --scheduler або завантажує опублікований набір. Він копіює заголовки без збирання або виконання коду A65/EV. Для нативного аналізу clang-tidy використовуйте scripts/run_cpp_tidy.sh із префіксами вибраного Scheduler і відповідного пакета підтримки тестів. TIDY_INSTALL_DEPS=1 встановлює нативні передумови аналізу хоста. Сценарій безпосередньо використовує їхні публічні експорти CMake, не активуючи й не змінюючи sysroot SDK. Файли реалізації GenAI з LLiMa залишаються поза цим профілем аналізу лише хоста. Сценарій не підставляє довільний пакет LLiMa навколишнього SDK замість залежності вибраного збирання. Збирання лише документації не готують нативні залежності.

Збирання для пристрою EV залишаються окремим ліцензованим процесом. Жодна з цих команд не викликає MetaWare, не замінює прошивку й не кваліфікує її зміну неявно.

Опубліковані залежності CI

Звичайне збирання Vulcan визначає політику Scheduler із deps/manifest.json через sima-cli, а потім завантажує вибраний незмінний випуск. Як і для LLiMa, політика гілки snap спочатку пробує поточну гілку Core. Лише якщо визначення випуску не вдається й індекс опублікованих гілок Scheduler підтверджує відсутність цієї гілки, вона повідомляє про перехід і повторює спробу з develop:latest. Інші помилки пошуку, зокрема недоступний або некоректний індекс гілок, залишаються помилками. Теги snap і явні селектори гілки/коміту не переходять на інший випуск. Отримання для пристрою та PCIe-хоста використовує спільну політику; PCIe --scheduler-spec <commit> також залишається строгим. Помилки завантаження, перевірки, початкового налаштування та підготовки після визначення випуску залишаються помилками. Записи зберігають фактично вибрані гілку та незмінний коміт. tools/ci/acquire_scheduler.py перевіряє хеші видавця перед запуском початкового завантажувача Scheduler. Встановлений координатор Scheduler розподіляє й перевіряє включені архіви Runner, Kernels і Codecs. Core не визначає ці репозиторії незалежно.

Вибраний пакет Scheduler встановлює свою точну політику SDK. В SDK build.sh запускає scripts/ci/prepare_scheduler_sdk.sh, який перевіряє версію sysroot і завантажує точні архіви платформи Runner до deps/ з окремою конфігурацією APT. Він запускає sysroot update лише з --update-sysroot. Координатор перевіряє фактичні версію й ціль GCC14 та ідентичності цільового SDK, а потім вибирає точні архіви постачальників середовища виконання, використані Runner, через NEAT_RUNNER_PLATFORM_RUNTIME_DEBS. Виконувані файли нативного ARM64-компілятора й кроскомпілятора не обов’язково мають бути побайтово ідентичними. Їхній цільовий ABI та вибрана платформа мають збігатися. На цьому кроці нічого не встановлюється на пристрій і прошивка не кваліфікується.

Тека --scheduler ніколи не поєднується із завантаженням і не замінюється ним. Наявна команда tools/ci/materialize_dependencies.py --manifest ... --output-root ... залишається необов’язковим засобом доставки окремо перевіреного незмінного маніфесту. Це не типовий процес, і неявного ci/dependencies.json немає.

Перевірка чистоти коду використовує tools/ci/acquire_scheduler.py, щоб незалежно отримати опублікований Scheduler за тією самою політикою залежностей, не очікуючи на збирання Core. Початкове налаштування Scheduler перевіряє набір пакетів. Аналіз хоста використовує експорти CMake його клієнтської частини та відповідної підтримки тестів без активації SDK або виконання на цільовому пристрої.

Див. Володіння апаратними тестами щодо супервізора на цільовому пристрої, потрібного захищеному шляху перевірки продуктивності.

Перевірка готового дистрибутива

build.sh --all перевіряє готовий дистрибутив після формування метаданих пакетів. scripts/ci/verify_core_dist.sh виконує ту саму перевірку лише для читання в CI, використовуючи середовище Python вибраного sima-cli. Явно задайте SIMA_CLI_PYTHON, якщо інтерпретатор не розміщено поряд із вибраним виконуваним файлом CLI.

Перевірка звіряє байти пакетів залежностей, поля сумісності, список дозволів інсталятора, усі контрольні суми ресурсів, ізоляцію публічного wheel та встановлені дерева CTest. Вона використовує наявні записи виробників, а не визначає чи виправляє залежності. Розрізняйте ці документи:

• dist/manifest.json: сумісність платформи, Model Zoo та ABI.
• dist/resolved-deps-manifest.json: вибраний запис бекенду, скопійований точно.
• build/resolved_manifest.json: повніший результат визначення збирання Core.

Не замінюйте файли й не перераховуйте вибрані контрольні суми після цієї перевірки. Якщо артефакт змінився, перебудуйте метадані та знову перевірте весь дистрибутив.

Явні пакети платформних постачальників

Виробнича публікація рамок і масок Core використовує координати int32. Виберіть Scheduler, зібраний із канонічною візуалізацією Kernels та відповідними API виконання Runner. SIMANEAT_REQUIRE_INT32_RENDERER типово відповідає вимозі артефакту середовища виконання та спричиняє помилку налаштування, якщо встановлений Scheduler не має цієї можливості. Задавайте OFF лише для профілю Core, який не використовує візуалізацію рамок або масок Core.

Візуалізація використовує вибрані пакети Kernels/Runner, а не окремий архів платформного засобу візуалізації. Для ревізії 2 API запитів перебудуйте весь набір компонентів разом.

В SDK build.sh задає наведене нижче через scripts/ci/prepare_scheduler_sdk.sh. Поза SDK надайте:

• NEAT_RUNNER_PLATFORM_RUNTIME_DEBS: JSON-масив абсолютних шляхів до точних DEB-пакетів постачальників середовища виконання, вибраних Runner. Включіть обов’язковий архів середовища виконання SimaHeap, а також архіви середовищ виконання MLA й TVM, якщо ці бекенди ввімкнено. Не включайте до цього масиву архіви розробки. Runner перевіряє фактичні назви завантажувача й байти бібліотек. Scheduler зберігає точні ідентичності архівів та переліки вмісту як докази збирання. Постачальники, які Runner оголосив власністю Platform, залишаються поза набором встановлюваних DEB Core; неоголошені постачальники зберігають точне включення архівів.

Цей вибір залишається явним і з текою --scheduler. Незмінний матеріалізатор чотирьох компонентів не завантажує архіви платформних постачальників. Отримайте їх у підтримуваного виробника перед викликом Core; відсутні або невикористані постачальники спричиняють помилку замість резервного вибору із sysroot. Для компіляції використовуйте відповідні пакети розробки. На DevKit автентифікований засіб допуску Scheduler перевіряє встановлених постачальників Platform щодо вхідних споживачів перед зміною пакетів. Інсталятор відхиляє плани APT, які замінюють або видаляють цих постачальників, а потім перевіряє їхню ідентичність і повний набір залежностей встановлених споживачів. FORCE_INSTALL не скасовує ці перевірки. Не перебудовуйте DEB лише для позначення приватної DSO як випущеного постачальника.

Формування пакета перевіряє неперекривне володіння вмістом, точні версії залежностей і незмінені архіви. Ці перевірки під час збирання не кваліфікують числове виконання, динамічні маски чи апаратне завершення. Для цього потрібні відповідні інтеграційні тести на вибраному цільовому наборі компонентів.