challenge s boots linux
Hi,
I have successfully booted linux on a challenge S. but the problem is that the kernel wants to write his output to the console, which isn't mij serial port unfortunatelly.
Does anyone have a kernel for me from which i can continue my quest of installing linux on a challenge s ? :)
Below you'll find my kernel booting information for whom is interested.
Regards,
Richard Hartensveld
Command Monitor. Type "exit" to return to the menu.
Quoted 1 line
Quoted 1 line
boot bootp():/vmlinux
72912+9440+3024+331696+23768d+3644+5808 entry: 0x8ff9a950 Setting $netaddr to 192.168.6.31 (from server perron-null) Obtaining /vmlinux from server perron-null
PROMLIB: SGI ARCS firmware Version 1 Revision 10
PROMLIB: Total free ram 131379200 bytes (128300K,125MB)
ARCH: SGI-IP22
CPU: MIPS-R5000 FPU<MIPS-R5000FPC> ICACHE DCACHE SCACHE Loading R4000 MMU routines.
CPU revision is: 00002310
Primary instruction cache 32kb, linesize 32 bytes)
Primary data cache 32kb, linesize 32 bytes)
Linux version 2.1.100 ([email protected]) (gcc version 2.7.2) #29 Thu Ju
l 9 22:19:39 EDT 1998
MC: SGI memory controller Revision 3
R4600/R5000 SCACHE size 512K, linesize 32 bytes. calculating r4koff... 000dbd5e(900446)
zs0: console input
zs0: console I/O
Calibrating delay loop... 179.81 BogoMIPS
Memory: 125208k/261732k available (1216k kernel code, 3456k data) Swansea University Computer Society NET3.039 for Linux 2.1
NET3: Unix domain sockets 0.16 for Linux NET3.038.
Swansea University Computer Society TCP/IP for NET3.037
IP Protocols: ICMP, UDP, TCP
Checking for 'wait' instruction... available.
POSIX conformance testing by UNIFIX
Starting kswapd v 1.5
Adv: about to run setup()initialize_kbd: Keyboard reset failed, no ACK
SGI Zilog8530 serial driver version 1.00
Keyboard timeout
Keyboard timeout
tty00 at 0xbfbd9838 (irq = 21) is a Zilog8530
tty01 at 0xbfbd9830 (irq = 21) is a Zilog8530
Ramdisk driver initialized : 16 ramdisks of 4096K size
loop: registered device at major 7
WD93: Driver version 1.25 compiled on Jul 7 1998 at 16:59:57
debug_flags=0x00
wd33c93-0: chip=WD33c93B/13 no_sync=0xff no_dma=0scsi0 : SGI WD93 scsi : 1 host.
sending SDTR 0103013f0csync_xfer=2c Vendor: SGI Model: IBM
DORS-32160
Rev: W80D
Type: Direct-Access ANSI SCSI revision: 02
Rev: W80D
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 1, lun 0
sending SDTR 0103013f0csync_xfer=2c Vendor: IBM Model:
DCAS-34330
Rev: S65A
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi disk sdb at scsi0, channel 0, id 6, lun 0
scsi : detected 2 SCSI disks total.
SCSI device sda: hdwr sector= 512 bytes. Sectors= 4197405 [2049 MB] [2.0
GB]
SCSI device sdb: hdwr sector= 512 bytes. Sectors= 8467200 [4134 MB] [4.1
GB]sgiseeq.c: David S. Miller ([email protected])
eth0: SGI Seeq8003 08:00:69:0a:41:7b
Sending BOOTP requests.... OK
IP-Config: Got BOOTP answer from 192.168.6.1, my address is 192.168.6.31
Partition check:
sda: sda1 sda2 sda3 sda4
sdb: sdb1 sdb2 sdb3 sdb4
Looking up port of RPC 100003/2 on 192.168.6.1
Looking up port of RPC 100005/1 on 192.168.6.1
VFS: Mounted root (nfs filesystem).
Adv: done running setup()
Freeing unused kernel memory: 44k freed
Warning: unable to open an initial console.
hmm, I had the same problem on my Indy. I found that IRIX had stripped the major and minor numbers from the device files in the tar distribution -- the answer was to untar using Linux, not IRIX (gtar doesn't help), or to manually recreate the dev files.
Try that, and I bet it fixes it.
Signature · 8 lines
Rob Lembree Strategic Software Organization Silicon Graphics, Inc. http://www.sgi.com One Cabot Road [email protected] Hudson, MA 01749 [email protected] Phone: 978-567-2141 FAX: 978-567-2341 PGP: 1F EE F8 58 30 F1 B1 20 C5 4F 12 21 AD 0D 6B 29
Quoted 5 lines · Rob Lembree
hmm, I had the same problem on my Indy. I found that IRIX had stripped the major and minor numbers from the device files in the tar distribution -- the answer was to untar using Linux, not IRIX (gtar doesn't help), or to manually recreate the dev files.
I've untarred the hardhat distr. on my linux machine and that's the machine that plays nfs server for the
challenge.
Should the default kernel support serial terminal consoles?? My goal is to install linux onto the challenge
(which is headless) using a serial terminal connected to it, is this possible by default or should i cross-compile my own kernel on another platform?.
Regards,
Richard Hartensveld
The Netherlands
Quoted 5 lines · Richard Hartensveld
Should the default kernel support serial terminal consoles?? My goal is to install linux onto the challenge
(which is headless) using a serial terminal connected to it, is this possible by default or should i cross-compile my own kernel on another platform?.
Rich,
First, I wonder how much of the kernel will actually work on the
Challenge S; I'm told there are SCSI controller differences.
The install kernel you're using (and oh god, is it ever a bad one)
is broken in that serial console won't work. Yes, I should have looked into it way back when. There's two things you can do:
- rebuild a kernel by cross compiling in the correct options (this is reasonably easy to do)
- wait for me to have my machine moved (finally) and online and I'll whip up a modern install kernel for you and the others with serial console
Just to reiterate, yes, I *will* be fixing the install. The initrd stuff is going to have to make it in, even if it kills me. And I'll be working on porting Rawhide 1.0 too.
- Alex
Thomas Bogendoerfer
maintainerQuoted 2 lines · Alex deVries
First, I wonder how much of the kernel will actually work on the
Challenge S; I'm told there are SCSI controller differences.
looking linus.linux.sgi.com, which is AFAIK a Challenge S, it seems the Challenge has a wd33c93 and a wd33c95. The wd33c93 is what we already support. As long as the harddisk are attached to it, it should work. The wd33c95 is a rather strange chip, and from the datasheet I have here, it looks like a lot of work to write a driver for it, because besides the kernel code, you have to write sequence code for the chip, too.
Quoted 3 lines
The install kernel you're using (and oh god, is it ever a bad one)
is broken in that serial console won't work. Yes, I should have looked into it way back when.
When I did the new console code, I first made the serial console working. As far as I remember I had to do some ugly hacks, but I'll try to clean it up and check it in.
Thomas.
Signature · 3 lines
See, you not only have to be a good coder to create a system like Linux,
you have to be a sneaky bastard too ;-)
[Linus Torvalds in <[email protected]>]Quoted 11 lines · Thomas Bogendoerfer
Quoted 2 lines · Alex deVries
First, I wonder how much of the kernel will actually work on the
Challenge S; I'm told there are SCSI controller differences.looking linus.linux.sgi.com, which is AFAIK a Challenge S, it seems the Challenge has a wd33c93 and a wd33c95. The wd33c93 is what we already support. As long as the harddisk are attached to it, it should work. The wd33c95 is a rather strange chip, and from the datasheet I have here, it looks like a lot of work to write a driver for it, because besides the kernel code, you have to write sequence code for the chip, too.
Quoted 8 lines
Quoted 3 lines
The install kernel you're using (and oh god, is it ever a bad one)
is broken in that serial console won't work. Yes, I should have looked into it way back when.When I did the new console code, I first made the serial console working. As far as I remember I had to do some ugly hacks, but I'll try to clean it up and check it in.
I'm going to build the cross compiler right now and get myself involved in linux/sgi porting, i've got
a reasonable amount of sgi's overhere to test on and maybe even get linux to boot a kernel on a non-indy machine.
Richard
Quoted 2 lines · Richard Hartensveld
I'm going to build the cross compiler right now and get myself involved in linux/sgi porting, i've got
There are actually cross compiler RPMs that may save you some trouble...
Let us know how the Challenge S works!
- Alex
What is the next architecture sgi/linux will be ported to? Indigo2 r4kXZ? What is the status of the newport Xserver? What is the best place to get specific hardware info? Has anyone started on the Indy XZ graphics? Thanks!
Jeremy Welling
Detroit
Quoted 3 lines · Jeremy John Welling
What is the next architecture sgi/linux will be ported to? Indigo2 r4kXZ? What is the status of the newport Xserver? What is the best place to get specific hardware info? Has anyone started on the Indy XZ graphics?
Well i've got a indigo2 r4400 with a defective motherboard, when i'm able to get this fixed (they're quite expensive) i'll be happy to volunteer in the development.
Richard
Quoted 2 lines
What is the next architecture sgi/linux will be ported to? Indigo2 r4kXZ? What is the status of the newport Xserver? What is the best place to get
Im still learning about the internals of the Xserver and building an "fb" driver layer to glue to the accelerated stuff. I've been dicing up afb so that it generates newport_something() commands for each area after having done its clipping. Hopefully they'll approximately match the real newport 8)
Quoted 3 lines · Jeremy John Welling
What is the next architecture sgi/linux will be ported to? Indigo2 r4kXZ? What is the status of the newport Xserver? What is the best place to get specific hardware info? Has anyone started on the Indy XZ graphics?
This is an interesting question, and I for one would much rather see things like the graphics for Newport and audio working on the INdy before we start off on other things like the Indigo2.
But, i've been thinking for awhile that an Indigo2 port would be the next box to target... i suppose there's no harm in looking at both machines concurrently.
Getting docs on the Indigo2 would be quite important for a successful port, though. That would require SGI's help, and I can see them being a lot more open to it if we got the Indy completely supported first.
- Alex
Alex deVries writes:
...
Quoted 7 lines
But, i've been thinking for awhile that an Indigo2 port would be the next box to target... i suppose there's no harm in looking at both machines concurrently.
Getting docs on the Indigo2 would be quite important for a successful port, though. That would require SGI's help, and I can see them being a lot more open to it if we got the Indy completely supported first.
...
Except for the EISA slots, Indigo2 is pretty close to Indy. They run
the same IRIX kernel binary. The graphics are more of an issue, since most Indigo2 systems use something other than Newport ("XL") graphics. It might be possible for Linux to get by using the very basic microcode downloaded by the PROM for XZ and other microcoded graphics cards, but I have not had time to research the interface presented.
There is general willingness to release information, although releasing
Indigo2-specific information would require a new authorization. The main problem is finding it in a form useful to people outside SGI. (That is not true for all hardware, but it is for quite a few of our older systems.) The easiest path would be if someone inside SGI cobbled up basic sample drivers for the various graphics cards, but so far there are no volunteers. (The reason it would be the easiest path is that SGI employees can use the IRIX source as a guide.)
Quoted 9 lines · William J. Earl
Alex deVries writes:
...Quoted 7 lines
But, i've been thinking for awhile that an Indigo2 port would be the next box to target... i suppose there's no harm in looking at both machines concurrently.
Getting docs on the Indigo2 would be quite important for a successful port, though. That would require SGI's help, and I can see them being a lot more open to it if we got the Indy completely supported first.
Quoted 9 lines
...
Except for the EISA slots, Indigo2 is pretty close to Indy. They run
the same IRIX kernel binary. The graphics are more of an issue, since most Indigo2 systems use something other than Newport ("XL") graphics. It might be possible for Linux to get by using the very basic microcode downloaded by the PROM for XZ and other microcoded graphics cards, but I have not had time to research the interface presented.
If i'll get my indigo2 with extreme gfx back to work, i'll see how far i can come with a kernel that usesa serial terminal for it's output. (no gfx card needed there).
But first get my crosscompiler to work properly ;]
Richard
Cool
In reply to Alex deVriesI agree a complete working port for Indy should be the first priority. I haven't been following this port till recently. But now I'm running it on my Indy. Very cool. I haven't seen too many congrats to the core team on this list, but good job people! Thanks for the hard work.
Jeremy Welling
Quoted 21 lines · Alex deVries
Quoted 3 lines · Jeremy John Welling
What is the next architecture sgi/linux will be ported to? Indigo2 r4kXZ? What is the status of the newport Xserver? What is the best place to get specific hardware info? Has anyone started on the Indy XZ graphics?
This is an interesting question, and I for one would much rather see things like the graphics for Newport and audio working on the INdy before we start off on other things like the Indigo2.
But, i've been thinking for awhile that an Indigo2 port would be the next box to target... i suppose there's no harm in looking at both machines concurrently.
Getting docs on the Indigo2 would be quite important for a successful port, though. That would require SGI's help, and I can see them being a lot more open to it if we got the Indy completely supported first.
- Alex
Quoted 6 lines
Quoted 3 lines
First, I wonder how much of the kernel will actually work on the
Challenge S; I'm told there are SCSI controller differences.looking linus.linux.sgi.com, which is AFAIK a Challenge S, it seems the Challenge has a wd33c93 and a wd33c95.
Correct. Challenge S has the same wd33c93 SCSI chip on it that the Indy has. Additionally, it has the wd33c95 chip for more SCSI buses in place of of video and audio that's on the Indy.
--
Richard F. Masoner Digi International
[email protected] 1602 Newton Drive
http://www.cd.com/ Champaign, IL 61822 USA
Quoted 10 lines · Thomas Bogendoerfer
Quoted 2 lines · Alex deVries
First, I wonder how much of the kernel will actually work on the
Challenge S; I'm told there are SCSI controller differences.looking linus.linux.sgi.com, which is AFAIK a Challenge S, it seems the Challenge has a wd33c93 and a wd33c95. The wd33c93 is what we already support. As long as the harddisk are attached to it, it should work. The wd33c95 is a rather strange chip, and from the datasheet I have here, it looks like a lot of work to write a driver for it, because besides the kernel code, you have to write sequence code for the chip, too.
Did I missunderstand the 95's documentation - I thought we can abuse the 95 as a 93, thereby saving alot of driver work for now?
Ralf
Quoted 13 lines · [email protected] wrote:
Quoted 10 lines · Thomas Bogendoerfer
Quoted 2 lines · Alex deVries
First, I wonder how much of the kernel will actually work on the
Challenge S; I'm told there are SCSI controller differences.looking linus.linux.sgi.com, which is AFAIK a Challenge S, it seems the Challenge has a wd33c93 and a wd33c95. The wd33c93 is what we already support. As long as the harddisk are attached to it, it should work. The wd33c95 is a rather strange chip, and from the datasheet I have here, it looks like a lot of work to write a driver for it, because besides the kernel code, you have to write sequence code for the chip, too.
Quoted 3 lines
Did I missunderstand the 95's documentation - I thought we can abuse the 95 as a 93, thereby saving alot of driver work for now?
My experience is that the wd93 driver doens't work with the wd95 controller, maybe someone else hassuccessfully tried this?
Richard
Quoted 6 lines · Richard Hartensveld
Quoted 3 lines
Did I missunderstand the 95's documentation - I thought we can abuse the 95 as a 93, thereby saving alot of driver work for now?
My experience is that the wd93 driver doens't work with the wd95 controller, maybe someone else hassuccessfully tried this?
It's not supposed to work without any changes at all.
Ralf
Thomas Bogendoerfer
maintainerQuoted 7 lines · On Thu, Sep 24, 1998 at 01:59:38AM +0200, [email protected] wrote:
Quoted 4 lines
As long as the harddisk are attached to it, it should work. The wd33c95 is a rather strange chip, and from the datasheet I have here, it looks like a lot of work to write a driver for it, because besides the kernel code, you have to write sequence code for the chip, too.
Did I missunderstand the 95's documentation - I thought we can abuse the 95 as a 93, thereby saving alot of driver work for now?
The documentation isn't really clear about that, but I believe you need sequencer code to make the 95 acting like a 93. And I couldn't find such a thing, yet.
Thomas.
Signature · 3 lines
See, you not only have to be a good coder to create a system like Linux,
you have to be a sneaky bastard too ;-)
[Linus Torvalds in <[email protected]>]Quoted 6 lines · Rob Lembree
hmm, I had the same problem on my Indy. I found that IRIX had stripped the major and minor numbers from the device files in the tar distribution -- the answer was to untar using Linux, not IRIX (gtar doesn't help), or to manually recreate the dev files.
Try that, and I bet it fixes it.
You can also just recreate the block devices from within Irix.
- Alex
Quoted 2 lines
Warning: unable to open an initial console.
I got this message for (it seemed) a variety of reasons. One was that it couldn't find the nfs server, but in the end it was that I was booting off an O2 and the permissions on the dev/ directory were all screwed from SGIs tar. Re-building dev to match a x86/Linux machine fixed it.
So it's a long shot, but check that your dev directory in the nfs mounted distribution looks like:
crw------- 1 root root 4, 0 Sep 13 20:05 console crw-rw-rw- 1 root root 1, 3 Jan 1 1980 null brw-r----- 1 root disk 1, 1 Jan 1 1980 ram crw------- 1 root root 4, 0 Sep 3 1995 systty crw------- 1 root root 4, 1 Sep 13 20:05 tty1 crw------- 1 root root 4, 2 Sep 13 20:05 tty2 crw------- 1 root root 4, 3 Sep 13 20:05 tty3 crw------- 1 root root 4, 4 Sep 13 20:05 tty4 crw------- 1 root root 4, 5 Sep 13 20:05 tty5
+
There's not a line that goes here that + Robin Humble
rhymes with anything, anything, / [email protected]
anything. - Camper van Beethoven + http://www.maths.monash.edu.au/~rjh/