PowerMac G3 Beige Status

[J.C. Roberts-3]

According to INSTALL.macppc, page 5 (yes, I printed it), "PowerMac G3
Beige status is unknown.

This won't be the case for long...

From what I've read, normal booting to the CD is just not supported. To
be specific, booting to the CD requires a boot loader off of the hard
drive according to the claims I've read. The Open Firmware (rev 2.4)
seems to support this claim since using `devalias` shows no CD, and
using the typical boot-holding-C only spins up the CDROM drive, without
actually booting to it.

Attempting to netboot fails
        > boot enet:,ofwboot /bsd.rd
        > boot enet:,ofwboot /bsd.rd BOOTP failed
        unable to open: enet:,ofwboot

It does light up the 10base LED on the switch, but that's about it.

The tftpd server is set up and works fine (tested via IP and tftp(1)
from another box). I even tried using a cross-over cable but the mac
still refuses to play nice.

This leaves me a few choices (raw writing):
1.) the hard drive
2.) the zip drive
3.) the floppy drive

I created a ffs formated floppy, copied the ofwboot file onto it and
tried to see if the firmware would read it.

        > boot fd:,ofwboot
        ok

But without a kernel small enough to fit on the floppy, I'm stuffed.

Thoughts?

--
J.C. Roberts

[Jonathan Gray]

Looks like you need to be using boot.mac not ofwboot
going by gwk's oldworld article:

http://undeadly.org/cgi?action=article&sid=20061209032245&mode=expanded

INSTALL.macppc should really document the purpose of boot.mac...

On Mon, Mar 09, 2009 at 04:27:27AM -0700, J.C. Roberts wrote:

> According to INSTALL.macppc, page 5 (yes, I printed it), "PowerMac G3
> Beige status is unknown.
>
> This won't be the case for long...
>
> >From what I've read, normal booting to the CD is just not supported. To
> be specific, booting to the CD requires a boot loader off of the hard
> drive according to the claims I've read. The Open Firmware (rev 2.4)
> seems to support this claim since using `devalias` shows no CD, and
> using the typical boot-holding-C only spins up the CDROM drive, without
> actually booting to it.
>
> Attempting to netboot fails
> > boot enet:,ofwboot /bsd.rd
> > boot enet:,ofwboot /bsd.rd BOOTP failed
> unable to open: enet:,ofwboot
>
> It does light up the 10base LED on the switch, but that's about it.
>
> The tftpd server is set up and works fine (tested via IP and tftp(1)
> from another box). I even tried using a cross-over cable but the mac
> still refuses to play nice.
>
> This leaves me a few choices (raw writing):
> 1.) the hard drive
> 2.) the zip drive
> 3.) the floppy drive
>
> I created a ffs formated floppy, copied the ofwboot file onto it and
> tried to see if the firmware would read it.
>
> > boot fd:,ofwboot
> ok
>
> But without a kernel small enough to fit on the floppy, I'm stuffed.
>
> Thoughts?
>
> --
> J.C. Roberts

[SebastianR]

On Monday 09 March 2009 12:27:27 pm you wrote:

> According to INSTALL.macppc, page 5 (yes, I printed it), "PowerMac G3
> Beige status is unknown.
>
> This won't be the case for long...
>
> From what I've read, normal booting to the CD is just not supported. To
> be specific, booting to the CD requires a boot loader off of the hard
> drive according to the claims I've read. The Open Firmware (rev 2.4)
> seems to support this claim since using `devalias` shows no CD, and
> using the typical boot-holding-C only spins up the CDROM drive, without
> actually booting to it.
>
> Attempting to netboot fails
>
> > boot enet:,ofwboot /bsd.rd
> > boot enet:,ofwboot /bsd.rd BOOTP failed
>
> unable to open: enet:,ofwboot
>
> It does light up the 10base LED on the switch, but that's about it.

I tried the same some months ago, and I got the install kernel booted from the
network, up to the point, where it asked what to do, e.g. install, upgrade or
shell.However, whatever I chose, after hitting the button, the box froze.
I had to define some addresses to make the thing boot, and IIRC I had to use
the ofwboot or boot.mac from netbsd, that worked, the other not.
I don't think my setup here still exists, so that I can just try booting and
take a look again.
you may take a look here:
http://marc.info/?l=openbsd-ppc&m=122997517907748&w=2

I also tried to load an ordinary kernel, but that one froze when it tried to
access the hard disk, checking for the root file system....
On the disk there is nothing on it, and I don't have another scsi box here,
where I could put sth. on it.

If you find a way to get obsd running, also only if network boot and nfs-root
filesyste, let me know, I'm still interested to get my box running too.  ;)

hth
Sebastian

>
> The tftpd server is set up and works fine (tested via IP and tftp(1)
> from another box). I even tried using a cross-over cable but the mac
> still refuses to play nice.
>
> This leaves me a few choices (raw writing):
> 1.) the hard drive
> 2.) the zip drive
> 3.) the floppy drive
>
> I created a ffs formated floppy, copied the ofwboot file onto it and
> tried to see if the firmware would read it.
>
> > boot fd:,ofwboot
>
> ok
>
> But without a kernel small enough to fit on the floppy, I'm stuffed.
>
> Thoughts?

[J.C. Roberts-3]

On Mon, 9 Mar 2009 23:43:59 +1100 Jonathan Gray <jsg@...> wrote:

> Looks like you need to be using boot.mac not ofwboot
> going by gwk's oldworld article:
>
> http://undeadly.org/cgi?action=article&sid=20061209032245&mode=expanded
>
> INSTALL.macppc should really document the purpose of boot.mac...

Thanks. It's an interesting article *but* ...

        For instance on my machines the only change required is to tweak
        real-base,

        0 > setenv real-base F000000
        0 > reset-all


I *think* the above, quoted exactly from the article, has an extra zero?

By attempting the above, the system rebooted, and came up with a
black screen. Typical CMD-ALT-O-F access to OF doesn't work now.

Attempting to reset the PRAM via CMD-ALT-P-R doesn't work.

I pulled the power cord and battery, then held down the system power
button for a while to drain the caps. Then I let it sit for an hour to
make sure it was completely dead (time mostly desperately spent looking
for an answer). After all this, another attempt at resetting the PRAM
worked with the CMD-ALT-P-R.

I made a second attempt at `setenv real-base F000000` with the same
black screen effect. So far I've been unable to revive it with the
above method. It might be that I'm just too impatient and not waiting
long enough.

I'm guessing it's a PMU (Power Management Unit) issue.
http://support.apple.com/kb/HT1939

Subsequently, I've found the battery is nearly dead, so I'll get a
replacement before I start messing with this again.


--
J.C. Roberts

[gwk-3]

Yes there is an extra 0 there that shouldn't be, however I don't know  
if that setting is relevant to your version of
openfirmware I have only ever tested a 9500 and 9600 which I believe  
are version 1.0.5. The best reference your going to find is likely the  
netbsd old world mac pages.

I have been busy lately but getting the old world macs to boot off the  
internal disk was really high on my priority list
I might return to this later in April, can't hack on it when I please  
right now because the 3 year old PC that served as nfs/tftp for the 12  
year old macs
died (oh the irony).

gwk

On Mar 10, 2009, at 9:00 AM, J.C. Roberts wrote:

> On Mon, 9 Mar 2009 23:43:59 +1100 Jonathan Gray <jsg@...> wrote:
>
>> Looks like you need to be using boot.mac not ofwboot
>> going by gwk's oldworld article:
>>
>> http://undeadly.org/cgi?action=article&sid=20061209032245&mode=expanded
>>
>> INSTALL.macppc should really document the purpose of boot.mac...
>
> Thanks. It's an interesting article *but* ...
>
> For instance on my machines the only change required is to tweak
> real-base,
>
> 0 > setenv real-base F000000
> 0 > reset-all
>
>
> I *think* the above, quoted exactly from the article, has an extra  
> zero?
>
> By attempting the above, the system rebooted, and came up with a
> black screen. Typical CMD-ALT-O-F access to OF doesn't work now.
>
> Attempting to reset the PRAM via CMD-ALT-P-R doesn't work.
>
> I pulled the power cord and battery, then held down the system power
> button for a while to drain the caps. Then I let it sit for an hour to
> make sure it was completely dead (time mostly desperately spent  
> looking
> for an answer). After all this, another attempt at resetting the PRAM
> worked with the CMD-ALT-P-R.
>
> I made a second attempt at `setenv real-base F000000` with the same
> black screen effect. So far I've been unable to revive it with the
> above method. It might be that I'm just too impatient and not waiting
> long enough.
>
> I'm guessing it's a PMU (Power Management Unit) issue.
> http://support.apple.com/kb/HT1939
>
> Subsequently, I've found the battery is nearly dead, so I'll get a
> replacement before I start messing with this again.
>
>
> --
> J.C. Roberts

[J.C. Roberts-3]

On Wed, 11 Mar 2009 11:24:30 -0600 Gordon Willem Klok <gwk@...>
wrote:

> Yes there is an extra 0 there that shouldn't be, however I don't
> know if that setting is relevant to your version of
> openfirmware I have only ever tested a 9500 and 9600 which I believe  
> are version 1.0.5. The best reference your going to find is likely
> the netbsd old world mac pages.
>
> I have been busy lately but getting the old world macs to boot off
> the internal disk was really high on my priority list
> I might return to this later in April, can't hack on it when I
> please right now because the 3 year old PC that served as nfs/tftp
> for the 12 year old macs
> died (oh the irony).
>
> gwk

I suspect the "fatal-ish" black screen problem is caused by a
combination of things... The interaction of setting the load-base out
of spec and a slowly failing battery resulted in garbage getting saved,
temporarily, where settings should have been. This in turn wreaked
havoc on the PMU (Power Management Unit) which controls video output
to some degree and has plenty of known issues (particularly on systems
with integrated displays like G3 Beige AIO "All In One" and G4 iMac
models).

Unplugging everything including the dying batter for a night, then
replacing the battery with a new one, and resetting the PRAM and PMU
solved the black screen problem.

I've been reading the NetBSD old-world mac pages diligently. They are
taking an approach which basically *requires* having MacOS around to
use the "System Disk" application to add firmware patches to NVRAM. If
I've read things correctly, using "System Disk" may also a prerequisite
for running MacOS 10.x. These firmware patches, at present, are fairly
unknown (at least to me), and figuring them out will require reverse
engineering the "System Disk" application.

Without the "System Disk" firmware patches, my G3 Beige with OFW 2.4
refuses to load the NetBSD XCOFF loader (ofwboot.xcf), regardless of
firmware settings (load-base, real-base, etc). It always dies with
"CLAIM failed" errors, and yes, I know that error requires a `reset-all`
afterwards. Our "boot.mac" loader has the same error, again regardless
of settings, and I've tried tons of combinations. --With all the
resetting, I've nearly gone so far as to unplug the speaker so I don't
have to keep hearing the damn apple startup sound. :-)

The OpenFirmware versions 2.0.x and 2.4 (possibly others?) have *some*
type of support for loading ELF, but no one has ever gotten it to work
as far as I can tell. Since we can patch the firmware via NVRAM,
getting ELF support to work might be feasible.

The OpenFirmware 3.0 version (mistakenly?) can be over written
(typically destroyed), but it makes me wonder if this (mis)feature is
somehow available in 2.x and whether or not it could be used to fix
firmware bugs.

I'll need to think about this whole thing...

--
J.C. Roberts