Yocto
On this page
from reddit
Yocto isn’t something you “put on a core” it’s a build system you run on a desktop that produces Linux distros. Just wanted to clarify that as a lot of people think yocto is a Linux distro and get confused very quickly. If you have no experience with Linux (I’m assuming so since you said you want to learn Linux as well) then you might want to take some time to learn things like a bash shell, systemv vs systemd, bash scripting and python if you don’t already know it. Once you learn that, then you might be ready to start with yocto. Variscite, toradex, stm32mp1 all have pretty decent documentation and hardware to get you started.
from reddit
Yocto is not a distro, the Yocto project is a build system for embedded Linux. It’s a way of installing just enough functionality to create a purpose-built machine. The image goes on an SD card for testing, and later on eMMC for production systems (for better speed). Honestly, unless you want to learn to do embedded development, it’s of limited use.
I’ve been using it for a few years now building kiosk systems, including openGL graphics (wanting to switch to Vulkan). It does not “co-exist” with other O/S, it creates a Linux O/S image for installation on the target device. My build system is a Linux workstation for editing the recipes, an older Linux multi-CPU server (strictly for the build process itself), and embedded board(s) for testing. But that’s for convenience, a single laptop and target board would get you started.
If you want to learn to use Yocto, I suggest a Raspberry Pi (if you lose interest in Yocto, you can repurpose the Pi using Raspberry Pi OS or similar).
If you are more serious about embedded dev, some eBay sellers have the BeagleBone Black Rev C which can be a reasonably-priced target as well.
I will caution you that while Yocto is not horribly hard to use, it’s a step-by-step process to learn it, not a “one and done.”
Oh, and I also do FreeRTOS, on ARM M4, using a separate ST Micro MCU on the same embedded board talking to an ARM A15. Because as much as I love Linux, it sucks swamp water at real-time work. And QNX ain’t cheap.
Best of luck.
from reddit
I was in your shoes about a year ago. I think the general recommendation from the Yocto Project is to find a source that does something similar to your needs and copy/modify it. Our board vendor provided their own board-support package (BSP) layer, which was useful to get started. Start your own layer repo and don’t worry about getting it right the first time.
One thing that still causes me grief is the definition of new terms they throw around. The following are my unofficial take on the terms:
Recipe: Essentially a script to build something, much like a cooking recipe. A recipe tells Yocto how to produce some software component (and sometimes multiple components watch out for this). They follow a standard set of steps - fetch source, extract source, configure build, perform build, install build, post-install scripts.
Package: Output from a recipe, probably wrapped in whatever archival format your chosen Package Manager employs (.deb, .rpm, etc).
Layer: A collection of Yocto "metadata", usually at least recipes, and usually in the form of a git repo with the naming convention "meta-*". Usually the git repo will have branches of support for specific Yocto versions by codename (fido, dizzy, morty, pyro, etc). There are special types of layers - Board-Support Package (BSP) layers, Distro layers - but your exposure to these will probably be limited at the onset.
Distro: An abstraction of the finished system, basically a selection of software components not yet tailored for your specific hardware. The reference distro, Poky, for instance may be tweaked by machines/images definitions. An x86 build of Poky will obviously output binaries with different instructions than an arm build, for instance, but beyond that they may require different config/data files as well.
Image: A concrete system, almost always a disk image ready to be flashed/extracted. Common formats are .sdcard, .tar.gz, .dd, among others.
Don’t be afraid to break things, and read recipes and errors very carefully. They are dense, but usually point you towards the solution.
from reddit
Omg I laugh so hard when I saw your comment about its username haha ! And anyway, Yocto is quite hard to dig into (managing distro and few images into a company for their next products, I am all on my own, and the company is not even familiar with linux…). So yeah this is quite time consuming to understand how everything work, between machine/distro/image, how to segregate things and everything… I would suggest you to build the minimalist image you can have (something like core-image-minimal), and get through it starting from the image recipe, seeing keywords, dependencies, inheritance etc… and check this with the mega manual from the website. It will give you at least a good idea of how is structured a yocto project, and the different solutions there are to exploit
basics
https://github.com/jynik/ready-set-yocto
simple setup
https://github.com/bootlin/simplest-yocto-setup