This forums is for OS project announcements including project openings, new releases, update notices, test requests, and job openings (both paying and volunteer).
A new version has been posted. v0.1 is the first official release that contains cleaned up SMP code as well as processor speed detection.
Documentation is still pretty limited as I have been focusing on the development of Pure64 itself.
Now I will be working on finding an easy way to allow the kernel developer to access the other CPU's in the system. Currently the AP's just sit in a loop waiting for something to do.
See the first post for the latest info (and screenshot )
-Ian
BareMetal OS - http://www.returninfinity.com/
Mono-tasking 64-bit OS for x86-64 based computers, written entirely in Assembly
Just a method of passing information to the kernel from the loader. IE, to prevent it from having to go back to real mode to get a memory map.
I haven't tried your loader yet, but you say it sets up SMP and does various things like detect the processor speed. Whats the point? If your not going to pass it to the kernel, then it should be done by the kernel, not the bootloader.
I do agree with you that in its current state is is kind of useless to calculate the speed of the CPU and activate the other processors in the system without giving the kernel a way to find out what Pure64 actually did.
This is what I am working on at the moment. I have been figuring out a format for a table in memory that would contain all of this valuable information (CPU/MEM/HDD info, etc). Stay tuned for the updates!
As for multiboot I probably won't support it. Multiboot looks like it is geared for 32-bit which doesn't really apply to what I am doing here.
-Ian
BareMetal OS - http://www.returninfinity.com/
Mono-tasking 64-bit OS for x86-64 based computers, written entirely in Assembly
Not to mention the draft is still incomplete and rather vague in some areas. Last I checked, GRUB 2 still didn't properly implement either multiboot as it is in GRUB Legacy or as it is in this draft. However that was quite long ago, and the situation may be better now. I did read the other day a mailing list post... somewhere... that I believe said the state of GRUB2 still wasn't much better.
IMO the GRUB2 devs seem to be focusing more on value-added features like pretty menus and such than getting the real functionality a bootloader needs working correctly.
I suppose I'll take the time this weekend to look in to GRUB2 again so I can have a more informed opinion. Until then take this post with a grain of salt.
Grub2 does need to be very user-friendly (or user-dumb) not to mention the majority of their donations come from these 'user friendly' linux distrobutions.
OrOS wrote:Grub2 does need to be very user-friendly (or user-dumb) not to mention the majority of their donations come from these 'user friendly' linux distrobutions.
I wasn't saying it shouldn't be user friendly. I was just saying that last I tried it, half the functionality a bootloader would be expected to have (like loading a binary and running it) still wasn't there. Okay, well, so it could load a binary and execute it when I last tried Grub2, but it did not properly implement any multiboot spec. And the documentation is severely lacking, although there's some docs about it in Debian that will hopefully be picked up.
Keep the good work up my good man! I have an interest in seeing this get done. You have an interest in seeing your bootloader used in my project since its going to be BIG (yes this is a revival of the commune project).
In all seriousness though what all is the bootloader going to make a list of in its system component list? I need to know so I can plan my kernel setup code.
It will at the very least include information about the CPU's (Speed, amount, APIC IDs), Memory (Total available MB, a copy of the E820 map), and storage.
Anything else you would need?
BareMetal OS - http://www.returninfinity.com/
Mono-tasking 64-bit OS for x86-64 based computers, written entirely in Assembly
I'm noticing one thing about this code that I would love if someone else could confirm... Does the system ever enter protected mode during this process? From what I can tell it doesn't but I may not know all the tricks.
Can you elaborate on your question about protected mode? If you are referring to Pure64 it jumps directly from 16-bit real mode to 64-bit protected mode.
-Ian
BareMetal OS - http://www.returninfinity.com/
Mono-tasking 64-bit OS for x86-64 based computers, written entirely in Assembly
)
