Coder Legion - Recent posts tagged low-level

qodon - a CLI based genomics tool

Thu, 24 Sep 2026 10:22:41 +0000

qodon (qdn) 🧬

A Command Line Genomics tool. Written in C

qodon (invoked as qdn) is an ultra-fast, lightweight command-line utility for quick genomic sequence manipulations. Written in pure C, it processes sequence arguments natively at bare-metal speeds, making it perfect for rapid testing, scripting, and pipeline integration.

✨ Features

Zero Overhead: Built in standard C for maximum execution velocity.
Dual-Mode Engine: Run quick one-off commands from your terminal or drop into a stateful interactive shell context.
Instant Evaluation: High-performance byte manipulation for zero-lag sequence transformations.
Core Bio-Utilities: Fast sequence transcription, complementing, reversing, and metric calculations.

🚀 Installation

You can install qodon directly or build from the source code.

1. Direct Install (Linux, x86_64)

Install precompiled binaries by running:

curl -L -o qdn https://github.com/Temi-Tade/qodon/releases/download/v0.2.0/qdn && chmod +x qdn && sudo mv qdn /usr/local/bin/

2. Build from source

Compile qdn natively using any modern C compiler (gcc or clang required):

# Clone the repository
git clone https://github.com/Temi-Tade/qodon.git
cd qodon

# Compile the binary with optimizations
gcc src/main.c -O3 src/lib/qodon.c src/lib/shell.c -o bin/qdn

# Move to your local bin to run it globally
sudo mv qdn /usr/local/bin/

Usage

🐚 Mode 1: Interactive Context Shell

Launch qdn with the -i flag followed by a target sequence to open the interactive context shell. The sequence is loaded directly into the session's workspace memory, allowing you to run rapid back-to-back operations against that specific strand without retyping it.

$ qdn -i ATGCATGC
Entering qodon shell...
Template sequence: ATGCATGC 
Length: 8bps 
GC content: 50.00%
qdn> len
8bps
qdn> cmp
ATGCATGC (Template strand)
||||||||
TACGTACG (Complementary strand)
qdn> gc
50.00%
qdn> rev
ATGCATGC (FWD)
CGTACGTA (REV)
qdn> exit
$

Available Shell Commands

Inside the shell, execute operations directly on the initialized sequence:

Command	Action	Description
cmp	Complement	Generates the complementary DNA/RNA strand
tr	Transcribe	Transcribes DNA to RNA (converts T to U)
rt	Reverse Transcribe	Reverse transcribes RNA to DNA (converts U to T)
rev	Reverse	Reverses the sequence direction
len	Length	Computes the total length of the sequence
gc	GC-Content	Calculates the exact GC content percentage
exit	Exit	Closes the interactive shell session

🛠️ Mode 2: Quick Terminal Flags

For quick one-offs or integration into larger bash scripts, pass an operational flag followed by your target nucleotide sequence string directly to your terminal:

qdn [flag] <SEQUENCE>

Core Flag Operations

Flag	Shell Command	Action	Description
-c	cmp	Complement	Generates the complementary DNA/RNA strand
-t	tr	Transcribe	Transcribes DNA to RNA (converts T to U)
-u	rt	Reverse Transcribe	Reverse transcribes RNA to DNA (converts U to T)
-l	len	Length	Computes the total length of the sequence
-g	gc	GC-Content	Calculates the GC content percentage
-i		Shell Mode	Enter interactive shell

💻 One-off Examples

Get Complementary Strand:

qdn -c ATGC
# Output: TACG

Transcribe DNA to RNA:

qdn -t GATTACA
# Output: CUAAUGU

Reverse Transcribe RNA to DNA

qdn -u UUAGC
# Output: AATCG

Calculate GC Content:

qdn -g CCGGTT
# Output: 66.67%

Get Sequence Length:

qdn -l ATGCATGC
# Output: 8bps

📄 License

This project is licensed under the MIT License.

What Math Actually Buys You: Optimizing a Rock-Paper-Scissors Game in C

Sat, 19 Sep 2026 12:32:40 +0000

I was looking through my old projects and found a couple of Rock-Paper-Scissors games I wrote in C a few years back. Why more than one? Because programming is fun, but also because I was experimenting. We're going to look at both versions and talk about how math actually shows up in code. This will not be some generic "you should know math" lecture, but a before/after comparison grounded in my humble experience.

Why this matters if you're self-taught

If you're a fresh CS student or a self-taught developer, there's a decent chance you don't fully buy that math concepts matter day to day. Fair. Here's how I think about it: programming gives you a lot of room to be creative in how you solve problems, but your creativity is powered by what you actually know. Knowledge is the raw material here and math is one of the biggest sources of that raw material.

Here's an example: if you wanted to write a loop in Rust with unusual control flow, and you didn't know that Rust's while is really just shorthand for the common pattern using loop + if + else + break, you'd spend a long time fighting while to do something it wasn't built for. If you knew that, you'd just build the custom loop you actually need.

Or the other direction: a senior dev once took a buggy 12-line React component I wrote and refactored it into 3 correct lines, because he knew which hooks and methods to reach for. Your imagination still needs building blocks to arrange. Math, at a certain stage, is where a lot of those blocks come from. It gives you a precise, calculable, universal way to reason about and express a problem instead of just poking at it until it works.

Let's look at actual code. The full source code for both implementations is public on GitHub here

Iteration 1: the naive version

Here's the main function of the first version I wrote:

int main(void) {
  srand(time(NULL));
  int random_int = (rand() % ((length_options + 1) - 1)) + 1;

  int option;

  printf("Let's play Rock Paper Scissors!\n");
  printf("First to 3 points wins!\n");

  while ((option != 1 && option != 2 && option != 3) ||
         (player_score != 3 && my_score != 3)) {

    round_number += 1;

    printf("\n===============\n");
    printf("Round %d\n", round_number);

    printScores();
    printOptions();

    scanf("%d", &option);

    if (option == 0 || option > length_options) {
      printf("\nPlease select a number ranging from 1 to 3 according to your "
             "desired option.\n\n");
    } else {
      printf("\nYou picked %s\n", options[option - 1].name);
      printf("I picked %s\n", options[random_int - 1].name);
      declare_round_winner((option - 1), (random_int - 1));
    }
    printf("\n===============\n");
  }

  printScores();
  declare_overall_winner();
  return 0;
}

Quick heads up before I explain anything: there's a bug in this loop condition. option is declared but never given a value before the while check reads it:

while ((option != 1 && option != 2 && option != 3) || ...)

Reading an uninitialized variable in C is undefined behavior. It happens to "work" here because whatever garbage value is sitting in that memory slot almost never equals 1, 2, or 3, so the loop starts anyway. But that's luck, not correctness. If you're newer to C, this is a good example of a bug that won't show up as a crash, it'll just quietly rely on the right garbage value. Moving on.

The supporting pieces are what you'd expect: an Option struct holding a name and value, an array of three options (Rock, Paper, Scissors), score counters, a printScores function, a printOptions function that loops over the array so adding a fourth option later doesn't require touching the print logic, and input validation that re-prompts on an out-of-range choice.

The main focal point for this post is how the winner gets decided:

int check_rules(int player_option, int my_option) {
  switch (player_option) {
  case 0:
    if (my_option == 0) return 0;
    else if (my_option == 1) return 1;
    else return -1;
  case 1:
    if (my_option == 0) return -1;
    else if (my_option == 1) return 0;
    else return 1;
  case 2:
    if (my_option == 0) return 1;
    else if (my_option == 1) return -1;
    else return 0;
  default:
    return 0;
  }
}

This checks every possible value of player_option against every possible value of my_option and returns -1 (loss), 0 (draw), or 1 (win). It's ugly, but it's also the most direct solution I could think of at the time. It also doesn't scale. Let's say you wanted to play the more advanced and respected version of the game: Rock-Paper-Scissors-Lizard-Spock, you'd have to add Lizard and Spock. You'd also have to rewrite every branch. Sheldon wouldn't approve.

Iteration 2: what changed, and why

Instead of guessing which part needed optimizing, I looked at the code and realized the winner-check was the ugliest and least scalable part of it so I wrote out every possible outcome as a table:

	Rock	Paper	Scissors
Rock	Draw	Rock Loss	Rock Win
Paper	Paper Win	Draw	Paper Loss
Scissors	Scissors Loss	Scissors Win	Draw

Then I substituted numbers for the outcomes (Win = 1, Draw = 0, Loss = -1):

	Rock	Paper	Scissors
Rock	0	-1	1
Paper	1	0	-1
Scissors	-1	1	0

That's a lookup table. I originally called this "a matrix," but I want to be more precise here than I was when I first wrote this, because the interesting math isn't that it has a nice grid-looking shape. It's that the values in this grid aren't arbitrary. Notice the pattern. It's skew-symmetric (flip any cell across the diagonal and the sign flips), and it repeats in a cycle. This is called modular arithmetic. If you assign Rock = 0, Paper = 1, Scissors = 2, the outcome of any matchup is:

outcome = (player - opponent + 3) % 3

Where a result of 1 means the player wins, 2 means the player loses, and 0 is a draw (you'd remap those three values to +1/0/-1 to match the table above). That's the math concept doing the work here: a cyclic relationship expressed with the modulo operator, the same operation that underlies clock arithmetic, hashing, and a good chunk of the number theory that shows up in cryptography (RSA leans on modular exponentiation directly). A 3x3 lookup table is one way to encode that relationship.

In code, the lookup table version looks like this:

int rules_matrix[3][3] = {{0, -1, 1}, {1, 0, -1}, {-1, 1, 0}};

int check_rules_matrix(int x, int y) {
  return rules_matrix[x][y];
}

void update_scores(int outcome) {
  switch (outcome) {
  case 1:
    computer_score += 1;
    printf("\nI won this round!\n");
    break;
  case -1:
    player_score += 1;
    printf("\nYou won this round!\n");
    break;
  default:
    printf("\nDraw\n");
    break;
  }
}

void declare_round_winner(int c_option, int p_option) {
  update_scores(check_rules_matrix(c_option, p_option));
}

Determining a winner is now a single array access instead of nine branches. Add Lizard and Spock, and you're extending a 3x3 table to a 5x5 table and updating the options array. No switch statements to rewrite.

Does it actually matter?

I wanted to check the performance claim instead of just asserting it, so I benchmarked both approaches directly, 100 million calls each, isolated from I/O:

#define ITERATIONS 100000000

int check_rules_switch(int player_option, int my_option) {
  switch (player_option) {
  case 0:
    if (my_option == 0) return 0;
    else if (my_option == 1) return 1;
    else return -1;
  case 1:
    if (my_option == 0) return -1;
    else if (my_option == 1) return 0;
    else return 1;
  case 2:
    if (my_option == 0) return 1;
    else if (my_option == 1) return -1;
    else return 0;
  default:
    return 0;
  }
}

static const int rules_matrix[3][3] = {
    { 0, -1,  1},
    { 1,  0, -1},
    {-1,  1,  0}
};

int check_rules_matrix(int x, int y) {
  return rules_matrix[x][y];
}

Results, run three times:

1. Switch/Branching Method: 0.343620 seconds (3.44 ns per call)
2. Matrix Lookup Method:    0.275987 seconds (2.76 ns per call)

3. Switch/Branching Method: 0.342246 seconds (3.42 ns per call)
4. Matrix Lookup Method:    0.272867 seconds (2.73 ns per call)

5. Switch/Branching Method: 0.340185 seconds (3.40 ns per call)
6. Matrix Lookup Method:    0.272581 seconds (2.73 ns per call)

The lookup table wins consistently, by about 0.7 nanoseconds per call, roughly a 20% improvement in this specific isolated benchmark. But let's be clear on what that means. 0.7 nanoseconds is nothing in absolute terms. In a real Rock-Paper-Scissors game bottlenecked by scanf waiting on a human, this difference is completely invisible.

So yeah this isn't exactly going to save your production system (unless that's a specific problem your system has). The main point is that recognizing the modular structure of the problem gave me a solution that was simultaneously simpler to read, easier to extend, and measurably faster, all from the same insight. And that's how math helps. Besides making code faster, it also changes what kind of solution occurs to you in the first place.

This is the fact I keep noticing as I move further into security work. A lot of what looks like "cleverness" in an optimized or exploited system is really just someone noticing the underlying structure before anyone else bothered to look for it.

Addendum: what if you skip the table entirely?

If the outcome is really just modular arithmetic, why store a table at all? You can compute the result directly:

int check_rules_mod(int x, int y) {
  return ((x - y + 4) % 3) - 1;
}

Same return convention as check_rules_matrix (1 if x wins, -1 if y wins, 0 for a draw). I checked this against all 9 possible matchups by brute force and it matches exactly, so correctness isn't in question.

Performance is where this got more interesting than I expected, and where I want to be upfront about the limits of what I actually understand.

While putting this post together, I recompiled the exact same switch-vs-matrix benchmark file from above with the -O2 optimization flag, mostly out of curiosity, and the ranking completely inverted:

1. Switch/Branching Method: 0.119248 seconds (1.19 ns per call)
2. Matrix Lookup Method:    0.133597 seconds (1.34 ns per call)
 
1. Switch/Branching Method: 0.120751 seconds (1.21 ns per call)
2. Matrix Lookup Method:    0.128811 seconds (1.29 ns per call)
 
1. Switch/Branching Method: 0.122600 seconds (1.23 ns per call)
2. Matrix Lookup Method:    0.132499 seconds (1.32 ns per call)

The only thing I changed was adding the build flag, and switch went from consistently losing to consistently winning. I don't yet know enough about what the compiler is actually doing under -O2 to explain that properly, branching, inlining, and instruction-level optimization are a whole subject I haven't put real time into, and I'd rather say that plainly than dress up a guess as an explanation.

I also wanted numbers for the modular version above, not just correctness. Getting a fair three-way comparison meant controlling for whether the compiler inlines each function, which isn't something I know how to force myself yet, so I had AI help write a benchmark harness that pins that down explicitly. I compiled and ran it on my own machine, these are the numbers I got:

All three functions forced to inline (best case):

1. Switch/Branching Method: 1.293 ns per call
2. Matrix Lookup Method:    1.339 ns per call
3. Modular Arithmetic:      1.261 ns per call

All three functions forced to be real function calls:

1. Switch/Branching Method: 2.261 ns per call
2. Matrix Lookup Method:    1.697 ns per call
3. Modular Arithmetic:      1.793 ns per call

Same story as the -O2 flip: which one wins depends on a compiler decision, not on the code itself. Inlined, switch is fastest and mod edges out matrix. Forced into real function calls, matrix takes over and switch falls behind badly. Mod never loses badly either way, but I'm not going to dress that up as "modular arithmetic is the safe choice performance-wise" when I can't yet explain why the ranking moves the way it does.

Consider this a flag rather than a finding: something real is going on here, across two separate build decisions, it's outside what I currently know, and it's on the list for a proper, dedicated post once I've actually built the compiler knowledge to back it up instead of just reporting numbers I can't fully explain.

Cover photo by Antony Hyson Seltran on Unsplash

Are computers truly random? How chaos powers randomness.

Fri, 17 Jul 2026 14:51:34 +0000

You would have come across randomness on a computer at a particular point; whether it is playing a game where assets spawn at random locations, writing code that requires random numbers, shuffling a playlist to play a random song next, the whole shebang. Computers use random numbers in everyday applications.

This article contains an affiliate link to purchase OneKey crypto hardware wallets, at no extra cost to you. This helps support my articles.

This begs the question of “are computers truly random?”. How can a device with wires, circuits, logic gates and transistors that are switching on and off billions of times a second able to generate random numbers?

Let me put you out of your misery, computers are not random, on their own at least.

Computers are deterministic.

This is a fancy way of saying that for a given set of inputs, a computer would always produce the same output. A computer cannot just create a number out of thin air. It needs a starting number (seed) and a formula to produce a “random" number. At a high level, this is how Pseudo Random Number Generators (PRNGs) work.

The paradox.

This means that if someone knows the starting number and the formula the computer uses to generate a random number, one can actually generate every random number the computer has generated in the past and would ever generate.

For average users like you and I, this is not a problem in our games and streaming platforms. However for advanced folks, this is an issue as they can literally ‘crack’ the system.

Computers use random numbers beyond games and shuffling your playlist. Web3 wallets use random numbers to generate private keys, Password salts involve the use of random numbers among other secure applications.

Imagine if someone could predict every private key you would ever generate on your device, that’s basically a disaster waiting to happen.

The solution: Entropy

Computers are deterministic and attackers can steal information from memory to predict future random numbers. How then do computers generate “secure random numbers"?

The solution is to look outside its CPU and memory walls and get real-world data.

The world we live in is a chaotic mess of ever-changing data: temperature, photons hitting a surface, traffic data among others.

Computers can use this data to generate random numbers that are secure and unpredictable.

How?

The computer takes real-world data around it using sensors and its hardware, the data is passed into an entropy pool in the operating system and the pool is hashed using a mathematical function. When the computer needs a random number, it takes a snapshot of the pool, applies a mathematical formula with a counter and spits it out.

Why this beats math for security.
Like I said earlier, an attacker could grab the starting number and formula from memory and generate every random number the computer would ever generate.

Using chaotic, real-world data that the OS dumps into its entropy pool, the computer can generate random numbers by looking outside its own self.

A classic example of this is how Cloudflare uses Lava lamps - https://www.cloudflare.com/learning/ssl/lava-lamp-encryption/ to create secure internet connections.

How secure is this?

This method of computer randomness is so secure that it is used to generate private keys for web3 wallets, encrypt passwords and other high-risk security applications.

How does it handle duplicates? Random data is added to the entropy pool every few milliseconds and the hashing formula has a property called the avalanche effect — addition of a small new data causes a big change in the output.

[1,3,6] — 0x1acd.... // current entropy pool

[1,3,6,1] — 0xc176....// entropy pool after addition of new data

Also, the key used with the counter to generate random bytes is destroyed every few seconds. The counter is a nonce (number that can be used once) that cannot be replayed once used.

All of these factors keep the Random Number Generator truly random, very secure and unbreakable.

Are humans any better?

If you are asked right now, to "quickly pick a random number between 1 and 20," your brain feels like it is making a completely free, chaotic choice. But cognitive psychologists have run this experiment thousands of times, and the results show that humans are incredibly predictable.

Our brains are hardwired pattern-recognition engines. We are physically incapable of "making something up" without being influenced by our recent memories, what we are looking at in the room, our cultural biases, and the neural wiring of our brains.

In a strange way, a computer using an entropy pool is actually mimicking us. It uses its "eyes and ears" (hardware sensors measuring heat and noise) to pick a number, just like we use our senses and subconscious memory to pick one.

So, who is truly random?
If "true randomness" means generating a number out of pure nothingness without any prior cause, then neither computers nor humans can do it. We both live in a physical universe governed by cause and effect.

In my next article, we will explore how crypto hardware wallets like OneKey, use randomness to generate secure private keys.

OneKey offers secure hardware wallets whose firmware and hardware designs are fully open-source and auditable right on GitHub. Backed by heavyweights like Coinbase Ventures and Dragonfly, they offer an incredible product lineup.

Click the link below to get 10% off OneKey hardware wallets.

Get 10% off OneKey Hardware wallets

# Breaking the 200ns Barrier: The Geometric Logic Behind Penta-V Kernel

Sat, 02 May 2026 04:58:03 +0000

After weeks of fighting the Rust borrow checker and optimizing atomic operations, I finally stabilized the Penta-V Kernel (pvk). In this post, I’ll dive deep into why traditional linear queuing fails under extreme jitter and how "Geometric Dissipation" provides a new path for structural immunity.

The Penta-V Kernel isn't just a library; it's a structural insurance policy for high-load systems. By combining geometric logic with Rust's performance, it provides a decisive edge in stability and resource management.

Core Technical Benefits & Deep-Dive

1. Beyond Linear Scaling (Geometric Poles)

Traditional load balancers fail when traffic spikes exceed their buffer capacity. Instead of static buffers, Penta-V reshapes its defensive posture based on system stressors.

Geometric Dissipation: As stress increases, the system "reshapes" itself from a Triangle to a Circle to ensure higher survival rates during sudden traffic surges.
The Benefit: Decoupling load logic from execution logic allows for easier auditing and faster incident response.

2. Thermal-Aware Resilience (The Cooling Protocol)

Software "heat" (computational stress) often leads to cascading failures. Penta-V integrates a proactive thermal-aware layer that mitigates load before the core reaches a critical state.

The Logic: By reducing system impact early, we eliminate the "thundering herd" problem and ensure predictable behavior under extreme stress.

3. Benchmarks & Zero-Cost Abstractions

Built in 100% Rust with no external dependencies, Penta-V offers high-level geometric logic with minimal latency.

Performance: Achieving sub-200ns latency (avg 188.58ns) on ![no_std] bare-metal environments.
Throughput: Capable of handling approximately 8.5 million operations per second with very low jitter.

️ Target Ecosystems & Applications

Cloud Infrastructure & Edge Computing: Prevents local node collapse in resource-constrained environments.
High-Frequency Trading (FinTech): Provides "Structural Immunity" during market volatility, ensuring the transaction pipeline remains in equilibrium.
Cyber-Defense: Unlike traditional buffers that drop packets, Penta-V escalates through geometric tiers to neutralize volumetric spikes.
Embedded Systems & IoT: Ideal for mission-critical hardware, allowing low-power processors to manage "Digital Heat" efficiently via the #![no_std] core.

️ Roadmap & Future Vision

This isn't just about speed; it's about building systems that are "immune" to systemic chaos. The next steps for the pvk architecture include:

Formal Verification: Hardening the "Geometric Poles" logic with rigorous mathematical proofs.
Wasm Integration: Bringing the Cooling Protocol to serverless environments via optimized WebAssembly targets.
Architect-Eye OS Integration: Implementing Penta-V as the core stability layer for the upcoming sovereign operating system.

Join the Architecture

If you are an engineer interested in sub-200ns systems and "Structural Immunity," I’d love to hear your feedback on the geometric approach.

