bypassing MacOS using Open Firmware on Apple pmac G3

bypassing MacOS using Open Firmware on Apple pmac G3

[Jim Chapman]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

I have an Apple PowerMAC G3 and I currently boot Linux via MacOS using
BootX. I am trying to configure the Open Firmware (OF) NVRAM settings
such that Linux is booted by default, but I can't make it work Can
anyone help?

I have 2 IDE disks. ide0 is used by MacOS and ide1 is for Linux. The
root partition is on ide1 (hdb5).

I followed instructions in the LinuxPPC Installation Guide but when I
try to boot, OF displays

boot MAC-PARTS: LOAD (interposed) not supported load-size=0 adler32=1

What is this message telling me? Is the machine still trying to boot
MacOS?

I set the following variables using the OF "setenv" command:-

boot-device    ide1/disk@0:5
boot-file    ide1/disk@0:5/boot/vmlinux root=/dev/hdb5 hda=noautotune
hdb=noautotune
boot-command    dev ide1 cr set-timeout 0 cr boot
load-base    0x100000 (and 0x4000, 0x60000, 0x10000...)

I guessed that ide1, partition 5 would be represented as ide1/disk@0:5.
What does that @0 represent?
Perhaps I need to set other variables?

OF displays its versions as PowerMAC1, 1 1.1f1, Open Firmware 3.1.1.

I also noticed that the LinuxPPC "nvsetenv" command doesn't display that
variable values as listed above. Effectively, any changes to boot
variables I make with "nvsetenv" seem to be localised to the Linux
environment; they are remembered between reboots, but the values are
different to those displayed by the OF "printenv" command. It's as if
the OF "setenv" command and linux "nvsetenv" command modify different
copies of the parameters in NVRAM!!!! Is anyone else seeing this?

Thanks

    Jim Chapman


[-- Attachment #2: Card for Jim Chapman --]
[-- Type: text/x-vcard, Size: 342 bytes --]

begin:vcard 
n:Chapman;Jim
tel;fax:+44-1865-784004
tel;work:+44-1865-784569
x-mozilla-html:TRUE
url:http://www.xstreamis.com
org:Xstreamis plc;R&D
version:2.1
email;internet:jim.chapman@xstreamis.com
title:Principal Engineer
adr;quoted-printable:;;Magdalen Centre=0D=0AOxford Science Park;OXFORD;OXON;RG8 0ND;ENGLAND
fn:Jim Chapman
end:vcard

Re: bypassing MacOS using Open Firmware on Apple pmac G3

[Ethan Benson]

On 22/10/99 Jim Chapman wrote:

>I have an Apple PowerMAC G3 and I currently boot Linux via MacOS using
>BootX. I am trying to configure the Open Firmware (OF) NVRAM settings
>such that Linux is booted by default, but I can't make it work Can
>anyone help?

this is a blue G3 isn't it?  (i recognize the BF version number)

>I have 2 IDE disks. ide0 is used by MacOS and ide1 is for Linux. The
>root partition is on ide1 (hdb5).
>
>I followed instructions in the LinuxPPC Installation Guide but when I
>try to boot, OF displays
>
>boot MAC-PARTS: LOAD (interposed) not supported load-size=0 adler32=1
>
>What is this message telling me? Is the machine still trying to boot
>MacOS?

its telling you that OpenFirmware is complete junk^U its telling you 
that its ignoring the bootblocks on your disk (which contain the 
first stage quik loader) its not necessarily trying to boot macos it 
just won't boot off a disk like that, it insists that you point it at 
a file directly on the filesystem (say the second stage quik loader 
or a linux kernel) the problem is 1) those are on ext2 filesystems 
which OF don't understand, and even if it did the linux kernel 
(unlike *bsd) is unbootable by OF because it lacks the correct OF 
note section in the executable, quik second stage in elf format is 
unusable still since it is clueless on what it is supposed to do.

I have tinkered a tremendous amount hacking trying to figure a way to 
get OF to boot a bootblock off the disk and have not yet found a way, 
Cort tells me he thought someone had done it but has not got back to 
me yet.  (are you out there Cort??)

the next solution I have come up with (for true MacOS freedom) is to 
partition the disk with fdisk using a regular PC DOS partition table 
and make an extra 800K DOS formatted partition then put the quik 
second stage loader on that, this will work and you can get OF to 
boot the quik loader (which right now does not do much other then say 
quik 2.0 and fail) so first we need to teach the elf version of quik 
to presumably parse a configuration file and then to load a kernel 
image off the specified partition.

I would prefer to use DOS partitions since they can be created in a 
GNU/Linux only environment mac partition tables are only bootable if 
there is HFS filesystems on them and you cannot create HFS 
filesystems with GNU/Linux (and may not even be able to mount them 
under 2.4 kernel unless someone picks up the orphaned HFS code)

in short this used to work on older G3s and apple just crippled it on 
the new ones to make their own life difficult along with ours.

>I set the following variables using the OF "setenv" command:-
>
>boot-device    ide1/disk@0:5
>boot-file    ide1/disk@0:5/boot/vmlinux root=/dev/hdb5 hda=noautotune
>hdb=noautotune
>boot-command    dev ide1 cr set-timeout 0 cr boot
>load-base    0x100000 (and 0x4000, 0x60000, 0x10000...)
>
>I guessed that ide1, partition 5 would be represented as ide1/disk@0:5.
>What does that @0 represent?
>Perhaps I need to set other variables?

your settings are fine, just useless because of the crippled 
BrokenFirmware on these machines.

>OF displays its versions as PowerMAC1, 1 1.1f1, Open Firmware 3.1.1.

BlueG3 BrokenFirmware

>I also noticed that the LinuxPPC "nvsetenv" command doesn't display that
>variable values as listed above. Effectively, any changes to boot
>variables I make with "nvsetenv" seem to be localised to the Linux
>environment; they are remembered between reboots, but the values are
>different to those displayed by the OF "printenv" command. It's as if
>the OF "setenv" command and linux "nvsetenv" command modify different
>copies of the parameters in NVRAM!!!! Is anyone else seeing this?

I don't think that utility works right on blue G3s...



Best Regards,
Ethan Benson
To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bypassing MacOS using Open Firmware on Apple pmac G3

[Peter Bierman]

>in short this used to work on older G3s and apple just crippled it on
>the new ones to make their own life difficult along with ours.

Heheh. How true.

OF serves no one's goals beyond booting Mac OS. Anything else is good
fortune for those using it. The good news is that as new machines come out,
OF generally gets better at booting non-Traditional Mac OS things.

Mac OS X should make your lives easier.

I suggest a small HFS springboard partition. OF on all machines knows how
to find and boot an HFS volume. You can put a fake System folder with a
boot 2 resource, and a tbxi fake ROM image that acts as your booter.

Standard HFS is a pretty simple filesystem.

if you go with the above design, I predict you'll have a lot less work to
do to keep up with new hardware and OF versions.

I don't work on OF, so don't bother asking,
-pmb

--
"Apple is doomed. At some point the universe may collapse upon itself, and
 this would crush even the hard plastic shells of fast, high-capacity iMacs."
 - Minneapolis Star Tribune 10.19.99


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bypassing MacOS using Open Firmware on Apple pmac G3

[Ethan Benson]

On 22/10/99 Peter Bierman wrote:

>
>Heheh. How true.
>
>OF serves no one's goals beyond booting Mac OS.

right MacOS8.* EXCLUDING OSX

>Anything else is good
>fortune for those using it. The good news is that as new machines come out,
>OF generally gets better at booting non-Traditional Mac OS things.
>
>Mac OS X should make your lives easier.

not really. unless we buy new hardware of course (assuming OF 
engineers get some clue at some point.)

>I suggest a small HFS springboard partition. OF on all machines knows how
>to find and boot an HFS volume. You can put a fake System folder with a
>boot 2 resource, and a tbxi fake ROM image that acts as your booter.

thats unnecessary, OF could not give a flying fart about a system 
folder, blessed folders etc, you can point it directly at a ordinary 
file.

using HFS is not an option IMO because it must be created on macos, 
unless someone wants to write a mkfs.hfs, didn't think so.  no thanks 
I'll stick with a DOS partition that I can take care of in a total 
Free environment rather then keeping macos around just to maintain 
the bootloader.  (which is just as bad as using Bootx

>Standard HFS is a pretty simple filesystem.

not really, otherwise we would have mkfs.hfs and a 2.4 kernel 
compatible hfs.o, its obviously complicated enough that nobody wants 
to spend the time on it. (more to the point its irrelevant how 
complicated it is, nobody is working on it.)

>if you go with the above design, I predict you'll have a lot less work to
>do to keep up with new hardware and OF versions.

using DOS partition tables and a DOS partition in place of non free 
HFS has no problems either, we still need a second stage quik that 
does something useful however.  (ISO filesystem might work too but I 
have had problems getting BF to read from it.)

>I don't work on OF, so don't bother asking,

can you sneak up on the OF engineers and give them a good healthy 
whack with a clue stick?



Best Regards,
Ethan Benson
To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bypassing MacOS using Open Firmware on Apple pmac G3

[Tony Mantler]

At 7:24 PM -0500 10/22/99, Ethan Benson wrote:
>On 22/10/99 Peter Bierman wrote:
[...]
>>Standard HFS is a pretty simple filesystem.
>
>not really, otherwise we would have mkfs.hfs and a 2.4 kernel
>compatible hfs.o, its obviously complicated enough that nobody wants
>to spend the time on it. (more to the point its irrelevant how
>complicated it is, nobody is working on it.)

Being a person who knows how HFS works (After having to manually rescue my
main drive. Oops, good lesson to always backup), I can say that it is
indeed a very simple filesystem.

The basic parts of HFS are a Parent Directory/Filename sorted catalog
B-Tree, a Filenumber (iirc) sorted Extents B-Tree, a volume bitmap, and a
few special blocks sprinkled about for good measure.

*However*...

Coding a stable, writable filesystem - *any* filesystem - is a bloody pain
in the wrists, and thus not something people (including myself) tend ot
volunteer to do. As such, it doesn't get done very often. (Though sometimes
money and equipment donations help get things done. *hint* *hint*) :)

