Jump to content

SMC Emulation in DSDT


  • Please log in to reply
44 replies to this topic

#21
fassl

fassl

    InsanelyMac Legend

  • Retired
  • 623 posts
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 :)

#22
EncryptedSoul

EncryptedSoul

    InsanelyMac Protégé

  • Members
  • Pip
  • 34 posts
  • Gender:Male

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 -_-

The qemu patch is boot loader worthy.

We can easily make applesmc emulation a part of Darwin.

I am always trying to find the "better way"... Ya know?

~ES

#23
fassl

fassl

    InsanelyMac Legend

  • Retired
  • 623 posts
If it is so easy I hope to see such an emulation by you soon :(

#24
mitch_de

mitch_de

    InsanelyMacaholic

  • Local Moderators
  • 2,880 posts
  • Gender:Male
  • Location:Stuttgart / Germany
So the benefit of last DSDT code SMC is more cosmetic (less error messages) or does the DSDT SMC does something more even there is no real smc chip ?
Thanks for explaining SMC device.

#25
EncryptedSoul

EncryptedSoul

    InsanelyMac Protégé

  • Members
  • Pip
  • 34 posts
  • Gender:Male

So the benefit of last DSDT code SMC is more cosmetic (less error messages) or does the DSDT SMC does something more even there is no real smc chip ?
Thanks for explaining SMC device.

The smc code is recognized by the os, however when the os looks for the binaries to decrypt atsserver, loginwindow, finder, etc. The smc errors out with initialization errors. Basically, the os see's the supposed smc device but can't retrieve any data from it.

@ coconup: if you have gotten far enough to have a battery meter show, maybe it can be as simple to edit the stock kext to read your battery status.

#26
EncryptedSoul

EncryptedSoul

    InsanelyMac Protégé

  • Members
  • Pip
  • 34 posts
  • Gender:Male

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!

#27
sonotone

sonotone

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,151 posts
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?

#28
EncryptedSoul

EncryptedSoul

    InsanelyMac Protégé

  • Members
  • Pip
  • 34 posts
  • Gender:Male

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.

#29
Kabyl

Kabyl

    InsanelyMac Geek

  • Retired Developers
  • 170 posts
  • Gender:Male
In a related subject, what's the "Automatic Boot Decrypt" in your signature?

#30
EncryptedSoul

EncryptedSoul

    InsanelyMac Protégé

  • Members
  • Pip
  • 34 posts
  • Gender:Male

In a related subject, what's the "Automatic Boot Decrypt" in your signature?


Read the decrypt.txt file in the OSx86_SourceCode folder and you will have the answer.

Cheers

#31
Kabyl

Kabyl

    InsanelyMac Geek

  • Retired Developers
  • 170 posts
  • Gender:Male

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.

#32
EncryptedSoul

EncryptedSoul

    InsanelyMac Protégé

  • Members
  • Pip
  • 34 posts
  • Gender:Male

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


So is trolling around something you do on the regular?

#33
Kabyl

Kabyl

    InsanelyMac Geek

  • Retired Developers
  • 170 posts
  • Gender:Male

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?

#34
sonotone

sonotone

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,151 posts

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.

#35
EncryptedSoul

EncryptedSoul

    InsanelyMac Protégé

  • Members
  • Pip
  • 34 posts
  • Gender:Male

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...

#36
Kabyl

Kabyl

    InsanelyMac Geek

  • Retired Developers
  • 170 posts
  • Gender:Male

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.

#37
EncryptedSoul

EncryptedSoul

    InsanelyMac Protégé

  • Members
  • Pip
  • 34 posts
  • Gender:Male
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.

#38
kdawg

kdawg

    InsanelyMac Legend

  • Donators
  • 508 posts
  • Gender:Male
  • Location:Boston, MA

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.

#39
crazybyte

crazybyte

    InsanelyMac Protégé

  • Members
  • PipPip
  • 68 posts
I found some strings that are present in your DSDT code in netkas new fakesmc.kext, that might be interesting. We have to talk with netkas about his source code. And how he solved the problems that we have with DSDT code.

#40
FKA

FKA

    are we there yet?

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,626 posts
  • Gender:Male

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.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy