Embedded Linux and Yocto Engineering

Navigate the Linux filesystem hierarchy and locate configuration, device, log, and executable files from the command line.

Construct shell pipelines using redirection, grep, find, sed, awk, and xargs to inspect build artifacts and logs.

Configure Linux users, groups, ownership, permissions, sudo access, and executable files for a development workspace.

Install and verify host development packages with APT while monitoring filesystem capacity and inode usage.

Inspect processes, signals, systemd units, and journal logs to diagnose a failed host service.

Configure an Ethernet interface and diagnose DNS, routing, ports, and SSH connectivity with standard Linux tools.

Create a private implementation repository and a public showcase repository, then configure branches, .gitignore rules, secret scanning, and a workflow for exporting sanitized artifacts.

Build a multi-file C application with Make and diagnose a runtime defect using GDB.

Explain the roles and relationships of the Yocto Project, OpenEmbedded-Core, BitBake, Poky, distributions, machines, recipes, and layers.

Prepare an Ubuntu build host and initialize a release-compatible Poky build environment with oe-init-build-env.

Configure bblayers.conf and local.conf to select layers, machine, distribution, package format, downloads, and shared-state locations.

Using prepared download and shared-state caches, build and boot a minimal QEMU image and record the commands, revisions, configuration, and artifacts required to reproduce it.

Locate sources, task work directories, sysroots, package data, logs, stamps, shared state, and deployed images in a Yocto workspace.

Explain how task signatures determine shared-state reuse and demonstrate a cache hit after a metadata-preserving rebuild.

Compare reproducible outputs for a bounded recipe or image artifact while controlling source timestamps, host paths, tool versions, and release metadata.

Tune thread counts, disk monitoring, cleanup, and download or shared-state storage for a 16 GB development host.

Predict the value of a BitBake variable after deferred, immediate, weak-default, append, prepend, remove, and override operations.

Use bitbake -e and datastore history to identify which metadata assignment produced an unexpected variable value.

Trace a recipe through fetch, unpack, patch, configure, compile, install, package, and package-write tasks.

Add a custom BitBake task with explicit ordering and implement a shell or Python pre-function for an existing task.

Write a recipe for a locally developed C application using SRC_URI, licensing checksums, reproducible source revisioning, and a raw Makefile.

Write a CMake-based recipe that obtains build-time dependencies from a recipe sysroot and declares correct runtime dependencies.

Package a versioned shared library into runtime and development outputs while resolving FILES, unversioned-so, RPATH, and installed-but-not-shipped QA errors.

Diagnose a failed recipe using log.do_*, run.do_*, devshell, forced single-task execution, and oe-pkgdata-util.

Create a custom layer with valid collection patterns, priority, dependencies, release compatibility, and yocto-check-layer results.

Extend an upstream recipe with a bbappend, FILESEXTRAPATHS, and a source patch without modifying the supplying layer.

Factor shared metadata into a bbclass or include file and expose an optional feature through PACKAGECONFIG.

Define a custom distribution that selects init system, C library, package format, and deliberate DISTRO_FEATURES.

Create a custom image and packagegroup that install the gateway software stack without relying on ad hoc IMAGE_INSTALL changes.

Configure deterministic users, groups, filesystem permissions, image sizing, and WIC or ext4 output in image metadata.

Generate a standard SDK and use its sysroots and environment script to build and remotely debug an application with gdbserver.

Use an extensible SDK and devtool to add, modify, build, deploy, and finish a recipe-backed source change.

Select an AM62x development board and CAN-FD accessories, map their power, serial, Ethernet, storage, and expansion interfaces to the schematics, and produce a safe lab wiring checklist.

Flash a vendor-reference image, capture a serial boot baseline, and verify storage, Ethernet, USB, and basic peripheral enumeration.

Create an AM62x machine configuration with correct tuning, serial console, machine features, image types, and virtual kernel or bootloader providers.

Apply a kernel configuration fragment through Yocto and prove that the requested option is present in the deployed kernel.

Modify and validate a device tree to enable one board peripheral with correct pin multiplexing, clocks, interrupts, and status.

Package and load a simple out-of-tree kernel module using a Yocto module recipe.

Apply a U-Boot configuration or board patch and verify its environment storage and boot-target behavior on the board.

Load firmware on an AM62x remote processor with remoteproc and exchange a test message through RPMsg.

Draw the runtime data flow and trust boundaries for an AM62x gateway connecting CAN-FD, Ethernet, persistent storage, management, and update services.

Bring up a CAN-FD interface with SocketCAN and verify nominal bitrate, data bitrate, frame transmission, error counters, and bus-off recovery.

Configure dual Ethernet interfaces with static routing and IEEE 802.1Q VLAN separation on Linux.

Configure and measure precision time synchronization with linuxptp for gateway timekeeping.

Implement nftables firewall rules and verify zone-isolation policies between gateway network segments.

Implement and package a supervised CAN-to-IP gateway service with structured logging, restart policy, and bounded resource usage.

Quantize a pretrained telemetry or anomaly-detection model to INT8 and compare its size and held-out accuracy with the original model.

Write a Yocto application recipe that depends on an existing inference-runtime recipe, installs the model and configuration, and records on-target inference latency and memory use.

Construct an AM62x secure-boot chain showing HS-FS and HS-SE lifecycle states, the eFuse-backed Boot ROM trust anchor, authenticated firmware stages such as TIFS, SPL, TF-A, U-Boot, and FIT images, protected target data, and any remaining root-filesystem integrity gap.

Design a platform-compatible key hierarchy that separates offline root-key custody, AM62x primary and backup signing roles, firmware and FIT signing, OTA signing, code-encryption keys, and development versus production credentials, with ownership, access, revocation, and rotation rules.

Define an AM62x signed-image certificate or container that binds the target-data hash, signed-region boundaries, image identifier, offset, load address, entry point, security version, and permitted signing algorithm.

Generate disposable development keys and a platform-compatible X.509 certificate and signed boot artifact with TI or equivalent vendor tooling, then inspect the public keys, signature algorithm, identifiers, extensions, and fields actually enforced by ROM or firmware.

Write a non-destructive HS-FS-to-HS-SE provisioning runbook covering the root public-key hash, primary or backup key selection, revocation fields, software-revision counters, lifecycle transition, verification gates, and recovery limits without programming production values on the learning board.

Independently verify the certificate chain, certificate signature, target-data hash, signed-region boundaries, image offset, load address, and entry point, then diagnose rejection after controlled certificate, metadata, or payload tampering.

Distinguish the X.509 certificate-format version from firmware monotonic versions, map TFMV and NTFMV where defined by the selected image format to the applicable AM62x OTP or firmware software-revision mechanism, and demonstrate non-destructive rejection of an older signed test image.

Trace a platform-supported code-encryption test vector through content-key generation, key wrapping, IV or nonce handling, certificate metadata, target-data location, decryption and authentication ordering, and final plaintext placement, while explaining why encryption does not replace signature verification.

Partition gateway data into immutable system content, volatile runtime state, persistent configuration, logs, credentials, and update metadata.

Configure a read-only root filesystem with tmpfs, bind mounts, or overlayfs and verify operation across an abrupt reboot.

Create a WIC layout containing boot assets, redundant rootfs slots, persistent data, and bootloader environment storage.

Implement U-Boot slot selection using bootcount, bootlimit, upgrade_available, and an explicit last-known-good state transition.

Configure RAUC system and slot metadata to match the generated partition layout and bootloader backend.

Create and verify an X.509-signed RAUC bundle, install it into the inactive slot, and inspect bundle verification evidence.

Connect application health, watchdog reset, boot-attempt accounting, and userspace mark-good logic to demonstrate automatic rollback.

Design a staged fleet rollout and recovery procedure covering interrupted downloads, incompatible versions, key rotation, and rescue access.

Configure dm-verity for an immutable root filesystem, bind its root hash to authenticated boot metadata, and diagnose a deliberate block-integrity failure.

Enable and verify selected compiler, linker, kernel, and filesystem hardening controls in a Yocto distribution.

Sandbox the gateway systemd service using process capabilities, namespace isolation, filesystem restrictions, and system-call filters.

Author and enforce a minimal Mandatory Access Control profile for the gateway service using AppArmor or SELinux.

Run Yocto CVE checking, validate whether one reported issue affects the product configuration, and document its patch or risk disposition.

Implement a CI workflow that uses shared caches, builds and tests the gateway components, checks Yocto metadata, scans for exposed secrets, runs negative secure-boot or update tests where feasible, and archives release evidence.

Publish a sanitized public GitHub showcase release containing a product README, architecture diagrams, decision records, reproducible build guide, demonstration evidence, SPDX SBOM, license summary, and test results while keeping keys and sensitive implementation material private.

Create a LinkedIn project entry and technical case-study post that explain the gateway problem, architecture, engineering trade-offs, measured results, and personal contribution without disclosing sensitive material.