Embedded System running on Linux

[BlogRahul]

Hello

I want to learn Linux for Embedded System. I need someone who worked on embedded linux or who know about it. I found linux runs on Embedded System. There are so many varients of Linux. Please suggest me which varient of linux is more papular for Embedded system

Welcome for further suggestions   

[DiTBho]

it's like when people point a dog and say "pit-bull": what does it mean?!?
a hunting dog is a "pit-bull", but there are several types.

I don't know, maybe "OpenWRT" for routers? 

It's how I learned it. 21 Years ago.

(they still call it "vodka", but actually it's a "pit-bull"  )

[alexanderbrevig]

https://jaycarlson.net/embedded-linux/

[FlyingDutch]

Hello,

Yocto is a standard Linux distro for embedded systems. But it is rather a build system and is quite complex. Many vendors have their own standards: for Example Xilinx has "PetaLinux", ST "OpenSTLinux".
I personally made few "Distros" based on meta-distribution "Gentoo" Linux (for ARMs CPUs). For RPI one can use "Raspbian OS" (if we accept that RPI is a embedded system).

Best Regards

[DiTBho]

I personally made few "Distros" based on meta-distribution "Gentoo" Linux (for ARMs CPUs)

Based on stage3s, or based on Catalyst?

[rstofer]

I consider Linux (Raspian) on the Raspberry Pi to be an embedded system.  Maybe it isn't so deeply embedded when I have a mouse, keyboard and monitor attached but most embedded systems have some form of user interaction.  Maybe SSH or VNC counts...

To get started, I recommend the Freenove Ultimate Starter Kit (doesn't include Pi)

https://www.amazon.com/Freenove-Raspberry-Processing-Tutorials-Components/dp/B06W54L7B5

The tutorials are excellent and all of the code is provided.  Highly recommended as a place to start.  Sooner or later, every embedded system has to talk to something and the included gadgets might just be on the list.  Keypad, 7 segment displays, LEDs, etc...

BTW:  You do the experiments using the same Pi as you run the tutorials.  You'll be Linux all the way because there is no other machine involved (unless you use SSH or VNC from elsewhere).

Here's where it gets really cool:  I use the Digilent Analog Discovery 2 for a lot of my experiments and the Waveforms software also runs on the same Pi with the tutorial and project.  I get to see what the machine is doing while working on the machine itself.

You can get the tutorial.pdf file here:  https://github.com/Freenove/Freenove_Ultimate_Starter_Kit_for_Raspberry_Pi

[FlyingDutch]

I personally made few "Distros" based on meta-distribution "Gentoo" Linux (for ARMs CPUs)

Based on stage3s, or based on Catalyst?

Based on stage0 - but it was about 2012 year. I built almost all from sources (ARM CPU) - based on very old Gentoo tutorial.

Best Regards

[nctnico]

Do yourself a favour and use a distribution like Debian or Ubuntu. Buildroot and (worse) Yocto have a steep learning curve and are only to be considered if you are constrained for space due to cost savings. Expect to need at least 6 months fulltime to learn all the in&outs of Buildroot.

[DiTBho]

Buildroot and (worse) Yocto have a steep learning curve and ..

Despite the effort of fantastic and very smart people like "Vapier", Gentoo CrossDev has never worked like expected, and by the end of 2021 it still failed on cross-emerging, at least with these (which are my personal domain of interests):

• host=x86-unknown-linux-gnu, target=MIPS{ II/BE, III/BE, IV/BE, 32/BE, 32/LE }-unknown-linux-gnu -----> epic failures
• host=x86-unknown-linux-gnu, target=HPPA2-unknown-linux-gnu -----> epic failures
• host=x86-unknown-linux-gnu, target=PPC{ 4xx, 750, 74xx }-unknown-linux-gnu -----> epic failures
• host=x86-unknown-linux-gnu, target=ARM{ armv5tel-softfloat-linux-gnueabi, 7a-unknown-linux-gnueabihf } -----> epic failures

Probably one day it will be fixed, I hope. In the meanwhile, ... well I don't know, personally I know I'd better user real hardware to native compile (target=host).

Cross-Compiling the kernel is not a problem, but Cross-Emerging simply doesn't work correctly.

So, you are 100% right here: it took me two years just to prepare a working stage4, six months to fix issues with Catalyst, and Ada still has serious problems, as well as HPPA2, SPARC, and PPC compilers, while the support for ARM seems better.

[nctnico]

A much better route is to cross-compile the kernel, use chroot to create a root image from a mainstream distro and load that onto your platform. From there compile your own code on the platform itself. For most (modern) SOCs you can buy nice development boards that also support peripherals like an Msata or M.2 (PCIe) SSD so storage space is no issue at all.

Cross compiling is nice in theory but many applications don't really support well (IOW: it takes hacking the compilation recipies to make it work). I have spend lots of days with Buildroot to get packages to cross-compile properly. Nowadays being able to do 'apt-get install' to get some (debugging) utilities installed is so much easier & quicker.

[Monkeh]

Buildroot and (worse) Yocto have a steep learning curve and ..

Despite the effort of fantastic and very smart people like "Vapier", Gentoo CrossDev has never worked like expected, and by the end of 2021 it still failed on cross-emerging, at least with these (which are my personal domain of interests):

• host=x86-unknown-linux-gnu, target=MIPS{ II/BE, III/BE, IV/BE, 32/BE, 32/LE }-unknown-linux-gnu -----> epic failures
• host=x86-unknown-linux-gnu, target=HPPA2-unknown-linux-gnu -----> epic failures
• host=x86-unknown-linux-gnu, target=PPC{ 4xx, 750, 74xx }-unknown-linux-gnu -----> epic failures
• host=x86-unknown-linux-gnu, target=ARM{ armv5tel-softfloat-linux-gnueabi, 7a-unknown-linux-gnueabihf } -----> epic failures

Probably one day it will be fixed, I hope. In the meanwhile, ... well I don't know, personally I know I'd better user real hardware to native compile (target=host).

Cross-Compiling the kernel is not a problem, but Cross-Emerging simply doesn't work correctly.

So, you are 100% right here: it took me two years just to prepare a working stage4, six months to fix issues with Catalyst, and Ada still has serious problems, as well as HPPA2, SPARC, and PPC compilers, while the support for ARM seems better.

crossdev is and always has been a broken, unusable mess. And vapier is responsible for more broken system packages and failed merges in my 17 years of using Gentoo than everyone else combined..

[Nominal Animal]

To learn how to build your own Linux distribution (or even a single installation) directly from the sources, go read Linux From Scratch.

OpenWRT is widely used on network appliances, like routers and such.  You can get a cheap compatible device, install OpenWRT on it, and start exploring how it works, is maintained, and is put together.

On anything that has at least 512 MiB of RAM or more, you can install a minimal Debian (armel/armhf/arm64), and treat as a fully fledged but memory-limited Linux installation.  (There is also related Devuan/Dev1 forum for SystemD-free Debian derivative/fork on ARM architectures.)

In general terms, working on Embedded Linux systems is mostly software integration work, because even embedded Linux systems look and feel like desktop, server, or laptop Linux systems.  The software components, from the init system to userspace applications and servers, just matter a LOT MORE than in desktop systems, because of the use constrains.

(As an example, you probably have seen all sorts of blue screen error messages in public displays.  This is a sign of bad integration work; of a poor embedded system integration, choosing software components that require user interaction.)

There are tools that let even a drunk monkey (eventually) set up a seemingly working Linux installation on an embedded system.  Many e.g. router manufacturers hire quick teams to derive one from a snapshot of OpenWRT or similar, maybe provide updates for a year or so, and then end the support, leaving the users with the perfectly working hardware no option but buy a new device.  This is a working business practice, similar to planned obsolescense, and very cheap, too.  It is healthy to dislike such practices.  Don't become one of the people who do that.  At minimum, let the users maintain the device on their own after official support has ended, because after all, you yourself are relying on the open source efforts of thousands of Linux developers to make your product in the first place.

If things like long boot times are an issue, you will have to either find or develop yourself alternatives to the most common init system in Linux (systemd) and its "associated" services.  They are not really suitable for use in embedded systems, even though some do choose to use them (especially when the device has more than half a gigabyte of RAM, and therefore can be treated like a desktop machine from the systems integration point of view).

It is not difficult to construct a completely new Linux distribution or a single system from sources, but the actual number of software components needed and used when even a simple system is running, will surprise you: there are a lot of details.  Don't let that discourage you, because they are just that, components.

[PKTKS]

(..)
If things like long boot times are an issue, you will have to either find or develop yourself alternatives to the most common init system in Linux (systemd) and its "associated" services.  They are not really suitable for use in embedded systems, even though some do choose to use them (especially when the device has more than half a gigabyte of RAM, and therefore can be treated like a desktop machine from the systems integration point of view).
(..)

Agreed 99% really...

The thing with the POTTERIX machine is that it is meant to replicate (or reimplement) the 80s/90s "mainstream desktop" gizmo... or computer as a toaster  machine...
which main business  is actually cosmetic desktop girly fruuuus....

when things behave well and goes as planned they grin...
When things fail and a single bit has a bad result... well...  it is a total train wreckage

Apart from the 80s  toaster machine systemD is meant to replicate..
CONSTRAINED SYSTEMS require some more issues worth to mention:
- first and foremost (as already pointed)  THE TOOLCHAIN USED
- it may not seem big deal but as soon as things high level (JRE? Pyhtonist?)  are used.. is tragic
- THE toolchain directly points to the chosen LIBC  where GNU libc is bloated...
- LIBC is the utmost piece of problems because it holds pthread lib
- any reasonable MCU (ARM multi core) will use THREADS today... even Arduino tries to implement some sort of scheduler or things alike..
- Last piece of the chain is BUSYBOX..  no constrained system avoids using a BUSYBOX deploy.. tied to the chosen PTHREAD library and the toolchain..

Best alternatives scratched yourself from LFS comes from https://voidlinux.org/
using a MUSLC http://musl.libc.org/  implementation which can be easily
integrated by BUSYBOX https://busybox.net/

Last worth mention is https://alpinelinux.org/downloads/  builds...

Last piece of 2 cents is the train wreck presented by JAVA itself..
JAVA is tied to the CPU thread model...
even the minor change in the chain renders JRE unusable...
so be warned


Paul

[alexanderbrevig]

Also relevant to your interests:

Digi-Key "Introduction to Embedded Linux"

https://www.youtube.com/playlist?list=PLEBQazB0HUyTpoJoZecRK6PpDG31Y7RPB

I found this a very clear introduction, together with the previously linked Jay Carlson - So you want to build en embedded linux system? it got me up and running

[rpiloverbd]

I think you can start with Raspberry PI. Raspberry Pi's operating system is based on linux. Banana Pi, Orange Pi also are examples of embedded linux systems. But Raspberry Pi tutorials and resources are more available than the others.

[PKTKS]

Also relevant to your interests:

Digi-Key "Introduction to Embedded Linux"

https://www.youtube.com/playlist?list=PLEBQazB0HUyTpoJoZecRK6PpDG31Y7RPB

I found this a very clear introduction, together with the previously linked Jay Carlson - So you want to build en embedded linux system? it got me up and running

Very interesting comments on this post....

I found this particular paragraph the most suitable argument to ditch anything which will even resemble systemD  thingys  for booting  MCUs  ( with MMUs or even wo them but fine tuned to real time schedulers) ... which require a very organized predictable sequence and toolchain to inter-operate the chain stack..


Console UART

Unlike MCU-based designs, on an embedded Linux system, you absolutely, positively, must have a console UART available. Linuxs entire tracing architecture is built around logging messages to a console, as is the U-Boot bootloader.

That doesnt mean you shouldnt also have JTAG/SWD access, especially in the early stage of development when youre bringing up your bootloader (otherwise youll be stuck with printf() calls). Having said that, if you actually have to break out your J-Link on your embedded Linux board, it probably means youre having a really bad day. While you can attach a debugger to an MPU, getting everything set up correctly is extremely clunky when compared to debugging an MCU. Prepare to relocate symbol tables as your code transitions from SRAM to main DRAM memory. Its not uncommon to have to muck around with other registers, too (like forcing your CPU out of Thumb mode). And on top of that, Ive found that some U-Boot ports remux the JTAG pins (either due to alternate functionality or to save power), and the JTAG chains on some parts are quite complex and require using less-commonly used pins and features of the interface. Oh, and since you have an underlying Boot ROM that executes first, JTAG adapters can screw that up, too.



SystemD advocates  are always mocking the console and user interaction as being a thing from the 70s..  like tele-printer tapes..

The other way around... they are essential topologies (consoles and uarts) for proper MCUs and real time interactive peripherals...  where (if using) everything messed up by a single supervisor  is just a dead shit from the 80s/90s...  or a consumer toaster for the 2020s..
a total train wreck to deal with in serious scenarios

Thanks for the reading..
Paul

[FlyingDutch]

Do yourself a favour and use a distribution like Debian or Ubuntu. Buildroot and (worse) Yocto have a steep learning curve and are only to be considered if you are constrained for space due to cost savings. Expect to need at least 6 months fulltime to learn all the in&outs of Buildroot.

Hello @nctnico,

on my PC Box in home I am using "Linux Mint" and "Debian".On my Job laptop I am also using "Debian". On RPI3 i am using "Ubuntu". The OP was asking about Embedded Linux standards. Yocto is such standard suported by MCU producers (STM, NXP and many others). If you ask me if I like Yocto I will answer you no. I also prefer Linux distros with "normal" packages repositories, but I am not person which makes standards 

Best Regards

[nctnico]

Do yourself a favour and use a distribution like Debian or Ubuntu. Buildroot and (worse) Yocto have a steep learning curve and are only to be considered if you are constrained for space due to cost savings. Expect to need at least 6 months fulltime to learn all the in&outs of Buildroot.

Hello @nctnico,

on my PC Box in home I am using "Linux Mint" and "Debian".On my Job laptop I am also using "Debian". On RPI3 i am using "Ubuntu". The OP was asking about Embedded Linux standards. Yocto is such standard suported by MCU producers (STM, NXP and many others). If you ask me if I like Yocto I will answer you no. I also prefer Linux distros with "normal" packages repositories, but I am not person which makes standards 

IMHO ST, NXP, et al are falling behind by still clinging onto Yocto. If you go onto NXP's forum for embedded processors -for example- you'll see many use Debian linux. Yocto has become more like an excuse to deny support questions. If you look at NVidia Jetson modules or the Raspberry pi: both use standard distros. Not Yocto or buildroot.

And why would you want to use Yocto or Buildroot nowadays? Several GB worth of flash has been cheap for the past decade. Nowadays you can buy an eMMC with a capacitory of several GB for a few dollars and it has wear levelling build in. Yocto and buildroot where great tools if you only have like  8MB of flash and 16MB of memory (been there, done that) but nowadays it is just not worth the trouble. I've also ran into plenty of problems with uClibc as well because it implements only a subset of the standard C library (the space savings have to come from somewhere).

Bottom line: At some point a tool gets outdated and stating that Yocto or Buildroot are used by default / by standard to run embedded Linux no longer holds IMHO. IOW: I would strongly discourage someone who just starts with embedded Linux to start with Yocto or buildroot.

[bson]

Are you talking commercial work or hobbyist?  All commercial systems - system board support packages (BSPs) - have been Red Hat, but that's likely specific to the industry I have experience with (TVs, Blu-Ray players, STBs, DVRs, etc).  Given you're not going to port your favorite flavor of Linux to a complex system with tons of drivers, boot certs generators, video pipeline drivers, and all kinds of rather complex stuff, the BSP is going to be the flavor you work with.  This, of course, has practically zero impact on the actual engineering work - that of writing or porting system software to run on these devices.  Or interfacing custom hardware - which is still mainly a software problem.  Instead, you're going to get really good at cross-compiling an entire system from source, including your added components (drivers, daemons, network filters and other kernel modules, etc), and staging it for testing on a tftp boot server running on your workstation.  In addition, complex SoCs like this will come with reference systems that you buy (and which are rather pricey) and base your own designs off of.  This way you can start software work on day one, and shift over to your own hardware when the first working systems are ready.  Since the problem domain is 99.99% software, this is critical to getting products out in a timely manner and why literally everyone uses reference platforms.

[nctnico]

Perhaps it is good to make a distinction on what software layers are involved with a Linux system.

At the base there usually is a bootloader (which in turn gets started by a ROM bootloader or something similar). U-boot is quite popular nowadays but there are several others. The bootloader takes care of basic system initialisation (memory, clocks, maybe show an image on screen) and load the Linux kernel from the system's storage medium. U-boot has become quite advanced over the years. I think it is possible to use it as a mini-OS as well; there are so many drivers and tools for it.

The Linux kernel has all the system's drivers and hardware definitions. This will initialise the hardware further and run an application called 'init' from the boot medium. This application will start all the OS and application software which is last layer of software.

Most of the development effort usually is in tailoring the kernel for the hardware target by adding manufacturer specific drivers and setting up the device tree definition. Sometimes more hacking is involved to add special features OR the platform is relatively new and you need to apply kernel patches to fix bugs. U-boot is usually provided and more or less ready to go but it could need changes to match different memory types / size.

The OS & application software is mostly a matter of selection the software packages you need, adding the manufacturer specific libraries / user space driver files.

[rpiloverbd]

Hi again, I think it will be of great help if you follow some Raspberry pi tutorials. Following are some good ones. As you're from India, you can look at Hindi tutorials too.

1) https://www.theengineeringprojects.com/2021/03/what-is-raspberry-pi-4-pinout-specs-projects-datasheet.html

2) 

[Doctorandus_P]

My 2ct:

Before thinking about embedded linux, start by using a mainstream linux distribution on any regular PC hardware.
This way you can get acquainted with many aspects of Linux in a comfortable way. There is no need to mess with SSH or ethernet connections or terminal windows (yet).

A long time ago I started with Debian, and I still only use Debian based distributions, even if the sole reason is to cut down on the amount of choices to make.
My daily driver is Linux Mint. It is a very beginner friendly Linux distribution.
The only thing you need to do is:

1. Go to their website.
2. Download an image.
3. Flash it to an USB stick.
4. Boot from it.

Also: SSD's and HDD's are cheap.
Booting directly from an USB stick is nice for "rescue or install operations", but not so nice for daily work.
Because SSD's are so cheap, I recommend to buy an EUR 30 SSD and install Linux onto it.
This way you do not have to change a single bit on your regular SSD. If you do not like Linux anymore, just pull it out of your PC and you're done.

Most Bios'es have an option to select a boot device upon power up, and you can also set a default boot device in the BIOS.
This way you can use the BIOS functions of your PC for a multi-boot setup