Hi Daniel,
Here is verbose log about
SPI registers for reference.
Best Regards,
Hony
From:
Sent: Wednesday, August 11, 2010
11:23 PM
To: Carl-Daniel Hailfinger
Cc:
Subject: RE: [flashrom] Urgent:
Flash part would be destroied by flashrom 0.9.2 once manager application is
running.
Hi Daniel,
Thanks for your quick response. Please kindly see my answers with blue
texts as below and share you my experiments today.
I use AMD HDT hardware ICE to interrupt CPU for
examining data on physical address 0xFEC10000 ~ 0xFEC
Best regards,
Hony
From: Carl-Daniel Hailfinger
[mailto:c-d.hailfinger.devel.2006@gmx.net]
Sent: 2010/8/11 [星期三] 下午 09:05
To:
Cc:
Subject: Re: [flashrom] Urgent:
Flash part would be destroied by flashrom 0.9.2 once manager application is
running.
Hi Hony,
we will help you.
On 11.08.2010 04:27, Hony.Chiang@mic.com.tw wrote:
> I get the serious problem on flashrom 0.9.2 on our server systems. We
always have to run 3rd party manager application to call up flashrom for BIOS
upgrade.
Can you tell us the name of the manager application you are using?
UpdateXpress System Pack Installer through a graphical user
interface (GUI).
http://publib.boulder.ibm.com/infocenter/toolsctr/v1r0/index.jsp?topic=/uxspi/uspi_r_using_compare_update.html
> However, flashrom would be failed on “Verifying flash” step because some
of programmed data in flash part is different with ones in golden ROM image
file on random offset addresses. This defect occurs on Red Hat 5 x64, SLES 10
x64 and SLES 11 x64. If I run flashrom tool manually without this 3rd
application, it would always flash SPI part successfully.
This is good. It means that flashrom works fine if nothing else accesses
the flash chip.
> Due to the 3rd party application is confidential, it can not be provided
to you for defect reproduction.
>
>
> Q1: May I suspect that expected data that is written to mapped virtual
memory space by flashrom is overwritten or interfered by other process from 3rd
application before SPI host controller operates these data to SPI ROM?
>
> Q2: May I suspect that expected data that is written to mapped virtual
memory space by flashrom is not sync to physical memory space immediately when
SPI host controller operates these data to SPI ROM?
>
flashrom does not write to the mapped memory space of the flash chip on
SP5100. flashrom uses only the SPI host controller registers to
read/write. If any other software accesses (read or write) the mapped
memory space of the flash chip or the SPI host controller registers at
the same time, the SPI host controller registers will change in
unexpected ways. This can lead to corruption of the flash chip or
corruption of reads.
> Q3: In order to prevent other process to interfere /dev/mem, mapped
virtual memory space or physical memory space that flashrom uses, would you
have any idea or some slice codes to lock them during flashrom operation?
>
Locking under most operating systems is not mandatory, and this means
even if flashrom asks for a lock, all other applications can ignore the
lock. I don't know any application which does locking on /dev/mem
because that might interfere with X.org graphics and other software.
> Q4: Would you have any idea to trace the root cause interfered flashrom?
>
I wrote a patch which should be able to detect interference from other
applications. I will send it later once it is tested.
Thank you. I will try it to give
you more inputs.
> Verbose message:
> Programming flash done.
> COMPLETE.
> Verifying flash... VERIFY FAILED at 0x00017ca4! Expected=0xff, Read=0x25,
failed
> byte count from 0x00000000-0x003fffff: 0x
>
> Syntax:
> ./flashrom –w
>
> Hardware configuration:
> MB: AMD platform solution
>
> Flash part: ST M25P32
>
> NOS:
> Reg Hat 5 X86_X64
> SLES 10 X86_X64
> SLES 11 X86_X64
>
Could you please send the output of "flashrom -V" so I can check the
contents of some SP5100 registers? Thanks.
I will capture message with -V
parameter on my lab tomorrow, and will provide you output.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/