Board.KolibriOS.org

Да у меня времени нет, к сожалению, и так проектов по горло. Но, тому кто возьмется, помочь обещаю. Могу реверс биоса делать.
Самый верный вариант - спросить у нас в рассылке coreboot@coreboot.org
Щас вот биос открыл - 3300IA5.rom - он?
А то я не помню уже

XVilka
Спасибо за детальную инструкцию!
Попробую прошить в реальное железо.
Насколько я понял, для этого QEMU не требуется?

Жаль
Я бы хотел всё-таки подарить знакомому человеку, сам понимаешь. Я же там у вас никого не знаю.
Для eBox-3300 - он самый. Для eBox-3300MX нужен другой - прилагаю. Я продаю и eBox-3300, и eBox-3300MX, но eBox-3300MX гораздо более перспективный (больше памяти поддерживает, вход для блока питания стандартный, звук HD Audio, есть функция MMX и т.д.). Так что, если уж совсем конкретно, то лучше всего eBox-3300MX.

art_zh: сначала рекомендую запустить на qemu, а потом уже в железку загонять

не понял про загрузчик? Это то что касательно int 19h? Или дисковые операции упарзняются, как таковые, а загрузка вырождается в операцию копирования память-память и все?
Так?
И еще
если делается реверс(ы) биоса для coreboot, как для автономного проекта, то не проще ли и без него вообще?

Т.е. раз делать дизасм бутблока и глубокий анализ инита чипсета, особенно под память, (только под данную или выбранную, допустим встраиваемую платформу), то можно же навыдирать "конкретного нужного" под "встроенную" тему и все. Тогда и coreboot избыток, так?

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

Ну вот, тогда зачем получается coreboot вообще не нужен?
Если еще более сузить потребности в биос коде, и если речь допустим о конкретном встроенном решении типа Колибри-А или Колибри-eBox или Колибри-AWARD то получается места вообще валом, а скорость загрузки спошной реактив + минимум настроек чипсета... Сюда же и видеобиосный код "чикается" только под нужное разрешение и все.
Я что то упускаю? Крамолы нет?

Да, вырождение загрузчика в копирование памяти.

Я же не весь бутблок реверсю, а только конкретные функции.
А почему coreboot? А потому что код в нем тестируется сотнями человек, и лучше добавить немного изменений в уже готовый проект, чем изобретать свой чугунный велосипед с квадратными колесами.
Кроме того, coreboot занимает очень мало места.

VaStaNi


Получается, что CoreBoot вместе с загрузчиком занимает около 80к
Плюс еще 128к на видео-биос (его CoreBoot просто выдирает из старого ROM-кода).

Остаётся как минимум 800к - для ядра, драйверов, библиотек и утилит вполне достаточно.

А если делать через BIOS - тогда только ядро влезет, шрифты и иконки (у меня в ROM меньше 128к свободного места)

Вот и смотри в чем лучше копаться - в CoreBoot или в недокументированных реверсах BIOS ?

Ну это смотря какой BIOS и какой flash ROM chip - вот опять же, в eBox чип 2 Мегабайта, а BIOS только 256 Килобайт, получается для Колибри при "родном" БИОСе остаётся 1.75 Мегабайт - туда и полный floppy-image влезет, и ещё на семечки останется

BIOS, как минимум дольше запускается...
Не забываем, что прриведенные выше размеры относятся для дебаг-версий. Конечный файл, без всего лишнего, еще меньше и быстрее получиться.

Я начал делать реверс биоса, но мне нужен вывод lspci -nnvvvxxxx

yogev_ezra, можно еще вывод "lspci -nnvvvxxxx" из под линукса сделать?

art_zh, давай по-файлово определимся что оставим, а что можно выкинуть.
Я думаю, лучше начать с самого минимума, а потом можно добавлять постепенно функциональность, блоками.

У меня такая идея:
coreboot может загружать elf напрямую, может загружать SeaBIOS, который предоставляет сервисы легаси-биоса
Я предлагаю попробовать исключить из цепочки SeaBIOS, и попробовать скомпоновать elf-файл, который сам себя будет загружать сразу. Сразу 32-битный код, и убрать зависимость от биос-функций.
Определение дисков без биоса можно сделать так: у меня есть код на С, я могу его скомпилировать и отреверсить в ассемлерный текст Я на ассемблере не очень пишу, а реверсю быстрее.

