davinci: omapl138_lcdk: fix PLL0 frequency

PATCH In review David Lechner 7 participants 20 messages Mar 15, 2018 – Mar 22, 2018

Subsystems (3)

Arm (32-bit) Arm sub-architectures TI DaVinci machine support

lore

Share & tools

lore

David Lechner

author

2018-03-15 01:36 UTC #0 lore raw

PATCH 1/1 davinci: omapl138_lcdk: fix PLL0 frequency

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 <[email protected]>

---

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(-)

configs/omapl138_lcdk_defconfig +1 -0

index ccb308b..0a2af11 100644
@@ -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

include/configs/omapl138_lcdk.h +2 -1

index ea7bdf1..1e1c66b 100644
@@ -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
 
 /*

Signature · 1 line

2.7.4

Peter Howard

2018-03-15 10:39 UTC #1 lore raw

PATCH 1/1 davinci: omapl138_lcdk: fix PLL0 frequency

Quoted 43 lines · David Lechner

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 <[email protected]>
---
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:

Quoted 8 lines

   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

(As I don't have anything set up on NAND the cycling is to be expected)

Quoted 40 lines

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(-)

configs/omapl138_lcdk_defconfig +1 -0

index ccb308b..0a2af11 100644
@@ -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

include/configs/omapl138_lcdk.h +2 -1

index ea7bdf1..1e1c66b 100644
@@ -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
 
 /*

Signature · 10 lines

Peter Howard <[email protected]>

(also <[email protected]>)
-------------- 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>

Sekhar Nori

2018-03-15 12:34 UTC #2 lore raw

PATCH 1/1 davinci: omapl138_lcdk: fix PLL0 frequency

In reply to David Lechner

Hi David,

Quoted 25 lines · David Lechner

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

Quoted 6 lines

input to PLLDIVn = 456 / (0 + 1) = 456MHz (desired result)
                    ^     ^
                 PLLOUT POSTDIV
Fixes 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0 frequency")
Signed-off-by David Lechner <[email protected]>

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

Quoted 11 lines

---
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

Sekhar Nori

2018-03-15 13:42 UTC #3 lore raw

PATCH 1/1 davinci: omapl138_lcdk: fix PLL0 frequency

Quoted 2 lines · Sekhar Nori

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 ###

Sekhar Nori

2018-03-15 14:31 UTC #4 lore raw

PATCH 1/1 davinci: omapl138_lcdk: fix PLL0 frequency

Quoted 8 lines · Sekhar Nori

Quoted 2 lines · Sekhar Nori
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

Quoted 33 lines

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 ###

Tom Rini

2018-03-15 14:56 UTC #5 lore raw

PATCH 1/1 davinci: omapl138_lcdk: fix PLL0 frequency

Quoted 8 lines · Sekhar Nori

Quoted 7 lines · Sekhar Nori
Quoted 2 lines · Sekhar Nori
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].

Quoted 7 lines

Quoted 1 line
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!

Signature · 8 lines

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>

David Lechner

author

2018-03-15 15:02 UTC #6 lore raw

PATCH 1/1 davinci: omapl138_lcdk: fix PLL0 frequency

Quoted 11 lines · Tom Rini

Quoted 10 lines · Sekhar Nori
Quoted 8 lines · Sekhar Nori
Quoted 2 lines · Sekhar Nori
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.

Quoted 9 lines

Quoted 5 lines
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.

Sekhar Nori

2018-03-16 08:04 UTC #7 lore raw

PATCH 1/1 davinci: omapl138_lcdk: fix PLL0 frequency

Quoted 39 lines · David Lechner

Quoted 11 lines · Tom Rini
Quoted 10 lines · Sekhar Nori
Quoted 8 lines · Sekhar Nori
Quoted 2 lines · Sekhar Nori
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.
Quoted 9 lines
Quoted 5 lines
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:
(quoted diff) +12 -0
+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

Quoted 7 lines

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

Lokesh Vutla

2018-03-15 15:01 UTC #8 lore raw

PATCH 1/1 davinci: omapl138_lcdk: fix PLL0 frequency

In reply to Sekhar Nori

Quoted 8 lines · Sekhar Nori

Quoted 7 lines · Sekhar Nori
Quoted 2 lines · Sekhar Nori
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].

Quoted 7 lines

Quoted 1 line
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?

arch/arm/mach-davinci/Kconfig +1 -0

index 30752839a3..5e7baba3fe 100644
@@ -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

Sekhar Nori

2018-03-16 07:51 UTC #9 lore raw

PATCH 1/1 davinci: omapl138_lcdk: fix PLL0 frequency

Quoted 27 lines · Lokesh Vutla

Quoted 8 lines · Sekhar Nori
Quoted 7 lines · Sekhar Nori
Quoted 2 lines · Sekhar Nori
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].
Quoted 7 lines
Quoted 1 line
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?
arch/arm/mach-davinci/Kconfig +0 -0
index 30752839a3..5e7baba3fe 100644

arch/arm/mach-davinci/Kconfig config SOC_DA850 · line 61

Quoted 4 lines

arch/arm/mach-davinci/Kconfig +1 -0

@@ -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 <[email protected]>

Tested-by Sekhar Nori <[email protected]>

Thanks,
Sekhar

David Lechner

author

2018-03-15 14:32 UTC #10 lore raw

PATCH 1/1 davinci: omapl138_lcdk: fix PLL0 frequency

In reply to Sekhar Nori

Quoted 57 lines · Sekhar Nori

Hi David,
Quoted 25 lines · David Lechner
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
Quoted 6 lines
input to PLLDIVn = 456 / (0 + 1) = 456MHz (desired result)
                     ^     ^
                  PLLOUT POSTDIV
Fixes 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0 frequency")
Signed-off-by David Lechner <[email protected]>
Thanks for the patch and great description. It looks correct to me. Hopefully I can provide some testing feedback too soon.
Quoted 11 lines
---
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.

Quoted 6 lines

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.

Sekhar Nori

2018-03-16 09:26 UTC #11 lore raw

PATCH 1/1 davinci: omapl138_lcdk: fix PLL0 frequency

Quoted 7 lines · David Lechner

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 <[email protected]>

Thanks,
Sekhar

David Lechner

author

2018-03-16 15:45 UTC #12 lore raw

PATCH 1/1 davinci: omapl138_lcdk: fix PLL0 frequency

Quoted 11 lines · Sekhar Nori

Quoted 7 lines · David Lechner
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

Quoted 6 lines

Tested-by Sekhar Nori <[email protected]>
Thanks,
Sekhar

Peter Howard

2018-03-18 04:21 UTC #13 lore raw

PATCH 1/1 davinci: omapl138_lcdk: fix PLL0 frequency

Quoted 22 lines · David Lechner

Quoted 6 lines · Sekhar Nori
Quoted 5 lines · David Lechner
Thanks for the tips. I've actually done exactly that (using my own SD
card).
Quoted 8 lines
Quoted 5 lines
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.

Quoted 13 lines

[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.

Quoted 14 lines

[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
Quoted 3 lines
Tested-by Sekhar Nori <[email protected]>

Quoted 8 lines

Quoted 3 lines
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>

Peter Howard

2018-03-18 04:22 UTC #14 lore raw

PATCH 1/1 davinci: omapl138_lcdk: fix PLL0 frequency

In reply to David Lechner

Quoted 22 lines · David Lechner

Quoted 6 lines · Sekhar Nori
Quoted 5 lines · David Lechner
Thanks for the tips. I've actually done exactly that (using my own SD
card).
Quoted 8 lines
Quoted 5 lines
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.

Quoted 13 lines

[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.

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.

Quoted 22 lines

[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
Quoted 6 lines
Tested-by Sekhar Nori <[email protected]>
Thanks,
Sekhar
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot

Signature · 8 lines

Peter Howard <[email protected]>
-------------- 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>

Mike Looijmans

2018-03-16 06:26 UTC #15 lore raw

PATCH 1/1 davinci: omapl138_lcdk: fix PLL0 frequency

In reply to David Lechner

Quoted 21 lines · David Lechner

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.

Quoted 8 lines

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.

Quoted 42 lines

Fixes 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0 frequency")
Signed-off-by David Lechner <[email protected]>
---
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(-)
configs/omapl138_lcdk_defconfig +1 -0
index ccb308b..0a2af11 100644
@@ -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
include/configs/omapl138_lcdk.h +0 -0
index ea7bdf1..1e1c66b 100644

include/configs/omapl138_lcdk.h line 64

Quoted 9 lines

include/configs/omapl138_lcdk.h +2 -1

@@ -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

David Lechner

author

2018-03-16 15:56 UTC #16 lore raw

PATCH 1/1 davinci: omapl138_lcdk: fix PLL0 frequency

Quoted 34 lines · Mike Looijmans

Quoted 21 lines · David Lechner
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.
Quoted 8 lines
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.

Quoted 8 lines

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?

Mike Looijmans

2018-03-18 18:26 UTC #17 lore raw

PATCH 1/1 davinci: omapl138_lcdk: fix PLL0 frequency

Quoted 49 lines · David Lechner

Quoted 39 lines · Mike Looijmans
Quoted 21 lines · David Lechner
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.
Quoted 8 lines
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:
Quoted 7 lines
#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.

Quoted 5 lines

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...

Signature · 1 line

Mike Looijmans

Peter Howard

2018-03-18 04:12 UTC #18 lore raw

PATCH 1/1 davinci: omapl138_lcdk: fix PLL0 frequency

In reply to David Lechner

Quoted 43 lines · David Lechner

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 <[email protected]>
---
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:

Quoted 8 lines

   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.

Quoted 3 lines

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.

Quoted 28 lines

[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(-)

configs/omapl138_lcdk_defconfig +1 -0

index ccb308b..0a2af11 100644
@@ -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

include/configs/omapl138_lcdk.h +0 -0

index ea7bdf1..1e1c66b 100644

include/configs/omapl138_lcdk.h line 64

Quoted 9 lines

include/configs/omapl138_lcdk.h +2 -1

@@ -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
 
 /*

Tom Rini

2018-03-22 20:35 UTC #19 lore raw

In reply to David Lechner

Quoted 25 lines · David Lechner

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

Quoted 8 lines

input to PLLDIVn = 456 / (0 + 1) = 456MHz (desired result)
                    ^     ^
                 PLLOUT POSTDIV
Fixes 1601dd97edc6 ("davinci: omapl138_lcdk: increase PLL0 frequency")
Signed-off-by David Lechner <[email protected]>
Reported-by Sekhar Nori <[email protected]>
Tested-by Sekhar Nori <[email protected]>

Applied to u-boot/master, thanks!

Signature · 8 lines

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>