Icon: "nico.h@gmx.de: Split Adding/reviewing flash chips out of Development Guidelines"

2023-12-03T17:46:37Z

"nico.h@gmx.de: Split Adding/reviewing flash chips out of Development Guidelines"

New page

# Get the datasheet of the exact type of chip.
# Open <tt>flashchips.c</tt> and <tt>flashchips.h</tt>.
# First, find the best* IDs in the datasheet (*FIXME: this needs to be explained together with the probing somewhere else in detail) and check if the ID exists in <tt>flashchips.h</tt> already
#* If it does but is named after a different chip,
#*:then add a comment regarding the twin and continue by comparing the definition in <tt>flashchips.c</tt> with the datasheet of the twin/new chip as if you would add it but leave out the next step (see below). First you should change the <tt>.name</tt> to reflect the additional chip model (see other chips of naming examples). If you find significant* differences in the chips behavior you have found a so called evil twin (*judging the significance of a difference is quite hard and requires some understanding of flashprog behavior, examples of significant differences are: different sizes of blocks or different opcodes for operations). In that case copy the entry and continue to change that (don't forget to undo the previous changes before).
#* If it does and the name matches too,
#*:the chip is either already added or only the ID was added and you should use that define.
#* If it does not,
#*:then you should add it conforming to the standards/comments in the file.
#: Usually the chip IDs follow a simple scheme: They are all uppercase; first the manufacturer name (like for the manufacturer IDs on top of each paragraph in flashchips.h) followed by an underscore and then the chipname. The latter should in general equal the <tt>.name</tt>, with dots (and other disallowed characters) replaced by underscores. Shared chip IDs typically use the macro name that happened to be added first to flashprog (which is also probably the first one manufactured) and which usually matches the other chips of that series in flashchips.h.
# If possible copy an existing, similar entry in the giant array in <tt>flashchips.c</tt> or start a new one at the right position (according to the comment on top of the array)
# Add <tt>.vendor</tt>, <tt>.name</tt>, IDs selected as explained above and <tt>.total_size</tt>.
# <tt>.page_size</tt> is really hard. Please read this [http://www.flashrom.org/pipermail/flashrom/2013-April/010817.html long explanation], or ignore it for now and set it to <tt>256</tt>.
# We encode various features of flash chips in a bitmask named <tt>.feature_bits</tt>. The various possibilities can be found in <tt>flash.h</tt>.
# <tt>.tested</tt> is used to indicate if the code was tested to work with real hardware, its possible values are defined in <tt>flash.h</tt>. Without any tests it should be set to <tt>TEST_UNTESTED</tt>.
# <tt>.probe</tt> indicates which function is called to fetch IDs from the chip and to compare them with the ones in <tt>.manufacture_id</tt> and <tt>.model_id</tt>. This requires some knowledge or source reading. For most SPI flash chips <tt>probe_spi_rdid</tt> is the right one if the datasheets mentions <tt>0x9f</tt> as an identification/probing opcode.
# <tt>.probe_timing</tt> is only used for non-SPI chips. It indicates the delay after "enter/exit ID mode" commands in microseconds (see <tt>flash.h</tt> for special values).
# <tt>.block_erasers</tt> stores an array of pairs of erase functions (<tt>.block_erase</tt>) with their respective layout (<tt>.eraseblocks</tt>).
## <tt>.block_erase</tt> is similar to the probing function. You should at least check that the opcode named in the function name is matching the respective opcode in the datasheet.
## Two forms of <tt>.eraseblocks</tt> can be distinguished: symmetric and asymmetric layouts. Symmetric means that all blocks that can be erased by an opcode are sized equal. In that case a single range can define the whole layout (e.g. <tt>{4 * 1024, 256}</tt> means 256 blocks of 4 kB each). Asymmetric layouts on the other hand contain differently sized blocks, ordered by their base addresses (e.g. <tt>{{8 * 1024, 1}, {4 * 1024, 2}, {16 * 1024, 7}}</tt> describes a layout that starts with a single 8 kB block, followed by two 4 kB blocks and 7 16 kB blocks at the end).
# <tt>.printlock</tt> is a [http://www.flashrom.org/pipermail/flashrom/2011-May/006495.html misnomer to some extent]. It is misused not only to print (write) protected address ranges of the chip, but also to pretty print the values of the status register(s) - especially true for SPI chips. There are a lot of existing functions for that already and you should reuse one if possible. Comparing the description of the status register in the datasheet of an already supported chip with that of your chip can help to determine if you can reuse a printlock function.
# <tt>.unlock</tt> is called before flashprog wants to modify the chip's contents to disable possible write protections. It is tightly related to the <tt>.printlock</tt> function as it tries to change some of the bits displayed by <tt>.printlock</tt>.
# <tt>.write</tt> and <tt>.read</tt> are function pointers with the obvious meaning. Currently flashprog does only support a single function each. The one that is best supported by existing programmers should be used for now, but others should be noted in a comment if available.
# <tt>.voltage</tt> defines the upper and lower bounds of the supply voltage of the chip. If there are multiple chip models with different allowed voltage ranges, the [http://en.wikipedia.org/wiki/Intersection_(set_theory) intersection] should be used and an appropriate comment added.
# The write [http://www.flashrom.org/pipermail/flashrom/2013-April/010817.html granularity] can be expressed by the <tt>.gran</tt> field. If you think you need something else than the default (<tt>write_gran_256bytes</tt>) then you should definitely ask one of the regular flashprog hackers first. Possible values can be found in <tt>flash.h</tt>.

Adding and Reviewing new flash chips - Revision history

Icon: "nico.h@gmx.de: Split Adding/reviewing flash chips out of Development Guidelines"