agentsclimarketplace
Sign in

Bootloader debug

Skill easyzoom/aix-skills/skills/bootloader-debug

Use when debugging embedded bootloaders, application jumps, vector table offsets, firmware upgrade flow, OTA state, image validation, rollback, or boot selection failuresFrom its SKILL.md

Install
npx -y skills add easyzoom/aix-skills --skill bootloader-debug

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 24 stars24 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.0 KB, 823 tokens by cl100k_base, as published. Nobody here has run it

Bootloader Debug

Overview

Use this skill to debug bootloader and application handoff problems without destroying recovery paths. Verify memory layout, image metadata, vector table, stack pointer, reset handler, validation, and rollback state before reflashing or erasing boot regions.

When To Use

Use this skill when:

  • A bootloader cannot start an application or jumps to the wrong image.
  • OTA/upgrade succeeds but the new firmware does not boot.
  • The issue involves image headers, checksums, signatures, slots, rollback, vector table relocation, or boot pins.
  • The user mentions MCUboot, U-Boot, vendor bootloader, IAP, DFU, app offset, or recovery mode.

Do not use this skill for ordinary application crashes after a confirmed clean handoff; use embedded-fault-debug. For MCUboot-specific slot/signing/swap issues, use mcuboot-integration. For OTA delivery pipeline issues, use ota-update-integration.

First Questions

Ask for:

  • Chip/board and bootloader type.
  • Memory map: bootloader, app slot, scratch, config, NVM, and backup areas.
  • Image format and validation: raw binary, HEX, signed image, checksum, metadata header.
  • Upgrade state: active slot, pending, confirmed, rollback, recovery, or unknown.
  • Logs from bootloader and application if available.
  • Whether recovery access still works.

Workflow

  1. Protect recovery. Do not erase bootloader, recovery slot, calibration, or persistent upgrade state without explicit approval.

  2. Confirm memory layout. Compare linker script, flash programming address, image header, and bootloader slot configuration.

  3. Validate handoff basics. For MCU apps, check initial SP and reset handler at the application offset. For Linux boot, check kernel, device tree, rootfs, and bootargs.

  4. Check image decision logic. Inspect version, checksum/signature, pending/confirmed flags, rollback counters, and slot priority.

  5. Trace the jump. Halt before handoff, inspect target SP/PC, vector table relocation, interrupts, clocks, caches, and peripheral state.

  6. Ask before destructive recovery. Erasing slots, clearing flags, disabling signature checks, or rewriting boot config requires approval.

MCU Handoff Checks

  • Application offset matches linker origin.
  • Vector table word 0 is valid RAM stack pointer.
  • Vector table word 1 is valid reset handler address.
  • VTOR or equivalent vector relocation is set when required.
  • Interrupts are disabled or cleaned up before jump.
  • MSP/PSP is set correctly for the application.
  • Caches, MPU, clock tree, and peripherals left by bootloader are expected by app.

Upgrade And Rollback Checks

  • Image header is at the offset the bootloader expects.
  • Length, checksum, signature, and version fields match.
  • Pending/confirmed flags reflect intended state.
  • Rollback reason is logged before clearing it.
  • Power-fail update path preserves at least one bootable image.

Verification

Before claiming progress:

  • State bootloader type, memory map, active slot, and application offset.
  • Report whether image validation passed or which check failed.
  • Report target SP/PC for app handoff when MCU-based.
  • State whether recovery remains available.
  • List destructive operations skipped or awaiting approval.

Common Failures

  • Flashing the app at flash base when the bootloader expects an offset.
  • Forgetting vector table relocation.
  • Clearing rollback flags before recording why rollback happened.
  • Disabling validation to "test quickly" without preserving recovery.
  • Leaving interrupts or peripherals active across app jump.

Example

User:

Bootloader 能跑，但跳 app 后死掉。

Agent:

  1. Asks for memory map, app offset, linker script, boot log, and image header.
  2. Checks app vector table SP/PC at the slot offset.
  3. Verifies VTOR, interrupts, stack setup, and image validation before reflashing.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most debug triage skills give in 823 tokens

Counted across 1,020 of the 1,639 authors here whose files we hold, read 2026-09-06

  • Find root cause before attempting any fixin 134 of 1020, across 118 files
  • Create a failing test case before implementing a fixin 109 of 1020, across 95 files
  • Read error messages and stack traces completelyin 102 of 1020, across 88 files
  • Reproduce the issue consistently before investigatingin 90 of 1020, across 77 files
  • Make the smallest possible change to test a hypothesisin 90 of 1020, across 76 files
  • Trace data flow backward to find the sourcein 84 of 1020, across 70 files
  • Form a single hypothesis before testingin 78 of 1020, across 64 files
  • Implement only one fix at a timein 76 of 1020, across 63 files
  • Question the architecture if three fixes failin 73 of 1020, across 59 files
  • Add diagnostic instrumentation at component boundariesin 68 of 1020, across 56 files
  • Compare broken code against working examplesin 68 of 1020, across 57 files
  • Write a regression test before applying the fixin 62 of 1020, across 55 files

Said here and by no other author read

  • protect recovery paths from erasure
  • compare memory layout with linker script
  • verify initial stack pointer and reset handler
  • inspect image headers and validation flags
  • halt execution before jump to inspect state
  • check vector table relocation settings

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.