cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
frosteyes
Adventurer
Adventurer
778 Views
Registered: ‎12-15-2016

New USB__RESET__MODE in ZynqMP Processing System design - clarification

Jump to solution

From version 3.2 of the Zynq UltraScale+ MPSoC processing customize IP setup, the USB have got the PSU__USB__RESET__MODE.

Though it is not documented exactly what it does and how it is used.

It has a number of options - Boot Pin, Shared MIO pin, Separate MIO pin, Disable. It default to Boot pin,

What is the intended use for each of those options?

My understanding is that it is a reset going to the cyrres GTR below the DWC3. Is this correct?

Is it possible to create the equivalent phy reset of the GTR from register writes, or better, have an interface from the Linux kernel, to do the same from userspace, without having the hardware wired up.

 

I am not sure on the forum location, so please move if you find it more relevant in another subforum.

I have an external CCG (Usb type-C controller), so I use this for initiating the USB from userspace anyway.

1 Solution

Accepted Solutions
irohloff
Visitor
Visitor
169 Views
Registered: ‎08-20-2014

Hi,

I recently found stuff about this, even if I am not sure if I got it 100% correct. So all the information I give here might be wrong; but this is what I THINK is true:

The ZynqMP seems to have an undocumented option to DRIVE values onto the Boot Mode pins[3..0].

This function is controlled via an undocumented hardware register located at 0xFF5E0250.

Now as far as I can tell at least the Ultra96-v2 board uses Boot Mode Pin 1 to trigger a reset of the ULPI PHYs connected to the ZynqMP.

So what happens is, that the direction of Boot Mode Pin 1 is set to "output" for the ZynqMP and then the pin is driven to LOW to assert a reset to the ULPI PHY.

WHY this is done via a Boot Mode Pin ? No clue; it really does not make too much sense to me.

Anyway: It seems that the FSBL will already assert this reset.

My Guess: The "PSU__USB__RESET__MODE" setting tells the FSBL if it should try to use the Boot Pin 1 as ULPI Reset or something else or nothing at all.

Again no clue why this was implemented this way.

 

Oh and BTW: The same kind of ULPI reset is hardcoded in the ATF (Arm Trusted Firmware); so be prepared to run into more resets, this time triggered by Linux (via the ATF + PMUFW).

View solution in original post

0 Kudos
Reply
1 Reply
irohloff
Visitor
Visitor
170 Views
Registered: ‎08-20-2014

Hi,

I recently found stuff about this, even if I am not sure if I got it 100% correct. So all the information I give here might be wrong; but this is what I THINK is true:

The ZynqMP seems to have an undocumented option to DRIVE values onto the Boot Mode pins[3..0].

This function is controlled via an undocumented hardware register located at 0xFF5E0250.

Now as far as I can tell at least the Ultra96-v2 board uses Boot Mode Pin 1 to trigger a reset of the ULPI PHYs connected to the ZynqMP.

So what happens is, that the direction of Boot Mode Pin 1 is set to "output" for the ZynqMP and then the pin is driven to LOW to assert a reset to the ULPI PHY.

WHY this is done via a Boot Mode Pin ? No clue; it really does not make too much sense to me.

Anyway: It seems that the FSBL will already assert this reset.

My Guess: The "PSU__USB__RESET__MODE" setting tells the FSBL if it should try to use the Boot Pin 1 as ULPI Reset or something else or nothing at all.

Again no clue why this was implemented this way.

 

Oh and BTW: The same kind of ULPI reset is hardcoded in the ATF (Arm Trusted Firmware); so be prepared to run into more resets, this time triggered by Linux (via the ATF + PMUFW).

View solution in original post

0 Kudos
Reply