FPGA load via USB broken under Linux

[GregAC]

I've had a go using a build of the firmware from the most recent commit to trial FPGA image loading via USB (with a fix for the v0.2 PCB issue: https://github.com/newaetech/sonata-pcb/issues/4). It seems it only works under Windows, copying the same bit file under Windows to the FPGA folder works as expected but doing it under Linux has no effect.

I've done a little bit of debugging and it seems we don't hit this block of code: https://github.com/newaetech/sonata-rp2040/blob/main/usb_msc/msc_disk.c#L149 when Linux does the USB write. Perhaps it goes about things in a different way to Windows and the code is assuming the Windows way of doing things?

[alex-dewar]

The chain of logic there is

1. Check that the write is outside the first 4 clusters, since they should be the README and other folder info
2. Get the information for the FPGA folder (it does actually look through the file system for the right folder info)
3. Look for the first valid file in the folder

​1 or 3 could be an incorrect assumption. Hopefully it's a simple bug rather than Linux doing anything too crazy.

[alex-dewar]

Unfortunately, it looks like Linux writes the actual file data before it writes any information about that file, such as its length or location. As the RP2040 doesn't have enough RAM for this, we'll need to write the bitstream to SPI flash, then read it back off the flash once we know where it's supposed to go.

This might make the FLASH/FPGA folders unnecessary, since transfers always have to be written to flash anyways.

[colinoflynn]

In theory a "FPGA" folder could still be used, but yeah would actually be holding in SPI flash. Not sure if there is much point in that then as you say, and instead just have the FLASH slots. By default it could always write a new bitstream to the FPGA if it's the selected slot?

[alees24]

Does this help?

I've done a bit of poking around, and the '<>.bit' bitstream file starts with a header that contains a sequence of fields, as described here which can be used to determine the size of the bitstream data, as well as validating that the file is in the expected format, of course.

The byte sequence 0x65 <a> <b> <c> <d> <...bitstream data> encodes the bitstream length using a,b,c,d in big endian order and - with the proviso that we assume that the clusters within the file are written to the medium in contiguous, ascending order (not guaranteed, but robust in practice) could allow the bitstream to be processed as it's received.

[alex-dewar]

The main issue is that we don't know which folder the bitstream is being written to until it's fully transferred. The original plan was to have separate folders for loading only to the FPGA vs also loading into SPI flash, as well as for loading firmware. It would be preferable not to have to reprogram the SPI flash every time you just want to load a bitstream.

[alex-dewar]

Programming should now work on both Windows and Linux. We could do something like a config file to allow users to program spi flash, just the FPGA, or both.

[alex-dewar]

Closing, as this should be pretty reliable now