This message is from the T13 list server.
// Hale L: > ... Unexpected host read/write accesses ... > The most dangerous of all these > is the host that writes the Command register > while BSY=1 or BSY=0 DRQ=1 Internally when we enumerate resets we distinguish power-on, pin 1 RESET-, bit 2 SRST, x90 ExecuteDeviceDiagnostic, x08 DeviceReset ... and this, which we term "unexpected command reset" aka UCRST. > the host that writes the Command register > while BSY=1 or BSY=0 DRQ=1 I hear Windows CE CompactFlash drivers do this normally? Slanderous? True? Maybe something about moving x1FE rather than x200 bytes of xEC Identify data, and the proceeding with the next command? Consequently, to plug 'n play as an Ata device, all you can do is quietly forget the last command, hope you don't need any parameters from the task file that the host couldn't successfully write while you were BSY, and proceed. > the host that writes the Command register > while BSY=1 or BSY=0 DRQ=1 > (except that stupid DEVICE RESETthing). When first I found hosts that wrote my Atapi device during BSY:DRQ != 0:0 via x1F7 Command with other than x08 DeviceReset, my firmware hung, having stumbled across an unexpected condition that kicked my asic into a mode I didn't know existed. This made some Bios boot unacceptably slowly. My next try was to reset myself. That was what the first couple of generations that I shipped did. I never actually saw this break - but the fact that any reset ends with ERR = 0 bothers me, and making a self-generated reset work this way bothered me more. So with my UDma generation of Atapi firmware I reset myself but then ended with ERR = 1. I think we have to be careful to be sure that whatever we say gives us the answer we want when the value written to x1F7 Command was the x90 ExecuteDeviceDiagnostic that both devices ordinarily do respond to. > the host that writes the Command register > while BSY=1 or BSY=0 DRQ=1 > status of BSY=0 DRQ=0 ERR=1 ABRT=1 and IDNF=1 Should the device raise ... or lower ... INTRQ? > status of BSY=0 DRQ=0 ERR=1 ABRT=1 and IDNF=1 No doubt it would be Evil to make yet another documented difference, or worse, undocumented difference between Ata and Atapi, ... But ... The x10 IDNF and x04 ABRT bits of the x1F1 Error register have a radically different meaning in Atapi? If the command interrupted by a UCRST was the xA0 Packet command - say because a power-managing Bios spoke in the middle of an Atapi operation - then what might work a lot better would be to set x1F1 Error = x50 i.e. SK 5 i.e. protocol trouble. > ... What I think I remember I finally shipped was a completely standard x08 DeviceReset signature i.e. x01 in the x1F1 Error register, the xEB:14 Atapi signature in x1F5:1F4, ... except that I did also set ERR. > ... In Atapi it's also helpful to smash the x1F2 SectorCount register, so that is says x01 CommandOut which I'd say means unexpectedly bus free whenever BSY:DRQ = 0:0. The value to avoid leaving in the x1F2 SectorCount is x03 StatusIn ... ... unless you do mean to more completely simulate that either command did end with an error, in which case we have to raise INTRQ. Pat LaVarre >>> [EMAIL PROTECTED] 12/06/01 05:22PM >>> This message is from the T13 list server. I sent this to Pat but not to the reflector a few hours ago... ==================BEGIN FORWARDED MESSAGE================== >To: "Pat LaVarre" <[EMAIL PROTECTED]> >Date: Thu, 06 Dec 2001 12:45:57 -0700 >From: "Hale Landis" <[EMAIL PROTECTED]> >Subject: Re: [t13] Re: unexpected data clocks On Thu, 06 Dec 2001 10:54:58 -0700, Pat LaVarre wrote: >For Pio I guess I think of this as a special case of >how to respond to Pio r/w of the x1F0 Data register >at times when DRQ is clear. An read or write of the Data register while BSY=1 or while BSY=0 DRQ=0 is ignored. See the I/O response tables. It has been this way since before ATA-1. Of course a host that performs reads or writes under these device status condition is a confused host. Unexpected host read/write accesses that could indicate a confused host is an area T13 just does want to address (so far) but I think the day is approaching fast when something will need to be done. The most dangerous of all these is the host that writes the Command register while BSY=1 or BSY=0 DRQ=1 (except that stupid DEVICE RESET thing). I want the standards to say that if a device detects this (an the detection logic can be optional, but if implemented) the device shall immediately have status of BSY=0 DRQ=0 ERR=1 ABRT=1 and IDNF=1 with no assertion of INTRQ. The device shall continue to have this status until a H/W or S/W reset (or DEVICE RESET) is received. Maybe the same thing should apply to an unexpected read/write of the Data register during a PIO data transfer command? ===================END FORWARDED MESSAGE=================== *** Hale Landis *** [EMAIL PROTECTED] *** *** Niwot, CO USA *** www.ata-atapi.com *** Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
