[U-Boot] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.

Robert Nelson robertcnelson at gmail.com
Fri Aug 16 17:07:58 CEST 2013


On Fri, Aug 16, 2013 at 9:34 AM, Peter A. Bigot <pab at 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 at 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.
>
> I think it's dangerous to assume that the mixture of an unpatched Linux with
> a patched u-boot will never occur, and the cause of the failure that results
> is pretty subtle.  So whatever gets merged would be safer if it restored the
> default setting of CM_CLKSEL5_PLL prior to handing off control to Linux.

Agree, we should not apply this, till we also have an 'approved' patch
for mainline linux posted.  Right now we have a set of kernel hacks,
but no agreed on method as the kernel maintainer did not have a board
that suffered from the errata..

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/


More information about the U-Boot mailing list