Hi Guys
I run into trouble using flashrom.
first I downloaded the ROM to flash
then I downloaded flashrom
and run the following command
----------
sudo flashrom
---------- Result:
flashrom v0.9.1-r946
No coreboot table found.
Found chipset "Intel ICH7/ICH7R", enabling flash write... OK.
This chipset supports the following protocols: FWH.
Calibrating delay loop... OK.
Found chip "SST SST49LF004A/B" (512 KB, FWH) at physical address
0xfff80000.
No operations were specified.
---------
I assumed that flashrom can burn my BIOS (since there was no warning given)
Then I tried
---------
sudo flashrom -wv Desktop/Downloads/P5LD2-2002.ROM
---------
Result was that two opperations are not permittet or so
After studying the man page I ran the following command
---------
sudo flashrom -w Desktop/Downloads/P5LD2-2002.ROM
---------
and got panic!!!!!!!
--------
flashrom v0.9.1-r946
No coreboot table found.
Found chipset "Intel ICH7/ICH7R", enabling flash write... OK.
This chipset supports the following protocols: FWH.
Calibrating delay loop... OK.
Found chip "SST SST49LF004A/B" (512 KB, FWH) at physical address
0xfff80000.
Flash image seems to be a legacy BIOS. Disabling checks.
Writing flash chip... Erasing flash chip... ERASE FAILED at
0x000002c8! Expected=0xff,
Read=0x4c, failed byte count from 0x00000000-0x00000fff: 0xd12
ERASE FAILED!
ERASE FAILED at 0x000002c8! Expected=0xff, Read=0x4c, failed byte
count from
0x00000000-0x0000ffff: 0xfc2b
ERASE FAILED!
FAILED!
ERASE FAILED!
FAILED!
Your flash chip is in an unknown state.
Get help on IRC at irc.freenode.net (channel #flashrom) or
mail flashrom(a)flashrom.org!
-------------------------------------------------------------------------------
DO NOT REBOOT OR POWEROFF!
-----------------------------------
PLEASE ADVICE what to do next.
LOOKING EAGERLY FORWARD to YOUR REPLY
Regards
Benjamin
--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
On Fri, 12 Mar 2010, Michael Karcher wrote:
> Was introduced in r926. Found by Henrik Kretzschmar <henne(a)nachtwindheim.de>.
>
> Signed-off-by: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de>
Imo looks sane and should be commited.
Acked-by: Maciej Pijanka <maciej.pijanka(a)gmail.com>
> ---
> board_enable.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/board_enable.c b/board_enable.c
> index aa463bc..0e89137 100644
> --- a/board_enable.c
> +++ b/board_enable.c
> @@ -1445,7 +1445,7 @@ int board_flash_enable(const char *vendor, const char *part)
> if (!board)
> board = board_match_pci_card_ids();
>
> - if (board->status == NT) {
> + if (board && board->status == NT) {
> if (!force_boardenable)
> {
> printf("WARNING: Your mainboard is %s %s, but the mainboard-specific\n"
> --
--
Maciej Pijanka
I don't fear computers, I fear lack of them -- Isaac Asimov
Currently messages like "Writing flash chip..." that don't end with a
newline are buffered until the operation is complete, unless the
particular write function generates status output in the meantime.
Flushing stdout after each message ensures that the message appears
immediately.
Signed-off-by: Ed Swierk <eswierk(a)aristanetworks.com>
---
Index: flashrom-0.9.2-r1057/cli_output.c
===================================================================
--- flashrom-0.9.2-r1057.orig/cli_output.c
+++ flashrom-0.9.2-r1057/cli_output.c
@@ -47,5 +47,6 @@ int print(int type, const char *fmt, ...
va_start(ap, fmt);
ret = vfprintf(output_type, fmt, ap);
va_end(ap);
+ fflush(output_type);
return ret;
}
On 5/14/10 3:06 PM, Michael Karcher wrote:
> Am Freitag, den 14.05.2010, 14:48 +0200 schrieb Stefan Reinauer:
>
>> On 4/16/10 6:21 PM, Stefan Reinauer wrote:
>>
>>> Look at the return value of wait_82802ab()
>>> Index: sst49lfxxxc.c
>>> ===================================================================
>>> --- sst49lfxxxc.c (revision 993)
>>> +++ sst49lfxxxc.c (working copy)
>>> @@ -84,6 +84,7 @@
>>> chip_writeb(0xD0, bios + address);
>>>
>>> status = wait_82802ab(bios);
>>> + print_status_82802ab(status);
>>>
> [...]
> basically a good idea, but printing one status dump per erased block
> seems a bit excessive, even in verbose mode, as there are some chips
> with 4K sector size. Could you limit status printing to "status !=
> 0x80", as this is "ready, no error bits"?
>
That's what the 82802ab and sharp lhf00l04 do, too. So if you think the
behavior should be changed, you should change it in all three places.
Stefan
