flashrom Rangeley with WINDBOND25Q64

Hello,

I am testing flashrom on a Rangeley system using coreboot. The flash chip is W25Q64.V. I am using Stefan's refactored support for Baytrail/Rangeley:
https://github.com/stefanct/flashrom/tree/intel.

The read operation failed (log attached). Any suggestions to debug it would be appreciated!

Thanks,

Wen

PS:
Stefan - I finally got subscribed to the mailing list I think. My system was treating flashrom.org as spam initially. Thanks for responding my earlier email.

-----Original Message-----
From: "Stefan Tauner" 
Sent: Monday, August 11, 2014 6:22pm
To: "Wen Wang" 
Subject: Re: flashrom Rangeley/Baytrail

On Mon, 11 Aug 2014 12:20:15 -0400
"Wen Wang"  wrote:
> Hello Stefan,
>
> I am trying to test the flashrom patch for Rangeley and Baytrail. I read in
> your recent blog that you made some updates on top of Martin's patch.  I am
> very interested in trying your changes.  Is it enough if I pull your branch
> https://github.com/stefanct/flashrom/tree/intel? I have a Bayley Bay CRB and
> a mohonpeak equivalent system to try.

Hello,

using that branch is fine, yes. Good luck, hopefully you won't need
it :)
> PS:  I was trying to get onto the flashrom mailing list, but for some reason
> I never got through. So I have to send an email to you directly.

Maybe your server was not accepting mails from the flashrom host and
you never got subscribed therefore (the flashrom.org domain had
problems in the last weeks for some people which led to some servers
not accepting mails from the list). Anyway, you can always send mails
to the mailing list without being subscribed, we just have to moderate
them manually. Please do so with any logs you create, and optionally
you may wanna retry to subscribe...

[Stefan Tauner]

On Tue, 12 Aug 2014 12:15:53 -0400 (EDT)
[e-mail] wrote:
> 0x54: 0x000f0000 FREG0: Warning: Flash Descriptor region (0x00000000-0x0000ffff) is read-only.
> 0x58: 0x07ff0200 FREG1: BIOS region (0x00200000-0x007fffff) is read-write.

Hello Wen,

it seems like this bogus kind of descriptor layout becomes popular. Let
me explain in case you don't understand: The descriptor region in the
first 4kB of the flash chip - similar to a partition table - defines
(among other things) which parts of the flash chip are used for what
components. Usually all addresses of the flas chip are covered by this
but sometimes vendor forget to do this properly - or do have no use for
it.

The problem (for flashrom) is that the Intel SPI controllers forbid
accesses to addresses that are not covered by the descriptor regions - 
like 0x00010000 to 0x001FFFFF in this case, which is almost a quarter
of the flash chip - but flashrom tries to read the whole chip
nevertheless (for good reasons).

So flashrom works more or less as expected on that board as far as you
have tested it. That result is probably not very useful to you, but
fine with me for now... :)

If you want to be able to write to the BIOS region, you
will also need my layout patches (they are also on github), and also
set the read_all_first variable in doit() in flashrom.c to 0.
I'd welcome such further tests of course but please be prepared for
recovery if need be.

I have included Marc from Sage because I guess he may be able to tell
us about the reason for this.

[Rich Futyma]

Hi,

In addition to what Stefan described about ME descriptors, there is also
BIOS CNTL register, that if BIOS
enables it, you will not be able to write to flash using flashrom.

Refer to:

Intel® C600 Series Chipset and
Intel® X79 Express Chipset

BIOS_CNTL—BIOS Control Register
(LPC I/F—D31:F0)

---
Rich

On Tue, Aug 12, 2014 at 3:07 PM, Stefan Tauner <
[e-mail]> wrote:
> On Tue, 12 Aug 2014 12:15:53 -0400 (EDT)
> [e-mail] wrote:
> > 0x54: 0x000f0000 FREG0: Warning: Flash Descriptor region
>
> (0x00000000-0x0000ffff) is read-only.
> > 0x58: 0x07ff0200 FREG1: BIOS region (0x00200000-0x007fffff) is
>
> read-write.
>
> Hello Wen,
>
> it seems like this bogus kind of descriptor layout becomes popular. Let
> me explain in case you don't understand: The descriptor region in the
> first 4kB of the flash chip - similar to a partition table - defines
> (among other things) which parts of the flash chip are used for what
> components. Usually all addresses of the flas chip are covered by this
> but sometimes vendor forget to do this properly - or do have no use for
> it.
>
> The problem (for flashrom) is that the Intel SPI controllers forbid
> accesses to addresses that are not covered by the descriptor regions -
> like 0x00010000 to 0x001FFFFF in this case, which is almost a quarter
> of the flash chip - but flashrom tries to read the whole chip
> nevertheless (for good reasons).
>
> So flashrom works more or less as expected on that board as far as you
> have tested it. That result is probably not very useful to you, but
> fine with me for now... :)
>
> If you want to be able to write to the BIOS region, you
> will also need my layout patches (they are also on github), and also
> set the read_all_first variable in doit() in flashrom.c to 0.
> I'd welcome such further tests of course but please be prepared for
> recovery if need be.
>
> I have included Marc from Sage because I guess he may be able to tell
> us about the reason for this.
> --
> Kind regards/Mit freundlichen Grüßen, Stefan Tauner
>
> flashrom mailing list
> [e-mail]
> http://www.flashrom.org/mailman/listinfo/flashrom

CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited.  If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING.  Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina Corporation (or any of its subsidiaries), or any other person or entity.

[Marc Jones]

On Tue, Aug 12, 2014 at 3:07 PM, Stefan Tauner
 wrote:
> On Tue, 12 Aug 2014 12:15:53 -0400 (EDT)
> [e-mail] wrote:
> > 0x54: 0x000f0000 FREG0: Warning: Flash Descriptor region (0x00000000-0x0000ffff) is read-only.
> > 0x58: 0x07ff0200 FREG1: BIOS region (0x00200000-0x007fffff) is read-write.
>
> Hello Wen,
>
> it seems like this bogus kind of descriptor layout becomes popular. Let
> me explain in case you don't understand: The descriptor region in the
> first 4kB of the flash chip - similar to a partition table - defines
> (among other things) which parts of the flash chip are used for what
> components. Usually all addresses of the flas chip are covered by this
> but sometimes vendor forget to do this properly - or do have no use for
> it.
>
> The problem (for flashrom) is that the Intel SPI controllers forbid
> accesses to addresses that are not covered by the descriptor regions -
> like 0x00010000 to 0x001FFFFF in this case, which is almost a quarter
> of the flash chip - but flashrom tries to read the whole chip
> nevertheless (for good reasons).
>
> So flashrom works more or less as expected on that board as far as you
> have tested it. That result is probably not very useful to you, but
> fine with me for now... :)
>
> If you want to be able to write to the BIOS region, you
> will also need my layout patches (they are also on github), and also
> set the read_all_first variable in doit() in flashrom.c to 0.
> I'd welcome such further tests of course but please be prepared for
> recovery if need be.
>
> I have included Marc from Sage because I guess he may be able to tell
> us about the reason for this.

I recommend that you use and external programmer to re-write the
descriptor as you need for development. The coreboot ifdtool is
helpful for this. (someone want to post a how-to on the wiki?)

Marc
>