[U-Boot] [PATCH] ARM: uniphier: remove BLK select

[Masahiro Yamada]

This is a user configurable option, but "select BLK" forces users to
enable it.

Even with this commit, BLK is still enabled by "default y if DM_MMC"
for UniPhier SoCs; the difference is users can disable it if they
do not need it.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7203d63..714dd8b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -829,7 +829,6 @@ config TARGET_COLIBRI_PXA270
 
 config ARCH_UNIPHIER
bool "Socionext UniPhier SoCs"
-   select BLK
select CLK_UNIPHIER
select DM
select DM_GPIO
-- 
2.7.4

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

[U-Boot] [PATCH v2] net:phy:MSCC Add Support for VSC8530-VSC8531-VSC8540-VSC8541

[John Haechten]

net:phy:MSCC Add Support for VSC8530-VSC8531-VSC8540-VSC8541

Signed-off-by: John Haechten 
---

 drivers/net/phy/Makefile|   1 +
 drivers/net/phy/mscc.c  | 509 
 drivers/net/phy/phy.c   |   3 +
 include/config_phylib_all_drivers.h |   1 +
 include/configs/am335x_evm.h|   3 +
 include/phy.h   |   1 +
 6 files changed, 518 insertions(+)
 create mode 100644 drivers/net/phy/mscc.c

diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile index 
1e299b9..d372971 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -27,3 +27,4 @@ obj-$(CONFIG_PHY_TERANETICS) += teranetics.o
 obj-$(CONFIG_PHY_TI) += ti.o
 obj-$(CONFIG_PHY_XILINX) += xilinx_phy.o
 obj-$(CONFIG_PHY_VITESSE) += vitesse.o
+obj-$(CONFIG_PHY_MSCC) += mscc.o
diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c new file mode 
100644 index 000..e665b50
--- /dev/null
+++ b/drivers/net/phy/mscc.c
@@ -0,0 +1,509 @@
+/*
+ * Microsemi PHY drivers
+ *
+ * SPDX-License-Identifier: The MIT License (MIT)
+ *
+ * Copyright (c) 2016 Microsemi Corporation
+ *
+ * Author: John Haechten
+ *
+ */
+
+#include 
+#include 
+
+/* Microsemi PHY ID's */
+#define PHY_ID_VSC8530  0x00070560
+#define PHY_ID_VSC8531  0x00070570
+#define PHY_ID_VSC8540  0x00070760
+#define PHY_ID_VSC8541  0x00070770
+
+/* Microsemi VSC85xx PHY Register Pages */
+#define MSCC_EXT_PAGE_ACCESS31 /* Page Access Register */
+#define MSCC_PHY_PAGE_STD  0x /* Standard registers */
+#define MSCC_PHY_PAGE_EXT1 0x0001 /* Extended registers - page 1 */
+#define MSCC_PHY_PAGE_EXT2 0x0002 /* Extended registers - page 2 */
+#define MSCC_PHY_PAGE_EXT3 0x0003 /* Extended registers - page 3 */
+#define MSCC_PHY_PAGE_EXT4 0x0004 /* Extended registers - page 4 */
+#define MSCC_PHY_PAGE_GPIO 0x0010 /* GPIO registers */
+#define MSCC_PHY_PAGE_TEST 0x2A30 /* TEST Page registers */
+#define MSCC_PHY_PAGE_TR   0x52B5 /* Token Ring Page registers */
+
+/* Std Page Register 28 - PHY AUX Control/Status */
+#define MIIM_AUX_CNTRL_STAT_REG28
+#define MIIM_AUX_CNTRL_STAT_ACTIPHY_TO (0x0004)
+#define MIIM_AUX_CNTRL_STAT_F_DUPLEX   (0x0020)
+#define MIIM_AUX_CNTRL_STAT_SPEED_MASK (0x0018)
+#define MIIM_AUX_CNTRL_STAT_SPEED_POS  (3)
+#define MIIM_AUX_CNTRL_STAT_SPEED_10M  (0x0)
+#define MIIM_AUX_CNTRL_STAT_SPEED_100M (0x1)
+#define MIIM_AUX_CNTRL_STAT_SPEED_1000M(0x2)
+
+/* Std Page Register 23 - Extended PHY CTRL_1 */
+#define MSCC_PHY_EXT_PHY_CNTL_1_REG23
+#define MAC_IF_SELECTION_MASK  (0x1800)
+#define MAC_IF_SELECTION_GMII  (0)
+#define MAC_IF_SELECTION_RMII  (1)
+#define MAC_IF_SELECTION_RGMII (2)
+#define MAC_IF_SELECTION_POS   (11)
+#define MAC_IF_SELECTION_WIDTH (2)
+
+/* Extended Page 2 Register 20E2 */
+#define MSCC_PHY_RGMII_CNTL_REG20
+#define VSC_FAST_LINK_FAIL2_ENA_MASK   (0x8000)
+#define RX_CLK_OUT_MASK(0x0800)
+#define RX_CLK_OUT_POS (11)
+#define RX_CLK_OUT_WIDTH   (1)
+#define RX_CLK_OUT_NORMAL  (0)
+#define RX_CLK_OUT_DISABLE (1)
+#define RGMII_RX_CLK_DELAY_POS (4)
+#define RGMII_RX_CLK_DELAY_WIDTH   (3)
+#define RGMII_RX_CLK_DELAY_MASK(0x0070)
+#define RGMII_TX_CLK_DELAY_POS (0)
+#define RGMII_TX_CLK_DELAY_WIDTH   (3)
+#define RGMII_TX_CLK_DELAY_MASK(0x0007)
+
+/* Extended Page 2 Register 27E2 */
+#define MSCC_PHY_WOL_MAC_CONTROL   27
+#define EDGE_RATE_CNTL_POS (5)
+#define EDGE_RATE_CNTL_WIDTH   (3)
+#define EDGE_RATE_CNTL_MASK(0x00E0)
+#define RMII_CLK_OUT_ENABLE_POS(4)
+#define RMII_CLK_OUT_ENABLE_WIDTH  (1)
+#define RMII_CLK_OUT_ENABLE_MASK   (0x10)
+
+/* Token Ring Page 0x52B5 Registers */
+#define MSCC_PHY_REG_TR_ADDR_1616
+#define MSCC_PHY_REG_TR_DATA_1717
+#define MSCC_PHY_REG_TR_DATA_1818
+
+/* Token Ring - Read Value in */
+#define MSCC_PHY_TR_16_READ(0xA000)
+/* Token Ring - Write Value out */
+#define MSCC_PHY_TR_16_WRITE   (0x8000)
+
+/* Token Ring Registers */
+#define MSCC_PHY_TR_LINKDETCTRL_POS(3)
+#define MSCC_PHY_TR_LINKDETCTRL_WIDTH  (2)
+#define MSCC_PHY_TR_LINKDETCTRL_VAL(3)
+#define MSCC_PHY_TR_LINKDETCTRL_MASK   (0x0018)
+#define MSCC_PHY_TR_LINKDETCTRL_ADDR   (0x07F8)
+
+#define MSCC_PHY_TR_VGATHRESH100_POS   (0)
+#define MSCC_PHY_TR_VGATHRESH100_WIDTH (7)
+#define MSCC_PHY_TR_VGATHRESH100_VAL   (0x0018)
+#define MSCC_PHY_TR_VGATHRESH100_MASK  (0x007f)
+#define MSCC_PHY_TR_VGATHRESH100_ADDR  (0x0FA4)
+
+#define MSCC_PHY_TR_VGAGAIN10_U_POS(0)
+#define MSCC_PHY_TR_VGAGAIN10_U_WIDTH  

[U-Boot] post_codes in u-boot?

[Haleigh Novak]

Hello All,


I am currently deciphering post_code ouput on a machine running Yocto with a 
bios of coreboot with a payload of SeaBIOS and another (i think) u-boot, in 
searching online for one of the post_code values I stumbled on a post 
(http://lists.denx.de/pipermail/u-boot/2016-January/241577.html) noting that 
u-boot has post codes of its own. I was wondering if there was a consolidation 
of most (if not all) of the post_codes used, like there sort of is in coreboot 
at /src/console/post_code.h; or if there is not would someone mind giving me a 
direction on what function(s) u-boot uses to post the u-boot post_codes; i.e. 
coreboot utilizes a function called post_code as well as asm code and some of 
the binaries have their own post codes  - is there anything like that in u-boot?


Thank you for your time.

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

[U-Boot] Rockchip RK3288 regulator device table problem

[Rick Bronson]

Hi All,

  How do I enable a particular regulator upon boot?  I have two
identically set LDO entries:

vccio_en: LDO_REG1 {
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
regulator-name = "vccio_en";
regulator-state-mem {
regulator-on-in-suspend;
regulator-suspend-microvolt = <330>;
};
};

vcc33_mic: LDO_REG2 {
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
regulator-name = "vcc33_mic";
regulator-state-mem {
regulator-on-in-suspend;
regulator-suspend-microvolt = <330>;
};
};

  Yet one is enabled, the other disabled, any idea why?:

=> regulator status
Name EnableduV mA Mode
...
vccio_en enabled   330  - -
vcc33_micdisabled  330  - -

  And oddly, the uV values actually don't come from the DT but from
the rk808_ldo table in drivers/power/regulator/rk808.c

  Any ideas?

Thanks for any help.

  Rick



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

[U-Boot] [PATCH v2] net:phy:MSCC Add Support for VSC8530-VSC8531-VSC8540-VSC8541

[John Haechten]

net:phy:MSCC Add Support for VSC8530-VSC8531-VSC8540-VSC8541

Signed-off-by: John Haechten 
---

 drivers/net/phy/Makefile|   1 +
 drivers/net/phy/mscc.c  | 509 
 drivers/net/phy/phy.c   |   3 +
 include/config_phylib_all_drivers.h |   1 +
 include/configs/am335x_evm.h|   3 +
 include/phy.h   |   1 +
 6 files changed, 518 insertions(+)
 create mode 100644 drivers/net/phy/mscc.c

diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile index 
1e299b9..d372971 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -27,3 +27,4 @@ obj-$(CONFIG_PHY_TERANETICS) += teranetics.o
 obj-$(CONFIG_PHY_TI) += ti.o
 obj-$(CONFIG_PHY_XILINX) += xilinx_phy.o
 obj-$(CONFIG_PHY_VITESSE) += vitesse.o
+obj-$(CONFIG_PHY_MSCC) += mscc.o
diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c new file mode 
100644 index 000..e665b50
--- /dev/null
+++ b/drivers/net/phy/mscc.c
@@ -0,0 +1,509 @@
+/*
+ * Microsemi PHY drivers
+ *
+ * SPDX-License-Identifier: The MIT License (MIT)
+ *
+ * Copyright (c) 2016 Microsemi Corporation
+ *
+ * Author: John Haechten
+ *
+ */
+
+#include 
+#include 
+
+/* Microsemi PHY ID's */
+#define PHY_ID_VSC8530  0x00070560
+#define PHY_ID_VSC8531  0x00070570
+#define PHY_ID_VSC8540  0x00070760
+#define PHY_ID_VSC8541  0x00070770
+
+/* Microsemi VSC85xx PHY Register Pages */
+#define MSCC_EXT_PAGE_ACCESS31 /* Page Access Register */
+#define MSCC_PHY_PAGE_STD  0x /* Standard registers */
+#define MSCC_PHY_PAGE_EXT1 0x0001 /* Extended registers - page 1 */
+#define MSCC_PHY_PAGE_EXT2 0x0002 /* Extended registers - page 2 */
+#define MSCC_PHY_PAGE_EXT3 0x0003 /* Extended registers - page 3 */
+#define MSCC_PHY_PAGE_EXT4 0x0004 /* Extended registers - page 4 */
+#define MSCC_PHY_PAGE_GPIO 0x0010 /* GPIO registers */
+#define MSCC_PHY_PAGE_TEST 0x2A30 /* TEST Page registers */
+#define MSCC_PHY_PAGE_TR   0x52B5 /* Token Ring Page registers */
+
+/* Std Page Register 28 - PHY AUX Control/Status */
+#define MIIM_AUX_CNTRL_STAT_REG28
+#define MIIM_AUX_CNTRL_STAT_ACTIPHY_TO (0x0004)
+#define MIIM_AUX_CNTRL_STAT_F_DUPLEX   (0x0020)
+#define MIIM_AUX_CNTRL_STAT_SPEED_MASK (0x0018)
+#define MIIM_AUX_CNTRL_STAT_SPEED_POS  (3)
+#define MIIM_AUX_CNTRL_STAT_SPEED_10M  (0x0)
+#define MIIM_AUX_CNTRL_STAT_SPEED_100M (0x1)
+#define MIIM_AUX_CNTRL_STAT_SPEED_1000M(0x2)
+
+/* Std Page Register 23 - Extended PHY CTRL_1 */
+#define MSCC_PHY_EXT_PHY_CNTL_1_REG23
+#define MAC_IF_SELECTION_MASK  (0x1800)
+#define MAC_IF_SELECTION_GMII  (0)
+#define MAC_IF_SELECTION_RMII  (1)
+#define MAC_IF_SELECTION_RGMII (2)
+#define MAC_IF_SELECTION_POS   (11)
+#define MAC_IF_SELECTION_WIDTH (2)
+
+/* Extended Page 2 Register 20E2 */
+#define MSCC_PHY_RGMII_CNTL_REG20
+#define VSC_FAST_LINK_FAIL2_ENA_MASK   (0x8000)
+#define RX_CLK_OUT_MASK(0x0800)
+#define RX_CLK_OUT_POS (11)
+#define RX_CLK_OUT_WIDTH   (1)
+#define RX_CLK_OUT_NORMAL  (0)
+#define RX_CLK_OUT_DISABLE (1)
+#define RGMII_RX_CLK_DELAY_POS (4)
+#define RGMII_RX_CLK_DELAY_WIDTH   (3)
+#define RGMII_RX_CLK_DELAY_MASK(0x0070)
+#define RGMII_TX_CLK_DELAY_POS (0)
+#define RGMII_TX_CLK_DELAY_WIDTH   (3)
+#define RGMII_TX_CLK_DELAY_MASK(0x0007)
+
+/* Extended Page 2 Register 27E2 */
+#define MSCC_PHY_WOL_MAC_CONTROL   27
+#define EDGE_RATE_CNTL_POS (5)
+#define EDGE_RATE_CNTL_WIDTH   (3)
+#define EDGE_RATE_CNTL_MASK(0x00E0)
+#define RMII_CLK_OUT_ENABLE_POS(4)
+#define RMII_CLK_OUT_ENABLE_WIDTH  (1)
+#define RMII_CLK_OUT_ENABLE_MASK   (0x10)
+
+/* Token Ring Page 0x52B5 Registers */
+#define MSCC_PHY_REG_TR_ADDR_1616
+#define MSCC_PHY_REG_TR_DATA_1717
+#define MSCC_PHY_REG_TR_DATA_1818
+
+/* Token Ring - Read Value in */
+#define MSCC_PHY_TR_16_READ(0xA000)
+/* Token Ring - Write Value out */
+#define MSCC_PHY_TR_16_WRITE   (0x8000)
+
+/* Token Ring Registers */
+#define MSCC_PHY_TR_LINKDETCTRL_POS(3)
+#define MSCC_PHY_TR_LINKDETCTRL_WIDTH  (2)
+#define MSCC_PHY_TR_LINKDETCTRL_VAL(3)
+#define MSCC_PHY_TR_LINKDETCTRL_MASK   (0x0018)
+#define MSCC_PHY_TR_LINKDETCTRL_ADDR   (0x07F8)
+
+#define MSCC_PHY_TR_VGATHRESH100_POS   (0)
+#define MSCC_PHY_TR_VGATHRESH100_WIDTH (7)
+#define MSCC_PHY_TR_VGATHRESH100_VAL   (0x0018)
+#define MSCC_PHY_TR_VGATHRESH100_MASK  (0x007f)
+#define MSCC_PHY_TR_VGATHRESH100_ADDR  (0x0FA4)
+
+#define MSCC_PHY_TR_VGAGAIN10_U_POS(0)
+#define MSCC_PHY_TR_VGAGAIN10_U_WIDTH  

Re: [U-Boot] [PATCH v3 02/13] net: fec_mxc: Convert into driver model

[Jagan Teki]

On Dec 9, 2016 7:22 PM, "Joe Hershberger"  wrote:

Hi Jagan,

On Mon, Dec 5, 2016 at 5:00 PM, Jagan Teki  wrote:
> From: Jagan Teki 
>
> This patch add driver model support for fec_mxc driver.
>
> Cc: Simon Glass 
> Cc: Joe Hershberger 
> Cc: Peng Fan 
> Cc: Stefano Babic 
> Cc: Michael Trimarchi 
> Signed-off-by: Jagan Teki 
> ---
> Changes for v3:
> - Removed the stub functions[1] and revert back to previous changes where
#ifdef on
>   each function call. We can't use the stub functions to minimize the
#ifdef's as the
>   driver is organize the code in such a way that it can't modularized the
code. So better
>   to use #ifdef to not to break the non-dm.
>
> [1] http://git.denx.de/?p=u-boot/u-boot-imx.git;a=commitdiff;h=
fa2ce02b73fa59fe91d2d0ad61bf837392e03ab9

So the plan is to drop that from u-boot-imx and use this instead? If so,


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

Re: [U-Boot] [U-Boot, 1/1] arm: mach-omap2: Fix secure file generation

[Andrew F. Davis]

On 12/09/2016 03:30 PM, Tom Rini wrote:
> On Fri, Dec 09, 2016 at 02:24:32PM -0600, Andrew F. Davis wrote:
>> On 12/09/2016 02:10 PM, Tom Rini wrote:
>>> On Fri, Dec 09, 2016 at 02:05:29PM -0600, Andrew F. Davis wrote:
 On 12/09/2016 01:59 PM, Tom Rini wrote:
> On Thu, Dec 08, 2016 at 04:48:07PM -0600, Andrew F. Davis wrote:
>
>> When TI_SECURE_DEV_PKG is not defined we warn that the file '*_HS' was
>> not generated but generate an unsigned one anyway. When TI_SECURE_DEV_PKG
>> is exported and the user re-builds, make will detect this file as
>> unchangedand and so assume it does not need to be re-generated. This
>> causes it to pack unsigned files. Fix this by not generating these
>> fake unsigned *_HS files.
>>
>> Signed-off-by: Andrew F. Davis 
>> Reviewed-by: Tom Rini 
>> ---
>>  arch/arm/mach-omap2/config_secure.mk | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/config_secure.mk 
>> b/arch/arm/mach-omap2/config_secure.mk
>> index 1122439..33c7059 100644
>> --- a/arch/arm/mach-omap2/config_secure.mk
>> +++ b/arch/arm/mach-omap2/config_secure.mk
>> @@ -35,12 +35,12 @@ cmd_omapsecureimg = 
>> $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh \
>>  else
>>  cmd_omapsecureimg = echo "WARNING:" \
>>  "$(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh not 
>> found." \
>> -"$@ was NOT created!"; cp $< $@
>> +"$@ was NOT created!";
>>  endif
>>  else
>>  cmd_omapsecureimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \
>>  "variable must be defined for TI secure devices." \
>> -"$@ was NOT created!"; cp $< $@
>> +"$@ was NOT created!";
>>  endif
>>  endif
>
> OK, but now that I build test this (without the tools present) this is a
> NAK.  The root problem is that if we don't make that dummy file we then:
>arm:  +   am57xx_hs_evm
> +(am57xx_hs_evm) ./tools/mkimage: Can't open u-boot-nodtb_HS.bin: No such 
> file or directory
> +(am57xx_hs_evm) ./tools/mkimage: failed to build FIT
> +(am57xx_hs_evm) make[1]: *** [u-boot_HS.img] Error 1
> +(am57xx_hs_evm) make: *** [sub-make] Error 2

 Is this not okay? build *should* fail if TI_SECURE_DEV_PKG is not
 defined. You cannot sign images that *need* to be signed to work on this
 platform, making a fake un-bootable image instead of failing is a hack
 and it confuses the make system when you do put the signing tool in-place.
>>>
>>> Well, I suppose this is a valid question.  I run into it failing as I
>>> (and travis-ci) build all ARM targets.  Maybe we can have the build not
>>> happen (and echo a Warning) and then not invoke mkimage later on if the
>>> env isn't right?
>>
>> For test building you can export TI_SECURE_DEV_PKG to point to a dummy
>> signing tool which just runs cp $1 $2. For real world building this tool
>> is needed just as much as the compiler, if you don't have it you will
>> not build working images, build needs to fail here.
> 
> Hmmm, OK.  But can we not automate that based on TI_SECURE_DEV_PKG being
> unset?
> 

That is what we already do, if TI_SECURE_DEV_PKG is unset, build should
fail, but right now it fakes a successful build, most likely to keep the
auto-validation happy as it does not have the signing tool.

The only other thing I can think of is to always try to sign the images,
even when they have not changed on disk since the last build. Would this
be acceptable?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 1/1] arm: mach-omap2: Fix secure file generation

[Tom Rini]

On Fri, Dec 09, 2016 at 02:24:32PM -0600, Andrew F. Davis wrote:
> On 12/09/2016 02:10 PM, Tom Rini wrote:
> > On Fri, Dec 09, 2016 at 02:05:29PM -0600, Andrew F. Davis wrote:
> >> On 12/09/2016 01:59 PM, Tom Rini wrote:
> >>> On Thu, Dec 08, 2016 at 04:48:07PM -0600, Andrew F. Davis wrote:
> >>>
>  When TI_SECURE_DEV_PKG is not defined we warn that the file '*_HS' was
>  not generated but generate an unsigned one anyway. When TI_SECURE_DEV_PKG
>  is exported and the user re-builds, make will detect this file as
>  unchangedand and so assume it does not need to be re-generated. This
>  causes it to pack unsigned files. Fix this by not generating these
>  fake unsigned *_HS files.
> 
>  Signed-off-by: Andrew F. Davis 
>  Reviewed-by: Tom Rini 
>  ---
>   arch/arm/mach-omap2/config_secure.mk | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
>  diff --git a/arch/arm/mach-omap2/config_secure.mk 
>  b/arch/arm/mach-omap2/config_secure.mk
>  index 1122439..33c7059 100644
>  --- a/arch/arm/mach-omap2/config_secure.mk
>  +++ b/arch/arm/mach-omap2/config_secure.mk
>  @@ -35,12 +35,12 @@ cmd_omapsecureimg = 
>  $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh \
>   else
>   cmd_omapsecureimg = echo "WARNING:" \
>   "$(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh not 
>  found." \
>  -"$@ was NOT created!"; cp $< $@
>  +"$@ was NOT created!";
>   endif
>   else
>   cmd_omapsecureimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \
>   "variable must be defined for TI secure devices." \
>  -"$@ was NOT created!"; cp $< $@
>  +"$@ was NOT created!";
>   endif
>   endif
> >>>
> >>> OK, but now that I build test this (without the tools present) this is a
> >>> NAK.  The root problem is that if we don't make that dummy file we then:
> >>>arm:  +   am57xx_hs_evm
> >>> +(am57xx_hs_evm) ./tools/mkimage: Can't open u-boot-nodtb_HS.bin: No such 
> >>> file or directory
> >>> +(am57xx_hs_evm) ./tools/mkimage: failed to build FIT
> >>> +(am57xx_hs_evm) make[1]: *** [u-boot_HS.img] Error 1
> >>> +(am57xx_hs_evm) make: *** [sub-make] Error 2
> >>
> >> Is this not okay? build *should* fail if TI_SECURE_DEV_PKG is not
> >> defined. You cannot sign images that *need* to be signed to work on this
> >> platform, making a fake un-bootable image instead of failing is a hack
> >> and it confuses the make system when you do put the signing tool in-place.
> > 
> > Well, I suppose this is a valid question.  I run into it failing as I
> > (and travis-ci) build all ARM targets.  Maybe we can have the build not
> > happen (and echo a Warning) and then not invoke mkimage later on if the
> > env isn't right?
> 
> For test building you can export TI_SECURE_DEV_PKG to point to a dummy
> signing tool which just runs cp $1 $2. For real world building this tool
> is needed just as much as the compiler, if you don't have it you will
> not build working images, build needs to fail here.

Hmmm, OK.  But can we not automate that based on TI_SECURE_DEV_PKG being
unset?

-- 
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/5] net: phy: Add support for Marvell M88E1512

[Joe Hershberger]

On Fri, Dec 9, 2016 at 6:41 AM, Stefan Roese  wrote:
> Hi Phil,
>
>
> On 09.12.2016 13:38, Phil Edworthy wrote:
>>
>> On 09 December 2016 12:16, Stefan Roese wrote:
>>>
>>> On 09.12.2016 11:40, Phil Edworthy wrote:

 Signed-off-by: Phil Edworthy 
 ---
  drivers/net/phy/marvell.c | 11 +++
  1 file changed, 11 insertions(+)

 diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
 index 06029c0..a7ea435 100644
 --- a/drivers/net/phy/marvell.c
 +++ b/drivers/net/phy/marvell.c
 @@ -560,6 +560,16 @@ static struct phy_driver M88E1510_driver = {
 .shutdown = _shutdown,
  };

 +static struct phy_driver M88E1512_driver = {
 +   .name = "Marvell 88E1512",
 +   .uid = 0x01410dd4,
 +   .mask = 0xfff,
 +   .features = PHY_GBIT_FEATURES,
 +   .config = _config,
 +   .startup = _startup,
 +   .shutdown = _shutdown,
 +};
 +
  static struct phy_driver M88E1518_driver = {
 .name = "Marvell 88E1518",
 .uid = 0x1410dd1,
 @@ -591,6 +601,7 @@ int phy_marvell_init(void)
 phy_register(_driver);
 phy_register(_driver);
 phy_register(_driver);
 +   phy_register(_driver);
 phy_register(_driver);
>>>
>>>
>>> Do you need some special handling for the M88E1512 or is it identical
>>> to the 1518 handling? If its identical, why do we need a new entry
>>> for this PHY?
>>
>> Good point, they are the same except for the uid so no need for a new
>> entry. I'll change the mask of the 1518 to cover it.

I'm not sure I get it. The previous patch was to pay attention to the
last nibble of the ID (unlike Linux) so that the special 1518 handler
is run. Now you want to have a 1510 + 1512 handler? Are you planning a
funky mask like 0xff1? Maybe it would be better to just have them
checked explicitly since there is need for discrimination within the
151x family.

>
> Thanks.
>
>> Btw, what's the best way to indicate that the code supports the 1512
>> as well? It's not so easy to see if the code supports a particular device
>> ahead of hardware arriving, other than trying to match the uid's
>> manually.
>
>
> A comment would be welcome here. Not sure if this is done in a more
> generic way in the Linux PHY drivers. You might want to check there
> as well...
>
> Thanks,
> Stefan
>
> ___
> 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] [PATCH 1/5] net: phy: Fix mask so that we can identify Marvell 88E1518

[Joe Hershberger]

On Fri, Dec 9, 2016 at 6:13 AM, Stefan Roese  wrote:
> On 09.12.2016 11:40, Phil Edworthy wrote:
>>
>> The mask for the 88E1510 meant that the 88E1518 code would never be
>> used.
>>
>> Signed-off-by: Phil Edworthy 

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

Re: [U-Boot] [U-Boot, 1/1] arm: mach-omap2: Fix secure file generation

[Andrew F. Davis]

On 12/09/2016 02:10 PM, Tom Rini wrote:
> On Fri, Dec 09, 2016 at 02:05:29PM -0600, Andrew F. Davis wrote:
>> On 12/09/2016 01:59 PM, Tom Rini wrote:
>>> On Thu, Dec 08, 2016 at 04:48:07PM -0600, Andrew F. Davis wrote:
>>>
 When TI_SECURE_DEV_PKG is not defined we warn that the file '*_HS' was
 not generated but generate an unsigned one anyway. When TI_SECURE_DEV_PKG
 is exported and the user re-builds, make will detect this file as
 unchangedand and so assume it does not need to be re-generated. This
 causes it to pack unsigned files. Fix this by not generating these
 fake unsigned *_HS files.

 Signed-off-by: Andrew F. Davis 
 Reviewed-by: Tom Rini 
 ---
  arch/arm/mach-omap2/config_secure.mk | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-omap2/config_secure.mk 
 b/arch/arm/mach-omap2/config_secure.mk
 index 1122439..33c7059 100644
 --- a/arch/arm/mach-omap2/config_secure.mk
 +++ b/arch/arm/mach-omap2/config_secure.mk
 @@ -35,12 +35,12 @@ cmd_omapsecureimg = 
 $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh \
  else
  cmd_omapsecureimg = echo "WARNING:" \
"$(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh not found." \
 -  "$@ was NOT created!"; cp $< $@
 +  "$@ was NOT created!";
  endif
  else
  cmd_omapsecureimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \
"variable must be defined for TI secure devices." \
 -  "$@ was NOT created!"; cp $< $@
 +  "$@ was NOT created!";
  endif
  endif
>>>
>>> OK, but now that I build test this (without the tools present) this is a
>>> NAK.  The root problem is that if we don't make that dummy file we then:
>>>arm:  +   am57xx_hs_evm
>>> +(am57xx_hs_evm) ./tools/mkimage: Can't open u-boot-nodtb_HS.bin: No such 
>>> file or directory
>>> +(am57xx_hs_evm) ./tools/mkimage: failed to build FIT
>>> +(am57xx_hs_evm) make[1]: *** [u-boot_HS.img] Error 1
>>> +(am57xx_hs_evm) make: *** [sub-make] Error 2
>>
>> Is this not okay? build *should* fail if TI_SECURE_DEV_PKG is not
>> defined. You cannot sign images that *need* to be signed to work on this
>> platform, making a fake un-bootable image instead of failing is a hack
>> and it confuses the make system when you do put the signing tool in-place.
> 
> Well, I suppose this is a valid question.  I run into it failing as I
> (and travis-ci) build all ARM targets.  Maybe we can have the build not
> happen (and echo a Warning) and then not invoke mkimage later on if the
> env isn't right?
> 

For test building you can export TI_SECURE_DEV_PKG to point to a dummy
signing tool which just runs cp $1 $2. For real world building this tool
is needed just as much as the compiler, if you don't have it you will
not build working images, build needs to fail here.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 1/1] arm: mach-omap2: Fix secure file generation

[Tom Rini]

On Fri, Dec 09, 2016 at 02:05:29PM -0600, Andrew F. Davis wrote:
> On 12/09/2016 01:59 PM, Tom Rini wrote:
> > On Thu, Dec 08, 2016 at 04:48:07PM -0600, Andrew F. Davis wrote:
> > 
> >> When TI_SECURE_DEV_PKG is not defined we warn that the file '*_HS' was
> >> not generated but generate an unsigned one anyway. When TI_SECURE_DEV_PKG
> >> is exported and the user re-builds, make will detect this file as
> >> unchangedand and so assume it does not need to be re-generated. This
> >> causes it to pack unsigned files. Fix this by not generating these
> >> fake unsigned *_HS files.
> >>
> >> Signed-off-by: Andrew F. Davis 
> >> Reviewed-by: Tom Rini 
> >> ---
> >>  arch/arm/mach-omap2/config_secure.mk | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-omap2/config_secure.mk 
> >> b/arch/arm/mach-omap2/config_secure.mk
> >> index 1122439..33c7059 100644
> >> --- a/arch/arm/mach-omap2/config_secure.mk
> >> +++ b/arch/arm/mach-omap2/config_secure.mk
> >> @@ -35,12 +35,12 @@ cmd_omapsecureimg = 
> >> $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh \
> >>  else
> >>  cmd_omapsecureimg = echo "WARNING:" \
> >>"$(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh not found." \
> >> -  "$@ was NOT created!"; cp $< $@
> >> +  "$@ was NOT created!";
> >>  endif
> >>  else
> >>  cmd_omapsecureimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \
> >>"variable must be defined for TI secure devices." \
> >> -  "$@ was NOT created!"; cp $< $@
> >> +  "$@ was NOT created!";
> >>  endif
> >>  endif
> > 
> > OK, but now that I build test this (without the tools present) this is a
> > NAK.  The root problem is that if we don't make that dummy file we then:
> >arm:  +   am57xx_hs_evm
> > +(am57xx_hs_evm) ./tools/mkimage: Can't open u-boot-nodtb_HS.bin: No such 
> > file or directory
> > +(am57xx_hs_evm) ./tools/mkimage: failed to build FIT
> > +(am57xx_hs_evm) make[1]: *** [u-boot_HS.img] Error 1
> > +(am57xx_hs_evm) make: *** [sub-make] Error 2
> 
> Is this not okay? build *should* fail if TI_SECURE_DEV_PKG is not
> defined. You cannot sign images that *need* to be signed to work on this
> platform, making a fake un-bootable image instead of failing is a hack
> and it confuses the make system when you do put the signing tool in-place.

Well, I suppose this is a valid question.  I run into it failing as I
(and travis-ci) build all ARM targets.  Maybe we can have the build not
happen (and echo a Warning) and then not invoke mkimage later on if the
env isn't right?

-- 
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 1/5] net: phy: Fix mask so that we can identify Marvell 88E1518

[Joe Hershberger]

On Fri, Dec 9, 2016 at 7:38 AM, Phil Edworthy  wrote:
> The mask for the 88E1510 meant that the 88E1518 code would never be
> used.
>
> Signed-off-by: Phil Edworthy 
> Reviewed-by: Stefan Roese 

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

Re: [U-Boot] Pull request: u-boot-net.git master

[Michal Simek]

Hi Joe,

2016-12-09 19:35 GMT+01:00 Joe Hershberger :

> On Fri, Dec 9, 2016 at 11:43 AM, Michal Simek  wrote:
> > Hi Joe,
> >
> > 2016-12-09 17:22 GMT+01:00 Joe Hershberger :
> >>
> >> Hi Tom,
> >>
> >> On Fri, Dec 9, 2016 at 6:12 AM, Tom Rini  wrote:
> >> > On Thu, Dec 08, 2016 at 10:37:26AM -0600, Joe Hershberger wrote:
> >> >
> >> >> Hi Tom,
> >> >>
> >> >> The following changes since commit
> >> >> 388019f1e2166638453bc4e0cc5d138c2a19e0c9:
> >> >>
> >> >>   Merge branch 'master' of git://git.denx.de/u-boot-usb (2016-12-06
> >> >> 08:07:20 -0500)
> >> >>
> >> >> are available in the git repository at:
> >> >>
> >> >>
> >> >>   git://git.denx.de/u-boot-net.git master
> >> >>
> >> >> for you to fetch changes up to
> >> >> bb135a0180c31fbd7456021fb9700b49bba7f533:
> >> >>
> >> >>   net/phy/vitesse: Rework RGMII skew configuration for VSC8601
> >> >> (2016-12-08 10:36:22 -0600)
> >> >
> >> > This is a NAK and is what is breaking microblaze-generic and
> >> > imgtec_xilfpga at least:
>
> Uhh... so it's not a NAK? This PR seems to be in your master.
>
> I've rebased and have no commits left on top of your master. I've
> pushed it for travis as another test anyway.
> https://travis-ci.org/jhershbe/u-boot/builds/182680490
>
> >> > +(imgtec_xilfpga,microblaze-generic)   ret =
> >> > mdio_register_seq(emaclite->bus,
> >> > dev->seq);+(imgtec_xilfpga,microblaze-generic)   ^
> >> > +(imgtec_xilfpga,microblaze-generic) drivers/net/built-in.o: In
> function
> >> > `emaclite_probe':
> >> > +(imgtec_xilfpga)
> >> > ../drivers/net/xilinx_emaclite.c:(.text.emaclite_probe+0x64):
> undefined
> >> > reference to `mdio_register_seq'
> >> > +(imgtec_xilfpga,microblaze-generic) make[1]: *** [u-boot] Error 1
> >> > +(imgtec_xilfpga,microblaze-generic) make: *** [sub-make] Error 2
> >> > +(microblaze-generic)   ret = mdio_register_seq(priv->bus, dev->seq);
> >> > +(microblaze-generic) drivers/net/built-in.o: In function
> >> > `axi_emac_probe': +(microblaze-generic)
> >> > build/../drivers/net/xilinx_axi_emac.c:652: undefined reference to
> >> > `mdio_register_seq'
> >> > +(microblaze-generic) build/../drivers/net/xilinx_emaclite.c:570:
> >> > undefined reference to `mdio_register_seq'
> >>
> >> This is strange... I build tested this on Travis.
> >>
> >> https://travis-ci.org/jhershbe/u-boot/builds/180270329
> >>
> >> Are we missing microblaze coverage on Travis or something?
> >
> >
> >
> > This patches went to the tree by accident. Tom reverted that incorrect
> > merge.
> > Adding mdio_register_seq was sent recently for review and it shouldn't
> have
> > these compilation issue.
> > I have no idea what's wrong with imgtec_xilfpga.
> > And microblaze should be covered by travis already.
>


I have some patches in master but nothing what is ready for merge.
And Tom lost one email that he merged something what I didn't ask for.
Anyway I think it is good reason start to use pull request based on tags
not on branches.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/5] net: phy: Marvell 88E151x: Add support for RGMII

[Joe Hershberger]

Hi Phil,

On Fri, Dec 9, 2016 at 7:38 AM, Phil Edworthy  wrote:
> This has been tested with a Marvell 88E1512 PHY.
>
> Signed-off-by: Phil Edworthy 
> Reviewed-by: Stefan Roese 
> ---
> v2:
>  Rebased on top of Joe's code to use macros
> ---
>  drivers/net/phy/marvell.c | 17 +
>  1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index 5adfe7d..646b00d 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -94,6 +94,7 @@
>  #define MIIM_88E151x_INT_EN_OFFS   7
>  /* Page 18 registers */
>  #define MIIM_88E151x_GENERAL_CTRL  20
> +#define MIIM_88E151x_MODE_RGMII0

I'm not sure why this is needed. The HW reset value for the mode is
0x7 (RGMII auto detect mode). Would it not be sufficient to simply not
change it if the mode is RGMII?

>  #define MIIM_88E151x_MODE_SGMII1
>  #define MIIM_88E151x_RESET_OFFS15
>
> @@ -315,14 +316,22 @@ static int m88e1518_config(struct phy_device *phydev)
> phy_write(phydev, MDIO_DEVAD_NONE, 16, 0x2159);
> phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE, 0x);
>
> -   /* SGMII-to-Copper mode initialization */
> -   if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
> +   /* SGMII/RGMII-to-Copper mode initialization */
> +   if ((phydev->interface == PHY_INTERFACE_MODE_SGMII) ||
> +   phy_interface_is_rgmii(phydev)) {
> +   u16 mode;
> +
> +   if (phydev->interface == PHY_INTERFACE_MODE_SGMII)
> +   mode = MIIM_88E151x_MODE_SGMII;
> +   else
> +   mode = MIIM_88E151x_MODE_RGMII;
> +
> /* Select page 18 */
> phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE, 18);
>
> -   /* In reg 20, write MODE[2:0] = 0x1 (SGMII to Copper) */
> +   /* In reg 20, write MODE[2:0], SGMII or RGMII to Copper */
> m88e1518_phy_writebits(phydev, MIIM_88E151x_GENERAL_CTRL,
> -  0, 3, MIIM_88E151x_MODE_SGMII);
> +  0, 3, mode);
>
> /* PHY reset is necessary after changing MODE[2:0] */
> m88e1518_phy_writebits(phydev, MIIM_88E151x_GENERAL_CTRL,
> --
> 2.7.4
>
> ___
> 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] [PATCH 4/5] net: phy: Marvell 88E151x: Increase delay after init

[Joe Hershberger]

On Fri, Dec 9, 2016 at 4:41 AM, Phil Edworthy  wrote:
> On Marvell 88E1512, the delay is not enough when connected
> to some external switches (e.g. Netgear GS108E).
>
> Signed-off-by: Phil Edworthy 

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

Re: [U-Boot] [U-Boot, 1/1] arm: mach-omap2: Fix secure file generation

[Andrew F. Davis]

On 12/09/2016 01:59 PM, Tom Rini wrote:
> On Thu, Dec 08, 2016 at 04:48:07PM -0600, Andrew F. Davis wrote:
> 
>> When TI_SECURE_DEV_PKG is not defined we warn that the file '*_HS' was
>> not generated but generate an unsigned one anyway. When TI_SECURE_DEV_PKG
>> is exported and the user re-builds, make will detect this file as
>> unchangedand and so assume it does not need to be re-generated. This
>> causes it to pack unsigned files. Fix this by not generating these
>> fake unsigned *_HS files.
>>
>> Signed-off-by: Andrew F. Davis 
>> Reviewed-by: Tom Rini 
>> ---
>>  arch/arm/mach-omap2/config_secure.mk | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/config_secure.mk 
>> b/arch/arm/mach-omap2/config_secure.mk
>> index 1122439..33c7059 100644
>> --- a/arch/arm/mach-omap2/config_secure.mk
>> +++ b/arch/arm/mach-omap2/config_secure.mk
>> @@ -35,12 +35,12 @@ cmd_omapsecureimg = 
>> $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh \
>>  else
>>  cmd_omapsecureimg = echo "WARNING:" \
>>  "$(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh not found." \
>> -"$@ was NOT created!"; cp $< $@
>> +"$@ was NOT created!";
>>  endif
>>  else
>>  cmd_omapsecureimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \
>>  "variable must be defined for TI secure devices." \
>> -"$@ was NOT created!"; cp $< $@
>> +"$@ was NOT created!";
>>  endif
>>  endif
> 
> OK, but now that I build test this (without the tools present) this is a
> NAK.  The root problem is that if we don't make that dummy file we then:
>arm:  +   am57xx_hs_evm
> +(am57xx_hs_evm) ./tools/mkimage: Can't open u-boot-nodtb_HS.bin: No such 
> file or directory
> +(am57xx_hs_evm) ./tools/mkimage: failed to build FIT
> +(am57xx_hs_evm) make[1]: *** [u-boot_HS.img] Error 1
> +(am57xx_hs_evm) make: *** [sub-make] Error 2
> 

Is this not okay? build *should* fail if TI_SECURE_DEV_PKG is not
defined. You cannot sign images that *need* to be signed to work on this
platform, making a fake un-bootable image instead of failing is a hack
and it confuses the make system when you do put the signing tool in-place.

> So perhaps we need to make use of some other logic to rebuild on
> TI_SECURE_DEV_PKG changing?
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 1/1] arm: mach-omap2: Fix secure file generation

[Tom Rini]

On Thu, Dec 08, 2016 at 04:48:07PM -0600, Andrew F. Davis wrote:

> When TI_SECURE_DEV_PKG is not defined we warn that the file '*_HS' was
> not generated but generate an unsigned one anyway. When TI_SECURE_DEV_PKG
> is exported and the user re-builds, make will detect this file as
> unchangedand and so assume it does not need to be re-generated. This
> causes it to pack unsigned files. Fix this by not generating these
> fake unsigned *_HS files.
> 
> Signed-off-by: Andrew F. Davis 
> Reviewed-by: Tom Rini 
> ---
>  arch/arm/mach-omap2/config_secure.mk | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/config_secure.mk 
> b/arch/arm/mach-omap2/config_secure.mk
> index 1122439..33c7059 100644
> --- a/arch/arm/mach-omap2/config_secure.mk
> +++ b/arch/arm/mach-omap2/config_secure.mk
> @@ -35,12 +35,12 @@ cmd_omapsecureimg = 
> $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh \
>  else
>  cmd_omapsecureimg = echo "WARNING:" \
>   "$(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh not found." \
> - "$@ was NOT created!"; cp $< $@
> + "$@ was NOT created!";
>  endif
>  else
>  cmd_omapsecureimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \
>   "variable must be defined for TI secure devices." \
> - "$@ was NOT created!"; cp $< $@
> + "$@ was NOT created!";
>  endif
>  endif

OK, but now that I build test this (without the tools present) this is a
NAK.  The root problem is that if we don't make that dummy file we then:
   arm:  +   am57xx_hs_evm
+(am57xx_hs_evm) ./tools/mkimage: Can't open u-boot-nodtb_HS.bin: No such file 
or directory
+(am57xx_hs_evm) ./tools/mkimage: failed to build FIT
+(am57xx_hs_evm) make[1]: *** [u-boot_HS.img] Error 1
+(am57xx_hs_evm) make: *** [sub-make] Error 2

So perhaps we need to make use of some other logic to rebuild on
TI_SECURE_DEV_PKG changing?

-- 
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/5] net: phy: Marvell: Use phy_interface_is_rgmii helper function

[Joe Hershberger]

On Fri, Dec 9, 2016 at 4:41 AM, Phil Edworthy  wrote:
> Signed-off-by: Phil Edworthy 

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

Re: [U-Boot] [PATCH v2 5/5] net: phy: Marvell: Use phy_interface_is_rgmii helper function

[Joe Hershberger]

On Fri, Dec 9, 2016 at 7:38 AM, Phil Edworthy  wrote:
> Signed-off-by: Phil Edworthy 
> Reviewed-by: Stefan Roese 

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

Re: [U-Boot] [PATCH v2 2/5] net: phy: Add support for Marvell M88E1512

[Joe Hershberger]

On Fri, Dec 9, 2016 at 7:43 AM, Stefan Roese  wrote:
> On 09.12.2016 14:38, Phil Edworthy wrote:
>>
>> This device also works with the 88E1518 code, so we just adjust
>> the UID mask accordingly.
>>
>> Signed-off-by: Phil Edworthy 
>> ---
>> v2:
>>  Don't add a new entry, just adjust the UID mask.

Alright. I assume we will see what other IDs they come out with.

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

Re: [U-Boot] [PATCH 2/5] net: phy: Add support for Marvell M88E1512

[Joe Hershberger]

On Fri, Dec 9, 2016 at 12:54 PM, Joe Hershberger
 wrote:
> On Fri, Dec 9, 2016 at 6:41 AM, Stefan Roese  wrote:
>> Hi Phil,
>>
>>
>> On 09.12.2016 13:38, Phil Edworthy wrote:
>>>
>>> On 09 December 2016 12:16, Stefan Roese wrote:

 On 09.12.2016 11:40, Phil Edworthy wrote:
>
> Signed-off-by: Phil Edworthy 
> ---
>  drivers/net/phy/marvell.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index 06029c0..a7ea435 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -560,6 +560,16 @@ static struct phy_driver M88E1510_driver = {
> .shutdown = _shutdown,
>  };
>
> +static struct phy_driver M88E1512_driver = {
> +   .name = "Marvell 88E1512",
> +   .uid = 0x01410dd4,
> +   .mask = 0xfff,
> +   .features = PHY_GBIT_FEATURES,
> +   .config = _config,
> +   .startup = _startup,
> +   .shutdown = _shutdown,
> +};
> +
>  static struct phy_driver M88E1518_driver = {
> .name = "Marvell 88E1518",
> .uid = 0x1410dd1,
> @@ -591,6 +601,7 @@ int phy_marvell_init(void)
> phy_register(_driver);
> phy_register(_driver);
> phy_register(_driver);
> +   phy_register(_driver);
> phy_register(_driver);


 Do you need some special handling for the M88E1512 or is it identical
 to the 1518 handling? If its identical, why do we need a new entry
 for this PHY?
>>>
>>> Good point, they are the same except for the uid so no need for a new
>>> entry. I'll change the mask of the 1518 to cover it.
>
> I'm not sure I get it. The previous patch was to pay attention to the
> last nibble of the ID (unlike Linux) so that the special 1518 handler
> is run. Now you want to have a 1510 + 1512 handler? Are you planning a
> funky mask like 0xff1? Maybe it would be better to just have them

I guess you were making the 1512 behave like the 1518, not the 1510 -
I see your follow-up patch used 0xffb as a mask.

Still seems a bit smelly to me, but I guess we can see where it ends
up with some future marvell phy.

> checked explicitly since there is need for discrimination within the
> 151x family.
>
>>
>> Thanks.
>>
>>> Btw, what's the best way to indicate that the code supports the 1512
>>> as well? It's not so easy to see if the code supports a particular device
>>> ahead of hardware arriving, other than trying to match the uid's
>>> manually.
>>
>>
>> A comment would be welcome here. Not sure if this is done in a more
>> generic way in the Linux PHY drivers. You might want to check there
>> as well...
>>
>> Thanks,
>> Stefan
>>
>> ___
>> 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] Pull request: u-boot-net.git master

[Tom Rini]

On Fri, Dec 09, 2016 at 12:35:59PM -0600, Joe Hershberger wrote:
> On Fri, Dec 9, 2016 at 11:43 AM, Michal Simek  wrote:
> > Hi Joe,
> >
> > 2016-12-09 17:22 GMT+01:00 Joe Hershberger :
> >>
> >> Hi Tom,
> >>
> >> On Fri, Dec 9, 2016 at 6:12 AM, Tom Rini  wrote:
> >> > On Thu, Dec 08, 2016 at 10:37:26AM -0600, Joe Hershberger wrote:
> >> >
> >> >> Hi Tom,
> >> >>
> >> >> The following changes since commit
> >> >> 388019f1e2166638453bc4e0cc5d138c2a19e0c9:
> >> >>
> >> >>   Merge branch 'master' of git://git.denx.de/u-boot-usb (2016-12-06
> >> >> 08:07:20 -0500)
> >> >>
> >> >> are available in the git repository at:
> >> >>
> >> >>
> >> >>   git://git.denx.de/u-boot-net.git master
> >> >>
> >> >> for you to fetch changes up to
> >> >> bb135a0180c31fbd7456021fb9700b49bba7f533:
> >> >>
> >> >>   net/phy/vitesse: Rework RGMII skew configuration for VSC8601
> >> >> (2016-12-08 10:36:22 -0600)
> >> >
> >> > This is a NAK and is what is breaking microblaze-generic and
> >> > imgtec_xilfpga at least:
> 
> Uhh... so it's not a NAK? This PR seems to be in your master.
> 
> I've rebased and have no commits left on top of your master. I've
> pushed it for travis as another test anyway.
> https://travis-ci.org/jhershbe/u-boot/builds/182680490

OK, thanks.  I messed things up slightly but I think we're all good now,
thanks for checking.

-- 
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 4/5] net: phy: Marvell 88E151x: Increase delay after init

[Joe Hershberger]

On Fri, Dec 9, 2016 at 7:38 AM, Phil Edworthy  wrote:
> On Marvell 88E1512, the delay is not enough when connected
> to some external switches (e.g. Netgear GS108E).
>
> Signed-off-by: Phil Edworthy 
> Reviewed-by: Stefan Roese 

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

Re: [U-Boot] [PATCH 2/2] net: xilinx: Use mdio_register_seq() to support multiple instances

[Joe Hershberger]

On Fri, Dec 9, 2016 at 12:39 AM, Michal Simek  wrote:
> axi_emac, emaclite and gem have the same issue with registering
> multiple instances with mdio busses. mdio bus name has to be uniq but
> drivers are setting up only one name for all.
> Use mdio_register_seq() and pass dev->seq number to allow multiple
> mdio instances registration.
>
> Reported-by: Phani Kiran Kara 
> Signed-off-by: Michal Simek 

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

Re: [U-Boot] [PATCH 1/2] common: miiphyutil: Add helper function for mdio bus name

[Joe Hershberger]

On Fri, Dec 9, 2016 at 12:39 AM, Michal Simek  wrote:
> The most of ethernet drivers are using this mdio registration sequence.
> strcpy(priv->bus->name, "emac");
> mdio_register(priv->bus);
> Where driver can be used only with one MDIO bus because only unique
> name should be used.
>
> Other drivers are using unique device name for MDIO registration to
> support multiple instances.
> snprintf(priv->bus->name, sizeof(bus->name), "%s", name);
>
> With DM dev->seq is used more even in logs
> (like random MAC address generation:
> printf("\nWarning: %s (eth%d) using random MAC address - %pM\n",
>dev->name, dev->seq, pdata->enetaddr);
> )
> where eth%d prefix is used.
>
> Simplify driver code to register mdio device with dev->seq number
> to simplify mdio registration and reduce code duplication across
> all drivers. With DM_SEQ_ALIAS enabled dev->seq reflects alias setting.
>
> Signed-off-by: Michal Simek 

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

Re: [U-Boot] Pull request: u-boot-net.git master

[Joe Hershberger]

On Fri, Dec 9, 2016 at 11:43 AM, Michal Simek  wrote:
> Hi Joe,
>
> 2016-12-09 17:22 GMT+01:00 Joe Hershberger :
>>
>> Hi Tom,
>>
>> On Fri, Dec 9, 2016 at 6:12 AM, Tom Rini  wrote:
>> > On Thu, Dec 08, 2016 at 10:37:26AM -0600, Joe Hershberger wrote:
>> >
>> >> Hi Tom,
>> >>
>> >> The following changes since commit
>> >> 388019f1e2166638453bc4e0cc5d138c2a19e0c9:
>> >>
>> >>   Merge branch 'master' of git://git.denx.de/u-boot-usb (2016-12-06
>> >> 08:07:20 -0500)
>> >>
>> >> are available in the git repository at:
>> >>
>> >>
>> >>   git://git.denx.de/u-boot-net.git master
>> >>
>> >> for you to fetch changes up to
>> >> bb135a0180c31fbd7456021fb9700b49bba7f533:
>> >>
>> >>   net/phy/vitesse: Rework RGMII skew configuration for VSC8601
>> >> (2016-12-08 10:36:22 -0600)
>> >
>> > This is a NAK and is what is breaking microblaze-generic and
>> > imgtec_xilfpga at least:

Uhh... so it's not a NAK? This PR seems to be in your master.

I've rebased and have no commits left on top of your master. I've
pushed it for travis as another test anyway.
https://travis-ci.org/jhershbe/u-boot/builds/182680490

>> > +(imgtec_xilfpga,microblaze-generic)   ret =
>> > mdio_register_seq(emaclite->bus,
>> > dev->seq);+(imgtec_xilfpga,microblaze-generic)   ^
>> > +(imgtec_xilfpga,microblaze-generic) drivers/net/built-in.o: In function
>> > `emaclite_probe':
>> > +(imgtec_xilfpga)
>> > ../drivers/net/xilinx_emaclite.c:(.text.emaclite_probe+0x64): undefined
>> > reference to `mdio_register_seq'
>> > +(imgtec_xilfpga,microblaze-generic) make[1]: *** [u-boot] Error 1
>> > +(imgtec_xilfpga,microblaze-generic) make: *** [sub-make] Error 2
>> > +(microblaze-generic)   ret = mdio_register_seq(priv->bus, dev->seq);
>> > +(microblaze-generic) drivers/net/built-in.o: In function
>> > `axi_emac_probe': +(microblaze-generic)
>> > build/../drivers/net/xilinx_axi_emac.c:652: undefined reference to
>> > `mdio_register_seq'
>> > +(microblaze-generic) build/../drivers/net/xilinx_emaclite.c:570:
>> > undefined reference to `mdio_register_seq'
>>
>> This is strange... I build tested this on Travis.
>>
>> https://travis-ci.org/jhershbe/u-boot/builds/180270329
>>
>> Are we missing microblaze coverage on Travis or something?
>
>
>
> This patches went to the tree by accident. Tom reverted that incorrect
> merge.
> Adding mdio_register_seq was sent recently for review and it shouldn't have
> these compilation issue.
> I have no idea what's wrong with imgtec_xilfpga.
> And microblaze should be covered by travis already.
>
> Thanks,
> Michal
>
> --
> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
> Maintainer of Linux kernel - Xilinx Zynq ARM architecture
> Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] net: phy: ti: Fix dp83867 RGMII_TXID interface path

[Joe Hershberger]

Hi Phil,

On Fri, Dec 9, 2016 at 4:46 AM, Phil Edworthy  wrote:
> There is code that is specifically for RGMII_TXID interface, but this
> will never get used because the code checks that the RGMII interface
> is RGMII_ID to RGMII_RXID; RGMII_TXID is after this.
>
> To fix this and avoid similar problems in the future, use the
> phy_interface_is_rgmii helper function.
>
> Signed-off-by: Phil Edworthy 

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

Re: [U-Boot] [PATCH v3 02/13] net: fec_mxc: Convert into driver model

[Joe Hershberger]

Hi Jagan,

On Mon, Dec 5, 2016 at 5:00 PM, Jagan Teki  wrote:
> From: Jagan Teki 
>
> This patch add driver model support for fec_mxc driver.
>
> Cc: Simon Glass 
> Cc: Joe Hershberger 
> Cc: Peng Fan 
> Cc: Stefano Babic 
> Cc: Michael Trimarchi 
> Signed-off-by: Jagan Teki 
> ---
> Changes for v3:
> - Removed the stub functions[1] and revert back to previous changes where 
> #ifdef on
>   each function call. We can't use the stub functions to minimize the 
> #ifdef's as the
>   driver is organize the code in such a way that it can't modularized the 
> code. So better
>   to use #ifdef to not to break the non-dm.
>
> [1] 
> http://git.denx.de/?p=u-boot/u-boot-imx.git;a=commitdiff;h=fa2ce02b73fa59fe91d2d0ad61bf837392e03ab9

So the plan is to drop that from u-boot-imx and use this instead? If so,

Acked-by: Joe Hershberger 

>  drivers/net/fec_mxc.c | 268 
> +-
>  drivers/net/fec_mxc.h |   4 +
>  2 files changed, 246 insertions(+), 26 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 09/14] net: Add ability to set MAC address via EEPROM

[Joe Hershberger]

On Fri, Dec 2, 2016 at 4:12 AM, Olliver Schinagl  wrote:
> Hey Joe,
>
>
>
> On 30-11-16 21:00, Joe Hershberger wrote:
>>
>> On Fri, Nov 25, 2016 at 9:30 AM, Olliver Schinagl 
>> wrote:
>>>
>>> This patch allows Kconfig to enable and set parameters to make it
>>> possible to read the MAC address from an EEPROM. The net core layer then
>>> uses this information to read MAC addresses from this EEPROM.
>>>
>>> Besides the various tuneables as to how to access the eeprom (bus,
>>> address, addressing mode/length, 2 configurable that are EEPROM generic
>>> (e.g. SPI or some other form of access) which are:
>>>
>>> NET_ETHADDR_EEPROM_OFFSET, indicating where in the EEPROM the start of
>>> the MAC address is. The default is 8 allowing for 8 bytes before the MAC
>>> for other purposes (header MAGIC for example).
>>>
>>> NET_ETHADDR_EEPROM_CRC8, indicating the MAC is appended with a CRC8-CCIT
>>> checksum that should be verified.
>>>
>>> Currently only I2C eeproms have been tested and thus only those options
>>> are available, but shouldn't be a limit. NET_ETHADDR_EEPROM_SPI can be
>>> just as created and added.
>>>
>>> The code currently first checks if there is a non-zero MAC address in
>>> the eeprom. If that fails to be the case, the read_rom_hwaddr can be
>>> used by a board to supply the MAC in other ways.
>>>
>>> If both these fails, the other code is still in place to query the
>>> environent, which then can be used to override the hardware supplied
>>> data.
>>>
>>> Signed-off-by: Olliver Schinagl 
>>> ---
>>>   doc/README.enetaddr | 99
>>> +
>>>   include/net.h   | 14 
>>>   net/Kconfig | 59 +++
>>>   net/eth-uclass.c|  9 +++--
>>>   net/eth_common.c| 34 ++
>>>   net/eth_legacy.c|  2 ++
>>>   6 files changed, 214 insertions(+), 3 deletions(-)
>>>

...

>>> diff --git a/net/eth_common.c b/net/eth_common.c
>>> index 079be89..e0d8b62 100644
>>> --- a/net/eth_common.c
>>> +++ b/net/eth_common.c
>>> @@ -8,10 +8,44 @@
>>>
>>>   #include 
>>>   #include 
>>> +#include 
>>>   #include 
>>>   #include 
>>>   #include "eth_internal.h"
>>>
>>> +int eeprom_read_enetaddr(const int index, unsigned char *enetaddr)
>>> +{
>>> +   uint8_t eeprom[ARP_HLEN + 1] = { 0x00 };
>>> +#if defined(CONFIG_NET_ETHADDR_EEPROM) &&
>>> defined(CONFIG_NET_ETHADDR_EEPROM_I2C)
>>
>> Since it is easily reasonable that SPI PROM is a likely useful
>> support, why not keep the layout stuff separate from the I2C stuff so
>> that it is trivial to plug in a different bus later? It will also make
>> the code clearer by untangling these.
>
>
> I strongly agree, but I recommend a follow up patch series (and thus merge
> this as is for now) to use Maxime's EEPROM framework patches. So then this
> gets replaced by simple read from eeprom.
>
> So yes, I have contemplated in splitting it up now and have a simply
> read_from_i2c() kind of function, I figured this gets solved elsewhere
> anyway.
>
> Additionally, the layout stuff would ideally be replaced by Igor (i think it
> was) eeprom layout framework (if those two combine) which solves both
> problems in one go.
>
> Or you want to see it split now as the other is a bad plan (tm)?

It's fine to wait if there is a plan going forward with a dependency
that might make this throw-away work.

> Olliver
>
>>
>>> +   int old_i2c_bus;
>>> +
>>> +   old_i2c_bus = i2c_get_bus_num();
>>> +   if (old_i2c_bus != CONFIG_NET_ETHADDR_EEPROM_I2C_BUS)
>>> +   i2c_set_bus_num(CONFIG_NET_ETHADDR_EEPROM_I2C_BUS);
>>> +   /* Skip in blocks of 8 (ARP + CRC8 + pad), but read 7 from the
>>> eeprom */
>>> +   if (i2c_read(CONFIG_NET_ETHADDR_EEPROM_I2C_ADDR,
>>> +CONFIG_NET_ETHADDR_EEPROM_OFFSET + (index *
>>> (ARP_HLEN + 2)),
>>> +CONFIG_NET_ETHADDR_EEPROM_I2C_ADDRLEN,
>>> +eeprom, ARP_HLEN + 1)) {
>>> +   i2c_set_bus_num(old_i2c_bus);
>>> +   puts("Could not read the EEPROM or EEPROM missing on
>>> device: ");
>>> +   return -ENOSYS;
>>> +   }
>>> +   i2c_set_bus_num(old_i2c_bus);
>>> +
>>> +#ifdef CONFIG_NET_ETHADDR_EEPROM_CRC8
>>> +   if (crc8(0, eeprom, ARP_HLEN) != eeprom[ARP_HLEN]) {
>>> +   puts("CRC error on MAC address from EEPROM on device: ");
>>> +   return -EINVAL;
>>> +   }
>>> +#endif
>>> +#endif
>>> +
>>> +   memcpy(enetaddr, eeprom, ARP_HLEN);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>>   void eth_parse_enetaddr(const char *addr, uchar *enetaddr)
>>>   {
>>>  char *end;
>>> diff --git a/net/eth_legacy.c b/net/eth_legacy.c
>>> index bf4de37..8fb5844 100644
>>> --- a/net/eth_legacy.c
>>> +++ b/net/eth_legacy.c
>>> @@ -136,6 +136,8 @@ int eth_write_hwaddr(struct eth_device *dev, const
>>> char *base_name,
>>>  unsigned char 

[U-Boot] [PATCH v2] net: phy: Improve the Marvell 151x constants

[Joe Hershberger]

Use some constants for the phy configuration instead of so many magic
numbers.

Signed-off-by: Joe Hershberger 
---

Changes in v2:
-Fixed changed name from last-minute checkpatch line-length change

 drivers/net/phy/marvell.c | 47 ---
 1 file changed, 36 insertions(+), 11 deletions(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 4eeb0f6..ac13a67 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -82,6 +82,21 @@
 #define MIIM_88E1310_PHY_RGMII_CTRL21
 #define MIIM_88E1310_PHY_PAGE  22
 
+/* 88E151x PHY defines */
+/* Page 3 registers */
+#define MIIM_88E151x_LED_FUNC_CTRL 16
+#define MIIM_88E151x_LED_FLD_SZ4
+#define MIIM_88E151x_LED0_OFFS (0 * MIIM_88E151x_LED_FLD_SZ)
+#define MIIM_88E151x_LED1_OFFS (1 * MIIM_88E151x_LED_FLD_SZ)
+#define MIIM_88E151x_LED0_ACT  3
+#define MIIM_88E151x_LED1_100_1000_LINK6
+#define MIIM_88E151x_LED_TIMER_CTRL18
+#define MIIM_88E151x_INT_EN_OFFS   7
+/* Page 18 registers */
+#define MIIM_88E151x_GENERAL_CTRL  20
+#define MIIM_88E151x_MODE_SGMII1
+#define MIIM_88E151x_RESET_OFFS15
+
 /* Marvell 88E1011S */
 static int m88e1011s_config(struct phy_device *phydev)
 {
@@ -289,7 +304,7 @@ static int m88e1518_config(struct phy_device *phydev)
 */
 
/* EEE initialization */
-   phy_write(phydev, MDIO_DEVAD_NONE, 22, 0x00ff);
+   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE, 0x00ff);
phy_write(phydev, MDIO_DEVAD_NONE, 17, 0x214B);
phy_write(phydev, MDIO_DEVAD_NONE, 16, 0x2144);
phy_write(phydev, MDIO_DEVAD_NONE, 17, 0x0C28);
@@ -298,21 +313,23 @@ static int m88e1518_config(struct phy_device *phydev)
phy_write(phydev, MDIO_DEVAD_NONE, 16, 0x214D);
phy_write(phydev, MDIO_DEVAD_NONE, 17, 0xCC0C);
phy_write(phydev, MDIO_DEVAD_NONE, 16, 0x2159);
-   phy_write(phydev, MDIO_DEVAD_NONE, 22, 0x);
+   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE, 0x);
 
/* SGMII-to-Copper mode initialization */
if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
/* Select page 18 */
-   phy_write(phydev, MDIO_DEVAD_NONE, 22, 18);
+   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE, 18);
 
/* In reg 20, write MODE[2:0] = 0x1 (SGMII to Copper) */
-   m88e1518_phy_writebits(phydev, 20, 0, 3, 1);
+   m88e1518_phy_writebits(phydev, MIIM_88E151x_GENERAL_CTRL,
+  0, 3, MIIM_88E151x_MODE_SGMII);
 
/* PHY reset is necessary after changing MODE[2:0] */
-   m88e1518_phy_writebits(phydev, 20, 15, 1, 1);
+   m88e1518_phy_writebits(phydev, MIIM_88E151x_GENERAL_CTRL,
+  MIIM_88E151x_RESET_OFFS, 1, 1);
 
/* Reset page selection */
-   phy_write(phydev, MDIO_DEVAD_NONE, 22, 0);
+   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE, 0);
 
udelay(100);
}
@@ -324,17 +341,25 @@ static int m88e1518_config(struct phy_device *phydev)
 static int m88e1510_config(struct phy_device *phydev)
 {
/* Select page 3 */
-   phy_write(phydev, MDIO_DEVAD_NONE, 22, 3);
+   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE,
+ MIIM_88E1118_PHY_LED_PAGE);
 
/* Enable INTn output on LED[2] */
-   m88e1518_phy_writebits(phydev, 18, 7, 1, 1);
+   m88e1518_phy_writebits(phydev, MIIM_88E151x_LED_TIMER_CTRL,
+  MIIM_88E151x_INT_EN_OFFS, 1, 1);
 
/* Configure LEDs */
-   m88e1518_phy_writebits(phydev, 16, 0, 4, 3); /* LED[0]:0011 (ACT) */
-   m88e1518_phy_writebits(phydev, 16, 4, 4, 6); /* LED[1]:0110 (LINK) */
+   /* LED[0]:0011 (ACT) */
+   m88e1518_phy_writebits(phydev, MIIM_88E151x_LED_FUNC_CTRL,
+  MIIM_88E151x_LED0_OFFS, MIIM_88E151x_LED_FLD_SZ,
+  MIIM_88E151x_LED0_ACT);
+   /* LED[1]:0110 (LINK 100/1000 Mbps) */
+   m88e1518_phy_writebits(phydev, MIIM_88E151x_LED_FUNC_CTRL,
+  MIIM_88E151x_LED1_OFFS, MIIM_88E151x_LED_FLD_SZ,
+  MIIM_88E151x_LED1_100_1000_LINK);
 
/* Reset page selection */
-   phy_write(phydev, MDIO_DEVAD_NONE, 22, 0);
+   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE, 0);
 
return m88e1518_config(phydev);
 }
-- 
1.7.11.5

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

Re: [U-Boot] Pull request: u-boot-net.git master

[Michal Simek]

Hi Joe,

2016-12-09 17:22 GMT+01:00 Joe Hershberger :

> Hi Tom,
>
> On Fri, Dec 9, 2016 at 6:12 AM, Tom Rini  wrote:
> > On Thu, Dec 08, 2016 at 10:37:26AM -0600, Joe Hershberger wrote:
> >
> >> Hi Tom,
> >>
> >> The following changes since commit 388019f1e2166638453bc4e0cc5d13
> 8c2a19e0c9:
> >>
> >>   Merge branch 'master' of git://git.denx.de/u-boot-usb (2016-12-06
> 08:07:20 -0500)
> >>
> >> are available in the git repository at:
> >>
> >>
> >>   git://git.denx.de/u-boot-net.git master
> >>
> >> for you to fetch changes up to bb135a0180c31fbd7456021fb9700b
> 49bba7f533:
> >>
> >>   net/phy/vitesse: Rework RGMII skew configuration for VSC8601
> (2016-12-08 10:36:22 -0600)
> >
> > This is a NAK and is what is breaking microblaze-generic and
> > imgtec_xilfpga at least:
> > +(imgtec_xilfpga,microblaze-generic)   ret =
> > mdio_register_seq(emaclite->bus, 
> > dev->seq);+(imgtec_xilfpga,microblaze-generic)
>  ^
> > +(imgtec_xilfpga,microblaze-generic) drivers/net/built-in.o: In function
> > `emaclite_probe':
> > +(imgtec_xilfpga)
> > ../drivers/net/xilinx_emaclite.c:(.text.emaclite_probe+0x64): undefined
> reference to `mdio_register_seq'
> > +(imgtec_xilfpga,microblaze-generic) make[1]: *** [u-boot] Error 1
> > +(imgtec_xilfpga,microblaze-generic) make: *** [sub-make] Error 2
> > +(microblaze-generic)   ret = mdio_register_seq(priv->bus, dev->seq);
> > +(microblaze-generic) drivers/net/built-in.o: In function
> `axi_emac_probe': +(microblaze-generic)
> > build/../drivers/net/xilinx_axi_emac.c:652: undefined reference to
> `mdio_register_seq'
> > +(microblaze-generic) build/../drivers/net/xilinx_emaclite.c:570:
> undefined reference to `mdio_register_seq'
>
> This is strange... I build tested this on Travis.
>
> https://travis-ci.org/jhershbe/u-boot/builds/180270329
>
> Are we missing microblaze coverage on Travis or something?
>


This patches went to the tree by accident. Tom reverted that incorrect
merge.
Adding mdio_register_seq was sent recently for review and it shouldn't have
these compilation issue.
I have no idea what's wrong with imgtec_xilfpga.
And microblaze should be covered by travis already.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC v2 3/3] arm: socfpga: Add reset manager defines for reset status

[Dinh Nguyen]

Add additional defines for the reset manager for different reset status bits.

Signed-off-by: Dinh Nguyen 
---
 arch/arm/mach-socfpga/include/mach/reset_manager.h | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h 
b/arch/arm/mach-socfpga/include/mach/reset_manager.h
index 2f070f2..9750026 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
@@ -79,4 +79,25 @@ struct socfpga_reset_manager {
 /* Create a human-readable reference to SoCFPGA reset. */
 #define SOCFPGA_RESET(_name)   RSTMGR_##_name
 
+#define RSTMGR_STAT_L4WD1RST_MASK 0x8000
+#define RSTMGR_STAT_L4WD0RST_MASK 0x4000
+#define RSTMGR_STAT_MPUWD1RST_MASK 0x2000
+#define RSTMGR_STAT_MPUWD0RST_MASK 0x1000
+#define RSTMGR_STAT_SWWARMRST_MASK 0x0400
+#define RSTMGR_STAT_FPGAWARMRST_MASK 0x0200
+#define RSTMGR_STAT_NRSTPINRST_MASK 0x0100
+#define RSTMGR_STAT_SWCOLDRST_MASK 0x0010
+#define RSTMGR_STAT_CONFIGIOCOLDRST_MASK 0x0008
+#define RSTMGR_STAT_FPGACOLDRST_MASK 0x0004
+#define RSTMGR_STAT_NPORPINRST_MASK 0x0002
+#define RSTMGR_STAT_PORVOLTRST_MASK 0x0001
+
+#define RSTMGR_WARMRST_MASK(RSTMGR_STAT_SWWARMRST_MASK | \
+RSTMGR_STAT_L4WD0RST_MASK | \
+RSTMGR_STAT_L4WD1RST_MASK | \
+RSTMGR_STAT_MPUWD1RST_MASK | \
+RSTMGR_STAT_MPUWD0RST_MASK | \
+RSTMGR_STAT_FPGAWARMRST_MASK | \
+RSTMGR_STAT_NRSTPINRST_MASK)
+
 #endif /* _RESET_MANAGER_H_ */
-- 
2.7.4

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

[U-Boot] [RFC v2 2/3] arm: socfpga: scrub the SDRAM to properly enable ECC support

[Dinh Nguyen]

In order for SDRAM ECC to work correctly, the SDRAM needs to get zero'd which
enables the ECC bit. By using the PL330 DMA to fill the SDRAM with zeroes,
the operation is completed in ~1.2 seconds, versus ~14 seconds with a memset.

Signed-off-by: Dinh Nguyen 
---
v2: explanation for size of pl330_buf
remove reset manager defines
---
 arch/arm/mach-socfpga/include/mach/sdram.h |  2 ++
 arch/arm/mach-socfpga/spl.c|  8 
 arch/arm/mach-socfpga/wrap_sdram_config.c  | 32 ++
 configs/socfpga_cyclone5_defconfig |  2 ++
 4 files changed, 44 insertions(+)

diff --git a/arch/arm/mach-socfpga/include/mach/sdram.h 
b/arch/arm/mach-socfpga/include/mach/sdram.h
index b11228f..a70d5c6 100644
--- a/arch/arm/mach-socfpga/include/mach/sdram.h
+++ b/arch/arm/mach-socfpga/include/mach/sdram.h
@@ -20,6 +20,8 @@ const struct socfpga_sdram_rw_mgr_config 
*socfpga_get_sdram_rwmgr_config(void);
 const struct socfpga_sdram_io_config *socfpga_get_sdram_io_config(void);
 const struct socfpga_sdram_misc_config *socfpga_get_sdram_misc_config(void);
 
+void sdram_ecc_init(void);
+
 #define SDR_CTRLGRP_ADDRESS(SOCFPGA_SDR_ADDRESS | 0x5000)
 
 struct socfpga_sdr_ctrl {
diff --git a/arch/arm/mach-socfpga/spl.c b/arch/arm/mach-socfpga/spl.c
index fec4c7a..26688ad 100644
--- a/arch/arm/mach-socfpga/spl.c
+++ b/arch/arm/mach-socfpga/spl.c
@@ -30,6 +30,8 @@ static struct nic301_registers *nic301_regs =
(struct nic301_registers *)SOCFPGA_L3REGS_ADDRESS;
 static struct socfpga_system_manager *sysmgr_regs =
(struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
+static const struct socfpga_reset_manager *reset_manager_base =
+   (void *)SOCFPGA_RSTMGR_ADDRESS;
 
 u32 spl_boot_device(void)
 {
@@ -85,6 +87,9 @@ void board_init_f(ulong dummy)
 #endif
unsigned long sdram_size;
unsigned long reg;
+   u32 rst_mgr_status;
+
+   rst_mgr_status = readl(_manager_base->status);
 
/*
 * First C code to run. Clear fake OCRAM ECC first as SBE
@@ -179,6 +184,9 @@ void board_init_f(ulong dummy)
 
socfpga_bridges_reset(1);
 
+   if ((rst_mgr_status & RSTMGR_WARMRST_MASK) == 0)
+   sdram_ecc_init();
+
/* Configure simple malloc base pointer into RAM. */
gd->malloc_base = CONFIG_SYS_TEXT_BASE + (1024 * 1024);
 }
diff --git a/arch/arm/mach-socfpga/wrap_sdram_config.c 
b/arch/arm/mach-socfpga/wrap_sdram_config.c
index 8fb808a..1509cba 100644
--- a/arch/arm/mach-socfpga/wrap_sdram_config.c
+++ b/arch/arm/mach-socfpga/wrap_sdram_config.c
@@ -5,8 +5,10 @@
  */
 
 #include 
+#include 
 #include 
 #include 
+#include 
 
 /* Board-specific header. */
 #include 
@@ -317,3 +319,33 @@ const struct socfpga_sdram_misc_config 
*socfpga_get_sdram_misc_config(void)
 {
return _config;
 }
+
+#if (CONFIG_HPS_SDR_CTRLCFG_CTRLCFG_ECCEN == 1)
+/* init the whole SDRAM ECC bit */
+void sdram_ecc_init(void)
+{
+   struct pl330_transfer_struct pl330;
+   /*
+* 1200 bytes is the buffer size needed to handle the microcode for
+* transferring 1GB of zero's.
+*/
+   u8 pl330_buf[1200];
+
+   pl330.dst_addr = CONFIG_SYS_SDRAM_BASE;
+   pl330.len = sdram_calculate_size();
+   pl330.channel_num = 0;
+   pl330.buf_size = sizeof(pl330_buf);
+   pl330.buf = pl330_buf;
+
+   pl330.transfer_type = DMA_SUPPORTS_DEV_TO_MEM;
+   pl330.reg_base = (void __iomem *)SOCFPGA_DMASECURE_ADDRESS;
+
+   puts("SDRAM: Initializing SDRAM ECC\n");
+
+   arm_pl330_transfer();
+
+   printf("SDRAM: ECC initialized successfully\n");
+}
+#else
+void sdram_ecc_init(void) {}
+#endif
diff --git a/configs/socfpga_cyclone5_defconfig 
b/configs/socfpga_cyclone5_defconfig
index 905f766..8a8c71b 100644
--- a/configs/socfpga_cyclone5_defconfig
+++ b/configs/socfpga_cyclone5_defconfig
@@ -63,3 +63,5 @@ CONFIG_G_DNL_MANUFACTURER="altera"
 CONFIG_G_DNL_VENDOR_NUM=0x0525
 CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
 CONFIG_USE_TINY_PRINTF=y
+CONFIG_SPL_DMA_SUPPORT=y
+CONFIG_PL330_DMA=y
-- 
2.7.4

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

[U-Boot] [RFC v2 1/3] drivers: dma: Add the ARM PL330 DMA driver

[Dinh Nguyen]

From: Dinh Nguyen 

Adopted from the Linux kernel PL330 DMA driver.

Signed-off-by: Dinh Nguyen 
---
v2: Add Kconfig CONFIG_PL330_DMA entry
---
 arch/arm/include/asm/pl330.h | 105 +
 drivers/dma/Kconfig  |   4 +
 drivers/dma/Makefile |   1 +
 drivers/dma/pl330.c  | 942 +++
 4 files changed, 1052 insertions(+)
 create mode 100644 arch/arm/include/asm/pl330.h
 create mode 100644 drivers/dma/pl330.c

diff --git a/arch/arm/include/asm/pl330.h b/arch/arm/include/asm/pl330.h
new file mode 100644
index 000..dd19b4c
--- /dev/null
+++ b/arch/arm/include/asm/pl330.h
@@ -0,0 +1,105 @@
+/*
+ * Copyright (C) 2010 Samsung Electronics Co. Ltd.
+ * Jaswinder Singh 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * adapted from linux kernel pl330.h
+ */
+
+#ifndef__PL330_H_
+#define__PL330_H_
+
+#define PL330_STATE_STOPPED(1 << 0)
+#define PL330_STATE_EXECUTING  (1 << 1)
+#define PL330_STATE_WFE(1 << 2)
+#define PL330_STATE_FAULTING   (1 << 3)
+#define PL330_STATE_COMPLETING (1 << 4)
+#define PL330_STATE_WFP(1 << 5)
+#define PL330_STATE_KILLING(1 << 6)
+#define PL330_STATE_FAULT_COMPLETING   (1 << 7)
+#define PL330_STATE_CACHEMISS  (1 << 8)
+#define PL330_STATE_UPDTPC (1 << 9)
+#define PL330_STATE_ATBARRIER  (1 << 10)
+#define PL330_STATE_QUEUEBUSY  (1 << 11)
+#define PL330_STATE_INVALID(1 << 15)
+
+#define PL330_DMA_MAX_BURST_SIZE   3
+
+/* structure to be passed in for pl330_transfer_x */
+struct pl330_transfer_struct {
+   void __iomem *reg_base;
+   u32 channel_num;
+   u32 src_addr;
+   u32 dst_addr;
+   u32 len;
+   u32 brst_size;
+   u32 single_brst_size;
+   u32 brst_len;
+   u32 peripheral_id;
+   u32 transfer_type;
+   u32 enable_cache1;
+   u32 buf_size;
+   u8 *buf;
+};
+
+enum pl330_srccachectrl {
+   SCCTRL0 = 0,/* Noncacheable and nonbufferable */
+   SCCTRL1,/* Bufferable only */
+   SCCTRL2,/* Cacheable, but do not allocate */
+   SCCTRL3,/* Cacheable and bufferable, but do not allocate */
+   SINVALID1,
+   SINVALID2,
+   SCCTRL6,/* Cacheable write-through, allocate on reads only */
+   SCCTRL7,/* Cacheable write-back, allocate on reads only */
+};
+
+enum pl330_dstcachectrl {
+   DCCTRL0 = 0,/* Noncacheable and nonbufferable */
+   DCCTRL1,/* Bufferable only */
+   DCCTRL2,/* Cacheable, but do not allocate */
+   DCCTRL3,/* Cacheable and bufferable, but do not allocate */
+   DINVALID1 = 8,
+   DINVALID2,
+   DCCTRL6,/* Cacheable write-through, allocate on writes only */
+   DCCTRL7,/* Cacheable write-back, allocate on writes only */
+};
+
+enum pl330_byteswap {
+   SWAP_NO = 0,
+   SWAP_2,
+   SWAP_4,
+   SWAP_8,
+   SWAP_16,
+};
+
+/*
+ * Request Configuration.
+ * The PL330 core does not modify this and uses the last
+ * working configuration if the request doesn't provide any.
+ *
+ * The Client may want to provide this info only for the
+ * first request and a request with new settings.
+ */
+struct pl330_reqcfg {
+   /* Address Incrementing */
+   unsigned dst_inc:1;
+   unsigned src_inc:1;
+
+   /*
+* For now, the SRC & DST protection levels
+* and burst size/length are assumed same.
+*/
+   int nonsecure;
+   int privileged;
+   int insnaccess;
+   unsigned brst_len:5;
+   unsigned brst_size:3; /* in power of 2 */
+
+   enum pl330_dstcachectrl dcctl;
+   enum pl330_srccachectrl scctl;
+   enum pl330_byteswap swap;
+};
+
+void arm_pl330_transfer(struct pl330_transfer_struct *pl330);
+#endif /* __PL330_H_ */
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 1b92c77..d95f959 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -19,4 +19,8 @@ config TI_EDMA3
  This driver support data transfer between memory
  regions.
 
+config PL330_DMA
+   bool "PL330 DMA driver"
+   help
+ Enable the ARM PL330 DMA driver.
 endmenu # menu "DMA Support"
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 39b78b2..d287512 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_FSL_DMA) += fsl_dma.o
 obj-$(CONFIG_TI_KSNAV) += keystone_nav.o keystone_nav_cfg.o
 obj-$(CONFIG_TI_EDMA3) += ti-edma3.o
 obj-$(CONFIG_DMA_LPC32XX) += lpc32xx_dma.o
+obj-$(CONFIG_PL330_DMA) += pl330.o
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
new file mode 100644
index 000..a97cd9f
--- /dev/null
+++ b/drivers/dma/pl330.c
@@ -0,0 +1,942 @@
+/*
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * 

[U-Boot] [RFC v2 0/3] Add PL330 DMA support on SoCFPGA

[Dinh Nguyen]

Hello,

I'm seeking advice on debugging on what is happening when I use the PL330
DMA controller to transfer zero's to the SDRAM and the effect of memory
barriers.

Here are my current observations:

1) With commit "a78cd8613204 ARM: Rework and correct barrier definitions",
   the correct memory barrier calls are in place. With this patch in place,
   this version of the PL330 DMA driver can correctly transfer zero's to
   the SDRAM.

   However, after the transfer is done, I'm encountering this error on SPL
   boot up:
Trying to boot from MMC1
spl: could not find mmc device. error: -19
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

   The above error can be narrowed down to the list_emtpy(>dev_head) in
   uclass_find_device() being true. A simple revert of patch a78cd8613204
   make this error go away.

2) I've tried to replace all the readl/writel with raw_readl/raw_writel in
   the pl330 driver. Same error.

3) Removing the __iormb and __iowmb in readl/writel, effectively, removing
   the barriers. Error goes away.

I don't know enough what affect the barriers are having on the DMA memory
transfer, so any guidance would be greatly appreciated.

Thanks,
Dinh


Dinh Nguyen (3):
  drivers: dma: Add the ARM PL330 DMA driver
  arm: socfpga: scrub the SDRAM to properly enable ECC support
  arm: socfpga: Add reset manager defines for reset status

 arch/arm/include/asm/pl330.h   | 105 +++
 arch/arm/mach-socfpga/include/mach/reset_manager.h |  21 +
 arch/arm/mach-socfpga/include/mach/sdram.h |   2 +
 arch/arm/mach-socfpga/spl.c|   8 +
 arch/arm/mach-socfpga/wrap_sdram_config.c  |  32 +
 configs/socfpga_cyclone5_defconfig |   2 +
 drivers/dma/Kconfig|   4 +
 drivers/dma/Makefile   |   1 +
 drivers/dma/pl330.c| 942 +
 9 files changed, 1117 insertions(+)
 create mode 100644 arch/arm/include/asm/pl330.h
 create mode 100644 drivers/dma/pl330.c

-- 
2.7.4

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

Re: [U-Boot] [PATCH 1/1] Adding MSCC PHY-VSC8530-VSC8531-VSC8540-VSC8541

[Joe Hershberger]

Hi Alexey,

On Fri, Dec 9, 2016 at 3:06 AM, Alexey Brodkin
 wrote:
> Hi Joe,
>
>> -Original Message-
>> From: Joe Hershberger [mailto:joe.hershber...@gmail.com]
>> Sent: Thursday, December 08, 2016 8:05 PM
>> To: Alexey Brodkin 
>> Cc: john.haech...@microsemi.com; u-boot@lists.denx.de; joe.hershber...@ni.com
>> Subject: Re: [U-Boot] [PATCH 1/1] Adding MSCC 
>> PHY-VSC8530-VSC8531-VSC8540-VSC8541
>>
>> Hi Alexey,
>>
>> Thanks for the review. I agree with most of your comments, but I'll
>> note where I don't.
>>
>> On Thu, Dec 8, 2016 at 6:24 AM, Alexey Brodkin
>>  wrote:
>>
>> ...
>>
>> >> +static int mscc_vsc8531_vsc8541_init_scripts(struct phy_device *phydev)
>> >> +{
>> >> + u16 reg_val17;
>> >> + u16 reg_val18;
>> >
>> > Any reason to keep variables in different lines?
>>
>> I think separate lines is cleaner and prefer it stay this way.
>
> Well especially here IMHO there's no need to separate 2 temporary vars.
> Still it's more a matter of your taste/preference.
> Moreover I'm not really asking to do that change but wondering about reasons
> and with good explanation I'm fine with it as it is.

The way the code is currently written the two variables are used
concurrently, but I'd be surprised if that was a requirement. Maybe
John can confirm otherwise, but simply doing each read/modify/write
operations sequentially instead of mixing the order would allow a
single temp variable for the operation.

>> >> +
>> >> + /* Set to Access Token Ring Registers */
>> >> + phy_write(phydev, MDIO_DEVAD_NONE,
>> >> + MSCC_EXT_PAGE_ACCESS, MSCC_PHY_PAGE_TR);
>> >> +
>> >> + /* Update LinkDetectCtrl default to optimized values */
>> >> + /* Determined during Silicon Validation Testing */
>> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_REG_TR_ADDR_16, 0xA7F8);
>> >
>> > Cryptic values are not very nice to deal with. I'd advise you to use 
>> > defines here.
>> > Moreover I'm wondering:
>> >  a) why all this complicated setup is required?
>> >  b) is it mentioned in any datasheet? If it is mentioned it worth adding a 
>> > comment
>> > about source of those figures and explanation of the procedure itself.
>> > This will help mere mortals to figure out what is done here and if 
>> > required people will
>> > use that knowledge as a reference in other projects.
>> >
>> >> + reg_val17 = phy_read(phydev, MDIO_DEVAD_NONE, 
>> >> MSCC_PHY_REG_TR_DATA_17);
>> >> + reg_val17 = bitfield_replace(reg_val17, MSCC_PHY_TR_LINKDETCTRL_POS,
>> >> +MSCC_PHY_TR_LINKDETCTRL_WIDTH, 3);
>> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_REG_TR_DATA_17, 
>> >> reg_val17);
>> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_REG_TR_ADDR_16, 0x87F8);
>> >> +
>> >> + /* Update VgaThresh100 defaults to optimized values */
>> >> + /* Determined during Silicon Validation Testing */
>> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_REG_TR_ADDR_16, 0xAFA4);
>> >> + reg_val18 = phy_read(phydev, MDIO_DEVAD_NONE, 
>> >> MSCC_PHY_REG_TR_DATA_18);
>> >> + reg_val18 = bitfield_replace(reg_val18, 
>> >> MSCC_PHY_TR_VGATHRESH100_POS,
>> >> +MSCC_PHY_TR_VGATHRESH100_WIDTH, 24);
>> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_REG_TR_DATA_18, 
>> >> reg_val18);
>> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_REG_TR_ADDR_16, 0x8FA4);
>> >> +
>> >> + /* Update VgaGain10 defaults to optimized values */
>> >> + /* Determined during Silicon Validation Testing */
>> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_REG_TR_ADDR_16, 0xAF92);
>> >> + reg_val18 = phy_read(phydev, MDIO_DEVAD_NONE, 
>> >> MSCC_PHY_REG_TR_DATA_18);
>> >> + reg_val17 = phy_read(phydev, MDIO_DEVAD_NONE, 
>> >> MSCC_PHY_REG_TR_DATA_17);
>> >> + reg_val18 = bitfield_replace(reg_val18, MSCC_PHY_TR_VGAGAIN10_U_POS,
>> >> +MSCC_PHY_TR_VGAGAIN10_U_WIDTH, 0);
>> >> +
>> >> + reg_val17 = bitfield_replace(reg_val17, MSCC_PHY_TR_VGAGAIN10_L_POS,
>> >> +MSCC_PHY_TR_VGAGAIN10_L_WIDTH, 1);
>> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_REG_TR_DATA_18, 
>> >> reg_val18);
>> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_REG_TR_DATA_17, 
>> >> reg_val17);
>> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_REG_TR_ADDR_16, 0x8F92);
>> >> +
>> >> + /* Set back to Access Standard Page Registers */
>> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_EXT_PAGE_ACCESS,
>> >> + MSCC_PHY_PAGE_STD);
>> >> +
>> >> + return 0;
>> >> +}
>> >> +
>> >> +static int mscc_parse_status(struct phy_device *phydev)
>> >> +{
>> >> + u16 speed;
>> >> + u16 mii_reg;
>> >> +
>> >> + mii_reg = phy_read(phydev, MDIO_DEVAD_NONE, 
>> >> MIIM_AUX_CNTRL_STAT_REG);
>> >
>> > u16 speed, mii_reg = phy_read(phydev, MDIO_DEVAD_NONE, 
>> > 

Re: [U-Boot] Pull request: u-boot-net.git master

[Joe Hershberger]

Hi Tom,

On Fri, Dec 9, 2016 at 6:12 AM, Tom Rini  wrote:
> On Thu, Dec 08, 2016 at 10:37:26AM -0600, Joe Hershberger wrote:
>
>> Hi Tom,
>>
>> The following changes since commit 388019f1e2166638453bc4e0cc5d138c2a19e0c9:
>>
>>   Merge branch 'master' of git://git.denx.de/u-boot-usb (2016-12-06 08:07:20 
>> -0500)
>>
>> are available in the git repository at:
>>
>>
>>   git://git.denx.de/u-boot-net.git master
>>
>> for you to fetch changes up to bb135a0180c31fbd7456021fb9700b49bba7f533:
>>
>>   net/phy/vitesse: Rework RGMII skew configuration for VSC8601 (2016-12-08 
>> 10:36:22 -0600)
>
> This is a NAK and is what is breaking microblaze-generic and
> imgtec_xilfpga at least:
> +(imgtec_xilfpga,microblaze-generic)   ret =
> mdio_register_seq(emaclite->bus, 
> dev->seq);+(imgtec_xilfpga,microblaze-generic)   ^
> +(imgtec_xilfpga,microblaze-generic) drivers/net/built-in.o: In function
> `emaclite_probe':
> +(imgtec_xilfpga)
> ../drivers/net/xilinx_emaclite.c:(.text.emaclite_probe+0x64): undefined 
> reference to `mdio_register_seq'
> +(imgtec_xilfpga,microblaze-generic) make[1]: *** [u-boot] Error 1
> +(imgtec_xilfpga,microblaze-generic) make: *** [sub-make] Error 2
> +(microblaze-generic)   ret = mdio_register_seq(priv->bus, dev->seq);
> +(microblaze-generic) drivers/net/built-in.o: In function `axi_emac_probe':   
>   +(microblaze-generic)
> build/../drivers/net/xilinx_axi_emac.c:652: undefined reference to 
> `mdio_register_seq'
> +(microblaze-generic) build/../drivers/net/xilinx_emaclite.c:570: undefined 
> reference to `mdio_register_seq'

This is strange... I build tested this on Travis.

https://travis-ci.org/jhershbe/u-boot/builds/180270329

Are we missing microblaze coverage on Travis or something?

Thanks,
-Joe

> --
> Tom
>
> ___
> 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] [PATCH v6 1/2] armv8/fsl-layerscape: fdt: fixup LS1043A rev1 GIC node

[york sun]

On 12/09/2016 01:58 AM, Wenbin Song wrote:
> Hi, york
>
> Because the other patch [patch v6 2/2 ] in this set depends on the format of  
> MSI  node  which is not yet ready to upstream.
> I planed  to send them together.

OK.

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

Re: [U-Boot] [PATCH 2/7] disk: Add CONFIG_PARTITION to Kconfig

[Andrew F. Davis]

On 12/09/2016 06:27 AM, Tom Rini wrote:
> On Thu, Dec 08, 2016 at 04:04:28PM -0600, Andrew F. Davis wrote:
> 
>> Signed-off-by: Andrew F. Davis 
>> ---
>>  Kconfig   |  2 ++
>>  disk/Kconfig  | 11 +++
>>  include/config_defaults.h |  1 -
>>  3 files changed, 13 insertions(+), 1 deletion(-)
>>  create mode 100644 disk/Kconfig
> 
> OK, but, we've also got https://patchwork.ozlabs.org/patch/702717/ which
> I'll be taking soon, sorry!
>  
> 

Works for me, this conversion is needed for AM335x HS etherway, so I'll
rebase my AM335x HS patchsets on Patrick's series, and push those.

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

[U-Boot] [PATCH] sf: Do not force the DT memory map size to exactly match the device

[Phil Edworthy]

As long as the memory mapped size specifeid in the DT is the same or
bigger than the device size, it will work. So do not force the sizes
to be identical.

Signed-off-by: Phil Edworthy 
---
 drivers/mtd/spi/spi_flash.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 6e595c8..fee930b 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -902,7 +902,7 @@ int spi_flash_decode_fdt(const void *blob, struct spi_flash 
*flash)
return 0;
}
 
-   if (flash->size != size) {
+   if (flash->size > size) {
debug("%s: Memory map must cover entire device\n", __func__);
return -1;
}
-- 
2.7.4

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

Re: [U-Boot] [PATCH] travis-ci: Switch to building QEMU

[Tom Rini]

On Wed, Dec 07, 2016 at 05:46:14PM +0100, Daniel Schwierzeck wrote:
> 
> 
> Am 07.12.2016 um 17:20 schrieb Tom Rini:
> > First, there are a number of features in newer QEMU that will allow us
> > to test a wider range of platforms, so we want to use at least v2.8.0.
> > Second, making use of a PPA for QEMU fails from time to time.  So we
> > change to checking out and building a copy of QEMU when we know that we
> > are going to use test.py and need QEMU to be installed.  This adds
> > around 4 minutes per test.py job that we run.
> > 
> > Signed-off-by: Tom Rini 
> > ---
> >  .travis.yml | 26 +++---
> >  1 file changed, 19 insertions(+), 7 deletions(-)
> > 
> > diff --git a/.travis.yml b/.travis.yml
> > index 79bc24263abd..31fe27467184 100644
> > --- a/.travis.yml
> > +++ b/.travis.yml
> > @@ -10,8 +10,6 @@ language: c
> >  
> >  addons:
> >apt:
> > -sources:
> > -- sourceline: 'ppa:gns3/qemu'
> >  packages:
> >  - cppcheck
> >  - sloccount
> > @@ -21,10 +19,6 @@ addons:
> >  - libsdl1.2-dev
> >  - python
> >  - python-virtualenv
> > -- qemu-system-arm
> > -- qemu-system-mips
> > -- qemu-system-ppc
> > -- qemu-system-x86
> >  - gcc-powerpc-linux-gnu
> >  - gcc-arm-linux-gnueabihf
> >  - gcc-aarch64-linux-gnu
> > @@ -54,7 +48,7 @@ install:
> >  
> >  env:
> >global:
> > -- PATH=/tmp/dtc:/tmp/uboot-test-hooks/bin:$PATH
> > +- PATH=/tmp/dtc:/tmp/qemu-install/bin:/tmp/uboot-test-hooks/bin:$PATH
> >  - PYTHONPATH=/tmp/uboot-test-hooks/py/travis-ci
> >  - BUILD_DIR=build
> >  - HOSTCC="cc"
> > @@ -74,6 +68,15 @@ before_script:
> >echo -e "\n[toolchain-prefix]\nx86 = 
> > ${HOME}/.buildman-toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-"
> >  >> ~/.buildman;
> >  fi
> >- if [[ "${TOOLCHAIN}" == *xtensa* ]]; then ./tools/buildman/buildman 
> > --fetch-arch xtensa ; fi
> > +  - if [[ "${QEMU_TARGET}" != "" ]]; then
> > +   git clone git://git.qemu.org/qemu.git /tmp/qemu;
> > +   pushd /tmp/qemu;
> > +   git submodule update --init dtc &&
> > +   git checkout v2.8.0-rc3 &&
> 
> you could speed up git clone:
> 
> git clone --depth 1 --single-branch --branch v2.8.0-rc3 
> git://git.qemu.org/qemu.git /tmp/qemu
> pushd /tmp/qemu
> git submodule update --init --recommend-shallow --reference /tmp/dtc dtc
> 
> Because we already cloned dtc in the install steps, we could use it as 
> reference repository.
> 
> BTW: you should consider adding "--single-branch --branch master" to the 
> other clone tasks too.

I might do this in a follow up but this is an area where we're talking
about seconds of time vs making things start to be harder to read.
Thanks!

-- 
Tom


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

[U-Boot] [PATCH] imgtec: Update MAINTAINERS for more config files

[Tom Rini]

Cover all of the boston and malta variations.

Signed-off-by: Tom Rini 
---
 board/imgtec/boston/MAINTAINERS | 5 -
 board/imgtec/malta/MAINTAINERS  | 2 ++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/board/imgtec/boston/MAINTAINERS b/board/imgtec/boston/MAINTAINERS
index 30dd481a26db..ec850d2f9144 100644
--- a/board/imgtec/boston/MAINTAINERS
+++ b/board/imgtec/boston/MAINTAINERS
@@ -3,4 +3,7 @@ M:  Paul Burton 
 S: Maintained
 F: board/imgtec/boston/
 F: include/configs/boston.h
-F: configs/boston_defconfig
+F: configs/boston32r2_defconfig
+F: configs/boston32r2el_defconfig
+F: configs/boston64r2_defconfig
+F: configs/boston64r2el_defconfig
diff --git a/board/imgtec/malta/MAINTAINERS b/board/imgtec/malta/MAINTAINERS
index a0b3284992d7..052ec67b14f5 100644
--- a/board/imgtec/malta/MAINTAINERS
+++ b/board/imgtec/malta/MAINTAINERS
@@ -3,5 +3,7 @@ M:  Paul Burton 
 S: Maintained
 F: board/imgtec/malta/
 F: include/configs/malta.h
+F: configs/malta64_defconfig
+F: configs/malta64el_defconfig
 F: configs/malta_defconfig
 F: configs/maltael_defconfig
-- 
1.9.1

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

Re: [U-Boot] Makefile: Fix linking with modern binutils

[Tom Rini]

On Thu, Dec 08, 2016 at 02:22:51PM +1100, Joel Stanley wrote:

> Since Binutils 1a9ccd70f9a7[1] u-boot will not link targets that set
> CONFIG_SYS_TEXT_BASE=0 with the following error:
> 
>   LD  u-boot
> arm-linux-gnueabi-ld.bfd: u-boot: Not enough room for program headers, try
>  linking with -N
> arm-linux-gnueabi-ld.bfd: final link failed: Bad value
> 
> The issue can reproduced the bad binutils and the rock2_defconfig target.
> 
> This issue was also encountered by the powerpc kernel[2], with the fix
> being to pass --no-dynamic-linker for linkers newer than 2.26 when this
> flag was introduced. While version 2.26 and 2.27 will not show this
> error, we are technically creating invalid ELF files without this
> option.
> 
> Ubuntu Zesty's Binutils 2.27.51.20161202 hits this error.
> 
> [1] 
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=1a9ccd70f9a7
> [2] 
> https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/commit/?h=next=ff45000fcb56b5b0f1a14a865d3541746d838a0a
> 
> Signed-off-by: Joel Stanley 
> Reviewed-by: Simon Glass 
> ---
>  Makefile | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index dfed58bec661..0bfd57d81646 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -792,7 +792,11 @@ ifneq ($(CONFIG_BUILD_TARGET),)
>  ALL-y += $(CONFIG_BUILD_TARGET:"%"=%)
>  endif
>  
> -LDFLAGS_u-boot += $(LDFLAGS_FINAL)
> +# Avoid Not enough room for program headers on binutils 2.28 onwards.
> +# Flag was introduced in 2.26
> +LDFLAGS_u-boot += $(LDFLAGS_FINAL) \
> + $(call ld-ifversion, -ge, 2260, --no-dynamic-linker)

This breaks on things like:
$ arm-none-eabi-ld --version
GNU ld (GNU Tools for ARM Embedded Processors) 2.24.0.20150921

so please use ld-option instead to add this when supported, thanks!

-- 
Tom


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

[U-Boot] [PATCH v3] timer: Support clocks via phandle

[Vlad Zakharov]

Earlier timer driver needed a clock-frequency property in compatible
device-tree nodes. Another way is to reference a clock via a phandle.

So now timer_pre_probe tries to get clock by reference through device
tree. In case it is impossible to get clock device through the
reference, clock-frequency property of the timer node is read to provide
backward compatibility.

Signed-off-by: Vlad Zakharov 
Reviewed-by: Simon Glass 
---
Changes v2..v3:
 - Use value type instead of pointer for timer_clk in order to fix
build time warnings

 drivers/timer/timer-uclass.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/timer/timer-uclass.c b/drivers/timer/timer-uclass.c
index f8ddf93..5c63e6b 100644
--- a/drivers/timer/timer-uclass.c
+++ b/drivers/timer/timer-uclass.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -42,9 +43,19 @@ unsigned long notrace timer_get_rate(struct udevice *dev)
 static int timer_pre_probe(struct udevice *dev)
 {
struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
-
-   uc_priv->clock_rate = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
-"clock-frequency", 0);
+   struct clk timer_clk;
+   int err;
+   ulong ret;
+
+   err = clk_get_by_index(dev, 0, _clk);
+   if (!err) {
+   ret = clk_get_rate(_clk);
+   if (IS_ERR_VALUE(ret))
+   return ret;
+   uc_priv->clock_rate = ret;
+   } else
+   uc_priv->clock_rate = fdtdec_get_int(gd->fdt_blob,
+   dev->of_offset, "clock-frequency", 0);
 
return 0;
 }
-- 
2.7.4

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

Re: [U-Boot] [PATCH v2 2/5] net: phy: Add support for Marvell M88E1512

[Stefan Roese]

On 09.12.2016 14:38, Phil Edworthy wrote:

This device also works with the 88E1518 code, so we just adjust
the UID mask accordingly.

Signed-off-by: Phil Edworthy 
---
v2:
 Don't add a new entry, just adjust the UID mask.
---
 drivers/net/phy/marvell.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 95d1492..5adfe7d 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -585,10 +585,14 @@ static struct phy_driver M88E1510_driver = {
.shutdown = _shutdown,
 };

+/* This supports:
+ *  88E1518, uid 0x1410dd1
+ *  88E1512, uid 0x1410dd4
+ */


Nitpicking comment:

Please use this multiline comment style:

/*
 * This supports:
 *  88E1518, uid 0x1410dd1
 *  88E1512, uid 0x1410dd4
 */


 static struct phy_driver M88E1518_driver = {
.name = "Marvell 88E1518",
.uid = 0x1410dd1,
-   .mask = 0xfff,
+   .mask = 0xffb,
.features = PHY_GBIT_FEATURES,
.config = _config,
.startup = _startup,



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 v2 5/5] net: phy: Marvell: Use phy_interface_is_rgmii helper function

[Phil Edworthy]

Signed-off-by: Phil Edworthy 
Reviewed-by: Stefan Roese 
---
v2:
 No changes
---
 drivers/net/phy/marvell.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index b6c005f..f640a81 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -193,10 +193,7 @@ static int m88es_config(struct phy_device *phydev)
 {
int reg;
 
-   if ((phydev->interface == PHY_INTERFACE_MODE_RGMII) ||
-   (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) ||
-   (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
-   (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)) {
+   if (phy_interface_is_rgmii(phydev)) {
reg = phy_read(phydev,
MDIO_DEVAD_NONE, MIIM_88E_PHY_EXT_CR);
if ((phydev->interface == PHY_INTERFACE_MODE_RGMII) ||
-- 
2.7.4

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

[U-Boot] [PATCH v2 3/5] net: phy: Marvell 88E151x: Add support for RGMII

[Phil Edworthy]

This has been tested with a Marvell 88E1512 PHY.

Signed-off-by: Phil Edworthy 
Reviewed-by: Stefan Roese 
---
v2:
 Rebased on top of Joe's code to use macros
---
 drivers/net/phy/marvell.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 5adfe7d..646b00d 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -94,6 +94,7 @@
 #define MIIM_88E151x_INT_EN_OFFS   7
 /* Page 18 registers */
 #define MIIM_88E151x_GENERAL_CTRL  20
+#define MIIM_88E151x_MODE_RGMII0
 #define MIIM_88E151x_MODE_SGMII1
 #define MIIM_88E151x_RESET_OFFS15
 
@@ -315,14 +316,22 @@ static int m88e1518_config(struct phy_device *phydev)
phy_write(phydev, MDIO_DEVAD_NONE, 16, 0x2159);
phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE, 0x);
 
-   /* SGMII-to-Copper mode initialization */
-   if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
+   /* SGMII/RGMII-to-Copper mode initialization */
+   if ((phydev->interface == PHY_INTERFACE_MODE_SGMII) ||
+   phy_interface_is_rgmii(phydev)) {
+   u16 mode;
+
+   if (phydev->interface == PHY_INTERFACE_MODE_SGMII)
+   mode = MIIM_88E151x_MODE_SGMII;
+   else
+   mode = MIIM_88E151x_MODE_RGMII;
+
/* Select page 18 */
phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE, 18);
 
-   /* In reg 20, write MODE[2:0] = 0x1 (SGMII to Copper) */
+   /* In reg 20, write MODE[2:0], SGMII or RGMII to Copper */
m88e1518_phy_writebits(phydev, MIIM_88E151x_GENERAL_CTRL,
-  0, 3, MIIM_88E151x_MODE_SGMII);
+  0, 3, mode);
 
/* PHY reset is necessary after changing MODE[2:0] */
m88e1518_phy_writebits(phydev, MIIM_88E151x_GENERAL_CTRL,
-- 
2.7.4

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

[U-Boot] [PATCH v2 4/5] net: phy: Marvell 88E151x: Increase delay after init

[Phil Edworthy]

On Marvell 88E1512, the delay is not enough when connected
to some external switches (e.g. Netgear GS108E).

Signed-off-by: Phil Edworthy 
Reviewed-by: Stefan Roese 
---
v2:
 No changes
---
 drivers/net/phy/marvell.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 646b00d..b6c005f 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -340,7 +340,7 @@ static int m88e1518_config(struct phy_device *phydev)
/* Reset page selection */
phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE, 0);
 
-   udelay(100);
+   udelay(500);
}
 
return m88es_config(phydev);
-- 
2.7.4

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

[U-Boot] [PATCH v2 2/5] net: phy: Add support for Marvell M88E1512

[Phil Edworthy]

This device also works with the 88E1518 code, so we just adjust
the UID mask accordingly.

Signed-off-by: Phil Edworthy 
---
v2:
 Don't add a new entry, just adjust the UID mask.
---
 drivers/net/phy/marvell.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 95d1492..5adfe7d 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -585,10 +585,14 @@ static struct phy_driver M88E1510_driver = {
.shutdown = _shutdown,
 };
 
+/* This supports:
+ *  88E1518, uid 0x1410dd1
+ *  88E1512, uid 0x1410dd4
+ */
 static struct phy_driver M88E1518_driver = {
.name = "Marvell 88E1518",
.uid = 0x1410dd1,
-   .mask = 0xfff,
+   .mask = 0xffb,
.features = PHY_GBIT_FEATURES,
.config = _config,
.startup = _startup,
-- 
2.7.4

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

[U-Boot] [PATCH v2 1/5] net: phy: Fix mask so that we can identify Marvell 88E1518

[Phil Edworthy]

The mask for the 88E1510 meant that the 88E1518 code would never be
used.

Signed-off-by: Phil Edworthy 
Reviewed-by: Stefan Roese 
---
Note: This has only been tested on a board that uses a Marvell 88E1512
PHY, see subsequent patches.

v2:
 No changes
---
 drivers/net/phy/marvell.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index ac13a67..95d1492 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -578,7 +578,7 @@ static struct phy_driver M88E1149S_driver = {
 static struct phy_driver M88E1510_driver = {
.name = "Marvell 88E1510",
.uid = 0x1410dd0,
-   .mask = 0xff0,
+   .mask = 0xfff,
.features = PHY_GBIT_FEATURES,
.config = _config,
.startup = _startup,
@@ -588,7 +588,7 @@ static struct phy_driver M88E1510_driver = {
 static struct phy_driver M88E1518_driver = {
.name = "Marvell 88E1518",
.uid = 0x1410dd1,
-   .mask = 0xff0,
+   .mask = 0xfff,
.features = PHY_GBIT_FEATURES,
.config = _config,
.startup = _startup,
-- 
2.7.4

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

[U-Boot] [PATCH v2 0/5] net: phy: Add Marvell M88E1512

[Phil Edworthy]

These patches add support for the Marvell M88E1512 PHY.

Phil Edworthy (5):
  net: phy: Fix mask so that we can identify Marvell 88E1518
  net: phy: Add support for Marvell M88E1512
  net: phy: Marvell 88E151x: Add support for RGMII
  net: phy: Marvell 88E151x: Increase delay after init
  net: phy: Marvell: Use phy_interface_is_rgmii helper function

 drivers/net/phy/marvell.c | 32 +---
 1 file changed, 21 insertions(+), 11 deletions(-)

-- 
2.7.4

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

Re: [U-Boot] [PATCH] net: phy: Improve the Marvell 151x constants

[Phil Edworthy]

Hi Joe,

On 02 December 2016 05:50, Joe Hershberger wrote:
> On 01.12.2016 18:08, Joe Hershberger wrote:
> > Use some constants for the phy configuration instead of so many magic
> > numbers.
> >
> > Signed-off-by: Joe Hershberger 
> > ---
> >
> >  drivers/net/phy/marvell.c | 47 -
> --
> >  1 file changed, 36 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> > index 4eeb0f6..e06fdac 100644
> > --- a/drivers/net/phy/marvell.c
> > +++ b/drivers/net/phy/marvell.c
> > @@ -82,6 +82,21 @@
> >  #define MIIM_88E1310_PHY_RGMII_CTRL21
> >  #define MIIM_88E1310_PHY_PAGE  22
> >
> > +/* 88E151x PHY defines */
> > +/* Page 3 registers */
> > +#define MIIM_88E151x_LED_FUNC_CTRL 16
> > +#define MIIM_88E151x_LED_FLD_SZ4
> > +#define MIIM_88E151x_LED0_OFFS (0 *
> MIIM_88E151x_LED_FLD_SIZE)
> > +#define MIIM_88E151x_LED1_OFFS (1 *
> MIIM_88E151x_LED_FLD_SIZE)

Build error: 
marvell.c:89:38: error: 'MIIM_88E151x_LED_FLD_SIZE' undeclared
I guess it should use 'MIIM_88E151x_LED_FLD_SZ' instead!


> > +#define MIIM_88E151x_LED0_ACT  3
> > +#define MIIM_88E151x_LED1_100_1000_LINK6
> > +#define MIIM_88E151x_LED_TIMER_CTRL18
> > +#define MIIM_88E151x_INT_EN_OFFS   7
> > +/* Page 18 registers */
> > +#define MIIM_88E151x_GENERAL_CTRL  20
> > +#define MIIM_88E151x_MODE_SGMII1
> > +#define MIIM_88E151x_RESET_OFFS15
> > +
> >  /* Marvell 88E1011S */
> >  static int m88e1011s_config(struct phy_device *phydev)
> >  {
> > @@ -289,7 +304,7 @@ static int m88e1518_config(struct phy_device *phydev)
> >  */
> >
> > /* EEE initialization */
> > -   phy_write(phydev, MDIO_DEVAD_NONE, 22, 0x00ff);
> > +   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE,
> 0x00ff);
> > phy_write(phydev, MDIO_DEVAD_NONE, 17, 0x214B);
> > phy_write(phydev, MDIO_DEVAD_NONE, 16, 0x2144);
> > phy_write(phydev, MDIO_DEVAD_NONE, 17, 0x0C28);
> > @@ -298,21 +313,23 @@ static int m88e1518_config(struct phy_device
> *phydev)
> > phy_write(phydev, MDIO_DEVAD_NONE, 16, 0x214D);
> > phy_write(phydev, MDIO_DEVAD_NONE, 17, 0xCC0C);
> > phy_write(phydev, MDIO_DEVAD_NONE, 16, 0x2159);
> > -   phy_write(phydev, MDIO_DEVAD_NONE, 22, 0x);
> > +   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE,
> 0x);
> >
> > /* SGMII-to-Copper mode initialization */
> > if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
> > /* Select page 18 */
> > -   phy_write(phydev, MDIO_DEVAD_NONE, 22, 18);
> > +   phy_write(phydev, MDIO_DEVAD_NONE,
> MIIM_88E1118_PHY_PAGE, 18);
> >
> > /* In reg 20, write MODE[2:0] = 0x1 (SGMII to Copper) */
> > -   m88e1518_phy_writebits(phydev, 20, 0, 3, 1);
> > +   m88e1518_phy_writebits(phydev,
> MIIM_88E151x_GENERAL_CTRL,
> > +  0, 3, MIIM_88E151x_MODE_SGMII);
> >
> > /* PHY reset is necessary after changing MODE[2:0] */
> > -   m88e1518_phy_writebits(phydev, 20, 15, 1, 1);
> > +   m88e1518_phy_writebits(phydev,
> MIIM_88E151x_GENERAL_CTRL,
> > +  MIIM_88E151x_RESET_OFFS, 1, 1);
> >
> > /* Reset page selection */
> > -   phy_write(phydev, MDIO_DEVAD_NONE, 22, 0);
> > +   phy_write(phydev, MDIO_DEVAD_NONE,
> MIIM_88E1118_PHY_PAGE, 0);
> >
> > udelay(100);
> > }
> > @@ -324,17 +341,25 @@ static int m88e1518_config(struct phy_device
> *phydev)
> >  static int m88e1510_config(struct phy_device *phydev)
> >  {
> > /* Select page 3 */
> > -   phy_write(phydev, MDIO_DEVAD_NONE, 22, 3);
> > +   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE,
> > + MIIM_88E1118_PHY_LED_PAGE);
> >
> > /* Enable INTn output on LED[2] */
> > -   m88e1518_phy_writebits(phydev, 18, 7, 1, 1);
> > +   m88e1518_phy_writebits(phydev, MIIM_88E151x_LED_TIMER_CTRL,
> > +  MIIM_88E151x_INT_EN_OFFS, 1, 1);
> >
> > /* Configure LEDs */
> > -   m88e1518_phy_writebits(phydev, 16, 0, 4, 3); /* LED[0]:0011 (ACT) */
> > -   m88e1518_phy_writebits(phydev, 16, 4, 4, 6); /* LED[1]:0110 (LINK) */
> > +   /* LED[0]:0011 (ACT) */
> > +   m88e1518_phy_writebits(phydev, MIIM_88E151x_LED_FUNC_CTRL,
> > +  MIIM_88E151x_LED0_OFFS,
> MIIM_88E151x_LED_FLD_SZ,
> > +  MIIM_88E151x_LED0_ACT);
> > +   /* LED[1]:0110 (LINK 100/1000 Mbps) */
> > +   m88e1518_phy_writebits(phydev, MIIM_88E151x_LED_FUNC_CTRL,
> > +  MIIM_88E151x_LED1_OFFS,
> MIIM_88E151x_LED_FLD_SZ,
> > +  MIIM_88E151x_LED1_100_1000_LINK);
> >
> > /* Reset page selection */
> > -   phy_write(phydev, MDIO_DEVAD_NONE, 22, 0);
> > +   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE, 0);
> >
> > return 

Re: [U-Boot] [PATCH 02/10] arm: socfpga: arria10: Added config option build for SPL

[Marek Vasut]

On 12/09/2016 10:46 AM, Chee, Tien Fong wrote:
> On Rab, 2016-12-07 at 14:54 +0100, Marek Vasut wrote:
>> On 12/07/2016 11:57 AM, Chee, Tien Fong wrote:
>>>
>>> On Sel, 2016-12-06 at 13:47 +0100, Marek Vasut wrote:

 On 12/06/2016 08:52 AM, Chee Tien Fong wrote:
>
>
> From: Tien Fong Chee 
>
> These changes to ensure Arria10 SPL build success.
 Please reword the commit message, mention you're removing the
 Arria10
 bits. Still, this does not even apply on mainline, on top of what
 does
 this apply ?

>>> I disabled some features temporary, so SPL build can pass and print
>>> out
>>> working. I will enable these features back in upcoming patches.
>>> This is
>>> base on 01-arria10 branch.
>> But this patch seems to only enable stuff ... ?
>>
> Enable the spl. Disable SPI flash temporary, for preventing build
> failed, but this will be enabled back with upcoming patches for
> supporting SPI flash.

What's the problem with SPI flash ? I thought it's the same block as in
C/A 5 ?


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

Re: [U-Boot] [PATCH 05/10] arm: socfpga: arria10: Added support for Arria 10 SoC dev kit

[Marek Vasut]

On 12/09/2016 10:55 AM, Chee, Tien Fong wrote:
> On Rab, 2016-12-07 at 14:57 +0100, Marek Vasut wrote:
>> On 12/07/2016 12:21 PM, Chee, Tien Fong wrote:
>>>
>>> On Sel, 2016-12-06 at 13:51 +0100, Marek Vasut wrote:

 On 12/06/2016 09:07 AM, Chee Tien Fong wrote:
>
>
> From: Tien Fong Chee 
>
> Signed-off-by: Tien Fong Chee 
> Cc: Marek Vasut 
> Cc: Dinh Nguyen 
> Cc: Chin Liang See 
> Cc: Tien Fong 
> ---
>  arch/arm/mach-socfpga/include/mach/base_addr_a10.h |   11 +-
>  arch/arm/mach-socfpga/system_manager.c |4 +-
>  drivers/fpga/socfpga.c |7 +-
>  include/configs/socfpga_arria10_socdk.h|  152
> +--
>  4 files changed, 151 insertions(+), 23 deletions(-)
>
> diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_a10.h
> b/arch/arm/mach-socfpga/include/mach/base_addr_a10.h
> index 902c321..487a5dc 100644
> --- a/arch/arm/mach-socfpga/include/mach/base_addr_a10.h
> +++ b/arch/arm/mach-socfpga/include/mach/base_addr_a10.h
> @@ -1,7 +1,7 @@
>  /*
> - * Copyright (C) 2014 Altera Corporation 
> + * Copyright (C) 2014-2016 Altera Corporation 
>   *
> - * SPDX-License-Identifier:  GPL-2.0+
> + * SPDX-License-Identifier:  GPL-2.0
 Can you change license this way ?

>>> Okay, i will revert this change. I discussed with Chin Liang today,
>>> and
>>> we decided to let owner to make the changes. How about the year
>>> change
>>> 2014-2016?
>> To change a license of a file, you need to get an ACK from every
>> single
>> contributor to that file.
>>
>> Year change I believe is fine.
>>
>> [...]
>>
> Okay, noted.
>>>

>
> @@ -89,6 +120,95 @@
>   " root=${qspiroot} rw
> rootfstype=${qspirootfstype};"\
>   "bootm ${loadaddr} - ${fdt_addr}\0"
>  
> -/* The rest of the configuration is shared */
> -#include 
> +/*
> + * External memory configurations
> + */
 Why is this being duplicated in board support code when it
 previously
 was in common code ? That's just wrong.

>>> I found that many conflicts between the board support code and
>>> common
>>> code. It is safe for Arria10 having its own setting here. What do
>>> you
>>> think?
>> It looks like 95% of the stuff below is the same as the stuff in
>> socfpga-common.h , the rest can be pulled from DT or ifdef'd .
>>
> If socfpga-common.h is preferred, then i have to use ifdef method, are
> you ok with this? However, this would look a bit messy, because some
> #define setting in here, and other #define setting in socfpga-common.h
> under same category or peripheral configuration group.

Looks like there are only about two or three differences between the
stuff below and socfpga_common.h , so just put it into common , it
should be OK.


>
> +#define PHYS_SDRAM_1   0x0
> +#define PHYS_SDRAM_1_SIZE  0x8000
> +#define CONFIG_SYS_SDRAM_BASE  0
> +#define CONFIG_NR_DRAM_BANKS   1
> +#define CONFIG_SYS_MEMTEST_START   0
> +#define CONFIG_SYS_MEMTEST_END 0x10
> +
> +/*
> + * Serial / UART configurations
> + */
> +#define CONFIG_SYS_NS16550_SERIAL
> +#define CONFIG_SYS_NS16550_MEM32
> +#define CONFIG_SYS_NS16550_REG_SIZE-4
> +#define CONFIG_SYS_NS16550_COM1SOCFPGA_UART1_ADDRESS
> +#define CONFIG_SYS_BAUDRATE_TABLE {4800, 9600, 19200, 38400,
> 57600, 115200}
> +#define CONFIG_SYS_NS16550_CLK (5000)
> +#define CONFIG_CONS_INDEX  1
> +#define CONFIG_BAUDRATE115200
> +
> +/*
> + * L4 OSC1 Timer 0
> + */
> +/* This timer use eosc1 where the clock frequency is fixed
> + * throughout any condition */
> +#define CONFIG_SYS_TIMERBASE SOCFPGA_SYSTIMER0_
> ADDR
> ESS
> +/* address of timer counter value */
> +#define CONFIG_SYS_TIMER_COUNTER (CONFIG_SYS_TIMERBASE
> +
> 0x4)
> +/* reload value when timer count to zero */
> +#define TIMER_LOAD_VAL   0x
> +/* Clocks source frequency to timer */
> +#define CONFIG_SYS_TIMER_RATE(2500)
> +
> +/* DesignWare timer is a countdown timer */
> +#define CONFIG_SYS_TIMER_COUNTS_DOWN
> +
> +/*
> + * L4 Watchdog configurations
> + */
> +#ifdef CONFIG_HW_WATCHDOG
> +#define CONFIG_DESIGNWARE_WATCHDOG
> +#define CONFIG_DW_WDT_BASE   SOCFPGA_L4WD0_ADDRES
> S
> +#define CONFIG_HPS_CLK_OSC1_HZ   2500
> +#define CONFIG_DW_WDT_CLOCK_KHZ  (CONFIG_HPS_CLK
> _OSC
> 1_HZ / 1000)
> +#define CONFIG_HW_WATCHDOG_TIMEOUT_MS(2000)
> +#endif

Re: [U-Boot] [PATCH 06/10] arm: socfpga: arria10: Added drivers for Arria10 Reset Manager

[Marek Vasut]

On 12/09/2016 11:04 AM, Chee, Tien Fong wrote:
> On Rab, 2016-12-07 at 14:58 +0100, Marek Vasut wrote:
>> On 12/07/2016 12:58 PM, Chee, Tien Fong wrote:
>>>
>>> On Sel, 2016-12-06 at 13:55 +0100, Marek Vasut wrote:

 On 12/06/2016 09:08 AM, Chee Tien Fong wrote:
>
>
> From: Tien Fong Chee 
>
> Drivers for reset manager is restructured such that common
> functions,
> gen5 drivers and Arria10 drivers are moved to reset_manager.c,
> reset_manager_gen5.c and reset_manager_arria10.c respectively.
>
> Signed-off-by: Tien Fong Chee 
> Cc: Marek Vasut 
> Cc: Dinh Nguyen 
> Cc: Chin Liang See 
> Cc: Tien Fong 
>> [...]
>>
>>>

>
> +void reset_deassert_dedicated_peripherals(void)
> +{
> + int i;
> + u32 mask0 = 0;
> + u32 mask1 = 0;
> + u32 pinmux_addr = SOCFPGA_PINMUX_DEDICATED_IO_ADDRESS;
> + u32 mask = 0;
> +#if defined(CONFIG_MMC)
> + mask |= ALT_RSTMGR_PER0MODRST_SDMMCECC_SET_MSK;
> +#elif defined(CONFIG_CADENCE_QSPI)
> + mask |= ALT_RSTMGR_PER0MODRST_QSPIECC_SET_MSK;
> +#elif defined(CONFIG_NAND_DENALI)
> + mask |= ALT_RSTMGR_PER0MODRST_NANDECC_SET_MSK;
> +#else
 Shouldn't this come from OF instead of being ifdef'd ?

>>> What is OF?
>> Device Tree (Open Firmware).
>>
>>>
>>> what is your suggestion to make this function generic for
>>> all type of flash?
>> Pull it from OF ?
>>
> Why you prefer device tree implementation over #define in defconfig,
> because there is performance penalty.

Because we are moving away from excessive random #defines and toward
having one single binary where you could exchange just the DT and run
it on multiple boards, just like Linux, that is the ultimate goal.

Also, this is not performance critical code, is it.

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

Re: [U-Boot] [GIT PULL] Xilinx and SCSI changes

[Tom Rini]

On Fri, Dec 09, 2016 at 01:54:30PM +0100, Michal Simek wrote:
> Hi Tom,
> 
> On 9.12.2016 13:11, Tom Rini wrote:
> > On Fri, Dec 02, 2016 at 02:55:00PM +0100, Michal Simek wrote:
> >> Hi Tom,
> >>
> >> here are some patches I have collected for Xilinx devices, one miiphy
> >> patch and SCSI changes I have made.
> >>
> >> Simon: I have sent v4 of DM_SCSI + ceva sata driver moved to DM which
> >> should go through your tree because you have applied
> >> "dm: blk: Fix get_desc to return block device descriptor"
> >> which is required. They are based on this branch.
> >>
> >> Tom: I have tested also travis with zynq qemu but it looks like a
> >> problem with qemu timing for zynq model. The rest of python tests look
> >> good. https://travis-ci.org/michalsimek-test/u-boot/jobs/180384185
> >> Also for running this I had to use CONFIG_OF_EMBED=y to handle dtb.
> >> Anyway I will talk to Qemu guys what I can do with it and when this
> >> timing issue was solved and which mainline qemu version this requires.
> >> Is there arm64 qemu available too?
> >>
> >> Thanks,
> >> Michal
> >>
> >>
> >>  The following changes since commit
> >> 9ae0e14350758e6447c90615ff4df530549a45e2:
> >>
> >>Merge git://www.denx.de/git/u-boot-marvell (2016-12-01 09:24:02 -0500)
> >>
> >>  are available in the git repository at:
> >>
> >>
> >>git://www.denx.de/git/u-boot-microblaze.git master
> >>
> >>  for you to fetch changes up to 861fe6503e205622202a61d3ca86cd4ccb80bf03:
> >>
> >>cmd: scsi: Make private functions static (2016-12-02 14:37:32 +0100)
> >>
> > 
> > Applied to u-boot/master, thanks!
> > 
> 
> This PR was applied already. And if you look at what you have applied
> just now is temporary branch. Nothing what should be added to tree in
> this state. In general it is mess.
> You should revert that stuff you have merged even it contain some
> patches which should be merged soon.

OK, oops, sorry.  I've reverted that merge just now.  Sorry about that!

And for the record, this was applied correctly earlier but I lost the
mail apparently.

-- 
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] [GIT PULL] Xilinx and SCSI changes

[Michal Simek]

Hi Tom,

On 9.12.2016 13:11, Tom Rini wrote:
> On Fri, Dec 02, 2016 at 02:55:00PM +0100, Michal Simek wrote:
>> Hi Tom,
>>
>> here are some patches I have collected for Xilinx devices, one miiphy
>> patch and SCSI changes I have made.
>>
>> Simon: I have sent v4 of DM_SCSI + ceva sata driver moved to DM which
>> should go through your tree because you have applied
>> "dm: blk: Fix get_desc to return block device descriptor"
>> which is required. They are based on this branch.
>>
>> Tom: I have tested also travis with zynq qemu but it looks like a
>> problem with qemu timing for zynq model. The rest of python tests look
>> good. https://travis-ci.org/michalsimek-test/u-boot/jobs/180384185
>> Also for running this I had to use CONFIG_OF_EMBED=y to handle dtb.
>> Anyway I will talk to Qemu guys what I can do with it and when this
>> timing issue was solved and which mainline qemu version this requires.
>> Is there arm64 qemu available too?
>>
>> Thanks,
>> Michal
>>
>>
>>  The following changes since commit
>> 9ae0e14350758e6447c90615ff4df530549a45e2:
>>
>>Merge git://www.denx.de/git/u-boot-marvell (2016-12-01 09:24:02 -0500)
>>
>>  are available in the git repository at:
>>
>>
>>git://www.denx.de/git/u-boot-microblaze.git master
>>
>>  for you to fetch changes up to 861fe6503e205622202a61d3ca86cd4ccb80bf03:
>>
>>cmd: scsi: Make private functions static (2016-12-02 14:37:32 +0100)
>>
> 
> Applied to u-boot/master, thanks!
> 

This PR was applied already. And if you look at what you have applied
just now is temporary branch. Nothing what should be added to tree in
this state. In general it is mess.
You should revert that stuff you have merged even it contain some
patches which should be merged soon.

Thanks,
Michal



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

Re: [U-Boot] [PATCH 2/5] net: phy: Add support for Marvell M88E1512

[Stefan Roese]

Hi Phil,

On 09.12.2016 13:38, Phil Edworthy wrote:

On 09 December 2016 12:16, Stefan Roese wrote:

On 09.12.2016 11:40, Phil Edworthy wrote:

Signed-off-by: Phil Edworthy 
---
 drivers/net/phy/marvell.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 06029c0..a7ea435 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -560,6 +560,16 @@ static struct phy_driver M88E1510_driver = {
.shutdown = _shutdown,
 };

+static struct phy_driver M88E1512_driver = {
+   .name = "Marvell 88E1512",
+   .uid = 0x01410dd4,
+   .mask = 0xfff,
+   .features = PHY_GBIT_FEATURES,
+   .config = _config,
+   .startup = _startup,
+   .shutdown = _shutdown,
+};
+
 static struct phy_driver M88E1518_driver = {
.name = "Marvell 88E1518",
.uid = 0x1410dd1,
@@ -591,6 +601,7 @@ int phy_marvell_init(void)
phy_register(_driver);
phy_register(_driver);
phy_register(_driver);
+   phy_register(_driver);
phy_register(_driver);


Do you need some special handling for the M88E1512 or is it identical
to the 1518 handling? If its identical, why do we need a new entry
for this PHY?

Good point, they are the same except for the uid so no need for a new
entry. I'll change the mask of the 1518 to cover it.


Thanks.


Btw, what's the best way to indicate that the code supports the 1512
as well? It's not so easy to see if the code supports a particular device
ahead of hardware arriving, other than trying to match the uid's
manually.


A comment would be welcome here. Not sure if this is done in a more
generic way in the Linux PHY drivers. You might want to check there
as well...

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

Re: [U-Boot] [PATCH 3/5] net: phy: Marvell 88E151x: Add support for RGMII

[Phil Edworthy]

Hi Stefan,

On 09 December 2016 12:19, Stefan Roese wrote:
> On 09.12.2016 11:41, Phil Edworthy wrote:
> > This has been tested with a Marvell 88E1512 PHY.
> >
> > Signed-off-by: Phil Edworthy 
> > ---
> >  drivers/net/phy/marvell.c | 14 ++
> >  1 file changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> > index a7ea435..8214760 100644
> > --- a/drivers/net/phy/marvell.c
> > +++ b/drivers/net/phy/marvell.c
> > @@ -300,13 +300,19 @@ static int m88e1518_config(struct phy_device
> *phydev)
> > phy_write(phydev, MDIO_DEVAD_NONE, 16, 0x2159);
> > phy_write(phydev, MDIO_DEVAD_NONE, 22, 0x);
> >
> > -   /* SGMII-to-Copper mode initialization */
> > -   if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
> > +   /* SGMII/RGMII-to-Copper mode initialization */
> > +   if ((phydev->interface == PHY_INTERFACE_MODE_SGMII) ||
> > +   phy_interface_is_rgmii(phydev)) {
> > /* Select page 18 */
> > phy_write(phydev, MDIO_DEVAD_NONE, 22, 18);
> >
> > -   /* In reg 20, write MODE[2:0] = 0x1 (SGMII to Copper) */
> > -   m88e1518_phy_writebits(phydev, 20, 0, 3, 1);
> > +   if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
> > +   /* In reg 20, write MODE[2:0] = 0x1 (SGMII to Copper) */
> > +   m88e1518_phy_writebits(phydev, 20, 0, 3, 1);
> > +   } else {
> > +   /* In reg 20, write MODE[2:0] = 0x0 (RGMII to Copper) */
> > +   m88e1518_phy_writebits(phydev, 20, 0, 3, 0);
> > +   }
> >
> > /* PHY reset is necessary after changing MODE[2:0] */
> > m88e1518_phy_writebits(phydev, 20, 15, 1, 1);
> >
> 
> Joe has recently sent a patch, adding some nice macros for the
> some "standard" Marvell PHY register, like PAGE [1]. So this patch
> will most likely generate some merge problems. Please rebase it
> on top of Joe's patch.
Will do!

Thanks
Phil
> Other than this:
> 
> Reviewed-by: Stefan Roese 
> 
> Thanks,
> Stefan
> 
> [1] https://patchwork.ozlabs.org/patch/701613/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] net: phy: Add support for Marvell M88E1512

[Phil Edworthy]

Hi Stefan,

On 09 December 2016 12:16, Stefan Roese wrote:
> On 09.12.2016 11:40, Phil Edworthy wrote:
> > Signed-off-by: Phil Edworthy 
> > ---
> >  drivers/net/phy/marvell.c | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> > index 06029c0..a7ea435 100644
> > --- a/drivers/net/phy/marvell.c
> > +++ b/drivers/net/phy/marvell.c
> > @@ -560,6 +560,16 @@ static struct phy_driver M88E1510_driver = {
> > .shutdown = _shutdown,
> >  };
> >
> > +static struct phy_driver M88E1512_driver = {
> > +   .name = "Marvell 88E1512",
> > +   .uid = 0x01410dd4,
> > +   .mask = 0xfff,
> > +   .features = PHY_GBIT_FEATURES,
> > +   .config = _config,
> > +   .startup = _startup,
> > +   .shutdown = _shutdown,
> > +};
> > +
> >  static struct phy_driver M88E1518_driver = {
> > .name = "Marvell 88E1518",
> > .uid = 0x1410dd1,
> > @@ -591,6 +601,7 @@ int phy_marvell_init(void)
> > phy_register(_driver);
> > phy_register(_driver);
> > phy_register(_driver);
> > +   phy_register(_driver);
> > phy_register(_driver);
> 
> Do you need some special handling for the M88E1512 or is it identical
> to the 1518 handling? If its identical, why do we need a new entry
> for this PHY?
Good point, they are the same except for the uid so no need for a new
entry. I'll change the mask of the 1518 to cover it.

Btw, what's the best way to indicate that the code supports the 1512
as well? It's not so easy to see if the code supports a particular device
ahead of hardware arriving, other than trying to match the uid's
manually.

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

Re: [U-Boot] [PATCH v2 2/6] mmc: complete unfinished move of CONFIG_MMC

[Masahiro Yamada]

2016-12-09 8:29 GMT+09:00 Jaehoon Chung :
> On 12/07/2016 10:10 PM, Masahiro Yamada wrote:
>> Commit 7a777f6d6f35 ("mmc: Add generic Kconfig option") created
>> a Kconfig entry for this option without any actual moves, then
>> commit 44c798799f66 ("sunxi: Use Kconfig CONFIG_MMC") moved
>> instances only for SUNXI.
>>
>> We generally do not like such partial moves.  This kind of work
>> is automated by tools/moveconfig.py, so it is pretty easy to
>> complete this move.
>>
>> I am adding "default ARM || PPC || SANDBOX" (suggested by Tom).
>> This shortens the configs and will ease new board porting.
>>
>> This commit was created as follows:
>>
>> [1] Edit Kconfig (remove the "depends on", add the "default",
>> copy the prompt and help message from Linux)
>>
>> [2] Run 'tools/moveconfig.py -y -s -r HEAD MMC'
>>
>> Signed-off-by: Masahiro Yamada 
>
> Reviewd-by: Jaehoon Chung 
>
> Best Regards,
> Jaehoon Chung


I am fixing s/Reviewd/Reviewed/
so that Patchwork will handle the tag correctly.

Reviewed-by: Jaehoon Chung 


(BTW, please stop full-quoting for big patches.)



-- 
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 2/7] disk: Add CONFIG_PARTITION to Kconfig

[Tom Rini]

On Thu, Dec 08, 2016 at 04:04:28PM -0600, Andrew F. Davis wrote:

> Signed-off-by: Andrew F. Davis 
> ---
>  Kconfig   |  2 ++
>  disk/Kconfig  | 11 +++
>  include/config_defaults.h |  1 -
>  3 files changed, 13 insertions(+), 1 deletion(-)
>  create mode 100644 disk/Kconfig

OK, but, we've also got https://patchwork.ozlabs.org/patch/702717/ which
I'll be taking soon, sorry!
 
-- 
Tom


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

Re: [U-Boot] [PATCH 5/5] net: phy: Marvell: Use phy_interface_is_rgmii helper function

[Stefan Roese]

On 09.12.2016 11:41, Phil Edworthy wrote:

Signed-off-by: Phil Edworthy 
---
 drivers/net/phy/marvell.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 48ebb50..dc1d25f 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -177,10 +177,7 @@ static int m88es_config(struct phy_device *phydev)
 {
int reg;

-   if ((phydev->interface == PHY_INTERFACE_MODE_RGMII) ||
-   (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) ||
-   (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
-   (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)) {
+   if (phy_interface_is_rgmii(phydev)) {
reg = phy_read(phydev,
MDIO_DEVAD_NONE, MIIM_88E_PHY_EXT_CR);
if ((phydev->interface == PHY_INTERFACE_MODE_RGMII) ||


Reviewed-by: Stefan Roese 

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

Re: [U-Boot] [PATCH 4/5] net: phy: Marvell 88E151x: Increase delay after init

[Stefan Roese]

On 09.12.2016 11:41, Phil Edworthy wrote:

On Marvell 88E1512, the delay is not enough when connected
to some external switches (e.g. Netgear GS108E).

Signed-off-by: Phil Edworthy 
---
 drivers/net/phy/marvell.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 8214760..48ebb50 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -320,7 +320,7 @@ static int m88e1518_config(struct phy_device *phydev)
/* Reset page selection */
phy_write(phydev, MDIO_DEVAD_NONE, 22, 0);

-   udelay(100);
+   udelay(500);
}

return m88es_config(phydev);


Reviewed-by: Stefan Roese 

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

Re: [U-Boot] [PATCH 3/5] net: phy: Marvell 88E151x: Add support for RGMII

[Stefan Roese]

On 09.12.2016 11:41, Phil Edworthy wrote:

This has been tested with a Marvell 88E1512 PHY.

Signed-off-by: Phil Edworthy 
---
 drivers/net/phy/marvell.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index a7ea435..8214760 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -300,13 +300,19 @@ static int m88e1518_config(struct phy_device *phydev)
phy_write(phydev, MDIO_DEVAD_NONE, 16, 0x2159);
phy_write(phydev, MDIO_DEVAD_NONE, 22, 0x);

-   /* SGMII-to-Copper mode initialization */
-   if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
+   /* SGMII/RGMII-to-Copper mode initialization */
+   if ((phydev->interface == PHY_INTERFACE_MODE_SGMII) ||
+   phy_interface_is_rgmii(phydev)) {
/* Select page 18 */
phy_write(phydev, MDIO_DEVAD_NONE, 22, 18);

-   /* In reg 20, write MODE[2:0] = 0x1 (SGMII to Copper) */
-   m88e1518_phy_writebits(phydev, 20, 0, 3, 1);
+   if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
+   /* In reg 20, write MODE[2:0] = 0x1 (SGMII to Copper) */
+   m88e1518_phy_writebits(phydev, 20, 0, 3, 1);
+   } else {
+   /* In reg 20, write MODE[2:0] = 0x0 (RGMII to Copper) */
+   m88e1518_phy_writebits(phydev, 20, 0, 3, 0);
+   }

/* PHY reset is necessary after changing MODE[2:0] */
m88e1518_phy_writebits(phydev, 20, 15, 1, 1);



Joe has recently sent a patch, adding some nice macros for the
some "standard" Marvell PHY register, like PAGE [1]. So this patch
will most likely generate some merge problems. Please rebase it
on top of Joe's patch.

Other than this:

Reviewed-by: Stefan Roese 

Thanks,
Stefan

[1] https://patchwork.ozlabs.org/patch/701613/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] net: phy: Add support for Marvell M88E1512

[Stefan Roese]

On 09.12.2016 11:40, Phil Edworthy wrote:

Signed-off-by: Phil Edworthy 
---
 drivers/net/phy/marvell.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 06029c0..a7ea435 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -560,6 +560,16 @@ static struct phy_driver M88E1510_driver = {
.shutdown = _shutdown,
 };

+static struct phy_driver M88E1512_driver = {
+   .name = "Marvell 88E1512",
+   .uid = 0x01410dd4,
+   .mask = 0xfff,
+   .features = PHY_GBIT_FEATURES,
+   .config = _config,
+   .startup = _startup,
+   .shutdown = _shutdown,
+};
+
 static struct phy_driver M88E1518_driver = {
.name = "Marvell 88E1518",
.uid = 0x1410dd1,
@@ -591,6 +601,7 @@ int phy_marvell_init(void)
phy_register(_driver);
phy_register(_driver);
phy_register(_driver);
+   phy_register(_driver);
phy_register(_driver);


Do you need some special handling for the M88E1512 or is it identical
to the 1518 handling? If its identical, why do we need a new entry
for this PHY?

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

Re: [U-Boot] [PATCH v3] arm: am33xx: Initialize EMIF REG_PR_OLD_COUNT for BBB and am335x-evm

[Tom Rini]

On Fri, Dec 09, 2016 at 12:29:13PM +0200, Jyri Sarha wrote:

> Initialize EMIF OCP_CONFIG registers REG_COS_COUNT_1, REG_COS_COUNT_2,
> and REG_PR_OLD_COUNT field for Beaglebone-Black and am335x-evm. With
> the default values LCDC suffers from DMA FIFO underflows and frame
> synchronization lost errors. The initialization values are the highest
> that work flawlessly when heavy memory load is generated by CPU. 32bpp
> colors were used in the test. On BBB the video mode used 110MHz pixel
> clock. The mode supported by the panel of am335x-evm uses 30MHz pixel
> clock.
> 
> Signed-off-by: Jyri Sarha 

Thanks again!

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/5] net: phy: Fix mask so that we can identify Marvell 88E1518

[Stefan Roese]

On 09.12.2016 11:40, Phil Edworthy wrote:

The mask for the 88E1510 meant that the 88E1518 code would never be
used.

Signed-off-by: Phil Edworthy 
---
Note: This has only been tested on a board that uses a Marvell 88E1512
PHY, see subsequent patches.
---
 drivers/net/phy/marvell.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 4eeb0f6..06029c0 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -553,7 +553,7 @@ static struct phy_driver M88E1149S_driver = {
 static struct phy_driver M88E1510_driver = {
.name = "Marvell 88E1510",
.uid = 0x1410dd0,
-   .mask = 0xff0,
+   .mask = 0xfff,
.features = PHY_GBIT_FEATURES,
.config = _config,
.startup = _startup,
@@ -563,7 +563,7 @@ static struct phy_driver M88E1510_driver = {
 static struct phy_driver M88E1518_driver = {
.name = "Marvell 88E1518",
.uid = 0x1410dd1,
-   .mask = 0xff0,
+   .mask = 0xfff,
.features = PHY_GBIT_FEATURES,
.config = _config,
.startup = _startup,


Nice catch, thanks. I wonder, why this wasn't detected until now. Still:

Reviewed-by: Stefan Roese 

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

Re: [U-Boot] Pull request: u-boot-net.git master

[Tom Rini]

On Thu, Dec 08, 2016 at 10:37:26AM -0600, Joe Hershberger wrote:

> Hi Tom,
>
> The following changes since commit 388019f1e2166638453bc4e0cc5d138c2a19e0c9:
>
>   Merge branch 'master' of git://git.denx.de/u-boot-usb (2016-12-06 08:07:20 
> -0500)
>
> are available in the git repository at:
>
>
>   git://git.denx.de/u-boot-net.git master
>
> for you to fetch changes up to bb135a0180c31fbd7456021fb9700b49bba7f533:
>
>   net/phy/vitesse: Rework RGMII skew configuration for VSC8601 (2016-12-08 
> 10:36:22 -0600)

This is a NAK and is what is breaking microblaze-generic and
imgtec_xilfpga at least:
+(imgtec_xilfpga,microblaze-generic)   ret =
mdio_register_seq(emaclite->bus, dev->seq);+(imgtec_xilfpga,microblaze-generic) 
  ^
+(imgtec_xilfpga,microblaze-generic) drivers/net/built-in.o: In function
`emaclite_probe':
+(imgtec_xilfpga)
../drivers/net/xilinx_emaclite.c:(.text.emaclite_probe+0x64): undefined 
reference to `mdio_register_seq'
+(imgtec_xilfpga,microblaze-generic) make[1]: *** [u-boot] Error 1
+(imgtec_xilfpga,microblaze-generic) make: *** [sub-make] Error 2
+(microblaze-generic)   ret = mdio_register_seq(priv->bus, dev->seq);
+(microblaze-generic) drivers/net/built-in.o: In function `axi_emac_probe': 
+(microblaze-generic)
build/../drivers/net/xilinx_axi_emac.c:652: undefined reference to 
`mdio_register_seq'
+(microblaze-generic) build/../drivers/net/xilinx_emaclite.c:570: undefined 
reference to `mdio_register_seq'

-- 
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] [GIT PULL] Xilinx and SCSI changes

[Tom Rini]

On Fri, Dec 02, 2016 at 02:55:00PM +0100, Michal Simek wrote:
> Hi Tom,
> 
> here are some patches I have collected for Xilinx devices, one miiphy
> patch and SCSI changes I have made.
> 
> Simon: I have sent v4 of DM_SCSI + ceva sata driver moved to DM which
> should go through your tree because you have applied
> "dm: blk: Fix get_desc to return block device descriptor"
> which is required. They are based on this branch.
> 
> Tom: I have tested also travis with zynq qemu but it looks like a
> problem with qemu timing for zynq model. The rest of python tests look
> good. https://travis-ci.org/michalsimek-test/u-boot/jobs/180384185
> Also for running this I had to use CONFIG_OF_EMBED=y to handle dtb.
> Anyway I will talk to Qemu guys what I can do with it and when this
> timing issue was solved and which mainline qemu version this requires.
> Is there arm64 qemu available too?
> 
> Thanks,
> Michal
> 
> 
>  The following changes since commit
> 9ae0e14350758e6447c90615ff4df530549a45e2:
> 
>Merge git://www.denx.de/git/u-boot-marvell (2016-12-01 09:24:02 -0500)
> 
>  are available in the git repository at:
> 
> 
>git://www.denx.de/git/u-boot-microblaze.git master
> 
>  for you to fetch changes up to 861fe6503e205622202a61d3ca86cd4ccb80bf03:
> 
>cmd: scsi: Make private functions static (2016-12-02 14:37:32 +0100)
> 

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] [GIT PULL] Xilinx and SCSI changes

[Tom Rini]

On Fri, Dec 09, 2016 at 07:34:05AM +0100, Michal Simek wrote:
> Hi Tom,
> 
> On 8.12.2016 17:04, Tom Rini wrote:
> > On Fri, Dec 02, 2016 at 02:55:00PM +0100, Michal Simek wrote:
> > 
> >> Hi Tom,
> >>
> >> here are some patches I have collected for Xilinx devices, one miiphy
> >> patch and SCSI changes I have made.
> >>
> >> Simon: I have sent v4 of DM_SCSI + ceva sata driver moved to DM which
> >> should go through your tree because you have applied
> >> "dm: blk: Fix get_desc to return block device descriptor"
> >> which is required. They are based on this branch.
> >>
> >> Tom: I have tested also travis with zynq qemu but it looks like a
> >> problem with qemu timing for zynq model. The rest of python tests look
> >> good. https://travis-ci.org/michalsimek-test/u-boot/jobs/180384185
> >> Also for running this I had to use CONFIG_OF_EMBED=y to handle dtb.
> >> Anyway I will talk to Qemu guys what I can do with it and when this
> >> timing issue was solved and which mainline qemu version this requires.
> >> Is there arm64 qemu available too?
> >>
> >> Thanks,
> >> Michal
> >>
> >>
> >>  The following changes since commit
> >> 9ae0e14350758e6447c90615ff4df530549a45e2:
> >>
> >>Merge git://www.denx.de/git/u-boot-marvell (2016-12-01 09:24:02 -0500)
> >>
> >>  are available in the git repository at:
> >>
> >>
> >>git://www.denx.de/git/u-boot-microblaze.git master
> >>
> >>  for you to fetch changes up to 861fe6503e205622202a61d3ca86cd4ccb80bf03:
> >>
> >>cmd: scsi: Make private functions static (2016-12-02 14:37:32 +0100)
> > 
> > This blows up microblaze-generic, please fix, thanks!
> 
> What exactly is the problem?
> 
> [u-boot]$ ./tools/buildman/buildman microblaze-generic -b uboot -C -o
> /tmp/2 -c 8 -sSedB
> boards.cfg is up to date. Nothing to do.
> Summary of 8 commits for 1 boards (1 thread, 8 jobs per thread)
> 01: scsi: Take lun from device block description
> 02: scsi: Move pccb buffer initalization directly to scsi_detect_dev
> 03: scsi: Simplify scsi_read/scsi_write()
> 04: scsi: Remove completely unused functions
> 05: scsi: Make private functions static
> 06: scsi: Change scsi_scan() to be able to return value
> 07: scsi: Separate SCSI private block description initialization
> 08: cmd: scsi: Make private functions static
> (no errors to report)
> [u-boot]$ git log --oneline -n 1
> 861fe6503e20 cmd: scsi: Make private functions static
> [u-boot]$
> 
> Microblaze is not enabling anything related to SCSI. I have one design
> from past
> with sata but it was custom project which is not supported in mainline.

Oh, sorry, my fault, wrong PR was breaking things.

-- 
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] net: phy: ti: Fix dp83867 RGMII_TXID interface path

[Phil Edworthy]

There is code that is specifically for RGMII_TXID interface, but this
will never get used because the code checks that the RGMII interface
is RGMII_ID to RGMII_RXID; RGMII_TXID is after this.

To fix this and avoid similar problems in the future, use the
phy_interface_is_rgmii helper function.

Signed-off-by: Phil Edworthy 
---
This has _not_ been tested in any way, shape or form! It was picked
up when converting PHY code to use the phy_interface_is_rgmii helper
function.
---
 drivers/net/phy/ti.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
index c55dd97..5e2b2dd 100644
--- a/drivers/net/phy/ti.c
+++ b/drivers/net/phy/ti.c
@@ -246,8 +246,7 @@ static int dp83867_config(struct phy_device *phydev)
phy_write(phydev, MDIO_DEVAD_NONE, MII_DP83867_BISCR, 0x0);
}
 
-   if ((phydev->interface >= PHY_INTERFACE_MODE_RGMII_ID) &&
-   (phydev->interface <= PHY_INTERFACE_MODE_RGMII_RXID)) {
+   if (phy_interface_is_rgmii(phydev)) {
val = phy_read_mmd_indirect(phydev, DP83867_RGMIICTL,
DP83867_DEVADDR, phydev->addr);
 
-- 
2.7.4

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

[U-Boot] [PATCH 4/5] net: phy: Marvell 88E151x: Increase delay after init

[Phil Edworthy]

On Marvell 88E1512, the delay is not enough when connected
to some external switches (e.g. Netgear GS108E).

Signed-off-by: Phil Edworthy 
---
 drivers/net/phy/marvell.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 8214760..48ebb50 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -320,7 +320,7 @@ static int m88e1518_config(struct phy_device *phydev)
/* Reset page selection */
phy_write(phydev, MDIO_DEVAD_NONE, 22, 0);
 
-   udelay(100);
+   udelay(500);
}
 
return m88es_config(phydev);
-- 
2.7.4

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

[U-Boot] [PATCH 3/5] net: phy: Marvell 88E151x: Add support for RGMII

[Phil Edworthy]

This has been tested with a Marvell 88E1512 PHY.

Signed-off-by: Phil Edworthy 
---
 drivers/net/phy/marvell.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index a7ea435..8214760 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -300,13 +300,19 @@ static int m88e1518_config(struct phy_device *phydev)
phy_write(phydev, MDIO_DEVAD_NONE, 16, 0x2159);
phy_write(phydev, MDIO_DEVAD_NONE, 22, 0x);
 
-   /* SGMII-to-Copper mode initialization */
-   if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
+   /* SGMII/RGMII-to-Copper mode initialization */
+   if ((phydev->interface == PHY_INTERFACE_MODE_SGMII) ||
+   phy_interface_is_rgmii(phydev)) {
/* Select page 18 */
phy_write(phydev, MDIO_DEVAD_NONE, 22, 18);
 
-   /* In reg 20, write MODE[2:0] = 0x1 (SGMII to Copper) */
-   m88e1518_phy_writebits(phydev, 20, 0, 3, 1);
+   if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
+   /* In reg 20, write MODE[2:0] = 0x1 (SGMII to Copper) */
+   m88e1518_phy_writebits(phydev, 20, 0, 3, 1);
+   } else {
+   /* In reg 20, write MODE[2:0] = 0x0 (RGMII to Copper) */
+   m88e1518_phy_writebits(phydev, 20, 0, 3, 0);
+   }
 
/* PHY reset is necessary after changing MODE[2:0] */
m88e1518_phy_writebits(phydev, 20, 15, 1, 1);
-- 
2.7.4

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

[U-Boot] [PATCH 5/5] net: phy: Marvell: Use phy_interface_is_rgmii helper function

[Phil Edworthy]

Signed-off-by: Phil Edworthy 
---
 drivers/net/phy/marvell.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 48ebb50..dc1d25f 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -177,10 +177,7 @@ static int m88es_config(struct phy_device *phydev)
 {
int reg;
 
-   if ((phydev->interface == PHY_INTERFACE_MODE_RGMII) ||
-   (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) ||
-   (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
-   (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)) {
+   if (phy_interface_is_rgmii(phydev)) {
reg = phy_read(phydev,
MDIO_DEVAD_NONE, MIIM_88E_PHY_EXT_CR);
if ((phydev->interface == PHY_INTERFACE_MODE_RGMII) ||
-- 
2.7.4

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

[U-Boot] [PATCH 2/5] net: phy: Add support for Marvell M88E1512

[Phil Edworthy]

Signed-off-by: Phil Edworthy 
---
 drivers/net/phy/marvell.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 06029c0..a7ea435 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -560,6 +560,16 @@ static struct phy_driver M88E1510_driver = {
.shutdown = _shutdown,
 };
 
+static struct phy_driver M88E1512_driver = {
+   .name = "Marvell 88E1512",
+   .uid = 0x01410dd4,
+   .mask = 0xfff,
+   .features = PHY_GBIT_FEATURES,
+   .config = _config,
+   .startup = _startup,
+   .shutdown = _shutdown,
+};
+
 static struct phy_driver M88E1518_driver = {
.name = "Marvell 88E1518",
.uid = 0x1410dd1,
@@ -591,6 +601,7 @@ int phy_marvell_init(void)
phy_register(_driver);
phy_register(_driver);
phy_register(_driver);
+   phy_register(_driver);
phy_register(_driver);
 
return 0;
-- 
2.7.4

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

[U-Boot] [PATCH v3] arm: am33xx: Initialize EMIF REG_PR_OLD_COUNT for BBB and am335x-evm

[Jyri Sarha]

Initialize EMIF OCP_CONFIG registers REG_COS_COUNT_1, REG_COS_COUNT_2,
and REG_PR_OLD_COUNT field for Beaglebone-Black and am335x-evm. With
the default values LCDC suffers from DMA FIFO underflows and frame
synchronization lost errors. The initialization values are the highest
that work flawlessly when heavy memory load is generated by CPU. 32bpp
colors were used in the test. On BBB the video mode used 110MHz pixel
clock. The mode supported by the panel of am335x-evm uses 30MHz pixel
clock.

Signed-off-by: Jyri Sarha 
---
Changes since v2:
- Improved the comment in board/ti/am335x/board.h

Changes since v1:
- Move board specific EMIF_OCP_CONFIG_* definitions to board/ti/am335x/board.h
  and improve the related comment
- Handle also am335x-evms older than revision 1.5

This patch (the first version) has been part of TI's latest 2016LTS
based release and has gone trough our regular tesing as a part of
that. There has been no noticable side effects.

 arch/arm/include/asm/emif.h  |  1 +
 arch/arm/mach-omap2/am33xx/ddr.c |  4 
 board/ti/am335x/board.c  | 15 +++
 board/ti/am335x/board.h  | 13 +
 4 files changed, 33 insertions(+)

diff --git a/arch/arm/include/asm/emif.h b/arch/arm/include/asm/emif.h
index b00dece..9a46340 100644
--- a/arch/arm/include/asm/emif.h
+++ b/arch/arm/include/asm/emif.h
@@ -1171,6 +1171,7 @@ struct emif_regs {
u32 sdram_tim1;
u32 sdram_tim2;
u32 sdram_tim3;
+   u32 ocp_config;
u32 read_idle_ctrl;
u32 zq_config;
u32 temp_alert_config;
diff --git a/arch/arm/mach-omap2/am33xx/ddr.c b/arch/arm/mach-omap2/am33xx/ddr.c
index 6acf30c..690487e 100644
--- a/arch/arm/mach-omap2/am33xx/ddr.c
+++ b/arch/arm/mach-omap2/am33xx/ddr.c
@@ -180,6 +180,10 @@ void config_sdram(const struct emif_regs *regs, int nr)
writel(regs->ref_ctrl, _reg[nr]->emif_sdram_ref_ctrl);
writel(regs->ref_ctrl, _reg[nr]->emif_sdram_ref_ctrl_shdw);
writel(regs->sdram_config, _reg[nr]->emif_sdram_config);
+
+   /* Write REG_COS_COUNT_1, REG_COS_COUNT_2, and REG_PR_OLD_COUNT. */
+   if (regs->ocp_config)
+   writel(regs->ocp_config, _reg[nr]->emif_l3_config);
 }
 
 /**
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index da9eab4..b994b42 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -109,6 +109,16 @@ static const struct emif_regs ddr2_emif_reg_data = {
.emif_ddr_phy_ctlr_1 = MT47H128M16RT25E_EMIF_READ_LATENCY,
 };
 
+static const struct emif_regs ddr2_evm_emif_reg_data = {
+   .sdram_config = MT47H128M16RT25E_EMIF_SDCFG,
+   .ref_ctrl = MT47H128M16RT25E_EMIF_SDREF,
+   .sdram_tim1 = MT47H128M16RT25E_EMIF_TIM1,
+   .sdram_tim2 = MT47H128M16RT25E_EMIF_TIM2,
+   .sdram_tim3 = MT47H128M16RT25E_EMIF_TIM3,
+   .ocp_config = EMIF_OCP_CONFIG_AM335X_EVM,
+   .emif_ddr_phy_ctlr_1 = MT47H128M16RT25E_EMIF_READ_LATENCY,
+};
+
 static const struct ddr_data ddr3_data = {
.datardsratio0 = MT41J128MJT125_RD_DQS,
.datawdsratio0 = MT41J128MJT125_WR_DQS,
@@ -198,6 +208,7 @@ static struct emif_regs ddr3_beagleblack_emif_reg_data = {
.sdram_tim1 = MT41K256M16HA125E_EMIF_TIM1,
.sdram_tim2 = MT41K256M16HA125E_EMIF_TIM2,
.sdram_tim3 = MT41K256M16HA125E_EMIF_TIM3,
+   .ocp_config = EMIF_OCP_CONFIG_BEAGLEBONE_BLACK,
.zq_config = MT41K256M16HA125E_ZQ_CFG,
.emif_ddr_phy_ctlr_1 = MT41K256M16HA125E_EMIF_READ_LATENCY,
 };
@@ -208,6 +219,7 @@ static struct emif_regs ddr3_evm_emif_reg_data = {
.sdram_tim1 = MT41J512M8RH125_EMIF_TIM1,
.sdram_tim2 = MT41J512M8RH125_EMIF_TIM2,
.sdram_tim3 = MT41J512M8RH125_EMIF_TIM3,
+   .ocp_config = EMIF_OCP_CONFIG_AM335X_EVM,
.zq_config = MT41J512M8RH125_ZQ_CFG,
.emif_ddr_phy_ctlr_1 = MT41J512M8RH125_EMIF_READ_LATENCY |
PHY_EN_DYN_PWRDN,
@@ -486,6 +498,9 @@ void sdram_init(void)
config_ddr(400, _evmsk, _icev2_data,
   _icev2_cmd_ctrl_data, _icev2_emif_reg_data,
   0);
+   else if (board_is_gp_evm())
+   config_ddr(266, , _data,
+  _cmd_ctrl_data, _evm_emif_reg_data, 0);
else
config_ddr(266, , _data,
   _cmd_ctrl_data, _emif_reg_data, 0);
diff --git a/board/ti/am335x/board.h b/board/ti/am335x/board.h
index 9776df7..48c139a 100644
--- a/board/ti/am335x/board.h
+++ b/board/ti/am335x/board.h
@@ -11,6 +11,19 @@
 #ifndef _BOARD_H_
 #define _BOARD_H_
 
+/**
+ * AM335X (EMIF_4D) EMIF REG_COS_COUNT_1, REG_COS_COUNT_2, and
+ * REG_PR_OLD_COUNT values to avoid LCDC DMA FIFO underflows and Frame
+ * Synchronization Lost errors. The values are the biggest that work
+ * reliably with offered video modes and the memory subsystem on the
+ * boards. These register have are briefly documented in "7.3.3.5.2
+ * Command Starvation" 

[U-Boot] [PATCH 1/5] net: phy: Fix mask so that we can identify Marvell 88E1518

[Phil Edworthy]

The mask for the 88E1510 meant that the 88E1518 code would never be
used.

Signed-off-by: Phil Edworthy 
---
Note: This has only been tested on a board that uses a Marvell 88E1512
PHY, see subsequent patches.
---
 drivers/net/phy/marvell.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 4eeb0f6..06029c0 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -553,7 +553,7 @@ static struct phy_driver M88E1149S_driver = {
 static struct phy_driver M88E1510_driver = {
.name = "Marvell 88E1510",
.uid = 0x1410dd0,
-   .mask = 0xff0,
+   .mask = 0xfff,
.features = PHY_GBIT_FEATURES,
.config = _config,
.startup = _startup,
@@ -563,7 +563,7 @@ static struct phy_driver M88E1510_driver = {
 static struct phy_driver M88E1518_driver = {
.name = "Marvell 88E1518",
.uid = 0x1410dd1,
-   .mask = 0xff0,
+   .mask = 0xfff,
.features = PHY_GBIT_FEATURES,
.config = _config,
.startup = _startup,
-- 
2.7.4

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

[U-Boot] [PATCH 0/5] net: phy: Add Marvell M88E1512

[Phil Edworthy]

These patches add support for the Marvell M88E1512 PHY.

Phil Edworthy (5):
  net: phy: Fix mask so that we can identify Marvell 88E1518
  net: phy: Add support for Marvell M88E1512
  net: phy: Marvell 88E151x: Add support for RGMII
  net: phy: Marvell 88E151x: Increase delay after init
  net: phy: Marvell: Use phy_interface_is_rgmii helper function

 drivers/net/phy/marvell.c | 36 +---
 1 file changed, 25 insertions(+), 11 deletions(-)

-- 
2.7.4

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

Re: [U-Boot] [PATCH] bootm: relocate ramdisk if CONFIG_SYS_BOOT_RAMDISK_HIGH set

[Cédric Le Goater]

On 12/08/2016 07:51 PM, Rick Altherr wrote:
> In 35fc84f, bootm was refactored so plain 'bootm' and
> 'bootm ' shared a common implementation.
> The 'bootm ramdisk' command implementation is now part of the common
> implementation but not invoke by plain 'bootm' since the original
> implementation never did ramdisk relocation.  Instead, ramdisk
> relocation happened in image_setup_linux() which is typically called
> during the OS portion of 'bootm'.
> 
> On ARM, parameters to the Linux kernel can either be passed by FDT or
> ATAGS. When using FDT, image_setup_linux() is called which also triggers
> ramdisk relocation.  When using ATAGS, image_setup_linux() is _not_
> called because it mostly does FDT setup.
> 
> Instead of calling image_setup_linux() in both FDT and ATAGS cases,
> include BOOTM_STATE_RAMDISK in the requested states during a plain
> 'bootm' if CONFIG_SYS_BOOT_RAMDISK_HIGH is set and remove the ramdisk
> relocation from image_setup_linux().  This causes ramdisk relocation to
> happen on any system where CONFIG_SYS_BOOT_RAMDISK_HIGH regardless of
> the OS being booted. Also remove IMAGE_ENABLE_RAMDISK_HIGH as it was
> only used by the now-removed code from image_setup_linux().
> 
> Signed-off-by: Rick Altherr 
> Reviewed-by: Simon Glass 
> Reviewed-by: Joel Stanley 


Reviewed-by: Cédric Le Goater 

and I gave it a good test on various boards we have.

Thanks,

C.

> ---
> 
>  cmd/bootm.c |  3 +++
>  common/image.c  | 10 --
>  include/image.h |  6 --
>  3 files changed, 3 insertions(+), 16 deletions(-)
> 
> diff --git a/cmd/bootm.c b/cmd/bootm.c
> index 083f3d1..a7e181d 100644
> --- a/cmd/bootm.c
> +++ b/cmd/bootm.c
> @@ -126,6 +126,9 @@ int do_bootm(cmd_tbl_t *cmdtp, int flag, int argc, char * 
> const argv[])
>   return do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START |
>   BOOTM_STATE_FINDOS | BOOTM_STATE_FINDOTHER |
>   BOOTM_STATE_LOADOS |
> +#ifdef CONFIG_SYS_BOOT_RAMDISK_HIGH
> + BOOTM_STATE_RAMDISK |
> +#endif
>  #if defined(CONFIG_PPC) || defined(CONFIG_MIPS)
>   BOOTM_STATE_OS_CMDLINE |
>  #endif
> diff --git a/common/image.c b/common/image.c
> index bd07e86..b4a6839 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -1571,10 +1571,7 @@ int image_setup_linux(bootm_headers_t *images)
>  {
>   ulong of_size = images->ft_len;
>   char **of_flat_tree = >ft_addr;
> - ulong *initrd_start = >initrd_start;
> - ulong *initrd_end = >initrd_end;
>   struct lmb *lmb = >lmb;
> - ulong rd_len;
>   int ret;
>  
>   if (IMAGE_ENABLE_OF_LIBFDT)
> @@ -1588,13 +1585,6 @@ int image_setup_linux(bootm_headers_t *images)
>   return ret;
>   }
>   }
> - if (IMAGE_ENABLE_RAMDISK_HIGH) {
> - rd_len = images->rd_end - images->rd_start;
> - ret = boot_ramdisk_high(lmb, images->rd_start, rd_len,
> - initrd_start, initrd_end);
> - if (ret)
> - return ret;
> - }
>  
>   if (IMAGE_ENABLE_OF_LIBFDT) {
>   ret = boot_relocate_fdt(lmb, of_flat_tree, _size);
> diff --git a/include/image.h b/include/image.h
> index 575f592..4c39bd7 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -99,12 +99,6 @@ struct lmb;
>  
>  #endif /* IMAGE_ENABLE_FIT */
>  
> -#ifdef CONFIG_SYS_BOOT_RAMDISK_HIGH
> -# define IMAGE_ENABLE_RAMDISK_HIGH   1
> -#else
> -# define IMAGE_ENABLE_RAMDISK_HIGH   0
> -#endif
> -
>  #ifdef CONFIG_SYS_BOOT_GET_CMDLINE
>  # define IMAGE_BOOT_GET_CMDLINE  1
>  #else
> 

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

Re: [U-Boot] [PATCH v6 1/2] armv8/fsl-layerscape: fdt: fixup LS1043A rev1 GIC node

[Wenbin Song]

Hi, york

Because the other patch [patch v6 2/2 ] in this set depends on the format of  
MSI  node  which is not yet ready to upstream. 
I planed  to send them together. 

Do you have any idea?


Best Regards
Wenbin Song

> -Original Message-
> From: york sun
> Sent: Friday, December 09, 2016 3:07 AM
> To: Wenbin Song ; albert.u.b...@aribaud.net;
> Mingkai Hu ; u-boot@lists.denx.de
> Subject: Re: [PATCH v6 1/2] armv8/fsl-layerscape: fdt: fixup LS1043A rev1 GIC
> node
> 
> On 11/16/2016 05:14 PM, Wenbin Song wrote:
> > []  ok, I will make this change  in the next version of the patch.
> >
> 
> Wenbin,
> 
> Have you sent an update for this set?
> 
> York

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

Re: [U-Boot] [PATCH 06/10] arm: socfpga: arria10: Added drivers for Arria10 Reset Manager

[Chee, Tien Fong]

On Rab, 2016-12-07 at 14:58 +0100, Marek Vasut wrote:
> On 12/07/2016 12:58 PM, Chee, Tien Fong wrote:
> > 
> > On Sel, 2016-12-06 at 13:55 +0100, Marek Vasut wrote:
> > > 
> > > On 12/06/2016 09:08 AM, Chee Tien Fong wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > Drivers for reset manager is restructured such that common
> > > > functions,
> > > > gen5 drivers and Arria10 drivers are moved to reset_manager.c,
> > > > reset_manager_gen5.c and reset_manager_arria10.c respectively.
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > Cc: Marek Vasut 
> > > > Cc: Dinh Nguyen 
> > > > Cc: Chin Liang See 
> > > > Cc: Tien Fong 
> [...]
> 
> > 
> > > 
> > > > 
> > > > +void reset_deassert_dedicated_peripherals(void)
> > > > +{
> > > > +   int i;
> > > > +   u32 mask0 = 0;
> > > > +   u32 mask1 = 0;
> > > > +   u32 pinmux_addr = SOCFPGA_PINMUX_DEDICATED_IO_ADDRESS;
> > > > +   u32 mask = 0;
> > > > +#if defined(CONFIG_MMC)
> > > > +   mask |= ALT_RSTMGR_PER0MODRST_SDMMCECC_SET_MSK;
> > > > +#elif defined(CONFIG_CADENCE_QSPI)
> > > > +   mask |= ALT_RSTMGR_PER0MODRST_QSPIECC_SET_MSK;
> > > > +#elif defined(CONFIG_NAND_DENALI)
> > > > +   mask |= ALT_RSTMGR_PER0MODRST_NANDECC_SET_MSK;
> > > > +#else
> > > Shouldn't this come from OF instead of being ifdef'd ?
> > > 
> > What is OF?
> Device Tree (Open Firmware).
> 
> > 
> > what is your suggestion to make this function generic for
> > all type of flash?
> Pull it from OF ?
> 
Why you prefer device tree implementation over #define in defconfig,
because there is performance penalty.
> > 
> > > 
> > > > 
> > > > +#error "unsupported dedicated peripherals"
> > > > +#endif
> > > > +   mask |= ALT_RSTMGR_PER0MODRST_DMAECC_SET_MSK;
> > > > +
> > > > +   /* enable ECC OCP first */
> > > > +   clrbits_le32(_manager_base->per0modrst, mask);
> > > [...]
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 05/10] arm: socfpga: arria10: Added support for Arria 10 SoC dev kit

[Chee, Tien Fong]

On Rab, 2016-12-07 at 14:57 +0100, Marek Vasut wrote:
> On 12/07/2016 12:21 PM, Chee, Tien Fong wrote:
> > 
> > On Sel, 2016-12-06 at 13:51 +0100, Marek Vasut wrote:
> > > 
> > > On 12/06/2016 09:07 AM, Chee Tien Fong wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > Cc: Marek Vasut 
> > > > Cc: Dinh Nguyen 
> > > > Cc: Chin Liang See 
> > > > Cc: Tien Fong 
> > > > ---
> > > >  arch/arm/mach-socfpga/include/mach/base_addr_a10.h |   11 +-
> > > >  arch/arm/mach-socfpga/system_manager.c |4 +-
> > > >  drivers/fpga/socfpga.c |7 +-
> > > >  include/configs/socfpga_arria10_socdk.h|  152
> > > > +--
> > > >  4 files changed, 151 insertions(+), 23 deletions(-)
> > > > 
> > > > diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_a10.h
> > > > b/arch/arm/mach-socfpga/include/mach/base_addr_a10.h
> > > > index 902c321..487a5dc 100644
> > > > --- a/arch/arm/mach-socfpga/include/mach/base_addr_a10.h
> > > > +++ b/arch/arm/mach-socfpga/include/mach/base_addr_a10.h
> > > > @@ -1,7 +1,7 @@
> > > >  /*
> > > > - * Copyright (C) 2014 Altera Corporation 
> > > > + * Copyright (C) 2014-2016 Altera Corporation 
> > > >   *
> > > > - * SPDX-License-Identifier:GPL-2.0+
> > > > + * SPDX-License-Identifier:GPL-2.0
> > > Can you change license this way ?
> > > 
> > Okay, i will revert this change. I discussed with Chin Liang today,
> > and
> > we decided to let owner to make the changes. How about the year
> > change
> > 2014-2016?
> To change a license of a file, you need to get an ACK from every
> single
> contributor to that file.
> 
> Year change I believe is fine.
> 
> [...]
> 
Okay, noted.
> > 
> > > 
> > > > 
> > > > @@ -89,6 +120,95 @@
> > > >     " root=${qspiroot} rw
> > > > rootfstype=${qspirootfstype};"\
> > > >     "bootm ${loadaddr} - ${fdt_addr}\0"
> > > >  
> > > > -/* The rest of the configuration is shared */
> > > > -#include 
> > > > +/*
> > > > + * External memory configurations
> > > > + */
> > > Why is this being duplicated in board support code when it
> > > previously
> > > was in common code ? That's just wrong.
> > > 
> > I found that many conflicts between the board support code and
> > common
> > code. It is safe for Arria10 having its own setting here. What do
> > you
> > think?
> It looks like 95% of the stuff below is the same as the stuff in
> socfpga-common.h , the rest can be pulled from DT or ifdef'd .
> 
If socfpga-common.h is preferred, then i have to use ifdef method, are
you ok with this? However, this would look a bit messy, because some
#define setting in here, and other #define setting in socfpga-common.h
under same category or peripheral configuration group.
> > 
> > > 
> > > > 
> > > > +#define PHYS_SDRAM_1   0x0
> > > > +#define PHYS_SDRAM_1_SIZE  0x8000
> > > > +#define CONFIG_SYS_SDRAM_BASE  0
> > > > +#define CONFIG_NR_DRAM_BANKS   1
> > > > +#define CONFIG_SYS_MEMTEST_START   0
> > > > +#define CONFIG_SYS_MEMTEST_END 0x10
> > > > +
> > > > +/*
> > > > + * Serial / UART configurations
> > > > + */
> > > > +#define CONFIG_SYS_NS16550_SERIAL
> > > > +#define CONFIG_SYS_NS16550_MEM32
> > > > +#define CONFIG_SYS_NS16550_REG_SIZE-4
> > > > +#define CONFIG_SYS_NS16550_COM1SOCFPGA_UART1_ADDRESS
> > > > +#define CONFIG_SYS_BAUDRATE_TABLE {4800, 9600, 19200, 38400,
> > > > 57600, 115200}
> > > > +#define CONFIG_SYS_NS16550_CLK (5000)
> > > > +#define CONFIG_CONS_INDEX  1
> > > > +#define CONFIG_BAUDRATE115200
> > > > +
> > > > +/*
> > > > + * L4 OSC1 Timer 0
> > > > + */
> > > > +/* This timer use eosc1 where the clock frequency is fixed
> > > > + * throughout any condition */
> > > > +#define CONFIG_SYS_TIMERBASE   SOCFPGA_SYSTIMER0_
> > > > ADDR
> > > > ESS
> > > > +/* address of timer counter value */
> > > > +#define CONFIG_SYS_TIMER_COUNTER   (CONFIG_SYS_TIMERBASE
> > > > +
> > > > 0x4)
> > > > +/* reload value when timer count to zero */
> > > > +#define TIMER_LOAD_VAL 0x
> > > > +/* Clocks source frequency to timer */
> > > > +#define CONFIG_SYS_TIMER_RATE  (2500)
> > > > +
> > > > +/* DesignWare timer is a countdown timer */
> > > > +#define CONFIG_SYS_TIMER_COUNTS_DOWN
> > > > +
> > > > +/*
> > > > + * L4 Watchdog configurations
> > > > + */
> > > > +#ifdef CONFIG_HW_WATCHDOG
> > > > +#define CONFIG_DESIGNWARE_WATCHDOG
> > > > +#define CONFIG_DW_WDT_BASE SOCFPGA_L4WD0_ADDRES
> > > > S
> > > > +#define CONFIG_HPS_CLK_OSC1_HZ 2500
> > > > +#define CONFIG_DW_WDT_CLOCK_KHZ(CONFIG_HPS_CLK
> > > > _OSC
> > > > 1_HZ / 1000)
> > > > +#define CONFIG_HW_WATCHDOG_TIMEOUT_MS  (2000)
> > > > 

Re: [U-Boot] [PATCH 02/10] arm: socfpga: arria10: Added config option build for SPL

[Chee, Tien Fong]

On Rab, 2016-12-07 at 14:54 +0100, Marek Vasut wrote:
> On 12/07/2016 11:57 AM, Chee, Tien Fong wrote:
> > 
> > On Sel, 2016-12-06 at 13:47 +0100, Marek Vasut wrote:
> > > 
> > > On 12/06/2016 08:52 AM, Chee Tien Fong wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > These changes to ensure Arria10 SPL build success.
> > > Please reword the commit message, mention you're removing the
> > > Arria10
> > > bits. Still, this does not even apply on mainline, on top of what
> > > does
> > > this apply ?
> > > 
> > I disabled some features temporary, so SPL build can pass and print
> > out
> > working. I will enable these features back in upcoming patches.
> > This is
> > base on 01-arria10 branch.
> But this patch seems to only enable stuff ... ?
> 
Enable the spl. Disable SPI flash temporary, for preventing build
failed, but this will be enabled back with upcoming patches for
supporting SPI flash.
> > 
> > > 
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > Cc: Marek Vasut 
> > > > Cc: Dinh Nguyen 
> > > > Cc: Chin Liang See 
> > > > Cc: Tien Fong 
> > > > ---
> > > >  arch/arm/Kconfig |8 
> > > >  1 files changed, 4 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > > index 220bb19..05ce8b8 100644
> > > > --- a/arch/arm/Kconfig
> > > > +++ b/arch/arm/Kconfig
> > > > @@ -622,12 +622,12 @@ config ARCH_SNAPDRAGON
> > > >  config ARCH_SOCFPGA
> > > >     bool "Altera SOCFPGA family"
> > > >     select CPU_V7
> > > > -   select SUPPORT_SPL if !TARGET_SOCFPGA_ARRIA10
> > > > +   select SUPPORT_SPL
> > > >     select OF_CONTROL
> > > > -   select SPL_OF_CONTROL if !TARGET_SOCFPGA_ARRIA10
> > > > +   select SPL_OF_CONTROL
> > > >     select DM
> > > > -   select DM_SPI_FLASH
> > > > -   select DM_SPI
> > > > +   select DM_SPI_FLASH if !TARGET_SOCFPGA_ARRIA10
> > > > +   select DM_SPI if !TARGET_SOCFPGA_ARRIA10
> > > >  
> > > >  config TARGET_CM_T43
> > > >     bool "Support cm_t43"
> > > > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] Adding MSCC PHY-VSC8530-VSC8531-VSC8540-VSC8541

[Alexey Brodkin]

Hi Joe,

> -Original Message-
> From: Joe Hershberger [mailto:joe.hershber...@gmail.com]
> Sent: Thursday, December 08, 2016 8:05 PM
> To: Alexey Brodkin 
> Cc: john.haech...@microsemi.com; u-boot@lists.denx.de; joe.hershber...@ni.com
> Subject: Re: [U-Boot] [PATCH 1/1] Adding MSCC 
> PHY-VSC8530-VSC8531-VSC8540-VSC8541
> 
> Hi Alexey,
> 
> Thanks for the review. I agree with most of your comments, but I'll
> note where I don't.
> 
> On Thu, Dec 8, 2016 at 6:24 AM, Alexey Brodkin
>  wrote:
> 
> ...
> 
> >> +static int mscc_vsc8531_vsc8541_init_scripts(struct phy_device *phydev)
> >> +{
> >> + u16 reg_val17;
> >> + u16 reg_val18;
> >
> > Any reason to keep variables in different lines?
> 
> I think separate lines is cleaner and prefer it stay this way.

Well especially here IMHO there's no need to separate 2 temporary vars.
Still it's more a matter of your taste/preference.
Moreover I'm not really asking to do that change but wondering about reasons
and with good explanation I'm fine with it as it is.

> >> +
> >> + /* Set to Access Token Ring Registers */
> >> + phy_write(phydev, MDIO_DEVAD_NONE,
> >> + MSCC_EXT_PAGE_ACCESS, MSCC_PHY_PAGE_TR);
> >> +
> >> + /* Update LinkDetectCtrl default to optimized values */
> >> + /* Determined during Silicon Validation Testing */
> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_REG_TR_ADDR_16, 0xA7F8);
> >
> > Cryptic values are not very nice to deal with. I'd advise you to use 
> > defines here.
> > Moreover I'm wondering:
> >  a) why all this complicated setup is required?
> >  b) is it mentioned in any datasheet? If it is mentioned it worth adding a 
> > comment
> > about source of those figures and explanation of the procedure itself.
> > This will help mere mortals to figure out what is done here and if 
> > required people will
> > use that knowledge as a reference in other projects.
> >
> >> + reg_val17 = phy_read(phydev, MDIO_DEVAD_NONE, 
> >> MSCC_PHY_REG_TR_DATA_17);
> >> + reg_val17 = bitfield_replace(reg_val17, MSCC_PHY_TR_LINKDETCTRL_POS,
> >> +MSCC_PHY_TR_LINKDETCTRL_WIDTH, 3);
> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_REG_TR_DATA_17, 
> >> reg_val17);
> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_REG_TR_ADDR_16, 0x87F8);
> >> +
> >> + /* Update VgaThresh100 defaults to optimized values */
> >> + /* Determined during Silicon Validation Testing */
> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_REG_TR_ADDR_16, 0xAFA4);
> >> + reg_val18 = phy_read(phydev, MDIO_DEVAD_NONE, 
> >> MSCC_PHY_REG_TR_DATA_18);
> >> + reg_val18 = bitfield_replace(reg_val18, MSCC_PHY_TR_VGATHRESH100_POS,
> >> +MSCC_PHY_TR_VGATHRESH100_WIDTH, 24);
> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_REG_TR_DATA_18, 
> >> reg_val18);
> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_REG_TR_ADDR_16, 0x8FA4);
> >> +
> >> + /* Update VgaGain10 defaults to optimized values */
> >> + /* Determined during Silicon Validation Testing */
> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_REG_TR_ADDR_16, 0xAF92);
> >> + reg_val18 = phy_read(phydev, MDIO_DEVAD_NONE, 
> >> MSCC_PHY_REG_TR_DATA_18);
> >> + reg_val17 = phy_read(phydev, MDIO_DEVAD_NONE, 
> >> MSCC_PHY_REG_TR_DATA_17);
> >> + reg_val18 = bitfield_replace(reg_val18, MSCC_PHY_TR_VGAGAIN10_U_POS,
> >> +MSCC_PHY_TR_VGAGAIN10_U_WIDTH, 0);
> >> +
> >> + reg_val17 = bitfield_replace(reg_val17, MSCC_PHY_TR_VGAGAIN10_L_POS,
> >> +MSCC_PHY_TR_VGAGAIN10_L_WIDTH, 1);
> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_REG_TR_DATA_18, 
> >> reg_val18);
> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_REG_TR_DATA_17, 
> >> reg_val17);
> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_REG_TR_ADDR_16, 0x8F92);
> >> +
> >> + /* Set back to Access Standard Page Registers */
> >> + phy_write(phydev, MDIO_DEVAD_NONE, MSCC_EXT_PAGE_ACCESS,
> >> + MSCC_PHY_PAGE_STD);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static int mscc_parse_status(struct phy_device *phydev)
> >> +{
> >> + u16 speed;
> >> + u16 mii_reg;
> >> +
> >> + mii_reg = phy_read(phydev, MDIO_DEVAD_NONE, MIIM_AUX_CNTRL_STAT_REG);
> >
> > u16 speed, mii_reg = phy_read(phydev, MDIO_DEVAD_NONE, 
> > MIIM_AUX_CNTRL_STAT_REG);
> 
> This is especially ugly. It looks more like a python function
> returning a tuple than clean C code. Please do not do this.

Again just an example of how I would do that.
But I may agree that it may look a bit ugly :)

Anyways thanks for your input.

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

[U-Boot] [PATCH 5/5] ls1046ardb: Add support power initialization

[Zhiqiang Hou]

From: Hou Zhiqiang 

Add the chip power supply voltage initialization on LS1046ARDB.
Add function power_init_board(), and it will initialize the
PMIC and call the chip power initialization function.

Signed-off-by: Hou Zhiqiang 
---
 arch/arm/Kconfig|  1 +
 board/freescale/ls1046ardb/ls1046ardb.c | 34 +
 include/configs/ls1046ardb.h|  6 ++
 3 files changed, 41 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 49bc9d8..62c0fd5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -819,6 +819,7 @@ config TARGET_LS1046ARDB
select ARMV8_MULTIENTRY
select SUPPORT_SPL
select DM_SPI_FLASH if DM_SPI
+   select POWER_MC34VR500
help
  Support for Freescale LS1046ARDB platform.
  The LS1046A Reference Design Board (RDB) is a high-performance
diff --git a/board/freescale/ls1046ardb/ls1046ardb.c 
b/board/freescale/ls1046ardb/ls1046ardb.c
index 585c807..33a58cf 100644
--- a/board/freescale/ls1046ardb/ls1046ardb.c
+++ b/board/freescale/ls1046ardb/ls1046ardb.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "cpld.h"
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -87,6 +88,39 @@ int board_init(void)
return 0;
 }
 
+int board_setup_core_volt(u32 vdd)
+{
+   bool en_0v9;
+
+   en_0v9 = (vdd == 900) ? true : false;
+   cpld_select_core_volt(en_0v9);
+
+   return 0;
+}
+
+int get_serdes_volt(void)
+{
+   return mc34vr500_get_sw_volt(SW4);
+}
+
+int set_serdes_volt(int svdd)
+{
+   return mc34vr500_set_sw_volt(SW4, svdd);
+}
+
+int power_init_board(void)
+{
+   int ret;
+
+   ret = power_mc34vr500_init(0);
+   if (ret)
+   return ret;
+
+   setup_chip_volt();
+
+   return 0;
+}
+
 void config_board_mux(void)
 {
 #ifdef CONFIG_HAS_FSL_XHCI_USB
diff --git a/include/configs/ls1046ardb.h b/include/configs/ls1046ardb.h
index 2fe8fc1..d16736f 100644
--- a/include/configs/ls1046ardb.h
+++ b/include/configs/ls1046ardb.h
@@ -164,6 +164,12 @@
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS  5
 #define I2C_RETIMER_ADDR   0x18
 
+/* PMIC */
+#define CONFIG_POWER
+#ifdef CONFIG_POWER
+#define CONFIG_POWER_I2C
+#endif
+
 /*
  * Environment
  */
-- 
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 4/5] armv8/fsl_lsch2: Add chip power supply voltage setup

[Zhiqiang Hou]

From: Hou Zhiqiang 

Set up chip power supply voltage according to voltage ID.
The fuse status register provides the values from on-chip
voltage ID fuses programmed at the factory. These values
define the voltage requirements for the chip.

Main operations:
1. Set up the core voltage
2. Set up the SERDES voltage and reset SERDES lanes
3. Enable/disable DDR controller support 0.9V if needed

Signed-off-by: Hou Zhiqiang 
---
 .../cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c| 272 +
 arch/arm/cpu/armv8/fsl-layerscape/soc.c|  89 +++
 .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |   8 +
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |   3 +
 include/fsl_ddr_sdram.h|   1 +
 5 files changed, 373 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c
index e06b063..c0b4d0a 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c
@@ -129,6 +129,278 @@ void serdes_init(u32 sd, u32 sd_addr, u32 sd_prctl_mask, 
u32 sd_prctl_shift,
serdes_prtcl_map[NONE] = 1;
 }
 
+__weak int get_serdes_volt(void)
+{
+   return -1;
+}
+
+__weak int set_serdes_volt(int svdd)
+{
+   return -1;
+}
+
+int setup_serdes_volt(u32 svdd)
+{
+   struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
+   struct ccsr_serdes *serdes1_base;
+#ifdef CONFIG_SYS_FSL_SRDS_2
+   struct ccsr_serdes *serdes2_base;
+#endif
+   u32 cfg_rcw4 = gur_in32(>rcwsr[4]);
+   u32 cfg_rcw5 = gur_in32(>rcwsr[5]);
+   u32 cfg_tmp, reg = 0;
+   int svdd_cur, svdd_tar;
+   int ret;
+   int i;
+
+   /* Only support switch SVDD to 900mV/1000mV */
+   if (svdd != 900 && svdd != 1000)
+   return -EINVAL;
+
+   svdd_tar = svdd;
+   svdd_cur = get_serdes_volt();
+   if (svdd_cur < 0)
+   return -EINVAL;
+
+   debug("%s: current SVDD: %dmV; target SVDD: %dmV\n",
+ __func__, svdd_cur, svdd_tar);
+   if (svdd_cur == svdd_tar)
+   return 0;
+
+   serdes1_base = (void *)CONFIG_SYS_FSL_SERDES_ADDR;
+#ifdef CONFIG_SYS_FSL_SRDS_2
+   serdes2_base = (void *)serdes1_base + 0x1;
+#endif
+
+   /* Put the all enabled lanes in reset */
+#ifdef CONFIG_SYS_FSL_SRDS_1
+   cfg_tmp = cfg_rcw4 & FSL_CHASSIS2_RCWSR4_SRDS1_PRTCL_MASK;
+   cfg_tmp >>= FSL_CHASSIS2_RCWSR4_SRDS1_PRTCL_SHIFT;
+
+   for (i = 0; i < 4 && cfg_tmp & (0xf << (3 - i)); i++) {
+   reg = in_be32(_base->lane[i].gcr0);
+   reg &= 0xFF9F;
+   out_be32(_base->lane[i].gcr0, reg);
+   }
+#endif
+#ifdef CONFIG_SYS_FSL_SRDS_2
+   cfg_tmp = cfg_rcw4 & FSL_CHASSIS2_RCWSR4_SRDS2_PRTCL_MASK;
+   cfg_tmp >>= FSL_CHASSIS2_RCWSR4_SRDS2_PRTCL_SHIFT;
+
+   for (i = 0; i < 4 && cfg_tmp & (0xf << (3 - i)); i++) {
+   reg = in_be32(_base->lane[i].gcr0);
+   reg &= 0xFF9F;
+   out_be32(_base->lane[i].gcr0, reg);
+   }
+#endif
+
+   /* Put the all enabled PLL in reset */
+#ifdef CONFIG_SYS_FSL_SRDS_1
+   cfg_tmp = (cfg_rcw5 >> 22) & 0x3;
+   for (i = 0; i < 2 && !(cfg_tmp & (0x1 << (1 - i))); i++) {
+   reg = in_be32(_base->bank[i].rstctl);
+   reg &= 0xFFBF;
+   reg |= 0x1000;
+   out_be32(_base->bank[i].rstctl, reg);
+   udelay(1);
+
+   reg = in_be32(_base->bank[i].rstctl);
+   reg &= 0xFF1F;
+   out_be32(_base->bank[i].rstctl, reg);
+   }
+   udelay(1);
+#endif
+
+#ifdef CONFIG_SYS_FSL_SRDS_2
+   cfg_tmp = (cfg_rcw5 >> 20) & 0x3;
+   for (i = 0; i < 2 && !(cfg_tmp & (0x1 << (1 - i))); i++) {
+   reg = in_be32(_base->bank[i].rstctl);
+   reg &= 0xFFBF;
+   reg |= 0x1000;
+   out_be32(_base->bank[i].rstctl, reg);
+   udelay(1);
+
+   reg = in_be32(_base->bank[i].rstctl);
+   reg &= 0xFF1F;
+   out_be32(_base->bank[i].rstctl, reg);
+   }
+   udelay(1);
+#endif
+
+   /* Put the Rx/Tx calibration into reset */
+#ifdef CONFIG_SYS_FSL_SRDS_1
+   reg = in_be32(_base->srdstcalcr);
+   reg &= 0xF7FF;
+   out_be32(_base->srdstcalcr, reg);
+   reg = in_be32(_base->srdsrcalcr);
+   reg &= 0xF7FF;
+   out_be32(_base->srdsrcalcr, reg);
+
+#endif
+#ifdef CONFIG_SYS_FSL_SRDS_2
+   reg = in_be32(_base->srdstcalcr);
+   reg &= 0xF7FF;
+   out_be32(_base->srdstcalcr, reg);
+   reg = in_be32(_base->srdsrcalcr);
+   reg &= 0xF7FF;
+   out_be32(_base->srdsrcalcr, reg);
+#endif
+
+   /*
+* If SVDD set failed, will not return directly, so that the
+* serdes lanes can complete reseting.
+*/
+   

[U-Boot] [PATCH 3/5] ls1046ardb: cpld: add API for selecting core volt

[Zhiqiang Hou]

From: Hou Zhiqiang 

Signed-off-by: Hou Zhiqiang 
---
 board/freescale/ls1046ardb/cpld.c | 9 +
 board/freescale/ls1046ardb/cpld.h | 1 +
 2 files changed, 10 insertions(+)

diff --git a/board/freescale/ls1046ardb/cpld.c 
b/board/freescale/ls1046ardb/cpld.c
index 81a646e..c0500f4 100644
--- a/board/freescale/ls1046ardb/cpld.c
+++ b/board/freescale/ls1046ardb/cpld.c
@@ -82,6 +82,15 @@ void cpld_set_sd(void)
 
CPLD_WRITE(system_rst, 1);
 }
+
+void cpld_select_core_volt(bool en_0v9)
+{
+   u8 reg17 = en_0v9;
+
+   CPLD_WRITE(vdd_en, 1);
+   CPLD_WRITE(vdd_sel, reg17);
+}
+
 #ifdef DEBUG
 static void cpld_dump_regs(void)
 {
diff --git a/board/freescale/ls1046ardb/cpld.h 
b/board/freescale/ls1046ardb/cpld.h
index 458da7e..f6a1a61 100644
--- a/board/freescale/ls1046ardb/cpld.h
+++ b/board/freescale/ls1046ardb/cpld.h
@@ -35,6 +35,7 @@ struct cpld_data {
 u8 cpld_read(unsigned int reg);
 void cpld_write(unsigned int reg, u8 value);
 void cpld_rev_bit(unsigned char *value);
+void cpld_select_core_volt(bool en_0v9);
 
 #define CPLD_READ(reg) cpld_read(offsetof(struct cpld_data, reg))
 #define CPLD_WRITE(reg, value)  \
-- 
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/5] pmic: pmic_mc34vr500: Add a driver for the mc34vr500 pmic

[Zhiqiang Hou]

From: Hou Zhiqiang 

This patch adds a simple pmic driver for the mc34vr500 pmic which
is used in conjunction with the fsl T1 and LS1 series SoC.

Signed-off-by: Hou Zhiqiang 
---
 drivers/power/pmic/Kconfig  |   7 ++
 drivers/power/pmic/Makefile |   1 +
 drivers/power/pmic/pmic_mc34vr500.c |  32 +++
 include/power/mc34vr500_pmic.h  | 166 
 4 files changed, 206 insertions(+)
 create mode 100644 drivers/power/pmic/pmic_mc34vr500.c
 create mode 100644 include/power/mc34vr500_pmic.h

diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
index ce204b3..73e1d53 100644
--- a/drivers/power/pmic/Kconfig
+++ b/drivers/power/pmic/Kconfig
@@ -157,3 +157,10 @@ config PMIC_LP873X
---help---
The LP873X is a PMIC containing couple of LDOs and couple of SMPS.
This driver binds the pmic children.
+
+config POWER_MC34VR500
+   bool "Enable driver for Freescale MC34VR500 PMIC"
+   ---help---
+   The MC34VR500 is used in conjunction with the FSL T1 and LS1 series
+   SoC. It provides 4 buck DC-DC convertors and 5 LDOs, and it is accessed
+   via an I2C interface.
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index cd1c694..58d0241 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -32,3 +32,4 @@ obj-$(CONFIG_POWER_TPS65218) += pmic_tps62362.o
 obj-$(CONFIG_POWER_TPS65218) += pmic_tps65218.o
 obj-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
 obj-$(CONFIG_POWER_HI6553) += pmic_hi6553.o
+obj-$(CONFIG_POWER_MC34VR500) += pmic_mc34vr500.o
diff --git a/drivers/power/pmic/pmic_mc34vr500.c 
b/drivers/power/pmic/pmic_mc34vr500.c
new file mode 100644
index 000..db9e210
--- /dev/null
+++ b/drivers/power/pmic/pmic_mc34vr500.c
@@ -0,0 +1,32 @@
+/*
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ * Hou Zhiqiang 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int power_mc34vr500_init(unsigned char bus)
+{
+   static const char name[] = "MC34VR500";
+   struct pmic *p = pmic_alloc();
+
+   if (!p) {
+   printf("%s: POWER allocation error!\n", __func__);
+   return -ENOMEM;
+   }
+
+   p->name = name;
+   p->interface = PMIC_I2C;
+   p->number_of_regs = MC34VR500_NUM_OF_REGS;
+   p->hw.i2c.addr = MC34VR500_I2C_ADDR;
+   p->hw.i2c.tx_num = 1;
+   p->bus = bus;
+
+   return 0;
+}
diff --git a/include/power/mc34vr500_pmic.h b/include/power/mc34vr500_pmic.h
new file mode 100644
index 000..df4985a
--- /dev/null
+++ b/include/power/mc34vr500_pmic.h
@@ -0,0 +1,166 @@
+/*
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ * Hou Zhiqiang 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __MC34VR500_H_
+#define __MC34VR500_H_
+
+#include 
+
+#define MC34VR500_I2C_ADDR 0x08
+
+/* Drivers name */
+#define MC34VR500_REGULATOR_DRIVER "mc34vr500_regulator"
+
+/* Register map */
+enum {
+   MC34VR500_DEVICEID  = 0x00,
+
+   MC34VR500_SILICONREVID  = 0x03,
+   MC34VR500_FABID,
+   MC34VR500_INTSTAT0,
+   MC34VR500_INTMASK0,
+   MC34VR500_INTSENSE0,
+   MC34VR500_INTSTAT1,
+   MC34VR500_INTMASK1,
+   MC34VR500_INTSENSE1,
+
+   MC34VR500_INTSTAT4  = 0x11,
+   MC34VR500_INTMASK4,
+   MC34VR500_INTSENSE4,
+
+   MC34VR500_PWRCTL= 0x1B,
+
+   MC34VR500_SW1VOLT   = 0x2E,
+   MC34VR500_SW1STBY,
+   MC34VR500_SW1OFF,
+   MC34VR500_SW1MODE,
+   MC34VR500_SW1CONF,
+   MC34VR500_SW2VOLT,
+   MC34VR500_SW2STBY,
+   MC34VR500_SW2OFF,
+   MC34VR500_SW2MODE,
+   MC34VR500_SW2CONF,
+
+   MC34VR500_SW3VOLT   = 0x3C,
+   MC34VR500_SW3STBY,
+   MC34VR500_SW3OFF,
+   MC34VR500_SW3MODE,
+   MC34VR500_SW3CONF,
+
+   MC34VR500_SW4VOLT   = 0x4A,
+   MC34VR500_SW4STBY,
+   MC34VR500_SW4OFF,
+   MC34VR500_SW4MODE,
+   MC34VR500_SW4CONF,
+
+   MC34VR500_REFOUTCRTRL   = 0x6A,
+
+   MC34VR500_LDO1CTL   = 0x6D,
+   MC34VR500_LDO2CTL,
+   MC34VR500_LDO3CTL,
+   MC34VR500_LDO4CTL,
+   MC34VR500_LDO5CTL,
+
+   MC34VR500_PAGE_REGISTER = 0x7F,
+
+   /* Internal RAM */
+   MC34VR500_SW1_VOLT  = 0xA8,
+   MC34VR500_SW1_SEQ,
+   MC34VR500_SW1_CONFIG,
+
+   MC34VR500_SW2_VOLT  = 0xAC,
+   MC34VR500_SW2_SEQ,
+   MC34VR500_SW2_CONFIG,
+
+   MC34VR500_SW3_VOLT  = 0xB0,
+   MC34VR500_SW3_SEQ,
+   MC34VR500_SW3_CONFIG,
+
+   MC34VR500_SW4_VOLT  = 0xB8,
+   MC34VR500_SW4_SEQ,
+   MC34VR500_SW4_CONFIG,
+
+   MC34VR500_REFOUT_SEQ= 0xC4,
+
+   MC34VR500_LDO1_VOLT = 0xCC,
+   

[U-Boot] [PATCH 2/5] pmic: pmic_mc34vr500: Add APIs to set/get SWx volt

[Zhiqiang Hou]

From: Hou Zhiqiang 

Signed-off-by: Hou Zhiqiang 
---
 board/freescale/common/Makefile|  1 +
 board/freescale/common/mc34vr500.c | 95 ++
 include/power/mc34vr500_pmic.h |  9 
 3 files changed, 105 insertions(+)
 create mode 100644 board/freescale/common/mc34vr500.c

diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile
index be114ce..eea9514 100644
--- a/board/freescale/common/Makefile
+++ b/board/freescale/common/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_VSC_CROSSBAR)+= vsc3316_3308.o
 obj-$(CONFIG_IDT8T49N222A) += idt8t49n222a_serdes_clk.o
 obj-$(CONFIG_ZM7300)   += zm7300.o
 obj-$(CONFIG_POWER_PFUZE100)   += pfuze.o
+obj-$(CONFIG_POWER_MC34VR500)  += mc34vr500.o
 
 obj-$(CONFIG_LS102XA_STREAM_ID)+= ls102xa_stream_id.o
 
diff --git a/board/freescale/common/mc34vr500.c 
b/board/freescale/common/mc34vr500.c
new file mode 100644
index 000..9c57569
--- /dev/null
+++ b/board/freescale/common/mc34vr500.c
@@ -0,0 +1,95 @@
+/*
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ * Hou Zhiqiang 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static uint8_t swxvolt_addr[4] = { MC34VR500_SW1VOLT,
+  MC34VR500_SW2VOLT,
+  MC34VR500_SW3VOLT,
+  MC34VR500_SW4VOLT };
+
+static uint8_t swx_set_point_base[4] = { 13, 9, 9, 9 };
+
+int mc34vr500_get_sw_volt(uint8_t sw)
+{
+   struct pmic *p;
+   u32 swxvolt;
+   uint8_t spb;
+   int sw_volt;
+   int ret;
+
+   debug("%s: Get SW%u volt from swxvolt_addr = 0x%x\n",
+ __func__, sw + 1, swxvolt_addr[sw]);
+   if (sw > SW4) {
+   printf("%s: Unsupported SW(sw%d)\n", __func__, sw + 1);
+   return -EINVAL;
+   }
+
+   p = pmic_get("MC34VR500");
+   if (!p) {
+   printf("%s: Did NOT find PMIC MC34VR500\n", __func__);
+   return -ENODEV;
+   }
+
+   ret = pmic_probe(p);
+   if (ret)
+   return ret;
+
+   ret = pmic_reg_read(p, swxvolt_addr[sw], );
+   if (ret) {
+   printf("%s: Failed to get SW%u volt\n", __func__, sw + 1);
+   return ret;
+   }
+
+   debug("%s: SW%d step point swxvolt = %u\n", __func__, sw + 1, swxvolt);
+   spb = swx_set_point_base[sw];
+   /* The base of SW volt is 625mV and increase by step 25mV */
+   sw_volt = 625 + (swxvolt - spb) * 25;
+
+   debug("%s: SW%u volt = %dmV\n", __func__, sw + 1, sw_volt);
+   return sw_volt;
+}
+
+int mc34vr500_set_sw_volt(uint8_t sw, int sw_volt)
+{
+   struct pmic *p;
+   u32 swxvolt;
+   uint8_t spb;
+   int ret;
+
+   debug("%s: Set SW%u volt to %dmV\n", __func__, sw + 1, sw_volt);
+   /* The least SW volt is 625mV, and only 4 SW outputs */
+   if (sw > SW4 || sw_volt < 625)
+   return -EINVAL;
+
+   p = pmic_get("MC34VR500");
+   if (!p) {
+   printf("%s: Did NOT find PMIC MC34VR500\n", __func__);
+   return -ENODEV;
+   }
+
+   ret = pmic_probe(p);
+   if (ret)
+   return ret;
+
+   spb = swx_set_point_base[sw];
+   /* The base of SW volt is 625mV and increase by step 25mV */
+   swxvolt = (sw_volt - 625) / 25 + spb;
+   debug("%s: SW%d step point swxvolt = %u\n", __func__, sw + 1, swxvolt);
+   if (swxvolt > 63)
+   return -EINVAL;
+
+   ret = pmic_reg_write(p, swxvolt_addr[sw], swxvolt);
+   if (ret)
+   return ret;
+
+   return 0;
+}
diff --git a/include/power/mc34vr500_pmic.h b/include/power/mc34vr500_pmic.h
index df4985a..b0b143a 100644
--- a/include/power/mc34vr500_pmic.h
+++ b/include/power/mc34vr500_pmic.h
@@ -162,5 +162,14 @@ enum {
 #define APS_PFM0xc
 #define PWM_PFM0xd
 
+enum swx {
+   SW1 = 0,
+   SW2,
+   SW3,
+   SW4,
+};
+
+int mc34vr500_get_sw_volt(uint8_t sw);
+int mc34vr500_set_sw_volt(uint8_t sw, int sw_volt);
 int power_mc34vr500_init(unsigned char bus);
 #endif /* __MC34VR500_PMIC_H_ */
-- 
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 v2 0/14] sunxi: Add support for the CHIP Pro

[Maxime Ripard]

On Mon, Dec 05, 2016 at 10:33:35PM +0100, Jagan Teki wrote:
> Hi Maxime,
> 
> On Sun, Dec 4, 2016 at 8:19 AM, Jagan Teki  wrote:
> > On Tue, Nov 22, 2016 at 6:08 PM, Maxime Ripard
> >  wrote:
> >> The CHIP Pro is a SoM made by NextThing Co, and that embeds a GR8 SIP, an
> >> AXP209 PMIC, a WiFi BT chip and a 512MB SLC NAND.
> >>
> >> Since the first Allwinner device coming whit an SLC NAND that doesn't have
> >> the shortcomings (and breakages) the MLC NAND has, we can finally enable
> >> the NAND support on a board by default.
> >>
> >> This is the occasion to introduce a bunch of additions needed imo to be
> >> able to come up with a sane NAND support for our users.
> >>
> >> The biggest pain point is that the BROM uses a different ECC and randomizer
> >> configuration than for the rest of the NAND. In order to lessen the number
> >> of bitflips, you also need to pad with random data the SPL image.
> >>
> >> Since it's quite tedious to do right (and most users won't be able to
> >> figure it out) and since if it is not done right, it will eventually turn
> >> into an unusable system (which is bad UX), we think that the best solution
> >> is to generate an SPL image that already embeds all this. We'll possible
> >> have to do the same thing for the U-Boot image (at least for the random
> >> padding) on MLC NANDs.
> >>
> >> The only drawback from that is that you need to flash it raw, instead of
> >> using the usual nand write, but it's just a different command, nothing
> >> major anyway.
> >>
> >> In order to flash it, from a device switched in FEL, on your host:
> >> sunxi-fel spl spl/sunxi-spl.bin
> >> sunxi-fel write 0x4a00 u-boot-dtb.bin
> >> sunxi-fel write 0x4300 spl/sunxi-spl-with-ecc.bin
> >> sunxi-fel exe 0x4a00
> >>
> >> And on the board, once u-boot is running (assuming the NAND is already
> >> erased):
> >>
> >> nand write.raw.noverify 0x4300 0 40
> >> nand write.raw.noverify 0x4300 0x40 40
> >>
> >> nand write 0x4a00 0x80 0xc
> >>
> >> I also encountered some weird bug in the private libgcc that prevents
> >> U-Boot from loading. Disabling CONFIG_USE_PRIVATE_LIBGCC fixes that.
> >>
> >> Let me know what you think,
> >> Maxime
> >>
> >> Changes from v1:
> >>   - Allowed to build lib/bch.c for the host, and used that in the image
> >> builder
> >>   - Fixed a bug in the NAND driver
> >>   - Wrote a documentation on how to flash a NAND image on an Allwinner
> >> board
> >>   - Fixed a few compilation breakages and issues
> >>   - Moved U-boot offset out of the config header and into Kconfig
> >>   - Moved the environment into UBI
> >>   - Moved the environment selection to Kconfig
> >>   - Moved the CMD_MTDPARTS options to Kconfig
> >>   - Provide MTDIDS_DEFAULT and MTDPARTS_DEFAULT options through Kconfig
> >>   - Added the tags from everyone
> >>
> >> Boris Brezillon (1):
> >>   mtd: nand: add support for the TC58NVG2S0H chip
> >
> > Will skip this, already in tree.
> >
> >>
> >> Hans de Goede (1):
> >>   sunxi: Enable UBI and NAND support
> >>
> >> Maxime Ripard (12):
> >>   nand: sunxi: Fix modulo by zero error
> >>   bch: Allow to build for the host
> >>   tools: sunxi: Add spl image builder
> >>   common: Move environment choice to Kconfig
> >>   cmd: Add Kconfig option for CMD_MTDPARTS and related options
> >>   mtd: sunxi: Select the U-Boot location config option
> >>   mtd: sunxi: Change U-Boot offset
> >>   sunxi: Add the default mtdids and mtdparts to our env
> >>   nand: sunxi: Add options for the SPL NAND configuration
> >>   scripts: sunxi: Build an raw SPL image
> >
> > Reviewed-by: Jagan Teki 
> >
> >>   sunxi: Sync GR8 DTS and AXP209 with the kerne
> >
> > Sent the review comments about this.
> >
> >>   sunxi: Add support for the CHIP Pro
> 
> Found many buildman issue with this series[1], please refer to
> master-next and let me know for if I miss any or fixes from you.
> 
> [1] https://paste.ubuntu.com/23585255/

Sorry, I haven't been able to work on this lately. Please ignore that
version for now, I will resubmit a v3 with this fixed.

Thanks!
Maxime

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


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