Chameleon RC4 is out!

[rekursor]

Still get this with pre11e:

 

Memory allocation error! Addr=0x0, Size=0x10, File=string.c, Line=246.

This is a non recoverable error! System HALTED!!!

 

Is not the same error as DB1 had

EDIT: sorry, something has been done for that one but it is not enough apparently...

 

 

With this I get both slots detected, but serial is incorrect (Serial Number: e&Q[). Previous version was working fine. Also, the boot loader has gotten very slow since memory detection was introduced. I get a blinking cursor that lasts for a few seconds before the white boot screen.

Interesting; because I have now permitted the ascii serial code to be translated as ascii following the ddr2 ddr3 spd definitions recommendations.

I will revert that, thanks.

 

This can be caused by 'strdup' in these lines:

			slot->PartNo = strdup(getDDRPartNum(slot->spd) );
		slot->Vendor = strdup(getVendorName(slot) );
		slot->SerialNo = strdup(getDDRSerial(slot->spd));

 

@Rek,

 

Would you mind using something like: if (spd[2] == MEM_TYPE_DDR3) instead of: if (spd[2]==0x0b) // DDR3

Saving you the comments and my old head a headache reading it. Thanks.

No, unfortunately the problem was anterior to this 11e code.

Also There are the SPD memory types and the smbios memory types which differ,

this is why I preferred to 'see' the value I was handling to avoid ambiguity, but the right thing to do would be to declare SMB_MEM_TYPE_XXX AND SPD_MEM_TYPE_XXX I suppose and they exists already so no excuse

[zef]

@rekursor:

 

I get an instant reboot with trunk/r103 on my desktop P5K-E board (P35 + ICH9R chipset). We had similar issues when testing iNDi's SPD stuff. Somehow he managed to fix that.

[rachaf]

sorry my mistake

04004028==)675282948

[rekursor]

@rekursor:

 

I get an instant reboot with trunk/r103 on my desktop P5K-E board (P35 + ICH9R chipset). We had similar issues when testing iNDi's SPD stuff. Somehow he managed to fix that.

Well I now understand why he got crazy with the spd stuff ...

[Master Chief]

...

No, unfortunately the problem was anterior to this 11e code.

