Jump to content

Chameleon 2.4svn Official PKG Installer

ErmaC

By ErmaC,
in Chameleon

 Share
4,261 posts in this topic

Recommended Posts

Zenith432
Zenith432
Posted
Posted

csrutil shows you the right status, as it gets the value by doing a system call to get it from the kernel.

The source code for KCPM is unavailable, but if it gets the value from NVRam variable csr-active-config, it is doing the wrong thing.

boot.efi reads this nvram variable, and puts the value in kernel struct boot-args.  Chameleon sets this value directly in boot-args without bothering with NVram, which it does not support.  The value used by the kernel is the one in the struct, and can be obtained from the kernel with a system call.

If it makes you feel better, I'll add a printout into bdmesg to show the value it is setting.  This won't alter the behavior of csrutil or KCPM.

 

 

Booting with r2812 I'm still having issues with CsrActiveConfig. I have it set in my boot.plist as follows,

	<key>CsrActiveConfig</key>
	<string>103</string>

csrutil status results in, System Integrity Protection status: disabled. But for example KCPM Utility shows the following

Warning: 
System Integrity Protection >> B1: Allow Unrestricted Filesystem is currently DISABLED.

You cannot install kernel extensions into /System/Library/Extensions/.
  • Like 1
Link to comment
Share on other sites
Shaneee
Shaneee
Posted
Posted

 

 

csrutil shows you the right status, as it gets the value by doing a system call to get it from the kernel.

The source code for KCPM is unavailable, but if it gets the value from NVRam variable csr-active-config, it is doing the wrong thing.

boot.efi reads this nvram variable, and puts the value in kernel struct boot-args. Chameleon sets this value directly in boot-args without bothering with NVram, which it does not support. The value used by the kernel is the one in the struct, and can be obtained from the kernel with a system call.

If it makes you feel better, I'll add a printout into bdmesg to show the value it is setting. This won't alter the behavior of csrutil or KCPM.

Ahh ok wasn't aware they got the value different ways. No need to change it then :)

 

Sent from my SM-G920F using Tapatalk

Link to comment
Share on other sites
Micky1979
Micky1979
Posted
Posted

Didn't work, same errors as before.

Found the bug with -f (I guess)

 

// bootFile must start with a / if it not start with a device name

if (!bootFileWithDevice && (bootInfo->bootFile)[0] != '/')

{

        if ( !YOSEMITE || !ELCAPITAN ) //Is not Yosemite 10.10 or El Capitan 10.11

        if ( MacOSVerCurrent < MacOSVer2Int("10.10") ) //Is not Yosemite 10.10 or El Capitan 10.11

        {

            snprintf(bootFile, sizeof(bootFile), "/%s", bootInfo->bootFile); // append a leading /

        }

        else

        {

            snprintf(bootFile, sizeof(bootFile), kDefaultKernelPathForYos"%s", bootInfo->bootFile); // Yosemite or El Capitan

        }

}

boot.zip

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

crazybirdy, Shanee --> trunk@2815 both issues.

 

 

Found the bug with -f (I guess)

 

// bootFile must start with a / if it not start with a device name

if (!bootFileWithDevice && (bootInfo->bootFile)[0] != '/')

{

        if ( !YOSEMITE || !ELCAPITAN ) //Is not Yosemite 10.10 or El Capitan 10.11

        if ( MacOSVerCurrent < MacOSVer2Int("10.10") ) //Is not Yosemite 10.10 or El Capitan 10.11

        {

            snprintf(bootFile, sizeof(bootFile), "/%s", bootInfo->bootFile); // append a leading /

        }

        else

        {

            snprintf(bootFile, sizeof(bootFile), kDefaultKernelPathForYos"%s", bootInfo->bootFile); // Yosemite or El Capitan

        }

}

 

Thanks for reply.

Both boot files work fine to read /System/Library/Kernels/kernel,

but stuck before Read HFS+ file: hd 0,x ......

trunk 2815

post-61100-0-81979500-1463457779_thumb.jpg

Enoch 2816

post-61100-0-73160400-1463457786_thumb.jpg

 

And I found the root cause is (2807) trunk/i386/libsaio/fake_efi.c, it didn't boot with my old MB asus P5B.

After replace to old fake_efi.c (2790-2806) and rebuild boot file, the kext reading works fine and boot to 10.11.4 system now.(patched kernel)

So I can't use Enoch branch 2816 now.

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

And I found the root cause is (2807) trunk/i386/libsaio/fake_efi.c, it didn't boot with my old MB asus P5B.

After replace to old fake_efi.c (2790-2806) and rebuild boot file, the kext reading works fine and boot to 10.11.4 system now.(patched kernel)

So I can't use Enoch branch 2816 now.

It's because of this

//

// FIXME: PM Timer is usually @ 0x408, but its position is relocatable

// via PCI-to-ISA bridge. The location is reported in ACPI FADT,

// PM Timer Block address - zenith432

//

Your PM Timer is not at 0x408, so esi always gets the same value, and the continue statement there generates an infinite loop. As a temporary workaround, comment out the continue statement a few lines below this comment. I need to think of a permanent solution.

 

The fix to the kernel path for Enoch (or this problem) has not been checked in yet.

  • Like 2
Link to comment
Share on other sites
Zenith432
Zenith432
Posted
Posted (edited)

crazybirdy,

 

Please try attached fake_efi.c with trunk 2815.  Overwrite i386/libsaio/fake_efi.c and make a clean build of boot.  Check if it prevents the freeze, or if the workaround causes a noticeable delay.  If it's ok I'll commit it.

 

Thanks.

 

Edit: Attachment removed, committed to r2817.

Edited by Zenith432
  • Like 2
Link to comment
Share on other sites
crazybirdy
crazybirdy
Posted
Posted

crazybirdy,

 

Please try attached fake_efi.c with trunk 2815.  Overwrite i386/libsaio/fake_efi.c and make a clean build of boot.  Check if it prevents the freeze, or if the workaround causes a noticeable delay.  If it's ok I'll commit it.

 

Thanks.

 

Good news.

Rebuild trunk 2815 with new fake_efi.c, boot fine to system 10.11.4 without any freeze or errors with -v -f, patched kernel.

Thanks, have a nice day.

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

It's because of this

Your PM Timer is not at 0x408, so esi always gets the same value, and the continue statement there generates an infinite loop. As a temporary workaround, comment out the continue statement a few lines below this comment. I need to think of a permanent solution.

 

The fix to the kernel path for Enoch (or this problem) has not been checked in yet.

Cool, great (Thanks)

Thanks for reply.

 

So I can't use Enoch branch 2816 now.

Thanks to you my friend!

If is not a problem can you test this one also, with Zenith432 fix? (for Pandora)

boot.zip

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

In Enoch.

 

r2824 in trunk - Attempt to have uniform flow of time in progress bar during countdown.

Originally I added support for protected-mode interrupts for this, but ErmaC disabled it later on.  So progress bar regressed.  Now I try something else so that timer interrupts are not missed during countdown.

Link to comment
Share on other sites
  • 3 weeks later...
>Federico<
>Federico<
Posted
Posted

New version r2824 in Pandora's Box with kernel patcher improvement (thanks crazybirdy to have find the bug)

With this improvement chameleon will load kexts from E/E?

 

EDIT

I tried version r3015 and kext inject by E/E doesn't work in verbose says searching and then nothing found, also KernelPm patch doesn't work in verbose says kernel patched but I always get kp due AICPMU.kext (idk if it is related to that :))

Link to comment
Share on other sites
Micky1979
Micky1979
Posted
Posted

With this improvement chameleon will load kexts from E/E?

 

tested and working

I tried version r3015 and kext inject by E/E doesn't work in verbose says searching and then nothing found

normal behavior, never logs kexts loaded.

also KernelPm patch doesn't work in verbose says kernel patched but I always get kp due AICPMU.kext (idk if it is related to that  :))

 

No, nothing to do with AppleIntelCPUPowerManagement, so will continue to give you panics  :hysterical:

 

 

I tried version r3015

you have receive the downloadable r2824 update for Enoch? Can I have the log inside the Extra folder?

 

 

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