Sideband PHY unusable on older Cynthions

[Lunaphied]

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.

[martinling]

This all works quite differently in later versions of the hardware - which is in the process of moving to its own repository.

Instead of the Host and Sideband ports, there's now a Control port and an Aux port. The Control port is used for programming, and connects to either the MCU or to the FPGA-controlled PHY, via a D+/D- switch that's controlled by the MCU. So we don't have the same issue on newer boards: to hand off the port, the MCU can just control that switch. It no longer needs to control the PHY reset.

On r0.4, in order for the FPGA to use the Sideband port, the MCU would need to both release the SIDEBAND_RESET signal and also release its data lines by switching them to GPIO mode and configuring them as inputs. At that point I think it should be possible to have the FPGA use the Sideband port via the PHY.

I don't think there's currently a good place to make that fix for r0.4, though.

Something that's not in mainline Apollo yet, but is in the pipeline, is some logic for the firmware to decide at startup whether to take control of the USB port that the MCU is attached to, or leave it to the FPGA - as well as being able to override that choice with the Program button. We'll also be adding a new vendor request that tells the firmware to release the port it's using to the FPGA.

Once we have those features, I think it would be straightforward to backport that behaviour to r0.4 by having it drive or release the PHY reset & its data lines, rather than by controlling the D+/D- switch.

[Lunaphied]

Ah I figured something like that was the case.

I actually don't think the situation looks as bad for r0.4 as it seems though. The reset defaults to being pulled low, keeping the PHY in reset and letting the microcontroller take charge.

I think this means that the microcontroller side can simply always treat that GPIO as an input and read the value (which would be driven by the FPGA) to decide what actions to take.

I already have a functional PoC to get those lines to disconnect via a vendor command I added but working out how to reinitialize them later has proven to need a bit more thought than just hacking something together.

Once I've worked out that bit, it should be possible to connect it to the GPIO input in addition to the vendor command.

As an aside, am I correct in thinking that without the sideband PHY switch there's not a good way to analyze traffic from a different host than the device is connected to?

[martinling]

As an aside, am I correct in thinking that without the sideband PHY switch there's not a good way to analyze traffic from a different host than the device is connected to?

No. Capturing USB traffic for analysis is done by using the target PHY in passive mode, which is attached to the D+/D- pair running between the Target-A and Target-C ports. It's a passive sniffer - the traffic doesn't pass through the FPGA. The analyzer's USB interface shows up on the Host port (r0.4) or Control port (r0.5+).

[mossmann]

I've reopened this because we plan to try a fix. Part of the problem with using the Sideband port is that there needs to be a way to tell Apollo to take over the port. The obvious way to do this is with the DFU button, but we haven't ever implemented the DFU button for older Cynthions, partly because of complications with the button's microcontroller pin being shared with LED A. We'd like to try disabling LED A and responding to DFU button presses which would allow the user to switch from the Sideband PHY to Apollo.

[mossmann]

Currently Apollo does allow the FPGA to use the Sideband PHY, but it is difficult or impossible for Apollo to regain control of the USB port once the FPGA is configured with gateware that uses the Sideband PHY.