Re: [PATCH 5/8] mx6memcal: Remove SPL_USB_HOST

2022-06-12 Thread Eric Nelson

Thanks Tom.

On 6/12/22 17:02, Tom Rini wrote:

As this particular platform is intended to be loaded and run a specific
set of routines in SPL, we do not need the ability to further use the
USB as a host device in SPL.  Disable this support.

Cc: Eric Nelson 
Signed-off-by: Tom Rini 
---
Please correct me if I'm wrong here and I'll update the subsequent patch
that lead me to discover this.
---
  configs/mx6memcal_defconfig | 1 -
  1 file changed, 1 deletion(-)

diff --git a/configs/mx6memcal_defconfig b/configs/mx6memcal_defconfig
index a1bc95bb4a1c..021e8a6151ee 100644
--- a/configs/mx6memcal_defconfig
+++ b/configs/mx6memcal_defconfig
@@ -16,7 +16,6 @@ CONFIG_SYS_MEMTEST_START=0x1000
  CONFIG_SYS_MEMTEST_END=0x2000
  CONFIG_SUPPORT_RAW_INITRD=y
  CONFIG_SYS_SPL_MALLOC=y
-CONFIG_SPL_USB_HOST=y
  CONFIG_SPL_WATCHDOG=y
  CONFIG_HUSH_PARSER=y
  CONFIG_SYS_MAXARGS=32


Acked-by: Eric Nelson 


Re: [PATCH 07/18] mx6memcal: Disable USB GADGET in SPL

2021-05-25 Thread Eric Nelson
Hi Tom,

On 5/25/21 9:45 AM, Tom Rini wrote:
> On Tue, May 25, 2021 at 09:19:30AM -0700, Eric Nelson wrote:
>> Hi Tom,
>>
>> On 5/25/21 8:47 AM, Tom Rini wrote:
>>> On Tue, May 25, 2021 at 07:10:29AM -0700, Eric Nelson wrote:
>>>
>>>> Since the proper U-Boot doesn't do anything at the moment, I don't think
>>>> this hurts much.
>>>>
>>>> My usage of mx6memcal generally ends after SPL spits out calibration
>>>> values, and I suspect the same is true for other users, so
>>>>
>>>> Acked-by: Eric Nelson 
>>> But don't you need SPL gadget support to easily load this in?
>>>
>> No. The calibration is done by the SPL running in internal RAM.
> ... ah, yes, sorry, I'm with you now.  ROM loads via gadget, SPL runs,
> does memcalc, displays values, then you move on to the real board.
>

And test under Linux, where you can exercise things with the GPU and VPU
active.

Testing under U-Boot doesn't tend to find calibration errors.

It would be helpful to test under U-Boot by adding support for changing up
the DDR frequencies (as done in the NXP test), but that's something for
another day.


Re: [PATCH 07/18] mx6memcal: Disable USB GADGET in SPL

2021-05-25 Thread Eric Nelson
Hi Tom,

On 5/25/21 8:47 AM, Tom Rini wrote:
> On Tue, May 25, 2021 at 07:10:29AM -0700, Eric Nelson wrote:
>
>> Since the proper U-Boot doesn't do anything at the moment, I don't think
>> this hurts much.
>>
>> My usage of mx6memcal generally ends after SPL spits out calibration
>> values, and I suspect the same is true for other users, so
>>
>> Acked-by: Eric Nelson 
> But don't you need SPL gadget support to easily load this in?
>
No. The calibration is done by the SPL running in internal RAM.


Re: [PATCH 07/18] mx6memcal: Disable USB GADGET in SPL

2021-05-25 Thread Eric Nelson
Since the proper U-Boot doesn't do anything at the moment, I don't think
this hurts much.

My usage of mx6memcal generally ends after SPL spits out calibration
values, and I suspect the same is true for other users, so

Acked-by: Eric Nelson 

On 5/22/21 5:47 AM, Tom Rini wrote:
> As this board does not use CONFIG_OF_CONTROL and the DM_USB migration
> deadline has passed, disable USB_GADGET support.
> 
> Cc: Eric Nelson 
> Cc: Stefano Babic 
> Signed-off-by: Tom Rini 
> ---
> I realize this removes an important functional part of the board.  I
> suspect the path forward here is to make a generic mx6 device tree to
> use here, so that the USB functionality keeps working.
> ---
>  configs/mx6memcal_defconfig | 9 -
>  1 file changed, 9 deletions(-)
> 
> diff --git a/configs/mx6memcal_defconfig b/configs/mx6memcal_defconfig
> index 41ff942cf1ce..a860fbe77738 100644
> --- a/configs/mx6memcal_defconfig
> +++ b/configs/mx6memcal_defconfig
> @@ -16,9 +16,6 @@ CONFIG_SPL=y
>  CONFIG_SUPPORT_RAW_INITRD=y
>  CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg,SPL"
>  CONFIG_SPL_USB_HOST_SUPPORT=y
> -CONFIG_SPL_USB_GADGET=y
> -CONFIG_SPL_USB_ETHER=y
> -CONFIG_SPL_USB_SDP_SUPPORT=y
>  CONFIG_SPL_WATCHDOG_SUPPORT=y
>  CONFIG_HUSH_PARSER=y
>  # CONFIG_CMD_BOOTD is not set
> @@ -45,11 +42,5 @@ CONFIG_BOUNCE_BUFFER=y
>  # CONFIG_MMC is not set
>  CONFIG_FSL_USDHC=y
>  CONFIG_MXC_UART=y
> -CONFIG_USB=y
> -CONFIG_USB_GADGET=y
> -CONFIG_USB_GADGET_MANUFACTURER="FSL"
> -CONFIG_USB_GADGET_VENDOR_NUM=0x0525
> -CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
> -CONFIG_CI_UDC=y
>  CONFIG_OF_LIBFDT=y
>  # CONFIG_EFI_LOADER is not set
> 



Re: [PATCH v2 13/14] blkcache: Extend blkcache_init to cover CONFIG_NEEDS_MANUAL_RELOC

2020-07-15 Thread Eric Nelson

On 7/10/20 3:19 AM, Ovidiu Panait wrote:

Extend manual relocation of block_cache list pointers to all platforms that
enable CONFIG_NEEDS_MANUAL_RELOC. Remove m68k-specific checks and provide a
single implementation that adds gd->reloc_off to the pre-relocation
pointers.

Cc: Angelo Durgehello 
Reviewed-by: Simon Glass 
Signed-off-by: Ovidiu Panait 
---
v2 updates:
- add reviewed-by tag



Reviewed-by: Eric Nelson 


Re: [PATCH 2/8] mx6memcal: Finish migration to defconfig options

2020-06-02 Thread Eric Nelson

Reviewed by: Eric Nelson 

On 5/26/20 12:06 PM, Tom Rini wrote:

The config header for this platform uses '#undef' in a number of cases.
All of the MMC related ones were already handled correctly in the
defconfig file.  In the case of CONFIG_CMD_FUSE, the command was being
built and enabled via defconfig.  Disable it in the defconfig, cleanup
the header.

Cc: Eric Nelson 
Signed-off-by: Tom Rini 
---
  configs/mx6memcal_defconfig | 1 +
  include/configs/mx6memcal.h | 5 -
  2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/configs/mx6memcal_defconfig b/configs/mx6memcal_defconfig
index 8b5e0ff9b134..ed24b7996b6b 100644
--- a/configs/mx6memcal_defconfig
+++ b/configs/mx6memcal_defconfig
@@ -33,6 +33,7 @@ CONFIG_CMD_MEMINFO=y
  CONFIG_CMD_MEMTEST=y
  CONFIG_SYS_MEMTEST_START=0x1000
  CONFIG_SYS_MEMTEST_END=0x2000
+# CONFIG_CMD_FUSE is not set
  # CONFIG_CMD_LOADB is not set
  # CONFIG_CMD_LOADS is not set
  CONFIG_CMD_CACHE=y
diff --git a/include/configs/mx6memcal.h b/include/configs/mx6memcal.h
index 3d79a7e43765..b774b167f648 100644
--- a/include/configs/mx6memcal.h
+++ b/include/configs/mx6memcal.h
@@ -13,11 +13,6 @@
  #include "mx6_common.h"
  #include "imx6_spl.h"
  
-#undef CONFIG_MMC

-#undef CONFIG_SPL_MMC_SUPPORT
-#undef CONFIG_GENERIC_MMC
-#undef CONFIG_CMD_FUSE
-
  #define CONFIG_SYS_MALLOC_LEN (64 * 1024 * 1024)
  
  #define CONFIG_MXC_UART




[PATCH] common: blk: fix comment about blkcache_read return value

2020-01-22 Thread Eric Nelson
The blkcache_read() routine returns 1 (true) to indicate that a block was
found in the cache and returned, or 0 if not.

Signed-off-by: Eric Nelson 
---
 include/blk.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/blk.h b/include/blk.h
index 65db69f5d9..6f541bb2ba 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -129,7 +129,7 @@ int blkcache_init(void);
  * @param blksz - size in bytes of each block
  * @param buf - buffer to contain cached data
  *
