Disk error 0x0C80 when trying to load data from disk.

Gigaboy · **Joined:** Wed Aug 23, 2017 1:09 pm **Posts:** 20

When I run my OS with Qemu I get disk error 0x0C80 from the boot sector when trying to load data from disk. I looked to see the error at this web page and it says "unsupported track/invalid media". I don't know what that means please help me. This is the dropbox link for my files.

iansjack · **Posted:** Wed Aug 23, 2017 1:57 pm

It might help to post a few details. Is this the only partition on the disk? What format is it? What does your boot sector look like? How did you write the sector to the disk image?

Gigaboy · **Joined:** Wed Aug 23, 2017 1:09 pm **Posts:** 20

There is 3 partitions on disk.

The OS is on the 3rd partition in ext4 file format. This is the boot sector code.
Boot_sector.asm:

Code:

[org 0x7c00]
KERNEL_OFFSET equ 0x1000 ; The same one we used when linking the kernel

    mov [BOOT_DRIVE], dl ; Remember that the BIOS sets us the boot drive in 'dl' on boot
    mov bp, 0x9000
    mov sp, bp

    mov bx, MSG_REAL_MODE 
    call print
    call print_nl

    call load_kernel ; read the kernel from disk
    call switch_to_pm ; disable interrupts, load GDT,  etc. Finally jumps to 'BEGIN_PM'
    jmp $ ; Never executed

%include "boot/print.asm"
%include "boot/print_hex.asm"
%include "boot/disk.asm"
%include "boot/gdt.asm"
%include "boot/32bit_print.asm"
%include "boot/switch_pm.asm"

[bits 16]
load_kernel:
    mov bx, MSG_LOAD_KERNEL
    call print
    call print_nl

    mov bx, KERNEL_OFFSET ; Read from disk and store in 0x1000
    mov dh, 16 ; Our future kernel will be larger, make this big
    mov dl, [BOOT_DRIVE]
    call disk_load
    ret

[bits 32]
BEGIN_PM:
    mov ebx, MSG_PROT_MODE
    call print_string_pm
    call KERNEL_OFFSET ; Give control to the kernel
    jmp $ ; Stay here when the kernel returns control to us (if ever)


BOOT_DRIVE db 0 ; It is a good idea to store it in memory because 'dl' may get overwritten
MSG_REAL_MODE db "Started in 16-bit Real Mode", 0
MSG_PROT_MODE db "Landed in 32-bit Protected Mode", 0
MSG_LOAD_KERNEL db "Loading kernel into memory", 0

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

Disk.asm

Code:

disk_load:
    pusha
    ; reading from disk requires setting specific values in all registers
    ; so we will overwrite our input parameters from 'dx'. Let's save it
    ; to the stack for later use.
    push dx

    mov ah, 0x02 ; ah <- int 0x13 function. 0x02 = 'read'
    mov al, dh   ; al <- number of sectors to read (0x01 .. 0x80)
    mov cl, 0x02 ; cl <- sector (0x01 .. 0x11)
                 ; 0x01 is our boot sector, 0x02 is the first 'available' sector
    mov ch, 0x00 ; ch <- cylinder (0x0 .. 0x3FF, upper 2 bits in 'cl')
    ; dl <- drive number. Our caller sets it as a parameter and gets it from BIOS
    ; (0 = floppy, 1 = floppy2, 0x80 = hdd, 0x81 = hdd2)
    mov dh, 0x00 ; dh <- head number (0x0 .. 0xF)

    ; [es:bx] <- pointer to buffer where the data will be stored
    ; caller sets it up for us, and it is actually the standard location for int 13h
    int 0x13      ; BIOS interrupt
    jc disk_error ; if error (stored in the carry bit)

    pop dx
    cmp al, dh    ; BIOS also sets 'al' to the # of sectors read. Compare it.
    jne sectors_error
    popa
    ret


disk_error:
    mov bx, DISK_ERROR
    call print
    call print_nl
    mov dh, ah ; ah = error code, dl = disk drive that dropped the error
    call print_hex ; check out the code at http://stanislavs.org/helppc/int_13-1.html
    jmp disk_loop

sectors_error:
    mov bx, SECTORS_ERROR
    call print

disk_loop:
    jmp $

DISK_ERROR: db "Disk read error", 0
SECTORS_ERROR: db "Incorrect number of sectors read", 0

iansjack · **Posted:** Wed Aug 23, 2017 2:46 pm

