[U-Boot] [U-Boot, v2, 4/4] arm: am33xx: Add support for mulitiple PLL input frequencies

Tom Rini trini at konsulko.com
Fri Jun 9 11:20:46 UTC 2017


On Fri, Jun 09, 2017 at 12:22:44PM +0200, Heiko Schocher wrote:
> Hello Lokesh,
> 
> Am 09.06.2017 um 11:25 schrieb Lokesh Vutla:
> >
> >
> >On Friday 09 June 2017 09:30 AM, Heiko Schocher wrote:
> >>Hello Tom,
> >>
> >>Am 09.06.2017 um 02:45 schrieb Tom Rini:
> >>>On Thu, Jun 08, 2017 at 10:17:09AM +0530, Lokesh Vutla wrote:
> >>>>
> >>>>
> >>>>On Thursday 08 June 2017 12:20 AM, Emmanuel Vadot wrote:
> >>>>>On Fri, 12 May 2017 13:20:50 -0400
> >>>>>Tom Rini <trini at konsulko.com> wrote:
> >>>>>
> >>>>>>On Fri, May 05, 2017 at 12:59:10PM +0530, Lokesh Vutla wrote:
> >>>>>>
> >>>>>>>am335x supports various sysclk frequencies which can be determined
> >>>>>>>using sysboot pins. PLLs should be configures based on this
> >>>>>>>sysclk frequency. Add PLL configurations for all supported
> >>>>>>>frequencies.
> >>>>>>>
> >>>>>>>Signed-off-by: Lokesh Vutla <lokeshvutla at ti.com>
> >>>>>>>Reviewed-by: Tom Rini <trini at konsulko.com>
> >>>>>>
> >>>>>>Applied to u-boot/master, thanks!
> >>>>>>
> >>>>>>--
> >>>>>>Tom
> >>>>>
> >>>>>   Hello,
> >>>>>
> >>>>>   This appears to break beaglebone black support, reverting this commit
> >>>>>make u-boot works again.
> >>>>
> >>>>hmm..I see the problem. Here we are hard coding MPU freq to 1GHz even
> >>>>efuse say it is not supported(I am not sure why this is being done, may
> >>>>be Tom can give more details). Even in kernel I see that cpufreq is
> >>>>reading efuse to determine mpu frequency. Now that we have jitter
> >>>>optimized pll configurations, looks like unsupported freq is causing an
> >>>>issue. Can you see if the below patch helps?
> >>>
> >>>Well, in the kernel, did anyone poke the Beagleboard folks about this,
> >>>before pushing the change?  There's BBB shipping with chips that did not
> >>>have their efuses set, hence the way things were structured in U-Boot.
> >>
> >>I have runnint tbot tests on a BBB [1] ... and yes, currently test
> >>is red = bad ... :-(
> >>
> >>Not sure, if it is this patch ...
> >
> >Yeah, I don't think this is the patch causing the issue. AM335x-evm
> >boots fine for me. There are similar boot failures reported[1] on NVIDIA
> >platforms as well. Not sure if we are hitting the same issue. Ill did
> >more into this and update you guys.
> >
> >[1] https://www.mail-archive.com/u-boot@lists.denx.de/msg252698.html
> 
> Time for using tbot and automated git bisect testcase ;-)

How do you have the BBB configured such that you can recover it from a
bad U-Boot, automatically?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170609/6166d145/attachment.sig>


More information about the U-Boot mailing list