Voodooprojects
Chameleon => Feature Requests => Topic started by: FrodoKenny 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?
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.
-
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
-
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)?
-
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 ?
-
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
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.
-
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. ::)
-
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.
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
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"
-
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.
-
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
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
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
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
-
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.
-
That because they create IODT:/option in bootloader, so appleefinvram arent working at all.
-
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).
-
One more reason:
http://forum.voodooprojects.org/index.php/topic,200.0.html
-
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
-
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
-
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).
-
...
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).
-
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.
-
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 ^^