OSDev.org

I am attaching a image of the bootloader running. Jack Scott was asking how far along it is and they say a picture is worth a thousand words.

I didn't read the whole post so sorry if some of this stuff was alreadz discussed but I did take a quick peek at your link and noticed some problems:

• Not really a problem, but I see no reason for which the protected mode bit needs to be set in order to go to long mode. It doesn't even map well with the way many people go to long mode, i.e., without going through protected mode first (as documented by AMD here and show in practice on our wiki here and here).
• Bit 4 can be set without bit 6. You can't have long mode without enabling paging. Furthermore, I don't understand what you mean by bit 6 being undefined when bit 6 is not set... (You probably mean that bits 7, 8, and 9 are to be ignored.)
• It is debatable whether paging support makes any sense in a boot loader at all; not sure whether it will help the kernel or just get in its way. One solution is to leave the kernel to set it if in protected mode and use identity mapping in long mode since that's pretty much the bare minimum.
• Even if you did wish to implement paging in the boot loader, there's nothing on page tables... That's pretty funny, actually.
• Would be nice to actually provide some abstractions. The boot loader isn't really useful if it just passes the tables on to the kernel. E.g., MP tables vs. whatever you can dig from the ACPI tables vs. CPUID, ACPI vs. APM, etc.
• Support for internationalization would be nice.

How exactly is this better than the Multiboot specification?

Love4Boobies wrote:I didn't read the whole post so sorry if some of this stuff was alreadz discussed but I did take a quick peek at your link and noticed some problems:

• Not really a problem, but I see no reason for which the protected mode bit needs to be set in order to go to long mode. It doesn't even map well with the way many people go to long mode, i.e., without going through protected mode first (as documented by AMD here and show in practice on our wiki here and here).
• Bit 4 can be set without bit 6. You can't have long mode without enabling paging. Furthermore, I don't understand what you mean by bit 6 being undefined when bit 6 is not set... (You probably mean that bits 7, 8, and 9 are to be ignored.)
• It is debatable whether paging support makes any sense in a boot loader at all; not sure whether it will help the kernel or just get in its way. One solution is to leave the kernel to set it if in protected mode and use identity mapping in long mode since that's pretty much the bare minimum.
• Even if you did wish to implement paging in the boot loader, there's nothing on page tables... That's pretty funny, actually.
• Would be nice to actually provide some abstractions. The boot loader isn't really useful if it just passes the tables on to the kernel. E.g., MP tables vs. whatever you can dig from the ACPI tables vs. CPUID, ACPI vs. APM, etc.
• Support for internationalization would be nice.

How exactly is this better than the Multiboot specification?

The arguement for including paging is that it allows you to specify the virtual address of the kernel(allowing for a higher half kerne;, without any of the hacks mentioned in the wiki having to be implemented in the kernel).

The argument for paging is that you dont have to write an intermediate loader or Position Indepenent Code to setup pageing. However Pageing is completly optional there is no requriment for it to setup paging.

Bit 4 can be set without bit 6. You can't have long mode without enabling paging. Furthermore, I don't understand what you mean by bit 6 being undefined when bit 6 is not set... (You probably mean that bits 7, 8, and 9 are to be ignored.)

Thats what i meant I have been moving bit definitions around and havnt updated some of it yet to reflect the new location.

Even if you did wish to implement paging in the boot loader, there's nothing on page tables... That's pretty funny, actually.

Im not quite sure what you mean theres nothing on page tables?

Would be nice to actually provide some abstractions. The boot loader isn't really useful if it just passes the tables on to the kernel. E.g., MP tables vs. whatever you can dig from the ACPI tables vs. CPUID, ACPI vs. APM, etc.

Again not sure what you mean here. If your saying the bootloader needs to do more the collect and pass information then i agree thats why it sets up paging, sets processor modes. enables other cores and proccessors in a SMP system. etc

As far as the 64 bit stuff I have said before I have not done any 64 bit programming. I need to recompile bochs to beable to work with 64 bit mode to beable to do any testing. I have the documentation but havnt had time to really do any reading into it so the bits in the UBI spec are just place holders.

As far as being better then Multi boot I never said it was and at this point its not even a goal. Its just a different standard that i feel alot of people will rather use because it dose alot of low level setup that first time os devers struggle with.

Will it work with EFI? Netboot?

No on both at this point. If someone who uses either could send me a private message or explain on here the pseudo-code they use I would like to implement. but as for right now. Its a no on both.

Edit: Sorry Berkus just saw that you were asking if it will support those, not if it dose curently. The answer is yes to Net boot and more then likely to EFI. I must admit I had to do a quick google search for EFI when you mentioned it. At this point I don't know alot about EFI is there a solid use for it in osdev? is it hard to configure? what are the benifits of using it vs standard bios? and how common is it on hardware?

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

It looks promising, but this right here stops me from ever considering it. Thanks for the effort, though.

Lithorien wrote:

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

It looks promising, but this right here stops me from ever considering it. Thanks for the effort, though.

Just to be clear.. Is it the fact that I forgot licensing or that I'm considering using GPL for the license? And if it is the license then what license would you sugest and why?

A lot of people (myself included) don't really like the GPL because it is what is known as "viral", where if you use a piece of GPL software inside your software project, then your software project also has to be licensed under the GPL. People who don't like this usually prefer a license such as the MIT or BSD licenses, because they don't have this property.

Of course, a bootloader isn't linked with anything, so it can't cause problems by being "virally" licensed.

NickJohnson wrote:Of course, a bootloader isn't linked with anything, so it can't cause problems by being "virally" licensed.

Yeah, but it's on the same disk.. it might touch it.. icky.

I wasn't aware of that.. I will have to reconsider licensing options.. I'll post as soon as i figure something out. For the mean time consider it open source with no requirment on licensing of other code.(no viral licensing). So open it look at the source learn heck copy and paste if you want and do what you want with it. This is a learning site and how can one learn without seeing code.. Also Brynet-Inc I like your signiture except for one thing. Windows also allow things to fall through and disapear such as money, cpu cycles, hard drive space, etc

Edit: Decided to use the MIT license as follows:
Copyright (C) 2011 by John Barker

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

havok wrote:Also Brynet-Inc I like your signiture except for one thing. Windows also allow things to fall through and disapear such as money, cpu cycles, hard drive space, etc

The "nothing more" was meant to emphasize there was no other definition of the word, not to identify all that could pass through them.

Hi,

havok wrote:

Will it work with EFI? Netboot?

No on both at this point. If someone who uses either could send me a private message or explain on here the pseudo-code they use I would like to implement. but as for right now. Its a no on both.

I've used network boot (PXE), and it is relatively easy if you're used to the normal boot process on PC BIOS. In general, the network card's ROM downloads your boot loader from a (properly configured) server and jumps to it; and provides an API that can be used to download more files from the server (and/or use the inbuilt networking stack to do other things if you want). There's a good introduction in the wiki's "Diskless booting" page to get you started; and if you need to know something that isn't clear in the specification you can ask on the forums (where other people can also help, so you're not just stuck with my advice) or PM me directly.

havok wrote:I must admit I had to do a quick google search for EFI when you mentioned it. At this point I don't know alot about EFI is there a solid use for it in osdev? is it hard to configure? what are the benifits of using it vs standard bios? and how common is it on hardware?

Quick history: EFI was invented by Intel in the "mid 1990's", partly for Itanium but also as something that could be used on 80x86 to remove limitations with "PC BIOS". Intel create the "Unified EFI Forum" to continue development of UEFI/EFI in 2005; and the UEFI people have maintained and extended Intel's original specification and Intel's (open source) code since. For 80x86, mainstream OSs (except OS X) were a little slow to adopt EFI; but the last mainstream OS (Windows) started supporting EFI in 2008, and now all mainstream 80x86 OSs support EFI.

At the moment, all 80x86 Apple machines support EFI and a growing number of "white box" 80x86 machines support it too. I'd estimate that around 10% of all (desktop/server) 80x86 machines sold this year will support EFI; and (now that all mainstream OSs support it) that this will increase faster than it has in the past - maybe in 5 years it'll be supported by around 50% of 80x86 computers. There's also at least 2 emulators (VirtualBox and Qemu) that support EFI now too.

EFI is both simpler than PC BIOS and more complex. Simpler because all the legacy crud is gone (e.g. no real mode, no A20, etc) and because there's a consistent interface (e.g. unlike "PC BIOS" where you need slightly different boot code for booting from different devices, for EFI the exact same boot loader can work regardless of what you're booting from). More complex because EFI is sort of like a small OS, with it's own file system, it's own drivers, it's own shell, etc; and unfortunately (apart from in the official EFI/UFI specifications), there isn't much good information for EFI development on the internet, and not very many people who are familiar with EFI development who can help or answer questions.

To be honest, for (amateur) OS developers like us I've been getting a little worried about the rate of EFI adoption. An OS developer needs to look at what hardware will be around when their OS is "finished" and not what hardware is around now. As a community, to avoid the risk of being left behind, we need more information about using and developing for EFI in the wiki, and more people who are familiar with EFI that are willing to help others in the forums.

I started writing a boot loader for EFI about 5 weeks ago; but my progress has been very slow - mostly because I'm (supposed to be) a full-time student at the moment, partly because of Minecraft (!) and partly because EFI is all new to me and not really suited to assembly language programming. In any case, if you need to know something that isn't clear in the specification you can ask on the forums (where someone might be able to help, and where replies might become useful for other/future OS developers) or PM me directly (so we can be confused together ).


Cheers,

Brendan

Wow Brendan Great post very informative. From that looks like net-boot shouldnt be an issue in support. EFI on the other hand I think ill hold off on until i at least have a 1st version boot-loader supporting UBI, which like I said shouldn't take much longer. Depending how much time I have this week I may at least get the 32 bit stuff and pageing stuff done. It can already build a GDT, switch to protected mode. Load an windows 32 exe. ( i do intend for it to support other formats also). Gather all information except acpi tables and vesa tables. I intend to have both of those done by end of the day today.

Could you make it multiboot compatible? As in, able to be booted by a multiboot bootloader. I'm cautious about installing a home brewed bootloader and would rather use it as a second stage loader. (Maybe a second stage bootloader is more necessary than a whole bootloader.)

Of course you could, the real question is whether you really want that at all. The Multiboot specification isn't particularly good for anything other than loading images with GRUB legacy, as there aren't many Multiboot-compliant boot loaders out there, and Multiboot 2 isn't seeing a lot of progress...