DFU boot magic at 0x38000000 collides with HISTO SOF marker — streamed data can spoof a bootloader request across warm reset

[boringethan]

What's wrong

The DFU-request magic value 0xDEADBEEF is written to 0x38000000 (Core/Src/main.c, OW_CMD_DFU path) and read back on boot (Core/Src/system_stm32h7xx.c). That address is inside spi6_buffer — the FPGA histogram DMA buffer at the bottom of SRAM4 (D3) — and 0xDEADBEEF is also HISTO_SOF_MARKER (Core/Inc/histo_fake.h). Streamed histogram data landing at that word can therefore spoof a bootloader-entry request across a warm reset.

Where

• Core/Src/main.c — writes *((uint32_t *)0x38000000) = 0xDEADBEEFU;
• Core/Src/system_stm32h7xx.c — reads/clears the same word on boot
• Core/Inc/memory_map.h — no dedicated, non-DMA location defined for boot flags

Impact

Spurious DFU entry / boot-flag corruption is possible while histogram streaming is active. Confirmed still present on next as of 20edc5b.

Fix already written (orphaned)

Commit cf3f91f on branch feature/fast-dfu-deploy ("fix(boot): move DFU boot flags out of spi6_buffer, reset on bootloader jump-entry") relocates the boot flags to the unused top words of SRAM4 and adds a jump-entry clean-reset. It was bundled into stale PR #44, whose deploy feature already merged separately via baa37a5; the fw fix never landed and does not cherry-pick cleanly onto current next (conflicts in memory_map.h and main.c).

It also overlaps in-flight DFU-boot work on fix/dfu-marker-survives-seed ("seed SRAM4 after SystemInit so the DFU enter marker survives boot") — reconcile the two approaches before porting. Needs a fresh PR off next + bench validation (the jump-to-app hang means deploys still need a power cycle).

[boringethan]

Correction: fix/dfu-marker-survives-seed (5721ade) is already merged into next, not in-flight. It deliberately keeps the marker at 0x38000000 and moves the SRAM4 ECC-seed to just after bl SystemInit so CheckBootloaderFlag() consumes the marker before it's zeroed (HW-verified: enter_dfu now enumerates 0483:DF11).

That doesn't resolve this issue — the marker still shares 0x38000000 with spi6_buffer / HISTO_SOF_MARKER. But it does mean the cf3f91f relocation approach must be reconciled with the merged SRAM4-seed timing in startup_stm32h743xx.s: relocating the flags out of 0x38000000 changes what CheckBootloaderFlag() reads and where the seed must avoid, so both the startup seed order and CheckBootloaderFlag() need updating together.