orangecrab-fpga / orangecrab-hardware

ECP5 breakout board in a feather physical format
Other
485 stars 57 forks source link

Problems with 85F #48

Open japm48 opened 2 years ago

japm48 commented 2 years ago

I am having some issues with the OrangeCrab variant 85F. When I program it I get the following:

$ dfu-util -D blink_reset.dfu
Match vendor ID from file: 1209
Match product ID from file: 5af0
dfu-util: More than one DFU capable USB device found! Try `--list' and specify the serial number or disconnect all but one device

(Note: using latest dfu-util version 0.11, provided by oss-cad-suite-build)

This is the corresponding device list:

$ dfu-util --list
Found DFU: [1209:5af0] ver=0101, devnum=7, cfg=1, intf=0, path="3-2", alt=1, name="0x00100000 RISC-V Firmware", serial="UNKNOWN"
Found DFU: [1209:5af0] ver=0101, devnum=7, cfg=1, intf=0, path="3-2", alt=0, name="0x00080000 Bitstream", serial="UNKNOWN"

If I select the "alternative 0" (dfu-util -a 0 -D blink_reset.dfu) everything works fine (modulo the error message in #37).

Litex/nmigen/etc., all assume that there is only one "device" (1209:5af0), so I understand this is not intended by design. If so, is this fixed in the last DFU bootloader? I may have received a unit with an outdated version.

Possibly useful: lsusb output.

Also, apparently, the 25F and 85F bitstreams are incompatible, but dfu-util will happily a bitstream, but the FPGA is stuck doing nothing until reset into DFU mode. This is especially frustrating as the toolchains hardcode 25F in them (I'll probably post some PRs once this is sorted out). I would suggest using a separate USB PID, but of course, it is already too late and I understand PIDs are a scarce resource; so maybe there is a way to still convince dfu-util to refuse to upload it? (maybe iSerialNumber or in the iProduct string).

gregdavill commented 2 years ago

This seems like a combination of 2 issues, which I'll cover separately

Alt interfaces

The Alt interfaces were actually added to newer boot loaders. The idea is that you can load a bitstream to one section of FLASH, and if your bitstream requires firmware or other data then this can be loaded to the second section. However this creates the issue you've described, where you get an error asking to specify an alt interface.

This should be fixed upstream where required, basically just ensuring that --alt 0 is passed, which will be backwards compatible with the older bootloaders. I'll take a look over LiteX/Amaranth(nmigen) implementations to fix this.

25F / 85F bitstream compatibility

Correct. Bitstreams generated for the 25F will not load onto the 85F, and vise-versa. I'd not considered this when we introduced the 85F OrangeCrabs.

Ideally at a minimum there should be a mechanism to alert the user that a compiled bitstream is not compatible with the board they're trying to load it onto. There are a few ways to achieve this:

As you mention adding a new PID has drawbacks. We're using PIDs from pid-codes, so there isn't any extra cost, but I'd like to avoid getting new PIDs if not required.

We can add info about which FPGA is supproted in the USB descriptors, dfu-util lets us target alt section by name, not just number. So that might be a solution. But this would require further upstream changes.

Part of the bitstream header contains the device IDCODE, this is checked by the FPGA when it's loading and if it doesn't match the device then an error is generated. We can use this same code, the bootloader can check that the bitstream being downloaded is compatible. If it's not then it can present

errTARGET: File is not targeted for use by this device.

This should have the effect of showing this or a similar message from dfu-util. Indicating to the user that an error has occurred with the device type.

japm48 commented 2 years ago

Great, thanks for the detailed explanation!

Part of the bitstream header contains the device IDCODE, this is checked by the FPGA when it's loading and if it doesn't match the device then an error is generated. We can use this same code, the bootloader can check that the bitstream being downloaded is compatible.

Interesting.


Just another question: what would you suggest for flashing the bootloader? Apparently fomu-flash only works on RPi.

stevecheckoway commented 1 year ago

For future users reading this issue, in the Makefiles for the orangecrab-examples, you need to change the dfu target to be

dfu: ${PROJ}.dfu
    dfu-util -a 0 -D $<

and you need to change the %_out.config target to be

%_out.config: %.json
    nextpnr-ecp5 --json $< --textcfg $@ --85k --package CSFBGA285 --lpf ..$(PATH_SEP)orangecrab_${VERSION}.pcf

The two changes are adding -a 0 as an argument to dfu-util and changing --25k to --85k to generate the correct bitstream for the LFE5U-85F.