OSDev http://osdev.su/ |
|
INT 13h, AH=42h - extended read sectors http://osdev.su/viewtopic.php?f=6&t=506 |
Страница 1 из 4 |
Автор: | Yoda [ 08 мар 2012, 15:10 ] |
Заголовок сообщения: | INT 13h, AH=42h - extended read sectors |
Такой вопрос по subj функции BIOS. В пакете LBA указывается 64-битный номер сектора на чтение. Действительно ли современные BIOS будут читать сектора свыше 2Тб, если я укажу сектор с номером, не помещающимся в 32 бита? Никто не пробовал? |
Автор: | phantom-84 [ 08 мар 2012, 16:30 ] |
Заголовок сообщения: | Re: INT 13h, AH=42h - extended read sectors |
Ты чё загрузчик для NTFS собрался писать? "Современные" будут. Вот только проблема, что по версии эту "современность" никак не определить, т.к. это поле было определено еще в самой первой версии EDD, поэтому спокойно работаешь в соответствии с EDD Spec. и не думаешь о плохом ))) Пока не будет прецедентов незагрузки системы по этой причине, можно не париться, но возможность самой загрузки нужно прорабатывать (поддержка GPT, той же NTFS), чтобы такие прецеденты в принципе могли появиться. |
Автор: | Yoda [ 08 мар 2012, 17:08 ] |
Заголовок сообщения: | Re: INT 13h, AH=42h - extended read sectors |
phantom-84 писал(а): Ты чё загрузчик для NTFS собрался писать? Да уж бОльшую часть написал :) phantom-84 писал(а): Пока не будет прецедентов незагрузки системы по этой причине, можно не париться, но возможность самой загрузки нужно прорабатывать Вот и прорабатываю. Просто думал, может это пустой труд. Очень неудобно оперировать 64-битными числами в загрузочном секторе. Регистров не хватает для эффективной работы. У меня винт 2Тб. Чуть-чуть, зараза, не хватает, чтобы проверить реальную работу. У кого-нибудь больше 2Тб есть? |
Автор: | phantom-84 [ 08 мар 2012, 21:23 ] |
Заголовок сообщения: | Re: INT 13h, AH=42h - extended read sectors |
Yoda писал(а): Вот и прорабатываю. Просто думал, может это пустой труд. Глянь на виндовые загрузчики для NTFS в плане использования старших 32 бит при обращении к функции 42h. Еще по сети гуляют оригинальные исходники загрузчика для старых версий виндов (вероятно, WinNT) - там вообще сервис EDD не используется (сейчас глянул, вроде не увидел), но подсмотреть что-нибудь интересное, думаю, можно.Цитата: Очень неудобно оперировать 64-битными числами в загрузочном секторе. Регистров не хватает для эффективной работы. Ну, насколько я понимаю, зато нет существенных ограничений по размеру кода - можно сделать подпрограммы для каждой операции и обращаться к операндам посредством указателей/смещений. Я когда-то уже говорил, что не использую в первичных загрузчиках даже 32-разрядные регистры, но как-то выкручиваюсь, благодаря различным приемам, например, функция чтения сектора принимает в качестве входных параметров указатель (по сути только смещение) на базовый номер сектора и 16-разрядный относительный номер сектора (относительно базового номера) или функция деления позволяет получить при делении 32-разрядного делимого на 16-разрядный делитель 32-разрядное частное. Короче используй память и подпрограммы.Цитата: У меня винт 2Тб. Чуть-чуть, зараза, не хватает, чтобы проверить реальную работу. Можно поискать. Вопрос в том, как тестировать.
У кого-нибудь больше 2Тб есть? |
Автор: | Yoda [ 09 мар 2012, 00:12 ] |
Заголовок сообщения: | Re: INT 13h, AH=42h - extended read sectors |
phantom-84 писал(а): Глянь на виндовые загрузчики для NTFS в плане использования старших 32 бит при обращении к функции 42h. Еще по сети гуляют оригинальные исходники загрузчика для старых версий виндов (вероятно, WinNT) - там вообще сервис EDD не используется (сейчас глянул, вроде не увидел), но подсмотреть что-нибудь интересное, думаю, можно. Виндовых загрузчиков у меня нет. Когда мучился с пониманием работы NTFS, набрёл на загрузчик из состава GRUB utilities. Там есть опенсорс загрузчик NTFS. Но я глянул - это такой бдыщь! Я не смог в нём разобраться. Он практически нечитаем и непонимаем. Но я знаю, что LBA адреса в нём везде только 32 битные. Вся мировая практика неоднократно показала, что проще и надёжней написать что-то по документации с нуля, чем переписывать чей-то фарш. За криком: "Ваааа! Исходники!!!" практически всегда следует стон разочарования. phantom-84 писал(а): Ну, насколько я понимаю, зато нет существенных ограничений по размеру кода - можно сделать подпрограммы для каждой операции и обращаться к операндам посредством указателей/смещений. Да сделаю, прорвёмся :) phantom-84 писал(а): Цитата: У кого-нибудь больше 2Тб есть? Можно поискать. Вопрос в том, как тестировать.Да тестировать как раз просто. В один из последних секторов записываешь что-то уникальное (а можно и не писать, если там уже есть что-то уникальное), потом формируешь единственный запрос на чтение этого сектора и сравниваешь считанные данные с ожидаемыми. |
Автор: | phantom-84 [ 09 мар 2012, 09:09 ] |
Заголовок сообщения: | Re: INT 13h, AH=42h - extended read sectors |
Yoda писал(а): phantom-84 писал(а): Глянь на виндовые загрузчики для NTFS в плане использования старших 32 бит при обращении к функции 42h. Еще по сети гуляют оригинальные исходники загрузчика для старых версий виндов (вероятно, WinNT) - там вообще сервис EDD не используется (сейчас глянул, вроде не увидел), но подсмотреть что-нибудь интересное, думаю, можно. Виндовых загрузчиков у меня нет. Когда мучился с пониманием работы NTFS, набрёл на загрузчик из состава GRUB utilities. Там есть опенсорс загрузчик NTFS. Но я глянул - это такой бдыщь! Я не смог в нём разобраться. Он практически нечитаем и непонимаем. Но я знаю, что LBA адреса в нём везде только 32 битные. Есть еще один важный момент. Возможно, создатели этих загрузчиков не сильно парились на эту тему по причине того, что винда не поддерживает схему загрузки "GPT-on-BIOS". А в системах, где такая схема поддерживается, обычно используется не совсем традиционный порядок загрузки и несколько другие ФС. Короче нужно искать систему с подобной схемой и традиционным порядком загрузки и смотреть на ее загрузчики. Можно пробовать самостоятельно реализовать подобную схему, попутно поддержав EDD Spec. в плане реализации гибридного MBR-загрузчика в соответствии с данной спецификацией. |
Автор: | Yoda [ 09 мар 2012, 15:30 ] |
Заголовок сообщения: | Re: INT 13h, AH=42h - extended read sectors |
phantom-84 писал(а): Типа винду принципиально не ставишь ))) Просто посмотри, задействованы ли в них старшие 32 бита при обращении к функции 42h или нет. Типа, дизассемблить загрузчик? Если в загрузчике с исходными кодами толком не разобраться, то что говорить про дизассемблированный?! phantom-84 писал(а): Если самому разбирать лень, можно воспользоваться исследованиями довольно популярного апологета в этой области (и антиапологета в области веб-дизайна))) ) - use keywords "starman ntfs", хотя я не уверен, что это будут именно последние версии загрузчиков. Заглянул к нему. Да уж, Старман действительно с дизайном явно не "на ты" :) Но наковырял с тонну добра из загрузчиков. phantom-84 писал(а): Возможно, создатели этих загрузчиков не сильно парились на эту тему по причине того, что винда не поддерживает схему загрузки "GPT-on-BIOS". А в системах, где такая схема поддерживается, обычно используется не совсем традиционный порядок загрузки и несколько другие ФС. У Винды совершенно точно с GPT довольно натянутые отношения. Поддерживается только в 64-битных версиях семёрки и загрузка исключительно через EFI-BIOS. Поэтому я почти уверен, что традиционная загрузка с больших разделов не предусмотрена. Но моя задача не винду грузить. По этой причине я хочу поддержать всё то, что теоретически возможно поддержать на нормальной среднестатистической системе. Раз спецификации предусматривают 64-битные LBA адреса, буду на них закладываться. Если они реально работают, то я не вижу абсолютно никакой необходимости в EFI. И дело даже не только в GPT. В принципе, у нас может быть не разбитый на разделы носитель, целиком отформатированный под NTFS. PS. У Стармана дизассембли только первого сектора NTFS-загрузчика, но там видно, что в функции чтения сектора в LBA-пакет пихаются только младшие 32 бита. Так что, отстой все эти загрузчики и активное проталкивание спецификаций EFI :) |
Автор: | phantom-84 [ 09 мар 2012, 17:04 ] |
Заголовок сообщения: | Re: INT 13h, AH=42h - extended read sectors |
Yoda писал(а): Типа, дизассемблить загрузчик? Если в загрузчике с исходными кодами толком не разобраться, то что говорить про дизассемблированный?! Не понимаю, в чем трудность нахождения фрагмента, в котором идет обращение к функции 42h. Нашел за пару мин. (загрузчик семерки):Код: 7D1D 66| 60 pushad Та же фигня. Еще бросается в глаза отсутствие оптимизации по размеру (push 0/1/10h, jc loc_0007) и интенсивное использование 32-разрядных регистров (в этой подпрограмме не так заметно).7D1F 1E push ds 7D20 06 push es 7D21 loc_0006: 7D21 66| A1 0011 mov eax,ds:data_0010e 7D25 66| 03 06 001C add eax,ds:data_0012e 7D2A 1E push ds 7D2B 66| 68 00000000 push 0 7D31 66| 50 push eax 7D33 06 push es 7D34 53 push bx 7D35 68 0001 push 1 7D38 68 0010 push 10h 7D3B B4 42 mov ah,42h 7D3D 8A 16 000E mov dl,ds:data_0008e 7D41 16 push ss 7D42 1F pop ds 7D43 8B F4 mov si,sp 7D45 CD 13 int 13h 7D47 66| 59 pop ecx 7D49 5B pop bx 7D4A 5A pop dx 7D4B 66| 59 pop ecx 7D4D 66| 59 pop ecx 7D4F 1F pop ds 7D50 0F 82 0016 jc loc_0007 7D54 66| FF 06 0011 inc dword ptr ds:data_0002e 7D59 03 16 000F add dx,ds:data_0001e 7D5D 8E C2 mov es,dx 7D5F FF 0E 0016 dec word ptr ds:data_0003e 7D63 75 BC jnz loc_0006 7D65 07 pop es 7D66 1F pop ds 7D67 66| 61 popad 7D69 C3 retn 7D6A loc_0007: 7D6A A0 01F8 mov al,data_0016 7D6D loc_0008: 7D6D E8 0009 call sub_0002 7D70 A0 01FB mov al,data_0019 7D73 E8 0003 call sub_0002 7D76 loc_0009: 7D76 F4 hlt 7D77 EB FD jmp short loc_0009 Цитата: У Винды совершенно точно с GPT довольно натянутые отношения. Поддерживается только в 64-битных версиях семёрки и загрузка исключительно через EFI-BIOS. Поэтому я почти уверен, что традиционная загрузка с больших разделов не предусмотрена. Еще при MBR-разметке раздел может начинаться до отметки 2 тб и пересекать ее.
Но моя задача не винду грузить. По этой причине я хочу поддержать всё то, что теоретически возможно поддержать на нормальной среднестатистической системе. Раз спецификации предусматривают 64-битные LBA адреса, буду на них закладываться. Если они реально работают, то я не вижу абсолютно никакой необходимости в EFI. И дело даже не только в GPT. В принципе, у нас может быть не разбитый на разделы носитель, целиком отформатированный под NTFS. |
Автор: | Станислав [ 09 мар 2012, 17:48 ] |
Заголовок сообщения: | Re: INT 13h, AH=42h - extended read sectors |
64-битные LBA адреса добавили для огромных дисков, которые будут в будущем(на данный момент это редкость), для загрузчиков писать их поддержку не обязательно. Ну в принципи забивайте в пакет из NTFS 64-битный LBA адрес на всякий. Чтение IDE контроллером командой "READ SECTORS DMA" 0C8h LBA адрес меньше 32 бит. |
Автор: | phantom-84 [ 09 мар 2012, 19:28 ] |
Заголовок сообщения: | Re: INT 13h, AH=42h - extended read sectors |
Станислав писал(а): 64-битные LBA адреса добавили для огромных дисков, которые будут в будущем(на данный момент это редкость)... В магазин сходи, чтобы посмотреть на будущее)))Цитата: Чтение IDE контроллером командой "READ SECTORS DMA" 0C8h LBA адрес меньше 32 бит. Вот именно что меньше! Я уже не помню, когда у меня на компе стоял диск меньше 128 гиг.
|
Страница 1 из 4 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |