BootLoader Configuration Script?

[havok]

So your basicly looking for 16bit real mode?

[rdos]

So your basicly looking for 16bit real mode?

No, but my kernel is loaded as a 16-bit protected mode code segment, not a flat binary. OTOH, I see no reason why you cannot also add support for booting from real-mode as well if somebody wants to make the transisition to protected mode themselves. And you might provide support for setting up 64-bit mode as well.

In essence, you should extend the current multiboot header with this (which means creating a new header):

* Mode of startup code (real mode, 16-bit protected mode, 32-bit protected mode, 32-bit flat mode, 64-bit flat mode)
* Selector of startup code (for the protected mode variants)
* Offset of startup module in the image file
* Size of startup module in the image file
* Offset of startup-procedure within startup module (initial IP/EIP/RIP)

[havok]

No, but my kernel is loaded as a 16-bit protected mode code segment, not a flat binary. OTOH, I see no reason why you cannot also add support for booting from real-mode as well if somebody wants to make the transisition to protected mode themselves. And you might provide support for setting up 64-bit mode as well.

maybe you could give an example of how your executable is setup..maybe a linker script. as far as the real mode booting that is supported by leaving the 'pmode' bit and newly defined 'Use Descriptor Tables' bit both unset would effectivly leave the system in 16 bit real mode. The 64 bit is a little bit harder as i don't have any hardware to test on i cant really do any codeing to see what features are needed how ever if someone who is working with 64 bit mode maybe that person can message me or post the proccessor initalization sequence for 64 bit mode and we can figure out what settings the bootloader can do and therefore what bits to define for 64 bit mode.


* Mode of startup code (real mode, 16-bit protected mode, 32-bit protected mode, 32-bit flat mode, 64-bit flat mode)
- This is already defined in the rouph draft of the spec.
* Selector of startup code (for the protected mode variants)
-at most i would think the boot loader should only set up 1 code and 1 data segment.... Has anyone run into a case where the bootloader needed to configure more?
* Offset of startup module in the image file
-I beleave the majority of users use either pe files or *nix's equivlent wich as far as i know both provede the offset in there tables.
* Size of startup module in the image file
-again proveded in the majority of executable formats tables.
* Offset of startup-procedure within startup module (initial IP/EIP/RIP)

The last 3 points in your list normally would not change between system startups and really between kernel rebuilds. and if your kernel is being rebuilt wouldnt it be easier just to update the executables tables?

rdos i know you said your kernel is different and im sorry to say i can't remember how so if you already explained it im sorry. I just wanted to get this post out. my weekly job dosnt leave me much time to os dev. but brings in enouph that i dont have to work weekends lol

[rdos]

maybe you could give an example of how your executable is setup..maybe a linker script.

It isn't created with a linker, but rather with a tool that adds headers to prebuilt executables, and puts them into a single file. One of these files is the kernel, which is the one that a loader needs to find, create a code selector for, and initialize by jumping to its entrypoint. The kernel module does not need to be the first file in the image, and thus its offset in the file might change between builds.

* Selector of startup code (for the protected mode variants)
-at most i would think the boot loader should only set up 1 code and 1 data segment.... Has anyone run into a case where the bootloader needed to configure more?

Yes, but the startup code might require a specific selector to be used.

* Offset of startup module in the image file
-I beleave the majority of users use either pe files or *nix's equivlent wich as far as i know both provede the offset in there tables.
* Size of startup module in the image file
-again proveded in the majority of executable formats tables.
* Offset of startup-procedure within startup module (initial IP/EIP/RIP)

Not so. The multiboot standard uses a header with a signature that provides GRUB with information about how to load the kernel. It does not need to examine PE/ELF headers if there is a multiboot header. The problem is that some information for non-flat mode OSes is missing in the multiboot header.

This discussion gave me an idea how to be able to boot RDOS with a single image with GRUB. The image build tool could put the grubloader stub first in the image, with the muiltiboot header. Might be worth testing at some point.

[havok]

ok again sorry for the delay. Decided to make it more like the current multi boot spec and include configuration information in the first K of the kernel, (or first file loaded). it will follow the current spec mostly except for 2 key differences. The signiture instead of being 0x1BADB002 will be 0x3BADBOO2. to signify the difference in spec. the signiture passed back to the kernel from the loader will be 0x4BADB002. the other differences are basicly a difference of allowing for support of more features such as bootloader setting paging giving the kernel more control over how the bootloader configures protected mode and even allowing the bootloader to configure unreal mode. And although i don't have the ability to implement any kind of 64 bit settings yet im going to set aside 4 bits (bits 12-15) for 64bit use. Please anyone who dose 64bit programming please let me know if thats enouph and what they should be named/used for.

[JackScott]

