[U-Boot] [U-Boot, v2, 4/4] arm: am33xx: Add support for mulitiple PLL input frequencies
Heiko Schocher
hs at denx.de
Fri Jun 9 04:00:17 UTC 2017
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 ...
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
More information about the U-Boot
mailing list