Chameleon v2.1 (Main Trunk)

[Slice]

@Azimutz

{ 0x100268C0,  "ATI Radeon 5670 Series", "Galago"},

The data from iMac11,2 21"

[downlord]

Yeah... i took a look around and i think there's hope for you

According to ATI dev id list, there are only 4 dev id's for your card's ASIC (chipset), M66:

{“ ATI MOBILITY FireGL V5250	 ,M66  ,71D4 “}
 {“ ATI MOBILITY RADEON X1700	 ,M66  ,71D5 “}
 {“ ATI MOBILITY RADEON X1700	 ,M66  ,71DE “} <--- on X1000
 {“ ATI MOBILITY RADEON X1700 XT  ,M66  ,71D6 “}

71DE is present on ATIRadeonX1000. I suspect Wormy is not the fb for your card?!.. that's for X1900, which uses dev id's

started by 72. Tell me something.. do you have a Leopard install?

I'll be back later... quite busy now to check anything...

 

Hi Azimutz, thank for investigations.

According tho this list X1700 M is driven by Wormy and in 10.5 it worked well.

That's why I'm using the 10.5 framebuffer in 10.6, in 32 bit mode.´

But since 10.6.7 something has changed. The old ATINDRV doesn't get loaded anymore, so I'm expecting

a big change in Lion.

 

I can make a leopard install. Tell me about your toughts. I'm curious about your findings.

[bcc9]

yep, I know, but in snow I'm forced to use the 10.5 framebuffer because

the 10.6 works differently and with EFI string injection I'm unable to

call the wormy driver (apart of having some issues with edid and blank screens at boot...)

That sounds crazy of you to try to use 10.5 ATI drivers with 10.6, why doesn't configuring AtiConfig=wormy work for you under 10.6?

For testing purposes, you can just specify it as a command line argument from the chameleon GUI.

[downlord]

That sounds crazy of you to try to use 10.5 ATI drivers with 10.6,

 

Yes, but it works, and til now it is the only way to get it work.

 

That sounds crazy of you to try to use 10.5 ATI drivers with 10.6, why doesn't configuring AtiConfig=wormy work for you under 10.6?

For testing purposes, you can just specify it as a command line argument from the chameleon GUI.

 

AFAIK Kabyls rewriting the code never included Wormy as FB, but this was my assumption till now.

I had a look at ati.c in the trunk and wormy isn't defined, neither X1700m -> RV535 (a cooler RV530), nor the X1600m, wich is the one compatible with my v5250. (uff, ati's naming strategies make me want to buy only geforces LOL)

[bcc9]

AFAIK Kabyls rewriting the code never included Wormy as FB, but this was my assumption till now.

I had a look at ati.c in the trunk and wormy isn't defined, neither X1700m -> RV535 (a cooler RV530), nor the X1600m, wich is the one compatible with my v5250. (uff, ati's naming strategies make me want to buy only geforces LOL)

Ah, I didn't realize ati.c was missing a personality name. In any case, you could inject the ATI strings yourself (I'd recommend via dsdt), and test the results with current driver code. Seems like a required step before anything is added to the trunk.

Naming conventions aside, the OSX ati code is a lot easier to work with (mod) than the nvidia code.

[Bungo]

Hi Azimutz,

Hi bungo... do you really mean AutoResolution?... or you're talking about the Resolution module recently added to the trunk?

If you're talking about AutoResolution patch, it doesn't work with the chipset on your signature; only works with Intel 800/900 series.

On the other hand, if you're talking about the Resolution module, it does read the resolution from EDID but it's not being passed to the GUI atm.

Anyway, if Graphics Mode does the job, you can thank your graphics card vendor for fitting the VBIOS with a table with your native resolution many of us don't have that luck.

Thank's for explanation, ofcourse i meant AutoResolution patch.

 

Why do you want to override the hardware uuid? On the picture, the uuid on bdmesg should be the real hardware uuid of your machine; check bdmesg near the end for this line "Customizing SystemID with :..." and see if it's the same. That uuid is added to ioreg "IODeviceTree:/efi/platform/system-id" in it's real format and "IOService:/IOPlatformUUID" on a converted format for use on System Profiler (Hardware -> Hardware UUID).

I want to get my machine as closer to MBP6,1 as possible, i use UUID from real MBP6,1' SMBIOS but don't get the same info in System Profiler as MBP6,1'. XPC 0.85.05 gives correct value.

About SMmembankloc and SMmemdevloc, at least the modules info seems correct; did you tried checking that on Windows with Everest or similar tool? If not, do it and if it doesn't match, get an ioreg dump and file an issue at:

http://forge.voodooprojects.org/p/chameleon/issues/

I had the feeling those were disabled on the old code... not sure...

 

Cheers...

Mem info is correct but smbios.plist overriding doesn't work for memory modules

[Azimutz]

@Azimutz

{ 0x100268C0,  "ATI Radeon 5670 Series", "Galago"},

The data from iMac11,2 21"

Thanks Slice... just saw your post on ProjectOSX

I'll add it to ati.c when i get back to it, if useful; need to study this stuff better, to understand the logic...

 

Hi Azimutz, thank for investigations.

According tho this list X1700 M is driven by Wormy and in 10.5 it worked well.

That's why I'm using the 10.5 framebuffer in 10.6, in 32 bit mode.´

But since 10.6.7 something has changed. The old ATINDRV doesn't get loaded anymore, so I'm expecting

a big change in Lion.

 

I can make a leopard install. Tell me about your toughts. I'm curious about your findings.

Hi Downlord... Back for a while...

Well, Wormy or not, the main problem is that your card (like mine) was moved by AMD to legacy support

a good while ago; after that, we enter HD "age" and that's the GE code target, since Netkas put it together.

He never really added "legacy" support (and Kabyl killed it for good in his revision)! This "supposed" GE legacy support

is a courtesy of Snow Leopard and this line in the code; that simply sets Megalodon as the framebuffer to any unknown dev id.

Here i go... long writing... there's no easy way to explain this stuff

As you know, Snow ATI support is very different from Leo, specialy when it comes to framebuffers; Leo has no Controller kexts

and the framebuffers are individually stored on ATINDRV.kext and ATIRNDRV.kext; on Snow besides the new Controller kexts,

framebuffers were merged on a single ATIFramebuffer.kext; as with many things, this brought disadvantages (the easiest way

i found to inject Caretta was gone) and advantages, for this matter, the GE "legacy" support.

As i mentioned above, Megalodon is (on the old code) the default fb for unknown cards; what happens is that e.g. my rv516

works with Megalodon; in fact, after testing this stuff on 10.6.0, i got to the conclusion that my card worked whit most of the

legacy fb's common to Leo, being Wormy the only exception i can remember atm.

As bcc9 can explain much better than me, this is very dependent on the card's connector layout; my ATI (scroll down a bit)

has 2 DVI connectors (one of them dual-link) and a s-video TV out (which is not relevant for this matter); adding to this,

there's the fact that the dual-link DVI is the first connector, making it compatible with many fb's layouts.

So, this is the possible explanation for the so called ATI legacy GE support.

The big pain in the rear is that, adding the dev id of the card to the code and link it to Caretta (in my case) is not enough

and leads to kp. I need to clean up the code of HD stuff, play with the devProps to figure out what's needed or not, to get

to a conclusion (i hope). That's one of the reasons why i'm keeping the ATI on the machine for now...

 

Just a word on this framebuffer stuff on Lion; fb's personalities are being merged into the Controller kexts.

So, in a way, it's a return to Leo; me hopes it's a positive move for us (osx86)..!?.. we'll see...

 

Now, about my thought's; bcc9 already touched them

Using Leo's drivers on Snow is a bit crazy, though it works (worked, as you mention) but you are missing many

improvements apple did since 10.6.0. Also, DSDT would be the best way to test this stuff, that is, if someone

knows a DSDT patch that works in Snow!? The one i was using, stopped working around 10.6.3/4 and i still

didn't had the patience to check what's missing in it; i hope to find out while testing the old ati.c code;

some devProp injected by Chameleon is missing, i just need to figure what it is.

This is the reason why i asked you about a Leo install; the DSDT patch works fine there and you can test and inject the

correct fb with it (as bcc9 also pointed out). But, since you don't have a Leo install, we'll leave that for later (if needed)

and this is my plan for now:

 

- clean up Snow from all ATI Leo stuff and restore original kexts; use Pacifist and the 10.6.7 combo for the job;

open the pkg on the app, expand Contents of manual, expand first Contents of SUBaseSystemCombo..., navigate to

System folder, etc... and install kexts; next do the same with Contents of MacOSXUpdCombo...; if you don't do this,

you risk getting incomplete kexts!

- bin patch ATIRadeonX1000 and replace the dev id on info.plist; logic tells me to use the closest dev id for your

chipset and that's 71DE so i would try that first (find hex DE71 and replace by D471) but, you'll later need to

add/replace your dev id to one of the controllers (1900 or 1600) so, use common sense;

- install kext to S/L/E or use it in E/E.mkext; if you opt for Extra, do use mkext and add dependencies:

ATIFramebuffer.kext, ATISupport.kext, IOGraphicsFamily.kext and IONDRVSupport.kext (at least), If any is missing

you'll notice it on dmesg (or kernel log) while booting.

- use the booter from my branch; compile, replace boot file and add ATiGraphicsEnabler.dylib to Extra/modules.

GE is enabled by default so, just reboot and cross fingers... don't forget -v;

- if you get kp, try GraphicsEnabler=n or a rescue booter to get back to the system and try bin patch with another dev id;

Note: there are some bugs with the prompt; check issue 83.

- if boot is successful, check if ATIRadeonX1000.kext is loaded and if you have QE/CI; if so, all you need to figure out

is what's the Controller for your card, that's if it's not already loaded??! I need to replace 7187 by 7181 on 1300Controller,

but that's because the dev id is there; if you check the other controllers, that's not always (or never) the case.

Anyway, from my experience there's no need to bin patch the Controller so, just do the plist edit and place it were you

installed the patched RadeonX1000 (same dependencies) and reboot to try it.

 

This works for me; if it doesn't for you, then i recommend you do the Leo install to research this stuff.

On Leo, the simplest way i have of getting the card working, is with a simple Caretta's info.plist edit

(besides X1000 bin patch; that's mandatory).

I'm assuming you have knowledge for the procedure any doubt, give me a shout (pm)...

 

Going for a beer... or 5...

See ya later.

 

I want to get my machine as closer to MBP6,1 as possible, i use UUID from real MBP6,1' SMBIOS but don't get the same info in System Profiler as MBP6,1'. XPC 0.85.05 gives correct value.

Hi there...

Mate, i don't want to be rude but, that's a bit stupid, to say the least!! The hardware uuid is specific to any machine,

meaning that there aren't two machines with the same uuid (universally unique identifier) not even Mac's.

Same thing for any other uuid, not just hardware ones.

Non sense, mate there's absolutely no advantage in doing what you want...

 

Mem info is correct but smbios.plist overriding doesn't work for memory modules

yeah... bug. Check some posts back... don't tell me you're trying to match the Mac on that too!?

Edited June 11, 2011 by Azimutz

[Kabyl]

I am not using any underscores in my smbios.plist. I don't see any syntax change that you're referring to.

When I posted those 3 globs, it was because I was sure that they are what caused the regression. I know this because I checked out r861, tested it (result: failure), reverted those 3 globs, tested (result: success). The current mainline, r1000 also fails.

 

I haven't looked into what your change was for, but I suspect you really want these routines to return a tri-state not a simple true/false.

If I revert it, it will break it for others, so I left the code commented.

 

Could you upload an ioreg from each case?

[bcc9]

If I revert it, it will break it for others, so I left the code commented.

I tested the reverted version on my sandy bridge system and it worked fine (the auto-identified memory remained identified; the unused slots remained unused). I'm not sure what your original change was trying to fix so I hesitate to make a more specific recommendation...

Could you upload an ioreg from each case?

Not the whole thing, at least not publicly. Maybe you just want the applesmbios subtree?

I use system_profiler SPMemoryDataType as a quick&easy way to get just the memory info from the shell.

[Kabyl]

I tested the reverted version on my sandy bridge system and it worked fine (the auto-identified memory remained identified; the unused slots remained unused). I'm not sure what your original change was trying to fix so I hesitate to make a more specific recommendation...

OK, I think there is a better solution, I'll add a quick hack to check if UseMemDetect is true and return a default value, otherwise leave whatever is found in the original SMBMemoryDevice records, and hope non-Intel-based chipset users wouldn't complain about having no memory info.

[downlord]

Hi Downlord... Back for a while...

....

I'm assuming you have knowledge for the procedure any doubt, give me a shout (pm)...

 

Going for a beer... or 5...

See ya later.

 

What can I say. Respect.

The generosity of your answer blows me away.

 

Thank you very much for the detailed insight.

I have now to read carefully your suggestions, and study it.

I will try in Snow as you suggest and if no tangible results arise, I can make a Leo install on an external disk and

try the other way around.

 

And yes, I know the procedures . Will keep you updated, maybe somewhere else to avoid hijacking the thread.

 

I owe you two sardines

and some beers.

 

cheers

[Azimutz]

... I owe you two sardines

and some beers.

 

cheers

LoL, estou mesmo a ficar "distraído"

Se não tivesses falado em sardinhas ainda não tinha reparado

Desculpa lá, mano... saudações da Margem Sul para ti!

Pois, temos que tratar de combinar umas bjecas um desses dias!

 

Se tiveres alguma duvida sobre o procedimento manda pm, aqui ou em VoodooForums...

vai acabar por ser mais facil encontrar-me lá do que aqui... penso eu de que!?

 

Aperto de mão...

[bcc9]

OK, I think there is a better solution, I'll add a quick hack to check if UseMemDetect is true and return a default value, otherwise leave whatever is found in the original SMBMemoryDevice records, and hope non-Intel-based chipset users wouldn't complain about having no memory info.

Ok, I've actually looked into the code now.

To review, you made the memory manufacturer, serial#, part number return false.

In my smbios.plist I set:

SMmemspeed, SMmemtype, SMmemmanufacturer, SMmempart

Since I am not manually setting all the memory strings ( I left out the serial #), it winds up never set, and so the whole SPMemoryDataType lookup fails.

Before your change all the strings would be set, so SPMemoryDataType would succeed.

If I set SMmemserial as well as the above, then I've set all the memory strings manually, and so things work regardless of whether those routines return true or false.

 

I think simply letting these strings always be set was the right behavior. I still don't understand what case you fixed by changing it.

 

 

Also for the nvidia platform, chameleon could obtain the memory information automatically via DMI.

dmidecode under linux works on my nvidia system and obtains the memory manufacturer, speed, part #, serial #...

[Kabyl]

I think simply letting these strings always be set was the right behavior. I still don't understand what case you fixed by changing it.

The case where a user has a good SMBIOS, and wants to keep the original data.

 

And if you check the change log you'll see that I was going back and forth between the two, and finally decided on the previous change.

 

But now, I think we have a better way (check the last commit).

 

Also for the nvidia platform, chameleon could obtain the memory information automatically via DMI.

That's exactly what the return false does, but sometimes SMBIOS is buggy.

[bcc9]

The case where a user has a good SMBIOS, and wants to keep the original data.

As I said, I tested this and the code worked fine on my sandy bridge desktop with the routines returning true... (the auto-generated information is kept).

[Bansaku]

Heyas good folk! I have been steadily testing out each new update and all in all things gave been working great. However, since at least v2 RC5 1000, and the same for 1003, sleep has been doing funky things to both SL and Lion. Since I updated from to 1000, in SL when I wake from sleep my internet no longer works; network reports active but cannot reconnect to my ISP 1003 fixed problem. In Lion (DP4), an old friend returns: BIOS reset!

Admittedly, I have not tried out sleep for either since 974, where it was working fine. Nothing has been changed by me system wise. I have simply been updating Chameleon. Have there been any changes that would affect wake?

 

Note: I already am aware of the CMOS reset problems some have experienced. I have posted here in regards to this issue.

[Gringo Vermelho]

since at least v2 RC5 1000, and the same for 1002, sleep has been doing funky things to both SL and Lion. Since I updated from to 1000, in SL when I wake from sleep my internet no longer works; network reports active but cannot reconnect to my ISP.

Just pulled r1003 from svn and installed it, S3 sleep still works fine for me.

 

Retail 10.6.7

 

P45/ICH10

Core 2 Duo

GTX 460

Marvell 88E8056 LAN

AD2000B sound

[bcc9]

I just found a bug in setSMBValue().

The code that parses bytes/words/dwords is always returning a 4 byte quantity, thus clobbering data if it should only be parsing a byte or word.

So for example, If I set SMmemtype in my smbios.plist, then my memory speed is corrupted. If I set my SMmemspeed, then my SMmemmanufacturer is corrupted.

 

This is part of why I had thought the auto-detection code didn't handle nvidia chipset

[Bansaku]

Just pulled r1003 from svn and installed it, S3 sleep still works fine for me.

 

Retail 10.6.7

 

P45/ICH10

Core 2 Duo

GTX 460

Marvell 88E8056 LAN

AD2000B sound

 

 

 

I miss-typed, and corrected myself. It was 1003 I installed, today.

[Kabyl]

As I said, I tested this and the code worked fine on my sandy bridge desktop with the routines returning true... (the auto-generated information is kept).

I got that, I will clarify the what the code does a bit more though:

- first we check for smbios.plist key/value pairs, if the specific key isn't found (false),

- call the getters functions, if that returns false (value not set),

- use the default value, if that's not set (false),

- use the original data from the BIOS whatever that data is, it could be buggy, which is the case for your SMBMemoryDeviceSerialNumber.

 

Now, since our SMBMemoryDevice* getters for the string fields always return a value, the original data from the BIOS is never used, and this is an option some users might want to use.

 

What I did in the last commit is remove this option for Intel-chipset users (always return a value (true)) because in most cases we can read the SPD and RAM controller info.

 

 

 

I just found a bug in setSMBValue().

The code that parses bytes/words/dwords is always returning a 4 byte quantity, thus clobbering data if it should only be parsing a byte or word.

So for example, If I set SMmemtype in my smbios.plist, then my memory speed is corrupted. If I set my SMmemspeed, then my SMmemmanufacturer is corrupted.

 

This is part of why I had thought the auto-detection code didn't handle nvidia chipset

That's very possible, probably the reason why it worked in my tests is the order in which the fields are set. I shouldn't have trusted that.

 

I'll have to do more tests and fix this later.

[bcc9]

I just found a bug in setSMBValue().

The code that parses bytes/words/dwords is always returning a 4 byte quantity, thus clobbering data if it should only be parsing a byte or word.

So for example, If I set SMmemtype in my smbios.plist, then my memory speed is corrupted. If I set my SMmemspeed, then my SMmemmanufacturer is corrupted.

 

This is part of why I had thought the auto-detection code didn't handle nvidia chipset

Here's a fix.

With this fix, I can finally get all but the memory type auto-parsed on my nvidia chipset system. (The memory type is misclassified as 'reserved' by my machine's bios so I have to set it via SMmemtype in smbios.plist.)

patch_smbios_parse.txt

[bcc9]

I got that, I will clarify the what the code does a bit more though:

- first we check for smbios.plist key/value pairs, if the specific key isn't found (false),

- call the getters functions, if that returns false (value not set),

- use the default value, if that's not set (false),

- use the original data from the BIOS whatever that data is, it could be buggy, which is the case for your SMBMemoryDeviceSerialNumber.

Got it now, I didn't realize there was a distinction being made between the getters routines and the original bios data.

 

My BIOS's SMBMemoryDeviceSerialNumber is actually fine, it's just that it was being clobbered by that setSMBValue() bug I fixed. With the fix, the serial numbers are OK and all is fine.

[Bungo]

Azimutz thank's once more for your explanation and patience. I found these bugs (IMHO) and wanted to report it, that's all nothing more.

 

Hi there...

Mate, i don't want to be rude but, that's a bit stupid, to say the least!! The hardware uuid is specific to any machine,

meaning that there aren't two machines with the same uuid (universally unique identifier) not even Mac's.

Same thing for any other uuid, not just hardware ones.

Non sense, mate there's absolutely no advantage in doing what you want...

I know, i know but what is SystemID feature in Boot.plist for? May be i try to use it in wrong way or it doesn't work?

 

yeah... bug. Check some posts back... don't tell me you're trying to match the Mac on that too!?

Why not? Anyways would be nice to have it working.

 

BTW. If i use UseMemDetect=No get correct info in SysProf but if UseMemDetect=Yes get different mem speeds on identical modules (tested with two different pairs of modules in all combinations)

 

I need help to get rid of error in SysProf-Diagnostics section

After some investigation and studying the SMBIOS Reference Specification, I've an idea to override coresponding SMBIOS (table handle: 0x002B, type: 17 ) Error Information Handle field with 0xFF value (no error), now is 0x002D (dmidecode.txt).

Some people reported this issue. May be adding a patch fix this up: if field1 <> 0xFF check field2 then if field2 = OK then field1:= 0xFF (field1=Error Information Handle, field2=Type)

[Kabyl]

Here's a fix.

With this fix, I can finally get all but the memory type auto-parsed on my nvidia chipset system. (The memory type is misclassified as 'reserved' by my machine's bios so I have to set it via SMmemtype in smbios.plist.)

Thanks for the patch! applied with a few changes (r1004).

[digital_dreamer]

Anyone having trouble entering flags in the non-GUI version of RC5 when booting Lion (installer)?

When I attempt to enter "-f", I never get any farther than the "-" (hyphen). Everything appears to lock up, although the cursor still blinks. The cursor moves to the second character position, but the "f" (or any other character) never gets output. A hard reset is the only solution. Interestingly, it takes several seconds before anything happens after the reset.

 

I noticed this with r1002.

Went back to r972, then r877 (I think). Still no luck.

Went all the way back to r752 and was able to enter more than one character. Worked fine with that revision.

 

This is trying to boot a USB disk, partitioned as MBR. System is in signature.

 

kind regards,

MAJ