OSDev.org

Hi all,

Well I know that during POST all hard drives attached to disk controllers embedded in the chipset of a PC are probed and detected.

Now I wanna know, is this true for Hard disks attached to disk controllers on pci expansion cards installed on mobo.

AFAIK, this should not be the case, as the info about such hard drives is not showed in bios setup. But for drives attached to controllers embedded in chipset, the bios shows all the drives detected.

I went through bios enhanced disk drive specs, but I couldn't find any clue.

Can anyone clarify the issue?

I have used a PCI IDE controller once before. It worked just like all the SCSI drivers out there: it contains a ROM with the necessary drivers, and attaches itself to the int 13h interrupt to allow booting from it. Calling int 13h thus calls through the various plug-in and SCSI controllers, and if none of them understands the drive number, the BIOS will be the last to provide the answer (or simply a "no").

That means BIOS supports all interfaces, and we can retrieve info about any hard drive no matter it is scsi or ide or sata, and no matter it is attached to controller embedded on chipset, or to controller on pci expansion card. Am I right?


If this is the case, then acc. to EDD spec Int13h(Fn = 48h) can be used to retrieve info about any hard drive attached to the system.

The EDD spec mentions 3 imp data structures which are returned about a particular drive, when Int13h(Fn = 48h) is invoked. These are :

Interface type: ATA, ATAPI, SCSI, USB, etc.
Interface path: PCI, legacy(ISA/EISA etc.) , ie the interface of controller to which HDD is attached.
Device path: Master/Slave on ATA, LUN on SCSI, TBD(???) on usb, etc.
Device Parameter Table Extension (DPTE): This contains alongwith other info, the I/O base address through which we can directly access an HDD.

EDD spec also says:
The Device Path combined with the Interface Path allows software external to a system BIOS to locate a specific mass storage device.

The Device Path field provides a path from an interface to a specific device. The format of the Device Path is dependent on the Interface type.

EDD spec again says:
The DPTE provides hardware configuration information to applications that bypass Int 13h for accessing an ATA device.

Does it mean that DPTE is only for ATA/SATA drives? Is it not for USB and SCSI drives?

If BIOS emulates USB hard drives and pen drives, as ATA drives, then DPTE should provide info for communicating with USB hard drives and pen drives.

I'm actually asking this becoz, I am trying to read/write usb hard drives and flash drives for a DOS application. I need to read/write usb hard drives and usb pen drives, bypassing Int13h completely, except of course using Fn=48h to get the info about them which is necessary to communicate with usb drives.

Actually it is a disk I/O sensitive application in protected mode. So using Int13h would involve heavy penalty in terms of performance, due to mode switching. Besides I need to use Programmed I/O for reading writing usb hard drives. So, I am trying to avoid using Int13h.

Can anyone enlighten me?

jacks wrote: I need to read/write usb hard drives and usb pen drives, bypassing Int13h completely, except of course using Fn=48h to get the info about them which is necessary to communicate with usb drives.

You have to write a USB Stack Driver and then the USB Mass Storage Driver.
The EDD information will provide about 0.01% of the information required, good luck with the other 99.99%.

tom9876543 wrote:

jacks wrote: I need to read/write usb hard drives and usb pen drives, bypassing Int13h completely, except of course using Fn=48h to get the info about them which is necessary to communicate with usb drives.

You have to write a USB Stack Driver and then the USB Mass Storage Driver.
The EDD information will provide about 0.01% of the information required, good luck with the other 99.99%.

First, what is that 0.01% of info that EDD can provide me.

Second, when we can access a usb keyboard by writing/reading at I/O port 60h just like a PS/2 keyboard, when bios provides emulation for usb keyboard(and in fact, all PCs I have used, provide this emulation), it doesn't seem a impossible thought for a usb mass storage device to be emulated as an conventional ata device, which can be accessed via some virtual data port mapped at an I/O address. The bios, with assistance from chipset may redirect the data to appropriate usb drive. Of course it is on bios implementers as to what they want to emulate and what they don't want, unless they are bounded by an standard/spec, which till now, I don't know about.

There should be some way. Do we have something like 32-bit protected mode bios service for accessing disk drives, just like we have Int 13h for 16-bit?

Is really there no way other than using Int 13h in protected mode, or writing a usb stack and usb mass storage driver for DOS .

Generally, you could use vm8086 or v86emu to run BIOS code in protected mode (or only emulator in long mode), but both of them are considered *hacks* and not real solutions. The real solution for accessing USB devices is to write USB stack - did anyone say that OS development is easy?

Second, when we can access a usb keyboard by writing/reading at I/O port 60h just like a PS/2 keyboard, when bios provides emulation for usb keyboard

And that's where you go wrong.

