dmazar

So far you can see it only by examining memory map from UEFI shell.

I do not know if memory mapping can be altered in UEFI. Do not have enough knowledge about those things. Kernel area for loading starts at 0x100000, so RT_Data @ 0x3f000 is not important in this case. You specific issue is BS_Code 0000000010000000-000000001000AFFF 000000000000000B 000000000000000F This area separates two available larger areas. If this area could be released then you would get 0xFF00+0xB more pages available in for relocation block which is 255MB. And how much could be used also depends on how much system will allocate to Clover, before AptioFix get a chance to use it.

Hi guys. I've seen similar memory map from some x99 board received from Rampage Dev few months ago. And now one from maleorderbride and one from nickwoodhams. They all have the same issue - not enough memory space in the first 4GB area. Most of the ram on those boards is mapped above 4GB (0x100000000 up). boot.efi normally always loads kernelcache and build kernel image (kernelcache + memmap + boot args + device tree + RT areas + MMIO reserved area + whatever) in the first 4GB area and kernel expects it to be there since transition from boot.efi to kernel still goes in 32 bit mode. Arguments passed between boot.efi and kernel (boot args) are also legacy with 32 bit space for memory addresses. So, boot.efi and kernel are not ready for loading above 4GB. AptioFix follows the same logic and allocates so called relocation block for kernel image under 4GB, so your available memory above 4GB is just not used. AptioFix takes over after boot.efi is done loading by intercepting jump to kernel - so this happens in 32 bit. And received pointer to boot args also 32 bit. Currently it must be under 4GB. Maybe this can be done differently. Maybe it is possible to do it with using relocation block above 4GB. But it looks to me as something that requires significant research and the whole new AptioFix which would do many things differently. With a great chance that it is not even possible. Sorry guys - no solution from me for this. Bad combination of Apple's legacy 32 bit, current AptioFix and specially UEFI developers of your boards who decided to map memory so badly for us.

This codec detection was developed in SnowLeo/Lion times when we used to have 887 layout if for 887 codec, 885 layout id for 885 codec and so on. It was automatically injecting those layout ids for such codecs, if they are detected. But those time are over and this detection seems useless now. I think this can be safely removed.

If you do not put slide=xxx, then you are booting like on a real Mac - boot.efi will randomly load kernel to different locations in memory (boot.efi will randomly choose slide value). So in this case kernel may be loaded at 0x100000 sometimes, but not always. If you set slide=0, then boot.efi will always load kernel at 0x100000. If you set slide=1 then kernel will be loaded at 0x300000, with slide=2 at 0x500000 and so on ... In any case, if you are not having allocation errors on booting, you are ok.

Probably can be resolved by checking your boot log (can be generated with DarwinDumper). Or you can generate pre-boot log from Clover by pressing F2 - this should generate preboot.log in /efi/clover/misc folder.

Ok, so just not to confuse other people who reads this topic: AptioFix2 is a special version of AptioFix driver which enables hibernate to work on some systems. It's for advanced users only, since it is not universal as standard AptioFix driver. I'm not sure from where above mammap is (from UEFI shell memmap or from OSX with DarwinDumper and with what driver) so I can not tell much more. But if you stick with the following rule, you'll be fine: If you boot with AptioFix2 and without slide parameter specified and if you get allocation errors during boot, then you need slide parameter. It is also possible that numerous boots without slide parameter will work and then one would end up with allocation errors. That means that slide parameter is needed. And which one to use is described here: http://www.projectosx.com/forum/index.php?showtopic=3167&st=200&p=39912&&do=findComment&comment=39912

I do not know about "Find My Mac", sorry, never tried that. Is that related to iCloud or iMessage? People had issues with iMessage when they switched from old AptioFix+EmuVariable to new AptioFix (with real nvram) and had to reactivate the account or change ROM and MLB values. Can you login to any of those?

The first thing is that you need to install Clover to EFI partition of your GPT disk. Meaning: mount EFI parttion in OSX and copy EFI/Clover folder from USB stick to EFI partition into EFI/Clover folder. Then: 1. Standard procedure: - reboot into Clover USB stick - Clover will detect installation on GPT disk and you will have some menu in tools section (Clover boot options?) where you can select "Add as UERI boot option" - this should add Clover as first entry in boot options - then restart and Clover should start - you can also check if Clover appears as boot option in BIOS/UEFI But sometimes this does not work. Usually on laptops, which are ment to be used with Windows only and then have some kind of protection against having first boot option other then Windows. Then ... 2. bootx64.efi way - mount EFI partition and copy /EFI/Clover/Cloverx64.efi to /EFI/BOOT/Bootx64.efi - reboot and see if this will add that drive as UEFI boot option And if this does not work, then ... 3. Clover masked as windows boot manager - mount EFI partition - if there is /efi/microsoft/boot/bootmgfw.efi (if UEFI windows is installed), then rename it to /efi/microsoft/boot/bootmgfw-orig.efi - and copy /EFI/Clover/Cloverx64.efi to /efi/microsoft/boot/bootmgfw.efi - reboot and see if this will add that drive as UEFI boot option

Remove OsxLowMemFixDrv and install OsxAptioFixDrv

It's additional PCI card and requires UEFI driver to work. I guess the driver is already on the card as option ROM, but maybe it is not enabled in BIOS. There should be some options like CSM Support, Boot Mode Selection, Storage Boot Option Control or similar.

As far as I know VirtualBox contains HFS+ driver implementation that does not support hard links which is needed for installation. So, Mavericks can not be installed in VirtualBox just like that. If you do not want to use Chameleon or Clover, then you could try: - prepare VirtualBox and install SnowLeo, Lion or ML in it - install Mavericks on real comp on a separate partition (could be even USB dongle) - use DiskUtil to make dmg image of installed Mavericks - create new disk in VirtualBox, start SL/Lion/ML in it VirtualBox and then extract installed Mavericks dmg to new VirtualBox disk P.S. interesting nick by the way

Well, with EmuVariableUefi it's like living with a gummy sex doll. When you enable real nvram, it's like the real woman is living with you now. So yes ... what can I say ... expect some issues.

You should probably just comment that line - I do no see this one allocated. Or just turn off asserts when building driver.

Assert can happen in FreePool if you pass it something that is not allocated with AllocatePool. For example: possible issue in grub_driver.c, GetFSGuid(): FreePool(FsName).