Blog

Every embedded processor, camera sensor, NPU, SPI device, or I²C peripheral comes with large technical documentation.

Indicative documentation ranges: actual document volume varies by vendor, device family and product maturity.

The most important information is often not obvious. A vendor may include a device-specific note such as:

Such requirements may appear in hardware errata sheets, vendor application notes, internal engineering documents or NDA-protected updates.

Why AI Fails Here

AI can only reason from the technical information made available to it. It may not have access to confidential errata, vendor support history, internal workarounds or proprietary initialization sequences.

As a result, AI may generate code that looks correct but fails on real hardware.

What Human Engineers Do

• Read hundreds of pages of documentation
• Identify hidden initialization requirements
• Compare datasheet and errata revisions
• Test different register sequences
• Validate behaviour on actual boards

This is a hardware engineering task, not just a coding task.

A driver does not operate in isolation. It interacts with interrupt controllers, DMA engines, caches, clocks, power domains and external peripherals.

Many failures are caused by timing, ordering or hardware-state problems.

/* Interrupt arrives */
irq_handler();

/* Device-specific interrupt acknowledge */
writel(IRQ_CLEAR, base + STATUS_REG);

/* On some non-coherent streaming DMA paths,
 * synchronize before CPU access when required. */
dma_sync_single_for_cpu(dev, dma_addr, size, direction);

If the sequence or timing is wrong, the interrupt may repeat forever, DMA data may be corrupted, the kernel may crash intermittently, or the board may freeze only once every few hours.

How Engineers Debug This

An engineer may need to measure an SPI clock, verify reset pulse width, check whether an interrupt line toggles, confirm DMA completion timing or observe power sequencing.

This is why debugging skills remain one of the most valuable abilities in embedded Linux development.

A common misconception is: “If the driver works on one board, it will work on another.”

A reusable driver may work across several boards, but every board still requires correct hardware description, resource configuration and validation.

Device Tree Problems

A driver may fail simply because the Device Tree is wrong.

&spi1 {
    status = "okay";
    pinctrl-0 = <&spi1_pins>;
};

A single incorrect pinmux setting can prevent the device from being created or the driver from binding correctly.

Power Sequencing Problems

Many peripherals require a strict sequence:

If the order is wrong, the device may not respond, the sensor may remain in reset, or—in poorly protected hardware—components may be stressed or damaged.

Memory Architecture Problems

DMA behaviour depends on whether memory is coherent, non-coherent, IOMMU-mapped, cached or non-cached. The correct implementation depends on the SoC, device and board design.

What Human Engineers Must Understand

• Board schematics
• Power rails
• Clock trees
• Reset circuits
• GPIO routing
• Memory architecture
• Kernel configuration
• Firmware description

AI does not know the complete behaviour of a custom board unless the relevant design information, constraints and measurements are supplied—and even then, the result must be verified on hardware.

Imagine drivers used in automotive ADAS systems, medical equipment, aerospace electronics or industrial robots. A single bug can have serious consequences.

Responsible engineering teams will not release production driver code without human review, hardware validation, testing and accountable sign-off.

The Required Engineering Process

• Code review
• Hardware validation
• Stress testing
• Performance testing
• Safety analysis
• Documentation
• Regression testing
• Engineering sign-off

A human engineer must take responsibility for the final result.