On Fri, 28 Jul 100, Maki wrote:

>   First, than you and others for the efforts on the Magnum.  I finally had a chance to test it on my Bull DPX/Prostation M-20 and had a few comments.  My machine BTW is a rebadged Magnum 3000.

Excellent!  Thanks for the feedback Maki

> 
>   I have 64Mb of ram(4Mx16), but it looks like only 32 were detected.

The memory tests have been restricted to 32MB as I was unsure what would
happen to the memory aliasing with 4MB SIMM's in the system.  With luck
the next kernel will detect it correctly now I have a better idea what is
happening in the physical address space.

>   I have my floppy disconnected, and I get the floppy Interrupt repeating every time I boot.

Sorry about that.  On my system it only occurs from time to time, and if I
reset the system it behaves itself again.   Going by the datasheet I have
attempted to reset the device but there must also be another condition
that I'm not handling correctly.

What I have done recently is mask the interrupt after if occurs just in
case I couldn't service the floppy controllers reason for generating the
interrupt.

Because of the Mk48T02 failure, your 'bootmode' environment variable is
probably set to 'e' (for error).  This means the hardware isn't checked on
powerup or reset - for that reason the FDC may not be reset 100% by the
firmware.

What I suggest you try is 'setenv bootmode m' and reset the machine.  You
will see the poweron diags run and get an error.  Along the way the FDC
will be tested and (hopefully) reset.  Boot your kernel at that stage to
see if the floppy interrupts go away.

>   The NVRAM M48T02 in my machine was dead, so I removed it, and the machine didn't boot.  With my dead NVRAM, my ethernet hardware address is set to 00:00:00:00:00:00 and that seems to be a problem with my bootpd.  I ordered a new NVRAM chip, and it should be here next week, but does anyone know how to set the MAC address?  I have RiscOS running on that machine if that helps.  I booted netbsd using sash.

I have 2 machines in a similar situation.  Unfortunately it isn't as easy
to set as the NVRAM is broken into 2 sections.  The first 1024 bytes are
READ ONLY and enforced by hardware, The remaining 1015 bytes (leaving room 
for the RTC registers) are R/W Access.   Because of the hardware write
protect on the first 1k of memory you cannot reprogram the chip from the
monitor as Soren does on the sgimips platforms.

I tried breifly to locate a datasheet on the device and had no luck (only 
tried for 10 minutes).  I beleive it is pin equiv to a 6116 CMOS RAM chip
with a RTC in the last few address locations.   What I plan to do is lift
one of the address lines (A11?) and tie it high (most logic floats high
anyway, so we may not need a 5cent resistor and a soldering iron)
We then reprogram the lower 1k region as in the upper 1k region's address
space.
There are a few problems with that as the firmware uses the upper address
space for the environment settings, and they might get in the way somehow.

If all else fails we have to hardcode the MAC Address into the kernel -
that goes against every single rule in networking and IU would be very
reluctant to do that.

If you have access to anything that takes a 6116 then you will hopefully
be able to reprogram it on that machine.   I would like to see the
datasheet first to ensure it is in fact able to be done that way.

More info on a procedure will follow when I have reprogrammed mine.

>   I'm looking forward to getting the userland stuff.

I now have the kernel running NetBSD-current reliably as the userland has
been compiling non stop for the last 24 hours as a regression test.

There is a little housekeeping required on the code before it can hit the
tree, but I expect it to be only a week away.

Wayne
--
  _____	   	Wayne Knowles,  Systems Manager
 / o   \/   	National Institute of Water & Atmospheric Research Ltd
 \/  v /\   	P.O. Box 14-901 Kilbirnie, Wellington, NEW ZEALAND
  `---'     	Email:   w.knowles@niwa.cri.nz