[U-Boot] [PATCH v1 1/2] ARM: mvebu: a38x: move definition of PEX_CFG_DIRECT_ACCESS

[Chris Packham]

PEX_CFG_DIRECT_ACCESS was defined in ddr3_hws_hw_training_def.h despite
only being used in the serdes code. Move this definition to ctrl_pex.h
where all the other PEX defines are. Also remove the duplicate
definition of PEX_DEVICE_AND_VENDOR_ID which is already defined in
ctrl_pex.h.

Signed-off-by: Chris Packham 
---

 arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h  | 1 +
 drivers/ddr/marvell/a38x/ddr3_hws_hw_training_def.h | 2 --
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h 
b/arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h
index ca8a4d206a36..d6f0d4fcd381 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h
+++ b/arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h
@@ -47,6 +47,7 @@
 
 /* Controller revision info */
 #define PEX_DEVICE_AND_VENDOR_ID   0x000
+#define PEX_CFG_DIRECT_ACCESS(if, reg) (PEX_IF_REGS_BASE(if) + (reg))
 
 /* PCI Express Configuration Address Register */
 #define PXCAR_REG_NUM_OFFS 2
diff --git a/drivers/ddr/marvell/a38x/ddr3_hws_hw_training_def.h 
b/drivers/ddr/marvell/a38x/ddr3_hws_hw_training_def.h
index 06d0ab10aa2a..bca0af89a72d 100644
--- a/drivers/ddr/marvell/a38x/ddr3_hws_hw_training_def.h
+++ b/drivers/ddr/marvell/a38x/ddr3_hws_hw_training_def.h
@@ -422,8 +422,6 @@
 
 /* Power Management Clock Gating Control Register */
 #define POWER_MNG_CTRL_REG 0x18220
-#define PEX_DEVICE_AND_VENDOR_ID   0x000
-#define PEX_CFG_DIRECT_ACCESS(if, reg) (PEX_IF_REGS_BASE(if) + (reg))
 #define PMC_PEXSTOPCLOCK_OFFS(p)   ((p) < 8 ? (5 + (p)) : (18 + (p)))
 #define PMC_PEXSTOPCLOCK_MASK(p)   (1 << PMC_PEXSTOPCLOCK_OFFS(p))
 #define PMC_PEXSTOPCLOCK_EN(p) (1 << PMC_PEXSTOPCLOCK_OFFS(p))
-- 
2.16.2

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

[U-Boot] [PATCH v1 2/2] ARM: mvebu: a38x: move sys_env_device_rev_get

[Chris Packham]

Move sys_env_device_rev_get() from the ddr training code to
sys_env_lib.c (which currently resides with the serdes code). This
brings sys_env_device_rev_get() into line with sys_env_device_id_get()
and sys_env_model_get().

Signed-off-by: Chris Packham 
---

 arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c | 24 
 drivers/ddr/marvell/a38x/ddr3_init.c  | 24 
 2 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c 
b/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c
index cc3e5e23c0dd..4f15746c092b 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c
+++ b/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c
@@ -235,3 +235,27 @@ u32 sys_env_device_id_get(void)
 
return g_dev_id;
 }
+
+/*
+ * sys_env_device_rev_get - Get Marvell controller device revision number
+ *
+ * DESCRIPTION:
+ *   This function returns 8bit describing the device revision as defined
+ *   Revision ID Register.
+ *
+ * INPUT:
+ *   None.
+ *
+ * OUTPUT:
+ *   None.
+ *
+ * RETURN:
+ *   8bit desscribing Marvell controller revision number
+ */
+u8 sys_env_device_rev_get(void)
+{
+   u32 value;
+
+   value = reg_read(DEV_VERSION_ID_REG);
+   return (value & (REVISON_ID_MASK)) >> REVISON_ID_OFFS;
+}
diff --git a/drivers/ddr/marvell/a38x/ddr3_init.c 
b/drivers/ddr/marvell/a38x/ddr3_init.c
index 55baad498ae5..032c4d54f359 100644
--- a/drivers/ddr/marvell/a38x/ddr3_init.c
+++ b/drivers/ddr/marvell/a38x/ddr3_init.c
@@ -108,30 +108,6 @@ static int ddr3_hws_tune_training_params(u8 dev_num);
 /* A39x revisions */
 #define MV_88F69XX_Z1_ID   0x2
 
-/*
- * sys_env_device_rev_get - Get Marvell controller device revision number
- *
- * DESCRIPTION:
- *   This function returns 8bit describing the device revision as defined
- *   Revision ID Register.
- *
- * INPUT:
- *   None.
- *
- * OUTPUT:
- *   None.
- *
- * RETURN:
- *   8bit desscribing Marvell controller revision number
- */
-u8 sys_env_device_rev_get(void)
-{
-   u32 value;
-
-   value = reg_read(DEV_VERSION_ID_REG);
-   return (value & (REVISON_ID_MASK)) >> REVISON_ID_OFFS;
-}
-
 /*
  * sys_env_dlb_config_ptr_get
  *
-- 
2.16.2

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

[U-Boot] [PATCH v1 0/2] ARM: mvebu: a38x: updates

[Chris Packham]

This small series represents some low hanging fruit needed before we can
bring in the updated version of Marvell's DDR training code. These are
things that really shouldn't have been part of the DDR code in the first
place but for one reason or another ended up there.

Patch 2 is borrowed in part from commit 09275c77 in
https://github.com/MarvellEmbeddedProcessors/u-boot-marvell.git


Chris Packham (2):
  ARM: mvebu: a38x: move definition of PEX_CFG_DIRECT_ACCESS
  ARM: mvebu: a38x: move sys_env_device_rev_get

 arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h |  1 +
 arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c  | 24 ++
 .../ddr/marvell/a38x/ddr3_hws_hw_training_def.h|  2 --
 drivers/ddr/marvell/a38x/ddr3_init.c   | 24 --
 4 files changed, 25 insertions(+), 26 deletions(-)

-- 
2.16.2

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

Re: [U-Boot] [PATCH v2] timer: add High Precision Event Timers (HPET) support

[Ivan Gorinov]

On Wed, Apr 04, 2018 at 12:15:24PM +0800, Bin Meng wrote:
> > Doesn't readX/writeX imply a single I/O operation?
> > It may be misleading to define it as two.
> >
> > Assuming MMX or SSE2 to be supported by all x86 processors, 64-bit I/O
> > registers can be accessed as a single operation even in 32-bit code:
> >
> 
> Adding such requirement (MMX or SSE2) to U-Boot is not good. Why do we
> require MMX or SSE2 for readq? Can we use general purpose registers?

In 32-bit code, we can't make a 64-bit memory read operation using only
general purpose registers.

> 
> > static inline u64 readq(void *addr)
> > {
> > u64 value;
> >
> > asm volatile ("movq (%0), %%xmm0" : : "r" (addr));
> > asm volatile ("movq %%xmm0, %0" : "=m" (value));
> >
> > return value;
> > }
> >
> > I can add these definitions to "asm/io.h".
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] timer: add High Precision Event Timers (HPET) support

[Bin Meng]

On Wed, Apr 4, 2018 at 7:26 AM, Ivan Gorinov  wrote:
> On Tue, Apr 03, 2018 at 06:17:42AM -0600, Andy Shevchenko wrote:
>> >> > If readq() is defined as two read operations in 32-bit code, main 
>> >> > counter
>> >> > rollover (low part overflow, high part increment) can happen between 
>> >> > them.
>> >> And how this contradicts ther current code?
>> > It just does not make the code simpler,
>> ...b/c you misread what I suggested.
>> > rollover check is
>> > still required if U-Boot is compiled as 32-bit code.
>> > Can we do something like the following?
>> Yes, but... why?
>> What's wrong with replacing two sequential 32-bit reads with one 64-bit?
>
> Doesn't readX/writeX imply a single I/O operation?
> It may be misleading to define it as two.
>
> Assuming MMX or SSE2 to be supported by all x86 processors, 64-bit I/O
> registers can be accessed as a single operation even in 32-bit code:
>

Adding such requirement (MMX or SSE2) to U-Boot is not good. Why do we
require MMX or SSE2 for readq? Can we use general purpose registers?

> static inline u64 readq(void *addr)
> {
> u64 value;
>
> asm volatile ("movq (%0), %%xmm0" : : "r" (addr));
> asm volatile ("movq %%xmm0, %0" : "=m" (value));
>
> return value;
> }
>
> I can add these definitions to "asm/io.h".

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

Re: [U-Boot] Marvell Armada-38x DDR training code

[Chris Packham]

On Thu, Mar 29, 2018 at 4:01 PM, Chris Packham  wrote:
> Hi,
>
> I've posted a couple of improvements to the in-tree ddr training code
> but we've known for a while that u-boot proper is a bit behind
> Marvell's code for ddr training. And now I really do have a problem on
> my board that is fixed by using Marvell's code.
>
> Yesterday I got hold of patches from Marvell for their "standalone"
> mv_ddr code. It's under a tri-license Proprietary/GPL/BSD-3c so I've
> exercised my rights under the GPL and made it available on github
> https://github.com/cpackham/mv_ddr.git

Actually looks like Marvell have their own official one
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git so
there's no need for mine. I'll take it down to avoid confusion.

> This standalone code looks the most u-boot-ish of any code I've gotten
> out of Marvell. In fact I suspect it was based on the work that Stefan
> did initially.
>
> The question how do I get this upstream I could submit 475 odd patches
> preserving the authorship, I could submit one big roll-up of changes.
> Neither option is particularly appealing. It would be hard to narrow
> down the subset of changes that fixes my particular problem.
>
> Any suggestions on how to proceed?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v5 11/11] Revert "sunxi: Pine64: temporarily remove extra Pine64 non-plus DT"

[Andre Przywara]

Now with the MMC environment gone, we have enough space to accommodate
the Pine64 "non-plus" .dtb again.

This reverts commit 47952b8e42c2790150e16d3d4235b3a1ee0ba9bb.

Signed-off-by: Andre Przywara 
---
 configs/pine64_plus_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
index e98740aec0..c512c1846d 100644
--- a/configs/pine64_plus_defconfig
+++ b/configs/pine64_plus_defconfig
@@ -9,6 +9,7 @@ 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_OF_LIST="sun50i-a64-pine64 sun50i-a64-pine64-plus"
 CONFIG_SUN8I_EMAC=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
-- 
2.14.1

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

[U-Boot] [PATCH v5 04/11] net: sun8i-emac: add support for new EMAC DT binding

[Andre Przywara]

The Ethernet MAC used in newer Allwinner SoCs (H3, A64, H5) got an
upstream Linux driver in v4.15.
This one uses a slightly different binding from the original one used
by the U-Boot driver.
The differences to the old binding are:
- The "syscon" address is held in a separate node, referenced via a
  phandle in the "syscon" property.
- The reference to the PHY is held in a property called "phy-handle",
  not "phy".
- The PHY register is at offset 0x30 in the syscon device, not at 0.
- The internal PHY is activated when the node, which phy-handle points
  to, is a child node of an "allwinner,sun8i-h3-mdio-internal" node.

Teach the U-Boot driver how to find its resources in a "new-style" DT,
so that we can use a Linux kernel compatible DT for U-Boot as well.
This keeps support for the old binding for now, to allow a smooth
transition.

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
---
 drivers/net/sun8i_emac.c | 59 +---
 1 file changed, 51 insertions(+), 8 deletions(-)

diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
index c8c8ef73e9..55d82f86de 100644
--- a/drivers/net/sun8i_emac.c
+++ b/drivers/net/sun8i_emac.c
@@ -279,7 +279,7 @@ static int sun8i_emac_set_syscon(struct emac_eth_dev *priv)
int ret;
u32 reg;
 
-   reg = readl(priv->sysctl_reg);
+   reg = readl(priv->sysctl_reg + 0x30);
 
if (priv->variant == H3_EMAC) {
ret = sun8i_emac_set_syscon_ephy(priv, );
@@ -310,7 +310,7 @@ static int sun8i_emac_set_syscon(struct emac_eth_dev *priv)
return -EINVAL;
}
 
-   writel(reg, priv->sysctl_reg);
+   writel(reg, priv->sysctl_reg + 0x30);
 
return 0;
 }
@@ -806,17 +806,52 @@ static int sun8i_emac_eth_ofdata_to_platdata(struct 
udevice *dev)
 #endif
 
pdata->iobase = devfdt_get_addr_name(dev, "emac");
+   if (pdata->iobase == FDT_ADDR_T_NONE)
+   pdata->iobase = devfdt_get_addr(dev);
+   if (pdata->iobase == FDT_ADDR_T_NONE) {
+   debug("%s: Cannot find MAC base address\n", __func__);
+   return -EINVAL;
+   }
+
priv->sysctl_reg = devfdt_get_addr_name(dev, "syscon");
+   if (priv->sysctl_reg == FDT_ADDR_T_NONE) {
+   const fdt32_t *reg;
+
+   offset = fdtdec_lookup_phandle(gd->fdt_blob, node, "syscon");
+   if (offset < 0) {
+   debug("%s: cannot find syscon node\n", __func__);
+   return -EINVAL;
+   }
+   reg = fdt_getprop(gd->fdt_blob, offset, "reg", NULL);
+   if (!reg) {
+   debug("%s: cannot find reg property in syscon node\n",
+ __func__);
+   return -EINVAL;
+   }
+   priv->sysctl_reg = fdt_translate_address((void *)gd->fdt_blob,
+offset, reg);
+   } else {
+   priv->sysctl_reg -= 0x30;
+   }
+
+   if (priv->sysctl_reg == FDT_ADDR_T_NONE) {
+   debug("%s: Cannot find syscon base address\n", __func__);
+   return -EINVAL;
+   }
 
pdata->phy_interface = -1;
priv->phyaddr = -1;
priv->use_internal_phy = false;
 
-   offset = fdtdec_lookup_phandle(gd->fdt_blob, node,
-  "phy");
-   if (offset > 0)
-   priv->phyaddr = fdtdec_get_int(gd->fdt_blob, offset, "reg",
-  -1);
+   offset = fdtdec_lookup_phandle(gd->fdt_blob, node, "phy");
+   if (offset < 0)
+   offset = fdtdec_lookup_phandle(gd->fdt_blob, node,
+  "phy-handle");
+   if (offset < 0) {
+   debug("%s: Cannot find PHY address\n", __func__);
+   return -EINVAL;
+   }
+   priv->phyaddr = fdtdec_get_int(gd->fdt_blob, offset, "reg", -1);
 
phy_mode = fdt_getprop(gd->fdt_blob, node, "phy-mode", NULL);
 
@@ -839,8 +874,16 @@ static int sun8i_emac_eth_ofdata_to_platdata(struct 
udevice *dev)
 
if (priv->variant == H3_EMAC) {
if (fdt_getprop(gd->fdt_blob, node,
-   "allwinner,use-internal-phy", NULL))
+   "allwinner,use-internal-phy", NULL)) {
priv->use_internal_phy = true;
+   } else {
+   int parent = fdt_parent_offset(gd->fdt_blob, offset);
+
+   if (parent >= 0 &&
+   !fdt_node_check_compatible(gd->fdt_blob, parent,
+   "allwinner,sun8i-h3-mdio-internal"))
+   priv->use_internal_phy = true;
+   }
}
 
priv->interface = pdata->phy_interface;
-- 
2.14.1

[U-Boot] [PATCH v5 03/11] net: sun8i-emac: support new pinctrl DT bindings

[Andre Przywara]

The Linux kernel driver for the Allwinner pin controller gained support
for generic properties, which are now also used in the DTs.
The sun8i-emac Ethernet driver for new Allwinner MACs reads the pins from
the DT, but so far only supported the old binding.
Update the parsing routine to cope with both the old and new bindings,
so that the newer DTs can be used with U-Boot and its Ethernet driver.

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
---
 drivers/net/sun8i_emac.c | 52 
 1 file changed, 39 insertions(+), 13 deletions(-)

diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
index be43472b1a..c8c8ef73e9 100644
--- a/drivers/net/sun8i_emac.c
+++ b/drivers/net/sun8i_emac.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef CONFIG_DM_GPIO
 #include 
 #endif
@@ -465,30 +466,55 @@ static int parse_phy_pins(struct udevice *dev)
}
 
drive = fdt_getprop_u32_default_node(gd->fdt_blob, offset, 0,
-"allwinner,drive", 4);
-   pull = fdt_getprop_u32_default_node(gd->fdt_blob, offset, 0,
-   "allwinner,pull", 0);
+"drive-strength", ~0);
+   if (drive != ~0) {
+   if (drive <= 10)
+   drive = SUN4I_PINCTRL_10_MA;
+   else if (drive <= 20)
+   drive = SUN4I_PINCTRL_20_MA;
+   else if (drive <= 30)
+   drive = SUN4I_PINCTRL_30_MA;
+   else
+   drive = SUN4I_PINCTRL_40_MA;
+   } else {
+   drive = fdt_getprop_u32_default_node(gd->fdt_blob, offset, 0,
+"allwinner,drive", 4);
+   }
+
+   if (fdt_get_property(gd->fdt_blob, offset, "bias-pull-up", NULL))
+   pull = SUN4I_PINCTRL_PULL_UP;
+   else if (fdt_get_property(gd->fdt_blob, offset, "bias-disable", NULL))
+   pull = SUN4I_PINCTRL_NO_PULL;
+   else if (fdt_get_property(gd->fdt_blob, offset, "bias-pull-down", NULL))
+   pull = SUN4I_PINCTRL_PULL_DOWN;
+   else
+   pull = fdt_getprop_u32_default_node(gd->fdt_blob, offset, 0,
+   "allwinner,pull", 0);
for (i = 0; ; i++) {
int pin;
 
pin_name = fdt_stringlist_get(gd->fdt_blob, offset,
  "allwinner,pins", i, NULL);
-   if (!pin_name)
-   break;
-   if (pin_name[0] != 'P')
-   continue;
-   pin = (pin_name[1] - 'A') << 5;
-   if (pin >= 26 << 5)
+   if (!pin_name) {
+   pin_name = fdt_stringlist_get(gd->fdt_blob, offset,
+ "pins", i, NULL);
+   if (!pin_name)
+   break;
+   }
+
+   pin = sunxi_name_to_gpio(pin_name);
+   if (pin < 0)
continue;
-   pin += simple_strtol(_name[2], NULL, 10);
 
sunxi_gpio_set_cfgpin(pin, SUN8I_GPD8_GMAC);
-   sunxi_gpio_set_drv(pin, drive);
-   sunxi_gpio_set_pull(pin, pull);
+   if (drive != ~0)
+   sunxi_gpio_set_drv(pin, drive);
+   if (pull != ~0)
+   sunxi_gpio_set_pull(pin, pull);
}
 
if (!i) {
-   printf("WARNING: emac: cannot find allwinner,pins property\n");
+   printf("WARNING: emac: cannot find pins property\n");
return -2;
}
 
-- 
2.14.1

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

[U-Boot] [PATCH v5 09/11] sunxi: disable direct MMC environment

[Andre Przywara]

Since the dawn of time for the Allwinner support in mainline U-Boot
we store the environment to the SD card and write directly at
544KB from the beginning of the device. This leads to problems when
the U-Boot proper image grows beyond 504KB and eventually overlaps.
With one release of having the environment preferably in a FAT
partition, let's now turn off the MMC variant fallback, so we get back
all the space we need to implement features.

Signed-off-by: Andre Przywara 
---
 env/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/env/Kconfig b/env/Kconfig
index 35548721bd..3bc1a35f65 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -152,7 +152,6 @@ config ENV_IS_IN_MMC
bool "Environment in an MMC device"
depends on !CHAIN_OF_TRUST
depends on MMC
-   default y if ARCH_SUNXI
default y if ARCH_EXYNOS4
default y if MX6SX || MX7D
default y if TEGRA30 || TEGRA124
-- 
2.14.1

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

[U-Boot] [PATCH v5 06/11] arm: dts: sunxi: update H3 to new EMAC binding

[Andre Przywara]

The U-Boot driver for the sun8i-emac was using some preliminary DT
binding. Now since Linux got its own driver in v4.15 and our driver
can now cope with both bindings, let's convert the DT nodes used by the
various H3 boards over to the new bindings used by the kernel.

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
---
 arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts  |  6 +--
 arch/arm/dts/sun8i-h3-libretech-all-h3-cc.dts |  7 +--
 arch/arm/dts/sun8i-h3-nanopi-neo.dts  |  6 +--
 arch/arm/dts/sun8i-h3-orangepi-2.dts  |  7 +--
 arch/arm/dts/sun8i-h3-orangepi-one.dts|  7 +--
 arch/arm/dts/sun8i-h3-orangepi-pc.dts |  7 +--
 arch/arm/dts/sun8i-h3-orangepi-plus.dts   |  8 +++-
 arch/arm/dts/sun8i-h3-orangepi-plus2e.dts |  9 +++-
 arch/arm/dts/sun8i-h3.dtsi| 69 ---
 9 files changed, 75 insertions(+), 51 deletions(-)

diff --git a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts 
b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
index 20d489cb2a..e0efcb3ba3 100644
--- a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
+++ b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
@@ -100,14 +100,10 @@
 };
 
  {
-   phy = <>;
+   phy-handle = <_mii_phy>;
phy-mode = "mii";
-   allwinner,use-internal-phy;
allwinner,leds-active-low;
status = "okay";
-   phy1: ethernet-phy@1 {
-   reg = <1>;
-   };
 };
 
  {
diff --git a/arch/arm/dts/sun8i-h3-libretech-all-h3-cc.dts 
b/arch/arm/dts/sun8i-h3-libretech-all-h3-cc.dts
index 97b993f636..c8fd69f0a4 100644
--- a/arch/arm/dts/sun8i-h3-libretech-all-h3-cc.dts
+++ b/arch/arm/dts/sun8i-h3-libretech-all-h3-cc.dts
@@ -125,15 +125,10 @@
 };
 
  {
-   phy = <>;
+   phy-handle = <_mii_phy>;
phy-mode = "mii";
-   allwinner,use-internal-phy;
allwinner,leds-active-low;
status = "okay";
-
-   phy1: ethernet-phy@1 {
-   reg = <1>;
-   };
 };
 
  {
diff --git a/arch/arm/dts/sun8i-h3-nanopi-neo.dts 
b/arch/arm/dts/sun8i-h3-nanopi-neo.dts
index 5113059098..78f6c24952 100644
--- a/arch/arm/dts/sun8i-h3-nanopi-neo.dts
+++ b/arch/arm/dts/sun8i-h3-nanopi-neo.dts
@@ -48,12 +48,8 @@
 };
 
  {
-   phy = <>;
+   phy-handle = <_mii_phy>;
phy-mode = "mii";
-   allwinner,use-internal-phy;
allwinner,leds-active-low;
status = "okay";
-   phy1: ethernet-phy@1 {
-   reg = <1>;
-   };
 };
diff --git a/arch/arm/dts/sun8i-h3-orangepi-2.dts 
b/arch/arm/dts/sun8i-h3-orangepi-2.dts
index caa1a6959c..d97fdacb35 100644
--- a/arch/arm/dts/sun8i-h3-orangepi-2.dts
+++ b/arch/arm/dts/sun8i-h3-orangepi-2.dts
@@ -55,6 +55,7 @@
aliases {
serial0 = 
/* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
+   ethernet0 = 
ethernet1 = 
};
 
@@ -110,14 +111,10 @@
 };
 
  {
-   phy = <>;
+   phy-handle = <_mii_phy>;
phy-mode = "mii";
-   allwinner,use-internal-phy;
allwinner,leds-active-low;
status = "okay";
-   phy1: ethernet-phy@1 {
-   reg = <1>;
-   };
 };
 
  {
diff --git a/arch/arm/dts/sun8i-h3-orangepi-one.dts 
b/arch/arm/dts/sun8i-h3-orangepi-one.dts
index 8df5c74f04..adab1cbfc9 100644
--- a/arch/arm/dts/sun8i-h3-orangepi-one.dts
+++ b/arch/arm/dts/sun8i-h3-orangepi-one.dts
@@ -53,6 +53,7 @@
compatible = "xunlong,orangepi-one", "allwinner,sun8i-h3";
 
aliases {
+   ethernet0 = 
serial0 = 
};
 
@@ -95,14 +96,10 @@
 };
 
  {
-   phy = <>;
+   phy-handle = <_mii_phy>;
phy-mode = "mii";
-   allwinner,use-internal-phy;
allwinner,leds-active-low;
status = "okay";
-   phy1: ethernet-phy@1 {
-   reg = <1>;
-   };
 };
 
  {
diff --git a/arch/arm/dts/sun8i-h3-orangepi-pc.dts 
b/arch/arm/dts/sun8i-h3-orangepi-pc.dts
index b8340f74e7..afba264ea5 100644
--- a/arch/arm/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/dts/sun8i-h3-orangepi-pc.dts
@@ -53,6 +53,7 @@
compatible = "xunlong,orangepi-pc", "allwinner,sun8i-h3";
 
aliases {
+   ethernet0 = 
serial0 = 
};
 
@@ -167,12 +168,8 @@
 };
 
  {
-   phy = <>;
+   phy-handle = <_mii_phy>;
phy-mode = "mii";
-   allwinner,use-internal-phy;
allwinner,leds-active-low;
status = "okay";
-   phy1: ethernet-phy@1 {
-   reg = <1>;
-   };
 };
diff --git a/arch/arm/dts/sun8i-h3-orangepi-plus.dts 
b/arch/arm/dts/sun8i-h3-orangepi-plus.dts
index e7079b26bc..136e4414a4 100644
--- a/arch/arm/dts/sun8i-h3-orangepi-plus.dts
+++ b/arch/arm/dts/sun8i-h3-orangepi-plus.dts
@@ -82,7 +82,13 @@
pinctrl-0 = <_rgmii_pins>;
phy-supply = <_gmac_3v3>;
phy-mode = "rgmii";
-   /delete-property/allwinner,use-internal-phy;
+};
+
+_mdio {
+   ext_rgmii_phy: 

[U-Boot] [PATCH v5 07/11] arm: dts: sunxi: update H5 to new EMAC binding

[Andre Przywara]

The U-Boot driver for the sun8i-emac was using some preliminary DT
binding. Now since Linux got its own driver in v4.15 and our driver
can now cope with both bindings, let's convert the DT nodes used by the
OrangePi PC2 over to the new bindings used by the kernel.

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
---
 arch/arm/dts/sun50i-h5-orangepi-pc2.dts | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/sun50i-h5-orangepi-pc2.dts 
b/arch/arm/dts/sun50i-h5-orangepi-pc2.dts
index 780d59a096..d1c347d2b8 100644
--- a/arch/arm/dts/sun50i-h5-orangepi-pc2.dts
+++ b/arch/arm/dts/sun50i-h5-orangepi-pc2.dts
@@ -108,10 +108,13 @@
pinctrl-names = "default";
pinctrl-0 = <_rgmii_pins>;
phy-mode = "rgmii";
-   phy = <>;
+   phy-handle = <_rgmii_phy>;
status = "okay";
+};
 
-   phy1: ethernet-phy@1 {
+_mdio {
+   ext_rgmii_phy: ethernet-phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c22";
reg = <1>;
};
 };
-- 
2.14.1

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

[U-Boot] [PATCH v5 08/11] net: sun8i-emac: remove support for old binding

[Andre Przywara]

The original DT binding used by U-Boot's sun8i-emac driver was not really
agreed upon, and deviated from the "official" binding now used by the
kernel. Since now all U-Boot users have been converted to the new
binding, we can remove support for the old DT nodes from the driver.

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
---
 drivers/net/sun8i_emac.c | 78 
 1 file changed, 25 insertions(+), 53 deletions(-)

diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
index 55d82f86de..b6e5dafe83 100644
--- a/drivers/net/sun8i_emac.c
+++ b/drivers/net/sun8i_emac.c
@@ -456,7 +456,7 @@ static int parse_phy_pins(struct udevice *dev)
 {
int offset;
const char *pin_name;
-   int drive, pull, i;
+   int drive, pull = SUN4I_PINCTRL_NO_PULL, i;
 
offset = fdtdec_lookup_phandle(gd->fdt_blob, dev_of_offset(dev),
   "pinctrl-0");
@@ -476,31 +476,20 @@ static int parse_phy_pins(struct udevice *dev)
drive = SUN4I_PINCTRL_30_MA;
else
drive = SUN4I_PINCTRL_40_MA;
-   } else {
-   drive = fdt_getprop_u32_default_node(gd->fdt_blob, offset, 0,
-"allwinner,drive", 4);
}
 
if (fdt_get_property(gd->fdt_blob, offset, "bias-pull-up", NULL))
pull = SUN4I_PINCTRL_PULL_UP;
-   else if (fdt_get_property(gd->fdt_blob, offset, "bias-disable", NULL))
-   pull = SUN4I_PINCTRL_NO_PULL;
else if (fdt_get_property(gd->fdt_blob, offset, "bias-pull-down", NULL))
pull = SUN4I_PINCTRL_PULL_DOWN;
-   else
-   pull = fdt_getprop_u32_default_node(gd->fdt_blob, offset, 0,
-   "allwinner,pull", 0);
+
for (i = 0; ; i++) {
int pin;
 
pin_name = fdt_stringlist_get(gd->fdt_blob, offset,
- "allwinner,pins", i, NULL);
-   if (!pin_name) {
-   pin_name = fdt_stringlist_get(gd->fdt_blob, offset,
- "pins", i, NULL);
-   if (!pin_name)
-   break;
-   }
+ "pins", i, NULL);
+   if (!pin_name)
+   break;
 
pin = sunxi_name_to_gpio(pin_name);
if (pin < 0)
@@ -798,6 +787,7 @@ static int sun8i_emac_eth_ofdata_to_platdata(struct udevice 
*dev)
struct eth_pdata *pdata = _pdata->eth_pdata;
struct emac_eth_dev *priv = dev_get_priv(dev);
const char *phy_mode;
+   const fdt32_t *reg;
int node = dev_of_offset(dev);
int offset = 0;
 #ifdef CONFIG_DM_GPIO
@@ -805,35 +795,25 @@ static int sun8i_emac_eth_ofdata_to_platdata(struct 
udevice *dev)
int ret = 0;
 #endif
 
-   pdata->iobase = devfdt_get_addr_name(dev, "emac");
-   if (pdata->iobase == FDT_ADDR_T_NONE)
-   pdata->iobase = devfdt_get_addr(dev);
+   pdata->iobase = devfdt_get_addr(dev);
if (pdata->iobase == FDT_ADDR_T_NONE) {
debug("%s: Cannot find MAC base address\n", __func__);
return -EINVAL;
}
 
-   priv->sysctl_reg = devfdt_get_addr_name(dev, "syscon");
-   if (priv->sysctl_reg == FDT_ADDR_T_NONE) {
-   const fdt32_t *reg;
-
-   offset = fdtdec_lookup_phandle(gd->fdt_blob, node, "syscon");
-   if (offset < 0) {
-   debug("%s: cannot find syscon node\n", __func__);
-   return -EINVAL;
-   }
-   reg = fdt_getprop(gd->fdt_blob, offset, "reg", NULL);
-   if (!reg) {
-   debug("%s: cannot find reg property in syscon node\n",
- __func__);
-   return -EINVAL;
-   }
-   priv->sysctl_reg = fdt_translate_address((void *)gd->fdt_blob,
-offset, reg);
-   } else {
-   priv->sysctl_reg -= 0x30;
+   offset = fdtdec_lookup_phandle(gd->fdt_blob, node, "syscon");
+   if (offset < 0) {
+   debug("%s: cannot find syscon node\n", __func__);
+   return -EINVAL;
}
-
+   reg = fdt_getprop(gd->fdt_blob, offset, "reg", NULL);
+   if (!reg) {
+   debug("%s: cannot find reg property in syscon node\n",
+ __func__);
+   return -EINVAL;
+   }
+   priv->sysctl_reg = fdt_translate_address((void *)gd->fdt_blob,
+offset, reg);
if (priv->sysctl_reg == FDT_ADDR_T_NONE) {
debug("%s: Cannot find syscon base 

[U-Boot] [PATCH v5 10/11] sunxi: revert disabling of features

[Andre Przywara]

In January some commits were introduced to mitigate the U-Boot image
size issues we encountered on sunxi builds.
Now with the MMC environment removed we can bring them back, as we
practically don't have a size limit anymore.

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
---
 cmd/Kconfig   | 5 -
 drivers/video/Kconfig | 2 --
 lib/Kconfig   | 1 -
 3 files changed, 8 deletions(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 136836d146..27086df09b 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -426,7 +426,6 @@ menu "Memory commands"
 config CMD_CRC32
bool "crc32"
select HASH
-   default n if ARCH_SUNXI
default y
help
  Compute CRC32.
@@ -568,7 +567,6 @@ config CMD_LZMADEC
 
 config CMD_UNZIP
bool "unzip"
-   default n if ARCH_SUNXI
default y if CMD_BOOTI
help
  Uncompress a zip-compressed memory region.
@@ -780,14 +778,12 @@ config CMD_I2C
 
 config CMD_LOADB
bool "loadb"
-   default n if ARCH_SUNXI
default y
help
  Load a binary file over serial line.
 
 config CMD_LOADS
bool "loads"
-   default n if ARCH_SUNXI
default y
help
  Load an S-Record file over serial line
@@ -1187,7 +1183,6 @@ config CMD_GETTIME
 # TODO: rename to CMD_SLEEP
 config CMD_MISC
bool "sleep"
-   default n if ARCH_SUNXI
default y
help
  Delay execution for some time
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 2fc0defcd0..45a105db06 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -38,7 +38,6 @@ config BACKLIGHT_GPIO
 config VIDEO_BPP8
bool "Support 8-bit-per-pixel displays"
depends on DM_VIDEO
-   default n if ARCH_SUNXI
default y if DM_VIDEO
help
  Support drawing text and bitmaps onto a 8-bit-per-pixel display.
@@ -49,7 +48,6 @@ config VIDEO_BPP8
 config VIDEO_BPP16
bool "Support 16-bit-per-pixel displays"
depends on DM_VIDEO
-   default n if ARCH_SUNXI
default y if DM_VIDEO
help
  Support drawing text and bitmaps onto a 16-bit-per-pixel display.
diff --git a/lib/Kconfig b/lib/Kconfig
index a4029a67dd..436b90fa85 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -66,7 +66,6 @@ config PANIC_HANG
 
 config REGEX
bool "Enable regular expression support"
-   default n if ARCH_SUNXI
default y if NET
help
  If this variable is defined, U-Boot is linked against the
-- 
2.14.1

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

[U-Boot] [PATCH v5 05/11] arm: dts: sunxi: update A64 to new EMAC binding

[Andre Przywara]

The U-Boot driver for the sun8i-emac was using some preliminary DT
binding. Now since Linux got its own driver in v4.15 and our driver
can now cope with both bindings, let's convert the DT nodes used for the
Pine64+ board over to the new bindings used by the kernel.

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
---
 arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi | 51 +++--
 1 file changed, 30 insertions(+), 21 deletions(-)

diff --git a/arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi 
b/arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi
index 9c61beac01..32a263ce3d 100644
--- a/arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi
+++ b/arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi
@@ -4,25 +4,38 @@
};
 
soc {
-   emac: ethernet@01c3 {
+   syscon: syscon@1c0 {
+   compatible = "allwinner,sun50i-a64-system-controller",
+"syscon";
+   reg = <0x01c0 0x1000>;
+   };
+
+   emac: ethernet@1c3 {
compatible = "allwinner,sun50i-a64-emac";
-   reg = <0x01c3 0x2000>, <0x01c00030 0x4>;
-   reg-names = "emac", "syscon";
+   syscon = <>;
+   reg = <0x01c3 0x1>;
interrupts = ;
+   interrupt-names = "macirq";
resets = < RST_BUS_EMAC>;
-   reset-names = "ahb";
+   reset-names = "stmmaceth";
clocks = < CLK_BUS_EMAC>;
-   clock-names = "ahb";
+   clock-names = "stmmaceth";
#address-cells = <1>;
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <_pins>;
phy-mode = "rgmii";
-   phy = <>;
+   phy-handle = <_rgmii_phy>;
status = "okay";
 
-   phy1: ethernet-phy@1 {
-   reg = <1>;
+   mdio: mdio {
+   compatible = "snps,dwmac-mdio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   ext_rgmii_phy: ethernet-phy@1 {
+   compatible = 
"ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+   };
};
};
};
@@ -30,21 +43,17 @@
 
  {
rmii_pins: rmii_pins {
-   allwinner,pins = "PD10", "PD11", "PD13", "PD14",
-"PD17", "PD18", "PD19", "PD20",
-"PD22", "PD23";
-   allwinner,function = "emac";
-   allwinner,drive = <3>;
-   allwinner,pull = <0>;
+   pins = "PD10", "PD11", "PD13", "PD14", "PD17",
+  "PD18", "PD19", "PD20", "PD22", "PD23";
+   function = "emac";
+   drive-strength = <40>;
};
 
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>;
+   pins = "PD8", "PD9", "PD10", "PD11", "PD12",
+  "PD13", "PD15", "PD16", "PD17", "PD18",
+  "PD19", "PD20", "PD21", "PD22", "PD23";
+   function = "emac";
+   drive-strength = <40>;
};
 };
-- 
2.14.1

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

[U-Boot] [PATCH v5 01/11] sunxi: README.sunxi64: Add hint about non-debug of ARM Trusted Firmware

[Andre Przywara]

As we are running into issues where the final U-Boot FIT image file is
exceeding our size limit, add a hint to the README.sunxi64 file
to point out the possibility of building non-debug versions of the ATF
binary. These are about 12KB smaller than the standard debug build, and
so allow successful U-Boot builds for many boards with the Allwinner H5
SoC.
Please note that under normal circumstances the debug build is still
recommended, as it gives valuable clues in case something goes wrong in
the ATF.

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
---
 board/sunxi/README.sunxi64 | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/board/sunxi/README.sunxi64 b/board/sunxi/README.sunxi64
index 5a363d27b8..df1dbc818f 100644
--- a/board/sunxi/README.sunxi64
+++ b/board/sunxi/README.sunxi64
@@ -38,6 +38,12 @@ the root of your U-Boot build directory (or create a 
symbolic link).
 $ export BL31=/src/arm-trusted-firmware/build/sun50iw1p1/debug/bl31.bin
   (adjust the actual path accordingly)
 
+If you run into size issues with the resulting U-Boot image file, it might
+help to use a release build, by using "DEBUG=0" when building bl31.bin.
+As sometimes the ATF build process is a bit picky about the toolchain used,
+or if you can't be bothered with building ATF, there are known working
+binaries in the firmware repository[3], purely for convenience reasons.
+
  SPL/U-Boot
 
 Both U-Boot proper and the SPL are using the 64-bit mode. As the boot ROM
-- 
2.14.1

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

[U-Boot] [PATCH v5 02/11] sunxi: gpio: add missing compatible strings

[Andre Przywara]

The sunxi GPIO driver is missing some compatible strings for recent
SoCs. While most of the sunxi GPIO code seems to not rely on this (and
so works anyway), the sunxi_name_to_gpio() function does and fails at
the moment (for instance when resolving the MMC CD pin name).
Add the compatible strings for the A64 and V3s, which were missing
from the list. This now covers all pinctrl nodes in our own DTs.

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
---
 drivers/gpio/sunxi_gpio.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
index 3cf01b6e36..ea6f3593b9 100644
--- a/drivers/gpio/sunxi_gpio.c
+++ b/drivers/gpio/sunxi_gpio.c
@@ -354,12 +354,15 @@ static const struct udevice_id sunxi_gpio_ids[] = {
ID("allwinner,sun8i-a83t-pinctrl",  a_all),
ID("allwinner,sun8i-h3-pinctrl",a_all),
ID("allwinner,sun8i-r40-pinctrl",   a_all),
+   ID("allwinner,sun8i-v3s-pinctrl",   a_all),
ID("allwinner,sun9i-a80-pinctrl",   a_all),
+   ID("allwinner,sun50i-a64-pinctrl",  a_all),
ID("allwinner,sun6i-a31-r-pinctrl", l_2),
ID("allwinner,sun8i-a23-r-pinctrl", l_1),
ID("allwinner,sun8i-a83t-r-pinctrl",l_1),
ID("allwinner,sun8i-h3-r-pinctrl",  l_1),
ID("allwinner,sun9i-a80-r-pinctrl", l_3),
+   ID("allwinner,sun50i-a64-r-pinctrl",l_1),
{ }
 };
 
-- 
2.14.1

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

[U-Boot] [PATCH v5 00/11] sunxi: update H3/H5/A64 EMAC DT nodes

[Andre Przywara]

This is the first half of the DT update series, just updating the
EMAC DT nodes, for which the bindings have diverged.
Just fixed some checkpatch warnings and rebased (without conflicts)
against v2018.05-rc1.
As before, this includes the patches to drop the direct MMC environment
for all Allwinner boards, to finally get rid of the image size limitation.

Patch 01 leaves some hint in the README how to avoid the situation
when overrunning U-Boot's image size on 64-bit boards.
The old v2 EMAC DT update series is in patches 02-08, it prepares U-Boot's
EMAC driver for using the new DT binding used in Linux, also updates
the DTs to the new EMAC DT node already.

The final patches lift the space limit we currently have due to the raw
MMC environment.
Patch 09 disables that for all sunxi boards, to give us finally some
space. Patches 10 and 11 consequently revert the disabling of features we
saw a few weeks ago to migitate the size problem.

Cheers,
Andre.

Changelog v4 .. v5:
- drop Linux DT update patches for now
- fix minor checkpatch complaints

Changelog v3 .. v4:
- remove MMC environment for all Allwinner boards (including 32 bit ones)
- keep MMC environment offset to the old values
- drop DT adjustments to use fixed MMC regulator

Changelog v2 .. v3:
01: added, was on the list before
02: drop redundant H5 line
03-08: unchanged
09-20: added

Changelog v1 .. v2:
01, 02, 03: unchanged
04, 05, 06, 07: added

Andre Przywara (11):
  sunxi: README.sunxi64: Add hint about non-debug of ARM Trusted
Firmware
  sunxi: gpio: add missing compatible strings
  net: sun8i-emac: support new pinctrl DT bindings
  net: sun8i-emac: add support for new EMAC DT binding
  arm: dts: sunxi: update A64 to new EMAC binding
  arm: dts: sunxi: update H3 to new EMAC binding
  arm: dts: sunxi: update H5 to new EMAC binding
  net: sun8i-emac: remove support for old binding
  sunxi: disable direct MMC environment
  sunxi: revert disabling of features
  Revert "sunxi: Pine64: temporarily remove extra Pine64 non-plus DT"

 arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi | 51 --
 arch/arm/dts/sun50i-h5-orangepi-pc2.dts |  7 +-
 arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts|  6 +-
 arch/arm/dts/sun8i-h3-libretech-all-h3-cc.dts   |  7 +-
 arch/arm/dts/sun8i-h3-nanopi-neo.dts|  6 +-
 arch/arm/dts/sun8i-h3-orangepi-2.dts|  7 +-
 arch/arm/dts/sun8i-h3-orangepi-one.dts  |  7 +-
 arch/arm/dts/sun8i-h3-orangepi-pc.dts   |  7 +-
 arch/arm/dts/sun8i-h3-orangepi-plus.dts |  8 ++-
 arch/arm/dts/sun8i-h3-orangepi-plus2e.dts   |  9 ++-
 arch/arm/dts/sun8i-h3.dtsi  | 69 ++-
 board/sunxi/README.sunxi64  |  6 ++
 cmd/Kconfig |  5 --
 configs/pine64_plus_defconfig   |  1 +
 drivers/gpio/sunxi_gpio.c   |  3 +
 drivers/net/sun8i_emac.c| 89 ++---
 drivers/video/Kconfig   |  2 -
 env/Kconfig |  1 -
 lib/Kconfig |  1 -
 19 files changed, 185 insertions(+), 107 deletions(-)

-- 
2.14.1

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

[U-Boot] [PATCH 1/1] get_maintainer.pl: update from Linux kernel v4.16

[Heinrich Schuchardt]

The most significant change is the addition of the --self-test option
which allows to run a consistency check on all MAINTAINERS files.

Signed-off-by: Heinrich Schuchardt 
---
 scripts/get_maintainer.pl | 211 ++
 1 file changed, 193 insertions(+), 18 deletions(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 07800e62d1..e3b41616c9 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -57,6 +57,7 @@ my $sections = 0;
 my $file_emails = 0;
 my $from_filename = 0;
 my $pattern_depth = 0;
+my $self_test = undef;
 my $version = 0;
 my $help = 0;
 my $find_maintainer_files = 1;
@@ -136,6 +137,7 @@ my %VCS_cmds_git = (
 "subject_pattern" => "^GitSubject: (.*)",
 "stat_pattern" => "^(\\d+)\\t(\\d+)\\t\$file\$",
 "file_exists_cmd" => "git ls-files \$file",
+"list_files_cmd" => "git ls-files \$file",
 );
 
 my %VCS_cmds_hg = (
@@ -165,6 +167,7 @@ my %VCS_cmds_hg = (
 "subject_pattern" => "^HgSubject: (.*)",
 "stat_pattern" => "^(\\d+)\t(\\d+)\t\$file\$",
 "file_exists_cmd" => "hg files \$file",
+"list_files_cmd" => "hg manifest -R \$file",
 );
 
 my $conf = which_conf(".get_maintainer.conf");
@@ -214,6 +217,14 @@ if (-f $ignore_file) {
 close($ignore);
 }
 
+if ($#ARGV > 0) {
+foreach (@ARGV) {
+if ($_ =~ /^-{1,2}self-test(?:=|$)/) {
+die "$P: using --self-test does not allow any other option or 
argument\n";
+}
+}
+}
+
 if (!GetOptions(
'email!' => \$email,
'git!' => \$email_git,
@@ -250,6 +261,7 @@ if (!GetOptions(
'fe|file-emails!' => \$file_emails,
'f|file' => \$from_filename,
'find-maintainer-files' => \$find_maintainer_files,
+   'self-test:s' => \$self_test,
'v|version' => \$version,
'h|help|usage' => \$help,
)) {
@@ -266,6 +278,12 @@ if ($version != 0) {
 exit 0;
 }
 
+if (defined $self_test) {
+read_all_maintainer_files();
+self_test();
+exit 0;
+}
+
 if (-t STDIN && !@ARGV) {
 # We're talking to a terminal, but have no command line arguments.
 die "$P: missing patchfile or -f file - use --help if necessary\n";
@@ -309,14 +327,17 @@ if (!top_of_kernel_tree($lk_path)) {
 my @typevalue = ();
 my %keyword_hash;
 my @mfiles = ();
+my @self_test_info = ();
 
 sub read_maintainer_file {
 my ($file) = @_;
 
 open (my $maint, '<', "$file")
or die "$P: Can't open MAINTAINERS file '$file': $!\n";
+my $i = 1;
 while (<$maint>) {
my $line = $_;
+   chomp $line;
 
if ($line =~ m/^([A-Z]):\s*(.*)/) {
my $type = $1;
@@ -336,9 +357,12 @@ sub read_maintainer_file {
}
push(@typevalue, "$type:$value");
} elsif (!(/^\s*$/ || /^\s*\#/)) {
-   $line =~ s/\n$//g;
push(@typevalue, $line);
}
+   if (defined $self_test) {
+   push(@self_test_info, {file=>$file, linenr=>$i, line=>$line});
+   }
+   $i++;
 }
 close($maint);
 }
@@ -355,26 +379,30 @@ sub find_ignore_git {
 return grep { $_ !~ /^\.git$/; } @_;
 }
 
-if (-d "${lk_path}MAINTAINERS") {
-opendir(DIR, "${lk_path}MAINTAINERS") or die $!;
-my @files = readdir(DIR);
-closedir(DIR);
-foreach my $file (@files) {
-   push(@mfiles, "${lk_path}MAINTAINERS/$file") if ($file !~ /^\./);
+read_all_maintainer_files();
+
+sub read_all_maintainer_files {
+if (-d "${lk_path}MAINTAINERS") {
+opendir(DIR, "${lk_path}MAINTAINERS") or die $!;
+my @files = readdir(DIR);
+closedir(DIR);
+foreach my $file (@files) {
+push(@mfiles, "${lk_path}MAINTAINERS/$file") if ($file !~ /^\./);
+}
 }
-}
 
-if ($find_maintainer_files) {
-find( { wanted => \_is_maintainer_file,
-   preprocess => \_ignore_git,
-   no_chdir => 1,
-   }, "${lk_path}");
-} else {
-push(@mfiles, "${lk_path}MAINTAINERS") if -f "${lk_path}MAINTAINERS";
-}
+if ($find_maintainer_files) {
+find( { wanted => \_is_maintainer_file,
+preprocess => \_ignore_git,
+no_chdir => 1,
+}, "${lk_path}");
+} else {
+push(@mfiles, "${lk_path}MAINTAINERS") if -f "${lk_path}MAINTAINERS";
+}
 
-foreach my $file (@mfiles) {
-read_maintainer_file("$file");
+foreach my $file (@mfiles) {
+read_maintainer_file("$file");
+}
 }
 
 #
@@ -584,6 +612,135 @@ if ($web) {
 
 exit($exit);
 
+sub self_test {
+my @lsfiles = ();
+my @good_links = ();
+my @bad_links = ();
+my @section_headers = ();
+my $index = 0;
+
+@lsfiles = vcs_list_files($lk_path);
+
+for my $x (@self_test_info) {
+   $index++;
+
+   ## Section header duplication and missing section content
+   if (($self_test eq "" || $self_test =~ /\bsections\b/) &&
+   $x->{line} =~ 

Re: [U-Boot] [PATCH v2] timer: add High Precision Event Timers (HPET) support

[Ivan Gorinov]

On Tue, Apr 03, 2018 at 06:17:42AM -0600, Andy Shevchenko wrote:
> >> > If readq() is defined as two read operations in 32-bit code, main counter
> >> > rollover (low part overflow, high part increment) can happen between 
> >> > them.
> >> And how this contradicts ther current code?
> > It just does not make the code simpler,
> ...b/c you misread what I suggested.
> > rollover check is
> > still required if U-Boot is compiled as 32-bit code.
> > Can we do something like the following?
> Yes, but... why?
> What's wrong with replacing two sequential 32-bit reads with one 64-bit?

Doesn't readX/writeX imply a single I/O operation?
It may be misleading to define it as two.

Assuming MMX or SSE2 to be supported by all x86 processors, 64-bit I/O
registers can be accessed as a single operation even in 32-bit code:

static inline u64 readq(void *addr)
{
u64 value;

asm volatile ("movq (%0), %%xmm0" : : "r" (addr));
asm volatile ("movq %%xmm0, %0" : "=m" (value));

return value;
}

I can add these definitions to "asm/io.h".
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] MAINTAINERS: ARM STM STM32MP: correct file paths

[Heinrich Schuchardt]

Provide correct file paths.

Signed-off-by: Heinrich Schuchardt 
---
 MAINTAINERS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index fde77b2b61..510ad12a41 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -201,8 +201,8 @@ ARM STM STM32MP
 M: Patrick Delaunay 
 S: Maintained
 F: arch/arm/mach-stm32mp
-F: clk/clk_stm32mp1.c
-F: ram/stm32mp1
+F: drivers/clk/clk_stm32mp1.c
+F: drivers/ram/stm32mp1/
 
 ARM STM STV0991
 M: Vikas Manocha 
-- 
2.16.3

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

Re: [U-Boot] [linux-sunxi] Re: [PATCH 1/3] dm: Add migration plan for CONFIG_BLK

[Peter Korsgaard]

> "Tom" == Tom Rini  writes:

Hi,

 >> That seems like a good idea to me.

 > I've lamented before (and I think others have too) that it's really a
 > shame that gcc treats arm32 and arm64 as totally distinct builds (and
 > where clang is a win).  But I don't think we can require people to have
 > both an arm and an aarch64 compiler available in order to build U-Boot
 > for some aarch64.

No, please not. It would make it very hard to handle U-Boot builds in
Buildroot for these boards.

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

Re: [U-Boot] [PATCH] Makefile: Disable stack-usage check for ARC

[Tom Rini]

On Tue, Apr 03, 2018 at 08:27:20PM +, Alexey Brodkin wrote:
> Hi Tom,
> 
> On Tue, 2018-04-03 at 16:25 -0400, Tom Rini wrote:
> > On Tue, Apr 03, 2018 at 08:21:06PM +, Alexey Brodkin wrote:
> > > Hi Tom,
> > > 
> > > On Tue, 2018-04-03 at 16:17 -0400, Tom Rini wrote:
> > > > On Mon, Apr 02, 2018 at 12:18:02PM +0300, Alexey Brodkin wrote:
> > > > 
> > > > > With the most recent tools for ARC (arc-2017.09) in case of
> > > > > "naked" function compiler throws a warning:
> > > > > -->8-
> > > > > board/synopsys/hsdk/hsdk.c: In function 'hsdk_core_init_f':
> > > > > board/synopsys/hsdk/hsdk.c:345:1: warning: stack usage computation 
> > > > > not supported for this target
> > > > >  }
> > > > >  ^
> > > > > -->8-
> > > > > 
> > > > > That happens because the compiler doesn't handle "naked" functions
> > > > > as a special case where stack calculation shouldn't be done.
> > > > > 
> > > > > But for now until this is fixed in GCC to get clean buildman output
> > > > > we're disabling stack-usage check for ARC.
> > > > > 
> > > > > See https://lists.denx.de/pipermail/u-boot/2018-April/324455.html
> > > > > for more background.
> > > > > 
> > > > > Signed-off-by: Alexey Brodkin 
> > > > > Cc: Masahiro Yamada 
> > > > > Cc: Tom Rini 
> > > > 
> > > > Erm, this patch isn't working for me.  I take the current ARC PR, and
> > > > apply this, and I still see the warning showing up.
> > > 
> > > How do you see an issue?
> > > Could you please make sure arc-2017.09 tools are used but not arc-2016.09?
> > > See my change for TravisCI in the same PR.
> > 
> > ... but the patch here is disabling -fstack-usage altogether for ARC,
> > yes?
> 
> Right, but that's a temporary "patch" for the problem in hand.
> Once GCC 8.x gets released we'll just switch to it and that problem shouldn't
> bother us any longer.

OK.  But this patch doesn't work and we're trying -fstack-usage is the
problem I see :)

-- 
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] efi_loader: correctly determine the boot partition

[Heinrich Schuchardt]

The device path of the loaded image should be set to the partition
from which the image was loaded. This requires using the same logic as
the load command.

Without the patch the device path pointed to the whole disk after executing

load mmc 0: 0x4300 FILE

and not to the boot partition from which the file was actually loaded.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/bootefi.c | 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 412e6519ba..fd54c9925e 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -487,16 +487,6 @@ U_BOOT_CMD(
bootefi_help_text
 );
 
-static int parse_partnum(const char *devnr)
-{
-   const char *str = strchr(devnr, ':');
-   if (str) {
-   str++;
-   return simple_strtoul(str, NULL, 16);
-   }
-   return 0;
-}
-
 void efi_set_bootdev(const char *dev, const char *devnr, const char *path)
 {
char filename[32] = { 0 }; /* dp->str is u16[32] long */
@@ -504,12 +494,13 @@ void efi_set_bootdev(const char *dev, const char *devnr, 
const char *path)
 
if (strcmp(dev, "Net")) {
struct blk_desc *desc;
+   disk_partition_t fs_partition;
int part;
 
-   desc = blk_get_dev(dev, simple_strtol(devnr, NULL, 10));
-   if (!desc)
+   part = blk_get_device_part_str(dev, devnr, , _partition,
+  1);
+   if (part < 0)
return;
-   part = parse_partnum(devnr);
 
bootefi_device_path = efi_dp_from_part(desc, part);
} else {
-- 
2.16.3

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

[U-Boot] [PATCH 0/2] efi_loader: EFI_FILE_PROTOCOL

[Heinrich Schuchardt]

This patch series contains correction for the EFI_FILE_PROTOCOL.

The formation type EFI_FILE_SYSTEM_INFO in the service GetInfo()
of the EFI_FILE_PROTOCOL is implemented.

Heinrich Schuchardt (2):
  efi_loader: use correct types in EFI_FILE_PROTOCOL
  efi_loader: implement EFI_FILE_SYSTEM_INFO

 include/efi_api.h| 27 +++---
 include/efi_loader.h |  2 +
 lib/efi_loader/efi_boottime.c|  5 +-
 lib/efi_loader/efi_file.c| 81 +++-
 lib/efi_selftest/efi_selftest_block_device.c |  2 +-
 5 files changed, 96 insertions(+), 21 deletions(-)

-- 
2.16.3

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

[U-Boot] [PATCH 2/2] efi_loader: implement EFI_FILE_SYSTEM_INFO

[Heinrich Schuchardt]

Implement the information type EFI_FILE_SYSTEM_INFO in the service
GetInfo() of the EFI_FILE_PROTOCOL.

Signed-off-by: Heinrich Schuchardt 
---
 include/efi_api.h | 13 +
 include/efi_loader.h  |  2 ++
 lib/efi_loader/efi_file.c | 34 ++
 3 files changed, 49 insertions(+)

diff --git a/include/efi_api.h b/include/efi_api.h
index 43c8c891e7..16da736113 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -868,6 +868,10 @@ struct efi_simple_file_system_protocol {
EFI_GUID(0x9576e92, 0x6d3f, 0x11d2, \
 0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
 
+#define EFI_FILE_SYSTEM_INFO_GUID \
+   EFI_GUID(0x09576e93, 0x6d3f, 0x11d2, \
+0x8e, 0x39, 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
+
 #define EFI_FILE_MODE_READ 0x0001
 #define EFI_FILE_MODE_WRITE0x0002
 #define EFI_FILE_MODE_CREATE   0x8000
@@ -891,6 +895,15 @@ struct efi_file_info {
s16 file_name[0];
 };
 
+struct efi_file_system_info {
+   u64 size;
+   u8 read_only;
+   u64 volume_size;
+   u64 free_space;
+   u32 block_size;
+   u16 volume_label[0];
+};
+
 #define EFI_DRIVER_BINDING_PROTOCOL_GUID \
EFI_GUID(0x18a031ab, 0xb443, 0x4d1a,\
 0xa5, 0xc0, 0x0c, 0x09, 0x26, 0x1e, 0x9f, 0x71)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index ee553c667f..ab20773947 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -112,6 +112,8 @@ extern const efi_guid_t efi_guid_loaded_image;
 extern const efi_guid_t efi_guid_device_path_to_text_protocol;
 extern const efi_guid_t efi_simple_file_system_protocol_guid;
 extern const efi_guid_t efi_file_info_guid;
+/* GUID for file system information */
+extern const efi_guid_t efi_file_system_info_guid;
 extern const efi_guid_t efi_guid_device_path_utilities_protocol;
 
 extern unsigned int __efi_runtime_start, __efi_runtime_stop;
diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index 1e2751f7cf..37a999d0b2 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -12,6 +12,9 @@
 #include 
 #include 
 
+/* GUID for file system information */
+const efi_guid_t efi_file_system_info_guid = EFI_FILE_SYSTEM_INFO_GUID;
+
 struct file_system {
struct efi_simple_file_system_protocol base;
struct efi_device_path *dp;
@@ -472,6 +475,37 @@ static efi_status_t EFIAPI efi_file_getinfo(struct 
efi_file_handle *file,
info->attribute |= EFI_FILE_DIRECTORY;
 
ascii2unicode((u16 *)info->file_name, filename);
+   } else if (!guidcmp(info_type, _file_system_info_guid)) {
+   struct efi_file_system_info *info = buffer;
+   disk_partition_t part;
+   efi_uintn_t required_size;
+   int r;
+
+   if (fh->fs->part >= 1)
+   r = part_get_info(fh->fs->desc, fh->fs->part, );
+   else
+   r = part_get_info_whole_disk(fh->fs->desc, );
+   if (r < 0) {
+   ret = EFI_DEVICE_ERROR;
+   goto error;
+   }
+   required_size = sizeof(info) + 2 *
+   (strlen((const char *)part.name) + 1);
+   if (*buffer_size < required_size) {
+   *buffer_size = required_size;
+   ret = EFI_BUFFER_TOO_SMALL;
+   goto error;
+   }
+
+   memset(info, 0, required_size);
+
+   info->size = required_size;
+   info->read_only = true;
+   info->volume_size = part.size * part.blksz;
+   info->free_space = 0;
+   info->block_size = part.blksz;
+   ascii2unicode((u16 *)info->volume_label,
+ (const char *)part.name);
} else {
ret = EFI_UNSUPPORTED;
}
-- 
2.16.3

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

[U-Boot] [PATCH 1/2] efi_loader: use correct types in EFI_FILE_PROTOCOL

[Heinrich Schuchardt]

In the EFI_FILE_PROTOCOL buffer sizes and positions are passed as UINTN and
not as u64.

Signed-off-by: Heinrich Schuchardt 
---
 include/efi_api.h| 14 +
 lib/efi_loader/efi_boottime.c|  5 +--
 lib/efi_loader/efi_file.c| 47 +---
 lib/efi_selftest/efi_selftest_block_device.c |  2 +-
 4 files changed, 47 insertions(+), 21 deletions(-)

diff --git a/include/efi_api.h b/include/efi_api.h
index c8a41a499d..43c8c891e7 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -837,17 +837,19 @@ struct efi_file_handle {
efi_status_t (EFIAPI *close)(struct efi_file_handle *file);
efi_status_t (EFIAPI *delete)(struct efi_file_handle *file);
efi_status_t (EFIAPI *read)(struct efi_file_handle *file,
-   u64 *buffer_size, void *buffer);
+   efi_uintn_t *buffer_size, void *buffer);
efi_status_t (EFIAPI *write)(struct efi_file_handle *file,
-   u64 *buffer_size, void *buffer);
+   efi_uintn_t *buffer_size, void *buffer);
efi_status_t (EFIAPI *getpos)(struct efi_file_handle *file,
-   u64 *pos);
+   efi_uintn_t *pos);
efi_status_t (EFIAPI *setpos)(struct efi_file_handle *file,
-   u64 pos);
+   efi_uintn_t pos);
efi_status_t (EFIAPI *getinfo)(struct efi_file_handle *file,
-   efi_guid_t *info_type, u64 *buffer_size, void *buffer);
+   efi_guid_t *info_type, efi_uintn_t *buffer_size,
+   void *buffer);
efi_status_t (EFIAPI *setinfo)(struct efi_file_handle *file,
-   efi_guid_t *info_type, u64 buffer_size, void *buffer);
+   efi_guid_t *info_type, efi_uintn_t buffer_size,
+   void *buffer);
efi_status_t (EFIAPI *flush)(struct efi_file_handle *file);
 };
 
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index d15a131e74..7a9449f59c 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1513,7 +1513,7 @@ efi_status_t efi_load_image_from_path(struct 
efi_device_path *file_path,
struct efi_file_info *info = NULL;
struct efi_file_handle *f;
static efi_status_t ret;
-   uint64_t bs;
+   efi_uintn_t bs;
 
f = efi_file_from_path(file_path);
if (!f)
@@ -1534,7 +1534,8 @@ efi_status_t efi_load_image_from_path(struct 
efi_device_path *file_path,
if (ret)
goto error;
 
-   EFI_CALL(ret = f->read(f, >file_size, *buffer));
+   bs = info->file_size;
+   EFI_CALL(ret = f->read(f, , *buffer));
 
 error:
free(info);
diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index 52a4e7438e..1e2751f7cf 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -314,29 +314,41 @@ static efi_status_t dir_read(struct file_handle *fh, u64 
*buffer_size,
 }
 
 static efi_status_t EFIAPI efi_file_read(struct efi_file_handle *file,
-   u64 *buffer_size, void *buffer)
+efi_uintn_t *buffer_size, void *buffer)
 {
struct file_handle *fh = to_fh(file);
efi_status_t ret = EFI_SUCCESS;
+   u64 bs;
 
EFI_ENTRY("%p, %p, %p", file, buffer_size, buffer);
 
+   if (!buffer_size || !buffer) {
+   ret = EFI_INVALID_PARAMETER;
+   goto error;
+   }
+
if (set_blk_dev(fh)) {
ret = EFI_DEVICE_ERROR;
goto error;
}
 
+   bs = *buffer_size;
if (fh->isdir)
-   ret = dir_read(fh, buffer_size, buffer);
+   ret = dir_read(fh, , buffer);
else
-   ret = file_read(fh, buffer_size, buffer);
+   ret = file_read(fh, , buffer);
+   if (bs <= SIZE_MAX)
+   *buffer_size = bs;
+   else
+   *buffer_size = SIZE_MAX;
 
 error:
return EFI_EXIT(ret);
 }
 
 static efi_status_t EFIAPI efi_file_write(struct efi_file_handle *file,
-   u64 *buffer_size, void *buffer)
+ efi_uintn_t *buffer_size,
+ void *buffer)
 {
struct file_handle *fh = to_fh(file);
efi_status_t ret = EFI_SUCCESS;
@@ -363,21 +375,27 @@ error:
 }
 
 static efi_status_t EFIAPI efi_file_getpos(struct efi_file_handle *file,
-   u64 *pos)
+  efi_uintn_t *pos)
 {
struct file_handle *fh = to_fh(file);
+
EFI_ENTRY("%p, %p", file, pos);
-   *pos = fh->offset;
-   return EFI_EXIT(EFI_SUCCESS);
+
+   if (fh->offset <= SIZE_MAX) {
+   *pos = fh->offset;
+   return EFI_EXIT(EFI_SUCCESS);
+   } else {
+   return 

[U-Boot] [PATCH v2 6/6] arm: print information about loaded UEFI images

[Heinrich Schuchardt]

If an exception occurs in a UEFI loaded image we need the start address of
the image to determine the relocation offset.

This patch adds the necessary lines after the registers in the crash dump.
A possible output would be:

UEFI image
start 0x7fdb4000, size 0xa7b60
pc offset 0x72ca
/\snp.efi

With the offset 0x72ca we can now find the relevant instruction in the
disassembled 'snp.efi' binary.

Signed-off-by: Heinrich Schuchardt 
---
v2
no change
---
 arch/arm/lib/interrupts.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/lib/interrupts.c b/arch/arm/lib/interrupts.c
index 80869adb61..a28fef8f46 100644
--- a/arch/arm/lib/interrupts.c
+++ b/arch/arm/lib/interrupts.c
@@ -20,6 +20,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -51,6 +52,14 @@ void bad_mode (void)
reset_cpu (0);
 }
 
+static void show_efi_loaded_images(struct pt_regs *regs)
+{
+#if defined(CONFIG_EFI_LOADER) && \
+   !defined(CONFIG_SPL_BUILD) && !defined(API_BUILD)
+   efi_print_image_infos((void *)instruction_pointer(regs));
+#endif
+}
+
 void show_regs (struct pt_regs *regs)
 {
unsigned long __maybe_unused flags;
@@ -77,6 +86,7 @@ void show_regs (struct pt_regs *regs)
printf("sp : %08lx  ip : %08lx   fp : %08lx\n",
   regs->ARM_sp, regs->ARM_ip, regs->ARM_fp);
printf ("r10: %08lx  r9 : %08lx  r8 : %08lx\n",
+
regs->ARM_r10, regs->ARM_r9, regs->ARM_r8);
printf ("r7 : %08lx  r6 : %08lx  r5 : %08lx  r4 : %08lx\n",
regs->ARM_r7, regs->ARM_r6, regs->ARM_r5, regs->ARM_r4);
@@ -106,6 +116,7 @@ void do_undefined_instruction (struct pt_regs *pt_regs)
printf ("undefined instruction\n");
fixup_pc(pt_regs, -4);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
 }
 
@@ -115,6 +126,7 @@ void do_software_interrupt (struct pt_regs *pt_regs)
printf ("software interrupt\n");
fixup_pc(pt_regs, -4);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
 }
 
@@ -124,6 +136,7 @@ void do_prefetch_abort (struct pt_regs *pt_regs)
printf ("prefetch abort\n");
fixup_pc(pt_regs, -8);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
 }
 
@@ -133,6 +146,7 @@ void do_data_abort (struct pt_regs *pt_regs)
printf ("data abort\n");
fixup_pc(pt_regs, -8);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
 }
 
@@ -142,6 +156,7 @@ void do_not_used (struct pt_regs *pt_regs)
printf ("not used\n");
fixup_pc(pt_regs, -8);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
 }
 
@@ -151,6 +166,7 @@ void do_fiq (struct pt_regs *pt_regs)
printf ("fast interrupt request\n");
fixup_pc(pt_regs, -8);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
 }
 
@@ -160,5 +176,6 @@ void do_irq (struct pt_regs *pt_regs)
printf ("interrupt request\n");
fixup_pc(pt_regs, -8);
show_regs (pt_regs);
+   show_efi_loaded_images(pt_regs);
bad_mode ();
 }
-- 
2.16.3

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

[U-Boot] [PATCH v2 3/6] efi_loader: ImageSize must be multiple of SectionAlignment

[Heinrich Schuchardt]

According to the Portable Executable and Common Object File Format
Specification the image size must be a multiple of the alignment
of sections.

Signed-off-by: Heinrich Schuchardt 
---
v2
no change
---
 lib/efi_loader/efi_image_loader.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/efi_loader/efi_image_loader.c 
b/lib/efi_loader/efi_image_loader.c
index 7f602bbf4c..770efeffa3 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -176,6 +176,7 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
*loaded_image_info)
entry = efi_reloc + opt->AddressOfEntryPoint;
rel_size = opt->DataDirectory[rel_idx].Size;
rel = efi_reloc + opt->DataDirectory[rel_idx].VirtualAddress;
+   virt_size = ALIGN(virt_size, opt->SectionAlignment);
} else if (can_run_nt32 &&
   (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR32_MAGIC)) 
{
IMAGE_OPTIONAL_HEADER32 *opt = >OptionalHeader;
@@ -191,6 +192,7 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
*loaded_image_info)
entry = efi_reloc + opt->AddressOfEntryPoint;
rel_size = opt->DataDirectory[rel_idx].Size;
rel = efi_reloc + opt->DataDirectory[rel_idx].VirtualAddress;
+   virt_size = ALIGN(virt_size, opt->SectionAlignment);
} else {
printf("%s: Invalid optional header magic %x\n", __func__,
   nt->OptionalHeader.Magic);
-- 
2.16.3

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

[U-Boot] [PATCH v2 5/6] efi_loader: new functions to print loaded image information

[Heinrich Schuchardt]

Introduce functions to print information about loaded images.

If we want to analyze an exception in an EFI image we need the offset
between the PC and the start of the loaded image.

With efi_print_image_info() we can print the necessary information for a
single image, e.g.

UEFI image
start 0x7fdb4000, size 0xa7b60
pc offset 0x72ca
/\snp.efi

efi_print_image_infos() provides output for all loaded images.

Signed-off-by: Heinrich Schuchardt 
---
v2
GRUB does not allow the relocated address to be used as ImageBase
in the loaded image information. So the relocation address has to
be stored in an additional field.
---
 include/efi_loader.h  |  4 
 lib/efi_loader/efi_image_loader.c | 45 +++
 2 files changed, 49 insertions(+)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 0df482ee21..ee553c667f 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -306,6 +306,10 @@ efi_status_t efi_setup_loaded_image(
struct efi_device_path *file_path);
 efi_status_t efi_load_image_from_path(struct efi_device_path *file_path,
  void **buffer);
+/* Print information about a loaded image */
+efi_status_t efi_print_image_info(struct efi_loaded_image *image, void *pc);
+/* Print information about all loaded images */
+void efi_print_image_infos(void *pc);
 
 #ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER
 extern void *efi_bounce_buffer;
diff --git a/lib/efi_loader/efi_image_loader.c 
b/lib/efi_loader/efi_image_loader.c
index 770efeffa3..663def1039 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -22,6 +22,51 @@ const efi_guid_t efi_simple_file_system_protocol_guid =
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID;
 const efi_guid_t efi_file_info_guid = EFI_FILE_INFO_GUID;
 
+/*
+ * Print information about a loaded image.
+ *
+ * If the program counter is located within the image the offset to the base
+ * address is shown.
+ *
+ * @image: loaded image
+ * @pc:program counter (use NULL to suppress offset output)
+ * @return:status code
+ */
+efi_status_t efi_print_image_info(struct efi_loaded_image *image, void *pc)
+{
+   if (!image)
+   return EFI_INVALID_PARAMETER;
+   printf("UEFI image\nstart 0x%p, size 0x%llx\n",
+  image->reloc_base, image->reloc_size);
+   if (pc && pc >= image->reloc_base &&
+   pc < image->reloc_base + image->reloc_size)
+   printf("pc offset 0x%zx\n", pc - image->reloc_base);
+   if (image->file_path)
+   printf("%pD\n", image->file_path);
+   return EFI_SUCCESS;
+}
+
+/*
+ * Print information about all loaded images.
+ *
+ * @pc:program counter (use NULL to suppress offset output)
+ */
+void efi_print_image_infos(void *pc)
+{
+   struct efi_object *efiobj;
+   struct efi_handler *handler;
+
+   list_for_each_entry(efiobj, _obj_list, link) {
+   list_for_each_entry(handler, >protocols, link) {
+   if (!guidcmp(handler->guid, _guid_loaded_image)) {
+   printf("\n");
+   efi_print_image_info(
+   handler->protocol_interface, pc);
+   }
+   }
+   }
+}
+
 static efi_status_t efi_loader_relocate(const IMAGE_BASE_RELOCATION *rel,
unsigned long rel_size, void *efi_reloc)
 {
-- 
2.16.3

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

[U-Boot] [PATCH v2 1/6] efi_loader: use efi_uintn_t for LoadImage

[Heinrich Schuchardt]

We generally use efi_uintn_t where the UEFI spec uses UINTN.

Signed-off-by: Heinrich Schuchardt 
---
v2
Fix typo in commit message.
---
 include/efi_api.h | 2 +-
 lib/efi_loader/efi_boottime.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/efi_api.h b/include/efi_api.h
index 28de93a132..f138fc90ec 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -107,7 +107,7 @@ struct efi_boot_services {
efi_status_t (EFIAPI *load_image)(bool boot_policiy,
efi_handle_t parent_image,
struct efi_device_path *file_path, void *source_buffer,
-   unsigned long source_size, efi_handle_t *image);
+   efi_uintn_t source_size, efi_handle_t *image);
efi_status_t (EFIAPI *start_image)(efi_handle_t handle,
   unsigned long *exitdata_size,
   s16 **exitdata);
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index fd35ffa359..d15a131e74 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1568,14 +1568,14 @@ static efi_status_t EFIAPI efi_load_image(bool 
boot_policy,
  efi_handle_t parent_image,
  struct efi_device_path *file_path,
  void *source_buffer,
- unsigned long source_size,
+ efi_uintn_t source_size,
  efi_handle_t *image_handle)
 {
struct efi_loaded_image *info;
struct efi_object *obj;
efi_status_t ret;
 
-   EFI_ENTRY("%d, %p, %pD, %p, %ld, %p", boot_policy, parent_image,
+   EFI_ENTRY("%d, %p, %pD, %p, %zd, %p", boot_policy, parent_image,
  file_path, source_buffer, source_size, image_handle);
 
if (!image_handle || !parent_image) {
-- 
2.16.3

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

[U-Boot] [PATCH v2 2/6] efi_loader: save image relocation address and size

[Heinrich Schuchardt]

For analyzing crash output the relocation address and size are needed.
Save them in the loaded image info.

Signed-off-by: Heinrich Schuchardt 
---
v2
GRUB does not allow the relocated address to be used as ImageBase
in the loaded image information. So the relocation address has to
be stored in an additional field.
---
 include/efi_api.h | 2 ++
 lib/efi_loader/efi_image_loader.c | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/include/efi_api.h b/include/efi_api.h
index f138fc90ec..ca8e7849ff 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -331,6 +331,8 @@ struct efi_loaded_image {
 
/* Below are efi loader private fields */
 #ifdef CONFIG_EFI_LOADER
+   void *reloc_base;
+   aligned_u64 reloc_size;
efi_status_t exit_status;
struct jmp_buf_data exit_jmp;
 #endif
diff --git a/lib/efi_loader/efi_image_loader.c 
b/lib/efi_loader/efi_image_loader.c
index cac64ba9fe..7f602bbf4c 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -221,6 +222,8 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
*loaded_image_info)
/* Populate the loaded image interface bits */
loaded_image_info->image_base = efi;
loaded_image_info->image_size = image_size;
+   loaded_image_info->reloc_base = efi_reloc;
+   loaded_image_info->reloc_size = virt_size;
 
return entry;
 }
-- 
2.16.3

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

[U-Boot] [PATCH v2 0/6] efi_loader: fixes for loaded image protocol

[Heinrich Schuchardt]

This patch series fixes various bugs in the handling of loaded images.

The following new functionality is provided:

If a crash occurs the relocation information of loaded EFI images is
displayed.

---
v2
Merge with "efi_loader: print information about loaded UEFI images"
patch series.

GRUB does not allow the relocated address to be used as ImageBase
in the loaded image information. So the relocation address has to
be stored in an additional field.
---

Heinrich Schuchardt (6):
  efi_loader: use efi_uintn_t for LoadImage
  efi_loader: save image relocation address and size
  efi_loader: ImageSize must be multiple of SectionAlignment
  efi_loader: correct types for EFI_LOADED_IMAGE_PROTOCOL
  efi_loader: new functions to print loaded image information
  arm: print information about loaded UEFI images

 arch/arm/lib/interrupts.c | 17 +
 include/efi_api.h |  8 ---
 include/efi_loader.h  |  4 
 lib/efi_loader/efi_boottime.c |  4 ++--
 lib/efi_loader/efi_image_loader.c | 50 +++
 5 files changed, 78 insertions(+), 5 deletions(-)

-- 
2.16.3

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

[U-Boot] [PATCH v2 4/6] efi_loader: correct types for EFI_LOADED_IMAGE_PROTOCOL

[Heinrich Schuchardt]

We should not use void * but specific types for
* device_handle
* file_path

Signed-off-by: Heinrich Schuchardt 
---
v2
no change
---
 include/efi_api.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/efi_api.h b/include/efi_api.h
index ca8e7849ff..c8a41a499d 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -318,8 +318,8 @@ struct efi_loaded_image {
u32 revision;
void *parent_handle;
struct efi_system_table *system_table;
-   void *device_handle;
-   void *file_path;
+   efi_handle_t device_handle;
+   struct efi_device_path *file_path;
void *reserved;
u32 load_options_size;
void *load_options;
-- 
2.16.3

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

Re: [U-Boot] [PATCH] Makefile: Disable stack-usage check for ARC

[Alexey Brodkin]

Hi Tom,

On Tue, 2018-04-03 at 16:25 -0400, Tom Rini wrote:
> On Tue, Apr 03, 2018 at 08:21:06PM +, Alexey Brodkin wrote:
> > Hi Tom,
> > 
> > On Tue, 2018-04-03 at 16:17 -0400, Tom Rini wrote:
> > > On Mon, Apr 02, 2018 at 12:18:02PM +0300, Alexey Brodkin wrote:
> > > 
> > > > With the most recent tools for ARC (arc-2017.09) in case of
> > > > "naked" function compiler throws a warning:
> > > > -->8-
> > > > board/synopsys/hsdk/hsdk.c: In function 'hsdk_core_init_f':
> > > > board/synopsys/hsdk/hsdk.c:345:1: warning: stack usage computation not 
> > > > supported for this target
> > > >  }
> > > >  ^
> > > > -->8-
> > > > 
> > > > That happens because the compiler doesn't handle "naked" functions
> > > > as a special case where stack calculation shouldn't be done.
> > > > 
> > > > But for now until this is fixed in GCC to get clean buildman output
> > > > we're disabling stack-usage check for ARC.
> > > > 
> > > > See https://lists.denx.de/pipermail/u-boot/2018-April/324455.html
> > > > for more background.
> > > > 
> > > > Signed-off-by: Alexey Brodkin 
> > > > Cc: Masahiro Yamada 
> > > > Cc: Tom Rini 
> > > 
> > > Erm, this patch isn't working for me.  I take the current ARC PR, and
> > > apply this, and I still see the warning showing up.
> > 
> > How do you see an issue?
> > Could you please make sure arc-2017.09 tools are used but not arc-2016.09?
> > See my change for TravisCI in the same PR.
> 
> ... but the patch here is disabling -fstack-usage altogether for ARC,
> yes?

Right, but that's a temporary "patch" for the problem in hand.
Once GCC 8.x gets released we'll just switch to it and that problem shouldn't
bother us any longer.

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

Re: [U-Boot] [PATCH] Makefile: Disable stack-usage check for ARC

[Tom Rini]

On Tue, Apr 03, 2018 at 08:21:06PM +, Alexey Brodkin wrote:
> Hi Tom,
> 
> On Tue, 2018-04-03 at 16:17 -0400, Tom Rini wrote:
> > On Mon, Apr 02, 2018 at 12:18:02PM +0300, Alexey Brodkin wrote:
> > 
> > > With the most recent tools for ARC (arc-2017.09) in case of
> > > "naked" function compiler throws a warning:
> > > -->8-
> > > board/synopsys/hsdk/hsdk.c: In function 'hsdk_core_init_f':
> > > board/synopsys/hsdk/hsdk.c:345:1: warning: stack usage computation not 
> > > supported for this target
> > >  }
> > >  ^
> > > -->8-
> > > 
> > > That happens because the compiler doesn't handle "naked" functions
> > > as a special case where stack calculation shouldn't be done.
> > > 
> > > But for now until this is fixed in GCC to get clean buildman output
> > > we're disabling stack-usage check for ARC.
> > > 
> > > See https://lists.denx.de/pipermail/u-boot/2018-April/324455.html
> > > for more background.
> > > 
> > > Signed-off-by: Alexey Brodkin 
> > > Cc: Masahiro Yamada 
> > > Cc: Tom Rini 
> > 
> > Erm, this patch isn't working for me.  I take the current ARC PR, and
> > apply this, and I still see the warning showing up.
> 
> How do you see an issue?
> Could you please make sure arc-2017.09 tools are used but not arc-2016.09?
> See my change for TravisCI in the same PR.

... but the patch here is disabling -fstack-usage altogether for ARC,
yes?

-- 
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] [PATCH] Makefile: Disable stack-usage check for ARC

[Alexey Brodkin]

Hi Tom,

On Tue, 2018-04-03 at 16:17 -0400, Tom Rini wrote:
> On Mon, Apr 02, 2018 at 12:18:02PM +0300, Alexey Brodkin wrote:
> 
> > With the most recent tools for ARC (arc-2017.09) in case of
> > "naked" function compiler throws a warning:
> > -->8-
> > board/synopsys/hsdk/hsdk.c: In function 'hsdk_core_init_f':
> > board/synopsys/hsdk/hsdk.c:345:1: warning: stack usage computation not 
> > supported for this target
> >  }
> >  ^
> > -->8-
> > 
> > That happens because the compiler doesn't handle "naked" functions
> > as a special case where stack calculation shouldn't be done.
> > 
> > But for now until this is fixed in GCC to get clean buildman output
> > we're disabling stack-usage check for ARC.
> > 
> > See https://lists.denx.de/pipermail/u-boot/2018-April/324455.html
> > for more background.
> > 
> > Signed-off-by: Alexey Brodkin 
> > Cc: Masahiro Yamada 
> > Cc: Tom Rini 
> 
> Erm, this patch isn't working for me.  I take the current ARC PR, and
> apply this, and I still see the warning showing up.

How do you see an issue?
Could you please make sure arc-2017.09 tools are used but not arc-2016.09?
See my change for TravisCI in the same PR.

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

Re: [U-Boot] [PATCH] Makefile: Disable stack-usage check for ARC

[Tom Rini]

On Mon, Apr 02, 2018 at 12:18:02PM +0300, Alexey Brodkin wrote:

> With the most recent tools for ARC (arc-2017.09) in case of
> "naked" function compiler throws a warning:
> -->8-
> board/synopsys/hsdk/hsdk.c: In function 'hsdk_core_init_f':
> board/synopsys/hsdk/hsdk.c:345:1: warning: stack usage computation not 
> supported for this target
>  }
>  ^
> -->8-
> 
> That happens because the compiler doesn't handle "naked" functions
> as a special case where stack calculation shouldn't be done.
> 
> But for now until this is fixed in GCC to get clean buildman output
> we're disabling stack-usage check for ARC.
> 
> See https://lists.denx.de/pipermail/u-boot/2018-April/324455.html
> for more background.
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Masahiro Yamada 
> Cc: Tom Rini 

Erm, this patch isn't working for me.  I take the current ARC PR, and
apply this, and I still see the warning showing up.

-- 
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] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK

[Tom Rini]

On Wed, Apr 04, 2018 at 01:53:17AM +0800, Simon Glass wrote:
> Hi Andre,
> 
> On 2 April 2018 at 19:00, André Przywara  wrote:
> > Hi,
> >
> > On 02/04/18 03:30, Simon Glass wrote:
> >>
> >> Hi Andre,
> >>
> >> On 2 April 2018 at 09:43, André Przywara  wrote:
> >>> Hi,
> >>>
> >>> On 01/04/18 14:19, Tom Rini wrote:
>  On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote:
> > On Mon, Sep 4, 2017 at 9:57 PM,   wrote:
> >> Hi Tom,
> >>
> >> On 7 August 2017 at 09:39, Tom Rini  wrote:
> >>> On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote:
> >>>
>  The CONFIG_BLK conversion involves quite invasive changes in the 
>  U-Boot
>  code, with #ifdefs and different code paths. We should try to move 
>  over to
>  this soon so we can drop the old code.
> >
> > I hope this will applicable to SPL too?
> >
> > If so, we are having SPL size issues with few Allwinner families, if
> > enable SPL_DM any suggestions?
> 
>  How close, and have you looked at the u-boot-spl.map to see what you can
>  maybe trim?  Or areas to look at reducing in code complexity?
> >>>
> >>> The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64
> >>> SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map
> >>> and picked most low hanging fruits already.
> >>> So far we discussed several mitigations, but mostly to cover the
> >>> "natural" SPL code size grow over time:
> >>> 1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of
> >>> padding (for a 2KB architectural alignment). Given that the vectors are
> >>> used only for debugging purposes, we could scrap them entirely or
> >>> construct them on the fly in some other SRAM. So would free about 2.5KB,
> >>> ideally. Lowest hanging fruit so far.
> >>> 2) We can compile the SPL in AArch32 mode, which can use the Thumb2
> >>> encoding. This reduces the size significantly, to about 20KB. The
> >>> disadvantage is using a second cross-compiler or even a additional
> >>> cross-compiler for native builds, complicating the build process.
> >>> I maintain a branch for enabling FEL booting here [1], which provides
> >>> two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper).
> >>> There are no technical disadvantages in running the SPL in 32-bit, so
> >>> this is mostly a build issue.
> >>
> >> FYI 32-bit tegra compiles SPL with ARMv4T and U-Boot proper with
> >> ARMv7. It should be fairly easy to do,
> >
> > Yes, but this is merely different compiler *flags*, to the same (cross)
> > compiler binary. ARM32 and ARM64 are different architectures to GCC, so
> > require different compiler binaries with different prefixes.
> > Last time I checked this wasn't easy to integrate into the U-Boot build
> > system.
> > One hack could be a "switching script", which filters for, say -m32",
> > and calls the respective binary. But still we need to somehow set *two*
> > CROSS_COMPILE prefixes. CROSS_COMPILE_SPL, maybe?
> > But still it would require to install *two* cross compilers, and would
> > spoil a completely native build by still requiring a cross compiler.
> 
> That seems like a good idea to me.

I've lamented before (and I think others have too) that it's really a
shame that gcc treats arm32 and arm64 as totally distinct builds (and
where clang is a win).  But I don't think we can require people to have
both an arm and an aarch64 compiler available in order to build U-Boot
for some aarch64.

> 
> >
> >>> 3) Try to use ILP32 for the AArch64 SPL build. This reduces the pointer
> >>> size and sizeof(long) to be 32-bit and should help, though I haven't
> >>> been able to successfully compile it yet (relocation types problems).
> >>> Despite lacking mainline support for AArch64 ILP32 in Linux and
> >>> glibc(?), GCC supports it for quite a while already. Unknown saving 
> >>> effect.
> >>> 4) Use runtime decompression. Most SoCs have larger or more SRAM than
> >>> the 32KB, so we could leverage this. Siarhei knows more about this.
> >>> 5) Use a TPL. Haven't looked at this in detail yet.

Here, my preference would be to again look at (4) then (3).  I think a
(5) TPL here would be enough of a something to get DDR available so that
SPL can run there and not be subject to the tiny limits.  But I have no
idea how feasible that is here.

-- 
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] efi_loader: completely initialize network

[Heinrich Schuchardt]

Add missing network initialization code.

Before the patch the network was only usable if a network command like
dhcp or tftp had beed executed.

This was visible when interrupting the console countdown and executing
bootefi selftest for vexpress_ca15_tc2_defconfig.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_net.c | 36 ++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c
index 3d860e658e..9afe76cdb3 100644
--- a/lib/efi_loader/efi_net.c
+++ b/lib/efi_loader/efi_net.c
@@ -54,14 +54,46 @@ static efi_status_t EFIAPI efi_net_stop(struct 
efi_simple_network *this)
return EFI_EXIT(EFI_SUCCESS);
 }
 
+/*
+ * Initialize network adapter and allocate transmit and receive buffers.
+ *
+ * This function implements the Initialize service of the
+ * EFI_SIMPLE_NETWORK_PROTOCOL. See the Unified Extensible Firmware Interface
+ * (UEFI) specification for details.
+ *
+ * @this:  pointer to the protocol instance
+ * @extra_rx:  extra receive buffer to be allocated
+ * @extra_tx:  extra transmit buffer to be allocated
+ * @return:status code
+ */
 static efi_status_t EFIAPI efi_net_initialize(struct efi_simple_network *this,
  ulong extra_rx, ulong extra_tx)
 {
+   int ret;
+   efi_status_t r = EFI_SUCCESS;
+
EFI_ENTRY("%p, %lx, %lx", this, extra_rx, extra_tx);
 
-   eth_init();
+   if (!this) {
+   r = EFI_INVALID_PARAMETER;
+   goto error;
+   }
 
-   return EFI_EXIT(EFI_SUCCESS);
+   /* Setup packet buffers */
+   net_init();
+   /* Disable hardware and put it into the reset state */
+   eth_halt();
+   /* Set current device according to environment variables */
+   eth_set_current();
+   /* Get hardware ready for send and receive operations */
+   ret = eth_init();
+   if (ret < 0) {
+   eth_halt();
+   r = EFI_DEVICE_ERROR;
+   }
+
+error:
+   return EFI_EXIT(r);
 }
 
 static efi_status_t EFIAPI efi_net_reset(struct efi_simple_network *this,
-- 
2.16.3

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

[U-Boot] [PATCH v2 0/3] efi_loader: armv7: enable unaligned access

[Heinrich Schuchardt]

We use the command bootefi to run UEFI executables like GRUB and iPXE.
The UEFI spec requires that unaligned access is enabled if the CPU
supports it. This is true for armv7.

So we should not set bit 1 of the system control register, the alignment
bit.

Without this patch iPXE snp.efi cannot be executed on armv7,
e.g. Allwinner A20.

As suggested by Siarhei unaligned access is only enabled in the EFI
subsystem. This allows unintended unaligned access in the rest of U-Boot
to become evident in testing.

---
v2
Enable unaligned access only in EFI subsystem.
---

Heinrich Schuchardt (3):
  efi_loader: allow unaligned memory access
  arm: armv7: allow unaligned memory access
  efi_selftest: test unaligned memory access

 arch/arm/cpu/armv7/Makefile   |  4 ++
 arch/arm/cpu/armv7/sctlr.S| 23 +++
 cmd/bootefi.c | 13 ++
 include/asm-generic/unaligned.h   |  3 ++
 lib/efi_selftest/Makefile |  4 ++
 lib/efi_selftest/efi_selftest_unaligned.c | 66 +++
 6 files changed, 113 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/sctlr.S
 create mode 100644 lib/efi_selftest/efi_selftest_unaligned.c

-- 
2.16.3

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

[U-Boot] [PATCH v2 2/3] arm: armv7: allow unaligned memory access

[Heinrich Schuchardt]

The UEFI spec mandates that unaligned memory access should be enabled if
supported by the CPU architecture.

This patch implements the function unaligned_access() to reset the aligned
access flag in the system control register (SCTLR). It is called when the
bootefi command is invoked.

Signed-off-by: Heinrich Schuchardt 
---
 arch/arm/cpu/armv7/Makefile |  4 
 arch/arm/cpu/armv7/sctlr.S  | 23 +++
 2 files changed, 27 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/sctlr.S

diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index b14ee54519..cdb56e490b 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -12,6 +12,10 @@ obj-y+= cache_v7.o cache_v7_asm.o
 obj-y  += cpu.o cp15.o
 obj-y  += syslib.o
 
+ifneq ($(CONFIG_SPL_BUILD),y)
+obj-$(CONFIG_EFI_LOADER) += sctlr.o
+endif
+
 ifneq ($(CONFIG_SKIP_LOWLEVEL_INIT),y)
 obj-y  += lowlevel_init.o
 endif
diff --git a/arch/arm/cpu/armv7/sctlr.S b/arch/arm/cpu/armv7/sctlr.S
new file mode 100644
index 00..cfdb7d2a52
--- /dev/null
+++ b/arch/arm/cpu/armv7/sctlr.S
@@ -0,0 +1,23 @@
+/*
+ *  Routines to access the system control register
+ *
+ *  Copyright (c) 2018 Heinrich Schuchardt
+ *
+ *  SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+
+/*
+ * void allow_unaligned(void) - allow unaligned access
+ *
+ * This routine clears the aligned flag in the system control register.
+ * After calling this routine unaligned access does no longer lead to a
+ * data abort but is handled by the CPU.
+ */
+ENTRY(allow_unaligned)
+   mrc p15, 0, r0, c1, c0, 0   @ load system control register
+   bic r0, r0, #2  @ clear aligned flag
+   mcr p15, 0, r0, c1, c0, 0   @ write system control register
+   bx  lr  @ return
+ENDPROC(allow_unaligned)
-- 
2.16.3

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

[U-Boot] [PATCH v2 1/3] efi_loader: allow unaligned memory access

[Heinrich Schuchardt]

The UEFI spec mandates that unaligned memory access should be enabled if
supported by the CPU architecture.

This patch adds an empty weak function unaligned_access() that can be
overridden by an architecture specific routine.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/bootefi.c   | 13 +
 include/asm-generic/unaligned.h |  3 +++
 2 files changed, 16 insertions(+)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index ba258ac9f3..412e6519ba 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -89,6 +90,15 @@ out:
return ret;
 }
 
+/*
+ * Allow unaligned memory access.
+ *
+ * This routine is overridden by architectures providing this feature.
+ */
+void __weak allow_unaligned(void)
+{
+}
+
 /*
  * Set the load options of an image from an environment variable.
  *
@@ -351,6 +361,9 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
efi_status_t r;
void *fdt_addr;
 
+   /* Allow unaligned memory access */
+   allow_unaligned();
+
/* Initialize EFI drivers */
r = efi_init_obj_list();
if (r != EFI_SUCCESS) {
diff --git a/include/asm-generic/unaligned.h b/include/asm-generic/unaligned.h
index fd0255099a..3d33a5a063 100644
--- a/include/asm-generic/unaligned.h
+++ b/include/asm-generic/unaligned.h
@@ -20,4 +20,7 @@
 #error invalid endian
 #endif
 
+/* Allow unaligned memory access */
+void allow_unaligned(void);
+
 #endif
-- 
2.16.3

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

[U-Boot] [PATCH v2 3/3] efi_selftest: test unaligned memory access

[Heinrich Schuchardt]

According to the UEFI spec unaligned memory access should be enabled on
CPUs supporting it.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_selftest/Makefile |  4 ++
 lib/efi_selftest/efi_selftest_unaligned.c | 67 +++
 2 files changed, 71 insertions(+)
 create mode 100644 lib/efi_selftest/efi_selftest_unaligned.c

diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
index 31b444fc8b..2ca58cebe4 100644
--- a/lib/efi_selftest/Makefile
+++ b/lib/efi_selftest/Makefile
@@ -31,6 +31,10 @@ efi_selftest_tpl.o \
 efi_selftest_util.o \
 efi_selftest_watchdog.o
 
+ifeq ($(CONFIG_CMD_BOOTEFI_SELFTEST),y)
+obj-$(CONFIG_CPU_V7) += efi_selftest_unaligned.o
+endif
+
 ifeq ($(CONFIG_BLK)$(CONFIG_PARTITIONS),yy)
 obj-$(CONFIG_CMD_BOOTEFI_SELFTEST) += efi_selftest_block_device.o
 endif
diff --git a/lib/efi_selftest/efi_selftest_unaligned.c 
b/lib/efi_selftest/efi_selftest_unaligned.c
new file mode 100644
index 00..f799c6dd0f
--- /dev/null
+++ b/lib/efi_selftest/efi_selftest_unaligned.c
@@ -0,0 +1,67 @@
+/*
+ * efi_selftest_unaligned
+ *
+ * Copyright (c) 2018 Heinrich Schuchardt 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ *
+ * Test unaligned memory access on ARMv7.
+ */
+
+#include 
+
+struct aligned_buffer {
+   char a[8] __aligned(8);
+};
+
+/*
+ * Return an u32 at a give address.
+ * If the address is not four byte aligned, an unaligned memory access
+ * occurs.
+ *
+ * @addr:  address to read
+ * @return:value at the address
+ */
+static inline u32 deref(u32 *addr)
+{
+   int ret;
+
+   asm(
+   "ldr %[out], [%[in]]\n\t"
+   : [out] "=r" (ret)
+   : [in] "r" (addr)
+   );
+   return ret;
+}
+
+/*
+ * Execute unit test.
+ * An unaligned memory access is executed. The result is checked.
+ *
+ * @return:EFI_ST_SUCCESS for success
+ */
+static int execute(void)
+{
+   struct aligned_buffer buf = {
+   {0, 1, 2, 3, 4, 5, 6, 7},
+   };
+   void *v = 
+   u32 r = 0;
+
+   /* Read an unaligned address */
+   r = deref(v + 1);
+
+   /* UEFI only supports low endian systems */
+   if (r != 0x04030201) {
+   efi_st_error("Unaligned access failed");
+   return EFI_ST_FAILURE;
+   }
+
+   return EFI_ST_SUCCESS;
+}
+
+EFI_UNIT_TEST(unaligned) = {
+   .name = "unaligned memory access",
+   .phase = EFI_EXECUTE_BEFORE_BOOTTIME_EXIT,
+   .execute = execute,
+};
-- 
2.16.3

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

Re: [U-Boot] [linux-sunxi] Re: [PATCH v2 5/6] sunxi: add code for recalculating the DRAM size in U-Boot

[André Przywara]

On 03/04/18 15:13, Siarhei Siamashka wrote:

Hi Siarhei,

thanks for chiming in!

> On Tue, 3 Apr 2018 13:43:43 +0100
> Andre Przywara  wrote:
>> On 03/04/18 12:51, Icenowy Zheng wrote:



 I guess we'd need to find another way (put some information in an
 SRAM somewhere?) to try to do that for all variants.  
>>>
>>> Extend the SPL header again? If we found SPL v3+, use
>>> the DRAM size encoded and bypass ram_get_size,
>>> otherwise fallback to ram_get_size?  
>>
>> Yes, that would be a possibility as well. Though I believe at the moment
>> we don't access the SPL header from U-Boot proper, do we?
> 
> We do. The boot device and also the boot.scr location (in the case of
> FEL boot) is read from the SPL header by the main U-Boot part.

Ah, true, forgot about that. Even better then.

>> Not a real show-stopper, but we probably need to document that the SPL
>> header would need to stay around.
> 
> Maybe.
> 
>> But if we have a fallback anyway ...
> 
> Which fallback? Do you mean calling things like ram_get_size()
> from U-Boot?

Yes, that was what Icenowy suggested: If SPL version > 2, we use the
information from there, otherwise we fall back to the current behaviour,
which is to ride through the DRAM and hope for the best.
Though I am not sure this is really needed, as I don't see a strong
reason to combine different versions of SPL and U-Boot proper (apart
from FEL, maybe).

> We should never do this because this is very wrong.

I mostly agree, though it's not too bad, since we have quite a
controlled environment. But if we can get rid of it: Yes, we should.

> The D-Cache may be already enabled, causing all kinds of weird
> effects. Also modifying data in DRAM (even temporarily) while
> our code is already running from DRAM is dangerous.

I don't see immediately how the D$ could get nasty here, but as I said
above, we should do it.

>>> (Although it will lead to some days of mess on sunxi-tools,
>>> this is a reasonable choice.)  
>>
>> True, but actually I wonder why we have SPL_MAX_VERSION in there in the
>> first place. Can't we just postulate that every new SPL version stays
>> backwards compatible? So if sunxi-tools can deal with v2, a v3 SPL would
>> still be fine, you would just loose the v3 features (if at all)?
>> We can just put a warning in there, to ask users to upgrade.
>> That would have worked already with the v1/v2 transition, I believe.
> 
> Yes, that's more or less how this was supposed to work in sunxi-tools
> from the very beginning. Except that we unfortunately got a bug in
> this code, which has been reported back in July 2017 and is still not
> resolved due to various reasons:

Well, that sounds more like a design issue to me: Defining the latest
currently supported version as the maximum.

>https://github.com/linux-sunxi/sunxi-tools/issues/104
> 
> But hopefully it can be fixed sooner or later.

I think we can do it now, see below.

>> Probably worth a separate discussion with some sunxi-tools stakeholders.
> 
> On the U-Boot side we can just increase the version number as long as
> the new header is a backwards compatible superset of the old one.
> 
> In the unlikely case if we suddenly have to introduce a compatibility
> breaking change to the SPL header format, we can always change the SPL
> header signature from 'SPL' to something else.

Or we could introduce some major/minor scheme, with a major change
breaking compatibility, whereas a minor change does not.
Then we split the uint8_t version into 2 bits of major and 6 bits of
minor, for instance.
So we just document this and bump SPL_MAX_VERSION now to 0x3f and are
good for a while.

Thoughts?

Cheers,
Andre.

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

Re: [U-Boot] [PATCH v2 u-boot 1/2] clk: Add get/enable/disable/release for a bulk of clocks

[Simon Glass]

On 3 April 2018 at 17:44, Neil Armstrong  wrote:
> This patch adds a "bulk" API to the clock API in order to get/enable/disable
> /release a group of clocks associated with a device.
>
> This bulk API will avoid adding a copy of the same code to manage
> a group of clocks in drivers.
>
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/clk/clk-uclass.c | 59 +++
>  include/clk.h| 72 
> +++-
>  2 files changed, 130 insertions(+), 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 v2 u-boot 1/2] reset: Add get/assert/deassert/release for bulk of reset signals

[Simon Glass]

On 3 April 2018 at 17:40, Neil Armstrong  wrote:
> This patch adds a "bulk" API to the reset API in order to get/deassert/
> assert/release a group of reset signals associated with a device.
>
> This bulk API will avoid adding a copy of the same code to manage
> a group of reset signals in drivers.
>
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/reset/reset-uclass.c | 60 +++
>  include/reset.h  | 99 
> 
>  2 files changed, 159 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 v2 u-boot 2/2] reset: add sandbox test for bulk API

[Simon Glass]

On 3 April 2018 at 17:40, Neil Armstrong  wrote:
> This patch adds the bulk reset API tests for the sandbox test suite.
>
> Unlike the main test, it also check the "other" reset signal using the bulk 
> API
> and checks if the resets are correctly asserted/deasserted.
>
> To allow the bulk API to work, and avoid changing the DT, the number of resets
> of the sandbox reset controller has been bumped to 101 for the "other" reset
> line to be valid.

Does it need to be 101, or would, say, 5 be enough?

>
> Signed-off-by: Neil Armstrong 
> ---
>  arch/sandbox/include/asm/reset.h   |  4 
>  drivers/reset/sandbox-reset-test.c | 29 +
>  drivers/reset/sandbox-reset.c  |  2 +-
>  test/dm/reset.c| 33 +
>  4 files changed, 67 insertions(+), 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 v2 u-boot 2/2] clk: add sandbox test for bulk API

[Simon Glass]

On 3 April 2018 at 17:44, Neil Armstrong  wrote:
> This patch adds the bulk clock API tests for the sandbox test suite.
>
> It's very similar to the main test but only uses the _bulk() API and
> checks if the clocks are correctly enabled/disabled.
>
> Signed-off-by: Neil Armstrong 
> ---
>  arch/sandbox/include/asm/clk.h | 32 
>  drivers/clk/clk_sandbox_test.c | 29 +
>  test/dm/clk.c  | 38 ++
>  3 files changed, 99 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/3] dm: Add migration plan for CONFIG_BLK

[Simon Glass]

Hi Andre,

On 2 April 2018 at 19:00, André Przywara  wrote:
> Hi,
>
> On 02/04/18 03:30, Simon Glass wrote:
>>
>> Hi Andre,
>>
>> On 2 April 2018 at 09:43, André Przywara  wrote:
>>> Hi,
>>>
>>> On 01/04/18 14:19, Tom Rini wrote:
 On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote:
> On Mon, Sep 4, 2017 at 9:57 PM,   wrote:
>> Hi Tom,
>>
>> On 7 August 2017 at 09:39, Tom Rini  wrote:
>>> On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote:
>>>
 The CONFIG_BLK conversion involves quite invasive changes in the U-Boot
 code, with #ifdefs and different code paths. We should try to move 
 over to
 this soon so we can drop the old code.
>
> I hope this will applicable to SPL too?
>
> If so, we are having SPL size issues with few Allwinner families, if
> enable SPL_DM any suggestions?

 How close, and have you looked at the u-boot-spl.map to see what you can
 maybe trim?  Or areas to look at reducing in code complexity?
>>>
>>> The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64
>>> SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map
>>> and picked most low hanging fruits already.
>>> So far we discussed several mitigations, but mostly to cover the
>>> "natural" SPL code size grow over time:
>>> 1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of
>>> padding (for a 2KB architectural alignment). Given that the vectors are
>>> used only for debugging purposes, we could scrap them entirely or
>>> construct them on the fly in some other SRAM. So would free about 2.5KB,
>>> ideally. Lowest hanging fruit so far.
>>> 2) We can compile the SPL in AArch32 mode, which can use the Thumb2
>>> encoding. This reduces the size significantly, to about 20KB. The
>>> disadvantage is using a second cross-compiler or even a additional
>>> cross-compiler for native builds, complicating the build process.
>>> I maintain a branch for enabling FEL booting here [1], which provides
>>> two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper).
>>> There are no technical disadvantages in running the SPL in 32-bit, so
>>> this is mostly a build issue.
>>
>> FYI 32-bit tegra compiles SPL with ARMv4T and U-Boot proper with
>> ARMv7. It should be fairly easy to do,
>
> Yes, but this is merely different compiler *flags*, to the same (cross)
> compiler binary. ARM32 and ARM64 are different architectures to GCC, so
> require different compiler binaries with different prefixes.
> Last time I checked this wasn't easy to integrate into the U-Boot build
> system.
> One hack could be a "switching script", which filters for, say -m32",
> and calls the respective binary. But still we need to somehow set *two*
> CROSS_COMPILE prefixes. CROSS_COMPILE_SPL, maybe?
> But still it would require to install *two* cross compilers, and would
> spoil a completely native build by still requiring a cross compiler.

That seems like a good idea to me.

>
>>> 3) Try to use ILP32 for the AArch64 SPL build. This reduces the pointer
>>> size and sizeof(long) to be 32-bit and should help, though I haven't
>>> been able to successfully compile it yet (relocation types problems).
>>> Despite lacking mainline support for AArch64 ILP32 in Linux and
>>> glibc(?), GCC supports it for quite a while already. Unknown saving effect.
>>> 4) Use runtime decompression. Most SoCs have larger or more SRAM than
>>> the 32KB, so we could leverage this. Siarhei knows more about this.
>>> 5) Use a TPL. Haven't looked at this in detail yet.
>>>
>>> So 1) would be the easiest to pursue, but 2.5KB are not enough to offset
>>> the >10 KB toll the DM_SPL support actually takes.
>>
>> Is this the cost on 64-bit?
>
> Yes, this is AArch64, just enabling DM_SPL_MMC and DM_SPL.

OK I see, and presumably OF_CONTROL as well?

>
>> I wonder if CONFIG_OF_PLATDATA might be an option?
>
> Well, this would be a requirement, I guess, since adding any kind of DT
> to the mix makes it even worse.

Well it still uses DT as the source for the config. It's just that it
compiles it to C so we don't have to build in libfdt. It does have
some painful side effects though - e.g. you need to adjust drivers to
read the new C structure.

>
> Cheers,
> Andre
>

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

Re: [U-Boot] [PATCH v2 3/3] dm: led: add testcase for "default-state" property

[Simon Glass]

On 3 April 2018 at 15:31,   wrote:
> From: Patrick Bruenn 
>
> Add two more gpio-leds to sandbox test device tree with default-state
> property set to "on"/"off".
> Add dm_test_led_default_state() to check that these new LED's are set to
> LEDST_ON and LEDST_OFF.
>
> Signed-off-by: Patrick Bruenn 
> ---
> patman complains about: test/dm/led.c:45: check: Please use a blank line
> after function/struct/union/enum declarations.
> I compared with other DM_TEST() usage and decided to ignore this check.
> Should we fix the macro, patman or keep ignoring this?
>
> Changes in v2: None
>
>  arch/sandbox/dts/test.dts | 12 
>  test/dm/led.c | 16 
>  2 files changed, 28 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 v2 2/3] dm: led: auto probe() LEDs with "default-state"

[Simon Glass]

On 3 April 2018 at 15:31,   wrote:
> From: Patrick Bruenn 
>
> To avoid board specificy LED activation code, automatically
> activate gpio-leds with "default-state" property during bind().
>
> Signed-off-by: Patrick Bruenn 
> ---
>
> Changes in v2: None
>
>  drivers/led/led_gpio.c | 9 +
>  1 file changed, 9 insertions(+)

Reviewed-by: Simon Glass 

But please see below.

>
> diff --git a/drivers/led/led_gpio.c b/drivers/led/led_gpio.c
> index e68d8d3864..d2fe3d5ad5 100644
> --- a/drivers/led/led_gpio.c
> +++ b/drivers/led/led_gpio.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> @@ -120,6 +121,14 @@ static int led_gpio_bind(struct udevice *parent)
> return ret;
> uc_plat = dev_get_uclass_platdata(dev);
> uc_plat->label = label;
> +
> +   if (ofnode_read_string(node, "default-state")) {

Here I think you mean ofnode_read_boot() ?

> +   struct udevice *devp;
> +
> +   ret = uclass_get_device_tail(dev, 0, );
> +   if (ret)
> +   return ret;
> +   }
> }
>
> return 0;
> --
> 2.11.0
>
>

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

Re: [U-Boot] [PATCH v2 1/3] dm: led: Support "default-state" property

[Simon Glass]

On 3 April 2018 at 15:31,   wrote:
> From: Patrick Bruenn 
>
> Add support for the device tree property "default-state". This feature
> might be useful for LEDs indicating "power on" or similar states.
>
> Note: Even with this commit gpio-leds remain in reset state. That's
> because the led_gpio is not probed until DM_FLAG_ACTIVATED is set.
>
> Signed-off-by: Patrick Bruenn 
>
> ---
>
> Changes in v2:
> - rebase to v2018.05-rc1
> - add dm_test_led_default_state() to tests/dm/led.c
>
>  drivers/led/led_gpio.c | 16 +++-
>  1 file changed, 15 insertions(+), 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] reset: socfpga: add reset driver for SoCFPGA platform

[Marek Vasut]

On 04/03/2018 04:43 PM, Dinh Nguyen wrote:
> 
> 
> On 04/03/2018 09:07 AM, Marek Vasut wrote:
> 
> [...]
>>
>>>
>>> I have a patchset that tested this code, the i2c support in SoCFPGA was
>>> converted to DM, and uses this reset framework. Should I send that along
>>> with this patch in v2?
>>
>> Yes please, otherwise this will be just another dead code.
>>
> 
> Ok will do! A question: ideally I'd like to have the Stratix10 SPL use
> the reset manager framework,

Awesome

> so I'd not have to add a another platform
> specific reset_manager_s10. Would that be possible? I think it is, but
> wanted to confirm.

I think so, the reset handling on socfpga looks trivial.

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

[U-Boot] FIT Image with same kernel but different load/entry point

[Clément Péron]

Hi,

Is it possible to have one kernel entry in a FIT image with two
different load/entry point.

I have 2 boards which share the same kernel but doesn't have the same
entry/load point.

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

Re: [U-Boot] [PATCH v4 00/19] sunxi: sync H3, H5, A64 DTs from mainline Linux

[Jagan Teki]

Hi Andre,

On Wed, Mar 14, 2018 at 7:26 AM, Andre Przywara  wrote:
> A minor update to the v3 version sent earlier this month.
> I reworked patch 09 to drop the direct MMC environment for 32-bit Allwinner
> boards as well and keep the current MMC offset.
> For now I also dropped the two patches changing (back) the MMC regulator.
> I still believe they are good to have and keep them as U-Boot specific
> .dtsi files in my tree, possibly posting them later again.
>
> As the previous version, this combines the EMAC DT support update with
> an update of the full Linux kernel DTs for all H3, H5 and A64 boards.
>
> Patch 01 leaves some hint in the README how to avoid the situation
> when overrunning U-Boot's image size on 64-bit boards.
> The old v2 EMAC DT update series is in patches 02-08, it prepares U-Boot's
> EMAC driver for using the new DT binding used in Linux, also updates
> the DTs to the new EMAC DT node already.
>
> Changes to sync the whole of U-Boot's DT files for the H3, H5 and A64 SoCs
> to those from Linux are in the following patches. However this first requires
> lifting the space limit we currently have due to the raw MMC environment.
> Patch 09 disables that for all sunxi boards, to give us finally some
> space. Patches 10 and 11 consequently revert the disabling of features we
> saw a few weeks ago to migitate the size problem.
>
> Patches 12-19 then bring in the Linux DTs, split by SoCs, with the .dtsi
> files first, then the board files.
>
> Merging the H3 and H5 device tree files brings in significant changes,
> also to the structure of the .dtsi files. However U-Boot's own DT usage
> is pretty limited, so it doesn't matter.
>
> The huge benefit of syncing the DTs is that we can use U-Boot's DT copy
> to directly pass it to the kernel, avoiding to actually load a .dtb file
> from somewhere. To allows seamless and automatic UEFI booting, so
> distribution installer images should just work (TM).
>
> As a goodie the final patch brings in the actual SoPine + baseboard DT
> files, which we were completely missing so far.
>
> This is based on sunxi/master (2d53018a0ef2).
>
> Cheers,
> Andre.
>
> Changelog v3 .. v4:
> - remove MMC environment for all Allwinner boards (including 32 bit ones)
> - keep MMC environment offset to the old values
> - drop DT adjustments to use fixed MMC regulator
>
> Changelog v2 .. v3:
> 01: added, was on the list before
> 02: drop redundant H5 line
> 03-08: unchanged
> 09-20: added
>
> Changelog v1 .. v2:
> 01, 02, 03: unchanged
> 04, 05, 06, 07: added
>
> Andre Przywara (19):
>   sunxi: README.sunxi64: Add hint about non-debug of ARM Trusted
> Firmware
>   sunxi: gpio: add missing compatible strings
>   net: sun8i-emac: support new pinctrl DT bindings
>   net: sun8i-emac: add support for new EMAC DT binding
>   arm: dts: sunxi: update A64 to new EMAC binding
>   arm: dts: sunxi: update H3 to new EMAC binding
>   arm: dts: sunxi: update H5 to new EMAC binding
>   net: sun8i-emac: remove support for old binding
>   sunxi: disable direct MMC environment
>   sunxi: revert disabling of features
>   Revert "sunxi: Pine64: temporarily remove extra Pine64 non-plus DT"

Can you rebase and fix few checkpatch issue on these 11 patches?

Jagan.

-- 
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] [PATCH v3 1/2] warp7: defconfig: Fix CAAM on boot with tip-of-tree

[Breno Matheus Lima]

Hi Bryan,

2018-03-31 17:04 GMT-03:00 Bryan O'Donoghue :
> Booting the following image with tip-of-tree we get a CAAM DECO error (and
> subsequent crash due to a kernel bug in 4.1).
>
> http://freescale.github.io/#download -> BoardsWaRPboard community - WaRP -
> Wearable Reference PlatformFSL Community BSP 2.3fsl-image-multimediawayland
>
> Image: fsl-image-multimedia-imx7s-warp-20180323-90.rootfs.sdcard
>
> Error:
> caam 3090.caam: Entropy delay = 3200
> caam 3090.caam: failed to acquire DECO 0
> 
> caam 3090.caam: failed to acquire DECO 0
> caam 3090.caam: Entropy delay = 12400
> caam 3090.caam: failed to acquire DECO 0
> caam 3090.caam: failed to instantiate RNG
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at
> /home/jenkins/workspace/fsl-community-bsp-pyro_xwayland_2/build/tmp/work-shared/imx7s-warp/kernel-source/mm/vmalloc.c:1465
> caam_remove+0x6)
> Trying to vfree() nonexistent vm area (88047000)
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 4.1.36-4.1-1.0.x-imx-warp7+ga543d1b #1
> Hardware name: Freescale i.MX7 Dual (Device Tree)
> [<80015d54>] (unwind_backtrace) from [<80012688>] (show_stack+0x10/0x14)
> [<80012688>] (show_stack) from [<8076e810>] (dump_stack+0x78/0x8c)
> [<8076e810>] (dump_stack) from [<800346a0>]
> (warn_slowpath_common+0x80/0xb0)
> [<800346a0>] (warn_slowpath_common) from [<80034700>]
> (warn_slowpath_fmt+0x30/0x40)
> [<80034700>] (warn_slowpath_fmt) from [<8054c278>] (caam_remove+0x6c/0x3f4)
> [<8054c278>] (caam_remove) from [<8054ce74>] (caam_probe+0x874/0xfa8)
> [<8054ce74>] (caam_probe) from [<80382a7c>] (platform_drv_probe+0x48/0xa4)
> [<80382a7c>] (platform_drv_probe) from [<80381328>]
> (driver_probe_device+0x174/0x2a8)
> [<80381328>] (driver_probe_device) from [<8038152c>]
> (__driver_attach+0x8c/0x90)
> [<8038152c>] (__driver_attach) from [<8037f9d4>]
> (bus_for_each_dev+0x68/0x9c)
> [<8037f9d4>] (bus_for_each_dev) from [<80380a68>]
> (bus_add_driver+0xf4/0x1e8)
> [<80380a68>] (bus_add_driver) from [<80381b38>] (driver_register+0x78/0xf4)
> [<80381b38>] (driver_register) from [<80009738>]
> (do_one_initcall+0x8c/0x1d0)
> [<80009738>] (do_one_initcall) from [<80a66dac>]
> (kernel_init_freeable+0x140/0x1d0)
> [<80a66dac>] (kernel_init_freeable) from [<8076aa38>]
> (kernel_init+0x8/0xe8)
> [<8076aa38>] (kernel_init) from [<8000f468>] (ret_from_fork+0x14/0x2c)
> ---[ end trace d5f941204ed8cb28 ]---
> caam: probe of 3090.caam failed with error -11
> Unable to handle kernel NULL pointer dereference at virtual address
> 0004
> pgd = 80004000
> [0004] *pgd=
> Internal error: Oops: 805 [#1] PREEMPT SMP ARM
> 
> [<8055cdf8>] (caam_sm_startup) from [<80aa83c8>] (caam_sm_init+0x50/0x58)
> [<80aa83c8>] (caam_sm_init) from [<80009738>] (do_one_initcall+0x8c/0x1d0)
> [<80009738>] (do_one_initcall) from [<80a66dac>]
> (kernel_init_freeable+0x140/0x1d0)
> [<80a66dac>] (kernel_init_freeable) from [<8076aa38>]
> (kernel_init+0x8/0xe8)
> [<8076aa38>] (kernel_init) from [<8000f468>] (ret_from_fork+0x14/0x2c)
> Code: e59d300c e2832010 e5843008 e5834068 (e58a2004)
> ---[ end trace d5f941204ed8cb29 ]---
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
>
> Fix: Enable the CAAM correctly by setting CONFIG_ARMV7_BOOT_SEC_DEFAULT=y
> in the upstream defconfig.
>
> Signed-off-by: Bryan O'Donoghue 
> Cc: Fabio Estevam 
> Cc: Breno Lima 
> Reviewed-by: Fabio Estevam 

Tested-by: Breno Lima 

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

Re: [U-Boot] [PATCH] reset: socfpga: add reset driver for SoCFPGA platform

[Dinh Nguyen]

On 04/03/2018 09:07 AM, Marek Vasut wrote:

[...]
>
>>
>> I have a patchset that tested this code, the i2c support in SoCFPGA was
>> converted to DM, and uses this reset framework. Should I send that along
>> with this patch in v2?
> 
> Yes please, otherwise this will be just another dead code.
> 

Ok will do! A question: ideally I'd like to have the Stratix10 SPL use
the reset manager framework, so I'd not have to add a another platform
specific reset_manager_s10. Would that be possible? I think it is, but
wanted to confirm.

Thanks,

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

Re: [U-Boot] [linux-sunxi] Re: [PATCH v2 5/6] sunxi: add code for recalculating the DRAM size in U-Boot

[Siarhei Siamashka]

On Tue, 3 Apr 2018 13:43:43 +0100
Andre Przywara  wrote:

> Hi Icenowy,
> 
> On 03/04/18 12:51, Icenowy Zheng wrote:
> > 
> > 
> > 于 2018年4月3日 GMT+08:00 下午7:34:55, Maxime Ripard  
> > 写到:  
> >> On Tue, Apr 03, 2018 at 11:13:17AM +0100, Andre Przywara wrote:  
> >>> For hacking it, see my implementation in v1, which assumes the
> >>> only size supported bigger than 2GiB is 3GiB (which is
> >>> acceptable on sunxi, but might not work on other platforms).
> >>>
> >>> As Andre said, that function has another big problem -- it  
> >> detects  
> >>> memory with writing to it. This is risky.  
> >>
> >> How is it risky when it's done by the SPL?  
> >
> > Originally that was my confusion as well: It's not the SPL calling  
> >> that  
> > function. The DRAM controller init function in there knows very
> > precisely how much DRAM we have, but we don't communicate this to  
> >> U-Boot  
> > proper. So U-Boot *proper* goes ahead and probes the DRAM. This  
> >> means it  
> > could step into secure memory, for instance. On sunxi64 we have  
> >> the ATF  
> > running between SPL and U-Boot, also all kind of secure payloads  
> >> could  
> > already have been registered.
> > So I wonder if it would be easier to somehow pass on this *one*  
> >> word of  
> > information between SPL and U-Boot proper to avoid calling this  
> >> function  
> > altogether?  
> 
>  That would definitely make sense yes.  
> >>>
> >>> So since the SPL loads the DT anyway (from the FIT image) and puts it  
> >> at  
> >>> the end of the U-Boot (proper) binary, wouldn't it be the easiest to
> >>> just patch the actual DRAM size in there?
> >>> IIRC we don't have any FDT write code in the SPL at the moment, and
> >>> pulling it in would probably push it over the edge again, but:  
> >>
> >> That assumes that you are loading a FIT image, which might or might
> >> not be the case, and on most arm32 chips, most likely won't.
> >>
> >> I guess we'd need to find another way (put some information in an
> >> SRAM somewhere?) to try to do that for all variants.  
> > 
> > Extend the SPL header again? If we found SPL v3+, use
> > the DRAM size encoded and bypass ram_get_size,
> > otherwise fallback to ram_get_size?  
> 
> Yes, that would be a possibility as well. Though I believe at the moment
> we don't access the SPL header from U-Boot proper, do we?

We do. The boot device and also the boot.scr location (in the case of
FEL boot) is read from the SPL header by the main U-Boot part.

> Not a real show-stopper, but we probably need to document that the SPL
> header would need to stay around.

Maybe.

> But if we have a fallback anyway ...

Which fallback? Do you mean calling things like ram_get_size()
from U-Boot? We should never do this because this is very wrong.

The D-Cache may be already enabled, causing all kinds of weird
effects. Also modifying data in DRAM (even temporarily) while
our code is already running from DRAM is dangerous.

> > (Although it will lead to some days of mess on sunxi-tools,
> > this is a reasonable choice.)  
> 
> True, but actually I wonder why we have SPL_MAX_VERSION in there in the
> first place. Can't we just postulate that every new SPL version stays
> backwards compatible? So if sunxi-tools can deal with v2, a v3 SPL would
> still be fine, you would just loose the v3 features (if at all)?
> We can just put a warning in there, to ask users to upgrade.
> That would have worked already with the v1/v2 transition, I believe.

Yes, that's more or less how this was supposed to work in sunxi-tools
from the very beginning. Except that we unfortunately got a bug in
this code, which has been reported back in July 2017 and is still not
resolved due to various reasons:

   https://github.com/linux-sunxi/sunxi-tools/issues/104

But hopefully it can be fixed sooner or later.

> Probably worth a separate discussion with some sunxi-tools stakeholders.

On the U-Boot side we can just increase the version number as long as
the new header is a backwards compatible superset of the old one.

In the unlikely case if we suddenly have to introduce a compatibility
breaking change to the SPL header format, we can always change the SPL
header signature from 'SPL' to something else.

-- 
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] reset: socfpga: add reset driver for SoCFPGA platform

[Marek Vasut]

On 04/03/2018 04:04 PM, Dinh Nguyen wrote:
> 
> 
> On 03/30/2018 02:45 PM, Marek Vasut wrote:
>> On 03/30/2018 06:53 PM, Dinh Nguyen wrote:
>>> Add a DM compatible reset driver for the SoCFPGA platform.
>>>
>>> Signed-off-by: Dinh Nguyen 
>>> ---
>>>  drivers/reset/Kconfig |   7 +++
>>>  drivers/reset/Makefile|   1 +
>>>  drivers/reset/reset-socfpga.c | 111 
>>> ++
>>>  3 files changed, 119 insertions(+)
>>>  create mode 100644 drivers/reset/reset-socfpga.c
>>>
>>> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
>>> index 3964b9e..90b021f 100644
>>> --- a/drivers/reset/Kconfig
>>> +++ b/drivers/reset/Kconfig
>>> @@ -83,4 +83,11 @@ config RESET_ROCKCHIP
>>>   though is that some reset signals, like I2C or MISC reset multiple
>>>   devices.
>>>  
>>> +config RESET_SOCFPGA
>>> +   bool "Reset controller driver for SoCFPGA"
>>> +   depends on DM_RESET && ARCH_SOCFPGA
>>> +   default y
>>> +   help
>>> + Support for reset controller on SoCFPGA platform.
>>> +
>>>  endmenu
>>> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
>>> index 7d7e080..6f791ee 100644
>>> --- a/drivers/reset/Makefile
>>> +++ b/drivers/reset/Makefile
>>> @@ -13,3 +13,4 @@ obj-$(CONFIG_RESET_BCM6345) += reset-bcm6345.o
>>>  obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
>>>  obj-$(CONFIG_AST2500_RESET) += ast2500-reset.o
>>>  obj-$(CONFIG_RESET_ROCKCHIP) += reset-rockchip.o
>>> +obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
>>> diff --git a/drivers/reset/reset-socfpga.c b/drivers/reset/reset-socfpga.c
>>> new file mode 100644
>>> index 000..af585ec
>>> --- /dev/null
>>> +++ b/drivers/reset/reset-socfpga.c
>>> @@ -0,0 +1,111 @@
>>> +/*
>>> + * Socfpga Reset Controller Driver
>>> + *
>>> + * Copyright 2014 Steffen Trumtrar 
>>> + *
>>> + * based on
>>> + * Allwinner SoCs Reset Controller driver
>>> + *
>>> + * Copyright 2013 Maxime Ripard
>>> + *
>>> + * Maxime Ripard 
>>> + *
>>> + * SPDX-License-Identifier: GPL-2.0+
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define BANK_INCREMENT 4
>>> +#define NR_BANKS   8
>>> +
>>> +struct socfpga_reset_data {
>>> +   void __iomem *membase;
>>> +};
>>> +
>>> +static int socfpga_reset_assert(struct reset_ctl *reset_ctl)
>>> +{
>>> +   struct socfpga_reset_data *data = dev_get_priv(reset_ctl->dev);
>>> +   int id = reset_ctl->id;
>>> +   int reg_width = sizeof(u32);
>>> +   int bank = id / (reg_width * BITS_PER_BYTE);
>>> +   int offset = id % (reg_width * BITS_PER_BYTE);
>>> +   unsigned long flags;
>>> +   u32 reg;
>>> +
>>> +   reg = readl(data->membase + (bank * BANK_INCREMENT));
>>> +   writel(reg | BIT(offset), data->membase + (bank * BANK_INCREMENT));
>>
>> setbits_le32() ?
>>
> 
> Ok..
> 
>>> +   return 0;
>>> +}
>>> +
>>> +static int socfpga_reset_deassert(struct reset_ctl *reset_ctl)
>>> +{
>>> +   struct socfpga_reset_data *data = dev_get_priv(reset_ctl->dev);
>>> +   int id = reset_ctl->id;
>>> +   int reg_width = sizeof(u32);
>>> +   int bank = id / (reg_width * BITS_PER_BYTE);
>>> +   int offset = id % (reg_width * BITS_PER_BYTE);
>>> +   unsigned long flags;
>>> +   u32 reg;
>>> +
>>> +   reg = readl(data->membase + (bank * BANK_INCREMENT));
>>> +   writel(reg & ~BIT(offset), data->membase + (bank * BANK_INCREMENT));
>>
>> clrbits_le32() ?
>>
> 
> Ok..
> 
>> [...]
>>
>> What I do not see is any user of this code, nor any conversion of
>> existing systems to use this code. Is that expected to happen ? I do not
>> want to see dead code piling up in U-Boot.
>>
> 
> I have a patchset that tested this code, the i2c support in SoCFPGA was
> converted to DM, and uses this reset framework. Should I send that along
> with this patch in v2?

Yes please, otherwise this will be just another dead code.

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

Re: [U-Boot] [PATCH] reset: socfpga: add reset driver for SoCFPGA platform

[Dinh Nguyen]

On 03/30/2018 02:45 PM, Marek Vasut wrote:
> On 03/30/2018 06:53 PM, Dinh Nguyen wrote:
>> Add a DM compatible reset driver for the SoCFPGA platform.
>>
>> Signed-off-by: Dinh Nguyen 
>> ---
>>  drivers/reset/Kconfig |   7 +++
>>  drivers/reset/Makefile|   1 +
>>  drivers/reset/reset-socfpga.c | 111 
>> ++
>>  3 files changed, 119 insertions(+)
>>  create mode 100644 drivers/reset/reset-socfpga.c
>>
>> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
>> index 3964b9e..90b021f 100644
>> --- a/drivers/reset/Kconfig
>> +++ b/drivers/reset/Kconfig
>> @@ -83,4 +83,11 @@ config RESET_ROCKCHIP
>>though is that some reset signals, like I2C or MISC reset multiple
>>devices.
>>  
>> +config RESET_SOCFPGA
>> +bool "Reset controller driver for SoCFPGA"
>> +depends on DM_RESET && ARCH_SOCFPGA
>> +default y
>> +help
>> +  Support for reset controller on SoCFPGA platform.
>> +
>>  endmenu
>> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
>> index 7d7e080..6f791ee 100644
>> --- a/drivers/reset/Makefile
>> +++ b/drivers/reset/Makefile
>> @@ -13,3 +13,4 @@ obj-$(CONFIG_RESET_BCM6345) += reset-bcm6345.o
>>  obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
>>  obj-$(CONFIG_AST2500_RESET) += ast2500-reset.o
>>  obj-$(CONFIG_RESET_ROCKCHIP) += reset-rockchip.o
>> +obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
>> diff --git a/drivers/reset/reset-socfpga.c b/drivers/reset/reset-socfpga.c
>> new file mode 100644
>> index 000..af585ec
>> --- /dev/null
>> +++ b/drivers/reset/reset-socfpga.c
>> @@ -0,0 +1,111 @@
>> +/*
>> + * Socfpga Reset Controller Driver
>> + *
>> + * Copyright 2014 Steffen Trumtrar 
>> + *
>> + * based on
>> + * Allwinner SoCs Reset Controller driver
>> + *
>> + * Copyright 2013 Maxime Ripard
>> + *
>> + * Maxime Ripard 
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define BANK_INCREMENT  4
>> +#define NR_BANKS8
>> +
>> +struct socfpga_reset_data {
>> +void __iomem *membase;
>> +};
>> +
>> +static int socfpga_reset_assert(struct reset_ctl *reset_ctl)
>> +{
>> +struct socfpga_reset_data *data = dev_get_priv(reset_ctl->dev);
>> +int id = reset_ctl->id;
>> +int reg_width = sizeof(u32);
>> +int bank = id / (reg_width * BITS_PER_BYTE);
>> +int offset = id % (reg_width * BITS_PER_BYTE);
>> +unsigned long flags;
>> +u32 reg;
>> +
>> +reg = readl(data->membase + (bank * BANK_INCREMENT));
>> +writel(reg | BIT(offset), data->membase + (bank * BANK_INCREMENT));
> 
> setbits_le32() ?
> 

Ok..

>> +return 0;
>> +}
>> +
>> +static int socfpga_reset_deassert(struct reset_ctl *reset_ctl)
>> +{
>> +struct socfpga_reset_data *data = dev_get_priv(reset_ctl->dev);
>> +int id = reset_ctl->id;
>> +int reg_width = sizeof(u32);
>> +int bank = id / (reg_width * BITS_PER_BYTE);
>> +int offset = id % (reg_width * BITS_PER_BYTE);
>> +unsigned long flags;
>> +u32 reg;
>> +
>> +reg = readl(data->membase + (bank * BANK_INCREMENT));
>> +writel(reg & ~BIT(offset), data->membase + (bank * BANK_INCREMENT));
> 
> clrbits_le32() ?
> 

Ok..

> [...]
> 
> What I do not see is any user of this code, nor any conversion of
> existing systems to use this code. Is that expected to happen ? I do not
> want to see dead code piling up in U-Boot.
> 

I have a patchset that tested this code, the i2c support in SoCFPGA was
converted to DM, and uses this reset framework. Should I send that along
with this patch in v2?

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

Re: [U-Boot] [PATCH v2 5/6] sunxi: add code for recalculating the DRAM size in U-Boot

[Andre Przywara]

Hi Icenowy,

On 03/04/18 12:51, Icenowy Zheng wrote:
> 
> 
> 于 2018年4月3日 GMT+08:00 下午7:34:55, Maxime Ripard  写到:
>> On Tue, Apr 03, 2018 at 11:13:17AM +0100, Andre Przywara wrote:
>>> For hacking it, see my implementation in v1, which assumes the
>>> only size supported bigger than 2GiB is 3GiB (which is
>>> acceptable on sunxi, but might not work on other platforms).
>>>
>>> As Andre said, that function has another big problem -- it
>> detects
>>> memory with writing to it. This is risky.
>>
>> How is it risky when it's done by the SPL?
>
> Originally that was my confusion as well: It's not the SPL calling
>> that
> function. The DRAM controller init function in there knows very
> precisely how much DRAM we have, but we don't communicate this to
>> U-Boot
> proper. So U-Boot *proper* goes ahead and probes the DRAM. This
>> means it
> could step into secure memory, for instance. On sunxi64 we have
>> the ATF
> running between SPL and U-Boot, also all kind of secure payloads
>> could
> already have been registered.
> So I wonder if it would be easier to somehow pass on this *one*
>> word of
> information between SPL and U-Boot proper to avoid calling this
>> function
> altogether?

 That would definitely make sense yes.
>>>
>>> So since the SPL loads the DT anyway (from the FIT image) and puts it
>> at
>>> the end of the U-Boot (proper) binary, wouldn't it be the easiest to
>>> just patch the actual DRAM size in there?
>>> IIRC we don't have any FDT write code in the SPL at the moment, and
>>> pulling it in would probably push it over the edge again, but:
>>
>> That assumes that you are loading a FIT image, which might or might
>> not be the case, and on most arm32 chips, most likely won't.
>>
>> I guess we'd need to find another way (put some information in an
>> SRAM somewhere?) to try to do that for all variants.
> 
> Extend the SPL header again? If we found SPL v3+, use
> the DRAM size encoded and bypass ram_get_size,
> otherwise fallback to ram_get_size?

Yes, that would be a possibility as well. Though I believe at the moment
we don't access the SPL header from U-Boot proper, do we? Not a real
show-stopper, but we probably need to document that the SPL header would
need to stay around.
But if we have a fallback anyway ...

> (Although it will lead to some days of mess on sunxi-tools,
> this is a reasonable choice.)

True, but actually I wonder why we have SPL_MAX_VERSION in there in the
first place. Can't we just postulate that every new SPL version stays
backwards compatible? So if sunxi-tools can deal with v2, a v3 SPL would
still be fine, you would just loose the v3 features (if at all)? We can
just put a warning in there, to ask users to upgrade.
That would have worked already with the v1/v2 transition, I believe.

Probably worth a separate discussion with some sunxi-tools stakeholders.

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

Re: [U-Boot] [PATCH v2] timer: add High Precision Event Timers (HPET) support

[Andy Shevchenko]

On Tue, Apr 3, 2018 at 2:00 AM, Ivan Gorinov  wrote:
> On Sat, Mar 31, 2018 at 06:31:03AM -0600, Andy Shevchenko wrote:
>> >> > +   tl = readl(regs + HPET_MAIN_COUNT_L);
>> >> > +   th = readl(regs + HPET_MAIN_COUNT_H);
>> >>
>> >> Ditto.
>> >
>> > If readq() is defined as two read operations in 32-bit code, main counter
>> > rollover (low part overflow, high part increment) can happen between them.
>>
>> And how this contradicts ther current code?
>
> It just does not make the code simpler,

...b/c you misread what I suggested.

> rollover check is
> still required if U-Boot is compiled as 32-bit code.
>
> Can we do something like the following?

Yes, but... why?

What's wrong with replacing two sequential 32-bit reads with one 64-bit?

See below.

> #ifdef CONFIG_X86_64
>
> static u64 read_main_counter(void *regs)
> {
> return readq(regs + HPET_MAIN_COUNT);
> }
>
> #else
>
> /*
>  * Read the main counter as two 32-bit registers,
>  * repeat if rollover happens.
>  */
> static u64 read_main_counter(void *regs)
> {
> u64 now_tick;
> u32 tl, th, th0;
>
> th = readl(regs + HPET_MAIN_COUNT_H);
> do {

now_tick = readq();

> th0 = th;
> tl = readl(regs + HPET_MAIN_COUNT_L);
> th = readl(regs + HPET_MAIN_COUNT_H);
> now_tick = th;
> now_tick <<= 32;
> now_tick |= tl;

> } while (th != th0);

} while (th != (now_tick >> 32));

>
> return now_tick;
> }
>
> #endif


-- 
With Best Regards,
Andy Shevchenko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/6] sunxi: add code for recalculating the DRAM size in U-Boot

[Icenowy Zheng]

于 2018年4月3日 GMT+08:00 下午7:34:55, Maxime Ripard  写到:
>On Tue, Apr 03, 2018 at 11:13:17AM +0100, Andre Przywara wrote:
>>  For hacking it, see my implementation in v1, which assumes the
>>  only size supported bigger than 2GiB is 3GiB (which is
>>  acceptable on sunxi, but might not work on other platforms).
>> 
>>  As Andre said, that function has another big problem -- it
>detects
>>  memory with writing to it. This is risky.
>> >>>
>> >>> How is it risky when it's done by the SPL?
>> >>
>> >> Originally that was my confusion as well: It's not the SPL calling
>that
>> >> function. The DRAM controller init function in there knows very
>> >> precisely how much DRAM we have, but we don't communicate this to
>U-Boot
>> >> proper. So U-Boot *proper* goes ahead and probes the DRAM. This
>means it
>> >> could step into secure memory, for instance. On sunxi64 we have
>the ATF
>> >> running between SPL and U-Boot, also all kind of secure payloads
>could
>> >> already have been registered.
>> >> So I wonder if it would be easier to somehow pass on this *one*
>word of
>> >> information between SPL and U-Boot proper to avoid calling this
>function
>> >> altogether?
>> > 
>> > That would definitely make sense yes.
>> 
>> So since the SPL loads the DT anyway (from the FIT image) and puts it
>at
>> the end of the U-Boot (proper) binary, wouldn't it be the easiest to
>> just patch the actual DRAM size in there?
>> IIRC we don't have any FDT write code in the SPL at the moment, and
>> pulling it in would probably push it over the edge again, but:
>
>That assumes that you are loading a FIT image, which might or might
>not be the case, and on most arm32 chips, most likely won't.
>
>I guess we'd need to find another way (put some information in an
>SRAM somewhere?) to try to do that for all variants.

Extend the SPL header again? If we found SPL v3+, use
the DRAM size encoded and bypass ram_get_size,
otherwise fallback to ram_get_size?

(Although it will lead to some days of mess on sunxi-tools,
this is a reasonable choice.)

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

Re: [U-Boot] [PATCH v2 5/6] sunxi: add code for recalculating the DRAM size in U-Boot

[Icenowy Zheng]

于 2018年4月3日 GMT+08:00 下午7:41:41, Andre Przywara  写到:
>Hi,
>
>On 03/04/18 12:34, Maxime Ripard wrote:
>> On Tue, Apr 03, 2018 at 11:13:17AM +0100, Andre Przywara wrote:
>>> For hacking it, see my implementation in v1, which assumes the
>>> only size supported bigger than 2GiB is 3GiB (which is
>>> acceptable on sunxi, but might not work on other platforms).
>>>
>>> As Andre said, that function has another big problem -- it
>detects
>>> memory with writing to it. This is risky.
>>
>> How is it risky when it's done by the SPL?
>
> Originally that was my confusion as well: It's not the SPL calling
>that
> function. The DRAM controller init function in there knows very
> precisely how much DRAM we have, but we don't communicate this to
>U-Boot
> proper. So U-Boot *proper* goes ahead and probes the DRAM. This
>means it
> could step into secure memory, for instance. On sunxi64 we have
>the ATF
> running between SPL and U-Boot, also all kind of secure payloads
>could
> already have been registered.
> So I wonder if it would be easier to somehow pass on this *one*
>word of
> information between SPL and U-Boot proper to avoid calling this
>function
> altogether?

 That would definitely make sense yes.
>>>
>>> So since the SPL loads the DT anyway (from the FIT image) and puts
>it at
>>> the end of the U-Boot (proper) binary, wouldn't it be the easiest to
>>> just patch the actual DRAM size in there?
>>> IIRC we don't have any FDT write code in the SPL at the moment, and
>>> pulling it in would probably push it over the edge again, but:
>> 
>> That assumes that you are loading a FIT image, which might or might
>> not be the case, and on most arm32 chips, most likely won't.
>
>That's true, but my understanding is that this >4GB is only relevant
>for
>64-bit SoCs, where we mandate FIT images, don't we?

It's also relevant with A80, theortically.

And Allwinner is continously producing Cortex-A7
SoCs, which might use this design.

>
>> I guess we'd need to find another way (put some information in an
>> SRAM somewhere?) to try to do that for all variants.
>
>Oh, so your aim at getting rid of the call to the memory probing
>function at all? I was just assuming that we change it for the purpose
>of this 3GB support, which would be 64-bit only?
>
>Cheers,
>Andre
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 2/3] dm: led: auto probe() LEDs with "default-state"

[linux-kernel-dev]

From: Patrick Bruenn 

To avoid board specificy LED activation code, automatically
activate gpio-leds with "default-state" property during bind().

Signed-off-by: Patrick Bruenn 
---

Changes in v2: None

 drivers/led/led_gpio.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/led/led_gpio.c b/drivers/led/led_gpio.c
index e68d8d3864..d2fe3d5ad5 100644
--- a/drivers/led/led_gpio.c
+++ b/drivers/led/led_gpio.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -120,6 +121,14 @@ static int led_gpio_bind(struct udevice *parent)
return ret;
uc_plat = dev_get_uclass_platdata(dev);
uc_plat->label = label;
+
+   if (ofnode_read_string(node, "default-state")) {
+   struct udevice *devp;
+
+   ret = uclass_get_device_tail(dev, 0, );
+   if (ret)
+   return ret;
+   }
}
 
return 0;
-- 
2.11.0


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

[U-Boot] [PATCH v2 3/3] dm: led: add testcase for "default-state" property

[linux-kernel-dev]

From: Patrick Bruenn 

Add two more gpio-leds to sandbox test device tree with default-state
property set to "on"/"off".
Add dm_test_led_default_state() to check that these new LED's are set to
LEDST_ON and LEDST_OFF.

Signed-off-by: Patrick Bruenn 
---
patman complains about: test/dm/led.c:45: check: Please use a blank line
after function/struct/union/enum declarations.
I compared with other DM_TEST() usage and decided to ignore this check.
Should we fix the macro, patman or keep ignoring this?

Changes in v2: None

 arch/sandbox/dts/test.dts | 12 
 test/dm/led.c | 16 
 2 files changed, 28 insertions(+)

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 06d0e8ce85..07f9bad258 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -254,6 +254,18 @@
gpios = <_a 2 0>;
label = "sandbox:green";
};
+
+   default_on {
+   gpios = <_a 3 0>;
+   label = "sandbox:default_on";
+   default-state = "on";
+   };
+
+   default_off {
+   gpios = <_a 4 0>;
+   label = "sandbox:default_off";
+   default-state = "off";
+   };
};
 
