OSDev.org

I DON'T want to code GDT in assembly. Holy **** C does not work with 16 bit code...

I give up. Not once did I in this thread say anything about using C in real mode. You just do not care to listen.

It seems that you are discomforted while coding in Assembly, and that is very bad for OS developement.
You don't have to use Grub; try some copyleft bootloader and modify its code within your needs.

neon wrote:

I don't want to code GDT in assembly. Holy **** C does not work with 16 bit code...

I give up. Not once did I in this thread say anything about using C in real mode. You just do not care to listen.

Maybe I replied to a wrong person, sorry I am really messed up.
Edit: you were talking about 32 bit code that I was referring to.
If the kernel is going to be a 32 bit C image, then the system better already be in 32 bit protected mode

Lukand wrote:It seems that you are discomforted while coding in Assembly, and that is very bad for OS developement.
You don't have to use Grub; try some copyleft bootloader and modify its code within your needs.

C is my primary language. Assembly is something that I know just a little, just enough.
Not going to do anything. Deleting Basic OS Revision 3. I am going to use GRUB and start working on Basic OS Revision 4.
I guess I will just have to suffer while trying to return to real mode and initialize VBE. That is it. Nobody really read what I asked or tried to answer that.
Topic closed.

Why would you want to use real mode directly? GRUB can set the video mode and load files for you. Anyway returning to real mode is not a difficult task.

Edit: oh, you've changed your mind.

I think everybody read what you asked... You just didn't like the replies.

Coding a basic GDT in assembly is no harder than doing it in C.

Set up a stack where you please (and it won't be overwritten by the loader), it's just going to be temporary.

If you're using a filesystem, you need to be able to code some way to locate and load stage 2 of your loader (written in C) off of hard disk. There's plenty of example code out there.

Roman wrote:Why would you want to use real mode directly? GRUB can set the video mode and load files for you. Anyway returning to real mode is not a difficult task.

Edit: oh, you've changed your mind.

I don't want GRUB to set my video mode directly. Because then I cannot give user an ability to choose between wanted video modes. I will make a screen that asks you to press a co-responding key.

crunch wrote:I think everybody read what you asked... You just didn't like the replies.

Coding a basic GDT in assembly is no harder than doing it in C.

Set up a stack where you please (and it won't be overwritten by the loader), it's just going to be temporary.

If you're using a filesystem, you need to be able to code some way to locate and load stage 2 of your loader (written in C) off of hard disk. There's plenty of example code out there.

Coding something in assembly is not as fun as doing it in C. Thanks for trying, but my bootloader is already far gone. I deleted it and started working on the 4th revision.

Maybe I replied to a wrong person, sorry I am really messed up.
Edit: you were talking about 32 bit code that I was referring to.
If the kernel is going to be a 32 bit C image, then the system better already be in 32 bit protected mode

That is correct. In other words, if you are going to run 32 bit C code, the CPU must already be in 32 bit protected mode - this means you need to have a valid GDT even before the C code can run.

When I mentioned using C in a boot loader - I didn't at all say anything about the processor mode since there are lots of different designs (i.e., we use 32 bit or 64 bit C.) In all cases, you'll need some assembly language.

For VBE...Use Virtual 8086 mode rather than real mode. You can then control VBE any way you want. If you decide to support paging and multitasking, virtual 8086 mode is your only reliable option. You can also write native drivers for Bochs, VirtualBox, QEmu, and others.

neon wrote:

Maybe I replied to a wrong person, sorry I am really messed up.
Edit: you were talking about 32 bit code that I was referring to.
If the kernel is going to be a 32 bit C image, then the system better already be in 32 bit protected mode

That is correct. In other words, if you are going to run 32 bit C code, the CPU must already be in 32 bit protected mode - this means you need to have a valid GDT even before the C code can run.

When I mentioned using C in a boot loader - I didn't at all say anything about the processor mode since there are lots of different designs (i.e., we use 32 bit or 64 bit C.) In all cases, you'll need some assembly language.

For VBE...Use Virtual 8086 mode rather than real mode. You can then control VBE any way you want. If you decide to support paging and multitasking, virtual 8086 mode is your only reliable option. You can also write native drivers for Bochs, VirtualBox, QEmu, and others.

Now I get what you wanted to say. And it is really sad to my understandings. I am 100% sure I want to have paging and multitasking. But people are saying that Virtual 8086 mode does not work on the real hardware.
I want to support hardware that is somewhere in between 2008 and 2017. (does virtual 8086 mode work on those models?)

When 64 bit long mode was introduced, you were not able to use virtual 8086 mode from within long mode. (If you ever wondered why you can't run 16 bit apps under 64 bit Windows, this is why.) However, virtual 8086 mode is still supported in 32 bit protected mode. In the most recent CPU's, Intel has added back the ability to use virtual 8086 mode from long mode, however this was very recent.

In other words - yes, you should be able to use virtual 8086 mode if you stick with 32 bit. If you want to eventually use 64 bit, you will need native drivers.

Real mode requires you to disable hardware interrupts and reinstall the real mode IVT - this means no more timers that your scheduler needs. Also, real mode doesn't use paging - so if the code being executed isn't identity mapped, it will crash. Finally, if you configured the hardware in a way that the firmware does not expect, it can produce unexpected results. These are three (of many) reasons why real mode is not a good option here. Virtual 8086 mode was designed to get around these problems.

Dropping down to real mode is more suitable for boot loaders and other boot applications (this is how C boot loaders work.) But within the kernel, you should be using virtual 8086 mode.

neon wrote:When 64 bit long mode was introduced, you were not able to use virtual 8086 mode from within long mode. (If you ever wondered why you can't run 16 bit apps under 64 bit Windows, this is why.) However, virtual 8086 mode is still supported in 32 bit protected mode. In the most recent CPU's, Intel has added back the ability to use virtual 8086 mode from long mode, however this was very recent.

In other words - yes, you should be able to use virtual 8086 mode if you stick with 32 bit. If you want to eventually use 64 bit, you will need native drivers.

That is great!
I guess I will have to manage those 4 GB of memory as best as I can.
Also how do I make a bootable flash drive with GRUB?
I tried everything and GRUB does not seem to be working on the real hardware.

Hi,


Writing your own bootloader gives you more flexibility over what the kernel has (or doesn't have) to do, which is especially important in microkernels. Having the microkernel set up many things isn't really the best option, since the microkernel should be, by definition, as small as possible. If you are writing a monolithic kernel, it's more acceptable to have the kernel set up some things.

However, in either case, it is more convenient to have the bootloader initialise the initial environment (the kernel shouldn't have to initialise paging and/or long mode) and abstract the firmware (the kernel shouldn't really care whether the firmware is BIOS or UEFI or something else). Having the kernel do less work means less memory consumption (since the bootloader code will be discarded anyway), plus better maintainability over the kernel source code.

On the other side, writing a bootloader that does its job well can be a very difficult task (as others have already suggested) and, if done improperly, you should rather expect it to be rewritten. Writing a bootloader might also take development time you would rather spend on the kernel and/or userspace.

What I suggest for now is to try to think of what information does the kernel need to obtain from the bootloader. This might include writing the kernel first and see in which ways GRUB is inconvenient to use or not. Then, you write your bootloader to match whatever you have designed/learnt before, and you refactor the kernel to fit the newly written bootloader.

Hope this helps.


Regards,
glauxosdever

glauxosdever wrote:Hi,


Writing your own bootloader gives you more flexibility over what the kernel has (or doesn't have) to do, which is especially important in microkernels. Having the microkernel set up many things isn't really the best option, since the microkernel should be, by definition, as small as possible. If you are writing a monolithic kernel, it's more acceptable to have the kernel set up some things.

However, in either case, it is more convenient to have the bootloader initialise the initial environment (the kernel shouldn't have to initialise paging and/or long mode) and abstract the firmware (the kernel shouldn't really care whether the firmware is BIOS or UEFI or something else). Having the kernel do less work means less memory consumption (since the bootloader code will be discarded anyway), plus better maintainability over the kernel source code.

On the other side, writing a bootloader that does its job well can be a very difficult task (as others have already suggested) and, if done improperly, you should rather expect it to be rewritten. Writing a bootloader might also take development time you would rather spend on the kernel and/or userspace.

What I suggest for now is to try to think of what information does the kernel need to obtain from the bootloader. This might include writing the kernel first and see in which ways GRUB is inconvenient to use or not. Then, you write your bootloader to match whatever you have designed/learnt before, and you refactor the kernel to fit the newly written bootloader.

Hope this helps.

Regards,
glauxosdever

I am developing a hybrid microkernel where all my main drivers operate in ring 0 and others in ring 3 (written by user) , it also has a multitasking support (not right now).
I am aware that writing one is a difficult task. I don't think I will be doing another in lets say 10 years from now. It surely takes time, but that is the cost.
Looks like I can't escape GRUB. Thanks for your time.

Edit: Oops, missed that there was a second page meanwhile...

octacone wrote:5.GRUB has one really screwed up system, where if you want to set a video mode using GRUB you need to do it right away, can't do it when kernel is already loaded

That concept is called "bootloader". A bootloader is code that starts the kernel and is never run again afterwards (and probably overwritten in memory very soon). If you plan to implement something else, then it's not a bootloader any more, but part of the OS.

Now if you want to make it a part of the OS so that you can later switch between video modes, you need to have code to switch between Real and Protected Mode, in both directions. And as soon as you have this, the environment that GRUB sets up for you is as good or bad as the environment your own bootloader could provide for this task. And once we're there, I'd go the final step and remove the RM/PM switches but instead use some kind of RM emulation, e.g. a simple VM86 monitor, which is a lot easier than switching between processor modes while running an actual OS.

Video mode switching is not a good reason for rolling your own bootloader - especially if you want to switch video modes at runtime.