CODEWITHSUNDEEP
x86kernelnasmbootloaderosdev
ali
ali

Reputation: 27

Although I have defined ORG 7C00, ISO file shows D800

I'm trying to develop a bootloader. But there was one part I didn't understand. I knew that when ORG 7C00 was defined in my assembly file, the program would be loaded at disk 7C00. I compiled it as binary and created the iso file in Magic ISO. Then, when I looked at the hexadecimal version of the ISO file, I saw that the code I wrote started at the D800 address. Shouldn't it be installed at 7C00?

org 0x7C00
bits 16

start:
    cli

times 510 - ($ - $$) db 0
dw 0xAA55

https://i.sstatic.net/TFVDE.png

I also have another question. There is another bootloader signature at address D010. Why?

https://i.sstatic.net/dyZgl.png

Also, there is one more thing I want to know. I want to place some files in my ISO file and I want to read these files at this level. I do my experiments in VirtualBox. How do I read the files inside the ISO file. Or how do I run a program. So what I want to do is to place the kernel here and load it from the bootloader.

If I'm wrong, is there a resource detailing how the bootloaders are loaded and how the BIOS loads?

Upvotes: 1

Views: 77

Answers (1)

Brendan
Brendan

Reputation: 37222

I knew that when ORG 7C00 was defined in my assembly file, the program would be loaded at disk 7C00.

The ORG 0x7C00 tells the assembler that it should assume the code will be running with that starting address. It doesn't guarantee that the code will actually be run at that starting address.

Then, when I looked at the hexadecimal version of the ISO file, I saw that the code I wrote started at the D800 address. Shouldn't it be installed at 7C00?

Files don't have addresses, they have offsets. You'd hope that your code will be loaded from "offset 0xD800 in the file" to "address 0x7C00 in RAM".

There is another bootloader signature at address D010. Why?

For a bootable CD-ROM (according to my vague memory of the relevant specs); sectors are 2048 bytes, the first 16 sectors are unused and should just be zeros, then at some point after that there's a list of "boot records". The firmware is supposed to check these records to determine what to boot (e.g. so you can have one boot loader for PowerPC, one for 80x86, one for Itanium, ... and the firmware will automatically choose whichever boot loader makes sense). That 0xAA55 is part of it (but I can't remember if it's for each entry, or at the end of the list of all entries).

Note that if your boot record says "80x86, no emulation, load segment in memory = 0x1234" then the BIOS will load a whole boot loader file, won't care if there's an unnecessary 0xAA55 signature anywhere in that file, and will load it into the requested segment in memory; and that "segment in memory" is the only thing that determine the address your code is loaded (and needs to match the ORG you told the assembler in an "load_address = load_segment_in_boot_record * 16 + 0 = unknown_segment * 16 + ORG_from_assembler" way).

Alternatively; if your boot record says "emulate a floppy" or "emulate a hard disk" then the firmware will do what it's told, including the inefficient "read a 2048-byte sector and discard 75% of it to pretend sectors are 512 bytes" stuff), and including loading it at the address 0x00007C00. Of course this was intended as a work-around for ancient operating systems (e.g. MS-DOS) that were written before CD-ROM existed and couldn't have supported booting from CD-ROM properly.

If I'm wrong, is there a resource detailing how the bootloaders are loaded and how the BIOS loads?

For booting from CD-ROM; the document you want is "El Torito Bootable CD-ROM Format Specification Version 1.0, January 25, 1995" (easy to find from a web search, possibly here: https://pdos.csail.mit.edu/6.828/2018/readings/boot-cdrom.pdf ).

For booting network you want the the PXE Specification (see: https://en.wikipedia.org/wiki/Preboot_Execution_Environment - there's a link at the bottom).

For booting from floppy and hard drive there's "inherited behavior passed from one generation to the next" (and no official specification); but it's covered by about 5 thousand different tutorials that are all slightly wrong.

For booting from USB flash; there's no specification and a horrible mess ("heuristical hackery" done by firmware to try to decide if it should behave like a floppy with a BPB and no partitions or behave like a hard drive with partitions and no BPB; combined with firmware specific quirks).

Of course it's 2022 now, so it's probably a better idea to throw all this in the trash and only support UEFI, where everything is adequately specified.

Upvotes: 5

Related Questions