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

[MacFaulty]

Hello, good people!

 

Sorry not giving any news this day-and-a-half.

 

As i told you all, i was trying to compile the result of the 10.8 xnu kernel with the patches provided by the diff from RAWx86 (generated from his winner Lion 10.7.4 kernel). Instead of doing it using the patch command from terminal (process which i already did, with no luck), i underwent a long and arduous work of copy-pasting, from which i acquire new TextEdit usage skills that will be with me for life. But the work isn't finished yet. I'm having issues!

 

The result was kinda difficult to compile: as RAW and a lot of other wiser guys had already told me, the codes has changed. Lots of small adjustments had to be done to the patches so those errors went away. This tedious work anyway provide me with some good knowledge about kernel patching for AMD is (being) done (at least until now). The crucial changes made by the patches from RAW (in fact, based on anterior patches from Bronzovka, AnV, meklort and many others) affected cupid, as we already knew, but many other files also (i'll post later a comprehensive list of files affected). Some of them, like IOcatalogue.cpp, gave me some hard times to adapt to patches that, good or bad, were made for a different iteration of OSX. Now i have some other candidates for ssse3-issues investigation: start.s and idt.s and idt64.s. These patches created some new files and headers and, given the complexity of them as a whole, should have needed a lot of hard work to be made. We should be very grateful to the people who disposed of sometimes precious spare time to help us.

 

The issues that i'm having now? Well, the errors are all gone. The kernel compiles almost to the end. Almost. The problem is the linker, now:

 

 

Undefined symbols for architecture x86_64:

"_BUG", referenced from:

_get_amd_cache_info in cpuid.o

"_DBG", referenced from:

_cpuid_set_info in cpuid.o

_cpuid_vmm_info in cpuid.o

"_cpuid_get_names", referenced from:

_cpuid_get_leaf7_feature_names in cpuid.o

_cpuid_feature_display in cpuid.o

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

make[2]: *** [/users/jimihendrix/Desktop/XNUVIRGEM2/BUILD/obj/RELEASE_X86_64/./mach_kernel] Error 1

make[1]: *** [build_all] Error 2

make: *** [all] Error 2

 

Anyone who comes with a solution for this would be helping a lot. We're almost there! I think, sincerely, that this patches could be the foundations of an actually working Mountain Lion kernel for AMD and legacy Intel users, even if it at first only works with Bulldozer CPUs or doesn't get to the user land at all. But first, we must have a mach_kernel to experiment with. We're making it! I'm counting on any help i can have now.

 

 

 

 

Hi, spakk!

 

Thank you for your ideas! In fact, i already did the experience with those proposed changes, and the result was unusable. But i could've well done something wrong, so i'll download your code and build it: we should give everything a shot! Unfortunately, as you can read in the post above, i'm in the middle of another experience, a promising one, so i can't guarantee i'll make the kernel from your code today or tomorrow, but i'll do it, be sure.

 

Thanks for that AMD link: i downloaded the microcode. Don't know if it's going to be useful, or for what, any bit of something we can get now could be potentially helpful. Thanks and keep in tune.

 

That the errors are gone is a beginning (far beginning). I hope you can make it. Next year I'll get a class in Application Developer which I will graduate in (takes me 3 years, but hey) and then I might also be of some help to you. But for now I'll stick to beta testing. hahah

[zchef2k]

Can you pastebin cpuid.o?

[Lordadmiral Drake]

.o files are already compiled, you won't really find anything there

[theconnactic]

To my dismay, i just found out that the issues i went through when trying to build the kernel are Xcode related: i cannot build any Xnu using any architecture, even when linking to the correct libraries. Perhaps i just should reinstall it from scratch.

 

Anyway, to save time, i generated a diff file from the kernel i made with RAWx86's Lion patches (many thanks to him, and to Bronzovka, Andy Vandjick, the Voodoo team, meklort and others, since the patches are based on their previous work), adapting them to the code changes of Mountain Lion (just minor adaptations, let's see if it works).

 

Here's the file: xnu.diff.zip

 

P.S.: to learn how to apply a diff: http://jungels.net/a...en-minutes.html

 

P.P.S.: it's for Mountain Lion, and it's not guaranteed to work, since the patch was designed originaly by RAWx86 to work with Lion 10.7.4. Probably won't work with Lion either, since it's kind of a stripped-down version of the original (sorry, Pooky).

 

P.P.P.S.: Keep in mind: this is totally untested: in my machine, i couldn't even generate the mach_kernel executable because of Xcode issues. If you want to try to compile and use it, do at your own risk. It's here for experimental reasons, so we can someday get a fully working kernel for AMD and legacy Intel machines. Again, this is not the work done!

 

P.P.P.P.S.: i someone manages to compile it, please upload the resulting mach_kernel to this topic.

[spakk]

To my dismay, i just found out that the issues i went through when trying to build the kernel are Xcode related: i cannot build any Xnu using any architecture, even when linking to the correct libraries. Perhaps i just should reinstall it from scratch.

 

Anyway, to save time, i generated a diff file from the kernel i made with RAWx86's Lion patches (many thanks to him, and to Bronzovka, Andy Vandjick, the Voodoo team, meklort and others, since the patches are based on their previous work), adapting them to the code changes of Mountain Lion (just minor adaptations, let's see if it works).

 

Here's the file: xnu.diff.zip

 

P.S.: to learn how to apply a diff: http://jungels.net/a...en-minutes.html

 

P.P.S.: it's for Mountain Lion, and it's not guaranteed to work, since the patch was designed originaly by RAWx86 to work with Lion 10.7.4. Probably won't work with Lion either, since it's kind of a stripped-down version of the original (sorry, Pooky).

 

P.P.P.S.: Keep in mind: this is totally untested: in my machine, i couldn't even generate the mach_kernel executable because of Xcode issues. If you want to try to compile and use it, do at your own risk. It's here for experimental reasons, so we can someday get a fully working kernel for AMD and legacy Intel machines. Again, this is not the work done!

 

P.P.P.P.S.: i someone manages to compile it, please upload the resulting mach_kernel to this topic.

 

Hi theconnactic,

 

Once a great praise for your quick processing of patches

at the moment I'm not at home. When I'm back home tonight, I will test the patch immediately and give you information

 

 

Hi theconnactic,

 

which xcode version do you use? beta version or the xcode 4.5?

[theconnactic]

Xcode 4.5

[zchef2k]

My hat's in the ring now. I've patched the xnu source, tried to compile it and got to the same undefined "_BUG" error. First one to post a compiled kernel wins.

 

Changed my handle back to 'zchef2k' from 'byt3m3.'

[spakk]

Patch with the last kernel of RAV brought no success. I will make tomorrow another try

[ZackehSoul]

I want to apologise if this seems too negative (also, I only read the first couple of pages before this post so I may be outdated):

 

In all honesty I really don't see this going very far for a very long time. The code changes between Lion and Mountain Lion will be massively different even if it doesn't seem it at first. Getting something to compile doesn't mean it's going to work, and even if it does actually run at all there's no telling what kind of breakages there will be in the system, and it's highly likely there will have to be some emulation written in there to deal with everything in the correct way. Since the Mountain Lion kernel is an advancement on the Lion kernel, I agree it would make sense to move through Lion to Mountain Lion which gives a better starting point rather than using patches that weren't even correctly implemented in the Lion AMD kernels. I'm aware there were several AMD kernels flying about for Lion, but they were all exceptionally buggy at best (correct me if there was one which was flawless). To me it would seem that perfecting Lion on AMD would be the logical next step, as we're not taking too big a jump at once.

 

I do agree that this is a worthwhile thing to look into, but expecting results so soon is probably a bit overoptimistic. It took months and months of work to get a partially working kernel for Lion and we're all talking about the end product here after about two months (by self-proclaimed beginners).

 

Don't get me wrong, I think it's great that it's turned into some kind of "community kernel" so to speak and I'd gladly contribute, I just think getting ahead of ourselves could cause a lot of frustration.

 

P.S. That's my view without looking at the source (well, recently), and the patches that you've all put together - my apologies if you're actually further than I expect.

[theconnactic]

I want to apologise if this seems too negative (also, I only read the first couple of pages before this post so I may be outdated):

 

Hi, Zack!

 

Sometimes a sober and somber tone can help us to put things in perspective. A reality check is never a bad thing, and not much like pure and irrational pessimism/fatalism. So, no harm done: let's keep calm and carry on.

 

In all honesty I really don't see this going very far for a very long time. The code changes between Lion and Mountain Lion will be massively different even if it doesn't seem it at first. Getting something to compile doesn't mean it's going to work, and even if it does actually run at all there's no telling what kind of breakages there will be in the system, and it's highly likely there will have to be some emulation written in there to deal with everything in the correct way.

 

I think you got it right. It's a mid-to-long term goal. Compile the kernel is just the beginning of the beginning. A necessary step, though, and we must keep in mind that every little step we make is one step closer to our goals. Worths the effort!

 

Since the Mountain Lion kernel is an advancement on the Lion kernel, I agree it would make sense to move through Lion to Mountain on which gives a better starting point rather than using patches that weren't even correctly implemented in the Lion AMD kernels. I'm aware there were several AMD kernels flying about for Lion, but they were all exceptionally buggy at best (correct me if there was one which was flawless). To me it would seem that perfecting Lion on AMD would be the logical next step, as we're not taking too big a jump at once.

 

There's at least one, precisely the one i used to do this first experience. It works flawlessly on Bulldozer CPUs, with 64-bit user land and performance akin to Intel counterparts. Unfortunately, not the broad support we desired, but it is something indeed. Your suggestion - PookyMacMan proposed more or less the same - is quite reasonable. I opted the other way, but nothing prevents you or anyone else to start researching a better Lion kernel, and that research would be of course interchangeable with Mountain Lion's and very valuable to it, as you correctly perceived.

 

I do agree that this is a worthwhile thing to look into, but expecting results so soon is probably a bit overoptimistic. It took months and months of work to get a partially working kernel for Lion and we're all talking about the end product here after about two months (by self-proclaimed beginners).

 

You're absolutely right on the money here. I said it before, including above in this very post, but it's never to much to stress it: we'd better be not expecting results in the short term. But i'm afraid i must add just this: Mountain Lion's source was released comparatively sooner since its release than Lion's. This surely makes our prospect better, compared to the Lion days. On the other side, in Lion days, we had the real deal at our side, the experienced kernel gurus of the community. Now only the beginners like me have stepped in until now. It perhaps makes things a little bit difficult but hey!, someone has to do the job.

 

Don't get me wrong, I think it's great that it's turned into some kind of "community kernel" so to speak and I'd gladly contribute, I just think getting ahead of ourselves could cause a lot of frustration.

 

Yeah, that's the fun of it. That's the meaning of the whole thing, isn't it? To have fun! To learn. To enjoy a great OS on my cheap about-average PC in the best way possible. Quoting myself, if i have to spend lots of money (hey, i'm not rulling out spending some in supported and cool peripherals, and i myself did it more than once) assembling a whole new computer with natively supported parts, i would be better switching to a Mac.

 

P.S. That's my view without looking at the source (well, recently), and the patches that you've all put together - my apologies if you're actually further than I expect.

 

Nevermind. Wanna jump to the boat? We need every help we can gather to row and sail through the troubled waters of the AMD hackintoshing seas!

 

About the building issues, meklort point me yesterday to the probable cause of the problem: "somebody" (that is, me) forgot to define BUG and other macros.

 

The fact is that the patches were so tiresome and time-consuming (remember, i did some of them using copy and paste directly to the sources, whenever the patch command failed to do it because of the Mountain Lion code changes) that i simply decided to upload the result here and let others help me to investigate the issue.

 

Could be a Xcode issue too, since i downloaded the 10.7.5 XNU and it fails to build here, either in i386 or x86_64 architectures. The 10.8 vanilla XNU, however, builds just fine, so maybe i'm doing something wrong.

[theconnactic]

About the ssse3 emulator: would be preferable if we had access to the source of the Voodoo's sse3emu to have some ideas about how to properly write and implement an emulator, since it was a highly successful one. But the sources aren't anywhere! Writting from scratch will indeed be a real pain.

 

Googling about the subject, i found this: https://lkml.org/lkml/2012/1/25/112. Is about sse3, not ssse3, but any info we can gather will be highly helpful.

[theconnactic]

Update: well, meklort shared the old maxus' sse3 emulator link with me, and i'm sharing it here with you, folks: http://pastebin.com/cQe9aSYV

 

It's in assembly language. Hard, huh? First, we must decipher what makes it tick. Second, upgrade it so it add support for ssse3 (easier talking than doing, i know).

[theconnactic]

I am not a C programmer. Bear with me.

 

Neither i am, if "C programmer" means someone who develops C codes for a living. You're doing just fine.

 

theconnactic, I can get past the error you presented in #102.

 

Are you sure you're getting past the error? Seems to me that the error that you're getting now happens before the point the issue i reported should occur. Open please the XNU directory/Build/Release: what folders do you see?

 

Is cpuid_get_names no longer defined in cpuid.c after the patch is applied?

 

It seems. Maybe adding it back indeed solves the issue. I'll give it a shot later.

[theconnactic]

Here's the exact point where the error i get happens. Indeed is shortly after LDFILELIST:

 

 

LDFILELIST bsd

CC lastkernelconstructor.o

CC version.o

LD mach_kernel.sys

Undefined symbols for architecture x86_64:

"_BUG", referenced from:

_get_amd_cache_info in cpuid.o

"_DBG", referenced from:

_cpuid_set_info in cpuid.o

_cpuid_vmm_info in cpuid.o

"_cpuid_get_names", referenced from:

_cpuid_get_leaf7_feature_names in cpuid.o

_cpuid_feature_display in cpuid.o

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

make[2]: *** [/users/jimihendrix/Desktop/XNUPATCHED/BUILD/obj/RELEASE_X86_64/./mach_kernel] Error 1

make[1]: *** [build_all] Error 2

make: *** [all] Error 2

 

Here's the folders i have at the BUILD/obj/RELEASEX86_64 after the build fails:

 

 

/BUILD/obj/RELEASE_X86_64/bsd/

/BUILD/obj/RELEASE_X86_64/iokit/

/BUILD/obj/RELEASE_X86_64/kernel-kpi.exp

/BUILD/obj/RELEASE_X86_64/kgmacros

/BUILD/obj/RELEASE_X86_64/lastkernelconstructor.d

/BUILD/obj/RELEASE_X86_64/lastkernelconstructor.o

/BUILD/obj/RELEASE_X86_64/lastkernelconstructor.o.ctf

/BUILD/obj/RELEASE_X86_64/libkern/

/BUILD/obj/RELEASE_X86_64/libsa/

/BUILD/obj/RELEASE_X86_64/link.filelist

/BUILD/obj/RELEASE_X86_64/osfmk/

/BUILD/obj/RELEASE_X86_64/pexpert/

/BUILD/obj/RELEASE_X86_64/security/

/BUILD/obj/RELEASE_X86_64/version.c

/BUILD/obj/RELEASE_X86_64/version.d

/BUILD/obj/RELEASE_X86_64/version.o

[zchef2k]

Deleted my earlier post. It was off track and adds to clutter. I have no evidence my reintroduction of get_names to cpuid.c made any difference.

 

Continuing on...

[theconnactic]

Oh, i forgot to tell: meklort sent me yesterday an old diff, from Leopard times, that have inside a 64-bit sse3 bcopy.s, and that same diff mentions a sse3 emulator (unfortunately, that emulator isn't really there).

 

The link: http://xnu-dev.googlecode.com/files/voodoobuild-0.3.0.tar.bz2

[theconnactic]

UPDATE! It compiled! It compiled!

 

Who wants to test it first?

 

If someone actually gets to the console (because i don't think it will really boot to the desktop or even to Launchd) please post pictures. Everybody report back. Later i'll post the diff. The problem was indeed at cpuid.c, as i thought, and i solved it in a clumsy way: "commented" the offending functions.

 

Unzip it, put at the root of your OSX disk and boot with the flag "con" (without the quotes):connactic.zip

[Lordadmiral Drake]

You might want to rename that file. I just wanted to download it under Windows 7 and it said that the filename con is system reserved

Also, what kernel version is this? 10.8.0, 10.8.1 or 10.8.2?

[theconnactic]

Hi, LordAdmiralDrake!

 

I used "con" without issues, but that may be because i don't use Windows at all, despite having it installed on a PATA disk. Rename it at will, but don't use mach_kernel, since it would replace your original kernel. It's the 12.0 (10.8.0) Darwin kernel.

 

Post your results: i got a panic and will post a screenshot later, as soon as i charge my iPad a little.

 

Anyway, i changed the name, just in case you cannot do it at all.

[Lordadmiral Drake]

Well, my hackintoshs HDD is quite flaky and often needs several restarts before being recognized in the bios in order to boot up my Lion installation

[theconnactic]

My kernel panic (sorry for the bad bad photo):

 

 

As you cannot see (again, sorry), my panic had com.apple.kec.corecrypto (1.0) in backtrace. I googled immediately, still no useful info.

[bcobco]

in my system, it blanks screen but immediately turns back to boot loader. i cannot see messages.

 

maybe the best way to test is in a working osx-10.8 system

[PookyMacMan]

Lordadmiraldrake, first off you are using Mountain Lion? Not Lion?

 

Second, you could always see if you can find an Apple kext in S/L/E with a similar name and then remove it...

 

theconnactic, good find! And that emulator you mentioned earlier...the Leopard kernels indeed had an SSE3 emulator, and a good one too. But you either forgot the extra S in your post or didn't remember that we want an SSSE3 emu.

[spakk]

UPDATE! It compiled! It compiled!

 

Who wants to test it first?

 

If someone actually gets to the console (because i don't think it will really boot to the desktop or even to Launchd) please post pictures. Everybody report back. Later i'll post the diff. The problem was indeed at cpuid.c, as i thought, and i solved it in a clumsy way: "commented" the offending functions.

 

Unzip it, put at the root of your OSX disk and boot with the flag "con" (without the quotes):connactic.zip

 

 

Hi theconnactic , I will test them and then i will inform you.

[zchef2k]

in my system, it blanks screen but immediately turns back to boot loader. i cannot see messages.

 

maybe the best way to test is in a working osx-10.8 system

 

Same here. What bootloader should we be using for this testing? I'm currently using Chameleon 3255.

 

Good work on the compile, theconnactic.