ESP32-P4 (eco2) won't boot: bootloader flashed at 0x0 (should be 0x2000) + eco5-linked bootloader/app crash on eco2 silicon #278

Summary

fbuild cannot produce a bootable image for the ESP32-P4-EV (eco2 silicon, chip rev v1.3). Two distinct bugs in the P4 target config, the second masked by the first:

1. Wrong second-stage bootloader flash offset — fbuild flashes the bootloader at 0x0, but the ESP32-P4 ROM loads it from 0x2000. Result: ROM-level boot loop printing invalid header: 0x47550ff7.
2. Bootloader + app linked against the wrong ROM revision (eco5) for eco2 silicon — once the bootloader is placed at 0x2000, it panics with Illegal instruction at its entry point; the app image is likewise rejected (Segment ... overlaps bootloader stack / No bootable app partitions).

The stock Espressif/Arduino toolchain (PlatformIO framework) boots fine on this exact board, so this is fbuild-specific, not a silicon limitation.

Environment

• Board: ESP32-P4-EV (board = esp32-p4-evboard), COM25, VID 0x303A PID 0x1001 (USB-Serial/JTAG)
• ROM banner: ESP-ROM:esp32p4-eco2-20240710 / Build:Jul 10 2024; esptool reports chip revision v1.3
• fbuild: 2.2.7 (FastLED pin); config branch reference fix/esp32p4-include-paths
• Reached via bash autoresearch esp32p4 --parlio after the include-path fix (PR fix(esp32): strip Windows UNC prefix + collect .S/.s assembly sources (FastLED #2507) #273, merged) — build + flash now succeed; the device never boots the app.

Bug 1 — bootloader flashed at 0x0, P4 ROM expects 0x2000

crates/fbuild-build/src/esp32/configs/esp32p4.json:

"flash_offsets": {
  "bootloader": "0x0",      // <-- WRONG for ESP32-P4
  "partitions": "0x8000",
  "firmware":   "0x10000"
}

ESP32-P4 (like ESP32-C5) loads the second-stage bootloader from 0x2000, not 0x0. Compare the sibling configs, which are correct for their ROMs: esp32.json/esp32s2.json = 0x1000, esp32s3/c3/c6/h2 = 0x0.

Evidence — flash dump after fbuild deploy:

The ROM reads the little-endian word 0x47550ff7 at 0x2000, fails the 0xE9 magic check, and prints invalid header: 0x47550ff7 in a tight reboot loop (observed ~3300×).

Fix: set "bootloader": "0x2000" for esp32p4 (and verify esp32c5, which is also 0x0 and is likely the same bug).

Verified locally: re-flashing fbuild's own bootloader.bin to 0x2000 with esptool clears the invalid header loop and the ROM proceeds to execute the bootloader (see Bug 2).

Bug 2 — bootloader/app built for eco5 ROM, chip is eco2

After placing the bootloader at 0x2000, the ROM loads and jumps to it, and it panics immediately at its entry point:

boot:0x30f (SPI_FAST_FLASH_BOOT)
load:0x4ffb60d0,len:0x1078
load:0x4ffac2c0,len:0xbe0
load:0x4ffaefc0,len:0x3494
entry 0x4ffac2c0
Guru Meditation Error: Core 0 panic'ed (Illegal instruction)
PC : 0x4ffac2c0   <-- == entry; crashes on the first instruction, before any "boot:" log

esp32p4.json links only eco5 ROM scripts:

"esp32p4.rom.eco5.ld",
"esp32p4.rom.eco5.rvfp.ld",
"esp32p4.rom.eco5.libgcc.ld",
"esp32p4.rom.eco5.newlib.ld",
"esp32p4.rom.eco5.libc.ld",

ROM symbol addresses differ between P4 eco revisions; eco5-linked code calling eco2 ROM entry points executes an illegal instruction.

Control experiment (proves it's fbuild-specific, not eco2-unsupported)

Flashing the stock PlatformIO/Arduino bootloader.bin to 0x2000 on the same board boots correctly and prints normal ESP-IDF logs:

E (290) esp_image: Segment 5 0x4ff20d44-0x4ff361f0 invalid: overlaps bootloader stack
E (291) boot: OTA app partition slot 0 is not bootable
E (291) boot: No bootable app partitions in the partition table

So the official bootloader runs on eco2; only fbuild's eco5-linked bootloader crashes. The second error here is the app side of the same problem: fbuild's eco5-linked firmware.bin has a segment layout that's invalid on eco2 (Segment 5 ... overlaps bootloader stack), so even the working bootloader can't load it.

Fix: select ROM scripts by detected chip revision (use eco2/base ROM .ld for eco2 silicon), and link the app for the same revision. Add a chip-revision check / clear error rather than crashing.

Impact

bash autoresearch esp32p4 --parlio builds and flashes but the device never boots the app, so the JSON-RPC handshake times out. This blocks all hardware-in-the-loop autoresearch on ESP32-P4.

Cross-references (FastLED repo)

• FastLED #2510 — agent runbook: get bash autoresearch esp32p4 --parlio working end-to-end (this is the now-identified root cause of "blocker 3 / no host-visible bytes" — the app never booted)
• FastLED #2507 — earlier P4 build failures (resolved by fbuild fix(esp32): strip Windows UNC prefix + collect .S/.s assembly sources (FastLED #2507) #273)
• FastLED #2519 / #2518 — PARLIO show-timing fix whose hardware validation this unblocks
• fbuild fbuild-python DaemonConnection drops PLATFORMIO_SRC_DIR so FastLED autoresearch builds the wrong sketch #274 — separate daemon PLATFORMIO_SRC_DIR bug