Disk Read Error while loading sectors into memory

Question

I tried to develop a bootloader using this, but when it is run it shows:

disk read error!

If I ignore it, in a later part, it shows me wrong memory mapping. I also followed some other sources too but in vain. It feels like I'm just copying what they are doing. If I do even a little different a new kind of error generates every time.

Should I use an already built bootloader or what to do?

The code of disk load error is as follow:

[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

I use this command to assemble and run my bootloader:

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

I get stuck at this point. My bootloader display disk read error. If I ignore it at this point in time, then it creates problems while executing my kernel.c It seems to use wrong memory mapping.

One problem you do have is that you don't properly set up the _DS_ (Data segment) when your program starts. You also set SP, but you don't actually set a valid _SS_ (Stack Segment). This could cause problems too. In disk_load you don't set the _ES_ (Extended segment), which needs to be set properly so that the memory location where data is read is fully specified (ES:BX is the address buffer). If you are creating a 720k floppy disk reading 15 sectors likely won't work because the maximum sectors on a track(cylinder) is 9. This can cause read problems. — Michael Petch, Dec 12 '15 at 05:27
Also a good idea to put `[bits 16]` at the top so that NASM knows to generate all 16 bit code for the bootloader — Michael Petch, Dec 12 '15 at 14:50
Commands: nasm boot.asm -f bin -o boot.bin && qemu-system-i386 boot.bin — Palvit Garg, Dec 12 '15 at 15:23
So it appears you are doing this on Linux? One problem I can see with how you load your bin file is that the file won't be large enough to actually have data for the other sectors your boot loader loads (QEMU will not be able to load sectors from a disk image that don't exist). You really need to be creating a disk image (something the size of a floppy disk image will do to start). Then you need to place boot.bin in the first sector. I'll assume you aren't using _dd_ at all? — Michael Petch, Dec 12 '15 at 15:41
What you can try is something like `nasm -f bin boot.asm -o boot.bin`, then to create a disk image (this the size of a 1.44MB floppy as an example) do `dd if=/dev/zero of=disk.img bs=1024 count=1440` then place the bin file into the beginning of the disk image with `dd if=boot.bin of=disk.img conv=notrunc` . Then try running QEMU like this `qemu-system-i386 -fda disk.img` . This will boot the disk image as floppy A: — Michael Petch, Dec 12 '15 at 15:45
Wow!! It works......Can you provide its more clear explanation? — Palvit Garg, Dec 12 '15 at 15:58
If you wish to place a file (like a kernel) starting at sector 2, it can be inserted with something like `dd if=kernel.bin of=disk.img bs=512 seek=1 conv=notrunc` The `bs=512 seek=1` seeks into the output file past the first 512 bytes and writes kernel.bin. So adding a command like this allows you to write the kernelin the sectors just past the boot sector without destroying the boot sector. — Michael Petch, Dec 12 '15 at 16:01
I faced the same error. The problem was that the code was trying to read 15 sectors from disk, but my disk image was too small (592 bytes only). So I used Michael's recommendation and used `dd` to create a larger disk image, and everything worked as expected. — ARV, Jul 06 '20 at 12:51

Sep Roland · Accepted Answer · 2015-12-20T16:19:23.303

"He's making a list, he's checking it twice..."

Your bootloader starts in the real address mode, so it is best to force your assembler in using 16-bit code. You achieve this in NASM by writing [bits 16] at the top of your program.
When your bootloader starts, BIOS will have placed it at linear address 00007C00h. It can do this in a number of ways with respect to the combination of segment and offset.
When you explicitly wrote [org 0x7C00] you (kind of) expected this combination to have the segment part equal to zero. But this is by no means an obligation for BIOS! And so it is up to you to set the segment registers (DS, ES, and SS) manually.
The BIOS teletype function that you use in your print_string routine uses BL and BH as parameters. So you should never use the BX register to address your text. Sure, some BIOSes don't use these BL and BH parameters (any more) but do try to develop programs for the biggest audience.
When you initialized the SP register with 0x9000 you effectively set up a stack that could easily, without you noticing it, overwrite the program beneath it! It would be best to choose a combination of SS and SP that satisfies your needs and nothing more. A 4608 bytes stack that stays above the bootsector at 7C00h and ends at 9000h would require: SS=07E0h SP=1200h. To avoid any problems on 8086 hardware it's best to disable interrupts when changing SS:SP.
You used pusha and popa instructions. These are not valid instructions on 8086 hardware. When writing robust software, we should test if the hardware is up to the task. But here the simplest solution is to only push/pop single registers.
You have interpreted the return value from the BIOS function that reads from the disk, but you just abort when an incorrect number of sectors were transferred. This is a wrong approach. When BIOS tells you about an incomplete transfer (this can happen if your BIOS is not multitrack enabled) you have to repeat the call for the remaining number of sectors. Obviously some of the parameters will have to be adjusted: next head, maybe next cylinder, and always sector=1. (A perfect solution would involve retrieving the disk geometry from BIOS or reading it from the BPB present on the disk). I assumed basic 1.44 MB floppy operation.
When reading from the disk doesn't succeed first time you should retry it a number of times. Such first time fails are perfectly normal. Five retries is a good value. In between tries you call the BIOS function that resets the diskdrive.
To make sure QEMU can actually read those additional 15 sectors you should pad this file so it has a total length of 16 sectors worth. The text you linked to did this also!

"Putting it all together"

[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

Just a comment about updating _SS:SP_ . What you say is in fact true to be compatible with the widest variety of hardware, but the main reason for CLI/STI pair is to circumvent a bug on some buggy 8088 CPUs from the 1980's. When you update the _SS_ register with a MOV instruction it is suppose to disable interrupts until after the _NEXT_ instruction. Usually that is the update to _SP_ . Unfortunately on some buggy 8088 CPUs the interrupts didn't get turned off as expected so one would explicitly use CLI/STI to avoid the bug. — Michael Petch, Dec 20 '15 at 16:08
I upvoted your answer. Will make one other little observation. You rely on _AL_ being the number of sectors read. There are some ancient BIOSes that only return a value in _AL_ if CF=1 (Yes, sounds a bit crazy but is true). Most bootloaders (targeting a wider array of real hardware) don't assume the value _AL_ can be relied upon. So generally most bootloaders read one sector at a time, or get the disk geometry (either from BPB or BDA) and only do multi sector reads that never span a track(cylinder). But your code will work with most hardware (and all the emulators I am aware of). — Michael Petch, Dec 20 '15 at 16:58

Disk Read Error while loading sectors into memory

1 Answers1

Linked