Clover Problems and Solutions

[apianti]

Well, it's hard to say it's not related to memmap, there's a high possibility it is still. Seems that all of these tests reveal that slide needs to be more carefully calculated and I can only imagine that the free2000 is working for all because there's nothing for it to conflict with, all that memory has been freed.

[Sherlocks]

i found backlight bug.

some laptop can read backlight-level from nvram.plist when booting.

 

but

(dell)other laptop can't read backlight-level from nvram.plist when booting. clover log is good "Adding Key: backlight-level: Size = 2, Data: 69 05 ". but not actually reflect this value. only hold 80% brightness.

-> only works that can control that want brightness value in SystemParameters-BacklightLevel.

 

in other site, rehabman advice that SystemParameters-BacklightLevel = 0, but it's not working. i'm trying to resolve issue...

 

add. i dont know where take a value in nvram.plist? need debug

[cecekpawon]

These are errors I get when trying to use Intel Graphics instead of Nvidia. My solution was always to just keep restarting until it doesn't happen.

 

1 cold boot usually enough for me brother

[Sherlocks]

@apianti

 

i want to fix nvram backlight issue in dell laptop.

here is detail report.

-enviroment

EmuVariableUefi-64.efi + rc script

 

generally,

when booting, read backlight-level in vram.plist from “SetNvramVariable”

if you don’t have backllight-level in config.plist, first try “SetNvramVariable” then “AddNvramVariable” again.

 

this process is working on other laptop, but it’s not working on dell laptop.

 

so i decided to debug this issue.

i found some point

on dell laptop, if backlight-level is set in config.plist, i can use set value in config.plist when booting. but always hold brightness(set value). reflected value.

 

but if don’t have backlight-level in config.plist, system read backlight-level from nvram.plist. in nvram.plist, backlight-level is no problem. log too.

 

but actually not reflected last brightness value in nvram.plist when booting.

 

 

there are two vram values setting in Nvram.c

SetNvramVariable (

  IN  CHAR16   *VariableName,

  IN  EFI_GUID *VendorGuid,

  IN  UINT32   Attributes,

  IN  UINTN    DataSize,

  IN  VOID     *Data

  )

{

 

AddNvramVariable (

IN  CHAR16   *VariableName,

IN  EFI_GUID *VendorGuid,

IN  UINT32   Attributes,

IN  UINTN    DataSize,

IN  VOID     *Data

  )

{

 

only dell latpop has issue in AddNvramVariable function.

in SetNvramVariable, 

this return “return gRT->SetVariable (VariableName, VendorGuid, Attributes, DataSize, Data);” is working on dell laptop

“

/** Puts all vars from nvram.plist to RT vars. Should be used in CloverEFI only

 *  or if some UEFI boot uses EmuRuntimeDxe driver.

 */

VOID

PutNvramPlistToRtVars ()

{

  EFI_STATUS Status;

  TagPtr     Tag;

  TagPtr     ValTag;

  INTN       Size, i;

  CHAR16     KeyBuf[128];

  VOID       *Value;

~~~~~

    // set RT var: all vars visible in nvram.plist are gEfiAppleBootGuid

/*   Status = gRS->SetVariable (

                    KeyBuf,

                    VendorGuid,

                    EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS,

                    Size,

                    Value

                    ); */

 

    SetNvramVariable (

                      KeyBuf,

                      VendorGuid,

                      EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS,

                      Size,

                      Value

                      );

    if (!GlobalConfig.DebugLog) {

      //DBG ("\n");

    }

  }

“

 

this process shown correct working in log.

 

in DataHubCpu.c

  // Download-Fritz: Do not mess with BacklightLevel; it's OS X's business

  if (gMobile) {

    if (gSettings.BacklightLevelConfig) {

      DBG("  BacklightLevel = 0x%04lx\n", gSettings.BacklightLevel);

      SetNvramVariable(L"backlight-level", &gEfiAppleBootGuid, Attributes, sizeof(gSettings.BacklightLevel), &gSettings.BacklightLevel);

      DBG("Backlight - SetNvramVariable\n");

    } else {

      DBG("  BacklightLevel = 0x%04lx\n", gSettings.BacklightLevel);

      AddNvramVariable(L"backlight-level", &gEfiAppleBootGuid, Attributes, sizeof(gSettings.BacklightLevel), &gSettings.BacklightLevel);

      DBG("Backlight - AddNvramVariable\n");

    }

  }

 

because i didn’t set backlightlevel in config.plist, my dell system start “AddNvramVariable”. but not work “AddNvramVariable” in dell laptop.

 

==summary==

-enviroment

EmuVariableUefi-64.efi + rc script, i don’t have backlight-level in config.plist

process

read backlight level in nvram.plist -> added value from “SetNvramVariable” -> checked backlight-level in config.plist -> start “AddNvramVariable” -> compared between already have backlight value in gEfiAppleBootGuid and gSettings.BacklightLevel=0xFFFF in platformdata.c, then if have backlight value in gEfiAppleBootGuid, not use 0xFFFF, then start boot with backlight level in nvram.plist.

.

in this process, AddNvramVariable is not working properly. 

 

if have backlight-level “0x0569” in config.plist

read backlight level in nvram.plist -> added value from “SetNvramVariable” -> checked backlight-level in config.plist -> start “SetNvramVariable” -> compared between already have backlight value in gEfiAppleBootGuid and gSettings.BacklightLevel= 0x0569 in config.plst, then if have backlight value in gEfiAppleBootGuid, remove it in gEfiAppleBootGuid, then start boot with backlight level in config.plist.

in this process, SetNvramVariable is working in dell laptop.

 

as result, in SetNvramVariable funtion blow, have to use 

‘return gRT->SetVariable (VariableName, VendorGuid, Attributes, DataSize, Data);”

 

i can’t make code my thinks properly. i need help

 

sorry my english

 

 

thanks in advance.

 

Fixed

 

need this keys "ALI0/ALRV/ALV0/MSLD/RMde" in FakeSMC.kext's info.

 

added

Slice's FakeSMC r43 has 5 keys above. previous r40 version doesn't have those keys. it's good. thanks Slice.

[apianti]

@sherlocks,

 

I'm going to use your results to see if I can come up with a (better and aptly named) fix that incorporates the best parts of the aptiofixes, I think I have an idea. It would help though if I could get the same methodology of tests from the original two drivers too as you did with the -free2000. I do not consider that a viable option for a fix, more like an atomic option.

[Sherlocks]

@sherlocks,

 

I'm going to use your results to see if I can come up with a (better and aptly named) fix that incorporates the best parts of the aptiofixes, I think I have an idea. It would help though if I could get the same methodology of tests from the original two drivers too as you did with the -free2000. I do not consider that a viable option for a fix, more like an atomic option.

Okay. Im ready for report in detail

 

나의 LG-F800S 의 Tapatalk에서 보냄

[mhaeuser]

fix that incorporates the best parts of the aptiofixes

 

http://www.insanelymac.com/forum/topic/306156-clover-bugissue-report-and-patch/page-18?do=findComment&comment=2227865

[apianti]

No, it doesn't involve a relocate block, it involves doing what aptiofix2 does and convert the pages to MMIO so they aren't touched (except the necessary few that need to be moved). But then modifying what the relocation block did by trying to force boot.efi to pick the spot we want it to pick, ie where the slide should be. It also involves hooking the memory allocator methods in boot services and not allocating anything in the region of that reserved spot. Also what you described in that post is practically what aptiofix does, except more confusing. The whole point of the relocate block is to pick a place in memory and act like that's slide=0. So there shouldn't be an RT region there or it would say it couldn't allocate the relocation region. The problem with both fixes is boot regions being allocated randomly inside there without preventing it. And also miscalculation of page counts or something weird with that.

 

EDIT: I think the problem with the drivers is they try to stay backwards compatible, which we don't need, we can determine which version is booting and act accordingly. Like Lion needs the relocation most likely because low memory almost certainly has allocations in the way. But ML and on should try to slide the kernel instead.

[mhaeuser]

it involves doing what aptiofix2 does and convert the pages to MMIO so they aren't touched

AptioFix2 works fine, what do you want to do there? You can 'search' for some bigger free block and adapt the slide-value at boot time, but that requires such a block to be present and also in the scope of the slide parameter.

 

It also involves hooking the memory allocator methods in boot services and not allocating anything in the region of that reserved spot

Entirely impractical. Some older Aptio versions have the SystemTable in the 'resevered' area. And for those that don't, you need to run very early, preferably at early DXE, which would require a firmware flash. And even then you are bound to a certain slide value range.

 

Also what you described in that post is practically what aptiofix does, except more confusing.

I think you meant 'robust, dynamic and future-rpoof' instead of 'confusing'  It is very little like AF, except that allocs are redirected.

 

 The whole point of the relocate block is to pick a place in memory and act like that's slide=0. So there shouldn't be an RT region there or it would say it couldn't allocate the relocation region.

It does not act as slide=0, but as the physical memory. If boot.efi tries to allocate 0x01, it will be redirected to RelocationBlockAddress + 0x01. And for the case there is an RT block present, see my post.

 

And also miscalculation of page counts or something weird with that.

If you mean that guy that said dmazar was smoking something while writing that code, because he thought the relocation block size / page count was wrong... he did not understand how it works, there is nothing wrong currently known.

 

I think the problem with the drivers is they try to stay backwards compatible, which we don't need, we can determine which version is booting and act accordingly. Like Lion needs the relocation most likely because low memory almost certainly has allocations in the way. But ML and on should try to slide the kernel instead.

My idea is universal.

[apianti]

AptioFix2 works fine, what do you want to do there? You can 'search' for some bigger free block and adapt the slide-value at boot time, but that requires such a block to be present and also in the scope of the slide parameter.

 

No actually it doesn't. I handle the bug tickets and there are many getting the same allocation failures because the memory regions are too fragmented. And your second part was exactly my point.

 

Entirely impractical. Some older Aptio versions have the SystemTable in the 'resevered' area. And for those that don't, you need to run very early, preferably at early DXE, which would require a firmware flash. And even then you are bound to a certain slide value range.

 

No, it's not at all. I'm talking about when the GUI launches, preventing allocating boot memory in that region, that's part of the problem. Drivers and memory allocations for setting up the boot are being loaded into fragmentation, I want to prevent that by allocating all that stuff together.

 

I think you meant 'robust, dynamic and future-rpoof' instead of 'confusing'  It is very little like AF, except that allocs are redirected.

 

Actually, except that it would break SMM, and also firmwares that put hardcoded addresses into RT tables. Not everyone follows rules just cause they are given, or may not understand them. Basically you are moving maybe one region of RT space, to do the exact same thing that aptiofix does. And when I've seen that can't allocate relocation block error happen maybe twice and can also imagine that it's also to do with memory fragmentation.

 

It does not act as slide=0, but as the physical memory. If boot.efi tries to allocate 0x01, it will be redirected to RelocationBlockAddress + 0x01. And for the case there is an RT block present, see my post.

 

Actually it does act like slide=0, it uses slide=0 to make the memory always load at the base address (this is necessary for Lion) and then actually allocates the memory from the relocation block. If there is an RT page then the block should be moved, by preventing boot memory from being fragmented.

 

If you mean that guy that said dmazar was smoking something while writing that code, because he thought the relocation block size / page count was wrong... he did not understand how it works, there is nothing wrong currently known.

 

No I mean that there are page count miscalculations. It is a current bug in both drivers, just in different ways.

 

My idea is universal.

 

You literally say your idea isn't universal in your own post dude. Come on.

 

EDIT: Words. Spacing.

[mhaeuser]

No actually it doesn't.

*sigh* it works fine for what it is supposed to be....

 

No, it's not at all. I'm talking about when the GUI launches, preventing allocating boot memory in that region, that's part of the problem. Drivers and memory allocations for setting up the boot are being loaded into fragmentation, I want to prevent that by allocating all that stuff together.

That is not a fix, that is a patch that covers quarter the issues as pre-Clover mem is far more crucial and, especially, not minimizable without a flash.

 

Actually, except that it would break SMM, and also firmwares that put hardcoded addresses into RT tables. Not everyone follows rules just cause they are given, or may not understand them. Basically you are moving maybe one region of RT space, to do the exact same thing that aptiofix does. And when I've seen that can't allocate relocation block error happen maybe twice and can also imagine that it's also to do with memory fragmentation.

It would not break SMM except for when the AptioFix and AptioFix2 would actually fail to boot. I guess broken SMM is not as bad as a boot time error. You could argue that it's hiding a problem till in-OS, but I am not targeting people who just want to throw some driver somewhere and have a perfect system, neither with my concept, nor with my repos. AptioFix simply overwrites the memory in the target area which is, imo, far worse, and AptioFix2 depends on enough free space and a correct slide-value (or luck during generation time).

 

EDIT: You could actually error-exit when a RT page is in the way and still profit for when it's 'only' a BS page.

 

Actually it does act like slide=0, it uses slide=0 to make the memory always load at the base address (this is necessary for Lion) and then actually allocates the memory from the relocation block.

Acting like != using it. slide=0 is used so you don't need a 2TB relocation block to load the few hundred megs kernel (yes, that was an exaggeration).

 

If there is an RT page then the block should be moved, by preventing boot memory from being fragmented.

The issue is not when there is an RT page where the relocation block wants to go, but when there is a RT page where boot.efi wants to allocate fixed-address memory. You could try to relocate and not relocate back (physically), but I would not do that due to future-proofness. Whatever crazy stuff Apple will do in the future, they surely will not make sure to not use internal copies of addresses so external moves are not broken. That would be pretty hacky anyway.

 

No I mean that there are page count miscalculations. It is a current bug in both drivers, just in different ways.

Care to explain?

 

You literally say your idea isn't universal in your own post dude. Come on.

Universal as in it will always boot if there is enough mem, not as in everything will be fine on the Pony Ranch and all SMM drivers live happily thereafter. This is the most possible minimization of pre-boot issues possible without editing the firmware or do hacky, vendor- and likely version-dependant stuff. If you want an AptioFix that fixes all possible issues on Clover execution and boot.efi just runs through, dream on.

[apianti]

That is not a fix, that is a patch that covers quarter the issues as pre-Clover mem is far more crucial and, especially, not minimizable without a flash.

 

The problem with newer systems is there are more things that have option roms and require memory regions to work, which is why if you put too many peripherals, you almost always get this error. I haven't seen very many memmaps that don't have enough memory before clover launch to have space for the kernel memory and I'm not too worried about those. I have however seen plenty from after clover is started where there is not enough contiguous space.

 

It would not break SMM except for when the AptioFix and AptioFix2 would actually fail to boot. I guess broken SMM is not as bad as a boot time error. You could argue that it's hiding a problem till in-OS, but I am not targeting people who just want to throw some driver somewhere and have a perfect system, neither with my concept, nor with my repos. AptioFix simply overwrites the memory in the target area which is, imo, far worse, and AptioFix2 depends on enough free space and a correct slide-value (or luck during generation time).

 

EDIT: You could actually error-exit when a RT page is in the way and still profit for when it's 'only' a BS page.

 

I don't even know how to respond to this. Like what? Aptiofix does not overwrite any memory, it allocates a relocation block and serves allocations from there. Aptiofix2 and better calculating the slide is part of what I'm talking about. There are those drivers that I suggested as a testing method that somehow people are using for what god awful reason to boot always, and I've been very vocally against them because they actually do destroy memory.

 

Acting like != using it. slide=0 is used so you don't need a 2TB relocation block to load the few hundred megs kernel (yes, that was an exaggeration).

 

The issue is not when there is an RT page where the relocation block wants to go, but when there is a RT page where boot.efi wants to allocate fixed-address memory. You could try to relocate and not relocate back (physically), but I would not do that due to future-proofness. Whatever crazy stuff Apple will do in the future, they surely will not make sure to not use internal copies of addresses so external moves are not broken. That would be pretty hacky anyway.

 

The slide is part of ASLR, it has nothing to do with a huge relocation block but a randomized sliding of the kernel in memory so that it's not as susceptible to attack. It works like base_address = 0x100000 + (slide * 0x200000). The fixed address it wants is the base address, what do you mean?

 

Care to explain?

 

Ever seen the error couldn't allocated whatever pages at address and it's inside an available region but extends some amount of pages above when there's plenty of space below where it should have allocated? Then use the other driver and it works. But then others have the opposite driver do it and switch and it works. Page count miscalculations or something similar.

 

Universal as in it will always boot if there is enough mem, not as in everything will be fine on the Pony Ranch and all SMM drivers live happily thereafter. This is the most possible minimization of pre-boot issues possible without editing the firmware or do hacky, vendor- and likely version-dependant stuff. If you want an AptioFix that fixes all possible issues on Clover execution and boot.efi just runs through, dream on.

 

I mean I can make a universal driver super easy by just destroying boot memory. But that doesn't make it a good solution. Breaking something to get something to work when you're probably going to want the broken something later is not really a solution. And of course, I don't think it's possible for all firmwares to be fixed but the number of working ones should be as high as possible.....

What's the "trick" in displaying the right vram?

 

I place 4096 in config, it shows 0MB in profiler.

I place 8,000,000 it shows 512MB 

I place 16,000,00 it shows 1024MB

Logic says if I place 64,000,000 it should show 4096MB, but shows 0MB

 

I feel like a dog chasing its tail.

 

So, as I said, what's the "trick" 

 

What card do you have? Also putting in 8TB says 512MB? What setting are you changing it should be in MB to begin. Are you sure you don't have injection on/off when it needs to be the opposite?

[mhaeuser]

The problem with newer systems is there are more things that have option roms and require memory regions to work, which is why if you put too many peripherals, you almost always get this error. I haven't seen very many memmaps that don't have enough memory before clover launch to have space for the kernel memory and I'm not too worried about those. I have however seen plenty from after clover is started where there is not enough contiguous space.

Checked the "slide=0 area"? <= Lion users can go home?

 

I don't even know how to respond to this. Like what? Aptiofix does not overwrite any memory,

I think you confused that with 'I don't know how the code I'm trying to explain works' Mhmm, so, it does not overwrite any memory? You better make a commit then to fix this mess.

 

The slide is part of ASLR, it has nothing to do with a huge relocation block but a randomized sliding of the kernel in memory so that it's not as susceptible to attack. It works like base_address = 0x100000 + (slide * 0x200000). The fixed address it wants is the base address, what do you mean?

Sorry, can just lol at this. I talk about the reason for why it is used [by AptioFix] and you tell me what it is part of (KASLR) as a correction? The greater the slide value, the further back in memory the kernel sections get allocated and hence the bigger the Relocation Block needs to be as it acts as start of the physical memory

 

Ever seen the error couldn't allocated whatever pages at address and it's inside an available region but extends some amount of pages above when there's plenty of space below where it should have allocated? Then use the other driver and it works. But then others have the opposite driver do it and switch and it works. Page count miscalculations or something similar.

Sorry, I bet on people having no clue how AptioFix even works. Without a concrete example, I don't get it.

 

I mean I can make a universal driver super easy by just destroying boot memory. But that doesn't make it a good solution. Breaking something to get something to work when you're probably going to want the broken something later is not really a solution.

*yawn* It breaks what it needs to break in order to boot. You might be able to instead permanently relocate kernel areas (No, that is NOT what AptioFix is doing now... not at all, especially not with the Relocation Block), but idk how 'safe' that is.

[apianti]

Checked the "slide=0 area"? <= Lion users can go home?

 

Already said that it would be hybrid like a bunch of posts ago because Lion needs relocation.

 

I think you confused that with 'I don't know how the code I'm trying to explain works' Mhmm, so, it does not overwrite any memory? You better make a commit then to fix this mess.

 

When do you think this takes place? Literally the last step of aptiofix after exit boot services and intercepting the jump to kernel. All RT regions are moved into the relocation block. Nothing is getting overwritten. I think you need to understand how it works.

 

Sorry, can just lol at this. I talk about the reason for why it is used [by AptioFix] and you tell me what it is part of (KASLR) as a correction? The greater the slide value, the further back in memory the kernel sections get allocated and hence the bigger the Relocation Block needs to be as it acts as start of the physical memory

 

It only acts as the region that the kernel asks for but thinks is at the slide position is what I was saying, it uses slide=0 in this case. Because as you pointed out it moves it back to slide=0, in the first code snipped you linked. I was referring that if we just calculate the slide better then we can just have the kernel go where it wants without having to relocate it.

 

Sorry, I bet on people having no clue how AptioFix even works. Without a concrete example, I don't get it

 

Well I do, so maybe don't think that you know the answer if you don't get it. But I'll explain it again. Even though I've seen many examples of this, hypothetically, there is a region, 0xe000000 which has let's say 0x1500 pages available. For everything to be loaded it needs let's say 0x987 pages. Then the allocation fails saying couldn't allocate 0x987 pages at 0xec00000. Although it had down to 0xe000000, it did not try to allocate there, and therefore extended beyond the available region by about 0x87 pages, which are easily available below that.

 

*yawn* It breaks what it needs to break in order to boot. You might be able to instead permanently relocate kernel areas (No, that is NOT what AptioFix is doing now... not at all, especially not with the Relocation Block), but idk how 'safe' that is.

 

It's becoming clear that you are just going to disagree with me because you don't actually understand. Not even going to continue this conversation. In fact, it's {censored} like this that makes me not want to do anything and why I left for so long before.

[mhaeuser]

Already said that it would be hybrid like a bunch of posts ago because Lion needs relocation.

'best of both' sounded like one solution instead of dynamically chosing a solution.

 

When do you think this takes place? Literally the last step of aptiofix after exit boot services and intercepting the jump to kernel. All RT regions are moved into the relocation block. Nothing is getting overwritten. I think you need to understand how it works.

The MMIO conversion which you want to keep (and should keep) is exactly what prevents this (this is its sole purpose), only the SystemTable page is moved. MMIO is "added to the RTBlock" as part of virtual addressing, but not as in physically moving it. Any runtime memory that is not relocated by DefragmentRuntimeServices() (MMIO (i.e. all RT_data except for SystemTable plus actual MMIO), ACPI, Reserved, ...) is in danger considering this operation that overwrites memory. If you copied these regions into the relocation block as part of the AptioFix code (which, to my best knowledge, is nowhere to be found, in case you imply this is already happening), that would make some sense, but could overwrite kernel code.

 

Well I do, so maybe don't think that you know the answer if you don't get it. But I'll explain it again. Even though I've seen many examples of this, hypothetically, there is a region, 0xe000000 which has let's say 0x1500 pages available. For everything to be loaded it needs let's say 0x987 pages. Then the allocation fails saying couldn't allocate 0x987 pages at 0xec00000. Although it had down to 0xe000000, it did not try to allocate there, and therefore extended beyond the available region by about 0x87 pages, which are easily available below that.

Errr, you do know that this sounds like a 'boot.efi issue' and that boot.efi doesn't care where memory is free? Kernel sections (not considering KASLR now) are allocated at fixed locations and after that has happened, any LoaderData memory is allocated right after the end of the last section. If there is too much space between the sections, boot.efi doesn't care. If the memory allocated after the sections could just as well go inbetween them, boot.efi doesn't care. The Relocation Block is nothing else but a 'shift' in memory, not a stack.

 

It's becoming clear that you are just going to disagree with me because you don't actually understand.

lol.

 

In fact, it's {censored} like this that makes me not want to do anything and why I left for so long before.

I have logs of you naming a totally different reason, but whatever, IHateThisWebsite.

[apianti]

'best of both' sounded like one solution instead of dynamically chosing a solution.

 

Best of both means both. I didn't say how it was going to do it up to that point other than that lion needed the relocation so it had to be part of it.

 

The MMIO conversion which you want to keep (and should keep) is exactly what prevents this (this is its sole purpose), only the SystemTable page is moved. MMIO is "added to the RTBlock" as part of virtual addressing, but not as in physically moving it. Any runtime memory that is not relocated by DefragmentRuntimeServices() (MMIO (i.e. all RT_data except for SystemTable plus actual MMIO), ACPI, Reserved, ...) is in danger considering this operation that overwrites memory. If you copied these regions into the relocation block as part of the AptioFix code (which, to my best knowledge, is nowhere to be found, in case you imply this is already happening), that would make some sense, but could overwrite kernel code.

 

Dude, no, on all that. It's actually done right there in that function. The only RT that is not moved is the system table. I mean the comment right before the function says what it does.

/** Copies RT code and data blocks to reserved area inside kernel boot image. */

This is taking place into the relocation block.

 

EDIT: Or into the special reserved section that aptiofix2 adds to the kernel memory request. Which is part of the reason there is miscalculation.

EDIT2: So in other words only one situation could result in overwriting memory, when an MMIO is in very low memory and you are trying to boot with relocation. And that's not likely. In fact I think that the range 0x100000 - 0xEFFFFF is required to be available and not memory mapped by the ibm pc compatible standard.

 

Errr, you do know that this sounds like a 'boot.efi issue' and that boot.efi doesn't care where memory is free? Kernel sections (not considering KASLR now) are allocated at fixed locations and after that has happened, any LoaderData memory is allocated right after the end of the last section. If there is too much space between the sections, boot.efi doesn't care. If the memory allocated after the sections could just as well go inbetween them, boot.efi doesn't care. The Relocation Block is nothing else but a 'shift' in memory, not a stack.

 

Weird how you can just switch the driver and it works, in either case that it happens with one of the drivers. So no, it is a calculation issue. Wtf does a stack have to do with anything.

 

lol.

 

I have logs of you naming a totally different reason, but whatever, IHateThisWebsite.

 

Yes, you've shown you are a master of time and space. Imaginary time and space, but hey, you're the master none the less. Now please stop.

[mhaeuser]

Best of both means both. I didn't say how it was going to do it up to that point other than that lion needed the relocation so it had to be part of it.

"sounded"

 

Dude, no, on all that. It's actually done right there in that function. The only RT that is not moved is the system table. I mean the comment right before the function says what it does.

/** Copies RT code and data blocks to reserved area inside kernel boot image. */

Yes, RT code and data. By the time this function runs, ProtectRtDataFromRelocation() has been called, which converts those pages to MMIO. They are no longer RT code/data at this point. And yes, what I said about SystemTable was incomplete, AptioFix' copy of SystemTable is moved [EDIT: when required], not the SystemTable all other drivers/apps have gotten. Though this is literally the only page moved, the kernel crashes when ST is outside.

 

EDIT2: So in other words only one situation could result in overwriting memory, when an MMIO is in very low memory and you are trying to boot with relocation. And that's not likely. In fact I think that the range 0x100000 - 0xEFFFFF is required to be available and not memory mapped by the ibm pc compatible standard.

1) Not only MMIO, any permanent memory that isn't RT_data/code 2) You argue with specs after posting that people don't follow specs... ok. 0x100000  is sometimes blocked, such as with my old MSI OEM board.

 

Weird how you can just switch the driver and it works, in either case that it happens with one of the drivers. So no, it is a calculation issue. Wtf does a stack have to do with anything.

Could be a calc issue, just said that is not what I would guess. I mentioned that the Reloc Block is not a stack as it sounded (yes, SOUNDED, you did not literally say it) that there is enough space in the Reloc block and it is not used correctly. With AptioFix2, boot.efi gets to call AllocatePages() through a shim that does not mod the request, so switching for AF1 is not a point in this context.

 

Yes, you've shown you are a master of time and space. Imaginary time and space, but hey, you're the master none the less. Now please stop.

Yes, let mirrors do self-relection for you.  And as my goal is to have a more solid, dynamic solution instead of trying to show how oh-so-knowledged dev I am who is wasting so many nerves talking to the fools, no, I will not stop discussion ideas and tell you why you are wrong.

[apianti]

Yes, RT code and data. By the time this function runs, ProtectRtDataFromRelocation() has been called, which converts those pages to MMIO. They are no longer RT code/data at this point. And yes, what I said about SystemTable was incomplete, AptioFix' copy of SystemTable is moved, not the SystemTable all other drivers/apps have gotten. Though this is literally the only page moved, the kernel crashes when ST is outside.

 

1) Not only MMIO, any permanent memory that isn't RT_data/code 2) You argue with specs after posting that people don't follow specs... ok. 0x100000  is sometimes blocked, such as with my old MSI OEM board.

 

