nrf7002dk flash headroom: earlier measurements retracted, needs a verified build to assess

[mikeysklar]

The measurements originally in this issue are retracted. Do not rely on them.

They were produced by a run where make ... | tail reported tail's exit status rather than the build's, so failed builds looked like successes, and by a toolchain we could not confirm matched CI. Every byte count previously here, the 944 KB region size, the 100.00% figures and the 44 and 12 bytes free, came from that run. All of it is withdrawn.

Recording the question anyway, because flash pressure on nordic_nrf7002dk constrains what we can add to shared ports/zephyr-cp code.

What is actually verified

Checked against adafruit main:

• Two of the 37 zephyr-cp board directories disable modules. nordic/nrf7002dk disables six (aesio, adafruit_bus_device, zlib, jpegio, tilepalettemapper, gifio), more than any other board. nordic/nrf54h20dk disables three. Every other zephyr-cp board disables nothing.
• CI builds the board. ports (zephyr-cp) / board (nordic_nrf7002dk) is one of 27 zephyr-cp board jobs, so a change that overflows it turns CI red.
• It carries Adafruit's VID 0x239A with PID 0x8168, and Scott Shawcroft is the most frequent author of its board files.
• It passed CI on supervisor/web_workflow: check the listener socket calls for failure adafruit/circuitpython#11207, so as of that commit it still links.

The six disabled modules are the strongest signal that the board is tight, since nothing else in the tree needs that treatment. That is an inference from configuration, not a measurement.

What is not known

How much flash headroom the board actually has, and therefore whether small additions to shared zephyr-cp files are safe. Answering that needs a build with a toolchain confirmed to match CI, with the exit status checked properly.

One early version of the scan timeout patch did fail to link on this board with a FLASH region overflow. That build came from the same unverified setup, so treat it as a hint that the margin is small rather than as evidence of any specific number.

The question

If the margin really is small, it is worth asking directly rather than guessing: should fixes touching shared zephyr-cp code be conditional, should another module be disabled on that board, or is it due for a different partition layout.

Relevant to #57, #58, #59 and PR #60, all of which touch shared zephyr-cp files.

[mikeysklar]

Retracting the numbers in this issue. They came from a broken build script and a toolchain that does not match CI, so they do not support the conclusion.

What was wrong

The wrapper used to build nordic_nrf7002dk was:

make BOARD=nordic_nrf7002dk 2>&1 | tail -25
echo "BUILD_EXIT=$?"

$? after a pipeline is tail's status, so it was always 0, and tail -25 truncated the log so the linker error often fell outside what was then grepped. Every "builds OK" for that board in this issue is unverified.

Re-run with set -o pipefail, the exit code captured directly, and a check that zephyr.elf actually exists:

tree	result
fb2568d8a0 unmodified	MAKE_EXIT=2, no ELF, region FLASH overflowed by 840 bytes
30ae4d5c77 unmodified (after the bleio merge)	same, 840 bytes

So the board was already failing here before any of our changes. The claim that our timeout patch overflowed it by 28 bytes, and the 44 and 12 byte headroom figures, are all withdrawn.

Why it probably is not an upstream break

This build uses Homebrew arm-none-eabi-gcc 14.3 through ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb, not the Zephyr SDK that Adafruit CI uses. Code size differs between them, so an overflow here does not mean an overflow there. Upstream CI for the bleio merge was still running when this was checked, so its result is unknown either way.

What is still true

The board does carry DISABLED_MODULES=["aesio", "adafruit_bus_device", "zlib", "jpegio", "tilepalettemapper", "gifio"] and is the only zephyr-cp board that disables anything, so it is genuinely the tightest board in the port. That much is visible in the tree and does not depend on my build.

But flash headroom cannot be measured meaningfully from this setup. Anyone wanting a real number needs the Zephyr SDK toolchain, or should read it off a CI artifact.

The SiWx917 build results elsewhere in these issues used a different wrapper that checks the exit code directly and confirms zephyr.rps was produced, so those are unaffected.