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.
firmware drivers switchover
- Combuster
- 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
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.So they first use the firmware drivers (be it BIOS or UEFI), discard them
Which doesn't mean it can't switch back.ntldr switches to protected mode early in the process
Re: firmware drivers switchover
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.
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.
Re: firmware drivers switchover
Obviously, they switch back to real mode to call the BIOS.the confusion is as to how it switches to protected mode while using real mode drivers at the same time?
Re: firmware drivers switchover
Hi,
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:
Cheers,
Brendan
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.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.
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.