| Message ID | 7ef0d989-49bd-ef37-e7f1-a835caa9b520@ti.com |
|---|---|
| State | RFC |
| Delegated to: | Tom Rini |
| Headers | show |
On Thu, 8 Jun 2017 10:17:09 +0530 Lokesh Vutla <lokeshvutla@ti.com> 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? This doesn't fix the issues, I'm seeing the same behavior. Since we are in rc release maybe it's best to revert the commit and properly implement the changes after 2017.07 is out ? Thanks, > ------------8<------------------8<-------------------------- > From 519035c54cef3f9156303b70322c02f10ec69e00 Mon Sep 17 00:00:00 2001 > From: Lokesh Vutla <lokeshvutla@ti.com> > Date: Thu, 8 Jun 2017 09:34:52 +0530 > Subject: [PATCH] board: am335x: Do not harcode mpu freq for beagleboneblack > > For all am335x boards the mpu frequency is determined by readin > efuse. But for beagleboneblack it is hard coded to 1GHz > irrespective of efuse settings. Due to which some boards > fails to boot with not recommended frequency. Fix it to > use efuse to determine mpu frequency. > > Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> > --- > board/ti/am335x/board.c | 10 ---------- > 1 file changed, 10 deletions(-) > > diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c > index 517965c0f0..4cf6617efb 100644 > --- a/board/ti/am335x/board.c > +++ b/board/ti/am335x/board.c > @@ -294,9 +294,6 @@ const struct dpll_params *get_dpll_mpu_params(void) > if (bone_not_connected_to_ac_power()) > freq = MPUPLL_M_600; > > - if (board_is_bone_lt()) > - freq = MPUPLL_M_1000; > - > switch (freq) { > case MPUPLL_M_1000: > return &dpll_mpu_opp[ind][5]; > @@ -336,13 +333,6 @@ static void scale_vcores_bone(int freq) > if (bone_not_connected_to_ac_power()) > freq = MPUPLL_M_600; > > - /* > - * Override what we have detected since we know if we have > - * a Beaglebone Black it supports 1GHz. > - */ > - if (board_is_bone_lt()) > - freq = MPUPLL_M_1000; > - > if (freq == MPUPLL_M_1000) { > usb_cur_lim = TPS65217_USB_INPUT_CUR_LIMIT_1800MA; > mpu_vdd = TPS65217_DCDC_VOLT_SEL_1325MV; > -- > 2.11.0
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.
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@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@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@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
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@lists.denx.de/msg252698.html 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@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@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@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
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@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@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@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@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 >
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@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@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!
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@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@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. bye, Heiko
On Thu, Jun 8, 2017 at 7:45 PM, Tom Rini <trini@konsulko.com> wrote: > 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. Part of the fun, most shipping BeagleBone and Varients have the proper efuse'ed silicon nowadays.. I think all my Rev B's (2GB eMMC which all 100% have the non-efused silicon) are in my up-time test farm at home. I might have an old one somewhere here at work. But yes, all BeagleBone am335x's where pinned at TI for 1Ghz support before TI started efuse'ing Regards,
On Wed, Jun 7, 2017 at 11:47 PM, Lokesh Vutla <lokeshvutla@ti.com> 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? In the kernel, we are re-enabling the 1GHz option in the BoneBlack's device tree blob: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-boneblack.dts?h=v4.12-rc4&id=bc4b1736f246102e84ce6d3f1a32f614ae27d81f Regards,
On Wed, Jun 7, 2017 at 11:47 PM, Lokesh Vutla <lokeshvutla@ti.com> 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? > > ------------8<------------------8<-------------------------- > From 519035c54cef3f9156303b70322c02f10ec69e00 Mon Sep 17 00:00:00 2001 > From: Lokesh Vutla <lokeshvutla@ti.com> > Date: Thu, 8 Jun 2017 09:34:52 +0530 > Subject: [PATCH] board: am335x: Do not harcode mpu freq for beagleboneblack > > For all am335x boards the mpu frequency is determined by readin > efuse. But for beagleboneblack it is hard coded to 1GHz > irrespective of efuse settings. Due to which some boards > fails to boot with not recommended frequency. Fix it to > use efuse to determine mpu frequency. > > Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> > --- > board/ti/am335x/board.c | 10 ---------- > 1 file changed, 10 deletions(-) > > diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c > index 517965c0f0..4cf6617efb 100644 > --- a/board/ti/am335x/board.c > +++ b/board/ti/am335x/board.c > @@ -294,9 +294,6 @@ const struct dpll_params *get_dpll_mpu_params(void) > if (bone_not_connected_to_ac_power()) > freq = MPUPLL_M_600; > > - if (board_is_bone_lt()) > - freq = MPUPLL_M_1000; > - > switch (freq) { > case MPUPLL_M_1000: > return &dpll_mpu_opp[ind][5]; > @@ -336,13 +333,6 @@ static void scale_vcores_bone(int freq) > if (bone_not_connected_to_ac_power()) > freq = MPUPLL_M_600; > > - /* > - * Override what we have detected since we know if we have > - * a Beaglebone Black it supports 1GHz. > - */ > - if (board_is_bone_lt()) > - freq = MPUPLL_M_1000; > - > if (freq == MPUPLL_M_1000) { > usb_cur_lim = TPS65217_USB_INPUT_CUR_LIMIT_1800MA; > mpu_vdd = TPS65217_DCDC_VOLT_SEL_1325MV; > -- > 2.11.0 > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot Tested-by: Robert Nelson <robertcnelson@gmail.com> On my BBB A5A (2GB), PG 2.0 non-efused silicon.. *************************** U-Boot SPL 2017.07-rc1-00075-g156d64fa55-dirty (Jun 09 2017 - 12:31:11) Trying to boot from MMC1 ** Unable to use mmc 0:1 for loading the env ** Using default environment U-Boot 2017.07-rc1-00075-g156d64fa55-dirty (Jun 09 2017 - 12:31:11 -0500) CPU : AM335X-GP rev 2.0 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 [9df32580, 9df32624] eth0: ethernet@4a100000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 ** File not found boot.scr ** ** Unrecognized filesystem type ** switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... switch to partitions #0, OK *************************** Regards,
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@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@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.
> 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. The button is routed to the expansion header.. I've got a few hot-wired.. GND: P8_43 Regards,
On Fri, 9 Jun 2017 15:13:05 -0400 Tom Rini <trini@konsulko.com> wrote: > 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@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@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 BBB can directly boot from SD if you leave the eMMC blank, that's what I do on all my BBB.
On Fri, Jun 09, 2017 at 02:45:32PM -0500, Robert Nelson wrote: > > 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. > > The button is routed to the expansion header.. > > I've got a few hot-wired.. > > GND: P8_43 Ah, so if I wire P8_43 to ground, the button will always be pressed? Neat, I need to go try that..
On Fri, Jun 09, 2017 at 09:53:14PM +0200, Emmanuel Vadot wrote: > On Fri, 9 Jun 2017 15:13:05 -0400 > Tom Rini <trini@konsulko.com> wrote: > > > 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@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@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. > > BBB can directly boot from SD if you leave the eMMC blank, that's what > I do on all my BBB. I think I knew that, and forgot. Thanks! Time to order up more WiFi SD cards I suspect...
On Fri, Jun 9, 2017 at 3:00 PM, Tom Rini <trini@konsulko.com> wrote: > On Fri, Jun 09, 2017 at 02:45:32PM -0500, Robert Nelson wrote: >> > 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. >> >> The button is routed to the expansion header.. >> >> I've got a few hot-wired.. >> >> GND: P8_43 > > Ah, so if I wire P8_43 to ground, the button will always be pressed? > Neat, I need to go try that.. Correct! Then eMMC won't be even looked at: <normal> mmc1 mmc0 usart0 usb0 <push/button, P8_43/GND> SPI0 mmc0 usb0 uart0 Regards,
Hello Robert, Am 09.06.2017 um 22:00 schrieb Tom Rini: > On Fri, Jun 09, 2017 at 02:45:32PM -0500, Robert Nelson wrote: >>> 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. >> >> The button is routed to the expansion header.. >> >> I've got a few hot-wired.. >> >> GND: P8_43 > > Ah, so if I wire P8_43 to ground, the button will always be pressed? > Neat, I need to go try that.. So I can switch between eMMC and SD card bootmode if I connect a relais? That would be great. So I can in case I see a problem switch to other bootmode and can automate git bisect. Also it would be possible to verify both bootmodes. I have to wait to try this, until Wolfgang is back from vacation, as I have no physical access to the bbb. Thanks for this hint! bye, Heiko
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c index 517965c0f0..4cf6617efb 100644 --- a/board/ti/am335x/board.c +++ b/board/ti/am335x/board.c @@ -294,9 +294,6 @@ const struct dpll_params *get_dpll_mpu_params(void) if (bone_not_connected_to_ac_power()) freq = MPUPLL_M_600; - if (board_is_bone_lt()) - freq = MPUPLL_M_1000; - switch (freq) { case MPUPLL_M_1000: return &dpll_mpu_opp[ind][5]; @@ -336,13 +333,6 @@ static void scale_vcores_bone(int freq) if (bone_not_connected_to_ac_power()) freq = MPUPLL_M_600; - /* - * Override what we have detected since we know if we have - * a Beaglebone Black it supports 1GHz. - */ - if (board_is_bone_lt()) - freq = MPUPLL_M_1000; - if (freq == MPUPLL_M_1000) { usb_cur_lim = TPS65217_USB_INPUT_CUR_LIMIT_1800MA; mpu_vdd = TPS65217_DCDC_VOLT_SEL_1325MV;