OSDev.org

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

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

The new multiboot draft is geared towards 64-bit extensions.

Yeah, you can find the draft here.

Love4Boobies wrote:Yeah, you can find the draft here.

It still mentions VSTa. How out-of-date can one be???


JAL

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.

After some code cleanup Pure64 is now working on physical hardware. (1 bit can cause so much debugging pain).

Test system is a Dual Core Celeron @ 1.6GHz with 2048MB of RAM. Booting from a 64MB Compact Flash card via a Compact Flash to IDE adapter.

Picture is here:
Picasa

Next step is finalizing the system component list so the OS can figure out what Pure64 did and what state the PC is in.

-Ian

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?

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.

He may be using the direct to long mode trick that Brendan posted on the wiki.

Hi chezzestix,

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