flashrom September 2011

flashrom@flashrom.org

41 participants
161 discussions

[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

summary from EPoX EP-8KRAI-X
by Ben Taylor 22 Sep '11

22 Sep '11

Hello, stefanct requested I send this summary. My motherboard is a EPoX EP-8KRAI-X with a Winbond W49F002UP12B bios chip (with sticker "DP1"). http://paste.flashrom.org/view.php?id=834 As you can see, my eeprom is not detected. My goal is to update my bios with EPoX's latest version. I could provide that rom and EpoX's manual pdf if that would help you. Thanks, Ben Taylor (MacGuges)

2 1

Re: [flashrom] ReportFlashrom
by Stefan Tauner 20 Sep '11

20 Sep '11

On Wed, 14 Sep 2011 21:48:57 +0800 Boris Klimenko <bdostuk(a)gmail.com> wrote: > DMI string system-manufacturer: "Gigabyte Technology Co., Ltd." > DMI string system-product-name: "P67A-UD3P" > DMI string system-version: " " > DMI string baseboard-manufacturer: "Gigabyte Technology Co., Ltd." > DMI string baseboard-product-name: "P67A-UD3P" > DMI string baseboard-version: "x.x" > DMI string chassis-type: "Desktop" > Found ITE Super I/O, ID 0x8728 on port 0x2e > Found chipset "Intel P67" with PCI ID 8086:1c46. > 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! Hello Boris, Thanks for your report! I have marked the chipset and mainboard as tested and will commit that later. There are two almost identical revisions of the mainboard (1.0 and 1.1). Just for the record... do you happen to know which version you got? Thanks. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

ECS P4VXMS (V1.0A) - OK
by Marcos Felipe Rasia de Mello 19 Sep '11

19 Sep '11

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

1 0

Re: [flashrom] [PATCH] Unsignify lengths and addresses in chip functions and structs
by Carl-Daniel Hailfinger 19 Sep '11

19 Sep '11

Am 23.08.2011 17:12 schrieb Stefan Tauner: > compile tested with gcc 4.4.5 and clang 2.8 I agree with the idea and support it. However, I don't know how supportable this is on 16 bit platforms with 16 bit int. We need at least 24 bits to handle flash addresses, and we could either create a new typedef chipoffset_t or specify uint32_t explicitly. I favor a new typedef because it will make auditing easier if we ever run on 16 bit programmers. > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> A comment about the typedef idea would be appreciated. Anyway, this is (even if you reject the explicit type idea) Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Regards, Carl-Daniel -- http://www.hailfinger.org/

2 3

← Newer
1
2
3
4
5
6
7
8
9
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom September 2011