Well there might be stuff there but it won't be MMIO. So it should either be moved or not matter cause it won't be needed by the point it's overwritten. And actually, that is a bug. I did not realize that was changed to be used in both fixes. That is definitely a problem. Well the PC, XT, AT standards are pretty important, you couldn't legacy boot if it stuck important stuff in that region since that's basically all legacy can access after post.

 

Could be a calc issue, just said that is not what I would guess. I mentioned that the Reloc Block is not a stack as it sounded (yes, SOUNDED, you did not literally say it) that there is enough space in the Reloc block and it is not used correctly. With AptioFix2, boot.efi gets to call AllocatePages() through a shim that does not mod the request, so switching for AF1 is not a point in this context.

 

I think actually marking those pages after they are counted might be the reason there is a miscalculation. They both actually have shims for allocating memory, but af allocates a block and serves from that where af2 modifies the allocations as it sees fit. I can't recall of the top of my head where it exactly increases the pages that it needs to request. I'm about to leave so I don't have the time to look. This is actually promising though, I think that a merged driver will be entirely possible. Trying to act similar to af2 by default, and falling back to similar to af otherwise. And I've seen a few more miscellaneous things that might be bugs but I haven't had the time to look through and actually figure out.

 

Yes, let mirrors do self-relection for you.  And as my goal is to have a more solid, dynamic solution instead of trying to show how oh-so-knowledged dev I am who is wasting so many nerves talking to the fools, no, I will not stop discussion ideas and tell you why you are wrong.

 

