[U-Boot] [PATCH] 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 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_Utilit...
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
/*
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.
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
/*
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_c...
Prepare an SD card for boot:
$ sudo dd if=u-boot.ais of=/dev/sd<N> seek=117 bs=512 conv=fsync
Thanks, Sekhar
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 ###
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 ###
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!
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.
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
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
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
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_c...
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.
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
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_Utilit... [2]: http://processors.wiki.ti.com/index.php/L138/C6748_Development_Kit_(LCDK)#Pr... [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_s...
Tested-by: Sekhar Nori nsekhar@ti.com
Thanks, Sekhar
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.
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@lists.denx.de https://lists.denx.de/listinfo/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.
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@lists.denx.de https://lists.denx.de/listinfo/u-boot
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.
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@topicproducts.com Website: www.topicproducts.com
Please consider the environment before printing this e-mail
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?
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...
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.
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
/*
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!
participants (7)
-
David Lechner -
Lokesh Vutla -
Mike Looijmans -
Peter Howard -
Peter Howard -
Sekhar Nori -
Tom Rini