Lines Matching refs:the
31 the particular license, please see the license text that is distributed with
32 the firmware.
44 In this document, the term 'microcode' refers to the sequence of 32-bit
45 integers that compose the actual QE microcode.
47 The term 'firmware' refers to a binary blob that contains the microcode as
50 1) describes the microcode's purpose
51 2) describes how and where to upload the microcode
52 3) specifies the values of various registers
62 disables the microcode) must be performed first.
64 QE microcode is uploaded using the following procedure:
66 1) The microcode is placed into I-RAM at a specific location, using the
69 2) The CERCR.CIR bit is set to 0 or 1, depending on whether the firmware
71 QEs with multiple RISC processors, such as the 8360. Splitting the I-RAM
75 3) The TIBCR trap registers are loaded with the addresses of the trap handlers
76 in the microcode.
78 4) The RSP.ECCR register is programmed with the value provided.
80 5) If necessary, device drivers that need the virtual traps and extended mode
85 These virtual traps are conditional branches in the microcode. These are
86 "soft" provisional introduced in the ROMcode in order to enable higher
88 being fixed in the RAM package utilizing they should be activated. This data
89 structure signals the microcode which of these virtual traps is active.
91 This structure contains 6 words that the application should copy to some
92 specific been defined. This table describes the structure.
120 which has an impact on the software drivers. Each bit has its own impact
121 and has special instructions for the s/w associated with it. This structure is
128 | | push command | given by the application, the software must |
134 | | RX INIT | command, the host must issue another special|
136 | | | following that re-issue the ATM RX INIT |
137 | | | command. (This makes the sequence of |
138 | | | initializing the ATM receiver a sequence of |
143 | 2 | Add/remove | Indicates that following the specific host |
145 | | validation | Table" used in Interworking setup, the user |
150 | 3 | General push | Indicates that the s/w has to initialize |
151 | | command | some pointers in the Ethernet thread pages |
154 | | | pointers is located in the software drivers.|
170 header file contains macros that define the microcode binary itself as well as
173 the need for a more portable format. This section defines that format.
175 Instead of distributing a header file, the microcode and related data are
176 embedded into a binary blob. This blob is passed to the qe_upload_firmware()
177 function, which parses the blob and performs everything necessary to upload
178 the microcode.
180 All integers are big-endian. See the comments for function
183 This structure supports versioning, where the version of the structure is
184 embedded into the structure itself. To ensure forward and backwards
185 compatibility, all versions of the structure must use the same 'qe_header'
186 structure at the beginning.
189 The 'length' field is the size, in bytes, of the entire structure,
190 including all the microcode embedded in it, as well as the CRC (if
193 The 'magic' field is an array of three bytes that contains the letters
197 The 'version' field is a single byte that indicates the version of this
198 structure. If the layout of the structure should ever need to be
199 changed to add support for additional types of microcode, then the
203 identifies the firmware.
205 The 'count' field indicates the number of 'microcode' structures. There
207 Therefore, this field also represents the number of RISC processors for this
210 The 'soc' structure contains the SOC numbers and revisions used to match
211 the microcode to the SOC itself. Normally, the microcode loader should
212 check the data in this structure with the SOC number and revisions, and
213 only upload the microcode if there's a match. However, this check is not
216 Although it is not recommended, you can specify '0' in the soc.model
219 The 'model' field is a 16-bit number that matches the actual SOC. The
220 'major' and 'minor' fields are the major and minor revision numbers,
221 respectively, of the SOC.
223 For example, to match the 8323, revision 1.0:
228 'padding' is necessary for structure alignment. This field ensures that the
232 impact on the device drivers. Each bit has its own impact and has special
233 instructions for the driver associated with it. This field is stored in
234 the QE library and available to any driver that calles qe_get_firmware_info().
237 virtual traps. As with 'extended_modes', this field is stored in the QE
242 'microcode' structure is for the first RISC, and so on.
248 for each of the 16 traps. If trap[i] is 0, then this particular
250 is written as-is to the TIBCR[i] register, so be sure to set the EN
253 'eccr' is the value to program into the ECCR register.
255 'iram_offset' is the offset into IRAM to start writing the
258 'count' is the number of 32-bit words in the microcode.
260 'code_offset' is the offset, in bytes, from the beginning of this
261 structure where the microcode itself can be found. The first
262 microcode binary should be located immediately after the 'microcode'
265 'major', 'minor', and 'revision' are the major, minor, and revision
266 version numbers, respectively, of the microcode. If all values are 0,
270 is an array, the 64-bit 'extended_modes' field needs to be aligned
271 on a 64-bit boundary, and this can only happen if the size of
275 After the last microcode is a 32-bit CRC. It can be calculated using
294 A Python program that creates firmware binaries from the header files normally