wireguard-openbsd/sys/arch/sgi/include/mnode.h, branch jd/queueboosts WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/sgi/include/mnode.h?h=jd%2Fqueueboosts 2011-04-17T17:44:24Z On IP27 systems, fill the array of node hub widget numbers early, so that all 2011-04-17T17:44:24Z miod miod@openbsd.org 2011-04-17T17:44:24Z urn:sha1:b44ee4b6cfd7f5da65b94bb87e99e89badaa9d52 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. Rename a few xbow global variable names to make them less ambiguous. 2011-04-05T14:43:10Z miod miod@openbsd.org 2011-04-05T14:43:10Z urn:sha1:6f53fca928d7bf6830218cc793f73aa448379a21 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. Normalize sentinel. Use _MACHINE_*_H_ and _<ARCH>_*_H_ properly and consitently. 2011-03-23T16:54:33Z pirofti pirofti@openbsd.org 2011-03-23T16:54:33Z urn:sha1:2fa72412907ae78c4787a4a8f888c5f0486e225c Discussed and okay drahn@. Okay deraadt@. Add more KL grovelling routines: one routine to enumerate on all nodes, 2010-04-06T19:09:44Z miod miod@openbsd.org 2010-04-06T19:09:44Z urn:sha1:a7b13b5d488f4caface8b427d2857a5cce10204f 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. Update KL structure definitions to match IP35 use of previously unused fields. 2010-03-21T13:52:03Z miod miod@openbsd.org 2010-03-21T13:52:03Z urn:sha1:40adf64c6b6c2cfdc746326825b3c1c010f9155f No functional change yet. On Origin-like systems, get glass console information (if any) from the 2010-03-07T13:42:15Z miod miod@openbsd.org 2010-03-07T13:42:15Z urn:sha1:44e8cb744dc9de40f13e62a78e7403fd8eb71b5d 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. Define struct cpu_hwinfo, to hold hardware specific information about each 2010-01-09T20:33:13Z miod miod@openbsd.org 2010-01-09T20:33:13Z urn:sha1:c301e791294a0a3d9a3aa99f9efe61347dbf5d24 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. Get serial console speed from prom, and use it instead of hardcoding 9600 bps, 2009-10-16T00:15:46Z miod miod@openbsd.org 2009-10-16T00:15:46Z urn:sha1:180f56c5ee4d88aef238528f6cc6d76927d3cf88 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). Recognize more brick types and probe fooX bricks in the same order as 2009-10-08T19:11:57Z miod miod@openbsd.org 2009-10-08T19:11:57Z urn:sha1:87c714a7d7819ed771058a7b29c21692cdadb25c foo bricks (they differ by having PCI-X bridges instead of PCI bridges but are otherwise built the same) When rebooting, pass a request to the PROM for it to skip diagnostics and 2009-07-11T19:56:02Z miod miod@openbsd.org 2009-07-11T19:56:02Z urn:sha1:9ff8c787925117ced6e623020518bce0c4c0f161 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).