iansjack wrote:
There are hacks to do what you want but, in my opinion, it's better to keep the 32- and 64-bit code separate. I use Grub which loads the 32-bit code as the main kernel and the 64-bit code as a separate module. It works beautifully and it just seems more elegant this way. If you want to roll your own boot loader, just make it act the same way.
I got a quote for this
Adam Savage wrote:
I reject your reality and substitute my own.
(^ that's not meant offensively)
Yes, I fully comprehend and understand what you are saying; but the design I have does not allow for this.
I have thrown out every standard concept of POSIX and the standard way an OS is loaded. Which means that most everything in my code would be considered a "hack" by most everyone on here.
So I found myself in this situation due to a "chicken and egg" scenario, which I shall *attempt* to explain:
There are 3 stages to my OSLoader:
Stage 1 - MBR/VBR, This just loads Stage 1.5 and has a public "ReadFile" function.
Stage 1.5 - The First Binary ["SysInit.bin"] <- This is where the "chicken & egg" comes it
Stage 2 - The linker
So, Stage 1.5 does the following (may not be in order):
1. Checks CPUID to determine x86 or AMD64
2. Installs proper GDT for the system
3. Loads a less limited driver for the boot device (main entry point is 32-bits, but is still allowed to use BIOS for I/O) <- This is no issue as I can get NASM to output elf32-i386 to link to the C source
4. Load Stage 2
Due to Stage 2 requiring malloc and vmm_map to properly link everything without carrying the relocation tables around I have decided to load and initialize both memory managers (between step 3&4 above)
Now this will load in the memory managers based on the detected CPU, but as we know to get to Long Mode you must have a page directory - so I want the initialization function to be 32-bits (which is fine if I create this function in ASM - but due to it only being called once I really don't want to spend the time and prefer C here)
I thought about having Stage 1.5 create a temporary PDIR and load the PMM and VMM in stage 2, but the issue here is the hackish way I would have to load and link to the current running BINARY (not elf) - which I have done with a variable though I hate hard-coding function locations where I need not.
(I hope that made sense, as I was distracted many times while trying to write this...)
I understand what I am doing, I just don't think I'm able to properly explain it
Stage 2 takes the objects either elf32-i386 or elf64-x86-64 without me having to send through LD - so anything after Stage 1.5 the issue does not exist.
But would you have any information on these "hacks" you mentioned?
Best regards,
B!