Jump to content

Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)

Mountain Lion AMD legacy kernel x64_86 ssse3 ssse3 emulator

  • Please log in to reply
6379 replies to this topic

#141
zchef2k

zchef2k

    InsanelyMac Protégé

  • Members
  • PipPip
  • 79 posts
I can test pretty quickly. On my ESXi host I have an Oracle Linux VM to which I can attach the 10.8 VM disk and make modifications (journaling off, of course). I scripted the swap so it takes less than a minute. For me to have a chance I will need emulation as my opterons don't have the SSSE3 instruction set.

Back to corecrypto- the first two keys in that kext's Info.plist take booleans and I've toggled them every which way to the same result I reported earlier. Everything else struck me as a time sink.


#142
instant idiot

instant idiot

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 182 posts
  • Gender:Male

Posted Image

Any other things I can do to help? :)

#143
zchef2k

zchef2k

    InsanelyMac Protégé

  • Members
  • PipPip
  • 79 posts

Any other things I can do to help? :)


Welcome to the party.

Everyone on this thread is on IRC, right?

#144
instant idiot

instant idiot

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 182 posts
  • Gender:Male
Uh, no. What channel?

#145
zchef2k

zchef2k

    InsanelyMac Protégé

  • Members
  • PipPip
  • 79 posts
chat.osx86.hu - #mountainlion , #hackint0sh , or both.

#146
instant idiot

instant idiot

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 182 posts
  • Gender:Male
Connecting......

#147
theconnactic

theconnactic

    Stubborn AMD user

  • Local Moderators
  • 2,973 posts
  • Gender:Male

What about AMD E-Series APUs, do they have SSSE3?


Hi, LordAdmiralDrake.

Is this a Bulldozer CPU? If it's the case, the answer is yes, they have.

I'm guessing you know this already, but Nawcom's Snow Leopard legacy kenel does sse3 emulation, and from what I hear it does a darn good job. I'm sure he'd give you the sources if you asked..

Also, you have to remember - back in the 10.5 days, OSx86 was in full swing. With 10.4 we started getting the idea that maybe, just maybe, Apple's trusted computing DRM scheme could be cracked or worked around, and Mac OS X could be run on standard x86 hardware. By 10.5, that idea took off, and pretty much all Mac users smart enough to know what the x86 and PPC differences were started looking in to it (hence distros appeared - the general majority of people wanted a Windows-like, insert-disc-and-click install). Apple halted, or at least slowed down, this growth via various DMCA crackdowns and SMC enchancements, which is why the community is now back to the small group of hackers it was in the 10.4 days. All this goes to say, however, that OSx86's best days were (arguably) the 10.5 ones - so in other words, I'm sure searching on GitHub or Google Code would yield plenty of (potentially valuable) results.


Hi, SS01!

