Jump to content

Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)

theconnactic

By theconnactic,
in OS X 10.9 (Mavericks)

 Share
6,414 posts in this topic

Recommended Posts

Sinetek
Sinetek
Posted
Posted

Yes it will, No more glitches on ATI, NVIDIA.

still got some pink icons though.

 

 

mtrr.diff:

--- xnu-2422.1.72/osfmk/i386/mtrr.c	2011-10-18 18:42:25.000000000 -0400
+++ xnu-2422.1.72-anv/osfmk/i386/mtrr.c	2013-11-07 17:48:28.000000000 -0500
@@ -65,7 +65,7 @@
 
 //#define MTRR_DEBUG 1
 #if	MTRR_DEBUG
-#define DBG(x...)	kprintf(x)
+#define DBG(x...)	printf(x)
 #else
 #define DBG(x...)
 #endif
@@ -257,6 +257,24 @@
 }
 #endif /* MTRR_DEBUG */
 
+/*** Sinetek: AMD requires configuring a few more things ***/
+/***   doesn't seem to do anything ***/
+void mtrr_amd_init()
+{
+	uint64_t HWCR = rdmsr64(0xC0010015 );
+	printf("AMD_HWCR  %016llX\n", HWCR);
+
+	HWCR |= 1 << 1;
+	HWCR |= 1 << 3;
+	HWCR |= 1 << 4;
+	HWCR |= 1 << 6;
+	HWCR |= 1 << 8;
+	HWCR |= 1 << 17;
+	HWCR |= 1 << 18;
+
+	wrmsr64(0xC0010015, HWCR);
+}
+
 /*
  * Called by the boot processor (BP) early during boot to initialize MTRR
  * support.  The MTRR state on the BP is saved, any additional processors
@@ -273,6 +291,8 @@
 	if ((cpuid_features() & CPUID_FEATURE_MTRR) == 0)
         	return;  /* no MTRR feature */
 
+	//mtrr_amd_init();
+
 	/* use a lock to serialize MTRR changes */
 	bzero((void *)&mtrr_state, sizeof(mtrr_state));
 	simple_lock_init(&mtrr_lock, 0);
@@ -337,6 +357,10 @@
 	/* flush TLBs */
 	flush_tlb_raw();
 
+	//uint32_t amd;
+	//PE_parse_boot_argn("-amd", &amd, sizeof (amd));
+	//if(amd) mtrr_amd_init();
+
 	if (CACHE_CONTROL_PAT == cache_control_type) {
 		/* Change PA6 attribute field to WC */
 		uint64_t pat = rdmsr64(MSR_IA32_CR_PAT);
@@ -362,7 +386,8 @@
 
 		/* enable all MTRR range registers (what if E was not set?) */
 		wrmsr64(MSR_IA32_MTRR_DEF_TYPE,
-			mtrr_state.MTRRdefType | IA32_MTRR_DEF_TYPE_E);
+			MTRR_TYPE_UNCACHEABLE | IA32_MTRR_DEF_TYPE_E );
+
 	}
 
 	/* flush all caches and TLBs a second time */
@@ -680,7 +705,8 @@
 	boolean_t	istate;
 	uint64_t	pat;
 
-	if (!(cpuid_features() & CPUID_FEATURE_PAT))
+	return;
+	if ( !(cpuid_features() & CPUID_FEATURE_PAT))
 		return;
 
 	istate = ml_set_interrupts_enabled(FALSE);
  • Like 8
Link to comment
Share on other sites
gils83
gils83
Posted
Posted

 

Yes it will, No more glitches on ATI, NVIDIA.

still got some pink icons though.

 

 

mtrr.diff:

--- xnu-2422.1.72/osfmk/i386/mtrr.c	2011-10-18 18:42:25.000000000 -0400
+++ xnu-2422.1.72-anv/osfmk/i386/mtrr.c	2013-11-07 17:48:28.000000000 -0500
@@ -65,7 +65,7 @@
 
 //#define MTRR_DEBUG 1
 #if	MTRR_DEBUG
-#define DBG(x...)	kprintf(x)
+#define DBG(x...)	printf(x)
 #else
 #define DBG(x...)
 #endif
@@ -257,6 +257,24 @@
 }
 #endif /* MTRR_DEBUG */
 
+/*** Sinetek: AMD requires configuring a few more things ***/
+/***   doesn't seem to do anything ***/
+void mtrr_amd_init()
+{
+	uint64_t HWCR = rdmsr64(0xC0010015 );
+	printf("AMD_HWCR  %016llX\n", HWCR);
+
+	HWCR |= 1 << 1;
+	HWCR |= 1 << 3;
+	HWCR |= 1 << 4;
+	HWCR |= 1 << 6;
+	HWCR |= 1 << 8;
+	HWCR |= 1 << 17;
+	HWCR |= 1 << 18;
+
+	wrmsr64(0xC0010015, HWCR);
+}
+
 /*
  * Called by the boot processor (BP) early during boot to initialize MTRR
  * support.  The MTRR state on the BP is saved, any additional processors
@@ -273,6 +291,8 @@
 	if ((cpuid_features() & CPUID_FEATURE_MTRR) == 0)
         	return;  /* no MTRR feature */
 
+	//mtrr_amd_init();
+
 	/* use a lock to serialize MTRR changes */
 	bzero((void *)&mtrr_state, sizeof(mtrr_state));
 	simple_lock_init(&mtrr_lock, 0);
@@ -337,6 +357,10 @@
 	/* flush TLBs */
 	flush_tlb_raw();
 
+	//uint32_t amd;
+	//PE_parse_boot_argn("-amd", &amd, sizeof (amd));
+	//if(amd) mtrr_amd_init();
+
 	if (CACHE_CONTROL_PAT == cache_control_type) {
 		/* Change PA6 attribute field to WC */
 		uint64_t pat = rdmsr64(MSR_IA32_CR_PAT);
@@ -362,7 +386,8 @@
 
 		/* enable all MTRR range registers (what if E was not set?) */
 		wrmsr64(MSR_IA32_MTRR_DEF_TYPE,
-			mtrr_state.MTRRdefType | IA32_MTRR_DEF_TYPE_E);
+			MTRR_TYPE_UNCACHEABLE | IA32_MTRR_DEF_TYPE_E );
+
 	}
 
 	/* flush all caches and TLBs a second time */
@@ -680,7 +705,8 @@
 	boolean_t	istate;
 	uint64_t	pat;
 
-	if (!(cpuid_features() & CPUID_FEATURE_PAT))
+	return;
+	if ( !(cpuid_features() & CPUID_FEATURE_PAT))
 		return;
 
 	istate = ml_set_interrupts_enabled(FALSE);

génial Sinetek !! , tu vas nous changer la vie !!   :thumbsup_anim:  :thumbsup_anim:

Link to comment
Share on other sites
hotcorez
hotcorez
Posted
Posted

Awesome work guys! Now all that needs to be done is to integrate the various voodoo tsc kext based fixes into the kernel to support procesors that require it and job done!

 

Congrats again to all involved :thumbsup_anim:

 

ps. does anyone know if voodoopowermini will work with this kernel or does it need to be rebuilt? thanks

Link to comment
Share on other sites
Shaneee
Shaneee
Posted
Posted

Awesome work guys! Just need to polish it off now and integrate the various tsc fix kext functions into the kernel to support the various processors and job done! Congrats to all involved

 

ps. does voodoopowermini work with this kernel or does it need to be rebuilt? thanks

 

Try the kexts and app from this post, http://www.insanelymac.com/forum/topic/281450-mavericks-kernel-testing-on-amd-formerly-mountain-lion-kernel-testing-on-amd/?p=1963282

 

Don't use the kernel though. The kernel I posted was built from that one with Sinetek's graphics fix ;)

 

Edit: If someone can tell me how to make a diff I post post the full thing :D

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

Try the kexts and app from this post, http://www.insanelymac.com/forum/topic/281450-mavericks-kernel-testing-on-amd-formerly-mountain-lion-kernel-testing-on-amd/?p=1963282

 

Don't use the kernel though. The kernel I posted was built from that one with Sinetek's graphics fix ;)

 

Edit: If someone can tell me how to make a diff I post post the full thing :D

ah, i missed the great work here! thanks for pointing me in the right direction. could the addtional voodoopower system file dependancy be removed by clever coding or patching in clover for instance?

  • Like 1
Link to comment
Share on other sites
theconnactic
theconnactic
Posted
  • Author
Posted (edited)

Congratulations, Sinetek!

 

First you've made 64-bit OSX86 on AMD possible with your opcode emulator - the very reason we're still around - and now you inject new life on the AMD hackintosh scene by making the user experience flawless. Much respect to you! And thank you very much again.

 

If this is possible to be implemented as a binary patch, so iCloud services become supported OOB, we can even start recommending AMD builds for the tighter budgets. :)

 

All the best!


P.S.: can anyone who is around a computer with GCC/Xcode add the graphics fix patch to Lion and ML's kernels?

Edited by theconnactic
Originally sent from iPhone, awful grammar, had to edit it! :p
  • Like 5
Link to comment
Share on other sites
Shaneee
Shaneee
Posted
Posted

Congratulations, Sinetek!

 

First you made 64-bit OSX86 on AMD possible with your opcode emulator - the very reason we're still around - and now you inject new life on the AMD hackintosh scene by makin the user experience flawless. Much respect to you! And thank you very much again.

 

If this is possible to be implemented as a binary patch, so iCloud services became supported, we can even recommend AMD builds for the tighter budgets. :)

 

All the best!

P.S.: can anyone who is around a computer with GCC/Xcode add the graphics fix patch to Lion and ML's kernels?

 

Would this be somewhere to start then?

 

http://forge.voodooprojects.org/p/chameleon/source/tree/341/branches/meklort/i386/modules/KernelPatcher

  • Like 1
Link to comment
Share on other sites
Mohamed Khairy
Mohamed Khairy
Posted
Posted

Congratulations, Sinetek!

 

First you made 64-bit OSX86 on AMD possible with your opcode emulator - the very reason we're still around - and now you inject new life on the AMD hackintosh scene by makin the user experience flawless. Much respect to you! And thank you very much again.

 

If this is possible to be implemented as a binary patch, so iCloud services became supported, we can even recommend AMD builds for the tighter budgets. :)

 

All the best!

P.S.: can anyone who is around a computer with GCC/Xcode add the graphics fix patch to Lion and ML's kernels?

really don't know if binary patch will help on fixing iCloud etc or not

 

as i tested latest andy kernel on my notebook and iCloud worked normally

 

nearly we need to make os x identify our cpu as intel more

 

any way it will be solved and other problems with the time  with our genius developers :D 

Link to comment
Share on other sites
theconnactic
theconnactic
Posted
  • Author
Posted

as i tested latest andy kernel on my notebook and iCloud worked normally

 

Can you sign out and sign back in? Try it - at your own risk, I warn you, because you probably cloned your current installation from a system where iCloud works, thus you have your token, and if you sign out you'll lose it - because AFAIK no compiled kernel can sign in to iCloud, because iCloud support doesn't come with XNU sources (Apple, always giving thinks, never giving everything :) )

Maybe contact Meklort for an idea on how to start?

I don't think he has time to help us with this - in fact, I'm currently helping him, providing an appropriate patch for Atom CPUs, because (his exact words) the current patch, which happens to be Andy's patch for AMD, is way to large for him to implement it.

 

But you can always file a bug report here - KernelPatcher - and talk with him directly.

 

All the best!

  • Like 2
Link to comment
Share on other sites
Mohamed Khairy
Mohamed Khairy
Posted
Posted

Can you sign out and sign back in? Try it - at your own risk, I warn you, because you probably cloned your current installation from a system where iCloud works, thus you have your token, and if you sign out you'll lose it - because AFAIK no compiled kernel can sign in to iCloud, because iCloud support doesn't come with XNU sources (Apple, always giving thinks, never giving everything :) )

I don't think he has time to help us with this - in fact, I'm currently helping him, providing an appropriate patch for Atom CPUs, because (his exact words) the current patch, which happens to be Andy's patch for AMD, is way to large for him to implement it.

 

But you can always file a bug report here - KernelPatcher - and talk with him directly.

 

All the best!

you are right :)

@Sinetek

 

what about my problem with lag that enforce me to use yes > /dev/null

is there anther work around on kernel for that ?

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