README.arm-caches
1Disabling I-cache:
2- Set CONFIG_SYS_ICACHE_OFF
3
4Disabling D-cache:
5- Set CONFIG_SYS_DCACHE_OFF
6
7Enabling I-cache:
8- Make sure CONFIG_SYS_ICACHE_OFF is not set and call icache_enable().
9
10Enabling D-cache:
11- Make sure CONFIG_SYS_DCACHE_OFF is not set and call dcache_enable().
12
13Enabling Caches at System Startup:
14- Implement enable_caches() for your platform and enable the I-cache and
15 D-cache from this function. This function is called immediately
16 after relocation.
17
18Guidelines for Working with D-cache:
19
20Memory to Peripheral DMA:
21- Flush the buffer after the MPU writes the data and before the DMA is
22 initiated.
23
24Peripheral to Memory DMA:
25- Invalidate the buffer before starting the DMA. In case there are any dirty
26 lines from the DMA buffer in the cache, subsequent cache-line replacements
27 may corrupt the buffer in memory while the DMA is still going on. Cache-line
28 replacement can happen if the CPU tries to bring some other memory locations
29 into the cache while the DMA is going on.
30- Invalidate the buffer after the DMA is complete and before the MPU reads
31 it. This may be needed in addition to the invalidation before the DMA
32 mentioned above, because in some processors memory contents can spontaneously
33 come to the cache due to speculative memory access by the CPU. If this
34 happens with the DMA buffer while DMA is going on we have a coherency problem.
35
36Buffer Requirements:
37- Any buffer that is invalidated(that is, typically the peripheral to
38 memory DMA buffer) should be aligned to cache-line boundary both at
39 at the beginning and at the end of the buffer.
40- If the buffer is not cache-line aligned invalidation will be restricted
41 to the aligned part. That is, one cache-line at the respective boundary
42 may be left out while doing invalidation.
43- A suitable buffer can be alloced on the stack using the
44 ALLOC_CACHE_ALIGN_BUFFER macro.
45
46Cleanup Before Linux:
47- cleanup_before_linux() should flush the D-cache, invalidate I-cache, and
48 disable MMU and caches.
49- The following sequence is advisable while disabling d-cache:
50 1. dcache_disable() - flushes and disables d-cache
51 2. invalidate_dcache_all() - invalid any entry that came to the cache
52 in the short period after the cache was flushed but before the
53 cache got disabled.
54
README.arm-relocation
1To make relocation on arm working, the following changes are done:
2
3At arch level: add linker flag -pie
4
5 This causes the linker to generate fixup tables .rel.dyn and .dynsym,
6 which must be applied to the relocated image before transferring
7 control to it.
8
9 These fixups are described in the ARM ELF documentation as type 23
10 (program-base-relative) and 2 (symbol-relative)
11
12At cpu level: modify linker file and add a relocation and fixup loop
13
14 the linker file must be modified to include the .rel.dyn and .dynsym
15 tables in the binary image, and to provide symbols for the relocation
16 code to access these tables
17
18 The relocation and fixup loop must be executed after executing
19 board_init_f at initial location and before executing board_init_r
20 at final location.
21
22At board level:
23
24 dram_init(): bd pointer is now at this point not accessible, so only
25 detect the real dramsize, and store it in gd->ram_size. Bst detected
26 with get_ram_size().
27
28TODO: move also dram initialization there on boards where it is possible.
29
30 Setup of the bd_info dram bank info is done in the new function
31 dram_init_banksize() called after bd is accessible.
32
33At lib level:
34
35 Board.c code is adapted from ppc code
36
37* WARNING ** WARNING ** WARNING ** WARNING ** WARNING ** WARNING ** WARNING *
38
39Boards which are not fixed to support relocation will be REMOVED!
40
41-----------------------------------------------------------------------------
42
43For boards which boot from spl, it is possible to save one copy
44if CONFIG_TEXT_BASE == relocation address! This prevents that uboot code
45is copied again in relocate_code().
46
47example for the tx25 board booting from NAND Flash:
48
49a) cpu starts
50b) it copies the first page in nand to internal ram
51 (spl code)
52c) end executes this code
53d) this initialize CPU, RAM, ... and copy itself to RAM
54 (this bin must fit in one page, so board_init_f()
55 don;t fit in it ... )
56e) there it copy u-boot to CFG_SYS_NAND_U_BOOT_DST and
57 starts this image @ CFG_SYS_NAND_U_BOOT_START
58f) u-boot code steps through board_init_f() and calculates
59 the relocation address and copy itself to it
60
61If CONFIG_TEXT_BASE == relocation address, the copying of u-boot
62in f) could be saved.
63
64-----------------------------------------------------------------------------
65
66TODO
67
68- fill in struct bd_info infos (check)
69- adapt all boards
70
71- maybe adapt CONFIG_TEXT_BASE (this must be checked from board maintainers)
72 This *must* be done for boards, which boot from NOR flash
73
74 on other boards if CONFIG_TEXT_BASE = relocation baseaddr, this saves
75 one copying from u-boot code.
76
77- new function dram_init_banksize() is actual board specific. Maybe
78 we make a weak default function in arch/arm/lib/board.c ?
79
80-----------------------------------------------------------------------------
81
82Relocation with SPL (example for the tx25 booting from NAND Flash):
83
84- cpu copies the first page from NAND to 0xbb000000 (IMX_NFC_BASE)
85 and start with code execution on this address.
86
87- The First page contains u-boot code from drivers/mtd/nand/raw/mxc_nand_spl.c
88 which inits the dram, cpu registers, reloacte itself to CONFIG_SPL_TEXT_BASE and loads
89 the "real" u-boot to CFG_SYS_NAND_U_BOOT_DST and starts execution
90 @CFG_SYS_NAND_U_BOOT_START
91
92- This u-boot does no RAM init, nor CPU register setup. Just look
93 where it has to copy and relocate itself to this address. If
94 relocate address = CONFIG_TEXT_BASE (not the same, as the
95 CONFIG_SPL_TEXT_BASE from the spl code), then there is no need
96 to copy, just go on with bss clear and jump to board_init_r.
97
98-----------------------------------------------------------------------------
99
100How ELF relocations 23 and 2 work.
101
102TBC
103
104-------------------------------------------------------------------------------------
105
106Debugging u-boot in RAM:
107(example on the qong board)
108
109-----------------
110
111a) start debugger
112
113arm-linux-gdb u-boot
114
115[hs@pollux u-boot]$ arm-linux-gdb u-boot
116GNU gdb Red Hat Linux (6.7-2rh)
117Copyright (C) 2007 Free Software Foundation, Inc.
118License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
119This is free software: you are free to change and redistribute it.
120There is NO WARRANTY, to the extent permitted by law. Type "show copying"
121and "show warranty" for details.
122This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux".
123The target architecture is set automatically (currently arm)
124..
125(gdb)
126
127-----------------
128
129b) connect to target
130
131target remote bdi10:2001
132
133(gdb) target remote bdi10:2001
134Remote debugging using bdi10:2001
1350x8ff17f10 in ?? ()
136(gdb)
137
138-----------------
139
140c) discard symbol-file
141
142(gdb) symbol-file
143Discard symbol table from `/home/hs/celf/u-boot/u-boot'? (y or n) y
144No symbol file now.
145(gdb)
146
147-----------------
148
149d) load new symbol table:
150
151(gdb) add-symbol-file u-boot 0x8ff08000
152add symbol table from file "u-boot" at
153 .text_addr = 0x8ff08000
154(y or n) y
155Reading symbols from /home/hs/celf/u-boot/u-boot...done.
156(gdb) c
157Continuing.
158^C
159Program received signal SIGSTOP, Stopped (signal).
1600x8ff17f18 in serial_getc () at serial_mxc.c:192
161192 while (__REG(UART_PHYS + UTS) & UTS_RXEMPTY);
162(gdb)
163
164add-symbol-file u-boot 0x8ff08000
165 ^^^^^^^^^^
166 get this address from u-boot bdinfo command
167 or get it from gd->relocaddr in gdb
168
169 => bdinfo
170rch_number = XXXXXXXXXX
171boot_params = XXXXXXXXXX
172DRAM bank = XXXXXXXXXX
173-> start = XXXXXXXXXX
174-> size = XXXXXXXXXX
175ethaddr = XXXXXXXXXX
176ip_addr = XXXXXXXXXX
177baudrate = XXXXXXXXXX
178TLB addr = XXXXXXXXXX
179relocaddr = 0x8ff08000
180 ^^^^^^^^^^
181reloc off = XXXXXXXXXX
182irq_sp = XXXXXXXXXX
183sp start = XXXXXXXXXX
184FB base = XXXXXXXXXX
185
186or interrupt execution by any means and re-load the symbols at the location
187specified by gd->relocaddr -- this is only valid after board_init_f.
188
189(gdb) set $s = gd->relocaddr
190(gdb) symbol-file
191(gdb) add-symbol-file u-boot $s
192
193Now you can use gdb as usual :-)
194
README.armada-secureboot
1The trusted boot framework on Marvell Armada 38x
2================================================
3
4Contents:
5
61. Overview of the trusted boot
72. Terminology
83. Boot image layout
94. The secured header
105. The secured boot flow
116. Usage example
127. Work to be done
138. Bibliography
14
151. Overview of the trusted boot
16-------------------------------
17
18The Armada's trusted boot framework enables the SoC to cryptographically verify
19a specially prepared boot image. This can be used to establish a chain of trust
20from the boot firmware all the way to the OS.
21
22To achieve this, the Armada SoC requires a specially prepared boot image, which
23contains the relevant cryptographic data, as well as other information
24pertaining to the boot process. Furthermore, a eFuse structure (a
25one-time-writeable memory) need to be configured in the correct way.
26
27Roughly, the secure boot process works as follows:
28
29* Load the header block of the boot image, extract a special "root" public RSA
30 key from it, and verify its SHA-256 hash against a SHA-256 stored in a eFuse
31 field.
32* Load an array of code signing public RSA keys from the header block, and
33 verify its RSA signature (contained in the header block as well) using the
34 "root" RSA key.
35* Choose a code signing key, and use it to verify the header block (excluding
36 the key array).
37* Verify the binary image's signature (contained in the header block) using the
38 code signing key.
39* If all checks pass successfully, boot the image.
40
41The chain of trust is thus as follows:
42
43* The SHA-256 value in the eFuse field verifies the "root" public key.
44* The "root" public key verifies the code signing key array.
45* The selected code signing key verifies the header block and the binary image.
46
47In the special case of building a boot image containing U-Boot as the binary
48image, which employs this trusted boot framework, the following tasks need to
49be addressed:
50
511. Creation of the needed cryptographic key material.
522. Creation of a conforming boot image containing the U-Boot image as binary
53 image.
543. Burning the necessary eFuse values.
55
56(1) will be addressed later, (2) will be taken care of by U-Boot's build
57system (some user configuration is required, though), and for (3) the necessary
58data (essentially a series of U-Boot commands to be entered at the U-Boot
59command prompt) will be created by the build system as well.
60
61The documentation of the trusted boot mode is contained in part 1, chapter
627.2.5 in the functional specification [1], and in application note [2].
63
642. Terminology
65--------------
66
67 CSK - Code Signing Key(s): An array of RSA key pairs, which
68 are used to sign and verify the secured header and the
69 boot loader image.
70 KAK - Key Authentication Key: A RSA key pair, which is used
71 to sign and verify the array of CSKs.
72 Header block - The first part of the boot image, which contains the
73 image's headers (also known as "headers block", "boot
74 header", and "image header")
75 eFuse - A one-time-writeable memory.
76 BootROM - The Armada's built-in boot firmware, which is
77 responsible for verifying and starting secure images.
78 Boot image - The complete image the SoC's boot firmware loads
79 (contains the header block and the binary image)
80 Main header - The header in the header block containing information
81 and data pertaining to the boot process (used for both
82 the regular and secured boot processes)
83 Binary image - The binary code payload of the boot image; in this
84 case the U-Boot's code (also known as "source image",
85 or just "image")
86 Secured header - The specialized header in the header block that
87 contains information and data pertaining to the
88 trusted boot (also known as "security header")
89 Secured boot mode - A special boot mode of the Armada SoC in which secured
90 images are verified (non-secure images won't boot);
91 the mode is activated by setting a eFuse field.
92 Trusted debug mode - A special mode for the trusted boot that allows
93 debugging of devices employing the trusted boot
94 framework in a secure manner (untested in the current
95 implementation).
96Trusted boot framework - The ARMADA SoC's implementation of a secure verified
97 boot process.
98
993. Boot image layout
100--------------------
101
102+-- Boot image --------------------------------------------+
103| |
104| +-- Header block --------------------------------------+ |
105| | Main header | |
106| +------------------------------------------------------+ |
107| | Secured header | |
108| +------------------------------------------------------+ |
109| | BIN header(s) | |
110| +------------------------------------------------------+ |
111| | REG header(s) | |
112| +------------------------------------------------------+ |
113| | Padding | |
114| +------------------------------------------------------+ |
115| |
116| +------------------------------------------------------+ |
117| | Binary image + checksum | |
118| +------------------------------------------------------+ |
119+----------------------------------------------------------+
120
1214. The secured header
122---------------------
123
124For the trusted boot framework, a additional header is added to the boot image.
125The following data are relevant for the secure boot:
126
127 KAK: The KAK is contained in the secured header in the form
128 of a RSA-2048 public key in DER format with a length of
129 524 bytes.
130Header block signature: The RSA signature of the header block (excluding the
131 CSK array), created using the selected CSK.
132Binary image signature: The RSA signature of the binary image, created using
133 the selected CSK.
134 CSK array: The array of the 16 CSKs as RSA-2048 public keys in DER
135 format with a length of 8384 = 16 * 524 bytes.
136 CSK block signature: The RSA signature of the CSK array, created using the
137 KAK.
138
139NOTE: The JTAG delay, Box ID, and Flash ID header fields do play a role in the
140trusted boot process to enable and configure secure debugging, but they were
141not tested in the current implementation of the trusted boot in U-Boot.
142
1435. The secured boot flow
144------------------------
145
146The steps in the boot flow that are relevant for the trusted boot framework
147proceed as follows:
148
1491) Check if trusted boot is enabled, and perform regular boot if it is not.
1502) Load the secured header, and verify its checksum.
1513) Select the lowest valid CSK from CSK0 to CSK15.
1524) Verify the SHA-256 hash of the KAK embedded in the secured header.
1535) Verify the RSA signature of the CSK block from the secured header with the
154 KAK.
1556) Verify the header block signature (which excludes the CSK block) from the
156 secured header with the selected CSK.
1577) Load the binary image to the main memory and verify its checksum.
1588) Verify the binary image's RSA signature from the secured header with the
159 selected CSK.
1609) Continue the boot process as in the case of the regular boot.
161
162NOTE: All RSA signatures are verified according to the PKCS #1 v2.1 standard
163described in [3].
164
165NOTE: The Box ID and Flash ID are checked after step 6, and the trusted debug
166mode may be entered there, but since this mode is untested in the current
167implementation, it is not described further.
168
1696. Usage example
170----------------
171
172### Create key material
173
174To employ the trusted boot framework, cryptographic key material needs to be
175created. In the current implementation, two keys are needed to build a valid
176secured boot image: The KAK private key and a CSK private key (both have to be
1772048 bit RSA keys in PEM format). Note that the usage of more than one CSK is
178currently not supported.
179
180NOTE: Since the public key can be generated from the private key, it is
181sufficient to store the private key for each key pair.
182
183OpenSSL can be used to generate the needed files kwb_kak.key and kwb_csk.key
184(the names of these files have to be configured, see the next section on
185kwbimage.cfg settings):
186
187openssl genrsa -out kwb_kak.key 2048
188openssl genrsa -out kwb_csk.key 2048
189
190The generated files have to be placed in the U-Boot root directory.
191
192Alternatively, instead of copying the files, symlinks to the private keys can
193be placed in the U-Boot root directory.
194
195WARNING: Knowledge of the KAK or CSK private key would enable an attacker to
196generate secured boot images containing arbitrary code. Hence, the private keys
197should be carefully guarded.
198
199### Create/Modifiy kwbimage.cfg
200
201The Kirkwook architecture in U-Boot employs a special board-specific
202configuration file (kwbimage.cfg), which controls various boot image settings
203that are interpreted by the BootROM, such as the boot medium. The support the
204trusted boot framework, several new options were added to faciliate
205configuration of the secured boot.
206
207The configuration file's layout has been retained, only the following new
208options were added:
209
210 KAK - The name of the KAK RSA private key file in the U-Boot
211 root directory, without the trailing extension of ".key".
212 CSK - The name of the (active) CSK RSA private key file in the
213 U-Boot root directory, without the trailing extension of
214 ".key".
215 BOX_ID - The BoxID to be used for trusted debugging (a integer
216 value).
217 FLASH_ID - The FlashID to be used for trusted debugging (a integer
218 value).
219 JTAG_DELAY - The JTAG delay to be used for trusted debugging (a
220 integer value).
221 CSK_INDEX - The index of the active CSK (a integer value).
222SEC_SPECIALIZED_IMG - Flag to indicate whether to include the BoxID and FlashID
223 in the image (that is, whether to use the trusted debug
224 mode or not); no parameters.
225 SEC_BOOT_DEV - The boot device from which the trusted boot is allowed to
226 proceed, identified via a numeric ID. The tested values
227 are 0x34 = NOR flash, 0x31 = SDIO/MMC card; for
228 additional ID values, consult the documentation in [1].
229 SEC_FUSE_DUMP - Dump the "fuse prog" commands necessary for writing the
230 correct eFuse values to a text file in the U-Boot root
231 directory. The parameter is the architecture for which to
232 dump the commands (currently only "a38x" is supported).
233
234The parameter values may be hardcoded into the file, but it is also possible to
235employ a dynamic approach of creating a Autoconf-like kwbimage.cfg.in, then
236reading configuration values from Kconfig options or from the board config
237file, and generating the actual kwbimage.cfg from this template using Makefile
238mechanisms (see board/gdsys/a38x/Makefile as an example for this approach).
239
240### Set config options
241
242To enable the generation of trusted boot images, the corresponding support
243needs to be activated, and a index for the active CSK needs to be selected as
244well.
245
246Furthermore, eFuse writing support has to be activated in order to burn the
247eFuse structure's values (this option is just needed for programming the eFuse
248structure; production boot images may disable it).
249
250ARM architecture
251 -> [*] Build image for trusted boot
252 (0) Index of active CSK
253 -> [*] Enable eFuse support
254 [ ] Fake eFuse access (dry run)
255
256### Build and test boot image
257
258The creation of the boot image is done via the usual invocation of make (with a
259suitably set CROSS_COMPILE environment variable, of course). The resulting boot
260image u-boot-with-spl.kwb can then be tested, if so desired. The hdrparser from [5]
261can be used for this purpose. To build the tool, invoke make in the
262'tools/marvell/doimage_mv' directory of [5], which builds a stand-alone
263hdrparser executable. A test can be conducted by calling hdrparser with the
264produced boot image and the following (mandatory) parameters:
265
266./hdrparser -k 0 -t u-boot-with-spl.kwb
267
268Here we assume that the CSK index is 0 and the boot image file resides in the
269same directory (adapt accordingly if needed). The tool should report that all
270checksums are valid ("GOOD"), that all signature verifications succeed
271("PASSED"), and, finally, that the overall test was successful
272("T E S T S U C C E E D E D" in the last line of output).
273
274### Burn eFuse structure
275
276+----------------------------------------------------------+
277| WARNING: Burning the eFuse structure is a irreversible |
278| operation! Should wrong or corrupted values be used, the |
279| board won't boot anymore, and recovery is likely |
280| impossible! |
281+----------------------------------------------------------+
282
283After the build process has finished, and the SEC_FUSE_DUMP option was set in
284the kwbimage.cfg was set, a text file kwb_fuses_a38x.txt should be present in
285the U-Boot top-level directory. It contains all the necessary commands to set
286the eFuse structure to the values needed for the used KAK digest, as well as
287the CSK index, Flash ID and Box ID that were selected in kwbimage.cfg.
288
289Sequentially executing the commands in this file at the U-Boot command prompt
290will write these values to the eFuse structure.
291
292If the SEC_FUSE_DUMP option was not set, the commands needed to burn the fuses
293have to be crafted by hand. The needed fuse lines can be looked up in [1]; a
294rough overview of the process is:
295
296* Burn the KAK public key hash. The hash itself can be found in the file
297 pub_kak_hash.txt in the U-Boot top-level directory; be careful to account for
298 the endianness!
299* Burn the CSK selection, BoxID, and FlashID
300* Enable trusted boot by burning the corresponding fuse (WARNING: this must be
301 the last fuse line written!)
302* Lock the unused fuse lines
303
304The command to employ is the "fuse prog" command previously enabled by setting
305the corresponding configuration option.
306
307For the trusted boot, the fuse prog command has a special syntax, since the
308ARMADA SoC demands that whole fuse lines (64 bit values) have to be written as
309a whole. The fuse prog command itself allows lists of 32 bit words to be
310written at a time, but this is translated to a series of single 32 bit write
311operations to the fuse line, where the individual 32 bit words are identified
312by a "word" counter that is increased for each write.
313
314To work around this restriction, we interpret each line to have three "words"
315(0-2): The first and second words are the values to be written to the fuse
316line, and the third is a lock flag, which is supposed to lock the fuse line
317when set to 1. Writes to the first and second words are memoized between
318function calls, and the fuse line is only really written and locked (on writing
319the third word) if both words were previously set, so that "incomplete" writes
320are prevented. An exception to this is a single write to the third word (index
3212) without previously writing neither the first nor the second word, which
322locks the fuse line without setting any value; this is needed to lock the
323unused fuse lines.
324
325As an example, to write the value 0011223344556677 to fuse line 10, we would
326use the following command:
327
328fuse prog -y 10 0 00112233 44556677 1
329
330Here 10 is the fuse line number, 0 is the index of the first word to be
331written, 00112233 and 44556677 are the values to be written to the fuse line
332(first and second word) and the trailing 1 is the value for the third word
333responsible for locking the line.
334
335A "lock-only" command would look like this:
336
337fuse prog -y 11 2 1
338
339Here 11 is the fuse number, 2 is the index of the first word to be written
340(notice that we only write to word 2 here; the third word for fuse line
341locking), and the 1 is the value for the word we are writing to.
342
343WARNING: According to application note [4], the VHV pin of the SoC must be
344connected to a 1.8V source during eFuse programming, but *must* be disconnected
345for normal operation. The AN [4] describes a software-controlled circuit (based
346on a N-channel or P-channel FET and a free GPIO pin of the SoC) to achieve
347this, but a jumper-based circuit should suffice as well. Regardless of the
348chosen circuit, the issue needs to be addressed accordingly!
349
3507. Work to be done
351------------------
352
353* Add the ability to populate more than one CSK
354* Test secure debug
355* Test on Armada XP
356
3578. Bibliography
358---------------
359
360[1] ARMADA(R) 38x Family High-Performance Single/Dual CPU System on Chip
361 Functional Specification; MV-S109094-00, Rev. C; August 2, 2015,
362 Preliminary
363[2] AN-383: ARMADA(R) 38x Families Secure Boot Mode Support; MV-S302501-00
364 Rev. A; March 11, 2015, Preliminary
365[3] Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography
366 Specifications Version 2.1; February 2003;
367 https://www.ietf.org/rfc/rfc3447.txt
368[4] AN-389: ARMADA(R) VHV Power; MV-S302545-00 Rev. B; January 28, 2016,
369 Released
370[5] Marvell Armada 38x U-Boot support; November 25, 2015;
371 https://github.com/MarvellEmbeddedProcessors/u-boot-marvell
372
3732017-01-05, Mario Six <mario.six@gdsys.cc>
374
README.asn1
1ASN1
2====
3
4Abstract Syntax Notation One (or ASN1) is a standard by ITU-T and ISO/IEC
5and used as a description language for defining data structure in
6an independent manner.
7Any data described in ASN1 notation can be serialized (or encoded) and
8de-serialized (or decoded) with well-defined encoding rules.
9
10A combination of ASN1 compiler and ASN1 decoder library function will
11provide a function interface for parsing encoded binary into specific
12data structure:
131) define data structure in a text file (*.asn1)
142) define "action" routines for specific "tags" defined in (1)
153) generate bytecode as a C file (*.asn1.[ch]) from *.asn1 file
16 with ASN1 compiler (tools/asn1_compiler)
174) call a ASN1 decoder (asn1_ber_decoder()) with bytecode and data
18
19Usage of ASN1 compiler
20----------------------
21 asn1_compiler [-v] [-d] <grammar-file> <c-file> <hdr-file>
22
23 <grammar-file>: ASN1 input file
24 <c-file>: generated C file
25 <hdr-file>: generated include file
26
27Usage of ASN1 decoder
28---------------------
29 int asn1_ber_decoder(const struct asn1_decoder *decoder, void *context,
30 const unsigned char *data, size_t datalen);
31
32 @decoder: bytecode binary
33 @context: context for decoder
34 @data: data to be parsed
35 @datalen: size of data
36
37
38As of writing this, ASN1 compiler and decoder are used to implement
39X509 certificate parser, pcks7 message parser and RSA public key parser
40for UEFI secure boot.
41
README.atmel_mci
1How to use SD/MMC cards with Atmel SoCs having MCI hardware
2-----------------------------------------------------------
32010-08-16 Reinhard Meyer <reinhard.meyer@emk-elektronik.de>
4
5This is a new approach to use Atmel MCI hardware with the
6general MMC framework. Therefore it benefits from that
7framework's abilities to handle SDHC Cards and the ability
8to write blocks.
9
10- AT91SAM9XE512 (tested, will definitely work with XE128 and XE256)
11- AT91SAM9260 (not tested, but MCI is to AT91SAM9XE)
12- AT91SAM9G20 (not tested, should work)
13
14It should work with all other ATMEL devices that have MCI.
15
16The generic driver does NOT assign port pins to the MCI block
17nor does it start the MCI clock. This has to be handled in a
18board/SoC specific manner before the driver is initialized:
19
20example: this is added to at91sam9260_devices.c:
21
22#if defined(CONFIG_GENERIC_ATMEL_MCI)
23void at91_mci_hw_init(void)
24{
25 at91_set_a_periph(AT91_PIO_PORTA, 8, PUP); /* MCCK */
26#if defined(CONFIG_ATMEL_MCI_PORTB)
27 at91_set_b_periph(AT91_PIO_PORTA, 1, PUP); /* MCCDB */
28 at91_set_b_periph(AT91_PIO_PORTA, 0, PUP); /* MCDB0 */
29 at91_set_b_periph(AT91_PIO_PORTA, 5, PUP); /* MCDB1 */
30 at91_set_b_periph(AT91_PIO_PORTA, 4, PUP); /* MCDB2 */
31 at91_set_b_periph(AT91_PIO_PORTA, 3, PUP); /* MCDB3 */
32#else
33 at91_set_a_periph(AT91_PIO_PORTA, 7, PUP); /* MCCDA */
34 at91_set_a_periph(AT91_PIO_PORTA, 6, PUP); /* MCDA0 */
35 at91_set_a_periph(AT91_PIO_PORTA, 9, PUP); /* MCDA1 */
36 at91_set_a_periph(AT91_PIO_PORTA, 10, PUP); /* MCDA2 */
37 at91_set_a_periph(AT91_PIO_PORTA, 11, PUP); /* MCDA3 */
38#endif
39}
40#endif
41
42the board specific file need added:
43...
44#ifdef CONFIG_GENERIC_ATMEL_MCI
45# include <mmc.h>
46#endif
47...
48#ifdef CONFIG_GENERIC_ATMEL_MCI
49/* this is a weak define that we are overriding */
50int board_mmc_init(struct bd_info *bd)
51{
52 /* Enable clock */
53 at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9260_ID_MCI);
54 at91_mci_hw_init();
55
56 /* This calls the atmel_mci_init in gen_atmel_mci.c */
57 return atmel_mci_init((void *)AT91_BASE_MCI);
58}
59
60/* this is a weak define that we are overriding */
61int board_mmc_getcd(struct mmc *mmc)
62{
63 return !at91_get_gpio_value(CFG_SYS_MMC_CD_PIN);
64}
65
66#endif
67
68and the board definition files needs:
69
70/* SD/MMC card */
71#define CONFIG_GENERIC_ATMEL_MCI 1
72#define CONFIG_ATMEL_MCI_PORTB 1 /* Atmel XE-EK uses port B */
73#define CFG_SYS_MMC_CD_PIN AT91_PIN_PC9
74#define CONFIG_CMD_MMC 1
75
README.atmel_pmecc
1How to enable PMECC(Programmable Multibit ECC) for nand on Atmel SoCs
2-----------------------------------------------------------
32012-08-22 Josh Wu <josh.wu@atmel.com>
4
5The Programmable Multibit ECC (PMECC) controller is a programmable binary
6BCH(Bose, Chaudhuri and Hocquenghem) encoder and decoder. This controller
7can be used to support both SLC and MLC NAND Flash devices. It supports to
8generate ECC to correct 2, 4, 8, 12 or 24 bits of error per sector (512 or
91024 bytes) of data.
10
11Following Atmel AT91 products support PMECC.
12- AT91SAM9X25, X35, G25, G15, G35 (tested)
13- AT91SAM9N12 (not tested, Should work)
14
15As soon as your nand flash software ECC works, you can enable PMECC.
16
17To use PMECC in this driver, the user needs to set:
18 1. the PMECC correction error bits capability: CONFIG_PMECC_CAP.
19 It can be 2, 4, 8, 12 or 24.
20 2. The PMECC sector size: CONFIG_PMECC_SECTOR_SIZE.
21 It only can be 512 or 1024.
22
23Take 'configs/at91sam9x5ek_nandflash_defconfig' as an example, the board
24configuration file has the following entries:
25
26 CONFIG_PMECC_CAP=2
27 CONFIG_PMECC_SECTOR_SIZE=512
28 CONFIG_SPL_GENERATE_ATMEL_PMECC_HEADER=y
29
30How to enable PMECC header for direct programmable boot.bin
31-----------------------------------------------------------
322014-05-19 Andreas Bie��mann <andreas@biessmann.org>
33
34The usual way to program SPL into NAND flash is to use the SAM-BA Atmel tool.
35This however is often not usable when doing field updates. To be able to
36program a SPL binary into NAND flash we need to add the PMECC header to the
37binary before. Chapter '12.4.4.1 NAND Flash Boot: NAND Flash Detection' in
38sama5d3 SoC spec (as of 03. April 2014) defines how this PMECC header has to
39look like. In order to do so we have a new image type added to mkimage to
40generate this PMECC header and integrated this into the build process of SPL.
41
42To enable the generation of atmel PMECC header for SPL one needs to define
43CONFIG_SPL_GENERATE_ATMEL_PMECC_HEADER. The required parameters are taken from
44board configuration and compiled into the host tools atmel_pmecc_params. This
45tool will be called in build process to parametrize mkimage for atmelimage
46type. The mkimage tool has intentionally _not_ compiled in those parameters.
47
48The mkimage image type atmelimage also set the 6'th interrupt vector to the
49correct value. This feature can also be used to setup a boot.bin for MMC boot.
50
README.autoboot
1SPDX-License-Identifier: GPL-2.0+
2/*
3 * (C) Copyright 2001
4 * Dave Ellis, SIXNET, dge@sixnetio.com
5 *
6 */
7
8Using autoboot configuration options
9====================================
10
11The basic autoboot configuration options are documented in the main
12U-Boot README. See it for details. They are:
13
14 bootdelay
15 bootcmd
16 CONFIG_BOOTDELAY
17 CONFIG_BOOTCOMMAND
18
19Some additional options that make autoboot safer in a production
20product are documented here.
21
22Why use them?
23-------------
24
25The basic autoboot feature allows a system to automatically boot to
26the real application (such as Linux) without a user having to enter
27any commands. If any key is pressed before the boot delay time
28expires, U-Boot stops the autoboot process, gives a U-Boot prompt
29and waits forever for a command. That's a good thing if you pressed a
30key because you wanted to get the prompt.
31
32It's not so good if the key press was a stray character on the
33console serial port, say because a user who knows nothing about
34U-Boot pressed a key before the system had time to boot. It's even
35worse on an embedded product that doesn't have a console during
36normal use. The modem plugged into that console port sends a
37character at the wrong time and the system hangs, with no clue as to
38why it isn't working.
39
40You might want the system to autoboot to recover after an external
41configuration program stops autoboot. If the configuration program
42dies or loses its connection (modems can disconnect at the worst
43time) U-Boot will patiently wait forever for it to finish.
44
45These additional configuration options can help provide a system that
46boots when it should, but still allows access to U-Boot.
47
48What they do
49------------
50
51 CONFIG_BOOT_RETRY_TIME
52 CONFIG_BOOT_RETRY_MIN
53
54 "bootretry" environment variable
55
56 These options determine what happens after autoboot is
57 stopped and U-Boot is waiting for commands.
58
59 CONFIG_BOOT_RETRY_TIME must be defined to enable the boot
60 retry feature. If the environment variable "bootretry" is
61 found then its value is used, otherwise the retry timeout is
62 CONFIG_BOOT_RETRY_TIME. CONFIG_BOOT_RETRY_MIN is optional and
63 defaults to CONFIG_BOOT_RETRY_TIME. All times are in seconds.
64
65 If the retry timeout is negative, the U-Boot command prompt
66 never times out. Otherwise it is forced to be at least
67 CONFIG_BOOT_RETRY_MIN seconds. If no valid U-Boot command is
68 entered before the specified time the boot delay sequence is
69 restarted. Each command that U-Boot executes restarts the
70 timeout.
71
72 If CONFIG_BOOT_RETRY_TIME < 0 the feature is there, but
73 doesn't do anything unless the environment variable
74 "bootretry" is >= 0.
75
76 CONFIG_AUTOBOOT_KEYED
77 CONFIG_AUTOBOOT_KEYED_CTRLC
78 CONFIG_AUTOBOOT_PROMPT
79 CONFIG_AUTOBOOT_DELAY_STR
80 CONFIG_AUTOBOOT_STOP_STR
81
82 "bootdelaykey" environment variable
83 "bootstopkey" environment variable
84
85 These options give more control over stopping autoboot. When
86 they are used a specific character or string is required to
87 stop or delay autoboot.
88
89 Define CONFIG_AUTOBOOT_KEYED (no value required) to enable
90 this group of options. CONFIG_AUTOBOOT_DELAY_STR,
91 CONFIG_AUTOBOOT_STOP_STR or both should be specified (or
92 specified by the corresponding environment variable),
93 otherwise there is no way to stop autoboot.
94
95 CONFIG_AUTOBOOT_PROMPT is displayed before the boot delay
96 selected by CONFIG_BOOTDELAY starts. If it is not defined
97 there is no output indicating that autoboot is in progress.
98
99 Note that CONFIG_AUTOBOOT_PROMPT is used as the (only)
100 argument to a printf() call, so it may contain '%' format
101 specifications, provided that it also includes, sepearated by
102 commas exactly like in a printf statement, the required
103 arguments. It is the responsibility of the user to select only
104 such arguments that are valid in the given context. A
105 reasonable prompt could be defined as
106
107 #define CONFIG_AUTOBOOT_PROMPT \
108 "autoboot in %d seconds\n",bootdelay
109
110 If CONFIG_AUTOBOOT_DELAY_STR or "bootdelaykey" is specified
111 and this string is received from console input before
112 autoboot starts booting, U-Boot gives a command prompt. The
113 U-Boot prompt will time out if CONFIG_BOOT_RETRY_TIME is
114 used, otherwise it never times out.
115
116 If CONFIG_AUTOBOOT_STOP_STR or "bootstopkey" is specified and
117 this string is received from console input before autoboot
118 starts booting, U-Boot gives a command prompt. The U-Boot
119 prompt never times out, even if CONFIG_BOOT_RETRY_TIME is
120 used.
121
122 The string recognition is not very sophisticated. If a
123 partial match is detected, the first non-matching character
124 is checked to see if starts a new match. There is no check
125 for a shorter partial match, so it's best if the first
126 character of a key string does not appear in the rest of the
127 string.
128
129 The CONFIG_AUTOBOOT_KEYED_CTRLC #define allows for the boot
130 sequence to be interrupted by ctrl-c, in addition to the
131 "bootdelaykey" and "bootstopkey". Setting this variable
132 provides an escape sequence from the limited "password"
133 strings.
134
135 CONFIG_AUTOBOOT_ENCRYPTION
136
137 "bootstopkeysha256" environment variable
138
139 - Hash value of the input which unlocks the device and
140 stops autoboot.
141
142 This option allows a string to be entered into U-Boot to stop the
143 autoboot. The string itself is hashed and compared against the hash
144 in the environment variable 'bootstopkeysha256'. If it matches then
145 boot stops and a command-line prompt is presented.
146
147 This provides a way to ship a secure production device which can also
148 be accessed at the U-Boot command line.
149
150 CONFIG_RESET_TO_RETRY
151
152 (Only effective when CONFIG_BOOT_RETRY_TIME is also set)
153 After the countdown timed out, the board will be reset to restart
154 again.
155
156 CONFIG_AUTOBOOT_USE_MENUKEY
157 CONFIG_AUTOBOOT_MENUKEY
158
159 If this key is pressed to stop autoboot, then the commands in the
160 environment variable 'menucmd' will be executed before boot starts.
161 For example, 33 means "!" in ASCII, so pressing ! at boot would take
162 this action.
163
README.bcmns3
1BCMNS3 QSPI memory layout
2=========================
3
4BCMNS3 has total 8MB non-volatile SPI flash memory. It is used to store
5different images like fip.bin, nitro firmware, DDR shmo value and other backup
6images.
7
8Following is the QSPI flash memory layout.
9
10/* QSPI layout
11 * |---------------------------|->0x000000
12 * | |
13 * | |
14 * | fip.bin |
15 * | 2MB |
16 * | |
17 * ~ ~
18 * ~ ~
19 * | |
20 * | |
21 * | |
22 * |---------------------------|->0x200000
23 * | |
24 * | |
25 * | |
26 * | fip.bin (Mirror) |
27 * | 2MB |
28 * ~ ~
29 * ~ ~
30 * | |
31 * | |
32 * | |
33 * |---------------------------|->0x400000
34 * | |
35 * | Nitro NS3 Config |
36 * | 1.5M |
37 * | |
38 * ~ ~
39 * ~ ~
40 * | |
41 * |---------------------------|->0x580000
42 * | Nitro NS3 Config |
43 * | 1.5M |
44 * | (Mirror) |
45 * ~ ~
46 * ~ ~
47 * | |
48 * |---------------------------|->0x700000
49 * | Nitro NS3 bspd Config |
50 * | 64KB |
51 * ~ ~
52 * ~ ~
53 * | |
54 * |---------------------------|->0x710000
55 * | Nitro NS3 bspd Config |
56 * | 64KB |
57 * ~ (Mirror) ~
58 * ~ ~
59 * | |
60 * |---------------------------|->0x720000
61 * | SHMOO |
62 * | 64KB |
63 * | |
64 * ~ ~
65 * ~ ~
66 * |---------------------------|->0x730000
67 * | Meta Data |
68 * | 832KB |
69 * | |
70 * ~ ~
71 * ~ ~
72 * | |
73 * |---------------------------|
74 */
75
README.bitbangMII
1This patch rewrites the miiphybb ( Bit-banged MII bus driver ) in order to
2support an arbitrary number of mii buses. This feature is useful when your
3board uses different mii buses for different phys and all (or a part) of these
4buses are implemented via bit-banging mode.
5
6The driver requires that the following macros should be defined into the board
7configuration file:
8
9CONFIG_BITBANGMII - Enable the miiphybb driver
10CONFIG_BITBANGMII_MULTI - Enable the multi bus support
11
12If the CONFIG_BITBANGMII_MULTI is not defined, the board's config file needs
13to define at least the following macros:
14
15MII_INIT - Generic code to enable the MII bus (optional)
16MDIO_DECLARE - Declaration needed to access to the MDIO pin (optional)
17MDIO_ACTIVE - Activate the MDIO pin as out pin
18MDIO_TRISTATE - Activate the MDIO pin as input/tristate pin
19MDIO_READ - Read the MDIO pin
20MDIO(v) - Write v on the MDIO pin
21MDC_DECLARE - Declaration needed to access to the MDC pin (optional)
22MDC(v) - Write v on the MDC pin
23
24The previous macros make the driver compatible with the previous version
25(that didn't support the multi-bus).
26
27When the CONFIG_BITBANGMII_MULTI is also defined, the board code needs to fill
28the bb_miiphy_buses[] array with a record for each required bus and declare
29the bb_miiphy_buses_num variable with the number of mii buses.
30The record (struct bb_miiphy_bus) has the following fields/callbacks (see
31miiphy.h for details):
32
33char name[] - The symbolic name that must be equal to the MII bus
34 registered name
35int (*init)() - Initialization function called at startup time (just
36 before the Ethernet initialization)
37int (*mdio_active)() - Activate the MDIO pin as output
38int (*mdio_tristate)() - Activate the MDIO pin as input/tristate pin
39int (*set_mdio)() - Write the MDIO pin
40int (*get_mdio)() - Read the MDIO pin
41int (*set_mdc)() - Write the MDC pin
42int (*delay)() - Delay function
43void *priv - Private data used by board specific code
44
45The board code will look like:
46
47struct bb_miiphy_bus bb_miiphy_buses[] = {
48 { .name = "miibus#1", .init = b1_init, .mdio_active = b1_mdio_active, ... },
49 { .name = "miibus#2", .init = b2_init, .mdio_active = b2_mdio_active, ... },
50 ...
51};
52int bb_miiphy_buses_num = sizeof(bb_miiphy_buses) /
53 sizeof(bb_miiphy_buses[0]);
54
552009 Industrie Dial Face S.p.A.
56 Luigi 'Comio' Mantellini <luigi.mantellini@idf-hit.com>
57
README.bootcount
1.. SPDX-License-Identifier: GPL-2.0+
2
3Boot Count Limit
4================
5
6This is enabled by CONFIG_BOOTCOUNT_LIMIT.
7
8This allows to detect multiple failed attempts to boot Linux.
9
10After a power-on reset, the "bootcount" variable will be initialized to 1, and
11each reboot will increment the value by 1.
12
13If, after a reboot, the new value of "bootcount" exceeds the value of
14"bootlimit", then instead of the standard boot action (executing the contents of
15"bootcmd"), an alternate boot action will be performed, and the contents of
16"altbootcmd" will be executed.
17
18If the variable "bootlimit" is not defined in the environment, the Boot Count
19Limit feature is disabled. If it is enabled, but "altbootcmd" is not defined,
20then U-Boot will drop into interactive mode and remain there.
21
22It is the responsibility of some application code (typically a Linux
23application) to reset the variable "bootcount" to 0 when the system booted
24successfully, thus allowing for more boot cycles.
25
26CONFIG_BOOTCOUNT_EXT
27--------------------
28
29This adds support for maintaining boot count in a file on an EXT filesystem.
30The file to use is defined by:
31
32CONFIG_SYS_BOOTCOUNT_EXT_INTERFACE
33CONFIG_SYS_BOOTCOUNT_EXT_DEVPART
34CONFIG_SYS_BOOTCOUNT_EXT_NAME
35
36The format of the file is:
37
38==== =================
39type entry
40==== =================
41u8 magic
42u8 version
43u8 bootcount
44u8 upgrade_available
45==== =================
46
47To prevent unattended usage of "altbootcmd", the "upgrade_available" variable is
48used.
49If "upgrade_available" is 0, "bootcount" is not saved.
50If "upgrade_available" is 1, "bootcount" is saved.
51So a userspace application should take care of setting the "upgrade_available"
52and "bootcount" variables to 0, if the system boots successfully.
53This also avoids writing the "bootcount" information on all reboots.
54
README.boston
1MIPS Boston Development Board
2
3---------
4 About
5---------
6
7The MIPS Boston development board is built around an FPGA & 3 PCIe controllers,
8one of which is connected to an Intel EG20T Platform Controller Hub which
9provides most connectivity to the board. It is used during the development &
10testing of both new CPUs and the software support for them. It is essentially
11the successor of the older MIPS Malta board.
12
13--------
14 QEMU
15--------
16
17U-Boot can be run on a currently out-of-tree branch of QEMU with support for
18the Boston board added. This QEMU code can currently be found in the "boston"
19branch of git://git.linux-mips.org/pub/scm/paul/qemu.git and used like so:
20
21 $ git clone git://git.linux-mips.org/pub/scm/paul/qemu.git -b boston
22 $ cd qemu
23 $ ./configure --target-list=mips64el-softmmu
24 $ make
25 $ ./mips64el-softmmu/qemu-system-mips64el -M boston -m 2G \
26 -bios u-boot.bin -serial stdio
27
28Please note that QEMU will default to emulating the I6400 CPU which implements
29the MIPS64r6 ISA, and at the time of writing doesn't implement any earlier CPUs
30with support for the CPS features the Boston board relies upon. You will
31therefore need to configure U-Boot to build for MIPSr6 in order to obtain a
32binary that will work in QEMU.
33
34-------------
35 Toolchain
36-------------
37
38If building for MIPSr6 then you will need a toolchain including GCC 5.x or
39newer, or the Codescape toolchain available for download from Imagination
40Technologies:
41
42 http://codescape-mips-sdk.imgtec.com/components/toolchain/2015.06-05/
43
44The "IMG GNU Linux Toolchain" is capable of building for all current MIPS ISAs,
45architecture revisions & both endiannesses.
46
47--------
48 TODO
49--------
50
51 - AHCI support
52 - CPU driver
53 - Exception handling (+UHI?)
54 - Flash support
55 - IOCU support
56 - L2 cache support
57 - More general LCD display driver
58 - Multi-arch-variant multi-endian fat binary
59
README.cfi
1The common CFI driver provides this weak default implementation for
2flash_cmd_reset():
3
4static void __flash_cmd_reset(flash_info_t *info)
5{
6 /*
7 * We do not yet know what kind of commandset to use, so we issue
8 * the reset command in both Intel and AMD variants, in the hope
9 * that AMD flash roms ignore the Intel command.
10 */
11 flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
12 udelay(1);
13 flash_write_cmd(info, 0, 0, FLASH_CMD_RESET);
14}
15void flash_cmd_reset(flash_info_t *info)
16 __attribute__((weak,alias("__flash_cmd_reset")));
17
18Some flash chips seem to have trouble with this reset sequence.
19In this case, board-specific code can override this weak default
20version with a board-specific function.
21
22At the time of writing, there are two boards that define their own
23routine for this.
24
25First, the digsy_mtc board equipped with the M29W128GH from Numonyx
26needs this version to function properly:
27
28void flash_cmd_reset(flash_info_t *info)
29{
30 flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
31}
32
33In addition, the t3corp board defines the routine thusly:
34
35void flash_cmd_reset(flash_info_t *info)
36{
37 /*
38 * FLASH at address CFG_SYS_FLASH_BASE is a Spansion chip and
39 * needs the Spansion type reset commands. The other flash chip
40 * is located behind a FPGA (Xilinx DS617) and needs the Intel type
41 * reset command.
42 */
43 if (info->start[0] == CFG_SYS_FLASH_BASE)
44 flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
45 else
46 flash_write_cmd(info, 0, 0, FLASH_CMD_RESET);
47}
48
49see also:
50http://www.mail-archive.com/u-boot@lists.denx.de/msg24368.html
51
52
53Config Option
54
55 CONFIG_SYS_MAX_FLASH_SECT: Number of sectors available on Flash device
56
57 CONFIG_SYS_FLASH_CFI_WIDTH: Data-width of the flash device
58
59 CONFIG_CMD_FLASH: Enables Flash command library
60
61 CONFIG_FLASH_CFI_DRIVER: Enables CFI Flash driver
62
63 CONFIG_FLASH_CFI_MTD: Enables MTD frame work for NOR Flash devices
64
README.commands.itest
1A slow day today so here is a revised itest command with provisional
2support for comparing strings as well :-))
3
4Now table driven to allow the operators
5-eq, -ne, -lt, -gt, -le, -ge, ==, !=, <>, <, >, <=, >=
6
7Uses the expected command modifier for integer compares of width 1, 2 or
84 bytes of .b, .w, .l and the new modifer of .s for a string compare.
9String comparison is over the length of the shorter, this hopefully
10avoids missing terminators when using an indirect pointer.
11
12eg.
13if itest.l *40000 == 12345678 then; ....
14if itest.w *40000 != 1234 then; ....
15if itest.b *40000 >= 12 then; ....
16if itest.s *40000 -eq hello then; ....
17
README.commands.spl
1The spl command is used to export a boot parameter image to RAM. Later
2it may implement more functions connected to the SPL.
3
4SUBCOMMAND EXPORT
5To execute the command everything has to be in place as if bootm should be
6used. (kernel image, initrd-image, fdt-image etc.)
7
8export has two subcommands:
9 atags: exports the ATAGS
10 fdt: exports the FDT
11
12Call is:
13spl export <fdt|atags> [kernel_addr] [initrd_addr] [fdt_addr if fdt]
14
15
16TYPICAL CALL
17
18on OMAP3:
19nandecc hw
20nand read 0x82000000 0x280000 0x400000 /* Read kernel image from NAND*/
21spl export atags /* export ATAGS */
22nand erase 0x680000 0x20000 /* erase - one page */
23nand write 0x80000100 0x680000 0x20000 /* write the image - one page */
24
25call with FDT:
26nandecc hw
27nand read 0x82000000 0x280000 0x400000 /* Read kernel image from NAND*/
28tftpboot 0x80000100 devkit8000.dtb /* Read fdt */
29spl export fdt 0x82000000 - 0x80000100 /* export FDT */
30nand erase 0x680000 0x20000 /* erase - one page */
31nand write <adress shown by spl export> 0x680000 0x20000
32
README.console
1SPDX-License-Identifier: GPL-2.0+
2/*
3 * (C) Copyright 2000
4 * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arsenio@tin.it
5 */
6
7U-Boot console handling
8========================
9
10HOW THE CONSOLE WORKS?
11----------------------
12
13At system startup U-Boot initializes a serial console. When U-Boot
14relocates itself to RAM, all console drivers are initialized (they
15will register all detected console devices to the system for further
16use).
17
18If not defined in the environment, the first input device is assigned
19to the 'stdin' file, the first output one to 'stdout' and 'stderr'.
20
21You can use the command "coninfo" to see all registered console
22devices and their flags. You can assign a standard file (stdin,
23stdout or stderr) to any device you see in that list simply by
24assigning its name to the corresponding environment variable. For
25example:
26
27 setenv stdin serial <- To use the serial input
28 setenv stdout video <- To use the video console
29
30Do a simple "saveenv" to save the console settings in the environment
31and get them working on the next startup, too.
32
33HOW CAN I USE STANDARD FILE INTO THE SOURCES?
34---------------------------------------------
35
36You can use the following functions to access the console:
37
38* STDOUT:
39 putc (to put a char to stdout)
40 puts (to put a string to stdout)
41 printf (to format and put a string to stdout)
42
43* STDIN:
44 tstc (to test for the presence of a char in stdin)
45 getc (to get a char from stdin)
46
47* STDERR:
48 eputc (to put a char to stderr)
49 eputs (to put a string to stderr)
50 eprintf (to format and put a string to stderr)
51
52* FILE (can be 'stdin', 'stdout', 'stderr'):
53 fputc (like putc but redirected to a file)
54 fputs (like puts but redirected to a file)
55 fprintf (like printf but redirected to a file)
56 ftstc (like tstc but redirected to a file)
57 fgetc (like getc but redirected to a file)
58
59Remember that all FILE-related functions CANNOT be used before
60U-Boot relocation (done in 'board_init_r' in arch/*/lib/board.c).
61
62HOW CAN I USE STANDARD FILE INTO APPLICATIONS?
63----------------------------------------------
64
65Use the 'bd_mon_fnc' field of the bd_info structure passed to the
66application to do everything you want with the console.
67
68But REMEMBER that that will work only if you have not overwritten any
69U-Boot code while loading (or uncompressing) the image of your
70application.
71
72For example, you won't get the console stuff running in the Linux
73kernel because the kernel overwrites U-Boot before running. Only
74some parameters like the framebuffer descriptors are passed to the
75kernel in the high memory area to let the applications (the kernel)
76use the framebuffers initialized by U-Boot.
77
78SUPPORTED DRIVERS
79-----------------
80
81Working drivers:
82
83 serial (architecture dependent serial stuff)
84 video (mpc8xx video controller)
85
86Work in progress:
87
88 wl_kbd (Wireless 4PPM keyboard)
89
90Waiting for volounteers:
91
92 lcd (mpc8xx lcd controller; to )
93
94TESTED CONFIGURATIONS
95---------------------
96
97The driver has been tested with the following configurations (see
98CREDITS for other contact informations):
99
100- MPC823FADS with AD7176 on a PAL TV (YCbYCr) - arsenio@tin.it
101
README.davinci
1Summary
2=======
3
4Note: this document used to be about the entire family of DaVinci SOCs but the
5support for the DM* family and DA830 has since been dropped.
6
7This README is about U-Boot support for TI's DA850 SoC. This SOC has an OMAP
8part number but is very similar to the DaVinci series.
9
10Currently the following boards are supported:
11
12* TI DA850 EVM
13
14* TI OMAP-L138 LCDK
15
16* Lego EV3
17
18Build
19=====
20
21* TI DA850 EVM:
22
23make da850evm_config
24make
25
26* TI OMAP-L138 LCDK
27
28make omapl138_lcdk_defconfig
29make
30
31* Lego EV3
32
33make legoev3_defconfig
34make
35
36Bootloaders
37===============
38
39For DA850 an SPL (secondary program loader, see doc/README.SPL) is provided
40to load U-Boot from SPI flash, MMC or NAND. The SPL takes care of the low level
41initialization.
42
43The SPL is built as u-boot.ais for all DA850 defconfigs except those booting
44from NOR flash. The resulting image file can be programmed to the SPI flash
45of the DA850 EVM/LCDK.
46
47Devices that support booting from NOR utilize execute in place (XIP) and do
48not require SPL to perform low level initialization.
49
50Environment Variables
51=====================
52
53The DA850 EVM allows the user to specify the maximum cpu clock allowed by the
54silicon, in Hz, via an environment variable "maxcpuclk".
55
56The maximum clock rate allowed depends on the silicon populated on the EVM.
57Please make sure you understand the restrictions placed on this clock in the
58device specific datasheet before setting up this variable. This information is
59passed to the Linux kernel using the ATAG_REVISION atag.
60
61If "maxcpuclk" is not defined, the configuration CFG_DA850_EVM_MAX_CPU_CLK
62is used to obtain this information.
63
64Links
65=====
66
671) TI DA850 EVM
68http://focus.ti.com/docs/prod/folders/print/omap-l138.html
69http://www.logicpd.com/products/development-kits/zoom-omap-l138-evm-development-kit
70
712) TI OMAP-L138 LCDK
72http://focus.ti.com/docs/prod/folders/print/omap-l138.html
73https://www.ti.com/tool/TMDXLCDK138
74
75Davinci special defines
76=======================
77
78CFG_SYS_DV_NOR_BOOT_CFG: AM18xx based boards, booting in NOR Boot mode
79 need a "NOR Boot Configuration Word" stored
80 in the NOR Flash. This define adds this.
81 More Info about this, see:
82 spraba5a.pdf chapter 3.1
83
README.davinci.nand_spl
1With this approach, we don't need the UBL any more on DaVinci boards.
2A "make boardname" will compile a u-boot.ubl, with UBL Header, which is
3needed for the RBL to find the "UBL", which actually is a UBL-compatible
4header, nand spl code and u-boot code.
5
6
7As the RBL uses another read function as the "standard" u-boot,
8we need a command, which switches between this two read/write
9functions, so we can write the UBL header and the spl
10code in a format, which the RBL can read. This is realize
11(at the moment in board specific code) in the u-boot command
12nandrbl
13
14nandrbl without arguments returns actual mode (rbl or uboot).
15with nandrbl mode (mode = "rbl" or "uboot") you can switch
16between the two NAND read/write modes.
17
18
19To set up mkimage you need a config file for mkimage, example:
20board/ait/cam_enc_4xx/ublimage.cfg
21
22For information about the configuration please see:
23doc/README.ublimage
24
25Example for the cam_enc_4xx board:
26On the cam_enc_4xx board we have a NAND flash with blocksize = 0x20000 and
27pagesize = 0x800, so the u-boot.ubl image (which you get with:
28"make cam_enc_4xx") looks like this:
29
3000000000 00 ed ac a1 20 00 00 00 06 00 00 00 05 00 00 00 |.... ...........|
3100000010 00 00 00 00 20 00 00 00 ff ff ff ff ff ff ff ff |.... ...........|
3200000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
33*
3400000800 14 00 00 ea 14 f0 9f e5 10 f0 9f e5 0c f0 9f e5 |................|
3500000810 08 f0 9f e5 04 f0 9f e5 00 f0 9f e5 04 f0 1f e5 |................|
3600000820 00 01 00 00 78 56 34 12 78 56 34 12 78 56 34 12 |....xV4.xV4.xV4.|
37[...]
38*
3900001fe0 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff |................|
4000001ff0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
41*
4200003800 14 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................|
4300003810 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................|
4400003820 80 01 08 81 e0 01 08 81 40 02 08 81 a0 02 08 81 |........@.......|
45
46In the first "page" of the image, we have the UBL Header, needed for
47the RBL to find the spl code.
48
49The spl code starts in the second "page" of the image, with a size
50defined by:
51
52#define CONFIG_SYS_NROF_PAGES_NAND_SPL 6
53
54After the spl code, there comes the "real" u-boot code
55@ (6 + 1) * pagesize = 0x3800
56
57------------------------------------------------------------------------
58Setting up spl code:
59
60/*
61 * RBL searches from Block n (n = 1..24)
62 * so we can define, how many UBL Headers
63 * we write before the real spl code
64 */
65#define CONFIG_SYS_NROF_UBL_HEADER 5
66#define CONFIG_SYS_NROF_PAGES_NAND_SPL 6
67
68#define CONFIG_SYS_NAND_U_BOOT_OFFS ((CONFIG_SYS_NROF_UBL_HEADER * \
69 CONFIG_SYS_NAND_BLOCK_SIZE) + \
70 (CONFIG_SYS_NROF_PAGES_NAND_SPL) * \
71 CONFIG_SYS_NAND_PAGE_SIZE)
72------------------------------------------------------------------------
73
74Burning into NAND:
75
76step 1:
77The RBL searches from Block n ( n = 1..24) on page 0 for valid UBL
78Headers, so you have to burn the UBL header page from the u-boot.ubl
79image to the blocks, you want to have the UBL header.
80!! Don;t forget to switch to rbl nand read/write functions with
81 "nandrbl rbl"
82
83step 2:
84You need to setup in the ublimage.cfg, where the RBL can find the spl
85code, and how big it is.
86
87!! RBL always starts reading from page 0 !!
88
89For the AIT board, we have:
90PAGES 6
91START_BLOCK 5
92
93So we need to copy the spl code to block 5 page 0
94!! Don;t forget to switch to rbl nand read/write functions with
95 "nandrbl rbl"
96
97step 3:
98You need to copy the u-boot image to the block/page
99where the spl code reads it (CONFIG_SYS_NAND_U_BOOT_OFFS)
100!! Don;t forget to switch to rbl nand read/write functions with
101 "nandrbl uboot", which is default.
102
103On the cam_enc_4xx board it is:
104#define CONFIG_SYS_NAND_U_BOOT_OFFS (0xc0000)
105
106-> this results in following NAND usage on the cam_enc_4xx board:
107
108addr
109
11020000 possible UBL Header
11140000 possible UBL Header
11260000 possible UBL Header
11380000 possilbe UBL Header
114a0000 spl code
115c0000 u-boot code
116
117The above steps are executeed through the following environment vars:
118(using 80000 as address for the UBL header)
119
120pagesz=800
121uboot=/tftpboot/cam_enc_4xx/u-boot.ubl
122load=tftp 80000000 ${uboot}
123writeheader nandrbl rbl;nand erase 80000 ${pagesz};nand write 80000000 80000 ${pagesz};nandrbl uboot
124writenand_spl nandrbl rbl;nand erase a0000 3000;nand write 80000800 a0000 3000;nandrbl uboot
125writeuboot nandrbl uboot;nand erase c0000 5d000;nand write 80003800 c0000 5d000
126update=run load writeheader writenand_spl writeuboot
127
128If you do a "run load update" u-boot, spl + ubl header
129are magically updated ;-)
130
131Note:
132- There seem to be a bug in the RBL code (at least on my HW),
133 In the UBL block, I can set the page to values != 0, so it
134 is possible to burn step 1 and step 2 in one step into the
135 flash, but the RBL ignores the page settings, so I have to
136 burn the UBL Header to a page 0 and the spl code to
137 a page 0 ... :-(
138- If we make the nand read/write functions in the RBL equal to
139 the functions in u-boot (as I have no RBL code, it is only
140 possible in u-boot), we could burn the complete image in
141 one step ... that would be nice ...
142
README.dfutftp
1# SPDX-License-Identifier: GPL-2.0+
2#
3# Copyright (C) 2015
4#
5# Lukasz Majewski <l.majewski@majess.pl>
6
7Device Firmware Upgrade (DFU) - extension to use TFTP
8=====================================================
9
10Why?
11----
12
13* Update TFTP (CONFIG_UPDATE_TFTP) only supports writing
14code to NAND memory via TFTP.
15* DFU supports writing data to the variety of mediums (NAND,
16eMMC, SD, partitions, RAM, etc) via USB.
17
18Combination of both solves their shortcomings!
19
20
21Overview
22--------
23
24This document briefly describes how to use DFU for
25upgrading firmware (e.g. kernel, u-boot, rootfs, etc.)
26via TFTP protocol.
27
28By using Ethernet (TFTP protocol to be precise) it is
29possible to overcome the major problem of USB based DFU -
30the relatively low transfer speed for large files.
31This was caused by DFU standard, which imposed utilization
32of only EP0 for transfer. By using Ethernet we can circumvent
33this shortcoming.
34
35Beagle Bone Black rev. C (BBB) powered by TI's am335x CPU has
36been used as a demo board.
37
38To utilize this feature, one needs to first enable support
39for USB based DFU (CONFIG_DFU_*) and DFU TFTP update
40(CONFIG_DFU_TFTP) described in ./doc/README.update.
41
42The "dfu" command has been extended to support transfer via TFTP - one
43needs to type for example "dfu tftp 0 mmc 0"
44
45As of this writing (SHA1:8d77576371381ade83de475bb639949b44941e8c v2015.10-rc2)
46the update.c code is not enabled (CONFIG_UPDATE_TFTP) by any board in the
47contemporary u-boot tree.
48
49
50Environment variables
51---------------------
52
53The "dfu tftp" command can be used in the "preboot" environment variable
54(when it is enabled by defining CONFIG_PREBOOT).
55This is the preferable way of using this command in the early boot stage
56as opposed to legacy update_tftp() function invocation.
57
58
59Beagle Bone Black (BBB) setup
60-----------------------------
61
621. Setup tftp env variables:
63 * select desired eth device - 'ethact' variable ["ethact=cpsw"]
64 (use "bdinfo" to check current setting)
65 * setup "serverip" and "ipaddr" variables
66 * set "loadaddr" as a fixed buffer where incoming data is placed
67 ["loadaddr=0x81000000"]
68
69#########
70# BONUS #
71#########
72It is possible to use USB interface to emulate ETH connection by setting
73"ethact=usb_ether". In this way one can have very fast DFU transfer via USB.
74
75For 33MiB test image the transfer rate was 1MiB/s for ETH over USB and 200KiB/s
76for pure DFU USB transfer.
77
782. Setup update_tftp variables:
79 * set "updatefile" - the file name to be downloaded via TFTP (stored on
80 the HOST at e.g. /srv/tftp)
81
823. If required, to update firmware on boot, put the "dfu tftp 0 mmc 0" in the
83 "preboot" env variable. Otherwise use this command from u-boot prompt.
84
854. Inspect "dfu" specific variables:
86 * "dfu_alt_info" - information about available DFU entities
87 * "dfu_bufsiz" - variable to set buffer size [in bytes] - when it is not
88 possible to set large enough default buffer (8 MiB @ BBB)
89
90
91FIT image format for download
92-----------------------------
93
94To create FIT image for download one should follow the update tftp README file
95(./doc/README.update) with one notable difference:
96
97The original snippet of ./doc/uImage.FIT/update_uboot.its
98
99 images {
100 update@1 {
101 description = "U-Boot binary";
102
103should look like
104
105 images {
106 u-boot.bin@1 {
107 description = "U-Boot binary";
108
109where "u-boot.bin" is the DFU entity name to be stored.
110
111
112To do
113-----
114
115* Extend dfu-util command to support TFTP based transfers
116* Upload support (via TFTP)
117
README.displaying-bmps
1If you are experiencing hangups/data-aborts when trying to display a BMP image,
2the following might be relevant to your situation...
3
4Some architectures cannot handle unaligned memory accesses, and an attempt to
5perform one will lead to a data abort. On such architectures it is necessary to
6make sure all data is properly aligned, and in many situations simply choosing
7a 32 bit aligned address is enough to ensure proper alignment. This is not
8always the case when dealing with data that has an internal layout such as a
9BMP image:
10
11BMP images have a header that starts with 2 byte-size fields followed by mostly
1232 bit fields. The packed struct that represents this header can be seen below:
13
14typedef struct bmp_header {
15 /* Header */
16 char signature[2];
17 __u32 file_size;
18 __u32 reserved;
19 __u32 data_offset;
20 ... etc
21} __attribute__ ((packed)) bmp_header_t;
22
23When placed in an aligned address such as 0x80a00000, char signature offsets
24the __u32 fields into unaligned addresses (in our example 0x80a00002,
250x80a00006, and so on...). When these fields are accessed by U-Boot, a 32 bit
26access is generated at a non-32-bit-aligned address, causing a data abort.
27The proper alignment for BMP images is therefore: 32-bit-aligned-address + 2.
28
README.dns
1Domain Name System
2-------------------------------------------
3
4The Domain Name System (DNS) is a hierarchical naming system for computers,
5services, or any resource participating in the Internet. It associates various
6information with domain names assigned to each of the participants. Most
7importantly, it translates domain names meaningful to humans into the numerical
8(binary) identifiers associated with networking equipment for the purpose of
9locating and addressing these devices world-wide. An often used analogy to
10explain the Domain Name System is that it serves as the "phone book" for the
11Internet by translating human-friendly computer hostnames into IP addresses.
12For example, www.example.com translates to 208.77.188.166.
13
14For more information on DNS - http://en.wikipedia.org/wiki/Domain_Name_System
15
16U-Boot and DNS
17------------------------------------------
18
19CONFIG_CMD_DNS - controls if the 'dns' command is compiled in. If it is, it
20 will send name lookups to the dns server (env var 'dnsip')
21 Turning this option on will about abou 1k to U-Boot's size.
22
23 Example:
24
25bfin> print dnsip
26dnsip=192.168.0.1
27
28bfin> dns www.google.com
2966.102.1.104
30
31 By default, dns does nothing except print the IP number on
32 the default console - which by itself, would be pretty
33 useless. Adding a third argument to the dns command will
34 use that as the environment variable to be set.
35
36 Example:
37
38bfin> print googleip
39## Error: "googleip" not defined
40bfin> dns www.google.com googleip
4164.233.161.104
42bfin> print googleip
43googleip=64.233.161.104
44bfin> ping ${googleip}
45Using Blackfin EMAC device
46host 64.233.161.104 is alive
47
48 In this way, you can lookup, and set many more meaningful
49 things.
50
51bfin> sntp
52ntpserverip not set
53bfin> dns pool.ntp.org ntpserverip
5472.18.205.156
55bfin> sntp
56Date: 2009-07-18 Time: 4:06:57
57
58 For some helpful things that can be related to DNS in U-Boot,
59 look at the top level README for these config options:
60 CONFIG_CMD_DHCP
61 CONFIG_BOOTP_DNS
62 CONFIG_BOOTP_DNS2
63
README.enetaddr
1---------------------------------
2 Ethernet Address (MAC) Handling
3---------------------------------
4
5There are a variety of places in U-Boot where the MAC address is used, parsed,
6and stored. This document covers proper usage of each location and the moving
7of data between them.
8
9-----------
10 Locations
11-----------
12
13Here are the places where MAC addresses might be stored:
14
15 - board-specific location (eeprom, dedicated flash, ...)
16 Note: only used when mandatory due to hardware design etc...
17
18 - environment ("ethaddr", "eth1addr", ...)
19 Note: this is the preferred way to permanently store MAC addresses
20
21 - ethernet data (struct eth_device -> enetaddr)
22 Note: these are temporary copies of the MAC address which exist only
23 after the respective init steps have run and only to make usage
24 in other places easier (to avoid constant env lookup/parsing)
25
26 - struct bd_info and/or device tree
27 Note: these are temporary copies of the MAC address only for the
28 purpose of passing this information to an OS kernel we are about
29 to boot
30
31Correct flow of setting up the MAC address (summarized):
32
331. Read from hardware in initialize() function
342. Read from environment in net/eth.c after initialize()
353. The environment variable will be compared to the driver initialized
36 struct eth_device->enetaddr. If they differ, a warning is printed, and the
37 environment variable will be used unchanged.
38 If the environment variable is not set, it will be initialized from
39 eth_device->enetaddr, and a warning will be printed.
40 If both are invalid and CONFIG_NET_RANDOM_ETHADDR is defined, a random,
41 locally-assigned MAC is written to eth_device->enetaddr.
424. Program the address into hardware if the following conditions are met:
43 a) The relevant driver has a 'write_addr' function
44 b) The user hasn't set an 'ethmacskip' environment variable
45 c) The address is valid (unicast, not all-zeros)
46
47Previous behavior had the MAC address always being programmed into hardware
48in the device's init() function.
49
50-------
51 Usage
52-------
53
54If the hardware design mandates that the MAC address is stored in some special
55place (like EEPROM etc...), then the board specific init code (such as the
56board-specific misc_init_r() function) is responsible for locating the MAC
57address(es) and initializing the respective environment variable(s) from it.
58Note that this shall be done if, and only if, the environment does not already
59contain these environment variables, i.e. existing variable definitions must
60not be overwritten.
61
62During runtime, the ethernet layer will use the environment variables to sync
63the MAC addresses to the ethernet structures. All ethernet driver code should
64then only use the enetaddr member of the eth_device structure. This is done
65on every network command, so the ethernet copies will stay in sync.
66
67Any other code that wishes to access the MAC address should query the
68environment directly. The helper functions documented below should make
69working with this storage much smoother.
70
71---------
72 Helpers
73---------
74
75To assist in the management of these layers, a few helper functions exist. You
76should use these rather than attempt to do any kind of parsing/manipulation
77yourself as many common errors have arisen in the past.
78
79 * void string_to_enetaddr(const char *addr, uchar *enetaddr);
80
81Convert a string representation of a MAC address to the binary version.
82char *addr = "00:11:22:33:44:55";
83uchar enetaddr[6];
84string_to_enetaddr(addr, enetaddr);
85/* enetaddr now equals { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 } */
86
87 * int eth_env_get_enetaddr(char *name, uchar *enetaddr);
88
89Look up an environment variable and convert the stored address. If the address
90is valid, then the function returns 1. Otherwise, the function returns 0. In
91all cases, the enetaddr memory is initialized. If the env var is not found,
92then it is set to all zeros. The common function is_valid_ethaddr() is used
93to determine address validity.
94uchar enetaddr[6];
95if (!eth_env_get_enetaddr("ethaddr", enetaddr)) {
96 /* "ethaddr" is not set in the environment */
97 ... try and setup "ethaddr" in the env ...
98}
99/* enetaddr is now set to the value stored in the ethaddr env var */
100
101 * int eth_env_set_enetaddr(char *name, const uchar *enetaddr);
102
103Store the MAC address into the named environment variable. The return value is
104the same as the env_set() function.
105uchar enetaddr[6] = { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 };
106eth_env_set_enetaddr("ethaddr", enetaddr);
107/* the "ethaddr" env var should now be set to "00:11:22:33:44:55" */
108
109 * the %pM format modifier
110
111The %pM format modifier can be used with any standard printf function to format
112the binary 6 byte array representation of a MAC address.
113uchar enetaddr[6] = { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 };
114printf("The MAC is %pM\n", enetaddr);
115
116char buf[20];
117sprintf(buf, "%pM", enetaddr);
118/* the buf variable is now set to "00:11:22:33:44:55" */
119
README.esbc_validate
1SPDX-License-Identifier: GPL-2.0+
2/*
3 * (C) Copyright 2015
4 */
5
6esbc_validate command
7========================================
8
91. esbc_validate command is meant for validating header and
10 signature of images (Boot Script and ESBC uboot client).
11 SHA-256 and RSA operations are performed using SEC block in HW.
12 This command works on both PBL based and Non PBL based Freescale
13 platforms.
14 Command usage:
15 esbc_validate img_hdr_addr [pub_key_hash]
16 esbc_validate hdr_addr <hash_val>
17 Validates signature using RSA verification.
18 $hdr_addr Address of header of the image to be validated.
19 $hash_val -Optional. It provides Hash of public/srk key to be
20 used to verify signature.
21
222. ESBC uboot client can be linux. Additionally, rootfs and device
23 tree blob can also be signed.
243. In the event of header or signature failure in validation,
25 ITS and ITF bits determine further course of action.
264. In case of soft failure, appropriate error is dumped on console.
275. In case of hard failure, SoC is issued RESET REQUEST after
28 dumping error on the console.
296. KEY REVOCATION Feature:
30 QorIQ platforms like B4/T4 have support of srk key table and key
31 revocation in ISBC code in Silicon.
32 The srk key table allows the user to have a key table with multiple
33 keys and revoke any key in case of particular key gets compromised.
34 In case the ISBC code uses the key revocation and srk key table to
35 verify the u-boot code, the subsequent chain of trust should also
36 use the same.
376. ISBC KEY EXTENSION Feature:
38 This feature allows large number of keys to be used for esbc validation
39 of images. A set of public keys is being signed and validated by ISBC
40 which can be further used for esbc validation of images.
41
README.ext4
1U-Boot supports access of both ext2 and ext4 filesystems, either in read-only
2mode or in read-write mode.
3
4First, to enable support for both ext4 (and, automatically, ext2 as well),
5but without selecting the corresponding commands, enable one of the following:
6
7 CONFIG_FS_EXT4 (for read-only)
8 CONFIG_EXT4_WRITE (for read-write)
9
10Next, to select the ext2-related commands:
11
12 * ext2ls
13 * ext2load
14
15or ext4-related commands:
16
17 * ext4size
18 * ext4ls
19 * ext4load
20
21use one or both of:
22
23 CONFIG_CMD_EXT2
24 CONFIG_CMD_EXT4
25
26Selecting either of the above automatically selects CONFIG_FS_EXT4 if it
27wasn't enabled already.
28
29In addition, to get the write access command "ext4write", enable:
30
31 CONFIG_CMD_EXT4_WRITE
32
33which automatically selects CONFIG_EXT4_WRITE if it wasn't defined
34already.
35
36Also relevant are the generic filesystem commands, selected by:
37
38 CONFIG_CMD_FS_GENERIC
39
40This does not automatically enable EXT4 support for you, you still need
41to do that yourself.
42
43Some sample commands to test ext4 support:
44
451. Check that the commands can be seen in the output of U-Boot help:
46
47 UBOOT #help
48 ...
49 ext4load- load binary file from a Ext4 file system
50 ext4ls - list files in a directory (default /)
51 ext4size - determine a file's size
52 ext4write- create a file in ext4 formatted partition
53 ...
54
552. To list the files in an ext4-formatted partition, run:
56
57 ext4ls <interface> <dev[:part]> [directory]
58
59 For example:
60 UBOOT #ext4ls mmc 0:5 /usr/lib
61
623. To read and load a file from an ext4-formatted partition to RAM, run:
63
64 ext4load <interface> <dev[:part]> [addr] [filename] [bytes]
65
66 For example:
67 UBOOT #ext4load mmc 2:2 0x30007fc0 uImage
68
694. To write a file to an ext4-formatted partition.
70
71 a) First load a file to RAM at a particular address for example 0x30007fc0.
72 Now execute ext4write command:
73 ext4write <interface> <dev[:part]> [filename] [Address] [sizebytes]
74
75 For example:
76 UBOOT #ext4write mmc 2:2 /boot/uImage 0x30007fc0 6183120
77 (here 6183120 is the size of the file to be written)
78 Note: Absolute path is required for the file to be written
79
80References :
81 -- ext4 implementation in Linux Kernel
82 -- Uboot existing ext2 load and ls implementation
83 -- Journaling block device JBD2 implementation in linux Kernel
84
README.fec_mxc
1U-Boot config options used in fec_mxc.c
2
3CONFIG_FEC_MXC
4 Selects fec_mxc.c to be compiled into u-boot. Can read out the
5 ethaddr from the SoC eFuses (see below).
6
7CONFIG_MII
8 Must be defined if CONFIG_FEC_MXC is defined.
9
10CFG_FEC_MXC_SWAP_PACKET
11 Forced on iff MX28.
12 Swaps the bytes order of all words(4 byte units) in the packet.
13 This should not be specified by a board file. It is cpu specific.
14
15CONFIG_PHYLIB
16 fec_mxc supports PHYLIB and should be used for new boards.
17
18CONFIG_FEC_MXC_NO_ANEG
19 Relevant only if PHYLIB not used. Skips auto-negotiation restart.
20
21CFG_FEC_MXC_PHYADDR
22 Optional, selects the exact phy address that should be connected
23 and function fecmxc_initialize will try to initialize it.
24
25Reading the ethaddr from the SoC eFuses:
26if CONFIG_FEC_MXC is defined and the U-Boot environment does not contain the
27ethaddr variable, then its value gets read from the corresponding eFuses in
28the SoC. See the README files of the specific SoC for details.
29
README.fsl-ddr
1Table of interleaving 2-4 controllers
2=====================================
3 +--------------+-----------------------------------------------------------+
4 |Configuration | Memory Controller |
5 | | 1 2 3 4 |
6 |--------------+--------------+--------------+-----------------------------+
7 | Two memory | Not Intlv'ed | Not Intlv'ed | |
8 | complexes +--------------+--------------+ |
9 | | 2-way Intlv'ed | |
10 |--------------+--------------+--------------+--------------+ |
11 | | Not Intlv'ed | Not Intlv'ed | Not Intlv'ed | |
12 | Three memory +--------------+--------------+--------------+ |
13 | complexes | 2-way Intlv'ed | Not Intlv'ed | |
14 | +-----------------------------+--------------+ |
15 | | 3-way Intlv'ed | |
16 +--------------+--------------+--------------+--------------+--------------+
17 | | Not Intlv'ed | Not Intlv'ed | Not Intlv'ed | Not Intlv'ed |
18 | Four memory +--------------+--------------+--------------+--------------+
19 | complexes | 2-way Intlv'ed | 2-way Intlv'ed |
20 | +-----------------------------+-----------------------------+
21 | | 4-way Intlv'ed |
22 +--------------+-----------------------------------------------------------+
23
24
25Table of 2-way interleaving modes supported in cpu/8xxx/ddr/
26======================================================
27 +-------------+---------------------------------------------------------+
28 | | Rank Interleaving |
29 | +--------+-----------+-----------+------------+-----------+
30 |Memory | | | | 2x2 | 4x1 |
31 |Controller | None | 2x1 lower | 2x1 upper | {CS0+CS1}, | {CS0+CS1+ |
32 |Interleaving | | {CS0+CS1} | {CS2+CS3} | {CS2+CS3} | CS2+CS3} |
33 +-------------+--------+-----------+-----------+------------+-----------+
34 |None | Yes | Yes | Yes | Yes | Yes |
35 +-------------+--------+-----------+-----------+------------+-----------+
36 |Cacheline | Yes | Yes | No | No, Only(*)| Yes |
37 | |CS0 Only| | | {CS0+CS1} | |
38 +-------------+--------+-----------+-----------+------------+-----------+
39 |Page | Yes | Yes | No | No, Only(*)| Yes |
40 | |CS0 Only| | | {CS0+CS1} | |
41 +-------------+--------+-----------+-----------+------------+-----------+
42 |Bank | Yes | Yes | No | No, Only(*)| Yes |
43 | |CS0 Only| | | {CS0+CS1} | |
44 +-------------+--------+-----------+-----------+------------+-----------+
45 |Superbank | No | Yes | No | No, Only(*)| Yes |
46 | | | | | {CS0+CS1} | |
47 +-------------+--------+-----------+-----------+------------+-----------+
48 (*) Although the hardware can be configured with memory controller
49 interleaving using "2x2" rank interleaving, it only interleaves {CS0+CS1}
50 from each controller. {CS2+CS3} on each controller are only rank
51 interleaved on that controller.
52
53 For memory controller interleaving, identical DIMMs are suggested. Software
54 doesn't check the size or organization of interleaved DIMMs.
55
56The ways to configure the ddr interleaving mode
57==============================================
581. In board header file(e.g.MPC8572DS.h), add default interleaving setting
59 under "CFG_EXTRA_ENV_SETTINGS", like:
60 #define CFG_EXTRA_ENV_SETTINGS \
61 "hwconfig=fsl_ddr:ctlr_intlv=bank" \
62 ......
63
642. Run U-Boot "setenv" command to configure the memory interleaving mode.
65 Either numerical or string value is accepted.
66
67 # disable memory controller interleaving
68 setenv hwconfig "fsl_ddr:ctlr_intlv=null"
69
70 # cacheline interleaving
71 setenv hwconfig "fsl_ddr:ctlr_intlv=cacheline"
72
73 # page interleaving
74 setenv hwconfig "fsl_ddr:ctlr_intlv=page"
75
76 # bank interleaving
77 setenv hwconfig "fsl_ddr:ctlr_intlv=bank"
78
79 # superbank
80 setenv hwconfig "fsl_ddr:ctlr_intlv=superbank"
81
82 # 1KB 3-way interleaving
83 setenv hwconfig "fsl_ddr:ctlr_intlv=3way_1KB"
84
85 # 4KB 3-way interleaving
86 setenv hwconfig "fsl_ddr:ctlr_intlv=3way_4KB"
87
88 # 8KB 3-way interleaving
89 setenv hwconfig "fsl_ddr:ctlr_intlv=3way_8KB"
90
91 # disable bank (chip-select) interleaving
92 setenv hwconfig "fsl_ddr:bank_intlv=null"
93
94 # bank(chip-select) interleaving cs0+cs1
95 setenv hwconfig "fsl_ddr:bank_intlv=cs0_cs1"
96
97 # bank(chip-select) interleaving cs2+cs3
98 setenv hwconfig "fsl_ddr:bank_intlv=cs2_cs3"
99
100 # bank(chip-select) interleaving (cs0+cs1) and (cs2+cs3) (2x2)
101 setenv hwconfig "fsl_ddr:bank_intlv=cs0_cs1_and_cs2_cs3"
102
103 # bank(chip-select) interleaving (cs0+cs1+cs2+cs3) (4x1)
104 setenv hwconfig "fsl_ddr:bank_intlv=cs0_cs1_cs2_cs3"
105
106 # bank(chip-select) interleaving (auto)
107 setenv hwconfig "fsl_ddr:bank_intlv=auto"
108 This auto mode only select from cs0_cs1_cs2_cs3, cs0_cs1, null dependings
109 on DIMMs.
110
111Memory controller address hashing
112==================================
113If the DDR controller supports address hashing, it can be enabled by hwconfig.
114
115Syntax is:
116hwconfig=fsl_ddr:addr_hash=true
117
118Memory controller ECC on/off
119============================
120If ECC is enabled in board configuratoin file, i.e. #define CONFIG_DDR_ECC,
121ECC can be turned on/off by hwconfig.
122
123Syntax is
124hwconfig=fsl_ddr:ecc=off
125
126
127Memory address parity on/off
128============================
129address parity can be turned on/off by hwconfig.
130Syntax is:
131hwconfig=fsl_ddr:parity=on
132
133
134Memory testing options for mpc85xx
135==================================
1361. Memory test can be done once U-Boot prompt comes up using mtest, or
1372. Memory test can be done with Power-On-Self-Test function, activated at
138 compile time.
139
140 In order to enable the POST memory test, CFG_POST needs to be
141 defined in board configuraiton header file. By default, POST memory test
142 performs a fast test. A slow test can be enabled by changing the flag at
143 compiling time. To test memory bigger than 2GB, 36BIT support is needed.
144 Memory is tested within a 2GB window. TLBs are used to map the virtual 2GB
145 window to physical address so that all physical memory can be tested.
146
147Combination of hwconfig
148=======================
149Hwconfig can be combined with multiple parameters, for example, on a supported
150platform
151
152hwconfig=fsl_ddr:addr_hash=true,ctlr_intlv=cacheline,bank_intlv=cs0_cs1_cs2_cs3,ecc=on
153
154
155Table for dynamic ODT for DDR3
156==============================
157For single-slot system with quad-rank DIMM and dual-slot system, dynamic ODT may
158be needed, depending on the configuration. The numbers in the following tables are
159in Ohms.
160
161* denotes dynamic ODT
162
163Two slots system
164+-----------------------+----------+---------------+-----------------------------+-----------------------------+
165| Configuration | |DRAM controller| Slot 1 | Slot 2 |
166+-----------+-----------+----------+-------+-------+--------------+--------------+--------------+--------------+
167| | | | | | Rank 1 | Rank 2 | Rank 1 | Rank 2 |
168+ Slot 1 | Slot 2 |Write/Read| Write | Read |-------+------+-------+------+-------+------+-------+------+
169| | | | | | Write | Read | Write | Read | Write | Read | Write | Read |
170+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
171| | | Slot 1 | off | 75 | 120 | off | off | off | off | off | 30 | 30 |
172| Dual Rank | Dual Rank |----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
173| | | Slot 2 | off | 75 | off | off | 30 | 30 | 120 | off | off | off |
174+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
175| | | Slot 1 | off | 75 | 120 | off | off | off | 20 | 20 | | |
176| Dual Rank |Single Rank|----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
177| | | Slot 2 | off | 75 | off | off | 20 | 20 | 120 *| off | | |
178+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
179| | | Slot 1 | off | 75 | 120 *| off | | | off | off | 20 | 20 |
180|Single Rank| Dual Rank |----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
181| | | Slot 2 | off | 75 | 20 | 20 | | | 120 | off | off | off |
182+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
183| | | Slot 1 | off | 75 | 120 *| off | | | 30 | 30 | | |
184|Single Rank|Single Rank|----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
185| | | Slot 2 | off | 75 | 30 | 30 | | | 120 *| off | | |
186+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
187| Dual Rank | Empty | Slot 1 | off | 75 | 40 | off | off | off | | | | |
188+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
189| Empty | Dual Rank | Slot 2 | off | 75 | | | | | 40 | off | off | off |
190+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
191|Single Rank| Empty | Slot 1 | off | 75 | 40 | off | | | | | | |
192+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
193| Empty |Single Rank| Slot 2 | off | 75 | | | | | 40 | off | | |
194+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
195
196Single slot system
197+-------------+------------+---------------+-----------------------------+-----------------------------+
198| | |DRAM controller| Rank 1 | Rank 2 | Rank 3 | Rank 4 |
199|Configuration| Write/Read |-------+-------+-------+------+-------+------+-------+------+-------+------+
200| | | Write | Read | Write | Read | Write | Read | Write | Read | Write | Read |
201+-------------+------------+-------+-------+-------+------+-------+------+-------+------+-------+------+
202| | R1 | off | 75 | 120 *| off | off | off | 20 | 20 | off | off |
203| |------------+-------+-------+-------+------+-------+------+-------+------+-------+------+
204| | R2 | off | 75 | off | 20 | 120 | off | 20 | 20 | off | off |
205| Quad Rank |------------+-------+-------+-------+------+-------+------+-------+------+-------+------+
206| | R3 | off | 75 | 20 | 20 | off | off | 120 *| off | off | off |
207| |------------+-------+-------+-------+------+-------+------+-------+------+-------+------+
208| | R4 | off | 75 | 20 | 20 | off | off | off | 20 | 120 | off |
209+-------------+------------+-------+-------+-------+------+-------+------+-------+------+-------+------+
210| | R1 | off | 75 | 40 | off | off | off |
211| Dual Rank |------------+-------+-------+-------+------+-------+------+
212| | R2 | off | 75 | 40 | off | off | off |
213+-------------+------------+-------+-------+-------+------+-------+------+
214| Single Rank | R1 | off | 75 | 40 | off |
215+-------------+------------+-------+-------+-------+------+
216
217Reference http://www.xrosstalkmag.com/mag_issues/xrosstalk_oct08_final.pdf
218 http://download.micron.com/pdf/technotes/ddr3/tn4108_ddr3_design_guide.pdf
219
220
221Table for ODT for DDR2
222======================
223Two slots system
224+-----------------------+----------+---------------+-----------------------------+-----------------------------+
225| Configuration | |DRAM controller| Slot 1 | Slot 2 |
226+-----------+-----------+----------+-------+-------+--------------+--------------+--------------+--------------+
227| | | | | | Rank 1 | Rank 2 | Rank 1 | Rank 2 |
228+ Slot 1 | Slot 2 |Write/Read| Write | Read |-------+------+-------+------+-------+------+-------+------+
229| | | | | | Write | Read | Write | Read | Write | Read | Write | Read |
230+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
231| | | Slot 1 | off | 150 | off | off | off | off | 75 | 75 | off | off |
232| Dual Rank | Dual Rank |----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
233| | | Slot 2 | off | 150 | 75 | 75 | off | off | off | off | off | off |
234+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
235| | | Slot 1 | off | 150 | off | off | off | off | 75 | 75 | | |
236| Dual Rank |Single Rank|----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
237| | | Slot 2 | off | 150 | 75 | 75 | off | off | off | off | | |
238+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
239| | | Slot 1 | off | 150 | off | off | | | 75 | 75 | off | off |
240|Single Rank| Dual Rank |----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
241| | | Slot 2 | off | 150 | 75 | 75 | | | off | off | off | off |
242+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
243| | | Slot 1 | off | 150 | off | off | | | 75 | 75 | | |
244|Single Rank|Single Rank|----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
245| | | Slot 2 | off | 150 | 75 | 75 | | | off | off | | |
246+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
247| Dual Rank | Empty | Slot 1 | off | 75 | 150 | off | off | off | | | | |
248+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
249| Empty | Dual Rank | Slot 2 | off | 75 | | | | | 150 | off | off | off |
250+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
251|Single Rank| Empty | Slot 1 | off | 75 | 150 | off | | | | | | |
252+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
253| Empty |Single Rank| Slot 2 | off | 75 | | | | | 150 | off | | |
254+-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
255
256Single slot system
257+-------------+------------+---------------+-----------------------------+
258| | |DRAM controller| Rank 1 | Rank 2 |
259|Configuration| Write/Read |-------+-------+-------+------+-------+------+
260| | | Write | Read | Write | Read | Write | Read |
261+-------------+------------+-------+-------+-------+------+-------+------+
262| | R1 | off | 75 | 150 | off | off | off |
263| Dual Rank |------------+-------+-------+-------+------+-------+------+
264| | R2 | off | 75 | 150 | off | off | off |
265+-------------+------------+-------+-------+-------+------+-------+------+
266| Single Rank | R1 | off | 75 | 150 | off |
267+-------------+------------+-------+-------+-------+------+
268
269Reference http://www.samsung.com/global/business/semiconductor/products/dram/downloads/applicationnote/ddr2_odt_control_200603.pdf
270
271
272Interactive DDR debugging
273===========================
274
275For DDR parameter tuning up and debugging, the interactive DDR debugger can
276be activated by setting the environment variable "ddr_interactive" to any
277value. (The value of ddr_interactive may have a meaning in the future, but,
278for now, the presence of the variable will cause the debugger to run.) Once
279activated, U-Boot will show the prompt "FSL DDR>" before enabling the DDR
280controller. The available commands are printed by typing "help".
281
282Another way to enter the interactive DDR debugger without setting the
283environment variable is to send the 'd' character early during the boot
284process. To save booting time, no additional delay is added, so the window
285to send the key press is very short -- basically, it is the time before the
286memory controller code starts to run. For example, when rebooting from
287within U-Boot, the user must press 'd' IMMEDIATELY after hitting enter to
288initiate a 'reset' command. In case of power on/reset, the user can hold
289down the 'd' key while applying power or hitting the board's reset button.
290
291The example flow of using interactive debugging is
292type command "compute" to calculate the parameters from the default
293type command "print" with arguments to show SPD, options, registers
294type command "edit" with arguments to change any if desired
295type command "copy" with arguments to copy controller/dimm settings
296type command "go" to continue calculation and enable DDR controller
297
298Additional commands to restart the debugging are:
299type command "reset" to reset the board
300type command "recompute" to reload SPD and start over
301
302Note, check "next_step" to show the flow. For example, after edit opts, the
303next_step is STEP_ASSIGN_ADDRESSES. After editing registers, the next_step is
304STEP_PROGRAM_REGS. Upon issuing command "go", the debugger will program the
305DDR controller with the current setting without further calculation and then
306exit to resume the booting of the machine.
307
308The detail syntax for each commands are
309
310print [c<n>] [d<n>] [spd] [dimmparms] [commonparms] [opts] [addresses] [regs]
311 c<n> - the controller number, eg. c0, c1
312 d<n> - the DIMM number, eg. d0, d1
313 spd - print SPD data
314 dimmparms - DIMM parameters, calculated from SPD
315 commonparms - lowest common parameters for all DIMMs
316 opts - options
317 addresses - address assignment (not implemented yet)
318 regs - controller registers
319
320edit <c#> <d#> <spd|dimmparms|commonparms|opts|addresses|regs> <element> <value>
321 c<n> - the controller number, eg. c0, c1
322 d<n> - the DIMM number, eg. d0, d1
323 spd - print SPD data
324 dimmparms - DIMM parameters, calculated from SPD
325 commonparms - lowest common parameters for all DIMMs
326 opts - options
327 addresses - address assignment (not implemented yet)
328 regs - controller registers
329 <element> - name of the modified element
330 byte number if the object is SPD
331 <value> - decimal or heximal (prefixed with 0x) numbers
332
333copy <src c#> <src d#> <spd|dimmparms|commonparms|opts|addresses|regs> <dst c#> <dst d#>
334 same as for "edit" command
335 DIMM numbers ignored for commonparms, opts, and regs
336
337reset
338 no arguement - reset the board
339
340recompute
341 no argument - reload SPD and start over
342
343compute
344 no argument - recompute from current next_step
345
346next_step
347 no argument - show current next_step
348
349help
350 no argument - print a list of all commands
351
352go
353 no argument - program memory controller(s) and continue with U-Boot
354
355Examples of debugging flow
356
357 FSL DDR>compute
358 Detected UDIMM UG51U6400N8SU-ACF
359 FSL DDR>print
360 print [c<n>] [d<n>] [spd] [dimmparms] [commonparms] [opts] [addresses] [regs]
361 FSL DDR>print dimmparms
362 DIMM parameters: Controller=0 DIMM=0
363 DIMM organization parameters:
364 module part name = UG51U6400N8SU-ACF
365 rank_density = 2147483648 bytes (2048 megabytes)
366 capacity = 4294967296 bytes (4096 megabytes)
367 burst_lengths_bitmask = 0C
368 base_addresss = 0 (00000000 00000000)
369 n_ranks = 2
370 data_width = 64
371 primary_sdram_width = 64
372 ec_sdram_width = 0
373 registered_dimm = 0
374 n_row_addr = 15
375 n_col_addr = 10
376 edc_config = 0
377 n_banks_per_sdram_device = 8
378 tCKmin_X_ps = 1500
379 tCKmin_X_minus_1_ps = 0
380 tCKmin_X_minus_2_ps = 0
381 tCKmax_ps = 0
382 caslat_X = 960
383 tAA_ps = 13125
384 caslat_X_minus_1 = 0
385 caslat_X_minus_2 = 0
386 caslat_lowest_derated = 0
387 tRCD_ps = 13125
388 tRP_ps = 13125
389 tRAS_ps = 36000
390 tWR_ps = 15000
391 tWTR_ps = 7500
392 tRFC_ps = 160000
393 tRRD_ps = 6000
394 tRC_ps = 49125
395 refresh_rate_ps = 7800000
396 tIS_ps = 0
397 tIH_ps = 0
398 tDS_ps = 0
399 tDH_ps = 0
400 tRTP_ps = 7500
401 tDQSQ_max_ps = 0
402 tQHS_ps = 0
403 FSL DDR>edit c0 opts ECC_mode 0
404 FSL DDR>edit c0 regs cs0_bnds 0x000000FF
405 FSL DDR>go
406 2 GiB left unmapped
407 4 GiB (DDR3, 64-bit, CL=9, ECC off)
408 DDR Chip-Select Interleaving Mode: CS0+CS1
409 Testing 0x00000000 - 0x7fffffff
410 Testing 0x80000000 - 0xffffffff
411 Remap DDR 2 GiB left unmapped
412
413 POST memory PASSED
414 Flash: 128 MiB
415 L2: 128 KB enabled
416 Corenet Platform Cache: 1024 KB enabled
417 SERDES: timeout resetting bank 3
418 SRIO1: disabled
419 SRIO2: disabled
420 MMC: FSL_ESDHC: 0
421 EEPROM: Invalid ID (ff ff ff ff)
422 PCIe1: disabled
423 PCIe2: Root Complex, x1, regs @ 0xfe201000
424 01:00.0 - 8086:10d3 - Network controller
425 PCIe2: Bus 00 - 01
426 PCIe3: disabled
427 In: serial
428 Out: serial
429 Err: serial
430 Net: Initializing Fman
431 Fman1: Uploading microcode version 101.8.0
432 e1000: 00:1b:21:81:d2:e0
433 FM1@DTSEC1, FM1@DTSEC2, FM1@DTSEC3, FM1@DTSEC4, FM1@DTSEC5, e1000#0 [PRIME]
434 Warning: e1000#0 MAC addresses don't match:
435 Address in SROM is 00:1b:21:81:d2:e0
436 Address in environment is 00:e0:0c:00:ea:05
437
438 Hit any key to stop autoboot: 0
439 =>
440
README.fsl-esdhc
1Freescale esdhc-specific options
2
3 - CONFIG_SYS_FSL_ESDHC_LE
4 ESDHC IP is in little-endian mode. Accessing ESDHC registers can be
5 determined by ESDHC IP's endian mode or processor's endian mode.
6 - CONFIG_SYS_FSL_ESDHC_BE
7 ESDHC IP is in big-endian mode. Accessing ESDHC registers can be determined
8 by ESDHC IP's endian mode or processor's endian mode.
9
README.fsl-hwconfig
1Freescale-specific 'hwconfig' options.
2
3This file documents Freescale-specific key:value pairs for the 'hwconfig'
4option. See README.hwconfig for general information about 'hwconfig'.
5
6audclk
7 Specific to the P1022DS reference board.
8
9 This option specifies which of the two oscillator frequencies should be
10 routed to the Wolfson WM8776 codec. The ngPIXIS can be programmed to
11 route either a 11.2896MHz or a 12.288MHz clock. The default is
12 12.288MHz. This option has two effects. First, the MUX on the board
13 will be programmed accordingly. Second, the clock-frequency property
14 in the codec node in the device tree will be updated to the correct
15 value.
16
17 'audclk:11'
18 Select the 11.2896MHz clock
19
20 'audclk:12'
21 Select the 12.288MHz clock
22
23usb
24 Specific to boards have USB controller
25
26 This option specifies the following for a USB controller:
27
28 - which controller mode to use
29 - which USB PHY to use
30
31 This is used by generic USB device-tree fixup function to update
32 modified values of phy type and controller mode.
33
34 Also used for configuring multiple USB controllers such that
35 'usbN' (where N is 1, 2, etc. refers to controller no.)
36
37 'phy_type'
38 Select USB phy type: 'utmi' OR 'ulpi'
39
40 'dr_mode'
41 Select USB controller mode: 'host', 'peripheral' OR 'otg'
42
43 Examples:
44 usb1:dr_mode=host;usb2:dr_mode=peripheral'
45
46 usb1:dr_mode=host,phy_type=utmi;usb2:dr_mode=host'
47
README.fsl-trustzone-components
1Freescale ARM64 SoCs like LS2080A have ARM TrustZone components like
2TZPC-BP147 (TrustZone Protection Controller) and TZASC-400 (TrustZone
3Address Space Controller).
4
5While most of the configuration related programming of these peripherals
6is left to a root-of-trust security software layer (running in EL3
7privilege mode), but still some configurations of these peripherals
8might be required while the bootloader is executing in EL3 privilege
9mode. The following sections define how to turn on these features for
10LS2080A like SoCs.
11
12TZPC-BP147 (TrustZone Protection Controller)
13============================================
14- Depends on CONFIG_FSL_TZPC_BP147 configuration flag.
15- Separates Secure World and Normal World on-chip RAM (OCRAM) spaces.
16- Provides a programming model to set access control policy via the TZPC
17 TZDECPROT Registers.
18
19TZASC-400 (TrustZone Address Space Controller)
20==============================================
21- Depends on CONFIG_FSL_TZASC_400 configuration flag.
22- Separates Secure World and Normal World external memory spaces for bus masters
23 such as processors and DMA-equipped peripherals.
24- Supports 8 fully programmable address regions, initially inactive at reset,
25 and one base region, always active, that covers the remaining address space.
26
README.fsl_iim
1Driver implementing the fuse API for Freescale's IC Identification Module (IIM)
2
3This IP can be found on the following SoCs:
4 - MPC512x,
5 - i.MX25,
6 - i.MX27,
7 - i.MX31,
8 - i.MX35,
9 - i.MX51,
10 - i.MX53.
11
12The section numbers in this file refer to the i.MX25 Reference Manual.
13
14A fuse word contains 8 fuse bit slots, as explained in 30.4.2.2.1.
15
16A bank contains 256 fuse word slots, as shown by the memory map in 30.3.1.
17
18Some fuse bit or word slots may not have the corresponding fuses actually
19implemented in the fusebox.
20
21See the README files of the SoCs using this driver in order to know the
22conventions used by U-Boot to store some specific data in the fuses, e.g. MAC
23addresses.
24
25Fuse operations:
26
27 Read
28 Read operations are implemented as read accesses to the shadow registers,
29 using "Word y of Bank x" from the register summary in 30.3.2. This is
30 explained in detail in 30.4.5.1.
31
32 Sense
33 Sense operations are implemented as explained in 30.4.5.2.
34
35 Program
36 Program operations are implemented as explained in 30.4.5.3. Following
37 this operation, the shadow registers are reloaded by the hardware (not
38 immediately, but this does not make any difference for a user reading
39 these registers).
40
41 Override
42 Override operations are implemented as write accesses to the shadow
43 registers, as explained in 30.4.5.4.
44
45Configuration:
46
47 CONFIG_FSL_IIM
48 Enable this to enable the fsl_iim driver.
49
README.fuse
1Fuse API functions and commands
2
3The fuse API allows to control a fusebox and how it is used by the upper
4hardware layers.
5
6A fuse corresponds to a single non-volatile memory bit that can be programmed
7(i.e. blown, set to 1) only once. The programming operation is irreversible. A
8fuse that has not been programmed reads 0.
9
10Fuses can be used by SoCs to store various permanent configuration and data,
11e.g. boot configuration, security configuration, MAC addresses, etc.
12
13A fuse word is the smallest group of fuses that can be read at once from the
14fusebox control IP registers. This is limited to 32 bits with the current API.
15
16A fuse bank is the smallest group of fuse words having a common ID, as defined
17by each SoC.
18
19Upon startup, the fusebox control IP reads the fuse values and stores them to a
20volatile shadow cache.
21
22See the README files of the drivers implementing this API in order to know the
23SoC- and implementation-specific details.
24
25Functions / commands:
26
27 int fuse_read(u32 bank, u32 word, u32 *val);
28 fuse read <bank> <word> [<cnt>]
29 Read fuse words from the shadow cache.
30
31 int fuse_sense(u32 bank, u32 word, u32 *val);
32 fuse sense <bank> <word> [<cnt>]
33 Sense - i.e. read directly from the fusebox, skipping the shadow cache -
34 fuse words. This operation does not update the shadow cache.
35
36 This is useful to know the true value of fuses if an override has been
37 performed (see below).
38
39 int fuse_prog(u32 bank, u32 word, u32 val);
40 fuse prog [-y] <bank> <word> <hexval> [<hexval>...]
41 Program fuse words. This operation directly affects the fusebox and is
42 irreversible. The shadow cache is updated accordingly or not, depending on
43 each IP.
44
45 Only the bits to be programmed should be set in the input value (i.e. for
46 fuse bits that have already been programmed and hence should be left
47 unchanged by a further programming, it is preferable to clear the
48 corresponding bits in the input value in order not to perform a new
49 hardware programming operation on these fuse bits).
50
51 int fuse_override(u32 bank, u32 word, u32 val);
52 fuse override <bank> <word> <hexval> [<hexval>...]
53 Override fuse words in the shadow cache.
54
55 The fusebox is unaffected, so following this operation, the shadow cache
56 may differ from the fusebox values. Read or sense operations can then be
57 used to get the values from the shadow cache or from the fusebox.
58
59 This is useful to change the behaviors linked to some cached fuse values,
60 either because this is needed only temporarily, or because some of the
61 fuses have already been programmed or are locked (if the SoC allows to
62 override a locked fuse).
63
64Configuration:
65
66 CONFIG_CMD_FUSE
67 Define this to enable the fuse commands.
68
README.generic-board
1# SPDX-License-Identifier: GPL-2.0+
2#
3# (C) Copyright 2014 Google, Inc
4# Simon Glass <sjg@chromium.org>
5
6Background
7----------
8
9U-Boot traditionally had a board.c file for each architecture. This introduced
10quite a lot of duplication, with each architecture tending to do
11initialisation slightly differently. To address this, a new 'generic board
12init' feature was introduced in March 2013 (further motivation is
13provided in the cover letter below).
14
15All boards and architectures have moved to this as of mid 2016.
16
17
18What has changed?
19-----------------
20
21The main change is that the arch/<arch>/lib/board.c file is removed in
22favour of common/board_f.c (for pre-relocation init) and common/board_r.c
23(for post-relocation init).
24
25Related to this, the global_data and bd_info structures now have a core set of
26fields which are common to all architectures. Architecture-specific fields
27have been moved to separate structures.
28
29
30Further Background
31------------------
32
33The full text of the original generic board series is reproduced below.
34
35--8<-------------
36
37This series creates a generic board.c implementation which contains
38the essential functions of the major arch/xxx/lib/board.c files.
39
40What is the motivation for this change?
41
421. There is a lot of repeated code in the board.c files. Any change to
43things like setting up the baud rate requires a change in 10 separate
44places.
45
462. Since there are 10 separate files, adding a new feature which requires
47initialisation is painful since it must be independently added in 10
48places.
49
503. As time goes by the architectures naturally diverge since there is limited
51pressure to compare features or even CONFIG options against similar things
52in other board.c files.
53
544. New architectures must implement all the features all over again, and
55sometimes in subtle different ways. This places an unfair burden on getting
56a new architecture fully functional and running with U-Boot.
57
585. While it is a bit of a tricky change, I believe it is worthwhile and
59achievable. There is no requirement that all code be common, only that
60the code that is common should be located in common/board.c rather than
61arch/xxx/lib/board.c.
62
63All the functions of board_init_f() and board_init_r() are broken into
64separate function calls so that they can easily be included or excluded
65for a particular architecture. It also makes it easier to adopt Graeme's
66initcall proposal when it is ready.
67
68http://lists.denx.de/pipermail/u-boot/2012-January/114499.html
69
70This series removes the dependency on generic relocation. So relocation
71happens as one big chunk and is still completely arch-specific. See the
72relocation series for a proposed solution to this for ARM:
73
74http://lists.denx.de/pipermail/u-boot/2011-December/112928.html
75
76or Graeme's recent x86 series v2:
77
78http://lists.denx.de/pipermail/u-boot/2012-January/114467.html
79
80Instead of moving over a whole architecture, this series takes the approach
81of simply enabling generic board support for an architecture. It is then up
82to each board to opt in by defining CONFIG_SYS_GENERIC_BOARD in the board
83config file. If this is not done, then the code will be generated as
84before. This allows both sets of code to co-exist until we are comfortable
85with the generic approach, and enough boards run.
86
87ARM is a relatively large board.c file and one which I can test, therefore
88I think it is a good target for this series. On the other hand, x86 is
89relatively small and simple, but different enough that it introduces a
90few issues to be solved. So I have chosen both ARM and x86 for this series.
91After a suggestion from Wolfgang I have added PPC also. This is the
92largest and most feature-full board, so hopefully we have all bases
93covered in this RFC.
94
95A generic global_data structure is also required. This might upset a few
96people. Here is my basic reasoning: most fields are the same, all
97architectures include and need it, most global_data.h files already have
98#ifdefs to select fields for a particular SOC, so it is hard to
99see why architecures are different in this area. We can perhaps add a
100way to put architecture-specific fields into a separate header file, but
101for now I have judged that to be counter-productive.
102
103Similarly we need a generic bd_info structure, since generic code will
104be accessing it. I have done this in the same way as global_data and the
105same comments apply.
106
107There was dicussion on the list about passing gd_t around as a parameter
108to pre-relocation init functions. I think this makes sense, but it can
109be done as a separate change, and this series does not require it.
110
111While this series needs to stand on its own (as with the link script
112cleanup series and the generic relocation series) the goal is the
113unification of the board init code. So I hope we can address issues with
114this in mind, rather than focusing too narrowly on particular ARM, x86 or
115PPC issues.
116
117I have run-tested ARM on Tegra Seaboard only. To try it out, define
118CONFIG_SYS_GENERIC_BOARD in your board file and rebuild. Most likely on
119x86 and PPC at least it will hang, but if you are lucky it will print
120something first :-)
121
122I have run this though MAKEALL with CONFIG_SYS_GENERIC_BOARD on for all
123ARM, PPC and x86 boards. There are a few failures due to errors in
124the board config, which I have sent patches for. The main issue is
125just the difference between __bss_end and __bss_end__.
126
127Note: the first group of commits are required for this series to build,
128but could be separated out if required. I have included them here for
129convenience.
130
131------------->8--
132
133Simon Glass, sjg@chromium.org
134March 2014
135Updated after final removal, May 2016
136
README.generic_usb_ohci
1Notes on the the generic USB-OHCI driver
2========================================
3
4This driver (drivers/usb/usb_ohci.[ch]) is the result of the merge of
5various existing OHCI drivers that were basically identical beside
6cpu/board dependant initalization. This initalization has been moved
7into cpu/board directories and are called via the hooks below.
8
9Configuration options
10----------------------
11
12 CONFIG_USB_OHCI_NEW: enable the new OHCI driver
13
14 CFG_SYS_USB_OHCI_REGS_BASE: defines the base address of the OHCI
15 registers
16
17 CONFIG_SYS_USB_OHCI_SLOT_NAME: slot name
18
19Endianness issues
20------------------
21
22The USB bus operates in little endian, but unfortunately there are
23OHCI controllers that operate in big endian such as ppc4xx. For these the
24config option
25
26 CONFIG_SYS_OHCI_BE_CONTROLLER
27
28needs to be defined.
29
30
README.gpio
1
2GPIO hog (CONFIG_GPIO_HOG)
3--------
4
5All the GPIO hog are initialized using DM_FLAG_PROBE_AFTER_BIND DM flag
6after bind().
7
8Example, for the device tree:
9
10 tca6416@20 {
11 compatible = "ti,tca6416";
12 reg = <0x20>;
13 #gpio-cells = <2>;
14 gpio-controller;
15
16 env_reset {
17 gpio-hog;
18 input;
19 gpios = <6 GPIO_ACTIVE_LOW>;
20 };
21 boot_rescue {
22 gpio-hog;
23 input;
24 line-name = "foo-bar-gpio";
25 gpios = <7 GPIO_ACTIVE_LOW>;
26 };
27 };
28
29You can than access the gpio in your board code with:
30
31 struct gpio_desc *desc;
32 int ret;
33
34 ret = gpio_hog_lookup_name("boot_rescue", &desc);
35 if (ret)
36 return;
37 if (dm_gpio_get_value(desc) == 1)
38 printf("\nBooting into Rescue System\n");
39 else if (dm_gpio_get_value(desc) == 0)
40 printf("\nBoot normal\n");
41
README.gpt
1# SPDX-License-Identifier: GPL-2.0+
2#
3# Copyright (C) 2012 Samsung Electronics
4#
5# Lukasz Majewski <l.majewski@samsung.com>
6
7Glossary:
8========
9- UUID -(Universally Unique Identifier)
10- GUID - (Globally Unique ID)
11- EFI - (Extensible Firmware Interface)
12- UEFI - (Unified EFI) - EFI evolution
13- GPT (GUID Partition Table) - it is the EFI standard part
14- partitions - lists of available partitions (defined at u-boot):
15 ./include/configs/{target}.h
16
17Introduction:
18=============
19This document describes the GPT partition table format and usage of
20the gpt command in u-boot.
21
22UUID introduction:
23====================
24
25GPT for marking disks/partitions is using the UUID. It is supposed to be a
26globally unique value. A UUID is a 16-byte (128-bit) number. The number of
27theoretically possible UUIDs is therefore about 3 x 10^38.
28More often UUID is displayed as 32 hexadecimal digits, in 5 groups,
29separated by hyphens, in the form 8-4-4-4-12 for a total of 36 characters
30(32 digits and 4 hyphens)
31
32For instance, GUID of Basic data partition: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
33and GUID of Linux filesystem data: 0FC63DAF-8483-4772-8E79-3D69D8477DE4
34
35Historically there are 5 methods to generate this number. The oldest one is
36combining machine's MAC address and timer (epoch) value.
37
38Successive versions are using MD5 hash, random numbers and SHA-1 hash. All major
39OSes and programming languages are providing libraries to compute UUID (e.g.
40uuid command line tool).
41
42GPT brief explanation:
43======================
44
45 Layout:
46 -------
47
48 --------------------------------------------------
49 LBA 0 |Protective MBR |
50 ----------------------------------------------------------
51 LBA 1 |Primary GPT Header | Primary
52 -------------------------------------------------- GPT
53 LBA 2 |Entry 1|Entry 2| Entry 3| Entry 4|
54 --------------------------------------------------
55 LBA 3 |Entries 5 - 128 |
56 | |
57 | |
58 ----------------------------------------------------------
59 LBA 34 |Partition 1 |
60 | |
61 -----------------------------------
62 |Partition 2 |
63 | |
64 -----------------------------------
65 |Partition n |
66 | |
67 ----------------------------------------------------------
68 LBA -34 |Entry 1|Entry 2| Entry 3| Entry 4| Backup
69 -------------------------------------------------- GPT
70 LBA -33 |Entries 5 - 128 |
71 | |
72 | |
73 LBA -2 | |
74 --------------------------------------------------
75 LBA -1 |Backup GPT Header |
76 ----------------------------------------------------------
77
78For a legacy reasons, GPT's LBA 0 sector has a MBR structure. It is called
79"protective MBR".
80Its first partition entry ID has 0xEE value, and disk software, which is not
81handling the GPT sees it as a storage device without free space.
82
83It is possible to define 128 linearly placed partition entries.
84
85"LBA -1" means the last addressable block (in the mmc subsystem:
86"dev_desc->lba - 1")
87
88Primary/Backup GPT header:
89----------------------------
90Offset Size Description
91
920 8 B Signature ("EFI PART", 45 46 49 20 50 41 52 54)
938 4 B Revision (For version 1.0, the value is 00 00 01 00)
9412 4 B Header size (in bytes, usually 5C 00 00 00 meaning 92 bytes)
9516 4 B CRC32 of header (0 to header size), with this field zeroed
96 during calculation
9720 4 B Reserved (ZERO);
9824 8 B Current LBA (location of this header copy)
9932 8 B Backup LBA (location of the other header copy)
10040 8 B First usable LBA for partitions (primary partition table last
101 LBA + 1)
10248 8 B Last usable LBA (secondary partition table first LBA - 1)
10356 16 B Disk GUID (also referred as UUID on UNIXes)
10472 8 B Partition entries starting LBA (always 2 in primary copy)
10580 4 B Number of partition entries
10684 4 B Size of a partition entry (usually 128)
10788 4 B CRC32 of partition array
10892 * Reserved; must be ZERO (420 bytes for a 512-byte LBA)
109
110TOTAL: 512 B
111
112
113IMPORTANT:
114
115GPT headers and partition entries are protected by CRC32 (the POSIX CRC32).
116
117Primary GPT header and Backup GPT header have swapped values of "Current LBA"
118and "Backup LBA" and therefore different CRC32 check-sum.
119
120CRC32 for GPT headers (field "CRC of header") are calculated up till
121"Header size" (92), NOT 512 bytes.
122
123CRC32 for partition entries (field "CRC32 of partition array") is calculated for
124the whole array entry ( Number_of_partition_entries *
125sizeof(partition_entry_size (usually 128)))
126
127Observe, how Backup GPT is placed in the memory. It is NOT a mirror reflect
128of the Primary.
129
130 Partition Entry Format:
131 ----------------------
132 Offset Size Description
133
134 0 16 B Partition type GUID (Big Endian)
135 16 16 B Unique partition GUID in (Big Endian)
136 32 8 B First LBA (Little Endian)
137 40 8 B Last LBA (inclusive)
138 48 8 B Attribute flags [+]
139 56 72 B Partition name (text)
140
141 Attribute flags:
142 Bit 0 - System partition
143 Bit 1 - Hide from EFI
144 Bit 2 - Legacy BIOS bootable
145 Bit 48-63 - Defined and used by the individual partition type
146 For Basic data partition :
147 Bit 60 - Read-only
148 Bit 62 - Hidden
149 Bit 63 - Not mount
150
151Creating GPT partitions in U-Boot:
152==============
153
154To restore GUID partition table one needs to:
1551. Define partition layout in the environment.
156 Format of partitions layout:
157 "uuid_disk=...;name=u-boot,size=60MiB,uuid=...;
158 name=kernel,size=60MiB,uuid=...;"
159 or
160 "uuid_disk=${uuid_gpt_disk};name=${uboot_name},
161 size=${uboot_size},uuid=${uboot_uuid};"
162
163 The fields 'name' and 'size' are mandatory for every partition.
164 The field 'start' is optional.
165
166 If field 'size' of the last partition is 0, the partition is extended
167 up to the end of the device.
168
169 The fields 'uuid' and 'uuid_disk' are optional if CONFIG_RANDOM_UUID is
170 enabled. A random uuid will be used if omitted or they point to an empty/
171 non-existent environment variable. The environment variable will be set to
172 the generated UUID. The 'gpt guid' command reads the current value of the
173 uuid_disk from the GPT.
174
175 The field 'bootable' is optional, it is used to mark the GPT partition
176 bootable (set attribute flags "Legacy BIOS bootable").
177 "name=u-boot,size=60MiB;name=boot,size=60Mib,bootable;name=rootfs,size=0"
178 It can be used to locate bootable disks with command
179 "part list <interface> <dev> -bootable <varname>",
180 please check out doc/develop/distro.rst for use.
181
1822. Define 'CONFIG_EFI_PARTITION' and 'CONFIG_CMD_GPT'
183
1843. From u-boot prompt type:
185 gpt write mmc 0 $partitions
186
187Checking (validating) GPT partitions in U-Boot:
188===============================================
189
190Procedure is the same as above. The only change is at point 3.
191
192At u-boot prompt one needs to write:
193 gpt verify mmc 0 [$partitions]
194
195where [$partitions] is an optional parameter.
196
197When it is not provided, only basic checks based on CRC32 calculation for GPT
198header and PTEs are performed.
199When provided, additionally partition data - name, size and starting
200offset (last two in LBA) - are compared with data defined in '$partitions'
201environment variable.
202
203After running this command, return code is set to 0 if no errors found in
204on non-volatile medium stored GPT.
205
206Following line can be used to assess if GPT verification has succeed:
207
208U-BOOT> gpt verify mmc 0 $partitions
209U-BOOT> if test $? = 0; then echo "GPT OK"; else echo "GPT ERR"; fi
210
211Renaming GPT partitions from U-Boot:
212====================================
213
214GPT partition names are a mechanism via which userspace and U-Boot can
215communicate about software updates and boot failure. The 'gpt guid',
216'gpt read', 'gpt rename' and 'gpt swap' commands facilitate
217programmatic renaming of partitions from bootscripts by generating and
218modifying the partitions layout string. Here is an illustration of
219employing 'swap' to exchange 'primary' and 'backup' partition names:
220
221U-BOOT> gpt swap mmc 0 primary backup
222
223Afterwards, all partitions previously named 'primary' will be named
224'backup', and vice-versa. Alternatively, single partitions may be
225renamed. In this example, mmc0's first partition will be renamed
226'primary':
227
228U-BOOT> gpt rename mmc 0 1 primary
229
230The GPT functionality may be tested with the 'sandbox' board by
231creating a disk image as described under 'Block Device Emulation' in
232doc/arch/index.rst:
233
234=>host bind 0 ./disk.raw
235=> gpt read host 0
236[ . . . ]
237=> gpt swap host 0 name othername
238[ . . . ]
239
240Modifying GPT partition layout from U-Boot:
241===========================================
242
243The entire GPT partition layout can be exported to an environment
244variable and then modified enmasse. Users can change the partition
245numbers, offsets, names and sizes. The resulting variable can used to
246reformat the device. Here is an example of reading the GPT partitions
247into a variable and then modifying them:
248
249U-BOOT> gpt read mmc 0 current_partitions
250U-BOOT> env edit current_partitions
251edit: uuid_disk=[...];name=part1,start=0x4000,size=0x4000,uuid=[...];
252name=part2,start=0xc000,size=0xc000,uuid=[...];[ . . . ]
253
254U-BOOT> gpt write mmc 0 $current_partitions
255U-BOOT> gpt verify mmc 0 $current_partitions
256
257Partition type GUID:
258====================
259
260For created partition, the used partition type GUID is
261PARTITION_BASIC_DATA_GUID (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7).
262
263If you define 'CONFIG_PARTITION_TYPE_GUID', an optional parameter 'type'
264can specify a other partition type guid:
265
266 "uuid_disk=...;name=u-boot,size=60MiB,uuid=...;
267 name=kernel,size=60MiB,uuid=...,
268 type=0FC63DAF-8483-4772-8E79-3D69D8477DE4;"
269
270Some strings can be also used at the place of known GUID :
271 "system" = PARTITION_SYSTEM_GUID
272 (C12A7328-F81F-11D2-BA4B-00A0C93EC93B)
273 "mbr" = LEGACY_MBR_PARTITION_GUID
274 (024DEE41-33E7-11D3-9D69-0008C781F39F)
275 "msft" = PARTITION_MSFT_RESERVED_GUID
276 (E3C9E316-0B5C-4DB8-817D-F92DF00215AE)
277 "data" = PARTITION_BASIC_DATA_GUID
278 (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7)
279 "linux" = PARTITION_LINUX_FILE_SYSTEM_DATA_GUID
280 (0FC63DAF-8483-4772-8E79-3D69D8477DE4)
281 "raid" = PARTITION_LINUX_RAID_GUID
282 (A19D880F-05FC-4D3B-A006-743F0F84911E)
283 "swap" = PARTITION_LINUX_SWAP_GUID
284 (0657FD6D-A4AB-43C4-84E5-0933C84B4F4F)
285 "lvm" = PARTITION_LINUX_LVM_GUID
286 (E6D6D379-F507-44C2-A23C-238F2A3DF928)
287 "u-boot-env" = PARTITION_U_BOOT_ENVIRONMENT
288 (3DE21764-95BD-54BD-A5C3-4ABE786F38A8)
289
290 "uuid_disk=...;name=u-boot,size=60MiB,uuid=...;
291 name=kernel,size=60MiB,uuid=...,type=linux;"
292
293They are also used to display the type of partition in "part list" command.
294
295
296Useful info:
297============
298
299Two programs, namely: 'gdisk' and 'parted' are recommended to work with GPT
300recovery. Both are able to handle GUID partitions.
301Please, pay attention at -l switch for parted.
302
303"uuid" program is recommended to generate UUID string. Moreover it can decode
304(-d switch) passed in UUID string. It can be used to generate partitions UUID
305passed to u-boot environment variables.
306If optional CONFIG_RANDOM_UUID is defined then for any partition which environment
307uuid is unset, uuid is randomly generated and stored in correspond environment
308variable.
309
310note:
311Each string block of UUID generated by program "uuid" is in big endian and it is
312also stored in big endian in disk GPT.
313Partitions layout can be printed by typing "mmc part". Note that each partition
314GUID has different byte order than UUID generated before, this is because first
315three blocks of GUID string are in Little Endian.
316
README.Heterogeneous-SoCs
1DSP side awareness for Freescale heterogeneous multicore chips based on
2StarCore and Power Architecture
3===============================================================
4powerpc/mpc85xx code ve APIs and function to get the number,
5configuration and frequencies of all PowerPC cores and devices
6connected to them, but it didnt have the similar code ofr HEterogeneous
7SC3900/DSP cores and such devices like CPRI, MAPLE, MAPLE-ULB etc.
8
9Code for DSP side awareness provides such functionality for Freescale
10Heterogeneous SoCs which are chasis-2 compliant like B4860 and B4420
11
12As part of this feature, following changes have been made:
13==========================================================
14
151. Changed files:
16=================
17- arch/powerpc/cpu/mpc85xx/cpu.c
18
19Code added in this file to print the DSP cores and other device's(CPRI,
20MAPLE etc) frequencies
21
22- arch/powerpc/cpu/mpc85xx/speed.c
23
24Added Defines and code to extract the frequncy information for all
25required cores and devices from RCW and System frequency
26
27- arch/powerpc/cpu/mpc8xxx/cpu.c
28
29Added API to get the number of SC cores in running system and Their BIT
30MASK, similar to the code written for PowerPC
31
32- arch/powerpc/include/asm/config_mpc85xx.h
33
34Added top level CONFIG to identify presence of HETEROGENUOUS clusters
35in the system and CONFIGS for SC3900/DSP components
36
37- arch/powerpc/include/asm/processor.h
38- include/common.h
39
40Added newly added Functions Declaration
41
42- include/e500.h
43
44Global structure updated for dsp cores and other components
45
462. CONFIGs ADDED
47================
48
49CONFIG_HETROGENOUS_CLUSTERS - Define for checking the presence of
50 DSP/SC3900 core clusters
51
52CONFIG_SYS_FSL_NUM_CC_PLLS - Define for number of PLLs
53
54Though there are only 4 PLLs in B4, but in sequence of PLLs from PLL1 -
55PLL5, PLL3 is Reserved(as mentioned in RM), so this define contains the
56value as 5 not 4, to iterate over all PLLs while coding
57
58CONFIG_SYS_MAPLE - Define for MAPLE Baseband Accelerator
59CONFIG_SYS_CPRI - Define for CPRI Interface
60CONFIG_PPC_CLUSTER_START - Start index of ppc clusters
61CONFIG_DSP_CLUSTER_START - Start index of dsp clusters
62
63Following are the defines for PLL's index that provide the Clocking to
64CPRI, ULB and ETVE components
65
66CONFIG_SYS_CPRI_CLK - Define PLL index for CPRI clock
67CONFIG_SYS_ULB_CLK - Define PLL index for ULB clock
68CONFIG_SYS_ETVPE_CLK - Define PLL index for ETVPE clock
69
703. Changes in MPC85xx_SYS_INFO Global structure
71===============================================
72
73DSP cores and other device's components have been added in this structure.
74
75freq_processor_dsp[CONFIG_MAX_DSP_CPUS] - Array to contain the DSP core's frequencies
76freq_cpri - To store CPRI frequency
77freq_maple - To store MAPLE frequency
78freq_maple_ulb - To store MAPLE-ULB frequency
79freq_maple_etvpe - To store MAPLE-eTVPE frequency
80
814. U-BOOT LOGS
82==============
834.1 B4860QDS board
84 Boot from NOR flash
85
86U-Boot 2014.07-00222-g70587a8-dirty (Aug 07 2014 - 13:15:47)
87
88CPU0: B4860E, Version: 2.0, (0x86880020)
89Core: e6500, Version: 2.0, (0x80400020) Clock Configuration:
90 CPU0:1600 MHz, CPU1:1600 MHz, CPU2:1600 MHz, CPU3:1600 MHz,
91 DSP CPU0:1200 MHz, DSP CPU1:1200 MHz, DSP CPU2:1200 MHz, DSP CPU3:1200 MHz,
92 DSP CPU4:1200 MHz, DSP CPU5:1200 MHz,
93 CCB:666.667 MHz,
94 DDR:933.333 MHz (1866.667 MT/s data rate) (Asynchronous), IFC:166.667 MHz
95 CPRI:600 MHz
96 MAPLE:600 MHz, MAPLE-ULB:800 MHz, MAPLE-eTVPE:1000 MHz
97 FMAN1: 666.667 MHz
98 QMAN: 333.333 MHz
99
100CPUn - PowerPC core
101DSP CPUn - SC3900 core
102
103Shaveta Leekha(shaveta@freescale.com)
104Created August 7, 2014
105===========================================
106
README.hwconfig
1This implements a simple hwconfig infrastructure: an
2interface for software knobs to control hardware.
3
4This a is very simple implementation, i.e. it is implemented
5via the `hwconfig' environment variable. Later we could write
6some "hwconfig <enable|disable|list>" commands, ncurses
7interface for Award BIOS-like interface, and frame-buffer
8interface for AMI GUI[1] BIOS-like interface with mouse
9support[2].
10
11Current implementation details/limitations:
12
131. Doesn't support options dependencies and mutual exclusion.
14 We can implement this by integrating apt-get[3] into Das
15 U-Boot. But I haven't bothered yet.
16
172. Since we don't implement a hwconfig command, i.e. we're working
18 with the environment directly, there is no way to tell that
19 toggling a particular option will need a reboot to take
20 effect. So, for now it's advised to always reboot the
21 target after modifying the hwconfig variable.
22
233. We support hwconfig options with arguments. For example,
24
25 set hwconfig "dr_usb:mode=peripheral,phy_type=ulpi"
26
27 This selects three hwconfig options:
28 1. dr_usb - enable Dual-Role USB controller;
29 2. dr_usb_mode:peripheral - USB in Function mode;
30 3. dr_usb_phy_type:ulpi - USB should work with ULPI PHYs.
31
32The purpose of this simple implementation is to refine the
33internal API and then we can continue improving the user
34experience by adding more mature interfaces, like a hwconfig
35command with bells and whistles. Or not adding, if we feel
36that the current interface fits people's needs.
37
38[1] http://en.wikipedia.org/wiki/American_Megatrends
39[2] Regarding ncurses and GUI with mouse support -- I'm just
40 kidding.
41[3] The comment regarding apt-get is also a joke, meaning that
42 dependency tracking could be non-trivial. For example, for
43 enabling HW feature X we may need to disable Y, and turn Z
44 into reduced mode (like RMII-only interface for ethernet,
45 no MII).
46
47 It's quite trivial to implement simple cases though.
48
README.i2c
1I2C Bus Arbitration
2===================
3
4While I2C supports multi-master buses this is difficult to get right.
5The implementation on the master side in software is quite complex.
6Clock-stretching and the arbitrary time that an I2C transaction can take
7make it difficult to share the bus fairly in the face of high traffic.
8When one or more masters can be reset independently part-way through a
9transaction it is hard to know the state of the bus.
10
11U-Boot provides a scheme based on two 'claim' GPIOs, one driven by the
12AP (Application Processor, meaning the main CPU) and one driven by the EC
13(Embedded Controller, a small CPU aimed at handling system tasks). With
14these they can communicate and reliably share the bus. This scheme has
15minimal overhead and involves very little code. The scheme can survive
16reboots by either side without difficulty.
17
18Since U-Boot runs on the AP, the terminology used is 'our' claim GPIO,
19meaning the AP's, and 'their' claim GPIO, meaning the EC's. This terminology
20is used by the device tree bindings in Linux also.
21
22The driver is implemented as an I2C mux, as it is in Linux. See
23i2c-arb-gpio-challenge for the implementation.
24
25GPIO lines are shared between the AP and EC to manage the bus. The AP and EC
26each have a 'bus claim' line, which is an output that the other can see.
27
28- AP_CLAIM: output from AP, signalling to the EC that the AP wants the bus
29- EC_CLAIM: output from EC, signalling to the AP that the EC wants the bus
30
31The basic algorithm is to assert your line when you want the bus, then make
32sure that the other side doesn't want it also. A detailed explanation is best
33done with an example.
34
35Let's say the AP wants to claim the bus. It:
36
371. Asserts AP_CLAIM
382. Waits a little bit for the other side to notice (slew time)
393. Checks EC_CLAIM. If this is not asserted, then the AP has the bus, and we
40 are done
414. Otherwise, wait for a few milliseconds (retry time) and see if EC_CLAIM is
42 released
435. If not, back off, release the claim and wait for a few more milliseconds
44 (retry time again)
456. Go back to 1 if things don't look wedged (wait time has expired)
467. Panic. The other side is hung with the CLAIM line set.
47
48The same algorithm applies on the EC.
49
50To release the bus, just de-assert the claim line.
51
52Typical delays are:
53- slew time 10 us
54- retry time 3 ms
55- wait time - 50ms
56
57In general the traffic is fairly light, and in particular the EC wants access
58to the bus quite rarely (maybe every 10s or 30s to check the battery). This
59scheme works very nicely with very low contention. There is only a 10 us
60wait for access to the bus assuming that the other side isn't using it.
61
README.iomux
1SPDX-License-Identifier: GPL-2.0+
2/*
3 * (C) Copyright 2008
4 * Gary Jennejohn, DENX Software Engineering GmbH <garyj@denx.de>
5 */
6
7U-Boot console multiplexing
8===========================
9
10HOW CONSOLE MULTIPLEXING WORKS
11------------------------------
12
13This functionality is controlled with CONFIG_CONSOLE_MUX in the board
14configuration file.
15
16Two new files, common/iomux.c and include/iomux.h, contain the heart
17(iomux_doenv()) of the environment setting implementation.
18
19iomux_doenv() is called in common/cmd_nvedit.c to handle setenv and in
20common/console.c in console_init_r() during bootup to initialize
21stdio_devices[].
22
23A user can use a comma-separated list of devices to set stdin, stdout
24and stderr. For example: "setenv stdin serial,nc". NOTE: No spaces
25are allowed around the comma(s)!
26
27The length of the list is limited by malloc(), since the array used
28is allocated and freed dynamically.
29
30It should be possible to specify any device which console_assign()
31finds acceptable, but the code has only been tested with serial and
32nc.
33
34iomux_doenv() prevents multiple use of the same device, e.g. "setenv
35stdin nc,nc,serial" will discard the second nc. iomux_doenv() is
36not able to modify the environment, however, so that "pri stdin" still
37shows "nc,nc,serial".
38
39The major change in common/console.c was to modify fgetc() to call
40the iomux_tstc() routine in a for-loop. iomux_tstc() in turn calls
41the tstc() routine for every registered device, but exits immediately
42when one of them returns true. fgetc() then calls iomux_getc(),
43which calls the corresponding getc() routine. fgetc() hangs in
44the for-loop until iomux_tstc() returns true and the input can be
45retrieved.
46
47Thus, a user can type into any device registered for stdin. No effort
48has been made to demulitplex simultaneous input from multiple stdin
49devices.
50
51fputc() and fputs() have been modified to call iomux_putc() and
52iomux_puts() respectively, which call the corresponding output
53routines for every registered device.
54
55Thus, a user can see the ouput for any device registered for stdout
56or stderr on all devices registered for stdout or stderr. As an
57example, if stdin=serial,nc and stdout=serial,nc then all output
58for serial, e.g. echos of input on serial, will appear on serial and nc.
59
60Just as with the old console code, this statement is still true:
61If not defined in the environment, the first input device is assigned
62to the 'stdin' file, the first output one to 'stdout' and 'stderr'.
63
64If CONFIG_SYS_CONSOLE_IS_IN_ENV is defined then multiple input/output
65devices can be set at boot time if defined in the environment.
66
67CAVEATS
68-------
69
70Note that common/iomux.c calls console_assign() for every registered
71device as it is discovered. This means that the environment settings
72for application consoles will be set to the last device in the list.
73
74On a slow machine, such as MPC852T clocked at 66MHz, the overhead associated
75with calling tstc() and then getc() means that copy&paste will normally not
76work, even when stdin=stdout=stderr=serial.
77On a faster machine, such as a sequoia, cut&paste of longer (about 80
78characters) lines works fine when serial is the only device used.
79
80Using nc as a stdin device results in even more overhead because nc_tstc()
81is quite slow. Even on a sequoia cut&paste does not work on the serial
82interface when nc is added to stdin, although there is no character loss using
83the ethernet interface for input. In this test case stdin=serial,nc and
84stdout=serial.
85
86In addition, the overhead associated with sending to two devices, when one of
87them is nc, also causes problems. Even on a sequoia cut&paste does not work
88on the serial interface (stdin=serial) when nc is added to stdout (stdout=
89serial,nc).
90
README.JFFS2_NAND
1JFFS2 NAND support:
2
3To enable, use the following #define in the board configuration file:
4
5#define CONFIG_JFFS2_NAND
6
7Configuration of partitions is similar to how this is done in U-Boot
8for JFFS2 on top NOR flash.
9
README.kconfig
1Kconfig in U-Boot
2=================
3
4This document describes the configuration infrastructure of U-Boot.
5
6The conventional configuration was replaced by Kconfig at v2014.10-rc1 release.
7
8
9Language Specification
10----------------------
11
12Kconfig originates in Linux Kernel.
13See the file "Documentation/kbuild/kconfig*.txt" in your Linux Kernel
14source directory for a basic specification of Kconfig.
15
16
17Difference from Linux's Kconfig
18-------------------------------
19
20Here are some worth-mentioning configuration targets.
21
22- silentoldconfig
23
24 This target updates .config, include/generated/autoconf.h and
25 include/configs/* as in Linux. In U-Boot, it also does the following
26 for the compatibility with the old configuration system:
27
28 * create a symbolic link "arch/${ARCH}/include/asm/arch" pointing to
29 the SoC/CPU specific header directory
30 * create include/config.h
31 * create include/autoconf.mk
32 * create spl/include/autoconf.mk (SPL and TPL only)
33 * create tpl/include/autoconf.mk (TPL only)
34
35 If we could completely switch to Kconfig in a long run
36 (i.e. remove all the include/configs/*.h), those additional processings
37 above would be removed.
38
39- defconfig
40
41 In U-Boot, "make defconfig" is a shorthand of "make sandbox_defconfig"
42
43- <board>_defconfig
44
45 Now it works as in Linux.
46 The prefixes such as "+S:" in *_defconfig are deprecated.
47 You can simply remove the prefixes. Do not add them for new boards.
48
49- <board>_config
50
51 This does not exist in Linux's Kconfig.
52 "make <board>_config" works the same as "make <board>_defconfig".
53 Prior to Kconfig, in U-Boot, "make <board>_config" was used for the
54 configuration. It is still supported for backward compatibility, so
55 we do not need to update the distro recipes.
56
57
58The other configuration targets work as in Linux Kernel.
59
60
61Migration steps to Kconfig
62--------------------------
63
64Prior to Kconfig, the C preprocessor based board configuration had been used
65in U-Boot.
66
67Although Kconfig was introduced and some configs have been moved to Kconfig,
68many of configs are still defined in C header files. It will take a very
69long term to move all of them to Kconfig. In the interim, the two different
70configuration infrastructures should coexist.
71The configuration files are generated by both Kconfig and the old preprocessor
72based configuration as follows:
73
74Configuration files for use in C sources
75 - include/generated/autoconf.h (generated by Kconfig for Normal)
76 - include/configs/<board>.h (exists for all boards)
77
78Configuration file for use in makefiles
79 - include/config/auto.conf (generated by Kconfig)
80 - include/autoconf.mk (generated by the old config for Normal)
81 - spl/include/autoconfig.mk (generated by the old config for SPL)
82 - tpl/include/autoconfig.mk (generated by the old config for TPL)
83
84When adding a new CONFIG macro, it is highly recommended to add it to Kconfig
85rather than to a header file.
86
87
88Conversion from boards.cfg to Kconfig
89-------------------------------------
90
91Prior to Kconfig, boards.cfg was a primary database that contained Arch, CPU,
92SoC, etc. of all the supported boards. It was deleted when switching to
93Kconfig. Each field of boards.cfg was converted as follows:
94
95 Status -> "S:" entry of MAINTAINERS
96 Arch -> CONFIG_SYS_ARCH defined by Kconfig
97 CPU -> CONFIG_SYS_CPU defined by Kconfig
98 SoC -> CONFIG_SYS_SOC defined by Kconfig
99 Vendor -> CONFIG_SYS_VENDOR defined by Kconfig
100 Board -> CONFIG_SYS_BOARD defined by Kconfig
101 Target -> File name of defconfig (configs/<target>_defconfig)
102 Maintainers -> "M:" entry of MAINTAINERS
103
104
105Tips to add/remove boards
106-------------------------
107
108When adding a new board, the following steps are generally needed:
109
110 [1] Add a header file include/configs/<target>.h
111 [2] Make sure to define necessary CONFIG_SYS_* in Kconfig:
112 Define CONFIG_SYS_CPU="cpu" to compile arch/<arch>/cpu/<cpu>
113 Define CONFIG_SYS_SOC="soc" to compile arch/<arch>/cpu/<cpu>/<soc>
114 Define CONFIG_SYS_VENDOR="vendor" to compile board/<vendor>/common/*
115 and board/<vendor>/<board>/*
116 Define CONFIG_SYS_BOARD="board" to compile board/<board>/*
117 (or board/<vendor>/<board>/* if CONFIG_SYS_VENDOR is defined)
118 Define CONFIG_SYS_CONFIG_NAME="target" to include
119 include/configs/<target>.h
120 [3] Add a new entry to the board select menu in Kconfig.
121 The board select menu is located in arch/<arch>/Kconfig or
122 arch/<arch>/*/Kconfig.
123 [4] Add a MAINTAINERS file
124 It is generally placed at board/<board>/MAINTAINERS or
125 board/<vendor>/<board>/MAINTAINERS
126 [5] Add configs/<target>_defconfig
127
128When removing an obsolete board, the following steps are generally needed:
129
130 [1] Remove configs/<target>_defconfig
131 [2] Remove include/configs/<target>.h if it is not used by any other boards
132 [3] Remove board/<vendor>/<board>/* or board/<board>/* if it is not used
133 by any other boards
134 [4] Update MAINTAINERS if necessary
135 [5] Remove the unused entry from the board select menu in Kconfig
136 [6] Add an entry to doc/README.scrapyard
137
138
139TODO
140----
141
142- In the pre-Kconfig, a single board had multiple entries in the boards.cfg
143 file with differences in the option fields. The corresponding defconfig
144 files were auto-generated when switching to Kconfig. Now we have too many
145 defconfig files compared with the number of the supported boards. It is
146 recommended to have only one defconfig per board and allow users to select
147 the config options.
148
149- Move the config macros in header files to Kconfig. When we move at least
150 macros used in makefiles, we can drop include/autoconfig.mk, which makes
151 the build scripts much simpler.
152
README.kwbimage
1---------------------------------------------
2Kirkwood Boot Image generation using mkimage
3---------------------------------------------
4
5This document describes the U-Boot feature as it
6is implemented for the Kirkwood family of SoCs.
7
8The Kirkwood SoC's can boot directly from NAND FLASH,
9SPI FLASH, SATA etc. using its internal bootRom support.
10
11for more details refer section 24.2 of Kirkwood functional specifications.
12ref: www.marvell.com/products/embedded.../kirkwood/index.jsp
13
14Command syntax:
15--------------
16./tools/mkimage -l <kwboot_file>
17 to list the kwb image file details
18
19./tools/mkimage -n <board specific configuration file> \
20 -T kwbimage -a <start address> -e <execution address> \
21 -d <input_raw_binary> <output_kwboot_file>
22
23for ex.
24./tools/mkimage -n ./board/Marvell/openrd_base/kwbimage.cfg \
25 -T kwbimage -a 0x00600000 -e 0x00600000 \
26 -d u-boot.bin u-boot.kwb
27
28
29kwbimage support available with mkimage utility will generate kirkwood boot
30image that can be flashed on the board NAND/SPI flash. The make target
31which uses mkimage to produce such an image is "u-boot.kwb". For example:
32
33 export KBUILD_OUTPUT=/tmp/build
34 make distclean
35 make yourboard_config
36 make u-boot.kwb
37
38
39Board specific configuration file specifications:
40------------------------------------------------
411. This file must present in the $(BOARDDIR). The default name is
42 kwbimage.cfg. The name can be set as part of the full path
43 to the file using CONFIG_SYS_KWD_CONFIG (probably in
44 include/configs/<yourboard>.h). The path should look like:
45 $(CFG_BOARDDIR)/<yourkwbimagename>.cfg
462. This file can have empty lines and lines starting with "#" as first
47 character to put comments
483. This file can have configuration command lines as mentioned below,
49 any other information in this file is treated as invalid.
50
51Configuration command line syntax:
52---------------------------------
531. Each command line is must have two strings, first one command or address
54 and second one data string
552. Following are the valid command strings and associated data strings:-
56 Command string data string
57 -------------- -----------
58 BOOT_FROM nand/spi/sata
59 NAND_ECC_MODE default/rs/hamming/disabled
60 NAND_PAGE_SIZE any uint16_t hex value
61 SATA_PIO_MODE any uint32_t hex value
62 DDR_INIT_DELAY any uint32_t hex value
63 DATA regaddr and regdara hex value
64 you can have maximum 55 such register programming commands
65
663. All commands are optional to program
67
68Typical example of kwimage.cfg file:
69-----------------------------------
70
71# Boot Media configurations
72BOOT_FROM nand
73NAND_ECC_MODE default
74NAND_PAGE_SIZE 0x0800
75
76# Configure RGMII-0 interface pad voltage to 1.8V
77DATA 0xFFD100e0 0x1b1b1b9b
78# DRAM Configuration
79DATA 0xFFD01400 0x43000c30
80DATA 0xFFD01404 0x37543000
81DATA 0xFFD01408 0x22125451
82DATA 0xFFD0140C 0x00000a33
83DATA 0xFFD01410 0x000000cc
84DATA 0xFFD01414 0x00000000
85DATA 0xFFD01418 0x00000000
86DATA 0xFFD0141C 0x00000C52
87DATA 0xFFD01420 0x00000040
88DATA 0xFFD01424 0x0000F17F
89DATA 0xFFD01428 0x00085520
90DATA 0xFFD0147C 0x00008552
91DATA 0xFFD01504 0x0FFFFFF1
92DATA 0xFFD01508 0x10000000
93DATA 0xFFD0150C 0x0FFFFFF5
94DATA 0xFFD01514 0x00000000
95DATA 0xFFD0151C 0x00000000
96DATA 0xFFD01494 0x00030000
97DATA 0xFFD01498 0x00000000
98DATA 0xFFD0149C 0x0000E803
99DATA 0xFFD01480 0x00000001
100# End of Header extension
101DATA 0x0 0x0
102
103------------------------------------------------
104Author: Prafulla Wadaskar <prafulla@marvell.com>
105
README.LED
1Status LED
2========================================
3
4This README describes the status LED API.
5
6The API is defined by the include file include/status_led.h
7
8The first step is to enable CONFIG_LED_STATUS in menuconfig:
9> Device Drivers > LED Support.
10
11If the LED support is only for specific board, enable
12CONFIG_LED_STATUS_BOARD_SPECIFIC in the menuconfig.
13
14Status LEDS 0 to 5 are enabled by the following configurations at menuconfig:
15CONFIG_STATUS_LED0, CONFIG_STATUS_LED1, ... CONFIG_STATUS_LED5
16
17The following should be configured for each of the enabled LEDs:
18CONFIG_STATUS_LED_BIT<n>
19CONFIG_STATUS_LED_STATE<n>
20CONFIG_STATUS_LED_FREQ<n>
21Where <n> is an integer 1 through 5 (empty for 0).
22
23CONFIG_STATUS_LED_BIT is passed into the __led_* functions to identify which LED
24is being acted on. As such, the value choose must be unique with with respect to
25the other CONFIG_STATUS_LED_BIT's. Mapping the value to a physical LED is the
26reponsiblity of the __led_* function.
27
28CONFIG_STATUS_LED_STATE is the initial state of the LED. It should be set to one
29of these values: CONFIG_LED_STATUS_OFF or CONFIG_LED_STATUS_ON.
30
31CONFIG_STATUS_LED_FREQ determines the LED blink frequency.
32Values range from 2 to 10.
33
34Some other LED macros
35---------------------
36
37CONFIG_STATUS_LED_BOOT is the LED to light when the board is booting.
38This must be a valid LED number (0-5).
39
40CONFIG_STATUS_LED_RED is the red LED. It is used to signal errors. This must be
41a valid LED number (0-5). Other similar color LED's macros are
42CONFIG_STATUS_LED_GREEN, CONFIG_STATUS_LED_YELLOW and CONFIG_STATUS_LED_BLUE.
43
44General LED functions
45---------------------
46The following functions should be defined:
47
48__led_init is called once to initialize the LED to CONFIG_STATUS_LED_STATE.
49One time start up code should be placed here.
50
51__led_set is called to change the state of the LED.
52
53__led_toggle is called to toggle the current state of the LED.
54
55Colour LED
56========================================
57
58Colour LED's are at present only used by ARM.
59
60The functions names explain their purpose.
61
62coloured_LED_init
63red_LED_on
64red_LED_off
65green_LED_on
66green_LED_off
67yellow_LED_on
68yellow_LED_off
69blue_LED_on
70blue_LED_off
71
72These are weakly defined in arch/arm/lib/board.c to noops. Where applicable, define
73these functions in the board specific source.
74
75TBD : Describe older board dependent macros similar to what is done for
76
77TBD : Describe general support via asm/status_led.h
78
README.link-local
1------------------------------------------
2 Link-local IP address auto-configuration
3------------------------------------------
4
5Negotiate with other link-local clients on the local network
6for an address that doesn't require explicit configuration.
7This is especially useful if a DHCP server cannot be guaranteed
8to exist in all environments that the device must operate.
9
10This is an implementation of RFC3927.
11
12----------
13 Commands
14----------
15
16When CONFIG_CMD_LINK_LOCAL is defined in the board config file,
17the "linklocal" command is available. This running this will
18take approximately 5 seconds while the address is negotiated.
19
20------------------------
21 Environment interation
22------------------------
23
24The "llipaddr" variable is set with the most recently
25negotiated address and is preferred in future negotiations.
26
27The "ipaddr", "netmask", and "gatewayip" variables are set
28after successful negotiation to enable network access.
29
30-------------
31 Limitations
32-------------
33
34RFC3927 requires that addresses are continuously checked to
35avoid conflicts, however this can only happen when the net_loop
36is getting called. It is possible for a conflict to go undetected
37until a command that accesses the network is executed.
38
39Using NetConsole is one way to ensure that net_loop is always
40processing packets and monitoring for conflicts.
41
42This is also not a concern if the feature is use to connect
43directly to another machine that may not be running a DHCP server.
44
45----------------
46 Example script
47----------------
48
49This script allows use of DHCP and/or Link-local controlled
50by env variables. It depends on CONFIG_CMD_LINK_LOCAL, CONFIG_CMD_DHCP,
51and CONFIG_BOOTP_MAY_FAIL.
52If both fail or are disabled, static settings are used.
53
54#define CFG_EXTRA_ENV_SETTINGS \
55 "ipconfigcmd=if test \\\"$dhcpenabled\\\" -ne 0;" \
56 "then " \
57 "dhcpfail=0;dhcp || dhcpfail=1;" \
58 "else " \
59 "dhcpfail=-1;" \
60 "fi;" \
61 "if test \\\"$linklocalenabled\\\" -ne 0 -a " \
62 "\\\"$dhcpfail\\\" -ne 0;" \
63 "then " \
64 "linklocal;" \
65 "llfail=0;" \
66 "else " \
67 "llfail=-1;" \
68 "fi;" \
69 "if test \\\"$llfail\\\" -ne 0 -a " \
70 "\\\"$dhcpfail\\\" -ne 0; " \
71 "then " \
72 "setenv ipaddr $sipaddr; " \
73 "setenv netmask $snetmask; " \
74 "setenv gatewayip $sgatewayip; " \
75 "fi;\0" \
76
README.malta
README.marvell
1Marvell U-Boot Build Instructions
2=================================
3
4This document describes how to compile the U-Boot and how to change U-Boot configuration
5
6Build Procedure
7----------------
81. Install required packages:
9
10 # sudo apt-get install libssl-dev
11 # sudo apt-get install device-tree-compiler
12 # sudo apt-get install swig libpython-dev
13
142. Set the cross compiler:
15
16 # sudo apt-get install gcc-aarch64-linux-gnu
17 # export CROSS_COMPILE=aarch64-linux-gnu-
18
193. Clean-up old residuals:
20
21 # make mrproper
22
234. Configure the U-Boot:
24
25 # make <defconfig_file>
26
27 - For the Armada-70x0/80x0 DB board use "mvebu_db_armada8k_defconfig"
28 - For the Armada-80x0 MacchiatoBin use "make mvebu_mcbin-88f8040_defconfig"
29 - For the Armada-3700 DB board use "make mvebu_db-88f3720_defconfig"
30 - For the Armada-3700 EspressoBin use "make mvebu_espressobin-88f3720_defconfig"
31
325. Configure the device-tree and build the U-Boot image:
33
34 For the Armada-70x0/80x0 DB board compile u-boot and set the required device-tree using:
35
36 # make DEVICE_TREE=<name>
37
38 NOTE:
39 Compilation with "mvebu_db_armada8k_defconfig" requires explicitly exporting DEVICE_TREE
40 for the requested board.
41 By default, u-boot is compiled with armada-8040-db device-tree.
42 Using A80x0 device-tree on A70x0 might break the device.
43 In order to prevent this, the required device-tree MUST be set during compilation.
44 All device-tree files are located in ./arch/arm/dts/ folder.
45
46 For other DB boards (MacchiatoBin, EspressoBin and 3700 DB board) compile u-boot with
47 just default device-tree from defconfig using:
48
49 # make
50
51 NOTE:
52 The u-boot.bin should not be used as a stand-alone image.
53 The ARM Trusted Firmware (ATF) build process uses this image to generate the
54 flash image. See TF-A Build Instructions for Marvell Platforms for more details at:
55 https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/build.html
56
57Configuration update
58---------------------
59 To update the U-Boot configuration, please refer to doc/README.kconfig
60
61
62Permanent ethernet MAC address
63-------------------------------
64 Prior flashing new U-Boot version (as part of ATF image) it is suggested to backup
65 permanent ethernet MAC addresses as they are stored only in U-Boot env storage (SPI or eMMC).
66 Some boards like EspressoBin have MAC addresses printed on sticker. Some boards got assigned
67 only one address other may also more than one. To print current MAC addresses run:
68
69 # echo $ethaddr
70 # echo $eth1addr
71 # echo $eth2addr
72 # echo $eth3addr
73 # ...
74
75 MAC addresses 00:51:82:11:22:00, 00:51:82:11:22:01, 00:51:82:11:22:02, 00:51:82:11:22:03
76 and F0:AD:4E:03:64:7F are default hardcoded values found in Marvell's and Armbian U-Boot
77 forks and therefore *not* unique. Usage of static hardcoded MAC addresses should be avoided.
78 When original address is lost (e.g. erased by Armbian boot scripts for EspressoBin) it is
79 suggested to generate new random one.
80
81 After flashing new U-Boot version it is suggested to reset U-Boot env variables to default
82 and then set correct permanent ethernet MAC addresses.
83
84 # env default -a
85 # setenv ethaddr XX:XX:XX:XX:XX:XX
86 # setenv eth1addr XX:XX:XX:XX:XX:XX
87 # setenv eth2addr YY:YY:YY:YY:YY:YY
88 # setenv eth3addr ZZ:ZZ:ZZ:ZZ:ZZ:ZZ
89 # ...
90 # saveenv
91
92 Where value for ethaddr is required permanent ethernet MAC address and values for ethNaddr
93 are optional per-port MAC addresses. When optional ethNaddr variables are not defined then
94 they are inherited from required ethaddr variable. eth1addr contains MAC address for the
95 wan port, other for particular lan ports.
96
97 Recent Linux kernel versions use correct permanent ethernet MAC address from U-Boot env as
98 U-Boot will inject it into kernel's device-tree.
99
README.mediatek
1# SPDX-License-Identifier: GPL-2.0+
2#
3# Copyright (C) 2018 MediaTek Inc.
4# Ryder Lee <ryder.lee@kernel.org>
5
6
7This document describes how to compile the U-Boot and how to change U-Boot
8configuration about the MediaTek SoCs.
9
10
11Build Procedure
12===============
13 -Set the cross compiler:
14
15 # export CROSS_COMPILE=/path/to/toolchain/arm-linux-gnueabi-
16
17 -Clean-up old residuals:
18
19 # make mrproper
20
21 -Configure the U-Boot:
22
23 # make <defconfig_file>
24 # make
25
26 - For the MT7623n bananapi R2 board use "mt7623n_bpir2_defconfig"
27 - For the MT7629 reference board use "mt7629_rfb_defconfig"
28
29
30Boot sequence
31=============
32 -Bootrom -> MTK preloader -> U-Boot
33
34 - MT7623n
35
36 This version of U-Boot doesn't implement SPL. So, MTK preloader binary
37 is needed to boot up:
38
39 https://github.com/BPI-SINOVOIP/BPI-R2-bsp/tree/master/mt-pack/mtk/bpi-r2/bin
40
41
42 -Bootrom -> SPL -> U-Boot
43
44 - MT7629
45
46
47Configuration update
48====================
49 To update the U-Boot configuration, please refer to doc/README.kconfig
50
51
52MediaTek image header
53=====================
54Currently there are two image headers used for MediaTek chips:
55
56 - BootROM image header. This header is used by the first stage bootloader. It records
57 the desired compatible boot device, integrity information and its load address.
58
59 The on-chip BootROM will firstly verify integrity and compatibility of the bootloader.
60
61 If verification passed, the BootROM will then load the bootloader into on-chip SRAM,
62 and pass control to it.
63
64 Note that this header is actually a combination of three independent headers:
65 Device header, BRLYT header and GFH header.
66
67 Used by U-Boot SPL of MT7629 and preloader of MT7623.
68
69
70 - MediaTek legacy image header. This header was originally used by the legacy image. It
71 basically records the load address, image size and image name.
72
73 After all low level initializations passed, the preloader will locate the LK image and
74 load it into DRAM, and pass control to it.
75
76 Now this header is used by U-Boot of MT7623.
77
78
79To generate these two headers with mkimage:
80
81 # mkimage -T mtk_image -a <load_addr> -n <option_string> -d <input_file> <image_file>
82
83 - mtk_image means using MediaTek's header generation method.
84
85
86 - load_addr is the load address of this image.
87 For first stage bootloader like U-Boot SPL or preloader, it usually points to the
88 on-chip SRAM.
89
90 For second stage bootloader like U-Boot, it usually points to the DRAM.
91
92
93 - option_string contains options to generate the header.
94
95 The option string is using the follow format:
96 key1=value1;key2=value2;...
97
98 The following key names are valid:
99 lk: If lk=1, LK image header is used. Otherwise BootROM image header is used.
100
101 lkname: The name of the LK image header. The maximum length is 32.
102 The default value is "U-Boot".
103
104 media: Desired boot device. The valid values are:
105 nand : Parallel NAND
106 snand: Serial NAND
107 nor : Serial NOR
108 emmc : eMMC
109 sdmmc: SD
110
111 nandinfo: Desired NAND device type, a combination of page size, oob size and
112 optional device capacity. Valid types are:
113 2k+64 : for Serial NAND, 2KiB page size + 64B oob size
114 2k+120 : for Serial NAND, 2KiB page size + 120B oob size
115 2k+128 : for Serial NAND, 2KiB page size + 128B oob size
116 4k+256 : for Serial NAND, 4KiB page size + 256B oob size
117 1g:2k+64 : for Parallel NAND, 2KiB page size + 64B oob size, total 1Gbit size
118 2g:2k+64 : for Parallel NAND, 2KiB page size + 64B oob size, total 2Gbit size
119 4g:2k+64 : for Parallel NAND, 2KiB page size + 64B oob size, total 4Gbit size
120 2g:2k+128: for Parallel NAND, 2KiB page size + 128B oob size, total 2Gbit size
121 4g:2k+128: for Parallel NAND, 2KiB page size + 128B oob size, total 4Gbit size
122
123
124MT7629 partitions on Serial NOR
125===============================
126
127 Start End Size Description
128 00000000 - 0000ffff: 64KiB U-Boot SPL
129 00010000 - 0005ffff: 320KiB U-Boot
130 00060000 - 0006ffff: 64KiB U-Boot env / MediaTek NVRAM
131 00070000 - 000affff: 256KiB RF calibration data
132 000b0000 - xxxxxxxx: all left Firmware image
133
134
135BPi-R2 (MT7623N) partitions on SD
136=================================
137 Please note that the last two partitions can vary from different Linux distributions
138 depending on the MBR partition table.
139
140 Start End Size Description
141 00000000 - 000001ff: 512B Device header (with MBR partition table)
142 00000200 - 000007ff: 1536B BRLYT header
143 00000800 - 0004ffff: 318KiB Preloader (with GFH header)
144 00050000 - 000fffff: 704KiB U-Boot
145 00100000 - 063fffff: 99MiB Reserved
146 06400000 - 163fffff: 256MiB Partition 1 (FAT32)
147 16400000 - xxxxxxxx: all left Partition 2 (ext4)
148
149
150Upgrading notice on Serial NOR
151==============================
152Example: MT7629
153
154 The command sf is used to operate the Serial NOR device:
155
156 - To probe current NOR flash:
157
158 # sf probe
159
160 - To erase a region:
161
162 # sf erase <offset> <len>
163
164 - To write data to an offset:
165
166 # sf write <data_addr> <offset> <len>
167
168 - To boot kernel:
169
170 # bootm 0x300b0000
171
172 The memory address range 0x30000000 - 0x3fffffff is mapped to the NOR flash.
173 The DRAM starts at 0x40000000.
174
175 Please note that the output binary u-boot-mtk.bin is a combination of SPL and U-Boot,
176 and it should be write to beginning of the flash.
177
178 Otherwise you should use standalone files:
179
180 spl/u-boot-spl-mtk.bin for SPL,
181 u-boot.img for U-Boot.
182
183
184Upgrading notice on SD / eMMC
185=============================
186Example: MT7623
187
188 Normally only Preloader and U-Boot can be upgraded within U-Boot, and other partitions
189 should be written in PC.
190
191 - To probe current SD card / eMMC:
192
193 # mmc dev 0 for eMMC
194 # mmc dev 1 for SD
195
196 - To erase a region:
197
198 # mmc erase <blk_offset> <blk_num>
199
200 - To write data to a block offset:
201
202 # mmc write <data_addr> <blk_offset> <blk_num>
203
204 - To load kernel image from partition 1:
205
206 # fatload mmc 0:1 <load_address> <path_to_kernel_uImage> for eMMC
207 # fatload mmc 1:1 <load_address> <path_to_kernel_uImage> for SD
208
209 - To boot kernel:
210
211 # bootm <load_address>
212
213 The DRAM starts at 0x80000000.
214
215 Please note that we use block offset and block count for SD card, not the byte offset.
216 The block size is always 512 bytes for SD card.
217
218
219Documentation
220=============
221 http://wiki.banana-pi.org/Banana_Pi_BPI-R2
222
README.memory-test
1The most frequent cause of problems when porting U-Boot to new
2hardware, or when using a sloppy port on some board, is memory errors.
3In most cases these are not caused by failing hardware, but by
4incorrect initialization of the memory controller. So it appears to
5be a good idea to always test if the memory is working correctly,
6before looking for any other potential causes of any problems.
7
8U-Boot implements 3 different approaches to perform memory tests:
9
101. The get_ram_size() function (see "common/memsize.c").
11
12 This function is supposed to be used in each and every U-Boot port
13 determine the presence and actual size of each of the potential
14 memory banks on this piece of hardware. The code is supposed to be
15 very fast, so running it for each reboot does not hurt. It is a
16 little known and generally underrated fact that this code will also
17 catch 99% of hardware related (i. e. reliably reproducible) memory
18 errors. It is strongly recommended to always use this function, in
19 each and every port of U-Boot.
20
212. The "mtest" command.
22
23 This is probably the best known memory test utility in U-Boot.
24 Unfortunately, it is also the most problematic, and the most
25 useless one.
26
27 There are a number of serious problems with this command:
28
29 - It is terribly slow. Running "mtest" on the whole system RAM
30 takes a _long_ time before there is any significance in the fact
31 that no errors have been found so far.
32
33 - It is difficult to configure, and to use. And any errors here
34 will reliably crash or hang your system. "mtest" is dumb and has
35 no knowledge about memory ranges that may be in use for other
36 purposes, like exception code, U-Boot code and data, stack,
37 malloc arena, video buffer, log buffer, etc. If you let it, it
38 will happily "test" all such areas, which of course will cause
39 some problems.
40
41 - It is not easy to configure and use, and a large number of
42 systems are seriously misconfigured. The original idea was to
43 test basically the whole system RAM, with only exempting the
44 areas used by U-Boot itself - on most systems these are the areas
45 used for the exception vectors (usually at the very lower end of
46 system memory) and for U-Boot (code, data, etc. - see above;
47 these are usually at the very upper end of system memory). But
48 experience has shown that a very large number of ports use
49 pretty much bogus settings of CONFIG_SYS_MEMTEST_START and
50 CONFIG_SYS_MEMTEST_END; this results in useless tests (because
51 the ranges is too small and/or badly located) or in critical
52 failures (system crashes).
53
54 Because of these issues, the "mtest" command is considered depre-
55 cated. It should not be enabled in most normal ports of U-Boot,
56 especially not in production. If you really need a memory test,
57 then see 1. and 3. above resp. below.
58
593. The most thorough memory test facility is available as part of the
60 POST (Power-On Self Test) sub-system, see "post/drivers/memory.c".
61
62 If you really need to perform memory tests (for example, because
63 it is mandatory part of your requirement specification), then
64 enable this test which is generic and should work on all archi-
65 tectures.
66
67WARNING:
68
69It should pointed out that _all_ these memory tests have one
70fundamental, unfixable design flaw: they are based on the assumption
71that memory errors can be found by writing to and reading from memory.
72Unfortunately, this is only true for the relatively harmless, usually
73static errors like shorts between data or address lines, unconnected
74pins, etc. All the really nasty errors which will first turn your
75hair gray, only to make you tear it out later, are dynamical errors,
76which usually happen not with simple read or write cycles on the bus,
77but when performing back-to-back data transfers in burst mode. Such
78accesses usually happen only for certain DMA operations, or for heavy
79cache use (instruction fetching, cache flushing). So far I am not
80aware of any freely available code that implements a generic, and
81efficient, memory test like that. The best known test case to stress
82a system like that is to boot Linux with root file system mounted over
83NFS, and then build some larger software package natively (say,
84compile a Linux kernel on the system) - this will cause enough context
85switches, network traffic (and thus DMA transfers from the network
86controller), varying RAM use, etc. to trigger any weak spots in this
87area.
88
89Note: An attempt was made once to implement such a test to catch
90memory problems on a specific board. The code is pretty much board
91specific (for example, it includes setting specific GPIO signals to
92provide triggers for an attached logic analyzer), but you can get an
93idea how it works: see "examples/standalone/test_burst*".
94
95Note 2: Ironically enough, the "test_burst" did not catch any RAM
96errors, not a single one ever. The problems this code was supposed
97to catch did not happen when accessing the RAM, but when reading from
98NOR flash.
99
README.mpc83xx.ddrecc
1Overview
2========
3
4The overall usage pattern for ECC diagnostic commands is the following:
5
6 * (injecting errors is initially disabled)
7
8 * define inject mask (which tells the DDR controller what type of errors
9 we'll be injecting: single/multiple bit etc.)
10
11 * enable injecting errors - from now on the controller injects errors as
12 indicated in the inject mask
13
14IMPORTANT NOTICE: enabling injecting multiple-bit errors is potentially
15dangerous as such errors are NOT corrected by the controller. Therefore caution
16should be taken when enabling the injection of multiple-bit errors: it is only
17safe when used on a carefully selected memory area and used under control of
18the 'ecc testdw' 'ecc testword' command (see example 'Injecting Multiple-Bit
19Errors' below). In particular, when you simply set the multiple-bit errors in
20inject mask and enable injection, U-Boot is very likely to hang quickly as the
21errors will be injected when it accesses its code, data etc.
22
23
24Use cases for DDR 'ecc' command:
25================================
26
27Before executing particular tests reset target board or clear status registers:
28
29=> ecc captureclear
30=> ecc errdetectclr all
31=> ecc sbecnt 0
32
33
34Injecting Single-Bit Errors
35---------------------------
36
371. Set 1 bit in Data Path Error Inject Mask
38
39=> ecc injectdatahi 1
40
412. Run test over some memory region
42
43=> ecc testdw 200000 10
44
453. Check ECC status
46
47=> ecc status
48...
49Memory Data Path Error Injection Mask High/Low: 00000001 00000000
50...
51Memory Single-Bit Error Management (0..255):
52 Single-Bit Error Threshold: 255
53 Single Bit Error Counter: 16
54...
55Memory Error Detect:
56 Multiple Memory Errors: 0
57 Multiple-Bit Error: 0
58 Single-Bit Error: 0
59...
60
6116 errors were generated, Single-Bit Error flag was not set as Single Bit Error
62Counter did not reach Single-Bit Error Threshold.
63
644. Make sure used memory region got re-initialized with 0x0123456789abcdef
65
66=> md 200000
6700200000: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
6800200010: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
6900200020: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
7000200030: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
7100200040: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
7200200050: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
7300200060: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
7400200070: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
7500200080: deadbeef deadbeef deadbeef deadbeef ................
7600200090: deadbeef deadbeef deadbeef deadbeef ................
77
78Injecting Multiple-Bit Errors
79-----------------------------
80
811. Set more than 1 bit in Data Path Error Inject Mask
82
83=> ecc injectdatahi 1
84=> ecc injectdatalo 1
85
862. Run test over some memory region
87
88=> ecc testword 200000 1
89
903. Check ECC status
91
92=> ecc status
93...
94Memory Data Path Error Injection Mask High/Low: 00000001 00000001
95...
96Memory Error Detect:
97 Multiple Memory Errors: 0
98 Multiple-Bit Error: 1
99 Single-Bit Error: 0
100...
101
102The Multiple Memory Errors flags not set and Multiple-Bit Error flags are set.
103
1044. Make sure used memory region got re-initialized with 0x0123456789abcdef
105
106=> md 200000
10700200000: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
10800200010: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
10900200020: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
11000200030: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
11100200040: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
11200200050: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
11300200060: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
11400200070: 01234567 89abcdef 01234567 89abcdef .#Eg.....#Eg....
11500200080: deadbeef deadbeef deadbeef deadbeef ................
11600200090: deadbeef deadbeef deadbeef deadbeef ................
117
118
119Test Single-Bit Error Counter and Threshold
120-------------------------------------------
121
1221. Set 1 bit in Data Path Error Inject Mask
123
124=> ecc injectdatahi 1
125
1262. Enable error injection
127
128=> ecc inject en
129
1303. Let u-boot run for a with Single-Bit error injection enabled
131
1324. Disable error injection
133
134=> ecc inject dis
135
1364. Check status
137
138=> ecc status
139
140...
141Memory Single-Bit Error Management (0..255):
142 Single-Bit Error Threshold: 255
143 Single Bit Error Counter: 199
144
145Memory Error Detect:
146 Multiple Memory Errors: 1
147 Multiple-Bit Error: 0
148 Single-Bit Error: 1
149...
150
151Observe that Single-Bit Error is 'on' which means that Single-Bit Error Counter
152reached Single-Bit Error Threshold. Multiple Memory Errors bit is also 'on', that
153is Counter reached Threshold more than one time (it wraps back after reaching
154Threshold).
155
README.mpc83xxads
1Freescale MPC83xx ADS Boards
2-----------------------------------------
3
40. Toolchain / Building
5
6 $ PATH=$PATH:/usr/powerpc/bin
7 $ CROSS_COMPILE=powerpc-linux-
8 $ export PATH CROSS_COMPILE
9
10 $ powerpc-linux-gcc -v
11 Reading specs from /usr/powerpc/lib/gcc/powerpc-linux/3.4.3/specs
12 Configured with: ../configure --prefix=/usr/powerpc
13 --exec-prefix=/usr/powerpc --target=powerpc-linux --enable-shared
14 --disable-nls --disable-multilib --enable-languages=c,c++,ada,f77,objc
15 Thread model: posix
16 gcc version 3.4.3 (Debian)
17
18 $ powerpc-linux-as -v
19 GNU assembler version 2.15 (powerpc-linux) using BFD version 2.15
20
21
22 $ make MPC8349ADS_config
23 Configuring for MPC8349ADS board...
24
25 $ make
26
27
281. Board Switches and Jumpers
29
30
312. Memory Map
32
332.1. The memory map should look pretty much like this:
34
35 0x0000_0000 0x7fff_ffff DDR 2G
36 0x8000_0000 0x9fff_ffff PCI MEM 512M
37 0xc000_0000 0xdfff_ffff Rapid IO 512M
38 0xe000_0000 0xe00f_ffff CCSR 1M
39 0xe200_0000 0xe2ff_ffff PCI IO 16M
40 0xf000_0000 0xf7ff_ffff SDRAM 128M
41 0xf800_0000 0xf80f_ffff BCSR 1M
42 0xfe00_0000 0xffff_ffff FLASH (boot bank) 16M
43
44
453. Definitions
46
473.1 Explanation of NEW definitions in:
48
49 include/configs/MPC8349ADS.h
50
51 CONFIG_MPC83xx MPC83xx family
52 CONFIG_MPC8349 MPC8349 specific
53 CONFIG_TSEC_ENET Use on-chip 10/100/1000 ethernet
54
55
564. Compilation
57
58 Assuming you're using BASH shell:
59
60 export CROSS_COMPILE=your-cross-compile-prefix
61 cd u-boot
62 make distclean
63 make MPC8349ADS_config
64 make
65
665. Downloading and Flashing Images
67
685.0 Download over serial line using Kermit:
69
70 loadb
71 [Drop to kermit:
72 ^\c
73 send <u-boot-bin-image>
74 c
75 ]
76
77
78 Or via tftp:
79
80 tftp 10000 u-boot.bin
81
825.1 Reflash U-Boot Image using U-Boot
83
84 tftp 10000 u-boot.bin
85 protect off fe000000 fe09ffff
86 erase fe000000 fe09ffff
87
88 cp.b 10000 fe000000 xxxx
89or
90 cp.b 10000 fe000000 a0000
91
92You might have to supply the correct byte count for 'xxxx' from
93the TFTP. Maybe a0000 will work too, that corresponds to the
94erased sectors.
95
96
976. Notes
98
README.mpc85xx
1External Debug Support
2----------------------
3
4Freescale's e500v1 and e500v2 cores (used in mpc85xx chips) have some
5restrictions on external debugging (JTAG). In particular, for the debugger to
6be able to receive control after a single step or breakpoint:
7 - MSR[DE] must be set
8 - A valid opcode must be fetchable, through the MMU, from the debug
9 exception vector (IVPR + IVOR15).
10
11To maximize the time during which this requirement is met, U-Boot sets MSR[DE]
12immediately on entry and keeps it set. It also uses a temporary TLB to keep a
13mapping to a valid opcode at the debug exception vector, even if we normally
14don't support exception vectors being used that early, and that's not the area
15where U-Boot currently executes from.
16
17Note that there may still be some small windows where debugging will not work,
18such as in between updating IVPR and IVOR15.
19
20Config Switches:
21----------------
22
23Please refer README section "MPC85xx External Debug Support"
24
25Major Config Switches during various boot Modes
26----------------------------------------------
27
28NOR boot
29 !defined(CONFIG_SYS_RAMBOOT) && !defined(CONFIG_SPL)
30NOR boot Secure
31 !defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_NXP_ESBC)
32RAMBOOT(SD, SPI & NAND boot)
33 defined(CONFIG_SYS_RAMBOOT)
34RAMBOOT Secure (SD, SPI & NAND)
35 defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_NXP_ESBC)
36NAND SPL BOOT
37 defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_NAND_SPL)
38
39
40TLB Entries during u-boot execution
41-----------------------------------
42
43Note: Sequence number is in order of execution
44
45A) defined(CONFIG_SYS_RAMBOOT) i.e. SD, SPI, NAND RAMBOOT & NAND_SPL boot
46
47 1) TLB entry to overcome e500 v1/v2 debug restriction
48 Location : Label "_start"
49 TLB Entry : CONFIG_SYS_PPC_E500_DEBUG_TLB
50 EPN -->RPN : CONFIG_SYS_MONITOR_BASE --> CONFIG_SYS_MONITOR_BASE
51 Properties : 256K, AS0, I, IPROT
52
53 2) TLB entry for working in AS1
54 Location : Label "create_init_ram_area"
55 TLB Entry : 15
56 EPN -->RPN : CONFIG_SYS_MONITOR_BASE --> CONFIG_SYS_MONITOR_BASE
57 Properties : 1M, AS1, I, G, IPROT
58
59 3) TLB entry for the stack during AS1
60 Location : Lable "create_init_ram_area"
61 TLB Entry : 14
62 EPN -->RPN : CFG_SYS_INIT_RAM_ADDR --> CFG_SYS_INIT_RAM_ADDR
63 Properties : 16K, AS1, IPROT
64
65 4) TLB entry for CCSRBAR during AS1 execution
66 Location : cpu_init_early_f
67 TLB Entry : 13
68 EPN -->RPN : CFG_SYS_CCSRBAR --> CFG_SYS_CCSRBAR
69 Properties : 1M, AS1, I, G
70
71 5) Invalidate unproctected TLB Entries
72 Location : cpu_init_early_f
73 Invalidated: 13
74
75 6) Create TLB entries as per boards/freescale/<board>/tlb.c
76 Location : cpu_init_early_f --> init_tlbs()
77 Properties : ..., AS0, ...
78 Please note It can overwrites previous TLB Entries.
79
80 7) Disable TLB Entries of AS1
81 Location : cpu_init_f --> disable_tlb()
82 Disable : 15, 14
83
84 8) Update Flash's TLB entry
85 Location : Board_init_r
86 TLB entry : Search from TLB entries
87 EPN -->RPN : CFG_SYS_FLASH_BASE --> CFG_SYS_FLASH_BASE_PHYS
88 Properties : Board specific size, AS0, I, G, IPROT
89
90
91B) !defined(CONFIG_SYS_RAMBOOT) i.e. NOR boot
92
93 1) TLB entry to overcome e500 v1/v2 debug restriction
94 Location : Label "_start"
95 TLB Entry : CONFIG_SYS_PPC_E500_DEBUG_TLB
96#if defined(CONFIG_NXP_ESBC)
97 EPN -->RPN : CONFIG_SYS_MONITOR_BASE --> CFG_SYS_PBI_FLASH_WINDOW
98 Properties : 1M, AS1, I, G, IPROT
99#else
100 EPN -->RPN : CONFIG_SYS_MONITOR_BASE & 0xffc00000 --> 0xffc00000
101 Properties : 4M, AS0, I, G, IPROT
102#endif
103
104 2) TLB entry for working in AS1
105 Location : Label "create_init_ram_area"
106 TLB Entry : 15
107#if defined(CONFIG_NXP_ESBC)
108 EPN -->RPN : CONFIG_SYS_MONITOR_BASE --> CFG_SYS_PBI_FLASH_WINDOW
109 Properties : 1M, AS1, I, G, IPROT
110#else
111 EPN -->RPN : CONFIG_SYS_MONITOR_BASE & 0xffc00000 --> 0xffc00000
112 Properties : 4M, AS1, I, G, IPROT
113#endif
114
115 3) TLB entry for the stack during AS1
116 Location : Lable "create_init_ram_area"
117 TLB Entry : 14
118 EPN -->RPN : CFG_SYS_INIT_RAM_ADDR --> CFG_SYS_INIT_RAM_ADDR
119 Properties : 16K, AS1, IPROT
120
121 4) TLB entry for CCSRBAR during AS1 execution
122 Location : cpu_init_early_f
123 TLB Entry : 13
124 EPN -->RPN : CFG_SYS_CCSRBAR --> CFG_SYS_CCSRBAR
125 Properties : 1M, AS1, I, G
126
127 5) TLB entry for Errata workaround CONFIG_SYS_FSL_ERRATUM_IFC_A003399
128 Location : cpu_init_early_f
129 TLB Entry : 9
130 EPN -->RPN : SRAM_BASE_ADDR --> SRAM_BASE_ADDR
131 Properties : 1M, AS1, I
132
133 6) CONFIG_SYS_FSL_ERRATUM_IFC_A003399 Adjust flash's phys addr
134 Location : cpu_init_early_f --> setup_ifc
135 TLB Entry : Get Flash TLB
136 EPN -->RPN : Adjusted flash_phys --> Adjusted flash_phys
137 Properties : 4M, AS1, I, G, IPROT
138
139 7) CONFIG_SYS_FSL_ERRATUM_IFC_A003399: E500 v1,v2 debug restriction
140 Location : cpu_init_early_f --> setup_ifc
141 TLB Entry : CONFIG_SYS_PPC_E500_DEBUG_TLB
142 EPN -->RPN : Adjusted flash_phys --> Adjusted flash_phys
143 Properties : 4M, AS0, I, G, IPROT
144
145 8) Invalidate unproctected TLB Entries
146 Location : cpu_init_early_f
147 Invalidated: 13, 9
148
149 9) Create TLB entries as per boards/freescale/<board>/tlb.c
150 Location : cpu_init_early_f --> init_tlbs()
151 Properties : ..., AS0, ...
152 Note: It can overwrites previous TLB Entries
153
154 10) Disable TLB Entries of AS1
155 Location : cpu_init_f --> disable_tlb()
156 Disable : 15, 14
157
158 11) Create DDR's TLB entriy
159 Location : Board_init_f -> dram_init
160 TLB entry : Search free TLB entry
161
162 12) Update Flash's TLB entry
163 Location : Board_init_r
164 TLB entry : Search from TLB entries
165 EPN -->RPN : CFG_SYS_FLASH_BASE --> CFG_SYS_FLASH_BASE_PHYS
166 Properties : Board specific size, AS0, I, G, IPROT
167
README.mpc85xx-sd-spi-boot
README.mpc85xx-spin-table
1Spin table in cache
2=====================================
3As specified by ePAPR v1.1, the spin table needs to be in cached memory. After
4DDR is initialized and U-Boot relocates itself into DDR, the spin table is
5accessible for core 0. It is part of release.S, within 4KB range after
6__secondary_start_page. For other cores to use the spin table, the booting
7process is described below:
8
9Core 0 sets up the reset page on the top 4K of memory (or 4GB if total memory
10is more than 4GB), and creates a TLB to map it to 0xffff_f000, regardless of
11the physical address of this page, with WIMGE=0b01010. Core 0 also enables boot
12page translation for secondary cores to use this page of memory. Then 4KB
13memory is copied from __secondary_start_page to the boot page, after flusing
14cache because this page is mapped as normal DDR. Before copying the reset page,
15core 0 puts the physical address of the spin table (which is in release.S and
16relocated to the top of mapped memory) into a variable __spin_table_addr so
17that secondary cores can see it.
18
19When secondary cores boot up from 0xffff_f000 page, they only have one default
20TLB. While booting, they set up another TLB in AS=1 space and jump into
21the new space. The new TLB covers the physical address of the spin table page,
22with WIMGE =0b00100. Now secondary cores can keep polling the spin table
23without stress DDR bus because both the code and the spin table is in cache.
24
25For the above to work, DDR has to set the 'M' bit of WIMGE, in order to keep
26cache coherence.
27
README.mpc85xxcds
1Motorola MPC85xxCDS boards
2--------------------------
3
4The CDS family of boards consists of a PCI backplane called the
5"Arcadia", a PCI-form-factor carrier card that plugs into a PCI slot,
6and a CPU daughter card that bolts onto the daughter card.
7
8Much of the content of the README.mpc85xxads for the 85xx ADS boards
9applies to the 85xx CDS boards as well. In particular the toolchain,
10the switch nomenclature, and the basis for the memory map. There are
11some differences, though.
12
13
14Building U-Boot
15---------------
16
17The Binutils in current ELDK toolchain will not support MPC85xx
18chip. You need to use binutils-2.14.tar.bz2 (or newer) from
19 http://ftp.gnu.org/gnu/binutils.
20
21The 85xx CDS code base is known to compile using:
22 gcc (GCC) 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-2a)
23
24
25Memory Map
26----------
27
28The memory map for U-Boot and linux has been extended w.r.t. the ADS
29platform to allow for utilization of all 85xx CDS devices. The memory
30map is setup for linux to operate properly. The linux source when
31configured for MPC85xx CDS has been updated to reflect the new memory
32map.
33
34The mapping is:
35
36 0x0000_0000 0x7fff_ffff DDR 2G
37 0x8000_0000 0x9fff_ffff PCI1 MEM 512M
38 0xa000_0000 0xbfff_ffff PCI2 MEM 512M
39 0xe000_0000 0xe00f_ffff CCSR 1M
40 0xe200_0000 0xe2ff_ffff PCI1 IO 16M
41 0xe300_0000 0xe3ff_ffff PCI2 IO 16M
42 0xf000_0000 0xf7ff_ffff SDRAM 128M
43 0xf800_0000 0xf80f_ffff NVRAM/CADMUS (*) 1M
44 0xff00_0000 0xff7f_ffff FLASH (2nd bank) 8M
45 0xff80_0000 0xffff_ffff FLASH (boot bank) 8M
46
47 (*) The system control registers (CADMUS) start at offset 0xfdb0_4000
48 within the NVRAM/CADMUS region of memory.
49
50
51Using Flash
52-----------
53
54The CDS board has two flash banks, each 8MB in size (2^23 = 0x00800000).
55There is a switch which allows the boot-bank to be selected. The switch
56settings for updating flash are given below.
57
58The U-Boot commands for copying the boot-bank into the secondary bank are
59as follows:
60
61 erase ff780000 ff7fffff
62 cp.b fff80000 ff780000 80000
63
64
65U-Boot/kermit commands for downloading an image, then copying
66it into the secondary bank:
67
68 loadb
69 [Drop to kermit:
70 ^\c
71 send <u-boot-bin-image>
72 c
73 ]
74
75 erase ff780000 ff7fffff
76 cp.b $loadaddr ff780000 80000
77
78
79U-Boot commands for downloading an image via tftp and flashing
80it into the second bank:
81
82 tftp 10000 <u-boot.bin.image>
83 erase ff780000 ff7fffff
84 cp.b 10000 ff780000 80000
85
86
87After copying the image into the second bank of flash, be sure to toggle
88SW2[2] on the carrier card before resetting the board in order to set the
89secondary bank as the boot-bank.
90
91
92Carrier Board Switches
93----------------------
94
95As a reminder, you should read the README.mpc85xxads too.
96
97Most switches on the carrier board should not be changed. The only
98user-settable switches on the carrier board are used to configure
99the flash banks and determining the PCI slot.
100
101The first two bits of SW2 control how flash is used on the board:
102
103 12345678
104 --------
105 SW2=00XXXXXX FLASH: Boot bank 1, bank 2 available.
106 01XXXXXX FLASH: Boot bank 2, bank 1 available (swapped).
107 10XXXXXX FLASH: Boot promjet, bank 1 available
108 11XXXXXX FLASH: Boot promjet, bank 2 available
109
110The boot bank is always mapped to FF80_0000 and listed first by
111the "flinfo" command. The secondary bank is always FF00_0000.
112
113When using PCI, linux needs to know to which slot the CDS carrier is
114connected.. By convention, the user-specific bits of SW2 are used to
115convey this information:
116
117 12345678
118 --------
119 SW2=xxxxxx00 PCI SLOT INFORM: The CDS carrier is in slot0 of the Arcadia
120 xxxxxx01 PCI SLOT INFORM: The CDS carrier is in slot1 of the Arcadia
121 xxxxxx10 PCI SLOT INFORM: The CDS carrier is in slot2 of the Arcadia
122 xxxxxx11 PCI SLOT INFORM: The CDS carrier is in slot3 of the Arcadia
123
124These are cleverly, er, clearly silkscreened as Slot 1 through 4,
125respectively, on the Arcadia near the support posts.
126
127
128The default setting of all switches on the carrier board is:
129
130 12345678
131 --------
132 SW1=01101100
133 SW2=0x1111yy x=Flash bank, yy=PCI slot
134 SW3=11101111
135 SW4=10001000
136
137
1388555/41 CPU Card Switches
139-------------------------
140
141Most switches on the CPU Card should not be changed. However, the
142frequency can be changed by setting SW3:
143
144 12345678
145 --------
146 SW3=XX00XXXX == CORE:CCB 2:1
147 XX01XXXX == CORE:CCB 5:2
148 XX10XXXX == CORE:CCB 3:1
149 XX11XXXX == CORE:CCB 7:2
150 XXXX1000 == CCB:SYSCLK 8:1
151 XXXX1010 == CCB:SYSCLK 10:1
152
153A safe default setting for all switches on the CPU board is:
154
155 12345678
156 --------
157 SW1=10001111
158 SW2=01000111
159 SW3=00001000
160 SW4=11111110
161
162
1638548 CPU Card Switches
164----------------------
165And, just to be confusing, in this set of switches:
166
167 ON = 1
168 OFF = 0
169
170Default
171 SW1=11111101
172 SW2=10011111
173 SW3=11001000 (8X) (2:1)
174 SW4=11110011
175
176 SW3=X000XXXX == CORE:CCB 4:1
177 X001XXXX == CORE:CCB 9:2
178 X010XXXX == CORE:CCB 1:1
179 X011XXXX == CORE:CCB 3:2
180 X100XXXX == CORE:CCB 2:1
181 X101XXXX == CORE:CCB 5:2
182 X110XXXX == CORE:CCB 3:1
183 X111XXXX == CORE:CCB 7:2
184 XXXX0000 == CCB:SYSCLK 16:1
185 XXXX0001 == RESERVED
186 XXXX0010 == CCB:SYSCLK 2:1
187 XXXX0011 == CCB:SYSCLK 3:1
188 XXXX0100 == CCB:SYSCLK 4:1
189 XXXX0101 == CCB:SYSCLK 5:1
190 XXXX0110 == CCB:SYSCLK 6:1
191 XXXX0111 == RESERVED
192 XXXX1000 == CCB:SYSCLK 8:1
193 XXXX1001 == CCB:SYSCLK 9:1
194 XXXX1010 == CCB:SYSCLK 10:1
195 XXXX1011 == RESERVED
196 XXXX1100 == CCB:SYSCLK 12:1
197 XXXX1101 == CCB:SYSCLK 20:1
198 XXXX1110 == RESERVED
199 XXXX1111 == RESERVED
200
201
202eDINK Info
203----------
204
205One bank of flash may contain an eDINK image.
206
207Memory Map:
208
209 CCSRBAR @ 0xe0000000
210 Flash Bank 1 @ 0xfe000000
211 Flash Bank 2 @ 0xff000000
212 Ram @ 0
213
214Commands for downloading a U-Boot image to memory from edink:
215
216 env -c
217 time -s 4/8/2004 4:30p
218 dl -k -b -o 100000
219 [Drop to kermit:
220 ^\c
221 transmit /binary <u-boot-bin-image>
222 c
223 ]
224
225 fu -l 100000 fe780000 80000
226
README.multi-dtb-fit
1MULTI DTB FIT and SPL_MULTI_DTB_FIT
2
3The purpose of this feature is to enable U-Boot or the SPL to select its DTB
4from a FIT appended at the end of the binary.
5It comes in two flavors: U-Boot (CONFIG_MULTI_DTB_FIT) and SPL
6(CONFIG_SPL_MULTI_DTB_FIT).
7
8U-Boot flavor:
9Usually the DTB is selected by the SPL and passed down to U-Boot. But some
10platforms don't use the SPL. In this case MULTI_DTB_FIT can used to provide
11U-Boot with a choice of DTBs.
12The relevant DTBs are packed into a FIT (list provided by CONFIG_OF_LIST). The
13FIT is automatically generated at the end of the compilation and appended to
14u-boot.bin so that U-Boot can locate it and select the correct DTB from inside
15the FIT.
16The selection is done using board_fit_config_name_match() (same as what the SPL
17uses to select the DTB for U-Boot). The selection happens during fdtdec_setup()
18which is called during before relocation by board_init_f().
19
20SPL flavor:
21the SPL uses only a small subset of the DTB and it usually depends more
22on the SOC than on the board. So it's usually fine to include a DTB in the
23SPL that doesn't exactly match the board. There are howerver some cases
24where it's not possible. In the later case, in order to support multiple
25boards (or board revisions) with the same SPL binary, SPL_MULTI_DTB_FIT
26can be used.
27The relevant DTBs are packed into a FIT. This FIT is automatically generated
28at the end of the compilation, compressed and appended to u-boot-spl.bin, so
29that SPL can locate it and select the correct DTB from inside the FIT.
30CONFIG_SPL_OF_LIST is used to list the relevant DTBs.
31The compression stage is optional but reduces the impact on the size of the
32SPL. LZO and GZIP compressions are supported. By default, the area where the
33FIT is uncompressed is dynamicaly allocated but this behaviour can be changed
34for platforms that don't provide a HEAP big enough to contain the uncompressed
35FIT.
36The SPL uses board_fit_config_name_match() to find the correct DTB within the
37FIT (same as what the SPL uses to select the DTB for U-Boot).
38Uncompression and selection stages happen in fdtdec_setup() which is called
39during the early initialization stage of the SPL (spl_early_init() or
40spl_init())
41
42Impacts and performances (SPL flavor):
43The impact of this option is relatively small. Here are some numbers measured
44for a TI DRA72 platform:
45
46 +----------+------------+-----------+------------+
47 | size | size delta | SPL boot | boot time |
48 | (bytes) | (bytes) | time (s) | delta (s) |
49+---------------------------+----------+------------+-----------+------------+
50| 1 DTB | | | | |
51+---------------------------+----------+------------+-----------+------------+
52| reference | 125305 | 0 | 1.389 | 0 |
53| LZO (dynamic allocation) | 125391 | 86 | 1.381 | -0.008 |
54+---------------------------+----------+------------+-----------+------------+
55| 4 DTBs (DRA7, DRA71, | | | | |
56| DRA72, DRA72 revC) | | | | |
57+---------------------------+----------+------------+-----------+------------+
58| LZO (dynamic allocation) | 125991 | 686 | 1.39 | 0.001 |
59| LZO (user defined area) | 125927 | 622 | 1.403 | 0.014 |
60| GZIP (user defined area) | 133880 | 8575 | 1.421 | 0.032 |
61| No compression (in place) | 137472 | 12167 | 1.412 | 0.023 |
62+---------------------------+----------+------------+-----------+------------+
63
64Note: SPL boot time is the time elapsed between the 'reset' command is entered
65and the time when the first U-Boot (not SPL) version string is displayed.
66
README.mxc_ocotp
1Driver implementing the fuse API for Freescale's On-Chip OTP Controller (OCOTP)
2on MXC
3
4This IP can be found on the following SoCs:
5 - Vybrid VF610,
6 - i.MX6.
7
8Note that this IP is different from albeit similar to the IPs of the same name
9that can be found on the following SoCs:
10 - i.MX23,
11 - i.MX28,
12 - i.MX50.
13
14The section numbers in this file refer to the i.MX6 Reference Manual.
15
16A fuse word contains 32 fuse bit slots, as explained in 46.2.1.
17
18A bank contains 8 fuse word slots, as explained in 46.2.1 and shown by the
19memory map in 46.4.
20
21Some fuse bit or word slots may not have the corresponding fuses actually
22implemented in the fusebox.
23
24See the README files of the SoCs using this driver in order to know the
25conventions used by U-Boot to store some specific data in the fuses, e.g. MAC
26addresses.
27
28Fuse operations:
29
30 Read
31 Read operations are implemented as read accesses to the shadow registers,
32 using "Bankx Wordy" from the memory map in 46.4. This is explained in
33 detail by the first two paragraphs in 46.2.1.2.
34
35 Sense
36 Sense operations are implemented as the direct fusebox read explained by
37 the steps in 46.2.1.2.
38
39 Program
40 Program operations are implemented as explained by the steps in 46.2.1.3.
41 Following this operation, the shadow registers are not reloaded by the
42 hardware.
43
44 Override
45 Override operations are implemented as write accesses to the shadow
46 registers, as explained by the first paragraph in 46.2.1.3.
47
48Configuration:
49
50 CONFIG_MXC_OCOTP
51 Define this to enable the mxc_ocotp driver.
52
README.nand
1# SPDX-License-Identifier: GPL-2.0+
2NAND FLASH commands and notes
3
4See NOTE below!!!
5
6# (C) Copyright 2003
7# Dave Ellis, SIXNET, dge@sixnetio.com
8#
9
10Commands:
11
12 nand bad
13 Print a list of all of the bad blocks in the current device.
14
15 nand device
16 Print information about the current NAND device.
17
18 nand device num
19 Make device `num' the current device and print information about it.
20
21 nand erase off|partition size
22 nand erase clean [off|partition size]
23 Erase `size' bytes starting at offset `off'. Alternatively partition
24 name can be specified, in this case size will be eventually limited
25 to not exceed partition size (this behaviour applies also to read
26 and write commands). Only complete erase blocks can be erased.
27
28 If `erase' is specified without an offset or size, the entire flash
29 is erased. If `erase' is specified with partition but without an
30 size, the entire partition is erased.
31
32 If `clean' is specified, a JFFS2-style clean marker is written to
33 each block after it is erased.
34
35 This command will not erase blocks that are marked bad. There is
36 a debug option in cmd_nand.c to allow bad blocks to be erased.
37 Please read the warning there before using it, as blocks marked
38 bad by the manufacturer must _NEVER_ be erased.
39
40 nand info
41 Print information about all of the NAND devices found.
42
43 nand read addr ofs|partition size
44 Read `size' bytes from `ofs' in NAND flash to `addr'. Blocks that
45 are marked bad are skipped. If a page cannot be read because an
46 uncorrectable data error is found, the command stops with an error.
47
48 nand read.oob addr ofs|partition size
49 Read `size' bytes from the out-of-band data area corresponding to
50 `ofs' in NAND flash to `addr'. This is limited to the 16 bytes of
51 data for one 512-byte page or 2 256-byte pages. There is no check
52 for bad blocks or ECC errors.
53
54 nand write addr ofs|partition size
55 Write `size' bytes from `addr' to `ofs' in NAND flash. Blocks that
56 are marked bad are skipped. If a page cannot be read because an
57 uncorrectable data error is found, the command stops with an error.
58
59 As JFFS2 skips blocks similarly, this allows writing a JFFS2 image,
60 as long as the image is short enough to fit even after skipping the
61 bad blocks. Compact images, such as those produced by mkfs.jffs2
62 should work well, but loading an image copied from another flash is
63 going to be trouble if there are any bad blocks.
64
65 nand write.trimffs addr ofs|partition size
66 Enabled by the CONFIG_CMD_NAND_TRIMFFS macro. This command will write to
67 the NAND flash in a manner identical to the 'nand write' command
68 described above -- with the additional check that all pages at the end
69 of eraseblocks which contain only 0xff data will not be written to the
70 NAND flash. This behaviour is required when flashing UBI images
71 containing UBIFS volumes as per the UBI FAQ[1].
72
73 [1] http://www.linux-mtd.infradead.org/doc/ubi.html#L_flasher_algo
74
75 nand write.oob addr ofs|partition size
76 Write `size' bytes from `addr' to the out-of-band data area
77 corresponding to `ofs' in NAND flash. This is limited to the 16 bytes
78 of data for one 512-byte page or 2 256-byte pages. There is no check
79 for bad blocks.
80
81 nand read.raw addr ofs|partition [count]
82 nand write.raw addr ofs|partition [count]
83 Read or write one or more pages at "ofs" in NAND flash, from or to
84 "addr" in memory. This is a raw access, so ECC is avoided and the
85 OOB area is transferred as well. If count is absent, it is assumed
86 to be one page. As with .yaffs2 accesses, the data is formatted as
87 a packed sequence of "data, oob, data, oob, ..." -- no alignment of
88 individual pages is maintained.
89
90Configuration Options:
91
92 CONFIG_SYS_NAND_U_BOOT_OFFS
93 NAND Offset from where SPL will read u-boot image. This is the starting
94 address of u-boot MTD partition in NAND.
95
96 CONFIG_CMD_NAND
97 Enables NAND support and commands.
98
99 CONFIG_CMD_NAND_TORTURE
100 Enables the torture command (see description of this command below).
101
102 CONFIG_SYS_NAND_MAX_CHIPS
103 The maximum number of NAND chips per device to be supported.
104
105 CONFIG_SYS_NAND_SELF_INIT
106 Traditionally, glue code in drivers/mtd/nand/raw/nand.c has driven
107 the initialization process -- it provides the mtd and nand
108 structs, calls a board init function for a specific device,
109 calls nand_scan(), and registers with mtd.
110
111 This arrangement does not provide drivers with the flexibility to
112 run code between nand_scan_ident() and nand_scan_tail(), or other
113 deviations from the "normal" flow.
114
115 If a board defines CONFIG_SYS_NAND_SELF_INIT, drivers/mtd/nand/raw/nand.c
116 will make one call to board_nand_init(), with no arguments. That
117 function is responsible for calling a driver init function for
118 each NAND device on the board, that performs all initialization
119 tasks except setting mtd->name, and registering with the rest of
120 U-Boot. Those last tasks are accomplished by calling nand_register()
121 on the new mtd device.
122
123 Example of new init to be added to the end of an existing driver
124 init:
125
126 /* chip is struct nand_chip, and is now provided by the driver. */
127 mtd = nand_to_mtd(&chip);
128
129 /*
130 * Fill in appropriate values if this driver uses these fields,
131 * or uses the standard read_byte/write_buf/etc. functions from
132 * nand_base.c that use these fields.
133 */
134 chip.IO_ADDR_R = ...;
135 chip.IO_ADDR_W = ...;
136
137 if (nand_scan_ident(mtd, CFG_SYS_MAX_NAND_CHIPS, NULL))
138 error out
139
140 /*
141 * Insert here any code you wish to run after the chip has been
142 * identified, but before any other I/O is done.
143 */
144
145 if (nand_scan_tail(mtd))
146 error out
147
148 /*
149 * devnum is the device number to be used in nand commands
150 * and in mtd->name. Must be less than CONFIG_SYS_MAX_NAND_DEVICE.
151 */
152 if (nand_register(devnum, mtd))
153 error out
154
155 In addition to providing more flexibility to the driver, it reduces
156 the difference between a U-Boot driver and its Linux counterpart.
157 nand_init() is now reduced to calling board_nand_init() once, and
158 printing a size summary. This should also make it easier to
159 transition to delayed NAND initialization.
160
161 Please convert your driver even if you don't need the extra
162 flexibility, so that one day we can eliminate the old mechanism.
163
164
165Platform specific options
166=========================
167 CONFIG_NAND_OMAP_GPMC
168 Enables omap_gpmc.c driver for OMAPx and AMxxxx platforms.
169 GPMC controller is used for parallel NAND flash devices, and can
170 do ECC calculation (not ECC error detection) for HAM1, BCH4, BCH8
171 and BCH16 ECC algorithms.
172
173 CONFIG_NAND_OMAP_ELM
174 Enables omap_elm.c driver for OMAPx and AMxxxx platforms.
175 ELM controller is used for ECC error detection (not ECC calculation)
176 of BCH4, BCH8 and BCH16 ECC algorithms.
177 Some legacy platforms like OMAP3xx do not have in-built ELM h/w engine,
178 thus such SoC platforms need to depend on software library for ECC error
179 detection. However ECC calculation on such plaforms would still be
180 done by GPMC controller.
181
182 CONFIG_SPL_NAND_AM33XX_BCH
183 Enables SPL-NAND driver (am335x_spl_bch.c) which supports ELM based
184 hardware ECC correction. This is useful for platforms which have ELM
185 hardware engine and use NAND boot mode.
186 Some legacy platforms like OMAP3xx do not have in-built ELM h/w engine,
187 so those platforms should use CONFIG_SPL_NAND_SIMPLE for enabling
188 SPL-NAND driver with software ECC correction support.
189
190 CONFIG_NAND_OMAP_GPMC_PREFETCH
191 On OMAP platforms that use the GPMC controller
192 (CONFIG_NAND_OMAP_GPMC_PREFETCH), this options enables the code that
193 uses the prefetch mode to speed up read operations.
194
195NOTE:
196=====
197
198The Disk On Chip driver is currently broken and has been for some time.
199There is a driver in drivers/mtd/nand/raw, taken from Linux, that works with
200the current NAND system but has not yet been adapted to the u-boot
201environment.
202
203Additional improvements to the NAND subsystem by Guido Classen, 10-10-2006
204
205JFFS2 related commands:
206
207 implement "nand erase clean" and old "nand erase"
208 using both the new code which is able to skip bad blocks
209 "nand erase clean" additionally writes JFFS2-cleanmarkers in the oob.
210
211Miscellaneous and testing commands:
212 "markbad [offset]"
213 create an artificial bad block (for testing bad block handling)
214
215 "scrub [offset length]"
216 like "erase" but don't skip bad block. Instead erase them.
217 DANGEROUS!!! Factory set bad blocks will be lost. Use only
218 to remove artificial bad blocks created with the "markbad" command.
219
220 "torture offset [size]"
221 Torture block to determine if it is still reliable.
222 Enabled by the CONFIG_CMD_NAND_TORTURE configuration option.
223 This command returns 0 if the block is still reliable, else 1.
224 If the block is detected as unreliable, it is up to the user to decide to
225 mark this block as bad.
226 The analyzed block is put through 3 erase / write cycles (or less if the block
227 is detected as unreliable earlier).
228 This command can be used in scripts, e.g. together with the markbad command to
229 automate retries and handling of possibly newly detected bad blocks if the
230 nand write command fails.
231 It can also be used manually by users having seen some NAND errors in logs to
232 search the root cause of these errors.
233 The underlying nand_torture() function is also useful for code willing to
234 automate actions following a nand->write() error. This would e.g. be required
235 in order to program or update safely firmware to NAND, especially for the UBI
236 part of such firmware.
237 Optionally, a second parameter size can be given to test multiple blocks with
238 one call. If size is not a multiple of the NAND's erase size, then the block
239 that contains offset + size will be tested in full. If used with size, this
240 command returns 0 if all tested blocks have been found reliable, else 1.
241
242
243NAND locking command (for chips with active LOCKPRE pin)
244
245 "nand lock"
246 set NAND chip to lock state (all pages locked)
247
248 "nand lock tight"
249 set NAND chip to lock tight state (software can't change locking anymore)
250
251 "nand lock status"
252 displays current locking status of all pages
253
254 "nand unlock [offset] [size]"
255 unlock consecutive area (can be called multiple times for different areas)
256
257 "nand unlock.allexcept [offset] [size]"
258 unlock all except specified consecutive area
259
260I have tested the code with board containing 128MiB NAND large page chips
261and 32MiB small page chips.
262
README.odroid
1 U-Boot for Odroid X2/U3/XU3/XU4/HC1
2========================
3
41. Summary
5==========
6This is a quick instruction for setup Odroid boards.
7Board config: odroid_config for X2/U3
8Board config: odroid-xu3_config for XU3/XU4/HC1
9
102. Supported devices
11====================
12This U-BOOT config can be used on three boards:
13- Odroid U3
14- Odroid X2
15with CPU Exynos 4412 rev 2.0 and 2GB of RAM
16- Odroid XU3
17- Odroid XU4
18- Odroid HC1
19with CPU Exynos5422 and 2GB of RAM
20
213. Boot sequence
22================
23iROM->BL1->(BL2 + TrustZone)->U-BOOT
24
25This version of U-BOOT doesn't implement SPL. So, BL1, BL2, and TrustZone
26binaries are needed to boot up.
27
28<< X2/U3 >>
29It can be found in "boot.tar.gz" from here:
30http://dev.odroid.com/projects/4412boot/wiki/FrontPage?action=download&value=boot.tar.gz
31or here:
32http://odroid.in/guides/ubuntu-lfs/boot.tar.gz
33
34<< XU3/XU4 >>
35It can be downloaded from:
36https://github.com/hardkernel/u-boot/tree/odroidxu3-v2012.07/sd_fuse/hardkernel_1mb_uboot
37
38
394. Boot media layout
40====================
41The table below shows SD/eMMC cards layout for U-Boot.
42The block offset is starting from 0 and the block size is 512B.
43 -------------------------------------
44| Binary | Block offset| part type |
45| name | SD | eMMC |(eMMC only)|
46 -------------------------------------
47| Bl1 | 1 | 0 | 1 (boot) |
48| Bl2 | 31 | 30 | 1 (boot) |
49| U-Boot | 63 | 62 | 1 (boot) |
50| Tzsw | 2111 | 2110 | 1 (boot) |
51| Uboot Env | 2560 | 2560 | 0 (user) |
52 -------------------------------------
53
545. Prepare the SD boot card - with SD card reader
55=================================================
56To prepare bootable media you need boot binaries provided by hardkernel.
57From the downloaded files, You can find:
58- bl1.bin
59- tzsw.bin
60- bl2.bin
61- sd_fusing.sh
62- u-boot.bin
63(The file names can be slightly different, but you can distinguish what they are
64without problem)
65
66This is all you need to boot this board. But if you want to use your custom
67U-Boot then you need to change u-boot.bin with your own U-Boot binary*
68and run the script "sd_fusing.sh" - this script is valid only for SD card.
69
70*note:
71The proper binary file of current U-Boot is u-boot-dtb.bin.
72
73quick steps for Linux:
74- Download all files from the link at point 3 and extract it if needed.
75- put any SD card into the SD reader
76- check the device with "dmesg"
77- run ./sd_fusing.sh /dev/sdX - where X is SD card device (but not a partition)
78Check if Hardkernel U-Boot is booting, and next do the same with your U-Boot.
79
806. Prepare the eMMC boot card
81 with a eMMC card reader (boot from eMMC card slot)
82=====================================================
83To boot the device from the eMMC slot you should use a special card reader
84which supports eMMC partition switch. All of the boot binaries are stored
85on the eMMC boot partition which is normally hidden.
86
87The "sd_fusing.sh" script can be used after updating offsets of binaries
88according to the table from point 4. Be sure that you are working on the right
89eMMC partition - its size is usually very small, about 1-4 MiB.
90
917. Prepare the eMMC boot card
92 with a SD card reader (boot from SD card slot)
93=================================================
94If you have an eMMC->microSD adapter you can prepare the card as in point 5.
95But then the device can boot only from the SD card slot.
96
978. Prepare the boot media using Hardkernel U-Boot
98=================================================
99You can update the U-Boot to the custom one if you have a working bootloader
100delivered with the board on the eMMC/SD card. Then follow the steps:
101- install the android fastboot tool
102- connect a micro usb cable to the board
103- on the U-Boot prompt, run command: fastboot (as a root)
104- on the host, run command: "fastboot flash bootloader u-boot-dtb.bin"
105- the custom U-Boot should start after the board resets.
106
1079. Partition layout
108====================
109Default U-Boot environment is setup for fixed partition layout.
110
111Partition table: MSDOS. Disk layout and files as listed in the table below.
112 ----- ------ ------ ------ -------- ---------------------------------
113| Num | Name | FS | Size | Offset | Reguired files |
114| | | Type | MiB | MiB | |
115 ----- ------ ------ ------ -------- ---------------------------------
116| 1 | BOOT | fat | 100 | 2 | kernel, fdt** |
117| 2 | ROOT | ext4 | - | | any Linux system |
118 ----- ------ ------ ------ -------- ---------------------------------
119
120**note:
121Supported fdt files are:
122- exynos4412-odroidx2.dtb
123- exynos4412-odroidu3.dtb
124- exynos5422-odroidxu3.dtb
125- exynos5422-odroidxu3-lite.dtb
126- exynos5422-odroidxu4.dtb
127- exynos5422-odroidhc1.dtb
128
129Supported kernel files are:
130- Image.itb
131- zImage
132- uImage
133
134The default environmental variable "dfu_alt_info" is set* for above layout.
135Each partition size is just an example, dfu_alt_info tries init two partitions.
136The size of each is not important.
137
138*note:
139$dfu_alt_info is set on a boot time and it is concatenated using two variables:
140- $dfu_alt_boot(set dynamically)
141- $dfu_alt_system(from current env).
142
143To add any changes to dfu_alt_info - please modify $dfu_alt_system only.
144Changes are visible after board reset.
145
14610. The environment and booting the kernel
147==========================================
148There are three macros defined in config for various boot options:
149Two for both, kernel with device tree support and also without it:
150- boot_uimg - load uImage
151- boot_zimg - load zImage
152If proper fdt file exists then it will be automatically loaded,
153so for old kernel types, please remove fdt file from boot partition.
154
155The third boot option for multi image support (more info: doc/uImage.FIT/)
156- boot_fit - for binary file: "Image.itb"
157
158Default boot command: "autoboot"
159And the boot sequence is:
160- boot_fit - if "Image.itb" exists
161- boot_zimg - if "zImage" exists
162- boot_uimg - if "uImage" exists
163
16411. USB host support
165====================
166NOTE: This section is only for Odroid X2/U3.
167
168The ethernet can be accessed after starting the USB subsystem in U-Boot.
169The adapter does not come with a preconfigured MAC address, and hence it needs
170to be set before starting USB.
171setenv usbethaddr 02:DE:AD:BE:EF:FF
172
173Note that in this example a locally managed MAC address is chosen. Care should
174be taken to make these MAC addresses unique within the same subnet.
175
176Start the USB subsystem:
177Odroid # setenv usbethaddr 02:DE:AD:BE:EF:FF
178Odroid # usb start
179(Re)start USB...
180USB0: USB EHCI 1.00
181scanning bus 0 for devices... 4 USB Device(s) found
182 scanning usb for storage devices... 1 Storage Device(s) found
183 scanning usb for ethernet devices... 1 Ethernet Device(s) found
184Odroid #
185
186Automatic IP assignment:
187------------------------
188If the ethernet is connected to a DHCP server (router maybe with DHCP enabled),
189then the below will automatically assign an ip address through DHCP.
190setenv autoload no
191dhcp
192
193Odroid # setenv autoload no
194Odroid # dhcp
195Waiting for Ethernet connection... done.
196BOOTP broadcast 1
197DHCP client bound to address 192.168.1.10 (524 ms)
198Odroid #
199
200Note that this automatically sets the many IP address related variables in
201U-Boot that is obtained from the DHCP server.
202
203Odroid # printenv ipaddr netmask gatewayip dnsip
204ipaddr=192.168.1.10
205netmask=255.255.255.0
206gatewayip=192.168.1.1
207dnsip=192.168.1.1
208
209Ping example:
210The ping command can be used a test to check connectivity. In this example,
211192.168.1.27 is a pingable server in the network.
212Odroid # ping 192.168.1.27
213Waiting for Ethernet connection... done.
214Using sms0 device
215host 192.168.1.27 is alive
216Odroid #
217
218Static IP assignment:
219---------------------
220In the case where there are no DHCP servers in the network, or you want to
221set the IP address statically, it can be done by:
222Odroid # setenv ipaddr 192.168.1.10
223Odroid # ping 192.168.1.27
224Waiting for Ethernet connection... done.
225Using sms0 device
226host 192.168.1.27 is alive
227
228TFTP booting:
229-------------
230Say there exists a tftp server in the network with address 192.168.1.27 and
231it serves a kernel image (zImage.3.17) and a DTB blob (exynos4412-odroidu3.dtb)
232that needs to be loaded and booted. It can be accomplished as below:
233(Assumes that you have setenv usbethaddr, and have not set autoload to no)
234
235Odroid # setenv serverip 192.168.1.27
236Odroid # tftpboot 0x40080000 zImage.3.17
237Waiting for Ethernet connection... done.
238Using sms0 device
239TFTP from server 192.168.1.27; our IP address is 192.168.1.10
240Filename 'zImage.3.17'.
241Load address: 0x40080000
242Loading: #################################################################
243 #################################################################
244 #################################################################
245 #######################
246 52.7 KiB/s
247done
248Bytes transferred = 3194200 (30bd58 hex)
249Odroid # tftpboot 0x42000000 exynos4412-odroidu3.dtb
250Waiting for Ethernet connection... done.
251Using sms0 device
252TFTP from server 192.168.1.27; our IP address is 192.168.1.10
253Filename 'exynos4412-odroidu3.dtb'.
254Load address: 0x42000000
255Loading: ####
256 40 KiB/s
257done
258Bytes transferred = 46935 (b757 hex)
259Odroid # printenv bootargs
260bootargs=Please use defined boot
261Odroid # setenv bootargs console=ttySAC1,115200n8 root=/dev/mmcblk0p2 rootwait
262Odroid # bootz 40080000 - 42000000
263Kernel image @ 0x40080000 [ 0x000000 - 0x30bd58 ]
264## Flattened Device Tree blob at 42000000
265 Booting using the fdt blob at 0x42000000
266 Loading Device Tree to 4fff1000, end 4ffff756 ... OK
267
268Starting kernel ...
269
270[ 0.000000] Booting Linux on physical CPU 0xa00
271... etc ...
272
273In the above example you can substitute 'dhcp' for 'tftpboot' as well.
274
275USB Storage booting:
276--------------------
277Similarly we can use the USB storage to load the kernel image/initrd/fdt etc
278and boot. For this example, there is a USB drive plugged in. It has a FAT
2791st partition and an EXT 2nd partition. Using the generic FS (ls/load) makes
280it even easier to work with FAT/EXT file systems.
281For this example the second EXT partition is used for booting and as rootfs.
282The boot files - kernel and the dtb are present in the /boot directory of the
283second partition.
284
285Odroid # usb start
286(Re)start USB...
287USB0: USB EHCI 1.00
288scanning bus 0 for devices... 4 USB Device(s) found
289 scanning usb for storage devices... 1 Storage Device(s) found
290 scanning usb for ethernet devices...
291Error: sms0 address not set. <----- Note the error as usbethaddr
292Warning: failed to set MAC address <----- is not set.
2931 Ethernet Device(s) found
294Odroid # usb part 0
295
296Partition Map for USB device 0 -- Partition Type: DOS
297
298Part Start Sector Num Sectors UUID Type
299 1 3072 263168 000c4046-01 06
300 2 266240 13457408 000c4046-02 83
301
302Odroid # ls usb 0:2 /boot
303<DIR> 4096 .
304<DIR> 4096 ..
305 353 boot.scr
306 281 boot.txt
307 101420 config-3.8.13.23
308 2127254 initrd.img-3.8.13.23
309 2194825 uInitrd
310 2194825 uInitrd-3.8.13.23
311 2453112 zImage
312 101448 config-3.8.13.26
313 2127670 uInitrd-3.8.13.26
314 2127606 initrd.img-3.8.13.26
315 3194200 zImage.3.17 <--- Kernel
316 46935 exynos4412-odroidu3.dtb <--- DTB
317Odroid # load usb 0:2 40080000 /boot/zImage.3.17
3183194200 bytes read in 471 ms (6.5 MiB/s)
319Odroid # load usb 0:2 42000000 /boot/exynos4412-odroidu3.dtb
32046935 bytes read in 233 ms (196.3 KiB/s)
321Odroid # setenv bootargs console=ttySAC1,115200n8 root=/dev/sda2 rootwait
322Odroid # bootz 40080000 - 42000000
323Kernel image @ 0x40080000 [ 0x000000 - 0x30bd58 ]
324## Flattened Device Tree blob at 42000000
325 Booting using the fdt blob at 0x42000000
326 Loading Device Tree to 4fff1000, end 4ffff756 ... OK
327
328Starting kernel ...
329
330[ 0.000000] Booting Linux on physical CPU 0xa00
331
332Please refer to README.usb for additional information.
333
README.OFT
README.omap-ulpi-viewport
1Reference code ""drivers/usb/ulpi/omap-ulpi-viewport.c"
2
3Contains the ulpi read write api's to perform
4any ulpi phy port access on omap platform.
5
6On omap ehci reg map contains INSNREG05_ULPI
7register which offers the ulpi phy access so
8any ulpi phy commands should be passsed using this
9register.
10
11omap-ulpi-viewport.c is a low level function
12implementation of "drivers/usb/ulpi/ulpi.c"
13
14To enable and use omap-ulpi-viewport.c
15we require CONFIG_USB_ULPI_VIEWPORT_OMAP and
16CONFIG_USB_ULPI be enabled in config file.
17
18Any ulpi ops request can be done with ulpi.c
19and soc specific binding and usage is done with
20omap-ulpi-viewport implementation.
21
22Ex: scenario:
23omap-ehci driver code requests for ulpi phy reset if
24ehci is used in phy mode, which will call ulpi phy reset
25the ulpi phy reset does ulpi_read/write from viewport
26implementation which will do ulpi reset using the
27INSNREG05_ULPI register.
28
README.omap3
1
2Summary
3=======
4
5This README is about U-Boot support for TI's ARM Cortex-A8 based OMAP3 [1]
6family of SoCs. TI's OMAP3 SoC family contains an ARM Cortex-A8. Additionally,
7some family members contain a TMS320C64x+ DSP and/or an Imagination SGX 2D/3D
8graphics processor and various other standard peripherals.
9
10Currently the following boards are supported:
11
12* OMAP3530 BeagleBoard [2]
13
14* Gumstix Overo [3]
15
16* TI EVM [4]
17
18* OpenPandora Ltd. Pandora [5]
19
20* TI/Logic PD Zoom MDK [6]
21
22* TI/Logic PD Zoom 2 [7]
23
24* CompuLab Ltd. CM-T35 [8]
25
26Build
27=====
28
29* BeagleBoard:
30
31make omap3_beagle_config
32make
33
34* Gumstix Overo:
35
36make omap3_overo_config
37make
38
39* TI EVM:
40
41make omap3_evm_config
42make
43
44* Zoom 2:
45
46make omap3_zoom2_config
47make
48
49* CM-T35:
50
51make cm_t35_config
52make
53
54
55Custom commands
56===============
57
58To make U-Boot for OMAP3 support NAND device SW or HW ECC calculation, U-Boot
59for OMAP3 supports custom user command
60
61nandecc hw/sw
62
63To be compatible with NAND drivers using SW ECC (e.g. kernel code)
64
65nandecc sw
66
67enables SW ECC calculation. HW ECC enabled with
68
69nandecc hw
70
71is typically used to write 2nd stage bootloader (known as 'x-loader') which is
72executed by OMAP3's boot rom and therefore has to be written with HW ECC.
73
74For all other commands see
75
76help
77
78Interfaces
79==========
80
81gpio
82----
83
84To set a bit :
85
86 if (!gpio_request(N, "")) {
87 gpio_direction_output(N, 0);
88 gpio_set_value(N, 1);
89 }
90
91To clear a bit :
92
93 if (!gpio_request(N, "")) {
94 gpio_direction_output(N, 0);
95 gpio_set_value(N, 0);
96 }
97
98To read a bit :
99
100 if (!gpio_request(N, "")) {
101 gpio_direction_input(N);
102 val = gpio_get_value(N);
103 gpio_free(N);
104 }
105 if (val)
106 printf("GPIO N is set\n");
107 else
108 printf("GPIO N is clear\n");
109
110dma
111---
112void omap3_dma_init(void)
113 Init the DMA module
114int omap3_dma_get_conf_chan(uint32_t chan, struct dma4_chan *config);
115 Read config of the channel
116int omap3_dma_conf_chan(uint32_t chan, struct dma4_chan *config);
117 Write config to the channel
118int omap3_dma_conf_transfer(uint32_t chan, uint32_t *src, uint32_t *dst,
119 uint32_t sze)
120 Config source, destination and size of a transfer
121int omap3_dma_wait_for_transfer(uint32_t chan)
122 Wait for a transfer to end - this hast to be called before a channel
123 or the data the channel transferd are used.
124int omap3_dma_get_revision(uint32_t *minor, uint32_t *major)
125 Read silicon Revision of the DMA module
126
127NAND
128====
129
130There are some OMAP3 devices out there with NAND attached. Due to the fact that
131OMAP3 ROM code can only handle 1-bit hamming ECC for accessing first page
132(place where SPL lives) we require this setup for u-boot at least when reading
133the second progam within SPL. A lot of newer NAND chips however require more
134than 1-bit ECC for the pages, some can live with 1-bit for the first page. To
135handle this we can switch to another ECC algorithm after reading the payload
136within SPL.
137
138BCH8
139----
140
141To enable hardware assisted BCH8 (8-bit BCH [Bose, Chaudhuri, Hocquenghem]) on
142OMAP3 devices we can use the BCH library in lib/bch.c. To do so add CONFIG_BCH
143and set CONFIG_NAND_OMAP_ECCSCHEME=5 (refer README.nand) for selecting BCH8_SW.
144The NAND OOB layout is the same as in linux kernel, if the linux kernel BCH8
145implementation for OMAP3 works for you so the u-boot version should also.
146When you require the SPL to read with BCH8 there are two more configs to
147change:
148
149 * CFG_SYS_NAND_ECCPOS (must be the same as .eccpos in
150 GPMC_NAND_HW_BCH8_ECC_LAYOUT defined in
151 arch/arm/include/asm/arch-omap3/omap_gpmc.h)
152 * CFG_SYS_NAND_ECCSIZE must be 512
153 * CFG_SYS_NAND_ECCBYTES must be 13 for this BCH8 setup
154
155Acknowledgements
156================
157
158OMAP3 U-Boot is based on U-Boot tar ball [9] for BeagleBoard and EVM done by
159several TI employees.
160
161Links
162=====
163
164[1] OMAP3:
165
166https://www.ti.com/omap3 (high volume) and
167https://www.ti.com/omap35x (broad market)
168
169[2] OMAP3530 BeagleBoard:
170
171http://beagleboard.org/
172
173[3] Gumstix Overo:
174
175http://www.gumstix.net/Overo/
176
177[4] TI EVM:
178
179http://focus.ti.com/docs/toolsw/folders/print/tmdxevm3503.html
180
181[5] OpenPandora Ltd. Pandora:
182
183http://openpandora.org/
184
185[6] TI/Logic PD Zoom MDK:
186
187http://www.logicpd.com/products/devkit/ti/zoom_mobile_development_kit
188
189[7] TI/Logic PD Zoom 2
190
191http://www.logicpd.com/sites/default/files/1012659A_Zoom_OMAP34x-II_MDP_Brief.pdf
192
193[8] CompuLab Ltd. CM-T35:
194
195http://www.compulab.co.il/t3530/html/t3530-cm-datasheet.htm
196
197[9] TI OMAP3 U-Boot:
198
199http://beagleboard.googlecode.com/files/u-boot_beagle_revb.tar.gz
200
README.pblimage
1------------------------------------------------------------------
2Freescale PBL(pre-boot loader) Boot Image generation using mkimage
3------------------------------------------------------------------
4
5The CoreNet SoC's can boot directly from eSPI FLASH, SD/MMC and
6NAND, etc. These SoCs use PBL to load RCW and/or pre-initialization
7instructions. For more details refer section 5 Pre-boot loader
8specifications of reference manual P3041RM/P4080RM/P5020RM at link:
9http://www.freescale.com/webapp/search/Serp.jsp?Reference+Manuals
10
11Building PBL Boot Image and boot steps
12--------------------------------------
13
141. Building PBL Boot Image.
15 The default Image is u-boot.pbl.
16
17 For eSPI boot(available on P2041/P3041/P4080/P5020/P5040/T4240):
18 To build the eSPI boot image:
19 make <board_name>_SPIFLASH
20
21 For SD boot(available on P2041/P3041/P4080/P5020/P5040/T4240):
22 To build the SD boot image:
23 make <board_name>_SDCARD
24
25 For Nand boot(available on P2041/P3041/P5020/P5040):
26 To build the NAND boot image:
27 make <board_name>_NAND
28
29
302. pblimage support available with mkimage utility will generate Freescale PBL
31boot image that can be flashed on the board eSPI flash, SD/MMC and NAND.
32Following steps describe it in detail.
33
34 1). Boot from eSPI flash
35 Write u-boot.pbl to eSPI flash from offset 0x0.
36 for ex in u-boot:
37 =>tftp 100000 u-boot.pbl
38 =>sf probe 0
39 =>sf erase 0 100000
40 =>sf write 100000 0 $filesize
41 Change SW1[1:5] = off off on off on.
42
43 2). Boot from SD/MMC
44 Write u-boot.pbl to SD/MMC from offset 0x1000.
45 for ex in u-boot:
46 =>tftp 100000 u-boot.pbl
47 =>mmcinfo
48 =>mmc write 100000 8 441
49 Change SW1[1:5] = off off on on off.
50
51 3). Boot from Nand
52 Write u-boot.pbl to Nand from offset 0x0.
53 for ex in u-boot:
54 =>tftp 100000 u-boot.pbl
55 =>nand info
56 =>nand erase 0 100000
57 =>nand write 100000 0 $filesize
58 Change SW1[1:5] = off on off off on
59 Change SW7[1:4] = on off off on
60
61Board specific configuration file specifications:
62------------------------------------------------
631. Configuration files rcw.cfg and pbi.cfg must present in the
64board/freescale/<BOARD>/ directory, rcw.cfg is for RCW, pbi.cfg is for
65PBI instructions. File name must not be changed since they are used
66in Makefile.
672. These files can have empty lines and lines starting with "#" as first
68character to put comments
69
70Typical example of rcw.cfg file:
71-----------------------------------
72
73#PBL preamble and RCW header
74aa55aa55 010e0100
75#64 bytes RCW data
764c580000 00000000 18185218 0000cccc
7740464000 3c3c2000 58000000 61000000
7800000000 00000000 00000000 008b6000
7900000000 00000000 00000000 00000000
80
81Typical example of pbi.cfg file:
82-----------------------------------
83
84#PBI commands
85#Initialize CPC1
8609010000 00200400
8709138000 00000000
88091380c0 00000100
8909010100 00000000
9009010104 fff0000b
9109010f00 08000000
9209010000 80000000
93#Configure LAW for CPC1
9409000d00 00000000
9509000d04 fff00000
9609000d08 81000013
9709000010 00000000
9809000014 ff000000
9909000018 81000000
100#Initialize eSPI controller
10109110000 80000403
10209110020 2d170008
10309110024 00100008
10409110028 00100008
1050911002c 00100008
106#Flush PBL data
10709138000 00000000
108091380c0 00000000
109
110------------------------------------------------
111Author: Shaohui Xie<Shaohui.Xie@freescale.com>
112
README.pcap
1PCAP:
2
3U-Boot supports live Ethernet packet capture in PCAP(2.4) format.
4This is enabled by CONFIG_CMD_PCAP.
5
6The capture is stored on physical memory, and should be copied to
7a machine capable of parsing and displaying PCAP files (IE. wireshark)
8If networking works properly one can copy the capture file from physical memory
9using tftpput, or save it to local storage with (sf write, mmc write, fatwrite, etc)
10
11the pcap capturing requires maximum buffer size.
12when the buffer is full an error message will be displayed and then packets
13will silently drop.
14the actual capture file size is populate in the environment variable "pcapsize".
15
16Usage example:
17
18# Initialize pcap capture to physical address (0x100000) with maximum size of
19# 100000 bytes.
20
21# Start capture
22pcap start
23
24# Initialize network activity
25env set ipaddr 10.0.2.15; env set serverip 10.0.2.2; tftp uImage64
26
27# Stop capture
28pcap stop
29
30# pcap init 0x100000 100000
31PCAP capture initialized: addr: 0xffffffff80100000 max length: 100000
32
33# pcap start
34# env set ipaddr 10.0.2.15; env set serverip 10.0.2.2; tftp uImage64
35eth0@10000000: PHY present at 0
36eth0@10000000: link up, 1000Mbps full-duplex (lpa: 0x7c00)
37Using eth0@10000000 device
38TFTP from server 10.0.2.2; our IP address is 10.0.2.15
39Filename 'uImage64'.
40Load address: 0xffffffff88000000
41Loading: #################################################################
42 #################################################################
43 #################################################################
44 #################################################################
45!!! Buffer is full, consider increasing buffer size !!!
46 #################################################################
47 #################################################################
48 #################################################################
49 #################################################################
50 #################################################################
51 #
52 18.2 MiB/s
53done
54Bytes transferred = 8359376 (7f8dd0 hex)
55PCAP status:
56 Initialized addr: 0xffffffff80100000 max length: 100000
57 Status: Active. file size: 99991
58 Incoming packets: 66 Outgoing packets: 67
59
60# pcap stop
61# tftpput 0xffffffff80100000 $pcapsize 10.0.2.2:capture.pcap
62
README.POST
1Power-On-Self-Test support in U-Boot
2------------------------------------
3
4This project is to support Power-On-Self-Test (POST) in U-Boot.
5
61. High-level requirements
7
8The key requirements for this project are as follows:
9
101) The project shall develop a flexible framework for implementing
11 and running Power-On-Self-Test in U-Boot. This framework shall
12 possess the following features:
13
14 o) Extensibility
15
16 The framework shall allow adding/removing/replacing POST tests.
17 Also, standalone POST tests shall be supported.
18
19 o) Configurability
20
21 The framework shall allow run-time configuration of the lists
22 of tests running on normal/power-fail booting.
23
24 o) Controllability
25
26 The framework shall support manual running of the POST tests.
27
282) The results of tests shall be saved so that it will be possible to
29 retrieve them from Linux.
30
313) The following POST tests shall be developed for MPC823E-based
32 boards:
33
34 o) CPU test
35 o) Cache test
36 o) Memory test
37 o) Ethernet test
38 o) Serial channels test
39 o) Watchdog timer test
40 o) RTC test
41 o) I2C test
42 o) SPI test
43 o) USB test
44
454) The LWMON board shall be used for reference.
46
472. Design
48
49This section details the key points of the design for the project.
50The whole project can be divided into two independent tasks:
51enhancing U-Boot/Linux to provide a common framework for running POST
52tests and developing such tests for particular hardware.
53
542.1. Hardware-independent POST layer
55
56A new optional module will be added to U-Boot, which will run POST
57tests and collect their results at boot time. Also, U-Boot will
58support running POST tests manually at any time by executing a
59special command from the system console.
60
61The list of available POST tests will be configured at U-Boot build
62time. The POST layer will allow the developer to add any custom POST
63tests. All POST tests will be divided into the following groups:
64
65 1) Tests running on power-on booting only
66
67 This group will contain those tests that run only once on
68 power-on reset (e.g. watchdog test)
69
70 2) Tests running on normal booting only
71
72 This group will contain those tests that do not take much
73 time and can be run on the regular basis (e.g. CPU test)
74
75 3) Tests running in special "slow test mode" only
76
77 This group will contain POST tests that consume much time
78 and cannot be run regularly (e.g. strong memory test, I2C test)
79
80 4) Manually executed tests
81
82 This group will contain those tests that can be run manually.
83
84If necessary, some tests may belong to several groups simultaneously.
85For example, SDRAM test may run in both normal and "slow test" mode.
86In normal mode, SDRAM test may perform a fast superficial memory test
87only, while running in slow test mode it may perform a full memory
88check-up.
89
90Also, all tests will be discriminated by the moment they run at.
91Specifically, the following groups will be singled out:
92
93 1) Tests running before relocating to RAM
94
95 These tests will run immediately after initializing RAM
96 as to enable modifying it without taking care of its
97 contents. Basically, this group will contain memory tests
98 only.
99
100 2) Tests running after relocating to RAM
101
102 These tests will run immediately before entering the main
103 loop as to guarantee full hardware initialization.
104
105The POST layer will also distinguish a special group of tests that
106may cause system rebooting (e.g. watchdog test). For such tests, the
107layer will automatically detect rebooting and will notify the test
108about it.
109
1102.1.1. POST layer interfaces
111
112This section details the interfaces between the POST layer and the
113rest of U-Boot.
114
115The following flags will be defined:
116
117#define POST_POWERON 0x01 /* test runs on power-on booting */
118#define POST_NORMAL 0x02 /* test runs on normal booting */
119#define POST_SLOWTEST 0x04 /* test is slow, enabled by key press */
120#define POST_POWERTEST 0x08 /* test runs after watchdog reset */
121#define POST_ROM 0x100 /* test runs in ROM */
122#define POST_RAM 0x200 /* test runs in RAM */
123#define POST_MANUAL 0x400 /* test can be executed manually */
124#define POST_REBOOT 0x800 /* test may cause rebooting */
125#define POST_PREREL 0x1000 /* test runs before relocation */
126
127The POST layer will export the following interface routines:
128
129 o) int post_run(struct bd_info *bd, char *name, int flags);
130
131 This routine will run the test (or the group of tests) specified
132 by the name and flag arguments. More specifically, if the name
133 argument is not NULL, the test with this name will be performed,
134 otherwise all tests running in ROM/RAM (depending on the flag
135 argument) will be executed. This routine will be called at least
136 twice with name set to NULL, once from board_init_f() and once
137 from board_init_r(). The flags argument will also specify the
138 mode the test is executed in (power-on, normal, power-fail,
139 manual).
140
141 o) int post_info(char *name);
142
143 This routine will print the list of all POST tests that can be
144 executed manually if name is NULL, and the description of a
145 particular test if name is not NULL.
146
147 o) int post_log(char *format, ...);
148
149 This routine will be called from POST tests to log their
150 results. Basically, this routine will print the results to
151 stderr. The format of the arguments and the return value
152 will be identical to the printf() routine.
153
154Also, the following board-specific routines will be called from the
155U-Boot common code:
156
157 o) int post_hotkeys_pressed(gd_t *gd)
158
159 This routine will scan the keyboard to detect if a magic key
160 combination has been pressed, or otherwise detect if the
161 power-on long-running tests shall be executed or not ("normal"
162 versus "slow" test mode).
163
164The list of available POST tests be kept in the post_tests array
165filled at U-Boot build time. The format of entry in this array will
166be as follows:
167
168struct post_test {
169 char *name;
170 char *cmd;
171 char *desc;
172 int flags;
173 int (*test)(struct bd_info *bd, int flags);
174};
175
176 o) name
177
178 This field will contain a short name of the test, which will be
179 used in logs and on listing POST tests (e.g. CPU test).
180
181 o) cmd
182
183 This field will keep a name for identifying the test on manual
184 testing (e.g. cpu). For more information, refer to section
185 "Command line interface".
186
187 o) desc
188
189 This field will contain a detailed description of the test,
190 which will be printed on user request. For more information, see
191 section "Command line interface".
192
193 o) flags
194
195 This field will contain a combination of the bit flags described
196 above, which will specify the mode the test is running in
197 (power-on, normal, power-fail or manual mode), the moment it
198 should be run at (before or after relocating to RAM), whether it
199 can cause system rebooting or not.
200
201 o) test
202
203 This field will contain a pointer to the routine that will
204 perform the test, which will take 2 arguments. The first
205 argument will be a pointer to the board info structure, while
206 the second will be a combination of bit flags specifying the
207 mode the test is running in (POST_POWERON, POST_NORMAL,
208 POST_SLOWTEST, POST_MANUAL) and whether the last execution of
209 the test caused system rebooting (POST_REBOOT). The routine will
210 return 0 on successful execution of the test, and 1 if the test
211 failed.
212
213The lists of the POST tests that should be run at power-on/normal/
214power-fail booting will be kept in the environment. Namely, the
215following environment variables will be used: post_poweron,
216powet_normal, post_slowtest.
217
2182.1.2. Test results
219
220The results of tests will be collected by the POST layer. The POST
221log will have the following format:
222
223...
224--------------------------------------------
225START <name>
226<test-specific output>
227[PASSED|FAILED]
228--------------------------------------------
229...
230
231Basically, the results of tests will be printed to stderr. This
232feature may be enhanced in future to spool the log to a serial line,
233save it in non-volatile RAM (NVRAM), transfer it to a dedicated
234storage server and etc.
235
2362.1.3. Integration issues
237
238All POST-related code will be #ifdef'ed with the CONFIG_POST macro.
239This macro will be defined in the config_<board>.h file for those
240boards that need POST. The CFG_POST macro will contain the list of
241POST tests for the board. The macro will have the format of array
242composed of post_test structures:
243
244#define CFG_POST \
245 {
246 "On-board peripherals test", "board", \
247 " This test performs full check-up of the " \
248 "on-board hardware.", \
249 POST_RAM | POST_SLOWTEST, \
250 &board_post_test \
251 }
252
253A new file, post.h, will be created in the include/ directory. This
254file will contain common POST declarations and will define a set of
255macros that will be reused for defining CFG_POST. As an example,
256the following macro may be defined:
257
258#define POST_CACHE \
259 {
260 "Cache test", "cache", \
261 " This test verifies the CPU cache operation.", \
262 POST_RAM | POST_NORMAL, \
263 &cache_post_test \
264 }
265
266A new subdirectory will be created in the U-Boot root directory. It
267will contain the source code of the POST layer and most of POST
268tests. Each POST test in this directory will be placed into a
269separate file (it will be needed for building standalone tests). Some
270POST tests (mainly those for testing peripheral devices) will be
271located in the source files of the drivers for those devices. This
272way will be used only if the test subtantially uses the driver.
273
2742.1.4. Standalone tests
275
276The POST framework will allow to develop and run standalone tests. A
277user-space library will be developed to provide the POST interface
278functions to standalone tests.
279
2802.1.5. Command line interface
281
282A new command, diag, will be added to U-Boot. This command will be
283used for listing all available hardware tests, getting detailed
284descriptions of them and running these tests.
285
286More specifically, being run without any arguments, this command will
287print the list of all available hardware tests:
288
289=> diag
290Available hardware tests:
291 cache - cache test
292 cpu - CPU test
293 enet - SCC/FCC ethernet test
294Use 'diag [<test1> [<test2>]] ... ' to get more info.
295Use 'diag run [<test1> [<test2>]] ... ' to run tests.
296=>
297
298If the first argument to the diag command is not 'run', detailed
299descriptions of the specified tests will be printed:
300
301=> diag cpu cache
302cpu - CPU test
303 This test verifies the arithmetic logic unit of CPU.
304cache - cache test
305 This test verifies the CPU cache operation.
306=>
307
308If the first argument to diag is 'run', the specified tests will be
309executed. If no tests are specified, all available tests will be
310executed.
311
312It will be prohibited to execute tests running in ROM manually. The
313'diag' command will not display such tests and/or run them.
314
3152.1.6. Power failure handling
316
317The Linux kernel will be modified to detect power failures and
318automatically reboot the system in such cases. It will be assumed
319that the power failure causes a system interrupt.
320
321To perform correct system shutdown, the kernel will register a
322handler of the power-fail IRQ on booting. Being called, the handler
323will run /sbin/reboot using the call_usermodehelper() routine.
324/sbin/reboot will automatically bring the system down in a secure
325way. This feature will be configured in/out from the kernel
326configuration file.
327
328The POST layer of U-Boot will check whether the system runs in
329power-fail mode. If it does, the system will be powered off after
330executing all hardware tests.
331
3322.1.7. Hazardous tests
333
334Some tests may cause system rebooting during their execution. For
335some tests, this will indicate a failure, while for the Watchdog
336test, this means successful operation of the timer.
337
338In order to support such tests, the following scheme will be
339implemented. All the tests that may cause system rebooting will have
340the POST_REBOOT bit flag set in the flag field of the correspondent
341post_test structure. Before starting tests marked with this bit flag,
342the POST layer will store an identification number of the test in a
343location in IMMR. On booting, the POST layer will check the value of
344this variable and if it is set will skip over the tests preceding the
345failed one. On second execution of the failed test, the POST_REBOOT
346bit flag will be set in the flag argument to the test routine. This
347will allow to detect system rebooting on the previous iteration. For
348example, the watchdog timer test may have the following
349declaration/body:
350
351...
352#define POST_WATCHDOG \
353 {
354 "Watchdog timer test", "watchdog", \
355 " This test checks the watchdog timer.", \
356 POST_RAM | POST_POWERON | POST_REBOOT, \
357 &watchdog_post_test \
358 }
359...
360
361...
362int watchdog_post_test(struct bd_info *bd, int flags)
363{
364 unsigned long start_time;
365
366 if (flags & POST_REBOOT) {
367 /* Test passed */
368 return 0;
369 } else {
370 /* disable interrupts */
371 disable_interrupts();
372 /* 10-second delay */
373 ...
374 /* if we've reached this, the watchdog timer does not work */
375 enable_interrupts();
376 return 1;
377 }
378}
379...
380
3812.2. Hardware-specific details
382
383This project will also develop a set of POST tests for MPC8xx- based
384systems. This section provides technical details of how it will be
385done.
386
3872.2.1. Generic PPC tests
388
389The following generic POST tests will be developed:
390
391 o) CPU test
392
393 This test will check the arithmetic logic unit (ALU) of CPU. The
394 test will take several milliseconds and will run on normal
395 booting.
396
397 o) Cache test
398
399 This test will verify the CPU cache (L1 cache). The test will
400 run on normal booting.
401
402 o) Memory test
403
404 This test will examine RAM and check it for errors. The test
405 will always run on booting. On normal booting, only a limited
406 amount of RAM will be checked. On power-fail booting a fool
407 memory check-up will be performed.
408
4092.2.1.1. CPU test
410
411This test will verify the following ALU instructions:
412
413 o) Condition register istructions
414
415 This group will contain: mtcrf, mfcr, mcrxr, crand, crandc,
416 cror, crorc, crxor, crnand, crnor, creqv, mcrf.
417
418 The mtcrf/mfcr instructions will be tested by loading different
419 values into the condition register (mtcrf), moving its value to
420 a general-purpose register (mfcr) and comparing this value with
421 the expected one. The mcrxr instruction will be tested by
422 loading a fixed value into the XER register (mtspr), moving XER
423 value to the condition register (mcrxr), moving it to a
424 general-purpose register (mfcr) and comparing the value of this
425 register with the expected one. The rest of instructions will be
426 tested by loading a fixed value into the condition register
427 (mtcrf), executing each instruction several times to modify all
428 4-bit condition fields, moving the value of the conditional
429 register to a general-purpose register (mfcr) and comparing it
430 with the expected one.
431
432 o) Integer compare instructions
433
434 This group will contain: cmp, cmpi, cmpl, cmpli.
435
436 To verify these instructions the test will run them with
437 different combinations of operands, read the condition register
438 value and compare it with the expected one. More specifically,
439 the test will contain a pre-built table containing the
440 description of each test case: the instruction, the values of
441 the operands, the condition field to save the result in and the
442 expected result.
443
444 o) Arithmetic instructions
445
446 This group will contain: add, addc, adde, addme, addze, subf,
447 subfc, subfe, subme, subze, mullw, mulhw, mulhwu, divw, divwu,
448 extsb, extsh.
449
450 The test will contain a pre-built table of instructions,
451 operands, expected results and expected states of the condition
452 register. For each table entry, the test will cyclically use
453 different sets of operand registers and result registers. For
454 example, for instructions that use 3 registers on the first
455 iteration r0/r1 will be used as operands and r2 for result. On
456 the second iteration, r1/r2 will be used as operands and r3 as
457 for result and so on. This will enable to verify all
458 general-purpose registers.
459
460 o) Logic instructions
461
462 This group will contain: and, andc, andi, andis, or, orc, ori,
463 oris, xor, xori, xoris, nand, nor, neg, eqv, cntlzw.
464
465 The test scheme will be identical to that from the previous
466 point.
467
468 o) Shift instructions
469
470 This group will contain: slw, srw, sraw, srawi, rlwinm, rlwnm,
471 rlwimi
472
473 The test scheme will be identical to that from the previous
474 point.
475
476 o) Branch instructions
477
478 This group will contain: b, bl, bc.
479
480 The first 2 instructions (b, bl) will be verified by jumping to
481 a fixed address and checking whether control was transferred to
482 that very point. For the bl instruction the value of the link
483 register will be checked as well (using mfspr). To verify the bc
484 instruction various combinations of the BI/BO fields, the CTR
485 and the condition register values will be checked. The list of
486 such combinations will be pre-built and linked in U-Boot at
487 build time.
488
489 o) Load/store instructions
490
491 This group will contain: lbz(x)(u), lhz(x)(u), lha(x)(u),
492 lwz(x)(u), stb(x)(u), sth(x)(u), stw(x)(u).
493
494 All operations will be performed on a 16-byte array. The array
495 will be 4-byte aligned. The base register will point to offset
496 8. The immediate offset (index register) will range in [-8 ...
497 +7]. The test cases will be composed so that they will not cause
498 alignment exceptions. The test will contain a pre-built table
499 describing all test cases. For store instructions, the table
500 entry will contain: the instruction opcode, the value of the
501 index register and the value of the source register. After
502 executing the instruction, the test will verify the contents of
503 the array and the value of the base register (it must change for
504 "store with update" instructions). For load instructions, the
505 table entry will contain: the instruction opcode, the array
506 contents, the value of the index register and the expected value
507 of the destination register. After executing the instruction,
508 the test will verify the value of the destination register and
509 the value of the base register (it must change for "load with
510 update" instructions).
511
512 o) Load/store multiple/string instructions
513
514
515The CPU test will run in RAM in order to allow run-time modification
516of the code to reduce the memory footprint.
517
5182.2.1.2 Special-Purpose Registers Tests
519
520TBD.
521
5222.2.1.3. Cache test
523
524To verify the data cache operation the following test scenarios will
525be used:
526
527 1) Basic test #1
528
529 - turn on the data cache
530 - switch the data cache to write-back or write-through mode
531 - invalidate the data cache
532 - write the negative pattern to a cached area
533 - read the area
534
535 The negative pattern must be read at the last step
536
537 2) Basic test #2
538
539 - turn on the data cache
540 - switch the data cache to write-back or write-through mode
541 - invalidate the data cache
542 - write the zero pattern to a cached area
543 - turn off the data cache
544 - write the negative pattern to the area
545 - turn on the data cache
546 - read the area
547
548 The negative pattern must be read at the last step
549
550 3) Write-through mode test
551
552 - turn on the data cache
553 - switch the data cache to write-through mode
554 - invalidate the data cache
555 - write the zero pattern to a cached area
556 - flush the data cache
557 - write the negative pattern to the area
558 - turn off the data cache
559 - read the area
560
561 The negative pattern must be read at the last step
562
563 4) Write-back mode test
564
565 - turn on the data cache
566 - switch the data cache to write-back mode
567 - invalidate the data cache
568 - write the negative pattern to a cached area
569 - flush the data cache
570 - write the zero pattern to the area
571 - invalidate the data cache
572 - read the area
573
574 The negative pattern must be read at the last step
575
576To verify the instruction cache operation the following test
577scenarios will be used:
578
579 1) Basic test #1
580
581 - turn on the instruction cache
582 - unlock the entire instruction cache
583 - invalidate the instruction cache
584 - lock a branch instruction in the instruction cache
585 - replace the branch instruction with "nop"
586 - jump to the branch instruction
587 - check that the branch instruction was executed
588
589 2) Basic test #2
590
591 - turn on the instruction cache
592 - unlock the entire instruction cache
593 - invalidate the instruction cache
594 - jump to a branch instruction
595 - check that the branch instruction was executed
596 - replace the branch instruction with "nop"
597 - invalidate the instruction cache
598 - jump to the branch instruction
599 - check that the "nop" instruction was executed
600
601The CPU test will run in RAM in order to allow run-time modification
602of the code.
603
6042.2.1.4. Memory test
605
606The memory test will verify RAM using sequential writes and reads
607to/from RAM. Specifically, there will be several test cases that will
608use different patterns to verify RAM. Each test case will first fill
609a region of RAM with one pattern and then read the region back and
610compare its contents with the pattern. The following patterns will be
611used:
612
613 1) zero pattern (0x00000000)
614 2) negative pattern (0xffffffff)
615 3) checkerboard pattern (0x55555555, 0xaaaaaaaa)
616 4) bit-flip pattern ((1 << (offset % 32)), ~(1 << (offset % 32)))
617 5) address pattern (offset, ~offset)
618
619Patterns #1, #2 will help to find unstable bits. Patterns #3, #4 will
620be used to detect adherent bits, i.e. bits whose state may randomly
621change if adjacent bits are modified. The last pattern will be used
622to detect far-located errors, i.e. situations when writing to one
623location modifies an area located far from it. Also, usage of the
624last pattern will help to detect memory controller misconfigurations
625when RAM represents a cyclically repeated portion of a smaller size.
626
627Being run in normal mode, the test will verify only small 4Kb regions
628of RAM around each 1Mb boundary. For example, for 64Mb RAM the
629following areas will be verified: 0x00000000-0x00000800,
6300x000ff800-0x00100800, 0x001ff800-0x00200800, ..., 0x03fff800-
6310x04000000. If the test is run in power-fail mode, it will verify the
632whole RAM.
633
634The memory test will run in ROM before relocating U-Boot to RAM in
635order to allow RAM modification without saving its contents.
636
6372.2.2. Common tests
638
639This section describes tests that are not based on any hardware
640peculiarities and use common U-Boot interfaces only. These tests do
641not need any modifications for porting them to another board/CPU.
642
6432.2.2.1. I2C test
644
645For verifying the I2C bus, a full I2C bus scanning will be performed
646using the i2c_probe() routine. If a board defines
647CFG_SYS_POST_I2C_ADDRS the I2C test will pass if all devices
648listed in CFG_SYS_POST_I2C_ADDRS are found, and no additional
649devices are detected. If CFG_SYS_POST_I2C_ADDRS is not defined
650the test will pass if any I2C device is found.
651
652The CFG_SYS_POST_I2C_IGNORES define can be used to list I2C
653devices which may or may not be present when using
654CFG_SYS_POST_I2C_ADDRS. The I2C POST test will pass regardless
655if the devices in CFG_SYS_POST_I2C_IGNORES are found or not.
656This is useful in cases when I2C devices are optional (eg on a
657daughtercard that may or may not be present) or not critical
658to board operation.
659
6602.2.2.2. Watchdog timer test
661
662To test the watchdog timer the scheme mentioned above (refer to
663section "Hazardous tests") will be used. Namely, this test will be
664marked with the POST_REBOOT bit flag. On the first iteration, the
665test routine will make a 10-second delay. If the system does not
666reboot during this delay, the watchdog timer is not operational and
667the test fails. If the system reboots, on the second iteration the
668POST_REBOOT bit will be set in the flag argument to the test routine.
669The test routine will check this bit and report a success if it is
670set.
671
6722.2.2.3. RTC test
673
674The RTC test will use the rtc_get()/rtc_set() routines. The following
675features will be verified:
676
677 o) Time uniformity
678
679 This will be verified by reading RTC in polling within a short
680 period of time (5-10 seconds).
681
682 o) Passing month boundaries
683
684 This will be checked by setting RTC to a second before a month
685 boundary and reading it after its passing the boundary. The test
686 will be performed for both leap- and nonleap-years.
687
6882.2.3. MPC8xx peripherals tests
689
690This project will develop a set of tests verifying the peripheral
691units of MPC8xx processors. Namely, the following controllers of the
692MPC8xx communication processor module (CPM) will be tested:
693
694 o) Serial Management Controllers (SMC)
695
696 o) Serial Communication Controllers (SCC)
697
6982.2.3.1. Ethernet tests (SCC)
699
700The internal (local) loopback mode will be used to test SCC. To do
701that the controllers will be configured accordingly and several
702packets will be transmitted. These tests may be enhanced in future to
703use external loopback for testing. That will need appropriate
704reconfiguration of the physical interface chip.
705
706The test routines for the SCC ethernet tests will be located in
707arch/powerpc/cpu/mpc8xx/scc.c.
708
7092.2.3.2. UART tests (SMC/SCC)
710
711To perform these tests the internal (local) loopback mode will be
712used. The SMC/SCC controllers will be configured to connect the
713transmitter output to the receiver input. After that, several bytes
714will be transmitted. These tests may be enhanced to make to perform
715"external" loopback test using a loopback cable. In this case, the
716test will be executed manually.
717
718The test routine for the SMC/SCC UART tests will be located in
719arch/powerpc/cpu/mpc8xx/serial.c.
720
7212.2.3.3. USB test
722
723TBD
724
7252.2.3.4. SPI test
726
727TBD
728
README.power-framework
1#
2# (C) Copyright 2014 Samsung Electronics
3# Lukasz Majewski <l.majewski@samsung.com>
4#
5# SPDX-License-Identifier: GPL-2.0+
6#
7
8Introduction
9------------
10
11This document describes the second version of the u-boot's PMIC (Power
12Management IC) framework. As a reference boards please consider Samsungs' Trats
13and Trats2.
14
15Background
16----------
17
18Boards supported by u-boot are getting increasingly complex. Developers and
19designers strive to cut down power consumption. Hence several different types of
20devices are now available on the board - namely power managers (PMIC), fuel
21gauges (FG), micro USB interface controllers (MUIC), batteries, multi-function
22devices (MFD).
23
24Explanation of key design decisions
25-----------------------------------
26
27One package can integrate PMIC and MUIC with different addresses on the I2C bus.
28The same device - e.g. MAX8997 uses two different I2C busses and addresses.
29
30Power devices use not only I2C for communication, but SPI as well. Additionally
31different ICs use different endianess. For this reason struct pmic holds
32information about I2C/SPI transmission, which is used with generic
33pmic_req_write() function.
34
35The "flat" hierarchy for power devices works well when each device performs only
36one operation - e.g. PMIC enables LDO.
37
38The problem emerges when we have a device (battery) which conceptually shall be
39the master and uses methods exported by other devices. We need to control MUIC
40to start charging the battery, use PMIC to reduce board's overall power
41consumption (by disabling not needed LDOs, BUCKs) and get current state of
42energy on the battery from FG.
43Up till now u-boot doesn't support device model, so a simple one had to be
44added.
45
46The directory hierarchy has following structure:
47./include/power/<device_name>_<device_function>.h
48e.g. ./include/power/max8997_pmic.h
49
50./drivers/power/pmic/power_{core files}.c
51e.g. ./drivers/power/pmic/power_core.c
52
53./drivers/power/pmic/<device_function>/<device_function>_<device_name>.c
54e.g. ./drivers/power/pmic/pmic_max8997.c
55e.g. ./drivers/power/battery/trats/bat_trats.c
56e.g. ./drivers/power/fuel_gauge/fg_max17042.c
57
58The framework classifies devices by their function - separate directories should
59be maintained for different classes of devices.
60
61Current design
62--------------
63
64Everything is a power device described by struct pmic. Even battery is
65considered as a valid power device. This helps for better management of those
66devices.
67
68- Block diagram of the hierarchy:
69 -----------------
70 --------| BAT |------------
71 | | | |
72 | ----------------- |
73 | | |
74 \|/ \|/ \|/
75 ----------- ----------------- ---------
76 |FG | |MUIC | |CHRG |
77 | | | | | |
78 ----------- ----------------- ---------
79
80
811. When hierarchy is not needed (no complex battery charge):
82
83Definition of the struct pmic is only required with proper name and parameters
84for communication. This is enough to use the "pmic" command in the u-boot
85prompt to change values of device's register (enable/disable LDO, BUCK).
86
87The PG, MUIC and CHRG above are regarded to be in the same level in the
88hierarchy.
89
902. Complex battery charging.
91
92To charge a battery, information from several "abstract" power devices is
93needed (defined at ./include/power/pmic.h):
94- FG device (struct power_fg):
95 -- *fg_battery_check - check if battery is not above its limits
96 -- *fg_battery_update - update the pmic framework with current
97 battery state(voltage and current capacity)
98
99- Charger device (struct power_chrq):
100 -- *chrg_type - type/capacity of the charger (including information
101 about USB cable disconnection)
102 -- *chrg_bat_present - detection if battery to be charged is
103 present
104 -- *chrg_state - status of the charger - if it is enabled or
105 disabled
106
107- Battery device (struct power_battery):
108 -- *battery_init - assign proper callbacks to be used by top
109 hierarchy battery device
110 -- *battery_charge - called from "pmic" command, responsible
111 for performing the charging
112
113Now two batteries are supported; trats and trats2 [*]. Those differ in the way
114how they handle the exact charging. Trats uses polling (MAX8997) and trats2
115relies on the PMIC/MUIC HW completely (MAX77693).
116
117__Example for trats (this can be very different for other board):__
118 -- *fg_battery_check -> FG device (fg_max17042.c)
119 -- *fg_battery_update -> FG device (fg_max17042.c)
120 -- *chrg_type -> MUIC device (muic_max8997.c)
121 -- *chrg_bat_present -> PMIC device (pmic_max8997.c)
122 -- *chrg_state -> PMIC device (pmic_max8997.c)
123 -- *battery_init -> BAT device (bat_trats.c)
124 -- *battery_charge -> BAT device (bat_trats.c)
125
126Also the struct pmic holds method (*low_power_mode) for reducing board's
127power consumption when one calls "pmic BAT_TRATS bat charge" command.
128
129How to add a new power device
130-----------------------------
131
1321. Simple device should be added with creation of file
133<pmic_function>_<pmic_name>.c, <pmic_name>_<pmic_function>.h according to the
134proposed and described above scheme.
135
136Then "pmic" command supports reading/writing/dump of device's internal
137registers.
138
1392. Charging battery with hierarchy
140Define devices as listed at 1.
141
142Define battery file (bat_<board>.c). Please also note that one might need a
143corresponding battery model description for FG.
144
145For points 1 and 2 use a generic function power_init_board() to initialise the
146power framework on your board.
147
148For reference, please look into the trats/trats2 boards.
149
150TO DO list (for PMICv3) - up till v2014.04
151------------------------------------------
152
1531. Description of the devices related to power via device tree is not available.
154This is the main problem when a developer tries to build a multi-boot u-boot
155binary. The best would be to parse the DTS from Linux kernel.
156
1572. To support many instances of the same IC, like two MAX8997, one needs to
158copy the corresponding pmic_max8997.c file with changed name to "MAX8997_PMICX",
159where X is the device number. This problem will be addressed when extended
160pmic_core.c will support storing available devices in a list.
161
1623. Definition of batteries [*] (for trats/trats2) should be excluded from the
163code responsible for charging them and since it in fact describes the charging
164profile it should be put to a separate file.
165
1664. Adjust the framework to work with the device model.
167
README.pxe
1SPDX-License-Identifier: GPL-2.0+
2/*
3 * Copyright 2010-2011 Calxeda, Inc.
4 */
5
6The 'pxe' commands provide a near subset of the functionality provided by
7the PXELINUX boot loader. This allows U-Boot based systems to be controlled
8remotely using the same PXE based techniques that many non U-Boot based servers
9use.
10
11Commands
12========
13
14pxe get
15-------
16 syntax: pxe get
17
18 follows PXELINUX's rules for retrieving configuration files from a tftp
19 server, and supports a subset of PXELINUX's config file syntax.
20
21 Environment
22 -----------
23 'pxe get' requires two environment variables to be set:
24
25 pxefile_addr_r - should be set to a location in RAM large enough to hold
26 pxe files while they're being processed. Up to 16 config files may be
27 held in memory at once. The exact number and size of the files varies with
28 how the system is being used. A typical config file is a few hundred bytes
29 long.
30
31 bootfile,serverip - these two are typically set in the DHCP response
32 handler, and correspond to fields in the DHCP response.
33
34 'pxe get' optionally supports these two environment variables being set:
35
36 ethaddr - this is the standard MAC address for the ethernet adapter in use.
37 'pxe get' uses it to look for a configuration file specific to a system's
38 MAC address.
39
40 pxeuuid - this is a UUID in standard form using lower case hexadecimal
41 digits, for example, 550e8400-e29b-41d4-a716-446655440000. 'pxe get' uses
42 it to look for a configuration file based on the system's UUID.
43
44 File Paths
45 ----------
46 'pxe get' repeatedly tries to download config files until it either
47 successfully downloads one or runs out of paths to try. The order and
48 contents of paths it tries mirrors exactly that of PXELINUX - you can
49 read in more detail about it at:
50
51 http://syslinux.zytor.com/wiki/index.php/Doc/pxelinux
52
53pxe boot
54--------
55 syntax: pxe boot [pxefile_addr_r]
56
57 Interprets a pxe file stored in memory.
58
59 pxefile_addr_r is an optional argument giving the location of the pxe file.
60 The file must be terminated with a NUL byte.
61
62 Environment
63 -----------
64 There are some environment variables that may need to be set, depending
65 on conditions.
66
67 pxefile_addr_r - if the optional argument pxefile_addr_r is not supplied,
68 an environment variable named pxefile_addr_r must be supplied. This is
69 typically the same value as is used for the 'pxe get' command.
70
71 bootfile - typically set in the DHCP response handler based on the
72 same field in the DHCP respone, this path is used to generate the base
73 directory that all other paths to files retrieved by 'pxe boot' will use.
74 If no bootfile is specified, paths used in pxe files will be used as is.
75
76 serverip - typically set in the DHCP response handler, this is the IP
77 address of the tftp server from which other files will be retrieved.
78
79 kernel_addr_r, initrd_addr_r - locations in RAM at which 'pxe boot' will
80 store the kernel(or FIT image) and initrd it retrieves from tftp. These
81 locations will be passed to the bootm command to boot the kernel. These
82 environment variables are required to be set.
83
84 fdt_addr_r - location in RAM at which 'pxe boot' will store the fdt blob it
85 retrieves from tftp. The retrieval is possible if 'fdt' label is defined in
86 pxe file and 'fdt_addr_r' is set. If retrieval is possible, 'fdt_addr_r'
87 will be passed to bootm command to boot the kernel.
88
89 fdt_addr - the location of a fdt blob. 'fdt_addr' will be passed to bootm
90 command if it is set and 'fdt_addr_r' is not passed to bootm command.
91
92 fdtoverlay_addr_r - location in RAM at which 'pxe boot' will temporarily store
93 fdt overlay(s) before applying them to the fdt blob stored at 'fdt_addr_r'.
94
95 pxe_label_override - override label to be used, if exists, instead of the
96 default label. This will allow consumers to choose a pxe label at
97 runtime instead of having to prompt the user. If "pxe_label_override" is set
98 but does not exist in the pxe menu, pxe would fallback to the default label if
99 given, and no failure is returned but rather a warning message.
100
101pxe file format
102===============
103The pxe file format is nearly a subset of the PXELINUX file format; see
104http://syslinux.zytor.com/wiki/index.php/PXELINUX. It's composed of one line
105commands - global commands, and commands specific to labels. Lines begining
106with # are treated as comments. White space between and at the beginning of
107lines is ignored.
108
109The size of pxe files and the number of labels is only limited by the amount
110of RAM available to U-Boot. Memory for labels is dynamically allocated as
111they're parsed, and memory for pxe files is statically allocated, and its
112location is given by the pxefile_addr_r environment variable. The pxe code is
113not aware of the size of the pxefile memory and will outgrow it if pxe files
114are too large.
115
116Supported global commands
117-------------------------
118Unrecognized commands are ignored.
119
120default <label> - the label named here is treated as the default and is
121 the first label 'pxe boot' attempts to boot.
122
123menu title <string> - sets a title for the menu of labels being displayed.
124
125menu include <path> - use tftp to retrieve the pxe file at <path>, which
126 is then immediately parsed as if the start of its
127 contents were the next line in the current file. nesting
128 of include up to 16 files deep is supported.
129
130prompt <flag> - if 1, always prompt the user to enter a label to boot
131 from. if 0, only prompt the user if timeout expires.
132
133timeout <num> - wait for user input for <num>/10 seconds before
134 auto-booting a node.
135
136label <name> - begin a label definition. labels continue until
137 a command not recognized as a label command is seen,
138 or EOF is reached.
139
140Supported label commands
141------------------------
142labels end when a command not recognized as a label command is reached, or EOF.
143
144menu default - set this label as the default label to boot; this is
145 the same behavior as the global default command but
146 specified in a different way
147
148kernel <path> - if this label is chosen, use tftp to retrieve the kernel
149 (or FIT image) at <path>. it will be stored at the address
150 indicated in the kernel_addr_r environment variable, and
151 that address will be passed to bootm to boot this kernel.
152 For FIT image, The configuration specification can be
153 appended to the file name, with the format:
154 <path>#<conf>[#<extra-conf[#...]]
155 It will passed to bootm with that address.
156 (see: doc/uImage.FIT/command_syntax_extensions.txt)
157 It useful for overlay selection in pxe file
158 (see: doc/uImage.FIT/overlay-fdt-boot.txt)
159
160fdtoverlays <path> [...] - if this label is chosen, use tftp to retrieve the DT
161 overlay(s) at <path>. it will be temporarily stored at the
162 address indicated in the fdtoverlay_addr_r environment variable,
163 and then applied in the load order to the fdt blob stored at the
164 address indicated in the fdt_addr_r environment variable.
165
166devicetree-overlay <path> [...] - if this label is chosen, use tftp to retrieve the DT
167 overlay(s) at <path>. it will be temporarily stored at the
168 address indicated in the fdtoverlay_addr_r environment variable,
169 and then applied in the load order to the fdt blob stored at the
170 address indicated in the fdt_addr_r environment variable.
171 Alias for fdtoverlays.
172
173kaslrseed - set this label to request random number from hwrng as kaslr seed.
174
175append <string> - use <string> as the kernel command line when booting this
176 label.
177
178initrd <path> - if this label is chosen, use tftp to retrieve the initrd
179 at <path>. it will be stored at the address indicated in
180 the initrd_addr_r environment variable, and that address
181 will be passed to bootm.
182 For FIT image, the initrd can be provided with the same value than
183 kernel, including configuration:
184 <path>#<conf>[#<extra-conf[#...]]
185 In this case, kernel_addr_r is passed to bootm.
186
187fdt <path> - if this label is chosen, use tftp to retrieve the fdt blob
188 at <path>. it will be stored at the address indicated in
189 the fdt_addr_r environment variable, and that address will
190 be passed to bootm.
191 For FIT image, the device tree can be provided with the same value
192 than kernel, including configuration:
193 <path>#<conf>[#<extra-conf[#...]]
194 In this case, kernel_addr_r is passed to bootm.
195
196devicetree <path> - if this label is chosen, use tftp to retrieve the fdt blob
197 at <path>. it will be stored at the address indicated in
198 the fdt_addr_r environment variable, and that address will
199 be passed to bootm. Alias for fdt.
200
201fdtdir <path> - if this label is chosen, use tftp to retrieve a fdt blob
202 relative to <path>. If the fdtfile environment variable
203 is set, <path>/<fdtfile> is retrieved. Otherwise, the
204 filename is generated from the soc and board environment
205 variables, i.e. <path>/<soc>-<board>.dtb is retrieved.
206 If the fdt command is specified, fdtdir is ignored.
207
208localboot <flag> - Run the command defined by "localcmd" in the environment.
209 <flag> is ignored and is only here to match the syntax of
210 PXELINUX config files.
211
212Example
213-------
214Here's a couple of example files to show how this works.
215
216------------/tftpboot/pxelinux.cfg/menus/base.menu-----------
217menu title Linux selections
218
219# This is the default label
220label install
221 menu label Default Install Image
222 kernel kernels/install.bin
223 append console=ttyAMA0,38400 debug earlyprintk
224 initrd initrds/uzInitrdDebInstall
225
226# Just another label
227label linux-2.6.38
228 kernel kernels/linux-2.6.38.bin
229 append root=/dev/sdb1
230
231# The locally installed kernel
232label local
233 menu label Locally installed kernel
234 append root=/dev/sdb1
235 localboot 1
236-------------------------------------------------------------
237
238------------/tftpboot/pxelinux.cfg/default-------------------
239menu include pxelinux.cfg/menus/base.menu
240timeout 500
241
242default linux-2.6.38
243-------------------------------------------------------------
244
245When a pxe client retrieves and boots the default pxe file,
246'pxe boot' will wait for user input for 5 seconds before booting
247the linux-2.6.38 label, which will cause /tftpboot/kernels/linux-2.6.38.bin
248to be downloaded, and boot with the command line "root=/dev/sdb1"
249
250Differences with PXELINUX
251=========================
252The biggest difference between U-Boot's pxe and PXELINUX is that since
253U-Boot's pxe support is written entirely in C, it can run on any platform
254with network support in U-Boot. Here are some other differences between
255PXELINUX and U-Boot's pxe support.
256
257- U-Boot's pxe does not support the PXELINUX DHCP option codes specified
258 in RFC 5071, but could be extended to do so.
259
260- when U-Boot's pxe fails to boot, it will return control to U-Boot,
261 allowing another command to run, other U-Boot command, instead of resetting
262 the machine like PXELINUX.
263
264- U-Boot's pxe doesn't rely on or provide an UNDI/PXE stack in memory, it
265 only uses U-Boot.
266
267- U-Boot's pxe doesn't provide the full menu implementation that PXELINUX
268 does, only a simple text based menu using the commands described in
269 this README. With PXELINUX, it's possible to have a graphical boot
270 menu, submenus, passwords, etc. U-Boot's pxe could be extended to support
271 a more robust menuing system like that of PXELINUX's.
272
273- U-Boot's pxe expects U-Boot uimg's as kernels. Anything that would work
274 with the 'bootm' command in U-Boot could work with the 'pxe boot' command.
275
276- U-Boot's pxe only recognizes a single file on the initrd command line. It
277 could be extended to support multiple.
278
279- in U-Boot's pxe, the localboot command doesn't necessarily cause a local
280 disk boot - it will do whatever is defined in the 'localcmd' env
281 variable. And since it doesn't support a full UNDI/PXE stack, the
282 type field is ignored.
283
284- the interactive prompt in U-Boot's pxe only allows you to choose a label
285 from the menu. If you want to boot something not listed, you can ctrl+c
286 out of 'pxe boot' and use existing U-Boot commands to accomplish it.
287
README.ramboot-ppc85xx
1 RAMBOOT for MPC85xx Platforms
2 ==============================
3
4RAMBOOT literally means boot from DDR. But since DDR is volatile memory some
5pre-mechanism is required to load the DDR with the bootloader binary.
6- In case of SD and SPI boot this is done by BootROM code inside the chip
7 itself.
8- In case of NAND boot FCM supports loading initial 4K code from NAND flash
9 which can initialize the DDR and get the complete bootloader copied to DDR.
10
11In addition to the above there could be some more methods to initialize the DDR
12and load it manually.
13Two of them are described below.There is also an explanation as to where these
14methods could be handy.
151. Load the RAM based bootloader onto DDR via JTAG/BDI interface. And then
16 execute the bootloader from DDR.
17 This may be handy in the following cases:
18 - In very early stage of platform bringup where other boot options are not
19 functional because of various reasons.
20 - In case the support to program the flashes on the board is not available.
21
222. Load the RAM based bootloader onto DDR using already existing bootloader on
23 the board.And then execute the bootloader from DDR.
24 Some usecases where this may be used:
25 - While developing some new feature of u-boot, for example USB driver or
26 SPI driver.
27 Suppose the board already has a working bootloader on it. And you would
28 prefer to keep it intact, at the same time want to test your bootloader.
29 In this case you can get your test bootloader binary into DDR via tftp
30 for example. Then execute the test bootloader.
31 - Suppose a platform already has a propreitery bootloader which does not
32 support for example AMP boot. In this case also RAM boot loader can be
33 utilized.
34
35 So basically when the original bootloader is required to be kept intact
36 RAM based bootloader can offer an updated bootloader on the system.
37
38Both the above Bootloaders are slight variants of SDcard or SPI Flash
39bootloader or for that matter even NAND bootloader.
40All of them define CONFIG_SYS_RAMBOOT.
41The main difference among all of them is the way the pre-environment is getting
42configured and who is doing that.
43- In case of SD card and SPI flash bootloader this is done by On Chip BootROM inside the Si itself.
44- In case of NAND boot SPL/TPL code does it with some support from Si itself.
45- In case of the pure RAM based bootloaders we have to do it by JTAG manually or already existing bootloader.
46
47How to use them:
481. Using JTAG
49 Boot up in core hold off mode or stop the core after reset using JTAG
50 interface.
51 Preconfigure DDR/L2SRAM through JTAG interface.
52 - setup DDR controller registers.
53 - setup DDR LAWs
54 - setup DDR TLB
55 Load the RAM based boot loader to the proper location in DDR/L2SRAM.
56 set up IAR (Instruction counter properly)
57 Enable the core to execute.
58
592. Using already existing bootloader.
60 get the rambased boot loader binary into DDR/L2SRAM via tftp.
61 execute the RAM based bootloader.
62 => tftp 11000000 u-boot-ram.bin
63 => go 1107f000
64
65Please note that L2SRAM can also be used instead of DDR if the SOC has
66sufficient size of L2SRAM.
67
68Necessary Code changes Required:
69=====================================
70Please note that below mentioned changes are for 85xx platforms.
71They have been tested on P1020/P2020/P1010 RDB.
72
73The main difference between the above two methods from technical perspective is
74that in 1st case SOC is just out of reset so it is in default configuration.
75(CCSRBAR is at 0xff700000).
76In the 2nd case bootloader has already re-located CCSRBAR to 0xffe00000
77
781. File name-> boards.cfg
79 There can be added specific Make options for RAMBoot. We can keep different
80 options for the two cases mentioned above.
81 for example
82 P1020RDB_JTAG_RAMBOOT and P1020RDB_GO_RAMBOOT.
83
842. platform config file
85 for example include/configs/P1_P2_RDB.h
86
87 #ifdef CONFIG_RAMBOOT
88 #define CONFIG_SDCARD
89 #endif
90
91 This will finally use the CONFIG_SYS_RAMBOOT.
92
933. Change CONFIG_SYS_CCSRBAR_DEFAULT in menuconfig accordingly.
94 In the section of the particular SOC, for example P1020, pseudo code
95
96 #if defined(CONFIG_GO)
97 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xffe00000
98 #else
99 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff700000
100 #endif
101
102For JTAG RAMBOOT this is not required because CCSRBAR is at ff700000.
103
README.rockchip
1# SPDX-License-Identifier: GPL-2.0+
2#
3# Copyright (C) 2015 Google. Inc
4# Written by Simon Glass <sjg@chromium.org>
5
6U-Boot on Rockchip
7==================
8
9A wide range of Rockchip SoCs are supported in mainline U-Boot
10
11Warning
12=======
13This document is being moved to doc/board/rockchip, so information on it
14might be incomplete or outdated.
15
16Prerequisites
17=============
18
19You will need:
20
21 - Firefly RK3288 board or something else with a supported RockChip SoC
22 - Power connection to 5V using the supplied micro-USB power cable
23 - Separate USB serial cable attached to your computer and the Firefly
24 (connect to the micro-USB connector below the logo)
25 - rkflashtool [3]
26 - openssl (sudo apt-get install openssl)
27 - Serial UART connection [4]
28 - Suitable ARM cross compiler, e.g.:
29 sudo apt-get install gcc-4.7-arm-linux-gnueabi
30
31Building
32========
33
341. To build RK3288 board:
35
36 CROSS_COMPILE=arm-linux-gnueabi- make O=firefly firefly-rk3288_defconfig all
37
38 (or you can use another cross compiler if you prefer)
39
402. To build RK3308 board:
41
42 See doc/board/rockchip/rockchip.rst
43
443. To build RK3399 board:
45
46 Option 1: Package the image with Rockchip miniloader:
47
48 - Compile U-Boot
49
50 => cd /path/to/u-boot
51 => make nanopi-neo4-rk3399_defconfig
52 => make
53
54 - Get the rkbin
55
56 => git clone https://github.com/rockchip-linux/rkbin.git
57
58 - Create trust.img
59
60 => cd /path/to/rkbin
61 => ./tools/trust_merger RKTRUST/RK3399TRUST.ini
62
63 - Create uboot.img
64
65 => cd /path/to/rkbin
66 => ./tools/loaderimage --pack --uboot /path/to/u-boot/u-boot-dtb.bin uboot.img
67
68 (Get trust.img and uboot.img)
69
70 Option 2: Package the image with SPL:
71
72 - Export cross compiler path for aarch64
73
74 - Compile ATF
75
76 => git clone https://github.com/ARM-software/arm-trusted-firmware.git
77 => cd arm-trusted-firmware
78
79 (export cross compiler path for Cortex-M0 MCU likely arm-none-eabi-)
80 => make realclean
81 => make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399
82
83 (export bl31.elf)
84 => export BL31=/path/to/arm-trusted-firmware/build/rk3399/release/bl31/bl31.elf
85
86 - Compile PMU M0 firmware
87
88 This is optional for most of the rk3399 boards.
89
90 => git clone git://git.theobroma-systems.com/rk3399-cortex-m0.git
91 => cd rk3399-cortex-m0
92
93 (export cross compiler path for Cortex-M0 PMU)
94 => make CROSS_COMPILE=arm-cortex_m0-eabi-
95
96 (export rk3399m0.bin)
97 => export PMUM0=/path/to/rk3399-cortex-m0/rk3399m0.bin
98
99 - Compile U-Boot
100
101 => cd /path/to/u-boot
102 => make orangepi-rk3399_defconfig
103 => make
104
105 (Get spl/u-boot-spl-dtb.bin, u-boot.itb images and some boards would get
106 spl/u-boot-spl.bin since it doesn't enable CONFIG_SPL_OF_CONTROL
107
108 If TPL enabled on the target, get tpl/u-boot-tpl-dtb.bin or tpl/u-boot-tpl.bin
109 if CONFIG_TPL_OF_CONTROL not enabled)
110
111Writing to the board with USB
112=============================
113
114For USB to work you must get your board into ROM boot mode, either by erasing
115your MMC or (perhaps) holding the recovery button when you boot the board.
116To erase your MMC, you can boot into Linux and type (as root)
117
118 dd if=/dev/zero of=/dev/mmcblk0 bs=1M
119
120Connect your board's OTG port to your computer.
121
122To create a suitable image and write it to the board:
123
124 ./firefly-rk3288/tools/mkimage -n rk3288 -T rkimage -d \
125 ./firefly-rk3288/spl/u-boot-spl-dtb.bin out && \
126 cat out | openssl rc4 -K 7c4e0304550509072d2c7b38170d1711 | rkflashtool l
127
128If all goes well you should something like:
129
130 U-Boot SPL 2015.07-rc1-00383-ge345740-dirty (Jun 03 2015 - 10:06:49)
131 Card did not respond to voltage select!
132 spl: mmc init failed with error: -17
133 ### ERROR ### Please RESET the board ###
134
135You will need to reset the board before each time you try. Yes, that's all
136it does so far. If support for the Rockchip USB protocol or DFU were added
137in SPL then we could in principle load U-Boot and boot to a prompt from USB
138as several other platforms do. However it does not seem to be possible to
139use the existing boot ROM code from SPL.
140
141
142Writing to the eMMC with USB on ROC-RK3308-CC
143=============================================
144For USB to work you must get your board into Bootrom mode,
145either by erasing the eMMC or short circuit the GND and D0
146on core board.
147
148Connect the board to your computer via tyepc.
149=> rkdeveloptool db rk3308_loader_v1.26.117.bin
150=> rkdeveloptool wl 0x40 idbloader.img
151=> rkdeveloptool wl 0x4000 u-boot.itb
152=> rkdeveloptool rd
153
154Then you will see the boot log from Debug UART at baud rate 1500000:
155DDR Version V1.26
156REGFB: 0x00000032, 0x00000032
157In
158589MHz
159DDR3
160 Col=10 Bank=8 Row=14 Size=256MB
161msch:1
162Returning to boot ROM...
163
164U-Boot SPL 2020.01-rc1-00225-g34b681327f (Nov 14 2019 - 10:58:04 +0800)
165Trying to boot from MMC1
166INFO: Preloader serial: 2
167NOTICE: BL31: v1.3(release):30f1405
168NOTICE: BL31: Built : 17:08:28, Sep 23 2019
169INFO: Lastlog: last=0x100000, realtime=0x102000, size=0x2000
170INFO: ARM GICv2 driver initialized
171INFO: Using opteed sec cpu_context!
172INFO: boot cpu mask: 1
173INFO: plat_rockchip_pmu_init: pd status 0xe b
174INFO: BL31: Initializing runtime services
175WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will rK
176ERROR: Error initializing runtime service opteed_fast
177INFO: BL31: Preparing for EL3 exit to normal world
178INFO: Entry point address = 0x600000
179INFO: SPSR = 0x3c9
180
181
182U-Boot 2020.01-rc1-00225-g34b681327f (Nov 14 2019 - 10:58:47 +0800)
183
184Model: Firefly ROC-RK3308-CC board
185DRAM: 254 MiB
186MMC: dwmmc@ff480000: 0, dwmmc@ff490000: 1
187rockchip_dnl_key_pressed read adc key val failed
188Net: No ethernet found.
189Hit any key to stop autoboot: 0
190Card did not respond to voltage select!
191switch to partitions #0, OK
192mmc1(part 0) is current device
193Scanning mmc 1:4...
194Found /extlinux/extlinux.conf
195Retrieving file: /extlinux/extlinux.conf
196151 bytes read in 3 ms (48.8 KiB/s)
1971: kernel-mainline
198Retrieving file: /Image
19914737920 bytes read in 377 ms (37.3 MiB/s)
200append: earlycon=uart8250,mmio32,0xff0c0000 console=ttyS2,1500000n8
201Retrieving file: /rk3308-roc-cc.dtb
20228954 bytes read in 4 ms (6.9 MiB/s)
203Flattened Device Tree blob at 01f00000
204Booting using the fdt blob at 0x1f00000
205## Loading Device Tree to 000000000df3a000, end 000000000df44119 ... OK
206
207Starting kernel ...
208[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd042]
209[ 0.000000] Linux version 5.4.0-rc1-00040-g4dc2d508fa47-dirty (andy@B150) (gcc version 6.3.1 20170404 (Linaro GCC 6.3-209
210[ 0.000000] Machine model: Firefly ROC-RK3308-CC board
211[ 0.000000] earlycon: uart8250 at MMIO32 0x00000000ff0c0000 (options '')
212[ 0.000000] printk: bootconsole [uart8250] enabled
213
214Booting from an SD card
215=======================
216
217To write an image that boots from an SD card (assumed to be /dev/sdc):
218
219 ./firefly-rk3288/tools/mkimage -n rk3288 -T rksd -d \
220 firefly-rk3288/spl/u-boot-spl-dtb.bin out && \
221 sudo dd if=out of=/dev/sdc seek=64 && \
222 sudo dd if=firefly-rk3288/u-boot-dtb.img of=/dev/sdc seek=16384
223
224This puts the Rockchip header and SPL image first and then places the U-Boot
225image at block 16384 (i.e. 8MB from the start of the SD card). This
226corresponds with this setting in U-Boot:
227
228 #define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0x4000
229
230Put this SD (or micro-SD) card into your board and reset it. You should see
231something like:
232
233 U-Boot 2016.01-rc2-00309-ge5bad3b-dirty (Jan 02 2016 - 23:41:59 -0700)
234
235 Model: Radxa Rock 2 Square
236 DRAM: 2 GiB
237 MMC: dwmmc@ff0f0000: 0, dwmmc@ff0c0000: 1
238 *** Warning - bad CRC, using default environment
239
240 In: serial
241 Out: vop@ff940000.vidconsole
242 Err: serial
243 Net: Net Initialization Skipped
244 No ethernet found.
245 Hit any key to stop autoboot: 0
246 =>
247
248The rockchip bootrom can load and boot an initial spl, then continue to
249load a second-stage bootloader (ie. U-Boot) as soon as the control is returned
250to the bootrom. Both the RK3288 and the RK3036 use this special boot sequence.
251The configuration option enabling this is:
252
253 CONFIG_SPL_ROCKCHIP_BACK_TO_BROM=y
254
255You can create the image via the following operations:
256
257 ./firefly-rk3288/tools/mkimage -n rk3288 -T rksd -d \
258 firefly-rk3288/spl/u-boot-spl-dtb.bin out && \
259 cat firefly-rk3288/u-boot-dtb.bin >> out && \
260 sudo dd if=out of=/dev/sdc seek=64
261
262Or:
263 ./firefly-rk3288/tools/mkimage -n rk3288 -T rksd -d \
264 firefly-rk3288/spl/u-boot-spl-dtb.bin:firefly-rk3288/u-boot-dtb.bin \
265 out && \
266 sudo dd if=out of=/dev/sdc seek=64
267
268If you have an HDMI cable attached you should see a video console.
269
270For evb_rk3036 board:
271 ./evb-rk3036/tools/mkimage -n rk3036 -T rksd -d evb-rk3036/spl/u-boot-spl.bin out && \
272 cat evb-rk3036/u-boot-dtb.bin >> out && \
273 sudo dd if=out of=/dev/sdc seek=64
274
275Or:
276 ./evb-rk3036/tools/mkimage -n rk3036 -T rksd -d \
277 evb-rk3036/spl/u-boot-spl.bin:evb-rk3036/u-boot-dtb.bin out && \
278 sudo dd if=out of=/dev/sdc seek=64
279
280Note: rk3036 SDMMC and debug uart use the same iomux, so if you boot from SD, the
281 debug uart must be disabled
282
283
284Booting from an SD card on RK3288 with TPL
285==========================================
286
287Since the size of SPL can't be exceeded 0x8000 bytes in RK3288, it is not possible add
288new SPL features like Falcon mode or etc.
289
290So introduce TPL so-that adding new features to SPL is possible because now TPL should
291run minimal with code like DDR, clock etc and rest of new features in SPL.
292
293As of now TPL is added on Vyasa-RK3288 board.
294
295To write an image that boots from an SD card (assumed to be /dev/mmcblk0):
296
297 sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 &&
298 sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 seek=16384
299
300Booting from an SD card on RK3188
301=================================
302
303For rk3188 boards the general storage onto the card stays the same as
304described above, but the image creation needs a bit more care.
305
306The bootrom of rk3188 expects to find a small 1kb loader which returns
307control to the bootrom, after which it will load the real loader, which
308can then be up to 29kb in size and does the regular ddr init. This is
309handled by a single image (built as the SPL stage) that tests whether
310it is handled for the first or second time via code executed from the
311boot0-hook.
312
313Additionally the rk3188 requires everything the bootrom loads to be
314rc4-encrypted. Except for the very first stage the bootrom always reads
315and decodes 2kb pages, so files should be sized accordingly.
316
317# copy tpl, pad to 1020 bytes and append spl
318tools/mkimage -n rk3188 -T rksd -d spl/u-boot-spl.bin out
319
320# truncate, encode and append u-boot.bin
321truncate -s %2048 u-boot.bin
322cat u-boot.bin | split -b 512 --filter='openssl rc4 -K 7C4E0304550509072D2C7B38170D1711' >> out
323
324Booting from an SD card on Pine64 Rock64 (RK3328)
325=================================================
326
327For Rock64 rk3328 board the following three parts are required:
328TPL, SPL, and the u-boot image tree blob.
329
330 - Write TPL/SPL image at 64 sector
331
332 => sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64
333
334 - Write u-boot image tree blob at 16384 sector
335
336 => sudo dd if=u-boot.itb of=/dev/mmcblk0 seek=16384
337
338Booting from an SD card on RK3399
339=================================
340
341To write an image that boots from an SD card (assumed to be /dev/sdc):
342
343Option 1: Package the image with Rockchip miniloader:
344
345 - Create idbloader.img
346
347 => cd /path/to/u-boot
348 => ./tools/mkimage -n rk3399 -T rksd -d /path/to/rkbin/bin/rk33/rk3399_ddr_800MHz_v1.20.bin idbloader.img
349 => cat /path/to/rkbin/bin/rk33/rk3399_miniloader_v1.19.bin >> idbloader.img
350
351 - Write idbloader.img at 64 sector
352
353 => sudo dd if=idbloader.img of=/dev/sdc seek=64
354
355 - Write trust.img at 24576
356
357 => sudo dd if=trust.img of=/dev/sdc seek=24576
358
359 - Write uboot.img at 16384 sector
360
361 => sudo dd if=uboot.img of=/dev/sdc seek=16384
362 => sync
363
364Put this SD (or micro-SD) card into your board and reset it. You should see
365something like:
366
367DDR Version 1.20 20190314
368In
369Channel 0: DDR3, 933MHz
370Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB
371no stride
372ch 0 ddrconfig = 0x101, ddrsize = 0x20
373pmugrf_os_reg[2] = 0x10006281, stride = 0x17
374OUT
375Boot1: 2019-03-14, version: 1.19
376CPUId = 0x0
377ChipType = 0x10, 239
378mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
379mmc: ERROR: Card did not respond to voltage select!
380emmc reinit
381mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
382mmc: ERROR: Card did not respond to voltage select!
383emmc reinit
384mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
385mmc: ERROR: Card did not respond to voltage select!
386SdmmcInit=2 1
387mmc0:cmd5,20
388SdmmcInit=0 0
389BootCapSize=0
390UserCapSize=60543MB
391FwPartOffset=2000 , 0
392StorageInit ok = 45266
393SecureMode = 0
394SecureInit read PBA: 0x4
395SecureInit read PBA: 0x404
396SecureInit read PBA: 0x804
397SecureInit read PBA: 0xc04
398SecureInit read PBA: 0x1004
399SecureInit read PBA: 0x1404
400SecureInit read PBA: 0x1804
401SecureInit read PBA: 0x1c04
402SecureInit ret = 0, SecureMode = 0
403atags_set_bootdev: ret:(0)
404GPT 0x3380ec0 signature is wrong
405recovery gpt...
406GPT 0x3380ec0 signature is wrong
407recovery gpt fail!
408LoadTrust Addr:0x4000
409No find bl30.bin
410Load uboot, ReadLba = 2000
411hdr 0000000003380880 + 0x0:0x88,0x41,0x3e,0x97,0xe6,0x61,0x54,0x23,0xe9,0x5a,0xd1,0x2b,0xdc,0x2f,0xf9,0x35,
412
413Load OK, addr=0x200000, size=0x9c9c0
414RunBL31 0x10000
415NOTICE: BL31: v1.3(debug):370ab80
416NOTICE: BL31: Built : 09:23:41, Mar 4 2019
417NOTICE: BL31: Rockchip release version: v1.1
418INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
419INFO: Using opteed sec cpu_context!
420INFO: boot cpu mask: 0
421INFO: plat_rockchip_pmu_init(1181): pd status 3e
422INFO: BL31: Initializing runtime services
423INFO: BL31: Initializing BL32
424INF [0x0] TEE-CORE:init_primary_helper:337: Initializing (1.1.0-195-g8f090d20 #6 Fri Dec 7 06:11:20 UTC 2018 aarch64)
425
426INF [0x0] TEE-CORE:init_primary_helper:338: Release version: 1.2
427
428INF [0x0] TEE-CORE:init_teecore:83: teecore inits done
429INFO: BL31: Preparing for EL3 exit to normal world
430INFO: Entry point address = 0x200000
431INFO: SPSR = 0x3c9
432
433
434U-Boot 2019.04-rc4-00136-gfd121f9641-dirty (Apr 16 2019 - 14:02:47 +0530)
435
436Model: FriendlyARM NanoPi NEO4
437DRAM: 1022 MiB
438MMC: dwmmc@fe310000: 2, dwmmc@fe320000: 1, sdhci@fe330000: 0
439Loading Environment from MMC... *** Warning - bad CRC, using default environment
440
441In: serial@ff1a0000
442Out: serial@ff1a0000
443Err: serial@ff1a0000
444Model: FriendlyARM NanoPi NEO4
445Net: eth0: ethernet@fe300000
446Hit any key to stop autoboot: 0
447=>
448
449Option 2: Package the image with SPL:
450
451 - Prefix rk3399 header to SPL image
452
453 => cd /path/to/u-boot
454 => ./tools/mkimage -n rk3399 -T rksd -d spl/u-boot-spl-dtb.bin out
455
456 - Write prefixed SPL at 64th sector
457
458 => sudo dd if=out of=/dev/sdc seek=64
459
460 - Write U-Boot proper at 16384 sector
461
462 => sudo dd if=u-boot.itb of=/dev/sdc seek=16384
463 => sync
464
465Put this SD (or micro-SD) card into your board and reset it. You should see
466something like:
467
468U-Boot SPL board init
469Trying to boot from MMC1
470
471
472U-Boot 2019.01-00004-g14db5ee998 (Mar 11 2019 - 13:18:41 +0530)
473
474Model: Orange Pi RK3399 Board
475DRAM: 2 GiB
476MMC: dwmmc@fe310000: 2, dwmmc@fe320000: 1, sdhci@fe330000: 0
477Loading Environment from MMC... OK
478In: serial@ff1a0000
479Out: serial@ff1a0000
480Err: serial@ff1a0000
481Model: Orange Pi RK3399 Board
482Net: eth0: ethernet@fe300000
483Hit any key to stop autoboot: 0
484=>
485
486Option 3: Package the image with TPL:
487
488 - Write tpl+spl at 64th sector
489
490 => sudo dd if=idbloader.img of=/dev/sdc seek=64
491
492 - Write U-Boot proper at 16384 sector
493
494 => sudo dd if=u-boot.itb of=/dev/sdc seek=16384
495 => sync
496
497Put this SD (or micro-SD) card into your board and reset it. You should see
498something like:
499
500U-Boot TPL board init
501Trying to boot from BOOTROM
502Returning to boot ROM...
503
504U-Boot SPL board init
505Trying to boot from MMC1
506
507
508U-Boot 2019.07-rc1-00241-g5b3244767a (May 08 2019 - 10:51:06 +0530)
509
510Model: Orange Pi RK3399 Board
511DRAM: 2 GiB
512MMC: dwmmc@fe310000: 2, dwmmc@fe320000: 1, sdhci@fe330000: 0
513Loading Environment from MMC... OK
514In: serial@ff1a0000
515Out: serial@ff1a0000
516Err: serial@ff1a0000
517Model: Orange Pi RK3399 Board
518Net: eth0: ethernet@fe300000
519Hit any key to stop autoboot: 0
520=>
521
522Using fastboot on rk3288
523========================
524- Write GPT partition layout to mmc device which fastboot want to use it to
525store the image
526
527 => gpt write mmc 1 $partitions
528
529- Invoke fastboot command to prepare
530
531 => fastboot 1
532
533- Start fastboot request on PC
534
535 fastboot -i 0x2207 flash loader evb-rk3288/spl/u-boot-spl-dtb.bin
536
537You should see something like:
538
539 => fastboot 1
540 WARNING: unknown variable: partition-type:loader
541 Starting download of 357796 bytes
542 ..
543 downloading of 357796 bytes finished
544 Flashing Raw Image
545 ........ wrote 357888 bytes to 'loader'
546
547Booting from SPI
548================
549
550To write an image that boots from SPI flash (e.g. for the Haier Chromebook or
551Bob):
552
553 ./chromebook_jerry/tools/mkimage -n rk3288 -T rkspi \
554 -d chromebook_jerry/spl/u-boot-spl-dtb.bin spl.bin && \
555 dd if=spl.bin of=spl-out.bin bs=128K conv=sync && \
556 cat spl-out.bin chromebook_jerry/u-boot-dtb.img >out.bin && \
557 dd if=out.bin of=out.bin.pad bs=4M conv=sync
558
559This converts the SPL image to the required SPI format by adding the Rockchip
560header and skipping every second 2KB block. Then the U-Boot image is written at
561offset 128KB and the whole image is padded to 4MB which is the SPI flash size.
562The position of U-Boot is controlled with this setting in U-Boot:
563
564 #define CONFIG_SYS_SPI_U_BOOT_OFFS 0x20000
565
566If you have a Dediprog em100pro connected then you can write the image with:
567
568 sudo em100 -s -c GD25LQ32 -d out.bin.pad -r
569
570When booting you should see something like:
571
572 U-Boot SPL 2015.07-rc2-00215-g9a58220-dirty (Jun 23 2015 - 12:11:32)
573
574
575 U-Boot 2015.07-rc2-00215-g9a58220-dirty (Jun 23 2015 - 12:11:32 -0600)
576
577 Model: Google Jerry
578 DRAM: 2 GiB
579 MMC:
580 Using default environment
581
582 In: serial@ff690000
583 Out: serial@ff690000
584 Err: serial@ff690000
585 =>
586
587Future work
588===========
589
590Immediate priorities are:
591
592- USB host
593- USB device
594- Run CPU at full speed (code exists but we only see ~60 DMIPS maximum)
595- NAND flash
596- Boot U-Boot proper over USB OTG (at present only SPL works)
597
598
599Development Notes
600=================
601
602There are plenty of patches in the links below to help with this work.
603
604[1] https://github.com/rkchrome/uboot.git
605[2] https://github.com/linux-rockchip/u-boot-rockchip.git branch u-boot-rk3288
606[3] https://github.com/linux-rockchip/rkflashtool.git
607[4] http://wiki.t-firefly.com/index.php/Firefly-RK3288/Serial_debug/en
608
609rkimage
610-------
611
612rkimage.c produces an SPL image suitable for sending directly to the boot ROM
613over USB OTG. This is a very simple format - just the string RK32 (as 4 bytes)
614followed by u-boot-spl-dtb.bin.
615
616The boot ROM loads image to 0xff704000 which is in the internal SRAM. The SRAM
617starts at 0xff700000 and extends to 0xff718000 where we put the stack.
618
619rksd
620----
621
622rksd.c produces an image consisting of 32KB of empty space, a header and
623u-boot-spl-dtb.bin. The header is defined by 'struct header0_info' although
624most of the fields are unused by U-Boot. We just need to specify the
625signature, a flag and the block offset and size of the SPL image.
626
627The header occupies a single block but we pad it out to 4 blocks. The header
628is encoding using RC4 with the key 7c4e0304550509072d2c7b38170d1711. The SPL
629image can be encoded too but we don't do that.
630
631The maximum size of u-boot-spl-dtb.bin which the boot ROM will read is 32KB,
632or 0x40 blocks. This is a severe and annoying limitation. There may be a way
633around this limitation, since there is plenty of SRAM, but at present the
634board refuses to boot if this limit is exceeded.
635
636The image produced is padded up to a block boundary (512 bytes). It should be
637written to the start of an SD card using dd.
638
639Since this image is set to load U-Boot from the SD card at block offset,
640CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR, dd should be used to write
641u-boot-dtb.img to the SD card at that offset. See above for instructions.
642
643rkspi
644-----
645
646rkspi.c produces an image consisting of a header and u-boot-spl-dtb.bin. The
647resulting image is then spread out so that only the first 2KB of each 4KB
648sector is used. The header is the same as with rksd and the maximum size is
649also 32KB (before spreading). The image should be written to the start of
650SPI flash.
651
652See above for instructions on how to write a SPI image.
653
654rkmux.py
655--------
656
657You can use this script to create #defines for SoC register access. See the
658script for usage.
659
660
661Device tree and driver model
662----------------------------
663
664Where possible driver model is used to provide a structure to the
665functionality. Device tree is used for configuration. However these have an
666overhead and in SPL with a 32KB size limit some shortcuts have been taken.
667In general all Rockchip drivers should use these features, with SPL-specific
668modifications where required.
669
670GPT partition layout
671----------------------------
672
673Rockchip use a unified GPT partition layout in open source support.
674With this GPT partition layout, uboot can be compatilbe with other components,
675like miniloader, trusted-os, arm-trust-firmware.
676
677There are some documents about partitions in the links below.
678http://rockchip.wikidot.com/partitions
679
680--
681Jagan Teki <jagan@amarulasolutions.com>
68227 Mar 2019
683Simon Glass <sjg@chromium.org>
68424 June 2015
685
README.rockusb
1Rockusb (Rockchip USB protocol)
2=====================================================
3
4Overview
5--------
6
7Rockusb protocol is widely used by Rockchip SoC based devices. It can
8read/write info, image to/from devices. This document briefly describes how to
9use Rockusb for upgrading firmware (e.g. kernel, u-boot, rootfs, etc.).
10
11Tools
12--------
13There are many tools can support Rockusb protocol. rkdeveloptool
14(https://github.com/rockchip-linux/rkdeveloptool) is open source,
15It is maintained by Rockchip. People don't want to build from source
16can download from here
17(https://github.com/rockchip-linux/rkbin/blob/master/tools/rkdeveloptool)
18
19Usage
20--------
21The Usage of Rockusb command is:
22
23rockusb <USB_controller> <devtype> <dev[:part]>
24
25e.g. rockusb 0 mmc 0
26
27On your U-Boot console, type this command to enter rockusb mode.
28On your host PC. use lsusb command. you should see a usb device
29using 0x2207 as its USB verdor id.
30
31for more detail about the rkdeveloptool. please read the usage.
32
33rkdeveloptool -h
34
35use rkdeveloptool wl command to write lba. BeginSec is the lba on device
36you want to write.
37
38sudo rkdeveloptool wl <BeginSec> <File>
39
40to flash U-Boot image use below command. U-Boot binary is made by mkimage.
41see doc/README.rockchip for more detail about how to get U-Boot binary.
42
43sudo rkdeveloptool wl 64 <U-Boot binary>
44
45Current set of rkdeveloptool commands supported:
46- rci: Read Chip Info
47- rfi: Read Flash Id
48- rd : Reset Device
49- td : Test Device Ready
50- rl : Read blocks using LBA
51- wl : Write blocks using LBA
52- wlx: Write partition
53
54To do
55-----
56* Fully support Rockusb protocol
57
README.s5p4418
README.s5pc1xx
1
2Summary
3=======
4
5This README is about U-Boot support for SAMSUNG's ARM Cortex-A8 based S5PC1xx
6family of SoCs (S5PC100 [1] and S5PC110).
7
8Currently the following board is supported:
9
10* SMDKC100 [2]
11
12Toolchain
13=========
14
15While ARM Cortex-A8 support ARM v7 instruction set (-march=armv7a) we compile
16with -march=armv5 to allow more compilers to work. For U-Boot code this has
17no performance impact.
18
19Build
20=====
21
22* SMDKC100
23
24make smdkc100_config
25make
26
27
28Interfaces
29==========
30
31cpu
32
33To check SoC:
34
35 if (cpu_is_s5pc100())
36 printf("cpu is s5pc100\n");
37
38 or
39
40 if (cpu_is_s5pc110())
41 printf("cpu is s5pc110\n");
42
43gpio
44
45 struct s5pc100_gpio *gpio = (struct s5pc100_gpio*)S5PC100_GPIO_BASE;
46
47 /* GPA[0] pin set to irq */
48 gpio_cfg_pin(&gpio->gpio_a, 0, GPIO_IRQ);
49
50 /* GPA[0] pin set to input */
51 gpio_direction_input(&gpio->gpio_a, 0);
52
53 /* GPA[0] pin set to output/high */
54 gpio_direction_output(&gpio->gpio_a, 0, 1);
55
56 /* GPA[0] value set to low */
57 gpio_set_value(&gpio->gpio_a, 0, 0);
58
59 /* get GPA[0] value */
60 value = gpio_get_value(&gpio->gpio_a, 0);
61
62Links
63=====
64
65[1] S5PC100:
66
67http://www.samsung.com/global/business/semiconductor/productInfo.do?
68fmly_id=229&partnum=S5PC100
69
70[2] SMDKC100:
71
72http://meritech.co.kr/eng/products/product_view.php?num=28
73
README.sata
11. SATA usage in U-Boot
2
3 There are two ways to operate the hard disk
4
5 * Read/write raw blocks from/to SATA hard disk
6 * ext2load to read a file from ext2 file system
7
81.0 How to read the SATA hard disk's information?
9
10 => sata info
11
12SATA device 0: Model: ST3320620AS Firm: 3.AAD Ser#: 4QF01ZTN
13 Type: Hard Disk
14 Supports 48-bit addressing
15 Capacity: 305245.3 MB = 298.0 GB (625142448 x 512)
16
171.1 How to raw write the kernel, file system, dtb to a SATA hard disk?
18
19 Notes: Hard disk sectors are normally 512 bytes, so
20 0x1000 sectors = 2 MBytes
21
22 write kernel
23 => tftp 40000 /tftpboot/uImage.837x
24 => sata write 40000 0 2000
25
26 write ramdisk
27 => tftp 40000 /tftpboot/ramdisk.837x
28 => sata write 40000 2000 8000
29
30 write dtb
31 => tftp 40000 /tftpboot/mpc837xemds.dtb
32 => sata write 40000 a000 1000
33
341.2 How to raw read the kernel, file system, dtb from a SATA hard disk?
35
36 load kernel
37 => sata read 200000 0 2000
38
39 load ramdisk
40 => sata read 1000000 2000 8000
41
42 load dtb
43 => sata read 2000000 a000 1000
44
45 boot
46 => bootm 200000 1000000 2000000
47
481.3 How to load an image from an ext2 file system in U-Boot?
49
50 U-Boot doesn't support writing to an ext2 file system, so the
51 files must be written by other means (e.g. linux).
52
53 => ext2ls sata 0:1 /
54 <DIR> 4096 .
55 <DIR> 4096 ..
56 <DIR> 16384 lost+found
57 1352023 uImage.837x
58 3646377 ramdisk.837x
59 12288 mpc837xemds.dtb
60 12 hello.txt
61
62 => ext2load sata 0:1 200000 /uImage.837x
63
64 => ext2load sata 0:1 1000000 /ramdisk.837x
65
66 => ext2load sata 0:1 2000000 /mpc837xemds.dtb
67
68 => bootm 200000 1000000 2000000
69
README.sched
1Notes on the scheduler in sched.c:
2~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3
4 'sched.c' provides an very simplistic multi-threading scheduler.
5 See the example, function 'sched(...)', in the same file for its
6 API usage.
7
8 Until an exhaustive testing can be done, the implementation cannot
9 qualify as that of production quality. It works with the example
10 in 'sched.c', it may or may not work in other cases.
11
12
13Limitations:
14~~~~~~~~~~~~
15
16 - There are NO primitives for thread synchronization (locking,
17 notify etc).
18
19 - Only the GPRs and FPRs context is saved during a thread context
20 switch. Other registers on the PowerPC processor (60x, 7xx, 7xxx
21 etc) are NOT saved.
22
23 - The scheduler is NOT transparent to the user. The user
24 applications must invoke thread_yield() to allow other threads to
25 scheduler.
26
27 - There are NO priorities, and the scheduling policy is round-robin
28 based.
29
30 - There are NO capabilities to collect thread CPU usage, scheduler
31 stats, thread status etc.
32
33 - The semantics are somewhat based on those of pthreads, but NOT
34 the same.
35
36 - Only seven threads are allowed. These can be easily increased by
37 changing "#define MAX_THREADS" depending on the available memory.
38
39 - The stack size of each thread is 8KBytes. This can be easily
40 increased depending on the requirement and the available memory,
41 by increasing "#define STK_SIZE".
42
43 - Only one master/parent thread is allowed, and it cannot be
44 stopped or deleted. Any given thread is NOT allowed to stop or
45 delete itself.
46
47 - There NOT enough safety checks as are probably in the other
48 threads implementations.
49
50 - There is no parent-child relationship between threads. Only one
51 thread may thread_join, preferably the master/parent thread.
52
53(C) 2003 Arun Dharankar <ADharankar@ATTBI.Com>
54
README.scrapyard
1Over time, support for more and more boards gets added to U-Boot -
2while other board support code dies a silent death caused by
3negligence in combination with ordinary bitrot. Sometimes this goes
4by unnoticed, but often build errors will result. If nobody cares any
5more to resolve such problems, then the code is really dead and will
6be removed from the U-Boot source tree. The remainders rest in peace
7in the imperishable depths of the git history. Please use the tools
8git provides to read through this history. A common example would be:
9$ git log -p --follow -- board/technexion/twister
10to see the history and changes made to the Technexion "twister" board
11from introduction to removal.
12
README.serial_dt_baud
1Fetch serial baudrate from DT
2-----------------------------
3
4To support fetching of baudrate from DT, the following is done:-
5
6The baudrate configured in Kconfig symbol CONFIG_BAUDRATE is taken by default by serial.
7If change of baudrate is required then the Kconfig symbol CONFIG_BAUDRATE needs to
8changed and U-Boot recompilation is required or the U-Boot environment needs to be updated.
9
10To avoid this, add support to fetch the baudrate directly from the device tree file and
11update the environment.
12
13The default environment stores the default baudrate value. When default baudrate and dtb
14baudrate are not same glitches are seen on the serial.
15So, the environment also needs to be updated with the dtb baudrate to avoid the glitches on
16the serial which is enabled by OF_SERIAL_BAUD.
17
18The Kconfig SPL_ENV_SUPPORT needs to be enabled to allow patching in SPL.
19
20The Kconfig DEFAULT_ENV_IS_RW which is enabled by OF_SERIAL_BAUD with making the environment
21writable.
22
23The ofnode_read_baud() function parses and fetches the baudrate value from the DT. This value
24is validated and updated to baudrate during serial init. Padding is added at the end of the
25default environment and the dt baudrate is updated with the latest value.
26
27Example:-
28
29The serial port options are of the form "bbbbpnf", where "bbbb" is the baud rate, "p" is parity ("n", "o", or "e"),
30"n" is number of bits, and "f" is flow control ("r" for RTS or omit it). Default is "115200n8".
31
32chosen {
33 bootargs = "earlycon console=ttyPS0,115200 clk_ignore_unused root=/dev/ram0 rw init_fatal_sh=1";
34 stdout-path = "serial0:115200n8";
35 };
36
37From the chosen node, stdout-path property is obtained as string.
38
39 stdout-path = "serial0:115200n8";
40
41The string is parsed to get the baudrate 115200. This string is converted to integer and updated to the environment.
42
README.serial_multi
1The support for multiple serial interfaces as implemented is mainly
2intended to allow for modem dial-in / dial-out while still being able
3to use a serial console on a (different) serial port.
4
5MPC8XX Specific
6===============
7At the moment, the ports must be split on a SMC and a SCC port on a
88xx processor; other configurations are not (yet) supported.
9
10Support for hardware handshake has not been implemented yet (but is
11in the works).
12
13*) The default console depends on the keys pressed:
14 - SMC if keys not pressed (modem not enabled)
15 - SCC if keys pressed (modem enabled)
16
17*) The console can be switched to SCC by any of the following commands:
18
19 setenv stdout serial_scc
20 setenv stdin serial_scc
21 setenv stderr serial_scc
22
23*) The console can be switched to SMC by any of the following commands:
24
25 setenv stdout serial_smc
26 setenv stdin serial_smc
27 setenv stderr serial_smc
28
29*) If a file descriptor is set to "serial" then the current serial device
30will be used which, in turn, can be switched by above commands.
31
32*) The baudrate is the same for all serial devices. But it can be switched
33just after switching the console:
34
35 setenv sout serial_scc; setenv baudrate 38400
36
37After that press 'enter' at the SCC console. Note that baudrates <38400
38are not allowed on LWMON with watchdog enabled (see CFG_SYS_BAUDRATE_TABLE in
39include/configs/lwmon.h).
40
41
42PPC4XX Specific
43===============
44*) The default console is UART0
45
46*) The console can be switched to UART1 by any of the following commands:
47 setenv stdout serial1
48 setenv stderr serial1
49 setenv stdin serial1
50
51*) The console can be switched to UART0 by any of the following commands:
52 setenv stdout serial0
53 setenv stderr serial0
54 setenv stdin serial0
55
README.silent
1The config option CONFIG_SILENT_CONSOLE can be used to quiet messages
2on the console. If the option has been enabled, the output can be
3silenced by setting the environment variable "silent".
4
5- CONFIG_SILENT_CONSOLE_UPDATE_ON_SET
6 When the "silent" variable is changed with env set, the change
7 will take effect immediately.
8
9- CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC
10 Some environments are not available until relocation (e.g. NAND)
11 so this will make the value in the flash env take effect at
12 relocation.
13
14The following actions are taken if "silent" is set at boot time:
15
16 - Until the console devices have been initialized, output has to be
17 suppressed by testing for the flag "GD_FLG_SILENT" in "gd->flags".
18
19 - When the console devices have been initialized, "stdout" and
20 "stderr" are set to "nulldev", so subsequent messages are
21 suppressed automatically. Make sure to enable "nulldev" by
22 enabling CONFIG_SYS_DEVICE_NULLDEV in your board defconfig file.
23
24 - When booting a linux kernel, the "bootargs" are fixed up so that
25 the argument "console=" will be in the command line, no matter how
26 it was set in "bootargs" before. If you don't want the linux command
27 line to be affected, define CONFIG_SILENT_U_BOOT_ONLY in your board
28 config file as well, and this part of the feature will be disabled.
29
README.SNTP
1To use SNTP support, add define CONFIG_CMD_SNTP to the
2configuration file of the board.
3
4The "sntp" command gets network time from NTP time server and
5syncronize RTC of the board. This command needs the command line
6parameter of server's IP address or environment variable
7"ntpserverip". The network time is sent as UTC. So if you want to
8set local time to RTC, set the offset in second from UTC to the
9environment variable "time offset".
10
11If the DHCP server provides time server's IP or time offset, you
12don't need to set the above environment variables yourself.
13
14Current limitations of SNTP support:
151. The roundtrip time is ignored.
162. Only the 1st NTP server IP, in the option ntp-servers of DHCP, will
17 be used.
18
README.socfpga
1----------------------------------------
2SOCFPGA Documentation for U-Boot and SPL
3----------------------------------------
4
5This README is about U-Boot and SPL support for Altera's ARM Cortex-A9MPCore
6based SOCFPGA. To know more about the hardware itself, please refer to
7www.altera.com.
8
9---------------------------------------------------------------------
10Cyclone 5 / Arria 5 generating the handoff header files for U-Boot SPL
11---------------------------------------------------------------------
12
13This text is assuming quartus 16.1, but newer versions will probably work just fine too;
14verified with DE1_SOC_Linux_FB demo project (https://github.com/VCTLabs/DE1_SOC_Linux_FB).
15Updated/working projects should build using either process below.
16
17Note: it *should* work from Quartus 14.0.200 onwards, however, the current vendor demo
18projects must have the IP cores updated as shown below.
19
20Rebuilding your Quartus project
21-------------------------------
22
23Choose one of the follwing methods, either command line or GUI.
24
25Using the command line
26~~~~~~~~~~~~~~~~~~~~~~
27
28First run the embedded command shell, using your path to the Quartus install:
29
30 $ /path/to/intelFPGA/16.1/embedded/embedded_command_shell.sh
31
32Then (if necessary) update the IP cores in the project, generate HDL code, and
33build the project:
34
35 $ cd path/to/project/dir
36 $ qsys-generate soc_system.qsys --upgrade-ip-cores
37 $ qsys-generate soc_system.qsys --synthesis=[VERILOG|VHDL]
38 $ quartus_sh --flow compile <project name>
39
40Convert the resulting .sof file (SRAM object file) to .rbf file (Raw bit file):
41
42 $ quartus_cpf -c <project_name>.sof soc_system.rbf
43
44
45Generate BSP handoff files
46~~~~~~~~~~~~~~~~~~~~~~~~~~
47
48You can run the bsp editor GUI below, or run the following command from the
49project directory:
50
51 $ /path/to/bsb/tools/bsp-create-settings --type spl --bsp-dir build \
52 --preloader-settings-dir hps_isw_handoff/soc_system_hps_0/ \
53 --settings build/settings.bsp
54
55You should use the bsp "build" directory above (ie, where the settings.bsp file is)
56in the following u-boot command to update the board headers. Once these headers
57are updated for a given project build, u-boot should be configured for the
58project board (eg, de0-nano-sockit) and then build the normal spl build.
59
60Now you can skip the GUI section.
61
62
63Using the Qsys GUI
64~~~~~~~~~~~~~~~~~~
65
661. Navigate to your project directory
672. Run Quartus II
683. Open Project (Ctrl+J), select <project_name>.qpf
694. Run QSys [Tools->QSys]
70 4.1 In the Open dialog, select '<project_name>.qsys'
71 4.2 In the Open System dialog, wait until completion and press 'Close'
72 4.3 In the Qsys window, click on 'Generate HDL...' in bottom right corner
73 4.3.1 In the 'Generation' window, click 'Generate'
74 4.3.2 In the 'Generate' dialog, wait until completion and click 'Close'
75 4.4 In the QSys window, click 'Finish'
76 4.4.1 In the 'Quartus II' pop up window, click 'OK'
775. Back in Quartus II main window, do the following
78 5.1 Use Processing -> Start -> Start Analysis & Synthesis (Ctrl+K)
79 5.2 Use Processing -> Start Compilation (Ctrl+L)
80
81 ... this may take some time, have patience ...
82
836. Start the embedded command shell as shown in the previous section
84 6.1 Change directory to 'software/spl_bsp'
85 6.2 Prepare BSP by launching the BSP editor from ECS
86 => bsp-editor
87 6.3 In BSP editor
88 6.3.1 Use File -> Open
89 6.3.2 Select 'settings.bsp' file
90 6.3.3 Click Generate
91 6.3.4 Click Exit
92
93
94Post handoff generation
95~~~~~~~~~~~~~~~~~~~~~~~
96
97Now that the handoff files are generated, U-Boot can be used to process
98the handoff files generated by the bsp-editor. For this, please use the
99following script from the u-boot source tree:
100
101 $ ./arch/arm/mach-socfpga/qts-filter.sh \
102 <soc_type> \
103 <input_qts_dir> \
104 <input_bsp_dir> \
105 <output_dir>
106
107Process QTS-generated files into U-Boot compatible ones.
108
109 soc_type - Type of SoC, either 'cyclone5' or 'arria5'.
110 input_qts_dir - Directory with compiled Quartus project
111 and containing the Quartus project file (QPF).
112 input_bsp_dir - Directory with generated bsp containing
113 the settings.bsp file.
114 output_dir - Directory to store the U-Boot compatible
115 headers.
116
117This will generate (or update) the following 4 files:
118
119 iocsr_config.h
120 pinmux_config.h
121 pll_config.h
122 sdram_config.h
123
124These files should be copied into "qts" directory in the board directory
125(see output argument of qts-filter.sh command above).
126
127Here is an example for the DE-0 Nano SoC after the above rebuild process:
128
129 $ ll board/terasic/de0-nano-soc/qts/
130 total 36
131 -rw-r--r-- 1 sarnold sarnold 8826 Mar 21 18:11 iocsr_config.h
132 -rw-r--r-- 1 sarnold sarnold 4398 Mar 21 18:11 pinmux_config.h
133 -rw-r--r-- 1 sarnold sarnold 3190 Mar 21 18:11 pll_config.h
134 -rw-r--r-- 1 sarnold sarnold 9022 Mar 21 18:11 sdram_config.h
135
136Note: file sizes will differ slightly depending on the selected board.
137
138Now your board is ready for full mainline support including U-Boot SPL.
139The Preloader will not be needed any more.
140
141----------------------------------------------------------
142Arria 10 generating the handoff header files for U-Boot SPL
143----------------------------------------------------------
144
145A header file for inclusion in a devicetree for Arria10 can be generated
146by the qts-filter-a10.sh script directly from the hps_isw_handoff/hps.xml
147file generated during the FPGA project compilation. The header contains
148all PLL, clock, pinmux, and bridge configurations required.
149
150Please look at the socfpga_arria10_socdk_sdmmc-u-boot.dtsi for an example
151that includes use of the generated handoff header.
152
153Devicetree header generation
154~~~~~~~~~~~~~~~~~~~~~~~~~~~~
155
156The qts-filter-a10.sh script can process the compile time genetated hps.xml
157to create the appropriate devicetree header.
158
159
160 $ ./arch/arm/mach-socfpga/qts-filter-a10.sh \
161 <hps_xml> \
162 <output_file>
163
164 hps_xml - hps_isw_handoff/hps.xml from Quartus project
165 output_file - Output filename and location for header file
166
167The script generates a single header file names <output_file> that should
168be placed in arch/arm/dts.
169
README.splashprepare
1---------------------------------------------------------------------
2Splash Screen
3---------------------------------------------------------------------
4The splash_screen_prepare() function is a weak function defined in
5common/splash.c. It is called as part of the splash screen display
6sequence. It gives the board an opportunity to prepare the splash
7image data before it is processed and sent to the frame buffer by
8U-Boot. Define your own version to use this feature.
9
10CONFIG_SPLASH_SOURCE
11
12Use the splash_source.c library. This library provides facilities to declare
13board specific splash image locations, routines for loading splash image from
14supported locations, and a way of controlling the selected splash location
15using the "splashsource" environment variable.
16
17splashsource works as follows:
18- If splashsource is set to a supported location name as defined by board code,
19 use that splash location.
20- If splashsource is undefined, use the first splash location as default.
21- If splashsource is set to an unsupported value, do not load a splash screen.
22
23A splash source location can describe either storage with raw data, a storage
24formatted with a file system or a FIT image. In case of a filesystem, the splash
25screen data is loaded as a file. The name of the splash screen file can be
26controlled with the environment variable "splashfile".
27
28To enable loading the splash image from a FIT image, CONFIG_FIT must be
29enabled. The FIT image has to start at the 'offset' field address in the
30selected splash location. The name of splash image within the FIT shall be
31specified by the environment variable "splashfile".
32
33In case the environment variable "splashfile" is not defined the default name
34'splash.bmp' will be used.
35
README.srio-pcie-boot-corenet
1---------------------------------------
2SRIO and PCIE Boot on Corenet Platforms
3---------------------------------------
4
5For some PowerPC processors with SRIO or PCIE interface, boot location can be
6configured to SRIO or PCIE by RCW. The processor booting from SRIO or PCIE can
7do without flash for u-boot image, ucode and ENV. All the images can be fetched
8from another processor's memory space by SRIO or PCIE link connected between
9them.
10
11This document describes the processes based on an example implemented on P4080DS
12platforms and a RCW example with boot from SRIO or PCIE configuration.
13
14Environment of the SRIO or PCIE boot:
15 a) Master and slave can be SOCs in one board or SOCs in separate boards.
16 b) They are connected with SRIO or PCIE links, whether 1x, 2x or 4x, and
17 directly or through switch system.
18 c) Only Master has NorFlash for booting, and all the Master's and Slave's
19 U-Boot images, UCodes will be stored in this flash.
20 d) Slave has its own EEPROM for RCW and PBI.
21 e) Slave's RCW should configure the SerDes for SRIO or PCIE boot port, set
22 the boot location to SRIO or PCIE, and holdoff all the cores.
23
24 ----------- ----------- -----------
25 | | | | | |
26 | | | | | |
27 | NorFlash|<----->| Master |SRIO or PCIE | Slave |<---->[EEPROM]
28 | | | |<===========>| |
29 | | | | | |
30 ----------- ----------- -----------
31
32The example based on P4080DS platform:
33 Two P4080DS platforms can be used to implement the boot from SRIO or PCIE.
34 Their SRIO or PCIE ports 1 will be connected directly and will be used for
35 the boot from SRIO or PCIE.
36
37 1. Slave's RCW example for boot from SRIO port 1 and all cores in holdoff.
38 00000000: aa55 aa55 010e 0100 0c58 0000 0000 0000
39 00000010: 1818 1818 0000 8888 7440 4000 0000 2000
40 00000020: f440 0000 0100 0000 0000 0000 0000 0000
41 00000030: 0000 0000 0083 0000 0000 0000 0000 0000
42 00000040: 0000 0000 0000 0000 0813 8040 063c 778f
43
44 2. Slave's RCW example for boot from PCIE port 1 and all cores in holdoff.
45 00000000: aa55 aa55 010e 0100 0c58 0000 0000 0000
46 00000010: 1818 1818 0000 8888 1440 4000 0000 2000
47 00000020: f040 0000 0100 0000 0020 0000 0000 0000
48 00000030: 0000 0000 0083 0000 0000 0000 0000 0000
49 00000040: 0000 0000 0000 0000 0813 8040 547e ffc9
50
51 3. Sequence in Step by Step.
52 a) Update RCW for slave with boot from SRIO or PCIE port 1 configuration.
53 b) Program slave's U-Boot image, UCode, and ENV parameters into master's
54 NorFlash.
55 c) Set environment variable "bootmaster" to "SRIO1" or "PCIE1" and save
56 environment for master.
57 setenv bootmaster SRIO1
58 or
59 setenv bootmaster PCIE1
60 saveenv
61 d) Restart up master and it will boot up normally from its NorFlash.
62 Then, it will finish necessary configurations for slave's boot from
63 SRIO or PCIE port 1.
64 e) Master will set inbound SRIO or PCIE windows covered slave's U-Boot
65 image stored in master's NorFlash.
66 f) Master will set an inbound SRIO or PCIE window covered slave's UCode
67 and ENV stored in master's NorFlash.
68 g) Master will set outbound SRIO or PCIE windows in order to configure
69 slave's registers for the core's releasing.
70 h) Since all cores of slave in holdoff, slave should be powered on before
71 all the above master's steps, and wait to be released by master. In the
72 startup phase of the slave from SRIO or PCIE, it will finish some
73 necessary configurations.
74 i) Slave will set a specific TLB entry for the boot process.
75 j) Slave will set a LAW entry with the TargetID SRIO or PCIE port 1 for
76 the boot.
77 k) Slave will set a specific TLB entry in order to fetch UCode and ENV
78 from master.
79 l) Slave will set a LAW entry with the TargetID SRIO or PCIE port 1 for
80 UCode and ENV.
81
82How to use this feature:
83 To use this feature, you need to focus those points.
84
85 1. Slave's RCW with SRIO or PCIE boot configurations, and all cores in holdoff
86 configurations.
87 Please refer to the examples given above.
88
89 2. U-Boot image's compilation.
90 For master, U-Boot image should be generated normally.
91
92 For example, master U-Boot image used on P4080DS should be compiled with
93
94 make P4080DS_config.
95
96 For slave, U-Boot image should be generated specifically by
97
98 make xxxx_SRIO_PCIE_BOOT_config.
99
100 For example, slave U-Boot image used on P4080DS should be compiled with
101
102 make P4080DS_SRIO_PCIE_BOOT_config.
103
104 3. Necessary modifications based on a specific environment.
105 For a specific environment, the addresses of the slave's U-Boot image,
106 UCode, ENV stored in master's NorFlash, and any other configurations
107 can be modified in the file:
108 include/configs/corenet_ds.h.
109
110 4. Set and save the environment variable "bootmaster" with "SRIO1", "SRIO2"
111 or "PCIE1", "PCIE2", "PCIE3" for master, and then restart it in order to
112 perform the role as a master for boot from SRIO or PCIE.
113
114NOTE: When the Slave's ENV parameters are stored in Master's NorFlash,
115 it can fetch them through PCIE or SRIO interface. But the ENV
116 parameters can not be modified by "saveenv" or other commands under
117 the Slave's u-boot environment, because the Slave can not erase,
118 write Master's NorFlash by PCIE or SRIO link.
119
README.standalone
1Design Notes on Exporting U-Boot Functions to Standalone Applications:
2======================================================================
3
41. The functions are exported by U-Boot via a jump table. The jump
5 table is allocated and initialized in the jumptable_init() routine
6 (common/exports.c). Other routines may also modify the jump table,
7 however. The jump table can be accessed as the 'jt' field of the
8 'global_data' structure. The struct members for the jump table are
9 defined in the <include/exports.h> header. E.g., to substitute the
10 malloc() and free() functions that will be available to standalone
11 applications, one should do the following:
12
13 DECLARE_GLOBAL_DATA_PTR;
14
15 gd->jt->malloc = my_malloc;
16 gd->jt->free = my_free;
17
18 Note that the pointers to the functions are real function pointers
19 so the compiler can perform type checks on these assignments.
20
212. The pointer to the jump table is passed to the application in a
22 machine-dependent way. PowerPC, ARM, MIPS, Blackfin and Nios II
23 architectures use a dedicated register to hold the pointer to the
24 'global_data' structure: r2 on PowerPC, r9 on ARM, k0 on MIPS,
25 P3 on Blackfin and gp on Nios II. The x86 architecture does not
26 use such a register; instead, the pointer to the 'global_data'
27 structure is passed as 'argv[-1]' pointer.
28
29 The application can access the 'global_data' structure in the same
30 way as U-Boot does:
31
32 DECLARE_GLOBAL_DATA_PTR;
33
34 printf("U-Boot relocation offset: %x\n", gd->reloc_off);
35
363. The application should call the app_startup() function before any
37 call to the exported functions. Also, implementor of the
38 application may want to check the version of the ABI provided by
39 U-Boot. To facilitate this, a get_version() function is exported
40 that returns the ABI version of the running U-Boot. I.e., a
41 typical application startup may look like this:
42
43 int my_app (int argc, char *const argv[])
44 {
45 app_startup (argv);
46 if (get_version () != XF_VERSION)
47 return 1;
48 }
49
504. The default load and start addresses of the applications are as
51 follows:
52
53 Load address Start address
54 x86 0x00040000 0x00040000
55 PowerPC 0x00040000 0x00040004
56 ARM 0x0c100000 0x0c100000
57 MIPS 0x80200000 0x80200000
58 Blackfin 0x00001000 0x00001000
59 Nios II 0x02000000 0x02000000
60 RISC-V 0x00600000 0x00600000
61
62 For example, the "hello world" application may be loaded and
63 executed on a PowerPC board with the following commands:
64
65 => tftp 0x40000 hello_world.bin
66 => go 0x40004
67
685. To export some additional function long foobar(int i,char c), the following steps
69 should be undertaken:
70
71 - Append the following line at the end of the include/_exports.h
72 file:
73
74 EXPORT_FUNC(foobar, long, foobar, int, char)
75
76 Parameters to EXPORT_FUNC:
77 - the first parameter is the function that is exported (default implementation)
78 - the second parameter is the return value type
79 - the third parameter is the name of the member in struct jt_funcs
80 this is also the name that the standalone application will used.
81 the rest of the parameters are the function arguments
82
83 - Add the prototype for this function to the include/exports.h
84 file:
85
86 long foobar(int i, char c);
87
88 Initialization with the default implementation is done in jumptable_init()
89
90 You can override the default implementation using:
91
92 gd->jt->foobar = another_foobar;
93
94 The signature of another_foobar must then match the declaration of foobar.
95
96 - Increase the XF_VERSION value by one in the include/exports.h
97 file
98
99 - If you want to export a function which depends on a CONFIG_XXX
100 use 2 lines like this:
101 #ifdef CONFIG_FOOBAR
102 EXPORT_FUNC(foobar, long, foobar, int, char)
103 #else
104 EXPORT_FUNC(dummy, void, foobar, void)
105 #endif
106
107
1086. The code for exporting the U-Boot functions to applications is
109 mostly machine-independent. The only places written in assembly
110 language are stub functions that perform the jump through the jump
111 table. That said, to port this code to a new architecture, the
112 only thing to be provided is the code in the examples/stubs.c
113 file. If this architecture, however, uses some uncommon method of
114 passing the 'global_data' pointer (like x86 does), one should add
115 the respective code to the app_startup() function in that file.
116
117 Note that these functions may only use call-clobbered registers;
118 those registers that are used to pass the function's arguments,
119 the stack contents and the return address should be left intact.
120
README.t1040-l2switch
1This file contains information for VSC9953, a Vitesse L2 Switch IP
2which is integrated in the T1040/T1020 Freescale SoCs.
3
4About Device:
5=============
6VSC9953 is an 8-port Gigabit Ethernet switch supports the following features:
7 - 8192 MAC addresses
8 - Static Address provisioning
9 - Dynamic learning of MAC addresses and aging
10 - 4096 VLANs
11 - Independent and shared VLAN learning (IVL, SVL)
12 - Policing with storm control and MC/BC protection
13 - IPv4 and IPv6 multicast
14 - Jumbo frames (9.6 KB)
15 - Access Control List
16 - VLAN editing, translation and remarking
17 - RMON counters per port
18
19Switch interfaces:
20 - 8 Gigabit switch ports (ports 0 to 7) are external and are connected to external PHYs
21 - 2 switch ports (ports 8 and 9) of 2.5 G are connected (fixed links)
22 to FMan ports (FM1@DTSEC1 and FM1@DTSEC2)
23
24Commands Overview:
25=============
26Commands supported
27 - enable/disable a port or show its configuration (speed, duplexity, status, etc.)
28 - port statistics
29 - MAC learning
30 - add/remove FDB entries
31 - Port-based VLAN
32 - Private/Shared VLAN learning
33 - VLAN ingress filtering
34 - Port LAG
35
36Commands syntax
37ethsw [port <port_no>] { enable | disable | show } - enable/disable a port; show a port's configuration
38ethsw [port <port_no>] statistics { [help] | [clear] } - show an l2 switch port's statistics
39ethsw [port <port_no>] learning { [help] | show | auto | disable } - enable/disable/show learning configuration on a port
40ethsw [port <port_no>] [vlan <vid>] fdb { [help] | show | flush | { add | del } <mac> } - add/delete a mac entry in FDB; use show to see FDB entries;
41 if [vlan <vid>] is missing, VID 1 will be used
42ethsw [port <port_no>] pvid { [help] | show | <pvid> } - set/show PVID (ingress and egress VLAN tagging) for a port
43ethsw [port <port_no>] vlan { [help] | show | add <vid> | del <vid> } - add a VLAN to a port (VLAN members)
44ethsw [port <port_no>] untagged { [help] | show | all | none | pvid } - set egress tagging mode for a port
45ethsw [port <port_no>] egress tag { [help] | show | pvid | classified } - configure VID source for egress tag.
46 Tag's VID could be the frame's classified VID or the PVID of the port
47ethsw vlan fdb { [help] | show | shared | private } - make VLAN learning shared or private
48ethsw [port <port_no>] ingress filtering { [help] | show | enable | disable } - enable/disable VLAN ingress filtering on port
49ethsw [port <port_no>] aggr { [help] | show | <lag_group_no> } - get/set LAG group for a port
50
51=> ethsw show
52 Port Status Link Speed Duplex
53 0 enabled down 10 half
54 1 enabled down 10 half
55 2 enabled down 10 half
56 3 enabled up 1000 full
57 4 disabled down - half
58 5 disabled down - half
59 6 disabled down - half
60 7 disabled down - half
61 8 enabled up 2500 full
62 9 enabled up 2500 full
63=>
64
README.tee
1=============
2TEE uclass
3=============
4
5This document describes the TEE uclass in U-Boot
6
7A TEE (Trusted Execution Environment) is a trusted OS running in some
8secure environment, for example, TrustZone on ARM CPUs, or a separate
9secure co-processor etc. A TEE driver handles the details needed to
10communicate with the TEE.
11
12This uclass deals with:
13
14- Registration of TEE drivers
15
16- Managing shared memory between U-Boot and the TEE
17
18- Providing a generic API to the TEE
19
20The TEE interface
21=================
22
23include/tee.h defines the generic interface to a TEE.
24
25A client finds the TEE device via tee_find_device(). Other important functions
26when interfacing with a TEE are:
27
28- tee_shm_alloc(), tee_shm_register() and tee_shm_free() to manage shared
29 memory objects often needed when communicating with the TEE.
30
31- tee_get_version() lets the client know which the capabilities of the TEE
32 device.
33
34- tee_open_session() opens a session to a Trusted Application
35
36- tee_invoke_func() invokes a function in a Trusted Application
37
38- tee_close_session() closes a session to a Trusted Application
39
40Much of the communication between clients and the TEE is opaque to the
41driver. The main job for the driver is to receive requests from the
42clients, forward them to the TEE and send back the results.
43
44OP-TEE driver
45=============
46
47The OP-TEE driver handles OP-TEE [1] based TEEs. Currently it is only the ARM
48TrustZone based OP-TEE solution that is supported.
49
50Lowest level of communication with OP-TEE builds on ARM SMC Calling
51Convention (SMCCC) [2], which is the foundation for OP-TEE's SMC interface
52[3] used internally by the driver. Stacked on top of that is OP-TEE Message
53Protocol [4].
54
55OP-TEE SMC interface provides the basic functions required by SMCCC and some
56additional functions specific for OP-TEE. The most interesting functions are:
57
58- OPTEE_SMC_FUNCID_CALLS_UID (part of SMCCC) returns the version information
59 which is then returned by TEE_IOC_VERSION
60
61- OPTEE_SMC_CALL_GET_OS_UUID returns the particular OP-TEE implementation, used
62 to tell, for instance, a TrustZone OP-TEE apart from an OP-TEE running on a
63 separate secure co-processor.
64
65- OPTEE_SMC_CALL_WITH_ARG drives the OP-TEE message protocol
66
67- OPTEE_SMC_GET_SHM_CONFIG lets the driver and OP-TEE agree on which memory
68 range to used for shared memory between Linux and OP-TEE.
69
70The GlobalPlatform TEE Client API [5] is implemented on top of the generic
71TEE API.
72
73Picture of the relationship between the different components in the
74OP-TEE architecture:
75
76 U-Boot Secure world
77 ~~~~~~ ~~~~~~~~~~~~
78 +------------+ +-------------+
79 | Client | | Trusted |
80 | | | Application |
81 +------------+ +-------------+
82 /\ /\
83 || ||
84 \/ \/
85 +------------+ +-------------+
86 | TEE | | TEE Internal|
87 | uclass | | API |
88 +------------+ +-------------+
89 | OP-TEE | | OP-TEE |
90 | driver | | Trusted OS |
91 +------------+-----------+-------------+
92 | OP-TEE MSG |
93 | SMCCC (OPTEE_SMC_CALL_*) |
94 +--------------------------------------+
95
96RPC (Remote Procedure Call) are requests from secure world to the driver.
97An RPC is identified by a special range of SMCCC return values from
98OPTEE_SMC_CALL_WITH_ARG.
99
100References
101==========
102
103[1] https://github.com/OP-TEE/optee_os
104
105[2] http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
106
107[3] drivers/tee/optee/optee_smc.h
108
109[4] drivers/tee/optee/optee_msg.h
110
111[5] http://www.globalplatform.org/specificationsdevice.asp look for
112 "TEE Client API Specification v1.0" and click download.
113
README.TPL
1Generic TPL framework
2=====================
3
4Overview
5--------
6
7TPL---Third Program Loader.
8
9Due to the SPL on some boards(powerpc mpc85xx) has a size limit and cannot
10be compatible with all the external device(e.g. DDR). So add a tertiary
11program loader (TPL) to enable a loader stub loaded by the code from the
12SPL. It loads the final uboot image into DDR, then jump to it to begin
13execution. Now, only the powerpc mpc85xx has this requirement and will
14implemente it.
15
16Keep consistent with SPL, with this framework almost all source files for a
17board can be reused. No code duplication or symlinking is necessary anymore.
18
19How it works
20------------
21
22There has been a directory $(srctree)/spl which contains only a Makefile. The
23Makefile is shared by SPL and TPL.
24
25The object files are built separately for SPL/TPL and placed in the
26directory spl/tpl. The final binaries which are generated are
27u-boot-{spl|tpl}, u-boot-{spl|tpl}.bin and u-boot-{spl|tpl}.map.
28
29During the TPL build a variable named CONFIG_TPL_BUILD is exported in the
30make environment and also appended to CPPFLAGS with -DCONFIG_TPL_BUILD.
31
32The SPL options are shared by SPL and TPL, the board config file should
33determine which SPL options to choose based on whether CONFIG_TPL_BUILD
34is set. Source files can be compiled for TPL with options chosen in the
35board config file.
36
37TPL use a small device tree (u-boot-tpl.dtb), containing only the nodes with
38the pre-relocation properties: 'bootph-all' and 'bootph-pre-sram'
39(see doc/develop/spl.rst for details).
40
41For example:
42
43spl/Makefile:
44LIBS-$(CONFIG_SPL_LIBCOMMON_SUPPORT) += common/libcommon.o
45
46CONFIG_SPL_LIBCOMMON_SUPPORT is defined in board config file:
47#ifdef CONFIG_TPL_BUILD
48#define CONFIG_SPL_LIBCOMMON_SUPPORT
49#endif
50
README.ubi
1-------------------
2UBI usage in U-Boot
3-------------------
4
5UBI support in U-Boot is broken down into five separate commands.
6The first is the ubi command, which has six subcommands:
7
8=> help ubi
9ubi - ubi commands
10
11Usage:
12ubi part [part] [offset]
13 - Show or set current partition (with optional VID header offset)
14ubi info [l[ayout]] - Display volume and ubi layout information
15ubi create[vol] volume [size] [type] - create volume name with size
16ubi write[vol] address volume size - Write volume from address with size
17ubi write.part address volume size [fullsize]
18 - Write part of a volume from address
19ubi read[vol] address volume [size] - Read volume to address with size
20ubi remove[vol] volume - Remove volume
21[Legends]
22 volume: character name
23 size: specified in bytes
24 type: s[tatic] or d[ynamic] (default=dynamic)
25
26
27The first command that is needed to be issues is "ubi part" to connect
28one mtd partition to the UBI subsystem. This command will either create
29a new UBI device on the requested MTD partition. Or it will attach a
30previously created UBI device. The other UBI commands will only work
31when such a UBI device is attached (via "ubi part"). Here an example:
32
33=> mtdparts
34
35device nor0 <1fc000000.nor_flash>, # parts = 6
36 #: name size offset mask_flags
37 0: kernel 0x00200000 0x00000000 0
38 1: dtb 0x00040000 0x00200000 0
39 2: root 0x00200000 0x00240000 0
40 3: user 0x01ac0000 0x00440000 0
41 4: env 0x00080000 0x01f00000 0
42 5: u-boot 0x00080000 0x01f80000 0
43
44active partition: nor0,0 - (kernel) 0x00200000 @ 0x00000000
45
46defaults:
47mtdids : nor0=1fc000000.nor_flash
48mtdparts: mtdparts=1fc000000.nor_flash:2m(kernel),256k(dtb),2m(root),27392k(user),512k(env),512k(u-boot)
49
50=> ubi part root
51Creating 1 MTD partitions on "nor0":
520x000000240000-0x000000440000 : "mtd=2"
53UBI: attaching mtd1 to ubi0
54UBI: physical eraseblock size: 262144 bytes (256 KiB)
55UBI: logical eraseblock size: 262016 bytes
56UBI: smallest flash I/O unit: 1
57UBI: VID header offset: 64 (aligned 64)
58UBI: data offset: 128
59UBI: attached mtd1 to ubi0
60UBI: MTD device name: "mtd=2"
61UBI: MTD device size: 2 MiB
62UBI: number of good PEBs: 8
63UBI: number of bad PEBs: 0
64UBI: max. allowed volumes: 128
65UBI: wear-leveling threshold: 4096
66UBI: number of internal volumes: 1
67UBI: number of user volumes: 1
68UBI: available PEBs: 0
69UBI: total number of reserved PEBs: 8
70UBI: number of PEBs reserved for bad PEB handling: 0
71UBI: max/mean erase counter: 2/1
72
73
74Now that the UBI device is attached, this device can be modified
75using the following commands:
76
77ubi info Display volume and ubi layout information
78ubi createvol Create UBI volume on UBI device
79ubi removevol Remove UBI volume from UBI device
80ubi read Read data from UBI volume to memory
81ubi write Write data from memory to UBI volume
82ubi write.part Write data from memory to UBI volume, in parts
83
84
85Here a few examples on the usage:
86
87=> ubi create testvol
88Creating dynamic volume testvol of size 1048064
89
90=> ubi info l
91UBI: volume information dump:
92UBI: vol_id 0
93UBI: reserved_pebs 4
94UBI: alignment 1
95UBI: data_pad 0
96UBI: vol_type 3
97UBI: name_len 7
98UBI: usable_leb_size 262016
99UBI: used_ebs 4
100UBI: used_bytes 1048064
101UBI: last_eb_bytes 262016
102UBI: corrupted 0
103UBI: upd_marker 0
104UBI: name testvol
105
106UBI: volume information dump:
107UBI: vol_id 2147479551
108UBI: reserved_pebs 2
109UBI: alignment 1
110UBI: data_pad 0
111UBI: vol_type 3
112UBI: name_len 13
113UBI: usable_leb_size 262016
114UBI: used_ebs 2
115UBI: used_bytes 524032
116UBI: last_eb_bytes 2
117UBI: corrupted 0
118UBI: upd_marker 0
119UBI: name layout volume
120
121=> ubi info
122UBI: MTD device name: "mtd=2"
123UBI: MTD device size: 2 MiB
124UBI: physical eraseblock size: 262144 bytes (256 KiB)
125UBI: logical eraseblock size: 262016 bytes
126UBI: number of good PEBs: 8
127UBI: number of bad PEBs: 0
128UBI: smallest flash I/O unit: 1
129UBI: VID header offset: 64 (aligned 64)
130UBI: data offset: 128
131UBI: max. allowed volumes: 128
132UBI: wear-leveling threshold: 4096
133UBI: number of internal volumes: 1
134UBI: number of user volumes: 1
135UBI: available PEBs: 0
136UBI: total number of reserved PEBs: 8
137UBI: number of PEBs reserved for bad PEB handling: 0
138UBI: max/mean erase counter: 4/1
139
140=> ubi write 800000 testvol 80000
141Volume "testvol" found at volume id 0
142
143=> ubi read 900000 testvol 80000
144Volume testvol found at volume id 0
145read 524288 bytes from volume 0 to 900000(buf address)
146
147=> cmp.b 800000 900000 80000
148Total of 524288 bytes were the same
149
150
151Next, the ubifsmount command allows you to access filesystems on the
152UBI partition which has been attached with the ubi part command:
153
154=> help ubifsmount
155ubifsmount - mount UBIFS volume
156
157Usage:
158ubifsmount <volume-name>
159 - mount 'volume-name' volume
160
161For example:
162
163=> ubifsmount ubi0:recovery
164UBIFS: mounted UBI device 0, volume 0, name "recovery"
165UBIFS: mounted read-only
166UBIFS: file system size: 46473216 bytes (45384 KiB, 44 MiB, 366 LEBs)
167UBIFS: journal size: 6348800 bytes (6200 KiB, 6 MiB, 50 LEBs)
168UBIFS: media format: w4/r0 (latest is w4/r0)
169UBIFS: default compressor: LZO
170UBIFS: reserved for root: 0 bytes (0 KiB)
171
172Note that unlike Linux, U-Boot can only have one active UBI partition
173at a time, which can be referred to as ubi0, and must be supplied along
174with the name of the filesystem you are mounting.
175
176
177Once a UBI filesystem has been mounted, the ubifsls command allows you
178to list the contents of a directory in the filesystem:
179
180
181=> help ubifsls
182ubifsls - list files in a directory
183
184Usage:
185ubifsls [directory]
186 - list files in a 'directory' (default '/')
187
188For example:
189
190=> ubifsls
191 17442 Thu Jan 01 02:57:38 1970 imx28-evk.dtb
192 2998146 Thu Jan 01 02:57:43 1970 zImage
193
194
195And the ubifsload command allows you to load a file from a UBI
196filesystem:
197
198
199=> help ubifsload
200ubifsload - load file from an UBIFS filesystem
201
202Usage:
203ubifsload <addr> <filename> [bytes]
204 - load file 'filename' to address 'addr'
205
206For example:
207
208=> ubifsload ${loadaddr} zImage
209Loading file 'zImage' to addr 0x42000000 with size 2998146 (0x002dbf82)...
210Done
211
212
213Finally, you can unmount the UBI filesystem with the ubifsumount
214command:
215
216=> help ubifsumount
217ubifsumount - unmount UBIFS volume
218
219Usage:
220ubifsumount - unmount current volume
221
222For example:
223
224=> ubifsumount
225Unmounting UBIFS volume recovery!
226
227
228Usage of the UBI CRC skip-check flag of static volumes:
229-------------------------------------------------------
230Some users of static UBI volumes implement their own integrity check,
231thus making the volume CRC check done at open time useless. For
232instance, this is the case when one use the ubiblock + dm-verity +
233squashfs combination, where dm-verity already checks integrity of the
234block device but this time at the block granularity instead of verifying
235the whole volume.
236
237Skipping this test drastically improves the boot-time.
238
239U-Boot now supports the "skip_check" flag to optionally skip the CRC
240check at open time.
241
242Usage: Case A - Upon UBI volume creation:
243You can optionally add "--skipcheck" to the "ubi create" command:
244
245ubi create[vol] volume [size] [type] [id] [--skipcheck]
246 - create volume name with size ('-' for maximum available size)
247
248Usage: Case B - With an already existing UBI volume:
249Use the "ubi skipcheck" command:
250
251ubi skipcheck volume on/off - Set or clear skip_check flag in volume header
252
253Example:
254=> ubi skipcheck rootfs0 on
255Setting skip_check on volume rootfs0
256
257BTW: This saves approx. 10 seconds Linux bootup time on a MT7688 based
258target with 128MiB of SPI NAND.
259
README.ubispl
1Lightweight UBI and UBI fastmap support
2
3# Copyright (C) Thomas Gleixner <tglx@linutronix.de>
4#
5# SPDX-License-Identifier: GPL 2.0+ BSD-3-Clause
6
7Scans the UBI information and loads the requested static volumes into
8memory.
9
10Configuration Options:
11
12 CONFIG_SPL_UBI
13 Enables the SPL UBI support
14
15 CONFIG_SPL_UBI_MAX_VOL_LEBS
16 The maximum number of logical eraseblocks which a static volume
17 to load can contain. Used for sizing the scan data structure
18
19 CONFIG_SPL_UBI_MAX_PEB_SIZE
20 The maximum physical erase block size. Either a compile time
21 constant or runtime detection. Used for sizing the scan data
22 structure
23
24 CONFIG_SPL_UBI_MAX_PEBS
25 The maximum physical erase block count. Either a compile time
26 constant or runtime detection. Used for sizing the scan data
27 structure
28
29 CONFIG_SPL_UBI_VOL_IDS
30 The maximum volume ids which can be loaded. Used for sizing the
31 scan data structure.
32
33Usage notes:
34
35In the board config file define for example:
36
37#define CONFIG_SPL_UBI
38#define CONFIG_SPL_UBI_MAX_VOL_LEBS 256
39#define CONFIG_SPL_UBI_MAX_PEB_SIZE (256*1024)
40#define CONFIG_SPL_UBI_MAX_PEBS 4096
41#define CONFIG_SPL_UBI_VOL_IDS 8
42
43The size requirement is roughly as follows:
44
45 2k for the basic data structure
46 + CONFIG_SPL_UBI_VOL_IDS * CONFIG_SPL_UBI_MAX_VOL_LEBS * 8
47 + CONFIG_SPL_UBI_MAX_PEBS * 64
48 + CONFIG_SPL_UBI_MAX_PEB_SIZE * UBI_FM_MAX_BLOCKS
49
50The last one is big, but I really don't care in that stage. Real world
51implementations only use the first couple of blocks, but the code
52handles up to UBI_FM_MAX_BLOCKS.
53
54Given the above configuration example the requirement is about 5M
55which is usually not a problem to reserve in the RAM along with the
56other areas like the kernel/dts load address.
57
58So something like this will do the trick:
59
60#define SPL_FINFO_ADDR 0x80800000
61#define SPL_DTB_LOAD_ADDR 0x81800000
62#define SPL_KERNEL_LOAD_ADDR 0x82000000
63
64In the board file, implement the following:
65
66static struct ubispl_load myvolumes[] = {
67 {
68 .vol_id = 0, /* kernel volume */
69 .load_addr = (void *)SPL_KERNEL_LOAD_ADDR,
70 },
71 {
72 .vol_id = 1, /* DT blob */
73 .load_addr = (void *)SPL_DTB_LOAD_ADDR,
74 }
75};
76
77int spl_start_uboot(void)
78{
79 struct ubispl_info info;
80
81 info.ubi = (struct ubi_scan_info *) SPL_FINFO_ADDR;
82 info.fastmap = 1;
83 info.read = nand_spl_read_flash;
84
85#if COMPILE_TIME_DEFINED
86 /*
87 * MY_NAND_NR_SPL_PEBS is the number of physical erase blocks
88 * in the FLASH which are reserved for the SPL. Think about
89 * mtd partitions:
90 *
91 * part_spl { .start = 0, .end = 4 }
92 * part_ubi { .start = 4, .end = NR_PEBS }
93 */
94 info.peb_offset = MY_NAND_NR_SPL_PEBS;
95 info.peb_size = CONFIG_SYS_NAND_BLOCK_SIZE;
96 info.vid_offset = MY_NAND_UBI_VID_OFFS;
97 info.leb_start = MY_NAND_UBI_DATA_OFFS;
98 info.peb_count = MY_NAND_UBI_NUM_PEBS;
99#else
100 get_flash_info(&flash_info);
101 info.peb_offset = MY_NAND_NR_SPL_PEBS;
102 info.peb_size = flash_info.peb_size;
103
104 /*
105 * The VID and Data offset depend on the capability of the
106 * FLASH chip to do subpage writes.
107 *
108 * If the flash chip supports subpage writes, then the VID
109 * header starts at the second subpage. So for 2k pages size
110 * with 4 subpages the VID offset is 512. The DATA offset is 2k.
111 *
112 * If the flash chip does not support subpage writes then the
113 * VID offset is FLASH_PAGE_SIZE and the DATA offset
114 * 2 * FLASH_PAGE_SIZE
115 */
116 info.vid_offset = flash_info.vid_offset;
117 info.leb_start = flash_info.data_offset;
118
119 /*
120 * The flash reports the total number of erase blocks, so
121 * we need to subtract the number of blocks which are reserved
122 * for the SPL itself and not managed by UBI.
123 */
124 info.peb_count = flash_info.peb_count - MY_NAND_NR_SPL_PEBS;
125#endif
126
127 ret = ubispl_load_volumes(&info, myvolumes, ARRAY_SIZE(myvolumes);
128
129 ....
130
131}
132
133Note: you can load any payload that way. You can even load u-boot from
134UBI, so the only non UBI managed FLASH area is the one which is
135reserved for the SPL itself and read from the SoC ROM.
136
137And you can do fallback scenarios:
138
139 if (ubispl_load_volumes(&info, volumes0, ARRAY_SIZE(volumes0)))
140 if (ubispl_load_volumes(&info, volumes1, ARRAY_SIZE(volumes1)))
141 ubispl_load_volumes(&info, vol_uboot, ARRAY_SIZE(vol_uboot));
142
README.ublimage
1---------------------------------------------
2UBL image Boot Image generation using mkimage
3---------------------------------------------
4
5This document describes how to set up an U-Boot image that can be directly
6booted by a DaVinci processor via NAND boot mode, using an UBL header,
7but without need for UBL.
8
9For more details see section 11.2 "ARM ROM Boot Modes" of
10http://focus.ti.com/lit/ug/sprufg5a/sprufg5a.pdf
11
12Command syntax:
13--------------
14./tools/mkimage -l <u-boot_file>
15 to list the UBL image file details
16
17./tools/mkimage -T ublimage \
18 -n <board specific configuration file> \
19 -d <u-boot binary> <output image file>
20
21For example, for the davinci dm365evm board:
22./tools/mkimage -n ./board/davinci/dm365evm/ublimage.cfg \
23 -T ublimage \
24 -d u-boot-nand.bin u-boot.ubl
25
26You can generate the image directly when you compile u-boot with:
27
28$ make u-boot.ubl
29
30The output image can be flashed into the NAND.
31
32Please check the DaVinci documentation for further details.
33
34Board specific configuration file specifications:
35-------------------------------------------------
361. This file must present in the $(BOARDDIR) and the name should be
37 ublimage.cfg (since this is used in Makefile).
382. This file can have empty lines and lines starting with "#" as first
39 character to put comments.
403. This file can have configuration command lines as mentioned below,
41 any other information in this file is treated as invalid.
42
43Configuration command line syntax:
44---------------------------------
451. Each command line must have two strings, first one command or address
46 and second one data string
472. Following are the valid command strings and associated data strings:-
48 Command string data string
49 -------------- -----------
50 MODE UBL special mode, on of:
51 safe
52 Example:
53 MODE safe
54
55 ENTRY Entry point address for the user
56 bootloader (absolute address) = TEXT_BASE
57 nand_spl loader.
58 Example:
59 ENTRY 0x00000020
60
61 PAGES Number of pages (size of user bootloader
62 in number of pages)
63 Example:
64 PAGES 27
65
66 START_BLOCK Block number where user bootloader is present
67 Example:
68 START_BLOCK 5
69
70 START_PAGE Page number where user bootloader is present
71 (for RBL always 0)
72 Example:
73 START_PAGE 0
74
75------------------------------------------------
76
77Structure of the u-boot.ubl binary:
78
79compile steps:
80
811) nand_spl code compile, with pad_to = (TEXT_BASE +
82 (CONFIG_SYS_NROF_PAGES_NAND_SPL * pagesize))
83 Example: cam_enc_4xx pad_to = 0x20 + (6 * 0x800) = 0x3020 = 12320
84 -> u-boot-spl-16k.bin
85
86 !! TEXT_BASE = 0x20, as the RBL starts at 0x20
87
882) compile u-boot.bin ("normal" u-boot)
89 -> u-boot.bin
90
913) create u-boot-nand.bin = u-boot-spl-16k.bin + u-boot.bin
92
934) create u-boot.ubl, size = 1 page size NAND
94 create UBL header and paste it before u-boot.bin
95
96This steps are done automagically if you do a "make all"
97
98-> You get an u-boot.ubl binary, which you can flash
99 into your NAND.
100
101Structure of this binary (Example for the cam_enc_4xx board with a NAND
102page size = 0x800):
103
104offset : 0x00000 | 0x800 | 0x3800
105content: UBL | nand_spl | u-boot code
106 Header | code |
107
108The NAND layout looks for example like this:
109
110(Example for the cam_enc_4xx board with a NAND page size = 0x800, block
111size = 0x20000 and CONFIG_SYS_NROF_UBL_HEADER 5):
112
113offset : 0x80000 | 0xa0000 | 0xa3000
114content: UBL | nand_spl | u-boot code
115 Header | code |
116 ^ ^
117 ^ 0xa0000 = CONFIG_SYS_NROF_UBL_HEADER * 0x20000
118 ^
119 0x80000 = Block 4 * 0x20000
120
121If the cpu starts in NAND boot mode, it checks the UBL descriptor
122starting with block 1 (page 0). When a valid UBL signature is found,
123the corresponding block number (from 1 to 24) is written to the last 32
124bits of ARM internal memory (0x7ffc-0x8000). This feature is provided
125as a basic debug mechanism. If not found, it continues with block 2
126... last possible block is 24
127
128If a valid UBL descriptor is found, the UBL descriptor is read and
129processed. The descriptor gives the information required for loading
130and control transfer to the nand_spl code. The nand_spl code is then
131read and processed.
132
133Once the user-specified start-up conditions are set, the RBL copies the
134nand_spl into ARM internal RAM, starting at address 0x0000: 0020.
135 ^^^^
136
137The nand_spl code itself now does necessary intializations, and at least,
138copies the u-boot code from NAND into RAM, and jumps to it ...
139
140------------------------------------------------
141Author: Heiko Schocher <hs@denx.de>
142
README.udp
1Udp framework
2
3The udp framework is build on top of network framework and is designed
4to define new protocol or new command based on udp without modifying
5the network framework.
6
7The udp framework define a function udp_loop that take as argument
8a structure udp_ops (defined in include/net/udp.h) :
9
10struct udp_ops {
11 int (*prereq)(void *data);
12 int (*start)(void *data);
13 void *data;
14};
15
16The callback prereq define if all the requirements are
17valid before running the network/udp loop.
18
19The callback start define the first step in the network/udp loop,
20and it may also be used to configure a timemout and udp handler.
21
22The pointer data is used to store private data that
23could be used by both callback.
24
25A simple example to use this framework:
26
27static struct udp_ops udp_ops = {
28 .prereq = wmp_prereq,
29 .start = wmp_start,
30 .data = NULL,
31};
32
33...
34
35err = udp_loop(&udp_ops);
36
README.unaligned-memory-access.txt
1Editors note: This document is _heavily_ cribbed from the Linux Kernel, with
2really only the section about "Alignment vs. Networking" removed.
3
4UNALIGNED MEMORY ACCESSES
5=========================
6
7Linux runs on a wide variety of architectures which have varying behaviour
8when it comes to memory access. This document presents some details about
9unaligned accesses, why you need to write code that doesn't cause them,
10and how to write such code!
11
12
13The definition of an unaligned access
14=====================================
15
16Unaligned memory accesses occur when you try to read N bytes of data starting
17from an address that is not evenly divisible by N (i.e. addr % N != 0).
18For example, reading 4 bytes of data from address 0x10004 is fine, but
19reading 4 bytes of data from address 0x10005 would be an unaligned memory
20access.
21
22The above may seem a little vague, as memory access can happen in different
23ways. The context here is at the machine code level: certain instructions read
24or write a number of bytes to or from memory (e.g. movb, movw, movl in x86
25assembly). As will become clear, it is relatively easy to spot C statements
26which will compile to multiple-byte memory access instructions, namely when
27dealing with types such as u16, u32 and u64.
28
29
30Natural alignment
31=================
32
33The rule mentioned above forms what we refer to as natural alignment:
34When accessing N bytes of memory, the base memory address must be evenly
35divisible by N, i.e. addr % N == 0.
36
37When writing code, assume the target architecture has natural alignment
38requirements.
39
40In reality, only a few architectures require natural alignment on all sizes
41of memory access. However, we must consider ALL supported architectures;
42writing code that satisfies natural alignment requirements is the easiest way
43to achieve full portability.
44
45
46Why unaligned access is bad
47===========================
48
49The effects of performing an unaligned memory access vary from architecture
50to architecture. It would be easy to write a whole document on the differences
51here; a summary of the common scenarios is presented below:
52
53 - Some architectures are able to perform unaligned memory accesses
54 transparently, but there is usually a significant performance cost.
55 - Some architectures raise processor exceptions when unaligned accesses
56 happen. The exception handler is able to correct the unaligned access,
57 at significant cost to performance.
58 - Some architectures raise processor exceptions when unaligned accesses
59 happen, but the exceptions do not contain enough information for the
60 unaligned access to be corrected.
61 - Some architectures are not capable of unaligned memory access, but will
62 silently perform a different memory access to the one that was requested,
63 resulting in a subtle code bug that is hard to detect!
64
65It should be obvious from the above that if your code causes unaligned
66memory accesses to happen, your code will not work correctly on certain
67platforms and will cause performance problems on others.
68
69
70Code that does not cause unaligned access
71=========================================
72
73At first, the concepts above may seem a little hard to relate to actual
74coding practice. After all, you don't have a great deal of control over
75memory addresses of certain variables, etc.
76
77Fortunately things are not too complex, as in most cases, the compiler
78ensures that things will work for you. For example, take the following
79structure:
80
81 struct foo {
82 u16 field1;
83 u32 field2;
84 u8 field3;
85 };
86
87Let us assume that an instance of the above structure resides in memory
88starting at address 0x10000. With a basic level of understanding, it would
89not be unreasonable to expect that accessing field2 would cause an unaligned
90access. You'd be expecting field2 to be located at offset 2 bytes into the
91structure, i.e. address 0x10002, but that address is not evenly divisible
92by 4 (remember, we're reading a 4 byte value here).
93
94Fortunately, the compiler understands the alignment constraints, so in the
95above case it would insert 2 bytes of padding in between field1 and field2.
96Therefore, for standard structure types you can always rely on the compiler
97to pad structures so that accesses to fields are suitably aligned (assuming
98you do not cast the field to a type of different length).
99
100Similarly, you can also rely on the compiler to align variables and function
101parameters to a naturally aligned scheme, based on the size of the type of
102the variable.
103
104At this point, it should be clear that accessing a single byte (u8 or char)
105will never cause an unaligned access, because all memory addresses are evenly
106divisible by one.
107
108On a related topic, with the above considerations in mind you may observe
109that you could reorder the fields in the structure in order to place fields
110where padding would otherwise be inserted, and hence reduce the overall
111resident memory size of structure instances. The optimal layout of the
112above example is:
113
114 struct foo {
115 u32 field2;
116 u16 field1;
117 u8 field3;
118 };
119
120For a natural alignment scheme, the compiler would only have to add a single
121byte of padding at the end of the structure. This padding is added in order
122to satisfy alignment constraints for arrays of these structures.
123
124Another point worth mentioning is the use of __attribute__((packed)) on a
125structure type. This GCC-specific attribute tells the compiler never to
126insert any padding within structures, useful when you want to use a C struct
127to represent some data that comes in a fixed arrangement 'off the wire'.
128
129You might be inclined to believe that usage of this attribute can easily
130lead to unaligned accesses when accessing fields that do not satisfy
131architectural alignment requirements. However, again, the compiler is aware
132of the alignment constraints and will generate extra instructions to perform
133the memory access in a way that does not cause unaligned access. Of course,
134the extra instructions obviously cause a loss in performance compared to the
135non-packed case, so the packed attribute should only be used when avoiding
136structure padding is of importance.
137
138
139Code that causes unaligned access
140=================================
141
142With the above in mind, let's move onto a real life example of a function
143that can cause an unaligned memory access. The following function taken
144from the Linux Kernel's include/linux/etherdevice.h is an optimized routine
145to compare two ethernet MAC addresses for equality.
146
147bool ether_addr_equal(const u8 *addr1, const u8 *addr2)
148{
149#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
150 u32 fold = ((*(const u32 *)addr1) ^ (*(const u32 *)addr2)) |
151 ((*(const u16 *)(addr1 + 4)) ^ (*(const u16 *)(addr2 + 4)));
152
153 return fold == 0;
154#else
155 const u16 *a = (const u16 *)addr1;
156 const u16 *b = (const u16 *)addr2;
157 return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) == 0;
158#endif
159}
160
161In the above function, when the hardware has efficient unaligned access
162capability, there is no issue with this code. But when the hardware isn't
163able to access memory on arbitrary boundaries, the reference to a[0] causes
1642 bytes (16 bits) to be read from memory starting at address addr1.
165
166Think about what would happen if addr1 was an odd address such as 0x10003.
167(Hint: it'd be an unaligned access.)
168
169Despite the potential unaligned access problems with the above function, it
170is included in the kernel anyway but is understood to only work normally on
17116-bit-aligned addresses. It is up to the caller to ensure this alignment or
172not use this function at all. This alignment-unsafe function is still useful
173as it is a decent optimization for the cases when you can ensure alignment,
174which is true almost all of the time in ethernet networking context.
175
176
177Here is another example of some code that could cause unaligned accesses:
178 void myfunc(u8 *data, u32 value)
179 {
180 [...]
181 *((u32 *) data) = cpu_to_le32(value);
182 [...]
183 }
184
185This code will cause unaligned accesses every time the data parameter points
186to an address that is not evenly divisible by 4.
187
188In summary, the 2 main scenarios where you may run into unaligned access
189problems involve:
190 1. Casting variables to types of different lengths
191 2. Pointer arithmetic followed by access to at least 2 bytes of data
192
193
194Avoiding unaligned accesses
195===========================
196
197The easiest way to avoid unaligned access is to use the get_unaligned() and
198put_unaligned() macros provided by the <asm/unaligned.h> header file.
199
200Going back to an earlier example of code that potentially causes unaligned
201access:
202
203 void myfunc(u8 *data, u32 value)
204 {
205 [...]
206 *((u32 *) data) = cpu_to_le32(value);
207 [...]
208 }
209
210To avoid the unaligned memory access, you would rewrite it as follows:
211
212 void myfunc(u8 *data, u32 value)
213 {
214 [...]
215 value = cpu_to_le32(value);
216 put_unaligned(value, (u32 *) data);
217 [...]
218 }
219
220The get_unaligned() macro works similarly. Assuming 'data' is a pointer to
221memory and you wish to avoid unaligned access, its usage is as follows:
222
223 u32 value = get_unaligned((u32 *) data);
224
225These macros work for memory accesses of any length (not just 32 bits as
226in the examples above). Be aware that when compared to standard access of
227aligned memory, using these macros to access unaligned memory can be costly in
228terms of performance.
229
230If use of such macros is not convenient, another option is to use memcpy(),
231where the source or destination (or both) are of type u8* or unsigned char*.
232Due to the byte-wise nature of this operation, unaligned accesses are avoided.
233
234--
235In the Linux Kernel,
236Authors: Daniel Drake <dsd@gentoo.org>,
237 Johannes Berg <johannes@sipsolutions.net>
238With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt,
239Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock, Uli Kunitz,
240Vadim Lobanov
241
README.uniphier
1U-Boot for UniPhier SoC family
2==============================
3
4
5Recommended toolchains
6----------------------
7
8The UniPhier platform is well tested with Linaro toolchains.
9You can download pre-built toolchains from:
10
11 http://www.linaro.org/downloads/
12
13
14Compile the source
15------------------
16
17The source can be configured and built with the following commands:
18
19 $ make <defconfig>
20 $ make CROSS_COMPILE=<toolchain-prefix> DEVICE_TREE=<device-tree>
21
22The recommended <toolchain-prefix> is `arm-linux-gnueabihf-` for 32bit SoCs,
23`aarch64-linux-gnu-` for 64bit SoCs, but you may wish to change it to use your
24favorite compiler.
25
26The following tables show <defconfig> and <device-tree> for each board.
27
2832bit SoC boards:
29
30 Board | <defconfig> | <device-tree>
31---------------|-----------------------------|------------------------------
32LD4 reference | uniphier_ld4_sld8_defconfig | uniphier-ld4-ref (default)
33sld8 reference | uniphier_ld4_sld8_defconfig | uniphier-sld8-def
34Pro4 reference | uniphier_v7_defconfig | uniphier-pro4-ref
35Pro4 Ace | uniphier_v7_defconfig | uniphier-pro4-ace
36Pro4 Sanji | uniphier_v7_defconfig | uniphier-pro4-sanji
37Pro5 4KBOX | uniphier_v7_defconfig | uniphier-pro5-4kbox
38PXs2 Gentil | uniphier_v7_defconfig | uniphier-pxs2-gentil
39PXs2 Vodka | uniphier_v7_defconfig | uniphier-pxs2-vodka (default)
40LD6b reference | uniphier_v7_defconfig | uniphier-ld6b-ref
41
4264bit SoC boards:
43
44 Board | <defconfig> | <device-tree>
45---------------|-----------------------|----------------------------
46LD11 reference | uniphier_v8_defconfig | uniphier-ld11-ref
47LD11 Global | uniphier_v8_defconfig | uniphier-ld11-global
48LD20 reference | uniphier_v8_defconfig | uniphier-ld20-ref (default)
49LD20 Global | uniphier_v8_defconfig | uniphier-ld20-global
50PXs3 reference | uniphier_v8_defconfig | uniphier-pxs3-ref
51
52For example, to compile the source for PXs2 Vodka board, run the following:
53
54 $ make uniphier_v7_defconfig
55 $ make CROSS_COMPILE=arm-linux-gnueabihf- DEVICE_TREE=uniphier-pxs2-vodka
56
57The device tree marked as (default) can be omitted. `uniphier-pxs2-vodka` is
58the default device tree for the configuration `uniphier_v7_defconfig`, so the
59following gives the same result.
60
61 $ make uniphier_v7_defconfig
62 $ make CROSS_COMPILE=arm-linux-gnueabihf-
63
64
65Booting 32bit SoC boards
66------------------------
67
68The build command will generate the following:
69- u-boot.bin
70- spl/u-boot.bin
71
72U-Boot can boot UniPhier 32bit SoC boards by itself. Flash the generated images
73to the storage device (NAND or eMMC) on your board.
74
75 - spl/u-boot-spl.bin at the offset address 0x00000000
76 - u-boot.bin at the offset address 0x00020000
77
78The `u-boot-with-spl.bin` is the concatenation of the two (with appropriate
79padding), so you can also do:
80
81 - u-boot-with-spl.bin at the offset address 0x00000000
82
83If a TFTP server is available, the images can be easily updated.
84Just copy the u-boot-spl.bin and u-boot.bin to the TFTP public directory,
85and run the following command at the U-Boot command line:
86
87To update the images in NAND:
88
89 => run nandupdate
90
91To update the images in eMMC:
92
93 => run emmcupdate
94
95
96Booting 64bit SoC boards
97------------------------
98
99The build command will generate the following:
100- u-boot.bin
101
102However, U-Boot is not the first stage loader for UniPhier 64bit SoC boards.
103U-Boot serves as a non-secure boot loader loaded by [ARM Trusted Firmware],
104so you need to provide the `u-boot.bin` to the build command of ARM Trusted
105Firmware.
106
107[ARM Trusted Firmware]: https://github.com/ARM-software/arm-trusted-firmware
108
109
110Verified Boot
111-------------
112
113U-Boot supports an image verification method called "Verified Boot".
114This is a brief tutorial to utilize this feature for the UniPhier platform.
115You will find details documents in the doc/uImage.FIT directory.
116
117Here, we take LD20 reference board for example, but it should work for any
118other boards including 32 bit SoCs.
119
1201. Generate key to sign with
121
122 $ mkdir keys
123 $ openssl genpkey -algorithm RSA -out keys/dev.key \
124 -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537
125 $ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
126
127Two files "dev.key" and "dev.crt" will be created. The base name is arbitrary,
128but need to match to the "key-name-hint" property described below.
129
1302. Describe FIT source
131
132You need to write an FIT (Flattened Image Tree) source file to describe the
133structure of the image container.
134
135The following is an example for a simple usecase:
136
137---------------------------------------->8----------------------------------------
138/dts-v1/;
139
140/ {
141 description = "Kernel, DTB and Ramdisk for UniPhier LD20 Reference Board";
142 #address-cells = <1>;
143
144 images {
145 kernel {
146 description = "linux";
147 data = /incbin/("PATH/TO/YOUR/LINUX/DIR/arch/arm64/boot/Image.gz");
148 type = "kernel";
149 arch = "arm64";
150 os = "linux";
151 compression = "gzip";
152 load = <0x82080000>;
153 entry = <0x82080000>;
154 hash-1 {
155 algo = "sha256";
156 };
157 };
158
159 fdt-1 {
160 description = "fdt";
161 data = /incbin/("PATH/TO/YOUR/LINUX/DIR/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dtb");
162 type = "flat_dt";
163 arch = "arm64";
164 compression = "none";
165 hash-1 {
166 algo = "sha256";
167 };
168 };
169
170 ramdisk {
171 description = "ramdisk";
172 data = /incbin/("PATH/TO/YOUR/ROOTFS/DIR/rootfs.cpio");
173 type = "ramdisk";
174 arch = "arm64";
175 os = "linux";
176 compression = "none";
177 hash-1 {
178 algo = "sha256";
179 };
180 };
181 };
182
183 configurations {
184 default = "config-1";
185
186 config-1 {
187 description = "Configuration0";
188 kernel = "kernel";
189 fdt = "fdt-1";
190 ramdisk = "ramdisk";
191 signature-1 {
192 algo = "sha256,rsa2048";
193 key-name-hint = "dev";
194 sign-images = "kernel", "fdt", "ramdisk";
195 };
196 };
197 };
198};
199---------------------------------------->8----------------------------------------
200
201You need to change the three '/incbin/' lines, depending on the location of
202your kernel image, device tree blob, and init ramdisk. The "load" and "entry"
203properties also need to be adjusted if you want to change the physical placement
204of the kernel.
205
206The "key-name-hint" must specify the key name you have created in the step 1.
207
208The FIT file name is arbitrary. Let's say you saved it into "fit.its".
209
2103. Compile U-Boot with FIT and signature enabled
211
212To use the Verified Boot, you need to enable the following two options:
213 CONFIG_FIT
214 CONFIG_FIT_SIGNATURE
215
216They are disabled by default for UniPhier defconfig files. So, you need to
217tweak the configuration from "make menuconfig" or friends.
218
219 $ make uniphier_v8_defconfig
220 $ make menuconfig
221 [ enable CONFIG_FIT and CONFIG_FIT_SIGNATURE ]
222 $ make CROSS_COMPILE=aarch64-linux-gnu-
223
2244. Build the image tree blob
225
226After building U-Boot, you will see tools/mkimage. With this tool, you can
227create an image tree blob as follows:
228
229 $ tools/mkimage -f fit.its -k keys -K dts/dt.dtb -r -F fitImage
230
231The -k option must specify the key directory you have created in step 1.
232
233A file "fitImage" will be created. This includes kernel, DTB, Init-ramdisk,
234hash data for each of the three, and signature data.
235
236The public key needed for the run-time verification is stored in "dts/dt.dtb".
237
2385. Compile U-Boot again
239
240Since the "dt.dtb" has been updated in step 4, you need to re-compile the
241U-Boot.
242
243 $ make CROSS_COMPILE=aarch64-linux-gnu-
244
245The re-compiled "u-boot.bin" is appended with DTB that contains the public key.
246
2476. Flash the image
248
249Flash the "fitImage" to a storage device (NAND, eMMC, or whatever) on your
250board.
251
252Please note the "u-boot.bin" must be signed, and verified by someone when it is
253loaded. For ARMv8 SoCs, the "someone" is generally ARM Trusted Firmware BL2.
254ARM Trusted Firmware supports an image authentication mechanism called Trusted
255Board Boot (TBB). The verification process must be chained from the moment of
256the system reset. If the Chain of Trust has a breakage somewhere, the verified
257boot process is entirely pointless.
258
2597. Boot verified kernel
260
261Load the fitImage to memory and run the following from the U-Boot command line.
262
263 > bootm <addr>
264
265Here, <addr> is the base address of the fitImage.
266
267If it is successful, you will see messages like follows:
268
269---------------------------------------->8----------------------------------------
270## Loading kernel from FIT Image at 84100000 ...
271 Using 'config-1' configuration
272 Verifying Hash Integrity ... sha256,rsa2048:dev+ OK
273 Trying 'kernel' kernel subimage
274 Description: linux
275 Created: 2017-10-20 14:32:29 UTC
276 Type: Kernel Image
277 Compression: gzip compressed
278 Data Start: 0x841000c8
279 Data Size: 6957818 Bytes = 6.6 MiB
280 Architecture: AArch64
281 OS: Linux
282 Load Address: 0x82080000
283 Entry Point: 0x82080000
284 Hash algo: sha256
285 Hash value: 82a37b7f11ae55f4e07aa25bf77e4067cb9dc1014d52d6cd4d588f92eee3aaad
286 Verifying Hash Integrity ... sha256+ OK
287## Loading ramdisk from FIT Image at 84100000 ...
288 Using 'config-1' configuration
289 Trying 'ramdisk' ramdisk subimage
290 Description: ramdisk
291 Created: 2017-10-20 14:32:29 UTC
292 Type: RAMDisk Image
293 Compression: uncompressed
294 Data Start: 0x847a5cc0
295 Data Size: 5264365 Bytes = 5 MiB
296 Architecture: AArch64
297 OS: Linux
298 Load Address: unavailable
299 Entry Point: unavailable
300 Hash algo: sha256
301 Hash value: 44980a2874154a2e31ed59222c9f8ea968867637f35c81e4107a984de7014deb
302 Verifying Hash Integrity ... sha256+ OK
303## Loading fdt from FIT Image at 84100000 ...
304 Using 'config-1' configuration
305 Trying 'fdt-1' fdt subimage
306 Description: fdt
307 Created: 2017-10-20 14:32:29 UTC
308 Type: Flat Device Tree
309 Compression: uncompressed
310 Data Start: 0x847a2cb0
311 Data Size: 12111 Bytes = 11.8 KiB
312 Architecture: AArch64
313 Hash algo: sha256
314 Hash value: c517099db537f6d325e6be46b25c871a41331ad5af0283883fd29d40bfc14e1d
315 Verifying Hash Integrity ... sha256+ OK
316 Booting using the fdt blob at 0x847a2cb0
317 Uncompressing Kernel Image ... OK
318 reserving fdt memory region: addr=80000000 size=2000000
319 Loading Device Tree to 000000009fffa000, end 000000009fffff4e ... OK
320
321Starting kernel ...
322---------------------------------------->8----------------------------------------
323
324Please pay attention to the lines that start with "Verifying Hash Integrity".
325
326"Verifying Hash Integrity ... sha256,rsa2048:dev+ OK" means the signature check
327passed.
328
329"Verifying Hash Integrity ... sha256+ OK" (3 times) means the hash check passed
330for kernel, DTB, and Init ramdisk.
331
332If they are not displayed, the Verified Boot is not working.
333
334
335Deployment for Distro Boot
336--------------------------
337
338UniPhier SoC family boot the kernel in a generic manner as described in
339doc/develop/distro.rst.
340
341To boot the kernel, you need to deploy necesssary components to a file
342system on one of your block devices (eMMC, NAND, USB drive, etc.).
343
344The components depend on the kernel image format.
345
346[1] Bare images
347
348 - kernel
349 - init ramdisk
350 - device tree blob
351 - boot configuration file (extlinux.conf)
352
353Here is an exmple of the configuration file.
354
355-------------------->8--------------------
356menu title UniPhier Boot Options.
357
358timeout 50
359default UniPhier
360
361label UniPhier
362 kernel ../Image
363 initrd ../rootfs.cpio.gz
364 fdtdir ..
365-------------------->8--------------------
366
367Then, write 'Image', 'rootfs.cpio.gz', 'uniphier-ld20-ref.dtb' (DTB depends on
368your board), and 'extlinux/extlinux.conf' to the file system.
369
370[2] FIT
371
372 - FIT blob
373 - boot configuration file (extlinux.conf)
374
375-------------------->8--------------------
376menu title UniPhier Boot Options.
377
378timeout 50
379default UniPhier
380
381label UniPhier
382 kernel ../fitImage
383-------------------->8--------------------
384
385Since the init ramdisk and DTB are contained in the FIT blob,
386you do not need to describe them in the configuration file.
387Write 'fitImage' and 'extlinux/extlinux.conf' to the file system.
388
389
390UniPhier specific commands
391--------------------------
392
393 - pinmon (enabled by CONFIG_CMD_PINMON)
394 shows the boot mode pins that has been latched at the power-on reset
395
396 - ddrphy (enabled by CONFIG_CMD_DDRPHY_DUMP)
397 shows the DDR PHY parameters set by the PHY training
398
399 - ddrmphy (enabled by CONFIG_CMD_DDRMPHY_DUMP)
400 shows the DDR Multi PHY parameters set by the PHY training
401
402
403Supported devices
404-----------------
405
406 - UART (on-chip)
407 - NAND
408 - SD/eMMC
409 - USB 2.0 (EHCI)
410 - USB 3.0 (xHCI)
411 - GPIO
412 - LAN (on-board SMSC9118)
413 - I2C
414 - EEPROM (connected to the on-board I2C bus)
415 - Support card (SRAM, NOR flash, some peripherals)
416
417
418Micro Support Card
419------------------
420
421The recommended bit switch settings are as follows:
422
423 SW2 OFF(1)/ON(0) Description
424 ------------------------------------------
425 bit 1 <---- BKSZ[0]
426 bit 2 ----> BKSZ[1]
427 bit 3 <---- SoC Bus Width 16/32
428 bit 4 <---- SERIAL_SEL[0]
429 bit 5 ----> SERIAL_SEL[1]
430 bit 6 ----> BOOTSWAP_EN
431 bit 7 <---- CS1/CS5
432 bit 8 <---- SOC_SERIAL_DISABLE
433
434 SW8 OFF(1)/ON(0) Description
435 ------------------------------------------
436 bit 1 <---- CS1_SPLIT
437 bit 2 <---- CASE9_ON
438 bit 3 <---- CASE10_ON
439 bit 4 Don't Care Reserve
440 bit 5 Don't Care Reserve
441 bit 6 Don't Care Reserve
442 bit 7 ----> BURST_EN
443 bit 8 ----> FLASHBUS32_16
444
445The BKSZ[1:0] specifies the address range of memory slot and peripherals
446as follows:
447
448 BKSZ Description RAM slot Peripherals
449 --------------------------------------------------------------------
450 0b00 15MB RAM / 1MB Peri 00000000-00efffff 00f00000-00ffffff
451 0b01 31MB RAM / 1MB Peri 00000000-01efffff 01f00000-01ffffff
452 0b10 64MB RAM / 1MB Peri 00000000-03efffff 03f00000-03ffffff
453 0b11 127MB RAM / 1MB Peri 00000000-07efffff 07f00000-07ffffff
454
455Set BSKZ[1:0] to 0b01 for U-Boot.
456This mode is the most handy because EA[24] is always supported by the save pin
457mode of the system bus. On the other hand, EA[25] is not supported for some
458newer SoCs. Even if it is, EA[25] is not connected on most of the boards.
459
460--
461Masahiro Yamada <yamada.masahiro@socionext.com>
462Oct. 2017
463
README.update
1Automatic software update from a TFTP server
2============================================
3
4Overview
5--------
6
7This feature allows to automatically store software updates present on a TFTP
8server in NOR Flash. In more detail: a TFTP transfer of a file given in
9environment variable 'updatefile' from server 'serverip' is attempted during
10boot. The update file should be a FIT file, and can contain one or more
11updates. Each update in the update file has an address in NOR Flash where it
12should be placed, updates are also protected with a SHA-1 checksum. If the
13TFTP transfer is successful, the hash of each update is verified, and if the
14verification is positive, the update is stored in Flash.
15
16The auto-update feature is enabled by the CONFIG_UPDATE_TFTP macro:
17
18#define CONFIG_UPDATE_TFTP 1
19
20
21Note that when enabling auto-update, Flash support must be turned on. Also,
22one must enable FIT and LIBFDT support:
23
24#define CONFIG_FIT 1
25#define CONFIG_OF_LIBFDT 1
26
27The auto-update feature uses the following configuration knobs:
28
29- CONFIG_UPDATE_LOAD_ADDR
30
31 Normally, TFTP transfer of the update file is done to the address specified
32 in environment variable 'loadaddr'. If this variable is not present, the
33 transfer is made to the address given in CONFIG_UPDATE_LOAD_ADDR (0x100000
34 by default).
35
36- CONFIG_UPDATE_TFTP_CNT_MAX
37 CONFIG_UPDATE_TFTP_MSEC_MAX
38
39 These knobs control the timeouts during initial connection to the TFTP
40 server. Since a transfer is attempted during each boot, it is undesirable to
41 have a long delay when a TFTP server is not present.
42 CONFIG_UPDATE_TFTP_MSEC_MAX specifies the number of milliseconds to wait for
43 the server to respond to initial connection, and CONFIG_UPDATE_TFTP_CNT_MAX
44 gives the number of such connection retries. CONFIG_UPDATE_TFTP_CNT_MAX must
45 be non-negative and is 0 by default, CONFIG_UPDATE_TFTP_MSEC_MAX must be
46 positive and is 100 by default.
47
48Since the update file is in FIT format, it is created from an *.its file using
49the mkimage tool. dtc tool with support for binary includes, e.g. in version
501.2.0 or later, must also be available on the system where the update file is
51to be prepared. Refer to the doc/uImage.FIT/ directory for more details on FIT
52images.
53
54
55Example .its files
56------------------
57
58- doc/uImage.FIT/update_uboot.its
59
60 A simple example that can be used to create an update file for automatically
61 replacing U-Boot image on a system.
62
63 Assuming that an U-Boot image u-boot.bin is present in the current working
64 directory, and that the address given in the 'load' property in the
65 'update_uboot.its' file is where the U-Boot is stored in Flash, the
66 following command will create the actual update file 'update_uboot.itb':
67
68 mkimage -f update_uboot.its update_uboot.itb
69
70 Place 'update_uboot.itb' on a TFTP server, for example as
71 '/tftpboot/update_uboot.itb', and set the 'updatefile' variable
72 appropriately, for example in the U-Boot prompt:
73
74 setenv updatefile /tftpboot/update_uboot.itb
75 saveenv
76
77 Now, when the system boots up and the update TFTP server specified in the
78 'serverip' environment variable is accessible, the new U-Boot image will be
79 automatically stored in Flash.
80
81 NOTE: do make sure that the 'u-boot.bin' image used to create the update
82 file is a good, working image. Also make sure that the address in Flash
83 where the update will be placed is correct. Making mistake here and
84 attempting the auto-update can render the system unusable.
85
86- doc/uImage.FIT/update3.its
87
88 An example containing three updates. It can be used to update Linux kernel,
89 ramdisk and FDT blob stored in Flash. The procedure for preparing the update
90 file is similar to the example above.
91
92TFTP update via DFU
93-------------------
94
95- It is now possible to update firmware (bootloader, kernel, rootfs, etc.) via
96 TFTP by using DFU (Device Firmware Upgrade). More information can be found in
97 ./doc/README.dfutftp documentation entry.
98
README.usb
1SPDX-License-Identifier: GPL-2.0+
2/*
3 * (C) Copyright 2001
4 * Denis Peter, MPL AG Switzerland
5 */
6
7USB Support
8===========
9
10The USB support is implemented on the base of the UHCI Host
11controller.
12
13Currently supported are USB Hubs, USB Keyboards, USB Floppys, USB
14flash sticks and USB network adaptors.
15Tested with a TEAC Floppy TEAC FD-05PUB and Chicony KU-8933 Keyboard.
16
17How it works:
18-------------
19
20The USB (at least the USB UHCI) needs a frame list (4k), transfer
21descriptor and queue headers which are all located in the main memory.
22The UHCI allocates every millisecond the PCI bus and reads the current
23frame pointer. This may cause to crash the OS during boot. So the USB
24_MUST_ be stopped during OS boot. This is the reason, why the USB is
25NOT automatically started during start-up. If someone needs the USB
26he has to start it and should therefore be aware that he had to stop
27it before booting the OS.
28
29For USB keyboards this can be done by a script which is automatically
30started after the U-Boot is up and running. To boot an OS with a
31USB keyboard another script is necessary, which first disables the
32USB and then executes the boot command. If the boot command fails,
33the script can re-enable the USB keyboard.
34
35Common USB Commands:
36- usb start:
37- usb reset: (re)starts the USB. All USB devices will be
38 initialized and a device tree is build for them.
39- usb tree: shows all USB devices in a tree like display
40- usb info [dev]: shows all USB infos of the device dev, or of all
41 the devices
42- usb stop [f]: stops the USB. If f==1 the USB will also stop if
43 a USB keyboard is assigned as stdin. The stdin
44 is then switched to serial input.
45Storage USB Commands:
46- usb scan: scans the USB for storage devices. The USB must be
47 running for this command (usb start)
48- usb device [dev]: show or set current USB storage device
49- usb part [dev]: print partition table of one or all USB storage
50 devices
51- usb read addr blk# cnt:
52 read `cnt' blocks starting at block `blk#'to
53 memory address `addr'
54- usbboot addr dev:part:
55 boot from USB device
56
57Config Switches:
58----------------
59CONFIG_CMD_USB enables basic USB support and the usb command
60CONFIG_USB_UHCI defines the lowlevel part. A lowlevel part must be defined
61 if using CONFIG_CMD_USB
62CONFIG_USB_KEYBOARD enables the USB Keyboard
63CONFIG_USB_STORAGE enables the USB storage devices
64CONFIG_USB_HOST_ETHER enables USB ethernet adapter support
65
66
67USB Host Networking
68===================
69
70If you have a supported USB Ethernet adapter you can use it in U-Boot
71to obtain an IP address and load a kernel from a network server.
72
73Note: USB Host Networking is not the same as making your board act as a USB
74client. In that case your board is pretending to be an Ethernet adapter
75and will appear as a network interface to an attached computer. In that
76case the connection is via a USB cable with the computer acting as the host.
77
78With USB Host Networking, your board is the USB host. It controls the
79Ethernet adapter to which it is directly connected and the connection to
80the outside world is your adapter's Ethernet cable. Your board becomes an
81independent network device, able to connect and perform network operations
82independently of your computer.
83
84
85Device support
86--------------
87
88Currently supported devices are listed in the drivers according to
89their vendor and product IDs. You can check your device by connecting it
90to a Linux machine and typing 'lsusb'. The drivers are in
91drivers/usb/eth.
92
93For example this lsusb output line shows a device with Vendor ID 0x0x95
94and product ID 0x7720:
95
96Bus 002 Device 010: ID 0b95:7720 ASIX Electronics Corp. AX88772
97
98If you look at drivers/usb/eth/asix.c you will see this line within the
99supported device list, so we know this adapter is supported.
100
101 { 0x0b95, 0x7720 }, /* Trendnet TU2-ET100 V3.0R */
102
103If your adapter is not listed there is a still a chance that it will
104work. Try looking up the manufacturer of the chip inside your adapter.
105or take the adapter apart and look for chip markings. Then add a line
106for your vendor/product ID into the table of the appropriate driver,
107build U-Boot and see if it works. If not then there might be differences
108between the chip in your adapter and the driver. You could try to get a
109datasheet for your device and add support for it to U-Boot. This is not
110particularly difficult - you only need to provide support for four basic
111functions: init, halt, send and recv.
112
113
114Enabling USB Host Networking
115----------------------------
116
117The normal U-Boot commands are used with USB networking, but you must
118start USB first. For example:
119
120usb start
121setenv bootfile /tftpboot/uImage
122bootp
123
124
125To enable USB Host Ethernet in U-Boot, your platform must of course
126support USB with CONFIG_CMD_USB enabled and working. You will need to
127add some settings to your board configuration:
128
129CONFIG_CMD_USB=y /* the 'usb' interactive command */
130CONFIG_USB_HOST_ETHER=y /* Enable USB Ethernet adapters */
131
132and one or more of the following for individual adapter hardware:
133
134CONFIG_USB_ETHER_ASIX=y
135CONFIG_USB_ETHER_ASIX88179=y
136CONFIG_USB_ETHER_LAN75XX=y
137CONFIG_USB_ETHER_LAN78XX=y
138CONFIG_USB_ETHER_MCS7830=y
139CONFIG_USB_ETHER_RTL8152=y
140CONFIG_USB_ETHER_SMSC95XX=y
141
142As with built-in networking, you will also want to enable some network
143commands, for example:
144
145CONFIG_CMD_NET=y
146CONFIG_CMD_PING=y
147CONFIG_CMD_DHCP=y
148
149and some bootp options, which tell your board to obtain its subnet,
150gateway IP, host name and boot path from the bootp/dhcp server. These
151settings should start you off:
152
153#define CONFIG_BOOTP_SUBNETMASK
154#define CONFIG_BOOTP_GATEWAY
155#define CONFIG_BOOTP_HOSTNAME
156#define CONFIG_BOOTP_BOOTPATH
157
158You can also set the default IP address of your board and the server
159as well as the default file to load when a 'bootp' command is issued.
160However note that encoding these individual network settings into a
161common executable is discouraged, as it leads to potential conflicts,
162and all the parameters can either get stored in the board's external
163environment, or get obtained from the bootp server if not set.
164
165#define CONFIG_IPADDR 10.0.0.2 (replace with your value)
166#define CONFIG_SERVERIP 10.0.0.1 (replace with your value)
167#define CONFIG_BOOTFILE "uImage"
168
169The 'usb start' command should identify the adapter something like this:
170
171CrOS> usb start
172(Re)start USB...
173USB EHCI 1.00
174scanning bus for devices... 3 USB Device(s) found
175 scanning bus for storage devices... 0 Storage Device(s) found
176 scanning bus for ethernet devices... 1 Ethernet Device(s) found
177CrOS> print ethact
178ethact=asx0
179
180You can see that it found an ethernet device and we can print out the
181device name (asx0 in this case).
182
183Then 'bootp' or 'dhcp' should use it to obtain an IP address from DHCP,
184perhaps something like this:
185
186CrOS> bootp
187Waiting for Ethernet connection... done.
188BOOTP broadcast 1
189BOOTP broadcast 2
190DHCP client bound to address 172.22.73.81
191Using asx0 device
192TFTP from server 172.22.72.144; our IP address is 172.22.73.81
193Filename '/tftpboot/uImage-sjg-seaboard-261347'.
194Load address: 0x40c000
195Loading: #################################################################
196 #################################################################
197 #################################################################
198 ################################################
199done
200Bytes transferred = 3557464 (364858 hex)
201CrOS>
202
203
204Another way of doing this is to issue a tftp command, which will cause the
205bootp to happen automatically.
206
207
208MAC Addresses
209-------------
210
211Most Ethernet dongles have a built-in MAC address which is unique in the
212world. This is important so that devices on the network can be
213distinguished from each other. MAC address conflicts are evil and
214generally result in strange and erratic behaviour.
215
216Some boards have USB Ethernet chips on-board, and these sometimes do not
217have an assigned MAC address. In this case it is up to you to assign
218one which is unique. You should obtain a valid MAC address from a range
219assigned to you before you ship the product.
220
221Built-in Ethernet adapters support setting the MAC address by means of
222an ethaddr environment variable for each interface (ethaddr, eth1addr,
223eth2addr). There is similar support on the USB network side, using the
224names usbethaddr, usbeth1addr, etc. They are kept separate since we
225don't want a USB device taking the MAC address of a built-in device or
226vice versa.
227
228So if your USB Ethernet chip doesn't have a MAC address available then
229you must set usbethaddr to a suitable MAC address. At the time of
230writing this functionality is only supported by the SMSC driver.
231
README.vf610
1U-Boot for Freescale Vybrid VF610
2
3This file contains information for the port of U-Boot to the Freescale Vybrid
4VF610 SoC.
5
61. CONVENTIONS FOR FUSE ASSIGNMENTS
7-----------------------------------
8
91.1 MAC Address: It is stored in fuse bank 4, with the 16 msbs in word 2 and the
10 32 lsbs in word 3.
11
README.video
1SPDX-License-Identifier: GPL-2.0+
2/*
3 * (C) Copyright 2000
4 * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arsenio@tin.it
5 */
6
7"video-mode" environment variable
8=================================
9
10The 'video-mode' environment variable can be used to enable and configure
11some video drivers. The format matches the video= command-line option used
12for Linux:
13
14 video-mode=<driver>:<xres>x<yres>-<depth>@<freq><,option=string>
15
16 <driver> The video driver name, ignored by U-Boot
17 <xres> The X resolution (in pixels) to use.
18 <yres> The Y resolution (in pixels) to use.
19 <depth> The color depth (in bits) to use.
20 <freq> The frequency (in Hz) to use.
21 <options> A comma-separated list of device-specific options
22
23
24U-Boot MPC8xx video controller driver
25=====================================
26
27The driver has been tested with the following configurations:
28
29- MPC823FADS with AD7176 on a PAL TV (YCbYCr) - arsenio@tin.it
30
31Example: video-mode=fslfb:1280x1024-32@60,monitor=dvi
32
33
34U-Boot sunxi video controller driver
35====================================
36
37U-Boot supports hdmi and lcd output on Allwinner sunxi SoCs, lcd output
38requires the CONFIG_VIDEO_LCD_MODE Kconfig value to be set.
39
40The sunxi U-Boot driver supports the following video-mode options:
41
42- monitor=[none|dvi|hdmi|lcd|vga|composite-*] - Select the video output to use
43 none: Disable video output.
44 dvi/hdmi: Selects output over the hdmi connector with dvi resp. hdmi output
45 format, if edid is used the format is automatically selected.
46 lcd: Selects video output to a LCD screen.
47 vga: Selects video output over the VGA connector.
48 composite-pal/composite-ntsc/composite-pal-m/composite-pal-nc:
49 Selects composite video output, note the specified resolution is
50 ignored with composite video output.
51 Defaults to monitor=dvi.
52
53- hpd=[0|1] - Enable use of the hdmi HotPlug Detect feature
54 0: Disabled. Configure dvi/hdmi output even if no cable is detected
55 1: Enabled. Fallback to the lcd / vga / none in that order (if available)
56 Defaults to hpd=1.
57
58- hpd_delay=<int> - How long to wait for the hdmi HPD signal in milliseconds
59 When the monitor and the board power up at the same time, it may take some
60 time for the monitor to assert the HPD signal. This configures how long to
61 wait for the HPD signal before assuming no cable is connected.
62 Defaults to hpd_delay=500.
63
64- edid=[0|1] - Enable use of DDC + EDID to get monitor info
65 0: Disabled.
66 1: Enabled. If valid EDID info was read from the monitor the EDID info will
67 overrides the xres, yres and refresh from the video-mode env. variable.
68 Defaults to edid=1.
69
70- overscan_x/overscan_y=<int> - Set x/y overscan value
71 This configures a black border on the left and right resp. top and bottom
72 to deal with overscanning displays. Defaults to overscan_x=32 and
73 overscan_y=20 for composite monitors, 0 for other monitors.
74
75For example to always use the hdmi connector, even if no cable is inserted,
76using edid info when available and otherwise initalizing it at 1024x768@60Hz,
77use: "setenv video-mode sunxi:1024x768-24@60,monitor=dvi,hpd=0,edid=1".
78
79
80TrueType fonts
81--------------
82
83U-Boot supports the use of antialiased TrueType fonts on some platforms. This
84has been tested in x86, ARMv7 and sandbox.
85
86To enable this, select CONFIG_CONSOLE_TRUETYPE. You can choose between several
87fonts, with CONSOLE_TRUETYPE_NIMBUS being the default.
88
89TrueType support requires floating point at present. On ARMv7 platforms you
90need to disable use of the private libgcc. You can do this by disabling
91CONFIG_USE_PRIVATE_LIBGCC. See chromebook_jerry for an example. Note that this
92increases U-Boot's size by about 70KB at present.
93
94On ARM you should also make sure your toolchain supports hardfp. This is
95normally given in the name of your toolchain, e.g. arm-linux-gnueabihf (hf
96means hardware floating point). You can also run gcc with -v to see if it has
97this option.
98
README.VLAN
1U-Boot has networking support for VLANs (802.1q), and CDP (Cisco
2Discovery Protocol).
3
4You control the sending/receiving of VLAN tagged packets with the
5"vlan" environmental variable. When not present no tagging is
6performed.
7
8CDP is used mainly to discover your device VLAN(s) when connected to
9a Cisco switch.
10
11Note: In order to enable CDP support a small change is needed in the
12networking driver. You have to enable reception of the
1301:00:0c:cc:cc:cc MAC address which is a multicast address.
14
15Various defines control CDP; see the README section.
16
README.VSC3316-3308
1This file contains API information of the initialization code written for
2Vitesse cross-point devices, VSC3316 and VSC3308 for board B4860QDS
3
4Author: Shaveta Leekha <shaveta@freescale.com>
5
6About Device:
7=============
8VSC 3316/3308 is a low-power, low-cost asynchronous crosspoint switch capable of data rates upto 11.5Gbps.
9
10VSC3316 has 16 input and 16 output ports whereas VSC3308 has 8 input and 8 output ports. Programming of these devices are performed by two-wire or four-wire serial interface.
11
12Initialization:
13===============
14On reset, VSC devices are in low-power state with all inputs, outputs and connections in an off state.
15First thing required is to program it to interface with either two-wire or four-wire interface.
16In our case the interface is two-wire I2C serial interface. So the value in Interface mode register at address 79.h to be written is 0x02 for two-wire interface. Also for crosspoint connections to be activated, 01.h value need to be written in 75.h (core configuration register).
17
18API Overview:
19=============
20
21 vsc_if_enable(u8 vsc_addr):
22 --------------------------
23 This API programs VSC to interface with either two-wire or four-wire interface. In our case the interface is two-wire I2C serial interface. So the value in Interface mode register at address 79.h to be written is 0x02 for two-wire interface.
24 Parameters:
25 vsc_addr - Address of the VSC device on board.
26
27
28 vsc3316_config(u8 vsc_addr, int con_arr[][2], u8 num_con):
29 ---------------------------------------------------------
30 This API configures the VSC3316 device for required connections. Connection through the VSC device requires the inputs and outputs to be properly configured.
31 Connection registers are on page 00. It Configures the selected input and output correctly and join them to make a connection. It also program Input state register, Global input ISE, Global input LOS, Global core control, Output mode register and core control registers etc.
32 vsc3308_config(u8 vsc_addr, int con_arr[][2], u8 num_con) does the essential configurations for VSC3308.
33
34 Parameters:
35 vsc_addr - Address of the VSC device on board.
36 con_arr - connection array
37 num_con - number of connections to be configured
38
39 vsc_wp_config(u8 vsc_addr):
40 --------------------------
41 For crosspoint connections to be activated, 01.h value need to be written in 75.h (core configuration register), which is done by this API.
42 Parameters:
43 vsc_addr - Address of the VSC device on board.
44
README.watchdog
1Watchdog driver general info
2
3CONFIG_HW_WATCHDOG
4 This enables hw_watchdog_reset to be called during various loops,
5 including waiting for a character on a serial port. But it
6 does not also call hw_watchdog_init. Boards which want this
7 enabled must call this function in their board file. This split
8 is useful because some rom's enable the watchdog when downloading
9 new code, so it must be serviced, but the board would rather it
10 was off. And, it cannot always be turned off once on.
11
12CONFIG_WATCHDOG_TIMEOUT_MSECS
13 Can be used to change the timeout for i.mx31/35/5x/6x.
14 If not given, will default to maximum timeout. This would
15 be 128000 msec for i.mx31/35/5x/6x.
16
17CONFIG_WDT_AT91
18 Available for AT91SAM9 to service the watchdog.
19
20CONFIG_IMX_WATCHDOG
21 Available for i.mx31/35/5x/6x to service the watchdog. This is not
22 automatically set because some boards (vision2) still need to define
23 their own hw_watchdog_reset routine.
24 TODO: vision2 is removed now, so perhaps this can be changed.
25
26CONFIG_XILINX_TB_WATCHDOG
27 Available for Xilinx Axi platforms to service timebase watchdog timer.
28
README.zfs
1This patch series adds support for ZFS listing and load to u-boot.
2
3To Enable zfs ls and load commands, modify the board specific config file with
4#define CONFIG_CMD_ZFS
5
6Steps to test:
7
81. After applying the patch, zfs specific commands can be seen
9 in the boot loader prompt using
10 UBOOT #help
11
12 zfsload- load binary file from a ZFS file system
13 zfsls - list files in a directory (default /)
14
152. To list the files in zfs pool, device or partition, execute
16 zfsls <interface> <dev[:part]> [POOL/@/dir/file]
17 For example:
18 UBOOT #zfsls mmc 0:5 /rpool/@/usr/bin/
19
203. To read and load a file from an ZFS formatted partition to RAM, execute
21 zfsload <interface> <dev[:part]> [addr] [filename] [bytes]
22 For example:
23 UBOOT #zfsload mmc 2:2 0x30007fc0 /rpool/@/boot/uImage
24
25References :
26 -- ZFS GRUB sources from Solaris GRUB-0.97
27 -- GRUB Bazaar repository
28
29Jorgen Lundman <lundman at lundman.net> 2012.
30