NetBSD Problem Report #44895
From jmmv+mini.jmmv@julipedia.org Fri Apr 22 14:49:19 2011
Return-Path: <jmmv+mini.jmmv@julipedia.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by www.NetBSD.org (Postfix) with ESMTP id D642863B842
for <gnats-bugs@gnats.netbsd.org>; Fri, 22 Apr 2011 14:49:19 +0000 (UTC)
Message-Id: <20110422144912.1DF2262F33C@mini.julipedia.org>
Date: Fri, 22 Apr 2011 15:49:11 +0100 (IST)
From: jmmv+mini.jmmv@julipedia.org
Reply-To: jmmv+mini.jmmv@julipedia.org
To: gnats-bugs@gnats.NetBSD.org
Subject: ofwboot.xcf from current cannot boot system
X-Send-Pr-Version: 3.95
>Number: 44895
>Notify-List: uwe@netbsd.org
>Category: port-macppc
>Synopsis: ofwboot.xcf from current cannot boot system
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: port-macppc-maintainer
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Apr 22 14:50:01 +0000 2011
>Last-Modified: Tue Apr 02 16:55:00 +0000 2019
>Originator: Julio Merino
>Release: NetBSD 5.99.49
>Organization:
>Environment:
System: NetBSD mini.julipedia.org 5.99.49 NetBSD 5.99.49 (GENERIC) #1: Sun Apr 17 08:45:23 IST 2011 builder@mini.julipedia.org:/home/builder/obj/usr/src/sys/arch/macppc/compile/GENERIC macppc
Architecture: powerpc
Machine: macppc
>Description:
The ofwboot.xcf that is currently in -current cannot boot a system
on, at least, the Mac Mini G4 I have. Using the ofwboot.xcf from
NetBSD 5.1 (with the same kernel) works just fine.
I have the following partition scheme (from pdisk):
-----
Partition map (with 512 byte blocks) on '/dev/wd0c'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: Apple_HFS Boot 204800 @ 64 (100.0M)
3: Apple_UNIX_SVR2 Swap 4194304 @ 204864 ( 2.0G) S1 SFS k0 (swap)
4: Apple_UNIX_SVR2 Root 151902320 @ 4399168 ( 72.4G) S0 RUFS k0 /
Device block size=512, Number of Blocks=156301488 (74.5G)
DeviceType=0x0, DeviceId=0x0
-----
The following OF commands boot the system fine when I use the
ofwboot.xcf from 5.1:
boot hd:,\ofwboot-5.xcf netbsd
boot hd:,\ofwboot-5.xcf hd:4,/netbsd
However, these same commands fail miserably with the ofwboot.xcf
from current. They are able to locate the kernel, but as soon as
the kernel starts, it either panics or the machine reboots. An
example of the output I see sometimes:
-----
No ADB support present, assuming USB keyboard
trap: kernel ISI by 0xff847288 (SRR1 0x40003030), lr: 0x1001bc
panic: trap
Stopped
-----
See this port-macppc thread for some extra details:
http://mail-index.netbsd.org/port-macppc/2011/04/09/msg001374.html
>How-To-Repeat:
Install NetBSD/macppc current on a Mac Mini G4 1.2Ghz, try to boot
the kernel and see it fail.
>Fix:
Unknown. The code in ofwboot.xcf has changed significantly since
the 5.1 release.
>Release-Note:
>Audit-Trail:
From: Julio Merino <julio@meroh.net>
To: gnats-bugs@gnats.netbsd.org
Cc:
Subject: Re: port-macppc/44895
Date: Sat, 14 Jul 2012 22:27:06 -0400
Still true as of 6.99.8. ofwboot.xcf from NetBSD 5 continues to work
just fine, but current's does not.
--
Julio Merino / @jmmv
From: coypu@sdf.org
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-macppc/44895: ofwboot.xcf from current cannot boot system
Date: Sun, 16 Apr 2017 13:30:13 +0000
ping.
this is still true as of netbsd 7.1.
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-macppc/44895: ofwboot.xcf from current cannot boot system
Date: Mon, 17 Apr 2017 02:34:17 +0300
ofwboot.xcf from -D 20100313 works and the one from -D 20100314 doesn't.
So it looks like it was broken by:
sys/lib/libsa/loadfile_elf32.c
revision 1.25
date: 2010-03-13 00:43:11 +0300; author: darran; state: Exp; lines: +60 -4;
branches: 1.25.2;
DTrace: Add support for CTF sections in the netbsd elf image, load these
at boot.
Add a ksyms_mod_foreach() function to iterate a callback function over the
set of elf symbols for a specific module (netbsd included).
Add kern_ctf.c and mod_ctf_get() to allow the retrieval and decompression
of CTF sections for a specific module.
-uwe
From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-macppc/44895: ofwboot.xcf from current cannot boot system
Date: Mon, 17 Apr 2017 01:40:38 +0200
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--9gaCF22r1lRUhd5XWXcw7gM8Fi3AhRN74
Content-Type: multipart/mixed; boundary="ofV9SQkJ5nHscHSRRE62k7qoroedRQD5Q";
protected-headers="v1"
From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Message-ID: <3ffe35e1-a254-2e59-5a72-a4aa937b5c13@gmx.com>
Subject: Re: port-macppc/44895: ofwboot.xcf from current cannot boot system
References: <pr-port-macppc-44895@gnats.netbsd.org>
<20110422144912.1DF2262F33C@mini.julipedia.org>
<20170416233500.B38CF7A2AD@mollari.NetBSD.org>
In-Reply-To: <20170416233500.B38CF7A2AD@mollari.NetBSD.org>
--ofV9SQkJ5nHscHSRRE62k7qoroedRQD5Q
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 17.04.2017 01:35, Valery Ushakov wrote:
> The following reply was made to PR port-macppc/44895; it has been noted=
by GNATS.
>=20
> From: Valery Ushakov <uwe@stderr.spb.ru>
> To: gnats-bugs@NetBSD.org
> Cc:=20
> Subject: Re: port-macppc/44895: ofwboot.xcf from current cannot boot sy=
stem
> Date: Mon, 17 Apr 2017 02:34:17 +0300
>=20
> ofwboot.xcf from -D 20100313 works and the one from -D 20100314 doesn'=
t.
> So it looks like it was broken by:
> =20
> sys/lib/libsa/loadfile_elf32.c
> =20
> revision 1.25
> date: 2010-03-13 00:43:11 +0300; author: darran; state: Exp; lines:=
+60 -4;
> branches: 1.25.2;
> DTrace: Add support for CTF sections in the netbsd elf image, load the=
se
> at boot.
> Add a ksyms_mod_foreach() function to iterate a callback function over=
the
> set of elf symbols for a specific module (netbsd included).
> Add kern_ctf.c and mod_ctf_get() to allow the retrieval and decompress=
ion
> of CTF sections for a specific module.
> =20
> -uwe
> =20
>=20
Thanks for working on it! This bug affects my macppc (although I need to
get new apple keyboard to get into openfirmware again and test new
installation).
--ofV9SQkJ5nHscHSRRE62k7qoroedRQD5Q--
--9gaCF22r1lRUhd5XWXcw7gM8Fi3AhRN74
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJY9AD7AAoJEEuzCOmwLnZsfvcP/j3ZUOKvTDJl+3ZLhx2l3D12
xnjxHWX9YSRBCIatyzyS1Q3mCVMscGj612v2In6Fr7wgj6N/S+v3FzXBbsKe01Rt
CMn6FgrKurNiSqf9hguzqU2y3c9SWnwSdA/ygAM/+PVmFV+niwxRjPVSBipLYh79
lxT6Mf30p4JZxyYLexzcWs73AUSNOPT3A6WHtASBH2v9FMUwxHjbSQEsQ/KyWXMc
FO/Ml8onN0RZaBK+vG9PnO90G7925vcixtZZkTwIa59AO2owoQzkTtPGScrm0d+5
IgxStmNzztqrKMCxyMGucZdtCNFCb+1UEAXZ3DYQeChmLhNAcZYZDoTi/FfcdOU6
2JLWxuAZKtmIHJqvGvNUNH4FgoJLv6TDJhitPEi8jlhvhdHkZ8+H9ZAzlhNCt/dQ
mD0V+3uRAMZAG1TGOAssFTMrj12UDoEdpti1CGmGsxkM/pAo83fYB5U6u1hyG4YQ
AZhZiI4mPK/iSGV9+WFLFFi8hToS6MYON6o6uqUA9G427/7YJx4KomP4UzDfvCM6
DWxhhR4H6dYN6TmZzC5y2F2jZAa08aCmlIN0JtBoS9BR8wpH0rggtfaCKBMax6YV
3f9cq87YSqVa/Cs6MAgARVJtitRBzBbnIHPPVHOFf4FDyhV7fx3lsQvW0PR+gSaa
vDiBH/gXkEWEs7zdjbD+
=JyyK
-----END PGP SIGNATURE-----
--9gaCF22r1lRUhd5XWXcw7gM8Fi3AhRN74--
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-macppc/44895: ofwboot.xcf from current cannot boot system
Date: Mon, 17 Apr 2017 16:59:57 +0300
I did a bit more research but my xcoff and powerpc fu is not enough.
Here's what I've leared so far.
If you want to be historically correct:
- checkout trunk at -D 20100313
- that gives you sys/lib/libsa/loadfile_elf32.c 1.24 (that works)
- manually check out 1.25 of loadfile_elf32.c (that breaks xcoff)
but you should probably just use current.
- build.sh -m macppc ... tools
nbmake-macppc obj
# i also did nbmake-macppc do-distrib-dirs includes - but those are not
# necessary to build the bootloader
- cd sys/arch/macppc/stand/ofwboot
- I used the following patch to make elf/xcoff comparison easier
(patch against the old sources, but it should be obvious what it
does to apply it to current):
Index: Makefile
===================================================================
RCS file: /cvsroot/src/sys/arch/macppc/stand/ofwboot/Makefile,v
retrieving revision 1.49
diff -u -p -u -r1.49 Makefile
--- Makefile 3 Apr 2009 10:38:13 -0000 1.49
+++ Makefile 17 Apr 2017 13:44:25 -0000
@@ -47,6 +47,7 @@ RELOC= E00000
ENTRY= _start
CLEANFILES+= vers.c ${PROG}.elf ${PROG}.el1 ${PROG}.mrg ${PROG}.xcf
+CLEANFILES+= ${PROG}.elm
CPPFLAGS+= -I. -I${.CURDIR} -I${.CURDIR}/../../.. -I${.CURDIR}/../../../..
CPPFLAGS+= -DRELOC=0x${RELOC} -DRELOC_FLATFILE=0x${RELOC_FLATFILE}
@@ -79,7 +80,7 @@ cleanlibdir:
vers.c: version
${HOST_SH} ${S}/conf/newvers_stand.sh ${.CURDIR}/version "macppc" ${NEWVERSWHAT}
-all realall: ${PROG} ${PROG}.xcf ${PROG}.elf
+all realall: ${PROG} ${PROG}.xcf ${PROG}.elf ${PROG}.elm
${PROG}: ${OBJS} ${LIBSA} ${LIBZ} ${LIBKERN}
${_MKTARGET_LINK}
@@ -98,8 +99,14 @@ ${PROG}.elf: ${OBJS} ${LIBSA} ${LIBZ} ${
${PROG}.xcf: ${OBJS} ${XCOFFXTRAOBJ} ${LIBSA} ${LIBZ} ${LIBKERN}
${_MKTARGET_LINK}
${LD} -s -N -T ${.CURDIR}/../fixcoff/elf32_powerpc_merge.x -e _entry \
- -Ttext ${RELOC} -Bstatic -o ${PROG}.mrg ${XCOFFXTRAOBJ} \
- ${OBJS} ${LIBSA} ${LIBZ} ${LIBKERN}
+ -Ttext ${RELOC} -Bstatic -o ${PROG}.mrg \
+ ${OBJS} ${LIBSA} ${LIBZ} ${LIBKERN} ${XCOFFXTRAOBJ}
${OBJCOPY} -O aixcoff-rs6000 -R .comment -R .note \
${PROG}.mrg ${PROG}.xcf
${TOOL_MACPPCFIXCOFF} ${PROG}.xcf
+
+${PROG}.elm: ${OBJS} ${XCOFFXTRAOBJ} ${LIBSA} ${LIBZ} ${LIBKERN}
+ ${_MKTARGET_LINK}
+ ${LD} -s -N -T ${.CURDIR}/../fixcoff/elf32_powerpc_merge.x \
+ -Ttext ${RELOC} -Bstatic -o ${PROG}.elm \
+ ${OBJS} ${LIBSA} ${LIBZ} ${LIBKERN} ${XCOFFXTRAOBJ}
The ofwboot.elm is an elf file with the same .text layout as the
xcoff file. It also uses the same linker script as the xcoff file.
objdump -d on ofwboot.elm and ofwboot.xcf shows identical code.
- nbmake-macppc dependall
- copy ofwboot.elf and ofwboot.xcf to your boot partition (I used FAT
on this test box, so this was trivial)
You are now set up to test this. Note that the ofwboot.elm works and
ofwboot.xcf doesn't work. It loads the kernel, but the kernel panics
very early. Adding some instrumentation to the kernel, I see that it
fails in OF_peer(0) call in sys/arch/powerpc/oea/ofwoea_machdep.c in
set_timebase() - we probably screw up memory mappings for the OFW.
This is puzzling given that we use exactly the same code in elf and
xcoff versions.
That revision 1.25 doesn't have anything too suspicious (though I'm
not sure why does it need to read .shstrtab twice). Basically it just
reads a few hundred bytes of .shstrtab section to the in-memory elf
image.
-uwe
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-macppc/44895: ofwboot.xcf from current cannot boot system
Date: Mon, 17 Apr 2017 18:11:40 +0300
After playing with it a bit more I think the real bug is in the
bootloader's memory allocator code. If I roll back to
loadfile_elf32.c 1.24 (the good one) and just add ALLOC/DEALLOC pair
where 1.25 would allocate "shstr", the resulting ofwboot.xcf is
broken.
-uwe
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-macppc/44895: ofwboot.xcf from current cannot boot system
Date: Mon, 3 Jul 2017 14:26:53 +0300
Data point: Some people has been reporting that ofwboot.xcf does work
for them on their minis. What they were doing differently was using
compressed netbsd.gz instead of netbsd.
-uwe
From: scole_mail <scole_mail@gmx.com>
To: gnats-bugs@NetBSD.org
Cc: matt@netbsd.org
Subject: Re: port-macppc/44895: ofwboot.xcf from current cannot boot system
Date: Fri, 15 Sep 2017 14:39:15 -0700
I ran into this issue from current from a few days ago. I'm using a
powermac 7500/604, and couldn't boot ofwboot
0 > boot file: 10.0.0.1,ofwboot.xcfloading XCOFF
tsize=10000 dsize=258 bsize=2750 entry=E00000
SECTIONS:
.text 00E00000 00E00000 00010000 00001000
.data 00E10000 00E10000 00000258 00011000
.bss 00E10258 00E10258 00002750 00000000
.gnu.att 00000000 00000000 00000010 00011258
.ident 00000000 00000000 00000076 00011268
loading .textDEFAULT CATCH!, code=FFF00300
ok
7.1 worked fine for me though:
0 > boot file: 10.0.0.1,ofwboot.xcfloading XCOFF
tsize=EF00 dsize=250 bsize=2750 entry=E00000
SECTIONS:
.eh_fram 00000074 00000074 00002218 0000014C
.text 00E00000 00E00000 0000EF00 00002370
.data 00E0F000 00E0F000 00000250 00011270
.bss 00E0F250 00E0F250 00002750 00000000
.gnu.att 00000000 00000000 00000010 000114C0
.ident 00000000 00000000 00000076 000114D0
loading .text, done..
loading .data, done..
clearing .bss, done..
Neither versions (current or 7.1) of the ofwboot.elf worked for me.
I haven't had time to look at this, but I may have had a similar issue
before
http://mail-index.netbsd.org/port-macppc/2014/12/23/msg002129.html
but <matt> did some magic fixing the linker script, maybe the problem is
similar.
Thanks
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc: scole_mail <scole_mail@gmx.com>
Subject: Re: port-macppc/44895: ofwboot.xcf from current cannot boot system
Date: Sat, 16 Sep 2017 02:31:35 +0300
On Fri, Sep 15, 2017 at 21:40:01 +0000, scole_mail wrote:
> I ran into this issue from current from a few days ago. I'm using a
> powermac 7500/604, and couldn't boot ofwboot
>
> 0 > boot file: 10.0.0.1,ofwboot.xcfloading XCOFF
> tsize=10000 dsize=258 bsize=2750 entry=E00000
> SECTIONS:
> .text 00E00000 00E00000 00010000 00001000
> .data 00E10000 00E10000 00000258 00011000
> .bss 00E10258 00E10258 00002750 00000000
> .gnu.att 00000000 00000000 00000010 00011258
> .ident 00000000 00000000 00000076 00011268
> loading .textDEFAULT CATCH!, code=FFF00300
> ok
No, this is a different problem. What you describe is ofwboot
*itself* not being loaded/started correctly. This bug is about
ofwboot not loading the kernel correctly.
-uwe
From: scole_mail <scole_mail@gmx.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-macppc/44895: ofwboot.xcf from current cannot boot system
Date: Fri, 15 Sep 2017 17:40:35 -0700
Valery Ushakov <uwe@stderr.spb.ru> writes:
>
> No, this is a different problem. What you describe is ofwboot
> *itself* not being loaded/started correctly. This bug is about
> ofwboot not loading the kernel correctly.
>
> -uwe
Apologies, I'll try to look at this further and file a separate PR if
needed.
Thanks
From: Alexander Hedges <ahedges@student.ethz.ch>
To: <gnats-bugs@NetBSD.org>
Cc:
Subject: Re: port-macppc/44895: ofwboot.xcf from current cannot boot system
Date: Sat, 26 Aug 2017 10:40:58 +0200
I'm not sure if this is the same issue but booting the 7.1 netbsd.macppc from
the provided disk image does not work on my PowerBook G4 (2005).
When I run
boot cd:,\ofwboot.xcf netbsd.macppc
loading the xcf seems to work fine, but then I get
5926884+130584=0x5c71fc
start=0x100000
Decrementer exception at %SRR0: 004d51e0 %SRR1:00003030
ok
Now, I found someone on the internet who seemed to have had a similar problem in
2008, booting FreeBSD (markmail.org/message/nmzthacf33qdfd7b) where somebody
else suggested setting the decrementer register using `1 1f lshift not dec!` as
a workaround (I'm not really that familiar with OpenFirmware). After rebooting
and trying that out the new failure message reads:
5926884+130584=0x5c71fc
start=0x100000
Invalid memory access at %SRR0: 004d51e0 %SRR1:00003030
ok
From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: uwe@netbsd.org, port-macppc-maintainer@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
jmmv+mini.jmmv@julipedia.org
Subject: re: port-macppc/44895: ofwboot.xcf from current cannot boot system
Date: Wed, 20 Sep 2017 06:32:39 +1000
> I'm not sure if this is the same issue but booting the 7.1 netbsd.macpp=
c from
> the provided disk image does not work on my PowerBook G4 (2005).
> =
> When I run
> =
> boot cd:,\ofwboot.xcf netbsd.macppc
> =
> loading the xcf seems to work fine, but then I get
> =
> 5926884+130584=3D0x5c71fc
> start=3D0x100000
> =
> Decrementer exception at %SRR0: 004d51e0 %SRR1:00003030
> ok
> =
> Now, I found someone on the internet who seemed to have had a similar p=
roblem in
> 2008, booting FreeBSD (markmail.org/message/nmzthacf33qdfd7b) where som=
ebody
> else suggested setting the decrementer register using `1 1f lshift not =
dec!` as
> a workaround (I'm not really that familiar with OpenFirmware). After re=
booting
> and trying that out the new failure message reads:
> =
> 5926884+130584=3D0x5c71fc
> start=3D0x100000
> =
> Invalid memory access at %SRR0: 004d51e0 %SRR1:00003030
> ok
this looks like PR 22316 to me:
http://gnats.netbsd.org/22316
.mrg.
From: "Valeriy E. Ushakov" <uwe@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/44895 CVS commit: src/sys/arch/macppc/stand/ofwboot
Date: Wed, 6 Jun 2018 22:56:26 +0000
Module Name: src
Committed By: uwe
Date: Wed Jun 6 22:56:25 UTC 2018
Modified Files:
src/sys/arch/macppc/stand/ofwboot: Locore.c Makefile boot.c
Log Message:
Provide an option to use libsa allocator. Not yet enabled. Same
binary code is generated.
To enable uncomment -DHEAP_VARIABLE and comment out alloc.c in the
makefile.
PR port-macppc/44895
To generate a diff of this commit:
cvs rdiff -u -r1.29 -r1.30 src/sys/arch/macppc/stand/ofwboot/Locore.c
cvs rdiff -u -r1.58 -r1.59 src/sys/arch/macppc/stand/ofwboot/Makefile
cvs rdiff -u -r1.28 -r1.29 src/sys/arch/macppc/stand/ofwboot/boot.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-macppc/44895: ofwboot.xcf from current cannot boot system
Date: Thu, 7 Jun 2018 02:19:28 +0300
On Mon, Apr 17, 2017 at 15:15:01 +0000, Valery Ushakov wrote:
> After playing with it a bit more I think the real bug is in the
> bootloader's memory allocator code. If I roll back to
> loadfile_elf32.c 1.24 (the good one) and just add ALLOC/DEALLOC pair
> where 1.25 would allocate "shstr", the resulting ofwboot.xcf is
> broken.
Apparently I never posted a follow up...
I've just committed a bit of trivial code that I had sitting in my
tree to use libsa alloc.c instead of ofwboot's own ./alloc.c. It's
not yet enabled and the same object code is generated for now. You
can edit the makefile to change to the libsa allocator.
The new (disabled) code makes ofwboot.xcf happy, apparently. Since
the root cause of the bug was never discovered it may be just masking
the bug, but whatever :)
./alloc.c is very naive as it rounds every allocation up to the page
size that it gets with OF_claim.
The new code OF_claim's HEAP_SIZE heap (default 0x20000) and lets
libsa manage it.
Since libsa allocator cannot request additional memory anyway we may
as well just use an array in .bss for heap instead.
But I wanted to commit what I had and what's known to fix or at least
mask the issue and then someone who's interested can experiment and
test on other machines too.
-uwe
From: Michael <macallan@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-macppc/44895: ofwboot.xcf from current cannot boot system
Date: Wed, 13 Jun 2018 13:46:26 -0400
I just booted my Powerbook6,7 from disk with an ofwboot.xcf built from
Sunday's sources. A slightly older ofwboot.xcf would crash on this
machine, so I guess your fix works.
have fun
Michael
From: coypu@sdf.org
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-macppc/44895: ofwboot.xcf from current cannot boot system
Date: Tue, 2 Apr 2019 16:54:25 +0000
please make it the default option, working is a good default.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.