OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 10:50 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 23 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: Bootloader design
PostPosted: Sun Jun 21, 2020 3:10 am 
Offline
Member
Member

Joined: Sun Apr 05, 2020 1:01 pm
Posts: 182
nexos wrote:
How I plan on doing it is kind of complex, but here we go. The MBR code loads up stage 2. Stage 2 is two files concatenated with the cat command. The first one enters Protected Mode, and enables A20. It also relocates the second one, which is directly after. It then jumps to it. It is a C executable. When calling the BIOS, it will drop to real mode and call it, and then bounce back to PMode. Disk buffers will be put in a low memory temporary buffer, and then copied to the permanent buffer, which can be anywhere. Hopefully that makes sense and is of help.


Yeah that sounds good, what do you use to compile the C file? Thanks.


Top
 Profile  
 
 Post subject: Re: Bootloader design
PostPosted: Sun Jun 21, 2020 5:21 am 
Offline
Member
Member

Joined: Tue Feb 18, 2020 3:29 pm
Posts: 1071
My OS is more Windows like, so MinGW for Linux, and it loads a PE. You could use a GCC cross compiler and load an ELF, or you could output a flat binary or MZ with Smaller C.

_________________
"How did you do this?"
"It's very simple — you read the protocol and write the code." - Bill Joy
Projects: NexNix | libnex | nnpkg


Top
 Profile  
 
 Post subject: Re: Bootloader design
PostPosted: Sun Jun 21, 2020 8:15 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
One thing I will suggest is that you need to think beyond just the bootloader itself, and consider how you are going to install the loader onto a given system (even if it is just a disk image for a VM). Especially if you intend to make your system installable onto different media, or onto systems which use UEFI. A good OS installer is in some ways as much a code generator and editor as it is an image writer.

_________________
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.


Top
 Profile  
 
 Post subject: Re: Bootloader design
PostPosted: Sun Jun 21, 2020 8:47 am 
Offline
Member
Member

Joined: Fri Nov 22, 2019 5:46 am
Posts: 590
Schol-R-LEA wrote:
One thing I will suggest is that you need to think beyond just the bootloader itself, and consider how you are going to install the loader onto a given system (even if it is just a disk image for a VM). Especially if you intend to make your system installable onto different media, or onto systems which use UEFI. A good OS installer is in some ways as much a code generator and editor as it is an image writer.

I don't understand this.
Can't you just copy stage2 and the kernel to /boot/efi/ (or /boot/ or whatever your Linux distro uses to mount the ESP)? And doesn't Windows allow the user to copy files to the ESP?

And why is the installer a generator? An editor?

Greetings
Peter


Top
 Profile  
 
 Post subject: Re: Bootloader design
PostPosted: Sun Jun 21, 2020 9:36 am 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 1584
PeterX wrote:
I don't understand this.
Me neither, but I might have a clue what he could meant.
PeterX wrote:
Can't you just copy stage2 and the kernel to /boot/efi/ (or /boot/ or whatever your Linux distro uses to mount the ESP)? And doesn't Windows allow the user to copy files to the ESP?
Yes, if your loader is smart enough. But there are other things, like being multiplatform or userland for example to beconsidered. How will you create a partition for those data in the first place? How would you access those? For a kernel that's fine to copy to ESP, but you can't put everything on the ESP (well, you can, but you probably shouldn't). If your OS uses ext2, then how would you use it under Win? These are not unsolvable problems, but definitely things to be sorted out.
PeterX wrote:
And why is the installer a generator? An editor?
I believe what he meant is, you'll never need all the things all the time. For example there's no point in putting the AArch64 version of "ls" into an x86-only bootable image.

Cheers,
bzt


Top
 Profile  
 
 Post subject: Re: Bootloader design
PostPosted: Sun Jun 21, 2020 9:46 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
I had something a bit more immediate in mind: a first-stage boot loader designed for a BIOS system loading from a floppy will be different from one loading from a fixed drive, which in turn would differ from one booting from an El Torito CD (despite the latter's emulation functions). A BIOS system boots in a different way from a UEFI system, which realistically doesn't really need a first-stage loader at all in most cases, but does have its own way of interfacing with the kernel which the kernel needs to know about and handle sensibly. That sort of thing.

There's also the matter of tuning the boot process for the existing hardware, though that can be an open-ended sink for time and effort.

I'll admit that this is something of a gripe I have with a lot of loader designs, in that they stick to something very generic and as a result under-perform for most hardware. But then, I also favor source-based package management (in principle) for much the same reason, despite the fact that none of the existing ones are really usable (which is why I switched from Gentoo to Manjaro for my preferred Linux distro), so perhaps I am the crazy one here (I mean, I am crazy anyway, but... you know what I mean).

_________________
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.


Top
 Profile  
 
 Post subject: Re: Bootloader design
PostPosted: Sun Jun 21, 2020 10:09 am 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 1584
Schol-R-LEA wrote:
I had something a bit more immediate in mind: a first-stage boot loader designed for a BIOS system loading from a floppy will be different from one loading from a fixed drive, which in turn would differ from one booting from an El Torito CD
Ok, maybe for floppies, but if you move them out of the equation to solely rely on LBA, all the rest can use the same boot record (see my bootloader's boot.asm).

Schol-R-LEA wrote:
A BIOS system boots in a different way from a UEFI system, which realistically doesn't really need a first-stage loader at all in most cases, but does have its own way of interfacing with the kernel which the kernel needs to know about and handle sensibly. That sort of thing.
First part is true, but the second isn't. You can write a bunch of bootloaders in a way that they interface with the kernel exactly the same way, therefore the kernel doesn't need to know about the firmware at all. Actually that's the whole point of BOOTBOOT Protocol. Write your kernel once, and don't care on which platform it's booted on and how. (Being binary compatible on platforms with the same CPU, and source compatible for platforms with different CPUs.)

Schol-R-LEA wrote:
I also favor source-based package management (in principle) for much the same reason, despite the fact that none of the existing ones are really usable (which is why I switched from Gentoo to Manjaro for my preferred Linux distro), so perhaps I am the crazy one here (I mean, I am crazy anyway, but... you know what I mean).
Nope, I totally agree with you. And I also had to gave up on Gentoo, a change in emerge created a circular dependency hell with fast Furier transformation library. And I said: a) why on earth does a package manager need fast Furier transform in the first place? b) if I have to reinstall my entire system because of this stupid issue, do I really want to go with Gentoo again? Which is sad, because when there was no issues with emerge I really really liked that distro. It was comfortable (for me) and everything run lightning fast, perfectly tuned to my computer. Booted in less than a sec from turn on to X11 logon :-) Do that with Bugbuntu!

Cheers,
bzt


Top
 Profile  
 
 Post subject: Re: Bootloader design
PostPosted: Sun Jun 21, 2020 10:50 am 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
Schol-R-LEA wrote:
I had something a bit more immediate in mind: a first-stage boot loader designed for a BIOS system loading from a floppy will be different from one loading from a fixed drive, which in turn would differ from one booting from an El Torito CD (despite the latter's emulation functions).

Floppy and hard drive bootloaders will be different, but El Torito emulation allows you to use both unmodified (provided they use BIOS calls to access the disk). I wouldn't say it's a good idea, but it will work.

Schol-R-LEA wrote:
There's also the matter of tuning the boot process for the existing hardware, though that can be an open-ended sink for time and effort.

I'll admit that this is something of a gripe I have with a lot of loader designs, in that they stick to something very generic and as a result under-perform for most hardware.

What exactly do you have in mind here?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 23 posts ]  Go to page Previous  1, 2

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 24 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group