Re: TO DO, was Re: localtalk, pcmcia etc.

[Finn Thain <fthain@telegraphics.com.au>]

On Wed, 19 Aug 2020, Brad Boyer wrote:

> On Thu, Aug 20, 2020 at 11:15:28AM +1000, Finn Thain wrote:
> > On Sat, 15 Aug 2020, I wrote, incorrectly:
> > > 
> > > I think macfb could be replaced entirely by simplefb and some nubus 
> > > drivers, now that nubus has actual drivers under the Linux driver 
> > > model (as of Linux v4.16).
> > > 
> > 
> > I was forgetting about palette operations. So macfb is actually 
> > required for on-board video hardware.
> 
> That's fine, although at least Valkyrie already has a separate driver as 
> it is also used in some PowerPC models. Would separating them out like 
> they are there make the code simpler?

Optimistically, that driver could become so comprehensive as to acquire a 
complexity problem in need of a solution like that. I don't think we've 
reached that goal yet.

But I can see some value in splitting off the nubus card support into a 
separate driver (e.g. macfb-nubus) in the course of supporting multiple 
displays. The on-board driver (e.g. macfb) will probably never need to 
instantiate multiple devices.

> I know there is also a separate driver for Control, which is the video 
> chip on the various PowerMac 7x00 models.
> 
> > > As of Linux v5.1 you can configure SCC IOP bypass using /dev/nvram 
> > > on 68k Macs. (I wonder whether PRAM reset would enable or disable 
> > > bypass...)
> > > 
> > 
> > /dev/nvram functionality works on IIfx but not Quadra 900/950 models 
> > because there's no Caboose driver yet. RTC and soft power control 
> > functionality are also missing on Quadra 900/950 for the same reason.
> 
> That might be a tough one. I've never heard of anyone finding good 
> documentation on Caboose. This may be one thing that has to be 
> completely reverse engineered by disassembling the ROM code. Even on the 
> various IIfx craziness, we still managed to find some basic information 
> to give us a head start.
> 
> The official board diagram for the Q900 shows Caboose connected to VIA1 
> instead of directly to the CPU. The MESS hardware information claims it 
> is a 68HC05 just like Egret and Cuda.

I would not be surprised if the Caboose chip was a forerunner of the Egret 
chip (which was itself the forerunner of the Cuda).

AFAIK, all of three designs are or were publicly undocumented up until 
mkLinux gave us an open source Cuda driver.

> Perhaps we should try the via-cuda driver with ADB disabled and see what 
> happens?
> 

Yes.