Re: [PATCH 5/8] mx6memcal: Remove SPL_USB_HOST
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 AgnerThis 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
Hi Stefan, On 09/08/2017 05:35 PM, Fabio Estevam wrote: On Fri, Sep 8, 2017 at 8:35 PM, Stefan Agnerwrote: + /* +* 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
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
Hi Stefan, On 09/08/2017 04:35 PM, Stefan Agner wrote: From: Stefan AgnerThe 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
Hi Stefan, On 09/08/2017 04:35 PM, Stefan Agner wrote: From: Stefan AgnerThis 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
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
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
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
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
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
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 AgnerThis 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
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
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
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 RobinsonSigned-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
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 FanSigned-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
Hi Stefan, On 09/04/2017 06:21 PM, Stefan Agner wrote: From: Stefan AgnerThis 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
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 RobinsonSigned-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
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
On 08/31/2017 04:11 PM, Fabio Estevam wrote: Troy, On Thu, Aug 31, 2017 at 7:53 PM, Troy Kiskywrote: 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
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
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
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
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
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
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
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
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
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
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
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
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
Hi Stefan, On 08/04/2017 04:38 PM, Stefan Agner wrote: From: Stefan AgnerThis 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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)
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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