Chapter 126: Closing: what to read next¶
The main path has followed an embedded system from its boot contract to its update policy. The important result is a model of the responsibilities in that system, not a claim that reading it qualifies a board or turns every example into production code. This chapter points to references for refining that model.
MCU bridge: Think of the rootfs as the firmware image’s file-backed runtime environment. On an MCU you link everything into flash. On Linux, programs and config live in this mounted tree. MCU bridge: Think of U-Boot like a much larger boot stub plus debug monitor: it initializes hardware, loads the next image, and gives you commands before Linux starts. rootfs: root filesystem, the directory tree mounted at / that contains /bin, /etc, /dev, and libraries. U-Boot: the bootloader that initializes enough hardware to load and start the Linux kernel.
126.1 The next-step canon¶
Five books and sites that pick up where this book ends:
1. Linux Device Drivers, 3rd Ed. (LDD3), Corbet, Rubini, Kroah-Hartman¶
The canonical kernel-driver book. Written for kernel 2.6 (so the specific APIs are dated), but the concepts are timeless, char devices, blocks, networking drivers, USB drivers, PCI, sleeping primitives, kernel memory management. The mental model it gives you is correct. Just check current APIs in the kernel source when implementing.
Free online: https://lwn.net/Kernel/LDD3/
2. Bootlin’s “Embedded Linux” training material¶
Bootlin (formerly Free Electrons) is a French embedded-Linux training + consulting company. Their training slides + labs are free, comprehensive, current, and license-permissive. Topics: kernel internals, Yocto, Buildroot, audio, video, real-time, security.
Yocto: a metadata-driven build system for producing custom Linux distributions. Buildroot: a configuration-driven build system that produces a complete root filesystem and related images.
Probably the best free online resource for further study.
3. kernelnewbies.org¶
Wiki + mailing list for new kernel contributors. Hosts:
A “first patch” tutorial.
Release notes for every kernel version since 2.6, read these to track what’s changing.
“KernelHacking” tutorials.
The most welcoming community for first-time kernel contributors. Mailing-list lurkers welcome.
4. LWN.net¶
The professional-grade kernel-development periodical. A paid subscription ($10/month) is worth it if you work with Linux full-time. Coverage:
Weekly summaries of LKML threads.
Deep dives on new kernel features (eBPF, io_uring, sched_ext).
Conference reports (Linux Plumbers, Kernel Summit, Open Source Summit).
Subsystem maintainer profiles.
Reading LWN weekly is one of the most reliable ways to absorb kernel-development culture and stay current.
5. Documentation/process/ in the Linux source tree¶
The kernel ships its own onboarding documentation. Read in order:
1.Intro.rst: “the kernel project is huge”2.Process.rst: “how the release cycle works”3.Early-stage.rst: “what to do before sending a patch”4.Coding.rst: “the code style and norms”5.Posting.rst: “how to send patches (Ch 120A’s bible)”6.Followthrough.rst: “how to respond to reviews”7.AdvancedTopics.rst: “everything else”
200 pages total. Every new contributor should read it once.
126.2 Communities and conferences¶
Linux Plumbers Conference (annual. ~Sep–Oct), the developer’s conference. Streamed talks free.
Embedded Linux Conference (Linux Foundation. Spring + fall), embedded-specific.
FOSDEM (Brussels, Feb), free, sprawling, every open-source project under one roof.
Open Source Summit (Linux Foundation, multiple cities), broader open-source.
DebConf (annual), Debian-specific. Many embedded developers attend.
Local: search for “Linux meetup” or “embedded systems meetup” in your city. Bring questions. The community is welcoming.
126.3 Mailing lists¶
Subscribe (digest mode if volume is too high):
linux-kernel@vger.kernel.org: the firehose. ~500 mails/day. Lurk.
linux-arm-kernel@lists.infradead.org: ARM-specific. ~50/day. Relevant to you.
linux-imx@nxp.com: NXP-imx-specific (moderated). ~5/day. Very relevant.
devicetree@vger.kernel.org: DT bindings discussions.
stable@vger.kernel.org: stable-kernel patch announcements.
kernelnewbies@kernelnewbies.org: beginner Q&A.
Lurk for a month before posting. Read the patches you can understand. Ignore the rest. Slowly your understanding accretes.
126.4 Three further specializations¶
Depending on your interests:
Path A, Kernel hacker¶
Goal: become a subsystem maintainer.
Pick a subsystem (e.g., IIO sensors, GPIO, regulators).
MCU bridge: Think of Linux GPIO like the same pin set/reset block you used on STM32, but accessed through a kernel subsystem that owns numbering, direction, interrupts, and user-space exposure. IIO: Industrial I/O, Linux’s subsystem for sensors, ADCs, DACs, and buffered sampled data. GPIO: General-Purpose Input/Output, a pin controlled as a digital input, output, or interrupt source.
Read every patch on that subsystem’s mailing list for 6 months.
Submit small fixes. Build reputation.
Eventually: maintain a driver, then a subsystem.
Path B, Product engineer¶
Goal: ship great embedded products.
Master one BSP family deeply (i.MX, STM32MP, TI Sitara, RPi).
BSP: Board Support Package: vendor patches, configs, bootloader files, and scripts needed to boot one board.
Build the CI/release/OTA infrastructure (Ch 121A, 125).
Develop soft skills: talking to product managers, defending engineering trade-offs.
Eventually: tech lead on a product team.
Path C, Embedded security¶
Goal: build trustworthy embedded systems.
Deepen on TrustZone + OP-TEE.
Study secure boot in depth across multiple SoCs.
Learn cryptography (Boneh’s online course is excellent).
Eventually: security architect. Review designs across products.
126.5 Skills outside Linux you’ll still need¶
C and C++: kernel is C. Many embedded apps are C++.
Python: for tooling, build scripts, test automation.
Rust: increasingly relevant. Learn it for new kernel contributions and for high-reliability user-space.
Git: beyond
add/commit/push. Understand rebase, bisect, blame, format-patch, send-email.Make + CMake + Meson: build system fluency saves hours.
Networking: TCP/IP at the implementation level, not just usage. RFC 793 / 1122.
Shell scripting:
bash,awk,sed. Indispensable.Schematic / PCB reading: you may never design boards, but you’ll read thousands.
Public speaking and writing: explaining technical decisions to non-engineers is a force multiplier.
126.6 Key Notes¶
Every layer needs an owner and a contract: what it receives, what it changes, what it promises, and how failure is reported.
Device Tree describes hardware relationships, while drivers and frameworks implement behavior. A matching node is not proof that electrical or timing assumptions are correct.
Update design must preserve a recoverable state through interruption and incompatible changes. A/B is one useful mechanism, not the only possible strategy.
Source versions and board provenance are part of an implementation’s meaning. Vendor support and upstream support should be assessed against actual hardware coverage and maintenance needs.
Secure boot, provisioning, runtime authority and updates protect different boundaries. None alone establishes a secure product.
Implementation tools can generate code, but design judgment still has to account for dependencies, failure modes and evidence from the real system.
126.7 Acknowledgements¶
(Reserved for the book author’s final acknowledgements: the people who made the journey possible, the colleagues who reviewed early drafts, the readers who reported errors, the maintainers whose code makes this possible at all.)
126.8 Errata + feedback¶
(Reserved: URL of the book’s errata page. An email or GitHub issues tracker for reader-submitted corrections.)
End of the main i.MX6ULL path.
An embedded system is easier to reason about when a failure can be traced to a particular responsibility. That is the thread joining the bootloader, kernel, rootfs and application chapters. The details will change, but questions about ownership, interfaces and recovery will remain useful.
The optional next path, Part IX: Applied virtualization and mixed-criticality systems, asks when those responsibilities should be separated more strongly. It uses QEMU models, Xen, the i.MX6ULL’s limits, Jailhouse and STM32MP1’s Linux/RTOS split.