Bringing up firmware on a new SoC rarely fails at the “write the code” step. It fails somewhere after that: a register gets configured in the wrong order, a peripheral driver assumes a board revision that isn’t the one on the bench, or code that compiles cleanly never actually boots. The gap between “code exists” and “firmware works” is where most bring-up time disappears.
This is a walkthrough of one such run, using the TI AM62x family, a Linux-capable applications processor line, as the target platform.
Starting from the documentation, not the prompt
The run did not start with “write me a driver.” It started with FWAuto pulling in the AM62x datasheet, the vendor SDK, and the known errata for the specific silicon revision, and building a queryable reference from them. Only after that reference existed did code generation begin. This ordering matters: a model that writes first and checks the datasheet later is guessing until it happens to be right. A model that reads the relevant register definitions and known hardware quirks before writing has fewer reasons to guess.
Connecting to the board, not just the toolchain
AM62x boards are Linux-capable, so the connection method was SSH, the same path FWAuto uses for other Linux-based targets such as NXP i.MX. MCU-class boards without a Linux userspace, such as STM32, use UART instead, since there’s no network stack to SSH into. The distinction matters because it determines what “verification” can even mean: an SSH-reachable Linux board can run test binaries, check kernel logs, and confirm a driver actually loaded. A bare-metal MCU target verifies through UART log output instead.
The loop: build, flash, verify, repair
Once connected, the sequence was: build the firmware, flash it to the board, run the verification checks, and read back the actual result from the hardware, not a predicted result. When a check failed, FWAuto used that failure output to make a correction and reran the same loop. This repeated until the checks passed on the real board, not until the code merely compiled.
This is the part that separates a workflow system from a code generator. A tool that stops at “the build succeeded” has told you the syntax is valid. It hasn’t told you the firmware does what it’s supposed to do on the chip that will actually ship. FWAuto’s loop doesn’t consider the task complete until the hardware confirms it, and every step in that loop, what was tried, what the board reported back, what was changed in response, is logged. That log is what makes the result auditable instead of a claim.
What this case study is not
It’s worth being precise about what this run demonstrates and what it doesn’t. It shows FWAuto executing a full plan, build, flash, verify, repair loop end to end on a real AM62x board, using the datasheet, SDK, and errata as the basis for the generated code rather than model memory. It does not represent a benchmark against a specific baseline, and TI AM62x support here reflects a verified target platform, not a vendor partnership or endorsement.
Why this matters beyond one chip
The AM62x run isn’t interesting because AM62x is unusual. It’s representative of what bring-up looks like across most application processors: read fragmented, sometimes hundreds-of-pages-long documentation, generate code against it, and then find out on real hardware whether any of it actually holds up. The value FWAuto adds isn’t a smarter way to write the initial code. It’s closing the loop between “the code compiles” and “the hardware confirms it works,” automatically, with a record of every step in between.
That’s the same standard the next case study should be held to: not a faster model, a verified result.