DEV Community: Can Gulmez

Embedded Linux Development - Part 6

Can Gulmez — Tue, 21 Apr 2026 09:03:18 +0000

In this tutorial, I will continue to discuss embedded Linux development with ssh server activation. Previously, I've entered into BeagleBone Black over J1 serial header with a USB-UART converter. In here, I will show that how to enter into it with ssh command.

Firstly, there are two important points that you have to do. I've already did these in previous tutorials. Firstly, I compiled the kernel with USB Gadget module and secondly, I installed openssh-server package into the rootfs. USB gadget module enables the USB connection as the virtual ethernet adapter.

Let's do required settings for both side. Use the J1 serial header again to enter into the BeagleBone Black.

Type the "root" and the password. Also creating a normal user is good practice.

root@can:/# useradd -m -s /bin/bash can
root@can:/# passwd can
root@can:/# usermod -aG sudo can

I've created a user named "can" and set the its password. After that go to the your home directory and create a bash script. I named it as setup-usb-gadget.sh.

root@can:/home/can# ls
setup-usb-gadget.sh

Open and copy this into that:

#!/bin/bash

INTERFACE="usb0"
IP_ADDR="198.168.7.2/24"

# Load the g_ether kernel module that creates the ethernet virtual link.
modprobe g_ether

# Configure the link interface.
ip addr flush dev "$INTERFACE"
ip link set "$INTERFACE" up
ip addr add "$IP_ADDR" dev "$INTERFACE"

# Ensure that SSH is running.
systemctl start ssh

In here, I loaded the g_ether module into the kernel. It's the name of USB gadget module. I will create usb0 interface. After that I set it as "up" and its IP address as "198.168.7.2". You can give any IP address, doesn't matter. But generally, "198.168.7.2" is used. Lastly make sure that ssh server is enabled.

Set the executable permission:

root@can:/home/can# chmod +x ./setup-usb-gadget.sh

And then run it.

root@can:/home/can# ./setup-usb-gadget.sh 
[  644.487501] g_ether gadget.0: HOST MAC f6:b0:84:e3:dc:c2
[  644.493125] g_ether gadget.0: MAC e2:87:7a:43:97:1d
[  644.498588] g_ether gadget.0: Ethernet Gadget, version: Memorial Day 2008
[  644.505565] g_ether gadget.0: g_ether ready
[  644.522283] PM: Cannot get wkup_m3_ipc handle

Lastly, list the available interface on BeagleBone Black:

root@can:/home/can# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
3: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 64:8c:bb:f2:25:78 brd ff:ff:ff:ff:ff:ff
4: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether e2:87:7a:43:97:1d brd ff:ff:ff:ff:ff:ff
    inet 198.168.7.2/24 brd 198.168.7.255 scope global usb0
       valid_lft forever preferred_lft forever
    inet6 fe80::e087:7aff:fe43:971d/64 scope link 
       valid_lft forever preferred_lft forever

You see the "usb0" interface. That's enough for BeagleBone Black. Let's continue with host side. Open a new terminal and list the available interfaces on host:

can@can:~$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether e8:6a:64:19:45:15 brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether b0:fc:36:c1:cf:eb brd ff:ff:ff:ff:ff:ff
    inet 10.152.197.93/24 brd 10.152.197.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 3521sec preferred_lft 3521sec
    inet6 fe80::18fc:91fe:ea80:8fad/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether fa:47:d4:7a:67:3e brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
13: enxf6b084e3dcc2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether f6:b0:84:e3:dc:c2 brd ff:ff:ff:ff:ff:ff

BeagleBone Black seems as "enxf6b084e3dcc2" for now. You probably see the different name. It doesn't matter. As wee did in BeagleBone Black, let's do the same things at host side:

can@can:~$ ip addr flush dev enxf6b084e3dcc2
can@can:~$ sudo ip link set enxf6b084e3dcc2 up
can@can:~$ sudo ip addr add 198.168.7.1/24 dev enxf6b084e3dcc2

I assigned the IP address "198.168.7.1" to host (I did "198.168.7.2" for BeagleBone Black).

Lastly, ping BeagleBone Black interface:

can@can:~$ ping 198.168.7.2
PING 198.168.7.2 (198.168.7.2) 56(84) bytes of data.
64 bytes from 198.168.7.2: icmp_seq=1 ttl=64 time=0.904 ms
64 bytes from 198.168.7.2: icmp_seq=2 ttl=64 time=0.351 ms
64 bytes from 198.168.7.2: icmp_seq=3 ttl=64 time=0.449 ms
64 bytes from 198.168.7.2: icmp_seq=4 ttl=64 time=0.478 ms
64 bytes from 198.168.7.2: icmp_seq=5 ttl=64 time=0.585 ms
64 bytes from 198.168.7.2: icmp_seq=6 ttl=64 time=0.477 ms
^C
--- 198.168.7.2 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5114ms
rtt min/avg/max/mdev = 0.351/0.540/0.904/0.176 ms

That's okey 🥳🥳🥳🥳. You can connect to BeagleBone Black with ssh command for now:

can@can:~$ ssh can@198.168.7.2
can@198.168.7.2's password: 
Linux can 6.14.0-ge8b471285262 #1 SMP Mon Apr 13 12:31:38 +03 2026 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Jan  1 00:43:51 2000 from 198.168.7.1
can@can:~$ 
can@can:~$ ls
setup-usb-gadget.sh
can@can:~$ cd ..
can@can:/home$ cd ..
can@can:/$ ls
bin  boot  dev  etc  home  lib  lost+found  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

You don't need anymore J1 serial header. You can use it within the ssh terminal for now. Also you can set the setup-usb-gadget.sh as startup script so that it runs automatically after the boot.

In next tutorial, I will inspect the uEnv.txt file and u-boot console. You can make many interesting tricks in there.

Resources:

Simmonds C., Mastering Embedded Linux Programming, Packt Publishing, 2015
Embedded Linux system development training, Bootlin, 2024

Embedded Linux Development - Part 5

Can Gulmez — Tue, 14 Apr 2026 13:18:52 +0000

Until here, I've talked about the embedded Linux development in four stage: toolchain, bootloader, Linux kernel, rootfs. In this tutorial, I will create a SD card image including these and then run it in BeagleBone Black.

Firstly, let's remember that what I've produced from these stages:

MLO (second-stage bootloader)
u-boot.img (main bootloader)
uEnv.txt (commands for the bootloader)
zImage (compressed the kernel image)
am335x-boneblack.dtb (device tree for the kernel)
Debian rootfs (including the kernel modules)

How can I create a SD card image including all of these?

