gateware.platform: add ApolloAdvertiser hook in boards with USB switch

[mndza]

control_phy_hook is called during USBDevice elaboration and:

• Adds ApolloAdvertiser submodule.
• Modifies the device descriptor to add an additional interface with bInterfaceClass=0xFF and bInterfaceSubclass=0 (Apollo interface).
• Adds request handler with that interface as recipient for stopping advertisement.

Merge in block with:

• gateware.usb.usb2.request: add claim to RequestHandlerInterface luna#225
• gateware.usb2: add port-specific hook support in USBDevice luna#226
• Add support for one-way FPGA advertisement pin apollo#22

[martinling]

This needs a quick update to add the hook to the r1.4 platform.

However, even after making that change myself, this isn't currently working for me in cynthion-test.

The visible symptom is that when running a bitstream that uses the CONTROL port, I tell Apollo to honor_fpga_adv, and that request succeeds, but Apollo remains enumerated on the CONTROL port. However, when the bitstream is loaded from flash at reset, it does enumerate on the CONTROL port, which suggests the advertising mechanism is initially working.

I'm using current main/master branches of Apollo, LUNA and Cynthion with greatscottgadgets/apollo#22, greatscottgadgets/luna#225, greatscottgadgets/luna#226 and this PR merged, with the r1.4 platform patched to include the hook as per r1.3.

You should be able to reproduce this as follows (no Tycho required):

1. Check out the update-dependencies branch of https://github.com/martinling/cynthion-test/ and update submodules.
2. Edit the Makefile and set MAJOR and MINOR to match your Cynthion board.
3. Delete firmware.bin and all the .bit files (these are prebuilt for r1.4).
4. Run make firmware bitstreams to set up the environment and rebuild the binaries.
5. Put Cynthion into Saturn-V mode and run environment/bin/fwup-util firmware.bin to flash Apollo.
6. Run environment/bin/apollo flash with either analyzer.bit, or speedtest.bit, both of which use the CONTROL port.
7. Press the RESET button.
8. The FPGA enumerates on the CONTROL port.
9. Press the PROGRAM button.
10. Apollo enumerates on the CONTROL port.
11. Run the following with environment/bin/python:

from apollo_fpga import ApolloDebugger
apollo = ApolloDebugger()
apollo.honor_fpga_adv()

12. Apollo remains on the bus.

[mndza]

I think I have found the root cause of the problem.

We changed the behavior of the PROGRAM button in greatscottgadgets/apollo#28: when Apollo takes over the control port, it also unconfigures the FPGA. Consequently, honor_fpga_adv will simply do nothing because no message has been received in the current time window.

Could you try the following?

from apollo_fpga import ApolloDebugger
apollo = ApolloDebugger()
apollo.soft_reset()
apollo.honor_fpga_adv()

I did not test this properly after that merge because of my PCB issues with FPGA_ADV (a bad contact that I was unable to rectify).

[martinling]

Could you try the following?

from apollo_fpga import ApolloDebugger
apollo = ApolloDebugger()
apollo.soft_reset()
apollo.honor_fpga_adv()

This isn't working either - Apollo stays enumerated. But if I push RESET, the bitstream loads from flash and enumerates.

Configuring a bitstream into RAM also doesn't work - the honor_fpga_adv call is there at the end of the configure_fpga command, but after starting the bitstream, Apollo stays enumerated. Yet the bitstream is definitely running, because in the case of speedtest.bit it enumerates on the other ports successfully. And if I write that bitstream to flash, Apollo hands CONTROL over to it on startup.

[martinling]

We've resolved the above issues, and this is now being used successfully on the update-dependencies branch of the Cynthion factory test.