Hello,
Parted Magic 6.7 is available.
http://partedmagic.com/doku.php?id=changelog
root@PartedMagic:~# flashrom
flashrom v0.9.4-r1394 on Linux 3.0.4-pmagic (i686), built with libpci
3.1.7, GCC 4.6.1, little endian
Tjuess
Heino
Hi!
Flashrom V0.9.4-r1395 results:
Found chipset « Intel SCH Poulsbo”
Found SST flash chip “SST49LF008A” (1024kB, FWM) @ 0xfff00000
I am under TCL (TinyCore Linux).
Flashing Bios is OK, but erasing flash need many loops to erase all flash (from 0x1000 to 0xFF000 = 256 loops).
But sometimes, it is ok in one time.
What can I do to increase erasing speed (times) … or is there any known bug … perhaps increasing timeout … or ?
Thanks
Daniel.
Daniel MONDON
Ingénieur d'applications
LPG SYSTEMS
30, rue du Docteur Abel
BP 35
26902 VALENCE Cedex 9
Tel: +33475786881 Fax: +33475786953
http://www.lpgsystems.fr
Merci de penser à l'environnement avant d'imprimer ce message
this was fixed by retry (or so :), see below for the log of the IRC
conversation.
* cupantae (~mark@*) has joined #flashrom
<cupantae> I tried to update my bios but now even the writing the backup gives an error. What can I do?
<cupantae> I have emailed flashrom(a)flashrom.org with the report
<idwer> first thing to not do is reboot, second thing is to upload the whole output to http://paste.flashrom.org
<cupantae> ok. done
<cupantae> i'm not sure if this is helpful, but at the "VERIFY FAILED", it gave a different reason each time
<cupantae> first it was at 0x000acd00! Expected=0x23, Read=0xff, failed byte count from 0x00000000-0x000fffff: 0xfe
<cupantae> then at 0x00029400! Expected=0x12, Read=0xff, failed byte count from 0x00000000-0x000fffff: 0x1fc
<cupantae> then at 0x00067700! Expected=0x2f, Read=0xff, failed byte count from 0x00000000-0x000fffff: 0x4ea
<cupantae> oh wait, but always 0xff
<agaran> what machine it is
<cupantae> it's there in http://paste.flashrom.org
<cupantae> it's a geforce6100pm-m2
<agaran> video card?
<cupantae> no that's the name of the motherboard
<cupantae> named after the onboard graphics, it would seem
<agaran> hmm, i never tried upgrading bios on such combo board, but if on internal programmer you get changing reads its *WEIRD*
<agaran> cupantae: can you dump few times actual flash content to new file each time (and not overwriting first backup), then calc md5 over those and show us?
<cupantae> you mean with flashrom -r?
<agaran> yes
<cupantae> ok
<agaran> but please do not overwrite backup
<cupantae> ok. i'm starting "dump1"
<cupantae> without flashing the rom in between, the md5 stayed the same
<cupantae> 625ad915d91e7b134b48aef0105a640b
<cupantae> currently flashing again with the updated version of the bios
<agaran> so it fails on write but in different things
<agaran> so now it worked?
<cupantae> well, attempting to flash, i suppose i should say
<agaran> ok, so verification now against backup passes?
<cupantae> oh my god, it verified this time
<cupantae> i didn't change anything, so is it reasonable to be nervous about rebooting?
<agaran> so if you did backup and assuming read is always correct then i should its quite safe
<agaran> but still i would be somewhat uncertain why it failed at different addresses each time on verify
<cupantae> it does seem strange. that said, i'm not at all familiar with this stuff :-)
<agaran> it is strange
<cupantae> the output is the same before the verifying stage, btw
<cupantae> between the working and failing attempts
<cupantae> anyway, i suppose i don't need your help any more! thanks for your time
<cupantae> so will i reboot and tell you if it worked?
* cupantae has quit (Quit: rebooting)
* cupantae (~mark@*) has joined #flashrom
<cupantae> agaran: back on post-reboot.
<cupantae> seems like a fairly shitty "upgrade" but what harm :-P
<cupantae> thanks for all the support!
* cupantae has quit (Client Quit)
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Op 30-9-2011 19:09, Marcos Felipe Rasia de Mello schreef:
>> I get differences with the previous one. I haven't enter in the bios or change
>> anything... I was expecting no differences between them. Am I missing
>> anything?
>>
>> Regards
>> Jorge
>
> http://flashrom.org/Random_notes#Bios_content_changes_between_reboots
It might be usefull if Flashrom gets a percentage counter:
'file savebios.bin is 99.3% identical to EEPROM contents, continue at
your own risk. It's also 50.0 % identical to file asusbios.bin'
instead of something along the lines of 'verification failed, file is
corrupt'.
Above example would also require a way to reference a 2nd file to verify
against. Let's say that 2nd file is an internet-downloaded original
motherboard vendor's BIOS instead of a flashrom dumped file.
After all, people might want to check if flashrom works correctly before
writing anything. What better way than dump current bios, compare dumped
file to bios but also compare to vendor bios file. All 3 should be
(near-)identical.
On Mon, 19 Sep 2011 18:23:00 -0300
Marcos Felipe Rasia de Mello <marcosfrm(a)gmail.com> wrote:
> The flash chip is a Winbond W49F002U-12B.
>
> BIOS "vxmsv12c.BIN" from:
> http://www.ecs.com.tw/ECSWebSite/Downloads/Downloads_Driver_Detail.aspx?det…
>
> Attached the verbose logs and lspci output.
>
> Marcos
Hello Marcos,
Thanks for your report!
I have marked the chipset as OK and added the ECS P4VXMS (V1.0A) to the
list of supported boards. I will commit that later together with other
small changes.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
2011/9/30 Jorge Fernandez Monteagudo <jorgefm(a)cirsa.com>
>
> Hi,
>
> I'm using flashrom to save the bios from my system to a file.
> I've seen an unexpected behaviour and I would like to know if it's ok.
>
> If I run:
>
> # flashrom --read bios_1st.bin
> # flashrom --read bios_2nd.bin
>
> comparing both files I can't find any difference, but If I reboot the system and
> then:
>
> # flashrom --read bios_3rd.bin
>
> I get differences with the previous one. I haven't enter in the bios or change
> anything... I was expecting no differences between them. Am I missing
> anything?
>
> Regards
> Jorge
http://flashrom.org/Random_notes#Bios_content_changes_between_reboots
Marcos
$ sudo flashrom -V
flashrom v0.9.4-r1395 on Linux 3.0.4 (x86_64), built with libpci 3.1.7,
GCC 4.5.3, little endian
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OS timer resolution is 1 usecs, 649M loops per
second, delay more than 10% too short (got 52% of expected delay),
recalculating... 842M loops per second, delay more than 10% too short
(got 66% of expected delay), recalculating... 597M loops per second,
delay more than 10% too short (got 62% of expected delay),
recalculating... 749M loops per second, delay more than 10% too short
(got 74% of expected delay), recalculating... 822M loops per second,
delay loop is unreliable, trying to continue 10 myus = 8 us, 100 myus =
64 us, 1000 myus = 646 us, 10000 myus = 6992 us, 4 myus = 5 us, OK.
Initializing internal programmer
No coreboot table found.
DMI string system-manufacturer: "To Be Filled By O.E.M."
DMI string system-product-name: "To Be Filled By O.E.M."
DMI string system-version: "To Be Filled By O.E.M."
DMI string baseboard-manufacturer: " "
DMI string baseboard-product-name: "ALiveNF5-eSATA2+ "
DMI string baseboard-version: " "
DMI string chassis-type: "Desktop"
Found chipset "NVIDIA MCP65" with PCI ID 10de:0441.
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... This chipset is not really supported yet.
Guesswork...
ISA/LPC bridge reg 0x8a contents: 0x00, bit 6 is 0, bit 5 is 0
Flash bus type is LPC
Found SMBus device 10de:0446 at 00:01:1
MCP SPI BAR is at 0x00000000
MCP SPI is not used.
Please send the output of "flashrom -V" to flashrom(a)flashrom.org with
your board name: flashrom -V as the subject to help us finish support
for your
chipset. Thanks.
OK.
This chipset supports the following protocols: LPC.
Probing for AMIC A49LF040A, 512 kB: probe_jedec_common: id1 0xda, id2 0x54
Probing for PMC Pm49FL002, 256 kB: probe_jedec_common: id1 0xda, id2 0x54
Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0xda, id2 0x54
Probing for SST SST49LF020, 256 kB: probe_jedec_common: id1 0xda, id2 0x54
Probing for SST SST49LF020A, 256 kB: probe_jedec_common: id1 0xda, id2 0x54
Probing for SST SST49LF040, 512 kB: probe_jedec_common: id1 0xda, id2 0x54
Probing for SST SST49LF040B, 512 kB: probe_jedec_common: id1 0xda, id2 0x54
Probing for SST SST49LF080A, 1024 kB: Chip lacks correct probe timing
information, using default 10mS/40uS. probe_jedec_common: id1 0xff, id2
0xff, id1 parity violation, id1 is normal flash content, id2 is normal
flash content
Probing for SST SST49LF160C, 2048 kB: probe_82802ab: id1 0xff, id2 0xff,
id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for ST M50FLW040A, 512 kB: probe_82802ab: id1 0xff, id2 0xff,
id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0xff, id2 0xff,
id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for ST M50FLW080A, 1024 kB: probe_82802ab: id1 0xff, id2 0xff,
id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for ST M50FLW080B, 1024 kB: probe_82802ab: id1 0xff, id2 0xff,
id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for ST M50LPW116, 2048 kB: probe_82802ab: id1 0xff, id2 0xff,
id1 parity violation, id1 is normal flash content, id2 is normal flash
content
Probing for Winbond W39V040A, 512 kB: probe_jedec_common: id1 0xda, id2 0x54
Probing for Winbond W39V040B, 512 kB: probe_jedec_common: id1 0xda, id2 0x54
Found Winbond flash chip "W39V040B" (512 kB, LPC) at physical address
0xfff80000.
Lockout bits:
Hardware bootblock locking (#TBL) is not active.
Hardware remaining chip locking (#WP) is not active..
Probing for Winbond W39V040C, 512 kB: probe_jedec_common: id1 0xda, id2 0x54
Probing for Winbond W39V080A, 1024 kB: probe_jedec_common: id1 0xff, id2
0xff, id1 parity violation, id1 is normal flash content, id2 is normal
flash content
Probing for Winbond W49V002A, 256 kB: probe_jedec_common: id1 0xda, id2 0x54
===
This flash part has status UNTESTED for operations: WRITE
The test status of this chip may have been updated in the latest development
version of flashrom. If you are running the latest development version,
please email a report to flashrom(a)flashrom.org if any of the above
operations
work correctly for you with this flash part. Please include the flashrom
output with the additional -V option for all operations you tested (-V, -Vr,
-Vw, -VE), and mention which mainboard or programmer you tested.
Please mention your board in the subject line. Thanks for your help!
No operations were specified.
Restoring PCI config space for 00:01:0 reg 0x6d
Restoring PCI config space for 00:01:0 reg 0x90
Restoring PCI config space for 00:01:0 reg 0x8c
Restoring PCI config space for 00:01:0 reg 0x88