CODEWITHSUNDEEP
assemblyx86cpubios
Yetimwork Beyene
Yetimwork Beyene

Reputation: 249

Entering the CMOS or BIOS at the console after boot and before the OS comes up, its able identify the devices

Can someone confirm my thinking based on the question above? After the CPU process the reset vector address instruction located at this system BIOS address. It then process the system BIOS code that includes scanning all the io buses and dynamically assigning system resources (interrupts, io addresses) to these io devices. And then it builds an interrupt vector table for these allocated system resources in system memory?

Upvotes: 0

Views: 153

Answers (2)

old_timer
old_timer

Reputation: 71516

Pretty much yes. You are talking about x86 specifically though. The x86 PC model is for the BIOS to scan and detect the ISA/PCI(e) based peripherals. The BIOSes on each peripheral (and/or the main BIOS) will be setup to respond to the BIOS interrupts. That is not in any way all that the BIOS does and it isn't necessarily the first thing that the BIOS does but it is in the list of tasks that the BIOS does.

Upvotes: 1

Brendan
Brendan

Reputation: 37214

It then process the system BIOS code that includes scanning all the io buses and dynamically assigning system resources (interrupts, io addresses) to these io devices.

Sort of. Note that some hardware starts in "crippled legacy limp mode" (e.g. the first video card, USB keyboard, old SATA controllers with "parallel ATA emulation", etc), so when an OS actually wants to use these device properly it has to reconfigure them. This includes interrupt controllers - nothing will be configured by BIOS to use modern MSI ("Message Signaled Interrupts") and nothing will be configured by BIOS to use the older IO APIC chips - things will be configured (where possible) to use the ancient PIC chips (which are fairly limited/useless for multi-CPU systems). In the same way you can assume (e.g.) the IOMMU will be left in a "least secure, everything passes through" state.

There's also the possibility of buses the BIOS doesn't support. For example, if you have a device connected to an infiniband controller it's unlikely the BIOS will have any code to handle it.

Then there's hot-plug PCI and things like thunderbolt, where it's impossible for BIOS to configure it and assign resources if it isn't plugged in until during/after BIOS is booting; which mostly forces a (full fledged) OS to support its own configuration and resource assignment.

Of course if the OS doing its own configuration and resource assignment anyway; then it makes sense for the OS to do all of its own configuration and resource assignment (to be immune from BIOS bugs and quirks, to avoid the annoying "legacy modes", to support other kinds of firmware more easily, to make it easier to support things like "kexec()", and to make it easier to handle virtual machines that crash leaving any PCI devices that were used with "pass through" in unknown states, and to improve security using a "disable as many devices as possible, configure IOMMU to as restrictive as possible, then setup a dynamic root of trust with SKINIT or similar" approach).

In other words; yes, the BIOS does try to do configuration and resource assignment, but in practice this isn't really very useful for much more than the fraction of a second it takes to starting something better.

And then it builds an interrupt vector table for these allocated system resources in system memory?

Don't forget that IRQs are only one type of resource - there's memory mapped IO registers and IO ports (and DMA channels if you want to look at old ISA cards); and only IRQs make sense in the interrupt vector table. Also, the BIOS itself typically uses polling (and not IRQs), so even when the BIOS does support a device it can leave devices' IRQs disabled and not have anything for them in the interrupt vector table.

Upvotes: 3

Related Questions