[U-Boot] [PATCH 3/3] imx: mx6ul_evk: convert to use Driver model for power and i2c

[Peng Fan]

Convert to use DM_PMIC/DM_REGULATOR/DM_I2C for mx6ul evk.
To mx6ul_14x14_evk, there is no pmic on board, so only enable DM_I2C.

Since we have PINCTRL driver and DM_I2C enabled, we could discard
the pinmux setting in board file, but we can not do this, because
still some dependency in arch/arm/imx-common/i2c-mxv7.c. Later
we may need to find out a way to refine this.

To avoid SPL build warning, disable i2c-mxc driver for SPL part.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
Cc: Fabio Estevam 
---
 board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c | 38 +--
 configs/mx6ul_14x14_evk_defconfig |  1 +
 configs/mx6ul_9x9_evk_defconfig   |  8 +
 include/configs/mx6ul_14x14_evk.h | 11 ++-
 4 files changed, 25 insertions(+), 33 deletions(-)

diff --git a/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c 
b/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c
index 98d5675..62a3e68 100644
--- a/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c
+++ b/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c
@@ -174,45 +174,35 @@ static struct i2c_pads_info i2c_pad_info1 = {
},
 };
 
-#ifdef CONFIG_POWER
-#define I2C_PMIC   0
+#ifdef CONFIG_DM_PMIC
 int power_init_board(void)
 {
if (is_mx6ul_9x9_evk()) {
-   struct pmic *pfuze;
-   int ret;
-   unsigned int reg, rev_id;
+   struct udevice *dev;
+   int ret, dev_id, rev_id;
 
-   ret = power_pfuze3000_init(I2C_PMIC);
-   if (ret)
+   ret = pmic_get("pfuze3000", );
+   if (ret == -ENODEV)
+   return 0;
+   else if (ret != 0)
return ret;
 
-   pfuze = pmic_get("PFUZE3000");
-   ret = pmic_probe(pfuze);
-   if (ret)
-   return ret;
-
-   pmic_reg_read(pfuze, PFUZE3000_DEVICEID, );
-   pmic_reg_read(pfuze, PFUZE3000_REVID, _id);
+   dev_id = pmic_reg_read(dev, PFUZE3000_DEVICEID);
+   rev_id = pmic_reg_read(dev, PFUZE3000_REVID);
printf("PMIC: PFUZE3000 DEV_ID=0x%x REV_ID=0x%x\n",
-  reg, rev_id);
+  dev_id, rev_id);
 
/* disable Low Power Mode during standby mode */
-   pmic_reg_read(pfuze, PFUZE3000_LDOGCTL, );
-   reg |= 0x1;
-   pmic_reg_write(pfuze, PFUZE3000_LDOGCTL, reg);
+   pmic_clrsetbits(dev, PFUZE3000_LDOGCTL, 0, 1);
 
/* SW1B step ramp up time from 2us to 4us/25mV */
-   reg = 0x40;
-   pmic_reg_write(pfuze, PFUZE3000_SW1BCONF, reg);
+   pmic_reg_write(dev, PFUZE3000_SW1BCONF, 0x40);
 
/* SW1B mode to APS/PFM */
-   reg = 0xc;
-   pmic_reg_write(pfuze, PFUZE3000_SW1BMODE, reg);
+   pmic_reg_write(dev, PFUZE3000_SW1BMODE, 0xc);
 
/* SW1B standby voltage set to 0.975V */
-   reg = 0xb;
-   pmic_reg_write(pfuze, PFUZE3000_SW1BSTBY, reg);
+   pmic_reg_write(dev, PFUZE3000_SW1BSTBY, 0xb);
}
 
return 0;
diff --git a/configs/mx6ul_14x14_evk_defconfig 
b/configs/mx6ul_14x14_evk_defconfig
index a756de7..b67e0cb 100644
--- a/configs/mx6ul_14x14_evk_defconfig
+++ b/configs/mx6ul_14x14_evk_defconfig
@@ -4,6 +4,7 @@ CONFIG_CMD_DHCP=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_PING=y
 CONFIG_DEFAULT_DEVICE_TREE="imx6ul-14x14-evk"
+CONFIG_DM_I2C=y
 CONFIG_OF_CONTROL=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_FULL=y
diff --git a/configs/mx6ul_9x9_evk_defconfig b/configs/mx6ul_9x9_evk_defconfig
index fed0254..cebfbdd 100644
--- a/configs/mx6ul_9x9_evk_defconfig
+++ b/configs/mx6ul_9x9_evk_defconfig
@@ -3,7 +3,15 @@ CONFIG_ARM=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_PING=y
+CONFIG_CMD_PMIC=y
+CONFIG_CMD_REGULATOR=y
 CONFIG_DEFAULT_DEVICE_TREE="imx6ul-9x9-evk"
+CONFIG_DM_I2C=y
+CONFIG_DM_PMIC=y
+CONFIG_DM_PMIC_PFUZE100=y
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_PFUZE100=y
+CONFIG_ERRNO_STR=y
 CONFIG_OF_CONTROL=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_FULL=y
diff --git a/include/configs/mx6ul_14x14_evk.h 
b/include/configs/mx6ul_14x14_evk.h
index c7e10f9..8a27b26 100644
--- a/include/configs/mx6ul_14x14_evk.h
+++ b/include/configs/mx6ul_14x14_evk.h
@@ -50,19 +50,12 @@
 #endif
 
 /* I2C configs */
+#ifndef CONFIG_SPL
 #define CONFIG_CMD_I2C
 #ifdef CONFIG_CMD_I2C
-#define CONFIG_SYS_I2C
 #define CONFIG_SYS_I2C_MXC
-#define CONFIG_SYS_I2C_MXC_I2C1/* enable I2C bus 1 */
-#define CONFIG_SYS_I2C_MXC_I2C2/* enable I2C bus 2 */
 #define CONFIG_SYS_I2C_SPEED   10
-
-/* PMIC only for 9X9 EVK */
-#define CONFIG_POWER
-#define CONFIG_POWER_I2C
-#define CONFIG_POWER_PFUZE3000
-#define CONFIG_POWER_PFUZE3000_I2C_ADDR  0x08
+#endif
 #endif
 
 #define 

[U-Boot] [PATCH 2/3] imx: mx6ul_evk: default enable device tree support

[Peng Fan]

Default enable device tree for mx6ul_14x14_evk and
mx6ul_9x9_evk board. And sort the defconfig file to be in
alphabet order.

Enable pinctrl driver for the two boards.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
Cc: Fabio Estevam 
---
 configs/mx6ul_14x14_evk_defconfig | 15 ++-
 configs/mx6ul_9x9_evk_defconfig   | 15 ++-
 2 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/configs/mx6ul_14x14_evk_defconfig 
b/configs/mx6ul_14x14_evk_defconfig
index 835285f..a756de7 100644
--- a/configs/mx6ul_14x14_evk_defconfig
+++ b/configs/mx6ul_14x14_evk_defconfig
@@ -1,8 +1,13 @@
-CONFIG_ARM=y
 CONFIG_ARCH_MX6=y
-CONFIG_TARGET_MX6UL_14X14_EVK=y
-CONFIG_SPL=y
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg"
-CONFIG_CMD_GPIO=y
+CONFIG_ARM=y
 CONFIG_CMD_DHCP=y
+CONFIG_CMD_GPIO=y
 CONFIG_CMD_PING=y
+CONFIG_DEFAULT_DEVICE_TREE="imx6ul-14x14-evk"
+CONFIG_OF_CONTROL=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_FULL=y
+CONFIG_PINCTRL_IMX6=y
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg"
+CONFIG_TARGET_MX6UL_14X14_EVK=y
diff --git a/configs/mx6ul_9x9_evk_defconfig b/configs/mx6ul_9x9_evk_defconfig
index efbffe3..fed0254 100644
--- a/configs/mx6ul_9x9_evk_defconfig
+++ b/configs/mx6ul_9x9_evk_defconfig
@@ -1,8 +1,13 @@
-CONFIG_ARM=y
 CONFIG_ARCH_MX6=y
-CONFIG_TARGET_MX6UL_9X9_EVK=y
-CONFIG_SPL=y
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg"
-CONFIG_CMD_GPIO=y
+CONFIG_ARM=y
 CONFIG_CMD_DHCP=y
+CONFIG_CMD_GPIO=y
 CONFIG_CMD_PING=y
+CONFIG_DEFAULT_DEVICE_TREE="imx6ul-9x9-evk"
+CONFIG_OF_CONTROL=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_FULL=y
+CONFIG_PINCTRL_IMX6=y
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg"
+CONFIG_TARGET_MX6UL_9X9_EVK=y
-- 
2.6.2

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

[U-Boot] [PATCH 0/3] imx6ul: convert to enable pinctrl/DM POWER

[Peng Fan]

This patch set is to covert to enable pinctrl driver and
DM_PMIC and DM_REGULATOR for imx6ul 14x14/9x9 evk board.

This patch set is only to add device tree for i.MX6UL and
is just initial step to convert to support device tree for
i.MX6/7, I just have an idea to discard the pinmux settings
in board file and let pinctrl driver to handle these for
different drivers.

I am not very sure whether we need a full device tree here,
since we do not support so many devices as linux kernel.

Any comments on this? There maybe some work need to be done
to support this.

To the i2c part, the pinmux settings are still needed in
board file, because there are some dependency in
arch/arm/imx-common/i2c-mxv7.c. In future, we may need
to refine this to totally let i2c driver handle this.

Peng Fan (3):
  imx: imx6ul: Introduce device tree files
  imx: mx6ul_evk: default enable device tree support
  imx: mx6ul_evk: convert to use Driver model for power and i2c

 arch/arm/dts/Makefile |4 +
 arch/arm/dts/imx6ul-14x14-evk.dts |  693 
 arch/arm/dts/imx6ul-9x9-evk.dts   |  790 ++
 arch/arm/dts/imx6ul-pinfunc.h |  938 +
 arch/arm/dts/imx6ul.dtsi  | 1158 +
 board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c |   38 +-
 configs/mx6ul_14x14_evk_defconfig |   16 +-
 configs/mx6ul_9x9_evk_defconfig   |   23 +-
 include/configs/mx6ul_14x14_evk.h |   11 +-
 include/dt-bindings/clock/imx6ul-clock.h  |  240 +
 10 files changed, 3868 insertions(+), 43 deletions(-)
 create mode 100644 arch/arm/dts/imx6ul-14x14-evk.dts
 create mode 100644 arch/arm/dts/imx6ul-9x9-evk.dts
 create mode 100644 arch/arm/dts/imx6ul-pinfunc.h
 create mode 100644 arch/arm/dts/imx6ul.dtsi
 create mode 100644 include/dt-bindings/clock/imx6ul-clock.h

-- 
2.6.2

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

[U-Boot] [PATCH v2 2/3] armv8/ls1043aqds: Return i2c mux to default chennel

[Wenbin Song]

Return i2c mux to the default channel after accessing retimer.

Signed-off-by: Wenbin Song 
---
Change for v2:
-Rework the commit message and the subject
---
 board/freescale/ls1043aqds/ls1043aqds.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/board/freescale/ls1043aqds/ls1043aqds.c 
b/board/freescale/ls1043aqds/ls1043aqds.c
index a72fe52..fba6b88 100644
--- a/board/freescale/ls1043aqds/ls1043aqds.c
+++ b/board/freescale/ls1043aqds/ls1043aqds.c
@@ -170,8 +170,7 @@ void board_retimer_init(void)
u8 reg;
 
/* Retimer is connected to I2C1_CH7_CH5 */
-   reg = I2C_MUX_CH7;
-   i2c_write(I2C_MUX_PCA_ADDR_PRI, 0, 1, , 1);
+   select_i2c_ch_pca9547(I2C_MUX_CH7);
reg = I2C_MUX_CH5;
i2c_write(I2C_MUX_PCA_ADDR_SEC, 0, 1, , 1);
 
@@ -219,6 +218,9 @@ void board_retimer_init(void)
i2c_write(I2C_RETIMER_ADDR, 0x63, 1, , 1);
reg = 0xcd;
i2c_write(I2C_RETIMER_ADDR, 0x64, 1, , 1);
+
+   /* Return the default channel */
+   select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
 }
 
 int board_early_init_f(void)
-- 
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 v2 3/3] armv8/ls1043aqds: Enable ID_EEPROM support for ls1043aqds

[Wenbin Song]

Signed-off-by: Wenbin Song 
---
Changes for v2:
-Rework the subject
---
 include/configs/ls1043aqds.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/configs/ls1043aqds.h b/include/configs/ls1043aqds.h
index 158cf02..e269522 100644
--- a/include/configs/ls1043aqds.h
+++ b/include/configs/ls1043aqds.h
@@ -114,6 +114,16 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_DOS_PARTITION
 #define CONFIG_BOARD_LATE_INIT
 
+
+/* EEPROM */
+#define CONFIG_ID_EEPROM
+#define CONFIG_SYS_I2C_EEPROM_NXID
+#define CONFIG_SYS_EEPROM_BUS_NUM  0
+#define CONFIG_SYS_I2C_EEPROM_ADDR 0x57
+#define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1
+#define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS  3
+#define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS  5
+
 #define CONFIG_SYS_SATAAHCI_BASE_ADDR
 
 #define CONFIG_SYS_SCSI_MAX_SCSI_ID1
-- 
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 v2 1/3] freescale: vid: Return i2c mux to default channel

[Wenbin Song]

IR chip is on one of the channels on multiplexed I2C-bus.
Reset to default channel after accessing.

Signed-off-by: Wenbin Song 
---
Changes for v2:
-Rework the commit message and the tag int the subject.
---
 board/freescale/common/vid.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/board/freescale/common/vid.c b/board/freescale/common/vid.c
index 1bd65a8..a6a132a 100644
--- a/board/freescale/common/vid.c
+++ b/board/freescale/common/vid.c
@@ -454,6 +454,9 @@ int adjust_vdd(ulong vdd_override)
 exit:
if (re_enable)
enable_interrupts();
+
+   i2c_multiplexer_select_vid_channel(I2C_MUX_CH_DEFAULT);
+
return ret;
 }
 
@@ -469,7 +472,7 @@ static int print_vdd(void)
ret = find_ir_chip_on_i2c();
if (ret < 0) {
printf("VID: Could not find voltage regulator on I2C.\n");
-   return -1;
+   goto exit;
} else {
i2caddress = ret;
debug("VID: IR Chip found on I2C address 0x%02x\n", i2caddress);
@@ -481,11 +484,14 @@ static int print_vdd(void)
vdd_last = read_voltage(i2caddress);
if (vdd_last < 0) {
printf("VID: Couldn't read sensor abort VID adjustment\n");
-   return -1;
+   goto exit;
}
printf("VID: Core voltage is at %d mV\n", vdd_last);
+exit:
+   i2c_multiplexer_select_vid_channel(I2C_MUX_CH_DEFAULT);
+
+   return ret < 0 ? -1 : 0;
 
-   return 0;
 }
 
 static int do_vdd_override(cmd_tbl_t *cmdtp,
-- 
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] mmc: send CMD0 before CMD1 for some MMC cards

[Yangbo Lu]

When the MMC framework was added in u-boot, the mmc_go_idle was
added before mmc_send_op_cond_iter in function mmc_send_op_cond
annotating that some cards seemed to need this. Actually, we still
need to do this in function mmc_complete_op_cond for those cards.
This has been verified on Micron MTFC4GACAECN eMMC chip.

Signed-off-by: Yangbo Lu 
---
 drivers/mmc/mmc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index ede5d6e..82e3268 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -418,6 +418,9 @@ static int mmc_complete_op_cond(struct mmc *mmc)
uint start;
int err;
 
+   /* Some cards seem to need this */
+   mmc_go_idle(mmc);
+
mmc->op_cond_pending = 0;
if (!(mmc->ocr & OCR_BUSY)) {
start = get_timer(0);
-- 
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 v6 00/76] mtd: Add SPI-NOR core support

[Huan Wang]

Hi, Jagan,

> On 03/03/2016 01:06 PM, york sun wrote:
> > On 02/29/2016 04:26 AM, Jagan Teki wrote:
> >> Hi York,
> >>
> >> On 27 February 2016 at 02:14, york sun  wrote:
> >>> On 02/22/2016 10:18 AM, Jagan Teki wrote:
> 
> 
> 
> 
>  Can you pls- test the dataflash changes? use u-boot-spi/spi-nor
> 
> >>> Jagan,
> >>>
> >>> I am getting there. Will test sf probe/read/write and probably boot
> >>> on selected platforms. Is there any specific platform/test in your
> mind?
> >>
> >> Yes, these tests OK. and if possible please verify 'sf protect' as
> well.
> >>
> >
> > Jagan,
> >
> > Sorry for the delay. I am having issue with both ls1021aqds and
> > ls1043aqds. Need to work with internal team to sort it out.
> >
> > My understanding the tests you need are for spi-nor, in my case,
> > fsl-qspi, right? This is not for fsl-dspi or fsl-espi driver. I only
> > have ls1021aqds and ls1043aqds with such support.
> >
> 
> Jagan,
> 
> Alison and Qianyu have tested on LS1021AQDS and LS1043AQDS. There were
> some issues. They will post their findings (and possible fix) to this
> thread.
> 
[Alison Wang] I verified QSPI boot on LS1021AQDS and LS1021ATWR boards based
on u-boot-spi/spi-nor branch. As we also support QSPI in SD boot, some 
modifications
are needed for ls1021aqds_sdcard_qspi_defconfig and 
ls1021atwr_sdcard_qspi_defconfig.
I submitted a set for the modifications, please help to review.
http://patchwork.ozlabs.org/patch/594819/ 
http://patchwork.ozlabs.org/patch/594820/ 

BTW, I have a concern about so much debugging information. Could we print them 
only when debugging?

drivers/mtd/spi-nor/m25p80.c:
printf("m25p80: 0x%p => cmd = { 0x%02x 0x%02x%02x%02x } chunk_len = %zu\n",
   buf, flash->command[0], flash->command[1], flash->command[2],
   flash->command[3], len);

=> run upqspiboot
Speed: 1000, full duplex
Using eTSEC3 device
TFTP from server 10.192.208.233; our IP address is 10.193.20.116
Filename 'wh/ls1/u-boot-qspiboot-swap.bin'.
Load address: 0x8200
Loading: ###
 1.5 MiB/s
done
Bytes transferred = 508532 (7c274 hex)
m25p80: erase d8  1  0  0 (1)
m25p80: erase d8  2  0  0 (2)
m25p80: erase d8  3  0  0 (3)
m25p80: erase d8  4  0  0 (4)
m25p80: erase d8  5  0  0 (5)
m25p80: erase d8  6  0  0 (6)
m25p80: erase d8  7  0  0 (7)
m25p80: erase d8  8  0  0 (8)
m25p80: erase d8  9  0  0 (9)
SF: 589824 bytes @ 0x1 Erased: OK
device 0 offset 0x1, size 0x8
m25p80: 0x8200 => cmd = { 0x02 0x01 } chunk_len = 64
m25p80: 0x8240 => cmd = { 0x02 0x010040 } chunk_len = 64
m25p80: 0x8280 => cmd = { 0x02 0x010080 } chunk_len = 64
m25p80: 0x82c0 => cmd = { 0x02 0x0100c0 } chunk_len = 64
m25p80: 0x82000100 => cmd = { 0x02 0x010100 } chunk_len = 64
m25p80: 0x82000140 => cmd = { 0x02 0x010140 } chunk_len = 64
m25p80: 0x82000180 => cmd = { 0x02 0x010180 } chunk_len = 64
m25p80: 0x820001c0 => cmd = { 0x02 0x0101c0 } chunk_len = 64
m25p80: 0x82000200 => cmd = { 0x02 0x010200 } chunk_len = 64
m25p80: 0x82000240 => cmd = { 0x02 0x010240 } chunk_len = 64
m25p80: 0x82000280 => cmd = { 0x02 0x010280 } chunk_len = 64
m25p80: 0x820002c0 => cmd = { 0x02 0x0102c0 } chunk_len = 64
m25p80: 0x82000300 => cmd = { 0x02 0x010300 } chunk_len = 64
m25p80: 0x82000340 => cmd = { 0x02 0x010340 } chunk_len = 64
m25p80: 0x82000380 => cmd = { 0x02 0x010380 } chunk_len = 64
m25p80: 0x820003c0 => cmd = { 0x02 0x0103c0 } chunk_len = 64
 (So much..)


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

