Чому BIOS має стати текстом: як я перетворив HDMI-відеосигнал на SSH-термінал і створив власний КВМ

В епоху Cloud Native та Infrastructure as Code один рівень обчислень досі залишається напрочуд аналоговим і майже не піддається автоматизації. Це момент до завантаження операційної системи — фаза Pre-OS.

Сучасна інфраструктура будується на спостережуваності (observability): логи, метрики, трейси. Але вся ця модель руйнується рівно в той момент, коли ядро ще не завантажене. У фазі Pre-OS спостережуваність колапсує в набір пікселів на моніторі.

Проблема курки та яйця: «Просто використовуй Serial Console»

Коли я розповідаю про аналіз відеовиходу BIOS, досвідчені інженери часто кажуть:

«Навіщо ці складнощі? Просто використовуй Serial-over-LAN або IPMI/Redfish».

На enterprise-обладнанні ці інструменти справді безцінні — коли вони працюють. Але на практиці serial-консоль часто виявляється вторинним механізмом, який залежить від того, що він покликаний замінити: відеовиходу.

Я неодноразово стикався з класичним сценарієм: встановлення стандартного Debian netinst ISO на чисту машину, маючи доступ лише через serial. Я перезавантажую сервер, очікуючи побачити меню інсталятора — і замість цього отримую тишу.

Причина проста. За замовчуванням інсталятор виводить інтерфейс у VGA. Вивід у serial вимкнений, доки я явно не передам console=ttyS0. Але щоб увімкнути serial, мені потрібно взаємодіяти з меню завантаження, яке зараз відображається лише на відеовиході, якого я не бачу.

Щоб змусити serial працювати, мені спочатку потрібен доступ до відео. Це класична проблема курки та яйця. Якщо BIOS скинутий або використовується стандартний ISO — текстові інструменти знову замовкають. Відео залишається єдиним джерелом істини, яке є завжди.

Моє рішення: перетворення відео на потік даних

Це не відеострім BIOS. Це текстовий інтерфейс BIOS, переданий через SSH.

Це не відеопотік BIOS. Це BIOS, декодований у текст і доступний через SSH.  

Я підійшов до проблеми радикально інакше. Замість того щоб просто транслювати зображення екрана, як це роблять класичні IP-KVM, я вирішив декодувати сам інтерфейс.

Так з’явився пристрій USBridge. Він захоплює «сирий» відеосигнал Pre-OS, обробляє його покадрово в реальному часі й перетворює не на відео, а на живий структурований текстовий інтерфейс, доступний по SSH.

Це принципово не OCR. І ось чому.

Чому OCR тут не працює

Класичний OCR — це ймовірнісний процес. Він ресурсоємний, повільний і, що найгірше, може помилятися: плутати 8 і B, 0 і O. В адмініструванні інфраструктури такі помилки неприпустимі. Неможливо «вгадувати» UUID диска або параметри RAID-контролера.

Підхід BIOS-to-Text базується на тому, що BIOS і текстові UEFI — це детерміновані інтерфейси. Символи формуються з фіксованих бітових патернів, їхні координати стабільні, а структура екрану передбачувана.

Фактично BIOS — це цифровий текст, закодований в аналоговому відеосигналі. Завдання полягало не в «розпізнаванні», а в точному декодуванні.

Архітектура пайплайну (under the hood)

В якості апаратної платформи використовується SoC Rockchip RK3566 з чотирма ядрами ARM Cortex-A55. Увесь процес перетворення виглядає так:

1. Raw Capture (захоплення відеосигналу)

Захоплення відеосигналу через HDMI-to-USB (UVC). Для текстових режимів оптимальним виявився режим 800×600, який забезпечує стабільну текстову розмітку екрану.

2. Signal Normalization & Structure Analysis

Відеосигнал приводиться до уніфікованого вигляду, після чого з нього відновлюється координатна модель екрану. Це дозволяє перейти від пікселів до структурованого текстового представлення — без використання OCR.

3. Glyph Resolution

