How does one kind of absorb the material in the book properly? Would you guys take physical notes? Kind of struggling to know how to absorb the material properly lol

Hi

I've been working on a baseboard where I have an SoC running Linux and FPGA that uses external flash as a bitstream storage.

This flash is in fact shared between Linux and FPGA but not simultaneously. It is "muxed" so that it can only be accessible either by Linux or FPGA at once. This is designed so that the flash can be updated from Linux.

When the platform is booting, the mux is always switched so that the FPGA can access the flash and load its bitstream.  Whenever I want to update the flash I need to make it accessible physically (need to change the mux config) for Linux as well as "logically" -  meaning that the appropriate driver has to be loaded. Once the update is done, Linux should release the flash and no longer use it unless the update has to be repeated so the update sequence is roughly like this:

• change mux config

• bind driver

• write flash

• unbind driver

• change mux config again

I am trying to determine the correct way to model and implement this. I could implement most of the sequence in userspace, but the SPI device still needs platform-specific information such as the SPI controller, chip select, maximum clock frequency, and possibly a GPIO-based chip select provided by a GPIO expander.

One possible approach would be to describe the flash normally in the Device Tree with  "okay" status. The initial spi-nor probe would fail because the flash is connected to the FPGA during boot. Later, when an update is required, userspace could switch the mux and retry probing the existing SPI device:

• change mux

• echo spi0.2 > /sys/bus/spi/drivers_probe or echo spi0.2 >

/sys/bus/spi/drivers/spi-nor/bind

• update flash

• echo spi0.2 > /sys/bus/spi/drivers/spi-nor/unbind

• change mux again

but is this really a good option? I feel that I'm leaking hardware specific information to userspace, I'll have to hardcode some paths, driver names in flashing script / prepare separate script for each device (if there are differences between platforms) or carry platform hardware description config file so that the flashing tool could stay generic and read necessary info from config.

Other option would be to create a small platform driver and expose sysfs attribute called eg. target with values like:

• none meaning fpga takes control over flash

• primary meaning that primary flash is controlled by Linux

• secondary meaning that secondary flash is controlled by Linux

Internally I could use gpio or mux subsystems to control mux and call spi add / remove device functions that would probe for the driver

This would also give me more control over the SPI bus ownership.

What would be a better idea in your opinion? How would you approach this?

What do I need to know before reading Mastering Embedded Linux Development? What are the basics I need to know? Also, what are the other resources would you recommend reading simultaneously?

I have not had a chance to work with embedded and I'm dying to get into embedded linux. I have a Macbook Pro with processor 2 GHz Quad-Core Intel Core i5. What would you recommend setting up to do a few cool projects and learn more about embedded linux?

I've completed the following courses:

CS 3410: Computer System Organization and Programming,

CS 4410: Operating Systems,

CS 4414:  Systems Programming,

So I'm kind of wondering what is an appropriate start and recommendations for setting up?

Thanks!

Hi guys,

I'd like to share with you my personal solution to implementing and debugging binary communication protocols for embedded systems using C++(11) programming language. It's been in constant development as my side project for the last 12 years and is called CommsChampion Ecosystem. It started as a single C++ library to resolve some code boilerplating but grew into its own DSL (Domain Specific Language), multiple code generators for various purposes, and higher level libraries for some industry protocols like MQTT.

The primary features are:

• Suitable for third party protocols, i.e. doesn't impose any particular protocol structure and/or framing.
• Allows full control over I/O data for extra encryption and/or processing.
• Focus on robust handling of malformed data rather than optimizing for quickest data serialization.
• Easy integration with business logic requiring significantly reduced amount of boilerplate code.
• Allows customization of various storage types as well as avoiding dynamic memory allocation to make it suitable for bare-metal system without heap and limited RAM size.
• Allows injection of custom code if the generated one is incorrect or incomplete.
• Generation of "C" interface for C++ classes for easier integration with "C" codebase.
• Although C++ and embedded systems are first class citizens, there is support for other programming languages via bindings / glue code generated by SWIG or Emscripten.
• Visual "in-house" protocol analysis tool allowing custom I/O stack handling as well as generation of Wireshark dissector.
• Generation of LaTeX files for the defined protocol specification.
• Support for easy buildroot and yocto integration.
• The higher level protocol libraries follow specific pattern and philosophy dedicated to easy integration with any event loop infrastructure chosen for any particular embedded system.

Although already providing extensive set of features covering the needs for majority of the developers there is still room for extra new functionality. Any new feature requests are welcome.

Disclosure: We’re the team behind Cachely. We do not support Yocto today, but we’re researching whether it would be a useful integration.

We recently spoke with a team using Jenkins and Yocto that had been keeping the sstate cache locally on each build node.

That worked while build volume was low, but they are now moving to a centralized cache because the local setup no longer scales.

Their preferred model was:

• Nightly CI builds can read and write
• Developers can read, but not upload
• The cache is available over HTTP or FTP
• Setup should mostly be a URL and credentials
• Nobody wants to spend much time maintaining it

We’re trying to understand how common this setup is.

For teams using Yocto today:

• Where do you store the shared sstate cache?
• Are you using NFS, object storage, Nexus, or a basic HTTP server?
• Do CI and developer machines use the same cache?
• How do you separate read and write access?
• How do you handle retention and different Yocto or machine versions?
• Is on-prem storage a requirement?
• Is the main pain setup, maintenance, performance, or understanding why something missed?

We’re especially interested in whether an HTTP-compatible managed cache would solve a real problem, or whether shared storage is already simple enough for most teams.

Hi everyone,

I'm looking for advice from engineers who have made a similar transition.

\## Background

\- B.Tech in Electrical and Electronics Engineering (EEE) from NIT Calicut.

\- Around 2 years of experience in product companies.

## Current work

\- I'm working on cloud-managed networking products(switch , access points) at an MNC.

## My work involves:

\- Linux-based networking products.

\- C based agents running on networking devices.

\- Device discovery and monitoring.

\- Production debugging.

\- Configuration management between devices and the cloud.

\- Some changes in an existing C codebase.

\- Go-based packet capture using BPF libraries.

\- Understanding Linux-based networking systems.

## However, I'm not working on:

Firmware

RTOS

Device drivers

BSP

Bootloaders

Kernel development

## What I've realized

I think what actually interests me is lower-level work like:

\- Firmware

\- Device drivers

\- Embedded systems

\- Hardware-software interaction

I enjoy understanding how hardware actually works more than writing cloud-facing applications.

## My dilemma

I'm unsure about the best path from my current position.

Should I:

1. Continue in networking/systems software and try to move toward firmware gradually?

2. Learn firmware (STM32, FreeRTOS, peripherals, etc.) while staying at current company and then apply directly to firmware roles?

3. Target companies like Qualcomm, NVIDIA, AMD, Cisco, Broadcom, etc., in systems software first and then try for an internal move later?

4. Consider an M.Tech if I want to move closer to firmware or embedded systems?

## Questions

I'd appreciate answers from people who have actually worked in firmware or embedded systems.

1. Is my current networking/Linux background considered relevant for firmware or embedded systems roles?

2. If you were in my position, what would your roadmap be?

3. What skills would you prioritize over the next 12–24 months?

4. Am I underestimating how difficult this transition is?

5. If you've made a similar transition, what was your path?

I'm looking for honest opinions rather than encouragement. If you think my plan has flaws, I'd appreciate direct feedback.

TIA

I kept running into the same Linux debugging pain: something broke on a box, but I had no history of what actually happened. journald helps a little. auditd is heavy. strace is too narrow. So I built ltm — a small machine-history debugger that records process/file/network metadata via eBPF and lets you query it like a timeline.

What it does:

• Attaches to syscall tracepoints (exec, open/write/rename/unlink, connect/bind, etc.)

• Stores metadata only (no file contents)

• Lets you do things like:

sudo ltm start --mode ebpf

ltm status

ltm timeline --since 1h

ltm diff --from "10m" --to now

ltm query "who modified /tmp/ltm-demo.txt?"

On a real VM run it recorded ~7k events with 0 drops, and the query returned the exact bash write events that touched the demo file.

There's also a demo mode so you can exercise the CLI/storage/diff/query path without root or BPF.

Stack is Go + embedded BPF ELF + cilium/ebpf. Local store is append-only JSONL. Ignore rules skip /proc, /sys, /dev, and common caches.

Repo: https://github.com/Agent-Hellboy/ltm

Still early. Useful next steps I'm considering:

1. better diff/query formatting
2. containerized eBPF integration test
3. more query templates ("what opened this port?", "what restarted before X?")

Please do star the repo, it will help in discoverability

I'm trying to get ADB working on a Raspberry Pi Zero W (ARM1176JZF-S / ARMv6, Raspberry Pi OS Bookworm/Trixie).

Current Debian/Raspberry Pi packages install, but the modern adb binary crashes because it's built for ARMv7.

So far I've tried:

• Current Debian/Raspberry Pi adb
• Old Debian archive packages (Android 4.2 era) – still ARMv7
• Old GitHub ARM binaries – also ARMv7
• Searching for the old adbarmv6.7z binary that used to be linked on the Raspberry Pi forums/XDA (appears to be gone)

At this point I'm looking for any of the following:

• A working ARMv6 adb binary.
• An old Raspbian package that still supports ARMv6.
• Someone who has successfully built adb for ARMv6 recently.
• Another lightweight alternative that provides the standard adb commands (devices, shell, push, pull, install, etc.).

I'm happy to compile from source if there's a minimal build method that doesn't require downloading the entire Android source tree.

Any help or old binaries would be massively appreciated!

Also ive already posted this on r/raspberry_pi, but it didn't get much traction and i havent gotten a useful response so hopefully you can help!

Hello everyone! I'm working on a redundant network stack using the RT kernel patch and the hsr kernel module for redundancy. Both Ethernet devices can leave hardware timestamps for debugging purposes. My question is, is there a way to retrieve those timestamps from the userspace when working with a socket bound to the hsr virtual interface?

​

I have a background in embedded systems and currently work mainly on MCUs, writing firmware in C/C++. I'm comfortable with topics like peripherals, RTOS, debugging, communication protocols (UART, SPI, I2C, CAN), and general embedded development.

Now I want to transition into Embedded Linux and would like some guidance on the best learning path and resources.

Specifically, I'm interested in learning:

Linux internals relevant to embedded systems

Device drivers

Device Tree

Bootloaders (U-Boot, etc.)

Kernel basics

Build systems like Yocto or Buildroot

Debugging techniques (JTAG, GDB, tracing tools)

Practical projects that can help me gain hands-on experience

I prefer learning through books, courses, and real projects rather than just theoretical material.

For those who made a similar transition from bare-metal/RTOS development to Embedded Linux, what resources, books, courses, or project ideas would you recommend?

Hi everyone,
I’m working on an embedded Linux platform (Qualcomm SA8797) and validating I2C communication with MAX96861 devices.
I have successfully identified the I2C buses from the device tree and confirmed communication with two devices:
MAX96861_1 on /dev/i2c-0 (7-bit address 0x42)
MAX96861_2 on /dev/i2c-9 (7-bit address 0x60)
Communication is working (no I2C errors), but I’m seeing behavior that I don’t fully understand.
For example, on MAX96861_2:
i2cset -f -y 9 0x60 0x00 0x55

i2cget -f -y 9 0x60 0x00
0x34

i2cget -f -y 9 0x60 0x00
0x50

i2cget -f -y 9 0x60 0x00
0x00

i2cget -f -y 9 0x60 0x00
0x41

i2cget -f -y 9 0x60 0x00
0x98
Interestingly, performing the exact same test on MAX96861_1 (/dev/i2c-0, address 0x42) produces a very similar sequence.
I also dumped registers 0x00–0x0F several times and noticed that many registers change between successive reads, even without performing any writes.
I don’t currently have access to the MAX96861 register documentation, so I don’t know whether these are status registers, indirect registers, or whether a page-selection mechanism is required before accessing the register map.
My questions are:
Is this expected behavior for MAX96861 devices?
Do these devices require indirect/page-based register access instead of simple SMBus byte reads?
Could i2cget/i2cset be using an access mode that is not appropriate for this device?
Has anyone worked with MAX96861 and can suggest the correct Linux access method or register sequence?
Thanks in advance for any pointers.

I am setting a gpio to high
After setting when I am trying to read it , it is returning 0. Not the value that I set.

Also i see the direction if the pin is changed to input

Benchmarked typed IPC against raw sockets on Linux

D-Bus is fine for control messages, not built for speed. So when something needs to be fast, most people drop to raw sockets and hand-roll framing and dispatch themselves. I wanted to know how much that actually buys you, so I measured it.

Setup: a message gets serialized, sent over TCP to a router, routed to the target process, dispatched to the right thread, then deserialized before the method gets called. That's 2 hops, one-way: sender -> router -> receiver. I went through a router instead of connecting processes directly because it removes hardcoded addresses and startup ordering — any component can reach any other, in any order, without knowing where it physically lives. The trade-off is a longer path than a direct connection.

Hardware: i7-13700H laptop, DDR4, Ubuntu, performance governor. Not embedded ARM — more on that below.

Result: ~12 microseconds one-way, ~23.5 μs round-trip. Round trip is 4 hops: sender -> router -> receiver -> router -> sender.

For reference, a bare blocking socket call with zero framework still costs ~4-11 μs round-trip on dedicated hardware (Unix domain sockets, Werner/MPI-HD, 2021). A full typed call through 4 hops and a router, with serialization on both ends, lands within shouting distance of that.

I also ran the same payload size (one-way, not round-trip) against a 2025 Hitachi Energy benchmark of ZeroMQ, NanoMsg, and NNG (arXiv:2508.07934), ~1KB messages:

Caveat: their numbers are raw transport only, on an isolated-core Xeon workstation. Mine includes full serialization and dispatch, on a mobile CPU, through an extra hop via router. Every condition favors them, and it's still close.

I'm the author of areg-sdk -- a C++17 framework released under Apache 2.0. Runs on Linux, Windows, and macOS, on x86, x86-64, arm32, and arm64. TCP-based, assumes a private network (no TLS yet), fits embedded Linux deployments, builds without extra dependency install.

One thing missing from this: real numbers from actual ARM boards instead of a laptop CPU. If anyone runs this on a Pi or BeagleBone, I'd genuinely like to see the results.

Methodology: github.com/aregtech/areg-sdk/blob/master/docs/wiki/08c-areg-vs-hitachi-benchmark.md
Try it yourself: github.com/aregtech/areg-sdk/tree/master/examples/30_publatency
Very easy to build, parameters are well documented.

What do you all actually use for fast IPC on embedded boards?

Hello everyone.
I'm trying connect tft display (Red 2.8" TFT 240x320 V1.1) to SBC called Luckfox Pico but my brightness are inverted (black = white) and I'm don't know whats wrong. I change some variables in device tree but it didn't help me, i'm trying tft,invert=<1>; and backlight pins but this makes nothing whatever i use it or manually enable PWM.
I'm making this for fun and learning and use X11 so maybe there some way to invert colors in X11? But i heard something usual like xcalib didn't work with fbtft driver so i hope there are other way...
Thank you.

fbtft@0 {
compatible = "sitronix,st7789v";
reg = <0>;
spi-max-frequency = <20000000>;
fps = <30>;
buswidth = <8>;
debug = <0x7>;
led-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;//BL
dc-gpios = <&gpio1 RK_PA2 GPIO_ACTIVE_HIGH>;//DC
reset-gpios = <&gpio1 RK_PC3 GPIO_ACTIVE_LOW>;//RES
rotate = <90>;
bgr = <1>;
invert = <1>; 
};

Hey everyone!

Since December 2025 I've been building Strux, a framework that makes it genuinely simple to turn a web app into a dedicated kiosk or IoT device — using the tools you already know.

Here's the idea: you write a web frontend (React, Vue, or plain HTML/JS — your call) and a Go backend, and Strux compiles the whole thing into a complete, bootable Linux OS image with a single command. Kernel, bootloader, root filesystem, display stack — all of it. The device powers on and boots straight into your app, full-screen, with nothing else in the way. No desktop, no login, no "where's the cursor" — just your UI running in a Wayland compositor (Cage + WPE WebKit).

A few things that make it nice to work with:

• Live dev mode — hot-reloading dev server that pushes changes to real hardware (or QEMU) in seconds, so you're not reflashing constantly.
• Smart build cache — SHA256 dependency tracking skips unchanged steps, so only the first build is slow.
• Board Support Packages (BSPs) — target different hardware; each BSP carries its own kernel, bootloader, and device config.
• Single static CLI binary, Docker-orchestrated builds — easy to get running.

We just released v0.3.0, and we're now working on reference hardware so there's a known-good, supported board to build and test against out of the box.

This is where you come in: we're looking for testers and contributors, and we want to build a community around this. Whether you want to kick the tires, flash it onto a board, file bugs, write a BSP for your favorite hardware, or help shape where it goes next — we'd love to have you.

Docs and getting started here: https://strux-sh.github.io/strux/

Happy to answer any questions in the comments!

Hello getting into Linux driver development.

My idea: pass an RFID card to an ESP32 to authenticate sudo instead of typing a password. The secret lives on the card, not the machine. Is this a good project to learn linux driver development? ? Thanks

I'm not asking you to hire me. I'm just wondering what things look like on the other side of the process these days.

Hi,
I recently joined my current team and am working as a Test Software Developer for automotive hardware components.
Currently, I am working on a task to read ADC values from the SCC. My software runs on the SoC, and reading SCC ADC values requires communication between the SoC and SCC, which is done via SPI.
The OS is linux.
And the OS binaries are recieved from Another team. I am only responsible for the SW interface
As part of the integration, I need to configure the SPI interface in my software. However, I do not see any SPI device nodes under:
/dev/spi*
On the other hand, I do see the SPI device listed under:
/sys/bus/spi/devices/spi21.1

My question is: can this SPI device under /sys/bus/spi/devices/ be used directly for communication, or do I need a corresponding SPI character device (for example, /dev/spidevX.Y) to be available under /dev?
Thanks in advance for your guidance.

Was curious how Linux actually boots, so I skipped the usual distros and built my own. Custom kernel compiled from source, BusyBox for userspace, containerd for running containers, and Dropbear for SSH. Everything fits in a single disk image that boots in ~15 seconds.

Learned a ton about:

- How initramfs works and why it exists

- What GRUB actually does under the hood

- Why containerd needs cgroup v2 and how to wire it up

- The difference between static and dynamic linking the hard way (dropbear needs libutil, who knew)

- How to install GRUB without root (Python + raw disk writes)

Still needs polish — networking is basic QEMU user-mode, no real package manager, and the build script only recently stopped being Fedora-only. But it boots, runs containers, and I can SSH into it.

Repo if anyone wants to poke at it (fair warning: the kernel config is held together by duct tape): https://github.com/Shreyas0047/veilbox

Texas Instruments and BeagleBoard.org have announced that the AM62x and AM26x PRU Academy is now available, adding new learning material for developers working with BeaglePlay and PocketBeagle 2.

https://linuxgizmos.com/am62x-pru-academy-goes-live-for-beagleplay-and-pocketbeagle-2/

Hey all! Looking to break into the kernel or embedded space and curious to get some opinions on the best places to find those jobs? I feel like LinkedIn and Indeed are lacking in these areas. For context, I have 3 yoe as a backend software engineer.