Ваше мнение о LiteBIOS?

С глубоким прискорбием сообщаем, что LiteBIOS, как проект, после продолжительныой болезни таки скончался. Осиновый кол вбит совместными усилиями архитектуры процессоров AMD-64 и отсутствием документации на чипсеты nVidia (в частности - nForce4 со товарищи).

Первый аргумент состоит в том, что прежде чем выполнять хоть какой-то код в BIOS, необходимо настроить регистр D4h = Clock Power/Timing Low, что в корне нарушает идею тестирования на самом раннем этапе старта.

Второй аргумент - настройка регистров чипсета с тем, чтобы разрешить вывод в порт, как таковой (иначе вывод выполняется в Африку). Хотя это возможно для каждого конкретного чипсета, не имея четкого представления о намерениях nVidia не представляется возможным поддержить все, что сходит со стапелей этой верфи. А значит - нет более универсального подхода с точки зрения архитектуры х86. К этому давно всё шло...

Добавлено спустя 1 день 1 час 46 минут 30 секунд:

Кто сказал "как мы теперь без этого"?
Также, как и раньше

Я кликнул на "подхвачу знамя", но исключительно в смысле - исходники дайте Типа пусть будут...

В полном смысле исходники дать никак невозможно. Дело в том, что компиляция ROMBIOS ни у одного из производителей не сделана регулярно. (Что такое регулярность - можно объяснить отдельной темой). Для формирования финальной версии LiteBIOS используются специальные программы и BAT-файлы (от идеи использовать разного рода make-конструкции отказались сразу же). Так вот, именно "конструктор" сделать публичным невозможно по внутренним правилам.

Сам же LiteBIOS состоит из загрузочного блока и "тела". Само "тело" на данный момент не интересно, так его выполнение требует от платформы изрядной доли исправности. Boot Block интересен во всех отношениях. Мы его можем выложить в эту ветку с комментариями. Конечно, для этого потребуется время, но результат может быть полезен, т.к. именно Boot Block позволяет стартовать на условно исправных (не совсем "мертвых") платах.

Если такие условия принимаются, то шаг за шагом мы может обсуждать исходный код загрузочного блока LiteBIOS.

условия принимаются. ждем рассказа.

Да, для общего развития однозначно интересно. В профессиональном плане меня интересуют по идее немного более другие вещи (взаимодействие и влияние на Addon (причем, довольно хитрые) BIOSы основного).

Но больше знаешь вообще - быстрее и осознаннее работаешь...

Это отдельный и огромный мир. Вопрос действительно интересный.

А теперь по сути темы. Разрабатывая тестовый BIOS преследовалась цель на самом раннем этапе старта получить софтверное подтверждение не только работоспособности платформы (ну, например, в тривиальном случае - системный BIOS искажен до неузнаваемости), но и диагностику неисправности.

Для диагностики необходимо использовать аппаратное устройство, это понятно, т.к. в момент старта о видео говорить не приходится. POST-карты, как устройста, отображающего состояние порта 80h - мало. Было принято решение дополнить функционал нашей POST-карты отображением состояния портов 110h...117h (как редко используемых). Хотя можно было бы использовать и любой другой подходящий диапазон портов.

1) Каким образом работать через 110h...117h?
А очень, оказывается, просто. Конструкция
MOV eax, 55AA00FFh
MOV dx, 110h
OUT dx, eax
обеспечивает наличие в портах 110h...117h байтов, из которых состоит EAX. Факт может очевидный, а может и не очевидный. Не могу сказать, что додумались, просто - написали и все тут.

2) Как искать неисправность?
Это оказалось тоже несложно. Идея такая:
MOV eax, 55AA00FFh
MOV dx, 110h ; первая 32-х битная посылка
OUT dx, eax
MOV dx, 114h ; вторая 32-х битная посылка
OUT dx, eax
Что в результате? Если данные не искажены, это значит, что в цепочке до Южного моста (шина 64 бита, с оговорками) ->PCI (шина 32 бита) -> ISA (шина 16 бит) -> BIOS (8 бит, с оговорками) проблем нет. Для надежности необходимо повторить эту же операуцию с инверсными данными, например 0AA55FF00h. Если есть четыре симметричных искажения, то проблема в связке ISA-BIOS, если два, то в PCI-ISA и т.д. (Хотя на практике все немного сложнее).

Если все понятно, то будем обсуждать далее. Если есть вопросы, то готов на них ответить.

напр., сейчас уже в компе есть 128-битные шины. Или как минимум подозрения на их наличие. Можно ли таким образом (без модификации) гарантированно споймать неисправность? Мне почему-то кажется, что нет, т.к. придется использовать 128-битные посылки. Ну, или четыре 32
В остальном вопросов нет.

