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

[Emmanuel Vadot]

On Fri, 9 Jun 2017 15:13:05 -0400
Tom Rini <trini at konsulko.com> wrote:

> On Fri, Jun 09, 2017 at 05:55:10PM +0200, Heiko Schocher wrote:
> > Hello Tom,
> > 
> > Am 09.06.2017 um 13:20 schrieb Tom Rini:
> > >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!
> > 
> > That;s exactly the reason, why I did not started a "git bisect", as this
> > is not solved for the BBB in our lab. Wolfgang bought such a Airflash
> > card, but we did not found time to try it.
> 
> Ah, the problem with BBB is that it wants to boot from eMMC, not SD,
> unless the button is pressed.  It's possible, and I'd have to look at
> the TRM and maybe the schematic, to see about changing the order, or
> being able to remote boot it with a blank eMMC.
> 
> -- 
> Tom

 BBB can directly boot from SD if you leave the eMMC blank, that's what
I do on all my BBB.

-- 
Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>