Jump to content

[possible solution][X99] OsxAptioFixDrv: requested memory exceeds our allocated relocation block


xeye
 Share

79 posts in this topic

Recommended Posts

tried building it with clovergrowerpro and got this:

 

- gcc-4.9.2 extracting...
- gcc-4.9.2 extracted
- gcc-4.9.2 (native) configure...
Error configuring GCC-4.9.2 ! Check the log /Users/jamiethemorris/**WORKSPACE**/CloverGrowerPro/src/logs/gcc-native.x64.configure.log.txt
 
- Ejecting RAM disk
"disk2" unmounted.
"disk2" ejected.
Toolchain build  ERROR!!
configure: error: Unable to find a usable CLooG.  See config.log for details.

 

It's not possible

At the address ftp://gcc.gnu.org/pub/gcc/infrastructure/ I see cloog-0.18.1 as required by the script.

I think the problem in in CGP that is not updated very long.

I am using manual compilation and all is working here.

See CloverInstructions->Developement

  • Like 1
Link to comment
Share on other sites

It's not possible

At the address ftp://gcc.gnu.org/pub/gcc/infrastructure/ I see cloog-0.18.1 as required by the script.

I think the problem in in CGP that is not updated very long.

I am using manual compilation and all is working here.

See CloverInstructions->Developement

I just tried doing it manually, I got the same "unable to find usable cloog" error. I would download it separately but i don't know where to put it

Link to comment
Share on other sites

It's not possible

At the address ftp://gcc.gnu.org/pub/gcc/infrastructure/ I see cloog-0.18.1 as required by the script.

I think the problem in in CGP that is not updated very long.

I am using manual compilation and all is working here.

See CloverInstructions->Developement

 

I also have an error (different though) with manual compilation.  I am getting "./ebuild.sh: No such file or directoy" when on the last 3 lines of your instructions. 

 

If I copy the ebuild.sh from edk2/OvmfPkg to edk2/ then It returns the error "build.exe: error: no such option: --low-abda

 

If I change directories to one that contains an ebuild.sh, then I receive a different error.

 

 

 

Do you know what I did wrong?

 

