diff options
author | Adrian Dudau <adrian.dudau@enea.com> | 2013-12-12 13:38:32 +0100 |
---|---|---|
committer | Adrian Dudau <adrian.dudau@enea.com> | 2013-12-12 13:50:20 +0100 |
commit | e2e6f6fe07049f33cb6348780fa975162752e421 (patch) | |
tree | b1813295411235d1297a0ed642b1346b24fdfb12 /README.hardware | |
download | poky-e2e6f6fe07049f33cb6348780fa975162752e421.tar.gz |
initial commit of Enea Linux 3.1
Migrated from the internal git server on the dora-enea branch
Signed-off-by: Adrian Dudau <adrian.dudau@enea.com>
Diffstat (limited to 'README.hardware')
-rw-r--r-- | README.hardware | 494 |
1 files changed, 494 insertions, 0 deletions
diff --git a/README.hardware b/README.hardware new file mode 100644 index 0000000000..607062b59a --- /dev/null +++ b/README.hardware | |||
@@ -0,0 +1,494 @@ | |||
1 | Poky Hardware README | ||
2 | ==================== | ||
3 | |||
4 | This file gives details about using Poky with the reference machines | ||
5 | supported out of the box. A full list of supported reference target machines | ||
6 | can be found by looking in the following directories: | ||
7 | |||
8 | meta/conf/machine/ | ||
9 | meta-yocto-bsp/conf/machine/ | ||
10 | |||
11 | If you are in doubt about using Poky/OpenEmbedded with your hardware, consult | ||
12 | the documentation for your board/device. | ||
13 | |||
14 | Support for additional devices is normally added by creating BSP layers - for | ||
15 | more information please see the Yocto Board Support Package (BSP) Developer's | ||
16 | Guide - documentation source is in documentation/bspguide or download the PDF | ||
17 | from: | ||
18 | |||
19 | http://yoctoproject.org/documentation | ||
20 | |||
21 | Support for physical reference hardware has now been split out into a | ||
22 | meta-yocto-bsp layer which can be removed separately from other layers if not | ||
23 | needed. | ||
24 | |||
25 | |||
26 | QEMU Emulation Targets | ||
27 | ====================== | ||
28 | |||
29 | To simplify development, the build system supports building images to | ||
30 | work with the QEMU emulator in system emulation mode. Several architectures | ||
31 | are currently supported: | ||
32 | |||
33 | * ARM (qemuarm) | ||
34 | * x86 (qemux86) | ||
35 | * x86-64 (qemux86-64) | ||
36 | * PowerPC (qemuppc) | ||
37 | * MIPS (qemumips) | ||
38 | |||
39 | Use of the QEMU images is covered in the Yocto Project Reference Manual. | ||
40 | The appropriate MACHINE variable value corresponding to the target is given | ||
41 | in brackets. | ||
42 | |||
43 | |||
44 | Hardware Reference Boards | ||
45 | ========================= | ||
46 | |||
47 | The following boards are supported by the meta-yocto-bsp layer: | ||
48 | |||
49 | * Texas Instruments Beagleboard (beagleboard) | ||
50 | * Freescale MPC8315E-RDB (mpc8315e-rdb) | ||
51 | * Ubiquiti Networks RouterStation Pro (routerstationpro) | ||
52 | |||
53 | For more information see the board's section below. The appropriate MACHINE | ||
54 | variable value corresponding to the board is given in brackets. | ||
55 | |||
56 | |||
57 | Consumer Devices | ||
58 | ================ | ||
59 | |||
60 | The following consumer devices are supported by the meta-yocto-bsp layer: | ||
61 | |||
62 | * Intel x86 based PCs and devices (genericx86) | ||
63 | |||
64 | For more information see the device's section below. The appropriate MACHINE | ||
65 | variable value corresponding to the device is given in brackets. | ||
66 | |||
67 | |||
68 | |||
69 | Specific Hardware Documentation | ||
70 | =============================== | ||
71 | |||
72 | |||
73 | Intel x86 based PCs and devices (genericx86) | ||
74 | ========================================== | ||
75 | |||
76 | The genericx86 MACHINE is tested on the following platforms: | ||
77 | |||
78 | Intel Xeon/Core i-Series: | ||
79 | + Intel Romley Server: Sandy Bridge Xeon processor, C600 PCH (Patsburg), (Canoe Pass CRB) | ||
80 | + Intel Romley Server: Ivy Bridge Xeon processor, C600 PCH (Patsburg), (Intel SDP S2R3) | ||
81 | + Intel Crystal Forest Server: Sandy Bridge Xeon processor, DH89xx PCH (Cave Creek), (Stargo CRB) | ||
82 | + Intel Chief River Mobile: Ivy Bridge Mobile processor, QM77 PCH (Panther Point-M), (Emerald Lake II CRB, Sabino Canyon CRB) | ||
83 | + Intel Huron River Mobile: Sandy Bridge processor, QM67 PCH (Cougar Point), (Emerald Lake CRB, EVOC EC7-1817LNAR board) | ||
84 | + Intel Calpella Platform: Core i7 processor, QM57 PCH (Ibex Peak-M), (Red Fort CRB, Emerson MATXM CORE-411-B) | ||
85 | + Intel Nehalem/Westmere-EP Server: Xeon 56xx/55xx processors, 5520 chipset, ICH10R IOH (82801), (Hanlan Creek CRB) | ||
86 | + Intel Nehalem Workstation: Xeon 56xx/55xx processors, System SC5650SCWS (Greencity CRB) | ||
87 | + Intel Picket Post Server: Xeon 56xx/55xx processors (Jasper Forest), 3420 chipset (Ibex Peak), (Osage CRB) | ||
88 | + Intel Storage Platform: Sandy Bridge Xeon processor, C600 PCH (Patsburg), (Oak Creek Canyon CRB) | ||
89 | + Intel Shark Bay Client Platform: Haswell processor, LynxPoint PCH, (Walnut Canyon CRB, Lava Canyon CRB, Basking Ridge CRB, Flathead Creek CRB) | ||
90 | + Intel Shark Bay Ultrabook Platform: Haswell ULT processor, Lynx Point-LP PCH, (WhiteTip Mountain 1 CRB) | ||
91 | |||
92 | Intel Atom platforms: | ||
93 | + Intel embedded Menlow: Intel Atom Z510/530 CPU, System Controller Hub US15W (Portwell NANO-8044) | ||
94 | + Intel Luna Pier: Intel Atom N4xx/D5xx series CPU (aka: Pineview-D & -M), 82801HM I/O Hub (ICH8M), (Advantech AIMB-212, Moon Creek CRB) | ||
95 | + Intel Queens Bay platform: Intel Atom E6xx CPU (aka: Tunnel Creek), Topcliff EG20T I/O Hub (Emerson NITX-315, Crown Bay CRB, Minnow Board) | ||
96 | + Intel Fish River Island platform: Intel Atom E6xx CPU (aka: Tunnel Creek), Topcliff EG20T I/O Hub (Kontron KM2M806) | ||
97 | + Intel Cedar Trail platform: Intel Atom N2000 & D2000 series CPU (aka: Cedarview), NM10 Express Chipset (Norco kit BIS-6630, Cedar Rock CRB) | ||
98 | |||
99 | and is likely to work on many unlisted Atom/Core/Xeon based devices. The MACHINE | ||
100 | type supports ethernet, wifi, sound, and Intel/vesa graphics by default in | ||
101 | addition to common PC input devices, busses, and so on. Note that it does not | ||
102 | included the binary-only graphic drivers used on some Atom platforms, for | ||
103 | accelerated graphics on these machines please refer to meta-intel. | ||
104 | |||
105 | Depending on the device, it can boot from a traditional hard-disk, a USB device, | ||
106 | or over the network. Writing generated images to physical media is | ||
107 | straightforward with a caveat for USB devices. The following examples assume the | ||
108 | target boot device is /dev/sdb, be sure to verify this and use the correct | ||
109 | device as the following commands are run as root and are not reversable. | ||
110 | |||
111 | USB Device: | ||
112 | 1. Build a live image. This image type consists of a simple filesystem | ||
113 | without a partition table, which is suitable for USB keys, and with the | ||
114 | default setup for the genericx86 machine, this image type is built | ||
115 | automatically for any image you build. For example: | ||
116 | |||
117 | $ bitbake core-image-minimal | ||
118 | |||
119 | 2. Use the "dd" utility to write the image to the raw block device. For | ||
120 | example: | ||
121 | |||
122 | # dd if=core-image-minimal-genericx86.hddimg of=/dev/sdb | ||
123 | |||
124 | If the device fails to boot with "Boot error" displayed, or apparently | ||
125 | stops just after the SYSLINUX version banner, it is likely the BIOS cannot | ||
126 | understand the physical layout of the disk (or rather it expects a | ||
127 | particular layout and cannot handle anything else). There are two possible | ||
128 | solutions to this problem: | ||
129 | |||
130 | 1. Change the BIOS USB Device setting to HDD mode. The label will vary by | ||
131 | device, but the idea is to force BIOS to read the Cylinder/Head/Sector | ||
132 | geometry from the device. | ||
133 | |||
134 | 2. Without such an option, the BIOS generally boots the device in USB-ZIP | ||
135 | mode. To write an image to a USB device that will be bootable in | ||
136 | USB-ZIP mode, carry out the following actions: | ||
137 | |||
138 | a. Determine the geometry of your USB device using fdisk: | ||
139 | |||
140 | # fdisk /dev/sdb | ||
141 | Command (m for help): p | ||
142 | |||
143 | Disk /dev/sdb: 4011 MB, 4011491328 bytes | ||
144 | 124 heads, 62 sectors/track, 1019 cylinders, total 7834944 sectors | ||
145 | ... | ||
146 | |||
147 | Command (m for help): q | ||
148 | |||
149 | b. Configure the USB device for USB-ZIP mode: | ||
150 | |||
151 | # mkdiskimage -4 /dev/sdb 1019 124 62 | ||
152 | |||
153 | Where 1019, 124 and 62 are the cylinder, head and sectors/track counts | ||
154 | as reported by fdisk (substitute the values reported for your device). | ||
155 | When the operation has finished and the access LED (if any) on the | ||
156 | device stops flashing, remove and reinsert the device to allow the | ||
157 | kernel to detect the new partition layout. | ||
158 | |||
159 | c. Copy the contents of the image to the USB-ZIP mode device: | ||
160 | |||
161 | # mkdir /tmp/image | ||
162 | # mkdir /tmp/usbkey | ||
163 | # mount -o loop core-image-minimal-genericx86.hddimg /tmp/image | ||
164 | # mount /dev/sdb4 /tmp/usbkey | ||
165 | # cp -rf /tmp/image/* /tmp/usbkey | ||
166 | |||
167 | d. Install the syslinux boot loader: | ||
168 | |||
169 | # syslinux /dev/sdb4 | ||
170 | |||
171 | e. Unmount everything: | ||
172 | |||
173 | # umount /tmp/image | ||
174 | # umount /tmp/usbkey | ||
175 | |||
176 | Install the boot device in the target board and configure the BIOS to boot | ||
177 | from it. | ||
178 | |||
179 | For more details on the USB-ZIP scenario, see the syslinux documentation: | ||
180 | http://git.kernel.org/?p=boot/syslinux/syslinux.git;a=blob_plain;f=doc/usbkey.txt;hb=HEAD | ||
181 | |||
182 | |||
183 | Texas Instruments Beagleboard (beagleboard) | ||
184 | =========================================== | ||
185 | |||
186 | The Beagleboard is an ARM Cortex-A8 development board with USB, DVI-D, S-Video, | ||
187 | 2D/3D accelerated graphics, audio, serial, JTAG, and SD/MMC. The xM adds a | ||
188 | faster CPU, more RAM, an ethernet port, more USB ports, microSD, and removes | ||
189 | the NAND flash. The beagleboard MACHINE is tested on the following platforms: | ||
190 | |||
191 | o Beagleboard C4 | ||
192 | o Beagleboard xM rev A & B | ||
193 | |||
194 | The Beagleboard C4 has NAND, while the xM does not. For the sake of simplicity, | ||
195 | these instructions assume you have erased the NAND on the C4 so its boot | ||
196 | behavior matches that of the xM. To do this, issue the following commands from | ||
197 | the u-boot prompt (note that the unlock may be unecessary depending on the | ||
198 | version of u-boot installed on your board and only one of the erase commands | ||
199 | will succeed): | ||
200 | |||
201 | # nand unlock | ||
202 | # nand erase | ||
203 | # nand erase.chip | ||
204 | |||
205 | To further tailor these instructions for your board, please refer to the | ||
206 | documentation at http://www.beagleboard.org. | ||
207 | |||
208 | From a Linux system with access to the image files perform the following steps | ||
209 | as root, replacing mmcblk0* with the SD card device on your machine (such as sdc | ||
210 | if used via a usb card reader): | ||
211 | |||
212 | 1. Partition and format an SD card: | ||
213 | # fdisk -lu /dev/mmcblk0 | ||
214 | |||
215 | Disk /dev/mmcblk0: 3951 MB, 3951034368 bytes | ||
216 | 255 heads, 63 sectors/track, 480 cylinders, total 7716864 sectors | ||
217 | Units = sectors of 1 * 512 = 512 bytes | ||
218 | |||
219 | Device Boot Start End Blocks Id System | ||
220 | /dev/mmcblk0p1 * 63 144584 72261 c Win95 FAT32 (LBA) | ||
221 | /dev/mmcblk0p2 144585 465884 160650 83 Linux | ||
222 | |||
223 | # mkfs.vfat -F 16 -n "boot" /dev/mmcblk0p1 | ||
224 | # mke2fs -j -L "root" /dev/mmcblk0p2 | ||
225 | |||
226 | The following assumes the SD card partition 1 and 2 are mounted at | ||
227 | /media/boot and /media/root respectively. Removing the card and reinserting | ||
228 | it will do just that on most modern Linux desktop environments. | ||
229 | |||
230 | The files referenced below are made available after the build in | ||
231 | build/tmp/deploy/images. | ||
232 | |||
233 | 2. Install the boot loaders | ||
234 | # cp MLO-beagleboard /media/boot/MLO | ||
235 | # cp u-boot-beagleboard.bin /media/boot/u-boot.bin | ||
236 | |||
237 | 3. Install the root filesystem | ||
238 | # tar x -C /media/root -f core-image-$IMAGE_TYPE-beagleboard.tar.bz2 | ||
239 | # tar x -C /media/root -f modules-$KERNEL_VERSION-beagleboard.tgz | ||
240 | |||
241 | 4. Install the kernel uImage | ||
242 | # cp uImage-beagleboard.bin /media/boot/uImage | ||
243 | |||
244 | 5. Prepare a u-boot script to simplify the boot process | ||
245 | The Beagleboard can be made to boot at this point from the u-boot command | ||
246 | shell. To automate this process, generate a user.scr script as follows. | ||
247 | |||
248 | Install uboot-mkimage (from uboot-mkimage on Ubuntu or uboot-tools on Fedora). | ||
249 | |||
250 | Prepare a script config: | ||
251 | |||
252 | # (cat << EOF | ||
253 | setenv bootcmd 'mmc init; fatload mmc 0:1 0x80300000 uImage; bootm 0x80300000' | ||
254 | setenv bootargs 'console=tty0 console=ttyO2,115200n8 root=/dev/mmcblk0p2 rootwait rootfstype=ext3 ro' | ||
255 | boot | ||
256 | EOF | ||
257 | ) > serial-boot.cmd | ||
258 | # mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Core Minimal" -d ./serial-boot.cmd ./boot.scr | ||
259 | # cp boot.scr /media/boot | ||
260 | |||
261 | 6. Unmount the SD partitions, insert the SD card into the Beagleboard, and | ||
262 | boot the Beagleboard | ||
263 | |||
264 | Note: As of the 2.6.37 linux-yocto kernel recipe, the Beagleboard uses the | ||
265 | OMAP_SERIAL device (ttyO2). If you are using an older kernel, such as the | ||
266 | 2.6.34 linux-yocto-stable, be sure to replace ttyO2 with ttyS2 above. You | ||
267 | should also override the machine SERIAL_CONSOLE in your local.conf in | ||
268 | order to setup the getty on the serial line: | ||
269 | |||
270 | SERIAL_CONSOLE_beagleboard = "115200 ttyS2" | ||
271 | |||
272 | |||
273 | Freescale MPC8315E-RDB (mpc8315e-rdb) | ||
274 | ===================================== | ||
275 | |||
276 | The MPC8315 PowerPC reference platform (MPC8315E-RDB) is aimed at hardware and | ||
277 | software development of network attached storage (NAS) and digital media server | ||
278 | applications. The MPC8315E-RDB features the PowerQUICC II Pro processor, which | ||
279 | includes a built-in security accelerator. | ||
280 | |||
281 | (Note: you may find it easier to order MPC8315E-RDBA; this appears to be the | ||
282 | same board in an enclosure with accessories. In any case it is fully | ||
283 | compatible with the instructions given here.) | ||
284 | |||
285 | Setup instructions | ||
286 | ------------------ | ||
287 | |||
288 | You will need the following: | ||
289 | * NFS root setup on your workstation | ||
290 | * TFTP server installed on your workstation | ||
291 | * Straight-thru 9-conductor serial cable (DB9, M/F) connected from your | ||
292 | PC to UART1 | ||
293 | * Ethernet connected to the first ethernet port on the board | ||
294 | |||
295 | --- Preparation --- | ||
296 | |||
297 | Note: if you have altered your board's ethernet MAC address(es) from the | ||
298 | defaults, or you need to do so because you want multiple boards on the same | ||
299 | network, then you will need to change the values in the dts file (patch | ||
300 | linux/arch/powerpc/boot/dts/mpc8315erdb.dts within the kernel source). If | ||
301 | you have left them at the factory default then you shouldn't need to do | ||
302 | anything here. | ||
303 | |||
304 | --- Booting from NFS root --- | ||
305 | |||
306 | Load the kernel and dtb (device tree blob), and boot the system as follows: | ||
307 | |||
308 | 1. Get the kernel (uImage-mpc8315e-rdb.bin) and dtb (uImage-mpc8315e-rdb.dtb) | ||
309 | files from the tmp/deploy directory, and make them available on your TFTP | ||
310 | server. | ||
311 | |||
312 | 2. Connect the board's first serial port to your workstation and then start up | ||
313 | your favourite serial terminal so that you will be able to interact with | ||
314 | the serial console. If you don't have a favourite, picocom is suggested: | ||
315 | |||
316 | $ picocom /dev/ttyUSB0 -b 115200 | ||
317 | |||
318 | 3. Power up or reset the board and press a key on the terminal when prompted | ||
319 | to get to the U-Boot command line | ||
320 | |||
321 | 4. Set up the environment in U-Boot: | ||
322 | |||
323 | => setenv ipaddr <board ip> | ||
324 | => setenv serverip <tftp server ip> | ||
325 | => setenv bootargs root=/dev/nfs rw nfsroot=<nfsroot ip>:<rootfs path> ip=<board ip>:<server ip>:<gateway ip>:255.255.255.0:mpc8315e:eth0:off console=ttyS0,115200 | ||
326 | |||
327 | 5. Download the kernel and dtb, and boot: | ||
328 | |||
329 | => tftp 1000000 uImage-mpc8315e-rdb.bin | ||
330 | => tftp 2000000 uImage-mpc8315e-rdb.dtb | ||
331 | => bootm 1000000 - 2000000 | ||
332 | |||
333 | |||
334 | Ubiquiti Networks RouterStation Pro (routerstationpro) | ||
335 | ====================================================== | ||
336 | |||
337 | The RouterStation Pro is an Atheros AR7161 MIPS-based board. Geared towards | ||
338 | networking applications, it has all of the usual features as well as three | ||
339 | type IIIA mini-PCI slots and an on-board 3-port 10/100/1000 Ethernet switch, | ||
340 | in addition to the 10/100/1000 Ethernet WAN port which supports | ||
341 | Power-over-Ethernet. | ||
342 | |||
343 | Setup instructions | ||
344 | ------------------ | ||
345 | |||
346 | You will need the following: | ||
347 | * A serial cable - female to female (or female to male + gender changer) | ||
348 | NOTE: cable must be straight through, *not* a null modem cable. | ||
349 | * USB flash drive or hard disk that is able to be powered from the | ||
350 | board's USB port. | ||
351 | * tftp server installed on your workstation | ||
352 | |||
353 | NOTE: in the following instructions it is assumed that /dev/sdb corresponds | ||
354 | to the USB disk when it is plugged into your workstation. If this is not the | ||
355 | case in your setup then please be careful to substitute the correct device | ||
356 | name in all commands where appropriate. | ||
357 | |||
358 | --- Preparation --- | ||
359 | |||
360 | 1) Build an image (e.g. core-image-minimal) using "routerstationpro" as the | ||
361 | MACHINE | ||
362 | |||
363 | 2) Partition the USB drive so that primary partition 1 is type Linux (83). | ||
364 | Minimum size depends on your root image size - core-image-minimal probably | ||
365 | only needs 8-16MB, other images will need more. | ||
366 | |||
367 | # fdisk /dev/sdb | ||
368 | Command (m for help): p | ||
369 | |||
370 | Disk /dev/sdb: 4011 MB, 4011491328 bytes | ||
371 | 124 heads, 62 sectors/track, 1019 cylinders, total 7834944 sectors | ||
372 | Units = sectors of 1 * 512 = 512 bytes | ||
373 | Sector size (logical/physical): 512 bytes / 512 bytes | ||
374 | I/O size (minimum/optimal): 512 bytes / 512 bytes | ||
375 | Disk identifier: 0x0009e87d | ||
376 | |||
377 | Device Boot Start End Blocks Id System | ||
378 | /dev/sdb1 62 1952751 976345 83 Linux | ||
379 | |||
380 | 3) Format partition 1 on the USB as ext3 | ||
381 | |||
382 | # mke2fs -j /dev/sdb1 | ||
383 | |||
384 | 4) Mount partition 1 and then extract the contents of | ||
385 | tmp/deploy/images/core-image-XXXX.tar.bz2 into it (preserving permissions). | ||
386 | |||
387 | # mount /dev/sdb1 /media/sdb1 | ||
388 | # cd /media/sdb1 | ||
389 | # tar -xvjpf tmp/deploy/images/core-image-XXXX.tar.bz2 | ||
390 | |||
391 | 5) Unmount the USB drive and then plug it into the board's USB port | ||
392 | |||
393 | 6) Connect the board's serial port to your workstation and then start up | ||
394 | your favourite serial terminal so that you will be able to interact with | ||
395 | the serial console. If you don't have a favourite, picocom is suggested: | ||
396 | |||
397 | $ picocom /dev/ttyUSB0 -b 115200 | ||
398 | |||
399 | 7) Connect the network into eth0 (the one that is NOT the 3 port switch). If | ||
400 | you are using power-over-ethernet then the board will power up at this point. | ||
401 | |||
402 | 8) Start up the board, watch the serial console. Hit Ctrl+C to abort the | ||
403 | autostart if the board is configured that way (it is by default). The | ||
404 | bootloader's fconfig command can be used to disable autostart and configure | ||
405 | the IP settings if you need to change them (default IP is 192.168.1.20). | ||
406 | |||
407 | 9) Make the kernel (tmp/deploy/images/vmlinux-routerstationpro.bin) available | ||
408 | on the tftp server. | ||
409 | |||
410 | 10) If you are going to write the kernel to flash (optional - see "Booting a | ||
411 | kernel directly" below for the alternative), remove the current kernel and | ||
412 | rootfs flash partitions. You can list the partitions using the following | ||
413 | bootloader command: | ||
414 | |||
415 | RedBoot> fis list | ||
416 | |||
417 | You can delete the existing kernel and rootfs with these commands: | ||
418 | |||
419 | RedBoot> fis delete kernel | ||
420 | RedBoot> fis delete rootfs | ||
421 | |||
422 | --- Booting a kernel directly --- | ||
423 | |||
424 | 1) Load the kernel using the following bootloader command: | ||
425 | |||
426 | RedBoot> load -m tftp -h <ip of tftp server> vmlinux-routerstationpro.bin | ||
427 | |||
428 | You should see a message on it being successfully loaded. | ||
429 | |||
430 | 2) Execute the kernel: | ||
431 | |||
432 | RedBoot> exec -c "console=ttyS0,115200 root=/dev/sda1 rw rootdelay=2 board=UBNT-RSPRO" | ||
433 | |||
434 | Note that specifying the command line with -c is important as linux-yocto does | ||
435 | not provide a default command line. | ||
436 | |||
437 | --- Writing a kernel to flash --- | ||
438 | |||
439 | 1) Go to your tftp server and gzip the kernel you want in flash. It should | ||
440 | halve the size. | ||
441 | |||
442 | 2) Load the kernel using the following bootloader command: | ||
443 | |||
444 | RedBoot> load -r -b 0x80600000 -m tftp -h <ip of tftp server> vmlinux-routerstationpro.bin.gz | ||
445 | |||
446 | This should output something similar to the following: | ||
447 | |||
448 | Raw file loaded 0x80600000-0x8087c537, assumed entry at 0x80600000 | ||
449 | |||
450 | Calculate the length by subtracting the first number from the second number | ||
451 | and then rounding the result up to the nearest 0x1000. | ||
452 | |||
453 | 3) Using the length calculated above, create a flash partition for the kernel: | ||
454 | |||
455 | RedBoot> fis create -b 0x80600000 -l 0x240000 kernel | ||
456 | |||
457 | (change 0x240000 to your rounded length -- change "kernel" to whatever | ||
458 | you want to name your kernel) | ||
459 | |||
460 | --- Booting a kernel from flash --- | ||
461 | |||
462 | To boot the flashed kernel perform the following steps. | ||
463 | |||
464 | 1) At the bootloader prompt, load the kernel: | ||
465 | |||
466 | RedBoot> fis load -d -e kernel | ||
467 | |||
468 | (Change the name "kernel" above if you chose something different earlier) | ||
469 | |||
470 | (-e means 'elf', -d 'decompress') | ||
471 | |||
472 | 2) Execute the kernel using the exec command as above. | ||
473 | |||
474 | --- Automating the boot process --- | ||
475 | |||
476 | After writing the kernel to flash and testing the load and exec commands | ||
477 | manually, you can automate the boot process with a boot script. | ||
478 | |||
479 | 1) RedBoot> fconfig | ||
480 | (Answer the questions not specified here as they pertain to your environment) | ||
481 | 2) Run script at boot: true | ||
482 | Boot script: | ||
483 | .. fis load -d -e kernel | ||
484 | .. exec | ||
485 | Enter script, terminate with empty line | ||
486 | >> fis load -d -e kernel | ||
487 | >> exec -c "console=ttyS0,115200 root=/dev/sda1 rw rootdelay=2 board=UBNT-RSPRO" | ||
488 | >> | ||
489 | 3) Answer the remaining questions and write the changes to flash: | ||
490 | Update RedBoot non-volatile configuration - continue (y/n)? y | ||
491 | ... Erase from 0xbfff0000-0xc0000000: . | ||
492 | ... Program from 0x87ff0000-0x88000000 at 0xbfff0000: . | ||
493 | 4) Power cycle the board. | ||
494 | |||