flashrom's output below. what I've missed so far?
Calibrating delay loop... Setting up microsecond timing loop 798M loops per second ok No LinuxBIOS table found. Enabling flash write on ICH7DH...tried to set 0xdc to 0x3 on ICH7DH failed (WARNING ONLY) Trying Am29F040B, 512 KB probe_29f040b: id1 0xff, id2 0xff Trying Am29F016D, 2048 KB probe_29f040b: id1 0xff, id2 0xff Trying AE49F2008, 256 KB probe_jedec: id1 0xff, id2 0xff Trying At29C040A, 512 KB probe_jedec: id1 0xff, id2 0xff Trying Mx29f002, 256 KB probe_29f002: id1 0xff, id2 0xff Trying SST29EE020A, 256 KB probe_jedec: id1 0xff, id2 0xff Trying SST25LF080A, 1024 KB probe_jedec: id1 0x0, id2 0x0 Trying SST28SF040A, 512 KB probe_28sf040: id1 0xff, id2 0xff Trying SST39SF010A, 128 KB probe_jedec: id1 0xff, id2 0xff Trying SST39SF020A, 256 KB
On Tue, Mar 27, 2007 at 07:21:06PM +0400, Anton wrote:
flashrom's output below. what I've missed so far?
Which chip is this? And on which mainboard do you try to use flashrom?
This _could_ be a problem, but not necessarily. It might also work, I think.
Uwe.
[Please always reply to the mailing list, not individual developers]
----- Forwarded message from Anton anton.borisov@gmail.com -----
From: Anton anton.borisov@gmail.com To: Uwe Hermann uwe@hermann-uwe.de Subject: Re: [LinuxBIOS] ICH7DH: flash_enable failed Date: Fri, 30 Mar 2007 19:08:41 +0400
On Fri, 30 Mar 2007 15:52:25 +0200 Uwe Hermann uwe@hermann-uwe.de wrote:
00:00.0 Host bridge: Intel Corporation 82975X Memory Controller Hub 00:01.0 PCI bridge: Intel Corporation 82975X PCI Express Root Port 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.4 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 5 (rev 01) 00:1c.5 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 6 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GH (ICH7DH) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) 00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller IDE (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 04:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller 05:00.0 VGA compatible controller: S3 Inc. ViRGE/DX or /GX (rev 01) 05:04.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) 05:05.0 RAID bus controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02)
00:00.0 Class 0600: 8086:277c 00:01.0 Class 0604: 8086:277d 00:1b.0 Class 0403: 8086:27d8 (rev 01) 00:1c.0 Class 0604: 8086:27d0 (rev 01) 00:1c.4 Class 0604: 8086:27e0 (rev 01) 00:1c.5 Class 0604: 8086:27e2 (rev 01) 00:1d.0 Class 0c03: 8086:27c8 (rev 01) 00:1d.1 Class 0c03: 8086:27c9 (rev 01) 00:1d.2 Class 0c03: 8086:27ca (rev 01) 00:1d.3 Class 0c03: 8086:27cb (rev 01) 00:1d.7 Class 0c03: 8086:27cc (rev 01) 00:1e.0 Class 0604: 8086:244e (rev e1) 00:1f.0 Class 0601: 8086:27b0 (rev 01) 00:1f.1 Class 0101: 8086:27df (rev 01) 00:1f.2 Class 0101: 8086:27c0 (rev 01) 00:1f.3 Class 0c05: 8086:27da (rev 01) 04:00.0 Class 0200: 8086:109a 05:00.0 Class 0300: 5333:8a01 (rev 01) 05:04.0 Class 0c00: 104c:8024 05:05.0 Class 0104: 1095:3114 (rev 02)
But it doesn't.
P.S. Flash chip is *infamous* SST25LF080A :-)
----- End forwarded message -----
* Uwe Hermann uwe@hermann-uwe.de [070330 18:32]:
But it doesn't.
P.S. Flash chip is *infamous* SST25LF080A :-)
Ah, flashrom of course does not support SPI chips.
On Sat, 31 Mar 2007 01:19:33 +0200 Stefan Reinauer stepan@coresystems.de wrote:
Yep. Solutions / ideas?
* Anton anton.borisov@gmail.com [070331 01:49]:
gotta love git and its urls
http://dev.laptop.org/git?p=projects/olpcflash;a=blob;h=73331cd596e639da7229...
On 31.03.2007 01:49, Anton wrote:
olpcflash should work.
Regards, Carl-Daniel
On Sat, 31 Mar 2007 01:56:32 +0200 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
He-he. SST and Winbond are there :)
Anton wrote:
P.S. Flash chip is *infamous* SST25LF080A :-)
Ah, flashrom of course does not support SPI chips.
olpcflash will not work. olpcflash does very specific things that are only valid on a ENE EC. olpcflash deals with the flash in what the ene calls "firmware" mode. Where each SPI byte you write to the SPI bridge gets put directly on the SPI bus. It does this via IO access to the EC.
The SPI bridge in the ICH7 does not work that way. The SPI registers are memory mapped and it looks like you fill some registers with the Op codes you want to run, some registers with the Data and then some other registers with the address and say go.
I also see some stuff that may pose a problem.
5.25.5.1 BIOS Range Write Protection The ICH7 provides a method for blocking writes to specific ranges in the SPI flash when the Protected BIOS Ranges are enabled. This is achieved by checking the Opcode type information (which can be locked down by the initial Boot BIOS) and the address of the requested command against the base and limit fields of a Write Protected BIOS range.
Note: Once BIOS has locked down the Protected BIOS Range registers, this mechanism remains in place until the next system reset.
This is the same style of thing that OLPC is using. Once you set the write protect it can only be cleared by a system reset.
So if they have some sort of fallback mechanism that they never want overwritten they could set the bios that range and then we will not be able to overwrite it.
Some sort of exploit or chip removal would be the only way to reprogram it if thats the case.
On Sat, Mar 31, 2007 at 01:19:33AM +0200, Stefan Reinauer wrote:
P.S. Flash chip is *infamous* SST25LF080A :-)
Ah, flashrom of course does not support SPI chips.
It also does not support any southbridge SPI masters.
On Sat, Mar 31, 2007 at 01:55:54AM +0200, Stefan Reinauer wrote:
On Sat, Mar 31, 2007 at 01:56:32AM +0200, Carl-Daniel Hailfinger wrote:
olpcflash should work.
No, it shouldn't.
olpcflash is an OLPC-specific tool that programs an SPI flash rom through the embedded controller on the OLPC.
On other boards, this is done by the southbridge. See chapter 5 and 21 in the ICH7 datasheet for example.
There are many lockdown mechanisms in the ICH7. If any of them is enabled by the default system BIOS, it will not be possible for flashrom to reprogram an SPI flash chip. But then it will also not be possible for any Intel software to do so. Hopefully that's not commonly done.
The solution is to implement SPI master support in flashrom for the needed southbridge. It would be nice if flashrom could identify a particular board model (Luc's patches, right?) so that SPI can be auto-selected, but flashrom could also first try LPC/parallell write and if that doesn't work try SPI, or worst case require the user to enable SPI programming.
I estimate adding this SPI support is a day or two's worth of hacking. A board is needed to test. (Mostly to learn if and how the SPI master has been locked down by the factory BIOS.)
//Peter
On Sat, 31 Mar 2007 04:03:25 +0200 Peter Stuge stuge-linuxbios@cdy.org wrote:
Feel free to address hw testing to me. I have ICH7 board exactly for this purpose.
On Sat, Mar 31, 2007 at 03:40:30PM +0400, Anton wrote:
No time right now. Maybe in a week or two, but please don't wait if anyone else wants to go for it.
Do you have equipment to analyze the signals to the flash chip? Ideally a logic analyzer, but a 20MHz scope can work too.
There's no other way to debug this code. :\
//Peter
Do you have equipment to analyze the signals to the flash chip? Ideally a logic analyzer, but a 20MHz scope can work too.
That's ideally. In reality, several things are absent.
There's no other way to debug this code. :\
Except to rev-eng the code, original flasher uses. But this isn't suitable for me (too much time is required for analysis).
On Sat, Mar 31, 2007 at 09:45:25PM +0400, Anton wrote:
A scope is easier to come by though. I have one, but I don't have a board with SPI flash.
If the new software doesn't work even though it's implemented "just like" the original flasher we still need to see what's (not) happening on the bus.
//Peter
-
Anton -
Carl-Daniel Hailfinger -
Peter Stuge -
Richard Smith -
Stefan Reinauer -
Uwe Hermann