Parallella Community

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

Hi Joerg,
Thank you so much for digging into this!! We are in the middle of generating and verifying a new FSBL through Vivado. Once that is done we will verify your proposed workaround.
Andreas

Hi Andreas,
is there a ps7_init.c-file within this FSBL? It usually comes with the BSP.
If you could provide it, I couls\d check, how USB init is handled...
BR
Joerg

Hi, on my board is the same problem with USB PHY.

My workaround: On my board U17 was not installed. U17 pad has BOARD_RESET_L pin 27, and pin 29 - P1_USB_STP. I short this pins, setup MIO42 as GPIO and reset line BOARD_RESET_L in bootloader.

That is an awesome hack!!

Andreas,
in my experience c and tcl are the same. This tcl shows the same behaviour 0xf8000770++ and 0f80007a4++ are just configured in ascending order(the MIO pins for the2 USBs). And in the main routine, the MIO are configured first, and then PLLs are configured. So the behavour should be the same.
Maybe I finde the time to try this in the next days,
BR
Joerg

Will a new image be released with instructions on a hardware mod?

Thanks
Sean

Has there been any progress on this - I've been stopped in my tracks with this bug.

Steve