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

[Lordadmiral Drake]

In Win7 I went to kernel source code root folder and then entered Content: *text* in the search field. Don't know for OS X however

 

EDIT: Did a search for amd and found it in following files:

 

..\bsd\security\audit\audit_bsd.c

..\osfmk\i386cpuid.h

..\bsd\dev\i386\dis_tables.c

..\bsd\sys\dtrace.h

..\bsd\dev\i386\fasttrap_isa.c

..\bsd\dev\i386\fasttrap_regset.h

..\bsd\dev\i386\fbt_x86.c

..\bsd\kern\kern_fork.c

..\bsd\dev\memdev.c

..\bsd\nfs\nfs.h

..\bsd\sys\sdt_impl.h

..\osfmk\i386\trap.c

[theconnactic]

in cpuid.c

/* this function is Intel-specific */
static void
cpuid_set_cache_info( i386_cpu_info_t * info_p )

/* verify we are running on a supported CPU */
if ((strncmp(CPUID_VID_INTEL, info_p->cpuid_vendor,
 min(strlen(CPUID_STRING_UNKNOWN) + 1,
sizeof(info_p->cpuid_vendor)))) ||
(cpuid_set_cpufamily(info_p) == CPUFAMILY_UNKNOWN))
panic("Unsupported CPU");
info_p->cpuid_cpu_type = CPU_TYPE_X86;
info_p->cpuid_cpu_subtype = CPU_SUBTYPE_X86_ARCH1;

 

in fpu.c

/* Advertise SSE support */
if (cpuid_features() & CPUID_FEATURE_FXSR) {
fp_kind = FP_FXSR;
set_cr4(get_cr4() | CR4_OSFXS);
/* And allow SIMD exceptions if present */
if (cpuid_features() & CPUID_FEATURE_SSE) {
set_cr4(get_cr4() | CR4_OSXMM);
}
fp_register_state_size = sizeof(struct x86_fx_thread_state);
} else
panic("fpu is not FP_FXSR");

/*
* SSE arithmetic exception handling code.
* Basically the same as the x87 exception handler with a different subtype
*/
void
fpSSEexterrflt(void)

there are a lot of things to look at. i think that with proper knowledge, it should be possible to make darwin/xnu completely compatible with generic x86 and x86_64 architectures, not only intel specific hardware.

 

 

 

one legal question: can be forked the xnu source; in github, sourceforge, googlecode, or whatever public repository?

the idea is to create a darwin/xnu68 project. actually it seems that there is no project with this objetive (if there is some official project, lets join it.)

 

 

Thank you very much, bcobco! I was intending to check cpuid.c last night, but i couldn't stand it - needed to get some sleep. Very useful info, and by putting together every piece, we're slowly solving this puzze.

 

As for you questions, 1) have in mind that i'm no lawyer, but i think that, being Darwin open source, there'd be no issues about forking it elsewhere and anyhow and 2) interesting idea of yours about that versions of Darwin. Your point is reasonable, but i think it would not be possible. See - Lion XNU is also Darwin: can we run Mountain Lion with it? No, we cannot. It's not just a question of having a CPU-agnostic version of Darwin; to run Mountain Lion, its associated specific version of Darwin should be either all-x86 compatible or hacked for AMD machines. But, well, we could compile it - the other Darwins - and try it just to see what happens.

 

LordAdmiralDrake, Well done! Very very valuable.

[bcobco]

Thank you very much, bcobco! I was intending to check cpuid.c last night, but i couldn't stand it - needed to get some sleep. Very useful info, and by putting together every piece, we're slowly solving this puzze.

 

As for you questions, 1) have in mind that i'm no lawyer, but i think that, being Darwin open source, there'd be no issues about forking it elsewhere and anyhow and 2) interesting idea of yours about that versions of Darwin. Your point is reasonable, but i think it would not be possible. See - Lion XNU is also Darwin: can we run Mountain Lion with it? No, we can. It's not a question of having a CPU-agnostic version of Darwin; to run Mountain Lion, its associated specific version of Darwin should be either all-x86 or hacked for AMD machines. But, well, we could compile it - the other Darwins - and try it just to see what happens.

 

LordAdmiralDrake, Well done! Very very valuable.

 

yeah thats true, but i think thats because because osx-10.8 runs over darwin-12, and osx-10.7 runs on top of darwin-11. something similar would happen if you run osx-10.5 that runs over darwin-9, over another darwin version different from version 9.

not sure about this but seems logic. please correct me if im wrogn.

 

i mean, if you fork an arbitrary darwin version, the osx version must correspond to it.

http://en.wikipedia.org/wiki/Darwin_(operating_system)#Mascot

[theconnactic]

No, bcobco: you point seems quite reasonable to me. Really worth a try, why not? (remember that Puredarwin is a complete OS; what would be helpful for us, in theory, is its kernel)

 

EDIT: Puredarwin's kernel is out of question, at least for Mountain Lion. See why (http://www.puredarwin.org/developers/repository):

 

 

ARCH

Target the architecture.

ARCH="i386"

At this time, only "i386" is supported, but we're convinced that minor efforts (e.g., adapting bootloader steps to different OpenFirmware, adding some needed projects specific/related to the PPC support in "pd_roots", etc...) should be involved in order to bring PPC support in Darwin 9. Idem for "X86_64".

Feel free to help us in this quest too.

[PookyMacMan]

Hi, Pooky! Thanks for the answer.

 

Perhaps i can "define the define" (forgiven!): it's a C preprocessor directive that tells the preprocessor to replace with a specific value any ocurrence of a given character string. Its syntax is:

 

#define name_of_the_macro body_of_the_macro

 

where the name of the macro is the character string and its body, the value specified.

 

For exemple, #define CPUID_FEATURE_SSSE3 _HBit(9) replaces the character string CPUID_FEATURE_SSSE3 for the value _HBit every time it appears in the file.

 

Or, at least, it's what i learned. There's people more skilled than i am that could wish to correct what i just wrote.

I have a feeling that will be useful later on, thanks for that tip.

 

The PureDarwin issue: PureDarwin, though it does use a Darwin kernel, is more like Linux than Mac OS. The troubles I believe that AMD (and legacy Intel) people have are related to non-Darwin (a.k.a. OS X-specific) components. Although the changes needed for AMD/legacy Intel are in the kernel, the original problems occur (in my knowledge) because of interactions between the Mac OS components (kexts, system daemons etc.) and the kernel.

 

Also, something I'd like to know is whether or not getting legacy Intel to work would require the same work as AMD or more/less, or if it must be a totally different approach...I know that the main topic is AMD, but me and many others also have legacy Intel boxes.

 

Another thing I'm thinking is...let's stick with Lion XNU for now. ML has, from what I can see, a lot more architectural differences than Lion, so probably fixing Lion's issues first is the best idea.

 

Legality of forking XNU: totally legal. That's why we have patched kernels; an example of an actual code repository would be the old Voodoo kernel, produced back when dinosaurs of OSx86 roamed the earth (10.5)

[theconnactic]

I have a feeling that will be useful later on, thanks for that tip.

 

You're welcome, Pooky!

 

The PureDarwin issue: PureDarwin, though it does use a Darwin kernel, is more like Linux than Mac OS. The troubles I believe that AMD (and legacy Intel) people have are related to non-Darwin (a.k.a. OS X-specific) components. Although the changes needed for AMD/legacy Intel are in the kernel, the original problems occur (in my knowledge) because of interactions between the Mac OS components (kexts, system daemons etc.) and the kernel.

 

Yeah, it's that why we have to be careful with what we change. If there's some crucial kernel task requiring ssse3, for an example (and in Lion it seems that's the case for 64-bit support, according to David Elliot's page), simply erasing or bypassing ssse3 calls and checks won't solve anything: we'll have to substitute them for sets of supported instructions that do the same thing. Could be even worse: for example, suppose there's no crucial task that uses those much discussed ssse3 instructions in the kernel itself, but important kernel extensions were written taking those instructions for granted? This is an awful prospect. In this case, we'll need a runtime ssse3 emulator, precisely the thing that we're trying to avoid at all costs.

 

Also, something I'd like to know is whether or not getting legacy Intel to work would require the same work as AMD or more/less, or if it must be a totally different approach...I know that the main topic is AMD, but me and many others also have legacy Intel boxes.

 

I think that's the same principle, the same idea. The ideal scenario (and meklort expressly advised me to seek it) is not to simply add AMD patches, but to hinder the CPU ID checks and replace the modern-Intel-only CPU instructions calls, if needed, with ones that permit the kernel and extensions to run on the largest array possible of x86 CPU models.

 

Another thing I'm thinking is...let's stick with Lion XNU for now. ML has, from what I can see, a lot more architectural differences than Lion, so probably fixing Lion's issues first is the best idea.

 

I'm not sure if i agree here. Mountain Lion drops support to more hardware than Lion, that's a certainty, but that doesn't mean that solving its issues with unsupported hardware, as far as the kernel is concerned, would be more problematic than with Lion already was. Besides this, Lion issues, in a certain way, are solved: we can alread run it on a vast collection of otherwise unsupported hardware, either by simply patching it (Atom CPUs) or add the boot flag -legacy to the patches so it runs 32-bit, yet badly (older AMD and Intel CPUs). Mountain Lion, by its turn, runs only on natively supported hardware until now, except for Atom CPUs (thanks to meklort expertise), which by their own turn were once supported by Apple. And it's a newer, better, way cooler OS than Lion is. So i think the benefits are bigger, the prize, better. Of course it's just my opinion here.

 

Legality of forking XNU: totally legal. That's why we have patched kernels; an example of an actual code repository would be the old Voodoo kernel, produced back when dinosaurs of OSx86 roamed the earth (10.5)

 

Good to know i was right.

 

Thank you for answering.

[SS01]

Tons of posts!

Update: already there, already being trolled, lol. But i'm failing to join the rooms you told me to, Pooky. I'm getting this annoying message:

 

You need to identify with network services to join the room "#lion" on "irc.osx86.hu".

 

Another update: joined them, finally. Never used IRC before, so i think i'm forgiven, lol!

 

Uptading again: talked with Nawcom. He was busy, neverthless he answered me. It was a good conversation, and he briefly explained some of the issues he found when he tried to add support for AMD CPUs in Lion, and the real dimensions of the work we're trying to do. We didn't talked much about the ssse3 instructions and how to find them in the commpage though. Instead, we focused on the AMD patches themselves. It was very brief, as i said, and i expect we talk more about it. He is really a nice guy. He told me that he'll even try something with Mountain Lion on his Bulldozer machine. It will be great if he succeds.

 

 

Later, if i can, i'll try to talk with meklort (is his IRC nickname "meklort"?), if he goes online. Any news from this conversation, if it really happens, i'll post here. Thank you, Pooky, for the IRC chat tip.

Forgiven! IRC was invented in 1993 and not a thing has changed since then, so it isn't exactly the most user friendly chat program out there, lol.

Well, i talked to meklort. He was nice, too. Lot of patience with the loads of inept questions i just threw at him, lol.

 

I'm not going to explain what he told me exactly, because i need to understand it first. He told me, however, that someday he could well do something with AMD and Mountain Lion. But don't count on it for now, guys. That someday could well take three years, according to him.

 

By the way, i was right: 3) We know not.

 

It'll take a lot of effort, reading and learning for me to do the job. Alone, to be candid, it's probably above my capabilities for now. Long term goal, my friends. But i'm still on the front.

so it seems that would be nice to create an open project, an official fork of darwin/xnu (in github or similar), to make the kernel compatible with all x86 architecture, capable to handle incompatible instructions of userland code.

 

 

a huge challenge!

A very good idea. I recommend using Google Code - As an advanced Linux user I have experience with GibHub, and trust me, it's a pain.

