New Contributor
New ContributorHello
I will be working with others to come up with suggestions/ideas for you.
Thank you,
New ContributorHello
First for a review of the schematic:
The reset of 0 to 1 for GPIO0 looks correct for the USB2513. The reason is that the USB-2513 needs to be run with Reset_n (1 to 0) but since there is an inverter on the pin 26 of this part, the reset follows the datasheet requirement.
The GPI09 is connected to the TC7USB40MU, which is the USB Select. It changes from 0 to 1. Since OE is ground (L) and the input S changes from L to H, it selects 2D connections (USB2513’s USBDP_UP and USBDM_UP which are the “upstream USB data signals (host, port or upstream hub).”
Now for details on the messages that you see:
For your line of socfpga_bridges_reset: FPGA not ready, aborting.
This issue tells that the HPS have issues communicating with the FPGA.
For the lines of
MMC: dwmmc0@ff704000: 0
*** Warning - bad CRC, using default environment
The warning is stating that default settings are used, because it cannot read the U-boot from the SD card correctly. The default settings are probably not what you want.
For the lines of
** Unable to read file menu.rbf **
Wrong parameters for FPGA request
This means that the FPGA is not configured correctly. This issue can caused by an SD card issue.
Question: Could you please try re-flashing another, new SD card (within the FAT partition) with a new u-boot (including .rbf file)? (I realized that you installed once more the Raetro u-boot but this is a suggestion)
For the errors of “not finding the expected .rbf file”, the .rbf file defines the operation of the I/Os, thus if is not finding the correct .rbf file, the I/Os could be incorrect.
Question: When you open your .dtsi file, can you double-check that gpio I/Os are defined correctly? Can you also check that the HPS interfaces are defined correctly?
Thank you
New ContributorHello,
I'm well aware of the reason why the rbf file is not found or the bad CRC, but that shouldn't prevent the correct initialization of the USB OTG. Take into account that Raetro's u-boot (the one that works) works under the same circumstances, so I don't think the lack or RBF or even not being able to find u-boot configuration on the SD card could be related, or could it be?
Regarding your last question about the .dtsi... In both cases they are heavily based on the socfpga_cyclone5.dtsi and socfpga.dtsi. I can see that in my non-working attempt, the gpio2 is not enabled, only gpio0 and gpio1, but I believe that should be enough for a proper USB OTG initialization.
I didn't spot anything suspicious, the GPIO0 for instance is defined like this in the socfpga.dtsi file:
gpio0: gpio@ff708000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "snps,dw-apb-gpio";
reg = <0xff708000 0x1000>;
clocks = <&l4_mp_clk>;
resets = <&rst GPIO0_RESET>;
status = "disabled";
porta: gpio-controller@0 {
compatible = "snps,dw-apb-gpio-port";
gpio-controller;
#gpio-cells = <2>;
snps,nr-gpios = <29>;
reg = <0>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <0 164 4>;
};
};
and then in the top dts file we just have:
&gpio0 {
status = "okay";
};
For the HPS, the content of the base socfpga.dtsi is used as is.
Cheers
Manuel
