I am trying to make a custom bootloader, and i tried to study the source code of gujin and GRUB; But i can't understand how it reads disk. What I am trying to understand is that :
Both the bootloaders (GRUB and Gujin) have disk reading functions coded in C. But as far as i know, the stage where the bootloaders actually read the disk, is coded in Assembly because the CPU in in Real mode (and because of various other reasons.) .
It would be great if somebody elaborately explains the EXACT process GRUB uses to make its path to the kernel.
EXACT process of Booting of a kernel
-
- Member
- Posts: 37
- Joined: Sat Apr 11, 2015 9:37 am
- Schol-R-LEA
- Member
- Posts: 1925
- Joined: Fri Oct 27, 2006 9:42 am
- Location: Athens, GA, USA
Re: EXACT process of Booting of a kernel
First off, I wouldn't recommend trying to learn from a release-grade bootloader when starting off, for much the same reason we generally discourage reading the Linux kernel when first learning - even if it is well-documented (and I have no idea how GRUB or Gujin are in that regard), they spend a lot of the code handling edge cases that will only distract from understanding the bigger picture. While it may seem pointless, studying and writing a toy boot loader first makes more sense. I've attached a copy of one I wrote years ago, maybe it will be worth your while to look at it.
Second, if you haven't done so already, take a look at the overview of the boot process in the wiki. It will explain what the code is doing well enough that you can put together what the code is doing, at least. Again, reading the GRUB code is likely to be counter-productive at this stage, but even in a smaller bootloader you need to know what it is supposed to be doing to understand how it does it.
As for the question itself, I'll need to get back to you on that, but I can see two possibilities off the top of my head. First, it is possible that they are using a 16-bit real mode C compiler specifically for that part of the code. More likely, though, is that the assembly part of the loader switched to 32-bit protected mode even before any of the C code is running. I'll take a look at it later and see which of those is happening, or if it is something else entirely.
Second, if you haven't done so already, take a look at the overview of the boot process in the wiki. It will explain what the code is doing well enough that you can put together what the code is doing, at least. Again, reading the GRUB code is likely to be counter-productive at this stage, but even in a smaller bootloader you need to know what it is supposed to be doing to understand how it does it.
As for the question itself, I'll need to get back to you on that, but I can see two possibilities off the top of my head. First, it is possible that they are using a 16-bit real mode C compiler specifically for that part of the code. More likely, though, is that the assembly part of the loader switched to 32-bit protected mode even before any of the C code is running. I'll take a look at it later and see which of those is happening, or if it is something else entirely.
- Attachments
-
- stagetwo.asm
- (2.66 KiB) Downloaded 35 times
-
- verbum.asm
- (7.54 KiB) Downloaded 42 times
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.
- BASICFreak
- Member
- Posts: 284
- Joined: Fri Jan 16, 2009 8:34 pm
- Location: Louisiana, USA
Re: EXACT process of Booting of a kernel
For everything bootloader you should check out both BIOS ints and (U)EFI functions.
The BIOS ints can be found here.
Int 0x13 has disk functions
Int 0x10 has video functions
Int 0x15 has memory functions (and other things that are probably not used anymore - most functions here are to do with system management)
And I'm assuming the UEFI wiki page has UEFI information (I have yet to support, so I'm unsure the actual differences)
But looking at GRUB's code will get you nowhere (other than confused) fast. - It is not terrible code, it is just a little much and over complicated (to support a very [extremely] wide range of systems).
It would be easier to write one without trying to follow what they (GRUB) does.
The BIOS ints can be found here.
Int 0x13 has disk functions
Int 0x10 has video functions
Int 0x15 has memory functions (and other things that are probably not used anymore - most functions here are to do with system management)
And I'm assuming the UEFI wiki page has UEFI information (I have yet to support, so I'm unsure the actual differences)
But looking at GRUB's code will get you nowhere (other than confused) fast. - It is not terrible code, it is just a little much and over complicated (to support a very [extremely] wide range of systems).
It would be easier to write one without trying to follow what they (GRUB) does.
BOS Source Thanks to GitHub
BOS Expanded Commentary
Both under active development!
BOS Expanded Commentary
Both under active development!
Sortie wrote:
- Don't play the role of an operating systems developer, be one.
- Be truly afraid of undefined [behavior].
- Your operating system should be itself, not fight what it is.
-
- Member
- Posts: 37
- Joined: Sat Apr 11, 2015 9:37 am
Re: EXACT process of Booting of a kernel
I am not just starting up with OSDeving, I have already made a kernel with a GDT, keyboard driver, and other features - capable of booting with grub. I just want to remove my dependency over GRUB.