You can see my original post (#6670) in the Clover General thread.

Link to comment
Share on other sites

For anyone else who might be following this, I have stopped using the BT firmware kexts as that cuts 5MBs of kernelcache from my build and using a USB BT dongle instead. That has allowed me to avoid the AptioFix problem for some time now.

 

My own attempts to edit did not seem to make any difference other than changing which blocks are unable to be reallocated. It does not seem like those some regions are able to get re-mapped to free up more room.

 

That said, there is a larger block available that AptioFix does not use, even if recompiled with that specific address range specified. No doubt I am doing it wrong, so hopefully someone can get a version that works better with X99 boards and similar memorymaps to the X99 Deluxe/ X99-E WS.

Link to comment
Share on other sites

Thank you for posting everyone, I have done some serious research and I am still getting the osxaptiofixdrv cannot allocate relocation block error. 

 

I have documented it extensively here:

https://sourceforge.net/p/cloverefiboot/tickets/125/

 

The short version, I am running a Gigabyte X99-UD5 with 32GB of DDR4. 

 

Getting the OsxAptiofixDrv error when booting with two video cards installed or a video card and two PCIe SSDs. The error seems to be related to bad memory mapping in Clover. 

 

Thank you @jamiethemorris for providing the DumpUEFICalls EFI file, it worked. The results are logged to /EFI/CLOVER/misc/eficalls.log. Here is my output:

https://www.dropbox.com/s/ooe26ub3t4qshm9/EfiCalls-not-bootable-config.log?dl=0

 

Does anyone have an idea of how to proceed? Been working on this for over a month now. 

 

Any help will be GREATLY appreciated! 

  • Like 1
Link to comment
Share on other sites

I am facing similar issues. I am however able to temporarily solve the issues by booting OS X using the usb stick i installed os x with (which does have chameleon) and then run the kext utility without installing any kexts. just let it rebuild stuff. However this is not exactly a viable option since it wrecks my imessage and everything else. 

 

Any suggestions?

 

GA-X99-UD4

Gigabyte GeFore GTX 970

16 Gbyte ram

5930K

Link to comment
Share on other sites

I am facing similar issues. I am however able to temporarily solve the issues by booting OS X using the usb stick i installed os x with (which does have chameleon) and then run the kext utility without installing any kexts. just let it rebuild stuff. However this is not exactly a viable option since it wrecks my imessage and everything else. 

 

Any suggestions?

 

GA-X99-UD4

Gigabyte GeFore GTX 970

16 Gbyte ram

5930K

Use legacy clover instead of chameleon, it will achieve the same thing. This is a uefi-specific clover issue.

Link to comment
Share on other sites

Use legacy clover instead of chameleon, it will achieve the same thing. This is a uefi-specific clover issue.

Hey jamiethemorris, has anyone discussed this with Slice and does he agree? It's kinda hard keeping up with Clover now that ProjectOSX is history...  These problems with OsxAptiofixDrv may be hard to resolve without dmazar...

 

  • Like 1
Link to comment
Share on other sites

Hey jamiethemorris, has anyone discussed this with Slice and does he agree? It's kinda hard keeping up with Clover now that ProjectOSX is history... These problems with OsxAptiofixDrv may be hard to resolve without dmazar...

aptiofix is only used for uefi booting. BTW you know the new changes are being posted in their own thread in the clover section right? There's also always the commit history on sourceforge.
  • Like 1
Link to comment
Share on other sites

Dmazar is the one who created optiofix not Slice.

did you read the post...  "resolve without dmazar"...

aptiofix is only used for uefi booting....

And most of us are booting UEFI...  Yeah, I watch the commit history on sourceforge, must have missed the changes being posted in the clover section.  Regards-

Link to comment
Share on other sites

Snatch I was simply stating that Slice said couple of times that he didn't write AptioFix :)

 

On the side note, for some reason I don't have memory address issues with original AptioFix booting UEFI on x99e ws with dual gtx 980 and 64gb memory.

My issue is and will be 5960x and kernelcache.

Link to comment
Share on other sites

Snatch I was simply stating that Slice said couple of times that he didn't write AptioFix :)

 

On the side note, for some reason I don't have memory address issues with original AptioFix booting UEFI on x99e ws with dual gtx 980 and 64gb memory.

My issue is and will be 5960x and kernelcache.

You're the only one I've seen that can boot Clover with 2 980/970's... I have a friend that's been wrestling with 2 980's for weeks, so any help you can offer (maybe config.plist) would be helpful...

 

Confused: "My issue is and will be 5960x and kernelcache" What processor are you using to run the 2 980's?  Maybe I'm kinda dense... :rolleyes:

Link to comment
Share on other sites

FYI, Dmazar PM'ed me, so I sent him the requested info and also linked to this thread. Here's hoping!

 

My guess is that 2x Maxwell would require additional space in the kernel for Clover, would that make sense? So if you want 2x, then perhaps remove every single spare KB you can manage. Strip plugins for FakeSMC, no USB 3.0 kext, no ethernet, no BT, etc.

 

Anyone know for certain how to tell if the Webdriver requires additional space for 2x cards?

Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

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.

 

Thanks for looking Dmazar!

 

Do you think it is possible to alter the memmap in the BIOS? Meaning, is this something that Coderush could potentially help with? 

 

If so, would relocating the RT_Data @ 0x3f000 be sufficient do you think, or would even more space be required than that would free up?

Link to comment
Share on other sites

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.
Link to comment
Share on other sites

@dmazar Is there any way to see if a board has this issue by looking at the bios? I am looking into buying an evga x99 classy but nobody has hacked one yet as far as I can tell, it would be nice to be able to download the bios and find out beforehand if it has this issue.

Link to comment
Share on other sites

I can't guarantee the correctness of this answer, though I'm absolutely sure sure there is no way this is changeable from or visible in the ROM file. The memory map is a dynamic map of all currently allocated memory, so you can't alter it directly either way. And I honestly doubt the ROM contains a map where to map which memory and think this is simple an implementation variation of EFI_BOOT_SERVICES.AllocatePages/Pool which decides where to allocate the memory by its type.

 

I might have a look at the UEFI spec at the weekend to verify this, though I'm sure enough :)

  • Like 2
Link to comment
Share on other sites

@dmazar Is there any way to see if a board has this issue by looking at the bios? I am looking into buying an evga x99 classy but nobody has hacked one yet as far as I can tell, it would be nice to be able to download the bios and find out beforehand if it has this issue.

 

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

  • Like 1
Link to comment
Share on other sites

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

Well, I guess I'll be the guinea pig for this board then. If worse comes to worse I'll just use CloverEFI.

BTW I've heard Linux runs terribly on X99, is that still true?

  • Like 1
Link to comment
Share on other sites

Well, I guess I'll be the guinea pig for this board then. If worse comes to worse I'll just use CloverEFI.

BTW I've heard Linux runs terribly on X99, is that still true?

 

What exactly is necessary to boot legacy? I am getting an "error allocating runtime" when attempting to boot with legacy clover.

 

I installed with the following options:

1. Install Clover in the ESP

2. Bootloader: Install boot0af in MBR (also tried Don't update)

3. CloverEFI: 64-bit SATA

4. HFS+ 64-bit driver, filesystemdrv, nothing else.

Link to comment
Share on other sites

What exactly is necessary to boot legacy? I am getting an "error allocating runtime" when attempting to boot with legacy clover.

 

I installed with the following options:

1. Install Clover in the ESP

2. Bootloader: Install boot0af in MBR (also tried Don't update)

3. CloverEFI: 64-bit SATA

4. HFS+ 64-bit driver, filesystemdrv, nothing else.

Did you see black screen with 5_ at the start?

 

You also can choose Clover BiosBlockIO. It sometimes works better. 

Link to comment
Share on other sites

 Share

×
×
  • Create New...