rosmaniac

Ah, yes, found the list, thanks. As i see the 4321 is listed with a ? for Mav I'll report back my results when I get the chance to do a Mav install on this M4300 with the DW1505/BCM4321.

Oh, I understand completely; just giving a bit of a heads-up, that's all. Anyway, enjoy the box and learn; there are a number of tools out there that can help you put a driver into place properly. The most important piece of the pie is getting the kextcaches built against an /Extra with the proper permissions on all files. I think at one point while I was doing the install on my 690 I used something called kext wizard that does most of the heavy lifting, but that has been a while (I did the 10.6 install on the 690 right at two years ago, and that's a long time in this scene; lots of changes since then). The Hackinstaller script is what I used at the time (none of the other tools at that time worked for me in my instance, since I was needing to install to SATA but use a PATA DVD to do the install). None of the tools, Nawcom's or TM's, or MyHack, worked for me in my particular situation at that time. You can find the Hackinstaller script at http://www.insanelymac.com/forum/topic/185097-guide-scripted-retail-mavericksmountain-lion-install-on-gigabyte-mobos/page-1 and that might help you get enough info for you to be able to help with the EDP model setup. But I've not used the latest version of that script, nor am I likely to do so. I personally would like to get EDP up on it, but I simply haven't had the time at the moment.

Is there a list somewhere of cards/chips that are supported under Mav? Got a BCM4321 here, (DW1505, I think) and it works great on ML, but haven't tried Mav yet.

Unifail? Oh, I get it. You'll need the matching Multifail package to mesh with that. As to installing the kext, you're a bit on your own there, since the EDP setup does all of the work like that automatically, thanks in no small part to myFix. With the /Extra setup that the Unifail installer placed, you really should use the matching Multifail post-install tool to work with. I personally would prefer to see the 490/690 supported directly with a bootpack and integration to EDP, and the posting that you did might help a bit with that.

For reference, there are two 'latest' BIOS's for M4300. If I go to dell.com and look for drivers and downloads for my specific service tag I see the latest BIOS as being A15; if I select for all M4300's I see A17 and A15 both available as the latest. I'm at A15; it appears A16 and A17 are mainly for signed BIOS updates, at least that's what the Dell info says. The easiest way to flash these if you don't have a Windows partition is made possible by using the OSX unetbootin package; use unetbootin to make a FreeDOS boot USB, then copy the BIOS update file(s) to that USB stick. You can then boot the USB, select no drivers and no install, and get the FreeDOS prompt. You can then execute the BIOS flasher there easily. (That's for reference, and for searches; Herve already knows how to do all this, I'm sure).

Ok, the /Extra from my boot USB made by Hackinstaller for the P690 Do note that this /Extra was made for 10.6.0 retail DVD; there are changes required to get it to work with a 10.6.3 retail DVD. But perhaps something here will help you out. There are further changes required to get it to work with 10.6.8; stepwide updating to 10.6.2, then to 10.6.3, then 10.6.7, and finally 10.6.8 was required, with minor adjustments to the /Extra each time. I'm not where the 690 that I have running is right at the moment, but this is the boot USB's /Extra that I originally used to do the install. extra-sl-p690-2.zip

Herve, I can, but I'm not sure how much it will help, since it's for Snow Leopard. It will take me a bit, since getting the /Extra from an AppleRAID system isn't quite as straightforward as a non AppleRAID system (hidden helper partitions). But now I'm intrigued about trying this myself; just need to get a couple of drives and pull the old 10.6.8 system drives out for testing.... rjjd, You'll need to get a video card that' supported by Mav first.

I see you have a T8400 CPU; that's .... hey, wait a minute, a T8400? There's a T8300 at 2.4 and a P8400 at 2.27..... Anyway, that's a Penryn, same family as the T9300 that I'm getting ready to put into my primary M4300, so that's good news. MBP5,1 profile, eh. Is this due to the Penryn? And, if it is, can a 'Penryn' enabled bootpack and EDP model for the D830/M4300 be set up that takes direct advantage of this?

The M65 is functionally equivalent to a D820, with the NVS120M (not the 110M). I just day before yesterday reinstalled Lion on my D820/M65 mutt, using the D820 nVidia bootpack for Lion from April 8th. Are you using the App Store downloaded .app?

Herve, Is there a good list somewhere that shows which cards? I'm thinking anything 8000-series and newer is probably at least somewhat supported, and I know there's a thread out there that lists by PCI ID and such, but I'm talking a human-readable list. I have an 8400GS in the 690 at home, running the nVidia drivers, not the native SL drivers (in order to get full resolution on my 1680x1050 monitor).

Herve, when you initially boot the USB stick it may black screen hang on you; I found that if you hard power cycle (hold down power for eight or more seconds) and then power back up you have about a 50% chance of the USB stick booting correctly the second time with no additional boot options. You'll find elsewhere in the forum to use PCIRoot=1 but I've found that even using that doesn't always allow the USB stick to boot correctly every time. I'm not sure why this is, but it's likely related to the nVidia graphics. I've seen that behavior both with and without being docked to the D/Dock with a second monitor attached (to the VGA port).

Here's the lspci output (from CentOS 6) on one of our 690's here: 00:00.0 Host bridge: Intel Corporation 5000X Chipset Memory Controller Hub (rev 12) 00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 2 (rev 12) 00:03.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 3 (rev 12) 00:04.0 PCI bridge: Intel Corporation 5000X Chipset PCI Express x16 Port 4-7 (rev 12) 00:05.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 5 (rev 12) 00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 6 (rev 12) 00:07.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 7 (rev 12) 00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 12) 00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 12) 00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 12) 00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev 12) 00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev 12) 00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev 12) 00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev 12) 00:1b.0 Audio device: Intel Corporation 631xESB/632xESB High Definition Audio Controller (rev 09) 00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 1 (rev 09) 00:1d.0 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 (rev 09) 00:1d.1 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 (rev 09) 00:1d.2 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3 (rev 09) 00:1d.3 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #4 (rev 09) 00:1d.7 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller (rev 09) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9) 00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller (rev 09) 00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE Controller (rev 09) 00:1f.2 SATA controller: Intel Corporation 631xESB/632xESB SATA AHCI Controller (rev 09) 00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller (rev 09) 01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port (rev 01) 01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X Bridge (rev 01) 02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E1 (rev 01) 02:01.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E2 (rev 01) 04:00.0 USB controller: VIA Technologies, Inc. Device 3432 (rev 02) 05:0b.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068 PCI-X Fusion-MPT SAS (rev 01) 07:00.0 VGA compatible controller: NVIDIA Corporation G92 [GeForce 8800 GTS 512] (rev a2) 0b:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5752 Gigabit Ethernet PCI Express (rev 02) 0c:0a.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22A IEEE-1394a-2000 Controller (PHY/Link) [iOHCI-Lynx] Devices 04:00.0 and 07:00.0 are addons: a USB 3.0 PCIe card, and the GeForce 8800GTS 512 video. The CPU type you have is also important. This one has two E5335's in it, for a total of 8 cores. The one I have at home has one E5345 2.33GHz quad core in it, running 10.6.8. However, the 690 (and the 490) support all the way back to the Dempsey dual-core NetBurst-based processors, which are older than the minimum Core architecture needed. However, Herve has a 670 with Irwindale Xeon's running; see his post on that subject. To get this info, you can boot a Linux boot CD/ boot USB; something like the CentOS liveCD or a Ubuntu CD or Knoppix or whatever. You need to get a command line shell, and issue three commands as root: lspci -v cat /proc/cpuinfo dmidecode Attach the output as a text file; the dmidecode output, in particular, is large. You may want to sanitize the service tag number and/or the serial number in the output of dmidecode. I can get a working DSDT for SL easily, since I have a running 690 on SL, but I have no idea whatsoever if that will work with Mav. I do, however, have another 690 available to test on..... The 490/690 is a bit long in the tooth; the current generation is the T7600, one gen removed is the T7500, two gens removed is the T7400, and the 490/690 is three generations older than current at this point in time. But it is still quite a powerful machine, particularly loaded with 16GB or more of RAM and eight cores.

The 490 should be able to run at least Lion with no issue. The very similar 690 runs Lion fine; I'm still at 10.6.8 on my 690, but that's due mostly to simple inertia and the different installer I used on it. I keep thinking I'll take a 1TB drive and try to get Lion on it the myHack way. There are some odd things about the 490 and the 690 that make it a bit difficult, mostly due to the mixed-mode ATA controller. AHCI works, but if you're booting from CD you have to have a SATA CD drive, since the default AHCI support doesn't recognize the PATA optical drives. But see http://www.insanelymac.com/forum/topic/273540-anyone-with-lion-on-dell-precision-690-yes-me/page-2?do=findComment&comment=1911546 for someone who seems to have done ML on one, using myHack 3.2. [EDIT] The script I originally used for SL on the 690 has been updated, see: http://www.insanelymac.com/forum/topic/185097-guide-scripted-retail-mavericksmountain-lion-install-on-gigabyte-mobos/ That's probably a bit off-topic here, though. I used that script at the time because it does AppleRAID and I had a couple of 750GB drives in the box already, and AppleRAID works quite well (SATA drives, AHCI mode, not connected to the LSI SAS RAID controller).

Herve, Perhaps I didn't explain correctly; I originally had an M65/D820, and replaced its motherboard. I then got the M4300, and updated EDP to the M4300 set while the drive was still in the M65/D820, shutdown, moved the disk over to the M4300, and booted it up (this was in Lion), on the M4300, and it worked fine. I used the M4300 bootpack for the upgrade to ML. The D820 bootpack was only used when I upgraded from SL to Lion, on the M65/D820. Same hard drive in all, though, and currently running fine in the M4300. When EDP works right, it enables this sort of thing pretty easily. Sorry for the confusion. In any case, here's my lspci output, under CentOS 6, on my M4300: 00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c) 00:01.0 PCI bridge: Intel Corporation Mobile PM965/GM965/GL960 PCI Express Root Port (rev 0c) 00:1a.0 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 02) 00:1a.1 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 02) 00:1a.7 USB controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 02) 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 02) 00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 02) 00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 (rev 02) 00:1d.0 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 02) 00:1d.1 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 02) 00:1d.2 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 02) 00:1d.7 USB controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) 00:1f.0 ISA bridge: Intel Corporation 82801HM (ICH8M) LPC Interface Controller (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] (rev 02) 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02) 01:00.0 VGA compatible controller: NVIDIA Corporation G86M [Quadro FX 360M] (rev a1) 03:01.0 CardBus bridge: O2 Micro, Inc. Cardbus bridge (rev 21) 03:01.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02) 09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5755M Gigabit Ethernet PCI Express (rev 02) 0c:00.0 Network controller: Broadcom Corporation BCM4321 802.11a/b/g/n (rev 01) 0d:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) The D830 equivalent to the M4300, I think, has the NVS140M as opposed to the NVS135M graphics; if it's anything at all like the D820NV/M65 difference, it should be possible to flash (with patching) an M4300 BIOS on an NVS140M D830 (that sort of cross-flashing up to the Precision M65 is doable on the D820 nVidia if it's the right chip; google for that and you'll find the instructions). M4300's on eBay go for really good prices these days, and with the T9300 chips running right around $50 the M4300/D830 can have some really quick performance. (you can put up to an X9000 in the D830/M4300, but the performance increase from the T9300 at 2.5GHz to the X9000 isn't anywhere near as much as the T7700 at 2.4GHz to the T9300 at 2.5...... I actually am going to be putting a T9300 in this M4300, which currently has a T7700, once I get time to crack the case that far down, and I was planning to coincide that with an upgrade to Mavericks on a 1TB drive. My second M4300, which has a bad USB port on the back, already has a T9300 in it).

I'm running ML 10.8.5 on my M4300 and the ethernet is working; after a lot of traffic, however, it drops out and requires a shutdown/boot up to fix. Note that I primarily use a D/Dock and its ethernet port (right now, in fact). But the D/Dock just extends the lines, to the best of my knowledge; lspci isn't working for me at the moment (gives a cannot find any working access method error). My /Extra shows that the EDP svn version I'm using is 701; that is actually from when I upgraded Lion to ML (with lots of issues of apps getting put in /Recovered Items, argh!) 10.8.3 and running EDP then. I've not been able to successfully update EDP since then; reinstalling and then re-running just produces the same blank window I've seen reported as with Mavericks (by you, in the thread https://osxlatitude.com/index.php?/topic/5568-mavericks-on-m4300/ ) I've also had other issues, mainly frequent kernel panics on boot (it'll KP twice, then boot up ok for a while). I've also seen booting from the USB installer stick bringing up a black screen, but the very next boot, without changing any boot parameters, it will work fine). i've seen this with two separate M4300's, so I don't think it's my hardware, but I reserve the right to be wrong. Since I dual-boot CentOS 6 (64-bit) and that works perfectly fine, I'm further convinced that the hardware is fine. CentOS is actually my primary OS on the laptop, but I do some audio production that requires OS X tools, and so that gets me in OS X at least once a week. My install started life as a 'leppy700m' boot disk install of 10.6.0 on an M65, upgraded to an EDP install (back early in the EDP 5.x cycle), changed to a D820 (motherboard/GPU failure), upgraded to Lion and through 10.7.5, then changed to the M4300 (by doing an EDP build for M4300 on the M65/D820 and swapping the HD to the M4300 and rebooting, which worked fine), then upgraded to ML 10.8.3, and finally a combo update to 10.8.5. Whew. Yes, I'm getting ready to do a scratch install on a new drive. I said that to say that it's quite possible my install has' issues' from the upgrade chain, and a fresh install may be very different.

This works for me. (I still see the 'every other boot or so black screens' issue I've had since getting this M4300, but that's a different thread). Adding arch=x86_64 allowed the boot from USB to proceed, and, after a while, the installer came up (on the second boot, but, again, that's a different thread). I thought this was fixed, but was it not in the bootpack? Or is there a regression?

I'm seeing the same thing with a freshly prepped (with MyHack 3.3) USB stick, app store 10.9 .app, and the Precision M4300 bootpack downloaded today, 10/30/2013. The M4300 is functionally identical to the D830, with just slightly different video (same chip as the NVS140M, I believe, different firmware causes it to report as FX360M, OS X sees it as an 8400M GS). The message that flashes by is too quick to capture, but I'll try to video it..... [uPDATE] The message is 'Mach-O file has bad magic number' Thread URL on this forum is https://osxlatitude.com/index.php?/topic/3065-mach-o-file-has-bad-magic-number-installing-mavericks/ but I'm seeing this booting from the install USB stick itself. Chameleon version is 2266, which is probably the current version in EDP (this install USB was built today, with the 10/27 build of the bootpack and MyHack 3.3). [uPDATE] Making a new installer USB on a stick that I've successfully used several times, with SL, Lion, and ML. Will report back..... [Reporting back] Nope, the stick I've successfully used in the past does exactly the same thing.

MacMacMac, I had already successfully made the transition, as mentioned in the update to the first post. I just made notice of the one gotcha that I found, which was the hardware change that triggered everything that I mentioned. But the transition itself went fine.

MacMacMac, The issue isn't my local smbios.plist; it's the smbios.plist that was in EDP SVN at the time I posted this. The EDP setup for D820 with nVidia as of the revision I posted has incorrect information, and doesn't work on my D820/nVidia. The EDP setup for D620 nVidia does work, and the difference appears to be in the smbios.plist that is in EDP SVN (revision 564). While I am still pulling svn updates, I haven't pursued this further as yet, but may again in the near future, since several updates have happened since rev 564. Using the D620 EDP smbios.plist on my D820 nVidia machine works, and is currently what I'm using.

Ok, I've been looking a bit at this situation, and I've found the following, using the model_data in SVN revision 564: 1.) The DSDT.aml for the D620-nvidia and the D820-nvidia are identical (used DSDTSE to decompile to .dsl): $ diff -u *.dsl --- dsdt-d620-nv.dsl 2013-04-27 11:44:28.000000000 -0400 +++ dsdt-d820-nv.dsl 2013-04-27 11:44:42.000000000 -0400 @@ -2,7 +2,7 @@ * Intel ACPI Component Architecture * AML Disassembler version 20091214 * - * Disassembly of ./dsdt.aml, Sat Apr 27 11:42:53 2013 + * Disassembly of ./dsdt.aml, Sat Apr 27 11:43:09 2013 * * * Original Table Header: $ 2.) The smbios.plist is different, and not just a little different: $ diff -u Dell_Latitude_D620-nvidia/common/smbios.plist Dell_Latitude_D820-nvidia/common/smbios.plist --- Dell_Latitude_D620-nvidia/common/smbios.plist 2013-03-30 13:38:10.000000000 -0400 +++ Dell_Latitude_D820-nvidia/common/smbios.plist 2013-03-30 13:37:43.000000000 -0400 @@ -5,15 +5,15 @@ <key>SMUUID</key> <string></string> <key>SMbiosdate</key> - <string>2/29/2008</string> + <string>10/12/06</string> <key>SMbiosvendor</key> - <string>Apple Inc.</string> + <string>Apple Computer, Inc.</string> <key>SMbiosversion</key> - <string>MB21.00A5.B07</string> + <string>MB11.88Z.0061.B03.0610121324</string> <key>SMboardmanufacturer</key> <string>Apple Computer, Inc.</string> <key>SMboardproduct</key> - <string>Mac-F42C88C8</string> + <string>Mac-F4208CC8</string> <key>SMfamily</key> <string>MacBook</string> <key>SMmanufacturer</key> @@ -21,10 +21,10 @@ <key>SMmemmanufacturer</key> <string>Apple Computer Inc.</string> <key>SMproductname</key> - <string>MacBook2,1</string> + <string>MacBook1,1</string> <key>SMserial</key> <string>5W4ZPC123</string> <key>SMsystemversion</key> - <string>1.1</string> + <string>1.0</string> </dict> </plist> $ Huh?!? The D620 with nVidia is a MacBook 2,1 but the D820 with the same nVidia is a MacBook 1,1? That can't be right. 3.) The org.chameleon.Boot.plist differs: $ diff -u Dell_Latitude_D620-nvidia/common/org.chameleon.Boot.plist Dell_Latitude_D820-nvidia/common/org.chameleon.Boot.plist --- Dell_Latitude_D620-nvidia/common/org.chameleon.Boot.plist 2013-03-30 13:38:10.000000000 -0400 +++ Dell_Latitude_D820-nvidia/common/org.chameleon.Boot.plist 2013-03-30 13:37:43.000000000 -0400 @@ -2,12 +2,8 @@ <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> - <key>EHCIacquire</key> - <string>Yes</string> <key>EthernetBuiltIn</key> <string>Yes</string> - <key>ForceHPET</key> - <string>Yes</string> <key>GenerateCStates</key> <string>Yes</string> <key>GeneratePStates</key> @@ -26,15 +22,9 @@ <string>Default</string> <key>Timeout</key> <string>2</string> - <key>UHCIreset</key> - <string>Yes</string> - <key>USBBusFix</key> - <string>Yes</string> <key>arch</key> <string>i386</string> <key>UseKernelCache</key> <string>Yes</string> - <key>device-properties</key> - <string>5c0400000100000001000000500400001700000002010c00d041030a000000000101060000010101060000007fff04000e0000004e00560050004d00000020000000010000000000000000000000000000000000000000000000000000001c000000400030002c00660062006f006600660073006500740000000800000000000200360000004100410050004c002c006100750078002d0070006f007700650072002d0063006f006e006e0065006300740065006400000008000000010000001c0000006400650076006900630065005f00740079007000650000000f0000004e5644412c506172656e74240000004100410050004c00300030002c0069006e0076006500720074006500720000000800000000000000220000004100410050004c002c0067007200610079002d00700061006700650000000800000001000000320000004100410050004c002c006200610063006b006c0069006700680074002d0063006f006e00740072006f006c0000000800000001000000420000004100410050004c00300030002c0062006c00610063006b00730063007200650065006e002d0070007200650066006500720065006e0063006500730000000800000000000008100000006d006f00640065006c0000001e0000006e56696469612051756164726f204e5653203131304d20454649160000006200750069006c0074002d0069006e000000050000000022000000400030002c006400650076006900630065005f00740079007000650000000b000000646973706c61791c000000400031002c006200750069006c0074002d0069006e0000000400000022000000400031002c006400650076006900630065005f00740079007000650000000b000000646973706c617920000000400031002c0063006f006d00700061007400690062006c00650000000e0000004e5644412c4e564d616314000000400030002c006e0061006d0065000000120000004e5644412c446973706c61792d411c000000400030002c006200750069006c0074002d0069006e0000000400000014000000400030002c004e0056004d00540000005c0000000a037f204c2d1c0278051a044807d0056006000041041d0421040000f0c1410700000100000000ff00000000000000000000000000000000000000000000000000000000ffff00000000000000000000010000000000000014000000400031002c006e0061006d0065000000120000004e5644412c446973706c61792d421200000049004f004e0061006d00650000000b000000646973706c617920000000400030002c0063006f006d00700061007400690062006c00650000000e0000004e5644412c4e564d616324000000400031002c00630061006e002d0068006f0074002d0070006c0075006700000004000000100000004e00560043004100500000001800000004000100000003000c0000000000000a000000002a00000049004f0050004d004900730050006f007700650072004d0061006e00610067006500640000000500000001</string> </dict> </plist> $ That's also not a small difference, with the D620's containing a lot more (and this is the exact .plists I'm booting my D820/M65 with right now!). Hmm, what about the Intel GMA D820..... Same thing, the D820 gets a MacBook1,1 but the D620 is MacBook2,1; but I don't have a D820-Intel to test on, so it might very well work that way on the D820-intel). In a similar light, my Inspiron 9400 (GMA950, 1920x1200 screen) works as a D620-intel-high (MB2,1) but won't work with the smbios.plist provided in the Inspiron_9400 EDP (set up as a MBP3,1). My D820/P-M65 is happy with the D620 EDP (as a MacBook2,1) but it is not happy with the D820 EDP (as a MacBook 1,1). For that matter, my D820/M65 is happy without a DSDT.aml or smbios.plist at all, using the leppy700m BootCD (happier, in ways, since the VGA and DVI ports on the D/Dock work with the leppy700m BootCD but don't with the D620 EDP). But that is of course a substantially older Chameleon..... Anyway, there's a few data points....

I'm running SL 10.6.8 on my D820/M65 'mutt' here 'upgraded' from an original 'leppy700m' SL bootCD (with almost zero postinstall work) to the current EDP setup, and I had a very similar symptom using the D820 nVidia bootpack and the D820 nVidia EDP. Everything works with the D620 nVidia bootpack and EDP. I haven't had the time to track down the differences between the D620 nVidia bootpack/EDP and the D820 nVidia bootpack/EDP to be able to say for certain, but it's probably a DSDT issue. [EDIT: looks more like an smbios.plist and/or org.chameleon.Boot.plist issue.... see https://osxlatitude.com/index.php?/topic/2493-d820-nvidia-and-d620-nvidia-differences-in-edp/ for that thread....] Can you try with an external monitor connected? EDIT: Thought of something else; which USB port are you using? I've had the best reliability with the bottom right-hand-side port for USB keys and drives; the top port works, but seems to provide less power (possibly my hardware). The back ports haven't been as reliable as the bottom right-hand ports, but I don't use the back ports very often since I have a full D/Dock (with PCI slot), and I've found that the USB ports on the D/Dock are the least reliable for large transfers. But that's another post (and a question....).

A further update: do note that if you do this migration to EDP from something else that your machine ID might be changed, and programs that you have activated on the machine may need reactivating. UPDATE: And make sure you deactivate any software prior to doing the transition; some software authors (such as Celemony for their Melodyne product) can take a very hard line on this, and you lose an activation (yes, I remembered to deactivate a couple of programs before I did the migration, and so didn't lose any activations....). Also, Time Machine will detect the box as being a new machine, and will complain when you try to do a backup, asking if you want to reuse the existing backup, create a new one, or don't back up now......

And an update: Selecting D620 nvidia instead of D820 nvidia works fine, and the display is good.

Herve (sorry to not have the accent; haven't had to type that before, and cut and paste want to make it a link); Thanks much for the reply. I attempted the fix at the post https://osxlatitude.com/index.php?/topic/2290-d820-nvidia-no-network-card-after-lion-install/page-2&do=findComment&comment=17395 but that didn't seem to work. Booting the D820-nvidia-bootpacked installer USB key, selecting the installed OSX 10.6.8 instead of the installer, works fine. I'm trying, next, what was suggested in https://osxlatitude.com/index.php?/topic/2102-d820-lion-black-screen-nvs110/&do=findComment&comment=15884 My D820/M65 has the NVS120m instead of the 110m that is more 'normal' for the D820.... and I unfortunately don't have an external monitor to try at home, but I will try again with the D820 EDP next week when I'm back at work. What I would love, though, is a keyboard shortcut to do either a shutdown or graceful restart from the login screen; on a regular Mac this involves the 'eject' key with modifiers, but using the 'F12' key in its place doesn't produce the desired effect.... then even with a black screen it could be recovered more gracefully than holding the power button down for eight seconds and doing an fsck in single user mode on the next boot.... And again, thanks for the reply. When I have opportunity I'll dig a little deeper; I've pulled a svnsync of the EDP repo and will slog through it as I can. It seems to be just the ticket for these boxen, and I appreciate the work!

Update: Well, after not seeing anything for a while, and after doing some more research, I took the plunge and simply installed EDP. I did a build (current rev 537); then did the 10.6.8 combo update, did the build again, and only then did I reboot. Upon reboot, got the black screen issue. I can boot with the USB key I prepared earlier for the D820 nVidia, so that's good, just have to work out what's wrong to cause the blackscreen. Specs: nVidia NVS 120M w/ 1920x1200 LCD, D820/M65 motherboard.