> OK. I'm really upset now. 188.8.131.52 told me that I had a BogoMIPS
> rating of 50.03. Now, I go and boot 1.3.62 and I have only 49.87.
> Who, exactly, is going to pick up the over .16 BogoMIP? Tell me that,
> why don't you? BogoMIPS don't grow on tress, you know. If I wanted
> only 49.87 BogoMIPS, I'd be running NT...
> :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
I suggest to replace the BogoMIPS benchmark in the kernel by an assignment.
It's more efficient, anyway ;-)
> Or, in other words, 1.3.62 seems to work for me, for a suitible
> definition of work. Here's the boot sequence. Seems like a thing or
> two is amiss:
> Launching Kernel... (bold font, rest lighter)
> Console: 0 point font, 0 scans
> Console: colour VGA+ 80x50, 1 virtual console (max 63)
> Calibrating delay loop.. ok - 49.87 BogoMIPS
> Memory: 31280k/32768k available (424k kernel code, 964k data)
> Swansea University Computer Society NET3.033 for Linux 1.3.50
> NET3: Unix domain sockets 0.10 BETA for Linux NET3.033.
> Checking for 'wait' instruction... unavailable.
Correct for R4000.
> Linux version 1.3.62 (firstname.lastname@example.org) (gcc version 2.7.2) #29 Tue Feb
> 13 22:36:40 MST 1996
> initialize_kbd: reset kbd failed, no ACK.
> Floppy drive(s): fd0 is 1.44M
> Started kswapd v 184.108.40.206
> floppy0: no floppy controllers found
> VFS: Insert root floppy and press ENTER
> Well, as you might have guessed from the above messages, it hangs with
> the blinking underscore. The keyboard is dead. But after a time, the
> screen saver comes on :-) I had to transcribe the above quickly...
> This leads me to some questions...
> 1) Why can't it find the keyboard? Another interrupt thing?
> I rebooted a second time (to see if I could find my missing
> bogomips) and found that I got a *flood* of keyboard error
> 2) Why did it find a floopy (fd0) and then say it couldn't
> find a controller?
It kind a assumes the existence of a floppy.
The kernel really tries to detect the type of floppy controller this
might fail just as the keyboard stuff if either your ports aren't
accessible or interrupts don't work.
> 3) Shouldn't I have a WAIT instruction? Hmmm... Not in the
> MUM, so maybe not.
No, R4000/R4400 don't have one. Most other R4xx0 like the R4200, R4300i,
R4600, R4650, R4700 have a wait insn.
> Anyway, this is with an almost a bog standard 1.3.62 distribution.
> This is good news, I think. The diffs between what I built and 1.3.62
> are about 262 lines long. The diffs are in the ./Makefile (gmake and
> awk rather than make and gawk), the load address chanage that I sent a
> while ago to this list in arch/mips/Makefile, a couple of lines of
> debug that incremented the upper righthand corner of the screen on
> each interrupt in arch/mips/kernel/rpc44.S, spurious_interrupt removed
> from rpc44.S and tyne.S, a horrible kludge in init/main.c in
> calibrate_delay (outb(0,0x21)), a hack to scripts/Config to use a
> local bash and a horrible video kludge vga.c (which is replicated
> code). Time to take my kludges out one at a time and see if that
> helps my situation. Anyway, this is likely trivia for most people,
> but good places to look if you are adding a new machine type.
> Why does it now work? Obviously, it is because Ralf is a God. It may
Think I'll have to print out this mail and stick it to the wall :->>>
If I only could resurrect my car's electronic ignition that easily ...
> have also been faulty hardware on my end. I noticed that the system
> BIOS thought LPT lived at IRQ 0 for some reasoon. Changed that to 7,
> but the old kernels wouldn't boot right, the "second" interrupt
> problem that I talked about before, but the new ones booted as above.
> I now have a new slew of problems to solve, plus some interesting
> integration issues to solve that Ralf raised. Plus all the other cool
> stuff I wanted to work on :-).
> I'm much happier now about my MIPS box...
Congratulations - well done!
After some learning last night I tried to compile sendspam^H^H^H^Hmail
for Linux/MIPS and voila it worked almost out of the box. I just had
to add the two missing syscalls statfs and fstatfs to glibc.