overdue-scratch

Author Topic: NVRAM support  (Read 14098 times)

0 Members and 1 Guest are viewing this topic.

FrodoKenny

  • Observer
  • Posts: 10
NVRAM support
« on: April 08, 2009, 11:44:32 AM »
From the comments:

On EFIv9 it is possible to write to NVRAM (under IODeviceTree:/options). This is needed for Front Row to able to play DVDs (it needs to find the regions code keys there). I guess this is one for the next version?

May be related to this?

Quote
CAINE · 11. JANUARY 2009, 23:55 · #

@zef
What about nvram saving support in stage 2 boot? It could be helpful for saving keyboard layout, set boot options, choosing boot volume (at least within same hdd), maybe it could resolve some uuid problems etc..
All you need (as I think:)) is to handle efiRuntimeServices->SetVariable and efiRuntimeServices->GetVariable in fake_efi.c and read/store data to some file on disk.
It would be nice if you add this feature to next release.

mackerintel

  • VoodooLabs
  • Posts: 38
Re: NVRAM support
« Reply #1 on: April 09, 2009, 09:03:07 AM »
Between the developers we have discussed this matter and have concluded that this feature and concluded that instability introduced by this feature (it may corrupt your filesystem. "just write to file" isn't possible) and the hassle to implement it by far outweight the advantages. The DVD-fix is probably a workaround and such workaround will be added

FrodoKenny

  • Observer
  • Posts: 10
Re: NVRAM support
« Reply #2 on: April 09, 2009, 01:38:38 PM »
Thanks for the info. I can understand the reasoning.
Does the DVD-fix mean the variables can be saved but are not persistent between reboots (as with efiv9 now)?


cparm

  • Observer
  • Posts: 12
Re: NVRAM support
« Reply #3 on: April 09, 2009, 09:24:43 PM »
Between the developers we have discussed this matter and have concluded that this feature and concluded that instability introduced by this feature (it may corrupt your filesystem. "just write to file" isn't possible) and the hassle to implement it by far outweight the advantages. The DVD-fix is probably a workaround and such workaround will be added

hi, makerintel, i have 2 question:

1 pc_efi 9 support nvram, is pc_efi 9 affected by this instability ?

2 what kind of filesystem corruption, sometime, in single user mode, when i run fsck_hfs -fyrd /dev/rdisk*s*, standard output report that catalog file of the startup disk can't be rebuild, is that kind of corruption ?
« Last Edit: April 10, 2009, 12:21:48 PM by cparm »

mackerintel

  • VoodooLabs
  • Posts: 38
Re: NVRAM support
« Reply #4 on: April 10, 2009, 09:38:53 PM »
1 pc_efi 9 support nvram, is pc_efi 9 affected by this instability ?
AFAIK it doesn't, it just workarounds the absence of nvram by adding some values in the device tree
Quote
2 what kind of filesystem corruption, sometime, in single user mode, when i run fsck_hfs -fyrd /dev/rdisk*s*, standard output report that catalog file of the startup disk can't be rebuild, is that kind of corruption ?
It can be any FS corruption. The problem is that fake_efi is under the FS and disk drivers. If it implements its own fs driver then it may easily corrupt your FS because of the lack of coordination with normal driver. If you want to call normal FS/disk functions a far better way is to do a kext. But kexts are outside of the scope of chameleon.

zhell

  • Member
  • Posts: 46
Re: NVRAM support
« Reply #5 on: April 11, 2009, 12:32:47 AM »
So if I get that right, you are suggesting someone write a KEXT that inserts the NVRAM device into the tree and provides a back end that reads from and writes to some file, leisurely using the system's filesystem driver?

Since the booter determines the set of KEXTs that get loaded first, one could even ensure that NVRAM.kext be  among the first kids on the block, no?

Very well then, should be a fun project to learn programming KEXTs for someone interested in NVRAM support.  ::)

mackerintel

  • VoodooLabs
  • Posts: 38
Re: NVRAM support
« Reply #6 on: April 11, 2009, 02:17:19 AM »
So if I get that right, you are suggesting someone write a KEXT that inserts the NVRAM device into the tree and provides a back end that reads from and writes to some file, leisurely using the system's filesystem driver?
It's not as easy as it sounds. OSX drivers assume that nvram can always be used. So in this logic using nvram from fs driver is ok. However with the kext it will cause an infinite loop. Another possibility is a system crash. In this even kernel tries to write panic log to nvram. But if crashed driver is disk driver calling its functions on this stage may both corrupt your FS and triple fault.
Quote
Since the booter determines the set of KEXTs that get loaded first, one could even ensure that NVRAM.kext be  among the first kids on the block, no?
Just put it into Extra.mkext. But the actual load order isn't determined by bootloader but by iokit

Quote
Very well then, should be a fun project to learn programming KEXTs for someone interested in NVRAM support.  ::)
IMHO it's not worth the hassle. I didn't say impossibl, just "not worht it"

zhell

  • Member
  • Posts: 46
Re: NVRAM support
« Reply #7 on: April 12, 2009, 09:29:38 AM »
Thanks for your thoughts, mackerintel.

I hope I do not get on anyone's nerves here, otherwise please tell me or stop reading :-)

Oone way out of this fixture without risking filesystem corruption could be a separate 8MB partition, or even better, a USB stick. I have in mind something similar to the swap partition under linux, where a signature allows to quite reliably identify the partition/disk.

The approach would be for the kext to access its partition in a similar fashion as AppleFlashNVRAM accesses its NVRAM chip. This means that NVRAM data is essentially kept in DRAM until either it changes, the machine shuts down, or there is a kernel panic.
« Last Edit: April 12, 2009, 11:41:36 AM by zhell »

mackerintel

  • VoodooLabs
  • Posts: 38
Re: NVRAM support
« Reply #8 on: April 12, 2009, 01:45:37 PM »
Oone way out of this fixture without risking filesystem corruption could be a separate 8MB partition,
No good actually. The problem is that both OSX and your fake_efi send commands to your HD controller. I'm not familiar with ata but what is hard to avoid is that if OSX sends commands like:
Go to sector X1
Write Y1
And fake_efi sends
Go to sector X2
Write Y2
But it may happen that OSX sends its commands between the commands (e.g. running from another CPU) of fake_efi. You get:
Go to sector X1
Go to sector X2
Write Y2
Write Y1
This way fake_efi overwrites a useful file
Quote
or even better, a USB stick.
How do you prevent OSX from accessing this stick. Even if you do you have the same issue as previously just this time with usb controller. It means that data on any USB drive isn't safe anymore
Quote
I have in mind something similar to the swap partition under linux, where a signature allows to quite reliably identify the partition/disk.
You can check whatever you want, it doesn't prevent race conditions on controllers
Quote
The approach would be for the kext to access its partition in a similar fashion as AppleFlashNVRAM accesses its NVRAM chip. This means that NVRAM data is essentially kept in DRAM until either it changes, the machine shuts down, or there is a kernel panic.
This is handled by OSX, not EFI. EFI just writes/reads NVRAM

FrodoKenny

  • Observer
  • Posts: 10
Re: NVRAM support
« Reply #9 on: April 14, 2009, 10:13:59 AM »
AFAIK it doesn't, it just workarounds the absence of nvram by adding some values in the device tree

You can also add values to the nvram with PCEFI v9, by adding values to IODeviceTree/options or using the nvram command line tool. They are not saved after a reboot, but with chameleon it is not possible to add nvram values at all.


netkas

  • Entrant
  • Posts: 4
Re: NVRAM support
« Reply #10 on: April 16, 2009, 06:02:18 AM »
That because they create IODT:/option in bootloader, so appleefinvram arent working at all.

FrodoKenny

  • Observer
  • Posts: 10
Re: NVRAM support
« Reply #11 on: April 16, 2009, 09:10:34 AM »
That because they create IODT:/option in bootloader, so appleefinvram arent working at all.

I thought so. So what would be needed to support AppleEFINVRAM is to implement efiRuntimeServices->SetVariable and efiRuntimeServices->GetVariable in fake_efi.c?
I agree that saving them to disk is risky, but at least they could be kept in memory. That way I can set the needed variables myself each time after reboot (which is what I'm doing now with PCEFIv9) to allow Front Row to work (and dvd player and some others I think).

FrodoKenny

  • Observer
  • Posts: 10
Re: NVRAM support
« Reply #12 on: April 21, 2009, 09:35:23 AM »

Eps

  • Entrant
  • Posts: 7
Re: NVRAM support
« Reply #13 on: May 21, 2009, 11:19:25 AM »
Without this feature and we may have never seen "Installation Completed" from retail install DVD.

Can't access "efi-boot-device" NVRAM variable
Error setting the Startup Disk.
Could not set boot device property: 0xe00002c7

then installation failed. :P

fxtentacle

  • Entrant
  • Posts: 4
Re: NVRAM support
« Reply #14 on: May 26, 2009, 07:02:47 PM »
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