Adds a function to enable the flash interface on w83697xx superio's.
Still needs to be hooked up to the superio detection framework though.
Signed-off-by: David Borg <borg.db(a)gmail.com>
On Wed, 12 Oct 2011 22:01:01 +0400
"Andrey V. Bondarenko" <avbondarenko(a)gmail.com> wrote:
> Hello,
>
> Verbose output is in the attachment file for chipset Intel C204. I sent this
> e-mail because it was suggested to send report.
>
> # ./flashrom --read ./P8B-E-4L-ASUS-0602.ROM
> flashrom v0.9.4-r1395 on Linux 2.6.18-274.3.1.el5.028stab094.3 (x86_64),
> built with libpci 3.1.7, GCC 4.1.2 20080704 (Red Hat 4.1.2-51), little
> endian
> flashrom is free software, get the source code at http://www.flashrom.org
>
> Calibrating delay loop... OK.
> Found chipset "Intel C204".
> This chipset is marked as untested. If you are using an up-to-date version
> of flashrom please email a report to flashrom(a)flashrom.org including a
> verbose (-V) log. Thank you!
> Enabling flash write... OK.
> This chipset supports the following protocols: FWH, SPI.
> Found Winbond flash chip "W25Q64" (8192 kB, SPI) at physical address
> 0xff800000.
> Reading flash... Transaction error!
> Read operation failed!
> FAILED.
hello and thanks for your report.
this is another case of a locked Management Engine (ME) region, which
we can't unlock yet.
i have added the P8B-E/4L to our list of boards with a note about the
problem for now and will commit that later.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Hello,
I would like to submit a patch, that enables extra argument when using
FT2232 external programmer, a frequency divider. For FT2232 programmer
we have this divider set to 3 by default by DIVIDE_BY constant, which
will result in 10MHz (H-chips) or 2MHz (non H-chips) SPI speeds.
By providing divider as parameter, SPI interface frequency culd be
overridden by user, resulting in different speeds (H-chip example):
divider | freq
---------+--------
1 | 30Mhz
2 | 15Mhz
3 | 10Mhz
4 | 7.5Mhz
5 | 6Mhz
6 | 5Mhz
15 | 2Mhz
30 | 1Mhz
60 | 0.5Mhz
600 | 0.05Mhz
(and so on)
These lower than default SPI speeds can be very useful when we have
flawed flash chips that would not support 10Mhz or bad quality or too
long cabling between programmer and the chip. Higher than default speeds
might also be useful (if only flashrom AAI implementation was faster).
Please note that this parameter is arbitrary integer, maybe only a value
up to 255 would really make sense, but i can not be sure about that
since it may be programmer hardware dependent. All values between 1-255
worked for me (PicoTAP programmer), as well as 300 & 600 (these resulted
in extremely slow flash reads, as expected, 2MB flash that usually takes
16s to read @2-10Mhz, took more than 6 minutes @0.05Mhz). Others values
i haven't tested.
Signed-off-by: Samir Ibradžić <sibradzic(a)gmail.com>
---
$ svn diff
Index: ft2232_spi.c
===================================================================
--- ft2232_spi.c (revision 1451)
+++ ft2232_spi.c (working copy)
@@ -168,6 +168,7 @@
enum ftdi_interface ft2232_interface = INTERFACE_B;
char *arg;
double mpsse_clk;
+ int divider = DIVIDE_BY;
arg = extract_programmer_param("type");
if (arg) {
@@ -237,6 +238,17 @@
}
}
free(arg);
+ arg = extract_programmer_param("divider");
+ if (arg) {
+ if (isdigit(*arg) && (atoi(arg) > 0))
+ divider = atoi(arg);
+ else {
+ msg_perr("Error: Invalid frequency divider specified.\n");
+ free(arg);
+ return -2;
+ }
+ }
+ free(arg);
msg_pdbg("Using device type %s %s ",
get_ft2232_vendorname(ft2232_vid, ft2232_type),
get_ft2232_devicename(ft2232_vid, ft2232_type));
@@ -298,16 +310,16 @@
msg_pdbg("Set clock divisor\n");
buf[0] = 0x86; /* command "set divisor" */
/* valueL/valueH are (desired_divisor - 1) */
- buf[1] = (DIVIDE_BY - 1) & 0xff;
- buf[2] = ((DIVIDE_BY - 1) >> 8) & 0xff;
+ buf[1] = (divider - 1) & 0xff;
+ buf[2] = ((divider - 1) >> 8) & 0xff;
if (send_buf(ftdic, buf, 3)) {
ret = -6;
goto ftdi_err;
}
msg_pdbg("MPSSE clock: %f MHz divisor: %d "
- "SPI clock: %f MHz\n", mpsse_clk, DIVIDE_BY,
- (double)(mpsse_clk / (((DIVIDE_BY - 1) + 1) * 2)));
+ "SPI clock: %f MHz\n", mpsse_clk, divider,
+ (double)(mpsse_clk / (((divider - 1) + 1) * 2)));
/* Disconnect TDI/DO to TDO/DI for loopback. */
msg_pdbg("No loopback of TDI/DO TDO/DI\n");
--
R,
S
Hello,
I tried out flashrom on a ASUS OPLX-M motherboard, and it didn't find a flash
device. I found some info by googling (that I cannot verify) that the OPLX-M
would be an OEM (or something) version of the ASUS MEL-M; I suppose this
particular board originally came with a Fujitsu/Siemens PC.
http://support.asus.com/download/download.aspx?modelname=MEL-M&SLanguage=...
On Sun, 27 Nov 2011 11:48:51 -0800
David Hendricks <david.hendricks(a)gmail.com> wrote:
> On Sat, Nov 26, 2011 at 3:35 PM, Stefan Tauner <
> stefan.tauner(a)student.tuwien.ac.at> wrote:
>
> > This includes the notorious read-only flash descriptors and locked ME
> > regions.
> > ---
> > non-verbose sample output from my laptop:
> > […]
> > Found chipset "Intel QS57". Enabling flash write... WARNING: SPI
> > Configuration Lockdown activated.
> > WARNING: Flash Descriptor region is not fully accessible and flashrom can
> > not deal with this correctly yet. Intel does not provide us the necessary
> > documention to support this.
>
>
> To be fair, I think Intel documents it fine.
That depends on what 'it' is. The limitations and the influence of
FDOPSS on that limitation are well defined in public documentation. But
the unlocking process is not documented at all publicly. We know from
different leaked documents and also from the fact that vendor tools
exist, that unlocking can be done by software only and without touching
the FDOPSS pin by sending the "HMRFPO Enable" command via HECI/MEI to
the ME. The details are documented in the BIOS writer guide(s) (which
are "restricted secret" level(?))
> I think what we've got to do
> is checking the flash descriptor override pin strap status (FDOPSS). If it
> is cleared then we can ignore the descriptor, otherwise if it is set then
> we need to avoid locked regions.
I would not call it 'ignoring'. We should be aware, that the limitation
do not apply (we do print a message to the user already in that case),
but we could and should use the regions where it makes sense
(e.g. automatic creation of layout (file)s.
> It's really just a pain in the ass and, as you pointed out, may leave the
> BIOS/ME firmware blobs in an inconsistent or incompatible state. So the
> onus is on the user to ensure a safe upgrade path if only part of the ROM
> can be updated. It's probably worth displaying a warning and requiring
> "--force" or something in that scenario.
As a first step yes. IIRC i have sent a patch that does that when active
PR protections are found(?), but i think it is not in/reviewed yet. I
agree, we should set write_allowed = 0 (or whatever it was) and
rephrase the warning to include that.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Hi Mike,
On 23.02.2010 05:45, Spangler, Mike T wrote:
> I can probe with a continuity tester, but would need to know specific
> pin locations to try. Do you have any generic info on doing this?
Yes (well, I'd have to write up something), but the solution mentioned
by Michael is way easier, so I'll wait until Michael has diagnosed the
GPIO settings from the flashrom run on factory BIOS.
Regards,
Carl-Daniel
--
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth
