test at Target mode

[Kayoko Isshi]

"Justin T. Gibbs" wrote:

> >I doubted the hardware, but I cannot prove it.
> >It's reassuring that Adaptec co. is backing up.
> >When I questioned Adaptec co. on AIC7xxx assembler before,
> >they said that the information cannot be opened.
> >Now It's pleased to find opened ML and the assembler.
>
> The open sourced code had very little to do with Adaptec.  The
> target mode code you are using now was developed and released for
> FreeBSD long before I started work at Adaptec.  Most of it was
> done with little or now documentation on the chips - just lots
> of experimentation.  Adaptec is now supporting the open source
> effort (at least the initiator side), but they didn't help
> much from 1994-2000 when the bulk of the code was created. 8-)

I see the circumstances.
Now you cooperate in me.

> >Without CAM, target I/O system can be implemented under 6.1.13.
> >I have some changes:
> >1)When any abort message is received, sequencer should go to BusFree.
>
> This is supposed to be handled by the message handler in the kernel
> driver.  Abort is a rare occurance, so, other than honoring ATNI in
> all of the right places, the sequencer shouldn't waste instructions on
> handling abort on its own.

When sequencer goes to ITloop_target,it automatically goes to command phase.
How dose it go to BusFree directly?

> >2)When any abort message is received, sequencer should set SAVED_LUN.
>
> I believe the original intention was to just upload the "selection packet"
> to the host even if no command was sent and pull the info from there.
> I don't see much harm in setting the SAVED_LUN field the instruction
> after we have verified the identify message.  It will probably assist
> in diagnostics.  Making this a special case for the abort path seems
> cumbersome.

I will check the method without SAVED_LUN again.

> >3)When ABORT message(=1 bytes message) is received,
> >    driver cannot get it because ATNI is off.
>
> You mean the kernel handler for target messages doesn't work for 1
> byte messages?  That seems odd.  ATNI should drop after our REQ and
> before the ACK for the last byte.  You don't see this hapening?

I'm sorry that the explanation is not sufficient.
There are 3 cases when abort/reset message received:
    1)C006      →Abort message×        goto ident_message_done
    2)0C        →Device Reset message○ goto host_message_loop
    3)C020260d  →Abort tag message×    goto ident_message_done

Since next ATNI is off after getting last message,
ident_message_done dose not go to target_mesgout_pending,
but goes to ITloop_target.

If it gose to host_message_loop,
it invokes an INTSTAT interrupt with HOST_MSG_LOOP.
Then the driver can change the registers but cannot change the route.
If not so,ITloop_target automatically gose to command phase
and invokes an INTSTAT interrupt with CMDCMPLT.
Then the driver cannot change the process,
because sequencer has already gone to BusFree.

Maybe the above method is different with my design.

Thanks.
----------------
Kayoko Isshi


To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message