Page 1 of 4
[Closed Don't Reply] Old Question
Posted: Wed Dec 28, 2016 5:29 am
by Octacone
I am making my own bootloader and I have couple of rather deep question -> I want some deep answers.
This is how I am doing it:
1. Stage: loaded at 0x7C00, reads one sector from the disk loads that data at 0x7E00
2. Stage: loaded at 0x7E00, enables A20
What do I need to do next in order to load my C kernel?
To compile my C kernel and then just link it together with the second stage? Also I want to load my kernel above 1MiB barrier. Also why do people put their kernels at 0xC0000000 isn't that equal to 3GiB of RAM total? What if my machine has lets say 512MB of RAM and I use 0xC0000000? I think 0xC0000000 refers to virtual memory. Is BIOS map getting scaled so it fits to your memory accordingly?
Now lets talk about what matters:
What to do after enabling A20, to set a new stack pointer? Do I need to reserve (resb) lets say 2*1024*1024 bytes of memory in bss and then just pass it to esp? I don't want to enter user mode directly or load GDT and stuff like that. This is what I want to do:
After A20 is enabled: 1.Set up a new stack (I guess) 2.Call VBE 3.Call my C entry 4.Load GDT, IDT, paging and other things 5.Return back to my bootloader and enable protected mode + reload segments and far jump 6.Return to C code Is this even possible?
I am really open to suggestion and really want to learn this stuff once and forever.
Re: Deep Bootloader Questions
Posted: Wed Dec 28, 2016 5:39 am
by matt11235
I don't think that you should link your kernel with the second stage. Instead the second stage should have a filesystem driver that loads your kernel image.
Re: Deep Bootloader Questions
Posted: Wed Dec 28, 2016 6:13 am
by Octacone
zenzizenzicube wrote:I don't think that you should link your kernel with the second stage. Instead the second stage should have a filesystem driver that loads your kernel image.
I don't really want to do that. I've see many many people doing it with only the interrupt 13. I don't want to do anything floppy related, my OS needs to be able to boot of a hard drive (0x80). I want to use assembly as little as possible.
Re: Deep Bootloader Questions
Posted: Wed Dec 28, 2016 6:29 am
by matt11235
octacone wrote:I want to use assembly as little as possible.
Have a look at UEFI, or use somebody else's bootloader.
Re: Deep Bootloader Questions
Posted: Wed Dec 28, 2016 6:37 am
by Octacone
zenzizenzicube wrote:octacone wrote:I want to use assembly as little as possible.
Have a look at UEFI, or use somebody else's bootloader.
I prefer BIOS over UEFI. That would beat the point of this. (learning)
Let me fix my statement: I want to use assembly as little as possible when it comes to stuff that can be done in C, such as file systems.
Re: Deep Bootloader Questions
Posted: Wed Dec 28, 2016 9:44 am
by Kevin
octacone wrote:What do I need to do next in order to load my C kernel?
Throw away, or at least shelve, your code and use an existing bootloader for now. As long as you can't answer most of the questions you're asking, you're not ready for writing a proper bootloader. Bootloaders are one of the more advanced topics and getting some more OS dev experience first will help you with writing one.
Re: Deep Bootloader Questions
Posted: Wed Dec 28, 2016 9:53 am
by Octacone
Kevin wrote:octacone wrote:What do I need to do next in order to load my C kernel?
Throw away, or at least shelve, your code and use an existing bootloader for now. As long as you can't answer most of the questions you're asking, you're not ready for writing a proper bootloader. Bootloaders are one of the more advanced topics and getting some more OS dev experience first will help you with writing one.
No, I would rather die than use GRUB again! GRUB is so limited and there are so many things I would like to do. How am I supposed to answer them when I can't find the answers online? I know how a bootloader loads it but I need a deeper explanation. This sounds like a noob question, but it is not. Can you guys please just answer my questions so I can code my bootloader the way it is supposed to work. Without a custom bootloader my project is dead, can't start a fourth revision without it. Please please just answer my questions.
Re: Deep Bootloader Questions
Posted: Wed Dec 28, 2016 10:28 am
by matt11235
octacone wrote:GRUB is so limited and there are so many things I would like to do.
What features do you think that GRUB is lacking?
Re: Deep Bootloader Questions
Posted: Wed Dec 28, 2016 10:32 am
by neon
If you want to boot from hard disks, use the extended read BIOS services (int 13h function 42h). It is typically recommended to keep the boot loader ("stage 2") separate - although you can link it with the kernel, most of the code within the boot loader would be specialized for it and wouldn't work well to satisfy the requirements a kernel needs. Also, returning to real mode is only really suitable in boot loaders and other boot applications that require it - once the kernel enables paging it becomes very hard to do this properly. Besides, why would you want to return back to the boot loader just to enable protected mode and setup segments? This should be done for you already: the boot loader should load the kernel image, enable protected (or long) mode, and set up the environment that the kernel needs to run (i.e. load any other module the kernel needs, enable paging if it needs it, create the initial address space, etc.)
In other words, you really only have two choices here: Use the extended read BIOS services or use an existing boot loader that does this for you.
Also, you can write most of the boot loader in C if you design it carefully. It is recommended to have already made a boot loader in assembly language first though in order to get a better idea of the environment the code runs in and learn about the areas that you need to be careful about. Using UEFI here would be a lot easier if this is your first boot loader.
Re: Deep Bootloader Questions
Posted: Wed Dec 28, 2016 10:41 am
by Octacone
neon wrote:If you want to boot from hard disks, use the extended read BIOS services (int 13h function 42h). It is typically recommended to keep the boot loader ("stage 2") separate - although you can link it with the kernel, most of the code within the boot loader would be specialized for it and wouldn't work well to satisfy the requirements a kernel needs. Also, returning to real mode is only really suitable in boot loaders and other boot applications that require it - once the kernel enables paging it becomes very hard to do this properly. Besides, why would you want to return back to the boot loader just to enable protected mode and setup segments? This should be done for you already: the boot loader should load the kernel image, enable protected (or long) mode, and set up the environment that the kernel needs to run (i.e. load any other module the kernel needs, enable paging if it needs it, create the initial address space, etc.)
In other words, you really only have two choices here: Use the extended read BIOS services or use an existing boot loader that does this for you.
I need to do that because I cannot enter protected mode without having a global descriptor table, I need to get back so I can enable protected mode after I load my GDT with C.
Like this:
1.Assembly: call Kernel_Main
call Enter_Protected_Mode
2.C: GDT_Install();
return; //Or whatever, now by default my OS should return to assembly code and enable protected mode.
I can't do this:
1.Assembly: call Enter_Protected_Mode
call Kernel_Main
2.C: GDT_Install();
Thanks for answering at least something.
Re: Deep Bootloader Questions
Posted: Wed Dec 28, 2016 11:02 am
by Kevin
Trying to use C in real mode is probably not worth it. gcc can't do it anyway, you'd need a different compiler for that. Whatever little code must be executed in Real Mode can be written in assembly.
octacone wrote:No, I would rather die than use GRUB again! GRUB is so limited and there are so many things I would like to do.
Your own bootloader is much more limited than GRUB.
But seriously, I was not kidding. For a proper bootloader, and even more so for one that makes GRUB look limited, you need more OS dev experience than you currently have. Once you have that experience, you can answer the questions yourself, because a bootloader is mostly just a small OS.
This sounds like a noob question, but it is not.
Yes, it is.
Re: Deep Bootloader Questions
Posted: Wed Dec 28, 2016 11:03 am
by neon
This is stuff that should be done in a boot loader. The reasoning is that the boot loader needs to set up the execution environment that the kernel (and, in fact, operating system) needs in order to operate. If the kernel is going to be a 32 bit C image, then the system better already be in 32 bit protected mode prior to even calling the kernel. In other words,
you really do not have a choice here.
What you should have is this:
Code: Select all
// Boot loader:
Install_GDT();
Enable_Protected_Mode();
Load_Kernel_Modules();
Execute_Kernel();
I can't do this:
1.Assembly: call Enter_Protected_Mode
call Kernel_Main
2.C: GDT_Install();
Why can't you just do GDT_Install within Enter_Protected_Mode? Besides, its not like you have a choice. The C function GDT_Install would most certainly be 32 bit code that already relies on valid descriptor segments (most notably CS and SS.)
Re: Deep Bootloader Questions
Posted: Wed Dec 28, 2016 11:07 am
by Octacone
zenzizenzicube wrote:octacone wrote:GRUB is so limited and there are so many things I would like to do.
What features do you think that GRUB is lacking?
1.Does not boot into real mode automatically, sets protected mode automatically, which is stupid for my use
2.Cannot use "bits 16" code
3.Does not work on the real hardware (my custom bootloader boots just fine, I can't make GRUB do the same (speaking of my OS not Linux))
4.I need to do lots of crap in order to return to real mode and set VBE
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
6.Many others that I can't remember right away because of how pissed I am, because there is not a single person that can politely explain what I asked
Re: Deep Bootloader Questions
Posted: Wed Dec 28, 2016 11:10 am
by Octacone
neon wrote:This is stuff that should be done in a boot loader. The reasoning is that the boot loader needs to set up the execution environment that the kernel (and, in fact, operating system) needs in order to operate. If the kernel is going to be a 32 bit C image, then the system better already be in 32 bit protected mode prior to even calling the kernel. In other words,
you really do not have a choice here.
What you should have is this:
Code: Select all
// Boot loader:
Install_GDT();
Enable_Protected_Mode();
Load_Kernel_Modules();
Execute_Kernel();
I can't do this:
1.Assembly: call Enter_Protected_Mode
call Kernel_Main
2.C: GDT_Install();
Why can't you just do GDT_Install within Enter_Protected_Mode? Besides, its not like you have a choice. The C function GDT_Install would most certainly be 32 bit code that already relies on valid descriptor segments (most notably CS and SS.)
I
don't want to code GDT in assembly. Holy **** C does not work with 16 bit code...
Also it would not be 16 bit code, (speaking of protected mode enabling and GDT in C)
Re: Deep Bootloader Questions
Posted: Wed Dec 28, 2016 11:11 am
by Octacone
Kevin wrote:Trying to use C in real mode is probably not worth it. gcc can't do it anyway, you'd need a different compiler for that. Whatever little code must be executed in Real Mode can be written in assembly.
octacone wrote:No, I would rather die than use GRUB again! GRUB is so limited and there are so many things I would like to do.
Your own bootloader is much more limited than GRUB.
But seriously, I was not kidding. For a proper bootloader, and even more so for one that makes GRUB look limited, you need more OS dev experience than you currently have. Once you have that experience, you can answer the questions yourself, because a bootloader is mostly just a small OS.
This sounds like a noob question, but it is not.
Yes, it is.
I don't want to beat GRUB, I just want a simple as **** bootloader that can load my kernel and set up some stuff.
Okay if you think so, okay.