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

[Tom Rini]

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
-------------- 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/e693aa54/attachment.sig>