[U-Boot] [PATCH 1/3] mmc: dw_mmc: remove the duplicated header file

[Jaehoon Chung]

 is already included in .
It can use  instead of 

Signed-off-by: Jaehoon Chung 
---
 drivers/mmc/dw_mmc.c| 1 -
 drivers/mmc/exynos_dw_mmc.c | 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 2cf7bae..8687368 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #define PAGE_SIZE 4096
 
diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
index 283befc..57271f1 100644
--- a/drivers/mmc/exynos_dw_mmc.c
+++ b/drivers/mmc/exynos_dw_mmc.c
@@ -10,12 +10,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 
 #defineDWMMC_MAX_CH_NUM4
 #defineDWMMC_MAX_FREQ  5200
-- 
1.9.1

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

[U-Boot] [PATCH 3/3] mmc: use the generic error number

[Jaehoon Chung]

Use the generic error number instead of specific error number.
If use the generic error number, it can debug more easier.

Signed-off-by: Jaehoon Chung 
---
 drivers/mmc/arm_pl180_mmci.c |  2 +-
 drivers/mmc/bfin_sdh.c   | 10 +-
 drivers/mmc/davinci_mmc.c| 11 ++-
 drivers/mmc/dw_mmc.c |  8 
 drivers/mmc/fsl_esdhc.c  | 13 +++--
 drivers/mmc/ftsdc010_mci.c   | 10 +-
 drivers/mmc/gen_atmel_mci.c  | 10 +-
 drivers/mmc/mmc.c| 18 +-
 drivers/mmc/mmc_spi.c| 11 ++-
 drivers/mmc/mvebu_mmc.c  |  9 +
 drivers/mmc/mxcmmc.c |  6 +++---
 drivers/mmc/mxsmmc.c | 18 +-
 drivers/mmc/omap_hsmmc.c | 18 +-
 drivers/mmc/s3c_sdi.c|  4 ++--
 drivers/mmc/sdhci.c  |  8 
 drivers/mmc/sh_mmcif.c   |  8 
 drivers/mmc/sh_sdhi.c|  6 +++---
 drivers/mmc/sunxi_mmc.c  |  6 +++---
 drivers/mmc/tegra_mmc.c  |  7 ---
 drivers/mmc/uniphier-sd.c|  2 +-
 include/mmc.h|  6 --
 21 files changed, 95 insertions(+), 96 deletions(-)

diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index 8f2694f..e64ac3c 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -37,7 +37,7 @@ static int wait_for_command_end(struct mmc *dev, struct 
mmc_cmd *cmd)
writel(statusmask, >base->status_clear);
if (hoststatus & SDI_STA_CTIMEOUT) {
debug("CMD%d time out\n", cmd->cmdidx);
-   return TIMEOUT;
+   return -ETIMEDOUT;
} else if ((hoststatus & SDI_STA_CCRCFAIL) &&
   (cmd->resp_type & MMC_RSP_CRC)) {
printf("CMD%d CRC error\n", cmd->cmdidx);
diff --git a/drivers/mmc/bfin_sdh.c b/drivers/mmc/bfin_sdh.c
index 9bdfbbc..0e493da 100644
--- a/drivers/mmc/bfin_sdh.c
+++ b/drivers/mmc/bfin_sdh.c
@@ -109,9 +109,9 @@ sdh_send_cmd(struct mmc *mmc, struct mmc_cmd *mmc_cmd)
}
 
if (status & CMD_TIME_OUT)
-   ret = TIMEOUT;
+   ret = -ETIMEDOUT;
else if (status & CMD_CRC_FAIL && flags & MMC_RSP_CRC)
-   ret = COMM_ERR;
+   ret = -ECOMM;
else
ret = 0;
 
@@ -136,7 +136,7 @@ static int sdh_setup_data(struct mmc *mmc, struct mmc_data 
*data)
 
/* Don't support write yet. */
if (data->flags & MMC_DATA_WRITE)
-   return UNUSABLE_ERR;
+   return -EOPNOTSUPP;
 #ifndef RSI_BLKSZ
data_ctl |= ((ffs(data->blocksize) - 1) << 4);
 #else
@@ -194,10 +194,10 @@ static int bfin_sdh_request(struct mmc *mmc, struct 
mmc_cmd *cmd,
 
if (status & DAT_TIME_OUT) {
bfin_write_SDH_STATUS_CLR(DAT_TIMEOUT_STAT);
-   ret |= TIMEOUT;
+   ret = -ETIMEDOUT;
} else if (status & (DAT_CRC_FAIL | RX_OVERRUN)) {
bfin_write_SDH_STATUS_CLR(DAT_CRC_FAIL_STAT | 
RX_OVERRUN_STAT);
-   ret |= COMM_ERR;
+   ret = -ECOMM;
} else
bfin_write_SDH_STATUS_CLR(DAT_BLK_END_STAT | 
DAT_END_STAT);
 
diff --git a/drivers/mmc/davinci_mmc.c b/drivers/mmc/davinci_mmc.c
index aae00e9..b495c75 100644
--- a/drivers/mmc/davinci_mmc.c
+++ b/drivers/mmc/davinci_mmc.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -66,7 +67,7 @@ dmmc_wait_fifo_status(volatile struct davinci_mmc_regs *regs, 
uint status)
udelay(100);
 
if (wdog == 0)
-   return COMM_ERR;
+   return -ECOMM;
 
return 0;
 }
@@ -80,7 +81,7 @@ static int dmmc_busy_wait(volatile struct davinci_mmc_regs 
*regs)
udelay(10);
 
if (wdog == 0)
-   return COMM_ERR;
+   return -ECOMM;
 
return 0;
 }
@@ -99,7 +100,7 @@ static int dmmc_check_status(volatile struct 
davinci_mmc_regs *regs,
return 0;
} else if (mmcstatus & st_error) {
if (mmcstatus & MMCST0_TOUTRS)
-   return TIMEOUT;
+   return -ETIMEDOUT;
printf("[ ST0 ERROR %x]\n", mmcstatus);
/*
 * Ignore CRC errors as some MMC cards fail to
@@ -107,7 +108,7 @@ static int dmmc_check_status(volatile struct 
davinci_mmc_regs *regs,
 */
if (mmcstatus & MMCST0_CRCRS)
return 0;
-   return COMM_ERR;
+   return -ECOMM;
}
udelay(10);
 
@@ -116,7 +117,7 @@ static int dmmc_check_status(volatile struct 
davinci_mmc_regs *regs,
 
printf("Status %x Timeout ST0:%x ST1:%x\n", st_ready, mmcstatus,
 

[U-Boot] [PATCH 2/3] mmc: fsl_esdhc: remove the duplcated header file

[Jaehoon Chung]

"mmc.h" is already included. It's duplicated.

Signed-off-by: Jaehoon Chung 
---
 drivers/mmc/fsl_esdhc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index a865c7b..86c9a67 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -16,7 +16,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
1.9.1

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

Re: [U-Boot] u-boot: x86: interrupt mapping

[Bin Meng]

Hi Jian,

On Tue, Jul 19, 2016 at 4:03 PM, Jian Luo  wrote:
> Hallo Christian,
>
>
> On 19.07.2016 08:02, Christian Gmeiner wrote:
>
> Hi Bin
>
> For the moment I have no answer to this question. I need to dive into
> the vxworks code, which
> is not what I like to do now (but needs to be done)-
>
> Yes, please do track it down. The interrupt line register configured
> by U-Boot should be enough for VxWorks to function under PIC mode.
>
> I have an other (wired) question you may could help out.
>
> http://www.mouser.com/pdfdocs/Intel_Platform_Controller_Hub_EG20T_datasheet.pdf
> (page 124)
>
> On my development board the uart_clk is connected to a oscillator and
> everything works as expected.
> But on the production devices the uart_clk is not connected and fsp
> hangs with post code 0x2e.
>
> I am not sure about the meaning of post code 0x2e. Jian has some
> working experience on Atom E6xx with U-Boot. Adding him.
>
> 0x2e == POST_PRE_MRC (arch/x86/include/asm/post.h)
>
> Now I would like to change the initial mux settings to use usb_48mhz
> but I am quite sure that I need
> to have the pci bus and its devices initialised already in order to
> change the CLKCFG register. Do you
> think there is an other way of accessing this register like fixed
> memory address etc?
>
> Which register do you want to program for this uart_clk? If it's on
> the PCI configuration space, you can use PCI config APIs to program.
>
> There a handful of registers I would need to program but all of them are
> accessible via pic config space. E.g CLKCFG:
>
> Size: 32-bit Default: 2C00 Power Well: Core
> Access PCI Configuration B:D:F D0:F0 Offset Start: Offset End: 500h 503h
> Memory Mapped I/O BAR: PKTHubCTLBASE Offset: 500h
>
>
> As I need to program those registers before fsp_init I must setup the pci
> bus by myself, change the register values and call fsb_init routine.
> Correct?
>
> My board had this problem too. I however toke a different approach

Great, I got you :)

> by patching the original FSP. The waiting for Topcliff UART ready is

How did you patch the original FSP? Did you reverse engineering the FSP?

> completely
> bypassed in all UEFI blobs. You can use UEFITool [1] to extract blobs in
> the attached FSP for comparison.
>
> greets
> --
> Christian Gmeiner, MSc
>
> https://soundcloud.com/christian-gmeiner
>
> [1] https://github.com/LongSoft/UEFITool
>

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

[U-Boot] [PATCH v3 2/3] spi: zynqmp_qspi: Add QSPI driver support for ZynqMP

[Siva Durga Prasad Paladugu]

This adds QSPI driver support for ZynqMP platform
This driver supports all spi flash commands in
qspi single mode.

Signed-off-by: Siva Durga Prasad Paladugu 
---
Changes for v3:
- None
Changes for v2:
- set no_all_quad as zynqmp qspi
  controller doesnt support it
---
 drivers/spi/Kconfig   |   9 +
 drivers/spi/Makefile  |   1 +
 drivers/spi/zynqmp_qspi.c | 705 ++
 3 files changed, 715 insertions(+)
 create mode 100644 drivers/spi/zynqmp_qspi.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index aca385d..6814ff9 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -172,6 +172,15 @@ config ZYNQ_QSPI
  Zynq QSPI IP core. This IP is used to connect the flash in
  4-bit qspi, 8-bit dual stacked and shared 4-bit dual parallel.
 
+config ZYNQMP_QSPI
+   bool "ZynqMP QSPI driver"
+   depends on ARCH_ZYNQMP
+   help
+ Enable the ZynqMP Quad-SPI (QSPI) driver. This driver can be
+ used to access the SPI NOR flash on platforms embedding this
+ ZynqMP QSPI IP core. This IP is used to connect the flash in
+ 4-bit qspi, 8-bit dual stacked and shared 4-bit dual parallel.
+
 config OMAP3_SPI
bool "McSPI driver for OMAP"
help
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index b1d9e20..4ea1266 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -53,3 +53,4 @@ obj-$(CONFIG_TI_QSPI) += ti_qspi.o
 obj-$(CONFIG_XILINX_SPI) += xilinx_spi.o
 obj-$(CONFIG_ZYNQ_SPI) += zynq_spi.o
 obj-$(CONFIG_ZYNQ_QSPI) += zynq_qspi.o
+obj-$(CONFIG_ZYNQMP_QSPI) += zynqmp_qspi.o
diff --git a/drivers/spi/zynqmp_qspi.c b/drivers/spi/zynqmp_qspi.c
new file mode 100644
index 000..93ace51
--- /dev/null
+++ b/drivers/spi/zynqmp_qspi.c
@@ -0,0 +1,705 @@
+/*
+ * Xilinx ZynqMP Quad-SPI(QSPI) Controller Driver
+ *
+ * (C) Copyright 2016 Xilinx, Inc
+ * Siva Durga Prasad 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "../mtd/spi/sf_internal.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * QSPI Config Register bit Masks
+ */
+#define ZYNQMP_QSPI_CONFIG_STRT_MODE_MASK  BIT(29)
+#define ZYNQMP_QSPI_CONFIG_MODE_EN_MASKGENMASK(31, 30)
+#define ZYNQMP_QSPI_CONFIG_DMA_MODEBIT(31)
+#define ZYNQMP_QSPI_CONFIG_CPHA_MASK   BIT(2)
+#define ZYNQMP_QSPI_CONFIG_CPOL_MASK   BIT(1)
+#define ZYNQMP_QSPI_CONFIG_GFIFO_WP_HOLD   BIT(19)
+#define ZYNQMP_QSPI_CONFIG_BAUD_DIV_MASK   GENMASK(5, 3)
+#define ZYNQMP_QSPI_CONFIG_DFLT_BAUD_RATE_DIV  BIT(3)
+
+/*
+ * QSPI Interrupt Registers bit Masks
+ */
+#define ZYNQMP_QSPI_IXR_TXNFULL_MASK   BIT(2)
+#define ZYNQMP_QSPI_IXR_TXFULL_MASKBIT(3)
+#define ZYNQMP_QSPI_IXR_RXNEMTY_MASK   BIT(4)
+#define ZYNQMP_QSPI_IXR_GFEMTY_MASKBIT(7)
+#define ZYNQMP_QSPI_IXR_ALL_MASK   (ZYNQMP_QSPI_IXR_TXNFULL_MASK | \
+ZYNQMP_QSPI_IXR_RXNEMTY_MASK)
+#define ZYNQMP_QSPI_GFIFO_ALL_INT_MASK 0xFBE
+
+/*
+ * QSPI Enable Register bit Masks
+ */
+#define ZYNQMP_QSPI_ENABLE_ENABLE_MASK BIT(0)
+
+/*
+ * QSPI Generic FIFO register bit masks
+ */
+#define ZYNQMP_QSPI_GFIFO_LOW_BUS  BIT(14)
+#define ZYNQMP_QSPI_GFIFO_CS_LOWER BIT(12)
+#define ZYNQMP_QSPI_GFIFO_UP_BUS   BIT(15)
+#define ZYNQMP_QSPI_GFIFO_CS_UPPER BIT(13)
+#define ZYNQMP_QSPI_GFIFO_SPI_MODE_QSPIGENMASK(11, 10)
+#define ZYNQMP_QSPI_GFIFO_SPI_MODE_SPI BIT(10)
+#define ZYNQMP_QSPI_GFIFO_TX   BIT(16)
+#define ZYNQMP_QSPI_GFIFO_RX   BIT(17)
+#define ZYNQMP_QSPI_GFIFO_STRIPE_MASK  BIT(18)
+#define ZYNQMP_QSPI_GFIFO_IMD_MASK GENMASK(7, 0)
+#define ZYNQMP_QSPI_GFIFO_EXP_MASK BIT(9)
+#define ZYNQMP_QSPI_GFIFO_DATA_XFR_MASKBIT(8)
+
+#define ZYNQMP_QSPI_GFIFO_IMD_DATA_CS_ASSERT   5
+#define ZYNQMP_QSPI_GFIFO_IMD_DATA_CS_DEASSERT 5
+#define ZYNQMP_QSPI_GFIFO_EXP_INIT_VAL 8
+#define ZYNQMP_QSPI_GFIFO_IMD_MAX_DATA_LEN 255
+/*
+ * QSPI DMA Destination status register bit masks
+ */
+#define ZYNQMP_QSPI_DMA_DST_I_STS_DONE BIT(1)
+#define ZYNQMP_QSPI_DMA_DST_I_STS_MASK GENMASK(7, 1)
+
+/*
+ * QSPI Generic QSPI selection register bit mask
+ */
+#define ZYNQMP_QSPI_GQSPI_SELECT   BIT(0)
+
+#define ZYNQMP_QSPI_FIFO_THRESHOLD 1
+
+#define SPI_XFER_ON_BOTH   0
+#define SPI_XFER_ON_LOWER  1
+#define SPI_XFER_ON_UPPER  2
+
+#define ZYNQMP_QSPI_DMA_ALIGN  0x4
+#define ZYNQMP_QSPI_DMA_POLL_TIMEOUT   1000
+
+#define ZYNQMP_QSPI_GENERIC_BASEADDR_OFFSET0x100
+#define ZYNQMP_QSPI_GENERIC_DMABASE_OFFSET 0x800
+
+/* QSPI register offsets */
+struct zynqmp_qspi_regs {
+   u32 confr;  /* 0x00 */
+   u32 isr;/* 0x04 */
+   u32 ier;/* 0x08 */
+   u32 idisr;  /* 0x0C 

[U-Boot] [PATCH] board: ls1012afrdm: overwrite CONFIG_EXTRA_ENV_SETTINGS

[Prabhakar Kushwaha]

LS1012AFRDM has 512MB of DDR.
So update Kernel load address as 0x9600 instead of default
0xa000.

Signed-off-by: Prabhakar Kushwaha 
---
 include/configs/ls1012afrdm.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/include/configs/ls1012afrdm.h b/include/configs/ls1012afrdm.h
index ad81142..64dced2 100644
--- a/include/configs/ls1012afrdm.h
+++ b/include/configs/ls1012afrdm.h
@@ -39,4 +39,20 @@
 #define CONFIG_SYS_MEMTEST_START   0x8000
 #define CONFIG_SYS_MEMTEST_END 0x9fff
 
+#undef CONFIG_EXTRA_ENV_SETTINGS
+#define CONFIG_EXTRA_ENV_SETTINGS  \
+   "initrd_high=0x\0"  \
+   "verify=no\0"   \
+   "hwconfig=fsl_ddr:bank_intlv=auto\0"\
+   "loadaddr=0x8010\0" \
+   "kernel_addr=0x10\0"\
+   "ramdisk_addr=0x80\0"   \
+   "ramdisk_size=0x200\0"  \
+   "fdt_high=0x\0" \
+   "initrd_high=0x\0"  \
+   "kernel_start=0xa0\0"   \
+   "kernel_load=0x9600\0"  \
+   "kernel_size=0x280\0"   \
+   "console=ttyAMA0,38400n8\0"
+
 #endif /* __LS1012ARDB_H__ */
-- 
1.9.1


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

[U-Boot] [PATCH v3 1/3] spi: spi_flash: Dont set quad enable for micron in all cases

[Siva Durga Prasad Paladugu]

Dont set quad enable for micron devices in all cases
Setting the quad enable bit in micron expects all other
commands like register reads on quad lines which may
not be supported by some controllers. Hence, dont
set the quad enable if controller driver sets the
no_all_quad.

Signed-off-by: Siva Durga Prasad Paladugu 
---
Changes for v3:
- None
Changes for v2:
- Newly added in series.
---
 drivers/mtd/spi/spi_flash.c | 13 -
 include/spi.h   |  2 +-
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 64d4e0f..1be3e56 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -926,6 +926,8 @@ static int micron_quad_enable(struct spi_flash *flash)
 
 static int set_quad_mode(struct spi_flash *flash, u8 idcode0)
 {
+   struct spi_slave *spi = flash->spi;
+
switch (idcode0) {
 #ifdef CONFIG_SPI_FLASH_MACRONIX
case SPI_FLASH_CFI_MFR_MACRONIX:
@@ -938,7 +940,16 @@ static int set_quad_mode(struct spi_flash *flash, u8 
idcode0)
 #endif
 #ifdef CONFIG_SPI_FLASH_STMICRO
case SPI_FLASH_CFI_MFR_STMICRO:
-   return micron_quad_enable(flash);
+   /*
+* Set quad enable for micron only
+* if controller supports sending of
+* all commands on quad lines, otherwise
+* dont enable it
+*/
+   if (spi->no_all_quad)
+   return 0;
+   else
+   return micron_quad_enable(flash);
 #endif
default:
printf("SF: Need set QEB func for %02x flash\n", idcode0);
diff --git a/include/spi.h b/include/spi.h
index ca96fa4..e43c864 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -117,7 +117,7 @@ struct spi_slave {
unsigned int max_write_size;
void *memory_map;
u8 option;
-
+   u8 no_all_quad;
u8 flags;
 #define SPI_XFER_BEGIN BIT(0)  /* Assert CS before transfer */
 #define SPI_XFER_END   BIT(1)  /* Deassert CS after transfer */
-- 
2.1.1

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

[U-Boot] [PATCH v3 0/3]spi: Add ZynqMP QSPI driver support

[Siva Durga Prasad Paladugu]

This series adds the qspi driver support for zynqmp
Also sent a patch for not setting quad enable bit
in the series as zynqmp qspi series wont work for
micron devices with out that patch.

Siva Durga Prasad Paladugu (3):
  spi: spi_flash: Dont set quad enable for micron in all cases
  spi: zynqmp_qspi: Add QSPI driver support for ZynqMP
  spi: zynqmp_qspi: Add qspi driver support for ZynqMP boards

 configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig |   4 +
 configs/xilinx_zynqmp_zcu102_defconfig   |   4 +
 configs/xilinx_zynqmp_zcu102_revB_defconfig  |   4 +
 drivers/mtd/spi/spi_flash.c  |  13 +-
 drivers/spi/Kconfig  |   9 +
 drivers/spi/Makefile |   1 +
 drivers/spi/zynqmp_qspi.c| 705 +++
 include/spi.h|   2 +-
 8 files changed, 740 insertions(+), 2 deletions(-)
 create mode 100644 drivers/spi/zynqmp_qspi.c

-- 
2.7.4

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

[U-Boot] [PATCH] rockchip: add basic support for fennec-rk3288 board

[Ziyuan Xu]

Fennec is a RK3288-based development board with 2 USB ports, HDMI,
micro-SD card, audio and WiFi and Gigabit Ethernet. It also includes
on-board 8GB eMMC and 2GB of SDRAM. Expansion connectors provides access
to display pins, I2C, SPI, UART and GPIOs.

Signed-off-by: Ziyuan Xu 
---
This patch is based on u-boot-rockchip/master, also is based on commit
778e95d(Revert "rockchip: Move the MMC setup check earlier").

 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/rk3288-fennec.dts   |  60 
 arch/arm/dts/rk3288-fennec.dtsi  | 421 +++
 arch/arm/mach-rockchip/rk3288-board-spl.c|   3 +-
 arch/arm/mach-rockchip/rk3288/Kconfig|  10 +
 board/rockchip/fennec_rk3288/Kconfig |  15 +
 board/rockchip/fennec_rk3288/MAINTAINERS |   6 +
 board/rockchip/fennec_rk3288/Makefile|   7 +
 board/rockchip/fennec_rk3288/fennec-rk3288.c |  15 +
 configs/fennec-rk3288_defconfig  |  66 +
 doc/README.rockchip  |   3 +-
 include/configs/fennec_rk3288.h  |  26 ++
 12 files changed, 630 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/dts/rk3288-fennec.dts
 create mode 100644 arch/arm/dts/rk3288-fennec.dtsi
 create mode 100644 board/rockchip/fennec_rk3288/Kconfig
 create mode 100644 board/rockchip/fennec_rk3288/MAINTAINERS
 create mode 100644 board/rockchip/fennec_rk3288/Makefile
 create mode 100644 board/rockchip/fennec_rk3288/fennec-rk3288.c
 create mode 100644 configs/fennec-rk3288_defconfig
 create mode 100644 include/configs/fennec_rk3288.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 3f5b2bf..1536ec9 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -32,6 +32,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-jerry.dtb \
rk3288-rock2-square.dtb \
rk3288-evb.dtb \
+   rk3288-fennec.dtb \
rk3399-evb.dtb
 dtb-$(CONFIG_ARCH_MESON) += \
meson-gxbb-odroidc2.dtb
diff --git a/arch/arm/dts/rk3288-fennec.dts b/arch/arm/dts/rk3288-fennec.dts
new file mode 100644
index 000..36e9f3d
--- /dev/null
+++ b/arch/arm/dts/rk3288-fennec.dts
@@ -0,0 +1,60 @@
+/*
+ * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier: GPL-2.0+ X11
+ */
+
+/dts-v1/;
+#include "rk3288-fennec.dtsi"
+
+/ {
+   model = "Rockchip RK3288 Fennec Board";
+   compatible = "rockchip,rk3288-fennec", "rockchip,rk3288";
+
+   chosen {
+   stdout-path = 
+   };
+};
+
+ {
+   rockchip,num-channels = <2>;
+   rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
+   0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
+   0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
+   0x1 0x2 0x2 0x4 0x0 0x0 0xc0 0x4
+   0x8 0x1f4>;
+   rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
+   0x0 0xc3 0x6 0x2>;
+   /* Add a dummy value to cause of-platdata think this is bytes */
+   rockchip,sdram-channel = /bits/ 8 <0x2 0xa 0x3 0x2 0x2 0x0 0xe 0xe 
0xff>;
+   rockchip,sdram-params = <0x20d266a4 0x5b6 2 53300 6 9 0>;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   u-boot,dm-pre-reloc;
+   reg-shift = <2>;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/rk3288-fennec.dtsi b/arch/arm/dts/rk3288-fennec.dtsi
new file mode 100644
index 000..f61252c
--- /dev/null
+++ b/arch/arm/dts/rk3288-fennec.dtsi
@@ -0,0 +1,421 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and 

Re: [U-Boot] [PATCH] common: fit: Allow U-Boot images to be booted

[Mario Six]

On Tue, Jul 19, 2016 at 7:46 AM, Michal Simek  wrote:
> On 18.7.2016 14:05, Mario Six wrote:
>> In certain circumstances it comes in handy to be able to boot into a second
>> U-Boot. But as of now it is not possible to boot a U-Boot binary that is 
>> inside
>> a FIT image, which is problematic for projects that e.g. need to guarantee a
>> unbroken chain of trust from SOC all the way into the OS, since the FIT 
>> signing
>> mechanism cannot be used.
>>
>> This patch adds the capability to load such FIT images.
>>
>> An example its snippet (utilizing signature verification) might look like the
>> following:
>>
>> images {
>>   kernel@1 {
>>   description = "2nd stage U-Boot image";
>>   data = /incbin/("u-boot-dtb.img.gz");
>>   type = "kernel";
>
> Isn't this type weird for u-boot itself?
>
> The rest is good.
>
> Thanks,
> Michal

It is, but the problem is that adding a new type, like "ubootimage," or
something like that, would not be as easy as with the platform-specific image
types (like, e.g. "rkimage"), which only appear in mkimage, because we'd have
to account for this new type in common/bootm.c (essentially, add a lot of
additional "|| images.os.type == IH_TYPE_UBOOT").

I didn't think that it was worth the hassle, and it would have the additional
minor problem that it would effectively be a synonym of "kernel," so you could
declare a regular kernel as having type "ubootimage," and U-Boot would happily
boot it; to prevent that we'd have to do more checks, like, e.g. check the os
value against the type and only boot if the combination makes sense or some
such.

It would be nicer to have a dedicated type, but I think it's too much effort
for such a fringe use case; should it become popular, though, I'll happily add
a new type :-)

Best regards,

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

Re: [U-Boot] [PATCH] common: fit: Allow U-Boot images to be booted

[Wolfgang Denk]

Dear Mario,

In message  
you wrote:
>
> It is, but the problem is that adding a new type, like "ubootimage," or
> something like that, would not be as easy as with the platform-specific image
> types (like, e.g. "rkimage"), which only appear in mkimage, because we'd have
> to account for this new type in common/bootm.c (essentially, add a lot of
> additional "|| images.os.type == IH_TYPE_UBOOT").

There is no need for a new type.  IH_TYPE_FIRMWARE should be used for
this; see also comments around [1]

[1] http://git.denx.de/?p=u-boot.git;a=blob;f=include/image.h#l228

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Obviously, a major malfunction has occurred."
  -- Steve Nesbitt, voice of Mission Control, January 28,
 1986, as the shuttle Challenger exploded within view
 of the grandstands.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] common: fit: Allow U-Boot images to be booted

[Mario Six]

Hi Wolfgang,

On Tue, Jul 19, 2016 at 9:14 AM, Wolfgang Denk  wrote:
> Dear Mario,
>
> In message 
>  you 
> wrote:
>>
>> It is, but the problem is that adding a new type, like "ubootimage," or
>> something like that, would not be as easy as with the platform-specific image
>> types (like, e.g. "rkimage"), which only appear in mkimage, because we'd have
>> to account for this new type in common/bootm.c (essentially, add a lot of
>> additional "|| images.os.type == IH_TYPE_UBOOT").
>
> There is no need for a new type.  IH_TYPE_FIRMWARE should be used for
> this; see also comments around [1]
>
> [1] http://git.denx.de/?p=u-boot.git;a=blob;f=include/image.h#l228
>
> Best regards,
>
> Wolfgang Denk
>

Ah, OK, I thought that IH_TYPE_FIRMWARE should exclusively be used for firmware
updates, like the comment said, not for actually *running* the firmware. In
that case the work is more manageable (there's still some changes needed,
because common/image-fit.c refuses to boot images with firmware type, too).

I'll look into preparing a v2.

Thanks for the help!

Best regards,

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

Re: [U-Boot] [PATCH] wandboard: move environment partition farther from u-boot.img

[Stefano Babic]

On 18/07/2016 15:28, Fabio Estevam wrote:
> Hi Stefano,
> 
> On Sat, Jul 9, 2016 at 9:42 AM, Alexey Brodkin
>  wrote:
>> Recently I started to notice that u-boot.img built for Wandboard
>> by some toolchains becomes so large that it basically overlaps with
>> U-Boot environment area on SD-card.
>>
>> According to
>> http://wiki.wandboard.org/index.php/Boot-process#sdcard_boot_data_layout
>> Wandboard's SD-card layout is as follows:
>> -->8---
>> ==
>> 1. 0x   Reserved For MBR
>> 2. 0x0200   512 Secondary Image Table (optional)
>> 3. 0x0400   1024uBoot Image (Starting From IVT)
>> 4. 0x0006   393216  start of uboot env (size:8k)
>> 5. 0x00062000   end of uboot env
>> 6. 0x0010   1048576 Linux kernel start
>> 7. 0x0076AC00   280 start of partition 1
>> -->8---
>>
>> So for U-Boot we have 383kB (392192 bytes).
>>
>> But in up to date U-Boot for Wandboard we build separately
>>  a) SPL
>>  b) u-boot.img
>>
>> which gives us a bit more detailed SD-card layout:
>> -->8---
>> ==
>> 1. 0x   Reserved For MBR
>> 2. 0x0200   512 Secondary Image Table (optional)
>> 3. 0x0400   1024SPL
>> 4. 0x00011400   70656   u-boot.img
>> 5. 0x0006   393216  start of uboot env (size:8k)
>> 6. 0x00062000   end of uboot env
>> ...
>> -->8---
>>
>> From that layout we may calculate amount of space reserved for
>> u-boot.img. It's just 315kb (322560 bytes).
>>
>> Now if I build U-Boot with Sourcery CodeBench ARM 2014.05 produced
>> u-boot.img is already more than we expected
>> (323840 bytes instead of "< 322560"):
>> -->8---
>> ls -la u-boot.img
>> -rw-rw-r-- 1 user user 323840 Jul  5 07:38 u-boot.img
>> -->8---
>>
>> Funny enough if I rebuild U-Boot with ARM toolchain available in
>> my Fedora 23 distro u-boot.img becomes a little bit smaller:
>> -->8---
>> ls -la u-boot.img
>> -rw-rw-r-- 1 user user 322216 Jul  5 07:39 u-boot.img
>> -->8---
>>
>> What's worse this problem might not affect people most of the time
>> because what happens people would just copy u-boot.img on SD-card and
>> live in happiness with it... well until somebody attempts to save
>> environment in U-Boot with "saveenv" command which will simply
>> overwrite the very end of u-boot.img.
>> That will lead to unusable SD-card until user dd u-boot.img on
>> SD-card again.
>>
>> I may foresee this issue in the future to become more visible once we
>> add more features in U-Boot for Wandboard or just existing code base
>> becomes bulkier and people will consistently get larger u-boot.img
>> files produced.
>>
>> IMHO there's an obvious solution for all that - just move U-Boot's env
>> to the very end of the gap between U-Boot and the first real partition
>> on the SD-card. This patch will follow
>> 8fb9eea5653796 ("mx6sabre_common: Fix U-Boot corruption after 'saveenv'").
>> So env is still not in the very end of the gap (obviously 256kb is way
>> too much for U-Boot's env) but at least we have now the same
>> partitioning for i.MX6 boards.
>>
>> Signed-off-by: Alexey Brodkin 
>> Cc: Fabio Estevam 
>> Cc: Otavio Salvador 
>> Cc: Peter Robinson 
>> Cc: Tom Rini 
>> Cc: Peter Korsgaard 
>> Cc: Wolfgang Denk 
> 
> Any comments about this one? Could it be applied?


No, it is ok, I will apply it.

Regards,
Stefano

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] online wiki page for "fdt" commands full of FDT_ERR_BADMAGIC msgs

[Robert P. J. Day]

On Mon, 18 Jul 2016, Wolfgang Denk wrote:

> Dear Robert,
>
> In message  you 
> wrote:
> >
> >   i'm sure i mentioned this before but the denx wiki page describing
> > the "fdt" command is loaded with pretty much nothing but error
> > messages:
> >
> > http://www.denx.de/wiki/view/DULG/UBootCmdFDT
>
> Obviously the DULGData_%BOARD%.UBootFDTCmd* %INCLUDE files are broken.
> Eventually Heiko might remember where this test case was run;
> alternatively, someone could recreate these manually.
>
> Let's wait for comment from Heiko when he's back from vacation in a
> week.

  i was going to tweak some of those %INCLUDEd snippets to bring them
up to date, but i have no idea whether (or how) one is allowed to do
that. i'm guessing those snippets are totally under the control of the
folks at denx? or no?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[U-Boot] [PATCH v3] dm: clk: Remove simple version of clk_get_by_index/name()

[Michal Simek]

Simple version of clk_get_by_index() added by:
"dm: clk: Add a simple version of clk_get_by_index()"
(sha1: a4b10c088c4f6ef2e2bba33e8cfea369bcbbce44)
is only working for #clock-cells=<1> but not for
any other values. Fixed clocks is using #clock-cells=<0>
which requires full implementation.

Remove simplified versions of clk_get_by_index() and use full version.
Also remove empty clk_get_by_name() which is failing when it is called
which is useless.

Signed-off-by: Michal Simek 
---

Changes in v3:
- Rebase on the top of
  "dm: clk: Add support for of-platdata"
  (sha1:  7423daa60eb30b6613dfc19a51c55de23fd4d703)
  Keep of-platdata part in the tree.

Changes in v2:
- Also use full version of clk_get_by_name()
- Subject change from "Remove simple version of clk_get_by_index()"

---
 drivers/clk/clk-uclass.c | 28 +---
 1 file changed, 1 insertion(+), 27 deletions(-)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index e0f85677e346..4d78e3fcac43 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -21,7 +21,6 @@ static inline struct clk_ops *clk_dev_ops(struct udevice *dev)
 }
 
 #if CONFIG_IS_ENABLED(OF_CONTROL)
-#ifdef CONFIG_SPL_BUILD
 # if CONFIG_IS_ENABLED(OF_PLATDATA)
 int clk_get_by_index_platdata(struct udevice *dev, int index,
  struct phandle_2_cell *cells, struct clk *clk)
@@ -38,31 +37,6 @@ int clk_get_by_index_platdata(struct udevice *dev, int index,
return 0;
 }
 # else
-int clk_get_by_index(struct udevice *dev, int index, struct clk *clk)
-{
-   int ret;
-   u32 cell[2];
-
-   if (index != 0)
-   return -ENOSYS;
-   assert(clk);
-   ret = uclass_get_device(UCLASS_CLK, 0, >dev);
-   if (ret)
-   return ret;
-   ret = fdtdec_get_int_array(gd->fdt_blob, dev->of_offset, "clocks",
-  cell, 2);
-   if (ret)
-   return ret;
-   clk->id = cell[1];
-   return 0;
-}
-# endif /* OF_PLATDATA */
-
-int clk_get_by_name(struct udevice *dev, const char *name, struct clk *clk)
-{
-   return -ENOSYS;
-}
-#else
 static int clk_of_xlate_default(struct clk *clk,
struct fdtdec_phandle_args *args)
 {
@@ -119,6 +93,7 @@ int clk_get_by_index(struct udevice *dev, int index, struct 
clk *clk)
 
return clk_request(dev_clk, clk);
 }
+# endif /* OF_PLATDATA */
 
 int clk_get_by_name(struct udevice *dev, const char *name, struct clk *clk)
 {
@@ -135,7 +110,6 @@ int clk_get_by_name(struct udevice *dev, const char *name, 
struct clk *clk)
 
return clk_get_by_index(dev, index, clk);
 }
-#endif /* CONFIG_SPL_BUILD */
 #endif /* OF_CONTROL */
 
 int clk_request(struct udevice *dev, struct clk *clk)
-- 
1.9.1

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

Re: [U-Boot] [PATCH] common: fit: Allow U-Boot images to be booted

[Mario Six]

On Tue, Jul 19, 2016 at 8:47 AM, Michal Simek  wrote:
> On 19.7.2016 08:45, Mario Six wrote:
>> On Tue, Jul 19, 2016 at 7:46 AM, Michal Simek  
>> wrote:
>>> On 18.7.2016 14:05, Mario Six wrote:
 In certain circumstances it comes in handy to be able to boot into a second
 U-Boot. But as of now it is not possible to boot a U-Boot binary that is 
 inside
 a FIT image, which is problematic for projects that e.g. need to guarantee 
 a
 unbroken chain of trust from SOC all the way into the OS, since the FIT 
 signing
 mechanism cannot be used.

 This patch adds the capability to load such FIT images.

 An example its snippet (utilizing signature verification) might look like 
 the
 following:

 images {
   kernel@1 {
   description = "2nd stage U-Boot image";
   data = /incbin/("u-boot-dtb.img.gz");
   type = "kernel";
>>>
>>> Isn't this type weird for u-boot itself?
>>>
>>> The rest is good.
>>>
>>> Thanks,
>>> Michal
>>
>> It is, but the problem is that adding a new type, like "ubootimage," or
>> something like that, would not be as easy as with the platform-specific image
>> types (like, e.g. "rkimage"), which only appear in mkimage, because we'd have
>> to account for this new type in common/bootm.c (essentially, add a lot of
>> additional "|| images.os.type == IH_TYPE_UBOOT").
>>
>> I didn't think that it was worth the hassle, and it would have the additional
>> minor problem that it would effectively be a synonym of "kernel," so you 
>> could
>> declare a regular kernel as having type "ubootimage," and U-Boot would 
>> happily
>> boot it; to prevent that we'd have to do more checks, like, e.g. check the os
>> value against the type and only boot if the combination makes sense or some
>> such.
>>
>> It would be nicer to have a dedicated type, but I think it's too much effort
>> for such a fringe use case; should it become popular, though, I'll happily 
>> add
>> a new type :-)
>
> Is the type property even required for this case?
>
> Thanks,
> Michal

I just tried to boot one without the type, and apparently it is required:

## Loading kernel from FIT Image at 0200 ...
   Using 'config@1' configuration
   Verifying Hash Integrity ... OK
   Trying 'kernel@1' kernel subimage
 Description:  2nd stage U-Boot image
 Type: Unknown Image
 Compression:  gzip compressed
 Data Start:   0x02d4
 Data Size:206485 Bytes = 201.6 KiB
 Sign algo:sha256,rsa4096:ccdc
 Sign value:   ...
   Verifying Hash Integrity ... sha256,rsa4096:ccdc+ OK
No U-Boot ARM Kernel Image Image
ERROR: can't get kernel image!

That makes sense, since common/bootm.c checks the image type in several places.

Best regards,

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

Re: [U-Boot] [PATCH] common: fit: Allow U-Boot images to be booted

[Michal Simek]

On 19.7.2016 08:45, Mario Six wrote:
> On Tue, Jul 19, 2016 at 7:46 AM, Michal Simek  wrote:
>> On 18.7.2016 14:05, Mario Six wrote:
>>> In certain circumstances it comes in handy to be able to boot into a second
>>> U-Boot. But as of now it is not possible to boot a U-Boot binary that is 
>>> inside
>>> a FIT image, which is problematic for projects that e.g. need to guarantee a
>>> unbroken chain of trust from SOC all the way into the OS, since the FIT 
>>> signing
>>> mechanism cannot be used.
>>>
>>> This patch adds the capability to load such FIT images.
>>>
>>> An example its snippet (utilizing signature verification) might look like 
>>> the
>>> following:
>>>
>>> images {
>>>   kernel@1 {
>>>   description = "2nd stage U-Boot image";
>>>   data = /incbin/("u-boot-dtb.img.gz");
>>>   type = "kernel";
>>
>> Isn't this type weird for u-boot itself?
>>
>> The rest is good.
>>
>> Thanks,
>> Michal
> 
> It is, but the problem is that adding a new type, like "ubootimage," or
> something like that, would not be as easy as with the platform-specific image
> types (like, e.g. "rkimage"), which only appear in mkimage, because we'd have
> to account for this new type in common/bootm.c (essentially, add a lot of
> additional "|| images.os.type == IH_TYPE_UBOOT").
> 
> I didn't think that it was worth the hassle, and it would have the additional
> minor problem that it would effectively be a synonym of "kernel," so you could
> declare a regular kernel as having type "ubootimage," and U-Boot would happily
> boot it; to prevent that we'd have to do more checks, like, e.g. check the os
> value against the type and only boot if the combination makes sense or some
> such.
> 
> It would be nicer to have a dedicated type, but I think it's too much effort
> for such a fringe use case; should it become popular, though, I'll happily add
> a new type :-)

Is the type property even required for this case?

Thanks,
Michal


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

Re: [U-Boot] [PATCH] mmc: dw_mmc: reduce timeout detection cycle

[Jaehoon Chung]

Hi,

On 07/19/2016 04:40 PM, Ziyuan Xu wrote:
> Hi Jaehoon,
> 
> On 2016年07月19日 12:22, Jaehoon Chung wrote:
>> Hi Ziyuan,
>>
>> On 07/19/2016 11:33 AM, Ziyuan Xu wrote:
>>> Hi Jaehoon,
>>>
>>> On 2016年07月19日 10:03, Jaehoon Chung wrote:
 Hi Ziyuan,

 On 07/19/2016 10:38 AM, Ziyuan Xu wrote:
> It's no need to speed 10 seconds to wait the mmc device out from busy
> status. 500 milliseconds enough.
 I agreed that 10 seconds is too big..
 Could you explain more how you get 500ms and feel enough?
>>> Ordinarily, there are 3 types of scenarios that the mmc device was busy:
>>> 1. The mmc interface didn't initialize (eg. gpio  iomux)
>>> The device will be busy status until gpio iomux.
>>>
>>> 2. The last command with data transfer.
>>> The maximum value of data timeout is 0xff cyles(see dwi databook 
>>> Timeout Register), and the clock is up to 52MHZ under high speed mode.
>>> timeout = 0xff * 1/52M = 0.32s
>>>
>>> 3. voltage switch
>>> U-BOOT doesn't support voltage switch.
>>>
>>> In summary, I think 500 milliseconds is enough. What do you think?
>> I think it's not important thing.
>>
>> This is for checking whether card is busy or not before sending command.
>> I think it's not relevant to Timeout register. Just ensure that card is not 
>> busy before sending command.
>> And there is no effect for I/O performance, isn't?
> Yup,  I agree with you.  For scenarios 2, I mean that if the last command 
> with data transfer, we will hit data_busy assertion probably. If the mmc 
> device remains in a busy state more than 500ms, I think it may also be busy 
> state after 10s.
>>
>> But 50ms is not bad. :) It's personal preference.
> BTW, the timeout value is 500ms in kernel.

Yep, it looks good to me. :)
I have tested your patch with Exynos SoCs.

Reviewed-by: Jaehoon Chung 
Tested-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

>>
>> Best Regards,
>> Jaehoon Chung
>>
 Best Regards,
 Jaehoon Chung

> Signed-off-by: Ziyuan Xu 
> ---
>
>drivers/mmc/dw_mmc.c | 2 +-
>1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> index 2cf7bae..790a166 100644
> --- a/drivers/mmc/dw_mmc.c
> +++ b/drivers/mmc/dw_mmc.c
> @@ -195,7 +195,7 @@ static int dwmci_send_cmd(struct mmc *mmc, struct 
> mmc_cmd *cmd,
>ALLOC_CACHE_ALIGN_BUFFER(struct dwmci_idmac, cur_idmac,
> data ? DIV_ROUND_UP(data->blocks, 8) : 0);
>int ret = 0, flags = 0, i;
> -unsigned int timeout = 10;
> +unsigned int timeout = 500;
>u32 retry = 10;
>u32 mask, ctrl;
>ulong start = get_timer(0);
>


>>>
>>>
>>>
>>>
>>
>>
>>
> 
> 
> 
> 
> 

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

Re: [U-Boot] [PATCH] mmc: dw_mmc: reduce timeout detection cycle

[Ziyuan Xu]

Hi Jaehoon,

On 2016年07月19日 15:51, Jaehoon Chung wrote:

Hi,

On 07/19/2016 04:40 PM, Ziyuan Xu wrote:

Hi Jaehoon,

On 2016年07月19日 12:22, Jaehoon Chung wrote:

Hi Ziyuan,

On 07/19/2016 11:33 AM, Ziyuan Xu wrote:

Hi Jaehoon,

On 2016年07月19日 10:03, Jaehoon Chung wrote:

Hi Ziyuan,

On 07/19/2016 10:38 AM, Ziyuan Xu wrote:

It's no need to speed 10 seconds to wait the mmc device out from busy
status. 500 milliseconds enough.

I agreed that 10 seconds is too big..
Could you explain more how you get 500ms and feel enough?

Ordinarily, there are 3 types of scenarios that the mmc device was busy:
1. The mmc interface didn't initialize (eg. gpio  iomux)
The device will be busy status until gpio iomux.

2. The last command with data transfer.
The maximum value of data timeout is 0xff cyles(see dwi databook Timeout 
Register), and the clock is up to 52MHZ under high speed mode.
timeout = 0xff * 1/52M = 0.32s

3. voltage switch
U-BOOT doesn't support voltage switch.

In summary, I think 500 milliseconds is enough. What do you think?

I think it's not important thing.

This is for checking whether card is busy or not before sending command.
I think it's not relevant to Timeout register. Just ensure that card is not 
busy before sending command.
And there is no effect for I/O performance, isn't?

Yup,  I agree with you.  For scenarios 2, I mean that if the last command with 
data transfer, we will hit data_busy assertion probably. If the mmc device 
remains in a busy state more than 500ms, I think it may also be busy state 
after 10s.

But 50ms is not bad. :) It's personal preference.

BTW, the timeout value is 500ms in kernel.

Yep, it looks good to me. :)
I have tested your patch with Exynos SoCs.

Reviewed-by: Jaehoon Chung 
Tested-by: Jaehoon Chung 

Thanks for your test and review!


Best Regards,
Jaehoon Chung


Best Regards,
Jaehoon Chung


Best Regards,
Jaehoon Chung


Signed-off-by: Ziyuan Xu 
---

drivers/mmc/dw_mmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 2cf7bae..790a166 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -195,7 +195,7 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd 
*cmd,
ALLOC_CACHE_ALIGN_BUFFER(struct dwmci_idmac, cur_idmac,
 data ? DIV_ROUND_UP(data->blocks, 8) : 0);
int ret = 0, flags = 0, i;
-unsigned int timeout = 10;
+unsigned int timeout = 500;
u32 retry = 10;
u32 mask, ctrl;
ulong start = get_timer(0);






















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

[U-Boot] [PATCH 1/2] tools: Fix return code of fit_image_process_sig()

[Mario Six]

When signing images, we repeatedly call fit_add_file_data() with
successively increasing size values to include the keys in the DTB.

Unfortunately, if large keys are used (such as 4096 bit RSA keys), this
process fails sometimes, and mkimage needs to be called repeatedly to
integrate the keys into the DTB.

This is because fit_add_file_data actually returns the wrong error
code, and the loop terminates prematurely, instead of trying again with
a larger size value.

This patch corrects the return value and also removes a error message,
which is misleading, since we actually allow the function to fail. A
(hopefully helpful) comment is also added to explain the lack of error
message.

This is probably related to 1152a05 ("tools: Correct error handling in
fit_image_process_hash()") and the corresponding error reported here:

https://www.mail-archive.com/u-boot@lists.denx.de/msg217417.html

Signed-off-by: Mario Six 
---
 tools/image-host.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/tools/image-host.c b/tools/image-host.c
index 3e14fdc..399ec94 100644
--- a/tools/image-host.c
+++ b/tools/image-host.c
@@ -238,12 +238,13 @@ static int fit_image_process_sig(const char *keydir, void 
*keydest,
/* Get keyname again, as FDT has changed and invalidated our pointer */
info.keyname = fdt_getprop(fit, noffset, "key-name-hint", NULL);

-   /* Write the public key into the supplied FDT file */
-   if (keydest && info.algo->add_verify_data(, keydest)) {
-   printf("Failed to add verification data for '%s' signature node 
in '%s' image node\n",
-  node_name, image_name);
-   return -1;
-   }
+   ret = info.algo->add_verify_data(, keydest);
+
+   /* Write the public key into the supplied FDT file; this might fail
+* several times, since we try signing with successively increasing
+* size values */
+   if (keydest && ret)
+   return ret;

return 0;
 }
--
2.9.0

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

[U-Boot] [PATCH 0/2] Fix signing problems with large keys

[Mario Six]

This patch series fixes a problem that occurs when signing FIT images with
large keys (e.g. RSA with 4096 bits).

Signing sometimes fails because of unexpected return values from
fit_add_file_data() and the functions called by it.

Some error messages are also removed, since we tolerate failure of the
corresponding functions.

This is probably related to 1152a05 ("tools: Correct error handling in
fit_image_process_hash()") and the corresponding error reported here:

https://www.mail-archive.com/u-boot@lists.denx.de/msg217417.html

Mario Six (2):
  tools: Fix return code of fit_image_process_sig()
  rsa: Fix return value and masked error

 lib/rsa/rsa-sign.c | 10 +-
 tools/image-host.c | 13 +++--
 2 files changed, 12 insertions(+), 11 deletions(-)

--
2.9.0

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

[U-Boot] [PATCH v2] mmc-uclass: correct the device number

[Kever Yang]

Not like the mmc-legacy which the devnum starts from 1, it starts from 0
in mmc-uclass, so the device number should be (devnum + 1) in get_mmc_num().

Signed-off-by: Kever Yang 
---

Changes in v2:
- add comment for get_mmc_num() in mmc.h
- update mmc_get_next_devnum()

 drivers/mmc/mmc-uclass.c | 4 ++--
 include/mmc.h| 6 ++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
index 38ced41..d0ca91b 100644
--- a/drivers/mmc/mmc-uclass.c
+++ b/drivers/mmc/mmc-uclass.c
@@ -111,7 +111,7 @@ struct mmc *find_mmc_device(int dev_num)
 
 int get_mmc_num(void)
 {
-   return max(blk_find_max_devnum(IF_TYPE_MMC), 0);
+   return max((blk_find_max_devnum(IF_TYPE_MMC) + 1), 0);
 }
 
 int mmc_get_next_devnum(void)
@@ -122,7 +122,7 @@ int mmc_get_next_devnum(void)
if (ret < 0)
return ret;
 
-   return ret + 1;
+   return ret;
 }
 
 struct blk_desc *mmc_get_blk_desc(struct mmc *mmc)
diff --git a/include/mmc.h b/include/mmc.h
index 8f309f1..4288e59 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -503,6 +503,12 @@ void mmc_set_clock(struct mmc *mmc, uint clock);
 struct mmc *find_mmc_device(int dev_num);
 int mmc_set_dev(int dev_num);
 void print_mmc_devices(char separator);
+
+/**
+ * get_mmc_num() - get the total MMC device number
+ *
+ * @return number of MMC device
+ */
 int get_mmc_num(void);
 int mmc_hwpart_config(struct mmc *mmc, const struct mmc_hwpart_conf *conf,
  enum mmc_hwpart_conf_mode mode);
-- 
1.9.1


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

Re: [U-Boot] [PATCH v2] dm: clk: Remove simple version of clk_get_by_index/name()

[Michal Simek]

Hi Simon,

On 18.7.2016 13:20, Simon Glass wrote:
> Hi Michal,
> 
> On 18 July 2016 at 00:57, Michal Simek  wrote:
>> Hi Simon,
>>
>> On 15.7.2016 17:43, Stephen Warren wrote:
>>> On 07/15/2016 01:02 AM, Michal Simek wrote:
 Simple version of clk_get_by_index() added by:
 "dm: clk: Add a simple version of clk_get_by_index()"
 (sha1: a4b10c088c4f6ef2e2bba33e8cfea369bcbbce44)
 is only working for #clock-cells=<1> but not for
 any other values. Fixed clocks is using #clock-cells=<0>
 which requires full implementation.

 Remove simplified versions of clk_get_by_index() and use full version.
 Also remove empty clk_get_by_name() which is failing when it is called
 which is useless.
>>>
>>> This seems reasonable to me,
>>> Acked-by: Stephen Warren 
>>
>> I see your patch
>> "dm: clk: Add support for of-platdata"
>> (sha1:  7423daa60eb30b6613dfc19a51c55de23fd4d703)
>> has been merged to the tree and it is in conflict with this patch.
>> Is there any problem about using full version and just remove the whole
>> SPL part?
> 
> Yes I was going to mention that. Unfortunately we need the of-platdata
> version since in that case there is no device tree (it has been
> converted to a C struct).

v3 sent which address this.

Thanks,
Michal

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

Re: [U-Boot] [PATCH v1 6/6] armv8: layerscape: Convert to use common MMU framework

[Alexander Graf]

On 25.06.16 01:46, York Sun wrote:
> Drop platform code to create static MMU tables. Use common framework
> to create MMU tables on the run. Tested on LS2080ARDB with secure and
> non-secure ram scenarios.
> 
> Signed-off-by: York Sun 
> 
>  Alison Wang ,
>  Prabhakar Kushwaha 

What is this? :)


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

Re: [U-Boot] [PATCH] mmc: dw_mmc: reduce timeout detection cycle

[Ziyuan Xu]

Hi Jaehoon,

On 2016年07月19日 12:22, Jaehoon Chung wrote:

Hi Ziyuan,

On 07/19/2016 11:33 AM, Ziyuan Xu wrote:

Hi Jaehoon,

On 2016年07月19日 10:03, Jaehoon Chung wrote:

Hi Ziyuan,

On 07/19/2016 10:38 AM, Ziyuan Xu wrote:

It's no need to speed 10 seconds to wait the mmc device out from busy
status. 500 milliseconds enough.

I agreed that 10 seconds is too big..
Could you explain more how you get 500ms and feel enough?

Ordinarily, there are 3 types of scenarios that the mmc device was busy:
1. The mmc interface didn't initialize (eg. gpio  iomux)
The device will be busy status until gpio iomux.

2. The last command with data transfer.
The maximum value of data timeout is 0xff cyles(see dwi databook Timeout 
Register), and the clock is up to 52MHZ under high speed mode.
timeout = 0xff * 1/52M = 0.32s

3. voltage switch
U-BOOT doesn't support voltage switch.

In summary, I think 500 milliseconds is enough. What do you think?

I think it's not important thing.

This is for checking whether card is busy or not before sending command.
I think it's not relevant to Timeout register. Just ensure that card is not 
busy before sending command.
And there is no effect for I/O performance, isn't?
Yup,  I agree with you.  For scenarios 2, I mean that if the last 
command with data transfer, we will hit data_busy assertion probably. If 
the mmc device remains in a busy state more than 500ms, I think it may 
also be busy state after 10s.


But 50ms is not bad. :) It's personal preference.

BTW, the timeout value is 500ms in kernel.


Best Regards,
Jaehoon Chung


Best Regards,
Jaehoon Chung


Signed-off-by: Ziyuan Xu 
---

   drivers/mmc/dw_mmc.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 2cf7bae..790a166 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -195,7 +195,7 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd 
*cmd,
   ALLOC_CACHE_ALIGN_BUFFER(struct dwmci_idmac, cur_idmac,
data ? DIV_ROUND_UP(data->blocks, 8) : 0);
   int ret = 0, flags = 0, i;
-unsigned int timeout = 10;
+unsigned int timeout = 500;
   u32 retry = 10;
   u32 mask, ctrl;
   ulong start = get_timer(0);
















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

[U-Boot] what is the *recommended* split between defconfig file and header file?

[Robert P. J. Day]

  kind of a style question but what is the preferred way to define a
board in the sense of what belongs in the defconfig file and what
belongs in the header file?

  example: i'm now messing with a MPC8315ERDB, and here's
configs/MPC8315ERDB_defconfig in its entirety:

CONFIG_PPC=y
CONFIG_MPC83xx=y
CONFIG_TARGET_MPC8315ERDB=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_OF_STDOUT_VIA_ALIAS=y
CONFIG_BOOTDELAY=6
CONFIG_HUSH_PARSER=y
CONFIG_CMD_I2C=y
CONFIG_CMD_USB=y
# CONFIG_CMD_SETEXPR is not set
CONFIG_CMD_MII=y
CONFIG_CMD_PING=y
CONFIG_CMD_EXT2=y
CONFIG_SYS_NS16550=y
CONFIG_OF_LIBFDT=y

  based on my current understanding, the absolute minimum i would need
in this defconfig file is just the first three lines:

CONFIG_PPC=y
CONFIG_MPC83xx=y
CONFIG_TARGET_MPC8315ERDB=y

which is sufficient to get me to the corresponding header file
include/configs/MPC8315ERDB.h, at which point we're good.

  but is there a recommended style for what belongs in the defconfig
file, and what belongs in the header file? or is that all just
personal preference?

  i do appreciate that if there is a family of closely-related target
boards, the header file can further include a "common" header file to
avoid duplication but, beyond that, any style rules?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [U-Boot] u-boot: x86: interrupt mapping

[Jian Luo]

Hi Bin,

On 19.07.2016 10:10, Bin Meng wrote:

Hi Jian,

On Tue, Jul 19, 2016 at 4:03 PM, Jian Luo  wrote:

Hallo Christian,


On 19.07.2016 08:02, Christian Gmeiner wrote:

Hi Bin

For the moment I have no answer to this question. I need to dive into
the vxworks code, which
is not what I like to do now (but needs to be done)-

Yes, please do track it down. The interrupt line register configured
by U-Boot should be enough for VxWorks to function under PIC mode.

I have an other (wired) question you may could help out.

http://www.mouser.com/pdfdocs/Intel_Platform_Controller_Hub_EG20T_datasheet.pdf
(page 124)

On my development board the uart_clk is connected to a oscillator and
everything works as expected.
But on the production devices the uart_clk is not connected and fsp
hangs with post code 0x2e.

I am not sure about the meaning of post code 0x2e. Jian has some
working experience on Atom E6xx with U-Boot. Adding him.

0x2e == POST_PRE_MRC (arch/x86/include/asm/post.h)

Now I would like to change the initial mux settings to use usb_48mhz
but I am quite sure that I need
to have the pci bus and its devices initialised already in order to
change the CLKCFG register. Do you
think there is an other way of accessing this register like fixed
memory address etc?

Which register do you want to program for this uart_clk? If it's on
the PCI configuration space, you can use PCI config APIs to program.

There a handful of registers I would need to program but all of them are
accessible via pic config space. E.g CLKCFG:

Size: 32-bit Default: 2C00 Power Well: Core
Access PCI Configuration B:D:F D0:F0 Offset Start: Offset End: 500h 503h
 Memory Mapped I/O BAR: PKTHubCTLBASE Offset: 500h


As I need to program those registers before fsp_init I must setup the pci
bus by myself, change the register values and call fsb_init routine.
Correct?

My board had this problem too. I however toke a different approach

Great, I got you :)


by patching the original FSP. The waiting for Topcliff UART ready is

How did you patch the original FSP? Did you reverse engineering the FSP?

Only at where it hangs. With the help of an ECM-XDP3 Debugger.
Then I made a wild guess that in all compressed PE32 sections have the 
same problem.

Yepp, dirty hack.



completely
bypassed in all UEFI blobs. You can use UEFITool [1] to extract blobs in
the attached FSP for comparison.

greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner

[1] https://github.com/LongSoft/UEFITool


Regards,
Bin


Best regards,

*Jian Luo
DC-IA/EAH2*

Tel.  +49(9352)18-4266

*Be**QIK
*

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

[U-Boot] [PATCH 2/2] rsa: Fix return value and masked error

[Mario Six]

When signing images, we repeatedly call fit_add_file_data() with
successively increasing size values to include the keys in the DTB.

Unfortunately, if large keys are used (such as 4096 bit RSA keys), this
process fails sometimes, and mkimage needs to be called repeatedly to
integrate the keys into the DTB.

This is because fit_add_file_data actually returns the wrong error
code, and the loop terminates prematurely, instead of trying again with
a larger size value.

This patch corrects the return value by fixing the return value of
fdt_add_bignum, fixes a case where an error is masked by a unconditional
setting of a return value variable, and also removes a error message,
which is misleading, since we actually allow the function to fail. A
(hopefully helpful) comment is also added to explain the lack of error
message.

This is probably related to 1152a05 ("tools: Correct error handling in
fit_image_process_hash()") and the corresponding error reported here:

https://www.mail-archive.com/u-boot@lists.denx.de/msg217417.html

Signed-off-by: Mario Six 
---
 lib/rsa/rsa-sign.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
index 5d9716f..d4a1a5e 100644
--- a/lib/rsa/rsa-sign.c
+++ b/lib/rsa/rsa-sign.c
@@ -420,11 +420,11 @@ static int fdt_add_bignum(void *blob, int noffset, const 
char *prop_name,
BN_rshift(num, num, 32); /*  N = N/B */
}

+   /* We try signing with successively increasing size values, so this
+* might fail several times */
ret = fdt_setprop(blob, noffset, prop_name, buf, size);
-   if (ret) {
-   fprintf(stderr, "Failed to write public key to FIT\n");
-   return -ENOSPC;
-   }
+   if (ret)
+   return -FDT_ERR_NOSPACE;
free(buf);
BN_free(tmp);
BN_free(big2);
@@ -508,7 +508,7 @@ int rsa_add_verify_data(struct image_sign_info *info, void 
*keydest)
ret = fdt_setprop_string(keydest, node, FIT_ALGO_PROP,
 info->algo->name);
}
-   if (info->require_keys) {
+   if (!ret && info->require_keys) {
ret = fdt_setprop_string(keydest, node, "required",
 info->require_keys);
}
--
2.9.0

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

[U-Boot] [PATCH] spl: fit: Fix the number of bytes read in raw mode

[Lokesh Vutla]

In raw mode a full sector is to be read even if image covers part of
a sector. Number of sectors are calculated as ROUND_UP(size)/sec_size by FIT
framework. This calculation assumes that image is at the 0th offset of a sector,
which is not true always in FIT case. So, include the image offset while
calculating number of sectors.

Signed-off-by: Lokesh Vutla 
---
 common/spl/spl_fit.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 069e94d..be86072 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -115,8 +115,10 @@ static int get_aligned_image_overhead(struct spl_load_info 
*info, int offset)
 static int get_aligned_image_size(struct spl_load_info *info, int data_size,
  int offset)
 {
+   data_size = data_size + get_aligned_image_overhead(info, offset);
+
if (info->filename)
-   return data_size + get_aligned_image_overhead(info, offset);
+   return data_size;
 
return (data_size + info->bl_len - 1) / info->bl_len;
 }
-- 
2.9.2

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

Re: [U-Boot] [PATCH] spi: zynq_spi: Fix infinite looping while xfer

[Lad, Prabhakar]

On Thu, Jun 23, 2016 at 2:58 PM, Lad, Prabhakar
 wrote:
> During spi transfer, for example:
> sspi 1:1.0 8 ff
>
> the rx_len values will  be:
> rx_len = 0
> rx_len = 4294967295
>
> This caused a busy looping during xfer, this patch fixes it
> by adding a check while reading the rx fifo
>
Gentle ping..

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

[U-Boot] [PATCH v3 3/3] spi: zynqmp_qspi: Add qspi driver support for ZynqMP boards

[Siva Durga Prasad Paladugu]

Added the qspi driver support for respective ZynqMP boards
ZCU102, ZCU102 RevB and DC1 boards.

Signed-off-by: Siva Durga Prasad Paladugu 
---
Changes for v3:
- None
Changes for v2:
- None
---
 configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 4 
 configs/xilinx_zynqmp_zcu102_defconfig   | 4 
 configs/xilinx_zynqmp_zcu102_revB_defconfig  | 4 
 3 files changed, 12 insertions(+)

diff --git a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
index 91af8ce..e3942be 100644
--- a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
@@ -4,6 +4,9 @@ CONFIG_ARCH_ZYNQMP=y
 CONFIG_SYS_MALLOC_F_LEN=0x8000
 CONFIG_DM_I2C=y
 CONFIG_DM_GPIO=y
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_ZYNQMP_QSPI=y
 CONFIG_ZYNQMP_USB=y
 CONFIG_SYS_TEXT_BASE=0x800
 CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zc1751-xm015-dc1"
@@ -32,6 +35,7 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_SF=y
 CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_CLK=y
diff --git a/configs/xilinx_zynqmp_zcu102_defconfig 
b/configs/xilinx_zynqmp_zcu102_defconfig
index d7eb8c2..d3cc038 100644
--- a/configs/xilinx_zynqmp_zcu102_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_defconfig
@@ -3,6 +3,9 @@ CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp_zcu102"
 CONFIG_ARCH_ZYNQMP=y
 CONFIG_SYS_MALLOC_F_LEN=0x8000
 CONFIG_DM_GPIO=y
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_ZYNQMP_QSPI=y
 CONFIG_ZYNQMP_USB=y
 CONFIG_SYS_TEXT_BASE=0x800
 CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zcu102"
@@ -31,6 +34,7 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_SF=y
 CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_CLK=y
diff --git a/configs/xilinx_zynqmp_zcu102_revB_defconfig 
b/configs/xilinx_zynqmp_zcu102_revB_defconfig
index 80a59ef..2df9779 100644
--- a/configs/xilinx_zynqmp_zcu102_revB_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_revB_defconfig
@@ -3,6 +3,9 @@ CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp_zcu102"
 CONFIG_ARCH_ZYNQMP=y
 CONFIG_SYS_MALLOC_F_LEN=0x8000
 CONFIG_DM_GPIO=y
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_ZYNQMP_QSPI=y
 CONFIG_ZYNQMP_USB=y
 CONFIG_SYS_TEXT_BASE=0x800
 CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zcu102-revB"
@@ -31,6 +34,7 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_SF=y
 CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_CLK=y
-- 
2.1.1

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

Re: [U-Boot] [PATCH] mmc-uclass: correct the device number

[Kever Yang]

Hi Simon,

On 07/18/2016 07:55 PM, Simon Glass wrote:

Hi Kever,

On 18 July 2016 at 03:52, Kever Yang  wrote:

The devnum in is start from 0, so the device number should be
(devnum+1).

Signed-off-by: Kever Yang 
---

  drivers/mmc/mmc-uclass.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
index 38ced41..7c40d24 100644
--- a/drivers/mmc/mmc-uclass.c
+++ b/drivers/mmc/mmc-uclass.c
@@ -111,7 +111,7 @@ struct mmc *find_mmc_device(int dev_num)

  int get_mmc_num(void)
  {
-   return max(blk_find_max_devnum(IF_TYPE_MMC), 0);
+   return max((blk_find_max_devnum(IF_TYPE_MMC)+1), 0);

Please add spaces around the +

Also can you add a comment to the function in mmc.h describing what it
should do? From what you are saying it should return the number of mmc
devices.

Also you will need to adjust mmc_get_next_devnum() which uses this function.


Sure, checkpatch script did not give me an error report for the format :(

For mmc_get_next_devnum(), not like legacy mmc, no one use it in mmc-uclass,
are we still need this function? blk_find_max_devnum() is used in 
blk_create_device.


Thanks,
- Kever

  }

  int mmc_get_next_devnum(void)
--
1.9.1



Regards,
Simon






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

Re: [U-Boot] u-boot: x86: interrupt mapping

[Christian Gmeiner]

Hi Bin

>>
>> For the moment I have no answer to this question. I need to dive into
>> the vxworks code, which
>> is not what I like to do now (but needs to be done)-
>>
>
> Yes, please do track it down. The interrupt line register configured
> by U-Boot should be enough for VxWorks to function under PIC mode.
>
>> I have an other (wired) question you may could help out.
>>
>> http://www.mouser.com/pdfdocs/Intel_Platform_Controller_Hub_EG20T_datasheet.pdf
>> (page 124)
>>
>> On my development board the uart_clk is connected to a oscillator and
>> everything works as expected.
>> But on the production devices the uart_clk is not connected and fsp
>> hangs with post code 0x2e.
>>
>
> I am not sure about the meaning of post code 0x2e. Jian has some
> working experience on Atom E6xx with U-Boot. Adding him.
>

0x2e == POST_PRE_MRC (arch/x86/include/asm/post.h)

>> Now I would like to change the initial mux settings to use usb_48mhz
>> but I am quite sure that I need
>> to have the pci bus and its devices initialised already in order to
>> change the CLKCFG register. Do you
>> think there is an other way of accessing this register like fixed
>> memory address etc?
>>
>
> Which register do you want to program for this uart_clk? If it's on
> the PCI configuration space, you can use PCI config APIs to program.
>

There a handful of registers I would need to program but all of them are
accessible via pic config space. E.g CLKCFG:

Size: 32-bit Default: 2C00 Power Well: Core
Access PCI Configuration B:D:F D0:F0 Offset Start: Offset End: 500h 503h
Memory Mapped I/O BAR: PKTHubCTLBASE Offset: 500h


As I need to program those registers before fsp_init I must setup the pci
bus by myself, change the register values and call fsb_init routine. Correct?

greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] fs/fat/fatwrite: Local variable as buffer to store dir_slot entries

[Tien Fong Chee]

On Thu, 2016-07-14 at 15:00 -0600, Stephen Warren wrote:
> On 07/13/2016 03:01 AM, Tien Fong Chee wrote:
> > fill_dir_slot use get_contents_vfatname_block as a temporary buffer
> > for
> > constructing a list of dir_slot entries. To save the memory and
> > providing
> > correct type of memory for above usage, a local buffer with
> > accurate size
> > declaration is introduced.
> >
> > The local array size 640 is used because for long file name entry,
> > each entry use 32 bytes, one entry can store up to 13 characters.
> > The maximum number of entry possible is 20. So, total size is
> > 32*20=640bytes.
>
> I'm fairly sure this series is correct[1], although the FAT write
> code
> is a little hard to follow.
>
> [1] except in the face of disk read errors or corrupted data while
> parsing long filename entries, but the code already looks broken in
> the
> case of disk errors, and the corrupted data case probably isn't much
> worse now.
>
> > diff --git a/include/fat.h b/include/fat.h
>
> > +/* Maximum number of entry for long file name according to spec */
> > +#define MAX_LFN_SLOT   20
> > +
> >
> >   /* Filesystem identifiers */
> >   #define FAT12_SIGN"FAT12   "
>
> Why 2 blank lines there?
Good catch!!
>
> Also, I'd suggest simply deleting get_contents_vfatname_block and
> renaming all references to it to use get_dentfromdir_block instead.
> That
> way, anyone reading the code in the future won't assume the two
> "block"
> variables refer to different memory, when in fact they share storage.
> Related, there's little point keeping the now-redundant memcpy() call
> at
> the end of get_long_file_name():
>
> > memcpy(get_dentfromdir_block,
> > get_contents_vfatname_block,
> > mydata->clust_size * mydata->sect_size);
>
Yeah, i agree with you that we should renaming all to single name to
avoid any confusion. I would remove those redundant codes.

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

Re: [U-Boot] [PATCH] common: fit: Allow U-Boot images to be booted

[Michal Simek]

On 18.7.2016 14:05, Mario Six wrote:
> In certain circumstances it comes in handy to be able to boot into a second
> U-Boot. But as of now it is not possible to boot a U-Boot binary that is 
> inside
> a FIT image, which is problematic for projects that e.g. need to guarantee a
> unbroken chain of trust from SOC all the way into the OS, since the FIT 
> signing
> mechanism cannot be used.
> 
> This patch adds the capability to load such FIT images.
> 
> An example its snippet (utilizing signature verification) might look like the
> following:
> 
> images {
>   kernel@1 {
>   description = "2nd stage U-Boot image";
>   data = /incbin/("u-boot-dtb.img.gz");
>   type = "kernel";

Isn't this type weird for u-boot itself?

The rest is good.

Thanks,
Michal

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

[U-Boot] [PATCH v2 5/9] defconfig: zc706: Add dual modes support for zc706

[Siva Durga Prasad Paladugu]

Add QSPI dual mode support for zc706 by enabling
the config option SF_DUAL_FLASH

Signed-off-by: Siva Durga Prasad Paladugu 
---
 configs/zynq_zc706_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/zynq_zc706_defconfig b/configs/zynq_zc706_defconfig
index 8b24d90..e65d5c5 100644
--- a/configs/zynq_zc706_defconfig
+++ b/configs/zynq_zc706_defconfig
@@ -34,6 +34,7 @@ CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_ZYNQ_SDHCI=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
+CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=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 9/9] spi: spi_flash: Set Quad enable bit of upper flash

[Siva Durga Prasad Paladugu]

Set quad enable for upper flash incase of
Dual stacked mode.

Signed-off-by: Siva Durga Prasad Paladugu 
---
 drivers/mtd/spi/spi_flash.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 293b47b..5a152db 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -1237,6 +1237,17 @@ int spi_flash_scan(struct spi_flash *flash)
debug("SF: Fail to set QEB for %02x\n", idcode[0]);
return -EINVAL;
}
+#ifdef CONFIG_SF_DUAL_FLASH
+   if (flash->dual_flash & SF_DUAL_STACKED_FLASH) {
+   flash->spi->flags |= SPI_XFER_U_PAGE;
+   if (set_quad_mode(flash, idcode[0])) {
+   debug("SF: Fail to set QEB Upper Flash %02x\n",
+ idcode[0]);
+   return 0;
+   }
+   flash->spi->flags &= ~SPI_XFER_U_PAGE;
+   }
+#endif
}
 
