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

[theconnactic]

Hey, SS01!

 

If we somehow get to the beta testing phase, any machine will be more than welcome, lol!

 

Glad that you're in this kernel quest! The more people join efforts, the most are our chances of to succeed.

 

Check out this thread: http://osx86.co/f100...d-kernel-t7687/ - RAWX86 shared his diff. It's for Lion 10.7.4, i tried to apply it to the Mountain Lion XNU but it was an epic fail, as expected. But it can help us to understand what must be done somehow.

 

I'm in the process right now of comparing Lion and Mountain Lion XNU kernels to figure out what the fundamental changes were. I'm using FileMerge (Xcode tool), thanks to an advice from RAWX86, and i recommend you to use it too, as it makes the work easier.

 

Bcobco, i didn't check your links out yet, but they're in my reading list.

 

Other pieces of info i collected here and there, all of them related to Lion but they could well suit Mountain Lion:

 

- Meklort said to PookyMacMan, that by his turn told me, that the ssse3 calls that ruled almost all AMD CPUs out for Lion are at the commpage, writen in assembly. Pooky thinks that the process of making that sss3-requiring kernel compatible to non-ssse3 CPUs could be quite simple; in fact, it would just to be a matter of alter the ssse3 calls to sse3 in the assembly files (i'm in the process to learn assembly language, but veeeeeery slowly: by know, i just learnt to make assembly codes to perform basic arithmetic calculations, lol) - http://www.insanelym...ic=277290&st=80

 

- Curiously, when asked about the possibility of a binary patch for AMD, meklort told me the patches could be written mostly in C. This could be good news, since i'm just confortable with C now. But he didn't elaborate any longer about it, so i'm out and lost. - http://www.osx86.net...-3150-a-21.html

 

- A guy called justinster compiled a 64-bit kernel that, if couldn't get us to boot (gets a kernel panic somewhere at the middle of the road), didn't give us an instant reboot either, unlike all other tested 64-bit Lion kernels for AMD. Another guy called Delta0 did something similar and posted at the same forum. I tried to PM both of them, but got no reply: http://osx86.co/f100...06/page111.html

[bcobco]

/*
* instruction length decoder (written by kaitek, modified by mercurysquad)
* voodoo xnu kernel
*
* based on code from AntiHookExec 1.00, Copyright © 2004 Chew Keong TAN
* opcode tables based on documentation from http://www.sandpile.org/
*
*   todo:   * support for instruction set extensions newer than SSSE3
*		   * verify that VT instructions are correctly decoded
* AnV - Added better opcode + SSE4.1 + SSE4.2 support
*/

i tried to read that C file... that part is the only part i understand hahah impossible when have not the knowledge. for me is like a chinese dialect.

[SS01]

After looking at the XNU for ML, I came up with nothing, as expected. I am wondering, would it be realistic to focus on the Bobcat, Bulldozer, and Pileframe (all of which support SSSE3 natively) architectures first? Then once (if) we get a bootable kernel, we could write the SSSE3 emu. Just a suggestion lol.

[theconnactic]

Hy, folks!

 

Did another preparatory experience: i used the universal patched kernel for Lion 10.7.4 made by RAWX86 (raw64bit.zip), booting with raw64bit archx86_64 npci=0x3000 -v to boot 10.8.0 and got this result:

 

 

(notice the sixth line: "mach0 is malformed" or something like that)

 

How funny, the photos uploaded upside down, as in another forum i posted them. Well, at least i know the problem is from me, lol.

 

bcobco, google for a book called Learn C in 24 Hours. Very summarized, good for beginners and a cheap one.

 

SS01, you're probably right. In fact, i think we have not much of a choice.

Edited September 19, 2012 by theconnactic

[SS01]

SS01, you're probably right. In fact, i think we have not much of a choice.

Yeah.. the reason i say this is because I think out best option would be manually translating the SSSE3 instructions to SSE3, and to do that, we'd need to see what our finished mach_kernel looks like. I suppose a full blown, on-the-fly emulator could be done now, but it'd obviously much more difficult, not to mention a drain on system resources and that I think we should be focusing our effores on getting something to boot first.

[theconnactic]

Yes, and we most not to forget that Bulldozer CPUs run Lion flawlessly with full 64-bit support (even on a i386 kernel).

 

An interesting thought just came to my mind: i'm using 10.8.1 in my netbook for weeks now. You know what?, it doesn't feel like an upgrade. Instead, it feels like a Lion update, with a bunch of cool features and core apps added, not quite a whole new OS (am i'm not alone in this opinion, as you can see taking a quick look at the App Store reviews).

 

In fact, 10.6.8 had more crucial differences to 10.6.0 (App Store a good example) than 10.8.1 to 10.7.4. I don't know if it reflects itself at kernel level, but, look!, i managed to use RAW's 10.7.4 64-bit kernel on my non-supported Athlon II CPU to boot 10.8.0, and get to the point i had an ACPI kernel panic, not an instant reboot i'd have if i tried to, say, use Snow Leo kernel to boot Lion. That should mean something.

[bcobco]

image is blur. text is hard to see.

did you applied that patch as is?

[theconnactic]

Hi, bcobco!

 

Better saying, i applied the kernel as is. Simply put the 10.7.4 RAWX86 kernel at the root of my 10.8 disk and boot with flags "arch x86_64 npci=0x3000 raw64bit" (without quotes, of course).

 

I should have paused the process to see the other lines before the last ones above the kernel panic, there could be useful info in those lines.

[SS01]

Hi, bcobco!

 

Better saying, i applied the kernel as is. Simply put the 10.7.4 RAWX86 kernel at the root of my 10.8 disk and boot with flags "arch x86_64 npci=0x3000 raw64bit" (without quotes, of course).

 

I should have paused the process to see the other lines before the last ones above the kernel panic, there could be useful info in those lines.

 

Interesting. As soon as I get ML on my Hackbook Pro (it's running SL atm - my signature is lying) I'll take a look at the RAW kernel and see if an ML conversion might be possible, assuming it can also boot Intel CPUs. Just out of curiosity, does -force64 and cpus=1 get you anywhere?

 

Also, I think we need to ask meklort to elaborate a bit on how an AMD binary patch in C would be done - it'd probably help us if we knew more about what exactly we have to do.

[bcobco]

raw64bit arch=x86_64 -force64 npci=0x3000 -v

you forgot the = in arch flag, try also without arch=x86_64 -force64 to see what happens

 

im not sure but maybe it doesnt work since 10.8 kexts depends on 10.8 kernel things that are not in a 10.7 kernel.. im not sure about this. maybe its a cause please confirm.

i cannot read that screenshot, its not a steady shot. but i can read undefined this undefined that... seems that things does not feet.

[Lordadmiral Drake]

I'll type down what I can read:

 

kxld(com.apple.iokit.IOACPIFamily): In interface com.apple.kpl.private of __kernel__, couldn't find symbol _throttle_io_will_be_throttled

 

kxld(com.apple.iokit.IOACPIFamily): In interface com.apple.kpl.private of __kernel__, couldn't find lmdlroot symbol _***_is_traffic_class_priviledged (_***_is_service_class_priviledged)

 

kxld(com.apple.iokit.IOACPIFamily): In interface com.apple.kpl.unsupported of __kernel__, couldn't find symbol ***

 

kxld(com.apple.iokit.IOACPIFamily): In interface com.apple.kpl.unsupported of __kernel__, couldn't find symbol _mach_***_lookup

 

kxld(com.apple.iokit.IOACPIFamily): The Mach-0 file is malformed: Invalid segment type in ***_KEXT_HANDLE kext: 42.

Can't load com.apple.iokit.IOACPIFamily - link failed.

Failed to load executable for com.apple.iokit.IOACPIFamily.

Kext com.apple.iokit.IOACPIFamily failed to load (0xdc000015)

Dependency com.apple.iokit.IOACPIFamily of kext com.apple.driver.AppleACPIPlatform failed to load

Kext com.apple.driver.AppleACPIPlatform failed to load (0xdc000015)

Failed to load kext com.apple.driver.AppleACPIPlatform (error 0xdc000015)

Couldn't alloc class "AppleACPIPlatformExport"

 

blah blah blah

 

panic(cpu 0 caller *somehex*): Unable to find driver for this platform \"ACPI\".n\*path to IOPlatformExport.cpp*: 1500

Debugger called: (panic)

*Stacktrace*

[bcobco]

thanks for the effort!

 

i was meaning that lines where kxld cant find some symbols. acpi fails to load, so kernel cant continue

 

 

realease notes:
###############
The system hang after HD initialization on non-SSSE3 capable systems is not fixed, yet.
If this concerns you, use -leagcy flag and Finder from Lion DP2.

what happens when you start with -legacy flag?

[Lordadmiral Drake]

I have an AMD machine myself, so I'm a bit motivated

 

Unfortunately I don't know anything about assember and extremely little C

[theconnactic]

Hi, bcobco!

 

No, i didn't forget the "=", i omitted it for the sake of fast typing.

 

I realized that, in Lion, i can use the 64-bit Raw 10.7.4 kernel to the point the "Kernel=LP64" appears (and the boot hangs there, as expected), so i was wrong about the results in Mountain Lion being better with this same kernel. The problem is indeed between 64-bit Kernels in Lion (i don't know what changed in Mountain Lion) and AMD CPUS (even Bulldozer ones, on which the result is even worse - instant reboots! - despite the fact Buldozers can get 64-bit app support in i386, not needing to use -legacy flag). I don't know if it persists in Mountain Lion, since nobody compiled and AMD patched kernel to it until AFAIK (i was using, just to stress it, the RAW 64-bit 10.7.4).

 

Reading an interesting paper by Davi Eliiot, (this one: http://tgwbd.org/darwin/xnu.html) i realized that the problem lies indeed at the commpage, as someone else told me. There's a routine called there, which is required to run 64-bit, and which needs ssse3 instructions to run. This routine is called bcopy.s, written in assembly, and has the following code:

 

#include

/* void *memcpy((void *) to, (const void *) from, (size_t) bcount) */

/* rdi, rsi, rdx */

/*

* Note: memcpy does not support overlapping copies

*/

ENTRY(memcpy)

movq %rdx,%rcx

shrq $3,%rcx /* copy by 64-bit words */

cld /* copy forwards */

rep

movsq

movq %rdx,%rcx

andq $7,%rcx /* any bytes left? */

rep

movsb

ret

/* void bcopy((const char *) from, (char *) to, (unsigned int) count) */

/* rdi, rsi, rdx */

ENTRY(bcopy_no_overwrite)

xchgq %rsi,%rdi

jmp EXT(memcpy)

/*

* bcopy(src, dst, cnt)

* rdi, rsi, rdx

* ws@tools.de (Wolfgang Solfrank, TooLs GmbH) +49-228-985800

*/

ENTRY(bcopy)

xchgq %rsi,%rdi

movq %rdx,%rcx

movq %rdi,%rax

subq %rsi,%rax

cmpq %rcx,%rax /* overlapping && src

jb 1f

shrq $3,%rcx /* copy by 64-bit words */

cld /* nope, copy forwards */

rep

movsq

movq %rdx,%rcx

andq $7,%rcx /* any bytes left? */

rep

movsb

ret

/* ALIGN_TEXT */

1:

addq %rcx,%rdi /* copy backwards */

addq %rcx,%rsi

decq %rdi

decq %rsi

andq $7,%rcx /* any fractional bytes? */

std

rep

movsb

movq %rdx,%rcx /* copy remainder by 32-bit words */

shrq $3,%rcx

subq $7,%rsi

subq $7,%rdi

rep

movsq

cld

ret

 

Again, this is in Lion 10.7.4. I really don't know if there are any necessary ssse3-only routines in Mountain Lion to run 64-bit. But the interesting thing is that it's only one routine, even crucial as it is, that requires ssse3 instructions. I think that if we can rewrite somehow this routine - or, at list, the part that requires ssse3 - so it calls ss3, we can escape the task of writting an on-the-fly sss3 emulator. So that's the point (again, in Lion! Maybe Mountain Lion doesn't have this narrow end, and all we must to do is patched the kernel so it loads on AMD).

 

As for assembly, i'm studying by myself using this book: http://www.drpaulcarter.com/pcasm/ (thanks, pookymacman)

 

I'll type down what I can read:

 

kxld(com.apple.iokit.IOACPIFamily): In interface com.apple.kpl.private of __kernel__, couldn't find symbol _throttle_io_will_be_throttled

 

kxld(com.apple.iokit.IOACPIFamily): In interface com.apple.kpl.private of __kernel__, couldn't find lmdlroot symbol _***_is_traffic_class_priviledged (_***_is_service_class_priviledged)

 

kxld(com.apple.iokit.IOACPIFamily): In interface com.apple.kpl.unsupported of __kernel__, couldn't find symbol ***

 

kxld(com.apple.iokit.IOACPIFamily): In interface com.apple.kpl.unsupported of __kernel__, couldn't find symbol _mach_***_lookup

 

kxld(com.apple.iokit.IOACPIFamily): The Mach-0 file is malformed: Invalid segment type in ***_KEXT_HANDLE kext: 42.

Can't load com.apple.iokit.IOACPIFamily - link failed.

Failed to load executable for com.apple.iokit.IOACPIFamily.

Kext com.apple.iokit.IOACPIFamily failed to load (0xdc000015)

Dependency com.apple.iokit.IOACPIFamily of kext com.apple.driver.AppleACPIPlatform failed to load

Kext com.apple.driver.AppleACPIPlatform failed to load (0xdc000015)

Failed to load kext com.apple.driver.AppleACPIPlatform (error 0xdc000015)

Couldn't alloc class "AppleACPIPlatformExport"

 

blah blah blah

 

panic(cpu 0 caller *somehex*): Unable to find driver for this platform \"ACPI\".n\*path to IOPlatformExport.cpp*: 1500

Debugger called: (panic)

*Stacktrace*

 

Hey, it just comes to my mind: what if we try an ACPI rollback? Say, try to boot it with ACPIPlatform.kext from Lion 10.7.4 instead of Mountain Lion's?

 

 

EDIT: Now i'm sure that is a waste of time to use Lion 10.7.4 XNU kernel as is to boot Mountain Lion, since it requires ssse3 instructions to boot 64-bit, and Mountain Lion requires a 64-bit kernel. We could just try to solve this problem with the ssse3 routine (it would help Lion AMD users too), but even with this, maybe it cannot boot Mountain Lion anyway because of core changes in the new OS (even the changes being not so drastic from an end-user point of view).

 

So i think there's two main paths for AMD hackintoshing by now: 1) focus on Mountain Lion XNU itself, and before even trying to patch it for AMD, we must discover if it has any ssse3 routines required to run, which ones, and how to change it and then apply patches AMD-specific (unless we plan to abandon non-Buldozer users like me, lol) or 2) focus on Lion 10.7.4 XNU, since we have a patched one for AMD, then making it run 64-bit flawlessly on AMD with Lion itself, by correcting the ssse3 calls in the commpage and bcopy.s routine and perfecting the AMD patches (remember that even Bulldozer ssse3-enabled CPUs have to boot arch=i386, which won't work with ML), and only then try to either have ML booting with it or generate a diff file from it by comparing it with ML's, and then apply this diff with AMD patches and ssse3 correction as a patch to ML XNU (I tried something like that though, applying RAW's diff directly as a patch on 12.0 XNU, and got an epic fail).

Edited September 21, 2012 by theconnactic

[tdtran1025]

Snow Leopard and earlier iterations of OsX used to run flawlessly on AMD systems. Maybe it comes to my mind only because my AMD computer isn't invited to the party, but seems to me that, while apple is trying to use the power of intel CPUs to the maximum, which is good for performance, it makes its system more and more dependent on Intel's capability of innovate and improve. Intel has the edge now and i'm pretty sure that it will have it in the near future. But then, who knows?

 

OsX isn't anymore a straight x86-based system (or, more accurately, x86_64), but an Intel EM64T system. As it goes, Microsoft is making improvements in multithreading for Windows 8, so it could use the full eight cores of, say, AMD Piledriver upcoming CPUS. Maybe that gives an Intel-high-end-level of performance to this AMD CPUs, which will surely cost less. Is the newest releases of OsX optimized for multithreading? If so, a Piledriver hackintosh is not bad a prospect for power users, and could well worth the effort of writing emulators etc.

 

I disagree on the latter part of the comment. I think they (apple) do this out of resource allocation. They did try out several AMD chip variations; and according to some internal reports, AMD show terrible reliability issues. Do not jump my me AMD fans because I am one too. It pained me a great deal when I had to switch to Intel platform to be able to enjoy Hackintosh. As you can see here in the forum, the choice of motherboard has a great deal of success on the outcome. Every board we use is not conforming to Apple's SMC codes so that's why we need to use different FakeSMC to boot. Enough for this simple reason.

I also think the development effort on alternative CPU architecture in the last several years has been secretly going on at Apple. For now and time-to-market reason, they stick with Intel because their work is not complete yet. What I am saying is they probably present their own ARM-based architecture in the very near future that can scale up to MacPro with dozens of CPUs. When that day comes, we all have to buy new Macs because the Chinese computer industry won't be able to make any motherboard that utilizes ARM CPU. It may not that bad considering the price-to-performance ratio of any non-portable Macs.

[theconnactic]

It may not that bad considering the price-to-performance ratio of any non-portable Macs.

 

I couldn't disagree more. Mac Pros and iMacs (worse with the former) are outrageously overpriced, tdtran.

[SS01]

So i think there's two main paths for AMD hackintoshing by now: 1) focus on Mountain Lion XNU itself, and before even trying to patch it for AMD, we must discover if it has any ssse3 routines required to run, which ones, and how to change it and then apply patches AMD-specific (unless we plan to abandon non-Buldozer users like me, lol) or 2) focus on Lion 10.7.4 XNU, since we have a patched one for AMD, then making it run 64-bit flawlessly on AMD with Lion itself, by correcting the ssse3 calls in the commpage and bcopy.s routine and perfecting the AMD patches (remember that even Bulldozer ssse3-enabled CPUs have to boot arch=i386, which won't work with ML), and only then try to either have ML booting with it or generate a diff file from it by comparing it with ML's, and then apply this diff with AMD patches and ssse3 correction as a patch to ML XNU (I tried something like that though, applying RAW's diff directly as a patch on 12.0 XNU, and got an epic fail).

