[flashrom] [PATCH 1/3] Refine Flash Component descriptor handling.

[Marc Jones]

On Wed, Aug 13, 2014 at 9:04 AM, Stefan Tauner
<stefan.tauner at alumni.tuwien.ac.at> wrote:
> On Tue, 12 Aug 2014 17:01:42 -0600
> Marc Jones <marcj303 at 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



-- 
http://se-eng.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: intel_test_logs.tar.gz
Type: application/x-gzip
Size: 1013314 bytes
Desc: not available
URL: <http://www.flashrom.org/pipermail/flashrom/attachments/20140814/c1ff67b8/attachment.gz>