Explore the Code: [https://github.com/narukihto/Penta-V-Kernel.git].
pypi.org: [https://pypi.org/project/penta-v-kernel]
Crates.io: [https://crates.io/crates/penta_v_kernel]
Connect: Emails are not allowed ** as we redefine system stability.

"Geometry is the remedy for systemic chaos."

Embedded Linux Development - Part 6

Tue, 21 Apr 2026 09:08:36 +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 your password (set in previous tutorial). 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. It 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. 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

Tue, 14 Apr 2026 13:21:14 +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 - Part4

Mon, 13 Apr 2026 17:18:30 +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

Mon, 13 Apr 2026 14:06:30 +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

Sun, 12 Apr 2026 19:13:05 +0000

In this tutorial, 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 tutorial, 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

Sun, 12 Apr 2026 12:59:13 +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 tutorial, 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 tutorial 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

Wed, 08 Apr 2026 12:50:12 +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.

The Linux Programming Interface - Time

Wed, 08 Apr 2026 10:43:35 +0000

In any type of program, we mostly are interested in two different time:

Real (Calendar) time: This time is measured from a standard point (generally, UTC, 1 January 1970). Obtaining the calendar time is primarily source of what you see at screen of your computer.
Process time: This is the amount of CPU time used by a process. Measuring process time is useful for checking or optimizing the performance of a program or algorithm.

Every computer has a dedicated built-in hardware clock that enables the kernel to measure real and process time.

Calendar Time and Time Conversion

To handle real time, the GNU libraries give us many functions as below:

These are also function signatures that we use when handling time in the program:

time_t time(time_t *tloc);
char *asctime(const struct tm *tm);
char *ctime(const time_t *timep);
struct tm *gmtime(const time_t *timep);
struct tm *localtime(const time_t *timep);
time_t mktime(struct tm *tm);
size_t strftime(char *s, size_t max, const char *format, const struct tm *tm);

The time() system call returns the number of seconds since the Epoch (1 January 1970) and then this number of seconds are stored in _time_t_ (typedef long time_t) data type.

To convert this number of seconds in printable format, we use the ctime() function.

We can also convert this number of seconds into a so-called broken-down time (struct tm) by using gmtime() and localtime() functions. After that, we see the year, month, week, hours and so on.

The mktime() function does vise-verse, translates a broken-down time into number of seconds.

We also use asctime() to convert broken-down time to printable format.

I put here a simple program that shows the how to use these functions I've described:

 /* Retrieving and converting calendar times */

 #include "../linux.h"

 #define SECONDS_IN_TROPICAL_YEAR    (365.24219 * 24 * 60 * 60)

void main(int argc, char *argv[])
{
   time_t t;
   struct tm *gmp, *locp;
   struct tm gm, loc;
   struct timeval tv;

   t = time(NULL);
   printf("Seconds since the Epoch: %ld", (long) t);
   printf(" (about %6.3f years)\n", t / SECONDS_IN_TROPICAL_YEAR);

   if (gettimeofday(&tv, NULL) == -1)
      syscall_error();
   printf(" gettimeofday() returned %ld secs, %ld microsecs\n",
      (long) tv.tv_sec, (long) tv.tv_usec);

   gmp = gmtime(&t);
   if (gmp == NULL)
      syscall_error();

   gm = *gmp;  /* Save local copy */

   printf("Broken down by gmtime():\n");
   printf(" year=%d, mon=%d, mday=%d, hour=%d, min=%d, sec=%d ", 
      gm.tm_year, gm.tm_mon, gm.tm_mday, gm.tm_hour, gm.tm_min, gm.tm_sec);
   printf(" wday=%d, yday=%d, isdst=%d\n", gm.tm_wday, gm.tm_yday, gm.tm_isdst);

   locp = localtime(&t);
   if (locp == NULL)
      syscall_error();

   loc = *locp;   /* Save local copy */

   printf("Broken down by localtime():\n");
   printf(" year=%d, mon=%d, mday=%d, hour=%d, min=%d, sec=%d ", 
      loc.tm_year, loc.tm_mon, loc.tm_mday, loc.tm_hour, loc.tm_min, loc.tm_sec);
   printf(" wday=%d, yday=%d, isdst=%d\n", loc.tm_wday, loc.tm_yday, loc.tm_isdst);

   printf("asctime() formats the gmtime() value as: %s\n", asctime(&gm));
   printf("ctime() formats the time() value as: %s\n", ctime(&t));

   printf("mktime() of gmtime() value: %ld secs\n", (long) mktime(&gm));
   printf("mktime() of localtime() value: %ld secs\n", (long) mktime(&loc));
   
   exit(EXIT_SUCCESS);
}

The strftime() function provides us with more precise control when converting a broken-down into printable form. We just put pre-defined specifiers into third argument of strftime() function. These specifiers:

Below is the another program that shows the function usage:

 /* A function that returns a string containing the current time */

 #include "../linux.h"

 #define BUF_SIZE  1000

/* Return a string containing the current time formatted according to
   the specification in 'format' (see strftime(3) for specifiers).
   If 'format' is NULL, we use "%c" as a specifier (which gives the
   date and time as for ctime(3), but without the trailing newline).
   Returns NULL on error. */

char *currTime(const char *format)
{
   static char buffer[BUF_SIZE];
   time_t t;
   size_t s;
   struct tm *tm;

   t = time(NULL);
   tm = localtime(&t); 
   if (tm == NULL)
      return NULL;

   s = strftime(buffer, BUF_SIZE, (format != NULL) ? format : "%c", tm);
   
   return (s == 0) ? NULL : buffer;
}

Timezones

Different countries operate on different timezones and DST regimes. Programs that input and output times must take care of this.

Timezone information tends to be both voluminous and volatile. So rather than encoding it directly into libraries, the system maintains this information in files under /usr/share/zoneinfo.

To specify a timezone when running a program, we set the TZ environment variable to a string consisting of a colon followed by one of the timezone names (like TZ=":Pacific/Auckland").

The tzset() function is used to obtain the current timezone setting. This function initializes three global variables:

char *tzname[2];
int daylight;
long timezone;

This function first checks the TZ environment variable. If this variable is not set, then the timezone is initialized to the default defined in the timezone file /etc/localtime. If the TZ environment variable is defined with a value that can't be matched to a timezone file, or it is an empty string, then UTC is used.

Locales

Different countries use different conventions for displaying information such as numbers, currency amounts, dates, and times.

Ideally, all programs designed to run in more than one location should deal with locales in order to display and input information in the user's preferred language and format. This constitutes the complex subject of internationalization (I18N).

Like timezone information, locales are maintained under /usr/share/locale. Under each locale subdirectory is a standard set of files that specify the conventions for this locale:

The setlocale() function is used to both set and query program's current locale. Below is the its function signature:

char *setlocale(int category, const char *locale);

There are two different methods of setting the locale. The locale argument may be a string specifying one of the locales defined under /usr/lib/locale or more conveniently selocale(LC_ALL, "") meaning that locale settings should be taken from environment variables.

Process Time

Process time is the amount of CPU time used by a process since it was created. For recording purposes, the kernel separates CPU time into the following two components:

User CPU time (amount of time spent executing in user mode)
System CPU time (amount of time spent executing in kernel mode)

Sometimes, we refer to process time as the total CPU time consumed by the process.

When dealing with process time, times() and clock() functions are used. Signatures are below:

clock_t times(struct tms *buf);
clock_t clock(void);

The times() system call retrieves process time information (both user and system time separately) and store it into struct tms.

Otherwise, clock() function is simpler and returns the total amount of CPU time. Below is the basic program that shows both of these functions.

 /* Retrieving process CPU times */

 #include "../linux.h"

void displayProcessTimes(const char *msg)
{
   struct tms t;
   clock_t clockTime;
   static long clockTicks = 0;
   
   if (msg != NULL)
      printf("%s", msg);

   if (clockTicks == 0) {  /* Fetch clock ticks on first call */
      clockTicks = sysconf(_SC_CLK_TCK);
      if (clockTicks == -1)
         syscall_error();
   }

   clockTime = clock();
   if (clockTime == -1)
      syscall_error();

   printf("clock() returns: %ld clocks-per-sec (%.2f secs)\n",
      (long) clockTime, (double) clockTime / CLOCKS_PER_SEC);

   if (times(&t) == -1)
      syscall_error();

   printf("times() yields: user CPU: %.2f; system CPU: %.2f\n", 
      (double) t.tms_utime / clockTicks, 
      (double) t.tms_stime / clockTicks);
}

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

   printf("CLOCKS_PER_SEC: %ld  sysconf(_SC_CLK_TCK): %ld\n\n",
      (long) CLOCKS_PER_SEC, sysconf(_SC_CLK_TCK));

   displayProcessTimes("At program start:\n");

   numCalls = (argc > 1) ? atoi(argv[1]) : 100000000;
   for (i = 0; i < numCalls; i++)
      (void) getppid();

   displayProcessTimes("After getppid() loop:\n");

   exit(EXIT_SUCCESS);
}

ELF Executable Analysis in Detail

Tue, 07 Apr 2026 11:58:08 +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 ).
r_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.

Simple Code Injection into ELF Executable

Mon, 06 Apr 2026 20:12:17 +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.

Interrupt Management in ARM Cortex-M

Mon, 06 Apr 2026 15:15:30 +0000

Interrupts is the must-known concept in embedded programming. So I wanna explain the interrupt management in ARM Cortex-M in this tutorial.

ARM architecture distinguishes between the two types: interrupt and system exception. Interrupts are primarily sourced by external hardware like UART that warns about arrival of data. System exceptions are more software-related and caused by ARM Cortex internal.

Interrupts and system exceptions are exchangeably used. But even if both of these do same thing (especially in programming), the differences are important for us, engineers!

I'll use "interrupt" word for both terms further, if otherwise declared.

Before diving into interrupts, you need to understand the general execution workflow of ARM Cortex. There are two types of execution modes: thread and interrupt. After resetting the microcontroller, execution flow starts in thread mode so that if you want to use interrupts, you need to enter the interrupt mode. But how?

When you flash your firmware into microcontroller (base address of 0x08000000, in case), ARM Cortex starts to execute the firmware's machine instructions in thread mode. If you want to use any interrupt, you have to explicitly say it to ARM Cortex by using Interrupt Service Routines (ISRs). ISRs are actually standard C functions, but have the special signatures. I'm gonna explain it later.

The most important question about interrupts is that why do we need interrupts?

The answer: Interrupts are the source of multiprogramming!

Interrupts give us second execution flow besides the main flow (executed in thread mode by default). It also gives the context switch mechanism for RTOS. I will explain it lastly.

ARM Cortex has a special hardware called Nested Vectored Interrupt Controller (NVIC). It handles and manages the all interrupt usage. Below is the its simple schematic:

Another important dedicated hardware is the EXTI Controller. The peripheral interrupts in the microcontroller directly are connected to NVIC. But If you want to use interrupts over microcontroller pins (like detecting rising or falling edge of a button), you have to use EXTI lines. Microcontroller pins are grouped and tied to specific EXTI lines. Please look at the reference manual to find it.

We have many different types of interrupts. For now, let's look at these:

ARM Cortex has defined 15 fixed system exceptions (coming from internal of Cortex). But microcontroller vendors specify also variable-length interrupts (coming from external of Cortex). For example, STM32 series microcontrollers allow up to 256 interrupts.

But where are located these interrupts? The answer is the at vector table.

The vector table is an array of word data inside the system
memory, each representing the starting address of one exception type [1].

If you've flashed any firmware into microcontroller over OpenOCD + GDB, you've seen probably the this vector table. If you've not, let's see it exactly.

I have STM32F446RE microcontroller and ST-LINK connection. I've compiled a firmware (firmware.elf) to flash it. Open a terminal and type:

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

And open the second terminal and type:

$ arm-none-eabi-gdb firmware.elf

Lastly, type these into GDB session:

(gdb) target remote localhost:3333
(gdb) monitor reset halt
(gdb) load

After flashed the firmware into microcontroller, you will see:

Loading section .isr_vector, size 0x1c4 lma 0x8000000
Loading section .text, size 0x1080 lma 0x80001d0
Loading section .rodata, size 0x10 lma 0x8001250
Loading section .init_array, size 0x4 lma 0x8001260
Loading section .fini_array, size 0x4 lma 0x8001264
Loading section .data, size 0x10 lma 0x8001268
Start address 0x80011d0, load size 4716
Transfer rate: 9 KB/sec, 786 bytes/write.

Yeah! You see the interrupt vector table (_.isr_vector_) section was flashed at the base address of flash memory and other sections after the vector table. If you use any type of interrupt, the ARM Cortex gets the corresponding ISR handler from there so that ARM Cortex exactly knows the ISR handler addresses. You just need to select the required ISR handler function!

As I said before, ISR handlers are special type of C functions. But why? Because the handlers have predefined function prototypes. You have to use these function prototypes. Otherwise, ARM Cortex cannot find it and treated as normal C functions, not the ISR handlers.

These predefined handler prototypes are stored in the startup code. For STM32F446RE, it is _startup_stm32f446xx.S_ file. Below is a part of this startup code:

(...)

  .word  Reset_Handler
  .word  NMI_Handler
  .word  HardFault_Handler
  .word  MemManage_Handler
  .word  BusFault_Handler

(...)

  .word     CAN1_TX_IRQHandler                /* CAN1 TX                      */                         
  .word     CAN1_RX0_IRQHandler               /* CAN1 RX0                     */                          
  .word     CAN1_RX1_IRQHandler               /* CAN1 RX1                     */                          
  .word     CAN1_SCE_IRQHandler               /* CAN1 SCE                     */                          
  .word     EXTI9_5_IRQHandler                /* External Line[9:5]s          */                          
  .word     TIM1_BRK_TIM9_IRQHandler          /* TIM1 Break and TIM9          */         
  .word     TIM1_UP_TIM10_IRQHandler          /* TIM1 Update and TIM10        */         
  .word     TIM1_TRG_COM_TIM11_IRQHandler     /* TIM1 Trigger and Commutation and TIM11 */
  .word     TIM1_CC_IRQHandler                /* TIM1 Capture Compare         */                          
  .word     TIM2_IRQHandler                   /* TIM2                         */                   
  .word     TIM3_IRQHandler                   /* TIM3                         */                   
  .word     TIM4_IRQHandler                   /* TIM4                         */                   
  .word     I2C1_EV_IRQHandler                /* I2C1 Event                   */                          
  .word     I2C1_ER_IRQHandler                /* I2C1 Error                   */                          
  .word     I2C2_EV_IRQHandler                /* I2C2 Event                   */                          
  .word     I2C2_ER_IRQHandler                /* I2C2 Error                   */          

(...)

At the beginning, I've stated that interrupts are the source of multiprogramming. This is core logic behind the RTOS!

RTOSes use the interrupts to create many tasks. In classic firmware written with RTOS, there are many tasks that the RTOS kernel have to handle and manage. You can think that task in the firmware corresponds to process in the computers.

The RTOS kernel needs to execute these tasks in order and with same time-slice so that the kernel cuts the one task execution and passes to the next task execution using context switches. This is done by using interrupts. For example, FreeRTOS kernel uses SVC and PendSV interrupts specificly to make the contex switch. Apart from that, the RTOS kernel uses also the SysTick interrupt to give the equal execution time to each task.

Got it. I've explain the interrupt management in ARM Cortex-M in general. I put the some references below. You can look at the interrupts and similar topics in there.

References:

[1]. Yiu J., The Definitive Guide to The ARM Cortex-M3, Second Edition, Newnes, page 36.
Noviello C., Mastering STM32, 0.26 Release, Leanpub

How to build a firmware using Makefile?

Mon, 06 Apr 2026 15:13:09 +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"

I've also published a repository for that. You can look at it from here: https://github.com/CanGulmez/Embedded-Firmware-with-Makefile

Flashing and Debugging A Firmware in Detail

Mon, 06 Apr 2026 14:53:30 +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    hexfilename
   5252     20   1732   7004   1b5cfirmware.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      subsp, #68@ 0x44
 80007a0:f000 f8ac bl80008fc <HAL_Init>
 80007a4:f000 f82c bl8000800 <configOscClk>
 80007a8:f000 f844 bl8000834 <configDebugPort>
 80007ac:4911      ldrr1, [pc, #68]@ (80007f4 <main+0x58>)
 80007ae:4d12      ldrr5, [pc, #72]@ (80007f8 <main+0x5c>)
 80007b0:4c12      ldrr4, [pc, #72]@ (80007fc <main+0x60>)
 80007b2:4668      movr0, sp
 80007b4:f7ff ff08 bl80005c8 <strcpy>
 80007b8:4668      movr0, sp
 80007ba:f7ff ff81 bl80006c0 <strlen>
 80007be:f04f 33ff mov.wr3, #4294967295@ 0xffffffff
 80007c2:b282      uxthr2, r0
 80007c4:4669      movr1, sp
 80007c6:480d      ldrr0, [pc, #52]@ (80007fc <main+0x60>)
 80007c8:f000 fdc2 bl8001350 <HAL_UART_Transmit>
 80007cc:4629      movr1, r5
 80007ce:4668      movr0, sp
 80007d0:f7ff fefa bl80005c8 <strcpy>
 80007d4:4668      movr0, sp
 80007d6:f7ff ff73 bl80006c0 <strlen>
 80007da:f04f 33ff mov.wr3, #4294967295@ 0xffffffff
 80007de:b282      uxthr2, r0
 80007e0:4669      movr1, sp
 80007e2:4620      movr0, r4
 80007e4:f000 fdb4 bl8001350 <HAL_UART_Transmit>
 80007e8:f44f 707a mov.wr0, #1000@ 0x3e8
 80007ec:f000 f8b2 bl8000954 <HAL_Delay>
 80007f0:e7ec      b.n80007cc <main+0x30>
 80007f2:bf00      nop
 80007f4:0800146c .word0x0800146c
 80007f8:08001489 .word0x08001489
 80007fc:20000084 .word0x20000084

(...)

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 <command-name> 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.