| Age | Commit message (Collapse) | Author |
|---|
|
basically an IP22 system (R4000 Indigo2) with the ECC memory board of IP28,
and a so-called ``streaming'' L2 cache.
IP26 kernels currently boot single-user, but don't live long; I am suspecting
a bug in the tcc cache routines, but am currently not able to find it (come
to think of it, my understanding of how this cache works could be wrong, and
of course there is no documentation for it but what can be gathered from
IRIX' <sys/IP26.h> comments and defines).
Hopefully this situation will improve in the near future; in the meantime I
am commiting this as `work in progress' to make sure this code doesn't get
lost.
|
|
|
|
|
|
updated gcc and ld to understand the new -nopie flag.
ok deraadt@
|
|
cleaned up later.
ok deraadt@
|
|
interrupt on Indy; do not use it on such systems. Then, bring back a clock0 at
mainbus attachment to IP22 kernels, and attach it late in the autoconf process
if no other device has claimed the clock yet.
This means R4000 and R4400 based Indy may experience the lost clock interrupt
processor errata again, until a better way to skirt it is found.
|
|
counter register close to a trigger of the counter interrupt, may cause the
interrupt not to be generated. This makes it a bad idea to use the internal
counter both for the scheduling clock and for delay().
Therefore, on IP22 systems (and IP28 because it makes my life easier), use
one of the two 8254 timers connected to the onboard interrupt controller as
the scheduling clock source.
Adapted from NetBSD.
|
|
onboard devices need only attach to hpc0 instead of hpc?.
While there, remove hpc1 and hpc2 attachment from IP28 configurations, as these
can not exist on Indigo2 systems.
|
|
ECC checking disabled, which allows the existing Indigo2 drivers to run
unmodified.
|
|
IP22 family. This is just the bridge so far, as the underlying pci drivers
will need some changes to work (dc(4) does not work correctly yet, and tl(4)
needs to be bus_dma'ified).
|
|
IP22 kernels. Oops.
|
|
with -j2.
|
|
bus-specific attachment; impactreg.h and impactvar.h move from sgi/xbow/ to
sgi/dev/.
Teach the generic impact code how to code with pre-ImpactSR boards, which have
a slightly different register layout (information obtained from Peter Fuerst's
Linux IP28 patches).
Add an impact@gio attachment (unfortunately untested, no Impact GIO boards
here). All Indigo 2 graphics options should be supported now (assuming the
Extreme/Ultra will actually work with grtwo(4) out of the box).
Tested not to disturb operation on IP30.
** ATTENTION! If you are building IP27 or IP30 kernels, be sure to rm impact.d
** before building a new kernel.
|
|
NetBSD driver, with the infinite loops removed, the negative heights fixed,
and the explicit delay() calls removed. And support for fonts wider than
8 pixels.
|
|
From NetBSD.
|
|
only. Ported from NetBSD, not tested due to lack of hardware, hopefully it
will be working as intended (fingers crossed)
|
|
where applicable (i.e. Indy only).
|
|
(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).
|
|
|
|
cache is still not supported yet (needs extra code being worked on, as does
the R5000SC Indy).
|
|
being configured and we'll see which boards need care. (Only ep(4) is known
to work so far, but I am waiting for review and approval of the changes
required to make it work on sgi). Anyone with a working ahb(4) EISA board to
spare?
|
|
the PROM data area.
|
|
(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).
|
|
files to operate); reported to work by Graeme Neilson (firstname, lolux dot net)
on sgi@
|
|
by krw and myself.
|
|
|
|
spikes in other developers by making it so that removal of a .d
file without removing the corresponding object will result in the
latter being treated as out of date.
ok beck@ art@ drahn@
|
|
ok beck deraadt
|
|
scsi?" rule, similar to how ethernet PHY drivers attach at mii.
Discussed on icb.
|
|
ATAPI devices. atapiscsi(4) is only for handling ATAPI devices on an
ATA bus, so umass(4) shouldn't care about it.
ok krw@, dlg@; no objections from deraadt@
|
|
my tree for a very long while, no reason not to allow people with such
devices to have fun (and maybe experience new bugs) with them on sgi.
Also, clean up some comments and explicitely mention which `option' lines are
actually mandatory (ARCBIOS, TGT_xxx, etc).
|
|
using the -MD option to cc, with -MP, -MT, and -MF where needed, converting
"make depend" to a no-op. This increases parallelism for those using "make -j"
and keeps the dependencies up to date with each compilation automatically.
sparc and vax users will need to rebuild gcc with support for the
-M[PTF] options before config'ing with this diff.
|
|
in some grief. Split this out.
From Vladimir Kirillov
|
|
early MD and late MI files must be split up so that vers.o can sneak
between. Issue spotted by bluhm, repair discussed with miod
|
|
having it linked last is bad (on at least i386 and amd64) because the lapic
is mapped over the start of the data segment -- savecore(8) then reads the
version string for a fixed buffer space, and reads into the lapic area
causing unintended side-effects (at least on Intel X5570 and X5680)
found by pedro, discussed with kettenis and mpf and miod
|
|
until possible removal, if indeed this causes no regression for scanner users.
|
|
|
|
ok deraadt@, miod@
|
|
noticed by brad
|
|
General huzzahs.
"go for it" deraadt@
|
|
suggestion of more devices and ok tedu@; ok krw@
|
|
prefer binutils-compatible options in STRIPFLAGS (now that our non-binutils
strip(1) can handle them too)
ok drahn; miod kettenis (for parts)
|
|
to genassym.sh
ok deraadt
|
|
the differences between these files. You will need a newer config(8) binary
to be able to build kernels.
ok kettenis miod
|
|
result: kernels built without 'make depend'-provided information
(ie. the .depend file) are more likely to have their *.[Ss] file
compilations track changes to *.h files.
The "*.o: assym.h" dependencies listed are gotten from reading the
.depend output --- from the biggest kernel possible (ie. GENERIC.MP).
When an architecture changes in a substantial way (new .[sS] files),
the list should be updated in the prettiest way possible.
This is not encouraging people to skip 'make depend'; other issues are
not resolved and may be solved later with a change guenther is working
on. You can still screwed really easily, so continue running make
depend as config tells you.
Idea from a discussion with drahn
ok drahn, kettenis likes the idea too
|
|
idea that came out of discussion with drahn
|
|
delete the archaic links: target which is easily misused
handle special .[sS] files in a portable way
|
|
|
|
|
|
ok various people, tested by fewer people, tested by me on 15.
|
