Apple

does someone know where is stored the MAC-address on the Pbook's motherboard ?
I mean which chip, and it's position on the motherboard, as I can't locate it

thank you

p.s.
it's the last PowerBook-G4 made by Apple before they switched into x86

I have one, but it is currently in use and can't be taken apart.
I believe it is stored in the 28F008, but this might be wrong.

If all you want is to change the MAC, this can be done from software by copying the driver and editing it. Then you force the real driver to unload and load the copy.

yes, I need to change it, but I need to make it permanently changed.

Then I think you need to write to the flash. In these machines the flash is writeable if the CPU maps its physical region. So if you open /dev/mem at 0xFFF0,0000 and dump it to a file, and search for the MAC address (which will be "prop-encoded"), you could change it by writing a different address back (also "prop-encoded"). The property is readable from Open Firmware at
dev /enet .properties
called "local-mac-address". I don't know how to set this from Open Firmware, it may not be easy to do.

It goes without saying that writing to the flash can brick the machine. There is also an area of a 28F008 that is treated as NVRAM and it might be in that area, although it is not in any of the exposed nvram variables.

Another idea is that if you wrote FCode that set the MAC address at boot time, it might or might not be honored by the system (it depends on order of execution of the boot options). You would put the FCode to do this in the nvram variable "nvramrc". It would be permanent in the sense of always being run before loading the OS, but without changing the firmware directly.

You would do something similar to (check this):

or perhaps this: [fixed a bug]

thank you

OK, I was able to restart and test whether this works:
Short answer: it doesn't.
The escaped double-quotes in the version supra cause problems with csh (it complains they don't balance). With ksh they work ok. You can force them to work in tcsh with the backslash_quote shell variable. But using single-quotes is a cleaner solution (but see infra ).
Setting the " local-mac-address" property in the enet package works from the Open Firmware prompt, but vagaries of the probing process overwrite the property if done from nvramrc.
You can get an idea of the process from Oracle docs.
http://docs.oracle.com/cd/E19620-01/805 ... index.html
(although banner and suppress-banner don't seem to be defined in Apple's FCode, so there appears to be no way to override the probe steps)

I still couldn't get it to work from nvramrc, so I wrote a test:

If you drop to Open Firmware console by holding Command-Option-O-F during the boot chime, you can see that the nvramrc has already run:

But there was no property to use then:

If we run it again now, the property is there:


The problem is that when nvramrc runs, there is no mac-address property yet, because the enet device hasn't been probed. If we probe it ourselves the device tree gets messed up when OF does it again (tried that, OSX hangs on boot). What we need is to force some code to be run later, after probing is complete (when the console would be able to do it interactively).
The way that you continue booting OSX from the OF console is typing mac-boot. You can see what it does, funny enough, with the see word:

A clue! interesting. We can change what happens when mac-boot runs since it is dynamic. It runs after all the probing and device init is done, after the console exits. But we still want that original code to run when we are finished for the OS to load.

(Notice the switch from single-quoting to double-quoting for the shell's sake.)
I tested this and it works.

Nicely done!

ClassicHasClass wrote: Nicely done!

Thanks, it was fun (and a dozen restarts). Apple OpenFirmware docs aren't much use, but Sun's OpenBoot 3 docs are very helpful.

yup, super