Legality of forking XNU: totally legal. That's why we have patched kernels; an example of an actual code repository would be the old Voodoo kernel, produced back when dinosaurs of OSx86 roamed the earth (10.5)

 

Yup, definitely legal - the APSL allows you to do anything with it as long as you release the end result under the same licence. (/shot for Canadian spelling)

 

Anycase, just posting to say I'm still alive. Also, I just thought it worth mentioning that I've been using Arch Linux as my desktop OS for quite some time now (yes I prefer OS X, but my choice of hardware has always been so that it's easier to make Linux adapt), so I can help with UNIX stuff if need be.

[theconnactic]

Hello, folks!

 

Today i'm effectively starting to play seriously with the Mountain Lion XNU using the info we're gathering here in this topic (my anterior experiences either involved either applying Lion patches to the Mountain Lion kernel, using the Lion kernels to try to boot Mountain Lion, or use the patched-for-Atom kernel to see what happens).

 

My road map:

 

 

Erase altogether the sss3 mentions (in fact, CPUID_FEATURE_SSSE) at these lines/files (thanks to LordAdmiralDrake for the efforts to find them):

 

- cpuid.c, line 888

- cpuid.h, line 97

- machine_routines.c, line 444

 

Erase this case from the vector unit switch function at the compage.c:

 

case 6:

bits |= kHasSupplementalSSE3;

 

Still in cpuid.c, i intend to remove these lines (thanks, bcobco):

 

/* this function is Intel-specific */

static void

cpuid_set_cache_info( i386_cpu_info_t * info_p )

 

And, of course, eliminate all calls to this function throughout the kernel files.

 

Finally, remove this:

 

if ((strncmp(CPUID_VID_INTEL, info_p->cpuid_vendor,

min(strlen(CPUID_STRING_UNKNOWN) + 1,

sizeof(info_p->cpuid_vendor)))) ||

(cpuid_set_cpufamily(info_p) == CPUFAMILY_UNKNOWN))

panic("Unsupported CPU");

 

Let's see what happens when i compile and put this mutant to work! I'll keep you informed.

[MacFaulty]

Yeah, I just found this topic off of Google and am very excited! If you need a tester, I'll qualify Nice to hear that there's so much going on at the background to get AMD working with ML

 

I've got an AMD Phenom II X4 945 CPU and really would like to get full x64 experience

[bcobco]

Erase

im not really sure but.. just erasing works? maybe it need adapting. some code expects the things you erased. but if it works, hooray!

i would like to help in this modifying kernel code task but i have not the knowledge.

[PookyMacMan]

For testing, I have an idea...

 

Try booting the current AMD kernel on a Lion system in verbose mode and take a pic of the KP that pops up. Then, when we try these kernels (in verbose, of course) we can compare KPs and see if we can find anything.

 

theconnactic, also, since I'm particularly interested in Lion, once you make the changes to the code, how about you create and send me a diff and I can apply it to the Lion kernels and see how that works?

[theconnactic]

im not really sure but.. just erasing works? maybe it need adapting. some code expects the things you erased. but if it works, hooray!

i would like to help in this modifying kernel code task but i have not the knowledge.

 

Precisely, bcobco! I don't expect it to work: my goal is exactly using the error messages i'll get to know which files needs the calls, checks, functions and macros deleted, to investigate to extent of the work that should be done.

 

In fact, i'm not sure if the verbose boot will be enough to get the detailed info i need, and i don't know yet how to debug the kernel using VMware (tried to google it, but no clear explanation; tried to make contact with nawcom to get advice, but he wasn't available at the time).

 

I didn't do any compilation yet. Wan't to take a little more time today to find more things that would be useful to change in the XNU for this first experiment.

 

As for your feelings that you can't effectively help, have in mind that you're helping a lot already.

 

Hey, spakk and Wcool!

 

Thank you for your input, and i expect you guys follow the topic here. We're not even close to a working solution yet, but glad to know this thread sparked interest again for AMD hackintoshing. I'll keep you informed of any advances i made, and - since i am myself no programming expert, just a beginner willing to try, any idea we'll be more than welcome. We're in the same boat!

 

Spread the news: maybe someone more capable than i am feels encouraged to step in and help us.

 

For testing, I have an idea...

 

Try booting the current AMD kernel on a Lion system in verbose mode and take a pic of the KP that pops up. Then, when we try these kernels (in verbose, of course) we can compare KPs and see if we can find anything.

 

theconnactic, also, since I'm particularly interested in Lion, once you make the changes to the code, how about you create and send me a diff and I can apply it to the Lion kernels and see how that works?

 

Remember that's not expected to be a working solution, and that i tried the other way around - that is, to apply the diff from a Lion patched kernel to the Mountain Lion XNU - to no avail, and it was a diff from a patched kernel that's a working and stable version. That said, i'll do what you're asking, of course.

[theconnactic]

Update: it didn't work. Not saying the system didn't boot fine, wasn't the intention; but i couldn't infer anything from this experiments (in fact, two of them: i tried also to use the 10.6.7 bcopy.s instead of ML's, since the bcopy-related issue that added ssse3 support as system requirement for 64-bit support wasn't present in Snow Leopard, i think).

 

The problem is that the boot freezes in a black screen immediately after the point all kexts finish to be loaded, and the console output should show up. No instant reboot, but i wouldn't say it's a victory, since it would be quite the same thing as far as i understand.

 

Back to the drawing board.

[PookyMacMan]

Update: it didn't work. Not saying the system didn't boot fine, wasn't the intention; but i couldn't infer anything from this experiments (in fact, two of them: i tried also to use the 10.6.7 bcopy.s instead of ML's, since the bcopy-related issue that added ssse3 support as system requirement for 64-bit support wasn't present in Snow Leopard, i think).

Actually, the bcopy issue was present back in the Leopard days.

The problem is that the boot freezes in a black screen immediately after the point all kexts finish to be loaded, and the console output should show up. No instant reboot, but i wouldn't say it's a victory, since it would be quite the same thing as far as i understand.

 

Back to the drawing board.

This should be fairly easy to overcome; this just means that one of the cpuid checks failed. You might have missed one. OTOH meklort knows how to fully remove those so you can at least see text flowing.

[theconnactic]

Actually, the bcopy issue was present back in the Leopard days.

 

AFAIK, it wasn't an ssse3 issue, right?

 

This should be fairly easy to overcome; this just means that one of the cpuid checks failed. You might have missed one. OTOH meklort knows how to fully remove those so you can at least see text flowing.

 

But where it is? Help me to find this little runaway!

 

Meklort has been giving me lots of good advices these days, and i can't complain at all, but it seems that he doesn't want to get directly involved with it at the moment and i'll respect his decision.

 

I'm gonna take a look again later tonight, maybe do another experiment. Let's see what i get.

[PookyMacMan]

A quote from the thread I linked:

But what exactly is required to run the retail Leopard DVD and the so-called vanilla (ie Apple-supplied) kernel? Why can't my Pentium D run it?

 

It turns out the kernel performs an explicit check for the CPU 'family'. Only processors in 'Family 6' (or P6 processors) are permitted to boot. Pentium 4 and its derivatives (including Celeron D and Pentium D) are in Family 7 (P7).

 

There are a whole bunch of intel CPUs in the P6 family, but only Core Solo and above have SSE3, thus effectively limiting the kernel to Core processors.

 

64-bit operation adds another level of complexity - the only implementation of a certain routine in the kernel code (bcopy) in 64-bit mode uses SSSE3 (Supplemental SSE3), which - again - only Core and better CPUs have.

Even though he was referring to the Pentium Intel line, it applies to AMD too.

[theconnactic]

Good piece of info, Pooky! Thanks a lot!

 

Why then AMD CPUs before the Buldozer era were able to run 64-bit Snow Leopard? That's the crucial answer now: if there was some alternative road to 64-bit for AMD users with Snow Leopard - and perhaps there was, since running 64-bit Snow Leopard, yet hard as it was, was a reality at a time Bulldozer CPUs didn't even exist - we must know if we can use it in Lion/Mountain Lion. If not, we shall venture to the assembly land and try to change the bcopy.s routine in conformity with our needs.

 

We must not forget that maybe even with a working 64-bit kernel, maybe certain kexts and core services need ssse3 to run properly at 64 bit, so some kind of emulation would be needed - a frightening prospect i hope that does not correspond with reality.

 

P.S.: There is always the possibility of the new bcopy.s routine does not present this ssse3 issue for us. As i said before, i checked it exhaustively and found no ssse3 instruction explicitly used in the assembly code. Maybe, as said before, things aren that straightforward, but even meklort agreed that these instructions could not be there at all.

 

P.P.S.: Tonight i'll try a new approach. Not so new, perhaps, since i'll use RAW's diff of his patched kernel, but this time i'm not intending to simply apply it as a patch, but examine it to see the changes and try to do the same to equivalent files in ML XNU, one by one. Let's see where it can take us.

[bcobco]

Why then AMD CPUs before the Buldozer era were able to run 64-bit Snow Leopard? That's the crucial answer now: if there was some alternative road to 64-bit for AMD users with Snow Leopard - and perhaps there was, since running 64-bit Snow Leopard, yet hard as it was, was a reality at a time Bulldozer CPUs didn't even exist - we must know if we can use it in Lion/Mountain Lion. If not, we shall venture to the assembly land and try to change the bcopy.s routine in conformity with our needs.

as far as i know -with AMD processors- osx-10.6 (snow leopard) is able to run 64-bits in userspace (the flag -force64 enables this). but the kernel space runs in 32-bits. mandatory to boot, the arch=i386 flag.

 

or, im just wrong, and it is possible to run kernelspace in 64-bits?

maibe im wrogn: i have been using osx since a few months ago, there are things that i still dont know very well.. i would really appreciate the clarification.

[theconnactic]

as far as i know -with AMD processors- osx-10.6 (snow leopard) is able to run 64-bits in userspace (the flag -force64 enables this). but the kernel space runs in 32-bits. mandatory to boot, the arch=i386 flag.

 

or, im just wrong, and it is possible to run kernelspace in 64-bits? (maibe im wrogn: i have been using osx since a few months ago, there are things that i still dont know very well.)

 

Me too, bcobco, believe it or not: my first contact with hackintosh was in may, and my first try with it running natively was about july.

 

Supposing you're right, that leads to another question: why on earth can't we get 64-bit userland support with Lion and later, since this ssse3 obstacle was nothing new?

[bcobco]

i dont know. what makes this harder is that information and resources are not as collected as in (for example) debian project, rockbox project, ... i understand this, this does not seem to be easy considering the few people behind the code in comparison those big projects. this does not subestimate the big effort to make osx more open to the world.

[PookyMacMan]

Indeed; the kernel worked so that the kernel ran in 32-bit but you could still run 64-bit applications. All kexts were run in 32-bit, but all userspace could be 64-bit with the force64 flag. This is the way it has worked for the early Intel Mac machines that only had a 32-bit EFI but a 64-bit CPU. However, that support is dropped in ML, hence why the early Core 2 Duo Macs are incompatible.

[theconnactic]

Compiling...

[spakk]

Compiling...

 

Hello theconnactic,

I have revised the data for download here http://www.uploadarea.de/upload/x34992e71kwvormcrgdkr5vaf.html

I made the changes as you have described above.

Unfortunately, I have zero experience in Xcode, please make the kernel.

 

I hope it works

[spakk]

I got this information from the AMD website maybe this information can bring us further

 

http://www.amd64.org/index.php?id=50&file=amd-ucode-latest.tar

[theconnactic]

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.

 

Hello theconnactic,

I have revised the data for download here http://www.uploadare...crgdkr5vaf.html

I made the changes as you have described above.

Unfortunately, I have zero experience in Xcode, please make the kernel.

 

I hope it works

 

 

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.