Важно только, какова разрядность шин по пути выполнения BIOS из ROM: CPU -> NB -> SB -> PCI -> ISA -> BIOS. Практика показывает, что даже при 64-х битной архитектуре до SB включительно, одиночное повреждение вызывает двойную ошибку (одна в блоке портов 110h...113h, вторая - 114h...117h). Сей феномен нуждается в точном трактовании с привлечением сил разработчика чипсета

И еще важно отметить, что первая команда из BIOS может быть выполнена на "цифровой" платформе, т.е. если все питания и тактирования в норме, иначе у нас поиск неисправностей на "аналоговой" платформе требует не тестового BIOS, а измерительных приборов и осциллографа. По этой же причине "существенные" разрушения NB or/and SB приведут к тому же эффекту бесполезности LiteBIOS. Нас интересует только те случаи, когда может быть выполнена хотя бы одна команда из ROM.

Продолжение.
Следующая мысль при тестировании системы из ROM - это инкремент (а вернее - декремент) адреса. Очевидно, что в точке входа (для простоты будем счиать ее FFF0) выполнение кода будет продолжиться по адресам от FFF0 до FFFF, пока не наступит JMP в младшие адреса. Гарантировать это может только исправность младших 4-х линий адреса и сие не подвластно нам.
Вопрос, куда переходить из крошечного участка FFF0...FFFF? Если нет уверенности в испраности линий адреса, то мы можем позволить себе изменений только одного бита из старших. Таким образом следующий фрагмент кода должен (или может) располагаться, например, по таким адресам:
FFE0
FFD0
FFB0
FF70
Но никак не по FFA0 или FFC0, ибо в этом случае изменения коснуться двух битов (почти наверняка - двух линий!) адреса.

кул не придумал бы - честно )))) Но при дефектах в младших битах энто не поможет Но там никакой софт работать не сможет

Совершенно верно: либо переход в точку входа будет затруднен, либо код FFF0...FFFF не выполнится. Но для этого на POST-карте должен быть режим "DATA", в нем и только в нем мы обнаружим дефект старта на Very Very Early этапе.

[продолжение]
Итак, чтобы костер не затух, зададим жару: следующая предпосылка для постоения BIOS - точка входа. Всем и каждому известно, что процессор (начиная с i386DX) выполняет первую инструкцию по адресу 0FFFFFFF0h, находящемуся в топе 4 Гб пространства. В этом, казалось бы, легко убедиться с помощью несложной программы на ассемблере:

.586P
CODESG	SEGMENT PARA 'CODE' PUBLIC USE16
BBLOCK	PROC NEAR
	ASSUME	CS:CODESG, DS:CODESG, SS:CODESG
reset:
	jmp	start
start:
	nop
; ...

;------ Entry point for LiteBIOS start
	ORG	0FFF0h
;	mov	ebx,edx
;Following power-on reset the EDX register contains the values shown
;Type [13:12] Family [11:8] Model [7:4] Stepping [3:0]

testloop:
	mov	al,55h
	out	80h,al
	jmp	testloop ;do not use hlt!
	nop ; 1
	nop ; 2
	nop ; 3
	nop ; 4
	nop ; 5
	nop ; 6
	nop ; 7
	nop ; 8
	nop ; 9
	nop ; 10
BBLOCK	ENDP
CODESG	ENDS
	END	BBLOCK

Почему "казалось бы"? Потому что на всех платформах до появления процессора AMD Athlon/Duron в сокете 462 это работать будет. А означенному CPU в виду его свойства ROM SIP необходимо до выполнения первой инструкции BIOS, если специально не установлена ПЗУ с SIP-таблицей (а она на мей памяти ни разу на плате не была установлена), необходимо из BIOS вычитать эту самую SIP-таблицу.

NB: Наш коллега FatumNNM активно работает в этом направления на чипсетах nForce (см., например, forum.rom.by/viewtopic.php?t=9715&postdays=0&postorder=asc&&am... ).

Для постоение SIP-таблиц уже следует принимать во внимание специфику каждого из чипсетов для AMD Athlon/Duron. Так для SiS таблица размещается по адресу 0F000h:0FFD0h, для VIA - 0F000h:0FFE0h, для nForce - не специфицирована. Так как, к счастью, адреса не пересекаются, еще теплится жизнь в единой для всех чипсетов версии тестового BIOS. Но из-за угла бельмом цвета слоновой кости уже смотрит на нас AMD64...

:)