Contribute
Register

DSDT - what are the *essential* edits?

Status
Not open for further replies.
moshymoshy said:
So something IS writing to the BIOS then if it's resetting it default.

Why would Mac OS itself do this? It doesn't know anything about BIOS, being designed to sit on an EFI based system... it must be Chameleon doing it, no?

Sorry, I'm still not able to get my head round what mechanism is setting BIOSes back to their defaults if it isn't the user himself.
I've never heard about that a bootloader reset a Bios. I don't know how or why it happens but the fact is it's happening :)
 
moshymoshy said:
So something IS writing to the BIOS then if it's resetting it default.

Why would Mac OS itself do this? It doesn't know anything about BIOS, being designed to sit on an EFI based system... it must be Chameleon doing it, no?

Sorry, I'm still not able to get my head round what mechanism is setting BIOSes back to their defaults if it isn't the user himself.
There are 2 parts to the BIOS, the actual code and the settings. So the settings area can get corrupted as it is writable.

There is a know bug in the Gigabyte BIOSes and DSDTs that they finally started fixing in new releases as of I think April 2010. The issue is that in their DSDTs an IO resource descriptor has the wrong length defined. So when the OS writes to the IO resource it is overwriting something it shouldn't and causes the CMOS to get corrupted. You will only see this corruption at reboot and the computer will reboot with default BIOS settings. All of the Gigabyte DSDTs in the database have this fix implemented one way or the other.
 
That might explain the bad BIOS corruption problem I had on my l*pt*p then. I had tried to spin my own aml file. I did that in ignorance of the fact that it even had the capability of causing corruption. I thought it was more like a 'BIOS proxy'.

I had wrongly assumed that the UserDSDT process was idiot-safe, as in it was a runtime operation that couldn't have any ill effects except during the current OS execution.

Very informative, thanks.

Could an improper DSDT brick a motherboard for good then, just by running MultiBeast on it?
 
moshymoshy said:
Could an improper DSDT brick a motherboard for good then, just by running MultiBeast on it?
Not that I am aware of.
 
Status
Not open for further replies.
Back
Top