Clover General discussion

[PMheart]

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

Don't have a look on that but SearchAndCount() is enough IMHO. 

[mhaeuser]

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?

[Slice]

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.

[joevt]

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.

[mhaeuser]

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

[kosakgroove]

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???

[nekonoko]

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

 

Please test.

 

That seems to fix the CMOS error, thanks!

[kosakgroove]

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  

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

[Sherlocks]

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

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

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에서 보냄

[Mirone]

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에서 보냄

I restarted about 3 times and so far, everything is fine.

[PMheart]

Hi. I made the new style of KernelPm patching possible based on http://www.insanelymac.com/forum/topic/284656-clover-general-discussion/?p=2360288

Please test and feedback. 

 

kernel_patcher.c_kernelPm_test.zip    // deprecated now and also check http://www.insanelymac.com/forum/topic/284656-clover-general-discussion/?p=2360939

[joevt]

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?

[mhaeuser]

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

[PMheart]

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

 

new_kernel_patcher.c_kernelPm-newway.zip

[RehabMan]

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

 

new_kernel_patcher.c_kernelPm-newway.zip

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

[PMheart]

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

Yes though. 

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;

[joevt]

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.

[mhaeuser]

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?

[r2tincan]

If softRAID drives are attached during boot, clover will not start past "scanning entries...". This issue did not exist in a previous version from last year. No idea when it crept in, I'm running the newest release.

 

Created a ticket. https://sourceforge.net/p/cloverefiboot/tickets/330/

[Sherlocks]

If softRAID drives are attached during boot, clover will not start past "scanning entries...". This issue did not exist in a previous version from last year. No idea when it crept in, I'm running the newest release.

 

Created a ticket. https://sourceforge.net/p/cloverefiboot/tickets/330/

 

r3974 no problem?

[Sherlocks]

@tluck

 

i found rc script bug today.

fail case.

 

left nvram pm 4:15 in /

right nvram pm 4:18 in ESP

[Slice]

 

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

Some other. What do you ask? A purpose?

[kosakgroove]

That seems to fix the CMOS error, thanks!

Ok after extensive testing, the error has happened 1 in like 20 times.

I am running Clover r3994 with your fix and it definitely improved (before i had the error 2 of every 3 boots +- )

This is a Lenovo Thinkpad L420 with Clover in the ESP of my only hard drive with GUID and boot0ss )

 

This computer does not have UEFI. I wonder if that may be the issue and Clover or Mac OS X make my BIOS not like the GUID partition system, should I maybe try and have Clover in a 300 mb partition in a MBR scheme??

[Slice]

Ordinary BIOS doesn't see if HDD formatted as MBR or as GPT or as other map.

It boots from device. HD, CD, USB-HDD or Floppy... no matter if it has GUID or no.

 

If you install legacy Clover to GPT HDD then

boot0af into master boot record,

boot1f32 into first sector of ESP which is FAT32 formatted,

no active partitions,

boot6 rename to boot and write into ESP

EFI folder write into ESP.

That's all!

 

 

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

BS_Code    0000000000060000-000000000009EFFF 000000000000003F 000000000000000F

[nekonoko]

CMOS reset error is still there for me in 3998; I rolled back to 3994 with Sherlocks fix which works.