Re: I/O bus reset to fix CMD MSCP controllers (and probably others)

On 2025-03-31 22:08, Mouse wrote:
>> I think we're talking about the same manual.
>> http://www.bitsavers.org/pdf/dec/disc/uda50/AA-L621A-TK_UnibusPortDescription_1982.pdf
> 
> Well, I got it from bitsavers.trailing-edge.org, but I just now fetched
> the URL you give and the resulting PDF is identical, so, yes.

Good. :-)

>>>    * AA-L621A-TK is silent on some important questions.  In particular:
> 
>>>    * What does reading IP before the end of the four-step init sequence
>>>    *  return?  Are there any side effects of such a read?
> 
>> Reading the IP never returns anything relevant/interesting/useful.
> 
> As plausible as I find that, I don't see it stated anywhere.  IP is
> described (page 3-3) as having semantics on write and having semantics
> "[w]hen read while the port is operating".  Its semantics when read
> while the port is _not_ operating are not described.  It also does not
> describe the return value when read, not even to say it is undefined,
> as far as I can see.  This is good enough from the point of view of a
> driver author, in that the driver can't depend on anything about the
> value read, but it is somewhat difficult from the point of view of an
> emulator author.

Well. It say "when read while the port is operating, it causes the 
controller to initiate polling". So when it's not operating, it 
(obviously) don't trigger the polling.

I do read that as then basically nothing happens, since the polling is 
the only function of the read, and that is only happening when the 
device is operating.

>> As for what you actually return, I would probably respond with 0 at
>> any time.
> 
> That's what I did.

And I guess, technically, based on documentation, you could return 
anything. As it's not defined, no software can care anyway.

>>>    * What does reading SA during normal operation return?  Are there any
>>>    *  side effects of such a read?
> 
>> The manual states:
> 
>> "When read by the host during normal operation, it communicates
>> status information including port- and controller-detected fatal
>> errors."
> 
>> I would say there are no side effects.
> 
>> Chapter 7 shows a list of errors that can appear in SA.
> 
> I see nothing about what's in bits 11-14 on error (likely S1-S4 during
> init, who knows what after that), nor what the register contains on
> non-error (except, by implication, that bit 15 is zero).

But you do. First of all, "operational" means S1 to S4 (ie, bits 11-14) 
are zero. The document also says "If ER=1 and a step bit is set, then a 
fatal error was determined during hard initialization".

Second, if you look at that second document I referred to, you have the 
explicit values that will be in SA for each error. All 16 bits of it.

To repeat: 
http://www.bitsavers.org/pdf/dec/disc/uda50/AA-M185B-TC_UDA50_Maintenance_Guide_Nov82.pdf

Page 18 and forward.

If you read the SA and there is no error is another story. I can't find 
anything about if anything meaningful is contained in bits 0-10 if the 
device is operating and there is no error.
(If I were to make a guess, it will all be zero, but that is not clear.)

>> But I'm not sure what is meant by "first time" here.
> 
> I no longer recall.  Presumably I wrote a naïve implementation based on
> the manual ("The host begins the initialization sequence either by
> issuing a bus INIT or by writing any value to the IP register.  The
> port must guarantee that the host will read zeros in SA on the next bus
> cycle.  Initialization then sequences through Steps 1-4...") and found
> the boot ROMs didn't work with it.

This sounds super weird, and considering that all the drivers I looked 
at (3 so far) work under these exact assumptions, I'm really wondering 
about that boot rom...

I can certainly see the possibility that you'll never read a zero from 
SA after a reset of the controller. Because it is guaranteed to be zero 
at the next cycle, but within some limited time period, it will no 
longer be zero, and reading on the exact next cycle is probably unlikely.

>>>    * The spec is also silent on the question of what order the elements
>>>    *  of the command and response rings are supposed to be used in.
>>> [...]
>> [...]  I wonder if perhaps the MSCP spec means to imply that when the
>> controller is kicked, it will actually always scan the whole ring,
>> and you would in theory not need to care where you put your packets.
> 
> I doubt it.  If the ring is even vaguely large, that would imply
> relatively frequent bursts of heavy DMA traffic.  But I do think it
> should be stated.

I agree that this is why I'm questioning that interpretation. But 
reading the docs, it *could* be interpreted that way.
Anyway, again, all the code I've read basically just start at 0, and 
then just keep moving forward until pausing all the time.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: [email protected]             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol