OSDev.org

Pure64 is a 64-bit software loader initially created for BareMetal OS. The loader gets the computer into a full 64-bit state with no legacy compatibility layers and also enables all available CPU Cores in the computer. If you need a quick way to boot a 64-bit AMD/Intel based computer that will enable all available processors and load your software then Pure64 is ideal. Pure64 keeps an information table in memory that stores important details about the computer (Amount of RAM and memory layout, number of CPU cores and their APIC IDs, etc). The Pure64 loader has been released separately so others can use it in their own software projects.

https://github.com/ReturnInfinity/Pure64

Feedback would be appreciated.

-Ian

sounds very neat.

[edit]

so this is just a second stage bootloader? Or can I actually boot my computer into 64 bit mode using your loader? (as in, do I actually need a fat32 bootloader to start out)

Also, this initializes multi-core/processor systems and gives you information on them?

This really looks quite neat, and one of the problems I've had with making a 64bit kernel is just getting to 64bit mode. Do you plan on supporting any other file systems in near future? I think an ext file system or even just a FAT12 filesystem support would be nice..

I have tested it on QEmu 0.10.6 and Bochs, it seems that there's no problem!
Good work! I'll try to test it on my laptop.

Yes, Pure64 is technically the second stage. The boot sector (included in the distribution) loads Pure64 into memory. Pure64 will then get the computer into 64-bit mode and do all the "dirty work" for you. After that Pure64 will load a file called kernel64.sys from the boot disk and execute it. In the distribution I just include the BareMetal kernel as an example.

Yes, Pure64 enables all available CPU's in the system for you. Required information (APIC ID's, Local APIC Base Address) are stored in memory. http://www.returninfinity.com/pure64.html has a link to the Manual near the bottom. The manual has the layout of the information map in it.

At the moment it will just be FAT32. FAT16 and FAT12 may be in the future... I would also like to get PXE booting at some point.

-Ian

There is no *real* source code for Pure64? There are only some basic kernels and a bootsector.

Pure64 is closed-source at the moment. It may be released as open-source at some point.

The boot sector source code is there because it was adapted from the FreeDOS boot sector.

The included kernel sources are templates to get you started. To see an example of a more featured OS that uses Pure64 check out BareMetal OS: http://www.returninfinity.com/baremetal.html

The BareMetal source code shows how you can read the Pure64 info map to make use of the available resources (like the other CPUs in the system).

Yeah. I hope it will be open source'd soon. Maybe I don't like my kernel file named kernel64.sys

quanganht wrote:Yeah. I hope it will be open source'd soon. Maybe I don't like my kernel file named kernel64.sys

HexEditor to the rescue

bubach wrote:

quanganht wrote:Yeah. I hope it will be open source'd soon. Maybe I don't like my kernel file named kernel64.sys

HexEditor to the rescue

It's not so easy to disassembly an bootloader, especially when it is mixed from 16, 32, 64 bit code, all in one place.

I think what bubach meant was to modify the hard-coded value of "kernel64.sys" in the pure64.sys binary. That is possible of course.

Pure64 currently looks for a file called pure64.cfg and loads it into memory if it is available. As of version 0.5 I intend to get Pure64 to parse the contents of that file.

pure64.cfg will be a text file that looks something like this:

The non-kernel64.sys is just joke. Situation may get more complicted, something like "i can't use Fat32" or so.

ReturnInfinity wrote:Pure64 will then get the computer into 64-bit mode and do all the "dirty work" for you. After that Pure64 will load a file called kernel64.sys from the boot disk and execute it. I

I'm afraid you didn't say if dirty work includes detecting available memory, ACPI reclaimable mem, vbe modes, vbe Protected Mode entry. Basically you need at least as good as grub but for 64bit.
If or more likely when you provided all that and maybe other info that people will want (while in RealMode with BIOS) about computer components, question arises - how well did you handle bios inconsistencies?

Just some ideas not exactly criticism.

You black site is hard to read, at least for some people; and you are a company that will surely try to appeal to as many people as possible.
And not even on your site I found what exactly gets passed into kernel, so its like - you try our product first to find out more.

quanganht: How do you mean? FAT32 was picked because it is the most compatible.

geppyfx: Detection of memory and ACPI reclaimable memory is done. In fact a copy of the E820 System Memory Map is saved to memory while still in real mode. As for VBE data that it something Pure64 does not handle. As for BIOS inconsistency I don't have to worry about that too much since Pure64 will only run on new 64-bit enabled systems. What other information from the BIOS would you find useful to have before the switch to 64-bit mode?

For the website I increased the default font size and the contrast. Is this better?
Documentation for Pure64 is here: http://www.returninfinity.com/pure64-manual.html
There is a link to it at the bottom of the main Pure64 page. Complete documentation is the goal for the next release.

I just want to state that Pure64 is an alternative. The main goal is to provide developers with an easy way to get into 64-bit mode and not worry about much of the x86 legacy world.

Thanks for the feedback! Please keep it coming as I think its good to hear from the OS Dev community.

-Ian

Ok, I have a question.

What real reason do you have for keeping this closed source? Don't you think some people would like to see how do you it and *help* you to modify and improve it?

edit:
Or maybe we would like to init VBE while still in real mode without hacking stuff around so that it goes

fat32 bootloader->our real mode code to init VBE->your boot loader->kernel

Or maybe we don't like the executable format you use. There are a lot of reasons why it would be better if we could change this to suite our needs

ReturnInfinity wrote:quanganht: How do you mean? FAT32 was picked because it is the most compatible.

Because FAT32 is not good and not fit my design