diff options
| author | Richard Purdie <richard.purdie@linuxfoundation.org> | 2021-06-16 16:32:56 +0100 |
|---|---|---|
| committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2021-06-16 16:33:18 +0100 |
| commit | 0764538eb7dfab3e6bc60c30105fb4f83aa96ec3 (patch) | |
| tree | c05220ecfb22979e4e3fefdec9d8e200d705d592 /meta-yocto-bsp/README.hardware.md | |
| parent | ff6b8af378747d3cd14163d55f836446f0265b16 (diff) | |
| download | poky-0764538eb7dfab3e6bc60c30105fb4f83aa96ec3.tar.gz | |
README: Move to using markdown as the format
(From meta-yocto rev: d397ed754c04b8ef02b01ae4b439610ede12d9d9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta-yocto-bsp/README.hardware.md')
| -rw-r--r-- | meta-yocto-bsp/README.hardware.md | 265 |
1 files changed, 265 insertions, 0 deletions
diff --git a/meta-yocto-bsp/README.hardware.md b/meta-yocto-bsp/README.hardware.md new file mode 100644 index 0000000000..9803af006a --- /dev/null +++ b/meta-yocto-bsp/README.hardware.md | |||
| @@ -0,0 +1,265 @@ | |||
| 1 | Yocto Project Hardware Reference BSPs README | ||
| 2 | ============================================ | ||
| 3 | |||
| 4 | This file gives details about using the Yocto Project hardware reference BSPs. | ||
| 5 | The machines supported can be seen in the conf/machine/ directory and are listed | ||
| 6 | below. There is one per supported hardware architecture and these are primarily | ||
| 7 | used to validate that the Yocto Project works on the hardware arctectures of | ||
| 8 | those machines. | ||
| 9 | |||
| 10 | If you are in doubt about using Poky/OpenEmbedded/Yocto Project with your hardware, | ||
| 11 | consult the documentation for your board/device. | ||
| 12 | |||
| 13 | Support for additional devices is normally added by adding BSP layers to your | ||
| 14 | configuration. For more information please see the Yocto Board Support Package | ||
| 15 | (BSP) Developer's Guide - documentation source is in documentation/bspguide or | ||
| 16 | download the PDF from: | ||
| 17 | |||
| 18 | http://yoctoproject.org/documentation | ||
| 19 | |||
| 20 | Note that these reference BSPs use the linux-yocto kernel and in general don't | ||
| 21 | pull in binary module support for the platforms. This means some device functionality | ||
| 22 | may be limited compared to a 'full' BSP which may be available. | ||
| 23 | |||
| 24 | |||
| 25 | Hardware Reference Boards | ||
| 26 | ========================= | ||
| 27 | |||
| 28 | The following boards are supported by the meta-yocto-bsp layer: | ||
| 29 | |||
| 30 | * Texas Instruments Beaglebone (beaglebone-yocto) | ||
| 31 | * Ubiquiti Networks EdgeRouter Lite (edgerouter) | ||
| 32 | * General IA platforms (genericx86 and genericx86-64) | ||
| 33 | |||
| 34 | For more information see the board's section below. The appropriate MACHINE | ||
| 35 | variable value corresponding to the board is given in brackets. | ||
| 36 | |||
| 37 | Reference Board Maintenance | ||
| 38 | =========================== | ||
| 39 | |||
| 40 | Send pull requests, patches, comments or questions about meta-yocto-bsps to poky@yoctoproject.org | ||
| 41 | |||
| 42 | Maintainers: Kevin Hao <kexin.hao@windriver.com> | ||
| 43 | Bruce Ashfield <bruce.ashfield@windriver.com> | ||
| 44 | |||
| 45 | Consumer Devices | ||
| 46 | ================ | ||
| 47 | |||
| 48 | The following consumer devices are supported by the meta-yocto-bsp layer: | ||
| 49 | |||
| 50 | * Intel x86 based PCs and devices (genericx86) | ||
| 51 | * Ubiquiti Networks EdgeRouter Lite (edgerouter) | ||
| 52 | |||
| 53 | For more information see the device's section below. The appropriate MACHINE | ||
| 54 | variable value corresponding to the device is given in brackets. | ||
| 55 | |||
| 56 | |||
| 57 | |||
| 58 | Specific Hardware Documentation | ||
| 59 | =============================== | ||
| 60 | |||
| 61 | |||
| 62 | Intel x86 based PCs and devices (genericx86*) | ||
| 63 | ============================================= | ||
| 64 | |||
| 65 | The genericx86 and genericx86-64 MACHINE are tested on the following platforms: | ||
| 66 | |||
| 67 | Intel Xeon/Core i-Series: | ||
| 68 | + Intel NUC5 Series - ix-52xx Series SOC (Broadwell) | ||
| 69 | + Intel NUC6 Series - ix-62xx Series SOC (Skylake) | ||
| 70 | + Intel Shumway Xeon Server | ||
| 71 | |||
| 72 | Intel Atom platforms: | ||
| 73 | + MinnowBoard MAX - E3825 SOC (Bay Trail) | ||
| 74 | + MinnowBoard MAX - Turbot (ADI Engineering) - E3826 SOC (Bay Trail) | ||
| 75 | - These boards can be either 32bot or 64bit modes depending on firmware | ||
| 76 | - See minnowboard.org for details | ||
| 77 | + Intel Braswell SOC | ||
| 78 | |||
| 79 | and is likely to work on many unlisted Atom/Core/Xeon based devices. The MACHINE | ||
| 80 | type supports ethernet, wifi, sound, and Intel/vesa graphics by default in | ||
| 81 | addition to common PC input devices, busses, and so on. | ||
| 82 | |||
| 83 | Depending on the device, it can boot from a traditional hard-disk, a USB device, | ||
| 84 | or over the network. Writing generated images to physical media is | ||
| 85 | straightforward with a caveat for USB devices. The following examples assume the | ||
| 86 | target boot device is /dev/sdb, be sure to verify this and use the correct | ||
| 87 | device as the following commands are run as root and are not reversable. | ||
| 88 | |||
| 89 | USB Device: | ||
| 90 | 1. Build a live image. This image type consists of a simple filesystem | ||
| 91 | without a partition table, which is suitable for USB keys, and with the | ||
| 92 | default setup for the genericx86 machine, this image type is built | ||
| 93 | automatically for any image you build. For example: | ||
| 94 | |||
| 95 | $ bitbake core-image-minimal | ||
| 96 | |||
| 97 | 2. Use the "dd" utility to write the image to the raw block device. For | ||
| 98 | example: | ||
| 99 | |||
| 100 | # dd if=core-image-minimal-genericx86.hddimg of=/dev/sdb | ||
| 101 | |||
| 102 | If the device fails to boot with "Boot error" displayed, or apparently | ||
| 103 | stops just after the SYSLINUX version banner, it is likely the BIOS cannot | ||
| 104 | understand the physical layout of the disk (or rather it expects a | ||
| 105 | particular layout and cannot handle anything else). There are two possible | ||
| 106 | solutions to this problem: | ||
| 107 | |||
| 108 | 1. Change the BIOS USB Device setting to HDD mode. The label will vary by | ||
| 109 | device, but the idea is to force BIOS to read the Cylinder/Head/Sector | ||
| 110 | geometry from the device. | ||
| 111 | |||
| 112 | 2. Use a ".wic" image with an EFI partition | ||
| 113 | |||
| 114 | a) With a default grub-efi bootloader: | ||
| 115 | # dd if=core-image-minimal-genericx86-64.wic of=/dev/sdb | ||
| 116 | |||
| 117 | b) Use systemd-boot instead | ||
| 118 | - Build an image with EFI_PROVIDER="systemd-boot" then use the above | ||
| 119 | dd command to write the image to a USB stick. | ||
| 120 | |||
| 121 | |||
| 122 | Texas Instruments Beaglebone (beaglebone-yocto) | ||
| 123 | =============================================== | ||
| 124 | |||
| 125 | The Beaglebone is an ARM Cortex-A8 development board with USB, Ethernet, 2D/3D | ||
| 126 | accelerated graphics, audio, serial, JTAG, and SD/MMC. The Black adds a faster | ||
| 127 | CPU, more RAM, eMMC flash and a micro HDMI port. The beaglebone MACHINE is | ||
| 128 | tested on the following platforms: | ||
| 129 | |||
| 130 | o Beaglebone Black A6 | ||
| 131 | o Beaglebone A6 (the original "White" model) | ||
| 132 | |||
| 133 | The Beaglebone Black has eMMC, while the White does not. Pressing the USER/BOOT | ||
| 134 | button when powering on will temporarily change the boot order. But for the sake | ||
| 135 | of simplicity, these instructions assume you have erased the eMMC on the Black, | ||
| 136 | so its boot behavior matches that of the White and boots off of SD card. To do | ||
| 137 | this, issue the following commands from the u-boot prompt: | ||
| 138 | |||
| 139 | # mmc dev 1 | ||
| 140 | # mmc erase 0 512 | ||
| 141 | |||
| 142 | To further tailor these instructions for your board, please refer to the | ||
| 143 | documentation at http://www.beagleboard.org/bone and http://www.beagleboard.org/black | ||
| 144 | |||
| 145 | From a Linux system with access to the image files perform the following steps: | ||
| 146 | |||
| 147 | 1. Build an image. For example: | ||
| 148 | |||
| 149 | $ bitbake core-image-minimal | ||
| 150 | |||
| 151 | 2. Use the "dd" utility to write the image to the SD card. For example: | ||
| 152 | |||
| 153 | # dd if=core-image-minimal-beaglebone-yocto.wic of=/dev/sdb | ||
| 154 | |||
| 155 | 3. Insert the SD card into the Beaglebone and boot the board. | ||
| 156 | |||
| 157 | Ubiquiti Networks EdgeRouter Lite (edgerouter) | ||
| 158 | ============================================== | ||
| 159 | |||
| 160 | The EdgeRouter Lite is part of the EdgeMax series. It is a MIPS64 router | ||
| 161 | (based on the Cavium Octeon processor) with 512MB of RAM, which uses an | ||
| 162 | internal USB pendrive for storage. | ||
| 163 | |||
| 164 | Setup instructions | ||
| 165 | ------------------ | ||
| 166 | |||
| 167 | You will need the following: | ||
| 168 | * RJ45 -> serial ("rollover") cable connected from your PC to the CONSOLE | ||
| 169 | port on the device | ||
| 170 | * Ethernet connected to the first ethernet port on the board | ||
| 171 | |||
| 172 | If using NFS as part of the setup process, you will also need: | ||
| 173 | * NFS root setup on your workstation | ||
| 174 | * TFTP server installed on your workstation (if fetching the kernel from | ||
| 175 | TFTP, see below). | ||
| 176 | |||
| 177 | --- Preparation --- | ||
| 178 | |||
| 179 | Build an image (e.g. core-image-minimal) using "edgerouter" as the MACHINE. | ||
| 180 | In the following instruction it is based on core-image-minimal. Another target | ||
| 181 | may be similiar with it. | ||
| 182 | |||
| 183 | --- Booting from NFS root / kernel via TFTP --- | ||
| 184 | |||
| 185 | Load the kernel, and boot the system as follows: | ||
| 186 | |||
| 187 | 1. Get the kernel (vmlinux) file from the tmp/deploy/images/edgerouter | ||
| 188 | directory, and make them available on your TFTP server. | ||
| 189 | |||
| 190 | 2. Connect the board's first serial port to your workstation and then start up | ||
| 191 | your favourite serial terminal so that you will be able to interact with | ||
| 192 | the serial console. If you don't have a favourite, picocom is suggested: | ||
| 193 | |||
| 194 | $ picocom /dev/ttyS0 -b 115200 | ||
| 195 | |||
| 196 | 3. Power up or reset the board and press a key on the terminal when prompted | ||
| 197 | to get to the U-Boot command line | ||
| 198 | |||
| 199 | 4. Set up the environment in U-Boot: | ||
| 200 | |||
| 201 | => setenv ipaddr <board ip> | ||
| 202 | => setenv serverip <tftp server ip> | ||
| 203 | |||
| 204 | 5. Download the kernel and boot: | ||
| 205 | |||
| 206 | => tftp tftp $loadaddr vmlinux | ||
| 207 | => 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) | ||
| 208 | |||
| 209 | --- Booting from USB disk --- | ||
| 210 | |||
| 211 | To boot from the USB disk, you either need to remove it from the edgerouter | ||
| 212 | box and populate it from another computer, or use a previously booted NFS | ||
| 213 | image and populate from the edgerouter itself. | ||
| 214 | |||
| 215 | Type 1: Use partitioned image | ||
| 216 | ----------------------------- | ||
| 217 | |||
| 218 | Steps: | ||
| 219 | |||
| 220 | 1. Remove the USB disk from the edgerouter and insert it into a computer | ||
| 221 | that has access to your build artifacts. | ||
| 222 | |||
| 223 | 2. Flash the image. | ||
| 224 | |||
| 225 | # dd if=core-image-minimal-edgerouter.wic of=/dev/sdb | ||
| 226 | |||
| 227 | 3. Insert USB disk into the edgerouter and boot it. | ||
| 228 | |||
| 229 | Type 2: NFS | ||
| 230 | ----------- | ||
| 231 | |||
| 232 | Note: If you place the kernel on the ext3 partition, you must re-create the | ||
| 233 | ext3 filesystem, since the factory u-boot can only handle 128 byte inodes and | ||
| 234 | cannot read the partition otherwise. | ||
| 235 | |||
| 236 | These boot instructions assume that you have recreated the ext3 filesystem with | ||
| 237 | 128 byte inodes, you have an updated uboot or you are running and image capable | ||
| 238 | of making the filesystem on the board itself. | ||
| 239 | |||
| 240 | |||
| 241 | 1. Boot from NFS root | ||
| 242 | |||
| 243 | 2. Mount the USB disk partition 2 and then extract the contents of | ||
| 244 | tmp/deploy/core-image-XXXX.tar.bz2 into it. | ||
| 245 | |||
| 246 | Before starting, copy core-image-minimal-xxx.tar.bz2 and vmlinux into | ||
| 247 | rootfs path on your workstation. | ||
| 248 | |||
| 249 | and then, | ||
| 250 | |||
| 251 | # mount /dev/sda2 /media/sda2 | ||
| 252 | # tar -xvjpf core-image-minimal-XXX.tar.bz2 -C /media/sda2 | ||
| 253 | # cp vmlinux /media/sda2/boot/vmlinux | ||
| 254 | # umount /media/sda2 | ||
| 255 | # reboot | ||
| 256 | |||
| 257 | 3. Reboot the board and press a key on the terminal when prompted to get to the U-Boot | ||
| 258 | command line: | ||
| 259 | |||
| 260 | # reboot | ||
| 261 | |||
| 262 | 4. Load the kernel and boot: | ||
| 263 | |||
| 264 | => ext2load usb 0:2 $loadaddr boot/vmlinux | ||
| 265 | => bootoctlinux $loadaddr coremask=0x3 root=/dev/sda2 rw rootwait mtdparts=phys_mapped_flash:512k(boot0),512k(boot1),64k@3072k(eeprom) | ||
