Good news, the boot1 error for the E520/XPS410/Dimension 9200 has been solved! A little over a week ago a user called rivig successfully diagnosed and provided a solution for the problem on the VoodooLabs Forums. User rals2007 indicates that other computers may be affected by this problem as well.
If I'm understanding it correctly, the problem stems from an incorrectly coded BIOS that does not accept negative offsets. Without correct offsets, the bootloader cannot load the data that is located on the HFS+/FAT partition and is stuck with just the MBR stage. This was not a problem prior to Chameleon RCx because it did not need to load "external" data such as a GUI. However, rivig came up with a solution that should be universal. Zef acknowledged the patch and said that it will be incorporated into the next version of Chameleon, in all areas that pertain to linear address mapping (eg. CDBoot).
Fortunately, all that most of us need at the moment is a patched boot1h. Sgerber has provided a compiled version at the XPS410 thread on insanelymac. Since all release candidates of Chameleon, and all PC EFI V10.x, use the same boot1h, this patch should be applicable for all GUI-capable, Chameleon-based bootloaders. I can verify that it works, as the computer I'm posting this from is my E520 rebooted in AHCI without a USB drive. I'm just glad that it wasn't in disk.c or sys.c; makes me feel a little more competent!
Enjoy!
theStevo
Saturday, October 17, 2009
Monday, October 12, 2009
News, Discoveries, and Comments
So, I get my Latitude D830 to a place I'm really happy with and this inspires me to dive into my E520's DSDT. Well, unfortunately, it is not nearly as happy a place as the D830's DSDT. The E520/XPS410's DSDT is a pathetic showing that really disappoints me. Anyway, running into that broke my momentum of looking into hack stuff and brought me back to things in the real world. However, there are some things I would like to share.
Netkas announced some great news on October 8th! The 10.6.2 beta contains 64bit drivers for Intel's IGPs, which means the X3000 and X3500 should have 64bit support soon. Now, I have not seen the driver yet which means that I can't make any guarantees. The relationship with the framebuffer is finicky enough that it may cause problems. I got the 32bit framebuffer to work, but you can't mix and match. It will be all or nothing. I'm in no rush to make a 64bit version for a couple reasons. One, I hear that the beta drivers are rather buggy. Two, I use a discrete card for normal operation.
Another thing I want to mention on this topic came to me when I was reading recent comments to a previous post. I've said this on various forums, but not yet on my blog and it is a good thing to discuss. I am not aware of any way in which the X4500(M)(HD) chipset could even theoretically work with X3100 drivers. Yes, I'm aware that people have got the X3100 framebuffer to work... but that is entirely different. Early on, I looked into getting the X4500 to work with the X3100 and I worked with others on the IRC who were attempting the same thing. I'd like to see it working. However, it soon became apparent that the architectures are just too different. Just reading the wikipedia article about GMA will explain that. However, there is another logical argument why it won't work. Apple doesn't have a history of packing multiple architectures into the same kext like Intel (Windows) does with the same driver package. You have GMA915/950 kexts (essentially the same architecture), GMA965, but nothing about X4500 anywhere. If X4500 functionality was added to X3100 kexts it would be completely uncharacteristic of Apple. The only hope for X4500 drivers, which basically isn't even a chance in hell, is for the nVidia/Intel lawsuit to force Apple into switching back to GMA. But, even if that did happen Apple would want a new IGP instead of the X4500. They already showed that it is a gutless wonder, even Steve would have a hard time selling that switch.
Ok, I'll admit it, Viki's legacy kext for STAC9205 on the D830 spoiled me. I like the idea of full functionality using Apple's own drivers. However, I've had a devil of a time trying to get STAC9227 to work the same way. I started by reading THe KiNG's guide and then solidified my understanding of those principals by reading Master Chief's guide, basically saying the same thing differently. The catch is that neither of them really go into pathmaps or layouts. I'm pretty confident I figured it out and created a correct pathmap and layout, but it isn't working. The reason why I think I created a valid pathmap and layout is because if I use otherwise working ones in the same kext I get the same errors. My guess is that the problem has to do with codec support, and therefore hex editing. I have no problem with that, but it isn't very "legacy." MacGirl created some legacy kexts for the 9228, which isn't a native codec either, but I can't seem to get the same type of modifications to work for the 9227. The odd thing? STAC9205 isn't natively supported either, yet it works without hex editing. I don't know, if somebody smarter than I could explain that to me I'm probably a few minutes away from providing a nice legacy kext for the E520/XPS410 - and I wasn't able to find one currently available.
I was hoping to have the legacy kext ready for a move to Snow Leopard, but being I wasn't able to figure it out I looked into VoodooHDA instead. I've used it before, but I thought that the project was largely stagnate these days. Not true. The famed Slice has adopted the project and made many recent developments. I have no complaints at the moment, though I'm not viewing it as a permanent solution yet. Many people are posting much higher functionality with this newer version. Some may already have been aware of this, but since I didn't know I thought I'd pass it along.
Also, a later post will outline my instructions for creating pathmaps and layouts. It may not be perfect, but I'm confident my understanding is functional. Being that I wasn't able to find any comprehensive guide to that part of the AppleHDA patching process, think of it as an appendage to THe KiNG's or Master Chief's guides until they post their own.
Currently I've modded the DSDT to enable my graphics card, correct the USB issue, show all devices, enable custom P-States, load vanilla AppleLPC, and load vanilla AHCI/ATA. However, I haven't been able to get C-States working... story of my life lately. For those of you that have the boot1h error, that is a problem with Chameleon. I talked to Kabyl about it and he said that it is likely a change introduced by RC1 in disk.c or sys.c. I compared the code of RC1-3 to 1.0.11 and I haven't been able to figure out where it is. I've sold applications I've written before, but that doesn't make me a professional coder :) I guess I'm just missing the change, I don't know. Maybe one of you is smarter than I and can figure it out. In the mean time I'm using an old 32MB flash drive I had laying around to boot Chameleon, and therefore launch OS X with the AHCI enabled.
Well, I think I've only got two things left to implement on this baby - then it will be as perfect if Apple made it themselves :) One would be C-States (see below). And the other would be shutdown/restart/hibernate. I'm curious as to whether graphics power management could have something to do with that, being that it happens once hardware acceleration is enabled, but I'm not sure that Apple's graphics power management kext applies to the 8 series GPUs (which the 140M is). Anyway, the thing is rockin'! It's Geekbench scores are higher than those of MacBook Pro's of comparable hardware!
Intel 965 Drivers
Netkas announced some great news on October 8th! The 10.6.2 beta contains 64bit drivers for Intel's IGPs, which means the X3000 and X3500 should have 64bit support soon. Now, I have not seen the driver yet which means that I can't make any guarantees. The relationship with the framebuffer is finicky enough that it may cause problems. I got the 32bit framebuffer to work, but you can't mix and match. It will be all or nothing. I'm in no rush to make a 64bit version for a couple reasons. One, I hear that the beta drivers are rather buggy. Two, I use a discrete card for normal operation.
Another thing I want to mention on this topic came to me when I was reading recent comments to a previous post. I've said this on various forums, but not yet on my blog and it is a good thing to discuss. I am not aware of any way in which the X4500(M)(HD) chipset could even theoretically work with X3100 drivers. Yes, I'm aware that people have got the X3100 framebuffer to work... but that is entirely different. Early on, I looked into getting the X4500 to work with the X3100 and I worked with others on the IRC who were attempting the same thing. I'd like to see it working. However, it soon became apparent that the architectures are just too different. Just reading the wikipedia article about GMA will explain that. However, there is another logical argument why it won't work. Apple doesn't have a history of packing multiple architectures into the same kext like Intel (Windows) does with the same driver package. You have GMA915/950 kexts (essentially the same architecture), GMA965, but nothing about X4500 anywhere. If X4500 functionality was added to X3100 kexts it would be completely uncharacteristic of Apple. The only hope for X4500 drivers, which basically isn't even a chance in hell, is for the nVidia/Intel lawsuit to force Apple into switching back to GMA. But, even if that did happen Apple would want a new IGP instead of the X4500. They already showed that it is a gutless wonder, even Steve would have a hard time selling that switch.
STAC9227 Audio
Ok, I'll admit it, Viki's legacy kext for STAC9205 on the D830 spoiled me. I like the idea of full functionality using Apple's own drivers. However, I've had a devil of a time trying to get STAC9227 to work the same way. I started by reading THe KiNG's guide and then solidified my understanding of those principals by reading Master Chief's guide, basically saying the same thing differently. The catch is that neither of them really go into pathmaps or layouts. I'm pretty confident I figured it out and created a correct pathmap and layout, but it isn't working. The reason why I think I created a valid pathmap and layout is because if I use otherwise working ones in the same kext I get the same errors. My guess is that the problem has to do with codec support, and therefore hex editing. I have no problem with that, but it isn't very "legacy." MacGirl created some legacy kexts for the 9228, which isn't a native codec either, but I can't seem to get the same type of modifications to work for the 9227. The odd thing? STAC9205 isn't natively supported either, yet it works without hex editing. I don't know, if somebody smarter than I could explain that to me I'm probably a few minutes away from providing a nice legacy kext for the E520/XPS410 - and I wasn't able to find one currently available.
I was hoping to have the legacy kext ready for a move to Snow Leopard, but being I wasn't able to figure it out I looked into VoodooHDA instead. I've used it before, but I thought that the project was largely stagnate these days. Not true. The famed Slice has adopted the project and made many recent developments. I have no complaints at the moment, though I'm not viewing it as a permanent solution yet. Many people are posting much higher functionality with this newer version. Some may already have been aware of this, but since I didn't know I thought I'd pass it along.
Also, a later post will outline my instructions for creating pathmaps and layouts. It may not be perfect, but I'm confident my understanding is functional. Being that I wasn't able to find any comprehensive guide to that part of the AppleHDA patching process, think of it as an appendage to THe KiNG's or Master Chief's guides until they post their own.
E520 Update
Currently I've modded the DSDT to enable my graphics card, correct the USB issue, show all devices, enable custom P-States, load vanilla AppleLPC, and load vanilla AHCI/ATA. However, I haven't been able to get C-States working... story of my life lately. For those of you that have the boot1h error, that is a problem with Chameleon. I talked to Kabyl about it and he said that it is likely a change introduced by RC1 in disk.c or sys.c. I compared the code of RC1-3 to 1.0.11 and I haven't been able to figure out where it is. I've sold applications I've written before, but that doesn't make me a professional coder :) I guess I'm just missing the change, I don't know. Maybe one of you is smarter than I and can figure it out. In the mean time I'm using an old 32MB flash drive I had laying around to boot Chameleon, and therefore launch OS X with the AHCI enabled.
D830 Update
Well, I think I've only got two things left to implement on this baby - then it will be as perfect if Apple made it themselves :) One would be C-States (see below). And the other would be shutdown/restart/hibernate. I'm curious as to whether graphics power management could have something to do with that, being that it happens once hardware acceleration is enabled, but I'm not sure that Apple's graphics power management kext applies to the 8 series GPUs (which the 140M is). Anyway, the thing is rockin'! It's Geekbench scores are higher than those of MacBook Pro's of comparable hardware!
Subscribe to:
Posts (Atom)
