firmware drivers switchover

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
Post Reply
garegin
Posts: 8
Joined: Tue Jan 01, 2013 11:57 am

firmware drivers switchover

Post by garegin »

as far as I understand historically OSes were designed to use the drivers that were embedded in the bios and the extendable BIOS (adapter ROMs). But modern OSes all use native drivers. The point is that they still need the firmware drivers to even see the drivers on the drive to begin with! So they first use the firmware drivers (be it BIOS or UEFI), discard them, and then use native drivers.
my question is whether I have a correct picture. because the way the booting is described, ntldr switches to protected mode early in the process. Well, how it that possible? Doesn't any OS need to load the native driver before it can discard the firmware driver?
OSX and windows 8 use cached kernels so you wouldn't crash late in the boot process, but in other OSes you have observe the BSODs the second the process looks for the native driver and fails.
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Re: firmware drivers switchover

Post by Combuster »

So they first use the firmware drivers (be it BIOS or UEFI), discard them
Not quite. A lot of the firmware is still actively used when the OS runs. Just the part that helps the OS start itself up is one of the things that typically doesn't get used afterwards.
ntldr switches to protected mode early in the process
Which doesn't mean it can't switch back.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
garegin
Posts: 8
Joined: Tue Jan 01, 2013 11:57 am

Re: firmware drivers switchover

Post by garegin »

so my educated guess about driver loading is correct? the OS uses the firmware drivers up until it loads the native drivers? the confusion is as to how it switches to protected mode while using real mode drivers at the same time?
do know specifically known when say, linux or xp switch to using the protected mode storage drovers during boot?
the linux case is confusing since you have your initramfs and all the convoluted hand-offs.
Gigasoft
Member
Member
Posts: 856
Joined: Sat Nov 21, 2009 5:11 pm

Re: firmware drivers switchover

Post by Gigasoft »

the confusion is as to how it switches to protected mode while using real mode drivers at the same time?
Obviously, they switch back to real mode to call the BIOS.
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: firmware drivers switchover

Post by Brendan »

Hi,
garegin wrote:so my educated guess about driver loading is correct? the OS uses the firmware drivers up until it loads the native drivers? the confusion is as to how it switches to protected mode while using real mode drivers at the same time?
do know specifically known when say, linux or xp switch to using the protected mode storage drovers during boot?
the linux case is confusing since you have your initramfs and all the convoluted hand-offs.
Everything depends on something. For example, the firmware's code depends on the CPU's mode and the state of lots of pieces of hardware (timer, PIC/IO APIC, disk controllers, PCI bridges, etc). You can prevent the firmware's code from running (e.g. disable IRQs and don't call any of the firmware's functions) and do anything you like (including changing the CPU's mode and the state of lots of pieces of hardware) then restore everything the firmware depends on (including restoring the CPU's mode and the state of lots of pieces of hardware) and then continue using the firmware. Of course this is more like "pausing" the firmware - the firmware isn't discarded.

For example; a typical 32-bit boot loader (e.g. GRUB) might only change the CPU's mode and doesn't mess with the state of lots of pieces of hardware; and can run in 32-bit protected mode (with firmware "paused") and switch to real mode whenever the BIOS is actually needed.

All OSs boot differently; but in general you can mostly break it up into 4 phases:
  • Boot code uses firmware to load whatever the OS will need (possibly "pausing" the firmware and switching CPU modes if/when necessary) and gathers any other information about the system the OS might want (e.g. memory map); then
  • Boot code discards the firmware (OS can't use any hardware now); then
  • OS starts initialising its own drivers (that were previously loaded) until the OS is in control of all the hardware, and also starts things like file system code, networking, etc; then
  • OS is ready to run applications

Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Post Reply