7f522461d2
Functions added, but not executed during wic image creation include: _get_staging_libdir * Finds target lib directory if for some reason STAGING_LIBDIR isn't set. _do_configure_grub * Will search for a grub configuration passed via bootloader --configfile. If not found build a default one which searches for partition that contains the given the kernel name via grub search module. _do_prepare_grub 1. Sets default values for GRUB_MKIMAGE_FORMAT_PC and GRUB_PREFIX_PATH if none specified. Both variables are required by grub-mkimage. * GRUB_MKIMAGE_FORMAT_PC is used to define target platform. * GRUB_PREFIX_PATH is used to define which directory grub config and modules are going to reside in. 2. Generates grub config to embed into core.img. This config is used to search for partition containing grub config. 3. Creates a custom core.img or grub stage 1.5 with an embedded grub config. 4. Copies all the target built grub modules into GRUB_PREFIX_PATH directory. 5. Creates boot partition _do_install_grub 1. dd target platform specific boot.img to the first 0-440 bytes of the resulting wic image. dd grub stage 1 to wic image. If this wics plugin is used with GPT as partition table format and grub selected as bootloader it's more than likely for grub hybrid booting because bootimg_efi plugin should and more than likely will be used in that case. So, boot.img may be dd regardless if partition table format is GPT or MBR. 2. dd custom core.img (grub stage 1.5) with embedded configuration to the resulting wic image starting at byte 512 up to sizeof(core.img). 3. Both boot.img and core.img are required for legacy bios boot. See grub Wiki for more details on boot.img and core.img. https://en.wikipedia.org/wiki/GNU_GRUB Commit also imports python modules required by the above implemented functions. (From OE-Core rev: 27c56962f47303cf49a4cf641e85239e4d7779b5) Signed-off-by: Vincent Davis Jr <vince@underview.tech> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> |
||
|---|---|---|
| bitbake | ||
| contrib | ||
| documentation | ||
| meta | ||
| meta-poky | ||
| meta-selftest | ||
| meta-skeleton | ||
| meta-yocto-bsp | ||
| scripts | ||
| .b4-config | ||
| .gitignore | ||
| .templateconf | ||
| LICENSE | ||
| LICENSE.GPL-2.0-only | ||
| LICENSE.MIT | ||
| MAINTAINERS.md | ||
| MEMORIAM | ||
| oe-init-build-env | ||
| README.hardware.md | ||
| README.md | ||
| README.OE-Core.md | ||
| README.poky.md | ||
| README.qemu.md | ||
| SECURITY.md | ||
Poky
Poky is an integration of various components to form a pre-packaged build system and development environment which is used as a development and validation tool by the Yocto Project. It features support for building customised embedded style device images and custom containers. There are reference demo images ranging from X11/GTK+ to Weston, commandline and more. The system supports cross-architecture application development using QEMU emulation and a standalone toolchain and SDK suitable for IDE integration.
Additional information on the specifics of hardware that Poky supports is available in README.hardware. Further hardware support can easily be added in the form of BSP layers which extend the systems capabilities in a modular way. Many layers are available and can be found through the layer index.
As an integration layer Poky consists of several upstream projects such as BitBake, OpenEmbedded-Core, Yocto documentation, the 'meta-yocto' layer which has configuration and hardware support components. These components are all part of the Yocto Project and OpenEmbedded ecosystems.
The Yocto Project has extensive documentation about the system including a reference manual which can be found at https://docs.yoctoproject.org/
OpenEmbedded is the build architecture used by Poky and the Yocto project. For information about OpenEmbedded, see the OpenEmbedded website.
Contribution Guidelines
Please refer to our contributor guide here: https://docs.yoctoproject.org/dev/contributor-guide/ for full details on how to submit changes.
Where to Send Patches
As Poky is an integration repository (built using a tool called combo-layer), patches against the various components should be sent to their respective upstreams:
OpenEmbedded-Core (files in meta/, meta-selftest/, meta-skeleton/, scripts/):
- Git repository: https://git.openembedded.org/openembedded-core/
- Mailing list: openembedded-core@lists.openembedded.org
BitBake (files in bitbake/):
- Git repository: https://git.openembedded.org/bitbake/
- Mailing list: bitbake-devel@lists.openembedded.org
Documentation (files in documentation/):
- Git repository: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/
- Mailing list: docs@lists.yoctoproject.org
meta-yocto (files in meta-poky/, meta-yocto-bsp/):
- Git repository: https://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto
- Mailing list: poky@lists.yoctoproject.org
If in doubt, check the openembedded-core git repository for the content you intend to modify as most files are from there unless clearly one of the above categories. Before sending, be sure the patches apply cleanly to the current git repository branch in question.