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?
