LINUX.ORG.RU
решено Форум — Linux-hardware  

Включить текстовый (80x25) или VGA16-режим (640x480-4) при загрузке с UEFI

 , , , ,


0

3

Всем здравствуйте.

Итак, задача.

Задача

Заела ностальгия, хочу увидеть старую добрую фреймбуферную консоль с пингвином (CONFIG_LOGO_LINUX_VGA16 или CONFIG_LOGO_LINUX_CLUT224).

Всё это безобразие я пытаюсь выполнить на не самом старом ноутбуке с Core i7-7700HQ и i915 в качестве основной видеоплаты (есть ещё дискретная видеоплата AMD, но речь сейчас не о ней). Причём грузится Linux посредством UEFI (не BIOS).

«Родное» разрешение экрана – 1920x1080, поэтому в обычных условиях (без извращений, т. е. без efifb либо inteldrmfb) GRUB как-то автоматически цепляет именно это разрешение, а дальше я гружу ядро с параметрами video=eDP-1:1920x1080 video=HDMI-A-1:1920x1080.

Но вернёмся к задаче. Вопрос не об inteldrmfb и не о KMS – вопрос именно о включении VGA- или VESA-режимов. Основная проблема в том, что перевести фреймбуфер

  • в разрешение 720x400x16 (текстовая VGA-консоль 80x25)
  • либо в 640x480x16 (VGA16)
  • либо в любое из VESA-разрешений (хотя бы 800x600)

– я не могу. В худшем случае после меню GRUB я вижу просто чёрный экран, в лучшем – для вывода используется узкая полоска высотой 20px вверху экрана (похоже, что ядро просто пишет в самое начало видеопамяти, да ещё предполагает глубину цвета 4bpp вместо 32bpp). В обоих случаях приходится заходить на компьютер по сети.

Ход эксперимента

Варианты, которые я использовал:

  • текстовая консоль VGA (CONFIG_FB_VGA16 is not set, CONFIG_VGA_CONSOLE=y)
  • vesafb (CONFIG_FB_BOOT_VESA_SUPPORT=y, CONFIG_FB_VESA=y)
  • vga16fb (CONFIG_FB_VGA16=m)
  • uvesafb, VESA framebuffer в userspace, использующий «виртуальный» x86 BIOS (CONFIG_FB_VGA16=m, CONFIG_FB_UVESA=m, v86d установлен)

В случае с vga16fb у меня даже появляются /dev/fb0 и /sys/class/graphics/fb0/*, но, ещё раз, вывод приходится на самое начало видеопамяти .

Что я пытался сделать:

  1. Включал/выключал KMS (nomodeset, i915.modeset=0, вот это всё). В конце концов для чистоты эксперимента просто перестал собирать модули i915 и amdgpu.
  2. Играл с параметрами video= и vga=, как описано здесь, здесь здесь и здесь. Варианты vga=normal, vga=extended, vga=ask, vga=301, video=vga16fb:640x480-4, video=vesa, video=uvesafb н к чему не приводят, ядро на них кладёт.
  3. Играл с настройками GRUB. Команда vbeinfo отсутствует, команда videoinfo выводит пустой список видеорежимов. Установка GRUB_GFXPAYLOAD_LINUX=text приводит к тому, что GRUB радостно сообщает: «text» mode is not available и продолжает загрузку в слепом (blind) режиме. Т. е. это тоже чёрный экран, но уже средствами не ядра, а GRUB.
  4. Запускал hwinfo --framebuffer. Пустой список.

В сухом остатке – у меня ощущение, что я косячу либо с настройками GRUB, либо с параметрами ядра (в последнем случае не скажешь наверняка, т. к. документация на тот же vesafb была написана 20 лет назад, и хрен поймёт, насколько она актуальна сейчас).

Либо же то, что я наблюдаю – особенности именно интеловского фреймбуфера.

Либо же VGA- и VESA-режимы вообще недоступны пр загрузке через UEFI, но подтверждения этому я нигде не нашёл. Но, с другой стороны, x86 BIOS недоступен, да.

Вопрос

Собственно, вопрос. Оно вообще возможно – VGA или VESA через UEFI? Если да – то какие настройки GRUB и параметры ядра должны быть?

P.S. Смотрел в /boot/grub/x86_64-efi/video.lst – там только efi_gop, efi_uga, video_bochs, video_cirrus, что, в общем, закономерно. Никакого vbe там нет.

P.P.S. Ядро 4.19.251, хотя это и не важно. Модули, которые меня интересуют, не менялись десятилетиями.

★★★★★

Последнее исправление: Bass (всего исправлений: 3)

Ответ на: комментарий от agentgoblin

Спасибо за ответ.

Встречные вопросы.

  1. В машине, помимо UEFI, таки есть CSM. Его можно включить, загрузить какой-нибудь FreeDOS, и таки получить заветные 720x400 (80x25). Т. е. VGA-совместимость таки есть. Или ты имеешь в виду именно отсутствие VGA-совместимости в long-режиме через GOP-протокол, при загрузке через UEFI? Это странно, вот здесь, например, пишут. что

    UEFI GOP includes support for calling legacy video BIOS code through the CSM

  2. Хорошо, пусть я пока не могу «вывалиться» обратно в 16-битный реальный режим из 64-разрядного (хотя вот здесь сообщают, что это теоретически достижимо) – но логотип-то с пингвином при использовании efifb и/или inteldrmfb получить должно быть таки возможно. Как это сделать?

Bass ★★★★★
() автор топика
Ответ на: комментарий от Jameson

Спасибо, кэп.

Я в курсе и про конфигурационный параметр, и про где его найти. Вопрос: ты это прочитал в интеренете, или оно у тебя самого так работает при UEFI-загрузке?

В ядре три варианта логотипа – MONO, 16 цветов и 224 цвета. У меня пока не получилось добиться желаемого эффекта, и у меня сомнения, что это будет работать при 32-разрядной глубине цвета, которая у современных фреймбуферов по умолчанию.

Особенно с учётом того, что «OS or OS applications lose capability of changing display resolution and configuration if OS high performance display driver is not installed or functional» (в контексте Linux это, видимо, про efifb, отсюда).

Bass ★★★★★
() автор топика
Последнее исправление: Bass (всего исправлений: 1)
Ответ на: комментарий от Bass

Щас попробую, фигня вопрос.

А вот в истинном VGA text mode, который реализовывался нынче выкинутым из всех видеокарт блоком аппаратного знакогенератора никакого логотипа не было и быть не могло. Пингвинчик был только в graphic mode, уже с VESA фреймбуфером, и для многих тогда его наличие круто поднимало ЧСВ. А уж обладание матроксом с его шикарным matroxfb, ммм... Я адски кайфовал от матрокса помнится...

Но самый кайф был в том что матрокс имел в бивисе кроме графических VESA режимов ещё и VESA text mode c высокой плотностью и разрешением больше чем 80x25. Мне больше всего 132x25 режим нравился, на 15дюймовом монике он смотрелся лучше чем фреймбуфер 1024х768, так как не выжигал глаза 60герцами, был резкий как понос, с тонким шрифтом. Но без логотипа, да. Зато можно было прямо в этом режиме кинцо посмотреть через mplayer и модуль ядра mga_vid.

Jameson ★★★★★
()
Ответ на: комментарий от Jameson

Пингвинчик был только в graphic mode, уже с VESA фреймбуфером,..

Да, всё так, в VGA text mode я его и не ожидаю.

Про ЧСВ — в точку, у меня как раз кризис самооценки. Дай, думаю, пингвина включу — а тут такая фигня.

Про старые матроксы заинтриговал, у меня есть их несколько. Можно поставить Linux второй системой на старый Tualatin.

Bass ★★★★★
() автор топика
Ответ на: комментарий от Jameson

Вот видишь. К слову о преимуществах VESA перед этим вашим модным GOP.

Спасибо, что попробовал.

Bass ★★★★★
() автор топика
Последнее исправление: Bass (всего исправлений: 1)
Ответ на: комментарий от Bass

Ну справедливости ради неудивительно, так как efifb и simplefb сами ничего не инициализируют, тупо рисуют в то что им UEFI перед инициализацией предоставило. Можно попробовать специализированные фреймбуферы типа nouveau для Nvidia или что то там для АМД (у меня нет АМД, я не в курсе), и поиграть с глубиной цвета.

Jameson ★★★★★
()

Вот ты мне ежа под череп засадил. Тоже хочу стадо пингвинов теперь увидеть. Прочитал что параметр загрузки quiet подавляет лого, убрал, не, не помогло. Буду рыть. По идее 32bit фреймбуфер все равно должен 224цветное лого показывать. Потому что 24битный VESA фреймбуфер показывал, зуб даю.

Jameson ★★★★★
()
Ответ на: комментарий от Bass

Хвала Аспергеру, я разобрался и увидел стадо пингвинов. Теперь уже могу заняться наконец работой, за деньги.

Итак. FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=n (это важно, без этого пингвины прятались). В параметрах загрузки ядра — quiet убрать, loglevel=5 добавить. Ну и собсно лого включить в ядре, это очевидно. Результат — стадо пингвинов с UEFI, simplefb и 1920x1080x32 разрешением. Никаких VESA, CSM, legacy фреймбуферов не понадобилось.

Я кончил.

PS Для обладателей Nvidia

Новомодный simpledrm, который почему то тоже обозвали «Simple Framebuffer Driver» в menuconfig и врубили по умолчанию (defconfig) модулем с Nvidia не работает, «старый» simplefb находится в «Frame buffer Devices > Support for frame buffer devices», называется «Simple Framebuffer support» и прячется с глаз долой если simpledrm в Device Drivers > Graphics support вкомпилён в ядро статично.

Так что если вы желаете фреймбуфер и пропиетарные дрова одновременно — нужно либо выкинуть из ядра simpledrm, если он статично вкомпилён, и включить статично только simplefb, либо заблэклистить модуль simpledrm, чтобы он не загружался, если simplefb и simpledrm собраны модулями. Сложности добавляет то что он earlyboot и соответственно грузится из initrd.

Подробности тут: https://forums.developer.nvidia.com/t/510-39-01-on-5-16-0-kernel-green-screen...

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 2)
Ответ на: комментарий от Jameson

Итак, присоединяюсь к вышенаписанному.

У меня тоже всё получилось, но с некоторыми оговорками. FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER действительно n.

Нюансы же состоят в том, что у меня:

  1. видеоплата Intel (KMS-драйвера, i915.ko, вот это вот всё) и
  2. относительно старое (4.19) ядро, в котором ещё нет simpledrm и потому, по ощущениям, simplefb бесполезен чуть более, чем полностью (во всяком случае, получить работающий фреймбуфер, оставив включённым только simplefb, у меня не получилось).

Из работающих на моём железе драйверов, позволяющих стабильно получить честный /dev/fb0, я могу назвать два:

  • efifb (линкуется статически и сообщает, что он EFI VGA) и
  • i915 (можно слинковать в виде модуля, /sys/class/graphics/fb0/name сообщает, что он inteldrmfb).

Но при использовании стандартных настроек GRUB:

GRUB_TERMINAL=gfxterm
GRUB_GFXPAYLOAD_LINUX=keep

есть короткий интервал времени, когда окно GRUB уже скрылось, а подсистема DRM ещё не загрузилась (причём совершенно неважно, CONFIG_DRM=m или CONFIG_DRM=y). И именно в этот короткий интервал нам показываются пингвины. Поэтому в моём случае потребовалось ещё включить пресловутый efifb:

CONFIG_FB_EFI=y

(в 4.19, насколько я понял, ещё нет возможности включить его в виде модуля).

Проблема решена, ещё раз спасибо.

Bass ★★★★★
() автор топика
Linux-hardware