'RELENG_6_0_0_RELEASE'.

This commit was manufactured to restore the state of the 6.0-RELEASE image.

> Temporary hack to get the hme network interface on Sun E250 servers to
> work.  The code comment describes the issue, basically an as yet not
> totally understood interrupt routing problem.  This hack is being done
> to RELENG_6 so that the hme interface works on E250's for the release,
> but is not being done in HEAD so more work on the interrupt routing
> issue can be done.
>
> Requested by:	marius

Approved by:	re (scottl)

	sys/dev/uart/uart_cpu_sparc64.c 1.21

- Change the code that determines whether to use a serial console and
  which serial device to use in that case respectively to not rely on
  the OFW names of the input/output and stdin/stdout devices. While at
  it save on some variables and for sys/boot/sparc64/loader/metadata.c
  move the code in question to a new function md_bootserial() so it can
  be kept in sync with uart_cpu_getdev_console() more easily.
- Adjust the size of some buffers.
- Remove the package handle of the '/options' node from the argument
  list of uart_cpu_getdev_dbgport().

Approved by:	re (scottl)

not only means that it's possible (though unlikely) that we hand out
differing tags for the same bus space, it also means that the tags
we handed out are not used during bus enumeration. Both affect our
ability to compare tags. Fix the first by initializing our tags only
once. Fix the second by testing if one of the tags to compare is our
tag and the other is a busspace_isa_{io|mem} tag and declare them
equal if so.

This fixes using uart(4) as the serial console on a ds10. That is,
the low-level console worked, but we could not match the resources
to one of the UARTs found during bus enumeration, which prevented
uart(4) from becoming the console in single- or multi-user mode.

Approved by: re (kensmith)
MFC after: 2 days
Thanks to: all involved in getting a ds10 to me; directly or indirectly.
Special thanks to: Dave Knight, ISC (for not scratching my Porsche :-)

times which was added in the last revision with what should be a proper
solution as long as keyboards that were pluggged in after the kernel
has fully booted aren't supported. I.e. when sunkbd_configure() is
called for the high-level console probe make sure that the keyboard is
both successfully configured (i.e. also probed) and attached. The band-
aid left the possibility to attach the keyboard device to the high-level
console without attaching the keyboard device itself when the keyboard
is plugged in after uart(4) attached but before syscons(4) does.

share their IRQ lines with the i8042. Any IRQ activity (typically during
attach) on the NS16550 used to connect the keyboard when actually the
PS/2 keyboard is selected in OFW causes interaction with the OBP i8042
driver resulting in a hang (and vice versa). As RS232 keyboards and mice
obviously aren't meant to be used in parallel with PS/2 ones on these
boards don't attach to these NS16550 in case the RS232 keyboard isn't
selected in order to prevent such hangs.

Ok'ed by:	marcel

UARTs used to connect keyboards and not also PS/2 keyboards and only
return their package handle in case the keyboard is the preferred one
according to the OFW but otherwise still regardless of whether the
keyboard is used for stdin or not. This is simply achieved by looking
at the 'keyboard' alias and returning the corresponding package handle
in case it refers to a SCC/UART. This is change is done in order to
give the keyboard which the OFW or the user selected in OFW on boards
that support additional types of keyboards besides the RS232 ones also
preference in FreeBSD. It will be also used to determine on Sun AXi and
Sun AXmp boards whether a PS/2 or a RS232 is to be used as these are
sort of mutual exclusive there (see upcoming commit to uart_bus_ebus.c).
Note that Tatung AXi boards have the same issue but the former code
happened to already give the PS/2 keyboard preference by not identifying
the respective UART as keyboard system device there because the PS/2
keyboard node precedes the keyboard UART one in the OFW device tree of
these boards (which isn't the case for the Sun AXi).

Ok'ed by:	marcel

  a band-aid allowing to call this function savely multiple times, e.g.
  during sckbdprobe() and sc_probe_unit(). Otherwise calling it a second
  time results in a non-working keyboard. This needs a lot of more work
  to actually do the right thing and work like expected.
- Let sunkbd_configure() return the number of the found keyboards, i.e.
  1 in case probing succeeds, as it's expected. The return values of the
  keyboard configure functions however currently aren't checked so this
  doesn't make a difference at the moment.
- Use FBSDID.

The core console code checks this field when a console is added and
emits a warning if it's empty. In practice the warning is harmless for
uart(4), because the cn_name is filled in as soon as the device name is
known; which is when the device is enumerated.
To avoid the warning, to avoid possible complications caused by emitting
the warning without there (possibly) being a console selected yet and to
avoid complications when the UART isn't found during bus enumeration, we
just preset the cn_name field here to the name of the driver.

fact that access to RR0 does not need a prior write to the register
index because the index always reverts to 0 after the indexed register
has been accessed.

Typically when a RR or WR is to accessed, one programs the index (which
is a write to the control register), followed by a read or write to the
actual indexed register (a read pr write to the same control register).
When this non-atomic sequence is interrupted after having written the
index and low-level console I/O is done in that situation, the write to
program the index will actually write to the indexed register and nuke
state. This almost always yields a wedge.

By not programming the index register and instead just reading from RR0,
the worst case scenario is non-fatal. For if we don't actually read from
RR0 but some other register we get an invalid status, which may lead us
to conclude that the transit data register is empty when it's not or that
the receive data register contains data when it doesn't. Hence, we may
lose an output character or get a sporadic input character, but given
the situation this is a non-issue.

Full serialization is not possible due to the fact that this code needs
to work from DDB and before mutex initialization has happened.

In collaboration with: kris@, marius@
Tested by: kris@
MFC after: 1 day
X-MFC: 5.4-RELEASE candidate