Open japm48 opened 2 years ago
This seems like a combination of 2 issues, which I'll cover separately
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.
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.
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.
For future users reading this issue, in the Makefile
s 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.
I am having some issues with the OrangeCrab variant 85F. When I program it I get the following:
(Note: using latest
dfu-util
version 0.11, provided byoss-cad-suite-build
)This is the corresponding device list:
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 hardcode25F
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 convincedfu-util
to refuse to upload it? (maybeiSerialNumber
or in theiProduct
string).