[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: hfs boot floppy versions



@Sven: 20051031 boot.img works, but it will not throw out the floppy when it asks for the second disk root.bin - there is no soft eject command issued, I guess. As you surely know, apple forgot the hard-eject knob on most of their floppy drives and that makes it a slight problem to continue at this point...
thx in advance for having a look


Brad Boyer schrieb:

On Mon, Oct 31, 2005 at 02:56:52PM +0100, Christian M?ller wrote:
* http://www.netbsd.org/Ports/macppc/SystemDisk-tutorial/ (NetBSD also messes with real-base, sure they will have their reasons, but it will make a dual boot machine to a classic mac os uncomfortable - though mac os boots with the tampered with real-base, but resets it to default. i've read about systems prior to the beige G3 that reset many more of the boot variables to defaults <- maybe hack a forth script into nvram named bootlinux/bootbsd that sets proper variables and afterwards does 0 bootr if there is space in nvram for own forth functions <- are they kept like varaibles I set??)

I'm pretty sure my 7600 reset everything on a mac boot sequence. I know
it cleared out the patch for the control video mode bug.
Which was a forth function you somehow stored in nvram (the control cidmode patch)?

Somewhere I read a post saying that it might be possible to load a vmlinuz.xcoff directly via OpenFirmware command (which would render the extra ofwboot.xcf NetBSD uses pointless), I did not succeed in doing so. I tried it with boot-devie set to ide1/@0:,\INSTALL\POWERPC\VMLIN001.INI - if someone succeeded with something like this, please come forward =).

One of the early linuxppc installers did something like this. A kernel
and initrd were packaged up into a file called vmlinux.coff, which was
then written to an HFS floppy. The firmware was told to boot from the
path "fd:vmlinux.coff", and it read and executed the kernel directly
from the floppy. It looks like some of that support is still in the
kernel tree even in 2.6. Take a look at arch/ppc/boot/utils/hack-coff.c
and arch/ppc/boot/openfirmware/coffmain.c for more info.

Well, Sven actually does build those vmlinuz.coff, but they don't fit onto a floppy anymore - anyway, I tried to just let OpenFirmware search and load vmlinuz.coff directly from an iso9660 cd (which I tried with the above VMLIN.., wait - did I append ;1? - have to check that...). This ought to, if it were not for the huge size, work - I had OF boot the tiny ofwboot.xcf code successfuly either way - from a dos floppy and from an iso9660 cd. The size difference suggests the following problem: OF simply does not memcpy such a huge file into the mac memory and starts it. Another problem might be the kernel itself - does it expect to live somewhere in memory space (sorry, noob question)? With system disk patches applied vmlinuz.coff would start at 0x600000 in memspace. Still another thing I can think of is memory collision - does anybody have a little more insight what the real-base var effects? Right now I'm guessing (this is probably terribly wrong) that OpenFirmware is shadowed into the RAM somewhere, maybe @real-base?

regards,
Christian



Reply to: