[U-Boot] [PATCH v3] timer: Add High Precision Event Timers (HPET) support

2018-03-30 Thread Ivan Gorinov
Add HPET driver as an alternative timer for x86 (default is TSC).
HPET counter has constant frequency and does not need calibration.
This change also makes TSC timer driver optional on x86.
New HPET driver can also be selected as the early timer on x86.

HPET can be selected as the tick timer in the Device Tree "chosen" node:

/include/ "hpet.dtsi"

...

chosen {
tick-timer = "/hpet";
};

Signed-off-by: Ivan Gorinov 
---
 arch/Kconfig   |   2 +-
 arch/x86/Kconfig   |  21 +
 arch/x86/dts/hpet.dtsi |   7 ++
 drivers/timer/Kconfig  |   9 +++
 drivers/timer/Makefile |   1 +
 drivers/timer/hpet_timer.c | 190 +
 drivers/timer/tsc_timer.c  |   8 ++
 7 files changed, 237 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/dts/hpet.dtsi
 create mode 100644 drivers/timer/hpet_timer.c

diff --git a/arch/Kconfig b/arch/Kconfig
index e599e7a..37dabae 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -104,7 +104,7 @@ config X86
select DM_PCI
select PCI
select TIMER
-   select X86_TSC_TIMER
+   imply X86_TSC_TIMER
imply BLK
imply DM_ETH
imply DM_GPIO
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5c23b2c..bd1a644 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -119,6 +119,27 @@ source "arch/x86/cpu/tangier/Kconfig"
 
 # architecture-specific options below
 
+choice
+   prompt "Select which timer to use early on x86"
+   depends on X86
+   default X86_EARLY_TIMER_TSC
+
+config X86_EARLY_TIMER_TSC
+   bool "TSC"
+   depends on X86_TSC_TIMER
+   help
+ This selects x86 Time Stamp Counter (TSC) as the early timer.
+ See CONFIG_TIMER_EARLY for the early timer description.
+
+config X86_EARLY_TIMER_HPET
+   bool "HPET"
+   depends on HPET_TIMER
+   help
+ This selects High Precision Event Timers as the early timer.
+ Early HPET base address is specified by CONFIG_HPET_ADDRESS.
+
+endchoice
+
 config AHCI
default y
 
diff --git a/arch/x86/dts/hpet.dtsi b/arch/x86/dts/hpet.dtsi
new file mode 100644
index 000..a74f739
--- /dev/null
+++ b/arch/x86/dts/hpet.dtsi
@@ -0,0 +1,7 @@
+/ {
+   hpet: hpet@fed0 {
+   compatible = "hpet-x86";
+   u-boot,dm-pre-reloc;
+   reg = <0xfed0 0x1000>;
+   };
+};
diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index 2c96896..26743b7 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -65,6 +65,15 @@ config X86_TSC_TIMER
help
  Select this to enable Time-Stamp Counter (TSC) timer for x86.
 
+config HPET_TIMER
+   bool "High Precision Event Timers (HPET) support"
+   depends on TIMER
+   default y if X86
+   help
+ Select this to enable High Precision Event Timers (HPET) on x86.
+ HPET main counter increments at constant rate and does not need
+ calibration.
+
 config OMAP_TIMER
bool "Omap timer support"
depends on TIMER
diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
index a6e7832..557fecc 100644
--- a/drivers/timer/Makefile
+++ b/drivers/timer/Makefile
@@ -8,6 +8,7 @@ obj-y += timer-uclass.o
 obj-$(CONFIG_ALTERA_TIMER) += altera_timer.o
 obj-$(CONFIG_SANDBOX_TIMER)+= sandbox_timer.o
 obj-$(CONFIG_X86_TSC_TIMER)+= tsc_timer.o
+obj-$(CONFIG_HPET_TIMER)   += hpet_timer.o
 obj-$(CONFIG_OMAP_TIMER)   += omap-timer.o
 obj-$(CONFIG_AST_TIMER)+= ast_timer.o
 obj-$(CONFIG_STI_TIMER)+= sti-timer.o
diff --git a/drivers/timer/hpet_timer.c b/drivers/timer/hpet_timer.c
new file mode 100644
index 000..7287589
--- /dev/null
+++ b/drivers/timer/hpet_timer.c
@@ -0,0 +1,190 @@
+/*
+ * Copyright (c) 2017 Intel Corporation
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HPET_PERIOD_REG 0x004
+#define HPET_CONFIG_REG 0x010
+#define HPET_MAIN_COUNT_L 0x0f0
+#define HPET_MAIN_COUNT_H 0x0f4
+
+#define ENABLE_CNF 1
+
+#define HPET_MAX_PERIOD 1
+
+struct hpet_timer_priv {
+   void *regs;
+};
+
+/*
+ * Returns HPET clock frequency in HZ
+ * (rounding to the nearest integer),
+ * or 0 if HPET is not available.
+ */
+static inline u32 get_clock_frequency(void *regs)
+{
+   u64 d = 1000ull;
+   u32 period;
+
+   period = readl(regs + HPET_PERIOD_REG);
+   if (period == 0)
+   return 0;
+   if (period > HPET_MAX_PERIOD)
+   return 0;
+
+   d += period / 2;
+
+   return d / period;
+}
+
+/* Reset and start the main counter. */
+static void start_main_counter(void *regs)
+{
+   u32 config;
+
+   config = readl(regs + HPET_CONFIG_REG);
+   config &= ~ENABLE_CNF;
+   writel(config, regs + HPET_CONFIG_REG);
+   writel(0, regs + HPET_MAIN_COUNT_L);
+   writel(0, regs 

[U-Boot] [PATCH v3] timer: Add High Precision Event Timers (HPET) support

2018-03-30 Thread Ivan Gorinov
Add HPET driver as an alternative timer for x86 (default is TSC).
HPET counter has constant frequency and does not need calibration.
This change also makes TSC timer driver optional on x86.
New HPET driver can also be selected as the early timer on x86.

v3:
  Added early timer choice in x86-specific configuration.

v2:
  Moved duplicated code to static functions.

Ivan Gorinov (1):
  timer: Add High Precision Event Timers (HPET) support

 arch/Kconfig   |   2 +-
 arch/x86/Kconfig   |  21 +
 arch/x86/dts/hpet.dtsi |   7 ++
 drivers/timer/Kconfig  |   9 +++
 drivers/timer/Makefile |   1 +
 drivers/timer/hpet_timer.c | 190 +
 drivers/timer/tsc_timer.c  |   8 ++
 7 files changed, 237 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/dts/hpet.dtsi
 create mode 100644 drivers/timer/hpet_timer.c

-- 
2.7.4

___
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

2018-03-30 Thread Ivan Gorinov
On Fri, Mar 30, 2018 at 10:46:40PM +0300, Andy Shevchenko wrote:

> > +   writel(0, regs + HPET_MAIN_COUNT_L);
> > +   writel(0, regs + HPET_MAIN_COUNT_H);
> 
> Can we use writeq() here?

I don't see readq/writeq defined for x86, even x86_64.

> > +   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.

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


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

2018-03-30 Thread Ivan Gorinov
On Fri, Mar 30, 2018 at 10:42:57PM +0300, Andy Shevchenko wrote:
> On Fri, Mar 30, 2018 at 1:39 AM, Simon Glass  wrote:
> > On 29 March 2018 at 18:52, Andy Shevchenko
> >  wrote:
> 
> >> First question is how this will work in case of Broadwell and Ivybridge
> >> that have something to do with HPET in their CPU code, i.e.
> >>
> >> arch/x86/cpu/broadwell/pch.c
> >> arch/x86/cpu/ivybridge/lpc.c
> >>
> >> ?
> >>
> >> Look for
> >>
> >> clrsetbits_le32(RCB_REG(HPTC), 3, 1 << 7);
> 
> 
> > Perhaps that code can be removed in favour of this driver? I am happy
> > to test on these platforms if it helps.
> 
> That's my point.
> 

This code performs platform-specific enabling and may be required
for the generic HPET driver and OS kernel to work.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/2] ARC: HSDK: add platform-specific commands

2018-03-30 Thread Alexey Brodkin
Hi Tom,

On Mon, 2018-03-26 at 15:57 +0300, Eugeniy Paltsev wrote:
> This patch add support of hsdk platform-specific commands:
> 
> hsdk_clock set - set clock from axi_freq, cpu_freq and tun_freq
> environment variables/command line arguments
> 
> hsdk_clock get - save clock frequencies to axi_freq, cpu_freq
> and tun_freq environment variables
> 
> hsdk_clock print - show CPU, AXI, DDR and TUNNEL current
> clock frequencies.
> 
> hsdk_clock print_all - show all currently used clock frequencies.
> 
> hsdk_init - setup board HW in one of pre-defined configuration
> (hsdk_hs34 / hsdk_hs36 / hsdk_hs36_ccm / hsdk_hs38 /
> hsdk_hs38_ccm / hsdk_hs38x2 / hsdk_hs38x3 / hsdk_hs38x4)
> 
> hsdk_go - run baremetal application on hsdk configured
> by hsdk_init command.
> 
> This patch changes default behaviour of 'bootm' command:
> now we are able to set number of CPUs to be kicked by setting
> 'core_mask' environment variable before 'bootm' command run.
> 
> Signed-off-by: Eugeniy Paltsev 
> ---

I was about to send you a pull-request containing this one but
decided to give TravisCI a shot. And what I got was a warning
due to not yet supported "naked" attribute in GCC 6.x for ARC,
see https://travis-ci.org/abrodkin/u-boot/jobs/360259472

Ok I bumped ARC tools to the most recent arc-2017.09 based on
GCC 7.1 where "naked" attr for ARC is already supported.
But then I got another warning:
->8---
board/synopsys/hsdk/hsdk.c: In function "hsdk_core_init_f":
board/synopsys/hsdk/hsdk.c:345:1: error: stack usage computation not supported 
for this target [-Werror]
 }
 ^
->8---
see https://travis-ci.org/abrodkin/u-boot/jobs/360274604


That happens because GCC for ARC unconditionally tries to compute
stack requirements for all functions even if they are "naked".
And for "naked" computed value is negative thus the warning above.

So far I didn't manage to find a simple way to disable that warning.

And my question would be how to proceed with this [patch]?
Given we're seeing a problem in GCC it most probably won't be fixed
in U-Boot and we'll need to wait before new tools are available.

Or otherwise we'll start to see "failing" ARC jobs in TravisCI.

-Alexey
___
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

2018-03-30 Thread Andy Shevchenko
On Fri, Mar 30, 2018 at 1:29 AM, Ivan Gorinov  wrote:
> Adding HPET as an alternative timer for x86 (default is TSC).
> HPET counter has constant frequency and does not need calibration.
> This change also makes TSC timer driver optional on x86.
> If X86_TSC is disabled, early timer functions are provided by HPET.
>
> Signed-off-by: Ivan Gorinov 
> ---

Changelog?

>  arch/Kconfig   |   2 +-

> +config HPET_TIMER
> +   bool "High Precision Event Timers (HPET) support"
> +   depends on TIMER && X86

Does X86 makes any difference from building point of view?

> +   config = readl(regs + HPET_CONFIG_REG);
> +   config &= ~1;
> +   writel(config, regs + HPET_CONFIG_REG);

1  or BIT(0) is magic. Can be fixed in all places?

> +   writel(0, regs + HPET_MAIN_COUNT_L);
> +   writel(0, regs + HPET_MAIN_COUNT_H);

Can we use writeq() here?

> +   tl = readl(regs + HPET_MAIN_COUNT_L);
> +   th = readl(regs + HPET_MAIN_COUNT_H);

Ditto.

-- 
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] reset: socfpga: add reset driver for SoCFPGA platform

2018-03-30 Thread Marek Vasut
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() ?

> + 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() ?

[...]

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.

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


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

2018-03-30 Thread Andy Shevchenko
On Fri, Mar 30, 2018 at 1:39 AM, Simon Glass  wrote:
> On 29 March 2018 at 18:52, Andy Shevchenko
>  wrote:
>> On Wed, 2018-03-28 at 17:58 -0700, Ivan Gorinov wrote:

>> First question is how this will work in case of Broadwell and Ivybridge
>> that have something to do with HPET in their CPU code, i.e.
>>
>> arch/x86/cpu/broadwell/pch.c
>> arch/x86/cpu/ivybridge/lpc.c
>>
>> ?
>>
>> Look for
>>
>> clrsetbits_le32(RCB_REG(HPTC), 3, 1 << 7);


> Perhaps that code can be removed in favour of this driver? I am happy
> to test on these platforms if it helps.

That's my point.

-- 
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 26/36] rockchip: rk1108: remove rockchip timer for sys timer

2018-03-30 Thread Alexander Kochetkov
Hello, Kevel!

I can confirm, that rk3188 doesn’t have arch timer. I made test, see below.

By the way, could you tell what git head to use to apply your patch series?
I want to test other changes as well.

I failed to apply to this one head:

commit eef11acebaa48e241e9187c717dc92d3e175c119
Author: Tom Rini 
Date:   Mon Jan 29 20:12:33 2018 -0500

Prepare v2018.03-rc1

Signed-off-by: Tom Rini 

I took get_ticks() code from arch_timer.c into board file and tried to
execute it:

diff --git a/arch/arm/mach-rockchip/rk3188-board.c 
b/arch/arm/mach-rockchip/rk3188-board.c
index fc58aeb..b5d0984 100644
--- a/arch/arm/mach-rockchip/rk3188-board.c
+++ b/arch/arm/mach-rockchip/rk3188-board.c
@@ -25,9 +25,28 @@ __weak int rk_board_late_init(void)
return 0;
 }
 
+#define CONFIG_SYS_HZ_CLOCK2400
+
+ulong arch_tbl = 0;
+ulong arch_tbu = 0;
+ulong arch_timer_rate_hz = CONFIG_SYS_HZ_CLOCK / CONFIG_SYS_HZ;
+
+unsigned long long arch_get_ticks(void)
+{
+   ulong nowl, nowu;
+
+   asm volatile("mrrc p15, 0, %0, %1, c14" : "=r" (nowl), "=r" (nowu));
+
+   arch_tbl = nowl;
+   arch_tbu = nowu;
+
+   return (((unsigned long long)arch_tbu) << 32) | arch_tbl;
+}
+
 int board_late_init(void)
 {
struct rk3188_grf *grf;
+   ulong val0, val1;
 
setup_boot_mode();
grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
@@ -40,6 +59,12 @@ int board_late_init(void)
NOC_REMAP_MASK << NOC_REMAP_SHIFT);
}
 
+   val0 = arch_get_ticks();
+   udelay(100);
+   val1 = arch_get_ticks();
+
+   pr_err("val0 %lu; val1 %lu\n", val0, val1);
+
return rk_board_late_init();
 }

And I get undefined instruction error on rk3188 board:

undefined instruction
pc : [<9ff760d6>]  lr : [<9ff76129>]
reloc pc : [<600010d6>]lr : [<60001129>]
sp : 9df669d8  ip : 9df66918 fp : 0017
r10: 6003d648  r9 : 9df6cee8 r8 : 10080228
r7 : 9ffb0654  r6 : 9ffb05e4 r5 : 9ffb0658  r4 : 3ff75000
r3 : 10001000  r2 : 8000 r1 : 20008000  r0 : 20008000
Flags: nzcv  IRQs off  FIQs off  Mode SVC_32

Regards,
Alexander.

> 28 марта 2018 г., в 5:33, Kever Yang  написал(а):
> 
> Hi Alexander,
> 
> 
> On 03/28/2018 12:21 AM, Alexander Kochetkov wrote:
>> The question is: does rk3066 and rk3188 have arch timer? If no, than 
>> removing rk_timer
>> will break u-boot for these chips.
> 
> Thanks for your comment, I will double check about if this two chips
> have arch
> timer, I think it should be, but I don't have boards now.
> 
> Thanks,
> - Kever
>> 
>> And my comment was about global timer, not arch timer. And I failed to 
>> enable arch
>> timer for rk3188 in the kernel.
>> 
>> Alexander.
>> 
>>> 27 марта 2018 г., в 19:07, Alexander Kochetkov  
>>> написал(а):
>>> 
 27 марта 2018 г., в 12:29, Kever Yang  
 написал(а):
 
 We use ARM arch timer instead.
>>> Hi, Kever!
>>> 
>>> Just let you know, that arch timer rate on rk3066 and rk3188 depends on CPU 
>>> frequency.
>>> I’ve made patch[1] for fixing that in kernel.
>>> If u-boot do arm clock changes after timer initialization, timer can 
>>> provide inaccurate delays.
>>> 
>>> [1] 
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/clocksource/rockchip_timer.c?id=5e0a39d0f727b35c8b7ef56ba0724c8ceb006297
>>> 
>>> Alexander.
>> 
> 
> 

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


Re: [U-Boot] [PATCH v2 1/3] Move CONFIG_PHY_ADDR to Kconfig

2018-03-30 Thread Joe Hershberger
On Fri, Mar 30, 2018 at 2:49 AM, Bin Meng  wrote:
> Hi Joe,
>
> On Thu, Mar 29, 2018 at 2:17 AM, Joe Hershberger  
> wrote:
>> On Sun, Mar 25, 2018 at 8:40 PM, Bin Meng  wrote:
>>> Hi Joe,
>>>
>>> On Sat, Mar 24, 2018 at 1:11 AM, Joe Hershberger  
>>> wrote:
 On Thu, Mar 22, 2018 at 9:46 AM, Bin Meng  wrote:
> Hi,
>
> On Fri, Feb 2, 2018 at 9:53 PM, Stefan Mavrodiev  
> wrote:
>> CONFIG_PHY_ADDR is used for old-style configuration. This makes
>> impossible changing the PHY address, if multiple boards share a same
>> config header file (for example include/configs/sunxi-common.h).
>>
>> Moving this to Kconfig helps overcoming this issue. It's defined
>> as entry inside PHYLIB section.
>>
>> After the implemention, moveconfig was run. The issues are:
>> - edb9315a  - CONFIG_PHYLIB is not enabled. Entry is
>>   deleted.
>>
>> - ds414 - CONFIG_PHYLIB is in incompatible format:
>>   { 0x1, 0x0 }. This entry is also deleted.
>>
>> - devkit3250- The PHY_ADDR is in hex format (0x1F).
>>   Manually CONFIG_PHY_ADDR=31 is added in
>>   the defconfig.
>>
>> After the changes the suspicious defconfigs passes building.
>>
>> Signed-off-by: Stefan Mavrodiev 
>> Acked-by: Maxime Ripard 
>> ---
>>  Changes for v2:
>>- Replaced CONFIG_SUNXI_PHY_ADDR with a common one
>>  CONFIG_PHY_ADDR, using moveconfig.
>>
>>  README | 4 
>>  configs/devkit3250_defconfig   | 1 +
>>  configs/khadas-vim_defconfig   | 1 +
>>  configs/libretech-cc_defconfig | 1 +
>>  configs/p212_defconfig | 1 +
>>  drivers/net/phy/Kconfig| 7 +++
>>  include/configs/am335x_shc.h   | 1 -
>>  include/configs/baltos.h   | 1 -
>>  include/configs/devkit3250.h   | 1 -
>>  include/configs/ds414.h| 1 -
>>  include/configs/edb93xx.h  | 1 -
>>  include/configs/khadas-vim.h   | 2 --
>>  include/configs/libretech-cc.h | 2 --
>>  include/configs/p212.h | 2 --
>>  include/configs/pepper.h   | 1 -
>>  include/configs/sunxi-common.h | 2 --
>>  include/configs/work_92105.h   | 1 -
>>  include/configs/x600.h | 1 -
>>  scripts/config_whitelist.txt   | 1 -
>>  19 files changed, 11 insertions(+), 21 deletions(-)
>>
>
> [snip]
>
>> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
>> index 95b7534..c934aed 100644
>> --- a/drivers/net/phy/Kconfig
>> +++ b/drivers/net/phy/Kconfig
>> @@ -12,6 +12,13 @@ menuconfig PHYLIB
>>
>>  if PHYLIB
>>
>> +config PHY_ADDR
>> +   int "PHY address"
>> +   default 1 if ARCH_SUNXI
>> +   default 0
>> +   help
>> + The address of PHY on MII bus. Usually in range of 0 to 31.
>> +
>
> Sorry for jumping out so late, but this commit breaks Intel Galileo
> ethernet. Previously the board boots with the following log:
>
> Net: eth0: eth_designware#0, eth1: eth_designware#1
>
> With this commit it becomes:
>
> Net:   No ethernet found.
>
> The reason is that the board has two designware ethernet controllers,
> and PHY_ADDR has been set to zero for both. A simple fix is to:
>
> diff --git a/drivers/net/designware.c b/drivers/net/designware.c
> index 43670a7..1394119 100644
> --- a/drivers/net/designware.c
> +++ b/drivers/net/designware.c
> @@ -471,10 +471,6 @@ static int dw_phy_init(struct dw_eth_dev *priv, void 
> *dev)
> struct phy_device *phydev;
> int mask = 0x, ret;
>
> -#ifdef CONFIG_PHY_ADDR
> -   mask = 1 << CONFIG_PHY_ADDR;
> -#endif
> -
> phydev = phy_find_by_mask(priv->bus, mask, priv->interface);
> if (!phydev)
> return -ENODEV;
>
> But the real question is that: why do we introduce this PHY_ADDR
> Kconfig? It for sure won't work for multiple ethernet controllers.This
> should be eliminated IMHO. Comments?

 This should be able to come from the device tree, ultimately. Can you
 undefine the phy addr for the Galileo board?

> [snip]
>
>>>
>>> #undf the PHY_ADDR in Galileo board looks weird. This to me is a workaround.
>>
>> I didn't mean to add a #undef. I was just saying that if the "default
>> 0" in the Kconfig were instead "default 0 if !X86" or something (or
>> maybe if the board defconfig explicitly does unselects it).
>>
>
> This cannot be done as CONFIG_PHY_ADDR is an "int", not a "bool". We
> cannot do "# 

[U-Boot] [RFC PATCH] net: phy: Don't limit phy addresses by default

2018-03-30 Thread Joe Hershberger
Some boards expect to find more than one phy while other boards are old
and need to be limited to a specific phy address. Only limit the phy
address for boards that opt in.

Signed-off-by: Joe Hershberger 

---

 configs/am335x_baltos_defconfig| 1 +
 configs/am335x_shc_defconfig   | 1 +
 configs/am335x_shc_ict_defconfig   | 1 +
 configs/am335x_shc_netboot_defconfig   | 1 +
 configs/am335x_shc_prompt_defconfig| 1 +
 configs/am335x_shc_sdboot_defconfig| 1 +
 configs/am335x_shc_sdboot_prompt_defconfig | 1 +
 configs/devkit3250_defconfig   | 1 +
 configs/ds414_defconfig| 1 +
 configs/khadas-vim_defconfig   | 1 +
 configs/libretech-cc_defconfig | 1 +
 configs/p212_defconfig | 1 +
 configs/pepper_defconfig   | 1 +
 configs/work_92105_defconfig   | 1 +
 configs/x600_defconfig | 1 +
 drivers/net/phy/Kconfig| 8 
 16 files changed, 23 insertions(+)

diff --git a/configs/am335x_baltos_defconfig b/configs/am335x_baltos_defconfig
index ab7d96d..ed7d3a7 100644
--- a/configs/am335x_baltos_defconfig
+++ b/configs/am335x_baltos_defconfig
@@ -42,6 +42,7 @@ CONFIG_BOOTCOUNT_LIMIT=y
 CONFIG_SYS_OMAP24_I2C_SPEED=1000
 CONFIG_MMC_OMAP_HS=y
 CONFIG_NAND=y
+CONFIG_PHY_ADDR_ENABLE=y
 CONFIG_PHYLIB=y
 CONFIG_SYS_NS16550=y
 CONFIG_OMAP3_SPI=y
diff --git a/configs/am335x_shc_defconfig b/configs/am335x_shc_defconfig
index fb714da..ade16b9 100644
--- a/configs/am335x_shc_defconfig
+++ b/configs/am335x_shc_defconfig
@@ -35,6 +35,7 @@ CONFIG_CMD_MMC=y
 # CONFIG_SPL_ISO_PARTITION is not set
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_MMC_OMAP_HS=y
+CONFIG_PHY_ADDR_ENABLE=y
 CONFIG_PHYLIB=y
 CONFIG_SYS_NS16550=y
 CONFIG_OMAP3_SPI=y
diff --git a/configs/am335x_shc_ict_defconfig b/configs/am335x_shc_ict_defconfig
index 2568e3d..ac19a74 100644
--- a/configs/am335x_shc_ict_defconfig
+++ b/configs/am335x_shc_ict_defconfig
@@ -36,6 +36,7 @@ CONFIG_CMD_MMC=y
 # CONFIG_SPL_ISO_PARTITION is not set
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_MMC_OMAP_HS=y
+CONFIG_PHY_ADDR_ENABLE=y
 CONFIG_PHYLIB=y
 CONFIG_SYS_NS16550=y
 CONFIG_OMAP3_SPI=y
diff --git a/configs/am335x_shc_netboot_defconfig 
b/configs/am335x_shc_netboot_defconfig
index 16071fb..31f1847 100644
--- a/configs/am335x_shc_netboot_defconfig
+++ b/configs/am335x_shc_netboot_defconfig
@@ -37,6 +37,7 @@ CONFIG_CMD_MMC=y
 # CONFIG_SPL_ISO_PARTITION is not set
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_MMC_OMAP_HS=y
+CONFIG_PHY_ADDR_ENABLE=y
 CONFIG_PHYLIB=y
 CONFIG_SYS_NS16550=y
 CONFIG_OMAP3_SPI=y
diff --git a/configs/am335x_shc_prompt_defconfig 
b/configs/am335x_shc_prompt_defconfig
index bbad6dd..803304e 100644
--- a/configs/am335x_shc_prompt_defconfig
+++ b/configs/am335x_shc_prompt_defconfig
@@ -34,6 +34,7 @@ CONFIG_CMD_MMC=y
 # CONFIG_SPL_ISO_PARTITION is not set
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_MMC_OMAP_HS=y
+CONFIG_PHY_ADDR_ENABLE=y
 CONFIG_PHYLIB=y
 CONFIG_SYS_NS16550=y
 CONFIG_OMAP3_SPI=y
diff --git a/configs/am335x_shc_sdboot_defconfig 
b/configs/am335x_shc_sdboot_defconfig
index 82a61a3..2d4f4d1 100644
--- a/configs/am335x_shc_sdboot_defconfig
+++ b/configs/am335x_shc_sdboot_defconfig
@@ -36,6 +36,7 @@ CONFIG_CMD_MMC=y
 # CONFIG_SPL_ISO_PARTITION is not set
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_MMC_OMAP_HS=y
+CONFIG_PHY_ADDR_ENABLE=y
 CONFIG_PHYLIB=y
 CONFIG_SYS_NS16550=y
 CONFIG_OMAP3_SPI=y
diff --git a/configs/am335x_shc_sdboot_prompt_defconfig 
b/configs/am335x_shc_sdboot_prompt_defconfig
index 82a61a3..2d4f4d1 100644
--- a/configs/am335x_shc_sdboot_prompt_defconfig
+++ b/configs/am335x_shc_sdboot_prompt_defconfig
@@ -36,6 +36,7 @@ CONFIG_CMD_MMC=y
 # CONFIG_SPL_ISO_PARTITION is not set
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_MMC_OMAP_HS=y
+CONFIG_PHY_ADDR_ENABLE=y
 CONFIG_PHYLIB=y
 CONFIG_SYS_NS16550=y
 CONFIG_OMAP3_SPI=y
diff --git a/configs/devkit3250_defconfig b/configs/devkit3250_defconfig
index e1a9b49..b69808c 100644
--- a/configs/devkit3250_defconfig
+++ b/configs/devkit3250_defconfig
@@ -36,6 +36,7 @@ CONFIG_MTD_NOR_FLASH=y
 CONFIG_NAND=y
 CONFIG_SPL_NAND_SIMPLE=y
 CONFIG_PHYLIB=y
+CONFIG_PHY_ADDR_ENABLE=y
 CONFIG_PHY_ADDR=31
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/ds414_defconfig b/configs/ds414_defconfig
index 5d1d6ab..d68e64e 100644
--- a/configs/ds414_defconfig
+++ b/configs/ds414_defconfig
@@ -39,6 +39,7 @@ CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_PHY_ADDR_ENABLE=y
 CONFIG_PHY_GIGE=y
 CONFIG_MVNETA=y
 CONFIG_PCI=y
diff --git a/configs/khadas-vim_defconfig b/configs/khadas-vim_defconfig
index f4674ef..0bfb594 100644
--- a/configs/khadas-vim_defconfig
+++ b/configs/khadas-vim_defconfig
@@ -20,6 +20,7 @@ CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_MESON_GX=y
+CONFIG_PHY_ADDR_ENABLE=y
 CONFIG_PHY_ADDR=8
 CONFIG_PHY_MESON_GXL=y
 CONFIG_DM_ETH=y
diff --git 

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

2018-03-30 Thread Dinh Nguyen
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));
+   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));
+   return 0;
+}
+
+static int socfpga_reset_request(struct reset_ctl *reset_ctl)
+{
+   debug("%s(reset_ctl=%p) (dev=%p, id=%lu)\n", __func__,
+ reset_ctl, reset_ctl->dev, reset_ctl->id);
+
+   return 0;
+}
+
+static int socfpga_reset_free(struct reset_ctl *reset_ctl)
+{
+   debug("%s(reset_ctl=%p) (dev=%p, id=%lu)\n", __func__, reset_ctl,
+ reset_ctl->dev, reset_ctl->id);
+
+   return 0;
+}
+
+static const struct reset_ops socfpga_reset_ops = {
+   .request = socfpga_reset_request,
+   .free = socfpga_reset_free,
+   .rst_assert = socfpga_reset_assert,
+   .rst_deassert = socfpga_reset_deassert,
+};
+
+static int socfpga_reset_probe(struct udevice *dev)
+{
+   struct socfpga_reset_data *data = dev_get_priv(dev);
+   const void *blob = gd->fdt_blob;
+   int node = dev_of_offset(dev);
+   u32 modrst_offset;
+
+   data->membase = devfdt_get_addr_ptr(dev);
+
+   modrst_offset = fdtdec_get_int(blob, node, "altr,modrst-offset", 0x10);
+   data->membase += modrst_offset;
+
+   return 0;
+}
+
+static const struct udevice_id socfpga_reset_match[] = {
+   { .compatible = "altr,rst-mgr" },
+   { /* sentinel */ },
+};
+
+U_BOOT_DRIVER(socfpga_reset) = {
+   .name = "socfpga-reset",
+   .id = UCLASS_RESET,
+   .of_match = socfpga_reset_match,
+   .probe = socfpga_reset_probe,
+   .priv_auto_alloc_size = sizeof(struct socfpga_reset_data),
+   .ops = _reset_ops,
+};
-- 
2.7.4

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


Re: [U-Boot] [PATCH 15/18] warp7: Make load command an environment variable

2018-03-30 Thread Bryan O'Donoghue



On 30/03/18 16:05, Fabio Estevam wrote:


This will conflict with Pierre-Jean's recent patch series that makes
use of the generic load command:

https://lists.denx.de/pipermail/u-boot/2018-March/324065.html

and

https://lists.denx.de/pipermail/u-boot/2018-March/324066.html

Would his approach work for you?


If it does I'll redo my patchset on top of that and give a RB-tag on the 
series.


Thanks for point this out

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


Re: [U-Boot] [PATCH] ARM: mx6: ddr: Add write leveling correction code

2018-03-30 Thread Eric Nelson

Hi Marek,

Thanks for this update and the detailed notes.

On 03/29/2018 06:04 PM, Marek Vasut wrote:

When the DDR calibration is enabled, a situation may happen that it
will fail on a few select boards out of a whole production lot. In
particular, after the first write leveling stage, the MPWLDECTRLx
registers will contain a value 0x1nn , for nn usually being 0x7f or
slightly lower.

What this means is that the HW write leveling detected that the DQS
rising edge on one or more bundles arrives slightly _after_ CLK and
therefore when the DDR DRAM samples CLK on the DQS rising edge, the
CLK signal is already high (cfr. AN4467 rev2 Figure 7 on page 18).

The HW write leveling then ends up adding almost an entire cycle (thus
the 0x17f) to the DQS delay, which indeed aligns it, but also triggers
subsequent calibration failure in DQS gating due to this massive offset.

There are two observations here:
- If the MPWLDECTRLx value is corrected from 0x17f to 0x0 , then the
   DQS gating passes, the entire calibration passes as well and the
   DRAM is perfectly stable even under massive load.
- When using the NXP DRAM calibrator for iMX6/7, the value 0x17f or so
   in MPWLDECTRx register is not there, but it is replaced by 0x0 as one
   would expect.

Someone from NXP finally explains why, quoting [1]:

 "
 Having said all that, the DDR Stress Test does something that we
 do not advertise to the users. The Stress Test iself looks at the
 values of the MPWLDECTRL0/1 fields before reporting results, and
 if it sees any filed with a value greater than 200/256 delay
 (reported as half-cycle = 0x1 and ABS_OFFSET > 0x48), the DDR
 Stress test will reset the Write Leveling delay for this lane
 to 0x000 and not report it in the log.

 The reason that the DDR Stress test does this is because a delay
 of more than 78% a clock cycle means that the DQS edge is arriving
 within the JEDEC tolerence of 25% of the clock edge. In most cases,
 DQS is arriving < 5% tCK of the SDCLK edge in the early case, and
 it does not make sense to delay the DQS strobe almost a full clock
 cycle and add extra latency to each Write burst just to make the
 two edges align exactly. In this case, we are guilty of making a
 decision for the customer without telling them we are doing it so
 that we don't have to provide the above explanation to every customer.
 They don't need to know it.
 "

This patch adds the correction described above, that is if the MPWLDECTRx
value is over 0x148, the value is corrected back to 0x0.

[1] https://community.nxp.com/thread/456246

Signed-off-by: Marek Vasut 
Cc: Stefano Babic 
---
  arch/arm/mach-imx/mx6/ddr.c | 24 
  1 file changed, 24 insertions(+)

diff --git a/arch/arm/mach-imx/mx6/ddr.c b/arch/arm/mach-imx/mx6/ddr.c
index 43b77cfa41..6e5e40dd1a 100644
--- a/arch/arm/mach-imx/mx6/ddr.c
+++ b/arch/arm/mach-imx/mx6/ddr.c
@@ -85,6 +85,23 @@ static void modify_dg_result(u32 *reg_st0, u32 *reg_st1, u32 
*reg_ctrl)
writel(val_ctrl, reg_ctrl);
  }
  
+static void correct_mpwldectr_result(void *reg)

+{
+   /* Limit is 200/256 of CK, which is WL_HC_DELx | 0x48. */
+   const unsigned int limit = 0x148;
+   u32 val = readl(reg);
+   u32 old = val;
+


Nit: I think "val &= 0x" would be slightly easier to read
instead of the "<< 16":


+   if ((val & 0x17f) > limit)
+   val &= 0x << 16;
+
+   if (((val >> 16) & 0x17f) > limit)
+   val &= 0x;
+
+   if (old != val)
+   writel(val, reg);
+}
+
  int mmdc_do_write_level_calibration(struct mx6_ddr_sysinfo const *sysinfo)
  {
struct mmdc_p_regs *mmdc0 = (struct mmdc_p_regs *)MMDC_P0_BASE_ADDR;
@@ -176,6 +193,13 @@ int mmdc_do_write_level_calibration(struct mx6_ddr_sysinfo 
const *sysinfo)
errors |= 4;
}
  
+	correct_mpwldectr_result(>mpwldectrl0);

+   correct_mpwldectr_result(>mpwldectrl1);
+   if (sysinfo->dsize == 2) {
+   correct_mpwldectr_result(>mpwldectrl0);
+   correct_mpwldectr_result(>mpwldectrl1);
+   }
+
/*
 * User should issue MRS command to exit write leveling mode
 * through Load Mode Register command



Otherwise,

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


Re: [U-Boot] [PATCH] configs: warp7: Fix CAAM on boot with tip-of-tree

2018-03-30 Thread Bryan O'Donoghue



On 30/03/18 15:53, Fabio Estevam wrote:

Hi Bryan,

On Fri, Mar 30, 2018 at 7:55 AM, Bryan O'Donoghue
 wrote:

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).


For booting NXP based kernel you should use warp7_secure_defconfig
instead, which selects CONFIG_ARMV7_BOOT_SEC_DEFAULT=y.

Please see commit 375d199114c1 ("warp7: Add a secure mode target").

Also if using CONFIG_ARMV7_BOOT_SEC_DEFAULT=y is safe for booting both
mainline and NXP kernels then I think you are patch is OK and we can
get rid of warp7_secure_defconfig.

I don't have access to my warp7 board at the moment to give it a try.

Please confirm that this patch can successfully boot both mainline and
NXP kernels.

Thanks



Hi Fabio,

I can confirm I can boot the NXP 4.1, Linaro and a mainline 4.16-rcx 
kernels with CONFIG_ARMV7_BOOT_SEC_DEFAULT=y


I'll reconfirm to be sure and redo this patch 
CONFIG_ARMV7_BOOT_SEC_DEFAULT=y and subtract warp7_secure_defconfig

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


Re: [U-Boot] [PATCH] ARM: mx6: ddr: Add write leveling correction code

2018-03-30 Thread Fabio Estevam
Hi Marek,

On Thu, Mar 29, 2018 at 10:04 PM, Marek Vasut  wrote:
> When the DDR calibration is enabled, a situation may happen that it
> will fail on a few select boards out of a whole production lot. In
> particular, after the first write leveling stage, the MPWLDECTRLx
> registers will contain a value 0x1nn , for nn usually being 0x7f or
> slightly lower.
>
> What this means is that the HW write leveling detected that the DQS
> rising edge on one or more bundles arrives slightly _after_ CLK and
> therefore when the DDR DRAM samples CLK on the DQS rising edge, the
> CLK signal is already high (cfr. AN4467 rev2 Figure 7 on page 18).
>
> The HW write leveling then ends up adding almost an entire cycle (thus
> the 0x17f) to the DQS delay, which indeed aligns it, but also triggers
> subsequent calibration failure in DQS gating due to this massive offset.
>
> There are two observations here:
> - If the MPWLDECTRLx value is corrected from 0x17f to 0x0 , then the
>   DQS gating passes, the entire calibration passes as well and the
>   DRAM is perfectly stable even under massive load.
> - When using the NXP DRAM calibrator for iMX6/7, the value 0x17f or so
>   in MPWLDECTRx register is not there, but it is replaced by 0x0 as one
>   would expect.
>
> Someone from NXP finally explains why, quoting [1]:
>
> "
> Having said all that, the DDR Stress Test does something that we
> do not advertise to the users. The Stress Test iself looks at the
> values of the MPWLDECTRL0/1 fields before reporting results, and
> if it sees any filed with a value greater than 200/256 delay
> (reported as half-cycle = 0x1 and ABS_OFFSET > 0x48), the DDR
> Stress test will reset the Write Leveling delay for this lane
> to 0x000 and not report it in the log.
>
> The reason that the DDR Stress test does this is because a delay
> of more than 78% a clock cycle means that the DQS edge is arriving
> within the JEDEC tolerence of 25% of the clock edge. In most cases,
> DQS is arriving < 5% tCK of the SDCLK edge in the early case, and
> it does not make sense to delay the DQS strobe almost a full clock
> cycle and add extra latency to each Write burst just to make the
> two edges align exactly. In this case, we are guilty of making a
> decision for the customer without telling them we are doing it so
> that we don't have to provide the above explanation to every customer.
> They don't need to know it.
> "
>
> This patch adds the correction described above, that is if the MPWLDECTRx
> value is over 0x148, the value is corrected back to 0x0.
>
> [1] https://community.nxp.com/thread/456246
>
> Signed-off-by: Marek Vasut 
> Cc: Stefano Babic 

Thanks for the fix and for the detailed commit log!

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


Re: [U-Boot] [PATCH 15/18] warp7: Make load command an environment variable

2018-03-30 Thread Fabio Estevam
Hi Bryan,

On Fri, Mar 30, 2018 at 11:18 AM, Bryan O'Donoghue
 wrote:
> This patch replaces the current "fatload" command with an environment
> variable. Making the load command into an environment variable means we can
> change filesystem type in boot.scr and reuse existing commands within that
> boot script.
>
> Signed-off-by: Bryan O'Donoghue 
> ---
>  include/configs/warp7.h | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/include/configs/warp7.h b/include/configs/warp7.h
> index c957b2d..712850e 100644
> --- a/include/configs/warp7.h
> +++ b/include/configs/warp7.h
> @@ -51,12 +51,13 @@
> "mmcargs=setenv bootargs console=${console},${baudrate} " \
> "root=PARTUUID=${uuid} rootwait rw\0" \
> "warp7_auth_or_fail=hab_auth_img_or_fail ${hab_ivt_addr} ${filesize} 
> 0;\0" \
> +   "loadcmd=fatload\0" \
> "loadbootscript=" \
> -   "fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
> +   "${loadcmd} mmc ${mmcdev}:${mmcpart} ${loadaddr} 
> ${script};\0" \
> "bootscript=echo Running bootscript from mmc ...; " \
> "source\0" \
> -   "loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
> -   "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
> +   "loadimage=${loadcmd} mmc ${mmcdev}:${mmcpart} ${loadaddr} 
> ${image}\0" \
> +   "loadfdt=${loadcmd} mmc ${mmcdev}:${mmcpart} ${fdt_addr} 
> ${fdt_file}\0" \
> "mmcboot=echo Booting from mmc ...; " \

This will conflict with Pierre-Jean's recent patch series that makes
use of the generic load command:

https://lists.denx.de/pipermail/u-boot/2018-March/324065.html

and

https://lists.denx.de/pipermail/u-boot/2018-March/324066.html

Would his approach work for you?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 11/18] warp7: Add Kconfig WARP7_ROOT_PART

2018-03-30 Thread Fabio Estevam
Hi Bryan,

On Fri, Mar 30, 2018 at 11:18 AM, Bryan O'Donoghue
 wrote:
> Adding CONFIG_WARP7_ROOT_PART allows a defconfig to specify which partition
> is use as the root partition on WaRP7, this is a desirable change in order
> to support a different partitioning schemes. The default is the current
> partition #1.

I think you meant "partition #2" here instead.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] configs: warp7: Fix CAAM on boot with tip-of-tree

2018-03-30 Thread Fabio Estevam
Hi Bryan,

On Fri, Mar 30, 2018 at 7:55 AM, Bryan O'Donoghue
 wrote:
> 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).

For booting NXP based kernel you should use warp7_secure_defconfig
instead, which selects CONFIG_ARMV7_BOOT_SEC_DEFAULT=y.

Please see commit 375d199114c1 ("warp7: Add a secure mode target").

Also if using CONFIG_ARMV7_BOOT_SEC_DEFAULT=y is safe for booting both
mainline and NXP kernels then I think you are patch is OK and we can
get rid of warp7_secure_defconfig.

I don't have access to my warp7 board at the moment to give it a try.

Please confirm that this patch can successfully boot both mainline and
NXP kernels.

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


[U-Boot] [PATCH 10/18] warp7: Make CONFIG_SYS_FDT_ADDR a define

2018-03-30 Thread Bryan O'Donoghue
In order to sign images with the IMX code-signing-tool (CST) we need to
know the load address of a given image. The best way to derive this load
address is to make it into a define - so that u-boot.cfg contains the
address - which we can then parse when generating the IMX CST headers.

Signed-off-by: Bryan O'Donoghue 
Reviewed-by: Ryan Harkin 
---
 board/warp7/Kconfig | 6 ++
 include/configs/warp7.h | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/board/warp7/Kconfig b/board/warp7/Kconfig
index 61c33fb..00df19d 100644
--- a/board/warp7/Kconfig
+++ b/board/warp7/Kconfig
@@ -6,4 +6,10 @@ config SYS_BOARD
 config SYS_CONFIG_NAME
default "warp7"
 
+config SYS_FDT_ADDR
+   hex "FDT load address"
+   default 0x8300
+   help
+ The address the FDT file should be loaded to.
+
 endif
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 9ae2ca4..a92e675 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -39,7 +39,7 @@
"fdt_high=0x\0" \
"initrd_high=0x\0" \
"fdt_file=imx7s-warp.dtb\0" \
-   "fdt_addr=0x8300\0" \
+   "fdt_addr=" __stringify(CONFIG_SYS_FDT_ADDR)"\0" \
"optee_addr=" __stringify(CONFIG_OPTEE_LOAD_ADDR)"\0" \
"boot_fdt=try\0" \
"ip_dyn=yes\0" \
-- 
2.7.4

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


Re: [U-Boot] [PATCH 3/4] clk: add Amlogic meson clock driver

2018-03-30 Thread Andreas Färber
Hi guys,

Am 30.03.2018 um 10:41 schrieb Simon Glass:
> On 30 March 2018 at 15:53, Neil Armstrong  wrote:
>> On 30/03/2018 00:41, Simon Glass wrote:
>>> On 29 March 2018 at 16:42, Neil Armstrong  wrote:
 On 03/12/2017 10:17, Beniamino Galvani wrote:
> +
> + gate = [clk->id];
> +
> + if (gate->reg == 0)
> + return -ENOENT;

 Same here -ENOSYS
>>
>> Here thsi means it's not a gate.
> 
> Yes, but the driver still supports the operation. The problem is that
> its inputs are invalid. So use -ENOENT to mean that.

Isn't that the definition of -EINVAL?

Cheers,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 18/18] warp7: Add support for automated secure boot.scr verification

2018-03-30 Thread Bryan O'Donoghue
This patch adds support for verifying a signed boot.scr. With this in place
it's possible for run-time Linux to update boot.scr to set different
variables such as switching between different boot partitions, pointing to
different kernels etc and for u-boot to verify these changes via the HAB
prior to executing the commands contained in boot.scr.

Signed-off-by: Bryan O'Donoghue 
---
 include/configs/warp7.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index adf25ac..2a2d431 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -54,6 +54,14 @@
"ivt_offset=" __stringify(BOOTROM_IVT_HDR_OFFSET)"\0"\
"warp7_auth_or_fail=hab_auth_img_or_fail ${hab_ivt_addr} ${filesize} 
0;\0" \
"loadcmd=fatload\0" \
+   "do_bootscript_hab=" \
+   "if test ${hab_enabled} -eq 1; then " \
+   "setexpr hab_ivt_addr ${loadaddr} - ${ivt_offset}; " \
+   "setenv script ${script_signed}; " \
+   "${loadcmd} mmc ${mmcdev}:${mmcpart} ${hab_ivt_addr} 
${script}; " \
+   "run warp7_auth_or_fail; " \
+   "run bootscript; "\
+   "fi;\0" \
"loadbootscript=" \
"${loadcmd} mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
"bootscript=echo Running bootscript from mmc ...; " \
@@ -80,6 +88,7 @@
 #define CONFIG_BOOTCOMMAND \
   "mmc dev ${mmcdev};" \
   "mmc dev ${mmcdev}; if mmc rescan; then " \
+  "run do_bootscript_hab;" \
   "if run loadbootscript; then " \
   "run bootscript; " \
   "else " \
-- 
2.7.4

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


[U-Boot] [PATCH 07/18] warp7: Specify CONFIG_OPTEE_LOAD_ADDR

2018-03-30 Thread Bryan O'Donoghue
In order to sign images with the IMX code-signing-tool (CST) we need to
know the load address of a given image. The best way to derive this load
address is to make it into a define - so that u-boot.cfg contains the
address - which we can then parse when generating the IMX CST headers.

This patch makes the OPTEE_LOAD_ADDR available via u-boot.cfg for further
parsing by external tools.

Signed-off-by: Bryan O'Donoghue 
Reviewed-by: Ryan Harkin 
---
 configs/warp7_secure_defconfig | 1 +
 include/configs/warp7.h| 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/warp7_secure_defconfig b/configs/warp7_secure_defconfig
index 538f9ab..81b297f 100644
--- a/configs/warp7_secure_defconfig
+++ b/configs/warp7_secure_defconfig
@@ -41,3 +41,4 @@ CONFIG_USB_ETH_CDC=y
 CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
 CONFIG_OF_LIBFDT=y
 CONFIG_OPTEE=y
+CONFIG_OPTEE_LOAD_ADDR=0x8400
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index c6ab29a..9ae2ca4 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -40,6 +40,7 @@
"initrd_high=0x\0" \
"fdt_file=imx7s-warp.dtb\0" \
"fdt_addr=0x8300\0" \
+   "optee_addr=" __stringify(CONFIG_OPTEE_LOAD_ADDR)"\0" \
"boot_fdt=try\0" \
"ip_dyn=yes\0" \
"mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \
-- 
2.7.4

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


[U-Boot] [PATCH 05/18] warp7: Allocate specific region of memory to OPTEE

2018-03-30 Thread Bryan O'Donoghue
Subtracts CONFIG_OPTEE_TZDRAM_SIZE from the available DRAM size.

On WaRP7 we simply define the OPTEE region as from the maximum DRAM address
minus CONFIG_OPTEE_TZDRAM_SIZE bytes.

Note the OPTEE boot process will itself subtract the DRAM region it lives
in from the memory map passed to Linux.

Signed-off-by: Bryan O'Donoghue 
---
 board/warp7/warp7.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index 0d3d324..56f0cdd 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -58,6 +58,11 @@ int dram_init(void)
 {
gd->ram_size = PHYS_SDRAM_SIZE;
 
+   /* Subtract the defined OPTEE runtime firmware length */
+#ifdef CONFIG_OPTEE_TZDRAM_SIZE
+   gd->ram_size -= CONFIG_OPTEE_TZDRAM_SIZE;
+#endif
+
return 0;
 }
 
-- 
2.7.4

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


[U-Boot] [PATCH 12/18] warp7: select uuid partition based on rootpart

2018-03-30 Thread Bryan O'Donoghue
Assigning the UUID discovery path to a tweakable environment variable means
that later steps in the boot process - particularly a boot script can
change the target root partition of a particular Linux boot.

Retargeting the rootfs is an important feature when doing ping/pong
upgrades allowing a boot script to select ping or pong as necessary without
reprogramming the bootloader.

Signed-off-by: Bryan O'Donoghue 
---
 include/configs/warp7.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index a92e675..f2ee09b 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -45,7 +45,8 @@
"ip_dyn=yes\0" \
"mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \
"mmcpart=" __stringify(CONFIG_SYS_MMC_IMG_LOAD_PART) "\0" \
-   "finduuid=part uuid mmc 0:2 uuid\0" \
+   "rootpart=" __stringify(CONFIG_WARP7_ROOT_PART) "\0" \
+   "finduuid=part uuid mmc 0:${rootpart} uuid\0" \
"mmcargs=setenv bootargs console=${console},${baudrate} " \
"root=PARTUUID=${uuid} rootwait rw\0" \
"loadbootscript=" \
-- 
2.7.4

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


[U-Boot] [PATCH 11/18] warp7: Add Kconfig WARP7_ROOT_PART

2018-03-30 Thread Bryan O'Donoghue
Adding CONFIG_WARP7_ROOT_PART allows a defconfig to specify which partition
is use as the root partition on WaRP7, this is a desirable change in order
to support a different partitioning schemes. The default is the current
partition #1.

Signed-off-by: Bryan O'Donoghue 
---
 board/warp7/Kconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/board/warp7/Kconfig b/board/warp7/Kconfig
index 00df19d..c089bca 100644
--- a/board/warp7/Kconfig
+++ b/board/warp7/Kconfig
@@ -6,6 +6,14 @@ config SYS_BOARD
 config SYS_CONFIG_NAME
default "warp7"
 
+config WARP7_ROOT_PART
+   int "Partition number to use for root filesystem"
+   default 2
+   help
+ The partition number to use for root filesystem this is the
+ partition that is typically specified with root=/dev/sdaX or
+ which gets converted into a root=PARTUUID=some_uuid.
+
 config SYS_FDT_ADDR
hex "FDT load address"
default 0x8300
-- 
2.7.4

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


[U-Boot] [PATCH 03/18] warp7: hab: Set environment variable indicating HAB enable

2018-03-30 Thread Bryan O'Donoghue
This patch adds an environment variable called "hab_enabled" which gets set
to a boolean status indicating whether HAB is enabled or not.

Subsequent patches can use this environment variable to determine if its
necessary to run a given binary through the hab_auth_img console command.

Signed-off-by: Bryan O'Donoghue 
---
 board/warp7/warp7.c | 8 
 include/configs/warp7.h | 3 +++
 2 files changed, 11 insertions(+)

diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index 327f656..0d3d324 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -203,6 +204,13 @@ int board_late_init(void)
 */
clrsetbits_le16(>wcr, 0, 0x10);
 
+#ifdef CONFIG_SECURE_BOOT
+   /* Determine HAB state */
+   env_set_ulong(HAB_ENABLED_ENVNAME, imx_hab_is_enabled());
+#else
+   env_set_ulong(HAB_ENABLED_ENVNAME, 0);
+#endif
+
 #ifdef CONFIG_SERIAL_TAG
/* Set serial# standard environment variable based on OTP settings */
get_board_serial();
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 0c3b605..c6ab29a 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -139,4 +139,7 @@
 
 #define CONFIG_USBNET_DEV_ADDR "de:ad:be:af:00:01"
 
+/* Environment variable name to represent HAB enable state */
+#define HAB_ENABLED_ENVNAME"hab_enabled"
+
 #endif
-- 
2.7.4

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


[U-Boot] [PATCH 14/18] warp7: add warp7_auth_or_fail

2018-03-30 Thread Bryan O'Donoghue
Doing secure boot on the WaRP7 using a common image format and the same
variable to represent the base address for each call means we can reduce
down the command to a single environment command.

This patch adds warp7_auth_or_fail as a wrapper around
"hab_auth_img_or_fail ${hab_ivt_addr} ${filesize} 0".

Signed-off-by: Bryan O'Donoghue 
---
 include/configs/warp7.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 53fbcb2..c957b2d 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -50,6 +50,7 @@
"finduuid=part uuid mmc 0:${rootpart} uuid\0" \
"mmcargs=setenv bootargs console=${console},${baudrate} " \
"root=PARTUUID=${uuid} rootwait rw\0" \
+   "warp7_auth_or_fail=hab_auth_img_or_fail ${hab_ivt_addr} ${filesize} 
0;\0" \
"loadbootscript=" \
"fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
"bootscript=echo Running bootscript from mmc ...; " \
-- 
2.7.4

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


[U-Boot] [PATCH 17/18] warp7_secure: defconfig: Enable CMD_SETEXPR

2018-03-30 Thread Bryan O'Donoghue
setexpr allows us to do arithmetic for env variables - something that is
both useful and required when doing HAB authentication without hard-coding
HAB load addresses.

Enable setexpr in the secure defconfig - it's not required for the unsecure
version.

Signed-off-by: Bryan O'Donoghue 
---
 configs/warp7_secure_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/warp7_secure_defconfig b/configs/warp7_secure_defconfig
index 0d46aa7..3342f54 100644
--- a/configs/warp7_secure_defconfig
+++ b/configs/warp7_secure_defconfig
@@ -21,7 +21,7 @@ CONFIG_CMD_MMC=y
 CONFIG_CMD_PART=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
-# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_SETEXPR=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT2=y
 CONFIG_CMD_EXT4=y
-- 
2.7.4

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


[U-Boot] [PATCH 13/18] warp7: Define the name of a signed boot-script file

2018-03-30 Thread Bryan O'Donoghue
We need to know the name of a signed boot-script, its better to have a
separate variable for this then to simply append some fixed string to an
existing image name.

Signed-off-by: Bryan O'Donoghue 
---
 include/configs/warp7.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index f2ee09b..53fbcb2 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -33,6 +33,7 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
CONFIG_DFU_ENV_SETTINGS \
"script=boot.scr\0" \
+   "script_signed=boot.scr.imx-signed\0" \
"image=zImage\0" \
"console=ttymxc0\0" \
"ethact=usb_ether\0" \
-- 
2.7.4

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


[U-Boot] [PATCH 16/18] warp7: hab: Set environment variable indicating IVT offset

2018-03-30 Thread Bryan O'Donoghue
This patch introduces the environment variable ivt_offset. When we define a
load address for Linux or DTB or any file the IVT associated with that file
is prepended. We extract the actual load addresses from u-boot.cfg and feed
these values into the code-signing process - hence we want u-boot to have
the real load addresses exported in uboot.cfg.

ivt_offset represents the addition or subtraction from the load address
that must happen to find an IVT header.

Signed-off-by: Bryan O'Donoghue 
---
 include/configs/warp7.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 712850e..adf25ac 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -10,6 +10,7 @@
 #define __WARP7_CONFIG_H
 
 #include "mx7_common.h"
+#include 
 
 #define PHYS_SDRAM_SIZESZ_512M
 
@@ -50,6 +51,7 @@
"finduuid=part uuid mmc 0:${rootpart} uuid\0" \
"mmcargs=setenv bootargs console=${console},${baudrate} " \
"root=PARTUUID=${uuid} rootwait rw\0" \
+   "ivt_offset=" __stringify(BOOTROM_IVT_HDR_OFFSET)"\0"\
"warp7_auth_or_fail=hab_auth_img_or_fail ${hab_ivt_addr} ${filesize} 
0;\0" \
"loadcmd=fatload\0" \
"loadbootscript=" \
-- 
2.7.4

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


[U-Boot] [PATCH 08/18] warp7: defconfig: Enable CONFIG_SECURE_BOOT

2018-03-30 Thread Bryan O'Donoghue
Various function associated with booting the WaRP7 in High Assurance Boot
(HAB) mode are enabled by switching on CONFIG_SECURE_BOOT.

This patch enables CONFIG_SECURE_BOOT for the WaRP7 defconfig.

Signed-off-by: Bryan O'Donoghue 
---
 configs/warp7_secure_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/warp7_secure_defconfig b/configs/warp7_secure_defconfig
index 81b297f..d1d2495 100644
--- a/configs/warp7_secure_defconfig
+++ b/configs/warp7_secure_defconfig
@@ -1,5 +1,6 @@
 CONFIG_ARM=y
 CONFIG_ARCH_MX7=y
+CONFIG_SECURE_BOOT=y
 CONFIG_SYS_TEXT_BASE=0x8780
 CONFIG_TARGET_WARP7=y
 CONFIG_ARMV7_BOOT_SEC_DEFAULT=y
-- 
2.7.4

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


Re: [U-Boot] [PATCH 00/18] warp7: Enable automated OPTEE/HAB boot flow

2018-03-30 Thread Bryan O'Donoghue


+ Breno

Forget to add you to the CC Breno bod < sleep
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 04/18] warp7: defconfig: Enable OPTEE for WaRP7

2018-03-30 Thread Bryan O'Donoghue
Requires setting CONFIG_OPTEE=y and setting an OPTEE TrustZone DRAM base in
include/configs/warp7.h.

Signed-off-by: Bryan O'Donoghue 
---
 configs/warp7_secure_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/warp7_secure_defconfig b/configs/warp7_secure_defconfig
index 7310855..538f9ab 100644
--- a/configs/warp7_secure_defconfig
+++ b/configs/warp7_secure_defconfig
@@ -40,3 +40,4 @@ CONFIG_USB_ETHER=y
 CONFIG_USB_ETH_CDC=y
 CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
 CONFIG_OF_LIBFDT=y
+CONFIG_OPTEE=y
-- 
2.7.4

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


[U-Boot] [PATCH 15/18] warp7: Make load command an environment variable

2018-03-30 Thread Bryan O'Donoghue
This patch replaces the current "fatload" command with an environment
variable. Making the load command into an environment variable means we can
change filesystem type in boot.scr and reuse existing commands within that
boot script.

Signed-off-by: Bryan O'Donoghue 
---
 include/configs/warp7.h | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index c957b2d..712850e 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -51,12 +51,13 @@
"mmcargs=setenv bootargs console=${console},${baudrate} " \
"root=PARTUUID=${uuid} rootwait rw\0" \
"warp7_auth_or_fail=hab_auth_img_or_fail ${hab_ivt_addr} ${filesize} 
0;\0" \
+   "loadcmd=fatload\0" \
"loadbootscript=" \
-   "fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
+   "${loadcmd} mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
"bootscript=echo Running bootscript from mmc ...; " \
"source\0" \
-   "loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
-   "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
+   "loadimage=${loadcmd} mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
+   "loadfdt=${loadcmd} mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" 
\
"mmcboot=echo Booting from mmc ...; " \
"run finduuid; " \
"run mmcargs; " \
-- 
2.7.4

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


[U-Boot] [PATCH 06/18] warp7: Print out the OPTEE DRAM region

2018-03-30 Thread Bryan O'Donoghue
Right now a region of 0x30 bytes is allocated at the end of DRAM for
the purposes of loading an OPTEE firmware inside of it. This patch adds the
printout of the relevant address ranges.

Signed-off-by: Bryan O'Donoghue 
---
 board/warp7/warp7.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index 56f0cdd..da52b18 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -181,7 +181,17 @@ int checkboard(void)
else
mode = "non-secure";
 
+#ifdef CONFIG_OPTEE_TZDRAM_SIZE
+   unsigned long optee_start, optee_end;
+
+   optee_end = PHYS_SDRAM + PHYS_SDRAM_SIZE;
+   optee_start = optee_end - CONFIG_OPTEE_TZDRAM_SIZE;
+
+   printf("Board: WARP7 in %s mode OPTEE DRAM 0x%08lx-0x%08lx\n",
+  mode, optee_start, optee_end);
+#else
printf("Board: WARP7 in %s mode\n", mode);
+#endif
 
return 0;
 }
-- 
2.7.4

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


[U-Boot] [PATCH 02/18] warp7: hab: Add a CSF location definition

2018-03-30 Thread Bryan O'Donoghue
In order to correctly produce an image with a IVT/DCD header we need to
define a CSF in imximage.cfg. We just use the mx7 default here.

All we have to do with this option switched on is "make u-boot.imx" and we
then will get

- u-boot.imx
- u-boot.imx.log

The log file is really important because it gives the addresses for the HAB
that we will require to sign the u-boot image using the CST. Since the
addresses can change this logfile is a critical output.

Signed-off-by: Bryan O'Donoghue 
---
 board/warp7/imximage.cfg | 4 
 1 file changed, 4 insertions(+)

diff --git a/board/warp7/imximage.cfg b/board/warp7/imximage.cfg
index 5b42793..51a5bff 100644
--- a/board/warp7/imximage.cfg
+++ b/board/warp7/imximage.cfg
@@ -13,6 +13,10 @@
 #include 
 
 IMAGE_VERSION  2
+#ifdef CONFIG_SECURE_BOOT
+CSF CONFIG_CSF_SIZE
+#endif
+
 BOOT_FROM  sd
 
 /*
-- 
2.7.4

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


[U-Boot] [PATCH 09/18] warp7: defconfig: Enable CONFIG_BOOTM_TEE

2018-03-30 Thread Bryan O'Donoghue
This patch enables CONFIG_BOOTM_TEE. Once enabled its possible to
chain-load Linux through OPTEE.

Loading kernel to 0x8080
=> run loadimage

Load FDT to 0x8300
=> run loadfdt

Load OPTEE to 0x8400
=> fatload mmc 0:5 0x8400 /lib/firmware/uTee.optee

Then chain-load to the kernel via OPTEE

=> bootm 0x8400 - 0x8300

   Image Name:
   Image Type:   ARM Trusted Execution Environment Kernel Image (uncompressed)
   Data Size:249844 Bytes = 244 KiB
   Load Address: 9de4
   Entry Point:  9e00
   Verifying Checksum ... OK
   Loading Kernel Image ... OK

Signed-off-by: Bryan O'Donoghue 
---
 configs/warp7_secure_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/warp7_secure_defconfig b/configs/warp7_secure_defconfig
index d1d2495..0d46aa7 100644
--- a/configs/warp7_secure_defconfig
+++ b/configs/warp7_secure_defconfig
@@ -43,3 +43,4 @@ CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
 CONFIG_OF_LIBFDT=y
 CONFIG_OPTEE=y
 CONFIG_OPTEE_LOAD_ADDR=0x8400
+CONFIG_BOOTM_OPTEE=y
-- 
2.7.4

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


[U-Boot] [PATCH 00/18] warp7: Enable automated OPTEE/HAB boot flow

2018-03-30 Thread Bryan O'Donoghue
This series enables an automated HAB verified secure boot which chain-loads
via OPTEE see `git show 5cf3251..c225e7c` for details.

This set depends on three in-flight patchsets

1. [PATCH v3 0/3] NXP WaARP7 set serial# from OTP fuses for USB iSerial
   Already has a Reviewed-by from Fabio

2. [PATCH v3 0/2] imx: hab: Add helper functions for scripted HAB auth
   Has a Reviewed-by: from Breno

3. [PATCH] configs: warp7: Fix CAAM on boot with tip-of-tree

I'm trying not to make this cover email too long. So - once this set is
applied it is possible to boot from the BootROM using HAB to verify

- u-boot
- boot.scr
- Kernel
- DTB

Chainload via OPTEE and boot up to Linux. If there is a HAB failure at any
stage of the process we force-drop down to the USB HID failover mode, from
which we can send up a recovery image to unblock.

I've run the WaRP7 default u-boot and this new version on NXP's reference
yocto image and verified that that yocto image boots with both versions of
the WaRP7 -> warp7_defconfig and warp7_secure_defconfig.

http://freescale.github.io/#download -> BoardsWaRPboard community - WaRP -
Wearable Reference PlatformFSL Community BSP 2.3fsl-image-multimediawayland

In addition the modifications targeting warp7_secure_defconfig mean it is
possible to chain-load via OPTEE using scripted HAB to verify images prior
to exiting the u-boot domain.

Here is an example of the scripting we are doing which shows further reuse
of shell functions introduced in previous patches.

 Example secure-boot boot.scr.imx-signed 

# This section is responsbile for loading a signed Linux kernel
setenv image_signed zImage.imx-signed
if test ${hab_enabled} -eq 1; then
setexpr hab_ivt_addr ${loadaddr} - ${ivt_offset}
${loadcmd} mmc ${mmcdev}:${mmcpart} ${hab_ivt_addr} ${image_signed}
run warp7_auth_or_fail
else
run loadimage;
fi

# This section is responsbile for loading a signed FDT image
setenv fdt_file_signed imx7s-warp.dtb.imx-signed
if test ${hab_enabled} -eq 1; then
setexpr hab_ivt_addr ${fdt_addr} - ${ivt_offset}
${loadcmd} mmc ${mmcdev}:${mmcpart} ${hab_ivt_addr}
${fdt_file_signed}
run warp7_auth_or_fail
else
run loadfdt;
fi

# Set the filesystem type and partition target
setenv loadcmd ext4load

# Boot from rootfs1 by default
setenv mmcpart 3

# But if the rootfs2 file exists in partition 2, boot from rootfs2
ext4size mmc 0:2 rootfs2 && setenv mmcpart 5

# This section is responsbile for loading a signed OPTEE image
setenv optee_file /lib/firmware/uTee.optee
setenv optee_file_signed /lib/firmware/uTee.optee.imx-signed
setenv loadoptee "${loadcmd} mmc ${mmcdev}:${mmcpart} ${optee_addr}
${optee_file}"
if test ${hab_enabled} -eq 1; then
setexpr hab_ivt_addr ${optee_addr} - ${ivt_offset}
${loadcmd} mmc ${mmcdev}:${mmcpart} ${hab_ivt_addr}
${optee_file_signed}
run warp7_auth_or_fail
else
run loadoptee;
fi

# Set UUID mmcpart will be used to pass root id to kernel
setenv rootpart ${mmcpart}
run finduuid;
run mmcargs;

# Now boot
echo Booting secure Linux/OPTEE OS from mmc ...;
bootm ${optee_addr} - ${fdt_addr};

# Failsafe if something goes wrong
hab_failsafe

Bryan O'Donoghue (18):
  imximage: Specify default IVT offset in IMX image
  warp7: hab: Add a CSF location definition
  warp7: hab: Set environment variable indicating HAB enable
  warp7: defconfig: Enable OPTEE for WaRP7
  warp7: Allocate specific region of memory to OPTEE
  warp7: Print out the OPTEE DRAM region
  warp7: Specify CONFIG_OPTEE_LOAD_ADDR
  warp7: defconfig: Enable CONFIG_SECURE_BOOT
  warp7: defconfig: Enable CONFIG_BOOTM_TEE
  warp7: Make CONFIG_SYS_FDT_ADDR a define
  warp7: Add Kconfig WARP7_ROOT_PART
  warp7: select uuid partition based on rootpart
  warp7: Define the name of a signed boot-script file
  warp7: add warp7_auth_or_fail
  warp7: Make load command an environment variable
  warp7: hab: Set environment variable indicating IVT offset
  warp7_secure: defconfig: Enable CMD_SETEXPR
  warp7: Add support for automated secure boot.scr verification

 board/warp7/Kconfig| 14 ++
 board/warp7/imximage.cfg   |  4 
 board/warp7/warp7.c| 23 +++
 configs/warp7_secure_defconfig |  6 +-
 include/configs/warp7.h| 29 -
 include/imximage.h |  3 +++
 6 files changed, 73 insertions(+), 6 deletions(-)

-- 
2.7.4

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


[U-Boot] [PATCH 01/18] imximage: Specify default IVT offset in IMX image

2018-03-30 Thread Bryan O'Donoghue
This patch adds BOOTROM_IVT_HDR_OFFSET at 0xC00. The BootROM expects to
find the IVT header at a particular offset in an i.MX image.

Defining the expected offset of the IVT header in the first-stage BootROM
image format is of use of later stage authentication routines where those
routines continue to follow the first-stage authentication layout.

This patch defines the first stage offset which later patch make use of.

Signed-off-by: Bryan O'Donoghue 
Cc: Utkarsh Gupta 
Cc: Breno Lima 
Cc: Fabio Estevam 
---
 include/imximage.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/imximage.h b/include/imximage.h
index 553b852..800fd63 100644
--- a/include/imximage.h
+++ b/include/imximage.h
@@ -14,6 +14,9 @@
 #define APP_CODE_BARKER0xB1
 #define DCD_BARKER 0xB17219E9
 
+/* Specify the offset of the IVT in the IMX header as expected by BootROM */
+#define BOOTROM_IVT_HDR_OFFSET 0xC00
+
 /*
  * NOTE: This file must be kept in sync with arch/arm/include/asm/\
  *   mach-imx/imximage.cfg because tools/imximage.c can not
-- 
2.7.4

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


[U-Boot] Please pull u-.boot-marvell/master

2018-03-30 Thread Stefan Roese
Hi Tom,

please pull the first batch of Marvell related patches.

Thanks,
Stefan


The following changes since commit 81cf7c8d45935a295991fe2cd1df286f0f47511f:

  Merge git://git.denx.de/u-boot-ubi (2018-03-25 12:02:13 -0400)

are available in the Git repository at:

  git://www.denx.de/git/u-boot-marvell.git 

for you to fetch changes up to 25db371e17d64c7a50f0f75e77a675651e5a2d4c:

  arm64: a37xx: defconfigs: enable PCI_CMD and E1000 driver (2018-03-30 
12:52:49 +0200)


Alexander Graf (1):
  kwbimage: Fix out of bounds access

Baruch Siach (1):
  configs: clearfog: enable random random MAC address

Igal Liberman (1):
  dm: pcie: designware: add correct ATU handling

Ken Ma (14):
  arm64: a37xx: dts: add gpio head file including
  arm64: a37xx: defconfig: Enable PINCTRL and GPIO support for ESPRESSOBin 
board
  arm64: a37xx: dts: Add pinctrl configuration for ESPRESSOBin board
  arm64: a37xx: dts: Add additional pinctrl definition
  arm64: a37xx: pinctrl: Fix number of pin in south bridge
  arm64: a37xx: dts: Fix the number of GPIO on south bridge
  arm64: a37xx: pinctrl: Fix the pin 23 on south bridge
  arm64: a37xx: pinctrl: Fix gpio pin offset in register
  arm64: a37xx: pinctrl: Correct mpp definitions
  arm64: a37xx: dts: Correct mpp definitions
  doc: a37xx: Introduce pinctrl device tree binding
  Revert "arm64: a37xx: dts: Add pin control nodes to DT"
  arm64: a37xx: remove old pinctrl implementation
  arm64: a37xx: defconfigs: enable PCI_CMD and E1000 driver

Mark Kettenis (1):
  arm64: mvebu: a8k: Add distro boot support

Wilson Ding (4):
  arm64: a37xx: populate pcie memory region
  arm64: a37xx: pci: add support for aardvark pcie driver
  arm64: a37xx: defconfigs: enable aardvark pcie driver
  arm64: a37xx: dts: enable pcie port

 arch/arm/dts/armada-3720-db.dts|  14 +-
 arch/arm/dts/armada-3720-espressobin.dts   |  15 +
 arch/arm/dts/armada-37xx.dtsi  |  52 +-
 arch/arm/mach-mvebu/armada3700/cpu.c   |   8 +
 board/Marvell/mvebu_armada-37xx/board.c|  23 -
 configs/clearfog_defconfig |   1 +
 configs/mvebu_db-88f3720_defconfig |   5 +
 configs/mvebu_espressobin-88f3720_defconfig|   9 +
 .../pinctrl/marvell,armada-37xx-pinctrl.txt| 186 ++
 drivers/pci/Kconfig|  10 +
 drivers/pci/Makefile   |   1 +
 drivers/pci/pci-aardvark.c | 690 +
 drivers/pci/pcie_dw_mvebu.c|  91 ++-
 drivers/pinctrl/mvebu/pinctrl-armada-37xx.c|  52 +-
 include/configs/mvebu_armada-8k.h  |  19 +
 tools/kwbimage.c   |   4 +
 16 files changed, 1088 insertions(+), 92 deletions(-)
 create mode 100644 
doc/device-tree-bindings/pinctrl/marvell,armada-37xx-pinctrl.txt
 create mode 100644 drivers/pci/pci-aardvark.c
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] configs: clearfog: enable random random MAC address

2018-03-30 Thread Stefan Roese

On 19.02.2018 07:17, Baruch Siach wrote:

This makes the network devices usable when booting a blank board over
UART, with no pre-configured MAC address stored in the environment area.

Signed-off-by: Baruch Siach 
---
  configs/clearfog_defconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
index a5ed3b20a63a..e2f1b635152f 100644
--- a/configs/clearfog_defconfig
+++ b/configs/clearfog_defconfig
@@ -30,6 +30,7 @@ CONFIG_CMD_CACHE=y
  CONFIG_CMD_TIME=y
  # CONFIG_SPL_PARTITION_UUIDS is not set
  CONFIG_ENV_IS_IN_MMC=y
+CONFIG_NET_RANDOM_ETHADDR=y
  CONFIG_SPL_OF_TRANSLATE=y
  CONFIG_MMC_SDHCI=y
  CONFIG_MMC_SDHCI_SDMA=y



Applied to u-boot-marvell/master.

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


Re: [U-Boot] [PATCH] dm: pcie: designware: add correct ATU handling

2018-03-30 Thread Stefan Roese

On 14.02.2018 18:25, ig...@marvell.com wrote:

From: Igal Liberman 

Currently, ATU (address translation unit) implementation doesn't
support translate addresses > 32 bits.

This patch allows to configure ATU correctly for different
memory accesses (memory, configuration and IO).
The same approach is used in Linux Kernel.

Signed-off-by: Igal Liberman 
---
  drivers/pci/pcie_dw_mvebu.c | 91 +
  1 file changed, 58 insertions(+), 33 deletions(-)

diff --git a/drivers/pci/pcie_dw_mvebu.c b/drivers/pci/pcie_dw_mvebu.c
index a198855..a0032b7 100644
--- a/drivers/pci/pcie_dw_mvebu.c
+++ b/drivers/pci/pcie_dw_mvebu.c
@@ -111,6 +111,10 @@ struct pcie_dw_mvebu {
void *cfg_base;
fdt_size_t cfg_size;
int first_busno;
+
+   /* IO and MEM PCI regions */
+   struct pci_region io;
+   struct pci_region mem;
  };
  
  static int pcie_dw_get_link_speed(const void *regs_base)

@@ -126,6 +130,34 @@ static int pcie_dw_get_link_width(const void *regs_base)
  }
  
  /**

+ * pcie_dw_prog_outbound_atu() - Configure ATU for outbound accesses
+ *
+ * @pcie: Pointer to the PCI controller state
+ * @index: ATU region index
+ * @type: ATU accsess type
+ * @cpu_addr: the physical address for the translation entry
+ * @pci_addr: the pcie bus address for the translation entry
+ * @size: the size of the translation entry
+ */
+static void pcie_dw_prog_outbound_atu(struct pcie_dw_mvebu *pcie, int index,
+ int type, u64 cpu_addr, u64 pci_addr,
+ u32 size)
+{
+   writel(PCIE_ATU_REGION_OUTBOUND | index,
+  pcie->ctrl_base + PCIE_ATU_VIEWPORT);
+   writel(lower_32_bits(cpu_addr), pcie->ctrl_base + PCIE_ATU_LOWER_BASE);
+   writel(upper_32_bits(cpu_addr), pcie->ctrl_base + PCIE_ATU_UPPER_BASE);
+   writel(lower_32_bits(cpu_addr + size - 1),
+  pcie->ctrl_base + PCIE_ATU_LIMIT);
+   writel(lower_32_bits(pci_addr),
+  pcie->ctrl_base + PCIE_ATU_LOWER_TARGET);
+   writel(upper_32_bits(pci_addr),
+  pcie->ctrl_base + PCIE_ATU_UPPER_TARGET);
+   writel(type, pcie->ctrl_base + PCIE_ATU_CR1);
+   writel(PCIE_ATU_ENABLE, pcie->ctrl_base + PCIE_ATU_CR2);
+}
+
+/**
   * set_cfg_address() - Configure the PCIe controller config space access
   *
   * @pcie: Pointer to the PCI controller state
@@ -143,27 +175,29 @@ static uintptr_t set_cfg_address(struct pcie_dw_mvebu 
*pcie,
 pci_dev_t d, uint where)
  {
uintptr_t va_address;
+   u32 atu_type;
  
  	/*

 * Region #0 is used for Outbound CFG space access.
 * Direction = Outbound
 * Region Index = 0
 */
-   writel(0, pcie->ctrl_base + PCIE_ATU_VIEWPORT);
  
  	if (PCI_BUS(d) == (pcie->first_busno + 1))

/* For local bus, change TLP Type field to 4. */
-   writel(PCIE_ATU_TYPE_CFG0, pcie->ctrl_base + PCIE_ATU_CR1);
+   atu_type = PCIE_ATU_TYPE_CFG0;
else
/* Otherwise, change TLP Type field to 5. */
-   writel(PCIE_ATU_TYPE_CFG1, pcie->ctrl_base + PCIE_ATU_CR1);
+   atu_type = PCIE_ATU_TYPE_CFG1;
  
  	if (PCI_BUS(d) == pcie->first_busno) {

/* Accessing root port configuration space. */
va_address = (uintptr_t)pcie->ctrl_base;
} else {
d = PCI_MASK_BUS(d) | (PCI_BUS(d) - pcie->first_busno);
-   writel(d << 8, pcie->ctrl_base + PCIE_ATU_LOWER_TARGET);
+   pcie_dw_prog_outbound_atu(pcie, PCIE_ATU_REGION_INDEX0,
+ atu_type, (u64)pcie->cfg_base,
+ d << 8, pcie->cfg_size);
va_address = (uintptr_t)pcie->cfg_base;
}
  
@@ -231,6 +265,10 @@ static int pcie_dw_mvebu_read_config(struct udevice *bus, pci_dev_t bdf,

debug("(addr,val)=(0x%04x, 0x%08lx)\n", offset, value);
*valuep = pci_conv_32_to_size(value, offset, size);
  
+	pcie_dw_prog_outbound_atu(pcie, PCIE_ATU_REGION_INDEX0,

+ PCIE_ATU_TYPE_IO, pcie->io.phys_start,
+ pcie->io.bus_start, pcie->io.size);
+
return 0;
  }
  
@@ -272,6 +310,10 @@ static int pcie_dw_mvebu_write_config(struct udevice *bus, pci_dev_t bdf,

value = pci_conv_size_to_32(old, value, offset, size);
writel(value, va_address);
  
+	pcie_dw_prog_outbound_atu(pcie, PCIE_ATU_REGION_INDEX0,

+ PCIE_ATU_TYPE_IO, pcie->io.phys_start,
+ pcie->io.bus_start, pcie->io.size);
+
return 0;
  }
  
@@ -388,34 +430,6 @@ static int pcie_dw_mvebu_pcie_link_up(const void *regs_base, u32 cap_speed)

  }
  
  /**

- * pcie_dw_regions_setup() - iATU region setup
- *
- * @pcie: Pointer to the PCI controller state
- *
- * 

Re: [U-Boot] [PATCH] arm64: mvebu: a8k: Add distro boot support

2018-03-30 Thread Stefan Roese

On 17.03.2018 09:34, Mark Kettenis wrote:

The various load address values are taken from the a37xx configuration
and match the dowstream 'u-boot-2017.03-armada-17.10' release where
appropriate.

Signed-off-by: Mark Kettenis 
---
  include/configs/mvebu_armada-8k.h | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/include/configs/mvebu_armada-8k.h 
b/include/configs/mvebu_armada-8k.h
index f288cf5b17..1cd0fa93d3 100644
--- a/include/configs/mvebu_armada-8k.h
+++ b/include/configs/mvebu_armada-8k.h
@@ -106,4 +106,23 @@
  #define CONFIG_E1000
  #endif
  
+#define BOOT_TARGET_DEVICES(func) \

+   func(MMC, mmc, 1) \
+   func(MMC, mmc, 0) \
+   func(USB, usb, 0) \
+   func(SCSI, scsi, 0) \
+   func(PXE, pxe, na) \
+   func(DHCP, dhcp, na)
+
+#include 
+
+#define CONFIG_EXTRA_ENV_SETTINGS  \
+   "scriptaddr=0x4d0\0"  \
+   "pxefile_addr_r=0x4e0\0"  \
+   "fdt_addr_r=0x4f0\0"  \
+   "kernel_addr_r=0x500\0"   \
+   "ramdisk_addr_r=0x800\0"  \
+   "fdtfile=marvell/" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
+   BOOTENV
+
  #endif /* _CONFIG_MVEBU_ARMADA_8K_H */



Applied to u-boot-marvell/master.

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


Re: [U-Boot] [PATCH] kwbimage: Fix out of bounds access

2018-03-30 Thread Stefan Roese

On 15.03.2018 11:14, Alexander Graf wrote:

The kwbimage format is reading beyond its header structure if it
misdetects a Xilinx Zynq image and tries to read it. Fix it by
sanity checking that the header we want to read fits inside our
file size.

Signed-off-by: Alexander Graf 
---
  tools/kwbimage.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 3ca3b3b4a6..26686ad30f 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1616,6 +1616,10 @@ static int kwbimage_verify_header(unsigned char *ptr, 
int image_size,
  struct image_tool_params *params)
  {
uint8_t checksum;
+   size_t header_size = kwbimage_header_size(ptr);
+
+   if (header_size > image_size)
+   return -FDT_ERR_BADSTRUCTURE;
  
  	if (!main_hdr_checksum_ok(ptr))

return -FDT_ERR_BADSTRUCTURE;



Applied to u-boot-marvell/master.

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


Re: [U-Boot] [PATCH 1/5] arm64: a37xx: populate pcie memory region

2018-03-30 Thread Stefan Roese

On 26.03.2018 09:57, m...@marvell.com wrote:

From: Wilson Ding 

This patch added a new region of 32MiB AT 0xe800.
to Armada37x0's memory map. This region is supposed to
be mapped in MMU in order to enable the access to the
PCI I/O or MEM resources.

Signed-off-by: Wilson Ding 
Reviewed-on: http://vgitil04.il.marvell.com:8080/38724
Tested-by: iSoC Platform CI 
Reviewed-by: Victor Gu 
Signed-off-by: Ken Ma 
Cc: Simon Glass 
Cc: Stefan Roese 
---
  arch/arm/mach-mvebu/armada3700/cpu.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-mvebu/armada3700/cpu.c 
b/arch/arm/mach-mvebu/armada3700/cpu.c
index 6499eec..cfe4469 100644
--- a/arch/arm/mach-mvebu/armada3700/cpu.c
+++ b/arch/arm/mach-mvebu/armada3700/cpu.c
@@ -46,6 +46,14 @@ static struct mm_region mvebu_mem_map[] = {
 PTE_BLOCK_NON_SHARE
},
{
+   /* PCI regions */
+   .phys = 0xe800UL,
+   .virt = 0xe800UL,
+   .size = 0x0200UL,   /* 32MiB master PCI space */
+   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE
+   },
+   {
/* List terminator */
0,
}



Complete series applied to u-boot-marvell/master.

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


Re: [U-Boot] [PATCH 01/13] arm64: a37xx: dts: add gpio head file including

2018-03-30 Thread Stefan Roese

On 26.03.2018 09:55, m...@marvell.com wrote:

From: Ken Ma 

Cc: Simon Glass 
Cc: Stefan Roese 
Signed-off-by: Ken Ma 
---
  arch/arm/dts/armada-37xx.dtsi | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/armada-37xx.dtsi b/arch/arm/dts/armada-37xx.dtsi
index 6902342..75a22de 100644
--- a/arch/arm/dts/armada-37xx.dtsi
+++ b/arch/arm/dts/armada-37xx.dtsi
@@ -46,6 +46,7 @@
  
  #include 

  #include 
+#include 
  
  / {

model = "Marvell Armada 37xx SoC";



Complete series applied to u-boot-marvell/master.

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


Re: [U-Boot] [uboot-snps-arc] [PATCH v2 0/2] SF: add support for sst26wf016, sst26wf032, sst26wf064

2018-03-30 Thread Alexey Brodkin
Hi Jagan,

On Mon, 2018-03-26 at 14:08 +0300, Eugeniy Paltsev wrote:
> Add support for the SST sst26wf016, sst26wf032 and sst26wf064 flash IC:
> 
> sst26wf*** flash series block protection implementation differs from other
> SST series, so we add implementation for sst26wf*** lock/unlock/is_locked
> functions.
> 
> Add sst26wf016, sst26wf032 and sst26wf064 flash IC info to spi_flash_ids list.
> 
> 
> Changes v1->v2:
>  * Use generic defines from linux/sizes.h instead of custom ones.
> 
> Eugeniy Paltsev (2):
>   SPI Flash: add support of sst26wf* flash series
>   SF: add support for sst26wf016, sst26wf032, sst26wf064
> 
>  drivers/mtd/spi/spi_flash.c | 188 
> 
>  drivers/mtd/spi/spi_flash_ids.c |   3 +
>  2 files changed, 191 insertions(+)

Any chance for this series to hit your's and then Tom's
repos before RC1 gets cut on Monday April 2nd?

-Alexey

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


[U-Boot] [PATCH] configs: warp7: Fix CAAM on boot with tip-of-tree

2018-03-30 Thread 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 
---
 configs/warp7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index 29c4512..228f7d9 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_MX7=y
 CONFIG_SYS_TEXT_BASE=0x8780
 CONFIG_TARGET_WARP7=y
+CONFIG_ARMV7_BOOT_SEC_DEFAULT=y
 # CONFIG_ARMV7_VIRT is not set
 CONFIG_IMX_RDC=y
 CONFIG_IMX_BOOTAUX=y
-- 
2.7.4

___
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

2018-03-30 Thread Bin Meng
Hi Ivan,

On Fri, Mar 30, 2018 at 6:29 AM, Ivan Gorinov  wrote:
> Adding HPET as an alternative timer for x86 (default is TSC).
> HPET counter has constant frequency and does not need calibration.
> This change also makes TSC timer driver optional on x86.
> If X86_TSC is disabled, early timer functions are provided by HPET.
>
> Signed-off-by: Ivan Gorinov 
> ---
>  arch/Kconfig   |   2 +-
>  arch/x86/dts/hpet.dtsi |   7 ++
>  drivers/timer/Kconfig  |   6 ++
>  drivers/timer/Makefile |   1 +
>  drivers/timer/hpet_timer.c | 191 
> +
>  5 files changed, 206 insertions(+), 1 deletion(-)
>  create mode 100644 arch/x86/dts/hpet.dtsi
>  create mode 100644 drivers/timer/hpet_timer.c
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index e599e7a..37dabae 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -104,7 +104,7 @@ config X86
> select DM_PCI
> select PCI
> select TIMER
> -   select X86_TSC_TIMER
> +   imply X86_TSC_TIMER
> imply BLK
> imply DM_ETH
> imply DM_GPIO
> diff --git a/arch/x86/dts/hpet.dtsi b/arch/x86/dts/hpet.dtsi
> new file mode 100644
> index 000..037dc7e
> --- /dev/null
> +++ b/arch/x86/dts/hpet.dtsi
> @@ -0,0 +1,7 @@
> +/ {
> +   hpet0: hpet@fed0 {

nits: use 'hpet' instead of 'hpet0'? since there is only one hpet
timer in the system.

> +   compatible = "hpet-x86";
> +   u-boot,dm-pre-reloc;
> +   reg = <0xfed0 0x1000>;
> +   };
> +};
> diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
> index 2c96896..72ae6c5 100644
> --- a/drivers/timer/Kconfig
> +++ b/drivers/timer/Kconfig
> @@ -65,6 +65,12 @@ config X86_TSC_TIMER
> help
>   Select this to enable Time-Stamp Counter (TSC) timer for x86.
>
> +config HPET_TIMER
> +   bool "High Precision Event Timers (HPET) support"
> +   depends on TIMER && X86
> +   help
> + Select this to enable High Precision Event Timers (HPET) for x86.
> +
>  config OMAP_TIMER
> bool "Omap timer support"
> depends on TIMER
> diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
> index a6e7832..557fecc 100644
> --- a/drivers/timer/Makefile
> +++ b/drivers/timer/Makefile
> @@ -8,6 +8,7 @@ obj-y += timer-uclass.o
>  obj-$(CONFIG_ALTERA_TIMER) += altera_timer.o
>  obj-$(CONFIG_SANDBOX_TIMER)+= sandbox_timer.o
>  obj-$(CONFIG_X86_TSC_TIMER)+= tsc_timer.o
> +obj-$(CONFIG_HPET_TIMER)   += hpet_timer.o
>  obj-$(CONFIG_OMAP_TIMER)   += omap-timer.o
>  obj-$(CONFIG_AST_TIMER)+= ast_timer.o
>  obj-$(CONFIG_STI_TIMER)+= sti-timer.o
> diff --git a/drivers/timer/hpet_timer.c b/drivers/timer/hpet_timer.c
> new file mode 100644
> index 000..0bef859
> --- /dev/null
> +++ b/drivers/timer/hpet_timer.c
> @@ -0,0 +1,191 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define HPET_PERIOD_REG 0x004
> +#define HPET_CONFIG_REG 0x010
> +#define HPET_MAIN_COUNT_L 0x0f0
> +#define HPET_MAIN_COUNT_H 0x0f4
> +
> +#define HPET_MAX_PERIOD 1
> +
> +DECLARE_GLOBAL_DATA_PTR;

This is not needed.

> +
> +struct hpet_timer_priv {
> +   void *regs;
> +};
> +
> +/*
> + * Returns HPET clock frequency in HZ
> + * (rounding to the nearest integer),
> + * or 0 if HPET is not available.
> + */
> +static inline u32 get_clock_frequency(void *regs)
> +{
> +   u64 d = 1000ull;
> +   u32 period;
> +
> +   period = readl(regs + HPET_PERIOD_REG);
> +   if (period == 0)
> +   return 0;
> +   if (period > HPET_MAX_PERIOD)
> +   return 0;
> +
> +   d += period / 2;
> +
> +   return d / period;
> +}
> +
> +/*
> + * Reset and start the main counter.
> + */

nits: use one line comment format

> +static void start_main_counter(void *regs)
> +{
> +   u32 config;
> +
> +   config = readl(regs + HPET_CONFIG_REG);
> +   config &= ~1;
> +   writel(config, regs + HPET_CONFIG_REG);
> +   writel(0, regs + HPET_MAIN_COUNT_L);
> +   writel(0, regs + HPET_MAIN_COUNT_H);
> +   config |= 1;
> +   writel(config, regs + HPET_CONFIG_REG);
> +}
> +
> +/*
> + * 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 {
> +   th0 = th;
> +   tl = readl(regs + HPET_MAIN_COUNT_L);
> +   th = readl(regs + HPET_MAIN_COUNT_H);
> +   } while (th != th0);
> +
> +   now_tick = th;
> +   now_tick <<= 32;
> +   now_tick |= tl;
> +
> +   return now_tick;
> +}
> +
> +static int hpet_timer_get_count(struct 

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

2018-03-30 Thread 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 
---
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.

 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 

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

2018-03-30 Thread 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 
---
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.

 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 

Re: [U-Boot] [PATCH] mkimage: do not fail if there is no print_header function

2018-03-30 Thread Dr. Philipp Tomsich

> On 30 Mar 2018, at 10:28, Guillaume GARDET  wrote:
> 
> Commit 253c60a breaks the exit value of 'mkimage -T rkimage'
> and print the following  error:
>  mkimage: Can't print header for Rockchip Boot Image support: Success
> 
> It is not a failure to not print headers, so just display the warning message,
> and finish the function properly.
> 
> Signed-off-by: Guillaume GARDET 

Reviewed-by: Philipp Tomsich 

> Cc: Philipp Tomsich 
> Cc: Simon Glass 
> Cc: Tom Rini 
> ---
> tools/mkimage.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/mkimage.c b/tools/mkimage.c
> index 28ff35e670..4e561820e7 100644
> --- a/tools/mkimage.c
> +++ b/tools/mkimage.c
> @@ -588,9 +588,8 @@ int main(int argc, char **argv)
>   if (tparams->print_header)
>   tparams->print_header (ptr);
>   else {
> - fprintf (stderr, "%s: Can't print header for %s: %s\n",
> - params.cmdname, tparams->name, strerror(errno));
> - exit (EXIT_FAILURE);
> + fprintf (stderr, "%s: Can't print header for %s\n",
> + params.cmdname, tparams->name);
>   }
> 
>   (void) munmap((void *)ptr, sbuf.st_size);
> -- 
> 2.13.6
> 

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


Re: [U-Boot] [PATCH 6/8] cpu: Add cpu_print_info function

2018-03-30 Thread Simon Glass
Hi,

On 28 March 2018 at 20:38, Mario Six  wrote:
> Add a cpu_print_info function to the CPU uclass to emulate the behavior
> of some current non-DM drivers (e.g. MPC83xx) to print CPU information
> during startup.
>
> Signed-off-by: Mario Six 
> ---
>  drivers/cpu/cpu-uclass.c | 10 ++
>  include/cpu.h| 15 +++
>  2 files changed, 25 insertions(+)
>

I really don't want drivers printing stuff. Can you use the existing
get_info() method?

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


Re: [U-Boot] [PATCH 2/7] axi: Add AXI sandbox driver and simple emulator

2018-03-30 Thread Simon Glass
Hi Mario,

On 28 March 2018 at 20:40, Mario Six  wrote:
> Add test infrastructure and tests for the AXI uclass.
>
> Signed-off-by: Mario Six 
> ---
>  drivers/axi/Kconfig   |   6 +++
>  drivers/axi/Makefile  |   3 ++
>  drivers/axi/axi-emul-uclass.c |  68 
>  drivers/axi/axi_sandbox.c |  61 ++
>  drivers/axi/sandbox_store.c   | 118 
> ++
>  include/axi.h |  51 ++
>  include/dm/uclass-id.h|   1 +
>  7 files changed, 308 insertions(+)
>  create mode 100644 drivers/axi/axi-emul-uclass.c
>  create mode 100644 drivers/axi/axi_sandbox.c
>  create mode 100644 drivers/axi/sandbox_store.c
>
> diff --git a/drivers/axi/Kconfig b/drivers/axi/Kconfig
> index 19e1b7fd2f..a0333782cf 100644
> --- a/drivers/axi/Kconfig
> +++ b/drivers/axi/Kconfig
> @@ -21,4 +21,10 @@ config IHS_AXI
>   Support for IHS AXI bus on a gdsys IHS FPGA used to communicate with
>   IP cores in the FPGA (e.g. video transmitter cores).
>
> +config AXI_SANDBOX
> +   bool "Enable AXI sandbox driver"
> +   depends on DM
> +   help
> + Support the AXI emulation for the sandbox environment.

Please spell out abbreviations

> +
>  endif
> diff --git a/drivers/axi/Makefile b/drivers/axi/Makefile
> index 18d9380e9b..66b6c5a28f 100644
> --- a/drivers/axi/Makefile
> +++ b/drivers/axi/Makefile
> @@ -7,3 +7,6 @@
>
>  obj-$(CONFIG_AXI) += axi-uclass.o
>  obj-$(CONFIG_IHS_AXI) += ihs_axi.o
> +obj-$(CONFIG_SANDBOX) += axi-emul-uclass.o
> +obj-$(CONFIG_SANDBOX) += sandbox_store.o
> +obj-$(CONFIG_AXI_SANDBOX) += axi_sandbox.o
> diff --git a/drivers/axi/axi-emul-uclass.c b/drivers/axi/axi-emul-uclass.c
> new file mode 100644
> index 00..bf60c40518
> --- /dev/null
> +++ b/drivers/axi/axi-emul-uclass.c
> @@ -0,0 +1,68 @@
> +/*
> + * (C) Copyright 2018
> + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +int axi_sandbox_get_emul(struct udevice *bus, ulong address, enum axi_size_t 
> size,
> +struct udevice **emulp)
> +{
> +   struct udevice *dev;
> +   u32 reg[2];
> +   uint offset;
> +
> +   switch (size) {
> +   case AXI_SIZE_8:
> +   offset = 1;
> +   break;
> +   case AXI_SIZE_16:
> +   offset = 2;
> +   break;
> +   case AXI_SIZE_32:
> +   offset = 4;
> +   break;
> +   default:
> +   offset = 0;
> +   }
> +
> +   for (device_find_first_child(bus, );
> +dev;
> +device_find_next_child()) {
> +   int ret;
> +
> +   ret = dev_read_u32_array(dev, "reg", reg, ARRAY_SIZE(reg));
> +   if (ret)
> +   continue;
> +
> +   if (address >= reg[0] && address <= reg[0] + reg[1] - offset) 
> {
> +   if (device_probe(dev))
> +   return -ENODEV;
> +
> +   *emulp = dev;
> +   return 0;
> +   }
> +   }
> +
> +   return -ENODEV;
> +}
> +
> +int axi_get_store(struct udevice *dev, u8 **store)
> +{
> +   struct axi_emul_ops *ops = axi_emul_get_ops(dev);
> +
> +   if (!ops->get_store)
> +   return -ENOSYS;
> +
> +   return ops->get_store(dev, store);
> +}
> +
> +UCLASS_DRIVER(axi_emul) = {
> +   .id = UCLASS_AXI_EMUL,
> +   .name   = "axi_emul",
> +};
> diff --git a/drivers/axi/axi_sandbox.c b/drivers/axi/axi_sandbox.c
> new file mode 100644
> index 00..b0f24bdd9d
> --- /dev/null
> +++ b/drivers/axi/axi_sandbox.c
> @@ -0,0 +1,61 @@
> +/*
> + * (C) Copyright 2018
> + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +int axi_sandbox_read(struct udevice *bus, ulong address, void *data,
> +enum axi_size_t size)
> +{
> +   struct axi_emul_ops *ops;
> +   struct udevice *emul;
> +   int ret;
> +
> +   ret = axi_sandbox_get_emul(bus, address, size, );
> +   if (ret)
> +   return ret == -ENODEV ? 0 : ret;

Please add a comment as to why you are doing this.

> +   ops = axi_emul_get_ops(emul);
> +   if (!ops || !ops->read)
> +   return -ENOSYS;
> +
> +   return ops->read(emul, address, data, size);
> +}
> +
> +int axi_sandbox_write(struct udevice *bus, ulong address, void *data,
> + enum axi_size_t size)
> +{
> +   struct axi_emul_ops *ops;
> +   struct udevice *emul;
> +   int ret;
> +
> +   ret = axi_sandbox_get_emul(bus, address, size, );
> +   if (ret)
> +   return ret == -ENODEV ? 0 : ret;
> +   ops = 

Re: [U-Boot] [PATCH 1/1] log: fix typo LOGL_EFI

2018-03-30 Thread Simon Glass
On 24 March 2018 at 04:12, Heinrich Schuchardt  wrote:
> According to the documentation the EFI log category is called LOGC_EFI.
> All other categories start with LOGC_. So let's fix it.
>
> Fixes: 1973b381a1b3 ("log: add category LOGC_EFI")
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/log.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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


Re: [U-Boot] [PATCH 3/7] sandbox: Add and build AXI bus and device

2018-03-30 Thread Simon Glass
On 28 March 2018 at 20:40, Mario Six  wrote:
> Add test AXI drivers to the sandbox.
>
> Signed-off-by: Mario Six 
> ---
>  arch/sandbox/dts/sandbox.dts | 11 +++
>  arch/sandbox/dts/test.dts| 11 +++
>  configs/sandbox_defconfig|  3 +++
>  3 files changed, 25 insertions(+)

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


Re: [U-Boot] [RFC] net: eth_write_hwaddr hides ENOSYS

2018-03-30 Thread Simon Glass
Hi Heinrich,

On 24 March 2018 at 21:41, Heinrich Schuchardt  wrote:
> Hello Simon,
>
> in patch
> db9391e165dd ("net: Move driver-model code into its own file")
> function eth_write_hwaddr hides() you chose to introduce the follwing lines:
>
> static int eth_write_hwaddr(struct udevice *dev)
> ...
> /*
>  * Drivers are allowed to decide not to implement this at
>  * run-time. E.g. Some devices may use it and some may not.
>  */
> ret = eth_get_ops(dev)->write_hwaddr(dev);
> if (ret == -ENOSYS)
> ret = 0;
>
> For implementing efi_net_station_address() it would be preferable if the
> function would return -ENOSYS to signal that changing the MAC address
> failed.

Actually -ENOSYS if the method is not implemented, and -ENXIO or
something if the write failed.

There is a clear distinction between:

* -ENOSYS the method is not implemented (so you might choose to not
worry about the error)
* -Esomething_else - the method is implemented, but failed (so you
probably want to return an error)

>
> I could not find any caller of the driver model version of
> eth_write_hwaddr(). Do you remember why you made this choice?
>
> Best regards
>
> Heinrich

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


Re: [U-Boot] [PATCH] env: Properly check for BLK support

2018-03-30 Thread Simon Glass
On 23 March 2018 at 05:53, Sjoerd Simons  wrote:
> Use CONFIG_IS_ENABLED to see if CONFIG_BLK is enabled. Otherwise
> SPL compilation breaks on boards which do have CONFIG_BLK enabled but
> not DM_MMC for the SPL as follows:
>
> env/mmc.c: In function ‘init_mmc_for_env’:
> env/mmc.c:164:6: warning: implicit declaration of function 
> ‘blk_get_from_parent’; did you mean ‘efi_get_ram_base’? 
> [-Wimplicit-function-declaration]
>   if (blk_get_from_parent(mmc->dev, ))
>   ^~~
>   efi_get_ram_base
> env/mmc.c:164:29: error: ‘struct mmc’ has no member named ‘dev’
>   if (blk_get_from_parent(mmc->dev, ))
>  ^~
>
> Signed-off-by: Sjoerd Simons 
> ---
>
>  env/mmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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


Re: [U-Boot] [PATCH 6/7] video_display: Add power_on function

2018-03-30 Thread Simon Glass
Hi Mario,

On 28 March 2018 at 20:40, Mario Six  wrote:
> Add a power_on function to the display uclass to allow devices to be
> probed and powered-on separately.

Is this different from the 'enable' method?

Also note that we have a panel uclass that might be useful.

>
> Signed-off-by: Mario Six 
> ---
>  drivers/video/display-uclass.c | 10 ++
>  include/display.h  | 18 ++
>  2 files changed, 28 insertions(+)
>
> diff --git a/drivers/video/display-uclass.c b/drivers/video/display-uclass.c
> index e752eb07c4..4865057e94 100644
> --- a/drivers/video/display-uclass.c
> +++ b/drivers/video/display-uclass.c
> @@ -57,6 +57,16 @@ int display_read_timing(struct udevice *dev, struct 
> display_timing *timing)
> return edid_get_timing(buf, ret, timing, _bits_per_colour);
>  }
>
> +int display_power_on(struct udevice *dev, void *data)
> +{
> +   struct dm_display_ops *ops = display_get_ops(dev);
> +
> +   if (!ops || !ops->power_on)
> +   return -ENOSYS;
> +
> +   return ops->power_on(dev, data);
> +}
> +
>  bool display_in_use(struct udevice *dev)
>  {
> struct display_plat *disp_uc_plat = dev_get_uclass_platdata(dev);
> diff --git a/include/display.h b/include/display.h
> index d0a08d4aaa..bb263be246 100644
> --- a/include/display.h
> +++ b/include/display.h
> @@ -51,6 +51,15 @@ int display_enable(struct udevice *dev, int panel_bpp,
>   */
>  bool display_in_use(struct udevice *dev);
>
> +/**
> + * display_power_on() - Power on display port device
> + *
> + * @dev:   Device to power on
> + * @data:  Optional data needed to power on the display correctly
> + * @return 0 if OK, -ve on error
> + */
> +int display_power_on(struct udevice *dev, void *data);
> +
>  struct dm_display_ops {
> /**
>  * read_timing() - Read information directly
> @@ -81,6 +90,15 @@ struct dm_display_ops {
>  */
> int (*enable)(struct udevice *dev, int panel_bpp,
>   const struct display_timing *timing);
> +
> +   /**
> +* power_on() - Power on display port device
> +*
> +* @dev:Device to power on
> +* @data:   Optional data needed to power on the display correctly
> +* @return 0 if OK, -ve on error
> +*/
> +   int (*power_on)(struct udevice *dev, void *data);
>  };
>
>  #define display_get_ops(dev)   ((struct dm_display_ops *)(dev)->driver->ops)
> --
> 2.16.1
>

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


Re: [U-Boot] [PATCH 1/8] core: Add uclass_{first, next}_device_compat

2018-03-30 Thread Simon Glass
Hi Mario,

On 28 March 2018 at 20:38, Mario Six  wrote:
> A lot of times one wants to cycle through the devices in a uclass, but
> only certain ones, especially ones identified by their compatibility
> string, and ignore all others (in the best case this procedure should
> not even activate the devices one is not interested in).
>
> Hence, we add a pair of functions similar to uclass_{first,next}_device,
> but taking a compatibility string as an additional argument, which cycle
> through the devices of a uclass that conform to this compatibility
> string.

Can we not use a phandle to find the device? Using raw compatible
strings feel bad (and slow to me).

If not, a please add a sandbox test.

>
> Signed-off-by: Mario Six 
> ---
>  drivers/core/uclass.c | 33 +
>  include/dm/uclass.h   | 37 +
>  2 files changed, 70 insertions(+)

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


Re: [U-Boot] [PATCH 1/7] drivers: Add AXI uclass and ihs_axi driver

2018-03-30 Thread Simon Glass
Hi Mario,

On 28 March 2018 at 20:40, Mario Six  wrote:
> Add a uclass for AXI (Advanced eXtensible Interface) busses, and a
> driver for the gdsys IHS AXI bus on IHS FPGAs.
>
> Signed-off-by: Mario Six 
> ---
>  drivers/Kconfig  |   2 +
>  drivers/Makefile |   1 +
>  drivers/axi/Kconfig  |  24 ++
>  drivers/axi/Makefile |   9 +++
>  drivers/axi/axi-uclass.c |  40 ++
>  drivers/axi/ihs_axi.c| 199 
> +++
>  include/axi.h|  75 ++
>  include/dm/uclass-id.h   |   1 +
>  8 files changed, 351 insertions(+)
>  create mode 100644 drivers/axi/Kconfig
>  create mode 100644 drivers/axi/Makefile
>  create mode 100644 drivers/axi/axi-uclass.c
>  create mode 100644 drivers/axi/ihs_axi.c
>  create mode 100644 include/axi.h

Would UCLASS_MAILBOX be suitable here?

It's fine if you want a new uclass, just checking.

Please split out your driver into a separate patch. Adding the new
uclass should be in its own patch.

>
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index c2e813f5ad..eeaaa7575c 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -8,6 +8,8 @@ source "drivers/adc/Kconfig"
>
>  source "drivers/ata/Kconfig"
>
> +source "drivers/axi/Kconfig"
> +
>  source "drivers/block/Kconfig"
>
>  source "drivers/bootcount/Kconfig"
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 6846d181aa..f54a10f3ad 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -100,6 +100,7 @@ obj-y += input/
>  obj-y += soc/
>  obj-$(CONFIG_REMOTEPROC) += remoteproc/
>  obj-y += thermal/
> +obj-y += axi/
>
>  obj-$(CONFIG_MACH_PIC32) += ddr/microchip/
>  endif
> diff --git a/drivers/axi/Kconfig b/drivers/axi/Kconfig
> new file mode 100644
> index 00..19e1b7fd2f
> --- /dev/null
> +++ b/drivers/axi/Kconfig
> @@ -0,0 +1,24 @@
> +menuconfig AXI
> +   bool "AXI bus drivers"
> +   help
> + Support AXI (Advanced eXtensible Interface) busses, a on-chip
> + interconnect specification for managing functional blocks in SoC
> + designs, which is also often used in designs involving FPGAs (e.g.
> + communication with IP cores in Xilinx FPGAs).
> +
> + These types of busses expose a virtual address space that can be
> + accessed using different address widths (8, 16, and 32 are supported
> + for now).
> +
> + Other similar bus architectures may be compatible as well.
> +
> +if AXI
> +
> +config IHS_AXI
> +   bool "Enable IHS AXI driver"
> +   depends on DM
> +   help
> + Support for IHS AXI bus on a gdsys IHS FPGA used to communicate with
> + IP cores in the FPGA (e.g. video transmitter cores).

Please also spell out the abbreviations in the help

[...]

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


Re: [U-Boot] [PATCH 7/7] video_display: Add Xilinx LogiCore DP TX

2018-03-30 Thread Simon Glass
Hi Mario,

On 28 March 2018 at 20:40, Mario Six  wrote:
> Add a driver for the Xilinx LogiCORE DisplayPort IP core.
>
> Signed-off-by: Mario Six 
> ---
>  drivers/video/Kconfig|8 +
>  drivers/video/Makefile   |1 +
>  drivers/video/logicore_dp_dpcd.h |  342 ++
>  drivers/video/logicore_dp_tx.c   | 1974 
> ++
>  drivers/video/logicore_dp_tx.h   |   40 +
>  drivers/video/logicore_dp_tx_regif.h |  365 +++
>  6 files changed, 2730 insertions(+)
>  create mode 100644 drivers/video/logicore_dp_dpcd.h
>  create mode 100644 drivers/video/logicore_dp_tx.c
>  create mode 100644 drivers/video/logicore_dp_tx.h
>  create mode 100644 drivers/video/logicore_dp_tx_regif.h

Is it possible to have common code with the other DP drivers?

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


Re: [U-Boot] [PATCH 3/4] clk: add Amlogic meson clock driver

2018-03-30 Thread Simon Glass
Hi Neil,

On 30 March 2018 at 15:53, Neil Armstrong  wrote:
> On 30/03/2018 00:41, Simon Glass wrote:
>> Hi Neil,
>>
>> On 29 March 2018 at 16:42, Neil Armstrong  wrote:
>>> Hi Beniamino,
>>>
>>> On 03/12/2017 10:17, Beniamino Galvani wrote:
 Introduce a basic clock driver for Amlogic Meson SoCs which supports
 enabling/disabling clock gates and getting their frequency.

 Signed-off-by: Beniamino Galvani 
 ---
  arch/arm/mach-meson/Kconfig |   2 +
  drivers/clk/Makefile|   1 +
  drivers/clk/clk_meson.c | 196 
 
  3 files changed, 199 insertions(+)
  create mode 100644 drivers/clk/clk_meson.c

 diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig
 index d4bd230be3..7acee3bc5c 100644
 --- a/arch/arm/mach-meson/Kconfig
 +++ b/arch/arm/mach-meson/Kconfig
>>>
>>> [...]
 +
 +static int meson_set_gate(struct clk *clk, bool on)
 +{
 + struct meson_clk *priv = dev_get_priv(clk->dev);
 + struct meson_gate *gate;
 +
 + if (clk->id >= ARRAY_SIZE(gates))
 + return -ENOENT;
>>>
>>> This should be -ENOSYS, otherwise it breaks the ethernet driver since it 
>>> waits -ENOSYS if clock cannot be enabled.
>>
>> Perhaps, but this is a genuine error, so it is OK to break the
>> Ethernet driver, isn't it? We don't want errors to be silently
>> ignored.
>>
>> Not having a device is one thing, but having a device that does not work is 
>> bad.
>>
>
> The driver only manages the gates, enabling and disabling them and getting 
> their freq.
> The missing clocks of the ethernet driver in this case are dividers of the 
> PLL, thus
> we don't need to enable them, and for now the driver don't need the freq.

Yes but -ENOSYS means that the driver does not support the operation
at all. Put it another way: you can't return -ENOSYS for some
parameters and not for others.

>
>> Also I have tried to keep -ENOSYS for cases where the driver does not
>> support the operation. We should be very clear in clk-uclass.h as to
>> what errors are returned. At present I don't see ENOSYS mentioned. At
>> the very least we should update the docs if certain behaviour is
>> expected. I would also expect us to have a sandbox test for it.
>
> In this case, the driver does not support the operation for these clocks, but 
> maybe it would be
> better to add them with reg=0 and return -ENOSYS in the following return :

I don't like that - ENOENT seems better.

>
>>
>>>
 +
 + gate = [clk->id];
 +
 + if (gate->reg == 0)
 + return -ENOENT;
>>>
>>> Same here -ENOSYS
>
> Here thsi means it's not a gate.

Yes, but the driver still supports the operation. The problem is that
its inputs are invalid. So use -ENOENT to mean that.

>
>>>
 +
 + clrsetbits_le32(priv->addr + gate->reg,
 + BIT(gate->bit), on ? BIT(gate->bit) : 0);
 + return 0;
 +}
 +
 +static int meson_clk_enable(struct clk *clk)
 +{
 + return meson_set_gate(clk, true);
 +}
 +
 +static int meson_clk_disable(struct clk *clk)
 +{
 + return meson_set_gate(clk, false);
 +}
 +
 +static ulong meson_clk_get_rate(struct clk *clk)
 +{
 + struct meson_clk *priv = dev_get_priv(clk->dev);
 +
 + if (clk->id != CLKID_CLK81) {
 + if (clk->id >= ARRAY_SIZE(gates))
 + return -ENOENT;
>>>
>>> Same here -ENOSYS
>>>
 + if (gates[clk->id].reg == 0)
 + return -ENOENT;
>>>
>>> Same here -ENOSYS
>>>
 + }
 +
 + /* Use cached value if available */
 + if (priv->rate)
 + return priv->rate;
 +
 + priv->rate = meson_measure_clk_rate(CLK_81);
 +
 + return priv->rate;
 +}
 +
>>>
>>> [...]
>>>
>>> Neil
>>
>> Regards,
>> Simon
>>
>


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


Re: [U-Boot] [PATCH 1/2] misc: uclass: Add enable/disable functions

2018-03-30 Thread Simon Glass
Hi Mario,

On 28 March 2018 at 20:38, Mario Six  wrote:
> Add generic enable/disable functions to the misc uclass.
>
> Signed-off-by: Mario Six 
> ---
>  drivers/misc/misc-uclass.c | 20 
>  include/misc.h | 30 ++
>  2 files changed, 50 insertions(+)
>
> diff --git a/drivers/misc/misc-uclass.c b/drivers/misc/misc-uclass.c
> index d9eea3dac5..942fa8da94 100644
> --- a/drivers/misc/misc-uclass.c
> +++ b/drivers/misc/misc-uclass.c
> @@ -56,6 +56,26 @@ int misc_call(struct udevice *dev, int msgid, void 
> *tx_msg, int tx_size,
> return ops->call(dev, msgid, tx_msg, tx_size, rx_msg, rx_size);
>  }
>
> +int misc_enable(struct udevice *dev)
> +{
> +   const struct misc_ops *ops = device_get_ops(dev);
> +
> +   if (!ops->enable)
> +   return -ENOSYS;
> +
> +   return ops->enable(dev);
> +}
> +
> +int misc_disable(struct udevice *dev)
> +{
> +   const struct misc_ops *ops = device_get_ops(dev);
> +
> +   if (!ops->enable)
> +   return -ENOSYS;
> +
> +   return ops->disable(dev);
> +}
> +
>  UCLASS_DRIVER(misc) = {
> .id = UCLASS_MISC,
> .name   = "misc",
> diff --git a/include/misc.h b/include/misc.h
> index 03ef55cdc8..6f86396443 100644
> --- a/include/misc.h
> +++ b/include/misc.h
> @@ -58,6 +58,22 @@ int misc_ioctl(struct udevice *dev, unsigned long request, 
> void *buf);
>  int misc_call(struct udevice *dev, int msgid, void *tx_msg, int tx_size,
>   void *rx_msg, int rx_size);
>
> +/*
> + * Enable a device.
> + *
> + * @dev: the device to enable.
> + * @return: 0 if OK, -ve on error
> + */
> +int misc_enable(struct udevice *dev);

How about a single function like:

int misc_set_enable(struct udevice *dev, bool enable);

Also please state in the comment what exactly it means to
enable/disable a device.

> +
> +/*
> + * Disable a device.
> + *
> + * @dev: the device to disable.
> + * @return: 0 if OK, -ve on error
> + */
> +int misc_disable(struct udevice *dev);
> +
>  /*
>   * struct misc_ops - Driver model Misc operations
>   *
> @@ -109,6 +125,20 @@ struct misc_ops {
>  */
> int (*call)(struct udevice *dev, int msgid, void *tx_msg, int tx_size,
> void *rx_msg, int rx_size);
> +   /*
> +* Enable a device, optional.
> +*
> +* @dev: the device to enable.
> +* @return: 0 if OK, -ve on error
> +*/
> +   int (*enable)(struct udevice *dev);
> +   /*
> +* Disable a device, optional.
> +*
> +* @dev: the device to disable.
> +* @return: 0 if OK, -ve on error
> +*/
> +   int (*disable)(struct udevice *dev);
>  };
>
>  #endif /* _MISC_H_ */
> --
> 2.16.1
>

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


Re: [U-Boot] [PATCH v3 01/10] syscon: dm: Add a new method to get a regmap from DTS

2018-03-30 Thread Simon Glass
Hi Jean-Jacques,

On 26 March 2018 at 21:50, Jean-Jacques Hiblot  wrote:
> syscon_regmap_lookup_by_phandle() can be used to the regmap of a syscon

used to ... the

> device from a reference in the DTS. It operates similarly to the linux
> version of the namesake function.
>
> Signed-off-by: Jean-Jacques Hiblot 
>
> ---
>
> Changes in v3:
> - in syscon_regmap_lookup_by_phandle(), use dev_dbg() instead of printf()
> - added unit test for syscon_regmap_lookup_by_phandle()
>
> Changes in v2: None
>
>  arch/sandbox/dts/test.dts|  6 --
>  drivers/core/syscon-uclass.c | 23 +++
>  include/syscon.h | 13 +
>  test/dm/syscon.c | 29 +
>  4 files changed, 69 insertions(+), 2 deletions(-)
>

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


Re: [U-Boot] [PATCH 2/2] devinfo: Add gazerbeam info driver

2018-03-30 Thread Simon Glass
Hi Mario,

On 28 March 2018 at 20:36, Mario Six  wrote:
> Add a device information driver for the upcoming gdsys Gazerbeam board.
>
> Signed-off-by: Mario Six 
> ---
>  drivers/devinfo/gazerbeam.c | 151 
> 
>  drivers/devinfo/gazerbeam.h |  17 +
>  2 files changed, 168 insertions(+)
>  create mode 100644 drivers/devinfo/gazerbeam.c
>  create mode 100644 drivers/devinfo/gazerbeam.h
>
> diff --git a/drivers/devinfo/gazerbeam.c b/drivers/devinfo/gazerbeam.c
> new file mode 100644
> index 00..10226aa254
> --- /dev/null
> +++ b/drivers/devinfo/gazerbeam.c
> @@ -0,0 +1,151 @@
> +/*
> + * (C) Copyright 2017
> + * Mario Six,  Guntermann & Drunck GmbH, mario@gdsys.cc
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "gazerbeam.h"
> +
> +const int VER_GPIOS_COUNT = 4;
> +
> +struct devinfo_gazerbeam_priv {
> +   struct gpio_desc var_gpios[2];
> +   struct gpio_desc ver_gpios[4];
> +   int variant;
> +   int multichannel;
> +   int hwversion;
> +};
> +
> +static int _read_multichannel_variant(struct udevice *dev)
> +{
> +   struct devinfo_gazerbeam_priv *priv = dev_get_priv(dev);
> +   struct udevice *i2c_bus;
> +   struct udevice *dummy;
> +   char *listname;
> +   bool mc4, mc2, sc, con;
> +
> +   uclass_get_device_by_seq(UCLASS_I2C, 1, _bus);

Please pass the error through unless there is a good reason not to.

ret = uclass ...
if (ret) {
   debug(...)
   return ret
}

> +
> +   if (!i2c_bus) {
> +   puts("Could not get I2C bus\n");
> +   return -EIO;
> +   }
> +
> +   mc2 = !dm_i2c_probe(i2c_bus, 0x20, 0, );
> +   mc4 = !dm_i2c_probe(i2c_bus, 0x22, 0, );

Same here
> +
> +   if (mc2 && mc4) {
> +   puts("Board hardware configuration inconsistent.\n");
> +   return -EINVAL;
> +   }
> +
> +   listname = mc2 ? "var_gpios_mc2" : "var_gpios_mc4";

If these are DT properties they should use hyphen instead of underscore

> +
> +   if (!gpio_request_list_by_name(dev, listname, priv->var_gpios,
> +  2, GPIOD_IS_IN)) {
> +   printf("Requesting gpio list %s failed.\n", listname);
> +   return -ENODEV;

Return correct error

> +   }
> +
> +   sc = dm_gpio_get_value(>var_gpios[0]);
> +   con = dm_gpio_get_value(>var_gpios[1]);

And here
> +
> +   if ((sc && mc2) || (sc && mc4) || (!sc && !mc2 && !mc4)) {
> +   puts("Board hardware configuration inconsistent.\n");
> +   return -EINVAL;
> +   }
> +
> +   priv->variant = con ? VAR_CON : VAR_CPU;
> +
> +   priv->multichannel = mc4 ? 4 : (mc2 ? 2 : (sc ? 1 : 0));
> +
> +   return 0;
> +}
> +
> +static int _read_hwversion(struct udevice *dev)
> +{
> +   struct devinfo_gazerbeam_priv *priv = dev_get_priv(dev);
> +   int value;
> +
> +   if (!gpio_request_list_by_name(dev, "ver_gpios", priv->ver_gpios,

ver-gpios ?

> +  VER_GPIOS_COUNT, GPIOD_IS_IN))
> +   return -ENODEV;
> +
> +   value = dm_gpio_get_values_as_int(priv->ver_gpios, VER_GPIOS_COUNT);
> +
> +   if (value < 0)
> +   return value;
> +
> +   priv->hwversion = value;
> +
> +   gpio_free_list(dev, priv->ver_gpios, VER_GPIOS_COUNT);
> +
> +   return 0;
> +}
> +
> +int devinfo_gazerbeam_detect(struct udevice *dev)
> +{
> +   int res;
> +
> +   res = _read_multichannel_variant(dev);
> +   if (res)
> +   return res;
> +
> +   res = _read_hwversion(dev);
> +   if (res)
> +   return res;
> +
> +   return 0;
> +}
> +
> +int devinfo_gazerbeam_get_int(struct udevice *dev, int id, int *val)
> +{
> +   struct devinfo_gazerbeam_priv *priv = dev_get_priv(dev);
> +
> +   switch (id) {
> +   case DEVINFO_MULTICHANNEL:
> +   *val = priv->multichannel;
> +   break;
> +   case DEVINFO_VARIANT:
> +   *val = priv->variant;
> +   break;
> +   case DEVINFO_HWVERSION:
> +   *val = priv->hwversion;
> +   break;
> +   default:
> +   return -EINVAL;
> +   }
> +
> +   return 0;
> +}
> +
> +static const struct udevice_id devinfo_gazerbeam_ids[] = {
> +   { .compatible = "gdsys,devinfo_gazerbeam" },
> +   { /* sentinel */ }
> +};
> +
> +static const struct devinfo_ops devinfo_gazerbeam_ops = {
> +   .detect = devinfo_gazerbeam_detect,
> +   .get_int = devinfo_gazerbeam_get_int,
> +};
> +
> +int devinfo_gazerbeam_probe(struct udevice *dev)
> +{
> +   return 0;
> +}
> +
> +U_BOOT_DRIVER(devinfo_gazerbeam) = {
> +   .name   = "devinfo_gazerbeam",
> +   .id = UCLASS_DEVINFO,
> +   .of_match   = devinfo_gazerbeam_ids,
> +  

Re: [U-Boot] [PATCH 1/3] drivers: Add FPGA register map uclass

2018-03-30 Thread Simon Glass
Hi Mario,

On 28 March 2018 at 20:37, Mario Six  wrote:
> The FPGA (as a device) and the register map supplied by a FPGA are two
> different entities. There are U-Boot drivers for the former, but not for
> the later.
>
> Add a uclass that makes it possible to read from and write to FPGA
> memory maps. The interface provided emulates the PCI interface, with one
> function for reading/writing plus a size parameter.
>
> Signed-off-by: Mario Six 
> ---
>  drivers/Kconfig  |   2 +
>  drivers/Makefile |   1 +
>  drivers/fpgamap/Kconfig  |   9 +++
>  drivers/fpgamap/Makefile |   8 +++
>  drivers/fpgamap/fpgamap-uclass.c |  53 
>  include/dm/uclass-id.h   |   1 +
>  include/fpgamap.h| 131 
> +++
>  7 files changed, 205 insertions(+)
>  create mode 100644 drivers/fpgamap/Kconfig
>  create mode 100644 drivers/fpgamap/Makefile
>  create mode 100644 drivers/fpgamap/fpgamap-uclass.c
>  create mode 100644 include/fpgamap.h
>

Could we use regmap for this? That uclass really could use being
enhanced to do the things you do here.

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


Re: [U-Boot] [PATCH 1/2] drivers: Add devinfo uclass

2018-03-30 Thread Simon Glass
Hi Mario,

On 28 March 2018 at 20:36, Mario Six  wrote:
> Some boards have encoded information, e.g. hard-wired GPIOs on a GPIO
> expander, read-only memory ICs, etc. that carry information about the
> hardware.
>
> Add a uclass that encapsulates device information of such a kind and
> makes them accessible in a uniform manner. The devices of this uclass
> expose methods to read generic data types (integers, strings, booleans)
> to encode the information provided by the hardware.
>
> Signed-off-by: Mario Six 
> ---
>  drivers/Kconfig  |  2 ++
>  drivers/Makefile |  1 +
>  drivers/devinfo/Kconfig  | 17 
>  drivers/devinfo/Makefile |  9 +++
>  drivers/devinfo/devinfo-uclass.c | 55 +++
>  include/devinfo.h| 56 
> 
>  include/dm/uclass-id.h   |  1 +
>  7 files changed, 141 insertions(+)
>  create mode 100644 drivers/devinfo/Kconfig
>  create mode 100644 drivers/devinfo/Makefile
>  create mode 100644 drivers/devinfo/devinfo-uclass.c
>  create mode 100644 include/devinfo.h

Please can you add a sandbox driver for this and a test?

>
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index c2e813f5ad..34777d9013 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -22,6 +22,8 @@ source "drivers/ddr/Kconfig"
>
>  source "drivers/demo/Kconfig"
>
> +source "drivers/devinfo/Kconfig"
> +
>  source "drivers/ddr/fsl/Kconfig"
>
>  source "drivers/dfu/Kconfig"
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 6846d181aa..208b68081e 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -72,6 +72,7 @@ obj-y += block/
>  obj-$(CONFIG_BOOTCOUNT_LIMIT) += bootcount/
>  obj-$(CONFIG_CPU) += cpu/
>  obj-y += crypto/
> +obj-y += devinfo/
>  obj-y += firmware/
>  obj-$(CONFIG_FPGA) += fpga/
>  obj-y += misc/
> diff --git a/drivers/devinfo/Kconfig b/drivers/devinfo/Kconfig
> new file mode 100644
> index 00..0de70b410e
> --- /dev/null
> +++ b/drivers/devinfo/Kconfig
> @@ -0,0 +1,17 @@
> +menuconfig DEVINFO
> +   bool "Device Information"
> +   help
> + Support methods to query hardware configurations from internal
> + mechanisms (e.g. reading GPIO values, determining the presence of
> + devices on busses, etc.). This enables the usage of U-Boot with
> + modular board architectures.
> +
> +if DEVINFO
> +
> +
> +config DEVINFO_GAZERBEAM
> +   bool "Enable device information for the Gazerbeam board"
> +   help
> + Support querying device information for the gdsys Gazerbeam board.
> +
> +endif
> diff --git a/drivers/devinfo/Makefile b/drivers/devinfo/Makefile
> new file mode 100644
> index 00..0a9cad4a15
> --- /dev/null
> +++ b/drivers/devinfo/Makefile
> @@ -0,0 +1,9 @@
> +#
> +# (C) Copyright 2017
> +# Mario Six,  Guntermann & Drunck GmbH, mario@gdsys.cc
> +#
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +
> +obj-$(CONFIG_DEVINFO) += devinfo-uclass.o
> +obj-$(CONFIG_DEVINFO_GAZERBEAM) += gazerbeam.o
> diff --git a/drivers/devinfo/devinfo-uclass.c 
> b/drivers/devinfo/devinfo-uclass.c
> new file mode 100644
> index 00..89bbe8f343
> --- /dev/null
> +++ b/drivers/devinfo/devinfo-uclass.c
> @@ -0,0 +1,55 @@
> +/*
> + * (C) Copyright 2017
> + * Mario Six,  Guntermann & Drunck GmbH, mario@gdsys.cc
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +int devinfo_detect(struct udevice *dev)
> +{
> +   struct devinfo_ops *ops = devinfo_get_ops(dev);
> +
> +   if (!ops->detect)
> +   return -ENOSYS;
> +
> +   return ops->detect(dev);
> +}
> +
> +int devinfo_get_bool(struct udevice *dev, int id, bool *val)
> +{
> +   struct devinfo_ops *ops = devinfo_get_ops(dev);
> +
> +   if (!ops->get_bool)
> +   return -ENOSYS;
> +
> +   return ops->get_bool(dev, id, val);
> +}
> +
> +int devinfo_get_int(struct udevice *dev, int id, int *val)
> +{
> +   struct devinfo_ops *ops = devinfo_get_ops(dev);
> +
> +   if (!ops->get_int)
> +   return -ENOSYS;
> +
> +   return ops->get_int(dev, id, val);
> +}
> +
> +int devinfo_get_str(struct udevice *dev, int id, char *val)
> +{
> +   struct devinfo_ops *ops = devinfo_get_ops(dev);
> +
> +   if (!ops->get_str)
> +   return -ENOSYS;
> +
> +   return ops->get_str(dev, id, val);
> +}
> +
> +UCLASS_DRIVER(devinfo) = {
> +   .id = UCLASS_DEVINFO,
> +   .name   = "devinfo",
> +};
> diff --git a/include/devinfo.h b/include/devinfo.h
> new file mode 100644
> index 00..90014c27c4
> --- /dev/null
> +++ b/include/devinfo.h
> @@ -0,0 +1,56 @@
> +/*
> + * (C) Copyright 2017
> + * Mario Six,  Guntermann & Drunck GmbH, mario@gdsys.cc
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +struct devinfo_ops {
> +   int 

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

2018-03-30 Thread Simon Glass
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'.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] image: fit: Show firmware configuration property if present

2018-03-30 Thread Simon Glass
On 26 March 2018 at 22:31, Michal Simek  wrote:
> SPL ATF support requires to have firmware property which should be also
> listed by mkimage -l when images is created.
>
> The patch is also using this macro in spl_fit to match keyword.
>
> When image is created:
>  Default Configuration: 'config'
>  Configuration 0 (config)
>   Description:  ATF with full u-boot
>   Kernel:   unavailable
>   Firmware: atf
>   FDT:  dtb
>
> Signed-off-by: Michal Simek 
> ---
>
>  common/image-fit.c   | 4 
>  common/spl/spl_fit.c | 3 ++-
>  include/image.h  | 1 +
>  3 files changed, 7 insertions(+), 1 deletion(-)
>

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


[U-Boot] [PATCH] mkimage: do not fail if there is no print_header function

2018-03-30 Thread Guillaume GARDET
Commit 253c60a breaks the exit value of 'mkimage -T rkimage'
and print the following  error:
  mkimage: Can't print header for Rockchip Boot Image support: Success

It is not a failure to not print headers, so just display the warning message,
and finish the function properly.

Signed-off-by: Guillaume GARDET 

Cc: Philipp Tomsich 
Cc: Simon Glass 
Cc: Tom Rini 
---
 tools/mkimage.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/mkimage.c b/tools/mkimage.c
index 28ff35e670..4e561820e7 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -588,9 +588,8 @@ int main(int argc, char **argv)
if (tparams->print_header)
tparams->print_header (ptr);
else {
-   fprintf (stderr, "%s: Can't print header for %s: %s\n",
-   params.cmdname, tparams->name, strerror(errno));
-   exit (EXIT_FAILURE);
+   fprintf (stderr, "%s: Can't print header for %s\n",
+   params.cmdname, tparams->name);
}
 
(void) munmap((void *)ptr, sbuf.st_size);
-- 
2.13.6

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


[U-Boot] Please pull u-boot-x86

2018-03-30 Thread Bin Meng
Hi Tom,

The following changes since commit 81cf7c8d45935a295991fe2cd1df286f0f47511f:

  Merge git://git.denx.de/u-boot-ubi (2018-03-25 12:02:13 -0400)

are available in the git repository at:

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

for you to fetch changes up to 5d73292cf84db1e8f7d99dd27100ef2e8ac15c4e:

  x86: zImage: Pass working device tree data to the kernel (2018-03-30
16:06:58 +0800)


Alexander Graf (1):
  efi_stub: Fix GDT_NOTSYS check

Bernhard Messerklinger (1):
  x86: mmc: Fix mapping of BAR memory

Bin Meng (2):
  dm: pci: Check board information pointer in decode_regions()
  dm: pci: Avoid setting a PCI region that has 0 size

Ivan Gorinov (1):
  x86: zImage: Pass working device tree data to the kernel

 arch/x86/include/asm/bootparam.h |  7 +--
 arch/x86/lib/zimage.c| 35 +++
 drivers/mmc/pci_mmc.c|  5 ++---
 drivers/pci/pci-uclass.c |  8 ++--
 lib/efi/efi_stub.c   |  2 +-
 5 files changed, 49 insertions(+), 8 deletions(-)

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


Re: [U-Boot] [PATCH v3] x86: zImage: Pass working device tree data to the kernel

2018-03-30 Thread Bin Meng
On Tue, Mar 27, 2018 at 9:06 AM, Ivan Gorinov  wrote:
> On x86 platforms, U-Boot does not pass Device Tree data to the kernel.
> This prevents the kernel from using FDT loaded by U-Boot.
>
> Read the working FDT address from the "fdtaddr" environment variable
> and add a copy of the FDT data to the kernel setup_data list.
>
> Signed-off-by: Ivan Gorinov 
> ---
>  arch/x86/include/asm/bootparam.h |  7 +--
>  arch/x86/lib/zimage.c| 34 ++
>  2 files changed, 39 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/bootparam.h 
> b/arch/x86/include/asm/bootparam.h
> index 90768a9..6aba614 100644
> --- a/arch/x86/include/asm/bootparam.h
> +++ b/arch/x86/include/asm/bootparam.h
> @@ -10,8 +10,11 @@
>  #include 
>
>  /* setup data types */
> -#define SETUP_NONE 0
> -#define SETUP_E820_EXT 1
> +enum {
> +   SETUP_NONE = 0,
> +   SETUP_E820_EXT,
> +   SETUP_DTB,
> +};
>
>  /* extensible setup data list node */
>  struct setup_data {
> diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
> index 2a82bc8..1ff77e9 100644
> --- a/arch/x86/lib/zimage.c
> +++ b/arch/x86/lib/zimage.c
> @@ -14,6 +14,7 @@
>   */
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 

Sorry to mention that I added "#include " here to fix
build error seen on several x86 boards during a buildman testing.
Changed applied to u-boot-x86.

> @@ -95,6 +96,38 @@ static int get_boot_protocol(struct setup_header *hdr)
> }
>  }
>

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


Re: [U-Boot] [PATCH] efi_stub: Fix GDT_NOTSYS check

2018-03-30 Thread Bin Meng
Hi Alex,

On Thu, Feb 15, 2018 at 11:03 PM, Alexander Graf  wrote:
>
>
> On 12.02.18 07:26, Bin Meng wrote:
>> Hi Alexander,
>>
>> On Tue, Dec 5, 2017 at 7:20 AM, Bin Meng  wrote:
>>> On Mon, Dec 4, 2017 at 11:33 PM, Alexander Graf  wrote:
 The get_codeseg32() wants to know if a passed in descriptor has
 flag GDT_NOTSYS set (desc & GDT_NOTSYS), not whether desc and
 GDT_NOTSYS are not != 0 (desk && GDT_NOTSYS).

 This is an obvious typo. Fix it up.

 Signed-off-by: Alexander Graf 
 ---
  lib/efi/efi_stub.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

>>>
>>> Reviewed-by: Bin Meng 
>>
>> Looks this one is applied nowhere?
>
> lib/efi is something you maintain, no?
>
> I only want to run U-Boot as UEFI firmware, I don't particularly care
> about running U-Boot as UEFI payload :).

Since I see on patchwork, this patch was assigned to you so I did not take it.
I will pick this patch to x86. Thanks.

applied to u-boot-x86, thanks!

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


Re: [U-Boot] [PATCH 3/4] clk: add Amlogic meson clock driver

2018-03-30 Thread Neil Armstrong
On 30/03/2018 00:41, Simon Glass wrote:
> Hi Neil,
> 
> On 29 March 2018 at 16:42, Neil Armstrong  wrote:
>> Hi Beniamino,
>>
>> On 03/12/2017 10:17, Beniamino Galvani wrote:
>>> Introduce a basic clock driver for Amlogic Meson SoCs which supports
>>> enabling/disabling clock gates and getting their frequency.
>>>
>>> Signed-off-by: Beniamino Galvani 
>>> ---
>>>  arch/arm/mach-meson/Kconfig |   2 +
>>>  drivers/clk/Makefile|   1 +
>>>  drivers/clk/clk_meson.c | 196 
>>> 
>>>  3 files changed, 199 insertions(+)
>>>  create mode 100644 drivers/clk/clk_meson.c
>>>
>>> diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig
>>> index d4bd230be3..7acee3bc5c 100644
>>> --- a/arch/arm/mach-meson/Kconfig
>>> +++ b/arch/arm/mach-meson/Kconfig
>>
>> [...]
>>> +
>>> +static int meson_set_gate(struct clk *clk, bool on)
>>> +{
>>> + struct meson_clk *priv = dev_get_priv(clk->dev);
>>> + struct meson_gate *gate;
>>> +
>>> + if (clk->id >= ARRAY_SIZE(gates))
>>> + return -ENOENT;
>>
>> This should be -ENOSYS, otherwise it breaks the ethernet driver since it 
>> waits -ENOSYS if clock cannot be enabled.
> 
> Perhaps, but this is a genuine error, so it is OK to break the
> Ethernet driver, isn't it? We don't want errors to be silently
> ignored.
> 
> Not having a device is one thing, but having a device that does not work is 
> bad.
> 

The driver only manages the gates, enabling and disabling them and getting 
their freq.
The missing clocks of the ethernet driver in this case are dividers of the PLL, 
thus
we don't need to enable them, and for now the driver don't need the freq.

> Also I have tried to keep -ENOSYS for cases where the driver does not
> support the operation. We should be very clear in clk-uclass.h as to
> what errors are returned. At present I don't see ENOSYS mentioned. At
> the very least we should update the docs if certain behaviour is
> expected. I would also expect us to have a sandbox test for it.

In this case, the driver does not support the operation for these clocks, but 
maybe it would be
better to add them with reg=0 and return -ENOSYS in the following return :

> 
>>
>>> +
>>> + gate = [clk->id];
>>> +
>>> + if (gate->reg == 0)
>>> + return -ENOENT;
>>
>> Same here -ENOSYS

Here thsi means it's not a gate.

>>
>>> +
>>> + clrsetbits_le32(priv->addr + gate->reg,
>>> + BIT(gate->bit), on ? BIT(gate->bit) : 0);
>>> + return 0;
>>> +}
>>> +
>>> +static int meson_clk_enable(struct clk *clk)
>>> +{
>>> + return meson_set_gate(clk, true);
>>> +}
>>> +
>>> +static int meson_clk_disable(struct clk *clk)
>>> +{
>>> + return meson_set_gate(clk, false);
>>> +}
>>> +
>>> +static ulong meson_clk_get_rate(struct clk *clk)
>>> +{
>>> + struct meson_clk *priv = dev_get_priv(clk->dev);
>>> +
>>> + if (clk->id != CLKID_CLK81) {
>>> + if (clk->id >= ARRAY_SIZE(gates))
>>> + return -ENOENT;
>>
>> Same here -ENOSYS
>>
>>> + if (gates[clk->id].reg == 0)
>>> + return -ENOENT;
>>
>> Same here -ENOSYS
>>
>>> + }
>>> +
>>> + /* Use cached value if available */
>>> + if (priv->rate)
>>> + return priv->rate;
>>> +
>>> + priv->rate = meson_measure_clk_rate(CLK_81);
>>> +
>>> + return priv->rate;
>>> +}
>>> +
>>
>> [...]
>>
>> Neil
> 
> 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] Move CONFIG_PHY_ADDR to Kconfig

2018-03-30 Thread Bin Meng
Hi Joe,

On Thu, Mar 29, 2018 at 2:17 AM, Joe Hershberger  wrote:
> On Sun, Mar 25, 2018 at 8:40 PM, Bin Meng  wrote:
>> Hi Joe,
>>
>> On Sat, Mar 24, 2018 at 1:11 AM, Joe Hershberger  
>> wrote:
>>> On Thu, Mar 22, 2018 at 9:46 AM, Bin Meng  wrote:
 Hi,

 On Fri, Feb 2, 2018 at 9:53 PM, Stefan Mavrodiev  wrote:
> CONFIG_PHY_ADDR is used for old-style configuration. This makes
> impossible changing the PHY address, if multiple boards share a same
> config header file (for example include/configs/sunxi-common.h).
>
> Moving this to Kconfig helps overcoming this issue. It's defined
> as entry inside PHYLIB section.
>
> After the implemention, moveconfig was run. The issues are:
> - edb9315a  - CONFIG_PHYLIB is not enabled. Entry is
>   deleted.
>
> - ds414 - CONFIG_PHYLIB is in incompatible format:
>   { 0x1, 0x0 }. This entry is also deleted.
>
> - devkit3250- The PHY_ADDR is in hex format (0x1F).
>   Manually CONFIG_PHY_ADDR=31 is added in
>   the defconfig.
>
> After the changes the suspicious defconfigs passes building.
>
> Signed-off-by: Stefan Mavrodiev 
> Acked-by: Maxime Ripard 
> ---
>  Changes for v2:
>- Replaced CONFIG_SUNXI_PHY_ADDR with a common one
>  CONFIG_PHY_ADDR, using moveconfig.
>
>  README | 4 
>  configs/devkit3250_defconfig   | 1 +
>  configs/khadas-vim_defconfig   | 1 +
>  configs/libretech-cc_defconfig | 1 +
>  configs/p212_defconfig | 1 +
>  drivers/net/phy/Kconfig| 7 +++
>  include/configs/am335x_shc.h   | 1 -
>  include/configs/baltos.h   | 1 -
>  include/configs/devkit3250.h   | 1 -
>  include/configs/ds414.h| 1 -
>  include/configs/edb93xx.h  | 1 -
>  include/configs/khadas-vim.h   | 2 --
>  include/configs/libretech-cc.h | 2 --
>  include/configs/p212.h | 2 --
>  include/configs/pepper.h   | 1 -
>  include/configs/sunxi-common.h | 2 --
>  include/configs/work_92105.h   | 1 -
>  include/configs/x600.h | 1 -
>  scripts/config_whitelist.txt   | 1 -
>  19 files changed, 11 insertions(+), 21 deletions(-)
>

 [snip]

> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 95b7534..c934aed 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -12,6 +12,13 @@ menuconfig PHYLIB
>
>  if PHYLIB
>
> +config PHY_ADDR
> +   int "PHY address"
> +   default 1 if ARCH_SUNXI
> +   default 0
> +   help
> + The address of PHY on MII bus. Usually in range of 0 to 31.
> +

 Sorry for jumping out so late, but this commit breaks Intel Galileo
 ethernet. Previously the board boots with the following log:

 Net: eth0: eth_designware#0, eth1: eth_designware#1

 With this commit it becomes:

 Net:   No ethernet found.

 The reason is that the board has two designware ethernet controllers,
 and PHY_ADDR has been set to zero for both. A simple fix is to:

 diff --git a/drivers/net/designware.c b/drivers/net/designware.c
 index 43670a7..1394119 100644
 --- a/drivers/net/designware.c
 +++ b/drivers/net/designware.c
 @@ -471,10 +471,6 @@ static int dw_phy_init(struct dw_eth_dev *priv, void 
 *dev)
 struct phy_device *phydev;
 int mask = 0x, ret;

 -#ifdef CONFIG_PHY_ADDR
 -   mask = 1 << CONFIG_PHY_ADDR;
 -#endif
 -
 phydev = phy_find_by_mask(priv->bus, mask, priv->interface);
 if (!phydev)
 return -ENODEV;

 But the real question is that: why do we introduce this PHY_ADDR
 Kconfig? It for sure won't work for multiple ethernet controllers.This
 should be eliminated IMHO. Comments?
>>>
>>> This should be able to come from the device tree, ultimately. Can you
>>> undefine the phy addr for the Galileo board?
>>>
 [snip]

>>
>> #undf the PHY_ADDR in Galileo board looks weird. This to me is a workaround.
>
> I didn't mean to add a #undef. I was just saying that if the "default
> 0" in the Kconfig were instead "default 0 if !X86" or something (or
> maybe if the board defconfig explicitly does unselects it).
>

This cannot be done as CONFIG_PHY_ADDR is an "int", not a "bool". We
cannot do "# CONFIG_PHY_ADDR is not set" in the galileo_defconfig.

>> Since the designware ethernet controller driver supports finding any
>> PHY attached to its mdio bus, the changes suggested above can be a
>> proper fix.
>
> 

Re: [U-Boot] [PATCH v3] x86: zImage: Pass working device tree data to the kernel

2018-03-30 Thread Bin Meng
On Tue, Mar 27, 2018 at 9:58 AM, Bin Meng  wrote:
> On Tue, Mar 27, 2018 at 9:06 AM, Ivan Gorinov  wrote:
>> On x86 platforms, U-Boot does not pass Device Tree data to the kernel.
>> This prevents the kernel from using FDT loaded by U-Boot.
>>
>> Read the working FDT address from the "fdtaddr" environment variable
>> and add a copy of the FDT data to the kernel setup_data list.
>>
>> Signed-off-by: Ivan Gorinov 
>> ---
>>  arch/x86/include/asm/bootparam.h |  7 +--
>>  arch/x86/lib/zimage.c| 34 ++
>>  2 files changed, 39 insertions(+), 2 deletions(-)
>>
>
> Reviewed-by: Bin Meng 

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


Re: [U-Boot] [PATCH] x86: mmc: Fix mapping of BAR memory

2018-03-30 Thread Bin Meng
On Mon, Mar 19, 2018 at 11:43 AM, Bin Meng  wrote:
> On Thu, Feb 15, 2018 at 4:09 PM, Bernhard Messerklinger
>  wrote:
>> Use dm_pci_map_bar function for BAR mapping. This has the advantage
>> of clearing BAR flags and and only accepting mapped memory.
>>
>> Signed-off-by: Bernhard Messerklinger 
>> 
>> ---
>>
>>  drivers/mmc/pci_mmc.c | 5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>
> Reviewed-by: Bin Meng 

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


Re: [U-Boot] [PATCH 2/2] dm: pci: Avoid setting a PCI region that has 0 size

2018-03-30 Thread Bin Meng
On Fri, Mar 30, 2018 at 6:43 AM, Simon Glass  wrote:
> On 27 March 2018 at 15:46, Bin Meng  wrote:
>> It makes no sense to set a PCI region that has 0 size.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  drivers/pci/pci-uclass.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> Reviewed-by: Simon Glass 

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


Re: [U-Boot] [PATCH 1/2] dm: pci: Check board information pointer in decode_regions()

2018-03-30 Thread Bin Meng
On Fri, Mar 30, 2018 at 6:43 AM, Simon Glass  wrote:
> On 27 March 2018 at 15:46, Bin Meng  wrote:
>> PCI enumeration may happen very early on an x86 board. The board
>> information pointer should have been checked in decode_regions()
>> as its space may not be allocated yet.
>>
>> With this commit, Intel Galileo board boots again.
>>
>> Fixes: 664758c ("pci: Fix decode regions for memory banks")
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  drivers/pci/pci-uclass.c | 3 +++
>>  1 file changed, 3 insertions(+)
>
> Reviewed-by: Simon Glass 

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


[U-Boot] [PATCH] armv7m: disable icache before linux booting

2018-03-30 Thread Patrice Chotard
Similarly to ARMV7, on ARMV7M instruction cache memory needs
to be disabled before running linux kernel to avoid kernel to
be stuck.

Signed-off-by: Patrice Chotard 
---

 arch/arm/cpu/armv7m/cpu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/cpu/armv7m/cpu.c b/arch/arm/cpu/armv7m/cpu.c
index a424babde547..29597750f8be 100644
--- a/arch/arm/cpu/armv7m/cpu.c
+++ b/arch/arm/cpu/armv7m/cpu.c
@@ -37,6 +37,9 @@ int cleanup_before_linux(void)
 * dcache flushing and disabling dcache */
invalidate_dcache_all();
 
+   icache_disable();
+   invalidate_icache_all();
+
return 0;
 }
 
-- 
1.9.1

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


[U-Boot] Uboot send pull request

2018-03-30 Thread uboot
 Hi Tom,

 Please pull the following patch from u-boot-riscv into your tree.
 Thanks!

The following changes since commit 81cf7c8d45935a295991fe2cd1df286f0f47511f:

  Merge git://git.denx.de/u-boot-ubi (2018-03-25 12:02:13 -0400)

are available in the Git repository at:

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

for you to fetch changes up to d58717e42559189a226ea800173147399c8edef9:

  riscv: ae250: Support DT provided by the board at runtime (2018-03-30 
13:13:56 +0800)


Rick Chen (20):
  riscv: checkpatch: Fix Macro argument reuse
  riscv: checkpatch: Fix use of volatile
  riscv: checkpatch: Fix alignment should match open parenthesis
  riscv: checkpatch: Fix missing a blank line after declarations
  riscv: checkpatch: Fix static const char * array declarations
  riscv: bootm: Support to boot riscv-linux
  riscv: bootm: Remove ATAGS
  tools: mkimage: Support RISC-V arch
  doc: ae250: Describe riscv-linux booting via u-boot
  mmc: ftsdc010: Support High-Speed mode
  riscv: dts: AE250 support sd High-Speed mode
  nds32: dts: AG101P support sd High-Speed mode
  mmc: ftsdc010: Drop non-dm code
  board: Drop ftsdc010 non-dm code
  Drop CONFIG_FTSDC010_BASE
  Drop CONFIG_FTSDC010_NUMBER
  mmc: ftsdc010: Migrate CONFIG_FTSDC010_SDIO to Kconfig
  mmc: ftsdc010: Merge nds32_mmc to ftsdc010
  configs: Drop CONFIG_MMC_NDS32
  riscv: ae250: Support DT provided by the board at runtime

 arch/nds32/dts/ag101p.dts |   1 +
 arch/nds32/include/asm/arch-ae3xx/ae3xx.h |   2 -
 arch/nds32/include/asm/arch-ag101/ag101.h |   2 -
 arch/nds32/include/asm/arch-ag102/ag102.h |   2 -
 arch/riscv/cpu/nx25/start.S   |   2 +
 arch/riscv/dts/ae250.dts  |   1 +
 arch/riscv/include/asm/bootm.h|  49 
 arch/riscv/include/asm/encoding.h |  16 +---
 arch/riscv/include/asm/global_data.h  |   2 +-
 arch/riscv/include/asm/io.h   |  23 +---
 arch/riscv/include/asm/posix_types.h  |  12 --
 arch/riscv/include/asm/ptrace.h   |   9 ++---
 arch/riscv/include/asm/setup.h|  10 +++--
 arch/riscv/include/asm/string.h   |  12 --
 arch/riscv/lib/bootm.c| 185 
+++---
 arch/riscv/lib/interrupts.c   |   2 +-
 board/AndesTech/adp-ae3xx/adp-ae3xx.c |  11 --
 board/AndesTech/adp-ag101p/adp-ag101p.c   |  11 --
 board/AndesTech/nx25-ae250/nx25-ae250.c   |  14 +++
 common/image.c|   1 +
 configs/adp-ae3xx_defconfig   |   2 +-
 configs/adp-ag101p_defconfig  |   2 +-
 configs/nx25-ae250_defconfig  |   3 +-
 doc/README.ae250  | 148 
+---
 drivers/mmc/Kconfig   |  14 +++
 drivers/mmc/Makefile  |   1 -
 drivers/mmc/ftsdc010_mci.c| 219 
+--
 drivers/mmc/ftsdc010_mci.h|  15 
 drivers/mmc/nds32_mmc.c   | 136 
--
 include/configs/adp-ae3xx.h   |   6 ---
 include/configs/adp-ag101p.h  |   6 ---
 include/configs/nx25-ae250.h  |  18 ++---
 scripts/config_whitelist.txt  |   4 --
 33 files changed, 347 insertions(+), 594 deletions(-)
 delete mode 100644 drivers/mmc/nds32_mmc.c
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot