AptioMemoryFix

[mhaeuser]

14 hours ago, apianti said:

The kernel does this not boot.efi. You should know this since the code to do so is in the kernel and we talked about it. I said that the runtime pages need to be preserved, boot.efi is not doing that. The kernel does just like slice said:

 

With my last reply, I was giving you the benefit of the doubt that you actually mistyped and meant that boot.efi does this... would you mind explaining how the kernel, which has to be loaded to be executed, can relocate data to make room for itself to be loaded? This is a double timely paradox.

 

I cannot show the specific code in boot.efi itself now because the idb I have is mostly edited by vit and I don't plan to share without his explicite agreeing, however macosxbootloader might be good enough: https://github.com/Piker-Alpha/macosxbootloader/blob/El-Capitan/src/boot/MemoryMap.cpp#L254

 

If you are still doubting, you might be ready to quote the kernel source, which is open source.

 

EDIT: Even quicker way to verify: https://github.com/vit9696/AptioFixPkg/blob/master/Platform/AptioMemoryFix/BootFixes.c#L79

So, memory types are restored on kerne entry. How does the kernel deal with something ((not) relocating MMIO vs RT data), when it's changed back on the entry point call? Why is it changed during boot.efi execution when boot.efi is unrelated?

Edited June 11, 2018 by Download-Fritz

[vit9696]

6 hours ago, cecekpawon said:

Yo @vit9696 did you noticed "UnlockSlideSupportForSafeMode" has changed in 361.60.5 (10.13.5, maybe also newer)? How can we deal with this? Megathanks

Hi, thanks for the report, I can confirm that the check has changed. I committed a temporary workaround in the latest update, hopefully it will work for the time being, though I am starting to like the idea less and less.

[HDcat]

Sorry for coming back with a question. When I was under 10.13.x, everything started normally.
And when I want to test install 10.14, the following picture occurs.

 

My configuration is
CPU: i7-8700k
Motherboard: asus m10h
Memory: Corsair 8g*2 2400hz
Hard Drive: Samsung 960evo 250g

Graphics card: RX480 8G

 

used kext:Lilu IntelGraphicsFixup IntelmausiEthernet Shiki WhateverGreen Fakesmc

 

 

I'm sorry, my English is not very good. This is translated from Google。

 

Thank you in advance for the Great God。

Edited June 11, 2018 by HDcat

[Slice]

13 hours ago, Download-Fritz said:

 

If you are still doubting, you might be ready to quote the kernel source, which is open source.

 

	mptr = (EfiMemoryRange *)ml_static_ptovirt(args->MemoryMap);
	for (i=0; i < mcount; i++, mptr = (EfiMemoryRange *)(((vm_offset_t)mptr) + msize)) {
	    if (((mptr->Attribute & EFI_MEMORY_RUNTIME) == EFI_MEMORY_RUNTIME) ) {
		vm_size = (vm_offset_t)i386_ptob((uint32_t)mptr->NumberOfPages);
		vm_addr =   (vm_offset_t) mptr->VirtualStart;
		/* For K64 on EFI32, shadow-map into high KVA */
		if (vm_addr < VM_MIN_KERNEL_ADDRESS)
			vm_addr |= VM_MIN_KERNEL_ADDRESS;
		phys_addr = (vm_map_offset_t) mptr->PhysicalStart;
		DPRINTF(" Type: %x phys: %p EFIv: %p kv: %p size: %p\n",
			mptr->Type,
			(void *) (uintptr_t) phys_addr,
			(void *) (uintptr_t) mptr->VirtualStart,
			(void *) vm_addr,
			(void *) vm_size);
		pmap_map_bd(vm_addr, phys_addr, phys_addr + round_page(vm_size),
		     (mptr->Type == kEfiRuntimeServicesCode) ? VM_PROT_READ | VM_PROT_EXECUTE : VM_PROT_READ|VM_PROT_WRITE,
		     (mptr->Type == EfiMemoryMappedIO)       ? VM_WIMG_IO   : VM_WIMG_USE_DEFAULT);
	    }
	}

and so on

[mhaeuser]

	mptr = (EfiMemoryRange *)ml_static_ptovirt(args->MemoryMap);for (i=0; i 	    if (((mptr->Attribute & EFI_MEMORY_RUNTIME) == EFI_MEMORY_RUNTIME) ) {	vm_size = (vm_offset_t)i386_ptob((uint32_t)mptr->NumberOfPages);	vm_addr =   (vm_offset_t) mptr->VirtualStart;	/* For K64 on EFI32, shadow-map into high KVA */	if (vm_addr 			vm_addr |= VM_MIN_KERNEL_ADDRESS;	phys_addr = (vm_map_offset_t) mptr->PhysicalStart;	DPRINTF(" Type: %x phys: %p EFIv: %p kv: %p size: %p\n",		mptr->Type,		(void *) (uintptr_t) phys_addr,		(void *) (uintptr_t) mptr->VirtualStart,		(void *) vm_addr,		(void *) vm_size);	pmap_map_bd(vm_addr, phys_addr, phys_addr + round_page(vm_size),	     (mptr->Type == kEfiRuntimeServicesCode) ? VM_PROT_READ | VM_PROT_EXECUTE : VM_PROT_READ|VM_PROT_WRITE,	     (mptr->Type == EfiMemoryMappedIO)       ? VM_WIMG_IO   : VM_WIMG_USE_DEFAULT);    }}

and so on

This is literally code to map pages 1:1 physical to virtual with addresses provided by boot.efi, there isn't even unrelated copy code there, there is no copy code at all.

Is it even worth replying at tjis point?

[Slice]

I just said that the kernel change memory map. If you want to check you may open XNU sources and find EFIMemoryRange all occurrence.

[mhaeuser]

I just said that the kernel change memory map. If you want to check you may open XNU sources and find EFIMemoryRange all occurrence.

Well, this is about apianti's opinion: The kernel relocates RT data. And I asked him to show that code.

[chemary85]

How can I see/know what version I have installed?

Can be interesting put in the comments of file the version after compiling, so you can see the version being used in file info.

Is it possible to do this? Thank you!

Edited June 11, 2018 by chemary85

[vit9696]

AMF version is included in APTIO_MEMORY_FIX_PROTOCOL, which AMF installs. Is it not enough?

See: https://github.com/vit9696/AptioFixPkg/blob/master/Include/Protocol/AptioMemoryFixProtocol.h

[apianti]

4 hours ago, Download-Fritz said:

4 hours ago, Slice said:

I just said that the kernel change memory map. If you want to check you may open XNU sources and find EFIMemoryRange all occurrence.

Well, this is about apianti's opinion: The kernel relocates RT data. And I asked him to show that code.

 

I don't even care to respond to any of your other posts, but once again, I did not {censored} say that. I really don't care to speak with you anymore. But when I was talking about mapping the regions, only runtime is mapped. Where I was referring to the kernel being loaded, the kernel is loaded before any runtime is defragmented, you said yourself that there is a jump back to fix the memory regions for the kernel, if the kernel was loaded after defragmenting we could just fix the memory regions before hand when loading the kernel. And because boot.efi KNOWS that there is no Apple firmware in the slide regions at all, there is no such reason for it to attempt to preserve any memory there. The memory is overwritten by the kernel being loaded. End of story. That's what happens. Another thing, we wouldn't really need to fix slide would we if the memory was defragmented before the kernel was loaded. And the final thing, and my original point that no one seems to understand, only runtime pages are preserved. However, reserved memory regions can not be used at all by the OS regardless of the runtime attribute, and many firmwares, including mine, have non runtime reserved regions, these regions should be preserved as they may be important.

 

[mhaeuser]

1 hour ago, apianti said:

I did not {censored} say that.

 

On 6/9/2018 at 7:51 PM, apianti said:

The kernel maps and relocates runtime pages [...], so they are not moved by the kernel, remember????? Therefore, they could be overwritten by the kernel, "where the kernel wants to go."

 

I suppose you did in one way or the other... once or twice...

 

On 6/2/2018 at 8:55 PM, apianti said:

Aptiofix3 and AptioMemoryFix do not allow the relocation. Therefore, there is always some part of the firmware that is not moved and is in the way of where the kernel wants to go.

 

Implication: If AptioFix allowed defragmentation, there would be no memory range collision.

 

1 hour ago, apianti said:

the kernel is loaded before any runtime is defragmented

 

Former implication violated: If defragmatation takes place after the kernel is loaded (which is true), defragmatation can neither preserve data or make room, because all kernel loading operations that could possibly benefit already have taken place. Linear time.

 

1 hour ago, apianti said:

And because boot.efi KNOWS that there is no Apple firmware in the slide regions at all, there is no such reason for it to attempt to preserve any memory there. The memory is overwritten by the kernel being loaded. End of story.

 

It's not only factually wrong, because boot.efi uses AllocatePages() to allocate each of the kernel regions, which checks whether the target range is occupied already, but also ignores all the "memory allocation errors". There is no error to be displayed if boot.efi just copies into Nirvana without any checks. Show the code or go home.

 

 

I sometimes wonder whether you don't see such things or whether you just hope nobody notices due to walls of text.

Edited June 11, 2018 by Download-Fritz

[apianti]

Oh... You burned me.... You exactly proved my point but just can not read or comprehend apparently. The implication you say is wrong, you can imply anything you want that does not make it true or what was meant. But I was inferring that there is memory regions where the kernel is to be placed that have not been relocated and therefore the kernel CAN NOT BE PLACED THERE BECAUSE IT WOULD BE OVERWRITING THE REGION. But keep trying to being an annoying assclown just because you some how feel butt hurt about some imaginary slight I have made towards you. But seriously stop talking to me.

 

EDIT: I forgot to say about the relocation, AptioFix1 actually does prevent this error from happening by virtually relocating the kernelspace to a different region and then copying it back. Forgot AptioFix2 does not relocate either, but I'm not sure what would be the advantage of using that driver anymore.

Edited June 11, 2018 by apianti

[zlominus]

I just wanted to make a report (this is kind of cross-post from XPS 9550 Topic).

I can boot the installer and safe mode with either Aptiomemoryfix and AptioFixDrv3 (with this I use calculated slide value 145), but as soon as I add kernel extensions and prelinked kernel gets rebuilt (I see the file grow from like 13 MB to 25 MB) I cannot boot

 

A lot of other forum members had success with this laptop (It's running latest bios), so I'm not sure what I am doing wrong

 

I’m attaching memdump output from Clover UEFI shell as well as aptiodump screengrab (Latest debug version)

 

This is on macOS 10.13.5 (17F77)

memmap.txt

EDIT: After fully clearing NVRAM (by removing CMOS battery) it works fine.

Edited July 1, 2018 by zlominus

[otherwhaler]

Hi,

 

I read vit9696's post back on page 6 about debug logging with boot.efi. I'm trying to troubleshoot the wake-from-sleep freeze that X79 systems have had since High Sierra, and I wonder if I can use boot.efi logging to get some more information on it.

 

This wake issue has been difficult to troubleshoot because the system freezes before control returns to the OS, so there are no logs from macOS. I suspect it's ACPI-related somehow, but I don't have much concrete evidence to go on.

 

I was able to turn on at least some debug logging by running `nvram bootercfg="log=7 debug=7"`. (I just enabled all of the options for both the `log` and `debug` flags.) I have a "BOOTER.LOG" file on my EFI partition now, and it logs some things during boot, but I don't see any logs from sleep or wake.

 

vit9696's post also mentioned that some debug information might show up in IOReg under `efi/debug-log`, but I don't see a `debug-log` property under `efi`. (There is `efi/platform/boot-log`, but that's just the same as the output of `bdmesg`.)

 

So, has anyone used boot.efi logging to debug sleep/wake issues? Or (not to get too off-topic), is there a better way I could be looking for debug information for a freeze on wake? 

 

Thanks!

[mhaeuser]

S3-wake does not follow a full boot route but instead hands off to a defined OS wake vector after early init... boot.efi is not invoked

[Slice]

For debugging wake from hibernation there is DumpUefiCalls.efi driver that compiled together with Clover but not included into release package. Compile it by yourself or search on forum.

[otherwhaler]

Hmm. Is there any way to get debug information about S3 wake, then? For example, I see a bunch of `DEBUG()` calls in S3Resume.c from EDK, but from what I can tell, you need a serial connection to view those messages. (If they're even called on a Hackintosh.)

 

From what I've read, hibernation seems to be unreliable at best. I have tried it a few times as an alternative, but I'd really like to get S3 sleep/wake working again if possible.

[mhaeuser]

DEBUG() calls are usually not enabled in production images

[Funky frank]

Yes

[javanesse]

aptiomemoryfix give a completely  stuck at bios logo on my laptop.

so i have to unplug all of my HDD before i can booting normal again.

 

anyone know why?

 

hope the next release will fix this issue.

[Sherlocks]

@vit9696

hi. i want to report potential language issue between clover and aptiomemoryfix.

long time ago, i reported this issue in clover thread. but still there is issue.

 

first, to avoid this issue, always use OsxAptioFix2Drv + EmuVariableUefi-64.efi + set ko(config.plist).

https://sourceforge.net/p/cloverefiboot/code/HEAD/tree/rEFIt_UEFI/Platform/DataHubCpu.c#l212

today, i tested only your driver aptiomemoryfix without EmuVariableUefi and cleanup before update beta6.

this issue happen

1. installing => not keep korean language. always shown english. in recovery, too.

 

2. restart popup after install beta6. popup shown korean + english combination.

 

 

i checked realmac nvram dump

------------------------------------------------------------------------------
bluetoothInternalControllerInfo
------------------------------------------------------------------------------
000000: 95 82 ac 05 00 00 00 00 78 4f 43 7a 8c 80        |........xOCz..|

------------------------------------------------------------------------------
multiupdater-0
------------------------------------------------------------------------------
000000: 54 00 68 00 6f 00 72 00 55 00 74 00 69 00 6c 00  |T.h.o.r.U.t.i.l.|
000010: 2e 00 65 00 66 00 69 00 00 00 2d 00 67 00 20 00  |..e.f.i...-.g. .|
000020: 2d 00 6f 00 20 00 2d 00 73 00 72 00 20 00 31 00  |-.o. .-.s.r. .1.|
000030: 20 00 30 00 20 00 2d 00 66 00 73 00 20 00 65 00  | .0. .-.f.s. .e.|
000040: 66 00 69 00 2d 00 61 00 70 00 70 00 6c 00 65 00  |f.i.-.a.p.p.l.e.|
000050: 2d 00 70 00 61 00 79 00 6c 00 6f 00 61 00 64 00  |-.p.a.y.l.o.a.d.|
000060: 31 00 2d 00 64 00 61 00 74 00 61 00 20 00 2d 00  |1.-.d.a.t.a. .-.|
000070: 67 00 20 00 2d 00 6f 00 20 00 2d 00 73 00 72 00  |g. .-.o. .-.s.r.|
000080: 20 00 30 00 20 00 30 00 20 00 2d 00 66 00 73 00  | .0. .0. .-.f.s.|
000090: 20 00 65 00 66 00 69 00 2d 00 61 00 70 00 70 00  | .e.f.i.-.a.p.p.|
0000a0: 6c 00 65 00 2d 00 70 00 61 00 79 00 6c 00 6f 00  |l.e.-.p.a.y.l.o.|
0000b0: 61 00 64 00 32 00 2d 00 64 00 61 00 74 00 61 00  |a.d.2.-.d.a.t.a.|
0000c0: 20 00 2d 00 6e 00 6f 00 72 00 65 00 73 00 65 00  | .-.n.o.r.e.s.e.|
0000d0: 74 00 20 00 00 00 00 00 00 00 00 00 00 00        |t. ...........|

------------------------------------------------------------------------------
prev-lang:kbd
------------------------------------------------------------------------------
000000: 72 75 3a 30                                      |ru:0|

------------------------------------------------------------------------------
LocationServicesEnabled
------------------------------------------------------------------------------
000000: 01                                               |.|

 

 

in realmac, there is prev-lang:kbd variables.

vit9696, did you always use only english in macos? no default russian? i wonder whether you experience this issue like my issue.

 

I have no experience with RealMac.
What I'm wondering is that after you first purchase a Mac, when you select a language on the Settings screen, will the language you selected be recorded in NVRAM? I wonder if the record is prev-lang: kbd.

Or I wonder if prev-lang: kbd is specified according to RealMac which is released in each country. This is not clear, so it seems that the problem I am experiencing is present.

 

sorry for my bad english

thanks in advance

 

 

Edited August 6, 2018 by Sherlocks

[vit9696]

This is a macOS bug. I also have it. Unless the initial installation has prev-lang:kbd set to a correct local language, all the subsequent updates may break the locale of the operating system. If you google it, you could find several reports on apple forums and in other places. Apple Radar is your friend.

[Sherlocks]

This is a macOS bug. I also have it. Unless the initial installation has prev-lang:kbd set to a correct local language, all the subsequent updates may break the locale of the operating system. If you google it, you could find several reports on apple forums and in other places. Apple Radar is your friend.

okay. i have to keep emul option to avoid language issue. thank you so much:)

나의 LG-F800S 의 Tapatalk에서 보냄

[Roger Smith]

I have a problem starting boot.efi on an FV2 APFS partition. I have signed the boot.efi with the secureboot keys and can only get the graphics to work when I enable CSM in the BIOS.

 

Without CSM and with or without FASTBOOT,  MOHandleProtocol doesn't find the GOP (Graphics Output Protocol) on any file descriptor. I managed to find one at startup and save a that value, I checked the framebuffer address too and zeroed it so that I knew that it was valid but still no graphics output.

 

Without my changes I get an 0xE unsupported error. Adding the GOP manually gets me a display that is doing nothing. I can see two calls to the GOP device and no calls to any of the GOP methods.  Normally you see only the Blt call being made when things work.

 

Anyone have any ideas? The BIOS isn't going to be flashed on this device as I am currently repurposing int.

[vit9696]

Hi, I think it is not related to secure boot, but most likely your BIOS firmware does not properly implement GOP and uses UGA to draw the onscreen content. Perhaps some of the newer code expose parts of GOP (e.g. ConSplitter) but it does not guarantee that t is functional. I would suggest you write a shim betweeen GOP and UGA and submit it as a patch if it works out.

See https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/UgaDraw.h.