Date: Mon, 7 Jul 2003 17:46:12 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: sparc64@freebsd.org Subject: Re: pre-newbus address decoding Message-ID: <20030708004612.GA3359@dhcp01.pn.xcllnt.net> In-Reply-To: <20030707223217.GK44762@funkthat.com> References: <20030707210543.GA29440@ns1.xcllnt.net> <20030707213416.GG44762@funkthat.com> <20030707220139.GB29689@ns1.xcllnt.net> <20030707223217.GK44762@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 07, 2003 at 03:32:17PM -0700, John-Mark Gurney wrote: > > is this UART driver going to be generic enough that it will support ALL > serial devices? Don't forget that VERY few sparc64 machines have a NS16550 > compatible UART. Yes. Support will be added for SCCs (SAB82532 and Z8530) as well as the variants found on PC98. Note that SCCs are going to be supported in Async mode only. For Sync modes and SDLC/HDLC one better write a specific driver. > > all platforms (especially ia64 and sparc64) and most hardware. The > > low-level console code uses the newbus functions for I/O, but since > > newbus itself hasn't been initialized, needs machine dependent code > > to construct tags and handles. See also sparc64_fake_bustag() in > > sys/sparc64/sparc64/bus_machdep.c for how this is expected to work > > on sparc64. > > sparc64 users OFW for low-level console IO until newbus is initalized and > the proper driver is loaded. This is what ofw_console is for. No serial driver can technically claim to be the console when ofw_console is it. Try booting with -D. I saw double. > Currently sio doesn't know when it's console > and requires manual setting unlike the zs driver. sio(4) is too PC specific and fails to use of the platform when possible. sab(4) is too OpenFirmware specific and fails to avoid using the platform. zs(4) has a slightly better abstraction, but still assumes too much. Again: the right level of abstraction is the one we already have: newbus. All we need is the ability to construct a tag/handle pair prior to the initialization of newbus itself. > Personally, supporting OFW for console code like this will make it more > portable. No. It only works on OF based machines. > > 2. Consistency. All platforms are capable of supporting remote debugging > > using a serial interface and have the kernel drop into the debugger > > immediately after setting up the console. Not all platforms have this > > implemented. Clearly, we cannot use OFW to communicate over debug > > ports. > > Why do you say clearly? OFW was specificly designed to be able to be > used for debugging. Heck, the low level OFW console code can still output > to sio even once the sio driver is loaded. I mean in the current state of affairs. There's no GDB support. Nor is there support of booting with RB_KDB. We cannot make use of what is already there, because it does not work on sparc. Partly because the driver is non-portable, and partly because the sparc port is. > > 3. Extensibility. Our console code (ie pcvt and syscons) is in need for > > a replacement. It's too PC specific and is not going to work when > > UGA is the defacto standard on newer (EFI based) amd64, ia32 and ia64 > > machines. A possible future console framework is likely to be graphical > > to allow it to work with newer non-textual hardware. > > A similar argument applies to low-level console and/or debug port code > > that needs pre-newbus access to devices for with the OFW interfaces > > are not suitable. > > I still don't understand. Because OFW interface provides text drawing > on graphical frame buffers. So far you haven't said one feature that OFW > doesn't already support. Does it support writing to the framebuffer itself for splash screen support and other fancy stuff? > Q1 is bus specific and you need to look at the related bus attachment > documentation. I don't have a url handy for that, but it shouldn't be > hard to find using google. Q1 is only bus-specific if OFW doesn't provide an interface that hides the details. If OFW doesn't provide that interface then yes, you need to know what kind of bus it is and act accordingly. That's where Q2 and up come into play. We already have bus specific drivers, so all we need to do is make use of the knowledge that's already there. > Really, all of your questions are OS independant since you are assuming > that newbus (which makes FreeBSD, "FreeBSD") isn't initalized. Q1 is OS independent. Q2 and up are not. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030708004612.GA3359>