Bad return after INT 0x15 ah=e820

[mao]

Hi!

This issue might be obvious, but maybe some could help out.

I've been writing a 64bit kernel and want to detect the memory size and layout for the kernel heap.
Since - as far as I've read and understand - grub only reports up to 4GB of RAM, I started looking at the INT 15h e820 BIOS call.

After GRUB2 handoff, I disable interrupts and do the INT 15 ah=0xe820 call, however it never returns to the caller function or ASM snippet but always to address 0xe05b.
In this case the return address should be 0x507d - so it's not an address turncation issue.

1) Any ideas what the reason might be?
2) Is there a better way to detect memory above 4GB?

I skipped the code, since I don't belive it will to be relevant. How ever if requested I will post it.

Regards,
Mao

[Octocontrabass]

After GRUB2 handoff,

Have you switched everything back to the real-mode defaults?

[mao]

No, I have not. In ignorance I assumed grub had left the state in protected mode.
That is of course not the case, the machine is in protected mode.

Thanks!

[Bender]

No, I have not. In ignorance I assumed grub had left the state in protected mode.
That is of course not the case, the machine is in protected mode.

Thanks!

<OT>
*My brain resulted in an invalid opcode exception while trying to parse the above sentence*
Here's the log:

Code: Select all

Error at sentence 2 word 12: Unexpected Word: protected
Invalid Opcode.
Failed to understand the current sentence. Moving to next one.

</OT>
Serious: Maybe you meant that you assumed GRUB left you in Real Mode, but the machine was in Protected Mode?

[sortie]

Hmm. GRUB is able to report more than 4 GiB of RAM when giving the memory map to my 64-bit multiboot operating system, for instance my desktop has 6 GB.

[hometue]

Wouldn't that be long mode (If I have learnt correctly, correct me if I am wrong here). So does that mean GRUB goes to long mode in order to accurately tell you the RAM size?

[Nable]

So does that mean GRUB goes to long mode in order to accurately tell you the RAM size?

No. One switches mode of CPU to _use_ high parts of RAM but this is not required to just enumerate usable memory. After all, the only right™ way to find accessible memory regions is to ask firmware or the bootloader that loaded your code (which is the same for GRUB, so it just asks firmware and gives you converted result).

[mao]

Yes. Grub 2 does return memory above 4GB. I can't find the references that claimed it doesn't right now. However http://wiki.osdev.org/Detecting_Memory_ ... p_Via_GRUB does explain that "GRUB simply uses INT 15h, EAX=E820"

So, this got embarrassing.

[Nable]

Yes. Grub 2 does return memory above 4GB. I can't find the references that claimed it doesn't right now. However http://wiki.osdev.org/Detecting_Memory_ ... p_Via_GRUB does explain that "GRUB simply uses INT 15h, EAX=E820"

So, this got embarrassing.

What is embarrassing here? GRUB (and BIOS function that it uses) gives you just addresses and length of memory regions. You can return 64-bit variables (and do some arithmetic operations with them) in any mode of CPU, one have to switch to unreal/protected/long mode only to use memory after these pointers.
http://wiki.osdev.org/Detecting_Memory_(x86)#BIOS_Function:_INT_0x15.2C_EAX_.3D_0xE820 - this function sets 64-bit fields in corresponding structure, so it's obvious that it's can tell you about the presence of high (even > 4G) memory regions.

[mao]

The emabrassing part is that I made assumptions about grub and did not RFTM properly.

Any how, thanks. Made som progress now.