Not sure what you are asking me. I don't really like modes at all, particularly ones that involve pressing buttons.
For flash writing, there are still various use cases to consider:
- Writing bit stream to address 0 - DONE
- Writing a warm boot configuration to address 0
- Writing a bitstream to first warm boot image (probably address 0xa0)
- Writing a bitstream to second warm boot image (probably address 0x28000)
- Writing software binary to flash memory (probably address 0x50000)
A warm boot configuration includes a 160-byte header and two bitstreams. The second one isn't really necessary as it is a default. I am currently assuming we use the same mapping for a two-image warm boot configuration as the TinyFPGA BX. There is not much choice if you create it with icemulti, given the size of the flash memory. You could put the logic that icemulti uses to create the header into the firmware.
A software binary, which could be executed with XIP, or copied into RAM, can be any length, and could be written to other addresses.
To support warm boot configurations, a way to boot into the second (user) image without writing to flash, is needed.
The TinyFPGA BX tinyprog utility has options: -b to boot into user configuration (address 0x28000), -p to write to the user configuration, -u to write a software binary. It can combine these and write a bitstream and software binary in one go (useful for SoCs). You can also, optionally specify an address. It gets the length from the file parameter(s) you give it.
If you want to stick with modes, you could have a direct configuration mode, a flash configuration mode and a command mode for all these options.