/* Read dummy_byte: dummy byte is determined based on the
-- 
2.7.4

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

[U-Boot] [PATCH v2 8/9] spi: spi_flash: Fix Bank selection calculation for Dual parallel

[Siva Durga Prasad Paladugu]

In Dual parallel connection the bank selection calculation
should be performed using offset and not the calculated address

Signed-off-by: Siva Durga Prasad Paladugu 
---
 drivers/mtd/spi/spi_flash.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 404533b..293b47b 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -340,7 +340,7 @@ int spi_flash_write_common(struct spi_flash *flash, const 
u8 *cmd,
 
 int spi_flash_cmd_erase_ops(struct spi_flash *flash, u32 offset, size_t len)
 {
-   u32 erase_size, erase_addr;
+   u32 erase_size, erase_addr, bank_addr;
u8 cmd[SPI_FLASH_CMD_LEN];
int ret = -1;
 
@@ -361,13 +361,16 @@ int spi_flash_cmd_erase_ops(struct spi_flash *flash, u32 
offset, size_t len)
cmd[0] = flash->erase_cmd;
while (len) {
erase_addr = offset;
+   bank_addr = offset;
 
 #ifdef CONFIG_SF_DUAL_FLASH
if (flash->dual_flash > SF_SINGLE_FLASH)
spi_flash_dual(flash, _addr);
+   if (flash->dual_flash == SF_DUAL_STACKED_FLASH)
+   bank_addr = erase_addr;
 #endif
 #ifdef CONFIG_SPI_FLASH_BAR
-   ret = spi_flash_write_bar(flash, erase_addr);
+   ret = spi_flash_write_bar(flash, bank_addr);
if (ret < 0)
return ret;
 #endif
@@ -394,7 +397,7 @@ int spi_flash_cmd_write_ops(struct spi_flash *flash, u32 
offset,
 {
struct spi_slave *spi = flash->spi;
unsigned long byte_addr, page_size;
-   u32 write_addr;
+   u32 write_addr, bank_addr;
size_t chunk_len, actual;
u8 cmd[SPI_FLASH_CMD_LEN];
int ret = -1;
@@ -412,13 +415,16 @@ int spi_flash_cmd_write_ops(struct spi_flash *flash, u32 
offset,
cmd[0] = flash->write_cmd;
for (actual = 0; actual < len; actual += chunk_len) {
write_addr = offset;
+   bank_addr = offset;
 
 #ifdef CONFIG_SF_DUAL_FLASH
if (flash->dual_flash > SF_SINGLE_FLASH)
spi_flash_dual(flash, _addr);
+   if (flash->dual_flash == SF_DUAL_STACKED_FLASH)
+   bank_addr = write_addr;
 #endif
 #ifdef CONFIG_SPI_FLASH_BAR
-   ret = spi_flash_write_bar(flash, write_addr);
+   ret = spi_flash_write_bar(flash, bank_addr);
if (ret < 0)
return ret;
 #endif
@@ -488,7 +494,7 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 
offset,
 {
struct spi_slave *spi = flash->spi;
u8 *cmd, cmdsz;
-   u32 remain_len, read_len, read_addr;
+   u32 remain_len, read_len, read_addr, bank_addr;
int bank_sel = 0;
int ret = -1;
 
@@ -516,13 +522,16 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 
offset,
cmd[0] = flash->read_cmd;
while (len) {
read_addr = offset;
+   bank_addr = offset;
 
 #ifdef CONFIG_SF_DUAL_FLASH
if (flash->dual_flash > SF_SINGLE_FLASH)
spi_flash_dual(flash, _addr);
+   if (flash->dual_flash == SF_DUAL_STACKED_FLASH)
+   bank_addr = read_addr;
 #endif
 #ifdef CONFIG_SPI_FLASH_BAR
-   ret = spi_flash_write_bar(flash, read_addr);
+   ret = spi_flash_write_bar(flash, bank_addr);
if (ret < 0)
return ret;
bank_sel = flash->bank_curr;
-- 
2.7.4

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

[U-Boot] [PATCH v2 6/9] spi: spi_flash: Correct flash size calculation

[Siva Durga Prasad Paladugu]

Dont need to double the size while calculating
the flash size as the sector size calculation already
takes care of doubling the size incase of dual modes

Signed-off-by: Siva Durga Prasad Paladugu 
---
 drivers/mtd/spi/spi_flash.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 1be3e56..ef9b877 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -1167,7 +1167,7 @@ int spi_flash_scan(struct spi_flash *flash)
}
flash->page_size <<= flash->shift;
flash->sector_size = params->sector_size << flash->shift;
-   flash->size = flash->sector_size * params->nr_sectors << flash->shift;
+   flash->size = flash->sector_size * params->nr_sectors;
 #ifdef CONFIG_SF_DUAL_FLASH
if (flash->dual_flash & SF_DUAL_STACKED_FLASH)
flash->size <<= 1;
-- 
2.7.4

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

[U-Boot] [PATCH v2 7/9] spi: spi_flash: Correct bank select incase of dual stacked

[Siva Durga Prasad Paladugu]

Correct the bank selection issue incase of Dual stacked mode.
This fix corrects the wrong bank selection if banks are accessed
as below.
1. Access the bank2 in upper flash.
2. Access the bank1 in lower flash.
3. Now access the bank1 in upper flash.
But here in the step3, the present code was accessing the bank2 in
upper flash not bank1. This was because the code thinks the bank1
was already selected as part of step2 but it was not taking care of
upper or lower flash.

Signed-off-by: Siva Durga Prasad Paladugu 
---
 drivers/mtd/spi/spi_flash.c | 20 +---
 include/spi_flash.h |  1 +
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index ef9b877..404533b 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -146,12 +146,26 @@ static int write_evcr(struct spi_flash *flash, u8 evcr)
 #ifdef CONFIG_SPI_FLASH_BAR
 static int spi_flash_write_bar(struct spi_flash *flash, u32 offset)
 {
-   u8 cmd, bank_sel;
+   u8 cmd, bank_sel, upage_curr;
int ret;
 
bank_sel = offset / (SPI_FLASH_16MB_BOUN << flash->shift);
-   if (bank_sel == flash->bank_curr)
-   goto bar_end;
+
+   upage_curr = flash->spi->flags & SPI_XFER_U_PAGE;
+
+   if (flash->dual_flash != SF_DUAL_STACKED_FLASH) {
+   if (flash->bank_curr == bank_sel) {
+   debug("SF: not require to enable bank%d\n", bank_sel);
+   goto bar_end;
+   }
+   } else if (flash->upage_prev == upage_curr) {
+   if (flash->bank_curr == bank_sel) {
+   debug("SF: not require to enable bank%d\n", bank_sel);
+   goto bar_end;
+   }
+   } else {
+   flash->upage_prev = upage_curr;
+   }
 
cmd = flash->bank_write_cmd;
ret = spi_flash_write_common(flash, , 1, _sel, 1);
diff --git a/include/spi_flash.h b/include/spi_flash.h
index d0ce9e7..83052e0 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -78,6 +78,7 @@ struct spi_flash {
u8 bank_read_cmd;
u8 bank_write_cmd;
u8 bank_curr;
+   u8 upage_prev;
 #endif
u8 erase_cmd;
u8 read_cmd;
-- 
2.7.4

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

[U-Boot] [PATCH 2/2] armv8: ls1012a: Update Refresh cycle for DDR

[Prabhakar Kushwaha]

Refresh cycle value must be selected based on the frequency
of DDR. tREFI = 7.8 us as per JEDEC. The value for MDREF[REF_CNT]
should be based on round up (tREFI/tCK) formula. For 500MHz, mdref
value should be 0x0f3c8000.

Signed-off-by: Calvin Johnson 
Signed-off-by: Prabhakar Kushwaha 
---
 include/fsl_mmdc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/fsl_mmdc.h b/include/fsl_mmdc.h
index 833696b..a939d89 100644
--- a/include/fsl_mmdc.h
+++ b/include/fsl_mmdc.h
@@ -43,7 +43,7 @@
 
 #define CONFIG_SYS_MMDC_CORE_PWR_SAV_CTRL_STAT 0x1067
 
-#define CONFIG_SYS_MMDC_CORE_REFRESH_CTL   0x103e8000
+#define CONFIG_SYS_MMDC_CORE_REFRESH_CTL   0x0f3c8000
 
 #define START_REFRESH  0x0001
 
-- 
1.9.1


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

Re: [U-Boot] [PATCH v3 2/5] ARM64: rockchip: add support for rk3399 SoC based evb-board

[Kever Yang]

Hi Andreas,

On 07/18/2016 10:13 PM, Andreas Färber wrote:

Hi Kever,

Am 18.07.2016 um 06:54 schrieb Kever Yang:

Hi Andreas,

 Thanks for you comments, I will apply them one by one except some
confuse below.

On 07/18/2016 07:26 AM, Andreas Färber wrote:

Hi,

Isn't evb short for evaluation board? That makes board board then. ;)

Am 15.07.2016 um 10:42 schrieb Kever Yang:

RK3399 is a SoC from Rockchip with dual-core Cortex-A72
and qual-core Cortex-A53 CPU. It supports two USB3.0

quad-core


Fixed.




type-C ports and two USB2.0 EHCI ports. Other interfaces
are very like RK3288, the DRAM are 32bit width address

"very much like" or "very similar to"


Fixed.




and support address from 0 to 4GB-128MB range.

Signed-off-by: Kever Yang 
---

Changes in v3:
Rebase on patch from Andreas:
[PATCH] rockchip: Exclude rk_timer for ARM64
[PATCH] rockchip: Clean up CPU selection

Changes in v2:
fix description error on board Kconfig

   arch/arm/Kconfig   |  2 -
   arch/arm/mach-rockchip/Kconfig | 22 -
   arch/arm/mach-rockchip/rk3399/Kconfig  | 14 ++
   arch/arm/mach-rockchip/rk3399/Makefile |  5 ++
   board/rockchip/evb_rk3399/Kconfig  | 15 ++
   board/rockchip/evb_rk3399/MAINTAINERS  |  0
   board/rockchip/evb_rk3399/Makefile |  7 +++
   board/rockchip/evb_rk3399/evb-rk3399.c | 41 +
   include/configs/evb_rk3399.h   | 24 ++
   include/configs/rk3399_common.h| 84
++
   10 files changed, 211 insertions(+), 3 deletions(-)
   create mode 100644 arch/arm/mach-rockchip/rk3399/Kconfig
   create mode 100644 arch/arm/mach-rockchip/rk3399/Makefile
   create mode 100644 board/rockchip/evb_rk3399/Kconfig
   create mode 100644 board/rockchip/evb_rk3399/MAINTAINERS
   create mode 100644 board/rockchip/evb_rk3399/Makefile
   create mode 100644 board/rockchip/evb_rk3399/evb-rk3399.c
   create mode 100644 include/configs/evb_rk3399.h
   create mode 100644 include/configs/rk3399_common.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a262145..6e4d78a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -846,8 +846,6 @@ config STM32
 config ARCH_ROCKCHIP
   bool "Support Rockchip SoCs"
-select SUPPORT_SPL
-select SPL
   select OF_CONTROL
   select DM
   diff --git a/arch/arm/mach-rockchip/Kconfig
b/arch/arm/mach-rockchip/Kconfig
index d3f5ffd..8499692 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -9,6 +9,10 @@ config ROCKCHIP_RK3288
 video interfaces supporting HDMI and eDP, several DDR3 options
 and video codec support. Peripherals include Gigabit Ethernet,
 USB2 host and OTG, SDIO, I2S, UART,s, SPI, I2C and PWMs.
+select CPU_V7
+select RK_TIMER

You no longer define RK_TIMER - either please do (I liked it) or drop
the selection, it leads to warnings on, e.g., firefly-rk3288_defconfig
otherwise.


Fixed.




+select SUPPORT_SPL
+select SPL
 config ROCKCHIP_RK3036
   bool "Support Rockchip RK3036"
@@ -18,6 +22,21 @@ config ROCKCHIP_RK3036
 including NEON and GPU, Mali-400 graphics, several DDR3 options
 and video codec support. Peripherals include Gigabit Ethernet,
 USB2 host and OTG, SDIO, I2S, UART, SPI, I2C and PWMs.
+select CPU_V7
+select RK_TIMER
+select SUPPORT_SPL
+select SPL
+
+config ROCKCHIP_RK3399
+bool "Support Rockchip RK3399"
+help
+  The Rockchip RK3399 is a ARM-based SoC with a dual-core
Cortex-A72
+  and qual-core Cortex-A53.

quad-core


Fixed.




+  including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two
+  video interfaces supporting HDMI and eDP, several DDR3 options
+  and video codec support. Peripherals include Gigabit Ethernet,
+  USB2 host and OTG, SDIO, I2S, UART,s, SPI, I2C and PWMs.

UARTs


Fixed.




+select ARM64
 config SYS_MALLOC_F
   default y
@@ -44,8 +63,9 @@ config DM_GPIO
   default y
 config BLK
-default y
+default y if CPU_V7

Needs rebasing onto u-boot-rockchip.git.

Will fix in V5.



 source "arch/arm/mach-rockchip/rk3288/Kconfig"
   source "arch/arm/mach-rockchip/rk3036/Kconfig"
+source "arch/arm/mach-rockchip/rk3399/Kconfig"
   endif
diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig
b/arch/arm/mach-rockchip/rk3399/Kconfig
new file mode 100644
index 000..923a6de
--- /dev/null
+++ b/arch/arm/mach-rockchip/rk3399/Kconfig
@@ -0,0 +1,14 @@
+if ROCKCHIP_RK3399
+
+config TARGET_EVB_RK3399
+bool "RK3399 evb board"

Should this be enclosed in a choice section for futureproofness?

Will fix in V5.



+
+config SYS_SOC
+default "rockchip"
+
+config SYS_MALLOC_F_LEN
+default 0x0800
+
+source "board/rockchip/evb_rk3399/Kconfig"
+
+endif
diff --git a/arch/arm/mach-rockchip/rk3399/Makefile
b/arch/arm/mach-rockchip/rk3399/Makefile
new file mode 100644
index 000..ca69207
--- /dev/null
+++ 

Re: [U-Boot] [PATCH v2] pico-imx6ul: Add PMIC support

[Stefano Babic]

Hi Vanessa,

On 13/07/2016 19:27, Vanessa Maegima wrote:
> Add PMIC support. Tested by command "pmic PFUZE3000 dump".
> 
> Signed-off-by: Vanessa Maegima 
> ---

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] UBIFS broken on Microblaze architecture and possibly on other architectrures as well

[Hoefle Marco]

Hallo,

for ubifs on a spi flash I needed to add dummy functions and at atomic.h to the 
microblaze port in order to get it compile and work.

code base is v2016.07

Marco




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

Re: [U-Boot] [PATCH v2 5/9] mx7: set soc environment according to exact SoC type

[Fabio Estevam]

Hi Stefano,

On Tue, Jul 19, 2016 at 10:59 AM, Stefano Babic  wrote:

> We have already a global code, rather there are some boards (cubox, but
> also cgtqmx6eval) with own function.
>
> All is_mx6X() macros / functions are in
> arch/arm/include/asm/imx-common/sys_proto.h. The function can be
> replaced by is_mx6dq() from sysproto.h

Yes, I will send a patch converting these boards to use the common
is_mx6 common macros.

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

[U-Boot] [PATCH v5 4/4] ARM64: evb-rk3399: add a README for this board setup

[Kever Yang]

Add a README to guide people flash the ATF and U-Boot
with Rockchip tools to bring up to board.

Signed-off-by: Kever Yang 
---

Changes in v5:
- fix for comments from Simon, correct some typo;

Changes in v4: None
Changes in v3: None
Changes in v2:
- fix a binary path error

 board/rockchip/evb_rk3399/README | 73 
 1 file changed, 73 insertions(+)
 create mode 100644 board/rockchip/evb_rk3399/README

diff --git a/board/rockchip/evb_rk3399/README b/board/rockchip/evb_rk3399/README
new file mode 100644
index 000..fb8bb19
--- /dev/null
+++ b/board/rockchip/evb_rk3399/README
@@ -0,0 +1,73 @@
+Introduction
+
+
+RK3399 key features we might use in U-Boot:
+* CPU: ARMv8 64bit Big-Little architecture,
+*  Big: dual-core Cortex-A72
+*  Little: quad-core Cortex-A53
+* IRAM: 200KB
+* DRAM: 4GB-128MB dual-channel
+* eMMC: support eMMC 5.0/5.1, suport HS400, HS200, DDR50
+* SD/MMC: support SD 3.0, MMC 4.51
+* USB: USB3.0 typc-C port *2 with dwc3 controller
+*  USB2.0 EHCI host port *2
+* Display: RGB/HDMI/DP/MIPI/EDP
+
+evb key features:
+* regulator: pwm regulator for CPU B/L
+* PMIC: rk808
+* debug console: UART2
+
+In order to support Arm Trust Firmware(ATF), we need to use the
+miniloader from rockchip which:
+* do DRAM init
+* load and verify ATF image
+* load and verify U-Boot image
+
+Here is the step-by-step to boot to U-Boot on rk3399.
+
+Get the Source and prebuild binary
+==
+
+  > mkdir ~/evb_rk3399
+  > cd ~/evb_rk3399
+  > git clone https://github.com/ARM-software/arm-trusted-firmware.git
+  > git clone https://github.com/rockchip-linux/rkbin
+  > git clone https://github.com/rockchip-linux/rkflashtool
+
+Compile the ATF
+===
+
+  > cd arm-trusted-firmware
+  > make realclean
+  > make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 bl31
+
+Compile the U-Boot
+==
+
+  > cd ../u-boot
+  > make CROSS_COMPILE=aarch64-linux-gnu- evb-rk3399_defconfig all
+
+Compile the rkflashtool
+===
+
+  > cd ../rkflashtool
+  > make
+
+Package the image for miniloader
+
+  > cd ..
+  > cp arm-trusted-firmware/build/rk3399/release/bl31.bin rkbin/rk33
+  > ./rkbin/tools/trust_merger rkbin/tools/RK3399TRUST.ini
+  > ./rkbin/tools/loaderimage --pack --uboot u-boot/u-boot-dtb.bin uboot.img
+  > mkdir image
+  > mv trust.img ./image/
+  > mv uboot.img ./image/rk3399evb-uboot.bin
+
+Flash the image
+===
+Power on(or reset with RESET KEY) with MASKROM KEY preesed, and then:
+
+  > ./rkflashtool/rkflashloader rk3399evb
+
+You should be able to get U-Boot log message in console/UART2 now.
-- 
1.9.1


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

[U-Boot] [PATCH v3] mmc-uclass: correct the device number

[Kever Yang]

Not like the mmc-legacy which the devnum starts from 1, it starts from 0
in mmc-uclass, so the device number should be (devnum + 1) in get_mmc_num().

Signed-off-by: Kever Yang 
---

Changes in v3:
- apply comments from Jaehoon Chung

Changes in v2:
- add comment for get_mmc_num() in mmc.h
- update mmc_get_next_devnum()

 drivers/mmc/mmc-uclass.c | 4 ++--
 include/mmc.h| 6 ++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
index 38ced41..d0ca91b 100644
--- a/drivers/mmc/mmc-uclass.c
+++ b/drivers/mmc/mmc-uclass.c
@@ -111,7 +111,7 @@ struct mmc *find_mmc_device(int dev_num)
 
 int get_mmc_num(void)
 {
-   return max(blk_find_max_devnum(IF_TYPE_MMC), 0);
+   return max((blk_find_max_devnum(IF_TYPE_MMC) + 1), 0);
 }
 
 int mmc_get_next_devnum(void)
@@ -122,7 +122,7 @@ int mmc_get_next_devnum(void)
if (ret < 0)
return ret;
 
-   return ret + 1;
+   return ret;
 }
 
 struct blk_desc *mmc_get_blk_desc(struct mmc *mmc)
diff --git a/include/mmc.h b/include/mmc.h
index 8f309f1..dd47f34 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -503,6 +503,12 @@ void mmc_set_clock(struct mmc *mmc, uint clock);
 struct mmc *find_mmc_device(int dev_num);
 int mmc_set_dev(int dev_num);
 void print_mmc_devices(char separator);
+
+/**
+ * get_mmc_num() - get the total MMC device number
+ *
+ * @return 0 if there is no MMC device, else the number of devices
+ */
 int get_mmc_num(void);
 int mmc_hwpart_config(struct mmc *mmc, const struct mmc_hwpart_conf *conf,
  enum mmc_hwpart_conf_mode mode);
-- 
1.9.1


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

Re: [U-Boot] [PATCH 1/5] fsl: serdes: ensure accessing the initialized maps of serdes protocol

[Zhiqiang Hou]

Hi All,

Any comments?

> -Original Message-
> From: Zhiqiang Hou [mailto:zhiqiang@nxp.com]
> Sent: 2016年7月4日 14:28
> To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; york sun
> ; w...@denx.de; Prabhakar Kushwaha
> ; alison.w...@freescale.com;
> mingkai...@freescale.com
> Cc: yao.y...@freescale.com; qianyu.g...@freescale.com;
> bmeng...@gmail.com; Shengzhou Liu ; Zhiqiang Hou
> 
> Subject: [PATCH 1/5] fsl: serdes: ensure accessing the initialized maps of 
> serdes
> protocol
> 
> From: Hou Zhiqiang 
> 
> Up to now, the function is_serdes_configed() doesn't check if the map of 
> serdes
> protocol is initialized before accessing it. The function
> is_serdes_configed() will get wrong result when it was called before the 
> serdes
> protocol maps initialized. As the first eliment of the map isn't used for any 
> device,
> so use it as the flag to indicate if the map has been initialized.
> 
> Signed-off-by: Hou Zhiqiang 
> ---
> Tested on LS1043ARDB, LS1021AQDS and T4240QDS boards.
> 
>  arch/arm/cpu/armv7/ls102xa/fsl_ls1_serdes.c  |  9 +
>  arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c |  6 ++
> arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c |  9 +
>  arch/powerpc/cpu/mpc85xx/bsc9132_serdes.c|  6 ++
>  arch/powerpc/cpu/mpc85xx/c29x_serdes.c   |  6 ++
>  arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c   | 15 +++
>  arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c|  6 ++
>  arch/powerpc/cpu/mpc85xx/mpc8536_serdes.c| 16 +++-
>  arch/powerpc/cpu/mpc85xx/mpc8544_serdes.c| 16 +++-
>  arch/powerpc/cpu/mpc85xx/mpc8548_serdes.c|  6 ++
>  arch/powerpc/cpu/mpc85xx/mpc8568_serdes.c|  6 ++
>  arch/powerpc/cpu/mpc85xx/mpc8569_serdes.c|  6 ++
>  arch/powerpc/cpu/mpc85xx/mpc8572_serdes.c|  6 ++
>  arch/powerpc/cpu/mpc85xx/p1010_serdes.c  | 16 +++-
>  arch/powerpc/cpu/mpc85xx/p1021_serdes.c  |  6 ++
>  arch/powerpc/cpu/mpc85xx/p1022_serdes.c  | 16 +++-
>  arch/powerpc/cpu/mpc85xx/p1023_serdes.c  |  9 -
>  arch/powerpc/cpu/mpc85xx/p2020_serdes.c  |  6 ++
>  arch/powerpc/cpu/mpc86xx/mpc8610_serdes.c| 16 +++-
>  arch/powerpc/cpu/mpc86xx/mpc8641_serdes.c| 16 +++-
>  20 files changed, 191 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/ls102xa/fsl_ls1_serdes.c
> b/arch/arm/cpu/armv7/ls102xa/fsl_ls1_serdes.c
> index 9b78acb..ffb05cb 100644
> --- a/arch/arm/cpu/armv7/ls102xa/fsl_ls1_serdes.c
> +++ b/arch/arm/cpu/armv7/ls102xa/fsl_ls1_serdes.c
> @@ -23,9 +23,15 @@ int is_serdes_configured(enum srds_prtcl device)
>   u64 ret = 0;
> 
>  #ifdef CONFIG_SYS_FSL_SRDS_1
> + if (!(serdes1_prtcl_map & 1ULL << NONE))
> + fsl_serdes_init();
> +
>   ret |= (1ULL << device) & serdes1_prtcl_map;  #endif  #ifdef
> CONFIG_SYS_FSL_SRDS_2
> + if (!(serdes2_prtcl_map & 1ULL << NONE))
> + fsl_serdes_init();
> +
>   ret |= (1ULL << device) & serdes2_prtcl_map;  #endif
> 
> @@ -87,6 +93,9 @@ u64 serdes_init(u32 sd, u32 sd_addr, u32 sd_prctl_mask, u32
> sd_prctl_shift)
>   serdes_prtcl_map |= (1ULL << lane_prtcl);
>   }
> 
> + /* Set the first bit to indicate serdes has been initialized */
> + serdes_prtcl_map |= (1ULL << NONE);
> +
>   return serdes_prtcl_map;
>  }
> 
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c
> b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c
> index fe3444a..fff80ef 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c
> @@ -19,6 +19,9 @@ int is_serdes_configured(enum srds_prtcl device)
>   int ret = 0;
> 
>  #ifdef CONFIG_SYS_FSL_SRDS_1
> + if (!serdes1_prtcl_map[NONE])
> + fsl_serdes_init();
> +
>   ret |= serdes1_prtcl_map[device];
>  #endif
> 
> @@ -103,6 +106,9 @@ void serdes_init(u32 sd, u32 sd_addr, u32 sd_prctl_mask,
> u32 sd_prctl_shift,
>   else
>   serdes_prtcl_map[lane_prtcl] = 1;
>   }
> +
> + /* Set the first eliment to indicate serdes has been initialized */
> + serdes_prtcl_map[NONE] = 1;
>  }
> 
>  void fsl_serdes_init(void)
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
> b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
> index be6acc6..d83a073 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
> @@ -28,9 +28,15 @@ int is_serdes_configured(enum srds_prtcl device)
>   int ret = 0;
> 
>  #ifdef CONFIG_SYS_FSL_SRDS_1
> + if (!serdes1_prtcl_map[NONE])

Re: [U-Boot] [PATCH] mmc: fix the output format

[Ziyuan Xu]

Hi Jaehoon,

On 2016年07月19日 18:35, Jaehoon Chung wrote:

Hi Ziyuan,

On 07/19/2016 07:14 PM, Ziyuan Xu wrote:

It's nicer to see this:

=> mmc list
dwmmc@ff0c: 0
dwmmc@ff0f: 1 (eMMC)

than this:

=> mmc list
dwmmc@ff0c: 0dwmmc@ff0f: 1 (eMMC)

With the latter, it's much clearer which mmc devices are on.

You're right. After applied your patch, it may display like mmc-legacy type.
If add the comment in more detail,
How about "Display mmc list information like mmc-legacy type." ? :)

Looks good for me.I will change commit to
mmc: display mmc list informaton like mmc_legacy type.
Thanks!



Best Regards,
Jaehoon Chung


Signed-off-by: Ziyuan Xu 
---

  drivers/mmc/mmc-uclass.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
