BIOStrip - пишем программу для удаления/добавления модулей в BIOS

Немного не совсем структурированной информации из разных источников:
Самое структурированное

Еще кусок структурированной информации с какого-то китайского форума:

Бегло ознакомился с проектом UniFlash. Авторы выполнили титаническую работу. Из 440кб исходного текста примерно 400кб концептуально выглядит так:

// Вычисление m = a1*a2
if((a1 == 2) && (a2 == 2))
  m = 4;
else if((a1 == 2) && (a2 == 3))
  m = 6;
else if((a1 == 2) && (a2 == 4))
  m = 8; // и т.д.

Причем добавление поддержки нового железа требует внесения изменений в текст программы.

"Мы пойдем другим путем" - табличным.

PS
maco, спасибо за информацию 

Часть инфы по флэшкам можно почерпнуть из AmiFlash, или из его разновидности AsrFlash с сайта AsRock.

Господа модераторы, в этой ветке форума исчезли несколько последних постов от 23-го и 24-го октября.

"Что делать и кто виноват?" 

Как что делать???
Воспользоваться сложившейся ситуацией
И запостить линк на новый, никем еще невиданный BIOStrip. Не выкидывающий 8 окон дебага при запуске. Умеющийй разбирать и собирать прошивки, корректно пр этом пересчитывая CRC, как мы в свое время управлялись с АК.
Шутка
Вы разве этого не видели?

Pavel,
что такое АК?

Предлагаю для ознакомления очередную альфа-версию программы BIOStrip.

Закончены плагины:
BsCmos - чтение CMOS
BsPciProbe - чтение Pci-регистров

В стадии завершения - BsReadFlash - чтение прошивки.
 
В базе данных оболочки появились новые таблицы.

Речь пойдет о плагине BsReadFlash (и не только о нем).

Этот плагин должен обеспечивать чтение содержимого Flash-памяти с образом биоса. Главная проблема - настройка чипсета для обеспечение доступа ко всему диапазону адресов ПЗУ. Эта настройка сильно зависит от конкретного чипсета.
Хотелось бы эту чипсет-зависимую часть вынести во внешний файл (базу данных оболочки). Тогда добавка нового железа не будет требовать изменения и перекомпиляции программы.Осталось выбрать формат хранения этой чипсет-зависимой части. Этот формат, с одной стороны, должен быть достаточно гибким, а с другой - простым для реализации и удобным для пользователя.

Например, для моего компьютера (Host bridge 0x1039:0x0650, LPC bridge 0x1039:0x0008) перед чтением прошивки биоса необходимо записать в устройство LPC Bridge (Class 0x060100) в регистр 0x40 значение 0x03.

На языке C++ с использованием оболочки это выглядит так:

DWORD bdfLpcBridge = PCI_REG(0, 2, 0, 0); // bus=0, dev=2, fun=0, reg=0
BYTE r40 = theApp.m_pIPci->rdPciRegByte(bdfLpcBridge + 0x40);

    






theApp.m_pIPci->wrPciRegByte(bdfLpcBridge + 0x40, (r40 & 0xFF) | 0x03);

Но в таком виде алгоритм настройки железа для чтения прошивки хранить нельзя.

Поэтому предлагается другой формат - более многословный, но зато простой для интерпретации.

FIND_PCI_DEVICE_BY_CLASS dw0, 0x060100 	// dw0=0x80001000 (адрес Lpc Bridge)
ADD dw0, 0x40 				// dw0 = 0x80001040 (полный адрес регистра 0x40)
READ_PCI_REG_BYTE b0, dw0 			// чтение регистра
MOV b1, b0 				// запомним прежнее значение
OR b0, 0x03 				// новое значение
WRITE_PCI_REG_BYTE b0, dw0 			// запись регистра
READ_FLASH  				// Вызов функции для чтения прошивки
WRITE_PCI_REG_BYTE b1, dw0 			// запись прежнего значения регистра

В таком виде чипсет-зависимые настройки можно хранить в базе данных.
Поиск настроек будет осуществляться по Vendor_ID/Device_ID южного моста.

Аналогичный подход можно будет использовать и для плагина BsWriteFlash. Но кое-что придется добавить (чтение-запись в порты и пр.).

Какие будут мнения по поводу такого специального языка для записи настроек в базе данных?

У версии 1.2 есть глюк: если при сборке прошивки начать двигать модули вверх/вниз, то программа без слов, тихо закрывается. Проверено на разных компутерах. Версия 1.1 работает стабильно.