【问题标题】:Disk Read Error while loading sectors into memory将扇区加载到内存时出现磁盘读取错误
【发布时间】:2016-03-16 23:22:42
【问题描述】:

我尝试使用this 开发引导加载程序,但运行时显示:

disk read error!

如果我忽略它,在后面的部分中,它会显示错误的内存映射。我也关注了其他一些来源,但徒劳无功。感觉就像我只是在复制他们正在做的事情。如果我做的有点不同,每次都会产生一种新的错误。

我应该使用已经构建的引导加载程序还是该怎么做?

磁盘加载错误代码如下:

[org 0x7c00]

    KERNEL_OFFSET equ 0x1000    
    mov [BOOT_DRIVE], dl        
    mov bp, 0x9000          
    mov sp, bp  
    mov bx, MSG_REAL_MODE       
    call print_string           
    call load_kernel            
    jmp $

print_string:
    pusha
    mov ah, 0x0e

loop:
    mov al,[bx]
    cmp al, 0
    je return
    int 0x10
    inc bx
    jmp loop

return:
    popa
    ret

disk_load: 
    push dx                                              
    mov ah, 0x02                                   
    mov al, dh                                          
    mov ch, 0x00                                    
    mov dh, 0x00                                     
    mov cl, 0x02                                    
    int 0x13                                           
    jc disk_error                                  
    pop dx                                               
    cmp dh, al                                         
    jne disk_error                                 
    ret

 disk_error :
   mov bx, DISK_ERROR_MSG 
   call print_string 
   jmp $

DISK_ERROR_MSG db "Disk read error!", 0

[bits 16]

load_kernel: 
    mov bx, KERNEL_OFFSET       
    mov dh, 15           
    mov dl, [BOOT_DRIVE]                      
    call disk_load                                                  
    ret

; Global variables
BOOT_DRIVE     db 0 
MSG_REAL_MODE db "Started in 16-bit Real Mode", 0 

; Bootsector padding 
times 510-($-$$) db 0 
dw 0xaa55

我使用这个命令来组装和运行我的引导加载程序:

nasm boot.asm -f bin -o boot.bin && qemu-system-i386 boot.bin

我在这一点上卡住了。我的引导加载程序显示disk read error。如果我此时忽略它,那么它会在执行我的 kernel.c 时产生问题。它似乎使用了错误的内存映射。

【问题讨论】:

  • 请检查此代码并帮助我!
  • 您遇到的一个问题是您在程序启动时没有正确设置DS(数据段)。您还设置了 SP,但实际上并没有设置有效的 SS(堆栈段)。这也可能导致问题。在 disk_load 中,您没有设置 ES(扩展段),需要正确设置它以便完全指定读取数据的内存位置(ES:BX 是地址缓冲区)。如果您正在创建 720k 软盘,读取 15 个扇区可能无法正常工作,因为磁道(柱面)上的最大扇区为 9。这可能会导致读取问题。
  • [bits 16] 放在顶部也是一个好主意,以便 NASM 知道为引导加载程序生成所有 16 位代码
  • 我正在使用 qemu 作为模拟器。
  • 你可以试试nasm -f bin boot.asm -o boot.bin,然后创建一个磁盘映像(以1.44MB软盘大小为例)做dd if=/dev/zero of=disk.img bs=1024 count=1440然后将bin文件放在开头带有dd if=boot.bin of=disk.img conv=notrunc 的磁盘映像。然后尝试像这样运行 QEMU qemu-system-i386 -fda disk.img 。这会将磁盘映像作为软盘 A 启动:

标签: assembly kernel qemu bootloader osdev


【解决方案1】:

“他在列一个清单,他检查了两次……”

  • 您的引导加载程序以实地址模式启动,因此最好强制您的汇编程序使用 16 位代码。在 NASM 中,您可以通过在程序顶部写入 [bits 16] 来实现这一点。

  • 当您的引导加载程序启动时,BIOS 会将其置于线性地址 00007C00h。对于段和偏移的组合,它可以通过多种方式做到这一点。
    当您明确写[org 0x7C00] 时,您(有点)期望这种组合的段部分等于零。但这绝不是 BIOS 的义务!因此,您可以手动设置段寄存器(DS、ES 和 SS)。

  • 您在 print_string 例程中使用的 BIOS 电传功能使用 BL 和 BH 作为参数。所以你永远不应该使用 BX 寄存器来处理你的文本。当然,一些 BIOS 不再使用这些 BL 和 BH 参数,但会尝试为最大的受众开发程序。

  • 当您使用 0x9000 初始化 SP 寄存器时,您有效地设置了一个堆栈,该堆栈可以在您不注意的情况下轻松覆盖它下面的程序!最好选择满足您需求的SS和SP的组合,仅此而已。一个 4608 字节的堆栈在 7C00h 处停留在引导扇区之上并在 9000h 处结束,需要:SS=07E0h SP=1200h。为避免 8086 硬件出现任何问题,最好在更改 SS:SP 时禁用中断。

  • 您使用了pushapopa 指令。这些不是 8086 硬件上的有效指令。在编写健壮的软件时,我们应该测试硬件是否能胜任这项任务。但这里最简单的解决方案是只推送/弹出单个寄存器。

  • 您已经解释了从磁盘读取的 BIOS 函数的返回值,但是当传输的扇区数不正确时,您就中止了。这是错误的做法。当 BIOS 告诉您传输不完整时(如果您的 BIOS 未启用多轨,则可能发生这种情况),您必须对剩余的扇区数重复调用。显然有些参数需要调整:下一个磁头,可能是下一个柱面,并且总是扇区=1。 (一个完美的解决方案是从 BIOS 中检索磁盘几何结构或从磁盘上存在的 BPB 中读取它)。我假设基本的 1.44 MB 软盘操作。

  • 如果第一次从磁盘读取不成功,您应该重试几次。 这样的第一次失败是完全正常的。五次重试是一个很好的价值。在两次尝试之间,您调用 BIOS 函数来重置磁盘驱动器。

  • 为确保 QEMU 可以实际读取这额外的 15 个扇区,您应该填充此文件,使其总长度为 16 个扇区。您链接的text 也这样做了!

“把它们放在一起”

[bits 16]
[org 0x7C00]

KERNEL_OFFSET equ 0x1000

xor  ax, ax
mov  ds, ax
mov  es, ax    
mov  [BOOT_DRIVE], dl
mov  ax, 0x07E0
cli
mov  ss, ax 
mov  sp, 0x1200
sti
mov  si, MSG_REAL_MODE       
call print_string           
call load_kernel            
jmp  $

print_string:
  push ax
  push bx
  push si
  mov  bx, 0x0007  ;BL=WhiteOnBlack BH=Display page 0
  mov  ah, 0x0E    ;Teletype function
 loop:
  mov  al, [si]
  cmp  al, 0
  je return
  int  0x10
  inc  si
  jmp  loop
 return:
  pop  si
  pop  bx
  pop  ax
  ret

disk_load:
  mov  [SECTORS], dh
  mov  ch, 0x00      ;C=0
  mov  dh, 0x00      ;H=0
  mov  cl, 0x02      ;S=2
 next_group:
  mov  di, 5         ;Max 5 tries
 again: 
  mov  ah, 0x02      ;Read sectors
  mov  al, [SECTORS]
  int  0x13
  jc   maybe_retry
  sub  [SECTORS], al ;Remaining sectors
  jz  ready
  mov  cl, 0x01      ;Always sector 1
  xor  dh, 1         ;Next head on diskette!
  jnz  next_group
  inc  ch            ;Next cylinder
  jmp  next_group
 maybe_retry:
  mov  ah, 0x00      ;Reset diskdrive
  int  0x13
  dec  di
  jnz  again
  jmp  disk_error
 ready:
  ret

disk_error:
  mov  si, DISK_ERROR_MSG 
  call print_string 
  jmp  $

DISK_ERROR_MSG db "Disk read error!", 0

load_kernel: 
  mov  bx, KERNEL_OFFSET       
  mov  dh, 15           
  mov  dl, [BOOT_DRIVE]                      
  call disk_load                                                  
  ret

; Global variables
BOOT_DRIVE     db 0
SECTORS        db 0
MSG_REAL_MODE  db "Started in 16-bit Real Mode", 0 

; Bootsector padding 
times 510-($-$$) db 0 
dw 0xAA55

; 15 sector padding
times 15*256 dw 0xDADA

【讨论】:

  • 只是关于更新 SS:SP 的评论。您所说的实际上与最广泛的硬件兼容是正确的,但 CLI/STI 对的主要原因是为了规避 1980 年代一些有问题的 8088 CPU 上的错误。当您使用 MOV 指令更新 SS 寄存器时,假设在 NEXT 指令之后禁用中断。通常这是对 SP 的更新。不幸的是,在一些有缺陷的 8088 CPU 上,中断并没有像预期的那样被关闭,所以人们会明确地使用 CLI/STI 来避免这个错误。
  • 我赞成你的回答。再做一点观察。您依赖 AL 作为读取的扇区数。有一些古老的 BIOS 仅在 CF=1 时返回 AL 中的值(是的,听起来有点疯狂,但确实如此)。大多数引导加载程序(针对更广泛的实际硬件)不假定值 AL 可以依赖。因此,通常大多数引导加载程序一次读取一个扇区,或者获取磁盘几何结构(从 BPB 或 BDA),并且只进行从不跨越磁道(柱面)的多扇区读取。但是您的代码将适用于大多数硬件(以及我所知道的所有模拟器)。
猜你喜欢
  • 2018-08-03
  • 2010-12-17
  • 2023-03-23
  • 2021-09-05
  • 1970-01-01
  • 2020-02-03
  • 2020-10-11
  • 2013-11-20
  • 2014-11-29
相关资源
最近更新 更多