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

[Heiko Schocher <hs@denx.de>]

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@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@ti.com>
>>>>> Reviewed-by: Tom Rini <trini@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 ...

Last working U-Boot test, see [2]

Sorry, did not looked earlier at it ... I really need to find time
again for my testsetup as at91 based boards also not running currently :-(

Ok, my BBB in the lab is running, also with current U-Boot, but I see

U-Boot 2017.07-rc1-00075-g156d64f (Jun 09 2017 - 05:48:18 +0200)

CPU  : AM335X-GP rev 2.1
Model: TI AM335x BeagleBone Black
DRAM:  512 MiB
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1

** Unable to use mmc 0:1 for loading the env **
Using default environment

ERROR: No USB device found

at drivers/usb/gadget/ether.c:2709/usb_ether_init()
<ethaddr> not set. Validating first E-fuse MAC
Net:   CACHE: Misaligned operation at range [9df31580, 9df31624]
eth0: ethernet at 4a100000

And my tbot tests breaking when using ethernet! For example:

=> print tbot_cmp_uboot
tbot_cmp_uboot=run cmp_uboot
=> print cmp_uboot
cmp_uboot=tftp ${cmp_addr_r} ${ubfile};cmp.b ${load_addr_r} ${cmp_addr_r} ${filesize}
=>
=> run tbot_upd_uboot
link up on port 0, speed 100, full duplex
Using ethernet at 4a100000 device
TFTP from server 192.168.1.1; our IP address is 192.168.20.95
Filename 'bbb/tbot/u-boot.img'.
Load address: 0x81000000
Loading: #############################################
          3.2 MiB/s
done
Bytes transferred = 654708 (9fd74 hex)
writing u-boot.img
654708 bytes written
=> run tbot_cmp_uboot
link up on port 0, speed 100, full duplex
Using ethernet at 4a100000 device
TFTP from server 192.168.1.1; our IP address is 192.168.20.95
Filename 'bbb/tbot/u-boot.img'.
Load address: 0x82000000
Loading: #############################################
          3.2 MiB/s
done
Bytes transferred = 654708 (9fd74 hex)
byte at 0x81000618 (0x33) != byte at 0x82000618 (0x74)
Total of 1560 byte(s) were the same
=>

So simply load file 'bbb/tbot/u-boot.img' twice with tftp
and compare fails ... but the image boots ...

bye,
Heiko

[1] http://xeidos.ddns.net/buildbot/tgrid
     bbb U-Boot Test = "bbb_ub"

[2] last working U-Boot test
     http://xeidos.ddns.net/tests/test_db_auslesen.php#319
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany