flashrom

flashrom@flashrom.org

3 participants
9189 discussions

Re: [flashrom] ECS P4VXMS (V1.0A) - OK
by Stefan Tauner 30 Sep '11

30 Sep '11

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

1 0

Re: [flashrom] My first question...
by Marcos Felipe Rasia de Mello 30 Sep '11

30 Sep '11

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

1 0

ASRock ALiveNF5-eSATA2+: flashrom -V
by James 30 Sep '11

30 Sep '11

$ 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

1 0

My first question...
by Jorge Fernandez Monteagudo 30 Sep '11

30 Sep '11

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 Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o CONFIDENCIAL. Si no es vd. el destinatario indicado, queda notificado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. This message is intended exclusively for its addressee and may contain information that is CONFIDENTIAL and protected by professional privilege. If you are not the intended recipient you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited by law. If this message has been received in error, please immediately notify us via e-mail and delete it.

1 0

[patch] OSX universal binaries
by Mark Pustjens 29 Sep '11

29 Sep '11

Hi List, The included patch will cause flashrom to be built as a universal binary on osx. Included architectures are i386 and x86_64. Greetings/Groetjes Mark Pustjens -- Index: Makefile =================================================================== --- Makefile (revision 1450) +++ Makefile (working copy) @@ -43,9 +43,9 @@ STRIP_ARGS = -s endif ifeq ($(OS_ARCH), Darwin) -CPPFLAGS += -I/opt/local/include -I/opt/local/include -I/usr/local/include +CPPFLAGS += -arch i386 -arch x86_64 -I/opt/local/include -I/usr/local/include # DirectHW framework can be found in the DirectHW library. -LDFLAGS += -framework IOKit -framework DirectHW -L/opt/local/lib -L/usr/local/lib +LDFLAGS += -framework IOKit -framework DirectHW -L/usr/local/lib -arch i386 -arch x86_64 endif ifeq ($(OS_ARCH), FreeBSD) CPPFLAGS += -I/usr/local/include @@ -530,7 +530,7 @@ TAROPTIONS = $(shell LC_ALL=C tar --version|grep -q GNU && echo "--owner=root --group=root") %.o: %.c .features - $(CC) -MMD $(CFLAGS) $(CPPFLAGS) $(FEATURE_CFLAGS) $(SVNDEF) -o $@ -c $< + $(CC) $(CFLAGS) $(CPPFLAGS) $(FEATURE_CFLAGS) $(SVNDEF) -o $@ -c $< # Make sure to add all names of generated binaries here. # This includes all frontends and libflashrom.

1 0

Re: [flashrom] Results of -rV on an Asus A8V-E SE running Asus Bios 001
by Bernd Blaauw 28 Sep '11

28 Sep '11

Op 27-9-2011 23:16, David Pascoe-Deslauriers schreef: > This is from a Asus A8V-E SE running Asus Bios -01. > > root@valhalla:~# uname -a > Linux valhalla 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:07:13 UTC > 2011 x86_64 GNU/Linux > > root@valhalla:~# flashrom -r current-mb-bios.bin -V > flashrom v0.9.1-r946 If you're willing/able to test your board against already released version 0.9.4 or latest trunk revision, you might get lucky enough if your board was added meanwhile. Thanks for the report, hopefully developers can use it :)

1 0

bitfield checker
by Carl-Daniel Hailfinger 26 Sep '11

26 Sep '11

Not a patch, and unfinished... I'd be interested in results of non-gcc compilers and/or non-i386 platforms. Will rework this once I have some more spare time. Regards, Carl-Daniel -- http://www.hailfinger.org/

2 1

NVidia MCP73
by Koen Rousseau 24 Sep '11

24 Sep '11

1 0

Re: [flashrom] Macronix MX25L6445E
by Stefan Tauner 22 Sep '11

22 Sep '11

On Thu, 22 Sep 2011 09:40:22 +0200 "Wagner, Helge (GE Germany)" <Helge.Wagner(a)ge.com> wrote: > Hi all, > > did I miss your answer or didn't you write one yet? hello helge! our patch queue[1] is quite long and my summer work for flashrom made it even longer. your patch wont get lost, but it might take a while for it to be reviewed further and merged eventually, sorry. 1: http://patchwork.coreboot.org/project/flashrom/list/ -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] Macronix MX25L6445E
by Wagner, Helge (GE Germany) 22 Sep '11

22 Sep '11

Hi all, did I miss your answer or didn't you write one yet? Regards, Helge -----Original Message----- From: flashrom-bounces(a)flashrom.org [mailto:flashrom-bounces@flashrom.org] On Behalf Of Wagner, Helge (GE Germany) Sent: Dienstag, 19. Juli 2011 10:57 To: Stefan Reinauer; Carl-Daniel Hailfinger Cc: flashrom(a)flashrom.org Subject: Re: [flashrom] Macronix MX25L6445E Stefan, Did you use my latest patch (at http://www.flashrom.org/pipermail/flashrom/2011-June/007013.html )? Carl-Daniel, > >> To be sure that the spi_block_erase_20 works for both the MX25L6405 > >> and the MX25L6445E, we could change the block erase size from 64K > >> to 4K. This should work even for the MX25L6405, but with the side > >> effect of the erase taking longer than needed. This was the comment for my first try. > Sorry, but AFAICS this will cause chip corruption. To be exact, > specifying a too small eraseblock size (4 kB instead of 64 kB) means > that flashrom will walk the device in 4 kB blocks, erase each block > and write to it. Now if the actual erase block size is bigger than the > specified block size, you'll get this: And exactly because of that I have reworked the patch (see above). Regards, Helge -----Original Message----- From: Stefan Reinauer [mailto:stefan.reinauer@coreboot.org] Sent: Montag, 18. Juli 2011 23:49 To: Carl-Daniel Hailfinger Cc: Wagner, Helge (GE Germany); flashrom(a)flashrom.org Subject: Re: [flashrom] Macronix MX25L6445E * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> [110718 23:44]: > Am 18.07.2011 19:07 schrieb Stefan Reinauer: > > * Wagner, Helge (GE Intelligent Platforms) <Helge.Wagner(a)ge.com> [110527 15:46]: > > > >> To be sure that the spi_block_erase_20 works for both the MX25L6405 > >> and the MX25L6445E, we could change the block erase size from 64K > >> to 4K. This should work even for the MX25L6405, but with the side > >> effect of the erase taking longer than needed. > >> > >> > >> > >> Any comments? > >> > > > > works great for me! > > > > > >> Please find my patches included. > >> > >> Signed-off-by: Helge Wagner <helge.wagner(a)ge.com> > >> > > Acked-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> > > > > Sorry, but AFAICS this will cause chip corruption. To be exact, > specifying a too small eraseblock size (4 kB instead of 64 kB) means > that flashrom will walk the device in 4 kB blocks, erase each block > and write to it. Now if the actual erase block size is bigger than the > specified block size, you'll get this: Yes, I agree that changing the block erase size is risky. Good thing the patch does not change it, so it should be save to apply, plus it solves the problem. Stefan _______________________________________________ flashrom mailing list flashrom(a)flashrom.org http://www.flashrom.org/mailman/listinfo/flashrom

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom