0% found this document useful (0 votes)
5 views3 pages

ESBook

The document discusses the fundamentals of embedded Linux, including its history, toolchains, and licensing implications. It outlines the components of a typical embedded system, such as the bootloader, kernel, and various types of memory, and describes the process of compiling and loading the kernel. Additionally, it highlights the importance of device trees in hardware interaction and the evolution of embedded Linux tools like BusyBox.

Uploaded by

saadon
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as ODT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
5 views3 pages

ESBook

The document discusses the fundamentals of embedded Linux, including its history, toolchains, and licensing implications. It outlines the components of a typical embedded system, such as the bootloader, kernel, and various types of memory, and describes the process of compiling and loading the kernel. Additionally, it highlights the importance of device trees in hardware interaction and the evolution of embedded Linux tools like BusyBox.

Uploaded by

saadon
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as ODT, PDF, TXT or read online on Scribd
You are on page 1/ 3

To execute command at every terminal start, go to ~/.bashrc and type your command, e.g.

:
export PATH =$PATH:/home/caelum/x-tools/arm-cortex_a8-linux-gnueabihf/bin

- Embedded linux started in 1999 by the AXIS camera , a digital video recorder TiVo.
- Over 2B devices with EL in 2015.
- We can avoid an operating system if the degree of complexity is low in the system, otherwise it’s
needed not get lost with every operation and change needed to carry.
- usually kernel have many patches that are not merged upstream because of uncompatibility. One
should consider the chip whose vendor does provide backward-compatible patches.

Toolchain: compiler linker and runtime libs, bootloader, kernel: manage resources and does
initialisation and handle interaction with the hardware.
Filesystem: run main library and programs upon which the application runs.

Licenses. BSD licenses allow you to get free without sharing your code and can make it proprietary.
While GPL makes your entire code GPL and can’t make proprietary and must share it as open
source the same.
Lesser-GPL allow you to lnk against libs without turning your entire code into GPL that must be
shared the same.
Starting from GPL/LGPL v3 things got contreversal.
Linux requires minimum 32-bit processor, 16M RAM
We used to use JTAG to load software into chips.Now we use RS323 or usb and so.

When we create a emulation using QEMU, in its command we connect the emul to the virtual sd
that uses a local file as root file system and a local zImage. Also we connect it a local virtual
network that is generated by a separate command. And so on ….

toolchain are based on GNU toolset or LLVM of Clang. As for the later, how to use
Clang for cross compilation at http://clang.llvm.org/docs/CrossCompilation.
Html

GCC (GNU compler collection) include c++, c, go, java, fortran, …..
C lib is based on posix specs.
The prefix of gnu’s componnents is cpuAch-vendor-kernel-gnueab.
Eabihf uses floating point while eabi calling convention uses general purpose integer.

Linux os:

many c library implementation: glibc


which the implem of the entire posix
standard, while uCLib is the reduced one
that serves better in system with less
resources.
Eglibc added new features and archs, but
glibc-v2 included all of that.

The glibc contains 4 parts: libc (main part), libm (math), libthread(thread functions) and librr (real
time extension)
To build toolchain by yourself, take a look at Cross Linux From Scratch (http://trac.clfs.org).

Yocto provide generic toolchain while the buildroot specific one for each target system
We generate shared gcc with option -shared and object files as input while we use ar (archive
utility) to generate static lib with rc option.
Crosscompiling manually using crosstool-ng toolchain may be so hard for packages with so many
dependencies. Using build tool like yocto and buildroot automate that. Otherwise build directly on
the target (Raspberry pi or BBB).

Uboot passes control to kernel using device tree (flattened device tree fdt)
bootloader does the minimum needed to load the kernel such as init of the memory CONTROLLER
so that we can access the dram.

Typical Composing
Type Volatile Writable Speed Usage
Size Element
KBs to 6T (6 transistors CPU cache,
SRAM Yes Yes 🔥 Very fast
low MBs per bit) registers
1T + 1C (1
512MB – Main memory
DRAM Yes Yes ⚡ Fast transistor +
32GB+ (RAM)
capacitor)
DDR ⚡⚡ Faster 1GB – Same as DRAM High-speed RAM
Yes Yes
(DDRx) DRAM 128GB (optimized) (DDR3/4/5)
Yes MBs – Floating-gate SSDs, eMMC,
Flash No 🐢 Medium
(block) TBs MOSFETs firmware storage
Boot code
ROM No ❌ No 🔒 Read-only KBs Masked logic
(factory set)
Custom
PROM No Write once 🔒 Read-only KBs Fuse or anti-fuse firmware/hardwar
e logic
Yes (UV KBs – low Floating-gate
EPROM No 🐢 Slow Legacy firmware
erase) MBs transistors
Config storage,
Bytes – Floating-gate
EEPROM No Yes 🐌 Slower BIOS,
few MBs transistors
microcontrollers

ROM code in cpu rom loads spl from flash mem to sram, spl loads tpl (thirdstage program
loader(grub) to dram, tpl load the kernel image to dram. Tpl passes device tree to kernel which
points the kernel to the hardware in hand.
Device tree has dts extension and it’s located in arch directory of the kernel or so, then there is a
common device tree (a sub tree) which is the part that is common among many devices (e.g. a
common cpu for many boards like cortex_a8 or so) these sub device trees have extension dtsi.

Device tree compilation


dtc device-tree.dts => device-tree.dtb

dtc doesn’t allow easy debuging in case of mistypo or so. Thus, we prefer using kbuild instead. The
kernel requires the dtb thus the need for compiling the dts.

Am335x is the mcu while the cortex_a8 is the cpu.


We generate the kernel either as uImage or zImage using make with options.
The generated files include an ELF called vmLinux which is the binary kernel file and system.map
which contains the symbols in human readable format.
uImage: zImage plus a 64-byte U-Boot header.

Bruce Perens built busybox to get linux to run from a 1.44MB floppy disk. Embedded linux got
interested.

You might also like