В ядре Linux 7.1 начался планомерный демонтаж поддержки процессоров Baikal. Линус Торвальдс уже принял изменения, которые убирают из дерева исходного кода драйверы контроллеров AHCI SATA и PCI Express, используемых в системе‑на‑кристалле Baikal‑T1. Это первые, но далеко не единственные компоненты, от которых ядро постепенно избавляется.
На рассмотрении находятся дополнительные pull‑запросы, предполагающие удаление целой группы связанных с Baikal‑T1 подсистем: драйверов таймера, памяти, physmap, шины, подсистемы мониторинга оборудования (hwmon), контроллеров DesignWare (dwc), а также раннего загрузочного кода bt1‑rom. Фактически речь идёт о зачистке всей специфичной инфраструктуры поддержки SoC BE‑T1000 на базе Baikal‑T1.
Этот процесс стартовал ещё в ветке Linux 7.0, когда из ядра исчезли драйверы i2c и spi dw, ориентированные на Baikal‑T1. Тогда уже было понятно, что платформа не развивается, а кодом практически никто не занимается. Версия 7.1 лишь закрепляет тренд: всё, что относится к российскому SoC Baikal‑T1 и не имеет активного сопровождения, последовательно убирается.
Официальная причина, на которую ссылаются разработчики ядра, - отсутствие поддержки со стороны мейнтейнеров и незавершённая интеграция платформенных компонентов Baikal в основное дерево Linux. Ключевые драйверы так и не были доведены до полноценного, безусловно работоспособного состояния. Отдельно подчёркивается, что драйвер PCIe для Baikal‑T1 долгие годы оставался в подвешенном, "полуэкспериментальном" виде, что неприемлемо для кода, находящегося в основном дереве и формально поддерживаемого.
На этом фоне логичным шагом стало и удаление связанных мейнтейнерских записей. Из списка сопровождающих исключены разработчики, отвечавшие за платформу BAIKAL‑T1, базовые драйверы для систем MIPS и целый набор подсистем Synopsys DesignWare: EDMA, SATA AHCI, APB GPIO, APB SSI и другие. Фактически ядро фиксирует реальность: людей, реально отвечающих за состояние кода под Baikal‑T1, больше нет, а значит, нет и гарантий качества, исправления ошибок и адаптации к новым версиям ядра.
Фон этой истории - прекращение самого аппаратного проекта. Производство чипов Baikal в России было остановлено в ноябре 2025 года из‑за дефицита компонентов и проблем с цепочками поставок. Попытка локализовать производство в Китае фактически захлебнулась ещё в 2022 году. Дополнительным ударом стал финансовый кризис вокруг связанных компаний: структура, через которую велась разработка и продвижение процессоров, в конечном итоге оказалась банкротом. В результате платформа фактически потеряла будущее - как с точки зрения "железа", так и в плане разработки программной поддержки.
Поддержка Baikal‑T1 и созданной на его основе SoC BE‑T1000 впервые появилась в ядре Linux в ветке 5.8. Тогда это подавалось как важный шаг для развития отечественной серверной и встраиваемой экосистемы. Процессор Baikal‑T1 представлял собой систему на кристалле с двумя суперскалярными ядрами P5600 (архитектура MIPS32 r5), работающими на частоте до 1,2 ГГц. В состав чипа входил кэш L2 объёмом 1 МБ, контроллер оперативной памяти DDR3‑1600 с поддержкой ECC, один порт 10‑гигабитного Ethernet, два гигабитных сетевых порта, контроллер PCIe Gen3 x4, два порта SATA 3.0, USB 2.0, интерфейсы GPIO, UART, SPI, I2C.
Архитектурно Baikal‑T1 позиционировался как относительно универсальная платформа для маршрутизаторов, сетевого оборудования, промышленных контроллеров и специализированных встраиваемых решений. Процессор поддерживал аппаратную виртуализацию, набор SIMD‑инструкций, а также оснащался интегрированным криптографическим ускорителем с поддержкой, среди прочего, ГОСТ 28147‑89. При этом базовый вычислительный блок был построен на лицензированном у Imagination Technologies ядре MIPS32 P5600 Warrior - это подчёркивало зависимость проекта от внешних технологий и лицензий.
С точки зрения ядра Linux, уход Baikal‑T1 - типичный пример того, как платформа, не получившая устойчивого рыночного распространения и нормальной инженерной поддержки, рано или поздно вымывается из основного дерева. Правило, по которому живёт ядро, предельно прагматично: если за кодом никто не следит, он устаревает, ломается при каждом крупном рефакторинге и начинает мешать развитию остальных подсистем. В таких случаях удаление - не политический жест, а рутинная работа по санитарной очистке кода.
Для конечных пользователей это означает, что новые версии Linux постепенно перестанут работать на системах с Baikal‑T1 "из коробки". Существующие дистрибутивы со старыми ядрами сохранят функциональность, но по мере устаревания и прекращения поддержки этих версий риски будут расти: от отсутствия исправлений безопасности до несовместимости с современным программным стеком. Владельцы оборудования на Baikal‑T1 окажутся перед выбором: либо "замораживать" инфраструктуру на старых ядрах и дистрибутивах, либо самостоятельно форкать и поддерживать драйверы, беря на себя роль мейнтейнеров.
Технически ничто не мешает сохранять поддержку Baikal‑T1 в виде сторонних патчей или отдельных веток ядра, которые будут поддерживаться производителями оборудования или сообществами энтузиастов. Однако такой подход требует серьёзных ресурсов: нужно отслеживать изменения в основных подсистемах ядра, адаптировать под них код, тестировать работу на реальном железе. Без устойчивой бизнес‑модели или массовой инсталляционной базы такие проекты быстро выдыхаются, что уже не раз происходило с нишевыми архитектурами и специализированными SoC.
Удаление поддержки Baikal‑T1 вписывается в более общий тренд: разработчики ядра регулярно сокращают "зоопарк" устаревших и не сопровождаемых платформ. Под нож идут и старые x86‑совместимые процессоры, и экзотические одноплатные решения, и аппаратные платформы, которые давно не производятся и присутствуют лишь в единичных экземплярах. Это позволяет уменьшить размер и сложность кода, упростить тестирование и сфокусировать усилия на тех архитектурах и контроллерах, которые реально используются и развиваются.
При этом важно различать поддержку архитектуры и поддержку конкретных SoC и драйверов. Архитектура MIPS как таковая из ядра не исчезает, но отдельные реализации - такие, как Baikal‑T1, - могут быть вычищены, если для них нет ни железа в продаже, ни активных разработчиков. Аналогичная судьба может ожидать и другие российские или зарубежные платформы, если они останутся без мейнтейнеров и экономического смысла продолжать их развивать.
Для российской ИТ‑отрасли эта история - показательна. Одного наличия формального "импортазамещённого" процессора недостаточно: критично важно обеспечить долгосрочное сопровождение, стабильное производство и предсказуемую инженерную политику. Без этого поддержка в крупных открытых проектах вроде ядра Linux превращается в временный эпизод. Когда компания прекращает деятельность, производственные линии останавливаются, а ключевые разработчики уходят, экосистема вокруг процессора неизбежно деградирует.
С практической точки зрения, организациям, которые всё ещё используют системы на Baikal‑T1, имеет смысл уже сейчас оценить риски и продумать миграцию. Возможные стратегии - переход на более распространённые архитектуры (x86‑64, ARM, RISC‑V), консолидация парка оборудования, создание внутренних веток ядра с длительной поддержкой или даже перевод критически важных систем в режим "консервации" без попыток обновления. Каждое из этих решений имеет свою цену, но игнорировать факт удаления поддержки из мейнлайна ядра уже нельзя.
Наконец, эта ситуация подчёркивает и ещё один важный момент: включение платформы в основное дерево Linux - не финальная цель, а только начало пути. Поддержка в ядре - это обязательство, требующее постоянной работы. Если производитель процессора или плат локализует усилия лишь на первом этапе - "затащить код в мейнлайн", но не закладывает ресурсы на его многолетнее сопровождение, результат предсказуем. Ядро рано или поздно избавится от мёртвого груза, а пользователи останутся один на один с устаревшей платформой.
