@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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