Personally I'd go with plan 1 - making the kernel sse3 capable, whether via an on-the-fly emulator or manually translating the instructions (the first would be hard, while the second would be easy but rather tedious) then focus on AMD patching. meklort did say that an AMD binary patch in C wouldn't be too hard, after all.

 

By the way, I don't know if this helps or not, but netkas compiled a 32-bit XNU kernel for ML: http://rghost.net/39532549 - it KPs almost instantly because all ML kexts are 64-bit, though.

[theconnactic]

Personally I'd go with plan 1 - making the kernel sse3 capable, whether via an on-the-fly emulator or manually translating the instructions (the first would be hard, while the second would be easy but rather tedious) then focus on AMD patching. meklort did say that an AMD binary patch in C wouldn't be too hard, after all.

 

Pursuing your suggestion, i'm right now taking a look at the commpage of the 10.8.2 XNU (http://opensource.ap.../i386/commpage/). Let's see if i manage to figure a little bit of something out of this.

 

Whoa, very interesting! Instructions!

 

 

Here's what to do if you want to add a new routine to the comm page:

*

* 1. Add a definition for it's address in osfmk/i386/cpu_capabilities.h,

* being careful to reserve room for future expansion.

*

* 2. Write one or more versions of the routine, each with it's own

* commpage_descriptor. The tricky part is getting the "special",

