cvs commit: src/sys/sparc64/sparc64 ofw_machdep.c

[Marius Strobl]

On Sat, May 21, 2005 at 03:16:06PM -0700, Marcel Moolenaar wrote:
> On May 21, 2005, at 1:17 PM, Marius Strobl wrote:
> *snip*
> >   - Make sure that the OFW address properties that are going to be 
> > decode
> >     consist of the expected number of address and size cells (we can't 
> > use
> >     dynamic arrays here because at the point in the boot process when 
> > this
> >     code is used malloc() doesn't work, yet). This fixes a Fast Data 
> > Access
> >     MMU Miss when uart(4) (erroneously) calls OF_decode_addr() to 
> > decode
> >     the address of PS/2 keyboards.
> 
> Interesting. Do you know why uart(4) calls OF_decode_addr() in that
> case?

In short because the nodes of PS/2 keyboards also have a 'keyboard'
property and their 'device_type' property is also 'serial'. Therefore
uart_cpu_getdev_keyboard() of uart_cpu_sparc64.c matches the nodes of
SCCs/UARTs serving as keyboard controllers and PS/2 keyboards alike.
Note that I screwed the comment I added to uart_cpu_getdev_keyboard()
somewhat; it actually also matches PS/2 keyboard nodes rather than
their parent/controller nodes and it doesn't match USB keyboard
nodes as those don't have a 'device_type' property (I didn't have
an USB keyboard back then).
With the approach uart_cpu_getdev_keyboard() currently takes one
can't tell nodes of SCCs/UARTs serving as keyboard controllers and
those of PS/2 keyboards apart without also looking at the 'name'
property. I can't think of another approach to this if we want to
keep identifying SCCs/UARTs serving as keyboard controllers also
when the keyboard is not the chosen input-device or not plugged in.
So in order properly fix this the only choice we have probably is
to also check the 'name' property for names of SCCs/UARTs which
are known to be used in that way (should be 'su', 'su_pnp' and
'zs'; the SAB82532 as well as NS16550 on ISA aren't used to
connect keyboards).

> And is it something uart(4) needs to be taught not to do?

I'd say we should eventually make uart_cpu_getdev_keyboard() not
match PS/2 keyboard nodes but not before fixing other stuff/
ensuring the whole thing works as expected. The crux is to do
the right thing when there is more than one keyboard (controller).
I'd think that at least for the low-level console we should
adhere to what the chosen input device in OFW is (to what extent
the keyboard mux stuff once implemented makes sense on sparc64
is another storry). The RS232 keyboard support of uart(4),
sunkbd_configure() in particular, however currently doesn't care
about whether the RS232 keyboard is the chosen input device or not.
PS/2 vs. RS232 keyboards in particular is only an issue on AXi
boards (there are others supporting PS/2 keyboards but these
can't also use RS232 keyboards, not taking into account that in
theory these keyboards work on any RS232 port including e.g. on
i386). The funny thing with PS/2 keyboards on sparc64 is that
the respective nodes (8042, keyboard, mouse) only appear in the
OFW device tree if there actually is a keyboard plugged in. On
the AXi boards the PS/2 keyboard node additionally happens to
occur before the keyboard UART. So the outcome of the current
code in uart(4) is that determining the keyboard UART fails
making the PS/2 keyboard (assuming support for atkbdc(4) on
ebus(4)) the default keyboard in FreeBSD. As the OBP also gives
preference to PS/2 keyboards over RS232 ones this behaviour
probably basically also is what a user would expect to happen.
I didn't give it a try, yet, but I think with the current code
syscons(4) would end up defaulting to the RS232 keyboard in
this case if we just made uart_cpu_getdev_keyboard() not match
PS/2 keyboard nodes.
For 6.0 I'm trying to get all the keyboard hardware on sparc64
and the common and typical configurations basically working.
Which means that for RS232 and USB keyboards I'm already done,
leaving the nits (keyboard LEDs in X, usb(4)/ukbd(4) leaving USB
keyboards in a state OBP doesn't like, etc.) and corner cases
in configurations for afterwards...

Marius