Hi there,
I did some digging in the data sheets. In my opinion the problem could be the initialization of the MIO pins for the ULPI.
After reset the MIO-pins for ULPI are configured input with pullup (3.3v).
In 15.16.1 of the Zynq TRM the order of initialization is mentioned, the STP pin is configured last. In the FSBL the STP pin is configured after ULPIDATA(4) and DIR and before of the rest of the pins - I took this information by making an FSBL-from scratch, based on the ps7_system_prj.xml-file. If someone could provide the actual FSBL source (ps7_init.c) I could check again.
The other pins will be configured right after this, but I guess the CPU is not running at full speed, because ARM-PLL and IO-PLL are configured after that. The USB-Controller IPCore (which signals the STP) is not held in reset by default, so I guess the STP could be 0 after configuring the MIO-pin for it. In this case we are signalling the PHY "ok to go" while we are still configuring the rest of the pins, and then configuring (and waiting for lock) the PLL for the core and io.
All while the USB core is not held in reset. My guessing is, that this could be very confusing for the PHY...
Possible solutions (IMHO):
The correct order should be:
USB-IPCore th reset
Confgure MIO-Pins - STP should be last - (to check STP is signalled 1, if USB-IPCore is in reset)
deassert reset after all PLL setting are done
This could be done in two ways:
1. edit FSBL (by hand), to the correct order of initialization
2. deactivate USB from Plattform Studio-project and generate FSBL, so MIO-Pins are not touched by FSBL. The do init in uboot.
sorry for only sharing the info without really doing it, I will try to do it, if I find time,
meanwhile, if someone else finds the time.....
BR
Joerg
