Detailed description
- This is a small new feature in the framework of Target Flash API.
- The existing problem is it's hard to check how much of flash is empty (only via
(gdb) x/16zw 0x08004000 etc.)
- This PR solves it by implementing and providing a target remote monitor command to run a blank-check against a connected halted target.
Many alternative gdbservers already implement a similar mechanism -- openocd flash, pyocd, Segger JLinkGDBServer, etc.
I opted to reuse the whatever flash write buffer is allocated in BMP heap for fast block reads (like bmd_crc32). The memcmp could be optimized to run in 4 bytes per comparison, but for a quick PoC 1 byte is enough, I get I/O bounded on swdptap.c (100-150 KiB/s for FS probes).
Tested on BMDA for dual blackpills, as usual, over JTAG transport, example output is
$ ./build/blackmagic -j -f 8M -M blank_check
DPv0 detected based on JTAG IDCode
Blank 0x08020000+131072
Blank 0x08040000+131072
Blank 0x08060000+131072
Blank 0x08010000+65536
Has data at 0x08000000
Blank 0x08004000+16384
Blank 0x08008000+16384
Blank 0x0800c000+16384
Notice how it walks the singly linked flash bank list backwards, but walks eraseblocks forwards. I erased the BMF from DUT, keeping only the BMD bootloader on it (in first 16 KiB). Output in GDB is similar, but there are progress dots printed before some lines.
Needs testing on smaller probes. Future usage could be skipping vFlashErase-triggered erase delays if reading memory-mapped flash is faster than waiting on it to erase (break-even is different for genuine STM32 with true simultaneous mass-erase vs. The Compatibles which back it with some sequential slow QuadSPI-like flash). It could also have interesting interactions with mass-erase -> load (skips all slow sector erases and starts writing to empty flash immediately), eliminating some unresponsiveness.
Your checklist for this pull request
Closing issues
## Detailed description
* This is a small new feature in the framework of Target Flash API.
* The existing problem is it's hard to check how much of flash is empty (only via `(gdb) x/16zw 0x08004000` etc.)
* This PR solves it by implementing and providing a target remote monitor command to run a blank-check against a connected halted target.
Many alternative gdbservers already implement a similar mechanism -- openocd flash, pyocd, Segger JLinkGDBServer, etc.
I opted to reuse the whatever flash write buffer is allocated in BMP heap for fast block reads (like bmd_crc32). The memcmp could be optimized to run in 4 bytes per comparison, but for a quick PoC 1 byte is enough, I get I/O bounded on swdptap.c (100-150 KiB/s for FS probes).
Tested on BMDA for dual blackpills, as usual, over JTAG transport, example output is
```c
$ ./build/blackmagic -j -f 8M -M blank_check
DPv0 detected based on JTAG IDCode
Blank 0x08020000+131072
Blank 0x08040000+131072
Blank 0x08060000+131072
Blank 0x08010000+65536
Has data at 0x08000000
Blank 0x08004000+16384
Blank 0x08008000+16384
Blank 0x0800c000+16384
```
Notice how it walks the singly linked flash bank list backwards, but walks eraseblocks forwards. I erased the BMF from DUT, keeping only the BMD bootloader on it (in first 16 KiB). Output in GDB is similar, but there are progress dots printed before some lines.
Needs testing on smaller probes. Future usage could be skipping vFlashErase-triggered erase delays if reading memory-mapped flash is faster than waiting on it to erase (break-even is different for genuine STM32 with true simultaneous mass-erase vs. The Compatibles which back it with some sequential slow QuadSPI-like flash). It could also have interesting interactions with mass-erase -> load (skips all slow sector erases and starts writing to empty flash immediately), eliminating some unresponsiveness.
## Your checklist for this pull request
* [x] I've read the [Code of Conduct](https://github.com/blackmagic-debug/blackmagic/blob/main/CODE_OF_CONDUCT.md)
* [x] I've read the [guidelines for contributing](https://github.com/blackmagic-debug/blackmagic/blob/main/CONTRIBUTING.md) to this repository
* [x] It builds for hardware native (see [Building the firmware](https://github.com/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-firmware))
* [x] It builds as BMDA (see [Building the BMDA](https://github.com/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-app))
* [x] I've tested it to the best of my ability
* [x] My commit messages provide a useful short description of what the commits do
## Closing issues