1. Running PureDarwin in VMware
2. Settings
1. VMware settings
1. Enable the built-in VNC server
2. Boot arguments
3. Faking guest OS detection
3. Devices
1. VMware Fusion BIOS
2. Bootloader
1. darwin.iso
3. Single user mode
4. Multi user mode
4. Boot
5. Network
1. Emulated NICs
1. e1000
2. Status
6. e1000 support quest
1. Notions
1. Driver and IOPCIDevice
2. PCI matching summarization
2. Vendor and Device IDs
1. Vendor ID (intel def.)
2. Device ID (Intel def.)
3. PCI configuration space registers
4. PCI matching dictionary
3. Real KEXTs
1. w/o KEXT
2. AppleIntel8255x
3. Intel82566MM
4. AppleIntel8254XEthernet
4. a KEXT pseudo-life
5. Host NIC
7. Troubleshooting
1. On read-only medium
2. Random log
8. Resources

It is very easy to run PureDarwin with VMware.

a VMware product a PureDarwin system (can be downloaded or produced)

• a ready-to-run .vmwarevm (read-write) or .vmdk
• a PureDarwin ISO, and either use it directly (read-only) This ISO can be converted into a VMware disk image (.vmdk) file using a little conversion tool called `qemu-img'. The resulting disk image will be read-write, and can be mounted by double-clicking so that you can change its contents from the host system: qemu-img convert -O vmdk PureDarwin.iso PureDarwin.vmdk

Launch VMware Fusion 2.0 or later and create a new machine based on the ISO or .vmdk - VMware Fusion will automatically recognize it as "Mac OS X Server" and configure the virtual machine accordingly. You do not need to change any settings.

Two KEXTs appeard useful for VMware release(s) other than Fusion:

• LegacyAppleIntelPIIXATA
• NullCPUPowerManagement They can be found in VMware-Drivers-OpenSource.zip. See Downloads page.

Add these lines in the .vmx file:

RemoteDisplay.vnc.port = "5900" RemoteDisplay.vnc.enabled = "TRUE"

RemoteDisplay.vnc.password = "password"

Then simply connect your favorite VNC client to localhost.

(please add text)

We need to fake VMware guest OS detection in order to avoid error message "The guest operating system is not Mac OS X Server" (implicitly to simply boot).

VMware guest OS detection is trivial, and so the way to avoid it:

touch "/Volumes/PureDarwin/System/Library/CoreServices/ServerVersion.plist" Note: This tweak should/could be deprecated by time.

VMware Fusion 2.0.5 Host: Mac OS X 9.7.0 Guest: PureDarwin (9J61)

Here's a vendor/device id list retrieved from the VMware guest OS:

"0x8086","0x7191","Intel Corporation","82443BX/ZX","440BX/ZX AGPset PCI-to-PCI bridge" "0x8086","0x7110","Intel Corporation","82371AB/EB/MB","PIIX4/4E/4M ISBridgeA " "0x8086","0x7113","Intel Corporation","82371AB/EB/MB","PIIX4/4E/4M Power Management Controller" "0x8086","0x7111","Intel Corporation","82371AB/EB/MB","PIIX4/4E/4M IDE Controller" "0x15ad","0x0790","","" [...] <- + x 30 "0x15ad","0x0790","",""

"0x8086","0x7112","Intel Corporation","82371AB/EB/MB","PIIX4/4E/4M USB Interface" "0x8086","0x100F","Intel Corporation","82545EM","Gigabit Ethernet Controller (copper)" "0x15AD","0x0770","VMware Inc.","n/a","Standard Enhanced PCI to USB Host Controller" "0x1274","0x1371","Ensoniq","ES 1371","AudioPCI" "0x1000","0x0030","LSI Logic","LSI53C1020/1030","PCI-X to Ultra320 SCSI Controller" "0x15AD","0x0405","VMware Inc.","9500MGS","NVIDIA" "0x15AD","0x0740","VMware Inc.","0X0880","VMWare VMCI Bus Device" "0x8086","0x7190","Intel Corporation","82443BX/ZX","440BX/ZX AGPset Host Bridge"

VMware Fusion comes with a combo PhoenixBIOS/VMware BIOS.

VMware uses darwin.iso (VMware Tools) which contains the DFE bootloader (Stage 2 boot file < 128K) to provide a bootloader.

Located in /Library/Application Support/VMware Fusion/isoimages/original/darwin.iso ISO 9660 CD-ROM filesystem data 'CD' (bootable) pdisk reports: Partition map (with 512 byte blocks) on 'original/darwin.iso' #: type name length base ( size ) 1: Apple_partition_map Apple 63 @ 1 2: Apple_HFS DiscRecording 3.2.0f2 6940 @ 244 ( 3.4M) Device block size=2048, Number of Blocks=3339059200 (6.2T) DeviceType=0x0, DeviceId=0x0 The DFE bootloader: -r--r--r--@ 1 201 wheel 63520 Jun 23 00:20 /Volumes/VMware Tools/.hiddendir/boot (dfe’) In order to compare the siwe, Chameleon takes 295328B and the latest DFE 63648B. Facing the bootloader size limitation: It is possible to alter the content of darwin.iso, but the package needs to be signed again. hdiutil -readwrite attach darwin.iso hdiutil eject.. openssl genrsa -out tools-priv.pem 2048 openssl rsa -in tools-priv.pem -pubout -out tools-key.pub openssl dgst -sha1 -sign tools-priv.pem < darwin.iso > darwin.iso.sig for A in *.iso ; do openssl dgst -sha1 -sign tools-priv.pem < $A > $A.sig ; done

It boots.

VMware seems to provide 3 emulated NIC:

• e1000
• **VMware NIC - vmxnet **High performance (Gigabit), need VMware drivers in the guest. OK for production.
• **VLANCE (aka AMD PCNET-32) **Lower perf, high CPU load, no kext available, problems solved. Update November 2012: A driver is in the works at https://code.google.com/p/pcnet32-driver-for-puredarwin/ - information about this driver still needs to be worked into this page

VMware emulates an Intel e1000 network card. "e1000" is apparently a generic term for a series of similar but different chips. http://www.intel.com/design/network/products/lan/controllers/82545.htm

From Intel: Stepping Vendor ID Device ID Description 82547EI-A0 8086h 1019h Copper 82547EI-A1 8086h 1019h Copper 82547EI-B0 8086h 1019h Copper 82547EI-B0 8086h 101Ah Mobile 82547GI-B0 8086h 1019h Copper 82546EB-A1 8086h 1010h Copper; Dual Port MAC Default 82546EB-A1 8086h 1012h Fiber; Dual Port 82546EB-A1 8086h 101Dh Copper; Quad Port 82546GB-B0 8086h 1079h Copper; Dual Port 82546GB-B0 8086h 107Ah Fiber; Dual Port 82546GB-B0 8086h 107Bh SerDes; Dual Port 82545EM-A 8086h 100Fh Copper 82545EM-A 8086h 1011h Fiber 82545GM-B 8086h 1026h Copper MAC Default 82545GM-B 8086h 1027h Fiber 82545GM-B 8086h 1028h SerDes 82544EI-A4 8086h 1107h Copper MAC Default 82544GC-A4 8086h 1112h Copper MAC Default 82541EI-A0 8086h 1013h Cooper MAC Default 82541EI-A0 8086h 1013h Cooper MAC Default 82541EI-B0 8086h 1013h Cooper MAC Default 82541EI-B0 8086h 1018h Mobile 82541GI-B1 8086h 1076h Cooper 82541GI-B1 8086h 1077h Mobile 82541PI-C0 8086h 1076h Cooper 82541ER-C0 8086h 1078h Cooper 82540EP-A 8086h 1017 Desktop 82540EP-A 8086h 1016 Mobile 82540EM-A 8086h 100E Desktop 82540EM-A 8086h 1015 Mobile

The VMware virtual device chipset seems to correspond to the Intel82545EM (Copper)

• Vendor ID: 0x8086
• Primary device ID: 0x100F

Mac OS X contains a driver (AppleIntel8254XEthernet) for the chip emulated by VMware which "should match and work". But this driver is not available for Darwin yet, neither in source nor binary form.

We found also two KEXTs close (but not enough "by nature") to the VMware 82545EM virtual device:

• AppleIntel8255x (built from the Darwinbuild project)
• 82566mm-osx-driver (an OpenSource one) Both of the two KEXTs personality file (Info.plist) can be modified to match the VMware virtual device in order to be (kext)loaded at boot. But no interface (e.g., en0) is affected...

PCI stands for Peripheral Component Interconnect.

A driver for a PCI Ethernet controller inherits from IOEthernetController but uses an instance of IOPCIDevice class (in order to connect to the PCI bus). IOPCIDevice is a basic nub class representing any PCI device in any PCI slot.

Ethernet driver <-> IOPCIDevice <-> IOPCIBridge <-> IOPlatformDevice <-> ...

A driver can control a device on a PCI bus. A driver announces this fact by including a "personality" in its plist file. This personality includes IOProviderClass=IOPCIDevice (Key=Value). IOPCIDevice defines 2 sets of keys that a driver can use for matching:

• a key based on standard PCI registers
• a key based on Open Firmware (probably related to PPC only) A PCI device driver can use one type of key or both of them (if personalities are disjoint)

This uniquely identifies all Intel PCI products. This field may be auto-loaded from the EEPROM at power on or upon the assertion of PCI_RST#. A value of 0x8086 is the default for this field upon power up if the EEPROM does not respond or is not programmed.

This uniquely identifies the Ethernet controller. This field may be autoloaded from the EEPROM at power on or upon the assertion of RST#. The default value for this field is used upon power up if the EEPROM does not respond or is not programmed.

• vendor and device ID (offsets 0x00 and 0x002)
• subsystem vendor and device ID (offsets 0x2C and 0x2E)
• class code (offset 0x09)
• revision ID (not available in property matching)
• header type (not available in property matching)

Value for a key can be a single register value or a list (space separator). Register values are little-endian hexa strings (device ID first then vendor ID). A mask can be included (only a part of the value is compared), bits set to 0 are ignored by the mask

• IOPCIMatch matches against primary vendor/device ID registers (checked first) or matches aganst the subsystem vendor/device ID
• IOPCIPrimaryMatch matches against primary vendor/device ID registers
• IOPCISecondaryMatch matches against the subsystem vendor/device ID registers
• IOPCIClassMatch matches against the class code register Examples of corresponding key/value based on vendor and device id which can be expected in Info.plist:

Vendor ID: 0x8086 Primary device ID: 0x100F <key>IOPCIMatch</key> <string>0x100F8086</string>

Vendor ID: 0x8086 Primary device ID: 0x1000 or 0x100F

<key>IOPCIMatch</key> <string>0x10008086 0x100F8086</string>

Vendor ID: 0x8086 Primary device ID: 0x1000..0x10FF (first two digits subsystem IDs are not checked)

<key>IOPCIPrimaryMatch</key> <string>0x10008086&0xFF00FFFF</string>

Class code for ethernet controller (0x0200 (in fact 4bytes, last byte ignored)) <key>IOPCIClassMatch</key> <string>0x02000000&0xffff0000</string> Consequently, the PCI ID associated to the 82545EM chipset should be "100F:8086" Which is confirmed on

• FreeBSD: 100F8086 -> 82545EM Gigabit ethernet controller Coper
• GNU/Linux: *pci 8086:100F kmod-e1000 *corresponds to e1000.ko
• Intel: From the "Intel PCI/PCI-X Family of Gigabit Ethernet Controllers Software Developer’s Manual", A list of pair model / device id is available in the Intel spec, which confirm the result above ( "IOModel" = "82545EM Copper" )
• e1000 from sourceforge: 82540EP/EM, 82541xx, 82544GC/EI, 82545GM/EM, 82546GB/EB, and 82547xx http://kent.dl.sourceforge.net/sourceforge/e1000/OpenSDM_8254x-37.pdf
• http://www.pcidatabase.com/vendor_details.php?id=1302 also. Note: "When running VMware ESX Server 3.0.0, you can experience a kernel panic if you use Intel e1000 network adapters with any of the following PCI IDs: 0x100F[...]" - http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2221

Example without any network kext loaded (according to kextstat and grep): Quickly finding the node into ioreg: class is IOPCIDevice even the IOName and name are the only "ethernet" occurence found 0x0200 is the class code for ethernet 0x8086 is the vendor id

| | | +-o S2F0@1 <class IOPCIDevice, registered, matched, active, busy 0, retain 6> | | | | { | | | | "IOPCIResourced" = Yes | | | | "IOInterruptControllers" = ("io-apic-0") | | | | "IOName" = "ethernet" | | | | "subsystem-id" = <50070000> | | | | "IODeviceMemory" = (({"address"=18446744073048031232,"length"=131072}),({"address"=18446744073047900160,"le$ | | | | "class-code" = <00000200> | | | | "IOPowerManagement" = {"CurrentPowerState"=2} | | | | "revision-id" = <01000000> | | | | "IOInterruptSpecifiers" = (<1300000007000000>) | | | | "assigned-addresses" = <1008028200000000000092d800000000000002001808028200000000000090d80000000000000100200$ | | | | "IOChildIndex" = 2 | | | | "built-in" = <00> | | | | "acpi-device" = "IOACPIPlatformDevice is not serializable" | | | | "device-id" = <0f100000> | | | | "vendor-id" = <86800000> | | | | "acpi-path" = "IOACPIPlane:/_SB/PCI0@0/P2P0@110000/S2F0@10000" | | | | "subsystem-vendor-id" = <ad150000> | | | | "name" = "ethernet" | | | | "reg" = <00080200000000000000000000000000000000001008020200000000000000000000000000000200180802020000000000$ | | | | "compatible" = <"pci15ad,750","pci8086,100f","pciclass,020000"> | | | | }