Project

General

Profile

Actions

Feature #364

closed

Feature #353: Release v1.3

Investigate whether clear_spi_id_cache() needs to be called before probing

Added by Anastasia Klimchuk over 2 years ago. Updated about 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Release prep
Target version:
Start date:
04/28/2022
Due date:
% Done:

100%

Estimated time:
Affected versions:
Needs backport to:
Affected hardware:
Affected OS:

Description

Currently clear_spi_id_cache() is only called in tests. Should it be also called for real, before probing?


Related links

WIP patch here https://review.coreboot.org/c/flashrom/+/62769 but needs some attention.

Actions #1

Updated by Edward . over 2 years ago

  • Assignee set to Edward .
  • Related links updated (diff)
Actions #2

Updated by Felix Singer about 2 years ago

  • Status changed from New to Response Needed
  • Target version changed from 1.3 to main

Hey David, could you look into this and explain what you wanted to do? That would be great :)

Actions #3

Updated by David Hendricks about 2 years ago

Felix Singer wrote in #note-2:

Hey David, could you look into this and explain what you wanted to do? That would be great :)

The original patch has some context in the commit message: https://chromium-review.googlesource.com/c/chromiumos/third_party/flashrom/+/313752/. Also, this patch is where the cache was introduced: https://chromium-review.googlesource.com/c/chromiumos/third_party/flashrom/+/35376

Wayyyy long ago, flashrom would call RDID/REMS for each chip in flashchips[] until a match was found. This resulted in significant time spent probing, especially for chips far down the list such as Windbond chips. Thus the cache was added so we only need to do RDID/REMS once.

The reason for clearing the cache is if you intend to do something that may change the value returned by RDID/REMS. The follow-up to chromium:313752 had to do with auto-detecting voltage when using an external programmer that can supply different voltages such as Dediprog SF100/SF600. The idea was to probe 1.8V chips first, then 3.3V chips. The steps went like this:

  1. Set external programmer voltage to 1.8V
  2. Do RDID/REMS. If a valid ID is returned, then we're done.
  3. Clear ID cache
  4. Set external programmer voltage to 3.3V
  5. Do RDID/REMS again and hope we get a valid ID this time.

I'm not sure how this sort of thing is handled nowadays. If there's a better probing algorithm now then please feel free to get rid of clear_spi_id_cache().

Actions #4

Updated by Anastasia Klimchuk about 2 years ago

David, thanks so much for the information!

Auto-detect voltage feature has been removed from chromium's dediprog programmer. The reason: there are some chips that allow probing at one voltage (lower) but expect a different voltage (higher) for reads/writes. For such cases, auto-detect feature would not work and even could maybe damage the chip.
Specifically, auto-detection was based on successful probing, and the same voltage would then be attempted for reads/writes.

If auto-detection in dediprog is the only feature that matters, then the answer to initial question seems to be "clear_spi_id_cache() is only needed for tests, and not for real". Which means, nothing to do for this ticket.

Actions #5

Updated by Anastasia Klimchuk about 2 years ago

  • Status changed from Response Needed to Resolved
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF