tockloader/board_interface: add flash-file support for stm32f4

[lschuermann]

This is useful because Tockloader can't install apps on these boards directly, given the erase-unit for flash pages on the STM32F is non-uniform and not equal to the flash page size.

[bradjc]

I think this is what bundle_apps is for, does that work? Eg

tockloader/tockloader/tockloader.py

Lines 139 to 142 in bcc70c3

	"stm32f4discovery": {
	"start_address": 0x08040000,
	"cmd_flags": {"bundle_apps": True},
	},

[lschuermann]

Hm, good point. Installing apps still didn't work, so I think there's still a bug.

But flash-file support can co-exist with direct flash access through a debugger anyways, right?

[bradjc]

Yes, but while the flash-file support is convenient when needed, I'm hesitant to lean into it. It's a much more old school approach. Everything can be done via command-line arguments for use cases that need it, but I don't want to converge on every board kind of supports both direct access and a shadow copy and which is getting used becomes confusing.

[lschuermann]

I disagree. I think the flash file support has legitimate use-cases even when proper direct access is supported and working, e.g. to pre-build an image that is flashed to devices (which appears to be a common use-case among the current production users of Tock).

[bradjc]

Ok, you've convinced me its ok for tockloader to have this setting. But, I remain convinced that the kernel's makefiles should as much as possible only flash the kernel, and only support flash-file as a last resort.

[lschuermann]

Ok, you've convinced me its ok for tockloader to have this setting. But, I remain convinced that the kernel's makefiles should as much as possible only flash the kernel, and only support flash-file as a last resort.

I agree with that. Users should preferably use direct flashing wherever possible. Flash-file is great for cases where (a) direct is not supported or (b) special use-cases, like pre-built binaries in CI or fully signed flash images.