Jump to content

spakk

Local Moderators
  • Content Count

    4,263
  • Joined

  • Last visited

  • Days Won

    41

Reputation Activity

  1. Like
    spakk reacted to theconnactic in Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)   
    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
  2. Like
    spakk reacted to theconnactic in Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)   
    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
  3. Like
    spakk reacted to theconnactic in Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)   
    Neither i am, if "C programmer" means someone who develops C codes for a living. You're doing just fine.
     
     
    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?
     
     
    It seems. Maybe adding it back indeed solves the issue. I'll give it a shot later.
  4. Like
    spakk reacted to theconnactic in Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)   
    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.
     
     
    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!
     
     
    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.
     
     
    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.
     
     
    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.
     
     
    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.
  5. Like
    spakk reacted to theconnactic in Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)   
    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.
  6. Like
    spakk reacted to theconnactic in Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)   
    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).
  7. Like
    spakk got a reaction from theconnactic in Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)   
    Patch with the last kernel of RAV brought no success. I will make tomorrow another try
  8. Like
    spakk got a reaction from theconnactic in Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)   
    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?
  9. Like
    spakk reacted to theconnactic in Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)   
    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.
  10. Like
    spakk got a reaction from theconnactic in Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)   
    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
  11. Like
    spakk got a reaction from theconnactic in Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)   
    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
  12. Like
    spakk got a reaction from theconnactic in Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)   
    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
  13. Like
    spakk reacted to theconnactic in Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)   
    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.
  14. Like
    spakk reacted to riws in HILFE!-USBF: 189.700 AppleUSBOHCI[0x3323000]: : CheckSleepCapability - OHCI Controller will be unloaded across sleep   
    Installierst den Kontroller Treiber für ULi/ALi? Gibt es sowas auf der DVD bei dir? Oder den VIA, dies müsste den selben Treiber haben.
×