New Flash supported firmware features

[Folknology]

OK I have been rethinking this, I think I will forgo adding these features as I cannot see a safe way to operate them as the firmware will never know what is synthesised inside the Ice40 and how it operates the flash.

One of the main reasons for adding a fractional flash write was to allow a running soc to run new code without the Ice40 having to relaod the Ice40 SOC image. However I think there might be better ways of doing this:

1) Use a Bootlaoder on The SOC that takes new binaries over the Uart (Like Arduino does)
2) Transfer the binary over the DSPI and have the SOC run this directly.
3) Have the firmware access bus mapped Flash/SDRAM via DSPI which would be properly arbitrated

Thoughts?

[lawrie]

I am very keen that the firmware support writing ROMs to specified addresses in flash memory.

Without this is is hard for users to run my NES and Acorn ports and SaxonSoc using XIP.

Al other FPGAs that I have used have this capability.

I don't mind if that resets the ice40.

If you have a bitstream and a rom in flash and then rewrite the rom and reset the FPGA, it will run the new program.

I don't really know what you mean by a fractional write.

[lawrie]

Your other solutions are much more complex and I think would discourage ports to the Blackice Mx.

The NES and Acorn Atom ports would have been much harder if I had to use one of those solutions and I may not have attempted them.

[Folknology]

I don't really know what you mean by a fractional write.

Just that image for Ice40 and code that runs of SOC being separately written rather than as a single combined image.

[Folknology]

I am very keen that the firmware support writing ROMs to specified addresses in flash memory.

Without this is is hard for users to run my NES and Acorn ports and SaxonSoc using XIP.

Al other FPGAs that I have used have this capability.

I don't mind if that resets the ice40.

I can do this (relatively safely, it might interrupt flash writes from the SOC) when I place Ice40 into reset, but to be clear this is a different function from what I was originally focused on.

BTW this could still result in the flash being corrupted, if for example it was updating the Ice40 config image at the time of our write from the STM32.

[AndyCap]

I'm a bit confused about what the problem is.

Is the issue that there is no way of "safely" writing to an area of flash from the stm side without resetting the ICE40?

[Folknology]

Is the issue that there is no way of "safely" writing to an area of flash from the stm side without resetting the ICE40?

It is safer to reset the Ice40 before trying to access the flash in order to prevent the SOC trying to read/write to the flash at the same time (The STM32 cannot know when it may do this).

A second problem hinted at above is that by resetting the Ice40 we may also still inadvertently interrupt a legitimate write to flash from the SOC, this could of course leave the flash corrupted.

[lawrie]

It is safer to reset the Ice40 before trying to access the flash in order to prevent the SOC trying to read/write to the flash at the same time (The STM32 cannot know when it may do this).

I thought it was necessary rather than safer. If the ice40 has the pins declared as output the attempt to write from the STM32 fails. That is what is currently happening with the existing USB-CDC-Issue 3 firmware.

A second problem hinted at above is that by resetting the Ice40 we may also still inadvertently interrupt a legitimate write to flash from the SOC, this could of course leave the flash corrupted.

I don't really think this is a problem. The user has asked for the STM32 to write to flash, and there is unlikely to be serious corruption.

A lot of ice40 boards are programmed by iceprog. I am pretty sure that resets the ice40 when it writes a file to flash, whatever the offset is, , or it would have the same problem of failing if the flash pins were set to output by the ice40.

[lawrie]

Just that image for Ice40 and code that runs of SOC being separately written rather than as a single combined image.

A combined image is a possibility but separate writes is better as otherwise a lot of padding might be necessary. Also having to concatenate the files complicates the build system. The hardware bitstream and the software image often have completely separate make files.

Most boards I have used allow separate writes of the bitstream and the program rom (or other data). The only one I know where you currently have to write a combined image is Fomu. The TinyFPGA BX lets you (optionally) write a bitstream and a data file in one call of tinyprog (without concatenation).

[lawrie]

1) Use a Bootlaoder on The SOC that takes new binaries over the Uart (Like Arduino does)2) Transfer the binary over the DSPI and have the SOC run this directly.3) Have the firmware access bus mapped Flash/SDRAM via DSPI which would be properly arbitrated

BTW, I do like all these ideas. It is just that they are all harder to implement that a simple copy or execute from flash on the ice40 side.

I have (1) working with the BlackiceMxArduino SaxonSoc, but it is quite complex and it is a bit slow and potentially unreliable.

I was keen to try @AndyCap's firmware and DSPI code to get (2) working. It is what @hoglet used for the Acorn Atom, Beeb etc on the Blackice I/II. But having looked at that recently, when porting the Acorn Atom, it was quite complex and needed a custom STM32 program. So I decided to do the more simple copy from flash memory.

I don't fully understand (3). What sort of API would the STM32 use? Is the idea to just remote the SPI commands?

[Folknology]

I agree, we might need to stress that any SOC writing to flash ability/feature should be minimised and provided with clear warning in order to avoid flash corruption risks. In fact we should dissuade the behaviour generally..

[lawrie]

I agree, we might need to stress that any SOC writing to flash ability/feature should be minimised and provided with clear warning in order to avoid flash corruption risks.

I think FPGA writes to flash are rare. It is just read by most of the projects I have seen and they expect it to be written to by host software.

I have a writeFlash utility that writes to it, but that really only exists because the firmware doesn't currently support writing to flash. I have also written utilities that read from the SD card and then write to flash. That is quite useful to choose which program to run from a menu.

But in these cases the write occurs immediately after a request from the user. I can't think of a case when an FPGA design would be continually writing to flash. You are more likely to use RAM or an SD card for that.

[lawrie]

Just that image for Ice40 and code that runs of SOC being separately written rather than as a single combined image.

Another problem with a combined image is that it would not let me do what I currently do for my NES and Acorn demos. I have the NES rom at address 0x40000 and the Acorn rom at address 0x70000. I can then run either the NES or Acorn bitstream.

A combined image for the NES rom would currently have to write the whole of flash memory.

If I could write multiple files to flash at different addresses (like tinyprog supports) rather than having to concatenate them, that would be fine.

[ajlennon]

Apologies if this is a stupid comment but can't we support Intel Hex format? That gives us multiple blocks with different start points I think?

[Folknology]

Ok I have been playing around with different ideas, here is my new proposal for extended flash support:

When IceCore boots up it is in regular BlackIce program mode, no flash commands.

To place this into Flash Mode issue the following:

cat flash.mode > /dev/ttyACMO

That places IceCore in a safe mode for Flash commands, the yellow led lights up to indicate such.
Now in flash mode we can issue supported flash commands (read/write etc..)
The IceCore will remain in Flash mode until any of the following occurs:
1. Mode button pressed takes it out of flash mode
2. An Ice40 image file is sent, in which case it will be written to flash and then the Ice40 will be restarted from that flash in regular BlackIce mode
3. A mode command is sent to restore regular BlackIce Mode:

cat ice.mode > /dev/ttyACMO

How would this suite everyone?

BTW there would be no manually selecting flash mode using the button in this version

[Folknology]

Apologies if this is a stupid comment but can't we support Intel Hex format? That gives us multiple blocks with different start points I think?

I am not quite sure what you mean, are you referring to the SOC binaries rather than the Ice40 images?

The Flash must contain an Ice40 image (cannot be Intel hex format, it's much more basic) and then a SOC specific binary(s) which could I guess be Intel hex format, not really my area of expertise, supporting such a thing maybe more onerous bootloader wise though?

[ajlennon]

If I could write multiple files to flash at different addresses (like tinyprog supports) rather than having to concatenate them, that would be fine.

Wouldn't use of an Intel Hex format support this?

[ajlennon]

i.e. cat the hexfile into the STM32 and it would then support decoding that to write to the appropriate locations

[Folknology]

i.e. cat the hexfile into the STM32 and it would then support decoding that to write to the appropriate locations

Ah ok, I didn't get that at first, I see what you are saying now. It maybe difficult as you would have to get it into the hex file format to begin with. The OS FPGA tools do not support this AFAIK we would have to write some that did?

We would then have to wirte a firmware decoder that also understood how to unpack it?

[lawrie]

How would this suite everyone?

Sounds plausible to me, but I would like to see the complete proposal including what flash commands are supported.

I certainly like the fact that it is all controlled by software and pressing the mode button is not necessary.