[U-Boot] [PATCH v2 5/5] sunxi: Enable EMAC on the Bananapi M64

2017-11-24 Thread Chen-Yu Tsai
The Bananapi M64 has an RTL8211E PHY connected to the EMAC using
RGMII. The PHY is powered by DCDC1 through SW @ 3.3V.

The EMAC driver is already enabled in the defconfig.

This patch adds a U-boot specific dtsi file for the board adding
an enabled EMAC node. The binding used here is the old revision
currently supported in U-boot. The U-boot driver has not been
updated to support the new binding.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/dts/sun50i-a64-bananapi-m64-u-boot.dtsi | 39 
 1 file changed, 39 insertions(+)
 create mode 100644 arch/arm/dts/sun50i-a64-bananapi-m64-u-boot.dtsi

diff --git a/arch/arm/dts/sun50i-a64-bananapi-m64-u-boot.dtsi 
b/arch/arm/dts/sun50i-a64-bananapi-m64-u-boot.dtsi
new file mode 100644
index ..f80a4255c0c1
--- /dev/null
+++ b/arch/arm/dts/sun50i-a64-bananapi-m64-u-boot.dtsi
@@ -0,0 +1,39 @@
+#include "sunxi-u-boot.dtsi"
+
+/ {
+   aliases {
+   ethernet0 = 
+   };
+
+   soc {
+   emac: ethernet@01c3 {
+   compatible = "allwinner,sun50i-a64-emac";
+   reg = <0x01c3 0x2000>, <0x01c00030 0x4>;
+   reg-names = "emac", "syscon";
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   phy-mode = "rgmii";
+   phy = <>;
+   status = "okay";
+
+   phy1: ethernet-phy@1 {
+   reg = <1>;
+   };
+   };
+   };
+};
+
+ {
+   rgmii_pins: rgmii_pins {
+   allwinner,pins = "PD8", "PD9", "PD10", "PD11",
+"PD12", "PD13", "PD15",
+"PD16", "PD17", "PD18", "PD19",
+"PD20", "PD21", "PD22", "PD23";
+   allwinner,function = "emac";
+   allwinner,drive = <3>;
+   allwinner,pull = <0>;
+   };
+};
-- 
2.15.0

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


[U-Boot] [PATCH v2 3/5] sunxi: Enable EMAC on the Cubietruck Plus

2017-11-24 Thread Chen-Yu Tsai
The Cubietruck Plus has an RTL8211E PHY connected to the EMAC using
RGMII. The PHY is powered by DLDO4 @ 3.3V, while the I/O pins are
powered by DLDO3 @ 2.5V.

This patch adds a U-boot specific dtsi file for the board adding
an enabled EMAC node, and enables the EMAC driver in the defconfig.
The binding used here is the old revision currently supported in
U-boot. The U-boot driver has not been updated to support the new
binding.

Signed-off-by: Chen-Yu Tsai 
---
 .../arm/dts/sun8i-a83t-cubietruck-plus-u-boot.dtsi | 38 ++
 configs/Cubietruck_plus_defconfig  |  2 ++
 2 files changed, 40 insertions(+)
 create mode 100644 arch/arm/dts/sun8i-a83t-cubietruck-plus-u-boot.dtsi

diff --git a/arch/arm/dts/sun8i-a83t-cubietruck-plus-u-boot.dtsi 
b/arch/arm/dts/sun8i-a83t-cubietruck-plus-u-boot.dtsi
new file mode 100644
index ..4637e128f76e
--- /dev/null
+++ b/arch/arm/dts/sun8i-a83t-cubietruck-plus-u-boot.dtsi
@@ -0,0 +1,38 @@
+#include "sunxi-u-boot.dtsi"
+
+/ {
+   aliases {
+   ethernet0 = 
+   };
+
+   soc {
+   emac: ethernet@01c3 {
+   compatible = "allwinner,sun8i-a83t-emac";
+   reg = <0x01c3 0x2000>, <0x01c00030 0x4>;
+   reg-names = "emac", "syscon";
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   phy-mode = "rgmii";
+   phy = <>;
+   status = "okay";
+
+   phy1: ethernet-phy@1 {
+   reg = <1>;
+   };
+   };
+   };
+};
+
+ {
+   rgmii_pins: rgmii_pins {
+   allwinner,pins = "PD2", "PD3", "PD4", "PD5", "PD6", "PD7",
+"PD11", "PD12", "PD13", "PD14", "PD18",
+"PD19", "PD21", "PD22", "PD23";
+   allwinner,function = "emac";
+   allwinner,drive = <3>;
+   allwinner,pull = <0>;
+   };
+};
diff --git a/configs/Cubietruck_plus_defconfig 
b/configs/Cubietruck_plus_defconfig
index 12120c2ceda5..77fbf91490c8 100644
--- a/configs/Cubietruck_plus_defconfig
+++ b/configs/Cubietruck_plus_defconfig
@@ -21,6 +21,8 @@ CONFIG_SPL=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_ISO_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_PHY_REALTEK=y
+CONFIG_SUN8I_EMAC=y
 CONFIG_AXP_DLDO3_VOLT=2500
 CONFIG_AXP_DLDO4_VOLT=3300
 CONFIG_AXP_FLDO1_VOLT=1200
-- 
2.15.0

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


[U-Boot] [PATCH v2 4/5] sunxi: Enable EMAC on the Bananapi M3

2017-11-24 Thread Chen-Yu Tsai
The Bananapi M3 has an RTL8211E PHY connected to the EMAC using
RGMII. The PHY is powered by DCDC1 through SW @ 3.3V.

This patch adds a U-boot specific dtsi file for the board adding
an enabled EMAC node, and enables the EMAC driver in the defconfig.
The binding used here is the old revision currently supported in
U-boot. The U-boot driver has not been updated to support the new
binding.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/dts/sun8i-a83t-bananapi-m3-u-boot.dtsi | 40 +
 configs/Sinovoip_BPI_M3_defconfig   |  2 ++
 2 files changed, 42 insertions(+)
 create mode 100644 arch/arm/dts/sun8i-a83t-bananapi-m3-u-boot.dtsi

diff --git a/arch/arm/dts/sun8i-a83t-bananapi-m3-u-boot.dtsi 
b/arch/arm/dts/sun8i-a83t-bananapi-m3-u-boot.dtsi
new file mode 100644
index ..5ac29058cc42
--- /dev/null
+++ b/arch/arm/dts/sun8i-a83t-bananapi-m3-u-boot.dtsi
@@ -0,0 +1,40 @@
+#include "sunxi-u-boot.dtsi"
+
+/ {
+   aliases {
+   ethernet0 = 
+   };
+
+   soc {
+   emac: ethernet@01c3 {
+   compatible = "allwinner,sun8i-a83t-emac";
+   reg = <0x01c3 0x2000>, <0x01c00030 0x4>;
+   reg-names = "emac", "syscon";
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   phy-mode = "rgmii";
+   phy = <>;
+   allwinner,rx-delay-ps = <700>;
+   allwinner,tx-delay-ps = <700>;
+   status = "okay";
+
+   phy1: ethernet-phy@1 {
+   reg = <1>;
+   };
+   };
+   };
+};
+
+ {
+   rgmii_pins: rgmii_pins {
+   allwinner,pins = "PD2", "PD3", "PD4", "PD5", "PD6", "PD7",
+"PD11", "PD12", "PD13", "PD14", "PD18",
+"PD19", "PD21", "PD22", "PD23";
+   allwinner,function = "emac";
+   allwinner,drive = <3>;
+   allwinner,pull = <0>;
+   };
+};
diff --git a/configs/Sinovoip_BPI_M3_defconfig 
b/configs/Sinovoip_BPI_M3_defconfig
index 60aea1eb3d22..6360e3761e6b 100644
--- a/configs/Sinovoip_BPI_M3_defconfig
+++ b/configs/Sinovoip_BPI_M3_defconfig
@@ -22,6 +22,8 @@ CONFIG_SPL=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_ISO_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_PHY_REALTEK=y
+CONFIG_SUN8I_EMAC=y
 CONFIG_AXP_DCDC5_VOLT=1200
 CONFIG_AXP_DLDO3_VOLT=2500
 CONFIG_AXP_SW_ON=y
-- 
2.15.0

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


[U-Boot] [PATCH v2 0/5] sunxi: Enable EMAC on various boards

2017-11-24 Thread Chen-Yu Tsai
Hi,

This series enables the EMAC for some A83T and A64 boards.

Changes since v1:

  - Added "bitfield: Include linux/bitops.h for ffs()" to fix build
errors
  - Use bitfield_replace_by_mask() instead of open coding bitfield ops
  - Trimmed used pins in the device tree to only those actually needed
  - Enabled Realtek PHY driver
  - Added "sunxi: Enable EMAC on the Bananapi M64"

ChenYu


Chen-Yu Tsai (5):
  bitfield: Include linux/bitops.h for ffs()
  net: sun8i_emac: Support RX/TX delay chains
  sunxi: Enable EMAC on the Cubietruck Plus
  sunxi: Enable EMAC on the Bananapi M3
  sunxi: Enable EMAC on the Bananapi M64

 arch/arm/dts/sun50i-a64-bananapi-m64-u-boot.dtsi   | 39 +
 arch/arm/dts/sun8i-a83t-bananapi-m3-u-boot.dtsi| 40 ++
 .../arm/dts/sun8i-a83t-cubietruck-plus-u-boot.dtsi | 38 
 configs/Cubietruck_plus_defconfig  |  2 ++
 configs/Sinovoip_BPI_M3_defconfig  |  2 ++
 drivers/net/sun8i_emac.c   | 22 
 include/bitfield.h |  1 +
 7 files changed, 144 insertions(+)
 create mode 100644 arch/arm/dts/sun50i-a64-bananapi-m64-u-boot.dtsi
 create mode 100644 arch/arm/dts/sun8i-a83t-bananapi-m3-u-boot.dtsi
 create mode 100644 arch/arm/dts/sun8i-a83t-cubietruck-plus-u-boot.dtsi

-- 
2.15.0

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


[U-Boot] [PATCH v2 2/5] net: sun8i_emac: Support RX/TX delay chains

2017-11-24 Thread Chen-Yu Tsai
The EMAC syscon has configurable RX/TX delay chains for use with RGMII
PHYs.

This adds support for configuring them via device tree properties. The
property names and format were defined in Linux's dwmac-sun8i binding
that was merged at one point.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/net/sun8i_emac.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
index 3ccc6b0bb612..ea26450d34bc 100644
--- a/drivers/net/sun8i_emac.c
+++ b/drivers/net/sun8i_emac.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -56,6 +57,8 @@
 #define H3_EPHY_SELECT BIT(15) /* 1: internal PHY, 0: external PHY */
 
 #define SC_RMII_EN BIT(13)
+#define SC_TXDC_MASK   GENMASK(12, 10)
+#define SC_RXDC_MASK   GENMASK(9, 5)
 #define SC_EPITBIT(2) /* 1: RGMII, 0: MII */
 #define SC_ETCS_MASK   GENMASK(1, 0)
 #define SC_ETCS_EXT_GMII   0x1
@@ -125,6 +128,8 @@ struct emac_eth_dev {
u32 addr;
u32 tx_slot;
bool use_internal_phy;
+   u32 tx_delay;
+   u32 rx_delay;
 
enum emac_variant variant;
void *mac_reg;
@@ -290,6 +295,10 @@ static int sun8i_emac_set_syscon(struct emac_eth_dev *priv)
if (priv->variant == H3_EMAC || priv->variant == A64_EMAC)
reg &= ~SC_RMII_EN;
 
+   /* Configure RX/TX delay chains */
+   reg = bitfield_replace_by_mask(reg, SC_RXDC_MASK, priv->rx_delay);
+   reg = bitfield_replace_by_mask(reg, SC_TXDC_MASK, priv->tx_delay);
+
switch (priv->interface) {
case PHY_INTERFACE_MODE_MII:
/* default */
@@ -839,6 +848,19 @@ static int sun8i_emac_eth_ofdata_to_platdata(struct 
udevice *dev)
}
 #endif
 
+   /* Get RX/TX delays for RGMII */
+   priv->rx_delay = fdtdec_get_uint(gd->fdt_blob, dev_of_offset(dev),
+"allwinner,rx-delay-ps", 0);
+   if (priv->rx_delay % 100 || priv->rx_delay > 3100)
+   debug("%s: invalid rx delay value\n", __func__);
+   priv->rx_delay /= 100;
+
+   priv->tx_delay = fdtdec_get_uint(gd->fdt_blob, dev_of_offset(dev),
+"allwinner,tx-delay-ps", 0);
+   if (priv->tx_delay % 100 || priv->tx_delay > 800)
+   debug("%s: invalid tx delay value\n", __func__);
+   priv->tx_delay /= 100;
+
return 0;
 }
 
-- 
2.15.0

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


[U-Boot] [PATCH v2 1/5] bitfield: Include linux/bitops.h for ffs()

2017-11-24 Thread Chen-Yu Tsai
bitfield_shift() uses the ffs() function, which is provided by bitops.h.

Explicitly include this header.

Signed-off-by: Chen-Yu Tsai 
---
 include/bitfield.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/bitfield.h b/include/bitfield.h
index a59f3c279aad..adfae49de580 100644
--- a/include/bitfield.h
+++ b/include/bitfield.h
@@ -37,6 +37,7 @@
  * tables which describe all bitfields in all registers.
  */
 
+#include 
 #include 
 
 /* Produces a mask of set bits covering a range of a uint value */
-- 
2.15.0

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


[U-Boot] EFI: incorrect device paths

2017-11-24 Thread Heinrich Schuchardt

Hello Emmanuel,

yesterday you reported on the u-boot ICS channel that you saw an 
incorrect device path for the SD card on your BananaPi M2 
(/venHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Usb(0x6,0x0)/HD(Part0,MBRType=01)).


In dp_fill() both mass storage (UCLASS_MASS_STORAGE) and USB hubs 
(UCLASS_USB_HUB) are mapped to USB devices. Maybe that is what happened 
to you.


On my Odroid C2 the following devices paths are created:

Installed device path protocols: 

/MemoryMapped(0x0,0x7ff9c604,0x7ff9c604) 


/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MMC(Slot0)/HD(Part0,Sig6fe3)

/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MMC(Slot0)/HD(Part1,Sig6fe3)

/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MMC(Slot0)/HD(Part2,Sig6fe3)

/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MMC(Slot0)/HD(Part3,Sig6fe3)

/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MMC(Slot0)

/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/
/VenHw(dbca4c98-6cb0-694d-0872-819c650cbbb1)

/VenHw(dbca4c98-6cb0-694d-0872-819c650cbbb1)/
VenHw(dbca4c98-6cb0-694d-0872-819c650cbba2)

/VenHw(dbca4c98-6cb0-694d-0872-819c650cbbb1)/
VenHw(dbca4c98-6cb0-694d-0872-819c650cbba2)/VenHw(dbca4c9...

I have an SD card with four partitions.

The entry with partition number 0 should match to the whole disk. So 
obviously one device path is missing.


eMMC should be reported as eMMC(SlotNumber) where slot number is a 
number only, e.g. eMMC(1).


SD cards should be reported as SD(SlotNumber), e.g. SD(1).

Partions should be reported as
HD(Partition,Type,Signature,Start,Size) or
HD(Partition,Type,Signature) (display only)
e.g.
HD(1,GPT,15E39A00-1DD2-1000-8D7F-00A0C92408FC,0x22,0x271000)

So there seems to be still a lot to be fixed.

Best regards

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


Re: [U-Boot] [PATCH 3/5] mmc: dump card and host capabilities if debug is enabled

2017-11-24 Thread Simon Glass
On 21 November 2017 at 08:13, Jean-Jacques Hiblot  wrote:
> This is a useful information while debugging the initialization process or
> performance issues.
>
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/mmc/mmc.c | 9 +
>  1 file changed, 9 insertions(+)
Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/5] dm: mmc: updated mmc_of_parse() to not fail because of an invalid bus-width

2017-11-24 Thread Simon Glass
Hi Jean-Jacques,


On 21 November 2017 at 08:13, Jean-Jacques Hiblot  wrote:
> Instead of failing, the driver uses the default: 1-bit bus width.
>
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/mmc/mmc-uclass.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index e30cde7..48fafce 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -137,9 +137,10 @@ int mmc_of_parse(const void *fdt, int node, struct 
> mmc_config *cfg)

Can you please add a function comment for this function in the header?

Also if you have time, this function should be converted to use live
tree - dev_read...() etc.

> cfg->host_caps |= MMC_MODE_1BIT;
> break;
> default:
> -   printf("error: %s invalid bus-width property %d\n",
> -  fdt_get_name(fdt, node, NULL), val);
> -   return -ENOENT;
> +   debug("warning: %s invalid bus-width property. using 1-bit\n",
> + fdt_get_name(fdt, node, NULL));
> +   cfg->host_caps |= MMC_MODE_1BIT;
> +   break;
> }
>
> cfg->f_max = fdtdec_get_int(fdt, node, "max-frequency", 5200);
> --
> 1.9.1
>

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


Re: [U-Boot] [PATCH] atcpit100: timer: Remove arch dependency.

2017-11-24 Thread Simon Glass
Hi Rick,

On 20 November 2017 at 23:50,   wrote:
>> -Original Message-
>> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
>> Sent: Monday, November 20, 2017 11:40 PM
>> To: Open Source Project uboot
>> Cc: U-Boot Mailing List; Wolfgang Denk; Detlev Zundel; Rick Jian-Zhi Chen(陳建
>> 志)
>> Subject: Re: [PATCH] atcpit100: timer: Remove arch dependency.
>>
>> On 14 November 2017 at 20:03, Andes  wrote:
>> > From: Rick Chen 
>>
>> How come the patch does not come from that email?

I was just confused by the need for the 'From' line. It seems like
your email is r...@andestech.com, and this reply has come from there,
so I wondered why the patch does not come from you as well. It seems
to come from ub...@andestech.com.

>>
>
> I do not know what patch do you mean ?
> I want to remove NDS32 in the string of "depends on TIMER && NDS32" in the 
> Kconfig
> Do I miss something or do something wrong ?
>
>> >
>> > ATCPIT100 is often used in AE3XX platform which is based on NDS32
>> > architecture recently. But in the future Andestech will have AE250
>> > platform which is embeded
>> > ATCPIT100 timer based on RISCV architecture.
>> >
>> > Signed-off-by: Rick Chen 
>> > ---
>> >  drivers/timer/Kconfig |2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Reviewed-by: Simon Glass 
> CONFIDENTIALITY NOTICE:
>
> This e-mail (and its attachments) may contain confidential and legally 
> privileged information or information protected from disclosure. If you are 
> not the intended recipient, you are hereby notified that any disclosure, 
> copying, distribution, or use of the information contained herein is strictly 
> prohibited. In this case, please immediately notify the sender by return 
> e-mail, delete the message (and any accompanying documents) and destroy all 
> printed hard copies. Thank you for your cooperation.
>
> Copyright ANDES TECHNOLOGY CORPORATION - All Rights Reserved.

Also please can you drop this from mailing list posts?

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


Re: [U-Boot] [PATCH 1/3] ae3xx: timer: Rename AE3XX to ATCPIT100

2017-11-24 Thread Simon Glass
Hi Rick,

On 21 November 2017 at 00:27,   wrote:
>
>
>> -Original Message-
>> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of
>> r...@andestech.com
>> Sent: Tuesday, November 21, 2017 2:40 PM
>> To: s...@chromium.org; Open Source Project uboot
>> Cc: u-boot@lists.denx.de; d...@denx.de
>> Subject: Re: [U-Boot] [PATCH 1/3] ae3xx: timer: Rename AE3XX to ATCPIT100
>>
>>
>> > -Original Message-
>> > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
>> > Sent: Monday, November 20, 2017 11:40 PM
>> > To: Open Source Project uboot
>> > Cc: U-Boot Mailing List; Wolfgang Denk; Detlev Zundel; Rick Jian-Zhi
>> > Chen(陳建
>> > 志)
>> > Subject: Re: [PATCH 1/3] ae3xx: timer: Rename AE3XX to ATCPIT100
>> >
>> > Hi,
>> >
>> > On 14 November 2017 at 19:48, Andes  wrote:
>> > > From: Rick Chen 
>> > >
>> > > ATCPIT100 is Andestech timer IP which is embeded in AE3XX and AE250
>> > > boards. So rename AE3XX to
>> > > ATCPIT100 will be more make sence.
>> > >
>> > > Signed-off-by: Rick Chen 
>> > > ---
>> > >  drivers/timer/Kconfig   |7 ++-
>> > >  drivers/timer/Makefile  |2 +-
>> > >  drivers/timer/ae3xx_timer.c |  117 
>> > > ---
>> > >  drivers/timer/atcpit100_timer.c |  117
>> > > +++
>> >
>> > If this is just a rename, why the big delta?
>> >
>>
>> I want to rename ae3xx_timer.c to atcpit100_timer.c By the way I also rename
>> function name and and struct name to let it more reasonable.
>> But I do not modify the code itself.
>>
>> Do you mean I shall not modify the content of atcpit100_timer.c ?
>> Or I can modify but I shall describe it more clear ?
>>
>
> Though the patch is not easy to see the differences.
> I tig it and list the delta for you reviewing

OK I see, thank you. Are you using 'patman' to submit the patches? It
should send this through as a proper delta.

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


Re: [U-Boot] [PATCH] fpga: allow programming fpga from FIT image for all FPGA drivers

2017-11-24 Thread Simon Glass
Hi Simon,

On 20 November 2017 at 22:38, Goldschmidt Simon
 wrote:
> Hi,
>
>> Simon Glass wrote:
>> On 10 November 2017 at 07:17, Goldschmidt Simon > fuchs.com> wrote:
>> > This drops the limit that fpga is only loaded from FIT images for Xilinx.
>> > This is done by moving the 'partial' check from 'common/image.c' to
>> > 'drivers/fpga/xilinx.c' (the only driver supporting partial images
>> > yet) and supplies a weak default implementation in 'drivers/fpga/fpga.c'.
>> >
>> > Signed-off-by: Simon Goldschmidt 
>> > ---
>> >  common/bootm.c|  2 +-
>> >  common/image.c|  6 ++
>> >  drivers/fpga/fpga.c   |  9 +
>> >  drivers/fpga/xilinx.c | 13 +
>> >  include/fpga.h|  1 +
>> >  5 files changed, 26 insertions(+), 5 deletions(-)
>> >
>>
>> I think the FPGA subsystem should move to driver model.
>
> I can understand the need for that. However, I don't have the expertise
> to do so, I guess. Also, I would have thought this requirement would be
> raised to someone actually adding/changing fpga code (like the recent
> Intel activities on this list).
>
> In contrast to this, I see my patch more like cleaning the code, moving
> Xilinx dependent code from 'common/image.c' to 'drivers/fpga/xilinx.c'.
> This cleanup in the common directory is rather independent of migrating
> the fpga subsystem to driver model.

I see that, although it is adding to the fpga header so presumably
making it harder for someone to move this over.

Does anyone on cc know the plan fr conversion of FPGA to driver model?
It does not look too tricky from a quick look at the header file.

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


Re: [U-Boot] [PATCH v2 04/11] tools: mkimage: Extend mkimage to also include pmufw

2017-11-24 Thread Simon Glass
On 21 November 2017 at 05:00, Michal Simek  wrote:
> The patch is adding external pmufw "Platform Management Unit firmware"
> to boot.bin image. Boot.bin is a Xilinx format which bootrom is capable
> to read and boot the system. pmufw is copied to the header data section
> follows by u-boot-spl.bin. pmufw is consumed by PMU unit (Microblaze)
> and SPL runs on a53-0.
>
> This is generated command line when PMUFW_INIT_FILE is setup.
>
> ./tools/mkimage -T zynqmpimage -R ./"" -n
> ./"board/xilinx/zynqmp/pmufw.bin" -d spl/u-boot-spl.bin spl/boot.bin
>
> Signed-off-by: Michal Simek 
> ---
>
> Changes in v2:
> - Change commit message - reported by sjg
> - Extend help in Kconfig - reported by sjg
>
>  arch/arm/cpu/armv8/zynqmp/Kconfig |  8 
>  scripts/Makefile.spl  |  3 +-
>  tools/zynqmpimage.c   | 99 
> ++-
>  3 files changed, 108 insertions(+), 2 deletions(-)
>

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


Re: [U-Boot] [PATCH] env: suppress a spurious warning with GCC 7.1

2017-11-24 Thread Simon Glass
On 21 November 2017 at 15:29, Philipp Tomsich
 wrote:
> GCC 7.1 seems to be smart enough to track val through the various
> static inline functions, but not smart enough to see that val will
> always be initialised when no error is returned.  This triggers
> the following warning:
>   env/mmc.c: In function 'mmc_get_env_addr':
>   env/mmc.c:121:12: warning: 'val' may be used uninitialized in this function 
> [-Wmaybe-uninitialized]
>
> To make it easier for compiler to understand what is going on, let's
> initialise val.
>
> Signed-off-by: Philipp Tomsich 
> ---
>
>  env/mmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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


Re: [U-Boot] [PATCH 4/5] mmc: Fixed a problem with old sd or mmc that do not support High speed

2017-11-24 Thread Simon Glass
On 21 November 2017 at 08:13, Jean-Jacques Hiblot  wrote:

nit: It is common to use the imperative tense in patches rather than
past tesse, e.g. 'Fix a problem with...'

> As the legacy modes were not added to the list of supported modes, old
> cards that do not support other modes could not be used.
>
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/mmc/mmc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

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


Re: [U-Boot] [PATCH 2/5] mmc: dm: support "mmc-ddr-1_2v" and "mmc-hs200-1_2v" boolean properties

2017-11-24 Thread Simon Glass
Hi Jean-Jacques,

On 21 November 2017 at 08:13, Jean-Jacques Hiblot  wrote:
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/mmc/mmc-uclass.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index 48fafce..9723129 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -161,8 +161,12 @@ int mmc_of_parse(const void *fdt, int node, struct 
> mmc_config *cfg)
> cfg->host_caps |= MMC_CAP(UHS_DDR50);
> if (fdtdec_get_bool(fdt, node, "mmc-ddr-1_8v"))
> cfg->host_caps |= MMC_CAP(MMC_DDR_52);
> +   if (fdtdec_get_bool(fdt, node, "mmc-ddr-1_2v"))
> +   cfg->host_caps |= MMC_CAP(MMC_DDR_52);
> if (fdtdec_get_bool(fdt, node, "mmc-hs200-1_8v"))
> cfg->host_caps |= MMC_CAP(MMC_HS_200);
> +   if (fdtdec_get_bool(fdt, node, "mmc-hs200-1_2v"))
> +   cfg->host_caps |= MMC_CAP(MMC_HS_200);

Hmm, please convert to livetree first - e.g. ofnode_read_bool()

>
> return 0;
>  }
> --
> 1.9.1
>

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


Re: [U-Boot] dm: mmc: fsl_esdhc: Drop mmc_init() call from fsl_esdhc_init()

2017-11-24 Thread Simon Glass
Hi,

On 20 November 2017 at 23:11, Y.b. Lu  wrote:
> Hi Simon,
>
>
>
> I found your below patch just dropping mmc_create() for probe procedure of
> DM.
>
> Actually the description seemed to be not the things this patch did.
>
>
>
> dm: mmc: fsl_esdhc: Drop mmc_init() call from fsl_esdhc_init()
>
>
>
> Do you have any suggestion to fix it?
>
> mmc_create() will allocate mmc structure and the DM in fsl_esdhc also
> allocate mmc structure in fsl_esdhc_plat structure.
>
> Do we need to rework the mmc_create(), or move rest initialization of
> mmc_create() in to fsl_esdhc_probe() ?

But mmc_create() is only used in legacy code, not with driver model.

Why do you want to call it here? Does your board not use CONFIG_DM_MMC?

>
>
>
> Thanks a lot.

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


Re: [U-Boot] [PATCH 5/5] arm: zynq: Add mini u-boot configuration for zynq

2017-11-24 Thread Simon Glass
Hi Michal,

On 21 November 2017 at 00:23, Michal Simek  wrote:
> On 20.11.2017 16:38, Simon Glass wrote:
>> On 6 November 2017 at 04:45, Michal Simek  wrote:
>>> Add configuration files/dtses for mini u-boot configurations which runs
>>> out of OCM.
>>>
>>> ram top is calculated from 0 that's why +#define CONFIG_SYS_SDRAM_BASE
>>> 0xfffc
>>> +#define CONFIG_SYS_SDRAM_SIZE  0x4
>>> was hardcoded.
>>>
>>> Signed-off-by: Michal Simek 
>>> ---
>>>
>>>  arch/arm/dts/Makefile  |   1 +
>>>  arch/arm/dts/zynq-cse-qspi-single.dts  |  13 
>>>  arch/arm/dts/zynq-cse-qspi.dtsi| 126 
>>> +
>>>  board/xilinx/zynq/zynq-cse-qspi-single |   1 +
>>>  configs/zynq_cse_qspi_defconfig|  62 
>>>  include/configs/zynq_cse.h |  53 ++
>>>  6 files changed, 256 insertions(+)
>>>  create mode 100644 arch/arm/dts/zynq-cse-qspi-single.dts
>>>  create mode 100644 arch/arm/dts/zynq-cse-qspi.dtsi
>>>  create mode 12 board/xilinx/zynq/zynq-cse-qspi-single
>>>  create mode 100644 configs/zynq_cse_qspi_defconfig
>>>  create mode 100644 include/configs/zynq_cse.h
>>
>> Reviewed-by: Simon Glass 
>>
>> It's sad to see that we still have so many CONFIG options not
>> converted to Kconfig.
>
> Unfortunately. That was the reason I wanted to push this to mainline.
> It is very minimal configuration which requires just a minimum stuff.
>
> Did someone convert CONFIG_SYS_MALLOC_LEN?
> I have another 2 configurations for NOR and NAND only mini
> configurations which depend on this to be converted.

Not that I saw. There are still at least a few dozen commonly used
generic configs that need conversion.

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


Re: [U-Boot] [PATCH 5/5] mmc: all hosts support 1-bit bus width and legacy timings

2017-11-24 Thread Simon Glass
Hi Jean-Jacques,

On 21 November 2017 at 08:13, Jean-Jacques Hiblot  wrote:
> Make sure that those basic capabilities are advertised by the host.
>
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/mmc/mmc.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
>

Your patch seems to suggest that the hardware is advertising the wrong
thing. Is that right?

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


Re: [U-Boot] [PATCH v2 2/5] board: odroid-c2: use common ethernet init function

2017-11-24 Thread Simon Glass
On 22 November 2017 at 06:25, Neil Armstrong  wrote:
> Switch Odroid-C2 Ethernet init to the common Ethernet init function.
>
> Signed-off-by: Neil Armstrong 
> ---
>  board/amlogic/odroid-c2/odroid-c2.c | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)

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


Re: [U-Boot] [PATCH v2 5/5] arm: Add Khadas VIM support based on Meson GXL family

2017-11-24 Thread Simon Glass
Hi Neil,

On 22 November 2017 at 06:25, Neil Armstrong  wrote:
> This adds platform code for the Khadas VIM board based on a
> Meson GXL (S905X) SoC with the Meson GXL configuration.
>
> This initial submission supports UART, MMC/SDCard and Ethernet with the
> Internal RMII PHY.
>
> The meson-gxl-s905x-khadas-vim.dts is synchronised from the linux 4.13
> stable tree as of 4.13.8.
>
> Signed-off-by: Neil Armstrong 
> ---
>  arch/arm/dts/Makefile   |   3 +-
>  arch/arm/dts/meson-gxl-s905x-khadas-vim.dts | 137 
> 
>  arch/arm/mach-meson/Kconfig |   9 ++
>  board/amlogic/khadas-vim/Kconfig|  12 +++
>  board/amlogic/khadas-vim/MAINTAINERS|   6 ++
>  board/amlogic/khadas-vim/Makefile   |   8 ++
>  board/amlogic/khadas-vim/README |  96 +++
>  board/amlogic/khadas-vim/khadas-vim.c   |  48 ++
>  configs/khadas-vim_defconfig|  35 +++
>  include/configs/khadas-vim.h|  21 +
>  10 files changed, 374 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/meson-gxl-s905x-khadas-vim.dts
>  create mode 100644 board/amlogic/khadas-vim/Kconfig
>  create mode 100644 board/amlogic/khadas-vim/MAINTAINERS
>  create mode 100644 board/amlogic/khadas-vim/Makefile
>  create mode 100644 board/amlogic/khadas-vim/README
>  create mode 100644 board/amlogic/khadas-vim/khadas-vim.c
>  create mode 100644 configs/khadas-vim_defconfig
>  create mode 100644 include/configs/khadas-vim.h

Reviewed-by: Simon Glass 

Please see below.

> diff --git a/board/amlogic/khadas-vim/README b/board/amlogic/khadas-vim/README
> new file mode 100644
> index 000..add6a29
> --- /dev/null
> +++ b/board/amlogic/khadas-vim/README
> @@ -0,0 +1,96 @@
> +U-Boot for Khadas VIM
> +===
> +
> +Khadas VIM is an Open Source DIY Box manufactured by Shenzhen Tomato
> +Technology Co., Ltd with the following specifications:
> +
> + - Amlogic S905x ARM Cortex-A53 quad-core SoC @ 2GHz
> + - ARM Mali 450 GPU
> + - 2GB DDR3 SDRAM
> + - 10/100 Ethernet
> + - HDMI 2.0 4K/60Hz display
> + - 40-pin GPIO header
> + - 2 x USB 2.0 Host, 1 x USB 2.0 Type-C OTG
> + - 8GB/16GBeMMC
> + - microSD
> + - SDIO Wifi Module, Bluetooth
> + - Two channels IR receiver
> +
> +Currently the u-boot port supports the following devices:
> + - serial
> + - eMMC, microSD
> + - Ethernet
> +
> +u-boot compilation

U-Boot

> +==
> +
> + > export ARCH=arm
> + > export CROSS_COMPILE=aarch64-none-elf-
> + > make khadas-vim_defconfig
> + > make
> +
> +Image creation
> +==
> +
> +Amlogic doesn't provide sources for the firmware and for tools needed
> +to create the bootloader image, so it is necessary to obtain them from
> +the git tree published by the board vendor:
> +
> + > wget 
> https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
> + > wget 
> https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
> + > tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
> + > tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
> + > export 
> PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
> + > git clone https://github.com/khadas/u-boot -b Vim vim-u-boot
> + > cd vim-u-boot
> + > make kvim_defconfig
> + > make
> + > export FIPDIR=$PWD/fip
> +
> +Go back to mainline U-Boot source tree then :
> + > mkdir fip
> +
> + > cp $FIPDIR/gxl/bl2.bin fip/
> + > cp $FIPDIR/gxl/acs.bin fip/
> + > cp $FIPDIR/gxl/bl21.bin fip/
> + > cp $FIPDIR/gxl/bl30.bin fip/
> + > cp $FIPDIR/gxl/bl301.bin fip/
> + > cp $FIPDIR/gxl/bl31.img fip/
> + > cp u-boot.bin fip/bl33.bin
> +
> + > $FIPDIR/blx_fix.sh \
> +   fip/bl30.bin \
> +   fip/zero_tmp \
> +   fip/bl30_zero.bin \
> +   fip/bl301.bin \
> +   fip/bl301_zero.bin \
> +   fip/bl30_new.bin \
> +   bl30
> +
> + > $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0
> +
> + > $FIPDIR/blx_fix.sh \
> +   fip/bl2_acs.bin \
> +   fip/zero_tmp \
> +   fip/bl2_zero.bin \
> +   fip/bl21.bin \
> +   fip/bl21_zero.bin \
> +   fip/bl2_new.bin \
> +   bl2
> +
> + > $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl30_new.bin
> + > $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl31.img
> + > $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl33.bin
> + > $FIPDIR/gxl/aml_encrypt_gxl --bl2sig --input fip/bl2_new.bin --output 
> fip/bl2.n.bin.sig
> + > $FIPDIR/gxl/aml_encrypt_gxl --bootmk \
> +   --output fip/u-boot.bin \
> +   --bl2 fip/bl2.n.bin.sig \
> +   --bl30 fip/bl30_new.bin.enc \
> +   --bl31 fip/bl31.img.enc \
> +   --bl33 fip/bl33.bin.enc
> +
> +and then 

Re: [U-Boot] [PATCH v2 4/5] arm: Add LibreTech CC support based on Meson GXL family

2017-11-24 Thread Simon Glass
Hi Neil,

On 22 November 2017 at 06:25, Neil Armstrong  wrote:
> This adds platform code for the Libre Computer CC "Le Potato" board based on a
> Meson GXL (S905X) SoC with the Meson GXL configuration.
>
> This initial submission supports UART, MMC/SDCard and Ethernet with the
> Internal RMII PHY.
>
> The meson-gxl-s905x-libretech-cc.dts is synchronised from the linux 4.13
> stable tree as of 4.13.8.
>
> Signed-off-by: Neil Armstrong 
> ---
>  arch/arm/dts/Makefile |   3 +-
>  arch/arm/dts/meson-gxl-s905x-libretech-cc.dts | 171 
> ++
>  arch/arm/mach-meson/Kconfig   |   9 ++
>  board/amlogic/libretech-cc/Kconfig|  12 ++
>  board/amlogic/libretech-cc/MAINTAINERS|   6 +
>  board/amlogic/libretech-cc/Makefile   |   8 ++
>  board/amlogic/libretech-cc/README |  96 +++
>  board/amlogic/libretech-cc/libretech-cc.c |  52 
>  configs/libretech-cc_defconfig|  35 ++
>  include/configs/libretech-cc.h|  21 
>  10 files changed, 412 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/meson-gxl-s905x-libretech-cc.dts
>  create mode 100644 board/amlogic/libretech-cc/Kconfig
>  create mode 100644 board/amlogic/libretech-cc/MAINTAINERS
>  create mode 100644 board/amlogic/libretech-cc/Makefile
>  create mode 100644 board/amlogic/libretech-cc/README
>  create mode 100644 board/amlogic/libretech-cc/libretech-cc.c
>  create mode 100644 configs/libretech-cc_defconfig
>  create mode 100644 include/configs/libretech-cc.h
>

Reviewed-by: Simon Glass 


[..]

> new file mode 100644
> index 000..d0e3bbb
> --- /dev/null
> +++ b/board/amlogic/libretech-cc/Makefile
> @@ -0,0 +1,8 @@
> +#
> +# (C) Copyright 2016 BayLibre, SAS
> +# Author: Neil Armstrong 
> +#
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +
> +obj-y  := libretech-cc.o
> diff --git a/board/amlogic/libretech-cc/README 
> b/board/amlogic/libretech-cc/README
> new file mode 100644
> index 000..8b38fff
> --- /dev/null
> +++ b/board/amlogic/libretech-cc/README
> @@ -0,0 +1,96 @@
> +U-Boot for LibreTech CC
> +===
> +
> +LibreTech CC is a single board computer manufactured by Libre Technology
> +with the following specifications:
> +
> + - Amlogic S905X ARM Cortex-A53 quad-core SoC @ 2GHz
> + - ARM Mali 450 GPU
> + - 2GB DDR3 SDRAM
> + - Gigabit Ethernet
> + - HDMI 2.0 4K/60Hz display
> + - 40-pin GPIO header
> + - 4 x USB 2.0 Host, 1 x USB OTG
> + - eMMC, microSD
> + - Infrared receiver
> +
> +Schematics are available on the manufacturer website.
> +
> +Currently the U-Boot port supports the following devices:
> + - serial
> + - eMMC, microSD
> + - Ethernet
> +
> +u-boot compilation

U-Boot

> +==
> +
> + > export ARCH=arm
> + > export CROSS_COMPILE=aarch64-none-elf-
> + > make libretech-cc_defconfig
> + > make
> +
> +Image creation
> +==
> +
> +Amlogic doesn't provide sources for the firmware and for tools needed
> +to create the bootloader image, so it is necessary to obtain them from
> +the git tree published by the board vendor:
> +
> + > wget 
> https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
> + > wget 
> https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
> + > tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
> + > tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
> + > export 
> PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
> + > git clone https://github.com/BayLibre/u-boot.git -b libretech-cc 
> amlogic-u-boot
> + > cd amlogic-u-boot
> + > make libretech_cc_defconfig
> + > make
> + > export FIPDIR=$PWD/fip
> +
> +Go back to mainline U-Boot source tree then :
> + > mkdir fip
> +
> + > cp $FIPDIR/gxl/bl2.bin fip/
> + > cp $FIPDIR/gxl/acs.bin fip/
> + > cp $FIPDIR/gxl/bl21.bin fip/
> + > cp $FIPDIR/gxl/bl30.bin fip/
> + > cp $FIPDIR/gxl/bl301.bin fip/
> + > cp $FIPDIR/gxl/bl31.img fip/
> + > cp u-boot.bin fip/bl33.bin
> +
> + > $FIPDIR/blx_fix.sh \
> +   fip/bl30.bin \
> +   fip/zero_tmp \
> +   fip/bl30_zero.bin \
> +   fip/bl301.bin \
> +   fip/bl301_zero.bin \
> +   fip/bl30_new.bin \
> +   bl30
> +
> + > $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0
> +
> + > $FIPDIR/blx_fix.sh \
> +   fip/bl2_acs.bin \
> +   fip/zero_tmp \
> +   fip/bl2_zero.bin \
> +   fip/bl21.bin \
> +   fip/bl21_zero.bin \
> +   fip/bl2_new.bin \
> +   bl2
> +
> + > $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl30_new.bin
> + > $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl31.img
> + > $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl33.bin
> + > 

Re: [U-Boot] [PATCH v2 3/5] board: p212: use common ethernet init function

2017-11-24 Thread Simon Glass
On 22 November 2017 at 06:25, Neil Armstrong  wrote:
> Switch P212 Ethernet init to the common Ethernet init function.
>
> Signed-off-by: Neil Armstrong 
> ---
>  board/amlogic/p212/p212.c | 14 ++
>  1 file changed, 2 insertions(+), 12 deletions(-)

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


Re: [U-Boot] [PATCH v2 1/5] ARM: arch-meson: add ethernet common init function

2017-11-24 Thread Simon Glass
Hi Neil,

On 22 November 2017 at 06:25, Neil Armstrong  wrote:
> Introduce a generic common Ethernet Hardware init function
> common to all Amlogic GX SoCs with support for the
> Internal PHY enable for GXL SoCs.
>
> Signed-off-by: Neil Armstrong 
> ---
>  arch/arm/include/asm/arch-meson/eth.h | 15 ++
>  arch/arm/mach-meson/Makefile  |  2 +-
>  arch/arm/mach-meson/eth.c | 53 
> +++
>  3 files changed, 69 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/include/asm/arch-meson/eth.h
>  create mode 100644 arch/arm/mach-meson/eth.c
>
> diff --git a/arch/arm/include/asm/arch-meson/eth.h 
> b/arch/arm/include/asm/arch-meson/eth.h
> new file mode 100644
> index 000..8ea8e10
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-meson/eth.h
> @@ -0,0 +1,15 @@
> +/*
> + * Copyright (C) 2016 BayLibre, SAS
> + * Author: Neil Armstrong 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#ifndef __MESON_ETH_H__
> +#define __MESON_ETH_H__
> +
> +#include 
> +
> +void meson_gx_eth_init(phy_interface_t mode, bool use_internal_phy);
> +
> +#endif /* __MESON_ETH_H__ */
> diff --git a/arch/arm/mach-meson/Makefile b/arch/arm/mach-meson/Makefile
> index bf49b8b..b4e8dde 100644
> --- a/arch/arm/mach-meson/Makefile
> +++ b/arch/arm/mach-meson/Makefile
> @@ -4,4 +4,4 @@
>  # SPDX-License-Identifier: GPL-2.0+
>  #
>
> -obj-y += board.o sm.o
> +obj-y += board.o sm.o eth.o
> diff --git a/arch/arm/mach-meson/eth.c b/arch/arm/mach-meson/eth.c
> new file mode 100644
> index 000..46ecb5e
> --- /dev/null
> +++ b/arch/arm/mach-meson/eth.c
> @@ -0,0 +1,53 @@
> +/*
> + * Copyright (C) 2016 BayLibre, SAS
> + * Author: Neil Armstrong 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +void meson_gx_eth_init(phy_interface_t mode, bool use_internal_phy)

Can you add a header file addition for this somewhere, with comments?

> +{
> +   switch (mode) {
> +   case PHY_INTERFACE_MODE_RGMII:
> +   case PHY_INTERFACE_MODE_RGMII_ID:
> +   case PHY_INTERFACE_MODE_RGMII_RXID:
> +   case PHY_INTERFACE_MODE_RGMII_TXID:
> +   /* Set RGMII mode */
> +   setbits_le32(GXBB_ETH_REG_0, GXBB_ETH_REG_0_PHY_INTF |
> +GXBB_ETH_REG_0_TX_PHASE(1) |
> +GXBB_ETH_REG_0_TX_RATIO(4) |
> +GXBB_ETH_REG_0_PHY_CLK_EN |
> +GXBB_ETH_REG_0_CLK_EN);
> +   break;
> +
> +   case PHY_INTERFACE_MODE_RMII:
> +   /* Set RMII mode */
> +   out_le32(GXBB_ETH_REG_0, GXBB_ETH_REG_0_INVERT_RMII_CLK |
> +GXBB_ETH_REG_0_CLK_EN);

How come this is using out_le32() instead of (for example) writel()?

> +
> +#ifdef CONFIG_MESON_GXL

This doesn't seem fully generic if it has this #ifdef in it. Can this
be a parameter? At worst can we use if() instead of #ifdef ?

> +   if (use_internal_phy) {
> +   /* Use Internal PHY */
> +   out_le32(GXBB_ETH_REG_2, 0x10110181);
> +   out_le32(GXBB_ETH_REG_3, 0xe40908ff);
> +   }
> +#endif
> +
> +   break;
> +
> +   default:
> +   printf("Invalid Ethernet interface mode\n");
> +   return;
> +   }
> +
> +   /* Enable power and clock gate */
> +   setbits_le32(GXBB_GCLK_MPEG_1, GXBB_GCLK_MPEG_1_ETH);
> +   clrbits_le32(GXBB_MEM_PD_REG_0, GXBB_MEM_PD_REG_0_ETH_MASK);

Seems like this should be in a clock driver.

> +}
> --
> 2.7.4
>

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


Re: [U-Boot] [PATCH u-boot] ARM: arch-meson: build memory banks using reported memory from registers

2017-11-24 Thread Simon Glass
Hi Neil,

On 20 November 2017 at 08:36, Neil Armstrong  wrote:
> As discussed at [1], the Amlogic Meson GX SoCs can embed a BL31 firmware
> and a secondary BL32 firmware.
> Since mid-2017, the reserved memory address of the BL31 firmware was moved
> and grown for security reasons.
>
> But mainline U-boot and Linux has the old address and size fixed.

U-Boot

>
> These SoCs have a register interface to get the two firmware reserved
> memory start and sizes.
>
> This patch adds a dynamic reservation of the memory zones in the device tree 
> bootmem
> reserved memory zone used by the kernel in early boot.
> To be complete, the memory zones are also added to the EFI reserved zones.
>
> Depends on patchset "Add support for Amlogic GXL Based SBCs" at [2].
>
> [1] 
> http://lists.infradead.org/pipermail/linux-amlogic/2017-October/004860.html
> [2] 
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005410.html
>
> Changes since RFC v2:
> - reduced preprocessor load
> - kept Odroid-C2 static memory mapping as exception
>
> Changes since RFC v1:
> - switch to fdt rsv mem table and efi reserve memory
> - replaced in_le32 by readl()
>
> Signed-off-by: Neil Armstrong 
> ---
>  arch/arm/include/asm/arch-meson/gxbb.h| 17 +++
>  arch/arm/mach-meson/board.c   | 74 
> +++
>  board/amlogic/khadas-vim/khadas-vim.c |  7 +++
>  board/amlogic/libretech-cc/libretech-cc.c |  7 +++
>  board/amlogic/odroid-c2/odroid-c2.c   |  7 +++
>  board/amlogic/p212/p212.c |  7 +++
>  configs/khadas-vim_defconfig  |  1 +
>  configs/libretech-cc_defconfig|  1 +
>  configs/odroid-c2_defconfig   |  1 +
>  configs/p212_defconfig|  1 +
>  include/configs/meson-gxbb-common.h   |  2 +-
>  11 files changed, 116 insertions(+), 9 deletions(-)

Reviewed-by: Simon Glass 

Various nits/suggestions below.

>
> diff --git a/arch/arm/include/asm/arch-meson/gxbb.h 
> b/arch/arm/include/asm/arch-meson/gxbb.h
> index 74d5290..117f796 100644
> --- a/arch/arm/include/asm/arch-meson/gxbb.h
> +++ b/arch/arm/include/asm/arch-meson/gxbb.h
> @@ -7,10 +7,27 @@
>  #ifndef __GXBB_H__
>  #define __GXBB_H__
>
> +#define GXBB_FIRMWARE_MEM_SIZE 0x100
> +
> +#define GXBB_AOBUS_BASE0xc810

Does this not come from the device tree?

>  #define GXBB_PERIPHS_BASE  0xc8834400
>  #define GXBB_HIU_BASE  0xc883c000
>  #define GXBB_ETH_BASE  0xc941
>
> +/* Always-On Peripherals registers */
> +#define GXBB_AO_ADDR(off)  (GXBB_AOBUS_BASE + ((off) << 2))
> +
> +#define GXBB_AO_SEC_GP_CFG0GXBB_AO_ADDR(0x90)
> +#define GXBB_AO_SEC_GP_CFG3GXBB_AO_ADDR(0x93)
> +#define GXBB_AO_SEC_GP_CFG4GXBB_AO_ADDR(0x94)
> +#define GXBB_AO_SEC_GP_CFG5GXBB_AO_ADDR(0x95)
> +
> +#define GXBB_AO_MEM_SIZE_MASK  0x
> +#define GXBB_AO_MEM_SIZE_SHIFT 16
> +#define GXBB_AO_BL31_RSVMEM_SIZE_MASK  0x
> +#define GXBB_AO_BL31_RSVMEM_SIZE_SHIFT 16
> +#define GXBB_AO_BL32_RSVMEM_SIZE_MASK  0x
> +
>  /* Peripherals registers */
>  #define GXBB_PERIPHS_ADDR(off) (GXBB_PERIPHS_BASE + ((off) << 2))

Can you use lower-case hex consistently?

Also consider a C struct for this peripheral.

>
> diff --git a/arch/arm/mach-meson/board.c b/arch/arm/mach-meson/board.c
> index e89c6aa..855614a 100644
> --- a/arch/arm/mach-meson/board.c
> +++ b/arch/arm/mach-meson/board.c
> @@ -11,6 +11,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> @@ -34,15 +37,70 @@ int dram_init(void)
> return 0;
>  }
>
> -int dram_init_banksize(void)
> +phys_size_t get_effective_memsize(void)
>  {
> -   /* Reserve first 16 MiB of RAM for firmware */
> -   gd->bd->bi_dram[0].start = 0x100;
> -   gd->bd->bi_dram[0].size  = 0xf00;
> -   /* Reserve 2 MiB for ARM Trusted Firmware (BL31) */
> -   gd->bd->bi_dram[1].start = 0x1000;
> -   gd->bd->bi_dram[1].size  = gd->ram_size - 0x1020;
> -   return 0;
> +   /* Size is reported in MiB, convert it in bytes */
> +   return ((readl(GXBB_AO_SEC_GP_CFG0) & GXBB_AO_MEM_SIZE_MASK)
> +   >> GXBB_AO_MEM_SIZE_SHIFT) * SZ_1M;
> +}
> +
> +static void meson_board_add_reserved_memory(void *fdt, u64 start, u64 size)
> +{
> +   int ret;
> +
> +   ret = fdt_add_mem_rsv(fdt, start, size);
> +   if (ret)
> +   printf("Could not reserve zone @ 0x%llx\n", start);
> +
> +#if defined(CONFIG_EFI_LOADER)

If it possible to do:

if (IS_ENABLED(CONFIG_EFI_LOADER)) {
...

That way we don't introduce a new code path for the build.


> +   efi_add_memory_map(start, ALIGN(size, EFI_PAGE_SIZE) >> 
> EFI_PAGE_SHIFT,
> +  EFI_RESERVED_MEMORY_TYPE, false);
> +#endif
> +}
> +
> +void ft_cpu_setup(void *fdt, bd_t *bd)

I know this is a standard name, but I 

Re: [U-Boot] Please pull u-boot-dm

2017-11-24 Thread Tom Rini
On Thu, Nov 23, 2017 at 06:48:52PM -0700, Simon Glass wrote:

> Hi Tom,
> 
> Happy Thanksgiving. Herewith some test fix-ups.
> 
> After this I have some patches to enable these tests with 'make
> tests'. But I'm a little nervous about it. One of them needs Python
> code coverage tools which not everyone will have. So I'll take those
> separately after I've tried with travis-cl.
> 
> https://travis-ci.org/sglass68/u-boot/builds/306101351
> 
> 
> The following changes since commit 16fa2eb95172e63820ee5f3d4052f3362a6de84e:
> 
>   ARM: dra7: Kconfig: Add thermal configs for dra7xx and am57xx
> (2017-11-21 08:03:39 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-dm.git
> 
> for you to fetch changes up to 9677faa34ee81c7abb4c08b0dc4ce4aace5473fc:
> 
>   binman: Return non-zero exit code on test failure (2017-11-22 18:05:38 
> -0700)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] Please pull ARC changes

2017-11-24 Thread Tom Rini
On Fri, Nov 24, 2017 at 04:39:15PM +, Alexey Brodkin wrote:

> Hi Tom,
> 
> Could you please pull a couple of fixes and improvements for ARC?
> Among them 2 trivial fixes and addition of GPIO controller for ARC HSDK board.
> 
> The following changes since commit d9d76023ea0d567b0630e85d1bef67b5b1a788d3:
> 
>   Merge git://git.denx.de/u-boot-rockchip (2017-11-22 07:28:58 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-arc.git 
> 
> for you to fetch changes up to f2a226780fa0e4055bec636b8108bf7e80951174:
> 
>   arc: cache: Add required NOPs after invalidation of instruction cache 
> (2017-11-24 19:38:23 +0300)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


[U-Boot] [PATCH 1/1] distro bootcmd: define bootloader name for x86

2017-11-24 Thread Heinrich Schuchardt
Currently X86 does not properly support distro defaults.
This patch is only a partial fix.

It provides the name of the bootloader EFI application
for the X86 architecture.

The architecture dependent file names are defined in the UEFI
specification.

Signed-off-by: Heinrich Schuchardt 
---
 include/config_distro_bootcmd.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index e0d0034ed3..eb2bdfa39d 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -91,6 +91,10 @@
 #define BOOTEFI_NAME "bootaa64.efi"
 #elif defined(CONFIG_ARM)
 #define BOOTEFI_NAME "bootarm.efi"
+#elif defined(CONFIG_X86_RUN_32BIT)
+#define BOOTEFI_NAME "bootia32.efi"
+#elif defined(CONFIG_X86_RUN_64BIT)
+#define BOOTEFI_NAME "bootx64.efi"
 #endif
 #endif
 
-- 
2.15.0

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


Re: [U-Boot] sun50i blocking SPL changes

2017-11-24 Thread Dr. Philipp Tomsich

> On 24 Nov 2017, at 21:36, Jagan Teki  wrote:
> 
> On Sat, Nov 25, 2017 at 1:17 AM, Dr. Philipp Tomsich
>  wrote:
>> Jagan, Maxime & Tom,
>> 
>> I have a couple of changes to spl_fit.c queued that we need to get merged to 
>> fix some issues for ATF support on Rockchip platforms.
> 
> Does all rk64 has enough SPL size's to fit?

The 64bit Rockchip platforms either have more than enough SRAM (i.e. the 
RK3399) or are already using a TPL w/ SPL executing in DRAM.
So the only failures I get are sun50i and sun50i_h3 platforms.

> 
>> However, due to internal alignment before the ARMv8 vectors, this breaks the 
>> sun50i builds (all exceeding their SPL size by up to approx. 1KB), even 
>> though I am adding only about a 100 bytes to the size of spl_fit.c.
> 
> Yes, as per as my trails[1] it's not possible to increase SPL size.

That is why I was suggesting to remove exceptions for sun50i for the time 
being, as the alignment for the vectors is more than 1kB in binary size.

>> The change that triggers this is:
>>https://patchwork.ozlabs.org/patch/813598/
>> 
>> However, the root cause lies in the “.align 11” in exceptions.c, which 
>> generates a ‘*fill*’ similar to this one (and we have been lucky enough that 
>> this came out as a rather small number up until me increasing the size of 
>> spl_fit.o):
>> *fill* 0x00011214  0x5ec
>> .text.vectors  0x00011800  0x838 
>> arch/arm/cpu/armv8/built-in.o
>> 
>> The quickest way to resolve would be to drop support for exception vectors 
>> on sun50i.
> 
> Don't we miss the exceptions during SPL?
> 
>> Any other suggestions are also welcome.
> 
> I would rather think to implement TPL provided if there is no option
> to increase the SPL size instead of missing exception vectors.

Someone will have to do this eventually, as the sun50i platforms are becoming 
an issue for other platforms now.

> 
> [1] https://patchwork.ozlabs.org/patch/835973/
> 
> thanks!
> -- 
> Jagan Teki
> Senior Linux Kernel Engineer | Amarula Solutions
> U-Boot, Linux | Upstream Maintainer
> Hyderabad, India.

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


Re: [U-Boot] sun50i blocking SPL changes

2017-11-24 Thread Jagan Teki
On Sat, Nov 25, 2017 at 2:06 AM, Jagan Teki  wrote:
> On Sat, Nov 25, 2017 at 1:17 AM, Dr. Philipp Tomsich
>  wrote:
>> Jagan, Maxime & Tom,
>>
>> I have a couple of changes to spl_fit.c queued that we need to get merged to 
>> fix some issues for ATF support on Rockchip platforms.
>
> Does all rk64 has enough SPL size's to fit?
>
>> However, due to internal alignment before the ARMv8 vectors, this breaks the 
>> sun50i builds (all exceeding their SPL size by up to approx. 1KB), even 
>> though I am adding only about a 100 bytes to the size of spl_fit.c.
>
> Yes, as per as my trails[1] it's not possible to increase SPL size.
>
>>
>> The change that triggers this is:
>> https://patchwork.ozlabs.org/patch/813598/
>>
>> However, the root cause lies in the “.align 11” in exceptions.c, which 
>> generates a ‘*fill*’ similar to this one (and we have been lucky enough that 
>> this came out as a rather small number up until me increasing the size of 
>> spl_fit.o):
>>  *fill* 0x00011214  0x5ec
>>  .text.vectors  0x00011800  0x838 
>> arch/arm/cpu/armv8/built-in.o
>>
>> The quickest way to resolve would be to drop support for exception vectors 
>> on sun50i.
>
> Don't we miss the exceptions during SPL?
>
>> Any other suggestions are also welcome.
>
> I would rather think to implement TPL provided if there is no option
> to increase the SPL size instead of missing exception vectors.
>
> [1] https://patchwork.ozlabs.org/patch/835973/

+ Andre
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] sun50i blocking SPL changes

2017-11-24 Thread Jagan Teki
On Sat, Nov 25, 2017 at 1:17 AM, Dr. Philipp Tomsich
 wrote:
> Jagan, Maxime & Tom,
>
> I have a couple of changes to spl_fit.c queued that we need to get merged to 
> fix some issues for ATF support on Rockchip platforms.

Does all rk64 has enough SPL size's to fit?

> However, due to internal alignment before the ARMv8 vectors, this breaks the 
> sun50i builds (all exceeding their SPL size by up to approx. 1KB), even 
> though I am adding only about a 100 bytes to the size of spl_fit.c.

Yes, as per as my trails[1] it's not possible to increase SPL size.

>
> The change that triggers this is:
> https://patchwork.ozlabs.org/patch/813598/
>
> However, the root cause lies in the “.align 11” in exceptions.c, which 
> generates a ‘*fill*’ similar to this one (and we have been lucky enough that 
> this came out as a rather small number up until me increasing the size of 
> spl_fit.o):
>  *fill* 0x00011214  0x5ec
>  .text.vectors  0x00011800  0x838 
> arch/arm/cpu/armv8/built-in.o
>
> The quickest way to resolve would be to drop support for exception vectors on 
> sun50i.

Don't we miss the exceptions during SPL?

> Any other suggestions are also welcome.

I would rather think to implement TPL provided if there is no option
to increase the SPL size instead of missing exception vectors.

[1] https://patchwork.ozlabs.org/patch/835973/

thanks!
-- 
Jagan Teki
Senior Linux Kernel Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] sun50i blocking SPL changes

2017-11-24 Thread Dr. Philipp Tomsich
Jagan, Maxime & Tom,

I have a couple of changes to spl_fit.c queued that we need to get merged to 
fix some issues for ATF support on Rockchip platforms.
However, due to internal alignment before the ARMv8 vectors, this breaks the 
sun50i builds (all exceeding their SPL size by up to approx. 1KB), even though 
I am adding only about a 100 bytes to the size of spl_fit.c.

The change that triggers this is:
https://patchwork.ozlabs.org/patch/813598/

However, the root cause lies in the “.align 11” in exceptions.c, which 
generates a ‘*fill*’ similar to this one (and we have been lucky enough that 
this came out as a rather small number up until me increasing the size of 
spl_fit.o):
 *fill* 0x00011214  0x5ec 
 .text.vectors  0x00011800  0x838 
arch/arm/cpu/armv8/built-in.o

The quickest way to resolve would be to drop support for exception vectors on 
sun50i.
Any other suggestions are also welcome.

Regards,
Philipp.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] dm: reset: have the reset-command perform a COLD reset

2017-11-24 Thread Philipp Tomsich
The DM version of do_reset has been issuing a warm-reset, which (on
some platforms keeps GPIOs and other parts of the platform active).
This may cause unintended behaviour, as calling do_reset usually
indicates a desire to reset the board/platform and not just the CPU.

This changes do_reset to always request a COLD reset.
Note that programmatic uses can still invoke a WARM reset through
reset_cpu() or using sysreset_walk().

Signed-off-by: Philipp Tomsich 
---

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

diff --git a/drivers/sysreset/sysreset-uclass.c 
b/drivers/sysreset/sysreset-uclass.c
index 3566d17..0747c52 100644
--- a/drivers/sysreset/sysreset-uclass.c
+++ b/drivers/sysreset/sysreset-uclass.c
@@ -70,7 +70,7 @@ void reset_cpu(ulong addr)
 
 int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
-   sysreset_walk_halt(SYSRESET_WARM);
+   sysreset_walk_halt(SYSRESET_COLD);
 
return 0;
 }
-- 
2.1.4

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


[U-Boot] Please pull ARC changes

2017-11-24 Thread Alexey Brodkin
Hi Tom,

Could you please pull a couple of fixes and improvements for ARC?
Among them 2 trivial fixes and addition of GPIO controller for ARC HSDK board.

The following changes since commit d9d76023ea0d567b0630e85d1bef67b5b1a788d3:

  Merge git://git.denx.de/u-boot-rockchip (2017-11-22 07:28:58 -0500)

are available in the git repository at:

  git://git.denx.de/u-boot-arc.git 

for you to fetch changes up to f2a226780fa0e4055bec636b8108bf7e80951174:

  arc: cache: Add required NOPs after invalidation of instruction cache 
(2017-11-24 19:38:23 +0300)


Alexey Brodkin (2):
  arc: bootm: Move slave cores kick-starting under !fake
  arc: cache: Add required NOPs after invalidation of instruction cache

Eugeniy Paltsev (1):
  ARC: HSDK: introduce CREG GPIO driver

 MAINTAINERS   |   6 ++
 arch/arc/lib/bootm.c  |   8 
 arch/arc/lib/cache.c  |   7 +++
 drivers/gpio/Kconfig  |   7 +++
 drivers/gpio/Makefile |   1 +
 drivers/gpio/hsdk-creg-gpio.c | 110 
++
 6 files changed, 135 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpio/hsdk-creg-gpio.c

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


Re: [U-Boot] Intel Edison build warning

2017-11-24 Thread Andy Shevchenko
On Fri, 2017-11-24 at 17:42 +0200, Andy Shevchenko wrote:
> On Fri, 2017-11-24 at 16:06 +0800, Bin Meng wrote:
> > Hi,
> > 
> > Intel Edison has a build warning below.
> > 
> > +  *env_addr = offset;
> > +^
> > w+../env/mmc.c: In function 'mmc_get_env_addr':
> > w+../env/mmc.c:121:12: warning: 'val' may be used uninitialized in
> > this function [-Wmaybe-uninitialized]
> > 
> > I did not figure out what is wrong here. v2017.11 does not have such
> > build warning.
> > 
> > Do you have any idea?

Somewhat compiler goes crazy?

I have a theory that instead of showing actual potential issues (which
are bogus anyway) it complains on __weak function instead.

The real complains might be env_mmc_load() / env_mmc_save() where
offset* is uninitialized indeed.

-- 
Andy Shevchenko 
Intel Finland Oy
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Intel Edison build warning

2017-11-24 Thread Andy Shevchenko
On Fri, 2017-11-24 at 16:06 +0800, Bin Meng wrote:
> Hi,
> 
> Intel Edison has a build warning below.
> 
> +  *env_addr = offset;
> +^
> w+../env/mmc.c: In function 'mmc_get_env_addr':
> w+../env/mmc.c:121:12: warning: 'val' may be used uninitialized in
> this function [-Wmaybe-uninitialized]
> 
> I did not figure out what is wrong here. v2017.11 does not have such
> build warning.
> 
> Do you have any idea?

I can't reproduce.

What I did:

% git remote update -p
Fetching origin

% git checkout origin/master

% git clean -xdf

% make W=2 edison_defconfig

% make W=2 -j1

% touch env/mmc.c

% make W=2 -j1

No warnings WRT env/mmc.c at all.

% gcc --version

gcc (Debian 7.2.0-16) 7.2.0

-- 
Andy Shevchenko 
Intel Finland Oy
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 5/5] ARM: dts: uniphier: Sync with Linux 4.15-rc1

2017-11-24 Thread Masahiro Yamada
Signed-off-by: Masahiro Yamada 
---

 arch/arm/dts/uniphier-ld11-ref.dts  | 10 +++-
 arch/arm/dts/uniphier-ld11.dtsi | 50 +--
 arch/arm/dts/uniphier-ld20-ref.dts  | 10 +++-
 arch/arm/dts/uniphier-ld20.dtsi | 87 -
 arch/arm/dts/uniphier-ld4-ref.dts   | 10 +++-
 arch/arm/dts/uniphier-ld4.dtsi  | 23 +++--
 arch/arm/dts/uniphier-ld6b-ref.dts  | 10 +++-
 arch/arm/dts/uniphier-pinctrl.dtsi  | 52 ++--
 arch/arm/dts/uniphier-pro4-ref.dts  | 10 +++-
 arch/arm/dts/uniphier-pro4.dtsi | 22 +++--
 arch/arm/dts/uniphier-pro5.dtsi | 16 +-
 arch/arm/dts/uniphier-pxs2.dtsi | 66 ++---
 arch/arm/dts/uniphier-pxs3-ref.dts  | 10 +++-
 arch/arm/dts/uniphier-pxs3.dtsi | 42 +++-
 arch/arm/dts/uniphier-sld8-ref.dts  | 10 +++-
 arch/arm/dts/uniphier-sld8.dtsi | 23 +++--
 arch/arm/dts/uniphier-support-card.dtsi |  3 +-
 arch/arm/dts/uniphier-v7-u-boot.dtsi|  8 +--
 arch/arm/mach-uniphier/sbc/sbc-ld11.c   |  2 +-
 arch/arm/mach-uniphier/sbc/sbc-pxs2.c   |  2 +-
 20 files changed, 400 insertions(+), 66 deletions(-)

diff --git a/arch/arm/dts/uniphier-ld11-ref.dts 
b/arch/arm/dts/uniphier-ld11-ref.dts
index ffb473a..54c5317 100644
--- a/arch/arm/dts/uniphier-ld11-ref.dts
+++ b/arch/arm/dts/uniphier-ld11-ref.dts
@@ -40,13 +40,21 @@
 };
 
  {
-   interrupts = <0 48 4>;
+   interrupts = <0 8>;
 };
 
  {
status = "okay";
 };
 
+ {
+   xirq0 {
+   gpio-hog;
+   gpios = ;
+   input;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm/dts/uniphier-ld11.dtsi b/arch/arm/dts/uniphier-ld11.dtsi
index cf079b9..40f27bb 100644
--- a/arch/arm/dts/uniphier-ld11.dtsi
+++ b/arch/arm/dts/uniphier-ld11.dtsi
@@ -7,6 +7,9 @@
  * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
  */
 
+#include 
+#include 
+
 /memreserve/ 0x8000 0x0200;
 
 / {
@@ -49,7 +52,7 @@
};
};
 
-   cluster0_opp: opp_table {
+   cluster0_opp: opp-table {
compatible = "operating-points-v2";
opp-shared;
 
@@ -96,6 +99,11 @@
};
};
 
+   emmc_pwrseq: emmc-pwrseq {
+   compatible = "mmc-pwrseq-emmc";
+   reset-gpios = < UNIPHIER_GPIO_PORT(3, 2) GPIO_ACTIVE_LOW>;
+   };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <1 13 4>,
@@ -119,6 +127,7 @@
pinctrl-0 = <_uart0>;
clocks = <_clk 0>;
clock-frequency = <5882>;
+   resets = <_rst 0>;
};
 
serial1: serial@54006900 {
@@ -130,6 +139,7 @@
pinctrl-0 = <_uart1>;
clocks = <_clk 1>;
clock-frequency = <5882>;
+   resets = <_rst 1>;
};
 
serial2: serial@54006a00 {
@@ -141,6 +151,7 @@
pinctrl-0 = <_uart2>;
clocks = <_clk 2>;
clock-frequency = <5882>;
+   resets = <_rst 2>;
};
 
serial3: serial@54006b00 {
@@ -152,6 +163,7 @@
pinctrl-0 = <_uart3>;
clocks = <_clk 3>;
clock-frequency = <5882>;
+   resets = <_rst 3>;
};
 
gpio: gpio@5500 {
@@ -200,6 +212,7 @@
pinctrl-names = "default";
pinctrl-0 = <_i2c0>;
clocks = <_clk 4>;
+   resets = <_rst 4>;
clock-frequency = <10>;
};
 
@@ -213,6 +226,7 @@
pinctrl-names = "default";
pinctrl-0 = <_i2c1>;
clocks = <_clk 5>;
+   resets = <_rst 5>;
clock-frequency = <10>;
};
 
@@ -223,6 +237,7 @@
#size-cells = <0>;
interrupts = <0 43 4>;
clocks = <_clk 6>;
+   resets = <_rst 6>;
clock-frequency = <40>;
};
 
@@ -236,6 +251,7 @@
pinctrl-names = "default";
pinctrl-0 = <_i2c3>;
clocks = <_clk 7>;
+   resets = <_rst 7>;
clock-frequency = <10>;
};
 
@@ -249,6 +265,7 @@
pinctrl-names = "default";
pinctrl-0 = <_i2c4>;
clocks = <_clk 8>;
+   resets = <_rst 8>;

[U-Boot] [PATCH 2/5] ARM: uniphier: remove IRQ settings

2017-11-24 Thread Masahiro Yamada
This work-around has been here in U-Boot because the AIDET and GPIO
drivers were missing in the upstream Linux.  Both are now available
in Linus' tree:
  - drivers/irqchip/irq-uniphier-aidet.c
  - drivers/gpio/gpio-uniphier.c

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/board_init.c | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/arch/arm/mach-uniphier/board_init.c 
b/arch/arm/mach-uniphier/board_init.c
index a6ee22e..28784ea 100644
--- a/arch/arm/mach-uniphier/board_init.c
+++ b/arch/arm/mach-uniphier/board_init.c
@@ -17,37 +17,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-static void uniphier_setup_xirq(void)
-{
-   const void *fdt = gd->fdt_blob;
-   int soc_node, aidet_node;
-   const fdt32_t *val;
-   unsigned long aidet_base;
-   u32 tmp;
-
-   soc_node = fdt_path_offset(fdt, "/soc");
-   if (soc_node < 0)
-   return;
-
-   aidet_node = fdt_subnode_offset_namelen(fdt, soc_node, "aidet", 5);
-   if (aidet_node < 0)
-   return;
-
-   val = fdt_getprop(fdt, aidet_node, "reg", NULL);
-   if (!val)
-   return;
-
-   aidet_base = fdt32_to_cpu(*val);
-
-   tmp = readl(aidet_base + 8);/* AIDET DETCONFR2 */
-   tmp |= 0x00ff;  /* Set XIRQ0-7 low active */
-   writel(tmp, aidet_base + 8);
-
-   tmp = readl(0x5590);/* IRQCTL */
-   tmp |= 0x00ff;
-   writel(tmp, 0x5590);
-}
-
 #ifdef CONFIG_ARCH_UNIPHIER_LD11
 static void uniphier_ld11_misc_init(void)
 {
@@ -192,10 +161,6 @@ int board_init(void)
 
led_puts("U3");
 
-   uniphier_setup_xirq();
-
-   led_puts("U4");
-
support_card_late_init();
 
led_puts("Uboo");
-- 
2.7.4

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


[U-Boot] [PATCH 4/5] gpio: uniphier: import dt-binginds header from Linux

2017-11-24 Thread Masahiro Yamada
Signed-off-by: Masahiro Yamada 
---

 drivers/gpio/gpio-uniphier.c |  3 +--
 include/dt-bindings/gpio/uniphier-gpio.h | 18 ++
 2 files changed, 19 insertions(+), 2 deletions(-)
 create mode 100644 include/dt-bindings/gpio/uniphier-gpio.h

diff --git a/drivers/gpio/gpio-uniphier.c b/drivers/gpio/gpio-uniphier.c
index 107c3fc..8d72ab8 100644
--- a/drivers/gpio/gpio-uniphier.c
+++ b/drivers/gpio/gpio-uniphier.c
@@ -13,8 +13,7 @@
 #include 
 #include 
 #include 
-
-#define UNIPHIER_GPIO_LINES_PER_BANK   8
+#include 
 
 #define UNIPHIER_GPIO_PORT_DATA0x0 /* data */
 #define UNIPHIER_GPIO_PORT_DIR 0x4 /* direction (1:in, 0:out) */
diff --git a/include/dt-bindings/gpio/uniphier-gpio.h 
b/include/dt-bindings/gpio/uniphier-gpio.h
new file mode 100644
index 000..9f0ad17
--- /dev/null
+++ b/include/dt-bindings/gpio/uniphier-gpio.h
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) 2017 Socionext Inc.
+ *   Author: Masahiro Yamada 
+ */
+
+#ifndef _DT_BINDINGS_GPIO_UNIPHIER_H
+#define _DT_BINDINGS_GPIO_UNIPHIER_H
+
+#define UNIPHIER_GPIO_LINES_PER_BANK   8
+
+#define UNIPHIER_GPIO_IRQ_OFFSET   ((UNIPHIER_GPIO_LINES_PER_BANK) * 15)
+
+#define UNIPHIER_GPIO_PORT(bank, line) \
+   ((UNIPHIER_GPIO_LINES_PER_BANK) * (bank) + (line))
+
+#define UNIPHIER_GPIO_IRQ(n)   ((UNIPHIER_GPIO_IRQ_OFFSET) + (n))
+
+#endif /* _DT_BINDINGS_GPIO_UNIPHIER_H */
-- 
2.7.4

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


[U-Boot] [PATCH 0/5] ARM: uniphier: UniPhier updates for v2018.01-rc1

2017-11-24 Thread Masahiro Yamada



Masahiro Yamada (5):
  ARM: uniphier: set CONFIG_LOGLEVEL to 6
  ARM: uniphier: remove IRQ settings
  ARM: uniphier: remove XIRQ pin settings
  gpio: uniphier: import dt-binginds header from Linux
  ARM: dts: uniphier: Sync with Linux 4.15-rc1

 arch/arm/dts/uniphier-ld11-ref.dts   | 10 +++-
 arch/arm/dts/uniphier-ld11.dtsi  | 50 --
 arch/arm/dts/uniphier-ld20-ref.dts   | 10 +++-
 arch/arm/dts/uniphier-ld20.dtsi  | 87 +++-
 arch/arm/dts/uniphier-ld4-ref.dts| 10 +++-
 arch/arm/dts/uniphier-ld4.dtsi   | 23 +++--
 arch/arm/dts/uniphier-ld6b-ref.dts   | 10 +++-
 arch/arm/dts/uniphier-pinctrl.dtsi   | 52 +--
 arch/arm/dts/uniphier-pro4-ref.dts   | 10 +++-
 arch/arm/dts/uniphier-pro4.dtsi  | 22 ++--
 arch/arm/dts/uniphier-pro5.dtsi  | 16 +-
 arch/arm/dts/uniphier-pxs2.dtsi  | 66 +---
 arch/arm/dts/uniphier-pxs3-ref.dts   | 10 +++-
 arch/arm/dts/uniphier-pxs3.dtsi  | 42 ++-
 arch/arm/dts/uniphier-sld8-ref.dts   | 10 +++-
 arch/arm/dts/uniphier-sld8.dtsi  | 23 +++--
 arch/arm/dts/uniphier-support-card.dtsi  |  3 +-
 arch/arm/dts/uniphier-v7-u-boot.dtsi |  8 +--
 arch/arm/mach-uniphier/board_init.c  | 51 ---
 arch/arm/mach-uniphier/sbc/sbc-ld11.c|  2 +-
 arch/arm/mach-uniphier/sbc/sbc-pxs2.c|  2 +-
 configs/uniphier_ld4_sld8_defconfig  |  1 +
 configs/uniphier_v7_defconfig|  1 +
 configs/uniphier_v8_defconfig|  1 +
 drivers/gpio/gpio-uniphier.c |  3 +-
 include/dt-bindings/gpio/uniphier-gpio.h | 18 +++
 26 files changed, 422 insertions(+), 119 deletions(-)
 create mode 100644 include/dt-bindings/gpio/uniphier-gpio.h

-- 
2.7.4

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


[U-Boot] [PATCH 3/5] ARM: uniphier: remove XIRQ pin settings

2017-11-24 Thread Masahiro Yamada
The XIRQ pins are now set up on the Linux side by the GPIO hogging.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/board_init.c | 16 
 1 file changed, 16 deletions(-)

diff --git a/arch/arm/mach-uniphier/board_init.c 
b/arch/arm/mach-uniphier/board_init.c
index 28784ea..121b786 100644
--- a/arch/arm/mach-uniphier/board_init.c
+++ b/arch/arm/mach-uniphier/board_init.c
@@ -17,24 +17,9 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#ifdef CONFIG_ARCH_UNIPHIER_LD11
-static void uniphier_ld11_misc_init(void)
-{
-   sg_set_pinsel(149, 14, 8, 4);   /* XIRQ0-> XIRQ0 */
-   sg_set_iectrl(149);
-   sg_set_pinsel(153, 14, 8, 4);   /* XIRQ4-> XIRQ4 */
-   sg_set_iectrl(153);
-}
-#endif
-
 #ifdef CONFIG_ARCH_UNIPHIER_LD20
 static void uniphier_ld20_misc_init(void)
 {
-   sg_set_pinsel(149, 14, 8, 4);   /* XIRQ0-> XIRQ0 */
-   sg_set_iectrl(149);
-   sg_set_pinsel(153, 14, 8, 4);   /* XIRQ4-> XIRQ4 */
-   sg_set_iectrl(153);
-
/* ES1 errata: increase VDD09 supply to suppress VBO noise */
if (uniphier_get_soc_revision() == 1) {
writel(0x0003, 0x6184e004);
@@ -105,7 +90,6 @@ static const struct uniphier_initdata uniphier_initdata[] = {
.sbc_init = uniphier_ld11_sbc_init,
.pll_init = uniphier_ld11_pll_init,
.clk_init = uniphier_ld11_clk_init,
-   .misc_init = uniphier_ld11_misc_init,
},
 #endif
 #if defined(CONFIG_ARCH_UNIPHIER_LD20)
-- 
2.7.4

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


[U-Boot] [PATCH 1/5] ARM: uniphier: set CONFIG_LOGLEVEL to 6

2017-11-24 Thread Masahiro Yamada
Print out KERN_NOTICE or higher level log messages.

Signed-off-by: Masahiro Yamada 
---

 configs/uniphier_ld4_sld8_defconfig | 1 +
 configs/uniphier_v7_defconfig   | 1 +
 configs/uniphier_v8_defconfig   | 1 +
 3 files changed, 3 insertions(+)

diff --git a/configs/uniphier_ld4_sld8_defconfig 
b/configs/uniphier_ld4_sld8_defconfig
index 3a991d7..542cebd 100644
--- a/configs/uniphier_ld4_sld8_defconfig
+++ b/configs/uniphier_ld4_sld8_defconfig
@@ -9,6 +9,7 @@ CONFIG_ARCH_UNIPHIER_LD4_SLD8=y
 CONFIG_MICRO_SUPPORT_CARD=y
 CONFIG_DEFAULT_DEVICE_TREE="uniphier-ld4-ref"
 # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
+CONFIG_LOGLEVEL=6
 CONFIG_SPL=y
 CONFIG_SPL_NOR_SUPPORT=y
 CONFIG_HUSH_PARSER=y
diff --git a/configs/uniphier_v7_defconfig b/configs/uniphier_v7_defconfig
index b4b54c0..9082ba5 100644
--- a/configs/uniphier_v7_defconfig
+++ b/configs/uniphier_v7_defconfig
@@ -8,6 +8,7 @@ CONFIG_SPL_NAND_SUPPORT=y
 CONFIG_MICRO_SUPPORT_CARD=y
 CONFIG_DEFAULT_DEVICE_TREE="uniphier-pxs2-vodka"
 # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
+CONFIG_LOGLEVEL=6
 CONFIG_SPL=y
 CONFIG_SPL_NOR_SUPPORT=y
 CONFIG_HUSH_PARSER=y
diff --git a/configs/uniphier_v8_defconfig b/configs/uniphier_v8_defconfig
index bc4bbbf..746e451 100644
--- a/configs/uniphier_v8_defconfig
+++ b/configs/uniphier_v8_defconfig
@@ -7,6 +7,7 @@ CONFIG_ARCH_UNIPHIER_V8_MULTI=y
 CONFIG_MICRO_SUPPORT_CARD=y
 CONFIG_DEFAULT_DEVICE_TREE="uniphier-ld20-ref"
 # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
+CONFIG_LOGLEVEL=6
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_CONFIG=y
 CONFIG_CMD_IMLS=y
-- 
2.7.4

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


[U-Boot] [PATCH 1/5] ARM: uniphier: set CONFIG_LOGLEVEL to 6

2017-11-24 Thread Masahiro Yamada
Print out KERN_NOTICE or higher level log messages.

Signed-off-by: Masahiro Yamada 
---

 configs/uniphier_ld4_sld8_defconfig | 1 +
 configs/uniphier_v7_defconfig   | 1 +
 configs/uniphier_v8_defconfig   | 1 +
 3 files changed, 3 insertions(+)

diff --git a/configs/uniphier_ld4_sld8_defconfig 
b/configs/uniphier_ld4_sld8_defconfig
index 3a991d7..542cebd 100644
--- a/configs/uniphier_ld4_sld8_defconfig
+++ b/configs/uniphier_ld4_sld8_defconfig
@@ -9,6 +9,7 @@ CONFIG_ARCH_UNIPHIER_LD4_SLD8=y
 CONFIG_MICRO_SUPPORT_CARD=y
 CONFIG_DEFAULT_DEVICE_TREE="uniphier-ld4-ref"
 # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
+CONFIG_LOGLEVEL=6
 CONFIG_SPL=y
 CONFIG_SPL_NOR_SUPPORT=y
 CONFIG_HUSH_PARSER=y
diff --git a/configs/uniphier_v7_defconfig b/configs/uniphier_v7_defconfig
index b4b54c0..9082ba5 100644
--- a/configs/uniphier_v7_defconfig
+++ b/configs/uniphier_v7_defconfig
@@ -8,6 +8,7 @@ CONFIG_SPL_NAND_SUPPORT=y
 CONFIG_MICRO_SUPPORT_CARD=y
 CONFIG_DEFAULT_DEVICE_TREE="uniphier-pxs2-vodka"
 # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
+CONFIG_LOGLEVEL=6
 CONFIG_SPL=y
 CONFIG_SPL_NOR_SUPPORT=y
 CONFIG_HUSH_PARSER=y
diff --git a/configs/uniphier_v8_defconfig b/configs/uniphier_v8_defconfig
index bc4bbbf..746e451 100644
--- a/configs/uniphier_v8_defconfig
+++ b/configs/uniphier_v8_defconfig
@@ -7,6 +7,7 @@ CONFIG_ARCH_UNIPHIER_V8_MULTI=y
 CONFIG_MICRO_SUPPORT_CARD=y
 CONFIG_DEFAULT_DEVICE_TREE="uniphier-ld20-ref"
 # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
+CONFIG_LOGLEVEL=6
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_CONFIG=y
 CONFIG_CMD_IMLS=y
-- 
2.7.4

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


[U-Boot] [PATCH 3/5] ARM: uniphier: remove XIRQ pin settings

2017-11-24 Thread Masahiro Yamada
The XIRQ pins are now set up on the Linux side by the GPIO hogging.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/board_init.c | 16 
 1 file changed, 16 deletions(-)

diff --git a/arch/arm/mach-uniphier/board_init.c 
b/arch/arm/mach-uniphier/board_init.c
index 28784ea..121b786 100644
--- a/arch/arm/mach-uniphier/board_init.c
+++ b/arch/arm/mach-uniphier/board_init.c
@@ -17,24 +17,9 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#ifdef CONFIG_ARCH_UNIPHIER_LD11
-static void uniphier_ld11_misc_init(void)
-{
-   sg_set_pinsel(149, 14, 8, 4);   /* XIRQ0-> XIRQ0 */
-   sg_set_iectrl(149);
-   sg_set_pinsel(153, 14, 8, 4);   /* XIRQ4-> XIRQ4 */
-   sg_set_iectrl(153);
-}
-#endif
-
 #ifdef CONFIG_ARCH_UNIPHIER_LD20
 static void uniphier_ld20_misc_init(void)
 {
-   sg_set_pinsel(149, 14, 8, 4);   /* XIRQ0-> XIRQ0 */
-   sg_set_iectrl(149);
-   sg_set_pinsel(153, 14, 8, 4);   /* XIRQ4-> XIRQ4 */
-   sg_set_iectrl(153);
-
/* ES1 errata: increase VDD09 supply to suppress VBO noise */
if (uniphier_get_soc_revision() == 1) {
writel(0x0003, 0x6184e004);
@@ -105,7 +90,6 @@ static const struct uniphier_initdata uniphier_initdata[] = {
.sbc_init = uniphier_ld11_sbc_init,
.pll_init = uniphier_ld11_pll_init,
.clk_init = uniphier_ld11_clk_init,
-   .misc_init = uniphier_ld11_misc_init,
},
 #endif
 #if defined(CONFIG_ARCH_UNIPHIER_LD20)
-- 
2.7.4

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


[U-Boot] [PATCH 0/5] ARM: uniphier: UniPhier updates for v2018.01-rc1

2017-11-24 Thread Masahiro Yamada


Masahiro Yamada (5):
  ARM: uniphier: set CONFIG_LOGLEVEL to 6
  ARM: uniphier: remove IRQ settings
  ARM: uniphier: remove XIRQ pin settings
  gpio: uniphier: import dt-binginds header from Linux
  ARM: dts: uniphier: Sync with Linux 4.15-rc1

 arch/arm/dts/uniphier-ld11-ref.dts   | 10 +++-
 arch/arm/dts/uniphier-ld11.dtsi  | 50 --
 arch/arm/dts/uniphier-ld20-ref.dts   | 10 +++-
 arch/arm/dts/uniphier-ld20.dtsi  | 87 +++-
 arch/arm/dts/uniphier-ld4-ref.dts| 10 +++-
 arch/arm/dts/uniphier-ld4.dtsi   | 23 +++--
 arch/arm/dts/uniphier-ld6b-ref.dts   | 10 +++-
 arch/arm/dts/uniphier-pinctrl.dtsi   | 52 +--
 arch/arm/dts/uniphier-pro4-ref.dts   | 10 +++-
 arch/arm/dts/uniphier-pro4.dtsi  | 22 ++--
 arch/arm/dts/uniphier-pro5.dtsi  | 16 +-
 arch/arm/dts/uniphier-pxs2.dtsi  | 66 +---
 arch/arm/dts/uniphier-pxs3-ref.dts   | 10 +++-
 arch/arm/dts/uniphier-pxs3.dtsi  | 42 ++-
 arch/arm/dts/uniphier-sld8-ref.dts   | 10 +++-
 arch/arm/dts/uniphier-sld8.dtsi  | 23 +++--
 arch/arm/dts/uniphier-support-card.dtsi  |  3 +-
 arch/arm/dts/uniphier-v7-u-boot.dtsi |  8 +--
 arch/arm/mach-uniphier/board_init.c  | 51 ---
 arch/arm/mach-uniphier/sbc/sbc-ld11.c|  2 +-
 arch/arm/mach-uniphier/sbc/sbc-pxs2.c|  2 +-
 configs/uniphier_ld4_sld8_defconfig  |  1 +
 configs/uniphier_v7_defconfig|  1 +
 configs/uniphier_v8_defconfig|  1 +
 drivers/gpio/gpio-uniphier.c |  3 +-
 include/dt-bindings/gpio/uniphier-gpio.h | 18 +++
 26 files changed, 422 insertions(+), 119 deletions(-)
 create mode 100644 include/dt-bindings/gpio/uniphier-gpio.h

-- 
2.7.4

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


[U-Boot] [PATCH 2/5] ARM: uniphier: remove IRQ settings

2017-11-24 Thread Masahiro Yamada
This work-around has been here in U-Boot because the AIDET and GPIO
drivers were missing in the upstream Linux.  Both are now available
in Linus' tree:
  - drivers/irqchip/irq-uniphier-aidet.c
  - drivers/gpio/gpio-uniphier.c

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/board_init.c | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/arch/arm/mach-uniphier/board_init.c 
b/arch/arm/mach-uniphier/board_init.c
index a6ee22e..28784ea 100644
--- a/arch/arm/mach-uniphier/board_init.c
+++ b/arch/arm/mach-uniphier/board_init.c
@@ -17,37 +17,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-static void uniphier_setup_xirq(void)
-{
-   const void *fdt = gd->fdt_blob;
-   int soc_node, aidet_node;
-   const fdt32_t *val;
-   unsigned long aidet_base;
-   u32 tmp;
-
-   soc_node = fdt_path_offset(fdt, "/soc");
-   if (soc_node < 0)
-   return;
-
-   aidet_node = fdt_subnode_offset_namelen(fdt, soc_node, "aidet", 5);
-   if (aidet_node < 0)
-   return;
-
-   val = fdt_getprop(fdt, aidet_node, "reg", NULL);
-   if (!val)
-   return;
-
-   aidet_base = fdt32_to_cpu(*val);
-
-   tmp = readl(aidet_base + 8);/* AIDET DETCONFR2 */
-   tmp |= 0x00ff;  /* Set XIRQ0-7 low active */
-   writel(tmp, aidet_base + 8);
-
-   tmp = readl(0x5590);/* IRQCTL */
-   tmp |= 0x00ff;
-   writel(tmp, 0x5590);
-}
-
 #ifdef CONFIG_ARCH_UNIPHIER_LD11
 static void uniphier_ld11_misc_init(void)
 {
@@ -192,10 +161,6 @@ int board_init(void)
 
led_puts("U3");
 
-   uniphier_setup_xirq();
-
-   led_puts("U4");
-
support_card_late_init();
 
led_puts("Uboo");
-- 
2.7.4

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


[U-Boot] [PATCH 1/2] rockchip: fix turning off boot-mode via Kconfig

2017-11-24 Thread Philipp Tomsich
The ROCKCHIP_BOOT_MODE_REG option defaults to a hex value, so 0 will
show as 0x0.  Consequently, the "is set to something other than 0" test
in a Makefile needs to be an ifneq($(CONFIG_ROCKCHIP_BOOT_MODE_REG), 0x0).

This commit fixes mach-rockchip/Makefile and also resulting link
issues (if boot_mode.o is not included) by defining a stub function
(in case the functionality is not built in) for setup_boot_mode in
boot_mode.h.

Fixes: e306779 (rockchip: make boot_mode related codes reused across all 
platforms)
Signed-off-by: Philipp Tomsich 
---

 arch/arm/include/asm/arch-rockchip/boot_mode.h | 6 ++
 arch/arm/mach-rockchip/Makefile| 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-rockchip/boot_mode.h 
b/arch/arm/include/asm/arch-rockchip/boot_mode.h
index 6b2a610..f3f62ee 100644
--- a/arch/arm/include/asm/arch-rockchip/boot_mode.h
+++ b/arch/arm/include/asm/arch-rockchip/boot_mode.h
@@ -19,7 +19,13 @@
 #define BOOT_BROM_DOWNLOAD 0xEF08A53C
 
 #ifndef __ASSEMBLY__
+
+#if (CONFIG_ROCKCHIP_BOOT_MODE_REG == 0)
+static inline int setup_boot_mode(void) { return 0; };
+#else
 int setup_boot_mode(void);
 #endif
 
 #endif
+
+#endif
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 2127f2b..051d2a3 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -23,7 +23,7 @@ obj-spl-$(CONFIG_ROCKCHIP_RK3399) += rk3399-board-spl.o 
spl-boot-order.o
 
 ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
 
-ifneq ($(CONFIG_ROCKCHIP_BOOT_MODE_REG),0)
+ifneq ($(CONFIG_ROCKCHIP_BOOT_MODE_REG),0x0)
 obj-y += boot_mode.o
 endif
 
-- 
2.1.4

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


[U-Boot] [PATCH 2/2] rockchip: defconfig: puma-rk3399: bypass ADC-based boot_mode check

2017-11-24 Thread Philipp Tomsich
The boot (and fallback/emergency boot) concept for the RK3399-Q7
differs from Rockchip's reference platforms.

On the RK3399-Q7, some of this functionality is present in the
bootloader itself (and configurable); some is backed in hardware by
the Qseven BIOS_DISABLE signal to invoke the final stages of fallbacks
(i.e. either an external boot bypassing on-module memories or falling
back to the BROM for USB recovery).

In summary: the ADC-based boot_mode check does not apply for the
RK3399-Q7 and we therefore disable it (in this commit) by setting
CONFIG_BOOT_MODE_REG to 0.

Signed-off-by: Philipp Tomsich 
---

 configs/puma-rk3399_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
index ebbf8a9..6d2c615 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -5,6 +5,7 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_SYS_MALLOC_F_LEN=0x4000
 CONFIG_ROCKCHIP_RK3399=y
+CONFIG_ROCKCHIP_BOOT_MODE_REG=0x0
 CONFIG_TARGET_PUMA_RK3399=y
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI_SUPPORT=y
-- 
2.1.4

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


Re: [U-Boot] [PATCH] fat: Use cache aligned buffers for fat_opendir

2017-11-24 Thread Fabio Estevam
Hi Neil,

On Fri, Nov 24, 2017 at 6:54 AM, Neil Armstrong  wrote:
> Before this patch one could receive following errors when executing "fatls"
> command on machine with cache enabled (ex i.MX6Q) :
>
> => fatls mmc 0:1
> CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
> CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
> ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x4f59dfc8
> ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x4f59e7c8
> CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
> CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
> ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x4f59dfc8
> ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x4f59e7c8
>
> To alleviate this problem - the calloc()s have been replaced with
> malloc_cache_aligned() and memset().
>
> After those changes the buffers are properly aligned (with both start
> address and size) to SoC cache line.
>
> Fixes: 09fa964bba80 ("fs/fat: Fix 'CACHE: Misaligned operation at range' 
> warnings")
> Suggested-by: Lukasz Majewski 
> Signed-off-by: Neil Armstrong 

Thanks for the fix:

Reviewed-by: Fabio Estevam 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] arm: mvebu: enable boot from NAND

2017-11-24 Thread Sean Nyekjaer
Check if we are booting from NAND and let the bootrom
continue to load the rest of the bootloader

Signed-off-by: Sean Nyekjaer 
---
 arch/arm/mach-mvebu/include/mach/soc.h |  1 +
 arch/arm/mach-mvebu/spl.c  | 16 ++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-mvebu/include/mach/soc.h 
b/arch/arm/mach-mvebu/include/mach/soc.h
index 4f81285bb5..1a06a1e876 100644
--- a/arch/arm/mach-mvebu/include/mach/soc.h
+++ b/arch/arm/mach-mvebu/include/mach/soc.h
@@ -147,6 +147,7 @@
 #define BOOT_DEV_SEL_OFFS  4
 #define BOOT_DEV_SEL_MASK  (0x3f << BOOT_DEV_SEL_OFFS)
 
+#define BOOT_FROM_NAND 0x0A
 #define BOOT_FROM_UART 0x28
 #define BOOT_FROM_UART_ALT 0x3f
 #define BOOT_FROM_SPI  0x32
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 2fd6c62589..d16a62d2dd 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -45,6 +45,10 @@ static u32 get_boot_device(void)
boot_device = (val & BOOT_DEV_SEL_MASK) >> BOOT_DEV_SEL_OFFS;
debug("SAR_REG=0x%08x boot_device=0x%x\n", val, boot_device);
switch (boot_device) {
+#if defined(CONFIG_ARMADA_38X)
+   case BOOT_FROM_NAND:
+   return BOOT_DEVICE_NAND;
+#endif
 #ifdef CONFIG_SPL_MMC_SUPPORT
case BOOT_FROM_MMC:
case BOOT_FROM_MMC_ALT:
@@ -128,7 +132,15 @@ void board_init_f(ulong dummy)
 * SPL has no chance to receive this information. So we
 * need to return to the BootROM to enable this xmodem
 * UART download.
+*
+* If booting from NAND lets let the BootROM load the
+* rest of the bootloader.
 */
-   if (get_boot_device() == BOOT_DEVICE_UART)
-   return_to_bootrom();
+   switch (get_boot_device()) {
+   case BOOT_DEVICE_UART:
+#if defined(CONFIG_ARMADA_38X)
+   case BOOT_DEVICE_NAND:
+#endif
+   return_to_bootrom();
+   }
 }
-- 
2.15.0

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


[U-Boot] [PATCH] arm: mvebu: fix boot from UART when in fallback mode

2017-11-24 Thread Sean Nyekjaer
It's the first 8 bits of the bootrom error register that
contains the boot error/fallback error code. Lets check that
and continue to boot from UART.

Signed-off-by: Sean Nyekjaer 
---
 arch/arm/mach-mvebu/include/mach/soc.h | 6 ++
 arch/arm/mach-mvebu/spl.c  | 9 +
 2 files changed, 15 insertions(+)

diff --git a/arch/arm/mach-mvebu/include/mach/soc.h 
b/arch/arm/mach-mvebu/include/mach/soc.h
index 1d302761f0..4f81285bb5 100644
--- a/arch/arm/mach-mvebu/include/mach/soc.h
+++ b/arch/arm/mach-mvebu/include/mach/soc.h
@@ -111,10 +111,16 @@
 #define COMPHY_REFCLK_ALIGNMENT(MVEBU_REGISTER(0x182f8))
 
 /* BootROM error register (also includes some status infos) */
+#if defined(CONFIG_ARMADA_38X)
+#define CONFIG_BOOTROM_ERR_REG (MVEBU_REGISTER(0x182d0))
+#define BOOTROM_ERR_MODE_OFFS  0
+#define BOOTROM_ERR_MODE_MASK  (0xf << BOOTROM_ERR_MODE_OFFS)
+#else
 #define CONFIG_BOOTROM_ERR_REG (MVEBU_REGISTER(0x182d0))
 #define BOOTROM_ERR_MODE_OFFS  28
 #define BOOTROM_ERR_MODE_MASK  (0xf << BOOTROM_ERR_MODE_OFFS)
 #define BOOTROM_ERR_MODE_UART  0x6
+#endif
 
 #if defined(CONFIG_ARMADA_375)
 /* SAR values for Armada 375 */
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index a72a769f7c..2fd6c62589 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -26,7 +26,16 @@ static u32 get_boot_device(void)
val = readl(CONFIG_BOOTROM_ERR_REG);
boot_device = (val & BOOTROM_ERR_MODE_MASK) >> BOOTROM_ERR_MODE_OFFS;
debug("BOOTROM_REG=0x%08x boot_device=0x%x\n", val, boot_device);
+#if defined(CONFIG_ARMADA_38X)
+   /*
+* If the bootrom error register contains any else than zeros
+* in the first 8 bits it's an error condition. And in that case
+* try to boot from UART.
+*/
+   if (boot_device)
+#else
if (boot_device == BOOTROM_ERR_MODE_UART)
+#endif
return BOOT_DEVICE_UART;
 
/*
-- 
2.15.0

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


[U-Boot] [PATCH] arm: mvebu: add nand pins

2017-11-24 Thread Sean Nyekjaer
Signed-off-by: Sean Nyekjaer 
---
 arch/arm/dts/armada-38x.dtsi | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/armada-38x.dtsi b/arch/arm/dts/armada-38x.dtsi
index dc8a1a66c1..5e5a158551 100644
--- a/arch/arm/dts/armada-38x.dtsi
+++ b/arch/arm/dts/armada-38x.dtsi
@@ -258,6 +258,19 @@
marvell,function = "i2c0";
};
 
+   nand_pins: nand-pins {
+   marvell,pins = "mpp22", "mpp34", 
"mpp23", "mpp33",
+  "mpp38", "mpp28", 
"mpp40", "mpp42",
+  "mpp35", "mpp36", 
"mpp25", "mpp30",
+  "mpp32";
+   marvell,function = "dev";
+   };
+
+   nand_rb: nand-rb {
+   marvell,pins = "mpp41";
+   marvell,function = "nand";
+   };
+
mdio_pins: mdio-pins {
marvell,pins = "mpp4", "mpp5";
marvell,function = "ge";
@@ -545,7 +558,7 @@
};
 
flash@d {
-   compatible = "marvell,armada370-nand";
+   compatible = 
"marvell,armada370-nand","marvell,mvebu-pxa3xx-nand";
reg = <0xd 0x54>;
#address-cells = <1>;
#size-cells = <1>;
-- 
2.15.0

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


Re: [U-Boot] dm: mmc: fsl_esdhc: Drop mmc_init() call from fsl_esdhc_init()

2017-11-24 Thread Y.b. Lu
Any suggestion?
Thanks.

From: Y.b. Lu
Sent: 2017年11月21日 14:11
To: u-boot@lists.denx.de
Cc: 'Simon Glass' ; Jaehoon Chung ; 
Yinbo Zhu ; Xiaobo Xie 
Subject: dm: mmc: fsl_esdhc: Drop mmc_init() call from fsl_esdhc_init()

Hi Simon,

I found your below patch just dropping mmc_create() for probe procedure of DM.
Actually the description seemed to be not the things this patch did.

dm: mmc: fsl_esdhc: Drop mmc_init() call from fsl_esdhc_init()

Do you have any suggestion to fix it?
mmc_create() will allocate mmc structure and the DM in fsl_esdhc also allocate 
mmc structure in fsl_esdhc_plat structure.
Do we need to rework the mmc_create(), or move rest initialization of 
mmc_create() in to fsl_esdhc_probe() ?

Thanks a lot.

Best regards,
Yangbo Lu

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


Re: [U-Boot] [PATCH v2] x86: lib: Implement standalone __udivdi3 etc instead of libgcc ones

2017-11-24 Thread Stefan Roese

Hi Bin,

On 24.11.2017 09:29, Bin Meng wrote:

On Mon, Nov 20, 2017 at 6:43 PM, Stefan Roese  wrote:

Hi Bin,


On 20.11.2017 08:24, Bin Meng wrote:


On Fri, Nov 17, 2017 at 2:02 PM, Stefan Roese  wrote:


This patch removes the inclusion of the libgcc math functions and
replaces them by functions coded in C, taken from the coreboot
project. This makes U-Boot building more independent from the toolchain
installed / available on the build system.

The code taken from coreboot is authored from Vadim Bendebury
 on 2014-11-28 and committed with commit
ID e63990ef [libpayload: provide basic 64bit division implementation]
(coreboot git repository located here [1]).

I modified the code so that its checkpatch clean without any
functional changes.

[1] git://github.com/coreboot/coreboot.git

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Cc: Bin Meng 
---
v2:
- Added coreboot git repository link to commit message

   arch/x86/config.mk|   3 --
   arch/x86/lib/Makefile |   2 +-
   arch/x86/lib/div64.c  | 113
++
   arch/x86/lib/gcc.c|  29 -
   4 files changed, 114 insertions(+), 33 deletions(-)
   create mode 100644 arch/x86/lib/div64.c
   delete mode 100644 arch/x86/lib/gcc.c

diff --git a/arch/x86/config.mk b/arch/x86/config.mk
index 8835dcf36f..472ada5490 100644
--- a/arch/x86/config.mk
+++ b/arch/x86/config.mk
@@ -34,9 +34,6 @@ PLATFORM_RELFLAGS += -ffunction-sections
-fvisibility=hidden
   PLATFORM_LDFLAGS += -Bsymbolic -Bsymbolic-functions
   PLATFORM_LDFLAGS += -m $(if $(IS_32BIT),elf_i386,elf_x86_64)

-LDFLAGS_FINAL += --wrap=__divdi3 --wrap=__udivdi3
-LDFLAGS_FINAL += --wrap=__moddi3 --wrap=__umoddi3
-
   # This is used in the top-level Makefile which does not include
   # PLATFORM_LDFLAGS
   LDFLAGS_EFI_PAYLOAD := -Bsymbolic -Bsymbolic-functions -shared
--no-undefined
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index fe00d7573f..d9b23f5cc4 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_SEABIOS) += coreboot_table.o
   obj-y  += early_cmos.o
   obj-$(CONFIG_EFI) += efi/
   obj-y  += e820.o
-obj-y  += gcc.o
+obj-y  += div64.o
   obj-y  += init_helpers.o
   obj-y  += interrupts.o
   obj-y  += lpc-uclass.o
diff --git a/arch/x86/lib/div64.c b/arch/x86/lib/div64.c
new file mode 100644
index 00..4efed74037
--- /dev/null
+++ b/arch/x86/lib/div64.c
@@ -0,0 +1,113 @@
+/*
+ * This file is copied from the coreboot repository as part of
+ * the libpayload project:
+ *
+ * Copyright 2014 Google Inc.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
+
+union overlay64 {
+   u64 longw;
+   struct {
+   u32 lower;
+   u32 higher;
+   } words;
+};
+
+u64 __ashldi3(u64 num, unsigned int shift)
+{
+   union overlay64 output;
+
+   output.longw = num;
+   if (shift >= 32) {
+   output.words.higher = output.words.lower << (shift - 32);
+   output.words.lower = 0;
+   } else {
+   if (!shift)
+   return num;
+   output.words.higher = (output.words.higher << shift) |
+   (output.words.lower >> (32 - shift));
+   output.words.lower = output.words.lower << shift;
+   }
+   return output.longw;
+}
+
+u64 __lshrdi3(u64 num, unsigned int shift)
+{
+   union overlay64 output;
+
+   output.longw = num;
+   if (shift >= 32) {
+   output.words.lower = output.words.higher >> (shift - 32);
+   output.words.higher = 0;
+   } else {
+   if (!shift)
+   return num;
+   output.words.lower = output.words.lower >> shift |
+   (output.words.higher << (32 - shift));
+   output.words.higher = output.words.higher >> shift;
+   }
+   return output.longw;
+}
+
+#define MAX_32BIT_UINT u64)1) << 32) - 1)
+
+static u64 _64bit_divide(u64 dividend, u64 divider, u64 *rem_p)
+{
+   u64 result = 0;
+
+   /*
+* If divider is zero - let the rest of the system care about the
+* exception.
+*/
+   if (!divider)
+   return 1 / (u32)divider;
+
+   /* As an optimization, let's not use 64 bit division unless we
must. */
+   if (dividend <= MAX_32BIT_UINT) {
+   if (divider > MAX_32BIT_UINT) {
+   result = 0;
+   if (rem_p)
+   *rem_p = divider;
+   } else {
+   result = (u32)dividend / (u32)divider;
+   if (rem_p)
+   *rem_p = (u32)dividend % (u32)divider;
+   }
+   return result;
+   }
+
+   while (divider <= dividend) {
+   u64 locald = divider;
+   u64 limit = 

Re: [U-Boot] [RFC PATCH 04/10] env: Pass additional parameters to the env lookup function

2017-11-24 Thread Quentin Schulz
Hi Maxime,

On 16/11/2017 10:22, Maxime Ripard wrote:
> In preparation for the multiple environment support, let's introduce two
> new parameters to the environment driver lookup function: the priority and
> operation.
> 
> The operation parameter is meant to identify, obviously, the operation you
> might want to perform on the environment.
> 
> The priority is a number passed to identify the environment priority you
> want to retrieve. The lowest priority parameter (0) will be the primary
> source.
> 
> Combining the two parameters allow you to support multiple environments
> through different priorities, and to change those priorities between read
> and writes operations.
> 
> This is especially useful to implement migration mechanisms where you want
> to always use the same environment first, be it to read or write, while the
> common case is more likely to use the same environment it has read from to
> write it to.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  env/env.c | 122 
> ++
>  include/environment.h |   7 +++
>  2 files changed, 80 insertions(+), 49 deletions(-)
> 
> diff --git a/env/env.c b/env/env.c
> index 97ada5b5a6fd..673bfa6ba41b 100644
> --- a/env/env.c
> +++ b/env/env.c
> @@ -26,8 +26,11 @@ static struct env_driver *_env_driver_lookup(enum 
> env_location loc)
>   return NULL;
>  }
>  
> -static enum env_location env_get_location(void)
> +static enum env_location env_get_location(enum env_operation op, int prio)
>  {
> + if (prio >= 1)
> + return ENVL_UNKNOWN;
> +
>   if IS_ENABLED(CONFIG_ENV_IS_IN_EEPROM)
>   return ENVL_EEPROM;
>   else if IS_ENABLED(CONFIG_ENV_IS_IN_FAT)
> @@ -52,11 +55,14 @@ static enum env_location env_get_location(void)
>   return ENVL_UNKNOWN;
>  }
>  
> -static struct env_driver *env_driver_lookup(void)
> +static struct env_driver *env_driver_lookup(enum env_operation op, int prio)
>  {
> - enum env_location loc = env_get_location();
> + enum env_location loc = env_get_location(op, prio);
>   struct env_driver *drv;
>  
> + if (loc == ENVL_UNKNOWN)
> + return NULL;
> +
>   drv = _env_driver_lookup(loc);
>   if (!drv) {
>   debug("%s: No environment driver for location %d\n", __func__,
> @@ -69,83 +75,101 @@ static struct env_driver *env_driver_lookup(void)
>  
>  int env_get_char(int index)
>  {
> - struct env_driver *drv = env_driver_lookup();
> - int ret;
> + struct env_driver *drv;
> + int prio;
>  
>   if (gd->env_valid == ENV_INVALID)
>   return default_environment[index];
> - if (!drv)
> - return -ENODEV;
> - if (!drv->get_char)
> - return *(uchar *)(gd->env_addr + index);
> - ret = drv->get_char(index);
> - if (ret < 0) {
> - debug("%s: Environment failed to load (err=%d)\n",
> -   __func__, ret);
> +
> + for (prio = 0; (drv = env_driver_lookup(ENVO_GET_CHAR, prio)); prio++) {
> + int ret;
> +
> + if (!drv->get_char)
> + continue;
> +
> + ret = drv->get_char(index);
> + if (!ret)
> + return 0;
> +
> + debug("%s: Environment %s failed to load (err=%d)\n", __func__,
> +   drv->name, ret);
>   }
>  
> - return ret;
> + return -ENODEV;
>  }
>  
>  int env_load(void)
>  {
> - struct env_driver *drv = env_driver_lookup();
> - int ret = 0;
> + struct env_driver *drv;
> + int prio;
>  
> - if (!drv)
> - return -ENODEV;
> - if (!drv->load)
> - return 0;
> - ret = drv->load();
> - if (ret) {
> - debug("%s: Environment failed to load (err=%d)\n", __func__,
> -   ret);
> - return ret;
> + for (prio = 0; (drv = env_driver_lookup(ENVO_LOAD, prio)); prio++) {
> + int ret;
> +
> + if (!drv->load)
> + continue;
> +
> + ret = drv->load();
> + if (!ret)
> + return 0;
> +
> + debug("%s: Environment %s failed to load (err=%d)\n", __func__,
> +   drv->name, ret);
>   }
>  
> - return 0;
> + return -ENODEV;
>  }
>  
>  int env_save(void)
>  {
> - struct env_driver *drv = env_driver_lookup();
> - int ret;
> + struct env_driver *drv;
> + int prio;
>  
> - if (!drv)
> - return -ENODEV;
> - if (!drv->save)
> - return -ENOSYS;
> -
> - printf("Saving Environment to %s...\n", drv->name);
> - ret = drv->save();
> - if (ret) {
> - debug("%s: Environment failed to save (err=%d)\n", __func__,
> -   ret);
> - return ret;
> + for (prio = 0; (drv = env_driver_lookup(ENVO_SAVE, prio)); prio++) {
> + int ret;
> +
> + if 

Re: [U-Boot] [PATCH] fat: Use cache aligned buffers for fat_opendir

2017-11-24 Thread Lukasz Majewski
On Fri, 24 Nov 2017 09:54:41 +0100
Neil Armstrong  wrote:

> Before this patch one could receive following errors when executing
> "fatls" command on machine with cache enabled (ex i.MX6Q) :
> 
> => fatls mmc 0:1  
> CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
> CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
> ERROR: v7_outer_cache_inval_range - start address is not aligned -
> 0x4f59dfc8 ERROR: v7_outer_cache_inval_range - stop address is not
> aligned - 0x4f59e7c8 CACHE: Misaligned operation at range [4f59dfc8,
> 4f59e7c8] CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
> ERROR: v7_outer_cache_inval_range - start address is not aligned -
> 0x4f59dfc8 ERROR: v7_outer_cache_inval_range - stop address is not
> aligned - 0x4f59e7c8
> 
> To alleviate this problem - the calloc()s have been replaced with
> malloc_cache_aligned() and memset().
> 
> After those changes the buffers are properly aligned (with both start
> address and size) to SoC cache line.
> 
> Fixes: 09fa964bba80 ("fs/fat: Fix 'CACHE: Misaligned operation at
> range' warnings") Suggested-by: Lukasz Majewski 
> Signed-off-by: Neil Armstrong 
> ---
>  fs/fat/fat.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> index 7fe7843..d16883f 100644
> --- a/fs/fat/fat.c
> +++ b/fs/fat/fat.c
> @@ -1149,11 +1149,13 @@ typedef struct {
>  
>  int fat_opendir(const char *filename, struct fs_dir_stream **dirsp)
>  {
> - fat_dir *dir = calloc(1, sizeof(*dir));
> + fat_dir *dir;
>   int ret;
>  
> + dir = malloc_cache_aligned(sizeof(*dir));
>   if (!dir)
>   return -ENOMEM;
> + memset(dir, 0, sizeof(*dir));
>  
>   ret = fat_itr_root(>itr, >fsdata);
>   if (ret)

Reviewed-by: Lukasz Majewski 

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


pgpE_kvQvPeut.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] fat: Use cache aligned buffers for fat_opendir

2017-11-24 Thread Neil Armstrong
Before this patch one could receive following errors when executing "fatls"
command on machine with cache enabled (ex i.MX6Q) :

=> fatls mmc 0:1
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x4f59dfc8
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x4f59e7c8
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x4f59dfc8
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x4f59e7c8

To alleviate this problem - the calloc()s have been replaced with
malloc_cache_aligned() and memset().

After those changes the buffers are properly aligned (with both start
address and size) to SoC cache line.

Fixes: 09fa964bba80 ("fs/fat: Fix 'CACHE: Misaligned operation at range' 
warnings")
Suggested-by: Lukasz Majewski 
Signed-off-by: Neil Armstrong 
---
 fs/fat/fat.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 7fe7843..d16883f 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -1149,11 +1149,13 @@ typedef struct {
 
 int fat_opendir(const char *filename, struct fs_dir_stream **dirsp)
 {
-   fat_dir *dir = calloc(1, sizeof(*dir));
+   fat_dir *dir;
int ret;
 
+   dir = malloc_cache_aligned(sizeof(*dir));
if (!dir)
return -ENOMEM;
+   memset(dir, 0, sizeof(*dir));
 
ret = fat_itr_root(>itr, >fsdata);
if (ret)
-- 
2.7.4

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


Re: [U-Boot] v7_outer_cache_inval_range error on iMX6Q

2017-11-24 Thread Neil Armstrong
Hi Łukasz,

On 23/11/2017 20:55, Lukasz Majewski wrote:
> Hi Neil,
> 
>> Hi,
>>
>> I'm having a strange issue while porting the DART-MX6 and it's
>> carrier board to mainline U-Boot.
>>
>> Everything works as expected except "fatls" where I get the following
>> output :
> 
> Please look into:
> http://patchwork.ozlabs.org/patch/831183/
> 
> IN short:
> 
> You may need to fix the code by using cache aware allocation
> functions instead of calloc(), malloc().

I found it in fat.c, thanks.

Neil

> 
> 
> BR,
> Łukasz
>>
>> => fatls mmc 0:1  
>> CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
>> CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
>> ERROR: v7_outer_cache_inval_range - start address is not aligned -
>> 0x4f59dfc8 ERROR: v7_outer_cache_inval_range - stop address is not
>> aligned - 0x4f59e7c8 CACHE: Misaligned operation at range [4f59dfc8,
>> 4f59e7c8] CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
>> ERROR: v7_outer_cache_inval_range - start address is not aligned -
>> 0x4f59dfc8 ERROR: v7_outer_cache_inval_range - stop address is not
>> aligned - 0x4f59e7c8
>>
>> 0 file(s), 0 dir(s)
>>
>> But :
>> => fatinfo mmc 0:1  
>> Interface:  MMC
>>   Device 0: Vendor: Man 74 Snr 62aee901 Rev: 4.2 Prod: USD  
>> Type: Removable Hard Disk
>> Capacity: 7695.0 MB = 7.5 GB (15759360 x 512)
>> Filesystem: FAT16 "boot   "
>>
>> And it contains :
>> 41541   imx6q-var-dt6customboard.dtb
>>   6535440   uImage
>>
>> And even fatload works :
>> => fatload mmc 0:1 $loadaddr uIMage  
>> reading uIMage
>> 6535440 bytes read in 322 ms (19.4 MiB/s)
>>
>> Same for mmc0 (SDCard) and mmc1 (eMMC).
>>
>> I tested against v2017.11 and master
>> (16fa2eb95172e63820ee5f3d4052f3362a6de84e) with :
>> gcc-linaro-4.9.4-2017.01-x86_64_arm-eabi
>> gcc-linaro-7.1.1-2017.08-x86_64_arm-linux-gnueabihf
>>
>> same behaviour.
>>
>> And same behaviour when reverting the following :
>> af609e3 fs/fat: Check malloc return values and fix memory leaks
>> 09fa964 fs/fat: Fix 'CACHE: Misaligned operation at range' warnings
>> 8df8731 fs/fat: Fix pathnames using '..' that lead to the root
>> directory 2460098 fs/fat: Reduce stack usage
>>
>> Do someone have an idea except disabling data cache ?
>>
>> Thanks,
>> Neil
>>
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> 




signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] Revert "x86: bootm: Fix FIT image booting on x86"

2017-11-24 Thread Bin Meng
On Fri, Nov 24, 2017 at 4:12 PM, Bin Meng  wrote:
> On Fri, Nov 24, 2017 at 1:59 AM, Anatolij Gustschin  wrote:
>> This reverts commit 13c531e52a09b4e6ffa8b5a1457199b0a574cb27.
>>
>> The error message with FIT style image mentioned in the above commit
>> only happens when booting using FIT image containing bzImage kernel
>> and without setup node (setup.bin). The current documentation for
>> x86 FIT support in doc/uImage.FIT/x86-fit-boot.txt mentions that
>> kernel's setup.bin file is required for building x86 FIT images.
>> The above commit breaks FIT images generated as described in the
>> documentation. Revert it to allow booting with images built in the
>> documented way.
>>
>> Signed-off-by: Anatolij Gustschin 
>> ---
>>  arch/x86/lib/bootm.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>
> Acked-by: Bin Meng 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2] x86: lib: Implement standalone __udivdi3 etc instead of libgcc ones

2017-11-24 Thread Bin Meng
Hi Stefan,

On Mon, Nov 20, 2017 at 6:43 PM, Stefan Roese  wrote:
> Hi Bin,
>
>
> On 20.11.2017 08:24, Bin Meng wrote:
>>
>> On Fri, Nov 17, 2017 at 2:02 PM, Stefan Roese  wrote:
>>>
>>> This patch removes the inclusion of the libgcc math functions and
>>> replaces them by functions coded in C, taken from the coreboot
>>> project. This makes U-Boot building more independent from the toolchain
>>> installed / available on the build system.
>>>
>>> The code taken from coreboot is authored from Vadim Bendebury
>>>  on 2014-11-28 and committed with commit
>>> ID e63990ef [libpayload: provide basic 64bit division implementation]
>>> (coreboot git repository located here [1]).
>>>
>>> I modified the code so that its checkpatch clean without any
>>> functional changes.
>>>
>>> [1] git://github.com/coreboot/coreboot.git
>>>
>>> Signed-off-by: Stefan Roese 
>>> Cc: Simon Glass 
>>> Cc: Bin Meng 
>>> ---
>>> v2:
>>> - Added coreboot git repository link to commit message
>>>
>>>   arch/x86/config.mk|   3 --
>>>   arch/x86/lib/Makefile |   2 +-
>>>   arch/x86/lib/div64.c  | 113
>>> ++
>>>   arch/x86/lib/gcc.c|  29 -
>>>   4 files changed, 114 insertions(+), 33 deletions(-)
>>>   create mode 100644 arch/x86/lib/div64.c
>>>   delete mode 100644 arch/x86/lib/gcc.c
>>>
>>> diff --git a/arch/x86/config.mk b/arch/x86/config.mk
>>> index 8835dcf36f..472ada5490 100644
>>> --- a/arch/x86/config.mk
>>> +++ b/arch/x86/config.mk
>>> @@ -34,9 +34,6 @@ PLATFORM_RELFLAGS += -ffunction-sections
>>> -fvisibility=hidden
>>>   PLATFORM_LDFLAGS += -Bsymbolic -Bsymbolic-functions
>>>   PLATFORM_LDFLAGS += -m $(if $(IS_32BIT),elf_i386,elf_x86_64)
>>>
>>> -LDFLAGS_FINAL += --wrap=__divdi3 --wrap=__udivdi3
>>> -LDFLAGS_FINAL += --wrap=__moddi3 --wrap=__umoddi3
>>> -
>>>   # This is used in the top-level Makefile which does not include
>>>   # PLATFORM_LDFLAGS
>>>   LDFLAGS_EFI_PAYLOAD := -Bsymbolic -Bsymbolic-functions -shared
>>> --no-undefined
>>> diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
>>> index fe00d7573f..d9b23f5cc4 100644
>>> --- a/arch/x86/lib/Makefile
>>> +++ b/arch/x86/lib/Makefile
>>> @@ -18,7 +18,7 @@ obj-$(CONFIG_SEABIOS) += coreboot_table.o
>>>   obj-y  += early_cmos.o
>>>   obj-$(CONFIG_EFI) += efi/
>>>   obj-y  += e820.o
>>> -obj-y  += gcc.o
>>> +obj-y  += div64.o
>>>   obj-y  += init_helpers.o
>>>   obj-y  += interrupts.o
>>>   obj-y  += lpc-uclass.o
>>> diff --git a/arch/x86/lib/div64.c b/arch/x86/lib/div64.c
>>> new file mode 100644
>>> index 00..4efed74037
>>> --- /dev/null
>>> +++ b/arch/x86/lib/div64.c
>>> @@ -0,0 +1,113 @@
>>> +/*
>>> + * This file is copied from the coreboot repository as part of
>>> + * the libpayload project:
>>> + *
>>> + * Copyright 2014 Google Inc.
>>> + *
>>> + * SPDX-License-Identifier: BSD-3-Clause
>>> + */
>>> +
>>> +#include 
>>> +
>>> +union overlay64 {
>>> +   u64 longw;
>>> +   struct {
>>> +   u32 lower;
>>> +   u32 higher;
>>> +   } words;
>>> +};
>>> +
>>> +u64 __ashldi3(u64 num, unsigned int shift)
>>> +{
>>> +   union overlay64 output;
>>> +
>>> +   output.longw = num;
>>> +   if (shift >= 32) {
>>> +   output.words.higher = output.words.lower << (shift - 32);
>>> +   output.words.lower = 0;
>>> +   } else {
>>> +   if (!shift)
>>> +   return num;
>>> +   output.words.higher = (output.words.higher << shift) |
>>> +   (output.words.lower >> (32 - shift));
>>> +   output.words.lower = output.words.lower << shift;
>>> +   }
>>> +   return output.longw;
>>> +}
>>> +
>>> +u64 __lshrdi3(u64 num, unsigned int shift)
>>> +{
>>> +   union overlay64 output;
>>> +
>>> +   output.longw = num;
>>> +   if (shift >= 32) {
>>> +   output.words.lower = output.words.higher >> (shift - 32);
>>> +   output.words.higher = 0;
>>> +   } else {
>>> +   if (!shift)
>>> +   return num;
>>> +   output.words.lower = output.words.lower >> shift |
>>> +   (output.words.higher << (32 - shift));
>>> +   output.words.higher = output.words.higher >> shift;
>>> +   }
>>> +   return output.longw;
>>> +}
>>> +
>>> +#define MAX_32BIT_UINT u64)1) << 32) - 1)
>>> +
>>> +static u64 _64bit_divide(u64 dividend, u64 divider, u64 *rem_p)
>>> +{
>>> +   u64 result = 0;
>>> +
>>> +   /*
>>> +* If divider is zero - let the rest of the system care about the
>>> +* exception.
>>> +*/
>>> +   if (!divider)
>>> +   return 1 / (u32)divider;
>>> +
>>> +   /* As an optimization, let's not use 64 bit division unless we
>>> must. */
>>> +   if (dividend <= MAX_32BIT_UINT) {
>>> +   if 

Re: [U-Boot] [PATCH] Revert "x86: bootm: Fix FIT image booting on x86"

2017-11-24 Thread Bin Meng
On Fri, Nov 24, 2017 at 1:59 AM, Anatolij Gustschin  wrote:
> This reverts commit 13c531e52a09b4e6ffa8b5a1457199b0a574cb27.
>
> The error message with FIT style image mentioned in the above commit
> only happens when booting using FIT image containing bzImage kernel
> and without setup node (setup.bin). The current documentation for
> x86 FIT support in doc/uImage.FIT/x86-fit-boot.txt mentions that
> kernel's setup.bin file is required for building x86 FIT images.
> The above commit breaks FIT images generated as described in the
> documentation. Revert it to allow booting with images built in the
> documented way.
>
> Signed-off-by: Anatolij Gustschin 
> ---
>  arch/x86/lib/bootm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Acked-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/1] x86: enable DISTRO_DEFAULTS for qemu

2017-11-24 Thread Bin Meng
Hi Heinrich,

On Mon, Nov 20, 2017 at 5:20 PM, Bin Meng  wrote:
> On Mon, Nov 20, 2017 at 3:07 PM, Bin Meng  wrote:
>> On Mon, Nov 20, 2017 at 1:30 AM, Heinrich Schuchardt  
>> wrote:
>>> Enable CONFIG_DISTRO_DEFAULTS in qemu-x86_64_defconfig
>>> and qemu-x86_defconfig.
>>>
>>> Signed-off-by: Heinrich Schuchardt 
>>> ---
>>>  configs/qemu-x86_64_defconfig | 1 +
>>>  configs/qemu-x86_defconfig| 1 +
>>>  2 files changed, 2 insertions(+)
>>>
>>
>> Reviewed-by: Bin Meng 
>
> applied to u-boot-x86, thanks!

Unfortunately, this creates build warnings on QEMU.

include/configs/x86-common.h:70:0: warning: "CONFIG_BOOTCOMMAND" redefined
 #define CONFIG_BOOTCOMMAND \
 ^

Can you please post your new patch against u-boot-x86/master that
fixes this issue?

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


[U-Boot] Intel Edison build warning

2017-11-24 Thread Bin Meng
Hi,

Intel Edison has a build warning below.

+  *env_addr = offset;
+^
w+../env/mmc.c: In function 'mmc_get_env_addr':
w+../env/mmc.c:121:12: warning: 'val' may be used uninitialized in
this function [-Wmaybe-uninitialized]

I did not figure out what is wrong here. v2017.11 does not have such
build warning.

Do you have any idea?

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