Haha, DF, you know we are friends and I'm just jesting with you. If you've taken offense by anything I've said, good. But, no, seriously, I'm just fooling around. I'm glad there's someone I know I can expect to call my {censored} sometimes.

[mhaeuser]

Well there might be stuff there but it won't be MMIO. So it should either be moved or not matter cause it won't be needed by the point it's overwritten. And actually, that is a bug.

That is not a bug, that is the fix for SMM code execution. How else do you want to achieve this? MMIO seems to be the only memory type that is not relocated, but is mapped r/w. Well, AptioFix could just not relocate it, but I assume that could cause trouble for boot.efi or the kernel and is totally not future-proof.

 

where af2 modifies the allocations as it sees fit.

No, AF2 does not modify anything during the call, it only stores information.

 

Haha, DF, you know we are friends and I'm just jesting with you. If you've taken offense by anything I've said, good. But, no, seriously, I'm just fooling around. I'm glad there's someone I know I can expect to call my {censored} sometimes.

From most OSx86 folks I considered 'buddies', I got legit kicks in the face for the most minor reasons one could possibly imagine (once for saying 'your problem' because the person assumed I was saying '**** off, I don't care for your issues') and after IHateThisWebsite, I had little doubt that you're serious.

Imo people should relax a bit, realize this is a hobby and both take stuff not so seriously (yes, not what I did...) and at the same time not provoke it...

[apianti]

That is not a bug, that is the fix for SMM code execution. How else do you want to achieve this? MMIO seems to be the only memory type that is not relocated, but is mapped r/w. Well, AptioFix could just not relocate it, but I assume that could cause trouble for boot.efi or the kernel and is totally not future-proof.

 

Nah, I meant it's a bug that it is converted to MMIO after it was counted as RT page to relocate earlier. There is possibility to do something really crazy that I just thought of when you mentioned relocating it. Relocate all RT, but keep a relocation map. In RTCode search through and find any addresses pointing into RTData regions and patch them to the new relocated spot. Then do the same for RTData regions, replacing addresses in other RTData regions. The only possible issue would be accidentally changing an eight byte series of instructions thinking it was an address, but I find it very unlikely that would occur. Having the option to do either might work best too. Or I may be insane.

 

EDIT: I was going to say something about 32bit would probably be harder because of the only four bytes then I remembered I'm stupid and that's not going to be an issue booting mac os. lol

EDIT2: Also this would only apply to using the relocation block, I think. Right?

 

No, AF2 does not modify anything during the call, it only stores information.

 

Misspoke, didn't mean it did it in the call. Just in general.

 

From most OSx86 folks I considered 'buddies', I got legit kicks in the face for the most minor reasons one could possibly imagine (once for saying 'your problem' because the person assumed I was saying '**** off, I don't care for your issues') and after IHateThisWebsite, I had little doubt that you're serious.

Imo people should relax a bit, realize this is a hobby and both take stuff not so seriously (yes, not what I did...) and at the same time not provoke it...

 

I'm almost never serious but somehow I must come across as dead serious a lot because people get mad at me, like real mad. Just don't edit my post and we'll always be cool. HAHA

[mhaeuser]

Relocate all RT, but keep a relocation map. In RTCode search through and find any addresses pointing into RTData regions and patch them to the new relocated spot. Then do the same for RTData regions, replacing addresses in other RTData regions. The only possible issue would be accidentally changing an eight byte series of instructions thinking it was an address, but I find it very unlikely that would occur. Having the option to do either might work best too. Or I may be insane.

Tbh, if you combine block-wise relocation with some intelligent slide determination, you should be fine already. Block-wise relocation takes care of BS stuff in the way and the slide detection makes sure there is sufficient space that isn't blocked by RT stuff.

 

EDIT: Could there possibly be a way to determine what image type a RT_code region is from? If we can make sure it's (not) SMM, we can relocate at least some regions safely.

 

I'm almost never serious but somehow I must come across as dead serious a lot because people get mad at me, like real mad. Just don't edit my post and we'll always be cool. HAHA

Well, there literally is no indication of humor, one has to know you as a person to realize it. While that is imo the best kind of humor, it's also the one most affected to misunderstandings.

The number of quote boxes gets less... guess this actually turned out somewhat well lol

[apianti]

Tbh, if you combine block-wise relocation with some intelligent slide determination, you should be fine already. Block-wise relocation takes care of BS stuff in the way and the slide detection makes sure there is sufficient space that isn't blocked by RT stuff.

 

EDIT: Could there possibly be a way to determine what image type a RT_code region is from? If we can make sure it's (not) SMM, we can relocate at least some regions safely.

 

Actually, maybe there is, by enumerating all EFI_LOADED_IMAGE_PROTOCOL interfaces. Then looking for runtime regions through the ImageCodeType/ImageDataType members. Once we find a runtime region we can then look for the EFI_SMM_*_PROTOCOL interfaces as well and inspect the image handles until we find a tree that contains both protocol interfaces handles. Unsure what dungeon of lunacy from which that came...

 

Well, there literally is no indication of humor, one has to know you as a person to realize it. While that is imo the best kind of humor, it's also the one most affected to misunderstandings.

The number of quote boxes gets less... guess this actually turned out somewhat well lol

 

Actually I think that we need to continue discussing this and we will create a great driver out of it. This is how stuff worked over on projectosx and that's why there was so much happening there.

[apianti]

What's the "trick" in displaying the right vram?

 

I place 4096 in config, it shows 0MB in profiler.

I place 8,000,000 it shows 512MB 

I place 16,000,00 it shows 1024MB

I place 32,000,000 it shows 3072MB

 

Logic says if I place 64,000,000 it should show 4096MB, but shows 0MB

 

I feel like a dog chasing its tail.

 

So, as I said, what's the "trick" 

 

edit: "trick" is to go 1 less

I place 63,999,999 it shows 4095MB

 

Is this BUG or did I catch my tail

 

and from bdmesg

8:541  0:000  nVidia MSI GeForce GTX 1050 Ti  63999999MB NV137 [10DE:1C82] :: PciRoot(0x0)\Pci(0x1,0x0)\Pci(0x0,0x0) => device #1

I've edited my post there is a definite bug there!!

 

I don't know from just you saying it doesn't work. What value are you changing? Are you injecting graphics? I guess you have a nVidia MSI GeForce GTX 1050 Ti? It says 63999999MB according to your output from bdmesg so what do you mean?

[Slice]

I've edited my post there is a definite bug there!!

Setting VRAM in Clover mostly has no sense because OSX do it by itself.

[cecekpawon]

Why you dont just install the WebDriver to take care that VRAM & other properties? You are still able to adjust current max port & boot-display with SSDT. Will works with Clover or Ozmosis.