>>> ecp5.flashrd(0,32) bytearray(b'\xff\x00Lattice Semiconductor Corporat')
>>> ecp5.flashrd(0x340000,32) bytearray(b'3\x04\x05\x00\xb3\x84\x05\x003\t\x06\x00\xef\x00@v3\x08\x05\x003\x05\x04\x00\xb3\x85\x04\x003\x06\t\x00') >>> ecp5.flashrd(0x380000,32) bytearray(b'\x13\x02\x05\x00\x93\x84\x05\x00\x97\xc2\x06\x00\x83\xa2\x82\xd9s\x90R\x10s\x10@\x10\x93\x02@\x00cRR"')
@Dolu1990 @emard As I understand the conversation, the current hypothesis is that the flash rom gets in a confused state during FPGA load.
That brought back a memory of working on an i2c driver (h/w and s/w) a few weeks backs for the Cortex. To get it working, one of the things was to always reset the bus/devices. For i2c this means clocking the bus until all devices release the data line and then issuing a start and a stop condition, as a stop condition terminates any pending command.
I could imagine that the flash SPI bus may need something similar, like clocking it for n pulses followed by a "soft reset" command to the device (if such a command exists).
So maybe try:
Now I came across this, apparently JEDEC standard JESD252 specifies a method to reset an SPI flash chip. If I understand the figure correctly, CLK is held low (in mode 0) and CS is used to clock the chip. The data line must carry 0-1-0-1 for a reset to happen:
mmc part, and it it lists partitions, do "boot".