I know it's been said before, but I'd strongly suggest you have at least a quick chat with some of the Multiboot/GRUB developers, just so that you don't tread on each other's toes. Using *very* similar (1 bit of difference) "magic" numbers might not the best idea...

[havok]

I know it's been said before, but I'd strongly suggest you have at least a quick chat with some of the Multiboot/GRUB developers, just so that you don't tread on each other's toes. Using *very* similar (1 bit of difference) "magic" numbers might not the best idea...

hmmm true. thanks for the idea.

[havok]

OK so after searching for contact information for anyone connected to the multi boot spec i found 2 e-mail addresses. I sent an email to both of them sunday night and as of yet have heard nothing back. So I have decided to continue work on my boot loader as it has been discussed so far if and when i get an e-mail back I can make apropriate changes to the code. For now though it seems I'm on my own so to speak. I also figured that since im putting this much time and effort into it I might as well take it all the way and have it support the following modes also. 64 bit flat mode,64 bit pageing mode, 32 bit unreal mode, 32 bit pageing mode (all 3 flavors), 32 bit protected mode, and even 16 bit mode. (if anyone can think of any other proccessor modes please let me know). Also it will support setting up 4 gig gdt tables or 4 gig data and kernel size code tables. and the capability to either identity map video memory/biosos areas or map them to another address. Let me know if anyone is interested in helping with the 64 bit stuff. as i said i currently have no way to test 64 bit code. Also i guese this needs to be moved from theory to announcements now that its changed from possabilitys to an actual project.

[shikhin]

Hi,

Let me know if anyone is interested in helping with the 64 bit stuff. as i said i currently have no way to test 64 bit code.

If it just involves testing and debugging I can prove useful. If it involves developing 64 bit "stuff" I am not interested, since I have my own kernel on my way.

Moreover, you can PM me or contact me on #osdev (nick: Shikhin) anytime, on the above.

Regards,
Shikhin

[RaffoPazzo]

Hi, as you can see i'm quite new to the forum as a writer though i would tell my opinion, too.

The thread started (if i'm not wrong) as an idea of configuring the bootloading process using XML.

Actually the multiboot spec is writing down the requirements to interface bootloaders to OSes and i think that from this point of view choosing the format for the configuration files is not just a matter of styles.
berkus, said XML is more an overkill than an advantage for those one-time thing. I think this is true only in "my own OS" (aka stand-alone). He is right saying it's a language for data exchanging. More properly, it's a language to interface systems (or components) and the schema validation is an enhancement, since it can ensure that the XML is actually "implementing" the interface. In this sense, XML would be the best choice to configure the bootloader and the environment that the OS being loaded is expecting also because any system will, today, support XML, avoiding, in this way, the needing of supporting a dedicated configuration language (improving code re-using).

I think (and i would suggest it) that GRUB2 should introduce XML and relative schemas in the spec.

Am i wrong?

[Brendan]

Hi,

If you write a tool to handle that XML for you so that you don't have to write it manually, sure.

The main benefit of XML is that instead of writing special code to understand binary data, you only need to write special code to understand the tags and then more code to parse text and encode the text (in potentially arbitrary character encodings). It's a huge win (for hardware manufacturers and unemployed web-monkeys). For any practical purpose it's too ugly and cryptic to be human readable, and not cryptic enough to be a viable encryption scheme.


Cheers,

Brendan

[Combuster]

Add to that, if you just want a simplistic bootloader (that is, not the mythical proportions that is GRUB) adding an XML library would probably double the code size. I don't think that's worth the increase in config legibility over CSV or even space separated values.

[havok]

Unfortuantly (because it was my idea to start with ) I have to agree. XML is just not suited for bootloader configuration.. nor from what I can tell at this point any type of configuration.. Unless the XML backend is designed in such a way that could provide security. As mentioned by one of the other posts C is not suited for string work and asm is even worse. C++ would be better if you were to implement the string class early on but it still breaks down to C style strings once you get "under the hood". Through trial and error and replanning and much rethinking I have decided at least for my operating system that it is easier to use bit fields and raw data for configuration. Since my Operating system dosn't allow the user to directly modify the settings files theres no reason to make them human readable and also since the initial configuration files are built at install time theres no real reason to make them platform independent either (the 2 major benifits I see to XML ).

[Solar]

Just on a tangent... XML isn't the best choice for any kind of human-generated configuration. To edit a XML file with any kind of convenience, you need a full-blown XML editor. Or do you really want to close and indent elements manually? XML is just too verbose (and has a rather mediocre size-to-value ratio).

IMHO, XML shines whereever a human defines the interface once (through DTD, XSLT or whatever), and afterwards the XML is both generated and read by software. And even then you have to take care that you compress it before sending it over the network or archive it, because it's bulky as hell.