Clover General discussion

[sebinouse]

@all

Test, please, 3591

CLOVERX64.efi-3591.zip

@Micky1979

Clover sources should be written in EDK2 code style.

Look, please, https://github.com/tianocore/tianocore.github.io/wiki/Code-Style-C

(this site has temporary problems now)

Not working as expected :

0:100  0:000  Starting Clover rev 3591 on American Megatrends EFI
...
0:118  0:000  KextsToPatch: 6 requested
0:118  0:000  KextsToPatch 0: IOGraphicsFamily (Boot Graphics)Matched OSes: 10.12.x
0:118  0:000   Kext bin patch, data len: 5
0:118  0:000  KextsToPatch 1: AppleIntelFramebufferAzul (port 0x05 DP to HDMI pipe 0x09)Matched OSes: 10.12
0:118  0:000   Kext bin patch, data len: 11
0:118  0:000  KextsToPatch 2: AppleIntelFramebufferAzul (port 0x05 DP to HDMI pipe 0x09 to 0x12)Matched OSes: 10.11.x
0:118  0:000   Kext bin patch, data len: 11
0:118  0:000  KextsToPatch 3: IOAHCIBlockStorage (Trim Enabler) Kext bin patch, data len: 9
0:118  0:000  KextsToPatch 4: AppleHDA (Binary ALC283)Matched OSes: 10.11.x,10.12
0:118  0:000   Kext bin patch, data len: 4
0:118  0:000  KextsToPatch 5: AppleHDA (Binary zero 1983)Matched OSes: 10.11.x,10.12.x,
0:118  0:000   Kext bin patch, data len: 4
...
0:264  0:000  KextsToPatch: 6 requested
0:264  0:000  KextsToPatch 0: IOGraphicsFamily (Boot Graphics)Matched OSes: 10.12.x
0:264  0:000   Kext bin patch, data len: 5
0:264  0:000  KextsToPatch 1: AppleIntelFramebufferAzul (port 0x05 DP to HDMI pipe 0x09)Matched OSes: 10.12
0:264  0:000   Kext bin patch, data len: 11
0:264  0:000  KextsToPatch 2: AppleIntelFramebufferAzul (port 0x05 DP to HDMI pipe 0x09 to 0x12)Matched OSes: 10.11.x
0:264  0:000   Kext bin patch, data len: 11
0:264  0:000  KextsToPatch 3: IOAHCIBlockStorage (Trim Enabler) Kext bin patch, data len: 9
0:264  0:000  KextsToPatch 4: AppleHDA (Binary ALC283)Matched OSes: 10.11.x,10.12
0:264  0:000   Kext bin patch, data len: 4
0:264  0:000  KextsToPatch 5: AppleHDA (Binary zero 1983)Matched OSes: 10.11.x,10.12.x,
0:264  0:000   Kext bin patch, data len: 4
...
5:278  0:000  Kernel and Kext Patches at 89DDD77A:
5:278  0:000  	Allowed: y
5:278  0:000  	Debug: y
5:278  0:000  	KernelCpu: n
5:278  0:000  	Lapic: n
5:278  0:000  	Haswell-E: n
5:278  0:000  	AICPUPM: y
5:278  0:000  	AppleRTC: y
5:278  0:000  	KernelPm: y
5:278  0:000  	FakeCPUID: 0x0
5:278  0:000  	ATIController: null
5:278  0:000  	ATIDataLength: 0
5:278  0:000  	0 Kexts to load
5:278  0:000  	6 Kexts to patch
5:278  0:000  	  KextPatch[0]: 5 bytes, IOGraphicsFamily
5:278  0:000  	  KextPatch[1]: 11 bytes, AppleIntelFramebufferAzul
5:278  0:000  	  KextPatch[2]: 11 bytes, AppleIntelFramebufferAzul
5:278  0:000  	  KextPatch[3]: 9 bytes, IOAHCIBlockStorage
5:278  0:000  	  KextPatch[4]: 4 bytes, AppleHDA
5:278  0:000  	  KextPatch[5]: 4 bytes, AppleHDA

macOS 10.12.DP2
sw_vers -productVersion 10.12
Clover r3591

MatchOS   not set            skipped > not OK
MatchOS   10.12              OK
MatchOS   10.12.x            skipped > not OK
MatchOS   10.11.x            skipped > maybe partially OK ? 
MatchOS   10.11.x,10.12      OK      > maybe partially OK ? 
MatchOS   10.11.x,10.12.x    skipped > not OK
MatchOS   10.11.x,10.12.x,   skipped > not OK

[Slice]

As I see 10.12.x != 10.12 

[sebinouse]

According source code :

MatchOS example for valid matches are:

10.7, only 10.7 (10.7.1 will be skipped)
10.10.2 only 10.10.2 (10.10.1 or 10.10.5 will be skipped)
10.10.x (or 10.10.X), in this case is valid for all minor version of 10.10 (10.10.(0-9))

I use 10.12 for the time being ...

As I see 10.12.x != 10.12 

Do you mean that this is the expected behaviour ? I always assumed 10.12.x included 10.12 ...

 

Edit : PM is OK on my Haswell with MSR 0xE2 locked on CLOVER r3591 (PM patch set to Yes)

[Micky1979]

 

@Micky1979

Clover sources should be written in EDK2 code style.

Look, please, https://github.com/tianocore/tianocore.github.io/wiki/Code-Style-C

(this site has temporary problems now)

Thanks, sorry I don't have habit with EFI style, but I will.

 

As I see 10.12.x != 10.12  

It should, again the same statement fail:

if (osToc->count == 2) {

        if (AsciiStrCmp(osToc->array[0], currOStoc->array[0]) == 0

            && AsciiStrCmp(osToc->array[1], currOStoc->array[1]) == 0) {

            ret = TRUE;

        }

    } else if (osToc->count == 3) {

        if (currOStoc->count == 3) {

            if (AsciiStrCmp(osToc->array[0], currOStoc->array[0]) == 0

                && AsciiStrCmp(osToc->array[1], currOStoc->array[1]) == 0

                && AsciiStrCmp(osToc->array[2], currOStoc->array[2]) == 0) {

                ret = TRUE;

            } else if (AsciiStrCmp(osToc->array[0], currOStoc->array[0]) == 0

                       && AsciiStrCmp(osToc->array[1], currOStoc->array[1]) == 0

                       && (AsciiStrCmp(osToc->array[2], "x") == 0 || AsciiStrCmp(osToc->array[2], "X") == 0)) {

                ret = TRUE;

            }

        } else if (currOStoc->count == 2) {

            if (AsciiStrCmp(osToc->array[0], currOStoc->array[0]) == 0

                && AsciiStrCmp(osToc->array[1], currOStoc->array[1]) == 0) {

                ret = TRUE;

            } else if (AsciiStrCmp(osToc->array[0], currOStoc->array[0]) == 0

                       && AsciiStrCmp(osToc->array[1], currOStoc->array[1]) == 0

                       && (AsciiStrCmp(osToc->array[2], "x") == 0 || AsciiStrCmp(osToc->array[2], "X") == 0)) {

                ret = TRUE;

            }

        }

    }

 

The fight is with the code is now only there. osToc = array of compontets like

10
12
x 

or

10
12

should be valid when you write 10.12.x (3 components = count 3) or 10.12  (2 components = count 2)

 

But wait, this depend on your real System version that can have 2 components (count 2 like 10.12) or 3 (count 3 like 10.12.1)

 

If real OS has 3 components like MatchOS compare all of 3 components.

else

if the count of the real OS is only 2, compare if MatchOS first two index are equal (valid for all)

 

..but this has different statement if MatchOS has a the .x suffix or not, so after matching the first two indexes (always to be done) we have to ensure MatchOS has the third component and is an 'x', that means run for all OSes that have index 0 and 1 already matching. Otherwise if no index 2 exits on real OS or, exist but is not equal to the index 2 of MatchOS or is not an 'x' ... is invalid.

Should be easy please 200 eyes on it 

[bs0d]

why not make 10.12 mean all 10.12.x releases and then use the point to explicitly limit ... seems more logical and easier to code ... oh and use integers

[tempel]

Hi all, since I'm somehow not allowed to post a new topic, I wonder if this is the right place to ask questions and give feedback on Clover?

 

If not, please let me know what's a better place. Thanks.

 

----

Hi, I'm a long time developer (did a lot of OS level work for over 30 years) and like to understand more of what I'm using here, especially because I'm have problems that I rather understand how to fix than try dozens of suggestions from other users without a clue

 

First, a few comments on the documentation on this site for Clover:

 

On https://clover-wiki.zetam.org/Prefacethe terms FakeEFI and RealEFI are explained. But what's missing is how this relates to Clover. Is Clover a FakeEFI or a RealEFI implementation? That should be mentioned there. Otherwise, this intro makes little sense.

There's also some info on https://clover-wiki.zetam.org/Technical-Background, but that doesn't refer to FakeEFI or RealEFI directly, either.

Maybe the two pages should be merged, or at least have some wiki links between them. Also, the term DUET is used in the background page without explaining it. A link would be nice. Same for "EDK2".

 

Now to my particular issues / questions:

 

1.

Where is the GUI of Clover's boot screen explained? I have no clue what some of the buttons do, and why they are there. I cannot find anything on the wiki that explains how to USE the GUI.

 

The GUI shows a row of apparent buttons below the row of partitions. The leftmost (shell) is self explanatory to me. Then come 1 to 3 clover buttons. What do they mean? Clicking them just refreshes the display without any clue what they did. Then come 3 more buttons which are fairly self explanatory again.

 

Below that is another bigger button, followed by the text for the selected partition. But this button doesn't seem to do anything when clicking on it. I'd expect it would start booting from that selected disk. Instead, the only way I can get the boot to progress is to double click the partition. That's not obvious, either.

 

2.

I have trouble using the keyboard once Clover is showing its menus. At the start of the PC, I can use the kbd in the BIOS setup just fine. But once Clover is up, it often doesn't work any more. When I then continue to boot into OSX (e.g. into the installer), it works again. Can I fix that in Clover's settings? I mean, the wiki explains that Clover "fixes" USB when it starts, so I guess it does that wrong on my system, and I hope there's a way to control that.

 

3.

I still have trouble understanding how, just after installing OSX, the system could reboot into OSX even though Clover has not been installed on the OSX disk's EFI partition, yet.

 

After OSX has been installed, the system reboots, and that would, in my understanding, load Clover from my OSX-Installer USB stick again, which would then end up loading the installer once again. But it didn't - so what made Clover on the USB stick know that it should instead boot the newly installed OSX system? On a normal Mac, the boot-parms would be stored in NVRAM. But that's not the case on a Hackintosh, or is it?

 

After having successfully booted into the newly installed OSX, I then installed Clover into its empty EFI partition. But after rebooting, it did not boot up (apparently due to some USB troubles again). So I wanted to reboot OSX again in the same way it was booted the first time after the installation, so that I could exchange the drivers in the EFI partition. How can I do that? Would it help if I erased the EFI partition again (I could do that by booting into Windows and then empty that dir - I have the tools for that)?

 

Also, Clover shows me a "RECOVERY" partition, but when I boot from that, I only end up with the OSX Installer again. Is that supposed to happen?

[mhaeuser]

To the wiki: Yeah, I wouldn't call it well maintained...

Clover is an UEFI application and not some FakeEFI what-so-ever... and in contrast to what everyone else 'says', there is no 'legacy Clover'. For UEFI emulation on legacy systems, a modded DUET (from the EDK2 project) is used which directly starts the Clover app. DUET is basically the UEFI reference implementation minus platform initialization (BIOS does this) plus some extra drivers (like NVRAM emulation).

 

to 1. Select the buttons to see their function (the label changes). 'Options' are the config.plist options and 'Clover boot Options' (did I get that right?) is for UEFI boot option management.

 

2. More info, please? Legacy or UEFI? USB or PS/2 keyboard?

 

3. If you have an UEFI board, NVRAM works pretty well and Clover partially knows how to treat them (partially because efi-boot-device(-data) is used, though they are only communication variables between userland and the kext, so Windows Boot Camp Control Panel will not give you the ability to chose the OS).

To boot like before, just chose USB from boot menu?

[Slice]

should be valid when you write 10.12.x (3 components = count 3) or 10.12  (2 components = count 2)

 

But wait, this depend on your real System version that can have 2 components (count 2 like 10.12) or 3 (count 3 like 10.12.1)

 

If real OS has 3 components like MatchOS compare all of 3 components.

else

if the count of the real OS is only 2, compare if MatchOS first two index are equal (valid for all)

 

..but this has different statement if MatchOS has a the .x suffix or not, so after matching the first two indexes (always to be done) we have to ensure MatchOS has the third component and is an 'x', that means run for all OSes that have index 0 and 1 already matching. Otherwise if no index 2 exits on real OS or, exist but is not equal to the index 2 of MatchOS or is not an 'x' ... is invalid.

Should be easy please 200 eyes on it 

New tests

Sergeys-iMac:1 slice$ gcc micky.c -o micky
Sergeys-iMac:1 slice$ ./micky 10.12 10.12
patch 10.12 is enabled for 10.12
Sergeys-iMac:1 slice$ ./micky 10.12.1 10.12
Segmentation fault: 11
Sergeys-iMac:1 slice$ ./micky 10.12.x 10.12
Segmentation fault: 11
Sergeys-iMac:1 slice$ 

micky.c.zip

My mistake

mo->array[newLen - 1] = '\0';

[tempel]

Tach!

 

 

to 1. Select the buttons to see their function (the label changes). 'Options' are the config.plist options and 'Clover boot Options' (did I get that right?) is for UEFI boot option management.

 

2. More info, please? Legacy or UEFI? USB or PS/2 keyboard?

 

3. If you have an UEFI board, NVRAM works pretty well and Clover partially knows how to treat them (partially because efi-boot-device(-data) is used, though they are only communication variables between userland and the kext, so Windows Boot Camp Control Panel will not give you the ability to chose the OS).

To boot like before, just chose USB from boot menu?

 

1) How do I select the buttons, in particular those unclear clover buttons? Hovering over with the mouse cursor is not helping. Clicking them shows nothing, only refreshes the screen. And the kbd does not work.

 

3) Okay, I still have to get used to the double level of boot loaders I forgot that I still can choose to boot from the USB stick, which will also boot Clover, but with the parameters from the USB stick. And with those, I can still boot into the newly installed OSX. It's only when I boot Clover from my new installation on the OSX disk, I get the boot problems. So, I can boot into OSX again and fix this now.

 

I am still not too happy with the way all those guides on the tony... website are written - they are way too fixed on one way to do it, and if something doesn't work out that way, then you're left with asking dozens of questions on the forum. I think it would really help if there was a single page that explained these things better, how they all work together, from a user's view. But maybe that's just how I think - I just want to understand things and get stuck where others with less care succeed. I just "think different", I guess

 

2) UEFI, USB kbd. But now that I boot again from my USB stick, I see that I can use the USB kbd there. I guess the EFI/CLOVER/config.plist is responsible for all behaviors of the clover GUI, so I can simply compare the two and figure out what's causing this. When I know, I'll report back - maybe this helps others in the future. (Again, a comprehensive page with all these conditions and solutions would be nice to have - the forum is a pain to search when there's 100s of similar answers that are all just not exactly on the point. But I also understand that it's difficult to maintain such a FAQ, I have the same problem with my own apps I develop. It's more work at first, but it will help in the long run. I wonder why there's no wiki any more where people with a clue could add this info - did it get out of hand?)

 

Also - does the EFI shell I can open in Clover use the full command set that I find here: http://docstore.mik.ua/manuals/hp-ux/en/5991-1247B/ch04s13.html- or does Clover do its own thing?

 

BTW - I just realize that I used to try to document some Hackintosh things back in 2009 already. Totally forgot about it, but now I found it again using Google

[Slice]

Should work now

CLOVERX64.efi-3593.zip

[tempel]

Should work now

CLOVERX64.efi-3593.zip

 

I wonder if you guys consider integrating the new OsxAptioFixDrv fix that was recently discussed (ticket 125), to fix the memory fragmentation issue. It certainly helped with my setup, while the 3 default options offered in Clover do not work for me. Or is it still not finished? Since I can reproduce the issue, I'd be happy to help, even with some debugging.

[Slice]

Tach!

 

 

 

1) How do I select the buttons, in particular those unclear clover buttons? Hovering over with the mouse cursor is not helping. Clicking them shows nothing, only refreshes the screen. And the kbd does not work.

 

3) Okay, I still have to get used to the double level of boot loaders I forgot that I still can choose to boot from the USB stick, which will also boot Clover, but with the parameters from the USB stick. And with those, I can still boot into the newly installed OSX. It's only when I boot Clover from my new installation on the OSX disk, I get the boot problems. So, I can boot into OSX again and fix this now.

 

I am still not too happy with the way all those guides on the tony... website are written - they are way too fixed on one way to do it, and if something doesn't work out that way, then you're left with asking dozens of questions on the forum. I think it would really help if there was a single page that explained these things better, how they all work together, from a user's view. But maybe that's just how I think - I just want to understand things and get stuck where others with less care succeed. I just "think different", I guess

 

2) UEFI, USB kbd. But now that I boot again from my USB stick, I see that I can use the USB kbd there. I guess the EFI/CLOVER/config.plist is responsible for all behaviors of the clover GUI, so I can simply compare the two and figure out what's causing this. When I know, I'll report back - maybe this helps others in the future. (Again, a comprehensive page with all these conditions and solutions would be nice to have - the forum is a pain to search when there's 100s of similar answers that are all just not exactly on the point. But I also understand that it's difficult to maintain such a FAQ, I have the same problem with my own apps I develop. It's more work at first, but it will help in the long run. I wonder why there's no wiki any more where people with a clue could add this info - did it get out of hand?)

 

Also - does the EFI shell I can open in Clover use the full command set that I find here: http://docstore.mik.ua/manuals/hp-ux/en/5991-1247B/ch04s13.html- or does Clover do its own thing?

 

BTW - I just realize that I used to try to document some Hackintosh things back in 2009 already. Totally forgot about it, but now I found it again using Google

Too many questions! Ask one question a time and you you get full answer from participants.

 

Clover uses Shell compiled from https://github.com/tianocore/edk2/tree/master/ShellPkg

but with some error corrections:

- short device path written into BOOTxxx NVRAM entries. It required by most BIOSes but ignored by EDK2 devs.

- using UnicodeCollation2 if UnicodeCollation is not present. Ignored by EDK2.

- time printing, may be already corrected.

- UUID printing, may be already corrected.

- don't ASSERT as we want return to Clover. Not accounting by EDK2

So the answer to your question. Yes, there is full commands support. Type "Help -b" to see the full list.

[bs0d]

Too many questions! Ask one question a time and you you get full answer from participants.

 

Clover uses Shell compiled from https://github.com/tianocore/edk2/tree/master/ShellPkg

but with some error corrections:

- short device path written into BOOTxxx NVRAM entries. It required by most BIOSes but ignored by EDK2 devs.

- using UnicodeCollation2 if UnicodeCollation is not present. Ignored by EDK2.

- time printing, may be already corrected.

- UUID printing, may be already corrected.

- don't ASSERT as we want return to Clover. Not accounting by EDK2

So the answer to your question. Yes, there is full commands support. Type "Help -b" to see the full list.

 

Your wrong about shortened device paths.

 

and ASSERTS aren't compiled in RELEASE target.

[Slice]

Your wrong about shortened device paths.

 

and ASSERTS aren't compiled in RELEASE target.

If compile Shell to RELEASE then NULL pointer dereferencing.

My patch

//  ASSERT(String != NULL);
//  ASSERT(*String!= NULL);
  if (!String || !(*String)) {
    return EFI_INVALID_PARAMETER;
  }
  //
  // Remove any spaces and tabs at the beginning of the (*String).
  //
  while (((*String)[0] == L' ') || ((*String)[0] == L'\t')) {
    CopyMem((*String), (*String)+1, StrSize((*String)) - sizeof((*String)[0]));
  }

[bs0d]

i dont think this is the place to teach people how to code and interpret code.

 

but you little snippet just proves you aren't testing parameters before the function.

[mhaeuser]

@tempel That 'new AptioFix' is totally awful and doesn't 'fix' anything. All it does is free all memory within the potential XNU kernel range... what if RT data is stored there? You can expect all kinds of malfunctioning with such a concept. The only real way of going at this is to either free BS data/code (this may be bad as boot.efi is not guaranteed to succeed) or to use many small relocation blocks (as I had proposed a few weeks back). RT code/data can be relocated in the way boot.efi does it by MemoryMap fooling.

 

@Slice Sorry, but I think you don't understand the point of ASSERT() and the EDK2 coding practice. All EDK2 protocol and services implementations, so everything that is called outside of the own binary, has an EFI_STATUS return (well, or VOID if there is nothing to return) and verifies parameters on each call and returns the appropiate status.

However, internal and library functions, which are only used within the binary/linked statically, use ASSERT() to verify parameters. Why? Because it is known at build time what the function requires. If a function does not support NULL parameters, then don't pass NULL - this is the idea behind ASSERT(), to verify the conditions are met. Every single ASSERT() triggerment resulting from such a check should be fixed within the caller code and not lead to some status return.

What I have just explained is common practise and makes a lot of sense to me, however it's not defined as part of any of the guidelines. Hence, different EDK2 developers have opted for a different way (like yours) and different ways of going at it can be seen within the source tree. However, the runtime checks for EFIAPI functions and ASSERT() for statically linked functions should be preferred imo.

 

EDIT:

 

Clover uses Shell compiled from https://github.com/tianocore/edk2/tree/master/ShellPkg

but with some error corrections:

- short device path written into BOOTxxx NVRAM entries. It required by most BIOSes but ignored by EDK2 devs.

- don't ASSERT as we want return to Clover. Not accounting by EDK2

 

ASSERT() explained above...

about short device paths: Yes, it's right that some UEFI implementations require it, but this is totally out of specs and a silly bug that either American Megacr** or the OEM introduced. Furthermore, I have added support for short device paths to ShellPkg (add and addp now work as expected).

[tempel]

Too many questions! Ask one question a time and you you get full answer from participants.

 

But that only adds more clutter to the many replies that are already here, I'd think. I'd rather post individual topics on this forum, but as I wrote first, the forum won't let me post new topics. No idea why. It's not that I'm not thinking here. But okay, if you prefer it that way, I'll post multiple comments with individual questions in the future.

@tempel That 'new AptioFix' is totally awful and doesn't 'fix' anything. All it does is free all memory within the potential XNU kernel range... what if RT data is stored there? You can expect all kinds of malfunctioning with such a concept. The only real way of going at this is to either free BS data/code (this may be bad as boot.efi is not guaranteed to succeed) or to use many small relocation blocks (as I had proposed a few weeks back). RT code/data can be relocated in the way boot.efi does it by MemoryMap fooling.

 

Oh, then I misunderstood what the fix does. Thanks for clarifying, as I had gotten the impression this was the holy grail of all the issues. I thought it would somehow force the memory map to be rearranged.

 

Could you elaborate on what's happening, i.e. why the defragmentation happens and why it's not happening with Apple's own EFI? Are all the answers in the ticket thread? (I must admit I only read a part of it as it's very long and I didn't think I needed to read it all, thinking it was solved.) I've helped with open source projects before (e.g. added HFS support to iPodLinux), so I'm not totally ignorant and like to learn new things, too. Or is there a better place to discuss this?

 

In short, I understand that the problem is that various drivers allocate memory, and there's only a limited amount available, and eventually the memory is so fragmented that even though there's plenty of free memory, nothing is big enough any more when we run into this "error allocating pages" issue. What I don't understand is why that even happens. Couldn't the total memory made available just be increased until it's enough, even with fragmentation?

[Riley Freeman]

Should work now

CLOVERX64.efi-3593.zip

 

All good now

[tempel]

Back on the Clover GUI and the question what the various <clover> icons do there.

 

Now that I have a working keyboard again in Clover, I could move the selection using the cursor keys to get to them and saw that they say "Clover Boot Options".

 

Still, that's all very non-obvious (e.g. I had no idea I could move the selection with the cursor keys, especially past the row of disks - that's all very unusual for a Mac user like me) and so I still suggest that a page is made on the wiki that explains how to use the GUI, with explanations what everything does.

 

If I can help with that, I'd be happy to (you'll find my contact details thru my website I post on my user page).

[Slice]

@bs0d, @Download-Fritz

Did you proposed better sources for ShellPkg? I never saw such propositions.

 

My Shell is working while Shell from EDK2 just show me ASSERT(bla-bla..) and computer hangs. That's all story.

[mhaeuser]

Oh, then I misunderstood what the fix does. Thanks for clarifying, as I had gotten the impression this was the holy grail of all the issues. I thought it would somehow force the memory map to be rearranged.

 

Could you elaborate on what's happening, i.e. why the defragmentation happens and why it's not happening when Apple' own EFI? Are all the answers in the ticket thread? (I must admit I only read a part of it as it's very long and I didn't think I needed to read it all, thinking it was solved.) I've helped with open source projects before (e.g. added HFS support to iPodLinux), so I'm not totally ignorant and like to learn new things, too. Or is there a better place to discuss this?

 

In short, I understand that the problem is that various drivers allocate memory, and there's only a limited amount available, and eventually the memory is so fragmented that even though there's plenty of free memory, nothing is big enough any more when we run into this "error allocating pages" issue. What I don't understand is why that even happens. Couldn't the total memory made available just be increased until it's enough, even with fragmentation?

 

You cannot just rearrange memory map as you wish, all the pointers to data would just point into the woods if you randomly relocated it. If you are interested in a possible solution, check here: http://www.insanelymac.com/forum/topic/306156-clover-bugissue-report-and-patch/page-18?do=findComment&comment=2227865. Another possible issue is when a relocation block is allocated where a future boot.efi region will be (double-conflict).

 

Defragmentation is not happen, but fragmentation lol. Can't say more than that AMI sucks, I have no clue how the memory map can be changing on each boot and be so incontinous. It doesn't happen in Apple's EFI and also not with DUET because they allocate memory from top to bottom (AMI should do that too but... no?).

And the primary issue is that boot.efi -> XNU transition happens with 32-bit addresses, so everything must be < 4GB. Even if you have 128GB in your system, it won't work out because only < 4GB gets used by boot.efi.

 

 

@bs0d, @Download-Fritz

Did you proposed better sources for ShellPkg? I never saw such propositions.

 

My Shell is working while Shell from EDK2 just show me ASSERT(bla-bla..) and computer hangs. That's all story.

 

The story would be complete if you would actually say where it ASSERTs... it always ASSERTs on exit for reasons unknown to me. I have asked in the list and nobody really gave an answer. I suppose it is because there is a memory leak, but it makes no sense to ASSERT because of that.

[Slice]

 

about short device paths: Yes, it's right that some UEFI implementations require it, but this is totally out of specs and a silly bug that either American Megacr** or the OEM introduced. Furthermore, I have added support for short device paths to ShellPkg (add and addp now work as expected).

OK, I have namely this buggy AMI UEFI BIOS. I can't correct it, I can adopt Shell for it.

[bs0d]

so AMI firmware is at fault and you blame EDK2 ASSERT .. way to go.

[tempel]

Can't say more than that AMI sucks, I have no clue how the memory map can be changing on each boot and be so incontinous.

 

Oh, so that's another misunderstanding of mine about how Clover works. That means that Clover is NOT implementing its own EFI-"BIOS" then but uses the one on the board (made by AMI)? I thought Clover is a "RealEFI", and thus would have full control over the entire communication between the EFI drivers and the EFI "OS"?

 

Well, I still have some holes in understanding how BIOS, EFI, and the particular implementations on PCs and Macs work. You wouldn't know of some good intro articles on that, would you?

[mhaeuser]

OK, I have namely this buggy AMI UEFI BIOS. I can't correct it, I can adopt Shell for it.

 

https://github.com/tianocore/edk2/commit/f86a5c346578a9503f7383c6eb77ce256f33b605