1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
|
imx-usb-loader Tools
The Freescale i.MX SoCs support bootstrapping from USB. These are host
side utilities handling this bootstrap process.
The imx-usb-loader tool is used to upload and start i.MX images. These
are images containing a DCD (Device Configuration Data) table. To generate
these images from raw binaries use the imx-image tool.
imx-image
---------
The imx-image tool can be used to generate imximages from raw binaries.
It requires an configuration file describing how to setup the SDRAM on
a particular board. This mainly consists of a poke table. The recognized
options in this file are:
soc <soctype> soctype can be one of imx35, imx51, imx53, imx6
loadaddr <adr> The address the binary is uploaded to
dcdofs <ofs> The offset of the image header in the image. This should be:
0x400 - MMC/SD, NAND, serial ROM, PATA, SATA
0x1000 - NOR Flash
0x100 - OneNAND
wm 8 <adr> <value> do a byte memory write
wm 16 <adr> <value> do a short memory write
wm 32 <adr> <value> do a word memory write
check <width> <cond> <addr> <mask> Poll until condition becomes true.
with <cond> being one of:
while_all_bits_clear,
while_all_bits_set,
while_any_bit_clear,
while_any_bit_set
set_bits <width> <addr> <bits> set <bits> in register <addr>
clear_bits <width> <addr> <bits> clear <bits> in register <addr>
nop do nothing
the i.MX SoCs support a wide range of fancy things doing with the flash header.
We limit ourselves to a very simple case, that is the flash header has a fixed
size of 0x1000 bytes. The application is expected right thereafter, so if you
specify a loadaddr of 0x80000000 in the config file, the first 0x1000 bytes
are occupied by the flash header. The raw image inside the imximage will then
end up at 0x80001000 from where it is then executed.
Example config file, suitable for an Eukra cpuimx35:
soc imx35
dcdofs 0x400
loadaddr 0x80000000
wm 32 0x53F80004 0x00821000
wm 32 0x53F80004 0x00821000
wm 32 0xb8001010 0x00000004
wm 32 0xB8001010 0x0000000C
wm 32 0xb8001004 0x0009572B
wm 32 0xb8001000 0x92220000
wm 8 0x80000400 0xda
wm 32 0xb8001000 0xa2220000
wm 32 0x80000000 0x12344321
wm 32 0x80000000 0x12344321
wm 32 0xb8001000 0xb2220000
wm 8 0x80000033 0xda
wm 8 0x82000000 0xda
wm 32 0xb8001000 0x82224080
wm 32 0xb8001010 0x00000004
example call:
imx-image -c cpuimx35.cfg -f raw.bin -o imximage.bin
imx-usb-loader
--------------
This utility is used to upload an imximage to a board. Some bootloaders directly
generate this file format, with others you can generate such an image with the
imx-image tool. The only required argument is the image file to upload. imx-usb-loader
will then look for a supported device, upload the file and execute it.
example usage:
imx-usb-loader imximage.bin
Some technical notes: The i.MX SoCs USB ROM boot mode supports doing register writes
and file uploads. The files are usually uploaded to SDRAM. For this to work the SDRAM
has to be initialized first. The information necessary to do this is contained in the
imximage itself, more exactly in the DCD table. The imx-usb-loader parses this table
and translates the DCD into register writes, basically it resembles what the i.MX would
do in ROM code when the same image would be loaded from another bootsource like SD/MMC
cards. Still the i.MX needs the DCD table to be uploaded. The i.MX would execute the DCD
data again, which would result in corrupting the just configured SDRAM. The imx-usb-loader
prevents this by setting the DCD length to 0x0 before uploading the image.
The i.MX Boot ROM supports different types of images to upload. The imx-usb-loader currently
only handles the simple case of uploading a single image which is executed right after
downloading.
|