From your perspective, the PC BIOS only responds to a bunch of interrupts and puts a bunch of tables into RAM. When you access a port, that BIOS is not involved. Instead the chipset gets the request, and it might decide to put the system into management mode while it tries to cover up for the stupid user not using proper drivers. The only difference is that the time to perform the access becomes much longer.

In other words, USB emulation is implemented for an essential part in silicon.

On the other hand, if you ask the PC bios for a keystroke, then it is free to handle that with its own USB code without needing the chipset to cover up. That means that for any nonstandard device, there are two possible usages that need to be covered by the designers. You may find yourself getting int 13h support for an USB stick, but if you try to access it as an IDE controller you will typically not get a fake USB controller but rather the actual IDE controller that's installed, or even nothing for a 100% SATA machine. Worse, a plug-in card lacks the wiring and it's therefore not possible to emulate it.

And nobody cares: harddisks have an age-long reputation of having multiple interfaces, and for more than a decade it's been standard issue that assuming IDE is a bad idea with all the SCSI cards out there that couldn't possibly be made to appear like an IDE controller.

Worse: The silicon that emulates an PS/2 keyboard over USB has an off state: it will have to so the OS can access all the other devices on the USB controller. And it typically does that the moment it thinks you're acting like a modern OS. I've seen enough weird triggers being mentioned in my history here that makes USB emulation rather unstable the moment you try anything beyond the basics.

As for all the plug-in cards, some might or might not support bios calls for the devices they control. You can't typically use EDD functions on a floppy, and when hardware's mixed that might work for one physical harddisk and not for the other. El-Torito is good enough at making fuzz to make an optic disk magnetic, with all the consequences thereof.



tl;dr:
USB emulation is a hack. Ask the BIOS politely or write a native driver. All other bets are off.

Thanks, for the useful info. It enabled me viewing things from wider perspective. But I have some doubts in my understanding.

Combuster wrote:

Second, when we can access a usb keyboard by writing/reading at I/O port 60h just like a PS/2 keyboard, when bios provides emulation for usb keyboard

And that's where you go wrong.

From your perspective, the PC BIOS only responds to a bunch of interrupts and puts a bunch of tables into RAM. When you access a port, that BIOS is not involved. Instead the chipset gets the request, and it might decide to put the system into management mode while it tries to cover up for the stupid user not using proper drivers. The only difference is that the time to perform the access becomes much longer.

In other words, USB emulation is implemented for an essential part in silicon.

I do agree with you, but I didn't get how the usb keyboard emulation works w/o bios support?. I understand that bios is not involved during port read/write. What I'm saying is that bios should have configured/enabled the emulation circuitry of the chipset at boot up.

I mean, when we read i/o port 60h, how does chipset know whether we wanna use PS/2 keyboard or USB keyboard?
To me, it seems that when POST detects usb keyboard, at bootup, it programs the chipset so that its PS/2 emulation is enabled. IOWs, when a usb keyboard is attached to PC, it is prefered over PS/2 one. But how both keyboards simultaneously work then.
Precisely, say I typed 'A' from usb keyboard, then 'B' from PS/2 one. When I read port 60h, in both cases, I got the correct scan code!
It seems , that chipset maps the keyboard dynamically rather than statically, depending on the source of keystroke - usb keyboard or PS/2 keyboard.

Combuster wrote: On the other hand, if you ask the PC bios for a keystroke, then it is free to handle that with its own USB code without needing the chipset to cover up. That means that for any nonstandard device, there are two possible usages that need to be covered by the designers. You may find yourself getting int 13h support for an USB stick, but if you try to access it as an IDE controller you will typically not get a fake USB controller but rather the actual IDE controller that's installed, or even nothing for a 100% SATA machine. Worse, a plug-in card lacks the wiring and it's therefore not possible to emulate it.

If I got it correctly, you are saying that if a bios is able to boot from usb hard drive or pen drive, then we can definitely access it via Int 13h routines, because, the pci usb controller, in its rom contain suppport for int 13h. Am I missing something here?

Combuster wrote: Worse: The silicon that emulates an PS/2 keyboard over USB has an off state: it will have to so the OS can access all the other devices on the USB controller. And it typically does that the moment it thinks you're acting like a modern OS.

Sorry I didn't get that. Can you elaborate?

thanks!

jacks wrote:I do agree with you, but I didn't get how the usb keyboard emulation works w/o bios support?. I understand that bios is not involved during port read/write. What I'm saying is that bios should have configured/enabled the emulation circuitry of the chipset at boot up.

I mean, when we read i/o port 60h, how does chipset know whether we wanna use PS/2 keyboard or USB keyboard?
To me, it seems that when POST detects usb keyboard, at bootup, it programs the chipset so that its PS/2 emulation is enabled. IOWs, when a usb keyboard is attached to PC, it is prefered over PS/2 one. But how both keyboards simultaneously work then.
Precisely, say I typed 'A' from usb keyboard, then 'B' from PS/2 one. When I read port 60h, in both cases, I got the correct scan code!
It seems , that chipset maps the keyboard dynamically rather than statically, depending on the source of keystroke - usb keyboard or PS/2 keyboard.

The BIOS developers set the chipset to do a SMM trap when accesses to the keyboard controller are done, that invokes code which emulates (very badly) the keyboard controller for keys received from the USB keyboard. Generally, there is another SMM trap set that disables this emulation as soon as you so much as breathe in the direction of the USB controller. This emulation is very bare bones, gets various things wrong, and, essentially, is only designed so that you can run old OSes (mainly DOS)

On the other hand, no such hardware-level emulation is provided for USB disk drives, because every OS was already used to needing drivers for non-ATA disk drives, and the EDD services are there so you can boot from the disk without a catch 22 situation.

Owen wrote: The BIOS developers set the chipset to do a SMM trap when accesses to the keyboard controller are done, that invokes code which emulates (very badly) the keyboard controller for keys received from the USB keyboard. Generally, there is another SMM trap set that disables this emulation as soon as you so much as breathe in the direction of the USB controller. This emulation is very bare bones, gets various things wrong, and, essentially, is only designed so that you can run old OSes (mainly DOS)

On the other hand, no such hardware-level emulation is provided for USB disk drives, because every OS was already used to needing drivers for non-ATA disk drives, and the EDD services are there so you can boot from the disk without a catch 22 situation.

Thank you for making things a bit more clear.

Is bios Int13h support for usb drives, a stable approach, for communicating with usb mass storage devices. I hope that this emulation is not bare bones, becoz pci usb controller rom routines should have hooked in int13h services to enable emulation.

Am I right?

jacks wrote:Thank you for making things a bit more clear.

Is bios Int13h support for usb drives, a stable approach, for communicating with usb mass storage devices. I hope that this emulation is not bare bones, becoz pci usb controller rom routines should have hooked in int13h services to enable emulation.

Am I right?

It's provided by the BIOS vendor, not the PCI USB card vendor (i.e. any support for the PCI USB card is because the BIOS vendor has implemented support for enumerating PCI USB cards and implementing USB disk emulation for them)

It's probably about as stable as the rest of the BIOS - i.e, it should work as long as you keep in mind the caveat that BIOS developers are the worst software developers imaginable* and remember that the BIOS is going away with the shift to EFI (e.g. I expect Windows 8 machines will probably no longer ship the BIOS emulation layer)

* Not quite true, but even if they do patch their code, your users are unlikely to patch their BIOSes, the end result being that you have to work around every BIOS bug ever that could affect your code. In other words, BIOS bugs only go away when you decree machines unsupported

Owen wrote:
... and remember that the BIOS is going away with the shift to EFI (e.g. I expect Windows 8 machines will probably no longer ship the BIOS emulation layer)

Thanks for clarifying again. Does it mean that EFI on x86 PC* will also not support standard interrupt routines, that were standarized in ISA/EISA era. or do you mean that all those standarized interrupt services will exist on x86 EFI too, but we can't rely int 13h usb emulation, as it is not a standarized service that every bios manufacturer need to be stick to.

Even if standard interrupt services might not be supported by EFI, does EFI will support specs like PnP, ESCD, ACPI, PCI BIOS, etc, that were supported by all BIOSes ?

*Well by def, a PC with EFI is not technically a PC in strict terminology, but I'm just using the term to represent the legacy PC architecture, but with BIOS replaced by EFI.

EFI is a replacement for the BIOS. It doesn't act like the IBM PC and has no reason to do so either.

It will still provide it's own way of loading from disk, be it SATA, USB, firewire or anything emulated on top, but you can throw your old PC-BIOS bootloader code away when dealing with EFI.
As far as hardware-level emulation is concerned, it'll mean a shift in mentality from "rust works, somewhat" to "do it the official way or gtfo" as well. Macs are a particular dictatorship on that subject.

Combuster wrote:EFI is a replacement for the BIOS. It doesn't act like the IBM PC and has no reason to do so either.

It will still provide it's own way of loading from disk, be it SATA, USB, firewire or anything emulated on top, but you can throw your old PC-BIOS bootloader code away when dealing with EFI.

Even if standard interrupt services might not be supported by EFI, does EFI will support specs like PnP, ESCD, ACPI, PCI BIOS, etc, that were supported by all BIOSes ? or are there any equivalent specs for EFI for x86 architecture?

These specs are necessary for obtaining configuration info that is specific to a system, even an OSes need them.

or is it something like, EFI will be only for IA64 architecture or others and not for x86 and x86_64 based architectures, which are an extension of IBM PC?