public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
* [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency
@ 2018-03-15  1:36 David Lechner
  2018-03-15 10:39 ` Peter Howard
                   ` (4 more replies)
  0 siblings, 5 replies; 20+ messages in thread
From: David Lechner @ 2018-03-15  1:36 UTC (permalink / raw)
  To: u-boot

commit 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0 frequency")
changed the PLL0 frequency to 456MHz, which is needed for the LCDC IP
block. However, in doing so, it caused the PLLOUT clock to be outside
of the allowable specifications given in the OMAP-L138 data sheet. (It
says PLLOUT must be 600MHz max). It also uses a PLLM value outside of
the range given in the TRM (it says PLLM must in the range 0 to 0x1f).

So here is what we have currently:

PLLOUT = 24 / (0 + 1) * (37 + 1) = 912MHz (out of spec)
         ^     ^         ^
       CLKIN PREDIV    PLLM (out of spec)

input to PLLDIVn = 912 / (1 + 1) = 456MHz (desired result)
                    ^     ^
                 PLLOUT POSTDIV

This changes the PLLM value to 18 and the POSTDIV value to 0 so that
PLLOUT is now within specification but we still get the desired
result.

PLLOUT = 24 / (0 + 1) * (18 + 1) = 456MHz (within spec)
         ^     ^         ^
       CLKIN PREDIV     PLLM

input to PLLDIVn = 456 / (0 + 1) = 456MHz (desired result)
                    ^     ^
                 PLLOUT POSTDIV

Fixes: 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0 frequency")
Signed-off-by: David Lechner <david@lechnology.com>
---

FYI, I haven't been able to test this patch yet. The changes affect the SPL
image, which has to be flashed to SPI. I am having trouble with the flash
utility[1] running on Linux. It gets stuck at:

   0% [ ------------------------------------------------------------ ]
                Programming application into flash...

So, if anyone has some advice on how to make it work or can test the patch,
that would be helpful.

However, the bootloader on my LCDK is using these values already, so I expect
this to work as advertized.

[1]: http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138


 configs/omapl138_lcdk_defconfig | 1 +
 include/configs/omapl138_lcdk.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/configs/omapl138_lcdk_defconfig b/configs/omapl138_lcdk_defconfig
index ccb308b..0a2af11 100644
--- a/configs/omapl138_lcdk_defconfig
+++ b/configs/omapl138_lcdk_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_DAVINCI=y
 CONFIG_SYS_TEXT_BASE=0xc1080000
 CONFIG_TARGET_OMAPL138_LCDK=y
+CONFIG_SYS_DA850_PLL0_POSTDIV=0
 CONFIG_SYS_DA850_PLL1_PLLDIV3=0x8003
 CONFIG_TI_COMMON_CMD_OPTIONS=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
diff --git a/include/configs/omapl138_lcdk.h b/include/configs/omapl138_lcdk.h
index ea7bdf1..1e1c66b 100644
--- a/include/configs/omapl138_lcdk.h
+++ b/include/configs/omapl138_lcdk.h
@@ -57,7 +57,8 @@
  * PLL configuration
  */
 
-#define CONFIG_SYS_DA850_PLL0_PLLM     37
+/* Requires CONFIG_SYS_DA850_PLL0_POSTDIV=0, set in Kconfig */
+#define CONFIG_SYS_DA850_PLL0_PLLM     18
 #define CONFIG_SYS_DA850_PLL1_PLLM     21
 
 /*
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency
  2018-03-15  1:36 [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency David Lechner
@ 2018-03-15 10:39 ` Peter Howard
  2018-03-15 12:34 ` Sekhar Nori
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 20+ messages in thread
From: Peter Howard @ 2018-03-15 10:39 UTC (permalink / raw)
  To: u-boot

On Wed, 2018-03-14 at 20:36 -0500, David Lechner wrote:
> commit 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0
> frequency")
> changed the PLL0 frequency to 456MHz, which is needed for the LCDC IP
> block. However, in doing so, it caused the PLLOUT clock to be outside
> of the allowable specifications given in the OMAP-L138 data sheet.
> (It
> says PLLOUT must be 600MHz max). It also uses a PLLM value outside of
> the range given in the TRM (it says PLLM must in the range 0 to
> 0x1f).
> 
> So here is what we have currently:
> 
> PLLOUT = 24 / (0 + 1) * (37 + 1) = 912MHz (out of spec)
>          ^     ^         ^
>        CLKIN PREDIV    PLLM (out of spec)
> 
> input to PLLDIVn = 912 / (1 + 1) = 456MHz (desired result)
>                     ^     ^
>                  PLLOUT POSTDIV
> 
> This changes the PLLM value to 18 and the POSTDIV value to 0 so that
> PLLOUT is now within specification but we still get the desired
> result.
> 
> PLLOUT = 24 / (0 + 1) * (18 + 1) = 456MHz (within spec)
>          ^     ^         ^
>        CLKIN PREDIV     PLLM
> 
> input to PLLDIVn = 456 / (0 + 1) = 456MHz (desired result)
>                     ^     ^
>                  PLLOUT POSTDIV
> 
> Fixes: 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0
> frequency")
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
> 
> FYI, I haven't been able to test this patch yet. The changes affect
> the SPL
> image, which has to be flashed to SPI. I am having trouble with the
> flash
> utility[1] running on Linux. It gets stuck at:
> 
>    0% [ ------------------------------------------------------------
> ]
>                 Programming application into flash...
> 
> So, if anyone has some advice on how to make it work or can test the
> patch,
> that would be helpful.
> 

I have done a first-pass sanity check and it works.  However the
current default setup is not what I have been using (this is the first
time in some months I've done anything on the LCDK) and I haven't
booted out of u-boot, so I wouldn't call this "works perfectly".  I'll
do some more serious testing over the weekend.

Cross-compile toolchain:
  gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)

Flash command:
  mono sfh_OMAP-L138.exe -flash_noubl -targetType OMAPL138_LCDK -flashType NAND -p /dev/ttyUSB1 u-boot.ais

Console output on boot:
  U-Boot SPL 2018.03-00068-g218da80-dirty (Mar 15 2018 - 21:15:08 +1100)
  Trying to boot from NAND

  U-Boot SPL 2018.03-00068-g218da80-dirty (Mar 15 2018 - 21:15:08 +1100)
  Trying to boot from NAND

  U-Boot SPL 2018.03-00068-g218da80-dirty (Mar 15 2018 - 21:15:08 +1100)
  Trying to boot from NAND

(As I don't have anything set up on NAND the cycling is to be expected)
 
> However, the bootloader on my LCDK is using these values already, so
> I expect
> this to work as advertized.
> 
> [1]: http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Lo
> ading_Utility_for_OMAP-L138
> 
> 
>  configs/omapl138_lcdk_defconfig | 1 +
>  include/configs/omapl138_lcdk.h | 3 ++-
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/configs/omapl138_lcdk_defconfig
> b/configs/omapl138_lcdk_defconfig
> index ccb308b..0a2af11 100644
> --- a/configs/omapl138_lcdk_defconfig
> +++ b/configs/omapl138_lcdk_defconfig
> @@ -2,6 +2,7 @@ CONFIG_ARM=y
>  CONFIG_ARCH_DAVINCI=y
>  CONFIG_SYS_TEXT_BASE=0xc1080000
>  CONFIG_TARGET_OMAPL138_LCDK=y
> +CONFIG_SYS_DA850_PLL0_POSTDIV=0
>  CONFIG_SYS_DA850_PLL1_PLLDIV3=0x8003
>  CONFIG_TI_COMMON_CMD_OPTIONS=y
>  CONFIG_SPL_LIBCOMMON_SUPPORT=y
> diff --git a/include/configs/omapl138_lcdk.h
> b/include/configs/omapl138_lcdk.h
> index ea7bdf1..1e1c66b 100644
> --- a/include/configs/omapl138_lcdk.h
> +++ b/include/configs/omapl138_lcdk.h
> @@ -57,7 +57,8 @@
>   * PLL configuration
>   */
>  
> -#define CONFIG_SYS_DA850_PLL0_PLLM     37
> +/* Requires CONFIG_SYS_DA850_PLL0_POSTDIV=0, set in Kconfig */
> +#define CONFIG_SYS_DA850_PLL0_PLLM     18
>  #define CONFIG_SYS_DA850_PLL1_PLLM     21
>  
>  /*

-- 
Peter Howard <pjh@northern-ridge.com.au>

(also <phoward@gme.net.au>)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180315/ed4427fb/attachment.sig>

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency
  2018-03-15  1:36 [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency David Lechner
  2018-03-15 10:39 ` Peter Howard
@ 2018-03-15 12:34 ` Sekhar Nori
  2018-03-15 13:42   ` Sekhar Nori
  2018-03-15 14:32   ` David Lechner
  2018-03-16  6:26 ` Mike Looijmans
                   ` (2 subsequent siblings)
  4 siblings, 2 replies; 20+ messages in thread
From: Sekhar Nori @ 2018-03-15 12:34 UTC (permalink / raw)
  To: u-boot

Hi David,

On Thursday 15 March 2018 07:06 AM, David Lechner wrote:
> commit 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0 frequency")
> changed the PLL0 frequency to 456MHz, which is needed for the LCDC IP
> block. However, in doing so, it caused the PLLOUT clock to be outside
> of the allowable specifications given in the OMAP-L138 data sheet. (It
> says PLLOUT must be 600MHz max). It also uses a PLLM value outside of
> the range given in the TRM (it says PLLM must in the range 0 to 0x1f).
> 
> So here is what we have currently:
> 
> PLLOUT = 24 / (0 + 1) * (37 + 1) = 912MHz (out of spec)
>          ^     ^         ^
>        CLKIN PREDIV    PLLM (out of spec)
> 
> input to PLLDIVn = 912 / (1 + 1) = 456MHz (desired result)
>                     ^     ^
>                  PLLOUT POSTDIV
> 
> This changes the PLLM value to 18 and the POSTDIV value to 0 so that
> PLLOUT is now within specification but we still get the desired
> result.
> 
> PLLOUT = 24 / (0 + 1) * (18 + 1) = 456MHz (within spec)
>          ^     ^         ^
>        CLKIN PREDIV     PLLM
> 
> input to PLLDIVn = 456 / (0 + 1) = 456MHz (desired result)
>                     ^     ^
>                  PLLOUT POSTDIV
> 
> Fixes: 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0 frequency")
> Signed-off-by: David Lechner <david@lechnology.com>

Thanks for the patch and great description. It looks correct to me.
Hopefully I can provide some testing feedback too soon.

> ---
> 
> FYI, I haven't been able to test this patch yet. The changes affect the SPL
> image, which has to be flashed to SPI. I am having trouble with the flash
> utility[1] running on Linux. It gets stuck at:
> 
>    0% [ ------------------------------------------------------------ ]
>                 Programming application into flash...
> 
> So, if anyone has some advice on how to make it work or can test the patch,
> that would be helpful.

The easiest thing to do would be to shift to MMC/SD boot so you can
easily update images.

Before starting though, I would take note of out-of-the-box boot switch
settings and also take a disk image backup of the SD card. Or better
yet, just use another SD card.

Setup the SW1 dip switch thus:
http://processors.wiki.ti.com/index.php/How_to_boot_OMAP-L138_LCDK_from_SD_card#Settings_DIP_switches_to_SD.2FMMC_boot_mode

Prepare an SD card for boot:

$ sudo dd if=u-boot.ais of=/dev/sd<N> seek=117 bs=512 conv=fsync

Thanks,
Sekhar

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency
  2018-03-15 12:34 ` Sekhar Nori
@ 2018-03-15 13:42   ` Sekhar Nori
  2018-03-15 14:31     ` Sekhar Nori
  2018-03-15 14:32   ` David Lechner
  1 sibling, 1 reply; 20+ messages in thread
From: Sekhar Nori @ 2018-03-15 13:42 UTC (permalink / raw)
  To: u-boot

On Thursday 15 March 2018 06:04 PM, Sekhar Nori wrote:
> Thanks for the patch and great description. It looks correct to me.
> Hopefully I can provide some testing feedback too soon.

Something seems to have broken MMC/SD support on OMAP-L138 LCDK on 
2018.03[1]. 2018.01 works fine[2].

Will check what went wrong.

Thanks,
Sekhar

[1]
U-Boot SPL 2018.01 (Mar 15 2018 - 19:03:49)
Trying to boot from MMC1


U-Boot 2018.01 (Mar 15 2018 - 19:03:49 +0530)

I2C:   ready
DRAM:  128 MiB
WARNING: Caches not enabled
NAND:  512 MiB
MMC:   davinci: 0
In:    serial
Out:   serial
Err:   serial
Invalid MAC address read.
Net:   DaVinci-EMAC
Warning: DaVinci-EMAC (eth0) using random MAC address - ce:e4:a2:63:dd:61

Hit any key to stop autoboot:  0 

[2]
U-Boot SPL 2018.03 (Mar 15 2018 - 19:07:39 +0530)
Trying to boot from MMC1
MMC Device 0 not found
spl: could not find mmc device. error: -19
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency
  2018-03-15 13:42   ` Sekhar Nori
@ 2018-03-15 14:31     ` Sekhar Nori
  2018-03-15 14:56       ` Tom Rini
  2018-03-15 15:01       ` Lokesh Vutla
  0 siblings, 2 replies; 20+ messages in thread
From: Sekhar Nori @ 2018-03-15 14:31 UTC (permalink / raw)
  To: u-boot

On Thursday 15 March 2018 07:12 PM, Sekhar Nori wrote:
> On Thursday 15 March 2018 06:04 PM, Sekhar Nori wrote:
>> Thanks for the patch and great description. It looks correct to me.
>> Hopefully I can provide some testing feedback too soon.
> 
> Something seems to have broken MMC/SD support on OMAP-L138 LCDK on 
> 2018.03[1]. 2018.01 works fine[2].
> 
> Will check what went wrong.

The commit that broke is 6aa4ad8e3820adefaf09fe21efae06772003620f
"Convert CONFIG_SOC_DA8XX et al to Kconfig". The commit prior to that
works. I cannot revert it cleanly on latest mainline.

I have copied others involved in that commit for help.

Thanks,
Sekhar

> 
> Thanks,
> Sekhar
> 
> [1]
> U-Boot SPL 2018.01 (Mar 15 2018 - 19:03:49)
> Trying to boot from MMC1
> 
> 
> U-Boot 2018.01 (Mar 15 2018 - 19:03:49 +0530)
> 
> I2C:   ready
> DRAM:  128 MiB
> WARNING: Caches not enabled
> NAND:  512 MiB
> MMC:   davinci: 0
> In:    serial
> Out:   serial
> Err:   serial
> Invalid MAC address read.
> Net:   DaVinci-EMAC
> Warning: DaVinci-EMAC (eth0) using random MAC address - ce:e4:a2:63:dd:61
> 
> Hit any key to stop autoboot:  0 
> 
> [2]
> U-Boot SPL 2018.03 (Mar 15 2018 - 19:07:39 +0530)
> Trying to boot from MMC1
> MMC Device 0 not found
> spl: could not find mmc device. error: -19
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
> 

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency
  2018-03-15 12:34 ` Sekhar Nori
  2018-03-15 13:42   ` Sekhar Nori
@ 2018-03-15 14:32   ` David Lechner
  2018-03-16  9:26     ` Sekhar Nori
  1 sibling, 1 reply; 20+ messages in thread
From: David Lechner @ 2018-03-15 14:32 UTC (permalink / raw)
  To: u-boot

On 03/15/2018 07:34 AM, Sekhar Nori wrote:
> Hi David,
> 
> On Thursday 15 March 2018 07:06 AM, David Lechner wrote:
>> commit 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0 frequency")
>> changed the PLL0 frequency to 456MHz, which is needed for the LCDC IP
>> block. However, in doing so, it caused the PLLOUT clock to be outside
>> of the allowable specifications given in the OMAP-L138 data sheet. (It
>> says PLLOUT must be 600MHz max). It also uses a PLLM value outside of
>> the range given in the TRM (it says PLLM must in the range 0 to 0x1f).
>>
>> So here is what we have currently:
>>
>> PLLOUT = 24 / (0 + 1) * (37 + 1) = 912MHz (out of spec)
>>           ^     ^         ^
>>         CLKIN PREDIV    PLLM (out of spec)
>>
>> input to PLLDIVn = 912 / (1 + 1) = 456MHz (desired result)
>>                      ^     ^
>>                   PLLOUT POSTDIV
>>
>> This changes the PLLM value to 18 and the POSTDIV value to 0 so that
>> PLLOUT is now within specification but we still get the desired
>> result.
>>
>> PLLOUT = 24 / (0 + 1) * (18 + 1) = 456MHz (within spec)
>>           ^     ^         ^
>>         CLKIN PREDIV     PLLM
>>
>> input to PLLDIVn = 456 / (0 + 1) = 456MHz (desired result)
>>                      ^     ^
>>                   PLLOUT POSTDIV
>>
>> Fixes: 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0 frequency")
>> Signed-off-by: David Lechner <david@lechnology.com>
> 
> Thanks for the patch and great description. It looks correct to me.
> Hopefully I can provide some testing feedback too soon.
> 
>> ---
>>
>> FYI, I haven't been able to test this patch yet. The changes affect the SPL
>> image, which has to be flashed to SPI. I am having trouble with the flash
>> utility[1] running on Linux. It gets stuck at:
>>
>>     0% [ ------------------------------------------------------------ ]
>>                  Programming application into flash...
>>
>> So, if anyone has some advice on how to make it work or can test the patch,
>> that would be helpful.
> 
> The easiest thing to do would be to shift to MMC/SD boot so you can
> easily update images.
> 
> Before starting though, I would take note of out-of-the-box boot switch
> settings and also take a disk image backup of the SD card. Or better
> yet, just use another SD card.
> 
> Setup the SW1 dip switch thus:
> http://processors.wiki.ti.com/index.php/How_to_boot_OMAP-L138_LCDK_from_SD_card#Settings_DIP_switches_to_SD.2FMMC_boot_mode
> 
> Prepare an SD card for boot:
> 
> $ sudo dd if=u-boot.ais of=/dev/sd<N> seek=117 bs=512 conv=fsync

Thanks for the tips. I've actually done exactly that (using my own SD card).

However, these changes affect the u-boot SPL image only. I was able to put
the regular u-boot.ais on the SD card, but I'm having troubling figuring
out how to install the SPL image.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency
  2018-03-15 14:31     ` Sekhar Nori
@ 2018-03-15 14:56       ` Tom Rini
  2018-03-15 15:02         ` David Lechner
  2018-03-15 15:01       ` Lokesh Vutla
  1 sibling, 1 reply; 20+ messages in thread
From: Tom Rini @ 2018-03-15 14:56 UTC (permalink / raw)
  To: u-boot

On Thu, Mar 15, 2018 at 08:01:58PM +0530, Sekhar Nori wrote:
> On Thursday 15 March 2018 07:12 PM, Sekhar Nori wrote:
> > On Thursday 15 March 2018 06:04 PM, Sekhar Nori wrote:
> >> Thanks for the patch and great description. It looks correct to me.
> >> Hopefully I can provide some testing feedback too soon.
> > 
> > Something seems to have broken MMC/SD support on OMAP-L138 LCDK on 
> > 2018.03[1]. 2018.01 works fine[2].
> > 
> > Will check what went wrong.
> 
> The commit that broke is 6aa4ad8e3820adefaf09fe21efae06772003620f
> "Convert CONFIG_SOC_DA8XX et al to Kconfig". The commit prior to that
> works. I cannot revert it cleanly on latest mainline.
> 
> I have copied others involved in that commit for help.

I would check into what SOC_DA8XX selects/implies, perhaps something
isn't quite right for DA8XX vs DA850 vs DA830 ?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180315/ada3acfc/attachment.sig>

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency
  2018-03-15 14:31     ` Sekhar Nori
  2018-03-15 14:56       ` Tom Rini
@ 2018-03-15 15:01       ` Lokesh Vutla
  2018-03-16  7:51         ` Sekhar Nori
  1 sibling, 1 reply; 20+ messages in thread
From: Lokesh Vutla @ 2018-03-15 15:01 UTC (permalink / raw)
  To: u-boot



On Thursday 15 March 2018 08:01 PM, Sekhar Nori wrote:
> On Thursday 15 March 2018 07:12 PM, Sekhar Nori wrote:
>> On Thursday 15 March 2018 06:04 PM, Sekhar Nori wrote:
>>> Thanks for the patch and great description. It looks correct to me.
>>> Hopefully I can provide some testing feedback too soon.
>>
>> Something seems to have broken MMC/SD support on OMAP-L138 LCDK on 
>> 2018.03[1]. 2018.01 works fine[2].
>>
>> Will check what went wrong.
> 
> The commit that broke is 6aa4ad8e3820adefaf09fe21efae06772003620f
> "Convert CONFIG_SOC_DA8XX et al to Kconfig". The commit prior to that
> works. I cannot revert it cleanly on latest mainline.
> 
> I have copied others involved in that commit for help.

Looks like DDR init is being removed. Can you try the below diff and see
if it helps?

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 30752839a3..5e7baba3fe 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -58,6 +58,7 @@ config SOC_DA850
 config SOC_DA8XX
 	bool
 	select SYS_DA850_PLL_INIT if SUPPORT_SPL || DA850_LOWLEVEL
+	select SYS_DA850_DDR_INIT if SUPPORT_SPL || DA850_LOWLEVEL

 config MACH_DAVINCI_DA850_EVM
 	bool


Thanks and regards,
Lokesh

^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency
  2018-03-15 14:56       ` Tom Rini
@ 2018-03-15 15:02         ` David Lechner
  2018-03-16  8:04           ` Sekhar Nori
  0 siblings, 1 reply; 20+ messages in thread
From: David Lechner @ 2018-03-15 15:02 UTC (permalink / raw)
  To: u-boot

On 03/15/2018 09:56 AM, Tom Rini wrote:
> On Thu, Mar 15, 2018 at 08:01:58PM +0530, Sekhar Nori wrote:
>> On Thursday 15 March 2018 07:12 PM, Sekhar Nori wrote:
>>> On Thursday 15 March 2018 06:04 PM, Sekhar Nori wrote:
>>>> Thanks for the patch and great description. It looks correct to me.
>>>> Hopefully I can provide some testing feedback too soon.
>>>
>>> Something seems to have broken MMC/SD support on OMAP-L138 LCDK on
>>> 2018.03[1]. 2018.01 works fine[2].
>>>
>>> Will check what went wrong.
>>
>> The commit that broke is 6aa4ad8e3820adefaf09fe21efae06772003620f
>> "Convert CONFIG_SOC_DA8XX et al to Kconfig". The commit prior to that
>> works. I cannot revert it cleanly on latest mainline.
>>
>> I have copied others involved in that commit for help.
> 
> I would check into what SOC_DA8XX selects/implies, perhaps something
> isn't quite right for DA8XX vs DA850 vs DA830 ?  Thanks!
> 

Indeed:

+config SOC_DA850
+	bool
+	select SOC_DA8XX
+	select SYS_DA850_DDR_INIT if SUPPORT_SPL || DA850_LOWLEVEL
+
+config SOC_DA8XX
+	bool
+	select SYS_DA850_PLL_INIT if SUPPORT_SPL || DA850_LOWLEVEL
+
+config MACH_DAVINCI_DA850_EVM
+	bool
+

I believe that

	select SYS_DA850_DDR_INIT if SUPPORT_SPL || DA850_LOWLEVEL

should be under SOC_DA8XX instead of SOC_DA850.

The LCDK board only selects SOC_DA8XX and not SOC_DA850, whereas
other DA850 family boards all select SOC_DA850. This would explain
why the LCDK is broken, but not other boards.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency
  2018-03-15  1:36 [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency David Lechner
  2018-03-15 10:39 ` Peter Howard
  2018-03-15 12:34 ` Sekhar Nori
@ 2018-03-16  6:26 ` Mike Looijmans
  2018-03-16 15:56   ` David Lechner
  2018-03-18  4:12 ` Peter Howard
  2018-03-22 20:35 ` [U-Boot] " Tom Rini
  4 siblings, 1 reply; 20+ messages in thread
From: Mike Looijmans @ 2018-03-16  6:26 UTC (permalink / raw)
  To: u-boot

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8-sig", Size: 3877 bytes --]


On 15-03-18 02:36, David Lechner wrote:
> commit 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0 frequency")
> changed the PLL0 frequency to 456MHz, which is needed for the LCDC IP
> block. However, in doing so, it caused the PLLOUT clock to be outside
> of the allowable specifications given in the OMAP-L138 data sheet. (It
> says PLLOUT must be 600MHz max). It also uses a PLLM value outside of
> the range given in the TRM (it says PLLM must in the range 0 to 0x1f).
> 
> So here is what we have currently:
> 
> PLLOUT = 24 / (0 + 1) * (37 + 1) = 912MHz (out of spec)
>           ^     ^         ^
>         CLKIN PREDIV    PLLM (out of spec)
> 
> input to PLLDIVn = 912 / (1 + 1) = 456MHz (desired result)
>                      ^     ^
>                   PLLOUT POSTDIV
> 
> This changes the PLLM value to 18 and the POSTDIV value to 0 so that
> PLLOUT is now within specification but we still get the desired
> result.
> 
> PLLOUT = 24 / (0 + 1) * (18 + 1) = 456MHz (within spec)
>           ^     ^         ^
>         CLKIN PREDIV     PLLM
> 
> input to PLLDIVn = 456 / (0 + 1) = 456MHz (desired result)
>                      ^     ^
>                   PLLOUT POSTDIV
> 

These are indeed the correct settings for 456MHz operation, I've used them in 
an L138 device a few years ago.

Did you also increase the CPU voltage to 1.3V? This can be done writing to the 
I2C power management chip, in my stone age setup I had this piece of code to 
do that:

#define TPS6507X_I2C_ADDR	0x48
#define TPS6507X_REG_DEFLDO2	0x17
u8 buf = 0x17;
i2c_write(TPS6507X_I2C_ADDR, TPS6507X_REG_DEFLDO2, 1, &buf, 1)

Without the voltage change, some batches of CPUs will fail to boot properly at 
456MHz.


> Fixes: 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0 frequency")
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
> 
> FYI, I haven't been able to test this patch yet. The changes affect the SPL
> image, which has to be flashed to SPI. I am having trouble with the flash
> utility[1] running on Linux. It gets stuck at:
> 
>     0% [ ------------------------------------------------------------ ]
>                  Programming application into flash...
> 
> So, if anyone has some advice on how to make it work or can test the patch,
> that would be helpful.
> 
> However, the bootloader on my LCDK is using these values already, so I expect
> this to work as advertized.
> 
> [1]: http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138
> 
> 
>   configs/omapl138_lcdk_defconfig | 1 +
>   include/configs/omapl138_lcdk.h | 3 ++-
>   2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/configs/omapl138_lcdk_defconfig b/configs/omapl138_lcdk_defconfig
> index ccb308b..0a2af11 100644
> --- a/configs/omapl138_lcdk_defconfig
> +++ b/configs/omapl138_lcdk_defconfig
> @@ -2,6 +2,7 @@ CONFIG_ARM=y
>   CONFIG_ARCH_DAVINCI=y
>   CONFIG_SYS_TEXT_BASE=0xc1080000
>   CONFIG_TARGET_OMAPL138_LCDK=y
> +CONFIG_SYS_DA850_PLL0_POSTDIV=0
>   CONFIG_SYS_DA850_PLL1_PLLDIV3=0x8003
>   CONFIG_TI_COMMON_CMD_OPTIONS=y
>   CONFIG_SPL_LIBCOMMON_SUPPORT=y
> diff --git a/include/configs/omapl138_lcdk.h b/include/configs/omapl138_lcdk.h
> index ea7bdf1..1e1c66b 100644
> --- a/include/configs/omapl138_lcdk.h
> +++ b/include/configs/omapl138_lcdk.h
> @@ -57,7 +57,8 @@
>    * PLL configuration
>    */
>   
> -#define CONFIG_SYS_DA850_PLL0_PLLM     37
> +/* Requires CONFIG_SYS_DA850_PLL0_POSTDIV=0, set in Kconfig */
> +#define CONFIG_SYS_DA850_PLL0_PLLM     18
>   #define CONFIG_SYS_DA850_PLL1_PLLM     21
>   
>   /*
> 



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans at topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail




^ permalink raw reply	[flat|nested] 20+ messages in thread

* [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency
  2018-03-15 15:01       ` Lokesh Vutla
@ 2018-03-16  7:51         ` Sekhar Nori
  0 siblings, 0 replies; 20+ messages in thread
From: Sekhar Nori @ 2018-03-16  7:51 UTC (permalink / raw)
  To: u-boot

On Thursday 15 March 2018 08:31 PM, Lokesh Vutla wrote:
> 
> 
> On Thursday 15 March 2018 08:01 PM, Sekhar Nori wrote:
>> On Thursday 15 March 2018 07:12 PM, Sekhar Nori wrote:
>>> On Thursday 15 March 2018 06:04 PM, Sekhar Nori wrote:
>>>> Thanks for the patch and great description. It looks correct to me.
>>>> Hopefully I can provide some testing feedback too soon.
>>>
>>> Something seems to have broken MMC/SD support on OMAP-L138 LCDK on 
>>> 2018.03[1]. 2018.01 works fine[2].
>>>
>>> Will check what went wrong.
>>
>> The commit that broke is 6aa4ad8e3820adefaf09fe21efae06772003620f
>> "Convert CONFIG_SOC_DA8XX et al to Kconfig". The commit prior to that
>> works. I cannot revert it cleanly on latest mainline.
>>
>> I have copied others involved in that commit for help.
> 
> Looks like DDR init is being removed. Can you try the below diff and see
> if it helps?
> 
> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> index 30752839a3..5e7baba3fe 100644
> --- a/arch/arm/mach-davinci/Kconfig
> +++ b/arch/arm/mach-davinci/Kconfig
> @@ -58,6 +58,7 @@ config SOC_DA850
>  config SOC_DA8XX
>  	bool
>  	select SYS_DA850_PLL_INIT if SUPPORT_SPL || DA850_LOWLEVEL
> +	select SYS_DA850_DDR_INIT if SUPPORT_SPL || DA850_LOWLEVEL

Yes, this restores LCDK board boot. Can you please submit a formal patch?

You can add:

Reported-by: Sekhar Nori <nsekhar@ti.com>
Tested-by: Sekhar Nori <nsekhar@ti.com>

Thanks,
Sekhar

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency
  2018-03-15 15:02         ` David Lechner
@ 2018-03-16  8:04           ` Sekhar Nori
  0 siblings, 0 replies; 20+ messages in thread
From: Sekhar Nori @ 2018-03-16  8:04 UTC (permalink / raw)
  To: u-boot

On Thursday 15 March 2018 08:32 PM, David Lechner wrote:
> On 03/15/2018 09:56 AM, Tom Rini wrote:
>> On Thu, Mar 15, 2018 at 08:01:58PM +0530, Sekhar Nori wrote:
>>> On Thursday 15 March 2018 07:12 PM, Sekhar Nori wrote:
>>>> On Thursday 15 March 2018 06:04 PM, Sekhar Nori wrote:
>>>>> Thanks for the patch and great description. It looks correct to me.
>>>>> Hopefully I can provide some testing feedback too soon.
>>>>
>>>> Something seems to have broken MMC/SD support on OMAP-L138 LCDK on
>>>> 2018.03[1]. 2018.01 works fine[2].
>>>>
>>>> Will check what went wrong.
>>>
>>> The commit that broke is 6aa4ad8e3820adefaf09fe21efae06772003620f
>>> "Convert CONFIG_SOC_DA8XX et al to Kconfig". The commit prior to that
>>> works. I cannot revert it cleanly on latest mainline.
>>>
>>> I have copied others involved in that commit for help.
>>
>> I would check into what SOC_DA8XX selects/implies, perhaps something
>> isn't quite right for DA8XX vs DA850 vs DA830 ?  Thanks!
>>
> 
> Indeed:
> 
> +config SOC_DA850
> +    bool
> +    select SOC_DA8XX
> +    select SYS_DA850_DDR_INIT if SUPPORT_SPL || DA850_LOWLEVEL
> +
> +config SOC_DA8XX
> +    bool
> +    select SYS_DA850_PLL_INIT if SUPPORT_SPL || DA850_LOWLEVEL
> +
> +config MACH_DAVINCI_DA850_EVM
> +    bool
> +
> 
> I believe that
> 
>     select SYS_DA850_DDR_INIT if SUPPORT_SPL || DA850_LOWLEVEL
> 
> should be under SOC_DA8XX instead of SOC_DA850.
> 
> The LCDK board only selects SOC_DA8XX and not SOC_DA850, whereas
> other DA850 family boards all select SOC_DA850. This would explain
> why the LCDK is broken, but not other boards.

In the latest mainline, after commit 2e87980580d0 ("davinci: Fix
omapl138_lcdk builds"), SYS_DA850_DDR_INIT remains unselected for all
boards. So, I believe boot should be broken on all DA850 boards.

There is no DA830 support in U-Boot anymore. So, SOC_DA8XX is
effectively is same as SOC_DA850.

Thanks,
Sekhar

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency
  2018-03-15 14:32   ` David Lechner
@ 2018-03-16  9:26     ` Sekhar Nori
  2018-03-16 15:45       ` David Lechner
  0 siblings, 1 reply; 20+ messages in thread
From: Sekhar Nori @ 2018-03-16  9:26 UTC (permalink / raw)
  To: u-boot

On Thursday 15 March 2018 08:02 PM, David Lechner wrote:
> 
> Thanks for the tips. I've actually done exactly that (using my own SD
> card).
> 
> However, these changes affect the u-boot SPL image only. I was able to put
> the regular u-boot.ais on the SD card, but I'm having troubling figuring
> out how to install the SPL image.

Err, I thought u-boot.ais is SPL and U-Boot images concatenated
together. Anyway, I was able to test your change.

Tested-by: Sekhar Nori <nsekhar@ti.com>

Thanks,
Sekhar

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency
  2018-03-16  9:26     ` Sekhar Nori
@ 2018-03-16 15:45       ` David Lechner
  2018-03-18  4:21         ` Peter Howard
  2018-03-18  4:22         ` Peter Howard
  0 siblings, 2 replies; 20+ messages in thread
From: David Lechner @ 2018-03-16 15:45 UTC (permalink / raw)
  To: u-boot

On 03/16/2018 04:26 AM, Sekhar Nori wrote:
> On Thursday 15 March 2018 08:02 PM, David Lechner wrote:
>>
>> Thanks for the tips. I've actually done exactly that (using my own SD
>> card).
>>
>> However, these changes affect the u-boot SPL image only. I was able to put
>> the regular u-boot.ais on the SD card, but I'm having troubling figuring
>> out how to install the SPL image.
> 
> Err, I thought u-boot.ais is SPL and U-Boot images concatenated
> together. Anyway, I was able to test your change.

I have no idea. :-)

I've been trying to follow the TI wiki pages, but they are rather inconsistent
so I am having trouble figuring out what is correct and what is not.

[1] seems to be pretty good, but it doesn't have any board-specific information
or information about installing U-Boot on the SD card. [2] Says to flash the
NAND. [3] says to `sudo dd in=u-boot.ais of=/dev/sdx seek=10` and to "Flash the
SPL AIS file into SPI flash" and to use some `tools/uflash/uflash` for the SD
card that I never found. [4] says to `sudo dd if=u-boot-omapl138-lcdk.ais
of=/dev/sd<N> seek=117 bs=512 conv=fsync`, which I did with my u-boot.bin, but
I doesn't explain how to actually boot from this.

[1]: http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138
[2]: http://processors.wiki.ti.com/index.php/L138/C6748_Development_Kit_(LCDK)#Procedure_to_Flash_and_boot_the_LCDK
[3]: http://processors.wiki.ti.com/index.php/OMAP-L138_Preparing_SD_Card_for_Boot
[4]: http://processors.wiki.ti.com/index.php/Processor_SDK_Linux_create_SD_card_script


> 
> Tested-by: Sekhar Nori <nsekhar@ti.com>
> 
> Thanks,
> Sekhar
> 

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency
  2018-03-16  6:26 ` Mike Looijmans
@ 2018-03-16 15:56   ` David Lechner
  2018-03-18 18:26     ` Mike Looijmans
  0 siblings, 1 reply; 20+ messages in thread
From: David Lechner @ 2018-03-16 15:56 UTC (permalink / raw)
  To: u-boot

On 03/16/2018 01:26 AM, Mike Looijmans wrote:
> 
> On 15-03-18 02:36, David Lechner wrote:
>> commit 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0 frequency")
>> changed the PLL0 frequency to 456MHz, which is needed for the LCDC IP
>> block. However, in doing so, it caused the PLLOUT clock to be outside
>> of the allowable specifications given in the OMAP-L138 data sheet. (It
>> says PLLOUT must be 600MHz max). It also uses a PLLM value outside of
>> the range given in the TRM (it says PLLM must in the range 0 to 0x1f).
>>
>> So here is what we have currently:
>>
>> PLLOUT = 24 / (0 + 1) * (37 + 1) = 912MHz (out of spec)
>>           ^     ^         ^
>>         CLKIN PREDIV    PLLM (out of spec)
>>
>> input to PLLDIVn = 912 / (1 + 1) = 456MHz (desired result)
>>                      ^     ^
>>                   PLLOUT POSTDIV
>>
>> This changes the PLLM value to 18 and the POSTDIV value to 0 so that
>> PLLOUT is now within specification but we still get the desired
>> result.
>>
>> PLLOUT = 24 / (0 + 1) * (18 + 1) = 456MHz (within spec)
>>           ^     ^         ^
>>         CLKIN PREDIV     PLLM
>>
>> input to PLLDIVn = 456 / (0 + 1) = 456MHz (desired result)
>>                      ^     ^
>>                   PLLOUT POSTDIV
>>
> 
> These are indeed the correct settings for 456MHz operation, I've used them in an L138 device a few years ago.
> 
> Did you also increase the CPU voltage to 1.3V? This can be done writing to the I2C power management chip, in my stone age setup I had this piece of code to do that:
> 
> #define TPS6507X_I2C_ADDR    0x48
> #define TPS6507X_REG_DEFLDO2    0x17
> u8 buf = 0x17;
> i2c_write(TPS6507X_I2C_ADDR, TPS6507X_REG_DEFLDO2, 1, &buf, 1)
> 
> Without the voltage change, some batches of CPUs will fail to boot properly at 456MHz.


I was wondering about this, but it looks to me like the LCDK board (at least the A7E
revision) has a fixed regulator at 1.3V (TPS650250RHBR). Perhaps you are using a
different board?

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency
  2018-03-15  1:36 [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency David Lechner
                   ` (2 preceding siblings ...)
  2018-03-16  6:26 ` Mike Looijmans
@ 2018-03-18  4:12 ` Peter Howard
  2018-03-22 20:35 ` [U-Boot] " Tom Rini
  4 siblings, 0 replies; 20+ messages in thread
From: Peter Howard @ 2018-03-18  4:12 UTC (permalink / raw)
  To: u-boot

On Wed, 2018-03-14 at 20:36 -0500, David Lechner wrote:
> commit 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0
> frequency")
> changed the PLL0 frequency to 456MHz, which is needed for the LCDC IP
> block. However, in doing so, it caused the PLLOUT clock to be outside
> of the allowable specifications given in the OMAP-L138 data sheet.
> (It
> says PLLOUT must be 600MHz max). It also uses a PLLM value outside of
> the range given in the TRM (it says PLLM must in the range 0 to
> 0x1f).
> 
> So here is what we have currently:
> 
> PLLOUT = 24 / (0 + 1) * (37 + 1) = 912MHz (out of spec)
>          ^     ^         ^
>        CLKIN PREDIV    PLLM (out of spec)
> 
> input to PLLDIVn = 912 / (1 + 1) = 456MHz (desired result)
>                     ^     ^
>                  PLLOUT POSTDIV
> 
> This changes the PLLM value to 18 and the POSTDIV value to 0 so that
> PLLOUT is now within specification but we still get the desired
> result.
> 
> PLLOUT = 24 / (0 + 1) * (18 + 1) = 456MHz (within spec)
>          ^     ^         ^
>        CLKIN PREDIV     PLLM
> 
> input to PLLDIVn = 456 / (0 + 1) = 456MHz (desired result)
>                     ^     ^
>                  PLLOUT POSTDIV
> 
> Fixes: 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0
> frequency")
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
> 
> FYI, I haven't been able to test this patch yet. The changes affect
> the SPL
> image, which has to be flashed to SPI. I am having trouble with the
> flash
> utility[1] running on Linux. It gets stuck at:
> 
>    0% [ ------------------------------------------------------------
> ]
>                 Programming application into flash...
> 
> So, if anyone has some advice on how to make it work or can test the
> patch,
> that would be helpful.
> 

OK, having applied the DDR fix on top of this fix I'm getting the LCDK
boot I expect.  Thinking back, when I've had hangs at that point it
relates to the NAND not being initialised properly.  And that was due
to me making changes in OMAP-L138_FlashAndBootUtils_2_21 itself and/or
because I was working on a custom L138 board (not the LCDK) and things
were wrong.

> However, the bootloader on my LCDK is using these values already, so
> I expect
> this to work as advertized.

Which bootloader are you referring to?  At that point the code running
is the stub that sfh_OMAP-L138.exe has transferred, not anything in u-
boot.

Have you ever had a succesful transfer with sfh_OMAP-L138.exe?  The
.ini files included didn't  work for me with the LCDK - I had to roll
my own.  That's _definitely_ an issue for running (the now-unnecesary)
HexAIS_OMAP-L138.exe, but I don't think it's relevant to the flashing
utility.

> 
> [1]: http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Lo
> ading_Utility_for_OMAP-L138
> 
> 
>  configs/omapl138_lcdk_defconfig | 1 +
>  include/configs/omapl138_lcdk.h | 3 ++-
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/configs/omapl138_lcdk_defconfig
> b/configs/omapl138_lcdk_defconfig
> index ccb308b..0a2af11 100644
> --- a/configs/omapl138_lcdk_defconfig
> +++ b/configs/omapl138_lcdk_defconfig
> @@ -2,6 +2,7 @@ CONFIG_ARM=y
>  CONFIG_ARCH_DAVINCI=y
>  CONFIG_SYS_TEXT_BASE=0xc1080000
>  CONFIG_TARGET_OMAPL138_LCDK=y
> +CONFIG_SYS_DA850_PLL0_POSTDIV=0
>  CONFIG_SYS_DA850_PLL1_PLLDIV3=0x8003
>  CONFIG_TI_COMMON_CMD_OPTIONS=y
>  CONFIG_SPL_LIBCOMMON_SUPPORT=y
> diff --git a/include/configs/omapl138_lcdk.h
> b/include/configs/omapl138_lcdk.h
> index ea7bdf1..1e1c66b 100644
> --- a/include/configs/omapl138_lcdk.h
> +++ b/include/configs/omapl138_lcdk.h
> @@ -57,7 +57,8 @@
>   * PLL configuration
>   */
>  
> -#define CONFIG_SYS_DA850_PLL0_PLLM     37
> +/* Requires CONFIG_SYS_DA850_PLL0_POSTDIV=0, set in Kconfig */
> +#define CONFIG_SYS_DA850_PLL0_PLLM     18
>  #define CONFIG_SYS_DA850_PLL1_PLLM     21
>  
>  /*
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180318/cb95ef12/attachment.sig>

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency
  2018-03-16 15:45       ` David Lechner
@ 2018-03-18  4:21         ` Peter Howard
  2018-03-18  4:22         ` Peter Howard
  1 sibling, 0 replies; 20+ messages in thread
From: Peter Howard @ 2018-03-18  4:21 UTC (permalink / raw)
  To: u-boot

On Fri, 2018-03-16 at 10:45 -0500, David Lechner wrote:
> On 03/16/2018 04:26 AM, Sekhar Nori wrote:
> > On Thursday 15 March 2018 08:02 PM, David Lechner wrote:
> > > 
> > > Thanks for the tips. I've actually done exactly that (using my
> > > own SD
> > > card).
> > > 
> > > However, these changes affect the u-boot SPL image only. I was
> > > able to put
> > > the regular u-boot.ais on the SD card, but I'm having troubling
> > > figuring
> > > out how to install the SPL image.
> > 
> > Err, I thought u-boot.ais is SPL and U-Boot images concatenated
> > together. Anyway, I was able to test your change.
> 
> I have no idea. :-)
> 
> I've been trying to follow the TI wiki pages, but they are rather
> inconsistent
> so I am having trouble figuring out what is correct and what is not.
> 
> [1] seems to be pretty good, but it doesn't have any board-specific
> information
> or information about installing U-Boot on the SD card. [2] Says to
> flash the
> NAND. [3] says to `sudo dd in=u-boot.ais of=/dev/sdx seek=10` and to
> "Flash the
> SPL AIS file into SPI flash" and to use some `tools/uflash/uflash`
> for the SD
> card that I never found. [4] says to `sudo dd if=u-boot-omapl138-
> lcdk.ais
> of=/dev/sd<N> seek=117 bs=512 conv=fsync`, which I did with my u-
> boot.bin, but
> I doesn't explain how to actually boot from this.

Note - the generated u-boot.ais and u-boot.bin are different images. 
As Sekhar said, u-boot.ais is u-boot.bin + the SPL bit (which for the
L138 is AIS code).  In an earlier reply, I mentioned HexAIS_OMAP-
L138.exe.  For a long time you had to use that (or the Windows-only GUI
program) to add the AIS initialistion code to u-boot.bin.  Now the SPL
section of u-boot does that, with u-boot.ais being the result.

If you put just the .bin file there, then the processor is going to
come up, look for an AIS "script", fail to find it, and give up.



> 
> [1]: http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Lo
> ading_Utility_for_OMAP-L138
> [2]: http://processors.wiki.ti.com/index.php/L138/C6748_Development_K
> it_(LCDK)#Procedure_to_Flash_and_boot_the_LCDK
> [3]: http://processors.wiki.ti.com/index.php/OMAP-L138_Preparing_SD_C
> ard_for_Boot
> [4]: http://processors.wiki.ti.com/index.php/Processor_SDK_Linux_crea
> te_SD_card_script
> 
> 
> > 
> > Tested-by: Sekhar Nori <nsekhar@ti.com>
> > 
> > Thanks,
> > Sekhar
> > 
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180318/ddb9d46d/attachment.sig>

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency
  2018-03-16 15:45       ` David Lechner
  2018-03-18  4:21         ` Peter Howard
@ 2018-03-18  4:22         ` Peter Howard
  1 sibling, 0 replies; 20+ messages in thread
From: Peter Howard @ 2018-03-18  4:22 UTC (permalink / raw)
  To: u-boot

On Fri, 2018-03-16 at 10:45 -0500, David Lechner wrote:
> On 03/16/2018 04:26 AM, Sekhar Nori wrote:
> > On Thursday 15 March 2018 08:02 PM, David Lechner wrote:
> > > 
> > > Thanks for the tips. I've actually done exactly that (using my
> > > own SD
> > > card).
> > > 
> > > However, these changes affect the u-boot SPL image only. I was
> > > able to put
> > > the regular u-boot.ais on the SD card, but I'm having troubling
> > > figuring
> > > out how to install the SPL image.
> > 
> > Err, I thought u-boot.ais is SPL and U-Boot images concatenated
> > together. Anyway, I was able to test your change.
> 
> I have no idea. :-)
> 
> I've been trying to follow the TI wiki pages, but they are rather
> inconsistent
> so I am having trouble figuring out what is correct and what is not.
> 
> [1] seems to be pretty good, but it doesn't have any board-specific
> information
> or information about installing U-Boot on the SD card. [2] Says to
> flash the
> NAND. [3] says to `sudo dd in=u-boot.ais of=/dev/sdx seek=10` and to
> "Flash the
> SPL AIS file into SPI flash" and to use some `tools/uflash/uflash`
> for the SD
> card that I never found. [4] says to `sudo dd if=u-boot-omapl138-
> lcdk.ais
> of=/dev/sd<N> seek=117 bs=512 conv=fsync`, which I did with my u-
> boot.bin, but
> I doesn't explain how to actually boot from this.

Note - the generated u-boot.ais and u-boot.bin are different images. 
As Sekhar said, u-boot.ais is u-boot.bin + the SPL bit (which for the
L138 is AIS code).  In an earlier reply, I mentioned HexAIS_OMAP-
L138.exe.  For a long time you had to use that (or the Windows-only GUI
program) to add the AIS initialistion code to u-boot.bin.  Now the SPL
section of u-boot does that, with u-boot.ais being the result.

If you put just the .bin file there, then the processor is going to
come up, look for an AIS "script", fail to find it, and give up.



> 
> [1]: http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Lo
> ading_Utility_for_OMAP-L138
> [2]: http://processors.wiki.ti.com/index.php/L138/C6748_Development_K
> it_(LCDK)#Procedure_to_Flash_and_boot_the_LCDK
> [3]: http://processors.wiki.ti.com/index.php/OMAP-L138_Preparing_SD_C
> ard_for_Boot
> [4]: http://processors.wiki.ti.com/index.php/Processor_SDK_Linux_crea
> te_SD_card_script
> 
> 
> > 
> > Tested-by: Sekhar Nori <nsekhar@ti.com>
> > 
> > Thanks,
> > Sekhar
> > 
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
-- 
Peter Howard <pjh@northern-ridge.com.au>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180318/08f5474e/attachment.sig>

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency
  2018-03-16 15:56   ` David Lechner
@ 2018-03-18 18:26     ` Mike Looijmans
  0 siblings, 0 replies; 20+ messages in thread
From: Mike Looijmans @ 2018-03-18 18:26 UTC (permalink / raw)
  To: u-boot

On 16-03-18 16:56, David Lechner wrote:
> On 03/16/2018 01:26 AM, Mike Looijmans wrote:
>>
>> On 15-03-18 02:36, David Lechner wrote:
>>> commit 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0 frequency")
>>> changed the PLL0 frequency to 456MHz, which is needed for the LCDC IP
>>> block. However, in doing so, it caused the PLLOUT clock to be outside
>>> of the allowable specifications given in the OMAP-L138 data sheet. (It
>>> says PLLOUT must be 600MHz max). It also uses a PLLM value outside of
>>> the range given in the TRM (it says PLLM must in the range 0 to 0x1f).
>>>
>>> So here is what we have currently:
>>>
>>> PLLOUT = 24 / (0 + 1) * (37 + 1) = 912MHz (out of spec)
>>>           ^     ^         ^
>>>         CLKIN PREDIV    PLLM (out of spec)
>>>
>>> input to PLLDIVn = 912 / (1 + 1) = 456MHz (desired result)
>>>                      ^     ^
>>>                   PLLOUT POSTDIV
>>>
>>> This changes the PLLM value to 18 and the POSTDIV value to 0 so that
>>> PLLOUT is now within specification but we still get the desired
>>> result.
>>>
>>> PLLOUT = 24 / (0 + 1) * (18 + 1) = 456MHz (within spec)
>>>           ^     ^         ^
>>>         CLKIN PREDIV     PLLM
>>>
>>> input to PLLDIVn = 456 / (0 + 1) = 456MHz (desired result)
>>>                      ^     ^
>>>                   PLLOUT POSTDIV
>>>
>>
>> These are indeed the correct settings for 456MHz operation, I've used 
>> them in an L138 device a few years ago.
>>
>> Did you also increase the CPU voltage to 1.3V? This can be done 
>> writing to the I2C power management chip, in my stone age setup I had 
>> this piece of code to do that:
>>
>> #define TPS6507X_I2C_ADDR    0x48
>> #define TPS6507X_REG_DEFLDO2    0x17
>> u8 buf = 0x17;
>> i2c_write(TPS6507X_I2C_ADDR, TPS6507X_REG_DEFLDO2, 1, &buf, 1)
>>
>> Without the voltage change, some batches of CPUs will fail to boot 
>> properly at 456MHz.
> 
> 
> I was wondering about this, but it looks to me like the LCDK board (at 
> least the A7E
> revision) has a fixed regulator at 1.3V (TPS650250RHBR). Perhaps you are 
> using a
> different board?

Yeah, the board was based on the DA850 which has an adjustable 
regulator. The L138 can run at lower voltage on lower frequencies, which 
makes for nice power savings (down to 1V at 96MHz if I recall 
correctly), so on a board defaulting to 375MHz the voltage would likely 
be 1v2 instead.

Just wanted to give you a headstart, as it took us quite a while to 
figure out why some chips would boot fine and others would not...

-- 
Mike Looijmans

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [U-Boot] davinci: omapl138_lcdk: fix PLL0 frequency
  2018-03-15  1:36 [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency David Lechner
                   ` (3 preceding siblings ...)
  2018-03-18  4:12 ` Peter Howard
@ 2018-03-22 20:35 ` Tom Rini
  4 siblings, 0 replies; 20+ messages in thread
From: Tom Rini @ 2018-03-22 20:35 UTC (permalink / raw)
  To: u-boot

On Wed, Mar 14, 2018 at 08:36:30PM -0500, David Lechner wrote:

> commit 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0 frequency")
> changed the PLL0 frequency to 456MHz, which is needed for the LCDC IP
> block. However, in doing so, it caused the PLLOUT clock to be outside
> of the allowable specifications given in the OMAP-L138 data sheet. (It
> says PLLOUT must be 600MHz max). It also uses a PLLM value outside of
> the range given in the TRM (it says PLLM must in the range 0 to 0x1f).
> 
> So here is what we have currently:
> 
> PLLOUT = 24 / (0 + 1) * (37 + 1) = 912MHz (out of spec)
>          ^     ^         ^
>        CLKIN PREDIV    PLLM (out of spec)
> 
> input to PLLDIVn = 912 / (1 + 1) = 456MHz (desired result)
>                     ^     ^
>                  PLLOUT POSTDIV
> 
> This changes the PLLM value to 18 and the POSTDIV value to 0 so that
> PLLOUT is now within specification but we still get the desired
> result.
> 
> PLLOUT = 24 / (0 + 1) * (18 + 1) = 456MHz (within spec)
>          ^     ^         ^
>        CLKIN PREDIV     PLLM
> 
> input to PLLDIVn = 456 / (0 + 1) = 456MHz (desired result)
>                     ^     ^
>                  PLLOUT POSTDIV
> 
> Fixes: 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0 frequency")
> Signed-off-by: David Lechner <david@lechnology.com>
> Reported-by: Sekhar Nori <nsekhar@ti.com>
> Tested-by: Sekhar Nori <nsekhar@ti.com>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180322/74182e42/attachment.sig>

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2018-03-22 20:35 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-03-15  1:36 [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency David Lechner
2018-03-15 10:39 ` Peter Howard
2018-03-15 12:34 ` Sekhar Nori
2018-03-15 13:42   ` Sekhar Nori
2018-03-15 14:31     ` Sekhar Nori
2018-03-15 14:56       ` Tom Rini
2018-03-15 15:02         ` David Lechner
2018-03-16  8:04           ` Sekhar Nori
2018-03-15 15:01       ` Lokesh Vutla
2018-03-16  7:51         ` Sekhar Nori
2018-03-15 14:32   ` David Lechner
2018-03-16  9:26     ` Sekhar Nori
2018-03-16 15:45       ` David Lechner
2018-03-18  4:21         ` Peter Howard
2018-03-18  4:22         ` Peter Howard
2018-03-16  6:26 ` Mike Looijmans
2018-03-16 15:56   ` David Lechner
2018-03-18 18:26     ` Mike Looijmans
2018-03-18  4:12 ` Peter Howard
2018-03-22 20:35 ` [U-Boot] " Tom Rini

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox