FAT16 bootloader

cakehonolulu · **Joined:** Thu Jun 16, 2016 9:35 am **Posts:** 37

MichaelPetch wrote:

Your DAP has moved. The bytes you are displaying no longer represent where your DAP now resides. I assume it has moved because you have made modifications to the code and data shifting the location.

You are 100% right, I didn't take into account the alignment:

Code:

0x0000000000007d30 <bogus+       0>:    0x10    0x00    0x01    0x00    0x00    0x06    0x00    0x00
0x0000000000007d38 <bogus+       8>:    0x2c    0x00    0x00    0x00    0x00    0x00    0x00    0x00

Registers:

Code:

rax: 00000000_0000422c
rbx: 00000000_00000600
rcx: 00000000_00090001
rdx: 00000000_00000080
rsp: 00000000_0000ffec
rbp: 00000000_00000000
rsi: 00000000_000e7d30
rdi: 00000000_0000ffac
r8 : 00000000_00000000
r9 : 00000000_00000000
r10: 00000000_00000000
r11: 00000000_00000000
r12: 00000000_00000000
r13: 00000000_00000000
r14: 00000000_00000000
r15: 00000000_00000000
rip: 00000000_00007cf5
eflags 0x00000202: id vip vif ac vm rf nt IOPL=0 of df IF tf sf zf af pf cf

This is right before the first int13 call

EDIT:
After using bochs debugger to see if the sector was copied on memory, after dissecting 0x600 i can find STAGE2 ��iY“R� �� which matches the sector on the hdd file where the file resides, so my next guess is that after verifying the file exists, I might have overstated some things and it's very possible that the formulas I use are wrong and the file load doesn't work due to that? (I've checked the real destination of STAGE2 on-memory and it appears blank [Should contain FA F4 "cli; hlt])

cakehonolulu · **Joined:** Thu Jun 16, 2016 9:35 am **Posts:** 37

I've been debugging and I just can't find the issue; I doubt it's an emulator specific error (Tried bochs and qemu) so, here I come again asking for some guidance...

Octocontrabass · **Joined:** Mon Mar 25, 2013 7:01 pm **Posts:** 5134

So what's it doing wrong? What have you found by debugging it? Where is your current code?

cakehonolulu · **Joined:** Thu Jun 16, 2016 9:35 am **Posts:** 37

Octocontrabass wrote:

So what's it doing wrong? What have you found by debugging it? Where is your current code?

So, the most recent code I have fiddled with is:

Code:

boot0:
        xor %ax, %ax
   mov %ax, %ds
   mov %ax, %es
   mov $0x0900, %bx
   cli
   mov %bx, %ss
   mov %ax, %sp
   mov %sp, %bp
   sti   
   cld
   mov %dl, bios_boot_drive

   xor %dx, %dx
   xor %ax, %ax
   
   mov bios_boot_drive, %dl
   
   mov number_of_fats, %ax
   mulw sectors_per_fat
   add reserved_sectors, %ax
   mov %ax, root_dir_offset

   xchg %bx, %ax

   mov sector_size, %ax
   mov $0x20, %cx
   div %cx

   xchg %cx, %ax
   mov total_fat_directory_entries, %ax
   div %cx
   add %bx, %ax
   mov %ax, data_cluster_offset

   xor %dx, %dx

.loop:
   mov root_dir_offset, %ax
   add %dx, %ax
   mov $0x0600, %bx
   mov $0x01, %cx
   push %dx
   # xchg %bx, %bx
   call read_sectors
   # xchg %bx, %bx

   mov $0x200, %bx
   mov %bx, %ax
   add sector_size, %ax

.loop_dir_entries:
   mov stage2_name, %di
   mov $0x06, %cx
   mov %bx, %si
   rep cmpsb
   je .match

   add $0x20, %bx
   cmp %bx, %ax
   jne .loop_dir_entries

   pop %dx
   inc %dx
   cmp $0x80, %dx
   jne .loop
   jmp error

.match:
   # xchg %bx, %bx
   movw 0x1A(%bx),%ax
   sub $0x02, %ax
   mulb sectors_per_cluster
   add data_cluster_offset, %ax
   mov $1, %cx # STAGE 2 Size
   mov $0x0600, %bx
   call read_sectors
   xchg %bx, %bx
   jmp $0x0, $0x1000

error:
   mov $0x0e, %ah
   mov $0x45, %al # Stands for Setup
   int $0x10
   cli
   hlt

read_sectors:
   pusha
   mov %eax, dap_sector_low
   mov %es, dap_segment
   mov %bx, dap_offset
.extended_read:
   mov $0x42, %ah
   mov bios_boot_drive, %dl
   mov $dap, %si
   int $0x13
   # xchg %bx, %bx
   jnc .read_ok

   mov $0x0e, %ah
   mov $0x52, %al # Read Failed, Retrying
   int $0x10

   xor %ax, %ax
   int $0x13
   jmp .extended_read

.read_ok:
   popa
   inc %eax
   add $0x200, %bx
   jnc .no_carry

   mov %es, %dx
   add $0x10, %dh
   mov %dx, %es

.no_carry:
   dec %cx
   jz read_sectors_exit
   jmp read_sectors

read_sectors_exit:
   ret

It looks like it fails loading the file, if you look at my previous comments, it looks like it finds it correctly so I'm a bit lost

Octocontrabass · **Joined:** Mon Mar 25, 2013 7:01 pm **Posts:** 5134

cakehonolulu wrote:

Code:

boot0:
   mov %ax, %ds

What value does AX have at this point?

cakehonolulu wrote:

It looks like it fails loading the file,

How does it fail? What is it doing that's different from what you expect?

cakehonolulu · **Joined:** Thu Jun 16, 2016 9:35 am **Posts:** 37

Octocontrabass wrote:

cakehonolulu wrote:

Code:

boot0:
   mov %ax, %ds

What value does AX have at this point?

It seems like I forgot to copy the "xor %ax, %ax" ! Corrected that, ax contains 0.

cakehonolulu wrote:

It looks like it fails loading the file,

How does it fail? What is it doing that's different from what you expect?

Last week I had different results, but now, bochs complains about:
int13_diskette: unsupported AH=42

But it's strange since I'm using an HDD and it *should* support int13 extensions on bochs

Octocontrabass · **Joined:** Mon Mar 25, 2013 7:01 pm **Posts:** 5134

cakehonolulu wrote:

int13_diskette

When you set a breakpoint at the INT 0x13 instruction, what value is in DL? Is it the same value that's in memory at bios_boot_drive? Is it the same value that was in DL when your bootloader first started?

cakehonolulu · **Joined:** Thu Jun 16, 2016 9:35 am **Posts:** 37

Octocontrabass wrote:

cakehonolulu wrote:

int13_diskette

When you set a breakpoint at the INT 0x13 instruction, what value is in DL? Is it the same value that's in memory at bios_boot_drive? Is it the same value that was in DL when your bootloader first started?

<bochs:9>
Next at t=17404879
(0) [0x000000007cf6] 0000:7cf6 (unk. ctxt): int 0x13 ; cd13
<bochs:10> r
rax: 00000000_0000422c
rbx: 00000000_00000600
rcx: 00000000_00090001
rdx: 00000000_00000080
rsp: 00000000_0000ffec
rbp: 00000000_00000000
rsi: 00000000_000e7d2c
rdi: 00000000_0000ffac
r8 : 00000000_00000000
r9 : 00000000_00000000
r10: 00000000_00000000
r11: 00000000_00000000
r12: 00000000_00000000
r13: 00000000_00000000
r14: 00000000_00000000
r15: 00000000_00000000
rip: 00000000_00007cf6
eflags 0x00000202: id vip vif ac vm rf nt IOPL=0 of df IF tf sf zf af pf cf

So, DL holds 0x80 (HDD) so it's correct!

DAP (0x7C00 Offset 0x12C = 0x7D2C)
x /16bx 0x7D2C
0x0000000000007d2c <bogus+ 0>: 0x10 0x00 0x01 0x00 0x00 0x06 0x00 0x00
0x0000000000007d34 <bogus+ 8>: 0x2c 0x00 0x00 0x00 0x00 0x00 0x00 0x00

Octocontrabass · **Joined:** Mon Mar 25, 2013 7:01 pm **Posts:** 5134

Well, that all looks good.

But you still haven't shown us the segment registers ("sreg" in the debugger).

cakehonolulu · **Joined:** Thu Jun 16, 2016 9:35 am **Posts:** 37

Octocontrabass wrote:

Well, that all looks good.

But you still haven't shown us the segment registers ("sreg" in the debugger).

Oh, sorry, I forgot:
<bochs:2> sreg
es:0x0000, dh=0x00009300, dl=0x0000ffff, valid=1
Data segment, base=0x00000000, limit=0x0000ffff, Read/Write, Accessed
cs:0x0000, dh=0x00009300, dl=0x0000ffff, valid=1
Data segment, base=0x00000000, limit=0x0000ffff, Read/Write, Accessed
ss:0x0900, dh=0x00009300, dl=0x9000ffff, valid=7
Data segment, base=0x00009000, limit=0x0000ffff, Read/Write, Accessed
ds:0x0000, dh=0x00009300, dl=0x0000ffff, valid=7
Data segment, base=0x00000000, limit=0x0000ffff, Read/Write, Accessed
fs:0x0000, dh=0x00009300, dl=0x0000ffff, valid=1
Data segment, base=0x00000000, limit=0x0000ffff, Read/Write, Accessed
gs:0x0000, dh=0x00009300, dl=0x0000ffff, valid=1
Data segment, base=0x00000000, limit=0x0000ffff, Read/Write, Accessed
ldtr:0x0000, dh=0x00008200, dl=0x0000ffff, valid=1
tr:0x0000, dh=0x00008b00, dl=0x0000ffff, valid=1
gdtr:base=0x00000000000f9af7, limit=0x30
idtr:base=0x0000000000000000, limit=0x3ff

There it goes!

BenLunt · **Posted:** Tue May 25, 2021 8:05 pm

Do you have an image file we can look at? The exact image file you are booting that is giving you the error?

Ben

cakehonolulu · **Joined:** Thu Jun 16, 2016 9:35 am **Posts:** 37

BenLunt wrote:

Do you have an image file we can look at? The exact image file you are booting that is giving you the error?

Ben

Absolutely!

I'll upload a compiled one right now!

EDIT:
https://mega.nz/file/48dEDZTI#5b2E-Yukl ... m_ELcgRQzI

There you go!

Schol-R-LEA · **Posted:** Wed May 26, 2021 10:55 am

As a side question, are you using any sort of version control system, and if so, do you have an offsite repo (on a service such as Github, CloudForge, SourceForge, Gitlab, etc. - I don't know if mega.nz provides VCS hosting, but if it does, all good) which you could share with us?

BenLunt · **Posted:** Wed May 26, 2021 6:17 pm

cakehonolulu wrote:

Code:

.loop_dir_entries:
   mov stage2_name, %di
   mov $0x06, %cx
   mov %bx, %si
   rep cmpsb
   je .match

Personally, I don't like the syntax being used here. I prefer the standard Intel (Microsoft?) syntax, but that is just me.

However, by using the syntax above, you have made a very common error.

Code:

mov stage2_name, %di

Is loading the two bytes at 0x7D20 into DI instead of loading the offset of stage2_name into DI. DI needs to be the offset of, not the value stored at DI.

Again, I am not familiar with, nor do I like this syntax, but doesn't the line need to be:

Code:

mov $stage2_name, %di

The single '$' character is missing.

With the standard Intel (Microsoft?) syntax, this would not be overlooked:

Code:

mov di, offset stage2_name

Because the 'offset' keyword is required.

Also, your SI value is 512 (0x200), so the cmpsb instruction is comparing the bytes at:

Code:

0000:0200 and 0000:5453

Your SI value should be 0x0600, yes? Probably forgot to modify it from a previous suggestion? This is where EQUATES come in really handy. hint, hint.

Ben

cakehonolulu · **Joined:** Thu Jun 16, 2016 9:35 am **Posts:** 37

BenLunt wrote:

cakehonolulu wrote:

Code:

.loop_dir_entries:
   mov stage2_name, %di
   mov $0x06, %cx
   mov %bx, %si
   rep cmpsb
   je .match

Personally, I don't like the syntax being used here. I prefer the standard Intel (Microsoft?) syntax, but that is just me.

However, by using the syntax above, you have made a very common error.

Code:

mov stage2_name, %di

Is loading the two bytes at 0x7D20 into DI instead of loading the offset of stage2_name into DI. DI needs to be the offset of, not the value stored at DI.

Again, I am not familiar with, nor do I like this syntax, but doesn't the line need to be:

Code:

mov $stage2_name, %di

The single '$' character is missing.

With the standard Intel (Microsoft?) syntax, this would not be overlooked:

Code:

mov di, offset stage2_name

Because the 'offset' keyword is required.

True! Fixed it! DI Now points to 0x7d1d (Running an x /6bx 0x7d1d shows 0x53 0x54 0x41 0x47 0x45 0x32 which translates to STAGE2)...

Quote:

Also, your SI value is 512 (0x200), so the cmpsb instruction is comparing the bytes at:

Code:

0000:0200 and 0000:5453

Your SI value should be 0x0600, yes? Probably forgot to modify it from a previous suggestion? This is where EQUATES come in really handy. hint, hint.

Ben

...and SI points to 0x0600 (Which also shows the STAGE2 ref.) so that should be good!

Changed jmp $0x0, $0x1000 to jmp $0x0, $0x0600 to account for the location where it's loaded and it works! It now loads STAGE2 off the disk! Many thanks for the input! Really appreciate your time!

OSDev.org

FAT16 bootloader

Who is online