Re: Building a macppc bootable USB image

On Wed, Jan 17, 2024 at 20:56:27 +0000, David Brownlee wrote:

> Technically it should be possible to generate an image which could be
> written to a USB device and booted for a large chunk of macppc
> machines, and would make it very much easier for people to try and
> install NetBSD/macppc.
> 
> Ideally we should be able to include something in build.sh so standard
> NetBSD builds could include an install and/or live macppc image
> similar to amd64/i386.
> 
> Does anyone have the time and inclination to look at any of this?

I spent a bit of time experimenting with booting my mini off of a
plain FAT USB and the results are a bit mixed.

One can dd the (proper) install CD onto the USB and boot off of that.
The downside is that the proper install CD requires a tool not in base
to create the proper HFS-whatever info for the CD (cf. non-bootable
iso images from daily builds).  So I thought I'll look at plain FAT.

OFW in mini groks FAT, so you can put ofwboot on a FAT partition
(that's how I normally boot).  But putting a kernel to the same FAT
partition seems to pose a problem.  As far as I understand we will use
OFW to read that file in that case and it looks like OFW's FAT
implementation has issues with "seek".  I can boot the generic kernel
from that same partition.  I can't boot either that same generic
kernel gzipped, or the gzipped install kernel.  I can't boot gunzipped
install kernel either.  I'm not sure why generic is lucky.

Gzipped kernels fail to boot b/c we read the gzipped file to the end
and then to seek backwards to read the symbols we need to reread the
whole file, but when we seek to the beginning, the read just returns
zero, as if we are stuck at EOF.

As an experiment, reading the whole file inside open and seeking back
to zero has the same effect - the next reads return 0.  If I do just a
few test reads inside open and then rewind, eventually some read later
on will fail.  So it's as if OFW deblocker keeps track of the position
correctly, but loses track of how much it can still read from that
position (that same generic kernel that happens to boot, will not boot
in this case, with a couple of extra reads/seeks thrown into the mix
inside open).

I haven't yet figured out how to convince ofwboot to use libsa version
of the filesystem code.  ofwboot can load kernel from whatever you
want, but it uses a bit different syntax, doesn't use devalias
abbreviations and so it's quite a pain to experiment b/c you need to type

  boot usb0/disk:,\ofwboot.elf /pci@f2000000/usb@1b,1/disk/install

in tiny letters, on a real keyboard instead of just pasting it into a
serial console.  (The above of course can be spelled as

  boot usb0/disl:,\ofwboot.elf install

and if the kernel is named "netbsd" instead of "install" you don't
have to type its name, but here the point was to, for now, avoid the
default on purpose.)

Instead of a kernel with a ramdisk we can probably just use a separate
partition on the same USB, but copying a few files onto a FAT
formatted USB is more convenient than creating an image you have to
dd, etc, etc.


-uwe