Re: OMAP L138 LCDK - giving up maintainership

[Peter Howard]

On Wed, 2019-12-18 at 18:26 +0530, Sekhar Nori wrote:
> On 18/12/19 6:15 PM, Adam Ford wrote:
> > On Tue, Dec 17, 2019 at 5:15 PM Peter Howard <
> > p...@northern-ridge.com.au> wrote:
> > > Tom and others,
> > > 
> > > I finish at my current job on Friday, as such I will have no
> > > immediate
> > > involvement with the L138 chip (not that I've had that much in
> > > recent
> > > times).  So it makes sense to remove me as
> > > maintainer.  Especially as
> > > the email listed for me will start bouncing.  so is the simplest
> > > way
> > 
> > Best wishes in the new endeavors.
> > 
> > > just to submit a patch clearing out the maintainer entry in
> > > board/davinci/da8xxevm/MAINTAINERS ?  Also does anyone on the
> > > list wish
> > > to take over?  Adam, I know you don't have the time from recent
> > > emails.
> > 
> > Because my employer views the LCDK as the replacement to the
> > product
> > they made (da850-evm), I don't think they would take kindly to me
> > being the maintainer of it.  I have been helping where can I to try
> > and unify those two devices as much as I can, because I think there
> > is
> > value in sharing as many of the resources as possible.  I have an
> > LCDK, and I will continue to help where I can.
> > 
> > > Bartosz?  Sekhar - do you want to nominate someone from TI?
> 
> Lokesh from TI has been a prolific U-Boot contributor. Has access to
> LCDK board. I just requested him to take up LCDK maintainership and
> he
> agreed.

Can I assume that he will submit a the patch to change over to him?

> 
> Thanks,
> Sekhar
-- 
Peter Howard 


signature.asc
Description: This is a digitally signed message part

OMAP L138 LCDK - giving up maintainership

[Peter Howard]

Tom and others,

I finish at my current job on Friday, as such I will have no immediate
involvement with the L138 chip (not that I've had that much in recent
times).  So it makes sense to remove me as maintainer.  Especially as
the email listed for me will start bouncing.  so is the simplest way
just to submit a patch clearing out the maintainer entry in
board/davinci/da8xxevm/MAINTAINERS ?  Also does anyone on the list wish
to take over?  Adam, I know you don't have the time from recent emails.
Bartosz?  Sekhar - do you want to nominate someone from TI?


-- 
Peter Howard 
Peter Howard 


signature.asc
Description: This is a digitally signed message part

Re: [U-Boot] [PATCH v4 2/5] omap: mmc: Avoid using libfdt with of-platdata

[Peter Howard]

On Thu, 2019-11-07 at 15:05 -0500, Tom Rini wrote:
> On Thu, Nov 07, 2019 at 08:53:09AM -0700, Simon Glass wrote:
> 
> > At present this driver is enabled in SPL on omapl138_lcdk, which
> > uses
> > of-platdata. The driver needs to be ported to use of-platdata
> > properly.
> > For now, avoid a build error by returning an error.
> > 
> > Signed-off-by: Simon Glass 
> > 
> > ---
> > 
> > Changes in v4:
> > - Add new patch for omap MMC build errors
> > 
> > Changes in v3: None
> > 
> >  drivers/mmc/davinci_mmc.c | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/drivers/mmc/davinci_mmc.c b/drivers/mmc/davinci_mmc.c
> > index 0d63279db0..79a7f50d25 100644
> > --- a/drivers/mmc/davinci_mmc.c
> > +++ b/drivers/mmc/davinci_mmc.c
> > @@ -507,6 +507,12 @@ static int davinci_mmc_probe(struct udevice
> > *dev)
> > priv->version = data->version;
> > }
> >  
> > +   /* FIXME: Cannot read from device tree with of-platdata */
> > +   if (CONFIG_IS_ENABLED(OF_PLATDATA)) {
> > +   printf("Please fix this driver to use of-platdata");
> > +   return -ENOSYS;
> > +   }
> > +
> > priv->reg_base = (struct davinci_mmc_regs *)dev_read_addr(dev);
> > priv->input_clk = clk_get(DAVINCI_MMCSD_CLKID);
> 
> Let me add the board maintainer here.

Re-replying (and not from %&$! Outlook)  after having a look at the
situation.

>   Peter, are we even using MMC in SPL on the omapl138_lcdk?  

The OMAP L138 LCDK can boot from MMC - so the MMC driver is used inthe
SPL. However, going back over the patches from this year, MMC usage was
broken back in July - refer https://patchwork.ozlabs.org/patch/1138200/
 
Bartosz is working on this but has hit problems.

Given that MMC access in the SPL is effectively broken right now, I
don't see that _this_ patch makes things any worse, so if this is the
only problem with the series I'd let it go through.  Bartosz, Adam:
Given you were discussing this at almost the same time Tom sent his
email, do you have any problem with this patch being applied.  If we
solve the overall problem with the davinci driver, adding the platdata
is trivial.

Peter

> If so, I believe we need to add platdata ala
> other platforms like board/ti/am335x/board.c for example.  Thanks!
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot


signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/2] ARM: davinci: SPL: fix BSS initialization

[Peter Howard]

Sorry about the double-send on this one - sent first time from off-list 
email addr.

On Thu, 2019-05-30 at 19:04 +0530, Sekhar Nori wrote:
> U-Boot README recommends initializing SDRAM in board_init_f(). DA850
> was doing it as part of board_init_r() (through call to
> spl_board_init()
> which calls arch_cpu_init() which calls da850_ddr_setup())
> 
> This worked fine till commit 15b8c7505819 ("davinci:
> da850evm/omapl138-lcdk: Move BSS to SDRAM because SRAM is full")
> moved
> BSS to SDRAM.
> 
> Functions like mmc_initialize() called in board_init_r() assume BSS
> is
> available. Since SDRAM was not initialized when arch/arm/lib/crt0.S
> tried
> to initialize BSS to 0, BSS is not initialized correctly.
> 
> Fix this by simply calling arch_cpu_init() from board_init_f(). Also
> move
> preloader_console_init() there to help debug issues with
> board_init_r().
> 
> With this spl_board_init() is no longer needed, we remove it.
> 
> Tested using MMC/SD boot on OMAP-L138 LCDK board.
> 
> Tested-by: Adam Ford  #da850evm

Tested-by: Peter Howard  #omapl138_lcdk

> Signed-off-by: Sekhar Nori 
> ---
>  arch/arm/mach-davinci/spl.c   | 5 -
>  configs/da850_am18xxevm_defconfig | 1 -
>  configs/da850evm_defconfig| 1 -
>  configs/da850evm_nand_defconfig   | 1 -
>  configs/ipam390_defconfig | 1 -
>  configs/omapl138_lcdk_defconfig   | 1 -
>  6 files changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/spl.c b/arch/arm/mach-
> davinci/spl.c
> index 103639e34757..be3daa9bc02d 100644
> --- a/arch/arm/mach-davinci/spl.c
> +++ b/arch/arm/mach-davinci/spl.c
> @@ -31,9 +31,12 @@ void putc(char c)
>  }
>  #endif /* CONFIG_SPL_LIBCOMMON_SUPPORT */
>  
> -void spl_board_init(void)
> +void board_init_f(ulong dummy)
>  {
>   arch_cpu_init();
> +
> + spl_early_init();
> +
>   preloader_console_init();
>  }
>  
> diff --git a/configs/da850_am18xxevm_defconfig
> b/configs/da850_am18xxevm_defconfig
> index f09822211312..7ecdc361ce85 100644
> --- a/configs/da850_am18xxevm_defconfig
> +++ b/configs/da850_am18xxevm_defconfig
> @@ -20,7 +20,6 @@ CONFIG_VERSION_VARIABLE=y
>  # CONFIG_DISPLAY_BOARDINFO is not set
>  CONFIG_BOARD_EARLY_INIT_F=y
>  CONFIG_SPL_TEXT_BASE=0x8000
> -CONFIG_SPL_BOARD_INIT=y
>  CONFIG_SPL_SPI_LOAD=y
>  CONFIG_HUSH_PARSER=y
>  CONFIG_SYS_PROMPT="U-Boot > "
> diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig
> index 8c16d5c4f5a7..c09505828255 100644
> --- a/configs/da850evm_defconfig
> +++ b/configs/da850evm_defconfig
> @@ -21,7 +21,6 @@ CONFIG_VERSION_VARIABLE=y
>  # CONFIG_DISPLAY_BOARDINFO is not set
>  CONFIG_BOARD_EARLY_INIT_F=y
>  CONFIG_SPL_TEXT_BASE=0x8000
> -CONFIG_SPL_BOARD_INIT=y
>  CONFIG_SPL_SYS_MALLOC_SIMPLE=y
>  CONFIG_SPL_SEPARATE_BSS=y
>  CONFIG_SPL_SPI_LOAD=y
> diff --git a/configs/da850evm_nand_defconfig
> b/configs/da850evm_nand_defconfig
> index b8eac0e65995..727101634679 100644
> --- a/configs/da850evm_nand_defconfig
> +++ b/configs/da850evm_nand_defconfig
> @@ -19,7 +19,6 @@ CONFIG_VERSION_VARIABLE=y
>  # CONFIG_DISPLAY_BOARDINFO is not set
>  CONFIG_BOARD_EARLY_INIT_F=y
>  CONFIG_SPL_TEXT_BASE=0x8000
> -CONFIG_SPL_BOARD_INIT=y
>  CONFIG_SPL_SYS_MALLOC_SIMPLE=y
>  CONFIG_SPL_SEPARATE_BSS=y
>  CONFIG_SPL_NAND_SUPPORT=y
> diff --git a/configs/ipam390_defconfig b/configs/ipam390_defconfig
> index f2270264bda4..88a0d971ef28 100644
> --- a/configs/ipam390_defconfig
> +++ b/configs/ipam390_defconfig
> @@ -14,7 +14,6 @@ CONFIG_VERSION_VARIABLE=y
>  # CONFIG_DISPLAY_BOARDINFO is not set
>  CONFIG_BOARD_EARLY_INIT_F=y
>  CONFIG_SPL_TEXT_BASE=0x8000
> -CONFIG_SPL_BOARD_INIT=y
>  CONFIG_SPL_NAND_SUPPORT=y
>  CONFIG_SPL_OS_BOOT=y
>  CONFIG_HUSH_PARSER=y
> diff --git a/configs/omapl138_lcdk_defconfig
> b/configs/omapl138_lcdk_defconfig
> index e43141844a10..48f251ebb804 100644
> --- a/configs/omapl138_lcdk_defconfig
> +++ b/configs/omapl138_lcdk_defconfig
> @@ -18,7 +18,6 @@ CONFIG_VERSION_VARIABLE=y
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_BOARD_EARLY_INIT_F=y
>  CONFIG_SPL_TEXT_BASE=0x8000
> -CONFIG_SPL_BOARD_INIT=y
>  CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0xb5
>  CONFIG_SPL_NAND_SUPPORT=y
>  CONFIG_HUSH_PARSER=y

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/2] ARM: davinci: omal138_lcdk: fix MMC boot breakage due to driver model conversion

[Peter Howard]

On Thu, 2019-05-30 at 19:04 +0530, Sekhar Nori wrote:
> commit 21af33ed0319 ("ARM: davinci: omapl138_lcdk: Enable DM_MMC")
> wanted to enable DM_MMC only for U-Boot and not for SPL.
> 
> But CONFIG_DM_MMC is defined for SPL build too. Because of this
> MMC device was not getting registered for SPL causing MMC/SD
> boot breakage.
> 
> Instead use CONFIG_IS_ENABLED(DM_MMC) which will remain false until
> CONFIG_SPL_DM_MMC is defined.
> 
> Tested-by: Adam Ford  #da850evm

Tested-by: Peter Howard  #omapl138_lcdk

> Signed-off-by: Sekhar Nori 
> ---
>  board/davinci/da8xxevm/omapl138_lcdk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c
> b/board/davinci/da8xxevm/omapl138_lcdk.c
> index 2c2f885d43e4..fe1bf4410145 100644
> --- a/board/davinci/da8xxevm/omapl138_lcdk.c
> +++ b/board/davinci/da8xxevm/omapl138_lcdk.c
> @@ -353,7 +353,7 @@ int misc_init_r(void)
>   return 0;
>  }
>  
> -#ifndef CONFIG_DM_MMC
> +#if !CONFIG_IS_ENABLED(DM_MMC)
>  #ifdef CONFIG_MMC_DAVINCI
>  static struct davinci_mmc mmc_sd0 = {
>   .reg_base = (struct davinci_mmc_regs *)DAVINCI_MMC_SD0_BASE,

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/2] ARM: davinci: omapl138_lcdk: fix MMC/SD boot breakage

[Peter Howard]

On Thu, 2019-05-30 at 19:04 +0530, Sekhar Nori wrote:
> Hi,
> 
> Here is a set of patches that fixes MMC/SD boot breakage introduced
> after 2018.09 release.
> 
> This was tested with MMC/SD boot on OMAP-L138 LCDK.
> 
> Peter,
> 
> I dropped your Tested-by: because the patches changed. It will be
> great
> to get your testing done again.

Just re-tested.  Seems to be working fine for me on LCDK both NAND and
MMC/SD.

> 
> v3:
> Add call to spl_early_init() in 2/2 to take of DA850 EVM which uses
> device-tree in SPL.
> 
> v2:
> Move console init to board_init_f() and drop spl_board_init() as its
> not needed anymore.
> 
> Thanks,
> Sekhar
> 
> Sekhar Nori (2):
>   ARM: davinci: omal138_lcdk: fix MMC boot breakage due to driver
> model
> conversion
>   ARM: davinci: SPL: fix BSS initialization
> 
>  arch/arm/mach-davinci/spl.c| 5 -
>  board/davinci/da8xxevm/omapl138_lcdk.c | 2 +-
>  configs/da850_am18xxevm_defconfig  | 1 -
>  configs/da850evm_defconfig | 1 -
>  configs/da850evm_nand_defconfig| 1 -
>  configs/ipam390_defconfig  | 1 -
>  configs/omapl138_lcdk_defconfig| 1 -
>  7 files changed, 5 insertions(+), 7 deletions(-)
> 

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] ARM: davinci: SPL: fix BSS initialization

[Peter Howard]

On Tue, 2019-05-21 at 20:39 +0530, Sekhar Nori wrote:
> U-Boot README recommends initializing SDRAM in board_init_f(). DA850
> was doing it as part of board_init_r() (through call to
> spl_board_init()
> which calls arch_cpu_init() which calls da850_ddr_setup())
> 
> This worked fine till commit 15b8c7505819 ("davinci:
> da850evm/omapl138-lcdk: Move BSS to SDRAM because SRAM is full")
> moved
> BSS to SDRAM.
> 
> Functions like mmc_initialize() called in board_init_r() assume BSS
> is
> available. Since SDRAM was not initialized when arch/arm/lib/crt0.S
> tried
> to initialize BSS to 0, BSS is not initialized correctly.
> 
> Fix this by simply calling arch_cpu_init() from board_init_f(). Since
> the
> README recommends calling preloader_console_init() from
> spl_board_init(),
> we keep it as-it-is.
> 
> Tested using MMC/SD boot on OMAP-L138 LCDK board.
> 
> Signed-off-by: Sekhar Nori 

Tested-by: Peter Howard 

> ---
>  arch/arm/mach-davinci/spl.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-davinci/spl.c b/arch/arm/mach-
> davinci/spl.c
> index 103639e34757..117b5ee836f8 100644
> --- a/arch/arm/mach-davinci/spl.c
> +++ b/arch/arm/mach-davinci/spl.c
> @@ -33,10 +33,14 @@ void putc(char c)
>  
>  void spl_board_init(void)
>  {
> - arch_cpu_init();
>   preloader_console_init();
>  }
>  
> +void board_init_f(ulong dummy)
> +{
> + arch_cpu_init();
> +}
> +
>  u32 spl_boot_device(void)
>  {
>   switch (davinci_syscfg_regs->bootcfg) {


signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] ARM: davinci: omal138_lcdk: fix MMC boot breakage due to driver model conversion

[Peter Howard]

On Tue, 2019-05-21 at 20:39 +0530, Sekhar Nori wrote:
> commit 21af33ed0319 ("ARM: davinci: omapl138_lcdk: Enable DM_MMC")
> wanted to enable DM_MMC only for U-Boot and not for SPL.
> 
> But CONFIG_DM_MMC is defined for SPL build too. Because of this
> MMC device was not getting registered for SPL causing MMC/SD
> boot breakage.
> 
> Instead use CONFIG_IS_ENABLED(DM_MMC) which will remain false until
> CONFIG_SPL_DM_MMC is defined.
> 
> Signed-off-by: Sekhar Nori 

Tested-by: Peter Howard 

> ---
>  board/davinci/da8xxevm/omapl138_lcdk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c
> b/board/davinci/da8xxevm/omapl138_lcdk.c
> index 2c2f885d43e4..fe1bf4410145 100644
> --- a/board/davinci/da8xxevm/omapl138_lcdk.c
> +++ b/board/davinci/da8xxevm/omapl138_lcdk.c
> @@ -353,7 +353,7 @@ int misc_init_r(void)
>   return 0;
>  }
>  
> -#ifndef CONFIG_DM_MMC
> +#if !CONFIG_IS_ENABLED(DM_MMC)
>  #ifdef CONFIG_MMC_DAVINCI
>  static struct davinci_mmc mmc_sd0 = {
>   .reg_base = (struct davinci_mmc_regs *)DAVINCI_MMC_SD0_BASE,


signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] ARM: davinci: omapl138_lcdk: fix MMC/SD boot breakage.

[Peter Howard]

Hi Sekhar

On Tue, 2019-05-21 at 20:39 +0530, Sekhar Nori wrote:
> Hi,
> 
> Here is a set of patches that fixes MMC/SD boot breakage introduced
> after 2018.09 release.
> 
> This was tested with MMC/SD boot on OMAP-L138 LCDK. I still need to
> do SPI and NAND boot on this board.
> 

I have tested NAND boot with the two patches and it seems to work fine.
I can confirm MMC boot (at least on the original LCDK)

The original LCDK didn't have SPI NAND - has that changed with the
latest board?

> Thanks,
> Sekhar
> 
> Sekhar Nori (2):
>   ARM: davinci: omal138_lcdk: fix MMC boot breakage due to driver
> model
> conversion
>   ARM: davinci: SPL: fix BSS initialization
> 
>  arch/arm/mach-davinci/spl.c| 6 +-
>  board/davinci/da8xxevm/omapl138_lcdk.c | 2 +-
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 


-- 
Peter Howard 
Peter Howard 


signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Building for ARMv5 - uint64_t alignment issues

[Peter Howard]

Dear all,

Most of my u-boot work is on one of two ARMv5 platforms.  When u-boot
changed to requiring a later gcc, I switched from my old-faithful
arago-2011.09 compiler to a newer Linaro release:

gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabi

And for my work on the da850 this seems to be fine.  However I've been
doing some work creating a nand driver for an older chip (which I
really wish I didn't have to care about, and is never going to see the
light of upstream).  Short form: inexplicable errors, which I
eventually chased down to issues around uint64_t.  Some googling turned
up this bug (and patch): 

http://lists.openembedded.org/pipermail/openembedded-core/2017-November/144043.html

So I upgraded to the next Linaro release:

gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabi

This fixed the problem in what I'll call "general" uint64_t usage, but
still left the same problem in structs.  Specifically size in struct
mdt_info.  Which I fixed by kludging 
-mstructure-size-boundary=64 into the build (which AFAIK I shouldn't
have to do).

I would hope I'm not the only person who can trigger this . . . which
means I'm hoping that no-one else has hit this (as far as I can tell
from the u-boot list) is that anyone building for ARMv5 is using a
different toolchain.  So . . . can those of you out there building for
any of the v5 boards tell me what toolchain you're currently using? 
And if you hit/fixed/worked around strd issues?

Thanks



-- 
Peter Howard 

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] MMC: davinici_mmc: Enable CD and WP with DM and OF_CONTROL

[Peter Howard]

On Thu, 2018-08-16 at 23:26 -0500, Adam Ford wrote:
> When used with a device tree, this will extract the card detect
> and write protect pins from the device tree and configure them
> accordingly.  This assumes the GPIO_ACTIVE_LOW/HIGH is supported
> byt da8xx_gpio.
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/drivers/mmc/davinci_mmc.c b/drivers/mmc/davinci_mmc.c
> index db950ea5ec..01d60f394f 100644
> --- a/drivers/mmc/davinci_mmc.c
> +++ b/drivers/mmc/davinci_mmc.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define DAVINCI_MAX_BLOCKS   (32)
>  #define WATCHDOG_COUNT   (10)
> @@ -35,6 +36,8 @@ struct davinci_mmc_priv {
>   struct davinci_mmc_regs *reg_base;  /* Register base
> address */
>   uint input_clk; /* Input clock to MMC
> controller */
>   uint version;   /* MMC Controller version */
> + struct gpio_desc cd_gpio;   /* Card Detect GPIO */
> + struct gpio_desc wp_gpio;   /* Write Protect GPIO */
>  };
>  
>  struct davinci_mmc_plat
> @@ -425,9 +428,38 @@ static const struct mmc_ops dmmc_ops = {
> .init   = dmmc_init,
>  };
>  #else
> +

The two new functions here - davinci_mmc_getcd() and
davinci_mmc_getwp() - also need to be wrapped in a check for DM_GPIO
being enabled, otherwise dm_gpio_get_value() isn't built.


> +static int davinci_mmc_getcd(struct udevice *dev)
> +{
> + struct davinci_mmc_priv *priv = dev_get_priv(dev);
> + int value;
> +
> + value = dm_gpio_get_value(>cd_gpio);
> + /* if no CD return as 1 */
> + if (value < 0)
> + return 1;
> +
> + return value;
> +}
> +
> +static int davinci_mmc_getwp(struct udevice *dev)
> +{
> + struct davinci_mmc_priv *priv = dev_get_priv(dev);
> + int value;
> +
> + value = dm_gpio_get_value(>wp_gpio);
> + /* if no WP return as 0 */
> + if (value < 0)
> + return 0;
> +
> + return value;
> +}
> +
>  static const struct dm_mmc_ops davinci_mmc_ops = {
>   .send_cmd   = davinci_mmc_send_cmd,
>   .set_ios= davinci_mmc_set_ios,
> + .get_cd = davinci_mmc_getcd,
> + .get_wp = davinci_mmc_getwp,

Again the assignment of .get_cd and .get_wp need to be wrapped in a
check for DM_GPIO.

>  };
>  #endif
>  
> @@ -475,6 +507,12 @@ static int davinci_mmc_probe(struct udevice
> *dev)
>   priv->reg_base = (struct davinci_mmc_regs
> *)dev_read_addr(dev);
>   priv->input_clk = clk_get(DAVINCI_MMCSD_CLKID);
>  
> +#if CONFIG_IS_ENABLED(DM_GPIO)
> + /* These GPIOs are optional */
> + gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio,
> GPIOD_IS_IN);
> + gpio_request_by_name(dev, "wp-gpios", 0, >wp_gpio,
> GPIOD_IS_IN);
> +#endif
> +
>   upriv->mmc = >mmc;
>  
>   return davinci_dm_mmc_init(dev);

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] MMC_DAVINCI not compliant with CONFIG_BLK

[Peter Howard]

Hi Adam,

My normal email is broken at the moment sorry for inflicting Outlook on you ☹


I've been working on this for a few weeks and at this stage I have a u-boot 
that builds.  The only problem is that introducing the DM into the SPL build 
(for NAND) currently overruns the SRAM area by 4K or so.  

If you want to have a look I'm happy to send you my changes so-far.

PJH

-Original Message-
From: Adam Ford  
Sent: Monday, 6 August 2018 10:11 PM
To: U-Boot Mailing List 
Cc: Peter Howard ; David Lechner ; 
Stefano Babic ; Heiko Schocher ; Christoph 
Rüdisser ; Manfred Rudigier 

Subject: MMC_DAVINCI not compliant with CONFIG_BLK

From what I gathered over the weekend, the MMC_DAVINCI hasn't migrated to 
DM_MMC nor does CONFIG_BLK successfully build on ARCH_DAVINCI boards that 
enable MMC_DAVINCI.

I started work to attempt to make it DM_MMC and OF_CONTROL compliant using the 
da850evm.

Before I go too far, I just want to make sure nobody else is doing this work.  
I don't want to duplicate an effort or waste time if it's been done or is in 
the works.

If someone is interesting in testing the patch when I am done, it would be very 
helpful, because I only have the da850evm.  If someone has a patch and wants me 
to test it, I would also be willing to try it.

adam

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com 
__

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] MMC_DAVINCI not compliant with CONFIG_BLK

[Peter Howard]

Sorry a clarification - my main focus is the LCDK board - it's that one which 
has the 4K overrun.

-Original Message-
From: Peter Howard 
Sent: Tuesday, 7 August 2018 8:22 AM
To: 'Adam Ford' ; U-Boot Mailing List 
Cc: David Lechner ; Stefano Babic ; Heiko 
Schocher ; Christoph Rüdisser 
; Manfred Rudigier 

Subject: RE: MMC_DAVINCI not compliant with CONFIG_BLK

Hi Adam,

My normal email is broken at the moment sorry for inflicting Outlook on you ☹


I've been working on this for a few weeks and at this stage I have a u-boot 
that builds.  The only problem is that introducing the DM into the SPL build 
(for NAND) currently overruns the SRAM area by 4K or so.  

If you want to have a look I'm happy to send you my changes so-far.

PJH

-Original Message-
From: Adam Ford  
Sent: Monday, 6 August 2018 10:11 PM
To: U-Boot Mailing List 
Cc: Peter Howard ; David Lechner ; 
Stefano Babic ; Heiko Schocher ; Christoph 
Rüdisser ; Manfred Rudigier 

Subject: MMC_DAVINCI not compliant with CONFIG_BLK

From what I gathered over the weekend, the MMC_DAVINCI hasn't migrated to 
DM_MMC nor does CONFIG_BLK successfully build on ARCH_DAVINCI boards that 
enable MMC_DAVINCI.

I started work to attempt to make it DM_MMC and OF_CONTROL compliant using the 
da850evm.

Before I go too far, I just want to make sure nobody else is doing this work.  
I don't want to duplicate an effort or waste time if it's been done or is in 
the works.

If someone is interesting in testing the patch when I am done, it would be very 
helpful, because I only have the da850evm.  If someone has a patch and wants me 
to test it, I would also be willing to try it.

adam

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com 
__

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] MMC_DAVINCI not compliant with CONFIG_BLK

[Peter Howard]

>From: Adam Ford  
>Sent: Tuesday, 7 August 2018 9:12 AM
>To: Peter Howard 
>Cc: U-Boot Mailing List ; David Lechner 
>; Stefano Babic ; Heiko Schocher 
>; Christoph Rüdisser ; 
>Manfred Rudigier 
>Subject: Re: MMC_DAVINCI not compliant with CONFIG_BLK
>
>
>> On Mon, Aug 6, 2018, 5:22 PM Peter Howard <mailto:phow...@gme.net.au> wrote:
>> Sorry a clarification - my main focus is the LCDK board - it's that one 
>> which has the 4K overrun.
>> 
>> -Original Message-
>> From: Peter Howard 
>> Sent: Tuesday, 7 August 2018 8:22 AM
>> To: 'Adam Ford' <mailto:aford...@gmail.com>; U-Boot Mailing List 
>> <mailto:u-boot@lists.denx.de>
>> Cc: David Lechner <mailto:da...@lechnology.com>; Stefano Babic 
>> <mailto:sba...@denx.de>; Heiko Schocher <mailto:h...@denx.de>; Christoph 
>> Rüdisser <mailto:christoph.ruedis...@omicronenergy.com>; Manfred Rudigier  
>> <mailto:manfred.rudig...@omicronenergy.com>
>> Subject: RE: MMC_DAVINCI not compliant with CONFIG_BLK
>>
>> Hi Adam,
>>
>> My normal email is broken at the moment sorry for inflicting Outlook on you ☹
>>
>>
>> I've been working on this for a few weeks and at this stage I have a u-boot 
>> that builds.  The only problem is that introducing the DM into the SPL build 
>> (for NAND) currently overruns the SRAM area by 4K or so.  
>>
>
> Is DM required in SPL?
>
> There are a variety of drivers with #ifdef around various parts of the code.

That's a question I'm not sure about.  However . . . MMC is enabled in the SPL. 
 So, even if DM isn't mandated, you have to either use it or maintain both the 
old and new form of the driver.  Or disable MMC.  The only other config I could 
find which definitely combines MMC in the SPL with the DM is 
configs/stm32mp15_basic_defconfig - and it uses the DM form (as far as I can 
see  - I could be wrong).

>
>
>> If you want to have a look I'm happy to send you my changes so-far.
>>
>> PJH
>>
>> -Original Message-
>> From: Adam Ford <mailto:aford...@gmail.com> 
>> Sent: Monday, 6 August 2018 10:11 PM
>> To: U-Boot Mailing List <mailto:u-boot@lists.denx.de>
>> Cc: Peter Howard <mailto:phow...@gme.net.au>; David Lechner 
>> <mailto:da...@lechnology.com>; Stefano Babic <mailto:sba...@denx.de>; Heiko 
>> Schocher <mailto:h...@denx.de>; Christoph Rüdisser 
>> <mailto:christoph.ruedis...@omicronenergy.com>;  Manfred Rudigier 
>> <mailto:manfred.rudig...@omicronenergy.com>
>> Subject: MMC_DAVINCI not compliant with CONFIG_BLK
>>
>> From what I gathered over the weekend, the MMC_DAVINCI hasn't migrated to 
>> DM_MMC nor does CONFIG_BLK successfully build on ARCH_DAVINCI boards that 
>> enable MMC_DAVINCI.
>>
>> I started work to attempt to make it DM_MMC and OF_CONTROL compliant using 
>> the da850evm.
>>
>> Before I go too far, I just want to make sure nobody else is doing this 
>> work.  I don't want to duplicate an effort or waste time if it's been done 
>> or is in the works.
>>
>> If someone is interesting in testing the patch when I am done, it would be 
>> very helpful, because I only have the da850evm.  If someone has a patch and 
>> wants me to test it, I would also be willing to try it.
>>
>> adam




__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency

[Peter Howard]

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 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 
> > 
> > Thanks,
> > Sekhar
> > 
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency

[Peter Howard]

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 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 <nsek...@ti.com>
> > 
> > Thanks,
> > Sekhar
> > 
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
-- 
Peter Howard <p...@northern-ridge.com.au>

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency

[Peter Howard]

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 PREDIVPLLM (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 
> ---
> 
> 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=0xc108
>  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
>  
>  /*

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] davinci: omapl138_lcdk: fix PLL0 frequency

[Peter Howard]

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 PREDIVPLLM (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 <da...@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=0xc108
>  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 <p...@northern-ridge.com.au>

(also <phow...@gme.net.au>)

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v5 11/11] configs: omapl138_lcdk: decrease the loglevel to reduce the size of the SPL

[Peter Howard]

On Thu, 2017-11-30 at 11:55 -0500, Tom Rini wrote:
> On Thu, Nov 30, 2017 at 05:44:04PM +0100, Jean-Jacques Hiblot wrote:
> 
> > The changes in the MMC stack have increased its footprint up to the
> > point
> > were its breaks the generation of the SPL for this platform.
> > Fix this by reducing the loglevel.
> > 
> > Signed-off-by: Jean-Jacques Hiblot <jjhib...@ti.com>
> > ---
> > 
> > new patch that takes adavntage of "mmc: convert most of printf() to
> > pr_err()
> > and pr_warn()" to reduce the size of the SPL.
> > WIthout this patch the SPL is too big and the build breaks.
> > 
> >  configs/omapl138_lcdk_defconfig | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/configs/omapl138_lcdk_defconfig
> > b/configs/omapl138_lcdk_defconfig
> > index 8d6b12f..0d4506e 100644
> > --- a/configs/omapl138_lcdk_defconfig
> > +++ b/configs/omapl138_lcdk_defconfig
> > @@ -8,6 +8,7 @@ CONFIG_SPL_MMC_SUPPORT=y
> >  CONFIG_SPL_SERIAL_SUPPORT=y
> >  CONFIG_SPL_NAND_SUPPORT=y
> >  CONFIG_BOOTDELAY=3
> > +CONFIG_LOGLEVEL=3
> >  CONFIG_VERSION_VARIABLE=y
> >  # CONFIG_DISPLAY_CPUINFO is not set
> >  # CONFIG_DISPLAY_BOARDINFO is not set
> 
> Peter?  Thanks!

Sorry, missed it first time.  Fine by me.

Reviewed-by: Peter Howard <phow...@gme.net.au>

> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] ARM: davinci: da850: Enable Caches for DA850-EVM

[Peter Howard]

On Sun, 2017-08-27 at 17:39 -0500, Adam Ford wrote:
> What starting up the DA850-EVM, U-Boot generates a warning:
>    WARNING: Caches not enabled
> 
> Looking at other arm926 processors, this is an attempt
> to enable the caches and remove the warning.
> 
> I am notsure who the proper TI or ARM people are to review this.
> 
> Signed-off-by: Adam Ford <aford...@gmail.com>
> ---
>  board/davinci/da8xxevm/da850evm.c | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/board/davinci/da8xxevm/da850evm.c
> b/board/davinci/da8xxevm/da850evm.c
> index c2d2e8e..33a923c 100644
> --- a/board/davinci/da8xxevm/da850evm.c
> +++ b/board/davinci/da8xxevm/da850evm.c
> @@ -491,3 +491,29 @@ int board_eth_init(bd_t *bis)
>   return 0;
>  }
>  #endif /* CONFIG_DRIVER_TI_EMAC */
> +
> +#ifndef CONFIG_SYS_ICACHE_OFF
> +/* Invalidate entire I-cache and branch predictor array */
> +void invalidate_icache_all(void)
> +{
> + unsigned long i = 0;
> +
> + asm ("mcr p15, 0, %0, c7, c5, 0" : : "r" (i));
> +}
> +#else
> +void invalidate_icache_all(void)
> +{
> +}
> +#endif
> +
> +#ifndef CONFIG_SYS_DCACHE_OFF
> +void enable_caches(void)
> +{
> + /* Enable D-cache. I-cache is already enabled in start.S */
> + dcache_enable();
> +}
> +#else
> +void enable_caches(void)
> +{
> +}
> +#endif /* CONFIG_SYS_DCACHE_OFF */

My 2c on this would be:

1) If it's going to be for the davinci specifically, I'd do it the same
way as for the at91 - i.e. under mach-davinci/arm926ejs

2) Is there any good reason _not_ to add it to
arch/arm/cpu/arm926ejs/cache.c rather than per-board?  Given it's a
feature of the arm core rather than anything specific to the davinci it
would make sense to me.



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

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] davinci: omapl138_lcdk: use correct AIS config

[Peter Howard]

On Thu, 2016-11-17 at 17:19 -0500, Tom Rini wrote:
>   Error verifying signature: gpg: Fatal: can't create directory
> '/home/phoward/.gnupg': File exists
> On Wed, Nov 16, 2016 at 05:33:33PM +0100, Fabien Parent wrote:
> 
> > 
> > The AIS image built for the OMAPL138-LCDK board is not booting
> > because
> > the AIS configuration is not correct.
> > This commit adds a AIS configuration file that allow the SPL to
> > boot
> > correctly.
> > 
> > Signed-off-by: Fabien Parent <fpar...@baylibre.com>
> 
> Reviewed-by: Tom Rini <tr...@konsulko.com>

Given these changes, can you modify/remove
board/davinci/da8xxevm/README.omapl138-lcdk please?


-- 
Peter Howard <p...@northern-ridge.com.au>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Env var initrd_high - logic reversed in check?

[Peter Howard]

Hi all,

I've been trying to stop my initrd being relocated duing a bootm
process, and ended up at this bit of code in common/image.c (starting
line 1135):


if ((s = getenv("initrd_high")) != NULL) {
/* a value of "no" or a similar string will act like 0,
 * turning the "load high" feature off. This is intentional.
 */
initrd_high = simple_strtoul(s, NULL, 16);
if (initrd_high == ~0)
initrd_copy_to_ram = 0;
} else {
initrd_high = getenv_bootm_mapsize() + getenv_bootm_low();
}

The check - "if (initrd_high == ~0)" seems wrong - based on the comment
an value of "no" for initrd_high gets interpreted as 0.  But the test
is effectively for 0x (or 0x).   Assuming the
comment is correct, shouldn't the check be against 0 rather than ~0 ?

Thanks


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


signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] Fix to davinci_nand.h to place CEnCFG registers at correct

[Peter Howard]

Signed-off-by: Peter Howard <phow...@gme.net.au>
---
 arch/arm/include/asm/ti-common/davinci_nand.h | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/ti-common/davinci_nand.h b/arch/arm/include/as
m/ti-common/davinci_nand.h
index 11407be..f343ac2 100644
--- a/arch/arm/include/asm/ti-common/davinci_nand.h
+++ b/arch/arm/include/asm/ti-common/davinci_nand.h
@@ -35,10 +35,12 @@ struct davinci_emif_regs {uint32_tsdrcr;
union {
uint32_t abncr[4];
-   uint32_t ab1cr;
-   uint32_t ab2cr;
-   uint32_t ab3cr;
-   uint32_t ab4cr;
+   struct {
+   uint32_t ab1cr;
+   uint32_t ab2cr;
+   uint32_t ab3cr;
+   uint32_t ab4cr;
+   };
};
uint32_tsdtimr;
uint32_tddrsr;
-- 
1.9.1

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] davinci: restore CONFIG_SPL=y to configs/omapl138_lcdk_defconfig

[Peter Howard]

Signed-off-by: Peter Howard phow...@gme.net.au
---
 configs/omapl138_lcdk_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/omapl138_lcdk_defconfig b/configs/omapl138_lcdk_defconfig
index 8f19721..4445c38 100644
--- a/configs/omapl138_lcdk_defconfig
+++ b/configs/omapl138_lcdk_defconfig
@@ -1,3 +1,4 @@
+CONFIG_SPL=y
 CONFIG_ARM=y
 CONFIG_ARCH_DAVINCI=y
 CONFIG_TARGET_OMAPL138_LCDK=y
-- 
1.9.3


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] davinci: add support for omapl138-lcdk board

[Peter Howard]

Signed-off-by: Peter Howard phow...@gme.net.au
---
 arch/arm/include/asm/mach-types.h   |   1 +
 arch/arm/mach-davinci/Kconfig   |   4 +
 board/davinci/da8xxevm/Kconfig  |  13 +
 board/davinci/da8xxevm/MAINTAINERS  |   6 +
 board/davinci/da8xxevm/Makefile |   1 +
 board/davinci/da8xxevm/README.omapl138-lcdk |  28 ++
 board/davinci/da8xxevm/omapl138_lcdk.c  | 383 
 configs/omapl138_lcdk_defconfig |   4 +
 include/configs/omapl138_lcdk.h | 330 
 9 files changed, 770 insertions(+)
 create mode 100644 board/davinci/da8xxevm/README.omapl138-lcdk
 create mode 100644 board/davinci/da8xxevm/omapl138_lcdk.c
 create mode 100644 configs/omapl138_lcdk_defconfig
 create mode 100644 include/configs/omapl138_lcdk.h

diff --git a/arch/arm/include/asm/mach-types.h 
b/arch/arm/include/asm/mach-types.h
index d4a447b..46a34e8 100644
--- a/arch/arm/include/asm/mach-types.h
+++ b/arch/arm/include/asm/mach-types.h
@@ -1108,6 +1108,7 @@ extern unsigned int __machine_arch_type;
 #define MACH_TYPE_KZM9G4140
 #define MACH_TYPE_COLIBRI_T30  4493
 #define MACH_TYPE_APALIS_T30   4513
+#define MACH_TYPE_OMAPL138_LCDK2495
 
 #ifdef CONFIG_ARCH_EBSA110
 # ifdef machine_arch_type
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 6827721..3ef55d3 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -21,6 +21,10 @@ config TARGET_CAM_ENC_4XX
bool CAM ENC 4xx board
select SUPPORT_SPL
 
+config TARGET_OMAPL138_LCDK
+   bool OMAPL138 LCDK
+   select SUPPORT_SPL
+
 config TARGET_DAVINCI_DM355EVM
bool DM355 EVM board
 
diff --git a/board/davinci/da8xxevm/Kconfig b/board/davinci/da8xxevm/Kconfig
index 1108e4b..33bfcc3 100644
--- a/board/davinci/da8xxevm/Kconfig
+++ b/board/davinci/da8xxevm/Kconfig
@@ -23,3 +23,16 @@ config SYS_CONFIG_NAME
default da850evm
 
 endif
+
+if TARGET_OMAPL138_LCDK
+
+config SYS_BOARD
+   default da8xxevm
+
+config SYS_VENDOR
+   default davinci
+
+config SYS_CONFIG_NAME
+   default omapl138_lcdk
+
+endif
diff --git a/board/davinci/da8xxevm/MAINTAINERS 
b/board/davinci/da8xxevm/MAINTAINERS
index 10c4e2f..f32ce66 100644
--- a/board/davinci/da8xxevm/MAINTAINERS
+++ b/board/davinci/da8xxevm/MAINTAINERS
@@ -12,3 +12,9 @@ F:include/configs/da850evm.h
 F: configs/da850_am18xxevm_defconfig
 F: configs/da850evm_defconfig
 F: configs/da850evm_direct_nor_defconfig
+
+OMAPL138_LCDK BOARD
+M: Peter Howard phow...@gme.net.au
+S: Maintained
+F: include/configs/omap1l38_lcdk.h
+F: configs/omapl138_lcdk_defconfig
diff --git a/board/davinci/da8xxevm/Makefile b/board/davinci/da8xxevm/Makefile
index 4da509b..93e1f1d 100644
--- a/board/davinci/da8xxevm/Makefile
+++ b/board/davinci/da8xxevm/Makefile
@@ -9,3 +9,4 @@
 
 obj-$(CONFIG_MACH_DAVINCI_DA830_EVM)   += da830evm.o
 obj-$(CONFIG_MACH_DAVINCI_DA850_EVM)   += da850evm.o
+obj-$(CONFIG_MACH_OMAPL138_LCDK) += omapl138_lcdk.o
diff --git a/board/davinci/da8xxevm/README.omapl138-lcdk 
b/board/davinci/da8xxevm/README.omapl138-lcdk
new file mode 100644
index 000..ea0c53d
--- /dev/null
+++ b/board/davinci/da8xxevm/README.omapl138-lcdk
@@ -0,0 +1,28 @@
+Summary
+===
+This README assumes you have read README.da850.  It contains some additional
+information specific to building the omapl138-lcdk.  The AIS file as generated
+by the build is, currently, not useable due to differences in the flash
+available on this board, as compared to the da850evm boards.
+
+Flash Differences
+=
+Refer to the discussion in [1] for more detail - basically the da850evm uses
+SPI flash whereas the lcdk uses NAND flash to store the bootloader, and
+the support isn't there in the SPL code.
+
+It should be possible to add the support in the SPL code should someone be
+sufficiently motivated.
+
+Using the built image
+=
+The output image to use is u-boot.bin.  This needs to be converted to an
+AIS file as described in [1] and then flashed using the utitilty linked to
+there and also described in README.da850.  You _may_ be able to write using
+u-boot itself, but the commands in README.da850 won't work as they write to
+SPI rather than NAND.
+
+Links
+=
+[1]
+ http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/386829
\ No newline at end of file
diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c 
b/board/davinci/da8xxevm/omapl138_lcdk.c
new file mode 100644
index 000..2c9d0e8
--- /dev/null
+++ b/board/davinci/da8xxevm/omapl138_lcdk.c
@@ -0,0 +1,383 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Based on da850evm.c. Original Copyrights follow:
+ *
+ * Copyright (C) 2009 Nick Thompson, GE Fanuc, Ltd. nick.thomp...@gefanuc.com
+ * Copyright (C) 2007 Sergey Kubushyn k...@koi8.net
+ *
+ * This program is free

[U-Boot] davinci: LCDK board

[Peter Howard]

I have a build of u-boot for the TI LCDK (the successor to the
Hawkboard).  It is based on:
  * The LCDK code TI supplied against 2012.04.01
  * The now-departed Hawkboard build in mainline prior to 2015.04
  * The current da850evm build.

It is built against the generic board framework.  It works well enough
for me the way I want to use it (conversion post-build with a TI utility
for flashing into NAND), but I haven't tried any of the other options
yet (e.g. booting off SD).  I'd like to get it into mainline; my
question is what is the best way from where I am?  Just post the patch
as it is to the list?  Find someone else to play with off list (any
volunteers?).  Go through more of the target options first?

Thanks,

-- 
Peter Howard p...@northern-ridge.com.au

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] da850evm: Use generic board and libfdt, fix size for SPI flash

[Peter Howard]

On Fri, 2014-12-19 at 12:14 +0530, Jagan Teki wrote:
 On 19 December 2014 at 02:54, Peter Howard p...@northern-ridge.com.au wrote:
  On Thu, 2014-12-18 at 12:33 +0530, Jagan Teki wrote:
  On 17 December 2014 at 06:44, Peter Howard p...@northern-ridge.com.au 
  wrote:
   Add defines to use CONFIG_SYS_GENERIC_BOARD and CONFIG_OF_LIBFDT.
   Semi-separate to this: the size of the image for the da850evm has
   increased to the point that the size in da850evm.h and the offset for
   the environment in SPI flash no longer work.  They are modified to
   account for the larger image size.
  
   Signed-off-by: Peter Howard phow...@gme.net.au
   ---
include/configs/da850evm.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
  
   diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
   index e5f8afe..e5a612c 100644
   --- a/include/configs/da850evm.h
   +++ b/include/configs/da850evm.h
   @@ -157,7 +157,7 @@
#define CONFIG_SPL_SPI_FLASH_SUPPORT
#define CONFIG_SPL_SPI_LOAD
#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x8000
   -#define CONFIG_SYS_SPI_U_BOOT_SIZE 0x3
   +#define CONFIG_SYS_SPI_U_BOOT_SIZE 0x4
#endif
  
/*
   @@ -251,7 +251,7 @@
#undef CONFIG_ENV_IS_IN_NAND
#define CONFIG_ENV_IS_IN_SPI_FLASH
#define CONFIG_ENV_SIZE(64  10)
   -#define CONFIG_ENV_OFFSET  (256  10)
   +#define CONFIG_ENV_OFFSET  (512  10)
 
  Please make sure the proper testing of this new flash env size.
 
 
  What sort of testing were you thinking of?  I've confirmed that it
  basically works (i.e. saving/loading/editing+save) - env size is 64K,
  SPI is 8MB and offset is only 512K in, so it fits.  u-boot image size is
  ~260K so there's plenty of room before the env.
 
 Looks fine to me, but we have some recent changes in sf which we published
 on master 5 days back - did you test on top of that?
 

If you're referring to commits 54ba653ab63b31c8f5405fb0ee9dfba05cbb1521,
74c2cee4e82bb71953267e87900e279ab5aa1dc3,
b648742a17c16639976ac5b38f246cb0f7d41da5, and
6dd6e90e13acc4014634d78fc469e7e82eefc255, then yes I tested on top of
those.

 
  Is there something more you wanted?
 
  Thanks.
 
  Reviewed-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
 
#define CONFIG_ENV_SECT_SIZE   (64  10)
#define CONFIG_SYS_NO_FLASH
#endif
   @@ -259,6 +259,7 @@
/*
 * U-Boot general configuration
 */
   +#define CONFIG_SYS_GENERIC_BOARD
#define CONFIG_MISC_INIT_R
#define CONFIG_BOARD_EARLY_INIT_F
#define CONFIG_BOOTFILEuImage /* Boot file name */
   @@ -275,6 +276,7 @@
#define CONFIG_SYS_LONGHELP
#define CONFIG_CRC32_VERIFY
#define CONFIG_MX_CYCLIC
   +#define CONFIG_OF_LIBFDT
  
/*
 * Linux Information
   --
   1.9.3
 
 thanks!


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH RFT 2/2] davinci: Do not duplicate setting of gd

[Peter Howard]

On Fri, 2014-12-19 at 16:53 -0500, Tom Rini wrote:
 In f0c3a6c we stopped setting gd in board_init_f, but later had to
 revert to due problems on certain platforms.  As davinci does not look
 to have these problems, we can drop the setting here and rely upon
 crt0.S to do it.
 
 Cc: Peter Howard p...@northern-ridge.com.au
 Signed-off-by: Tom Rini tr...@ti.com
 
 ---
 Peter, I don't have my davinci board hooked up but since you were doing
 some changes recently is there a chance you can test this easily?
 Thanks!

Applied this patch (with and without 1/1 as well - given part 1 is ARMv7
it shouldn't have any bearing on davinci but wanted to be sure).

U-boot doesn't boot on the da850evm with this change.  I tried both with
my changes to the generic board, and on a fresh clone of u-boot.git. And
on u-boot-ti.git.  I haven't looked further, but I'm guessing there is
early access to gd of the sort you patched out for v7.

 ---
  arch/arm/cpu/arm926ejs/davinci/spl.c |1 -
  1 file changed, 1 deletion(-)
 
 diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c 
 b/arch/arm/cpu/arm926ejs/davinci/spl.c
 index 59b304e..7b14420 100644
 --- a/arch/arm/cpu/arm926ejs/davinci/spl.c
 +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
 @@ -51,7 +51,6 @@ void board_init_f(ulong dummy)
   memset(__bss_start, 0, __bss_end - __bss_start);
  
   /* Finally, setup gd and move to the next step. */
 - gd = gdata;
   board_init_r(NULL, 0);
  }
  

-- 
Peter Howard p...@northern-ridge.com.au

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH RFT 2/2] davinci: Do not duplicate setting of gd

[Peter Howard]

On Fri, 2014-12-19 at 16:53 -0500, Tom Rini wrote:
 In f0c3a6c we stopped setting gd in board_init_f, but later had to
 revert to due problems on certain platforms.  As davinci does not look
 to have these problems, we can drop the setting here and rely upon
 crt0.S to do it.
 
 Cc: Peter Howard p...@northern-ridge.com.au
 Signed-off-by: Tom Rini tr...@ti.com
 
 ---
 Peter, I don't have my davinci board hooked up but since you were doing
 some changes recently is there a chance you can test this easily?

I can test on Monday - I only have access to my LCDK on the weekend, and
I have to get round to try the convoluted setup process for flashing
u-boot on it :-)

 Thanks!
 ---
  arch/arm/cpu/arm926ejs/davinci/spl.c |1 -
  1 file changed, 1 deletion(-)
 
 diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c 
 b/arch/arm/cpu/arm926ejs/davinci/spl.c
 index 59b304e..7b14420 100644
 --- a/arch/arm/cpu/arm926ejs/davinci/spl.c
 +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
 @@ -51,7 +51,6 @@ void board_init_f(ulong dummy)
   memset(__bss_start, 0, __bss_end - __bss_start);
  
   /* Finally, setup gd and move to the next step. */
 - gd = gdata;
   board_init_r(NULL, 0);
  }
  


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] da850evm: Use generic board and libfdt, fix size for SPI flash

[Peter Howard]

On Thu, 2014-12-18 at 12:33 +0530, Jagan Teki wrote:
 On 17 December 2014 at 06:44, Peter Howard p...@northern-ridge.com.au wrote:
  Add defines to use CONFIG_SYS_GENERIC_BOARD and CONFIG_OF_LIBFDT.
  Semi-separate to this: the size of the image for the da850evm has
  increased to the point that the size in da850evm.h and the offset for
  the environment in SPI flash no longer work.  They are modified to
  account for the larger image size.
 
  Signed-off-by: Peter Howard phow...@gme.net.au
  ---
   include/configs/da850evm.h | 6 --
   1 file changed, 4 insertions(+), 2 deletions(-)
 
  diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
  index e5f8afe..e5a612c 100644
  --- a/include/configs/da850evm.h
  +++ b/include/configs/da850evm.h
  @@ -157,7 +157,7 @@
   #define CONFIG_SPL_SPI_FLASH_SUPPORT
   #define CONFIG_SPL_SPI_LOAD
   #define CONFIG_SYS_SPI_U_BOOT_OFFS 0x8000
  -#define CONFIG_SYS_SPI_U_BOOT_SIZE 0x3
  +#define CONFIG_SYS_SPI_U_BOOT_SIZE 0x4
   #endif
 
   /*
  @@ -251,7 +251,7 @@
   #undef CONFIG_ENV_IS_IN_NAND
   #define CONFIG_ENV_IS_IN_SPI_FLASH
   #define CONFIG_ENV_SIZE(64  10)
  -#define CONFIG_ENV_OFFSET  (256  10)
  +#define CONFIG_ENV_OFFSET  (512  10)
 
 Please make sure the proper testing of this new flash env size.
 

What sort of testing were you thinking of?  I've confirmed that it
basically works (i.e. saving/loading/editing+save) - env size is 64K,
SPI is 8MB and offset is only 512K in, so it fits.  u-boot image size is
~260K so there's plenty of room before the env.

Is there something more you wanted?  

Thanks.

 Reviewed-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
 
   #define CONFIG_ENV_SECT_SIZE   (64  10)
   #define CONFIG_SYS_NO_FLASH
   #endif
  @@ -259,6 +259,7 @@
   /*
* U-Boot general configuration
*/
  +#define CONFIG_SYS_GENERIC_BOARD
   #define CONFIG_MISC_INIT_R
   #define CONFIG_BOARD_EARLY_INIT_F
   #define CONFIG_BOOTFILEuImage /* Boot file name */
  @@ -275,6 +276,7 @@
   #define CONFIG_SYS_LONGHELP
   #define CONFIG_CRC32_VERIFY
   #define CONFIG_MX_CYCLIC
  +#define CONFIG_OF_LIBFDT
 
   /*
* Linux Information
  --
  1.9.3
 
 
 thanks!

-- 
Peter Howard p...@northern-ridge.com.au

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem converting da850evm to generic board and use libfdt

[Peter Howard]

On Tue, 2014-12-16 at 17:27 +1100, Peter Howard wrote:
 On Wed, 2014-12-10 at 19:10 -0700, Simon Glass wrote:
  Hi Peter,
  
  On 10 December 2014 at 18:37, Simon Glass s...@chromium.org wrote:
   Hi Peter,
  
   On Dec 10, 2014 6:23 PM, Peter Howard p...@northern-ridge.com.au 
   wrote:
  
   On Wed, 2014-12-10 at 17:49 -0700, Simon Glass wrote:
Hi Peter,
   
On 10 December 2014 at 17:19, Peter Howard p...@northern-ridge.com.au
wrote:
 On Wed, 2014-12-10 at 15:43 -0700, Simon Glass wrote:
 Hi Peter,

 On 10 December 2014 at 15:17, Peter Howard
 p...@northern-ridge.com.au wrote:
 
  On Tue, 2014-12-09 at 17:45 -0700, Simon Glass wrote:
   Hi Peter,
  
   On 9 December 2014 at 17:13, Peter Howard
   p...@northern-ridge.com.au wrote:
   
On Wed, 2014-12-03 at 14:20 -0800, Simon Glass wrote:
 Hi Peter,

 On 3 December 2014 at 13:53, Peter Howard
 p...@northern-ridge.com.au wrote:
  On Wed, 2014-12-03 at 06:38 -0700, Simon Glass wrote:
  Hi Peter,
 
  On 2 December 2014 at 14:59, Peter Howard
  p...@northern-ridge.com.au wrote:
  
   I'm trying to make two changes to building u-boot for
   the da850evm.
 * Use the generic board code to get rid of the
   warning, and
 * Enable libfdt to allow booting of linux with a
   standalone dtb
   image.
  
   The first part appears to be simple.  Just adding
  
   #define CONFIG_SYS_GENERIC_BOARD
  
   in include/configs/da850evm.h works with no obvious
   side-effects.
  
   However, adding
  
   #define CONFIG_OF_LIBFDT
  
   is a different story.  It appears to introduce memory
   corruption when
   loading the environment.  On first boot it gives the
   bad CRC! warning
   and uses the default environment.  If you *don't* save
   the environment
   you can boot fine (including manual editing of the
   environment). However
   if you save the environment via saveenv bad things
   happen on the next
   boot.  An example log:
  
   U-Boot SPL 2015.01-rc1 (Nov 27 2014 - 14:30:26)
  
  
   U-Boot 2015.01-rc1 (Nov 27 2014 - 14:30:26)
  
   I2C:   ready
   DRAM:  64 MiB
   WARNING: Caches not enabled
   MMC:   davinci: 0
   SF: Detected M25P64 with page size 256 Bytes, erase 
   size
   64 KiB, total 8 MiB
   In:serial
   Out:   serial
   Err:   serial
   SF: Detected M25P64 with page size 256 Bytes, erase 
   size
   64 KiB, total 8 MiB
   Warning: Invalid MAC address read from SPI flash
   Net:   DaVinci-EMAC
   Error: DaVinci-EMAC address not set.
  
   U-Boot  help
   data abort
   pc : [c108ffd8]  lr : [c10900b4]
   sp : c3e5f838  ip :  fp : c3e5fda4
   r10: c10b1f28  r9 : c3e5ff08 r8 : 000e
   r7 : c10b22c4  r6 : c10aa2a0 r5 :   r4 :
   001b
   r3 : c10b8f70  r2 : 0001 r1 : c3e5f840  r0 :
   
   Flags: Nzcv  IRQs off  FIQs off  Mode SVC_32
   Resetting CPU ...
  
   If I rebuild  with CONFIG_OF_LIBFDT removed again from
   da850evm.h the
   problem disappears.  And you can see that the saveenv
   worked (i.e. the
   environment is what was saved before the reboot and 
   data
   abort).
  
   I've traced the problem as far as the inline version of
   console_puts()
   in common/console.c.  The table dispatch there and the
   fact that the
   problem appears only when you load the environment 
   makes
   me think it's
   memory corruption.
  
   Note: if you do *not* specify CONFIG_SYS_GENERIC_BOARD
   you still get the
   data abort, however it takes a bit more effort to
   trigger (like actually
   looking at the environment :-)  )
  
   (Note: This is building against the u-boot-2015.01-rc1
   tree)
  
   Suggestions?
 
  In case it helps, I got the same symptom (help crashes)
  and it was due
  to BSS not being cleared. Stefan (on cc) found this
  problem - he said
  something to do with GDT calculation or handling. However
  it is just a
  guess and probably has nothing to do with your issue.
 
  I may be missing something, but the GDT appears to be
  x86-specific
  whereas I'm building for ARMv5

[U-Boot] [PATCH] da850evm: Use generic board and libfdt, fix size for SPI flash

[Peter Howard]

Add defines to use CONFIG_SYS_GENERIC_BOARD and CONFIG_OF_LIBFDT.
Semi-separate to this: the size of the image for the da850evm has
increased to the point that the size in da850evm.h and the offset for
the environment in SPI flash no longer work.  They are modified to
account for the larger image size.

Signed-off-by: Peter Howard phow...@gme.net.au
---
 include/configs/da850evm.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index e5f8afe..e5a612c 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -157,7 +157,7 @@
 #define CONFIG_SPL_SPI_FLASH_SUPPORT
 #define CONFIG_SPL_SPI_LOAD
 #define CONFIG_SYS_SPI_U_BOOT_OFFS 0x8000
-#define CONFIG_SYS_SPI_U_BOOT_SIZE 0x3
+#define CONFIG_SYS_SPI_U_BOOT_SIZE 0x4
 #endif
 
 /*
@@ -251,7 +251,7 @@
 #undef CONFIG_ENV_IS_IN_NAND
 #define CONFIG_ENV_IS_IN_SPI_FLASH
 #define CONFIG_ENV_SIZE(64  10)
-#define CONFIG_ENV_OFFSET  (256  10)
+#define CONFIG_ENV_OFFSET  (512  10)
 #define CONFIG_ENV_SECT_SIZE   (64  10)
 #define CONFIG_SYS_NO_FLASH
 #endif
@@ -259,6 +259,7 @@
 /*
  * U-Boot general configuration
  */
+#define CONFIG_SYS_GENERIC_BOARD
 #define CONFIG_MISC_INIT_R
 #define CONFIG_BOARD_EARLY_INIT_F
 #define CONFIG_BOOTFILEuImage /* Boot file name */
@@ -275,6 +276,7 @@
 #define CONFIG_SYS_LONGHELP
 #define CONFIG_CRC32_VERIFY
 #define CONFIG_MX_CYCLIC
+#define CONFIG_OF_LIBFDT
 
 /*
  * Linux Information
-- 
1.9.3


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem converting da850evm to generic board and use libfdt

[Peter Howard]

On Wed, 2014-12-10 at 19:10 -0700, Simon Glass wrote:
 Hi Peter,
 
 On 10 December 2014 at 18:37, Simon Glass s...@chromium.org wrote:
  Hi Peter,
 
  On Dec 10, 2014 6:23 PM, Peter Howard p...@northern-ridge.com.au wrote:
 
  On Wed, 2014-12-10 at 17:49 -0700, Simon Glass wrote:
   Hi Peter,
  
   On 10 December 2014 at 17:19, Peter Howard p...@northern-ridge.com.au
   wrote:
On Wed, 2014-12-10 at 15:43 -0700, Simon Glass wrote:
Hi Peter,
   
On 10 December 2014 at 15:17, Peter Howard
p...@northern-ridge.com.au wrote:

 On Tue, 2014-12-09 at 17:45 -0700, Simon Glass wrote:
  Hi Peter,
 
  On 9 December 2014 at 17:13, Peter Howard
  p...@northern-ridge.com.au wrote:
  
   On Wed, 2014-12-03 at 14:20 -0800, Simon Glass wrote:
Hi Peter,
   
On 3 December 2014 at 13:53, Peter Howard
p...@northern-ridge.com.au wrote:
 On Wed, 2014-12-03 at 06:38 -0700, Simon Glass wrote:
 Hi Peter,

 On 2 December 2014 at 14:59, Peter Howard
 p...@northern-ridge.com.au wrote:
 
  I'm trying to make two changes to building u-boot for
  the da850evm.
* Use the generic board code to get rid of the
  warning, and
* Enable libfdt to allow booting of linux with a
  standalone dtb
  image.
 
  The first part appears to be simple.  Just adding
 
  #define CONFIG_SYS_GENERIC_BOARD
 
  in include/configs/da850evm.h works with no obvious
  side-effects.
 
  However, adding
 
  #define CONFIG_OF_LIBFDT
 
  is a different story.  It appears to introduce memory
  corruption when
  loading the environment.  On first boot it gives the
  bad CRC! warning
  and uses the default environment.  If you *don't* save
  the environment
  you can boot fine (including manual editing of the
  environment). However
  if you save the environment via saveenv bad things
  happen on the next
  boot.  An example log:
 
  U-Boot SPL 2015.01-rc1 (Nov 27 2014 - 14:30:26)
 
 
  U-Boot 2015.01-rc1 (Nov 27 2014 - 14:30:26)
 
  I2C:   ready
  DRAM:  64 MiB
  WARNING: Caches not enabled
  MMC:   davinci: 0
  SF: Detected M25P64 with page size 256 Bytes, erase size
  64 KiB, total 8 MiB
  In:serial
  Out:   serial
  Err:   serial
  SF: Detected M25P64 with page size 256 Bytes, erase size
  64 KiB, total 8 MiB
  Warning: Invalid MAC address read from SPI flash
  Net:   DaVinci-EMAC
  Error: DaVinci-EMAC address not set.
 
  U-Boot  help
  data abort
  pc : [c108ffd8]  lr : [c10900b4]
  sp : c3e5f838  ip :  fp : c3e5fda4
  r10: c10b1f28  r9 : c3e5ff08 r8 : 000e
  r7 : c10b22c4  r6 : c10aa2a0 r5 :   r4 :
  001b
  r3 : c10b8f70  r2 : 0001 r1 : c3e5f840  r0 :
  
  Flags: Nzcv  IRQs off  FIQs off  Mode SVC_32
  Resetting CPU ...
 
  If I rebuild  with CONFIG_OF_LIBFDT removed again from
  da850evm.h the
  problem disappears.  And you can see that the saveenv
  worked (i.e. the
  environment is what was saved before the reboot and data
  abort).
 
  I've traced the problem as far as the inline version of
  console_puts()
  in common/console.c.  The table dispatch there and the
  fact that the
  problem appears only when you load the environment makes
  me think it's
  memory corruption.
 
  Note: if you do *not* specify CONFIG_SYS_GENERIC_BOARD
  you still get the
  data abort, however it takes a bit more effort to
  trigger (like actually
  looking at the environment :-)  )
 
  (Note: This is building against the u-boot-2015.01-rc1
  tree)
 
  Suggestions?

 In case it helps, I got the same symptom (help crashes)
 and it was due
 to BSS not being cleared. Stefan (on cc) found this
 problem - he said
 something to do with GDT calculation or handling. However
 it is just a
 guess and probably has nothing to do with your issue.

 I may be missing something, but the GDT appears to be
 x86-specific
 whereas I'm building for ARMv5.
   
OK for some reason I thought this was PPC!
   
Maybe you can find your pc in System.map and work out where
it is
going wrong? Are you hitting some image size limit?
   
pc : [c108ffd8

Re: [U-Boot] Problem converting da850evm to generic board and use libfdt

[Peter Howard]

On Tue, 2014-12-09 at 17:45 -0700, Simon Glass wrote:
 Hi Peter,
 
 On 9 December 2014 at 17:13, Peter Howard p...@northern-ridge.com.au wrote:
 
  On Wed, 2014-12-03 at 14:20 -0800, Simon Glass wrote:
   Hi Peter,
  
   On 3 December 2014 at 13:53, Peter Howard p...@northern-ridge.com.au 
   wrote:
On Wed, 2014-12-03 at 06:38 -0700, Simon Glass wrote:
Hi Peter,
   
On 2 December 2014 at 14:59, Peter Howard p...@northern-ridge.com.au 
wrote:

 I'm trying to make two changes to building u-boot for the da850evm.
   * Use the generic board code to get rid of the warning, and
   * Enable libfdt to allow booting of linux with a standalone dtb
 image.

 The first part appears to be simple.  Just adding

 #define CONFIG_SYS_GENERIC_BOARD

 in include/configs/da850evm.h works with no obvious side-effects.

 However, adding

 #define CONFIG_OF_LIBFDT

 is a different story.  It appears to introduce memory corruption when
 loading the environment.  On first boot it gives the bad CRC! 
 warning
 and uses the default environment.  If you *don't* save the 
 environment
 you can boot fine (including manual editing of the environment). 
 However
 if you save the environment via saveenv bad things happen on the next
 boot.  An example log:

 U-Boot SPL 2015.01-rc1 (Nov 27 2014 - 14:30:26)


 U-Boot 2015.01-rc1 (Nov 27 2014 - 14:30:26)

 I2C:   ready
 DRAM:  64 MiB
 WARNING: Caches not enabled
 MMC:   davinci: 0
 SF: Detected M25P64 with page size 256 Bytes, erase size 64 KiB, 
 total 8 MiB
 In:serial
 Out:   serial
 Err:   serial
 SF: Detected M25P64 with page size 256 Bytes, erase size 64 KiB, 
 total 8 MiB
 Warning: Invalid MAC address read from SPI flash
 Net:   DaVinci-EMAC
 Error: DaVinci-EMAC address not set.

 U-Boot  help
 data abort
 pc : [c108ffd8]  lr : [c10900b4]
 sp : c3e5f838  ip :  fp : c3e5fda4
 r10: c10b1f28  r9 : c3e5ff08 r8 : 000e
 r7 : c10b22c4  r6 : c10aa2a0 r5 :   r4 : 001b
 r3 : c10b8f70  r2 : 0001 r1 : c3e5f840  r0 : 
 Flags: Nzcv  IRQs off  FIQs off  Mode SVC_32
 Resetting CPU ...

 If I rebuild  with CONFIG_OF_LIBFDT removed again from da850evm.h the
 problem disappears.  And you can see that the saveenv worked (i.e. 
 the
 environment is what was saved before the reboot and data abort).

 I've traced the problem as far as the inline version of 
 console_puts()
 in common/console.c.  The table dispatch there and the fact that the
 problem appears only when you load the environment makes me think 
 it's
 memory corruption.

 Note: if you do *not* specify CONFIG_SYS_GENERIC_BOARD you still get 
 the
 data abort, however it takes a bit more effort to trigger (like 
 actually
 looking at the environment :-)  )

 (Note: This is building against the u-boot-2015.01-rc1 tree)

 Suggestions?
   
In case it helps, I got the same symptom (help crashes) and it was due
to BSS not being cleared. Stefan (on cc) found this problem - he said
something to do with GDT calculation or handling. However it is just a
guess and probably has nothing to do with your issue.
   
I may be missing something, but the GDT appears to be x86-specific
whereas I'm building for ARMv5.
  
   OK for some reason I thought this was PPC!
  
   Maybe you can find your pc in System.map and work out where it is
   going wrong? Are you hitting some image size limit?
  
   pc : [c108ffd8]
 
 
  Sorry, been distracted on other stuff for a few days.
 
  First, I now understand the global descriptor a bit better.  For ARMv5
  It's stored in r9 and still looks sane.  The relevant info:
 
  (gdb) print/x *((gd_t *)$r9)
  $1 = {bd = 0xc3e5ffb0, flags = 0x183, baudrate = 0x1c200, cpu_clk = 0x0,
bus_clk = 0x0, pci_clk = 0x0, mem_clk = 0x0, have_console = 0x1,
env_addr = 0xc10a8fcc, env_valid = 0x1, ram_top = 0xc400,
relocaddr = 0xc3f8, ram_size = 0x400, mon_len = 0x6ffb0,
irq_sp = 0xc3e5fef0, start_addr_sp = 0xc3e5fee0, reloc_off = 0x2f0,
new_gd = 0xc3e5ff08, fdt_blob = 0x0, new_fdt = 0x0, fdt_size = 0x0,
jt = 0xc3e601c0, env_buf = {0x31, 0x31, 0x35, 0x32, 0x30, 0x30,
  0x0 repeats 26 times}, cur_i2c_bus = 0x0, timebase_h = 0x0,
timebase_l = 0x0, arch = {timer_rate_hz = 0x16e360, tbu = 0x0,
  tbl = 0x4cc62, lastinc = 0x0, timer_reset_value = 0x0,
  tlb_addr = 0xc3ff, tlb_size = 0x4000}}
 
 
  The pc is definitely bogus.  The reloc address is 0xc3f8 whereas
  that would be a pre-reloc address (starting at 0xc108).  And it's
  definitely relocated by the time of failure.  The only other bit of
  information I have right now is that adding

Re: [U-Boot] Problem converting da850evm to generic board and use libfdt

[Peter Howard]

On Wed, 2014-12-10 at 15:43 -0700, Simon Glass wrote:
 Hi Peter,
 
 On 10 December 2014 at 15:17, Peter Howard p...@northern-ridge.com.au wrote:
 
  On Tue, 2014-12-09 at 17:45 -0700, Simon Glass wrote:
   Hi Peter,
  
   On 9 December 2014 at 17:13, Peter Howard p...@northern-ridge.com.au 
   wrote:
   
On Wed, 2014-12-03 at 14:20 -0800, Simon Glass wrote:
 Hi Peter,

 On 3 December 2014 at 13:53, Peter Howard 
 p...@northern-ridge.com.au wrote:
  On Wed, 2014-12-03 at 06:38 -0700, Simon Glass wrote:
  Hi Peter,
 
  On 2 December 2014 at 14:59, Peter Howard 
  p...@northern-ridge.com.au wrote:
  
   I'm trying to make two changes to building u-boot for the 
   da850evm.
 * Use the generic board code to get rid of the warning, and
 * Enable libfdt to allow booting of linux with a 
   standalone dtb
   image.
  
   The first part appears to be simple.  Just adding
  
   #define CONFIG_SYS_GENERIC_BOARD
  
   in include/configs/da850evm.h works with no obvious side-effects.
  
   However, adding
  
   #define CONFIG_OF_LIBFDT
  
   is a different story.  It appears to introduce memory corruption 
   when
   loading the environment.  On first boot it gives the bad CRC! 
   warning
   and uses the default environment.  If you *don't* save the 
   environment
   you can boot fine (including manual editing of the environment). 
   However
   if you save the environment via saveenv bad things happen on the 
   next
   boot.  An example log:
  
   U-Boot SPL 2015.01-rc1 (Nov 27 2014 - 14:30:26)
  
  
   U-Boot 2015.01-rc1 (Nov 27 2014 - 14:30:26)
  
   I2C:   ready
   DRAM:  64 MiB
   WARNING: Caches not enabled
   MMC:   davinci: 0
   SF: Detected M25P64 with page size 256 Bytes, erase size 64 KiB, 
   total 8 MiB
   In:serial
   Out:   serial
   Err:   serial
   SF: Detected M25P64 with page size 256 Bytes, erase size 64 KiB, 
   total 8 MiB
   Warning: Invalid MAC address read from SPI flash
   Net:   DaVinci-EMAC
   Error: DaVinci-EMAC address not set.
  
   U-Boot  help
   data abort
   pc : [c108ffd8]  lr : [c10900b4]
   sp : c3e5f838  ip :  fp : c3e5fda4
   r10: c10b1f28  r9 : c3e5ff08 r8 : 000e
   r7 : c10b22c4  r6 : c10aa2a0 r5 :   r4 : 001b
   r3 : c10b8f70  r2 : 0001 r1 : c3e5f840  r0 : 
   Flags: Nzcv  IRQs off  FIQs off  Mode SVC_32
   Resetting CPU ...
  
   If I rebuild  with CONFIG_OF_LIBFDT removed again from 
   da850evm.h the
   problem disappears.  And you can see that the saveenv worked 
   (i.e. the
   environment is what was saved before the reboot and data abort).
  
   I've traced the problem as far as the inline version of 
   console_puts()
   in common/console.c.  The table dispatch there and the fact that 
   the
   problem appears only when you load the environment makes me 
   think it's
   memory corruption.
  
   Note: if you do *not* specify CONFIG_SYS_GENERIC_BOARD you still 
   get the
   data abort, however it takes a bit more effort to trigger (like 
   actually
   looking at the environment :-)  )
  
   (Note: This is building against the u-boot-2015.01-rc1 tree)
  
   Suggestions?
 
  In case it helps, I got the same symptom (help crashes) and it was 
  due
  to BSS not being cleared. Stefan (on cc) found this problem - he 
  said
  something to do with GDT calculation or handling. However it is 
  just a
  guess and probably has nothing to do with your issue.
 
  I may be missing something, but the GDT appears to be x86-specific
  whereas I'm building for ARMv5.

 OK for some reason I thought this was PPC!

 Maybe you can find your pc in System.map and work out where it is
 going wrong? Are you hitting some image size limit?

 pc : [c108ffd8]
   
   
Sorry, been distracted on other stuff for a few days.
   
First, I now understand the global descriptor a bit better.  For ARMv5
It's stored in r9 and still looks sane.  The relevant info:
   
(gdb) print/x *((gd_t *)$r9)
$1 = {bd = 0xc3e5ffb0, flags = 0x183, baudrate = 0x1c200, cpu_clk = 0x0,
  bus_clk = 0x0, pci_clk = 0x0, mem_clk = 0x0, have_console = 0x1,
  env_addr = 0xc10a8fcc, env_valid = 0x1, ram_top = 0xc400,
  relocaddr = 0xc3f8, ram_size = 0x400, mon_len = 0x6ffb0,
  irq_sp = 0xc3e5fef0, start_addr_sp = 0xc3e5fee0, reloc_off = 
0x2f0,
  new_gd = 0xc3e5ff08, fdt_blob = 0x0, new_fdt = 0x0, fdt_size = 0x0,
  jt = 0xc3e601c0, env_buf = {0x31, 0x31, 0x35, 0x32, 0x30, 0x30,
0x0 repeats 26 times}, cur_i2c_bus = 0x0

Re: [U-Boot] Problem converting da850evm to generic board and use libfdt

[Peter Howard]

On Wed, 2014-12-10 at 17:49 -0700, Simon Glass wrote:
 Hi Peter,
 
 On 10 December 2014 at 17:19, Peter Howard p...@northern-ridge.com.au wrote:
  On Wed, 2014-12-10 at 15:43 -0700, Simon Glass wrote:
  Hi Peter,
 
  On 10 December 2014 at 15:17, Peter Howard p...@northern-ridge.com.au 
  wrote:
  
   On Tue, 2014-12-09 at 17:45 -0700, Simon Glass wrote:
Hi Peter,
   
On 9 December 2014 at 17:13, Peter Howard p...@northern-ridge.com.au 
wrote:

 On Wed, 2014-12-03 at 14:20 -0800, Simon Glass wrote:
  Hi Peter,
 
  On 3 December 2014 at 13:53, Peter Howard 
  p...@northern-ridge.com.au wrote:
   On Wed, 2014-12-03 at 06:38 -0700, Simon Glass wrote:
   Hi Peter,
  
   On 2 December 2014 at 14:59, Peter Howard 
   p...@northern-ridge.com.au wrote:
   
I'm trying to make two changes to building u-boot for the 
da850evm.
  * Use the generic board code to get rid of the warning, 
and
  * Enable libfdt to allow booting of linux with a 
standalone dtb
image.
   
The first part appears to be simple.  Just adding
   
#define CONFIG_SYS_GENERIC_BOARD
   
in include/configs/da850evm.h works with no obvious 
side-effects.
   
However, adding
   
#define CONFIG_OF_LIBFDT
   
is a different story.  It appears to introduce memory 
corruption when
loading the environment.  On first boot it gives the bad 
CRC! warning
and uses the default environment.  If you *don't* save the 
environment
you can boot fine (including manual editing of the 
environment). However
if you save the environment via saveenv bad things happen on 
the next
boot.  An example log:
   
U-Boot SPL 2015.01-rc1 (Nov 27 2014 - 14:30:26)
   
   
U-Boot 2015.01-rc1 (Nov 27 2014 - 14:30:26)
   
I2C:   ready
DRAM:  64 MiB
WARNING: Caches not enabled
MMC:   davinci: 0
SF: Detected M25P64 with page size 256 Bytes, erase size 64 
KiB, total 8 MiB
In:serial
Out:   serial
Err:   serial
SF: Detected M25P64 with page size 256 Bytes, erase size 64 
KiB, total 8 MiB
Warning: Invalid MAC address read from SPI flash
Net:   DaVinci-EMAC
Error: DaVinci-EMAC address not set.
   
U-Boot  help
data abort
pc : [c108ffd8]  lr : [c10900b4]
sp : c3e5f838  ip :  fp : c3e5fda4
r10: c10b1f28  r9 : c3e5ff08 r8 : 000e
r7 : c10b22c4  r6 : c10aa2a0 r5 :   r4 : 001b
r3 : c10b8f70  r2 : 0001 r1 : c3e5f840  r0 : 
Flags: Nzcv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...
   
If I rebuild  with CONFIG_OF_LIBFDT removed again from 
da850evm.h the
problem disappears.  And you can see that the saveenv worked 
(i.e. the
environment is what was saved before the reboot and data 
abort).
   
I've traced the problem as far as the inline version of 
console_puts()
in common/console.c.  The table dispatch there and the fact 
that the
problem appears only when you load the environment makes me 
think it's
memory corruption.
   
Note: if you do *not* specify CONFIG_SYS_GENERIC_BOARD you 
still get the
data abort, however it takes a bit more effort to trigger 
(like actually
looking at the environment :-)  )
   
(Note: This is building against the u-boot-2015.01-rc1 tree)
   
Suggestions?
  
   In case it helps, I got the same symptom (help crashes) and it 
   was due
   to BSS not being cleared. Stefan (on cc) found this problem - 
   he said
   something to do with GDT calculation or handling. However it is 
   just a
   guess and probably has nothing to do with your issue.
  
   I may be missing something, but the GDT appears to be 
   x86-specific
   whereas I'm building for ARMv5.
 
  OK for some reason I thought this was PPC!
 
  Maybe you can find your pc in System.map and work out where it is
  going wrong? Are you hitting some image size limit?
 
  pc : [c108ffd8]


 Sorry, been distracted on other stuff for a few days.

 First, I now understand the global descriptor a bit better.  For 
 ARMv5
 It's stored in r9 and still looks sane.  The relevant info:

 (gdb) print/x *((gd_t *)$r9)
 $1 = {bd = 0xc3e5ffb0, flags = 0x183, baudrate = 0x1c200, cpu_clk = 
 0x0,
   bus_clk = 0x0, pci_clk = 0x0, mem_clk = 0x0, have_console = 0x1,
   env_addr = 0xc10a8fcc, env_valid = 0x1, ram_top = 0xc400,
   relocaddr

Re: [U-Boot] Problem converting da850evm to generic board and use libfdt

[Peter Howard]

On Wed, 2014-12-03 at 14:20 -0800, Simon Glass wrote:
 Hi Peter,
 
 On 3 December 2014 at 13:53, Peter Howard p...@northern-ridge.com.au wrote:
  On Wed, 2014-12-03 at 06:38 -0700, Simon Glass wrote:
  Hi Peter,
 
  On 2 December 2014 at 14:59, Peter Howard p...@northern-ridge.com.au 
  wrote:
  
   I'm trying to make two changes to building u-boot for the da850evm.
 * Use the generic board code to get rid of the warning, and
 * Enable libfdt to allow booting of linux with a standalone dtb
   image.
  
   The first part appears to be simple.  Just adding
  
   #define CONFIG_SYS_GENERIC_BOARD
  
   in include/configs/da850evm.h works with no obvious side-effects.
  
   However, adding
  
   #define CONFIG_OF_LIBFDT
  
   is a different story.  It appears to introduce memory corruption when
   loading the environment.  On first boot it gives the bad CRC! warning
   and uses the default environment.  If you *don't* save the environment
   you can boot fine (including manual editing of the environment). However
   if you save the environment via saveenv bad things happen on the next
   boot.  An example log:
  
   U-Boot SPL 2015.01-rc1 (Nov 27 2014 - 14:30:26)
  
  
   U-Boot 2015.01-rc1 (Nov 27 2014 - 14:30:26)
  
   I2C:   ready
   DRAM:  64 MiB
   WARNING: Caches not enabled
   MMC:   davinci: 0
   SF: Detected M25P64 with page size 256 Bytes, erase size 64 KiB, total 8 
   MiB
   In:serial
   Out:   serial
   Err:   serial
   SF: Detected M25P64 with page size 256 Bytes, erase size 64 KiB, total 8 
   MiB
   Warning: Invalid MAC address read from SPI flash
   Net:   DaVinci-EMAC
   Error: DaVinci-EMAC address not set.
  
   U-Boot  help
   data abort
   pc : [c108ffd8]  lr : [c10900b4]
   sp : c3e5f838  ip :  fp : c3e5fda4
   r10: c10b1f28  r9 : c3e5ff08 r8 : 000e
   r7 : c10b22c4  r6 : c10aa2a0 r5 :   r4 : 001b
   r3 : c10b8f70  r2 : 0001 r1 : c3e5f840  r0 : 
   Flags: Nzcv  IRQs off  FIQs off  Mode SVC_32
   Resetting CPU ...
  
   If I rebuild  with CONFIG_OF_LIBFDT removed again from da850evm.h the
   problem disappears.  And you can see that the saveenv worked (i.e. the
   environment is what was saved before the reboot and data abort).
  
   I've traced the problem as far as the inline version of console_puts()
   in common/console.c.  The table dispatch there and the fact that the
   problem appears only when you load the environment makes me think it's
   memory corruption.
  
   Note: if you do *not* specify CONFIG_SYS_GENERIC_BOARD you still get the
   data abort, however it takes a bit more effort to trigger (like actually
   looking at the environment :-)  )
  
   (Note: This is building against the u-boot-2015.01-rc1 tree)
  
   Suggestions?
 
  In case it helps, I got the same symptom (help crashes) and it was due
  to BSS not being cleared. Stefan (on cc) found this problem - he said
  something to do with GDT calculation or handling. However it is just a
  guess and probably has nothing to do with your issue.
 
  I may be missing something, but the GDT appears to be x86-specific
  whereas I'm building for ARMv5.
 
 OK for some reason I thought this was PPC!
 
 Maybe you can find your pc in System.map and work out where it is
 going wrong? Are you hitting some image size limit?
 
 pc : [c108ffd8]


Sorry, been distracted on other stuff for a few days.

First, I now understand the global descriptor a bit better.  For ARMv5
It's stored in r9 and still looks sane.  The relevant info:

(gdb) print/x *((gd_t *)$r9)
$1 = {bd = 0xc3e5ffb0, flags = 0x183, baudrate = 0x1c200, cpu_clk = 0x0, 
  bus_clk = 0x0, pci_clk = 0x0, mem_clk = 0x0, have_console = 0x1, 
  env_addr = 0xc10a8fcc, env_valid = 0x1, ram_top = 0xc400, 
  relocaddr = 0xc3f8, ram_size = 0x400, mon_len = 0x6ffb0, 
  irq_sp = 0xc3e5fef0, start_addr_sp = 0xc3e5fee0, reloc_off = 0x2f0, 
  new_gd = 0xc3e5ff08, fdt_blob = 0x0, new_fdt = 0x0, fdt_size = 0x0, 
  jt = 0xc3e601c0, env_buf = {0x31, 0x31, 0x35, 0x32, 0x30, 0x30, 
0x0 repeats 26 times}, cur_i2c_bus = 0x0, timebase_h = 0x0, 
  timebase_l = 0x0, arch = {timer_rate_hz = 0x16e360, tbu = 0x0, 
tbl = 0x4cc62, lastinc = 0x0, timer_reset_value = 0x0, 
tlb_addr = 0xc3ff, tlb_size = 0x4000}}


The pc is definitely bogus.  The reloc address is 0xc3f8 whereas
that would be a pre-reloc address (starting at 0xc108).  And it's
definitely relocated by the time of failure.  The only other bit of
information I have right now is that adding CONFIG_OF_LIBFDT drops the
reloc address from 0xc3f85000 to 0xc3f8.

Don't know if any of that gives additional insight.  Meanwhile I
continue tracing.

-- 
Peter Howard p...@northern-ridge.com.au

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem converting da850evm to generic board and use libfdt

[Peter Howard]

On Wed, 2014-12-03 at 06:38 -0700, Simon Glass wrote:
 Hi Peter,
 
 On 2 December 2014 at 14:59, Peter Howard p...@northern-ridge.com.au wrote:
 
  I'm trying to make two changes to building u-boot for the da850evm.
* Use the generic board code to get rid of the warning, and
* Enable libfdt to allow booting of linux with a standalone dtb
  image.
 
  The first part appears to be simple.  Just adding
 
  #define CONFIG_SYS_GENERIC_BOARD
 
  in include/configs/da850evm.h works with no obvious side-effects.
 
  However, adding
 
  #define CONFIG_OF_LIBFDT
 
  is a different story.  It appears to introduce memory corruption when
  loading the environment.  On first boot it gives the bad CRC! warning
  and uses the default environment.  If you *don't* save the environment
  you can boot fine (including manual editing of the environment). However
  if you save the environment via saveenv bad things happen on the next
  boot.  An example log:
 
  U-Boot SPL 2015.01-rc1 (Nov 27 2014 - 14:30:26)
 
 
  U-Boot 2015.01-rc1 (Nov 27 2014 - 14:30:26)
 
  I2C:   ready
  DRAM:  64 MiB
  WARNING: Caches not enabled
  MMC:   davinci: 0
  SF: Detected M25P64 with page size 256 Bytes, erase size 64 KiB, total 8 MiB
  In:serial
  Out:   serial
  Err:   serial
  SF: Detected M25P64 with page size 256 Bytes, erase size 64 KiB, total 8 MiB
  Warning: Invalid MAC address read from SPI flash
  Net:   DaVinci-EMAC
  Error: DaVinci-EMAC address not set.
 
  U-Boot  help
  data abort
  pc : [c108ffd8]  lr : [c10900b4]
  sp : c3e5f838  ip :  fp : c3e5fda4
  r10: c10b1f28  r9 : c3e5ff08 r8 : 000e
  r7 : c10b22c4  r6 : c10aa2a0 r5 :   r4 : 001b
  r3 : c10b8f70  r2 : 0001 r1 : c3e5f840  r0 : 
  Flags: Nzcv  IRQs off  FIQs off  Mode SVC_32
  Resetting CPU ...
 
  If I rebuild  with CONFIG_OF_LIBFDT removed again from da850evm.h the
  problem disappears.  And you can see that the saveenv worked (i.e. the
  environment is what was saved before the reboot and data abort).
 
  I've traced the problem as far as the inline version of console_puts()
  in common/console.c.  The table dispatch there and the fact that the
  problem appears only when you load the environment makes me think it's
  memory corruption.
 
  Note: if you do *not* specify CONFIG_SYS_GENERIC_BOARD you still get the
  data abort, however it takes a bit more effort to trigger (like actually
  looking at the environment :-)  )
 
  (Note: This is building against the u-boot-2015.01-rc1 tree)
 
  Suggestions?
 
 In case it helps, I got the same symptom (help crashes) and it was due
 to BSS not being cleared. Stefan (on cc) found this problem - he said
 something to do with GDT calculation or handling. However it is just a
 guess and probably has nothing to do with your issue.

I may be missing something, but the GDT appears to be x86-specific
whereas I'm building for ARMv5.
-- 
Peter Howard p...@northern-ridge.com.au

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Problem converting da850evm to generic board and use libfdt

[Peter Howard]

I'm trying to make two changes to building u-boot for the da850evm.
  * Use the generic board code to get rid of the warning, and
  * Enable libfdt to allow booting of linux with a standalone dtb
image.

The first part appears to be simple.  Just adding 

#define CONFIG_SYS_GENERIC_BOARD

in include/configs/da850evm.h works with no obvious side-effects.

However, adding

#define CONFIG_OF_LIBFDT

is a different story.  It appears to introduce memory corruption when
loading the environment.  On first boot it gives the bad CRC! warning
and uses the default environment.  If you *don't* save the environment
you can boot fine (including manual editing of the environment). However
if you save the environment via saveenv bad things happen on the next
boot.  An example log:

U-Boot SPL 2015.01-rc1 (Nov 27 2014 - 14:30:26) 


U-Boot 2015.01-rc1 (Nov 27 2014 - 14:30:26) 

I2C:   ready
DRAM:  64 MiB   
WARNING: Caches not enabled 
MMC:   davinci: 0   
SF: Detected M25P64 with page size 256 Bytes, erase size 64 KiB, total 8 MiB
In:serial   
Out:   serial   
Err:   serial   
SF: Detected M25P64 with page size 256 Bytes, erase size 64 KiB, total 8 MiB
Warning: Invalid MAC address read from SPI flash
Net:   DaVinci-EMAC 
Error: DaVinci-EMAC address not set.

U-Boot  help   
data abort  
pc : [c108ffd8]  lr : [c10900b4]
sp : c3e5f838  ip :  fp : c3e5fda4  
r10: c10b1f28  r9 : c3e5ff08 r8 : 000e  
r7 : c10b22c4  r6 : c10aa2a0 r5 :   r4 : 001b   
r3 : c10b8f70  r2 : 0001 r1 : c3e5f840  r0 :    
Flags: Nzcv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ... 

If I rebuild  with CONFIG_OF_LIBFDT removed again from da850evm.h the
problem disappears.  And you can see that the saveenv worked (i.e. the
environment is what was saved before the reboot and data abort).

I've traced the problem as far as the inline version of console_puts()
in common/console.c.  The table dispatch there and the fact that the
problem appears only when you load the environment makes me think it's
memory corruption.

Note: if you do *not* specify CONFIG_SYS_GENERIC_BOARD you still get the
data abort, however it takes a bit more effort to trigger (like actually
looking at the environment :-)  )

(Note: This is building against the u-boot-2015.01-rc1 tree)

Suggestions?
 
-- 
Peter Howard p...@northern-ridge.com.au

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot