NetBSD Problem Report #6200
Received: (qmail 20876 invoked from network); 26 Sep 1998 06:50:15 -0000
Date: Fri, 25 Sep 1998 23:50:08 -0700 (PDT)
From: "Erik E. Fair" <email@example.com>
Subject: video intialization of Shark Rev 5 CyberPro2010 chip
>Synopsis: video intialization of Shark Rev 5 CyberPro2010 chip
>Arrival-Date: Sat Sep 26 00:05:01 +0000 1998
>Last-Modified: Tue Jul 17 07:43:45 +0000 2007
>Originator: Erik E. Fair
>Release: NetBSD-current, 19980924
International Organization of Internet Clock Watchers
DEC Shark, rev 5, 32 MB, netbooted.
System: NetBSD digital.clock.org 1.3 NetBSD 1.3 (DIGITAL) #1: Mon May 25 14:16:49 PDT 1998 firstname.lastname@example.org:/usr/src/sys/arch/sparc/compile/DIGITAL sparc
I have an unmodified Shark that I've hooked to a television
with both S-Video and composite (RCA) jacks. When the device
is first booted, the PROMs initialize the video, and it
looks OK (overscanned, but OK) on a garden variety Sony TV.
Unfortunately, when the NetBSD kernel takes over, the video
goes from working to not working in that the screen spins
vertically (something that twiddling with the old "vertical
hold" knob on a TV might fix, if mine had one...).
Why are the NetBSD kernel's video initialization parameters
for this chip different than the PROMs?
Inspect the FCode that initializes the CyperPro 2010 chip,
and change the NetBSD/arm32 video driver to match.
Write to FirmWorks, inquire about the parameters, and change
the NetBSD/arm32 video driver to match.
From: Todd Vierling <email@example.com>
To: "Erik E. Fair" <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org
Subject: Re: port-arm32/6200: video intialization of Shark Rev 5
Date: Sat, 26 Sep 1998 11:02:53 -0400 (EDT)
On Fri, 25 Sep 1998, Erik E. Fair wrote:
: I have an unmodified Shark that I've hooked to a television
: with both S-Video and composite (RCA) jacks. When the device
: is first booted, the PROMs initialize the video, and it
: looks OK (overscanned, but OK) on a garden variety Sony TV.
: Unfortunately, when the NetBSD kernel takes over, the video
: goes from working to not working in that the screen spins
: vertically (something that twiddling with the old "vertical
: hold" knob on a TV might fix, if mine had one...).
: Why are the NetBSD kernel's video initialization parameters
: for this chip different than the PROMs?
Your options are:
- use ofcons instead of pccons,
- use X-Windows xdm over top of pccons with 31.5 x 60 scan rates,
and don't see the boot messages.
At the current time there is no alternative. That is because the default
SHARK console is pccons, who sets the video up for 80x25 VGA scan rate.
Some more detail:
The default OpenFirmware console opens up at 31.5 KHz horizontal, 60 Hz
vertical. The composite output is precisely half the horizontal rate: 15.5
KHz horizontal, 60 Hz vertical, just what is needed for composite output.
In the Amiga world, it's much like DblNTSC vs. NTSC video.
The pccons console increases that rate, IIRC, to 35 KHz horizontal, which
completely throws off the half-rate video for composite (now 17.5 KHz).
Hence you see a messed up screen on your composite monitor/TV.
If you set your XF86Config file properly to a monitor that allows only 31.5
KHz by 60 Hz, you should get proper X display. Unfortunately, if you switch
to ofcons such that you could see boot messages, you will lose the ability
to do X.
(Though you know this next part more than likely, for the benefit of other
readers:) We're working on a replacement for all those console drivers on
the various ports, called nwscons. It has support for a great variety of
video modes, including bitmapped as well as text. We _hope_ to have it
working by 1.4; and after all, Shark support is only available in -current
: Inspect the FCode that initializes the CyperPro 2010 chip,
: and change the NetBSD/arm32 video driver to match.
This isn't really an alternative. The pccons code would need more changes
to accomodate the differing screen. (For one, the ofcons screen is 80x30.)
The video mode itself is simple to figure out.
-- Todd Vierling (Personal email@example.com; Bus. firstname.lastname@example.org)
Responsible-Changed-When: Mon Dec 28 09:35:45 PST 1998
This PR is the responsibility of the portmaster,
not the GNATS database administrator.
Responsible-Changed-When: Sun Apr 7 07:41:34 PDT 2002
This is a shark bug.
State-Changed-When: Mon, 12 Mar 2007 12:42:03 +0000
Have you tried this with NetBSD-current? It might be fixed thanks to all
the changes to wscons and the screen driver (whose name I don't remember
now). If not, shall I be able to reproduce it hooking my rev5 shark to
*any* TV? (s/shall/should/ in the line above... can't fix...)
From: "Erik E. Fair" <email@example.com>
Subject: Re: port-shark/6200
Date: Mon, 16 Jul 2007 22:11:08 -0700
Alas, in my move from Mountain View to Lake Tahoe, my sharks vanished
(perhaps afraid of all that frigid fresh water?), and so I am unable
to test more recent NetBSD releases. I still have access to the TV
(I gave it to my next-door neighbor), so if the sharks turn up in
some box I haven't opened ...
State-Changed-When: Tue, 17 Jul 2007 07:43:45 +0000
feedback has been provided.
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.