Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

lnx64

macrumors member
Original poster
Sep 6, 2019
47
13
I've angered the proto/dev MP3,1. I was attempting to dump the NVRAM contents in Linux, and the machine hard locked. When it rebooted, it did this: https://streamable.com/xy0em

When I pulled the power cord and waited 10 seconds and plugged it back in, all is well now and is booting back up just fine as if nothing happened. Have any retail machines done this? I found nothing on that beep code whatsoever, and my friend who worked at Apple doesn't think it's any beep code he's heard (but he worked in AppleCare and isn't familiar with this particular version of the MP3,1).

Can the NVRAM possibly be protected?

The command on Linux that triggered this response was:
sudo modprobe nvram
dd if=/dev/nvram of=~/nvram.bin
 
Last edited:
It hurts when I do this Doc.

Don't do this......😂
I was thinking along the lines of preserving history, to dump the NVRAM that makes this machine boot in debug mode, since no one had seen a Mac boot quite like this one being a non-retail unit. But oh well, if it won't let me do it, I guess I simply cannot preserve its contents.
 
I was thinking along the lines of preserving history, to dump the NVRAM that makes this machine boot in debug mode, since no one had seen a Mac boot quite like this one being a non-retail unit. But oh well, if it won't let me do it, I guess I simply cannot preserve its contents.
Do tell more of this debug mode you speak?
 
Do tell more of this debug mode you speak?
It boots straight to CSM, does not EFI boot, diagnostic LED's are always lit, and it's permanently set to boot to CD first then the HD, you can't change the boot order. If you boot with no HD connect and no CD, even on a standard PC video card, you will get a text mode representation of the folder with the ? on it, (in 80x25 custom characters, 1-bit mono, no graphical mode). The boot ROM itself however is the same as a retail machine, so as was suspected by tsialex, it must have something in the NVRAM that puts it in a special mode to do all this. (It even when booted into DOS has PC speaker sound on old DOS games, but that might be a logic board difference). When I worked at Apple it was a dev unit. It simply cannot in this mode, boot a retail version of OS X, and I wanted to try and preserve it for historical purposes.
 
It boots straight to CSM, does not EFI boot, diagnostic LED's are always lit, and it's permanently set to boot to CD first then the HD, you can't change the boot order. If you boot with no HD connect and no CD, even on a standard PC video card, you will get a text mode representation of the folder with the ? on it, (in 80x25 custom characters, 1-bit mono, no graphical mode). The boot ROM itself however is the same as a retail machine, so as was suspected by tsialex, it must have something in the NVRAM that puts it in a special mode to do all this. (It even when booted into DOS has PC speaker sound on old DOS games, but that might be a logic board difference). When I worked at Apple it was a dev unit. It simply cannot in this mode, boot a retail version of OS X, and I wanted to try and preserve it for historical purposes.
Pretty cool, but always booting into CSM mode stinks.

Likely you could use Clover Legacy as a boot loader, I've done this before on my 3,1, but that isn't really what you are asking.

Zapping the NVRAM puts the machine back it debug mode, so those must be loaded as the defaults. I know a great deal about how that works on PowerPC/Open Firmware Mac's, but relatively nothing about how Intel Mac's work on this level.

I think it would be worth finding out how the NVRAM defaults are set, and that would likely be the answer you are looking for.

So, where are the NVRAM defaults stored?

And, how are they restored when we invoke Command+OPT+P+R?
 
Pretty cool, but always booting into CSM mode stinks.

Likely you could use Clover Legacy as a boot loader, I've done this before on my 3,1, but that isn't really what you are asking.

Zapping the NVRAM puts the machine back it debug mode, so those must be loaded as the defaults. I know a great deal about how that works on PowerPC/Open Firmware Mac's, but relatively nothing about how Intel Mac's work on this level.

I think it would be worth finding out how the NVRAM defaults are set, and that would likely be the answer you are looking for.

So, where are the NVRAM defaults stored?

And, how are they restored when we invoke Command+OPT+P+R?
I'm honestly not quite familiar with the firmware structure. I'm more familiar with OS X as a whole (at least to Mavericks before I quit), than the firmware on it itself. I know the HD's it used to have before I had to give those back, had a custom bootloader that allowed it to boot OS X.

On Linux, the NVRAM is located at /dev/nvram, and using sudo modprobe nvram will grant you access to it, at least on any other system. But as soon as I try to read from it, the computer intentionally hard locks itself then spits out those beep codes.

I was hesitant to try command+option+p+r in case it removed the debug mode, but alas, it actually ignores it! It completely ignores command+option+p+r and instead will just continue booting up to a black screen with a blinking DOS like cursor, before the Windows logo appears. Holding Option (alt in my case since I use a Redragon keyboard) also yields nothing, it completely ignores key strokes at boot.

It sucks it can't run OS X, but truth be told, I only ever really used Apple's from G3's to G4's, and beyond that was a Linux/Windows user that just happened to have a MP3,1 from work, which has been my daily driving personal desktop. Attached are pics of the text mode VGA rendition of the no HD icon, which is comical because it's not polished whatsoever, no anti aliasing, and the always on diagnostic LED's in the memory cage.

I wish I knew more about the debug mode it's in, but since the logic board also differs slightly from a retail machine; being you most certainly would NOT hear these PC speaker sound effects in a DOS game booted to FreeDOS on ANY Mac whatsoever: https://streamable.com/h6qg1 , I fear that without being able to dump NVRAM, it might not be possible.
 

Attachments

  • 75412360_2520461564890495_2535130048764051456_n.png
    75412360_2520461564890495_2535130048764051456_n.png
    126 KB · Views: 144
  • diag.jpg
    diag.jpg
    275.8 KB · Views: 118
That's a shame. It's a lost cause then. I was hoping to help maybe archive a bit of history. If it's a prototype it's a blue board not a red board. If it's a debug/dev kit, it's unique with having the timers wired up to the speaker for PC speaker sound, once again not sure for what purpose though. I guestimate for post codes, like it beeped at me when trying to read NVRAM from Linux, which it clearly triggered some lock out.
 
That's a shame. It's a lost cause then. I was hoping to help maybe archive a bit of history. If it's a prototype it's a blue board not a red board. If it's a debug/dev kit, it's unique with having the timers wired up to the speaker for PC speaker sound, once again not sure for what purpose though. I guestimate for post codes, like it beeped at me when trying to read NVRAM from Linux, which it clearly triggered some lock out.

Maybe worth checking the source code for the Linux nvram module to see if there is anyway to debug it.
 
Maybe. For now it's my gaming rig. lol. I just beat Doom 2016 on it (good game, relentlessly hard though). I'm fairly surprise how it was pulling 100fps just fine while not utilizing the CPU's very much, Xeon X5482's ain't bad, especially since it IS overclocked as well.
 
I finally found a utility that would dump the NVRAM, on Windows without trigger the machine to going into panic mode. But the dump was only 128 bytes. Surely that doesn't sound right? EDIT: No, it's not, NVRAM is 32kbit, not 128 bytes. It failed to dump it properly, and probably just napped something else.
 

Attachments

  • cmos.png
    cmos.png
    49 KB · Views: 114
Last edited:
I had a success with the UEFI shell method.
[automerge]1576892084[/automerge]
As stated earlier, this particular unit does not EFI boot, therefore cannot gain access to the UEFI shell. It CSM boots only, and no Command Option P R reset does anything (it actually ignores them), it's in a permanent debugging mode state, which is why I want to try and dump the NVRAM, but unfortunately as far as I know, you cannot gain access to the UEFI shell from within the CSM.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.