Jump to content

IM's AMD MAVERICKS TASK FORCE

Sinetek

By Sinetek,
in OS X 10.9 (Mavericks)

 Share
40 posts in this topic

Recommended Posts

Sinetek
Sinetek
Posted
Posted

Hello fellow insaners,

 

 

I'm calling a task force to gather as much information as we can about Mavericks so we can hit the ground running.

 

On the XNU Front:  I am not holding my breadth anytime soon for a source release, but I would be surprised to see none at all get released eventually. People still need to build kexts for this shiny "new" OS, so there's actually a legitimate reason for needing XNU sources. Once we get that, it's on!

 

Failing this, binary patching will be the way to go. Nawcom already provided us with proof that this is viable. I'm sort of expecting us to need a lot more binary patching in the 10.9 days to come.

 

There's been a trend i've been noticing, and the kernel itself is going the way of the Dodo. Everything nowadays is done in proprietary kexts, with no source code given whatsoever. This can only get worse now :-(

 

 

Pressing issues:

 

--- Investigate KEXT signature enforcement, protections. Find a way to caveman beat this down in sources. Binary patch if needed for now, our Intel friends here on the forum will need that, as well as a lot of other folks on the net.

 

--- Bootloader work needed?  

 

-- Check the following:   dyld,  libsystem dylibs.  Do they have SSE3 routines for memcpy, bcopy and friends?  IF NOT, dust off the opemu!!!

 

-- check this  thread, update etc

 

 

Sinetek, who wishes you a good summer from Hot Sunny Budapest!!

  • Like 5
Link to comment
https://www.insanelymac.com/forum/topic/289925-ims-amd-mavericks-task-force/
Share on other sites
theconnactic
theconnactic
Posted
Posted

Hi, Sinetek! Long time, no see.

 

On the XNU Front:  I am not holding my breadth anytime soon for a source release, but I would be surprised to see none at all get released eventually. People still need to build kexts for this shiny "new" OS, so there's actually a legitimate reason for needing XNU sources. Once we get that, it's on!

 

Did previous versions ever get their XNU open source kernel ever released in time? Or only after the official release?

 

 

 

-- Check the following:   dyld,  libsystem dylibs.  Do they have SSE3 routines for memcpy, bcopy and friends?  IF NOT, dust off the opemu!!!

 

How to, without access to the sources? Do you suggest to disassemble each of them and check it by eye, or there's a smooth command line tool to check it for us, if this must be done with binary files?

 

 

 

Failing this, binary patching will be the way to go. Nawcom already provided us with proof that this is viable. I'm sort of expecting us to need a lot more binary patching in the 10.9 days to come.

 

 Do you have access to meklort's kernel patcher source? That could be a good starting point.

 

 

Pressing issues:

 

--- Investigate KEXT signature enforcement, protections. Find a way to caveman beat this down in sources. Binary patch if needed for now, our Intel friends here on the forum will need that, as well as a lot of other folks on the net.

 

--- Bootloader work needed?

 

Chameleon and Clover can already boot Mavericks on Intel machines but Haswell, and RevoBoot boots Haswell just fine. CodeSign enforcement should be an issue for any time soon, and when it does become enforced, seems that crucial hackintosh kexts such as FakeSMC are already exempt by a list-kext provided by Apple (!) itself.

 

 

 

Sinetek, who wishes you a good summer from Hot Sunny Budapest!!

 

Enjoy, man! All the best!

  • Like 1
theconnactic
theconnactic
Posted
Posted

Bronzovka, do you mean that 1] Mountain Lion's kernel is working with Mavericks and stops at launchd? Or 2] Mavericks' kernel itself stops at launchd? If it's case 2], are you using the kernel patcher module? because without it, theoretically, it should give you an ACPI panic for the unidentified CPU. Either way, the kernel stopping at launchd at this early time (that is, without any serious kernel patching) is great news: half of the path is already walked for us.

 

Question: is it possible to locate in the binaries itself the Case/Switch function that's located in the commpage.c and, if it's the case, disable or patch it in the binary itself? If it is, i have a testing proposal...

 

All the best!

Shaneee
Shaneee
Posted
Posted

As hzhjy123 said it would be nice to get 10.8 running sweet first but if we can get 10.9 working at this early stage it would make it easier as it goes through updates. As always I am happy to test each kernel and patch and if I can contribute in anyway I can.

 

Best of luck to the developers.

  • Like 2
theconnactic
theconnactic
Posted
Posted

People, remember that when i started the Mountain Lion kernel project, Lion - the previous system version - wasn't fully working on AMD: only pure 32-bit mode, meaning no core services such as Finder, XPCHelper and ReportCrash crashes that used to render half of the useful apps unusable etc. It was the achievements of the Mountain Lion project (such as the opcode emulator) that made possible to run Lion full featured on AMD with the rock-solid stability we became accustomed. Therefore, i think Sinetek's initiative was appropriate, and perhaps the results will come earlier, since we all learned a lot since then, and pretty sure they will benefit also Mountain Lion users. Right?

 

