FreeCalypso > hg > freecalypso-tools

comparison doc/Loadtool-flash-support @ 517:809829dbc58a

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
new flash support documented
author Mychaela Falconia <falcon@freecalypso.org>
date Sat, 01 Jun 2019 06:46:46 +0000
parents
children
comparison
equal deleted inserted replaced
516:8bdbae4c0e53 517:809829dbc58a
1 fc-loadtool is our tool for reading and writing the non-volatile flash memory
2 on all of our supported target devices, and the set of targets which it needs
3 to support keeps growing. Here are some of the challenges we have to deal with:
4
5 * Some Calypso board designs use AMD-style flash, others use Intel-style flash.
6 Initially we only supported AMD-style flash chips that were used in our first
7 targets (Openmoko GTA02 and Pirelli DP-L10), then we got other targets that
8 have Intel-style flash. So far we have not yet run into a case where both
9 kinds of flash can be encountered on the same target family, but our current
10 design supports this possibility.
11
12 * All Calypso devices which we currently support have flash chips with non-
13 uniform sector geometries, i.e., the area that would otherwise be the first
14 or the last sector is subdivided into smaller sectors (erase units). Both
15 "top boot" (small sectors at high addresses) and "bottom boot" (small sectors
16 at low addresses) geometries are found among our targets, as well as flashes
17 that have small sectors at both ends. The exact sector geometry needs to be
18 known to the flash manipulation tool in order to perform correct flash erase
19 and program operations.
20
21 * While most Calypso devices have a single flash chip providing a single bank
22 of flash (can be as small as 2 MiB or as big as 8 MiB), some of our targets
23 (our own FCDEV3B and the Pirelli DP-L10 phone from which the idea was copied)
24 provide two flash chip select banks of 8 MiB each. To make the matters even
25 more complicated, all of that flash is actually a single 16 MiB chip that has
26 two chip selects instead of one, specifically designed for processors like
27 our Calypso that can only address a maximum of 8 MiB per chip select.
28
29 * It is a fixed target property whether a given board is wired for only one
30 flash chip select or allows the possibility of dual-bank flash, and if a
31 second flash chip select is provided for, which Calypso chip select it is
32 wired to.
33
34 Given the existence of the CFI (Common Flash Interface) standard and the fact
35 that every flash chip we have encountered so far in a Calypso device does have
36 a readable CFI structure, one may naively think that the most sensible way to
37 support all of our possible flash configurations would be to read and parse the
38 CFI structure in a device-agnostic way (i.e., without special cases for specific
39 chip types) and thus support "everything". But here are the problems with this
40 simplistic approach:
41
42 * On boards that have 16 MiB of flash in a Spansion S71PL129J or S71PL129N chip,
43 it makes the most sense for us to treat this big flash as two separate banks
44 of 8 MiB each - but the CFI structure describes a single 16 MiB flash chip.
45
46 * AMD-style flashes with "top boot" geometries are among our repertoire of
47 devices to be supported, and they have their regions listed in the wrong order
48 in the CFI structure - one needs to look in the AMD-specific part outside of
49 the vendor-neutral geometry structure to see the true "top boot" geometry.
50
51 * Intel-style flashes with independent read/write partitions such that each
52 partition has its own status register and its own "read array" vs. "read SR"
53 state require special handling in our architecture, but autoconfiguring this
54 quirk agnostically from CFI seems too difficult to me, and I wouldn't trust
55 it.
56
57 Our previous architectural attempts
58 ===================================
59
60 Initially we only supported two flash chip types, Samsung K5A32xx_T (Openmoko
61 GTA02) and Spansion S71PL129N (Pirelli DP-L10) with strictly manual selection:
62 -h gta02 selected one and -h pirelli selected the other via hardware parameter
63 files. There was an ID check to prevent bogosity from wrong manual selection,
64 but no autodetection or autoconfiguration. Then we added Compal target support;
65 aside from Mot C155/156 which has partition quirks that were only discovered
66 much later, these phones have simple Intel-style flashes without any of the CFI
67 problems listed above, thus they were handled via CFI. Thus we had a hybrid
68 architecture: Openmoko, Pirelli and FCDEV3B targets were handled by way of
69 manual selection and ID checks to catch errors, whereas Compal targets were
70 handled by way of CFI-based autodetection and autoconfiguration.
71
72 Then it was discovered that the 8 MiB Intel-style flash on the D-Sample board
73 and on Mot C155/156 has partition quirks which our CFI-based autoconfiguration
74 (looking at vendor-agnostic geometry bits only) could not take care of, and the
75 solution was to move these targets from CFI-based autoconfiguration to the same
76 kind of fixed device selection and configuration as was used for AMD flashes.
77 At that point our flash handling architecture became a mess, and when I started
78 questioning how to extend it further as the need arises to support more
79 different flash chip types on a wide variety of Calypso targets, it became
80 clear that a redesign was needed.
81
82 Our current architecture
83 ========================
84
85 In our current architecture the only flash configuration that is indicated
86 statically in the hardware parameter files (selected with the -h option,
87 practically meaning predefined target configurations) is board wiring
88 information. There are 3 possibilities that can be configured:
89
90 flash single-4M base_addr -- wired for 1 bank of up to 4 MiB
91 flash single-8M base_addr -- wired for 1 bank of up to 8 MiB
92 flash dual-8M bank0_base bank1_base -- wired for 2 banks of up to 8 MiB each
93
94 Naturally the dual-8M configuration only makes sense for boards that are wired
95 with a provision for a second flash bank, in which case the second bank base
96 address will depend on the board wiring, i.e., which Calypso chip select it is.
97 (Bank 0 base address will normally be 0x03000000, i.e., the alternate nCS0
98 mapping that needs to be used when the boot ROM is mapped at 0.) The choice
99 between single-4M and single-8M needs to match whether or not the associated
100 init script includes a "w16 fffef006 0008" command to enable ADD22.
101
102 Beyond this board wiring configuration, the rest of flash support is based on a
103 hard-coded table of all supported devices (a table that can grow indefinitely)
104 plus autodetection amongst this supported set. In other words, fc-loadtool will
105 only operate on a given flash chip if it explicitly knows about that chip, but
106 the set of supported chips can be indefinitely extended without hitting
107 architectural barriers, and our autodetection logic will detect and handle any
108 supported chip on any board target.
109
110 Autodetection details
111 =====================
112
113 The flash chip autodetection operation proceeds as follows:
114
115 * A sequence of writes is done to put the chip into the Read ID mode,
116 equivalent to the following hypothetical C code with base_addr being an
117 integer:
118
119 *(volatile uint16_t *)(base_addr + 0xAAA) = 0xAA;
120 *(volatile uint16_t *)(base_addr + 0x554) = 0x55;
121 *(volatile uint16_t *)(base_addr + 0xAAA) = 0x90;
122
123 * 16-bit words at base_addr offsets of 0 and 2 (where the manufacturer and
124 device ID codes are expected to reside) are read, and this ID is looked up in
125 a table. If the ID code is not known, we give up and don't allow any flash
126 operations.
127
128 * For most ID codes, if we have found the code in our table, we know what device
129 we should expect. But before we go ahead and assume that the command set and
130 the geometry are as we think based on the ID code, we also do a CFI check.
131 Specifically, we put the flash chip into CFI query mode, read a defined set
132 of word locations (can be different for each chip type), and require these
133 words to match our compiled-in table. Thus we guard against the possibility
134 of some other flash chip having the same ID code (yes, there are known
135 instances of ID code reuse) but having a different geometry.
136
137 * Some ID codes receive more complex handling. Right now the only such case is
138 Spansion PL-J/PL-N flash. PL129J and PL129N flashes have different geometries
139 and thus must be distinguished, but they have exactly the same ID codes and
140 can only be distinguished by CFI. We have CFI match tables for PL129J and
141 for PL129N; we try to match the CFI bits provided by the chip against one
142 table first, and if it fails to match, we try the other. (As an optimization,
143 we try the PL129N table first, as the N flash is the one found in real-world
144 Pirelli DP-L10 specimen and used on our FCDEV3B.) If the CFI matches neither
145 table, we give up and don't allow any flash operations.
146
147 The end effect of this logic is that we err on the side of caution: we only
148 allow flash erase and program operations if we detect a flash chip which is
149 fully known to us and fully matches our expectations, with both the ID codes
150 and the CFI structure being as we expect.
151
152 Adding support for new flash chip types
153 =======================================
154
155 All supported flash devices are listed in the fldevs.c source module; new
156 devices that differ in geometry, command set or quirks need to be added there.
157 The description of each flash device in fldevs.c also includes the CFI table
158 that needs to matched to confirm the device in question. A different module
159 named flashid.c contains the autodetection function and the table of device ID
160 codes; the latter table always needs to be extended, sometimes adding an
161 entirely new device, othertimes adding a newly found ID code for some flash
162 chip that is fully equivalent to an already supported one in terms of geometry,
163 command set and relevant quirks.
164
165 What do you do if you are an end user (not a FreeCalypso developer) and you got
166 a Calypso device whose flash chip is not being recognized by fc-loadtool?
167 Answer: you send the output of the "flash id" command (contains ID codes) and a
168 dump of the CFI structure to Mother Mychaela for analysis. To make a dump of
169 the CFI structure, execute the following commands:
170
171 loadtool> w16 030000aa 98
172 loadtool> dump2bin 03000000 200 cfidump.bin
173
174 Handling of dual-bank 16 MiB flash chips
175 ========================================
176
177 The Calypso can only address a maximum of 8 MiB per chip select, thus 16 MiB or
178 larger flash chips with a single chip select cannot be used in Calypso board
179 designs. However, there are some special 16 MiB flash chips that present
180 themselves as two banks of 8 MiB each (even though the CFI structure describes
181 a single 16 MiB chip), and such flash chips are used on the Pirelli DP-L10 and
182 on our own FCDEV3B.
183
184 The flash handling architecture of fc-loadtool allows two banks to be configured
185 via a flash dual-8M setting in the hardware parameter file, and when that
186 configuration is used (-h fcfam and -h pirelli), the two banks are treated as
187 being entirely independent. All regular flash commands operate only on the main
188 bank, and a parallel set of flash2 commands operates on the secondary bank.
189 The autodetection logic and the resulting configuration are done independently
190 on each flash bank when it is first accessed, thus fc-loadtool would happily
191 handle two separate flash chips of different types, even though such arrangement
192 is not expected to occur in any Calypso device. But when a PL129J or PL129N
193 device is detected (the two dual-bank devices we currently support) on the
194 autodetection probe of either bank, the operating geometry is configured
195 appropriately based on which bank it is.
196
197 Primary flash bank mapping at 0x03000000
198 ========================================
199
200 When loadagent runs on the Calypso target controlled by fc-loadtool, the Calypso
201 boot ROM will usually be mapped at 0, thus the alternate nCS0 mapping at
202 0x03000000 needs to be used for flash access. However, the Calypso chip (all
203 versions we work with) has a little design bug in this part of the silicon:
204 this alternate nCS0 mapping at 0x03000000 works only when the debug visibility
205 bit in the API-RHEA control register (bit 6 in the FFFF:FB0E register) is set,
206 and does not work otherwise. This bit is initially set as the Calypso comes
207 out of reset, and on most platforms we gain loadtool access via the boot ROM,
208 hence the problem does not occur - but on Compal targets we gain loadtool
209 access either through Compal's bootloader or via tfc139, and in both cases
210 Compal's fw (either the full fw or the bootloader part) has already set the
211 register in question to the runtime operational value of 0x2A (unchanged from
212 TI's TCS211 reference fw), with the debug visibility bit cleared, hence the
213 0x03000000 flash mapping no longer works.
214
215 There are two possible solutions: we can write into the FFFF:FB10 register to
216 disable the boot ROM and use the "regular" flash mapping at 0, which is what we
217 used to do, or we can write into the FFFF:FB0E register and re-enable the debug
218 visibility mode. Right now we do the latter, allowing us to use the same
219 0x03000000 flash mapping on all targets for consistency.