Board.KolibriOS.org

Demonikss wrote:Ядро Колибри вообще содержит обработчики исключений?

конечно содержит.

Demonikss wrote:Нормальный порядок инициализации любой железки описан достаточно подробно:
1. Проверка наличия, состояния.
2. Собственно инициализация (подготовка к работе, установка начального состояния).
3. Опрос устройства, проверка работоспособности.
Всеми любимый Таненбаум об этом писал и не раз...
... Глючные биос были и будут всегда. Отмазочка типа вся проблема в производителях биос конечно хороша, но с такой идеологией пишутся только системы Шиндоуз, монстры которые жрут ресурсы и делают вид что работают.

Строго наоборот.
BIOS инициализирует железо за полсекунды, потому что точно знает на какой платформе его прошили.
А Винда пытается запуститься на всём подряд, согласно канонам многомудрого Таненбаума.

Эффективность этих дедуктивных методов можно созерцать при каждой загрузке Винды.
И на любой платформе.

BIOS запускает все железо и предоставляет стандартный интерфейс доступа для любой операционной системы чтобы скрыть премудрости разработчика, и сделать любой компьютер совместимым с PC (ну со стандартом хотя бы), насколько мне известно. Вопрос заключался почему тогда инициализация ядра Колибри не соответствует стандарту?

Еще раз наоборот: это система команд i486 не соответствует стандарту ядра КолибриОС.

Имхо эта тема исчерпана, начинается дурацкий высокоинтеллектуальный трёп.

Это далеко не холивар. Часто указывается что метод используемый сейчас в Колибри, является устаревшим. Прерывания биос предоставляют для этих целей порт 92h ака ps/2 потому что многие отказываются от поддержки старых методов. То есть отказываясь от поддержки старых процессоров вы не желаете отказываться от остального старого? Непонятно. Может быть почистить тему и задать вопрос по другому? Мне хочется получить четкий ответ на вопрос заданный в начале. Почему вы используете метод включения А20 через порт контроллера клавиатуры, и система команд 486 тут не при чем. Никто адекватно не может пояснить почему нет проверки реально ли включился А20, хотя бы через тот же вызов биос или как там еще это можно сделать. Стандарт ядра Колибри я бы воспринял если бы оно само инициализировало железку и не было бы возможности проверить, только верить на слово что так оно и должно быть.
Можете перманентно и бан мне влепить, только ответа вразумительного я пока ни от одного кул програмера не услышал...

Demonikss wrote:Мне хочется получить четкий ответ на вопрос заданный в начале. Почему вы используете метод включения А20 через порт контроллера клавиатуры, и система команд 486 тут не при чем.

CleverMouse wrote: Demonikss писал(а):
Да и процедура активации A20 используемая ядром уже померла давно.
Нет. Она незначительно медленнее, но надёжнее.

http://wiki.osdev.org/A20_Line

However, the Fast A20 method is not supported everywhere and there is no reliable way to tell if it will have some effect or not on a given system. Even worse, on some systems, it may actually do something else like blanking the screen, so it should be used only after the BIOS has reported that FAST A20 is available. Code for systems lacking FAST A20 support is also needed, so relying only on this method is discouraged. Also, on some chipsets you might have to enable Fast A20 support in the BIOS configuration screen.

http://www.win.tue.nl/~aeb/linux/kbd/A20.html

Using 0x92 may be dangerous

Demonikss wrote:Можете перманентно и бан мне влепить, только ответа вразумительного я пока ни от одного кул програмера не услышал...

Если вы рассчитывали услышать ответ от кул программера, то явно ошиблись форумом.

Before enabling the A20 with any of the methods described below it is better to test whether the A20 address line was already enabled by the BIOS. This can be achieved by comparing, at boot time in real mode, the bootsector identifier (0xAA55) located at address 0000:7DFE with the value 1 MiB higher which is at address FFFF:7E0E. When the two values are different it means that the A20 is already enabled otherwise if the values are identical it must be ruled out that this is not by mere chance. Therefore the bootsector identifier needs to be changed, for instance by rotating it left by 8 bits, and again compared to the 16 bits word at FFFF:7E0E. When they are still the same then the A20 address line is disabled otherwise it is enabled.

Code: Select all

call    a20wait
        mov     al,0xAD
        out     0x64,al
 
        call    a20wait
        mov     al,0xD0
        out     0x64,al
 
        call    a20wait2
        in      al,0x60
        push    eax
 
        call    a20wait
        mov     al,0xD1
        out     0x64,al
 
        call    a20wait
        pop     eax
        or      al,2
        out     0x60,al
 
        call    a20wait
        mov     al,0xAE
        out     0x64,al
 

Насколько я вижу тут кучка рекомендаций, в связи с чем и задавался вопрос. Почему нет проверки включено/не включено, почему не блокируется клавиатура перед посылкой команды включения, почему в порт 60h пишется значение DFh хотя сказано и показано в коде что управляет гейтом бит 2... Почему не используется метод порта 92h я понял, хотя там написано что можно использовать если биос его поддерживает и вызовом биос его же можно и реализовать.
А по поводу проверки, так от метода с использованием контроллера клавиатуры уже отказались в IntelMac, хотя вообще непонятно зачем макинтошу использовать процессор не-АРМ и переписывать ядро.

Demonikss
1. Этот код идёт с самой первой ревизии. То есть ещё от Вилле. Так что вопрос надо адресовать ему.
2. Код работает везде, поэтому никто не лезет его чинить.

Хорошо. Считаю что вопрос исчерпан. Можно действительно закрывать тему. А насчет работает везде уже убедился что не везде, но с большинством спорить бесполезно.

Это входной фильтр. Где этот код не работает, система всё равно не сможет работать, зависнет в другом месте.
Ваша проблема с А20 не связана, что уже неоднократно указывалось.

Demonikss wrote:А насчет работает везде уже убедился что не везде, но с большинством спорить бесполезно.

Еще раз попытаюсь достучаться до вашего мыслительного процесса:
1) Ваша проблема в первую очередь связана с отсутствием поддержки команд входящих в архитектуру Pentium. Ни у кого из центральных разработчиков нет настолько старого железа, а значит нет потребности в написании кода для его поддержки.
2) Оборудование на запуск поддержки которого вы претендуете составляет менее 0,01% от всего парка железа на котором могла бы запуститься Колибри, плюс это усугубляется п.1 - обязательно это учитывайте! Очень тяжело писать код и исправлять ошибки для отсутствующего в живую оборудования.
3) Это свободный проект - вы можете делать свою версию хоть программ, хоть ядра, хоть всего проекта целиком, но требовать от других разработчиков удовлетворения исключительно ваших интересов не очень разумно, особенно потому что это усугублено п.1 и п.2.

В отношении поддержки старого железа я с вами не спорю. Я высказался конкретно в отношении перехода в защищенный режим. В любом случае отсутствует проверка реально ли сработало включение A20, и система команд тут совершенно ни при чем. Отсюда неадекватное поведение системы при попытке запуска на несовместимом железе. Для своих нужд я просто дописываю пока код включения А20 (взяв за пример ядро линукс где действительно все работает). Далее попробую найти адекватную замену rdtsc, не прибегая к исключению ее из кода. Думаю что вариант всегда существует. Хотя бы сделать обработчик с синеньким экранчиком и надписью А НЕЧЕГО ЗАПУСКАТЬ МЕНЯ НА ЭТОМ ДРЕВНЕМ ЖЕЛЕЗЕ
И я не требовал менять именно для меня, просто мне непонятен подход. В любом случае для того чтобы код работал стабильно и не был уязвим необходимо чтобы он был законченным и проверял результат своих действий на адекватность. Если я неправ, тогда посмотрим в сторону Мелкософта и его нагромождение кода, который гордо именуется ОПЕРАЦИОННАЯ СИСТЕМА. В идеале вы тоже стремитесь к такому же непонятному монстрику который делает непонятно что и жрет бог весть знает сколько неизвестно для каких целей?

Demonikss
В этом проекте никто ничего никому не должен (за исключением студентов SoC - они конечно обязаны отрабатывать свои гранты).
Каждый выкладывает тот код, который считает правильным, причем критерии отбора у всех разные.
Если Вам так приспичило запустить ядро на Вашей древней платформе - попробуйте заинтересовать кого-нибудь в частном порядке (как действует yogev_ezra, например).
Пока что, насколько можно судить по реакции коллег, ни у кого нет ни малейшего интереса браться за это неинтересное, неблагодарное и заведомо бесперспективное дело.

Что же касается Ваших теоретических умозаключений, то

Spoiler:

Доктор,все вокруг говорят, что я не дружу с логикой.
Это наглая ложь, тем более что у них для этого есть все основания!

Dear Demonikss,

Even when you get the kernel working without RDTSC and the like...
Dont forget that you'll want a VESA 2.0 compatible graphics card (which I havent seen in a 486 system yet.)
Also, the minimum amount of RAM stated for kernel is 8 MiB, but you'll want some more for the applications, 16 MiB or even 32 MiB might be needed.