Re: [flashrom] report for Intel QM67 | Winbond W25Q64 ([PATCH] (not for merge) ichspi: print BFPR (BIOS Flash Primary Region Register))
On Tue, 16 Aug 2011 15:06:32 +0200 "Frei, Thomas (GE Germany)" Thomas.Frei@ge.com wrote:
hello thomas and thanks for your report!
sorry for the lengthy mail... especially because it does not contain a real solution yet, but maybe there will be one when we are done with this thread :)
the basic SPI interface of the 6 series intel chipsets is not different from the earlier series. they have changed a few things behind the curtain though, which we don't understand fully yet. that could be the cause here.
i beg to differ. there is a chipset protection in place, but we don't know how it works exactly. :)
good idea, because it most certainly will fail.
Please help me - I will provide you all information you will need.
that would be great, but i fear you just don't have the information we need, or if you do you would be violating an NDA. :)
i guess you are working on a prototype for GE? in general we try to detect laptops because we don't support them very well yet. please see http://flashrom.org/Laptops for details why we care to detect them. your DMI table seems to not indicate explicitly enough if it is a laptop or not. that is not necessarily a problem in general, i just wanted to mention it in case you are involved in the firmware design.
in case you know it, could you please tell us a bit about the hardware design regarding the chipset<->flash connection? main question: is the flash chip directly connected to the qm67? are there any (external) ECs involved?
that's actually a bug. intel has changed the meaning of the bits in the GCS *again*. i'll look into it. afaics it is cosmetic only on all chipsets except ICH7, so it is not a problem for you thomas.
this is the first sign of the real problem. FDV=1 means the descriptor in the flash is valid and FLOCKDN=1 means that we are restricted in changing most of the relevant SPI settings. this is (officially) required since at least ibex peak (5 series). alone, it is not a problem. FDOPSS=1 is an override bit (Flash Descriptor Override Pin-Strap Status), that is set by a hardware strap. is this accessible to you by a switch of some sort (e.g. jumper)?
0xffff comes from the FDOPSS=1 and (should) indicate that we are allowed to access all regions of the flash (read and write).
the following registers indicate no protected address regions either.
now the interesting part. let's repeat the output of the FREGs ordered by address range:
transaction err.@400000 so the first transaction after the bios region fails. not that this is also the first address that is not described by any FREG. i can't remember right now if this was ever a problem. my suspicion is that the chipset prohibits any access to addresses that are not mentioned/described by the FREGs. i have "only" two (retail) boards with intel chipsets for testing. both have the whole address range covered by the FREGs (but have other problems.. namely the known write protection by FRAP/PR*). i will need to look into this further (searching for other reports).
how big is the image you want to write? (it is obviously 8MB because else flashrom would not continue, but did you modify it and was it 4MB before?) are you able to write the flash with intel's tool (iirc it is called FIT) under windows/dos? do you have access to the firmware modules that are combined to the full image and can you modify the descriptor part? if so it would be interesting to see what happens when you increase the FREG1.limit bits from 0x003fffff to 0x007fffff so that the bios region covers the second half of the flash too (this can be done by modifying the descriptor afaik). if i am right this would allow flashrom to access the whole flash.
another thing you could test are my hardware sequencing patches posted to this list and also accessible via http://patchwork.coreboot.org/bundle/stefanct/hwseq/). but i doubt that hwseq will behave different from swseq in this case. OTOH it would be nice to confirm this.
if it is not too inconvenient i would like to see the verbose output of a flashrom version modified by the attached patch to output BFPR. this should be equal to FREG1 and therefor we do not print it normally. it will certainly not change the general behavior in your case, i just want to be sure we know every possible detail.
a workaround for your problem would be to change flashrom in a way that it does not try to access addresses > 0x003fffff. currently this is only possible while writing (see layout option in the manpage). so you would probably want to hardcode the limit in flashrom to solve the problem quickly but ugly.
On Wed, 17 Aug 2011 04:38:06 +0200 Stefan Tauner stefan.tauner@student.tuwien.ac.at wrote:
1 is the normal setting i.e. no override. i thought it was the other way around. so most probably it is not available to you... sorry.
Hi Stefan,
First of all: thank you for the quick response. Yes I work on a prototype from GE :-)
OK - now to your questions: - the flashchip is connected as follows: SPI_CLK + SPI_MOSI are connected via a FET_busswitch, and SPI_MISI is connected directly to the chipset. - I can use FPT.EXE from intel, and it successfully reads the content of the flashchip - but only 4MB!!! - the file, I got from the hardware development, that should be used here, also has 4MB!!!???
Best regards
Thomas
P.S.: Bist Du etwa ein Student an der TU Wien - sprichst Du also Deutsch?
-----Original Message----- From: Stefan Tauner [mailto:stefan.tauner@student.tuwien.ac.at] Sent: Mittwoch, 17. August 2011 04:38 To: Frei, Thomas (GE Germany) Cc: flashrom@flashrom.org Subject: Re: [flashrom] report for Intel QM67 | Winbond W25Q64 ([PATCH] (not for merge) ichspi: print BFPR (BIOS Flash Primary Region Register))
On Tue, 16 Aug 2011 15:06:32 +0200 "Frei, Thomas (GE Germany)" Thomas.Frei@ge.com wrote:
hello thomas and thanks for your report!
sorry for the lengthy mail... especially because it does not contain a real solution yet, but maybe there will be one when we are done with this thread :)
the basic SPI interface of the 6 series intel chipsets is not different from the earlier series. they have changed a few things behind the curtain though, which we don't understand fully yet. that could be the cause here.
i beg to differ. there is a chipset protection in place, but we don't know how it works exactly. :)
good idea, because it most certainly will fail.
Please help me - I will provide you all information you will need.
that would be great, but i fear you just don't have the information we need, or if you do you would be violating an NDA. :)
i guess you are working on a prototype for GE? in general we try to detect laptops because we don't support them very well yet. please see http://flashrom.org/Laptops for details why we care to detect them. your DMI table seems to not indicate explicitly enough if it is a laptop or not. that is not necessarily a problem in general, i just wanted to mention it in case you are involved in the firmware design.
in case you know it, could you please tell us a bit about the hardware design regarding the chipset<->flash connection? main question: is the flash chip directly connected to the qm67? are there any (external) ECs involved?
that's actually a bug. intel has changed the meaning of the bits in the GCS *again*. i'll look into it. afaics it is cosmetic only on all chipsets except ICH7, so it is not a problem for you thomas.
this is the first sign of the real problem. FDV=1 means the descriptor in the flash is valid and FLOCKDN=1 means that we are restricted in changing most of the relevant SPI settings. this is (officially) required since at least ibex peak (5 series). alone, it is not a problem. FDOPSS=1 is an override bit (Flash Descriptor Override Pin-Strap Status), that is set by a hardware strap. is this accessible to you by a switch of some sort (e.g. jumper)?
0xffff comes from the FDOPSS=1 and (should) indicate that we are allowed to access all regions of the flash (read and write).
the following registers indicate no protected address regions either.
now the interesting part. let's repeat the output of the FREGs ordered by address range:
transaction err.@400000 so the first transaction after the bios region fails. not that this is also the first address that is not described by any FREG. i can't remember right now if this was ever a problem. my suspicion is that the chipset prohibits any access to addresses that are not mentioned/described by the FREGs. i have "only" two (retail) boards with intel chipsets for testing. both have the whole address range covered by the FREGs (but have other problems.. namely the known write protection by FRAP/PR*). i will need to look into this further (searching for other reports).
how big is the image you want to write? (it is obviously 8MB because else flashrom would not continue, but did you modify it and was it 4MB before?) are you able to write the flash with intel's tool (iirc it is called FIT) under windows/dos? do you have access to the firmware modules that are combined to the full image and can you modify the descriptor part? if so it would be interesting to see what happens when you increase the FREG1.limit bits from 0x003fffff to 0x007fffff so that the bios region covers the second half of the flash too (this can be done by modifying the descriptor afaik). if i am right this would allow flashrom to access the whole flash.
another thing you could test are my hardware sequencing patches posted to this list and also accessible via http://patchwork.coreboot.org/bundle/stefanct/hwseq/). but i doubt that hwseq will behave different from swseq in this case. OTOH it would be nice to confirm this.
if it is not too inconvenient i would like to see the verbose output of a flashrom version modified by the attached patch to output BFPR. this should be equal to FREG1 and therefor we do not print it normally. it will certainly not change the general behavior in your case, i just want to be sure we know every possible detail.
a workaround for your problem would be to change flashrom in a way that it does not try to access addresses > 0x003fffff. currently this is only possible while writing (see layout option in the manpage). so you would probably want to hardcode the limit in flashrom to solve the problem quickly but ugly.
-- Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Hi,
I patched my flashrom an here is the output of the new code:
---snip--- 0x00: 0x03ff0200 (BFPR) 0x00200000-0x003fffff ---snip---
Is this, what you expected?
If I want to hack my flashrom: - will it be possible to read the flash, or only to write it? - where will I have to change and what exactly, to have the quick, dirty and ugly hack working? (I tried to search for "limit" and changed it to 0x3fffff and 0x7fffff - but nothing changed in behavior)
Best regards
Thomas
P.S.: I know Helge Wagner, he is a colleague of me, but he is very busy, because he is our local one man BIOS/UEFI department. His Boss told me, not to bother him.
-----Original Message----- From: Stefan Tauner [mailto:stefan.tauner@student.tuwien.ac.at] Sent: Mittwoch, 17. August 2011 04:38 To: Frei, Thomas (GE Germany) Cc: flashrom@flashrom.org Subject: Re: [flashrom] report for Intel QM67 | Winbond W25Q64 ([PATCH] (not for merge) ichspi: print BFPR (BIOS Flash Primary Region Register))
On Tue, 16 Aug 2011 15:06:32 +0200 "Frei, Thomas (GE Germany)" Thomas.Frei@ge.com wrote:
hello thomas and thanks for your report!
sorry for the lengthy mail... especially because it does not contain a real solution yet, but maybe there will be one when we are done with this thread :)
the basic SPI interface of the 6 series intel chipsets is not different from the earlier series. they have changed a few things behind the curtain though, which we don't understand fully yet. that could be the cause here.
i beg to differ. there is a chipset protection in place, but we don't know how it works exactly. :)
good idea, because it most certainly will fail.
Please help me - I will provide you all information you will need.
that would be great, but i fear you just don't have the information we need, or if you do you would be violating an NDA. :)
i guess you are working on a prototype for GE? in general we try to detect laptops because we don't support them very well yet. please see http://flashrom.org/Laptops for details why we care to detect them. your DMI table seems to not indicate explicitly enough if it is a laptop or not. that is not necessarily a problem in general, i just wanted to mention it in case you are involved in the firmware design.
in case you know it, could you please tell us a bit about the hardware design regarding the chipset<->flash connection? main question: is the flash chip directly connected to the qm67? are there any (external) ECs involved?
that's actually a bug. intel has changed the meaning of the bits in the GCS *again*. i'll look into it. afaics it is cosmetic only on all chipsets except ICH7, so it is not a problem for you thomas.
this is the first sign of the real problem. FDV=1 means the descriptor in the flash is valid and FLOCKDN=1 means that we are restricted in changing most of the relevant SPI settings. this is (officially) required since at least ibex peak (5 series). alone, it is not a problem. FDOPSS=1 is an override bit (Flash Descriptor Override Pin-Strap Status), that is set by a hardware strap. is this accessible to you by a switch of some sort (e.g. jumper)?
0xffff comes from the FDOPSS=1 and (should) indicate that we are allowed to access all regions of the flash (read and write).
the following registers indicate no protected address regions either.
now the interesting part. let's repeat the output of the FREGs ordered by address range:
transaction err.@400000 so the first transaction after the bios region fails. not that this is also the first address that is not described by any FREG. i can't remember right now if this was ever a problem. my suspicion is that the chipset prohibits any access to addresses that are not mentioned/described by the FREGs. i have "only" two (retail) boards with intel chipsets for testing. both have the whole address range covered by the FREGs (but have other problems.. namely the known write protection by FRAP/PR*). i will need to look into this further (searching for other reports).
how big is the image you want to write? (it is obviously 8MB because else flashrom would not continue, but did you modify it and was it 4MB before?) are you able to write the flash with intel's tool (iirc it is called FIT) under windows/dos? do you have access to the firmware modules that are combined to the full image and can you modify the descriptor part? if so it would be interesting to see what happens when you increase the FREG1.limit bits from 0x003fffff to 0x007fffff so that the bios region covers the second half of the flash too (this can be done by modifying the descriptor afaik). if i am right this would allow flashrom to access the whole flash.
another thing you could test are my hardware sequencing patches posted to this list and also accessible via http://patchwork.coreboot.org/bundle/stefanct/hwseq/). but i doubt that hwseq will behave different from swseq in this case. OTOH it would be nice to confirm this.
if it is not too inconvenient i would like to see the verbose output of a flashrom version modified by the attached patch to output BFPR. this should be equal to FREG1 and therefor we do not print it normally. it will certainly not change the general behavior in your case, i just want to be sure we know every possible detail.
a workaround for your problem would be to change flashrom in a way that it does not try to access addresses > 0x003fffff. currently this is only possible while writing (see layout option in the manpage). so you would probably want to hardcode the limit in flashrom to solve the problem quickly but ugly.
-- Kind regards/Mit freundlichen Grüßen, Stefan Tauner
-
Frei, Thomas (GE Germany) -
Stefan Tauner