2466 replies to this topic

[bcobco]

maybe this helps...
there is a patch for modifying cpu instructions to adapt dyld and libSystem.dylib binaries to non intel cpus.
AvN made a kernel (Darwin compu.local 10.8.0 Darwin Kernel Version 10.8.0: ma 22 aug 2011 22:12:25 CEST; legacy kernel v8 :xnu-1504.15.3/BUILD/obj/RELEASE_I386 i386) with that patch built in the kernel. maybe he can drop some ideas

[theconnactic]

That could really help, bcobco. Where is this patch available?

How can i reach AnV out to get some advice? He's not being posting here for a long time; maybe he's too busy to invest time and effort on this kernel subject for now.

Thank you very much!

[bcobco]

look at this thread. with comments from aVn about this patch
http://osx86.co/f36/...-be-nice-t6845/

EDIT
i found a version here
http://www.osx86.net...sn_patcher.html
the other version i found somewhere i dont remember... but i have a copy.
PM me your email and i send you both versions

also, look for the darwin kernel modified by avn (or nawcom) against the original darwin source code to see what things change.

[theconnactic]

Thank you, bcobco: i'll check this out ASAP.

[SS01]

This is something that's been in the back of my head for a while... I'm taking a look at the XNU sources, given how much I know about programming (basic C++) I doubt I'll get anywhere, but if I find/do anything interesting I'll be sure to let you know. Also, I will offer myself for beta testing too - doubt a Deneb Phenom is really what you're after, but it can't hurt to volunteer can it?

[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   6.27MB   18 downloads), booting with raw64bit archx86_64 npci=0x3000 -v to boot 10.8.0 and got this result:

 kernelpanicwithraw64bit.jpg   507.97K   127 downloads  kernelpanicwithraw64bit.jpg   507.97K   127 downloads

(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 by theconnactic, 19 September 2012 - 07:20 PM.

[SS01]

theconnactic, on 19 September 2012 - 04:52 PM, said:

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]

theconnactic, on 20 September 2012 - 01:53 PM, said:

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 <i386/asm.h>
/* 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 < dst? */
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)

Lordadmiral Drake, on 21 September 2012 - 09:23 AM, said:

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 by theconnactic, 21 September 2012 - 06:53 PM.

[tdtran1025]

theconnactic, on 04 August 2012 - 01:04 AM, said:

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.