Bootloader Paging design problem

neon · Post by **neon** » Sat Oct 06, 2007 1:58 pm

Hey everyone,

I ran into a small design issue with the bootloader, and am looking for suggestions (Before anyone says it, no GRUB stuff, please

)

You can skip to "The Problem" section below, if you want.

History

Anywhoo... I am going back to the bootloader to add more content to it, but have finally admitted it: It has horrific memory management. Actually, it has NO memory management.

This makes it harder for the bootloader to execute programs. I am trying to find a nice way for my bootloader to load and execute a 16bit hardware detection (binary/COM like) program.

However, without any memory management, I need to load and execute this program directly within memory--which I am trying to avoid.

So, I decided to add some form of virtual memory management in the bootloader, and load the Kernel and other programs in their own virtual address space. This, of course, requires some form of paging, which is where the problem is at.

The Problem

Okay, the problem is with paging. I can only enable paging inside of PMode, as in RMode, Bochs gives me an error about setting the paging bit in CR0, when the PMode bit is 0 (RMode). This is understandable, but I run into a problem, as Bochs refuses to do this in RMode. It does not triple fault, it just repediatevly gives me the same error (And a large 17KB+ log file at that :/)

How can I enable paging in PMode, go back into RMode (While still using paging), in order to execute the 16bit COM program? I cannot switch back to RMode without it crashing.

Do I have no choice, or am I forgetting, or not seeing something? Does anyone have any suggestions here at what they would do?

The 16bit COM like program needs to be 16bit, as it accesses BIOS services. Because of this, I need to load and execute it from RMode. But, without a virtual address space, I am limited to this to execute it, which is as ugly as it can get:

Code: Select all

   ; execute hardware detection utility. It is loaded at 0x4000
	call 0x400:0

Thanks

frank · Post by **frank** » Sat Oct 06, 2007 2:29 pm

Well basically the only way to have paging and 16 bit code is too use VM86 mode. You can look it up in the Intel processor manuals. The intel manuals even say that the processor will signal an error if PG is enabled without PE being enabled.

neon · Post by **neon** » Sat Oct 06, 2007 2:37 pm

I'll take a look into it.

Thanks for the suggestion

Dex · Post by **Dex** » Sun Oct 07, 2007 12:26 pm

You can use "bootprog" to load com file http://alexfru.chat.ru/epm.html#bootprog
Or Minidos is only 2K and can be use or the code as a example:
http://board.flatassembler.net/topic.php?t=5275&start=0

You can also use the above method to load more than 1 com file, like for example dos did.
If you most have memory management, you could implement a simple one, without using paging, eg Dos did not use paging.

neon · Post by **neon** » Sun Oct 07, 2007 3:44 pm

Thanks alot

I'll be looking at MiniDOS to get some ideas from it on how I might be able to execute the programs.

I went back to the Stage2 bootloader and decided to rewrite the main programs' source. This is for better stabability in booting, and, mabey, a form of memory management.

Currently, this is what it does (In order):

1. Installs initil GDT.
2. Goes into PMode.
3. Installs initil IDT for error management.

I was then going to implement paging tonight. the reason why I think this is required is that, while I do need to execute COM programs, I also need to load and execute the Kernel, as well, and mabey even load and parse bootup configuration settings.

This seems like it would be quite hard to do without any nice memory management--Even if it is just a basic implementation.

So, next up I was thinking of...

4. Enable paging.
5. Enable v8086 mode, so we can use BIOS interrupts.
6. Load and execute the hardware detection COM program (DETECT.SYS)
7. Determine Kernel Booting configuration options
8. Based on the hardware configuration, Load the HAL (HAL.DLL)
9. Load other Kernel Level drivers the Kernel will need (Like FAT12.SYS, FLOPPY.SYS, whatever...)
10. Load the kernel (KRNL.EXE), Pass bootup options and hardware info to Kernel.

...Kernel takes control. The Kernel will first initialize all kernel level drivers (Including the HAL), and interface with them when required. This insures the Kernel can initialize the computer envirement (interrupts, timing, memory and file management, program management, et al...), while remaining completely hardware independent.

What do you think?

Please keep in mind that I am always looking for suggestions, and please no GRUB.

Thanks