Re: Booting on a Powerbook6,8 (was Re: Installing 8.0 on a Powerbook6,8)

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Fri, Feb 12, 2021 at 09:53:44 -0800, Jason Thorpe wrote:

> > On Mar 23, 2019, at 5:40 PM, Jason Thorpe <thorpej%me.com@localhost> wrote:
> > 
> >> On Mar 20, 2019, at 1:57 AM, Valery Ushakov <uwe%stderr.spb.ru@localhost> wrote:
> >> 
> >> On Wed, Mar 20, 2019 at 08:24:41 +0100, Martin Husemann wrote:
> >> 
> >>> On Wed, Mar 20, 2019 at 01:24:59AM -0400, Michael wrote:
> >>>> First, did you try -current? uwe@ fixed a bug in ofwboot which caused
> >>>> this kind of symptoms on Minis.
> >>> 
> >>> Can you please file a pullup request for that? I only see the fix for 
> >>> port-macppc/53727.
> >> 
> >> This is probably http://gnats.netbsd.org/44895 though I did NOT enable
> >> the fix.
> > 
> > I built ofwboot locally with the change.  I have to do the dance
> > do the "1 1f lshift not dec!" dance to get past the decrement
> > exception, but I still end up with "Invalid memory access at
> > %SRR0: 00000000 %SRR1: 00083030".  Doesn't matter if I load
> > ofwboot.elf or ofwboot.xcf.
> 
> My Powerbook6,8 is still struggling.  But it's been easier to make
> progress with it since I managed to dig out an old Leopard install
> DVD sitting in a long-forgotten box so I can at least boot
> *something* on it to move files around.

Just a remidner that one can also try to netboot the thing by
configuring isc dhcpd to speak a bit of Apple's BSDP:

  http://mail-index.netbsd.org/port-macppc/2018/06/11/msg002525.html
  http://mail-index.netbsd.org/port-macppc/2018/06/20/msg002535.html


> Using a bone-stock 9.1 boot loader and a -current kernel, I've made
> some progress tracking the problem down:
> 
> - Our ofwboot.elf seems to be fine, in that I was able to use it to
>   boot an OpenBSD 6.8 kernel on this machine.  I suspect ofwboot.xcf
>   would work just fine, too.

I wouldn't be so sure.  Too lazy to find the notes and the post
written based on them, but at one point I had ofwboot.xcf and
ofwboot.elf with exactly the same section contents and elf one worked
and xcf one didn't (that was mostly an exercise in pednatry, the usual
difference between them is the xcoff whatever that is normally at the
beginning of the text so shifts everything two words relative to the
elf version of .text)


> - I have determined that we do make it into the kernel.  It's
>   blowing up in ofw_machdep.c:mem_regions(), called from
>   oea_batinit(), called from ofwoea_batinit(), called from
>   ofwoea_initppc(), called from initppc().
> 
> - Specifically, it blows up on the call to OF_finddevice("/memory").
>   But this is after a successful call to OF_finddevice("/") and two
>   successful calls to OF_getprop() (to get #address-cells and
>   #size-cells).
>
> The /memory node does exist in OFW, and reflects two memory regions:

This is probably not the specific node, see e.g. Joerg's mail where if
was failing ofr him in a different OF_finddevice:

  http://mail-index.netbsd.org/port-macppc/2019/10/30/msg002659.html


So between the weird xcf vs elf issue, the libsa allocator issue, and
the observed OF_finddevice issues I suspect that something goes awry
at some point when we interact with OFW and all of the above are just
different manifestations of the same underlying problem.  But my
ppc-fu is weak, apple's ofw is actively hostile to inspection as it
has the forth headers stripped, and I don't have a serial console on
my test mini g4, so it was quite awkward to work on this even when me
and the mini where in the same epsilon neighborhood (and it's
impossible now when I'm not).

-uwe