assembly - "invalid command (error code 0x01)"在 BIOS int 13 中是什么意思

Question

我正在和我的一个 friend 一起开发一个简单的引导加载程序，并没有伪装成任何可用的东西。在编写了屏幕输入和输出函数之后，我们继续编写从磁盘读取扇区的函数，这就是第一个问题出现的地方。我声明在 qemu 和 bochs 上一切正常。对于物理硬件我不能说同样的事情，我遇到错误 0x0001，这意味着 Invalid Command .
但是，我没有找到有关此错误的太多信息。在我看来，这可能意味着我弄错了一些论点，但我在屏幕上打印了所有日志，但没有发现任何奇怪的值可以证明这种行为是正确的。
我正在从闪存驱动器启动。我认为这也可能是一个问题(因为它不是真正的软盘)，但是如果 BIOS 可以加载引导扇区，那么加载下一个扇区也应该没有问题。
但是，这里是 read_sector 函数的代码:

read_sector:
start_f
    pusha
    mov     (drive_number), %dl    # drive number is stored from the main function into a global variable
    mov     $0x03, %si             # try three times

1:
    mov     $0x0201, %ax
    int     $disk_int
    jnc     end

    dec     %si
    jz      2f
    xor     %ah, %ah
    int     $disk_int
    jmp     1b

2:
    movzx   %ah, %dx
    call    printh                 # print error code
end:
    popa
end_f

这是调用者函数(dl = 0):

    # ...

    mov     $0x0002, %cx
    xor     %dh, %dh
    mov     $0x7e00, %bx
    call    read_sector

    # ...

我们可能做错了什么？

Answer 1

这里的问题出在文件 init.s 中.我将一个值放入 drive_number在初始化代码段之前。
CPU 如何计算物理地址
real mode memory segmentation .
当我将此列表翻译成机器语言时，链接器计算 drive_number 的地址。通过引用它所在部分的开头(在本例中是 .text 部分，从地址 7c00 开始，如链接描述文件中所指定):

.text 0x7c00 :
    {
        *(.text);
    }

这意味着指令 mov $0, (drive_number)被翻译成 mov $0, 7c2e .然而，这不是一个实际的物理地址，而只是一个偏移量。
在实模式下 物理地址通过将移位 4 位(与乘以 16 相同)的特定段寄存器中的值添加到偏移量(如本例中的 7c2e )来计算。我们经常看到符号 AAAA:BBBB表示地址 AAAA * 16 + BBBB .为了确定用于读取或写入某种数据的内存中某个位置的物理地址，默认情况下 CPU 会利用存储在数据段寄存器 %ds 中的值。 .这意味着我们存储数据的实际地址确实是 ds * 16 + drive_number .
当 BIOS 跳转到引导扇区中编写的代码时，它并不能向我们保证段寄存器中的值就是我们想要的值。因此，在每个程序开始时，我们必须初始化这些寄存器以包含我们需要的值。如 %ds不为零， drive_number对应的物理地址 %ds初始化后就不一样了为零，这意味着此标签指向内存中的不同位置，具体取决于 %ds 中包含的值.
BIOS 告诉我们从哪个驱动器启动
BIOS 中断 13, 2要求 dl 包含指示我们应该从哪个驱动器读取的代码。但是，无需逐个查阅手册以从我们正在启动的驱动器中读取文本:实际上 BIOS 位于 %dl 中。在跳转到 07c0:0000 之前与我们正在启动的驱动器对应的值并开始执行引导扇区中的代码。
使用 BIOS 在 %dl 中传递的代码使代码更加可靠和健壮。