mbox: mbox {
diff --git a/test/dm/led.c b/test/dm/led.c
index fde700be38..c560abc4fb 100644
--- a/test/dm/led.c
+++ b/test/dm/led.c
@@ -28,6 +28,22 @@ static int dm_test_led_base(struct unit_test_state *uts)
 }
 DM_TEST(dm_test_led_base, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
 
+/* Test of the LED 'default-state' device tree property */
+static int dm_test_led_default_state(struct unit_test_state *uts)
+{
+   struct udevice *dev;
+
+   /* Check that we handle the default-state property correctly. */
+   ut_assertok(led_get_by_label("sandbox:default_on", ));
+   ut_asserteq(LEDST_ON, led_get_state(dev));
+
+   ut_assertok(led_get_by_label("sandbox:default_off", ));
+   ut_asserteq(LEDST_OFF, led_get_state(dev));
+
+   return 0;
+}
+DM_TEST(dm_test_led_default_state, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
 /* Test of the led uclass using the led_gpio driver */
 static int dm_test_led_gpio(struct unit_test_state *uts)
 {
-- 
2.11.0


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

[U-Boot] [PATCH v2 1/3] dm: led: Support "default-state" property

[linux-kernel-dev]

From: Patrick Bruenn 

Add support for the device tree property "default-state". This feature
might be useful for LEDs indicating "power on" or similar states.

Note: Even with this commit gpio-leds remain in reset state. That's
because the led_gpio is not probed until DM_FLAG_ACTIVATED is set.

Signed-off-by: Patrick Bruenn 

---

Changes in v2:
- rebase to v2018.05-rc1
- add dm_test_led_default_state() to tests/dm/led.c

 drivers/led/led_gpio.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/led/led_gpio.c b/drivers/led/led_gpio.c
index 9976635887..e68d8d3864 100644
--- a/drivers/led/led_gpio.c
+++ b/drivers/led/led_gpio.c
@@ -60,11 +60,25 @@ static int led_gpio_probe(struct udevice *dev)
 {
struct led_uc_plat *uc_plat = dev_get_uclass_platdata(dev);
struct led_gpio_priv *priv = dev_get_priv(dev);
+   const char *default_state;
+   int ret;
 
/* Ignore the top-level LED node */
if (!uc_plat->label)
return 0;
-   return gpio_request_by_name(dev, "gpios", 0, >gpio, GPIOD_IS_OUT);
+
+   ret = gpio_request_by_name(dev, "gpios", 0, >gpio, GPIOD_IS_OUT);
+   if (ret)
+   return ret;
+
+   default_state = dev_read_string(dev, "default-state");
+   if (default_state) {
+   if (!strncmp(default_state, "on", 2))
+   gpio_led_set_state(dev, LEDST_ON);
+   else if (!strncmp(default_state, "off", 3))
+   gpio_led_set_state(dev, LEDST_OFF);
+   }
+   return 0;
 }
 
 static int led_gpio_remove(struct udevice *dev)
-- 
2.11.0


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

[U-Boot] [PATCH v2 0/3] This series adds support for gpio-leds "default-state" property. The

[linux-kernel-dev]

From: Patrick Bruenn 

main usecase in mind are LEDs which indicate a state like "power on".
With this patchset applied, all you have to do is:
Add a gpio-led node with 'default-state = "on";' property to your device
tree. And the LED will automatically light up during U-Boot startup.

Changes in v2:
- rebase to v2018.05-rc1
- add dm_test_led_default_state() to tests/dm/led.c

Patrick Bruenn (3):
  dm: led: Support "default-state" property
  dm: led: auto probe() LEDs with "default-state"
  dm: led: add testcase for "default-state" property

 arch/sandbox/dts/test.dts | 12 
 drivers/led/led_gpio.c| 25 -
 test/dm/led.c | 16 
 3 files changed, 52 insertions(+), 1 deletion(-)

-- 
2.11.0


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

[U-Boot] [Feature] Android Fastboot over Ethernet

[Stanislas BERTRAND]

Has there been any development to support Android Fastboot Ethernet feature in 
U-Boot ?

https://android.googlesource.com/platform/system/core/+/android-7.1.2_r36/fastboot/fastboot_protocol.txt


The target board has not USB device port available to flash the on-board eMMC.

Flashing the eMMC via U-Boot shell commands would be very much slower and 
limited.


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

Re: [U-Boot] [PATCH v2 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

[Felix Brack]

On 02.04.2018 17:43, Alex Kiernan wrote:
> On Mon, Apr 2, 2018 at 12:13 PM, Felix Brack  wrote:
>> Hi Alex,
>>
>> On 01.04.2018 11:22, Alex Kiernan wrote:
>>> This converts CONFIG_DRIVER_TI_CPSW to Kconfig
>>>
>>> Signed-off-by: Alex Kiernan 
>>> Acked-by: Joe Hershberger 
>>> ---
>>>
>>> Changes in v2:
>>> - Move DRIVER_TI_CPSW outside of the NETDEVICES guard
>>> - Don't mark DRIVER_TI_CPSW default if ARCH_OMAP2PLUS to fix mistranslations
>>>   by moveconfig
>>>
>>
>> [..]
>>
>>> diff --git a/configs/am335x_pdu001_defconfig 
>>> b/configs/am335x_pdu001_defconfig
>>> index cb75ec0..87ae88c 100644
>>> --- a/configs/am335x_pdu001_defconfig
>>> +++ b/configs/am335x_pdu001_defconfig
>>> @@ -9,13 +9,13 @@ CONFIG_SPL_SERIAL_SUPPORT=y
>>>  CONFIG_SPL_LIBDISK_SUPPORT=y
>>>  # CONFIG_SPL_NAND_SUPPORT is not set
>>>  CONFIG_SPL_WATCHDOG_SUPPORT=y
>>> +CONFIG_SPL=y
>>>  CONFIG_SPL_FAT_SUPPORT=y
>>>  CONFIG_DEFAULT_DEVICE_TREE="am335x-pdu001"
>>>  CONFIG_LOCALVERSION="-EETS-1.0.0"
>>>  CONFIG_DISTRO_DEFAULTS=y
>>>  CONFIG_BOOTDELAY=1
>>>  # CONFIG_USE_BOOTCOMMAND is not set
>>> -CONFIG_SPL=y
>>>  # CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is not set
>>>  CONFIG_SPL_I2C_SUPPORT=y
>>>  CONFIG_SPL_YMODEM_SUPPORT=y
>>> @@ -39,6 +39,7 @@ CONFIG_DM_GPIO=y
>>>  CONFIG_DM_I2C=y
>>>  CONFIG_MMC_OMAP_HS=y
>>>  CONFIG_MMC_SDHCI=y
>>> +CONFIG_DRIVER_TI_CPSW=y
>>
>> Applying this patch series generates the following warning while
>> creating the default configuration for board PDU001:
>>
>> warning: (BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS &&
>> BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS && DRIVER_TI_CPSW &&
>> AG7XXX && ALTERA_TSE && BCM_SF2_ETH && DWC_ETH_QOS && ETH_DESIGNWARE &&
>> MVNETA && MVPP2 && MACB && PCH_GBE && SUN4I_EMAC && SUN8I_EMAC &&
>> SH_ETHER && XILINX_AXIEMAC && XILINX_EMACLITE && ZYNQ_GEM && PIC32_ETH
>> && RENESAS_RAVB) selects PHYLIB which has unmet direct dependencies (NET)
>>
>> This is due to the patch enabling CONFIG_DRIVER_TI_CPSW while leaving
>> CONFIG_NET disabled.
>> This board does not require/have network support for U-Boot so there is
>> no need or benefit activating CONFIG_DRIVER_TI_CPSW here. Leaving the
>> file configs/am355x_pdu001_defconfig without any modifications will make
>> your patch work properly and result in a clean, warning and error free,
>> build for the PDU001 board.
>>
>>>  CONFIG_PINCTRL=y
>>>  CONFIG_PINCTRL_SINGLE=y
>>>  CONFIG_DM_PMIC=y
>>
> 
> Oh bother, thanks for trying it. I think in fixing the opposite
> problem from v1 I've missed a depends on NET. Is your board covered by
> the Travis tests as I did push v2 and got a green build?
> 

From what I can see it is not, but I'm not sure. Using buildman with
am335x would include it. I have verified that.

> Unfortunately my laptop decided to die overnight and I'm away from the
> office for a couple of weeks so I'll have to pick it up when I'm back.
> 
> Alex
> 

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

Re: [U-Boot] [PATCH v2 5/6] sunxi: add code for recalculating the DRAM size in U-Boot

[Andre Przywara]

Hi,

On 03/04/18 12:34, Maxime Ripard wrote:
> On Tue, Apr 03, 2018 at 11:13:17AM +0100, Andre Przywara wrote:
>> For hacking it, see my implementation in v1, which assumes the
>> only size supported bigger than 2GiB is 3GiB (which is
>> acceptable on sunxi, but might not work on other platforms).
>>
>> As Andre said, that function has another big problem -- it detects
>> memory with writing to it. This is risky.
>
> How is it risky when it's done by the SPL?

 Originally that was my confusion as well: It's not the SPL calling that
 function. The DRAM controller init function in there knows very
 precisely how much DRAM we have, but we don't communicate this to U-Boot
 proper. So U-Boot *proper* goes ahead and probes the DRAM. This means it
 could step into secure memory, for instance. On sunxi64 we have the ATF
 running between SPL and U-Boot, also all kind of secure payloads could
 already have been registered.
 So I wonder if it would be easier to somehow pass on this *one* word of
 information between SPL and U-Boot proper to avoid calling this function
 altogether?
>>>
>>> That would definitely make sense yes.
>>
>> So since the SPL loads the DT anyway (from the FIT image) and puts it at
>> the end of the U-Boot (proper) binary, wouldn't it be the easiest to
>> just patch the actual DRAM size in there?
>> IIRC we don't have any FDT write code in the SPL at the moment, and
>> pulling it in would probably push it over the edge again, but:
> 
> That assumes that you are loading a FIT image, which might or might
> not be the case, and on most arm32 chips, most likely won't.

That's true, but my understanding is that this >4GB is only relevant for
64-bit SoCs, where we mandate FIT images, don't we?

> I guess we'd need to find another way (put some information in an
> SRAM somewhere?) to try to do that for all variants.

Oh, so your aim at getting rid of the call to the memory probing
function at all? I was just assuming that we change it for the purpose
of this 3GB support, which would be 64-bit only?

Cheers,
Andre


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

Re: [U-Boot] [PATCH v2 5/6] sunxi: add code for recalculating the DRAM size in U-Boot

[Maxime Ripard]

On Tue, Apr 03, 2018 at 11:13:17AM +0100, Andre Przywara wrote:
>  For hacking it, see my implementation in v1, which assumes the
>  only size supported bigger than 2GiB is 3GiB (which is
>  acceptable on sunxi, but might not work on other platforms).
> 
>  As Andre said, that function has another big problem -- it detects
>  memory with writing to it. This is risky.
> >>>
> >>> How is it risky when it's done by the SPL?
> >>
> >> Originally that was my confusion as well: It's not the SPL calling that
> >> function. The DRAM controller init function in there knows very
> >> precisely how much DRAM we have, but we don't communicate this to U-Boot
> >> proper. So U-Boot *proper* goes ahead and probes the DRAM. This means it
> >> could step into secure memory, for instance. On sunxi64 we have the ATF
> >> running between SPL and U-Boot, also all kind of secure payloads could
> >> already have been registered.
> >> So I wonder if it would be easier to somehow pass on this *one* word of
> >> information between SPL and U-Boot proper to avoid calling this function
> >> altogether?
> > 
> > That would definitely make sense yes.
> 
> So since the SPL loads the DT anyway (from the FIT image) and puts it at
> the end of the U-Boot (proper) binary, wouldn't it be the easiest to
> just patch the actual DRAM size in there?
> IIRC we don't have any FDT write code in the SPL at the moment, and
> pulling it in would probably push it over the edge again, but:

That assumes that you are loading a FIT image, which might or might
not be the case, and on most arm32 chips, most likely won't.

I guess we'd need to find another way (put some information in an
SRAM somewhere?) to try to do that for all variants.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [U-Boot] [PATCH v2 5/6] sunxi: add code for recalculating the DRAM size in U-Boot

[Dr. Philipp Tomsich]

> On 3 Apr 2018, at 12:39, Icenowy Zheng  wrote:
> 
> 
> 
> 于 2018年4月3日 GMT+08:00 下午6:13:17, Andre Przywara  > 写到:
>> Hi,
>> 
>> On 03/04/18 10:29, Maxime Ripard wrote:
>>> On Thu, Mar 29, 2018 at 01:21:38PM +0100, Andre Przywara wrote:
 Hi,
 
 On 29/03/18 10:37, Maxime Ripard wrote:
> On Wed, Mar 28, 2018 at 07:31:51PM +0800, Icenowy Zheng wrote:
>> 于 2018年3月28日 GMT+08:00 下午7:28:07, Maxime Ripard
>>  写到:
>>> On Mon, Mar 26, 2018 at 03:11:04PM +0800, Icenowy Zheng wrote:
 
 
 于 2018年3月26日 GMT+08:00 下午3:06:33, Maxime Ripard
>>>  写到:
> On Fri, Mar 23, 2018 at 05:41:43PM +0800, Icenowy Zheng wrote:
>> 
>> 
>> 于 2018年3月23日 GMT+08:00 下午5:40:41, Maxime Ripard
>  写到:
>>> On Fri, Mar 23, 2018 at 04:18:56PM +0800, Icenowy Zheng
>> wrote:
 The get_ram_size() function in U-Boot can only deal with
>> memory
> size
 smaller than 2GiB. To enable the support of 3GiB DRAM on
>> newer
> 64-bit
 SoCs, an alternative way to detect DRAM size is needed.
>>> 
>>> Why not just fixing get_ram_size then?
>> 
>> Even if it's fixed it won't support 3GiB DRAM at all.
> 
> Why?
 
 It has an assumption that the size is pow of 2.
>>> 
>>> I guess this would be fixable too? (or one could create a variant
>>> without that assumption).
>> 
>> I don't think its principle allows such kind of fix, as it just
>> checks writing then reading at some offset that is pow if 2.
> 
> You could do have a bunch of algorithm actually. One would be to
>> write
> the address in memory and try to detect where exactly it starts to
> loop.
> 
> You could do a bisection in the opposite direction once you settled
> for the upper limit (so you would have for example a workable 2G, a
> non-workable 4G, and then you try intervals that you always divide
>> by
> two, so testing then 3G (that works), then halfway between 3G and
>> 4G,
> etc.
> 
>> For hacking it, see my implementation in v1, which assumes the
>> only size supported bigger than 2GiB is 3GiB (which is
>> acceptable on sunxi, but might not work on other platforms).
>> 
>> As Andre said, that function has another big problem -- it detects
>> memory with writing to it. This is risky.
> 
> How is it risky when it's done by the SPL?
 
 Originally that was my confusion as well: It's not the SPL calling
>> that
 function. The DRAM controller init function in there knows very
 precisely how much DRAM we have, but we don't communicate this to
>> U-Boot
 proper. So U-Boot *proper* goes ahead and probes the DRAM. This
>> means it
 could step into secure memory, for instance. On sunxi64 we have the
>> ATF
 running between SPL and U-Boot, also all kind of secure payloads
>> could
 already have been registered.
 So I wonder if it would be easier to somehow pass on this *one* word
>> of
 information between SPL and U-Boot proper to avoid calling this
>> function
 altogether?
>>> 
>>> That would definitely make sense yes.
>> 
>> So since the SPL loads the DT anyway (from the FIT image) and puts it
>> at
>> the end of the U-Boot (proper) binary, wouldn't it be the easiest to
>> just patch the actual DRAM size in there?
>> IIRC we don't have any FDT write code in the SPL at the moment, and
>> pulling it in would probably push it over the edge again, but:
>> We should be able to somewhat short-cut it, if it's just about to
>> actually *patch* an existing value, as of:
>> - make sure we have a memory node and a reg property in the DT
>> - in the SPL learn the fdt offset of that reg property
>> -  patch in the memory size into the second word 
>> - teach U-Boot proper to read the memory size from the DT
>> - optionally look at #address-cells and #size-cells to make this
>> "second
>> word hack" more robust
>> 
>> This could actually be a rather generic patch, just with some "avoid
>> libfdt write library" hack to address our size issue. Maybe we already
>> have something like that for some platform (Rockchip comes to mind?)
> 
> Rockchip recalculates the memory size with the parameters
> in GRF when running the main U-Boot, so both TPL/SPL
> and miniloader can load mainline U-Boot.

More accurately, the GRF currently is used to store an encoded DRAM
configuration and the next stage can rely on this being there.

If the memory is initialised by miniloader, U-Boot reads the GRF and calculates
the memory size from that.  If U-Boot sets up DRAM, then it also populates the
GRF registers.

With more and more SOCs moving away from miniloader, there’s a good chance
that this will change at some point in the future and the 

Re: [U-Boot] [PATCH v2 5/6] sunxi: add code for recalculating the DRAM size in U-Boot

[Icenowy Zheng]

于 2018年4月3日 GMT+08:00 下午6:13:17, Andre Przywara  写到:
>Hi,
>
>On 03/04/18 10:29, Maxime Ripard wrote:
>> On Thu, Mar 29, 2018 at 01:21:38PM +0100, Andre Przywara wrote:
>>> Hi,
>>>
>>> On 29/03/18 10:37, Maxime Ripard wrote:
 On Wed, Mar 28, 2018 at 07:31:51PM +0800, Icenowy Zheng wrote:
> 于 2018年3月28日 GMT+08:00 下午7:28:07, Maxime Ripard
> 写到:
>> On Mon, Mar 26, 2018 at 03:11:04PM +0800, Icenowy Zheng wrote:
>>>
>>>
>>> 于 2018年3月26日 GMT+08:00 下午3:06:33, Maxime Ripard
>>  写到:
 On Fri, Mar 23, 2018 at 05:41:43PM +0800, Icenowy Zheng wrote:
>
>
> 于 2018年3月23日 GMT+08:00 下午5:40:41, Maxime Ripard
  写到:
>> On Fri, Mar 23, 2018 at 04:18:56PM +0800, Icenowy Zheng
>wrote:
>>> The get_ram_size() function in U-Boot can only deal with
>memory
 size
>>> smaller than 2GiB. To enable the support of 3GiB DRAM on
>newer
 64-bit
>>> SoCs, an alternative way to detect DRAM size is needed.
>>
>> Why not just fixing get_ram_size then?
>
> Even if it's fixed it won't support 3GiB DRAM at all.

 Why?
>>>
>>> It has an assumption that the size is pow of 2.
>>
>> I guess this would be fixable too? (or one could create a variant
>> without that assumption).
>
> I don't think its principle allows such kind of fix, as it just
> checks writing then reading at some offset that is pow if 2.

 You could do have a bunch of algorithm actually. One would be to
>write
 the address in memory and try to detect where exactly it starts to
 loop.

 You could do a bisection in the opposite direction once you settled
 for the upper limit (so you would have for example a workable 2G, a
 non-workable 4G, and then you try intervals that you always divide
>by
 two, so testing then 3G (that works), then halfway between 3G and
>4G,
 etc.

> For hacking it, see my implementation in v1, which assumes the
> only size supported bigger than 2GiB is 3GiB (which is
> acceptable on sunxi, but might not work on other platforms).
>
> As Andre said, that function has another big problem -- it detects
> memory with writing to it. This is risky.

 How is it risky when it's done by the SPL?
>>>
>>> Originally that was my confusion as well: It's not the SPL calling
>that
>>> function. The DRAM controller init function in there knows very
>>> precisely how much DRAM we have, but we don't communicate this to
>U-Boot
>>> proper. So U-Boot *proper* goes ahead and probes the DRAM. This
>means it
>>> could step into secure memory, for instance. On sunxi64 we have the
>ATF
>>> running between SPL and U-Boot, also all kind of secure payloads
>could
>>> already have been registered.
>>> So I wonder if it would be easier to somehow pass on this *one* word
>of
>>> information between SPL and U-Boot proper to avoid calling this
>function
>>> altogether?
>> 
>> That would definitely make sense yes.
>
>So since the SPL loads the DT anyway (from the FIT image) and puts it
>at
>the end of the U-Boot (proper) binary, wouldn't it be the easiest to
>just patch the actual DRAM size in there?
>IIRC we don't have any FDT write code in the SPL at the moment, and
>pulling it in would probably push it over the edge again, but:
>We should be able to somewhat short-cut it, if it's just about to
>actually *patch* an existing value, as of:
>- make sure we have a memory node and a reg property in the DT
>- in the SPL learn the fdt offset of that reg property
>-  patch in the memory size into the second word 
>- teach U-Boot proper to read the memory size from the DT
>- optionally look at #address-cells and #size-cells to make this
>"second
>word hack" more robust
>
>This could actually be a rather generic patch, just with some "avoid
>libfdt write library" hack to address our size issue. Maybe we already
>have something like that for some platform (Rockchip comes to mind?)

Rockchip recalculates the memory size with the parameters
in GRF when running the main U-Boot, so both TPL/SPL
and miniloader can load mainline U-Boot.

>
>How does that sound?
>
>Cheers,
>Andre.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 00/20] Bring NAND support to Nintendo NES Classic

[Maxime Ripard]

On Wed, Feb 28, 2018 at 08:51:42PM +0100, Miquel Raynal wrote:
> Hello,
> 
> This series first adds fixes and enhancements to sunxi NAND drivers (SPL
> and U-Boot). Once this is done, the SPL NAND driver is converted to use
> PIO instead of DMA with the goal to support all SoCs with this IP
> without the need for DMA-related code. Finally, NAND support is added to
> Nintendo NES Classic through Kconfig and DT additions.
> 
> Thanks,
> Miquèl

Merged every thing, thanks for your stubborn^W patience on this one :)

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [U-Boot] [PATCH v2 5/6] sunxi: add code for recalculating the DRAM size in U-Boot

[Andre Przywara]

Hi,

On 03/04/18 10:29, Maxime Ripard wrote:
> On Thu, Mar 29, 2018 at 01:21:38PM +0100, Andre Przywara wrote:
>> Hi,
>>
>> On 29/03/18 10:37, Maxime Ripard wrote:
>>> On Wed, Mar 28, 2018 at 07:31:51PM +0800, Icenowy Zheng wrote:
 于 2018年3月28日 GMT+08:00 下午7:28:07, Maxime Ripard 
  写到:
> On Mon, Mar 26, 2018 at 03:11:04PM +0800, Icenowy Zheng wrote:
>>
>>
>> 于 2018年3月26日 GMT+08:00 下午3:06:33, Maxime Ripard
>  写到:
>>> On Fri, Mar 23, 2018 at 05:41:43PM +0800, Icenowy Zheng wrote:


 于 2018年3月23日 GMT+08:00 下午5:40:41, Maxime Ripard
>>>  写到:
> On Fri, Mar 23, 2018 at 04:18:56PM +0800, Icenowy Zheng wrote:
>> The get_ram_size() function in U-Boot can only deal with memory
>>> size
>> smaller than 2GiB. To enable the support of 3GiB DRAM on newer
>>> 64-bit
>> SoCs, an alternative way to detect DRAM size is needed.
>
> Why not just fixing get_ram_size then?

 Even if it's fixed it won't support 3GiB DRAM at all.
>>>
>>> Why?
>>
>> It has an assumption that the size is pow of 2.
>
> I guess this would be fixable too? (or one could create a variant
> without that assumption).

 I don't think its principle allows such kind of fix, as it just
 checks writing then reading at some offset that is pow if 2.
>>>
>>> You could do have a bunch of algorithm actually. One would be to write
>>> the address in memory and try to detect where exactly it starts to
>>> loop.
>>>
>>> You could do a bisection in the opposite direction once you settled
>>> for the upper limit (so you would have for example a workable 2G, a
>>> non-workable 4G, and then you try intervals that you always divide by
>>> two, so testing then 3G (that works), then halfway between 3G and 4G,
>>> etc.
>>>
 For hacking it, see my implementation in v1, which assumes the
 only size supported bigger than 2GiB is 3GiB (which is
 acceptable on sunxi, but might not work on other platforms).

 As Andre said, that function has another big problem -- it detects
 memory with writing to it. This is risky.
>>>
>>> How is it risky when it's done by the SPL?
>>
>> Originally that was my confusion as well: It's not the SPL calling that
>> function. The DRAM controller init function in there knows very
>> precisely how much DRAM we have, but we don't communicate this to U-Boot
>> proper. So U-Boot *proper* goes ahead and probes the DRAM. This means it
>> could step into secure memory, for instance. On sunxi64 we have the ATF
>> running between SPL and U-Boot, also all kind of secure payloads could
>> already have been registered.
>> So I wonder if it would be easier to somehow pass on this *one* word of
>> information between SPL and U-Boot proper to avoid calling this function
>> altogether?
> 
> That would definitely make sense yes.

So since the SPL loads the DT anyway (from the FIT image) and puts it at
the end of the U-Boot (proper) binary, wouldn't it be the easiest to
just patch the actual DRAM size in there?
IIRC we don't have any FDT write code in the SPL at the moment, and
pulling it in would probably push it over the edge again, but:
We should be able to somewhat short-cut it, if it's just about to
actually *patch* an existing value, as of:
- make sure we have a memory node and a reg property in the DT
- in the SPL learn the fdt offset of that reg property
-  patch in the memory size into the second word 
- teach U-Boot proper to read the memory size from the DT
- optionally look at #address-cells and #size-cells to make this "second
word hack" more robust

This could actually be a rather generic patch, just with some "avoid
libfdt write library" hack to address our size issue. Maybe we already
have something like that for some platform (Rockchip comes to mind?)

How does that sound?

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

Re: [U-Boot] [PATCH] arm: stm32mp1: add PSCI support

[Patrick DELAUNAY]

Hi Tom

> From: Tom Rini [mailto:tr...@konsulko.com]
> 
> On Thu, Mar 29, 2018 at 04:59:21PM +, Patrick DELAUNAY wrote:
> > Hi  Mark,
> >
> >
> > > From: Mark Rutland [mailto:mark.rutl...@arm.com]
> > >
> > > Hi,
> > >
> > > On Tue, Mar 20, 2018 at 01:59:03PM +0100, Patrick Delaunay wrote:
> > > > Add minimal PSCI support for Linux.
> > > >
> > > > Signed-off-by: Patrick Delaunay 
> > >
> > > I'm a bit worried, because while PSCI_VERSION reports PSCI 1.0, this
> > > does not appear to be conformant with teh PSCI 1.0 spec, as some
> > > mandatory functions are missing:
> > >
> > > * AFFINITY_INFO -- Linux relies on this to ensure that CPUs have exited
> > >   the kernel when calling CPU_OFF (e.g. so that we don't free any data /
> > >   code that said CPU may be using on the path to calling CPU_OFF).
> > >
> > > * SYSTEM_OFF -- Can you implement this similarly to SYSTEM_RESET?
> >
> > I push this patch for STM32MP1 to be able to boot the Kernel version
> > on board (requested by ST Linux team :
> > https://patchwork.kernel.org/patch/10167343/)
> >
> > This patch  a minimal PSCI support to be able to boot
> > And I miss these part of the requirement PSCI v1.0 and also in issue in 
> > Linux
> trace:
> >
> > [0.00] psci: probing for conduit method from DT.
> > [0.00] psci: PSCIv1.0 detected in firmware.
> > [0.00] psci: Using standard PSCI v0.2 function IDs
> > [0.00] psci: MIGRATE_INFO_TYPE not supported.
> >
> > Thanks to point these point .
> > So I will add them in a second patch " arm: stm32mp1: complete PSCI v1.0
> support"
> >
> > I want keep this patch in v1, to have it merged in v2018.05-rc1, I hope...
> > Even if it is only a first step for a full PSCI v1.0 support, that allow 
> > linux kernel
> boot.
> >
> > And I need some time to check how to handle SYSTEM_OFF , to do the
> "completely removes power" because I don't think if it is possible today.
> >
> > > > +int __secure psci_cpu_on(u32 __always_unused unused, u32 mpidr,
> > > > +u32
> > > > +pc) {
> > >
> > > What about the context_id? PSCI 0.2+ mandates it, and some project
> > > rely upon it (though Linux currently does not).
> >
> > Yes context_id is not used in my code.
> >
> > In fact, I use the same psci_cpu_on prototypes and logic than other 
> > platform :
> >  ./arch/arm/cpu/armv7/sunxi/psci.c:246
> > ./arch/arm/mach-uniphier/arm32/psci.c:134
> > ./arch/arm/cpu/armv7/ls102xa/psci.S:117
> >
> > => all are based on psci_save_target_pc() to save the PC in secure context
> (psci_target_pc[])
> > ./arch/arm/cpu/armv7/psci-common.c:29
> >
> > But context is not saved or used in generic PSCI code, only pc is restored
> > => ./arch/arm/cpu/armv7/psci.S:330
> > r0 = psci_get_target_pc() is called before _do_nonsec_entry
> >
> > I will check deeper in this U-Boot PSCI code.
> >
> > => I try to solve the problem and push a RFC or a patch  to have feedback 
> > form
> other PSCI user.
> >  Even it is not block for Linux point of view, as context ID is not 
> > used in linux
> code always = 0:
> >  ./drivers/firmware/psci.c:
> > static int psci_cpu_on(unsigned long cpuid, unsigned long entry_point)
> > 
> > err = invoke_psci_fn(fn, cpuid, entry_point, 0);
> >
> > > Does some other part of U-Boot do some state tracking? What happens
> > > if this is called for a CPU that's already online?
> >
> > No issue,  the CPU continue to run
> > TAMP register is only used by BootRom to unpark the cpu on boot, update of
> the backup have no impact when the CPU is running.
> >
> > I will add a comment in the next patch " arm: stm32mp1: complete PSCI v1.0
> support"
> > and also check if I can add test the cpu state to manage other possible 
> > return
> value (never used in U-Boot):
> > PSCI_RET_ALREADY_ON
> > PSCI_RET_ON_PENDING
> >
> > >
> > > Thanks,
> > > Mark.
> >
> > Very thanks for the review.
> > That allows me to read deeper the PSCI documents.
> >
> > Tom:  do you think that this patch can be merged in v2018.05-rc1 ?
> >and I will sent a 2nd patch for full PCSI v1.0 support and 
> > correct the
> missing parts reported by Mark.
> 
> Lets see how far along you get before the v2018.05 final.  I don't think it's 
> a
> good idea to claim PSCI 1.0 support and not provide all of the required
> functionality, as that would be breaking the point of declaring that you 
> support
> something like that :)  Thanks!
> 
> --
> Tom

I understood and I am agree that it is better, 
So I will push a v2 as soon as possible with minimal PSCI v1.0 (adding the 2 
missing functions).

And an other patch to save the context ID for PSCI on arm v7 (with perhaps 
impact on other platform).

Patrick


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

[U-Boot] [PATCH v2 u-boot 1/2] clk: Add get/enable/disable/release for a bulk of clocks

[Neil Armstrong]

This patch adds a "bulk" API to the clock API in order to get/enable/disable
/release a group of clocks associated with a device.

This bulk API will avoid adding a copy of the same code to manage
a group of clocks in drivers.

Signed-off-by: Neil Armstrong 
---
 drivers/clk/clk-uclass.c | 59 +++
 include/clk.h| 72 +++-
 2 files changed, 130 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index ad76379..6e99b3b 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -104,6 +104,39 @@ int clk_get_by_index(struct udevice *dev, int index, 
struct clk *clk)
return clk_get_by_indexed_prop(dev, "clocks", index, clk);
 }
 
+int clk_get_bulk(struct udevice *dev, struct clk_bulk *bulk)
+{
+   int i, ret, err, count;
+   
+   bulk->count = 0;
+
+   count = dev_count_phandle_with_args(dev, "clocks", "#clock-cells");
+   if (!count)
+   return 0;
+
+   bulk->clks = devm_kcalloc(dev, count, sizeof(struct clk), GFP_KERNEL);
+   if (!bulk->clks)
+   return -ENOMEM;
+
+   for (i = 0; i < count; i++) {
+   ret = clk_get_by_index(dev, i, >clks[i]);
+   if (ret < 0)
+   goto bulk_get_err;
+
+   ++bulk->count;
+   }
+
+   return 0;
+
+bulk_get_err:
+   err = clk_release_all(bulk->clks, bulk->count);
+   if (err)
+   debug("%s: could release all clocks for %p\n",
+ __func__, dev);
+
+   return ret;
+}
+
 static int clk_set_default_parents(struct udevice *dev)
 {
struct clk clk, parent_clk;
@@ -336,6 +369,19 @@ int clk_enable(struct clk *clk)
return ops->enable(clk);
 }
 
+int clk_enable_bulk(struct clk_bulk *bulk)
+{
+   int i, ret;
+
+   for (i = 0; i < bulk->count; i++) {
+   ret = clk_enable(>clks[i]);
+   if (ret < 0 && ret != -ENOSYS)
+   return ret;
+   }
+
+   return 0;
+}
+
 int clk_disable(struct clk *clk)
 {
const struct clk_ops *ops = clk_dev_ops(clk->dev);
@@ -348,6 +394,19 @@ int clk_disable(struct clk *clk)
return ops->disable(clk);
 }
 
+int clk_disable_bulk(struct clk_bulk *bulk)
+{
+   int i, ret;
+
+   for (i = 0; i < bulk->count; i++) {
+   ret = clk_disable(>clks[i]);
+   if (ret < 0 && ret != -ENOSYS)
+   return ret;
+   }
+
+   return 0;
+}
+
 UCLASS_DRIVER(clk) = {
.id = UCLASS_CLK,
.name   = "clk",
diff --git a/include/clk.h b/include/clk.h
index a7d95d3..b3a9fce 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -60,6 +60,23 @@ struct clk {
unsigned long id;
 };
 
+/**
+ * struct clk_bulk - A handle to (allowing control of) a bulk of clocks.
+ *
+ * Clients provide storage for the clock bulk. The content of the structure is
+ * managed solely by the clock API. A clock bulk struct is
+ * initialized by "get"ing the clock bulk struct.
+ * The clock bulk struct is passed to all other bulk clock APIs to apply
+ * the API to all the clock in the bulk struct.
+ *
+ * @clks: An array of clock handles.
+ * @count: The number of clock handles in the clks array.
+ */
+struct clk_bulk {
+   struct clk *clks;
+   unsigned int count;
+};
+
 #if CONFIG_IS_ENABLED(OF_CONTROL) && CONFIG_IS_ENABLED(CLK)
 struct phandle_1_arg;
 int clk_get_by_index_platdata(struct udevice *dev, int index,
@@ -83,6 +100,21 @@ int clk_get_by_index_platdata(struct udevice *dev, int 
index,
 int clk_get_by_index(struct udevice *dev, int index, struct clk *clk);
 
 /**
+ * clock_get_bulk - Get/request all clocks of a device.
+ *
+ * This looks up and requests all clocks of the client device; each device is
+ * assumed to have n clocks associated with it somehow, and this function finds
+ * and requests all of them in a separate structure. The mapping of client
+ * device clock indices to provider clocks may be via device-tree properties,
+ * board-provided mapping tables, or some other mechanism.
+ *
+ * @dev:   The client device.
+ * @bulk   A pointer to a clock bulk struct to initialize.
+ * @return 0 if OK, or a negative error code.
+ */
+int clk_get_bulk(struct udevice *dev, struct clk_bulk *bulk);
+
+/**
  * clock_get_by_name - Get/request a clock by name.
  *
  * This looks up and requests a clock. The name is relative to the client
@@ -120,6 +152,11 @@ static inline int clk_get_by_index(struct udevice *dev, 
int index,
return -ENOSYS;
 }
 
+static inline int clk_get_bulk(struct udevice *dev, struct clk_bulk *bulk)
+{
+   return -ENOSYS;
+}
+
 static inline int clk_get_by_name(struct udevice *dev, const char *name,
   struct clk *clk)
 {
@@ -130,7 +167,6 @@ static inline int clk_release_all(struct clk *clk, int 
count)
 {
return -ENOSYS;
 

[U-Boot] [PATCH v2 u-boot 2/2] clk: add sandbox test for bulk API

[Neil Armstrong]

This patch adds the bulk clock API tests for the sandbox test suite.

It's very similar to the main test but only uses the _bulk() API and
checks if the clocks are correctly enabled/disabled.

Signed-off-by: Neil Armstrong 
---
 arch/sandbox/include/asm/clk.h | 32 
 drivers/clk/clk_sandbox_test.c | 29 +
 test/dm/clk.c  | 38 ++
 3 files changed, 99 insertions(+)

diff --git a/arch/sandbox/include/asm/clk.h b/arch/sandbox/include/asm/clk.h
index 9dc6c81..01b5ba4 100644
--- a/arch/sandbox/include/asm/clk.h
+++ b/arch/sandbox/include/asm/clk.h
@@ -64,6 +64,14 @@ int sandbox_clk_query_enable(struct udevice *dev, int id);
  */
 int sandbox_clk_test_get(struct udevice *dev);
 /**
+ * sandbox_clk_test_get_bulk - Ask the sandbox clock test device to request its
+ * clocks with the bulk clk API.
+ *
+ * @dev:   The sandbox clock test (client) devivce.
+ * @return:0 if OK, or a negative error code.
+ */
+int sandbox_clk_test_get_bulk(struct udevice *dev);
+/**
  * sandbox_clk_test_get_rate - Ask the sandbox clock test device to query a
  * clock's rate.
  *
@@ -91,6 +99,14 @@ ulong sandbox_clk_test_set_rate(struct udevice *dev, int id, 
ulong rate);
  */
 int sandbox_clk_test_enable(struct udevice *dev, int id);
 /**
+ * sandbox_clk_test_enable_bulk - Ask the sandbox clock test device to enable
+ * all clocks in it's clock bulk struct.
+ *
+ * @dev:   The sandbox clock test (client) devivce.
+ * @return:0 if OK, or a negative error code.
+ */
+int sandbox_clk_test_enable_bulk(struct udevice *dev);
+/**
  * sandbox_clk_test_disable - Ask the sandbox clock test device to disable a
  * clock.
  *
@@ -100,6 +116,14 @@ int sandbox_clk_test_enable(struct udevice *dev, int id);
  */
 int sandbox_clk_test_disable(struct udevice *dev, int id);
 /**
+ * sandbox_clk_test_disable_bulk - Ask the sandbox clock test device to disable
+ * all clocks in it's clock bulk struct.
+ *
+ * @dev:   The sandbox clock test (client) devivce.
+ * @return:0 if OK, or a negative error code.
+ */
+int sandbox_clk_test_disable_bulk(struct udevice *dev);
+/**
  * sandbox_clk_test_free - Ask the sandbox clock test device to free its
  * clocks.
  *
@@ -107,5 +131,13 @@ int sandbox_clk_test_disable(struct udevice *dev, int id);
  * @return:0 if OK, or a negative error code.
  */
 int sandbox_clk_test_free(struct udevice *dev);
+/**
+ * sandbox_clk_test_release_bulk - Ask the sandbox clock test device to release
+ * all clocks in it's clock bulk struct.
+ *
+ * @dev:   The sandbox clock test (client) devivce.
+ * @return:0 if OK, or a negative error code.
+ */
+int sandbox_clk_test_release_bulk(struct udevice *dev);
 
 #endif
diff --git a/drivers/clk/clk_sandbox_test.c b/drivers/clk/clk_sandbox_test.c
index 999100d..d089881 100644
--- a/drivers/clk/clk_sandbox_test.c
+++ b/drivers/clk/clk_sandbox_test.c
@@ -11,6 +11,7 @@
 
 struct sandbox_clk_test {
struct clk clks[SANDBOX_CLK_TEST_ID_COUNT];
+   struct clk_bulk bulk;
 };
 
 static const char * const sandbox_clk_test_names[] = {
@@ -34,6 +35,13 @@ int sandbox_clk_test_get(struct udevice *dev)
return 0;
 }
 
+int sandbox_clk_test_get_bulk(struct udevice *dev)
+{
+   struct sandbox_clk_test *sbct = dev_get_priv(dev);
+
+   return clk_get_bulk(dev, >bulk);
+}
+
 ulong sandbox_clk_test_get_rate(struct udevice *dev, int id)
 {
struct sandbox_clk_test *sbct = dev_get_priv(dev);
@@ -64,6 +72,13 @@ int sandbox_clk_test_enable(struct udevice *dev, int id)
return clk_enable(>clks[id]);
 }
 
+int sandbox_clk_test_enable_bulk(struct udevice *dev)
+{
+   struct sandbox_clk_test *sbct = dev_get_priv(dev);
+
+   return clk_enable_bulk(>bulk);
+}
+
 int sandbox_clk_test_disable(struct udevice *dev, int id)
 {
struct sandbox_clk_test *sbct = dev_get_priv(dev);
@@ -74,6 +89,13 @@ int sandbox_clk_test_disable(struct udevice *dev, int id)
return clk_disable(>clks[id]);
 }
 
+int sandbox_clk_test_disable_bulk(struct udevice *dev)
+{
+   struct sandbox_clk_test *sbct = dev_get_priv(dev);
+
+   return clk_disable_bulk(>bulk);
+}
+
 int sandbox_clk_test_free(struct udevice *dev)
 {
struct sandbox_clk_test *sbct = dev_get_priv(dev);
@@ -88,6 +110,13 @@ int sandbox_clk_test_free(struct udevice *dev)
return 0;
 }
 
+int sandbox_clk_test_release_bulk(struct udevice *dev)
+{
+   struct sandbox_clk_test *sbct = dev_get_priv(dev);
+
+   return clk_release_bulk(>bulk);
+}
+
 static const struct udevice_id sandbox_clk_test_ids[] = {
{ .compatible = "sandbox,clk-test" },
{ }
diff --git a/test/dm/clk.c b/test/dm/clk.c
index 712a1e6..95716f8 100644
--- a/test/dm/clk.c
+++ b/test/dm/clk.c
@@ -101,3 +101,41 @@ static int dm_test_clk(struct unit_test_state *uts)
return 0;
 }
 DM_TEST(dm_test_clk, DM_TESTF_SCAN_FDT);
+
+static int 

[U-Boot] [PATCH v2 u-boot 0/2] clk: Add get/enable/disable/release for a bulk of clocks

[Neil Armstrong]

This patch adds a "bulk" API to the clock API in order to get/enable/disable
/release a group of clocks associated with a device.

This bulk API will avoid adding a copy of the same code to manage
a group of clocks in drivers.

This serie and the "reset bulk" serie is necessary and suggested by Marek Vasut
for the "Add USB Support for Amlogic Meson GXL SoCs" to avoid adding the same
code to manage a bulk of clocks and resets in another driver.
I will push a RFC code to update the other drivers having a similar
code pattern when these patches are merged.

The second patch adds the bulk clock API tests for the sandbox test suite.

Changes since v1 :
 - Add sandbox tests

Neil Armstrong (2):
  clk: Add get/enable/disable/release for a bulk of clocks
  clk: add sandbox test for bulk API

 arch/sandbox/include/asm/clk.h | 32 +++
 drivers/clk/clk-uclass.c   | 59 ++
 drivers/clk/clk_sandbox_test.c | 29 +
 include/clk.h  | 72 +-
 test/dm/clk.c  | 38 ++
 5 files changed, 229 insertions(+), 1 deletion(-)

-- 
2.7.4

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

[U-Boot] [PATCH v2 u-boot 2/2] reset: add sandbox test for bulk API

[Neil Armstrong]

This patch adds the bulk reset API tests for the sandbox test suite.

Unlike the main test, it also check the "other" reset signal using the bulk API
and checks if the resets are correctly asserted/deasserted.

To allow the bulk API to work, and avoid changing the DT, the number of resets
of the sandbox reset controller has been bumped to 101 for the "other" reset
line to be valid.

Signed-off-by: Neil Armstrong 
---
 arch/sandbox/include/asm/reset.h   |  4 
 drivers/reset/sandbox-reset-test.c | 29 +
 drivers/reset/sandbox-reset.c  |  2 +-
 test/dm/reset.c| 33 +
 4 files changed, 67 insertions(+), 1 deletion(-)

diff --git a/arch/sandbox/include/asm/reset.h b/arch/sandbox/include/asm/reset.h
index 7146aa5..0cd7702 100644
--- a/arch/sandbox/include/asm/reset.h
+++ b/arch/sandbox/include/asm/reset.h
@@ -14,8 +14,12 @@ struct udevice;
 int sandbox_reset_query(struct udevice *dev, unsigned long id);
 
 int sandbox_reset_test_get(struct udevice *dev);
+int sandbox_reset_test_get_bulk(struct udevice *dev);
 int sandbox_reset_test_assert(struct udevice *dev);
+int sandbox_reset_test_assert_bulk(struct udevice *dev);
 int sandbox_reset_test_deassert(struct udevice *dev);
+int sandbox_reset_test_deassert_bulk(struct udevice *dev);
 int sandbox_reset_test_free(struct udevice *dev);
+int sandbox_reset_test_release_bulk(struct udevice *dev);
 
 #endif
diff --git a/drivers/reset/sandbox-reset-test.c 
b/drivers/reset/sandbox-reset-test.c
index e37d6c9..f0ceaa0 100644
--- a/drivers/reset/sandbox-reset-test.c
+++ b/drivers/reset/sandbox-reset-test.c
@@ -12,6 +12,7 @@
 
 struct sandbox_reset_test {
struct reset_ctl ctl;
+   struct reset_ctl_bulk bulk;
 };
 
 int sandbox_reset_test_get(struct udevice *dev)
@@ -21,6 +22,13 @@ int sandbox_reset_test_get(struct udevice *dev)
return reset_get_by_name(dev, "test", >ctl);
 }
 
+int sandbox_reset_test_get_bulk(struct udevice *dev)
+{
+   struct sandbox_reset_test *sbrt = dev_get_priv(dev);
+
+   return reset_get_bulk(dev, >bulk);
+}
+
 int sandbox_reset_test_assert(struct udevice *dev)
 {
struct sandbox_reset_test *sbrt = dev_get_priv(dev);
@@ -28,6 +36,13 @@ int sandbox_reset_test_assert(struct udevice *dev)
return reset_assert(>ctl);
 }
 
+int sandbox_reset_test_assert_bulk(struct udevice *dev)
+{
+   struct sandbox_reset_test *sbrt = dev_get_priv(dev);
+
+   return reset_assert_bulk(>bulk);
+}
+
 int sandbox_reset_test_deassert(struct udevice *dev)
 {
struct sandbox_reset_test *sbrt = dev_get_priv(dev);
@@ -35,6 +50,13 @@ int sandbox_reset_test_deassert(struct udevice *dev)
return reset_deassert(>ctl);
 }
 
+int sandbox_reset_test_deassert_bulk(struct udevice *dev)
+{
+   struct sandbox_reset_test *sbrt = dev_get_priv(dev);
+
+   return reset_deassert_bulk(>bulk);
+}
+
 int sandbox_reset_test_free(struct udevice *dev)
 {
struct sandbox_reset_test *sbrt = dev_get_priv(dev);
@@ -42,6 +64,13 @@ int sandbox_reset_test_free(struct udevice *dev)
return reset_free(>ctl);
 }
 
+int sandbox_reset_test_release_bulk(struct udevice *dev)
+{
+   struct sandbox_reset_test *sbrt = dev_get_priv(dev);
+
+   return reset_release_bulk(>bulk);
+}
+
 static const struct udevice_id sandbox_reset_test_ids[] = {
{ .compatible = "sandbox,reset-ctl-test" },
{ }
diff --git a/drivers/reset/sandbox-reset.c b/drivers/reset/sandbox-reset.c
index 4258af5..c310749 100644
--- a/drivers/reset/sandbox-reset.c
+++ b/drivers/reset/sandbox-reset.c
@@ -10,7 +10,7 @@
 #include 
 #include 
 
-#define SANDBOX_RESET_SIGNALS 3
+#define SANDBOX_RESET_SIGNALS 101
 
 struct sandbox_reset_signal {
bool asserted;
diff --git a/test/dm/reset.c b/test/dm/reset.c
index 0ae8031..8dc0023 100644
--- a/test/dm/reset.c
+++ b/test/dm/reset.c
@@ -13,6 +13,9 @@
 /* This must match the specifier for mbox-names="test" in the DT node */
 #define TEST_RESET_ID 2
 
+/* This is the other reset phandle specifier handled by bulk */
+#define OTHER_RESET_ID 2
+
 static int dm_test_reset(struct unit_test_state *uts)
 {
struct udevice *dev_reset;
@@ -37,3 +40,33 @@ static int dm_test_reset(struct unit_test_state *uts)
return 0;
 }
 DM_TEST(dm_test_reset, DM_TESTF_SCAN_FDT);
+
+static int dm_test_reset_bulk(struct unit_test_state *uts)
+{
+   struct udevice *dev_reset;
+   struct udevice *dev_test;
+
+   ut_assertok(uclass_get_device_by_name(UCLASS_RESET, "reset-ctl",
+ _reset));
+   ut_asserteq(0, sandbox_reset_query(dev_reset, TEST_RESET_ID));
+   ut_asserteq(0, sandbox_reset_query(dev_reset, OTHER_RESET_ID));
+
+   ut_assertok(uclass_get_device_by_name(UCLASS_MISC, "reset-ctl-test",
+ _test));
+   ut_assertok(sandbox_reset_test_get_bulk(dev_test));
+
+   

[U-Boot] [PATCH v2 u-boot 1/2] reset: Add get/assert/deassert/release for bulk of reset signals

[Neil Armstrong]

This patch adds a "bulk" API to the reset API in order to get/deassert/
assert/release a group of reset signals associated with a device.

This bulk API will avoid adding a copy of the same code to manage
a group of reset signals in drivers.

Signed-off-by: Neil Armstrong 
---
 drivers/reset/reset-uclass.c | 60 +++
 include/reset.h  | 99 
 2 files changed, 159 insertions(+)

diff --git a/drivers/reset/reset-uclass.c b/drivers/reset/reset-uclass.c
index 307a297..9a5c9c9 100644
--- a/drivers/reset/reset-uclass.c
+++ b/drivers/reset/reset-uclass.c
@@ -81,6 +81,40 @@ int reset_get_by_index(struct udevice *dev, int index,
return 0;
 }
 
+int reset_get_bulk(struct udevice *dev, struct reset_ctl_bulk *bulk)
+{
+   int i, ret, err, count;
+   
+   bulk->count = 0;
+
+   count = dev_count_phandle_with_args(dev, "resets", "#reset-cells");
+   if (!count)
+   return 0;
+
+   bulk->resets = devm_kcalloc(dev, count, sizeof(struct reset_ctl),
+   GFP_KERNEL);
+   if (!bulk->resets)
+   return -ENOMEM;
+
+   for (i = 0; i < count; i++) {
+   ret = reset_get_by_index(dev, i, >resets[i]);
+   if (ret < 0)
+   goto bulk_get_err;
+
+   ++bulk->count;
+   }
+
+   return 0;
+
+bulk_get_err:
+   err = reset_release_all(bulk->resets, bulk->count);
+   if (err)
+   debug("%s: could release all resets for %p\n",
+ __func__, dev);
+
+   return ret;
+}
+
 int reset_get_by_name(struct udevice *dev, const char *name,
 struct reset_ctl *reset_ctl)
 {
@@ -126,6 +160,19 @@ int reset_assert(struct reset_ctl *reset_ctl)
return ops->rst_assert(reset_ctl);
 }
 
+int reset_assert_bulk(struct reset_ctl_bulk *bulk)
+{
+   int i, ret;
+
+   for (i = 0; i < bulk->count; i++) {
+   ret = reset_assert(>resets[i]);
+   if (ret < 0)
+   return ret;
+   }
+
+   return 0;
+}
+
 int reset_deassert(struct reset_ctl *reset_ctl)
 {
struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
@@ -135,6 +182,19 @@ int reset_deassert(struct reset_ctl *reset_ctl)
return ops->rst_deassert(reset_ctl);
 }
 
+int reset_deassert_bulk(struct reset_ctl_bulk *bulk)
+{
+   int i, ret;
+
+   for (i = 0; i < bulk->count; i++) {
+   ret = reset_deassert(>resets[i]);
+   if (ret < 0)
+   return ret;
+   }
+
+   return 0;
+}
+
 int reset_release_all(struct reset_ctl *reset_ctl, int count)
 {
int i, ret;
diff --git a/include/reset.h b/include/reset.h
index 7185ade..d38f176 100644
--- a/include/reset.h
+++ b/include/reset.h
@@ -60,6 +60,24 @@ struct reset_ctl {
unsigned long id;
 };
 
+/**
+ * struct reset_ctl_bulk - A handle to (allowing control of) a bulk of reset
+ * signals.
+ *
+ * Clients provide storage for the reset control bulk. The content of the
+ * structure is managed solely by the reset API. A reset control bulk struct is
+ * initialized by "get"ing the reset control bulk struct.
+ * The reset control bulk struct is passed to all other bulk reset APIs to 
apply
+ * the API to all the reset signals in the bulk struct.
+ *
+ * @resets: An array of reset signal handles handles.
+ * @count: The number of reset signal handles in the reset array.
+ */
+struct reset_ctl_bulk {
+   struct reset_ctl *resets;
+   unsigned int count;
+};
+
 #ifdef CONFIG_DM_RESET
 /**
  * reset_get_by_index - Get/request a reset signal by integer index.
@@ -81,6 +99,22 @@ int reset_get_by_index(struct udevice *dev, int index,
   struct reset_ctl *reset_ctl);
 
 /**
+ * reset_get_bulk - Get/request all reset signals of a device.
+ *
+ * This looks up and requests all reset signals of the client device; each
+ * device is assumed to have n reset signals associated with it somehow,
+ * and this function finds and requests all of them in a separate structure.
+ * The mapping of client device reset signals indices to provider reset signals
+ * may be via device-tree properties, board-provided mapping tables, or some
+ * other mechanism.
+ *
+ * @dev:   The client device.
+ * @bulk   A pointer to a reset control bulk struct to initialize.
+ * @return 0 if OK, or a negative error code.
+ */
+int reset_get_bulk(struct udevice *dev, struct reset_ctl_bulk *bulk);
+
+/**
  * reset_get_by_name - Get/request a reset signal by name.
  *
  * This looks up and requests a reset signal. The name is relative to the
@@ -132,6 +166,21 @@ int reset_free(struct reset_ctl *reset_ctl);
 int reset_assert(struct reset_ctl *reset_ctl);
 
 /**
+ * reset_assert_bulk - Assert all reset signals in a reset control bulk struct.
+ *
+ * This function will assert the specified reset signals in a reset control
+ * 

[U-Boot] [PATCH v2 u-boot 0/2] reset: Add get/assert/deassert/release for bulk of reset signals

[Neil Armstrong]

This patch adds a "bulk" API to the reset API in order to get/deassert/
assert/release a group of reset signals associated with a device.

This bulk API will avoid adding a copy of the same code to manage
a group of reset signals in drivers.

This serie and the "clk bulk" serie is necessary and suggested by Marek Vasut
for the "Add USB Support for Amlogic Meson GXL SoCs" to avoid adding the same
code to manage a bulk of clocks and resets in another driver.
I will push a RFC code to update the other drivers having a similar
code pattern when these patches are merged.

The second patch adds the bulk reset API tests for the sandbox test suite.

Changes since v1 :
 - Add sandbox tests

Neil Armstrong (2):
  reset: Add get/assert/deassert/release for bulk of reset signals
  reset: add sandbox test for bulk API

 arch/sandbox/include/asm/reset.h   |  4 ++
 drivers/reset/reset-uclass.c   | 60 +++
 drivers/reset/sandbox-reset-test.c | 29 +++
 drivers/reset/sandbox-reset.c  |  2 +-
 include/reset.h| 99 ++
 test/dm/reset.c| 33 +
 6 files changed, 226 insertions(+), 1 deletion(-)

-- 
2.7.4

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

Re: [U-Boot] [PATCH v2 5/6] sunxi: add code for recalculating the DRAM size in U-Boot

[Maxime Ripard]

On Thu, Mar 29, 2018 at 01:21:38PM +0100, Andre Przywara wrote:
> Hi,
> 
> On 29/03/18 10:37, Maxime Ripard wrote:
> > On Wed, Mar 28, 2018 at 07:31:51PM +0800, Icenowy Zheng wrote:
> >> 于 2018年3月28日 GMT+08:00 下午7:28:07, Maxime Ripard 
> >>  写到:
> >>> On Mon, Mar 26, 2018 at 03:11:04PM +0800, Icenowy Zheng wrote:
> 
> 
>  于 2018年3月26日 GMT+08:00 下午3:06:33, Maxime Ripard
> >>>  写到:
> > On Fri, Mar 23, 2018 at 05:41:43PM +0800, Icenowy Zheng wrote:
> >>
> >>
> >> 于 2018年3月23日 GMT+08:00 下午5:40:41, Maxime Ripard
> >  写到:
> >>> On Fri, Mar 23, 2018 at 04:18:56PM +0800, Icenowy Zheng wrote:
>  The get_ram_size() function in U-Boot can only deal with memory
> > size
>  smaller than 2GiB. To enable the support of 3GiB DRAM on newer
> > 64-bit
>  SoCs, an alternative way to detect DRAM size is needed.
> >>>
> >>> Why not just fixing get_ram_size then?
> >>
> >> Even if it's fixed it won't support 3GiB DRAM at all.
> >
> > Why?
> 
>  It has an assumption that the size is pow of 2.
> >>>
> >>> I guess this would be fixable too? (or one could create a variant
> >>> without that assumption).
> >>
> >> I don't think its principle allows such kind of fix, as it just
> >> checks writing then reading at some offset that is pow if 2.
> > 
> > You could do have a bunch of algorithm actually. One would be to write
> > the address in memory and try to detect where exactly it starts to
> > loop.
> > 
> > You could do a bisection in the opposite direction once you settled
> > for the upper limit (so you would have for example a workable 2G, a
> > non-workable 4G, and then you try intervals that you always divide by
> > two, so testing then 3G (that works), then halfway between 3G and 4G,
> > etc.
> > 
> >> For hacking it, see my implementation in v1, which assumes the
> >> only size supported bigger than 2GiB is 3GiB (which is
> >> acceptable on sunxi, but might not work on other platforms).
> >>
> >> As Andre said, that function has another big problem -- it detects
> >> memory with writing to it. This is risky.
> > 
> > How is it risky when it's done by the SPL?
> 
> Originally that was my confusion as well: It's not the SPL calling that
> function. The DRAM controller init function in there knows very
> precisely how much DRAM we have, but we don't communicate this to U-Boot
> proper. So U-Boot *proper* goes ahead and probes the DRAM. This means it
> could step into secure memory, for instance. On sunxi64 we have the ATF
> running between SPL and U-Boot, also all kind of secure payloads could
> already have been registered.
> So I wonder if it would be easier to somehow pass on this *one* word of
> information between SPL and U-Boot proper to avoid calling this function
> altogether?

That would definitely make sense yes.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [U-Boot] [PATCH 1/6] arm64: zynqmp: Add support for zcu100 aka 96ultra board

[Michal Simek]

Hi,

On 31.3.2018 23:38, Alexander Graf wrote:
> 
> 
> On 28.03.18 17:06, Michal Simek wrote:
>> Add support for Xilinx zcu100.
>>
>> Signed-off-by: Michal Simek 
> 
> When I apply this on top of 2018.03 and boot it on a ZCU100 with FSBL,
> something seems to get stuck in i2c enumeration:
> 
> PMUFW: v0.3
> 
> 
> U-Boot 2018.03-00049-g6572147745 (Mar 31 2018 - 23:29:06 +0200) Xilinx
> ZynqMP ZCU100 RevC
> 
> I2C:
> 

I depends on i2c and bitstream. But I shouldn't enable i2c0 port because
this is supposed to be routed via PL.

Please try this patch and let me know.

diff --git a/configs/xilinx_zynqmp_zcu100_revC_defconfig
b/configs/xilinx_zynqmp_zcu100_revC_defconfig
index 39c1425ec59d..1fcbb135cc96 100644
--- a/configs/xilinx_zynqmp_zcu100_revC_defconfig
+++ b/configs/xilinx_zynqmp_zcu100_revC_defconfig
@@ -48,7 +48,6 @@ CONFIG_FPGA_XILINX=y
 CONFIG_FPGA_ZYNQMPPL=y
 CONFIG_DM_GPIO=y
 CONFIG_SYS_I2C_ZYNQ=y
-CONFIG_ZYNQ_I2C0=y
 CONFIG_ZYNQ_I2C1=y
 CONFIG_MISC=y
 CONFIG_DM_MMC=y

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

Re: [U-Boot] [PATCH v2] tools: buildman: Don't use the working dir as build dir

[Lothar Waßmann]

Hi,

On Mon,  2 Apr 2018 02:43:12 -0600 Simon Glass wrote:
> From: Lothar Waßmann 
> 
> When the U-Boot base directory happens to have the same name as the branch
> that buildman is directed to use via the '-b' option and no output
> directory is specified with '-o', buildman happily starts removing the
> whole U-Boot sources eventually only stopped with the error message:
> 
> OSError: [Errno 20] Not a directory: '..//boards.cfg
> 
> Add a check to avoid this and also deal with the case where '-o' points
> to the source directory, or any subdirectory of it.
> 
> Finally, tidy up the confusing logic for removing the old tree when using
> -b. This is only done when building a branch.
> 
> Signed-off-by: Lothar Waßmann 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v2:
> - Updated to check directories on start-up as per comments on v1 patch
> - Added a test
> - Expanded check to handle subdirectories
> 
>  tools/buildman/builderthread.py |  4 
>  tools/buildman/control.py   | 28 +---
>  tools/buildman/func_test.py |  9 +
>  3 files changed, 38 insertions(+), 3 deletions(-)
> 
[...]
> diff --git a/tools/buildman/control.py b/tools/buildman/control.py
> index 3cac9f7cf6..5bf128357d 100644
> --- a/tools/buildman/control.py
> +++ b/tools/buildman/control.py
> @@ -81,6 +81,28 @@ def ShowActions(series, why_selected, boards_selected, 
> builder, options):
>  print ('Total boards to build for each commit: %d\n' %
>  len(why_selected['all']))
>  
> +def CheckOutputDir(output_dir):
> +"""Make sure that the output directory is not within the current 
> directory
> +
> +If we try to use an output directory which is within the current 
> directory
> +(which is assumed to hold the U-Boot source) we may end up deleting the
> +U-Boot source code. Detect this and print an error in this case.
> +
> +Args:
> +output_dir: Output directory path to check
> +"""
> +path = os.path.realpath(output_dir)
> +cwd_path = os.path.realpath('.')
> +while True:
> +if os.path.realpath(path) == cwd_path:
> +Print("Cannot use output directory '%s' since it is within the "
> +  "current directtory '%s'" % (path, cwd_path))
s/directtory/directory/
NB: IMO its a bad habit to split format strings across multiple lines,
since it makes it harder to grep the source code for a message
that was printed on the terminal.

Otherwise, looks good to me.

Tested-by: Lothar Waßmann 


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

Re: [U-Boot] [PATCH 2/2] image: fit: Show information about OS type in firwmare case too

[Michal Simek]

On 30.3.2018 10:40, Simon Glass wrote:
> On 26 March 2018 at 22:31, Michal Simek  wrote:
>> SPL ATF implementation requires FIT image with partitions where the one
>> is Firmware/ATF and another one Firmware/U-Boot. OS field is used for
>> recording that difference that's why make sense to show values there for
>> Firmware types.
>>
>> For example:
>>  Image 0 (atf)
>>   Description:  ATF bl31.bin
>>   Created:  Mon Mar 26 15:58:14 2018
>>   Type: Firmware
>>   Compression:  uncompressed
>>   Data Size:51152 Bytes = 49.95 KiB = 0.05 MiB
>>   Architecture: ARM
>>   OS:   ARM Trusted Firmware
>>   Load Address: 0xfffe
>>   Hash algo:md5
>>   Hash value:   36a4212bbb698126bf5a248f0f4b5336
>>  Image 1 (uboot)
>>   Description:  u-boot.bin
>>   Created:  Mon Mar 26 15:58:14 2018
>>   Type: Firmware
>>   Compression:  uncompressed
>>   Data Size:761216 Bytes = 743.38 KiB = 0.73 MiB
>>   Architecture: ARM
>>   OS:   U-Boot
>>   Load Address: 0x0800
>>   Hash algo:md5
>>   Hash value:   f22960fe429be72296dc8dc59a47d566
>>
>> Signed-off-by: Michal Simek 
>> ---
>>
>>  common/image-fit.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> Reviewed-by: Simon Glass 
> 
> But please fix the commit subject 'firwmare'.
> 

ok. Fixed.

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

Re: [U-Boot] [RFC] Reserve ATF memory on Marvell Armdada 3700/7K/8K

[Matwey V. Kornilov]

Hello,

I think I suffered from random kernel crashed due to this issue. Could
you please also submit this patch to downstream Marvell u-boot at github PR?

31.03.2018 17:13, Mark Kettenis пишет:
> Currently U-Boot doesn't make any effort to reserve the memory used by
> ARM Trusted Firmware on these platforms.  The result is that the
> memory is listed as available in the EFI memory map.  And as soon as a
> loaded kernel tries to use this memory things explode.  I've seen this
> with the OpenBSD kernel.  But I totally expect a Linux kernel to
> suffer the same fate.
> 
> I'm currently using the diff below, but it is not entirely clear to me
> if arch_early_init_r() is the appropriate place to do this.  I'm also
> wondering whether the block should also be marked as reserved in the
> FDT using fdt_add_mem_rsv().  If the latter is required this probably
> needs to be done by ft_board_setup() or ft_system_setup().
> 
> The address and size of the region have been taken from Marvell's ATF
> fork at
> 
>   https://github.com/MarvellEmbeddedProcessors/atf-marvell
> 
> The memory layout is defined in
> 
>   plat/marvell/a8k/common/include/platform_def.h
> 
> where there are lots of defines and a diagram that attempt to describe
> the memory.  It is not entirely obvious to me what part needs to be
> reserved.  But 0x040-0x0420 works.
> 
> 
> 
> 
> diff --git a/arch/arm/mach-mvebu/arm64-common.c 
> b/arch/arm/mach-mvebu/arm64-common.c
> index 3c84043a2c..895cd2852f 100644
> --- a/arch/arm/mach-mvebu/arm64-common.c
> +++ b/arch/arm/mach-mvebu/arm64-common.c
> @@ -95,5 +95,11 @@ int arch_early_init_r(void)
>   pci_init();
>  #endif
>  
> +#ifdef CONFIG_EFI_LOADER
> + /* Reserve trusted SRAM section */
> + efi_add_memory_map(0x0400, 0x0020 >> EFI_PAGE_SHIFT,
> +EFI_RESERVED_MEMORY_TYPE, false);
> +#endif
> +
>   return 0;
>  }
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 


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

Re: [U-Boot] [PATCH v2 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

[Alex Kiernan]

On Mon, Apr 2, 2018 at 4:11 PM, Felix Brack  wrote:
> On 02.04.2018 17:43, Alex Kiernan wrote:
>> On Mon, Apr 2, 2018 at 12:13 PM, Felix Brack  wrote:
>>> Hi Alex,
>>>
>>> On 01.04.2018 11:22, Alex Kiernan wrote:
 This converts CONFIG_DRIVER_TI_CPSW to Kconfig

 Signed-off-by: Alex Kiernan 
 Acked-by: Joe Hershberger 
 ---

 Changes in v2:
 - Move DRIVER_TI_CPSW outside of the NETDEVICES guard
 - Don't mark DRIVER_TI_CPSW default if ARCH_OMAP2PLUS to fix 
 mistranslations
   by moveconfig

>>>
>>> [..]
>>>
 diff --git a/configs/am335x_pdu001_defconfig 
 b/configs/am335x_pdu001_defconfig
 index cb75ec0..87ae88c 100644
 --- a/configs/am335x_pdu001_defconfig
 +++ b/configs/am335x_pdu001_defconfig
 @@ -9,13 +9,13 @@ CONFIG_SPL_SERIAL_SUPPORT=y
  CONFIG_SPL_LIBDISK_SUPPORT=y
  # CONFIG_SPL_NAND_SUPPORT is not set
  CONFIG_SPL_WATCHDOG_SUPPORT=y
 +CONFIG_SPL=y
  CONFIG_SPL_FAT_SUPPORT=y
  CONFIG_DEFAULT_DEVICE_TREE="am335x-pdu001"
  CONFIG_LOCALVERSION="-EETS-1.0.0"
  CONFIG_DISTRO_DEFAULTS=y
  CONFIG_BOOTDELAY=1
  # CONFIG_USE_BOOTCOMMAND is not set
 -CONFIG_SPL=y
  # CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is not set
  CONFIG_SPL_I2C_SUPPORT=y
  CONFIG_SPL_YMODEM_SUPPORT=y
 @@ -39,6 +39,7 @@ CONFIG_DM_GPIO=y
  CONFIG_DM_I2C=y
  CONFIG_MMC_OMAP_HS=y
  CONFIG_MMC_SDHCI=y
 +CONFIG_DRIVER_TI_CPSW=y
>>>
>>> Applying this patch series generates the following warning while
>>> creating the default configuration for board PDU001:
>>>
>>> warning: (BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS &&
>>> BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS && DRIVER_TI_CPSW &&
>>> AG7XXX && ALTERA_TSE && BCM_SF2_ETH && DWC_ETH_QOS && ETH_DESIGNWARE &&
>>> MVNETA && MVPP2 && MACB && PCH_GBE && SUN4I_EMAC && SUN8I_EMAC &&
>>> SH_ETHER && XILINX_AXIEMAC && XILINX_EMACLITE && ZYNQ_GEM && PIC32_ETH
>>> && RENESAS_RAVB) selects PHYLIB which has unmet direct dependencies (NET)
>>>
>>> This is due to the patch enabling CONFIG_DRIVER_TI_CPSW while leaving
>>> CONFIG_NET disabled.
>>> This board does not require/have network support for U-Boot so there is
>>> no need or benefit activating CONFIG_DRIVER_TI_CPSW here. Leaving the
>>> file configs/am355x_pdu001_defconfig without any modifications will make
>>> your patch work properly and result in a clean, warning and error free,
>>> build for the PDU001 board.
>>>
  CONFIG_PINCTRL=y
  CONFIG_PINCTRL_SINGLE=y
  CONFIG_DM_PMIC=y
>>>
>>
>> Oh bother, thanks for trying it. I think in fixing the opposite
>> problem from v1 I've missed a depends on NET. Is your board covered by
>> the Travis tests as I did push v2 and got a green build?
>>
>
> From what I can see it is not, but I'm not sure. Using buildman with
> am335x would include it. I have verified that.
>
>> Unfortunately my laptop decided to die overnight and I'm away from the
>> office for a couple of weeks so I'll have to pick it up when I'm back.
>>
>> Alex
>>
>
> regards, Felix

It is included, just found it, but looks like it doesn't fail because
of that issue:

https://travis-ci.org/akiernan/u-boot/jobs/360830565#L962

I clearly need to go and understand the Travis build a whole lot better.

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