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

[Heiko Schocher <hs@denx.de>]

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@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 ...
>
> 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 at lists.denx.de/msg252698.html

Time for using tbot and automated git bisect testcase ;-)

bye,
Heiko
>
> Thanks and regards,
> Lokesh
>
>>
>> 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