Кожен символ представляється у вигляді нормалізованого бітового патерна та хешується. Якщо такий патерн уже зустрічався — відповідний символ миттєво береться з кешу. Це забезпечує високу швидкість і повну відсутність «мерехтіння» тексту.

4. SSH Text Renderer

На виході формується не відеопотік, а стандартні ANSI escape-послідовності. Користувач підключається по SSH і бачить звичайний текстовий термінал.

Що це дає на практиці

Підключаючись до KVM по SSH, ви не дивитеся на картинку — ви працюєте з текстом.

Copy & Paste

Можна виділяти мишкою повідомлення Kernel Panic, MAC-адреси або UUID дисків прямо з екрана BIOS і копіювати їх у тікет або чат.

Low Bandwidth

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

Automation-First

Оскільки екран представлений як структурований текст із координатною моделлю, можна писати керовані сценарії на Python, Expect або Go:

wait_for("Secure Boot") assert_value("Disabled")

Це не сліпа відправка клавіш, а процес зі зворотним зв’язком і контролем стану.

Для цільової машини пристрій виглядає як звичайний монітор і USB-клавіатура. Для користувача — як SSH-сервіс.

Обмеження

Технологія розрахована на текстові режими BIOS/UEFI та консольні інтерфейси.

Інтерфейси, де основною формою взаємодії є курсор миші, а відображення побудоване навколо повноцінного графічного рендерингу (іконки, анімації, 3D-елементи), не входять у базову модель системи.

Поточна реалізація орієнтована на латиницю.

Втім, для налаштування BIOS, RAID-контролерів, GRUB і Linux-інсталяторів цього більш ніж достатньо для переважної більшості серверних сценаріїв.

Висновок

Попри всю «магію» з перетворенням відео на текст, важливо розуміти одну просту річ: USBridge усе ще залишається звичайним KVM.

Для хоста це стандартний монітор і USB-клавіатура — без агентів, без програмного забезпечення на цільовій машині та без залежності від операційної системи.

Різниця лише в тому, що замість відеостріму користувач отримує текстовий інтерфейс по SSH.

Для роботи з пристроєм використовується кросплатформний клієнт на Go без web-UI. Він працює на Windows, macOS, Linux, а також на Android і iOS для базових сценаріїв доступу.

Окрім KVM-частини, пристрій уміє значно більше. Наприклад, він може створювати ізольовані файлові снапшоти на базі Btrfs без vendor lock-in. Але це вже окрема велика тема.

У наступній статті я детальніше розповім, навіщо я додав снапшоти в KVM-пристрій і які проблеми резервного копіювання вони вирішують у реальних сценаріях.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось10
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Амір Фаткулін, Ви пишете "

Що це дає на практиці
Підключаючись до KVM по SSH, ви не дивитеся на картинку — ви працюєте з текстом.

", — підкажіть, будь ласка, а що саме на влаштовує на практиці використання IP-KVM ?

Головна різниця — у тому, що звичайний IP-KVM транслює пікселі, а не дані.
На практиці це означає, що у відео-KVM я не можу виділити курсором текст помилки (наприклад, Kernel Panic) або UUID диска. Доводиться робити скріншот або переписувати руками. А тут працює звичайний Copy & Paste.
І найцікавіше — це відкриває двері для ШІ. Оскільки це текстовий SSH-потік, я можу підключити до керування сервером LLM-агента. Йому не треба розпізнавати зображення: він просто «читає» текст помилки в BIOS/консолі і може сам приймати рішення, як відновити систему.

Оце я розумію, thinking out of the box. Respect!

Я так розумію ви заздалегідь порахували хеш для кожного символу і створили словник, де ключ це хеш, а значення — відповідний ASCII символ?

Не заздалегідь. Там працює гібридний підхід: власна CNN на борту розпізнає нові символи, і вже результат лягає в кеш. Тобто кеш будується в рантаймі: перший раз розпізнали нейронкою — далі беремо з пам’яті.

Підписатись на коментарі