| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
hubs are known during autoconf. Then, pick the most populated 2GB window
as our DMA memory window. xbridge(4) can thus program the correct settings
regardless of the order in which the xbow(4) attach.
|
| |
|
|
|
|
|
|
|
| |
Remember the hub widget number of each node, instead of only the master node.
Use this in xbridge to compute the proper direct DMA map configuration
register value (it needs to embed the hub widget number matching the
physical address range).
This should allow us to pick memory from a different node than the one
we booted from, as the DMA window, if wanted.
|
| |
|
|
| |
Discussed and okay drahn@. Okay deraadt@.
|
| |
|
|
|
|
|
|
|
|
| |
and routines to turn a KL console and a KL component structs, respectively,
into struct sgi_device_location for further device identification.
XXX Due to the way PCI devices are numbered on PIC buses, this code is tainted
XXX by knowledge about PIC widgets, to compensate. I have considered changing
XXX xbridge(4) to have our PCI device numbering match KL on PIC-connected
XXX devices, but I expect this to be even uglier. This is not settled yet.
|
| |
|
|
| |
No functional change yet.
|
| |
|
|
|
|
| |
fake ARCBios component structures associated to the KL configuration.
The ARCBios data tells us if the device is the output console, and the
KL component data tells us its node and widget numbers.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
processor (instead of sys_config.cpu[]), and pass it in the attach_args
when attaching cpu devices.
This allows per-cpu information to be gathered late in the bootstrap process,
and not be limited by an arbitrary MAX_CPUS limit; this will suit IP27 and
IP35 systems better.
While there, use this information to make sure delay() uses the speed
information from the cpu it is invoked on.
|
| |
|
|
|
|
| |
on all systems but O2 (to catch up soon). Also use the IOC4 MCR register to
figure out the IOC4 clock, instead of checking the widget control register,
to be consistent with iof(4).
|
| |
|
|
|
| |
foo bricks (they differ by having PCI-X bridges instead of PCI bridges
but are otherwise built the same)
|
| |
|
|
|
|
|
| |
memory initialization. This reduces memory test and initialization time
from a "in soviet russia, memory test you" time of over 2 minutes for 1GB
on Origin 200, to a more reasonable 12 seconds (and on a Fuel with 2GB,
time goes down from 6 seconds to under a second).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- introduce an interface for widget drivers to ask the xbow to map arbitrary
views of their address space, in addition to the low 16MB. This operation
may fail or map a subset range of what the caller asked for, depending on
the platform we're running on.
- use this in xbridge to set up views on the direct memory and i/o spaces,
to map devices resources when they don't fit in one of the devio small
ranges (limited to 2MB anyway). These views are only allocated when
devio can't do the job, so as not to consume too many resources on
Origin family systems where such views are scarce resources (and
shared accross the whole crossbow).
This makes pci devices with large resource needs configure correctly.
While there, fix programming of 64 bit memory BAR; this makes bge(4)
work.
Tested on Octane (with Bridge revision < 4 and >= 4), Origin 200 (Bridge >= 4)
and Fuel (XBridge).
ok deraadt@
|
| |
|
|
|
| |
other hardware resources will follow shortly.
Tested on a dual-Origin 200 setup.
|
| | |
|
| |
|
|
|
| |
and then restart system (NMI on these systems aren't intended to be
recoverable).
|
| |
|
|
|
| |
drivers with callback routines. While there, skip disabled or failed
components.
|
| |
|
|
| |
code.
|
| | |
|
|
|
some years ago for KL enumeration, building on the existing XBow support
to limit ourselves to a single node for now.
This is a work-in-progress; it currently lacks complete interrupt code,
as well as PCI resource management. And there are likely bugs creeping
inside.
|
miod
pirofti