How does BIOS exactly read the first sector

Question

I need to know if the ATA command Read Sector still in use. I read in SATA Storage Technology book that this command and in general PIO read-in commands are used only in the booting process. So I started to look into the booting process and I have some confusion about it.

I know that the BIOS read the first sector or MBR as a part of the booting process. I read also that BIOS uses the INT 13 to do that.

SATA device communicates via HBA. So this reading of the first sector must be after the initialization process between SATA and HBA has finished.

How does the BIOS reads the first sector...

Does the HBA translate the INT 13 to ATA commands? If yes,
Doesn't this need the AHCI driver presence?
When does the driver getting loaded?

OR

Does the BIOS communicate directly with the Hard Drive? I think this is not possible.

Answer 1

For devices; there's floppy, SCSI, ATA, ATAPI, USB mass storage, SATA, NVME, etc. Most of them have a controller (where CPU can only talk to the controller and the controller talks to the device/s attached to the controller). Sometimes the interface the controller provides is relatively standardized (e.g. AHCI) and sometimes it is not (SCSI, hardware RAID controllers); and sometimes the controller provides multiple interfaces (e.g. a SATA controller might support AHCI, plus legacy (P)ATA emulation, plus a non-standard RAID interface; and have options to select which in BIOS settings).

For all cases; either the BIOS has (minimal) driver code built into it (likely for "relatively standardized" controllers/devices and controllers built into the motherboard); or the controller has a "device ROM" built into it (e.g. on the same PCI card) that hooks/intercepts "int 0x13".

In any case; "int 0x13" would use the "device number" parameter to figure out what the device is and branch to device driver code for that device.

Does the HBA translate the INT 13 to ATA commands?

If a SATA controller is using AHCI as its interface; then the driver would convert "int 0x13" requests into SATA/AHCI commands for HBA. If a SATA controller is using legacy (P)ATA emulation then the driver would convert "int 0x13" requests into legacy (P)ATA commands, then the HBA would translate ATA commands into the SATA command set.

Doesn't this need the AHCI driver presence?

Yes. Note that it's a minimal driver (not supporting things like "hot-plug SATA", native command queuing, secure erase, eject, trim, ...) that uses a "start command, waste CPU time while preventing parallelism and ruining performance until command completes, then return status" approach for simplicity. These things mean that it's nothing like a device driver than an OS would want to use.

When does the driver getting loaded?

The driver code is always present in a ROM somewhere (not loaded from disk at some point in time). The driver code is initialized either before firmware goes looking for "device ROMs" or when firmware is initializing "device ROMs".

After everything is initialized; (assuming BIOS is booting from normal disk - e.g. not booting from network) BIOS can just use 'int 0x13" to load the first sector from "whatever device it ended up being after device ROMs were initialized".

Answer 2

After some testing with SATA analyzer, it turns out that the BIOS or UEFI is smart enough to not use slow ATA commands such as READ SECTOR(S) in the boot process. instead it uses the ATA command READ DMA EXT.

for completeness, the sequence is:

after the drive send its signature, the HBA send the ATA command IDENTIFY DEVICE, and then send READ DMA EXT with LBA = 0.

I am not sure though if the OS use READ SECTOR(S) or WRITE SECTOR(S) in any case during normal work. I hope not as implementing PIO IN/OUT protocol in FPGA is not a pleasant work.