LINUX.ORG.RU

OS Development


0

0

проблема со чтением ide-шного винта через порты. в bochs все работает на 5 баллов - чтение, разбор структуры и тп, но как только тестирую ОС вживую (загрузка с дискеты) в буфер попадают случайные данные. код :

char *read_dev() { int cnt = 0;

while((in( CMD_PORT ) & 0xc0) != READY_STAT); bzero ( buffer, SECTOR_SIZE); out(DRV_AND_HEAD_PORT,0xa0); wait(); out(SECTOR_COUNT_PORT,0x01); wait(); out(SECTOR_NUM_PORT,0x01); wait(); out(CYL_LOW_PORT,0x00); wait(); out(CYL_HIGH_PORT,0x00); wait(); out(CMD_PORT,0x20); asm(""::"c"(SECTOR_IN_WORDS),"d"(DATA_PORT)," D"(buffer)); asm("rep insw");

return buffer; }

вопрос сводится вот к чему: надо ли при перепрограммировании PIC размаскировать IRQ 14 , надо ли вешать что-то специфическое на это IRQ? Нужны ли задержки между out в вышеприведенном коде и вообще - в чем может быть причина неоднозначного поведения софта в bochs & реальной жизни?

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

dilmah ★★★★★
()

вопрос довольно редкий (все-таки обычно умные люди задают вопросы)

я понять одного не могу - неужели делать нечего и надо тратить время на подобные разговоры. это из серии туповатых топиков вроде "что лучше - си или паскаль", или "а чем гном хуже кде", или "а с чего начать изучать..." ...

если я скажу что это курсовая работа - такой ответ устроит?

может я хочу ртп с микрокернелом писать, ну приведи мне хотя бы 2-3 free source таких (серьезных) операционок? (nt & qnx не в счет, а mach - утопия).

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

Titanicum
() автор топика

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

dilmah ★★★★★
()

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

dilmah ★★★★★
()

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

Titanicum
() автор топика

ok, оставлю титана наедине с другими полубогами.

dilmah ★★★★★
()

все, проблема решена. если кому-то интересно - перед rep insw нужна была солидная задержка.

ps: вообще rep insw - крайне неграмотный подход, старые биосы не контролируют готовность порта и часть данных может быть утеряна, потому лучше юзать for ( i =0 ; i < {cx}; i++) insw

Titanicum
() автор топика

а для задержек ты титомипсы учитываешь?

anonymous
()

задержка понятие абстрактное - в этом конкретном случае после (далее intel-овский синтаксис)

mov al,20h out dx,al

вставляем конструкцию

label: in al,dx test al,8 jz label

и все. для дебага юзал простой for.

Titanicum
() автор топика

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

..Это я так придираюсь от нечего делать.

anonymous
()

я ламер -- я не понимаю -- как может уживаться рил тайм и такой цикл?

anonymous
()

ответ на вопрос касательно отсоединения шлефа :

перед каждым чтением сектора я проверяю готовность контроллера (in(CMD_PORT)&0xc0 == 0x40). согласен, что чтение сектора не атомарная операция, но тем не менее - вероятность сбоя - крайне низкая. А что ты можешь предложить?

ответ на вопрос касательно цикла в ртп:

я не говорил что это раил тайм, я привел пример чего-то, что еще не реализовано по-человечески, как опровержение тому, что ничего нового в ТОС сделать на данный момент невозможно.

спасибо за замечания.

Titanicum
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.