Re: [U-Boot] [RFC] armv8: layerscape: Add support of u-boot device tree fix-up

[Prabhakar Kushwaha]

> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Wednesday, March 09, 2016 1:02 AM
> To: Prabhakar Kushwaha ; u-
> b...@lists.denx.de
> Cc: york sun ; Priyanka Jain 
> Subject: Re: [RFC] armv8: layerscape: Add support of u-boot device tree fix-
> up
> 
> On Tue, 2016-02-23 at 04:09 +, Prabhakar Kushwaha wrote:
> > > -Original Message-
> > > From: Scott Wood [mailto:o...@buserror.net]
> > > Sent: Tuesday, February 23, 2016 6:52 AM
> > > To: Prabhakar Kushwaha ; u-
> > > b...@lists.denx.de
> > > Cc: york sun ; Priyanka Jain
> > > 
> > > Subject: Re: [RFC] armv8: layerscape: Add support of u-boot device
> > > tree
> > > fix-
> > > up
> > >
> > > Where do you check that the device tree fits in OCRAM?  What about
> > > when SPL is occupying OCRAM?  Does the device tree get used with SPL
> > > (I don't think we were using FDT control at all the last time I
> > > worked with SPL on these chips)?
> > >
> >
> > I checked ls2085ardb dtb size in Linux. It is ~30K. So from 0xfff0 to
> > 2 there is enough space.
> >
> > For SPL. Assumption is SPL never use dts. It will only be used by u-boot.
> > Once control is transferred to u-boot, things work as it is like NOR boot.
> 
> I don't think that's a good assumption, given that I just saw a patch posted
> regarding SPL_OF_CONTROL.
> 

Thanks Scott for pointing out. 

This means SPL may also be have dtb.  Will it not increase size of SPL binary?

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

[U-Boot] [PATCH 1/2] defconfig: ls1021aqds_sdcard_qspi: Enable SPI-NOR

[Alison Wang]

As QSPI driver is supported in ls1021aqds_sdcard_qspi_defconfig, SPI-NOR
with MTD uclass, CONFIG_MTD_DATAFLASH and new flash vendor config
CONFIG_SPI_NOR_SPANSION need be enabled.

Signed-off-by: Alison Wang 
---
 configs/ls1021aqds_sdcard_qspi_defconfig | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/configs/ls1021aqds_sdcard_qspi_defconfig 
b/configs/ls1021aqds_sdcard_qspi_defconfig
index cd75af6..25ab3ee 100644
--- a/configs/ls1021aqds_sdcard_qspi_defconfig
+++ b/configs/ls1021aqds_sdcard_qspi_defconfig
@@ -7,8 +7,11 @@ CONFIG_DEFAULT_DEVICE_TREE="ls1021a-qds-duart"
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_OF_CONTROL=y
 CONFIG_DM=y
-CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_MTD=y
+CONFIG_MTD_SPI_NOR=y
+CONFIG_MTD_M25P80=y
+CONFIG_MTD_DATAFLASH=y
+CONFIG_SPI_NOR_SPANSION=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
 CONFIG_SYS_NS16550=y
-- 
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 2/2] defconfig: ls1021atwr_sdcard_qspi: Enable CONFIG_MTD

[Alison Wang]

As QSPI driver is supported in ls1021atwr_sdcard_qspi_defconfig,
CONFIG_MTD needs to be enabled for SPI-NOR with MTD uclass.

Signed-off-by: Alison Wang 
---
 configs/ls1021atwr_sdcard_qspi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/ls1021atwr_sdcard_qspi_defconfig 
b/configs/ls1021atwr_sdcard_qspi_defconfig
index 05f0806..867aaf7 100644
--- a/configs/ls1021atwr_sdcard_qspi_defconfig
+++ b/configs/ls1021atwr_sdcard_qspi_defconfig
@@ -6,6 +6,7 @@ CONFIG_SPL=y
 CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,SD_BOOT,SD_BOOT_QSPI"
 CONFIG_OF_CONTROL=y
 CONFIG_DM=y
+CONFIG_MTD=y
 CONFIG_MTD_SPI_NOR=y
 CONFIG_MTD_M25P80=y
 CONFIG_SPI_NOR_MISC=y
-- 
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] Newbie SPL question for socfpga_sockit

[Phil Reid]

G'day George,

On 3/03/2016 10:57 PM, George Broz wrote:

On 2 March 2016 at 23:11, Phil Reid  wrote:

On 3/03/2016 2:49 PM, George Broz wrote:


On 1 March 2016 at 19:49, Phil Reid  wrote:


On 2/03/2016 10:40 AM, George Broz wrote:


Sorry for the delayed response - got called away, but am back to this
now. I patched
socfpga_common.h and re-built the project. I picked up
spl/u-boot-spl-dtb.sfp and
u-boot-dtb.img and transferred them to the SD card with:

dd if=u-boot-spl-dtb.sfp of=/dev/sdf3 bs=64k seek=0
dd if=u-boot-dtb.img of=/dev/sdf3 bs=64k seek=4

Tried this with both the original DT set (socfpga.dtsi,
socfpga_cyclone.dtsi,
socfpga_cyclone5_sockit.dts) that came with the u-boot v2016.01 download
and
also an Altera-patched DT set that I've used to boot into Linux numerous
times.

When I start up the board I get:

U-Boot SPL 2016.01 (Mar 01 2016 - 17:28:14)
drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
drivers/ddr/altera/sequencer.c: CALIBRATION FAILED
drivers/ddr/altera/sequencer.c: Calibration complete
SDRAM calibration failed.
### ERROR ### Please RESET the board ###

I'm not a Quartus user, so I haven't done anything with the
qts-filter.sh script you
mentioned. Do I need to? I don't have any custom FPGA logic - it's
just the Terasic
board out of the box.

Thanks for any help!



Even without the custom FPGA logic the files generated from qts-filter.sh
need to match your board.
Sets up PLL and SDRAM parameters.
I'm not familiar with the Terasic dev board ( I do have the altera
devkit,
but haven't used it for awhile).
I'd hope the files in the git repo are correct for your board.
Without the corresponding qsys project it's hard to be sure.


Hi Phil,

So as my next attempt, there was a Quartus/Qsys example that came
with the Terasic board (specific to my Rev. of the board).

* I took the contents of the 'handoff folder', .sof, and .sopcinfo file.
* launched an "Embedded Command Shell" from EDS 15.0 and then the BSP
editor GUI
* pointed the BSP editor to the "handoff folder", and hit "Generate"
to produce iocsr, pinmux, pll, etc. files
* applied qts-filter.sh to these files, the output of which I then
dropped into the u-boot source @ ../board/terasic/sockit/qts
* rebuilt uboot spl & image, but got a similar result:

U-Boot SPL 2016.01 (Mar 02 2016 - 22:13:31)
drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
drivers/ddr/altera/sequencer.c: CALIBRATION FAILED
drivers/ddr/altera/sequencer.c: Calibration complete
SDRAM calibration failed.
### ERROR ### Please RESET the board ###

Except now it repeats four times, whereas before it only printed out once.

It that essentially the correct procedure? Is it now a matter of
looking through
the include files that where generated by qts-filter.sh to find a
setting that is "off"?

(BTW - my first attempt was to use EDS 13.0, but that resulted in
several undefined macros when it
came time to compile u-boot with the qts-filter-generated code. How
does one know which tool version to use?)



What does a diff of the new files show compared to the ones in uboot.


Here's two of them...

--- 
/home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/sdram_config.h.orig
+++ 
/home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/sdram_config.h

@@ -33,10 +33,10 @@
  #define CONFIG_HPS_SDR_CTRLCFG_DRAMODT_WRITE 1
  #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_AL 0
  #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TCL 7
-#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TCWL 6
-#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TFAW 12
-#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRFC 104
-#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRRD 4
+#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TCWL 7
+#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TFAW 15
+#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRFC 120
+#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRRD 3
  #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING2_IF_TRCD 6
  #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING2_IF_TREFI 3120
  #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING2_IF_TRP 6

@@ -46,12 +46,12 @@
  #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TMRD 4
  #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRAS 14
  #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRC 20
-#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRTP 4
+#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRTP 3
  #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING4_PWRDOWNEXIT 3
  #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING4_SELFRFSHEXIT 512
  #define CONFIG_HPS_SDR_CTRLCFG_FIFOCFG_INCSYNC 0
  #define CONFIG_HPS_SDR_CTRLCFG_FIFOCFG_SYNCMODE 0
-#define CONFIG_HPS_SDR_CTRLCFG_FPGAPORTRST 0x1FF
+#define CONFIG_HPS_SDR_CTRLCFG_FPGAPORTRST 0x0
  #define CONFIG_HPS_SDR_CTRLCFG_LOWPWREQ_SELFRFSHMASK 3
  #define CONFIG_HPS_SDR_CTRLCFG_LOWPWRTIMING_AUTOPDCYCLES 0
  #define CONFIG_HPS_SDR_CTRLCFG_LOWPWRTIMING_CLKDISABLECYCLES 8

@@ -147,7 +147,7 @@
  #define IO_SHIFT_DQS_EN_WHEN_SHIFT_DQS 0
  #define 

Re: [U-Boot] [PATCH 3/3] include/crc.h: Remove unreferenced cyg_xxx() prototypes

[Tom Rini]

On Thu, Mar 03, 2016 at 09:34:13AM +0100, Stefan Roese wrote:

> These cyg_ prototypes are not referenced anywhere in current mainline
> U-Boot. So lets remove them.
> 
> Signed-off-by: Stefan Roese 

Reviewed-by: Tom Rini 

-- 
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 2/3] lib/crc16.c: Rename cyg_crc16() to crc16_ccitt() and add crc start value

[Tom Rini]

On Thu, Mar 03, 2016 at 09:34:12AM +0100, Stefan Roese wrote:

> The original name of this function is unclear. This patch renames this
> CRC16 function to crc16_ccitt() matching its name with its
> implementation.
> 
> To make the usage of this function more flexible, lets add the CRC start
> value as parameter to this function. This way it can be used by other
> functions requiring different start values than 0 as well.
> 
> Signed-off-by: Stefan Roese 

Reviewed-by: Tom Rini 

-- 
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 1/3] lib/crc16.c: Coding-style cleanup

[Tom Rini]

On Thu, Mar 03, 2016 at 09:34:11AM +0100, Stefan Roese wrote:

> lib/crc16.c is changed to match the common U-Boot coding-style.
> 
> Signed-off-by: Stefan Roese 

Reviewed-by: Tom Rini 

-- 
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] buildman for sandbox

[Tom Rini]

On Sun, Mar 06, 2016 at 07:39:30PM -0700, Simon Glass wrote:
> Hi Joe,
> 
> On 7 May 2015 at 03:17, Joe Hershberger  wrote:
> > Hi Simon,
> >
> > Is there a way to make buildman compile sandbox with a non-system tool
> > chain? I've tried creating an alias from sandbox to i386 and removing
> > the "root" entry. It then simply claims not to have a sandbox tool
> > chain.
> >
> > Thanks,
> > -Joe
> 
> FYI I've prepared a series that permits:
> 
> [toolchain-prefix]
> sandbox = /path/to/sandbox-gcc

And in this case it just takes what it finds, if it exists right?  ie I
can also do:
sandbox = /usr/bin/clang
?

-- 
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 02/69] arm: Add a 64-bit division routine to the private library

[Tom Rini]

On Sun, Mar 06, 2016 at 07:27:45PM -0700, Simon Glass wrote:

> This is missing, with causes lldiv() to fail on boards with use the private
> libgcc. Add the missing routine.
> 
> Code is available for using the CLZ instruction but it is not enabled at
> present.

Mention the rev of coreboot we pull this file in from please, thanks!

-- 
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] [U-Boot,V2,2/2] malloc: remove !gd handling

[Tom Rini]

On Sat, Mar 05, 2016 at 10:30:53AM -0700, Stephen Warren wrote:

> Following the previous patch, malloc() is never called before gd is set,
> so we can remove the special-case check for this condition.
> 
> This reverts commit 854d2b9753e4 "dlmalloc: ensure gd is set for early
> alloc".
> 
> Cc: Rabin Vincent 
> Signed-off-by: Stephen Warren 
> Reviewed-by: Tom Rini 
> Reviewed-by: Simon Glass 

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

Re: [U-Boot] sandbox: Fix building with LLVM

[Tom Rini]

On Sat, Mar 05, 2016 at 02:07:44PM -0500, Tom Rini wrote:

> - The macro __BIGGEST_ALIGNMENT__ is gcc-specific.  If it is not defined
>   we'll just assume 16.  This is correct for at least the common cases
>   and LLVM does not provide an equivalent macro.
> - When linking U-Boot we're passing -T to the linker, and while gcc will
>   just pass this along with LLVM we need to be specific.
> 
> Cc: Simon Glass 
> Signed-off-by: Tom Rini 
> Reviewed-by: Simon Glass 

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

Re: [U-Boot] [U-Boot,V2,1/2] malloc: use hidden visibility

[Tom Rini]

On Sat, Mar 05, 2016 at 10:30:52AM -0700, Stephen Warren wrote:

> When running sandbox, the following phases occur, each with different
> malloc implementations or behaviors:
> 
> 1) Dynamic linker execution, using the dynamic linker's own malloc()
> implementation. This is fully functional.
> 
> 2) After U-Boot's malloc symbol has been hooked into the GOT, but before
> any U-Boot code has run. This phase is entirely non-functional, since
> U-Boot's gd symbol is NULL and U-Boot's initf_malloc() and
> mem_malloc_init() have not been called.
> 
> At least on Ubuntu Xenial, the dynamic linker does make both malloc() and
> free() calls during this phase. Currently these free() calls crash since
> they dereference gd, which is NULL.
> 
> U-Boot itself makes no use of malloc() during this phase.
> 
> 3) U-Boot execution after gd is set and initf_malloc() has been called.
> This is fully functional, albeit via a very simple malloc()
> implementation.
> 
> 4) U-Boot execution after mem_malloc_init() has been called. This is fully
> functional with a complete malloc() implementation.
> 
> Furthermore, if code that called malloc() during phase 1 calls free() in
> phase 3 or later, it is likely that heap corruption will occur, since
> U-Boot's malloc implementation will assume the pointer is part of its own
> heap, although it isn't. I have not actively observed this happening.
> 
> To prevent phase 2 from happening, this patch makes all of U-Boot's malloc
> library public symbols have hidden visibility. This prevents them from
> being hooked into the GOT, so only code in the U-Boot binary itself
> actually calls them; any other code will call into the standard C library
> malloc(). This also avoids the "furthermore" issue mentioned above.
> 
> I have seen references to this GCC pragma in blog posts from 2008, and
> RHEL5's ancient gcc appears to accept it fine, so I believe it's quite
> safe to use it without checking gcc version.
> 
> Cc: Rabin Vincent 
> Signed-off-by: Stephen Warren 
> Reviewed-by: Tom Rini 
> Reviewed-by: Simon Glass 

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

Re: [U-Boot] omap3: Use raw SPL by default for mmc1

[Tom Rini]

On Tue, Mar 01, 2016 at 09:56:34AM +0100, Alexander Graf wrote:

> Now that we fall back to the FS code path when we don't find u-boot
> at the raw sector offset, there is no good reason to not default to
> raw boot.
> 
> With this patch, I can successfully boot u-boot from a raw sector
> offset on beagle-xm.
> 
> Signed-off-by: Alexander Graf 

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

Re: [U-Boot] api: Export API structure address as an environment variable

[Tom Rini]

On Tue, Mar 01, 2016 at 02:19:04PM +0200, Stanislav Galabov wrote:

> This patch makes the U-Boot api export its structure address as an environment
> variable, so it can be used to directly hint FreeBSD's loader of api's 
> location.
> 
> The relevant FreeBSD loader change is currently under review at:
> https://reviews.freebsd.org/D5492
> 
> Signed-off-by: Stanislav Galabov 

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

Re: [U-Boot] [U-Boot, 2/2] OMAP3: am3517_evm: Add NAND MTD partitions with UBI/UBIFS support

[Tom Rini]

On Sat, Mar 05, 2016 at 01:19:59PM -0600, Derald D. Woods wrote:

> - Add required UBI/UBIFS config definitions
> - Add reasonable MTD partition layout
> - Remove JFFS2 config definitions
> - Drop some CFI verbage and definitions
> - Make comment 'one-liners' truly one line
> - Improve readability and content arrangement
> 
> Signed-off-by: Derald D. Woods 
> Reviewed-by: Tom Rini 

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

Re: [U-Boot] [U-Boot,1/2] OMAP3: am3517_evm: Use BCH8 ECC for NAND

[Tom Rini]

On Sat, Mar 05, 2016 at 01:19:58PM -0600, Derald D. Woods wrote:

> Select 8-bit BCH ecc-scheme with s/w based error correction
> - OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> 
> Signed-off-by: Derald D. Woods 
> Reviewed-by: Tom Rini 

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

Re: [U-Boot] [PATCH] spl: add a new stub spl_early_board_init() for early SoC-specific setup

[Simon Glass]

Hi Masahiro,

On 8 March 2016 at 04:37, Masahiro Yamada  wrote:
> We are generally supposed to implement SoC/board-specific SPL init
> code in spl_board_init(), but it is called after spl_init() where the
> FDT is setup and devices are bound.
>
> This new stub spl_early_board_init() would be useful to put something
> really SoC-specific, for example, debug_uart_init().
>
> In fact, I was hit by some problems on FDT setup when I was tackling
> on a completely new platform.  I wished I could use the debug UART
> earlier in situations like that.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  common/spl/spl.c | 6 ++
>  include/spl.h| 1 +
>  2 files changed, 7 insertions(+)
>
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index e5167bf..df85b09 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -150,6 +150,10 @@ static int spl_ram_load_image(void)
>  }
>  #endif
>
> +void __weak spl_early_board_init(void)
> +{
> +}
> +
>  int spl_init(void)
>  {
> int ret;
> @@ -344,6 +348,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
>  {
> int i;
>
> +   spl_early_board_init();

Why not put this in board_init_f()? That is a little earlier.

In fact you can replace that function with your own version.

(although it would be better if we had a single board_init_f() and
called out to board-specific code from there.)

> +
> debug(">>spl:board_init_r()\n");
>

[snip]

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

Re: [U-Boot] [PATCH] serial: pl01x: Add support for devices with the rate pre-configured.

[Simon Glass]

Hi Tom,

On 7 March 2016 at 16:37, Tom Rini  wrote:
> On Sun, Mar 06, 2016 at 07:38:47PM -0700, Simon Glass wrote:
>> Hi Stephen,
>>
>> On 5 March 2016 at 23:26, Stephen Warren  wrote:
>> >
>> > On 02/05/2016 09:19 PM, Stephen Warren wrote:
>> >>
>> >> On 02/05/2016 02:43 PM, Eric Anholt wrote:
>> >>>
>> >>> For Raspberry Pi, we had the input clock rate to the pl011 fixed in
>> >>> the rpi.c file, but it may be changed by firmware due to user changes
>> >>> to config.txt.  Since the firmware always sets up the uart (default
>> >>> 115200 output unless the user changes it), we can just skip our own
>> >>> uart init to simplify the boot process and more reliably get serial
>> >>> output.
>> >>
>> >>
>> >> Tested-by: Stephen Warren 
>> >> (With a 6MHz init_uart_clock and with/without init_uart_baud=9600)
>> >
>> >
>> > Simon/Tom, did this slip through the cracks, or are you deferring it until 
>> > the next release?
>>
>> We haven't heard back on the review comments.
>>
>> I don't really mind if we go the DT approach or this one. But this
>> patch needs a little rework I think.
>
> I thought the main review comment was "didn't we try and do this with
> DT?" ?  I'm feeling like we might want to skip doing anything DT related
> for this part...

My comment was on 6 Feb:

> +   TYPE_PL01X_PRECONFIGURED,

This seems odd. You are not adding a new UART type.

How about a separate bool flag?

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

Re: [U-Boot] [PATCH] debug_uart: output CR along with LF

[Simon Glass]

On 8 March 2016 at 02:19, Masahiro Yamada  wrote:
>
> The serial output from the debug UART carries on going far to the
> right in the console.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  include/debug_uart.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)


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

Re: [U-Boot] [PATCH V6] ARM: Various: Future-proof serial platdata

[Simon Glass]

On 7 March 2016 at 20:08, Adam Ford  wrote:
> A few boards still use ns16550_platdata structures, but assume the structure
> is going to be in a specific order. By explicitly naming each entry,
> this should also help 'future-proof' in the event the structure changes.
>
> Tested on the Logic PD Torpedo + Wireless.
>
> I only changed a handful of devices that used the same syntax as the Logic
> board.  Appologies if I missed one or stepped on toes.  Thanks to Derald Woods
> and Alexander Graf.
>
> Signed-off-by: Adam Ford 
>
> V6: Add fix to arch/arm/cpu/armv7/am33xx/board.c
>
> V5: Add fix to arch/arm/cpu/arm926ejs/lpc32xx/devices.c
>
> V4: Fix subject heading
>
> V3: Remove  reg_offset out in all the structs. It was reverted out, and and if
> it did exist, it would get initialized to 0 by default.
>
> V2: I hastily copy-pasted the boards without looking at the UART number.
> This addresses 3 boards that use UART3 and not UART1.
> ---
>  arch/arm/cpu/arm926ejs/lpc32xx/devices.c |  8 
>  arch/arm/cpu/armv7/am33xx/board.c| 12 ++--
>  board/isee/igep00x0/igep00x0.c   |  6 +++---
>  board/logicpd/omap3som/omap3logic.c  |  6 +++---
>  board/logicpd/zoom1/zoom1.c  |  6 +++---
>  board/overo/overo.c  |  6 +++---
>  board/quipos/cairo/cairo.c   |  6 +++---
>  board/ti/beagle/beagle.c |  6 +++---
>  board/timll/devkit8000/devkit8000.c  |  6 +++---
>  9 files changed, 31 insertions(+), 31 deletions(-)

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

Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Simon Glass]

