Bootloader location in memory

[tomik2256]

What is location of bootloader in RAM memory? I have two computer with UEFI and I'm using legacy BIOS settings in both but it wont load into 0x7C00. How do I know where is bootloader loaded?

[azblue]

How do you know it's not loading to 0x7c00? You implied you're on real hardware rather than an emulator, which I would think would make it rather difficult to know what's where. What does your boot code look like? Have you tried running it in an emulator where you can more clearly see what's happening?

[Muazzam]

If you want to know bootloader location just do a call and pop IP from the stack, and push it again and ret, IP (Instruction Pointer) register is location of your code into memory. There are many ways to access IP. But normally it is not accessible.

[bluemoon]

Also note that most loader use the address 00000:7C00, but it's totally legal if its not, indeed some buggy BIOS put you to 07C0:0000.

The loader code therefore should be position independent, at least in the entrance before it setup a useful memory layout.

[Gigasoft]

That's the exact same location. All PC BIOSes will load the boot sector to address 7c00h. If it then jumps to 07c0:0000 rather than 0000:7c00, it does not matter. Just don't depend on the value of CS, or use a jmp 0:xxxx instruction to fix it.

[iansjack]

It may be the same location, but it is by no means the same thing. Suppose, for example, the boot loader was 0x9000 bytes long.

[Schol-R-LEA]

That's the exact same location. All PC BIOSes will load the boot sector to address 7c00h. If it then jumps to 07c0:0000 rather than 0000:7c00, it does not matter.

Actually, while it is true that 0000:7C00 and 07C0:0000 are the same physical address, it potentially does matter how the segment and address are arranged. If you have assembled the code to use one set of segment:base addresses, and the code is loaded differently from that, then any absolute addresses will not be aligned. Fortunately, most of the jumps are relative to the current IP, including non-FAR CALLs, but there are situations where absolute segment-local addresses do rear their heads.

The solution is to adjust the segment registers as the first action of the boot sector, something that you should be doing anyway. Something like this is advisable (assuming NASM):

Code: Select all

[bits 16]
org 0x7c00

entry:
    mov cs, 0x0000
    jmp far cs:adjust        ; force the IP to the correct offset
adjust:
    mov ss, my_stack_bottom  ; set the stack to a known starting point
    mov ds, cs               ; have the local data segment overlap the code segment
    mov es, my_second_stage  ; set up any other segments you are using, as needed

This will ensure that the segment layout is what you want it to be.

tomik2256: As has been mentioned before, if you aren't already, it is highly recommended that you test your code using an emulator (e.g., Bochs, QEMU) or a virtualizer (e.g., VirtualBox, Microsoft Virtual PC) before testing on live hardware. You'll get a much faster turn-around for debugging and development, and have a safer development environment (since it can't trash your hard disks). Bochs in particular is simple to use and has built-in debugging, making it a good first-line testing environment.

[Icee]

Something like this is advisable (assuming NASM):

The idea is correct, except that there are no "mov sr, imm16" or "mov sr, sr" instructions in the x86 ISA, and "jmp far" expects a pair of immediates.

[Schol-R-LEA]

Ah, thank you for the corrections; I was working from memory, and it's been a while.

[Gigasoft]

Actually

The word "actually" is reserved for those who can actually be bothered to read all four sentences of what they're replying to.