Modify

Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#87 closed defect (fixed)

flashrom issues on m57sli-s4

Reported by: ward Owned by: hailfinger
Priority: major Milestone:
Component: flashrom (please use trac on flashrom.org) Keywords:
Cc: Dependencies:
Patch Status: there is no patch

Description

There is a problem with flashrom; it won't work reliably when the machine is booted under LinuxBIOS on the m57sli-s4.

This is what I used to see:

It works maybe 1 out of 10 times - it always works when booted with the proprietary BIOS. I can tell while it's flashing if it is good or not good: the speed of the flashing is moderately fast for a good flash. For a bad flash, it is either too fast, too slow, or it varies a lot during the flash.

This is what I'm seeing today (with the latest rev of flashrom, 2744):

Flashrom jumps from page 15 to page 224 while flashing, and then fails to verify. I've tried with several different chis (all of the same type though).

# ./flashrom -vvvv -w /home/ward/Desktop/buildrom/buildrom-devel/deploy/gigabyte-m57sli.rom -V
Calibrating delay loop... 537M loops per second. ok
Found canidate at: 00000530-00000e2c
Found LinuxBIOS table at: 00000530
lb_table found at address 0xb7e40530
LinuxBIOS header(24) checksum: e2db table(2300) checksum: 826c entries: 14
vendor id: GIGABYTE part id: m57sli
Found chipset "NVIDIA MCP55": Enabling flash write... OK.
Probing for Am29F040B, 512 KB
probe_29f040b: id1 0xff, id2 0xff
Probing for Am29F016D, 2048 KB
probe_29f040b: id1 0xff, id2 0xff
Probing for AE49F2008, 256 KB
probe_jedec: id1 0xbf, id2 0x5b
Probing for At29C040A, 512 KB
probe_jedec: id1 0xbf, id2 0x5b
Probing for At29C020, 256 KB
probe_jedec: id1 0xbf, id2 0x5b
Probing for Mx29f002, 256 KB
probe_29f002: id1 0xbf, id2 0x5b
Probing for SST29EE020A, 256 KB
probe_jedec: id1 0xbf, id2 0x5b
Probing for SST28SF040A, 512 KB
probe_28sf040: id1 0xff, id2 0xff
Probing for SST39SF010A, 128 KB
probe_jedec: id1 0xbf, id2 0x5b
Probing for SST39SF020A, 256 KB
probe_jedec: id1 0xbf, id2 0x5b
Probing for SST39SF040, 512 KB
probe_jedec: id1 0xbf, id2 0x5b
Probing for SST39VF020, 256 KB
probe_jedec: id1 0xbf, id2 0x5b
Probing for SST49LF040B, 512 KB
probe_jedec: id1 0xbf, id2 0x5b
Probing for SST49LF040, 512 KB
probe_jedec: id1 0xbf, id2 0x5b
Probing for SST49LF020A, 256 KB
probe_jedec: id1 0xbf, id2 0x5b
Probing for SST49LF080A, 1024 KB
probe_jedec: id1 0xbf, id2 0x5b
SST49LF080A found at physical address: 0xfff00000
Flash part is SST49LF080A (1024 KB)
LinuxBIOS last image size (not rom size) is 1048576 bytes.
MANUFACTURER: GIGABYTE
MAINBOARD ID: m57sli
This firmware image matches this motherboard.
Programming Page: 0255 at address: 0x000ff000
Verifying flash address: 0x00000000 - FAILED

I should note that I'm using a bios savior to swap flash chips, and that the socket has been soldered onto the board manually. But under the proprietary bios there is never a problem, so...

Attachments (0)

Change History (6)

comment:1 Changed 8 years ago by ward

  • Component changed from code to flashrom

comment:2 Changed 8 years ago by hailfinger

Two possible reasons:

  • Differing LPC bus frequency.
  • Differing GPIO configuration, which may result in uninitialized #WP and/or #WE on the flash chip.

You may want to verify both settings with an oscilloscope or any other tool you have handy. In case you want to verify correct settings from the software side, you have to make sure BIOS shadowing is disabled, then run a few timing trials of flash readout both under LB and proprietary. The speed should not differ. For GPIO configuration, check superiotool output differences and MCP55 GPIO registers (the latter may require a NDA to get a map of meanings).

comment:3 Changed 8 years ago by hailfinger

For timing tests of flash readout, make sure CPU frequency scaling and power management are disabled. Then run

time flashrom -V --read test.rom; md5sum test.rom

on an idle system a few times in a row. If the "delay loops per second" value varies a lot, either the system is under load or CPU frequency scaling is active. If the md5sum is not constant, something fishy is going on.

The real/user/sys time needed for the command is what I'm interested in. The delay loop value is useless for LPC bus frequency measurement.

comment:4 Changed 8 years ago by hailfinger

  • Owner changed from somebody to hailfinger

I need superiotool output for a board with parallel flash running under LB. NOW.

AFAICS the flash configuration is totally botched on LB with floating GPIOs, wrong timing etc.

I have a patch pending which will solve the flashing problem on all M57SLI boards, but I refuse to send it to the list before I have superiotool output to verify.

comment:5 Changed 8 years ago by hailfinger

  • Status changed from new to assigned

Thanks to Torsten and Andi for testing. This is fixed in r2955 for parallel flash.

Serial flash remains to be solved. For that I need superiotool output for both board generations under LB rev2955.

comment:6 Changed 7 years ago by ward

  • Resolution set to fixed
  • Status changed from assigned to closed

PLCC-based flashing was accidentally broken in r2972. This was fixed in r3087.

SPI-based flashing is now also fixed since r3088, thanks to Florentin Demetrescu.

Add Comment

Modify Ticket

Action
as closed The owner will remain hailfinger.
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.