-
Notifications
You must be signed in to change notification settings - Fork 59
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
Comments
This seems like a combination of 2 issues, which I'll cover separately Alt interfacesThe 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. This should be fixed upstream where required, basically just ensuring that 25F / 85F bitstream compatibilityCorrect. 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.
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, 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
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!
Interesting. Just another question: what would you suggest for flashing the bootloader? Apparently |
For future users reading this issue, in the dfu: ${PROJ}.dfu
dfu-util -a 0 -D $< and you need to change the %_out.config: %.json
nextpnr-ecp5 --json $< --textcfg $@ --85k --package CSFBGA285 --lpf ..$(PATH_SEP)orangecrab_${VERSION}.pcf The two changes are adding |
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>
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>
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>
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 convince
dfu-util
to refuse to upload it? (maybeiSerialNumber
or in theiProduct
string).The text was updated successfully, but these errors were encountered: