#101: flashrom: Remove pciutils check from Makefile
---------------------------------------------+------------------------------
Reporter: stuge | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone: flashrom v1.0
Component: flashrom | Version:
Keywords: pciutils libpci build ldflags | Dependencies:
Patchstatus: patch needs review |
---------------------------------------------+------------------------------
The check belongs in a configure script or similar, the check also claims
that packages can not be found for any build error, which is not good
enough. Has confused more than one user already.
--
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/101>
coreboot <http://www.coreboot.org/>
#113: problem
---------------------------------+------------------------------------------
Reporter: anonymous | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: adlo | Version: v2
Keywords: | Dependencies:
Patchstatus: there is no patch |
---------------------------------+------------------------------------------
there is a bug
--
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/113>
coreboot <http://www.coreboot.org/>
#106: flashrom: Add -T to automatically test all flash chip operations
---------------------------------+------------------------------------------
Reporter: stuge | Owner: somebody
Type: enhancement | Status: new
Priority: major | Milestone: flashrom v1.0
Component: flashrom | Version:
Keywords: testing | Dependencies:
Patchstatus: there is no patch |
---------------------------------+------------------------------------------
Maybe require -f to actually perform the test, since it will potentially
fail to restore the flash chip to it's original state.
--
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/106>
coreboot <http://www.coreboot.org/>
#141: flashrom: Warn the user when trying to read/write chips which are bigger
than what the chipset can decode
---------------------------------+------------------------------------------
Reporter: uwe | Owner: somebody
Type: defect | Status: new
Priority: critical | Milestone:
Component: flashrom | Version:
Keywords: | Dependencies:
Patchstatus: there is no patch |
---------------------------------+------------------------------------------
We should make a table in the flashrom code which tells it how much a
given (detected/supported) southbridge can decode.
Then, if the user tries to read/write/erase/verify a chip which is
_bigger_ (e.g. 512 KB) than what the southbridge can decode (e.g. 256 KB
as on the AMD CS5530A for example) flashrom should at the very least warn
the user, probably even bail out with an error.
I've stumbled upon exactly this problem, trying to make a backup of a
512KB chip in an CS5530A system. I ended up with only one half of the
contents (but duplicated) and it _did_ verify OK.
That's because I did 'flashrom -r bak.bin' on the box (which effectively
got me two equal, broken 256KB halves instead of one correct 512KB image).
Then I did 'flashrom -wv bak.bin' onto the other 512KB chip, which also
got the incorrect contents, _but_ flashrom said it verified fine (which is
actually true) because both the bak.bin _and_ the written contents are
crap.
I only noticed what was going on after lots of debugging. I finally did a
'dd if=/dev/urandom of=rnd.dd bs=1024c count=512', then 'flashrom -wv
rnd.dd' which then FAILED, because here the two 256KB-halves of the image
were _not_ the same as in the above case. Then I compared 'hexdump -Cv
rnd.dd' and 'flashrom -r readback.dd; hexdump -Cv readback.dd' outputs and
noticed that bytes 0x0..0x40000 (256 KB) were _not_ the same, but the
other 256 KB _were_ the same.
Anyway, this is a nice way for data loss, so we should fix it by throwing
an error in such cases.
--
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/141>
coreboot <http://www.coreboot.org/>
#123: layout file
-------------------------------------+--------------------------------------
Reporter: vivanov@… | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone: flashrom v1.0
Component: flashrom | Version: v2
Keywords: layout address offset | Dependencies:
Patchstatus: there is no patch |
-------------------------------------+--------------------------------------
Hello,
I am trying to update the BIOS "ST M50FW080" and get the following
incomprehensibility - layout file works in a strange way
1) saved the current BIOS
{{{
$ flashrom --read flash18_saved.rom
}}}
2) then I filled first 512K of this file with zeros (it is needed because
new BIOS will have 512K size)
3) then I created rom.layout file to use the normal image only:
{{{
00000000:0007ffff stuff
00080000:000fffff normal
}}}
4) and started to upgrade BIOS
{{{
$ flashrom --write --layout rom.layout --image flash18_saved.rom
}}}
And get the following:
{{{
Looking for "normal"... found.
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "Intel ICH4/ICH4-L", enabling flash write... OK.
Found chip "ST M50FW080" (1024 KB) at physical address 0xfff00000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to flashrom(a)coreboot.org if any of the above
operations
work correctly for you with this flash part. Please include the full
output
from the program, including chipset found. Thank you for your help!
===
Flash image seems to be a legacy BIOS. Disabling checks.
Programming page:
0000 at address: 0x00000000SKIPPED
0001 at address: 0x00010000SKIPPED
0002 at address: 0x00020000SKIPPED
0003 at address: 0x00030000SKIPPED
0004 at address: 0x00040000SKIPPED
0005 at address: 0x00050000SKIPPED
0006 at address: 0x00060000SKIPPED
'''0007 at address: 0x00070000DONE BLOCK 0x70000'''
0008 at address: 0x00080000SKIPPED
0009 at address: 0x00090000SKIPPED
0010 at address: 0x000a0000SKIPPED
0011 at address: 0x000b0000SKIPPED
0012 at address: 0x000c0000SKIPPED
0013 at address: 0x000d0000SKIPPED
0014 at address: 0x000e0000SKIPPED
0015 at address: 0x000f0000SKIPPED
}}}
'''Next'''
I changed the rom.layout file like follows:
{{{
# cat rom.layout
00000000:00080000 stuff
00080000:000fffff normal
}}}
and get the '''right''' behaviour:
{{{
# flashrom --write --layout rom.layout --image normal --verify
flash18_saved.rom
Looking for "normal"... found.
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "Intel ICH4/ICH4-L", enabling flash write... OK.
Found chip "ST M50FW080" (1024 KB) at physical address 0xfff00000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to flashrom(a)coreboot.org if any of the above
operations
work correctly for you with this flash part. Please include the full
output
from the program, including chipset found. Thank you for your help!
===
Flash image seems to be a legacy BIOS. Disabling checks.
Programming page:
0000 at address: 0x00000000SKIPPED
0001 at address: 0x00010000SKIPPED
0002 at address: 0x00020000SKIPPED
0003 at address: 0x00030000SKIPPED
0004 at address: 0x00040000SKIPPED
0005 at address: 0x00050000SKIPPED
0006 at address: 0x00060000SKIPPED
0007 at address: 0x00070000SKIPPED
0008 at address: 0x00080000SKIPPED
0009 at address: 0x00090000SKIPPED
0010 at address: 0x000a0000SKIPPED
0011 at address: 0x000b0000SKIPPED
0012 at address: 0x000c0000SKIPPED
0013 at address: 0x000d0000SKIPPED
0014 at address: 0x000e0000SKIPPED
0015 at address: 0x000f0000SKIPPED
Verifying flash... VERIFIED.
}}}
Please explain me which rom layout I should use to update the last 512K of
1M BIOS?
--
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/123>
coreboot <http://www.coreboot.org/>
#133: Create a typical failures FAQ
---------------------------------------+------------------------------------
Reporter: stuge | Owner: somebody
Type: enhancement | Status: new
Priority: major | Milestone:
Component: flashrom | Version:
Keywords: faq documentation debug | Dependencies:
Patchstatus: there is no patch |
---------------------------------------+------------------------------------
Briefly describe what flashrom needs to do to successfully identify, read
and write/erase the different type of chips to optimize the remote
debugging process with new users.
--
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/133>
coreboot <http://www.coreboot.org/>
#130: flashrom segfault (with backtrace)
---------------------------------+------------------------------------------
Reporter: fragabr@… | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: flashrom | Version: v2
Keywords: | Dependencies:
Patchstatus: there is no patch |
---------------------------------+------------------------------------------
I want to test flashrom with a supported motherboard (Asus M2N-E with
Linux 2.6.30-rc4) and it segfaults when I run it. I'm using the latest
libpci (3.1.2):
{{{
Calibrating delay loop... OK.
No coreboot table found.
Segmentation fault
}}}
Backtrace:
{{{
#0 0x00007f1395141d49 in pci_fill_info_v31 () from
/usr/local/lib/libpci.so.3
#1 0x00007f1395143c59 in pci_filter_match () from
/usr/local/lib/libpci.so.3
#2 0x000000000040732f in ?? ()
#3 0x00000000004016f8 in ?? ()
#4 0x0000000000406d46 in ?? ()
#5 0x00007f1394df24f6 in __libc_start_main () from /lib64/libc.so.6
#6 0x0000000000401619 in ?? ()
#7 0x00007fff9d579e98 in ?? ()
#8 0x000000000000001c in ?? ()
#9 0x0000000000000001 in ?? ()
#10 0x00007fff9d57ab55 in ?? ()
#11 0x0000000000000000 in ?? ()
}}}
--
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/130>
coreboot <http://www.coreboot.org/>
#140: flashrom: Consistently use stderr for error printing
---------------------------------+------------------------------------------
Reporter: uwe | Owner: somebody
Type: defect | Status: new
Priority: minor | Milestone: flashrom v1.0
Component: flashrom | Version:
Keywords: | Dependencies:
Patchstatus: there is no patch |
---------------------------------+------------------------------------------
We're not very consistent with error printing in flashrom. Many errors go
to stdout instead of stderr. We should fix that by using fprintf(stderr,
"Foo") where needed.
--
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/140>
coreboot <http://www.coreboot.org/>
#144: TYAN S7012 support
--------------------------------------------------------+-------------------
Reporter: john@… | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: flashrom | Version: v2
Keywords: TYAN S7012 Intel ICH10R SST SST25VF032B | Dependencies:
Patchstatus: there is no patch |
--------------------------------------------------------+-------------------
I'm unable to flash a system that runs on a TYAN S7012 motherboard.
# flashrom -w bios.bin
flashrom v0.9.0-r659
No coreboot table found.
Found chipset "Intel ICH10R", enabling flash write... OK.
This chipset supports the following protocols: LPC,FWH,SPI.
Calibrating delay loop... OK.
Found chip "SST SST25VF032B" (4096 KB, SPI) at physical address
0xffc00000.
Flash image seems to be a legacy BIOS. Disabling checks.
Writing flash chip... COMPLETE.
Verifying flash... VERIFY FAILED at 0x00002000! Expected=0x00, Read=0xff
Running it with verbose the following error messages are printed out
(repeating).
Writing flash chip... Invalid OPCODE 0x06
due to SPI master limitation, ignoring and hoping it will be run as PREOP
Transaction error!
run OPCODE 0x02 failed
spi_byte_program failed during command execution
Invalid OPCODE 0x06
due to SPI master limitation, ignoring and hoping it will be run as PREOP
Transaction error!
run OPCODE 0x02 failed
spi_byte_program failed during command execution
Invalid OPCODE 0x06
CONFIG_STRICT_DEVMEM is not set in my kernel.
Anything I should try out?
--
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/144>
coreboot <http://www.coreboot.org/>