Both HFS and HFS+ are completley and accuratley documented at Apple's web
site. Anyone interested in the issue should take the time to read and
understand those documents, it's well worth the effort.


Cheers - Tony


--
Tony Mantler         Renaissance Nerd Extraordinaire         eek@escape.ca
Winnipeg, Manitoba, Canada                       http://www.escape.ca/~eek


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bypassing MacOS using Open Firmware on Apple pmac G3

[Ani Joshi]

On Fri, 22 Oct 1999, Ethan Benson wrote:

> not really. unless we buy new hardware of course (assuming OF 
> engineers get some clue at some point.)

	could you please get yourself a "clue" and stop making such stupid
statements, this will prevent people from thinking you are as foolish as
your statements.

> not really, otherwise we would have mkfs.hfs and a 2.4 kernel 
> compatible hfs.o, its obviously complicated enough that nobody wants 
> to spend the time on it. (more to the point its irrelevant how 
> complicated it is, nobody is working on it.)

	2.4?  if its 2.3 you mean, hfs works fine with the latest (2.3.22
on my box is doing hfs fine), and i recall long ago formatting an hfs
floppy, though i forgot the util, i think it was in hfs-utils or
something....  i may be wrong though...

> using DOS partition tables and a DOS partition in place of non free 
> HFS has no problems either, we still need a second stage quik that 
> does something useful however.  (ISO filesystem might work too but I 
> have had problems getting BF to read from it.)
> 
> can you sneak up on the OF engineers and give them a good healthy 
> whack with a clue stick?

<flame>
	personally, this sounds like a lot of whining, this really has no
place here.  if you could please add some constructive comments on what
needs to be done instead of "this sucks, of sucks, you morons morons need
to fix it", why don't *you* do something about it then?  why don't you try
and fix it?

enuff with the bitching already, this is the second time i've seen you do
this...  its getting old dude...

</flame> 

> Best Regards,
> Ethan Benson
> 

ani


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bypassing MacOS using Open Firmware on Apple pmac G3

[Ethan Benson]

On 22/10/99 Ani Joshi wrote:

>
>	could you please get yourself a "clue" and stop making such stupid
>statements, this will prevent people from thinking you are as foolish as
>your statements.

excuse me?  OSX will not change the current OF that we have now which 
is preventing a non macos bootstrap, OSX bootloader is not going to 
load linux we still have to hack our own.  after OSX comes around 
Apple's OF will likely stop being so bloody macos 8* specific. as I 
believe is what peter meant. that does not change a damned thing for 
all the broken machines we have now.

>
>	2.4?  if its 2.3 you mean, hfs works fine with the latest (2.3.22
>on my box is doing hfs fine), and i recall long ago formatting an hfs
>floppy, though i forgot the util, i think it was in hfs-utils or
>something....  i may be wrong though...

I recall a thread on this list not too long ago where it was reported 
that HFS.o needed to be modified or rewritten to be compatible with 
the new kernel, just like every other filesystem, it was mentioned as 
a concern because nobody seems to be maintaining the hfs filesystem 
code. (or netatalk or anything else in the apple filesystem realm)

>
><flame>
>	personally, this sounds like a lot of whining, this really has no
>place here.  if you could please add some constructive comments on what
>needs to be done instead of "this sucks, of sucks, you morons morons need
>to fix it", why don't *you* do something about it then?  why don't you try
>and fix it?

bullshit, the current and past OF implemenatations have been causing 
nothing but trouble for just about everything related to linux, the 
more recent ones solve some problems but created new ones for the 
bootstrap, Peter seems to agree with me that OF is broken in its boot 
method as it creates headaches for OSX as well!  I have been spending 
alot of time trying to find various way to get OF to work with 
anything non macos and its really quite a pain.  I HAVE been trying 
to do some things to fix it, I have given Ben alot of clues and 
information to help with this issue.   so why don't you stop your 
useless flaming.



Best Regards,
Ethan Benson
To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bypassing MacOS using Open Firmware on Apple pmac G3

[BenH]

On Fri, Oct 22, 1999, Ethan Benson <erbenson@alaska.net> wrote:

>excuse me?  OSX will not change the current OF that we have now which 
>is preventing a non macos bootstrap, OSX bootloader is not going to 
>load linux we still have to hack our own.  after OSX comes around 
>Apple's OF will likely stop being so bloody macos 8* specific. as I 
>believe is what peter meant. that does not change a damned thing for 
>all the broken machines we have now.

OS X comes with OF patches that improve greatly OF behavious on almost
all PCI macs. Those patches are under the Apple open source licence (I
think so but Peter can confirm, I don't have them with me now). And for
those machines for which we don't really care about OF (we don't really
need the OF phandle's on them and we don't have RTAS), then a BootX-like
solution is fine and easier to install and that's why I wrote miBoot. I
don't think creating an HFS filesystem is so complex, and we might simply
at first bundle a pre-formatted small image (large enough for miBoot and
new OF secondary loader). There is still the issue of miBoot requiring
the kernel to be on the HFS boot partition, I agree.

>I recall a thread on this list not too long ago where it was reported 
>that HFS.o needed to be modified or rewritten to be compatible with 
>the new kernel, just like every other filesystem, it was mentioned as 
>a concern because nobody seems to be maintaining the hfs filesystem 
>code. (or netatalk or anything else in the apple filesystem realm)

We still have the hfsutils if Adrian don't find time to fix in-kernel
HFS. With those we can still write an installer.

>bullshit, the current and past OF implemenatations have been causing 
>nothing but trouble for just about everything related to linux

Related to booting, perhaps. But not related to linux. The presence of
the device tree has been quite useful but Paul is in a better position to
comment on this.

>the more recent ones solve some problems but created new ones for the 
>bootstrap, Peter seems to agree with me that OF is broken in its boot 
>method as it creates headaches for OSX as well!  I have been spending 
>alot of time trying to find various way to get OF to work with 
>anything non macos and its really quite a pain.  I HAVE been trying 
>to do some things to fix it, I have given Ben alot of clues and 
>information to help with this issue.   so why don't you stop your 
>useless flaming.

I think we should simply stop this discussion until someone comes up with
real code. Once I have the iBook working enough, I'll resume my various
booter experiments, my goal is first to make bootable CDs for distros,
and then to make a decent Linux OF booter (eventually graphical) for new
OFs. Apple's new built-in boot chooser is fun but too limited for linux ;)


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bypassing MacOS using Open Firmware on Apple pmac G3

[Takashi Oe]

On Fri, 22 Oct 1999, Ethan Benson wrote:

[...]
> using HFS is not an option IMO because it must be created on macos, 
> unless someone wants to write a mkfs.hfs, didn't think so.  no thanks 
> I'll stick with a DOS partition that I can take care of in a total 
> Free environment rather then keeping macos around just to maintain 
> the bootloader.  (which is just as bad as using Bootx

You can use hformat from hfsutils to creat a HFS partition.  It works just
fine.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bypassing MacOS using Open Firmware on Apple pmac G3

[Martin Costabel]

On Fri, 22 Oct 1999, Ani Joshi wrote:

[...]
>         2.4?  if its 2.3 you mean, hfs works fine with the latest (2.3.22
> on my box is doing hfs fine), 
[...]

Amid all the shouting, no one seems to have picked up on this.

Are you serious about hfs running correctly in 2.3.22? If yes, this
would be a major breakthrough. What is your patch (certainly more than
just commenting out the undefined "update_vm_cache")?

If I cp anything to an hfs partition under 2.3.xx (xx >= 18), I get an
immediate system freeze without error message, and I have to force
reboot. Mounting hfs partitions read-only seems to work, though.

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bypassing MacOS using Open Firmware on Apple pmac G3

[Ani Joshi]

martin,
	actually, thats exactly all i had to do, funny eh?  got rid of the
update_vm_cache and its been working fine.  I've been using 2.3.22 for a
week or so now, built many kernels which i cp'd numerous times over to one
of my hfs partitions, played many hours of mp3's which reside on another
hfs partition, and i even might have done some deleting of files on my hfs
too.  not a single crash with 2.3.22 so far and my files on hfs aren't
corrupted (yet, heh)...


ani


On Thu, 28 Oct 1999, Martin Costabel wrote:

> [...]
> >         2.4?  if its 2.3 you mean, hfs works fine with the latest (2.3.22
> > on my box is doing hfs fine), 
> [...]
> 
> Amid all the shouting, no one seems to have picked up on this.
> 
> Are you serious about hfs running correctly in 2.3.22? If yes, this
> would be a major breakthrough. What is your patch (certainly more than
> just commenting out the undefined "update_vm_cache")?
>
> Martin
> 


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/