July 2013 - flashrom - mail.coreboot.org

Re: [flashrom] A quick hack to support AMD Family 16h SOC
by Stefan Tauner July 30, 2013

July 30, 2013

On Fri, 26 Jul 2013 12:28:48 -0700 Wei Hu <wei(a)aristanetworks.com> wrote: > On Fri, Jul 26, 2013 at 12:18 AM, Carl-Daniel Hailfinger > <c-d.hailfinger.devel.2006(a)gmx.net> wrote: > >> I'll give you modified patch a test tomorrow. > > > > Please note that I expect problems with my patch. Not all of the FIFO > > management has been changed, and this might be the cause of error > > messages. Updated patch with more debugging at the end of this mail. > > After changing the device ID to match 0x780e, your patch works for > both reading and writing. Writing is extremely slow though. I feel > like on this new FCH we should ditch the SB600 interface and > investigate the new programming interface. My current patch is more > like a band aid workaround. I plan to do that but for now it would be better than nothing, *but* this will break Hudson-2... I talked to Martin Roth from sage and he confirmed that although AMD changed PCI IDs with Hudson-1 the interface did only really change with Kabini/Temash. That explains also why Hudson-2 worked fine previously: http://marc.info/?l=flashrom&m=131853263731000 Wang Qing Pei has tested his Hudson patch too probably before sending it to us but I don't know which system he used exactly. I'll try to get the Hudson-2 datasheets, but ATM I don't have them. We need a way to distinguish Kabini from the rest... since it is a SoC, we could match the pci ids of the root complex (00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] Family 16h Processor Root Complex [1022:1536] in my case), but we would need to maintain that for future models... Martin told me that they just read if the new registers are (non-)0xff and infer from that if they need to use the new interface. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

3 2

[PATCH] Fix dediprog crash if usb_open() fails
by David Woodhouse July 30, 2013

July 30, 2013

Signed-off-by: David Woodhouse <David.Woodhouse(a)intel.com> --- Ick. You made me touch Subversion, even if only through 'git svn clone'. diff --git a/dediprog.c b/dediprog.c index fb95d10..2640808 100644 --- a/dediprog.c +++ b/dediprog.c @@ -884,6 +884,10 @@ int dediprog_init(void) msg_pdbg("Found USB device (%04x:%04x).\n", dev->descriptor.idVendor, dev->descriptor.idProduct); dediprog_handle = usb_open(dev); + if (!dediprog_handle) { + msg_perr("Could not open USB device: %s\n", usb_strerror()); + return 1; + } ret = usb_set_configuration(dediprog_handle, 1); if (ret < 0) { msg_perr("Could not set USB device configuration: %i %s\n", -- David Woodhouse Open Source Technology Centre David.Woodhouse(a)intel.com Intel Corporation

2 1

[commit] r1705 - trunk
by repository service July 30, 2013

July 30, 2013

Author: stefanct Date: Tue Jul 30 11:34:44 2013 New Revision: 1705 URL: http://flashrom.org/trac/flashrom/changeset/1705 Log: dediprog: Fix crash if usb_open() fails. Signed-off-by: David Woodhouse <David.Woodhouse(a)intel.com> Acked-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Modified: trunk/dediprog.c Modified: trunk/dediprog.c ============================================================================== --- trunk/dediprog.c Fri Jul 26 00:58:56 2013 (r1704) +++ trunk/dediprog.c Tue Jul 30 11:34:44 2013 (r1705) @@ -884,6 +884,10 @@ msg_pdbg("Found USB device (%04x:%04x).\n", dev->descriptor.idVendor, dev->descriptor.idProduct); dediprog_handle = usb_open(dev); + if (!dediprog_handle) { + msg_perr("Could not open USB device: %s\n", usb_strerror()); + return 1; + } ret = usb_set_configuration(dediprog_handle, 1); if (ret < 0) { msg_perr("Could not set USB device configuration: %i %s\n",

1 0

/dev/mem mmap failed : Operation not permitted
by WON-JUN SONG July 30, 2013

July 30, 2013

Hi. I tried to read the contents of BIOS via flashrom. the main board is TYAN s8230. when I executed read command (such as sudo ./flashrom -r backup.bin -p internal), the error message are below "Error accessing flash chip, 0x2000000 bytes at 0x00000000fe000000 /dev/mem mmap failed: Operation not permitted" this message is derived from "probe_flash()" function. I don't understand why this error message occurs? anyway I modified the source code to skip some vendors and chip which cause above error message. then another error message are below "Reading flash.. SB600 FIFO pointer corruption! Pointer is 0, wanted 3 Something else is accessing the flash chip and causes random corruption. Please stop all applications and drivers and IPMI which access the flash chip Read operation failed! FAILED" I dont understand why IPMI is related to flashing BIOS. thanks.

2 1

Re: [flashrom] E350M1 Winbond W25Q32BVAIG and bus pirate
by Stefan Tauner July 29, 2013

July 29, 2013

On Sun, 28 Jul 2013 23:47:40 +0200 Marek <mlf.conv(a)gmail.com> wrote: > It seems that both hold and write-protect should be connected to 3.3V > but I'm not sure how to achieve it with BP 3.6. Why? Just connect them to Vcc. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] E350M1 Winbond W25Q32BVAIG and bus pirate
by Stefan Tauner July 28, 2013

July 28, 2013

On Sun, 28 Jul 2013 21:45:01 +0200 Marek <mlf.conv(a)gmail.com> wrote: > Hi Stefan, > > thanks for your response, I checked that webpage but it seems that the > suggestions apply to chips while they're still "sitting on" motherboards > where as in my case the chip is pulled out and connected via Probe kit(no > modifications). They do, but most parts of it do apply as well to directly connected chips. Also... be sure to connect ALL (input) pins. http://flashrom.org/Bus_Pirate -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] E350M1 Winbond W25Q32BVAIG and bus pirate
by Stefan Tauner July 28, 2013

July 28, 2013

On Sun, 28 Jul 2013 20:28:25 +0200 Marek <mlf.conv(a)gmail.com> wrote: > Hi, > > I'd like to ask whether someone has got some experience with flashing a > Winbond W25Q32BVAIG found on a E350M1 Asrock board using flashrom > and Bus Pirate +Bus Pirate Probe kit. > Currently I'm getting the following message: > > Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI). Check your cabling and see some more details here: http://flashrom.org/ISP -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

E350M1 Winbond W25Q32BVAIG and bus pirate
by Marek July 28, 2013

July 28, 2013

Hi, I'd like to ask whether someone has got some experience with flashing a Winbond W25Q32BVAIG found on a E350M1 Asrock board using flashrom and Bus Pirate +Bus Pirate Probe kit. Currently I'm getting the following message: Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI). === This flash part has status NOT WORKING for operations: PROBE READ ERASE WRITE BP bootloader 4.4 firmware v6.1 flashrom v0.9.6.1-r1704 on Linux 3.9.11_1 (i686) thanks, Marek

1 0

MSI k9N6SGM-V (ms-7309)
by Joakim Junttila July 28, 2013

July 28, 2013

Hello! I was trying to update my bios with flashrom but ran into this and was told to mail you about it. http://pastebin.com/dFanGufc ------------------------------------------------------------------------ Regards, Joakim Junttila <http://pastebin.com/dFanGufc>

1 0

Re: [flashrom] Flashrom fails on write. P4 motherboard
by Stefan Tauner July 27, 2013

July 27, 2013

On Thu, 25 Jul 2013 20:23:32 +0200 san <san(a)plusnet.pl> wrote: > Just uploaded lspci -nn here: http://e-san.info/Flashrom-P4/lspci-nn.txt > How to lower GPIO by hand (before patch)? Ah I forgot... I need one verbose flag too for the final patch, so that we see the subsystem IDs too, sorry. So it should have been lspci -nnv. I have prepared a preliminary patch that should at least verify if the reverse engineering is correct, see the attachment. You can also set this somehow with pciset as you know, I am just not entirely sure about the exact commands. you would need to get the gpiobase first with setpci -s 00:1f.0 58.l (only bits 6-15 are the base address see datasheet) and then fetch the old value with setpci -s 0:1f.0 gpiobase+0x0c and set it with setpci -s 0:1f.0 gpiobase+0x0c=... I would rather just try the patch. :) Sometimes there happen errors while reverse engineering the code so it is possible that you actually need to raise the pin instead or that the pin number is off by one. If you are a bit into programming then I am sure you can figure out how to refine the patch if necessary, but we can help you too of course. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 3