On Tue, 12 Aug 2014 17:01:42 -0600 Marc Jones marcj303@gmail.com wrote:
I tested this branch on CC2: https://github.com/stefanct/flashrom/tree/intel
See attached logs.
Flashrom views both chips as a single flash space.
Yes, because the Intel chipsets do not allow the chip select pin to be controlled by software directly. One has to use hardware sequencing and there it does not make much sense to separate the two (although we know the boundaries and could do so), or are there use cases for that in the wild? Like using the first chip for everything but the BIOS region and the second chip for the BIOS region only...?
What is the correct method for only updating a single descriptor area?
There is only one descriptor (area), but I presume you are meaning a region. Using a layout file allows to write only a part, but there are patches that extend the usage to other actions as well.
The second (i.e. write) log is more or less useless due to: "Warning: Chip content is identical to the requested image." Although it would be somewhat interesting... because the descriptor tells us that the flash chip has 256 B erase blocks, which is very improbable. Do you know which flash chips are mounted there? (The first one could be determined by forcing software sequencing via the -p internal:ich_spi_mode=swseq). I'd also like to see a -VV log (you could also use the -o <logfile> parameter ;) because with the flashrom prints more detailed information about the descriptor... and I think either the descriptor is wrong or they have changed something about the erase block sizes too... I need to verify that before committing.
On Wed, 13 Aug 2014 17:04:29 +0200 Stefan Tauner stefan.tauner@alumni.tuwien.ac.at wrote:
The second (i.e. write) log is more or less useless due to: "Warning: Chip content is identical to the requested image." Although it would be somewhat interesting... because the descriptor tells us that the flash chip has 256 B erase blocks, which is very improbable. Do you know which flash chips are mounted there? (The first one could be determined by forcing software sequencing via the -p internal:ich_spi_mode=swseq). I'd also like to see a -VV log (you could also use the -o <logfile> parameter ;) because with the flashrom prints more detailed information about the descriptor... and I think either the descriptor is wrong or they have changed something about the erase block sizes too... I need to verify that before committing.
The definition of the erase block sizes and the way flashrom accesses them is still the same on 7 series chipsets. The chipset allows to save two sets of configuration data for the two attached chips (in registers LVSCC and UVSCC), and a boundary that separates the two "lower" and "upper" regions (in register FPB).
"All attributes described in UVSCC must apply to all flash space equal to or above the FPBA, even if it spans between two separate flash parts." And since the FPBA is 0, flashrom uses the UVSCC bits to determine the characteristics of the whole address space.
This is from the CC2 log: 0xC4: 0x00800000 (LVSCC) LVSCC: BES=0x0, WG=0, WSR=0, WEWS=0, EO=0x0, VCL=1 0xC8: 0x00000000 (UVSCC) UVSCC: BES=0x0, WG=0, WSR=0, WEWS=0, EO=0x0, VCL=0 0xD0: 0x00000000 (FPB)
The only thing that is set is the bit that locks both VSCC registers (VCL in LVSCC; printing the same bit of the UVSCC is a bug in flashrom, which I have fixed locally already).
So, my conclusion is that the descriptor is not prepared for hwseq although the hardware configuration demands it. Maybe I am missing something...
On Wed, Aug 13, 2014 at 9:04 AM, Stefan Tauner stefan.tauner@alumni.tuwien.ac.at wrote:
On Tue, 12 Aug 2014 17:01:42 -0600 Marc Jones marcj303@gmail.com wrote:
I tested this branch on CC2: https://github.com/stefanct/flashrom/tree/intel
See attached logs.
Flashrom views both chips as a single flash space.
Yes, because the Intel chipsets do not allow the chip select pin to be controlled by software directly. One has to use hardware sequencing and there it does not make much sense to separate the two (although we know the boundaries and could do so), or are there use cases for that in the wild? Like using the first chip for everything but the BIOS region and the second chip for the BIOS region only...?
Yes, there are often cases where one device is the entire BIOS region and the other is for everything else. The Cougar Canyon 2 is this way.
What is the correct method for only updating a single descriptor area?
There is only one descriptor (area), but I presume you are meaning a region. Using a layout file allows to write only a part, but there are patches that extend the usage to other actions as well.
Yes, I meant region. A how-to on regions and layout files might be something helpful for the wiki.
The second (i.e. write) log is more or less useless due to: "Warning: Chip content is identical to the requested image." Although it would be somewhat interesting... because the descriptor tells us that the flash chip has 256 B erase blocks, which is very improbable. Do you know which flash chips are mounted there? (The first one could be determined by forcing software sequencing via the -p internal:ich_spi_mode=swseq). I'd also like to see a -VV log (you could also use the -o <logfile> parameter ;) because with the flashrom prints more detailed information about the descriptor... and I think either the descriptor is wrong or they have changed something about the erase block sizes too... I need to verify that before committing.
Switched to read, erase, and write with -VV -o for logs.
It looks like there is an erase block issue or ivy/pantherpoint. I have attached two different logs for that, 7472 and cc2. The devices are MX25L12805(D) and W25Q64.V as identified with flashrom dediprog.
testflashrom_ivypanther_7472.log testflashrom_ivypanther_cc2.log
The Rangeley and Bay Trail tests passed.
testflashrom_baytrail_mm.log testflashrom_rangely_mp.log
Marc
-- Kind regards/Mit freundlichen Grüßen, Stefan Tauner
-
Marc Jones -
Stefan Tauner