메뉴
Use when building or debugging a firmware and boot chain (RISC-V SBI, UEFI, ACPI, a bootloader handoff like Limine to an OS) or adding measured boot with a TPM, and a stage fails to hand off to the next
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when implementing a hardware block, protocol, peripheral, or ISA feature in ROHD and you should ground it in the authoritative spec, existing reference implementations, and reusable libraries you fetch first, instead of writing it from memory
Use when bringing up bare-metal or kernel code on a new architecture, SoC, or board (RISC-V, ARM, x86, ESP32) and it won't boot, hangs after boot, or faults early; covers trap vectors, MMU/PMP, syscall ABI, and boot ordering
Use when building or debugging a compiler backend, codegen, or assembler and you need to prove the generated machine code is correct by executing it on a real CPU or a fast emulator, not just inspecting the output
Use when verifying a hardware DUT (a CPU core, FPGA, or netlist) against a golden reference model, building coverage-guided fuzzing, or detecting where silicon diverges from a simulator like Spike, an emulator, or SPICE
Use when loading a bitstream onto a physical FPGA and driving or observing it over JTAG or GPIO, especially bit-banged JTAG from a host like a Raspberry Pi, or when configuration silently fails
Use when synthesizing RTL to an FPGA with yosys/nextpnr (ECP5/Lattice and similar), fighting area or routing congestion, measuring Fmax, deciding why a design won't fit or route, or instantiating block RAM; covers the pre-pack vs post-pack metric trap
| name | firmware-boot-chain |
| description | Use when building or debugging a firmware and boot chain (RISC-V SBI, UEFI, ACPI, a bootloader handoff like Limine to an OS) or adding measured boot with a TPM, and a stage fails to hand off to the next |
A boot chain is a relay of stages, each responsible for setting up just enough state to hand control to the next: ROM to firmware (SBI/UEFI), firmware to bootloader, bootloader to OS. Every handoff has a contract: where the next stage lives, what registers/tables it expects, and what memory is already set up.
Core principle: Each stage owns a contract with the next. Most boot failures are a broken contract at exactly one handoff, so isolate which handoff fails before theorizing about the stage itself.
Write down the relay before debugging:
ROM -> firmware (SBI/UEFI) -> bootloader -> OS kernel
provides: SBI calls, loads: expects: a0=hartid,
memory map, ACPI/DTB kernel+initrd a1=DTB/ACPI ptr, MMU off
For each arrow, name: the entry address, the register/pointer contract, and the memory/translation state. The failing arrow is your bug location.
These bite when chaining a general loader (for example Limine) into an OS:
bare-metal-bringup).If the chain is measured:
EFI_TCG2_PROTOCOL) and emit a TCG2 event log so the measurements are verifiable later.| Smell | Do instead |
|---|---|
| Hardcoded peripheral addresses | Probe from DTB/ACPI |
| RAM base as a constant | Build-time parameter per board |
| "It doesn't boot" with no stage isolated | Identify the failing handoff first |
| TPM probe with no presence gate | Gate on the platform description |
| Extending a PCR after the jump | Measure-then-transfer |
bare-metal-bringup for the early-output and translation rungs.