- * @return - '1' if block returned from cache, '0' otherwise.
+ * @return - 1 if block returned from cache, 0 otherwise.
  */
 int blkcache_read(int iftype, int dev,
  lbaint_t start, lbaint_t blkcnt,
-- 
2.17.1



Re: [PATCH] common: add blkcache init

2020-01-22 Thread Eric Nelson

Thanks Angelo,

On 1/21/20 2:37 AM, Angelo Dureghello wrote:

From: Angelo Durgehello 

On m68k, block_cache list is relocated, but next and prev list
pointers are not adjusted to the relocated struct list_head address,
so the first iteration over the block_cache list hangs.

This patch initializes the block_cache list after relocation.

Signed-off-by: Angelo Durgehello 
---
Changes for v2:
- call blkcache_init directly
---
  common/board_r.c | 3 +++
  drivers/block/blkcache.c | 9 -
  include/blk.h| 6 ++
  3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/common/board_r.c b/common/board_r.c
index 8a0c1114e7..4f56c19fcc 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -864,6 +864,9 @@ static init_fnc_t init_sequence_r[] = {
  #endif
  #if defined(CONFIG_PRAM)
initr_mem,
+#endif
+#ifdef CONFIG_BLOCK_CACHE
+   blkcache_init,
  #endif
run_main_loop,
  };
diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c
index 1fa64989d3..f603aa129d 100644
--- a/drivers/block/blkcache.c
+++ b/drivers/block/blkcache.c
@@ -21,13 +21,20 @@ struct block_cache_node {
char *cache;
  };
  
-static LIST_HEAD(block_cache);

+static struct list_head block_cache;
  
  static struct block_cache_stats _stats = {

.max_blocks_per_entry = 8,
.max_entries = 32
  };
  
+int blkcache_init(void)

+{
+   INIT_LIST_HEAD(_cache);
+
+   return 0;
+}
+
  static struct block_cache_node *cache_find(int iftype, int devnum,
   lbaint_t start, lbaint_t blkcnt,
   unsigned long blksz)
diff --git a/include/blk.h b/include/blk.h
index d0c033aece..65db69f5d9 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -113,6 +113,12 @@ struct blk_desc {
(PAD_SIZE(size, blk_desc->blksz))
  
  #if CONFIG_IS_ENABLED(BLOCK_CACHE)

+
+/**
+ * blkcache_init() - initialize the block cache list pointers
+ */
+int blkcache_init(void);
+
  /**
   * blkcache_read() - attempt to read a set of blocks from cache
   *



This looks good to me.

Reviewed-by: Eric Nelson 


Re: [U-Boot] [PATCH] ARM: mx6: pmu: Expose PMU LDO configuration interface

2019-11-26 Thread Eric Nelson

Hi Marek,

On 11/26/19 1:35 AM, Marek Vasut wrote:

Make the PMU LDO configuration interface available to board code,
so that board code can reconfigure the internal LDOs of the SoC.

Signed-off-by: Marek Vasut 
Cc: Eric Nelson 
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
  arch/arm/include/asm/arch-mx6/sys_proto.h | 8 
  arch/arm/mach-imx/mx6/soc.c   | 8 +---
  2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h 
b/arch/arm/include/asm/arch-mx6/sys_proto.h
index 4bf7dff8b4..1e5fa1a75e 100644
--- a/arch/arm/include/asm/arch-mx6/sys_proto.h
+++ b/arch/arm/include/asm/arch-mx6/sys_proto.h
@@ -20,6 +20,14 @@
  int imx6_pcie_toggle_power(void);
  int imx6_pcie_toggle_reset(void);
  
+enum ldo_reg {

+   LDO_ARM,
+   LDO_SOC,
+   LDO_PU,
+};
+
+int set_ldo_voltage(enum ldo_reg ldo, u32 mv);
+
  /**
   * iomuxc_set_rgmii_io_voltage - set voltage level of RGMII/USB pins
   *
diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
index 6dccee484c..3560dd7ee7 100644
--- a/arch/arm/mach-imx/mx6/soc.c
+++ b/arch/arm/mach-imx/mx6/soc.c
@@ -23,12 +23,6 @@
  #include 
  #include 
  
-enum ldo_reg {

-   LDO_ARM,
-   LDO_SOC,
-   LDO_PU,
-};
-
  struct scu_regs {
u32 ctrl;
u32 config;
@@ -254,7 +248,7 @@ static void clear_ldo_ramp(void)
   * Possible values are from 0.725V to 1.450V in steps of
   * 0.025V (25mV).
   */
-static int set_ldo_voltage(enum ldo_reg ldo, u32 mv)
+int set_ldo_voltage(enum ldo_reg ldo, u32 mv)
  {
struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
u32 val, step, old, reg = readl(>reg_core);



Reviewed-by: Eric Nelson 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 3/4] ARM: mx6: ddr: Configure all SDQS pullups using loop

2019-11-26 Thread Eric Nelson

Hi Marek,

On 11/26/19 1:34 AM, Marek Vasut wrote:

Instead of explicitly setting up each SDQS register, use a loop.
No functional change.

Signed-off-by: Marek Vasut 
Cc: Eric Nelson 
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
  arch/arm/mach-imx/mx6/ddr.c | 27 ---
  1 file changed, 8 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-imx/mx6/ddr.c b/arch/arm/mach-imx/mx6/ddr.c
index e917b04f3d..b2402f75db 100644
--- a/arch/arm/mach-imx/mx6/ddr.c
+++ b/arch/arm/mach-imx/mx6/ddr.c
@@ -249,25 +249,14 @@ static void mmdc_set_sdqs(bool set)
  {
struct mx6dq_iomux_ddr_regs *mx6_ddr_iomux =
(struct mx6dq_iomux_ddr_regs *)MX6DQ_IOM_DDR_BASE;
-
-   if (set) {
-   setbits_le32(_ddr_iomux->dram_sdqs0, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs1, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs2, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs3, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs4, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs5, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs6, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs7, 0x7000);
-   } else {
-   clrbits_le32(_ddr_iomux->dram_sdqs0, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs1, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs2, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs3, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs4, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs5, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs6, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs7, 0x7000);
+   u32 sdqs = (u32)(_ddr_iomux->dram_sdqs0);
+   int i;
+
+   for (i = 0; i < 8; i++) {
+   if (set)
+   setbits_le32(sdqs + (4 * i), 0x7000);
+   else
+   clrbits_le32(sdqs + (4 * i), 0x7000);
}
  }
  



Reviewed-by: Eric Nelson 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 4/4] ARM: mx6: ddr: Add support for iMX6SX

2019-11-26 Thread Eric Nelson

Hi Marek,

On 11/26/19 1:34 AM, Marek Vasut wrote:

This patch adds support for iMX6SX MMDC into the DDR calibration
code. The only difference between MX6DQ and MX6SX is that the SX
has 2 SDQS registers, while the DQ has 8.

Signed-off-by: Marek Vasut 
Cc: Eric Nelson 
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
  arch/arm/mach-imx/mx6/ddr.c | 18 ++
  1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-imx/mx6/ddr.c b/arch/arm/mach-imx/mx6/ddr.c
index b2402f75db..8ed8b79c8b 100644
--- a/arch/arm/mach-imx/mx6/ddr.c
+++ b/arch/arm/mach-imx/mx6/ddr.c
@@ -247,12 +247,22 @@ int mmdc_do_write_level_calibration(struct 
mx6_ddr_sysinfo const *sysinfo)
  
  static void mmdc_set_sdqs(bool set)

  {
-   struct mx6dq_iomux_ddr_regs *mx6_ddr_iomux =
+   struct mx6dq_iomux_ddr_regs *mx6dq_ddr_iomux =
(struct mx6dq_iomux_ddr_regs *)MX6DQ_IOM_DDR_BASE;
-   u32 sdqs = (u32)(_ddr_iomux->dram_sdqs0);
-   int i;
+   struct mx6sx_iomux_ddr_regs *mx6sx_ddr_iomux =
+   (struct mx6sx_iomux_ddr_regs *)MX6SX_IOM_DDR_BASE;
+   int i, sdqs_cnt;
+   u32 sdqs;
+
+   if (is_mx6sx()) {
+   sdqs = (u32)(_ddr_iomux->dram_sdqs0);
+   sdqs_cnt = 2;
+   } else {/* MX6DQ */
+   sdqs = (u32)(_ddr_iomux->dram_sdqs0);
+   sdqs_cnt = 8;
+   }
  
-	for (i = 0; i < 8; i++) {

+   for (i = 0; i < sdqs_cnt; i++) {
if (set)
setbits_le32(sdqs + (4 * i), 0x7000);
else



Reviewed-by: Eric Nelson 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/4] ARM: mx6: ddr: Factor out SDQS configuration code

2019-11-26 Thread Eric Nelson

Hi Marek,

On 11/26/19 1:34 AM, Marek Vasut wrote:

Pull out the code turning SDQS pullups on and off into a separate
function, since it is replicated in two places in the code and it
is the single place in the entire function which is SoC dependent.

Signed-off-by: Marek Vasut 
Cc: Eric Nelson 
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
  arch/arm/mach-imx/mx6/ddr.c | 46 ++---
  1 file changed, 28 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-imx/mx6/ddr.c b/arch/arm/mach-imx/mx6/ddr.c
index e6f69e904f..e917b04f3d 100644
--- a/arch/arm/mach-imx/mx6/ddr.c
+++ b/arch/arm/mach-imx/mx6/ddr.c
@@ -245,12 +245,36 @@ int mmdc_do_write_level_calibration(struct 
mx6_ddr_sysinfo const *sysinfo)
return errors;
  }
  
+static void mmdc_set_sdqs(bool set)

+{
+   struct mx6dq_iomux_ddr_regs *mx6_ddr_iomux =
+   (struct mx6dq_iomux_ddr_regs *)MX6DQ_IOM_DDR_BASE;
+
+   if (set) {
+   setbits_le32(_ddr_iomux->dram_sdqs0, 0x7000);
+   setbits_le32(_ddr_iomux->dram_sdqs1, 0x7000);
+   setbits_le32(_ddr_iomux->dram_sdqs2, 0x7000);
+   setbits_le32(_ddr_iomux->dram_sdqs3, 0x7000);
+   setbits_le32(_ddr_iomux->dram_sdqs4, 0x7000);
+   setbits_le32(_ddr_iomux->dram_sdqs5, 0x7000);
+   setbits_le32(_ddr_iomux->dram_sdqs6, 0x7000);
+   setbits_le32(_ddr_iomux->dram_sdqs7, 0x7000);
+   } else {
+   clrbits_le32(_ddr_iomux->dram_sdqs0, 0x7000);
+   clrbits_le32(_ddr_iomux->dram_sdqs1, 0x7000);
+   clrbits_le32(_ddr_iomux->dram_sdqs2, 0x7000);
+   clrbits_le32(_ddr_iomux->dram_sdqs3, 0x7000);
+   clrbits_le32(_ddr_iomux->dram_sdqs4, 0x7000);
+   clrbits_le32(_ddr_iomux->dram_sdqs5, 0x7000);
+   clrbits_le32(_ddr_iomux->dram_sdqs6, 0x7000);
+   clrbits_le32(_ddr_iomux->dram_sdqs7, 0x7000);
+   }
+}
+
  int mmdc_do_dqs_calibration(struct mx6_ddr_sysinfo const *sysinfo)
  {
struct mmdc_p_regs *mmdc0 = (struct mmdc_p_regs *)MMDC_P0_BASE_ADDR;
struct mmdc_p_regs *mmdc1 = (struct mmdc_p_regs *)MMDC_P1_BASE_ADDR;
-   struct mx6dq_iomux_ddr_regs *mx6_ddr_iomux =
-   (struct mx6dq_iomux_ddr_regs *)MX6DQ_IOM_DDR_BASE;
bool cs0_enable;
bool cs1_enable;
bool cs0_enable_initial;
@@ -272,14 +296,7 @@ int mmdc_do_dqs_calibration(struct mx6_ddr_sysinfo const 
*sysinfo)
setbits_le32(>mapsr, 0x1);
  
  	/* set DQS pull ups */

-   setbits_le32(_ddr_iomux->dram_sdqs0, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs1, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs2, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs3, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs4, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs5, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs6, 0x7000);
-   setbits_le32(_ddr_iomux->dram_sdqs7, 0x7000);
+   mmdc_set_sdqs(true);
  
  	/* Save old RALAT and WALAT values */

esdmisc_val = readl(>mdmisc);
@@ -524,14 +541,7 @@ int mmdc_do_dqs_calibration(struct mx6_ddr_sysinfo const 
*sysinfo)
writel(esdmisc_val, >mdmisc);
  
  	/* Clear DQS pull ups */

-   clrbits_le32(_ddr_iomux->dram_sdqs0, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs1, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs2, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs3, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs4, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs5, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs6, 0x7000);
-   clrbits_le32(_ddr_iomux->dram_sdqs7, 0x7000);
+   mmdc_set_sdqs(false);
  
  	/* Re-enable SDE (chip selects) if they were set initially */

if (cs1_enable_initial)



Reviewed-by: Eric Nelson 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/4] ARM: mx6: ddr: Make debug prints work with tiny printf

2019-11-26 Thread Eric Nelson

Hi Marek,

On 11/26/19 1:34 AM, Marek Vasut wrote:

The %08X format returns just zeroes with tiny printf, which is
horribly confusing, especially when debugging DRAM calibration
problems. Change the format to %08x (with lowercase x), which
behaves correctly with either implementation of printf in SPL.

Signed-off-by: Marek Vasut 
Cc: Eric Nelson 
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
  arch/arm/mach-imx/mx6/ddr.c | 24 
  1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-imx/mx6/ddr.c b/arch/arm/mach-imx/mx6/ddr.c
index 84b9236249..e6f69e904f 100644
--- a/arch/arm/mach-imx/mx6/ddr.c
+++ b/arch/arm/mach-imx/mx6/ddr.c
@@ -214,14 +214,14 @@ int mmdc_do_write_level_calibration(struct 
mx6_ddr_sysinfo const *sysinfo)
writel(esdmisc_val, >mdref);
writel(zq_val, >mpzqhwctrl);
  
-	debug("\tMMDC_MPWLDECTRL0 after write level cal: 0x%08X\n",

+   debug("\tMMDC_MPWLDECTRL0 after write level cal: 0x%08x\n",
  readl(>mpwldectrl0));
-   debug("\tMMDC_MPWLDECTRL1 after write level cal: 0x%08X\n",
+   debug("\tMMDC_MPWLDECTRL1 after write level cal: 0x%08x\n",
  readl(>mpwldectrl1));
if (sysinfo->dsize == 2) {
-   debug("\tMMDC_MPWLDECTRL0 after write level cal: 0x%08X\n",
+   debug("\tMMDC_MPWLDECTRL0 after write level cal: 0x%08x\n",
  readl(>mpwldectrl0));
-   debug("\tMMDC_MPWLDECTRL1 after write level cal: 0x%08X\n",
+   debug("\tMMDC_MPWLDECTRL1 after write level cal: 0x%08x\n",
  readl(>mpwldectrl1));
}
  
@@ -557,20 +557,20 @@ int mmdc_do_dqs_calibration(struct mx6_ddr_sysinfo const *sysinfo)

 */
debug("MMDC registers updated from calibration\n");
debug("Read DQS gating calibration:\n");
-   debug("\tMPDGCTRL0 PHY0 = 0x%08X\n", readl(>mpdgctrl0));
-   debug("\tMPDGCTRL1 PHY0 = 0x%08X\n", readl(>mpdgctrl1));
+   debug("\tMPDGCTRL0 PHY0 = 0x%08x\n", readl(>mpdgctrl0));
+   debug("\tMPDGCTRL1 PHY0 = 0x%08x\n", readl(>mpdgctrl1));
if (sysinfo->dsize == 2) {
-   debug("\tMPDGCTRL0 PHY1 = 0x%08X\n", readl(>mpdgctrl0));
-   debug("\tMPDGCTRL1 PHY1 = 0x%08X\n", readl(>mpdgctrl1));
+   debug("\tMPDGCTRL0 PHY1 = 0x%08x\n", readl(>mpdgctrl0));
+   debug("\tMPDGCTRL1 PHY1 = 0x%08x\n", readl(>mpdgctrl1));
}
debug("Read calibration:\n");
-   debug("\tMPRDDLCTL PHY0 = 0x%08X\n", readl(>mprddlctl));
+   debug("\tMPRDDLCTL PHY0 = 0x%08x\n", readl(>mprddlctl));
if (sysinfo->dsize == 2)
-   debug("\tMPRDDLCTL PHY1 = 0x%08X\n", readl(>mprddlctl));
+   debug("\tMPRDDLCTL PHY1 = 0x%08x\n", readl(>mprddlctl));
debug("Write calibration:\n");
-   debug("\tMPWRDLCTL PHY0 = 0x%08X\n", readl(>mpwrdlctl));
+   debug("\tMPWRDLCTL PHY0 = 0x%08x\n", readl(>mpwrdlctl));
if (sysinfo->dsize == 2)
-   debug("\tMPWRDLCTL PHY1 = 0x%08X\n", readl(>mpwrdlctl));
+   debug("\tMPWRDLCTL PHY1 = 0x%08x\n", readl(>mpwrdlctl));
  
  	/*

 * Registers below are for debugging purposes.  These print out



Reviewed-by: Eric Nelson 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/5] common: add blkcache init

2019-11-25 Thread Eric Nelson

Hi Angelo,

On 11/25/19 2:59 AM, Angelo Dureghello wrote:

Hi Eric,

On Sun, Nov 24, 2019 at 5:00 PM Eric Nelson  wrote:


Hi Angelo,

On 11/23/19 3:47 PM, Angelo Dureghello wrote:

From: Angelo Durgehello 

On m68k, block_cache list is relocated, but next and prev list
pointers are not adjusted to the relocated struct list_head address,
so the first iteration over the block_cache list hangs.

This patch initializes the block_cache list after relocation.

Signed-off-by: Angelo Durgehello 
---
   common/board_r.c | 12 
   drivers/block/blkcache.c |  7 ++-
   include/blk.h|  6 ++
   3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/common/board_r.c b/common/board_r.c
index 65720849cd..13e70a5ffb 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -628,6 +628,15 @@ static int initr_bedbug(void)
   }
   #endif

+#ifdef CONFIG_BLOCK_CACHE
+static int initr_blkcache(void)
+{
+ blkcache_init();
+
+ return 0;
+}
+#endif
+


Why the extra level of indirection?


   static int run_main_loop(void)
   {
   #ifdef CONFIG_SANDBOX
@@ -832,6 +841,9 @@ static init_fnc_t init_sequence_r[] = {
   #endif
   #if defined(CONFIG_PRAM)
   initr_mem,
+#endif
+#ifdef CONFIG_BLOCK_CACHE


It seems you could call blkcache_init from here directly:



reason for this is to maintain "initr_" naming convention, used from
quite all the initr_ calls,
as i.e. static int initr_mmc(void) that's doing the same.



Okay. I think this isn't a hard rule though (see log_init,
stdio_init_tables, etc).

I'm not sure that it would be a bad thing to rename blkcache_init
to initr_blkcache to indicate the usage.




+ initr_blkcache,
   #endif
   run_main_loop,
   };
diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c
index 1fa64989d3..bf0fa1ea6f 100644
--- a/drivers/block/blkcache.c
+++ b/drivers/block/blkcache.c
@@ -21,13 +21,18 @@ struct block_cache_node {
   char *cache;
   };

-static LIST_HEAD(block_cache);
+static struct list_head block_cache;

   static struct block_cache_stats _stats = {
   .max_blocks_per_entry = 8,
   .max_entries = 32
   };

+void blkcache_init(void)
+{
+ INIT_LIST_HEAD(_cache);
+}
+
   static struct block_cache_node *cache_find(int iftype, int devnum,
  lbaint_t start, lbaint_t blkcnt,
  unsigned long blksz)
diff --git a/include/blk.h b/include/blk.h
index d0c033aece..7070fd6af3 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -113,6 +113,12 @@ struct blk_desc {
   (PAD_SIZE(size, blk_desc->blksz))

   #if CONFIG_IS_ENABLED(BLOCK_CACHE)
+
+/**
+ * blkcache_init() - initialize the block cache list pointers
+ */
+void blkcache_init(void);
+
   /**
* blkcache_read() - attempt to read a set of blocks from cache
*




Regards,
--
Angelo Dureghello



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


Re: [U-Boot] [PATCH 2/5] common: add blkcache init

2019-11-25 Thread Eric Nelson

Hi Angelo,

On 11/25/19 2:59 AM, Angelo Dureghello wrote:

Hi Eric,

On Sun, Nov 24, 2019 at 5:00 PM Eric Nelson  wrote:


Hi Angelo,

On 11/23/19 3:47 PM, Angelo Dureghello wrote:

From: Angelo Durgehello 

On m68k, block_cache list is relocated, but next and prev list
pointers are not adjusted to the relocated struct list_head address,
so the first iteration over the block_cache list hangs.

This patch initializes the block_cache list after relocation.

Signed-off-by: Angelo Durgehello 
---
   common/board_r.c | 12 
   drivers/block/blkcache.c |  7 ++-
   include/blk.h|  6 ++
   3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/common/board_r.c b/common/board_r.c
index 65720849cd..13e70a5ffb 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -628,6 +628,15 @@ static int initr_bedbug(void)
   }
   #endif

+#ifdef CONFIG_BLOCK_CACHE
+static int initr_blkcache(void)
+{
+ blkcache_init();
+
+ return 0;
+}
+#endif
+


Why the extra level of indirection?


   static int run_main_loop(void)
   {
   #ifdef CONFIG_SANDBOX
@@ -832,6 +841,9 @@ static init_fnc_t init_sequence_r[] = {
   #endif
   #if defined(CONFIG_PRAM)
   initr_mem,
+#endif
+#ifdef CONFIG_BLOCK_CACHE


It seems you could call blkcache_init from here directly:



reason for this is to maintain "initr_" naming convention, used from
quite all the initr_ calls,
as i.e. static int initr_mmc(void) that's doing the same.



Okay. I think this isn't a hard rule though (see log_init,
stdio_init_tables, etc).

I'm not sure that it would be a bad thing to rename blkcache_init
to initr_blkcache to indicate the usage.




+ initr_blkcache,
   #endif
   run_main_loop,
   };
diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c
index 1fa64989d3..bf0fa1ea6f 100644
--- a/drivers/block/blkcache.c
+++ b/drivers/block/blkcache.c
@@ -21,13 +21,18 @@ struct block_cache_node {
   char *cache;
   };

-static LIST_HEAD(block_cache);
+static struct list_head block_cache;

   static struct block_cache_stats _stats = {
   .max_blocks_per_entry = 8,
   .max_entries = 32
   };

+void blkcache_init(void)
+{
+ INIT_LIST_HEAD(_cache);
+}
+
   static struct block_cache_node *cache_find(int iftype, int devnum,
  lbaint_t start, lbaint_t blkcnt,
  unsigned long blksz)
diff --git a/include/blk.h b/include/blk.h
index d0c033aece..7070fd6af3 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -113,6 +113,12 @@ struct blk_desc {
   (PAD_SIZE(size, blk_desc->blksz))

   #if CONFIG_IS_ENABLED(BLOCK_CACHE)
+
+/**
+ * blkcache_init() - initialize the block cache list pointers
+ */
+void blkcache_init(void);
+
   /**
* blkcache_read() - attempt to read a set of blocks from cache
*




Regards,
--
Angelo Dureghello



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


Re: [U-Boot] [PATCH 2/5] common: add blkcache init

2019-11-24 Thread Eric Nelson

Hi Angelo,

On 11/23/19 3:47 PM, Angelo Dureghello wrote:

From: Angelo Durgehello 

On m68k, block_cache list is relocated, but next and prev list
pointers are not adjusted to the relocated struct list_head address,
so the first iteration over the block_cache list hangs.

This patch initializes the block_cache list after relocation.

Signed-off-by: Angelo Durgehello 
---
  common/board_r.c | 12 
  drivers/block/blkcache.c |  7 ++-
  include/blk.h|  6 ++
  3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/common/board_r.c b/common/board_r.c
index 65720849cd..13e70a5ffb 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -628,6 +628,15 @@ static int initr_bedbug(void)
  }
  #endif
  
+#ifdef CONFIG_BLOCK_CACHE

+static int initr_blkcache(void)
+{
+   blkcache_init();
+
+   return 0;
+}
+#endif
+


Why the extra level of indirection?


  static int run_main_loop(void)
  {
  #ifdef CONFIG_SANDBOX
@@ -832,6 +841,9 @@ static init_fnc_t init_sequence_r[] = {
  #endif
  #if defined(CONFIG_PRAM)
initr_mem,
+#endif
+#ifdef CONFIG_BLOCK_CACHE


It seems you could call blkcache_init from here directly:


+   initr_blkcache,
  #endif
run_main_loop,
  };
diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c
index 1fa64989d3..bf0fa1ea6f 100644
--- a/drivers/block/blkcache.c
+++ b/drivers/block/blkcache.c
@@ -21,13 +21,18 @@ struct block_cache_node {
char *cache;
  };
  
-static LIST_HEAD(block_cache);

+static struct list_head block_cache;
  
  static struct block_cache_stats _stats = {

.max_blocks_per_entry = 8,
.max_entries = 32
  };
  
+void blkcache_init(void)

+{
+   INIT_LIST_HEAD(_cache);
+}
+
  static struct block_cache_node *cache_find(int iftype, int devnum,
   lbaint_t start, lbaint_t blkcnt,
   unsigned long blksz)
diff --git a/include/blk.h b/include/blk.h
index d0c033aece..7070fd6af3 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -113,6 +113,12 @@ struct blk_desc {
(PAD_SIZE(size, blk_desc->blksz))
  
  #if CONFIG_IS_ENABLED(BLOCK_CACHE)

+
+/**
+ * blkcache_init() - initialize the block cache list pointers
+ */
+void blkcache_init(void);
+
  /**
   * blkcache_read() - attempt to read a set of blocks from cache
   *



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


[U-Boot] [PATCH] imx: iomux-v3: fix IOMUX_PADS for single-CPU variant

2018-07-17 Thread Eric Nelson
When compiling for a single CPU variant (e.g. MX6Q or MX6DL),
the IOMUX constants are named MX6_PAD_blah, not MX6Q_PAD_blah.

Fix the macros IOMUX_PADS and SETUP_IOMUX_PAD to reflect this.

Signed-off-by: Eric Nelson 
---
 arch/arm/include/asm/mach-imx/iomux-v3.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/mach-imx/iomux-v3.h 
b/arch/arm/include/asm/mach-imx/iomux-v3.h
index bb93058..4be1c53 100644
--- a/arch/arm/include/asm/mach-imx/iomux-v3.h
+++ b/arch/arm/include/asm/mach-imx/iomux-v3.h
@@ -267,9 +267,9 @@ if (is_mx6dq() || is_mx6dqp()) {
\
 #define SETUP_IOMUX_PADS(x)\
imx_iomux_v3_setup_multiple_pads(x, ARRAY_SIZE(x)/2)
 #elif defined(CONFIG_MX6Q) || defined(CONFIG_MX6D)
-#define IOMUX_PADS(x) MX6Q_##x
+#define IOMUX_PADS(x) MX6_##x
 #define SETUP_IOMUX_PAD(def)   \
-   imx_iomux_v3_setup_pad(MX6Q_##def);
+   imx_iomux_v3_setup_pad(MX6_##def);
 #define SETUP_IOMUX_PADS(x)\
imx_iomux_v3_setup_multiple_pads(x, ARRAY_SIZE(x))
 #elif defined(CONFIG_MX6UL) || defined(CONFIG_MX6ULL)
-- 
2.7.4

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


Re: [U-Boot] [PATCH] ARM: mx6: ddr: Add write leveling correction code

2018-03-30 Thread Eric Nelson

Hi Marek,

Thanks for this update and the detailed notes.

On 03/29/2018 06:04 PM, Marek Vasut wrote:

When the DDR calibration is enabled, a situation may happen that it
will fail on a few select boards out of a whole production lot. In
particular, after the first write leveling stage, the MPWLDECTRLx
registers will contain a value 0x1nn , for nn usually being 0x7f or
slightly lower.

What this means is that the HW write leveling detected that the DQS
rising edge on one or more bundles arrives slightly _after_ CLK and
therefore when the DDR DRAM samples CLK on the DQS rising edge, the
CLK signal is already high (cfr. AN4467 rev2 Figure 7 on page 18).

The HW write leveling then ends up adding almost an entire cycle (thus
the 0x17f) to the DQS delay, which indeed aligns it, but also triggers
subsequent calibration failure in DQS gating due to this massive offset.

There are two observations here:
- If the MPWLDECTRLx value is corrected from 0x17f to 0x0 , then the
   DQS gating passes, the entire calibration passes as well and the
   DRAM is perfectly stable even under massive load.
- When using the NXP DRAM calibrator for iMX6/7, the value 0x17f or so
   in MPWLDECTRx register is not there, but it is replaced by 0x0 as one
   would expect.

Someone from NXP finally explains why, quoting [1]:

 "
 Having said all that, the DDR Stress Test does something that we
 do not advertise to the users. The Stress Test iself looks at the
 values of the MPWLDECTRL0/1 fields before reporting results, and
 if it sees any filed with a value greater than 200/256 delay
 (reported as half-cycle = 0x1 and ABS_OFFSET > 0x48), the DDR
 Stress test will reset the Write Leveling delay for this lane
 to 0x000 and not report it in the log.

 The reason that the DDR Stress test does this is because a delay
 of more than 78% a clock cycle means that the DQS edge is arriving
 within the JEDEC tolerence of 25% of the clock edge. In most cases,
 DQS is arriving < 5% tCK of the SDCLK edge in the early case, and
 it does not make sense to delay the DQS strobe almost a full clock
 cycle and add extra latency to each Write burst just to make the
 two edges align exactly. In this case, we are guilty of making a
 decision for the customer without telling them we are doing it so
 that we don't have to provide the above explanation to every customer.
 They don't need to know it.
 "

This patch adds the correction described above, that is if the MPWLDECTRx
value is over 0x148, the value is corrected back to 0x0.

[1] https://community.nxp.com/thread/456246

Signed-off-by: Marek Vasut <ma...@denx.de>
Cc: Stefano Babic <sba...@denx.de>
---
  arch/arm/mach-imx/mx6/ddr.c | 24 
  1 file changed, 24 insertions(+)

diff --git a/arch/arm/mach-imx/mx6/ddr.c b/arch/arm/mach-imx/mx6/ddr.c
index 43b77cfa41..6e5e40dd1a 100644
--- a/arch/arm/mach-imx/mx6/ddr.c
+++ b/arch/arm/mach-imx/mx6/ddr.c
@@ -85,6 +85,23 @@ static void modify_dg_result(u32 *reg_st0, u32 *reg_st1, u32 
*reg_ctrl)
writel(val_ctrl, reg_ctrl);
  }
  
+static void correct_mpwldectr_result(void *reg)

+{
+   /* Limit is 200/256 of CK, which is WL_HC_DELx | 0x48. */
+   const unsigned int limit = 0x148;
+   u32 val = readl(reg);
+   u32 old = val;
+


Nit: I think "val &= 0x" would be slightly easier to read
instead of the "<< 16":


+   if ((val & 0x17f) > limit)
+   val &= 0x << 16;
+
+   if (((val >> 16) & 0x17f) > limit)
+   val &= 0x;
+
+   if (old != val)
+   writel(val, reg);
+}
+
  int mmdc_do_write_level_calibration(struct mx6_ddr_sysinfo const *sysinfo)
  {
struct mmdc_p_regs *mmdc0 = (struct mmdc_p_regs *)MMDC_P0_BASE_ADDR;
@@ -176,6 +193,13 @@ int mmdc_do_write_level_calibration(struct mx6_ddr_sysinfo 
const *sysinfo)
errors |= 4;
}
  
+	correct_mpwldectr_result(>mpwldectrl0);

+   correct_mpwldectr_result(>mpwldectrl1);
+   if (sysinfo->dsize == 2) {
+   correct_mpwldectr_result(>mpwldectrl0);
+   correct_mpwldectr_result(>mpwldectrl1);
+   }
+
/*
 * User should issue MRS command to exit write leveling mode
 * through Load Mode Register command



Otherwise,

Reviewed-by: Eric Nelson <e...@nelint.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [RFC PATCH] SPL: allow fall-back to SDP boot

2018-01-20 Thread Eric Nelson
When SDP is enabled, allow it to be invoked as a fall-back
to allow re-programming a board with a full U-Boot loaded
over USB.

Signed-off-by: Eric Nelson <e...@nelint.com>
---
Since SDP loading is triggered through BOOT_DEVICE_BOARD, I'm not sure
if this should be specific to SDP.

 common/spl/spl.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index 76c1963..5bbd4ed 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -373,6 +373,9 @@ static int boot_from_devices(struct spl_image_info 
*spl_image,
 
 void board_init_r(gd_t *dummy1, ulong dummy2)
 {
+#ifdef CONFIG_SPL_USB_SDP_SUPPORT
+   int i;
+#endif
u32 spl_boot_list[] = {
BOOT_DEVICE_NONE,
BOOT_DEVICE_NONE,
@@ -417,6 +420,15 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
 #endif
board_boot_order(spl_boot_list);
 
+#ifdef CONFIG_SPL_USB_SDP_SUPPORT
+   for (i = 0; i < ARRAY_SIZE(spl_boot_list); i++) {
+   if (spl_boot_list[i] == BOOT_DEVICE_NONE) {
+   spl_boot_list[i] = BOOT_DEVICE_BOARD;
+   break;
+   }
+   }
+#endif
+
if (boot_from_devices(_image, spl_boot_list,
  ARRAY_SIZE(spl_boot_list))) {
puts("SPL: failed to boot from all boot devices\n");
-- 
2.7.4

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


[U-Boot] [PATCH] mx6memcal: fix comment in board header file

2018-01-18 Thread Eric Nelson
The board header file included a reference to the starting point
from nitrogen6x.h, but since so much changed, the file bears
little resemblance to that file.

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 include/configs/mx6memcal.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/include/configs/mx6memcal.h b/include/configs/mx6memcal.h
index 28c67c4..5be8ce4 100644
--- a/include/configs/mx6memcal.h
+++ b/include/configs/mx6memcal.h
@@ -1,8 +1,7 @@
 /*
- * Copyright (C) 2010-2011 Freescale Semiconductor, Inc.
+ * Copyright (C) 2010-2018 Freescale Semiconductor, Inc.
  *
- * Configuration settings for the Boundary Devices Nitrogen6X
- * and Freescale i.MX6Q Sabre Lite boards.
+ * Configuration settings for the virtual mx6memcal board.
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
-- 
2.7.4

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


[U-Boot] [PATCH 2/2] mx6memcal: enable SDP support

2018-01-18 Thread Eric Nelson
The initial implementation of mx6memcal reset the CPU after
running the memory calibration procedure because the generic
board has no information about which boot devices are available.

Now that we have SDP support in SPL, use it to allow a full
U-Boot to be uploaded (i.e. to use "mtest").

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 board/freescale/mx6memcal/spl.c |  1 -
 configs/mx6memcal_defconfig | 10 ++
 include/configs/mx6memcal.h |  2 ++
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/board/freescale/mx6memcal/spl.c b/board/freescale/mx6memcal/spl.c
index 8ee89ff..805fdab 100644
--- a/board/freescale/mx6memcal/spl.c
+++ b/board/freescale/mx6memcal/spl.c
@@ -452,5 +452,4 @@ void board_init_f(ulong dummy)
display_calibration();
}
}
-   reset_cpu(0);
 }
diff --git a/configs/mx6memcal_defconfig b/configs/mx6memcal_defconfig
index b27330c..d3720dc 100644
--- a/configs/mx6memcal_defconfig
+++ b/configs/mx6memcal_defconfig
@@ -8,6 +8,10 @@ CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_SPL_WATCHDOG_SUPPORT=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg,SPL,MX6QDL"
 CONFIG_SPL=y
+CONFIG_SPL_USB_HOST_SUPPORT=y
+CONFIG_SPL_USB_GADGET_SUPPORT=y
+CONFIG_SPL_USBETH_SUPPORT=y
+CONFIG_SPL_USB_SDP_SUPPORT=y
 CONFIG_HUSH_PARSER=y
 # CONFIG_CMD_BOOTD is not set
 # CONFIG_CMD_BOOTM is not set
@@ -29,4 +33,10 @@ CONFIG_CMD_MEMTEST=y
 # CONFIG_CMD_NFS is not set
 CONFIG_CMD_CACHE=y
 # CONFIG_MMC is not set
+CONFIG_USB=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="FSL"
+CONFIG_USB_GADGET_VENDOR_NUM=0x0525
+CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
+CONFIG_CI_UDC=y
 CONFIG_REGEX=y
diff --git a/include/configs/mx6memcal.h b/include/configs/mx6memcal.h
index f5238a5..28c67c4 100644
--- a/include/configs/mx6memcal.h
+++ b/include/configs/mx6memcal.h
@@ -56,4 +56,6 @@
 
 #define CONFIG_ENV_SIZE(8 * 1024)
 
+#define CONFIG_MXC_USB_PORTSC  PORT_PTS_UTMI
+
 #endif/* __CONFIG_H */
-- 
2.7.4

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


[U-Boot] [PATCH 1/2] mx6memcal: launder through savedefconfig

2018-01-18 Thread Eric Nelson
This patch just changes the order of configuration items in
mx6memcal_defconfig to match the Kconfig layout, making it easier
to track changes made using menuconfig.

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 configs/mx6memcal_defconfig | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/configs/mx6memcal_defconfig b/configs/mx6memcal_defconfig
index 9a3bb83..b27330c 100644
--- a/configs/mx6memcal_defconfig
+++ b/configs/mx6memcal_defconfig
@@ -9,25 +9,24 @@ CONFIG_SPL_WATCHDOG_SUPPORT=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg,SPL,MX6QDL"
 CONFIG_SPL=y
 CONFIG_HUSH_PARSER=y
-# CONFIG_MMC is not set
 # CONFIG_CMD_BOOTD is not set
 # CONFIG_CMD_BOOTM is not set
 # CONFIG_CMD_ELF is not set
 # CONFIG_CMD_IMI is not set
-# CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_XIMG is not set
 # CONFIG_CMD_EXPORTENV is not set
 # CONFIG_CMD_IMPORTENV is not set
 # CONFIG_CMD_EDITENV is not set
 # CONFIG_CMD_SAVEENV is not set
 # CONFIG_CMD_ENV_EXISTS is not set
-CONFIG_CMD_MEMTEST=y
 CONFIG_CMD_MEMINFO=y
-# CONFIG_CMD_LOADB is not set
-# CONFIG_CMD_LOADS is not set
+CONFIG_CMD_MEMTEST=y
 # CONFIG_CMD_FLASH is not set
 # CONFIG_CMD_FPGA is not set
+# CONFIG_CMD_LOADB is not set
+# CONFIG_CMD_LOADS is not set
 # CONFIG_CMD_NET is not set
 # CONFIG_CMD_NFS is not set
 CONFIG_CMD_CACHE=y
+# CONFIG_MMC is not set
 CONFIG_REGEX=y
-- 
2.7.4

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


[U-Boot] [PATCH V2] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model

2017-10-11 Thread Eric Nelson
Commit 6fbbcfd introduced device-tree support for MMC devices on
the mx7sabresd boards and didn't include BLK, which requires BLK.

Commit 8ae5bb3 did the same for secure boot.

Fix both by allowing blk-uclass (BLK) support.

Tested-by: Fabio Estevam <feste...@gmail.com>
Signed-off-by: Eric Nelson <e...@nelint.com>
---
V2 includes the updated to mx7dsabresd_secure_defconfig
 configs/mx7dsabresd_defconfig| 1 -
 configs/mx7dsabresd_secure_defconfig | 1 -
 2 files changed, 2 deletions(-)

diff --git a/configs/mx7dsabresd_defconfig b/configs/mx7dsabresd_defconfig
index 795c4f2..144fb50 100644
--- a/configs/mx7dsabresd_defconfig
+++ b/configs/mx7dsabresd_defconfig
@@ -38,7 +38,6 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
-# CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DM_GPIO=y
diff --git a/configs/mx7dsabresd_secure_defconfig 
b/configs/mx7dsabresd_secure_defconfig
index bd68831..d1af138 100644
--- a/configs/mx7dsabresd_secure_defconfig
+++ b/configs/mx7dsabresd_secure_defconfig
@@ -40,7 +40,6 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
-# CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DM_GPIO=y
-- 
2.7.4

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


Re: [U-Boot] [PATCH] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model

2017-10-11 Thread Eric Nelson

Hi Tom,

On 10/11/2017 01:51 PM, Tom Rini wrote:

On Wed, Oct 11, 2017 at 05:50:04PM -0300, Fabio Estevam wrote:

Hi Eric,

That was the fix I was waiting for, thanks!

On Wed, Oct 11, 2017 at 5:29 PM, Eric Nelson <e...@nelint.com> wrote:

Please add a commit log and explain that this fixes a regression.


Change-Id: I1bdfffe782a61a4c688f1bb56e85448024cd497b


Please remove this line.

Also, when you send a v2, please do the same change in
mx7dsabresd_secure_defconfig.


Signed-off-by: Eric Nelson <e...@nelint.com>


Now I can boot a kernel successfully, thanks:

Tested-by: Fabio Estevam <fabio.este...@nxp.com>


Is there perhaps a dependency here we need to enforce via Kconfig so
this isn't a game of whack-a-mole?  Thanks!



We have a "default Y if DM" for it, which should be enough.

http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/block/Kconfig;h=26760895f99dd53370f9077f5b7213a1a6f241fe;hb=HEAD#l3

Commit 6fbbcfd explicitly disabled it when converting to
DM_MMC (secure_defconfig followed suit in commit 8ae5bb3), and
that's where the trouble came in.

Hmmm. A quick search shows that quite a few configurations
have this choice (CONFIG_DM_MMC without CONFIG_BLK):

~u-boot/configs$ git grep -l CONFIG_DM_MMC=y | xargs grep BLK
am335x_boneblack_vboot_defconfig:# CONFIG_BLK is not set
am335x_evm_defconfig:# CONFIG_BLK is not set
am335x_hs_evm_defconfig:# CONFIG_BLK is not set
am43xx_evm_defconfig:# CONFIG_BLK is not set
am43xx_evm_usbhost_boot_defconfig:# CONFIG_BLK is not set
am43xx_hs_evm_defconfig:# CONFIG_BLK is not set
am57xx_evm_defconfig:# CONFIG_BLK is not set
am57xx_hs_evm_defconfig:# CONFIG_BLK is not set
k2g_evm_defconfig:# CONFIG_BLK is not set
k2g_hs_evm_defconfig:# CONFIG_BLK is not set
ls1012aqds_qspi_defconfig:# CONFIG_BLK is not set
ls1012ardb_qspi_defconfig:# CONFIG_BLK is not set
mx6slevk_defconfig:# CONFIG_BLK is not set
mx6slevk_spinor_defconfig:# CONFIG_BLK is not set
mx6sllevk_defconfig:# CONFIG_BLK is not set
mx6sllevk_plugin_defconfig:# CONFIG_BLK is not set
mx6sxsabreauto_defconfig:# CONFIG_BLK is not set
mx6ull_14x14_evk_defconfig:# CONFIG_BLK is not set
mx6ull_14x14_evk_plugin_defconfig:# CONFIG_BLK is not set
mx7ulp_evk_defconfig:# CONFIG_BLK is not set
mx7ulp_evk_plugin_defconfig:# CONFIG_BLK is not set
omap3_logic_defconfig:# CONFIG_BLK is not set
pic32mzdask_defconfig:# CONFIG_BLK is not set

Are all of these broken?

I don't have any of the other boards, and am not in a
position to say whether there's a legitimate use case
for DM_MMC without BLK.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model

2017-10-11 Thread Eric Nelson

Hi Fabio,

On 10/11/2017 01:50 PM, Fabio Estevam wrote:

Hi Eric,

That was the fix I was waiting for, thanks!



Glad to hear it.


On Wed, Oct 11, 2017 at 5:29 PM, Eric Nelson <e...@nelint.com> wrote:

Please add a commit log and explain that this fixes a regression.



Okay. If you insist ;)


Change-Id: I1bdfffe782a61a4c688f1bb56e85448024cd497b


Please remove this line.



Oops. I think we need to refresh checkpatch. I think the
version in the kernel tree checks for that.


Also, when you send a v2, please do the same change in
mx7dsabresd_secure_defconfig.



Okay.


Signed-off-by: Eric Nelson <e...@nelint.com>


Now I can boot a kernel successfully, thanks:

Tested-by: Fabio Estevam <fabio.este...@nxp.com>



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


[U-Boot] [PATCH] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model

2017-10-11 Thread Eric Nelson
Change-Id: I1bdfffe782a61a4c688f1bb56e85448024cd497b
Signed-off-by: Eric Nelson <e...@nelint.com>
---
 configs/mx7dsabresd_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/mx7dsabresd_defconfig b/configs/mx7dsabresd_defconfig
index 795c4f2..144fb50 100644
--- a/configs/mx7dsabresd_defconfig
+++ b/configs/mx7dsabresd_defconfig
@@ -38,7 +38,6 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
-# CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DM_GPIO=y
-- 
2.7.4

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


Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

2017-10-02 Thread Eric Nelson

Hi Stefano,

On 10/02/2017 06:21 AM, Stefano Babic wrote:

On 31/08/2017 00:13, Eric Nelson wrote:

This adds support for two additional boot modes on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

1. "bmode usb" can be used to force the ROM boot loader's serial
2. "bmode normal" can be used to revert to the normal boot mode
as specified by fuses and BOOT_MODE pins

Signed-off-by: Eric Nelson <e...@nelint.com>
---
V2 adds "normal" mode as suggested by Troy Kisky
  arch/arm/mach-imx/mx7/soc.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 87bf105..15be42a 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -372,6 +372,9 @@ void set_wdog_reset(struct wdog_regs *wdog)
   * to SBMR1, which will determine the boot device.
   */
  const struct boot_mode soc_boot_modes[] = {
+   {"normal",MAKE_CFGVAL(0x00, 0x00, 0x00, 0x00)},
+   {"usb",   MAKE_CFGVAL(0x01, 0x00, 0x00, 0x00)},
+
{"ecspi1:0",  MAKE_CFGVAL(0x00, 0x60, 0x00, 0x00)},
{"ecspi1:1",  MAKE_CFGVAL(0x40, 0x62, 0x00, 0x00)},
{"ecspi1:2",  MAKE_CFGVAL(0x80, 0x64, 0x00, 0x00)},



Sorry, it was for a long time in the queue - discussion in thread is
spreading away from the original review (I had errouneosly set it to
Changes requested).

Applied to u-boot-imx, -master, thanks !



Sorry, but we rejected this patch (because it doesn't work).

https://patchwork.ozlabs.org/patch/807934/

Regards,


Eric

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


Re: [U-Boot] [PATCH v3 2/2] imx_common: detect USB serial downloader reliably

2017-09-13 Thread Eric Nelson

Hi Stefan,

Thanks for this patch.

On 09/13/2017 02:29 PM, Stefan Agner wrote:

From: Stefan Agner <stefan.ag...@toradex.com>

The current mechanism using SCR/GPR registers work well when
the serial downloader boot mode has been selected explicitly
(either via boot mode pins or using bmode command). However,
in case the system entered boot ROM due to unbootable primary
boot devices (e.g. empty eMMC), the SPL fails to detect that
it has been downloaded through serial loader and tries to
continue booting from eMMC:
   Trying to boot from MMC1
   mmc_load_image_raw_sector: mmc block read error
   SPL: failed to boot from all boot devices
   ### ERROR ### Please RESET the board ###

The only known way to reliably detect USB serial downloader
is by checking the USB PHY receiver block power state...

Signed-off-by: Stefan Agner <stefan.ag...@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswi...@toradex.com>
Tested-by: Fabio Estevam <fabio.este...@nxp.com>
---

Changes in v4:
- Rename macro to is_usbotg_phy_active()

Changes in v3:
- Fix spelling and grammar

Changes in v2:
- Add comment that we infer boot ROM behavior from USB PHY state

  arch/arm/mach-imx/spl.c | 12 
  1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index 258578ac25..534cc6504d 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -31,6 +31,18 @@ u32 spl_boot_device(void)
if (((bmode >> 24) & 0x03) == 0x01) /* Serial Downloader */
return BOOT_DEVICE_BOARD;
  
+	/*

+* The above method does not detect that the boot ROM used
+* serial downloader in case the boot ROM decided to use the
+* serial downloader as a fall back (primary boot source failed).
+*
+* Infer that the boot ROM used the USB serial downloader by
+* checking whether the USB PHY is currently active... This
+* assumes that SPL did not (yet) initialize the USB PHY...
+*/
+   if (is_otgusb_phy_active())
+   return BOOT_DEVICE_BOARD;
+
/* BOOT_CFG1[7:4] - see IMX6DQRM Table 8-8 */
switch ((reg & IMX6_BMODE_MASK) >> IMX6_BMODE_SHIFT) {
 /* EIM: See 8.5.1, Table 8-9 */



Reviewed-by: Eric Nelson <e...@nelint.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 1/2] imx: add macro to detect whether USB PHY is active

2017-09-13 Thread Eric Nelson

On 09/13/2017 02:29 PM, Stefan Agner wrote:

From: Stefan Agner <stefan.ag...@toradex.com>

This macro allows to detect whether the USB PHY is active. This
is helpful to detect if the boot ROM has previously started the
USB serial downloader.

The idea is taken from the mfgtool support in the NXP U-Boot:
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/?h=imx_v2016.03_4.1.15_2.0.0_ga=a352ed3c5184b95c4c9f7468f5fbb5f43de5e412

Signed-off-by: Stefan Agner <stefan.ag...@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswi...@toradex.com>
Tested-by: Fabio Estevam <fabio.este...@nxp.com>
---

Changes in v4:
- Rename macro to is_usbotg_phy_active()

Changes in v3: None
Changes in v2:
- Move macro to sys_proto.h
- Renamed from is_boot_from_usb() to is_usbphy_active()
- Use defines for register offset and field
- Remove tab after define
- Remove comment since the actual "magic" is happening and
   documented at usage side

  arch/arm/include/asm/arch-mx6/sys_proto.h | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h 
b/arch/arm/include/asm/arch-mx6/sys_proto.h
index 14f5d948c9..ba73943260 100644
--- a/arch/arm/include/asm/arch-mx6/sys_proto.h
+++ b/arch/arm/include/asm/arch-mx6/sys_proto.h
@@ -6,3 +6,10 @@
   */
  
  #include 


I'd be more worried about these macro names (asking that they also
include "OTG") if they weren't defined in such close proximity to
their only use.


+
+#define USBPHY_PWD 0x
+
+#define USBPHY_PWD_RXPWDRX (1 << 20) /* receiver block power down */
+
+#define is_usbotg_phy_active(void) (!(readl(USB_PHY0_BASE_ADDR + USBPHY_PWD) & 
\
+  USBPHY_PWD_RXPWDRX))



Otherwise,

Reviewed-by: Eric Nelson <e...@nelint.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 1/2] imx: add macro to detect whether USB PHY is active

2017-09-13 Thread Eric Nelson

Hi Stefan,

On 09/13/2017 12:47 PM, Stefan Agner wrote:

On 2017-09-13 02:19, Stefano Babic wrote:

Hi Eric, Stefan,

On 13/09/2017 02:30, Eric Nelson wrote:

Hi Stefan,

I hate to be fussy about this, but I don't think I saw a reply
to my earlier comment about the term "USB PHY".

https://lists.denx.de/pipermail/u-boot/2017-September/305123.html

Since i.MX6 SoCs have USB **Host** Phy's as well as the USB OTG Phy,
this patch is a bit misleading.

There's no reference to OTG anywhere in this or patch 2.



Hm, sorry I missed that.


No worries. We're here to nag...



To be consistent with the names, Eric is right. We have PHY0 for OTG and
PHY1 for Host. If you still want to use as name is_usbphy_active, then
this should take as parameter the phy number, or you switch to a "otg"
name to ensure that it is only for the OTG interface.


For the registers itself I followed the notation used in chapter 66 and
arch/arm/include/asm/arch-mx6/imx-regs.h.

Renaming the function macro makes sense I agree.

The USB serial downloader only works with the OTG USB PHY anyway, so I
will rename it. I like to have USB still in there, how about:

is_usbotg_phy_active()



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


Re: [U-Boot] [PATCH v3 1/2] imx: add macro to detect whether USB PHY is active

2017-09-12 Thread Eric Nelson

Hi Stefan,

I hate to be fussy about this, but I don't think I saw a reply
to my earlier comment about the term "USB PHY".

https://lists.denx.de/pipermail/u-boot/2017-September/305123.html

Since i.MX6 SoCs have USB **Host** Phy's as well as the USB OTG Phy,
this patch is a bit misleading.

There's no reference to OTG anywhere in this or patch 2.

On 09/12/2017 04:54 PM, Stefan Agner wrote:

From: Stefan Agner 

This macro allows to detect whether the USB PHY is active. This
is helpful to detect if the boot ROM has previously started the
USB serial downloader.

The idea is taken from the mfgtool support in the NXP U-Boot:
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/?h=imx_v2016.03_4.1.15_2.0.0_ga=a352ed3c5184b95c4c9f7468f5fbb5f43de5e412

Signed-off-by: Stefan Agner 
Acked-by: Marcel Ziswiler 
Tested-by: Fabio Estevam 
---

Changes in v3: None
Changes in v2:
- Move macro to sys_proto.h
- Renamed from is_boot_from_usb() to is_usbphy_active()
- Use defines for register offset and field
- Remove tab after define
- Remove comment since the actual "magic" is happening and
   documented at usage side

  arch/arm/include/asm/arch-mx6/sys_proto.h | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h 
b/arch/arm/include/asm/arch-mx6/sys_proto.h
index 14f5d948c9..9d4b1d6768 100644
--- a/arch/arm/include/asm/arch-mx6/sys_proto.h
+++ b/arch/arm/include/asm/arch-mx6/sys_proto.h
@@ -6,3 +6,10 @@
   */
  
  #include 

+
+#define USBPHY_PWD 0x
+
+#define USBPHY_PWD_RXPWDRX (1 << 20) /* receiver block power down */
+
+#define is_usbphy_active(void) (!(readl(USB_PHY0_BASE_ADDR + USBPHY_PWD) & \
+  USBPHY_PWD_RXPWDRX))



Regards,


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


Re: [U-Boot] [PATCH v2 2/2] imx_common: detect USB serial downloader reliably

2017-09-08 Thread Eric Nelson

Hi Stefan,

On 09/08/2017 05:35 PM, Fabio Estevam wrote:

On Fri, Sep 8, 2017 at 8:35 PM, Stefan Agner  wrote:


+   /*
+* The above method does not detect that the boot ROM used
+* serial downloader in case the boot ROM descided to use the 


Typo: decided



You know you're on the right track when the only comments about
your patch are about naming, spelling and grammar ;)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/2] imx_common: detect USB serial downloader reliably

2017-09-08 Thread Eric Nelson

Hi Stefan,

On 09/08/2017 05:16 PM, Stefan Agner wrote:

On 2017-09-08 16:41, Eric Nelson wrote:

On 09/08/2017 04:35 PM, Stefan Agner wrote:

From: Stefan Agner <stefan.ag...@toradex.com>







Nit: should be "did not initialize" instead of "initialized".


Sorry, don't get that. Below I write "did not (yet) initialized"...



The proper English usage here is "did not (yet) initialize".

You don't need the past tense after "did not".

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


Re: [U-Boot] [PATCH v2 2/2] imx_common: detect USB serial downloader reliably

2017-09-08 Thread Eric Nelson

Hi Stefan,

On 09/08/2017 04:35 PM, Stefan Agner wrote:

From: Stefan Agner 

The current mechanism using SCR/GPR registers work well when
the serial downloader boot mode has been selected explicitly
(either via boot mode pins or using bmode command). However,
in case the system entered boot ROM due to unbootable primary
boot devices (e.g. empty eMMC), the SPL fails to detect that
it has been downloaded through serial loader and tries to
continue booting from eMMC:
   Trying to boot from MMC1
   mmc_load_image_raw_sector: mmc block read error
   SPL: failed to boot from all boot devices
   ### ERROR ### Please RESET the board ###

The only known way to reliably detect USB serial downloader
is by checking the USB PHY receiver block power state...

Signed-off-by: Stefan Agner 
Acked-by: Marcel Ziswiler 
Tested-by: Fabio Estevam 
---

Changes in v2:
- Add comment that we infer boot ROM behavior from USB PHY state

  arch/arm/mach-imx/spl.c | 12 
  1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index 258578ac25..f3fec81de7 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -31,6 +31,18 @@ u32 spl_boot_device(void)
if (((bmode >> 24) & 0x03) == 0x01) /* Serial Downloader */
return BOOT_DEVICE_BOARD;
  
+	/*

+* The above method does not detect that the boot ROM used
+* serial downloader in case the boot ROM descided to use the
+* serial downloader as a fall back (primary boot source failed).
+*


Nit: should be "did not initialize" instead of "initialized".

Otherwise, this is a nice comment that describes the situation.


+* Infer that the boot ROM used the USB serial downloader by
+* checking whether the USB PHY is currently active... This
+* assumes that SPL did not (yet) initialized the USB PHY...
+*/
+   if (is_usbphy_active())
+   return BOOT_DEVICE_BOARD;
+
/* BOOT_CFG1[7:4] - see IMX6DQRM Table 8-8 */
switch ((reg & IMX6_BMODE_MASK) >> IMX6_BMODE_SHIFT) {
 /* EIM: See 8.5.1, Table 8-9 */


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


Re: [U-Boot] [PATCH v2 1/2] imx: add macro to detect whether USB PHY is active

2017-09-08 Thread Eric Nelson

Hi Stefan,

On 09/08/2017 04:35 PM, Stefan Agner wrote:

From: Stefan Agner 

This macro allows to detect whether the USB PHY is active. This
is helpful to detect if the boot ROM has previously started the
USB serial downloader.

The idea is taken from the mfgtool support in the NXP U-Boot:
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/?h=imx_v2016.03_4.1.15_2.0.0_ga=a352ed3c5184b95c4c9f7468f5fbb5f43de5e412

Signed-off-by: Stefan Agner 
Acked-by: Marcel Ziswiler 
Tested-by: Fabio Estevam 
---

Changes in v2:
- Move macro to sys_proto.h
- Renamed from is_boot_from_usb() to is_usbphy_active()
- Use defines for register offset and field
- Remove tab after define
- Remove comment since the actual "magic" is happening and
   documented at usage side

  arch/arm/include/asm/arch-mx6/sys_proto.h | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h 
b/arch/arm/include/asm/arch-mx6/sys_proto.h
index 14f5d948c9..9d4b1d6768 100644
--- a/arch/arm/include/asm/arch-mx6/sys_proto.h
+++ b/arch/arm/include/asm/arch-mx6/sys_proto.h
@@ -6,3 +6,10 @@
   */
  
  #include 

+
+#define USBPHY_PWD 0x
+
+#define USBPHY_PWD_RXPWDRX (1 << 20) /* receiver block power down */
+


At least MX6 and MX7 have USB Host PHY as well as USB OTG.

How about is_otgphy_active() instead?


+#define is_usbphy_active(void) (!(readl(USB_PHY0_BASE_ADDR + USBPHY_PWD) & \
+  USBPHY_PWD_RXPWDRX))


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


Re: [U-Boot] video: ipu_common: fix build error

2017-09-07 Thread Eric Nelson

On 09/06/2017 11:01 PM, Lothar Waßmann wrote:

On Wed, 6 Sep 2017 10:34:33 -0700 Eric Nelson wrote:

On 09/05/2017 06:16 PM, Peng Fan wrote:

On Mon, Sep 04, 2017 at 07:48:56PM -0700, Eric Nelson wrote:

Hi Peng,

Can you tell that I'm hunting a bug in an old version?

I'm seeing a **very** intermittent regression between U-Boot
versions 2015.07 and 2016.05 and happened to spot something
in this patch.

On 04/27/2016 07:07 PM, Peng Fan wrote:

Some toolchains fail to build
"clk->rate = (u64)(clk->parent->rate * 16) / div;"
And the cast usage is wrong.

Use the following code to fix the issue,
"
do_div(parent_rate, div);
clk->rate = parent_rate;
"

Reported-by: Peter Robinson <pbrobin...@gmail.com>
Signed-off-by: Peng Fan <van.free...@gmail.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Tom Rini <tr...@konsulko.com>
Cc: Anatolij Gustschin <ag...@denx.de>
Cc: Peter Robinson <pbrobin...@gmail.com>
Reviewed-by: Tom Rini <tr...@konsulko.com>
Tested-by: Peter Robinson <pbrobin...@gmail.com>
---

Hi Peter,

   Please help test this patch to see whether this fix your issue or not.
   Thanks for pointing out this issue.

Thanks,
Peng.

   drivers/video/ipu_common.c | 4 +++-
   1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/ipu_common.c b/drivers/video/ipu_common.c
index 36d4b23..5676a0f 100644
--- a/drivers/video/ipu_common.c
+++ b/drivers/video/ipu_common.c
@@ -352,7 +352,9 @@ static int ipu_pixel_clk_set_rate(struct clk *clk, unsigned 
long rate)
 */
__raw_writel((div / 16) << 16, DI_BS_CLKGEN1(clk->id));


Did we lose a multiply by 16 in this change?


We already have "parent_rate = (unsigned long long)clk->parent->rate * 16;"
in this function.



Hmmm. So this patch also fixed a bug, since we previously had
**two** multiply-by-16's:


No! The 'second' multiply by 16 used the clk->parent->rate, not the
'parent_rate' which was multiplied by 16...

| parent_rate = (unsigned long long)clk->parent->rate * 16;
[...]
| clk->rate = (u64)(clk->parent->rate * 16) / div;



Doh! I clearly missed that.

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


Re: [U-Boot] [PATCH] ipu_common: Let the MX6 IPU clock be calculated in run-time

2017-09-06 Thread Eric Nelson

Thanks Fabio,

On 09/06/2017 09:49 AM, Fabio Estevam wrote:

From: Fabio Estevam <fabio.este...@nxp.com>

MX6Q/QP IPU operates at 264MHz and MX6DL IPU at 198MHz.

When running a SPL target, which supports multiple MX6 variants we cannot
properly setup the IPU clock frequency via CONFIG_IPUV3_CLK option as
such decision is done in build-time currently.

Remove the CONFIG_IPUV3_CLK option and let the IPU clock frequency be
configured in run-time on mx6.

Reported-by: Eric Nelson <e...@nelint.com>
Signed-off-by: Fabio Estevam <fabio.este...@nxp.com>
---
Changes since v1:
- Improve the mx6 detection logic (Troy)

  drivers/video/ipu_common.c| 14 +-
  include/configs/advantech_dms-ba16.h  |  1 -
  include/configs/apalis_imx6.h |  1 -
  include/configs/aristainetos-common.h |  1 -
  include/configs/cgtqmx6eval.h |  4 
  include/configs/cm_fx6.h  |  1 -
  include/configs/colibri_imx6.h|  1 -
  include/configs/embestmx6boards.h |  1 -
  include/configs/ge_bx50v3.h   |  1 -
  include/configs/gw_ventana.h  |  1 -
  include/configs/imx6-engicam.h|  1 -
  include/configs/m53evk.h  |  1 -
  include/configs/mx51evk.h |  1 -
  include/configs/mx53cx9020.h  |  1 -
  include/configs/mx53loco.h|  1 -
  include/configs/mx6cuboxi.h   |  1 -
  include/configs/mx6sabre_common.h |  5 -
  include/configs/nitrogen6x.h  |  1 -
  include/configs/novena.h  |  1 -
  include/configs/tbs2910.h |  1 -
  include/configs/wandboard.h   |  1 -
  scripts/config_whitelist.txt  |  1 -
  22 files changed, 13 insertions(+), 29 deletions(-)

diff --git a/drivers/video/ipu_common.c b/drivers/video/ipu_common.c
index f8d4488..a9584b8 100644
--- a/drivers/video/ipu_common.c
+++ b/drivers/video/ipu_common.c
@@ -19,6 +19,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include "ipu.h"
  #include "ipu_regs.h"
@@ -81,6 +82,11 @@ struct ipu_ch_param {
  
  #define IPU_SW_RST_TOUT_USEC	(1)
  
+#define IPUV3_CLK_MX51		13300

+#define IPUV3_CLK_MX53 2
+#define IPUV3_CLK_MX6Q 26400
+#define IPUV3_CLK_MX6DL19800
+
  void clk_enable(struct clk *clk)
  {
if (clk) {
@@ -196,7 +202,6 @@ static void clk_ipu_disable(struct clk *clk)
  
  static struct clk ipu_clk = {

.name = "ipu_clk",
-   .rate = CONFIG_IPUV3_CLK,
  #if defined(CONFIG_MX51) || defined(CONFIG_MX53)
.enable_reg = (u32 *)(CCM_BASE_ADDR +
offsetof(struct mxc_ccm_reg, CCGR5)),
@@ -476,6 +481,13 @@ int ipu_probe(void)
g_pixel_clk[1] = _clk[1];
  
  	g_ipu_clk = _clk;

+#if defined(CONFIG_MX51)
+   g_ipu_clk->rate = IPUV3_CLK_MX51;
+#elif defined(CONFIG_MX53)
+   g_ipu_clk->rate = IPUV3_CLK_MX53;
+#else
+   g_ipu_clk->rate = is_mx6sdl() ? IPUV3_CLK_MX6DL : IPUV3_CLK_MX6Q;
+#endif
debug("ipu_clk = %u\n", clk_get_rate(g_ipu_clk));
g_ldb_clk = _clk;
debug("ldb_clk = %u\n", clk_get_rate(g_ldb_clk));
diff --git a/include/configs/advantech_dms-ba16.h 
b/include/configs/advantech_dms-ba16.h
index 6329bf6..6e380d0 100644
--- a/include/configs/advantech_dms-ba16.h
+++ b/include/configs/advantech_dms-ba16.h
@@ -260,7 +260,6 @@
  #define CONFIG_BMP_16BPP
  #define CONFIG_VIDEO_LOGO
  #define CONFIG_VIDEO_BMP_LOGO
-#define CONFIG_IPUV3_CLK26000
  #define CONFIG_IMX_HDMI
  #define CONFIG_IMX_VIDEO_SKIP
  #endif
diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h
index 16af141..f10ce6d 100644
--- a/include/configs/apalis_imx6.h
+++ b/include/configs/apalis_imx6.h
@@ -124,7 +124,6 @@
  #define CONFIG_BMP_16BPP
  #define CONFIG_VIDEO_LOGO
  #define CONFIG_VIDEO_BMP_LOGO
-#define CONFIG_IPUV3_CLK   26000
  #define CONFIG_CONSOLE_MUX
  #define CONFIG_IMX_HDMI
  #define CONFIG_IMX_VIDEO_SKIP
diff --git a/include/configs/aristainetos-common.h 
b/include/configs/aristainetos-common.h
index 1c28fcf..3afc7a6 100644
--- a/include/configs/aristainetos-common.h
+++ b/include/configs/aristainetos-common.h
@@ -217,7 +217,6 @@
  #define CONFIG_BMP_16BPP
  #define CONFIG_VIDEO_LOGO
  #define CONFIG_VIDEO_BMP_LOGO
-#define CONFIG_IPUV3_CLK 19800
  #define CONFIG_IMX_VIDEO_SKIP
  
  #define CONFIG_PWM_IMX

diff --git a/include/configs/cgtqmx6eval.h b/include/configs/cgtqmx6eval.h
index 4996a89..6a6c063 100644
--- a/include/configs/cgtqmx6eval.h
+++ b/include/configs/cgtqmx6eval.h
@@ -87,10 +87,6 @@
  #define CONFIG_BMP_16BPP
  #define CONFIG_VIDEO_LOGO
  #define CONFIG_VIDEO_BMP_LOGO
-#ifdef CONFIG_MX6DL
-#define CONFIG_IPUV3_CLK 19800
-#else
-#define CONFIG_IPUV3_CLK 26400
  #endif
  #define CONFIG_IMX_HDMI
  
diff --git a/include/configs/cm_fx6.h b/include/configs/cm_fx6.h

index 4f45be1..5d4b670 100644
--- a/include/config

Re: [U-Boot] [U-Boot,2/3] imx: mx6: correct IPU clock

2017-09-06 Thread Eric Nelson

Thanks Ye (and Peng).

On 09/06/2017 02:37 AM, Ye Li wrote:

On 9/5/2017 6:33 PM, Eric Nelson wrote:

Hi Peng,

Pardon the reference to an old update, but do you have a description
of the symptoms that brought about this patch?

On 03/09/2016 01:07 AM, Peng Fan wrote:

The CONFIG_IPUV3_CLK should be 26400, to i.MX6DL, it should be
19800.

Signed-off-by: Peng Fan <van.free...@gmail.com>
Signed-off-by: Sandor Yu <sandor...@nxp.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Peter Robinson <pbrobin...@gmail.com>
---
include/configs/mx6sabre_common.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/configs/mx6sabre_common.h 
b/include/configs/mx6sabre_common.h
index 29d1f91..a6d821b 100644
--- a/include/configs/mx6sabre_common.h
+++ b/include/configs/mx6sabre_common.h
@@ -225,7 +225,11 @@
#define CONFIG_BMP_16BPP
#define CONFIG_VIDEO_LOGO
#define CONFIG_VIDEO_BMP_LOGO
-#define CONFIG_IPUV3_CLK 26000
+#ifdef CONFIG_MX6DL
+#define CONFIG_IPUV3_CLK 19800
+#else
+#define CONFIG_IPUV3_CLK 26400
+#endif



Note that this should probably be applied for other boards
which are compiled for multiple CPU types.

At least the Boundary Nitrogen boards, but probably others
like Wand have ordering options for DL or Solo processors
and may need the reduced clock rate.



#define CONFIG_IMX_HDMI
#define CONFIG_IMX_VIDEO_SKIP



Please advise,


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



CONFIG_IPUV3_CLK is used to indicate the default rate for IPU HSP clock.
The IPU driver in u-boot won't calculate the HSP clock rate according to
CCM registers, it needs this setting to know current rate. 198Mhz is the
correct value on DL not the 264Mhz.

If you select IPU DI clock (pixel clock) derived from HSP clock not the
external clock like LDB DI clock, I believe the 264Mhz will cause problem.



Do you know what sort of problem was seen (if any)?

Please advise,


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


Re: [U-Boot] video: ipu_common: fix build error

2017-09-06 Thread Eric Nelson

Thanks Peng.

On 09/05/2017 06:16 PM, Peng Fan wrote:

On Mon, Sep 04, 2017 at 07:48:56PM -0700, Eric Nelson wrote:

Hi Peng,

Can you tell that I'm hunting a bug in an old version?

I'm seeing a **very** intermittent regression between U-Boot
versions 2015.07 and 2016.05 and happened to spot something
in this patch.

On 04/27/2016 07:07 PM, Peng Fan wrote:

Some toolchains fail to build
"clk->rate = (u64)(clk->parent->rate * 16) / div;"
And the cast usage is wrong.

Use the following code to fix the issue,
"
   do_div(parent_rate, div);
   clk->rate = parent_rate;
"

Reported-by: Peter Robinson <pbrobin...@gmail.com>
Signed-off-by: Peng Fan <van.free...@gmail.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Tom Rini <tr...@konsulko.com>
Cc: Anatolij Gustschin <ag...@denx.de>
Cc: Peter Robinson <pbrobin...@gmail.com>
Reviewed-by: Tom Rini <tr...@konsulko.com>
Tested-by: Peter Robinson <pbrobin...@gmail.com>
---

Hi Peter,

  Please help test this patch to see whether this fix your issue or not.
  Thanks for pointing out this issue.

Thanks,
Peng.

  drivers/video/ipu_common.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/ipu_common.c b/drivers/video/ipu_common.c
index 36d4b23..5676a0f 100644
--- a/drivers/video/ipu_common.c
+++ b/drivers/video/ipu_common.c
@@ -352,7 +352,9 @@ static int ipu_pixel_clk_set_rate(struct clk *clk, unsigned 
long rate)
 */
__raw_writel((div / 16) << 16, DI_BS_CLKGEN1(clk->id));


Did we lose a multiply by 16 in this change?


We already have "parent_rate = (unsigned long long)clk->parent->rate * 16;"
in this function.



Hmmm. So this patch also fixed a bug, since we previously had
**two** multiply-by-16's:

http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/video/ipu_common.c;hb=3cb4f25cc702db17455583599d0940c81337a17a

Regards,


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


Re: [U-Boot] video: ipu_common: fix build error

2017-09-05 Thread Eric Nelson

Hi Fabio,

On 09/05/2017 06:33 AM, Fabio Estevam wrote:

Hi Eric,

On Mon, Sep 4, 2017 at 11:49 PM, Eric Nelson <e...@nelint.com> wrote:

Hi Peng,

Can you tell that I'm hunting a bug in an old version?

I'm seeing a **very** intermittent regression between U-Boot
versions 2015.07 and 2016.05 and happened to spot something
in this patch.


Just curious: how does the regression manifest itself?



With **some** televisions at a client site, on **some** power-on
cycles, the HDMI output under Linux doesn't seem to be generated
properly.

We haven't been able to reproduce it in-house, so testing is
taking a while, and we haven't (yet) determined if the
divisor patch has anything to do with the problem.

We are running on an i.MX6DL, but the IPU clock frequency
change doesn't fix the issue (running at 19.8MHz instead of
26MHz).

All we know at the moment is that version 2015.07 works and
2016.05 fails with essentially no changes to the board files.

We're doing this remotely across time zones with limited access
to failing machine(s), so it may take the rest of the week
before we know for sure.

I'll update the thread when we nail it down.

Regards,


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


Re: [U-Boot] [PATCH v1 1/2] imx: add macro to detect whether USB has been initialized

2017-09-05 Thread Eric Nelson

Hi Stefano,

On 09/05/2017 04:16 AM, Stefano Babic wrote:

Hi Stefan,
On 05/09/2017 03:21, Stefan Agner wrote:

From: Stefan Agner 

This macro allows to detect whether the boot ROM initialized USB
already (serial downloader). This is helpful to reliably detect
if the system has been recovered via USB serial downloader.

Signed-off-by: Stefan Agner 
Acked-by: Marcel Ziswiler 
---
Hi Stefano,

I noted already in my initial post that detection of serial
downloader mode is somewhat brittle:
https://lists.denx.de/pipermail/u-boot/2017-August/301952.html

This came up quite fast now also for other boards:
https://www.mail-archive.com/u-boot@lists.denx.de/msg262234.html

We use this patches since quite some time. Also NXP uses this
detection method to start their mfgr tools...


Then it seems to be an "undocumented feature" rather a hack.



This patch only detects that the OTG PHY is active, so it's
not really a hack.

The next patch uses this to infer how it happened (booted using
SDP), and since I don't think there's another way for that to
happen, it also seems to be reasonable.

Can you think of another way that the OTG PHY could be alive
when the code is hit in SPL?

... A comment to that effect is probably in order though.

Please advise,


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


Re: [U-Boot] [PATCH v1 1/2] imx: add macro to detect whether USB has been initialized

2017-09-05 Thread Eric Nelson

Hi Stefan,

On 09/04/2017 09:50 PM, Stefan Agner wrote:

On 2017-09-04 19:57, Eric Nelson wrote:

On 09/04/2017 06:21 PM, Stefan Agner wrote:





+
+/*
+ * If ROM fell back to USB recover mode, USBPH0_PWD will be clear to use USB
+ * If boot from the other mode, USB0_PWD will keep reset value
+ */
+#defineis_boot_from_usb(void) (!(readl(USB_PHY0_BASE_ADDR) & (1<<20)))
+
   #endif /* __ASSEMBLER__*/
   #endif /* __ASM_ARCH_MX6_IMX_REGS_H__ */


If I'm reading your comment correctly, the RXPWDRX bit will be set (the
PHY will be powered down) unless it was enabled by the Boot ROM.

Won't this also be clear if you've run 'usb start' under U-Boot?


Yes, this only works before a USB initialization...



Based on this, I'd recommend changing the macro name to something
like "is_udc_active" to reflect it's true meaning.


This should be fine for the use case I have in mind (see patch 2).

Note this idea is borrowed from NXP downstream and seems to work here:
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/arch/arm/include/asm/arch-mx7/imx-regs.h?h=imx_v2016.03_4.1.15_2.0.0_ga#n1204



Understood.

Using this detection mechanism in SPL (where there isn't another path
for initializing the UDC) makes sense.

Regards,


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


Re: [U-Boot] [U-Boot,2/3] imx: mx6: correct IPU clock

2017-09-05 Thread Eric Nelson

Hi Stefano,

On 09/05/2017 06:30 AM, Stefano Babic wrote:

On 05/09/2017 14:56, Fabio Estevam wrote:

Hi Eric,

On Mon, Sep 4, 2017 at 11:37 PM, Eric Nelson <ericnelso...@gmail.com> wrote:


--- a/include/configs/mx6sabre_common.h
+++ b/include/configs/mx6sabre_common.h
@@ -225,7 +225,11 @@
   #define CONFIG_BMP_16BPP
   #define CONFIG_VIDEO_LOGO
   #define CONFIG_VIDEO_BMP_LOGO
-#define CONFIG_IPUV3_CLK 26000
+#ifdef CONFIG_MX6DL
+#define CONFIG_IPUV3_CLK 19800
+#else
+#define CONFIG_IPUV3_CLK 26400
+#endif




Note that this should probably be applied for other boards
which are compiled for multiple CPU types.

At least the Boundary Nitrogen boards, but probably others
like Wand have ordering options for DL or Solo processors
and may need the reduced clock rate.


Agreed. The clock frequency decision should be done in run-time rather
than in build-time.


I agree, too. We have mechanism to take decisions at run time, at least
based on SOC type. Anyway, Anatolji has already merged this - should be
better to revert it ?



I don't think it should be reverted until we have a run-time decision
in place, or we'll re-introduce whatever problem the higher rate
caused, at least on SABRE boards with Solo or Dual-Lite processors.

I'm still wondering whether Peng has a description of the ramifications
of the higher rate on DL/Solo processors.

Regards,


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


Re: [U-Boot] video: ipu_common: fix build error

2017-09-05 Thread Eric Nelson

Hi Peng,

Can you tell that I'm hunting a bug in an old version?

I'm seeing a **very** intermittent regression between U-Boot
versions 2015.07 and 2016.05 and happened to spot something
in this patch.

On 04/27/2016 07:07 PM, Peng Fan wrote:

Some toolchains fail to build
"clk->rate = (u64)(clk->parent->rate * 16) / div;"
And the cast usage is wrong.

Use the following code to fix the issue,
"
   do_div(parent_rate, div);
   clk->rate = parent_rate;
"

Reported-by: Peter Robinson 
Signed-off-by: Peng Fan 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Tom Rini 
Cc: Anatolij Gustschin 
Cc: Peter Robinson 
Reviewed-by: Tom Rini 
Tested-by: Peter Robinson 
---

Hi Peter,

  Please help test this patch to see whether this fix your issue or not.
  Thanks for pointing out this issue.

Thanks,
Peng.

  drivers/video/ipu_common.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/ipu_common.c b/drivers/video/ipu_common.c
index 36d4b23..5676a0f 100644
--- a/drivers/video/ipu_common.c
+++ b/drivers/video/ipu_common.c
@@ -352,7 +352,9 @@ static int ipu_pixel_clk_set_rate(struct clk *clk, unsigned 
long rate)
 */
__raw_writel((div / 16) << 16, DI_BS_CLKGEN1(clk->id));
  


Did we lose a multiply by 16 in this change?


-   clk->rate = (u64)(clk->parent->rate * 16) / div;
+   do_div(parent_rate, div);
+
+   clk->rate = parent_rate;
  
  	return 0;

  }



Please advise,


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


Re: [U-Boot] [U-Boot,2/3] imx: mx6: correct IPU clock

2017-09-05 Thread Eric Nelson

Hi Peng,

Pardon the reference to an old update, but do you have a description
of the symptoms that brought about this patch?

On 03/09/2016 01:07 AM, Peng Fan wrote:

The CONFIG_IPUV3_CLK should be 26400, to i.MX6DL, it should be
19800.

Signed-off-by: Peng Fan 
Signed-off-by: Sandor Yu 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peter Robinson 
---
  include/configs/mx6sabre_common.h | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/configs/mx6sabre_common.h 
b/include/configs/mx6sabre_common.h
index 29d1f91..a6d821b 100644
--- a/include/configs/mx6sabre_common.h
+++ b/include/configs/mx6sabre_common.h
@@ -225,7 +225,11 @@
  #define CONFIG_BMP_16BPP
  #define CONFIG_VIDEO_LOGO
  #define CONFIG_VIDEO_BMP_LOGO
-#define CONFIG_IPUV3_CLK 26000
+#ifdef CONFIG_MX6DL
+#define CONFIG_IPUV3_CLK 19800
+#else
+#define CONFIG_IPUV3_CLK 26400
+#endif



Note that this should probably be applied for other boards
which are compiled for multiple CPU types.

At least the Boundary Nitrogen boards, but probably others
like Wand have ordering options for DL or Solo processors
and may need the reduced clock rate.



  #define CONFIG_IMX_HDMI
  #define CONFIG_IMX_VIDEO_SKIP
  


Please advise,


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


Re: [U-Boot] [PATCH v1 1/2] imx: add macro to detect whether USB has been initialized

2017-09-04 Thread Eric Nelson

Hi Stefan,

On 09/04/2017 06:21 PM, Stefan Agner wrote:

From: Stefan Agner 

This macro allows to detect whether the boot ROM initialized USB
already (serial downloader). This is helpful to reliably detect
if the system has been recovered via USB serial downloader.

Signed-off-by: Stefan Agner 
Acked-by: Marcel Ziswiler 
---
Hi Stefano,

I noted already in my initial post that detection of serial
downloader mode is somewhat brittle:
https://lists.denx.de/pipermail/u-boot/2017-August/301952.html

This came up quite fast now also for other boards:
https://www.mail-archive.com/u-boot@lists.denx.de/msg262234.html

We use this patches since quite some time. Also NXP uses this
detection method to start their mfgr tools... Altough a hack,
maybe we should still add it upstream?

--
Stefan


  arch/arm/include/asm/arch-mx6/imx-regs.h | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h 
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 86e267087a..895ef4de83 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -985,5 +985,12 @@ struct pwm_regs {
u32 pr;
u32 cnr;
  };


It seems as if you've already named a constant, so you might as well
#define and use it (USBPH0_PWD or USB0_PWD).

The reference manual seems to call it RXPWDRX though.


+
+/*
+ * If ROM fell back to USB recover mode, USBPH0_PWD will be clear to use USB
+ * If boot from the other mode, USB0_PWD will keep reset value
+ */
+#defineis_boot_from_usb(void) (!(readl(USB_PHY0_BASE_ADDR) & (1<<20)))
+
  #endif /* __ASSEMBLER__*/
  #endif /* __ASM_ARCH_MX6_IMX_REGS_H__ */


If I'm reading your comment correctly, the RXPWDRX bit will be set (the
PHY will be powered down) unless it was enabled by the Boot ROM.

Won't this also be clear if you've run 'usb start' under U-Boot?

Please advise,


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


Re: [U-Boot] video: ipu_common: fix build error

2017-09-04 Thread Eric Nelson

Hi Peng,

Can you tell that I'm hunting a bug in an old version?

I'm seeing a **very** intermittent regression between U-Boot
versions 2015.07 and 2016.05 and happened to spot something
in this patch.

On 04/27/2016 07:07 PM, Peng Fan wrote:

Some toolchains fail to build
"clk->rate = (u64)(clk->parent->rate * 16) / div;"
And the cast usage is wrong.

Use the following code to fix the issue,
"
   do_div(parent_rate, div);
   clk->rate = parent_rate;
"

Reported-by: Peter Robinson 
Signed-off-by: Peng Fan 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Tom Rini 
Cc: Anatolij Gustschin 
Cc: Peter Robinson 
Reviewed-by: Tom Rini 
Tested-by: Peter Robinson 
---

Hi Peter,

  Please help test this patch to see whether this fix your issue or not.
  Thanks for pointing out this issue.

Thanks,
Peng.

  drivers/video/ipu_common.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/ipu_common.c b/drivers/video/ipu_common.c
index 36d4b23..5676a0f 100644
--- a/drivers/video/ipu_common.c
+++ b/drivers/video/ipu_common.c
@@ -352,7 +352,9 @@ static int ipu_pixel_clk_set_rate(struct clk *clk, unsigned 
long rate)
 */
__raw_writel((div / 16) << 16, DI_BS_CLKGEN1(clk->id));
  


Did you intend to lose a multiply by 16 here?


-   clk->rate = (u64)(clk->parent->rate * 16) / div;
+   do_div(parent_rate, div);
+
+   clk->rate = parent_rate;
  
  	return 0;

  }



Please advise,


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


Re: [U-Boot] [U-Boot,2/3] imx: mx6: correct IPU clock

2017-09-04 Thread Eric Nelson

Hi all,

Adding my normal e-mail account to the chain, since the other account
isn't registered on the list.

On 09/04/2017 07:37 PM, Eric Nelson wrote:

Hi Peng,

Pardon the reference to an old update, but do you have a description
of the symptoms that brought about this patch?

On 03/09/2016 01:07 AM, Peng Fan wrote:

The CONFIG_IPUV3_CLK should be 26400, to i.MX6DL, it should be
19800.

Signed-off-by: Peng Fan <van.free...@gmail.com>
Signed-off-by: Sandor Yu <sandor...@nxp.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Fabio Estevam <fabio.este...@nxp.com>
Cc: Peter Robinson <pbrobin...@gmail.com>
---
  include/configs/mx6sabre_common.h | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/configs/mx6sabre_common.h 
b/include/configs/mx6sabre_common.h

index 29d1f91..a6d821b 100644
--- a/include/configs/mx6sabre_common.h
+++ b/include/configs/mx6sabre_common.h
@@ -225,7 +225,11 @@
  #define CONFIG_BMP_16BPP
  #define CONFIG_VIDEO_LOGO
  #define CONFIG_VIDEO_BMP_LOGO
-#define CONFIG_IPUV3_CLK 26000
+#ifdef CONFIG_MX6DL
+#define CONFIG_IPUV3_CLK 19800
+#else
+#define CONFIG_IPUV3_CLK 26400
+#endif



Note that this should probably be applied for other boards
which are compiled for multiple CPU types.

At least the Boundary Nitrogen boards, but probably others
like Wand have ordering options for DL or Solo processors
and may need the reduced clock rate.



  #define CONFIG_IMX_HDMI
  #define CONFIG_IMX_VIDEO_SKIP


Please advise,


Eric


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


Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

2017-08-31 Thread Eric Nelson

On 08/31/2017 04:11 PM, Fabio Estevam wrote:

Troy,

On Thu, Aug 31, 2017 at 7:53 PM, Troy Kisky
 wrote:

On 8/31/2017 2:28 PM, Troy Kisky wrote:



Maybe if you change the WDOG pinmux it might work ?




Worked for me

=> mm.l 302c
302c: 0003 ? 0
302c0004: 0001 ? q
=> bmod usb
resetting ...



Ok, but did you manage to successfully transfer u-boot via imx_usb_loader?

It did not work for me.



Ditto here. The OTG port didn't re-enumerate.


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


Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

2017-08-31 Thread Eric Nelson

On 08/31/2017 03:53 PM, Troy Kisky wrote:

On 8/31/2017 2:28 PM, Troy Kisky wrote:



Maybe if you change the WDOG pinmux it might work ?




Worked for me

=> mm.l 302c
302c: 0003 ? 0
302c0004: 0001 ? q
=> bmod usb
resetting ...



Hmm...

On SABRE-SD or Nitrogen7?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

2017-08-31 Thread Eric Nelson

Thanks Troy (and Peng),

On 08/31/2017 02:28 PM, Troy Kisky wrote:

On 8/31/2017 6:56 AM, Fabio Estevam wrote:

On Thu, Aug 31, 2017 at 10:35 AM, Fabio Estevam <feste...@gmail.com> wrote:

On Wed, Aug 30, 2017 at 7:13 PM, Eric Nelson <e...@nelint.com> wrote:

This adds support for two additional boot modes on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

1. "bmode usb" can be used to force the ROM boot loader's serial
2. "bmode normal" can be used to revert to the normal boot mode
as specified by fuses and BOOT_MODE pins

Signed-off-by: Eric Nelson <e...@nelint.com>


I tried testing your patch on a imx7d sabresd, but it seems there is
an issue with bmode that is unrelated to your patch.

I also did:

diff --git a/configs/mx7dsabresd_defconfig b/configs/mx7dsabresd_defconfig
index 8f2e33a..c70fde8 100644
--- a/configs/mx7dsabresd_defconfig
+++ b/configs/mx7dsabresd_defconfig
@@ -5,7 +5,6 @@ CONFIG_VIDEO=y
  # CONFIG_ARMV7_VIRT is not set
  CONFIG_IMX_RDC=y
  CONFIG_IMX_BOOTAUX=y
-# CONFIG_CMD_BMODE is not set
  CONFIG_DEFAULT_DEVICE_TREE="imx7d-sdb"
  CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx7dsabresd/imximage.cfg"
  CONFIG_BOOTDELAY=3

so that bmode command can be added.

However I am getting:

=> bmode usb
bmode - 


I missed to add 'add_board_boot_modes(board_boot_modes);'

Now I get:

=> bmode usb
resetting ...


U-Boot 2017.09-rc2-36996-g63af4b0-dirty (Aug 31 2017 - 10:53:12 -0300)

CPU:   Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 41C


Note the POR here (I would expect it to be WDOG).


Reset cause: POR
Model: Freescale i.MX7 SabreSD Board
Board: i.MX7D SABRESD in non-secure mode
DRAM:  1 GiB






I got this response from Peng when I asked him back in March of last year.


For now, bmode does not work. Since bmode use warm reset, but we now use
wdog to directly reset pmic. So bmode will not work.

Please check your code to see whether your board connect WDOG_B to pmic reset 
pin and have wdog

pinmux settings.


Thanks,
Peng.


Maybe if you change the WDOG pinmux it might work ?



The mx7dsabresd has GPIO1_IO00 configured for WDOG, and overriding it
does get rid of the POR.

Unfortunately, it also doesn't allow "bmode usb" to function.

=> mm 302c
302c: 0003 ? 0
302c0004:  ? x
=> bmode usb
resetting ...

(crickets here)

Based on this:

Rejected-by: Eric Nelson <e...@nelint.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2] imx: imx7d: remove CamelCase from ENET_xMHz macros

2017-08-31 Thread Eric Nelson
Update these macros to use all upper-case to avoid checkpatch
warnings:

ENET_25MHz,
ENET_50MHz,
ENET_125MHz,

Signed-off-by: Eric Nelson <e...@nelint.com>
---
V2 fixes a couple of references in mx7/clock.c
 arch/arm/include/asm/arch-mx7/clock.h | 6 +++---
 arch/arm/mach-imx/mx7/clock.c | 6 +++---
 board/freescale/mx7dsabresd/mx7dsabresd.c | 2 +-
 board/technexion/pico-imx7d/pico-imx7d.c  | 2 +-
 board/toradex/colibri_imx7/colibri_imx7.c | 2 +-
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx7/clock.h 
b/arch/arm/include/asm/arch-mx7/clock.h
index 688d236..3b115ad 100644
--- a/arch/arm/include/asm/arch-mx7/clock.h
+++ b/arch/arm/include/asm/arch-mx7/clock.h
@@ -318,9 +318,9 @@ struct clk_root_map {
 };
 
 enum enet_freq {
-   ENET_25MHz,
-   ENET_50MHz,
-   ENET_125MHz,
+   ENET_25MHZ,
+   ENET_50MHZ,
+   ENET_125MHZ,
 };
 
 u32 get_root_clk(enum clk_root_index clock_id);
diff --git a/arch/arm/mach-imx/mx7/clock.c b/arch/arm/mach-imx/mx7/clock.c
index 2cfde46..8150faa 100644
--- a/arch/arm/mach-imx/mx7/clock.c
+++ b/arch/arm/mach-imx/mx7/clock.c
@@ -966,15 +966,15 @@ int set_clk_enet(enum enet_freq type)
clock_enable(CCGR_ENET2, 0);
 
switch (type) {
-   case ENET_125MHz:
+   case ENET_125MHZ:
enet1_ref = ENET1_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_125M_CLK;
enet2_ref = ENET2_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_125M_CLK;
break;
-   case ENET_50MHz:
+   case ENET_50MHZ:
enet1_ref = ENET1_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_50M_CLK;
enet2_ref = ENET2_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_50M_CLK;
break;
-   case ENET_25MHz:
+   case ENET_25MHZ:
enet1_ref = ENET1_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_25M_CLK;
enet2_ref = ENET2_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_25M_CLK;
break;
diff --git a/board/freescale/mx7dsabresd/mx7dsabresd.c 
b/board/freescale/mx7dsabresd/mx7dsabresd.c
index a681ece..5819b18 100644
--- a/board/freescale/mx7dsabresd/mx7dsabresd.c
+++ b/board/freescale/mx7dsabresd/mx7dsabresd.c
@@ -260,7 +260,7 @@ static int setup_fec(void)
(IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK |
 IOMUXC_GPR_GPR1_GPR_ENET1_CLK_DIR_MASK), 0);
 
-   return set_clk_enet(ENET_125MHz);
+   return set_clk_enet(ENET_125MHZ);
 }
 
 
diff --git a/board/technexion/pico-imx7d/pico-imx7d.c 
b/board/technexion/pico-imx7d/pico-imx7d.c
index b4c9be7..67bab51 100644
--- a/board/technexion/pico-imx7d/pico-imx7d.c
+++ b/board/technexion/pico-imx7d/pico-imx7d.c
@@ -182,7 +182,7 @@ static int setup_fec(void)
(IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK |
IOMUXC_GPR_GPR1_GPR_ENET1_CLK_DIR_MASK), 0);
 
-   return set_clk_enet(ENET_125MHz);
+   return set_clk_enet(ENET_125MHZ);
 }
 
 int board_phy_config(struct phy_device *phydev)
diff --git a/board/toradex/colibri_imx7/colibri_imx7.c 
b/board/toradex/colibri_imx7/colibri_imx7.c
index 5cb14b4..13b2b57 100644
--- a/board/toradex/colibri_imx7/colibri_imx7.c
+++ b/board/toradex/colibri_imx7/colibri_imx7.c
@@ -280,7 +280,7 @@ static int setup_fec(void)
IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK);
 #endif
 
-   return set_clk_enet(ENET_50MHz);
+   return set_clk_enet(ENET_50MHZ);
 }
 
 int board_phy_config(struct phy_device *phydev)
-- 
2.7.4

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


Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

2017-08-31 Thread Eric Nelson

Hi Fabio,

On 08/31/2017 06:56 AM, Fabio Estevam wrote:

On Thu, Aug 31, 2017 at 10:35 AM, Fabio Estevam <feste...@gmail.com> wrote:

Hi Eric,

On Wed, Aug 30, 2017 at 7:13 PM, Eric Nelson <e...@nelint.com> wrote:

This adds support for two additional boot modes on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

1. "bmode usb" can be used to force the ROM boot loader's serial
2. "bmode normal" can be used to revert to the normal boot mode
as specified by fuses and BOOT_MODE pins

Signed-off-by: Eric Nelson <e...@nelint.com>


I tried testing your patch on a imx7d sabresd, but it seems there is
an issue with bmode that is unrelated to your patch.

I also did:

diff --git a/configs/mx7dsabresd_defconfig b/configs/mx7dsabresd_defconfig
index 8f2e33a..c70fde8 100644
--- a/configs/mx7dsabresd_defconfig
+++ b/configs/mx7dsabresd_defconfig
@@ -5,7 +5,6 @@ CONFIG_VIDEO=y
  # CONFIG_ARMV7_VIRT is not set
  CONFIG_IMX_RDC=y
  CONFIG_IMX_BOOTAUX=y
-# CONFIG_CMD_BMODE is not set
  CONFIG_DEFAULT_DEVICE_TREE="imx7d-sdb"
  CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx7dsabresd/imximage.cfg"
  CONFIG_BOOTDELAY=3

so that bmode command can be added.

However I am getting:

=> bmode usb
bmode - 


I missed to add 'add_board_boot_modes(board_boot_modes);'

Now I get:

=> bmode usb
resetting ...


U-Boot 2017.09-rc2-36996-g63af4b0-dirty (Aug 31 2017 - 10:53:12 -0300)

CPU:   Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 41C
Reset cause: POR
Model: Freescale i.MX7 SabreSD Board
Board: i.MX7D SABRESD in non-secure mode
DRAM:  1 GiB
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC:
MMC Device 0 not found
*** Warning - No MMC card found, using default environment

Video: 480x272x24
In:serial
Out:   serial
Err:   serial
Net:   FEC0
Hit any key to stop autoboot:  0
=>

So the board is resetting instead of going into serial download mode.

Any ideas?



I'm not sure. Since I'm currently working with a board with no
fuses blown, I'm getting USB mode either way ;)...

I have an MX7 SABRE SD and I'll try it out there.

Regards,


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


[U-Boot] [PATCH] imx: imx7d: remove CamelCase from ENET_xMHz macros

2017-08-30 Thread Eric Nelson
Update these macros to use all upper-case to avoid checkpatch
warnings:

ENET_25MHz,
ENET_50MHz,
ENET_125MHz,

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 arch/arm/include/asm/arch-mx7/clock.h | 6 +++---
 arch/arm/mach-imx/mx7/clock.c | 2 +-
 board/freescale/mx7dsabresd/mx7dsabresd.c | 2 +-
 board/technexion/pico-imx7d/pico-imx7d.c  | 2 +-
 board/toradex/colibri_imx7/colibri_imx7.c | 2 +-
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx7/clock.h 
b/arch/arm/include/asm/arch-mx7/clock.h
index 688d236..3b115ad 100644
--- a/arch/arm/include/asm/arch-mx7/clock.h
+++ b/arch/arm/include/asm/arch-mx7/clock.h
@@ -318,9 +318,9 @@ struct clk_root_map {
 };
 
 enum enet_freq {
-   ENET_25MHz,
-   ENET_50MHz,
-   ENET_125MHz,
+   ENET_25MHZ,
+   ENET_50MHZ,
+   ENET_125MHZ,
 };
 
 u32 get_root_clk(enum clk_root_index clock_id);
diff --git a/arch/arm/mach-imx/mx7/clock.c b/arch/arm/mach-imx/mx7/clock.c
index 2cfde46..423d697 100644
--- a/arch/arm/mach-imx/mx7/clock.c
+++ b/arch/arm/mach-imx/mx7/clock.c
@@ -970,7 +970,7 @@ int set_clk_enet(enum enet_freq type)
enet1_ref = ENET1_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_125M_CLK;
enet2_ref = ENET2_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_125M_CLK;
break;
-   case ENET_50MHz:
+   case ENET_50MHZ:
enet1_ref = ENET1_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_50M_CLK;
enet2_ref = ENET2_REF_CLK_ROOT_FROM_PLL_ENET_MAIN_50M_CLK;
break;
diff --git a/board/freescale/mx7dsabresd/mx7dsabresd.c 
b/board/freescale/mx7dsabresd/mx7dsabresd.c
index a681ece..5819b18 100644
--- a/board/freescale/mx7dsabresd/mx7dsabresd.c
+++ b/board/freescale/mx7dsabresd/mx7dsabresd.c
@@ -260,7 +260,7 @@ static int setup_fec(void)
(IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK |
 IOMUXC_GPR_GPR1_GPR_ENET1_CLK_DIR_MASK), 0);
 
-   return set_clk_enet(ENET_125MHz);
+   return set_clk_enet(ENET_125MHZ);
 }
 
 
diff --git a/board/technexion/pico-imx7d/pico-imx7d.c 
b/board/technexion/pico-imx7d/pico-imx7d.c
index b4c9be7..67bab51 100644
--- a/board/technexion/pico-imx7d/pico-imx7d.c
+++ b/board/technexion/pico-imx7d/pico-imx7d.c
@@ -182,7 +182,7 @@ static int setup_fec(void)
(IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK |
IOMUXC_GPR_GPR1_GPR_ENET1_CLK_DIR_MASK), 0);
 
-   return set_clk_enet(ENET_125MHz);
+   return set_clk_enet(ENET_125MHZ);
 }
 
 int board_phy_config(struct phy_device *phydev)
diff --git a/board/toradex/colibri_imx7/colibri_imx7.c 
b/board/toradex/colibri_imx7/colibri_imx7.c
index 5cb14b4..13b2b57 100644
--- a/board/toradex/colibri_imx7/colibri_imx7.c
+++ b/board/toradex/colibri_imx7/colibri_imx7.c
@@ -280,7 +280,7 @@ static int setup_fec(void)
IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK);
 #endif
 
-   return set_clk_enet(ENET_50MHz);
+   return set_clk_enet(ENET_50MHZ);
 }
 
 int board_phy_config(struct phy_device *phydev)
-- 
2.7.4

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


