From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Fri, 9 Jun 2017 12:22:44 +0200 Subject: [U-Boot] [U-Boot, v2, 4/4] arm: am33xx: Add support for mulitiple PLL input frequencies In-Reply-To: References: <20170505072910.20772-5-lokeshvutla@ti.com> <20170512172050.GT5701@bill-the-cat> <20170607205006.68b4780d28b90c1dfd9c12fe@bidouilliste.com> <7ef0d989-49bd-ef37-e7f1-a835caa9b520@ti.com> <20170609004521.GU10782@bill-the-cat> <593A1D51.5070505@denx.de> Message-ID: <593A76F4.8040504@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.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 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 >>>>>>> Reviewed-by: Tom Rini >>>>>> >>>>>> 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() >> 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