Re: port-mac68k/37611: macs with cuda adb don't boot -current

[Scott Reynolds <scottr%NetBSD.org@localhost>]

The following reply was made to PR port-mac68k/37611; it has been noted by 
GNATS.

From: Scott Reynolds <scottr%NetBSD.org@localhost>
To: Martin Husemann <martin%duskware.de@localhost>
Cc: gnats-bugs%NetBSD.org@localhost
Subject: Re: port-mac68k/37611: macs with cuda adb don't boot -current
Date: Tue, 1 Apr 2008 00:44:22 -0500

 On Mar 31, 2008, at 10:29 AM, Martin Husemann wrote:
 
 > On Sun, Mar 30, 2008 at 09:18:44PM -0500, Scott Reynolds wrote:
 >> This doesn't answer the question as to why it's broken; there could
 >> certainly be something that I'm missing. I am interested in knowing
 >> which machine you're having trouble with, though.
 >
 > I have no idea how ROM interoperates here, so I am probably missing  
 > big
 > parts of the picture.
 >
 > Could you explain how adb_op_comprout() is supposed to work? AFAICT  
 > it changes
 > a random word on the stack, probably something where previous  
 > versions of the
 > compiler used to store something important. I suppose it should modify
 > that "something" via a global pointer instead.
 
 The completion routine is called at interrupt time with the a2  
 register set to the completion data buffer. This data buffer is  
 registered on a per-call basis to the various "send" functions. You  
 will find that most of the time the completion data buffer is actually  
 associated with the specific ADB command sent (it's a part of struct  
 adbCommand); this allows multiple asynchronous commands to be sent,  
 e.g. one to the keyboard and one to the mouse, which can respond with  
 completion independently of each other.
 
 There is another case in adb_op_sync() similar to the one you see in  
 adb_read_date_time(). The adb_op_sync() version times out, though. I  
 suspect that's what is needed here, especially if the TOD clock is  
 malfunctioning somehow, or doesn't exist.