NetBSD on Sun's 32-bit Sparc based machines (NetBSD/sparc)

Sanford Barton | 1 Aug 2009 19:54

Picon

SS20 cg14 help

Hi,

Just did an install of 4.0.1 on my SS20.  Trying to get the CG14 (8mb
VSIMM) working with X.

When I execute startx, the screen flashes a couple of times and comes back with:

"X connection to :0.0 broken (explicit kill or server shutdown)"

I put a CG6 card in and it started X with no isses which is kinda
weird because I had the console set to use the cg14 so i was kinda
expecting to have to tell it to use the CG6 somehow.  So I took the
CG6 out again and just used the CG14 and get the above error.

Any pointers welcome.

Thanks,
Bart

Bruce O'Neel | 4 Aug 2009 13:05

Picon

Re: SS20 cg14 help

Hi,

It's been a while (and I no longer have a SS20 with a CG14 
to test on but...)

Are you sure that you're using 24 bit mode?  I don't remember the
CG14 working in 8 bit mode.

Looking at, what, /var/log/X*.log will probably give some sort of clue.

cheers

bruce

On Sat, Aug 01, 2009 at 11:54:15AM -0600, Sanford Barton wrote:
> Hi,
> 
> Just did an install of 4.0.1 on my SS20.  Trying to get the CG14 (8mb
> VSIMM) working with X.
> 
> When I execute startx, the screen flashes a couple of times and comes back with:
> 
> "X connection to :0.0 broken (explicit kill or server shutdown)"
> 
> I put a CG6 card in and it started X with no isses which is kinda
> weird because I had the console set to use the cg14 so i was kinda
> expecting to have to tell it to use the CG6 somehow.  So I took the
> CG6 out again and just used the CG14 and get the above error.
> 
> Any pointers welcome.

(Continue reading)

Michael | 4 Aug 2009 15:12

Picon

Re: SS20 cg14 help

Hello,

On Aug 4, 2009, at 7:05 AM, Bruce O'Neel wrote:

> It's been a while (and I no longer have a SS20 with a CG14
> to test on but...)
>
> Are you sure that you're using 24 bit mode?  I don't remember the
> CG14 working in 8 bit mode.

It can do both, at the same time. There's a kernel option to make the  
cgfourteen driver pretend it's an 8bit part for X's sake.  
( CG14_EMULATE_CG8 or something like that )

The wsdisplay driver will run the console on the cg14 in 8 bit for  
speed and switch to 32bit for X, the wsfb driver should know which  
pixel format to use in both XFree86 and Xorg. There is a cg14 driver  
for XFree86 but all it does is to do the switch between 'native' 8bit  
and 24bit on its own and to provide a hardware cursor, which wsfb can  
do as well ( using the appropriate ioctl()s )

have fun
Michael

der Mouse | 4 Aug 2009 17:34

Re: SS20 cg14 help

> [The SS20] can do both [8 and 24 bpp], at the same time.

Indeed.  It makes for a very usable system, with 8bpp's speed for
undemanding applications like terminal emulation but 24bpp available
when (comparatively) good colour is called for.  One of the first
things I did when I started using a cg14 was to build a ddx layer that
knows how to do both on the screen at once.

Not quite as nice as it would be if we knew, for example, how to use
the blitter, but still substantially faster than 24bpp by itself.

> The wsdisplay driver will run the console on the cg14 in 8 bit for
> speed and switch to 32bit for X, the wsfb driver should know which
> pixel format to use in both XFree86 and Xorg.

If wsdisplay can't describe both pixel formats - and how to select
between them - it sounds like a reason to not use wscons X, at least on
the cg14. :)

> There is a cg14 driver for XFree86 but all it does is to do the
> switch between 'native' 8bit and 24bit on its own and to provide a
> hardware cursor, which wsfb can do as well ( using the appropriate
> ioctl()s )

I'm a little surprised at the implication that nobody has already done
a both-depths-on-the-screen-at-once cg14 layer for recent X; If anyone
is interested in basing one on my dual-depth code, I'm happy to share.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

(Continue reading)

Michael | 4 Aug 2009 18:12

Picon

Re: SS20 cg14 help

Hello,

On Aug 4, 2009, at 11:34 AM, der Mouse wrote:

> Not quite as nice as it would be if we knew, for example, how to use
> the blitter, but still substantially faster than 24bpp by itself.

The 'blitter' is actually half of a SIMD CPU nailed to the mainboard -  
'half' as in 'no jumps, branches and related stuff'. You're supposed  
to feed it instructions through an IO port, it has a bunch of  
registers, it could probably be used to do stuff like alpha blending  
but we have no docs at all on the actual instruction set.
Since it's onboard we could use it even without a cg14 present but  
apparently nobody at Sun even knows about this thing anymore :/

