Re: Booting netbsd-GENERIC_MD on iMac G3 using ofwboot.xcf + genfb woes

[Sam van Kampen <sam%tehsvk.net@localhost>]

Hi Tom, all,

> The trick I've used, which Martin Husemann
> taught me, is to set up a minimal install on an NFS mount, boot from
> that as if diskless, and then invoke sysinst manually to install on
> local disk.

Ah, clever. I would have tried netinstall, but I figured it might be
its own rabbit hole on these systems - looking into it now it seems
like it wouldn't be too bad, though. Next time!

> After that, the standard GENERIC_MD kernel works.

(I assume you mean the standard GENERIC kernel, since _MD would still
be too large to load)

> But I've been wondering how long that'd keep being true, so I'd
> be for increasing RELOC or whatever is needed to have some more
> daylight for kernel growth, and maybe even re-enable the normal
> install/upgrade process.  All of those machines had at least 128MB
> when purchased, and eventually got upgraded to a lot more RAM, so
> I'm not too concerned about a little bit of wastage.

Same here, this machine has 192MB of RAM. Perhaps there can be a
separate version of ofwboot.xcf for the most resource-constrained
systems, just like e.g. mac68k has a SMALLRAM kernel.

Another option I considered but haven't yet tested is trying to load
ofwboot _under_ 0x100000. Since the loader is quite small (~76KB) it
might fit, and that leaves room for the kernel to grow as much as it
likes. But who knows how compatible that would be across all of these
machines, and I don't have any OFW 1.x or 2.x systems to test with.
I'd guess it is probably safer to load ofwboot at 24MB instead. (In my
original message I suggested 16MB, but of course when I built with
different options my kernel grew too big again.. so good to have a bit
of a bigger safety margin).

As for my original woes, I am happy to report that, with r128fb
enabled, I was able to boot and install the system successfully! By
default r128fb doesn't pick up my card, so it does require adding the
PCI ID of the card to its match function (patch below). After that it
was smooth sailing. Now onto the next hurdle, which seems to be X. The
r128 driver _should_ support this card.. but when I start the server I
just get an unrecoverable blank screen...

Cheers,

Sam

---
diff --git a/sys/dev/pci/r128fb.c b/sys/dev/pci/r128fb.c
index a525ddee08f..c081fa9f6d3 100644
--- a/sys/dev/pci/r128fb.c
+++ b/sys/dev/pci/r128fb.c
@@ -181,6 +181,7 @@ r128fb_match(device_t parent, cfdata_t match, void *aux)
        if ((PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ATI_RAGE1AGP4XT) ||
            (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ATI_RAGE3AGP4XT) ||
            (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ATI_RAGEGLPCI) ||
+           (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ATI_RAGEVRAGP) ||
            (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ATI_RAGE_MOB_M3_AGP))
                return 100;
        return (0);


On Mon, 19 Oct 2026 at 18:12, Tom Lane <tgl%sss.pgh.pa.us@localhost> wrote:
>
> Sam van Kampen <sam+netbsd%tehsvk.net@localhost> writes:
> > I am not sure what the best way forward is here. We can bump RELOC, I
> > imagine, but that would exclude systems with <=16MB of memory, and
> > there are lots of kernel configurations which are small enough to
> > boot. Perhaps that is acceptable (I imagine there are very few macppc
> > systems that are useful _and_ that low on memory), or otherwise the
> > GENERIC_MD kernel can be shrunk a bit?
>
> I have some practical experience with that.  I've run reasonably
> recent NetBSD (9.3 and later) on three different PPC Macs; the one
> that I still have is still on active duty with NetBSD 11.0.  On
> none of them has it been possible to boot the regular installer
> netbsd-GENERIC_MD.gz kernel --- I guess the RAM disk included in that
> pushes it over the limit.  The trick I've used, which Martin Husemann
> taught me, is to set up a minimal install on an NFS mount, boot from
> that as if diskless, and then invoke sysinst manually to install on
> local disk.  After that, the standard GENERIC_MD kernel works.
> But I've been wondering how long that'd keep being true, so I'd
> be for increasing RELOC or whatever is needed to have some more
> daylight for kernel growth, and maybe even re-enable the normal
> install/upgrade process.  All of those machines had at least 128MB
> when purchased, and eventually got upgraded to a lot more RAM, so
> I'm not too concerned about a little bit of wastage.
>
>                         regards, tom lane