When using the PS minimum system built on Zedboard in Vivado (2015.4.2), the USB-OTG fails to function properly and errors in the startup log.
After a comparison with each of the original startup files, it was determined that the bit out of the Vivado project was out of the question. This means that the construction works are wrong.
USB Boot error message: External PHY chip initialization failed, loading module failed.
EHCI_HCD:USB 2.0 ' enhanced ' Host Controller (EHCI) Driver
Usbcore:registered New Interface Driver Usb-storage
Usbcore:registered New Interface Driver usbserial
Usbcore:registered New Interface Driver Usbserial_generic
USBSERIAL:USB Serial support registered for generic
Usbcore:registered New Interface Driver Ftdi_sio
USBSERIAL:USB Serial support registered for FTDI USB Serial Device
E0002000.USB supply Vbus not found, using dummy regulator
CI_HDRC ci_hdrc.0:unable to init PHY: 110
Ci_hdrc:probe of ci_hdrc.0 failed with error-110
MOUSEDEV:PS/2 mouse device common for all mice
Since the issue of fsbl,uboot, kernel mirroring has been ruled out, the rest of the view is most likely related to hardware configuration. The PHY chip, in addition to the Mio signal line, has two lines: the Reset Otg-resetn and the 5V power control line Otg-vbusoc are found in the usb-phy part of the circuit. Where OTG-VBUSOC has been normal, so only one is the OTG-RESETN signal line, in fact, not from the system.
So will the question come up here?
First, see information about GPIO in SYSFS
cat /sys/kernel/debug/906-1023, Parent:platform/e000a000.gpio, Zynq_gpio:
The display is empty, that is, there is no invocation information for any gpio, including the OTG-RESETN pin.
And look at the Integrated RTL grid table.
Nor did I find any information about OTG-RESETN, it seems that Otg-resetn did not.
The following is the official model project, open. xdc file view, do have OTG-RESETN output, corresponding G17 pin, network name is gpio_bd[31]
Set_property -dict {package_pin H15 iostandard LVCMOS25} [get_ports gpio_bd[]] ; # # xadc- Gio0set_property -dict {package_pin R15 iostandard LVCMOS25} [get_ports gpio_bd[]] ; # # xadc-gio1set_ Property -dict {package_pin K15 iostandard LVCMOS25} [get_ports gpio_bd[]] ; # #xadc- gio2set_property-dict {package_pin J15 iostandard LVCMOS25} [Get_ports gpio_bd[ []] ; # #xadc-GIO3 set_property-dict {package_pin G17 iostandard LVCMOS25} [ Get_ports gpio_bd[31]] ; # # OTG-RESETN
Look back at GPIO_BD and find the relevant information in the top-level instance file
Then find the module associated with GPIO_BD, which is instantiated in the Ad_iobuf module.
ad_iobuf # ( . Data_width(+) i_iobuf ( . dio_t (gpio_t[:0)), . Dio_ I (gpio_o[:0]), . Dio_o (gpio_i[:0]), . Dio_p (GPIO_BD));
So what does this ad_iobuf do?
Modulead_iobuf (dio_t, Dio_i, Dio_o, dio_p); parameterData_width =1; //Parameters configurable, with a total of data_width instances input[(data_width-1):0] dio_t; input[(data_width-1):0] dio_i; Output[(data_width-1):0] dio_o; inout[(data_width-1):0] dio_p; GenvarN; Generate for(n =0; n < data_width; n = n +1)begin: G_iobufAssignDio_o[n] =Dio_p[n]; AssignDio_p[n] = (dio_t[n] = =1'B1)? 1'Bz:dio_i[n]; End endgenerateEndmodule
This is a module that is written by Adi itself and is actually a generic Gpio feature that is combined into a standard bidirectional programmable Gpio by Emio the original input (dio_i), Output (dio_o), and high impedance (dio_t). and consists of 32 gpio_bd pins in the top-level instance. (Note ad_iobuf
Multiple instances in the
In fact it corresponds to the 31st bit of Emio.
In combination with the description in the previous XDC file we can tell that the OTG-RESETN pin is gpio_bd[31].
After adding Emio to the project you have set up, and assigning the pin and network to the OTG-RESETN.
Set_property -dict {package_pin G17 iostandard LVCMOS25} [get_ports gpio_bd[]] ; # # Otg-resetn
Regenerate bit stream file, and Boot.bin, everything is OK after startup.
Probe into the problem of Zynq-zedboard USB host