Subject: Re: diskless boot fails on Super COMPstation 20S
To: None <msanders@celestar.com, tech@openbsd.org>
From: George Robbins <grr@shandakor.tharsis.com>
List: port-sparc
Date: 04/07/1997 22:00:01
> Subject: diskless boot fails on Super COMPstation 20S
> Date: Mon, 07 Apr 1997 16:57:52 +0000
> From: "Michael K. Sanders" <msanders@celestar.com>
> 
> After failing to get NetBSD to boot on a Tatung Super COMPstation 20S,
> I decided to try OpenBSD, and didn't have much more success. NetBSD
> gave me a 'panic: bremfree: lost tail' after the BOOTPARAM response
> for  mounting root and swap. OpenBSD isn't even getting that far. With
> the OpenBSD 2.0 bsd-generic kernel, I get:
> 
> mainbus0 (root): TWS,SuperCOMPstation-20S
> cpu0 at mainbus0: TI,TMS390Z50 @ 50MHz, on-chip FPU
> cache enabledl 20k instruction (64 b/l), 6k data (32 b/l)
> Data modified on freelist: word 0 of object 0xf867a780 size 60 previous type free (0x0 != 0xdeadbeef)
	*** deadbeef is either a hex memory initialization constant to
		let you know you're reading something bogus...
> obio0 at obio0
	*** this should be obio0 at mainbus0 !!
> Data modified on freelist: word 0 of object 0xf8151978 size 40 previous type ??? (0xf867z780 != 0xdeadbeef)
> data fault: pc=f802457c addr=f8668b94 sfsr=326<FAV>
> panic: kernel fault

As a guess I'd say there's something wrong with the way that the Boot
ROM monitor on this system is passsing the amount of memory available,
the addresses, the initial mapping or sharing between the monitor and
the system.  You left off the first few lines, but check how rational
the sizing information that it types out is.

Another possibility is that they've modified the Boot ROM or on-board
I/O sufficiently that the kernel isn't finding the keywords that it
expects in the autoconfiguration process.  On the sparc, much of that
consists of interrogating a "configuration directory" sort of thing in
in the monitor for specific keyword/values pairs...

Both NetBSD and OpenBSD share essentially the same code-base as far as
the Sparc machine specific stuff, so it's no surprise that they are both
unhappy.  I'd suggest that you try the kernel from either the most recent
OpenBSD snapshot release or maybe that NetBSD 1.2a release to get something
half-way current, it probably still won't work but might give a better
clue as to what's happening.  The support for the Sparc 4m architecture
systems is still new and not well tested across a broad range of systems
in the SS 10/20 class.  On a given system it may work well enough to be
useful or fail to boot, let alone run reliably.

						George