2

I'm working with a friend of mine on a simple bootloader, with no pretense of it becoming anything usable. After writing the on-screen input and output functions we moved on to writing the functions to read a sector from disk, and this is where the first problems arose. I state that both on qemu and bochs everything works fine. The same thing I can not say for the physical hardware, where I encounter the error 0x0001, which means Invalid Command.

However, I didn't find much information about this error. It seems to me that it could mean that I got some argument wrong, but I printed out all the logs on screen and didn't find any strange values that would justify this behavior.

I am booting from a flash drive. I thought that might be a problem, too (since it's not an actual floppy), but if the BIOS can load the bootsector it should have no problem loading the next sector as well.

However, here is the code for the read_sector function:

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

And here is the caller function (dl = 0):

    # ...

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

    # ...

What could we be doing wrong?

Giovanni Zaccaria
  • 341
  • 2
  • 12
  • 2
    The code seems correct. Is `drive_number` correctly initialized and correctly read back? If the bootloader is not too big, could you post it entirely? Or make a stripped-down version that reproduces the problem? – Margaret Bloom May 19 '21 at 17:44
  • Sure, the code is on [github](https://github.com/FrancescoLFM/butos), in particular the caller is in `init.s` while the callee is in `diskout.s`. The `init` function sets `drive_number` to `0x00` – Giovanni Zaccaria May 19 '21 at 17:49
  • 3
    Try moving `mov %dl, (drive_number)` *after* having initialized the segment registers :) – Margaret Bloom May 19 '21 at 17:52
  • Oh god, this makes sense, I'll try – Giovanni Zaccaria May 19 '21 at 17:53
  • I did try, and it worked. To make it work I also had not to assume that the drive number had to be zero, and use instead the value passed by the BIOS into register `%dl` as the drive number. I did that before, but it didn't work beacuse of the code segment, which was initialized to `0x07c0` instead of `0x0000` – Giovanni Zaccaria May 20 '21 at 11:15
  • 1
    Nice! If you have time, consider self answering your own question with any information that may help people facing the same problem. – Margaret Bloom May 20 '21 at 11:27

1 Answers1

3

The problem here is in the file init.s. I put a value into drive_number before initializing the code segment.

How the CPU computes a physical address

real mode memory segmentation.

When I translate this listing into machine language, the linker computes the address of drive_number by reference to the beginning of the section where it is located (in this case the .text section, which starts at address 7c00, as specified in the linker script):

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

This means that the instruction mov $0, (drive_number) gets translated into mov $0, 7c2e. However this is not an actual physical address, but only an offset. In real mode a phisical address is computed by adding the value in a specific segment register shifted by 4 bits (which is the same as multiplying by 16) to an offset (as in this case 7c2e). Often we see the notation AAAA:BBBB to indicate the address AAAA * 16 + BBBB. To determine the physical address of a place in memory used for reading or writing some sort of data, the CPU by default takes advantage of the value stored in the data segment register %ds. This means that the actual address where we're storing our data is indeed ds * 16 + drive_number.

When the BIOS jumps to the code written in the bootsector it does not assure us that the values in the segment registers are the ones we want. Therefore, at the beginning of each program we must initialize these registers to contain the values we need. If %ds isn't zero, the physical address corresponding to drive_number won't be the same after the initialization of %ds to zero, which means that this label points to a different location in memory depending on the value contained in %ds.

The BIOS tells us which drive we're booting from

The BIOS interrupt 13, 2 requires dl to contain code indicating which drive we should read from. However, there is no need to consult manual after manual to read text from the drive we are booting from: in fact the BIOS places in %dl the value corresponding to the drive we are booting from before jumping to 07c0:0000 and starting to execute the code in the bootsector. Using the code passed by the BIOS in %dl makes the code more reliable and robust.

Giovanni Zaccaria
  • 341
  • 2
  • 12