thanks for your mail. I have added the flashrom mailing list in CC:
because we should develop a generic way to handle DualBIOS and similar
On 09.04.2010 08:12, Vadim Girlin wrote:
> I'm going to try coreboot on Gigabyte GA-MA770-UD3.
> It's AMD 770 (RX780 / SB700).
> My motherboard supports hardware dual bios - with two chips on it.
> I'm going to try flashing backup chip and boot from it. It seems to be
> possible - I've tested it (flashing at least). Chips on this board could
> be switched by changing bit 0 at undocumented register EF on LDN 7 of
> IT8720. I can use slightly patched flashrom for accessing any chip I
> want without any problems. And this is tested many times.
> My idea is to use backup chip for debugging - that always keeps my
> chance to reboot from main bios chip. And removes the need for
> desoldering etc.
> And second problem is that original bios is checking second chip - and
> trying to recover it by flashing the bios from main chip on reboot?
> rewriting coreboot. AFAICS this could be solved by including some
> signatures etc. It seems to be easy to find out. May be someone is
> working on this?
> BTW I can send the patch for flashrom - but I think that with
> information I mentioned above somebody could make it much better than my
> ugly hack. I hope the regs should be the same for all latest Gigabyte
> MBs using IT8720/18
It would be great if you could send that patch. It will help us make a
flashrom design decision that works for all boards with multiple flash
By the way, some of us have good contacts at ITE, so we can ask ITE for
details about the undocumented registers.
before we change flashrom to work with current layout requirements, we
should summarize the features we need/want, and then decide how to
handle the individual layout regions internally.
"write strategy" describes a combination of erase+write commands with a
given block size, touching some blocks.
"read protected" describes a region which can not be read.
"write protected" describes a region which can not be written.
"write once" describes a region which can be written exactly once in the
If you add a feature to the list, please give it a nickname so we know
which feature people are referring to. Some of the features below might
not be desirable, but I want to list them anyway so we can explicitly
declare them as unsupported if needed.
fullwrite-unrestricted: Write a chip-sized image, no special read/write
restrictions of the chip, no layout file needs to be specified. Default
write case right now.
fullwrite-noread: Write a chip-sized image, reading anything from the
chip is not possible. Many DVD writers fall in that category. No
verification, violates our reliability guarantees.
fullwrite-postread: Write a chip-sized image, reading anything from the
chip is only possible after write. Chips which are read-locked until a
full erase/write fall in that category. Do those exist as standalone
flash chips or only integrated into processors?
fullwrite-partialread: Write a chip-sized image, reading is only
possible in some chip regions. Only partial verification, violates our
fullwrite-partialwrite: Write a chip-sized image, but writing is only
possible in some regions. This is obviously a conflict unless the image
has the same contents as the chip in the write-protected regions and
there is a possible write strategy for the whole image which does not
touch the write-protected regions. Should flashrom always refuse this
scenario, or only refuse it in case of conflicts?
partialwrite-unrestricted: Write only parts of an image, the rest of the
chip contents is kept, no special read/write restrictions.
partialwrite-partialread: Write only parts of an image, the rest of the
chip contents is kept, reading is only possible in some chip regions. If
no read-protected regions are written and a suitable write strategy
exists, should flashrom warn? If a read-protected region is written,
should flashrom warn/refuse due to reliability requirements?
partialwrite-partialwrite: Write only parts of an image, the rest of the
chip contents is kept, writing is only possible in some chip regions. If
no write-protected regions are written and a suitable write strategy
exists, should flashrom warn? flashrom will refuse to write a
fullread-unrestricted: Read the full chip, no special read restrictions
of the chip.
partialread-unrestricted: Read only parts of a chip, no special read
restrictions of the chip.
partialread-partialread: Read only parts of a chip, some regions are
read-protected. flashrom should refuse to read any read-protected regions.
partialread-imagefiller: If only parts of a chip are read and the read
image has full chip size, what should be used as filler for unread
regions? 0x00 or 0xff?
partialread-layout-imagesize: If only parts of a chip are read, should
the read image still have full chip size with all read regions filled in
at the respective locations?
partialread-layout-split: If only parts of a chip are read, should it be
possible to write each region (or a combination thereof) to a separate
image file, and would that mapping be specified in the layout file?
partialwrite-layout-split: If only parts of a chip are written, should
it be possible to collect each part of the new image from a separate
image file, and would that mapping be specified in the layout file?
readwrite-protection-time: Which read protection and write protection
times exist? Temporary lock until unlock, temporary lock until chip soft
reset, temporary lock until chip/programmer hard reset (powerdown or
reset line), permanent eternal lock.
readwrite-protection-type: Which read protection and write protection
types exist? Programmer lock (e.g. Intel SPI), hardware chip lock (WP
pin), software chip lock (chip command).
readwrite-protection-interaction: How should we express this situation:
A region is write-locked with a software chip lock, but to remove that
software chip lock, a hardware chip lock has to be disabled first, then
the software chip lock can be disabled.
partialaccess-crash: Some regions in the chip are really off-limits and
will cause an unrecoverable error (system crash) when accessed (read or
write). That seems to be the case for some EC/flash interactions.
Comments? Any forks of flashrom (e.g. chromium) which need
infrastructure features not mentioned above?
On Mon, 30 May 2011 02:45:44 +0200
Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> wrote:
> this patch also changes the display width of all addresses in physmap.c to 16 hex characters.
> FIXME: what about unmappings?
> munmap is safe.
> djgpp's __dpmi_free_physical_address_mapping: unknown.
> DirectHW's unmap_physical: unknown.
> FIXME: jakllsch suggested using PRIx64 instead of x, because it's more portable
FIXME: in the case we can not map and 'mayfail' is true we should return
ERROR_PTR instead of ERROR_PTR + diff
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
I post a success story about a VIA VT6421A based SATA/PATA PCI controller. The flashrom can probe/read/write successfully the onboard PMC Pm49FL004 chip. I downloaded the patch from http://patchwork.coreboot.org/patch/3214/. Just one thing... "BAR type unknown..." I don't known the meaning, but it worked for me without errors. Please add the patch from above to the trunk. I attached a verbose probe output too.
flashrom v0.9.3-r1362 on Linux 2.6.38-std220-i586 (i686), built with libpci 3.0.0, GCC 4.3.2, little endian
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK.
Found "VIA VT6421A" (1106:3249, BDF 00:0a.0).
BAR type unknown, please report a bug at flashrom(a)flashrom.org
This PCI device is UNTESTED. Please report the 'flashrom -p xxxx' output
to flashrom(a)flashrom.org if it works for you. Please add the name of your
PCI device to the subject. Thank you for your help!
Found chip "PMC Pm49FL004" (512 kB, LPC, FWH) on atavia.
Reading flash... done.
P.S.: Sorry for my english.
I would like to use a flashrom utility to access 2 serial flashes on
the SPI bus of my x86 board, but I'm struggling with the second one.
So I'm looking for any help, hints or advices which can help me to
solve this issue.
I have custom x86 board (Atom n450 CPU, ICH8M chipset) which have 2
serial flashes installed on it.
The first one is SST25VF016B and the second one is Numonyx M45PE16.
The M45PE16 is pretty the similar to the M25PE16.
Both this chips are connected to the SPI bus of the ICH8M chipset, the
CS (chip select) signal of the SST25VF is routed to the SPI_CS0 and
the CS signal of the M45PE16 is routed to the SPI_CS1.
I can successfully read, erase and write the SST flash.
Trying to figure out if flashrom utility can find the second Numonyx
flash I've added the proper description for it to the flashchips.c
(actually I've leaved it the same as for M25PE16 but changed model_id
field). Unfortunately it didn't help me at all.
So I'm wondering if flashrom can't find M45PE16 flash because of
cleared SPI_CS1 signal and how can I enable it?
Does flashrom utility support such kind of configurations or does it
simply searching for the flash on CS0?
Probably some of you have some ideas on enabling SPI_CS1 or even some
useful links etc.
Unfortunately the official Intel ICH8M documentation looks kind of
complicated and no so clear to me.
I'll of course digg into it but any help, hints or advices are highly
Thanks in advance,
#5: Winbond W25Q128 for ICH
Reporter: rheneus.paul@… | Owner: hailfinger
Type: defect | Status: new
Priority: critical | Milestone:
Component: flashrom | Version:
Keywords: | Dependencies:
Patch Status: there is no patch |
I could not use flashrom 0.9.3 -r1205 to detect Winbond W25Q128 to program
BIOS. Attached the read log
Just by adding WINBOND_NEX_W25Q128 0x4018 in flashchips.c for W25Q128,
similar to W25Q64 throws run Opcode 0x3 error for read.
Attached Verbose log of read
Ticket URL: <http://www.flashrom.org/trac/flashrom/ticket/5>
I have an ASUS P5LD2-VM, and I try to update bios, first with flashrom
v0.9.2-r1028 ( http://paste.flashrom.org/view.php?id=489 )
then with 0.9.3 ( http://paste.flashrom.org/view.php?id=490 also, the
ROM is at http://paste.flashrom.org/uploads/491.bin )
Writing flash chip... Erasing flash chip... Looking at blockwise erase
function 0... trying... 0x000000-0x000fff, 0x001000-0x001fff,
0x002000-0x002fff, 0x003000-0xff, 0x004000-0x004fff, 0x005000-0x005fff,
ERASE FAILED at 0x00005760! Expected=0xff, Read=0x50, failed byte count
from 0x00005000-0x00005fff: 0x87a
Can you help whit this?
I'm carco on freenode/#flashrom channel
I'm going to flash Gembird PCI 3SATA+1IDE controller's BIOS, there is W39V040C. I found an excellent professionaly modified ROM for this device. I will try to do it on board of ASUS P4P800E-DELUX. Just let me know, is it possible in the moment or I have to wait for a new version of flashrom.exe? This device have unfriendly relations to Radeon X1600 AGP, on board of ASRock P4i45E MB, so I found only new modified ROM of PCI controller can help.
Waiting for Your answer, Alexey.