I see you changed MAX_RAM_SLOTS from 12 into 8 but isn't there a better way to it? I mean can't you use say the CPU (what was it type or if? I'm too tired right now to think properly) to determine the maximum number of slots (roughly) which might be something like:

 

2 = mobile (by checking Platform.CPU.Mobile maybe?)

4 = dual channel

6 = triple channel

 

Also There are the SPD memory types and the smbios memory types which differ, this is why I preferred to 'see' the value I was handling to avoid ambiguity, but the right thing to do would be to declare SMB_MEM_TYPE_XXX AND SPD_MEM_TYPE_XXX I suppose and they exists already so no excuse

Yeah I did it from the top of my head. A much better read like this. Thanks!

[rekursor]

I see you changed MAX_RAM_SLOTS from 12 into 8 but isn't there a better way to it? I mean can't you use say the CPU (what was it type or if? I'm too tired right now to think properly) to determine the maximum number of slots (roughly) which might be something like:

 

2 = mobile (by checking Platform.CPU.Mobile maybe?)

4 = dual channel

6 = triple channel

 

 

Yeah I did it from the top of my head. A much better read like this. Thanks!

IMHO, The better way to do it would be to implement block read for the i2c as for now we only read the content byte per byte with a wait for dada ready delay than can go from 1 to 10 ms, this why it slows down the booter so much.

I did limit the number of slot because it was damn slow but this is not in the mid term what we should do.

I believe that we should:

- Reuse and adapt linux code like i2c/smbus code (some people worked among years to develop what I did for fun in few evenings, but the point is that they had the time to do it much better...)

- Add the GPL headers that would make those guys stay in harmony with us.

Now I believe I understood why asere did not release his work for dyn. mem detection:

it is probably simply because it contains gpl code.

 

But now the question is :

Who cares today about not being able to provide commercial solutions around chameleon ?

I certainly wouldn't.

 

I think I could reuse a lot of GPL code that does much more than what I did, like determining the real freq of ram by reading directly via the pci bus the relevant information.

 

The code was already there, but was never released because of gpl issues.

 

I would vote for incorporating the GPL code and of course keep the GPL license and headers,

then include in our README that some parts of the code comply to GPL, more restrictive than APSL.

[bs0d]

GPL licence is incompatible with APSL licence afaik

 

But licences arent my field better to wait for a more knowledgable person.

 

Time boot132 booters based were replaced anyway.

[rekursor]

Well, I don't see any problem to incorporate 'third party' software provided that you include adequate notice and license info. with it here's an extract of the APSL license:

" 2.4 Third Party Rights. You expressly acknowledge and agree that although Apple and each Contributor grants the licenses to their respective portions of the Covered Code set forth herein, no assurances are provided by Apple or any Contributor that the Covered Code does not infringe the patent or other intellectual property rights of any other entity. Apple and each Contributor disclaim any liability to You for claims brought by any other entity based on infringement of intellectual property rights or otherwise. As a condition to exercising the rights and licenses granted hereunder, You hereby assume sole responsibility to secure any other intellectual property rights needed, if any. For example, if a third party patent license is required to allow You to distribute the Covered Code, it is Your responsibility to acquire that license before distributing the Covered Code. "

 

In short it tells that you assume the responsibility to include other 3rd party material,

so it also shows that apsl does not forbid incorporation of 3rd party material.

 

Now on the GPL side, I saw many users of lgpl (less restrictive than gpl as apsl) libraries that also use GPL code, incorporate legal notices and license files and clearly stating that parts of the code are GPL licensed.

In the latter case, the most restrictive license apply and it also means you can't use anymore your software for commercial issues, which is not a problem I think for our public work.

 

This GPL paragraph seems to reinforce this:

"13. Use with the GNU Affero General Public License.

Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such."

 

My 2 cents

 

GPL licence is incompatible with APSL licence afaik

 

But licences arent my field better to wait for a more knowledgable person.

 

Time boot132 booters based were replaced anyway.

[Master Chief]

IMHO, The better way to do it would be to implement block read for the i2c as for now we only read the content byte per byte with a wait for dada ready delay than can go from 1 to 10 ms, this why it slows down the booter so much.

Or... you don't add this feature to boot2 but the pref panel? Making it smaller, faster be it a tad less user friendly. And IMHO it is just a matter of time before [more] people start complaining about the slow boot process – first they want it to work and then they want it to become faster.

 

I did limit the number of slot because it was damn slow but this is not in the mid term what we should do.

Pretty obvious.

 

I believe that we should:

- Reuse and adapt linux code like i2c/smbus code (some people worked among years to develop what I did for fun in few evenings, but the point is that they had the time to do it much better...)

I wonder what the performance hit and code size would be. And one thing is crystal clear to me; it cannot win from a one-time-only-initialization procedure – which I envision – where this kind of things is ran only once, and stored in say system.plist

 

- Add the GPL headers that would make those guys stay in harmony with us. Now I believe I understood why asere did not release his work for dyn. mem detection:

it is probably simply because it contains gpl code.

I think that I have been pretty clear about the APSL and third party additions in the past, but I was banned for addressing this issue properly, and thus I have to pass.

 

But now the question is :

Who cares today about not being able to provide commercial solutions around chameleon ?

I certainly wouldn't.

No problem for me.

 

I think I could reuse a lot of GPL code that does much more than what I did, like determining the real freq of ram by reading directly via the pci bus the relevant information.

I still don't get it why people would want to do this every single boot. Getting the info once should be enough. Storing this info is what you need [enter write problems from boot2].

 

 

...

I would vote for incorporating the GPL code and of course keep the GPL license and headers, then include in our README that some parts of the code comply to GPL, more restrictive than APSL.

I disagree. Not to mention that porting such solutions to your own 'pref' panel would be much easier [in terms of licensing].

[rekursor]

Or... you don't add this feature to boot2 but the pref panel? Making it smaller, faster be it a tad less user friendly. And IMHO it is just a matter of time before [more] people start complaining about the slow boot process – first they want it to work and then they want it to become faster.

...

I disagree. Not to mention that porting such solutions to your own 'pref' panel would be much easier [in terms of licensing].

AFAIK The pref panel code is not called at startup, it is only called after it is selected in the sys pref.

There are also other reasons why it does not have its place here, like all kexts would be ran _before_ the pref panel code, which btw runs in user privilege mode, so it would probably also need a kext to access the smbios and other data anyway.

 

Then I don't see how we could run 'only once' the patching process as the new smbios tables and ioregs have to be patched at every boot, AFAIK it is not persistent ?

 

I agree that the boot time is hardly acceptable and believe me, for making the delay unnoticeable for the user, we need to know how to read i2c blocks (256 bytes for each present slot detection).

So I propose to change the default of the new option I added (UseMemDetect) so that it is not activated by default, until we get more mature code.

 

Finally, I don't understand why you would not agree to add GPL info and headers where it is necessary (only few files), if we use GPL'ed code ?

Why would it be such a big deal ?

 

EDIT: I switched off by default the mem. autodetection (UseMemDetect=n), I have not enough time to continue this week.

[THe KiNG]

@ rekursor 100% agree with you.

IMHO we need options for disable default enabled functions, like DSDT load, now if no DSDT is found all rest ACPI fixes are doomed.

Same should go for the rest, e.g. SMBIOS and so...

I need this b/c I try to fix most of them in BIOS(what can be done) and for sure I'm not the only one...

[Master Chief]

AFAIK The pref panel code is not called at startup, it is only called after it is selected in the sys pref.

Of course. We don't want to run the pref panel code at startup.

 

There are also other reasons why it does not have its place here, like all kexts would be ran _before_ the pref panel code, which btw runs in user privilege mode, so it would probably also need a kext to access the smbios and other data anyway.

We're talking about two different things. I'll explain this shortly.

 

Then I don't see how we could run 'only once' the patching process as the new smbios tables and ioregs have to be patched at every boot, AFAIK it is not persistent ?

I was talking about collecting and storing static data. Let's start with a few very obvious candidates:

 

getAddressOfAcpiTable()

getAddressOfAcpi20Table()

getAddressOfSmbiosTable()

 

These won't change and could easily be collected and stored from your pref panel or init-application. Ditto for the SMBIOS table, including the latest RAM patches, because loading patched data is much faster than going over it every single boot.

 

I agree that the boot time is hardly acceptable and believe me, for making the delay unnoticeable for the user, we need to know how to read i2c blocks (256 bytes for each present slot detection). So I propose to change the default of the new option I added (UseMemDetect) so that it is not activated by default, until we get more mature code.

I agree with the latter.

 

Finally, I don't understand why you would not agree to add GPL info and headers where it is necessary (only few files), if we use GPL'ed code ? Why would it be such a big deal ?

You read me wrong. It isn't. I'm not opposed to adding GPL code, but I keep wondering if and when it is time to start working on a data collector storage. I mean you won't even have to add GPL code when you keep your code, simply because speed is no longer an issue anymore since it is run only once.

 

Using a data collector storage would also take care of the ATI / NVIDIA specific code, because why should people with ATI's have to load NVIDIA code and vise versa? I mean all you need is the device properties so... making the booter smaller and faster again.

[THe KiNG]

We need to have a bigger picture than that^^

Since when Chameleon is only a Darwin bootloader?

[Master Chief]

We need to have a bigger picture than that^^

Since when Chameleon is only a Darwin bootloader?

This has absolutely nothing to do with being a Darwin bootloader. Nada.

 

And booting can be done in two seconds now, so you either stick with old and dated ideas or join people with new ideas.

[THe KiNG]

@MC you cant do what you want w/o NVRAM implementation and EFI runtime stuff...

I try to fix what is possible in BIOS, what is hard or require too much time to develop I pass to bootloader, same for notebook stuff where playing with BIOS is dangerous or hard to recover...

Think on that...then tell me about ideas...

[Master Chief]

@MC you cant do what you want w/o NVRAM implementation and EFI runtime stuff... I try to fix what is possible in BIOS, what is hard or require too much time to develop I pass to bootloader, same for notebook stuff where playing with BIOS is dangerous or hard to recover...

Think on that...then tell me about ideas...

I don't want people to do BIOS modifications simply because that can go badly wrong yes. And this is one of the reasons why the in BIOS version of Revolution is not available. Sure. We all here want [need even] a working Chameleon boot loader, but we shouldn't let it do useless repetitive actions when there is no need for it. Also. The end-user should never have to say goodbye to previously introduced features. At least not when they are still supported and work as advertised.

 

Lets take a simple example. The recent memory patches. Which is also static data [non essential]. At least until you add/remove or change modules. So tell me something; Why would you want your boot loader to search for it, and every single boot, when it could use readily available data after the first run? What if we collect and store this data in say system.plist and use that data for the second boot?

 

What would that give you? A Screaming Eagle!

[THe KiNG]

IMHO about memory stuff we have 2 options:

1. Use GPL-ed stuff like rekursor said(might be good for other stuff too) that is proved fast enough(Asere branch)

2. Use old good smbios.plist patch

 

Most of smbios stuff can be done in BIOS also, atm digging on how to add missing apple custom table and get BIOS to "eat" those w/o complain...but this is other discussion not related here/chameleon

Example (not working yet)here:

[dtessier]

Lets take a simple example. The recent memory patches. Which is also static data [non essential]. At least until you add/remove or change modules. So tell me something; Why would you want your boot loader to search for it, and every single boot, when it could use readily available data after the first run? What if we collect and store this data in say system.plist and use that data for the second boot?

 

Not trying to be antagonistic here, just an honest question. The data needs to be obtained on startup, either directly from SPD, or a "cached" version in a plist file. Is SPD/SMBus access really that much slower than reading and parsing the XML in the plist file? Or are you strictly worried about boot load size?

[Flashe]

Hi

 

since my last attempt I have not tried another boot file, if there is corresponding to my problem, let me know.

I conducted a test with this file rekursor :boot_report2.tar.gz

 

I post the result

 

 

I am french

[Smith@@™]

The last cham downloaded from svn don't work for me; i've try it on desktop and on msiu and on both they restarted in a infinite loop.

[zef]

The last cham downloaded from svn don't work for me; i've try it on desktop and on msiu and on both they restarted in a infinite loop.

 

Same here with r111. It loads the kexts fine, then the last output what I can read is the "Patched DMI table", then I get the instant reboot.

[rekursor]

Same here with r111. It loads the kexts fine, then the last output what I can read is the "Patched DMI table", then I get the instant reboot.

Did you restore the ram data in smbios.plist ?

because the only change in 111 is the boolean flag UseMemDetect set to false (no mem detect by default).

Please try r107 and tell me if it boots correctly for you.

Seems that disabling autodetection has a side effect ...

[zef]

Did you restore the ram data in smbios.plist ?

because the only change in 111 is the boolean flag UseMemDetect set to false (no mem detect by default).

Please try r107 and tell me if it boots correctly for you.

Seems that disabling autodetection has a side effect ...

 

I don't use any smbios.plist but sure, will try r107 and get back to you

[rekursor]

I don't use any smbios.plist but sure, will try r107 and get back to you

I made a r112 that worked great for me on 2 different machines, hope this works for you...

[blackosx]

r112 works great for me.

And the memory detection works now... Great job Rekursor