Looking for MXM ROM

[muppet]

Here's how I went about looking for the MXM ROM on my (now upgraded) Acer Aspire 5520g. In short - I don't think this model has any of the MXM Structure containing mechanisms (int 15h, ACPI DSDT nor an MXM ROM) and instead hard codes the required data in the VBIOS.

Just posting this incase someone else is going to this level of detail in an effort to look at MXM compatibility issues etc - noting that messing at this level with any tool could crash or even brick your machine: the Linux lm_sensors package had references to crashes when probing I2C device addresses 0x6a and 0x69 on some machines and some documented cases of outright bricking of Thinkpads due to a misbehaving I2C device. I could also be totally wrong about how I went about this...

Background

The MXM software spec states "the MXM v 2.1 structure can be accessed from a serial ROM which is placed on the motherboard. Communication is through serial link DDCC and the ROM device is assumed to be at address ACh/ADh...The MXM v 2.1 structure is read out of the ROM by the VBIOS during POST, as a series of sequential bytes starting at offset 0 in the ROM".

My understanding of the above is:

DDCC

This is the I2C bus where the EDID for the laptop?s display is found (as well as the MXM ROM).

The software spec indicates "DDC/Aux Port" for "DDCC" in the MXM Output Device Structure.

The MXM Electro spec states that DDCC_CLK (pin 222) and DDCC_DAT (pin 220) are "Serial link, connect to EDID LVDS Panel and to MXM System Information ROM". The spec could also see an MXM external GPIO device on DDCC (if it exists, the spec requires that it exist on DDCC at 0x4C).

ACh/ADh

The so called I2C "1st byte" - with a 7-bit I2C slave address of 0x56 with read/write lsbit set (1010-110x) to on(ADh) or off(ACh).

offset 0 in the ROM

The Electro spec states ?For MXM System Information ROM implementations, the Motherboard is required to place a 256 Byte serial ROM that connects to DDCC_CLK and DDCC_DAT with a device address of 0xAC. The ROM must be compatible to an Atmel 24C02 and operate with 3.3 V signaling.?

Presumably there is some documentation for reading the contents of an 256B Atmel 24C02 (I did find references for variations with larger storage). Never got to this point... though I presume you need to write the offset to the device before reading.

Testing

To access the I2C buses from software, I grabbed an eval version of the WinI2C-DDC library and wrote some quick code to enumerate the buses looking for the EDID and MXM ROM, though lm_sensors under Linux also looked like an option and worst case I guess there's the VESA DDC BIOS functions (on int 10h) in DOS or possibly the WINIO driver. The WinI2C-DDC installs a driver that allows accessing the i2c buses natively.

Out of the box, WinI2C-DDC has a pre-compiled "VB I2C" sample that enumerates only the bus with the EDID on and looks for devices in the full 7 bit address range. I would recommend caution though (see above re devices at 0x6a and 0x69 and Thinkpad issues) ? even though I did end up scanning the same range with my C++ harness after not finding the MXM ROM device with no obvious ill effects. If you are running the VB I2C sample, you are looking for a device answering at address 86 (0x56).

Checking through the I2C devices found on the on the 4 I2C buses I could access on my machine, on the 4th bus enumerated I found a device acknowledging at 0x50 (later confirmed that this EEPROM contains the EDID structure of the laptop display panel) and a device at 0x6A, but nothing at 0x56 (MXM ROM) nor 0x4C (optional MXM GPIO device). I did this using the WinI2C-DDC option to use native bus access only ? the WinI2C-DDC option to use the display driver-only resulted in no buses to enumerate.

I presumed that bus 0 is the smbus, bus 1 is DDCA, bus 2 is DDCB and bus 3 is DDCC. Didn?t spend much time going into this though.

My best guess is that the device on the DDCC bus at address 0x6A is a clock device and not the MXM ROM at a non-standard address:

- lm_sensors faq has references to clocks at addresses 0x69 and 0x6A

- Address doesn?t have ?1010? msbits common to eeproms.

- Address has ?1101? msbits seemingly used by other clock devices.

Edited February 10, 2008 by muppet