-
Notifications
You must be signed in to change notification settings - Fork 14
/
README
293 lines (166 loc) · 8.01 KB
/
README
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
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
abootimg - manipulate Android Boot Images.
------------------------------------------
(c) 2010 Gilles Grandou <gilles@grandou.net>
(c) 2015 Daniel Hillenbrand <codeworkx@cyanogenmod.org>
* Android Boot Images
---------------------
It a special partition format defined by the Android Open Source Porject.
See bootimg.h in the source tree for more information about the structure.
It's used by Android Bootloaders to boot the OS.
Boot images mainly convey:
- a kernel image
- a ramdisk image
- optionaly, a 2nd stage bootloader
- the cmdline passed to the kernel when booting.
The official tool used to create boot images is part of the Android Project,
available here:
http://android.git.kernel.org/?p=platform/system/core.git;a=tree;f=mkbootimg
abootimg can work directly on block devices, or, the safest way, on a file image.
File images can be read/written with dd:
$ dd if=/dev/mmcblk0p2 of=boot.img
$ dd if=boot.img of=/dev/mmcblk0p2
You obviously need to have right access to the block device (using su, sudo,
...).
Android Boot Image contains an 32 bytes Id. The specification does not actually
mandates any specific implementation of this Id (it can be a timestamp, a CRC
checksum, a SHA hash, ...). Bootloader appears to do nothing of this Id, it's
solely here for tracking purpose. Currently abootimg does nothing with it, it's
never touched/modified.
* Building abootimg
-------------------
On a linux system, it's simply as:
$ make
blkid library is needed to perform some sanity checks when writing boot image
directly on a block device (to avoid writing a valid existing filesystem).
* Looking at an Android Boot Image
----------------------------------
Basic Information can be extracted from a boot image, using:
$ abootimg -i <bootimg>
Here is an example:
$ ./abootimg -i boot.img
Android Boot Image Info:
* file name = boot.img
* image size = 8388608 bytes (8.00 MB)
page size = 2048 bytes
* Boot Name = ""
* kernel size = 3002744 bytes (2.86 MB)
ramdisk size = 1639626 bytes (1.56 MB)
* load addresses:
kernel: 0x10008000
ramdisk: 0x11000000
tags: 0x10000100
* cmdline = mem=448M@0M nvmem=64M@448M vmalloc=320M video=tegrafb console=tty0 usbcore.old_scheme_first=1 quiet splash elevator=noop tegraboot=sdmmc cmdpart=1:7168:10240,2:17408:16384,3:35840:614400,4:4004864:27096064
* id = 0x07571070 0x13950a6a 0x185c996f 0x9ab7b64d 0xcccd09bd 0x00000000 0x00000000 0x00000000
* Extracting elements from an Android Boot Image
------------------------------------------------
All parts of boot image can be extracted with:
$ abootimg -x <bootimg> [<bootimg.cfg> [<kernel> [<ramdisk> [<secondstage>]]]]
Parts name are optional. Default ones are used if none are given:
* bootimg.cfg for the configuration file
* zImage for the Kernel image
* initrd.img for the Ramdisk
* stage2.img for the Second Stage image
Here is an example:
$ abootimg -x boot.img
writing boot image config in bootimg.cfg
extracting kernel in zImage
extracting ramdisk in initrd.img
* Boot Configuration file
-------------------------
It's an editable ascii file which is basically a dump of the header content,
to be able to rebuild a compatible image later.
Each entry takes one line and is in the form of:
<entry> = <value>
You can put any number of spaces/tab before/after the =
<value> is evalued starting from the fisrt non space character following the =
until the end of line
Numerical values can be given in decimal (12345) or hexadecimal (0x1234abcd).
Known configuration entries are:
* bootsize
Indicate the size of the boot image to produce
* pagesize
All sizes have to be a multiple of the page size.
Standard page size is 2048 bytes. I don't know if other page size
are supported by Android bootloader
* kerneladdr, ramdiskaddr, secondaddr, tagsaddr
Address in RAM used to load the kernel, ramdisk, 2nd stage
bootloader, and tags table.
* name
name given to the boot image.
not really used by bootloader, but it's can be usefull to keep
track of what the image actually contains
* cmdline
contains the command line passed to the kernel when booting
* Updating an existing Android Boot Image
-----------------------------------------
An existing valid Boot Image can be updated with:
$ abootimg -u <bootimg> [-c "param=value"] [-f <bootimg.cfg>] [-k <kernel>] [-r <ramdisk>] [-s <secondstage>]
Any part of the image can be individully updated. As an example:
$ abootimg -u boot.img -k zImage.new
will update the kernel
$ abootimg -u boot.img -r initrd.new.img
will update the image
$ abootimg -u boot.img -k zImage.new -r initrd.new.img
will update both
Image configuration can be updated either by giving a configuration file
(-f option) or by giving individual config entries on the command line (-c).
Severial config entries (-c) can be given on comamd line.
As an example:
$ abootimg -u boot.img -f bootimg.new.cfg
will update the configuration without touching the kernel
nor the ramdisk
$ abootimg -u boot.img -c "cmdline = mem=448M@0M nvmem=64M@448M vmalloc=320M \
video=tegrafb console=tty0 usbcore.old_scheme_first=1 quiet splash elevator=noop \
tegraboot=sdmmc tegrapart=recovery:700:a00:800,boot:1100:1000:800,mbr:2100:200:800,\
system:2300:25800:800,cache:27b00:32000:800,misc:59b00:400:800,userdata:5a000:9a600:800"
update the boot conmand line
$ abootimg -u boot.img -c "bootsize=0x500000"
update the boot image size to 5MB.
It's usefull if you want to shrink an existing image to make it
fit in another smaller boot partition.
(On Toshiba AC100, it allows you to take a part06.img and
transform it to fit inside part05)
The original boot image has to be valid, otherwise abootimg will refuse to
update it.
* Creating a new Android Boot Image from scratch
------------------------------------------------
A new boot image can be create with:
$ abootimg --create <bootimg> [-c "param=value"] [-f <bootimg.cfg>] -k <kernel> -r <ramdisk> [-s <secondstage>]
Parameters are the same than above for update. The only difference is that
kernel and ramdisk are mandatory.
* Working directly of Block Devices
-----------------------------------
Instead of manipulating Boot Image regular file, you can work directly on boot
block device.
Note that, on AC100, the current kernel needs to be patched in order to have
direct access to boot partitions (partitions 5 and 6).
Some examples:
$ sudo abootimg -i /dev/mmcblk0p2
read the current boot partition
$ sudo abootimg -u /dev/mmcblk0p2 -k arch/arm/boot/zImage
update the boot partition with the kernel you have just built
$ sudo abootimg -u /dev/mmcblk0p2 -c "cmdline=..."
update the boot partition with a new boot cmdline
$ sudo abootimg --create /dev/mmcblk0p2 -f boot.cfg -k zImage -r initrd.img
overwrite the boot partition (which can be damaged) with a
brand new image
If abootimg has to write to a block device (-u and --create), some sanity
check are performed:
* you oviously need read/write access to the block device (so use su,
sudo, ...)
* the actual partition must not be identified as containing a valid
filesystem as recognised by blkid library. Specifically, it cannot
contains a ext2/3 filesystem (this avoids you to ovewrite your root
filesystem by mistake)
* the updated/created boot image has to be same size than the block
device you try to write on.
* in case of update, the current boot partition has to contain a valid
Android Boot Image.
Failing any of these tests will abort the operation on block device.
It's by definition more risky to manipulate block device, as a bad
manipulation can as bad manipulation can make your system unbootable if you
don't fix it before the next reboot.
On the other hand, manipulating the block device allows abootimg to prevent
most of the stupid mistakes which can be made when writing boot image with dd
(overwriting another filesystem, writing a boot image bigger than the
partition, writing the wrong file or an invalid partition, ...)