1

I am trying to understand why lseek() is used in this image creator. Why 5 bytes away from start of file? If I changed that number, the OS won't boot.

The image creator creates a .img file with the bootloader.bin inside.

/* modify the sector count */



total_sector_number = file_size / 512

lseek(disk_image_fd, 5, SEEK_SET);
write(disk_image_fd, &total_sector_number, 2);
write(disk_image_fd, &kernel_32_sector_number, 2);

//printf("%d\n", lawl);
printf("TOTAL_SECTOR_NUMBER : %d\n", total_sector_number);
printf("KERNEL_32_SECTOR_NUMBER : %d\n", kernel_32_sector_number);

The source code (image maker): http://pastebin.com/raw.php?i=MuDpYP3Y

Bootloader: http://pastebin.com/raw.php?i=kzw2ZaU1

The hexdump with lseek() and writing umber of sectors to byte at offset 5: enter image description here

Without lseek() OS does not boot correctly.

Quaxton Hale
  • 2,460
  • 5
  • 40
  • 71
  • Rather obviously, because that is the location where this unnamed "OS" or bootloader expects to fund this information. – Chris Stratton Mar 20 '14 at 04:06
  • I'm vaguely recalling that the first 5 bytes are a branch to the start of the actual boot loader. After the sector has been read in control branches to the first location in the sector. – Hot Licks Mar 20 '14 at 04:06
  • I thought the bootloader starts at 0x07C0? [ORG 0x07c0] and ax and all of the segment registers are set to 0x07c0 – Quaxton Hale Mar 20 '14 at 04:43

1 Answers1

1

I only figured this out because of your previous post Bootloader memory location which contained different source code for the bootloader.

You mentioned the two unknown variables TOTALSECTORCOUNT and KERNEL32SECTORCOUNT. These variables were near the beginning of the file, and I guess when assembled they sit 5 bytes into the binary. Calling lseek with the SEEK_SET parameter moves the file pointer to 5 bytes after the beginning of the file. It then writes the two values which will overwrite the ones in the bootloader code.

When you remove the lseek it will instead append the two values to the end of the file. If you changed the offset parameter of lseek to zero it would overwrite the jmp command of the bootloader instead.

Notice in your hexdump.

00000000 00eb b8fa 02c0 0000 c000 e08e e88e 00b8
                     ^    ^- kernel_32_sector_number is never initialized.
                     |-total_sector_number which was calculated in code before the write.
Community
  • 1
  • 1
Breavyn
  • 2,232
  • 16
  • 29
  • I haven't written the kernel yet, so that is why it's 0. The bootloader still loads/runs fine. However, if I deleted the lseek() call and the two write calls afterwards, the OS fails to load. I wonder why that is? Since I'm not really using the total_sector_number or the kernel_sector_number. Shouldn't the bootloader load just fine? – Quaxton Hale Mar 20 '14 at 08:11
  • I can even pass in false values for both variables. And it would run fine, so this really confuses me. – Quaxton Hale Mar 20 '14 at 08:20
  • can you pastebin the **exact** code you are using right now for the bootloader and image writer? And are you using NASM? – Breavyn Mar 20 '14 at 08:25
  • It just so happens that there is an error in your bootloader. It is just lucky that the image writer overwrites your wrong code and by some extreme coincidence it runs – Breavyn Mar 20 '14 at 09:12
  • Are those two place holders necessary? Because I had commented out the two write commands. – Quaxton Hale Mar 20 '14 at 09:18
  • Can you give me some way to contact you? Comments aren't the place for these discussions. – Breavyn Mar 20 '14 at 09:20
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/50109/discussion-between--and-colin-gillespie) – Quaxton Hale Mar 20 '14 at 09:21