First articles create a peculiar optimism: the board exists, so the firmware must be close. It rarely is. A bring-up checklist written before the courier arrives keeps the week honest.
Power and clocks first
Confirm rails with a meter before you argue about drivers. Note which rails come up in which order, and whether your firmware assumes a sequence the PMIC does not provide. Clock trees deserve the same treatment — a wrong PLL setting can look like a “broken” peripheral for days.
Console before features
A reliable console (UART or equivalent) is the difference between debugging and guessing. If your secure boot story delays console, stage a temporary path that still respects production signing rules later. Document which build flavor opens the console.
One peripheral that unlocks the rest
Pick the bus or device that unblocks logging, storage, or network — not the flashiest demo. Get that path stable, then widen. Soak tests belong on the calendar early; green unit tests on the host are not a substitute for overnight runs on target.
Write the failure notes
When something flakes, write the exact steps, not “radio unstable.” Future you — or the consultant you hire for a Bring-Up Support Week — will need those notes more than a tidy summary slide.