New Contributor
New ContributorHi Erika,
thanks for your comments. In fact I have a working u-boot as I mentioned earlier in the conversation, coming from Raetro github repository. In this case, the USB HUB seems to get activated as you mentioned, by toggling the relevant GPIOs. I tried to emulate the same behavior from the u-boot prompt but I'm not able to see anything detected at all afterwards by ussing an usb start command.
I installed again Raetro u-boot on the SD card and I can see the following messages during boot:
U-Boot SPL 2017.03-gd209b72 (Dec 14 2025 - 08:23:38)
Trying to boot from MMC1U-Boot 2017.03-gd209b72 (Dec 14 2025 - 08:23:38 +0100)
Watchdog enabled
I2C: ready
DRAM: 512 MiB
socfpga_bridges_reset: FPGA not ready, aborting.
MMC: dwmmc0@ff704000: 0
*** Warning - bad CRC, using default environmentIn: serial
Out: serial
Err: serial
Model: Arrow Chameleon96
Net: No ethernet found.
Autoboot in 2 seconds
Resetting USB HUB...
gpio: pin 09 (gpio 9) value is 0
gpio: pin 0 (gpio 0) value is 0
gpio: pin 22 (gpio 22) value is 1
gpio: pin 09 (gpio 9) value is 1
gpio: pin 0 (gpio 0) value is 1
gpio: pin 25 (gpio 25) value is 1
Programming FPGA...
reading menu.rbf
** Unable to read file menu.rbf **
Wrong parameters for FPGA request
...
then some errors about not finding the expected rbf file follow, but the important thing is, in my opinion, the GPIO toggling on GPIO0 and GPIO9.
Once on the u-boot prompt, a usb start shows the two USB hubs:
=> version
U-Boot 2017.03-gd209b72 (Dec 14 2025 - 08:23:38 +0100)
arm-none-eabi-gcc (15:13.2.rel1-2) 13.2.1 20231009
GNU ld (2.42-1ubuntu1+23) 2.42
=> usb start
starting USB...
USB0: Core Release: 2.93a
scanning bus 0 for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
=> usb tree
USB device tree:
1 Hub (480 Mb/s, 0mA)
| U-Boot Root Hub
|
+-2 Hub (480 Mb/s, 2mA)
Also from the prompt:
The gpio setting attempt can be seen in the u-boot variables:
usb_reset=echo Resetting USB HUB...;gpio clear 09;gpio clear 0;sleep 1;gpio set 22;gpio set 09;gpio set 0;gpio set 25
which is used in bootcmd, here is the content of bootcmd as well as most of the other involved variables:
bootcmd=run usb_reset; mw 0xff709004 0x800; run mmcload; run mmcboot
mmcload=mmc rescan;run fpgacheck;run scrtest;run kernel_init
fpgacheck=if mt 0xFFD05054 0;then run fpgaload;else if mt 0x1FFFF000 0x87654321;then mw 0x1FFFF000 0;env import -t 0x1FFFF004;run fpgaload;fi;fi
fpgaload=echo Programming FPGA...;load mmc 0:$mmc_boot $fpgadata $core;fpga load 0 $fpgadata $filesize;echo Enabling FPGA to HPS bridges...;bridge enable;mw 0x1FFFF000 0; mw 0xFFD05054 0
scrtest=if test -e mmc 0:$mmc_boot /linux/u-boot.txt;then load mmc 0:$mmc_boot $loadaddr /linux/u-boot.txt;env import -t $loadaddr;fi
kernel_init=echo Loading Kernel and Device Tree...;load mmc 0:$mmc_boot $loadaddr $bootimage;setexpr.l fdt_addr $loadaddr + 0x2C;setexpr.l fdt_addr *$fdt_addr + $loadaddr
After the usb_reset, 0x800 is written to 0xff709004, what seems to be the data direction register of the gpio1 portb, setting to one bit 11, which I would think it should corresponds to GPIO40. GPIO40 doesn't even show in the device PIN configuration of the HPS so there is something I'm not getting here. I don't know why that bit is set to 1 during initialization.
I will try to setup again the non-working u-boot to see if I can spot any relevant differences. It beats me that gpio status show no claimed GPIO with this working u-boot, or why I'm not able to see any value at all. but that might be that I don't really understand how it works, or because they are configured as outputs and that is why I cannot see any value.
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
