OSDev.org

Hello everyone,

I have put up a pre-release version of my 64-bit OS loader on the internet.
UPDATE: The first official release (v0.1) is now available

Screenshot of Pure64 loading BareMetal OS.


Not much documentation at the moment but it does work.

What Pure64 does:
Pure64 sets up a clean 64-bit environment for you so you can focus on the kernel of your OS.

Getting started:
Two very simple kernels are included to get you started with your new 64-bit OS (One written in Assembly, the other in C).
A 64MB disk image is included with the proper boot sector so you can run your new OS in a virtual machine.

Requirements:
A drive formatted with FAT32
Your own 64-bit kernel (named kernel64.sys)

http://www.returninfinity.com/pure64.html

Comments and questions are welcome!

-Ian Seyler
http://www.returninfinity.com

Nice work! The 'asm_kernel' directory in the download is empty -- is there meant to be some code in there?

M

Hi there,

Just wondering (without downloading and poking through the source files) what the license for this project was?

Thanks

Maybe slightly off-topic, but IMHO they should use some reserved bit in the Multiboot specification to extended it for 64-bit OSes. Currently you have to jump to 64-bit mode in the kernel if you want it to be compliant.

Have you suggested that to the people who make GRUB? I'm sure if somebody thought up a good way to do it, they would at least consider it. If you don't suggest it, they will never know.

Thanks Mike. Yes, there will be files for an Assembly kernel but I have not written one yet. This was just a pre-release but it will be in the final 0.01 version. Expect more documentation as well.

JackScott, Pure64 (The component that gets the computer in 64-bit mode and loads the kernel) is currently binary only. A future version could be open source. The include bootsector is released under the GPL (Since it was modified from FreeDOS).

All other code is free to use however you want.

-Ian

JackScott wrote:Have you suggested that to the people who make GRUB? I'm sure if somebody thought up a good way to do it, they would at least consider it. If you don't suggest it, they will never know.

I doubt that nobody thought of it. However, I will send them my oppinion and some ideas on how the Multiboot spec could easily be extended.

http://grub.enbug.org/MultibootIdeas

See the bottom of that page, someone's already suggested it. Don't know if it's implemented, though.

AlexExtreme wrote:http://grub.enbug.org/MultibootIdeas

See the bottom of that page, someone's already suggested it. Don't know if it's implemented, though.

It was me suggesting that a few months ago. I don't know if they'll implement it though. I haven't written to their mailing list yet, which might be a good way to get in contact.

Walling wrote:It was me suggesting that a few months ago. I don't know if they'll implement it though. I haven't written to their mailing list yet, which might be a good way to get in contact.

The GRUB guys don't seem to be checking stuff like their wiki, or even their bugtracker. I filed a bug report with a patch to fix GRUB2's broken PXE module quite a while ago and haven't had a single response.

Just a quick update. SMP initialization is slowing coming along in Pure64. The MP configuration is parsed, the Local APIC enabled, and the AP's in the system are awoken. The AP's currently execute the code and increment a counter to show that they ran it properly. The AP's are still in real mode as I get a triple fault when putting them into 64-bit mode.

Has anyone worked with 64-bit SMP before? Does each CPU need its own PML4 or can I point all CPU's to the same one?



-Ian

Hi,

My 64 bit kernel uses the same PML4 for each core initially. After that, each CPU runs the scheduler initialisation function and they can be running with either the same PML4 or a different one, depending on whether they are running threads from the same task or are running two entirely separate tasks.

Cheers,
Adam

Thanks for the info AJ. I thought I might have needed multiple tables.

The triple fault issue has been fixed. Looking at the crash log in QEMU I saw that the AP's were not getting the GDT address loaded.

I had this: But this is the one that works: So all processors in the system are now in 64-bit mode!!!

Looking good, any plans to add at least basic multiboot support?

At the moment no. What advantage does multiboot give?