Hi,
On 08/20/2013 11:50 AM, Andreas Naumann wrote:
Hi,
Am 16.08.2013 17:30, schrieb Robert Nelson:
On Fri, Aug 16, 2013 at 10:07 AM, Robert Nelson robertcnelson@gmail.com wrote:
On Fri, Aug 16, 2013 at 9:34 AM, Peter A. Bigot pab@pabigot.com wrote:
On 08/16/2013 08:38 AM, Tom Rini wrote:
On Wed, Aug 14, 2013 at 09:53:16PM -0500, Peter A. Bigot wrote:
On 07/09/2013 02:43 AM, Naumann Andreas wrote: > > In chapter 'Advisory 2.1 USB Host Clock Drift Causes USB Spec > Non-compliance in Certain Configurations' of the TI Errata it is recommended > to use certain div/mult values for the DPLL5 clock setup. > So far u-boot used the old 34xx values, so I added the errata > recommended values specificly for 36xx init only. > Also, the FSEL registers exist no longer, so removed them from init. > > Tested this on a AM3703 board with 19.2MHz oscillator, which previously > couldnt lock the dpll5 (kernel complained). As a consequence the EHCI USB > port wasnt usable in U-Boot and kernel. With this patch, kernel panics > disappear and USB working fine in u-boot and kernel. > > Signed-off-by: Andreas Naumann anaumann@ultratronik.de
While this patch works with Linux that has been patched for this erratum, it will cause problems with some unpatched versions of Linux.
Right. So Linux also needs to be patched for the erratum.
Yes. My point was that if you update u-boot alone, then try to use it to boot an unpatched Linux that assumes CM_CLKSEL5_PLL has its power-on value, USB will not work.
Oh, I was not aware of that. But indeed i use a patched 3.1 kernel, see below. Some info on the history: In our design (19.2MHz crystal) we could clearly see the errata problem of high jitter on the 60MHz USB clock when (re-)booting a board that was already warmed up. Back then I applied a slightly extended kernel patch (see below) that I found on some kernel list. This reproducably did solve the problem with the jitter. We verified this with a high quality oscilloscope and numerous powercycles at different temperatures. The U-Boot in use was 2010.09 and some old X-Loader, both of which dont touch the PLL4/5 stuff.
Introducing the current U-Boot (to make use of SPL) brought up above described problems with the clock, probably due to setting the lock mode active. Hence this patch for DM37xx.
What are the symptoms you see when this issue triggers?
What is the test case to trigger the error? Is it just running any USB I/O for long enough time?
I have a beagle-xm (DM3730 ES1.2) with me and would like to reproduce the error.
cheers, -roger