USB workaround

Hardware related problems and workarounds

Re: USB workaround

Postby arhplanet » Mon Feb 23, 2015 8:12 pm

Hi everyone and thanks for a awesome little bord. I finally got the right ubuntu image installed and the usb works. Im however using the long cable trick. And I have spent countless hours in this forum to find a solution, and the one I found is to use the long cable.

But what i missed is why this happens? can anyone take the time to explain this properly in layman terms.

Cheers

Arne
arhplanet
 
Posts: 1
Joined: Mon Jan 05, 2015 8:30 pm

Re: USB workaround

Postby Frida » Thu Jul 16, 2015 8:30 am

Congratulations, it's now a year since I found this error.
Is there really no one, with the right software that can fix this error?
I wish there was free software, so I could fix this myself!

Happy 1 year.
User avatar
Frida
 
Posts: 22
Joined: Wed Sep 04, 2013 2:37 pm
Location: Middelfart, Denmark

Re: USB workaround

Postby ajtravis » Thu Jul 16, 2015 9:08 am

Frida wrote:Congratulations, it's now a year since I found this error.
Is there really no one, with the right software that can fix this error?
I wish there was free software, so I could fix this myself!

Happy 1 year.


Hi, Frida.

I share your frustration about the USB problems with Parallella, but I don't know anything about the FSBL or how to investigate this problem at the FPGA level. As I've mentioned several times before on this forum, I think that USB connectivity is the Achilles heel of Parallella as a 'desktop' computer intended to compete with the likes of the R-Pi for computer literacy projects. I've also acknowledged the efforts Adapteva have made to investigate the USB problem. We are in an odd situation, where Adapteva have found it difficult to reproduce the USB faults in testing that many of us see in practice. I hoped that the USB problem would, at least, have been diagnosed by now. Instead, we have a resounding silence about the issue from Adapteva and the Parallella community at large. I can only conclude that Adapteva do NOT see the 'desktop' version of Parallella as a commercially viable product and are cutting their losses. Personally, I believe the 'desktop' version of Parallella is a fantastic alternative to the R-Pi EXCEPT for it's unreliable USB initialisation problem!

Bye,

Tony.
Minke Informatics Limited, Registered in Scotland - Company No. SC419028
User avatar
ajtravis
 
Posts: 162
Joined: Fri Jul 18, 2014 12:54 pm
Location: Scotland (UK)

Re: USB workaround

Postby tnt » Thu Jul 16, 2015 9:27 am

I'm still wondering why you even think the fix would be software ...

AFAICT everything points to a hardware issue. The design isn't at fault, it _should_ work according to the datasheet of the zynq and the ulpi phy. But sometimes it doesn't ... which could be due to either the ZYNQ or to the PHY not behaving. The workaround in this thread is to hold the phy reset line longer, but no amount of software can accomplish that because that line is just not controllable by software !

And speaking of USB issue, I'd like to point out the RPi has plenty of those too ! I use one has a console server to access USB serial console and it fails half the time (and yeah, it's using a powered hub, and an industrial 5V power supply so not a power issue). Even just doing a while true; do lsusb; done will inevitably end up in a crash.
tnt
 
Posts: 408
Joined: Mon Dec 17, 2012 3:21 am

Re: USB workaround

Postby tnt » Thu Jul 16, 2015 9:38 am

Frida wrote:I wish there was free software, so I could fix this myself!


Free software to do what ?

The FPGA bitstream has no implication in this bug. (all usb lines are linked to MIO / PS pins and nothing PL).

The current generated FSBL code is GPL and it's in the project in the git.

If you don't want to use the vivado gui to generate a new one, you don't have too, you can just modify the existing FSBL sources (all the relevant registers are documented in the TRM) and use any ARM toolchain to build a new FSBL and use u-boot to flash it at the right place.

It's much less practical, and more risky because you could more easily screw something up, but it's definitely possible if you wanted to ...
tnt
 
Posts: 408
Joined: Mon Dec 17, 2012 3:21 am

Re: USB workaround

Postby ajtravis » Thu Jul 16, 2015 10:05 am

tnt wrote:I'm still wondering why you even think the fix would be software ...

AFAICT everything points to a hardware issue. The design isn't at fault, it _should_ work according to the datasheet of the zynq and the ulpi phy. But sometimes it doesn't ... which could be due to either the ZYNQ or to the PHY not behaving. The workaround in this thread is to hold the phy reset line longer, but no amount of software can accomplish that because that line is just not controllable by software !


Hi, tnt.

I don't think it's a 'software' issue exactly, I think it's a firmware issue (OK, firmware is software, but you see what I mean). From what Fred and Andreas have said before, I thought that the FSBL was responsible for initialising the USB PHY, but that the FSBL source is not available and you need the proprietary Vivado software to build a new FSBL anyway as well as a JTAG connector. There was also some discussion about using one of the GPIO pins to reset the USB PHY under software control at run-time (maybe just to diagnose any underlying hardware issues).

And speaking of USB issue, I'd like to point out the RPi has plenty of those too ! I use one has a console server to access USB serial console and it fails half the time (and yeah, it's using a powered hub, and an industrial 5V power supply so not a power issue). Even just doing a while true; do lsusb; done will inevitably end up in a crash.


Hmm... That's really bad news, of course, but my colleagues who use R-Pi's to teach bioinformatics have found them quite reliable in practice. My idea was to replace the R-Pi's with Parallella 'desktop' boards and open up their course to teaching about the use of MIMD parallel computing for bioinformatics.

Any idea if the Parallella 'desktop' and R-Pi USB problems have anything in common?

Bye,

Tony.
Minke Informatics Limited, Registered in Scotland - Company No. SC419028
User avatar
ajtravis
 
Posts: 162
Joined: Fri Jul 18, 2014 12:54 pm
Location: Scotland (UK)

Re: USB workaround

Postby tnt » Thu Jul 16, 2015 5:00 pm

ajtravis wrote:I don't think it's a 'software' issue exactly, I think it's a firmware issue (OK, firmware is software, but you see what I mean). From what Fred and Andreas have said before, I thought that the FSBL was responsible for initialising the USB PHY, but that the FSBL source is not available and you need the proprietary Vivado software to build a new FSBL anyway as well as a JTAG connector. There was also some discussion about using one of the GPIO pins to reset the USB PHY under software control at run-time (maybe just to diagnose any underlying hardware issues).


Firmware is Software ... my point is that I think any solution / workaround will need HARDWARE physical modifications.

The FSBL doesn't initialize the PHY. All the FSBL does is to configure which MIO pins are assigned to the USB interface.
The FSBL is just a few automatically generated .{c,h} files. They are generated by Vivado, but although proprietary, it's also free to download ... It used to be that the generated files were not re-distribuable, but it's not the case anymore. The generated files are now available as GPL if you want to hand-tweak them after generation or include them in other projects.

There was some discussions that the initialization order of the pins might make a difference. (since each pin is configured independently, some of the FPGA pins connected to the ULPI phy are initialized/switched to USB mode before some others). Currently it's just the default order generated by Vivado (and you can't change it in vivado). Someone that has the issue can try to change that order by tweaking the FSBL source code and rebuild and reflash. (and you can reflash from u-boot in theory ... but if it fails you bricked your board if you don't have JTAG).

Resetting the PHY at run-time is the workaround discussed here. But in the current board, that's not possible, you need to actually _solder_ a wire between that reset line and that GPIO (re-using the LED here because it's the only one easily available).


ajtravis wrote:Hmm... That's really bad news, of course, but my colleagues who use R-Pi's to teach bioinformatics have found them quite reliable in practice. My idea was to replace the R-Pi's with Parallella 'desktop' boards and open up their course to teaching about the use of MIMD parallel computing for bioinformatics.

Any idea if the Parallella 'desktop' and R-Pi USB problems have anything in common?


No nothing in common.

The RPi issue are not even that "binary". It works most of the time but it will loose USB packets which depending on the device can have more or less impact ... For a keyboard and mouse, you're unlikely to even notice. And the mechanism of failure is also pretty well understood from what I know, it's just that the USB controller needs real-time guarantee when driving it which is something linux can't offer (not being a RT OS).
tnt
 
Posts: 408
Joined: Mon Dec 17, 2012 3:21 am

Re: USB workaround

Postby ajtravis » Sun Jul 26, 2015 3:52 pm

tnt wrote:
ajtravis wrote:[...]
Any idea if the Parallella 'desktop' and R-Pi USB problems have anything in common?


No nothing in common.

The RPi issue are not even that "binary". It works most of the time but it will loose USB packets which depending on the device can have more or less impact ... For a keyboard and mouse, you're unlikely to even notice. And the mechanism of failure is also pretty well understood from what I know, it's just that the USB controller needs real-time guarantee when driving it which is something linux can't offer (not being a RT OS).


Hi, tnt.

I had a look at USB problems on the RPi and discovered lots of discussion about problems caused by 'backfeeding' power to the RPi through the upstream USB port. The Genesys Logic, Inc. based USB-hub that I'm using (Belkin USB 2.0 7-Port Mobile Powered HUB F4U018-BLK) 'backfeeds' power to the Parallella micro USB OTG port and is on the RPi 'Problem USB Hubs' list: http://elinux.org/RPi_Powered_USB_Hubs. I wonder if this might have an impact on the reliability of the Parallella USB PHY initialisation at reset, and power up, so I've started doing some experiments by cutting the +5v (red) wire on the USB upstream cable to stop 'backfeeding' power to the Parallella via the micro-USB 'B' OTG connector:

image20150726_163935326.jpg
image20150726_163935326.jpg (530.09 KiB) Viewed 18468 times

I've not reached any conclusions yet...

Bye,

Tony.
Minke Informatics Limited, Registered in Scotland - Company No. SC419028
User avatar
ajtravis
 
Posts: 162
Joined: Fri Jul 18, 2014 12:54 pm
Location: Scotland (UK)

Re: USB workaround

Postby ajtravis » Sat Aug 29, 2015 8:54 pm

ajtravis wrote:
tnt wrote:
ajtravis wrote:[...]
So, I'm not out of the woods with Parallella USB after all and I've just broken the microUSB connector off one of my boards this evening :-(


Hi,

Just in case anyone is interested my demo at the techMeetup https://www.facebook.com/pages/Aberdeen-TechMeetup/220140384757836 went OK after I, eventually, I got the Parallella USB to work: Iain, on the left, introducing my talk):
talk.jpg
talk.jpg (60.91 KiB) Viewed 18312 times

Lots of interest in my Parallella cluster at the meeting:
cluster.jpg
cluster.jpg (65.62 KiB) Viewed 18312 times


Bye,

Tony.
Minke Informatics Limited, Registered in Scotland - Company No. SC419028
User avatar
ajtravis
 
Posts: 162
Joined: Fri Jul 18, 2014 12:54 pm
Location: Scotland (UK)

Re: USB workaround

Postby Frida » Sun Jul 17, 2016 9:52 am

Congratulations 2 year and 1 day, and still no solution in sight.
User avatar
Frida
 
Posts: 22
Joined: Wed Sep 04, 2013 2:37 pm
Location: Middelfart, Denmark

PreviousNext

Return to Troubleshooting

Who is online

Users browsing this forum: No registered users and 4 guests