Author Topic: NVRAM support  (Read 15138 times)

0 Members and 1 Guest are viewing this topic.

FrodoKenny

  • Observer
  • Posts: 10
Re: NVRAM support
« Reply #15 on: May 27, 2009, 11:13:13 AM »
could you give me a test case that i can use to verify that nvram works the way it is needed ?
my 10.5.7 seems to be able to use front row to play dvd just fine without nvram

If you have a RPC-2 drive, it uses that and the "Region-Changes" and "Region-Code" properties under /options are not used. So it only applies to RPC-1 drives, which need to support region-codes in "software". Btw, dvd player works because it saves them as preferences if it can't write to /options. Haven't tested it in 10.5.7 though, but this is the way it works in 10.5.6.
If you want to test if nvram is working, just use the command line tool:
  "nvram name=value" to set and
  "nvram -p" to check.
  "nvram -?" for more info
As said, these are not persistent accross reboots.


p.s. It will be fixed for the next release:
That's because Chameleon sets it (creates the /options node, you can check the FireWire thread), and again this is not SMUUID it is hardcoded in the booter which shouldn't happen, the booter shouldn't create the /options node in the first place (it creates issues, sometimes causes a kernel panic) because it's the job of AppleEFINVRAM.

This is a serious bug we knew and know about, but it went into the sources anyway. It is now been removed, so you shouldn't have issues with it in the next release(s).
« Last Edit: May 27, 2009, 11:17:51 AM by FrodoKenny »

Kabyl

  • VoodooLabs
  • Posts: 158
Re: NVRAM support
« Reply #16 on: May 27, 2009, 01:00:51 PM »
...
As said, these are not persistent accross reboots.


p.s. It will be fixed for the next release:
That's because Chameleon sets it (creates the /options node, you can check the FireWire thread), and again this is not SMUUID it is hardcoded in the booter which shouldn't happen, the booter shouldn't create the /options node in the first place (it creates issues, sometimes causes a kernel panic) because it's the job of AppleEFINVRAM.

This is a serious bug we knew and know about, but it went into the sources anyway. It is now been removed, so you shouldn't have issues with it in the next release(s).


I didn't say the next release will have NVRAM support, just to make it clear, so people don't get the wrong idea. It's true if you have NVRAM support the IOPlatformUUID can be stored there and used once it's set, that if you have persistent way to store the data (NVRAM) and have it saved across reboots, that's not as easy as you might think.

Keep in mind that the IOPlatformUUID is not set by AppleEFINVRAM, it's just stored in the NVRAM.

But, one could implement ways to get around this (fake NVRAM support), this feature may or may not be in the next release(s).
« Last Edit: May 27, 2009, 01:03:41 PM by Kabyl »

BladeRunner

  • Member
  • Posts: 88
Re: NVRAM support
« Reply #17 on: May 27, 2009, 05:30:10 PM »
It is my understanding that, at least on MBR drives, most of the first track is unused beyond the MBR itself.  I have seen other boot loaders that made use of portions of track zero (0) to store data for use across boot sessions.

Couldn't Chameleon use the same strategy for things like NVRAM support or last-boot-default feature? 

I know, easy for me to say since I am not on the development team. :)  Well, it's just a thought.
Base system: HP Pavilion P6340f Desktop  Intel� Core2Quad�  CPU: Speed: 2.66 GHz   Package: Socket 775 LGA:  L2 Cache 2 x 2048 KB  RAM : 8.0 GB:  DDR3

Disks : 2 eSATA @ 2 TB (hardware raid 1), NAS 4 x 2 TB raid 5 Display : 21" Samsung on EVGA GeForce 9400 GT - PCIe - 1900x1080  Keyboard/mouse :  USB connected  OS Version : 10.6.0 from retail DVD + SW update to 10.6.5 - Kernel:  Vanilla mach_kernel

fxtentacle

  • Entrant
  • Posts: 4
Re: NVRAM support
« Reply #18 on: May 29, 2009, 10:05:50 AM »
storing data in anywhere on the hdd using low level methods is dangerous, as explained earlier with the controller sample. if your commands to the hardware and os x's commands to the hardware get mixed up badly, you might end up overwriting random blocks on the hard drive. that, of course, will be unacceptable for most users.

i'm toying around with dumping the nvram into a file using a mac os x shutdown script. it gets dumped late enough to capture stuff like "efi-boot-device-data", however the SystemAudioVolume set by appleHdaController is lost.

for the nvram var=value command to work, you dont need a fully working nvram implementation. a dummy one that just reports "EFI_NOT_FOUND" every time will work just fine for that.

so i'm still waiting for a test case which needs persistence across reboots ^^