USB workaround

[Sean S]

Yes please! The board is destined for the bin after all of the frustration. If it gets bricked it will be the end of my frustration

[Sean S]

Hi

Can anyone advise if this is the latest image for the FSBL in the QSPI flash:

https://github.com/parallella/parallell ... 1/firmware

Is it compatible with all boards?

Thanks in advance.
Sean

[FHuettig]

[ESI]

Hello,
what I understand the problem can be solved via a defined reset after the ULPI-related pins are configured.
(USB-Pins are all MIO-Pins, none are connect through FPGA(EMIO), if I read the schematics correctly. So they are configured in FSBL and never touched afterwards, configuring FPGA should not have anything to do with it)
Using the LED-pin is only one (clever!!) solution.
What does Linux do, if I assert a reset to the Ethernet phy and the USB phy during a running system, right?
In my understaning neither of these phys need initialization. I that case any MIO or FPGA-Pin could assert a reset, if connected to BOARD_RESET_L, right?
Is there any unused pin on any pad availlable for this work? Or is the LED pin the best to go with?
br
Joerg

[ajtravis]

[greytery]

Hi Tony,

Many possible reasons and workrounds are discussed in the threads, and the Parallella does seem to be sensitive and sulky at power up, but I initially suspect the PSU. The USB peripherals can put different loads on the boards during power up - and perhaps the combined pull may be erratic/unstable.

Can't remember exactly, but didn't you point at that snazzy 4-port USB PSU charger from Maplin?
Were you using that?
What peripherals were connected to each board?
Can you try with just one connected.. two , etc...?

I count myself extrememly lucky that I've never had USB, HDMI or network issues on my 7010 boards; I speak from a rather smug position.

Cheers,

[ajtravis]

[Frida]

@Tony
To see, if you have the same problems as I, then try an startup, and when it has done that, hit the reset-button shortly, and let it startup again. Now it should be possible to login.

I am now working on a delay circuit, to see how long time I can delay it after reset.

[FHuettig]

[greytery]

@ Tony: Thanks for answers (- and I did like the charger, BTW).

Frida's point about a delay circuit triggers another thought...
The random success/failure may be a race condition (cf PC BIOS delay setting for HDD initialisation).

Looking at the uBoot environment variables - as part of the topic: . There is a variable : bootdelay=0.

What is the effect of changing this value to, say, 5 (seconds)? Or more?
Would this give things time to 'settle down' before kernel boots to look for USB, HDMI, etc?

I can't test this - because I don't have the problems
It's sort of firmware .. but it's safer than reflashing!!!!

Cheers,