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
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
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.
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
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
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
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
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>
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
