Voodooprojects
Chameleon => Bug Reports => Topic started by: DooV on May 17, 2009, 01:15:20 PM
-
I'm not sure if it is really a bug yet, or simply it wasn't included in the latest release.
I'm trying to load a patched DSDT.aml from a Chameleon 2.0 RC1 cdboot in order to be able to boot my retail installation disk with absolutly no luck (lock up due to cpu aliases). Of course my patched DSDT.aml is already working on the same motherboard after doing the install process on a dsdt bug free motherboard, so my DSDT.aml is not the problem here.
I included the DSDT.aml in every posible location
cdboot root/
cdboot root/Extra
Preboot.dmg/
Preboot.dmg/Extra/
and I even tried to use
DSDT=rd(0,0)/Extra/DSDT.aml and
DSDT=rd(0,0)/DSDT.aml
Nothing worked at all. So far I have to use an old patched bios to be able to boot retail disks in this motherboard with Chameleon 2.0 RC1. If I use the newest one and the patched DSDT.aml simply all I got is a lock up.
-
Can you boot with verbose mode and press the Pause key right before the kernel starts? You will get some verbose output about patching the DSDT.
-
Too bad I have no longer the motherboard in which I had the issue (MSI Neo3-FR http://www.msi.com/index.php?func=proddesc&maincat_no=1&cat2_no=170&prod_no=1611 ).
DSDT loading worked fine with Chameleon 2 RC1 installed on the hard disk, except for MacOS X was detecting 6gb instead of the real 4gb the computer had. Surprisingly this problem didn't happen if I used the patched bios from http://www.osxcores.site50.net/ (which sadly.....I found after wasting hours trying to make dsdt loading work from cdboot)
So to sum up, if there is a problem with Chameleon 2 RC1 DSDT loading, it is located only in the cdboot code since, once installed on hard disk, DSDT loading worked just fine (except for the memory issue, which may be unrelated).
Thanks for showing interest in this "bug", I really hope someone else can confirm it and you find a solution. You are doing a great job guys.
Let me know if you need any additional info about the problem and excuse my english :P
p.s. I really hope you are also taking care of the firewire dma bug in Chameleon 2 rc1 :) , lots of musicians and video editors will be a lot happier if it's finally solved.
-
It works for me.
My DSDT.aml was extracted, patched and (de)compiled with Koalala's ACPIpatcher. I used XCode to hand-edit my LAN into the decompiled DSDT. My board has AMI BIOS.
I know some text editors will screw up the formatting in the DSDT table (Windows Notepad for example). It will probably still compile, but it won't work. Maybe that's what happened to you? I don't know what text formatting type it's supposed to be in.
/EDIT - here's more info (copied from a boot CD pdf guide) though I'm not sure if this is the same thing that happens when editing DSDT.
"UNIX and Mac OS X use the line feed (LF) character to mark the end of a line of text, Windows uses the carriage return (CR) character. Because .plist files must have linefeed characters at the end of every line to be readable by Mac OS X, editing these files with Windows tools can result in headaches."
The DSDT.aml works fine from my Chameleon boot CD, which I used to install retail.
I've since flashed my BIOS with a modified DSDT that only removes the CPU aliases, but before I did that the Chameleon boot CD was working fine as well.
-
It works for me.
My DSDT.aml was extracted, patched and (de)compiled with Koalala's ACPIpatcher. I used XCode to hand-edit my LAN into the decompiled DSDT. My board has AMI BIOS.
I know some text editors will screw up the formatting in the DSDT table (Windows Notepad for example). It will probably still compile, but it won't work. Maybe that's what happened to you? I don't know what text formatting type it's supposed to be in.
The DSDT.aml works fine from my Chameleon boot CD, which I used to install retail.
I've since flashed my BIOS with a modified DSDT that only removes the CPU aliases, but before I did that the Chameleon boot CD was working fine as well.
That's a quite interesting theory. But, the same DSDT.aml file worked when I loaded it from hard disk. Only using cdboot failed to load.
-
That's a quite interesting theory. But, the same DSDT.aml file worked when I loaded it from hard disk. Only using cdboot failed to load.
The boot and cdboot files are the same but a 2k long el-torito loader is injected at the beginning of boot, take a look at cdboot's Makefile:
cdboot: cdboot.s $(SYMROOT)/boot Makefile $(NASM)
$(NASM) cdboot.s -o $(SYMROOT)/cdboot
dd if=$(SYMROOT)/boot of=$(SYMROOT)/cdboot conv=sync bs=2k seek=1
Regarding the issue, i have a clue in case when swap your DVD to the retail. In this case the retail's Boot.plist will takes place with the default options (almost none), but specifing your dsdt file on the command line should still apply...
-
Too bad all my other motherboards have no problems with cpu aliases, so I can't continue testing. Anyway this guy happens to have a similar issue.
http://forum.voodooprojects.org/index.php/topic,54.0.html
So, maybe its not a isolated case.
-
I have exactly the same problem as reported.
The DSDT.aml gets loaded from hard-disk just fine, but NEVER from CDROM,
no matter where we place the DSDT file. :-\
Of course, this is a very needed feature to circumvent the BIOS flashing.
Thank you for the good work.
-
So, 3 different people having the same issue...this definetively starts to look like a real bug.
-
I guess I found a work around that ensures the DSDT.aml gets loaded.
It requires the OsX Install DVD to be cloned and the 'your-system-specific-DSDT.aml' file
to be copied to the root of the DVD.
Then it gets loaded alright! Not really what we want, but can be handy to un-stuck ...
Before, I needed to use an external VGA monitor to proceed with the OsX DVD installation.
Not anymore, Ufh!
Maybe, this hint can help somebody.
Cheers,
PS. The proof that it gets loaded is attached.
-
Great, as you said is not exactly what we were looking for (specially if we have to burn a dvd9 for each new motherboard which needs a patched dsdt), but it may be useful until this bug gets patched.
-
Thx guys!
Going to inspect this one, btw i don't see why it doesn't work from rd(0,0).
Be back with - hopefully positive - results.
-
Hi Zef,
We know you're quite a busy person, BUT it's been about ten days since last move.
We badly need an answer, please say something about this matter, or is it too complicated?
Thanks.
-
I like to point out that the 2.0 RC1 source code got released recently. That might enable others to look into this.
-
Thank You! The sources have allowed me to spot the bug.
The tiny change I've made to the file 'libsaio/dsdt_patcher.c' in
function 'int setupAcpi()' has fixed it.
What I do, is simply check for the presence 'DSDT.aml' file in Ramdisk rd(0,0)
as a last resort. And that did it.
For the more impatient (like me), the change is straightforward.
That's good news I gather. Thanks again.
Cheers
-
Thank You! The sources have allowed me to spot the bug.
Nice.
The tiny change I've made to the file 'libsaio/dsdt_patcher.c' in
function 'int setupAcpi()' has fixed it.
Would you please give the details of your fix somewhere, maybe here, maybe as a bug report in the Bugs sub-forum?
-
Hi again,
Here goes the tiny bit that worked for me.
//AniV: Note this NOT a valid file !!!!!
/* Setup ACPI. Replace DSDT if DSDT.aml is found */
int setupAcpi()
{
int fd, version;
void *new_dsdt;
const char *dsdt_filename;
char dirspec[512];
int len;
boolean_t drop_ssdt=NO;
//DBGDSDT ("Enter setupACPI\n");
//AniV: this will override the DSDT file name. Do not use a full-path-name (e.g. rd(0,0)\Extra\DSDT.aml),it won't work!
if (!getValueForKey("DSDT", &dsdt_filename, &len, &bootInfo->bootConfig))
dsdt_filename="DSDT.aml";
// Check booting partition
sprintf(dirspec,"/%s",dsdt_filename);
fd=open (dirspec,0);
if (fd<0)
{ // Check Extra on booting partition
sprintf(dirspec,"/Extra/%s",dsdt_filename);
fd=open (dirspec,0);
if (fd<0)
{ // Fall back to booter partition
sprintf(dirspec,"bt(0,0)/Extra/%s",dsdt_filename);
fd=open (dirspec,0);
//Aniv: Start ------------------> 18 June 09
//AniV: Have a last look in the ramdisk. Check only at the root, for simplicity!
if (fd < 0)
{
DBGDSDT ("Checking for DSDT replacement in ramdisk\n");
sprintf(dirspec,"rd(0,0)/%s",dsdt_filename);
fd=open (dirspec,0);
}
//Aniv: End <------------------
if (fd < 0)
{
verbose ("No DSDT replacement found. Leaving ACPI data as is\n");
return setupAcpiNoMod();
}
}
}
// continues untouched
//...........
//...........
}
Hope it helps someone out there.
In my opinion, this should be re-written by Zef's staff, etc.
Cheers,
And the lousy snapshot:
-
Great!!! You should contact Zef about it. :)
-
Instead adding another possible look-up for the specified file, we should just adjust the /%s formatting and the code around. This hardcoded leading slash prevents working the passed DSDT argument correctly for different devices like rd(0,0) since the code will always look on the selected volume.
Btw we would need a more generic function to pass path + filename arguments to search for a file on different locations, this function can be used in many situations (eg. loading plists).
-
Actually that's I meant by:
"In my opinion, this should be re-written by Zef's staff, etc."
But I didn't mean to be rude. I agree with you!
Cheers.
-
Ok, removed the leading slash, so device selectors - rd(0,0)/... - can be used when specifying the DSDT option.
-
Solved :)
-
Hi, I'm still a bit of a noob so I had a couple of questions to see if I've understood what I need to do.
Is it that I need to put my dsdt.aml on a ram disk and put that somehow on the boot CD? The dsdt.aml will then be loaded still when I switch to the Mac OS X DVD.
If so, are there instructions on how to make this ram disk and specify it to be loaded? I couldn't see any reading the help for chameleon.
Will this solution also work for a /extra/extensions folder? This would mean I can do away with boot123 for installation.
Thanks,
Donald
-
I posted a Chameleon 2.0 boot CD guide here a while back. Search..
-
Hi Gringo,
I believe I had read your posting - if there is a different one then I can't find it sorry. The posting tells how to make a bootable CD but doesn't talk about how to get extensions loaded from it before booting of the OS X DVD. My presumption is that a key similar to DSDT=rd(0,0)/Extra/DSDT.aml is required - hence my original posting.
BR,
Donald
-
You don't have to do anything special, just place your DSDT.aml in /extra on your boot CD.
Kernel extensions go in extra/extensions on the RAM disk image, preboot.dmg.
Chameleon Boot CD how-to and preboot.dmg can be found here:
http://forum.voodooprojects.org/index.php/topic,484.msg2131.html#msg2131
The how-to is still valid for Chameleon 2.0 RC5 rev xxx cdboot.