Hello,

>> i wonder if the driver can move to dev/ofw and become used by both
>> macppc & sparc64?
>    In theory that shouldn't be too difficult, although there are a few
>    weirdnesses - just one example: macppc and sparc64 disagree about 
> the
>    OF_interpret function - one uses OF_interpret(const char *, int, 
> int,
>    ...), the other uses OF_interpret(const char *, int, ... ), then 
> there
>
> what's the extra parameter do?  i wonder if OF_interpret() shouldn't
> have a stable API across all OFW platforms (in netbsd.)
According to the headers it sets the number of input parameters - 
apparently the form with 2 ints does some sort of printf()-like 
parameter substitution. And yes, it should be the same API for all OF 
platforms, somehow I expected it and was rather surprised that it 
isn't.

>    are the obvious problems with 64bit vs 32bit ( although these are 
> just
>    a matter of choosing the correct data type ). macppc does some 
> voodoo
>
> cell_t is the datatype you're after?  it should just work, depending on
> the bitsize the compiler wants etc?
Not really, the macppc code assumes pointers to be 32bit for instance, 
and to make matters worse the address property in OFs device tree is 
also just 32bit - macppc just uses an int and casts it to a pointer - 
sparc64 needs to expand it to 64bit first.

>    to make the framebuffer cacheable, I don't think it would work the 
> same
>    way on sparc64.
>
> yeah.  we can ignore that bit for sparc64 initially.
That's what I'm doing :)

>    The other OF calls are exactly the same.
>    With a little fiddling it could probably talk to SBus framebuffers 
> too,
>    the only reason it attaches to pci is that it does so on macppc.
>
> yeah.  i'm just thinking that if it can become a shared driver it would
> be a better move over all.
Certainly. No reason to keep two drivers which differ only in some 
details.

There are still a few problems to iron out - so far I can't get it to 
become ttyE0 - either none of the ttyE*s works or it picks one >0, 
apparently because I didn't attach using wsemul_cnattach - if I do I 
get panics, either in cnattach itself or later when rc.wscons tries to 
add more screens. Maybe there's still some more subtle data size 
mismatch somewhere hidden.
/dev/console works just fine though.

have fun
Michael