Jump to content

SMC Emulation in DSDT

EncryptedSoul

By EncryptedSoul,
in General Discussion

 Share
47 posts in this topic

Recommended Posts

EncryptedSoul
EncryptedSoul
Posted
  • Author
Posted
If it is so easy I hope to see such an emulation by you soon :)

I did not say it would be easy. However I'm not going to condemn the project by saying it can't be done...

 

Anything is possible.

 

By the way, if we aren't "exactly" "emulating" the smc device, what would the proper terminology be to use? I'm confused because you stated that you are "emulating" a smc device in your dsdt patcher thread. :D

 

having the battery meter to show up is just a matter of putting smb0 device in dsdt as I did in the post I linked... the problem is I didn't succeed in making it show anything useful at that time but I didn't test much... indeed I'm not really confident with dsdt coding and maybe somebody who's more 'expert' could point out if this is even possible or not...

 

btw tomorrow I'll try to modify the original mb's dsdt to send requests to the emulated smb0 and to make the smb0 device reply with the correct values.. I'll report if this works but as I stated I'm not confident at all with dsdt stuff so I'm actually just guessing.. any advice would be appreciated :)

That's the thing about dsdt. I don't think it can react to change's on the fly. It's a file that is implemented during boot, kinda like an image of the computer, if you will, and has no interaction there after. So the battery status might be a challenge, however I know there is interaction with hardware as it loads because of else. I'm sure you can have it load things to memory addresses.

 

EDIT: Memory is pluggable by adding custom data to dsdt under Scope (\_SB). You can add memx, keyx, oskx and assign memory values in memory slots that don't even exist. I did a test, my board supports 4gig, yet I have os x recognizing 8gig!!! This is cool... Let me see just what I can do here.

 

The Linux dudes are dsdt gods!

Link to comment
Share on other sites
EncryptedSoul
EncryptedSoul
Posted
  • Author
Posted
A simple question that comes to my mind is: Why?

dsmos or appledecrypt do the job, so what will are the benefits from this approach?

 

Well.... For starters it will help further a vanilla setup. Why do we go thru all this trouble figuring out how to move things to a hidden efi partition in a gpt partitioned drive, load extra folders, use external mkexts, edit bootloaders with fake efi implementation, load dsdt file, etc? If we achieve this in dsdt, we can then hardcode it into bios images. A non apple mobo that can dongle itself to mac os x is enough motivation for me to want to get'er done!

 

I can keep going but I think I made a valid point.

Link to comment
Share on other sites
Kabyl
Kabyl
Posted
Posted
Read the decrypt.txt file in the OSx86_SourceCode folder and you will have the answer.

 

Cheers

That thing is like more than a year old, so you mean there is nothing "new" in what you're using?

 

EDIT: checked the Decrypt.txt file again, it's not even what people are using now, it's the older obsolete method.

Link to comment
Share on other sites
Kabyl
Kabyl
Posted
Posted
So is trolling around something you do on the regular?

 

I asked a question, you either have and can answer it, or you can't.

 

It sounded like a "new" and better method, what's wrong with asking?

Link to comment
Share on other sites
sonotone
sonotone
Posted
Posted
Well.... For starters it will help further a vanilla setup. Why do we go thru all this trouble figuring out how to move things to a hidden efi partition in a gpt partitioned drive, load extra folders, use external mkexts, edit bootloaders with fake efi implementation, load dsdt file, etc? If we achieve this in dsdt, we can then hardcode it into bios images. A non apple mobo that can dongle itself to mac os x is enough motivation for me to want to get'er done!

 

I can keep going but I think I made a valid point.

 

Humm... like you, i'm convinced that DSDT can do many things, adding fix that can't be done with injectors, but it's clearly not designed for starters: not universal, complex to understand/edit, less flexible... and sometimes, injectors or drivers are doing better job (like krazubu's NVEnabler for Nvidia graphics).

And i'm agree with you about efi partition, in most of cases it's useless, just because some people want to think that OSX is unmodified, witch is not true. to my opinion, considering DSDT in this way take part of the same illusion.

Link to comment
Share on other sites
EncryptedSoul
EncryptedSoul
Posted
  • Author
Posted
Humm... like you, i'm convinced that DSDT can do many things, adding fix that can't be done with injectors, but it's clearly not designed for starters: not universal, complex to understand/edit, less flexible... and sometimes, injectors or drivers are doing better job (like krazubu's NVEnabler for Nvidia graphics).

And i'm agree with you about efi partition, in most of cases it's useless, just because some people want to think that OSX is unmodified, witch is not true. to my opinion, considering DSDT in this way take part of the same illusion.

 

Well to have someone make an additional kext to work with, or work in place of a stock kext is along the lines of a patch. Getting OS X to run on an AMD machine is the true definition of a "patch"!!! However to prpoperly fill out a system description table so the operating system know's the configuration it is dealing with is not a patch. The EULA agreement is broken everytime you add something, alter or modify anything in the stock os. Adding the aml file is a patch, but flashing the bios with a more complete table of info is not a patch. It's why you pay so much for an apple computer, because a professional already did it for you, and are selling you their time and efforts with a great os attached to it!

 

This thread is so crapped up with all this controversy lately I'm beginning to think it's not a matter of if it's possible or not. It's a matter of who wants it to happen...

Link to comment
Share on other sites
Kabyl
Kabyl
Posted
Posted
This thread is so crapped up with all this controversy lately I'm beginning to think it's not a matter of if it's possible or not. It's a matter of who wants it to happen...

So much for a technical topic.

 

Your posts and the way you're mixing stuff show the lack of knowledge about the low-level working of stuff, until you do more reading about the topic, you're not going to get anywhere, or maybe with a very small chance, you'll figure out that you're doing it wrong.

 

I don't know what's your issue with real technical questions, so how come you expect people to share their stuff with you, when you don't share yours?

 

I believe you're asking for help when you created this thread, so my advice (if you like to take it) be nice, because anyone could have the answer you're looking for.

 

Good luck.

  • Like 1
Link to comment
Share on other sites
EncryptedSoul
EncryptedSoul
Posted
  • Author
Posted

Over the past couple days I made some progress. ATM I have the smc interruptresource:init, where as before it would error out. I also have smcSMC(iokitResource):waiting......., but doesn't go any further and smchelper:(iokitResource)ERROR. It's progress, or at least a 3rd of the way there. Code is being injected by Method (_DSM, 4, NotSerialized) and a couple if statements and some returns.

Link to comment
Share on other sites
  • 2 months later...
kdawg
kdawg
Posted
Posted
Over the past couple days I made some progress. ATM I have the smc interruptresource:init, where as before it would error out. I also have smcSMC(iokitResource):waiting......., but doesn't go any further and smchelper:(iokitResource)ERROR. It's progress, or at least a 3rd of the way there. Code is being injected by Method (_DSM, 4, NotSerialized) and a couple if statements and some returns.

 

 

This might interest you guys.

 

Nekas has released an open source SMC emulator.

Link to comment
Share on other sites
FKA
FKA
Posted
Posted
You talked about the QEMU patch so i assume you have read the source. I did long time ago and if i understood and remember correctly: There are two SMC ports, the command and the data port. OSX reads from the SMC as following: write to the command port what value it wants to know and then the SMC device puts data to the data port byte wise like:

Command: read OSK0

SMC returns byte 0 of OSK0

Command: read next byte

SMC returns byte 1 of OSK0

....

until the SMC returns that end of data is reached.

and so on.

 

Note, that is just as i remember it, it's been a long time since i read through it. But what i can say for sure, we won't be able to do it in DSDT :(

 

@ crazybyte - read the thread. netkas's site also confirms - not possible!

Looks like the SMC DSDT idea is well dead and buried to me .

 

D.

Link to comment
Share on other sites
  • 8 months later...
cartri
cartri
Posted
Posted

Reviving this old post as it called my interest on some projects of mine.

Once we have the SMC dfu files, couldnt we just allocate their memory space by dsdt? The dfu seems like a simple software with information of what goes where clearly stated.

Link to comment
Share on other sites
  • 1 year later...
Maroc-OS
Maroc-OS
Posted
Posted 

			Device (SMC)
			{
				Name (_HID, EisaId ("APP0001"))
				Name (_CID, "smc-napa")
				Name (_STA, 0x0B)
				Name (_ADR, Zero)
				Method (_DSM, 4, NotSerialized)
				{
					Store (Package ()
						{
							"tjmax",
							Buffer ()
							{
								0x00, 0x00, 0x01, 0x00
							},
							"OSK0",
							Buffer (0x04)
							{
								"ourhardworkbythesewordsguardedpl"
							},
							"OSK1",
							Buffer (0x04)
							{
								"easedontsteal(c)AppleComputerInc"
							}
						}, Local0)
					DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
					Return (Local0)
				}
				Device (SMS0)
				{
					Name (_HID, EisaId ("APP0003"))
					Name (_CID, "smc-sms")
				}
				Device (ALS0)
				{
					Name (_HID, "ACPI0008")
					Name (_CID, "smc-als")
				}
			}

 

That can help :) if yes we need to add all the other values :) like

 

   <key>$Num</key>
   <data>
   AQ==
   </data>
   <key>ACID</key>
   <data>
   AAAAAAAA
   </data>
   <key>ALA0</key>
   <data>
   AAAAAAAAAAAAAAA=
   </data>
   <key>ALA1</key>
   <data>
   AAAAAAAAAAAAAAA=
   </data>
   <key>ALA2</key>
   <data>
   AAAA
   </data>
   <key>ALA4</key>
   <data>
   AAAA
   </data>

 

then we have it in dsdt :)

Link to comment
Share on other sites
Gringo Vermelho
Gringo Vermelho
Posted
Posted

It is not possible, DSDT is read-only. Apparently OS X needs to be able to write to the SMC device.

 

If you read the first post on page two of this thread hopefully you will understand:

 

You talked about the QEMU patch so i assume you have read the source. I did long time ago and if i understood and remember correctly: There are two SMC ports, the command and the data port. OSX reads from the SMC as following: write to the command port what value it wants to know and then the SMC device puts data to the data port byte wise like:

Command: read OSK0

SMC returns byte 0 of OSK0

Command: read next byte

SMC returns byte 1 of OSK0

....

until the SMC returns that end of data is reached.

and so on.

 

Note, that is just as i remember it, it's been a long time since i read through it. But what i can say for sure, we won't be able to do it in DSDT ;)

  • Like 2
Link to comment
Share on other sites
Maroc-OS
Maroc-OS
Posted
Posted

If it real we can create the SMC in dsdt with all the fixed values. and then we can emulate it with a simple way in chameleon and now we can read data from the Fake Device in DSDT, and store the return's to an adresse in memory.

 

if adresse 0x00000000 bla bla = 0 or null

read from acpi

else

get from adresse

 

but if it not?? (not writable)

 

the device is not writable, the values comes from memory and not from the Device it self and we can do more than like my simple example with Fake DSDT Device.

 

correct me if am wrong. :)

 

sorry for my bad english.

Link to comment
Share on other sites
  • 3 years later...
  • 5 weeks later...
 Share
Go to topic listing
×
×
  • Create New...