* "musthave", and "canthave" fields right, so that exactly one

* version of the routine is selected for every machine.

* The source files should be in osfmk/i386/commpage/.

*

* 3. Add a ptr to your new commpage_descriptor(s) in the "routines"

* array in osfmk/i386/commpage/commpage_asm.s. There are two

* arrays, one for the 32-bit and one for the 64-bit commpage.

*

* 4. Write the code in Libc to use the new routine.

[bcobco]

good investigation job!

so, the problem is that the comm page has instructions only for intel SSSE3 (?)

adding more routines to the comm page will make xnu compatible with all x86_64 processors (?)

[theconnactic]

And these statements summarize the CPU instructions. Notice the switch statement: for those non-familiar with C, this statement makes the machine evaluate the first conditional "case", by order of appearance. if the first case is not satisfied, that's it, bits |= kHasAVX1, that means different (|=) of kHasAVX1, than the other cases (satisfied by being different to given referred instruction also) are subsequently evaluated. If none of the cases are satisfied, than the machine evaluates the default, which breaks the statement. That means that the statement breaks when none of the cases are satisfied, that is, if the variable "bits" is not different from any of the CPU instructions (equal to all of them).

 

This could mean nothing (i'll have to take a look at the consequences of the assigment of inequality of any of the instructions to the variables being true). But it could be precisely here that the kernel evaluates if all required instructions are supported in a given CPU! If it's the case (no pun intended ), it suddenly comes to my mind that some of these "cases" should be erased from the map, lol!

 

Anyway, this seems crucial. Now i really need the assistance of someone more skilled programming-wise than i am!

 

 

switch (cpu_info.vector_unit) {

case 9:

bits |= kHasAVX1_0;

/* fall thru */

case 8:

bits |= kHasSSE4_2;

/* fall thru */

case 7:

bits |= kHasSSE4_1;

/* fall thru */

case 6:

bits |= kHasSupplementalSSE3;

/* fall thru */

case 5:

bits |= kHasSSE3;

/* fall thru */

case 4:

bits |= kHasSSE2;

/* fall thru */

case 3:

bits |= kHasSSE;

/* fall thru */

case 2:

bits |= kHasMMX;

default:

break;

 

good investigation job!

so, the problem is that the comm page has instructions only for intel SSSE3 (?)

adding more routines to the comm page will make xnu compatible with all x86_64 processors (?)

 

Maybe! Seems that the commpage explicitly requires a lot of CPU instructions to be present! Now i need some experienced advice here. We're getting close to something, it seems. The whole code is quite commented, which is good. Almost like the coders are giving guidance to the ones who wish to play with the code.

[SS01]

Something just occurred to me: this is likely a stupid question, but do any crucial system functions actually need ssse3? If not, the fix to this problem could be as simple as something like FakeSMC.kext, tricking OS X into thinking that everything is working.

 

EDIT: just noticed an ad for Opteron servers is at the top of this page while I'm writing this. I think AMD is hinting at something!

[bcobco]

Intel® 64 and IA-32 Architectures Software Developer Manuals

http://www.intel.com...er-manuals.html

 

 

 

the list of SupplementalSSE3 instructions

http://en.wikipedia.org/wiki/SSSE3

http://en.wikipedia....uction_listings

 

what can be the solution?

1- take all calls to an unsupported instructions set and implement them with avaliable instructions set

2- reimplement the part that calls that unsupported instruction with the avaliable instruction

3- fork darwin os to make full x86 compatible xnu branch. look at linux, bsd, ... kernels, they have options for a lot of specific processors and instructions sets, with the same code (?)

4- think more ideas that are always welcome

5- switch to intel and party hard

 

 

 

for example (option 1-), the instructions PHADDW/PHADDD that makes Packed Horizontal Add (Words or Doublewords):

takes registers A = [a0 a1 a2 …] and B = [b0 b1 b2 …] and outputs [a0+a1 a2+a3 … b0+b1 b2+b3 …]

a very trivial operation... this can perfectly be implemented with other instructions.

obviously it will require a little set of instructions that will always be slower than only one instruction designated for this task

 

 

 

i dont like CISC architecture

Edited September 24, 2012 by bcobco

[theconnactic]

Hey, bcobco!

 

In the end, when needed, we all turn ourselves into black magicians, huh?

 

 

I think this file, cpuid.c, is kinda an obligatory target for AMD patches - http://opensource.ap...mk/i386/cpuid.c

 

Take a look at one excerpt (notice that is another switch statement):

 

 

cpuid_set_cpufamily(i386_cpu_info_t *info_p)

{

uint32_t cpufamily = CPUFAMILY_UNKNOWN;

 

switch (info_p->cpuid_family) {

case 6:

switch (info_p->cpuid_model) {

#if CONFIG_YONAH

case 14:

cpufamily = CPUFAMILY_INTEL_YONAH;

break;

#endif

case 15:

cpufamily = CPUFAMILY_INTEL_MEROM;

break;

case 23:

cpufamily = CPUFAMILY_INTEL_PENRYN;

break;

case CPUID_MODEL_NEHALEM:

case CPUID_MODEL_FIELDS:

case CPUID_MODEL_DALES:

case CPUID_MODEL_NEHALEM_EX:

cpufamily = CPUFAMILY_INTEL_NEHALEM;

break;

case CPUID_MODEL_DALES_32NM:

case CPUID_MODEL_WESTMERE:

case CPUID_MODEL_WESTMERE_EX:

cpufamily = CPUFAMILY_INTEL_WESTMERE;

break;

case CPUID_MODEL_SANDYBRIDGE:

case CPUID_MODEL_JAKETOWN:

cpufamily = CPUFAMILY_INTEL_SANDYBRIDGE;

break;

case CPUID_MODEL_IVYBRIDGE:

cpufamily = CPUFAMILY_INTEL_IVYBRIDGE;

break;

}

break;

}

[theconnactic]

Something just occurred to me: this is likely a stupid question, but do any crucial system functions actually need ssse3? If not, the fix to this problem could be as simple as something like FakeSMC.kext, tricking OS X into thinking that everything is working.

 

EDIT: just noticed an ad for Opteron servers is at the top of this page while I'm writing this. I think AMD is hinting at something!

 

Not a stupid question at all! But the answer is not so simple. In Lion, as Dave Eliott's XNU dev. site points, there is indeed only one crucial function that actually needs ssse3: just the bcopy.s assembly routine, precisely the one that enables 64-bit support. That's exactly why our Athlon/Phenom CPUs, despite being 64-bit capable, cannot load the 64-bit kernel.

 

Would your idea of workaround work for Lion? 1) Well, the kernel loads first, so by the time the patched kext load to try to bypass the check, the kernel would have already accessed all commpage routines to start itself to run. However, the kext could be a 32-bit one, since Lion still support it, and it could try to reload the kernel - like some weird two stage boot method - and this would lead to 2) the routine is itself the thing that makes Lion 64-bit tick. It's not a check. If bypassed, the system would hang anyway. Instead, we could simply write some kind of executable that runs at kernel level, like a kext, reloading it with 64-bit support enabled (which is different from loading a full 64-bit kernel, but would be something anyway). Taking this at prospect, honestly, to translate the ssse3 instructions or even to write an on-the-fly emulator seems way easier and more feasible.

 

As for Mountain Lion, the problem is the system as a whole is 64 bit: all the kexts were compiled in EMT64 architecture. Even if there's not a routine written specifically to enable 64-bit support (which would be redundant, since it's a full 64-bit kernel and probably there's a routine to enable 32-bit app support - probably the bcopy.s file in the commpage again), a workaround like you suggested would be almost impossible, because since the kernel loads itself firts and it has to run in 64-bit mode to load all the kexts, the patched kext would have to be itself a 64-bit one, but if we could load any 64-bit kext, it would mean that we already have a running 64-bit kernel. Got it? Of course, we could try something like a two stage boot again, loading first the Netkas 32-bit ML kernel, to load our executable which would force the 64-bit support to a second kernel which would load immediately after, this time a patched AMD 64 kernel. Seems complicated? Yes, because it is indeed! We have to cross fingers and hope that there's no crucial task, specially none related to 64-bit CPU support, requiring ssse3 instructions, or we'll have to face the same issues we have with Lion, with one difference: we would not have the option of a -legacy boot; it would be either to emulate the ssse3 instructions or to translate the ssse3 routines to sse3 or not to have Mountain Lion at all!

 

Now that i just saw Jones Bones Jones smashing Belfort just after have his arm almost broken, i'm back to the fight here. The XNU is almost breaking my brain, but i think it will submit in the end.

[theconnactic]

Hi, folks!

 

It does appear that our russian fellas are doing their job, too: http://www.applelife.ru/threads/mac-os-x-10-8-mountain-lion-amd-cpu.37071/

 

At least two developers are working on it: one of them is Bronzovka, a.k.a. Dmitrik, one of the first to develop a successful Lion AMD kernel - which is, by the way, the core for the latest and greatest, from RAWX86.