OSDev.org

This is a project anouncment for the Uniform Boot Interface. Its a new proposed (hopefully someday )standard to make booting simpler. It started out as a redesigned boot loader and grew over time. At this time its close to version 0.1 (first release). It is fairly close in standard to the multi-boot spec except that it allows for the boot loader configuring paging, protected mode (both 32 bit and 64 bit((both flavors))), vesa 3.0 interface, acpi interface, support for multi-core,multi-processor systems (as far as configuring and starting aditional cores and logical processors), loading additional modules and specific sections from the kernel executable. Through proper bit setting one could even set up unreal mode. My boot-loader itself is a ways off (at least a couple weeks) but the spec is almost ready for its first version.

Please take a look at it ( the url is at the bottom of this post) and let me know if anyone has ideas of other features that could be supported.

http://embos.wikispot.org/Tables

edit: Also was wondering if anyone besides me would have a use for inclusion of PCI device information in the UBI Information Block

Thank you
John

Looks promising, and if it delivers on all that I'd certainly use it! I've got a couple of questions though. Firstly, what license is the project being released under? Secondly, how far along is the actual bootloader? You say it's a couple of weeks off, but I'd like to know what stage you've actually got to with that.

JackScott wrote:Looks promising, and if it delivers on all that I'd certainly use it! I've got a couple of questions though. Firstly, what license is the project being released under? Secondly, how far along is the actual bootloader? You say it's a couple of weeks off, but I'd like to know what stage you've actually got to with that.

Right sorry forgot license. Im going to license it under the GPL license.

as far as the boot loader right now it dose memory detection, drive detection, GDT setup, protected mode switch, loading the kernel file, a very detailed verbose mode. and of course supports the kernel and bootloader configuration bit settings. all it needs to support basic boot-loader functionality is load and posisition remaining sections and jump to the entry point. although unfortuantly right now it only supports fat 12 i am setting it to accept 'fs drivers' with a very simple interface.

I like this project. If you can actually do it, I would use it for my own kernel before I would grub.

I would like to be able to have it set cr3 to a value of my choice before jumping to my kenrel(so as to be able to use a statically stored PT). This would greatly ease higher half kernel development. (But would obviously be a great pain in your @$$, if possible at all.)

TylerH wrote:I like this project. If you can actually do it, I would use it for my own kernel before I would grub.

I would like to be able to have it set cr3 to a value of my choice before jumping to my kenrel(so as to be able to use a statically stored PT). This would greatly ease higher half kernel development. (But would obviously be a great pain in your @$$, if possible at all.)

So to be clear you would like it if the bootloader could use a Page Table that the user creates? Could you give me an example maybe of how this would help I'm not to sure how this would help higher half kernel dev. Maybe I'm not understanding though.

Edit: Sorry just saw that you wanted it to be staticly created. The only issue I can see with this would be for areas that change with each machine/boot (acpi tables come to mind). If you can figure out a way around this.. Possably useing key words?? We might beable to work this in.

havok wrote:

TylerH wrote:So to be clear you would like it if the bootloader could use a Page Table that the user creates? Could you give me an example maybe of how this would help I'm not to sure how this would help higher half kernel dev. Maybe I'm not understanding though.

Edit: Sorry just saw that you wanted it to be staticly created. The only issue I can see with this would be for areas that change with each machine/boot (acpi tables come to mind). If you can figure out a way around this.. Possably useing key words?? We might beable to work this in.

Yeah, the application I had in mind was to use the ability to set cr3 to use a PD stored in my kernel image. But, on second thought, if you allow the user to specify the virtual address of their kernel, which you do, that's all that matters. I'm not sure what I thought would be advantagous about using a statically stored PD other than being able to choose the virtual address at which the kernel starts.

What I think would be a good idea is to come up with a way to be able to allow the user where to map specific areas (BIOS data area,video memory acpi tables etc) in a simple space conserving way... Any ideas?

Hello,

In my opinion, you should rather include some fields such as, containing the address of the tables, so that the Kernel can easily locate them, and re-allocate if required. That would be more neater, IMHO.

Regards,
Shikhin

Shikhin wrote:Hello,

In my opinion, you should rather include some fields such as, containing the address of the tables, so that the Kernel can easily locate them, and re-allocate if required. That would be more neater, IMHO.

Regards,
Shikhin

I had planned just to pull the Page Table address from cr3.. But I suppose we can include it in the UBI Information Block.
How ever including the address of the GDT is important.
Any other tables that im missing?

The GDT's location can be obtained through the use of sgdt. (It's not fun, but it is possible.)

Does your bootloader add the regions of memory containing the boot information(such as the UBI info block) to the e820 list? IMHO, it should. Maybe with a uniqe(as in, not used by the BIOS itself) type, defined in the UBI spec.

TylerH wrote:The GDT's location can be obtained through the use of sgdt. (It's not fun, but it is possible.)

Does your bootloader add the regions of memory containing the boot information(such as the UBI info block) to the e820 list? IMHO, it should. Maybe with a uniqe(as in, not used by the BIOS itself) type, defined in the UBI spec.

I have defined memory region type code 0xFF as being UBI information so that the kernel's memory manager dosn't mark the page tables as free. The one thing i dont like about defining region codes is that any not defined by intel (or whomever defines them) holds the right to redefine them.....

Maybe we could add a field to the memory map entry specific to the UBI??

By field, do you mean new variable in the structure? If yes, then I would say absolutely not. For 2 reasons: 1) It still makes you incompatible with the standard e820 and vulnerable to changes in the spec and 2) It breaks compatibility with existing e820 parsers(who would likely just ignore an uknown value for the type field).

You basically have 2 options: 1) Use the e820 format, with an extra type value, or 2) Make your own format. Personally, I prefer 1 because it means less work for me to support it.

TylerH wrote:By field, do you mean new variable in the structure? If yes, then I would say absolutely not. For 2 reasons: 1) It still makes you incompatible with the standard e820 and vulnerable to changes in the spec and 2) It breaks compatibility with existing e820 parsers(who would likely just ignore an uknown value for the type field).

You basically have 2 options: 1) Use the e820 format, with an extra type value, or 2) Make your own format. Personally, I prefer 1 because it means less work for me to support it.

I agree but if they end up defining values to 0xFA-0xFF it would break UBI or E820 depending where the bootloader set up paging..

havok wrote:

TylerH wrote:By field, do you mean new variable in the structure? If yes, then I would say absolutely not. For 2 reasons: 1) It still makes you incompatible with the standard e820 and vulnerable to changes in the spec and 2) It breaks compatibility with existing e820 parsers(who would likely just ignore an uknown value for the type field).

You basically have 2 options: 1) Use the e820 format, with an extra type value, or 2) Make your own format. Personally, I prefer 1 because it means less work for me to support it.

I agree but if they end up defining values to 0xFA-0xFF it would break UBI or E820 depending where the bootloader set up paging..

First, they seem to be going in order, so 0xF* is *probably* a long way off.

Second, sorry, but I don't understand how the paging setup affects the e820. Could you elaborate a little, please?

It dosnt really.
My memory manager creates a bitmap the size of memory as un allocated then marks any range with a type code above 0x1(free) as being used. This solves the problem of over lapping regions. So creating another region entry in the map marked as 0xFF would prevent my allocator from allocating pages holding the page tables.

I guese i just assumed thats how everyone did there Page level allocation map.

So to make a long answer short it dosnt affect E820 but affects memory management later on.