Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems with 85F #48

Open
japm48 opened this issue Jan 3, 2022 · 3 comments
Open

Problems with 85F #48

japm48 opened this issue Jan 3, 2022 · 3 comments

Comments

@japm48
Copy link

japm48 commented Jan 3, 2022

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
Copy link
Collaborator

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:

  • Assign a new PID for 85F bootloader
  • Add device type in USB descriptor
  • Add check to the bootlaoder

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
Copy link
Author

japm48 commented Jan 5, 2022

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
Copy link

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.

orangecms added a commit to platform-system-interface/amaranth-boards that referenced this issue Jan 8, 2023
The newer bootloader on the 85F variant exposes two devices.
The first one (0) is the bitstream:

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

See also: orangecrab-fpga/orangecrab-hardware#48

Signed-off-by: Daniel Maslowski <info@orangecms.org>
whitequark pushed a commit to amaranth-lang/amaranth-boards that referenced this issue Jan 8, 2023
The newer bootloader on the 85F variant exposes two devices.
The first one (0) is the bitstream:

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

See also: orangecrab-fpga/orangecrab-hardware#48

Signed-off-by: Daniel Maslowski <info@orangecms.org>
lethalbit added a commit to shrine-maiden-heavy-industries/torii-boards that referenced this issue Oct 23, 2023
The newer bootloader on the 85F variant exposes two devices.
The first one (0) is the bitstream:

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

See also: orangecrab-fpga/orangecrab-hardware#48

Signed-off-by: Daniel Maslowski <info@orangecms.org>
Co-Authored-By: Daniel Maslowski <info@orangecms.org>
Co-Authored-By: Aki Van Ness <aki@lethalbit.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants