10.7.4 AMD Kernel

[The Connactic]

The fight isn't over, but for the fight to be won, it's not enought for Mountain Lion to be here if it does not roar in AMD Hackintoshes, lol.

[akimoa]

i do have ML running just looking into the programms next too xcode we need wich prob be

cxxfilt-11

dtrace-96

kext_tools-268.7

but i cant figure out wich version of bootstrap_cmds it is

maybe someone else can ? meanwhile i dl new xcode .....i might get it up and running by tonite and give it a shot ..but my timeframe is limited so will se if i get it goin

[pipko]

Originally Posted by akimoa i do have ML running just looking into the programms next too xcode we need wich prob be cxxfilt-11 dtrace-96 kext_tools-268.7 but i cant figure out wich version of bootstrap_cmds it is maybe someone else can ? meanwhile i dl new xcode .....i might get it up and running by tonite and give it a shot ..but my timeframe is limited so will se if i get it goin

is your ML run on amd or intel?

[akimoa]

on a Commodore C16 +4

na on a MacBookPro

[sulphide]

Differences between AMD64 and EM64T
There are a small number of differences between each instruction set. Compilers generally produce binaries that target both AMD64 and EM64T, making the differences mainly of interest to compiler developers and operating system developers.


Currently
EM64T’s BSF and BSR instructions act differently when the source is 0 and the operand size is 32 bits. The processor sets the
zero flag and leaves the upper 32 bits of the destination undefined.

AMD64 supports 3DNow! instructions. This includes prefetch with the opcode 0x0F 0x0D and PREFETCHW, which are useful for hiding memory latency.

EM64T lacks the ability to save and restore a reduced (and thus faster) version of the floating-point state (involving the FXSAVE and FXRSTOR instructions).

EM64T lacks some model-specific registers that are considered architectural to AMD64. These include SYSCFG, TOP_MEM, and TOP_MEM2.

EM64T supports microcode update as in 32-bit mode, whereas AMD64 processors use a different microcode update format and control MSRs.

EM64T’s CPUID instruction is very vendor-specific, as is normal for x86-style processors.

EM64T supports the MONITOR and MWAIT instructions, used by operating systems to better deal with Hyper-threading.

AMD64 systems allow the use of the AGP aperture as an IO-MMU. Operating systems can take advantage of this to let normal PCI devices DMA to memory above 4 GiB. EM64T systems require the use of bounce buffers, which are slower.

SYSCALL and SYSRET are also only supported in IA-32e mode (not in compatibility mode) on EM64T. SYSENTER and SYSEXIT are supported in both modes.

Near branches with the 0×66 (operand size) prefix behave differently. One type of CPU clears only the top 32 bits,
while the other type clears the top 48 bits.

may smth. of this be the clue?

[The Connactic]

It just has come to my mind: we have patches for AMD, made by bronzovka and rawx86. Using some text tool, can't we just separate the specific AMD instructions by comparing with the vanilla source and then apply them to the Mountain Lion source? Or even better, following and useful advice from Meklort, apply them as a binary patch to the Mountain Lion binary? It would be possible to test it?

If yes, i'm willing to do it and make the experiment. Can someone point me to some text tool that make possible to compare and extract the differences between two texts (these would be the patched kernel and the vanilla kernel) saving me the time to do it by eye, so i can re-patch it and compile it for mountain lion instead?

Can someone explain me what tools and procedures do i use to apply a binary patch to the binary kernel?

[R:A:W:X86]

Originally Posted by The Connactic It just has come to my mind: we have patches for AMD, made by bronzovka and rawx86. Using some text tool, can't we just separate the specific AMD instructions by comparing with the vanilla source and then apply them to the Mountain Lion source? Or even better, following and useful advice from Meklort, apply them as a binary patch to the Mountain Lion binary? It would be possible to test it?

The answer is no, it ain't that easy.
The main reason has already been discussed at great length in this thred.
It is, that the current patch works for i386 Kernel only, which is no longer part of Mountain Lion. It can be compiled from the source code, but is actually useless as all the Kernel Extensions are x86_64 only as well.

Also the new XNU comes up with some major code changes.

I am currenlty doing some experiments on this - but you should not expect a working solution - especially not within a short time.

Can someone point me to some text tool that make possible to compare and extract the differences between two texts

FileMerge - it's part of Xcode.

[The Connactic]

Originally Posted by R:A:W:X86 I am currenlty doing some experiments on this - but you should not expect a working solution - especially not within a short time.

Raw, what about your Mountain Lion experiments? Any success?

I don't know if i said it before, but thank you for the FileMerge tip.

[The Connactic]

As for me, i expect it not to be the clue. If we have to emulate more instructions yet than ssse3, then i think AMD hackintoshing is really at the verge of obsolescence.

[justinster123]

I compiled a 10.7.4 kernel with a mix of patches with R:A:W 's patches and the anv's legacy kernel 0.5.1 for on the fly patching, it boots up for x86_64 and i386 without instant reboot. but gives a kernel panic near where launchd would start up...
I'll upload it soon for you to test.. I doubt you'll get any further than the KP tho, interesting that I am the only one who made a kernel that didn't instantly reboot....
http://www.mediafire.com/download.php?u3kbvqy9it4sjda