Thank you for the suggestion. In fact, i asked him. He didn't answer yet. Meklort shared the maxxus' sse3 emulator (an older emulator, not so good as the voodoo/mercurysquad one, but it's something to start with). He linked a diff of a voodoo build of the Leopard kernel that mentions a sse3emu.c: unfortunately, the entire code was not there. He gave me also a copy of an old 64-bit sse3-supportive Bcopy.s. As you can see, more material from one person than i managed to gather in hours of Google research.

#148
instant idiot

instant idiot

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 182 posts
  • Gender:Male
The Connactic, are you on any IRC channels?

#149
theconnactic

theconnactic

    Stubborn AMD user

  • Local Moderators
  • 2,973 posts
  • Gender:Male

I see - sorry about that. I'd still use a kext just to be safe - much easier to boot with -x and delete a kext than having to recompile the kernel. :P

Just thought of a possible last resort if we end up in the same 32-bit only boat as Lion:
1. Patch the netkas 32-bit XNU to work with AMD.
2. Switch all ML kexts to their 32-bit Snow Leopard equivalents, or in the case of ML-only kexts rewrite them completely.
3. Install to AMD rig (either via swapping HDs with an Intel rig, or through a ModUSB-like program) and party hard.

Obviously very last resort, but just saying it's there.


As for the arch i386 kernel, i don't think it's a good idea: the kernel extensions aren't open source, it isn't easy, not to say not possible at all, to make 32-bit version of all of them, or any of them, better saying.

On the latest iterations of OSX, we had the "easy way" (quoting David Elliot): stick to -legacy mode (pure 32-bit mode) or the way most of the patched kernels were: arch i386 kernels with -force64 (64-bit user land) boot flag. We can avoid it anymore: Mountain Lion is designed to be purely 64-bit, so both the easy way (that saved many non-ssse3 AMD CPU users with Lion, despite the severe limitations) and the 64-bit user land (which prevailed until Snow Leopard) won't help anymore: we must face the challenge of making a full 64-bit patched kernel, and maybe even a ssse3 emulator.

Disabling corecrypto is what zchef2k did, and it hangs because the system needs to detect it. It's probably easier to have it detected and work around it rather than rewrite the stuff that interacts with it


Hi, Zach.

IMO, you are completely right. I intend, as a first try, to do a rollback to the Lion version of com.apple.kec.corecrypto, if it exists.

On this corecrypto issue. If you look at the Info.plist, the first key is AppleKernelExternalComponent. (Probably not fascinating but it's been a couple of years since I went fiddling around with this stuff). Looking at OSKextLibPrivate.h in the xnu kernel source I found this. Could cpu id(entification) still be at play here?

/*!
* @define kAppleKernelExternalComponentKey
* @abstract A boolean value indicating whether the kext is vending kernel
*		 KPI, and needs special loading behavior.
*/
#define kAppleKernelExternalComponentKey "AppleKernelExternalComponent"
// properties found in the registry root
#define kOSKernelCPUTypeKey			 "OSKernelCPUType"
#define kOSKernelCPUSubtypeKey		 "OSKernelCPUSubtype"
#define kOSStartupMkextCRC			 "OSStartupMkextCRC"			 /* value is 32-bit OSData */
#define kOSPrelinkKextCountKey		 "OSPrelinkKextCount"		 /* value is 32-bit OSNumber */
#define kOSPrelinkPersonalityCountKey "OSPrelinkPersonalityCount"	 /* value is 32-bit OSNumber */


Hi, zchef2k!

I don't know. What's the relationship did you perceive between this piece of code and a possible remaining cpuid.c issue?

What do i intend to do now:

1) Remove core crypto altogether, to repeat the hang zchef2k experienced. Then, do the rollback for the Lion version, if there is one;

2) Patch the bcopy.s (only the bcopy) of the Mountain Lion XNU using this diff file: Attached File  xnu-1228.7.58_voodoo_release1.0.diff.zip   63.24KB   9 downloads

3) Combine the to options above.

I'll do it later tonight or, more probably, tomorrow morning, because there's an important download in progress in my Lion hackintosh right now, and it's a really large file, so it will probably take hours to finish. That's why i uploaded the diff: if someone doesn't want to wait to tomorrow, can do it right now (don't forget to keep a backup of the original bcopy.s). If somebody actually do it, please post a screenshot here. :)

The Connactic, are you on any IRC channels?


Yes, i am, thanks to PookyMacMan, who kindly pointed me to the #lion and #MountainLion channels of the ircosx86.hu so i could get advice from meklort and nawcom about this little work of ours.

#150
Lordadmiral Drake

Lordadmiral Drake

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 421 posts
  • Gender:Male
  • Location:Austria

Hi, LordAdmiralDrake.

Is this a Bulldozer CPU? If it's the case, the answer is yes, they have.


Just looked it up on WIkipedia. The E-Series APUs with Zacate core support SSSE3 and SSE4a

#151
SS01

SS01

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 265 posts
  • Gender:Male
  • Location:Ottawa

As for the arch i386 kernel, i don't think it's a good idea: the kernel extensions aren't open source, it isn't easy, not to say not possible at all, to make 32-bit version of all of them, or any of them, better saying.

