USB MSD : how to turn BIOS "emulation" off ?

[Czernobyl]

Hi !
Hopefully this is the best place for asking a question about
common USB mass storage device emulation, by BIOSes,
as fake floppy or hard disk drives - generally, for the
sake of booting up an OS from said USB MSDs.

Is there a publicly known (RM or PM) call to the effect
of asking the BIOS to release the USB-storage device, i.e.
flush buffers and stop emulation ? I assume there has to be a way,
in order for an OS to install its own USB drivers and connect the
boot device to them. But I haven't been able to find anything
in whatever public specs on the web. The extended int 13 spec,
version 3, by Phoenix and others, mostly discusses compact disc (CD)
emulation for booting; hardly touches the case of USB devices...
I did try "int 13h AX=4B00" : does nothing to stop USB emulation.

Anybody ?

° I'd rather find an agreed-upon BIOS call rather than some ACPI-nonsensical one...

[johnsa]

I believe the emulation can and should be disabled by accessing the USB controllers PCI configuration space.
So assuming you've enumerated the PCI bus.. found the root USB host controllers and hubs and started the process of initializing them via MMIO emulation will stop happening.

see:

http://wiki.osdev.org/PCI

and

http://wiki.osdev.org/PCI_Express

From that point you'd have to refer to the USB controller specs to find the details of it's MMIO registers and PCI config space options.

[Nable]

Wiki showed me the following way: http://wiki.osdev.org/EHCI -> http://wiki.osdev.org/USB -> http://forum.osdev.org/viewtopic.php?p=167311#p167311

[...]in fact the particular PC may take advantage of EHCI's extended capabilities, which includes a semaphore mechanism for transferring ownership of the EHCI controller form the BIOS to the OS.

Supposing the worst--that the BIOS configures devices and neglects to reset them in case the OS doesn't support EHCI--you may want your OS to do the following:
[...]

[Czernobyl]

Thanks, very interesting information by "Madeofstaples" there.

I only want to stop the BIOS-established emulation though, in real mode at that, which I hope should be doable without diving into oh so complicated physical ?HCI control !

What I'm still searching is, much simpler, is there not an agreed-upon BIOS call or method for resetting USB MSD "emulation" in an orderly way, *prior to* OS trying to enumerate the hardware and recapture control over it ? Suspecting there is an agreed-upon by MS and BIOS makers method. Pity the Ralf Brown "list" has not been updated for so long (how is Ralf doing ?). Anybody looked through Linux kernel & driver initialisation sources ?

[Combuster]

The BIOS uses USB hardware to provide the features that would otherwise be missing, like keyboard and disk access. Of course there isn't going to be a BIOS call by design that is essentially equivalent to "self-destruct real mode".

[Czernobyl]

The BIOS uses USB hardware to provide the features that would otherwise be missing, like keyboard and disk access. Of course there isn't going to be a BIOS call by design that is essentially equivalent to "self-destruct real mode".

Disk emulation is separate from USB-HID emulation.
And, there has to be an orderly and non proprietary way to stop USB disk emulation, intended for hand-off from BIOS to OS, and this is what I want to use (or abuse).
Be assured I know to /not/ self destruct :=)

[embryo]

And, there has to be an orderly and non proprietary way to stop USB disk emulation, intended for hand-off from BIOS to OS, and this is what I want to use (or abuse).

Disk emulation is employed when you do a corresponding BIOS call, but when you do something else the emulation is of no importance. And if you have some USB driver that you are going to use, then why do you need BIOS's emulation? Just let your driver to (re)initialize the USB stuff. So, all the "hand-off" looks like "forget about BIOS" if you do not want to use it's calls any more. Or even if you want to use some unrelated to USB calls, then still you can forget about BIOS when using your USB driver. The only thing to preserve is some memory ranges with BIOS's data.

[Czernobyl]

Disk emulation is employed when you do a corresponding BIOS call, but when you do something else the emulation is of no importance. And if you have some USB driver that you are going to use, then why do you need BIOS's emulation?

No urgent need. I'm just the curious type, you know...

Just let your driver to (re)initialize the USB stuff. So, all the "hand-off" looks like "forget about BIOS"

You'd be surprised that even mainstream OSes get confused and hang if BIOS emulation of USM-MSD was turned on when they start. I tried one Windows, and one Linux : both hung. No need or desire to test more OSes,some of which have a bad habit of wrongly "remembering" whatever hardware they /think/ they once saw; and.or might demand tedious "reactivation" for no real reason ;=)

Of course a BIOS knows to disable emulation when asked to doing a standard reboot. Whether there is a known, somewhat universal, call to that effect is the question I am posing. Tracing the BIOS especially but not limited to SMM code is really too much of a burden !

To achieve testing, I did something pretty simple : booted DOS from a USB key, then chained to the Linux or Windows bootloaders without "notifying" the BIOS (conveniently achieved using Grub4DOS, although of course it could be done by other means).

The net conclusion is : OSes aren't prepared to finding "BIOS emulation" active when they're booted. that they hang while initialising their own USB drivers shows sufficiently IMHO that your proposal to "just let your driver (re)initialize the USB" isn't going to work ;=)

[Octocontrabass]

To achieve testing, I did something pretty simple : booted DOS from a USB key, then chained to the Linux or Windows bootloaders without "notifying" the BIOS (conveniently achieved using Grub4DOS, although of course it could be done by other means).

The net conclusion is : OSes aren't prepared to finding "BIOS emulation" active when they're booted. that they hang while initialising their own USB drivers shows sufficiently IMHO that your proposal to "just let your driver (re)initialize the USB" isn't going to work ;=)

Let me run this by you once to see if I've got this right.

You boot DOS from a USB flash drive, using USB emulation. Then you boot Windows or Linux using Grub4DOS, and they hang.

You boot Windows or Linux from a USB flash drive, using USB emulation, and they work. (Windows might complain a bit, though.)

You then conclude that USB emulation, which is active in both scenarios, is the reason why Windows and Linux hang when you load them through Grub4DOS.

Am I the only one who sees a problem here?

[Czernobyl]

You boot DOS from a USB flash drive, using USB emulation. Then you boot Windows or Linux using Grub4DOS, and they hang.

Yes.

You boot Windows or Linux from a USB flash drive, using USB emulation, and they work. (Windows might complain a bit, though.)

Nope, I didn't even try, such experimentation is outside of my point. MS-Windows can't be booted from removable media anyway, as far as I am aware.

You then conclude that USB emulation, which is active in both scenarios, is the reason why Windows and Linux hang when you load them through Grub4DOS.

Nope, you are the one making wrong deductions :=)

Booting the alternate OSes indirectly by GRUB4DOS - chainloading from DOS - works perfectly in the absence of "USB emulation", i.e. in case a USB MSD was not attached or detected during BIOS startup. I conclude it is the existence of the USB stack and mass storage driver, installed by the BIOS, which conflicts with the protected mode OSes.

[Combuster]

Considering google has thorough instructions on booting both windows and Linux from an USB stick, the presence of USB HD emulation can't be the problem in the general case.

If you boot from an USB drive and chainload to a different harddisk, you likely broke the device numbering and many other bootloaders hate that, not the USB part.

[Czernobyl]

Considering google has thorough instructions on booting both windows and Linux from an USB stick, the presence of USB HD emulation can't be the problem in the general case.

I am aware it is possible, even though in principle windows objects (or rather, Microsoft does). There is a difference to the point here, because in my experiment, the USB device hooked by the BIOS is not the same disk that the secondary OS (Win or Linux) 'sees' as the booting device.

If you boot from an USB drive and chainload to a different harddisk, you likely broke the device numbering and many other bootloaders hate that, not the USB part.

No, absolutely not, it didn't break that, i.e. device numbering.

Anyway, this is not my motivation. I am looking for an interface that would mandate how emulation can be stopped, releasing the BIOS's grasp over one or more USB MSDs. While I would'nt swear, I strongly suspect there is an agreed-upon protocol between the usual suspects ;=)
It is interesting and can be useful per se, without any reference to chainloading OSes. e.g., after booting DOS from a USB stick, and assuming you have command.com available to be reloaded from another disk,you might want to release/remove the stick and/or install native DOS drivers for USB.

[Brendan]

Hi,

Hopefully this is the best place for asking a question about
common USB mass storage device emulation, by BIOSes,
as fake floppy or hard disk drives - generally, for the
sake of booting up an OS from said USB MSDs.

That is not "emulation" in any sense of the word. The BIOS functions are just an API to access whatever the hardware happens to be; and "int 0x13" might be using PIO or DMA, and might be using AHCI, or ATA, or SCSI, or USB or anything else.

Is there a publicly known (RM or PM) call to the effect
of asking the BIOS to release the USB-storage device, i.e.
flush buffers and stop emulation ?

There either is no buffers, or the buffer are flushed before "int 0x13" returns (so that it complies with the API's semantics). There's no BIOS function to "release" the USB storage device, or the hard disk controller or floppy controller or video card or anything else. The OS takes control by force (without asking).

I assume there has to be a way,
in order for an OS to install its own USB drivers and connect the
boot device to them. But I haven't been able to find anything
in whatever public specs on the web. The extended int 13 spec,
version 3, by Phoenix and others, mostly discusses compact disc (CD)
emulation for booting; hardly touches the case of USB devices...
I did try "int 13h AX=4B00" : does nothing to stop USB emulation.

For "El Torito" bootable CDs there actually is emulation - e.g. a disk image on the CD (and not the whole CD) is used to emulate a completely different device (a floppy disk or hard disk) with very different characteristics (e.g. 512 byte sectors and not 2 KiB sectors, cylinders and not a long spiral, multiple heads and not single sided, etc).

If a bootable CD uses the "no emulation" option, then nothing is emulated (your code reads 2048-byte sectors from the full device and not from a disk image on the device). In this case "int 13h AX=4B00" does nothing.


Cheers,

Brendan

[Czernobyl]

Brendan, with all due respect, ... it IS an emulation. There is no reason not to call it as such, and indeed it is analogous in many respects to BIOS El torito CD/DVD booting : BIOS has a USB stack, most of the lower level routines being in SMM protected RAM (for no special technical reason except there might not be enough room in regular "visible" BIOS ROM space). The int 13 "high level" API calls down to the appropriate hardware routines according to the medium type, like you say. I don't see why on earth it couldn't be called an "emulation" when flash RAM thru USB is "disguised" by the BIOS as a floppy (or hard disk) with some unusual parameters nut... that's me, and it's only a matter of wording.

Whether you call it emulation or otherwise, a BIOS can be set up to enumerate, initialise and handle accesses to-from one (sometimes several) USB storage device(s) and boot up from one of them, this I like to call emulation.

There's no BIOS function to "release" the USB storage device

Yet the BIOS will release it as part a reboot sequence (be it "warm"). there evidently IS a routine that does the orderly release, including the flushing of buffers (and YES the BIOS must maintain at least one sector buffer, just stop to think a minute ! I've LOCATED such buffer in BIOS-managed RAM on this machine I'm now at ...

So, what you said can only have one sensible meaning, id est, there is no public, BIOS independent, interface for USER to ask BIOS to release the USB emulation.

Sadly this is a possibility : are you CERTAIN or just guessing ?
Unfortunately for the last 10 or 15 years more and more interfaces have gone opaque, as in : reserved to industry comity members.

[Nable]

You are mixing things. SMM code is for emulation of i8042: this code emulates presence of 8042 with PS/2 keyboard and mouse when you have only USB ones (and no physical 8042 IC even as a part of LPC chip).

But access to USB storage devices via 0x13 is just an API, it doesn't bring any emulated I/O ports.