Jump to content
vit9696

AptioMemoryFix

604 posts in this topic

Recommended Posts

Advertisement
21 hours ago, Download-Fritz said:

 

X) boot.efi loads the kernel. It uses UEFI allocation services.

Y, Y > X) boot.efi does or would (if the type hasn't been changed for all but one page) defragment the runtime data.

 

Can we please agree on the concept of linear time? "Jesus??????"

 

 

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:

 

9 hours ago, Slice said:

kernel not uses UEFI allocation and change memory map by himself.

 

 

8 hours ago, Download-Fritz said:
9 hours ago, Slice said:
kernel not uses UEFI allocation and change memory map by himself.

But boot.efi does, which is what I said

 

No, it doesn't. Look at the code for the kernel. Again. Then study up. Then don't talk because you're still going to be wrong, apparently.

Edited by apianti

Share this post


Link to post
Share on other sites
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 by Download-Fritz

Share this post


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

Share this post


Link to post
Share on other sites

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。

QQ20180611-0.jpg

Edited by HDcat

Share this post


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

Share this post


Link to post
Share on other sites



	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?

Share this post


Link to post
Share on other sites

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

Share this post


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

Share this post


Link to post
Share on other sites

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 by chemary85

Share this post


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

 

Share this post


Link to post
Share on other sites
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 by Download-Fritz

Share this post


Link to post
Share on other sites

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 by apianti

Share this post


Link to post
Share on other sites

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

IMG_3030.thumb.JPG.aa57f121f18841599c40ede39d063230.JPG

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

Edited by zlominus

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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.

KakaoTalk_Photo_2018-08-07-07-07-06.thumb.jpg.539c664ce116792405bff616ebca84dc.jpg

 

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

1903611738_2018-08-076_45_20.png.5cdff733e5b3841219f54671f62e9b44.png

 

 

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 by Sherlocks

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

Announcements

×