Re: [U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

2017-08-30 Thread Eric Nelson

Sorry for the spam.

I resent this by mistake.

On 08/30/2017 03:13 PM, Eric Nelson wrote:

This adds support for two additional boot modes on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

1. "bmode usb" can be used to force the ROM boot loader's serial
2. "bmode normal" can be used to revert to the normal boot mode
as specified by fuses and BOOT_MODE pins

Signed-off-by: Eric Nelson <e...@nelint.com>
---
V2 adds "normal" mode as suggested by Troy Kisky
  arch/arm/mach-imx/mx7/soc.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 87bf105..15be42a 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -372,6 +372,9 @@ void set_wdog_reset(struct wdog_regs *wdog)
   * to SBMR1, which will determine the boot device.
   */
  const struct boot_mode soc_boot_modes[] = {
+   {"normal",MAKE_CFGVAL(0x00, 0x00, 0x00, 0x00)},
+   {"usb",   MAKE_CFGVAL(0x01, 0x00, 0x00, 0x00)},
+
{"ecspi1:0",  MAKE_CFGVAL(0x00, 0x60, 0x00, 0x00)},
{"ecspi1:1",  MAKE_CFGVAL(0x40, 0x62, 0x00, 0x00)},
{"ecspi1:2",  MAKE_CFGVAL(0x80, 0x64, 0x00, 0x00)},



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


[U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

2017-08-30 Thread Eric Nelson
This adds support for two additional boot modes on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

1. "bmode usb" can be used to force the ROM boot loader's serial
2. "bmode normal" can be used to revert to the normal boot mode
   as specified by fuses and BOOT_MODE pins

Signed-off-by: Eric Nelson <e...@nelint.com>
---
V2 adds "normal" mode as suggested by Troy Kisky
 arch/arm/mach-imx/mx7/soc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 87bf105..15be42a 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -372,6 +372,9 @@ void set_wdog_reset(struct wdog_regs *wdog)
  * to SBMR1, which will determine the boot device.
  */
 const struct boot_mode soc_boot_modes[] = {
+   {"normal",  MAKE_CFGVAL(0x00, 0x00, 0x00, 0x00)},
+   {"usb", MAKE_CFGVAL(0x01, 0x00, 0x00, 0x00)},
+
{"ecspi1:0",MAKE_CFGVAL(0x00, 0x60, 0x00, 0x00)},
{"ecspi1:1",MAKE_CFGVAL(0x40, 0x62, 0x00, 0x00)},
{"ecspi1:2",MAKE_CFGVAL(0x80, 0x64, 0x00, 0x00)},
-- 
2.7.4

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


[U-Boot] [PATCH V2] imx: mx7: Add support for USB and normal boot modes

2017-08-30 Thread Eric Nelson
This adds support for two additional boot modes on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

1. "bmode usb" can be used to force the ROM boot loader's serial
2. "bmode normal" can be used to revert to the normal boot mode
   as specified by fuses and BOOT_MODE pins

Signed-off-by: Eric Nelson <e...@nelint.com>
---
V2 adds "normal" mode as suggested by Troy Kisky
 arch/arm/mach-imx/mx7/soc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 87bf105..15be42a 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -372,6 +372,9 @@ void set_wdog_reset(struct wdog_regs *wdog)
  * to SBMR1, which will determine the boot device.
  */
 const struct boot_mode soc_boot_modes[] = {
+   {"normal",  MAKE_CFGVAL(0x00, 0x00, 0x00, 0x00)},
+   {"usb", MAKE_CFGVAL(0x01, 0x00, 0x00, 0x00)},
+
{"ecspi1:0",MAKE_CFGVAL(0x00, 0x60, 0x00, 0x00)},
{"ecspi1:1",MAKE_CFGVAL(0x40, 0x62, 0x00, 0x00)},
{"ecspi1:2",MAKE_CFGVAL(0x80, 0x64, 0x00, 0x00)},
-- 
2.7.4

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


Re: [U-Boot] [PATCH] imx: mx7: Add support for USB boot mode

2017-08-30 Thread Eric Nelson

Hi Troy,

On 08/29/2017 11:55 AM, Troy Kisky wrote:

On 8/29/2017 7:37 AM, Eric Nelson wrote:

Hi Troy,

On 08/28/2017 09:42 AM, Troy Kisky wrote:

On 8/27/2017 3:04 PM, Eric Nelson wrote:

This adds support for USB boot mode on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

i.e., it enables you to enter the ROM boot loader's serial
download protocol using the command:

=> bmode usb

Signed-off-by: Eric Nelson <e...@nelint.com>
---
   arch/arm/mach-imx/mx7/soc.c | 2 ++
   1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 87bf105..63ee59f 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -372,6 +372,8 @@ void set_wdog_reset(struct wdog_regs *wdog)
* to SBMR1, which will determine the boot device.
*/
   const struct boot_mode soc_boot_modes[] = {


You might want to add

+   {"normal",  MAKE_CFGVAL(0x00, 0x00, 0x00, 0x00)},


while you're at it, to undo with "bmode normal"



Normal, meaning "don't override"?

Why would you want to do this?

Please advise,


Hi Eric!


If you do "bmode usb" and then use "imx_usb" to load a new u-boot.
You may want to do "bmode normal", so that a watchdog reset from
the linux kernel or from u-boot will work as expected, instead of
starting the ROM USB downloader again.



Got it.

It keeps you from reaching for the power or reset button after
using "bmode usb" or somesuch.

I'll ship a V2 momentarily.

Regards,


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


Re: [U-Boot] [PATCH] imx: mx7: Add support for USB boot mode

2017-08-29 Thread Eric Nelson

Hi Troy,

On 08/28/2017 09:42 AM, Troy Kisky wrote:

On 8/27/2017 3:04 PM, Eric Nelson wrote:

This adds support for USB boot mode on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

i.e., it enables you to enter the ROM boot loader's serial
download protocol using the command:

=> bmode usb

Signed-off-by: Eric Nelson <e...@nelint.com>
---
  arch/arm/mach-imx/mx7/soc.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 87bf105..63ee59f 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -372,6 +372,8 @@ void set_wdog_reset(struct wdog_regs *wdog)
   * to SBMR1, which will determine the boot device.
   */
  const struct boot_mode soc_boot_modes[] = {


You might want to add

+   {"normal",  MAKE_CFGVAL(0x00, 0x00, 0x00, 0x00)},


while you're at it, to undo with "bmode normal"



Normal, meaning "don't override"?

Why would you want to do this?

Please advise,


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


[U-Boot] [PATCH] imx: mx7: Add support for USB boot mode

2017-08-27 Thread Eric Nelson
This adds support for USB boot mode on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

i.e., it enables you to enter the ROM boot loader's serial
download protocol using the command:

=> bmode usb

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 arch/arm/mach-imx/mx7/soc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 87bf105..63ee59f 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -372,6 +372,8 @@ void set_wdog_reset(struct wdog_regs *wdog)
  * to SBMR1, which will determine the boot device.
  */
 const struct boot_mode soc_boot_modes[] = {
+   {"usb", MAKE_CFGVAL(0x01, 0x00, 0x00, 0x00)},
+
{"ecspi1:0",MAKE_CFGVAL(0x00, 0x60, 0x00, 0x00)},
{"ecspi1:1",MAKE_CFGVAL(0x40, 0x62, 0x00, 0x00)},
{"ecspi1:2",MAKE_CFGVAL(0x80, 0x64, 0x00, 0x00)},
-- 
2.7.4

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


Re: [U-Boot] [PATCH v1 0/7] imx: add USB Serial Download Protocol (SDP) support

2017-08-08 Thread Eric Nelson

Hi Stefan,

On 08/07/2017 11:06 AM, Stefan Agner wrote:

Hi Eric,

On 2017-08-06 08:19, Eric Nelson wrote:

Hi Stefan,

On 08/04/2017 04:38 PM, Stefan Agner wrote:

From: Stefan Agner <stefan.ag...@toradex.com>

This series adds NXP's Serial Download Protocol (SDP) support via
USB for SPL/U-Boot. It allows to download U-Boot via USB from a
(recovered) SPL using the same tools used to download SPL itself
(specifically imx_usb, but also sb_loader seems to work).



Nice!


The idea has been brought up when the first targets started to make
use of SPL for DDR initialization, see:
https://lists.denx.de/pipermail/u-boot/2015-July/220330.html



There have been lots of discussions surrounding the use of SDP,
and this seems to be a nice alternative to using the i.MX "plugin"
mode that I explored a while back:

https://lists.denx.de/pipermail/u-boot/2017-July/thread.html#298266



Hm, wasn't aware of that particular effort, thanks for pointing to it.

From a quick glance, it did not work out so far, is this correct?


That's right. I believe that the trouble is in the return-to-ROM
process. I hacked together a form of "setjmp/longjmp" to try and
get it to work, but wasn't successful and the documentation for
the entry points had me confused.



I looked into plugin mode also a little bit, but I did not continue to
look into it after reading this sentence in the i.MX 6 RM:

8.7 Plugin Image
The boot ROM detects the image type using the plugin flag of the boot
data structure (see
Boot Data Structure). If the plugin flag is 1, then the ROM uses the
image as a plugin
function. The function must initialize the boot device and copy the
program image to the
final location. At the end the plugin function must return with the
program image
parameters. (See High level boot sequence for details about boot flow).



Hmm. That doesn't seem to match the existing code in the NXP U-Boot.



So if SPL should work as a plugin as NXP defines it, SPL is supposed to
load the image from somewhere. The boot ROM then only takes care about
image verification and further boot steps, but it's the plugins job to
get the image from somewhere and store it in RAM.



I think the documentation is just misleading, as NXP is using SPL
to load the payload in stages. The ROM is loading the portion
that goes into RAM after executing the plugin to initialize the
DDR controller (and PMIC if needed).


Afact this is not really helpful in our case. We would want the boot ROM
to go through the boot sequence (again).



Not the full boot sequence. We'd just want it to load the rest of the
image into external RAM.


Unless returning an error/invalid image causes the boot ROM to go
through boot sequence again?


I'm not clear on how errors are handled.


The nice thing with our own SDP implementation is we can reuse it even
from within U-Boot again, e.g. to download a kernel/initramfs



There are lots of nice things about having SDP implemented in
open-source "C" code and I'm inclined to give up on worrying about
"plugin" mode, at least for now.

My primary rationale for trying to get plugins to work was to prevent
the need to have a "full" U-Boot for initial programming of eMMC.

There is one other use case for plugins though, and that's the
"resume from LPSR" on i.MX7. In this case, RAM already has a
running kernel loaded, but the LPDDR is in self-refresh and
something needs to detect that during boot and return after
restoring the DDR registers.


The initial SDP implementation (patch 2) requires the payload to
have the imx specific headers (hence the move of the imx header
file in patch 1).

Patch 3 extends image header support beyond the SDP specification,
specifically implements also support for U-Boot headers. This
allows to use the same SPL/U-Boot binaries for recovery as used on
the regular boot device (SD/eMMC). For that to work also the host
side imx_usb tools needed an extension, currently available here:

https://github.com/toradex/imx_loader/tree/imx_usb_batch_mode_refactored

The full patchset allows to download SPL and U-Boot over USB to a
target in recovery mode using the same usb_imx utility:


imx_usb?



Yeah right, sorry.


The usb_imx utility also has a batch mode which allows to download
multiple artifacts with a single invocation. The details are
outlined in the imx_usb commit message:
https://github.com/toradex/imx_loader/commit/5434415d921f1cc4d22332d9558bed6d42db9f60

In case this patchset gets accepted in U-Boot, I plan to push the
imx_usb changes upstream as well.



Do you have numbers for how much code/data size this adds to SPL?



Besides the protocol implementation also general USB (gadget) support is
required, hence it adds quite a bit.

Without USB Gadget/SDP support (Apalis iMX6 SPL):

$ arm-linux-gnueabihf-size spl/u-boot-spl
textdata bss dec hex filename
   245523808  92   284526f24 spl/u-boot-spl

With USB Gadge

Re: [U-Boot] [PATCH v1 0/7] imx: add USB Serial Download Protocol (SDP) support

2017-08-06 Thread Eric Nelson

Hi Stefan,

On 08/04/2017 04:38 PM, Stefan Agner wrote:

From: Stefan Agner 

This series adds NXP's Serial Download Protocol (SDP) support via
USB for SPL/U-Boot. It allows to download U-Boot via USB from a
(recovered) SPL using the same tools used to download SPL itself
(specifically imx_usb, but also sb_loader seems to work).



Nice!


The idea has been brought up when the first targets started to make
use of SPL for DDR initialization, see:
https://lists.denx.de/pipermail/u-boot/2015-July/220330.html



There have been lots of discussions surrounding the use of SDP,
and this seems to be a nice alternative to using the i.MX "plugin"
mode that I explored a while back:

https://lists.denx.de/pipermail/u-boot/2017-July/thread.html#298266


The initial SDP implementation (patch 2) requires the payload to
have the imx specific headers (hence the move of the imx header
file in patch 1).

Patch 3 extends image header support beyond the SDP specification,
specifically implements also support for U-Boot headers. This
allows to use the same SPL/U-Boot binaries for recovery as used on
the regular boot device (SD/eMMC). For that to work also the host
side imx_usb tools needed an extension, currently available here:

https://github.com/toradex/imx_loader/tree/imx_usb_batch_mode_refactored

The full patchset allows to download SPL and U-Boot over USB to a
target in recovery mode using the same usb_imx utility:


imx_usb?


The usb_imx utility also has a batch mode which allows to download
multiple artifacts with a single invocation. The details are
outlined in the imx_usb commit message:
https://github.com/toradex/imx_loader/commit/5434415d921f1cc4d22332d9558bed6d42db9f60

In case this patchset gets accepted in U-Boot, I plan to push the
imx_usb changes upstream as well.



Do you have numbers for how much code/data size this adds to SPL?

I believe some i.MX users have struggled to stay within the
size of internal RAM.

Regards,


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


Re: [U-Boot] [RFC PATCH 1/9] mx6: Add board mx6memcal for use in validating DDR

2017-07-27 Thread Eric Nelson
Hi Fabio,

On Fri, Jul 14, 2017 at 12:01 PM, Fabio Estevam <feste...@gmail.com> wrote:

> Hi Eric,
>
> On Fri, Jul 14, 2017 at 2:58 PM, Eric Nelson <e...@nelint.com> wrote:
>
> > I set this aside because I wasn't able to get the "return to
> > RBL" code working and figured I'd try to reverse-engineer the API.
> >
> > Any hints you have in that area would be helpful, and will solve
> > that other long-standing issue of how to live with SPL on i.MX.
>
> Sorry, but what does "return to RBL" mean?
>
>
I was trying to get the SPL to act as a plugin in this patch set, so we
could send
a full U-Boot with a memory test as a payload, but got stuck on the details.

https://lists.denx.de/pipermail/u-boot/2016-June/258784.html

Looking back at the patch set, the plugin support wasn't explicitly
included.

I sent some notes in November:

https://lists.denx.de/pipermail/u-boot/2016-November/271647.html

And there was some follow-up in January:

https://lists.denx.de/pipermail/u-boot/2017-January/278518.html
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC PATCH 1/9] mx6: Add board mx6memcal for use in validating DDR

2017-07-14 Thread Eric Nelson

Hi Fabio,

On 07/14/2017 07:18 AM, Fabio Estevam wrote:

Hi Eric,

On Tue, Nov 1, 2016 at 5:13 PM, Eric Nelson <e...@nelint.com> wrote:

This is a virtual "board" that uses configuration files and
Kconfig to define the memory layout used by a real board during
the board bring-up process.

It generates an SPL image that can be loaded using imx_usb or
SB_LOADER.exe.

When run, it will generate a set of calibration constants for
use in either or both a DCD configuration file for boards that
use u-boot.imx or struct mx6_mmdc_calibration for boards that
boot via SPL.

In essence, it is a configurable, open-source variant of the
Freescale ddr-stress tool.

 https://community.nxp.com/docs/DOC-105652

File mx6memcal_defconfig configures the board for use with
mx6sabresd or mx6qsabreauto.


Do you still have plans on refreshing this series?



Plans is a strong word, but I certainly hope to find some time
to continue this effort.

I haven't been doing too many new board bring-ups lately though,
so it moved away from my front burner.

I set this aside because I wasn't able to get the "return to
RBL" code working and figured I'd try to reverse-engineer the API.

Any hints you have in that area would be helpful, and will solve
that other long-standing issue of how to live with SPL on i.MX.


It does seem very useful.



It is, and even the RFC patch allows very quick testing of
large numbers of boards to gather calibration data.

Regards,


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


Re: [U-Boot] [PATCH v2 03/15] imx: Use IMX6_BMODE_* macros instead of numericals

2017-01-27 Thread Eric Nelson
Hi Jagan,

On 01/27/2017 10:54 AM, Jagan Teki wrote:
> On Fri, Jan 27, 2017 at 6:29 PM, Eric Nelson <e...@nelint.com> wrote:
>> Hi Jagan,
>>
>> On 01/27/2017 10:21 AM, Jagan Teki wrote:
>>> On Fri, Jan 27, 2017 at 4:18 PM, Eric Nelson <e...@nelint.com> wrote:
>>>> Hi Jagan,
>>>>
>>>> Love this patch! This was long overdue.
>>>>
>>>> On 01/27/2017 07:12 AM, Jagan Teki wrote:
>>>>> Use meaningful meacros IMX6_BMODE_*, instead of numerical
>>>>> number in boot mode detection code.
>>>>
>>>> s/meacros/macros/
>>>>
>>
>> 
>>
>>>>> diff --git a/arch/arm/include/asm/imx-common/sys_proto.h 
>>>>> b/arch/arm/include/asm/imx-common/sys_proto.h
>>>>> index 99e3869..d0cf3f1 100644
>>>>> --- a/arch/arm/include/asm/imx-common/sys_proto.h
>>>>> +++ b/arch/arm/include/asm/imx-common/sys_proto.h
>>>>> @@ -42,6 +42,40 @@
>>>>>  #ifdef CONFIG_MX6
>>>>>  #define IMX6_SRC_GPR10_BMODE BIT(28)
>>>>>
>>>>> +#define IMX6_BMODE_MASK  GENMASK(7, 0)
>>>>
>>>> This is a number (4), not a mask:
>>>
>>> This is 0xff not 4
>>
>> I was referring to IMX6_BMODE_SHIFT.
> 
> Sorry, I thought you replied on in-line to my messages and I'm trying
> to use bitops for possible vlaue BIT(2) make the value 4 (1 << 2)
> 

Methinks you tries too hard!

Bitops don't help when you're referring to a bit **position**, only
when referring to a mask.

>>
>>>  - switch ((reg & 0x00FF) >> 4) {
>>>  + switch ((reg & IMX6_BMODE_MASK) >> IMX6_BMODE_SHIFT) {
>>>
>>>>> +#define  IMX6_BMODE_SHIFTBIT(2)
>>>>> +#define IMX6_BMODE_EMI_MASK  BIT(3)
>>>>
>>>> Ditto (number, not mask):
>>>
>>> The reason for calling this as mask as the reg value is and'ing to
>>> mask value of 8 (which is last 0 and 1 bits)
>>>  - if ((reg & 0x0008) >> 3)
>>>  + switch ((reg & IMX6_BMODE_EMI_MASK) >> IMX6_BMODE_EMI_SHIFT) 
>>> {
>>>
>>
>> Again, I'm referring to the _SHIFT macro below:
> 
> Same comment as above.
> 
>>
>>>>> +#define IMX6_BMODE_EMI_SHIFT GENMASK(1, 0)
>>>>
>>>> Since there's also a "serial download mode", I'd prefer that these
>>>> say "SERIAL_NOR" to avoid confusion.
>>>
>>> Since serial here is also denoting I2C better to have SERIAL and we
>>> can use 'serial download' as SERIAL_DOWNLOAD or something similar.
>>>
>>
>> I2C is also serial ROM or serial NOR.
>>
>> BMODE_SERIAL just seems to have multiple meanings.
> 
> SERIAL_ROM may be better because SERIAL_NOR look spi-nor flash.
> 

Okay by me.

>>
>>>>
>>>>> +#define IMX6_BMODE_SERIAL_MASK   GENMASK(26, 24)
>>>>> +#define IMX6_BMODE_SERIAL_SHIFT  GENMASK(4, 3)
>>>>> +
>>>>
>>>> I'd prefer macros for these because they'd show the
>>>> values directly, making a comparison with the RM
>>>> easier.
>>>
>>> But these macro's making bit functioning smooth.
>>>
>>
>> My comment here was referring to the use of enums for
>> imx6_bmode, imx6_bmode_emi, and imx6_bmode_serial.
>>
>> If you use macros, it's easier to see that, for instance
>> IMX6_BMODE_EMMC == 7
> 
> May be this is true with imx6_bmode but the rest have serial in
> nature, but again enum make code compile time retain and good for for
> code readable instead of assigning values unlike macro.s
> 

If these were likely to be used more widely, I might agree, but
opinions vary.

My main thought is that having the numbers handy would make
it easier to compare against the reference manual (which I haven't)
or even the constants you just replaced (which I also haven't done).

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


Re: [U-Boot] [PATCH v2 03/15] imx: Use IMX6_BMODE_* macros instead of numericals

2017-01-27 Thread Eric Nelson
Hi Jagan,

On 01/27/2017 10:21 AM, Jagan Teki wrote:
> On Fri, Jan 27, 2017 at 4:18 PM, Eric Nelson <e...@nelint.com> wrote:
>> Hi Jagan,
>>
>> Love this patch! This was long overdue.
>>
>> On 01/27/2017 07:12 AM, Jagan Teki wrote:
>>> Use meaningful meacros IMX6_BMODE_*, instead of numerical
>>> number in boot mode detection code.
>>
>> s/meacros/macros/
>>



>>> diff --git a/arch/arm/include/asm/imx-common/sys_proto.h 
>>> b/arch/arm/include/asm/imx-common/sys_proto.h
>>> index 99e3869..d0cf3f1 100644
>>> --- a/arch/arm/include/asm/imx-common/sys_proto.h
>>> +++ b/arch/arm/include/asm/imx-common/sys_proto.h
>>> @@ -42,6 +42,40 @@
>>>  #ifdef CONFIG_MX6
>>>  #define IMX6_SRC_GPR10_BMODE BIT(28)
>>>
>>> +#define IMX6_BMODE_MASK  GENMASK(7, 0)
>>
>> This is a number (4), not a mask:
> 
> This is 0xff not 4

I was referring to IMX6_BMODE_SHIFT.

>  - switch ((reg & 0x00FF) >> 4) {
>  + switch ((reg & IMX6_BMODE_MASK) >> IMX6_BMODE_SHIFT) {
> 
>>> +#define  IMX6_BMODE_SHIFTBIT(2)
>>> +#define IMX6_BMODE_EMI_MASK  BIT(3)
>>
>> Ditto (number, not mask):
> 
> The reason for calling this as mask as the reg value is and'ing to
> mask value of 8 (which is last 0 and 1 bits)
>  - if ((reg & 0x0008) >> 3)
>  + switch ((reg & IMX6_BMODE_EMI_MASK) >> IMX6_BMODE_EMI_SHIFT) {
> 

Again, I'm referring to the _SHIFT macro below:

>>> +#define IMX6_BMODE_EMI_SHIFT GENMASK(1, 0)
>>
>> Since there's also a "serial download mode", I'd prefer that these
>> say "SERIAL_NOR" to avoid confusion.
> 
> Since serial here is also denoting I2C better to have SERIAL and we
> can use 'serial download' as SERIAL_DOWNLOAD or something similar.
> 

I2C is also serial ROM or serial NOR.

BMODE_SERIAL just seems to have multiple meanings.

>>
>>> +#define IMX6_BMODE_SERIAL_MASK   GENMASK(26, 24)
>>> +#define IMX6_BMODE_SERIAL_SHIFT  GENMASK(4, 3)
>>> +
>>
>> I'd prefer macros for these because they'd show the
>> values directly, making a comparison with the RM
>> easier.
> 
> But these macro's making bit functioning smooth.
> 

My comment here was referring to the use of enums for
imx6_bmode, imx6_bmode_emi, and imx6_bmode_serial.

If you use macros, it's easier to see that, for instance
IMX6_BMODE_EMMC == 7

> thanks!
> 

No. Thank you for the patch. This was pretty contorted previously.

Regards,


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


Re: [U-Boot] [PATCH v2 03/15] imx: Use IMX6_BMODE_* macros instead of numericals

2017-01-27 Thread Eric Nelson
Hi Jagan,

Love this patch! This was long overdue.

On 01/27/2017 07:12 AM, Jagan Teki wrote:
> Use meaningful meacros IMX6_BMODE_*, instead of numerical
> number in boot mode detection code.

s/meacros/macros/

> 
> Cc: Stefano Babic 
> Cc: Tim Harvey 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/imx-common/spl.c   | 39 
> ++---
>  arch/arm/include/asm/imx-common/sys_proto.h | 34 +
>  2 files changed, 58 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/arm/imx-common/spl.c b/arch/arm/imx-common/spl.c
> index fc3704b..38789b2 100644
> --- a/arch/arm/imx-common/spl.c
> +++ b/arch/arm/imx-common/spl.c
> @@ -30,39 +30,48 @@ u32 spl_boot_device(void)
>   if bmode >> 24) & 0x03)  == 0x01) || /* Serial Downloader */
>   (imx6_is_bmode_from_gpr9() && (reg == 1)))
>   return BOOT_DEVICE_UART;
> +
>   /* BOOT_CFG1[7:4] - see IMX6DQRM Table 8-8 */
> - switch ((reg & 0x00FF) >> 4) {
> + switch ((reg & IMX6_BMODE_MASK) >> IMX6_BMODE_SHIFT) {
>/* EIM: See 8.5.1, Table 8-9 */
> - case 0x0:
> + case IMX6_BMODE_EMI:
>   /* BOOT_CFG1[3]: NOR/OneNAND Selection */
> - if ((reg & 0x0008) >> 3)
> + switch ((reg & IMX6_BMODE_EMI_MASK) >> IMX6_BMODE_EMI_SHIFT) {
> + case IMX6_BMODE_ONENAND:
>   return BOOT_DEVICE_ONENAND;
> - else
> + case IMX6_BMODE_NOR:
>   return BOOT_DEVICE_NOR;
> - break;
> + }
>   /* SATA: See 8.5.4, Table 8-20 */
> - case 0x2:
> + case IMX6_BMODE_SATA:
>   return BOOT_DEVICE_SATA;
>   /* Serial ROM: See 8.5.5.1, Table 8-22 */
> - case 0x3:
> + case IMX6_BMODE_SERIAL:
>   /* BOOT_CFG4[2:0] */
> - switch ((reg & 0x0700) >> 24) {
> - case 0x0 ... 0x4:
> + switch ((reg & IMX6_BMODE_SERIAL_MASK) >>
> + IMX6_BMODE_SERIAL_SHIFT) {
> + case IMX6_BMODE_ECSPI1:
> + case IMX6_BMODE_ECSPI2:
> + case IMX6_BMODE_ECSPI3:
> + case IMX6_BMODE_ECSPI4:
> + case IMX6_BMODE_ECSPI5:
>   return BOOT_DEVICE_SPI;
> - case 0x5 ... 0x7:
> + case IMX6_BMODE_I2C1:
> + case IMX6_BMODE_I2C2:
> + case IMX6_BMODE_I2C3:
>   return BOOT_DEVICE_I2C;
>   }
>   break;
>   /* SD/eSD: 8.5.3, Table 8-15  */
> - case 0x4:
> - case 0x5:
> + case IMX6_BMODE_SD:
> + case IMX6_BMODE_ESD:
>   return BOOT_DEVICE_MMC1;
>   /* MMC/eMMC: 8.5.3 */
> - case 0x6:
> - case 0x7:
> + case IMX6_BMODE_MMC:
> + case IMX6_BMODE_EMMC:
>   return BOOT_DEVICE_MMC1;
>   /* NAND Flash: 8.5.2, Table 8-10 */
> - case 0x8:
> + case IMX6_BMODE_NAND:
>   return BOOT_DEVICE_NAND;
>   }
>   return BOOT_DEVICE_NONE;
> diff --git a/arch/arm/include/asm/imx-common/sys_proto.h 
> b/arch/arm/include/asm/imx-common/sys_proto.h
> index 99e3869..d0cf3f1 100644
> --- a/arch/arm/include/asm/imx-common/sys_proto.h
> +++ b/arch/arm/include/asm/imx-common/sys_proto.h
> @@ -42,6 +42,40 @@
>  #ifdef CONFIG_MX6
>  #define IMX6_SRC_GPR10_BMODE BIT(28)
>  
> +#define IMX6_BMODE_MASK  GENMASK(7, 0)

This is a number (4), not a mask:
> +#define  IMX6_BMODE_SHIFTBIT(2)
> +#define IMX6_BMODE_EMI_MASK  BIT(3)

Ditto (number, not mask):
> +#define IMX6_BMODE_EMI_SHIFT GENMASK(1, 0)

Since there's also a "serial download mode", I'd prefer that these
say "SERIAL_NOR" to avoid confusion.

> +#define IMX6_BMODE_SERIAL_MASK   GENMASK(26, 24)
> +#define IMX6_BMODE_SERIAL_SHIFT  GENMASK(4, 3)
> +

I'd prefer macros for these because they'd show the
values directly, making a comparison with the RM
easier.

> +enum imx6_bmode_serial {
> + IMX6_BMODE_ECSPI1,
> + IMX6_BMODE_ECSPI2,
> + IMX6_BMODE_ECSPI3,
> + IMX6_BMODE_ECSPI4,
> + IMX6_BMODE_ECSPI5,
> + IMX6_BMODE_I2C1,
> + IMX6_BMODE_I2C2,
> + IMX6_BMODE_I2C3,
> +};
> +
> +enum imx6_bmode_emi {
> + IMX6_BMODE_ONENAND,
> + IMX6_BMODE_NOR,
> +};
> +
> +enum imx6_bmode {
> + IMX6_BMODE_EMI,

Especially when doing things like this:

> + IMX6_BMODE_SATA = 0x2,
> + IMX6_BMODE_SERIAL,
> + IMX6_BMODE_SD,
> + IMX6_BMODE_ESD,
> + IMX6_BMODE_MMC,
> + IMX6_BMODE_EMMC,
> + IMX6_BMODE_NAND,
> +};
> +
>  static inline u8 imx6_is_bmode_from_gpr9(void)
>  {
>   struct src *psrc = (struct src *)SRC_BASE_ADDR;
> 

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


Re: [U-Boot] [PATCH] cmd: sata: fix init command return value

2017-01-11 Thread Eric Nelson
On 01/11/2017 08:51 AM, Gary Bisson wrote:
> Since commit aa6ab905b2, sata_initialize returns -1 if init_sata or
> scan_sata fails. But this return value becomes the do_sata return
> value which is equivalent to CMD_RET_USAGE.
> 
> In case one issues 'sata init' and that the hardware fails to
> initialize, there's no need to display the command usage. Instead
> the command shoud just return the CMD_RET_FAILURE value.

s/shoud/should/

> 
> Fixes: aa6ab905b2 (sata: fix sata command can not being executed bug)
> 
> Signed-off-by: Gary Bisson <gary.bis...@boundarydevices.com>
> ---
>  cmd/sata.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/cmd/sata.c b/cmd/sata.c
> index f56622acc2..4c53022ff6 100644
> --- a/cmd/sata.c
> +++ b/cmd/sata.c
> @@ -28,14 +28,15 @@ static int do_sata(cmd_tbl_t *cmdtp, int flag, int argc, 
> char * const argv[])
>   if (sata_curr_device != -1)
>   sata_stop();
>  
> - return sata_initialize();
> + return (sata_initialize() < 0) ?
> + CMD_RET_FAILURE : CMD_RET_SUCCESS;
>   }
>  
>   /* If the user has not yet run `sata init`, do it now */
>   if (sata_curr_device == -1) {
>   rc = sata_initialize();
>   if (rc == -1)
> - return rc;
> + return CMD_RET_FAILURE;
>   sata_curr_device = rc;
>   }
>  
> 
Otherwise,

Reviewed-by: Eric Nelson <e...@nelint.com>

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


Re: [U-Boot] [PATCH RESEND] imx-common: hab: fix return value from hab_auth_img

2016-11-28 Thread Eric Nelson
Hi all,

On 11/27/2016 08:27 AM, Eric Nelson wrote:
> The authenticate_image routine returns a boolean to indicate
> a valid (1) or invalid (0) image.
> 

An off-list discussion highlighted that the expected return value
from the authenticate_image() routine isn't obvious since there
isn't any user in main-line except the "hab_auth_img" command.

My understanding was gleaned from this use in the NXP tree:

http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/drivers/usb/gadget/f_fastboot.c?id=m6.0.1_2.1.0-ga#n1727

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


[U-Boot] [PATCH RESEND] imx-common: hab: fix return value from hab_auth_img

2016-11-27 Thread Eric Nelson
The authenticate_image routine returns a boolean to indicate
a valid (1) or invalid (0) image.

The hab_auth_img should return CMD_RET_SUCCESS to indicate
success (a valid image), but currently doesn't.

Before this patch, a valid image at addres 0x1200
with an IVT offset of 0x7a8000 will produce the following:

=> if hab_auth_img 0x1200 0x7a8000 ; then
> echo worked
>   else
> echo failed
>   fi
Authenticate image from DDR location 0x1200...
Secure boot enabled
HAB Configuration: 0xcc, HAB State: 0x99
failed

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 arch/arm/imx-common/hab.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/imx-common/hab.c b/arch/arm/imx-common/hab.c
index 6731825..e2c04f9 100644
--- a/arch/arm/imx-common/hab.c
+++ b/arch/arm/imx-common/hab.c
@@ -486,7 +486,9 @@ static int do_authenticate_image(cmd_tbl_t *cmdtp, int 
flag, int argc,
 
rcode = authenticate_image(addr, ivt_offset);
 
-   return rcode;
+   return (rcode != 0)
+   ? CMD_RET_SUCCESS
+   : CMD_RET_FAILURE;
 }
 
 U_BOOT_CMD(
-- 
2.7.4

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


Re: [U-Boot] [PATCH] tools: imximage: display DCD block offset, length

2016-11-17 Thread Eric Nelson
Hi Gary,

On 11/17/2016 05:16 AM, Gary Bisson wrote:
> Hi Eric, All,
> 
> On Wed, Nov 16, 2016 at 05:13:41PM -0700, Eric Nelson wrote:
>> These values can be used to sign a U-Boot image for use when
>> loading an image through the Serial Download Protocol (SDP).
>>
>> Note that the address of 0x91 is usable with the stock
>> configuration of imx_usb_loader on i.MX6 and i.MX7 SOCs:
>>
>> https://github.com/boundarydevices/imx_usb_loader/blob/master/mx6_usb_work.conf#L3
>>
>> Refer to the section on imx_usb_loader in this post for more
>> details:
>>
>> https://boundarydevices.com/high-assurance-boot-hab-dummies/
>>
>> Signed-off-by: Eric Nelson <e...@nelint.com>
> 
> Thanks, indeed such patch would ease the life of anybody that needs to
> deal with HAB when creating the CSF files.
> 
>> ---
>>  tools/imximage.c | 10 +-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/imximage.c b/tools/imximage.c
>> index c9e42ec..2cd8d88 100644
>> --- a/tools/imximage.c
>> +++ b/tools/imximage.c
>> @@ -281,7 +281,6 @@ static void set_dcd_rst_v2(struct imx_header *imxhdr, 
>> uint32_t dcd_len,
>>  d = (struct dcd_v2_cmd *)(((char *)d) + len);
>>  
>>  len = (char *)d - (char *)_v2->header;
>> -
> 
> Is this part of the patch intended?
> 

Nope.

>>  dcd_v2->header.tag = DCD_HEADER_TAG;
>>  dcd_v2->header.length = cpu_to_be16(len);
>>  dcd_v2->header.version = DCD_VERSION;
>> @@ -501,10 +500,19 @@ static void print_hdr_v2(struct imx_header *imx_hdr)
>>  printf("Entry Point:  %08x\n", (uint32_t)fhdr_v2->entry);
>>  if (fhdr_v2->csf && (imximage_ivt_offset != UNDEFINED) &&
>>  (imximage_csf_size != UNDEFINED)) {
>> +uint16_t dcdlen;
>> +int offs;
>> +
>> +dcdlen = hdr_v2->data.dcd_table.header.length;
>> +offs = (char *)_v2->data.dcd_table
>> +- (char *)hdr_v2;
>> +
>>  printf("HAB Blocks:   %08x %08x %08x\n",
>> (uint32_t)fhdr_v2->self, 0,
> 
> This isn't part of the patch, but why is self cast into a uint32_t
> although it's already a uint32_t?
> 

Unrelated, but good catch!

>> hdr_v2->boot_data.size - imximage_ivt_offset -
>> imximage_csf_size);
>> +printf("DCD Blocks:   0091 %08x %08x\n",
>> +   offs, be16_to_cpu(dcdlen));
>>  }
> 
> Not sure if "DCD Blocks" is the best naming, cause it really just
> applies to SDP protocol.
> 
> This got me thinking and I think the printf above should also show the
> Blocks for encryption which is also missing right now.
> 
> What about something like the snippet below?
> 
>   if (fhdr_v2->csf && (imximage_ivt_offset != UNDEFINED) &&
>   (imximage_csf_size != UNDEFINED)) {
>   uint16_t dcdlen;
>   uint32_t dcdoff;
>   uint32_t entryoff;
> 
>   dcdlen = hdr_v2->data.dcd_table.header.length;
>   dcdoff = (char *)_v2->data.dcd_table
>   - (char *)hdr_v2;
>   entryoff = fhdr_v2->entry - fhdr_v2->self;
> 
>   printf("[HAB][Signature]\n");
>   printf("Blocks:   %08x %08x %08x\n",
>  (uint32_t)fhdr_v2->self, 0,

I think somebody just pointed out that self is already a uint32_t,
so why the cast?

>  hdr_v2->boot_data.size - imximage_ivt_offset -
>  imximage_csf_size);
>   printf("[HAB][Encryption]\n");
>   printf("Blocks:   %08x %08x %08x\n",
>  fhdr_v2->self, 0, dcdoff + be16_to_cpu(dcdlen));
>   printf("Blocks:   %08x %08x %08x\n",
>  fhdr_v2->entry, entryoff,
>  hdr_v2->boot_data.size - imximage_ivt_offset -
>  imximage_csf_size - entryoff);
>   printf("[HAB][SDP]\n");
>   printf("Blocks:   0091 %08x %08x\n",
>  dcdoff, be16_to_cpu(dcdlen));
>   }

I like the more specific tags, but wonder if some minor edits wouldn't
make this more useful.

In particular, adding 0x before %08x would allow easier cut and paste
into signing scripts in a manual process.

I looked briefly at the output of 'mkimage -l' and found that it doesn't
reach this code block because imximage_ivt/csf_size variables are
set during the parsing of a .cfg file (they're UNDEFINED with
'mkimage -l').


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


[U-Boot] [PATCH] tools: imximage: display DCD block offset, length

2016-11-16 Thread Eric Nelson
These values can be used to sign a U-Boot image for use when
loading an image through the Serial Download Protocol (SDP).

Note that the address of 0x91 is usable with the stock
configuration of imx_usb_loader on i.MX6 and i.MX7 SOCs:

https://github.com/boundarydevices/imx_usb_loader/blob/master/mx6_usb_work.conf#L3

Refer to the section on imx_usb_loader in this post for more
details:

https://boundarydevices.com/high-assurance-boot-hab-dummies/

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 tools/imximage.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/tools/imximage.c b/tools/imximage.c
index c9e42ec..2cd8d88 100644
--- a/tools/imximage.c
+++ b/tools/imximage.c
@@ -281,7 +281,6 @@ static void set_dcd_rst_v2(struct imx_header *imxhdr, 
uint32_t dcd_len,
d = (struct dcd_v2_cmd *)(((char *)d) + len);
 
len = (char *)d - (char *)_v2->header;
-
dcd_v2->header.tag = DCD_HEADER_TAG;
dcd_v2->header.length = cpu_to_be16(len);
dcd_v2->header.version = DCD_VERSION;
@@ -501,10 +500,19 @@ static void print_hdr_v2(struct imx_header *imx_hdr)
printf("Entry Point:  %08x\n", (uint32_t)fhdr_v2->entry);
if (fhdr_v2->csf && (imximage_ivt_offset != UNDEFINED) &&
(imximage_csf_size != UNDEFINED)) {
+   uint16_t dcdlen;
+   int offs;
+
+   dcdlen = hdr_v2->data.dcd_table.header.length;
+   offs = (char *)_v2->data.dcd_table
+   - (char *)hdr_v2;
+
printf("HAB Blocks:   %08x %08x %08x\n",
   (uint32_t)fhdr_v2->self, 0,
   hdr_v2->boot_data.size - imximage_ivt_offset -
   imximage_csf_size);
+   printf("DCD Blocks:   0091 %08x %08x\n",
+  offs, be16_to_cpu(dcdlen));
}
} else {
imx_header_v2_t *next_hdr_v2;
-- 
2.7.4

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


[U-Boot] [RFC PATCH 2/3] ARM: mx6: ddr: add plugin-utils placeholder

2016-11-01 Thread Eric Nelson
Add entry points for saving the state of the machine at entry
from the Boot ROM and for restoring the state before a return.

Note that this needs some fixup before it's useful, so I'm
forwarding it as an RFC to solicit advice.

This placeholder is little more than a setjmp/longjmp that
saves the SP, LR and registers 0-9. Disassembling the ROM
for i.MX6DL and i.MX6SL shows that these are the only registers
used by the ROM on those SOCs.

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 arch/arm/cpu/armv7/mx6/Makefile |  2 +-
 arch/arm/cpu/armv7/mx6/ddr.c|  4 
 arch/arm/cpu/armv7/mx6/plugin-utils.S   | 24 
 arch/arm/include/asm/arch-mx6/mx6-ddr.h | 19 +++
 4 files changed, 48 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/cpu/armv7/mx6/plugin-utils.S

diff --git a/arch/arm/cpu/armv7/mx6/Makefile b/arch/arm/cpu/armv7/mx6/Makefile
index 8af191d..d0d0103 100644
--- a/arch/arm/cpu/armv7/mx6/Makefile
+++ b/arch/arm/cpu/armv7/mx6/Makefile
@@ -8,5 +8,5 @@
 #
 
 obj-y  := soc.o clock.o
-obj-$(CONFIG_SPL_BUILD) += ddr.o
+obj-$(CONFIG_SPL_BUILD) += ddr.o plugin-utils.o
 obj-$(CONFIG_MP) += mp.o
diff --git a/arch/arm/cpu/armv7/mx6/ddr.c b/arch/arm/cpu/armv7/mx6/ddr.c
index 0cf391e..7f8e30d 100644
--- a/arch/arm/cpu/armv7/mx6/ddr.c
+++ b/arch/arm/cpu/armv7/mx6/ddr.c
@@ -1536,3 +1536,7 @@ void mx6_dram_cfg(const struct mx6_ddr_sysinfo *sysinfo,
hang();
}
 }
+
+#ifdef CONFIG_SPL_BUILD
+struct plugin_state plugin_state __attribute__((section(".data")));
+#endif
diff --git a/arch/arm/cpu/armv7/mx6/plugin-utils.S 
b/arch/arm/cpu/armv7/mx6/plugin-utils.S
new file mode 100644
index 000..c284a76
--- /dev/null
+++ b/arch/arm/cpu/armv7/mx6/plugin-utils.S
@@ -0,0 +1,24 @@
+/*
+ * Utility functions for executing as an i.MX plugin
+ *
+ * Copyright (c) 2016 Nelson Integration, LLC
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+ENTRY(save_boot_params)
+   ldr r10, =plugin_state
+   stmia   r10, {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, fp, sp, lr}
+   b   save_boot_params_ret
+ENDPROC(save_boot_params)
+
+ENTRY(return_to_rom)
+   ldr r10, =plugin_state
+   ldmia   r10, {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, fp, sp, lr}
+   bx  lr
+ENDPROC(return_to_rom)
diff --git a/arch/arm/include/asm/arch-mx6/mx6-ddr.h 
b/arch/arm/include/asm/arch-mx6/mx6-ddr.h
index 2a8d443..52420da 100644
--- a/arch/arm/include/asm/arch-mx6/mx6-ddr.h
+++ b/arch/arm/include/asm/arch-mx6/mx6-ddr.h
@@ -528,4 +528,23 @@ void mx6_dram_cfg(const struct mx6_ddr_sysinfo *,
 #define MX6_MMDC_P1_MPZQLP2CTL 0x021b485C
 #define MX6_MMDC_P1_MPMUR0 0x021b48b8
 
+#ifdef CONFIG_SPL_BUILD
+struct plugin_state {
+   uint32_t r0;
+   uint32_t r1;
+   uint32_t r2;
+   uint32_t r3;
+   uint32_t r4;
+   uint32_t r5;
+   uint32_t r6;
+   uint32_t r7;
+   uint32_t r8;
+   uint32_t r9;
+   uint32_t fp;
+   uint32_t sp;
+   uint32_t lr;
+};
+void return_to_rom(void);
+#endif
+
 #endif /*__ASM_ARCH_MX6_DDR_H__ */
-- 
2.7.4

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


[U-Boot] [RFC PATCH 3/3] ARM: imx: mx6memcal: allow build of combined SPL+U-Boot

2016-11-01 Thread Eric Nelson
Add an imximage config file to construct u-boot.imx with SPL
as a plugin and use it as a straw-man for the mx6memcal
virtual board.

Note that this breaks the build of SPL because only one value
can be listed for IMX_CONFIG.

As it stands, all imx SPL builds use an almost empty .cfg file
from arch/arm/configs/spl_sd.cfg.

This could be hard-coded for use in building SPL if we just
remove the comments from the file (copyright).

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 arch/arm/imx-common/spl-plus-u-boot.cfg | 4 
 configs/mx6memcal_defconfig | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/imx-common/spl-plus-u-boot.cfg

diff --git a/arch/arm/imx-common/spl-plus-u-boot.cfg 
b/arch/arm/imx-common/spl-plus-u-boot.cfg
new file mode 100644
index 000..5940cb0
--- /dev/null
+++ b/arch/arm/imx-common/spl-plus-u-boot.cfg
@@ -0,0 +1,4 @@
+IMAGE_VERSION 2
+BOOT_FROM sd
+PLUGIN spl/u-boot-spl.bin 0x00907000
+
diff --git a/configs/mx6memcal_defconfig b/configs/mx6memcal_defconfig
index 7e07182..06aa85f 100644
--- a/configs/mx6memcal_defconfig
+++ b/configs/mx6memcal_defconfig
@@ -6,7 +6,7 @@ CONFIG_MX6_DDRCAL=y
 CONFIG_TARGET_MX6MEMCAL=y
 CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_SPL_WATCHDOG_SUPPORT=y
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg,SPL,MX6QDL"
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/imx-common/spl-plus-u-boot.cfg,SPL,MX6QDL"
 CONFIG_SPL=y
 CONFIG_HUSH_PARSER=y
 # CONFIG_CMD_BOOTD is not set
-- 
2.7.4

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


[U-Boot] [RFC PATCH 0/3] ARM: imx: mx6: Add plugin support for SPL

2016-11-01 Thread Eric Nelson
I forgot to mention in the cover letter for the previous patch set 
that because the mx6memcal board has no implementation of storage
(it only supports a serial console and DDR), I haven't tested the
resulting U-Boot, which has very little besides "mtest" included.

I'm hoping to use this code base (mx6memcal) as a straw man for 
loading both SPL (as a plugin) and U-Boot through the serial download 
path as we've previously discussed in at least [1], [2] and [3].

Now that Peng's patch to imximage has been applied, we can start
to look at the implementation details, and I hope this patch set
can help move us toward an implementation.

The gist of what's needed to allow SPL to be loaded as a plugin
and avoid the need for removable storage or a full (non-SPL)
U-Boot is shown in patch 2.

That is, we need something akin to setjmp/longjmp to:
1. to save the early state of the machine before SPL configures
   the DDR controller, and
2. a routine that we can call to return to the boot ROM

To address #1, there's a clear precedent in the support for a
save_boot_params() routine and patch 2 adds one that simply
saves the working register set. Examining the registers used
by the ROM code shows that r0-r9 plus sp and lr are sufficient.

Experimentally, I've found that the boot ROM stack is initialized
to 0x91ffb4 and that the stack pointer is at 0x91febc (248 bytes)
on all of the machines I've tested against (MX6Q, MX6DL, MX6S and
MX6SL), so we can save the stack just by moving the SPL stack
(patch #1).

We'll also need to determine where the decision to return to the
boot ROM occurs (i.e. when we call routine #2).

The obvious place for use during development is right after
DDR initialization if loaded through the serial downloader,
but it might also be useful to invoke the serial loader as
a last resort instead of the current call to hang().

Patch 3 adds a config file which will allow a build of 
u-boot.imx with SPL as a plugin followed by u-boot.bin as
the primary payload. It highlights the issue of only having
a single IMX_CONFIG variable so it breaks the build of a
stand-alone SPL. Rather, it doesn't break the build, but 
produces SPL that is effectively the same as u-boot.imx.

This leaves only the question of what the return_to_rom code 
should look like, and I'm a bit stumped. The ROM API isn't
documented in any document I have.

In Troy's original patch ([4]), he calls a routine that he
names HAB_RVT_LOAD_DATA. On i.MX Community ([5]), I found
a reference to a plugin_download() routine and I'm not
sure where that came from. The Community post suggests
that it's used in EBOOT.

I tried a simplistic copy of the tail end of plugin start
from [6] that calls pu_irom_hwcnfg_setup() and then returns
to ROM without success. I'm not certain that this was the
right approach and am hoping for some guidance.

References:
[1] - http://lists.denx.de/pipermail/u-boot/2015-June/thread.html#215606
[2] - http://lists.denx.de/pipermail/u-boot/2016-September/thread.html#266303
[3] - http://lists.denx.de/pipermail/u-boot/2015-May/thread.html#215573
[4] - http://patchwork.ozlabs.org/patch/186054/
[5] - http://community.nxp.com/thread/303794
[6] - 
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-mx6/mx6_plugin.S

Eric Nelson (3):
  ARM: mx6: preserve Boot ROM stack in SPL
  ARM: mx6: ddr: add plugin-utils placeholder
  ARM: imx: mx6memcal: allow build of combined SPL+U-Boot

 arch/arm/cpu/armv7/mx6/Makefile |  2 +-
 arch/arm/cpu/armv7/mx6/ddr.c|  4 
 arch/arm/cpu/armv7/mx6/plugin-utils.S   | 24 
 arch/arm/imx-common/spl-plus-u-boot.cfg |  4 
 arch/arm/include/asm/arch-mx6/mx6-ddr.h | 19 +++
 configs/mx6memcal_defconfig |  2 +-
 include/configs/imx6_spl.h  |  2 +-
 7 files changed, 54 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/mx6/plugin-utils.S
 create mode 100644 arch/arm/imx-common/spl-plus-u-boot.cfg

-- 
2.7.4

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


[U-Boot] [RFC PATCH 1/3] ARM: mx6: preserve Boot ROM stack in SPL

2016-11-01 Thread Eric Nelson
The i.MX6 Boot ROM starts its' stack at 0x091ffb4 and appears
to be a little less than 256 bytes deep when starting U-Boot.

This was determined experimentally on i.MX6DL and i.MX6SL.

Allow this stack to be preserved to simplify returning to
ROM when SPL is loaded as a plugin.

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 include/configs/imx6_spl.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/imx6_spl.h b/include/configs/imx6_spl.h
index 76d1ca0..fb1b237 100644
--- a/include/configs/imx6_spl.h
+++ b/include/configs/imx6_spl.h
@@ -28,7 +28,7 @@
 #define CONFIG_SPL_LDSCRIPT"arch/arm/cpu/armv7/omap-common/u-boot-spl.lds"
 #define CONFIG_SPL_TEXT_BASE   0x00908000
 #define CONFIG_SPL_MAX_SIZE0x1
-#define CONFIG_SPL_STACK   0x0091FFB8
+#define CONFIG_SPL_STACK   0x0091FEB8
 
 /* NAND support */
 #if defined(CONFIG_SPL_NAND_SUPPORT)
-- 
2.7.4

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


[U-Boot] [RFC PATCH 6/9] mx6memcal: add configuration for Wandboard Solo (512MiB of x32 DDR3)

2016-11-01 Thread Eric Nelson
Signed-off-by: Eric Nelson <e...@nelint.com>
---
 configs/mx6memcal_wandboard_solo_defconfig | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 configs/mx6memcal_wandboard_solo_defconfig

diff --git a/configs/mx6memcal_wandboard_solo_defconfig 
b/configs/mx6memcal_wandboard_solo_defconfig
new file mode 100644
index 000..f47ce43
--- /dev/null
+++ b/configs/mx6memcal_wandboard_solo_defconfig
@@ -0,0 +1,35 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MX6=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_MX6_DDRCAL=y
+CONFIG_TARGET_MX6MEMCAL=y
+CONFIG_DDRWIDTH=32
+CONFIG_DDRCS=1
+CONFIG_H5TQ2G63DFR=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_WATCHDOG_SUPPORT=y
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg,SPL,MX6QDL"
+CONFIG_SPL=y
+CONFIG_HUSH_PARSER=y
+# CONFIG_CMD_BOOTD is not set
+# CONFIG_CMD_BOOTM is not set
+# CONFIG_CMD_ELF is not set
+# CONFIG_CMD_IMI is not set
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_XIMG is not set
+# CONFIG_CMD_EXPORTENV is not set
+# CONFIG_CMD_IMPORTENV is not set
+# CONFIG_CMD_EDITENV is not set
+# CONFIG_CMD_SAVEENV is not set
+# CONFIG_CMD_ENV_EXISTS is not set
+CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_MEMINFO=y
+# CONFIG_CMD_LOADB is not set
+# CONFIG_CMD_LOADS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+# CONFIG_CMD_NET is not set
+# CONFIG_CMD_NFS is not set
+CONFIG_CMD_CACHE=y
+CONFIG_REGEX=y
-- 
2.7.4

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


[U-Boot] [RFC PATCH 7/9] mx6memcal: add configuration for Wandboard Quad

2016-11-01 Thread Eric Nelson
Note that for some reason, this is failing for me unless I
select a DDR bus width of 32 bits.

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 configs/mx6memcal_wandboard_quad_defconfig | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 configs/mx6memcal_wandboard_quad_defconfig

diff --git a/configs/mx6memcal_wandboard_quad_defconfig 
b/configs/mx6memcal_wandboard_quad_defconfig
new file mode 100644
index 000..291c273
--- /dev/null
+++ b/configs/mx6memcal_wandboard_quad_defconfig
@@ -0,0 +1,34 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MX6=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_MX6_DDRCAL=y
+CONFIG_TARGET_MX6MEMCAL=y
+CONFIG_DDRCS=1
+CONFIG_H5TQ4G63AFR=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_WATCHDOG_SUPPORT=y
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg,SPL,MX6QDL"
+CONFIG_SPL=y
+CONFIG_HUSH_PARSER=y
+# CONFIG_CMD_BOOTD is not set
+# CONFIG_CMD_BOOTM is not set
+# CONFIG_CMD_ELF is not set
+# CONFIG_CMD_IMI is not set
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_XIMG is not set
+# CONFIG_CMD_EXPORTENV is not set
+# CONFIG_CMD_IMPORTENV is not set
+# CONFIG_CMD_EDITENV is not set
+# CONFIG_CMD_SAVEENV is not set
+# CONFIG_CMD_ENV_EXISTS is not set
+CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_MEMINFO=y
+# CONFIG_CMD_LOADB is not set
+# CONFIG_CMD_LOADS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+# CONFIG_CMD_NET is not set
+# CONFIG_CMD_NFS is not set
+CONFIG_CMD_CACHE=y
+CONFIG_REGEX=y
-- 
2.7.4

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


[U-Boot] [RFC PATCH 9/9] mx6memcal: add configuration for warp board (i.MX6SL)

2016-11-01 Thread Eric Nelson
Signed-off-by: Eric Nelson <e...@nelint.com>
---
 configs/mx6memcal_warpboard_defconfig | 39 +++
 1 file changed, 39 insertions(+)
 create mode 100644 configs/mx6memcal_warpboard_defconfig

diff --git a/configs/mx6memcal_warpboard_defconfig 
b/configs/mx6memcal_warpboard_defconfig
new file mode 100644
index 000..1786e57
--- /dev/null
+++ b/configs/mx6memcal_warpboard_defconfig
@@ -0,0 +1,39 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MX6=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_MX6_DDRCAL=y
+CONFIG_TARGET_MX6MEMCAL=y
+CONFIG_DDRWIDTH=32
+CONFIG_DDRCS=1
+CONFIG_LPDDR2=y
+CONFIG_MT29PZZZ4D4BKESK=y
+CONFIG_DRAM_DRIVE_STRENGTH=4
+CONFIG_RALAT=2
+CONFIG_UART1_UART1=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_WATCHDOG_SUPPORT=y
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg,SPL,MX6SL"
+CONFIG_SPL=y
+CONFIG_HUSH_PARSER=y
+# CONFIG_CMD_BOOTD is not set
+# CONFIG_CMD_BOOTM is not set
+# CONFIG_CMD_ELF is not set
+# CONFIG_CMD_IMI is not set
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_XIMG is not set
+# CONFIG_CMD_EXPORTENV is not set
+# CONFIG_CMD_IMPORTENV is not set
+# CONFIG_CMD_EDITENV is not set
+# CONFIG_CMD_SAVEENV is not set
+# CONFIG_CMD_ENV_EXISTS is not set
+CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_MEMINFO=y
+# CONFIG_CMD_LOADB is not set
+# CONFIG_CMD_LOADS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+# CONFIG_CMD_NET is not set
+# CONFIG_CMD_NFS is not set
+CONFIG_CMD_CACHE=y
+CONFIG_REGEX=y
-- 
2.7.4

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


[U-Boot] [RFC PATCH 4/9] mx6memcal: add configuration for Nitrogen6_max board

2016-11-01 Thread Eric Nelson
Signed-off-by: Eric Nelson <e...@nelint.com>
---
 configs/mx6memcal_nitrogen6_max_defconfig | 33 +++
 1 file changed, 33 insertions(+)
 create mode 100644 configs/mx6memcal_nitrogen6_max_defconfig

diff --git a/configs/mx6memcal_nitrogen6_max_defconfig 
b/configs/mx6memcal_nitrogen6_max_defconfig
new file mode 100644
index 000..097d27d
--- /dev/null
+++ b/configs/mx6memcal_nitrogen6_max_defconfig
@@ -0,0 +1,33 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MX6=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_MX6_DDRCAL=y
+CONFIG_TARGET_MX6MEMCAL=y
+CONFIG_SERIAL_CONSOLE_UART2=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_WATCHDOG_SUPPORT=y
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg,SPL,MX6QDL"
+CONFIG_SPL=y
+CONFIG_HUSH_PARSER=y
+# CONFIG_CMD_BOOTD is not set
+# CONFIG_CMD_BOOTM is not set
+# CONFIG_CMD_ELF is not set
+# CONFIG_CMD_IMI is not set
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_XIMG is not set
+# CONFIG_CMD_EXPORTENV is not set
+# CONFIG_CMD_IMPORTENV is not set
+# CONFIG_CMD_EDITENV is not set
+# CONFIG_CMD_SAVEENV is not set
+# CONFIG_CMD_ENV_EXISTS is not set
+CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_MEMINFO=y
+# CONFIG_CMD_LOADB is not set
+# CONFIG_CMD_LOADS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+# CONFIG_CMD_NET is not set
+# CONFIG_CMD_NFS is not set
+CONFIG_CMD_CACHE=y
+CONFIG_REGEX=y
-- 
2.7.4

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


[U-Boot] [RFC PATCH 8/9] mx6memcal: add configuration for mx6slevk

2016-11-01 Thread Eric Nelson
Signed-off-by: Eric Nelson <e...@nelint.com>
---
 configs/mx6memcal_mx6slevk_defconfig | 37 
 1 file changed, 37 insertions(+)
 create mode 100644 configs/mx6memcal_mx6slevk_defconfig

diff --git a/configs/mx6memcal_mx6slevk_defconfig 
b/configs/mx6memcal_mx6slevk_defconfig
new file mode 100644
index 000..aaa81bc
--- /dev/null
+++ b/configs/mx6memcal_mx6slevk_defconfig
@@ -0,0 +1,37 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MX6=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_MX6_DDRCAL=y
+CONFIG_TARGET_MX6MEMCAL=y
+CONFIG_DDRWIDTH=32
+CONFIG_DDRCS=1
+CONFIG_LPDDR2=y
+CONFIG_RALAT=2
+CONFIG_UART1_UART1=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_WATCHDOG_SUPPORT=y
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg,SPL,MX6SL"
+CONFIG_SPL=y
+CONFIG_HUSH_PARSER=y
+# CONFIG_CMD_BOOTD is not set
+# CONFIG_CMD_BOOTM is not set
+# CONFIG_CMD_ELF is not set
+# CONFIG_CMD_IMI is not set
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_XIMG is not set
+# CONFIG_CMD_EXPORTENV is not set
+# CONFIG_CMD_IMPORTENV is not set
+# CONFIG_CMD_EDITENV is not set
+# CONFIG_CMD_SAVEENV is not set
+# CONFIG_CMD_ENV_EXISTS is not set
+CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_MEMINFO=y
+# CONFIG_CMD_LOADB is not set
+# CONFIG_CMD_LOADS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+# CONFIG_CMD_NET is not set
+# CONFIG_CMD_NFS is not set
+CONFIG_CMD_CACHE=y
+CONFIG_REGEX=y
-- 
2.7.4

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


[U-Boot] [RFC PATCH 3/9] mx6memcal: add configuration for SABRE Lite

2016-11-01 Thread Eric Nelson
Signed-off-by: Eric Nelson <e...@nelint.com>
---
 configs/mx6memcal_sabrelite_defconfig | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 configs/mx6memcal_sabrelite_defconfig

diff --git a/configs/mx6memcal_sabrelite_defconfig 
b/configs/mx6memcal_sabrelite_defconfig
new file mode 100644
index 000..f0c7148
--- /dev/null
+++ b/configs/mx6memcal_sabrelite_defconfig
@@ -0,0 +1,34 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MX6=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_MX6_DDRCAL=y
+CONFIG_TARGET_MX6MEMCAL=y
+CONFIG_MT41K128M16JT=y
+CONFIG_SERIAL_CONSOLE_UART2=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_WATCHDOG_SUPPORT=y
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg,SPL,MX6QDL"
+CONFIG_SPL=y
+CONFIG_HUSH_PARSER=y
+# CONFIG_CMD_BOOTD is not set
+# CONFIG_CMD_BOOTM is not set
+# CONFIG_CMD_ELF is not set
+# CONFIG_CMD_IMI is not set
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_XIMG is not set
+# CONFIG_CMD_EXPORTENV is not set
+# CONFIG_CMD_IMPORTENV is not set
+# CONFIG_CMD_EDITENV is not set
+# CONFIG_CMD_SAVEENV is not set
+# CONFIG_CMD_ENV_EXISTS is not set
+CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_MEMINFO=y
+# CONFIG_CMD_LOADB is not set
+# CONFIG_CMD_LOADS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+# CONFIG_CMD_NET is not set
+# CONFIG_CMD_NFS is not set
+CONFIG_CMD_CACHE=y
+CONFIG_REGEX=y
-- 
2.7.4

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


[U-Boot] [RFC PATCH 5/9] mx6memcal: add configuration for tr1x board (i.MX6SL with DDR3)

2016-11-01 Thread Eric Nelson
Signed-off-by: Eric Nelson <e...@nelint.com>
---
 configs/mx6memcal_tr1x_defconfig | 36 
 1 file changed, 36 insertions(+)
 create mode 100644 configs/mx6memcal_tr1x_defconfig

diff --git a/configs/mx6memcal_tr1x_defconfig b/configs/mx6memcal_tr1x_defconfig
new file mode 100644
index 000..c79fd72
--- /dev/null
+++ b/configs/mx6memcal_tr1x_defconfig
@@ -0,0 +1,36 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MX6=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_MX6_DDRCAL=y
+CONFIG_TARGET_MX6MEMCAL=y
+CONFIG_DDRWIDTH=32
+CONFIG_DDRCS=1
+CONFIG_MT41K128M16JT=y
+CONFIG_UART1_UART1=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_WATCHDOG_SUPPORT=y
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg,SPL,MX6SL"
+CONFIG_SPL=y
+CONFIG_HUSH_PARSER=y
+# CONFIG_CMD_BOOTD is not set
+# CONFIG_CMD_BOOTM is not set
+# CONFIG_CMD_ELF is not set
+# CONFIG_CMD_IMI is not set
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_XIMG is not set
+# CONFIG_CMD_EXPORTENV is not set
+# CONFIG_CMD_IMPORTENV is not set
+# CONFIG_CMD_EDITENV is not set
+# CONFIG_CMD_SAVEENV is not set
+# CONFIG_CMD_ENV_EXISTS is not set
+CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_MEMINFO=y
+# CONFIG_CMD_LOADB is not set
+# CONFIG_CMD_LOADS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+# CONFIG_CMD_NET is not set
+# CONFIG_CMD_NFS is not set
+CONFIG_CMD_CACHE=y
+CONFIG_REGEX=y
-- 
2.7.4

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


[U-Boot] [RFC PATCH 1/9] mx6: Add board mx6memcal for use in validating DDR

2016-11-01 Thread Eric Nelson
This is a virtual "board" that uses configuration files and
Kconfig to define the memory layout used by a real board during
the board bring-up process.

It generates an SPL image that can be loaded using imx_usb or
SB_LOADER.exe.

When run, it will generate a set of calibration constants for
use in either or both a DCD configuration file for boards that
use u-boot.imx or struct mx6_mmdc_calibration for boards that
boot via SPL.

In essence, it is a configurable, open-source variant of the
Freescale ddr-stress tool.

https://community.nxp.com/docs/DOC-105652

File mx6memcal_defconfig configures the board for use with
mx6sabresd or mx6qsabreauto.

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 arch/arm/cpu/armv7/mx6/Kconfig|   9 +
 board/freescale/mx6memcal/Kconfig | 235 +
 board/freescale/mx6memcal/MAINTAINERS |   7 +
 board/freescale/mx6memcal/Makefile|  13 +
 board/freescale/mx6memcal/README  |  49 
 board/freescale/mx6memcal/mx6memcal.c |  32 +++
 board/freescale/mx6memcal/spl.c   | 458 ++
 configs/mx6memcal_defconfig   |  32 +++
 include/configs/mx6memcal.h   |  62 +
 scripts/config_whitelist.txt  |   5 +
 10 files changed, 902 insertions(+)
 create mode 100644 board/freescale/mx6memcal/Kconfig
 create mode 100644 board/freescale/mx6memcal/MAINTAINERS
 create mode 100644 board/freescale/mx6memcal/Makefile
 create mode 100644 board/freescale/mx6memcal/README
 create mode 100644 board/freescale/mx6memcal/mx6memcal.c
 create mode 100644 board/freescale/mx6memcal/spl.c
 create mode 100644 configs/mx6memcal_defconfig
 create mode 100644 include/configs/mx6memcal.h

diff --git a/arch/arm/cpu/armv7/mx6/Kconfig b/arch/arm/cpu/armv7/mx6/Kconfig
index 8b2217e..ac4b0fd 100644
--- a/arch/arm/cpu/armv7/mx6/Kconfig
+++ b/arch/arm/cpu/armv7/mx6/Kconfig
@@ -100,6 +100,14 @@ config TARGET_MX6CUBOXI
bool "Solid-run mx6 boards"
select SUPPORT_SPL
 
+config TARGET_MX6MEMCAL
+   bool "mx6memcal"
+   select SUPPORT_SPL
+   help
+ The mx6memcal board is a virtual board that can be used to validate
+ and characterize the memory layout of a new design during the initial
+ development and pre-production stages.
+
 config TARGET_MX6QARM2
bool "mx6qarm2"
 
@@ -245,6 +253,7 @@ source "board/el/el6x/Kconfig"
 source "board/embest/mx6boards/Kconfig"
 source "board/engicam/icorem6/Kconfig"
 source "board/freescale/mx6qarm2/Kconfig"
+source "board/freescale/mx6memcal/Kconfig"
 source "board/freescale/mx6qsabreauto/Kconfig"
 source "board/freescale/mx6sabresd/Kconfig"
 source "board/freescale/mx6slevk/Kconfig"
diff --git a/board/freescale/mx6memcal/Kconfig 
b/board/freescale/mx6memcal/Kconfig
new file mode 100644
index 000..443804d
--- /dev/null
+++ b/board/freescale/mx6memcal/Kconfig
@@ -0,0 +1,235 @@
+if TARGET_MX6MEMCAL
+
+config SYS_BOARD
+   default "mx6memcal"
+
+config SYS_VENDOR
+   default "freescale"
+
+config SYS_CONFIG_NAME
+   default "mx6memcal"
+
+menu "mx6memcal specifics"
+choice
+   prompt "Serial console"
+   help
+ Either UART1 or UART2 will be used as the console for
+ displaying the calibration values or errors.
+
+config SERIAL_CONSOLE_UART1
+   bool "UART1"
+   help
+ Select this if your board uses UART1 for its' console.
+
+config SERIAL_CONSOLE_UART2
+   bool "UART2"
+   help
+ Select this if your board uses UART2 for its' console.
+
+endchoice
+
+choice
+   prompt "UART pads"
+   help
+ Select the RX and TX pads used for your serial console.
+ The choices below reflect the most commonly used options
+ for your UART.
+
+   config UART2_EIM_D26_27
+   bool "UART2 on EIM_D26/27 (SabreLite, Nitrogen6x)"
+   depends on SERIAL_CONSOLE_UART2
+   help
+ Choose this configuration if you're using pads
+ EIM_D26 and D27 for a console on UART2.
+ This is typical for designs that are based on the
+ NXP SABRELite.
+
+   config UART1_CSI0_DAT10_11
+   bool "UART1 on CSI0_DAT10/11 (Wand)"
+   depends on SERIAL_CONSOLE_UART1
+   help
+ Choose this configuration if you're using pads
+ CSI0_DAT10 and DAT11 for a console on UART1 as
+ is done on the i.MX6 Wand board.
+
+   config UART1_SD3_DAT6_7
+   bool "UART1 on SD3_DAT6/7 (SabreSD, SabreAuto)"
+   depends on SERIAL_CONSOLE_UART1
+   help
+ Choose this configuration if you're using pads
+ SD3_DAT6 

[U-Boot] [RFC PATCH 2/9] mx6memcal: zero values for MPWRDLCTL cause read DQS calibration errors

2016-11-01 Thread Eric Nelson
Signed-off-by: Eric Nelson <e...@nelint.com>
---
 board/freescale/mx6memcal/spl.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/board/freescale/mx6memcal/spl.c b/board/freescale/mx6memcal/spl.c
index 90e240f..4e63e34 100644
--- a/board/freescale/mx6memcal/spl.c
+++ b/board/freescale/mx6memcal/spl.c
@@ -400,6 +400,10 @@ void board_init_f(ulong dummy)
 
memset((void *)gd, 0, sizeof(struct global_data));
 
+   /* write leveling calibration defaults */
+   calibration.p0_mpwrdlctl = 0x40404040;
+   calibration.p1_mpwrdlctl = 0x40404040;
+
/* setup AIPS and disable watchdog */
arch_cpu_init();
 
-- 
2.7.4

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


[U-Boot] [RFC PATCH 0/9] ARM: imx: mx6: Add virtual mx6memcal board

2016-11-01 Thread Eric Nelson
This patch series adds a DDR calibration tool in the form of a
virtual i.MX6 board named "mx6memcal".

I was hoping to send this without the RFC, but found something that
needs some investigation in the process of cleanup (see ccgr_init in
patch 1) and would like to get it out so that others can experiment
and so I can get some additional feedback.

The board is added in patch 1.

The second patch is kept separate because I don't yet know why this
is needed. If the initial calibration is left as all zero, the 
calibration of the Nitrogen6_Max board will fail. Other boards don't
appear to have this problem.

The rest of the patches add configurations for use in testing.

Most of the boards are supported in main-line U-Boot, though I did
add the Nitrogen6_max board as a test of a 4GiB DDR arrangement.

The 'tr1x' board is a custom design that uses i.MX6SL and DDR3 that
I've been testing against and it works fine.

The mx6slevk and warp boards aren't currently supported because LPDDR2
isn't fully supported.

I did have them working in a local tree that pre-dated Marek's addition
of the calibration code into main-line:

https://github.com/ericnelsonaz/u-boot/tree/memcal-pass1

Finally, as noted in the commit message, I saw some quirkiness with
a Wandboard Quad. For some reason, the dynamic calibration failed on
this platform when I selected 64-bit bus width and I haven't taken
time to investigate.

Eric Nelson (9):
  mx6: Add board mx6memcal for use in validating DDR
  mx6memcal: zero values for MPWRDLCTL cause read DQS calibration errors
  mx6memcal: add configuration for SABRE Lite
  mx6memcal: add configuration for Nitrogen6_max board
  mx6memcal: add configuration for tr1x board (i.MX6SL with DDR3)
  mx6memcal: add configuration for Wandboard Solo (512MiB of x32 DDR3)
  mx6memcal: add configuration for Wandboard Quad
  mx6memcal: add configuration for mx6slevk
  mx6memcal: add configuration for warp board (i.MX6SL)

 arch/arm/cpu/armv7/mx6/Kconfig |   9 +
 board/freescale/mx6memcal/Kconfig  | 235 +++
 board/freescale/mx6memcal/MAINTAINERS  |   7 +
 board/freescale/mx6memcal/Makefile |  13 +
 board/freescale/mx6memcal/README   |  49 +++
 board/freescale/mx6memcal/mx6memcal.c  |  32 ++
 board/freescale/mx6memcal/spl.c| 462 +
 configs/mx6memcal_defconfig|  32 ++
 configs/mx6memcal_mx6slevk_defconfig   |  37 +++
 configs/mx6memcal_nitrogen6_max_defconfig  |  33 +++
 configs/mx6memcal_sabrelite_defconfig  |  34 +++
 configs/mx6memcal_tr1x_defconfig   |  36 +++
 configs/mx6memcal_wandboard_quad_defconfig |  34 +++
 configs/mx6memcal_wandboard_solo_defconfig |  35 +++
 configs/mx6memcal_warpboard_defconfig  |  39 +++
 include/configs/mx6memcal.h|  62 
 scripts/config_whitelist.txt   |   5 +
 17 files changed, 1154 insertions(+)
 create mode 100644 board/freescale/mx6memcal/Kconfig
 create mode 100644 board/freescale/mx6memcal/MAINTAINERS
 create mode 100644 board/freescale/mx6memcal/Makefile
 create mode 100644 board/freescale/mx6memcal/README
 create mode 100644 board/freescale/mx6memcal/mx6memcal.c
 create mode 100644 board/freescale/mx6memcal/spl.c
 create mode 100644 configs/mx6memcal_defconfig
 create mode 100644 configs/mx6memcal_mx6slevk_defconfig
 create mode 100644 configs/mx6memcal_nitrogen6_max_defconfig
 create mode 100644 configs/mx6memcal_sabrelite_defconfig
 create mode 100644 configs/mx6memcal_tr1x_defconfig
 create mode 100644 configs/mx6memcal_wandboard_quad_defconfig
 create mode 100644 configs/mx6memcal_wandboard_solo_defconfig
 create mode 100644 configs/mx6memcal_warpboard_defconfig
 create mode 100644 include/configs/mx6memcal.h

-- 
2.7.4

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


Re: [U-Boot] [PATCH v2 2/2] imx: make ipu's di configurable

2016-11-01 Thread Eric Nelson
On 11/01/2016 07:04 AM, Max Krummenacher wrote:
> The ipu has two display interfaces. Make the used one a parameter
> in struct display_info_t instead of using unconditionally DI0.
> DI0 is the default setting.
> 
> Signed-off-by: Max Krummenacher <max.krummenac...@toradex.com>
> 
> ---
> 
> Changes in v2:
> - none
> 
>  arch/arm/imx-common/video.c | 2 +-
>  arch/arm/include/asm/imx-common/video.h | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/imx-common/video.c b/arch/arm/imx-common/video.c
> index fdc987f..549bf9d 100644
> --- a/arch/arm/imx-common/video.c
> +++ b/arch/arm/imx-common/video.c
> @@ -34,7 +34,7 @@ int board_video_skip(void)
>   }
>  
>   if (i < display_count) {
> - ret = ipuv3_fb_init([i].mode, 0,
> + ret = ipuv3_fb_init([i].mode, displays[i].di ? 1 : 0,
>   displays[i].pixfmt);
>   if (!ret) {
>   if (displays[i].enable)
> diff --git a/arch/arm/include/asm/imx-common/video.h 
> b/arch/arm/include/asm/imx-common/video.h
> index cad5f86..941a031 100644
> --- a/arch/arm/include/asm/imx-common/video.h
> +++ b/arch/arm/include/asm/imx-common/video.h
> @@ -12,6 +12,7 @@ struct display_info_t {
>   int bus;
>   int addr;
>   int pixfmt;
> + int di;
>   int (*detect)(struct display_info_t const *dev);
>   void(*enable)(struct display_info_t const *dev);
>   struct  fb_videomode mode;
> 

Reviewed-by: Eric Nelson <e...@nelint.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V2 2/4] mx6: ddr: pass mx6_ddr_sysinfo to calibration routines

2016-10-30 Thread Eric Nelson
The DDR calibration routines have scattered support for bus
widths other than 64-bits:

-- The mmdc_do_write_level_calibration() routine assumes the
presence of PHY1, and
-- The mmdc_do_dqs_calibration() routine tries to determine
whether one or two DDR PHYs are active by reading MDCTL.

Since a caller of these routines must have a valid struct mx6_ddr_sysinfo
for use in calling mx6_dram_cfg(), and the bus width is available in the
"dsize" field, use this structure to inform the calibration routines which
PHYs are active.

This allows the use of the DDR calibration routines on CPU variants
like i.MX6SL that only have a single MMDC port.

Signed-off-by: Eric Nelson <e...@nelint.com>
Reviewed-by: Marek Vasut <ma...@denx.de>
---
No change in V2
 arch/arm/cpu/armv7/mx6/ddr.c| 98 +++--
 arch/arm/include/asm/arch-mx6/mx6-ddr.h |  4 +-
 board/kosagi/novena/novena_spl.c|  4 +-
 3 files changed, 60 insertions(+), 46 deletions(-)

diff --git a/arch/arm/cpu/armv7/mx6/ddr.c b/arch/arm/cpu/armv7/mx6/ddr.c
index b15f376..274a0ba 100644
--- a/arch/arm/cpu/armv7/mx6/ddr.c
+++ b/arch/arm/cpu/armv7/mx6/ddr.c
@@ -86,14 +86,15 @@ static void modify_dg_result(u32 *reg_st0, u32 *reg_st1, 
u32 *reg_ctrl)
writel(val_ctrl, reg_ctrl);
 }
 
-int mmdc_do_write_level_calibration(void)
+int mmdc_do_write_level_calibration(struct mx6_ddr_sysinfo const *sysinfo)
 {
struct mmdc_p_regs *mmdc0 = (struct mmdc_p_regs *)MMDC_P0_BASE_ADDR;
struct mmdc_p_regs *mmdc1 = (struct mmdc_p_regs *)MMDC_P1_BASE_ADDR;
u32 esdmisc_val, zq_val;
u32 errors = 0;
-   u32 ldectrl[4];
+   u32 ldectrl[4] = {0};
u32 ddr_mr1 = 0x4;
+   u32 rwalat_max;
 
/*
 * Stash old values in case calibration fails,
@@ -101,8 +102,10 @@ int mmdc_do_write_level_calibration(void)
 */
ldectrl[0] = readl(>mpwldectrl0);
ldectrl[1] = readl(>mpwldectrl1);
-   ldectrl[2] = readl(>mpwldectrl0);
-   ldectrl[3] = readl(>mpwldectrl1);
+   if (sysinfo->dsize == 2) {
+   ldectrl[2] = readl(>mpwldectrl0);
+   ldectrl[3] = readl(>mpwldectrl1);
+   }
 
/* disable DDR logic power down timer */
clrbits_le32(>mdpdc, 0xff00);
@@ -122,10 +125,10 @@ int mmdc_do_write_level_calibration(void)
writel(zq_val & ~0x3, >mpzqhwctrl);
 
/* 3. increase walat and ralat to maximum */
-   setbits_le32(>mdmisc,
-(1 << 6) | (1 << 7) | (1 << 8) | (1 << 16) | (1 << 17));
-   setbits_le32(>mdmisc,
-(1 << 6) | (1 << 7) | (1 << 8) | (1 << 16) | (1 << 17));
+   rwalat_max = (1 << 6) | (1 << 7) | (1 << 8) | (1 << 16) | (1 << 17);
+   setbits_le32(>mdmisc, rwalat_max);
+   if (sysinfo->dsize == 2)
+   setbits_le32(>mdmisc, rwalat_max);
/*
 * 4 & 5. Configure the external DDR device to enter write-leveling
 * mode through Load Mode Register command.
@@ -152,21 +155,25 @@ int mmdc_do_write_level_calibration(void)
 */
if (readl(>mpwlgcr) & 0x0F00)
errors |= 1;
-   if (readl(>mpwlgcr) & 0x0F00)
-   errors |= 2;
+   if (sysinfo->dsize == 2)
+   if (readl(>mpwlgcr) & 0x0F00)
+   errors |= 2;
 
debug("Ending write leveling calibration. Error mask: 0x%x\n", errors);
 
/* check to see if cal failed */
if ((readl(>mpwldectrl0) == 0x001F001F) &&
(readl(>mpwldectrl1) == 0x001F001F) &&
-   (readl(>mpwldectrl0) == 0x001F001F) &&
-   (readl(>mpwldectrl1) == 0x001F001F)) {
+   ((sysinfo->dsize < 2) ||
+((readl(>mpwldectrl0) == 0x001F001F) &&
+ (readl(>mpwldectrl1) == 0x001F001F {
debug("Cal seems to have soft-failed due to memory not 
supporting write leveling on all channels. Restoring original write leveling 
values.\n");
writel(ldectrl[0], >mpwldectrl0);
writel(ldectrl[1], >mpwldectrl1);
-   writel(ldectrl[2], >mpwldectrl0);
-   writel(ldectrl[3], >mpwldectrl1);
+   if (sysinfo->dsize == 2) {
+   writel(ldectrl[2], >mpwldectrl0);
+   writel(ldectrl[3], >mpwldectrl1);
+   }
errors |= 4;
}
 
@@ -189,16 +196,20 @@ int mmdc_do_write_level_calibration(void)
  readl(>mpwldectrl0));
debug("\tMMDC_MPWLDECTRL1 after write level cal: 0x%08X\n",
  readl(>mpwldectrl1));
-   debug("\tMMDC_MPWLDECTRL0 after write level cal: 0x%08X\n",
- readl(>mpw

[U-Boot] [PATCH V2 3/4] mx6: ddr: add routine to return DDR calibration data

2016-10-30 Thread Eric Nelson
Add routine mmdc_read_calibration() to return the output of DDR
calibration. This can be used for debugging or to aid in construction
of static memory configuration.

This routine will be used in a subsequent patch set adding a virtual
"mx6memcal" board, but could also be useful when gathering statistics
during an initial production run.

Signed-off-by: Eric Nelson <e...@nelint.com>
---
Commit message expanded in V2

 arch/arm/cpu/armv7/mx6/ddr.c| 23 +++
 arch/arm/include/asm/arch-mx6/mx6-ddr.h |  2 ++
 2 files changed, 25 insertions(+)

diff --git a/arch/arm/cpu/armv7/mx6/ddr.c b/arch/arm/cpu/armv7/mx6/ddr.c
index 274a0ba..b12fb64 100644
--- a/arch/arm/cpu/armv7/mx6/ddr.c
+++ b/arch/arm/cpu/armv7/mx6/ddr.c
@@ -1501,6 +1501,29 @@ void mx6_ddr3_cfg(const struct mx6_ddr_sysinfo *sysinfo,
mdelay(1);
 }
 
+void mmdc_read_calibration(struct mx6_ddr_sysinfo const *sysinfo,
+   struct mx6_mmdc_calibration *calib)
+{
+   struct mmdc_p_regs *mmdc0 = (struct mmdc_p_regs *)MMDC_P0_BASE_ADDR;
+   struct mmdc_p_regs *mmdc1 = (struct mmdc_p_regs *)MMDC_P1_BASE_ADDR;
+
+   calib->p0_mpwldectrl0 = readl(>mpwldectrl0);
+   calib->p0_mpwldectrl1 = readl(>mpwldectrl1);
+   calib->p0_mpdgctrl0 = readl(>mpdgctrl0);
+   calib->p0_mpdgctrl1 = readl(>mpdgctrl1);
+   calib->p0_mprddlctl = readl(>mprddlctl);
+   calib->p0_mpwrdlctl = readl(>mpwrdlctl);
+
+   if (sysinfo->dsize == 2) {
+   calib->p1_mpwldectrl0 = readl(>mpwldectrl0);
+   calib->p1_mpwldectrl1 = readl(>mpwldectrl1);
+   calib->p1_mpdgctrl0 = readl(>mpdgctrl0);
+   calib->p1_mpdgctrl1 = readl(>mpdgctrl1);
+   calib->p1_mprddlctl = readl(>mprddlctl);
+   calib->p1_mpwrdlctl = readl(>mpwrdlctl);
+   }
+}
+
 void mx6_dram_cfg(const struct mx6_ddr_sysinfo *sysinfo,
  const struct mx6_mmdc_calibration *calib,
  const void *ddr_cfg)
diff --git a/arch/arm/include/asm/arch-mx6/mx6-ddr.h 
b/arch/arm/include/asm/arch-mx6/mx6-ddr.h
index cd5bc97..12454fa 100644
--- a/arch/arm/include/asm/arch-mx6/mx6-ddr.h
+++ b/arch/arm/include/asm/arch-mx6/mx6-ddr.h
@@ -461,6 +461,8 @@ void mx6sl_dram_iocfg(unsigned width,
 #if defined(CONFIG_MX6QDL) || defined(CONFIG_MX6Q) || defined(CONFIG_MX6D)
 int mmdc_do_write_level_calibration(struct mx6_ddr_sysinfo const *sysinfo);
 int mmdc_do_dqs_calibration(struct mx6_ddr_sysinfo const *sysinfo);
+void mmdc_read_calibration(struct mx6_ddr_sysinfo const *sysinfo,
+   struct mx6_mmdc_calibration *calib);
 #endif
 
 /* configure mx6 mmdc registers */
-- 
2.7.4

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


[U-Boot] [PATCH V2 4/4] ARM: mx6: ddr: use Kconfig for inclusion of DDR calibration routines

2016-10-30 Thread Eric Nelson
The DDR calibration routines are gated by conditionals for the
i.MX6DQ SOCs, but with the use of the sysinfo parameter, these
are usable on at least i.MX6SDL and i.MX6SL variants with DDR3.

Also, since only the Novena board currently uses the dynamic
DDR calibration routines, these routines waste space on other
boards using SPL.

Add a KConfig entry to allow boards to selectively include the
DDR calibration routines.

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 arch/arm/cpu/armv7/mx6/Kconfig  | 8 
 arch/arm/cpu/armv7/mx6/ddr.c| 3 +--
 arch/arm/include/asm/arch-mx6/mx6-ddr.h | 2 +-
 configs/novena_defconfig| 1 +
 4 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/armv7/mx6/Kconfig b/arch/arm/cpu/armv7/mx6/Kconfig
index 762a581..8b2217e 100644
--- a/arch/arm/cpu/armv7/mx6/Kconfig
+++ b/arch/arm/cpu/armv7/mx6/Kconfig
@@ -35,6 +35,14 @@ config MX6ULL
bool
select MX6UL
 
+config MX6_DDRCAL
+   bool "Include dynamic DDR calibration routines"
+   depends on SPL
+   default n
+   help
+ Say "Y" if your board uses dynamic (per-boot) DDR calibration.
+ If unsure, say N.
+
 choice
prompt "MX6 board select"
optional
diff --git a/arch/arm/cpu/armv7/mx6/ddr.c b/arch/arm/cpu/armv7/mx6/ddr.c
index b12fb64..0cf391e 100644
--- a/arch/arm/cpu/armv7/mx6/ddr.c
+++ b/arch/arm/cpu/armv7/mx6/ddr.c
@@ -14,8 +14,7 @@
 #include 
 #include 
 
-#if defined(CONFIG_MX6QDL) || defined(CONFIG_MX6Q) || defined(CONFIG_MX6D)
-
+#if defined(CONFIG_MX6_DDRCAL)
 static void reset_read_data_fifos(void)
 {
struct mmdc_p_regs *mmdc0 = (struct mmdc_p_regs *)MMDC_P0_BASE_ADDR;
diff --git a/arch/arm/include/asm/arch-mx6/mx6-ddr.h 
b/arch/arm/include/asm/arch-mx6/mx6-ddr.h
index 12454fa..2a8d443 100644
--- a/arch/arm/include/asm/arch-mx6/mx6-ddr.h
+++ b/arch/arm/include/asm/arch-mx6/mx6-ddr.h
@@ -458,7 +458,7 @@ void mx6sl_dram_iocfg(unsigned width,
  const struct mx6sl_iomux_ddr_regs *,
  const struct mx6sl_iomux_grp_regs *);
 
-#if defined(CONFIG_MX6QDL) || defined(CONFIG_MX6Q) || defined(CONFIG_MX6D)
+#if defined(CONFIG_MX6_DDRCAL)
 int mmdc_do_write_level_calibration(struct mx6_ddr_sysinfo const *sysinfo);
 int mmdc_do_dqs_calibration(struct mx6_ddr_sysinfo const *sysinfo);
 void mmdc_read_calibration(struct mx6_ddr_sysinfo const *sysinfo,
diff --git a/configs/novena_defconfig b/configs/novena_defconfig
index 1ffdddc..9d47d5b 100644
--- a/configs/novena_defconfig
+++ b/configs/novena_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_MX6=y
 CONFIG_SPL_GPIO_SUPPORT=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_MX6_DDRCAL=y
 CONFIG_TARGET_KOSAGI_NOVENA=y
 CONFIG_SPL_EXT_SUPPORT=y
 CONFIG_SPL_FAT_SUPPORT=y
-- 
2.7.4

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


[U-Boot] [PATCH V2 0/4] mx6: ddr: updates for dynamic DDR calibration

2016-10-30 Thread Eric Nelson
This set of patches updates the interface to the DDR calibration in 
preparation for the addition of a pseudo-board for calibration on
i.MX6.

The first patch fixes an ommission in the use of the DG_CMP_CYC flag
in register MPDGCTRL0.

The second patch cleans up the handling of bus widths by passing
the system configuration information to the calibration routines.

The third patch adds support for returning the calibration data
written to the MMDC registers.

The fourth patch adds a Kconfig selection to inclut the DDR calibration
routines.

Eric Nelson (4):
  mx6: ddr: allow 32 cycles for DQS gating calibration
  mx6: ddr: pass mx6_ddr_sysinfo to calibration routines
  mx6: ddr: add routine to return DDR calibration data
  ARM: mx6: ddr: use Kconfig for inclusion of DDR calibration routines

 arch/arm/cpu/armv7/mx6/Kconfig  |   5 ++
 arch/arm/cpu/armv7/mx6/ddr.c| 131 +---
 arch/arm/include/asm/arch-mx6/mx6-ddr.h |   8 +-
 board/kosagi/novena/novena_spl.c|   4 +-
 configs/novena_defconfig|   1 +
 5 files changed, 100 insertions(+), 49 deletions(-)

-- 
V2 adds patch 4
2.7.4

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


[U-Boot] [PATCH V2 1/4] mx6: ddr: allow 32 cycles for DQS gating calibration

2016-10-30 Thread Eric Nelson
The DDR calibration code is only setting flag DG_CMP_CYC (DQS gating sample
cycle) for the first PHY.

Set the 32-cycle flag for both PHYs and clear when done so the MPDGCTRL0
output value isn't polluted with calibration artifacts.

Signed-off-by: Eric Nelson <e...@nelint.com>
Reviewed-by: Marek Vasut <ma...@denx.de>
---
No change in V2.
 arch/arm/cpu/armv7/mx6/ddr.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/cpu/armv7/mx6/ddr.c b/arch/arm/cpu/armv7/mx6/ddr.c
index 7beb7ea..b15f376 100644
--- a/arch/arm/cpu/armv7/mx6/ddr.c
+++ b/arch/arm/cpu/armv7/mx6/ddr.c
@@ -347,6 +347,8 @@ int mmdc_do_dqs_calibration(void)
 * 16 before comparing read data.
 */
setbits_le32(>mpdgctrl0, 1 << 30);
+   if (sysinfo->dsize == 2)
+   setbits_le32(>mpdgctrl0, 1 << 30);
 
/* Set bit 28 to start automatic read DQS gating calibration */
setbits_le32(>mpdgctrl0, 5 << 28);
@@ -365,6 +367,11 @@ int mmdc_do_dqs_calibration(void)
if ((bus_size == 0x2) && (readl(>mpdgctrl0) & 0x1000))
errors |= 2;
 
+   /* now disable mpdgctrl0[DG_CMP_CYC] */
+   clrbits_le32(>mpdgctrl0, 1 << 30);
+   if (sysinfo->dsize == 2)
+   clrbits_le32(>mpdgctrl0, 1 << 30);
+
/*
 * DQS gating absolute offset should be modified from
 * reflecting (HW_DG_LOWx + HW_DG_UPx)/2 to
-- 
2.7.4

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


Re: [U-Boot] [PATCH] ARM: mx6: ddr: use Kconfig for inclusion of DDR calibration routines

2016-10-30 Thread Eric Nelson
Thanks Marek,

On 10/30/2016 01:03 PM, Marek Vasut wrote:
> On 10/30/2016 08:20 PM, Eric Nelson wrote:
>> The DDR calibration routines are gated by conditionals for the
>> i.MX6DQ SOCs, but with the use of the sysinfo parameter, these
>> are usable on at least i.MX6SDL and i.MX6SL variants with DDR3.
>>
>> Also, since only the Novena board currently uses the dynamic
>> DDR calibration routines, these routines waste space on other
>> boards using SPL.
>>
>> Add a KConfig entry to allow boards to selectively include the
>> DDR calibration routines.
>>
>> Signed-off-by: Eric Nelson <e...@nelint.com>
>> ---
>>  arch/arm/cpu/armv7/mx6/Kconfig  | 5 +
>>  arch/arm/cpu/armv7/mx6/ddr.c| 3 +--
>>  arch/arm/include/asm/arch-mx6/mx6-ddr.h | 2 +-
>>  configs/novena_defconfig| 1 +
>>  4 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv7/mx6/Kconfig b/arch/arm/cpu/armv7/mx6/Kconfig
>> index 762a581..32536c0 100644
>> --- a/arch/arm/cpu/armv7/mx6/Kconfig
>> +++ b/arch/arm/cpu/armv7/mx6/Kconfig
>> @@ -35,6 +35,11 @@ config MX6ULL
>>  bool
>>  select MX6UL
>>  
>> +config MX6_DDRCAL
>> +bool "Include dynamic DDR calibration routines"
>> +depends on SPL
>> +default n
> 
> Help text would really be helpful ;)
> 

Cool.

I'll fix this and re-send the series as V2 (with the fourth patch).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] ARM: mx6: ddr: use Kconfig for inclusion of DDR calibration routines

2016-10-30 Thread Eric Nelson
The DDR calibration routines are gated by conditionals for the
i.MX6DQ SOCs, but with the use of the sysinfo parameter, these
are usable on at least i.MX6SDL and i.MX6SL variants with DDR3.

Also, since only the Novena board currently uses the dynamic
DDR calibration routines, these routines waste space on other
boards using SPL.

Add a KConfig entry to allow boards to selectively include the
DDR calibration routines.

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 arch/arm/cpu/armv7/mx6/Kconfig  | 5 +
 arch/arm/cpu/armv7/mx6/ddr.c| 3 +--
 arch/arm/include/asm/arch-mx6/mx6-ddr.h | 2 +-
 configs/novena_defconfig| 1 +
 4 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/armv7/mx6/Kconfig b/arch/arm/cpu/armv7/mx6/Kconfig
index 762a581..32536c0 100644
--- a/arch/arm/cpu/armv7/mx6/Kconfig
+++ b/arch/arm/cpu/armv7/mx6/Kconfig
@@ -35,6 +35,11 @@ config MX6ULL
bool
select MX6UL
 
+config MX6_DDRCAL
+   bool "Include dynamic DDR calibration routines"
+   depends on SPL
+   default n
+
 choice
prompt "MX6 board select"
optional
diff --git a/arch/arm/cpu/armv7/mx6/ddr.c b/arch/arm/cpu/armv7/mx6/ddr.c
index b12fb64..0cf391e 100644
--- a/arch/arm/cpu/armv7/mx6/ddr.c
+++ b/arch/arm/cpu/armv7/mx6/ddr.c
@@ -14,8 +14,7 @@
 #include 
 #include 
 
-#if defined(CONFIG_MX6QDL) || defined(CONFIG_MX6Q) || defined(CONFIG_MX6D)
-
+#if defined(CONFIG_MX6_DDRCAL)
 static void reset_read_data_fifos(void)
 {
struct mmdc_p_regs *mmdc0 = (struct mmdc_p_regs *)MMDC_P0_BASE_ADDR;
diff --git a/arch/arm/include/asm/arch-mx6/mx6-ddr.h 
b/arch/arm/include/asm/arch-mx6/mx6-ddr.h
index 12454fa..2a8d443 100644
--- a/arch/arm/include/asm/arch-mx6/mx6-ddr.h
+++ b/arch/arm/include/asm/arch-mx6/mx6-ddr.h
@@ -458,7 +458,7 @@ void mx6sl_dram_iocfg(unsigned width,
  const struct mx6sl_iomux_ddr_regs *,
  const struct mx6sl_iomux_grp_regs *);
 
-#if defined(CONFIG_MX6QDL) || defined(CONFIG_MX6Q) || defined(CONFIG_MX6D)
+#if defined(CONFIG_MX6_DDRCAL)
 int mmdc_do_write_level_calibration(struct mx6_ddr_sysinfo const *sysinfo);
 int mmdc_do_dqs_calibration(struct mx6_ddr_sysinfo const *sysinfo);
 void mmdc_read_calibration(struct mx6_ddr_sysinfo const *sysinfo,
diff --git a/configs/novena_defconfig b/configs/novena_defconfig
index 1ffdddc..9d47d5b 100644
--- a/configs/novena_defconfig
+++ b/configs/novena_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_MX6=y
 CONFIG_SPL_GPIO_SUPPORT=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_MX6_DDRCAL=y
 CONFIG_TARGET_KOSAGI_NOVENA=y
 CONFIG_SPL_EXT_SUPPORT=y
 CONFIG_SPL_FAT_SUPPORT=y
-- 
2.7.4

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


Re: [U-Boot] [PATCH 3/3] mx6: ddr: add routine to return DDR calibration data

2016-10-30 Thread Eric Nelson
Hi Marek,

On 10/30/2016 10:30 AM, Marek Vasut wrote:
> On 10/30/2016 06:19 PM, Eric Nelson wrote:
>> Add routine mmdc_read_calibration() to return the output of DDR
>> calibration. This can be used for debugging or to aid in construction
>> of static memory configuration.
>>
>> Signed-off-by: Eric Nelson <e...@nelint.com>
> 
> Do you plan to use it or will this be mostly dead code ?
> 

I plan to use it.

I'm cleaning things up before (re)sending a patch adding the
virtual "mx6memcal" board and wanted to push the supporting
changes in a separate set.

I have one more independent patch (4/3?) to send before
the new board.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 3/3] mx6: ddr: add routine to return DDR calibration data

2016-10-30 Thread Eric Nelson
Add routine mmdc_read_calibration() to return the output of DDR
calibration. This can be used for debugging or to aid in construction
of static memory configuration.

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 arch/arm/cpu/armv7/mx6/ddr.c| 23 +++
 arch/arm/include/asm/arch-mx6/mx6-ddr.h |  2 ++
 2 files changed, 25 insertions(+)

diff --git a/arch/arm/cpu/armv7/mx6/ddr.c b/arch/arm/cpu/armv7/mx6/ddr.c
index 274a0ba..b12fb64 100644
--- a/arch/arm/cpu/armv7/mx6/ddr.c
+++ b/arch/arm/cpu/armv7/mx6/ddr.c
@@ -1501,6 +1501,29 @@ void mx6_ddr3_cfg(const struct mx6_ddr_sysinfo *sysinfo,
mdelay(1);
 }
 
+void mmdc_read_calibration(struct mx6_ddr_sysinfo const *sysinfo,
+   struct mx6_mmdc_calibration *calib)
+{
+   struct mmdc_p_regs *mmdc0 = (struct mmdc_p_regs *)MMDC_P0_BASE_ADDR;
+   struct mmdc_p_regs *mmdc1 = (struct mmdc_p_regs *)MMDC_P1_BASE_ADDR;
+
+   calib->p0_mpwldectrl0 = readl(>mpwldectrl0);
+   calib->p0_mpwldectrl1 = readl(>mpwldectrl1);
+   calib->p0_mpdgctrl0 = readl(>mpdgctrl0);
+   calib->p0_mpdgctrl1 = readl(>mpdgctrl1);
+   calib->p0_mprddlctl = readl(>mprddlctl);
+   calib->p0_mpwrdlctl = readl(>mpwrdlctl);
+
+   if (sysinfo->dsize == 2) {
+   calib->p1_mpwldectrl0 = readl(>mpwldectrl0);
+   calib->p1_mpwldectrl1 = readl(>mpwldectrl1);
+   calib->p1_mpdgctrl0 = readl(>mpdgctrl0);
+   calib->p1_mpdgctrl1 = readl(>mpdgctrl1);
+   calib->p1_mprddlctl = readl(>mprddlctl);
+   calib->p1_mpwrdlctl = readl(>mpwrdlctl);
+   }
+}
+
 void mx6_dram_cfg(const struct mx6_ddr_sysinfo *sysinfo,
  const struct mx6_mmdc_calibration *calib,
  const void *ddr_cfg)
diff --git a/arch/arm/include/asm/arch-mx6/mx6-ddr.h 
b/arch/arm/include/asm/arch-mx6/mx6-ddr.h
index cd5bc97..12454fa 100644
--- a/arch/arm/include/asm/arch-mx6/mx6-ddr.h
+++ b/arch/arm/include/asm/arch-mx6/mx6-ddr.h
@@ -461,6 +461,8 @@ void mx6sl_dram_iocfg(unsigned width,
 #if defined(CONFIG_MX6QDL) || defined(CONFIG_MX6Q) || defined(CONFIG_MX6D)
 int mmdc_do_write_level_calibration(struct mx6_ddr_sysinfo const *sysinfo);
 int mmdc_do_dqs_calibration(struct mx6_ddr_sysinfo const *sysinfo);
+void mmdc_read_calibration(struct mx6_ddr_sysinfo const *sysinfo,
+   struct mx6_mmdc_calibration *calib);
 #endif
 
 /* configure mx6 mmdc registers */
-- 
2.7.4

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


[U-Boot] [PATCH 0/3] mx6: ddr: updates for dynamic DDR calibration

2016-10-30 Thread Eric Nelson
This set of patches updates the interface to the DDR calibration in 
preparation for the addition of a pseudo-board for calibration on
i.MX6.

The first patch fixes an ommission in the use of the DG_CMP_CYC flag
in register MPDGCTRL0.

The second patch cleans up the handling of bus widths by passing
the system configuration information to the calibration routines.

The third routine adds support for returning the calibration data
written to the MMDC registers.

Eric Nelson (3):
  mx6: ddr: allow 32 cycles for DQS gating calibration
  mx6: ddr: pass mx6_ddr_sysinfo to calibration routines
  mx6: ddr: add mmdc_read_calibration routine to return dynamic data

 arch/arm/cpu/armv7/mx6/ddr.c| 128 +---
 arch/arm/include/asm/arch-mx6/mx6-ddr.h |   6 +-
 board/kosagi/novena/novena_spl.c|   4 +-
 3 files changed, 92 insertions(+), 46 deletions(-)

-- 
2.7.4

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


[U-Boot] [PATCH 1/3] mx6: ddr: allow 32 cycles for DQS gating calibration

2016-10-30 Thread Eric Nelson
The DDR calibration code is only setting flag DG_CMP_CYC (DQS gating sample
cycle) for the first PHY.

Set the 32-cycle flag for both PHYs and clear when done so the MPDGCTRL0
output value isn't polluted with calibration artifacts.

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 arch/arm/cpu/armv7/mx6/ddr.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/cpu/armv7/mx6/ddr.c b/arch/arm/cpu/armv7/mx6/ddr.c
index 7beb7ea..b15f376 100644
--- a/arch/arm/cpu/armv7/mx6/ddr.c
+++ b/arch/arm/cpu/armv7/mx6/ddr.c
@@ -347,6 +347,8 @@ int mmdc_do_dqs_calibration(void)
 * 16 before comparing read data.
 */
setbits_le32(>mpdgctrl0, 1 << 30);
+   if (sysinfo->dsize == 2)
+   setbits_le32(>mpdgctrl0, 1 << 30);
 
/* Set bit 28 to start automatic read DQS gating calibration */
setbits_le32(>mpdgctrl0, 5 << 28);
@@ -365,6 +367,11 @@ int mmdc_do_dqs_calibration(void)
if ((bus_size == 0x2) && (readl(>mpdgctrl0) & 0x1000))
errors |= 2;
 
+   /* now disable mpdgctrl0[DG_CMP_CYC] */
+   clrbits_le32(>mpdgctrl0, 1 << 30);
+   if (sysinfo->dsize == 2)
+   clrbits_le32(>mpdgctrl0, 1 << 30);
+
/*
 * DQS gating absolute offset should be modified from
 * reflecting (HW_DG_LOWx + HW_DG_UPx)/2 to
-- 
2.7.4

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


[U-Boot] [PATCH 2/3] mx6: ddr: pass mx6_ddr_sysinfo to calibration routines

2016-10-30 Thread Eric Nelson
The DDR calibration routines have scattered support for bus
widths other than 64-bits:

-- The mmdc_do_write_level_calibration() routine assumes the
presence of PHY1, and
-- The mmdc_do_dqs_calibration() routine tries to determine
whether one or two DDR PHYs are active by reading MDCTL.

Since a caller of these routines must have a valid struct mx6_ddr_sysinfo
for use in calling mx6_dram_cfg(), and the bus width is available in the
"dsize" field, use this structure to inform the calibration routines which
PHYs are active.

This allows the use of the DDR calibration routines on CPU variants
like i.MX6SL that only have a single MMDC port.

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 arch/arm/cpu/armv7/mx6/ddr.c| 98 +++--
 arch/arm/include/asm/arch-mx6/mx6-ddr.h |  4 +-
 board/kosagi/novena/novena_spl.c|  4 +-
 3 files changed, 60 insertions(+), 46 deletions(-)

diff --git a/arch/arm/cpu/armv7/mx6/ddr.c b/arch/arm/cpu/armv7/mx6/ddr.c
index b15f376..274a0ba 100644
--- a/arch/arm/cpu/armv7/mx6/ddr.c
+++ b/arch/arm/cpu/armv7/mx6/ddr.c
@@ -86,14 +86,15 @@ static void modify_dg_result(u32 *reg_st0, u32 *reg_st1, 
u32 *reg_ctrl)
writel(val_ctrl, reg_ctrl);
 }
 
-int mmdc_do_write_level_calibration(void)
+int mmdc_do_write_level_calibration(struct mx6_ddr_sysinfo const *sysinfo)
 {
struct mmdc_p_regs *mmdc0 = (struct mmdc_p_regs *)MMDC_P0_BASE_ADDR;
struct mmdc_p_regs *mmdc1 = (struct mmdc_p_regs *)MMDC_P1_BASE_ADDR;
u32 esdmisc_val, zq_val;
u32 errors = 0;
-   u32 ldectrl[4];
+   u32 ldectrl[4] = {0};
u32 ddr_mr1 = 0x4;
+   u32 rwalat_max;
 
/*
 * Stash old values in case calibration fails,
@@ -101,8 +102,10 @@ int mmdc_do_write_level_calibration(void)
 */
ldectrl[0] = readl(>mpwldectrl0);
ldectrl[1] = readl(>mpwldectrl1);
-   ldectrl[2] = readl(>mpwldectrl0);
-   ldectrl[3] = readl(>mpwldectrl1);
+   if (sysinfo->dsize == 2) {
+   ldectrl[2] = readl(>mpwldectrl0);
+   ldectrl[3] = readl(>mpwldectrl1);
+   }
 
/* disable DDR logic power down timer */
clrbits_le32(>mdpdc, 0xff00);
@@ -122,10 +125,10 @@ int mmdc_do_write_level_calibration(void)
writel(zq_val & ~0x3, >mpzqhwctrl);
 
/* 3. increase walat and ralat to maximum */
-   setbits_le32(>mdmisc,
-(1 << 6) | (1 << 7) | (1 << 8) | (1 << 16) | (1 << 17));
-   setbits_le32(>mdmisc,
-(1 << 6) | (1 << 7) | (1 << 8) | (1 << 16) | (1 << 17));
+   rwalat_max = (1 << 6) | (1 << 7) | (1 << 8) | (1 << 16) | (1 << 17);
+   setbits_le32(>mdmisc, rwalat_max);
+   if (sysinfo->dsize == 2)
+   setbits_le32(>mdmisc, rwalat_max);
/*
 * 4 & 5. Configure the external DDR device to enter write-leveling
 * mode through Load Mode Register command.
@@ -152,21 +155,25 @@ int mmdc_do_write_level_calibration(void)
 */
if (readl(>mpwlgcr) & 0x0F00)
errors |= 1;
-   if (readl(>mpwlgcr) & 0x0F00)
-   errors |= 2;
+   if (sysinfo->dsize == 2)
+   if (readl(>mpwlgcr) & 0x0F00)
+   errors |= 2;
 
debug("Ending write leveling calibration. Error mask: 0x%x\n", errors);
 
/* check to see if cal failed */
if ((readl(>mpwldectrl0) == 0x001F001F) &&
(readl(>mpwldectrl1) == 0x001F001F) &&
-   (readl(>mpwldectrl0) == 0x001F001F) &&
-   (readl(>mpwldectrl1) == 0x001F001F)) {
+   ((sysinfo->dsize < 2) ||
+((readl(>mpwldectrl0) == 0x001F001F) &&
+ (readl(>mpwldectrl1) == 0x001F001F {
debug("Cal seems to have soft-failed due to memory not 
supporting write leveling on all channels. Restoring original write leveling 
values.\n");
writel(ldectrl[0], >mpwldectrl0);
writel(ldectrl[1], >mpwldectrl1);
-   writel(ldectrl[2], >mpwldectrl0);
-   writel(ldectrl[3], >mpwldectrl1);
+   if (sysinfo->dsize == 2) {
+   writel(ldectrl[2], >mpwldectrl0);
+   writel(ldectrl[3], >mpwldectrl1);
+   }
errors |= 4;
}
 
@@ -189,16 +196,20 @@ int mmdc_do_write_level_calibration(void)
  readl(>mpwldectrl0));
debug("\tMMDC_MPWLDECTRL1 after write level cal: 0x%08X\n",
  readl(>mpwldectrl1));
-   debug("\tMMDC_MPWLDECTRL0 after write level cal: 0x%08X\n",
- readl(>mpwldectrl0));
-   debug("\tMMDC

[U-Boot] [PATCH] imx: mx6: ddr: add register MPZQLP2CTL for LPDDR2

2016-10-28 Thread Eric Nelson
Add constants for the MPZQLP2CTL DDR register for both
banks to allow setting the LPDDR2 timing values in
.cfg files using a named constant instead of hex addresses
as is currently done in mx6slevk and other board files.

Signed-off-by: Eric Nelson <e...@nelint.com>
---
 arch/arm/include/asm/arch-mx6/mx6-ddr.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/arch-mx6/mx6-ddr.h 
b/arch/arm/include/asm/arch-mx6/mx6-ddr.h
index 9922409..53eb5fa 100644
--- a/arch/arm/include/asm/arch-mx6/mx6-ddr.h
+++ b/arch/arm/include/asm/arch-mx6/mx6-ddr.h
@@ -495,6 +495,7 @@ void mx6_dram_cfg(const struct mx6_ddr_sysinfo *,
 #define MX6_MMDC_P0_MPDGCTRL1  0x021b0840
 #define MX6_MMDC_P0_MPRDDLCTL  0x021b0848
 #define MX6_MMDC_P0_MPWRDLCTL  0x021b0850
+#define MX6_MMDC_P0_MPZQLP2CTL 0x021b085C
 #define MX6_MMDC_P0_MPMUR0 0x021b08b8
 
 #define MX6_MMDC_P1_MDCTL  0x021b4000
@@ -522,6 +523,7 @@ void mx6_dram_cfg(const struct mx6_ddr_sysinfo *,
 #define MX6_MMDC_P1_MPDGCTRL1  0x021b4840
 #define MX6_MMDC_P1_MPRDDLCTL  0x021b4848
 #define MX6_MMDC_P1_MPWRDLCTL  0x021b4850
+#define MX6_MMDC_P1_MPZQLP2CTL 0x021b485C
 #define MX6_MMDC_P1_MPMUR0 0x021b48b8
 
 #endif /*__ASM_ARCH_MX6_DDR_H__ */
-- 
2.7.4

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


  1   2   3   4   5   6   7   8   9   10   >