| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Most of the hard work by mpi@, who provided the initial diff.
Fixes for sparc from myself. Tested on sgi and sparc myself.
Compiles and detects zstty on my powerbook, compile tested on
sparc64 by me. Real testing with zs device on sparc64 by miod@
who also gave a lot of help and feedback.
ok miod@, mpi@
|
|
|
|
as some odd mips designs need moro than 32 bits in there. This causes a lot
of mechanical changes everywhere getsr() is used.
|
|
such statements with it.
|
|
and will report the link being down too aggressively. Better to always report
the link as up - these systems and boards are single media only so it won't
harm much.
Unbreaks dhcp in the installer on these interfaces; found the hard way by
sebastia@
|
|
controller. In this mode, access to physical memory are not allowed to
bypass the cache, and this allows the memory subsystem to run faster.
Of course, some device drivers will require uncached memory access (e.g.
for proper HPC DMA descriptor operation).
New ip22-specific functions to switch between `fast mode' and `slow mode'
are introduced.
hpc(4) now provides read and write routines to fetch a dma descriptor from
uncached memory into a local copy, and update it from said modified copy.
On systems without the ECC MC, these will do nothing and operation will
continue to access the uncached memory directly. On systems with the ECC MC,
they will perform a copy, and the writeback will be done in slow mode.
bus_dmamem_map() requests for DMA memory with BUS_DMA_COHERENT set in flags,
which would return uncached memory, will now always fail on systems with
the ECC memory controller. Drivers which really need uncached memory, and
are aware of this particular setup, will now pass
BUS_DMA_COHERENT | BUS_DMA_BUS1, which will let the request succeed.
sq(4) will use all of the above to work mostly unmodified on ECC MC systems
in fast mode.
Finally, fast mode is enabled after autoconf.
Tested on IP22 and IP28.
|
|
from a (non-compiling) diff from Brad.
|
|
Previous change was a tad too optimistic. This repairs E++ and GIO SCSI board
operation.
|
|
is inverted on Indigo, this just means that Indigo does not use the same
values as the later models. It does not mean that the Indigo is using wrong
values, which is how I first read this. In reality, Indigo systems use the
expected values of these signals being active low, while later designs
use active high signals.
So yes, some systems have inverted values - but the ones which need
compensating are not those I thought.
Change the logic to do TRT, but keep the device flags check, to be able to
force the other behaviour if the kernel guesses wrongly. Tested on Indigo,
Indy and Indigo 2.
|
|
|
|
|
|
figure out whether they attach to the onboard hpc or to an expansion slot
(or the Challenge S IO+ mezzanine). No functional change (yet)
|
|
amount of TX empty interrupts.
|
|
to, so make this controllable with device flags, and default to non-bogus
wiring.
|
|
console keyboard, otherwise led update commands will never get transmitted.
Noticed by sebastia@
|
|
regular `one key is up' events. Makes the shift, alt, ctrl, etc keys behave as
expected after the next keystroke.
|
|
|
|
From NetBSD.
|
|
where applicable (i.e. Indy only).
|
|
temporarily disabled (and then reenabled later). Will be necessary for the
next driver commit.
|
|
(NG1, XL, XGE) frame buffer.
Adapted from NetBSD; newport extended to support underline and fonts wider than
8 pixels, such as the default 12x22 Gallant font. Framebuffer depth computation
seems to be wrong on Indy models, to be investigated later (but doesn't prevent
text console from working).
|
|
- break each hpc1/hpc3 child lists into two lists, one for the onboard
devices, and one for the expansion devices.
- do not try to attach Indy-only devices (pckbc, haltwo) on Challenge S.
- do not duplicate entries for expansion devices, only with different interrupt
numbers depending on the system, but instead use a single entry with -1 as
the interrupt level, and have the attachment glue figure out which
interrupt vector applies, depending upon the system.
- on expansion hpc1 (or 1.5) boards, do a minimal bus check to decide whether
or not the hardware we are attaching is there, since we currently don't
know how to tell E++ (sq only) and GIO32 SCSI (wdsc only) boards apart.
This hopefully will get rid of misleading `device not configured' messages.
|
|
need to have knowledge of the underlying interrupt controller. No functional
change.
|
|
|
|
the current logic can be traced back to DaveM's intership at SGI in 1996,
and are adequate for the hardware he had access to.
However, ``recent'' Indigo2 and Indy systems are fit with a faster (33MHz
instead of 25MHz) GIO64 bus, which need different timing parameters, and
guess what? The PROM knows the right values to set.
Since programming these timing registers was apparently only necessary for
the Challenge S second interface:
1) only reprogram those registers on an IP24 (Indy, Challenge S) system.
2) pick proper values depending upon the actual GIO64 bus speed.
Item #1 fixes Ethernet operation on Indigo2 (at least my teal R4400SC).
Item #2 fixes Ethernet operation on my R5000SC Indy.
For the record, programming unoptimal value caused `TX DMA underrun' errors
(documented as `can't happen' in the HPC3 documentation, oh the irony),
which could be reproduced reliably with ypbind(8).
|
|
Indy PROM versions use different year bases - after all, using 1970 instead
of the previously used value of 1940 smelled like a bug, and probably was,
so this eventually got fixed in later PROM versions.
Instead of hardcoding a year base depending upon the system, we will now ask
ARCBios for its current year, and compare it to what can be read from the RTC
registers to figure out what year base is in use by the PROM.
|
|
the timebase on Indigo 2, but 1970 on Indy (verified with the `date' command
at the PROM prompt and checking what values ended up in the DS1286).
Indy will no longer be 30 years in the future from an IRIX point of view.
|
|
every register write. Hinted by IRIX' <sys/z8530.h>.
While there, flip the CTS, DCD, RTS and DTR bits in registers #0 and #5.
Aforementioned header says they are inverted due to a hardware bug.
Tested on IP20, IP22 and IP24.
|
|
PIO write buffer.
|
|
layout is enough to enforce this. Don't request DMA page boundary alignment
when allocating them.
|
|
narrow these in the various ipXX_machdep.c. On IP22-like systems, narrow
them to 28 bit physical addresses, but unpessimize this by extending this
to 32 bit after autoconf, if no 28-bit limited hpc(4) device has been found.
Since physical memory on these systems start at 128MB, this means that Indigo
systems with more than 128MB memory will behave correctly (and so will Indy
systems with E++ boards and more than 128MB memory).
|
|
TX interrupts since the TX interrupt handler now correctly acknowledges it.
|
|
install seen on IP22 and IP24.
|
|
out to be the same value).
|
|
(IP20, IP22, IP24) in 64-bit mode, adapated from NetBSD. Currently limited
to headless operation, input and video drivers will get ported soon.
Should work on all R4000, R4440 and R5000 based systems. L2 cache on R5000SC
Indy not supported yet (coming soon), R4600 not supported yet either (coming
soon as well).
Tested to boot multiuser on: Indigo2 R4000SC, Indy R4000PC, Indy R4000SC,
Indy R5000SC, Indigo2 R4400SC. There are still glitches in the Ethernet driver
which are being looked at.
Expansion support is limited to the GIO E++ board; GIO boards with PCI-GIO
bridges not ported yet due to the lack of hardware, and this kind of driver
does not port blindly.
Most of this work comes from NetBSD, polishing and integration work, as well
as putting as many ``R4x00 in 64-bit mode'' erratas as necessary, by yours
truly.
More work is coming, as well as trying to get some easy way to boot install
kernels (as older PROM can only boot ECOFF binaries, which won't do for the
kernel).
|
