1Open
build tooling #4770 — make program builds an ELF that no UF2 tool will take
Splicing an application into the kernel makes
objcopy lay the segments out again, and the
(NOLOAD) stack segment comes back claiming 5,376 bytes of file
content for RAM. Both converters are right to refuse it. The reported cause
— that elf2uf2-rs cannot handle RAM — is not what is
happening, and the workaround in the issue strips a section that is only
safe to strip by accident. Six candidate fixes measured; the one that works
is a single objcopy line, verified by running the real
make target on all four RP2 boards, with it and without
it.
build tooling #5160 — a flashing route with no ELF to get wrong
The reviewer who approved the four-line fix for #4770 asked
for something else in the same sentence: that these boards stop splicing an
application into the kernel ELF and use tockloader local-board
instead. That route was run end to end — assembled by tockloader, loaded
three ways (SWD, the bootloader, probe-rs), with two applications
co-resident and live in the kernel's own process list. It cannot hit the defect, because it never opens
an ELF. Four costs come with it, and the tool swap on three RP2040 boards is
the one a reviewer would stop on.
board #5165 — a pending interrupt survives the reset that silenced it
A Raspberry Pi Pico 2 could panic at boot with
unhandled interrupt 14, and the trigger looked random for most
of a day: twice in nine resets, from two different debuggers. If the bootrom
is still talking to a USB host when the chip is reset, the kernel clears the
interrupt controller at a moment when clearing it cannot work, then resets the
peripheral, leaving a pending bit whose cause is no longer anywhere to be
seen. Read in the panic handler:
the pending bit is set while the USB block is byte-for-byte identical to a
boot that did not panic.
chip driver #5157 — a PIO interrupt flag delivered to the wrong client
A PIO block raises eight IRQ flags that belong to the
block, and the driver delivered flag n to state machine n's
client — an association the hardware does not have, and one the
datasheet invites by naming those bits
SM0–SM3. A flag whose state machine has no
client is never cleared, so the peripheral keeps asserting and the kernel
spins. Invisible in the tree because the only user sits on the diagonal.
Both the misrouting and the fix were run on a Pico 2 W.
chip driver #5153 — EP0 IN is armed at bus reset and never taken back
The RP2040 USB driver hands EP0's IN buffer to the USB controller during bus reset, with a length of 64 and a PID of DATA0 and nothing queued to send. A SETUP packet does not take it back, so the first control read can be answered out of a buffer nobody filled. Two of the three claims in the issue's AI analysis hold up; the third points at a delay that is already in the code.
2How these are written
- Line numbers are pinned to a commit. Where a citation carries a line number it links to that line at that commit, so a claim about the source can be checked without cloning anything. Citations that name a file without a line are not linked; the file name is the whole claim.
- Numbers come from commands, and the command is named. Where a measurement can be reproduced without hardware, the script that produced it ships beside the page — 4770 has one. Most of what is quoted here came off a board over a debug probe, which no script reproduces; those are transcripts, quoted rather than summarised, with the invocation above them.
- Quotes from the datasheet are quoted, not paraphrased. The RP2040 and RP2350 datasheets are CC BY-ND, so they are cited and never reproduced here in bulk.
- Each page ends with what it does not establish. Untested is written down as untested; a fix nobody has run on hardware says so.
- Written with AI assistance, which is disclosed on each page. That is also why the evidence is arranged to be checkable rather than believed.