Hi Stefan,

On 8 March 2016 at 10:41, Stefan Roese  wrote:
> Hi Simon,
>
> On 08.03.2016 17:54, Simon Glass wrote:
>> Hi Stefan,
>>
>> On 8 March 2016 at 09:45, Stefan Roese  wrote:
>>> Hi Simon, Hi Bin,
>>>
>>> On 12.08.2015 05:54, Simon Glass wrote:
 +Gabriel

 Hi Andrew,

 On 11 August 2015 at 09:20, Andrew Bradford  
 wrote:
> Hi Simon,
>
> On 08/11 08:06, Simon Glass wrote:
>> Hi Andrew,
>>
>> On 11 August 2015 at 06:08, Andrew Bradford 
>>  wrote:
>>> Hi Simon,
>>>
>>> On 08/10 21:07, Simon Glass wrote:
 Hi Bin,

 On 10 August 2015 at 20:53, Bin Meng  wrote:
> Hi Andrew,
>
> On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford
>  wrote:
>> Hi Bin,
>>
>> On 08/09 10:52, Bin Meng wrote:
>>> Hi Andrew,
>>>
>>> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
>>>  wrote:
 Hi Simon,

 On 08/08 10:18, Simon Glass wrote:
> Hi,
>
> On 7 August 2015 at 06:44, Bin Meng  wrote:
>> On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
>>  wrote:
>>> From: Andrew Bradford 
>>>
>>> Allow for configuration of FSP UPD from the device tree which 
>>> will
>>> override any settings which the FSP was built with itself.
>>>
>>> Modify the MinnowMax and BayleyBay boards to transfer sensible 
>>> UPD
>>> settings from the Intel FSPv4 Gold release to the respective 
>>> dts files,
>>> with the condition that the memory-down parameters for 
>>> MinnowMax are
>>> also used.
>>>
>>> Signed-off-by: Andrew Bradford 
>>> ---
>>>
>>
>> Reviewed-by: Bin Meng 
>> Tested-by: Bin Meng 
>>
>
> Acked-by: Simon Glass 
> Tested on minnowmax:
> Tested-by: Simon Glass 
>
> I found that I need to remove two properties from the 
> minnowmax.dts:
>
> - fsp,enable-xhci needs to be removed as this does not work in 
> U-Boot
> at present and stops EHCI from working
> - fsp,mrc-debug-msg needs to be removed to prevent debug 
> information
> being displayed
>
> I plan to apply this with these changes - please let me know if 
> this
> doesn't suit.

 I'm OK with disabling xhci and the MRC debug output in the FSP.

 But if xhci is disabled then I believe when Linux boots that the 
 USB 3.0
 port on Minnow Max will only act as a USB 2.0 port.  That u-boot 
 doesn't
 yet have working XHCI on E3800 means there is a tradeoff and I 
 wasn't
 sure which was a better choice.
>>>
>>> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
>>> works, I'd rather we keep fsp,enable-xhci in the U-Boot.
>>
>> I believe that the xhci port does work on Minnow Max in Linux but I 
>> do
>> not have a board so I'm unable to test, sorry.
>>
>
> OK, my test shows that ehci works fine in U-Boot on Bayley Bay.
>
> Hi Simon,
>
> What do you think regarding to xhci vs. ehci in U-Boot?

 The problem is that USB is then broken in U-Boot. I think it is better
 to limit the speed for the moment until we have that fixed. It is
 quite useful to be able to use a keyboard or USB stick in U-Boot.

 With my testing the bottom (blue) port works fine but the top port
 does not. This happens regardless of the xhci setting.
>>>
>>> Minnowmax has a USB power switch enable which determines if the VBUS2
>>> net is turned on or not, which will supply or not supply power to the
>>> USB 2.0 port.  The blue USB 3.0 port also has an enable.  Both enables
>>> and the USB ports themselves are located on page 16 of the schematic
>>> that I have.
>>>
>>> The switches to enable the VBUS for each port are active high and pulled
>>> down.  So to turn them on, I believe that's the point of the pinmuxing
>>> and GPIO settings which are used in the minnowmax.dts.  Can you verify
>>> if these are 

Re: [U-Boot] [PATCH v2] arm: imx: Add support for GE Bx50v3 boards

[Fabio Estevam]

On Tue, Mar 8, 2016 at 7:48 PM, Akshay Bhat  wrote:

> If there are no further review comments, can this patch be applied in the
> next merge window (for v2016.05)?
>
> Also I have couple updates to the bx50v3.c file. Should I wait for this
> patch to be applied before sending a new patch with the changes (wasn't sure
> if you had a -next branch where the v2 patch was already applied)?

Yes, a -next branch would be very convenient.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm64: define _image_binary_end to fix SPL_OF_CONTROL

[Tom Rini]

On Tue, Mar 08, 2016 at 08:34:44PM +0900, Masahiro Yamada wrote:

> To make SPL_OF_CONTROL work on ARM64 SoCs, _image_binary_end must be
> defined in the linker script.
> 
>  LD  spl/u-boot-spl
> lib/built-in.o: In function `fdtdec_setup':
> lib/fdtdec.c:1186: undefined reference to `_image_binary_end'
> lib/fdtdec.c:1186: undefined reference to `_image_binary_end'
> make[1]: *** [spl/u-boot-spl] Error 1
> make: *** [spl/u-boot-spl] Error 2
> 
> Note:
> CONFIG_SPL_SEPARATE_BSS must be defined as well on ARM64 SoCs.
> 
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Tom Rini 

-- 
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] spl: add a new stub spl_early_board_init() for early SoC-specific setup

[Tom Rini]

On Tue, Mar 08, 2016 at 08:37:16PM +0900, Masahiro Yamada wrote:

> We are generally supposed to implement SoC/board-specific SPL init
> code in spl_board_init(), but it is called after spl_init() where the
> FDT is setup and devices are bound.
> 
> This new stub spl_early_board_init() would be useful to put something
> really SoC-specific, for example, debug_uart_init().
> 
> In fact, I was hit by some problems on FDT setup when I was tackling
> on a completely new platform.  I wished I could use the debug UART
> earlier in situations like that.
> 
> Signed-off-by: Masahiro Yamada 

This is usually done with s_init() and uniphier opts out of that.  I
would conceed however that things could use some further clean-up and
organization here.

-- 
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 v2] arm: imx: Add support for GE Bx50v3 boards

[Akshay Bhat]

Hi Stefano,

On 01/29/2016 11:07 PM, Peng Fan wrote:

Hi Akshay,

On Fri, Jan 29, 2016 at 03:16:40PM -0500, Akshay Bhat wrote:

Add support for GE B450v3, B650v3 and B850v3 boards. The boards
are based on Advantech BA16 module which has a i.MX6D processor.
The boards support:
- FEC Ethernet
- USB Ports
- SDHC and MMC boot
- SPI NOR
- LVDS and HDMI display

Basic information about the module:
- Module manufacturer: Advantech
- CPU: Freescale ARM Cortex-A9 i.MX6D
- SPECS:
 Up to 2GB Onboard DDR3 Memory;
 Up to 16GB Onboard eMMC NAND Flash
 Supports OpenGL ES 2.0 and OpenVG 1.1
 HDMI, 24-bit LVDS
 1x UART, 2x I2C, 8x GPIO,
 4x Host USB 2.0 port, 1x USB OTG port,
 1x micro SD (SDHC),1x SDIO, 1x SATA II,
 1x 10/100/1000 Mbps Ethernet, 1x PCIe X1 Gen2

Signed-off-by: Akshay Bhat 



Reviewed-by: Peng Fan 

Regards,
Peng.



If there are no further review comments, can this patch be applied in 
the next merge window (for v2016.05)?


Also I have couple updates to the bx50v3.c file. Should I wait for this 
patch to be applied before sending a new patch with the changes (wasn't 
sure if you had a -next branch where the v2 patch was already applied)?


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

Re: [U-Boot] [PATCH] sunxi: fix DCDC2 output in CHIP_defconfig

[Maxime Ripard]

On Mon, Mar 07, 2016 at 03:50:11PM +0200, Siarhei Siamashka wrote:
> On Mon,  7 Mar 2016 13:44:11 +0100
> Maxime Ripard  wrote:
> 
> > From: Boris Brezillon 
> > 
> > Unlike the datasheet recommendation, the R8 SoC requires a 1.4V supply
> > for its CPU when operating at 1Ghz.
> 
> That's interesting. Is this R8 SoC datasheet with the Allwinner
> recommended cpufreq operating points available in public access
> somewhere?

Yeah:
https://github.com/NextThingCo/CHIP-Hardware/tree/master/CHIP%5Bv1_0%5D/CHIPv1_0-BOM-Datasheets

But note that it's the usual datasheet from Allwinner, you don't have
a list of operating points.

> Are they really recommending 1008MHz @1.3V there?

It was a misunderstanding on our side. We thought that the nominal
tension was the recommended one, and our prototypes were running just
fine with it. Later samples (probably from a different batch) turned
out to have memory corruptions because of the lower voltage.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


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 1/7 v5] armv8: ls2080a: remove obsolete stream ID partitioning support

[Stuart Yoder]

From: Stuart Yoder 

Remove stream ID partitioning support that has been made
obsolete by upstream device tree bindings that specify how
representing how PCI requester IDs are mapped to MSI specifiers
and SMMU stream IDs.

Signed-off-by: Stuart Yoder 
---
-v5: no change

 arch/arm/cpu/armv8/fsl-layerscape/fdt.c |  113 ---
 drivers/pci/pcie_layerscape.c   |   70 ---
 2 files changed, 183 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index 4e4861d..7a64f41 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -70,115 +70,6 @@ void ft_fixup_cpu(void *blob)
 }
 #endif
 
-/*
- * the burden is on the the caller to not request a count
- * exceeding the bounds of the stream_ids[] array
- */
-void alloc_stream_ids(int start_id, int count, u32 *stream_ids, int max_cnt)
-{
-   int i;
-
-   if (count > max_cnt) {
-   printf("\n%s: ERROR: max per-device stream ID count exceed\n",
-  __func__);
-   return;
-   }
-
-   for (i = 0; i < count; i++)
-   stream_ids[i] = start_id++;
-}
-
-/*
- * This function updates the mmu-masters property on the SMMU
- * node as per the SMMU binding-- phandle and list of stream IDs
- * for each MMU master.
- */
-void append_mmu_masters(void *blob, const char *smmu_path,
-   const char *master_name, u32 *stream_ids, int count)
-{
-   u32 phandle;
-   int smmu_nodeoffset;
-   int master_nodeoffset;
-   int i;
-
-   /* get phandle of mmu master device */
-   master_nodeoffset = fdt_path_offset(blob, master_name);
-   if (master_nodeoffset < 0) {
-   printf("\n%s: ERROR: master not found\n", __func__);
-   return;
-   }
-   phandle = fdt_get_phandle(blob, master_nodeoffset);
-   if (!phandle) { /* if master has no phandle, create one */
-   phandle = fdt_create_phandle(blob, master_nodeoffset);
-   if (!phandle) {
-   printf("\n%s: ERROR: unable to create phandle\n",
-  __func__);
-   return;
-   }
-   }
-
-   /* append it to mmu-masters */
-   smmu_nodeoffset = fdt_path_offset(blob, smmu_path);
-   if (fdt_appendprop_u32(blob, smmu_nodeoffset, "mmu-masters",
-  phandle) < 0) {
-   printf("\n%s: ERROR: unable to update SMMU node\n", __func__);
-   return;
-   }
-
-   /* for each stream ID, append to mmu-masters */
-   for (i = 0; i < count; i++) {
-   fdt_appendprop_u32(blob, smmu_nodeoffset, "mmu-masters",
-  stream_ids[i]);
-   }
-
-   /* fix up #stream-id-cells with stream ID count */
-   if (fdt_setprop_u32(blob, master_nodeoffset, "#stream-id-cells",
-   count) < 0)
-   printf("\n%s: ERROR: unable to update #stream-id-cells\n",
-  __func__);
-}
-
-
-/*
- * The info below summarizes how streamID partitioning works
- * for ls2080a and how it is conveyed to the OS via the device tree.
- *
- *  -non-PCI legacy, platform devices (USB, SD/MMC, SATA, DMA)
- * -all legacy devices get a unique ICID assigned and programmed in
- *  their AMQR registers by u-boot
- * -u-boot updates the hardware device tree with streamID properties
- *  for each platform/legacy device (smmu-masters property)
- *
- *  -PCIe
- * -for each PCI controller that is active (as per RCW settings),
- *  u-boot will allocate a range of ICID and convey that to Linux via
- *  the device tree (smmu-masters property)
- *
- *  -DPAA2
- * -u-boot will allocate a range of ICIDs to be used by the Management
- *  Complex for containers and will set these values in the MC DPC image.
- * -the MC is responsible for allocating and setting up ICIDs
- *  for all DPAA2 devices.
- *
- */
-#ifdef CONFIG_FSL_LSCH3
-static void fdt_fixup_smmu(void *blob)
-{
-   int nodeoffset;
-
-   nodeoffset = fdt_path_offset(blob, "/iommu@500");
-   if (nodeoffset < 0) {
-   printf("\n%s: WARNING: no SMMU node found\n", __func__);
-   return;
-   }
-
-   /* fixup for all PCI controllers */
-#ifdef CONFIG_PCI
-   fdt_fixup_smmu_pcie(blob);
-#endif
-}
-#endif
-
 void ft_cpu_setup(void *blob, bd_t *bd)
 {
 #ifdef CONFIG_MP
@@ -200,8 +91,4 @@ void ft_cpu_setup(void *blob, bd_t *bd)
 #ifdef CONFIG_FSL_ESDHC
fdt_fixup_esdhc(blob, bd);
 #endif
-
-#ifdef CONFIG_FSL_LSCH3
-   fdt_fixup_smmu(blob);
-#endif
 }
diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 99f9c83..bb29222 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -664,73 +664,3 @@ void 

[U-Boot] [PATCH 2/7 v5] armv8: ls2080a: update stream ID partitioning info

[Stuart Yoder]

From: Stuart Yoder 

-update comments around how stream IDs are partitioned

-stream IDs allocated to PCI are no longer divided up by
 controller, but are instead a contiguous range

Signed-off-by: Stuart Yoder 
---
-v5: no change

 .../asm/arch-fsl-layerscape/ls2080a_stream_id.h|   55 
 1 file changed, 34 insertions(+), 21 deletions(-)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/ls2080a_stream_id.h 
b/arch/arm/include/asm/arch-fsl-layerscape/ls2080a_stream_id.h
index 954104b..ee28323 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/ls2080a_stream_id.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/ls2080a_stream_id.h
@@ -7,28 +7,48 @@
 #ifndef __FSL_STREAM_ID_H
 #define __FSL_STREAM_ID_H
 
-/* Stream IDs on ls2080a devices are not hardwired and are
+/*
+ * Stream IDs on ls2080a devices are not hardwired and are
  * programmed by sw.  There are a limited number of stream IDs
  * available, and the partitioning of them is scenario dependent.
  * This header defines the partitioning between legacy, PCI,
  * and DPAA2 devices.
  *
- * This partitiong can be customized in this file depending
- * on the specific hardware config-- e.g. perhaps not all
- * PEX controllers are in use.
+ * This partitioning can be customized in this file depending
+ * on the specific hardware config:
+ *
+ *  -non-PCI legacy, platform devices (USB, SD/MMC, SATA, DMA)
+ * -all legacy devices get a unique stream ID assigned and programmed in
+ *  their AMQR registers by u-boot
+ *
+ *  -PCIe
+ * -there is a range of stream IDs set aside for PCI in this
+ *  file.  U-boot will scan the PCI bus and for each device discovered:
+ * -allocate a streamID
+ * -set a PEXn LUT table entry mapping 'requester ID' to 'stream ID'
+ * -set a msi-map entry in the PEXn controller node in the
+ *  device tree (see Documentation/devicetree/bindings/pci/pci-msi.txt
+ *  for more info on the msi-map definition)
  *
- * On LS2080 stream IDs are programmed in AMQ registers (32-bits) for
+ *  -DPAA2
+ * -u-boot will allocate a range of stream IDs to be used by the Management
+ *  Complex for containers and will set these values in the MC DPC image.
+ * -the MC is responsible for allocating and setting up 'isolation context
+ *  IDs (ICIDs) based on the allocated stream IDs for all DPAA2 devices.
+ *
+ * On ls2080a SoCs stream IDs are programmed in AMQ registers (32-bits) for
  * each of the different bus masters.  The relationship between
  * the AMQ registers and stream IDs is defined in the table below:
  *  AMQ bitstreamID bit
  *  ---
- *   PL[18] 9
- *  BMT[17] 8
- *   VA[16] 7
- * [15] -
- * ICID[14:7]   -
- * ICID[6:0]6-0
+ *   PL[18] 9// privilege bit
+ *  BMT[17] 8// bypass translation
+ *   VA[16] 7// reserved
+ * [15] -// unused
+ * ICID[14:7]   -// unused
+ * ICID[6:0]6-0  // isolation context id
  * 
+ *
  */
 
 #define AMQ_PL_MASK(0x1 << 18)   /* priviledge bit */
@@ -46,16 +66,9 @@
 #define FSL_SATA2_STREAM_ID5
 #define FSL_DMA_STREAM_ID  6
 
-/* PCI - programmed in PEXn_LUT by OS */
-/*   4 IDs per controller */
-#define FSL_PEX1_STREAM_ID_START   7
-#define FSL_PEX1_STREAM_ID_END 10
-#define FSL_PEX2_STREAM_ID_START   11
-#define FSL_PEX2_STREAM_ID_END 14
-#define FSL_PEX3_STREAM_ID_START   15
-#define FSL_PEX3_STREAM_ID_END 18
-#define FSL_PEX4_STREAM_ID_START   19
-#define FSL_PEX4_STREAM_ID_END 22
+/* PCI - programmed in PEXn_LUT */
+#define FSL_PEX_STREAM_ID_START7
+#define FSL_PEX_STREAM_ID_END  22
 
 /* DPAA2 - set in MC DPC and alloced by MC */
 #define FSL_DPAA2_STREAM_ID_START  23
-- 
1.7.9.5

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

[U-Boot] [PATCH 6/7 v5] pci/layerscape: fdt: function to set msi-map entries

[Stuart Yoder]

From: Stuart Yoder 

msi-map properties are used to tell an OS how PCI requester
IDs are mapped to ARM SMMU stream IDs.  This patch defines a
function to append a single msi-map entry to a given PCI controller
device tree node.

Signed-off-by: Stuart Yoder 
---
-v5: no change

 drivers/pci/pcie_layerscape.c |   42 +
 1 file changed, 42 insertions(+)

diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index f3bf689..73af423 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -520,6 +520,48 @@ static u32 ls_pcie_next_streamid(void)
 
return next_stream_id++;
 }
+
+/*
+ * An msi-map is a property to be added to the pci controller
+ * node.  It is a table, where each entry consists of 4 fields
+ * e.g.:
+ *
+ *  msi-map = <[devid] [phandle-to-msi-ctrl] [stream-id] [count]
+ * [devid] [phandle-to-msi-ctrl] [stream-id] [count]>;
+ */
+static void fdt_pcie_set_msi_map_entry(void *blob, struct ls_pcie *pcie,
+  u32 devid, u32 streamid)
+{
+   char pcie_path[19];
+   u32 *prop;
+   u32 phandle;
+   int nodeoffset;
+
+   /* find pci controller node */
+   snprintf(pcie_path, sizeof(pcie_path), "/soc/pcie@%llx",
+(u64)pcie->dbi);
+   nodeoffset = fdt_path_offset(blob, pcie_path);
+   if (nodeoffset < 0) {
+   printf("\n%s: ERROR: unable to update PCIe node: %s\n",
+  __func__, pcie_path);
+   return;
+   }
+
+   /* get phandle to MSI controller */
+   prop = (u32 *)fdt_getprop(blob, nodeoffset, "msi-parent", 0);
+   if (prop == NULL) {
+   printf("\n%s: ERROR: missing msi-parent: %s\n", __func__,
+  pcie_path);
+   return;
+   }
+   phandle = be32_to_cpu(*prop);
+
+   /* set one msi-map row */
+   fdt_appendprop_u32(blob, nodeoffset, "msi-map", devid);
+   fdt_appendprop_u32(blob, nodeoffset, "msi-map", phandle);
+   fdt_appendprop_u32(blob, nodeoffset, "msi-map", streamid);
+   fdt_appendprop_u32(blob, nodeoffset, "msi-map", 1);
+}
 #endif
 
 int ls_pcie_init_ctrl(int busno, enum srds_prtcl dev, struct ls_pcie_info 
*info)
-- 
1.7.9.5

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

[U-Boot] [PATCH 4/7 v5] pci/layerscape: add support for LUT

[Stuart Yoder]

From: Stuart Yoder 

The per-PCI controller LUT (Look-Up-Table) is a 32-entry table
that maps PCI requester IDs (bus/dev/fun) to a stream ID.

This patch implements infrastructure to enable LUT initialization:
  -define registers offsets
  -add an index to 'struct ls_pcie' to track next available slot in LUT
  -add function to allocate the next available entry index
  -add function to program a LUT entry

Signed-off-by: Stuart Yoder 
---
-v5: check CONFIG_FSL_LSCH3 instead of SoC specific defines

 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |4 +++
 drivers/pci/pcie_layerscape.c  |   30 
 2 files changed, 34 insertions(+)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 91f3ce8..d04e336 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -86,6 +86,10 @@
 #define PCIE_LUT_BASE  0x8
 #define PCIE_LUT_LCTRL00x7F8
 #define PCIE_LUT_DBG   0x7FC
+#define PCIE_LUT_UDR(n) (0x800 + (n) * 8)
+#define PCIE_LUT_LDR(n) (0x804 + (n) * 8)
+#define PCIE_LUT_ENABLE (1 << 31)
+#define PCIE_LUT_ENTRY_COUNT32
 
 /* Device Configuration */
 #define DCFG_BASE  0x01e0
diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index bb29222..5cc6855 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -93,6 +93,7 @@ struct ls_pcie {
void __iomem *dbi;
void __iomem *va_cfg0;
void __iomem *va_cfg1;
+   int next_lut_index;
struct pci_controller hose;
 };
 
@@ -482,6 +483,34 @@ static void ls_pcie_setup_ep(struct ls_pcie *pcie, struct 
ls_pcie_info *info)
}
 }
 
+#ifdef CONFIG_FSL_LSCH3
+/*
+ * Return next available LUT index.
+ */
+static int ls_pcie_next_lut_index(struct ls_pcie *pcie)
+{
+   if (pcie->next_lut_index < PCIE_LUT_ENTRY_COUNT)
+   return pcie->next_lut_index++;
+   else
+   return -1;  /* LUT is full */
+}
+
+/*
+ * Program a single LUT entry
+ */
+static void ls_pcie_lut_set_mapping(struct ls_pcie *pcie, int index, u32 devid,
+u32 streamid)
+{
+   void __iomem *lut;
+
+   lut = pcie->dbi + PCIE_LUT_BASE;
+
+   /* leave mask as all zeroes, want to match all bits */
+   writel((devid << 16), lut + PCIE_LUT_UDR(index));
+   writel(streamid | PCIE_LUT_ENABLE, lut + PCIE_LUT_LDR(index));
+}
+#endif
+
 int ls_pcie_init_ctrl(int busno, enum srds_prtcl dev, struct ls_pcie_info 
*info)
 {
struct ls_pcie *pcie;
@@ -513,6 +542,7 @@ int ls_pcie_init_ctrl(int busno, enum srds_prtcl dev, 
struct ls_pcie_info *info)
pcie->va_cfg1 = map_physmem(info->cfg1_phys,
info->cfg1_size,
MAP_NOCACHE);
+   pcie->next_lut_index = 0;
 
/* outbound memory */
pci_set_region(>regions[0],
-- 
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] ARM: DRA72-evm: Update mux and VIRTUAL/MANUAL mode timings

[Tom Rini]

On Tue, Mar 08, 2016 at 10:10:20AM +0530, Lokesh Vutla wrote:

> All the mux configurations needs to be done as part of the IODelay
> sequence to avoid glitch. Adding all the mux configuration, MANUAL/VIRTUAL
> mode configuration as needed for DRA72-evm.
> 
> Also update the mux for SD card detect on DRA74-evm.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> Signed-off-by: Vignesh R 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
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] pull request: u-boot-uniphier/master

[Tom Rini]

On Wed, Mar 09, 2016 at 01:18:19AM +0900, Masahiro Yamada wrote:

> Hi Tom,
> 
> This is probably the last PR from me for the v2016.03 release.
> It includes some bug fixes and a minor document update.
> 
> 
> The following changes since commit 08b24722f0ac9159697360faed35d12852592eb3:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-usb (2016-03-04
> 20:53:50 -0500)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-uniphier.git master
> 
> for you to fetch changes up to 5d07648662edf2b994a6433465d472a9a3e89923:
> 
>   ARM: uniphier: allow debug_ll_init() to do nothing for unknown SoCs
> (2016-03-09 01:11:15 +0900)
> 

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

Re: [U-Boot] [PATCH 4/7 v4] pci/layerscape: add support for LUT

[Stuart Yoder]

> -Original Message-
> From: york sun
> Sent: Tuesday, March 08, 2016 1:46 PM
> To: Stuart Yoder ; u-boot@lists.denx.de
> Cc: Prabhakar Kushwaha ; Yang-Leo Li 
> 
> Subject: Re: [PATCH 4/7 v4] pci/layerscape: add support for LUT
> 
> On 03/08/2016 11:36 AM, Stuart Yoder wrote:
> >
> >
> >> -Original Message-
> >> From: york sun
> >> Sent: Tuesday, March 08, 2016 11:30 AM
> >> To: Stuart Yoder ; u-boot@lists.denx.de
> >> Cc: Prabhakar Kushwaha ; Yang-Leo Li 
> >> 
> >> Subject: Re: [PATCH 4/7 v4] pci/layerscape: add support for LUT
> >>
> >> On 03/08/2016 07:56 AM, Stuart Yoder wrote:
> >>> From: Stuart Yoder 
> >>>
> >>> The per-PCI controller LUT (Look-Up-Table) is a 32-entry table
> >>> that maps PCI requester IDs (bus/dev/fun) to a stream ID.
> >>>
> >>> This patch implements infrastructure to enable LUT initialization:
> >>>   -define registers offsets
> >>>   -add an index to 'struct ls_pcie' to track next available slot in LUT
> >>>   -add function to allocate the next available entry index
> >>>   -add function to program a LUT entry
> >>>
> >>> Signed-off-by: Stuart Yoder 
> >>> ---
> >>> -v4: put new support under LS2 #ifdef
> >>>
> >>>  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |4 +++
> >>>  drivers/pci/pcie_layerscape.c  |   30 
> >>> 
> >>>  2 files changed, 34 insertions(+)
> >>>
> >>> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> >> b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> >>> index 91f3ce8..d04e336 100644
> >>> --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> >>> +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> >>> @@ -86,6 +86,10 @@
> >>>  #define PCIE_LUT_BASE0x8
> >>>  #define PCIE_LUT_LCTRL0  0x7F8
> >>>  #define PCIE_LUT_DBG 0x7FC
> >>> +#define PCIE_LUT_UDR(n) (0x800 + (n) * 8)
> >>> +#define PCIE_LUT_LDR(n) (0x804 + (n) * 8)
> >>> +#define PCIE_LUT_ENABLE (1 << 31)
> >>> +#define PCIE_LUT_ENTRY_COUNT32
> >>>
> >>>  /* Device Configuration */
> >>>  #define DCFG_BASE0x01e0
> >>> diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
> >>> index bb29222..8435446 100644
> >>> --- a/drivers/pci/pcie_layerscape.c
> >>> +++ b/drivers/pci/pcie_layerscape.c
> >>> @@ -93,6 +93,7 @@ struct ls_pcie {
> >>>   void __iomem *dbi;
> >>>   void __iomem *va_cfg0;
> >>>   void __iomem *va_cfg1;
> >>> + int next_lut_index;
> >>>   struct pci_controller hose;
> >>>  };
> >>>
> >>> @@ -482,6 +483,34 @@ static void ls_pcie_setup_ep(struct ls_pcie *pcie, 
> >>> struct
> >> ls_pcie_info *info)
> >>>   }
> >>>  }
> >>>
> >>> +#if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
> >>
> >> Would CONFIG_FSL_LSCH3 serve this purpose better? We will have other SoC 
> >> in the
> >> same family.
> >
> > Maybe, I'm open to a common define if we can easily get agreement.
> >
> > I see at least 7 other references to:
> >defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
> >
> > I'd rather not see agreement on a common #define get mixed
> > up in this patch series which is focused on enabling
> > MSIs.  But, perhaps we need to agree on a name and
> > then clean all the common platform references up.
> >
> > I'm not sure I like FSL_LSCH3.  A while back we changed the
> > name of a u-boot directory that had "ch3" in it and changed to:
> > "fsl-layerscape". So, I thought we were moving in the direction
> > of removing references to "ch3".
> >
> > In Linux we use CONFIG_ARCH_LAYERSCAPE to refer to the ARMv8
> > family of SoCs.  While LAYERSCAPE is not ideal, it may be
> > better than CH3 which is a reference to an internal name
> > that no one outside of NXP will ever understand.
> >
> > My vote would be CONFIG_LAYERSCAPE.
> >
> 
> We already have CONFIG_FSL_LSCH3 and CONFIG_FSL_LSCH2 in U-Boot. My concern is
> not the name. If you see your change fits CONFIG_FSL_LSCH3, you can go ahead 
> to
> use it. Or if it only applies to CONFIG_LS2080A and CONFIG_LS2085A, you can 
> keep
> your change. With aother LSCH3 SoC around the corner, I am trying to save you
> the trouble to fix it when that comes.

Sure, makes sense...I'll change to use the existing CH3 define.  I suspect
that the existing references to defined(CONFIG_LS2080A) || 
defined(CONFIG_LS2085A)
should probably change at some point.

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

Re: [U-Boot] [PATCH 4/7 v4] pci/layerscape: add support for LUT

[Stuart Yoder]

> -Original Message-
> From: york sun
> Sent: Tuesday, March 08, 2016 11:30 AM
> To: Stuart Yoder ; u-boot@lists.denx.de
> Cc: Prabhakar Kushwaha ; Yang-Leo Li 
> 
> Subject: Re: [PATCH 4/7 v4] pci/layerscape: add support for LUT
> 
> On 03/08/2016 07:56 AM, Stuart Yoder wrote:
> > From: Stuart Yoder 
> >
> > The per-PCI controller LUT (Look-Up-Table) is a 32-entry table
> > that maps PCI requester IDs (bus/dev/fun) to a stream ID.
> >
> > This patch implements infrastructure to enable LUT initialization:
> >   -define registers offsets
> >   -add an index to 'struct ls_pcie' to track next available slot in LUT
> >   -add function to allocate the next available entry index
> >   -add function to program a LUT entry
> >
> > Signed-off-by: Stuart Yoder 
> > ---
> > -v4: put new support under LS2 #ifdef
> >
> >  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |4 +++
> >  drivers/pci/pcie_layerscape.c  |   30 
> > 
> >  2 files changed, 34 insertions(+)
> >
> > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> > index 91f3ce8..d04e336 100644
> > --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> > +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> > @@ -86,6 +86,10 @@
> >  #define PCIE_LUT_BASE  0x8
> >  #define PCIE_LUT_LCTRL00x7F8
> >  #define PCIE_LUT_DBG   0x7FC
> > +#define PCIE_LUT_UDR(n) (0x800 + (n) * 8)
> > +#define PCIE_LUT_LDR(n) (0x804 + (n) * 8)
> > +#define PCIE_LUT_ENABLE (1 << 31)
> > +#define PCIE_LUT_ENTRY_COUNT32
> >
> >  /* Device Configuration */
> >  #define DCFG_BASE  0x01e0
> > diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
> > index bb29222..8435446 100644
> > --- a/drivers/pci/pcie_layerscape.c
> > +++ b/drivers/pci/pcie_layerscape.c
> > @@ -93,6 +93,7 @@ struct ls_pcie {
> > void __iomem *dbi;
> > void __iomem *va_cfg0;
> > void __iomem *va_cfg1;
> > +   int next_lut_index;
> > struct pci_controller hose;
> >  };
> >
> > @@ -482,6 +483,34 @@ static void ls_pcie_setup_ep(struct ls_pcie *pcie, 
> > struct
> ls_pcie_info *info)
> > }
> >  }
> >
> > +#if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
> 
> Would CONFIG_FSL_LSCH3 serve this purpose better? We will have other SoC in 
> the
> same family.

Maybe, I'm open to a common define if we can easily get agreement.

I see at least 7 other references to:
   defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)

I'd rather not see agreement on a common #define get mixed
up in this patch series which is focused on enabling
MSIs.  But, perhaps we need to agree on a name and 
then clean all the common platform references up.

I'm not sure I like FSL_LSCH3.  A while back we changed the
name of a u-boot directory that had "ch3" in it and changed to:
"fsl-layerscape". So, I thought we were moving in the direction
of removing references to "ch3".

In Linux we use CONFIG_ARCH_LAYERSCAPE to refer to the ARMv8
family of SoCs.  While LAYERSCAPE is not ideal, it may be
better than CH3 which is a reference to an internal name
that no one outside of NXP will ever understand.

My vote would be CONFIG_LAYERSCAPE.

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

Re: [U-Boot] [PATCH 4/7 v4] pci/layerscape: add support for LUT

[york sun]

On 03/08/2016 11:36 AM, Stuart Yoder wrote:
> 
> 
>> -Original Message-
>> From: york sun
>> Sent: Tuesday, March 08, 2016 11:30 AM
>> To: Stuart Yoder ; u-boot@lists.denx.de
>> Cc: Prabhakar Kushwaha ; Yang-Leo Li 
>> 
>> Subject: Re: [PATCH 4/7 v4] pci/layerscape: add support for LUT
>>
>> On 03/08/2016 07:56 AM, Stuart Yoder wrote:
>>> From: Stuart Yoder 
>>>
>>> The per-PCI controller LUT (Look-Up-Table) is a 32-entry table
>>> that maps PCI requester IDs (bus/dev/fun) to a stream ID.
>>>
>>> This patch implements infrastructure to enable LUT initialization:
>>>   -define registers offsets
>>>   -add an index to 'struct ls_pcie' to track next available slot in LUT
>>>   -add function to allocate the next available entry index
>>>   -add function to program a LUT entry
>>>
>>> Signed-off-by: Stuart Yoder 
>>> ---
>>> -v4: put new support under LS2 #ifdef
>>>
>>>  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |4 +++
>>>  drivers/pci/pcie_layerscape.c  |   30 
>>> 
>>>  2 files changed, 34 insertions(+)
>>>
>>> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
>> b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
>>> index 91f3ce8..d04e336 100644
>>> --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
>>> +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
>>> @@ -86,6 +86,10 @@
>>>  #define PCIE_LUT_BASE  0x8
>>>  #define PCIE_LUT_LCTRL00x7F8
>>>  #define PCIE_LUT_DBG   0x7FC
>>> +#define PCIE_LUT_UDR(n) (0x800 + (n) * 8)
>>> +#define PCIE_LUT_LDR(n) (0x804 + (n) * 8)
>>> +#define PCIE_LUT_ENABLE (1 << 31)
>>> +#define PCIE_LUT_ENTRY_COUNT32
>>>
>>>  /* Device Configuration */
>>>  #define DCFG_BASE  0x01e0
>>> diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
>>> index bb29222..8435446 100644
>>> --- a/drivers/pci/pcie_layerscape.c
>>> +++ b/drivers/pci/pcie_layerscape.c
>>> @@ -93,6 +93,7 @@ struct ls_pcie {
>>> void __iomem *dbi;
>>> void __iomem *va_cfg0;
>>> void __iomem *va_cfg1;
>>> +   int next_lut_index;
>>> struct pci_controller hose;
>>>  };
>>>
>>> @@ -482,6 +483,34 @@ static void ls_pcie_setup_ep(struct ls_pcie *pcie, 
>>> struct
>> ls_pcie_info *info)
>>> }
>>>  }
>>>
>>> +#if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
>>
>> Would CONFIG_FSL_LSCH3 serve this purpose better? We will have other SoC in 
>> the
>> same family.
> 
> Maybe, I'm open to a common define if we can easily get agreement.
> 
> I see at least 7 other references to:
>defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
> 
> I'd rather not see agreement on a common #define get mixed
> up in this patch series which is focused on enabling
> MSIs.  But, perhaps we need to agree on a name and 
> then clean all the common platform references up.
> 
> I'm not sure I like FSL_LSCH3.  A while back we changed the
> name of a u-boot directory that had "ch3" in it and changed to:
> "fsl-layerscape". So, I thought we were moving in the direction
> of removing references to "ch3".
> 
> In Linux we use CONFIG_ARCH_LAYERSCAPE to refer to the ARMv8
> family of SoCs.  While LAYERSCAPE is not ideal, it may be
> better than CH3 which is a reference to an internal name
> that no one outside of NXP will ever understand.
> 
> My vote would be CONFIG_LAYERSCAPE.
> 

We already have CONFIG_FSL_LSCH3 and CONFIG_FSL_LSCH2 in U-Boot. My concern is
not the name. If you see your change fits CONFIG_FSL_LSCH3, you can go ahead to
use it. Or if it only applies to CONFIG_LS2080A and CONFIG_LS2085A, you can keep
your change. With aother LSCH3 SoC around the corner, I am trying to save you
the trouble to fix it when that comes.

York


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

Re: [U-Boot] [RFC] armv8: layerscape: Add support of u-boot device tree fix-up

[Scott Wood]

On Tue, 2016-02-23 at 04:09 +, Prabhakar Kushwaha wrote:
> > -Original Message-
> > From: Scott Wood [mailto:o...@buserror.net]
> > Sent: Tuesday, February 23, 2016 6:52 AM
> > To: Prabhakar Kushwaha ; u-
> > b...@lists.denx.de
> > Cc: york sun ; Priyanka Jain 
> > Subject: Re: [RFC] armv8: layerscape: Add support of u-boot device tree
> > fix-
> > up
> > 
> > Where do you check that the device tree fits in OCRAM?  What about when
> > SPL is occupying OCRAM?  Does the device tree get used with SPL (I don't
> > think we were using FDT control at all the last time I worked with SPL on
> > these chips)?
> > 
> 
> I checked ls2085ardb dtb size in Linux. It is ~30K. So from 0xfff0 to 2
> there is enough space.
> 
> For SPL. Assumption is SPL never use dts. It will only be used by u-boot. 
> Once control is transferred to u-boot, things work as it is like NOR boot. 

I don't think that's a good assumption, given that I just saw a patch posted
regarding SPL_OF_CONTROL.

-Scott

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

Re: [U-Boot] rockchip: make configure_emmc() empty for Firefly-RK3288

[Vagrant Cascadian]

On 2016-03-05, FUKAUMI Naoki wrote:
> on v2016.03-rc3, size of SPL image compiled by gcc 5.3.0 is too large for
> Firefly-RK3288. (it's fine for Rock2)
...
> to reduce size of SPL image, this patch makes configure_emmc() empty for
> Firefly-RK3288 as same as Rock2.
>
> Signed-off-by: FUKAUMI Naoki 
> Acked-by: Simon Glass 

Fixed booting on my Firefly-RK3288.

Tested-By: Vagrant Cascadian 

> ---
>  arch/arm/mach-rockchip/rk3288-board-spl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-rockchip/rk3288-board-spl.c 
> b/arch/arm/mach-rockchip/rk3288-board-spl.c
> index 6a54368..e133cca 100644
> --- a/arch/arm/mach-rockchip/rk3288-board-spl.c
> +++ b/arch/arm/mach-rockchip/rk3288-board-spl.c
> @@ -114,7 +114,7 @@ static void configure_l2ctlr(void)
>  #ifdef CONFIG_SPL_MMC_SUPPORT
>  static int configure_emmc(struct udevice *pinctrl)
>  {
> -#ifndef CONFIG_TARGET_ROCK2
> +#if !defined(CONFIG_TARGET_ROCK2) && !defined(CONFIG_TARGET_FIREFLY_RK3288)
>   struct gpio_desc desc;
>   int ret;
>  


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

Re: [U-Boot] [PATCH 2/2] driver/ddr/fsl: Add workaround for erratum A-009803

[york sun]

Shengzhou,

On 03/07/2016 10:01 PM, Shengzhou Liu wrote:
> During the initial DDR training, false parity errors may be detected.
> This can lead to the ERR_DETECT[APE], ERR_DETECT[MME] bits getting
> set during DDR training and the DDR could enter a bad state to try
> and recover since it thinks a parity error has occurred.

Please rephrase this sentence. It is too long and confusing. It would be helpful
to list the boards tested.

York

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

Re: [U-Boot] [PATCH 1/2] driver/ddr/fsl: add command/address parity for DDR4 UDIMM

[york sun]

Shengzhou,

Subject is inaccurate. Not only UDIMM for DDR4.

On 03/07/2016 10:01 PM, Shengzhou Liu wrote:
> Add support of command/address parity for DDR4 UDIMM or discrete memory.
> It requires to configurate corresponding MR5[2:0] and TIMING_CFG_7[PAR_LAT].
> Parity can be turned on/off by hwconfig, e.g. hwconfig=fsl_ddr:parity=on.
> 
> Signed-off-by: Shengzhou Liu 
> ---
>  doc/README.fsl-ddr  |  8 +++
>  drivers/ddr/fsl/ctrl_regs.c | 52 
> +++--
>  drivers/ddr/fsl/options.c   | 12 +--
>  include/fsl_ddr_sdram.h | 11 +-
>  4 files changed, 73 insertions(+), 10 deletions(-)
> 
> diff --git a/doc/README.fsl-ddr b/doc/README.fsl-ddr
> index cd71ec8..80f91d3 100644
> --- a/doc/README.fsl-ddr
> +++ b/doc/README.fsl-ddr
> @@ -143,6 +143,14 @@ platform
>  
>  
> hwconfig=fsl_ddr:addr_hash=true,ctlr_intlv=cacheline,bank_intlv=cs0_cs1_cs2_cs3,ecc=on
>  
> +
> +Memory address parity on/off
> +
> +address parity can be turned on/off by hwconfig, it's disabled by default.
> +Syntax is:
> +hwconfig=fsl_ddr:parity=on
> +
> +
>  Table for dynamic ODT for DDR3
>  ==
>  For single-slot system with quad-rank DIMM and dual-slot system, dynamic ODT 
> may
> diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c
> index 0bfcd34..1f5b9fc 100644
> --- a/drivers/ddr/fsl/ctrl_regs.c
> +++ b/drivers/ddr/fsl/ctrl_regs.c
> @@ -895,12 +895,10 @@ static void set_ddr_sdram_cfg_2(const unsigned int 
> ctrl_num,
>   slow = get_ddr_freq(ctrl_num) < 124900;
>  #endif
>  
> - if (popts->registered_dimm_en) {
> + ap_en = popts->ap_en;
> +
> + if (popts->registered_dimm_en)
>   rcw_en = 1;
> - ap_en = popts->ap_en;
> - } else {
> - ap_en = 0;
> - }
>  

This change removes the protection. popts->ap_en can be set by board ddr
setting. Without checking popts->registered_dimm_en, this could set ap_en
incorrectly. This was written for DDR3 RDIMM. Since DDR4 allows address parity
for UDIMM, I think it is better to check for DDR3.


>   x4_en = popts->x4_en ? 1 : 0;
>  
> @@ -1135,6 +1133,7 @@ static void set_ddr_sdram_mode_9(fsl_ddr_cfg_regs_t 
> *ddr,
>   unsigned short esdmode5;/* Extended SDRAM mode 5 */
>   int rtt_park = 0;
>   bool four_cs = false;
> + const unsigned int mclk_ps = get_memory_clk_period_ps(0);
>  
>  #if CONFIG_CHIP_SELECTS_PER_CTRL == 4
>   if ((ddr->cs[0].config & SDRAM_CS_CONFIG_EN) &&
> @@ -1150,6 +1149,19 @@ static void set_ddr_sdram_mode_9(fsl_ddr_cfg_regs_t 
> *ddr,
>   esdmode5 = 0x0400;  /* Data mask enabled */
>   }
>  
> + /* set command/address parity latency */
> + if (ddr->ddr_sdram_cfg_2 & SDRAM_CFG2_AP_EN) {
> + if (mclk_ps >= 935) {
> + /* for DDR4-1600/1866/2133 */
> + esdmode5 |= DDR_MR5_CA_PARITY_LAT_4_CLK;
> + } else if (mclk_ps >= 833) {
> + /* for DDR4-2400 */
> + esdmode5 |= DDR_MR5_CA_PARITY_LAT_5_CLK;
> + } else {
> + printf("parity: mclk_ps = %d not supported\n", mclk_ps);
> + }
> + }
> +
>   ddr->ddr_sdram_mode_9 = (0
>| ((esdmode4 & 0x) << 16)
>| ((esdmode5 & 0x) << 0)
> @@ -1170,6 +1182,19 @@ static void set_ddr_sdram_mode_9(fsl_ddr_cfg_regs_t 
> *ddr,
>   } else {
>   esdmode5 = 0x0400;
>   }
> +
> + if (ddr->ddr_sdram_cfg_2 & SDRAM_CFG2_AP_EN) {
> + if (mclk_ps >= 935) {
> + /* for DDR4-1600/1866/2133 */
> + esdmode5 |= DDR_MR5_CA_PARITY_LAT_4_CLK;
> + } else if (mclk_ps >= 833) {
> + /* for DDR4-2400 */
> + esdmode5 |= DDR_MR5_CA_PARITY_LAT_5_CLK;
> + } else {
> + printf("parity: the speed reserved\n");
> + }
> + }
> +
>   switch (i) {
>   case 1:
>   ddr->ddr_sdram_mode_11 = (0
> @@ -1925,12 +1950,25 @@ static void set_timing_cfg_7(const unsigned int 
> ctrl_num,
>const common_timing_params_t *common_dimm)
>  {
>   unsigned int txpr, tcksre, tcksrx;
> - unsigned int cke_rst, cksre, cksrx, par_lat, cs_to_cmd;
> + unsigned int cke_rst, cksre, cksrx, par_lat = 0, cs_to_cmd;
> + const unsigned int mclk_ps = get_memory_clk_period_ps(ctrl_num);
>  
>   txpr = max(5U, picos_to_mclk(ctrl_num, common_dimm->trfc1_ps + 1));
>   tcksre = max(5U, picos_to_mclk(ctrl_num, 

Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Stefan Roese]

Hi Simon,

On 08.03.2016 17:54, Simon Glass wrote:
> Hi Stefan,
> 
> On 8 March 2016 at 09:45, Stefan Roese  wrote:
>> Hi Simon, Hi Bin,
>>
>> On 12.08.2015 05:54, Simon Glass wrote:
>>> +Gabriel
>>>
>>> Hi Andrew,
>>>
>>> On 11 August 2015 at 09:20, Andrew Bradford  
>>> wrote:
 Hi Simon,

 On 08/11 08:06, Simon Glass wrote:
> Hi Andrew,
>
> On 11 August 2015 at 06:08, Andrew Bradford  
> wrote:
>> Hi Simon,
>>
>> On 08/10 21:07, Simon Glass wrote:
>>> Hi Bin,
>>>
>>> On 10 August 2015 at 20:53, Bin Meng  wrote:
 Hi Andrew,

 On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford
  wrote:
> Hi Bin,
>
> On 08/09 10:52, Bin Meng wrote:
>> Hi Andrew,
>>
>> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
>>  wrote:
>>> Hi Simon,
>>>
>>> On 08/08 10:18, Simon Glass wrote:
 Hi,

 On 7 August 2015 at 06:44, Bin Meng  wrote:
> On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
>  wrote:
>> From: Andrew Bradford 
>>
>> Allow for configuration of FSP UPD from the device tree which 
>> will
>> override any settings which the FSP was built with itself.
>>
>> Modify the MinnowMax and BayleyBay boards to transfer sensible 
>> UPD
>> settings from the Intel FSPv4 Gold release to the respective dts 
>> files,
>> with the condition that the memory-down parameters for MinnowMax 
>> are
>> also used.
>>
>> Signed-off-by: Andrew Bradford 
>> ---
>>
>
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 
>

 Acked-by: Simon Glass 
 Tested on minnowmax:
 Tested-by: Simon Glass 

 I found that I need to remove two properties from the 
 minnowmax.dts:

 - fsp,enable-xhci needs to be removed as this does not work in 
 U-Boot
 at present and stops EHCI from working
 - fsp,mrc-debug-msg needs to be removed to prevent debug 
 information
 being displayed

 I plan to apply this with these changes - please let me know if 
 this
 doesn't suit.
>>>
>>> I'm OK with disabling xhci and the MRC debug output in the FSP.
>>>
>>> But if xhci is disabled then I believe when Linux boots that the 
>>> USB 3.0
>>> port on Minnow Max will only act as a USB 2.0 port.  That u-boot 
>>> doesn't
>>> yet have working XHCI on E3800 means there is a tradeoff and I 
>>> wasn't
>>> sure which was a better choice.
>>
>> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
>> works, I'd rather we keep fsp,enable-xhci in the U-Boot.
>
> I believe that the xhci port does work on Minnow Max in Linux but I do
> not have a board so I'm unable to test, sorry.
>

 OK, my test shows that ehci works fine in U-Boot on Bayley Bay.

 Hi Simon,

 What do you think regarding to xhci vs. ehci in U-Boot?
>>>
>>> The problem is that USB is then broken in U-Boot. I think it is better
>>> to limit the speed for the moment until we have that fixed. It is
>>> quite useful to be able to use a keyboard or USB stick in U-Boot.
>>>
>>> With my testing the bottom (blue) port works fine but the top port
>>> does not. This happens regardless of the xhci setting.
>>
>> Minnowmax has a USB power switch enable which determines if the VBUS2
>> net is turned on or not, which will supply or not supply power to the
>> USB 2.0 port.  The blue USB 3.0 port also has an enable.  Both enables
>> and the USB ports themselves are located on page 16 of the schematic
>> that I have.
>>
>> The switches to enable the VBUS for each port are active high and pulled
>> down.  So to turn them on, I believe that's the point of the pinmuxing
>> and GPIO settings which are used in the minnowmax.dts.  Can you verify
>> if these are correctly turning on VBUS2 (since it sounds like they are
>> turning on VBUS1)?  If not, when you turn these GPIO on manually, does
>> the USB 2.0 port work correctly?
>
> I see power on the bottom 

Re: [U-Boot] [PATCH 4/7 v4] pci/layerscape: add support for LUT

[york sun]

On 03/08/2016 07:56 AM, Stuart Yoder wrote:
> From: Stuart Yoder 
> 
> The per-PCI controller LUT (Look-Up-Table) is a 32-entry table
> that maps PCI requester IDs (bus/dev/fun) to a stream ID.
> 
> This patch implements infrastructure to enable LUT initialization:
>   -define registers offsets
>   -add an index to 'struct ls_pcie' to track next available slot in LUT
>   -add function to allocate the next available entry index
>   -add function to program a LUT entry
> 
> Signed-off-by: Stuart Yoder 
> ---
> -v4: put new support under LS2 #ifdef
> 
>  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |4 +++
>  drivers/pci/pcie_layerscape.c  |   30 
> 
>  2 files changed, 34 insertions(+)
> 
> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
> b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> index 91f3ce8..d04e336 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> @@ -86,6 +86,10 @@
>  #define PCIE_LUT_BASE0x8
>  #define PCIE_LUT_LCTRL0  0x7F8
>  #define PCIE_LUT_DBG 0x7FC
> +#define PCIE_LUT_UDR(n) (0x800 + (n) * 8)
> +#define PCIE_LUT_LDR(n) (0x804 + (n) * 8)
> +#define PCIE_LUT_ENABLE (1 << 31)
> +#define PCIE_LUT_ENTRY_COUNT32
>  
>  /* Device Configuration */
>  #define DCFG_BASE0x01e0
> diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
> index bb29222..8435446 100644
> --- a/drivers/pci/pcie_layerscape.c
> +++ b/drivers/pci/pcie_layerscape.c
> @@ -93,6 +93,7 @@ struct ls_pcie {
>   void __iomem *dbi;
>   void __iomem *va_cfg0;
>   void __iomem *va_cfg1;
> + int next_lut_index;
>   struct pci_controller hose;
>  };
>  
> @@ -482,6 +483,34 @@ static void ls_pcie_setup_ep(struct ls_pcie *pcie, 
> struct ls_pcie_info *info)
>   }
>  }
>  
> +#if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)

Would CONFIG_FSL_LSCH3 serve this purpose better? We will have other SoC in the
same family.

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

Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Simon Glass]

Hi Stefan,

On 8 March 2016 at 09:45, Stefan Roese  wrote:
> Hi Simon, Hi Bin,
>
> On 12.08.2015 05:54, Simon Glass wrote:
>> +Gabriel
>>
>> Hi Andrew,
>>
>> On 11 August 2015 at 09:20, Andrew Bradford  
>> wrote:
>>> Hi Simon,
>>>
>>> On 08/11 08:06, Simon Glass wrote:
 Hi Andrew,

 On 11 August 2015 at 06:08, Andrew Bradford  
 wrote:
> Hi Simon,
>
> On 08/10 21:07, Simon Glass wrote:
>> Hi Bin,
>>
>> On 10 August 2015 at 20:53, Bin Meng  wrote:
>>> Hi Andrew,
>>>
>>> On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford
>>>  wrote:
 Hi Bin,

 On 08/09 10:52, Bin Meng wrote:
> Hi Andrew,
>
> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
>  wrote:
>> Hi Simon,
>>
>> On 08/08 10:18, Simon Glass wrote:
>>> Hi,
>>>
>>> On 7 August 2015 at 06:44, Bin Meng  wrote:
 On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
  wrote:
> From: Andrew Bradford 
>
> Allow for configuration of FSP UPD from the device tree which will
> override any settings which the FSP was built with itself.
>
> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
> settings from the Intel FSPv4 Gold release to the respective dts 
> files,
> with the condition that the memory-down parameters for MinnowMax 
> are
> also used.
>
> Signed-off-by: Andrew Bradford 
> ---
>

 Reviewed-by: Bin Meng 
 Tested-by: Bin Meng 

>>>
>>> Acked-by: Simon Glass 
>>> Tested on minnowmax:
>>> Tested-by: Simon Glass 
>>>
>>> I found that I need to remove two properties from the minnowmax.dts:
>>>
>>> - fsp,enable-xhci needs to be removed as this does not work in 
>>> U-Boot
>>> at present and stops EHCI from working
>>> - fsp,mrc-debug-msg needs to be removed to prevent debug information
>>> being displayed
>>>
>>> I plan to apply this with these changes - please let me know if this
>>> doesn't suit.
>>
>> I'm OK with disabling xhci and the MRC debug output in the FSP.
>>
>> But if xhci is disabled then I believe when Linux boots that the USB 
>> 3.0
>> port on Minnow Max will only act as a USB 2.0 port.  That u-boot 
>> doesn't
>> yet have working XHCI on E3800 means there is a tradeoff and I wasn't
>> sure which was a better choice.
>
> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
> works, I'd rather we keep fsp,enable-xhci in the U-Boot.

 I believe that the xhci port does work on Minnow Max in Linux but I do
 not have a board so I'm unable to test, sorry.

>>>
>>> OK, my test shows that ehci works fine in U-Boot on Bayley Bay.
>>>
>>> Hi Simon,
>>>
>>> What do you think regarding to xhci vs. ehci in U-Boot?
>>
>> The problem is that USB is then broken in U-Boot. I think it is better
>> to limit the speed for the moment until we have that fixed. It is
>> quite useful to be able to use a keyboard or USB stick in U-Boot.
>>
>> With my testing the bottom (blue) port works fine but the top port
>> does not. This happens regardless of the xhci setting.
>
> Minnowmax has a USB power switch enable which determines if the VBUS2
> net is turned on or not, which will supply or not supply power to the
> USB 2.0 port.  The blue USB 3.0 port also has an enable.  Both enables
> and the USB ports themselves are located on page 16 of the schematic
> that I have.
>
> The switches to enable the VBUS for each port are active high and pulled
> down.  So to turn them on, I believe that's the point of the pinmuxing
> and GPIO settings which are used in the minnowmax.dts.  Can you verify
> if these are correctly turning on VBUS2 (since it sounds like they are
> turning on VBUS1)?  If not, when you turn these GPIO on manually, does
> the USB 2.0 port work correctly?

 I see power on the bottom port but not the top one.
>>>
>>> OK, that's odd, but likely can be fixed with changes to the pin mux and
>>> pad settings in the dts.  I believe that the "pad-offset" for
>>> pin_usb_host_en1@0 is wrong and that it should be 0x250 instead of
>>> 0x258.
>>>
>>> diff 

Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Stefan Roese]

Hi Simon, Hi Bin,

On 12.08.2015 05:54, Simon Glass wrote:
> +Gabriel
> 
> Hi Andrew,
> 
> On 11 August 2015 at 09:20, Andrew Bradford  
> wrote:
>> Hi Simon,
>>
>> On 08/11 08:06, Simon Glass wrote:
>>> Hi Andrew,
>>>
>>> On 11 August 2015 at 06:08, Andrew Bradford  
>>> wrote:
 Hi Simon,

 On 08/10 21:07, Simon Glass wrote:
> Hi Bin,
>
> On 10 August 2015 at 20:53, Bin Meng  wrote:
>> Hi Andrew,
>>
>> On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford
>>  wrote:
>>> Hi Bin,
>>>
>>> On 08/09 10:52, Bin Meng wrote:
 Hi Andrew,

 On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
  wrote:
> Hi Simon,
>
> On 08/08 10:18, Simon Glass wrote:
>> Hi,
>>
>> On 7 August 2015 at 06:44, Bin Meng  wrote:
>>> On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
>>>  wrote:
 From: Andrew Bradford 

 Allow for configuration of FSP UPD from the device tree which will
 override any settings which the FSP was built with itself.

 Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
 settings from the Intel FSPv4 Gold release to the respective dts 
 files,
 with the condition that the memory-down parameters for MinnowMax 
 are
 also used.

 Signed-off-by: Andrew Bradford 
 ---

>>>
>>> Reviewed-by: Bin Meng 
>>> Tested-by: Bin Meng 
>>>
>>
>> Acked-by: Simon Glass 
>> Tested on minnowmax:
>> Tested-by: Simon Glass 
>>
>> I found that I need to remove two properties from the minnowmax.dts:
>>
>> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
>> at present and stops EHCI from working
>> - fsp,mrc-debug-msg needs to be removed to prevent debug information
>> being displayed
>>
>> I plan to apply this with these changes - please let me know if this
>> doesn't suit.
>
> I'm OK with disabling xhci and the MRC debug output in the FSP.
>
> But if xhci is disabled then I believe when Linux boots that the USB 
> 3.0
> port on Minnow Max will only act as a USB 2.0 port.  That u-boot 
> doesn't
> yet have working XHCI on E3800 means there is a tradeoff and I wasn't
> sure which was a better choice.

 Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
 works, I'd rather we keep fsp,enable-xhci in the U-Boot.
>>>
>>> I believe that the xhci port does work on Minnow Max in Linux but I do
>>> not have a board so I'm unable to test, sorry.
>>>
>>
>> OK, my test shows that ehci works fine in U-Boot on Bayley Bay.
>>
>> Hi Simon,
>>
>> What do you think regarding to xhci vs. ehci in U-Boot?
>
> The problem is that USB is then broken in U-Boot. I think it is better
> to limit the speed for the moment until we have that fixed. It is
> quite useful to be able to use a keyboard or USB stick in U-Boot.
>
> With my testing the bottom (blue) port works fine but the top port
> does not. This happens regardless of the xhci setting.

 Minnowmax has a USB power switch enable which determines if the VBUS2
 net is turned on or not, which will supply or not supply power to the
 USB 2.0 port.  The blue USB 3.0 port also has an enable.  Both enables
 and the USB ports themselves are located on page 16 of the schematic
 that I have.

 The switches to enable the VBUS for each port are active high and pulled
 down.  So to turn them on, I believe that's the point of the pinmuxing
 and GPIO settings which are used in the minnowmax.dts.  Can you verify
 if these are correctly turning on VBUS2 (since it sounds like they are
 turning on VBUS1)?  If not, when you turn these GPIO on manually, does
 the USB 2.0 port work correctly?
>>>
>>> I see power on the bottom port but not the top one.
>>
>> OK, that's odd, but likely can be fixed with changes to the pin mux and
>> pad settings in the dts.  I believe that the "pad-offset" for
>> pin_usb_host_en1@0 is wrong and that it should be 0x250 instead of
>> 0x258.
>>
>> diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
>> index d0c0fe6..4988163 100644
>> --- a/arch/x86/dts/minnowmax.dts
>> +++ b/arch/x86/dts/minnowmax.dts
>> @@ -39,7 +39,7 @@
>>
>>

[U-Boot] pull request: u-boot-uniphier/master

[Masahiro Yamada]

Hi Tom,

This is probably the last PR from me for the v2016.03 release.
It includes some bug fixes and a minor document update.


The following changes since commit 08b24722f0ac9159697360faed35d12852592eb3:

  Merge branch 'master' of git://git.denx.de/u-boot-usb (2016-03-04
20:53:50 -0500)

are available in the git repository at:


  git://git.denx.de/u-boot-uniphier.git master

for you to fetch changes up to 5d07648662edf2b994a6433465d472a9a3e89923:

  ARM: uniphier: allow debug_ll_init() to do nothing for unknown SoCs
(2016-03-09 01:11:15 +0900)


Masahiro Yamada (5):
  ARM: uniphier: document how-to-build for Ace and Sanji boards
  ARM: uniphier: fix build error when CONFIG_CMD_DDRMPHY_DUMP=y
  pinctrl: uniphier: set input-enable before pin-muxing
  pinctrl: uniphier: guard uniphier directory with CONFIG_PINCTRL_UNIPHIER
  ARM: uniphier: allow debug_ll_init() to do nothing for unknown SoCs

 arch/arm/mach-uniphier/arm32/debug_ll.S  |  1 +
 arch/arm/mach-uniphier/dram/cmd_ddrmphy.c| 18 ++
 doc/README.uniphier  |  8 
 drivers/pinctrl/Makefile |  2 +-
 drivers/pinctrl/uniphier/Kconfig | 14 +++---
 drivers/pinctrl/uniphier/Makefile|  2 +-
 drivers/pinctrl/uniphier/pinctrl-uniphier-core.c |  6 +++---
 7 files changed, 23 insertions(+), 28 deletions(-)


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

Re: [U-Boot] [PATCH] ARM: uniphier: allow debug_ll_init() to do nothing for unknown SoCs

[Masahiro Yamada]

2016-03-07 20:29 GMT+09:00 Masahiro Yamada :
> This function should just return for unknown SoCs rather than writing
> unexpected values to registers.
>
> Signed-off-by: Masahiro Yamada 

Applied to u-boot-uniphier/master.

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

Re: [U-Boot] [PATCH] pinctrl: uniphier: guard uniphier directory with CONFIG_PINCTRL_UNIPHIER

[Masahiro Yamada]

2016-03-04 15:56 GMT+09:00 Masahiro Yamada :
> CONFIG_PINCTRL_UNIPHIER is more suitable than CONFIG_ARCH_UNIPHIER
> to guard the drivers/pinctrl/uniphier directory.
>
> The current CONFIG_PINCTRL_UNIPHIER_CORE is a bit long, so rename it
> into CONFIG_PINCTRL_UNIPHIER.
>
> Signed-off-by: Masahiro Yamada 


Applied to u-boot-uniphier/master.


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

Re: [U-Boot] [PATCH] pinctrl: uniphier: set input-enable before pin-muxing

[Masahiro Yamada]

2016-03-04 15:56 GMT+09:00 Masahiro Yamada :
> While IECTRL is disabled, input signals are pulled-down internally.
> If pin-muxing is set up first, glitch signals (Low to High transition)
> might be input to hardware blocks.
>
> Bad case scenario:
> [1] The hardware block is already running before pinctrl is handled.
>(the reset is de-asserted by default or by a firmware, for example)
> [2] The pin-muxing is set up.  The input signals to hardware block
>are pulled-down by the chip-internal biasing.
> [3] The pins are input-enabled.  The signals from the board reach the
> hardware block.
>
> Actually, one invalid character is input to the UART blocks for such
> SoCs as PH1-LD4, PH1-sLD8, where UART devices start to run at the
> power on reset.
>
> To avoid such problems, pins should be input-enabled before muxing.
>
> [ ported from Linux commit bac7f4c1bf5e7c6ccd5bb71edc015b26c77f7460 ]
>
> Fixes: 5dc626f83619 ("pinctrl: uniphier: add UniPhier pinctrl core support")
> Signed-off-by: Masahiro Yamada 


Applied to u-boot-uniphier/master.


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

Re: [U-Boot] [PATCH] ARM: uniphier: fix build error when CONFIG_CMD_DDRMPHY_DUMP=y

[Masahiro Yamada]

2016-03-04 15:54 GMT+09:00 Masahiro Yamada :
> The build fails if compiled with CONFIG_CMD_DDRMPHY_DUMP=y since commit
> 46abfcc99e04 ("ARM: uniphier: rework struct uniphier_board_data").
>
> Fixes: 46abfcc99e04 ("ARM: uniphier: rework struct uniphier_board_data")
> Signed-off-by: Masahiro Yamada 

Applied to u-boot-uniphier/master.
-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: uniphier: document how-to-build for Ace and Sanji boards

[Masahiro Yamada]

2016-03-01 13:10 GMT+09:00 Masahiro Yamada :
> Signed-off-by: Masahiro Yamada 

Applied to u-boot-uniphier/master.



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

Re: [U-Boot] [PATCH] ARM: DRA72-evm: Update mux and VIRTUAL/MANUAL mode timings

[Tom Rini]

On Tue, Mar 08, 2016 at 10:10:20AM +0530, Lokesh Vutla wrote:

> All the mux configurations needs to be done as part of the IODelay
> sequence to avoid glitch. Adding all the mux configuration, MANUAL/VIRTUAL
> mode configuration as needed for DRA72-evm.
> 
> Also update the mux for SD card detect on DRA74-evm.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> Signed-off-by: Vignesh R 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
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 3/7 v4] pci: make pci_get_hose_head() available to external users

[Stuart Yoder]

From: Stuart Yoder 

put pci_get_hose_head() prototype in header so it is available to
external users-- allowing them to find and iterate over all pci controllers

Signed-off-by: Stuart Yoder 
---
-v4: no changes

 include/pci.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/include/pci.h b/include/pci.h
index 68548b0..8698056 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -700,6 +700,7 @@ extern void *pci_map_bar(pci_dev_t pdev, int bar, int 
flags);
 extern void pci_register_hose(struct pci_controller* hose);
 extern struct pci_controller* pci_bus_to_hose(int bus);
 extern struct pci_controller *find_hose_by_cfg_addr(void *cfg_addr);
+extern struct pci_controller *pci_get_hose_head(void);
 
 extern int pci_skip_dev(struct pci_controller *hose, pci_dev_t dev);
 extern int pci_hose_scan(struct pci_controller *hose);
-- 
1.7.9.5

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

[U-Boot] [PATCH 4/7 v4] pci/layerscape: add support for LUT

[Stuart Yoder]

From: Stuart Yoder 

The per-PCI controller LUT (Look-Up-Table) is a 32-entry table
that maps PCI requester IDs (bus/dev/fun) to a stream ID.

This patch implements infrastructure to enable LUT initialization:
  -define registers offsets
  -add an index to 'struct ls_pcie' to track next available slot in LUT
  -add function to allocate the next available entry index
  -add function to program a LUT entry

Signed-off-by: Stuart Yoder 
---
-v4: put new support under LS2 #ifdef

 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |4 +++
 drivers/pci/pcie_layerscape.c  |   30 
 2 files changed, 34 insertions(+)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 91f3ce8..d04e336 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -86,6 +86,10 @@
 #define PCIE_LUT_BASE  0x8
 #define PCIE_LUT_LCTRL00x7F8
 #define PCIE_LUT_DBG   0x7FC
+#define PCIE_LUT_UDR(n) (0x800 + (n) * 8)
+#define PCIE_LUT_LDR(n) (0x804 + (n) * 8)
+#define PCIE_LUT_ENABLE (1 << 31)
+#define PCIE_LUT_ENTRY_COUNT32
 
 /* Device Configuration */
 #define DCFG_BASE  0x01e0
diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index bb29222..8435446 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -93,6 +93,7 @@ struct ls_pcie {
void __iomem *dbi;
void __iomem *va_cfg0;
void __iomem *va_cfg1;
+   int next_lut_index;
struct pci_controller hose;
 };
 
@@ -482,6 +483,34 @@ static void ls_pcie_setup_ep(struct ls_pcie *pcie, struct 
ls_pcie_info *info)
}
 }
 
+#if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
+/*
+ * Return next available LUT index.
+ */
+static int ls_pcie_next_lut_index(struct ls_pcie *pcie)
+{
+   if (pcie->next_lut_index < PCIE_LUT_ENTRY_COUNT)
+   return pcie->next_lut_index++;
+   else
+   return -1;  /* LUT is full */
+}
+
+/*
+ * Program a single LUT entry
+ */
+static void ls_pcie_lut_set_mapping(struct ls_pcie *pcie, int index, u32 devid,
+u32 streamid)
+{
+   void __iomem *lut;
+
+   lut = pcie->dbi + PCIE_LUT_BASE;
+
+   /* leave mask as all zeroes, want to match all bits */
+   writel((devid << 16), lut + PCIE_LUT_UDR(index));
+   writel(streamid | PCIE_LUT_ENABLE, lut + PCIE_LUT_LDR(index));
+}
+#endif
+
 int ls_pcie_init_ctrl(int busno, enum srds_prtcl dev, struct ls_pcie_info 
*info)
 {
struct ls_pcie *pcie;
@@ -513,6 +542,7 @@ int ls_pcie_init_ctrl(int busno, enum srds_prtcl dev, 
struct ls_pcie_info *info)
pcie->va_cfg1 = map_physmem(info->cfg1_phys,
info->cfg1_size,
MAP_NOCACHE);
+   pcie->next_lut_index = 0;
 
/* outbound memory */
pci_set_region(>regions[0],
-- 
1.7.9.5

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

[U-Boot] [PATCH 0/7 v4] support mapping PCI device ids to stream ids for MSIs

[Stuart Yoder]

From: Stuart Yoder 

A binding for PCI nodes has been finalized specifying how PCI
device IDs can be mapped to MSI specifiers.  See
Documentation/devicetree/bindings/pci/pci-msi.txt in the kernel.

For ls2080a and similar Layerscape SoCs, the MSI specifier is the stream
id.  A programmable table (LUT) in the PCI controller defines the hardware
mapping of PCI requester IDs to stream IDs.

This patch series implements support for this mapping.

Patch 1 removes the obsolete available-stream-id support.
Patch 2 updates stream ID partitioning info to be current
Patch 3 updates pci.h so pci_get_hose_head() is available
Patch 4 implements support for programming the LUT
Patch 5 implements a simple stream ID allocator for PCI
Patch 6 implements a function to set msi-map properties
Patch 7 implements a function to iterate over all PCI buses
and set up a LUT entry and msi-map for all discovered
devices

This patch series enables MSIs on ls2080a on v4.5-rc5 and later
kernels.  The obsolete support removed was unused in any
upstream kernels.

-v2 changes
   -in patch 7 removed skip of the host bridge when scanning the
bus
-v3 changes
   -patch 4: moved LUT #defines to immap_lsch3.h, made index
 allocator return an int
   -patch 5: return 0x on error
   -patch 7: fixed return value checks
-v4 changes
   -put all device ID to stream ID mapping under LS2 #ifdefs

Stuart Yoder (7):
  armv8: ls2080a: remove obsolete stream ID partitioning support
  armv8: ls2080a: update stream ID partitioning info
  pci: make pci_get_hose_head() available to external users
  pci/layerscape: add support for LUT
  pci/layerscape: add stream ID allocator
  pci/layerscape: fdt: function to set msi-map entries
  pci/layerscape: set LUT and msi-map for discovered PCI devices

 arch/arm/cpu/armv8/fsl-layerscape/fdt.c|  113 --
 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |4 +
 .../asm/arch-fsl-layerscape/ls2080a_stream_id.h|   55 +++--
 drivers/pci/pcie_layerscape.c  |  217 +---
 include/pci.h  |1 +
 5 files changed, 186 insertions(+), 204 deletions(-)

-- 
1.7.9.5

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

[U-Boot] [PATCH 1/7 v4] armv8: ls2080a: remove obsolete stream ID partitioning support

[Stuart Yoder]

From: Stuart Yoder 

Remove stream ID partitioning support that has been made
obsolete by upstream device tree bindings that specify how
representing how PCI requester IDs are mapped to MSI specifiers
and SMMU stream IDs.

Signed-off-by: Stuart Yoder 
---
-v4: no changes

 arch/arm/cpu/armv8/fsl-layerscape/fdt.c |  113 ---
 drivers/pci/pcie_layerscape.c   |   70 ---
 2 files changed, 183 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index 4e4861d..7a64f41 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -70,115 +70,6 @@ void ft_fixup_cpu(void *blob)
 }
 #endif
 
-/*
- * the burden is on the the caller to not request a count
- * exceeding the bounds of the stream_ids[] array
- */
-void alloc_stream_ids(int start_id, int count, u32 *stream_ids, int max_cnt)
-{
-   int i;
-
-   if (count > max_cnt) {
-   printf("\n%s: ERROR: max per-device stream ID count exceed\n",
-  __func__);
-   return;
-   }
-
-   for (i = 0; i < count; i++)
-   stream_ids[i] = start_id++;
-}
-
-/*
- * This function updates the mmu-masters property on the SMMU
- * node as per the SMMU binding-- phandle and list of stream IDs
- * for each MMU master.
- */
-void append_mmu_masters(void *blob, const char *smmu_path,
-   const char *master_name, u32 *stream_ids, int count)
-{
-   u32 phandle;
-   int smmu_nodeoffset;
-   int master_nodeoffset;
-   int i;
-
-   /* get phandle of mmu master device */
-   master_nodeoffset = fdt_path_offset(blob, master_name);
-   if (master_nodeoffset < 0) {
-   printf("\n%s: ERROR: master not found\n", __func__);
-   return;
-   }
-   phandle = fdt_get_phandle(blob, master_nodeoffset);
-   if (!phandle) { /* if master has no phandle, create one */
-   phandle = fdt_create_phandle(blob, master_nodeoffset);
-   if (!phandle) {
-   printf("\n%s: ERROR: unable to create phandle\n",
-  __func__);
-   return;
-   }
-   }
-
-   /* append it to mmu-masters */
-   smmu_nodeoffset = fdt_path_offset(blob, smmu_path);
-   if (fdt_appendprop_u32(blob, smmu_nodeoffset, "mmu-masters",
-  phandle) < 0) {
-   printf("\n%s: ERROR: unable to update SMMU node\n", __func__);
-   return;
-   }
-
-   /* for each stream ID, append to mmu-masters */
-   for (i = 0; i < count; i++) {
-   fdt_appendprop_u32(blob, smmu_nodeoffset, "mmu-masters",
-  stream_ids[i]);
-   }
-
-   /* fix up #stream-id-cells with stream ID count */
-   if (fdt_setprop_u32(blob, master_nodeoffset, "#stream-id-cells",
-   count) < 0)
-   printf("\n%s: ERROR: unable to update #stream-id-cells\n",
-  __func__);
-}
-
-
-/*
- * The info below summarizes how streamID partitioning works
- * for ls2080a and how it is conveyed to the OS via the device tree.
- *
- *  -non-PCI legacy, platform devices (USB, SD/MMC, SATA, DMA)
- * -all legacy devices get a unique ICID assigned and programmed in
- *  their AMQR registers by u-boot
- * -u-boot updates the hardware device tree with streamID properties
- *  for each platform/legacy device (smmu-masters property)
- *
- *  -PCIe
- * -for each PCI controller that is active (as per RCW settings),
- *  u-boot will allocate a range of ICID and convey that to Linux via
- *  the device tree (smmu-masters property)
- *
- *  -DPAA2
- * -u-boot will allocate a range of ICIDs to be used by the Management
- *  Complex for containers and will set these values in the MC DPC image.
- * -the MC is responsible for allocating and setting up ICIDs
- *  for all DPAA2 devices.
- *
- */
-#ifdef CONFIG_FSL_LSCH3
-static void fdt_fixup_smmu(void *blob)
-{
-   int nodeoffset;
-
-   nodeoffset = fdt_path_offset(blob, "/iommu@500");
-   if (nodeoffset < 0) {
-   printf("\n%s: WARNING: no SMMU node found\n", __func__);
-   return;
-   }
-
-   /* fixup for all PCI controllers */
-#ifdef CONFIG_PCI
-   fdt_fixup_smmu_pcie(blob);
-#endif
-}
-#endif
-
 void ft_cpu_setup(void *blob, bd_t *bd)
 {
 #ifdef CONFIG_MP
@@ -200,8 +91,4 @@ void ft_cpu_setup(void *blob, bd_t *bd)
 #ifdef CONFIG_FSL_ESDHC
fdt_fixup_esdhc(blob, bd);
 #endif
-
-#ifdef CONFIG_FSL_LSCH3
-   fdt_fixup_smmu(blob);
-#endif
 }
diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 99f9c83..bb29222 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -664,73 +664,3 @@ void 

[U-Boot] [PATCH 7/7 v4] pci/layerscape: set LUT and msi-map for discovered PCI devices

[Stuart Yoder]

From: Stuart Yoder 

for all PCI devices discovered in a system:
  -allocate a LUT (look-up-table) entry in that PCI controller
  -allocate a stream ID for the device
  -program and enable a LUT entry (maps PCI requester id to stream ID)
  -set the msi-map property on the controller reflecting the
   LUT mapping

basic bus scanning loop/logic was taken from drivers/pci/pci.c
pci_hose_scan_bus().

Signed-off-by: Stuart Yoder 
---
-v4: no changes

 drivers/pci/pcie_layerscape.c |   64 +
 1 file changed, 64 insertions(+)

diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index c3dc911..2aa415a 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -562,6 +562,66 @@ static void fdt_pcie_set_msi_map_entry(void *blob, struct 
ls_pcie *pcie,
fdt_appendprop_u32(blob, nodeoffset, "msi-map", streamid);
fdt_appendprop_u32(blob, nodeoffset, "msi-map", 1);
 }
+
+static void fdt_fixup_pcie(void *blob)
+{
+   unsigned int found_multi = 0;
+   unsigned char header_type;
+   int index;
+   u32 streamid;
+   pci_dev_t dev;
+   int bus;
+   unsigned short id;
+   struct pci_controller *hose;
+   struct ls_pcie *pcie;
+   int i;
+
+   for (i = 0, hose = pci_get_hose_head(); hose; hose = hose->next, i++) {
+   pcie = hose->priv_data;
+   for (bus = hose->first_busno; bus <= hose->last_busno; bus++) {
+
+   for (dev =  PCI_BDF(bus, 0, 0);
+dev <  PCI_BDF(bus, PCI_MAX_PCI_DEVICES - 1,
+   PCI_MAX_PCI_FUNCTIONS - 1);
+dev += PCI_BDF(0, 0, 1)) {
+
+   if (PCI_FUNC(dev) && !found_multi)
+   continue;
+
+   pci_read_config_word(dev, PCI_VENDOR_ID, );
+
+   pci_read_config_byte(dev, PCI_HEADER_TYPE,
+_type);
+
+   if ((id == 0x) || (id == 0x))
+   continue;
+
+   if (!PCI_FUNC(dev))
+   found_multi = header_type & 0x80;
+
+   streamid = ls_pcie_next_streamid();
+   if (streamid == 0x) {
+   printf("ERROR: no stream ids free\n");
+   continue;
+   }
+
+   index = ls_pcie_next_lut_index(pcie);
+   if (index < 0) {
+   printf("ERROR: no LUT indexes free\n");
+   continue;
+   }
+
+   /* map PCI b.d.f to streamID in LUT */
+   ls_pcie_lut_set_mapping(pcie, index, dev >> 8,
+   streamid);
+
+   /* update msi-map in device tree */
+   fdt_pcie_set_msi_map_entry(blob, pcie, dev >> 8,
+  streamid);
+   }
+   }
+   }
+}
 #endif
 
 int ls_pcie_init_ctrl(int busno, enum srds_prtcl dev, struct ls_pcie_info 
*info)
@@ -740,6 +800,10 @@ void ft_pci_setup(void *blob, bd_t *bd)
#ifdef CONFIG_PCIE4
ft_pcie_ls_setup(blob, FSL_PCIE_COMPAT, CONFIG_SYS_PCIE4_ADDR, PCIE4);
#endif
+
+   #if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
+   fdt_fixup_pcie(blob);
+   #endif
 }
 
 #else
-- 
1.7.9.5

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

[U-Boot] [PATCH 5/7 v4] pci/layerscape: add stream ID allocator

[Stuart Yoder]

From: Stuart Yoder 

add a function to return the next available stream ID
for PCI

Signed-off-by: Stuart Yoder 
---
-v4: no changes

 drivers/pci/pcie_layerscape.c |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 8435446..4d24436 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -509,6 +509,17 @@ static void ls_pcie_lut_set_mapping(struct ls_pcie *pcie, 
int index, u32 devid,
writel((devid << 16), lut + PCIE_LUT_UDR(index));
writel(streamid | PCIE_LUT_ENABLE, lut + PCIE_LUT_LDR(index));
 }
+
+/* returns the next available streamid */
+static u32 ls_pcie_next_streamid(void)
+{
+   static int next_stream_id = FSL_PEX_STREAM_ID_START;
+
+   if (next_stream_id > FSL_PEX_STREAM_ID_END)
+   return 0x;
+
+   return next_stream_id++;
+}
 #endif
 
 int ls_pcie_init_ctrl(int busno, enum srds_prtcl dev, struct ls_pcie_info 
*info)
-- 
1.7.9.5

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

[U-Boot] [PATCH 6/7 v4] pci/layerscape: fdt: function to set msi-map entries

[Stuart Yoder]

From: Stuart Yoder 

msi-map properties are used to tell an OS how PCI requester
IDs are mapped to ARM SMMU stream IDs.  This patch defines a
function to append a single msi-map entry to a given PCI controller
device tree node.

Signed-off-by: Stuart Yoder 
---
-v4: no changes

 drivers/pci/pcie_layerscape.c |   42 +
 1 file changed, 42 insertions(+)

diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 4d24436..c3dc911 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -520,6 +520,48 @@ static u32 ls_pcie_next_streamid(void)
 
return next_stream_id++;
 }
+
+/*
+ * An msi-map is a property to be added to the pci controller
+ * node.  It is a table, where each entry consists of 4 fields
+ * e.g.:
+ *
+ *  msi-map = <[devid] [phandle-to-msi-ctrl] [stream-id] [count]
+ * [devid] [phandle-to-msi-ctrl] [stream-id] [count]>;
+ */
+static void fdt_pcie_set_msi_map_entry(void *blob, struct ls_pcie *pcie,
+  u32 devid, u32 streamid)
+{
+   char pcie_path[19];
+   u32 *prop;
+   u32 phandle;
+   int nodeoffset;
+
+   /* find pci controller node */
+   snprintf(pcie_path, sizeof(pcie_path), "/soc/pcie@%llx",
+(u64)pcie->dbi);
+   nodeoffset = fdt_path_offset(blob, pcie_path);
+   if (nodeoffset < 0) {
+   printf("\n%s: ERROR: unable to update PCIe node: %s\n",
+  __func__, pcie_path);
+   return;
+   }
+
+   /* get phandle to MSI controller */
+   prop = (u32 *)fdt_getprop(blob, nodeoffset, "msi-parent", 0);
+   if (prop == NULL) {
+   printf("\n%s: ERROR: missing msi-parent: %s\n", __func__,
+  pcie_path);
+   return;
+   }
+   phandle = be32_to_cpu(*prop);
+
+   /* set one msi-map row */
+   fdt_appendprop_u32(blob, nodeoffset, "msi-map", devid);
+   fdt_appendprop_u32(blob, nodeoffset, "msi-map", phandle);
+   fdt_appendprop_u32(blob, nodeoffset, "msi-map", streamid);
+   fdt_appendprop_u32(blob, nodeoffset, "msi-map", 1);
+}
 #endif
 
 int ls_pcie_init_ctrl(int busno, enum srds_prtcl dev, struct ls_pcie_info 
*info)
-- 
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 5/6] arm: am57xx: Enable 8-bit eMMC access on AM57XX EVM

[Tom Rini]

On Tue, Mar 08, 2016 at 06:42:27PM +0700, Semen Protsenko wrote:

> From: Sam Protsenko 
> 
> Use 8-bit access instead of 4-bit to speed up eMMC flashing speed.
> 
> Signed-off-by: Sam Protsenko 

Reviewed-by: Tom Rini 

-- 
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 4/6] arm: am57xx: Set serial# variable

[Tom Rini]

On Tue, Mar 08, 2016 at 06:42:26PM +0700, Semen Protsenko wrote:

> From: Sam Protsenko 
> 
> serial# variable is used to correctly display device ID in
> "fastboot devices".
> 
> Signed-off-by: Sam Protsenko 

Reviewed-by: Tom Rini 

-- 
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 3/6] arm: am57xx: Define Android partition table

[Tom Rini]

On Tue, Mar 08, 2016 at 06:42:25PM +0700, Semen Protsenko wrote:

> From: Sam Protsenko 
> 
> "fastboot oem format" command reuses "gpt write" command, which in turn
> requires correct partitions defined in $partitions variable. This patch
> adds such definition of Android partitions for AM57XX EVM board.
> 
> By default $partitions variable contains Linux partition table. In order
> to prepare Android environment one can run next commands from U-Boot
> shell:
> 
> => env set partitions $partitions_android
> => env save
> 
> After those operations one can go to fastboot mode and perform
> "fastboot oem format" to create Android partition table.
> 
> While at it, enable CONFIG_RANDOM_UUID to spare user from providing
> UUIDs for each partition manually.
> 
> Signed-off-by: Sam Protsenko 

Reviewed-by: Tom Rini 

-- 
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 4/7 v3] pci/layerscape: add support for LUT

[Stuart Yoder]

> -Original Message-
> From: york sun
> Sent: Monday, March 07, 2016 4:32 PM
> To: Stuart Yoder ; u-boot@lists.denx.de
> Cc: Prabhakar Kushwaha ; Mingkai Hu 
> ;
> Minghuan Lian ; Yang-Leo Li ;
> marc.zyng...@arm.com
> Subject: Re: [PATCH 4/7 v3] pci/layerscape: add support for LUT
> 
> On 02/26/2016 08:52 AM, Stuart Yoder wrote:
> > From: Stuart Yoder 
> >
> > The per-PCI controller LUT (Look-Up-Table) is a 32-entry table
> > that maps PCI requester IDs (bus/dev/fun) to a stream ID.
> >
> > This patch implements infrastructure to enable LUT initialization:
> >   -define registers offsets
> >   -add an index to 'struct ls_pcie' to track next available slot in LUT
> >   -add function to allocate the next available entry index
> >   -add function to program a LUT entry
> >
> > Signed-off-by: Stuart Yoder 
> > ---
> > -v3
> >-moved LUT #defines to immap_lsch3.h, made index
> > allocator return an int
> >
> >  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |4 +++
> >  drivers/pci/pcie_layerscape.c  |   29 
> > 
> >  2 files changed, 33 insertions(+)
> >
> > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> > index 91f3ce8..d04e336 100644
> > --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> > +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> > @@ -86,6 +86,10 @@
> >  #define PCIE_LUT_BASE  0x8
> >  #define PCIE_LUT_LCTRL00x7F8
> >  #define PCIE_LUT_DBG   0x7FC
> > +#define PCIE_LUT_UDR(n) (0x800 + (n) * 8)
> > +#define PCIE_LUT_LDR(n) (0x804 + (n) * 8)
> > +#define PCIE_LUT_ENABLE (1 << 31)
> > +#define PCIE_LUT_ENTRY_COUNT32
> >
> >  /* Device Configuration */
> >  #define DCFG_BASE  0x01e0
> > diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
> > index bb29222..8b1e6fb 100644
> > --- a/drivers/pci/pcie_layerscape.c
> > +++ b/drivers/pci/pcie_layerscape.c
> > @@ -93,6 +93,7 @@ struct ls_pcie {
> > void __iomem *dbi;
> > void __iomem *va_cfg0;
> > void __iomem *va_cfg1;
> > +   int next_lut_index;
> > struct pci_controller hose;
> >  };
> >
> > @@ -482,6 +483,33 @@ static void ls_pcie_setup_ep(struct ls_pcie *pcie, 
> > struct
> ls_pcie_info *info)
> > }
> >  }
> >
> > +
> > +/*
> > + * Return next available LUT index.
> > + */
> > +static int ls_pcie_next_lut_index(struct ls_pcie *pcie)
> > +{
> > +   if (pcie->next_lut_index < PCIE_LUT_ENTRY_COUNT)
> 
> This causes compiling error on LS1043 targets. LS1043is lsch2 device. Please
> test your patch on all layerscape targets.

Yes, forgot about ls1043...will respin.

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

Re: [U-Boot] [PATCH 2/6] arm: am57xx: Enable Fastboot

[Tom Rini]

On Tue, Mar 08, 2016 at 06:42:24PM +0700, Semen Protsenko wrote:

> From: Sam Protsenko 
> 
> Enable fastboot by default for AM57XX EVM.
> 
> This is based on following patch modified accordingly:
> http://git.omapzoom.org/?p=repo/u-boot.git;a=commit;h=b2e04f92b5d91c708b6fd6b79d2266966ac51f4b
> 
> Signed-off-by: Sam Protsenko 

Since you're spending some time in here, can you please start converting
some of the fastboot options over to Kconfig?  Thanks!

-- 
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 0/6] arm: am57xx: Add Fastboot support to AM57XX EVM

[Tom Rini]

On Tue, Mar 08, 2016 at 06:42:22PM +0700, Semen Protsenko wrote:
> 
> Hi All,
> 
> This patch series add Fastboot support to TexasInstruments AM57XX EVM board 
> and
> improves eMMC support. The most of code was borrowed from DRA7 EVM (since
> this board is very similar to DRA7 EVM).
> 
> Next commands were tested:
>   - fastboot devices
>   - fastboot getvar
>   - fastboot oem format
>   - fastboot flash
> 
> Sam Protsenko (6):
>   arm: am57xx: Enable USB gadget in AM57XX
>   arm: am57xx: Enable Fastboot
>   arm: am57xx: Define Android partition table
>   arm: am57xx: Set serial# variable
>   arm: am57xx: Enable 8-bit eMMC access on AM57XX EVM
>   arm: am57xx: Keep environment in eMMC
> 
>  board/ti/am57xx/board.c  |  1 +
>  include/configs/am57xx_evm.h | 58 
> +++-
>  2 files changed, 53 insertions(+), 6 deletions(-)

I think this series shows that we really need someone to step up and
spend time converting the environment options to Kconfig so that
different applications of the same board can easily tweak things they
need (ie save env on the eMMC that you're programming vs keep env as a
FAT file on the SD card users are often using).

-- 
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 5/6] arm: am57xx: Enable 8-bit eMMC access on AM57XX EVM

[Lokesh Vutla]

On Tuesday 08 March 2016 05:12 PM, Semen Protsenko wrote:
> From: Sam Protsenko 
> 
> Use 8-bit access instead of 4-bit to speed up eMMC flashing speed.

Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh

> 
> Signed-off-by: Sam Protsenko 
> ---
>  include/configs/am57xx_evm.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h
> index d075d61..1ab9498 100644
> --- a/include/configs/am57xx_evm.h
> +++ b/include/configs/am57xx_evm.h
> @@ -75,6 +75,7 @@
>  #define CONFIG_CMD_GPT
>  #define CONFIG_EFI_PARTITION
>  #define CONFIG_RANDOM_UUID
> +#define CONFIG_HSMMC2_8BIT
>  
>  /* CPSW Ethernet */
>  #define CONFIG_CMD_DHCP
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/6] arm: am57xx: Enable Fastboot

[Lokesh Vutla]

On Tuesday 08 March 2016 05:12 PM, Semen Protsenko wrote:
> From: Sam Protsenko 
> 
> Enable fastboot by default for AM57XX EVM.
> 
> This is based on following patch modified accordingly:
> http://git.omapzoom.org/?p=repo/u-boot.git;a=commit;h=b2e04f92b5d91c708b6fd6b79d2266966ac51f4b

Also mention that you are guarding for non SPL

Other than that:
Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh

> 
> Signed-off-by: Sam Protsenko 
> ---
>  include/configs/am57xx_evm.h | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h
> index 9191d61..9a740d4 100644
> --- a/include/configs/am57xx_evm.h
> +++ b/include/configs/am57xx_evm.h
> @@ -36,11 +36,22 @@
>  
>  #define CONFIG_SYS_OMAP_ABE_SYSCK
>  
> +#ifndef CONFIG_SPL_BUILD
>  /* Define the default GPT table for eMMC */
>  #define PARTS_DEFAULT \
>   "uuid_disk=${uuid_gpt_disk};" \
>   "name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}"
>  
> +/* Fastboot */
> +#define CONFIG_USB_FUNCTION_FASTBOOT
> +#define CONFIG_CMD_FASTBOOT
> +#define CONFIG_ANDROID_BOOT_IMAGE
> +#define CONFIG_FASTBOOT_BUF_ADDR CONFIG_SYS_LOAD_ADDR
> +#define CONFIG_FASTBOOT_BUF_SIZE 0x2F00
> +#define CONFIG_FASTBOOT_FLASH
> +#define CONFIG_FASTBOOT_FLASH_MMC_DEV1
> +#endif
> +
>  #include 
>  
>  /* Enhance our eMMC support / experience. */
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/6] arm: am57xx: Enable USB gadget in AM57XX

[Lokesh Vutla]

On Tuesday 08 March 2016 05:12 PM, Semen Protsenko wrote:
> From: Sam Protsenko 
> 
> Enable dwc3, dwc3-omap and PHY for dwc3.
> Also enable USB gadget.

Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh

> 
> Signed-off-by: Sam Protsenko 
> ---
>  include/configs/am57xx_evm.h | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h
> index 6308cab..9191d61 100644
> --- a/include/configs/am57xx_evm.h
> +++ b/include/configs/am57xx_evm.h
> @@ -77,6 +77,20 @@
>  #define CONFIG_OMAP_USB_PHY
>  #define CONFIG_OMAP_USB3PHY1_HOST
>  
> +/* USB GADGET */
> +#define CONFIG_USB_DWC3_PHY_OMAP
> +#define CONFIG_USB_DWC3_OMAP
> +#define CONFIG_USB_DWC3
> +#define CONFIG_USB_DWC3_GADGET
> +
> +#define CONFIG_USB_GADGET
> +#define CONFIG_USB_GADGET_DOWNLOAD
> +#define CONFIG_USB_GADGET_VBUS_DRAW  2
> +#define CONFIG_G_DNL_MANUFACTURER"Texas Instruments"
> +#define CONFIG_G_DNL_VENDOR_NUM  0x0451
> +#define CONFIG_G_DNL_PRODUCT_NUM 0xd022
> +#define CONFIG_USB_GADGET_DUALSPEED
> +
>  /* SATA */
>  #define CONFIG_BOARD_LATE_INIT
>  #define CONFIG_CMD_SCSI
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/3] armv8/ls1043aqds: Return the default chennel

[Wenbin Song]

In order to avoid effecting some i2c devices
mounted on default channel, return the default
channel after retimer initialization.

Signed-off-by: Wenbin Song 
---
 board/freescale/ls1043aqds/ls1043aqds.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/board/freescale/ls1043aqds/ls1043aqds.c 
b/board/freescale/ls1043aqds/ls1043aqds.c
index a72fe52..fba6b88 100644
--- a/board/freescale/ls1043aqds/ls1043aqds.c
+++ b/board/freescale/ls1043aqds/ls1043aqds.c
@@ -170,8 +170,7 @@ void board_retimer_init(void)
u8 reg;
 
/* Retimer is connected to I2C1_CH7_CH5 */
-   reg = I2C_MUX_CH7;
-   i2c_write(I2C_MUX_PCA_ADDR_PRI, 0, 1, , 1);
+   select_i2c_ch_pca9547(I2C_MUX_CH7);
reg = I2C_MUX_CH5;
i2c_write(I2C_MUX_PCA_ADDR_SEC, 0, 1, , 1);
 
@@ -219,6 +218,9 @@ void board_retimer_init(void)
i2c_write(I2C_RETIMER_ADDR, 0x63, 1, , 1);
reg = 0xcd;
i2c_write(I2C_RETIMER_ADDR, 0x64, 1, , 1);
+
+   /* Return the default channel */
+   select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
 }
 
 int board_early_init_f(void)
-- 
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/3] vid: Return to default channel of the i2c multiplexer

[Wenbin Song]

If the IR chip is connected to one of the channel of I2C-bus
multiplexer, Set to the default channel after accessing the IR chip.

Signed-off-by: Wenbin Song 
---
 board/freescale/common/vid.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/board/freescale/common/vid.c b/board/freescale/common/vid.c
index 1bd65a8..a6a132a 100644
--- a/board/freescale/common/vid.c
+++ b/board/freescale/common/vid.c
@@ -454,6 +454,9 @@ int adjust_vdd(ulong vdd_override)
 exit:
if (re_enable)
enable_interrupts();
+
+   i2c_multiplexer_select_vid_channel(I2C_MUX_CH_DEFAULT);
+
return ret;
 }
 
@@ -469,7 +472,7 @@ static int print_vdd(void)
ret = find_ir_chip_on_i2c();
if (ret < 0) {
printf("VID: Could not find voltage regulator on I2C.\n");
-   return -1;
+   goto exit;
} else {
i2caddress = ret;
debug("VID: IR Chip found on I2C address 0x%02x\n", i2caddress);
@@ -481,11 +484,14 @@ static int print_vdd(void)
vdd_last = read_voltage(i2caddress);
if (vdd_last < 0) {
printf("VID: Couldn't read sensor abort VID adjustment\n");
-   return -1;
+   goto exit;
}
printf("VID: Core voltage is at %d mV\n", vdd_last);
+exit:
+   i2c_multiplexer_select_vid_channel(I2C_MUX_CH_DEFAULT);
+
+   return ret < 0 ? -1 : 0;
 
-   return 0;
 }
 
 static int do_vdd_override(cmd_tbl_t *cmdtp,
-- 
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 3/3] armv8/ls1043aqds: Add SYS_EEPROM support

[Wenbin Song]

Signed-off-by: Wenbin Song 
---
 include/configs/ls1043aqds.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/configs/ls1043aqds.h b/include/configs/ls1043aqds.h
index 158cf02..e269522 100644
--- a/include/configs/ls1043aqds.h
+++ b/include/configs/ls1043aqds.h
@@ -114,6 +114,16 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_DOS_PARTITION
 #define CONFIG_BOARD_LATE_INIT
 
+
+/* EEPROM */
+#define CONFIG_ID_EEPROM
+#define CONFIG_SYS_I2C_EEPROM_NXID
+#define CONFIG_SYS_EEPROM_BUS_NUM  0
+#define CONFIG_SYS_I2C_EEPROM_ADDR 0x57
+#define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1
+#define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS  3
+#define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS  5
+
 #define CONFIG_SYS_SATAAHCI_BASE_ADDR
 
 #define CONFIG_SYS_SCSI_MAX_SCSI_ID1
-- 
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 0/4] ARM: DRA7: emif: Miscellaneous bug fixes

[Tom Rini]

On Tue, Mar 08, 2016 at 09:07:28AM +0530, Lokesh Vutla wrote:
> On Tuesday 08 March 2016 05:06 AM, Tom Rini wrote:
> > On Sat, Mar 05, 2016 at 05:32:27PM +0530, Lokesh Vutla wrote:
> > 
> >> This series fixes miscellaneous bugs for the emif driver. 
> >>
> >> Lokesh Vutla (4):
> >>   ARM: DRA7: emif: Fix updating of refresh ctrl shadow
> >>   ARM: DRA7: emif: Fix DDR init sequence during warm reset
> >>   ARM: DRA7: emif: Check for enable bits before updating leveling output
> >>   ARM: DRA7: emif: Enable interleaving for higher address space
> >>
> >>  arch/arm/cpu/armv7/omap-common/emif-common.c | 50 
> >> ++--
> >>  arch/arm/cpu/armv7/omap5/sdram.c | 34 ++-
> >>  arch/arm/include/asm/emif.h  |  9 +
> >>  3 files changed, 67 insertions(+), 26 deletions(-)
> > 
> > Note that my board is still unable to boot from mainline with these
> > applied but still works with the TI vendor tree.
> 
> Hmm..I guess you are talking about DRA72-evm. SPL even doesn't come up
> or U-boot is failing. Can I see the logs? And what switch settings are
> you using?(Ill try to reproduce in my place)

SPL doesn't even come up so no output.  SD card boot settings.  I can
send you SW2/SW3/SW5 off-list in a bit.

-- 
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 6/6] arm: am57xx: Keep environment in eMMC

[Lokesh Vutla]

On Tuesday 08 March 2016 05:12 PM, Semen Protsenko wrote:
> From: Sam Protsenko 
> 
> Use eMMC (instead of SD card) to store U-Boot environment.

Any specific reason why you want this change?

Thanks and regards,
Lokesh

> 
> Signed-off-by: Sam Protsenko 
> ---
>  include/configs/am57xx_evm.h | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h
> index 1ab9498..f467f46 100644
> --- a/include/configs/am57xx_evm.h
> +++ b/include/configs/am57xx_evm.h
> @@ -22,11 +22,13 @@
>  
>  #define CONFIG_NR_DRAM_BANKS 2
>  
> -#define CONFIG_ENV_SIZE  (64 << 10)
> -#define CONFIG_ENV_IS_IN_FAT
> -#define FAT_ENV_INTERFACE"mmc"
> -#define FAT_ENV_DEVICE_AND_PART  "0:1"
> -#define FAT_ENV_FILE "uboot.env"
> +/* MMC ENV related defines */
> +#define CONFIG_ENV_IS_IN_MMC
> +#define CONFIG_SYS_MMC_ENV_DEV   1   /* SLOT2: eMMC(1) */
> +#define CONFIG_ENV_SIZE  (128 << 10)
> +#define CONFIG_ENV_OFFSET0xE
> +#define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE)
> +#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
>  
>  #define CONSOLEDEV   "ttyO2"
>  #define CONFIG_SYS_NS16550_COM1  UART1_BASE  /* Base EVM has 
> UART0 */
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 5/6] arm: am57xx: Enable 8-bit eMMC access on AM57XX EVM

[Semen Protsenko]

From: Sam Protsenko 

Use 8-bit access instead of 4-bit to speed up eMMC flashing speed.

Signed-off-by: Sam Protsenko 
---
 include/configs/am57xx_evm.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h
index d075d61..1ab9498 100644
--- a/include/configs/am57xx_evm.h
+++ b/include/configs/am57xx_evm.h
@@ -75,6 +75,7 @@
 #define CONFIG_CMD_GPT
 #define CONFIG_EFI_PARTITION
 #define CONFIG_RANDOM_UUID
+#define CONFIG_HSMMC2_8BIT
 
 /* CPSW Ethernet */
 #define CONFIG_CMD_DHCP
-- 
2.7.0

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

[U-Boot] [PATCH 6/6] arm: am57xx: Keep environment in eMMC

[Semen Protsenko]

From: Sam Protsenko 

Use eMMC (instead of SD card) to store U-Boot environment.

Signed-off-by: Sam Protsenko 
---
 include/configs/am57xx_evm.h | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h
index 1ab9498..f467f46 100644
--- a/include/configs/am57xx_evm.h
+++ b/include/configs/am57xx_evm.h
@@ -22,11 +22,13 @@
 
 #define CONFIG_NR_DRAM_BANKS   2
 
-#define CONFIG_ENV_SIZE(64 << 10)
-#define CONFIG_ENV_IS_IN_FAT
-#define FAT_ENV_INTERFACE  "mmc"
-#define FAT_ENV_DEVICE_AND_PART"0:1"
-#define FAT_ENV_FILE   "uboot.env"
+/* MMC ENV related defines */
+#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_SYS_MMC_ENV_DEV 1   /* SLOT2: eMMC(1) */
+#define CONFIG_ENV_SIZE(128 << 10)
+#define CONFIG_ENV_OFFSET  0xE
+#define CONFIG_ENV_OFFSET_REDUND   (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE)
+#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
 
 #define CONSOLEDEV "ttyO2"
 #define CONFIG_SYS_NS16550_COM1UART1_BASE  /* Base EVM has 
UART0 */
-- 
2.7.0

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

[U-Boot] [PATCH 4/6] arm: am57xx: Set serial# variable

[Semen Protsenko]

From: Sam Protsenko 

serial# variable is used to correctly display device ID in
"fastboot devices".

Signed-off-by: Sam Protsenko 
---
 board/ti/am57xx/board.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 042f9ab..751de39 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -270,6 +270,7 @@ int board_late_init(void)
 * This is the POWERHOLD-in-Low behavior.
 */
palmas_i2c_write_u8(TPS65903X_CHIP_P1, 0xA0, 0x1);
+   omap_die_id_serial();
return 0;
 }
 
-- 
2.7.0

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

[U-Boot] [PATCH 0/6] arm: am57xx: Add Fastboot support to AM57XX EVM

[Semen Protsenko]

Hi All,

This patch series add Fastboot support to TexasInstruments AM57XX EVM board and
improves eMMC support. The most of code was borrowed from DRA7 EVM (since
this board is very similar to DRA7 EVM).

Next commands were tested:
  - fastboot devices
  - fastboot getvar
  - fastboot oem format
  - fastboot flash

Sam Protsenko (6):
  arm: am57xx: Enable USB gadget in AM57XX
  arm: am57xx: Enable Fastboot
  arm: am57xx: Define Android partition table
  arm: am57xx: Set serial# variable
  arm: am57xx: Enable 8-bit eMMC access on AM57XX EVM
  arm: am57xx: Keep environment in eMMC

 board/ti/am57xx/board.c  |  1 +
 include/configs/am57xx_evm.h | 58 
+++-
 2 files changed, 53 insertions(+), 6 deletions(-)


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

[U-Boot] [PATCH 3/6] arm: am57xx: Define Android partition table

[Semen Protsenko]

From: Sam Protsenko 

"fastboot oem format" command reuses "gpt write" command, which in turn
requires correct partitions defined in $partitions variable. This patch
adds such definition of Android partitions for AM57XX EVM board.

By default $partitions variable contains Linux partition table. In order
to prepare Android environment one can run next commands from U-Boot
shell:

=> env set partitions $partitions_android
=> env save

After those operations one can go to fastboot mode and perform
"fastboot oem format" to create Android partition table.

While at it, enable CONFIG_RANDOM_UUID to spare user from providing
UUIDs for each partition manually.

Signed-off-by: Sam Protsenko 
---
 include/configs/am57xx_evm.h | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h
index 9a740d4..d075d61 100644
--- a/include/configs/am57xx_evm.h
+++ b/include/configs/am57xx_evm.h
@@ -39,8 +39,25 @@
 #ifndef CONFIG_SPL_BUILD
 /* Define the default GPT table for eMMC */
 #define PARTS_DEFAULT \
+   /* Linux partitions */ \
"uuid_disk=${uuid_gpt_disk};" \
-   "name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}"
+   "name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}\0" \
+   /* Android partitions */ \
+   "partitions_android=" \
+   "uuid_disk=${uuid_gpt_disk};" \
+   "name=xloader,start=128K,size=128K,uuid=${uuid_gpt_xloader};" \
+   "name=bootloader,size=384K,uuid=${uuid_gpt_bootloader};" \
+   "name=environment,size=128K,uuid=${uuid_gpt_environment};" \
+   "name=misc,size=128K,uuid=${uuid_gpt_misc};" \
+   "name=efs,start=1280K,size=16M,uuid=${uuid_gpt_efs};" \
+   "name=crypto,size=16K,uuid=${uuid_gpt_crypto};" \
+   "name=recovery,size=10M,uuid=${uuid_gpt_recovery};" \
+   "name=boot,size=10M,uuid=${uuid_gpt_boot};" \
+   "name=system,size=768M,uuid=${uuid_gpt_system};" \
+   "name=cache,size=256M,uuid=${uuid_gpt_cache};" \
+   "name=ipu1,size=1M,uuid=${uuid_gpt_ipu1};" \
+   "name=ipu2,size=1M,uuid=${uuid_gpt_ipu2};" \
+   "name=userdata,size=-,uuid=${uuid_gpt_userdata}"
 
 /* Fastboot */
 #define CONFIG_USB_FUNCTION_FASTBOOT
@@ -57,6 +74,7 @@
 /* Enhance our eMMC support / experience. */
 #define CONFIG_CMD_GPT
 #define CONFIG_EFI_PARTITION
+#define CONFIG_RANDOM_UUID
 
 /* CPSW Ethernet */
 #define CONFIG_CMD_DHCP
-- 
2.7.0

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

[U-Boot] [PATCH 2/6] arm: am57xx: Enable Fastboot

[Semen Protsenko]

From: Sam Protsenko 

Enable fastboot by default for AM57XX EVM.

This is based on following patch modified accordingly:
http://git.omapzoom.org/?p=repo/u-boot.git;a=commit;h=b2e04f92b5d91c708b6fd6b79d2266966ac51f4b

Signed-off-by: Sam Protsenko 
---
 include/configs/am57xx_evm.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h
index 9191d61..9a740d4 100644
--- a/include/configs/am57xx_evm.h
+++ b/include/configs/am57xx_evm.h
@@ -36,11 +36,22 @@
 
 #define CONFIG_SYS_OMAP_ABE_SYSCK
 
+#ifndef CONFIG_SPL_BUILD
 /* Define the default GPT table for eMMC */
 #define PARTS_DEFAULT \
"uuid_disk=${uuid_gpt_disk};" \
"name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}"
 
+/* Fastboot */
+#define CONFIG_USB_FUNCTION_FASTBOOT
+#define CONFIG_CMD_FASTBOOT
+#define CONFIG_ANDROID_BOOT_IMAGE
+#define CONFIG_FASTBOOT_BUF_ADDR   CONFIG_SYS_LOAD_ADDR
+#define CONFIG_FASTBOOT_BUF_SIZE   0x2F00
+#define CONFIG_FASTBOOT_FLASH
+#define CONFIG_FASTBOOT_FLASH_MMC_DEV  1
+#endif
+
 #include 
 
 /* Enhance our eMMC support / experience. */
-- 
2.7.0

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

[U-Boot] [PATCH 1/6] arm: am57xx: Enable USB gadget in AM57XX

[Semen Protsenko]

From: Sam Protsenko 

Enable dwc3, dwc3-omap and PHY for dwc3.
Also enable USB gadget.

Signed-off-by: Sam Protsenko 
---
 include/configs/am57xx_evm.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h
index 6308cab..9191d61 100644
--- a/include/configs/am57xx_evm.h
+++ b/include/configs/am57xx_evm.h
@@ -77,6 +77,20 @@
 #define CONFIG_OMAP_USB_PHY
 #define CONFIG_OMAP_USB3PHY1_HOST
 
+/* USB GADGET */
+#define CONFIG_USB_DWC3_PHY_OMAP
+#define CONFIG_USB_DWC3_OMAP
+#define CONFIG_USB_DWC3
+#define CONFIG_USB_DWC3_GADGET
+
+#define CONFIG_USB_GADGET
+#define CONFIG_USB_GADGET_DOWNLOAD
+#define CONFIG_USB_GADGET_VBUS_DRAW2
+#define CONFIG_G_DNL_MANUFACTURER  "Texas Instruments"
+#define CONFIG_G_DNL_VENDOR_NUM0x0451
+#define CONFIG_G_DNL_PRODUCT_NUM   0xd022
+#define CONFIG_USB_GADGET_DUALSPEED
+
 /* SATA */
 #define CONFIG_BOARD_LATE_INIT
 #define CONFIG_CMD_SCSI
-- 
2.7.0

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

[U-Boot] [PATCH] spl: add a new stub spl_early_board_init() for early SoC-specific setup

[Masahiro Yamada]

We are generally supposed to implement SoC/board-specific SPL init
code in spl_board_init(), but it is called after spl_init() where the
FDT is setup and devices are bound.

This new stub spl_early_board_init() would be useful to put something
really SoC-specific, for example, debug_uart_init().

In fact, I was hit by some problems on FDT setup when I was tackling
on a completely new platform.  I wished I could use the debug UART
earlier in situations like that.

Signed-off-by: Masahiro Yamada 
---

 common/spl/spl.c | 6 ++
 include/spl.h| 1 +
 2 files changed, 7 insertions(+)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index e5167bf..df85b09 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -150,6 +150,10 @@ static int spl_ram_load_image(void)
 }
 #endif
 
+void __weak spl_early_board_init(void)
+{
+}
+
 int spl_init(void)
 {
int ret;
@@ -344,6 +348,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
 {
int i;
 
+   spl_early_board_init();
+
debug(">>spl:board_init_r()\n");
 
 #if defined(CONFIG_SYS_SPL_MALLOC_START)
diff --git a/include/spl.h b/include/spl.h
index 92cdc04..e3c1873 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -93,6 +93,7 @@ int spl_load_image_ext_os(block_dev_desc_t *block_dev, int 
partition);
  */
 int spl_init(void);
 
+void spl_early_board_init(void);
 #ifdef CONFIG_SPL_BOARD_INIT
 void spl_board_init(void);
 #endif
-- 
1.9.1

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

[U-Boot] [PATCH] arm64: define _image_binary_end to fix SPL_OF_CONTROL

[Masahiro Yamada]

To make SPL_OF_CONTROL work on ARM64 SoCs, _image_binary_end must be
defined in the linker script.

 LD  spl/u-boot-spl
lib/built-in.o: In function `fdtdec_setup':
lib/fdtdec.c:1186: undefined reference to `_image_binary_end'
lib/fdtdec.c:1186: undefined reference to `_image_binary_end'
make[1]: *** [spl/u-boot-spl] Error 1
make: *** [spl/u-boot-spl] Error 2

Note:
CONFIG_SPL_SEPARATE_BSS must be defined as well on ARM64 SoCs.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/cpu/armv8/u-boot-spl.lds | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds 
b/arch/arm/cpu/armv8/u-boot-spl.lds
index 4df339c..cc427c3 100644
--- a/arch/arm/cpu/armv8/u-boot-spl.lds
+++ b/arch/arm/cpu/armv8/u-boot-spl.lds
@@ -54,6 +54,8 @@ SECTIONS
*(.__end)
} >.sram
 
+   _image_binary_end = .;
+
.bss_start : {
. = ALIGN(8);
KEEP(*(.__bss_start));
-- 
1.9.1

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

Re: [U-Boot] Olimex-A20-EVB ethernet stops working with latest U-boot, works with tag v2016.01

[Hans de Goede]

Hi,

On 25-02-16 08:31, Ing. Damiano Bolla wrote:

Good morning Peng

I did revert the commit, see attached image showing git repository status

Unfortunately the result is still negative, see the following log

U-Boot 2016.03-rc2-00117-gde889c0 (Feb 25 2016 - 08:12:50 +0100) Allwinner 
Technology
CPU:   Allwinner A20 (SUN7I)
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
In:serial
Out:   serial
Err:   serial
SCSI:  SUNXI SCSI INIT
SATA link 0 timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net:   eth0: ethernet@01c5
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 0.00
USB3:   USB OHCI 0.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
Hit any key to stop autoboot:  0
ethernet@01c5 Waiting for PHY auto negotiation to complete. TIMEOUT 
!
ethernet@01c5: No link.
ethernet@01c5 Waiting for PHY auto negotiation to complete. TIMEOUT 
!
ethernet@01c5: No link.
Bad Linux ARM zImage magic!

Can I assist further ?


Can you please git bisect this, and find out which commit breaks things ?

Thanks & Regards,

Hans



Thanks, Damiano


In data 25 febbraio 2016 alle ore 02:11:00, Peng Fan  ha 
scritto:


Hi Damiano,

Can you try revert the following patch and retest on your board?
"
commit a058052c358c3ecf5f394ff37def6a45eb26768c
Author: Stefan Agner 
Date:   Wed Dec 9 11:21:25 2015 -0800

net: phy: do not read configuration register on reset
   When doing a software reset, the reset flag should be written without
other bits set. Writing the current state will lead to restoring the
state of the PHY (e.g. Powerdown), which is not what is expected from
a software reset.

Signed-off-by: Stefan Agner 
"

This patch breaks ethernet function of i.MX6 Quad Sabresd/Quad Sabreauto.
Not sure whether reverting this patch can help in your case or not. Please
try.

Thanks,
Peng.

On Wed, Feb 24, 2016 at 09:12:02AM +0100, Ing. Damiano Bolla wrote:

Good morning all

I updated to latest u-boot yesterday (git pull) and ethernet was not working

reverted to tag v2016.01 with the command

$ git checkout tags/v2016.01

rebuilt, uploaded and ethernet works

As far as I can tell the only difference on the two tests (just a simple ping 
192.168.1.1) is the u-boot version
Ethernet cable was not moved and I manage to load u-boot using FEL

I can do further tests is any of you is interested.

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







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


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

Re: [U-Boot] Ethernet not found on Arria 5.

[Bakhvalov, Denis (Nokia - PL/Wroclaw)]

Hi Marek,

> What do you mean by this ? Is your ethernet controller synthesised in
> the FPGA ? The arriaV socdk u-boot uses the top-side ethernet port,
> which is connected to the ethernet controller in the HPS.

I managed to get it working.
Right after configuring fpga from Linux I made a soft reset and PHY chip was 
successfully found.

Net: eth0: ethernet@ff702000

However there is still no ping in U-Boot.
After power reset I did:

># bridge disable
># fpga load 0  
># bridge enable

># md 0xff706000 1
ff706000: 0074  <-- this means fpga is in user mode

># setenv ethaddr ...
># setenv ipaddr ...
># setenv netmask ...
># setenv gatewayip ...

=> ping 192.168.1.126
Speed: 100, full duplex
Using ethernet@ff702000 device
ping failed; host 192.168.1.126 is not alive

With similar commands on previous U-Boot version I had ping.

Best regards,
Denis Bakhvalov
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] debug_uart: output CR along with LF

[Stefan Roese]

On 08.03.2016 10:19, Masahiro Yamada wrote:

The serial output from the debug UART carries on going far to the
right in the console.

Signed-off-by: Masahiro Yamada 


Yes, this has bugged me as well a few times as well. Thanks!

Reviewed-by: Stefan Roese 

Thanks,
Stefan

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

[U-Boot] [PATCH] debug_uart: output CR along with LF

[Masahiro Yamada]

The serial output from the debug UART carries on going far to the
right in the console.

Signed-off-by: Masahiro Yamada 
---

 include/debug_uart.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/debug_uart.h b/include/debug_uart.h
index 5d5349b..0d640b9 100644
--- a/include/debug_uart.h
+++ b/include/debug_uart.h
@@ -117,13 +117,15 @@ void printhex8(uint value);
 #define DEBUG_UART_FUNCS \
void printch(int ch) \
{ \
+   if (ch == '\n') \
+   _debug_uart_putc('\r'); \
_debug_uart_putc(ch); \
} \
 \
void printascii(const char *str) \
{ \
while (*str) \
-   _debug_uart_putc(*str++); \
+   printch(*str++); \
} \
 \
static inline void printhex1(uint digit) \
-- 
1.9.1

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