nvramrc modifications result in PowerBook G4 stuck in Open Firmware
Summary:
Let me provide a little backstory.
According to the [DARPA Visitor Guidelines|http://www.darpa.mil/body/visitor_guidelines.html] wireless network technology is prohibited from DARPA facilities. Laptops with a wireless card are required to be "disabled at the BIOS level".
Before an upcoming visit to DARPA I was told that I would need to make sure my laptop wireless card was disabled. I mentioned that Macs don't have BIOS but I'd look into doing it in Open Firmware. The response from DARPA was that no one has ever successfully brought an Apple laptop into the facility, and that I should procure a PC laptop for my visit. Ah, a challenge!
I booted into Open Firmware (⌘⌥OF), located the wireless card in the device tree, and removed two properties I figured the driver would be searching for: the vendor ID, and the product ID. I exited Open Firmware and continued to boot into Mac OS X v10.5.2.
Sure enough the System Profiler showed that no wireless card was installed. Success! Now I just need to make the device tree modifications persist between reboots.
It seemed the solution was to place the Open Firmware commands I issued to disable the card into nvramrc. So I set nvramrc to contain the same commands, and set use-nvramrc? to be true. I rebooted the machine but the card was still detected.
A bit [more research|http://docs.sun.com/app/docs/doc/805-4436/6j4719c8v?a=view] revealed that the device tree is not created by Open Firmware until after the nvramrc is executed. The solution is to build the device tree in the nvramrc and tell Open Firmware not to rebuild it. The documentation states that this is accomplished with the probe-all, install-console, and banner Forth commands. I added those commands to my nvramrc and rebooted. The contents of nvramrc:
-----
probe-all install-console banner
dev wireless
" device-id" delete-property
" vendor-id" delete-property
-----
The outcome... well technically the laptop has wireless disabled. Almost everything is disabled. The machine now boots directly into Open Firmware with a few ominous bits of output and no response from the keyboard.
-----
no active package
Apple PowerBook5,6 6.4.9.1f1 BootROM built on 01/21/05 at 10:51:16
Copyright 1994-2005 Apple Computer, Inc.
All Rights Reserved.
Welcome to Open Firmware, the system time and date is 05/06/2008 10:00:00
Command security mode
To continue booting, type "mac-boot" and press return.
To shut down, type "shut-down" and press return.
ok
0 > _
-----
The first sign that something has gone wrong is no active package. The second message just throws another wrench into the works: Command security mode. Yes, the Open Firmware password was enabled. In retrospect this was a bad thing to have set when mucking about in OF. I knew of the RAM change trick (see below) so this was not an issue at the time.
Question:
So the question is: What actions do I need to take to return the laptop to a useable state. That is, booting into Mac OS X.
*Attempted solutions:*
+1. Reset nvram+
The first and most obvious solution is to reset nvram using the snag key combination ⌘⌥PR. Unfortunately do to the firmware password being set, [all snag keys have been disabled|http://support.apple.com/kb/HT1352]. This means no target disk mode (⌘T), boot from CD (⌘C), boot from network (⌘N), etc... In any case an attempt at resetting nvram yields an additional message being appended to the Open Firmware screen:
Release keys to continue!_
+2. Reset nvram after changing amount RAM in system+
Luckily there is a work-around to firmware password protection. Changing the amount of RAM installed in the machine should allow the nvram zap snag to function. I removed one of the two 512MB DIMMS in the laptop and started up while holding down ⌘⌥PR. This results in the same message as above:
Release keys to continue!_
Not so lucky.
+3. Reset the Power Management Unit+
[Resetting the Power Management (PMU)|http://docs.info.apple.com/article.html?artnum=14449] is accomplished by removing the battery and disconnecting the power cord, and then holding down the power button for about 5 seconds. This had no effect besides resetting the system clock to 01/01/1904 00:00:41.
Getting more desperate...
+4. Search logic board for CUDA+
I [opened the machine|http://www.ifixit.com/Guide/Mac/PowerBook-G4-Al-15-Inch-1-5-1-67-BT-2-0 -LR/64] to search for a hidden [CUDA button|http://docs.info.apple.com/article.html?artnum=86760]. As expected, a CUDA button does not exist on this model and the PMU reset is accomplished as noted in attempted solution 3.
+5. Remove internal battery+
Well the laptop is open now, so I tried removing the internal memory backup battery and revisited each of the above solutions. No success.
+6. Remove hard drive+
Again, since the laptop was open, why not remove the hard drive and see what happens. The machine wasn't even making it to the boot-loader hand-off so I didn't expect this to produce any results. No results produced.
Thinking crazy thoughts...
+7. Attempt a firmware update+
Firmware updates have a side effect of resetting the nvram. Also firmware updates are initiated very early in the startup process by holding down the power button until a tone is heard and the power light flashes. My thought was that I would grab a previous firmware update for this laptop and force it to be reapplied. Unfortunately there have been no updates to this model's firmware.
+8. Write my own firmware update script+
While investigating solution #7 I realized that the file BootROMFirmware installed by the firmware updaters for G5s and G4s machines are just Forth programs with a binary payload attached to the end. I learned [Forth|http://en.wikipedia.org/wiki/Forth (programminglanguage)]. The BootROMFirmware files are really cool, since they do everything from drawing the progress bar during the update, uncompressing and check-summing the binary payload, and generally making sure you don't brick your machine. In any case it seem entirely doable to write my own program in Forth and undo the evil I did before. I really only need to flip one bit. I needed the use-nvramrc? variable set to false. So I created this very simple Forth program:
-----
\ debrickifier
setenv use-nvramrc? false
reset-all
-----
The original firmware file had additional attributes set, a creator and file type of fw99. So I set those two attributes on my file as well. I ran strings on the firmware installer program and guessed that it was copying the file to /System/Library/CoreServices. So this is where I placed my Forth file. Reinstalled the drive and rebooted the laptop while holding down the power key to initiate a firmware install. No dice.
Its hard to tell why this is failing. The file may in the wrong place, have the wrong permissions. From what I've reviewed in the original files, the setenv and reset-all words should be available. Maybe the Firmware Update utilities are setting some other magic in nvram before the reboot.
-----
I think I've covered all the different major solutions that I've attempted. Their might be a few more that I've forgotten to mention (like using an external USB keyboard). I still think that getting some Forth to execute via the firmware update mechanism could use some more exploration. My current worst case is that I'll replace the logic board, although I'd hate to do that when I know there are only a few bad bits flipped in a CMOS somewhere.
I'm posting this in the Unix group since there seems to be more knowledge of lower level system internals here, and I could not have accomplished all that I have done without the all-mighty command line. I'm hoping to snag the attention of the resident hardware/firmware guru that can shed some light upon the firmware update process, but any help or suggestions would be greatly appreciated.
Cheers,
Mark
Let me provide a little backstory.
According to the [DARPA Visitor Guidelines|http://www.darpa.mil/body/visitor_guidelines.html] wireless network technology is prohibited from DARPA facilities. Laptops with a wireless card are required to be "disabled at the BIOS level".
Before an upcoming visit to DARPA I was told that I would need to make sure my laptop wireless card was disabled. I mentioned that Macs don't have BIOS but I'd look into doing it in Open Firmware. The response from DARPA was that no one has ever successfully brought an Apple laptop into the facility, and that I should procure a PC laptop for my visit. Ah, a challenge!
I booted into Open Firmware (⌘⌥OF), located the wireless card in the device tree, and removed two properties I figured the driver would be searching for: the vendor ID, and the product ID. I exited Open Firmware and continued to boot into Mac OS X v10.5.2.
Sure enough the System Profiler showed that no wireless card was installed. Success! Now I just need to make the device tree modifications persist between reboots.
It seemed the solution was to place the Open Firmware commands I issued to disable the card into nvramrc. So I set nvramrc to contain the same commands, and set use-nvramrc? to be true. I rebooted the machine but the card was still detected.
A bit [more research|http://docs.sun.com/app/docs/doc/805-4436/6j4719c8v?a=view] revealed that the device tree is not created by Open Firmware until after the nvramrc is executed. The solution is to build the device tree in the nvramrc and tell Open Firmware not to rebuild it. The documentation states that this is accomplished with the probe-all, install-console, and banner Forth commands. I added those commands to my nvramrc and rebooted. The contents of nvramrc:
-----
probe-all install-console banner
dev wireless
" device-id" delete-property
" vendor-id" delete-property
-----
The outcome... well technically the laptop has wireless disabled. Almost everything is disabled. The machine now boots directly into Open Firmware with a few ominous bits of output and no response from the keyboard.
-----
no active package
Apple PowerBook5,6 6.4.9.1f1 BootROM built on 01/21/05 at 10:51:16
Copyright 1994-2005 Apple Computer, Inc.
All Rights Reserved.
Welcome to Open Firmware, the system time and date is 05/06/2008 10:00:00
Command security mode
To continue booting, type "mac-boot" and press return.
To shut down, type "shut-down" and press return.
ok
0 > _
-----
The first sign that something has gone wrong is no active package. The second message just throws another wrench into the works: Command security mode. Yes, the Open Firmware password was enabled. In retrospect this was a bad thing to have set when mucking about in OF. I knew of the RAM change trick (see below) so this was not an issue at the time.
Question:
So the question is: What actions do I need to take to return the laptop to a useable state. That is, booting into Mac OS X.
*Attempted solutions:*
+1. Reset nvram+
The first and most obvious solution is to reset nvram using the snag key combination ⌘⌥PR. Unfortunately do to the firmware password being set, [all snag keys have been disabled|http://support.apple.com/kb/HT1352]. This means no target disk mode (⌘T), boot from CD (⌘C), boot from network (⌘N), etc... In any case an attempt at resetting nvram yields an additional message being appended to the Open Firmware screen:
Release keys to continue!_
+2. Reset nvram after changing amount RAM in system+
Luckily there is a work-around to firmware password protection. Changing the amount of RAM installed in the machine should allow the nvram zap snag to function. I removed one of the two 512MB DIMMS in the laptop and started up while holding down ⌘⌥PR. This results in the same message as above:
Release keys to continue!_
Not so lucky.
+3. Reset the Power Management Unit+
[Resetting the Power Management (PMU)|http://docs.info.apple.com/article.html?artnum=14449] is accomplished by removing the battery and disconnecting the power cord, and then holding down the power button for about 5 seconds. This had no effect besides resetting the system clock to 01/01/1904 00:00:41.
Getting more desperate...
+4. Search logic board for CUDA+
I [opened the machine|http://www.ifixit.com/Guide/Mac/PowerBook-G4-Al-15-Inch-1-5-1-67-BT-2-0 -LR/64] to search for a hidden [CUDA button|http://docs.info.apple.com/article.html?artnum=86760]. As expected, a CUDA button does not exist on this model and the PMU reset is accomplished as noted in attempted solution 3.
+5. Remove internal battery+
Well the laptop is open now, so I tried removing the internal memory backup battery and revisited each of the above solutions. No success.
+6. Remove hard drive+
Again, since the laptop was open, why not remove the hard drive and see what happens. The machine wasn't even making it to the boot-loader hand-off so I didn't expect this to produce any results. No results produced.
Thinking crazy thoughts...
+7. Attempt a firmware update+
Firmware updates have a side effect of resetting the nvram. Also firmware updates are initiated very early in the startup process by holding down the power button until a tone is heard and the power light flashes. My thought was that I would grab a previous firmware update for this laptop and force it to be reapplied. Unfortunately there have been no updates to this model's firmware.
+8. Write my own firmware update script+
While investigating solution #7 I realized that the file BootROMFirmware installed by the firmware updaters for G5s and G4s machines are just Forth programs with a binary payload attached to the end. I learned [Forth|http://en.wikipedia.org/wiki/Forth (programminglanguage)]. The BootROMFirmware files are really cool, since they do everything from drawing the progress bar during the update, uncompressing and check-summing the binary payload, and generally making sure you don't brick your machine. In any case it seem entirely doable to write my own program in Forth and undo the evil I did before. I really only need to flip one bit. I needed the use-nvramrc? variable set to false. So I created this very simple Forth program:
-----
\ debrickifier
setenv use-nvramrc? false
reset-all
-----
The original firmware file had additional attributes set, a creator and file type of fw99. So I set those two attributes on my file as well. I ran strings on the firmware installer program and guessed that it was copying the file to /System/Library/CoreServices. So this is where I placed my Forth file. Reinstalled the drive and rebooted the laptop while holding down the power key to initiate a firmware install. No dice.
Its hard to tell why this is failing. The file may in the wrong place, have the wrong permissions. From what I've reviewed in the original files, the setenv and reset-all words should be available. Maybe the Firmware Update utilities are setting some other magic in nvram before the reboot.
-----
I think I've covered all the different major solutions that I've attempted. Their might be a few more that I've forgotten to mention (like using an external USB keyboard). I still think that getting some Forth to execute via the firmware update mechanism could use some more exploration. My current worst case is that I'll replace the logic board, although I'd hate to do that when I know there are only a few bad bits flipped in a CMOS somewhere.
I'm posting this in the Unix group since there seems to be more knowledge of lower level system internals here, and I could not have accomplished all that I have done without the all-mighty command line. I'm hoping to snag the attention of the resident hardware/firmware guru that can shed some light upon the firmware update process, but any help or suggestions would be greatly appreciated.
Cheers,
Mark
Aluminum 15" PowerBook G4 (low-res) PowerBook5,6, Mac OS X (10.5.2), Logic Board 820-1679-A
