x86_64 interrupt handling

[Roxxik]

1. I don't know why there was kernel relocation code. on i386 there is none. And the relocation code as it was did quite some garbage. That's why i removed it.
   It moved the memory from kernel_file + 0xB000 to kernel_file, so overwrote the kernel, and afterwards cleared 0xB000 Bytes from the end of the - now overwritten - kernel. And this memory is taken from 0x80000+ where there could be some parts from EBDA, which could have led to the Page Fault. Tried to move the kernel to some higher address(1MB+) and it worked, but i don't know if this memory is used elsewhere, and i don't see the purpose in moving the kernel. If this is needed for something and someone knows where to place the kernel, i'd be happy to put the code back.

2. Where does this MagicValue(tm) 0x18 come from? in

   mov eax, [kernel_file + 0x18]
   mov [interrupts.handler], rax
   

   It works on i386 but on x86_64 it points in the midst of zeroed memory

3. Interrupts are working now, the page fault experienced before was due to writing to protected lower memory (my theory, see above) and the kernel exception handler wasn't yet set up, which led to a triple fault.

tl;dr: We have interrupts, but I don't know where the kernel interrupt handler lives, so we can't do much with those interrupts.

[jackpot51]

The ELF entry address should be at offset 0x18. If it is not, then that must be adjusted to where it is. The entry address is the interrupt handler

[Roxxik]

Thanks for that hint, i'm currently trying to figure out why my dissasmbly doesn't match what i see in the debugger.
The address within the elf File is correct, but it is not loaded, where i'd expect it...

[Roxxik]

Offset is now correct, the interrupt handler is called correctly, but there is still some page fault in the kernel and the page fault handler itself faults, leading to a triple fault. I'll look into this later.

[Roxxik]

Now i know, why the kernel relocation led to a page fault, after writing to 0x81000.
Right there are the startup page tables

[jackpot51]

That's good work. The relocation was being done because ELF had placed the text section ahead of where it should be, use readelf -l build/x86_64-unknown-redox/debug/kernel.bin to see.

You should send an email to [email protected] asking for a chat invite from the address you want to use, we do discussion of internals there.

[Roxxik]

Oh thanks, i'll do that immediately.

I think the current kernel is too big to fit into low memory, which provides us at most 512KiB continuous Memory, and only after overriding the BIOS IVT and BDA and our Boot Sector

0x000000 - 0x0004FF (reserved) used by BIOS, do not override until the bios is no more needed
0x000500 - 0x007BFF ( usable ) unused, stack pointer grows from 0x7C00 downwards(currently)
0x007C00 - 0x007DFF ( usable ) Boot Sector, loaded from BIOS
0x007E00 - 0x07FFFF ( usable ) Unused, the kernel will be loaded here(currently)
0x080000 - 0x09FBFF (reserved) should be free, not sure, there might be some EBDA here
0x09FC00 - 0x09FFFF (reserved) EBDA, on most computers (varies from vendor to vendor)
0x0A0000 - 0x0FFFFF (reserved) video memory
usable after A20-Line is enabled
0x100000 - 0xEFFFFF ( usable ) upper memory
0xF00000 - 0xFFFFFF (reserved) ISA memory hole

kernel needs 517KiB, 394KiB after stripping
Paging needs 12KiB, 3 tables
stack needs ???
Memory Map needs some memory too, with current bochs settings it needs 78 Bytes, could be more with more memory or other BIOS, i don't know

this is in total (assuming 1KiB stack and 1KiB Memory Map) 408 KiB, after striping the kernel (i don't know if it boots without debug information, and where all the sections land) and i don't believe the kernel is about to shrink, so we need to think about restructuring the boot process.

enabling the A20-Line earlier should leave us with enough memory to keep going (14MiB)
IMPORTANT the BIOS can NOT write to higher mem (> 1MiB) so we'd need to load the kernel piece by piece to low mem and copy it up to high mem

[jackpot51]

I agree, I wish in both 32-bit and 64-bit versions that we loaded at 1 MB. We could feasibly get into unreal mode and do a bios read of 256 KB at a time, then copy it using unreal mode to higher memory. This would be easier than switching back and forth between protected mode, I believe.

OSDev has an example that fits in a bootloader: http://wiki.osdev.org/Unreal_Mode

[ticki]

Awesome stuff, @Roxxik!

[Roxxik]

I haven't considered the memory addressing in real mode. without protected mode we can't get above 1MiB. I'd ditch this branch and reopen another one, first refactoring i386 to use Unreal Mode, to have a already working example and afterwards going to x86_64 and implementing the same thing

[jackpot51]

Found a linker script/linker command combo that will make the 64-bit elf look the same as the 32-bit elf, will try that

[jackpot51]

No need to relocate anymore

[Roxxik]

the kernel is still pretty big for low memory.... i'd like to load the kernel immediately to higher memory

[jackpot51]

Understood, but it will allow me to fix other problems with x86_64 while you work on the unreal mode loader

[jackpot51]

I am compiling a 480KB kernel.bin, just small enough to fit in 0x00007E00 to 0x0007FFFF range it is loaded in

[Roxxik]

I'd close this one after #500 is merged, because it contains the same changes as this branch

[Roxxik]

I think this can be closed after merging #500