FIDs to be 128-bits wide and adds support for realms.
Add a new CODA_COMPAT_5 option, which requests support for the old
Coda 5.x interface instead of the new one.
Create a new coda5.ko module that supports the 5.x interface, and make
the existing coda.ko module use the new 6.x interface. These modules
cannot both be loaded at the same time.
Obtained from: Jan Harkes & the coda-6.0.2 distribution,
NetBSD (drochner) (CODA_COMPAT_5 option).
device special files created by sio(4). The latter are the device
special files created by uart(4). As of this moment sio(4) is not
supported on ia64... by me, that is :-)
building a module. Inclusion of option files (opt_ddb.h in this
case) is not possible for modules. The inclusion of opt_ddb.h
in this header is questionable.
(ns8250 copied and s/ns8250/i8251/g), but there for linkage purposes.
Real code to follow, once I get past some boot issues on my pc98 boxes
with recent current.
of what uart(4) is and/or is not see the initial commit log of one
of the files in sys/dev/uart (or see share/man/man4/uart.4).
Note that currently pc98 shares the MD file with i386. This needs
to change when pc98 support is fleshed-out to properly support the
various UARTs. A good example is sparc64 in this respect.
We build uart(4) as a module on all platforms. This may break
the ppc port. That depends on whether they do actually build
modules.
To use uart(4) on alpha, one must use the NO_SIO option.
It improves on sio(4) in the following areas:
o Fully newbusified to allow for memory mapped I/O. This is a must
for ia64 and sparc64,
o Machine dependent code to take full advantage of machine and firm-
ware specific ways to define serial consoles and/or debug ports.
o Hardware abstraction layer to allow the driver to be used with
various UARTs, such as the well-known ns8250 family of UARTs, the
Siemens sab82532 or the Zilog Z8530. This is especially important
for pc98 and sparc64 where it's common to have different UARTs,
o The notion of system devices to unkludge low-level consoles and
remote gdb ports and provides the mechanics necessary to support
the keyboard on sparc64 (which is UART based).
o The notion of a kernel interface so that a UART can be tied to
something other than the well-known TTY interface. This is needed
on sparc64 to present the user with a device and ioctl handling
suitable for a keyboard, but also allows us to cleanly hide an
UART when used as a debug port.
Following is a list of features and bugs/flaws specific to the ns8250
family of UARTs as compared to their support in sio(4):
o The uart(4) driver determines the FIFO size and automaticly takes
advantages of larger FIFOs and/or additional features. Note that
since I don't have sufficient access to 16[679]5x UARTs, hardware
flow control has not been enabled. This is almost trivial to do,
provided one can test. The downside of this is that broken UARTs
are more likely to not work correctly with uart(4). The need for
tunables or knobs may be large enough to warrant their creation.
o The uart(4) driver does not share the same bumpy history as sio(4)
and will therefore not provide the necessary hooks, tweaks, quirks
or work-arounds to deal with once common hardware. To that extend,
uart(4) supports a subset of the UARTs that sio(4) supports. The
question before us is whether the subset is sufficient for current
hardware.
o There is no support for multiport UARTs in uart(4). The decision
behind this is that uart(4) deals with one EIA RS232-C interface.
Packaging of multiple interfaces in a single chip or on a single
expansion board is beyond the scope of uart(4) and is now mostly
left for puc(4) to deal with. Lack of hardware made it impossible
to actually implement such a dependency other than is present for
the dual channel SAB82532 and Z8350 SCCs.
The current list of missing features is:
o No configuration capabilities. A set of tunables and sysctls is
being worked out. There are likely not going to be any or much
compile-time knobs. Such configuration does not fit well with
current hardware.
o No support for the PPS API. This is partly dependent on the
ability to configure uart(4) and partly dependent on having
sufficient information to implement it properly.
As usual, the manpage is present but lacks the attention the
software has gotten.
o Introduce PUC_PORT_TYPE_UART so that we can attach to uart(4),
o Introduce port sub-types (eg PUC_PORT_UART_NS8250, PUC_PORT_UART_Z8530)
to handle different hardware and determine resource sizes.
o Introduce two new IVARs: PUC_IVAR_SUBTYPE and PUC_IVAR_REGSHFT. Both
are used by uart(4) to get sufficient information to talk to the HW.
o Introduce PUC_FLAGS_ALTRES to tell puc(4) to try memory mapped I/O
if I/O port space cannot be allocated, or vice versa.
o Have ports of type PUC_PORT_TYPE_COM attach to uart(1) if attaching
to sio(4) fails (due to not having the sio driver).
o Put struct puc_device_description in struct puc_softc instead of
having a pointer to a device description in the softc. This allows
us to create device descriptions on the fly without having to use
malloc() or otherwise have them staticly defined.
o Move puc_find_description() from puc.c to puc_pci.c as it's specific
to PCI.
o Add EBUS and SBUS frontends for use on sparc64. Note that the P in
puc stands for PCI, so we kinda mess things up here. It's too soon
to worry about it though. We'll know what to do about it in time.
NOTE: This commit changes the behaviour of puc(4) to not quieten the
device probe and attach for child devices. The uart(4) driver provides
additional device description that is valuable to have.
we actually use. Originally, the code reserved 0x8000 to 0x80ff inclusive
which on my hardware conflicts with the acpi timer. This broke the amdpm
driver since it was actually given ports 0x800c to 0x810b (which should
not have happened, IMHO).
This also allows us to considerably simplify the handling of the nForce
smb driver, removing the need for a separate nfpm driver. With this, SMB
accesses appear to work on my Tyan Tiger MP board. Your mileage may vary.
In particular, the nForce changes have not been tested.
we can switch to 64M-sized identity mappings and not having to map the
first 64M. This is especially important because the first 1M contains
the VGA frame buffer and is otherwise a legacy memory range. Best to
make as little assumptions about it as possible. Switching to 64M-sized
mappings is important to avoid creating overlapping translations, which
have the side-effect of triggering machine checks. This is currently
what's preventing us to boot on an Intel Tiger 4.
Note that since we currently use 256M-sized identity mappings, we
would reduce the size of the mappings and consequently increase the
TLB pressure. The performance implications of this are minimal if
measurable at all because identify mappings are not our primary
means for memory management.
Also note that there's no guarantee that physical memory exists at
64M. Then again, we didn't had the guarantee when we were loading at
5M. We'll deal with this when it's a problem.
Discussed with: arun@
Special thanks to Pavlin Radoslavov <pavlin@icir.org> for testing and
fixing numerous problems.
Sponsored by: FreeBSD Foundation
Reviewed by: Pavlin Radoslavov <pavlin@icir.org>
and/or INTR_FAST. This belongs elsehwere and perhaps under bootverbose;
I'm committing it for now as it's uesful to know which drivers have
been converted and which have not.
we return to kernel or userland. This triggered a panic in a KSE
application when TDF_USTATCLOCK was set in the case userland was
interrupted, but we never called ast() on our way out. As such,
we called ast() at some other time. Unfortunately, TDF_USTATCLOCK
handling assumes running in the interrupt thread. This was not
the case anymore.
To avoid making the same mistake later, interrupt() now returns
to its caller whether we interrupted userland or not. This avoids
that we have to duplicate the check in assembly, where it's bound
to fall off the scope. Now we simply check the return value and
call ast() if appropriate.
Run into this: davidxu
