Pregunta

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.

¿Fue útil?

Solución

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.
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top