Jump to content
InsanelyMac Forum


  • Content count

  • Joined

  • Last visited

About LeXa2

  • Rank
    InsanelyMac Protégé

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Moscow, Russian Federation
  • Interests
    IT, *nix, SciFi
  1. LeXa2

    AnVAL (ACPI Loader)

    Andy, valv, any news on the AnVAL? Is the project still being developed or it had been superseded/merged with some other Chameleon-derived product?
  2. Hadn't tried yet as I got my AO522 only two days ago. Anyway I'm pretty sure it's possible to get OS X 10.6 up and running on this note using nawcom's modUSB and legacy kernel from nawcom or Andy. Problems might occur later on trying to get QI/CE/HDMI/D-SUB working with APU-integrated Radeon HD or things like cool-n-quite, backlight intensity setting, e.t.c. So I wouldn't expect installation to be an easy rote but it should be generally possible after lot of try-n-fix efforts. I'm going to give it a try a bit later after installing linux as a second boot OS. My final goal is to have triple boot system on this netbook.
  3. LeXa2

    Windows + VirtualBox = MAC OS

    I'm still trying to find a way to run vanilla Mac OS X kernel inside VirtualBOX on AMD CPU equipped host. ATM I need some feedback from people running vanilla kernel in their guests and having Intel CPU equipped hosts. It would be great if one would find some time to execute "VBoxManage list hostcpuids" command in the console and paste the output to this thread. It should look similar to this: [lexa2@lx2linux 2011-02-20]$ VBoxManage list hostcpuids Oracle VM VirtualBox Command Line Management Interface Version 3.2.12 © 2005-2010 Oracle Corporation All rights reserved. Host CPUIDs: Leaf no. EAX EBX ECX EDX 00000000 00000005 68747541 444d4163 69746e65 00000001 00100f43 01040800 00802009 178bfbff 00000002 00000000 00000000 00000000 00000000 00000003 00000000 00000000 00000000 00000000 00000004 00000000 00000000 00000000 00000000 00000005 00000040 00000040 00000003 00000000 00000006 00000000 00000000 00000000 00000000 80000000 8000001b 68747541 444d4163 69746e65 80000001 00100f43 10001b76 000037ff efd3fbff 80000002 20444d41 6e656850 74286d6f 4920296d 80000003 34582049 35353920 6f725020 73736563 80000004 0000726f 00000000 00000000 00000000 80000005 ff30ff10 ff30ff20 40020140 40020140 80000006 20800000 42004200 02008140 0030b140 80000007 00000000 00000000 00000000 000001f9 80000008 00003030 00000000 00002003 00000000 80000009 00000000 00000000 00000000 00000000 8000000a 00000001 00000040 00000000 0000000f 8000000b 00000000 00000000 00000000 00000000 8000000c 00000000 00000000 00000000 00000000 8000000d 00000000 00000000 00000000 00000000 8000000e 00000000 00000000 00000000 00000000 8000000f 00000000 00000000 00000000 00000000 80000010 00000000 00000000 00000000 00000000 80000011 00000000 00000000 00000000 00000000 80000012 00000000 00000000 00000000 00000000 80000013 00000000 00000000 00000000 00000000 80000014 00000000 00000000 00000000 00000000 80000015 00000000 00000000 00000000 00000000 80000016 00000000 00000000 00000000 00000000 80000017 00000000 00000000 00000000 00000000 80000018 00000000 00000000 00000000 00000000 80000019 f0300000 60100000 00000000 00000000 8000001a 00000003 00000000 00000000 00000000 8000001b 0000001f 00000000 00000000 00000000 8000001c 00000000 00000000 00000000 00000000 Along with the output please post the exact model and type of your CPU. The idea is to fool guest system into thinking that it is equipped with the Intel CPU by spoofing the results of the CPUID command. With a bit of luck this might allow to run 32bit vanilla kernel on hosts with recent AMD CPUs. 64bit kernel is guaranteed to crash due to differences between AMD64 and Intel EM64T x86-64 implementations (SYSCALL vs. SYSENTER opcodes problem). Thanks to volunteers in advance!
  4. LeXa2

    Windows + VirtualBox = MAC OS

    Then you had obviously done something wrong setting up VBox network settings and/or your host OS network settings. Using Samba to exchange files with host OS is by far the most fastest and easiest way this days when running Mac OS X under VBox.
  5. Andy, nawcom, thanks again for your work over this project. I'm wondering about the patch you had posted a link to: what is the background in a two words? I've been following the process of development xnu-kernel patches for a while now and as far as I remember correctly one of the latest bits required to provide "patch-free" Mac OS X experience for AMD CPU users was the creation of non-standard version of dynamic loader that would be capable of auto-patching dloaded libs to be free of cpuid checks and to be compatible with AMD64 way of doing system calls. It the patch you had posted the link to expected to replace Apple's vanilla dynamic loader with a custom version that would do exactly what I had just described? Also, is this patch a complement or a replacement to the compiled legacy kernel nawcom had posted at the first post in this thread?
  6. LeXa2

    VirtualBox drivers

    You're posting to the wrong forum, your question should had land to the "Multi-booting and Virtualisation" section. Nevertheless, the answer to your question is: there are no VirtulaBOX-specific drivers available currently. It had been officially promised by the VBox devs on the forums that the "Guest Additions" for Mac OS X are "being worked on", but there was no exact release date announced. Since that announcement a lot of time had passed and Sun had been acquired by Oracle. Current state of the Mac OS X guest additions development is unknown. We're still hoping that Oracle wouldn't throw the work that had already been done by VBox devs into the can and the Mac OS X guest additions would be finally released. P.S. As for changing display resolution for Mac OS X running under VirtualBOX - search the google for "VirtualBOX EFI GOP mode changing", or simply follow the advices published in the takwing's guide on installing Mac OS X under VirtualBOX. P.P.S. With recent version of VirtualBOX you might give VoodooHDA driver a try, as VBox now is capable of emulating Intel HDA audio device inside guest VM.
  7. LeXa2

    Windows + VirtualBox = MAC OS

    The only info relevant to run the Mac OS X under VirtualBOX is the model of your CPU. I might be wrong but it seems to me that your CPU is too new and there are no official Apple Mac computers out there with this CPU installed. Knowing that I want to warn you that you'd most probably get the "black screen" kernel panic if you'd try to install using native Mac OS X kernel. And you would definitely have no luck at using any Mac OS X versions prior to 10.6.6 with native kernel. Chances are that Apple is going to update the hardware of Mac computers soon and their configurations would include Core i7 CPU. If that's a case then there might be that support for this CPU had been introduced in the kernel shipped with 10.6.6. On the other hand, nothing stops you to install 10.6.5 version of Mac OS X with the patched legacy kernel and use it as a base for testing. Who knows, may be you'd be lucky enough to get 10.5.0 vanilla kernel (the version shipped with OS X 10.6.5) to work with your CPU under VirtualBOX. Succeeding with it would mean that it is safe for you to update to 10.6.6. So, what's the point to ask ;-)? Just give it a try, as takwing had already said.
  8. LeXa2

    Windows + VirtualBox = MAC OS

    Well, it's hard to tell what would you need to do to get the system up and working, but at least you may wish to try the following: 1. Remove fakesmc.kext, EvOReboot.kext and OpenHaltRestart.kext in case you've got installed any of them. Rebuild kext caches (use pfix for this - this wonderful tool makes the life much easier). 2. Remove all the extradata from the VM xml file. The only extradata you should have in it is the smc-key related. 3. Make sure your VM uses ICH6 IDE controller and the MacOS system virtual hard is connected to primary master port of it. 4. Enable EFI in VM properties, try to boot into it. It you had done all the things right now you should be able to see debug output of the kernel during bootup. So it either would boot normally (and you would be happy with it) or it would stuck at some place and you would be able to take a photo of the screen and post it here so we might be able to help you.
  9. LeXa2

    Windows + VirtualBox = MAC OS

    Side note: vanilla install won't be possible on each and every workstations. The requirement is that the CPU needs to match any of that had been used by Apple in original Macs.
  10. LeXa2

    Windows + VirtualBox = MAC OS

    Unfortunately, yes. Your CPU isn't NX/PAE capable. Here is a list of Intel Pentium M processors from which you may easily check that your CPU is only capable of MMX, SSE, SSE2 and Enhanced Intel SpeedStep Technology (EIST). Sad but true.
  11. LeXa2

    Windows + VirtualBox = MAC OS

    My experiments turned out that 1Gb is a minimal requirement. I hadn't been able to successfully install SL when the guest RAM amount was set to 512Mb (and even with 768Mb installation had hanged at about the middle of the file copying process). If by "config" you mean hardware - then it is the system with an Intel-based CPU that had been used in original Apple hardware and is also capable of Intel Virtualisation Extensions (VT-x). Memory amount is insignificant as long as you have at least 3Gb of it (1Gb for guest and 2Gb for host would be fine for general use). If you're talking about guest VM config, then take some time and read takwing's guide. You would find all the info you need there. Installation of SL from vanilla Install DVD using VirtualBOX EFI is possible in case you had configured your guest VM with SMC extradata and your host is equipped with CPU that had been used in original Apple's hardware. For all other cases you would be required to use either EmpireEFI or nawcom Mod CD to boot into installer.
  12. I'm in process of "OS X post-install fixing" old Toshiba Satellite L40-17T laptop equipped with Intel Celeron 540 CPU. This CPU is a single core device running at 1.86GHz based on the Core 2 architecture. Unfortunately this CPU lacks support of the Intel SpeedStep technology so no P-states are being supported. Situation is better with the C-states - this CPU supports C0, C2 and C3 halt states, which are successfully found and used by any recent linux distro. What I want is to force Mac OS X into using C-states as well. I use AnVAL 5.0.6 as a bootloader and it reports that ACPI tables were successfully patched to support C-states if I add GenerateCStates=Yes to the com.apple.Boot.plist. But I doubt if the states are really used by Mac OS X. As far as my understanding of the C-states vs. OS function is correct there should be some kind of a driver on the OS side that should replace default idle sleep function with a smarter one that would switch CPU to the C-state sleep. Looks like that in case of vanilla Mac OS X this driver is the famous AppleIntelCPUPowerManagement.kext. Trouble is that I have to blacklist this kext because the Celeron 540 CPU is not officially supported by this driver and causes the kernel panic. It is obvious that I should find some kind of replacement for AICPM.kext and the most obvious candidate for the replacement are Kexts from the VoodooPower* family. I doubt if VoodooPower*-family Kexts are suitable for enabling C-states on SpeedStep-uncapable systems. Does anybody know if it would work? And are there any ways to check if the Mac OS X system had detected and successfully using CPU C-states (something similar to the /proc/acpi/ interface in linux)?
  13. Thanks for the quick answer. As you made clear that the original Apple's hardware uses SmartBattery protocol to communicate with the battery over the SMB (so looks like that there's a "vendor-specific Embeded Controller" in original Mac hardware with the integrated SMBus controller that may be accessed using EC-SMB access protocol defined in the ACPI specs) now it is obvious that I wouldn't have a chance to correct the situation using the DSDT patch - it is generally possible to implement Control Method Battery in AML using accesses to the EC-SMB-SB, but not the vice-versa. Notebook I'm trying to "fix" is the pretty old Toshiba laptop and it incorporates it's own EC plus a lot of the ATK-ACPI stuff coded in AML that works with it's own proprietary protocol accessing EC and doing the fun stuff. Battery access is also implemented over the ATK/EC, but the communication protocol is not the SmartBattery-complaint and the battery interface provided to the OSPM is the ACPI Control Method one. I had installed the VoodooBattery kext few minutes ago and it seems to be working quite good. Once again, thanks for the quick answer. As for your advice to set the SystemType=2 - I had already done this just right after the installation of AnVAL edition of the Chameleon 2 bootloader. Looks like that it hadn't been required though because AnVAL seems to be smart enough to detect that the system it is running at is a laptop and to set the system-type=2 automatically.
  14. LeXa2

    Tried Updating to 10.6.5

    And not only the hardware, also it would be wise to post here any modifications you had make to get the 10.6.2 installation in a working state. I mean, Kexts installation, DSDT patches and all other thins of a such kind.
  15. Colleagues, I've got a question about the laptop battery recognition by the Mac OS X. ACPI specs state that there are two types of battery access interfaces out there: "Smart Battery" and "Control Method Battery". First one should be controlled over SMB and Embeded Controller with a special OS-specific driver, second one is a pure ACPI/AML solution that is expected to be coded in DSDT. Which of these does the original Apple hardware employ? My problem is that I've got a notebook which I had managed to install OS X on and now the battery isn't being detected and I have got no battery meter shown in the top bar. I know that I may want try to use Kext-based solutions like VoodooBattery but it seems to me that it would be better to patch DSDT to make vanilla OS X able to detect and show the battery status. So I'm trying to figure out if is this possible.