cvs commit: src/sys/dev/sab sab.c
marius at alchemy.franken.de
Mon Oct 18 13:58:55 PDT 2004
On Wed, Oct 13, 2004 at 01:19:20PM -0700, Marcel Moolenaar wrote:
> On Wed, Oct 13, 2004 at 11:44:22AM +0200, Marius Strobl wrote:
> > > >
> > > > Isn't this driver superseeded by uart(4) anyway ?
> > >
> > > Yes, in principle. I don't think I'm in the position to remove sab(4)
> > > though.
> > Uart(4) works fine as a replacement for sab(4) but we're not ready to
> > switch to uart(4) by default on sparc64.
> Z8530 issues, right?
The Z8530 issues are the biggest problem but there are others:
- When both uart(4) and ofw_console(4) are present but the input and output
are keyboard and screen respectively one ends up with no working console.
The problem simply is that the OFW keyboard driver no longer works once
uart(4) attaches to the keyboard port. A quick hack to uart_bus_probe()
to fail when the UART is the keyboard port but not a sysdev makes both
uart(4) and ofw_console(4) work happily together. But I'd rather make
uart(4) attach in sort of a disabled mode in the above case, i.e. claim
the resources but don't do anything with the UART, so nothing else can
attach to the respective UART, the user can be told what's going on and
device numbering is the same whether the keyboard is used directly or
- Using the second on-board 16550 on the ISA bus of sparc64 machines
causes a hang, i.e. an endless loop in uart_intr(), as these UARTs
share the same IRQ, uart(4) successfully registers both handlers as
fast ones but FreeBSD/sparc64 misses the MD part of shared fast
interrupt handlers (and also doesn't prevent setting up shared fast
interrupt handlers). A patch implementing the sparc64 part for shared
fast handlers is under review.
- There's no support for UARTs on the FHC bus (and for that matter also
not for powerpc/macio so zs(4) could be entirely replaced), yet. This
for one requires working Z8530 support but also a uart_bus_fhc.c and
support for FHC in the sparc64 OF_decode_addr() or better finally a
rewrite of OF_decode_addr() to be mostly bus-neutral (might even work
for powerpc then).
If there is a strong desire to remove sab(4) I'd say one could switch
to uart(4) by default on sparc64 once the first two problems above
are solved but one would have to disable support for Z8530 until
uart(4) really supports these or at least don't attach to the Z8530
that are keyboard or mosue ports as those currently causes the most
problems (Z8530 as console port works ok, but ttyb, i.e. the non-
console port of the first SCC doesn't reliably).
As for the Z8530 issues I spent quite a while trying to make it work
without success. I think the main problem is the "special" way uart(4)
work's around the problem that it can't use the interrupt status
register shared between the two channels. But there seem to be other
problems, e.g. according to my break-out box ttyb comes up in wired
states most of the time when the stock uart(4) initilizes it; I got it
to come up in a consistent state by rototilling the initialization to
be as close as possible to the datasheet but then ttyb never worked
(as opposed to sometimes with the stock uart(4)). The hang when
keyboard and mouse are unplugged is caused by an endless stream of
breaks on these ports in this case but for reasons unknown to me I
didn't manage to make the Z8530 to not trigger an interrupt on
I think the first step to get working Z8530 support is to create an
chip-aware scc(4) (as opposed to puc(4) which mainly is sort of a
resource multiplexer/splitter) but I currently don't really want to
deal with the other aspects of a scc(4) like synchronous mode etc.
More information about the cvs-src