Post a Comment
Saturday, August 6, 2011
"Frying" Another USB-to-IDE Converter
Last wednesday was the second time I fried another USB-to-IDE converter device due to buggy ATA command that was sent to the IDE device (a DVD-ROM Drive). I'm not really sure which command that causes it to happen. But, now is the time to look into ATA command set much deeper.
Well, this is just a precaution for guys/girls out there working with *-to-IDE converter device. Be very careful with ATA command that you send to the IDE device.
Apparently, the problem was the "offending" ATA command corrupt the firmware inside the converter. I haven't look very detailed into what type of chip used in the converter. Probably MIPS-based or ARM-based microcontroller. Too bad I don't have JTAG debugger to see what exactly happens.
Post a Comment
Post a Comment
Subscribe to:
Post Comments (Atom)
6 comments:
How are you sending arbitrary commands to a USB to IDE converter? (ie, what program are you using for this particular exploration)
I didn't do it from inside an OS because this was a BIOS development (official BIOS code). So, I was testing a patch when the BIOS routine "fried" the USB-to-IDE device. But, it could be done from inside an OS as well via kernel mode device driver. I don't see a reason why it cannot be done. It's just I will leave the latter for later. BIOS development comes first on this matter ;)
What routine? In my experience, there are only a few commands one can send to USB/IDE bridges... and seldom are those straight ATA commands. I'm curious how/what let you send arbitrary ones. I'd be happy to log in and email you privately, if you don't want to share publicly. ;-)
It's not arbitrary ATA command. The ATA command are related to ATA device speed initialization. In that process, I was trying to interrogate the IDE device (through the USB/IDA converter) as to what speed it supports. The original BIOS code is buggy. The routines I worked with programmed the IDE controller in the southbridge during such initialization, I need to send ATA command through the IDE controller to the IDE device. It's a quite intertwined process between the IDE controller on the board, the USB/IDE device and the IDE device itself. I'm not really sure how I'm going through about fixing the problem. Up to now, I think the BIOS handled the IDE device as "IDE emulation on top of USB".
I forgot to mention that the port used to communicate is the standard ATA ports (IIRC) 1F0h-1FFh. I'm still debugging the state of the IDE controller registers via the serial port. Some details are at: http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/033959.html and http://freebsd.1045724.n5.nabble.com/Fw-Re-PCI-IDE-Controller-Base-Address-Register-setting-td4039938.html . Perhaps not directly answer your question but at least describes the problem better.
I know for "Media" class devices, some commands are encapsulated in scsi pass thru, but still, quite odd you managed to fry it. If you happen to toast another and note the sequence, please share it with us. Thank you for your responses. ;-)
Post a Comment