Subject: (Limited) effects of RESET_START register

From: Peter Johansson <[email-masked]>
Date: Tue, 6 Apr 1999 15:44:29 EDT

In a message dated 99-04-06 09:36:48 EDT, [email-masked] writes:

<<I have a query regarding a write to RESET_START register (CSR register).
Actually a write to a RESET_START register causes a command reset. According
to IEEE 1394 std. 1995 sec:8.3.2.1 pg : 205 "A write to RESET_START reg in
cable environment shall not cause a reset of the PHY Layer nor a bus reset."

But the standard is not clear about a) should the node reinitialize the
transaction layer too. b) or it does reinitialization of applications above
transaction layer    which could be SBP-2 implementation, IP over 1394
implementation etc.>>

I don't believe that the transaction layer (maintenance of outstanding
transaction labels, etc.) is necessarily reset by a write to RESET_START.
Some transaction layer facilities expose themselves as CSRs; this is why the
CSR architecture (and 1394-1995) are careful to define CSR values after
various reset conditions. The three possible resets are a) power reset, b)
bus reset and c) command reset. Unless explicitly defined for any one of
these three cases, the register definition for "initial values" shall specify
the results for all of the resets. Notice that a reset of an
application-dependent CSR could cause partial or full reinitialization of the
application.

<<This Query arises when we read SBP-2 draft which states that if a write to
RESET_START register comes from one of the nodes that is *NOT* currently
logged-in initiators, the node shall ignore the command reset request.>>

And draft standard IEEE P1394a additionally narrows the effects of a command
reset (see clause 9.15).

<<Assume a scenario where we have two applications running over a OHCI Device
Driver, one being SBP-2 and other being IP over 1394. A valid initiator
node(peer SBP-2) initiates a command reset of a particular node, then if the
transaction layer is to be reinitialized then it affects the other
application also, namely IP over 1394.>>

As indicated above, I don't think this problem exists. It's my belief that a
command reset is mostly useful to reset (to a greater or lesser degree) the
operations of ALL of the unit architectures present within the node. The
extent of the reset is defined by the unit architecture.
Draft-IETF-IP1394-IPv4-14 defines no effects for a command reset.

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]