Any ideas?
superiotool finds nothing on this machine. It's i945/ICH7
On 11/26/09 7:34 PM, Stefan Reinauer wrote:
Any ideas?
superiotool finds nothing on this machine. It's i945/ICH7
The flash part is one of:
* EON EN29LV800AB * AMD M29LV800BE * Spansion S29AL008D * AMIC A29L800A
More information as I get it
There's almost certainly a GPIO protecting the flash.
The lack of superio is not surprising, or is it?
Can you do the "GPIO probe" that I did for the Dell and see if something pops up?
ron
On 11/26/09 7:46 PM, Stefan Reinauer wrote:
On 11/26/09 7:34 PM, Stefan Reinauer wrote:
Any ideas?
superiotool finds nothing on this machine. It's i945/ICH7
The flash part is one of:
- EON EN29LV800AB
- AMD M29LV800BE
- Spansion S29AL008D
- AMIC A29L800A
More information as I get it
Ok, Carl-Daniel, you were of course right. :-) The flash part is behind an ENE KB3910SF embedded controller. Opening the box I found out it's a spansion S29AL008D. Now if only the KB3910SF (EnE 910) datasheets were available.
Stefan
On 27.11.2009 13:03, Stefan Reinauer wrote:
On 11/26/09 7:46 PM, Stefan Reinauer wrote:
On 11/26/09 7:34 PM, Stefan Reinauer wrote:
superiotool finds nothing on this machine. It's i945/ICH7
The flash part is one of:
- EON EN29LV800AB
- AMD M29LV800BE
- Spansion S29AL008D
- AMIC A29L800A
Could you cross-check your flash part list with the list of supported chips? Maybe some of them are unsupported. Patches are appreciated as always.
Ok, Carl-Daniel, you were of course right. :-)
Heh. I would have loved to be wrong because that would have made the solution easier. ;-)
The flash part is behind an ENE KB3910SF embedded controller. Opening the box I found out it's a spansion S29AL008D. Now if only the KB3910SF (EnE 910) datasheets were available.
You could sniff LPC and SPI buses during reflashing with the vendor flash tool and correlate the dumps. It should at least give you an idea on how to probe for the EC and possibly also on how to send commands to the flash chip. The probe sequence is most interesting, though, because it allows flashrom to detect the EC and issue a warning message.
Regards, Carl-Daniel
On 11/27/09 1:23 PM, Carl-Daniel Hailfinger wrote:
You could sniff LPC and SPI buses during reflashing with the vendor flash tool and correlate the dumps.
How?
There is not SPI involved, however.
It should at least give you an idea on how to probe for the EC and possibly also on how to send commands to the flash chip. The probe sequence is most interesting, though, because it allows flashrom to detect the EC and issue a warning message.
I found out that I can dump (some of) the EC memory using ectool, but that's only a minor part of the story.
The ENE 910 has both a SPI and FWH interface, but otherwise it seems fairly similar to a 3700 (which was used in the OLPC) Unfortunately I didn't find any info on how to generically identify the presence of the 3700 either. In particular, I didn't find the IO address for indexing the full EC memory yet (0x381 on the OLPC)
Stefan
On 27.11.2009 15:01, Stefan Reinauer wrote:
On 11/27/09 1:23 PM, Carl-Daniel Hailfinger wrote:
You could sniff LPC and SPI buses during reflashing with the vendor flash tool and correlate the dumps.
How?
There is not SPI involved, however.
Sorry, my bad. I was writing two mails at the same time and confused the SPI problem with your problem.
It should at least give you an idea on how to probe for the EC and possibly also on how to send commands to the flash chip. The probe sequence is most interesting, though, because it allows flashrom to detect the EC and issue a warning message.
I found out that I can dump (some of) the EC memory using ectool, but that's only a minor part of the story.
The ENE 910 has both a SPI and FWH interface, but otherwise it seems fairly similar to a 3700 (which was used in the OLPC) Unfortunately I didn't find any info on how to generically identify the presence of the 3700 either. In particular, I didn't find the IO address for indexing the full EC memory yet (0x381 on the OLPC)
AFAIK this is configurable and can even be disabled by the EC firmware.
Regards, Carl-Daniel
Have we crossed some boundary where we're going to need tools to systematically reverse engineer the EC now? Maybe we need to start accumulating EC knowledge on a new coreboot.org page ... I am realizing I don't understand them at all.
ron
On 27.11.2009 17:43, ron minnich wrote:
Have we crossed some boundary where we're going to need tools to systematically reverse engineer the EC now? Maybe we need to start accumulating EC knowledge on a new coreboot.org page ... I am realizing I don't understand them at all.
coreboot.org or flashrom.org? The goals are pretty different. Each needs EC interaction, but coreboot doesn't care about being able to flash and usually has people who can dump the chip, while flashrom cares very much about being able to flash and nothing else.
I tried to explain the EC situation from a flashrom perspective: http://www.flashrom.org/Supported_hardware#Unsupported_Laptops.2FNotebooks.2...
Regards, Carl-Daniel
On Fri, Nov 27, 2009 at 9:27 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
coreboot.org or flashrom.org? The goals are pretty different. Each needs EC interaction, but coreboot doesn't care about being able to flash and usually has people who can dump the chip, while flashrom cares very much about being able to flash and nothing else.
The concerns are going to start to merge again if this serialice hack I'm thinking of works out :-)
ron
On 27.11.2009 20:05, ron minnich wrote:
On Fri, Nov 27, 2009 at 9:27 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
coreboot.org or flashrom.org? The goals are pretty different. Each needs EC interaction, but coreboot doesn't care about being able to flash and usually has people who can dump the chip, while flashrom cares very much about being able to flash and nothing else.
The concerns are going to start to merge again if this serialice hack I'm thinking of works out :-)
Rudolf was working on a serialice variant which could run DOS apps, and there are many vendor DOS apps which interact with ECs.
Regards, Carl-Daniel
On Fri, Nov 27, 2009 at 06:27:10PM +0100, Carl-Daniel Hailfinger wrote:
On 27.11.2009 17:43, ron minnich wrote:
Have we crossed some boundary where we're going to need tools to systematically reverse engineer the EC now? Maybe we need to start accumulating EC knowledge on a new coreboot.org page ... I am realizing I don't understand them at all.
coreboot.org or flashrom.org? The goals are pretty different. Each needs EC interaction, but coreboot doesn't care about being able to flash and usually has people who can dump the chip, while flashrom cares very much about being able to flash and nothing else.
I tried to explain the EC situation from a flashrom perspective: http://www.flashrom.org/Supported_hardware#Unsupported_Laptops.2FNotebooks.2...
Information about the EC used in thinkpads may possibly be gained from tp_smapi: http://www.thinkwiki.org/wiki/Tp_smapi The project has a thinkpad_ec module so they may have a method of reliably detecting the beast :-)
Ciao Jörg
On 26.11.2009 19:34, Stefan Reinauer wrote:
Any ideas?
superiotool finds nothing on this machine. It's i945/ICH7
Hm, yes. It seems we're missing a probe sequence for your superio or EC.
flashrom v0.9.1-r783 Found chipset "Intel ICH7M", enabling flash write... BIOS Lock Enable: disabled, BIOS Write Enable: enabled, BIOS_CNTL is 0x1
Write is enabled.
BIOS Interface Lock-Down: disabled, BOOT BIOS Straps: 0x3 (LPC)
Chipset is strapped to use LPC/FWH.
This chipset supports the following protocols: LPC,FWH.
ICH7 special feature. If it is strapped to LPC/FWH, SPI is really completely disabled. You can't even probe on SPI. (Yes, we tried.)
Probing for AMIC A49LF040A, 512 KB: probe_jedec: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL002, 256 KB: probe_jedec: id1 0x66, id2 0x51, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF003A/B, 384 KB: probe_jedec: id1 0x8b, id2 0x04, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V080FA, 1024 KB: probe_jedec: id1 0x02, id2 0x18, id1 is normal flash content, id2 is normal flash content
All probe sequences return either a parity violation for the vendor ID (there is not even a single vendor ID among all few hundred JEDEC mebers which violates parity) and are thus invalid, or at least the probe result is identical to the flash contents. Even if this was just an accident and we look up vendor ID 0x2, I don't believe AMI, National Instruments, ISOA, Optosys, Innovics Wireless, Patriot Memory, Mavrix create any BIOS flash (well, Patriot creates flash, but only the large kind for SSDs).
Given these constraints, I can almost guarantee that the flash is not directly attached to the chipset, but resides behind some sort of translator (most probably the EC). David Hendricks wanted to tackle EC recognition and flashing. No idea how far he progressed.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
Joerg Mayer -
ron minnich -
Stefan Reinauer