diff options
| author | Tudor Florea <tudor.florea@enea.com> | 2014-10-16 03:05:19 +0200 |
|---|---|---|
| committer | Tudor Florea <tudor.florea@enea.com> | 2014-10-16 03:05:19 +0200 |
| commit | c527fd1f14c27855a37f2e8ac5346ce8d940ced2 (patch) | |
| tree | bb002c1fdf011c41dbd2f0927bed23ecb5f83c97 /README.hardware | |
| download | poky-daisy-140929.tar.gz | |
initial commit for Enea Linux 4.0-140929daisy-140929
Migrated from the internal git server on the daisy-enea-point-release branch
Signed-off-by: Tudor Florea <tudor.florea@enea.com>
Diffstat (limited to 'README.hardware')
| -rw-r--r-- | README.hardware | 476 |
1 files changed, 476 insertions, 0 deletions
diff --git a/README.hardware b/README.hardware new file mode 100644 index 0000000000..37fdab08b0 --- /dev/null +++ b/README.hardware | |||
| @@ -0,0 +1,476 @@ | |||
| 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 Beaglebone (beaglebone) | ||
| 50 | * Freescale MPC8315E-RDB (mpc8315e-rdb) | ||
| 51 | |||
| 52 | For more information see the board's section below. The appropriate MACHINE | ||
| 53 | variable value corresponding to the board is given in brackets. | ||
| 54 | |||
| 55 | |||
| 56 | Consumer Devices | ||
| 57 | ================ | ||
| 58 | |||
| 59 | The following consumer devices are supported by the meta-yocto-bsp layer: | ||
| 60 | |||
| 61 | * Intel x86 based PCs and devices (genericx86) | ||
| 62 | * Ubiquiti Networks EdgeRouter Lite (edgerouter) | ||
| 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 Beaglebone (beaglebone) | ||
| 184 | ========================================= | ||
| 185 | |||
| 186 | The Beaglebone is an ARM Cortex-A8 development board with USB, Ethernet, 2D/3D | ||
| 187 | accelerated graphics, audio, serial, JTAG, and SD/MMC. The Black adds a faster | ||
| 188 | CPU, more RAM, eMMC flash and a micro HDMI port. The beaglebone MACHINE is | ||
| 189 | tested on the following platforms: | ||
| 190 | |||
| 191 | o Beaglebone Black A6 | ||
| 192 | o Beaglebone A6 (the original "White" model) | ||
| 193 | |||
| 194 | The Beaglebone Black has eMMC, while the White does not. Pressing the USER/BOOT | ||
| 195 | button when powering on will temporarily change the boot order. But for the sake | ||
| 196 | of simplicity, these instructions assume you have erased the eMMC on the Black, | ||
| 197 | so its boot behavior matches that of the White and boots off of SD card. To do | ||
| 198 | this, issue the following commands from the u-boot prompt: | ||
| 199 | |||
| 200 | # mmc dev 1 | ||
| 201 | # mmc erase 0 512 | ||
| 202 | |||
| 203 | To further tailor these instructions for your board, please refer to the | ||
| 204 | documentation at http://www.beagleboard.org/bone and http://www.beagleboard.org/black | ||
| 205 | |||
| 206 | From a Linux system with access to the image files perform the following steps | ||
| 207 | as root, replacing mmcblk0* with the SD card device on your machine (such as sdc | ||
| 208 | if used via a usb card reader): | ||
| 209 | |||
| 210 | 1. Partition and format an SD card: | ||
| 211 | # fdisk -lu /dev/mmcblk0 | ||
| 212 | |||
| 213 | Disk /dev/mmcblk0: 3951 MB, 3951034368 bytes | ||
| 214 | 255 heads, 63 sectors/track, 480 cylinders, total 7716864 sectors | ||
| 215 | Units = sectors of 1 * 512 = 512 bytes | ||
| 216 | |||
| 217 | Device Boot Start End Blocks Id System | ||
| 218 | /dev/mmcblk0p1 * 63 144584 72261 c Win95 FAT32 (LBA) | ||
| 219 | /dev/mmcblk0p2 144585 465884 160650 83 Linux | ||
| 220 | |||
| 221 | # mkfs.vfat -F 16 -n "boot" /dev/mmcblk0p1 | ||
| 222 | # mke2fs -j -L "root" /dev/mmcblk0p2 | ||
| 223 | |||
| 224 | The following assumes the SD card partitions 1 and 2 are mounted at | ||
| 225 | /media/boot and /media/root respectively. Removing the card and reinserting | ||
| 226 | it will do just that on most modern Linux desktop environments. | ||
| 227 | |||
| 228 | The files referenced below are made available after the build in | ||
| 229 | build/tmp/deploy/images. | ||
| 230 | |||
| 231 | 2. Install the boot loaders | ||
| 232 | # cp MLO-beaglebone /media/boot/MLO | ||
| 233 | # cp u-boot-beaglebone.img /media/boot/u-boot.img | ||
| 234 | |||
| 235 | 3. Install the root filesystem | ||
| 236 | # tar x -C /media/root -f core-image-$IMAGE_TYPE-beaglebone.tar.bz2 | ||
| 237 | |||
| 238 | 4. If using core-image-base or core-image-sato images, the SD card is ready | ||
| 239 | and rootfs already contains the kernel, modules and device tree (DTB) | ||
| 240 | files necessary to be booted with U-boot's default configuration, so | ||
| 241 | skip directly to step 8. | ||
| 242 | For core-image-minimal, proceed through next steps. | ||
| 243 | |||
| 244 | 5. If using core-image-minimal rootfs, install the modules | ||
| 245 | # tar x -C /media/root -f modules-beaglebone.tgz | ||
| 246 | |||
| 247 | 6. If using core-image-minimal rootfs, install the kernel uImage into /boot | ||
| 248 | directory of rootfs | ||
| 249 | # cp uImage-beaglebone.bin /media/root/boot/uImage | ||
| 250 | |||
| 251 | 7. If using core-image-minimal rootfs, also install device tree (DTB) files | ||
| 252 | into /boot directory of rootfs | ||
| 253 | # cp uImage-am335x-bone.dtb /media/root/boot/am335x-bone.dtb | ||
| 254 | # cp uImage-am335x-boneblack.dtb /media/root/boot/am335x-boneblack.dtb | ||
| 255 | |||
| 256 | 8. Unmount the SD partitions, insert the SD card into the Beaglebone, and | ||
| 257 | boot the Beaglebone | ||
| 258 | |||
| 259 | |||
| 260 | Freescale MPC8315E-RDB (mpc8315e-rdb) | ||
| 261 | ===================================== | ||
| 262 | |||
| 263 | The MPC8315 PowerPC reference platform (MPC8315E-RDB) is aimed at hardware and | ||
| 264 | software development of network attached storage (NAS) and digital media server | ||
| 265 | applications. The MPC8315E-RDB features the PowerQUICC II Pro processor, which | ||
| 266 | includes a built-in security accelerator. | ||
| 267 | |||
| 268 | (Note: you may find it easier to order MPC8315E-RDBA; this appears to be the | ||
| 269 | same board in an enclosure with accessories. In any case it is fully | ||
| 270 | compatible with the instructions given here.) | ||
| 271 | |||
| 272 | Setup instructions | ||
| 273 | ------------------ | ||
| 274 | |||
| 275 | You will need the following: | ||
| 276 | * NFS root setup on your workstation | ||
| 277 | * TFTP server installed on your workstation | ||
| 278 | * Straight-thru 9-conductor serial cable (DB9, M/F) connected from your | ||
| 279 | PC to UART1 | ||
| 280 | * Ethernet connected to the first ethernet port on the board | ||
| 281 | |||
| 282 | --- Preparation --- | ||
| 283 | |||
| 284 | Note: if you have altered your board's ethernet MAC address(es) from the | ||
| 285 | defaults, or you need to do so because you want multiple boards on the same | ||
| 286 | network, then you will need to change the values in the dts file (patch | ||
| 287 | linux/arch/powerpc/boot/dts/mpc8315erdb.dts within the kernel source). If | ||
| 288 | you have left them at the factory default then you shouldn't need to do | ||
| 289 | anything here. | ||
| 290 | |||
| 291 | --- Booting from NFS root --- | ||
| 292 | |||
| 293 | Load the kernel and dtb (device tree blob), and boot the system as follows: | ||
| 294 | |||
| 295 | 1. Get the kernel (uImage-mpc8315e-rdb.bin) and dtb (uImage-mpc8315e-rdb.dtb) | ||
| 296 | files from the tmp/deploy directory, and make them available on your TFTP | ||
| 297 | server. | ||
| 298 | |||
| 299 | 2. Connect the board's first serial port to your workstation and then start up | ||
| 300 | your favourite serial terminal so that you will be able to interact with | ||
| 301 | the serial console. If you don't have a favourite, picocom is suggested: | ||
| 302 | |||
| 303 | $ picocom /dev/ttyUSB0 -b 115200 | ||
| 304 | |||
| 305 | 3. Power up or reset the board and press a key on the terminal when prompted | ||
| 306 | to get to the U-Boot command line | ||
| 307 | |||
| 308 | 4. Set up the environment in U-Boot: | ||
| 309 | |||
| 310 | => setenv ipaddr <board ip> | ||
| 311 | => setenv serverip <tftp server ip> | ||
| 312 | => 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 | ||
| 313 | |||
| 314 | 5. Download the kernel and dtb, and boot: | ||
| 315 | |||
| 316 | => tftp 1000000 uImage-mpc8315e-rdb.bin | ||
| 317 | => tftp 2000000 uImage-mpc8315e-rdb.dtb | ||
| 318 | => bootm 1000000 - 2000000 | ||
| 319 | |||
| 320 | |||
| 321 | Ubiquiti Networks EdgeRouter Lite (edgerouter) | ||
| 322 | ============================================== | ||
| 323 | |||
| 324 | The EdgeRouter Lite is part of the EdgeMax series. It is a MIPS64 router | ||
| 325 | (based on the Cavium Octeon processor) with 512MB of RAM, which uses an | ||
| 326 | internal USB pendrive for storage. | ||
| 327 | |||
| 328 | Setup instructions | ||
| 329 | ------------------ | ||
| 330 | |||
| 331 | You will need the following: | ||
| 332 | * NFS root setup on your workstation | ||
| 333 | * TFTP server installed on your workstation | ||
| 334 | * RJ45 -> serial ("rollover") cable connected from your PC to the CONSOLE | ||
| 335 | port on the board | ||
| 336 | * Ethernet connected to the first ethernet port on the board | ||
| 337 | |||
| 338 | --- Preparation --- | ||
| 339 | |||
| 340 | Build an image (e.g. core-image-minimal) using "edgerouter" as the MACHINE. | ||
| 341 | In the following instruction it is based on core-image-minimal. Another target | ||
| 342 | may be similiar with it. | ||
| 343 | |||
| 344 | --- Booting from NFS root --- | ||
| 345 | |||
| 346 | Load the kernel, and boot the system as follows: | ||
| 347 | |||
| 348 | 1. Get the kernel (vmlinux) file from the tmp/deploy/images/edgerouter | ||
| 349 | directory, and make them available on your TFTP server. | ||
| 350 | |||
| 351 | 2. Connect the board's first serial port to your workstation and then start up | ||
| 352 | your favourite serial terminal so that you will be able to interact with | ||
| 353 | the serial console. If you don't have a favourite, picocom is suggested: | ||
| 354 | |||
| 355 | $ picocom /dev/ttyS0 -b 115200 | ||
| 356 | |||
| 357 | 3. Power up or reset the board and press a key on the terminal when prompted | ||
| 358 | to get to the U-Boot command line | ||
| 359 | |||
| 360 | 4. Set up the environment in U-Boot: | ||
| 361 | |||
| 362 | => setenv ipaddr <board ip> | ||
| 363 | => setenv serverip <tftp server ip> | ||
| 364 | |||
| 365 | 5. Download the kernel and boot: | ||
| 366 | |||
| 367 | => tftp tftp $loadaddr vmlinux | ||
| 368 | => bootoctlinux $loadaddr coremask=0x3 root=/dev/nfs rw nfsroot=<nfsroot ip>:<rootfs path> ip=<board ip>:<server ip>:<gateway ip>:<netmask>:edgerouter:eth0:off mtdparts=phys_mapped_flash:512k(boot0),512k(boot1),64k@3072k(eeprom) | ||
| 369 | |||
| 370 | --- Booting from USB root --- | ||
| 371 | |||
| 372 | To boot from the USB disk, you either need to remove it from the edgerouter | ||
| 373 | box and populate it from another computer, or use a previously booted NFS | ||
| 374 | image and populate from the edgerouter itself. | ||
| 375 | |||
| 376 | Type 1: Mounted USB disk | ||
| 377 | ------------------------ | ||
| 378 | |||
| 379 | To boot from the USB disk there are two available partitions on the factory | ||
| 380 | USB storage. The rest of this guide assumes that these partitions are left | ||
| 381 | intact. If you change the partition scheme, you must update your boot method | ||
| 382 | appropriately. | ||
| 383 | |||
| 384 | The standard partitions are: | ||
| 385 | |||
| 386 | - 1: vfat partition containing factory kernels | ||
| 387 | - 2: ext3 partition for the root filesystem. | ||
| 388 | |||
| 389 | You can place the kernel on either partition 1, or partition 2, but the roofs | ||
| 390 | must go on partition 2 (due to its size). | ||
| 391 | |||
| 392 | Note: If you place the kernel on the ext3 partition, you must re-create the | ||
| 393 | ext3 filesystem, since the factory u-boot can only handle 128 byte inodes and | ||
| 394 | cannot read the partition otherwise. | ||
| 395 | |||
| 396 | Steps: | ||
| 397 | |||
| 398 | 1. Remove the USB disk from the edgerouter and insert it into a computer | ||
| 399 | that has access to your build artifacts. | ||
| 400 | |||
| 401 | 2. Copy the kernel image to the USB storage (assuming discovered as 'sdb' on | ||
| 402 | the development machine): | ||
| 403 | |||
| 404 | 2a) if booting from vfat | ||
| 405 | |||
| 406 | # mount /dev/sdb1 /mnt | ||
| 407 | # cp tmp/deploy/images/edgerouter/vmlinux /mnt | ||
| 408 | # umount /mnt | ||
| 409 | |||
| 410 | 2b) if booting from ext3 | ||
| 411 | |||
| 412 | # mkfs.ext3 -I 128 /dev/sdb2 | ||
| 413 | # mount /dev/sdb2 /mnt | ||
| 414 | # mkdir /mnt/boot | ||
| 415 | # cp tmp/deploy/images/edgerouter/vmlinux /mnt/boot | ||
| 416 | # umount /mnt | ||
| 417 | |||
| 418 | 3. Extract the rootfs to the USB storage ext3 partition | ||
| 419 | |||
| 420 | # mount /dev/sdb2 /mnt | ||
| 421 | # tar -xvjpf core-image-minimal-XXX.tar.bz2 -C /mnt | ||
| 422 | # umount /mnt | ||
| 423 | |||
| 424 | 4. Reboot the board and press a key on the terminal when prompted to get to the U-Boot | ||
| 425 | command line: | ||
| 426 | |||
| 427 | 5. Load the kernel and boot: | ||
| 428 | |||
| 429 | 5a) vfat boot | ||
| 430 | |||
| 431 | => fatload usb 0:1 $loadaddr vmlinux | ||
| 432 | |||
| 433 | 5b) ext3 boot | ||
| 434 | |||
| 435 | => ext2load usb 0:2 $loadaddr boot/vmlinux | ||
| 436 | |||
| 437 | => bootoctlinux $loadaddr coremask=0x3 root=/dev/sda2 rw rootwait mtdparts=phys_mapped_flash:512k(boot0),512k(boot1),64k@3072k(eeprom) | ||
| 438 | |||
| 439 | |||
| 440 | Type 2: NFS | ||
| 441 | ----------- | ||
| 442 | |||
| 443 | Note: If you place the kernel on the ext3 partition, you must re-create the | ||
| 444 | ext3 filesystem, since the factory u-boot can only handle 128 byte inodes and | ||
| 445 | cannot read the partition otherwise. | ||
| 446 | |||
| 447 | These boot instructions assume that you have recreated the ext3 filesystem with | ||
| 448 | 128 byte inodes, you have an updated uboot or you are running and image capable | ||
| 449 | of making the filesystem on the board itself. | ||
| 450 | |||
| 451 | |||
| 452 | 1. Boot from NFS root | ||
| 453 | |||
| 454 | 2. Mount the USB disk partition 2 and then extract the contents of | ||
| 455 | tmp/deploy/core-image-XXXX.tar.bz2 into it. | ||
| 456 | |||
| 457 | Before starting, copy core-image-minimal-xxx.tar.bz2 and vmlinux into | ||
| 458 | rootfs path on your workstation. | ||
| 459 | |||
| 460 | and then, | ||
| 461 | |||
| 462 | # mount /dev/sda2 /media/sda2 | ||
| 463 | # tar -xvjpf core-image-minimal-XXX.tar.bz2 -C /media/sda2 | ||
| 464 | # cp vmlinux /media/sda2/boot/vmlinux | ||
| 465 | # umount /media/sda2 | ||
| 466 | # reboot | ||
| 467 | |||
| 468 | 3. Reboot the board and press a key on the terminal when prompted to get to the U-Boot | ||
| 469 | command line: | ||
| 470 | |||
| 471 | # reboot | ||
| 472 | |||
| 473 | 4. Load the kernel and boot: | ||
| 474 | |||
| 475 | => ext2load usb 0:2 $loadaddr boot/vmlinux | ||
| 476 | => bootoctlinux $loadaddr coremask=0x3 root=/dev/sda2 rw rootwait mtdparts=phys_mapped_flash:512k(boot0),512k(boot1),64k@3072k(eeprom) | ||
