Jump to content

Chameleon v2.1 (Main Trunk)


ErmaC
 Share

595 posts in this topic

Recommended Posts

diff V7 PLS is a test!

 

mix the ^Andy^ "cocktails"

also add the assemble code by DutchHockeyPro

Hi Fabio

 

I've applied your v7 diff to the Chameleon trunk r753 but didn't see a change to /i386/libsaio/asm.s. I've searched your v7 diff for disableIRQs to find DHP's asm.s patch but it's not there, though I see you've commented out the two outb's in boot.c. Am I missing something?

 

Do you happen to have Revolution v0.6.24 handy? The one I released on 16 November 2010? The one with my lapic.c patch? There you will find the answer. It's LINT0 and LINT1 that need to be addressed. More intel can be found in the MP v1.4 specification (24201606.pdf) which is what I used back in the day ;)

I thought I would have it as I keep most things but I can't see it and the earliest I can find it Revolution-633 from December 2010... (i'll keep looking...) But I'm having a read of 24201606.pdf now to see if I can make sense of any of it... Lol.

 

so use at your own risk!
It's probably best (pretty obvious for most here I know but I will say it anyway) to make sure you have a working boot disk or other hard disk that you can use to boot from just in case it does go pearshaped!

It's never a bad thing to overstate these things when it comes to testing.. Everyone, please take note of the above.

Link to comment
Share on other sites

Hi Fabio

 

I've applied your v7 diff to the Chameleon trunk r753 but didn't see a change to /i386/libsaio/asm.s. I've searched your v7 diff for disableIRQs to find DHP's asm.s patch but it's not there, though I see you've commented out the two outb's in boot.c. Am I missing something?

 

;)

 

.. missed...

 

re-up diff and binaries..

sorry...

 

Fabio

Link to comment
Share on other sites

Can I ask a really dumb question?

 

What does dhp's assembly code do? (I don't read assembly, hebrew, or anything in red lol) :rolleyes:

I'm no coder ^Andy^, so I can't tell you any more than you can see yourself in the code's comments.

// Port of original patch by: CPARM (who basically did this in boot.c) Thanks

The ACPI specification dictates that the 8259 (PC-AT compatible) vectors 
must be disabled (that is, masked) when enabling the ACPI APIC operation 
but this isn't done (apparently) on all mobo's and thus we do that here.

So to my simple knowledge, it does the same as Cparm's patch but in asm and not in boot.c. But to try to learn more, I'm going to look for some older source code here and read 24201606.pdf

Link to comment
Share on other sites

I'm no coder ^Andy^, so I can't tell you any more than you can see yourself in the code's comments.

// Port of original patch by: CPARM (who basically did this in boot.c) Thanks

The ACPI specification dictates that the 8259 (PC-AT compatible) vectors 
must be disabled (that is, masked) when enabling the ACPI APIC operation 
but this isn't done (apparently) on all mobo's and thus we do that here.

So to my simple knowledge, it does the same as Cparm's patch but in asm and not in boot.c. But to try to learn more, I'm going to look for some older source code here and read 24201606.pdf

 

Ah right if thats what I think it is then there are 2 lines of code that take care of that in the boot.c file..

// Masking out so that Lion doesn't doublefault
outb(0x21, 0xff);   /* Maskout all interrupts Pic1 */
outb(0xa1, 0xff);   /* Maskout all interrupts Pic2 */

Link to comment
Share on other sites

Absolutely.

 

I realise I'm noob to this but how or why would I remove those lines of code and apply the assembler code?

 

Is there a benefit and if so how would I go about actually doing it?

Link to comment
Share on other sites

my findings...

Snow Leopard (10.6.7 32&64) ok bud macmodel

Snow Leopard Server (10.6.7 32&64) ok bud macmodel

 

I was personally tested the bootloader (obviously).

And I'm not satisfied with the recognition of the Mac model.

I do not use the specific file smbios.plist in /Extra/

In my case, the recognition of the CPU is ok, but not the model ...

(MacBookPro8, 3)? LOL

Would it be possible to implement the Kabyl's SMBIOS patcher?

 

Fabio

Link to comment
Share on other sites

Apple uses the "Virtual Wire Mode" (not legacy PIC mode) which is done in function lapic_configure in lapic.c. And since the example in the 'System BIOS Programming Guidelines' blocks the NMI. Not to mention this important patch so that first generation Intel Core iN CPU's can boot without busratio=17 cpus=1 (example) in say the HP G72 notebook I used to use, and others who have to use a custom mach_kernel or get a KP in lapic.c I use this.

 

p.s. Not too many people know what asm.s does and thus they won't even open it let alone modify it. Unlike boot.c That file is also a known place for breakage. So all in all there's no harm done when someone makes a silly mistake in boot.c because it is safely hidden in asm.s :rolleyes:

 

Oh. I didn't even mention that it is faster ROFL

Link to comment
Share on other sites

Would be nice to have an updated keylist (all keys available + how to use) or readme for the newest boot (v7).

I ask because that mixed Andy/.... sources. For example is busratio= key available, or whats now for 32 / 64 Bit ( i followed that arch=, non arch discuss and get confused) ?

Link to comment
Share on other sites

Snow Leopard (10.6.7 32&64) ok bud macmodel

Snow Leopard Server (10.6.7 32&64) ok bud macmodel

....

I do not use the specific file smbios.plist in /Extra/

But that's why the /Extra/SMBIOS.plist exists so you can override the default settings.

 

Apple uses the "Virtual Wire Mode" (not legacy PIC mode)........

Thanks for the explanation, though TBH I'm still not 100% clued up here :D

But is it safe to say that your asm.s patch does more than the original boot.c patch by cparm, as well as being faster?

 

Would be nice to have an updated keylist (all keys available + how to use) or readme for the newest boot (v7).

I agree and hopefully one main branch can come out of all this along with documentation etc.

 

I have asked to add the Chimera source as my branch at forge.voodooprojects.org and am waiting on an answer.

Hi MacMan

 

Have you posted your source since the last communication at the voodooproject's forge? Therefore, just waiting for approval?

Link to comment
Share on other sites

At this "stage" is better substitute all the 3 files

boot

boot0 or boot0hfs

boot1h

 

the source from a version to other change a loot in all of the 3 file...

how to install it manually... How install manually

 

BUT PLEASE be careful that is a TEST BOOTLOADER...

 

so use at your own risk!

 

Fabio

 

thanks for the tip.

I´m only using on Lion, and it is my test system.

Link to comment
Share on other sites

Hi MacMan

 

Have you posted your source since the last communication at the voodooproject's forge? Therefore, just waiting for approval?

I have sent the diffs between the latest trunk and my branch to Kabyl under PM for his review. I'm not sure what the next step is after that.

 

Anyway, my source will be available as soon as possible, one way or another.

Link to comment
Share on other sites

I started to have problems with Adium (1.42b1, 1.41 and 1.40) and also when I installed M$ Messenger 8, the same problem (Kernel Related) happened.

 

As insatalling these new Chamaleons were the unique changes on my system it must be related.

Link to comment
Share on other sites

Would be nice to have an updated keylist (all keys available + how to use) or readme for the newest boot (v7).

I ask because that mixed Andy/.... sources. For example is busratio= key available, or whats now for 32 / 64 Bit ( i followed that arch=, non arch discuss and get confused) ?

 

Absolutely :):D

Link to comment
Share on other sites

I do now yes along with the latest ATi support - source code available here http://www.mediafire.com/?y3roclftu494xwb if anybody would like to try it (the zip also contains the compiled code in the sym/i386 folder if you don't want to compile it yourself).

 

This build will happily dual boot both Lion and Snow Leopard.

 

Enjoy :D

 

EDIT - I should add that very little of this is my own work - like yourself I have taken all of the bits that work from other people's builds and put it together as best I can. The ATi code is courtesy of Kabyl's hard work, the Sandybridge code is courtesy of AnVal/Valv's hard work and the Lion booting is courtesy of mozodojo. My only contribution is drinking plenty of coffee and beer whilst putting it all together and adding some new device id's and framebuffers to the ati.c file.

Hey Andy,

 

I checked the patch and it seems you forgot the changes in pci.c/pci.h, these are necessary in ati.c.

 

Thanks!

Link to comment
Share on other sites

Hey Andy,

 

I checked the patch and it seems you forgot the changes in pci.c/pci.h, these are necessary in ati.c.

 

Thanks!

 

Whoops :D I will take a look at that tonight - Thanks!

Link to comment
Share on other sites

I have sent the diffs between the latest trunk and my branch to Kabyl under PM for his review. I'm not sure what the next step is after that.

 

Anyway, my source will be available as soon as possible, one way or another.

Your source code (changes) should have been made available from day – along with the product when it was released – and unconditionally. All conform the license.

 

So how many lines were changes? I ask this because your made your post days ago already, and a simple look at the source code, with help of diff / FileMerge (et all) is just a manner of minutes. Not days. I'd say go with github because it is taking too long.

 

This is also why I don't like the 'we' part in voodoo because I don't have a crystal ball. I am clearly not part of the voodoo magic inner circle, and thus I (and everybody else here) will have to wait for 'someone' to say magically yes (or no). That IMHO is wrong.

Link to comment
Share on other sites

{censored}in hell, that's exactly what i got on my setup.. i posted just page or 2 back and none cared...but when i left it for very long time(over 20min) it eventually went into gui. at least once it did. then it f* my whole setup, including snow leo. i had to go from scratch(i hate time machine...)

 

Replacing both IntelCPUPowerManagement.kext along with IntelCPUPowerManagementClient.kext version 156.0.0 from DP2 Update 2 11e444d with the corresponding kexts version 155.0.0 from the preceding DP2 (11a430e) allowed me to successfully boot and run the DP2 11A444d post the 11a430e update.

 

It is also worth noting that I updated the 11a430e to 11a444d from the Snow Leopard partition via the LionSWUpdate.pkg rather than the automatic Software Update.

Link to comment
Share on other sites

 Share

×
×
  • Create New...