Looking at the current version of iceboot, it seems that it is programming the ice40 directly, i.e under reset with the ice40 acting as an SPI slave). Also as the available SPI hardware interfaces are in use for other purposes, it is bit-banging the SPI. Is that correct?
So, it appears that currently the SPI flash memory is not being used at all.
Going forwards will this be that way things work, by default?
It would seem better for the default action to be to write the bitstream to the flash memory. This has the advantages that it is then permanently in memory until overwritten, and that hardware SPI can be used. Is this the intention?
In some cases, users may want to create a multi-boot configuration with icemulti, so I believe that should be supported.
The code in the rbits function is currently parsing the bitstream. After the discussion a while ago with @rmiller, I don't think this is a good idea and it would need changing for multi-boot configurations.
There is also a requirement to write other files to the flash memory, for example a software binary to be executed by a SoC. This would require specifying an address for where in flash the file should be written.
There are options for how much intelligence is on the host computer and how much is in iceboot.
The TinyFPGA BX tinyprog program puts most of the intelligence in the host and sends flash memory commands to the equivalent of iceboot. The current iceboot puts all the intelligence in the STM32 processor, not the host.
There is a stated requirement to be compatible with Blackice and Blackice II and allow bitstreams to be written directly to USB device (/dev/ttyACM0 on Linux). I don't really know why this is a requirement, as software is unlikely to rely on it, only make files.
One option is to send commands to the USB programming device. A command could be encoded in a byte. If 0x7e, which starts a bit stream was treated as a command, this would support forwards compatibility.
Commands could be send either by a utility like tinyprog or by adding a header starting with the command byte to a file and then copying it to the USB stream. The two methods are equivalent.