All the best!

  • Like 2
gils83
gils83
Posted
Posted

:)

 

 

je suis partant pour l'avanture moi aussi , j'ai toujours mon matèriel à disposition :

 

I'm leaving for peradventure I also still have my matèriel available

 

 

- GT 610

- HD 5450

- HD 4850

- FX 6100

-Phenom 960t

- LE 1250

- celeron 341

 

- Acer 8930G core2duo / maveriks/mountain/w7

Bronya
Bronya
Posted
Posted

Bronzovka, do you mean that 1] Mountain Lion's kernel is working with Mavericks and stops at launchd? Or 2] Mavericks' kernel itself stops at launchd? If it's case 2], are you using the kernel patcher module? because without it, theoretically, it should give you an ACPI panic for the unidentified CPU. Either way, the kernel stopping at launchd at this early time (that is, without any serious kernel patching) is great news: half of the path is already walked for us.

 

Question: is it possible to locate in the binaries itself the Case/Switch function that's located in the commpage.c and, if it's the case, disable or patch it in the binary itself? If it is, i have a testing proposal...

 

All the best!

Hi ! I patched kernel and tested on FX. Stop at "launchd" . I dunno how fix Libsystem.B.dylib and others ... I think it is protection . I no continue .

  • Like 1
gils83
gils83
Posted
Posted

:)

 

je pense que c'est  la démarche de comprendre ML 10.8 qui nous a  permit de comprendre et d'avoir Lion 10.7 i386 ootb sur nos machine AMD , comme cette action est porteuse , pourquoi pas maveriks ? qui pourquoi pas règlerait nos problèmes sur ML 10.8 ?

 

une instruction corrompu de CPU AMD , peut-être ? pourquoi NV fonctionne X86_64 sur ML DP2 ? beaucoup de question et peu de réponse ?

 

I think this is the approach to understand ML 10.8 which allowed us to understand and have Lion 10.7 i386 ootb our AMD machine, as this action is carrier maveriks why not? that why not solve our problems on 10.8 ML?


a corrupted instruction AMD CPU, perhaps? why NV works on X86_64 ML DP2? many questions and few answers?

 
 
3.14r2
3.14r2
Posted
Posted

CodeSign enforcement should be an issue for any time soon, and when it does become enforced, seems that crucial hackintosh kexts such as FakeSMC are already exempt by a list-kext provided by Apple (!) itself.

I assume Apple may reverse the function of the kext to the opposite (from allow loading to forbid loading), when 10.9 is released to general public. Either way, the fact that Apple created the list, is both significant (it may be interpreted as an official recognition of hakckintosh scene existence from Apple itself, as Apple previously has acted as hackintosh scene is more or less non existent) and disturbing, as it may indicate (together with other facts) that Apple is going to take some serious actions against non authorised usage of OS X. Sure, it may also indicate intention to make hackintosh bit easier :)

  • 5 weeks later...
Konner
Konner
Posted
Posted

hmm. I really want to take part in trying to get 10.9 working on AMD, I have the FX-8350. But I would have no idea where to start on patches for AMD. I've tried googling things, etc. Any chance anyone that does code kernels, could point me in the direction to start? This is the kind of stuff that I'm highly interested in, in terms of a career is coding and getting things working. And figuring out how to do this, will be a great start in, It's a life long dream of mine to work and live around technology, and creating things for everyone to use freely as they want.

  • Like 1
theconnactic
theconnactic
Posted
Posted

Google and get the book "Learn C in 24 Hours". When you're familiarized with C, download and instal Xcode and google and add to Safari's reading list every tutorial you can find about using it. Only when you are okay with the language and tools, you should go to the Open Source Apple page and download some of the XNU kernels - a good exercise would be to download some of the diffs the developers post regularly on this forum and apply and compile the resulting kernel. Good study!

  • Like 2
gils83
gils83
Posted
Posted

For learning C, Aaron Hillegass's "Programming in objective c: the big nerd ranch guide" is also very useful. It's mostly for Objective-C, but it gives a damn good C intro as part of the course.

hello SS01  :)

 

For me it's Hieroglyphics, I include only fife! I'll ask for Champollion explains the enigma  :hysterical:

  • 4 weeks later...
Sinetek
Sinetek
Posted
  • Author
Posted

i'll be looking into the libs soon. 

So if i understand correctly, with ML kernel, we get up to mount root device, then launched tries to start, but  /usr/lib/dyld  doesn't work so the process never starts. Same problem we had to fix to get 64 bit working before in the past.

presumably the condition bits for memset, bcopy and friends changed in libc

 

http://opensource.apple.com/source/Libc/Libc-825.26/x86_64/string/

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...