Am I right in assuming that your OS code is stored in sectors 2,3, etc. of the third partition? (Note that this will have destroyed the ext4 filesystem? How did you write it to those sectors?

What you are reading is sectors 2,3,etc. of the physical disk, not the partition. And you need to know the geometry of the disk to use this BIOS call.

I'd recommend that you start of by booting from a floppy image rather than a hard disk one as you don't then have the complication of partitions and you have a known disk geometry. (Really, I'd recommend that you use a boot loader such as GRUB rather than reinventing the wheel, but that's an argument that's been thrashed out many times.)

MichaelPetch · **Joined:** Fri Aug 26, 2016 1:41 pm **Posts:** 692

How big is the disk image file you are booting from? I'd expect you might get that error if the number of sectors is less than 17 (1 for the boot sector and then 16 for the additional 16 sectors you read starting at sector 2). I'm almost thinking the disk image file you are booting from < 17*512=8704 bytes in size. QEMU will error out if you read more sectors than are physically in your disk image.

simeonz · **Joined:** Fri Aug 19, 2016 10:28 pm **Posts:** 360

Either I am not looking at the right place, or you are not initializing "es". Note that qemu will spit 0xc error for pretty much anything other than basic preliminary argument check failure. (I skimmed the seabios emulation code, and it pretty much has an "if op fails, say it is bad geometry.")

Also, note the previous comments, because even if the read succeeds, you will probably have other problems to deal with.

MichaelPetch · **Joined:** Fri Aug 26, 2016 1:41 pm **Posts:** 692

simeonz wrote:

Either I am not looking at the right place, or you are not initializing "es". Note that qemu will spit 0xc error for pretty much anything other than basic preliminary argument check failure. (I skimmed the seabios emulation code, and it pretty much has an "if op fails, say it is bad geometry.")

Yep, he doesn't explicitly set ES or DS nor is he even setting SS:SP (only SP). He's only lucky they appear to be working. I don't think though that is the reason he is not able to read. 0x0C return code from Int 13 read suggests there is something wrong with the disk image IMHO.

simeonz · **Joined:** Fri Aug 19, 2016 10:28 pm **Posts:** 360

MichaelPetch wrote:

simeonz wrote:

Either I am not looking at the right place, or you are not initializing "es". Note that qemu will spit 0xc error for pretty much anything other than basic preliminary argument check failure. (I skimmed the seabios emulation code, and it pretty much has an "if op fails, say it is bad geometry.")

Yep, he doesn't explicitly set ES or DS nor is he even setting SS:SP (only SP). He's only lucky they appear to be working. I don't think though that is the reason he is not able to read. 0x0C return code from Int 13 read suggests there is something wrong with the disk image IMHO.

I agree. It may be something completely different. It probably is. But apparently qemu is not very fine grained in expressing the cause of the error.

Here is the end of the ata_readwrite function in the seabios emulation:

Code:

    int ret;
    if (usepio)
        ret = ata_pio_cmd_data(op, iswrite, &cmd);
    else
        ret = ata_dma_cmd_data(op, &cmd);
    if (ret)
        return DISK_RET_EBADTRACK;
    return DISK_RET_SUCCESS;

Now, it is true that int 13 jumps a few hoops before it reaches here, but for service 2, the only other code that seems to be returned is DISK_RET_EPARAM (0x1), in case more than 128 sectors are requested, no sectors were requested, or sector 0 was requested, as well as when the CHS doesn't match the geometry. Unless I missed a branch, all other cases end up here (for ATA that is), which means they return DISK_RET_EBADTRACK (0xc) for all errors. Other disk emulation variants are similar in that regard. So, my point is, not much can be read into the error code itself. It could be anything, including bad buffer location.

MichaelPetch · **Joined:** Fri Aug 26, 2016 1:41 pm **Posts:** 692

simeonz wrote:

return DISK_RET_SUCCESS;[/code]Now, it is true that int 13 jumps a few hoops before it reaches here, but for service 2, the only other code that seems to be returned is DISK_RET_EPARAM (0x1), in case more than 128 sectors are requested, no sectors were requested, or sector 0 was requested, as well as when the CHS doesn't match the geometry. Unless I missed a branch, all other cases end up here (for ATA that is), which means they return DISK_RET_EBADTRACK (0xc) for all errors. Other disk emulation variants are similar in that regard. So, my point is, not much can be read into the error code itself. It could be anything, including bad buffer location.

I finally decided to revisit this. I took his code added a print_hex routine (can also observe it in QEMU/GDB debugging session). I created a disk image of exactly 17 sectors (8704) bytes and ran his code. It worked. I ran it with 16 sectors (8192) bytes and received 0x0C.

OSDev.org

Disk error 0x0C80 when trying to load data from disk.

Who is online