Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
30,171 posts in this topic

Recommended Posts

Mirone
Mirone
Posted
Posted

Anyone here have problems with reboot? with the latest version r3994 this problem for me became frequent.

simply does not restart, stays in a black screen with the led 
HDD blinking, and after that just only pressing the button 
power to turn off.

  • Like 1
Link to comment
Share on other sites
Sherlocks
Sherlocks
Posted
Posted

Anyone here have problems with reboot? with the latest version r3994 this problem for me became frequent.

simply does not restart, stays in a black screen with the led

HDD blinking, and after that just only pressing the button

power to turn off.

http://www.insanelymac.com/forum/index.php?/topic/284656-Clover-General-discussion&do=findComment&comment=2359605

 

Please test this, and report

 

Thank you

 

나의 LG-F410S 의 Tapatalk에서 보냄

  • Like 1
Link to comment
Share on other sites
PMheart
PMheart
Posted
Posted

Hi. I came up with a new idea to find the patch code for KernelPm dynamically instead of now-using static data.

But... Cannot test and too lazy to write code.  :P

Here it is: (Patch kernel_patcher.c)

 

1. Introduce "UINT32" variable 'i'

2. Call SearchAndCount() to find '00 00 00 00 00 00 00 00 0F 04 00 00 00 00 00 00' and check how many sets we can found.

3. Introduce "int" variable 'k'

4. for (k=0; k < SearchAndCount('00 00 00 00 00 00 00 00 0F 04 00 00 00 00 00 00'); k++) {

      // introduce "int" variable 'j'

      for (j=8; j>0; j--)

        bytes[i-j] == 0x00 // the actual patch for KernelPm 10.10+

}

 

Could someone write the code based on the idea above? Thanks in advance.  :)

Link to comment
Share on other sites
bs0d
bs0d
Posted
Posted

Hi. I came up with a new idea to find the patch code for KernelPm dynamically instead of now-using static data.

But... Cannot test and too lazy to write code.  :P

Here it is: (Patch kernel_patcher.c)

 

1. Introduce "UINT32" variable 'i'

2. Call SearchAndCount() to find '00 00 00 00 00 00 00 00 0F 04 00 00 00 00 00 00' and check how many sets we can found.

3. Introduce "int" variable 'k'

4. for (k=0; k < SearchAndCount('00 00 00 00 00 00 00 00 0F 04 00 00 00 00 00 00'); k++) {

      // introduce "int" variable 'j'

      for (j=8; j>0; j--)

        bytes[i-j] == 0x00 // the actual patch for KernelPm 10.10+

}

 

Could someone write the code based on the idea above? Thanks in advance.  :)

Or just port the symbol based patcher that meklort did umm 4 years ago for chameleon.

  • Like 3
Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

No.

Range [0x80000, 0x9f000] satisfies first condition but not second.

Yes, I know that... That is the question. What is that check actually trying to do, logically? You are not looking for something in that fixed span, so what do the values even mean?
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Yes, I know that... That is the question. What is that check actually trying to do, logically? You are not looking for something in that fixed span, so what do the values even mean?

It was the solution for Sleep/Wake in UEFI boot if Intel graphics used. It somehow used this range.

Link to comment
Share on other sites
joevt
joevt
Posted
Posted

I just saw this in the latest AptioFix src in Lib.c:

if ((Desc->PhysicalStart < 0xa0000) && (PhysicalEnd >= 0x9e000))
What is this supposed to do? Want to check for a Memory region that is fit in 0x9e000 - 0xa0000? If so, wouldn't it rather need to be this?

if ((Desc->PhysicalStart >= 0x9e000) && (PhysicalEnd <= 0xa0000))

 

"StartA < EndB and EndA >= StartB" returns true if A and B overlap (given that Start# is <= End#) except it should probably be written as this:

"StartA < EndB and EndA > StartB" because the first way would also return true if A precedes B with zero bytes between (if End# means the address after the last byte of the range).

 

 

"StartA >= StartB and EndA <= EndB" returns true if the A range is entirely inside the B range.

  • Like 1
Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

"StartA < EndB and EndA >= StartB" returns true if A and B overlap (given that Start# is <= End#) except it should probably be written as this:

"StartA < EndB and EndA > StartB" because the first way would also return true if A precedes B with zero bytes between (if End# means the address after the last byte of the range).

 

 

"StartA >= StartB and EndA <= EndB" returns true if the A range is entirely inside the B range.

Thanks, but I know what the logic does. I asked what it was supposed to do because I doubted it was coded the way it was meant logically, especially as the initial check was done against Start for either. :)

Link to comment
Share on other sites
kosakgroove
kosakgroove
Posted
Posted

I have a weird bug I have noticed, and it only happens when Mac OS X with Clover is installed in the hard drive. I am talking about my Lenovo Thinkpad L420

I get a message 2 out of 3 times I boot or restart the computer...

 

0251- CMOS bad checksum error - Default configuration used

 

After I press Esc then the computer resets the BIOS and successfully boots Clover from the GUID disk.

 

I already changed the CMOS battery for a brand new one and the error kept popping up. Then I installed the latest original BIOS from Lenovo and the error continued there. So I flashed again the custom BIOS mentioned in the first post. Then I inserted a HDD with Linux installed, and after like 20 boots I noticed the error was not there, even with the custom BIOS.

 

Then I tried with Windows, and the error also was not there. So I thought maybe the bug is gone, and proceeded to reinstall Mac OS X with Clover and yes, the error came back....

 

I figured maybe using the Apple RTC fix in Clover would help, but it doesn't

 

We are left with two explanations... This Lenovo does not like to have a GUID hard disk as a boot device or it is Mac OS X that randomly writes something to the BIOS or EFI partition and corrupts that boot sector, giving the checksum error. Weird thing is that it doesn't happen every boot, that is what really boggles my mind.

 

Is there anyone who could help debug this issue???

Link to comment
Share on other sites
kosakgroove
kosakgroove
Posted
Posted

That seems to fix the CMOS error, thanks!

I really appreciate your help! It seems to have solved the issue for me as of now. I will report back after extensive testing :D 

I wonder if Slice could integrate this fix to Clover, so I could use the default version... Cheers  :thumbsup_anim:

  • Like 3
Link to comment
Share on other sites
Sherlocks
Sherlocks
Posted
Posted

I really appreciate your help! It seems to have solved the issue for me as of now. I will report back after extensive testing :D

I wonder if Slice could integrate this fix to Clover, so I could use the default version... Cheers :thumbsup_anim:

Thank you for report.

 

I take a report with other issue in r3994 fix from tester. Most of features is working now like r3974. After this is resolve, i will post solution here.

 

 

나의 LG-F410S 의 Tapatalk에서 보냄

  • Like 2
Link to comment
Share on other sites
joevt
joevt
Posted
Posted

Thanks, but I know what the logic does. I asked what it was supposed to do because I doubted it was coded the way it was meant logically, especially as the initial check was done against Start for either. :)

You were asking whether the original or your version of the logic was correct.

I was trying to say that if the original was more correct, then it may still need a change so that it doesn't return true when the memory descriptor ends before 0x9e000 (when PhysicalEnd = 0x9e000).

 

I don't know what you mean by "initial check was done against Start for either". What's the initial check?

Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

Sorry, I'm on my phone, can't cite well or tell you the commit details, but some old rev checked PhysicalStart against both values (PhysicalEnd was not present; "initial check" was bad wording, sorry). Only the first solution makes sense to me, because I expect a fixed address (start addr) or a fixed range (min/max start addr and maybe max end address), not some 'overlap range'.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

Hi. Anyone wanna test the new way of KernelPm patching? If this works fine then I would be very appreciated!

I just noticed that we can do the same thing for 10.8.5, 10.9.x, @RehabMan and @Pike R. Alpha 's good old way is a little complicated... LOL

 

attachicon.gifnew_kernel_patcher.c_kernelPm-newway.zip

attachicon.gifCLOVERX64.efi.zip

I think your new code is a fair bit slower than the original.

Cleaning up the original is a fine idea, but we might want to keep some of the optimizations:

- data was aligned on 16 byte boundary (no need to start search at every byte)

- early termination of search when final patch is found/replaced

  • Like 1
Link to comment
Share on other sites
PMheart
PMheart
Posted
Posted

I think your new code is a fair bit slower than the original.

Yes though.  :P

But this can be more flexible since we may not need to check the new patch data when the new system is coming. At least. For 10.10.x ~ now 10.12.4 DP1. The way to find the patch code does not change, right? LOL 

I think your new code is a fair bit slower than the original.

Cleaning up the original is a fine idea, but we might want to keep some of the optimizations:

- data was aligned on 16 byte boundary (no need to start search at every byte)

- early termination of search when final patch is found/replaced

Thanks for your excellent suggestions. But now in Singapore it's almost 0:00 A.M... Time to sleep. See you tomorrow.  :)

BTW. I may be too lazy to write code and also may have no ability to do so. It's nearly 4 years that I haven't written C lang code...

Suggestion #1: Agree. May update later if I can...

                 #2: I don't think so. For 10.8.5 and 10.9.x, just work fine. But for 10.10+ we have to find/repl more than 1 time and we don't know when the last hex will be patched and therefore we don't know when to break;

Link to comment
Share on other sites
joevt
joevt
Posted
Posted

Sorry, I'm on my phone, can't cite well or tell you the commit details, but some old rev checked PhysicalStart against both values (PhysicalEnd was not present; "initial check" was bad wording, sorry). Only the first solution makes sense to me, because I expect a fixed address (start addr) or a fixed range (min/max start addr and maybe max end address), not some 'overlap range'.

I'm guessing the range [0x9e000, 0xa0000) is some kind of special physical memory range that requires a certain behavior from any memory descriptor that overlaps that range. Therefore the latest version of the line is logically more correct:

if ((Desc->PhysicalStart < 0xa0000) && (PhysicalEnd >= 0x9e000)) {
but it should be changed to this:

if ((Desc->PhysicalStart < 0xa0000) && (PhysicalEnd > 0x9e000)) {

 

For the initial checkin, I think you mean this:

if ((Desc->PhysicalStart >= 0x9e000) && (Desc->PhysicalStart < 0xa0000)) {
This one checks if the memory descriptor starts inside the range. That doesn't catch memory descriptors that start before the range and end inside the range.

 

Your suggestion doesn't catch memory descriptors that start before the range or end after the range.

 

I don't know where the range numbers come from, I don't know what the memory descriptor change does:

Desc->Type = EfiACPIMemoryNVS;
Desc->Attribute = 0;
and I don't know how memory descriptors that are not entirely inside the range behave.
Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

but it should be changed to this:

if ((Desc->PhysicalStart < 0xa0000) && (PhysicalEnd > 0x9e000)) {

If your assumption is correct, then definitely so. "PhysicalEnd" is not the last address, but the first address after the descriptor, so if it's equal, it would be the memory range immediately before the range.

 

Your suggestion doesn't catch memory descriptors that start before the range or end after the range.

 

I know, that is how I would expect the allocation of the memory to happen. But for that we would need to know what allocates it, how it allocates it - and what it does wouldn't be bad either (didn't find any information). ^^

 

I don't know what the memory descriptor change does:

Desc->Type = EfiACPIMemoryNVS;
Desc->Attribute = 0;

This will cause the memory in the range of the descriptor to not be mapped to the virtual address space, but physically remain available at the original location (will not be relocated by boot.efi or overwritten by the kernel).

 

EDIT: @Slice What is the Type of the region that is supposed to be converted?

  • Like 1
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...