New Contributor
New ContributorHello Erika,
thanks for your ideas and hints. Let me go over the topics you pointed out:
1. DTS/DTSI files:
yes, in fact that part of the dts is shared with the base cyclone5 dts. The only overrides/configuration the chameleon96 specific dts does regarding USB is:
&usb1 {
status = "okay";
};
The chameleon96 dts does include socfpga_cyclone5.dtsi which in fact includes socfpga.dtsi, where the main usb stuff is declared. In the working repository I shared I didn't find any difference regarding this topic.
2. U-Boot USB configuration:
this is where I was doing more tests, thinking that maybe I was missing some USB configuration there. As I see it, the chameleon96 has two USB Hubs:
I think this is properly detected, or at least so it looks like because U-Boot 'usb tree' command shows an USB Hub and also the linux kernel shows such device. But it might be it's detected but it's not enabled, idk.
this one has its reset pin controlled by GPIO0.
Somehow this combination is not working, either because one of these devices is hold on reset or for some other reason. I understand u-boot is configured with USB support and USB2513B i2c interface is not reachable, so it's expected to have a fixed configuration defined by its polarization.
I was doing lots of tests with the USB configuration, and I'm not sure if it's fine. But the USB configuration for u-boot changed significantly from the working version to the current version, letting aside that I'm no expert on this. So it might well be an issue with that.
Also what really beats me on this setup is that the USB3300 reset is connected to the USB2513B reset and they have reverse logic. I guess maybe because at least one of them senses the edge and not the level, but I'm not sure. Anyways, since there are working implementations of u-boot and linux kernel, that shouldn't be an issue. :)
3. The design including the platform designer setup looks good to me and I found no warnings related to the GPIO configuration whatsoever. I made the design available here
regards,
Manuel
New ContributorHello Manuel,
For your comment of “I think this is properly detected, or at least so it looks like because U-Boot 'usb tree' command shows an USB Hub and also the linux kernel shows such device. But it might be it's detected but it's not enabled, idk.”
Since you can run the usb tree command and the Linux kernel shows this device, yes, it looks like this device is detected and enabled. The usb tree command is a check that the USB is detected.
For your issue with the U-boot USB Configuration, where the issue seems to be more with the Child USB USB2513B because this Hub is not getting detected, here are some comments.
First, it was checked if there is a way to bypass the USB3300 and test the USB2513 directly but no, this is not possible. Now, since the USB2513 is not being detected, did you try toggling GPI0? For example, did you try to toggle the GPIO in the u-boot prompt, where the command is gpio <command> before using the command usb start? You could try commands such as gpio clear <GPIO> (for the USB2513B) and then gpio set GPIO for the USB2513B and then do similar steps for USB3300 to initialize the parts. You should put in some delay time between each command due to initialization time. The reason for toggling the GPIOs is that there are changes in u-boot, as you have seen. The older versions handled more of the initialization, while in the new version you will need to do more initialization i.e. toggle the I/O.
Out of curiosity, did Novtech provide you, for reference, an older u-boot version where you can see the Hub?
Are you able to check in your board.c file that it initializes the board_late_init with the correct initialization of GPIO?
As per your comment of Also what really beats me on this setup is that the USB3300 reset is connected to the USB2513B reset and they have reverse logic.
Comment: The USB3300 has a reset (active high) while the USB2513B has Reset_n (active low). Now for your question of how can an active high reset be connected to a reset? As such, can you please note there is an inverter (which is indicated with a very small round circle) to the right of the word “26” (Reset_n pin) on the USB2513B of the schematic? This circle can be easily missed as it is so small. No other pins on the USB2513B are shown this way with the inverter. One thing to do to check the resets of the USB2513B and USB3300. For example, in the USB2513B, there is a reset sequence that halts features (with the assertion of reset_n) vs features that are operational after the negation of reset_n. The USB2513B Hub only works after a certain period of time after the negation of the reset_n. When using the reset on USB3300, on the other hand, it is writing to a register. This register will clear after the completion of the reset. The reason for the 2 different resets-active high and active low for the two different USB devices is for synchronization during power up.
Do the above details help?
New ContributorHi Erika,
thanks for your comments.
Yes, I have some working u-boot with source code that is able to properly detect the USB Hub. In fact I tried to follow the same approach as this version, which can be found here: https://github.com/raetro/raetro_system_u-boot.git
They use u-boot commands to do the gpio toggling and that seems to be enough to enable the USB Hub. There are other stuff but seems somehow unrelated to me, even though I also tried to replicate it in my board late_init function.
They define a u-boot variable named usb_reset with the following content:
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:
bootcmd=run usb_reset; mw 0xff709004 0x800; run mmcload; run mmcboot
Now, if I run
gpio clear 9
gpio clear 0
a new run of usb reset will only find the OTG USB but not the HUB.
If I enable again those gpios doing:
gpio set 0
gpio set 9
usb reset finds now both USB Hubs with no further changes:
=> gpio clear 0
gpio: pin 0 (gpio 0) value is 0
=> gpio clear 9
gpio: pin 9 (gpio 9) value is 0
=> usb reset
resetting USB...
USB0: Core Release: 2.93a
scanning bus 0 for devices... 1 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=> gpio set 0
gpio: pin 0 (gpio 0) value is 1
=> gpio set 9
gpio: pin 9 (gpio 9) value is 1}
=> usb reset
resetting 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)
If I try to manually issue those commands under my u-boot version, the USB-Hub doesn't get enabled, or at least I cannot see it after a usb reset command.
=> gpio set 0
gpio: pin 0 (gpio 0) value is 1
=> gpio set 9
gpio: pin 9 (gpio 9) value is 1
=> usb reset
resetting USB...
USB DWC2
Bus usb@ffb40000: 1 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
The output of the gpio status command is a bit different but that might be because of different u-boot versions. For my version it looks like this:
=> gpio status -a
Bank porta:
porta0: output: 1 [ ]
porta1: input: 0 [ ]
porta2: input: 0 [ ]
porta3: input: 0 [ ]
porta4: input: 0 [ ]
porta5: input: 0 [ ]
porta6: input: 0 [ ]
porta7: input: 0 [ ]
porta8: input: 0 [ ]
porta9: output: 1 [ ]
porta10: input: 0 [ ]
porta11: input: 1 [ ]
porta12: input: 0 [ ]
porta13: input: 0 [ ]
porta14: input: 0 [ ]
porta15: input: 1 [ ]
porta16: input: 1 [ ]
porta17: input: 1 [ ]
porta18: input: 1 [ ]
porta19: input: 1 [ ]
porta20: input: 1 [ ]
...
but under Raetro's u-boot version, it shows no info about the gpio current values:
=> gpio status -a
Bank porta:
porta0: unknown
porta1: unknown
porta2: unknown
porta3: unknown
porta4: unknown
porta5: unknown
porta6: unknown
porta7: unknown
porta8: unknown
porta9: unknown
porta10: unknown
porta11: unknown
porta12: unknown
porta13: unknown
porta14: unknown
porta15: unknown
porta16: unknown
porta17: unknown
porta18: unknown
porta19: unknown
porta20: unknown
...
That is why I think that maybe there is some configuration missing in my u-boot, but I'm not able to figure out what can it be. Is there any way to validate that the GPIO configuration is okey? It looks like it is according to the gpio status output, but... why the working u-boot is not able to provide the output values?
In any case, what else could be preventing the USB Hub to get enabled?
