Hi,
On Tuesday, April 24, 2012 23:58 CEST, Miod Vallat <m...@online.fr> wrote:
> Hello,
>
> I am happy to announce that the current snapshots of OpenBSD support
> the IP20, IP22 and IP24 SGI systems. In other words:
>
> - R4000 and R4400 Indigo (IP20)
This is great! Since its Friday afternoon, I went on as proposed, removing the
dust from my Iris Indigo:
>> hinv
System: IP20
Processor: R4000 50 Mhz, with FPU
Primary I-cache size: 8 Kbytes
Primary D-cache size: 8 Kbytes
Secondary cache size: 1024 Kbytes
Memory size: 80 Mbytes
Graphics: GR2-Elan
SCSI Disk: scsi(0)disk(1)
SCSI Disk: scsi(0)disk(2)
SCSI Disk: Controller 0, ID 3, removable media
>> version
PROM Monitor SGI Version 4.0.5G Rev B IP20, Nov 10, 1992 (BE)
>> printenv
OSLoader=boot
OSLoadFilename=/bsd
AutoLoad=Yes
TimeZone=PST8PDT
console=d
diskless=0
dbaud=9600
volume=80
sgilogo=y
netaddr=10.0.0.31
eaddr=08:00:69:06:cc:6f
ConsoleOut=serial(0)
ConsoleIn=serial(0)
cpufreq=50
SystemPartition=scsi(0)disk(1)rdisk(0)partition(8)
OSLoadPartition=scsi(0)disk(1)rdisk(0)partition(0)
So reading the INSTALL.sgi file, I have to boot the bsd.rd.IP22 kernel, after
the bootecoff.
Then I got this far, until the box froze:
>> bootp()bootecoff bootp()bsd.rd.IP22
Setting $netaddr to 10.0.0.31 (from server )
Obtaining bootecoff from server
Cannot load bootp()bootecoff.
Unable to execute bootp()bootecoff
>> bootp()bootecoff bootp()bsd.rd.IP22
Setting $netaddr to 10.0.0.31 (from server )
Obtaining bootecoff from server
38720+208+2080 entry: 0x880020f0
Starting receive DMA in eput()
OpenBSD/sgi-IP20 ARCBios boot version 1.1
arg 0: bootp()bootecoff
arg 1: bootp()bsd.rd.IP22
arg 2: ConsoleIn=serial(0)
arg 3: ConsoleOut=serial(0)
arg 4: SystemPartition=scsi(0)disk(1)rdisk(0)partition(8)
arg 5: OSLoader=boot
arg 6: OSLoadPartition=scsi(0)disk(1)rdisk(0)partition(0)
arg 7: OSLoadFilename=/bsd
Boot: bootp()bsd.rd.IP22
Setting $netaddr to 10.0.0.31 (from server )
Obtaining bsd.rd.IP22 from server
Starting receive DMA in eput()
Setting $netaddr to 10.0.0.31 (from server )
Obtaining bsd.rd.IP22 from server
6938992+904080 [91Starting receive DMA in eput()
Setting $netaddr to 10.0.0.31 (from server )
Obtaining bsd.rd.IP22 from server
+122640+69813]=0x7aa068
Starting receive DMA in eput()
ARCS32 Firmware Version 1.10
Found SGI-IP20, setting up.
Initial setup done, switching console.
[ using 193384 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2012 OpenBSD. All rights reserved. http://www.OpenBSD.org
uvm_km_kmem_grow: grown to 0xc000000005000000
OpenBSD 5.1-current (RAMDISK-IP22) #14: Thu Apr 26 07:12:21 MDT 2012
dera...@sgi.openbsd.org:/sys/arch/sgi/compile/RAMDISK-IP22
real mem = 83886080 (80MB)
rsvd mem = 802816 (1MB)
avail mem = 74039296 (70MB)
mainbus0 at root: Indigo
cpu0 at mainbus0: MIPS R4000 CPU rev 2.2 100 MHz, R4010 FPC rev 0.0
cpu0: cache L1-I 8KB D 8KB direct, L2 1024KB direct
clock0 at mainbus0: ticker on int5 using count register
int0 at mainbus0 addr 0x1fb801c0
imc0 at mainbus0: revision 3
gio0 at imc0
grtwo0 at gio0 addr 0x1f000000: GR2-Elan
grtwo0: device has not been setup by firmware!
light0 at gio0 addr 0x1f3f0000
I did let it hanging around here for a couple of minutes, with the hope
it might go on, but nothing happens. Tried that two times, to make
sure its kind of reproducible.
cheers,
Sebastian
> - R4000, R4400 and R4600 Indigo2 and Challenge M (IP22)
> - all Indy and Challenge S (IP24)
>
> I know that several (many?) of you had been asking in the past, and I
> had always intended to work on this (didn't I get an R4000 Indigo, 12
> years ago, for this purpose?). Wait no more! This has eventually
> happened.
>
> This work was helped by the existing NetBSD work, which provided basic
> device support (serial, Ethernet and SCSI). Of course running these
> systems in 64-bit mode opened quite a large Pandora box-of-problems, but
> we have reached a point where the system is running stably and able to
> rebuild itself. Oh, did I mention that I stumbled onto a few hardware
> bugs, such as extremely important device registers not always returning
> their value when being read?
>
> Anyways, what this really means is that you can wipe the dust off your
> system, plug it back, boot the OpenBSD installer and get a working
> system in less than half an hour (unless there really is a lot of dust
> to clean first).
>
>
> There are still a few rough edges, though.
>
>
> What works:
>
> - onboard serial, keyboard/mouse, SCSI and Ethernet controllers. Tested
> and confirmed to work.
>
> - all frame buffers are supposed to work, at least in console mode.
> However, only Newport (XL/XGE, found on Indy and Indigo2) and
> Express/Ultra (XZ/Elan/Extreme, found on Indigo, Indy and Indigo2)
> have been tested. The Light/Entry/Starter graphics on Indigo, as well
> as Impact on Indigo2, ought to work out of the box, but could not be
> tested (donations welcome). There is no X11 server for any of these
> frame buffers yet.
>
> - GIO E++ boards work. GIO32 SCSI boards ought to work too, but could
> not be tested.
>
> - the Challenge S second Ethernet interface (on the IO+ mezzanine)
> ought to work.
>
>
> What doesn't work (yet):
>
> - the extra SCSI controllers (WD33C95) on the Challenge S IO+ mezzanine
> are not supported (anyone got a Challenge S to spare?)
>
> - Fast Ethernet GIO options (Phobos G130 and G160, as well as `Set
> Engineering' Fast Ethernet are not supported. There is code to borrow
> from NetBSD, but it's not really an option without access to the
> hardware.
>
> - on-board audio on Indigo (hdsp) and Indy/Indigo2 (haltwo).
>
> - on-board parallel port (honestly, I couldn't care less).
>
> - L2 cache on R4600SC and R5000SC processor modules. I am working on
> this, but need to introduce a few interfaces first, and this takes
> time checking I do not break other systems. Coming soon.
>
>
> What sort of works:
>
> - the EISA bus on the Indigo2 attaches and cards get detected. However I
> have only been able to test it with 3Com ep(4) boards; the 10MBit/s
> models have abysmal performance, and the 100MBit/s 3C597 (or Phobos
> G100) doesn't seem to interrupt. Your mileage may vary.
>
>
> Snapshots are available from OpenBSD FTP mirrors near you; do not
> hesistate and play with them! However, please, please, pretty please, do
> not expose an R4000 or R4400 based system to the internet. These
> processors suffer from unfixed errata which can be used by local users
> to gain supervisor privileges. On these systems, you can't trust your
> local users - at all. As in, never give me a shell access to the system
> or I'll root it without even thinking. R4600 and R5000 based systems do
> not suffer from such problems.
>
> If you have an early R4000 processor (either an 1.x or 2.x version),
> other bugs will prevent it from running stably (the so-called ``end of
> page'' bugs). The system will run multiuser, but from time to time, some
> processes will misbehave. My own Indigo has a revision 2.2 R4000, so I
> am experiencing these issues first hand (and this system is currently
> not able to rebuild itself because of these processor bugs). However the
> processor errata documentation is public, and I am working on designing
> a good way to circumvent them (and it's no easy task, especially with
> the goal of not affecting the performance of other processors).
>
>
> But enough said.
>
>
> The real reason for this work was to get good device support, in order
> to be able to port OpenBSD to the Power Indigo2 systems: both the R8000
> flavour (IP26) and the R10000 flavour (IP28). Those systems come with a
> specific memory controller which needs some care in order to operate
> properly; and of course the R8000 processor is an odd beast which, to
> this day, is not supported by any free operating system.
>
> I would like to change this state of things, and have IP26 and IP28
> systems be able to run OpenBSD, if only for the sake of it and the joy
> of getting my code to run on formerly unsupported hardware.
> Unfortunately, I do not own any such system - neither an R8000 Indigo2
> nor an R10000 Indigo2. If you know of such a system collecting dust,
> which owner would not mind parting of, please let me know. I'm sure we
> can arrange something.
>
>
> Miod
>
>
> PS: If you only have R4k ``PC'' processors, that is, without a secondary
> cache... then do yourself a favour and don't try to compile anything on
> them... these small caches get blown a few orders of magnitude by gcc 4
> when compiling even the smallest program. This is very hard on the
> R4000PC systems, which only have 2x8KB cache (I have such a system, it's
> perfectly stable but glacial as soon as you are compiling anything on
> it). R4400PC, R4600PC will be a bit more bearable because their cache is
> twice larger.
