OSDev.org

Hi, I'm trying to write a bit of code that will detect at runtime whether or not any of these three controllers exist: ATA/IDE, ATAPI, PS/2. And, then to determine if those controllers have connected devices. Would scanning the PCI bus be the best/easiest way to accomplish all this? Is there a better way?

By scanning the PCI bus, you'll only know if an ATA/ATAPI controller connected to the PCI bus exists or not. It won't help on detecting for example the PS/2 controller.

Hi, thanks for the quick reply.

Is scanning the PCI bus for ATA/ATAPI controllers/devices a sure fire way to do so?

In terms of the PS/2 controller, looking at its specifications, I find that for the keyboard I might try to send the echo command (i.e. 0xEE) and if I receive a 0xEE in return then I can assume a keyboard is present. And for the mouse, if I send 0xF6 or 0xF4 (as I do to configure the mouse anyway) if I receive a 0xFA from either of those commands, then I could assume a mouse was present.

Is this what others typically do or is there a better way that I still have not found in the specifications?

montrom wrote: Is scanning the PCI bus for ATA/ATAPI controllers/devices a sure fire way to do so?

Sadly, nothing is sure-fire when it comes to hardware detection -- in this case, it depends on if your OS is going to insist that all ATA/ATAPI drivers be PCI. There are non-PCI ones ... mostly obsolete stuff. But yes, if you find all the PCI hard disk controllers, and their PCI configuration spaces are designed properly, and you get their IO port ranges, and you know how to properly access their IO ports -- then you can send commands to their IO ports to see if any drives respond.

montrom wrote: In terms of the PS/2 controller, looking at its specifications, I find that for the keyboard I might try to send the echo command (i.e. 0xEE) and if I receive a 0xEE in return then I can assume a keyboard is present. And for the mouse, if I send 0xF6 or 0xF4 (as I do to configure the mouse anyway) if I receive a 0xFA from either of those commands, then I could assume a mouse was present.

It's easier to think of it the other way around. If you send a command to either device, and you do not get a response -- then you assume that the device is temporarily disconnected. The thing is, in reality a mouse or keyboard can get disconnected (or die) at any time while a machine is on. And you will almost certainly need to detect that situation. So you will need to ping that hardware at intervals anyway. If the ping fails, then you try to do a hardware reset. If the reset fails, the hardware is missing. After a mouse has been reset and initted, I happen to ping it by requesting a mouse packet -- in order to keep my mouse packets aligned.

PS/2 keyboards & mice aren't technically hot-pluggable, and just because you might be able to recover from it on some newer systems.. it doesn't mean it's going to work everywhere.

Best consider the condition fatal and require a machine restart, as simply reinitializing the hardware/driver from the software side may not work properly.. and leave things in an inconsistent state.

I thought that if there wasn't a keyboard or mouse attached, that I would halt the kernel. Not having a mouse in my gui would cripple the user and not having a keyboard in my cui would cripple a user. I would assume the user had a keyboard and mouse, but that it wasn't a PS/2 one, instead it would be USB, which I do not currently support. I must expect the device to be present, anything else would require a halt and reboot. I don't think I will be treating these devices like the USB, but I do find an interest in this ping suggestion. I am not currently doing that, I use a different method for ensuring packet alignment, but this idea sounds more typical than what I am doing, so it was a cool idea.

Anyway, I think I have all the information I need now, so thanks. I really appreciate the insight.

@Brynet: All machines made after 1985 do have hot pluggable ps2 ports.
People trip over cords. Both mice and keyboards become unplugged either intentionally or accidentally. It was certainly always intended that ps2 ports support hot plugging. Yes, there were a few ancient, obsolete machines made that did not. They are gone now. It is smartest to support and detect it. A complete OS fail because a user tripped over his mouse cable is not user friendly.

@montrom: What about headless systems? IO devices and even storage are usable over a network (eg, SSH or X); even if there isn't a mouse or keyboard plugged into the computer your OS is running on, it's still possible to use them. Just something to think about, because supporting that sort of stuff is what I (at least) would do later on in development, rather than early on.

Sounds friendly enough to me, that'll teach them clumsy users.. do not touch, just sit back and watch the BLINKENLIGHTS!

bewing wrote:@Brynet: All machines made after 1985 do have hot pluggable ps2 ports.

I disagree, unless you mean 1995, as PS/2 is from 1987 (with the introduction of the IBM PS/2 line of computers), and didn't gain much popularity until much later when ATX became the norm (Wikipedia lists 1993 for that). I bought my Pentium 1 motherboard somwhere in the mid nineties ('96 or thereabouts), pre-ATX form factor, and it had a PS/2 connector on the motherboard, for which I had to buy a separate PS/2 bracket. The PS/2 of this machine was definitely not hot-plugable: if it didn't boot with a PS/2 device attached, the PS/2 would be disabled. If the PS/2 was unplugged during operation, there was a chance the whole machine would hang. If it didn't hang, plugging the device back in may or may not reactivate it. Biggest chance was that it didn't.


JAL

Exactly what jal said, PS/2 hotplugging doesn't always work.. and probably should be assumed that it doesn't.

jal wrote: if it didn't boot with a PS/2 device attached, the PS/2 would be disabled. If the PS/2 was unplugged during operation, there was a chance the whole machine would hang. If it didn't hang, plugging the device back in may or may not reactivate it. Biggest chance was that it didn't.

These were almost certainly "features" of the OS -- not the hardware. If you still have that mboard, try testing it yourself. I bet you will find the thing is perfectly hot pluggable.

bewing wrote:These were almost certainly "features" of the OS -- not the hardware. If you still have that mboard, try testing it yourself. I bet you will find the thing is perfectly hot pluggable.

I do have that motherboard still, fully operational, and no, it is not hot pluggable. Not in Windows 2000, not in Linux, not in DOS. And, most importantly, not in my own OS: if there's no PS/2 device present, you cannot detect the PS/2, and neither when removing a PS/2 device previously connected. Sorry Bewing, you're just not correct on this one. And for the record, the mobo is a ChainTech, not too high end but no rubbish either.


JAL

The PS/2 interface itself is not hot pluggable for a simple reason: Nothing prevents the data connections contacting before power.

Why is this bad? Because what can happen is this:

• Ground connection is established through shield
• Data or clock pin connects before power pin
• Because the data pin is at a higher voltage than the power rail (5v vs 0v), the data pin's clamp diode (To prevent damage due to "overshoot") turns on and provides ~4.4V of power to the power rail
• The chip turns on and powers up the optical mouse' LED
• ~50mA is being drawn through a clamp diode rated for ~10mA max. Chip substrate heats substantially. Data pin drivers undergo thermal failure and are destroyed

This is the reason why hot pluggable connectors (USB, SATA power & data, SecureDigital, etc) have a connection order of ground, power, then data by making those pins longer and preventing angled insertion.