Re: All PPC ports broken since 5.99.61

[Michael <macallan%netbsd.org@localhost>]

Hello,

On Thu, 9 Feb 2012 14:06:42 -0800
Matt Thomas <matt%3am-software.com@localhost> wrote:

> On Feb 9, 2012, at 1:44 PM, Michael wrote:
> 
> > Hello,
> > 
> > On Thu, 09 Feb 2012 22:07:24 +0100
> > Frank Wille <frank%phoenix.owl.de@localhost> wrote:
> > 
> >> Michael wrote:
> >> 
> >>>> The crash occurs very early in the openfirmware() function,
> >>>> src/sys/arch/powerpc/oea/ofw_subr.S, line 125. So it has probably
> >>>> nothing to do with the recent kmem changes...?
> >>>> 
> >>>> The code didn't change. No idea why it is happening now, and why it
> >>>> is not happening on ofppc, for example.
> >>> 
> >>> Apple OF is always a little special. In several different ways
> >>> depending on the version. I downgraded trap_subr.S to 1.72 and
> >>> oea_machdep.c to 1.60 which made the kernel boot again, [...]
> >> 
> >> Hmm... that's the new code for supporting up to 8 BATs and the extended
> >> block size (>256MB). My iBook G4 has a 7447A, so it would take advantage of
> >> it, while my ofppc machine has a 750CXe with just 4 BATs (and works).
> > 
> > I've seen this on both my iBook G4 ( 7455 CPU ) and the Pismo ( plain old 
> > 750 )
> > The bus_space issue I've seen was related after all - finding a BAT mapping 
> > failed where it shouldn't.
> 
> I fixed that.
> 
> >> My guess is that the openfirmware() call in ofw_subr.S needs to save and
> >> restore all 8 BATs now. It still only uses 4, which might crash OFW...
> > 
> > Worth a shot I guess.
> 
> Since OFW doesn't turn on HID0 XBSEN or HIGH_BAT_EN that seems unlikely.

True, and it also happens on CPUs that don't have high BATs, like the 750 
mentioned above. So whatever confuses OF happens in either case.

have fun
Michael