index 38ced41..beebc70 100644
--- a/drivers/mmc/mmc-uclass.c
+++ b/drivers/mmc/mmc-uclass.c
@@ -169,7 +169,7 @@ void print_mmc_devices(char separator)
  
  	for (uclass_first_device(UCLASS_MMC, );

 dev;
-uclass_next_device()) {
+uclass_next_device(), first = false) {
struct mmc *m = mmc_get_mmc_dev(dev);
  
  		if (!first) {









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

[U-Boot] [PATCH v5 1/4] dts: add support for Rockchip rk3399 soc

[Kever Yang]

These files are from kernel upstream:
"649a371 Add linux-next specific files for 20160616"
with some modification need by U-Boot:
- chosen with stdout-path to uart2.
- add clock-frequency for uart2

Signed-off-by: Kever Yang 
Acked-by: Simon Glass 
---

Changes in v5:
- add file source and detail changes for U-Boot

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/dts/Makefile  |3 +-
 arch/arm/dts/rk3399-evb.dts|  104 
 arch/arm/dts/rk3399.dtsi   | 1028 
 include/dt-bindings/clock/rk3399-cru.h |  746 +++
 4 files changed, 1880 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/rk3399-evb.dts
 create mode 100644 arch/arm/dts/rk3399.dtsi
 create mode 100644 include/dt-bindings/clock/rk3399-cru.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 73e334e..974fbfb 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -32,7 +32,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-jerry.dtb \
rk3288-rock2-square.dtb \
rk3288-evb.dtb \
-   rk3036-sdk.dtb
+   rk3036-sdk.dtb \
+   rk3399-evb.dtb
 dtb-$(CONFIG_ARCH_MESON) += \
meson-gxbb-odroidc2.dtb
 dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
new file mode 100644
index 000..bbcfcd0
--- /dev/null
+++ b/arch/arm/dts/rk3399-evb.dts
@@ -0,0 +1,104 @@
+/*
+ * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+/dts-v1/;
+#include 
+#include "rk3399.dtsi"
+
+/ {
+   model = "Rockchip RK3399 Evaluation Board";
+   compatible = "rockchip,rk3399-evb", "rockchip,rk3399",
+"google,rk3399evb-rev2";
+
+   chosen {
+   stdout-path = 
+   };
+
+   vdd_center: vdd-center {
+   compatible = "pwm-regulator";
+   pwms = < 0 25000 0>;
+   regulator-name = "vdd_center";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-always-on;
+   regulator-boot-on;
+   status = "okay";
+   };
+
+   vcc3v3_sys: vcc3v3-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   vcc_phy: vcc-phy-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_phy";
+   regulator-always-on;
+   regulator-boot-on;
+   };
+};
+
+_phy {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   bus-width = <8>;
+   mmc-hs400-1_8v;
+   mmc-hs400-enhanced-strobe;
+   non-removable;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_host0_ehci {
+   status = "okay";
+};
+
+_host0_ohci {
+   status = "okay";
+};
+
+_host1_ehci {
+   status = "okay";
+};
+
+_host1_ohci {
+   status = "okay";
+};
+
+ {
+   pmic {
+   pmic_int_l: pmic-int-l {
+   rockchip,pins =
+   <1 21 RK_FUNC_GPIO _pull_up>;
+   };
+
+   pmic_dvs2: pmic-dvs2 {
+   rockchip,pins =
+   <1 18 RK_FUNC_GPIO _pull_down>;
+   };
+   };
+};
diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
new file mode 100644
index 000..fb5af54
--- /dev/null
+++ b/arch/arm/dts/rk3399.dtsi
@@ -0,0 +1,1028 @@
+/*
+ * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "rockchip,rk3399";
+
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   serial4 = 
+   };
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <_l0>;
+   };
+   core1 {
+   cpu = <_l1>;
+   };
+   core2 {
+   cpu = <_l2>;
+   };
+   core3 {
+   cpu = <_l3>;
+   

Re: [U-Boot] [PATCH v4 2/4] ARM64: rockchip: add support for rk3399 SoC based evb

[Kever Yang]

Hi Andreas,

On 07/18/2016 09:34 PM, Andreas Färber wrote:

Am 18.07.2016 um 10:46 schrieb Kever Yang:

RK3399 is a SoC from Rockchip with dual-core Cortex-A72
and quad-core Cortex-A53 CPU. It supports two USB3.0
type-C ports and two USB2.0 EHCI ports. Other interfaces
are very much like RK3288, the DRAM are 32bit width address
and support address from 0 to 4GB-128MB range.

Signed-off-by: Kever Yang 
---

Changes in v4:
remove extra blank line in evb_rk3399.h,
remove unnecessary including file in rk3399_common.h,
fix base on commend from Andreas,
Rebase to U-Boot ToT.

Most of my review comments are still unresolved...

I will reply your comments one by one this time, I make a mistake
because I didn't rebase to ToT of u-boot-rockchip, but rebase to ToT of 
U-Boot,

and also didn't spend enough time on Heiko's and your patch set.



Changes in v3:
Rebase on patch from Andreas:
[PATCH] rockchip: Exclude rk_timer for ARM64
[PATCH] rockchip: Clean up CPU selection

Changes in v2:
fix description error on board Kconfig

  arch/arm/Kconfig   |  2 -
  arch/arm/mach-rockchip/Kconfig | 18 +
  arch/arm/mach-rockchip/rk3399/Kconfig  | 18 +
  board/rockchip/evb_rk3399/Kconfig  | 15 +++
  board/rockchip/evb_rk3399/MAINTAINERS  |  0
  board/rockchip/evb_rk3399/Makefile |  7 
  board/rockchip/evb_rk3399/evb-rk3399.c | 40 +++
  include/configs/evb_rk3399.h   | 24 
  include/configs/rk3399_common.h| 71 ++
  9 files changed, 193 insertions(+), 2 deletions(-)
  create mode 100644 arch/arm/mach-rockchip/rk3399/Kconfig
  create mode 100644 board/rockchip/evb_rk3399/Kconfig
  create mode 100644 board/rockchip/evb_rk3399/MAINTAINERS
  create mode 100644 board/rockchip/evb_rk3399/Makefile
  create mode 100644 board/rockchip/evb_rk3399/evb-rk3399.c
  create mode 100644 include/configs/evb_rk3399.h
  create mode 100644 include/configs/rk3399_common.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f9fddad..fee6a1c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -838,8 +838,6 @@ config STM32
  
  config ARCH_ROCKCHIP

bool "Support Rockchip SoCs"
-   select SUPPORT_SPL
-   select SPL
select OF_CONTROL
select BLK
select DM

Here and below we seemed to get a merge conflict with Heiko's patch - he
added ifs instead, but still they selects got added below. I don't care
which way we do it, but it should be consistent please.


Will using what Simon do when he apply this patch.




diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 12415fc..4a4b6ee 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -9,6 +9,9 @@ config ROCKCHIP_RK3288
  video interfaces supporting HDMI and eDP, several DDR3 options
  and video codec support. Peripherals include Gigabit Ethernet,
  USB2 host and OTG, SDIO, I2S, UART,s, SPI, I2C and PWMs.
+   select CPU_V7

Still duplicate.


will fix in V5.




+   select SUPPORT_SPL
+   select SPL

Still below help.


will fix in V5.



  
  config ROCKCHIP_RK3036

bool "Support Rockchip RK3036"
@@ -18,7 +21,22 @@ config ROCKCHIP_RK3036
  including NEON and GPU, Mali-400 graphics, several DDR3 options
  and video codec support. Peripherals include Gigabit Ethernet,
  USB2 host and OTG, SDIO, I2S, UART, SPI, I2C and PWMs.
+   select CPU_V7
+   select SUPPORT_SPL
+   select SPL

Ditto.


will fix in V5.




+
+config ROCKCHIP_RK3399
+   bool "Support Rockchip RK3399"
+   help
+ The Rockchip RK3399 is a ARM-based SoC with a dual-core Cortex-A72
+ and quad-core Cortex-A53.
+ including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two
+ video interfaces supporting HDMI and eDP, several DDR3 options
+ and video codec support. Peripherals include Gigabit Ethernet,
+ USB2 host and OTG, SDIO, I2S, UARTs, SPI, I2C and PWMs.
+   select ARM64

Still below help.

Note that in Simon's tree this slipped below the new BROM option, it
should logically be above and after RK3288.


will fix in V5.



  
  source "arch/arm/mach-rockchip/rk3288/Kconfig"

  source "arch/arm/mach-rockchip/rk3036/Kconfig"

In Simon's tree this option accidentally got dropped in this patch!


will fix in V5.




+source "arch/arm/mach-rockchip/rk3399/Kconfig"
  endif
diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig 
b/arch/arm/mach-rockchip/rk3399/Kconfig
new file mode 100644
index 000..d15bb40
--- /dev/null
+++ b/arch/arm/mach-rockchip/rk3399/Kconfig
@@ -0,0 +1,18 @@
+if ROCKCHIP_RK3399
+
+config TARGET_EVB_RK3399
+   bool "RK3399 evaluation board"
+   help
+ RK3399evb is a evaluation board for Rockchp rk3399,
+ with full function and phisical connectors support like type-C ports,
+ usb2.0 host ports, LVDS, 

[U-Boot] [PATCH v5 0/4] add support for rk3399 soc and evb

[Kever Yang]

Hi Simon,

Sorry for didn't apply all the changes for comments from
Andreas in V4, I rebase this patchset on u-boot-rockchip.git
master branch and reset to below commit:
 f278234 rockchip: update fastboot usage

Please help to rebase my patches, you should be able to
apply these patches directly.

This patchset add support for rk3399 with ATF based on
Rockchip miniloader as secondary bootloader instead of
U-Boot SPL.

Rockchip miniloader init the DRAM and load the ATF and
U-Boot to runing address, and then jump to ATF, the ATF
do some init and switch to EL2/EL1 mode before jump to
next loader which is U-Boot here.

Pls reference board/rockchip/evb_rk3399/README to setup
the board.

Will migrate to SPL once its ready for ATF.

This patch set is based on below patch:
"board: move all the rockchip board in one folder"

This patch set has been test on rk3399 evb board.

In this version, I split the mmc driver in seperate thread,
because when I enable the full-model for mmc driver,
Seems bug happen in blk layer, will descript detail in
mmc patch.


Changes in v5:
- add file source and detail changes for U-Boot
- Rebase to u-boot-rockchip.git;
- fixes base on comments from Andreas;
- fix for comments from Simon, correct some typo;

Changes in v4:
- remove extra blank line in evb_rk3399.h,
- remove unnecessary including file in rk3399_common.h,
- fixes base on comments from Andreas,
- Rebase on U-Boot ToT.
- move config CONFIG_SYS_NS16550 from chip common to defconfig

Changes in v3:
- Rebase on patch from Andreas:
- [PATCH] rockchip: Exclude rk_timer for ARM64
- [PATCH] rockchip: Clean up CPU selection

Changes in v2:
- fix description error on board Kconfig
- fix a binary path error

Kever Yang (4):
  dts: add support for Rockchip rk3399 soc
  ARM64: rockchip: add support for rk3399 SoC based evb
  config: add config file for evb-rk3399
  ARM64: evb-rk3399: add a README for this board setup

 arch/arm/Kconfig   |6 +-
 arch/arm/dts/Makefile  |3 +-
 arch/arm/dts/rk3399-evb.dts|  104 
 arch/arm/dts/rk3399.dtsi   | 1028 
 arch/arm/mach-rockchip/Kconfig |   16 +
 arch/arm/mach-rockchip/Makefile|1 +
 arch/arm/mach-rockchip/rk3399/Kconfig  |   23 +
 arch/arm/mach-rockchip/rk3399/Makefile |7 +
 arch/arm/mach-rockchip/rk3399/rk3399.c |   28 +
 board/rockchip/evb_rk3399/Kconfig  |   15 +
 board/rockchip/evb_rk3399/MAINTAINERS  |0
 board/rockchip/evb_rk3399/Makefile |7 +
 board/rockchip/evb_rk3399/README   |   73 +++
 board/rockchip/evb_rk3399/evb-rk3399.c |   26 +
 configs/evb-rk3399_defconfig   |   33 +
 include/configs/evb_rk3399.h   |   26 +
 include/configs/rk3399_common.h|   73 +++
 include/dt-bindings/clock/rk3399-cru.h |  746 +++
 18 files changed, 2210 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/dts/rk3399-evb.dts
 create mode 100644 arch/arm/dts/rk3399.dtsi
 create mode 100644 arch/arm/mach-rockchip/rk3399/Kconfig
 create mode 100644 arch/arm/mach-rockchip/rk3399/Makefile
 create mode 100644 arch/arm/mach-rockchip/rk3399/rk3399.c
 create mode 100644 board/rockchip/evb_rk3399/Kconfig
 create mode 100644 board/rockchip/evb_rk3399/MAINTAINERS
 create mode 100644 board/rockchip/evb_rk3399/Makefile
 create mode 100644 board/rockchip/evb_rk3399/README
 create mode 100644 board/rockchip/evb_rk3399/evb-rk3399.c
 create mode 100644 configs/evb-rk3399_defconfig
 create mode 100644 include/configs/evb_rk3399.h
 create mode 100644 include/configs/rk3399_common.h
 create mode 100644 include/dt-bindings/clock/rk3399-cru.h

-- 
1.9.1


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

[U-Boot] [PATCH v5 3/4] config: add config file for evb-rk3399

[Kever Yang]

This patch add basic config option for evb-rk3399 board.

Signed-off-by: Kever Yang 
---

Changes in v5: None
Changes in v4:
- move config CONFIG_SYS_NS16550 from chip common to defconfig

Changes in v3: None
Changes in v2: None

 configs/evb-rk3399_defconfig | 33 +
 1 file changed, 33 insertions(+)
 create mode 100644 configs/evb-rk3399_defconfig

diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
new file mode 100644
index 000..3f9b47e
--- /dev/null
+++ b/configs/evb-rk3399_defconfig
@@ -0,0 +1,33 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_ROCKCHIP_RK3399=y
+CONFIG_TARGET_EVB_RK3399=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-evb"
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BOOTZ=y
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_CLK=y
+CONFIG_FIT=y
+CONFIG_SYSRESET=y
+CONFIG_DM_MMC=y
+CONFIG_ROCKCHIP_SDHCI=y
+CONFIG_PINCTRL=y
+CONFIG_RAM=y
+CONFIG_SYS_NS16550=y
+CONFIG_DEBUG_UART=y
+CONFIG_DEBUG_UART_BASE=0xFF1A
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_USE_TINY_PRINTF=y
+CONFIG_ERRNO_STR=y
-- 
1.9.1


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

[U-Boot] [PATCH v5 2/4] ARM64: rockchip: add support for rk3399 SoC based evb

[Kever Yang]

RK3399 is a SoC from Rockchip with dual-core Cortex-A72
and quad-core Cortex-A53 CPU. It supports two USB3.0
type-C ports and two USB2.0 EHCI ports. Other interfaces
are very much like RK3288, the DRAM are 32bit width address
and support address from 0 to 4GB-128MB range.

Signed-off-by: Kever Yang 
---

Changes in v5:
- Rebase to u-boot-rockchip.git;
- fixes base on comments from Andreas;

Changes in v4:
- remove extra blank line in evb_rk3399.h,
- remove unnecessary including file in rk3399_common.h,
- fixes base on comments from Andreas,
- Rebase on U-Boot ToT.

Changes in v3:
- Rebase on patch from Andreas:
- [PATCH] rockchip: Exclude rk_timer for ARM64
- [PATCH] rockchip: Clean up CPU selection

Changes in v2:
- fix description error on board Kconfig

 arch/arm/Kconfig   |  6 +--
 arch/arm/mach-rockchip/Kconfig | 16 
 arch/arm/mach-rockchip/Makefile|  1 +
 arch/arm/mach-rockchip/rk3399/Kconfig  | 23 +++
 arch/arm/mach-rockchip/rk3399/Makefile |  7 
 arch/arm/mach-rockchip/rk3399/rk3399.c | 28 +
 board/rockchip/evb_rk3399/Kconfig  | 15 +++
 board/rockchip/evb_rk3399/MAINTAINERS  |  0
 board/rockchip/evb_rk3399/Makefile |  7 
 board/rockchip/evb_rk3399/evb-rk3399.c | 26 
 include/configs/evb_rk3399.h   | 26 
 include/configs/rk3399_common.h| 73 ++
 12 files changed, 224 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/mach-rockchip/rk3399/Kconfig
 create mode 100644 arch/arm/mach-rockchip/rk3399/Makefile
 create mode 100644 arch/arm/mach-rockchip/rk3399/rk3399.c
 create mode 100644 board/rockchip/evb_rk3399/Kconfig
 create mode 100644 board/rockchip/evb_rk3399/MAINTAINERS
 create mode 100644 board/rockchip/evb_rk3399/Makefile
 create mode 100644 board/rockchip/evb_rk3399/evb-rk3399.c
 create mode 100644 include/configs/evb_rk3399.h
 create mode 100644 include/configs/rk3399_common.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f9fddad..aeac5f3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -838,14 +838,12 @@ config STM32
 
 config ARCH_ROCKCHIP
bool "Support Rockchip SoCs"
-   select SUPPORT_SPL
-   select SPL
select OF_CONTROL
select BLK
select DM
-   select SPL_DM
+   select SPL_DM if SPL
select SYS_MALLOC_F
-   select SPL_SYS_MALLOC_SIMPLE
+   select SPL_SYS_MALLOC_SIMPLE if SPL
select DM_GPIO
select DM_I2C
select DM_MMC
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index a3faafe..1aac3c8 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -3,6 +3,8 @@ if ARCH_ROCKCHIP
 config ROCKCHIP_RK3036
bool "Support Rockchip RK3036"
select CPU_V7
+   select SUPPORT_SPL
+   select SPL
help
  The Rockchip RK3036 is a ARM-based SoC with a dual-core Cortex-A7
  including NEON and GPU, Mali-400 graphics, several DDR3 options
@@ -12,6 +14,8 @@ config ROCKCHIP_RK3036
 config ROCKCHIP_RK3288
bool "Support Rockchip RK3288"
select CPU_V7
+   select SUPPORT_SPL
+   select SPL
help
  The Rockchip RK3288 is a ARM-based SoC with a quad-core Cortex-A17
  including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two
@@ -19,6 +23,17 @@ config ROCKCHIP_RK3288
  and video codec support. Peripherals include Gigabit Ethernet,
  USB2 host and OTG, SDIO, I2S, UART,s, SPI, I2C and PWMs.
 
+config ROCKCHIP_RK3399
+   bool "Support Rockchip RK3399"
+   select ARM64
+   help
+ The Rockchip RK3399 is a ARM-based SoC with a dual-core Cortex-A72
+ and quad-core Cortex-A53.
+ including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two
+ video interfaces supporting HDMI and eDP, several DDR3 options
+ and video codec support. Peripherals include Gigabit Ethernet,
+ USB2 host and OTG, SDIO, I2S, UARTs, SPI, I2C and PWMs.
+
 config ROCKCHIP_SPL_BACK_TO_BROM
bool "SPL returns to bootrom"
default y if ROCKCHIP_RK3036
@@ -29,4 +44,5 @@ config ROCKCHIP_SPL_BACK_TO_BROM
 
 source "arch/arm/mach-rockchip/rk3036/Kconfig"
 source "arch/arm/mach-rockchip/rk3288/Kconfig"
+source "arch/arm/mach-rockchip/rk3399/Kconfig"
 endif
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 722b582..157d42f 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -16,3 +16,4 @@ obj-y += rk_timer.o
 endif
 obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
 obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
+obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig 
b/arch/arm/mach-rockchip/rk3399/Kconfig
new file mode 100644
index 000..83bd04a
--- /dev/null
+++ b/arch/arm/mach-rockchip/rk3399/Kconfig
@@ -0,0 +1,23 @@
+if ROCKCHIP_RK3399
+
+choice
+  

Re: [U-Boot] [PATCH v2 5/9] mx7: set soc environment according to exact SoC type

[Stefano Babic]

Hi Tom,

On 19/07/2016 02:36, Tom Rini wrote:
> On Mon, Jul 18, 2016 at 03:21:39PM -0700, Stefan Agner wrote:
>> On 2016-07-18 15:19, Fabio Estevam wrote:
>>> On Wed, Jul 13, 2016 at 4:25 AM, Stefan Agner  wrote:
 From: Stefan Agner 

 This can be useful if the same U-Boot binary is used for boards
 available with a i.MX 7Solo and i.MX 7Dual.

 Signed-off-by: Stefan Agner 
 Reviewed-by: Simon Glass 
 ---

  arch/arm/cpu/armv7/mx7/soc.c | 14 ++
  include/configs/mx7_common.h |  2 ++
  2 files changed, 16 insertions(+)

 diff --git a/arch/arm/cpu/armv7/mx7/soc.c b/arch/arm/cpu/armv7/mx7/soc.c
 index ef46c92..dead1d3 100644
 --- a/arch/arm/cpu/armv7/mx7/soc.c
 +++ b/arch/arm/cpu/armv7/mx7/soc.c
 @@ -248,6 +248,20 @@ int arch_cpu_init(void)
 return 0;
  }

 +#ifdef CONFIG_ARCH_MISC_INIT
 +int arch_misc_init(void)
 +{
 +#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
 +   if (is_mx7d())
 +   setenv("soc", "imx7d");
 +   else
 +   setenv("soc", "imx7s");
 +#endif
 +
 +   return 0;
 +}
 +#endif
>>>
>>> What about adding the following code in your board file?
>>>
>>> int board_late_init(void)
>>> {
>>> #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
>>> if (is_mx7d())
>>> setenv("board_rev", "MX7D");
>>> else
>>> setenv("board_rev", "MX7S");
>>> #endif
>>>
>>> return 0;
>>> }
>>>
>>> This was the suggestion I got from Tom when I was doing runtime SoC
>>> detection for mx6cubox.
>>
>> I followed the runtime detection for Vybrid in:
>> arch/arm/cpu/armv7/vf610/generic.c
>>
>> But sure, doing it at board level would be possible too.
>>
>> Due to the similarity of i.MX 7Solo and 7Dual there will probably be
>> many board designs available in this two variants, hence I feel it would
>> be worthwhile to have it on arch level...
> 
> So, yeah, I may have said the wrong thing for cubox, maybe not.  I think
> that for the actual SoC (and 'soc') we should set that as high as we
> easily and _correctly_ can.  We set 'board_rev' today in the board
> files, and this makes sense to me, especially when used as the "board"
> part, eg:
> board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c: setenv("board_rev", "9X9");
> board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c: setenv("board_rev", 
> "14X14")
> 
> We set 'board_rev' today in a number of board files and a quick review
> just now tells me that yes, we should have done that higher up.
> Probably.  Using the mx6cubox example, I see:
> static bool is_mx6q(void)
> {
> if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
>   return true;
> 
> Can we move this to global code, check for each of the MX6 variants, MX7
> variants and always be returning what we return today?
> 

We have already a global code, rather there are some boards (cubox, but
also cgtqmx6eval) with own function.

All is_mx6X() macros / functions are in
arch/arm/include/asm/imx-common/sys_proto.h. The function can be
replaced by is_mx6dq() from sysproto.h

Best regards,
Stefano

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] ARM: uniphier: use (devm_)ioremap() instead of map_sysmem()

[Masahiro Yamada]

This does not have much impact on behavior, but makes code look more
more like Linux.  The use of devm_ioremap() often helps to delete
.remove callbacks entirely.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Replace more

 arch/arm/mach-uniphier/arm64/arm-cci500.c|  6 ++
 arch/arm/mach-uniphier/arm64/smp_kick_cpus.c |  6 ++
 arch/arm/mach-uniphier/arm64/timer.c |  6 ++
 arch/arm/mach-uniphier/dram/cmd_ddrphy.c |  9 -
 drivers/clk/uniphier/clk-uniphier-core.c | 12 +---
 drivers/clk/uniphier/clk-uniphier-mio.c  |  1 -
 drivers/clk/uniphier/clk-uniphier.h  |  1 -
 drivers/gpio/gpio-uniphier.c | 13 +
 drivers/i2c/i2c-uniphier-f.c | 13 +
 drivers/i2c/i2c-uniphier.c   | 13 +
 drivers/mmc/uniphier-sd.c|  4 +---
 drivers/pinctrl/uniphier/pinctrl-uniphier-core.c | 13 +
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c |  1 -
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c |  1 -
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld4.c  |  1 -
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld6b.c |  1 -
 drivers/pinctrl/uniphier/pinctrl-uniphier-pro4.c |  1 -
 drivers/pinctrl/uniphier/pinctrl-uniphier-pro5.c |  1 -
 drivers/pinctrl/uniphier/pinctrl-uniphier-pxs2.c |  1 -
 drivers/pinctrl/uniphier/pinctrl-uniphier-sld8.c |  1 -
 drivers/pinctrl/uniphier/pinctrl-uniphier.h  |  2 --
 drivers/serial/serial_uniphier.c | 11 +--
 22 files changed, 17 insertions(+), 101 deletions(-)

diff --git a/arch/arm/mach-uniphier/arm64/arm-cci500.c 
b/arch/arm/mach-uniphier/arm64/arm-cci500.c
index 607f96a..f86d72a 100644
--- a/arch/arm/mach-uniphier/arm64/arm-cci500.c
+++ b/arch/arm/mach-uniphier/arm64/arm-cci500.c
@@ -6,8 +6,6 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -28,13 +26,13 @@ void cci500_init(unsigned int nr_slaves)
void __iomem *base;
u32 tmp;
 
-   base = map_sysmem(slave_base, SZ_4K);
+   base = ioremap(slave_base, SZ_4K);
 
tmp = readl(base);
tmp |= CCI500_SNOOP_CTRL_EN_DVM | CCI500_SNOOP_CTRL_EN_SNOOP;
writel(tmp, base);
 
-   unmap_sysmem(base);
+   iounmap(base);
 
slave_base += CCI500_SLAVE_OFFSET;
}
diff --git a/arch/arm/mach-uniphier/arm64/smp_kick_cpus.c 
b/arch/arm/mach-uniphier/arm64/smp_kick_cpus.c
index 5971ad2..3ed208b 100644
--- a/arch/arm/mach-uniphier/arm64/smp_kick_cpus.c
+++ b/arch/arm/mach-uniphier/arm64/smp_kick_cpus.c
@@ -4,8 +4,6 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
-#include 
-#include 
 #include 
 #include 
 
@@ -18,11 +16,11 @@ void uniphier_smp_kick_all_cpus(void)
 {
void __iomem *rom_boot_rsv0;
 
-   rom_boot_rsv0 = map_sysmem(UNIPHIER_SMPCTRL_ROM_RSV0, SZ_8);
+   rom_boot_rsv0 = ioremap(UNIPHIER_SMPCTRL_ROM_RSV0, SZ_8);
 
writeq((u64)uniphier_secondary_startup, rom_boot_rsv0);
 
-   unmap_sysmem(rom_boot_rsv0);
+   iounmap(rom_boot_rsv0);
 
uniphier_smp_setup();
 
diff --git a/arch/arm/mach-uniphier/arm64/timer.c 
b/arch/arm/mach-uniphier/arm64/timer.c
index 4beab9d..b81e465 100644
--- a/arch/arm/mach-uniphier/arm64/timer.c
+++ b/arch/arm/mach-uniphier/arm64/timer.c
@@ -4,8 +4,6 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -21,7 +19,7 @@ int timer_init(void)
void __iomem *base;
u32 tmp;
 
-   base = map_sysmem(CNT_CONTROL_BASE, SZ_4K);
+   base = ioremap(CNT_CONTROL_BASE, SZ_4K);
 
/*
 * Note:
@@ -32,7 +30,7 @@ int timer_init(void)
tmp |= CNTCR_EN;
writel(tmp, base + CNTCR);
 
-   unmap_sysmem(base);
+   iounmap(base);
 
return 0;
 }
diff --git a/arch/arm/mach-uniphier/dram/cmd_ddrphy.c 
b/arch/arm/mach-uniphier/dram/cmd_ddrphy.c
index 7a9f76c..32108c0 100644
--- a/arch/arm/mach-uniphier/dram/cmd_ddrphy.c
+++ b/arch/arm/mach-uniphier/dram/cmd_ddrphy.c
@@ -5,7 +5,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 
@@ -51,7 +50,7 @@ static void dump_loop(unsigned long *base,
int p, dx;
 
for (p = 0; *base; base++, p++) {
-   phy = map_sysmem(*base, SZ_4K);
+   phy = ioremap(*base, SZ_4K);
 
for (dx = 0; dx < NR_DATX8_PER_DDRPHY; dx++) {
printf("PHY%dDX%d:", p, dx);
@@ -59,7 +58,7 @@ static void dump_loop(unsigned long *base,
printf("\n");
}
 
-   unmap_sysmem(phy);
+   iounmap(phy);
}
 }
 
@@ -172,7 +171,7 @@ static void reg_dump(unsigned long *base)
printf("\n--- DDR PHY registers ---\n");
 
for (p = 0; *base; base++, p++) {
-   phy = 

Re: [U-Boot] [PATCH v2] mmc-uclass: correct the device number

[Jaehoon Chung]

On 07/19/2016 06:28 PM, Kever Yang wrote:
> Not like the mmc-legacy which the devnum starts from 1, it starts from 0
> in mmc-uclass, so the device number should be (devnum + 1) in get_mmc_num().
> 
> Signed-off-by: Kever Yang 
> ---
> 
> Changes in v2:
> - add comment for get_mmc_num() in mmc.h
> - update mmc_get_next_devnum()
> 
>  drivers/mmc/mmc-uclass.c | 4 ++--
>  include/mmc.h| 6 ++
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index 38ced41..d0ca91b 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -111,7 +111,7 @@ struct mmc *find_mmc_device(int dev_num)
>  
>  int get_mmc_num(void)
>  {
> - return max(blk_find_max_devnum(IF_TYPE_MMC), 0);
> + return max((blk_find_max_devnum(IF_TYPE_MMC) + 1), 0);
>  }
>  
>  int mmc_get_next_devnum(void)
> @@ -122,7 +122,7 @@ int mmc_get_next_devnum(void)
>   if (ret < 0)
>   return ret;
>  
> - return ret + 1;
> + return ret;
>  }
>  
>  struct blk_desc *mmc_get_blk_desc(struct mmc *mmc)
> diff --git a/include/mmc.h b/include/mmc.h
> index 8f309f1..4288e59 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -503,6 +503,12 @@ void mmc_set_clock(struct mmc *mmc, uint clock);
>  struct mmc *find_mmc_device(int dev_num);
>  int mmc_set_dev(int dev_num);
>  void print_mmc_devices(char separator);
> +
> +/**
> + * get_mmc_num() - get the total MMC device number
> + *
> + * @return number of MMC device
> + */

If you add the comment for get_mmc_num(), i think you need to mention that it 
has what means when return 0.

@return 0 if there is no MMC device, else the number of devices.

Best Regards,
Jaehoon Chung

>  int get_mmc_num(void);
>  int mmc_hwpart_config(struct mmc *mmc, const struct mmc_hwpart_conf *conf,
> enum mmc_hwpart_conf_mode mode);
> 

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

[U-Boot] [PATCH] mmc: fix the output format

[Ziyuan Xu]

It's nicer to see this:

=> mmc list
dwmmc@ff0c: 0
dwmmc@ff0f: 1 (eMMC)

than this:

=> mmc list
dwmmc@ff0c: 0dwmmc@ff0f: 1 (eMMC)

With the latter, it's much clearer which mmc devices are on.

Signed-off-by: Ziyuan Xu 
---

 drivers/mmc/mmc-uclass.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
index 38ced41..beebc70 100644
--- a/drivers/mmc/mmc-uclass.c
+++ b/drivers/mmc/mmc-uclass.c
@@ -169,7 +169,7 @@ void print_mmc_devices(char separator)
 
for (uclass_first_device(UCLASS_MMC, );
 dev;
-uclass_next_device()) {
+uclass_next_device(), first = false) {
struct mmc *m = mmc_get_mmc_dev(dev);
 
if (!first) {
-- 
1.9.1


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

Re: [U-Boot] [PATCH v2 5/9] mx7: set soc environment according to exact SoC type

[Tom Rini]

On Mon, Jul 18, 2016 at 07:19:05PM -0700, Stefan Agner wrote:
> On 2016-07-18 17:36, Tom Rini wrote:
> > On Mon, Jul 18, 2016 at 03:21:39PM -0700, Stefan Agner wrote:
> >> On 2016-07-18 15:19, Fabio Estevam wrote:
> >> > On Wed, Jul 13, 2016 at 4:25 AM, Stefan Agner  wrote:
> >> >> From: Stefan Agner 
> >> >>
> >> >> This can be useful if the same U-Boot binary is used for boards
> >> >> available with a i.MX 7Solo and i.MX 7Dual.
> >> >>
> >> >> Signed-off-by: Stefan Agner 
> >> >> Reviewed-by: Simon Glass 
> >> >> ---
> >> >>
> >> >>  arch/arm/cpu/armv7/mx7/soc.c | 14 ++
> >> >>  include/configs/mx7_common.h |  2 ++
> >> >>  2 files changed, 16 insertions(+)
> >> >>
> >> >> diff --git a/arch/arm/cpu/armv7/mx7/soc.c b/arch/arm/cpu/armv7/mx7/soc.c
> >> >> index ef46c92..dead1d3 100644
> >> >> --- a/arch/arm/cpu/armv7/mx7/soc.c
> >> >> +++ b/arch/arm/cpu/armv7/mx7/soc.c
> >> >> @@ -248,6 +248,20 @@ int arch_cpu_init(void)
> >> >> return 0;
> >> >>  }
> >> >>
> >> >> +#ifdef CONFIG_ARCH_MISC_INIT
> >> >> +int arch_misc_init(void)
> >> >> +{
> >> >> +#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
> >> >> +   if (is_mx7d())
> >> >> +   setenv("soc", "imx7d");
> >> >> +   else
> >> >> +   setenv("soc", "imx7s");
> >> >> +#endif
> >> >> +
> >> >> +   return 0;
> >> >> +}
> >> >> +#endif
> >> >
> >> > What about adding the following code in your board file?
> >> >
> >> > int board_late_init(void)
> >> > {
> >> > #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
> >> > if (is_mx7d())
> >> > setenv("board_rev", "MX7D");
> >> > else
> >> > setenv("board_rev", "MX7S");
> >> > #endif
> >> >
> >> > return 0;
> >> > }
> >> >
> >> > This was the suggestion I got from Tom when I was doing runtime SoC
> >> > detection for mx6cubox.
> >>
> >> I followed the runtime detection for Vybrid in:
> >> arch/arm/cpu/armv7/vf610/generic.c
> >>
> >> But sure, doing it at board level would be possible too.
> >>
> >> Due to the similarity of i.MX 7Solo and 7Dual there will probably be
> >> many board designs available in this two variants, hence I feel it would
> >> be worthwhile to have it on arch level...
> > 
> > So, yeah, I may have said the wrong thing for cubox, maybe not.  I think
> > that for the actual SoC (and 'soc') we should set that as high as we
> > easily and _correctly_ can.  We set 'board_rev' today in the board
> 
> Can I take this as an Ack from your side Tom?
> 
> Also note that the current default for i.MX 7 is "mx7" which is not
> useful to build the typically used (Linux) device tree file name. It
> also seems that no i.MX 6/7 board uses ${soc} in its default
> environment...
> 
> IMHO ${soc} should be the first part of the device tree file, which is
> in this case imx7d- (and imx7s-...)

Making ${soc} have the correct and useful value, when
CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG is set seems fine to me, yes.

> > files, and this makes sense to me, especially when used as the "board"
> > part, eg:
> > board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c: setenv("board_rev", 
> > "9X9");
> > board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c: setenv("board_rev", 
> > "14X14")
> > 
> > We set 'board_rev' today in a number of board files and a quick review
> > just now tells me that yes, we should have done that higher up.
> > Probably.  Using the mx6cubox example, I see:
> > static bool is_mx6q(void)
> > {
> > if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
> > return true;
> > 
> > Can we move this to global code, check for each of the MX6 variants, MX7
> > variants and always be returning what we return today?
> 
> What is board_rev commonly used for?
> 
> It sounds more board specific, so we certainly would have to have a way
> to overwrite it on board level (e.g. if somebody has two MX6Q SKUs?)

board_rev is really a board-specific variable, yes.  The most common use
of board_name / board_rev is to do shell logic to determine what the
devicetree to load is.

-- 
Tom


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

[U-Boot] [PATCH] board: ls1012aqds: Update LBMAP_MASK and RST_CTL_RESET

[Prabhakar Kushwaha]

qixis_reset altbank usagge ~QIXIS_LBMAP_MASK in code. So define
inverse value QIXIS_LBMAP_MASK.

Also, update QIXIS_RST_CTL_RESET value to keep RST_CTL[REQ_MOD]
as 0b11 i.e. PORESET during qixis_reset

Signed-off-by: Prabhakar Kushwaha 
---
 include/configs/ls1012aqds.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/ls1012aqds.h b/include/configs/ls1012aqds.h
index fcf402c..6e31ca0 100644
--- a/include/configs/ls1012aqds.h
+++ b/include/configs/ls1012aqds.h
@@ -28,11 +28,11 @@
 #define CONFIG_SYS_I2C_FPGA_ADDR   0x66
 #define QIXIS_LBMAP_BRDCFG_REG 0x04
 #define QIXIS_LBMAP_SWITCH 6
-#define QIXIS_LBMAP_MASK   0xf7
+#define QIXIS_LBMAP_MASK   0x08
 #define QIXIS_LBMAP_SHIFT  0
 #define QIXIS_LBMAP_DFLTBANK   0x00
 #define QIXIS_LBMAP_ALTBANK0x08
-#define QIXIS_RST_CTL_RESET0x41
+#define QIXIS_RST_CTL_RESET0x31
 #define QIXIS_RCFG_CTL_RECONFIG_IDLE   0x20
 #define QIXIS_RCFG_CTL_RECONFIG_START  0x21
 #define QIXIS_RCFG_CTL_WATCHDOG_ENBLE  0x08
-- 
1.9.1


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

[U-Boot] [PATCH 1/2] armv8: ls1012a: Enable DDR row-bank-column decoding

[Prabhakar Kushwaha]

Enable DDR row-bank-column decoding to decode DDR address as
row-bank-column instead of bank-row-column for improving 
performance of serial data transfers.

Signed-off-by: Calvin Johnson 
Signed-off-by: Prabhakar Kushwaha 
---
 include/fsl_mmdc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/fsl_mmdc.h b/include/fsl_mmdc.h
index 281a819..833696b 100644
--- a/include/fsl_mmdc.h
+++ b/include/fsl_mmdc.h
@@ -12,7 +12,7 @@
 #define CONFIG_SYS_MMDC_CORE_TIMING_CFG_1  0xff328f64
 #define CONFIG_SYS_MMDC_CORE_TIMING_CFG_2  0x01ff00db
 
-#define CONFIG_SYS_MMDC_CORE_MISC  0x0680
+#define CONFIG_SYS_MMDC_CORE_MISC  0x1680
 #define CONFIG_SYS_MMDC_PHY_MEASURE_UNIT   0x0800
 #define CONFIG_SYS_MMDC_CORE_RDWR_CMD_DELAY0x2000
 #define CONFIG_SYS_MMDC_PHY_ODT_CTRL   0x022a
-- 
1.9.1


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

[U-Boot] [PATCH v2 1/9] spi: zynq_qspi: Add quad support for zynq qspi

[Siva Durga Prasad Paladugu]

Add quad commands supports for zynq qspi driver

Signed-off-by: Siva Durga Prasad Paladugu 
---
 drivers/spi/zynq_qspi.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/spi/zynq_qspi.c b/drivers/spi/zynq_qspi.c
index b98663c..e636244 100644
--- a/drivers/spi/zynq_qspi.c
+++ b/drivers/spi/zynq_qspi.c
@@ -11,7 +11,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include "../mtd/spi/sf_internal.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -156,6 +158,17 @@ static void zynq_qspi_init_hw(struct zynq_qspi_priv *priv)
writel(ZYNQ_QSPI_ENR_SPI_EN_MASK, >enr);
 }
 
+static int zynq_qspi_child_pre_probe(struct udevice *bus)
+{
+   struct spi_slave *slave = dev_get_parent_priv(bus);
+
+   slave->mode_rx = QUAD_OUTPUT_FAST;
+   slave->mode = SPI_TX_QUAD;
+   slave->no_all_quad = 1;
+
+   return 0;
+}
+
 static int zynq_qspi_probe(struct udevice *bus)
 {
struct zynq_qspi_platdata *plat = dev_get_platdata(bus);
@@ -627,4 +640,5 @@ U_BOOT_DRIVER(zynq_qspi) = {
.platdata_auto_alloc_size = sizeof(struct zynq_qspi_platdata),
.priv_auto_alloc_size = sizeof(struct zynq_qspi_priv),
.probe  = zynq_qspi_probe,
+   .child_pre_probe = zynq_qspi_child_pre_probe,
 };
-- 
2.7.4

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

[U-Boot] [PATCH v2 3/9] sf: Kconfig: Add SF_DUAL_FLASH config entry

[Siva Durga Prasad Paladugu]

Add SF_DUAL_FLASH config entry with help description
This is needed to support dual parallel and stacked
modes.

Signed-off-by: Siva Durga Prasad Paladugu 
---
 drivers/mtd/spi/Kconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
index 1f23c8e..be5fb78 100644
--- a/drivers/mtd/spi/Kconfig
+++ b/drivers/mtd/spi/Kconfig
@@ -128,6 +128,14 @@ config SPI_FLASH_MTD
 
  If unsure, say N
 
+config SF_DUAL_FLASH
+   bool "SPI Flash Dual support"
+   depends on SPI_FLASH
+   help
+ Enables the dual modes support for spi flash layer, this is required
+ to handle dual parallel and stacked modes during sf read, write and
+ erase ops.
+
 if SPL
 
 config SPL_SPI_SUNXI
-- 
2.7.4

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

[U-Boot] [PATCH v2 2/9] spi: zynq_qspi: Add support of Dual parallel and Dual stacked modes

[Siva Durga Prasad Paladugu]

Add Dual parallel and dual stacked supports for zynq
qspi driver. The is-dual property defines the dual
parallel mode and num-cs, numbere of chip selects
defines dual stacked mode if its value is 2

Signed-off-by: Siva Durga Prasad Paladugu 
---
 drivers/spi/zynq_qspi.c | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/drivers/spi/zynq_qspi.c b/drivers/spi/zynq_qspi.c
index e636244..44057ba 100644
--- a/drivers/spi/zynq_qspi.c
+++ b/drivers/spi/zynq_qspi.c
@@ -52,6 +52,10 @@ DECLARE_GLOBAL_DATA_PTR;
 #define CONFIG_SYS_ZYNQ_QSPI_WAIT  CONFIG_SYS_HZ/100   /* 10 ms */
 #endif
 
+#define ZYNQ_QSPI_LCR_TWO_MEM_MASK BIT(30) /* QSPI Enable Bit Mask */
+#define ZYNQ_QSPI_LCR_SEP_BUS_MASK BIT(29) /* QSPI Enable Bit Mask */
+#define ZYNQ_QSPI_LCR_U_PAGE   BIT(28) /* QSPI Upper memory set */
+
 /* zynq qspi register set */
 struct zynq_qspi_regs {
u32 cr; /* 0x00 */
@@ -96,6 +100,8 @@ struct zynq_qspi_priv {
int bytes_to_transfer;
int bytes_to_receive;
unsigned int is_inst;
+   unsigned int is_dual;
+   unsigned int u_page;
unsigned cs_change:1;
 };
 
@@ -154,6 +160,14 @@ static void zynq_qspi_init_hw(struct zynq_qspi_priv *priv)
confr &= ~ZYNQ_QSPI_LQSPICFG_LQMODE_MASK;
writel(confr, >lqspicfg);
 
+   if (priv->is_dual == SF_DUAL_PARALLEL_FLASH)
+   writel(ZYNQ_QSPI_LCR_TWO_MEM_MASK |
+   ZYNQ_QSPI_LCR_SEP_BUS_MASK,
+   >lqspicfg);
+   else if (priv->is_dual == SF_DUAL_STACKED_FLASH)
+   writel(ZYNQ_QSPI_LCR_TWO_MEM_MASK,
+  >lqspicfg);
+
/* Enable SPI */
writel(ZYNQ_QSPI_ENR_SPI_EN_MASK, >enr);
 }
@@ -161,7 +175,9 @@ static void zynq_qspi_init_hw(struct zynq_qspi_priv *priv)
 static int zynq_qspi_child_pre_probe(struct udevice *bus)
 {
struct spi_slave *slave = dev_get_parent_priv(bus);
+   struct zynq_qspi_priv *priv = dev_get_priv(bus->parent);
 
+   slave->option = priv->is_dual;
slave->mode_rx = QUAD_OUTPUT_FAST;
slave->mode = SPI_TX_QUAD;
slave->no_all_quad = 1;
@@ -173,10 +189,23 @@ static int zynq_qspi_probe(struct udevice *bus)
 {
struct zynq_qspi_platdata *plat = dev_get_platdata(bus);
struct zynq_qspi_priv *priv = dev_get_priv(bus);
+   const void *blob = gd->fdt_blob;
+   int node = bus->of_offset;
+   u8 is_dual = 0;
+   u8 num_cs = 0;
 
priv->regs = plat->regs;
priv->fifo_depth = ZYNQ_QSPI_FIFO_DEPTH;
 
+   is_dual = fdtdec_get_int(blob, node, "is-dual", 0);
+   if (is_dual) {
+   priv->is_dual = SF_DUAL_PARALLEL_FLASH;
+   } else {
+   num_cs = fdtdec_get_int(blob, node, "num-cs", 1);
+   if (num_cs == 2)
+   priv->is_dual = SF_DUAL_STACKED_FLASH;
+   }
+
/* init the zynq spi hw */
zynq_qspi_init_hw(priv);
 
@@ -437,6 +466,7 @@ static int zynq_qspi_irq_poll(struct zynq_qspi_priv *priv)
  */
 static int zynq_qspi_start_transfer(struct zynq_qspi_priv *priv)
 {
+   static u8 current_u_page;
u32 data = 0;
struct zynq_qspi_regs *regs = priv->regs;
 
@@ -446,6 +476,18 @@ static int zynq_qspi_start_transfer(struct zynq_qspi_priv 
*priv)
priv->bytes_to_transfer = priv->len;
priv->bytes_to_receive = priv->len;
 
+   if (priv->is_inst && (priv->is_dual == SF_DUAL_STACKED_FLASH) &&
+   (current_u_page != priv->u_page)) {
+   if (priv->u_page)
+   writel(ZYNQ_QSPI_LCR_TWO_MEM_MASK |
+   ZYNQ_QSPI_LCR_U_PAGE,
+   >lqspicfg);
+   else
+   writel(ZYNQ_QSPI_LCR_TWO_MEM_MASK,
+  >lqspicfg);
+   current_u_page = priv->u_page;
+   }
+
if (priv->len < 4)
zynq_qspi_fill_tx_fifo(priv, priv->len);
else
@@ -555,6 +597,11 @@ static int zynq_qspi_xfer(struct udevice *dev, unsigned 
int bitlen,
else
priv->cs_change = 0;
 
+   if (flags & SPI_XFER_U_PAGE)
+   priv->u_page = 1;
+   else
+   priv->u_page = 0;
+
zynq_qspi_transfer(priv);
 
return 0;
-- 
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/9] qspi: Add Quad and Dual mode support for Zynq QSPI

[Siva Durga Prasad Paladugu]

This series enables the Quad and dual modes support
for zynq. It also contains fixes for issues found
during testing of dual parallel and stacked modes.

Siva Durga Prasad Paladugu (9):
  spi: zynq_qspi: Add quad support for zynq qspi
  spi: zynq_qspi: Add support of Dual parallel and Dual stacked modes
  sf: Kconfig: Add SF_DUAL_FLASH config entry
  dts: zynq_zc706: update qspi node with is-dual and num-cs
  defconfig: zc706: Add dual modes support for zc706
  spi: spi_flash: Correct flash size calculation
  spi: spi_flash: Correct bank select incase of dual stacked
  spi: spi_flash: Fix Bank selection calculation for Dual parallel
  spi: spi_flash: Set Quad enable bit of upper flash

 arch/arm/dts/zynq-zc706.dts  |  2 ++
 configs/zynq_zc706_defconfig |  1 +
 drivers/mtd/spi/Kconfig  |  8 ++
 drivers/mtd/spi/spi_flash.c  | 54 +++
 drivers/spi/zynq_qspi.c  | 61 
 include/spi_flash.h  |  1 +
 6 files changed, 117 insertions(+), 10 deletions(-)

-- 
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/9] dts: zynq_zc706: update qspi node with is-dual and num-cs

[Siva Durga Prasad Paladugu]

Update qspi node with properties is-dual and num-cs
QSPI flash devices on zc706 connected in dual paralle mode
hence is-dual is 1 and num-cs is 1.
The property is-dual expalins the dual parallel connection mode
The property num-cs defines number of chip selects whose value
is 1 incase of dual parllel connection

Signed-off-by: Siva Durga Prasad Paladugu 
---
 arch/arm/dts/zynq-zc706.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/dts/zynq-zc706.dts b/arch/arm/dts/zynq-zc706.dts
index d04880a..ee58128 100644
--- a/arch/arm/dts/zynq-zc706.dts
+++ b/arch/arm/dts/zynq-zc706.dts
@@ -309,6 +309,8 @@
  {
u-boot,dm-pre-reloc;
status = "okay";
+   is-dual = <1>;
+   num-cs = <1>;
 };
 
  {
-- 
2.7.4

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

Re: [U-Boot] [PATCH] mmc: fix the output format

[Jaehoon Chung]

Hi Ziyuan,

On 07/19/2016 07:14 PM, Ziyuan Xu wrote:
> It's nicer to see this:
> 
> => mmc list
> dwmmc@ff0c: 0
> dwmmc@ff0f: 1 (eMMC)
> 
> than this:
> 
> => mmc list
> dwmmc@ff0c: 0dwmmc@ff0f: 1 (eMMC)
> 
> With the latter, it's much clearer which mmc devices are on.

You're right. After applied your patch, it may display like mmc-legacy type.
If add the comment in more detail, 
How about "Display mmc list information like mmc-legacy type." ? :)

Best Regards,
Jaehoon Chung

> 
> Signed-off-by: Ziyuan Xu 
> ---
> 
>  drivers/mmc/mmc-uclass.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index 38ced41..beebc70 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -169,7 +169,7 @@ void print_mmc_devices(char separator)
>  
>   for (uclass_first_device(UCLASS_MMC, );
>dev;
> -  uclass_next_device()) {
> +  uclass_next_device(), first = false) {
>   struct mmc *m = mmc_get_mmc_dev(dev);
>  
>   if (!first) {
> 

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

[U-Boot] [PATCH] cmd: misc: Add support for fractions in sleep

[Mario Six]

A feasible way to communicate certain errors for devices that have no
other way of signalling besides LEDs is to flash these LEDs. For errors
in U-Boot, a script that utilizes the led and sleep commands would be a
practicable way, but currently the sleep command can only delay for an
integral amount of seconds, which is too slow to create an easily
noticeable pattern for flashing LEDs.

Therefore, this patch adds support for fractions (down to .001 seconds)
to the sleep command.

The parsing is kept minimal, simplistic and as robust as possible: After
converting the passed string using simple_strtoul and multiplying it
with 1000, we search for the first dot, convert the three characters
after that into a number (if they are not numbers, we ignore the
fractional part and just use the delay we got from simple_strtoul), and
add this number to the delay.

Signed-off-by: Mario Six 
---
 cmd/misc.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/cmd/misc.c b/cmd/misc.c
index 39d8683..efcbb90 100644
--- a/cmd/misc.c
+++ b/cmd/misc.c
@@ -15,13 +15,31 @@
 static int do_sleep(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
ulong start = get_timer(0);
+   ulong mdelay = 0;
ulong delay;
+   char *frpart;
 
if (argc != 2)
return CMD_RET_USAGE;
 
delay = simple_strtoul(argv[1], NULL, 10) * CONFIG_SYS_HZ;
 
+   frpart = strchr(argv[1], '.');
+
+   if (frpart) {
+   uint mult = CONFIG_SYS_HZ / 10;
+   for (frpart++; *frpart != '\0' && mult > 0; frpart++) {
+   if (*frpart < '0' || *frpart > '9') {
+   mdelay = 0;
+   break;
+   }
+   mdelay += (*frpart - '0') * mult;
+   mult /= 10;
+   }
+   }
+
+   delay += mdelay;
+
while (get_timer(start) < delay) {
if (ctrlc())
return (-1);
@@ -36,7 +54,8 @@ U_BOOT_CMD(
sleep ,2,1, do_sleep,
"delay execution for some time",
"N\n"
-   "- delay execution for N seconds (N is _decimal_ !!!)"
+   "- delay execution for N seconds (N is _decimal_ and can be\n"
+   "  fractional)"
 );
 
 #ifdef CONFIG_CMD_TIMER
-- 
2.9.0

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

[U-Boot] [PATCH v2] mmc: display mmc list information like mmc_legacy type

[Ziyuan Xu]

From: Xu Ziyuan 

It's nicer to see this:

=> mmc list
dwmmc@ff0c: 0
dwmmc@ff0f: 1 (eMMC)

than this:

=> mmc list
dwmmc@ff0c: 0dwmmc@ff0f: 1 (eMMC)

With the latter, it's much clearer which mmc devices are on.

Signed-off-by: Ziyuan Xu 

Serise-changes: 2
- Update commit from Jaehoon

Signed-off-by: Ziyuan Xu 
---

 drivers/mmc/mmc-uclass.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
index 38ced41..beebc70 100644
--- a/drivers/mmc/mmc-uclass.c
+++ b/drivers/mmc/mmc-uclass.c
@@ -169,7 +169,7 @@ void print_mmc_devices(char separator)
 
for (uclass_first_device(UCLASS_MMC, );
 dev;
-uclass_next_device()) {
+uclass_next_device(), first = false) {
struct mmc *m = mmc_get_mmc_dev(dev);
 
if (!first) {
-- 
1.9.1


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

Re: [U-Boot] [PATCH v2 5/9] mx7: set soc environment according to exact SoC type

[Stefano Babic]

Hi Fabio,

On 19/07/2016 16:06, Fabio Estevam wrote:
> Hi Stefano,
> 
> On Tue, Jul 19, 2016 at 10:59 AM, Stefano Babic  wrote:
> 
>> We have already a global code, rather there are some boards (cubox, but
>> also cgtqmx6eval) with own function.
>>
>> All is_mx6X() macros / functions are in
>> arch/arm/include/asm/imx-common/sys_proto.h. The function can be
>> replaced by is_mx6dq() from sysproto.h
> 
> Yes, I will send a patch converting these boards to use the common
> is_mx6 common macros.

Thanks !!

Regards,
Stefano


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot: x86: interrupt mapping

[Christian Gmeiner]

Hi Jian,

>
> For the moment I have no answer to this question. I need to dive into
> the vxworks code, which
> is not what I like to do now (but needs to be done)-
>
> Yes, please do track it down. The interrupt line register configured
> by U-Boot should be enough for VxWorks to function under PIC mode.
>
> I have an other (wired) question you may could help out.
>
> http://www.mouser.com/pdfdocs/Intel_Platform_Controller_Hub_EG20T_datasheet.pdf
> (page 124)
>
> On my development board the uart_clk is connected to a oscillator and
> everything works as expected.
> But on the production devices the uart_clk is not connected and fsp
> hangs with post code 0x2e.
>
> I am not sure about the meaning of post code 0x2e. Jian has some
> working experience on Atom E6xx with U-Boot. Adding him.
>
> 0x2e == POST_PRE_MRC (arch/x86/include/asm/post.h)
>
> Now I would like to change the initial mux settings to use usb_48mhz
> but I am quite sure that I need
> to have the pci bus and its devices initialised already in order to
> change the CLKCFG register. Do you
> think there is an other way of accessing this register like fixed
> memory address etc?
>
> Which register do you want to program for this uart_clk? If it's on
> the PCI configuration space, you can use PCI config APIs to program.
>
> There a handful of registers I would need to program but all of them are
> accessible via pic config space. E.g CLKCFG:
>
> Size: 32-bit Default: 2C00 Power Well: Core
> Access PCI Configuration B:D:F D0:F0 Offset Start: Offset End: 500h 503h
> Memory Mapped I/O BAR: PKTHubCTLBASE Offset: 500h
>
>
> As I need to program those registers before fsp_init I must setup the pci
> bus by myself, change the register values and call fsb_init routine.
> Correct?
>
> My board had this problem too. I however toke a different approach
> by patching the original FSP. The waiting for Topcliff UART ready is
> completely
> bypassed in all UEFI blobs. You can use UEFITool [1] to extract blobs in
> the attached FSP for comparison.
>

Sooo... I did use the UEFITool to compare your fsp with mine and yeah...
some files are different.

File_Raw_06A70056_3D0F_4A94_A743_5491CC9391D3_body.bin
Section_PE32_image_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_body.bin
Section_PE32_image_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_header.bin
Section_PE32_image_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_body.bin
Section_PE32_image_74D3B506_EE9C_47ED_B749_41261401DA78_TCInitDxe_body.bin
Section_TE_image_1BA0062E_C779_4582_8566_336AE8F78F09_Volume_Top_File_body.bin
Section_TE_image_52C05B14_0B98_496C_BC3B_04B50211D680_PeiCore_body.bin
Section_TE_image_86D70125_BAA3_4296_A62F_602BEBBB9081_DxeIpl_body.bin
Section_TE_image_9618C0DC_50A4_496C_994F_7241F282ED01_PlatformEarlyInit_body.bin
Section_TE_image_9B3ADA4F_AE56_4C24_8DEA_F03B7558AE50_PcdPeim_body.bin
Section_TE_image_D2C69B26_82E1_4A1B_AD35_ED0261B9F347_MemoryInitPei_body.bin
File_PEI_module_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_info.txt
File_PEI_module_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_info.txt
File_PEI_module_74D3B506_EE9C_47ED_B749_41261401DA78_TCInitDxe_info.txt
Section_Compressed_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_info.txt
Section_Compressed_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_info.txt
Section_Compressed_74D3B506_EE9C_47ED_B749_41261401DA78_TCInitDxe_info.txt
Section_PE32_image_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_info.txt
Section_PEI_dependency_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_info.txt
Section_PEI_dependency_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_info.txt

Any hint at what to look for? Sadly I am not an UEFI guy.

greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 9/9] colibri_imx7: add Colibri iMX7S/iMX7D module support

[Stefano Babic]

Hi Stefan,


just a couple of minor things:


On 13/07/2016 09:25, Stefan Agner wrote:
> From: Stefan Agner 
> 
> This commit adds support for the Toradex Computer on Modules
> Colibri iMX7S/iMX7D. The two modules/SoC's are very similar hence
> can be easily supported by one board. The board code detects RAM
> size at runtime which is one of the differences between the two
> boards. The board also uses the UART's in DTE mode, hence making
> use of the new DTE support via serial DM.
> 
> Signed-off-by: Stefan Agner 
> ---
> 
>  arch/arm/cpu/armv7/mx7/Kconfig|   7 +
>  board/toradex/colibri_imx7/Kconfig|  12 +
>  board/toradex/colibri_imx7/MAINTAINERS|   6 +
>  board/toradex/colibri_imx7/Makefile   |   6 +
>  board/toradex/colibri_imx7/colibri_imx7.c | 420 
> ++
>  board/toradex/colibri_imx7/imximage.cfg   | 150 +++
>  configs/colibri_imx7_defconfig|  40 +++
>  include/configs/colibri_imx7.h| 248 ++
>  8 files changed, 889 insertions(+)
>  create mode 100644 board/toradex/colibri_imx7/Kconfig
>  create mode 100644 board/toradex/colibri_imx7/MAINTAINERS
>  create mode 100644 board/toradex/colibri_imx7/Makefile
>  create mode 100644 board/toradex/colibri_imx7/colibri_imx7.c
>  create mode 100644 board/toradex/colibri_imx7/imximage.cfg
>  create mode 100644 configs/colibri_imx7_defconfig
>  create mode 100644 include/configs/colibri_imx7.h
> 
> diff --git a/arch/arm/cpu/armv7/mx7/Kconfig b/arch/arm/cpu/armv7/mx7/Kconfig
> index dd51384..5fdc8dd 100644
> --- a/arch/arm/cpu/armv7/mx7/Kconfig
> +++ b/arch/arm/cpu/armv7/mx7/Kconfig
> @@ -27,12 +27,19 @@ config TARGET_WARP7
>   select DM
>   select DM_THERMAL
>  
> +config TARGET_COLIBRI_IMX7
> + bool "Support Colibri iMX7S/iMX7D modules"
> + select DM
> + select DM_SERIAL
> + select DM_THERMAL
> +
>  endchoice
>  
>  config SYS_SOC
>   default "mx7"
>  
>  source "board/freescale/mx7dsabresd/Kconfig"
> +source "board/toradex/colibri_imx7/Kconfig"
>  source "board/warp7/Kconfig"
>  
>  endif
> diff --git a/board/toradex/colibri_imx7/Kconfig 
> b/board/toradex/colibri_imx7/Kconfig
> new file mode 100644
> index 000..622ce66
> --- /dev/null
> +++ b/board/toradex/colibri_imx7/Kconfig
> @@ -0,0 +1,12 @@
> +if TARGET_COLIBRI_IMX7
> +
> +config SYS_BOARD
> + default "colibri_imx7"
> +
> +config SYS_VENDOR
> + default "toradex"
> +
> +config SYS_CONFIG_NAME
> + default "colibri_imx7"
> +
> +endif
> diff --git a/board/toradex/colibri_imx7/MAINTAINERS 
> b/board/toradex/colibri_imx7/MAINTAINERS
> new file mode 100644
> index 000..5ffb241
> --- /dev/null
> +++ b/board/toradex/colibri_imx7/MAINTAINERS
> @@ -0,0 +1,6 @@
> +Colibri iMX7
> +M:   Stefan Agner 
> +S:   Maintained
> +F:   board/toradex/colibri_imx7/
> +F:   include/configs/colibri_imx7.h
> +F:   configs/colibri_imx7_defconfig

I wonder we never add imximage.cfg into the MAINTAINERS. Boards with SPL
have a central and empty imximage.cfg, for the other ones we should add
it to the list. (Note: I have currently seen that no board having its
own imximage.cfg does not list it in the MAINTAINERS file).

> diff --git a/board/toradex/colibri_imx7/Makefile 
> b/board/toradex/colibri_imx7/Makefile
> new file mode 100644
> index 000..ea597de
> --- /dev/null
> +++ b/board/toradex/colibri_imx7/Makefile
> @@ -0,0 +1,6 @@
> +# Copyright (C) 2016 Toradex AG
> +#
> +# SPDX-License-Identifier:   GPL-2.0+
> +#
> +
> +obj-y  := colibri_imx7.o
> diff --git a/board/toradex/colibri_imx7/colibri_imx7.c 
> b/board/toradex/colibri_imx7/colibri_imx7.c
> new file mode 100644
> index 000..b36f580
> --- /dev/null
> +++ b/board/toradex/colibri_imx7/colibri_imx7.c
> @@ -0,0 +1,420 @@
> +/*
> + * Copyright (C) 2016 Toradex AG
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#define UART_PAD_CTRL  (PAD_CTL_DSE_3P3V_49OHM | \
> + PAD_CTL_PUS_PU100KOHM | PAD_CTL_HYS)
> +
> +#define USDHC_PAD_CTRL (PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
> + PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU47KOHM)
> +
> +#define ENET_PAD_CTRL  (PAD_CTL_PUS_PU100KOHM | PAD_CTL_DSE_3P3V_49OHM)
> +#define ENET_PAD_CTRL_MII  (PAD_CTL_DSE_3P3V_32OHM)
> +
> +#define ENET_RX_PAD_CTRL  (PAD_CTL_PUS_PU100KOHM | PAD_CTL_DSE_3P3V_49OHM)
> +
> +#define I2C_PAD_CTRL(PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
> + PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU100KOHM)
> +
> +#define LCD_PAD_CTRL(PAD_CTL_HYS | PAD_CTL_PUS_PU100KOHM | \
> + PAD_CTL_DSE_3P3V_49OHM)
> +
> +#define NAND_PAD_CTRL (PAD_CTL_DSE_3P3V_49OHM | 

[U-Boot] [tiU16.05 PATCH v1] keystone: k2h/e/l: Fix DMA coherency for QM PDSP

[Murali Karicheri]

commit 1f807a9f32aa ("ARM: keystone2: Refactor MSMC macros to avoid
left under a macro KS2_MSMC_SEGMENT_QM_PDSP which is no longer valid.
This, in effect disabled DMA coherency for QM PDSP.

Given that msmc_k2hkle_common_setup is valid for all K2H/K/L/E SoCs,
the #ifdef should been removed in the first place. Do the same.

Fixes: 1f807a9f32aa ("ARM: keystone2: Refactor MSMC macros to avoid #ifdeffery")
Signed-off-by: Murali Karicheri 
Acked-by: Nishanth Menon 
Reviewed-by: Tom Rini 
---
 - v2 - adding Fixes per comments
 arch/arm/mach-keystone/init.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-keystone/init.c b/arch/arm/mach-keystone/init.c
index 3b6d5ef..6e5a1e1 100644
--- a/arch/arm/mach-keystone/init.c
+++ b/arch/arm/mach-keystone/init.c
@@ -101,9 +101,7 @@ static void msmc_k2hkle_common_setup(void)
msmc_share_all_segments(KS2_MSMC_SEGMENT_C6X_0);
msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_ARM);
msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_NETCP);
-#ifdef KS2_MSMC_SEGMENT_QM_PDSP
msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_QM_PDSP);
-#endif
msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_PCIE0);
msmc_share_all_segments(KS2_MSMC_SEGMENT_DEBUG);
 }
-- 
1.9.1

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

Re: [U-Boot] [PATCH v2 9/9] colibri_imx7: add Colibri iMX7S/iMX7D module support

[Stefan Agner]

On 2016-07-19 07:14, Stefano Babic wrote:
> Hi Stefan,
> 
> 
> just a couple of minor things:
> 
> 
> On 13/07/2016 09:25, Stefan Agner wrote:
>> From: Stefan Agner 
>>
>> This commit adds support for the Toradex Computer on Modules
>> Colibri iMX7S/iMX7D. The two modules/SoC's are very similar hence
>> can be easily supported by one board. The board code detects RAM
>> size at runtime which is one of the differences between the two
>> boards. The board also uses the UART's in DTE mode, hence making
>> use of the new DTE support via serial DM.
>>
>> Signed-off-by: Stefan Agner 
>> ---
>>
>>  arch/arm/cpu/armv7/mx7/Kconfig|   7 +
>>  board/toradex/colibri_imx7/Kconfig|  12 +
>>  board/toradex/colibri_imx7/MAINTAINERS|   6 +
>>  board/toradex/colibri_imx7/Makefile   |   6 +
>>  board/toradex/colibri_imx7/colibri_imx7.c | 420 
>> ++
>>  board/toradex/colibri_imx7/imximage.cfg   | 150 +++
>>  configs/colibri_imx7_defconfig|  40 +++
>>  include/configs/colibri_imx7.h| 248 ++
>>  8 files changed, 889 insertions(+)
>>  create mode 100644 board/toradex/colibri_imx7/Kconfig
>>  create mode 100644 board/toradex/colibri_imx7/MAINTAINERS
>>  create mode 100644 board/toradex/colibri_imx7/Makefile
>>  create mode 100644 board/toradex/colibri_imx7/colibri_imx7.c
>>  create mode 100644 board/toradex/colibri_imx7/imximage.cfg
>>  create mode 100644 configs/colibri_imx7_defconfig
>>  create mode 100644 include/configs/colibri_imx7.h
>>
>> diff --git a/arch/arm/cpu/armv7/mx7/Kconfig b/arch/arm/cpu/armv7/mx7/Kconfig
>> index dd51384..5fdc8dd 100644
>> --- a/arch/arm/cpu/armv7/mx7/Kconfig
>> +++ b/arch/arm/cpu/armv7/mx7/Kconfig
>> @@ -27,12 +27,19 @@ config TARGET_WARP7
>>  select DM
>>  select DM_THERMAL
>>
>> +config TARGET_COLIBRI_IMX7
>> +bool "Support Colibri iMX7S/iMX7D modules"
>> +select DM
>> +select DM_SERIAL
>> +select DM_THERMAL
>> +
>>  endchoice
>>
>>  config SYS_SOC
>>  default "mx7"
>>
>>  source "board/freescale/mx7dsabresd/Kconfig"
>> +source "board/toradex/colibri_imx7/Kconfig"
>>  source "board/warp7/Kconfig"
>>
>>  endif
>> diff --git a/board/toradex/colibri_imx7/Kconfig 
>> b/board/toradex/colibri_imx7/Kconfig
>> new file mode 100644
>> index 000..622ce66
>> --- /dev/null
>> +++ b/board/toradex/colibri_imx7/Kconfig
>> @@ -0,0 +1,12 @@
>> +if TARGET_COLIBRI_IMX7
>> +
>> +config SYS_BOARD
>> +default "colibri_imx7"
>> +
>> +config SYS_VENDOR
>> +default "toradex"
>> +
>> +config SYS_CONFIG_NAME
>> +default "colibri_imx7"
>> +
>> +endif
>> diff --git a/board/toradex/colibri_imx7/MAINTAINERS 
>> b/board/toradex/colibri_imx7/MAINTAINERS
>> new file mode 100644
>> index 000..5ffb241
>> --- /dev/null
>> +++ b/board/toradex/colibri_imx7/MAINTAINERS
>> @@ -0,0 +1,6 @@
>> +Colibri iMX7
>> +M:  Stefan Agner 
>> +S:  Maintained
>> +F:  board/toradex/colibri_imx7/
>> +F:  include/configs/colibri_imx7.h
>> +F:  configs/colibri_imx7_defconfig
> 
> I wonder we never add imximage.cfg into the MAINTAINERS. Boards with SPL
> have a central and empty imximage.cfg, for the other ones we should add
> it to the list. (Note: I have currently seen that no board having its
> own imximage.cfg does not list it in the MAINTAINERS file).
> 

I added the directory where imximage.cfg is located in
(board/toradex/colibri_imx7/). We also don't add other files in there, I
think the scripts work fine with directories specified without
specifying the individual files...


>> diff --git a/board/toradex/colibri_imx7/Makefile 
>> b/board/toradex/colibri_imx7/Makefile
>> new file mode 100644
>> index 000..ea597de
>> --- /dev/null
>> +++ b/board/toradex/colibri_imx7/Makefile
>> @@ -0,0 +1,6 @@
>> +# Copyright (C) 2016 Toradex AG
>> +#
>> +# SPDX-License-Identifier:  GPL-2.0+
>> +#
>> +
>> +obj-y  := colibri_imx7.o
>> diff --git a/board/toradex/colibri_imx7/colibri_imx7.c 
>> b/board/toradex/colibri_imx7/colibri_imx7.c
>> new file mode 100644
>> index 000..b36f580
>> --- /dev/null
>> +++ b/board/toradex/colibri_imx7/colibri_imx7.c
>> @@ -0,0 +1,420 @@
>> +/*
>> + * Copyright (C) 2016 Toradex AG
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +#define UART_PAD_CTRL  (PAD_CTL_DSE_3P3V_49OHM | \
>> +PAD_CTL_PUS_PU100KOHM | PAD_CTL_HYS)
>> +
>> +#define USDHC_PAD_CTRL (PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
>> +PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU47KOHM)
>> +
>> +#define ENET_PAD_CTRL  (PAD_CTL_PUS_PU100KOHM | PAD_CTL_DSE_3P3V_49OHM)
>> +#define ENET_PAD_CTRL_MII  

Re: [U-Boot] [PATCH 2/2] fs/fat/fat: Optimizes memory size with single global variable instead of 3

[Stephen Warren]

On 07/18/2016 09:53 PM, Tien Fong Chee wrote:

On Fri, 2016-07-15 at 01:37 +0200, Benoît Thébaudeau wrote:

Dear Tien Fong,

On Thu, Jul 14, 2016 at 12:48 PM, Tien Fong Chee 
wrote:

Dear Benoît,

On Wed, 2016-07-13 at 12:56 +0200, Benoît Thébaudeau wrote:

Dear Tien Fong Chee,

On Jul 13, 2016 at 11:01 AM, Tien Fong Chee wrote:

Single 64KB get_contents_vfatname_block global variable would
be
used for
all FAT implementation instead of allocating additional two
global
variables
which are get_denfromdir_block and do_fat_read_at_block. This
implementation
can help in saving up 128KB memory space.

Signed-off-by: Tien Fong Chee 
Cc: Dinh Nguyen 
Cc: Dinh Nguyen 
Cc: ChinLiang 
Cc: Vagrant Cascadian 
Cc: Simon Glass 
Cc: Stephen Warren 
Cc: Benoît Thébaudeau 
---
  fs/fat/fat.c |6 ++
  1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 826bd85..5d1afe6 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -579,8 +579,7 @@ static __u8 mkcksum(const char name[8],
const
char ext[3])
   * Get the directory entry associated with 'filename' from the
directory
   * starting at 'startsect'
   */
-__u8 get_dentfromdir_block[MAX_CLUSTSIZE]
-   __aligned(ARCH_DMA_MINALIGN);
+__u8 *get_dentfromdir_block = get_contents_vfatname_block;

  static dir_entry *get_dentfromdir(fsdata *mydata, int
startsect,
   char *filename, dir_entry
*retdent,
@@ -811,8 +810,7 @@ exit:
 return ret;
  }

-__u8 do_fat_read_at_block[MAX_CLUSTSIZE]
-   __aligned(ARCH_DMA_MINALIGN);
+__u8 *do_fat_read_at_block = get_contents_vfatname_block;

  int do_fat_read_at(const char *filename, loff_t pos, void
*buffer,
loff_t maxsize, int dols, int dogetsize, loff_t
*size)


This probably breaks at least fat_write.c, which uses:
   memcpy(get_dentfromdir_block, get_contents_vfatname_block,


With this patch, this line code "memcpy(get_dentfromdir_block,
get_contents_vfatname_block," is not required anymore since both
  get_dentfromdir_block and get_contents_vfatname_block are sharing
the
same content and memory. So, this line code can be removed or
leaving
in there. However, there is only one place within
fill_dir_slot_buffer
function where it can corrupt the the global memory, and it is
fixed by
replacing with local buffer. This was sent out with another patch
called "[PATCH 1/2] fs/fat/fatwrite: Local variable as buffer to
store
dir_slot entries". Overall, applying these two patches, a lot
memory
space can be saved and fitting into small OCRAM, but need to be
very
careful when modifying the code related to global memory.


I get the point, but I am a bit concerned because these changes make
the code even more fragile and hard to maintain than it currently is.

Yeah, i agree with you, and there is trade-off in saving the memory
space.

Perhaps it would be time to switch to FatFs as previously suggested.
Here is its memory usage:
http://elm-chan.org/fsw/ff/en/appnote.html#memory


Cool. If i am not mistaken, this implementation would impact a lot of
areas, especially interface level. What's about the testing? I am still
voting for this simple patch changes, until we have enough resources to
do the switching.


I think switching to the FF library is a non-starter. It's 
excruciatingly slow since it always reads even contiguous files one 
cluster at a time. I did propose a change to the library, but the 
maintainer didn't seem interested in fixing the problem. If we were to 
switch, the Tianocore implementation might be worth looking at, now 
they've fixed the license of the FAT code to remove the requirement that 
it only be used in EFI implementations. I haven't looked the code to 
know whether it'd be possible/good to switch though.

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

Re: [U-Boot] [PATCH 1/5] fsl: serdes: ensure accessing the initialized maps of serdes protocol

[york sun]

On 07/03/2016 11:39 PM, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
>
> Up to now, the function is_serdes_configed() doesn't check if the map
> of serdes protocol is initialized before accessing it. The function
> is_serdes_configed() will get wrong result when it was called before
> the serdes protocol maps initialized. As the first eliment of the map

s/eliment/element

> isn't used for any device, so use it as the flag to indicate if the
> map has been initialized.

I am not sure it is safe to presume the first element is always not 
used. Take LS2080A as an example, the serdes map array is initialized by 
serdes_init(), which calls serdes_get_prtcl() to get the index of the 
array. With normal condition, the index shouldn't be zero. Zero is used 
as an error but it is not checked before setting

serdes_prtcl_map[lane_prtcl] = 1;

If you presumption is correct, and you want to use the first one as a 
flag, you probably need to check all of them to make sure errors are 
handled correctly, instead of setting the flag unexpected. Also it is 
important to document this idea so future platform code follows the same.

York

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

Re: [U-Boot] [PATCH v2 9/9] colibri_imx7: add Colibri iMX7S/iMX7D module support

[Stefano Babic]

Hi Stefan,

On 19/07/2016 18:05, Stefan Agner wrote:

>> I wonder we never add imximage.cfg into the MAINTAINERS. Boards with SPL
>> have a central and empty imximage.cfg, for the other ones we should add
>> it to the list. (Note: I have currently seen that no board having its
>> own imximage.cfg does not list it in the MAINTAINERS file).
>>
> 
> I added the directory where imximage.cfg is located in
> (board/toradex/colibri_imx7/). We also don't add other files in there, I
> think the scripts work fine with directories specified without
> specifying the individual files...

Of course, you're right - sorry for noise.

Best regards,
Stefano Babic


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] fsl-layerscape: Add workaround for PCIe erratum A010315

[york sun]

On 07/03/2016 11:39 PM, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
>
> As the access to serders protocol unselected PCIe controller will
> hang. So disable the R/W permission to unselected PCIe controller
> including its CCSR, IO space and memory space according to the
> serders protocol field of RCW.
>
> Signed-off-by: Hou Zhiqiang 
> ---
> Tested on LS1043ARDB, LS1021AQDS boards.
>
>  arch/arm/cpu/armv7/ls102xa/soc.c  | 14 ++
>  arch/arm/cpu/armv8/fsl-layerscape/soc.c   | 16 
>  arch/arm/include/asm/arch-fsl-layerscape/config.h |  2 ++
>  arch/arm/include/asm/arch-fsl-layerscape/soc.h|  4 
>  arch/arm/include/asm/arch-ls102xa/config.h|  1 +
>  arch/arm/include/asm/arch-ls102xa/ls102xa_soc.h   |  4 
>  board/freescale/ls1012aqds/ls1012aqds.c   |  4 
>  board/freescale/ls1012ardb/ls1012ardb.c   |  4 
>  board/freescale/ls1021aqds/ls1021aqds.c   |  4 
>  board/freescale/ls1021atwr/ls1021atwr.c   |  4 
>  board/freescale/ls1043aqds/ls1043aqds.c   |  4 
>  board/freescale/ls1043ardb/ls1043ardb.c   |  4 
>  12 files changed, 65 insertions(+)
>

Can you put the call of erratum_a010315() in an SoC file, instead of 
individual board file?

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

Re: [U-Boot] [PATCH v1 6/6] armv8: layerscape: Convert to use common MMU framework

[york sun]

On 07/18/2016 11:44 PM, Alexander Graf wrote:
>
>
> On 25.06.16 01:46, York Sun wrote:
>> Drop platform code to create static MMU tables. Use common framework
>> to create MMU tables on the run. Tested on LS2080ARDB with secure and
>> non-secure ram scenarios.
>>
>> Signed-off-by: York Sun 
>>
>> Alison Wang ,
>> Prabhakar Kushwaha 
>
> What is this? :)

This comes from patman tag. I must have used wrong format so patman sent 
it out. Will fix when merging.

 Series-to: U-boot
 Series-version: 1
 Series-cc: Alexander Graf ,
Alison Wang ,
Prabhakar Kushwaha 

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

Re: [U-Boot] u-boot: x86: interrupt mapping

[Jian Luo]

Hi Christian,

I took some time to recall what I did by patching FSP:

- search in every PE32 and TE image section for binary sequence
81c900018908c6460e01
and change to
81c9000102008908c6460e00

- then replace them in-place

The difference can be better understand if disassemblies are compared, eg:
 Disassembly of section .data:
@@ -3367,9 +3367,9 @@
 25fc:05 00 05 00 00   add$0x500,%eax
 2601:8b 08mov(%eax),%ecx
 2603:81 e1 ff ff f8 ffand$0xfff8,%ecx
-2609:81 c9 00 01 00 00or $0x100,%ecx
+2609:81 c9 00 01 02 00or $0x20100,%ecx
What I did here is setting BAUDSEL to SYS_25MHz.

 260f:89 08mov%ecx,(%eax)
-2611:c6 46 0e 01  movb   $0x1,0xe(%esi)
+2611:c6 46 0e 00  movb   $0x0,0xe(%esi)
Can't recall why I did this, maybe bypassing PLL altogether?

 2615:c6 46 0f 00  movb   $0x0,0xf(%esi)
 2619:c6 46 03 83  movb   $0x83,0x3(%esi)
 261d:c6 46 01 00  movb   $0x0,0x1(%esi)

Since I don't rely on Topcliff UART for output, the baud rate 
recalculation is all skipped.


Best regards,

*Jian Luo
DC-IA/EAH2*

Tel.  +49(9352)18-4266

*Be**QIK
*

On 19.07.2016 17:21, Christian Gmeiner wrote:

Hi Jian,


For the moment I have no answer to this question. I need to dive into
the vxworks code, which
is not what I like to do now (but needs to be done)-

Yes, please do track it down. The interrupt line register configured
by U-Boot should be enough for VxWorks to function under PIC mode.

I have an other (wired) question you may could help out.

http://www.mouser.com/pdfdocs/Intel_Platform_Controller_Hub_EG20T_datasheet.pdf
(page 124)

On my development board the uart_clk is connected to a oscillator and
everything works as expected.
But on the production devices the uart_clk is not connected and fsp
hangs with post code 0x2e.

I am not sure about the meaning of post code 0x2e. Jian has some
working experience on Atom E6xx with U-Boot. Adding him.

0x2e == POST_PRE_MRC (arch/x86/include/asm/post.h)

Now I would like to change the initial mux settings to use usb_48mhz
but I am quite sure that I need
to have the pci bus and its devices initialised already in order to
change the CLKCFG register. Do you
think there is an other way of accessing this register like fixed
memory address etc?

Which register do you want to program for this uart_clk? If it's on
the PCI configuration space, you can use PCI config APIs to program.

There a handful of registers I would need to program but all of them are
accessible via pic config space. E.g CLKCFG:

Size: 32-bit Default: 2C00 Power Well: Core
Access PCI Configuration B:D:F D0:F0 Offset Start: Offset End: 500h 503h
 Memory Mapped I/O BAR: PKTHubCTLBASE Offset: 500h


As I need to program those registers before fsp_init I must setup the pci
bus by myself, change the register values and call fsb_init routine.
Correct?

My board had this problem too. I however toke a different approach
by patching the original FSP. The waiting for Topcliff UART ready is
completely
bypassed in all UEFI blobs. You can use UEFITool [1] to extract blobs in
the attached FSP for comparison.


Sooo... I did use the UEFITool to compare your fsp with mine and yeah...
some files are different.

File_Raw_06A70056_3D0F_4A94_A743_5491CC9391D3_body.bin
Section_PE32_image_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_body.bin
Section_PE32_image_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_header.bin
Section_PE32_image_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_body.bin
Section_PE32_image_74D3B506_EE9C_47ED_B749_41261401DA78_TCInitDxe_body.bin
Section_TE_image_1BA0062E_C779_4582_8566_336AE8F78F09_Volume_Top_File_body.bin
Section_TE_image_52C05B14_0B98_496C_BC3B_04B50211D680_PeiCore_body.bin
Section_TE_image_86D70125_BAA3_4296_A62F_602BEBBB9081_DxeIpl_body.bin
Section_TE_image_9618C0DC_50A4_496C_994F_7241F282ED01_PlatformEarlyInit_body.bin
Section_TE_image_9B3ADA4F_AE56_4C24_8DEA_F03B7558AE50_PcdPeim_body.bin
Section_TE_image_D2C69B26_82E1_4A1B_AD35_ED0261B9F347_MemoryInitPei_body.bin
File_PEI_module_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_info.txt
File_PEI_module_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_info.txt
File_PEI_module_74D3B506_EE9C_47ED_B749_41261401DA78_TCInitDxe_info.txt
Section_Compressed_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_info.txt
Section_Compressed_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_info.txt
Section_Compressed_74D3B506_EE9C_47ED_B749_41261401DA78_TCInitDxe_info.txt
Section_PE32_image_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_info.txt
Section_PEI_dependency_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_info.txt
Section_PEI_dependency_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_info.txt

Any hint at what to look for? Sadly I am not an UEFI guy.

greets
--
Christian 

[U-Boot] [v2 1/1] wandboard: fix dtb file names.

[Adam Duskett]

With the previous suggestion from Wolfgang Denk, this patch removes
the findfdt function from wandboard.h and instead replaces it with
some simple logic in wandboard.c.

The new function "set_fdtfile" is called in board_late_init.  This
function simply finds the length of the dtb file name, allocates
enough space for that string, and sets the fdtfile name to that string.

This results in slightly shorter / faster script code as well.

Dear Adam Duskett,

In message  you wrote:
> With the release of kernel 4.1.15 for the imx6 line of processors,
> wandboard now uses imx6q-wandboard-revc1.dtb and imx6dl-wandboard-revc1.dtb.
> This patch fixes the naming convention to work with kernel 4.1.15
>
> Signed-off-by: Adam Duskett 
> ---
> include/configs/wandboard.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
> index 99f5c0c..d41b600 100644
> --- a/include/configs/wandboard.h
> +++ b/include/configs/wandboard.h
> @@ -135,9 +135,9 @@
> "setenv bootargs ${bootargs} ${fbmem}\0" \
> "findfdt="\
> "if test $board_name = C1 && test $board_rev = MX6Q ; then " \
> - "setenv fdtfile imx6q-wandboard.dtb; fi; " \
> + "setenv fdtfile imx6q-wandboard-revc1.dtb; fi; " \
> "if test $board_name = C1 && test $board_rev = MX6DL ; then " \
> - "setenv fdtfile imx6dl-wandboard.dtb; fi; " \
> + "setenv fdtfile imx6dl-wandboard-revc1.dtb; fi; " \
> "if test $board_name = B1 && test $board_rev = MX6Q ; then " \
> "setenv fdtfile imx6q-wandboard-revb1.dtb; fi; " \
> "if test $board_name = B1 && test $board_rev = MX6DL ; then " \

Instead of adding to an ever growing list of names, would it not make
sense to solve this programmatically, like by concatenating "i" +
tolower($board_rev) + "-wandboard-rev" + tolower($board_name) + ".dtb"?

I guess this would also result in shorter / faster script code?

Best regards,

Wolfgang Denk

Signed-off-by: Adam Duskett 
---
Changes:

v1 - v2:
 - Removed findfdt from h file and moved it to init code.

 
 board/wandboard/wandboard.c | 20 
 include/configs/wandboard.h | 12 
 2 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/board/wandboard/wandboard.c b/board/wandboard/wandboard.c
index 4ce74cd..a1037ed 100644
--- a/board/wandboard/wandboard.c
+++ b/board/wandboard/wandboard.c
@@ -29,6 +29,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -377,6 +379,22 @@ static bool is_revc1(void)
return false;
 }
 
+static void set_fdtfile(void)
+{
+   char *fdtfile;
+   int i;
+   int length = strlen(getenv("board_rev")) + strlen("-wandboard-rev") +
+strlen(getenv("board_name")) + strlen(".dtb") + 1;
+   fdtfile = malloc(length);
+   sprintf(fdtfile, "i%s-wandboard-rev%s.dtb", getenv("board_rev"), 
getenv("board_name"));
+   for (i = 0; i < length; i++){
+   fdtfile[i] = tolower(fdtfile[i]);
+   }
+
+   setenv("fdtfile", fdtfile);
+   free(fdtfile);
+}
+
 int board_late_init(void)
 {
 #ifdef CONFIG_CMD_BMODE
@@ -393,6 +411,8 @@ int board_late_init(void)
setenv("board_name", "C1");
else
setenv("board_name", "B1");
+
+   set_fdtfile();
 #endif
return 0;
 }
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index 99f5c0c..778c3f5 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -133,17 +133,6 @@
"echo '- no FWBADAPT-7WVGA-LCD-F07A-0102 display';" \
"fi; " \
"setenv bootargs ${bootargs} ${fbmem}\0" \
-   "findfdt="\
-   "if test $board_name = C1 && test $board_rev = MX6Q ; then " \
-   "setenv fdtfile imx6q-wandboard.dtb; fi; " \
-   "if test $board_name = C1 && test $board_rev = MX6DL ; then " \
-   "setenv fdtfile imx6dl-wandboard.dtb; fi; " \
-   "if test $board_name = B1 && test $board_rev = MX6Q ; then " \
-   "setenv fdtfile imx6q-wandboard-revb1.dtb; fi; " \
-   "if test $board_name = B1 && test $board_rev = MX6DL ; then " \
-   "setenv fdtfile imx6dl-wandboard-revb1.dtb; fi; " \
-   "if test $fdtfile = undefined; then " \
-   "echo WARNING: Could not determine dtb to use; fi; \0" \
"kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
"pxefile_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
"ramdisk_addr_r=0x1300\0" \
@@ -159,7 +148,6 @@
func(DHCP, dhcp, na)
 
 #define CONFIG_BOOTCOMMAND \
-  "run findfdt; " \
   "run distro_bootcmd"
 
 #include 
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de

Re: [U-Boot] [PATCH v2 0/9] mx7: add Colibri iMX7S/iMX7D support

[Stefan Agner]

On 2016-07-19 07:18, stefano wrote:
> Hi Stefan,
> 
> On 18/07/2016 22:59, Stefan Agner wrote:
>> On 2016-07-13 00:25, Stefan Agner wrote:
>>> From: Stefan Agner 
>>>
>>> This patchset adds support for the Toradex i.MX 7Solo and 7Dual
>>> based computer on modules Colibri iMX7S/iMX7D.
>>>
>>> It also brings several smaller i.MX 7 related fixes/cleanups.
>>
>> Is there anything holding us back merging this patchset?
>>
>> It touches several subsystems, ultimately the final patch adding the new
>> board is depending on all of them. What is the plan how to merge it?
>>
> 
> I see all patches are assigned to me - that makes sense to avoid some
> kind of breakages.
> 
> IMHO patches 1-4, 6-8 are ready to be merged. The best plan could be I
> start to apply them, and you resend an updated just for the ones to be
> changed. This should makes integration easier.

Afait, 5 should be fine too. The i.MX 6 changes will be in a separate
patch, and Tom agreed to the approach for the soc variable...

Will resend 9.

--
Stefan

> 
> Stefano
> 
>> --
>> Stefan
>>
>>>
>>> Changes since v1:
>>> - Dropped Ricoh RN5T567 PMIC support (for now)
>>> - Use CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG for runtime variables
>>> - Convert USB OTG Power Pin Polarity to Kconfig
>>> - Use gpio_request in lcd_setup
>>>
>>> Stefan Agner (9):
>>>   dm: imx: serial: Support DTE mode when using driver model
>>>   usb: move CONFIG_USB_EHCI_MX7 to Kconfig
>>>   usb: ehci-mx6: configure power polarity in usb_power_config
>>>   usb: ehci-mx6: introduce config for high active power pin
>>>   mx7: set soc environment according to exact SoC type
>>>   mx7_common: Put display board info config into board file
>>>   mx7_common: use Kconfig for ARMv7 non-secure mode
>>>   imx_watchdog: add weak attribute to reset_cpu function
>>>   colibri_imx7: add Colibri iMX7S/iMX7D module support
>>>
>>>  arch/arm/cpu/armv7/mx7/Kconfig|   9 +
>>>  arch/arm/cpu/armv7/mx7/soc.c  |  14 +
>>>  board/toradex/colibri_imx7/Kconfig|  12 +
>>>  board/toradex/colibri_imx7/MAINTAINERS|   6 +
>>>  board/toradex/colibri_imx7/Makefile   |   6 +
>>>  board/toradex/colibri_imx7/colibri_imx7.c | 420 
>>> ++
>>>  board/toradex/colibri_imx7/imximage.cfg   | 150 +++
>>>  configs/colibri_imx7_defconfig|  40 +++
>>>  configs/mx7dsabresd_defconfig |   3 +
>>>  configs/warp7_defconfig   |   4 +
>>>  drivers/serial/serial_mxc.c   |   9 +-
>>>  drivers/usb/host/Kconfig  |  16 ++
>>>  drivers/usb/host/ehci-mx6.c   |  14 +-
>>>  drivers/watchdog/imx_watchdog.c   |   2 +-
>>>  include/configs/colibri_imx7.h| 248 ++
>>>  include/configs/mx7_common.h  |  10 +-
>>>  include/configs/mx7dsabresd.h |   4 +-
>>>  include/configs/warp7.h   |   4 +-
>>>  include/dm/platform_data/serial_mxc.h |   1 +
>>>  19 files changed, 953 insertions(+), 19 deletions(-)
>>>  create mode 100644 board/toradex/colibri_imx7/Kconfig
>>>  create mode 100644 board/toradex/colibri_imx7/MAINTAINERS
>>>  create mode 100644 board/toradex/colibri_imx7/Makefile
>>>  create mode 100644 board/toradex/colibri_imx7/colibri_imx7.c
>>>  create mode 100644 board/toradex/colibri_imx7/imximage.cfg
>>>  create mode 100644 configs/colibri_imx7_defconfig
>>>  create mode 100644 include/configs/colibri_imx7.h
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [v2 1/1] wandboard: fix dtb file names.

[Adam Duskett]

> From: feste...@gmail.com
> Date: Tue, 19 Jul 2016 14:32:17 -0300
> Subject: Re: [U-Boot] [v2 1/1] wandboard: fix dtb file names.
> To: adamdusk...@outlook.com
> CC: u-boot@lists.denx.de; sba...@denx.de
> 
> On Tue, Jul 19, 2016 at 2:23 PM, Adam Duskett  wrote:
> > With the previous suggestion from Wolfgang Denk, this patch removes
> > the findfdt function from wandboard.h and instead replaces it with
> > some simple logic in wandboard.c.
> >
> > The new function "set_fdtfile" is called in board_late_init.  This
> > function simply finds the length of the dtb file name, allocates
> > enough space for that string, and sets the fdtfile name to that string.
> >
> > This results in slightly shorter / faster script code as well.
> >
> > Dear Adam Duskett,
> >
> > In message  you wrote:
> >> With the release of kernel 4.1.15 for the imx6 line of processors,
> >> wandboard now uses imx6q-wandboard-revc1.dtb and 
> >> imx6dl-wandboard-revc1.dtb.
> >> This patch fixes the naming convention to work with kernel 4.1.15
> >>
> >> Signed-off-by: Adam Duskett 
> >> ---
> >> include/configs/wandboard.h | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
> >> index 99f5c0c..d41b600 100644
> >> --- a/include/configs/wandboard.h
> >> +++ b/include/configs/wandboard.h
> >> @@ -135,9 +135,9 @@
> >> "setenv bootargs ${bootargs} ${fbmem}\0" \
> >> "findfdt="\
> >> "if test $board_name = C1 && test $board_rev = MX6Q ; then " \
> >> - "setenv fdtfile imx6q-wandboard.dtb; fi; " \
> >> + "setenv fdtfile imx6q-wandboard-revc1.dtb; fi; " \
> >> "if test $board_name = C1 && test $board_rev = MX6DL ; then " \
> >> - "setenv fdtfile imx6dl-wandboard.dtb; fi; " \
> >> + "setenv fdtfile imx6dl-wandboard-revc1.dtb; fi; " \
> >> "if test $board_name = B1 && test $board_rev = MX6Q ; then " \
> >> "setenv fdtfile imx6q-wandboard-revb1.dtb; fi; " \
> >> "if test $board_name = B1 && test $board_rev = MX6DL ; then " \
> >
> > Instead of adding to an ever growing list of names, would it not make
> > sense to solve this programmatically, like by concatenating "i" +
> > tolower($board_rev) + "-wandboard-rev" + tolower($board_name) + ".dtb"?
> >
> > I guess this would also result in shorter / faster script code?
> >
> > Best regards,
> >
> > Wolfgang Denk
> >
> > Signed-off-by: Adam Duskett 
> > ---
> > Changes:
> >
> > v1 - v2:
> >  - Removed findfdt from h file and moved it to init code.
> >
> >
> >  board/wandboard/wandboard.c | 20 
> >  include/configs/wandboard.h | 12 
> >  2 files changed, 20 insertions(+), 12 deletions(-)
> 
> This is not really making things simpler as shown by the diff stat.It changes 
> it to be programatic instead of static.
> 
> I prefer to keep the current code as is.
If it is left as is, then the previous version of the patch needs to be 
appliedbecause the new dtb file names in kernel 4.1.15 are different.   
  
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [v2 1/1] wandboard: fix dtb file names.

[Adam Duskett]

> From: feste...@gmail.com
> Date: Tue, 19 Jul 2016 14:51:11 -0300
> Subject: Re: [U-Boot] [v2 1/1] wandboard: fix dtb file names.
> To: tr...@konsulko.com
> CC: adamdusk...@outlook.com; u-boot@lists.denx.de
> 
> On Tue, Jul 19, 2016 at 2:43 PM, Tom Rini  wrote:
> 
> > But this does show that we need to step back and think about how to more
> > easily do what this is trying to do.  If $soc was set as in Stefan's
> > patch for example, we would just need board_name to be being set in
> > lowercase rather than upper case.
> 
> This patch says in the subject: "fix dtb file names" and it gives no
> indication of what is really wrong with the current code. What is it
> fixing?
> The original patch that I submitted just changed the dts files to the new 
> namingscheme found in 4.1.15.  Once I submitted that, (as you can see in the 
> commit message provided) Woflgang suggested changing it to some basic logic.  
> If I understand this correctly the goal of this patch is to make it
> work with a 4.1.15 kernel vendor dts naming scheme.
> 
> My suggestion is to change the kernel vendor dts name to the same used
> in mainline and then it will just work with the current U-boot code.

That was the first version of the patch I submitted.  Again; Wolfgang suggested 
changingit to a logic based function.  Would you like me to just change the 
names statically? Or would you like me to set the string dynamically?   
  
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [v2 1/1] wandboard: fix dtb file names.

[Tom Rini]

On Tue, Jul 19, 2016 at 02:51:11PM -0300, Fabio Estevam wrote:
> On Tue, Jul 19, 2016 at 2:43 PM, Tom Rini  wrote:
> 
> > But this does show that we need to step back and think about how to more
> > easily do what this is trying to do.  If $soc was set as in Stefan's
> > patch for example, we would just need board_name to be being set in
> > lowercase rather than upper case.
> 
> This patch says in the subject: "fix dtb file names" and it gives no
> indication of what is really wrong with the current code. What is it
> fixing?
> 
> If I understand this correctly the goal of this patch is to make it
> work with a 4.1.15 kernel vendor dts naming scheme.

Also true, and I agree, we (mainline U-Boot) shouldn't be trying to
match non-mainline DT names.

> My suggestion is to change the kernel vendor dts name to the same used
> in mainline and then it will just work with the current U-boot code.

Yes.  But it also shows that, ug, this could be better.

-- 
Tom


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

Re: [U-Boot] [v2 1/1] wandboard: fix dtb file names.

[Fabio Estevam]

On Tue, Jul 19, 2016 at 2:23 PM, Adam Duskett  wrote:
> With the previous suggestion from Wolfgang Denk, this patch removes
> the findfdt function from wandboard.h and instead replaces it with
> some simple logic in wandboard.c.
>
> The new function "set_fdtfile" is called in board_late_init.  This
> function simply finds the length of the dtb file name, allocates
> enough space for that string, and sets the fdtfile name to that string.
>
> This results in slightly shorter / faster script code as well.
>
> Dear Adam Duskett,
>
> In message  you wrote:
>> With the release of kernel 4.1.15 for the imx6 line of processors,
>> wandboard now uses imx6q-wandboard-revc1.dtb and imx6dl-wandboard-revc1.dtb.
>> This patch fixes the naming convention to work with kernel 4.1.15
>>
>> Signed-off-by: Adam Duskett 
>> ---
>> include/configs/wandboard.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
>> index 99f5c0c..d41b600 100644
>> --- a/include/configs/wandboard.h
>> +++ b/include/configs/wandboard.h
>> @@ -135,9 +135,9 @@
>> "setenv bootargs ${bootargs} ${fbmem}\0" \
>> "findfdt="\
>> "if test $board_name = C1 && test $board_rev = MX6Q ; then " \
>> - "setenv fdtfile imx6q-wandboard.dtb; fi; " \
>> + "setenv fdtfile imx6q-wandboard-revc1.dtb; fi; " \
>> "if test $board_name = C1 && test $board_rev = MX6DL ; then " \
>> - "setenv fdtfile imx6dl-wandboard.dtb; fi; " \
>> + "setenv fdtfile imx6dl-wandboard-revc1.dtb; fi; " \
>> "if test $board_name = B1 && test $board_rev = MX6Q ; then " \
>> "setenv fdtfile imx6q-wandboard-revb1.dtb; fi; " \
>> "if test $board_name = B1 && test $board_rev = MX6DL ; then " \
>
> Instead of adding to an ever growing list of names, would it not make
> sense to solve this programmatically, like by concatenating "i" +
> tolower($board_rev) + "-wandboard-rev" + tolower($board_name) + ".dtb"?
>
> I guess this would also result in shorter / faster script code?
>
> Best regards,
>
> Wolfgang Denk
>
> Signed-off-by: Adam Duskett 
> ---
> Changes:
>
> v1 - v2:
>  - Removed findfdt from h file and moved it to init code.
>
>
>  board/wandboard/wandboard.c | 20 
>  include/configs/wandboard.h | 12 
>  2 files changed, 20 insertions(+), 12 deletions(-)

This is not really making things simpler as shown by the diff stat.

I prefer to keep the current code as is.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/9] mx7: add Colibri iMX7S/iMX7D support

[Stefano Babic]

Hi Stefan,

On 19/07/2016 18:09, Stefan Agner wrote:
> On 2016-07-19 07:18, stefano wrote:
>> Hi Stefan,
>>
>> On 18/07/2016 22:59, Stefan Agner wrote:
>>> On 2016-07-13 00:25, Stefan Agner wrote:
 From: Stefan Agner 

 This patchset adds support for the Toradex i.MX 7Solo and 7Dual
 based computer on modules Colibri iMX7S/iMX7D.

 It also brings several smaller i.MX 7 related fixes/cleanups.
>>>
>>> Is there anything holding us back merging this patchset?
>>>
>>> It touches several subsystems, ultimately the final patch adding the new
>>> board is depending on all of them. What is the plan how to merge it?
>>>
>>
>> I see all patches are assigned to me - that makes sense to avoid some
>> kind of breakages.
>>
>> IMHO patches 1-4, 6-8 are ready to be merged. The best plan could be I
>> start to apply them, and you resend an updated just for the ones to be
>> changed. This should makes integration easier.
> 
> Afait, 5 should be fine too. The i.MX 6 changes will be in a separate
> patch, and Tom agreed to the approach for the soc variable...
> 

I see, agree on that. I merge patch 1-8, and I will wait for 9.

> Will resend 9.

Fine with me.

Stefano

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/9] mx7: add Colibri iMX7S/iMX7D support

[stefano]

Hi Stefan,

On 18/07/2016 22:59, Stefan Agner wrote:
> On 2016-07-13 00:25, Stefan Agner wrote:
>> From: Stefan Agner 
>>
>> This patchset adds support for the Toradex i.MX 7Solo and 7Dual
>> based computer on modules Colibri iMX7S/iMX7D.
>>
>> It also brings several smaller i.MX 7 related fixes/cleanups.
> 
> Is there anything holding us back merging this patchset?
> 
> It touches several subsystems, ultimately the final patch adding the new
> board is depending on all of them. What is the plan how to merge it?
> 

I see all patches are assigned to me - that makes sense to avoid some
kind of breakages.

IMHO patches 1-4, 6-8 are ready to be merged. The best plan could be I
start to apply them, and you resend an updated just for the ones to be
changed. This should makes integration easier.

Stefano

> --
> Stefan
> 
>>
>> Changes since v1:
>> - Dropped Ricoh RN5T567 PMIC support (for now)
>> - Use CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG for runtime variables
>> - Convert USB OTG Power Pin Polarity to Kconfig
>> - Use gpio_request in lcd_setup
>>
>> Stefan Agner (9):
>>   dm: imx: serial: Support DTE mode when using driver model
>>   usb: move CONFIG_USB_EHCI_MX7 to Kconfig
>>   usb: ehci-mx6: configure power polarity in usb_power_config
>>   usb: ehci-mx6: introduce config for high active power pin
>>   mx7: set soc environment according to exact SoC type
>>   mx7_common: Put display board info config into board file
>>   mx7_common: use Kconfig for ARMv7 non-secure mode
>>   imx_watchdog: add weak attribute to reset_cpu function
>>   colibri_imx7: add Colibri iMX7S/iMX7D module support
>>
>>  arch/arm/cpu/armv7/mx7/Kconfig|   9 +
>>  arch/arm/cpu/armv7/mx7/soc.c  |  14 +
>>  board/toradex/colibri_imx7/Kconfig|  12 +
>>  board/toradex/colibri_imx7/MAINTAINERS|   6 +
>>  board/toradex/colibri_imx7/Makefile   |   6 +
>>  board/toradex/colibri_imx7/colibri_imx7.c | 420 
>> ++
>>  board/toradex/colibri_imx7/imximage.cfg   | 150 +++
>>  configs/colibri_imx7_defconfig|  40 +++
>>  configs/mx7dsabresd_defconfig |   3 +
>>  configs/warp7_defconfig   |   4 +
>>  drivers/serial/serial_mxc.c   |   9 +-
>>  drivers/usb/host/Kconfig  |  16 ++
>>  drivers/usb/host/ehci-mx6.c   |  14 +-
>>  drivers/watchdog/imx_watchdog.c   |   2 +-
>>  include/configs/colibri_imx7.h| 248 ++
>>  include/configs/mx7_common.h  |  10 +-
>>  include/configs/mx7dsabresd.h |   4 +-
>>  include/configs/warp7.h   |   4 +-
>>  include/dm/platform_data/serial_mxc.h |   1 +
>>  19 files changed, 953 insertions(+), 19 deletions(-)
>>  create mode 100644 board/toradex/colibri_imx7/Kconfig
>>  create mode 100644 board/toradex/colibri_imx7/MAINTAINERS
>>  create mode 100644 board/toradex/colibri_imx7/Makefile
>>  create mode 100644 board/toradex/colibri_imx7/colibri_imx7.c
>>  create mode 100644 board/toradex/colibri_imx7/imximage.cfg
>>  create mode 100644 configs/colibri_imx7_defconfig
>>  create mode 100644 include/configs/colibri_imx7.h


-- 
stefano 
GPG Key: 0x55814DDE
Fingerprint 4E85 2A66 4CBA 497A 2A7B D3BF 5973 F216 5581 4DDE
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] fixing typo error in README file. CPU15 -> CP15

[yeongjun Kim]

Signed-off-by: yeongjun Kim 
---
 README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README b/README
index 3c3b699..8887cf5 100644
--- a/README
+++ b/README
@@ -4806,7 +4806,7 @@ Low Level (hardware related) configuration options:
 
 - CONFIG_SKIP_LOWLEVEL_INIT_ONLY
[ARM926EJ-S only] This allows just the call to lowlevel_init()
-   to be skipped. The normal CPU15 init (such as enabling the
+   to be skipped. The normal CP15 init (such as enabling the
instruction cache) is still performed.
 
 - CONFIG_SPL_BUILD
-- 
1.9.1

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

Re: [U-Boot] [PATCH v1 0/6] Convert FSL LayerScape ARMv8 SoCs to use common MMU code

[Alexander Graf]

On 25.06.16 01:46, York Sun wrote:
> To use common MMU code, non-identical mapping needs to be supported.
> Minior change in the MMU framework is required to support splitting
> blocks. With these changes, using common code is straight forward.
> Attention is needed where the tables are for early boot, secure and
> non-secure ram situations.

Reviewed-by: Alexander Graf 

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

Re: [U-Boot] [v2 1/1] wandboard: fix dtb file names.

[Fabio Estevam]

On Tue, Jul 19, 2016 at 2:40 PM, Adam Duskett  wrote:

>> I prefer to keep the current code as is.
> If it is left as is, then the previous version of the patch needs to be
> applied
> because the new dtb file names in kernel 4.1.15 are different.

Then please change the name of the 4.1.15 vendor kernel dts to match
the one from mainline.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [v2 1/1] wandboard: fix dtb file names.

[Wolfgang Denk]

Dear Adam,

In message  you wrote:
> 
> + int length = strlen(getenv("board_rev")) + strlen("-wandboard-rev") +
> +  strlen(getenv("board_name")) + strlen(".dtb") + 1;
> + fdtfile = malloc(length);

Don't you think you should add some error checking here? Each of the
getenv() calls may fail, as well as the malloc() - and then?

As is: NAK!!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Which witch wished which wicked wish?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [v2 1/1] wandboard: fix dtb file names.

[Fabio Estevam]

On Tue, Jul 19, 2016 at 2:43 PM, Tom Rini  wrote:

> But this does show that we need to step back and think about how to more
> easily do what this is trying to do.  If $soc was set as in Stefan's
> patch for example, we would just need board_name to be being set in
> lowercase rather than upper case.

This patch says in the subject: "fix dtb file names" and it gives no
indication of what is really wrong with the current code. What is it
fixing?

If I understand this correctly the goal of this patch is to make it
work with a 4.1.15 kernel vendor dts naming scheme.

My suggestion is to change the kernel vendor dts name to the same used
in mainline and then it will just work with the current U-boot code.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [v2 1/1] wandboard: fix dtb file names.

[Tom Rini]

On Tue, Jul 19, 2016 at 02:32:17PM -0300, Fabio Estevam wrote:
> On Tue, Jul 19, 2016 at 2:23 PM, Adam Duskett  wrote:
> > With the previous suggestion from Wolfgang Denk, this patch removes
> > the findfdt function from wandboard.h and instead replaces it with
> > some simple logic in wandboard.c.
> >
> > The new function "set_fdtfile" is called in board_late_init.  This
> > function simply finds the length of the dtb file name, allocates
> > enough space for that string, and sets the fdtfile name to that string.
> >
> > This results in slightly shorter / faster script code as well.
> >
> > Dear Adam Duskett,
> >
> > In message  you wrote:
> >> With the release of kernel 4.1.15 for the imx6 line of processors,
> >> wandboard now uses imx6q-wandboard-revc1.dtb and 
> >> imx6dl-wandboard-revc1.dtb.
> >> This patch fixes the naming convention to work with kernel 4.1.15
> >>
> >> Signed-off-by: Adam Duskett 
> >> ---
> >> include/configs/wandboard.h | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
> >> index 99f5c0c..d41b600 100644
> >> --- a/include/configs/wandboard.h
> >> +++ b/include/configs/wandboard.h
> >> @@ -135,9 +135,9 @@
> >> "setenv bootargs ${bootargs} ${fbmem}\0" \
> >> "findfdt="\
> >> "if test $board_name = C1 && test $board_rev = MX6Q ; then " \
> >> - "setenv fdtfile imx6q-wandboard.dtb; fi; " \
> >> + "setenv fdtfile imx6q-wandboard-revc1.dtb; fi; " \
> >> "if test $board_name = C1 && test $board_rev = MX6DL ; then " \
> >> - "setenv fdtfile imx6dl-wandboard.dtb; fi; " \
> >> + "setenv fdtfile imx6dl-wandboard-revc1.dtb; fi; " \
> >> "if test $board_name = B1 && test $board_rev = MX6Q ; then " \
> >> "setenv fdtfile imx6q-wandboard-revb1.dtb; fi; " \
> >> "if test $board_name = B1 && test $board_rev = MX6DL ; then " \
> >
> > Instead of adding to an ever growing list of names, would it not make
> > sense to solve this programmatically, like by concatenating "i" +
> > tolower($board_rev) + "-wandboard-rev" + tolower($board_name) + ".dtb"?
> >
> > I guess this would also result in shorter / faster script code?
> >
> > Best regards,
> >
> > Wolfgang Denk
> >
> > Signed-off-by: Adam Duskett 
> > ---
> > Changes:
> >
> > v1 - v2:
> >  - Removed findfdt from h file and moved it to init code.
> >
> >
> >  board/wandboard/wandboard.c | 20 
> >  include/configs/wandboard.h | 12 
> >  2 files changed, 20 insertions(+), 12 deletions(-)
> 
> This is not really making things simpler as shown by the diff stat.

But this does show that we need to step back and think about how to more
easily do what this is trying to do.  If $soc was set as in Stefan's
patch for example, we would just need board_name to be being set in
lowercase rather than upper case.

-- 
Tom


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

Re: [U-Boot] [v2 1/1] wandboard: fix dtb file names.

[Adam Duskett]

> From: feste...@gmail.com> Date: Tue, 19 Jul 2016 14:46:38 -0300
> Subject: Re: [U-Boot] [v2 1/1] wandboard: fix dtb file names.
> To: adamdusk...@outlook.com
> CC: u-boot@lists.denx.de; sba...@denx.de
> 
> On Tue, Jul 19, 2016 at 2:40 PM, Adam Duskett  wrote:
> 
> >> I prefer to keep the current code as is.
> > If it is left as is, then the previous version of the patch needs to be
> > applied
> > because the new dtb file names in kernel 4.1.15 are different.
> 
> Then please change the name of the 4.1.15 vendor kernel dts to match
> the one from mainline.

I did, and as per the commit message; Wolfgang Denk suggested making it into a 
logic based function?  What would you like me to do?  I can just resubmit the 
old patchwhich changed the vendor names, or would you like me to follow 
Wolfgang's directions?
Adam
  
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [Patch v2 6/6] armv8: layerscape: Convert to use common MMU framework

[York Sun]

Drop platform code to create static MMU tables. Use common framework
to create MMU tables on the run. Tested on LS2080ARDB with secure and
non-secure ram scenarios.

Signed-off-by: York Sun 
---
Change log
  v2: Drop two emails under signed-off line (mistakenly sent by patman)
  Restore gd->arch.tlb_addr from allocated position for EL2 in case of
  secure RAM for EL3. It was found during testing ls1043a boot with
  PPA, and returned to EL2.

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 360 -
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 310 -
 2 files changed, 238 insertions(+), 432 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index a397f5d..b6ebedc 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -26,13 +26,7 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-static struct mm_region layerscape_mem_map[] = {
-   {
-   /* List terminator */
-   0,
-   }
-};
-struct mm_region *mem_map = layerscape_mem_map;
+struct mm_region *mem_map = early_map;
 
 void cpu_name(char *name)
 {
@@ -56,233 +50,35 @@ void cpu_name(char *name)
 }
 
 #ifndef CONFIG_SYS_DCACHE_OFF
-static void set_pgtable_section(u64 *page_table, u64 index, u64 section,
-   u64 memory_type, u64 attribute)
-{
-   u64 value;
-
-   value = section | PTE_TYPE_BLOCK | PTE_BLOCK_AF;
-   value |= PMD_ATTRINDX(memory_type);
-   value |= attribute;
-   page_table[index] = value;
-}
-
-static void set_pgtable_table(u64 *page_table, u64 index, u64 *table_addr)
-{
-   u64 value;
-
-   value = (u64)table_addr | PTE_TYPE_TABLE;
-   page_table[index] = value;
-}
-
-/*
- * Set the block entries according to the information of the table.
- */
-static int set_block_entry(const struct sys_mmu_table *list,
-  struct table_info *table)
-{
-   u64 block_size = 0, block_shift = 0;
-   u64 block_addr, index;
-   int j;
-
-   if (table->entry_size == BLOCK_SIZE_L1) {
-   block_size = BLOCK_SIZE_L1;
-   block_shift = SECTION_SHIFT_L1;
-   } else if (table->entry_size == BLOCK_SIZE_L2) {
-   block_size = BLOCK_SIZE_L2;
-   block_shift = SECTION_SHIFT_L2;
-   } else {
-   return -EINVAL;
-   }
-
-   block_addr = list->phys_addr;
-   index = (list->virt_addr - table->table_base) >> block_shift;
-
-   for (j = 0; j < (list->size >> block_shift); j++) {
-   set_pgtable_section(table->ptr,
-   index,
-   block_addr,
-   list->memory_type,
-   list->attribute);
-   block_addr += block_size;
-   index++;
-   }
-
-   return 0;
-}
-
-/*
- * Find the corresponding table entry for the list.
- */
-static int find_table(const struct sys_mmu_table *list,
- struct table_info *table, u64 *level0_table)
-{
-   u64 index = 0, level = 0;
-   u64 *level_table = level0_table;
-   u64 temp_base = 0, block_size = 0, block_shift = 0;
-
-   while (level < 3) {
-   if (level == 0) {
-   block_size = BLOCK_SIZE_L0;
-   block_shift = SECTION_SHIFT_L0;
-   } else if (level == 1) {
-   block_size = BLOCK_SIZE_L1;
-   block_shift = SECTION_SHIFT_L1;
-   } else if (level == 2) {
-   block_size = BLOCK_SIZE_L2;
-   block_shift = SECTION_SHIFT_L2;
-   }
-
-   index = 0;
-   while (list->virt_addr >= temp_base) {
-   index++;
-   temp_base += block_size;
-   }
-
-   temp_base -= block_size;
-
-   if ((level_table[index - 1] & PTE_TYPE_MASK) ==
-   PTE_TYPE_TABLE) {
-   level_table = (u64 *)(level_table[index - 1] &
- ~PTE_TYPE_MASK);
-   level++;
-   continue;
-   } else {
-   if (level == 0)
-   return -EINVAL;
-
-   if ((list->phys_addr + list->size) >
-   (temp_base + block_size * NUM_OF_ENTRY))
-   return -EINVAL;
-
-   /*
-* Check the address and size of the list member is
-* aligned with the block size.
-*/
-   if (((list->phys_addr & (block_size - 1)) != 0) ||
-   ((list->size & (block_size - 1)) != 0))
-   return -EINVAL;
-
-   

Re: [U-Boot] what is the *recommended* split between defconfig file and header file?

[Tom Rini]

On Tue, Jul 19, 2016 at 04:15:47AM -0400, Robert P. J. Day wrote:

> 
>   kind of a style question but what is the preferred way to define a
> board in the sense of what belongs in the defconfig file and what
> belongs in the header file?

The header files will eventually go away.  Most of the contents are
things that could be, but haven't yet been, converted.  A few things
like default environment are going to be harder to figure out.

-- 
Tom


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

Re: [U-Boot] [v2 1/1] wandboard: fix dtb file names.

[Fabio Estevam]

On Tue, Jul 19, 2016 at 2:58 PM, Adam Duskett  wrote:

> The original patch that I submitted just changed the dts files to the new
> naming
> scheme found in 4.1.15.  Once I submitted that,

And the naming scheme in 4.1.15 vendor kernel is the problem. Make it
match the dtb names of the mainline kernel and this problem will be
solved.

Let me try to clarify: you are trying to make a U-boot change so that
it can read a dtb file called: imx6q-wandboard-revc1.dtb.

If you look at the dtb's in the mainline kernel we have (let's take
imx6q for example):

imx6q-wandboard.dtb ---> This should be used with revC1 boards
imx6q-wandboard-revb1.dtb ---> This should be used with revB1 boards

Just fix 4.1.15 to produce the same file names and then you don't need
to modify U-boot.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Resend: U-Boot PATCH v2] keystone: k2h/e/l: Fix DMA coherency for QM PDSP

[Murali Karicheri]

On 07/19/2016 02:35 PM, Murali Karicheri wrote:
> commit 1f807a9f32aa ("ARM: keystone2: Refactor MSMC macros to avoid
> left under a macro KS2_MSMC_SEGMENT_QM_PDSP which is no longer valid.
> This, in effect disabled DMA coherency for QM PDSP.
> 
> Given that msmc_k2hkle_common_setup is valid for all K2H/K/L/E SoCs,
> the #ifdef should been removed in the first place. Do the same.
> 
> Fixes: 1f807a9f32aa ("ARM: keystone2: Refactor MSMC macros to avoid 
> #ifdeffery")
> Signed-off-by: Murali Karicheri 
> Acked-by: Nishanth Menon 
> Reviewed-by: Tom Rini 
> ---
>  - v2 - fixed the prefix
>  - v1 - adding Fixes per comments and added Reviewed-by from Tom Rini
>  arch/arm/mach-keystone/init.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm/mach-keystone/init.c b/arch/arm/mach-keystone/init.c
> index 3b6d5ef..6e5a1e1 100644
> --- a/arch/arm/mach-keystone/init.c
> +++ b/arch/arm/mach-keystone/init.c
> @@ -101,9 +101,7 @@ static void msmc_k2hkle_common_setup(void)
>   msmc_share_all_segments(KS2_MSMC_SEGMENT_C6X_0);
>   msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_ARM);
>   msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_NETCP);
> -#ifdef KS2_MSMC_SEGMENT_QM_PDSP
>   msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_QM_PDSP);
> -#endif
>   msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_PCIE0);
>   msmc_share_all_segments(KS2_MSMC_SEGMENT_DEBUG);
>  }
> 
Please ignore. Will send v3 for merge. Sorry for flooding the list.

-- 
Murali Karicheri
Linux Kernel, Keystone
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [U-Boot PATCH v1] keystone: k2h/e/l: Fix DMA coherency for QM PDSP

[Murali Karicheri]

commit 1f807a9f32aa ("ARM: keystone2: Refactor MSMC macros to avoid
left under a macro KS2_MSMC_SEGMENT_QM_PDSP which is no longer valid.
This, in effect disabled DMA coherency for QM PDSP.

Given that msmc_k2hkle_common_setup is valid for all K2H/K/L/E SoCs,
the #ifdef should been removed in the first place. Do the same.

Fixes: 1f807a9f32aa ("ARM: keystone2: Refactor MSMC macros to avoid #ifdeffery")
Signed-off-by: Murali Karicheri 
Acked-by: Nishanth Menon 
Reviewed-by: Tom Rini 
---
 - v2 - fixed the prefix
 - v1 - adding Fixes per comments and added Reviewed-by from Tom Rini
 arch/arm/mach-keystone/init.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-keystone/init.c b/arch/arm/mach-keystone/init.c
index 3b6d5ef..6e5a1e1 100644
--- a/arch/arm/mach-keystone/init.c
+++ b/arch/arm/mach-keystone/init.c
@@ -101,9 +101,7 @@ static void msmc_k2hkle_common_setup(void)
msmc_share_all_segments(KS2_MSMC_SEGMENT_C6X_0);
msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_ARM);
msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_NETCP);
-#ifdef KS2_MSMC_SEGMENT_QM_PDSP
msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_QM_PDSP);
-#endif
msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_PCIE0);
msmc_share_all_segments(KS2_MSMC_SEGMENT_DEBUG);
 }
-- 
1.9.1

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