Int 0x15 0xE820 - Get memory map

[BMW]

Ok, I am using the code from http://wiki.osdev.org/Detecting_Memory_%28x86%29 to get a memory map with int 0x15 eax=0xE820. Yes I admit I copied it, but what's the point in reinventing the wheel? (I understand the code).

It locked my OS up, so I debugged it with GDB. (I am using QEMU).

The CPU ended up executing code at 0x000000FF in an infinite loop...

I did a few memory dumps and realised that something had modified the IVT!!! (Only 1 byte was changed, the first byte).

If I comment out the call to do_e820, the IVT is not modified, so something in the do_e820 function must be editing the IVT.

This is how I call do_e820:

Code: Select all

mov ax, 0x0000
mov es,ax
mov di, 0x2100
call do_e820

That should load the memory map to [es:di] (0x0000:0x2100 = 0x2100). However, my suspicion is that it is loading it to 0x0000 for some reason, therefore modifying the IVT. In that case, either QEMU's BIOS is ****ed, the code is wrong, or I am calling it wrong.

[Minoto]

Ok, I am using the code from http://wiki.osdev.org/Detecting_Memory_%28x86%29 to get a memory map with int 0x15 eax=0xE820. Yes I admit I copied it, but what's the point in reinventing the wheel? (I understand the code).

What modification / addition did you make to get it to assemble?

[BMW]

What modification / addition did you make to get it to assemble?

Not quite sure what you mean, but I put the code into my stage 2 bootloader and called it from there. I didn't change the do_e820 function.

[Minoto]

What modification / addition did you make to get it to assemble?

Not quite sure what you mean, but I put the code into my stage 2 bootloader and called it from there. I didn't change the do_e820 function.

Okay, more specifically: I'm assuming for the moment that es and di maintain reasonable values, and that writes to memory where the destination is some form of [es:di + offset] are working as expected and not overwriting the IVT. That just leaves this near the end:

Code: Select all

.e820f:
	mov [mmap_ent], bp	; store the entry count

The code in the wiki does not define mmap_ent, so I'm assuming that you did, somewhere else. What address is being written to at this point?

[BMW]

Okay, more specifically: I'm assuming for the moment that es and di maintain reasonable values, and that writes to memory where the destination is some form of [es:di + offset] are working as expected and not overwriting the IVT. That just leaves this near the end:

Code: Select all

.e820f:
	mov [mmap_ent], bp	; store the entry count

The code in the wiki does not define mmap_ent, so I'm assuming that you did, somewhere else. What address is being written to at this point?

Oh sorry, forgot about that. I removed that line, as I will store it later on.

[Minoto]

Okay, more specifically: I'm assuming for the moment that es and di maintain reasonable values, and that writes to memory where the destination is some form of [es:di + offset] are working as expected and not overwriting the IVT. That just leaves this near the end:

Code: Select all

.e820f:
	mov [mmap_ent], bp	; store the entry count

The code in the wiki does not define mmap_ent, so I'm assuming that you did, somewhere else. What address is being written to at this point?

Oh sorry, forgot about that. I removed that line, as I will store it later on.

Well, that shoots down my hypothesis. Rather than make any more false assumptions, I'll just suggest single-stepping through that part of the code and paying attention to register contents each time it writes to memory. If it's overwriting the IVT, you should be able to see when it happens, and working backwards from there should tell you the cause.

[BMW]

Hey, when I'm stepping through the code, will the interrupt show as one instruction, or will the debugger follow the interrupt's code?

[BMW]

??????
As soon as the interrupt is called, the CPU proceeds to execute an instruction at 0xF85F...and there is nothing there...
??????

[Combuster]

And remember kids, try first before asking!

[BMW]

And remember kids, try first before asking!

Are you talking about me asking about whether the debugger follows the interrupt code? Well I have tried it but I don't know what is going on with the interrupt, as when the interrupt is called, CS:IP changes to 0xF85F and there is nothing at that memory location.

[BMW]

Oooooookkkaaaaayyyyyyyyyyyyyyyyyyyyy.......... solved

I had the do_e820 code in the 32-bit section of my Stage2... so I put a "bits 16" above it and BOOM!!! It worked!

But I thought since I was using 32 bit registers I should put it in a 32-bit code section..... I guess I'm wrong, I'll have to research that.

EDIT: I RTFM ( )
http://www.nasm.us/doc/nasmdoc6.html

Code: Select all

You do not need to specify BITS 32 merely in order to use 32-bit instructions in a 16-bit DOS program; if you do, the assembler will generate incorrect code because it will be writing code targeted at a 32-bit platform, to be run on a 16-bit one. 

Thanks for all your help guys.