Date: Sun, 22 May 2005 20:13:13 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sparc64/sparc64 ofw_machdep.c Message-ID: <20050522201313.D75942@newtrinity.zeist.de> In-Reply-To: <d1f28189e2af839ffbb06c7a3dfb0730@xcllnt.net>; from marcel@xcllnt.net on Sat, May 21, 2005 at 03:16:06PM -0700 References: <200505212017.j4LKH1cM075616@repoman.freebsd.org> <d1f28189e2af839ffbb06c7a3dfb0730@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050522201313.D75942>