>> The wsdisplay driver will run the console on the cg14 in 8 bit for
>> speed and switch to 32bit for X, the wsfb driver should know which
>> pixel format to use in both XFree86 and Xorg.
>
> If wsdisplay can't describe both pixel formats - and how to select
> between them - it sounds like a reason to not use wscons X, at least  
> on
> the cg14. :)

This has nothing to do with wsdisplay at all. Again.

>> There is a cg14 driver for XFree86 but all it does is to do the
>> switch between 'native' 8bit and 24bit on its own and to provide a
>> hardware cursor, which wsfb can do as well ( using the appropriate

(Continue reading)

der Mouse | 4 Aug 2009 22:57

Re: SS20 cg14 help

>> Not quite as nice as it would be if we knew, for example, how to use
>> the blitter, but still substantially faster than 24bpp by itself.
> The 'blitter' is actually half of a SIMD CPU nailed to the mainboard
> - 'half' as in 'no jumps, branches and related stuff'.

I'd heard it said it was a DMA engine - which of course is not very
inconsistent with what you wrote.

I've also seen it said it has access to all of host RAM, not just
framebuffer RAM, and that this is why it shouldn't be accessible to
userland in general.

> You're supposed to feed it instructions through an IO port, it has a
> bunch of registers, it could probably be used to do stuff like alpha
> blending but we have no docs at all on the actual instruction set.

Yeah. :(  Like the cg6.  (I know how to use the cg6 for things like
lines and polygons and rectangular blits, but I understand there's a
lot more in there, including full 3D perspective transform....)

>> I'm a little surprised at the implication that nobody has already
>> done a both-depths-on-the-screen-at-once cg14 layer for recent X;
> I guess nobody cares enough.

Sounds that way.  Oh well, it works for me, and if anyone does decide
to do it, the offer of my code as a starting point is still open. :)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org

(Continue reading)

Michael | 5 Aug 2009 05:09

Picon

Re: SS20 cg14 help


Hello,

On Aug 4, 2009, at 4:57 PM, der Mouse wrote:

>>> Not quite as nice as it would be if we knew, for example, how to use
>>> the blitter, but still substantially faster than 24bpp by itself.
>> The 'blitter' is actually half of a SIMD CPU nailed to the mainboard
>> - 'half' as in 'no jumps, branches and related stuff'.
>
> I'd heard it said it was a DMA engine - which of course is not very
> inconsistent with what you wrote.

Well, in a way it is. An extremely weird one though.

> I've also seen it said it has access to all of host RAM, not just
> framebuffer RAM, and that this is why it shouldn't be accessible to
> userland in general.

It can access four memory areas which can be anywhere, framebuffer or  
not.

>> You're supposed to feed it instructions through an IO port, it has a
>> bunch of registers, it could probably be used to do stuff like alpha
>> blending but we have no docs at all on the actual instruction set.
>
> Yeah. :(  Like the cg6.

No, it's not anything lik the cg6. The cg6 has registers to feed it  
coordinates and whatnot, the SX works like a CPU - you feed it actual

(Continue reading)

der Mouse | 5 Aug 2009 07:38

Re: SS20 cg14 help

> [The SS20 onboard blitter/etc processor] can access four memory areas
> which can be anywhere, framebuffer or not.

Where did you get this info?  You clearly have had access to better
sources than I....

>>> You're supposed to feed it instructions through an IO port, it has
>>> a bunch of registers, it could probably be used to do stuff like
>>> alpha blending but we have no docs at all on the actual instruction
>>> set.
>> Yeah. :(  Like the cg6.
> No, it's not anything lik the cg6.

I actually meant, like the cg6 in that we have no docs on the
interesting parts, not in any other respect.

> I still hope SX docs will some day materialize on my doorstep,

Same here.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Michael | 5 Aug 2009 08:34

Picon

Re: SS20 cg14 help

Hello,

On Aug 5, 2009, at 1:38 AM, der Mouse wrote:

>> [The SS20 onboard blitter/etc processor] can access four memory areas
>> which can be anywhere, framebuffer or not.
>
> Where did you get this info?  You clearly have had access to better
> sources than I....

I talked to someone who designed graphics chips at Sun, unfortunately  
he didn't design the SX and I've been unable to contact the person who  
did.

>>>> You're supposed to feed it instructions through an IO port, it has
>>>> a bunch of registers, it could probably be used to do stuff like
>>>> alpha blending but we have no docs at all on the actual instruction
>>>> set.
>>> Yeah. :(  Like the cg6.
>> No, it's not anything lik the cg6.
>
> I actually meant, like the cg6 in that we have no docs on the  
> interesting parts, not in any other respect.

Well, we know enough about the cg6 to make it useful ( as in  
accelerated console, accelerated X ), unlike the SX.

>> I still hope SX docs will some day materialize on my doorstep,
>

(Continue reading)

der Mouse | 5 Aug 2009 08:36

Re: SS20 cg14 help

> I talked to someone who designed graphics chips at Sun, unfortunately
> he didn't design the SX and I've been unable to contact the person
> who did.

:(  Still, that's more info than I've found. :-/

>> I actually meant, like the cg6 in that we have no docs on the
>> interesting parts, not in any other respect.
> Well, we know enough about the cg6 to make it useful ( as in
> accelerated console, accelerated X ), unlike the SX.

True - well, true if you consider it not "useful" if you can't get
faster than dumb-framebuffer speeds.  I find 8bpp windows on the cg14
fast enough to be useful, while 24bpp is painful - but having 24bpp
available on the same screen is very nice.

>>> I still hope SX docs will some day materialize on my doorstep,
>> Same here.
> I'm not holding my breath though.

Same here. :-/

> Btw. some kind soul finally sent me an S24 - I've been reading your
> description of the hardware and it looks like it will be enough to
> write a kinda-sorta accelerated X driver ( fills, simple copies and
> colour expansion, apparently that's all we can get out of the
> hardware ).

Yeah, the acceleration is pretty rudimentary, but should be faster than
dumb framebuffer operations by a factor of somwhere between 2 and 32,

(Continue reading)

Michael | 5 Aug 2009 18:57

Picon

Re: SS20 cg14 help


Hello,

On Aug 5, 2009, at 2:36 AM, der Mouse wrote:

>> I talked to someone who designed graphics chips at Sun, unfortunately
>> he didn't design the SX and I've been unable to contact the person
>> who did.
>
> :(  Still, that's more info than I've found. :-/

Well, someone else established the contact.

>>> I actually meant, like the cg6 in that we have no docs on the
>>> interesting parts, not in any other respect.
>> Well, we know enough about the cg6 to make it useful ( as in
>> accelerated console, accelerated X ), unlike the SX.
>
> True - well, true if you consider it not "useful" if you can't get
> faster than dumb-framebuffer speeds.  I find 8bpp windows on the cg14
> fast enough to be useful, while 24bpp is painful - but having 24bpp
> available on the same screen is very nice.

Well, cg14 and SX are different things. We know enough to make the  
cg14 useful but not the SX.

>> Btw. some kind soul finally sent me an S24 - I've been reading your
>> description of the hardware and it looks like it will be enough to
>> write a kinda-sorta accelerated X driver ( fills, simple copies and
>> colour expansion, apparently that's all we can get out of the

(Continue reading)

Volker A. Brandt | 6 Aug 2009 00:57

Picon

Re: SS20 cg14 help

> Well, cg14 and SX are different things. We know enough to make the
> cg14 useful but not the SX.

Well, I have files here like "sx.c":

/*
 * Copyright (c) 1992-1993, by Sun Microsystems, Inc.
 *
 * Device and Segment Driver for SX graphics accelerator.
 */

#pragma ident           " <at> (#)sx.c 1.108     95/09/19 SMI"
...

and "sx_cmem.c":

/*
 * Copyright (c) 1992 Sun Microsystems, Inc.
 */

#pragma ident   " <at> (#)hat_sx.c 1.46      95/03/20 SMI"

/*
 * VM - Hardware Address Translation layer for SX.
 *
...

and a few more.

All of these are not redistributable.  But they only carry the

(Continue reading)

der Mouse | 6 Aug 2009 06:53

Re: SS20 cg14 help

>> Well, cg14 and SX are different things.  We know enough to make the
>> cg14 useful but not the SX.
> Well, I have files here like "sx.c": [...]
> and "sx_cmem.c": [...]
> All of these are not redistributable.  But they only carry the Sun
> copyright message, not any third party copyright.

Do you have them under NDA?  If not, I think in most jurisdictions it
would be legal for you to study them, deduce an interface spec, write
it up, and release it.  (I suppose it might be even if you are, but it
seems unlikely; that's just the kind of thing NDAs usually forbid.)

Of course, (a) I'm not sure my impression is accurate, and (b) even if
it is, I don't know whether your jurisdiction is one of "most", and (c)
if I were contemplating such a thing, I'd most certainly run the idea
past a lawyer first.  I mention it in case you're interested enough to
consider it worth into the possibility that it's legal where you are.

> Maybe if someone lobbied the right people, Sun might consider
> releasing these files...

That could certainly help.  But, have you read them?  Based on just
what you've said so far, it's possible that they're nothing but glue
layers, with the real smarts in the applications that speak to the
hardware - for example, framebuffer drivers are often like this, with
the code we'd really like to see being in the relevant window system
server.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

(Continue reading)

Erik Fair | 6 Aug 2009 14:02

Picon

Re: SS20 cg14 help


On Aug 5, 2009, at 21:53, der Mouse wrote:

> That could certainly help.  But, have you read them?  Based on just
> what you've said so far, it's possible that they're nothing but glue
> layers, with the real smarts in the applications that speak to the
> hardware - for example, framebuffer drivers are often like this, with
> the code we'd really like to see being in the relevant window system
> server.

Or in some "firmware" loader.

	Erik <fair <at> netbsd.org>

Volker A. Brandt | 6 Aug 2009 14:46

Picon

Re: SS20 cg14 help

> >> Well, cg14 and SX are different things.  We know enough to make the
> >> cg14 useful but not the SX.
> > Well, I have files here like "sx.c": [...]
> > and "sx_cmem.c": [...]
> > All of these are not redistributable.  But they only carry the Sun
> > copyright message, not any third party copyright.
>
> Do you have them under NDA?  If not, I think in most jurisdictions it
> would be legal for you to study them, deduce an interface spec, write
> it up, and release it.

ENOTIME

> > Maybe if someone lobbied the right people, Sun might consider
> > releasing these files...
>
> That could certainly help.  But, have you read them?  Based on just
> what you've said so far, it's possible that they're nothing but glue
> layers, with the real smarts in the applications that speak to the
> hardware - for example, framebuffer drivers are often like this, with
> the code we'd really like to see being in the relevant window system
> server.

ENOCLUE



To be a little less terse:  Yes, I think a dedicated person who has
the files could derive some h/w specs from the files.  I'm quite confident
it's legal if said person then stays away from the actual coding of a new

(Continue reading)

der Mouse | 6 Aug 2009 18:29

Re: SS20 cg14 help

> Given the age of the files, I believe that Sun does not really lose
> anything if they release the files.  It is more a challenge of
> finding someone at Sun who is willing to spend the time and effort of
> getting them released.

Aye.

It's the practicalities of getting the files - legally - into the hands
of someone with the time, inclination, and ability to go through and
extract the relevant data from them.  I've got the time and inclination
and quite probably the ability, but I don't know how hard it would be
to get me legal copies of the files.  I'm sure there are at least a
handful of others in basically the same situation.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Christian Corti | 19 Aug 2009 12:37

Picon

Picon

Re: SS20 cg14 help

Are the following files (and more of this kind) of any interest, or is the 
information already known?

cgfourteen.c
------------
[...]
#pragma ident   " <at> (#)cgfourteen.c 1.112 96/09/24 SMI"

/*
  * Driver for Campus-II MBus framebuffer (CG14).
  * The CG14 is made up of the MDI, the VBC, the RAMDAC, the PCG, and various
  * amounts of VRAM.  Together, these make up the VSIMM.
  * The CG14 provides access to 24 bit frame buffers and compatibility modes
  * for 8-bit and 16-bit (8+8) frame buffer access. The main functions
  * of this driver are to provide:
  *
  *      a) mappings to the MDI control address space which contains the cursor
  *         color look up tables, the DAC etc.
  *      b) mappings to the frame buffer a.k.a the VRAM in 8 different modes
  *         of access.
  *      c) a cgthree emulation mode to provide backwards binary compatibility
  *         for Pixrect/SunView applications.
  */
[...]

tcx.c
-----
#ifdef  SYSV
#pragma ident   " <at> (#)tcx.c
#else

(Continue reading)

Michael | 1 Aug 2009 21:55

Picon

Re: SS20 cg14 help


Hello,

On Aug 1, 2009, at 1:54 PM, Sanford Barton wrote:

> Just did an install of 4.0.1 on my SS20.  Trying to get the CG14 (8mb
> VSIMM) working with X.
>
> When I execute startx, the screen flashes a couple of times and  
> comes back with:
>
> "X connection to :0.0 broken (explicit kill or server shutdown)"
>
> I put a CG6 card in and it started X with no isses which is kinda
> weird because I had the console set to use the cg14 so i was kinda
> expecting to have to tell it to use the CG6 somehow.  So I took the
> CG6 out again and just used the CG14 and get the above error.
>
> Any pointers welcome.

Since you didn't give any useful details at all there's no way to  
figure out what's (not) going on.

have fun
Michael

Sanford Barton | 2 Aug 2009 00:39

Picon

Re: SS20 cg14 help

Any (pointers) welcome.  Spare me the BS please.

Michael | 2 Aug 2009 02:12

Picon

Re: SS20 cg14 help


Hello,

On Aug 1, 2009, at 6:39 PM, Sanford Barton wrote:

> Any (pointers) welcome.  Spare me the BS please.

Sorry, but "X doesn't start on hardware <whatever>" is not useful.

For starters:
which Xserver did you try to use - Xsun, Xsun24, Xorg?
what's in your xorg.conf and Xorg.0.log?
do you use a wscons kernel?

If you think that's BS I can't help you.

have fun
Michael

Return

Return to gmane.os.netbsd.ports.sparc.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane