Name Date Size #Lines LOC

..--

bitbake/H05-Jun-2025-130,827102,396

contrib/H05-Jun-2025-160122

documentation/H05-Jun-2025-65,00150,838

meta/H05-Jun-2025-431,411362,670

meta-poky/H05-Jun-2025-3,4133,069

meta-selftest/H05-Jun-2025-1,5881,165

meta-skeleton/H05-Jun-2025-1,037726

meta-yocto-bsp/H05-Jun-2025-918606

scripts/H05-Jun-2025-41,75931,946

.templateconfH A D05-Jun-202565 32

LICENSEH A D05-Jun-2025834 2115

LICENSE.GPL-2.0-onlyH A D05-Jun-202515 KiB289242

LICENSE.MITH A D05-Jun-20251.3 KiB2620

MAINTAINERS.mdH A D05-Jun-20252.2 KiB7356

MEMORIAMH A D05-Jun-2025244 64

MakefileH A D05-Jun-20251.2 KiB3621

README.OE-Core.mdH A D05-Jun-2025791 3019

README.hardware.mdH A D05-Jun-20259.7 KiB266178

README.mdH A D05-Jun-20253.6 KiB8560

README.poky.mdH A D05-Jun-20253.6 KiB8560

README.qemu.mdH A D05-Jun-2025529 1612

oe-init-build-envH A D05-Jun-20251.3 KiB5432

README.OE-Core.md

1OpenEmbedded-Core
2=================
3
4OpenEmbedded-Core is a layer containing the core metadata for current versions
5of OpenEmbedded. It is distro-less (can build a functional image with
6DISTRO = "nodistro") and contains only emulated machine support.
7
8For information about OpenEmbedded, see the OpenEmbedded website:
9    https://www.openembedded.org/
10
11The Yocto Project has extensive documentation about OE including a reference manual
12which can be found at:
13    https://docs.yoctoproject.org/
14
15
16Contributing
17------------
18
19Please refer to
20https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
21for guidelines on how to submit patches.
22
23Mailing list:
24
25    https://lists.openembedded.org/g/openembedded-core
26
27Source code:
28
29    https://git.openembedded.org/openembedded-core/
30

README.hardware.md

1                  Yocto Project Hardware Reference BSPs README
2                  ============================================
3
4This file gives details about using the Yocto Project hardware reference BSPs.
5The machines supported can be seen in the conf/machine/ directory and are listed
6below. There is one per supported hardware architecture and these are primarily
7used to validate that the Yocto Project works on the hardware arctectures of
8those machines.
9
10If you are in doubt about using Poky/OpenEmbedded/Yocto Project with your hardware,
11consult the documentation for your board/device.
12
13Support for additional devices is normally added by adding BSP layers to your
14configuration. For more information please see the Yocto Board Support Package
15(BSP) Developer's Guide - documentation source is in documentation/bspguide or
16download the PDF from:
17
18   https://docs.yoctoproject.org/
19
20Note that these reference BSPs use the linux-yocto kernel and in general don't
21pull in binary module support for the platforms. This means some device functionality
22may be limited compared to a 'full' BSP which may be available.
23
24
25Hardware Reference Boards
26=========================
27
28The 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
34For more information see the board's section below. The appropriate MACHINE
35variable value corresponding to the board is given in brackets.
36
37Reference Board Maintenance
38===========================
39
40Send pull requests, patches, comments or questions about meta-yocto-bsps to poky@lists.yoctoproject.org
41
42Maintainers: Kevin Hao <kexin.hao@windriver.com>
43             Bruce Ashfield <bruce.ashfield@gmail.com>
44
45Consumer Devices
46================
47
48The 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
53For more information see the device's section below. The appropriate MACHINE
54variable value corresponding to the device is given in brackets.
55
56
57
58                      Specific Hardware Documentation
59                      ===============================
60
61
62Intel x86 based PCs and devices (genericx86*)
63=============================================
64
65The genericx86 and genericx86-64 MACHINE are tested on the following platforms:
66
67Intel 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
72Intel 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
79and is likely to work on many unlisted Atom/Core/Xeon based devices. The MACHINE
80type supports ethernet, wifi, sound, and Intel/vesa graphics by default in
81addition to common PC input devices, busses, and so on.
82
83Depending on the device, it can boot from a traditional hard-disk, a USB device,
84or over the network. Writing generated images to physical media is
85straightforward with a caveat for USB devices. The following examples assume the
86target boot device is /dev/sdb, be sure to verify this and use the correct
87device as the following commands are run as root and are not reversable.
88
89USB 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
122Texas Instruments Beaglebone (beaglebone-yocto)
123===============================================
124
125The Beaglebone is an ARM Cortex-A8 development board with USB, Ethernet, 2D/3D
126accelerated graphics, audio, serial, JTAG, and SD/MMC. The Black adds a faster
127CPU, more RAM, eMMC flash and a micro HDMI port. The beaglebone MACHINE is
128tested on the following platforms:
129
130  o Beaglebone Black A6
131  o Beaglebone A6 (the original "White" model)
132
133The Beaglebone Black has eMMC, while the White does not. Pressing the USER/BOOT
134button when powering on will temporarily change the boot order. But for the sake
135of simplicity, these instructions assume you have erased the eMMC on the Black,
136so its boot behavior matches that of the White and boots off of SD card. To do
137this, issue the following commands from the u-boot prompt:
138
139    # mmc dev 1
140    # mmc erase 0 512
141
142To further tailor these instructions for your board, please refer to the
143documentation at http://www.beagleboard.org/bone and http://www.beagleboard.org/black
144
145From 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
157Ubiquiti Networks EdgeRouter Lite (edgerouter)
158==============================================
159
160The 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
162internal USB pendrive for storage.
163
164Setup instructions
165------------------
166
167You 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
172If 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
179Build an image (e.g. core-image-minimal) using "edgerouter" as the MACHINE.
180In the following instruction it is based on core-image-minimal. Another target
181may be similiar with it.
182
183--- Booting from NFS root / kernel via TFTP ---
184
185Load 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
211To boot from the USB disk, you either need to remove it from the edgerouter
212box and populate it from another computer, or use a previously booted NFS
213image and populate from the edgerouter itself.
214
215Type 1: Use partitioned image
216-----------------------------
217
218Steps:
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
229Type 2: NFS
230-----------
231
232Note: 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)
266

README.md

1Poky
2====
3
4Poky is an integration of various components to form a pre-packaged
5build system and development environment which is used as a development and
6validation tool by the [Yocto Project](https://www.yoctoproject.org/). It
7features support for building customised embedded style device images
8and custom containers. There are reference demo images ranging from X11/GTK+
9 to Weston, commandline and more. The system supports cross-architecture
10application development using QEMU emulation and a standalone toolchain and
11SDK suitable for IDE integration.
12
13Additional information on the specifics of hardware that Poky supports
14is available in README.hardware. Further hardware support can easily be added
15in the form of BSP layers which extend the systems capabilities in a modular way.
16Many layers are available and can be found through the
17[layer index](https://layers.openembedded.org/).
18
19As an integration layer Poky consists of several upstream projects such as
20[BitBake](https://git.openembedded.org/bitbake/),
21[OpenEmbedded-Core](https://git.openembedded.org/openembedded-core/),
22[Yocto documentation](https://git.yoctoproject.org/cgit.cgi/yocto-docs/),
23the '[meta-yocto](https://git.yoctoproject.org/cgit.cgi/meta-yocto/)' layer
24which has configuration and hardware support components. These components
25are all part of the Yocto Project and OpenEmbedded ecosystems.
26
27The Yocto Project has extensive documentation about the system including a
28reference manual which can be found at <https://docs.yoctoproject.org/>
29
30OpenEmbedded is the build architecture used by Poky and the Yocto project.
31For information about OpenEmbedded, see the
32[OpenEmbedded website](https://www.openembedded.org/).
33
34Contribution Guidelines
35-----------------------
36
37The project works using a mailing list patch submission process. Patches
38should be sent to the mailing list for the repository the components
39originate from (see below). Throughout the Yocto Project, the README
40files in the component in question should detail where to send patches,
41who the maintainers are and where bugs should be reported.
42
43A guide to submitting patches to OpenEmbedded is available at:
44
45<https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded>
46
47There is good documentation on how to write/format patches at:
48
49<https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines>
50
51Where to Send Patches
52---------------------
53
54As Poky is an integration repository (built using a tool called combo-layer),
55patches against the various components should be sent to their respective
56upstreams:
57
58OpenEmbedded-Core (files in meta/, meta-selftest/, meta-skeleton/, scripts/):
59
60- Git repository: <https://git.openembedded.org/openembedded-core/>
61- Mailing list: openembedded-core@lists.openembedded.org
62
63BitBake (files in bitbake/):
64
65- Git repository: <https://git.openembedded.org/bitbake/>
66- Mailing list: bitbake-devel@lists.openembedded.org
67
68Documentation (files in documentation/):
69
70- Git repository: <https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/>
71- Mailing list: docs@lists.yoctoproject.org
72
73meta-yocto (files in meta-poky/, meta-yocto-bsp/):
74
75- Git repository: <https://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto>
76- Mailing list: poky@lists.yoctoproject.org
77
78If in doubt, check the openembedded-core git repository for the content you
79intend to modify as most files are from there unless clearly one of the above
80categories. Before sending, be sure the patches apply cleanly to the current
81git repository branch in question.
82
83[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/765/badge)](https://bestpractices.coreinfrastructure.org/projects/765)
84
85

README.poky.md

1Poky
2====
3
4Poky is an integration of various components to form a pre-packaged
5build system and development environment which is used as a development and
6validation tool by the [Yocto Project](https://www.yoctoproject.org/). It
7features support for building customised embedded style device images
8and custom containers. There are reference demo images ranging from X11/GTK+
9 to Weston, commandline and more. The system supports cross-architecture
10application development using QEMU emulation and a standalone toolchain and
11SDK suitable for IDE integration.
12
13Additional information on the specifics of hardware that Poky supports
14is available in README.hardware. Further hardware support can easily be added
15in the form of BSP layers which extend the systems capabilities in a modular way.
16Many layers are available and can be found through the
17[layer index](https://layers.openembedded.org/).
18
19As an integration layer Poky consists of several upstream projects such as
20[BitBake](https://git.openembedded.org/bitbake/),
21[OpenEmbedded-Core](https://git.openembedded.org/openembedded-core/),
22[Yocto documentation](https://git.yoctoproject.org/cgit.cgi/yocto-docs/),
23the '[meta-yocto](https://git.yoctoproject.org/cgit.cgi/meta-yocto/)' layer
24which has configuration and hardware support components. These components
25are all part of the Yocto Project and OpenEmbedded ecosystems.
26
27The Yocto Project has extensive documentation about the system including a
28reference manual which can be found at <https://docs.yoctoproject.org/>
29
30OpenEmbedded is the build architecture used by Poky and the Yocto project.
31For information about OpenEmbedded, see the
32[OpenEmbedded website](https://www.openembedded.org/).
33
34Contribution Guidelines
35-----------------------
36
37The project works using a mailing list patch submission process. Patches
38should be sent to the mailing list for the repository the components
39originate from (see below). Throughout the Yocto Project, the README
40files in the component in question should detail where to send patches,
41who the maintainers are and where bugs should be reported.
42
43A guide to submitting patches to OpenEmbedded is available at:
44
45<https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded>
46
47There is good documentation on how to write/format patches at:
48
49<https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines>
50
51Where to Send Patches
52---------------------
53
54As Poky is an integration repository (built using a tool called combo-layer),
55patches against the various components should be sent to their respective
56upstreams:
57
58OpenEmbedded-Core (files in meta/, meta-selftest/, meta-skeleton/, scripts/):
59
60- Git repository: <https://git.openembedded.org/openembedded-core/>
61- Mailing list: openembedded-core@lists.openembedded.org
62
63BitBake (files in bitbake/):
64
65- Git repository: <https://git.openembedded.org/bitbake/>
66- Mailing list: bitbake-devel@lists.openembedded.org
67
68Documentation (files in documentation/):
69
70- Git repository: <https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/>
71- Mailing list: docs@lists.yoctoproject.org
72
73meta-yocto (files in meta-poky/, meta-yocto-bsp/):
74
75- Git repository: <https://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto>
76- Mailing list: poky@lists.yoctoproject.org
77
78If in doubt, check the openembedded-core git repository for the content you
79intend to modify as most files are from there unless clearly one of the above
80categories. Before sending, be sure the patches apply cleanly to the current
81git repository branch in question.
82
83[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/765/badge)](https://bestpractices.coreinfrastructure.org/projects/765)
84
85

README.qemu.md

1QEMU Emulation Targets
2======================
3
4To simplify development, the build system supports building images to
5work with the QEMU emulator in system emulation mode. Several architectures
6are currently supported in 32 and 64 bit variants:
7
8  * ARM (qemuarm + qemuarm64)
9  * x86 (qemux86 + qemux86-64)
10  * PowerPC (qemuppc only)
11  * MIPS (qemumips + qemumips64)
12
13Use of the QEMU images is covered in the Yocto Project Reference Manual.
14The appropriate MACHINE variable value corresponding to the target is given
15in brackets.
16