[U-Boot] [PATCH v3 1/4] QuadSPI: use QSPI_CMD_xx instead of flash opcodes
Use QSPI_CMD_xx instead of flash opcodes Signed-off-by: Peng Fan peng@freescale.com --- Changelog v3: Use QSPI_CMD_XX instead of flash opcodes. To fsl qspi controller, the LUT should be pre programmed with QSPI CMD. Changelog v2: none drivers/spi/fsl_qspi.c | 64 ++ 1 file changed, 33 insertions(+), 31 deletions(-) diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index ba20bef..61490c9 100644 --- a/drivers/spi/fsl_qspi.c +++ b/drivers/spi/fsl_qspi.c @@ -29,19 +29,19 @@ #define SEQID_PP 6 #define SEQID_RDID 7 -/* Flash opcodes */ -#define OPCODE_PP 0x02/* Page program (up to 256 bytes) */ -#define OPCODE_RDSR0x05/* Read status register */ -#define OPCODE_WREN0x06/* Write enable */ -#define OPCODE_FAST_READ 0x0b/* Read data bytes (high frequency) */ -#define OPCODE_CHIP_ERASE 0xc7/* Erase whole flash chip */ -#define OPCODE_SE 0xd8/* Sector erase (usually 64KiB) */ -#define OPCODE_RDID0x9f/* Read JEDEC ID */ - -/* 4-byte address opcodes - used on Spansion and some Macronix flashes */ -#define OPCODE_FAST_READ_4B0x0c/* Read data bytes (high frequency) */ -#define OPCODE_PP_4B 0x12/* Page program (up to 256 bytes) */ -#define OPCODE_SE_4B 0xdc/* Sector erase (usually 64KiB) */ +/* QSPI CMD */ +#define QSPI_CMD_PP0x02/* Page program (up to 256 bytes) */ +#define QSPI_CMD_RDSR 0x05/* Read status register */ +#define QSPI_CMD_WREN 0x06/* Write enable */ +#define QSPI_CMD_FAST_READ 0x0b/* Read data bytes (high frequency) */ +#define QSPI_CMD_CHIP_ERASE0xc7/* Erase whole flash chip */ +#define QSPI_CMD_SE0xd8/* Sector erase (usually 64KiB) */ +#define QSPI_CMD_RDID 0x9f/* Read JEDEC ID */ + +/* 4-byte address QSPI CMD - used on Spansion and some Macronix flashes */ +#define QSPI_CMD_FAST_READ_4B 0x0c/* Read data bytes (high frequency) */ +#define QSPI_CMD_PP_4B 0x12/* Page program (up to 256 bytes) */ +#define QSPI_CMD_SE_4B 0xdc/* Sector erase (usually 64KiB) */ #ifdef CONFIG_SYS_FSL_QSPI_LE #define qspi_read32in_le32 @@ -94,7 +94,7 @@ static void qspi_set_lut(struct fsl_qspi *qspi) /* Write Enable */ lut_base = SEQID_WREN * 4; - qspi_write32(regs-lut[lut_base], OPRND0(OPCODE_WREN) | + qspi_write32(regs-lut[lut_base], OPRND0(QSPI_CMD_WREN) | PAD0(LUT_PAD1) | INSTR0(LUT_CMD)); qspi_write32(regs-lut[lut_base + 1], 0); qspi_write32(regs-lut[lut_base + 2], 0); @@ -103,13 +103,15 @@ static void qspi_set_lut(struct fsl_qspi *qspi) /* Fast Read */ lut_base = SEQID_FAST_READ * 4; if (FSL_QSPI_FLASH_SIZE = SZ_16M) - qspi_write32(regs-lut[lut_base], OPRND0(OPCODE_FAST_READ) | + qspi_write32(regs-lut[lut_base], OPRND0(QSPI_CMD_FAST_READ) | PAD0(LUT_PAD1) | INSTR0(LUT_CMD) | OPRND1(ADDR24BIT) | PAD1(LUT_PAD1) | INSTR1(LUT_ADDR)); else - qspi_write32(regs-lut[lut_base], OPRND0(OPCODE_FAST_READ_4B) | - PAD0(LUT_PAD1) | INSTR0(LUT_CMD) | OPRND1(ADDR32BIT) | - PAD1(LUT_PAD1) | INSTR1(LUT_ADDR)); + qspi_write32(regs-lut[lut_base], +OPRND0(QSPI_CMD_FAST_READ_4B) | +PAD0(LUT_PAD1) | INSTR0(LUT_CMD) | +OPRND1(ADDR32BIT) | PAD1(LUT_PAD1) | +INSTR1(LUT_ADDR)); qspi_write32(regs-lut[lut_base + 1], OPRND0(8) | PAD0(LUT_PAD1) | INSTR0(LUT_DUMMY) | OPRND1(RX_BUFFER_SIZE) | PAD1(LUT_PAD1) | INSTR1(LUT_READ)); @@ -118,7 +120,7 @@ static void qspi_set_lut(struct fsl_qspi *qspi) /* Read Status */ lut_base = SEQID_RDSR * 4; - qspi_write32(regs-lut[lut_base], OPRND0(OPCODE_RDSR) | + qspi_write32(regs-lut[lut_base], OPRND0(QSPI_CMD_RDSR) | PAD0(LUT_PAD1) | INSTR0(LUT_CMD) | OPRND1(1) | PAD1(LUT_PAD1) | INSTR1(LUT_READ)); qspi_write32(regs-lut[lut_base + 1], 0); @@ -128,11 +130,11 @@ static void qspi_set_lut(struct fsl_qspi *qspi) /* Erase a sector */ lut_base = SEQID_SE * 4; if (FSL_QSPI_FLASH_SIZE = SZ_16M) - qspi_write32(regs-lut[lut_base], OPRND0(OPCODE_SE) | + qspi_write32(regs-lut[lut_base], OPRND0(QSPI_CMD_SE) | PAD0(LUT_PAD1) | INSTR0(LUT_CMD) | OPRND1(ADDR24BIT) | PAD1(LUT_PAD1) | INSTR1(LUT_ADDR)); else - qspi_write32(regs-lut[lut_base], OPRND0(OPCODE_SE_4B) | + qspi_write32(regs-lut[lut_base], OPRND0(QSPI_CMD_SE_4B) | PAD0(LUT_PAD1) | INSTR0(LUT_CMD) |
[U-Boot] [PATCH v3 2/4] QuadSPI: use correct amba_base
According cs, use different amba_base to choose the corresponding flash devices. If not, `sf probe 1:0` and `sf probe 1:1` will choose the same flash device, but not different flash devices. Signed-off-by: Peng Fan peng@freescale.com --- Changelog v3: none Changelog v2: none drivers/spi/fsl_qspi.c | 30 +- 1 file changed, 25 insertions(+), 5 deletions(-) diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index 61490c9..eae2f3a 100644 --- a/drivers/spi/fsl_qspi.c +++ b/drivers/spi/fsl_qspi.c @@ -194,12 +194,22 @@ struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs, if (bus = ARRAY_SIZE(spi_bases)) return NULL; + if (cs = FSL_QSPI_FLASH_NUM) + return NULL; + qspi = spi_alloc_slave(struct fsl_qspi, bus, cs); if (!qspi) return NULL; qspi-reg_base = spi_bases[bus]; - qspi-amba_base = amba_bases[bus]; + /* +* According cs, use different amba_base to choose the +* corresponding flash devices. +* +* If not, only one flash device is used even if passing +* different cs using `sf probe` +*/ + qspi-amba_base = amba_bases[bus] + cs * FSL_QSPI_FLASH_SIZE; qspi-slave.max_write_size = TX_BUFFER_SIZE; @@ -212,10 +222,20 @@ struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs, qspi_write32(regs-mcr, QSPI_MCR_RESERVED_MASK); total_size = FSL_QSPI_FLASH_SIZE * FSL_QSPI_FLASH_NUM; - qspi_write32(regs-sfa1ad, FSL_QSPI_FLASH_SIZE | qspi-amba_base); - qspi_write32(regs-sfa2ad, FSL_QSPI_FLASH_SIZE | qspi-amba_base); - qspi_write32(regs-sfb1ad, total_size | qspi-amba_base); - qspi_write32(regs-sfb2ad, total_size | qspi-amba_base); + /* +* Any read access to non-implemented addresses will provide +* undefined results. +* +* In case single die flash devices, TOP_ADDR_MEMA2 and +* TOP_ADDR_MEMB2 should be initialized/programmed to +* TOP_ADDR_MEMA1 and TOP_ADDR_MEMB1 respectively - in effect, +* setting the size of these devices to 0. This would ensure +* that the complete memory map is assigned to only one flash device. +*/ + qspi_write32(regs-sfa1ad, FSL_QSPI_FLASH_SIZE | amba_bases[bus]); + qspi_write32(regs-sfa2ad, FSL_QSPI_FLASH_SIZE | amba_bases[bus]); + qspi_write32(regs-sfb1ad, total_size | amba_bases[bus]); + qspi_write32(regs-sfb2ad, total_size | amba_bases[bus]); qspi_set_lut(qspi); -- 1.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/4] arm:mx6sx add QSPI support
Add QSPI support for mx6solox.
Signed-off-by: Peng Fan peng@freescale.com
---
Changelog v3:
none
Changelog v2:
Take Fabio's suggestion, split soc code and board code into two patches.
arch/arm/cpu/armv7/mx6/clock.c | 50
arch/arm/include/asm/arch-mx6/clock.h| 1 +
arch/arm/include/asm/arch-mx6/imx-regs.h | 12
drivers/spi/fsl_qspi.c | 19
4 files changed, 76 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index d200531..d11f98e 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -430,6 +430,56 @@ static u32 get_mmdc_ch0_clk(void)
}
#endif
+#ifdef CONFIG_MX6SX
+/* qspi_num can be from 0 - 1 */
+void enable_qspi_clk(int qspi_num)
+{
+ u32 reg = 0;
+ /* Enable QuadSPI clock */
+ switch (qspi_num) {
+ case 0:
+ /* disable the clock gate */
+ clrbits_le32(imx_ccm-CCGR3, MXC_CCM_CCGR3_QSPI1_MASK);
+
+ /* set 50M : (50 = 396 / 2 / 4) */
+ reg = readl(imx_ccm-cscmr1);
+ reg = ~(MXC_CCM_CSCMR1_QSPI1_PODF_MASK |
+MXC_CCM_CSCMR1_QSPI1_CLK_SEL_MASK);
+ reg |= ((1 MXC_CCM_CSCMR1_QSPI1_PODF_OFFSET) |
+ (2 MXC_CCM_CSCMR1_QSPI1_CLK_SEL_OFFSET));
+ writel(reg, imx_ccm-cscmr1);
+
+ /* enable the clock gate */
+ setbits_le32(imx_ccm-CCGR3, MXC_CCM_CCGR3_QSPI1_MASK);
+ break;
+ case 1:
+ /*
+* disable the clock gate
+* QSPI2 and GPMI_BCH_INPUT_GPMI_IO share the same clock gate,
+* disable both of them.
+*/
+ clrbits_le32(imx_ccm-CCGR4, MXC_CCM_CCGR4_QSPI2_ENFC_MASK |
+
MXC_CCM_CCGR4_RAWNAND_U_GPMI_BCH_INPUT_GPMI_IO_MASK);
+
+ /* set 50M : (50 = 396 / 2 / 4) */
+ reg = readl(imx_ccm-cs2cdr);
+ reg = ~(MXC_CCM_CS2CDR_QSPI2_CLK_PODF_MASK |
+MXC_CCM_CS2CDR_QSPI2_CLK_PRED_MASK |
+MXC_CCM_CS2CDR_QSPI2_CLK_SEL_MASK);
+ reg |= (MXC_CCM_CS2CDR_QSPI2_CLK_PRED(0x1) |
+ MXC_CCM_CS2CDR_QSPI2_CLK_SEL(0x3));
+ writel(reg, imx_ccm-cs2cdr);
+
+ /*enable the clock gate*/
+ setbits_le32(imx_ccm-CCGR4, MXC_CCM_CCGR4_QSPI2_ENFC_MASK |
+
MXC_CCM_CCGR4_RAWNAND_U_GPMI_BCH_INPUT_GPMI_IO_MASK);
+ break;
+ default:
+ break;
+ }
+}
+#endif
+
#ifdef CONFIG_FEC_MXC
int enable_fec_anatop_clock(enum enet_freq freq)
{
diff --git a/arch/arm/include/asm/arch-mx6/clock.h
b/arch/arm/include/asm/arch-mx6/clock.h
index 3c58a0a..4eb5ba4 100644
--- a/arch/arm/include/asm/arch-mx6/clock.h
+++ b/arch/arm/include/asm/arch-mx6/clock.h
@@ -66,4 +66,5 @@ int enable_spi_clk(unsigned char enable, unsigned spi_num);
void enable_ipu_clock(void);
int enable_fec_anatop_clock(enum enet_freq freq);
void enable_enet_clk(unsigned char enable);
+void enable_qspi_clk(int qspi_num);
#endif /* __ASM_ARCH_CLOCK_H */
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index a159309..5d07904 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -92,10 +92,10 @@
#define AIPS3_END_ADDR 0x022F
#define WEIM_ARB_BASE_ADDR 0x5000
#define WEIM_ARB_END_ADDR 0x57FF
-#define QSPI1_ARB_BASE_ADDR 0x6000
-#define QSPI1_ARB_END_ADDR 0x6FFF
-#define QSPI2_ARB_BASE_ADDR 0x7000
-#define QSPI2_ARB_END_ADDR 0x7FFF
+#define QSPI0_AMBA_BASE0x6000
+#define QSPI0_AMBA_END 0x6FFF
+#define QSPI1_AMBA_BASE0x7000
+#define QSPI1_AMBA_END 0x7FFF
#else
#define SATA_ARB_BASE_ADDR 0x0220
#define SATA_ARB_END_ADDR 0x02203FFF
@@ -262,8 +262,8 @@
#define AUDMUX_BASE_ADDR(AIPS2_OFF_BASE_ADDR + 0x58000)
#ifdef CONFIG_MX6SX
#define SAI2_BASE_ADDR (AIPS2_OFF_BASE_ADDR + 0x5C000)
-#define QSPI1_BASE_ADDR (AIPS2_OFF_BASE_ADDR + 0x6)
-#define QSPI2_BASE_ADDR (AIPS2_OFF_BASE_ADDR + 0x64000)
+#define QSPI0_BASE_ADDR (AIPS2_OFF_BASE_ADDR + 0x6)
+#define QSPI1_BASE_ADDR (AIPS2_OFF_BASE_ADDR + 0x64000)
#else
#define MIPI_CSI2_BASE_ADDR (AIPS2_OFF_BASE_ADDR + 0x5C000)
#define MIPI_DSI_BASE_ADDR (AIPS2_OFF_BASE_ADDR + 0x6)
diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index eae2f3a..e9c45de 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -14,7 +14,11 @@
#include fsl_qspi.h
#define RX_BUFFER_SIZE
[U-Boot] [PATCH v3 4/4] imx:mx6sxsabresd add qspi support
Configure the pad setting and enable qspi clock to support qspi
flashes access.
Signed-off-by: Peng Fan peng@freescale.com
---
Changelog v3:
none
Changelog v2:
Take Fabio's suggestion, split soc code and board code into two patches.
board/freescale/mx6sxsabresd/mx6sxsabresd.c | 40 +
include/configs/mx6sxsabresd.h | 12 +
2 files changed, 52 insertions(+)
diff --git a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
index 68d3718..0d8b214 100644
--- a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
+++ b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
@@ -272,11 +272,51 @@ int board_mmc_init(bd_t *bis)
return fsl_esdhc_initialize(bis, usdhc_cfg[0]);
}
+#ifdef CONFIG_FSL_QSPI
+
+#define QSPI_PAD_CTRL1 \
+ (PAD_CTL_SRE_FAST | PAD_CTL_SPEED_HIGH | \
+PAD_CTL_PKE | PAD_CTL_PUE | PAD_CTL_PUS_47K_UP | PAD_CTL_DSE_40ohm)
+
+static iomux_v3_cfg_t const quadspi_pads[] = {
+ MX6_PAD_NAND_WP_B__QSPI2_A_DATA_0 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_READY_B__QSPI2_A_DATA_1| MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_CE0_B__QSPI2_A_DATA_2 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_CE1_B__QSPI2_A_DATA_3 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_ALE__QSPI2_A_SS0_B | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_CLE__QSPI2_A_SCLK | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA07__QSPI2_A_DQS| MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA01__QSPI2_B_DATA_0 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA00__QSPI2_B_DATA_1 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_WE_B__QSPI2_B_DATA_2 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_RE_B__QSPI2_B_DATA_3 | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA03__QSPI2_B_SS0_B | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA02__QSPI2_B_SCLK | MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+ MX6_PAD_NAND_DATA05__QSPI2_B_DQS| MUX_PAD_CTRL(QSPI_PAD_CTRL1),
+};
+
+int board_qspi_init(void)
+{
+ /* Set the iomux */
+ imx_iomux_v3_setup_multiple_pads(quadspi_pads,
+ARRAY_SIZE(quadspi_pads));
+
+ /* Set the clock */
+ enable_qspi_clk(1);
+
+ return 0;
+}
+#endif
+
int board_init(void)
{
/* Address of boot parameters */
gd-bd-bi_boot_params = PHYS_SDRAM + 0x100;
+#ifdef CONFIG_FSL_QSPI
+ board_qspi_init();
+#endif
+
return 0;
}
diff --git a/include/configs/mx6sxsabresd.h b/include/configs/mx6sxsabresd.h
index e02ea18..032be89 100644
--- a/include/configs/mx6sxsabresd.h
+++ b/include/configs/mx6sxsabresd.h
@@ -211,6 +211,18 @@
/* FLASH and environment organization */
#define CONFIG_SYS_NO_FLASH
+#define CONFIG_FSL_QSPI
+
+#ifdef CONFIG_FSL_QSPI
+#define CONFIG_CMD_SF
+#define CONFIG_SPI_FLASH
+#define CONFIG_SPI_FLASH_SPANSION
+#define CONFIG_SPI_FLASH_STMICRO
+#define CONFIG_SYS_FSL_QSPI_LE
+#define FSL_QSPI_FLASH_SIZESZ_16M
+#define FSL_QSPI_FLASH_NUM 2
+#endif
+
#define CONFIG_ENV_OFFSET (6 * SZ_64K)
#define CONFIG_ENV_SIZESZ_8K
#define CONFIG_ENV_IS_IN_MMC
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] net: Add a command to access the EEPROM from ethernet devices
On Mon, Oct 13, 2014 at 3:56 AM, Alban Bedel alban.be...@avionic-design.de wrote: On Thu, 9 Oct 2014 17:17:00 +0200 Marek Vasut ma...@denx.de wrote: On Thursday, October 09, 2014 at 01:42:49 PM, Alban Bedel wrote: Many ethernet devices use an EEPROM to store various settings, most commonly the device MAC address. But on some devices it can contains a lot more, for example USB device might also have many USB related parameters. This commit add a set of commands to read/write this EEPROM, write a default configuration and read/write the device MAC address. The defaults command allow priming the EEPROM for devices that need more than just a MAC address in the EEPROM. Signed-off-by: Alban Bedel alban.be...@avionic-design.de I will not comment on the code yet, but would like to discuss the concept instead. I wonder, can we not have a more generic command here? One which can manage the ethernet device altogether, not just adjust it's eeprom? Something like 'ethtool' in Linux ... What do you think please ? Currently this is all I need for the boards I'm working on. However I have no problem with splitting the command from 'eth_eeprom' to 'eth eeprom' to leave room for other stuff. I agree that the command would be better if it was eth eeprom -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] mmc: fsl_esdhc: Update esdhc driver for iMX6SX
The reset value of uSDHCx_INT_STATUS_EN register is changed to 0
on iMX6SX. So the fsl_esdhc driver must update to set the register,
otherwise no state can be detected.
Signed-off-by: Ye.Li b37...@freescale.com
---
Changes since v1:
- Remove codes which set INT_STATUS_EN register according PIO or DMA mode.
drivers/mmc/fsl_esdhc.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 97d0389..bca86a8 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -23,6 +23,13 @@
DECLARE_GLOBAL_DATA_PTR;
+#define SDHCI_IRQ_EN_BITS (IRQSTATEN_CC | IRQSTATEN_TC | \
+ IRQSTATEN_CINT | \
+ IRQSTATEN_CTOE | IRQSTATEN_CCE | IRQSTATEN_CEBE
| \
+ IRQSTATEN_CIE | IRQSTATEN_DTOE | IRQSTATEN_DCE
| \
+ IRQSTATEN_DEBE | IRQSTATEN_BRR | IRQSTATEN_BWR
| \
+ IRQSTATEN_DINT)
+
struct fsl_esdhc {
uintdsaddr; /* SDMA system address register */
uintblkattr;/* Block attributes register */
@@ -558,6 +565,7 @@ int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg
*cfg)
esdhc_setbits32(regs-sysctl, SYSCTL_PEREN | SYSCTL_HCKEN
| SYSCTL_IPGEN | SYSCTL_CKEN);
+ writel(SDHCI_IRQ_EN_BITS, regs-irqstaten);
memset(cfg-cfg, 0, sizeof(cfg-cfg));
voltage_caps = 0;
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] imx: mx6sxsabresd: Add board support for USDHC2 and USDHC3
Add full support for USDHC2, USDHC3, USDHC4 on mx6sx sabresd board.
The default boot socket is USDHC4, so the MMC environment is set to
this device.
Signed-off-by: Ye.Li b37...@freescale.com
---
Changes since v1:
- Modify the function return value
board/freescale/mx6sxsabresd/mx6sxsabresd.c | 99 +--
include/configs/mx6sxsabresd.h |6 ++-
2 files changed, 99 insertions(+), 6 deletions(-)
diff --git a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
index 68d3718..f78 100644
--- a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
+++ b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
@@ -68,6 +68,34 @@ static iomux_v3_cfg_t const uart1_pads[] = {
MX6_PAD_GPIO1_IO05__UART1_RX | MUX_PAD_CTRL(UART_PAD_CTRL),
};
+static iomux_v3_cfg_t const usdhc2_pads[] = {
+ MX6_PAD_SD2_CLK__USDHC2_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD2_CMD__USDHC2_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD2_DATA0__USDHC2_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD2_DATA1__USDHC2_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD2_DATA2__USDHC2_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD2_DATA3__USDHC2_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+};
+
+static iomux_v3_cfg_t const usdhc3_pads[] = {
+ MX6_PAD_SD3_CLK__USDHC3_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD3_CMD__USDHC3_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD3_DATA0__USDHC3_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD3_DATA1__USDHC3_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD3_DATA2__USDHC3_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD3_DATA3__USDHC3_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD3_DATA4__USDHC3_DATA4 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD3_DATA5__USDHC3_DATA5 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD3_DATA6__USDHC3_DATA6 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD3_DATA7__USDHC3_DATA7 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+
+ /* CD pin */
+ MX6_PAD_KEY_COL0__GPIO2_IO_10 | MUX_PAD_CTRL(NO_PAD_CTRL),
+
+ /* RST_B, used for power reset cycle */
+ MX6_PAD_KEY_COL1__GPIO2_IO_11 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
static iomux_v3_cfg_t const usdhc4_pads[] = {
MX6_PAD_SD4_CLK__USDHC4_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
MX6_PAD_SD4_CMD__USDHC4_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
@@ -255,23 +283,84 @@ int board_early_init_f(void)
return 0;
}
-static struct fsl_esdhc_cfg usdhc_cfg[1] = {
+static struct fsl_esdhc_cfg usdhc_cfg[3] = {
+ {USDHC2_BASE_ADDR, 0, 4},
+ {USDHC3_BASE_ADDR},
{USDHC4_BASE_ADDR},
};
+#define USDHC3_CD_GPIO IMX_GPIO_NR(2, 10)
+#define USDHC3_PWR_GPIOIMX_GPIO_NR(2, 11)
+#define USDHC4_CD_GPIO IMX_GPIO_NR(6, 21)
+
int board_mmc_getcd(struct mmc *mmc)
{
- return 1; /* Assume boot SD always present */
+ struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
+ int ret = 0;
+
+ switch (cfg-esdhc_base) {
+ case USDHC2_BASE_ADDR:
+ ret = 1; /* Assume uSDHC2 is always present */
+ break;
+ case USDHC3_BASE_ADDR:
+ ret = !gpio_get_value(USDHC3_CD_GPIO);
+ break;
+ case USDHC4_BASE_ADDR:
+ ret = !gpio_get_value(USDHC4_CD_GPIO);
+ break;
+ }
+
+ return ret;
}
int board_mmc_init(bd_t *bis)
{
- imx_iomux_v3_setup_multiple_pads(usdhc4_pads, ARRAY_SIZE(usdhc4_pads));
+ int i, ret;
- usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC4_CLK);
- return fsl_esdhc_initialize(bis, usdhc_cfg[0]);
+ /*
+* According to the board_mmc_init() the following map is done:
+* (U-boot device node)(Physical Port)
+* mmc0USDHC2
+* mmc1USDHC3
+* mmc2USDHC4
+*/
+ for (i = 0; i CONFIG_SYS_FSL_USDHC_NUM; i++) {
+ switch (i) {
+ case 0:
+ imx_iomux_v3_setup_multiple_pads(
+ usdhc2_pads, ARRAY_SIZE(usdhc2_pads));
+ usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC2_CLK);
+ break;
+ case 1:
+ imx_iomux_v3_setup_multiple_pads(
+ usdhc3_pads, ARRAY_SIZE(usdhc3_pads));
+ gpio_direction_input(USDHC3_CD_GPIO);
+ gpio_direction_output(USDHC3_PWR_GPIO, 1);
+ usdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
+ break;
+ case 2:
+ imx_iomux_v3_setup_multiple_pads(
+ usdhc4_pads, ARRAY_SIZE(usdhc4_pads));
+ gpio_direction_input(USDHC4_CD_GPIO);
+ usdhc_cfg[2].sdhc_clk =
[U-Boot] [PATCH v2 2/2] imx: mx6slevk: Add support for USDHC1 and USDHC3 slots
There are three SD/MMC sockets on mx6slevk boards. Implements the
full support for them.
The default boot socket is USDHC2, so the MMC environment is set
to that device.
Signed-off-by: Ye.Li b37...@freescale.com
---
Changes since v1:
- Correct the return value of board_mmc_init function
board/freescale/mx6slevk/mx6slevk.c | 104 +--
include/configs/mx6slevk.h |6 ++-
2 files changed, 103 insertions(+), 7 deletions(-)
diff --git a/board/freescale/mx6slevk/mx6slevk.c
b/board/freescale/mx6slevk/mx6slevk.c
index a990b4c..d543962 100644
--- a/board/freescale/mx6slevk/mx6slevk.c
+++ b/board/freescale/mx6slevk/mx6slevk.c
@@ -51,6 +51,23 @@ static iomux_v3_cfg_t const uart1_pads[] = {
MX6_PAD_UART1_RXD__UART1_RXD | MUX_PAD_CTRL(UART_PAD_CTRL),
};
+static iomux_v3_cfg_t const usdhc1_pads[] = {
+ /* 8 bit SD */
+ MX6_PAD_SD1_CLK__USDHC1_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD1_CMD__USDHC1_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD1_DAT0__USDHC1_DAT0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD1_DAT1__USDHC1_DAT1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD1_DAT2__USDHC1_DAT2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD1_DAT3__USDHC1_DAT3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD1_DAT4__USDHC1_DAT4 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD1_DAT5__USDHC1_DAT5 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD1_DAT6__USDHC1_DAT6 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD1_DAT7__USDHC1_DAT7 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+
+ /*CD pin*/
+ MX6_PAD_KEY_ROW7__GPIO_4_7 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
static iomux_v3_cfg_t const usdhc2_pads[] = {
MX6_PAD_SD2_CLK__USDHC2_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
MX6_PAD_SD2_CMD__USDHC2_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
@@ -58,6 +75,21 @@ static iomux_v3_cfg_t const usdhc2_pads[] = {
MX6_PAD_SD2_DAT1__USDHC2_DAT1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
MX6_PAD_SD2_DAT2__USDHC2_DAT2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
MX6_PAD_SD2_DAT3__USDHC2_DAT3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+
+ /*CD pin*/
+ MX6_PAD_SD2_DAT7__GPIO_5_0 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
+static iomux_v3_cfg_t const usdhc3_pads[] = {
+ MX6_PAD_SD3_CLK__USDHC3_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD3_CMD__USDHC3_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD3_DAT0__USDHC3_DAT0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD3_DAT1__USDHC3_DAT1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD3_DAT2__USDHC3_DAT2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_SD3_DAT3__USDHC3_DAT3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+
+ /*CD pin*/
+ MX6_PAD_REF_CLK_32K__GPIO_3_22 | MUX_PAD_CTRL(NO_PAD_CTRL),
};
static iomux_v3_cfg_t const fec_pads[] = {
@@ -103,21 +135,81 @@ static void setup_iomux_fec(void)
gpio_set_value(ETH_PHY_RESET, 1);
}
-static struct fsl_esdhc_cfg usdhc_cfg[1] = {
- {USDHC2_BASE_ADDR},
+#define USDHC1_CD_GPIO IMX_GPIO_NR(4, 7)
+#define USDHC2_CD_GPIO IMX_GPIO_NR(5, 0)
+#define USDHC3_CD_GPIO IMX_GPIO_NR(3, 22)
+
+static struct fsl_esdhc_cfg usdhc_cfg[3] = {
+ {USDHC1_BASE_ADDR},
+ {USDHC2_BASE_ADDR, 0, 4},
+ {USDHC3_BASE_ADDR, 0, 4},
};
int board_mmc_getcd(struct mmc *mmc)
{
- return 1; /* Assume boot SD always present */
+ struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
+ int ret = 0;
+
+ switch (cfg-esdhc_base) {
+ case USDHC1_BASE_ADDR:
+ ret = !gpio_get_value(USDHC1_CD_GPIO);
+ break;
+ case USDHC2_BASE_ADDR:
+ ret = !gpio_get_value(USDHC2_CD_GPIO);
+ break;
+ case USDHC3_BASE_ADDR:
+ ret = !gpio_get_value(USDHC3_CD_GPIO);
+ break;
+ }
+
+ return ret;
}
int board_mmc_init(bd_t *bis)
{
- imx_iomux_v3_setup_multiple_pads(usdhc2_pads, ARRAY_SIZE(usdhc2_pads));
+ int i, ret;
+
+ /*
+* According to the board_mmc_init() the following map is done:
+* (U-boot device node)(Physical Port)
+* mmc0USDHC1
+* mmc1USDHC2
+* mmc2USDHC3
+*/
+ for (i = 0; i CONFIG_SYS_FSL_USDHC_NUM; i++) {
+ switch (i) {
+ case 0:
+ imx_iomux_v3_setup_multiple_pads(
+ usdhc1_pads, ARRAY_SIZE(usdhc1_pads));
+ gpio_direction_input(USDHC1_CD_GPIO);
+ usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
+ break;
+ case 1:
+ imx_iomux_v3_setup_multiple_pads(
+ usdhc2_pads, ARRAY_SIZE(usdhc2_pads));
+ gpio_direction_input(USDHC2_CD_GPIO);
+ usdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC2_CLK);
+
[U-Boot] [PATCH v2 1/2] imx: mx6sl: Add IOMUX setting for USDHC1-3
Set the USDHC1-3 IOMUX settings which are used for mx6slevk board.
Signed-off-by: Ye.Li b37...@freescale.com
---
Changes since v1:
- None
arch/arm/include/asm/arch-mx6/mx6sl_pins.h | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
index 045ccc4..d9db58c 100644
--- a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
@@ -14,12 +14,31 @@ enum {
MX6_PAD_ECSPI1_MOSI__ECSPI_MOSI =
IOMUX_PAD(0x035C, 0x006C, 0, 0x0688, 0, 0),
MX6_PAD_ECSPI1_SCLK__ECSPI_SCLK =
IOMUX_PAD(0x0360, 0x0070, 0, 0x067C, 0, 0),
MX6_PAD_ECSPI1_SS0__GPIO4_IO11 =
IOMUX_PAD(0x0364, 0x0074, 5, 0x, 0, 0),
+ MX6_PAD_SD1_CLK__USDHC1_CLK =
IOMUX_PAD(0x0534, 0x022C, 0, 0x, 0, 0),
+ MX6_PAD_SD1_CMD__USDHC1_CMD =
IOMUX_PAD(0x0538, 0x0230, 0, 0x, 0, 0),
+ MX6_PAD_SD1_DAT0__USDHC1_DAT0 =
IOMUX_PAD(0x053C, 0x0234, 0, 0x, 0, 0),
+ MX6_PAD_SD1_DAT1__USDHC1_DAT1 =
IOMUX_PAD(0x0540, 0x0238, 0, 0x, 0, 0),
+ MX6_PAD_SD1_DAT2__USDHC1_DAT2 =
IOMUX_PAD(0x0544, 0x023C, 0, 0x, 0, 0),
+ MX6_PAD_SD1_DAT3__USDHC1_DAT3 =
IOMUX_PAD(0x0548, 0x0240, 0, 0x, 0, 0),
+ MX6_PAD_SD1_DAT4__USDHC1_DAT4 =
IOMUX_PAD(0x054C, 0x0244, 0, 0x, 0, 0),
+ MX6_PAD_SD1_DAT5__USDHC1_DAT5 =
IOMUX_PAD(0x0550, 0x0248, 0, 0x, 0, 0),
+ MX6_PAD_SD1_DAT6__USDHC1_DAT6 =
IOMUX_PAD(0x0554, 0x024C, 0, 0x, 0, 0),
+ MX6_PAD_SD1_DAT7__USDHC1_DAT7 =
IOMUX_PAD(0x0558, 0x0250, 0, 0x, 0, 0),
+ MX6_PAD_KEY_ROW7__GPIO_4_7 =
IOMUX_PAD(0x04B0, 0x01A8, 5, 0x, 0, 0),
MX6_PAD_SD2_CLK__USDHC2_CLK =
IOMUX_PAD(0x055C, 0x0254, 0, 0x, 0, 0),
MX6_PAD_SD2_CMD__USDHC2_CMD =
IOMUX_PAD(0x0560, 0x0258, 0, 0x, 0, 0),
MX6_PAD_SD2_DAT0__USDHC2_DAT0 =
IOMUX_PAD(0x0564, 0x025C, 0, 0x, 0, 0),
MX6_PAD_SD2_DAT1__USDHC2_DAT1 =
IOMUX_PAD(0x0568, 0x0260, 0, 0x, 0, 0),
MX6_PAD_SD2_DAT2__USDHC2_DAT2 =
IOMUX_PAD(0x056C, 0x0264, 0, 0x, 0, 0),
MX6_PAD_SD2_DAT3__USDHC2_DAT3 =
IOMUX_PAD(0x0570, 0x0268, 0, 0x, 0, 0),
+ MX6_PAD_SD2_DAT7__GPIO_5_0 =
IOMUX_PAD(0x0580, 0x0278, 5, 0x, 0, 0),
+ MX6_PAD_SD3_CLK__USDHC3_CLK =
IOMUX_PAD(0x0588, 0x0280, 0, 0x, 0, 0),
+ MX6_PAD_SD3_CMD__USDHC3_CMD =
IOMUX_PAD(0x058C, 0x0284, 0, 0x, 0, 0),
+ MX6_PAD_SD3_DAT0__USDHC3_DAT0 =
IOMUX_PAD(0x0590, 0x0288, 0, 0x, 0, 0),
+ MX6_PAD_SD3_DAT1__USDHC3_DAT1 =
IOMUX_PAD(0x0594, 0x028C, 0, 0x, 0, 0),
+ MX6_PAD_SD3_DAT2__USDHC3_DAT2 =
IOMUX_PAD(0x0598, 0x0290, 0, 0x, 0, 0),
+ MX6_PAD_SD3_DAT3__USDHC3_DAT3 =
IOMUX_PAD(0x059C, 0x0294, 0, 0x, 0, 0),
+ MX6_PAD_REF_CLK_32K__GPIO_3_22 =
IOMUX_PAD(0x0530, 0x0228, 5, 0x, 0, 0),
MX6_PAD_UART1_RXD__UART1_RXD=
IOMUX_PAD(0x05A0, 0x0298, 0, 0x07FC, 0, 0),
MX6_PAD_UART1_TXD__UART1_TXD=
IOMUX_PAD(0x05A4, 0x029C, 0, 0x, 0, 0),
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] dm: imx: i2c: Use gpio_request() to request GPIOs
Hi Stefan, On 3 October 2014 08:39, Igor Grinberg grinb...@compulab.co.il wrote: On 10/02/14 17:17, Nikita Kiryanov wrote: From: Simon Glass s...@chromium.org GPIOs should be requested before use. Without this, driver model will not permit the GPIO to be used. Cc: Igor Grinberg grinb...@compulab.co.il Signed-off-by: Simon Glass s...@chromium.org Signed-off-by: Nikita Kiryanov nik...@compulab.co.il I like the small functionality oriented changes much more. Acked-by: Igor Grinberg grinb...@compulab.co.il I plan to pull these two patches from Nikita into u-boot-dm along with my other IMX and DM patches. It needs to come after SPI and there are about 8 series in the line. Is that OK with you? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/14] dm: omap: Provide access to driver model for am335x, and move boards
Hi, On 22 September 2014 17:48, Simon Glass s...@chromium.org wrote: This series adjusts the serial and GPIO drivers, used by Beaglebone for example, to work with driver model. Since there are still boards using these drivers but not driver model, this adds new functionality rather than replacing what exists. Several patches tweak and fix the existing driver model serial and GPIO implementation. There are two Beaglebone Black configurations: - Device tree control with verified boot - No device tree control The first uses device tree to select the serial console and provide information needed by the serial driver (similar to how things work on Tegra). The second uses platform data provided by a common board file. Both are converted, so this is a good example of how to support both device tree and platform data if needed. Are there any comments on this series please? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: serial: Fix breakage due to stdio changes
Hi Tom, On 10 October 2014 05:06, Simon Glass s...@chromium.org wrote: Commit 32d0192 broke the sandbox build - fix it. Signed-off-by: Simon Glass s...@chromium.org --- drivers/serial/serial-uclass.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c index fd010ca..6dde4ea 100644 --- a/drivers/serial/serial-uclass.c +++ b/drivers/serial/serial-uclass.c @@ -198,7 +198,7 @@ static int serial_pre_remove(struct udevice *dev) #ifdef CONFIG_SYS_STDIO_DEREGISTER struct serial_dev_priv *upriv = dev-uclass_priv; - if (stdio_deregister_dev(upriv-sdev), 0) + if (stdio_deregister_dev(upriv-sdev, 0)) return -EPERM; #endif Can you please pick up this one? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v10 14/14] RFC: Deprecate MAKEALL
Hi Tom, On 28 August 2014 17:43, Simon Glass s...@chromium.org wrote: Since buildman now includes most of the features of MAKEALL it is probably time to talk about deprecating MAKEALL. Comments welcome. Signed-off-by: Simon Glass s...@chromium.org Should this patch go in the release? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Broken target
On Mon, Oct 13, 2014 at 12:44:32PM -0300, Otavio Salvador wrote: On Mon, Oct 13, 2014 at 9:38 AM, Tom Rini tr...@ti.com wrote: On Mon, Oct 13, 2014 at 09:08:09AM -0300, Otavio Salvador wrote: On Mon, Oct 13, 2014 at 5:53 AM, Tom Rini tr...@ti.com wrote: On Sun, Oct 12, 2014 at 05:48:37PM -0300, Otavio Salvador wrote: The 'tools-only' target seems to be broken. In a clean tree (no previous build) running: $: make tools-only fails with: CHK include/config/uboot.release /bin/sh: 1: cannot open include/config/auto.conf: No such file Makefile:1049: recipe for target 'include/config/uboot.release' failed make: *** [include/config/uboot.release] Error 2 Any idea about the root cause? it is a regression as 2014.07 works fine in this case. Well blah. The issue is that we support CONFIG_LOCALVERSION now and a few parts of tools-only use PLAIN_VERSION (some just for version printing but at least once for the DT in signed images). So a no-config tools-only build isn't posible again unless we want to ignore LOCALVERSION. I would assume it to trigger: make defconfig make silientoldconfig by itself. So it could be used in old build recipes with no changes. Here's what I can do. If you do sandbox_config and then tools-only and I take tools-only out of the no config required list (because it's not true!) it will work in both v2014.04 (when tools-only was introduced) and v2014.10. In 2014.04, 2014.07 I had our tools recipe, in Yocto Project succeed when calling only 'make tools-only'. Right, we had Kbuild but not Kconfig support then, so no CONFIG_LOCALVERSION to further modify the version string. I think it is a drawback to require the sandbox explicit call before building it now. I can live with that seems not right. It's a feature, not a bug, that you need to have the config processed. I had a suggested possible use before I recalled that OE strips out the githash from kernel builds tho. -- 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] [PATCH v10 14/14] RFC: Deprecate MAKEALL
On Tue, Oct 14, 2014 at 09:38:36AM +0200, Simon Glass wrote: Hi Tom, On 28 August 2014 17:43, Simon Glass s...@chromium.org wrote: Since buildman now includes most of the features of MAKEALL it is probably time to talk about deprecating MAKEALL. Comments welcome. Signed-off-by: Simon Glass s...@chromium.org Should this patch go in the release? No, not yet. I am going to mention in the release notes that we're going to strongly start thinking about deleting MAKEALL. We can pick up the deprecation patch early in the next merge window. -- 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] [PATCH] Makefile: drop tools-only from no-dot-config-targets
On Mon, Oct 13, 2014 at 08:40:06AM -0400, Tom Rini wrote: With the introduction of CONFIG_LOCALVERSION support we cannot build tools without having a config file (as we won't know our PLAIN_VERSION until then). Reported-by: Otavio Salvador ota...@ossystems.com.br Signed-off-by: Tom Rini tr...@ti.com Applied to u-boot/master, thanks! -- 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] [ANN] U-Boot v2014.10 released
Hey all, I've pushed v2014.10 out to the repository and tarballs should exist soon. First, the big changes. We're using Kconfig now, not just Kbuild. There's still a lot of work to do on converting from defines in the config header files to Kconfig choices, but the first big step is done and I want to thank Masahiro Yamada again for all the hard work he's put in (and everyone else that's reviewed and tested and helped out) to get us this far. Second, the tools-only build target requires a valid config to have been done now as we have CONFIG_LOCALVERSION support. Next up, the device model work is coming along nicely, thanks Simon! We've got serial converted now and enhanced the gpio framework. One last thing I want to call big attention to. We're strongly considering deprecating MAKEALL in favor of the buildman tool we've also had for the last year and a half. We're at the point now where I think thus far everyone that's spoken up with a usecase for MAKEALL has an equivalent want to run buildman (and there's lots of nice things buildman gives that MAKEALL doesn't). So please, try it out and report back problems you see that would prevent you from switching over. As always, lots of nice little fixes here and there and everywhere. Since I've had a few requests to include some sort of ChangeLog (other than what git spits out), here's what I've come up with: - More clang related warning fixes (and more to come). - ARM HYP/non-secure fixes and support. - Lots and lots and lots of updates to many ARM SoC families. Give your favorites a spin! - More generic board conversions - fastboot flashing and sparse image support. NOTE: If any other projects out there need a BSD licensed copy of the Android sparse image support, see include/sparse_format.h as this copy was relicensed by Google, thanks Google! And I would encourage custodians to follow-up with anything big I've overlooked. Thanks for the hard work everyone! The merge window will open next Monday, the 20th and close Saturday November 8th (since there's a lot of custodians here at ELC-E). -- 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] [PATCH] dm: serial: Fix breakage due to stdio changes
On Tue, Oct 14, 2014 at 09:34:38AM +0200, Simon Glass wrote: Hi Tom, On 10 October 2014 05:06, Simon Glass s...@chromium.org wrote: Commit 32d0192 broke the sandbox build - fix it. Signed-off-by: Simon Glass s...@chromium.org --- drivers/serial/serial-uclass.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c index fd010ca..6dde4ea 100644 --- a/drivers/serial/serial-uclass.c +++ b/drivers/serial/serial-uclass.c @@ -198,7 +198,7 @@ static int serial_pre_remove(struct udevice *dev) #ifdef CONFIG_SYS_STDIO_DEREGISTER struct serial_dev_priv *upriv = dev-uclass_priv; - if (stdio_deregister_dev(upriv-sdev), 0) + if (stdio_deregister_dev(upriv-sdev, 0)) return -EPERM; #endif Can you please pick up this one? Arg, I thought I had already grabbed this one, sorry. -- 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] [PATCH] dm: serial: Fix breakage due to stdio changes
On Tue, Oct 14, 2014 at 09:34:38AM +0200, Simon Glass wrote: Hi Tom, On 10 October 2014 05:06, Simon Glass s...@chromium.org wrote: Commit 32d0192 broke the sandbox build - fix it. Signed-off-by: Simon Glass s...@chromium.org --- drivers/serial/serial-uclass.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c index fd010ca..6dde4ea 100644 --- a/drivers/serial/serial-uclass.c +++ b/drivers/serial/serial-uclass.c @@ -198,7 +198,7 @@ static int serial_pre_remove(struct udevice *dev) #ifdef CONFIG_SYS_STDIO_DEREGISTER struct serial_dev_priv *upriv = dev-uclass_priv; - if (stdio_deregister_dev(upriv-sdev), 0) + if (stdio_deregister_dev(upriv-sdev, 0)) return -EPERM; #endif Can you please pick up this one? Ah, wait! Author: Hans de Goede hdego...@redhat.com Date: Fri Oct 10 18:30:17 2014 +0200 serial-uclass: Fix compilation error Signed-off-by: Hans de Goede hdego...@redhat.com So we're good to go still. -- 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] Revert common, env: Fix support for environment in i2c eeprom
Since i2c_init_all always sets the bus back to CONFIG_SYS_SPD_BUS_NUM for compatibility reasons, it means that any eeprom not located on this CONFIG_SYS_SPD_BUS_NUM is not accessible with the eeprom commands, even if you change the bus number with an i2c dev command before. Furthermore i2c_init_all should disappear and is currently only called from the early board initialisation sequences, it is not suited for other usage. This reverts commit 01a0c64762e902971b34587a8a61b59e9ea51374. Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com --- common/cmd_eeprom.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/common/cmd_eeprom.c b/common/cmd_eeprom.c index a02f0cb..29f0f1f 100644 --- a/common/cmd_eeprom.c +++ b/common/cmd_eeprom.c @@ -389,13 +389,8 @@ void eeprom_init (void) #if defined(CONFIG_SPI) !defined(CONFIG_ENV_EEPROM_IS_ON_I2C) spi_init_f (); #endif -#if defined(CONFIG_HARD_I2C) || defined(CONFIG_SYS_I2C_SOFT) || \ - defined(CONFIG_SYS_I2C) -#ifdef CONFIG_SYS_I2C - i2c_init_all(); -#else - i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE); -#endif +#if defined(CONFIG_HARD_I2C) || defined(CONFIG_SYS_I2C_SOFT) + i2c_init (CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE); #endif } -- 1.8.0.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] km_kirkwood: remove KM_ENV_BUS and use CONFIG_I2C_ENV_EEPROM_BUS
KM_ENV_BUS was used for nothing else than an direct assignment to CONFIG_I2C_ENV_EEPROM_BUS. To avoid this, directly use CONFIG_I2C_ENV_EEPROM_BUS instead. Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com --- include/configs/km/km_arm.h | 2 +- include/configs/km_kirkwood.h | 4 2 files changed, 1 insertion(+), 5 deletions(-) diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h index d31e674..04cddb1 100644 --- a/include/configs/km/km_arm.h +++ b/include/configs/km/km_arm.h @@ -244,7 +244,7 @@ int get_scl(void); #define CONFIG_SYS_EEPROM_WREN #define CONFIG_ENV_OFFSET 0x0 /* no bracets! */ #define CONFIG_ENV_SIZE(0x2000 - CONFIG_ENV_OFFSET) -#define CONFIG_I2C_ENV_EEPROM_BUS KM_ENV_BUS +#define CONFIG_I2C_ENV_EEPROM_BUS 5 /* I2C2 (Mux-Port 5) */ #define CONFIG_ENV_OFFSET_REDUND 0x2000 /* no bracets! */ #define CONFIG_ENV_SIZE_REDUND (CONFIG_ENV_SIZE) #endif diff --git a/include/configs/km_kirkwood.h b/include/configs/km_kirkwood.h index dc26155..a445aaf 100644 --- a/include/configs/km_kirkwood.h +++ b/include/configs/km_kirkwood.h @@ -116,10 +116,6 @@ /* include common defines/options for all arm based Keymile boards */ #include km/km_arm.h -#ifndef CONFIG_KM_ENV_IS_IN_SPI_NOR -#define KM_ENV_BUS 5 /* I2C2 (Mux-Port 5)*/ -#endif - #if defined(CONFIG_KM_PIGGY4_88E6352) /* * Some keymile boards like mgcoge5un nusa1 have their PIGGY4 connected via -- 1.8.0.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: serial: Fix breakage due to stdio changes
Hi Tom, On 14 October 2014 10:50, Tom Rini tr...@ti.com wrote: On Tue, Oct 14, 2014 at 09:34:38AM +0200, Simon Glass wrote: Hi Tom, On 10 October 2014 05:06, Simon Glass s...@chromium.org wrote: Commit 32d0192 broke the sandbox build - fix it. Signed-off-by: Simon Glass s...@chromium.org --- drivers/serial/serial-uclass.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c index fd010ca..6dde4ea 100644 --- a/drivers/serial/serial-uclass.c +++ b/drivers/serial/serial-uclass.c @@ -198,7 +198,7 @@ static int serial_pre_remove(struct udevice *dev) #ifdef CONFIG_SYS_STDIO_DEREGISTER struct serial_dev_priv *upriv = dev-uclass_priv; - if (stdio_deregister_dev(upriv-sdev), 0) + if (stdio_deregister_dev(upriv-sdev, 0)) return -EPERM; #endif Can you please pick up this one? Ah, wait! Author: Hans de Goede hdego...@redhat.com Date: Fri Oct 10 18:30:17 2014 +0200 serial-uclass: Fix compilation error Signed-off-by: Hans de Goede hdego...@redhat.com So we're good to go still. Thanks, sorry I missed that. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Add CONFIG_MACH_TYPE defines to sun4i, sun5i and sun7i
On Mon, 2014-10-13 at 14:55 +0200, Hans de Goede wrote: Many people are still using old linux-sunxi-3.4 kernels on sunxi devices, adding the proper MACH_TYPE defines for this allows people to switch to upstream u-boot, so that we can stop maintaining the linux-sunxi u-boot fork. These machine-ids are all properly registered at: http://www.arm.linux.org.uk/developer/machines/ /me thinks having a machine id per soc (as opposed to,er, per machine) is a bit odd, but whatever: Acked-by: Ian Campbell i...@hellion.org.uk +#define CONFIG_MACH_TYPE 4104 The description of this in the machine registry is interesting. Further to our conversation last night about the need to know whether to boot in hyp or svc mode for these older kernels... The 3.4 kernel entry point has very early on (like in the first dozen instructions): setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode @ and irqs disabled IOW it should be dropping straight to svc mode. So I'm not sure why it doesn't work for you. Perhaps u-boot is failing to do some el1 level setup/teardown as we launch, e.g. flushing the svc mode tlb, flushing caches etc. It's also possible there are simply bug fixes from later kernels which are missing. It might be interesting to try backporting: commit 80c59dafb1a9a86fa996e6e34d06b60567c925ca Author: Dave Martin dave.mar...@linaro.org Date: Thu Feb 9 08:47:17 2012 -0800 ARM: virt: allow the kernel to be entered in HYP mode * Ensure that asynchronous aborts are masked at kernel entry. The bootloader should be masking these anyway, but this reduces the damage window just in case it doesn't. * Enter svc mode via exception return to ensure that CPU state is properly serialised. This does not matter when switching from an ordinary privileged mode (PL1 modes in ARMv7-AR rev C parlance), but it potentially does matter when switching from a another privileged mode such as hyp mode. This should allow the kernel to boot safely either from svc mode or hyp mode, even if no support for use of the ARM Virtualization Extensions is built into the kernel. Signed-off-by: Dave Martin dave.mar...@linaro.org Signed-off-by: Marc Zyngier marc.zyng...@arm.com [dropping all the #ifdef CONFIG_ARM_VIRT_EXT bits, makes the patch much smaller/simpler and you don't actually want those bits anyway] The second bullet there looks interesting. It's probable that if you did this you would also want these followups: 2a552d5e63d7ARM: 7549/1: HYP: fix boot on some ARM1136 cores 1ecec696c8bbARM: 7599/1: head: Remove boot-time HYP mode check for v5 and below 8e9c24a2b2e0ARM: virt: avoid clobbering lr when forcing svc mode 0e0779da2233ARM: 8053/1: kernel: sleep: restore HYP mode configuration in cpu_resume Most of those would be pretty small backports once the CONFIG_ARM_VIRT_EXT bits are nuked. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] imx: mx6slevk: Add support for USDHC1 and USDHC3 slots
On Tue, Oct 14, 2014 at 4:14 AM, Ye.Li b37...@freescale.com wrote: There are three SD/MMC sockets on mx6slevk boards. Implements the full support for them. The default boot socket is USDHC2, so the MMC environment is set to that device. Signed-off-by: Ye.Li b37...@freescale.com --- Changes since v1: - Correct the return value of board_mmc_init function Reviewed-by: Fabio Estevam fabio.este...@freescale.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] imx: mx6sl: Add IOMUX setting for USDHC1-3
On Tue, Oct 14, 2014 at 4:14 AM, Ye.Li b37...@freescale.com wrote: Set the USDHC1-3 IOMUX settings which are used for mx6slevk board. Signed-off-by: Ye.Li b37...@freescale.com Reviewed-by: Fabio Estevam fabio.este...@freescale.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] dm: Should U-Boot driver model abandon platform data?
On 14 October 2014 10:20, Simon Glass s...@chromium.org wrote: Hi, This question came up at the U-Boot mini-summit yesterday and I was tasked with starting a thread on the mailing list. There seemed to be a strong feeling in the room that permitting platform data in driver model is a mistake. Reasons mentioned were: - device tree is how things are done in Linux at least for most platforms we support - we can therefore import this directly in from Linux rather than writing new platform data - platform data is considered 'legacy' and we should not support legacy features in a new framework - device tree permits fully abstracting the device data from the code, avoiding #ifdefs - it is easier to change settings in device tree than in platform data The main impact is that all boards would need at least some sort of device tree when they move to driver model. I'm not fully agree with the statement platform data should not be part of driver model. Yes this statement is fine when we code platform data with fully functional devicetree driven u-boot ie possible in Linux now. I think going forward, this platform data will be part of devicetree based on u-boot devicetree development on all possible area's till that platform data is not a legacy for u-boot. Comments? There is also the question of SPL, where we are sometimes space-constrained. If we go with this policy I wonder if we should permit an exception for things required by SPL for now? Typically in SPL for these space-constrained platforms we only need a few devices so we could provide platform data for SPL while still using device tree in U-Boot It would be possible to enable device tree in SPL for many platforms but that feels like something that should not block progress. So perhaps platform data in SPL should be a separate question. Please have a think about this and reply on this thread. thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] km_kirkwood: remove KM_ENV_BUS and use CONFIG_I2C_ENV_EEPROM_BUS
-Original Message- From: Valentin Longchamp [mailto:valentin.longch...@keymile.com] Sent: 14 October 2014 14:49 To: u-boot@lists.denx.de; Prafulla Wadaskar Cc: Holger Brunck; Valentin Longchamp Subject: [PATCH] km_kirkwood: remove KM_ENV_BUS and use CONFIG_I2C_ENV_EEPROM_BUS KM_ENV_BUS was used for nothing else than an direct assignment to CONFIG_I2C_ENV_EEPROM_BUS. To avoid this, directly use CONFIG_I2C_ENV_EEPROM_BUS instead. Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com --- include/configs/km/km_arm.h | 2 +- include/configs/km_kirkwood.h | 4 2 files changed, 1 insertion(+), 5 deletions(-) diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h index d31e674..04cddb1 100644 --- a/include/configs/km/km_arm.h +++ b/include/configs/km/km_arm.h @@ -244,7 +244,7 @@ int get_scl(void); #define CONFIG_SYS_EEPROM_WREN #define CONFIG_ENV_OFFSET0x0 /* no bracets! */ #define CONFIG_ENV_SIZE (0x2000 - CONFIG_ENV_OFFSET) -#define CONFIG_I2C_ENV_EEPROM_BUSKM_ENV_BUS +#define CONFIG_I2C_ENV_EEPROM_BUS 5 /* I2C2 (Mux-Port 5) */ #define CONFIG_ENV_OFFSET_REDUND 0x2000 /* no bracets! */ #define CONFIG_ENV_SIZE_REDUND (CONFIG_ENV_SIZE) #endif diff --git a/include/configs/km_kirkwood.h b/include/configs/km_kirkwood.h index dc26155..a445aaf 100644 --- a/include/configs/km_kirkwood.h +++ b/include/configs/km_kirkwood.h @@ -116,10 +116,6 @@ /* include common defines/options for all arm based Keymile boards */ #include km/km_arm.h -#ifndef CONFIG_KM_ENV_IS_IN_SPI_NOR -#define KM_ENV_BUS 5 /* I2C2 (Mux-Port 5)*/ -#endif - #if defined(CONFIG_KM_PIGGY4_88E6352) /* * Some keymile boards like mgcoge5un nusa1 have their PIGGY4 connected via -- Applied to u-boot-marvell.git master branch Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Kconfig: Add EXPERT option
For similar reasons to why the Linux Kernel has an EXPERT option, we too want an option to allow for tweaking of some options that while normally should remain hidden, may need to be changed in some cases. Signed-off-by: Tom Rini tr...@ti.com --- Kconfig |8 1 file changed, 8 insertions(+) diff --git a/Kconfig b/Kconfig index e0c8992..73785b00 100644 --- a/Kconfig +++ b/Kconfig @@ -58,6 +58,14 @@ config CC_OPTIMIZE_FOR_SIZE endmenu# General setup +menuconfig EXPERT +bool Configure standard U-Boot features (expert users) +help + This option allows certain base U-Boot options and settings + to be disabled or tweaked. This is for specialized + environments which can tolerate a non-standard U-Boot. + Only use this if you really know what you are doing. + menu Boot images config SPL_BUILD -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert common, env: Fix support for environment in i2c eeprom
Hi Valentin, my patch fixed environment from i2c eeprom. I am not sure on which board I ran into that trouble. Probably PMC440. So reverting my former patch will break environment in i2c eeprom again on many boards. But perhaps there's a better way to fix that. Matthias On 10/14/2014 11:16 AM, Valentin Longchamp wrote: Since i2c_init_all always sets the bus back to CONFIG_SYS_SPD_BUS_NUM for compatibility reasons, it means that any eeprom not located on this CONFIG_SYS_SPD_BUS_NUM is not accessible with the eeprom commands, even if you change the bus number with an i2c dev command before. Furthermore i2c_init_all should disappear and is currently only called from the early board initialisation sequences, it is not suited for other usage. This reverts commit 01a0c64762e902971b34587a8a61b59e9ea51374. Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com --- common/cmd_eeprom.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/common/cmd_eeprom.c b/common/cmd_eeprom.c index a02f0cb..29f0f1f 100644 --- a/common/cmd_eeprom.c +++ b/common/cmd_eeprom.c @@ -389,13 +389,8 @@ void eeprom_init (void) #if defined(CONFIG_SPI) !defined(CONFIG_ENV_EEPROM_IS_ON_I2C) spi_init_f (); #endif -#if defined(CONFIG_HARD_I2C) || defined(CONFIG_SYS_I2C_SOFT) || \ - defined(CONFIG_SYS_I2C) -#ifdef CONFIG_SYS_I2C - i2c_init_all(); -#else - i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE); -#endif +#if defined(CONFIG_HARD_I2C) || defined(CONFIG_SYS_I2C_SOFT) + i2c_init (CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE); #endif } -- Dipl.-Ing. Matthias Fuchs Head of System Design esd electronic system design gmbh Vahrenwalder Str. 207 - 30165 Hannover - GERMANY Phone: +49-511-37298-0 - Fax: +49-511-37298-68 Please visit our homepage http://www.esd.eu Quality Products - Made in Germany - Geschäftsführer: Klaus Detering Amtsgericht Hannover HRB 51373 - VAT-ID DE 115672832 - ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert common, env: Fix support for environment in i2c eeprom
On 10/14/2014 02:32 PM, Matthias Fuchs wrote: Hi Valentin, my patch fixed environment from i2c eeprom. I am not sure on which board I ran into that trouble. Probably PMC440. So reverting my former patch will break environment in i2c eeprom again on many boards. But perhaps there's a better way to fix that. do you have CONFIG_I2C_ENV_EEPROM_BUS defined in your board config? Regards Holger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert common, env: Fix support for environment in i2c eeprom
On 10/14/2014 03:01 PM, Holger Brunck wrote: On 10/14/2014 02:32 PM, Matthias Fuchs wrote: Hi Valentin, my patch fixed environment from i2c eeprom. I am not sure on which board I ran into that trouble. Probably PMC440. So reverting my former patch will break environment in i2c eeprom again on many boards. But perhaps there's a better way to fix that. do you have CONFIG_I2C_ENV_EEPROM_BUS defined in your board config? No, I will give it a try. Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert common, env: Fix support for environment in i2c eeprom
Hi Matthias, On 10/14/2014 02:32 PM, Matthias Fuchs wrote: Hi Valentin, my patch fixed environment from i2c eeprom. I am not sure on which board I ran into that trouble. Probably PMC440. So reverting my former patch will break environment in i2c eeprom again on many boards. Good that you have answered to patch. I run into that trouble on our Keymile boards that have the environment in the EEPROM. On our boards, the environment eeprom works with or without your patch. However, with your patch, I cannot directly access ANY eeprom which is not on the CONFIG_I2C_ENV_EEPROM_BUS bus. But perhaps there's a better way to fix that. I think that the proposal that Holger made to actually define CONFIG_I2C_ENV_EEPROM_BUS for your boards is what I would try first. Valentin Matthias On 10/14/2014 11:16 AM, Valentin Longchamp wrote: Since i2c_init_all always sets the bus back to CONFIG_SYS_SPD_BUS_NUM for compatibility reasons, it means that any eeprom not located on this CONFIG_SYS_SPD_BUS_NUM is not accessible with the eeprom commands, even if you change the bus number with an i2c dev command before. Furthermore i2c_init_all should disappear and is currently only called from the early board initialisation sequences, it is not suited for other usage. This reverts commit 01a0c64762e902971b34587a8a61b59e9ea51374. Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com --- common/cmd_eeprom.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/common/cmd_eeprom.c b/common/cmd_eeprom.c index a02f0cb..29f0f1f 100644 --- a/common/cmd_eeprom.c +++ b/common/cmd_eeprom.c @@ -389,13 +389,8 @@ void eeprom_init (void) #if defined(CONFIG_SPI) !defined(CONFIG_ENV_EEPROM_IS_ON_I2C) spi_init_f (); #endif -#if defined(CONFIG_HARD_I2C) || defined(CONFIG_SYS_I2C_SOFT) || \ -defined(CONFIG_SYS_I2C) -#ifdef CONFIG_SYS_I2C -i2c_init_all(); -#else -i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE); -#endif +#if defined(CONFIG_HARD_I2C) || defined(CONFIG_SYS_I2C_SOFT) +i2c_init (CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE); #endif } ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: add PCIe-related pins to the Jetson TK1 pinmux tables
On 09/17/2014 10:16 AM, Stephen Warren wrote: On 08/22/2014 03:04 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com This pinmux tables currently omit any configuration for PCIe clk_req, wake, and rst pins, which in turn causes intermittent failures in U-Boot's PCIe support. Import an updated version of the pinmux tables which rectifies this. Signed-off-by: Stephen Warren swar...@nvidia.com Could this please make it into the imminent v2014.10 release? I see this in u-boot-tegra/master, but it doesn't seem to be in u-boot-arm/master or u-boot/master. Did a pull request get sent for this commit? I'd really like to see this bugfix get applied to the main U-Boot repo ASAP... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/3] net: Add a command to access the EEPROM from ethernet devices
Many ethernet devices use an EEPROM to store various settings, most
commonly the device MAC address. But on some devices it can contains
a lot more, for example USB device might also have many USB related
parameters.
This commit add a set of commands to read/write this EEPROM, write a
default configuration and read/write the device MAC address. The
defaults command allow priming the EEPROM for devices that need more
than just a MAC address in the EEPROM.
Signed-off-by: Alban Bedel alban.be...@avionic-design.de
---
v2: * No changes since v1
v3: * Replace the dedicated 'eth_eeprom' command with a subcommand
to the newly introduced 'eth' command
---
common/cmd_net.c | 121 +++
include/net.h| 28 +
net/eth.c| 46 +
3 files changed, 195 insertions(+)
diff --git a/common/cmd_net.c b/common/cmd_net.c
index 9cc0bdf..1c2e254 100644
--- a/common/cmd_net.c
+++ b/common/cmd_net.c
@@ -446,6 +446,109 @@ U_BOOT_CMD(
#endif /* CONFIG_CMD_LINK_LOCAL */
+#if defined(CONFIG_CMD_ETH_EEPROM)
+static int do_eth_eeprom_rw(struct eth_device *dev,
+ int argc, char * const argv[])
+{
+ ulong addr, offset, length = 1;
+
+ if (argc 3)
+ return CMD_RET_USAGE;
+
+ addr = simple_strtoul(argv[1], NULL, 16);
+ offset = simple_strtoul(argv[2], NULL, 16);
+ if (argc 3)
+ length = simple_strtoul(argv[3], NULL, 16);
+
+ if (!strcmp(argv[0], write)) {
+ if (eth_eeprom_write(dev, offset, length, (void *)addr)) {
+ printf(EEPROM write failed\n);
+ return CMD_RET_FAILURE;
+ }
+ return CMD_RET_SUCCESS;
+ } else if (!strcmp(argv[0], read)) {
+ if (eth_eeprom_read(dev, offset, length, (void *)addr)) {
+ printf(EEPROM read failed\n);
+ return CMD_RET_FAILURE;
+ }
+ return CMD_RET_SUCCESS;
+ }
+
+ return CMD_RET_USAGE;
+}
+
+static int do_eth_eeprom_defaults(struct eth_device *dev,
+ int argc, char * const argv[])
+{
+ if (eth_eeprom_defaults(dev)) {
+ printf(EEPROM write failed\n);
+ return CMD_RET_FAILURE;
+ }
+
+ return CMD_RET_SUCCESS;
+}
+
+static int do_eth_eeprom_set_mac(struct eth_device *dev,
+ int argc, char * const argv[])
+{
+ u8 mac[6];
+
+ if (argc 2)
+ return CMD_RET_USAGE;
+
+ eth_parse_enetaddr(argv[1], mac);
+ if (!is_valid_ether_addr(mac)) {
+ printf(Invalid mac address given\n);
+ return CMD_RET_FAILURE;
+ }
+
+ printf(Writing MAC to EEPROM \n);
+ if (eth_eeprom_write_mac(dev, mac)) {
+ printf(EEPROM write failed\n);
+ return CMD_RET_FAILURE;
+ }
+
+ return CMD_RET_SUCCESS;
+}
+
+static int do_eth_eeprom_show_mac(struct eth_device *dev,
+ int argc, char * const argv[])
+{
+ u8 data[6];
+
+ if (eth_eeprom_read_mac(dev, data)) {
+ printf(EEPROM read failed\n);
+ return CMD_RET_FAILURE;
+ }
+
+ printf(%pM\n, data);
+ if (!is_valid_ether_addr(data))
+ printf(Warning: MAC address is not valid!\n);
+
+ return CMD_RET_SUCCESS;
+}
+
+static int do_eth_eeprom(struct eth_device *dev,
+ int argc, char * const argv[])
+{
+ if (argc 2)
+ return CMD_RET_USAGE;
+
+ if (!strcmp(argv[1], read) || !strcmp(argv[1], write))
+ return do_eth_eeprom_rw(dev, argc - 1, argv + 1);
+ if (!strcmp(argv[1], defaults))
+ return do_eth_eeprom_defaults(dev, argc - 1, argv + 1);
+ if (!strcmp(argv[1], set_mac))
+ return do_eth_eeprom_set_mac(dev, argc - 1, argv + 1);
+ if (!strcmp(argv[1], show_mac))
+ return do_eth_eeprom_show_mac(dev, argc - 1, argv + 1);
+
+ printf(Unknown eeprom sub command: %s\n, argv[1]);
+
+ return CMD_RET_USAGE;
+}
+#endif
+
static int do_eth_show(struct eth_device *dev,
int argc, char * const argv[])
{
@@ -478,6 +581,10 @@ static int do_eth(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
if (!strcmp(argv[2], show))
return do_eth_show(dev, argc - 2, argv + 2);
+#if defined(CONFIG_CMD_ETH_EEPROM)
+ if (!strcmp(argv[2], eeprom))
+ return do_eth_eeprom(dev, argc - 2, argv + 2);
+#endif
printf(Unknown eth sub command: %s\n, argv[2]);
@@ -492,4 +599,18 @@ U_BOOT_CMD(
\n
eth dev show\n
- show basic information about the ethernet device\n
+#if defined(CONFIG_CMD_ETH_EEPROM)
+ eth dev eeprom command [args...]\n
+ - access the EEPROM of the ethernet
[U-Boot] [PATCH v3 1/3] net: Add a command to manipulate ethernet devices
Add the 'eth' command for operations on ethernet devices.
This first version only contains a command to show a device
properties, currently only name, index and MAC address.
Signed-off-by: Alban Bedel alban.be...@avionic-design.de
---
v1: * Patch didn't exists
v2: * Patch didn't exists
v3: * Replace the dedicated 'eth_eeprom' command with a subcommand
to the 'eth' command
---
common/cmd_net.c | 48
1 file changed, 48 insertions(+)
diff --git a/common/cmd_net.c b/common/cmd_net.c
index 09489d4..9cc0bdf 100644
--- a/common/cmd_net.c
+++ b/common/cmd_net.c
@@ -445,3 +445,51 @@ U_BOOT_CMD(
);
#endif /* CONFIG_CMD_LINK_LOCAL */
+
+static int do_eth_show(struct eth_device *dev,
+ int argc, char * const argv[])
+{
+ printf(Name : %s\n, dev-name);
+ printf(Index: %d\n, dev-index);
+ printf(MAC : %pM\n, dev-enetaddr);
+ return 0;
+}
+
+static int do_eth(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ struct eth_device *dev;
+ char *endp = NULL;
+ int index;
+
+ if (argc 3)
+ return CMD_RET_USAGE;
+
+ /* Get the ethernet device, by ID or by name */
+ index = (int) simple_strtoul(argv[1], endp, 16);
+ if (endp argv[1])
+ dev = eth_get_dev_by_index(index);
+ else
+ dev = eth_get_dev_by_name(argv[2]);
+
+ if (!dev) {
+ printf(Ethernet device not found\n);
+ return CMD_RET_FAILURE;
+ }
+
+ if (!strcmp(argv[2], show))
+ return do_eth_show(dev, argc - 2, argv + 2);
+
+ printf(Unknown eth sub command: %s\n, argv[2]);
+
+ return CMD_RET_USAGE;
+}
+
+U_BOOT_CMD(
+ eth,7, 0, do_eth,
+ extended ops for ethernet devices,
+ dev command [args...]\n
+ - run command on a device, device may be a name or id.\n
+ \n
+ eth dev show\n
+ - show basic information about the ethernet device\n
+);
--
2.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/3] usb: eth: smsc95xx: Add EEPROM access support for LAN9514
Use the new ethernet eeprom API to allow the user to read/write the
EEPROM.
Signed-off-by: Alban Bedel alban.be...@avionic-design.de
---
v2: * Rework the defaults implementation to use the proper config
depending on the device type.
* Allow the board to override the defaults data.
* Use the proper defaults instead of the Tamonten config.
* Fix style error in usb_ether.h
* Add a comment to explain why the default MAC has all bits set
v3: * No changes since v2
This patch is based on earlier work from Thierry Reding, I assumed
that the default config was derived from the datasheet. However it
turned out that this config had been customized for the Tamonten
boards. I restored the config according to the defaults found in the
datasheet. Sadly the datasheet doesn't properly document all the
fields from the EEPROM, so it may still have a few bugs as I don't
have the default values for all fields.
---
drivers/usb/eth/smsc95xx.c | 246 +++--
include/usb_ether.h| 8 ++
2 files changed, 247 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/eth/smsc95xx.c b/drivers/usb/eth/smsc95xx.c
index 6bca34d..4e06be7 100644
--- a/drivers/usb/eth/smsc95xx.c
+++ b/drivers/usb/eth/smsc95xx.c
@@ -59,6 +59,8 @@
#define E2P_CMD0x30
#define E2P_CMD_BUSY_ 0x8000
+#define E2P_CMD_EWEN_ 0x2000
+#define E2P_CMD_WRITE_ 0x3000
#define E2P_CMD_READ_ 0x
#define E2P_CMD_TIMEOUT_ 0x0400
#define E2P_CMD_LOADED_0x0200
@@ -146,6 +148,155 @@ struct smsc95xx_private {
int have_hwaddr; /* 1 if we have a hardware MAC address */
};
+#ifdef CONFIG_CMD_ETH_EEPROM
+struct smsc95xx_eeprom_device {
+ unsigned short vendor;
+ unsigned short product;
+ struct smsc95xx_eeprom_defaults *defaults;
+};
+
+/* Default values as used by the controller when the EEPROM hasn't
+ * been programmed yet. Note that when unset the MAC address has
+ * all bits set instead of all bits cleared as is usual in u-boot. */
+static u8 smsc9514_eeprom_defaults_data[] = {
+ /* 0x00 */
+ 0xA5, /* Signature */
+ 0xFF, 0xFF, /* MAC bytes 0-1 */
+ 0xFF, 0xFF, /* MAC bytes 2-3 */
+ 0xFF, 0xFF, /* MAC bytes 4-5 */
+ 0x01, /* FS Polling Interval for Interrupt Endpoint */
+ 0x04, /* HS Polling Interval for Interrupt Endpoint */
+ 0x05, /* Configuration Flags */
+ 0x09, 0x04, /* Language ID */
+ 0x0a, /* Manufacturer ID String Descriptor Length (bytes) */
+ 0x2f, /* Manufacturer ID String Descriptor EEPROM Word Offset
*/
+ 0x10, /* Product Name String Descriptor Length (bytes) */
+ 0x34, /* Product Name String Descriptor EEPROM Word Offset */
+ /* 0x10 */
+ 0x12, /* Serial Number String Descriptor Length (bytes) */
+ 0x3c, /* Serial Number String Descriptor EEPROM Word Offset */
+ 0x08, /* Configuration String Descriptor Length (bytes) */
+ 0x45, /* Configuration String Descriptor Word Offset */
+ 0x08, /* Interface String Descriptor Length (bytes) */
+ 0x49, /* Interface String Descriptor Word Offset */
+ 0x12, /* Hi-Speed Device Descriptor Length (bytes) */
+ 0x1d, /* Hi-Speed Device Descriptor Word Offset */
+ 0x12, /* Hi-Speed Configuration and Interface Descriptor
Length (bytes) */
+ 0x26, /* Hi-Speed Configuration and Interface Descriptor Word
Offset */
+ 0x12, /* Full-Speed Device Descriptor Length (bytes) */
+ 0x1d, /* Full-Speed Device Descriptor Word Offset */
+ 0x12, /* Full-Speed Configuration and Interface Descriptor
Length (bytes) */
+ 0x26, /* Full-Speed Configuration and Interface Descriptor
Word Offset */
+ 0x00, 0x00, /* RESERVED */
+ /* 0x20 */
+ 0x24, 0x04, /* Vendor ID */
+ 0x14, 0x95, /* Product ID */
+ 0x00, 0x01, /* Device ID */
+ 0x9b, /* Config Data Byte 1 Register (CFG1) */
+ 0x18, /* Config Data Byte 2 Register (CFG2) */
+ 0x00, /* Config Data Byte 3 Register (CFG3) */
+ 0x02, /* Non-Removable Devices Register (NRD) */
+ 0x00, /* Port Disable (Self) Register (PDS) */
+ 0x00, /* Port Disable (Bus) Register (PDB) */
+ 0x01, /* Max Power (Self) Register (MAXPS) */
+ 0x00, /* Max Power (Bus) Register (MAXPB) */
+ 0x01, /* Hub Controller Max Current (Self) Register (HCMCS) */
+ 0x00, /* Hub Controller Max Current (Bus) Register (HCMCB) */
+ /* 0x30 */
+ 0x32, /*
Re: [U-Boot] [PATCH v3 2/3] net: Add a command to access the EEPROM from ethernet devices
Hi, On 14 October 2014 18:26, Alban Bedel alban.be...@avionic-design.de wrote: Many ethernet devices use an EEPROM to store various settings, most commonly the device MAC address. But on some devices it can contains a lot more, for example USB device might also have many USB related parameters. This commit add a set of commands to read/write this EEPROM, write a default configuration and read/write the device MAC address. The defaults command allow priming the EEPROM for devices that need more than just a MAC address in the EEPROM. Signed-off-by: Alban Bedel alban.be...@avionic-design.de --- v2: * No changes since v1 v3: * Replace the dedicated 'eth_eeprom' command with a subcommand to the newly introduced 'eth' command I see a few EEPROM implementations in the code base. It feels to me like we need an EEPROM interface. In driver model terms this could be a uclass. I started something here: http://patchwork.ozlabs.org/patch/399039/ Of course we don't have DM for Ethernet yet - when we do I think a child EEPROM device below the Ethernet would make sense. It could be created by the Ethernet driver when it knows that this information exists. But even without that I feel that the EEPROM should be logically separated from Ethernet. So I suggest that instead of an #ifdef to adjust the Ethernet API, add a pointer to another struct containing the EEPROM API and put it in its own header. I also feel that there should ultimately be an eeprom command which operates on these. Then the only Ethernet API call would be to find the EEPROM pointer, if there is one. If someone feels like taking it on, driver model support for Ethernet should be pretty easy. Or even EEPROM could be done now and this might avoid churn. But I would be happy for this series to be applied as is while working on a driver model version. I just don't feel we should be adding new subsystems that don't use driver model. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: add PCIe-related pins to the Jetson TK1 pinmux tables
My gmail account has been in flux for a few weeks, so I can't say for sure whether I sent a PR or not. I'll resend one today to Albert. Tom -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Tuesday, October 14, 2014 8:25 AM To: Tom Warren; Tom Rini; albert.u.b...@aribaud.net Cc: u-boot@lists.denx.de; Simon Glass; Stephen Warren; Thierry Reding Subject: Re: [U-Boot] [PATCH] ARM: tegra: add PCIe-related pins to the Jetson TK1 pinmux tables On 09/17/2014 10:16 AM, Stephen Warren wrote: On 08/22/2014 03:04 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com This pinmux tables currently omit any configuration for PCIe clk_req, wake, and rst pins, which in turn causes intermittent failures in U-Boot's PCIe support. Import an updated version of the pinmux tables which rectifies this. Signed-off-by: Stephen Warren swar...@nvidia.com Could this please make it into the imminent v2014.10 release? I see this in u-boot-tegra/master, but it doesn't seem to be in u-boot- arm/master or u-boot/master. Did a pull request get sent for this commit? I'd really like to see this bugfix get applied to the main U-Boot repo ASAP... --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] powerpc/85xx: enable some P1/P2 boards mtdparts for nor flash
On 08/17/2014 07:43 PM, York Sun wrote: Yangbo, On 8/17/14 7:03 PM, Yangbo Lu yangbo...@freescale.com wrote: Enable these boards mtdparts for nor flash: p1020rdb-pd, p1021rdb-pc, p1022ds, p1025twr, and p2020rdb-pc. Signed-off-by: Xie Xiaobo x@freescale.com Signed-off-by: Yangbo Lu yangbo...@freescale.com Cc: York Sun york...@freescale.com Cc: Scott Wood scottw...@freescale.com --- Changes for v2: - changed commit message - fixed max line length problem in code Changes for v3: - added a Cc to York Sun --- include/configs/P1022DS.h | 12 include/configs/p1_p2_rdb_pc.h | 31 +++ include/configs/p1_twr.h | 12 3 files changed, 55 insertions(+) diff --git a/include/configs/P1022DS.h b/include/configs/P1022DS.h index 139d4fe..4480270 100644 --- a/include/configs/P1022DS.h +++ b/include/configs/P1022DS.h @@ -620,6 +620,18 @@ #endif /* + * Dynamic MTD Partition support with mtdparts + */ +#define CONFIG_MTD_DEVICE +#define CONFIG_MTD_PARTITIONS +#define CONFIG_CMD_MTDPARTS +#define CONFIG_FLASH_CFI_MTD +#define MTDIDS_DEFAULT nor0=e800.nor +#define MTDPARTS_DEFAULT mtdparts=e800.nor:48m(ramdisk), \ +14m(diagnostic),2m(dink),6m(kernel),58112k(fs), \ +512k(dtb),768k(u-boot) + Don't you need to consider both 32- and 36-bit physical address for the flash base here? The same comment applies to p1_p2_rdb_pc.h as well. Please respond. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/t104xrdb: make T104x board compliant in u-boot
On 09/21/2014 11:02 PM, Vijay Rai wrote: When booted with upstream code, it shows error in u-boot that board is not compliant. This patch will make board compliant with upstream code changes in u-boot. Signed-off-by: Vijay Rai vijay@freescale.com --- I think the commit message is not accurate. You are not making it compliant, but rather using generic board. No need to say upstream here. This is the upstream u-boot. Have you tested features such as deep sleep using generic board code? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] video: ipu_disp: remove pixclk fixup
The ipu display insists on having a lower_margin smaller
then 2. If this is not the case it will attempt to force
it and adjust the pixclk accordingly. This multiplies pixclk
in Hz with the width and height, since this is typically
a * 10^7 * b * 10^2 * c * 10^2 this will overflow the
uint_32 and make things even worse. Since this is a
bootloader and the adjustment is neglectible, just force
it to two and warn about it.
Cc: Stefano Babic sba...@denx.de
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
---
drivers/video/ipu_disp.c | 31 ++-
1 file changed, 6 insertions(+), 25 deletions(-)
diff --git a/drivers/video/ipu_disp.c b/drivers/video/ipu_disp.c
index e97a204..48fee99 100644
--- a/drivers/video/ipu_disp.c
+++ b/drivers/video/ipu_disp.c
@@ -802,28 +802,6 @@ int ipu_pixfmt_to_map(uint32_t fmt)
}
/*
- * This function is called to adapt synchronous LCD panel to IPU restriction.
- */
-void adapt_panel_to_ipu_restricitions(uint32_t *pixel_clk,
- uint16_t width, uint16_t height,
- uint16_t h_start_width,
- uint16_t h_end_width,
- uint16_t v_start_width,
- uint16_t *v_end_width)
-{
- if (*v_end_width 2) {
- uint16_t total_width = width + h_start_width + h_end_width;
- uint16_t total_height_old = height + v_start_width +
- (*v_end_width);
- uint16_t total_height_new = height + v_start_width + 2;
- *v_end_width = 2;
- *pixel_clk = (*pixel_clk) * total_width * total_height_new /
- (total_width * total_height_old);
- printf(WARNING: adapt panel end blank lines\n);
- }
-}
-
-/*
* This function is called to initialize a synchronous LCD panel.
*
* @param dispThe DI the panel is attached to.
@@ -880,9 +858,12 @@ int32_t ipu_init_sync_panel(int disp, uint32_t pixel_clk,
if ((v_sync_width == 0) || (h_sync_width == 0))
return -EINVAL;
- adapt_panel_to_ipu_restricitions(pixel_clk, width, height,
-h_start_width, h_end_width,
-v_start_width, v_end_width);
+ /* adapt panel to ipu restricitions */
+ if (v_end_width 2) {
+ v_end_width = 2;
+ puts(WARNING: v_end_width (lower_margin) must be = 2,
adjusted\n);
+ }
+
h_total = width + h_sync_width + h_start_width + h_end_width;
v_total = height + v_sync_width + v_start_width + v_end_width;
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] video: ipo: fix debug and comment
- fix debug pixel clk display and add unit
- fix some comments
Cc: Stefano Babic sba...@denx.de
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
---
drivers/video/ipu_disp.c | 2 +-
drivers/video/mxc_ipuv3_fb.c | 7 +++
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/video/ipu_disp.c b/drivers/video/ipu_disp.c
index 948e1fc..e97a204 100644
--- a/drivers/video/ipu_disp.c
+++ b/drivers/video/ipu_disp.c
@@ -887,7 +887,7 @@ int32_t ipu_init_sync_panel(int disp, uint32_t pixel_clk,
v_total = height + v_sync_width + v_start_width + v_end_width;
/* Init clocking */
- debug(pixel clk = %d\n, pixel_clk);
+ debug(pixel clk = %dHz\n, pixel_clk);
if (sig.ext_clk) {
if (!(g_di1_tvout (disp == 1))) { /*not round div for tvout*/
diff --git a/drivers/video/mxc_ipuv3_fb.c b/drivers/video/mxc_ipuv3_fb.c
index f75d770..b20c19c 100644
--- a/drivers/video/mxc_ipuv3_fb.c
+++ b/drivers/video/mxc_ipuv3_fb.c
@@ -258,8 +258,7 @@ static int mxcfb_set_par(struct fb_info *fbi)
if (fbi-var.sync FB_SYNC_CLK_IDLE_EN)
sig_cfg.clkidle_en = 1;
- debug(pixclock = %ul Hz\n,
- (u32) (PICOS2KHZ(fbi-var.pixclock) * 1000UL));
+ debug(pixclock = %lu Hz\n, PICOS2KHZ(fbi-var.pixclock) * 1000UL);
if (ipu_init_sync_panel(mxc_fbi-ipu_di,
(PICOS2KHZ(fbi-var.pixclock)) * 1000UL,
@@ -486,7 +485,7 @@ static struct fb_info *mxcfb_init_fbinfo(void)
/*
* Probe routine for the framebuffer driver. It is called during the
- * driver binding process. The following functions are performed in
+ * driver binding process. The following functions are performed in
* this routine: Framebuffer initialization, Memory allocation and
* mapping, Framebuffer registration, IPU initialization.
*
@@ -542,7 +541,7 @@ static int mxcfb_probe(u32 interface_pix_fmt, uint8_t disp,
mxcfb_set_fix(fbi);
- /* alocate fb first */
+ /* allocate fb first */
if (mxcfb_map_video_memory(fbi) 0)
return -ENOMEM;
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM: tegra: Use mem size from MC in combination with get_ram_size()
On 10/10/2014 03:32 PM, Marcel Ziswiler wrote: On popular request this now completes the Warren's work started for TK1: aeb3fcb35956461077804720b8a252d50758d7e0 ARM: tegra: Use mem size from MC rather than ODMDATA In addition to the move of using the Tegra memory controller (MC) register rather than ODMDATA for T20, T30 and T114 as well it further uses the generic get_ram_size() function (see common/memsize.c) supposed to be used in each and every U-Boot portTM. Added benefit is that it should catch 99% of hardware related (i. e. reliably reproducible) memory errors as well. Thoroughly tested on the various Toradex line of Tegra modules available which unfortunately does not include T114 and T124 (yet at least) plus on the Jetson TK1. Acked-by: Stephen Warren swar...@nvidia.com (I really should test this on all the boards I have, but unfortunately don't have time. IIRC, I looked at the BCTs in cbootimage-configs when you posted V1, and this should all be fine.) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] qe: add u-qe support to arm board
On 09/24/2014 10:52 PM, Zhao Qiang wrote: ls1021 is arm-core and support qe which is u-qe. add u-qe init for arm board. Signed-off-by: Zhao Qiang b45...@freescale.com --- arch/arm/include/asm/arch-ls102xa/config.h | 4 arch/arm/include/asm/global_data.h | 8 drivers/Makefile | 1 + drivers/qe/Makefile| 3 ++- drivers/qe/fdt.c | 2 ++ drivers/qe/qe.c| 13 + drivers/qe/qe.h| 1 + 7 files changed, 31 insertions(+), 1 deletion(-) Qiang, The subject is 2/4 but I don't see other three patches. Where are they? Alison, Can you comment on this patch (http://patchwork.ozlabs.org/patch/393256/)? Has this been verified on ls1021 boards? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] net: Add a command to access the EEPROM from ethernet devices
On Tue, Oct 14, 2014 at 12:21 PM, Simon Glass s...@chromium.org wrote: Hi, On 14 October 2014 18:26, Alban Bedel alban.be...@avionic-design.de wrote: Many ethernet devices use an EEPROM to store various settings, most commonly the device MAC address. But on some devices it can contains a lot more, for example USB device might also have many USB related parameters. This commit add a set of commands to read/write this EEPROM, write a default configuration and read/write the device MAC address. The defaults command allow priming the EEPROM for devices that need more than just a MAC address in the EEPROM. Signed-off-by: Alban Bedel alban.be...@avionic-design.de --- v2: * No changes since v1 v3: * Replace the dedicated 'eth_eeprom' command with a subcommand to the newly introduced 'eth' command I see a few EEPROM implementations in the code base. It feels to me like we need an EEPROM interface. In driver model terms this could be a uclass. I started something here: http://patchwork.ozlabs.org/patch/399039/ Of course we don't have DM for Ethernet yet - when we do I think a child EEPROM device below the Ethernet would make sense. It could be created by the Ethernet driver when it knows that this information exists. But even without that I feel that the EEPROM should be logically separated from Ethernet. So I suggest that instead of an #ifdef to adjust the Ethernet API, add a pointer to another struct containing the EEPROM API and put it in its own header. I also feel that there should ultimately be an eeprom command which operates on these. Then the only Ethernet API call would be to find the EEPROM pointer, if there is one. If someone feels like taking it on, driver model support for Ethernet should be pretty easy. Or even EEPROM could be done now and this might avoid churn. But I would be happy for this series to be applied as is while working on a driver model version. I just don't feel we should be adding new subsystems that don't use driver model. I agree that we shouldn't add new subsystems that don't use DM. I think this (adding eeprom access to Ethernet) is a decent compromise until we have driver model for Ethernet. I do like your idea of having an eeprom class / subsystem / command that can operate on this type of thing the same way no matter where it's connected, but it probably isn't a good idea to add an eeprom command for that without using DM first. So your idea sounds good, but it leaves me with one question... if we want to accept this now as it is, then do we want to introduce a new command (eth eeprom) when we already know we want to change its behavior or delete it once we add a uclass for eeproms? BTW, speaking of DM for Ethernet, I'll take on moving it over around the end of this month if no one beats me to it. Cheers, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] net: Add a command to access the EEPROM from ethernet devices
Hi Joe, On 14 October 2014 21:14, Joe Hershberger joe.hershber...@gmail.com wrote: On Tue, Oct 14, 2014 at 12:21 PM, Simon Glass s...@chromium.org wrote: Hi, On 14 October 2014 18:26, Alban Bedel alban.be...@avionic-design.de wrote: Many ethernet devices use an EEPROM to store various settings, most commonly the device MAC address. But on some devices it can contains a lot more, for example USB device might also have many USB related parameters. This commit add a set of commands to read/write this EEPROM, write a default configuration and read/write the device MAC address. The defaults command allow priming the EEPROM for devices that need more than just a MAC address in the EEPROM. Signed-off-by: Alban Bedel alban.be...@avionic-design.de --- v2: * No changes since v1 v3: * Replace the dedicated 'eth_eeprom' command with a subcommand to the newly introduced 'eth' command I see a few EEPROM implementations in the code base. It feels to me like we need an EEPROM interface. In driver model terms this could be a uclass. I started something here: http://patchwork.ozlabs.org/patch/399039/ Of course we don't have DM for Ethernet yet - when we do I think a child EEPROM device below the Ethernet would make sense. It could be created by the Ethernet driver when it knows that this information exists. But even without that I feel that the EEPROM should be logically separated from Ethernet. So I suggest that instead of an #ifdef to adjust the Ethernet API, add a pointer to another struct containing the EEPROM API and put it in its own header. I also feel that there should ultimately be an eeprom command which operates on these. Then the only Ethernet API call would be to find the EEPROM pointer, if there is one. If someone feels like taking it on, driver model support for Ethernet should be pretty easy. Or even EEPROM could be done now and this might avoid churn. But I would be happy for this series to be applied as is while working on a driver model version. I just don't feel we should be adding new subsystems that don't use driver model. I agree that we shouldn't add new subsystems that don't use DM. I think this (adding eeprom access to Ethernet) is a decent compromise until we have driver model for Ethernet. I do like your idea of having an eeprom class / subsystem / command that can operate on this type of thing the same way no matter where it's connected, but it probably isn't a good idea to add an eeprom command for that without using DM first. So your idea sounds good, but it leaves me with one question... if we want to accept this now as it is, then do we want to introduce a new command (eth eeprom) when we already know we want to change its behavior or delete it once we add a uclass for eeproms? Good question, in general I suppose we want to avoid changing the commands, although if you get to Ethernet in this merge window then it might not matter much. One option is to indicate in the help that it is a temporary command and the syntax may change. BTW, speaking of DM for Ethernet, I'll take on moving it over around the end of this month if no one beats me to it. SGTM, looking forward to it. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] powerpc/mpc85xx: modify erratum A007186
On 09/27/2014 08:21 PM, Zhao Qiang wrote:
T2080 v1.0 has this errata while v1.1 has fixed
this errata by hardware, add a new function has_errata_a007186
to check the SVR_SOC_VER, SVR_MAJ and SVR_MIN first,
if the sil has errata a007186, then run the errata code,
if not, doesn't run the code.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
Changes for v2:
- use has_errata_a007186 instead of not_has_errata_a007186
arch/powerpc/cpu/mpc85xx/cmd_errata.c | 3 +-
arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c | 210
++---
arch/powerpc/include/asm/fsl_errata.h | 22 +++
3 files changed, 138 insertions(+), 97 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index 3a04a89..0774461 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -270,7 +270,8 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
puts(Work-around for Erratum USB14 enabled\n);
#endif
#ifdef CONFIG_SYS_FSL_ERRATUM_A007186
- puts(Work-around for Erratum A007186 enabled\n);
+ if (has_erratum_a007186())
+ puts(Work-around for Erratum A007186 enabled\n);
#endif
#ifdef CONFIG_SYS_FSL_ERRATUM_A006593
puts(Work-around for Erratum A006593 enabled\n);
diff --git a/arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c
b/arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c
index d1fc76a..ac030be 100644
--- a/arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c
+++ b/arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c
@@ -11,6 +11,7 @@
#include asm/processor.h
#include asm/fsl_law.h
#include asm/errno.h
+#include asm/fsl_errata.h
#include fsl_corenet2_serdes.h
#ifdef CONFIG_SYS_FSL_SRDS_1
@@ -203,108 +204,125 @@ u64 serdes_init(u32 sd, u32 sd_addr, u32
sd_prctl_mask, u32 sd_prctl_shift)
* This workaround for the protocols and rates that only have the Ring VCO.
*/
#ifdef CONFIG_SYS_FSL_ERRATUM_A007186
- sfp_spfr0 = in_be32(sfp_regs-fsl_spfr0);
- debug(A007186: sfp_spfr0= %x\n, sfp_spfr0);
+ if (has_erratum_a007186()) {
+ sfp_spfr0 = in_be32(sfp_regs-fsl_spfr0);
+ debug(A007186: sfp_spfr0= %x\n, sfp_spfr0);
- sel = (sfp_spfr0 FUSE_VAL_SHIFT) FUSE_VAL_MASK;
+ sel = (sfp_spfr0 FUSE_VAL_SHIFT) FUSE_VAL_MASK;
- if (sel == 0x01 || sel == 0x02) {
- for (pll_num = 0; pll_num SRDS_MAX_BANK; pll_num++) {
- pll_status = in_be32(srds_regs-bank[pll_num].pllcr0);
- debug(A007186: pll_num=%x pllcr0=%x\n,
- pll_num, pll_status);
- /* STEP 1 */
- /* Read factory pre-set SerDes calibration values
- * from fuse block(SFP scratch register-sfp_spfr0)
- */
- switch (pll_status SRDS_PLLCR0_FRATE_SEL_MASK) {
- case SRDS_PLLCR0_FRATE_SEL_3_0:
- case SRDS_PLLCR0_FRATE_SEL_3_072:
- debug(A007186: 3.0/3.072 protocol rate\n);
- bc = (sfp_spfr0 BC1_SHIFT) BC_MASK;
- dc = (sfp_spfr0 DC1_SHIFT) DC_MASK;
- fc = (sfp_spfr0 FC1_SHIFT) FC_MASK;
- break;
- case SRDS_PLLCR0_FRATE_SEL_3_125:
- debug(A007186: 3.125 protocol rate\n);
- bc = (sfp_spfr0 BC2_SHIFT) BC_MASK;
- dc = (sfp_spfr0 DC2_SHIFT) DC_MASK;
- fc = (sfp_spfr0 FC2_SHIFT) FC_MASK;
- break;
- case SRDS_PLLCR0_FRATE_SEL_3_75:
- debug(A007186: 3.75 protocol rate\n);
- bc = (sfp_spfr0 BC1_SHIFT) BC_MASK;
- dc = (sfp_spfr0 DC1_SHIFT) DC_MASK;
- fc = (sfp_spfr0 FC1_SHIFT) FC_MASK;
- break;
- default:
- continue;
- }
+ if (sel == 0x01 || sel == 0x02) {
+ for (pll_num = 0; pll_num SRDS_MAX_BANK; pll_num++) {
+ pll_status = in_be32(srds_regs-
+ bank[pll_num].pllcr0);
+ debug(A007186: pll_num=%x pllcr0=%x\n,
+ pll_num, pll_status);
+ /* STEP 1 */
+ /* Read factory pre-set SerDes calibration
+ * values from fuse block(SFP scratch
+ * register-sfp_spfr0)
+ */
+ switch (pll_status
+
Re: [U-Boot] [PATCH v2 2/3] arm: relocate the exception vectors
Hi Albert,
Hi Masahiro,
As my issue is related to Kconfig, I would like you to give me your
opinions.
Le 11/10/2014 12:47, Albert ARIBAUD a écrit :
Hi Georges,
On Sat, 27 Sep 2014 21:48:10 +0200, Georges Savoundararadj
savou...@gmail.com wrote:
This commit relocates the exception vectors.
As ARM1176 and ARMv7 have the security extensions, it uses VBAR. For
the other ARM processors, it copies the relocated exception vectors to
the correct address: 0x or 0x.
Signed-off-by: Georges Savoundararadj savou...@gmail.com
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Tom Warren twar...@nvidia.com
---
This patch needs some tests because it impacts many boards. I have
tested it with my raspberry pi in the two cases: using VBAR and
using the copied exception vectors.
Changes in v2:
- Relocate exception vectors also on processors which do not support
security extensions
- Reword the commit message
arch/arm/cpu/armv7/start.S | 6 --
arch/arm/lib/relocate.S| 30 ++
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index fedd7c8..fdc05b9 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -81,12 +81,6 @@ ENTRY(c_runtime_cpu_setup)
mcr p15, 0, r0, c7, c10, 4 @ DSB
mcr p15, 0, r0, c7, c5, 4 @ ISB
#endif
-/*
- * Move vector table
- */
- /* Set vector address in CP15 VBAR register */
- ldr r0, =_start
- mcr p15, 0, r0, c12, c0, 0 @Set VBAR
bx lr
diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 8035251..88a478e 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -6,6 +6,8 @@
* SPDX-License-Identifier: GPL-2.0+
*/
+#include asm-offsets.h
+#include config.h
#include linux/linkage.h
/*
@@ -52,6 +54,34 @@ fixnext:
cmp r2, r3
blo fixloop
+ /*
+* Relocate the exception vectors
+*/
+#if (defined(CONFIG_ARM1176) || defined(CONFIG_ARMV7))
I would prefer a single CONFIG_HAS_VBAR symbol defined through
Kconfig.
1)
Actually, there is no Kconfig entry such as config ARM1176 nor config
ARMV7 in U-Boot,
unlike in Linux (arch/arm/mm/Kconfig).
If there were such entries, we would simply do like the following (in
arch/arm/Kconfig):
config HAS_VBAR
bool
config ARM1176
select HAS_VBAR
config ARMV7
select HAS_VBAR
Should we go in this direction?
It is the cleanest way to use Kconfig but it requires some work in order
to convert all
#define CONFIG_cpu into Kconfig entries.
2)
Otherwise, we can insert a select HAS_VBAR in all boards that have a
ARM1176 or a ARMv7
processor in arch/arm/Kconfig. It is not logical but this is what has
been done with the Kconfig
entry ARM64. And, it does not require much change.
3)
The last thing we can do is as follows:
config HAS_VBAR
bool
depends on SYS_CPU = arm1176 || SYS_CPU = armv7
default y
CONFIG_HAS_VBAR will be defined if SYS_CPU are arm1176 or armv7. It does
not require much
change as well but, I think, it is bad code.
What do you think is the best way to introduce CONFIG_HAS_VBAR symbol?
(1, 2 or 3)
+ /*
+* If the ARM processor has the security extensions,
+* use VBAR to relocate the exception vectors.
+*/
+ ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd-relocaddr */
+ mcr p15, 0, r0, c12, c0, 0 /* Set VBAR */
+#else
+ /*
+* Copy the relocated exception vectors to the
+* correct address
+* CP15 c1 V bit gives us the location of the vectors:
+* 0x or 0x.
+*/
+ ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd-relocaddr */
+ mrc p15, 0, r2, c1, c0, 0 /* V bit (bit[13]) in CP15 c1 */
+ andsr2, r2, #(1 13)
+ ldreq r1, =0x /* If V=0 */
+ ldrne r1, =0x /* If V=1 */
+ ldmia r0!, {r2-r8,r10}
+ stmia r1!, {r2-r8,r10}
+ ldmia r0!, {r2-r8,r10}
+ stmia r1!, {r2-r8,r10}
+#endif
+
relocate_done:
#ifdef __XSCALE__
Amicalement,
Regards,
Georges
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/BSC9132QDS: Enable creation of dynamic partition for NAND and NOR
On 10/06/2014 05:54 AM, Ashish Kumar wrote:
* fdt_fixup_mtdparts is called from ft_board_setup
* run mtdparts default to create NAND, NOR partition on uboot
* Use mtdparts to create partitions dynamically rather
than using static partitions in device tree
Signed-off-by: Ashish Kumar ashish.ku...@freescale.com
---
board/freescale/bsc9132qds/bsc9132qds.c | 12
include/configs/BSC9132QDS.h| 21 +
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/board/freescale/bsc9132qds/bsc9132qds.c
b/board/freescale/bsc9132qds/bsc9132qds.c
index 10580bc..c88838b 100644
--- a/board/freescale/bsc9132qds/bsc9132qds.c
+++ b/board/freescale/bsc9132qds/bsc9132qds.c
@@ -21,6 +21,9 @@
#include hwconfig.h
#include i2c.h
#include fsl_ddr_sdram.h
+#include jffs2/load_kernel.h
+#include mtd_node.h
+#include flash.h
#ifdef CONFIG_PCI
#include pci.h
@@ -354,6 +357,12 @@ void fdt_del_node_compat(void *blob, const char
*compatible)
}
#if defined(CONFIG_OF_BOARD_SETUP)
+#ifdef CONFIG_FDT_FIXUP_PARTITIONS
+struct node_info nodes[] = {
+ { cfi-flash, MTD_DEV_TYPE_NOR, },
+ { fsl,ifc-nand, MTD_DEV_TYPE_NAND, },
+};
+#endif
void ft_board_setup(void *blob, bd_t *bd)
{
phys_addr_t base;
@@ -369,6 +378,9 @@ void ft_board_setup(void *blob, bd_t *bd)
#endif
fdt_fixup_memory(blob, (u64)base, (u64)size);
+#ifdef CONFIG_FDT_FIXUP_PARTITIONS
+ fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes));
+#endif
ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
u32 porbmsr = in_be32(gur-porbmsr);
diff --git a/include/configs/BSC9132QDS.h b/include/configs/BSC9132QDS.h
index aeded6d..da78a19 100644
--- a/include/configs/BSC9132QDS.h
+++ b/include/configs/BSC9132QDS.h
@@ -630,6 +630,27 @@ combinations. this should be removed later
#endif
/*
+ * Dynamic MTD Partition support with mtdparts
+ */
+#ifndef CONFIG_SYS_NO_FLASH
+#define CONFIG_MTD_DEVICE
+#define CONFIG_MTD_PARTITIONS
+#define CONFIG_CMD_MTDPARTS
+#define CONFIG_FLASH_CFI_MTD
+#define MTDIDS_DEFAULT nor0=8800.nor,nand0=ff80.flash,
+#define MTDPARTS_DEFAULT mtdparts=8800.nor:256k(dtb),7m(kernel), \
+ 55m(fs),1m(uboot);ff80.flash:1m(uboot), \
+ 8m(kernel),512k(dtb),-(fs)
+#endif
Isn't this patch conflict with your earlier patch?
http://patchwork.ozlabs.org/patch/391991/
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/BSC9132QDS: Enable creation of dynamic partition for NAND and NOR
On 10/14/2014 01:19 PM, Kumar Ashish-B37399 wrote:
Hi York,
Yes, I should superseed/reject the below patches
http://patchwork.ozlabs.org/patch/391991/
I think your v2 patch reduced the size of SPI. Please check before you mark them
superseded.
York
http://patchwork.ozlabs.org/patch/391990/
Regards
Ashish
-Original Message-
From: Sun York-R58495
Sent: Wednesday, October 15, 2014 1:44 AM
To: Kumar Ashish-B37399; u-Boot@lists.denx.de
Cc: Wood Scott-B07421
Subject: Re: [PATCH] powerpc/BSC9132QDS: Enable creation of dynamic partition
for NAND and NOR
On 10/06/2014 05:54 AM, Ashish Kumar wrote:
* fdt_fixup_mtdparts is called from ft_board_setup
* run mtdparts default to create NAND, NOR partition on uboot
* Use mtdparts to create partitions dynamically rather
than using static partitions in device tree
Signed-off-by: Ashish Kumar ashish.ku...@freescale.com
---
board/freescale/bsc9132qds/bsc9132qds.c | 12
include/configs/BSC9132QDS.h| 21 +
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/board/freescale/bsc9132qds/bsc9132qds.c
b/board/freescale/bsc9132qds/bsc9132qds.c
index 10580bc..c88838b 100644
--- a/board/freescale/bsc9132qds/bsc9132qds.c
+++ b/board/freescale/bsc9132qds/bsc9132qds.c
@@ -21,6 +21,9 @@
#include hwconfig.h
#include i2c.h
#include fsl_ddr_sdram.h
+#include jffs2/load_kernel.h
+#include mtd_node.h
+#include flash.h
#ifdef CONFIG_PCI
#include pci.h
@@ -354,6 +357,12 @@ void fdt_del_node_compat(void *blob, const char
*compatible) }
#if defined(CONFIG_OF_BOARD_SETUP)
+#ifdef CONFIG_FDT_FIXUP_PARTITIONS
+struct node_info nodes[] = {
+{ cfi-flash, MTD_DEV_TYPE_NOR, },
+{ fsl,ifc-nand, MTD_DEV_TYPE_NAND, },
+};
+#endif
void ft_board_setup(void *blob, bd_t *bd) {
phys_addr_t base;
@@ -369,6 +378,9 @@ void ft_board_setup(void *blob, bd_t *bd)
#endif
fdt_fixup_memory(blob, (u64)base, (u64)size);
+#ifdef CONFIG_FDT_FIXUP_PARTITIONS
+fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes)); #endif
ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
u32 porbmsr = in_be32(gur-porbmsr); diff --git
a/include/configs/BSC9132QDS.h b/include/configs/BSC9132QDS.h index
aeded6d..da78a19 100644
--- a/include/configs/BSC9132QDS.h
+++ b/include/configs/BSC9132QDS.h
@@ -630,6 +630,27 @@ combinations. this should be removed later
#endif
/*
+ * Dynamic MTD Partition support with mtdparts */ #ifndef
+CONFIG_SYS_NO_FLASH #define CONFIG_MTD_DEVICE #define
+CONFIG_MTD_PARTITIONS #define CONFIG_CMD_MTDPARTS #define
+CONFIG_FLASH_CFI_MTD #define MTDIDS_DEFAULT
+nor0=8800.nor,nand0=ff80.flash,
+#define MTDPARTS_DEFAULT mtdparts=8800.nor:256k(dtb),7m(kernel), \
+55m(fs),1m(uboot);ff80.flash:1m(uboot), \
+8m(kernel),512k(dtb),-(fs)
+#endif
Isn't this patch conflict with your earlier patch?
http://patchwork.ozlabs.org/patch/391991/
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/7] common: spl: Add interactive DDR debugger support for SPL
On 09/26/2014 03:33 AM, Alison Wang wrote: For LS102xA, interactive DDR debugger is still needed in SPL part. So build the needed files in SPL image too. Signed-off-by: Alison Wang alison.w...@freescale.com --- Change log: v2: No change. common/Makefile | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/common/Makefile b/common/Makefile index b19d379..a166e4c 100644 --- a/common/Makefile +++ b/common/Makefile @@ -8,22 +8,12 @@ # core ifndef CONFIG_SPL_BUILD obj-y += main.o -obj-y += command.o obj-y += exports.o obj-y += hash.o ifdef CONFIG_SYS_HUSH_PARSER obj-y += cli_hush.o endif -# We always have this since drivers/ddr/fs/interactive.c needs it -obj-y += cli_simple.o - -obj-y += cli.o -obj-y += cli_readline.o -obj-y += s_record.o -obj-y += xyzModem.o -obj-y += cmd_disk.o - # This option is not just y/n - it can have a numeric value ifdef CONFIG_BOOTDELAY obj-y += autoboot.o @@ -265,4 +255,14 @@ obj-y += aboot.o obj-y += fb_mmc.o endif +# We always have this since drivers/ddr/fs/interactive.c needs it +obj-y += cli_simple.o + +obj-y += cli.o +obj-y += cli_readline.o +obj-y += command.o +obj-y += s_record.o +obj-y += xyzModem.o +obj-y += cmd_disk.o + CFLAGS_env_embedded.o := -Wa,--no-warn -DENV_CRC=$(shell tools/envcrc 2/dev/null) Can you explain more in commit message why moving them around adds interactive DDR debugging? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/BSC9132QDS: Enable creation of dynamic partition for NAND and NOR
Hi York,
Yes, I should superseed/reject the below patches
http://patchwork.ozlabs.org/patch/391991/
http://patchwork.ozlabs.org/patch/391990/
Regards
Ashish
-Original Message-
From: Sun York-R58495
Sent: Wednesday, October 15, 2014 1:44 AM
To: Kumar Ashish-B37399; u-Boot@lists.denx.de
Cc: Wood Scott-B07421
Subject: Re: [PATCH] powerpc/BSC9132QDS: Enable creation of dynamic partition
for NAND and NOR
On 10/06/2014 05:54 AM, Ashish Kumar wrote:
* fdt_fixup_mtdparts is called from ft_board_setup
* run mtdparts default to create NAND, NOR partition on uboot
* Use mtdparts to create partitions dynamically rather
than using static partitions in device tree
Signed-off-by: Ashish Kumar ashish.ku...@freescale.com
---
board/freescale/bsc9132qds/bsc9132qds.c | 12
include/configs/BSC9132QDS.h| 21 +
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/board/freescale/bsc9132qds/bsc9132qds.c
b/board/freescale/bsc9132qds/bsc9132qds.c
index 10580bc..c88838b 100644
--- a/board/freescale/bsc9132qds/bsc9132qds.c
+++ b/board/freescale/bsc9132qds/bsc9132qds.c
@@ -21,6 +21,9 @@
#include hwconfig.h
#include i2c.h
#include fsl_ddr_sdram.h
+#include jffs2/load_kernel.h
+#include mtd_node.h
+#include flash.h
#ifdef CONFIG_PCI
#include pci.h
@@ -354,6 +357,12 @@ void fdt_del_node_compat(void *blob, const char
*compatible) }
#if defined(CONFIG_OF_BOARD_SETUP)
+#ifdef CONFIG_FDT_FIXUP_PARTITIONS
+struct node_info nodes[] = {
+ { cfi-flash, MTD_DEV_TYPE_NOR, },
+ { fsl,ifc-nand, MTD_DEV_TYPE_NAND, },
+};
+#endif
void ft_board_setup(void *blob, bd_t *bd) {
phys_addr_t base;
@@ -369,6 +378,9 @@ void ft_board_setup(void *blob, bd_t *bd)
#endif
fdt_fixup_memory(blob, (u64)base, (u64)size);
+#ifdef CONFIG_FDT_FIXUP_PARTITIONS
+ fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes)); #endif
ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
u32 porbmsr = in_be32(gur-porbmsr); diff --git
a/include/configs/BSC9132QDS.h b/include/configs/BSC9132QDS.h index
aeded6d..da78a19 100644
--- a/include/configs/BSC9132QDS.h
+++ b/include/configs/BSC9132QDS.h
@@ -630,6 +630,27 @@ combinations. this should be removed later
#endif
/*
+ * Dynamic MTD Partition support with mtdparts */ #ifndef
+CONFIG_SYS_NO_FLASH #define CONFIG_MTD_DEVICE #define
+CONFIG_MTD_PARTITIONS #define CONFIG_CMD_MTDPARTS #define
+CONFIG_FLASH_CFI_MTD #define MTDIDS_DEFAULT
+nor0=8800.nor,nand0=ff80.flash,
+#define MTDPARTS_DEFAULT mtdparts=8800.nor:256k(dtb),7m(kernel), \
+ 55m(fs),1m(uboot);ff80.flash:1m(uboot), \
+ 8m(kernel),512k(dtb),-(fs)
+#endif
Isn't this patch conflict with your earlier patch?
http://patchwork.ozlabs.org/patch/391991/
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] arm: ls102xa: Add SD boot support for LS1021ATWR board
On 09/26/2014 03:33 AM, Alison Wang wrote: This patch adds SD boot support for LS1021ATWR board. SPL framework is used. PBL initialize the internal RAM and copy SPL to it, then SPL initialize DDR using SPD and copy u-boot from SD card to DDR, finally SPL transfer control to u-boot. Signed-off-by: Chen Lu chen...@freescale.com Signed-off-by: Alison Wang alison.w...@freescale.com Signed-off-by: Jason Jin jason@freescale.com --- Change log: v2: Use generic u-boot-spl.lds. Please update status and maintainers for this board. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/7] arm: ls102xa: Add SD boot support for LS1021AQDS board
On 09/26/2014 03:33 AM, Alison Wang wrote: This patch adds SD boot support for LS1021AQDS board. SPL framework is used. PBL initialize the internal RAM and copy SPL to it, then SPL initialize DDR using SPD and copy u-boot from SD card to DDR, finally SPL transfer control to u-boot. Signed-off-by: Alison Wang alison.w...@freescale.com Signed-off-by: Jason Jin jason@freescale.com --- Change log: v2: Use generic u-boot-spl.lds. Please update status and maintainers for this board. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] net: Add a command to access the EEPROM from ethernet devices
On Tuesday, October 14, 2014 at 07:21:06 PM, Simon Glass wrote: Hi, On 14 October 2014 18:26, Alban Bedel alban.be...@avionic-design.de wrote: Many ethernet devices use an EEPROM to store various settings, most commonly the device MAC address. But on some devices it can contains a lot more, for example USB device might also have many USB related parameters. This commit add a set of commands to read/write this EEPROM, write a default configuration and read/write the device MAC address. The defaults command allow priming the EEPROM for devices that need more than just a MAC address in the EEPROM. Signed-off-by: Alban Bedel alban.be...@avionic-design.de --- v2: * No changes since v1 v3: * Replace the dedicated 'eth_eeprom' command with a subcommand to the newly introduced 'eth' command I see a few EEPROM implementations in the code base. It feels to me like we need an EEPROM interface. In driver model terms this could be a uclass. I started something here: http://patchwork.ozlabs.org/patch/399039/ Of course we don't have DM for Ethernet yet - when we do I think a child EEPROM device below the Ethernet would make sense. It could be created by the Ethernet driver when it knows that this information exists. But even without that I feel that the EEPROM should be logically separated from Ethernet. So I suggest that instead of an #ifdef to adjust the Ethernet API, add a pointer to another struct containing the EEPROM API and put it in its own header. I also feel that there should ultimately be an eeprom command which operates on these. Then the only Ethernet API call would be to find the EEPROM pointer, if there is one. If someone feels like taking it on, driver model support for Ethernet should be pretty easy. Or even EEPROM could be done now and this might avoid churn. But I would be happy for this series to be applied as is while working on a driver model version. I just don't feel we should be adding new subsystems that don't use driver model. Speaking of eeprom command, I am now in the process of cleaning up common/cmd_eeprom.c . Simon, do you have anything related to DM which explicitly touches this file ? If not, I'd suggest you wait a bit until I manage to resolve the ifdef maze in there and look into it only after the cleanup is done. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On Saturday, October 11, 2014 at 03:39:36 AM, Fabio Estevam wrote: Hi Marek, Fixed all, I dunno where my git-foo got wrong :/ Thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On Sunday, October 12, 2014 at 08:33:21 AM, Sean Cross wrote: On 12/10/2014 05:04, Fabio Estevam wrote: On Sat, Oct 11, 2014 at 11:21 AM, Sean Cross x...@kosagi.com wrote: Ok, understood. Just curious: which Ethernet PHY is used on the novena board? It's the same Micrel PHY used on the Sabrelite, the KSZ9021. nitrogen/sabrelite holds Ethernet PHY reset low for 10ms, which is in accordance with ksz9021 datasheet. Shouldn't we wait 10ms here as well? The reference manual for the PHY indicates that you should hold reset low for 10ms after the supply voltage stabilizes. So long as it takes at least 10msto get from the point at which the CPU starts executing its ROM code to the point at which the reset line is toggled, we will be fine. This definitelly is the case, so I presume we don't need the delay ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] arm: relocate the exception vectors
Hi Georges, On Tue, 14 Oct 2014 22:02:00 +0200, Georges Savoundararadj savou...@gmail.com wrote: Hi Albert, Hi Masahiro, (putting Masahiro in Cc: just in case) As my issue is related to Kconfig, I would like you to give me your opinions. Le 11/10/2014 12:47, Albert ARIBAUD a écrit : Hi Georges, On Sat, 27 Sep 2014 21:48:10 +0200, Georges Savoundararadj savou...@gmail.com wrote: This commit relocates the exception vectors. As ARM1176 and ARMv7 have the security extensions, it uses VBAR. For the other ARM processors, it copies the relocated exception vectors to the correct address: 0x or 0x. Signed-off-by: Georges Savoundararadj savou...@gmail.com Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Tom Warren twar...@nvidia.com --- This patch needs some tests because it impacts many boards. I have tested it with my raspberry pi in the two cases: using VBAR and using the copied exception vectors. Changes in v2: - Relocate exception vectors also on processors which do not support security extensions - Reword the commit message arch/arm/cpu/armv7/start.S | 6 -- arch/arm/lib/relocate.S| 30 ++ 2 files changed, 30 insertions(+), 6 deletions(-) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index fedd7c8..fdc05b9 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -81,12 +81,6 @@ ENTRY(c_runtime_cpu_setup) mcr p15, 0, r0, c7, c10, 4 @ DSB mcr p15, 0, r0, c7, c5, 4 @ ISB #endif -/* - * Move vector table - */ - /* Set vector address in CP15 VBAR register */ - ldr r0, =_start - mcr p15, 0, r0, c12, c0, 0 @Set VBAR bx lr diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S index 8035251..88a478e 100644 --- a/arch/arm/lib/relocate.S +++ b/arch/arm/lib/relocate.S @@ -6,6 +6,8 @@ * SPDX-License-Identifier: GPL-2.0+ */ +#include asm-offsets.h +#include config.h #include linux/linkage.h /* @@ -52,6 +54,34 @@ fixnext: cmp r2, r3 blo fixloop + /* + * Relocate the exception vectors + */ +#if (defined(CONFIG_ARM1176) || defined(CONFIG_ARMV7)) I would prefer a single CONFIG_HAS_VBAR symbol defined through Kconfig. 1) Actually, there is no Kconfig entry such as config ARM1176 nor config ARMV7 in U-Boot, unlike in Linux (arch/arm/mm/Kconfig). If there were such entries, we would simply do like the following (in arch/arm/Kconfig): config HAS_VBAR bool config ARM1176 select HAS_VBAR config ARMV7 select HAS_VBAR Should we go in this direction? It is the cleanest way to use Kconfig but it requires some work in order to convert all #define CONFIG_cpu into Kconfig entries. 2) Otherwise, we can insert a select HAS_VBAR in all boards that have a ARM1176 or a ARMv7 processor in arch/arm/Kconfig. It is not logical but this is what has been done with the Kconfig entry ARM64. And, it does not require much change. 3) The last thing we can do is as follows: config HAS_VBAR bool depends on SYS_CPU = arm1176 || SYS_CPU = armv7 default y CONFIG_HAS_VBAR will be defined if SYS_CPU are arm1176 or armv7. It does not require much change as well but, I think, it is bad code. What do you think is the best way to introduce CONFIG_HAS_VBAR symbol? (1, 2 or 3) I believe you have already sorted the options in order of decreasing 'quality' -- 1 being the best option, and 3 being the worst... Indeed option 1 would be the best and cleanest, and it could possibly open the way for other per-CPU options. We could try and limit the effort to converting only ARM1176 and ARMV7 and leaving other CONFIG_cpu #define'd until some later point in the future, but experience shows that such half-hearted attempts are never completed. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Kconfig: Add EXPERT option
Hi Tom, On Tue, 14 Oct 2014 08:39:20 -0400, Tom Rini tr...@ti.com wrote: For similar reasons to why the Linux Kernel has an EXPERT option, we too want an option to allow for tweaking of some options that while normally should remain hidden, may need to be changed in some cases. Signed-off-by: Tom Rini tr...@ti.com --- Kconfig |8 1 file changed, 8 insertions(+) diff --git a/Kconfig b/Kconfig index e0c8992..73785b00 100644 --- a/Kconfig +++ b/Kconfig @@ -58,6 +58,14 @@ config CC_OPTIMIZE_FOR_SIZE endmenu # General setup +menuconfig EXPERT +bool Configure standard U-Boot features (expert users) +help + This option allows certain base U-Boot options and settings + to be disabled or tweaked. This is for specialized + environments which can tolerate a non-standard U-Boot. + Only use this if you really know what you are doing. + menu Boot images config SPL_BUILD Half-OT: we have a policy of not adding dead code in U-Boot. Here, this Kconfig change introduces CONFIG_EXPERT, but nowhere in the code is it used. Should we consider this dead code as well (and thus, expect/accept it only in a patch series where the EXPERT config is used somewhere else in the code) or not? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: add PCIe-related pins to the Jetson TK1 pinmux tables
Hi Tom, On Tue, 14 Oct 2014 18:05:40 +, Tom Warren twar...@nvidia.com wrote: My gmail account has been in flux for a few weeks, so I can't say for sure whether I sent a PR or not. I've gone through the U-Boot archives, and the last tegra PR sent was on aug 20, applied aug 29. I'll resend one today to Albert. I'll make sue to apply it as soon as I get it in my inbox. Tom Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: add PCIe-related pins to the Jetson TK1 pinmux tables
Albert, Please pull u-boot-tegra/master into ARM/master. Thanks! The following changes since commit a7f99bf139b3aaa0d5494693fd0395084355e41a: arm: Fix _start for CONFIG_SYS_DV_NOR_BOOT_CFG (2014-09-11 18:04:39 +0200) are available in the git repository at: git://git.denx.de/u-boot-tegra.git master for you to fetch changes up to 90a565acf3a18c61170ec0e0b2046c98cb7ecc85: arm: tegra: initial support for apalis t30 (2014-09-17 11:15:04 -0700) Marcel Ziswiler (1): arm: tegra: initial support for apalis t30 Stephen Warren (1): ARM: tegra: add PCIe-related pins to the Jetson TK1 pinmux tables arch/arm/cpu/armv7/tegra30/Kconfig | 4 + arch/arm/dts/Makefile | 1 + arch/arm/dts/tegra30-apalis.dts| 300 ++ arch/arm/include/asm/mach-types.h | 13 + board/nvidia/jetson-tk1/pinmux-config-jetson-tk1.h | 5 + board/toradex/apalis_t30/Kconfig | 15 + board/toradex/apalis_t30/MAINTAINERS | 7 + board/toradex/apalis_t30/Makefile | 6 + board/toradex/apalis_t30/apalis_t30.c | 92 ++ .../toradex/apalis_t30/pinmux-config-apalis_t30.h | 347 + configs/apalis_t30_defconfig | 4 + include/configs/apalis_t30.h | 80 + 12 files changed, 874 insertions(+) create mode 100644 arch/arm/dts/tegra30-apalis.dts create mode 100644 board/toradex/apalis_t30/Kconfig create mode 100644 board/toradex/apalis_t30/MAINTAINERS create mode 100644 board/toradex/apalis_t30/Makefile create mode 100644 board/toradex/apalis_t30/apalis_t30.c create mode 100644 board/toradex/apalis_t30/pinmux-config-apalis_t30.h create mode 100644 configs/apalis_t30_defconfig create mode 100644 include/configs/apalis_t30.h -- nvpublic -Original Message- From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] Sent: Tuesday, October 14, 2014 3:28 PM To: Tom Warren Cc: Stephen Warren; Tom Rini; u-boot@lists.denx.de; Simon Glass; Stephen Warren; Thierry Reding Subject: Re: [U-Boot] [PATCH] ARM: tegra: add PCIe-related pins to the Jetson TK1 pinmux tables Hi Tom, On Tue, 14 Oct 2014 18:05:40 +, Tom Warren twar...@nvidia.com wrote: My gmail account has been in flux for a few weeks, so I can't say for sure whether I sent a PR or not. I've gone through the U-Boot archives, and the last tegra PR sent was on aug 20, applied aug 29. I'll resend one today to Albert. I'll make sue to apply it as soon as I get it in my inbox. Tom Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch v4 0/6] keystone2: add k2l SoC and k2l_evm board support
This patch series adds Keystone II Lamar (K2L) SoC and k2l_evm board support. Based on [U-boot] [Patch v2] keystone: usb: add support of usb xhci https://patchwork.ozlabs.org/patch/386506/ v4..v3 - keystone2: k2l-evm: add board support remove dimm name reading v3..v2 - keystone2: k2l-evm: add board support Add maintainers information Enable SPL by default v2..v1 Rebased according to changes of c338f09e965a300ddd78af73e86c4af4c9464ce4 keystone: kconfig: move board select menu and common settings Hao Zhang (6): ARM: keystone2: add K2L device hardware definitions keystone2: clock: add K2L clock definitions and commands keystone2: msmc: add MSMC cache coherency support for K2L SOC ARM: keystone2: spl: add K2L SoC support keystone2: enable OSR clock domain for K2L SoC keystone2: k2l-evm: add board support arch/arm/cpu/armv7/keystone/Kconfig| 3 + arch/arm/cpu/armv7/keystone/Makefile | 1 + arch/arm/cpu/armv7/keystone/clock-k2l.c| 138 + arch/arm/cpu/armv7/keystone/cmd_clock.c| 10 ++ arch/arm/cpu/armv7/keystone/init.c | 52 arch/arm/cpu/armv7/keystone/spl.c | 7 ++ arch/arm/include/asm/arch-keystone/clock-k2l.h | 94 ++ arch/arm/include/asm/arch-keystone/clock.h | 4 + arch/arm/include/asm/arch-keystone/hardware-k2hk.h | 2 - arch/arm/include/asm/arch-keystone/hardware-k2l.h | 99 +++ arch/arm/include/asm/arch-keystone/hardware.h | 14 +++ board/ti/ks2_evm/Kconfig | 16 +++ board/ti/ks2_evm/MAINTAINERS | 2 + board/ti/ks2_evm/Makefile | 2 + board/ti/ks2_evm/board_k2l.c | 60 + board/ti/ks2_evm/ddr3_cfg.c| 36 ++ board/ti/ks2_evm/ddr3_cfg.h| 3 + board/ti/ks2_evm/ddr3_k2l.c| 43 +++ configs/k2l_evm_defconfig | 4 + include/configs/k2l_evm.h | 37 ++ 20 files changed, 625 insertions(+), 2 deletions(-) create mode 100644 arch/arm/cpu/armv7/keystone/clock-k2l.c create mode 100644 arch/arm/include/asm/arch-keystone/clock-k2l.h create mode 100644 arch/arm/include/asm/arch-keystone/hardware-k2l.h create mode 100644 board/ti/ks2_evm/board_k2l.c create mode 100644 board/ti/ks2_evm/ddr3_k2l.c create mode 100644 configs/k2l_evm_defconfig create mode 100644 include/configs/k2l_evm.h -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch v4 1/6] ARM: keystone2: add K2L device hardware definitions
From: Hao Zhang hzh...@ti.com
This patch adds hardware definitions specific to Keystone II
Lamar (K2L) SoC.
Acked-by: Vitaly Andrianov vita...@ti.com
Signed-off-by: Hao Zhang hzh...@ti.com
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
arch/arm/include/asm/arch-keystone/hardware-k2hk.h | 2 -
arch/arm/include/asm/arch-keystone/hardware-k2l.h | 74 ++
arch/arm/include/asm/arch-keystone/hardware.h | 13
3 files changed, 87 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/include/asm/arch-keystone/hardware-k2l.h
diff --git a/arch/arm/include/asm/arch-keystone/hardware-k2hk.h
b/arch/arm/include/asm/arch-keystone/hardware-k2hk.h
index 43c2c42..2db806c 100644
--- a/arch/arm/include/asm/arch-keystone/hardware-k2hk.h
+++ b/arch/arm/include/asm/arch-keystone/hardware-k2hk.h
@@ -10,8 +10,6 @@
#ifndef __ASM_ARCH_HARDWARE_K2HK_H
#define __ASM_ARCH_HARDWARE_K2HK_H
-#define KS2_MISC_CTRL (KS2_DEVICE_STATE_CTRL_BASE + 0xc7c)
-
#define KS2_ARM_PLL_EN BIT(13)
/* PA SS Registers */
diff --git a/arch/arm/include/asm/arch-keystone/hardware-k2l.h
b/arch/arm/include/asm/arch-keystone/hardware-k2l.h
new file mode 100644
index 000..3402d0c
--- /dev/null
+++ b/arch/arm/include/asm/arch-keystone/hardware-k2l.h
@@ -0,0 +1,74 @@
+/*
+ * K2L: SoC definitions
+ *
+ * (C) Copyright 2012-2014
+ * Texas Instruments Incorporated, www.ti.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __ASM_ARCH_HARDWARE_K2L_H
+#define __ASM_ARCH_HARDWARE_K2L_H
+
+#define KS2_ARM_PLL_EN BIT(13)
+
+/* PA SS Registers */
+#define KS2_PASS_BASE 0x2600
+
+/* Power and Sleep Controller (PSC) Domains */
+#define KS2_LPSC_MOD 0
+#define KS2_LPSC_DFE_IQN_SYS 1
+#define KS2_LPSC_USB 2
+#define KS2_LPSC_EMIF25_SPI3
+#define KS2_LPSC_TSIP 4
+#define KS2_LPSC_DEBUGSS_TRC 5
+#define KS2_LPSC_TETB_TRC 6
+#define KS2_LPSC_PKTPROC 7
+#define KS2_LPSC_PAKS2_LPSC_PKTPROC
+#define KS2_LPSC_SGMII 8
+#define KS2_LPSC_CPGMACKS2_LPSC_SGMII
+#define KS2_LPSC_CRYPTO9
+#define KS2_LPSC_PCIE0 10
+#define KS2_LPSC_PCIE1 11
+#define KS2_LPSC_JESD_MISC 12
+#define KS2_LPSC_CHIP_SRSS 13
+#define KS2_LPSC_MSMC 14
+#define KS2_LPSC_GEM_1 16
+#define KS2_LPSC_GEM_2 17
+#define KS2_LPSC_GEM_3 18
+#define KS2_LPSC_EMIF4F_DDR3 23
+#define KS2_LPSC_TAC 25
+#define KS2_LPSC_RAC 26
+#define KS2_LPSC_DDUC4X_CFR2X_BB 27
+#define KS2_LPSC_FFTC_A28
+#define KS2_LPSC_OSR 34
+#define KS2_LPSC_TCP3D_0 35
+#define KS2_LPSC_TCP3D_1 37
+#define KS2_LPSC_VCP2X4_A 39
+#define KS2_LPSC_VCP2X4_B 40
+#define KS2_LPSC_VCP2X4_C 41
+#define KS2_LPSC_VCP2X4_D 42
+#define KS2_LPSC_BCP 47
+#define KS2_LPSC_DPD4X 48
+#define KS2_LPSC_FFTC_B49
+#define KS2_LPSC_IQN_AIL 50
+
+/* Chip Interrupt Controller */
+#define KS2_CIC2_DDR3_ECC_IRQ_NUM 0x0D3
+#define KS2_CIC2_DDR3_ECC_CHAN_NUM 0x01D
+
+/* Number of DSP cores */
+#define KS2_NUM_DSPS 4
+
+/* NETCP pktdma */
+#define KS2_NETCP_PDMA_CTRL_BASE 0x26186000
+#define KS2_NETCP_PDMA_TX_BASE 0x26187000
+#define KS2_NETCP_PDMA_TX_CH_NUM 21
+#define KS2_NETCP_PDMA_RX_BASE 0x26188000
+#define KS2_NETCP_PDMA_RX_CH_NUM 91
+#define KS2_NETCP_PDMA_SCHED_BASE 0x26186100
+#define KS2_NETCP_PDMA_RX_FLOW_BASE0x26189000
+#define KS2_NETCP_PDMA_RX_FLOW_NUM 96
+#define KS2_NETCP_PDMA_TX_SND_QUEUE896
+
+#endif /* __ASM_ARCH_HARDWARE_K2L_H */
diff --git a/arch/arm/include/asm/arch-keystone/hardware.h
b/arch/arm/include/asm/arch-keystone/hardware.h
index c1642a5..adae69e 100644
--- a/arch/arm/include/asm/arch-keystone/hardware.h
+++ b/arch/arm/include/asm/arch-keystone/hardware.h
@@ -143,6 +143,7 @@ typedef volatile unsigned int *dv_reg_p;
/* Device speed */
#define KS2_REV1_DEVSPEED (KS2_DEVICE_STATE_CTRL_BASE + 0xc98)
#define KS2_EFUSE_BOOTROM (KS2_DEVICE_STATE_CTRL_BASE + 0xc90)
+#define KS2_MISC_CTRL (KS2_DEVICE_STATE_CTRL_BASE + 0xc7c)
/* Queue manager */
#define KS2_QM_BASE_ADDRESS0x23a8
@@ -177,6 +178,10 @@ typedef volatile unsigned int *dv_reg_p;
#include asm/arch/hardware-k2e.h
#endif
+#ifdef CONFIG_SOC_K2L
+#include asm/arch/hardware-k2l.h
+#endif
+
#ifndef __ASSEMBLY__
static inline int cpu_is_k2hk(void)
{
@@ -194,6 +199,14 @@ static inline int cpu_is_k2e(void)
return (part_no == 0xb9a6) ? 1 : 0;
}
[U-Boot] [U-boot] [Patch v4 4/6] ARM: keystone2: spl: add K2L SoC support
From: Hao Zhang hzh...@ti.com
Add Keystone II Lamar (K2L) SoC support.
Acked-by: Vitaly Andrianov vita...@ti.com
Signed-off-by: Hao Zhang hzh...@ti.com
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
arch/arm/cpu/armv7/keystone/spl.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/cpu/armv7/keystone/spl.c
b/arch/arm/cpu/armv7/keystone/spl.c
index d4b0e9b..6a3adf4 100644
--- a/arch/arm/cpu/armv7/keystone/spl.c
+++ b/arch/arm/cpu/armv7/keystone/spl.c
@@ -31,6 +31,13 @@ static struct pll_init_data spl_pll_config[] = {
};
#endif
+#ifdef CONFIG_K2L_EVM
+static struct pll_init_data spl_pll_config[] = {
+ CORE_PLL_799,
+ TETRIS_PLL_491,
+};
+#endif
+
void spl_init_keystone_plls(void)
{
init_plls(ARRAY_SIZE(spl_pll_config), spl_pll_config);
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch v4 5/6] keystone2: enable OSR clock domain for K2L SoC
From: Hao Zhang hzh...@ti.com
This patches enables the On-chip Shared Ram clock domain for K2L SoC.
Signed-off-by: Hao Zhang hzh...@ti.com
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
arch/arm/cpu/armv7/keystone/init.c| 49 +++
arch/arm/include/asm/arch-keystone/hardware-k2l.h | 25
arch/arm/include/asm/arch-keystone/hardware.h | 1 +
3 files changed, 75 insertions(+)
diff --git a/arch/arm/cpu/armv7/keystone/init.c
b/arch/arm/cpu/armv7/keystone/init.c
index a0ecfa2..2228132 100644
--- a/arch/arm/cpu/armv7/keystone/init.c
+++ b/arch/arm/cpu/armv7/keystone/init.c
@@ -13,6 +13,7 @@
#include asm/arch/msmc.h
#include asm/arch/clock.h
#include asm/arch/hardware.h
+#include asm/arch/psc_defs.h
void chip_configuration_unlock(void)
{
@@ -20,6 +21,53 @@ void chip_configuration_unlock(void)
__raw_writel(KS2_KICK1_MAGIC, KS2_KICK1);
}
+#ifdef CONFIG_SOC_K2L
+void osr_init(void)
+{
+ u32 i;
+ u32 j;
+ u32 val;
+ u32 base = KS2_OSR_CFG_BASE;
+ u32 ecc_ctrl[KS2_OSR_NUM_RAM_BANKS];
+
+ /* Enable the OSR clock domain */
+ psc_enable_module(KS2_LPSC_OSR);
+
+ /* Disable OSR ECC check for all the ram banks */
+ for (i = 0; i KS2_OSR_NUM_RAM_BANKS; i++) {
+ val = i | KS2_OSR_ECC_VEC_TRIG_RD |
+ (KS2_OSR_ECC_CTRL KS2_OSR_ECC_VEC_RD_ADDR_SH);
+
+ writel(val , base + KS2_OSR_ECC_VEC);
+
+ /**
+* wait till read is done.
+* Print should be added after earlyprintk support is added.
+*/
+ for (j = 0; j 1; j++) {
+ val = readl(base + KS2_OSR_ECC_VEC);
+ if (val KS2_OSR_ECC_VEC_RD_DONE)
+ break;
+ }
+
+ ecc_ctrl[i] = readl(base + KS2_OSR_ECC_CTRL) ^
+ KS2_OSR_ECC_CTRL_CHK;
+
+ writel(ecc_ctrl[i], KS2_MSMC_DATA_BASE + i * 4);
+ writel(ecc_ctrl[i], base + KS2_OSR_ECC_CTRL);
+ }
+
+ /* Reset OSR memory to all zeros */
+ for (i = 0; i KS2_OSR_SIZE; i += 4)
+ writel(0, KS2_OSR_DATA_BASE + i);
+
+ /* Enable OSR ECC check for all the ram banks */
+ for (i = 0; i KS2_OSR_NUM_RAM_BANKS; i++)
+ writel(ecc_ctrl[i] |
+ KS2_OSR_ECC_CTRL_CHK, base + KS2_OSR_ECC_CTRL);
+}
+#endif
+
int arch_cpu_init(void)
{
chip_configuration_unlock();
@@ -34,6 +82,7 @@ int arch_cpu_init(void)
#endif
#ifdef CONFIG_SOC_K2L
msmc_share_all_segments(14); /* PCIE 1 */
+ osr_init();
#endif
/*
diff --git a/arch/arm/include/asm/arch-keystone/hardware-k2l.h
b/arch/arm/include/asm/arch-keystone/hardware-k2l.h
index 3402d0c..dfde040 100644
--- a/arch/arm/include/asm/arch-keystone/hardware-k2l.h
+++ b/arch/arm/include/asm/arch-keystone/hardware-k2l.h
@@ -57,6 +57,31 @@
#define KS2_CIC2_DDR3_ECC_IRQ_NUM 0x0D3
#define KS2_CIC2_DDR3_ECC_CHAN_NUM 0x01D
+/* OSR */
+#define KS2_OSR_DATA_BASE 0x7000 /* OSR data base */
+#define KS2_OSR_CFG_BASE 0x02348c00 /* OSR config base */
+#define KS2_OSR_ECC_VEC0x08/* ECC Vector
reg */
+#define KS2_OSR_ECC_CTRL 0x14/* ECC control reg */
+
+/* OSR ECC Vector register */
+#define KS2_OSR_ECC_VEC_TRIG_RDBIT(15) /* trigger a
read op */
+#define KS2_OSR_ECC_VEC_RD_DONEBIT(24) /* read
complete */
+
+#define KS2_OSR_ECC_VEC_RAM_ID_SH 0 /* RAM ID shift */
+#define KS2_OSR_ECC_VEC_RD_ADDR_SH 16 /* read address shift */
+
+/* OSR ECC control register */
+#define KS2_OSR_ECC_CTRL_ENBIT(0) /* ECC enable bit */
+#define KS2_OSR_ECC_CTRL_CHK BIT(1) /* ECC check bit */
+#define KS2_OSR_ECC_CTRL_RMW BIT(2) /* ECC check bit */
+
+/* Number of OSR RAM banks */
+#define KS2_OSR_NUM_RAM_BANKS 4
+
+/* OSR memory size */
+#define KS2_OSR_SIZE 0x10
+
+
/* Number of DSP cores */
#define KS2_NUM_DSPS 4
diff --git a/arch/arm/include/asm/arch-keystone/hardware.h
b/arch/arm/include/asm/arch-keystone/hardware.h
index adae69e..29f7bf1 100644
--- a/arch/arm/include/asm/arch-keystone/hardware.h
+++ b/arch/arm/include/asm/arch-keystone/hardware.h
@@ -163,6 +163,7 @@ typedef volatile unsigned int *dv_reg_p;
/* MSMC control */
#define KS2_MSMC_CTRL_BASE 0x0bc0
+#define KS2_MSMC_DATA_BASE 0x0c00
/* USB */
#define KS2_USB_SS_BASE0x0268
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch v4 3/6] keystone2: msmc: add MSMC cache coherency support for K2L SOC
From: Hao Zhang hzh...@ti.com This patch adds Keystone II Lamar (K2L) SoC specific definitions to support MSMC cache coherency. Acked-by: Vitaly Andrianov vita...@ti.com Signed-off-by: Hao Zhang hzh...@ti.com Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com --- arch/arm/cpu/armv7/keystone/init.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/cpu/armv7/keystone/init.c b/arch/arm/cpu/armv7/keystone/init.c index a8f8aee..a0ecfa2 100644 --- a/arch/arm/cpu/armv7/keystone/init.c +++ b/arch/arm/cpu/armv7/keystone/init.c @@ -32,6 +32,9 @@ int arch_cpu_init(void) #ifdef CONFIG_SOC_K2E msmc_share_all_segments(13); /* PCIE 1 */ #endif +#ifdef CONFIG_SOC_K2L + msmc_share_all_segments(14); /* PCIE 1 */ +#endif /* * just initialise the COM2 port so that TI specific -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch v4 2/6] keystone2: clock: add K2L clock definitions and commands
From: Hao Zhang hzh...@ti.com
This patch adds clock definitions and commands to support Keystone II
K2L SOC.
Acked-by: Vitaly Andrianov vita...@ti.com
Signed-off-by: Hao Zhang hzh...@ti.com
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
arch/arm/cpu/armv7/keystone/Makefile | 1 +
arch/arm/cpu/armv7/keystone/clock-k2l.c| 138 +
arch/arm/cpu/armv7/keystone/cmd_clock.c| 10 ++
arch/arm/include/asm/arch-keystone/clock-k2l.h | 88
arch/arm/include/asm/arch-keystone/clock.h | 4 +
5 files changed, 241 insertions(+)
create mode 100644 arch/arm/cpu/armv7/keystone/clock-k2l.c
create mode 100644 arch/arm/include/asm/arch-keystone/clock-k2l.h
diff --git a/arch/arm/cpu/armv7/keystone/Makefile
b/arch/arm/cpu/armv7/keystone/Makefile
index 3d8fb70..4750371 100644
--- a/arch/arm/cpu/armv7/keystone/Makefile
+++ b/arch/arm/cpu/armv7/keystone/Makefile
@@ -10,6 +10,7 @@ obj-y += psc.o
obj-y += clock.o
obj-$(CONFIG_SOC_K2HK) += clock-k2hk.o
obj-$(CONFIG_SOC_K2E) += clock-k2e.o
+obj-$(CONFIG_SOC_K2L) += clock-k2l.o
obj-y += cmd_clock.o
obj-y += cmd_mon.o
obj-y += msmc.o
diff --git a/arch/arm/cpu/armv7/keystone/clock-k2l.c
b/arch/arm/cpu/armv7/keystone/clock-k2l.c
new file mode 100644
index 000..1c5e4d5
--- /dev/null
+++ b/arch/arm/cpu/armv7/keystone/clock-k2l.c
@@ -0,0 +1,138 @@
+/*
+ * Keystone2: get clk rate for K2L
+ *
+ * (C) Copyright 2012-2014
+ * Texas Instruments Incorporated, www.ti.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include asm/arch/clock.h
+#include asm/arch/clock_defs.h
+
+const struct keystone_pll_regs keystone_pll_regs[] = {
+ [CORE_PLL] = {KS2_MAINPLLCTL0, KS2_MAINPLLCTL1},
+ [PASS_PLL] = {KS2_PASSPLLCTL0, KS2_PASSPLLCTL1},
+ [TETRIS_PLL] = {KS2_ARMPLLCTL0, KS2_ARMPLLCTL1},
+ [DDR3_PLL] = {KS2_DDR3APLLCTL0, KS2_DDR3APLLCTL1},
+};
+
+int dev_speeds[] = {
+ SPD800,
+ SPD1000,
+ SPD1200,
+ SPD800,
+ SPD800,
+ SPD800,
+ SPD800,
+ SPD800,
+ SPD1200,
+ SPD1000,
+ SPD800,
+ SPD800,
+ SPD800,
+};
+
+int arm_speeds[] = {
+ SPD800,
+ SPD1000,
+ SPD1200,
+ SPD1350,
+ SPD1400,
+ SPD800,
+ SPD1400,
+ SPD1350,
+ SPD1200,
+ SPD1000,
+ SPD800,
+ SPD800,
+ SPD800,
+};
+
+/**
+ * pll_freq_get - get pll frequency
+ * Fout = Fref * NF(mult) / NR(prediv) / OD
+ * @pll: pll identifier
+ */
+static unsigned long pll_freq_get(int pll)
+{
+ unsigned long mult = 1, prediv = 1, output_div = 2;
+ unsigned long ret;
+ u32 tmp, reg;
+
+ if (pll == CORE_PLL) {
+ ret = external_clk[sys_clk];
+ if (pllctl_reg_read(pll, ctl) PLLCTL_PLLEN) {
+ /* PLL mode */
+ tmp = __raw_readl(KS2_MAINPLLCTL0);
+ prediv = (tmp PLL_DIV_MASK) + 1;
+ mult = (((tmp PLLM_MULT_HI_SMASK) 6) |
+ (pllctl_reg_read(pll, mult)
+ PLLM_MULT_LO_MASK)) + 1;
+ output_div = ((pllctl_reg_read(pll, secctl)
+ PLL_CLKOD_SHIFT) PLL_CLKOD_MASK) + 1;
+
+ ret = ret / prediv / output_div * mult;
+ }
+ } else {
+ switch (pll) {
+ case PASS_PLL:
+ ret = external_clk[pa_clk];
+ reg = KS2_PASSPLLCTL0;
+ break;
+ case TETRIS_PLL:
+ ret = external_clk[tetris_clk];
+ reg = KS2_ARMPLLCTL0;
+ break;
+ case DDR3_PLL:
+ ret = external_clk[ddr3_clk];
+ reg = KS2_DDR3APLLCTL0;
+ break;
+ default:
+ return 0;
+ }
+
+ tmp = __raw_readl(reg);
+ if (!(tmp PLLCTL_BYPASS)) {
+ /* Bypass disabled */
+ prediv = (tmp PLL_DIV_MASK) + 1;
+ mult = ((tmp PLL_MULT_SHIFT) PLL_MULT_MASK) + 1;
+ output_div = ((tmp PLL_CLKOD_SHIFT)
+ PLL_CLKOD_MASK) + 1;
+ ret = ((ret / prediv) * mult) / output_div;
+ }
+ }
+
+ return ret;
+}
+
+unsigned long clk_get_rate(unsigned int clk)
+{
+ switch (clk) {
+ case core_pll_clk: return pll_freq_get(CORE_PLL);
+ case pass_pll_clk: return pll_freq_get(PASS_PLL);
+ case tetris_pll_clk:return pll_freq_get(TETRIS_PLL);
+ case ddr3_pll_clk: return pll_freq_get(DDR3_PLL);
+ case sys_clk0_1_clk:
+ case sys_clk0_clk: return pll_freq_get(CORE_PLL) / pll0div_read(1);
+ case
[U-Boot] [U-boot] [Patch v4 6/6] keystone2: k2l-evm: add board support
From: Hao Zhang hzh...@ti.com
This patch adds Keystone II Lammar (K2L) EVM board support.
Acked-by: Vitaly Andrianov vita...@ti.com
Signed-off-by: Hao Zhang hzh...@ti.com
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
arch/arm/cpu/armv7/keystone/Kconfig| 3 ++
arch/arm/include/asm/arch-keystone/clock-k2l.h | 6 +++
board/ti/ks2_evm/Kconfig | 16 +++
board/ti/ks2_evm/MAINTAINERS | 2 +
board/ti/ks2_evm/Makefile | 2 +
board/ti/ks2_evm/board_k2l.c | 60 ++
board/ti/ks2_evm/ddr3_cfg.c| 36
board/ti/ks2_evm/ddr3_cfg.h| 3 ++
board/ti/ks2_evm/ddr3_k2l.c| 43 ++
configs/k2l_evm_defconfig | 4 ++
include/configs/k2l_evm.h | 37
11 files changed, 212 insertions(+)
create mode 100644 board/ti/ks2_evm/board_k2l.c
create mode 100644 board/ti/ks2_evm/ddr3_k2l.c
create mode 100644 configs/k2l_evm_defconfig
create mode 100644 include/configs/k2l_evm.h
diff --git a/arch/arm/cpu/armv7/keystone/Kconfig
b/arch/arm/cpu/armv7/keystone/Kconfig
index 24d0cbe..91211fd 100644
--- a/arch/arm/cpu/armv7/keystone/Kconfig
+++ b/arch/arm/cpu/armv7/keystone/Kconfig
@@ -9,6 +9,9 @@ config TARGET_K2HK_EVM
config TARGET_K2E_EVM
bool TI Keystone 2 Edison EVM
+config TARGET_K2L_EVM
+ bool TI Keystone 2 Lamar EVM
+
endchoice
config SYS_CPU
diff --git a/arch/arm/include/asm/arch-keystone/clock-k2l.h
b/arch/arm/include/asm/arch-keystone/clock-k2l.h
index 8cacee0..b3f4e71 100644
--- a/arch/arm/include/asm/arch-keystone/clock-k2l.h
+++ b/arch/arm/include/asm/arch-keystone/clock-k2l.h
@@ -69,7 +69,9 @@ enum {
#define CORE_PLL_799 {CORE_PLL, 13, 1, 2}
#define CORE_PLL_983 {CORE_PLL, 16, 1, 2}
+#define CORE_PLL_1000 {CORE_PLL, 114, 7, 2}
#define CORE_PLL_1167 {CORE_PLL, 19, 1, 2}
+#define CORE_PLL_1198 {CORE_PLL, 39, 2, 2}
#define CORE_PLL_1228 {CORE_PLL, 20, 1, 2}
#define PASS_PLL_1228 {PASS_PLL, 20, 1, 2}
#define PASS_PLL_983 {PASS_PLL, 16, 1, 2}
@@ -78,8 +80,12 @@ enum {
#define TETRIS_PLL_737 {TETRIS_PLL, 12, 1, 2}
#define TETRIS_PLL_799 {TETRIS_PLL, 13, 1, 2}
#define TETRIS_PLL_983 {TETRIS_PLL, 16, 1, 2}
+#define TETRIS_PLL_1000{TETRIS_PLL, 114, 7, 2}
#define TETRIS_PLL_1167{TETRIS_PLL, 19, 1, 2}
+#define TETRIS_PLL_1198{TETRIS_PLL, 39, 2, 2}
#define TETRIS_PLL_1228{TETRIS_PLL, 20, 1, 2}
+#define TETRIS_PLL_1352{TETRIS_PLL, 22, 1, 2}
+#define TETRIS_PLL_1401{TETRIS_PLL, 114, 5, 2}
#define DDR3_PLL_200 {DDR3_PLL, 4, 1, 2}
#define DDR3_PLL_400 {DDR3_PLL, 16, 1, 4}
#define DDR3_PLL_800 {DDR3_PLL, 16, 1, 2}
diff --git a/board/ti/ks2_evm/Kconfig b/board/ti/ks2_evm/Kconfig
index 3108782..36c31ff 100644
--- a/board/ti/ks2_evm/Kconfig
+++ b/board/ti/ks2_evm/Kconfig
@@ -29,3 +29,19 @@ config SYS_CONFIG_NAME
default k2hk_evm
endif
+
+if TARGET_K2L_EVM
+
+config SYS_BOARD
+ string
+ default ks2_evm
+
+config SYS_VENDOR
+ string
+ default ti
+
+config SYS_CONFIG_NAME
+ string
+ default k2l_evm
+
+endif
diff --git a/board/ti/ks2_evm/MAINTAINERS b/board/ti/ks2_evm/MAINTAINERS
index 595a80a..87c36c9 100644
--- a/board/ti/ks2_evm/MAINTAINERS
+++ b/board/ti/ks2_evm/MAINTAINERS
@@ -6,3 +6,5 @@ F: include/configs/k2hk_evm.h
F: configs/k2hk_evm_defconfig
F: include/configs/k2e_evm.h
F: configs/k2e_evm_defconfig
+F: include/configs/k2l_evm.h
+F: configs/k2l_evm_defconfig
diff --git a/board/ti/ks2_evm/Makefile b/board/ti/ks2_evm/Makefile
index 00f1164..071dbee 100644
--- a/board/ti/ks2_evm/Makefile
+++ b/board/ti/ks2_evm/Makefile
@@ -11,3 +11,5 @@ obj-$(CONFIG_K2HK_EVM) += board_k2hk.o
obj-$(CONFIG_K2HK_EVM) += ddr3_k2hk.o
obj-$(CONFIG_K2E_EVM) += board_k2e.o
obj-$(CONFIG_K2E_EVM) += ddr3_k2e.o
+obj-$(CONFIG_K2L_EVM) += board_k2l.o
+obj-$(CONFIG_K2L_EVM) += ddr3_k2l.o
diff --git a/board/ti/ks2_evm/board_k2l.c b/board/ti/ks2_evm/board_k2l.c
new file mode 100644
index 000..b8faff6
--- /dev/null
+++ b/board/ti/ks2_evm/board_k2l.c
@@ -0,0 +1,60 @@
+/*
+ * K2L EVM : Board initialization
+ *
+ * (C) Copyright 2014
+ * Texas Instruments Incorporated, www.ti.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include asm/arch/ddr3.h
+#include asm/arch/hardware.h
+#include asm/ti-common/ti-aemif.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+unsigned int external_clk[ext_clk_count] = {
+ [sys_clk] = 12288,
+ [alt_core_clk] = 1,
+ [pa_clk]= 12288,
+ [tetris_clk]= 12288,
+ [ddr3_clk] = 1,
+ [pcie_clk] = 1,
+ [sgmii_clk] = 15625,
+ [usb_clk] = 1,
+};
+
+static struct pll_init_data core_pll_config[] = {
+ CORE_PLL_799,
+ CORE_PLL_1000,
+
[U-Boot] [PATCH v3] powerpc/mpc85xx: modify erratum A007186
T2080 v1.0 has this errata while v1.1 has fixed
this errata by hardware, add a new function has_errata_a007186
to check the SVR_SOC_VER, SVR_MAJ and SVR_MIN first,
if the sil has errata a007186, then run the errata code,
if not, doesn't run the code.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
Changes for v2:
- use has_errata_a007186 instead of not_has_errata_a007186
Changes for v3:
- use if (has_erratum_a007186() sel == 0x01 || sel == 0x02) {
- instead of if (has_erratum_a007186()) {
if(sel == 0x01 || sel == 0x02)
arch/powerpc/cpu/mpc85xx/cmd_errata.c | 3 ++-
arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c | 3 ++-
arch/powerpc/include/asm/fsl_errata.h | 22 ++
3 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index 3a04a89..0774461 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -270,7 +270,8 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
puts(Work-around for Erratum USB14 enabled\n);
#endif
#ifdef CONFIG_SYS_FSL_ERRATUM_A007186
- puts(Work-around for Erratum A007186 enabled\n);
+ if (has_erratum_a007186())
+ puts(Work-around for Erratum A007186 enabled\n);
#endif
#ifdef CONFIG_SYS_FSL_ERRATUM_A006593
puts(Work-around for Erratum A006593 enabled\n);
diff --git a/arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c
b/arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c
index d1fc76a..b8ee6e0 100644
--- a/arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c
+++ b/arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c
@@ -11,6 +11,7 @@
#include asm/processor.h
#include asm/fsl_law.h
#include asm/errno.h
+#include asm/fsl_errata.h
#include fsl_corenet2_serdes.h
#ifdef CONFIG_SYS_FSL_SRDS_1
@@ -208,7 +209,7 @@ u64 serdes_init(u32 sd, u32 sd_addr, u32 sd_prctl_mask, u32
sd_prctl_shift)
sel = (sfp_spfr0 FUSE_VAL_SHIFT) FUSE_VAL_MASK;
- if (sel == 0x01 || sel == 0x02) {
+ if (has_erratum_a007186() sel == 0x01 || sel == 0x02) {
for (pll_num = 0; pll_num SRDS_MAX_BANK; pll_num++) {
pll_status = in_be32(srds_regs-bank[pll_num].pllcr0);
debug(A007186: pll_num=%x pllcr0=%x\n,
diff --git a/arch/powerpc/include/asm/fsl_errata.h
b/arch/powerpc/include/asm/fsl_errata.h
index 64da4bb..655072b 100644
--- a/arch/powerpc/include/asm/fsl_errata.h
+++ b/arch/powerpc/include/asm/fsl_errata.h
@@ -82,3 +82,25 @@ static inline bool has_erratum_a007075(void)
return false;
}
#endif
+
+#ifdef CONFIG_SYS_FSL_ERRATUM_A007186
+static inline bool has_erratum_a007186(void)
+{
+ u32 svr = get_svr();
+ u32 soc = SVR_SOC_VER(svr);
+
+ switch (soc) {
+ case SVR_T4240:
+ case SVR_T4160:
+ case SVR_T4080:
+ case SVR_B4860:
+ case SVR_B4420:
+ case SVR_T2081:
+ return true;
+ case SVR_T2080:
+ return IS_SVR_REV(svr, 1, 0);
+ }
+
+ return false;
+}
+#endif
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] powerpc/mpc85xx:Put errata number for T104x NAND boot issue
When device is configured to load RCW from NAND flash IFC_A[16:31] are driven
low after RCW loading. Hence Devices connected on IFC_CS[1:7] and using
IFC_A[16:31] lines are not accessible.
Workaround is already in-place.
Put the errata number to adhere errata handling framework.
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
README| 4
arch/powerpc/cpu/mpc85xx/cmd_errata.c | 4 +++-
arch/powerpc/include/asm/config_mpc85xx.h | 1 +
board/freescale/t104xrdb/spl.c| 4 ++--
include/configs/T104xRDB.h| 10 +-
5 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/README b/README
index 46def00..5ff19c3 100644
--- a/README
+++ b/README
@@ -409,6 +409,10 @@ The following options need to be configured:
Enables a workaround for IFC erratum A003399. It is only
requred during NOR boot.
+ CONFIG_A08044_WORKAROUND
+ Enables a workaround for T1040/T1042 erratum A008044. It is only
+ requred during NAND boot and valid for Rev 1.0 SoC revision
+
CONFIG_SYS_FSL_CORENET_SNOOPVEC_COREONLY
This is the value to write into CCSR offset 0x18600
diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index 3a04a89..82d31ba 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -308,7 +308,9 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
#ifdef CONFIG_SYS_FSL_ERRATUM_A005434
puts(Work-around for Erratum A-005434 enabled\n);
#endif
-
+#if defined(CONFIG_SYS_FSL_ERRATUM_A008044)
defined(CONFIG_A08044_WORKAROUND)
+ puts(Work-around for Erratum A-008044 enabled\n);
+#endif
return 0;
}
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
b/arch/powerpc/include/asm/config_mpc85xx.h
index 712f2ef..5e1e4b2 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -767,6 +767,7 @@ defined(CONFIG_PPC_T1020) || defined(CONFIG_PPC_T1022)
#define CONFIG_SYS_PME_CLK CONFIG_PME_PLAT_CLK_DIV
#define CONFIG_SYS_FSL_DDR_VER FSL_DDR_VER_5_0
#define CONFIG_SYS_FSL_IFC_BANK_COUNT 8
+#define CONFIG_SYS_FSL_ERRATUM_A008044
#define CONFIG_SYS_FMAN_V3
#define CONFIG_FM_PLAT_CLK_DIV 1
#define CONFIG_SYS_FM1_CLK CONFIG_FM_PLAT_CLK_DIV
diff --git a/board/freescale/t104xrdb/spl.c b/board/freescale/t104xrdb/spl.c
index 3822a37..218bda8 100644
--- a/board/freescale/t104xrdb/spl.c
+++ b/board/freescale/t104xrdb/spl.c
@@ -34,12 +34,12 @@ unsigned long get_board_ddr_clk(void)
void board_init_f(ulong bootflag)
{
u32 plat_ratio, sys_clk, uart_clk;
-#ifdef CONFIG_SPL_NAND_BOOT
+#if defined(CONFIG_SPL_NAND_BOOT) defined(CONFIG_A08044_WORKAROUND)
u32 porsr1, pinctl;
#endif
ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
-#ifdef CONFIG_SPL_NAND_BOOT
+#if defined(CONFIG_SPL_NAND_BOOT) defined(CONFIG_A08044_WORKAROUND)
/*
* There is T1040 SoC issue where NOR, FPGA are inaccessible during
* NAND boot because IFC signals IFC_AD7 are not enabled.
diff --git a/include/configs/T104xRDB.h b/include/configs/T104xRDB.h
index 5e2c100..bbfe15a 100644
--- a/include/configs/T104xRDB.h
+++ b/include/configs/T104xRDB.h
@@ -13,6 +13,9 @@
#define CONFIG_T104xRDB
#define CONFIG_PHYS_64BIT
+#define CONFIG_E500/* BOOKE e500 family */
+#include asm/config_mpc85xx.h
+
#ifdef CONFIG_RAMBOOT_PBL
#define CONFIG_SYS_FSL_PBL_PBI
$(SRCTREE)/board/freescale/t104xrdb/t104x_pbi.cfg
#ifdef CONFIG_T1040RDB
@@ -93,7 +96,6 @@
/* High Level Configuration Options */
#define CONFIG_BOOKE
-#define CONFIG_E500/* BOOKE e500 family */
#define CONFIG_E500MC /* BOOKE e500mc family */
#define CONFIG_SYS_BOOK3E_HV /* Category E.HV supported */
#define CONFIG_MP /* support multiple processors */
@@ -385,6 +387,12 @@
#define CONFIG_SYS_RAMBOOT
#endif
+#ifdef CONFIG_SYS_FSL_ERRATUM_A008044
+#if defined(CONFIG_NAND)
+#define CONFIG_A08044_WORKAROUND
+#endif
+#endif
+
#define CONFIG_BOARD_EARLY_INIT_R
#define CONFIG_MISC_INIT_R
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] board/t104xrdb: Conditional workaround of errata A-008044
Workaround of Errata A-008044 was implemented without errata number and it is
enabled by default. Errata A-008044 is only valid for T1040 Rev 1.0.
So put errata number and make it conditional.
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
arch/powerpc/cpu/mpc85xx/cmd_errata.c | 3 ++-
board/freescale/t104xrdb/spl.c| 22 ++
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index 82d31ba..a714617 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -309,7 +309,8 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
puts(Work-around for Erratum A-005434 enabled\n);
#endif
#if defined(CONFIG_SYS_FSL_ERRATUM_A008044)
defined(CONFIG_A08044_WORKAROUND)
- puts(Work-around for Erratum A-008044 enabled\n);
+ if (IS_SVR_REV(svr, 1, 0))
+ puts(Work-around for Erratum A-008044 enabled\n);
#endif
return 0;
}
diff --git a/board/freescale/t104xrdb/spl.c b/board/freescale/t104xrdb/spl.c
index 218bda8..255831e 100644
--- a/board/freescale/t104xrdb/spl.c
+++ b/board/freescale/t104xrdb/spl.c
@@ -36,18 +36,24 @@ void board_init_f(ulong bootflag)
u32 plat_ratio, sys_clk, uart_clk;
#if defined(CONFIG_SPL_NAND_BOOT) defined(CONFIG_A08044_WORKAROUND)
u32 porsr1, pinctl;
+ u32 svr = get_svr();
#endif
ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
#if defined(CONFIG_SPL_NAND_BOOT) defined(CONFIG_A08044_WORKAROUND)
- /*
-* There is T1040 SoC issue where NOR, FPGA are inaccessible during
-* NAND boot because IFC signals IFC_AD7 are not enabled.
-* This workaround changes RCW source to make all signals enabled.
-*/
- porsr1 = in_be32(gur-porsr1);
- pinctl = ((porsr1 ~(FSL_CORENET_CCSR_PORSR1_RCW_MASK)) | 0x2480);
- out_be32((unsigned int *)(CONFIG_SYS_DCSRBAR + 0x2), pinctl);
+ if (IS_SVR_REV(svr, 1, 0)) {
+ /*
+* There is T1040 SoC issue where NOR, FPGA are inaccessible
+* during NAND boot because IFC signals IFC_AD7 are not
+* enabled. This workaround changes RCW source to make all
+* signals enabled.
+*/
+ porsr1 = in_be32(gur-porsr1);
+ pinctl = ((porsr1 ~(FSL_CORENET_CCSR_PORSR1_RCW_MASK))
+ | 0x2480);
+ out_be32((unsigned int *)(CONFIG_SYS_DCSRBAR + 0x2),
+pinctl);
+ }
#endif
/* Memcpy existing GD at CONFIG_SPL_GD_ADDR */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] powerpc/mpc85xx: modify erratum A007186
T2080 v1.0 has this errata while v1.1 has fixed
this errata by hardware, add a new function has_errata_a007186
to check the SVR_SOC_VER, SVR_MAJ and SVR_MIN first,
if the sil has errata a007186, then run the errata code,
if not, doesn't run the code.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
Changes for v2:
- use has_errata_a007186 instead of not_has_errata_a007186
Changes for v3:
- use if (has_erratum_a007186() sel == 0x01 || sel == 0x02) {
- instead of if (has_erratum_a007186()) {
if(sel == 0x01 || sel == 0x02)
arch/powerpc/cpu/mpc85xx/cmd_errata.c | 3 ++-
arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c | 3 ++-
arch/powerpc/include/asm/fsl_errata.h | 22 ++
3 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index 3a04a89..0774461 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -270,7 +270,8 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
puts(Work-around for Erratum USB14 enabled\n);
#endif
#ifdef CONFIG_SYS_FSL_ERRATUM_A007186
- puts(Work-around for Erratum A007186 enabled\n);
+ if (has_erratum_a007186())
+ puts(Work-around for Erratum A007186 enabled\n);
#endif
#ifdef CONFIG_SYS_FSL_ERRATUM_A006593
puts(Work-around for Erratum A006593 enabled\n);
diff --git a/arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c
b/arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c
index d1fc76a..f3aa53a 100644
--- a/arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c
+++ b/arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c
@@ -11,6 +11,7 @@
#include asm/processor.h
#include asm/fsl_law.h
#include asm/errno.h
+#include asm/fsl_errata.h
#include fsl_corenet2_serdes.h
#ifdef CONFIG_SYS_FSL_SRDS_1
@@ -208,7 +209,7 @@ u64 serdes_init(u32 sd, u32 sd_addr, u32 sd_prctl_mask, u32
sd_prctl_shift)
sel = (sfp_spfr0 FUSE_VAL_SHIFT) FUSE_VAL_MASK;
- if (sel == 0x01 || sel == 0x02) {
+ if (has_erratum_a007186() (sel == 0x01 || sel == 0x02)) {
for (pll_num = 0; pll_num SRDS_MAX_BANK; pll_num++) {
pll_status = in_be32(srds_regs-bank[pll_num].pllcr0);
debug(A007186: pll_num=%x pllcr0=%x\n,
diff --git a/arch/powerpc/include/asm/fsl_errata.h
b/arch/powerpc/include/asm/fsl_errata.h
index 64da4bb..655072b 100644
--- a/arch/powerpc/include/asm/fsl_errata.h
+++ b/arch/powerpc/include/asm/fsl_errata.h
@@ -82,3 +82,25 @@ static inline bool has_erratum_a007075(void)
return false;
}
#endif
+
+#ifdef CONFIG_SYS_FSL_ERRATUM_A007186
+static inline bool has_erratum_a007186(void)
+{
+ u32 svr = get_svr();
+ u32 soc = SVR_SOC_VER(svr);
+
+ switch (soc) {
+ case SVR_T4240:
+ case SVR_T4160:
+ case SVR_T4080:
+ case SVR_B4860:
+ case SVR_B4420:
+ case SVR_T2081:
+ return true;
+ case SVR_T2080:
+ return IS_SVR_REV(svr, 1, 0);
+ }
+
+ return false;
+}
+#endif
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
Hi Marek, On 10/15/2014 12:38 AM, Marek Vasut wrote: On Sunday, October 12, 2014 at 08:33:21 AM, Sean Cross wrote: On 12/10/2014 05:04, Fabio Estevam wrote: On Sat, Oct 11, 2014 at 11:21 AM, Sean Cross x...@kosagi.com wrote: Ok, understood. Just curious: which Ethernet PHY is used on the novena board? It's the same Micrel PHY used on the Sabrelite, the KSZ9021. nitrogen/sabrelite holds Ethernet PHY reset low for 10ms, which is in accordance with ksz9021 datasheet. Shouldn't we wait 10ms here as well? The reference manual for the PHY indicates that you should hold reset low for 10ms after the supply voltage stabilizes. So long as it takes at least 10msto get from the point at which the CPU starts executing its ROM code to the point at which the reset line is toggled, we will be fine. This definitelly is the case, so I presume we don't need the delay ? Well, here's how I see the case. After power on, the PHY unfortunately is out of reset (R20G is DNP, imx6 pin pulled high internally after reset). At some unknown point in time the CPU reaches novena_spl_setup_iomux_enet(). During all this time the PHY is still out of reset. Neither this complies with the recommended sequence, and even more doesn't comply if we remove the delay. If we leave the delay as it is currently implemented, the actual reset sequence is just delayed (by the time it takes the CPU to reach the PHY reset code). At this later point we enforce the proper reset sequence: supply rail is obviously now stable, and we keep the PHY reset low for the minimum specified time: 10ms. My understanding is that this is simple and efficient way to guarantee that for all different cases (different temperatures, different CPU silicon revisions, differently configured drivers/subsystems), the PHY reset timing is generated properly, and will be generated properly in the future when the code evolves. Please tell me if I'm missing something. Kind regards, Nikolay ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
