OK, well I've tried everything I can think of to get a GENERIC kernel
with "options DDB" added to it to boot but I've had no luck at all yet.

I've built kernels on the host in question.  I've built kernels on the
cross-build machine that was used to build working, plain, GENERIC
kernels.  I've re-built kernels after uncommenting "options DDB" in the
GENERIC config that was just used to build a working kernel (re-running
config even with just adding DDB causes almost all .o's to be rebuilt,
but I thought I'd try anyway :-).  I've tried with just "options DDB",
as well as with the defaults for all the other related options
uncommented (as I reported previously).

Here are a couple of the example failures.  Note that it seems every
type of exception or alignment error is possible:

Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@1,0  File and args: netbsd
>> NetBSD/sparc Secondary Boot, Revision 1.12
>> (woods@proven, Tue May 27 17:35:26 EDT 2003)
Booting netbsd
2974912+109204+284944 [189600+144611Instruction Access Exception
Type  help  for more information
<#0> ok 

Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@1,0  File and args: netbsd
>> NetBSD/sparc Secondary Boot, Revision 1.12
>> (woods@proven, Tue May 27 17:35:26 EDT 2003)
Booting netbsd
2925248+106924+263080 [186720+142912Memory Address not Aligned
Type  help  for more information
<#0> ok 

Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@1,0  File and args: netbsd
>> NetBSD/sparc Secondary Boot, Revision 1.12
>> (woods@proven, Tue May 27 17:35:26 EDT 2003)
Booting netbsd
2921584+106908+262976 [186976+143158Data Access Exception
Type  help  for more information
<#0> ok 

I'm not sure why the text sizes are so different, though the first one
probably was not compiled with -O2.  Other than that the only difference
should have been with which related DDB options were uncommented.


The only thing I haven't done is prove I can build a working GENERIC
kernel using a self-hosted build, so I'm going to start that build
running now....  I don't know what that will prove w.r.t. DDB failing,
other than that my first attempt to build a GENERIC+DDB kernel wasn't
screwed up just because of toolchain problems on the target host, but
I'll try anyway.

If that doesn't reveal any new information then maybe I'll try a kernel
tuned specifically for the hardware (except maybe MULTIPROCESSOR).  Or
maybe I should try booting on the other processor -- or pulling one out?
I suppose I should also read through the boot loader code again -- it's
been a long time since I looked at the sparc boot loader.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>