[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Libreboot-dev] Dell OptiPlex 755 status

From: Patrick 'P. J.' McDermott
Subject: [Libreboot-dev] Dell OptiPlex 755 status
Date: Fri, 14 Aug 2015 23:11:16 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0

For the past two weeks I've been working on a (really nice) libreboot
candidate system: the Dell OptiPlex 755 USFF.  (There are three other
form factor variants of the 755, but I'm focusing on USFF for now.)
Following are notes from my work so far, for posterity.

The mainboard and northbridge are not yet supported by coreboot, but
I've started work on support for those (I wrote about 1300 lines of code
for them last week).  Everything else should work with coreboot.  I also
ported SerialICE to the OptiPlex 755.  But all the work I've done so far
is untested.

At this point, I'm stuck on a flashrom/programmer issue, as described in
the next section.

Flashing methods


This is where I'm a bit stuck on this port.

The mainboard has an Atmel AT26DF321 4-MiB SOIC-8 SPI flash chip [1],
which I've programmed before on an X200 with flashrom and Linux's spidev
on a BBB and Pomona 5250.

But on this board, I can't get flashrom to detect the chip.  I get 0xff
bytes on a read ID command (so the chip or something is holding MISO
high).  Normally this indicates a connection or data voltage issue, but
I'm pretty certain the connections are fine and I know the data voltage
is right.

I've sent to the flashrom mailing list [2][3] a description of
everything I've tried along with an example log.  As an addendum, I
think I've ruled out the Deep Power-Down mode theory.  I built a patched
flashrom that sends a resume command while I have CS# connected to GND
to assert it, waits ten seconds for me to switch CS# to VCC to deassert
it, then sends the read ID command.  I'm still getting all 0xff bytes,
although maybe the high impedance state between low and high voltage on
CS# is causing a problem.

So, I'm out of ideas for reading this AT26DF321 chip on this mainboard.
I'd welcome any suggestions or thoughts anyone else may have.

Otherwise, the only option is to desolder the chip from the board,
replace it with a DIP socket, and externally program some DIP chips.
I'd rather not have to do that just to write to a flash chip that should
work with in-system programming.

Installation of a known working ROM

The good news is that I think I've figured out a way to write a working
ROM (i.e. one that won't require recovery) on this board without
external flashing or soldering.

I accidentally discovered that the following things happen when the
"DIMM_2" slot is populated and "DIMM_1" isn't.  First, the Phoenix BIOS
throws an error "Alert!  Unsupported memory configuration. Please
populate DIMM1." but will still boot after the user presses their F1
key.  Second, apparently the BIOS sets the PR0–PR4 protected range
SPIBAR registers to allow reading and writing on all five flash regions.
Also, the FLMSTR1–FLMSTR3 flash master registers in the Flash Descriptor
region of flash allow read and write access by all three flash masters,
including the host CPU.

So flashrom is able to read (and probably write, though I haven't tested
this because I don't yet have a working recovery method) the entire
flash memory space when the BIOS boots with DIMM_1 unpopulated.  I
compared over 30 dumps of the flash contents, and I found that many of
them differ in a few bytes of the ME region.  So, this DIMM trick
affects only how the BIOS configures the ICH9, and the ME is still
running and writing to flash.  So if we write anything of our own to
flash, the ME will most likely clobber at least a few bytes of it.

There's a SERVICE_MODE jumper on the mainboard, but installing it
doesn't disable the ME (flash contents still change) or have any other
obvious effects.

Thus, we need a way to disable the ME.  We could first write to the
flash chip a Flash Descriptor region with an ICHSTRAP0 section modified
to disable the ME (as we do on GM45 systems).  Then we should be able to
reboot and find the ME not running, which would then allow us to write a
complete ROM image and overwrite the ME firmware.

So, to summarize, the following two-stage installation method should
work in theory: boot with DIMM_1 unpopulated, write a Flash Descriptor
that disables the ME, reboot with DIMM_1 still unpopulated, write a
complete ROM image.

Hardware details and coreboot support

Based on the E-number under a mainboard UL certification mark as well as
the word "ASUS" on a couple of chassis parts, I've determined that the
ODM for this computer is ASUSTeK.  In 2008 ASUSTeK split into three
different companies, and their design division is now Pegatron.  The
model number of the mainboard is HX553 A00.  I and others scoured the
Web and looked for public FTP sites in search of schematics.  I've
requested information from Pegatron for this board, but so far I've
heard nothing back and I don't expect a positive answer (ASUSTeK's
contract with Dell probably even forbids them from disclosing anything).
So, it looks like we'll never have schematics for the board, which is
unfortunate and limiting but not really fatal.

Dell published a "Technical Guide" [4] which has fairly detailed
specifications.  There's also a "User's Guide" [5] that shows some
maintenance procedures and BIOS troubleshooting information.

The CPU socket is LGA775.  The northbridge is an Intel 82Q35 GMCH (Intel
3 Series Chipset) [6], for which a datasheet [7] is available and a
mythical BIOS Writer's Guide is kept hidden away by Intel.  This
northbridge is not yet supported by coreboot, but I've written bootblock
and early romstage code and the beginnings of raminit code (enough to
query, validate, and print SPD data for each DIMM).

The southbridge is an Intel 82801IO ICH9 [8], for which a datasheet [9]
is available.  coreboot supports this chip.

The super I/O controller is an SMSC SCH5514E-NS, which might work with
coreboot's generic SMSC super I/O code.  No datasheets are published.
Microchip Technology Inc. bought out SMSC, and I've asked them for a
datasheet.  They've asked me to provide a contact at the OEM (Dell)
authorizing release of the document, after which they'll need an NDA
with my company.  So I'm just hoping the generic code in coreboot works.

So, after solving the flashing issue above, the main (overly simplified)
tasks will be:

 1. Finish the raminit code with the help of SerialICE (which I've also
    ported to the OptiPlex 755).
 2. Work on the ramstage code for the northbridge and mainboard.
 3. Work on native graphics init code.
 4. Add patches and a config to libreboot.

(This is a plan and not a guarantee that I'll be able to complete this
port.  But I really want to get this nice desktop system running


Patrick "P. J." McDermott
Lead Developer, ProteanOS

reply via email to

[Prev in Thread] Current Thread [Next in Thread]