greatscottgadgets / apollo Goto Github PK

Seen so far on r0.3 and r0.4 hardware:

(venv) mossmann@costard:~/src/cynthion/cynthion/python$ ~/src/luna/examples/blinky/blinky.py 
INFO    | __init__    | Building and uploading gateware to attached Cynthion r0.3...
Traceback (most recent call last):
  File "/home/mossmann/src/luna/examples/blinky/blinky.py", line 41, in <module>
    top_level_cli(Blinky)
  File "/home/mossmann/src/cynthion/cynthion/python/venv/lib/python3.11/site-packages/luna/__init__.py", line 113, in top_level_cli
    products = platform.build(fragment,
               ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mossmann/src/cynthion/cynthion/python/venv/lib/python3.11/site-packages/amaranth/build/plat.py", line 113, in build
    self.toolchain_program(products, name, **(program_opts or {}))
  File "/home/mossmann/src/cynthion/cynthion/python/venv/lib/python3.11/site-packages/cynthion/gateware/platform/core.py", line 79, in toolchain_program
    programmer.configure(bitstream)
  File "/home/mossmann/src/cynthion/cynthion/python/venv/lib/python3.11/site-packages/apollo_fpga/ecp5.py", line 461, in configure
    self._validate_status(status, expect_done=True)
  File "/home/mossmann/src/cynthion/cynthion/python/venv/lib/python3.11/site-packages/apollo_fpga/ecp5.py", line 334, in _validate_status
    error_handler("Failed to execute last command!{}".format(error_text))
  File "/home/mossmann/src/cynthion/cynthion/python/venv/lib/python3.11/site-packages/apollo_fpga/ecp5.py", line 318, in raise_error
    raise IOError(msg)
OSError: Failed to execute last command! (bitstream provides data past the device's SRAM array / ffffffff)

See greatscottgadgets/luna#241 for how we first encountered this.

I was unable to reproduce this problem with older Apollo firmware (version unknown, but it was using 4 KiB bootloader), but immediately reproduced it upon updating Apollo firmware to 171556d.

In case of a bitstream for a wrong FPGA I get the error message
OSError: Configuration failed: part ID mismatch / (04a00e10)
It seems to be generated here

The message could be a little more clear:

• Why is this an OSError?
• what mismatched (part IDs of the FPGA and the bitstream?)
• add human readable representation of the part IDs
• which part ID is actually shown? the ID in the bitstream or of the installed FPGA?

I would suggest an error message similar to the following:
configuration failed: trying to load a bitstream generated for FPGA Lattice ECP5 LFE5U-12 partid 04a00e10 onto an incompatible FPGA Lattice ECP5 LFE5U-25 partid 0x41111043

Request is addressed to interface 0, instead of the Apollo stub interface.

This is probably due to Apollo only claiming interface 0, and WinUSB enforcing the interface number used in the wIndex field of a request.

July 2023, issue #21 states that "From everything I can tell, at the moment there is no way to actually use the sideband PHY port from the FPGA. At least on the Luna v0.4 that I have." @martinling mentions that Apollo works quite differently in later versions of the Cynthion hardware, compared to v0.4 of Cynthion. Martin goes on to explain more about the changes and answers each of the questions in the issue, but a new issue remains to be resolved: What Apollo and other gateware should do on older board revisions.

We have WCID descriptors in Saturn-V but not Apollo.

From everything I can tell, at the moment there is no way to actually use the sideband PHY port from the FPGA. At least on the Luna v0.4 that I have.

The schematic for the LUNA implies that this should simply be a matter of how the SIDEBAND_RESET signal is driven, and indeed, this controls if the ULPI PHY is kept in reset, but the microcontroller's data lines stay attached to D+ and D-, so the PHY cannot actually take over once out of reset (making this seem to be an issue on Apollo's side).

I looked through the documentation and code for LUNA and Apollo but the only references to the sideband port are tests in LUNA that will pass so long as the FPGA can simply talk to the PHY itself, and floating the reset pin in fpga_io_init() in Apollo. So if there's some other logic involved with that sideband port I'm not seeing it.

Let me know if there's something I'm missing and if I should move this issue to LUNA itself or create a linked issue on that side.

Saturn-V is currently recognised as LUNA r1.0.

The apollo_fpga.support.selftest module imports from prompt_toolkit, but this is not declared as a dependency.

Ideally it would read "Cynthion" when connected to GSG Cynthion hardware and maybe something like "Cynthion-compatible" when connected to non-GSG hardware.

This can result in Apollo claiming the CONTROL port on Cynthion instead of handing it off to the FPGA shortly after start-up.

Due to a quirk of Apollo's behavior, some gateware that starts requesting the CONTROL port early at start-up can gain control of the port, but this is unreliable due to unpredictable timing (presumably FPGA PLL start-up).

Apollo firmware uses bcdDevice to indicate hardware revision. There should also be a vendor request or some method for the host to query the firmware version.

Similarly to apollo configure the command apollo flash_program should check whether the partID of the bitstream matches the partID of the installed FPGA. If not, an error message as described in #14 should be given.

The CLI help text in apollo_fpga/commands/cli.py is outdated. In particular, it mentions the "program" command, which seems to have been renamed "flash" and "flash-program." It is also missing the "leds" command. There might be some other inconsistencies.

This can result in modifications such as a change to BOARD_REVISION_MINOR not taking effect.

Workaround: rm -r _build

I'm not sure what the best solution is. The clean target is defined in an include from tinyusb.

Proposed plan:

• LED A: USB switch is in Apollo/Saturn-V mode (see #38)
• LED B: FPGA is being held offline
• LED C: Saturn-V heartbeat
• LED D: fault, e.g. FPGA failed to configure from flash
• LED E: Apollo heartbeat

[proposal replaced by "Alternative scheme" in comment below]

All LEDs would change function temporarily if a pattern other than idle is in use. The idle pattern would restore the indications above.

It would be nice to be able to toggle between Apollo CONTROL mode and FPGA CONTROL mode.

No license file present

jtag_init() in jtag_tap.c uses jtag_set_current_state(STATE_TEST_LOGIC_RESET) which sets the microcontroller's understanding of the state to Test-Logic-Reset without actually ensuring that the FPGA's JTAG TAP is in that state. This is worked around by calling jtag_go_to_state(STATE_TEST_LOGIC_RESET) immediately after calling jtag_init() (which is done from the host side with vendor request REQUEST_JTAG_GO_TO_STATE after REQUEST_JTAG_START) every time JTAG is initialized.

This is arguably a bug, but it needs further investigation and test.

This is the tracking issue for the next Apollo release.