Cyclone5 SoC: U-Boot not detecting USB-HUB

Hi teiram 

Good day! 

Is it possible if you could share me the repo for the 4.1.33-ltsi-altera and u-boot that you used previously?

It seems like the oldest kernel version that is available in the Altera github goes up to 4.9.76-ltsi :)

First thing we could try is comparing the changes between the latest and the old version that you are using.

Another thing could we take a look at the device tree node for the usb? If you could also share with me the deice tree that you are using for the board.

There device tree node could have change when the drivers are being updated.

Regards

tehjingy

Hello

Yes, you can go  back to the u-boot stage to see why the USB Hub is not recognized.

Since the original U-boot could recognize  the USB Hub, but not the recent version of u-boot, here are some items to check. 

Have you checked that in your device tree file (.dts/.dtsi) that the USB  Hub is defined?    As an example, do you see the command associated with &usb1.    An example of the command can be seen in the u-boot-socfpga/arch/arm/dts/socfpga_cyclone5_socdk.dts at the bottom of the page.   Is your  USB Hub set to a host/peripheral?  You will probably want the USB Hub to a host.

Have you checked in your configuration file (as seen in the configs/socfpga_cyclone5_defconfig)  that there are lines for USB such as Config_USB and then they have the item of y (yes) after them?  Do you see/not see a line of  Config_USB_Hub?    In your case, you would like it to be a Hub.

Now for the PIOs for USB Hub, here are some items to check:   Can you first check  within Quartus -> Platform Designer the  assignments and connections  are correct (no warnings)? Within Quartus, can you please check the I/O pin placement (do they correspond to the schematic) and I/O standards? These items are fast to double-check but it will narrow down other issues.

Hi 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 MMC1

U-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 environment

In: 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:

• gpio status shows nothing, as if no gpio was claimed (whatever that means).
• gpio status -a shows all ports in status unknown. porta and portb with ports from 0 to 28 and portc with ports from 0 to 26

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.

Hi teiram​ 

I can't spot any problem with the GPIO0 definition. Just giving a shot here. Could you please try with 

&usb1 {
    status = "okay";
    dr_mode = "host";
};