XVilka
я не понял зачем компилить всё ядро в .elf ?
Нужно написать (на Си) простенький системный загрузчик вместо bootcode.inc

Как я понял, существуют несколько разных вариантов реализации ROM-загрузки Колибри
1) с помощью 16-разрядных дисковых функций SeaBIOS (система грузится с обычного iso- или img-образа)
2) с помощью самодельного 32-разрядного загрузчика, прочитывающего img-файл с диска, загружающего его в память как RD/1, и уже с него загружающего 32- kernel.mnt (от которого должна остаться только 32-разрядная часть)
3) или с помощью упрощённого загрузчика, считывающего только kernel.mnt, а с остальными файлами работающего напрямую с диска (CoreBoot ведь должен уметь работать с FAT и с ext2/3 ?)
4) или ещё проще - загружающего RD-образ прямо из ROM. В этом случае можно обойтись вообще без дисковой подсистемы. Но каждый раз придется прошивать img-образ в RAM...

Ты какой из этих вариантов имел в виду?

Тут есть еще один важный вопрос:
Как в CoreBoot организована карта памяти ?
Сейчас Колибри сама формирует LDT и IDT, находясь в 16-разрядном пространстве, потом входит в PM и сразу же создает PDE/PTE для своего собственного страничного преобразования адресов. Насколько сложно будет это реализовать в 32-разрядном загрузчике?

у coreboot есть своя файловая система cbfs (http://tracker.coreboot.org/trac/corebo ... n/cbfs.txt) - она очень простая и флешка форматируется именно в нее. Есть вариант добавить драйвер cbfs в ядро колибри и загружать ядро из coreboot, сразу 32 разряда. А остальные диски можно подключать опционально.
в идеале - выкинуть надобность в SeaBIOS.
На Си это будет несложно организовать - можно взять и урезать до минимума FILO (http://www.coreboot.org/FILO)

Кстати, с помощью gcc-4.6.1, убрав информацию и функции дебага, можно coreboot скомпилить в 10 кб.

Карта памяти - http://www.coreboot.org/Developer_Manual/Memory_map

Прикрепляю избранные файлы из FILO/libpayload, которые нам собственно нужны.

Попробовал прошить CoreBoot на ASUS M4A78LT-M LE (говорят, что на очень близкой по архитектуре мат.плате он запускается).
Двое суток раскуривал мануалы и плевался, собирая ROM-образ по кусочкам. В конце концов собрал. Прошил. Не работает.

Глухо, как в бронепоезде. Как будто вообще без ROMа.

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

P.S. Напоминаю, что для прошивки нужны минимум два совершенно одинаковых flashROM-чипа .
Один из них стоит в Вашем компьютере; запасной чип можно заказать по каталогу или вынуть из точно такого же компьютера (с риском для второго).
После загрузки Линукса ROM можно скопировать в файл и (аккуратно!) вынуть из сокета и пометить яркой краской. На его место поставить запасной чип, прошить в него ROM-файл и перезагрузиться. Если получилось - значит с можно работать дальше. Если нет - лучше сразу закончить эксперименты.

art_zh: если что-то не работает - то есть лог и SerialICE http://www.serialice.com/News/News.html (только его тоже из svn надо ставить, последний)
Есть возможность записать лог с последовательного порта?

1. Скачиваем SerialICE из svn:

svn co svn://serialice.com/serialice/trunk/SerialICE serialice
cd serialice
make menuconfig (тут мы настраиваем что нам нужно)
make

Результирующий образ будет serialice.rom размером 64 Kb.
Мультиплицируем его по размеру флешки:
(пример для 256Кб)

cat serialice.rom serialice.rom serialice.rom serialice.rom > image.rom

Заливаем image.rom в микросхему.
Заливаем ТОЛЬКО с помощью программатора (если у вас нет программатора, который кстати легко сделать своими руками - лучше сюда даже не соваться)
Подключаем к последовательному порту нашей целевой машинки кабель, соединяем с другой, где запущен minicom, picocom, realterm или любой другой последовательный терминал
После включения целевой машинки мы должны увидеть приглашение SerialICE на экране терминала.
Если что-то не так, то проверяем подключение, в случае необходимости патчим serialice.

To be continued...