OSDev.org

I have an OS (actually a stand-alone application) that boots from FAT drives in several steps (MBR => boot sector => first sector of .SYS file => next few sectors of .SYS file => prot mode => entire rest of .SYS file). It works fine on real hard drives but the last step seems to go off the deep end during the final step, when booting from a USB flash drive which is emulating a HDD (with the BIOS's help).

I'm not a total moron -- well OK maybe I am, in fact I'm fairly sure of it, but not about the obvious fact that BIOS calls from pure prot mode cause death. I switch to V86 mode and emulate CLI/STI/HLT/INT/PUSHF/POPF/IRET in my GPF handler as usual, so normally I have no problem keeping the BIOS alive indefinitely (ints I don't handle are reflected to V86 mode, just like a DOS prot mode application). In particular, the same EDD BIOS call (AH=42h / INT 13h) that's blowing me out of the water with the USB drive, works fine on real PATA/SATA hard drives.

It's not a total shock that the BIOS's little USB boot driver might be fragile. I guess the UHCI has I/O-mapped registers but they're memory-mapped on the others, so the BIOS will need access to 32-bit addressing for those. If it's that simple, then of course it will explode when it tries to kick the CPU into prot mode to touch the regs, since I've already done that. But shouldn't all of this be happening via SMM BIOS magic behind my back? The xHCI specs give kind of a lot of thought to that, at least for PS/2 keyboard/mouse emulation. I haven't touched any xHCI registers, and I haven't turned off HDD emulation in the EDD BIOS, so as far as I know the BIOS is supposed to proceed as if we're still in real mode (which as I say, it is indeed doing with real HDDs, and floppies too) and do its thing with SMM w/o regard to what mode I think I've put the CPU in.

Right? Please feed clues into my empty brain! My OS is too big to load the whole thing into low memory before switching to PM, so I've been using bounce-buffering in PM. I guess I could drop back to genuine RM (not V86) for each read but ... I don't think I should have to. I'd rather understand what's happening that fiddle with it until it seems to work, because it already *used* to seem to work (could definitely boot from the same USB flash drive on a much older motherboard, using C/H/S BIOS calls).

Thanks!

Ignoring that it's a silly idea to depend on the BIOS once in pmode, it should keep working if you're calling from VM8086 and not touching the memory it was relying on.

USB storage emulation is not necessarily done via SMM, as it doesn't need to work once the OS has booted (SMM is usually only for emulating hardware, not for providing BIOS services).

JohnWilson wrote:My OS is too big to load the whole thing into low memory before switching to PM,

May I suggest ditching the v86 hard disk driver and using unreal mode to move data around instead?

Of course, this is just my opinion on the matter - maybe someone else will know how to get your v86 driver to work.

Hmm. Unreal mode isn't a bad idea, compared to flip-flopping between RM and PM anyway. Thanks!

I'm honoring the E820 map so if the BIOS HDD emulation has private memory, I shouldn't be stomping on it, and I certainly leave the low BIOS area and RM vectors alone, except for the ones I'm *supposed* to dink with (like INT 4Bh).

So I'm baffled. Using the BIOS from PM when necessary may be distasteful, but I can't find anything *illegal* about it (and of course the DOS build of my application has little choice so I have tons of support code built in).

So I'm hoping there's some undocumented assumption about USB booting (or maybe it's documented and I just haven't found it) that I need to satisfy -- like intercepting some weird INT 15h call or something (but the only INTs it's issuing while hung seem to be 1Ch timer ticks).