All jobs / Embedded / hardware

Embedded Linux interview questions

Embedded Linux questions a Embedded / hardware can be asked, from first job to senior. Open one to see the strongest answer and why it works.

1. Why do we cross-compile for an embedded Linux board instead of building on the board itself?

   The strongest answer: The build host is far faster and already holds the toolchain and sources; we build with a compiler that targets the board’s architecture and link against a sysroot of the board’s own headers and libraries

   Why it works: Right — and the sysroot is the part people forget, which is why binaries linked against host libraries fail to load.

   • Build on the host, for the target.
   • The toolchain targets the board’s architecture.
   • A sysroot supplies the target’s libraries.
   • Keep reproducible builds in CI.

2. A USB device you plug into the board does nothing. Where do you look first on the Linux side?

   The strongest answer: The kernel log — dmesg straight after plugging it in shows whether the kernel saw the attach, which driver bound, and any error it hit, which splits hardware from application immediately

   Why it works: Right — the kernel log is the first honest witness. Remember it is a ring buffer, so capture it before it wraps.

   • Read the kernel log before guessing.
   • Run dmesg right after the event.
   • Look for attach, bind, device node.
   • It is a ring buffer — capture it.

3. Walk me through what happens between power-on and a login prompt on an embedded Linux board.

   The strongest answer: A boot ROM loads a bootloader from a known device, the bootloader brings up RAM and storage and loads the kernel with its device tree, the kernel mounts the root filesystem, and init starts the services

   Why it works: Right — naming the stages is what lets you say which one went silent when a board stops booting.

   • Know the chain so you can bisect it.
   • ROM loads the bootloader.
   • Bootloader loads kernel and device tree.
   • Kernel mounts rootfs; init starts services.

4. What is the device tree for on an embedded Linux board?

   The strongest answer: It describes hardware the kernel cannot discover — which peripherals exist, at what addresses, on which interrupts and clocks, and which driver matches — so one kernel serves several boards through different blobs

   Why it works: Exactly — and that is why a board variant means a new blob, not a new kernel.

   • It describes non-discoverable hardware to the kernel.
   • Addresses, interrupts, clocks, driver match.
   • The bootloader passes the blob in.
   • Variants change the blob, not the kernel.

5. A new SPI sensor has to be read on an embedded Linux product, and someone proposes writing a kernel driver for it.

   How do you decide?

   The strongest answer: Userspace first, through the existing SPI and GPIO character devices: a crash kills a process, not the board, and it updates like any binary. A kernel driver earns its place for latency, DMA or a standard subsystem

   Why it works: Right — and name the cost of the kernel route: it panics the board, it ties you to a kernel version, and licensing gets a lawyer involved.

   • Userspace until the kernel is genuinely required.
   • Blast radius: process versus whole board.
   • Kernel for latency, DMA, subsystems.
   • Out-of-tree costs at every upgrade.

6. The silicon vendor ships a kernel fork several versions behind with their patches folded in, and the product must be supported for years.

   What do you commit to?

   The strongest answer: Knowing exactly what we carry — the base version and every patch, kept as a tracked series we can rebase — plus a funded path to move forward and a named route for security fixes

   Why it works: Right — the decision that hurts later is not which kernel, it is whether anyone can still say what is in it in year four.

   • Know what you carry and who moves it.
   • Track the base version and every patch.
   • Fund the upgrade before you need it.
   • Name the security-fix route.