Компиляция GRUB 2.04 и функция grub_bios_interrupt()

Что значит «дамп видяхи» сделать с помощью функции исходника Grub? В консольный строке груба есть несколько десятков команд по получению информации о видео плюс должны быть штатные средства ядра для получения информации о видео карте.

А почему нельзя использовать grub по назначению – загрузить freedos, и из-под него считать «дамп видяхи»? Даже в случае самописного считывателя это попроще будет.

должны быть штатные средства ядра для получения информации о видео карте.

Должны. но они не работают :( Это макбук про 2006 г. Старина Джобс постарался на славу. Биос с карточки читается только его собственным грабом, в котором я проверил команду read. Она получает правильные байты с адреса 0хс0000 в отличие от стандартного граба, который получает 0xffffffff и ничего более. Но джобсовый граб не умеет делать ничего (в нужном мне направлении), кроме прочесть с указанного адреса 4 байта и показать их. И как его заставить грузить Линукс я тоже не понимаю. И документации никакой не нашел. Да хотя бы, как выйти в его командную строку. Я в нее вышел чисто случайно, когда он перестал находить раздел с виндой из-за моих экспериментов с MBR, поскольку его убил установщик юбунты.

Я подозреваю, что и причина, почему драйвер тоже не может получить данные биоса и поэтому не работает, тоже находится где-то рядом. Хотя это странно, ведь, казалось бы, драйвер из ядра это делает, а ядру же вся память должна быть доступна. Результат - экран работает только с параметром загрузки ядра nomodeset при котором в принципе работать можно, но такие сайты, как алиэкспресс, лучше в браузере не открывать :(

Поэтому предполагался примерно такой план: В командной строке GRUB набираем:

insmod hexdump
hexdump (vrom) outfile=video.bin

Сейчас этот модуль понимает только

hexdump (mem) skip=xxxx length=yyyy

Но там реализовано простое чтение с адреса, которое не работает в защищенном режиме. Если чтение из реального режима сработает, то дальше надо понять, может ли граб подсунуть этот дамп ядру в качестве параметра при загрузке (скорее всего нет). Тогда остается только способ, описанный здесь, но он все же предполагает, что есть дамп ROM в виде файла.

А почему нельзя использовать grub по назначению

А я попробовал. Пока что не получается. Сделал, как написано здесь. На вот этом:

linux16 /memdisk
initrd16 /fdboot.img

GRUB говорит Error: too many boot sectors Флешку форматировал GParted на два раздела - в первом GRUB, во втором файлы memdisk и fdboot.img. Второй раздел сделал маленьким, как написано.

Могу только спросить: «Зачем два раздела?!». Файлы там небольшие по нынешним временам, вполне могут валяться с рядом с grub. А так надо разбираться:

• то ли делать chainloader +1 // написал от балды
• то ли делать корнем этот второй раздел
• а возможно модифицировать fdboot.img, который там вообще непонятно зачем: memdisk обычно самодостаточная программа – просто работает.

всё иду спать: надо же спутать memdisk c memtest ((

Могу только спросить: «Зачем два раздела?!».

Ну я просто скопировал, как написано в той инструкции. Я хз зачем. Ну, обычно, EFI раздел на харде отдельный же. Все сделал, как там. Взял именно те версии memdisk и fdboot.img, как там было написано. Про ошибку я соврал. Сейчас после linux16 /memdisk не пишет ничего, а после initrd /fdboot.img пишет «you need to load the kernel first». Команды ввожу руками в командной строке. Как так? GRUB 2.04 штатный из системы (т.е. не тот, с которым я экспериментировал) устанавливаю на флешку через grub-install --efi-directory=/media/alex/EFI --boot-directory=/media/alex/EFI/boot --removable EFI - метка раздела на флешке. Флешку разметил в MBR, а то вдруг что. Казалось бы, все по инструкции.

то ли делать корнем этот второй раздел

А он и есть корень. Вот полный текст grub.cfg:

 insmod fat
 set root='(hd0,msdos2)'
 linux16 /memdisk
 initrd16 /fdboot.img

Когда граб вываливается в строку, если ему сделать ls /, то он показывает нужные файлы. Но срабатывают только первые две сточки. Ну или три, я не знаю, как это понимать: на загрузку ядра не ругается, но потом говорит, что оно не загружено.

В общем, похоже, он не хочет ДОС грузить :( Максимум чего добился - вот с этим образом и мемдиском из установленной юбунты 20.04 граб тупо виснет без каких-либо сообщений об ошибках.

Так что изначальный вопрос остается в силе.

dos

mac… UEFI…

Картина проясняется ( То ли ты сразу не сказал, то ли я пропустил мимо…

В общем и целом никакой дос здесь не помощник. Я не очень просвещён в устройстве UEFI, но мне сложно поверить, что оно стартует в режиме совместимом с 16-bit «реальным режимом dos». Тем более деление на 32 и 64-битные UEFI намекает…

Как-то я пытался найти следы системы(программы) в ОЗУ после перезагрузки. Я даже добился записи дампов памяти «сразу» после перезагрузки на носитель, но свою задачу так и не выполнил. Может задачу неверно поставил, а может такое и невозможно в принципе выполнить…

К чему я это вспоминаю? Дело было на компьютере с UEFI и для решения задачи я пользовался UEFI Shell – он умеет показывать дамп памяти (команда аналогичная hd) и я как-то «заставил» UEFI Shell писать содержимое ОЗУ в файлы. Там не сложно, но сейчас не вспомню, разве что повторить – глядишь и «вспомниться».

Твой случай выглядит попроще:

• ты знаешь где искать, и главное этот блоб точно в памяти есть – даже UEFI без него ничего не покажет
• возможно ты знаешь какие-либо его «родовые метки» – заголовок, сигнатура, копирайты (что-то же должно быть?)

Попробуй воспользоваться шеллом UEFI (он же есть на маках?).

Я всё ещё считаю форк grub сверхусилием.

ты знаешь где искать, и главное этот блоб точно в памяти есть

Ну, если быть точнее то единственный факт, который я установил - это то, что эппловый GRUB может прочитать с адреса 0xc0000 правильные байты, с которых начинается дамп биос. Как он это делает, это вопрос. К тому же, я не очень понял: вроде же этот адрес 0xc0000 - это не адрес ROM VBIOS, а адрес, в который отображается дамп ROM. Т.е. мне непонятно, на какой стадии он туда отображается и кто этим занят? Может там его просто нет, если я не использую эппловый GRUB? Или это решается самой железкой? Тогда ок, можно ехать дальше.

Мне интересно вот что: под мастдаем в древние времена был такой кастомный драйвер уровня ядра, называется TVicHW95. Это просто скелет от VXD, который позволял читать/писать в порты и память. Вот интересно, под линуксом для х86 такого никто не сподобился сотворить? Ведь линуксовые драйвера уровня ядра (вроде бы) делать проще, чем мастдайные?

Попробуй воспользоваться шеллом UEFI (он же есть на маках?).

Я вообще без понятия, что это, но загуглить попробую.

PS: Погуглил. Да шоб им пусто было!

«…Apple disables access the option to launch the EFI shell on all of its computers. Using these factory settings, your entry into your MacBook Pro’s EFI is limited to a number of key commands at startup.»

Ты не горячись, к чему столько эмоций? Написано же Using these factory settings, your entry into your MacBook Pro’s EFI is limited to a number of key commands at startup я ничего фатального не уловил в этой фразе, правда я и не натуральный англосакс. Да и поиск в интернетах даёт намёки на возможность положительного исхода

You need a compatible EFI Shell program (called shell.efi) in your EFI partition.

1 rEFInd не нужен, у тебя есть grub. Нужен сам shell.efi. Там есть ценные замечания про версию EFI и варианты шелла.

или вот прямым текстом

If you want to launch the EFI shell, you can download third-party software that changes the interface EFI shows you at start-up. This includes the option for launching the EFI shell. However, installing this kind of software can be dangerous. If your MacBook Pro's EFI becomes corrupted, your computer could fail to boot properly. Damage to the very software that starts the computer will require a technician to repair, and tampering with EFI could void your MacBook Pro's warranty.

2 – другими словами, сделать можно, но это опасно

• злобные хакеры сделают твой мак ботом или что они там умеют
• компьютер станет «кирпичом» и гарантия теряется – вот это серьезно и может и в теории случиться на практике при определенных и возможно неизвестных нам обстоятельствах.

И это я ещё в ) гугл не заглядывал.

Кстати, возникает ещё ряд вопросов:

• grub как был установлен – куда Apple смотрел? на них совсем не похоже
• как с запуском других приложений efi (шелл, твой grub и его возможно модифицированная версия – все это приложения efi) нужен только бинарник или он должен быть подписан (и т.д.)

адрес 0xc0000 - это не адрес ROM VBIOS, а адрес, в который отображается дамп ROM. Т.е. мне непонятно, на какой стадии он туда отображается и кто этим занят?

EFI насколько я понимаю после включения компьютера это делает и другие действия тоже. Загрузчик и ОС такие низкоуровневые задачи не выполняют.

под мастдаем в древние времена был такой кастомный драйвер уровня ядра, называется TVicHW95. Это просто скелет от VXD, который позволял читать/писать в порты и память. Вот интересно, под линуксом для х86 такого никто не сподобился сотворить?

Есть примеры написания модулей ядра (это тоже гуглится), но это не твой случай – к моменту, когда модуль попадёт в память защищенный режим будет во все поля. И угадать где страницы с дампом ROM Video BIOS, а тем более узнать корректное ли у них содержание… я бы на это не надеялся.

единственный факт, который я установил - это то, что эппловый GRUB может прочитать с адреса 0xc0000 правильные байты, с которых начинается дамп биос.

Ты модифицировал grub? Можно поздравлять с успешным началом?

Насколько я знаю grub не умеет писать на носители данных – это серьезный барьер.