On the latest iterations of OSX, we had the "easy way" (quoting David Elliot): stick to -legacy mode (pure 32-bit mode) or the way most of the patched kernels were: arch i386 kernels with -force64 (64-bit user land) boot flag. We can avoid it anymore: Mountain Lion is designed to be purely 64-bit, so both the easy way (that saved many non-ssse3 AMD CPU users with Lion, despite the severe limitations) and the 64-bit user land (which prevailed until Snow Leopard) won't help anymore: we must face the challenge of making a full 64-bit patched kernel, and maybe even a ssse3 emulator.



Hi, Zach.

IMO, you are completely right. I intend, as a first try, to do a rollback to the Lion version of com.apple.kec.corecrypto, if it exists.



Hi, zchef2k!

I don't know. What's the relationship did you perceive between this piece of code and a possible remaining cpuid.c issue?

What do i intend to do now:

1) Remove core crypto altogether, to repeat the hang zchef2k experienced. Then, do the rollback for the Lion version, if there is one;

2) Patch the bcopy.s (only the bcopy) of the Mountain Lion XNU using this diff file: Attached File  xnu-1228.7.58_voodoo_release1.0.diff.zip   63.24KB   9 downloads

3) Combine the to options above.

I'll do it later tonight or, more probably, tomorrow morning, because there's an important download in progress in my Lion hackintosh right now, and it's a really large file, so it will probably take hours to finish. That's why i uploaded the diff: if someone doesn't want to wait to tomorrow, can do it right now (don't forget to keep a backup of the original bcopy.s). If somebody actually do it, please post a screenshot here. :)



Yes, i am, thanks to PookyMacMan, who kindly pointed me to the #lion and #MountainLion channels of the ircosx86.hu so i could get advice from meklort and nawcom about this little work of ours.

Yup, it's a bad idea. A terrible idea. But that's not to say it can't be done, even though I don't recommend it.
And about the extensions not being open source, well, we're breaking the EULA doing this, no? Just sayin.

Welcome to the party.

Everyone on this thread is on IRC, right?

I haven't been on IRC for a while, but I'll try to get on sometimes. Do we want our own #LegacyKernel channel? :3

#152
ZackehSoul

ZackehSoul

    InsanelyMac Protégé

  • Members
  • PipPip
  • 65 posts
  • Gender:Male
  • Location:Leeds, UK

I haven't been on IRC for a while, but I'll try to get on sometimes. Do we want our own #LegacyKernel channel? :3


It would make sense to start our own channel as well, so that it's always on topic

#153
SS01

SS01

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 265 posts
  • Gender:Male
  • Location:Ottawa

It would make sense to start our own channel as well, so that it's always on topic


I'll start the channel as soon as I get XChat installed. :)

Edit: Done. #LegacyKernel on irc.osx86.hu

#154
PookyMacMan

PookyMacMan

    InsanelyMac Legend

  • Moderators
  • 1,464 posts
  • Gender:Male
  • Location:Earth–Western Hemisphere, specifically
  • Interests:Computer science, engineering, trumpet performance, and a host of others. :D
Alright, I'll join when I can! :)

Edit: No one is there...lol :P

Edit 2: Now it's comin' alive. :D

Some links for you:

http://code.google.c...E3 Emulator.pdf

http://code.google.c...SourceCode?tm=4

#155
theconnactic

theconnactic

    Stubborn AMD user

  • Local Moderators
  • 2,973 posts
  • Gender:Male

Yup, it's a bad idea. A terrible idea. But that's not to say it can't be done, even though I don't recommend it.
And about the extensions not being open source, well, we're breaking the EULA doing this, no? Just sayin.


Man, i'm not talking about this EULA thing. :)

The problem is that we don't have the sources for changing and recompiling the kexts. No source, no joy. We could try to reverse engineering them, but to reverse engineering just one of them, it could take months, assuming specialized people help us. To get things worse, we'd have to reverse-engineer dozens of them.

No, the idea isn't bad at all! But i don't think it's feasible.

#156
PookyMacMan

PookyMacMan

    InsanelyMac Legend

  • Moderators
  • 1,464 posts
  • Gender:Male
  • Location:Earth–Western Hemisphere, specifically
  • Interests:Computer science, engineering, trumpet performance, and a host of others. :D

Man, i'm not talking about this EULA thing. :)

The problem is that we don't have the sources for changing and recompiling the kexts. No source, no joy. We could try to reverse engineering them, but to reverse engineering just one of them, it could take months, assuming specialized people help us. To get things worse, we'd have to reverse-engineer dozens of them.

Besides which, we would probably get in plenty of trouble for reverse-engineering (some of) the kexts - that and binary patching Apple isn't too happy with, so technically running an AMD hack is (kinda sorta) illegal...but not really. :P [explain]The EULA is not enforceable by law, the worst Apple can do is sue the offender, and that's only in the US, and they would only sue companies not individuals. On the other hand, reverse-engineering and binary patching of some things is a DMCA infringement, a much more serious offense. Again, only in the US[/explain]

#157
SS01

SS01

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 265 posts
  • Gender:Male
  • Location:Ottawa

Besides which, we would probably get in plenty of trouble for reverse-engineering (some of) the kexts - that and binary patching Apple isn't too happy with, so technically running an AMD hack is (kinda sorta) illegal...but not really. :P [explain]The EULA is not enforceable by law, the worst Apple can do is sue the offender, and that's only in the US, and they would only sue companies not individuals. On the other hand, reverse-engineering and binary patching of some things is a DMCA infringement, a much more serious offense. Again, only in the US[/explain]


What if I do all the reverse engineering? Canadaaaaaaaaaaaaaaa ftw! :P
Just kidding. Yeah, I can see why it'd take so long, lol. Also, binary patching XNU isn't illegal at all - we just need to mention that the finished result is released under the APSL.

#158
PookyMacMan

PookyMacMan

    InsanelyMac Legend

  • Moderators
  • 1,464 posts
  • Gender:Male
  • Location:Earth–Western Hemisphere, specifically
  • Interests:Computer science, engineering, trumpet performance, and a host of others. :D
Patching XNU is not an issue (I even said so earlier myself) - binary patching some of the system daemons and files are. The ones that are not open source. I think libsystem.dyld and a couple others...? Can't remember off the top of my head since I never owned an AMD box, only legacy Intel...

#159
SS01

SS01

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 265 posts
  • Gender:Male
  • Location:Ottawa

Patching XNU is not an issue (I even said so earlier myself) - binary patching some of the system daemons and files are. The ones that are not open source. I think libsystem.dyld and a couple others...? Can't remember off the top of my head since I never owned an AMD box, only legacy Intel...

Ohh I see. Stupid annoying American copryright laws! Up here we can decompile, reverse engineer, and patch whatever we want while sitting on a moose in an igloo watching hockey. :D

Anycase though, judging by the amount of people who use the "bay full of pirates" (A DMCA offence) on a daily basis I don't think we have much to worry about, even if we do a bit of reverse engineering. :)

#160
bcobco

bcobco

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 142 posts
  • Gender:Male
  • Location:Argentina
never saw about xnu-dev project. is the project that i whas talking about.
lets join it!

xnu-dev
A fork of the Apple® Darwin XNU kernel for generic x86 PCs

http://code.google.com/p/xnu-dev/

they describe a method to emulate a non supported instruction. (see "SSE3 Emulator.pdf")
the bottleneck is in the trap overhead, which i think that can be improved (actually adds about 430 cpu cycles). emulating instruction takes few cpu cycles.

Edited by bcobco, 07 October 2012 - 12:58 PM.






Also tagged with one or more of these keywords: Mountain Lion, AMD, legacy kernel, x64_86, ssse3, ssse3 emulator


3 user(s) are reading this topic

0 members, 3 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