INT 13h эффективный размер сектора - PullRequest
3 голосов
/ 20 июня 2020

Я работаю над написанием собственного загрузчика. Я хочу использовать int 13h,02h для чтения секторов с загрузочного диска. Я ссылаюсь на https://en.wikipedia.org/wiki/INT_13H для документации по этому прерыванию b ios.

Большинство найденных мной справочных кодов предполагает, что размер сектора составляет исключительно 512 байт, несмотря на тот факт, что существуют другие размеры (нестандартные размеры, такие как 520-байтовые секторы и 4096-байтовые сектора). Некоторые источники, которые я нашел, похоже, предполагают, что B IOS всегда будет эмулировать сектор как 512 байт независимо от базового размера ( LBA и размер сектора ), а некоторые, похоже, указывают, что это не случай (https://www.reddit.com/r/osdev/comments/ajfmtf/is_the_sector_size_for_bios_int_13h_ah2_always/), хотя ни один источник, который я нашел, не дает убедительной документации, подтверждающей этот факт.

Я понимаю, что могу использовать int 13h,48h для чтения информации о диске параметры, однако я все еще не уверен, будет ли «размер сектора», возвращаемый этим прерыванием, использоваться, или B IOS будет автоматически эмулировать 512-байтовые сектора. В дополнение к этому, int 13h, 48h не гарантируется, что будет поддерживаться на каждой платформе (я считаю). Ссылка, по-видимому, предлагает последнее: «Предположим, вы хотите прочитать 16 секторов (= 2000h байтов)».

Если возможно, я ищу следующее:

  1. Какой размер сектора на самом деле используется для дисков с нестандартным размером сектора, и конкретная документация, которая поддерживает этот ответ.
  2. Если на самом деле используется нестандартный размер, есть ли способ определить это значение, не полагаясь на int 13h,48h?

Ответы [ 2 ]

1 голос
/ 20 июня 2020

Все нерасширенные B IOS дисковые сервисы вроде Int 13h / AH = 2h , Int 13h = AH = 3h et c. все предполагаются 512-байтовыми секторами. Преобразование выполняется, если базовый носитель использует больший размер сектора диска.

Размеры сектора будут кратны 512 байтам, чтобы быть совместимыми с устаревшим B IOS. На заре IBM-P C были некоторые диски, которые поддерживали размеры секторов esoteri c, но они требовали использования различных служб, предоставляемых B IOS, или требовали прямого доступа к диску (через порты ввода-вывода и т. c). По сути, для использования таких устройств вам необходимо специальное оборудование или вам необходимо написать код, написанный специально для этих устройств.

Существуют определенные типы устройств SCSI (включая SAS SSD), которые используют 520-байтовые сектора на самом низком уровне, но обычно требуется стереть диск и переформатировать его, чтобы использовать стандартный размер сектора, кратный 512 байтам, чтобы его понимало большинство программ и операционных систем. Обычно это включает в себя передачу команд SCSI непосредственно диску. В Linux sg_format может использоваться для выполнения такого рода операции низкого уровня. Для таких дисков обычно также требуются специализированные контроллеры.

Расширенные дисковые службы B IOS, например Int 13h / AH = 42h и Int 13h / AH = 43h не делайте такого предположения, что размер сектора фиксирован и составляет 512 байт. На любом типе дисковода, который поддерживает расширенные службы диска B IOS, вы можете запросить параметры диска, чтобы определить размер сектора диска.

Если обнаружено, что диск поддерживает расширенные службы диска B IOS, вы можете определить размер сектора при запущенном загрузчике. См. дополнительные примечания о том, как проверить, поддерживает ли B IOS и диск эти расширения. Если B IOS и диск их поддерживают, вы можете использовать Int 13h / AH = 48h , чтобы запросить размер сектора диска:

IBM/MS INT 13 Extensions - GET DRIVE PARAMETERS
AH = 48h
DL = drive (80h-FFh)
DS:SI -> buffer for drive parameters (see #00273)

Return:
CF clear if successful
AH = 00h
DS:SI buffer filled
CF set on error
AH = error code

[snip]

Format of IBM/MS INT 13 Extensions drive parameters:

Offset  Size    Description     (Table 00273)
00h    WORD    (call) size of buffer
(001Ah for v1.x, 001Eh for v2.x, 42h for v3.0)
(ret) size of returned data
02h    WORD    information flags (see #00274)
04h    DWORD   number of physical cylinders on drive
08h    DWORD   number of physical heads on drive
0Ch    DWORD   number of physical sectors per track
10h    QWORD   total number of sectors on drive
**18h    WORD    bytes per sector**
---v2.0+ ---
1Ah    DWORD   -> EDD configuration parameters (see #00278)
FFFFh:FFFFh if not available
---v3.0 ---
1Eh    WORD    signature BEDDh to indicate presence of Device Path info
20h    BYTE    length of Device Path information, including signature and this
byte (24h for v3.0)
21h  3 BYTEs   reserved (0)
24h  4 BYTEs   ASCIZ name of host bus ("ISA" or "PCI")
28h  8 BYTEs   ASCIZ name of interface type
"ATA"
"ATAPI"
"SCSI"
"USB"
"1394" IEEE 1394 (FireWire)
"FIBRE" Fibre Channel
30h  8 BYTEs   Interface Path (see #00275)
38h  8 BYTEs   Device Path (see #00276)
40h    BYTE    reserved (0)
41h    BYTE    checksum of bytes 1Eh-40h (two's complement of sum, which makes
the 8-bit sum of bytes 1Eh-41h equal 00h)

Обратите внимание, что возвращенная структура диска включает:

10h    QWORD  total number of sectors on drive

Дополнительные примечания

Int 13h / AH = 48h, а другие расширенные дисковые функции, вероятно, будут частью всех современных систем, которые все еще поддерживают устаревшие BIOS. Десятилетия go это могло быть не так. Чтобы определить, действительно ли B IOS поддерживает службы расширенного диска B IOS, вы можете использовать Int 13 / AH = 41h / BX = 55AAh :

IBM/MS INT 13 Extensions - INSTALLATION CHECK
AH = 41h
BX = 55AAh
DL = drive (80h-FFh)

Return:
CF set on error (extensions not supported)
AH = 01h (invalid function)
CF clear if successful
BX = AA55h if installed
AH = major version of extensions
01h = 1.x
20h = 2.0 / EDD-1.0
21h = 2.1 / EDD-1.1
30h = EDD-3.0
AL = internal use
CX = API subset support bitmap (see #00271)
DH = extension version (v2.0+ ??? -- not present in 1.x)

Если вы используете эту службу B IOS и значение, возвращаемое в BX = AA55h, тогда B IOS поддерживает расширения дисков. Если это не так, вам придется вернуться к использованию нерасширенных дисковых функций с использованием адресации CHS. Если B IOS поддерживает расширенные дисковые службы, это не значит, что проверяемый диск действительно поддерживает их! Большинство гибких дисков не поддерживают расширенные дисковые службы B IOS, хотя сам B IOS поддерживает.

Вот почему вам также необходимо проверить возвращаемый флаг переноса (CF), чтобы увидеть, Расширения дисков поддерживаются на интересующем вас диске. Если они не поддерживаются, вам придется вернуться к нерасширенным дисковым службам B IOS с использованием адресации CHS, в противном случае вы можете использовать расширенный диск B IOS

После того, как вы определили, что диск поддерживает расширенные дисковые службы B IOS, вы можете использовать Int 13h / AH = 48h, как описано в первом разделе этого ответа, для определения размера сектора.

1 голос
/ 20 июня 2020

Один из способов узнать это - взглянуть на код существующих загрузчиков (например, Linux), потому что им тоже приходится иметь дело с этим. Тем не менее, я был бы действительно ДЕЙСТВИТЕЛЬНО удивлен, если бы существовал единственный жесткий диск, который не поддерживает чтение по 512 байт и не находится в этом режиме по умолчанию.

В дополнение к этому, int 13h, 48h не гарантируется, что поддерживаются на каждой платформе (я считаю).

Так что я думаю, что безопасный способ - попробовать INT 13h, 48h; если поддерживается, используйте это значение; если это не поддерживается, предположим, что 512 байт (потому что, если B IOS будет поддерживать другие размеры чтения, он также должен поддерживать INT 13h, 48h).

нестандартные размеры, такие как 520- байтовые сектора

Сейчас я программирую компьютеры более 40 лет, но я никогда не видел ни одного устройства, которое использует 520-байтовые сектора. И хотя есть ретро-компьютеры, где вы можете делать все, что хотите, со своей дискетой, контроллер дискеты P C позволяет использовать только степень двойки в качестве размера сектора, например 256, 512, 1024, 2048, 4096 и т. Д. * 1019. *. И вы вообще не можете изменить это на жестких дисках.

Так что мне действительно любопытно, какое устройство вы нашли с 520-байтовыми секторами?

...