Firstly, I need to create two partitions, one for booting and second for rootfs. So plugin the SD card into the PC (I'm on Ubuntu) and create the partitions:

$ sudo parted -s /dev/sdX mklabel msdos # parition table and partitions

$ sudo parted -s /dev/sdX mkpart primary fat32 1MiB 65MiB # boot partition (FAT32, 64MB)
$ sudo parted -s /dev/sdX set 1 boot on # make it first parititon

$ sudo parted -s /dev/sdX mkpart primary ext4 65MiB 100% # rootfs parititon (ext4, rest of SD card)

$ sudo mkfs.vfat -F 32 -n boot /dev/sdX1 # format the boot partition
$ sudo mkfs.ext4 -L rootfs /dev/sdX2 # format the rootfs partition

In here, I created the "boot" partition which was formatted with FAT32 and "rootfs" partition with ext4. Why did I create two distinct partitions? The first reason is that the kernel loads and runs the rootfs. So the bootloader cannot reside in the rootfs because of the bootloader runs before the kernel. Second reason is that the bootloader works with FAT32 better (even if the FAT32 size is much bigger).

After that, copy the MLO, u-boot.img, uEnv.txt, zImage, am335x-boneblack.dtb into the "boot" partition. Also copy the your rootfs content into the "rootfs" partition.

That's it. The SD card is ready to run the BeagleBone Black. So plugin the SD card and then power up the board. Well how to enter into the Debian rootfs? There is a J1 header besides the P9. It's the serial port. Pin 1 is GND, 4 is RX and 5 is TX. Use FT232R converter to connect these pins to PC.

To see the outputs, open a terminal and the type:

$ screen /dev/ttyUSBX 115200 # or /dev/ttyACMX

Reboot the BeagleBone Black and then you will see the u-boot and the kernel messages. Lastly, you will see the login session:

Type the "root" and the password (you set it in previous tutorial). That's it. You are in the BeagleBone Black terminal.

You can do whatever you want after that 🥳🥳🥳.

In the next tutorial, I will show that how to use ssh command so that you can easily make connection over USB cable, not needing to J1 header.

Resources:

Simmonds C., Mastering Embedded Linux Programming, Packt Publishing, 2015
Embedded Linux system development training, Bootlin, 2024

Embedded Linux Development - Part 4

Can Gulmez — Mon, 13 Apr 2026 17:15:36 +0000

In this tutorial, I will go with the fourth stage of embedded Linux development which is the rootfs.

Every Linux-based system have a filesystem. If you are on GNU/Linux, you already probably know it and how it structured.

Apart from that embedded Linux needs a few special applications to start up the system. The init is the first program that runs on user-space so that its process ID always is 1. This init program is responsible for start the other user-space applications and services like shell. It generally resides at /sbin/init, /etc/init, /bin/init or so on. The kernel try to find it and then run.

The organization of a Linux rootfs in terms of directories is well-defined by the Filesystem Hierarchy Standard. The general hierarchy:

/bin: Basic programs
/boot: Kernel images, configurations and booting tools
/dev: Device files
/etc: System-wide configuration
/home: Directory for the users home utilities
/lib: Basic libraries
/media: Mount points for removable media
/mnt: Mount point for a temporarily mounted filesystem
/proc: Mount point for the proc virtual filesystem
/root: How directory of the root user
/run: Run-time variable data
/sbin: Basic system programs
/sys: Mount point of the sysfs virtual filesystem
/tmp: Temporary files
/usr: User-specific utilities
/var: Variable data files, for system services

So in summary, I need to create a Linux rootfs and then put the required applications in there. I also want to build a development environment. For example, I want to run python 3 scripts, compiling C/C++ programs, or so on. But how?

There are three options here:

Building everything from scratch
A minimal BusyBox rootfs
A Debian rootfs with debootstap

Which option is for me?

Building everything from scratch means that creating the directories and then fetch the every program, package, library by hand. It means the hell of package dependency! It's not for me.

A minimal rootfs can be created with BusyBox easily. It can create the classic Linux directories and put the core utilities in there like cp, mkdir, ls or so on. If you're making embedded Linux system first time and just focusing on a "running" system, BusyBox is for you. But I need more. I wanna create a development environment!

The right tool is debootstrap program. It creates a base Debian rootfs including the utilities that we're using everyday like apt, systemctl, vi, or so on. This Debian rootfs is around ~200MB, while BusyBox rootfs is ~1MB.

By the way, if you want to go with BusyBox rootfs (while I'm not), below is the required commands:

$ git clone https://git.busybox.net/busybox
$ cd busybox
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- defconfig
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j$(nproc)
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig # optional
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- CONFIG_PREFIX=path/to/linux/rootfs install

Let's focus on debootstrap. Firstly download it.

$ sudo apt install qemu-user-static debootstrap

In here, I also installed qemu-user-static which lets me to run the ARM binaries onto x86_64.

Let's create the base Debian rootfs:

$ sudo debootstrap --arch=armhf --foreign bookworm path/to/linux/rootfs http://deb.debian.org/debian
$ sudo chroot path/to/linux/rootfs /debootstrap/debootstrap --second-stage

In here, bookworm is the nickname of Debian 12 which is the last stable version.

These two commands download the rootfs and then unpack it. So it takes some time (~30 minutes in my case). Don't forget, these just fetch the required and important packages from the Debian database, not fully OS.

The rootfs is ready to be used. But there are some tricks that you always must do:

$ sudo cp /usr/bin/qemu-arm-static <path/to/linux/rootfs>/usr/bin/

I also want to install the additional packages and make some settings. For example, you always must set the password. That means I need to run this rootfs on my Ubuntu host:

$ sudo chroot path/to/linux/rootfs

First thing you must is to update the password:

root@can:/# passwd
New password: 
Retype new password: 
passwd: password updated successfully

Install the additional packages if you want:

root@can:/# apt install gcc python3 vim openssh-server # and what you need

In here, make sure that you install the openssh-server. It's required for ssh command.

Lastly, I need to install the kernel modules in this rootfs. Go back to the kernel source and run:

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- INSTALL_MOD_PATH=path/to/linux/rootfs modules_install

That's it. I created the proper Debian rootfs that I can make software development. In the next tutorial, I will use the all artifacts coming from u-boot, the kernel and the rootfs to make SD card image.

Resources:

Simmonds C., Mastering Embedded Linux Programming, Packt Publishing, 2015
Embedded Linux system development training, Bootlin, 2024

Embedded Linux Development - Part 3

Can Gulmez — Mon, 13 Apr 2026 14:02:29 +0000

In this tutorial, I'll go with the third stage of embedded Linux development. That's the Linux kernel.

It's the responsible for:

Manage all the hardware resources: CPU, memory, I/O.
Provide a set of portable, architecture and hardware independent APIs to allow user space applications and libraries to use the hardware resources.
Handle concurrent accesses and usage of hardware resources set of system calls.

The kernel provides about 400 system calls that provide the services like opening the disk file, forking the new process, managing the memory or so on. These system calls are defined in /usr/include/x86_64-linux-gnu/asm/unistd.h like:

#define __NR_read 0
#define __NR_write 1
#define __NR_open 2
#define __NR_close 3
#define __NR_stat 4
#define __NR_fstat 5
#define __NR_lstat 6
#define __NR_poll 7
#define __NR_lseek 8
#define __NR_mmap 9
#define __NR_mprotect 10
#define __NR_munmap 11
#define __NR_brk 12

(...)

In user-space applications, we generally don't use these system calls directly. These system calls are wrapped by the standard POSIX C library. If you're a programmer, you already know it.

Let's start with downloading Linux kernel:

$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

I have the 6.14 kernel (slightly older, but doesn't matter). As you see that the kernel contains thousands of device drivers, filesystem drivers, network protocols and other configurable items.

As I did previously at u-boot stage, the first thing is to configure the kernel according to BeagleBone Black over configuration files (ends with _defconfig).

Which configuration file should be used for BeagleBone Black? It's omap2plus_defconfig under linux/arch/arm/configs (OMAP is the processor family including the AM335x Sitara processor by TI).

So let's configure the kernel:

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- omap2plus_defconfig

It will create the .config and write the associated configs in it.

As I said, this configuration file includes the generic AM335x Sitara processor configs. To customize and tailor the kernel further:

$ make menuconfig # or xconfig (for Qt-based)

It will open the terminal-based GUI window to select/unselect the configurable items like:

If you're unfamiliar or newer, I DON'T recommend it. But I need to make an important configuration in here about the USB gadget support. As I will explain in the next tutorail, I wanna use the ssh command to make connection with BeagleBone Black. If you don't make it, you're totally free.

Navigate to Device Drivers --> USB Support --> USB Gadget Support --> USB Gadget precomposed configurations --> Ethernet Gadget (with CDC Ethernet support), type "M" and then exit by saving. It will create the virtual USB link so that I can use the ssh command to connect to BeagleBone Black. I will explain it in the last tutorial in detail.

By the way, you will see the "*" and "M" marks as you navigate the configs. "*" means that the configs will be embedded into the kernel image, while "M" means that the configs is built as modules. These are plugins that can be loaded/unloaded dynamically at runtime to the kernel.

After configured the kernel, for now, you're ready to build the required outputs.

Which outputs exactly should be built from the kernel source? Three things:

zImage
am335x-boneblack.dtb
kernel modules

zImage is the compressed the Linux kernel image. am335x-boneblack.dtb is the device tree blob that describes the hardware connected to the kernel. The kernel modules also are being compiled externally, not embedded into the kernel image.

In here, I have to explain the device tree concept. It's the description of the hardware that the kernel manages at runtime. As you expect, the kernel must know the hardware that it will manage. It's written generally by the processor vendor or development board engineers. The device tree corresponding to BeagleBone Black is the am335x-boneblack.dts under linux/arch/arm/boot/dts/ti/omap.

To produces these outputs:

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j$(nproc) zImage dtbs modules

It will take for a while (~1 hours in my case). After that you will see the zImage under linux/arch/arm/boot and am335x-boneblack.dtb under linux/arch/arm/boot/dts/ti/omap.

The kernel modules are compiled ending with .ko suffix. After the rootfs is being created, I will install these kernel modules in it:

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- INSTALL_MOD_PATH=path/to/linux/rootfs modules_install

But DON'T do it for now. I need to create a rootfs firstly and then install the kernel modules in there. I will show it in the next tutorial.

That's it. I've produced the three essential components from the kernel source: zImage, am335x-boneblack.dtb, and kernel modules. In the next tutorial, I will interest with the rootfs.

Resources:

Simmonds C., Mastering Embedded Linux Programming, Packt Publishing, 2015
Embedded Linux system development training, Bootlin, 2024

Embedded Linux Development - Part 2

Can Gulmez — Sun, 12 Apr 2026 19:10:26 +0000

In this post, I will continue the embedded Linux development series with second stage which is the bootloader.

Firstly, a bit theoretical background.

The bootloader is a piece of code responsible for:

Basic hardware initialization
Loading of an application binary, usually an operating system kernel, from flash storage, from the network, or from another type of non-volatile storage
Possible decompression of the application binary
Execution of the application

Besides these basic functions, most bootloaders provide a shell or menu:

Menu to select the operating system to load
Shell with commands to load data from storage or network, inspect memory, perform hardware testing/diagnostics

Boot process highly is depended to processor. Let's focus on AM335x Sitara (ARM) booting sequence.

Most embedded processors include a ROM code that implements the initial step of the boot process. It's called the first-stage loader. This ROM code is written by the processor vendor directly built into the processor. That means, it cannot be changed or updated by the others. It initializes the CPU and internal SRAM. It also searches the MLO from NAND/NOR flash, from USB, from SD card, from eMMC, etc.

MLO is a file that you need to produce from the bootloader source code. It's called also second-program loader (SPL). Its mission is to initialize the DDR RAM and run the main bootloader.

The main bootloader initializes the hardware and then loads the Linux kernel and then jump to it. I will use the U-Boot. It's the mostly used bootloader in embedded world.

In summary, the booting process: ROM code --> MLO (SPL) --> U-Boot --> Linux kernel.

So after compiled the u-boot, I expect these:

MLO
u-boot.img

Let's produce these.

Firstly, download the u-boot:

$ git clone https://source.denx.de/u-boot/u-boot.git

If you look at the source code, you will see that the u-boot supports a lot of processors and boards. So first thing you should do is to configure the u-boot over configuration files (ends with *_defconfig) under u-boot/configs.

But which exactly configuration file corresponds to BeagleBone Black? The answer is am335x_evm_defconfig. It's generic AM335x Sitara processor configuration file.

To use this configuration file:

$ make am335x_evm_defconfig

It will create the .config file and write the configs in it. The important point is that you never edit this file by hand.

To customize and tailor this configs further:

$ make menuconfig     # or xconfig (for Qt-based)

It will open the terminal-based GUI to select/unselect the configs. If you are unfamiliar or newer, you should NOT do it. Because it will show the tons of different configs and it can seem messy. The previous command already made the generic required configs.

After setting up the configs, let's build the outputs.

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-

It will take for a while. Because it will compile the tons of source file and then link them together. The output will be like:

(...)

  AR      spl/fs/fat/built-in.o
  CC      spl/fs/fs_internal.o
  AR      spl/fs/built-in.o
  CC      spl/net/arp.o
  CC      spl/net/bootp.o
  CC      spl/net/eth-uclass.o
  CC      spl/net/eth_common.o
  CC      spl/net/net.o
  CC      spl/net/ping.o
  CC      spl/net/tftp.o
  AR      spl/net/built-in.o
  LDS     spl/u-boot-spl.lds
  LD      spl/u-boot-spl
  OBJCOPY spl/u-boot-spl-nodtb.bin
  COPY    spl/u-boot-spl.bin
  MKIMAGE MLO
  MKIMAGE MLO.byteswap
  SYM     spl/u-boot-spl.sym
  MKIMAGE u-boot-dtb.img
  OFCHK   .config

After that you can see the u-boot/MLO, u-boot/u-boot.img and a lots of other files.

As I said before, I need the MLO and u-boot.img and will use these in further. For now, just keeps these in mind.

There is also one more important file that I need. It's uEnv.txt and used by the u-boot when loading the Linux kernel. It consists of the key-value pairs that tell some command to u-boot. So create a new file named of it.

$ vim uEnv.txt

And write the following commands in it.

bootpart=0:1
devtype=mmc
bootdir=
bootfile=zImage
bootpartition=mmcblk0p2
console=ttyS0,115200n8
loadaddr=0x82000000
fdtaddr=0x88000000
set_mmc1=if test $board_name = A33515BB; then setenv bootpartition mmcblk1p2; fi
set_bootargs=setenv bootargs console=${console} root=/dev/${bootpartition} rw rootfstype=ext4 rootwait
uenvcmd=run set_mmc1; run set_bootargs;run loadimage;run loadfdt;printenv bootargs;bootz ${loadaddr} - ${fdtaddr}

At the end of this series, you will fully understand what these are. But basically:

the console name is set to ttyS0 and baud rate to 115200.
the Linux kernel name is defined as zImage.
the address that Linux kernel image will be placed is set to 0x82000000 and the address that device tree blob will be placed to 0x88000000.
set the boot environment and load the Linux kernel with bootz command.

Save it and then keep this file in mind as being MLO and u-boot.img.

That's it. You've produced the three components related to bootloader stage. In next post, I will interest with Linux kernel itself.

Resources:

Simmonds C., Mastering Embedded Linux Programming, Packt Publishing, 2015
Embedded Linux system development training, Bootlin, 2024

Embedded Linux Development - Part 1

Can Gulmez — Sun, 12 Apr 2026 12:53:51 +0000

In today, I'm beginning a new series about embedded Linux development. I'll show that how to build an end-to-end embedded Linux system from scratch by hand.

I'll fetch the associated every stuffs from source code and then build the corresponding outputs.

I will target the BeagleBone Black Rev C board. I will compile the everything for that board. So you need the following things for this series:

BeagleBone Black Rev C
USB Mini-B to USB-A cable
FTDI FT232R converter
SD card

Overall, embedded Linux development consists of four components:

Toolchain
Bootloader
Linux kernel
Rootfs

In this post, I will explain the toolchain that I need for all development sequence.

The toolchain is the first element of embedded Linux and the starting point of the project.

A toolchain is the set of tools that compiles source code into executables that can run on your target device, and includes many binaries for the different purposes. Usually, toolchains for Linux are based on components from the GNU project. A standard GNU toolchain consists of three main components:

Binutils is a set of tools to generate and manipulate binaries for a given architecture. Common binaries: as, ld, ar, randlib, objdump, readelf, size, nm, strings, strip, etc.
GCC is the main compiler.
C library is used to interract with the kernel. The programming interface to the UNIX operating system is defined in the C language, which is defined by the POSIX standards. The C library is the implementation of the interface.

In here, there are two types of toolchain:

Native: This toolchain runs on the same type of system.
Cross: This toolchain run on a different type of system than the target.

Almost all embedded Linux development is done using a cross development toolchain. Because doing embedded development, there is always a split between:

The host, the development workstation
The target, which is the embedded system

They are connected by various means: almost always a serial line for debugging purposes, frequently a network connection, sometimes a JTAG interface for low-level stuffs.

Many UNIX/Linux toolchains rely on architecture tuple names to identify machines. You probably compiled many programs on your host already and used the gcc command. But it's actually a shorthand. You can exactly see it with:

$ gcc -dumpmachine
x86_64-linux-gnu

Other examples: arm-linux-gnueabihf, mips64el-linux-gnu, arm-none-eabi- etc.

These tuples are 3 or 4 parts:

The architecture name: arm, riscv, mips64el, etc.
Optionally, a vendor name, which is free-form string.
An operating system name, or none when not targeting an operating system.

Of course, these are the pre-built toolchains. If you want, you can also create your own toolchain with crosstool-ng. It's another post topic. But shortly, when building a toolchain, the ABI used to generate binaries needs to be defined. ABI, Application Binary Interface, defines the calling conventions (how function arguments are passed, how the return value is passed, how system calls are made or so on) and the organization of structures. All binaries in a system are typically compiled with the same ABI, and the kernel must understand this ABI.

Anyway, I gave you the enough theoretical toolchain background. Let's go with our concern.

Which toolchain should be used for BeagleBone Black?

You have to know the used ARM processor in here. BeageBone Black has AM335x Sitara processor which is based on ARM-A8 (ARMv7), 32-bit architecture. So the toolchain for that is the gcc-arm-linux-gnueabihf.

The first thing in implementing embedded Linux is to install it.

$ sudo apt install gcc-arm-linux-gnueabihf

After that validate it.

$ arm-linux-gnueabihf-gcc --version
arm-linux-gnueabihf-gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

That's it. You have the required toolchain and ready to go with the bootloader.

Resources:

Simmonds C., Mastering Embedded Linux Programming, Packt Publishing, 2015
Embedded Linux system development training, Bootlin, 2024

POSIX Shared Memory

Can Gulmez — Wed, 08 Apr 2026 12:47:19 +0000

POSIX shared memory allows to us to share a mapped region between unrelated processes without needing to create a corresponding file.

Linux uses a dedicated tmpfs file system mounted under the directory /dev/shm. This file system has kernel persistance - the shared memory objects that it contains will persists even if no process currently has them open, but they will be lost if the system is shut down.

To use a POSIX shared memory object, we perform two steps:

Use the shm_open() function to open an object with a specified name. The shm_open() function is analogous to the open() system call. It either creates a new shared memory object or opens an existing object. As its function result, shm_open() returns a file descriptor referring to the object.
Pass the file descriptor obtained in the previous step in a call to mmap() that specifies MAP_SHARED in the flags argument. This maps the shared memory object into the process's virtual address space.

#include <sys/mman.h>
#include <sys/stat.h>        /* For mode constants */
#include <fcntl.h>           /* For O_* constants */

int shm_open(const char *name, int oflag, mode_t mode);
int shm_unlink(const char *name);

The name argument identifies the shared memory object to be created or opened. The oflags argument is a mask of bits of O_* as being in open() system call.

At any point, we can apply fstat() to the file descriptor returned by shm_open() in order to obtain a stat structure whose contain information about the shared memory object.

Example of creating a POSIX shared memory is here.

After created the memory object, we of course want to read and write the data into that. Data reading program is here and writing program is here.

SUSv3 requires that POSIX shared memory objects have at least kernel persistence; that is, they continue to exist until they are explicitly removed or the system is rebooted. When a shared memory object is no longer required, it should be removed using shm_unlink(). The example program of its usage is here.

In summary, a POSIX shared memory object is used to share a region of memory between unrelated processes without creating an underlying disk file. To do this, we replace the call to open() that normally precedes mmap() with a call to shm_open(). The shm_open() call creates a file in a memory-based file system, and we can employ traditional file descriptor system calls to perform various operations on this virtual file. In particular, ftruncate() must be used to set the size of the shared memory object, since initially it has a length of zero.

Flashing and Debugging A Firmware in Detail

Can Gulmez — Tue, 10 Mar 2026 20:38:32 +0000

In this tutorial, I will inspect, flash and debug a firmware written for STM32F446RE microcontroller. To accomplish this, we need some dedicated tools:

openocd
arm-none-eabi-*
gdb-multiarch

openocd is the primarily tool that we have to get. It's used as bridge between your host machine and debugger hardware. (I'm using use ST-Link hardware in this time). I will use it to connect to the debugger hardware. arm-none-eabi-* tools are the ARM toolchain used in development of the firmware. gdb-multiarch is the debugger too.

You can get these tools:

$ sudo apt install openocd gcc-arm-none-eabi gdb-multiarch

Note: I'm on Ubuntu 24.04, gcc-arm-none-eabi tools don't include the gdb debugger like arm-none-eabi-gdb. So that gdb-multiarch is being installed externally. On some distribution, the gdb debugger comes with gcc-arm-none-eabi.

Suppose that I have a firmware called "firmware.elf" and wanna inspect it as first step.

The first thing that you should do probably is to determine the firmware itself:

$ file firmware.elf
firmware.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped

The file command simply outputs the firmware properties like the endiannes, architecture, or so on. You can see easily that this firmware was written for 32-bit ARM Cortex.

We can see also the section sizes (in bytes) of the firmware with arm-none-eabi-size command:

$ arm-none-eabi-size firmware.elf
   text    data     bss     dec     hex filename
   5252      20    1732    7004    1b5c firmware.elf

If you are not familiar with sections of the executables, I've wrote many tutorials that explains the ELF executable. You can look at there.

If you exactly wanna see the contents of the firmware, arm-none-eabi-objdump is the primarily tool for that:

$ arm-none-eabi-objdump -j .text -d firmware.elf

firmware.elf:     file format elf32-littlearm


Disassembly of section .text:

(...)

0800079c <main>:
 800079c:   b500        push    {lr}
 800079e:   b091        sub sp, #68 @ 0x44
 80007a0:   f000 f8ac   bl  80008fc <HAL_Init>
 80007a4:   f000 f82c   bl  8000800 <configOscClk>
 80007a8:   f000 f844   bl  8000834 <configDebugPort>
 80007ac:   4911        ldr r1, [pc, #68]   @ (80007f4 <main+0x58>)
 80007ae:   4d12        ldr r5, [pc, #72]   @ (80007f8 <main+0x5c>)
 80007b0:   4c12        ldr r4, [pc, #72]   @ (80007fc <main+0x60>)
 80007b2:   4668        mov r0, sp
 80007b4:   f7ff ff08   bl  80005c8 <strcpy>
 80007b8:   4668        mov r0, sp
 80007ba:   f7ff ff81   bl  80006c0 <strlen>
 80007be:   f04f 33ff   mov.w   r3, #4294967295 @ 0xffffffff
 80007c2:   b282        uxth    r2, r0
 80007c4:   4669        mov r1, sp
 80007c6:   480d        ldr r0, [pc, #52]   @ (80007fc <main+0x60>)
 80007c8:   f000 fdc2   bl  8001350 <HAL_UART_Transmit>
 80007cc:   4629        mov r1, r5
 80007ce:   4668        mov r0, sp
 80007d0:   f7ff fefa   bl  80005c8 <strcpy>
 80007d4:   4668        mov r0, sp
 80007d6:   f7ff ff73   bl  80006c0 <strlen>
 80007da:   f04f 33ff   mov.w   r3, #4294967295 @ 0xffffffff
 80007de:   b282        uxth    r2, r0
 80007e0:   4669        mov r1, sp
 80007e2:   4620        mov r0, r4
 80007e4:   f000 fdb4   bl  8001350 <HAL_UART_Transmit>
 80007e8:   f44f 707a   mov.w   r0, #1000   @ 0x3e8
 80007ec:   f000 f8b2   bl  8000954 <HAL_Delay>
 80007f0:   e7ec        b.n 80007cc <main+0x30>
 80007f2:   bf00        nop
 80007f4:   0800146c    .word   0x0800146c
 80007f8:   08001489    .word   0x08001489
 80007fc:   20000084    .word   0x20000084

(...)

For example, you see the main() function in .text section of the firmware. At left, the address of the machine code were being displayed. At center, you see the machine code corresponding to assembly instructions that is at right side.

Inspecting the contents of ELF executable is huge topic. It has many variants and view-of-points in there.

"Flashing" term means writing the dedicated sections of the firmware into the flash memory area of the microcontroller. It's done with many different ways. But I will show you openocd tool.

In here, I have to define that how exactly does openocd work. It actually creates a server into the host machine with given configuration files. After starting the server session, you need to connect to that server over telnet or gdb.

Let's do it. Firstly, connect the microcontroller to the host machine. Then open a terminal session and type this command:

$ openocd -f interface/stlink.cfg -f target/stm32f4x.cfg

In here, I gave the two configuration files. First is the interface. As I said, I use the ST-Link connection. Second is the target file. It defines the target architecture. The openocd comes a bunch of configuration files. So search it and find the appropriate configuration files.

You will see something like this:

Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 2000 kHz
Info : STLINK V2J33M25 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.224656
Info : [stm32f4x.cpu] Cortex-M4 r0p1 processor detected
Info : [stm32f4x.cpu] target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f4x.cpu on 3333
Info : Listening on port 3333 for gdb connections

The openocd attached the 4444 port to telnet and 3333 port to gdb. So that I will bind the 3333 port in the gdb session.

Secondly, open the second terminal and type:

$ gdb-multiarch firmware.elf

At the moment, you are in the gdb session. In here, bind to the 3333 port:

(gdb) target remote localhost:3333

For now, you are in the control and responsible for the all flashing and debugging operations.

To flash the firmware, use these commands:

(gdb) monitor reset halt
(gdb) load
(gdb) monitor reset halt

There are tons of commands you can type in the gdb session. We can split these commands in two categories. monitor commands directly are run by the openocd command. Other commands are run by the gdb itself.

load is the main command to flash the firmware. Before and after that command, resetting and halting the CPU execution is good practice. Output will be like:

Loading section .isr_vector, size 0x1c4 lma 0x8000000
Loading section .text, size 0x126c lma 0x8000200
Loading section .rodata, size 0x4c lma 0x800146c
Loading section .ARM, size 0x8 lma 0x80014b8
Loading section .init_array, size 0x4 lma 0x80014c0
Loading section .fini_array, size 0x4 lma 0x80014c4
Loading section .data, size 0xc lma 0x80014c8
Start address 0x08001400, load size 5272
Transfer rate: 9 KB/sec, 753 bytes/write.

That means that the firmware successfully was flashed 🥳.

If you just wanna flash the firmware and not debugging, this following command is enough:

$ openocd -f interface/stlink.cfg -f target/stm32f4x.cfg -c "program firmware.elf verify reset exit"

Instead of dealing with two terminal sessions, above command is just the one-step operation.

The main reason opening the second gdb session is to make the debugging. If you did the debugging previously, you will be familiar with these commands:

(gdb) break main
(gdb) continue
(gdb) next
(gdb) finish
(gdb) print var
(gdb) x/16wx *ptr
(gdb) set var
(gdb) list

The debugging operations are huge and will not fit into a single tutorial as you guest. So that I don't wanna dive into the these and other operations. But I wanna give you a good reference: The Art of Debugging with GDB, DDD, and Eclipse written by Norman Matloff and Peter Jay Salzman.

Until here, I gave a overall explanation the end-to-end pipeline. I'll explain the other stuffs in further.

Simple Code Injection into ELF Executable

Can Gulmez — Tue, 03 Mar 2026 12:44:18 +0000

In this tutorial, I will explain an code injection technique into ELF executable.

Firstly, you need to understand the ELF executable, its contents, sections, symbol table or so on. I've written a dedicated article previously. So if you don't have any information about ELF, please read it firstly and then come here again.

Let's say we have the following source file:

/**
 * Simple Code Injection
 */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
    int i, num;

    num = 10;

    for (i = 0; i < num; i++)
    {
        printf("#%d\n", i);
    }

    return EXIT_SUCCESS;
}

Compile this source file and then run it:

$ gcc main.c -o main ; ./main

After that, you will see:

#0
#1
#2
#3
#4
#5
#6
#7
#8
#9

In here, I will change the num = 10 to num = 5 so that the output will be #0 to #4.

To accomplish this, I need to find the corresponding machine instruction/s. According to your background, you need to know that num variable will be in the .text section of ELF executable. Because it is the local variable. To display the .text section of the program, objdump is the primarily tool:

$ objdump -j .text -d main

The output will be as following:

(...)

0000000000001149 <main>:
    1149:   f3 0f 1e fa             endbr64
    114d:   55                      push   %rbp
    114e:   48 89 e5                mov    %rsp,%rbp
    1151:   48 83 ec 20             sub    $0x20,%rsp
    1155:   89 7d ec                mov    %edi,-0x14(%rbp)
    1158:   48 89 75 e0             mov    %rsi,-0x20(%rbp)
    115c:   c7 45 fc 0a 00 00 00    movl   $0xa,-0x4(%rbp)
    1163:   c7 45 f8 00 00 00 00    movl   $0x0,-0x8(%rbp)
    116a:   eb 1d                   jmp    1189 <main+0x40>
    116c:   8b 45 f8                mov    -0x8(%rbp),%eax
    116f:   89 c6                   mov    %eax,%esi
    1171:   48 8d 05 8c 0e 00 00    lea    0xe8c(%rip),%rax        # 2004 <_IO_stdin_used+0x4>
    1178:   48 89 c7                mov    %rax,%rdi
    117b:   b8 00 00 00 00          mov    $0x0,%eax
    1180:   e8 cb fe ff ff          call   1050 <printf@plt>
    1185:   83 45 f8 01             addl   $0x1,-0x8(%rbp)
    1189:   8b 45 f8                mov    -0x8(%rbp),%eax
    118c:   3b 45 fc                cmp    -0x4(%rbp),%eax
    118f:   7c db                   jl     116c <main+0x23>
    1191:   b8 00 00 00 00          mov    $0x0,%eax
    1196:   c9                      leave
    1197:   c3                      ret

Which machine instruction/s corresponds to num = 10? You need to know reading the assembly instructions in here. The answer is the movl $0xa,-0x4(%rbp) assembly instruction. Because the stack pointer of the program was enlarged by 4 bytes (int holds 4 bytes of memory) to lower address and put the immediate 0xA value. So that I need to change the 0xA value to 0x5.

After the found required assembly instruction, I need to determine the memory address of it. If you look at center column, the machine instruction is c7 45 fc 0a 00 00 00. In here:

c7: the opcode of movl register
45 fc: the displacement of -0x4(%rbp)
0a 00 00 00: the immediate value, 0xA (little-endian)

c7 byte resides at 0x115c address so that 0a byte at 0x115f.

To change that byte, I'm gonna use hexedit program:

$ hexedit ./main

You will see:

After that, you move to 0x115F address and change the 0x0A value to 0x05. Save the changes and then run the program again. You will see:

#0
#1
#2
#3
#4

That's it. You injected the new code in the ELF executable 🥳.

This technique is simple and powerful. But there are some limitations. The most important one is that you should not shift the byte addresses, just replace it. If you wanna change the entire ELF executable addresses, you need the other techniques. That's the next article's topic.

ELF Executable Analysis in Detail

Can Gulmez — Tue, 24 Feb 2026 20:03:28 +0000

In everyday, we run some kind of programs to handle our works. There are many type of programs, GUIs, CLIs, TUIs or so on. But at low level, there are two kind of program formats: PE (Portable Executable) for Windows and ELF (Executable and Linkable Format) for Linux.

In this tutorial, I will explain the ELF executables in detail.

Firstly, let's start with the overall layout:

As you see, an ELF executable consists of four layers:

Executable Header
Program Headers
Sections
Section Headers

Executable Header

Every ELF file starts with an executable header, which is just a structured series of bytes telling you that it's an ELF file, what kind of ELF file it is, and where in the file to find all the other contents. It's defined as follow in /usr/include/elf.h:

In here:

e_ident: The executable header starts with a 16-byte array. First 4-byte, magic value, identifying the file as an ELF binary.
e_type: The type of the executable. For example REL means relocatable object file, EXEC means executable binary and DYN means dynamic libraries.
e_machine: The architecture that the executable is intended to run on.
e_version: The version of the ELF specification (always 1, I really don't know why it exists 😂).
e_entry: The virtual address at which execution should start.
e_phoff, e_shoff: The file offsets to the beginning of the program header table and the section header table.
e_flags: The flags specific to the architecture for which the binary is compiled (typically 0 for x86_64).
e_ehsize: The size of the executable header, in bytes (for 64-bit systems, it's always 64).

You can see the executable header with this command:

$ readelf -h ./prog
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Position-Independent Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x1400
  Start of program headers:          64 (bytes into file)
  Start of section headers:          135496 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         13
  Size of section headers:           64 (bytes)
  Number of section headers:         29
  Section header string table index: 28

Section Headers

The code and data in an ELF binary are logically divided into continuous nonoverlapping chunks called sections. Sections don't have any predetermined structure; instead, the structure of each section varies depending on the contents. So every section is described in section header table. It's defined as follow:

In here:

sh_name: The index of the sections.
sh_type: Every section has a type, indicated by an integer field. Common types: PROBITS for machine instructions, SYMTAB for static symbol table, DYNSYM for dynamic symbol table, STRTAB for string tables, REL(A) for relocation entries used by the linker, DYNAMIC for information needed for dynamic linking or so on.
sh_flags: The section flags. Common flags: W means the section is writable, A means the content of the section are to be loaded into memory when executing the executable, X means the section is executable.
sh_addr, sh_offset, sh_size: The virtual address, file offset (in bytes from the start
of the file), and size (in bytes) of the sections.
sh_link: Sometimes, there are relationships between sections. This field keeps the index count of the related sections.
sh_info: Additional information about sections.
sh_addralign: Some sections may need to be aligned in memory in a particular way for efficiency of memory accesses. The values 0 and 1 are reserved to indicate no special alignment needs.
sh_entsize: Some sections contain a table of well-defined data structures. For such sections, this field indicates the size in bytes of each entry in the table. When the field is unused, it is set to zero.

You can see the section headers with this command:

$ readelf --sections --wide ./prog
There are 29 section headers, starting at offset 0x21148:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        0000000000000318 000318 00001c 00   A  0   0  1
  [ 2] .note.gnu.property NOTE            0000000000000338 000338 000030 00   A  0   0  8
  [ 3] .note.gnu.build-id NOTE            0000000000000368 000368 000024 00   A  0   0  4
  [ 4] .note.ABI-tag     NOTE            000000000000038c 00038c 000020 00   A  0   0  4
  [ 5] .gnu.hash         GNU_HASH        00000000000003b0 0003b0 000028 00   A  6   0  8
  [ 6] .dynsym           DYNSYM          00000000000003d8 0003d8 000378 18   A  7   1  8
  [ 7] .dynstr           STRTAB          0000000000000750 000750 00016d 00   A  0   0  1
  [ 8] .gnu.version      VERSYM          00000000000008be 0008be 00004a 02   A  6   0  2
  [ 9] .gnu.version_r    VERNEED         0000000000000908 000908 000080 00   A  7   2  8
  [10] .rela.dyn         RELA            0000000000000988 000988 0000d8 18   A  6   0  8
  [11] .rela.plt         RELA            0000000000000a60 000a60 0002d0 18  AI  6  24  8
  [12] .init             PROGBITS        0000000000001000 001000 00001b 00  AX  0   0  4
  [13] .plt              PROGBITS        0000000000001020 001020 0001f0 10  AX  0   0 16
  [14] .plt.got          PROGBITS        0000000000001210 001210 000010 10  AX  0   0 16
  [15] .plt.sec          PROGBITS        0000000000001220 001220 0001e0 10  AX  0   0 16
  [16] .text             PROGBITS        0000000000001400 001400 018c54 00  AX  0   0 16
  [17] .fini             PROGBITS        000000000001a054 01a054 00000d 00  AX  0   0  4
  [18] .rodata           PROGBITS        000000000001b000 01b000 002ee8 00   A  0   0 16
  [19] .eh_frame_hdr     PROGBITS        000000000001dee8 01dee8 0005fc 00   A  0   0  4
  [20] .eh_frame         PROGBITS        000000000001e4e8 01e4e8 001914 00   A  0   0  8
  [21] .init_array       INIT_ARRAY      0000000000020cc0 020cc0 000008 08  WA  0   0  8
  [22] .fini_array       FINI_ARRAY      0000000000020cc8 020cc8 000008 08  WA  0   0  8
  [23] .dynamic          DYNAMIC         0000000000020cd0 020cd0 000200 10  WA  7   0  8
  [24] .got              PROGBITS        0000000000020ed0 020ed0 000130 08  WA  0   0  8
  [25] .data             PROGBITS        0000000000021000 021000 000010 00  WA  0   0  8
  [26] .bss              NOBITS          0000000000021020 021010 000010 00  WA  0   0 32
  [27] .comment          PROGBITS        0000000000000000 021010 00002b 01  MS  0   0  1
  [28] .shstrtab         STRTAB          0000000000000000 02103b 00010a 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  D (mbind), l (large), p (processor specific)

Sections

In previous chapter, you see that the ELF executable has a set of sections at which each section has a special meaning. For now, let me explain these:

.init and .fini: The .init section contains machine code that performs initialization before the main() function and .fini runs after it.
.text: This section is where the main code of the executable resides that we've wrote. It's the main concern for binary analysis or reverse engineering efforts.
.bss, .data, .rodata: There sections are where the program variables live. According to the declaration style, the variable goes into one of the three sections. For example, initialized global variables live in .data, uninitialized global variables live in .bss and constant variables live in .rodata. Don't forget that the local variables go in the stack, so .text, not into one of these sections.
.rel.* and .rela.*: These sections contain the information used by the linker for performing relocations.
.dynamic: It contains the "road map" for dynamic linker when loading and setting up the ELF executable.

As an example, you can inspect a specific section with this command:

$ objdump -j .text -d ./prog

./prog:     file format elf64-x86-64

Disassembly of section .text:

0000000000001400 <.text>:
    1400:       f3 0f 1e fa             endbr64
    1404:       31 ed                   xor    %ebp,%ebp
    1406:       49 89 d1                mov    %rdx,%r9
    1409:       5e                      pop    %rsi
    140a:       48 89 e2                mov    %rsp,%rdx
    140d:       48 83 e4 f0             and    $0xfffffffffffffff0,%rsp
    1411:       50                      push   %rax
    1412:       54                      push   %rsp
    1413:       45 31 c0                xor    %r8d,%r8d
    1416:       31 c9                   xor    %ecx,%ecx
    1418:       48 8d 3d 48 15 00 00    lea    0x1548(%rip),%rdi        # 2967 <rand@plt+0x1577>
    141f:       ff 15 b3 fb 01 00       call   *0x1fbb3(%rip)        # 20fd8 <rand@plt+0x1fbe8>
    1425:       f4                      hlt
    1426:       66 2e 0f 1f 84 00 00    cs nopw 0x0(%rax,%rax,1)
    142d:       00 00 00 
    1430:       48 8d 3d d9 fb 01 00    lea    0x1fbd9(%rip),%rdi        # 21010 <rand@plt+0x1fc20>
    1437:       48 8d 05 d2 fb 01 00    lea    0x1fbd2(%rip),%rax        # 21010 <rand@plt+0x1fc20>
    143e:       48 39 f8                cmp    %rdi,%rax
    1441:       74 15                   je     1458 <rand@plt+0x68>
    1443:       48 8b 05 96 fb 01 00    mov    0x1fb96(%rip),%rax        # 20fe0 <rand@plt+0x1fbf0>
    144a:       48 85 c0                test   %rax,%rax
    144d:       74 09                   je     1458 <rand@plt+0x68>
    144f:       ff e0                   jmp    *%rax
    1451:       0f 1f 80 00 00 00 00    nopl   0x0(%rax)

(...)

Program Headers

The program header table provides a segment view of the binary, as opposed to the section view provided by the section header table. It's defined as follow:

In here:

p_type: The type of segments. Common types: LOAD means the segment are intended to be loaded into memory, INTERP means the segment contains .interp section providing name of the interpreter that is to be used to load the executable, DYNAMIC means the segment contains the .dynamic section, which tells the interpreter how to parse and prepare the binary for execution, PHDR means the segment encompasses the program header table.
p_flags: The runtime access permissions for the segments. Common flags: X means executable, R means readable, W means writable or so on.
p_offset, p_vaddr, p_paddr, p_filesz, p_memsz: These equals to sh_offset, sh_addr, sh_size fields in the section headers.
p_align: It's equal to sh_addralign field.

You can see the program headers with this command:

$ readelf --segments --wide ./prog

Elf file type is DYN (Position-Independent Executable file)
Entry point 0x1400
There are 13 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  PHDR           0x000040 0x0000000000000040 0x0000000000000040 0x0002d8 0x0002d8 R   0x8
  INTERP         0x000318 0x0000000000000318 0x0000000000000318 0x00001c 0x00001c R   0x1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x000d30 0x000d30 R   0x1000
  LOAD           0x001000 0x0000000000001000 0x0000000000001000 0x019061 0x019061 R E 0x1000
  LOAD           0x01b000 0x000000000001b000 0x000000000001b000 0x004dfc 0x004dfc R   0x1000
  LOAD           0x020cc0 0x0000000000020cc0 0x0000000000020cc0 0x000350 0x000370 RW  0x1000
  DYNAMIC        0x020cd0 0x0000000000020cd0 0x0000000000020cd0 0x000200 0x000200 RW  0x8
  NOTE           0x000338 0x0000000000000338 0x0000000000000338 0x000030 0x000030 R   0x8
  NOTE           0x000368 0x0000000000000368 0x0000000000000368 0x000044 0x000044 R   0x4
  GNU_PROPERTY   0x000338 0x0000000000000338 0x0000000000000338 0x000030 0x000030 R   0x8
  GNU_EH_FRAME   0x01dee8 0x000000000001dee8 0x000000000001dee8 0x0005fc 0x0005fc R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
  GNU_RELRO      0x020cc0 0x0000000000020cc0 0x0000000000020cc0 0x000340 0x000340 R   0x1

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .note.gnu.property .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt 
   03     .init .plt .plt.got .plt.sec .text .fini 
   04     .rodata .eh_frame_hdr .eh_frame 
   05     .init_array .fini_array .dynamic .got .data .bss 
   06     .dynamic 
   07     .note.gnu.property 
   08     .note.gnu.build-id .note.ABI-tag 
   09     .note.gnu.property 
   10     .eh_frame_hdr 
   11     
   12     .init_array .fini_array .dynamic .got

Until here, I gave you the overall, a bit detailed, presentation about the ELF executable. For next articles, I will dive into the binary analysis techniques in deeply for Linux.

Resource:

Andriesse D., Practical Binary Analysis, no starch press, San Francisco.

How to build a firmware using Makefile?

Can Gulmez — Sun, 21 Dec 2025 12:46:38 +0000

In embedded programming, we trust IDEs like STM32CubeIDE, Keil or so on. These IDEs give us just some buttons and UIs to build, flash, and debug the source code that we've written for a MCU. But, I think that every engineer that works on this field have to know that how these steps are made by hand.

In this tutorial, I will show building a firmware written for STM32F446RE MCU with just using a single Makefile.

Below is the project directory:

$ tree
.
├── bin/
├── drivers/
│   ├── CMSIS/
│   ├── STM32F446RETX_FLASH.ld
│   └── STM32F4xx_HAL_Driver/
├── lib/
├── Makefile
└── src/
    ├── it.c
    ├── main.c
    ├── main.h
    └── peripheral.c

Firstly, which libraries do we need to have?

HAL library
CMSIS library
Linker script
Startup/system code
arm-none-eabi-* tools

I've put the all required libraries/scripts into /drivers directory. Please download these using:

$ git clone --recurse-submodules https://github.com/STMicroelectronics/STM32CubeF4.git
$ sudo apt install gcc-arm-none-eabi

In here, HAL library is used to program the peripherals and CMSIS for ARM-Cortex itself. These are the most important libraries that we have to get.

Apart from that, we also need some special files. First is the linker script. It includes the memory layout of microcontroller. Sometimes, it comes from above command. But if you cannot find it there, please install it externally. Another file is the startup code. It's written in Assembly language. As its name suggests, it's the first code that runs in microcontroller. Basically, it includes the Reset_Handler and a branch that jumps into main() function in your source code. Also system code includes the some generic and general definitions.

After downloaded and explained the required ones, Let's write the Makefile step by step:

1. Toolchain definitions

CC              := arm-none-eabi-gcc
OBJCOPY         := arm-none-eabi-objcopy
SIZE            := arm-none-eabi-size
RM              := rm -f
FILE            := file

2. MCU-specific definitions

DEVICE_FAMILY        := STM32F4xx
DEVICE_MODEL         := STM32F446xx
DEVICE_VARIANT       := STM32F446RETx

3. Compiler and linker flags

CORTEX_FLAGS         := -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard
COMMON_FLAGS         := -g3 -Os -ffunction-sections -fdata-sections -Wall
AS_FLAGS             := -x assembler-with-cpp

In here, we've defined some flags:

-mthumb means that the firmware uses thumb (16-bit) instruction set.
-mcpu=cortex-m4 means the ARM-Cortex series itself.
-mfpu=fpv4-sp-d16 and -mfloat-abi=hard means that floating-point operations can be done in the firmware.

4. Include paths

MAIN_INC        := ./src
CMSIS_INC       := ./drivers/CMSIS/Include
CMSIS_DEV_INC   := ./drivers/CMSIS/Device/ST/STM32F4xx/Include
HAL_INC         := ./drivers/STM32F4xx_HAL_Driver/Inc
CMSIS_DSP_INC   := ./drivers/CMSIS/DSP/Include

In here, we specified the header files that are used in the source code.

5. Source and special files

MAIN_SRC        := $(wildcard ./src/*.c)
HAL_SRC         := $(wildcard ./drivers/STM32F4xx_HAL_Driver/Src/*.c)
SYSTEM_SRC      := ./drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/system_stm32f4xx.c
STARTUP_CODE    := ./drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/gcc/startup_stm32f446xx.S
LINKER_SCRIPT   := ./drivers/STM32F446RETX_FLASH.ld

6. Sorthands and build definitions

DEFINES         := -D$(DEVICE_FAMILY) -D$(DEVICE_MODEL) -D$(DEVICE_VARIANT) \
                        -DUSE_HAL_DRIVER

SOURCES         := $(MAIN_SRC) $(HAL_SRC) $(SYSTEM_SRC)
OBJECTS         := $(notdir $(patsubst %.c,%.o,$(SOURCES))) startup_stm32f446xx.o
INCLUDES            := -I$(MAIN_INC) -I$(CMSIS_DEV_INC) -I$(CMSIS_INC) -I$(HAL_INC) \
                        -I$(CMSIS_DSP_INC)

CFLAGS          := $(CORTEX_FLAGS) $(COMMON_FLAGS) $(DEFINES) $(INCLUDES)
AFLAGS          := $(CORTEX_FLAGS) $(AS_FLAGS) $(DEFINES) $(INCLUDES)
LDFLAGS         := $(CORTEX_FLAGS) -T $(LINKER_SCRIPT) \
                        -Wl,--gc-sections,--relax --specs=nano.specs --specs=nosys.specs \
                    -Wl,--start-group -lc -lm -lnosys -Wl,--end-group

In here, I mostly did the string operations and manipulations. But some points are interesting and need some explanations:

Firstly, I've grouped the sources and libraries and converted the source file suffixes into object file formats.
Also, I've created three total flags that will be used for compiling, assembling, and linking phases.
In linker flags, I put the linker script. As you noticed, this step will be done after the compiling the source files. I also linked the some libraries. -lc is the standard C library. In firmware, we use often string manipulation functions (strlen(), strcat(), strcpy() or so on), snprint(), memset(), or similar ones. -lm is the math library as you know. -lnosys means that I'm just implementing the bare-metal firmware, there is no such as kernel or fully OS.

7. Output files

FIRMWARE_ELF    := firmware.elf
FIRMWARE_BIN    := firmware.bin

Generally, we use the ELF file when flashing and debugging. ELF executable includes the both machine code, metadata, debug information, symbol table or similar stuffs. In contrast, BIN executable just includes the machine code. If you look at the size of both, you will use the ELF executable is much bigger!

8. The recipe

.PHONY: all

all:
    @echo "-------------------------------------"
    @echo "----- Building the source files -----"
    @echo "-------------------------------------"
    @$(CC) $(AFLAGS) -c $(STARTUP_CODE)
    @$(CC) $(CFLAGS) -c $(SOURCES)

    @echo "\n------------------------------------"
    @echo "----- Linking the object files -----"
    @echo "------------------------------------"
    @$(CC) $(LDFLAGS) $(OBJECTS) -o $(FIRMWARE_ELF)
    @$(OBJCOPY) -O binary $(FIRMWARE_ELF) $(FIRMWARE_BIN)
    @$(RM) $(OBJECTS)

    @echo "\n-------------------------------------"
    @echo "----- The firmware memory usage -----"
    @echo "-------------------------------------"
    @$(SIZE) $(FIRMWARE_ELF)

    @echo "\n-------------------------------------"
    @echo "----- The firmware binary format ----"
    @echo "-------------------------------------"
    @$(FILE) $(FIRMWARE_ELF)

Lastly, run the Makefile:

$ make

That's it 🥳🥳🥳. You've built the both firmware.elf and firmware.bin.

You are ready to flash the built firmware into microcontroller with this or similar command (over ST-Link connection):

$ openocd -f interface/stlink.cfg -f target/stm32f4x.cfg -c "program firmware.elf verify reset exit"

What exactly is "program" and what does it include?

Can Gulmez — Mon, 08 Dec 2025 14:05:17 +0000

In this article, I wanna talk about program and process terms that are fundamental elements in computer-science. This two terms generally are used exchangeably. But in technically, both are so different. Let's begin with explaining these terms and then deeply see the what it includes:

A program is a file containing a range of information that describes how to construct a "process" at run time [1].
A process is an instance of an executing program [1].

These are the formal definations. If I try to express with my words:

A program (or binary) is a file that includes the machine code + metadata + debug information (if the program compiled with -g flag) and process is a abstraction point that kernel creates and then allocates hardware resources like CPU, RAM, memory or similar ones.

First thing that you should know is the program format. In recently, there are two type of program formats that the compilers generate:

ELF (Executable and Linkable Format)
PE (Portable Executable)

Executable and Linkable Format

ELF is the standard format for UNIX/Linux systems and PE for Windows. I'm currently on Ubuntu 24.10 (x86_64) so that I will explain and use ELF format. As you guest, I don't know really PE format. But there is a good reference handbook that you can look at. It's "Practical Binary Analysis" written by Dennis Andriesse.

After explained the program formats, right now, let's look at the inside of the program:

In general, any program includes these:

Executable header
Program headers
Sections
Section headers

Every ELF file starts with an executable header, which is just a structured series of bytes telling you that it's and ELF file, what kind of ELF file it is, and where in the files to find all the other contents [2].

You can exactly see the content of this header with readelf command:

$ readelf -h ./copy
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Position-Independent Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x1160
  Start of program headers:          64 (bytes into file)
  Start of section headers:          17496 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         13
  Size of section headers:           64 (bytes)
  Number of section headers:         37
  Section header string table index: 36

In there, first four digits (7f 45) of Magic series define the program format. You will see the probably different series if you are on Windows. Other properties is the self-explaining.

The code and data in an ELF program are logically divided into sections. Each section includes a specific part of your source code. And the sections in the binary are contained in the section header table. Some sections are used to execute the machine instructions and some for other information (like symbol table used by debugger). Let's look at the section headers:

$ readelf --sections --wide ./copy
There are 37 section headers, starting at offset 0x4458:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        0000000000000318 000318 00001c 00   A  0   0  1
  [ 2] .note.gnu.property NOTE            0000000000000338 000338 000030 00   A  0   0  8
  [ 3] .note.gnu.build-id NOTE            0000000000000368 000368 000024 00   A  0   0  4
  [ 4] .note.ABI-tag     NOTE            000000000000038c 00038c 000020 00   A  0   0  4
  [ 5] .gnu.hash         GNU_HASH        00000000000003b0 0003b0 000028 00   A  6   0  8
  [ 6] .dynsym           DYNSYM          00000000000003d8 0003d8 000180 18   A  7   1  8
  [ 7] .dynstr           STRTAB          0000000000000558 000558 0000d3 00   A  0   0  1
  [ 8] .gnu.version      VERSYM          000000000000062c 00062c 000020 02   A  6   0  2
  [ 9] .gnu.version_r    VERNEED         0000000000000650 000650 000030 00   A  7   1  8
  [10] .rela.dyn         RELA            0000000000000680 000680 0000d8 18   A  6   0  8
  [11] .rela.plt         RELA            0000000000000758 000758 0000d8 18  AI  6  24  8
  [12] .init             PROGBITS        0000000000001000 001000 00001b 00  AX  0   0  4
  [13] .plt              PROGBITS        0000000000001020 001020 0000a0 10  AX  0   0 16
  [14] .plt.got          PROGBITS        00000000000010c0 0010c0 000010 10  AX  0   0 16
  [15] .plt.sec          PROGBITS        00000000000010d0 0010d0 000090 10  AX  0   0 16
  [16] .text             PROGBITS        0000000000001160 001160 00043a 00  AX  0   0 16
  [17] .fini             PROGBITS        000000000000159c 00159c 00000d 00  AX  0   0  4
  [18] .rodata           PROGBITS        0000000000002000 002000 000040 00   A  0   0  4
  [19] .eh_frame_hdr     PROGBITS        0000000000002040 002040 000034 00   A  0   0  4
  [20] .eh_frame         PROGBITS        0000000000002078 002078 0000a8 00   A  0   0  8
  [21] .init_array       INIT_ARRAY      0000000000003d78 002d78 000008 08  WA  0   0  8
  [22] .fini_array       FINI_ARRAY      0000000000003d80 002d80 000008 08  WA  0   0  8
  [23] .dynamic          DYNAMIC         0000000000003d88 002d88 0001f0 10  WA  7   0  8
  [24] .got              PROGBITS        0000000000003f78 002f78 000088 08  WA  0   0  8
  [25] .data             PROGBITS        0000000000004000 003000 000010 00  WA  0   0  8
  [26] .bss              NOBITS          0000000000004020 003010 000010 00  WA  0   0 32
  [27] .comment          PROGBITS        0000000000000000 003010 00002b 01  MS  0   0  1
  [28] .debug_aranges    PROGBITS        0000000000000000 00303b 000030 00      0   0  1
  [29] .debug_info       PROGBITS        0000000000000000 00306b 000472 00      0   0  1
  [30] .debug_abbrev     PROGBITS        0000000000000000 0034dd 000184 00      0   0  1
  [31] .debug_line       PROGBITS        0000000000000000 003661 00017e 00      0   0  1
  [32] .debug_str        PROGBITS        0000000000000000 0037df 00031a 01  MS  0   0  1
  [33] .debug_line_str   PROGBITS        0000000000000000 003af9 00012f 01  MS  0   0  1
  [34] .symtab           SYMTAB          0000000000000000 003c28 000438 18     35  18  8
  [35] .strtab           STRTAB          0000000000000000 004060 00028c 00      0   0  1
  [36] .shstrtab         STRTAB          0000000000000000 0042ec 00016a 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  D (mbind), l (large), p (processor specific)

The main topic of this tutorial is the sections. So I wanna explain in deeply each one:

.init and .fini: The machine code in these sections are used before/after the main() function in program. Don't forget that we're not writing this sections. Compiler itself creates these to handle low-level (or hardware-specific) works. I don't know actually what both of them do!
.text: It is the main area where we focus on binary analysis and reverse-engineering stuffs and includes the your code in machine instruction representation. If you look at there, you see that it has voluminous area and thousands of lines of machine code even if it is small program.
.bss, .data and .rodata: These sections are writable and used to hold various variable in source code. .bss includes the static and global uninitialized and .data includes the static and global initialized variables. Also .rodata consists of variables defined with const keyword in code.
.dynamic: This is the "road map" for the kernel and dynamic linker when loading and setting up an ELF binary for executions.
.init_array and .fini_array: These contains an array of pointers to functions to use as constructors/destructors. You maybe know that how to create constructor and destructor using compiler specific-tool, line one __attribute__((constructor)) void run_before_main(void);.
.shstrtab, .symtab, .strtab, .dynsym and .dynstr: The .shstrtab section is simply an array of NULL-terminated strings that contain the names of all the sections in binary. The .symtab contains a symbol table and .strtab contains the symbolic names. The .dynsym and .dynstr are analogous to .symtab and .strtab, except that they contain symbols and strings needed for dynamic linking rather than static linking.
.debug_: These sections are used primarily by debugger (GDB) so that it has not include and machine code but just metadata about program that debugger can use later. If you don't compile the program with -g option, these sections will not there.

Below is a part of .text section:

$ objdump -j .text -d ./copy

./copy:     file format elf64-x86-64

(...)

Disassembly of section .text:

0000000000001249 <main>:
    1249:f3 0f 1e fa          endbr64
    124d:55                   push   %rbp
    124e:48 89 e5             mov    %rsp,%rbp
    1251:48 81 ec 40 04 00 00 sub    $0x440,%rsp
    1258:89 bd cc fb ff ff    mov    %edi,-0x434(%rbp)
    125e:48 89 b5 c0 fb ff ff mov    %rsi,-0x440(%rbp)
    1265:64 48 8b 04 25 28 00 mov    %fs:0x28,%rax
    126c:00 00 
    126e:48 89 45 f8          mov    %rax,-0x8(%rbp)
    1272:31 c0                xor    %eax,%eax
    1274:83 bd cc fb ff ff 03 cmpl   $0x3,-0x434(%rbp)
    127b:75 24                jne    12a1 <main+0x58>
    127d:48 8b 85 c0 fb ff ff mov    -0x440(%rbp),%rax
    1284:48 83 c0 08          add    $0x8,%rax
    1288:48 8b 00             mov    (%rax),%rax
    128b:48 8d 15 72 0d 00 00 lea    0xd72(%rip),%rdx        # 2004 <_IO_stdin_used+0x4>

(...)

In here, we see the three columns that show the machine instructions of your program. At left side, you see the addresses of machine instructions. When running the program, stack pointer tracks these addresses. At center, you see the actual machine instructions corresponding to your code. Program counter register tracks this machine instructions. At right side, you see the assembly-level representations. When dealing with reverse-engineering, we inspect these to understand what program does.

Virtual Memory Layout

After discussed the ELF program format, right now, I will explain the virtual memory layout of a process (running program instance). When you run the program, kernel creates a memory layout as below:

I've explained the .text, .data, .bss, and .rodata sections previously. Apart from these, you see the stack and heap areas.

Both are the memory areas that kernel uses to execute the machine instructions. Stack area has LIFO (Last-In First-Out) model. When executing the program, kernel pushes/pops the instructions in here. So it grows up to lower address space. Heap area is completely different! It has FIFO (First-In First-Out) model. Kernel uses this memory space for dynamic allocation with malloc()/free() function family. And it grows up to upper address space. The heap address border is claimed by brk() function.

Until here, I wanna give you a general overview about programs and processes. If you want to dive in more, you can check and look at the below references.

[1]. Kerrisk M., The Linux Programming Interface, no starch press, San Francisco, page 113.
[2]. Andriesse D., Practical Binary Analysis, no starch press, San Francisco, page 33.