This message is from the T13 list server.
Hale, Thanks for the response. The key hint was the SRST behavior during the power up/hardware reset sequence. This solves 99% of the issue. As you stated, the other bits are much less critical and are (hopefully) initialized by software before they influence any behavior. Thanks, Alex. > Date: Fri, 07 Oct 2005 08:20:08 -0600 > From: "Hale Landis" <[EMAIL PROTECTED]> > To: [email protected] > Subject: Re: [t13] default value of Device Control Register > > This message is from the T13 list server. > > > Alexander Krebs wrote: > > This message is from the T13 list server. > > I have a question on the default value of the Device Control Register. > > Is it spec'ed anywhere? I could not find it in ATA/ATAPI-6, SATA 1.0a > > nor SATA 2.5. > > This is one of the (many) things that the SATA folks messed up and one > of the (many) reasons SATA is not ATA and should not be called ATA. > > First, by "default value of the Device Control register", I assume you > mean the power on or Hardware reset value... > > You are correct, ATA/ATAPI-6 does not say much about the value in the > Device Control register following power on or Hardware Reset. However, > ATA/ATAPI-6 does say that SRST will be set to zero by power on or > Hardware Reset processing. As for the other bits, it really doesn't > matter what value they have but my guess is most devices set all the > bits to zero. But looking at each of the bits: > > - HOB is set to zero by any write to the Command Block registers. > Nothing is said about a reset setting HOB to 0, however, devices must be > setting HOB to 0 because if they didn't it is possible that a host would > not see the 'device signature' data that is present in the Command Block > registers following a reset (and Exec Dev Diag). If someone is doing an > ATA/ATAPI-6 Errata it might be good to make sure all resets and Exec Dev > Diag set HOB to 0. > > - All the reserved bits should be 0 all the time, but who cares what > value they have because the host can't read them. > > - SRST is set to 0 as described above. > > - There is no specification for what happens with nIEN. But who cares? > For PATA this has never been a problem. The value of nIEN has not effect > on the processing of the reset - resets don't generate interrupts - and > that includes DEVICE RESET (that looks like a command). I have never > seen a PATA host that would not write to the Device Ctrl register before > issuing a command - this write is done just to make sure the nIEN bit is > correct. > > > The question came up in SATA context. A host may skip sending a Reg > > FIS in case the Device Control Register was written but the SRST bit > > was not changed. > > SATA has basically eliminated the nIEN bit - it has become useless. > There are apparently some comment about this from the secret society but > I'm not sure any of that was incorporated into ATA/ATAPI-7 (I don't look > at ATA/ATAPI-7 because it is such a mess just for things like the nIEN > problem). It is my understanding that when operating with a SATA device > a host must keep nIEN zero at all times - not doing this can lead to > unpredicatable results. If you are a host that can't determine if you > are working with a SATA device then the only safe thing to do is keep > nIEN zero all the time - of course this insures that SATA is not > backward compatible - but then SATA never was backward compatible - it > really isn't ATA! > > > Let's assume the host's default value of the Device Control Register > > is 0xfe. Let's also assume software never wrote this register before. > > Now, software wants to reset the device by setting SRST=1. Since the > > SRST bit did not change, the host may skip sending the Reg FIS. The > > device never sees SRST==1. BAD. > > I don't know of any host that would set the Device Control register to a > strange value like 0xfe - I don't know of any host that would have a > 'default value' for this register that was not 0x00. > > > To make this working correctly, at least Device Control Register bit > > 2 must have a reset value of 0. IMHO, the whole register should have > > a reset value of 0x00. Am I right here? > > Maybe... But SRST is really the only bit that needs to be zero at the > end of a reset. nIEN could be a problem but only if someone didn't > follow the 'recommendations' of the secret society (that probable means > ignoring ATA/ATAPI-7 - something everyone working on SATA should be > doing anyway!). > > > Or software must write SRST=0 before writing SRST=1 which is even more > > difficult to realize with plenty of legacy software around. > > SATA is basically not compatible with 'legacy' (that is PATA) software. > > > A related issue is whether host software can assume that nIEN is in a > > defined state after power up/reset. If yes, what value can it assume? > > See above. > > Hale > > -- > > ++ Hale Landis ++ www.ata-atapi.com ++ > >
