[PATCH] ls1021a: Set CONFIG_SYS_BOOTMAPSZ to the memory for relocation

2020-02-02 Thread Alison Wang
This patch sets CONFIG_SYS_BOOTMAPSZ to the amount of memory available
to safely contain a kernel, device tree and initrd for relocation. The
way to set fdt_high as 0x to disable device tree relocation is
removed.

Signed-off-by: Alison Wang 
---
 include/configs/ls1021aiot.h | 5 +++--
 include/configs/ls1021aqds.h | 3 +--
 include/configs/ls1021atsn.h | 3 ++-
 include/configs/ls1021atwr.h | 3 +--
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/configs/ls1021aiot.h b/include/configs/ls1021aiot.h
index 769a7e2..4e3d818 100644
--- a/include/configs/ls1021aiot.h
+++ b/include/configs/ls1021aiot.h
@@ -207,12 +207,13 @@
 
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"bootargs=root=/dev/ram0 rw console=ttyS0,115200\0" \
-"initrd_high=0x\0" \
-"fdt_high=0x\0"
+"initrd_high=0x\0"
 
 /*
  * Miscellaneous configurable options
  */
+#define CONFIG_SYS_BOOTMAPSZ   (256 << 20)
+
 #define CONFIG_CMD_GREPENV
 #define CONFIG_CMD_MEMINFO
 
diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
index 6f1c0d4..5345e8f 100644
--- a/include/configs/ls1021aqds.h
+++ b/include/configs/ls1021aqds.h
@@ -460,13 +460,11 @@ unsigned long get_board_ddr_clk(void);
 #ifdef CONFIG_LPUART
 #define CONFIG_EXTRA_ENV_SETTINGS   \
"bootargs=root=/dev/ram0 rw console=ttyLP0,115200\0" \
-   "fdt_high=0x\0" \
"initrd_high=0x\0"  \
"hwconfig=fsl_ddr:ctlr_intlv=null,bank_intlv=null\0"
 #else
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"bootargs=root=/dev/ram0 rw console=ttyS0,115200\0" \
-   "fdt_high=0x\0" \
"initrd_high=0x\0"  \
"hwconfig=fsl_ddr:ctlr_intlv=null,bank_intlv=null\0"
 #endif
@@ -474,6 +472,7 @@ unsigned long get_board_ddr_clk(void);
 /*
  * Miscellaneous configurable options
  */
+#define CONFIG_SYS_BOOTMAPSZ   (256 << 20)
 
 #define CONFIG_SYS_MEMTEST_START   0x8000
 #define CONFIG_SYS_MEMTEST_END 0x9fff
diff --git a/include/configs/ls1021atsn.h b/include/configs/ls1021atsn.h
index 84fdfce..039c794 100644
--- a/include/configs/ls1021atsn.h
+++ b/include/configs/ls1021atsn.h
@@ -154,7 +154,6 @@
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"bootargs=root=/dev/ram0 rw console=ttyS0,115200\0" \
"initrd_high=0x\0"  \
-   "fdt_high=0x\0" \
"fdt_addr=0x64f0\0" \
"kernel_addr=0x6100\0"  \
"kernelheader_addr=0x6080\0"\
@@ -216,6 +215,8 @@
"bootm $load_addr#$board\0"
 
 /* Miscellaneous configurable options */
+#define CONFIG_SYS_BOOTMAPSZ   (256 << 20)
+
 #define CONFIG_SYS_CBSIZE  256 /* Console I/O Buffer Size */
 #define CONFIG_SYS_PBSIZE  \
(CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16)
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index e845232..511d10a 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -299,7 +299,6 @@
 #define CONFIG_EXTRA_ENV_SETTINGS   \
"bootargs=root=/dev/ram0 rw console=ttyLP0,115200\0" \
"initrd_high=0x\0"  \
-   "fdt_high=0x\0" \
"fdt_addr=0x64f0\0" \
"kernel_addr=0x6500\0"  \
"scriptaddr=0x8000\0"   \
@@ -357,7 +356,6 @@
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"bootargs=root=/dev/ram0 rw console=ttyS0,115200\0" \
"initrd_high=0x\0"  \
-   "fdt_high=0x\0" \
"fdt_addr=0x64f0\0" \
"kernel_addr=0x6100\0"  \
"kernelheader_addr=0x6080\0"\
@@ -441,6 +439,7 @@
 /*
  * Miscellaneous configurable options
  */
+#define CONFIG_SYS_BOOTMAPSZ   (256 << 20)
 
 #define CONFIG_SYS_MEMTEST_START   0x8000
 #define CONFIG_SYS_MEMTEST_END 0x9fff
-- 
2.9.5



Re: [PATCH v2 02/10] mmc: Add init() API

2020-02-02 Thread Michal Simek
On 03. 02. 20 7:04, Sekhar Nori wrote:
> Michal,
> 
> On 30/01/20 9:08 PM, Tom Rini wrote:
>> On Thu, Jan 30, 2020 at 04:35:40PM +0100, Simon Goldschmidt wrote:
>>> Tom Rini  schrieb am Do., 30. Jan. 2020, 16:32:
>>>
 On Thu, Jan 30, 2020 at 04:30:54PM +0100, Michal Simek wrote:
> On 30. 01. 20 16:14, Faiz Abbas wrote:
>> Hi Michal,
>>
>> On 30/01/20 8:37 pm, Michal Simek wrote:
>>> On 30. 01. 20 16:03, Faiz Abbas wrote:
 Hi,

 +Lokesh, Tom

 On 29/01/20 1:37 pm, Simon Goldschmidt wrote:
> Forgot to ask: why isn't the subsystem maintainer on CC?
> If you would use patman to send patches or at least the
 get_maintainer script,
> he would have been...
>

 I did use get_maintainer for my send-email CC list but everyone other
 than Michal seems to have been dropped. Here is an excerpt from the
 email header I received:

 From: Faiz Abbas 
 To: 
 CC: , , <
 lokeshvu...@ti.com>,
   , 
 Subject: [PATCH v2 02/10] mmc: Add init() API
 Date: Fri, 24 Jan 2020 17:22:44 +0530


 But in the patchworks and in your reply, only Michal is remaining:
 https://patchwork.ozlabs.org/patch/1228781/

 Michal,

 What do you see in your message header? Does it have other people
 copied?
>>>
>>> [u-boot]$ ./scripts/get_maintainer.pl -f drivers/mmc/mmc.c
>>> Peng Fan  (maintainer:MMC)
>>> u-boot@lists.denx.de (open list)
>>>
>>> I see Peng there.
>>>
>>
>> You misunderstood. I am not asking if you see Peng in the
 get_maintainer
>> output. Do you see him CC'd in the original patch email?
>
> Nope. I can't see him there.

 Wolfgang, is there some mailman setting that needs tweaking or looking
 at here?  Thanks!

>>>
>>> Can this be a mailman issue? If Michal was CCed, is mailman involved in the
>>> way to him? I would have thought that mail got delivered directly.
>>
>> I was thinking about the setting on if you get your own messages / ones
>> you're on CC to or not, and if that was the copy say in Michal's inbox
>> or U-Boot folder.
> 
> Can you confirm how you received the message, directly or through the list?
> 
> The TI e-mail team says the CCs were not removed prior to leaving TI.

It looks like it went through list.

M


[PATCH 2/2] configs: ls2080ardb: Make BOOTCOMMAND access flash memory as per spi-mem

2020-02-02 Thread Kuldeep Singh
BOOT command currently access spi-nor flash memory directly. As per spi-mem
framework, flash memory access via absolute addresses is no more possible.
Use flash APIs to access memory instead of directly using it.

Signed-off-by: Kuldeep Singh 
---
 include/configs/ls2080ardb.h | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/include/configs/ls2080ardb.h b/include/configs/ls2080ardb.h
index 6a74f62..87d2aeb 100644
--- a/include/configs/ls2080ardb.h
+++ b/include/configs/ls2080ardb.h
@@ -509,9 +509,11 @@ unsigned long get_board_sys_clk(void);
 #ifdef CONFIG_TFABOOT
 #define QSPI_NOR_BOOTCOMMAND   \
"env exists mcinitcmd && env exists secureboot "\
-   "&& esbc_validate 0x2078; " \
+   "&& sf read 0x8078 0x78 0x4 "   \
+   "&& esbc_validate 0x8078; " \
"env exists mcinitcmd && "  \
-   "fsl_mc lazyapply dpl 0x20d0; " \
+   "sf read 0x80d0 0xd0 0x4 && "   \
+   "fsl_mc lazyapply dpl 0x80d0 ; "\
"run distro_bootcmd;run qspi_bootcmd; " \
"env exists secureboot && esbc_halt;"
 
@@ -539,9 +541,11 @@ unsigned long get_board_sys_clk(void);
 /* Try to boot an on-QSPI kernel first, then do normal distro boot */
 #define CONFIG_BOOTCOMMAND \
"env exists mcinitcmd && env exists secureboot "\
-   "&& esbc_validate 0x2078; " \
+   "&& sf read 0x8078 0x78 0x4 "   \
+   "&& esbc_validate 0x8078; " \
"env exists mcinitcmd && "  \
-   "fsl_mc lazyapply dpl 0x20d0; " \
+   "sf read 0x80d0 0xd0 0x4 && "   \
+   "fsl_mc lazyapply dpl 0x80d0; " \
"run distro_bootcmd;run qspi_bootcmd; " \
"env exists secureboot && esbc_halt;"
 #elif defined(CONFIG_SD_BOOT)
-- 
2.7.4



[PATCH 1/2] configs: ls2080ardb: Make QSPI_MC_INIT access flash memory as per spi-mem

2020-02-02 Thread Kuldeep Singh
MC_INIT command currently access spi-nor flash memory directly. As per
spi-mem framework, flash memory access via absolute addresses is no more
possible. Use flash APIs to access memory instead of directly using it.

Signed-off-by: Kuldeep Singh 
---
 include/configs/ls2080ardb.h | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/include/configs/ls2080ardb.h b/include/configs/ls2080ardb.h
index de14fb4..6a74f62 100644
--- a/include/configs/ls2080ardb.h
+++ b/include/configs/ls2080ardb.h
@@ -322,10 +322,14 @@ unsigned long get_board_sys_clk(void);
 
 #ifdef CONFIG_TFABOOT
 #define QSPI_MC_INIT_CMD   \
+   "sf probe 0:0; sf read 0x80A0 0xA0 0x10; "  \
+   "sf read 0x80E0 0xE0 0x10; "\
"env exists secureboot && " \
-   "esbc_validate 0x2070 && "  \
-   "esbc_validate 0x2074;" \
-   "fsl_mc start mc 0x20a0 0x20e0 \0"
+   "sf read 0x8070 0x70 0x4 && "   \
+   "sf read 0x8074 0x74 0x4 && "   \
+   "esbc_validate 0x8070 && "  \
+   "esbc_validate 0x8074; "\
+   "fsl_mc start mc 0x80A0 0x80E0 \0"
 #define SD_MC_INIT_CMD \
"mmcinfo;mmc read 0x80a0 0x5000 0x1200;" \
"mmc read 0x80e0 0x7000 0x800;" \
@@ -343,10 +347,14 @@ unsigned long get_board_sys_clk(void);
 #else
 #ifdef CONFIG_QSPI_BOOT
 #define MC_INIT_CMD\
-   "mcinitcmd=env exists secureboot && "   \
-   "esbc_validate 0x2070 && "  \
-   "esbc_validate 0x2074;" \
-   "fsl_mc start mc 0x20a0 0x20e0 \0"
+   "mcinitcmd=sf probe 0:0;sf read 0x80A0 0xA0 0x10; " \
+   " sf read 0x80E0 0xE0 0x10; "   \
+   "env exists secureboot && " \
+   "sf read 0x8070 0x70 0x4 && "   \
+   "sf read 0x8074 0x74 0x4 && "   \
+   "esbc_validate 0x8070 && "  \
+   "esbc_validate 0x8074; "\
+   "fsl_mc start mc 0x80A0 0x80E0 \0"
 #elif defined(CONFIG_SD_BOOT)
 #define MC_INIT_CMD \
"mcinitcmd=mmcinfo;mmc read 0x8000 0x5000 0x800;" \
-- 
2.7.4



Re: [PATCH v2 02/10] mmc: Add init() API

2020-02-02 Thread Sekhar Nori
Michal,

On 30/01/20 9:08 PM, Tom Rini wrote:
> On Thu, Jan 30, 2020 at 04:35:40PM +0100, Simon Goldschmidt wrote:
>> Tom Rini  schrieb am Do., 30. Jan. 2020, 16:32:
>>
>>> On Thu, Jan 30, 2020 at 04:30:54PM +0100, Michal Simek wrote:
 On 30. 01. 20 16:14, Faiz Abbas wrote:
> Hi Michal,
>
> On 30/01/20 8:37 pm, Michal Simek wrote:
>> On 30. 01. 20 16:03, Faiz Abbas wrote:
>>> Hi,
>>>
>>> +Lokesh, Tom
>>>
>>> On 29/01/20 1:37 pm, Simon Goldschmidt wrote:
 Forgot to ask: why isn't the subsystem maintainer on CC?
 If you would use patman to send patches or at least the
>>> get_maintainer script,
 he would have been...

>>>
>>> I did use get_maintainer for my send-email CC list but everyone other
>>> than Michal seems to have been dropped. Here is an excerpt from the
>>> email header I received:
>>>
>>> From: Faiz Abbas 
>>> To: 
>>> CC: , , <
>>> lokeshvu...@ti.com>,
>>>   , 
>>> Subject: [PATCH v2 02/10] mmc: Add init() API
>>> Date: Fri, 24 Jan 2020 17:22:44 +0530
>>>
>>>
>>> But in the patchworks and in your reply, only Michal is remaining:
>>> https://patchwork.ozlabs.org/patch/1228781/
>>>
>>> Michal,
>>>
>>> What do you see in your message header? Does it have other people
>>> copied?
>>
>> [u-boot]$ ./scripts/get_maintainer.pl -f drivers/mmc/mmc.c
>> Peng Fan  (maintainer:MMC)
>> u-boot@lists.denx.de (open list)
>>
>> I see Peng there.
>>
>
> You misunderstood. I am not asking if you see Peng in the
>>> get_maintainer
> output. Do you see him CC'd in the original patch email?

 Nope. I can't see him there.
>>>
>>> Wolfgang, is there some mailman setting that needs tweaking or looking
>>> at here?  Thanks!
>>>
>>
>> Can this be a mailman issue? If Michal was CCed, is mailman involved in the
>> way to him? I would have thought that mail got delivered directly.
> 
> I was thinking about the setting on if you get your own messages / ones
> you're on CC to or not, and if that was the copy say in Michal's inbox
> or U-Boot folder.

Can you confirm how you received the message, directly or through the list?

The TI e-mail team says the CCs were not removed prior to leaving TI.

Thanks,
Sekhar


Re: [PATCH 3/3] gpio: intel_gpio: Fix register/bit offsets intel_gpio_get_value()

2020-02-02 Thread Bin Meng
On Fri, Jan 10, 2020 at 3:35 PM Wolfgang Wallner
 wrote:
>
> Fix the following in intel_gpio_get_value():
>
>  * The value of the register is contained in the variable 'reg', not in
>'mode'. The variable 'mode' contains only the configuration whether
>the gpio is currently an input or an output.
>
>  * The correct bitmasks for the input and output value are
>PAD_CFG0_RX_STATE and PAD_CFG0_TX_STATE.
>Use them instead of the currently used PAD_CFG0_RX_STATE_BIT and
>PAD_CFG0_TX_STATE_BIT.
>
> Signed-off-by: Wolfgang Wallner 
>
> ---
>
>  drivers/gpio/intel_gpio.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH 2/3] gpio: intel_gpio: Clear tx state bit when setting output

2020-02-02 Thread Bin Meng
On Fri, Jan 10, 2020 at 3:35 PM Wolfgang Wallner
 wrote:
>
> Add missing 'PAD_CFG0_TX_STATE' to the clear mask for pcr_clrsetbits32().
> Otherwise this bit cannot be cleared again after it has been set once.
>
> Signed-off-by: Wolfgang Wallner 
> ---
>
>  drivers/gpio/intel_gpio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH v2 2/2] gpio: search for gpio label if gpio is not found through bank name

2020-02-02 Thread Heiko Schocher

Hello Simon,

Am 03.02.2020 um 01:04 schrieb Simon Glass:

On Sat, 1 Feb 2020 at 01:03, Heiko Schocher  wrote:


dm_gpio_lookup_name() searches for a gpio through
the bank name. But we have also gpio labels, and it
makes sense to search for a gpio also in the labels
we have defined, if no gpio is found through the
bank name definition.

This is useful for example if you have a wp pin on
different gpios on different board versions.

If dm_gpio_lookup_name() searches also for the gpio labels,
you can give the gpio an unique label name and search
for this label, and do not need to differ between
board revisions.

Signed-off-by: Heiko Schocher 
---

Example on the aristainetos board:

=> gpio clear wp_spi_nor.gpio-hog
gpio: pin wp_spi_nor.gpio-hog (gpio 47) value is 0
=>

before this patch, you need to know where your
pin is:

=> gpio clear GPIO2_15
gpio: pin GPIO2_15 (gpio 47) value is 0
=>

travis build:

Changes in v2:
- add comment from Simon Glass
   move code into seperate function dm_gpio_lookup_label()
   add test if dm_gpio_lookup_label() works

  drivers/gpio/gpio-uclass.c | 38 ++
  test/dm/gpio.c |  7 +++
  2 files changed, 45 insertions(+)


Reviewed-by: Simon Glass 

I wonder if this should be a Kconfig so we can disable it by default in SPL?


Hmm.. maybe a good idea for boards which have code size restrictions.
On the other hand, on such boards DM/DTS is most likely no option?

But it should be easy to add this into a Kconfig option, proposal

DM_GPIO_LOOKUP_LABEL ?

default: n for SPL and U-Boot ?

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


Re: [PATCH 1/3] gpio: intel_gpio: Pass pinctrl device to pcr_clrsetbits32()

2020-02-02 Thread Bin Meng
Hi Wolfgang,

On Fri, Jan 10, 2020 at 3:35 PM Wolfgang Wallner
 wrote:
>
> The function pcr_clrsetbits32() expects a device with a P2SB parent
> device.
>
> The currently passed device 'dev' is a gpio-controller with a device
> 'pinctrl' as parent. This does not match the expectations of
> pcr_clrsetbits32(). But he 'pinctrl'-device has a P2SB as parent.

typo: the 'pinctrl' device

>
> Pass the 'pinctrl' device instead of the 'dev' device to
> pcr_clrsetbits32().
>
> Signed-off-by: Wolfgang Wallner 
> ---
>
>  drivers/gpio/intel_gpio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/intel_gpio.c b/drivers/gpio/intel_gpio.c
> index 4bf1c9ddc4..db63115628 100644
> --- a/drivers/gpio/intel_gpio.c
> +++ b/drivers/gpio/intel_gpio.c
> @@ -39,7 +39,7 @@ static int intel_gpio_direction_output(struct udevice *dev, 
> uint offset,
> struct udevice *pinctrl = dev_get_parent(dev);
> uint config_offset = intel_pinctrl_get_config_reg_addr(pinctrl, 
> offset);
>
> -   pcr_clrsetbits32(dev, config_offset,
> +   pcr_clrsetbits32(pinctrl, config_offset,
>  PAD_CFG0_MODE_MASK | PAD_CFG0_RX_STATE |
>   PAD_CFG0_TX_DISABLE,
>  PAD_CFG0_MODE_GPIO | PAD_CFG0_RX_DISABLE |

Reviewed-by: Bin Meng 

But I think we should also fix intel_gpio_set_value() where dev is
passed instead of pinctrl.

Regards,
Bin


Re: [RFC] azure: Move to vs2017-win2016 platform build host

2020-02-02 Thread Bin Meng
On Mon, Feb 3, 2020 at 10:05 AM Bin Meng  wrote:
>
> Hi Tom,
>
> On Tue, Jan 28, 2020 at 5:23 AM Tom Rini  wrote:
> >
> > Azure is moving to remove the vs2015-win2012r2 platform build host.  The
> > two suggested new platforms to use are vs2017-win2016 and windows-2019.
> > For now, move up to vs2017-win2016.
> >
> > Cc: Bin Meng 
> > Signed-off-by: Tom Rini 
> > ---
> > I'm sending this as RFC as it fails to build for i686 but builds for
> > x86_64 and I'm out of my depth on fixing that.  Can you please take a
> > look Bin?  Thanks!
>
> I've looked at this issue. It was probably caused by the upstream
> MSYS2 Windows binary has not been updated to work with win2016 yet.
>
> I tried this patch today, and the Windows host tools build looks goood. See:
> https://dev.azure.com/bmeng/GitHub/_build/results?buildId=151=results

All Azure builds passed

Tested-by: Bin Meng 

I see this patch was assigned to me on patchwork, I will take this
patch via the x86 tree.

Regards,
Bin


Re: [PATCH v1 2/2] x86: edison: Switch to ACPI mode

2020-02-02 Thread Bin Meng
On Mon, Feb 3, 2020 at 12:59 PM Bin Meng  wrote:
>
> On Fri, Jan 10, 2020 at 5:12 AM Andy Shevchenko
>  wrote:
> >
> > SFI is quite poor and useless resource provider. Moreover it makes hard
> > to develop and extend functionality in the Linux kernel.
> >
> > Enable a necessary minimum to use ACPI on Intel Edison.
> >
> > Linux kernel have been prepared for this change since v5.4, where the last
> > crucial driver, i.e. for Basin Cove PMIC, has been submitted.
> >
> > Note, that stock image won't suffer by this change since it doesn't have
> > ACPI enabled on the kernel level.
> >
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  configs/edison_defconfig | 1 +
> >  1 file changed, 1 insertion(+)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH v1 1/2] x86: edison: Enable command line editing

2020-02-02 Thread Bin Meng
On Mon, Feb 3, 2020 at 12:57 PM Bin Meng  wrote:
>
> On Fri, Jan 10, 2020 at 5:12 AM Andy Shevchenko
>  wrote:
> >
> > From: Marek Vasut 
> >
> > Enable command line editing, because it is extremely convenient.
> >
> > Signed-off-by: Marek Vasut 
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  configs/edison_defconfig | 1 -
> >  1 file changed, 1 deletion(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH v1 2/2] x86: edison: Switch to ACPI mode

2020-02-02 Thread Bin Meng
On Thu, Jan 30, 2020 at 10:17 AM Simon Glass  wrote:
>
> On Wed, 29 Jan 2020 at 09:16, Andy Shevchenko
>  wrote:
> >
> > On Thu, Jan 09, 2020 at 11:12:35PM +0200, Andy Shevchenko wrote:
> > > SFI is quite poor and useless resource provider. Moreover it makes hard
> > > to develop and extend functionality in the Linux kernel.
> > >
> > > Enable a necessary minimum to use ACPI on Intel Edison.
> > >
> > > Linux kernel have been prepared for this change since v5.4, where the last
> > > crucial driver, i.e. for Basin Cove PMIC, has been submitted.
> > >
> > > Note, that stock image won't suffer by this change since it doesn't have
> > > ACPI enabled on the kernel level.
> >
> > Bin, Simon, can we get these into 2020.04?
>
> +Tom Rini FYI
>
> Reviewed-by: Simon Glass 
>
> I hope so. There's a small mountain of pending x86 patches. I think
> Bin is probably away until next week?

I was off for the Chinese new year holiday vacation, and there was the
2019-nCov epidemic situation going on that further delayed things :(

I will pick up patches that make sense for v2020.04 release.

Regards,
Bin


Re: [PATCH v1 2/2] x86: edison: Switch to ACPI mode

2020-02-02 Thread Bin Meng
On Fri, Jan 10, 2020 at 5:12 AM Andy Shevchenko
 wrote:
>
> SFI is quite poor and useless resource provider. Moreover it makes hard
> to develop and extend functionality in the Linux kernel.
>
> Enable a necessary minimum to use ACPI on Intel Edison.
>
> Linux kernel have been prepared for this change since v5.4, where the last
> crucial driver, i.e. for Basin Cove PMIC, has been submitted.
>
> Note, that stock image won't suffer by this change since it doesn't have
> ACPI enabled on the kernel level.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  configs/edison_defconfig | 1 +
>  1 file changed, 1 insertion(+)
>

Reviewed-by: Bin Meng 


Re: [PATCH v1 1/2] x86: edison: Enable command line editing

2020-02-02 Thread Bin Meng
On Fri, Jan 10, 2020 at 5:12 AM Andy Shevchenko
 wrote:
>
> From: Marek Vasut 
>
> Enable command line editing, because it is extremely convenient.
>
> Signed-off-by: Marek Vasut 
> Signed-off-by: Andy Shevchenko 
> ---
>  configs/edison_defconfig | 1 -
>  1 file changed, 1 deletion(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH 1/1] doc: Chromebook Coral: fix build warnings

2020-02-02 Thread Bin Meng
On Mon, Feb 3, 2020 at 12:54 PM Bin Meng  wrote:
>
> On Fri, Jan 10, 2020 at 3:33 AM Heinrich Schuchardt  
> wrote:
> >
> > Use valid restructured text to avoid warnings like
> >
> > WARNING: Title underline too short.
> > WARNING: Block quote ends without a blank line; unexpected unindent.
> >
> > when building with `make htmldocs`.
> >
> > Signed-off-by: Heinrich Schuchardt 
> > ---
> >  doc/board/google/chromebook_coral.rst | 90 ++-
> >  1 file changed, 46 insertions(+), 44 deletions(-)
> >
>
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH 1/1] doc: Chromebook Coral: fix build warnings

2020-02-02 Thread Bin Meng
On Fri, Jan 10, 2020 at 3:33 AM Heinrich Schuchardt  wrote:
>
> Use valid restructured text to avoid warnings like
>
> WARNING: Title underline too short.
> WARNING: Block quote ends without a blank line; unexpected unindent.
>
> when building with `make htmldocs`.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  doc/board/google/chromebook_coral.rst | 90 ++-
>  1 file changed, 46 insertions(+), 44 deletions(-)
>

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


Re: [PATCH] x86: limit the fs segment to the pointer size

2020-02-02 Thread Bin Meng
On Mon, Feb 3, 2020 at 12:41 PM Bin Meng  wrote:
>
> On Wed, Jan 8, 2020 at 7:14 PM Masahiro Yamada  wrote:
> >
> > The fs segment is only used to get the global data pointer.
> > If it is accessed beyond sizeof(new_gd->arch.gd_addr), it is a bug.
> >
> > To specify the byte-granule limit size, drop the G bit, so the
> > flag field is 0x8093 instead of 0xc093, and set the limit field
> > to sizeof(new_gd->arch.gd_addr) - 1.
> >
> > Signed-off-by: Masahiro Yamada 
> > ---
> >
> >  arch/x86/cpu/i386/cpu.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/cpu/i386/cpu.c b/arch/x86/cpu/i386/cpu.c
> > index 2b27617ca3a4..72fefdd3adca 100644
> > --- a/arch/x86/cpu/i386/cpu.c
> > +++ b/arch/x86/cpu/i386/cpu.c
> > @@ -137,8 +137,9 @@ void arch_setup_gd(gd_t *new_gd)
> >
> > /* FS: data, read/write, 4 GB, base (Global Data Pointer) */
>
> nits: this comment should be updated too

Fixed the comments, and

>
> > new_gd->arch.gd_addr = new_gd;
> > -   gdt_addr[X86_GDT_ENTRY_32BIT_FS] = GDT_ENTRY(0xc093,
> > -(ulong)_gd->arch.gd_addr, 0xf);
> > +   gdt_addr[X86_GDT_ENTRY_32BIT_FS] = GDT_ENTRY(0x8093,
> > +   (ulong)_gd->arch.gd_addr,
> > +   sizeof(new_gd->arch.gd_addr) - 1);
> >
> > /* 16-bit CS: code, read/execute, 64 kB, base 0 */
> > gdt_addr[X86_GDT_ENTRY_16BIT_CS] = GDT_ENTRY(0x009b, 0, 0x0);
> > --
>
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH] x86: use invd instead of wbinvd in real mode start code

2020-02-02 Thread Bin Meng
On Mon, Feb 3, 2020 at 12:41 PM Bin Meng  wrote:
>
> On Wed, Jan 8, 2020 at 7:09 PM Masahiro Yamada  wrote:
> >
> > I do not know why the boot code immediately after the system reset
> > should write-back the cache content. I think the cache invalidation
> > should be enough.
> >
> > I tested this commit with qemu-x86_defconfig, and it worked for me.
> >
> > Signed-off-by: Masahiro Yamada 
> > ---
> >
> >  arch/x86/cpu/start.S   | 2 +-
> >  arch/x86/cpu/start16.S | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
>
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH] x86: limit the fs segment to the pointer size

2020-02-02 Thread Bin Meng
On Wed, Jan 8, 2020 at 7:14 PM Masahiro Yamada  wrote:
>
> The fs segment is only used to get the global data pointer.
> If it is accessed beyond sizeof(new_gd->arch.gd_addr), it is a bug.
>
> To specify the byte-granule limit size, drop the G bit, so the
> flag field is 0x8093 instead of 0xc093, and set the limit field
> to sizeof(new_gd->arch.gd_addr) - 1.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  arch/x86/cpu/i386/cpu.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/cpu/i386/cpu.c b/arch/x86/cpu/i386/cpu.c
> index 2b27617ca3a4..72fefdd3adca 100644
> --- a/arch/x86/cpu/i386/cpu.c
> +++ b/arch/x86/cpu/i386/cpu.c
> @@ -137,8 +137,9 @@ void arch_setup_gd(gd_t *new_gd)
>
> /* FS: data, read/write, 4 GB, base (Global Data Pointer) */

nits: this comment should be updated too

> new_gd->arch.gd_addr = new_gd;
> -   gdt_addr[X86_GDT_ENTRY_32BIT_FS] = GDT_ENTRY(0xc093,
> -(ulong)_gd->arch.gd_addr, 0xf);
> +   gdt_addr[X86_GDT_ENTRY_32BIT_FS] = GDT_ENTRY(0x8093,
> +   (ulong)_gd->arch.gd_addr,
> +   sizeof(new_gd->arch.gd_addr) - 1);
>
> /* 16-bit CS: code, read/execute, 64 kB, base 0 */
> gdt_addr[X86_GDT_ENTRY_16BIT_CS] = GDT_ENTRY(0x009b, 0, 0x0);
> --

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


Re: [PATCH] x86: use invd instead of wbinvd in real mode start code

2020-02-02 Thread Bin Meng
On Wed, Jan 8, 2020 at 7:09 PM Masahiro Yamada  wrote:
>
> I do not know why the boot code immediately after the system reset
> should write-back the cache content. I think the cache invalidation
> should be enough.
>
> I tested this commit with qemu-x86_defconfig, and it worked for me.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  arch/x86/cpu/start.S   | 2 +-
>  arch/x86/cpu/start16.S | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>

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


Re: [PATCH 4/4] wdt: Add DM support for Designware WDT

2020-02-02 Thread Simon Glass
On Sun, 2 Feb 2020 at 18:18, Sean Anderson  wrote:
>
> On 2/2/20 7:04 PM, Simon Glass wrote:
> > Hi Sean,
> >
> > On Sun, 2 Feb 2020 at 10:25, Sean Anderson  wrote:
> >>
> >> On 2/2/20 12:13 PM, Sean Anderson wrote:
> >>> The binding used is the same as Linux's.
> >>> ---
> >>>  doc/device-tree-bindings/watchdog/dw_wdt.txt | 24 +++
> >>>  drivers/watchdog/designware_wdt.c| 67 
> >>>  2 files changed, 91 insertions(+)
> >>>  create mode 100644 doc/device-tree-bindings/watchdog/dw_wdt.txt
> >>
> >> Signed-off-by: Sean Anderson 
> >
> > Are you adding this to the Makefile somewhere?
>
> I'm not sure what you mean. This is optionally used in [1], but I didn't
> want to add an explicit dependency. However, this appears to be a bit of
> a duplicate effort in light of [2].

OK, thanks.

Reviewed-by: Simon Glass 


>
> [1] https://patchwork.ozlabs.org/project/uboot/list/?series=156389
> [2] https://patchwork.ozlabs.org/patch/1232414/
>
> --Sean


Re: [PATCH 2/2] doc: intel: Update serial driver changes in slimbootloader.rst

2020-02-02 Thread Bin Meng
On Mon, Feb 3, 2020 at 10:43 AM Bin Meng  wrote:
>
> On Wed, Dec 18, 2019 at 1:56 PM Park, Aiden  wrote:
> >
> > Now, Slim Bootloader uses NS16550_DYNAMIC to support serial port
> > configuration at runtime, so no more code change is required.
> > Therefore, remove unnecessary steps and fix minor typo.
> >
> > Signed-off-by: Aiden Park 
> > ---
> >  doc/board/intel/slimbootloader.rst | 35 +++---
> >  1 file changed, 8 insertions(+), 27 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH 1/2] x86: serial: Use NS16550_DYNAMIC in Slim Bootloader

2020-02-02 Thread Bin Meng
On Mon, Feb 3, 2020 at 10:43 AM Bin Meng  wrote:
>
> Hi Aiden,
>
> On Wed, Dec 18, 2019 at 1:56 PM Park, Aiden  wrote:
> >
> > Slim Bootloader provides serial port info in its HOB to support
> > both IO or MMIO serial ports, but it's controlled by SYS_NS16550_MEM32
> > or SYS_NS16550_PORT_MAPPED in U-Boot.
> > To support both serial port configurations dynamically at runtime,
> > Slim Bootloader serial driver leverages NS16550_DYNAMIC.
> >
> > Signed-off-by: Aiden Park 
> > ---
> >  arch/x86/cpu/slimbootloader/serial.c |  5 +
> >  include/configs/slimbootloader.h | 13 -
> >  2 files changed, 5 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/x86/cpu/slimbootloader/serial.c 
> > b/arch/x86/cpu/slimbootloader/serial.c
> > index 7b44a59bff..0f45b3ba72 100644
> > --- a/arch/x86/cpu/slimbootloader/serial.c
> > +++ b/arch/x86/cpu/slimbootloader/serial.c
> > @@ -45,7 +45,12 @@ static int 
> > slimbootloader_serial_ofdata_to_platdata(struct udevice *dev)
> > plat->base = data->base;
> > /* ns16550 uses reg_shift, then covert stride to shift */
> > plat->reg_shift = data->stride >> 1;
> > +   plat->reg_width = data->stride;
> > plat->clock = data->clk;
> > +   plat->fcr = UART_FCR_DEFVAL;
> > +   plat->flags = 0;
> > +   if (data->type == 1)
> > +   plat->flags |= NS16550_FLAG_IO;
>
> nits: the following comments in this function should be removed:
>
> /*
> * The data->type provides port io or mmio access type info,
> * but the access type will be controlled by
> * CONFIG_SYS_NS16550_PORT_MAPPED or CONFIG_SYS_NS16550_MEM32.
> *
> * TBD: ns16550 access type configuration in runtime.
> *  ex) plat->access_type = data->type
> */
>

Removed these obsolete comments, and

> >
> > return 0;
> >  }
> > diff --git a/include/configs/slimbootloader.h 
> > b/include/configs/slimbootloader.h
> > index e0011ed446..b8169072cc 100644
> > --- a/include/configs/slimbootloader.h
> > +++ b/include/configs/slimbootloader.h
> > @@ -8,19 +8,6 @@
> >
> >  #include 
> >
> > -/*
> > - * By default, CONFIG_SYS_NS16550_PORT_MAPPED is enabled for port io 
> > serial.
> > - * To use mmio base serial, enable CONFIG_SYS_NS16550_MEM32 and disable
> > - * CONFIG_SYS_NS16550_PORT_MAPPED until ns16550 driver supports serial port
> > - * configuration in run-time.
> > - *
> > - * #define CONFIG_SYS_NS16550_MEM32
> > - * #undef CONFIG_SYS_NS16550_PORT_MAPPED
> > - */
> > -#ifdef CONFIG_SYS_NS16550_MEM32
> > -#undef CONFIG_SYS_NS16550_PORT_MAPPED
> > -#endif
> > -
> >  #define CONFIG_STD_DEVICES_SETTINGS\
> > "stdin=serial,i8042-kbd,usbkbd\0"   \
> > "stdout=serial\0"   \
> > --
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH 1/2] x86: serial: Use NS16550_DYNAMIC in Slim Bootloader

2020-02-02 Thread Bin Meng
Hi Aiden,

On Wed, Dec 18, 2019 at 1:56 PM Park, Aiden  wrote:
>
> Slim Bootloader provides serial port info in its HOB to support
> both IO or MMIO serial ports, but it's controlled by SYS_NS16550_MEM32
> or SYS_NS16550_PORT_MAPPED in U-Boot.
> To support both serial port configurations dynamically at runtime,
> Slim Bootloader serial driver leverages NS16550_DYNAMIC.
>
> Signed-off-by: Aiden Park 
> ---
>  arch/x86/cpu/slimbootloader/serial.c |  5 +
>  include/configs/slimbootloader.h | 13 -
>  2 files changed, 5 insertions(+), 13 deletions(-)
>
> diff --git a/arch/x86/cpu/slimbootloader/serial.c 
> b/arch/x86/cpu/slimbootloader/serial.c
> index 7b44a59bff..0f45b3ba72 100644
> --- a/arch/x86/cpu/slimbootloader/serial.c
> +++ b/arch/x86/cpu/slimbootloader/serial.c
> @@ -45,7 +45,12 @@ static int slimbootloader_serial_ofdata_to_platdata(struct 
> udevice *dev)
> plat->base = data->base;
> /* ns16550 uses reg_shift, then covert stride to shift */
> plat->reg_shift = data->stride >> 1;
> +   plat->reg_width = data->stride;
> plat->clock = data->clk;
> +   plat->fcr = UART_FCR_DEFVAL;
> +   plat->flags = 0;
> +   if (data->type == 1)
> +   plat->flags |= NS16550_FLAG_IO;

nits: the following comments in this function should be removed:

/*
* The data->type provides port io or mmio access type info,
* but the access type will be controlled by
* CONFIG_SYS_NS16550_PORT_MAPPED or CONFIG_SYS_NS16550_MEM32.
*
* TBD: ns16550 access type configuration in runtime.
*  ex) plat->access_type = data->type
*/

>
> return 0;
>  }
> diff --git a/include/configs/slimbootloader.h 
> b/include/configs/slimbootloader.h
> index e0011ed446..b8169072cc 100644
> --- a/include/configs/slimbootloader.h
> +++ b/include/configs/slimbootloader.h
> @@ -8,19 +8,6 @@
>
>  #include 
>
> -/*
> - * By default, CONFIG_SYS_NS16550_PORT_MAPPED is enabled for port io serial.
> - * To use mmio base serial, enable CONFIG_SYS_NS16550_MEM32 and disable
> - * CONFIG_SYS_NS16550_PORT_MAPPED until ns16550 driver supports serial port
> - * configuration in run-time.
> - *
> - * #define CONFIG_SYS_NS16550_MEM32
> - * #undef CONFIG_SYS_NS16550_PORT_MAPPED
> - */
> -#ifdef CONFIG_SYS_NS16550_MEM32
> -#undef CONFIG_SYS_NS16550_PORT_MAPPED
> -#endif
> -
>  #define CONFIG_STD_DEVICES_SETTINGS\
> "stdin=serial,i8042-kbd,usbkbd\0"   \
> "stdout=serial\0"   \
> --

Reviewed-by: Bin Meng 

Regards,
Bin


Re: [PATCH 2/2] doc: intel: Update serial driver changes in slimbootloader.rst

2020-02-02 Thread Bin Meng
On Wed, Dec 18, 2019 at 1:56 PM Park, Aiden  wrote:
>
> Now, Slim Bootloader uses NS16550_DYNAMIC to support serial port
> configuration at runtime, so no more code change is required.
> Therefore, remove unnecessary steps and fix minor typo.
>
> Signed-off-by: Aiden Park 
> ---
>  doc/board/intel/slimbootloader.rst | 35 +++---
>  1 file changed, 8 insertions(+), 27 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH v3 4/4] x86: Move coreboot over to use the coreboot UART

2020-02-02 Thread Bin Meng
On Fri, Dec 20, 2019 at 8:58 AM Simon Glass  wrote:
>
> Use this UART to improve the compatibility of U-Boot when used as a
> coreboot payload.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/dts/coreboot.dts | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>

applied to u-boot-x86, thanks!


Re: [PATCH v3 3/4] x86: serial: Add a coreboot serial driver

2020-02-02 Thread Bin Meng
On Fri, Dec 20, 2019 at 8:58 AM Simon Glass  wrote:
>
> Coreboot can provide information about the serial device in use on a
> platform. Add a driver that uses this information to produce a working
> UART.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  drivers/serial/Kconfig   | 11 
>  drivers/serial/Makefile  |  1 +
>  drivers/serial/serial_coreboot.c | 46 
>  3 files changed, 58 insertions(+)
>  create mode 100644 drivers/serial/serial_coreboot.c
>

applied to u-boot-x86, thanks!


Re: [PATCH v3 1/4] serial: ns16550: Support run-time configuration

2020-02-02 Thread Bin Meng
On Mon, Feb 3, 2020 at 10:29 AM Bin Meng  wrote:
>
> On Fri, Dec 20, 2019 at 8:58 AM Simon Glass  wrote:
> >
> > At present this driver uses an assortment of CONFIG options to control
> > how it accesses the hardware. This is painful for platforms that are
> > supposed to be controlled by a device tree or a previous-stage bootloader.
> >
> > Add a new CONFIG option to enable fully dynamic configuration. This
> > controls register spacing, size, offset and endianness.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v3:
> > - Rewrite the conditional logic to a fix a bug and match serial_xx_shift()
> > - Add a separate flag for whether to use endian-aware out() functions
> >
> > Changes in v2:
> > - runtime -> run-time
> > - Enable run-time config for slimbootloader too
> > - Improve Kconfig help based on Bin's comments
> > - Use ns16550 in patch subject
> >
> >  drivers/serial/Kconfig   | 21 ++
> >  drivers/serial/ns16550.c | 59 ++--
> >  include/ns16550.h| 16 ++-
> >  3 files changed, 87 insertions(+), 9 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH v3 2/4] x86: Update coreboot serial table struct

2020-02-02 Thread Bin Meng
On Fri, Dec 20, 2019 at 8:58 AM Simon Glass  wrote:
>
> Since mid 2016, coreboot has additional fields in the serial struct that
> it passes down to U-Boot. Add these so we are in sync.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/include/asm/coreboot_tables.h | 19 +++
>  1 file changed, 19 insertions(+)
>

applied to u-boot-x86, thanks!


Re: [PATCH v3 1/4] serial: ns16550: Support run-time configuration

2020-02-02 Thread Bin Meng
On Fri, Dec 20, 2019 at 8:58 AM Simon Glass  wrote:
>
> At present this driver uses an assortment of CONFIG options to control
> how it accesses the hardware. This is painful for platforms that are
> supposed to be controlled by a device tree or a previous-stage bootloader.
>
> Add a new CONFIG option to enable fully dynamic configuration. This
> controls register spacing, size, offset and endianness.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3:
> - Rewrite the conditional logic to a fix a bug and match serial_xx_shift()
> - Add a separate flag for whether to use endian-aware out() functions
>
> Changes in v2:
> - runtime -> run-time
> - Enable run-time config for slimbootloader too
> - Improve Kconfig help based on Bin's comments
> - Use ns16550 in patch subject
>
>  drivers/serial/Kconfig   | 21 ++
>  drivers/serial/ns16550.c | 59 ++--
>  include/ns16550.h| 16 ++-
>  3 files changed, 87 insertions(+), 9 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [RFC] azure: Move to vs2017-win2016 platform build host

2020-02-02 Thread Bin Meng
Hi Simon,

On Tue, Jan 28, 2020 at 5:34 AM Simon Goldschmidt
 wrote:
>
> Tom Rini  schrieb am Mo., 27. Jan. 2020, 22:23:
>
> > Azure is moving to remove the vs2015-win2012r2 platform build host.  The
> > two suggested new platforms to use are vs2017-win2016 and windows-2019.
> > For now, move up to vs2017-win2016.
> >
> > Cc: Bin Meng 
> > Signed-off-by: Tom Rini 
> > ---
> > I'm sending this as RFC as it fails to build for i686 but builds for
> > x86_64 and I'm out of my depth on fixing that.  Can you please take a
> > look Bin?  Thanks!
> >
>
> Is this build publicly available? I just failed to find it, having no
> experience with azure whatsoever...
>

Yes it's publicly available and free service to open source projects.

You need a Microsoft account, and in your github account, search Azure
pipelines from the github marketplace and install it to your github
account.
It will prompt you to the Azure pipeline website and prompt you to log
in using your Microsoft account. Follow the instructions then. Good
luck.

Regards,
Bin


Re: [RFC] azure: Move to vs2017-win2016 platform build host

2020-02-02 Thread Bin Meng
Hi Tom,

On Tue, Jan 28, 2020 at 5:23 AM Tom Rini  wrote:
>
> Azure is moving to remove the vs2015-win2012r2 platform build host.  The
> two suggested new platforms to use are vs2017-win2016 and windows-2019.
> For now, move up to vs2017-win2016.
>
> Cc: Bin Meng 
> Signed-off-by: Tom Rini 
> ---
> I'm sending this as RFC as it fails to build for i686 but builds for
> x86_64 and I'm out of my depth on fixing that.  Can you please take a
> look Bin?  Thanks!

I've looked at this issue. It was probably caused by the upstream
MSYS2 Windows binary has not been updated to work with win2016 yet.

I tried this patch today, and the Windows host tools build looks goood. See:
https://dev.azure.com/bmeng/GitHub/_build/results?buildId=151=results

> ---
>  .azure-pipelines.yml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> index 916ab84ea0c4..a0713dd66c0a 100644
> --- a/.azure-pipelines.yml
> +++ b/.azure-pipelines.yml
> @@ -1,5 +1,5 @@
>  variables:
> -  windows_vm: vs2015-win2012r2
> +  windows_vm: vs2017-win2016
>ubuntu_vm: ubuntu-18.04
>ci_runner_image: trini/u-boot-gitlab-ci-runner:bionic-20200112-17Jan2020
># Add '-u 0' options for Azure pipelines, otherwise we get "permission
> --

Reviewed-by: Bin Meng 

Regards,
Bin


RE: [PATCH 02/21] dm: pci: Update the PCI read_config() method to const dev *

2020-02-02 Thread Tan, Ley Foon



> -Original Message-
> From: Simon Glass 
> Sent: Monday, January 27, 2020 11:50 PM
> To: U-Boot Mailing List 
> Cc: Simon Glass ; Alex Marginean
> ; Bao Xiaowei ; Bin
> Meng ; Frank Wunderlich ;
> GSS_MTK_Uboot_upstream ;
> Heiko Schocher ; Hou Zhiqiang ;
> Jaehoon Chung ; Tan, Ley Foon
> ; Marek BehĂșn ; Marek
> Vasut ; Marek Vasut
> ; Michael Walle ; Michal
> Simek ; Pankaj Bansal ;
> Pavel Herrmann ; Prabhakar Kushwaha
> ; Priyanka Jain ;
> Ramon Fried ; Ryder Lee
> ; Sekhar Nori ; Stefan Roese
> ; Thierry Reding ; Wasim Khan
> ; Weijie Gao ; liuhao
> ; shuyiqi 
> Subject: [PATCH 02/21] dm: pci: Update the PCI read_config() method to
> const dev *
> 
> At present this method uses a non-const udevice pointer, but the call should
> not modify the device. Use a const pointer.
> 
> Signed-off-by: Simon Glass 

For drivers/pci/pcie_intel_fpga.c, 
Reviewed-by: Ley Foon Tan 

> ---
> 
>  drivers/misc/p2sb_emul.c   |  5 +++--
>  drivers/misc/swap_case.c   |  9 +
>  drivers/pci/pci-aardvark.c |  2 +-
>  drivers/pci/pci-emul-uclass.c  |  2 +-
>  drivers/pci/pci-rcar-gen2.c|  4 ++--
>  drivers/pci/pci-rcar-gen3.c|  2 +-
>  drivers/pci/pci-uclass.c   | 14 --
>  drivers/pci/pci_mpc85xx.c  |  2 +-
>  drivers/pci/pci_mvebu.c|  2 +-
>  drivers/pci/pci_sandbox.c  |  2 +-
>  drivers/pci/pci_sh7751.c   |  2 +-
>  drivers/pci/pci_tegra.c|  2 +-
>  drivers/pci/pci_x86.c  |  5 +++--
>  drivers/pci/pcie_dw_mvebu.c|  2 +-
>  drivers/pci/pcie_dw_ti.c   |  2 +-
>  drivers/pci/pcie_ecam_generic.c| 11 ++-
>  drivers/pci/pcie_fsl.c |  2 +-
>  drivers/pci/pcie_imx.c |  2 +-
>  drivers/pci/pcie_intel_fpga.c  |  4 ++--
>  drivers/pci/pcie_layerscape.c  |  4 ++--
>  drivers/pci/pcie_layerscape_gen4.c |  2 +-
>  drivers/pci/pcie_mediatek.c|  4 ++--
>  drivers/pci/pcie_phytium.c |  7 +++
>  drivers/pci/pcie_xilinx.c  |  4 ++--
>  drivers/power/acpi_pmc/pmc_emul.c  |  2 +-
>  include/pci.h  | 22 --
>  26 files changed, 64 insertions(+), 57 deletions(-)
> 
> diff --git a/drivers/misc/p2sb_emul.c b/drivers/misc/p2sb_emul.c index
> c3795c59c0..a6ee9a235e 100644
> --- a/drivers/misc/p2sb_emul.c
> +++ b/drivers/misc/p2sb_emul.c
> @@ -48,8 +48,9 @@ struct p2sb_emul_priv {
>   u8 regs[16];
>  };
> 
> -static int sandbox_p2sb_emul_read_config(struct udevice *emul, uint offset,
> -  ulong *valuep, enum pci_size_t size)
> +static int sandbox_p2sb_emul_read_config(const struct udevice *emul,
> +  uint offset, ulong *valuep,
> +  enum pci_size_t size)
>  {
>   struct p2sb_emul_platdata *plat = dev_get_platdata(emul);
> 
> diff --git a/drivers/misc/swap_case.c b/drivers/misc/swap_case.c index
> 11189d16c8..97e2afa676 100644
> --- a/drivers/misc/swap_case.c
> +++ b/drivers/misc/swap_case.c
> @@ -51,7 +51,7 @@ struct swap_case_priv {
>   char mem_text[MEM_TEXT_SIZE];
>  };
> 
> -static int sandbox_swap_case_use_ea(struct udevice *dev)
> +static int sandbox_swap_case_use_ea(const struct udevice *dev)
>  {
>   return !!ofnode_get_property(dev->node, "use-ea", NULL);  } @@ -
> 82,7 +82,7 @@ static const u32 ea_regs[] = {
>   PCI_CAP_EA_SIZE_HI,
>  };
> 
> -static int sandbox_swap_case_read_ea(struct udevice *emul, uint offset,
> +static int sandbox_swap_case_read_ea(const struct udevice *emul, uint
> +offset,
>ulong *valuep, enum pci_size_t size)  {
>   u32 reg;
> @@ -95,8 +95,9 @@ static int sandbox_swap_case_read_ea(struct udevice
> *emul, uint offset,
>   return 0;
>  }
> 
> -static int sandbox_swap_case_read_config(struct udevice *emul, uint offset,
> -  ulong *valuep, enum pci_size_t size)
> +static int sandbox_swap_case_read_config(const struct udevice *emul,
> +  uint offset, ulong *valuep,
> +  enum pci_size_t size)
>  {
>   struct swap_case_platdata *plat = dev_get_platdata(emul);
> 
> diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c index
> aa0b4bc845..f1527ac667 100644
> --- a/drivers/pci/pci-aardvark.c
> +++ b/drivers/pci/pci-aardvark.c
> @@ -297,7 +297,7 @@ static int pcie_advk_check_pio_status(struct
> pcie_advk *pcie,
>   *
>   * Return: 0 on success
>   */
> -static int pcie_advk_read_config(struct udevice *bus, pci_dev_t bdf,
> +static int pcie_advk_read_config(const struct udevice *bus, pci_dev_t
> +bdf,
>uint offset, ulong *valuep,
>enum pci_size_t size)
>  {
> diff --git a/drivers/pci/pci-emul-uclass.c b/drivers/pci/pci-emul-uclass.c 
> index
> 0f63e491a7..9486e1cb96 100644
> --- 

Re: [PATCH 4/4] wdt: Add DM support for Designware WDT

2020-02-02 Thread Sean Anderson
On 2/2/20 7:04 PM, Simon Glass wrote:
> Hi Sean,
> 
> On Sun, 2 Feb 2020 at 10:25, Sean Anderson  wrote:
>>
>> On 2/2/20 12:13 PM, Sean Anderson wrote:
>>> The binding used is the same as Linux's.
>>> ---
>>>  doc/device-tree-bindings/watchdog/dw_wdt.txt | 24 +++
>>>  drivers/watchdog/designware_wdt.c| 67 
>>>  2 files changed, 91 insertions(+)
>>>  create mode 100644 doc/device-tree-bindings/watchdog/dw_wdt.txt
>>
>> Signed-off-by: Sean Anderson 
> 
> Are you adding this to the Makefile somewhere?

I'm not sure what you mean. This is optionally used in [1], but I didn't
want to add an explicit dependency. However, this appears to be a bit of
a duplicate effort in light of [2].

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=156389
[2] https://patchwork.ozlabs.org/patch/1232414/

--Sean


Re: [PATCH] serial: Set baudrate on boot

2020-02-02 Thread Sean Anderson
> This looks right to me.
> 
> Can you please update the docs for setbrg() in serial.h to mention
> that this method is always called after probing, so there is now no
> need to set the baud rate in the probe() method?
> 

Sure. Will do that in v2.


Re: [PATCH] x86: Correct error return value in mrccache_get_region()

2020-02-02 Thread Bin Meng
On Mon, Feb 3, 2020 at 4:37 AM Simon Glass  wrote:
>
> This function doesn't use uclass_find_first_device() correctly. Add a
> check that the device is found so we don't try to read properties from a
> NULL device.
>
> The fixes booting on minnoxmax.
>
> Fixes: 87f1084a630 ("x86: Adjust mrccache_get_region() to use livetree")
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/lib/mrccache.c | 2 ++
>  1 file changed, 2 insertions(+)
>

Reviewed-by: Bin Meng 


Re: [PATCH 2/2] spl: get rid of SPL_LIBDISK_SUPPORT

2020-02-02 Thread Simon Glass
On Sat, 1 Feb 2020 at 12:38, Thomas Hebb  wrote:
>
> This option hasn't actually affected what's linked into the build since
> commit 91ff6865629c ("blk: Rework guard around part_init call"), which
> switched libdisk in SPL to depend on (CONFIG_SPL_FRAMEWORK &&
> CONFIG_PARTITIONS). After removing one straggling reference that seems
> to been authored before 91ff6865629c landed, there are absolutely no
> references to this in the code. Let's remove it.
>
> Signed-off-by: Thomas Hebb 
>
> ---
>
>  arch/arm/Kconfig |  1 -
>  arch/arm/mach-imx/mx6/Kconfig|  1 -
>  arch/arm/mach-mvebu/Kconfig  |  2 --
>  arch/arm/mach-omap2/Kconfig  |  3 ---
>  arch/arm/mach-omap2/am33xx/Kconfig   |  2 --
>  arch/arm/mach-stm32mp/Kconfig|  1 -
>  arch/arm/mach-zynq/Kconfig   |  3 ---
>  arch/arm/mach-zynqmp/Kconfig |  3 ---
>  common/spl/Kconfig   | 19 ++-
>  configs/am335x_baltos_defconfig  |  1 -
>  configs/am335x_guardian_defconfig|  1 -
>  configs/am335x_hs_evm_uart_defconfig |  1 -
>  configs/am335x_igep003x_defconfig|  1 -
>  configs/am335x_pdu001_defconfig  |  1 -
>  configs/am335x_shc_defconfig |  1 -
>  configs/am335x_shc_ict_defconfig |  1 -
>  configs/am335x_shc_netboot_defconfig |  1 -
>  configs/am335x_shc_sdboot_defconfig  |  1 -
>  configs/am335x_sl50_defconfig|  1 -
>  configs/am65x_evm_a53_defconfig  |  1 -
>  configs/am65x_evm_r5_defconfig   |  1 -
>  configs/am65x_hs_evm_a53_defconfig   |  1 -
>  configs/am65x_hs_evm_r5_defconfig|  1 -
>  configs/birdland_bav335a_defconfig   |  1 -
>  configs/birdland_bav335b_defconfig   |  1 -
>  configs/cgtqmx6eval_defconfig|  1 -
>  configs/chiliboard_defconfig |  1 -
>  configs/cm_t335_defconfig|  1 -
>  configs/cm_t43_defconfig |  1 -
>  configs/draco_defconfig  |  1 -
>  configs/etamin_defconfig |  1 -
>  configs/imx6qdl_icore_mipi_defconfig |  1 -
>  configs/imx6qdl_icore_mmc_defconfig  |  1 -
>  configs/imx6qdl_icore_rqs_defconfig  |  1 -
>  configs/imx6ul_geam_mmc_defconfig|  1 -
>  configs/imx6ul_isiot_emmc_defconfig  |  1 -
>  configs/j721e_evm_a72_defconfig  |  1 -
>  configs/j721e_evm_r5_defconfig   |  1 -
>  configs/j721e_hs_evm_a72_defconfig   |  1 -
>  configs/j721e_hs_evm_r5_defconfig|  1 -
>  configs/mx6cuboxi_defconfig  |  1 -
>  configs/mx6sabreauto_defconfig   |  1 -
>  configs/mx6sabresd_defconfig |  1 -
>  configs/mx6slevk_spl_defconfig   |  1 -
>  configs/mx6sxsabresd_spl_defconfig   |  1 -
>  configs/mx6ul_14x14_evk_defconfig|  1 -
>  configs/mx6ul_9x9_evk_defconfig  |  1 -
>  configs/novena_defconfig |  1 -
>  configs/opos6uldev_defconfig |  1 -
>  configs/pcm051_rev1_defconfig|  1 -
>  configs/pcm051_rev3_defconfig|  1 -
>  configs/pcm058_defconfig |  1 -
>  configs/pengwyn_defconfig|  1 -
>  configs/pepper_defconfig |  1 -
>  configs/pfla02_defconfig |  1 -
>  configs/phycore-am335x-r2-wega_defconfig |  1 -
>  configs/pico-dwarf-imx6ul_defconfig  |  1 -
>  configs/pico-hobbit-imx6ul_defconfig |  1 -
>  configs/pico-imx6_defconfig  |  1 -
>  configs/pico-imx6ul_defconfig|  1 -
>  configs/pico-pi-imx6ul_defconfig |  1 -
>  configs/picosam9g45_defconfig|  1 -
>  configs/platinum_picon_defconfig |  1 -
>  configs/platinum_titanium_defconfig  |  1 -
>  configs/pxm2_defconfig   |  1 -
>  configs/rastaban_defconfig   |  1 -
>  configs/riotboard_spl_defconfig  |  1 -
>  configs/rut_defconfig|  1 -
>  configs/sama5d27_som1_ek_mmc1_defconfig  |  1 -
>  configs/sama5d27_som1_ek_mmc_defconfig   |  1 -
>  configs/sama5d27_som1_ek_qspiflash_defconfig |  1 -
>  configs/sama5d27_wlsom1_ek_mmc_defconfig |  1 -
>  configs/sama5d2_icp_mmc_defconfig|  1 -
>  configs/sama5d2_xplained_emmc_defconfig  |  1 -
>  configs/sama5d2_xplained_mmc_defconfig   |  1 -
>  configs/sama5d2_xplained_qspiflash_defconfig |  1 -
>  configs/sama5d3_xplained_mmc_defconfig   |  1 -
>  configs/sama5d3xek_mmc_defconfig |  1 -
>  configs/sama5d4_xplained_mmc_defconfig   |  1 -
>  configs/sama5d4ek_mmc_defconfig  |  1 -
>  configs/sksimx6_defconfig|  1 -
>  

Re: [PATCH v3 05/12] dm: Add support for simple-pm-bus

2020-02-02 Thread Simon Glass
Hi Sean,

On Sun, 2 Feb 2020 at 13:02, Sean Anderson  wrote:
>
> This type of bus is used in Linux to designate busses which have power domains
> and/or clocks which need to be enabled before their child devices can be used.
> Because power domains are automatically enabled before probing in u-boot, we
> just need to enable any clocks present.
>
> Signed-off-by: Sean Anderson 
> ---
>   Changes for v3:
>   - New
>
>  .../bus/simple-pm-bus.txt | 44 ++
>  drivers/core/simple-bus.c | 57 ++-
>  2 files changed, 99 insertions(+), 2 deletions(-)
>  create mode 100644 doc/device-tree-bindings/bus/simple-pm-bus.txt

Please can you add a test for this new functionality?

Thanks,
Simon


Re: [PATCH 2/4] arm: Move asm/utils.h to log2.h

2020-02-02 Thread Simon Glass
On Sun, 2 Feb 2020 at 10:12, Sean Anderson  wrote:
>
> This header is needed outside of the arm architecture by the designware wdt
> driver.
> ---
>  arch/arm/cpu/armv7/cache_v7.c  | 2 +-
>  arch/arm/mach-davinci/spl.c| 2 +-
>  arch/arm/mach-omap2/clocks-common.c| 2 +-
>  arch/arm/mach-omap2/emif-common.c  | 2 +-
>  arch/arm/mach-omap2/omap4/emif.c   | 2 +-
>  arch/arm/mach-omap2/omap5/dra7xx_iodelay.c | 2 +-
>  arch/arm/mach-omap2/omap5/emif.c   | 2 +-
>  arch/arm/mach-omap2/omap5/hwinit.c | 2 +-
>  arch/arm/mach-socfpga/spl_a10.c| 2 +-
>  arch/arm/mach-socfpga/spl_agilex.c | 2 +-
>  arch/arm/mach-socfpga/spl_gen5.c   | 2 +-
>  arch/arm/mach-socfpga/spl_s10.c| 2 +-
>  drivers/watchdog/designware_wdt.c  | 4 ++--
>  arch/arm/include/asm/utils.h => include/log2.h | 4 ++--
>  14 files changed, 16 insertions(+), 16 deletions(-)
>  rename arch/arm/include/asm/utils.h => include/log2.h (93%)

Reviewed-by: Simon Glass 


Re: SDL 2.0 in gitlab

2020-02-02 Thread Simon Glass
Hi Tom,

On Sun, 2 Feb 2020 at 09:56, Tom Rini  wrote:
>
> On Sun, Feb 02, 2020 at 09:14:56AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 13 Jan 2020 at 14:27, Tom Rini  wrote:
> > >
> > > On Sun, Jan 12, 2020 at 09:01:18PM +1300, Simon Glass wrote:
> > >
> > > > Hi Tom,
> > > >
> > > > I have a series which changes sandbox over to use the newer SDL2. At
> > > > present I cannot make it pass on gitlab since it seems to have SDL1.2
> > > > (only).
> > > >
> > > > Is it possible to change that?
> > >
> > > Yes, change
> > > https://gitlab.denx.de/u-boot/gitlab-ci-runner/blob/master/Dockerfile#L35
> > > and also
> > > https://gitlab.denx.de/u-boot/u-boot/blob/master/.travis.yml#L22
> > > at the same time.  Testing will be a little hard as you'll need to
> > > change your local .gitlab/.azure files to use your docker image to
> > > confirm the changes.
> >
> > OK thanks It's just a case of adding libsdl2-dev to the list. I put
> > the travis change in the series already.
> >
> > I created a commit. But how do I submit a change to the
> > gitlib-ci-runner project? I don't seem to be able to fork it or push
> > to it, but I see others have made changes.
>
> Post to the regular ML, prefix it so it's clear that it's for the gitlab
> file and I'll pick it up and sync things up.

OK thanks, done.

Regards,
Simon


Re: [PATCH 4/4] wdt: Add DM support for Designware WDT

2020-02-02 Thread Simon Glass
Hi Sean,

On Sun, 2 Feb 2020 at 10:25, Sean Anderson  wrote:
>
> On 2/2/20 12:13 PM, Sean Anderson wrote:
> > The binding used is the same as Linux's.
> > ---
> >  doc/device-tree-bindings/watchdog/dw_wdt.txt | 24 +++
> >  drivers/watchdog/designware_wdt.c| 67 
> >  2 files changed, 91 insertions(+)
> >  create mode 100644 doc/device-tree-bindings/watchdog/dw_wdt.txt
>
> Signed-off-by: Sean Anderson 

Are you adding this to the Makefile somewhere?

Regards,
Simon


Re: [PATCH v3 04/12] reset: Add generic reset driver

2020-02-02 Thread Simon Glass
HI Sean,

On Sun, 2 Feb 2020 at 13:01, Sean Anderson  wrote:
>
> This patch adds a generic reset driver. It is designed to be useful when one 
> has
> a register in a regmap which contains bits that reset other devices. I thought
> this seemed like a very generic use, so here is a generic driver. The overall
> structure has been modeled on the syscon-reboot driver.
>
> Signed-off-by: Sean Anderson 
> ---
>   Changes for v3:
>   - New
>
>  .../reset/syscon-reset.txt| 36 +
>  drivers/reset/Kconfig |  6 +-
>  drivers/reset/Makefile|  1 +
>  drivers/reset/reset-syscon.c  | 79 +++
>  4 files changed, 121 insertions(+), 1 deletion(-)
>  create mode 100644 doc/device-tree-bindings/reset/syscon-reset.txt
>  create mode 100644 drivers/reset/reset-syscon.c

Is there a sandbox test for this driver somewhere in your series?

Regards,
Simon


Re: [PATCH v2 2/2] gpio: search for gpio label if gpio is not found through bank name

2020-02-02 Thread Simon Glass
On Sat, 1 Feb 2020 at 01:03, Heiko Schocher  wrote:
>
> dm_gpio_lookup_name() searches for a gpio through
> the bank name. But we have also gpio labels, and it
> makes sense to search for a gpio also in the labels
> we have defined, if no gpio is found through the
> bank name definition.
>
> This is useful for example if you have a wp pin on
> different gpios on different board versions.
>
> If dm_gpio_lookup_name() searches also for the gpio labels,
> you can give the gpio an unique label name and search
> for this label, and do not need to differ between
> board revisions.
>
> Signed-off-by: Heiko Schocher 
> ---
>
> Example on the aristainetos board:
>
> => gpio clear wp_spi_nor.gpio-hog
> gpio: pin wp_spi_nor.gpio-hog (gpio 47) value is 0
> =>
>
> before this patch, you need to know where your
> pin is:
>
> => gpio clear GPIO2_15
> gpio: pin GPIO2_15 (gpio 47) value is 0
> =>
>
> travis build:
>
> Changes in v2:
> - add comment from Simon Glass
>   move code into seperate function dm_gpio_lookup_label()
>   add test if dm_gpio_lookup_label() works
>
>  drivers/gpio/gpio-uclass.c | 38 ++
>  test/dm/gpio.c |  7 +++
>  2 files changed, 45 insertions(+)

Reviewed-by: Simon Glass 

I wonder if this should be a Kconfig so we can disable it by default in SPL?


- Simon


Re: [PATCH v2 1/2] sandbox, test: add test for GPIO_HOG function

2020-02-02 Thread Simon Glass
On Sat, 1 Feb 2020 at 01:02, Heiko Schocher  wrote:
>
> currently gpio hog function is not tested with "ut dm gpio"
> so add some basic tests for gpio hog functionality.
>
> For this enable GPIO_HOG in sandbox_defconfig, add
> in DTS some gpio hog entries, and add testcase in
> "ut dm gpio" command.
>
> Signed-off-by: Heiko Schocher 
>
> ---
>
> Changes in v2:
> - add basic gpio hog test functions
>
>  arch/sandbox/dts/test.dts  | 24 
>  configs/sandbox64_defconfig|  1 +
>  configs/sandbox_defconfig  |  1 +
>  configs/sandbox_flattree_defconfig |  1 +
>  configs/sandbox_spl_defconfig  |  1 +
>  test/dm/gpio.c | 23 +++
>  6 files changed, 51 insertions(+)

Reviewed-by: Simon Glass 


Re: [PATCH] serial: Set baudrate on boot

2020-02-02 Thread Simon Glass
Hi Sean,

On Sun, 2 Feb 2020 at 11:15, Sean Anderson  wrote:
>
> Currently, the baud rate is never set on boot. This works ok when a previous
> bootloader has configured the baudrate properly, or when the baudrate is set 
> to
> a reasonable default in the serial driver's probe(). However, when this is not
> the case, we could be using a different baud rate than what was configured.
>
> Signed-off-by: Sean Anderson 
> ---
>  drivers/serial/serial-uclass.c | 1 +
>  1 file changed, 1 insertion(+)

This looks right to me.

Can you please update the docs for setbrg() in serial.h to mention
that this method is always called after probing, so there is now no
need to set the baud rate in the probe() method?


Re: [PATCH 1/1 v1] cmd: gpio: Correct do_gpio() return value

2020-02-02 Thread Simon Glass
Hi Tom,

On Fri, 31 Jan 2020 at 13:59, Tom Rini  wrote:
>
> On Thu, Jan 30, 2020 at 07:27:57PM -0700, Simon Glass wrote:
> > Hi Tom.
> >
> > On Thu, 30 Jan 2020 at 11:52, Tom Rini  wrote:
> > >
> > > On Wed, Jan 29, 2020 at 07:17:09PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 23 Jan 2020 at 14:12, Tom Rini  wrote:
> > > > >
> > > > > On Thu, Jan 23, 2020 at 10:04:05PM +0100, Luka Kovačič wrote:
> > > > >
> > > > > > Hello Tom,
> > > > > >
> > > > > > thank you for feedback and review. I understand the implications.
> > > > > > Would it make sense to document this somewhere to avoid any future 
> > > > > > confusion?
> > > > >
> > > > > Yes, along with a standalone patch to update the document to use
> > > > > CMD_RET_SUCCESS NOT CMD_SUCCESS.  Updating the gpio help text even to 
> > > > > be
> > > > > clear what the return value is would be nice.  Thanks!
> > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Luka
> > > > > >
> > > > > > On Thu, Jan 23, 2020 at 1:31 PM Tom Rini  wrote:
> > > > > > >
> > > > > > > On Sun, Jan 05, 2020 at 08:10:56PM +0100, Luka Kovacic wrote:
> > > > > > >
> > > > > > > > Use the correct return value in function do_gpio() and update
> > > > > > > > commands documentation with the return values from 
> > > > > > > > command_ret_t enum.
> > > > > > > >
> > > > > > > > CMD_RET_SUCCESS is returned on command success and 
> > > > > > > > CMD_RET_FAILURE is
> > > > > > > > returned on command failure.
> > > > > > > >
> > > > > > > > The command was returning the pin value, which caused confusion 
> > > > > > > > when
> > > > > > > > debugging (#define DEBUG).
> > > > > > > >
> > > > > > > > Signed-off-by: Luka Kovacic 
> > > > > > > > Tested-by: Robert Marko 
> > > > > > >
> > > > > > > So, I think the problem is that despite this not being an optimal 
> > > > > > > user
> > > > > > > interface, it's what we've had here for "forever".  We can't just 
> > > > > > > go
> > > > > > > change it now as there's scripts out in the world (and even
> > > > > > > include/configs/) that depend on the current behavior.  Sorry, 
> > > > > > > nak.
> > > >
> > > > The command is effectively returning a negative value on failure,
> > > > which causes the calling shell to try to exit!
> > > >
> > > > Also 'gpio set' will return failure if you enable a GPIO. I really
> > > > can't see that people could be relying too much on the current
> > > > behaviour.
> > > >
> > > > GIven our policy on upstream, if we fix the in-tree scripts do you
> > > > think we could fix this problem?
> > > >
> > > > The 'return -1' is definitely a bug BTW.
> > >
> > > My first comment is to look at configs/socfpga_vining_fpga_defconfig and
> > > include/configs/omap3_beagle.h around 'if gpio' and tell me if I'm
> > > simply misunderstanding how things are being used.
> > >
> > > But if I'm not then I'm not sure just changing the users is OK because
> > > it's baked into saved environments.  Now I can say that for the Beagle
> > > case it might be OK in the end.  But I'm not so sure about the socfpga
> > > case.  Marek?
> >
> > The omap3 code looks like it is checking if the GPIO is set or not.
> >
> > Oddly 'if gpio input xx' is true if the GPIO is 0, so it might be
> > confusing. Arguably this should be inverted.
> >
> > So how about we leave the behaviour for 'gpio input' alone, and 'fix'
> > the other bits?
>
> What about the socfpga example?  Thanks!

This is also using 'gpio input' so we should be OK.

Regards,
SImon


Re: [PATCH v2] dm: uclass: don't assign aliased seq numbers

2020-02-02 Thread Simon Glass
Hi Michael,

On Wed, 29 Jan 2020 at 19:16, Simon Glass  wrote:
>
> Hi Michael,
>
> On Fri, 20 Dec 2019 at 06:29, Michael Walle  wrote:
> >
> > If there are aliases for an uclass, set the base for the "dynamically"
> > allocated numbers next to the highest alias.
> >
> > Please note, that this might lead to holes in the sequences, depending
> > on the device tree. For example if there is only an alias "ethernet1",
> > the next device seq number would be 2.
> >
> > In particular this fixes a problem with boards which are using ethernet
> > aliases but also might have network add-in cards like the E1000. If the
> > board is started with the add-in card and depending on the order of the
> > drivers, the E1000 might occupy the first ethernet device and mess up
> > all the hardware addresses, because the devices are now shifted by one.
> >
> > Cc: Thomas Fitzsimmons 
> > Cc: Michal Simek 
> > Signed-off-by: Michael Walle 
> > Reviewed-by: Alex Marginean 
> > Tested-by: Alex Marginean 
> > Acked-by: Vladimir Oltean 
> > ---
> >
> > As a side effect, this should also make the following commits
> > superfluous:
> >  - 7f3289bf6d ("dm: device: Request next sequence number")
> >  - 61607225d1 ("i2c: Fill req_seq in i2c_post_bind()")
> >Although I don't understand the root cause of the said problem.
> >
> > Thomas, Michal, could you please test this and then I'd add a second
> > patch removing the old code.
>
> I think this is reasonable. We have discussed a possible rework of the
> logic to merge seq and req_seq, but I don't think we have any patches
> yet.
>
> Please can you add a test to your patch? You can put it in test-fdt.c
> for example.
>
> If you are reverting the other patches, could you please send patches for 
> those?

One more thing...this actually breaks existing tests so please fix those also.

Thanks,
SImon


Re: [PULL] u-boot-usb/master

2020-02-02 Thread Tom Rini
On Sun, Feb 02, 2020 at 06:20:45PM +0100, Marek Vasut wrote:

> The following changes since commit 80e99adbe47d1c8590f9b971ac52257fdc51a5ec:
> 
>   Merge tag 'uniphier-v2020.04-2' of
> https://gitlab.denx.de/u-boot/custodians/u-boot-uniphier (2020-01-31
> 13:26:28 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to 13cb7cc9e8e48eb888b13743f79ff02420405044:
> 
>   dfu: Add option to skip empty pages when flashing UBI images to NAND
> (2020-02-02 18:19:52 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/2] spl: get rid of SPL_LIBDISK_SUPPORT

2020-02-02 Thread Felix Brack

On 01.02.20 20:38, Thomas Hebb wrote:

This option hasn't actually affected what's linked into the build since
commit 91ff6865629c ("blk: Rework guard around part_init call"), which
switched libdisk in SPL to depend on (CONFIG_SPL_FRAMEWORK &&
CONFIG_PARTITIONS). After removing one straggling reference that seems
to been authored before 91ff6865629c landed, there are absolutely no
references to this in the code. Let's remove it.

Signed-off-by: Thomas Hebb 

---



For the PDU001 board:
Tested-by: Felix Brack 


[PATCH] x86: Correct error return value in mrccache_get_region()

2020-02-02 Thread Simon Glass
This function doesn't use uclass_find_first_device() correctly. Add a
check that the device is found so we don't try to read properties from a
NULL device.

The fixes booting on minnoxmax.

Fixes: 87f1084a630 ("x86: Adjust mrccache_get_region() to use livetree")

Signed-off-by: Simon Glass 
---

 arch/x86/lib/mrccache.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/lib/mrccache.c b/arch/x86/lib/mrccache.c
index b9420a4cab..288673b0ea 100644
--- a/arch/x86/lib/mrccache.c
+++ b/arch/x86/lib/mrccache.c
@@ -240,6 +240,8 @@ int mrccache_get_region(enum mrc_type_t type, struct 
udevice **devp,
 * memory map cannot be read.
 */
ret = uclass_find_first_device(UCLASS_SPI_FLASH, );
+   if (!ret && !dev)
+   ret = -ENODEV;
if (ret)
return log_msg_ret("Cannot find SPI flash\n", ret);
ret = dm_spi_get_mmap(dev, _base, _size, );
-- 
2.25.0.341.g760bfbb309-goog



Re: [PULL] u-boot-socfpga/master

2020-02-02 Thread Tom Rini
On Sun, Feb 02, 2020 at 06:18:53PM +0100, Marek Vasut wrote:

> The following changes since commit 80e99adbe47d1c8590f9b971ac52257fdc51a5ec:
> 
>   Merge tag 'uniphier-v2020.04-2' of
> https://gitlab.denx.de/u-boot/custodians/u-boot-uniphier (2020-01-31
> 13:26:28 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-socfpga.git master
> 
> for you to fetch changes up to 56c24875d92adcf214d97f5798e11c1b7b5e27fa:
> 
>   ddr: altera: Add DDR2 support to Gen5 driver (2020-02-02 18:18:05 +0100)
> 

A see a ton of failures:
   aarch64:  +   socfpga_agilex
   arm:  +   socfpga_is1 socfpga_cyclone5 socfpga_de10_nano socfpga_mcvevk 
socfpga_dbm_soc1 socfpga_arria5 socfpga_de1_soc socfpga_sr1500 socfpga_socrates 
socfpga_sockit socfpga_vining_fpga socfpga_de0_nano_soc

Thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH v3 12/12] riscv: Add initial Sipeed Maix support

2020-02-02 Thread Sean Anderson
The Sipeed Maix series is a collection of boards built around the RISC-V
Kendryte K210 processor. This processor contains several peripherals to
accelerate neural network processing and other "ai" tasks. This includes a "KPU"
neural network processor, an audio processor supporting beamforming reception,
and a digital video port supporting capture and output at VGA resolution. Other
peripherals include 8M of sram (accessible with and without caching);
remappable pins, including 40 GPIOs; AES, FFT, and SHA256 accelerators; a DMA
controller; and I2C, I2S, and SPI controllers. Maix peripherals vary, but
include spi flash; on-board usb-serial bridges; ports for cameras, displays, and
sd cards; and ESP32 chips. Currently, only the Sipeed Maix Bit V2.0 (bitm) is
supported, but the boards are fairly similar.

Documentation for Maix boards is located at .
Documentation for the Kendryte K210 is located at
. However, hardware details are rather lacking,
so most technical reference has been taken from the standalone sdk located at
.

Signed-off-by: Sean Anderson 
---
  Changes for v3:
  - Reorder to be last in the patch series
  - Add documentation for the board
  - Generate defconfig with "make savedefconfig"
  - Update Kconfig to imply most features we need
  - Update MAINTAINERS
  Changes for v2:
  - Select CONFIG_SYS_RISCV_NOCOUNTER
  - Imply CONFIG_CLK_K210
  - Remove spurious references to CONFIG_ARCH_K210
  - Remove many configs from defconfig where the defaults were fine
  - Add a few "not set" lines to suppress unneeded defaults
  - Reduce pre-reloc malloc space, now that clocks initialization happens later

 arch/riscv/Kconfig |  4 +++
 board/sipeed/maix/Kconfig  | 51 ++
 board/sipeed/maix/MAINTAINERS  | 10 ++
 board/sipeed/maix/Makefile |  5 +++
 board/sipeed/maix/maix.c   |  9 ++
 configs/sipeed_maix_bitm_defconfig | 10 ++
 doc/board/index.rst|  1 +
 doc/board/kendryte/index.rst   |  9 ++
 doc/board/kendryte/k210.rst| 46 +++
 include/configs/sipeed-maix.h  | 19 +++
 10 files changed, 164 insertions(+)
 create mode 100644 board/sipeed/maix/Kconfig
 create mode 100644 board/sipeed/maix/MAINTAINERS
 create mode 100644 board/sipeed/maix/Makefile
 create mode 100644 board/sipeed/maix/maix.c
 create mode 100644 configs/sipeed_maix_bitm_defconfig
 create mode 100644 doc/board/kendryte/index.rst
 create mode 100644 doc/board/kendryte/k210.rst
 create mode 100644 include/configs/sipeed-maix.h

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 87c40f6c4c..81ab35dd2d 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -20,6 +20,9 @@ config TARGET_QEMU_VIRT
 config TARGET_SIFIVE_FU540
bool "Support SiFive FU540 Board"
 
+config TARGET_SIPEED_MAIX
+   bool "Support Sipeed Maix Board"
+
 endchoice
 
 config SYS_ICACHE_OFF
@@ -53,6 +56,7 @@ source "board/AndesTech/ax25-ae350/Kconfig"
 source "board/emulation/qemu-riscv/Kconfig"
 source "board/microchip/mpfs_icicle/Kconfig"
 source "board/sifive/fu540/Kconfig"
+source "board/sipeed/maix/Kconfig"
 
 # platform-specific options below
 source "arch/riscv/cpu/ax25/Kconfig"
diff --git a/board/sipeed/maix/Kconfig b/board/sipeed/maix/Kconfig
new file mode 100644
index 00..b23d2448d9
--- /dev/null
+++ b/board/sipeed/maix/Kconfig
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2019 Sean Anderson 
+
+if TARGET_SIPEED_MAIX
+
+config SYS_BOARD
+   default "maix"
+
+config SYS_VENDOR
+   default "sipeed"
+
+config SYS_CPU
+   default "generic"
+
+config SYS_CONFIG_NAME
+   default "sipeed-maix"
+
+config SYS_TEXT_BASE
+   default 0x8000
+
+config DEFAULT_DEVICE_TREE
+   default "k210-maix-bit"
+
+config NR_CPUS
+   default 2
+
+config NR_DRAM_BANKS
+   default 2
+
+config BOARD_SPECIFIC_OPTIONS
+   def_bool y
+   select GENERIC_RISCV
+   select RISCV_PRIV_1_9_1
+   imply DM_SERIAL
+   imply SIFIVE_SERIAL
+   imply SIFIVE_CLINT
+   imply CLK_CCF
+   imply CLK_COMPOSITE_CCF
+   imply CLK_K210
+   imply DM_RESET
+   imply RESET_SYSCON
+   imply SYSRESET
+   imply SYSRESET_SYSCON
+   imply SPI
+   imply DESIGNWARE_SPI
+   imply SPI_FLASH_GIGADEVICE
+   imply MMC
+   imply MMC_SPI
+   imply MMC_BROKEN_CD
+   imply CMD_MMC
+endif
diff --git a/board/sipeed/maix/MAINTAINERS b/board/sipeed/maix/MAINTAINERS
new file mode 100644
index 00..43cf61fb64
--- /dev/null
+++ b/board/sipeed/maix/MAINTAINERS
@@ -0,0 +1,10 @@
+Sipeed Maix BOARD
+M: Sean Anderson 
+S: Maintained
+F: arch/riscv/dts/k210.dtsi
+F: arch/riscv/dts/k210-maix-bit.dts
+F: board/sipeed/maix/
+F: configs/sipeed_maix_defconfig
+F: drivers/clk/kendryte/
+F: 

[PATCH v3 11/12] riscv: Add device tree for K210

2020-02-02 Thread Sean Anderson
Where possible, I have tried to find compatible drivers based on the layout of
registers. However, I have not tested most of this functionality, and most
devices should be considered descriptive at best. I would appreciate if anyone
could help identify possibly compatible devices, especially for the timers
and rtc.

Should the size of a reg be the size of the documented registers, or the size
of the address space which will be routed to that device?

Signed-off-by: Sean Anderson 
---
  Changes for v3:
  - Move this patch to the end of the series
  - Add a max frequency for spi3
  - Remov unused compatible strings from spi-flash@0
  - Add s and u to isa string
  - Fix mmu-type
  - Remove cache-line size since it is unused (in u-boot) and undocumented
(upstream)
  - Add timer interrupts to clint0
  - Round up various registers
  - Add riscv,max-priority to plic
  - Add apb* busses, since they have clocks which need to be enabled to access
their devices
  - Change uart compatible strings to "snps,dw-apb-uart", since that appears to
match their registers
  - Add compatible string for wdt*
  - Add system reset device under sysctl
  - Add reset device under sysctl
  Changes for v2:
  - Model changed to "Sipeed Maix Bit" to match file name
  - Value of stdout-path fixed
  - SD card slot compatible changed to "mmc-spi-slot"
  - "jedec,spi-nor" added to spi flash compatible list
  - Aliases for spi busses added
  - timebase-frequency divided by 50 to match timer speed
  - cpu-frequency renamed to clock-frequency
  - CPUX_intc restyled to cpuX_intc
  - "kendryte,k210-soc" added to soc compatible list for future-proofing
  - PLIC handle renamed to plic0 from pic0
  - K210_RST_SOC removed from sysrst, due to not being located in the
reset register
  - K210_RST_* numbers changed to match their bit offset within the reset
register
  - gpio_controller restyled to gpio-controller
  - Added a second clock to the dma binding to match what the driver expects
  - Changed "snps,designware-spi" compatible string to "snps,dw-apb-ssi" to
match the correct driver
  - Added a name to the spi clocks
  - Added reg-io-width property to spi bindings
  - Assigned a default parent to K210_CLK_SPI3
  - Removed assigned clocks for ACLK and PLLs
  - Removed u-boot,dm-pre-reloc bindings

 arch/riscv/dts/Makefile |   1 +
 arch/riscv/dts/k210-maix-bit.dts|  42 ++
 arch/riscv/dts/k210.dtsi| 496 
 include/dt-bindings/reset/k210-sysctl.h |  38 ++
 4 files changed, 577 insertions(+)
 create mode 100644 arch/riscv/dts/k210-maix-bit.dts
 create mode 100644 arch/riscv/dts/k210.dtsi
 create mode 100644 include/dt-bindings/reset/k210-sysctl.h

diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index 4f30e6936f..3a6f96c67d 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -2,6 +2,7 @@
 
 dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
 dtb-$(CONFIG_TARGET_SIFIVE_FU540) += hifive-unleashed-a00.dtb
+dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
 
 targets += $(dtb-y)
 
diff --git a/arch/riscv/dts/k210-maix-bit.dts b/arch/riscv/dts/k210-maix-bit.dts
new file mode 100644
index 00..10f36921e0
--- /dev/null
+++ b/arch/riscv/dts/k210-maix-bit.dts
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Sean Anderson 
+ */
+
+/dts-v1/;
+
+#include "k210.dtsi"
+
+/ {
+   model = "Sipeed Maix Bit";
+   compatible = "sipeed,maix-bit", "kendryte,k210";
+
+   chosen {
+   stdout-path = "serial0:115200";
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   slot@0 {
+   compatible = "mmc-spi-slot";
+   reg = <0>;
+   broken-cd;
+   disable-wp;
+   };
+};
+
+ {
+   status = "okay";
+   spi-max-frequency = <12000>;
+   spi-flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <12000>;
+   m25p,fast-read;
+   };
+};
diff --git a/arch/riscv/dts/k210.dtsi b/arch/riscv/dts/k210.dtsi
new file mode 100644
index 00..cc46b692e6
--- /dev/null
+++ b/arch/riscv/dts/k210.dtsi
@@ -0,0 +1,496 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Sean Anderson 
+ */
+
+#include 
+#include 
+#include 
+
+/ {
+   /*
+* Although the K210 is a 64-bit CPU, the address bus is only 32-bits
+* wide, and the upper half of all addresses is ignored.
+*/
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "kendryte,k210";
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   spi0 = 
+   spi1 = 
+   spi2 = 
+   spi3 = 
+   };
+
+   clocks {
+   in0: oscillator {
+   compatible = 

[PATCH v3 09/12] riscv: Add K210 pll support

2020-02-02 Thread Sean Anderson
This pll code is primarily based on the code from the kendryte standalone sdk in
lib/drivers/sysctl.c. k210_pll_calc_params is roughly analogous to the algorithm
used to set the pll frequency, but it has been completely rewritten to be
fixed-point based.

Currently I am having problems setting the rate of the PLL. It seems that the
bypass does not work when the PLL is reset and the rate has changed. I may need
to reparent ACLK, which seems like a real pain to do generically. On the upside,
I have identified this PLL as a True Circuits, Inc. model.

Signed-off-by: Sean Anderson 
---
  Changes for v3:
  - Add an option to not include support for setting the pll rate. This saves
around 1K in the final executable.
  - Remove udelays to suppress warnings
  - Bypass PLL after enabling, instead of before
  - Check if the PLL is enabled already before doing a reset
  - Fix bug with locked mask
  Changes for v2:
  - Rename driver to "k210_clk_pll"
  - Add additional in-line documentation on algorithm and PLLs
  - Restrict the range of internal VCO and reference frequencies
  - Don't load driver before relocation
  - Remove spurious references to mach-k210

 drivers/clk/Kconfig   |   1 +
 drivers/clk/Makefile  |   1 +
 drivers/clk/kendryte/Kconfig  |  12 +
 drivers/clk/kendryte/Makefile |   1 +
 drivers/clk/kendryte/pll.c| 607 ++
 drivers/clk/kendryte/pll.h|  38 +++
 6 files changed, 660 insertions(+)
 create mode 100644 drivers/clk/kendryte/Kconfig
 create mode 100644 drivers/clk/kendryte/Makefile
 create mode 100644 drivers/clk/kendryte/pll.c
 create mode 100644 drivers/clk/kendryte/pll.h

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 16d4237f89..af75c7c4cf 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -145,6 +145,7 @@ source "drivers/clk/analogbits/Kconfig"
 source "drivers/clk/at91/Kconfig"
 source "drivers/clk/exynos/Kconfig"
 source "drivers/clk/imx/Kconfig"
+source "drivers/clk/kendryte/Kconfig"
 source "drivers/clk/meson/Kconfig"
 source "drivers/clk/mvebu/Kconfig"
 source "drivers/clk/owl/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 06131edb9f..4f3893f6fc 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_CLK_BCM6345) += clk_bcm6345.o
 obj-$(CONFIG_CLK_BOSTON) += clk_boston.o
 obj-$(CONFIG_CLK_EXYNOS) += exynos/
 obj-$(CONFIG_CLK_HSDK) += clk-hsdk-cgu.o
+obj-$(CONFIG_CLK_K210) += kendryte/
 obj-$(CONFIG_CLK_MPC83XX) += mpc83xx_clk.o
 obj-$(CONFIG_CLK_OWL) += owl/
 obj-$(CONFIG_CLK_RENESAS) += renesas/
diff --git a/drivers/clk/kendryte/Kconfig b/drivers/clk/kendryte/Kconfig
new file mode 100644
index 00..7b69c8afaf
--- /dev/null
+++ b/drivers/clk/kendryte/Kconfig
@@ -0,0 +1,12 @@
+config CLK_K210
+   bool "Clock support for Kendryte K210"
+   depends on CLK && CLK_CCF
+   help
+ This enables support clock driver for Kendryte K210 platforms.
+
+config CLK_K210_SET_RATE
+   bool "Enable setting the Kendryte K210 PLL rate"
+   depends on CLK_K210
+   help
+ Add functionality to calculate new rates for K210 PLLs. Enabling this
+ feature adds around 1K to U-Boot's final size.
diff --git a/drivers/clk/kendryte/Makefile b/drivers/clk/kendryte/Makefile
new file mode 100644
index 00..c56d93ea1c
--- /dev/null
+++ b/drivers/clk/kendryte/Makefile
@@ -0,0 +1 @@
+obj-y += pll.o
diff --git a/drivers/clk/kendryte/pll.c b/drivers/clk/kendryte/pll.c
new file mode 100644
index 00..03aec72fd7
--- /dev/null
+++ b/drivers/clk/kendryte/pll.c
@@ -0,0 +1,607 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Sean Anderson 
+ */
+#include "pll.h"
+
+#define LOG_CATEGORY UCLASS_CLK
+#include 
+/* For DIV_ROUND_DOWN_ULL, defined in linux/kernel.h */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CLK_K210_PLL "k210_clk_pll"
+#define to_k210_pll(_clk) container_of(_clk, struct k210_pll, clk)
+
+#ifdef CONFIG_CLK_K210_SET_RATE 
+static int k210_pll_enable(struct clk *clk);
+static int k210_pll_disable(struct clk *clk);
+
+/*
+ * The PLL included with the Kendryte K210 appears to be a True Circuits, Inc.
+ * General-Purpose PLL. The logical layout of the PLL with internal feedback is
+ * approximately the following:
+ *
+ *+---+
+ *|input clock|
+ *+---+
+ *  |
+ *  v
+ *+--+
+ *|/r|
+ *+--+
+ *  |
+ *  v
+ *  +---+
+ *  |reference clock|
+ *  +---+
+ *  |
+ *  v
+ * ++
+ * |phase comparator|<--+
+ * ++   |
+ *  |   |
+ *  v   +--+
+ *+---+ |feedback clock|
+ *|VCO| +--+
+ *+---+ ^
+ *  |+--+   |
+ *  +--->|/f|---+
+ *  |+--+
+ *  v
+ *+---+
+ *|/od|
+ *+---+
+ 

[PATCH v3 10/12] riscv: Add K210 clock support

2020-02-02 Thread Sean Anderson
Due to the large number of clocks, I decided to use the CCF. The overall
structure is modeled after the imx code. A common pattern is to create a
composite clock composed of several component clocks. For these component
clocks, the clk_register_* functions are not used, since they will be registered
as part of the composite clock. To create these component clocks, several helper
k210_clk_comp_* functions are used. This functionality seems like it would be
useful to other drivers also creating composite clocks, so perhaps some general
versions should be created. I am not particularly attached to the naming
convention, suggestions are welcome.

Signed-off-by: Sean Anderson 
---
  Changes for v3:
  - Removed sysctl struct, replacing it with defines. This is to have the same
interface to sysctl from C as from the device tree.
  - Fixed clocks having the same id
  - Fixed clocks not using the correct register/bits
  - Aligned the defines in headers
  Changes for v2:
  - Add clk.o to obj-y
  - Don't probe before relocation

 drivers/clk/kendryte/Kconfig|   2 +-
 drivers/clk/kendryte/Makefile   |   2 +-
 drivers/clk/kendryte/clk.c  | 390 
 drivers/clk/kendryte/clk.h  |  27 ++
 include/dt-bindings/clock/k210-sysctl.h |  53 
 include/dt-bindings/mfd/k210-sysctl.h   |  38 +++
 6 files changed, 510 insertions(+), 2 deletions(-)
 create mode 100644 drivers/clk/kendryte/clk.c
 create mode 100644 drivers/clk/kendryte/clk.h
 create mode 100644 include/dt-bindings/clock/k210-sysctl.h
 create mode 100644 include/dt-bindings/mfd/k210-sysctl.h

diff --git a/drivers/clk/kendryte/Kconfig b/drivers/clk/kendryte/Kconfig
index 7b69c8afaf..073fca0781 100644
--- a/drivers/clk/kendryte/Kconfig
+++ b/drivers/clk/kendryte/Kconfig
@@ -1,6 +1,6 @@
 config CLK_K210
bool "Clock support for Kendryte K210"
-   depends on CLK && CLK_CCF
+   depends on CLK && CLK_CCF && CLK_COMPOSITE_CCF
help
  This enables support clock driver for Kendryte K210 platforms.
 
diff --git a/drivers/clk/kendryte/Makefile b/drivers/clk/kendryte/Makefile
index c56d93ea1c..d26bce954f 100644
--- a/drivers/clk/kendryte/Makefile
+++ b/drivers/clk/kendryte/Makefile
@@ -1 +1 @@
-obj-y += pll.o
+obj-y += clk.o pll.o
diff --git a/drivers/clk/kendryte/clk.c b/drivers/clk/kendryte/clk.c
new file mode 100644
index 00..aaa7420c84
--- /dev/null
+++ b/drivers/clk/kendryte/clk.c
@@ -0,0 +1,390 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Sean Anderson 
+ */
+#include "clk.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pll.h"
+
+static ulong k210_clk_get_rate(struct clk *clk)
+{
+   struct clk *c;
+   int err = clk_get_by_id(clk->id, );
+
+   if (err)
+   return err;
+   return clk_get_rate(c);
+}
+
+static ulong k210_clk_set_rate(struct clk *clk, unsigned long rate)
+{
+   struct clk *c;
+   int err = clk_get_by_id(clk->id, );
+
+   if (err)
+   return err;
+   return clk_set_rate(c, rate);
+}
+
+static int k210_clk_set_parent(struct clk *clk, struct clk *parent)
+{
+   struct clk *c, *p;
+   int err = clk_get_by_id(clk->id, );
+
+   if (err)
+   return err;
+   
+   err = clk_get_by_id(parent->id, );
+   if (err)
+   return err;
+
+   return clk_set_parent(c, p);
+}
+
+static int k210_clk_endisable(struct clk *clk, bool enable)
+{
+   struct clk *c;
+   int err = clk_get_by_id(clk->id, );
+
+   if (err)
+   return err;
+   return enable ? clk_enable(c) : clk_disable(c);
+}
+
+static int k210_clk_enable(struct clk *clk)
+{
+   return k210_clk_endisable(clk, true);
+}
+
+static int k210_clk_disable(struct clk *clk)
+{
+   return k210_clk_endisable(clk, false);
+}
+
+static const struct clk_ops k210_clk_ops = {
+   .set_rate = k210_clk_set_rate,
+   .get_rate = k210_clk_get_rate,
+   .set_parent = k210_clk_set_parent,
+   .enable = k210_clk_enable,
+   .disable = k210_clk_disable,
+};
+
+/* The first clock is in0, which is filled in by k210_clk_probe */
+static const char *generic_sels[] = { NULL, "pll0", };
+static const char *aclk_sels[] = { "in0_half", "pll0_half", };
+static const char *pll2_sels[] = { NULL, "pll0", "pll1", };
+
+static struct clk_divider *k210_clk_comp_div_flags(void __iomem *reg, u8 shift,
+  u8 width, u8 flags)
+{
+   struct clk_divider *div;
+
+   div = kzalloc(sizeof(*div), GFP_KERNEL);
+   if (!div)
+   return div;
+   div->reg = reg;
+   div->shift = shift;
+   div->width = width;
+   div->flags = flags;
+   return div;
+}
+
+static inline struct clk_divider *k210_clk_comp_div(void __iomem *reg, u8 
shift,
+   u8 width)
+{
+   return k210_clk_comp_div_flags(reg, shift, width, 

[PATCH v3 08/12] riscv: Allow use of reset drivers

2020-02-02 Thread Sean Anderson
Currently, one cannot use a reset driver on RISC-V. Follow the MIPS example, and
disable the default reset handler when the sysreset driver is enabled.

Signed-off-by: Sean Anderson 
---
  Changes for v3:
  - New

 arch/riscv/lib/reset.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/riscv/lib/reset.c b/arch/riscv/lib/reset.c
index b8cecb309d..6cf6387f10 100644
--- a/arch/riscv/lib/reset.c
+++ b/arch/riscv/lib/reset.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 
+#ifndef CONFIG_SYSRESET
 int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
printf("resetting ...\n");
@@ -15,3 +16,4 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
 
return 0;
 }
+#endif
-- 
2.25.0



[PATCH v3 07/12] riscv: Add option to support RISC-V privileged spec 1.9.1

2020-02-02 Thread Sean Anderson
Some older processors (notably the Kendryte K210) use an older version of the
RISC-V privileged specification. The primary changes between the old and new are
in virtual memory, and in the merging of three separate counter enable CSRs.
Using the new CSR on an old processor causes an illegal instruction exception.
This patch adds an option to use the old CSRs instead of the new one.

Signed-off-by: Sean Anderson 
---
Changes for v3:
  - Renamed from "riscv: Add option to disable writes to mcounteren"
  - Added original functionality back for older priv specs.
Changes for v2:
  - Moved forward in the patch series

 arch/riscv/Kconfig   | 10 ++
 arch/riscv/cpu/cpu.c |  6 ++
 arch/riscv/include/asm/csr.h |  6 ++
 3 files changed, 22 insertions(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 85e15ebffa..87c40f6c4c 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -222,6 +222,16 @@ config XIP
  from a NOR flash memory without copying the code to ram.
  Say yes here if U-Boot boots from flash directly.
 
+config RISCV_PRIV_1_9_1
+   bool "Use version 1.9.1 of the RISC-V priviledged specification"
+   help
+ Older versions of the RISC-V priviledged specification had
+ separate counter enable CSRs for each privilege mode. Writing
+ to the unified mcounteren CSR on a processor implementing the
+ old specification will result in an illegal instruction
+ exception. In addition to counter CSR changes, the way virtual
+ memory is configured was also changed.
+
 config STACK_SIZE_SHIFT
int
default 14
diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index e457f6acbf..83cb6557cd 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -89,7 +89,13 @@ int arch_cpu_init_dm(void)
 * Enable perf counters for cycle, time,
 * and instret counters only
 */
+#ifdef CONFIG_RISCV_PRIV_1_9_1
+   /* FIXME: Can't use the macro for some reason... */
+   csr_write(mscounteren, GENMASK(2, 0));
+   csr_write(mucounteren, GENMASK(2, 0));
+#else
csr_write(CSR_MCOUNTEREN, GENMASK(2, 0));
+#endif
 
/* Disable paging */
if (supports_extension('s'))
diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h
index d1520743a2..c16b65d3f3 100644
--- a/arch/riscv/include/asm/csr.h
+++ b/arch/riscv/include/asm/csr.h
@@ -93,7 +93,13 @@
 #define CSR_MISA   0x301
 #define CSR_MIE0x304
 #define CSR_MTVEC  0x305
+#ifdef RISCV_PRIV_1_9_1
+#define CSR_MUCOUNTEREN 0x320
+#define CSR_MSCOUNTEREN 0x321
+#define CSR_MHCOUNTEREN 0x322
+#else
 #define CSR_MCOUNTEREN 0x306
+#endif
 #define CSR_MSCRATCH   0x340
 #define CSR_MEPC   0x341
 #define CSR_MCAUSE 0x342
-- 
2.25.0



[PATCH v3 06/12] riscv: Add headers for asm/global_data.h

2020-02-02 Thread Sean Anderson
This header depended on bd_t and ulong, but did not include the appropriate
headers.

Signed-off-by: Sean Anderson 
---
 arch/riscv/include/asm/global_data.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/riscv/include/asm/global_data.h 
b/arch/riscv/include/asm/global_data.h
index b74bd7e738..4f0c12b402 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -11,6 +11,8 @@
 #define __ASM_GBL_DATA_H
 
 #include 
+#include 
+#include 
 
 /* Architecture-specific global data */
 struct arch_global_data {
-- 
2.25.0



[PATCH v3 05/12] dm: Add support for simple-pm-bus

2020-02-02 Thread Sean Anderson
This type of bus is used in Linux to designate busses which have power domains
and/or clocks which need to be enabled before their child devices can be used.
Because power domains are automatically enabled before probing in u-boot, we
just need to enable any clocks present.

Signed-off-by: Sean Anderson 
---
  Changes for v3:
  - New

 .../bus/simple-pm-bus.txt | 44 ++
 drivers/core/simple-bus.c | 57 ++-
 2 files changed, 99 insertions(+), 2 deletions(-)
 create mode 100644 doc/device-tree-bindings/bus/simple-pm-bus.txt

diff --git a/doc/device-tree-bindings/bus/simple-pm-bus.txt 
b/doc/device-tree-bindings/bus/simple-pm-bus.txt
new file mode 100644
index 00..6f15037131
--- /dev/null
+++ b/doc/device-tree-bindings/bus/simple-pm-bus.txt
@@ -0,0 +1,44 @@
+Simple Power-Managed Bus
+
+
+A Simple Power-Managed Bus is a transparent bus that doesn't need a real
+driver, as it's typically initialized by the boot loader.
+
+However, its bus controller is part of a PM domain, or under the control of a
+functional clock.  Hence, the bus controller's PM domain and/or clock must be
+enabled for child devices connected to the bus (either on-SoC or externally)
+to function.
+
+While "simple-pm-bus" follows the "simple-bus" set of properties, as specified
+in the Devicetree Specification, it is not an extension of "simple-bus".
+
+
+Required properties:
+  - compatible: Must contain at least "simple-pm-bus".
+   Must not contain "simple-bus".
+   It's recommended to let this be preceded by one or more
+   vendor-specific compatible values.
+  - #address-cells, #size-cells, ranges: Must describe the mapping between
+   parent address and child address spaces.
+
+Optional platform-specific properties for clock or PM domain control (at least
+one of them is required):
+  - clocks: Must contain a reference to the functional clock(s),
+  - power-domains: Must contain a reference to the PM domain.
+Please refer to the binding documentation for the clock and/or PM domain
+providers for more details.
+
+
+Example:
+
+   bsc: bus@fec1 {
+   compatible = "renesas,bsc-sh73a0", "renesas,bsc",
+"simple-pm-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0 0x2000>;
+   reg = <0xfec1 0x400>;
+   interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <_clk>;
+   power-domains = <_a4s>;
+   };
diff --git a/drivers/core/simple-bus.c b/drivers/core/simple-bus.c
index 7fc23ef82d..d94567e98d 100644
--- a/drivers/core/simple-bus.c
+++ b/drivers/core/simple-bus.c
@@ -5,6 +5,11 @@
 
 #include 
 #include 
+#include 
+
+#define SIMPLE_BUS 0
+#define SIMPLE_MFD 1
+#define SIMPLE_PM_BUS 2
 
 struct simple_bus_plat {
u32 base;
@@ -50,9 +55,55 @@ UCLASS_DRIVER(simple_bus) = {
.per_device_platdata_auto_alloc_size = sizeof(struct simple_bus_plat),
 };
 
+static const int generic_simple_bus_probe(struct udevice *dev)
+{
+#if CONFIG_IS_ENABLED(CLK)
+   int ret;
+   struct clk_bulk *bulk;
+   ulong type = dev_get_driver_data(dev);
+
+   if (type == SIMPLE_PM_BUS) {
+   bulk = kzalloc(sizeof(*bulk), GFP_KERNEL);
+   if (!bulk)
+   return -ENOMEM;
+
+   ret = clk_get_bulk(dev, bulk);
+   if (ret)
+   return ret;
+   
+   ret = clk_enable_bulk(bulk);
+   if (ret && ret != -ENOSYS && ret != -ENOTSUPP) {
+   clk_release_bulk(bulk);
+   return ret;
+   }
+   dev->priv = bulk;
+   }
+#endif
+   return 0;
+}
+
+static const int generic_simple_bus_remove(struct udevice *dev)
+{
+   int ret = 0;
+#if CONFIG_IS_ENABLED(CLK)
+   struct clk_bulk *bulk;
+   ulong type = dev_get_driver_data(dev);
+
+   if (type == SIMPLE_PM_BUS) {
+   bulk = dev_get_priv(dev);
+   ret = clk_release_bulk(bulk);
+   kfree(bulk);
+   if (ret == -ENOSYS)
+   ret = 0;
+   }
+#endif
+   return ret;
+}
+
 static const struct udevice_id generic_simple_bus_ids[] = {
-   { .compatible = "simple-bus" },
-   { .compatible = "simple-mfd" },
+   { .compatible = "simple-bus", .data = SIMPLE_BUS },
+   { .compatible = "simple-mfd", .data = SIMPLE_MFD },
+   { .compatible = "simple-pm-bus", .data = SIMPLE_PM_BUS },
{ }
 };
 
@@ -60,5 +111,7 @@ U_BOOT_DRIVER(simple_bus_drv) = {
.name   = "generic_simple_bus",
.id = UCLASS_SIMPLE_BUS,
.of_match = generic_simple_bus_ids,
+   .probe = generic_simple_bus_probe,
+   .remove = generic_simple_bus_remove,
.flags  = DM_FLAG_PRE_RELOC,
 };
-- 
2.25.0



[PATCH v3 04/12] reset: Add generic reset driver

2020-02-02 Thread Sean Anderson
This patch adds a generic reset driver. It is designed to be useful when one has
a register in a regmap which contains bits that reset other devices. I thought
this seemed like a very generic use, so here is a generic driver. The overall
structure has been modeled on the syscon-reboot driver.

Signed-off-by: Sean Anderson 
---
  Changes for v3:
  - New

 .../reset/syscon-reset.txt| 36 +
 drivers/reset/Kconfig |  6 +-
 drivers/reset/Makefile|  1 +
 drivers/reset/reset-syscon.c  | 79 +++
 4 files changed, 121 insertions(+), 1 deletion(-)
 create mode 100644 doc/device-tree-bindings/reset/syscon-reset.txt
 create mode 100644 drivers/reset/reset-syscon.c

diff --git a/doc/device-tree-bindings/reset/syscon-reset.txt 
b/doc/device-tree-bindings/reset/syscon-reset.txt
new file mode 100644
index 00..47c1226567
--- /dev/null
+++ b/doc/device-tree-bindings/reset/syscon-reset.txt
@@ -0,0 +1,36 @@
+Generic SYSCON mapped register reset driver
+
+This is a generic reset driver using syscon to map the reset register.
+The reset is generally performed with a write to the reset register
+defined by the register map pointed by syscon reference plus the offset and
+shifted by the reset specifier/
+
+To assert a reset on some device, the equivalent of the following operation is
+performed, where reset_id is the reset specifier from the device's resets
+property. 
+
+   if (BIT(reset_id) & mask)
+   regmap[offset][reset_id] = assert-high;
+
+Required properties:
+- compatible: should contain "syscon-reset"
+- #reset-cells: must be 1
+- regmap: this is phandle to the register map node
+- offset: offset in the register map for the reboot register (in bytes)
+
+Optional properties:
+- mask: accept only the reset specifiers defined by the mask (32 bit)
+- assert-high: Bit to write when asserting a reset. Defaults to 1.
+
+Default will be little endian mode, 32 bit access only.
+
+Example:
+
+   reset-controller {
+   compatible = "syscon-reset";
+   #reset-cells = <1>;
+   regmap = <>;
+   offset = <0x20>;
+   mask = <0x27FF>;
+   assert-high = <0>;
+   };
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 75ccd65799..759d659c82 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -147,5 +147,9 @@ config RESET_IMX7
default y
help
  Support for reset controller on i.MX7/8 SoCs.
-
+config RESET_SYSCON
+   bool "Enable generic syscon reset driver support"
+   depends on DM_RESET
+   help
+ Support generic syscon mapped register reset devices.
 endmenu
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 0a044d5d8c..433f1eca54 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_RESET_MTMIPS) += reset-mtmips.o
 obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_RESET_HISILICON) += reset-hisilicon.o
 obj-$(CONFIG_RESET_IMX7) += reset-imx7.o
+obj-$(CONFIG_RESET_SYSCON) += reset-syscon.o
diff --git a/drivers/reset/reset-syscon.c b/drivers/reset/reset-syscon.c
new file mode 100644
index 00..db58b7705a
--- /dev/null
+++ b/drivers/reset/reset-syscon.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Sean Anderson
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct syscon_reset_priv {
+   struct regmap *regmap;
+   uint offset;
+   uint mask;
+   bool assert_high;
+};
+
+static int syscon_reset_request(struct reset_ctl *rst)
+{
+   struct syscon_reset_priv *priv = dev_get_priv(rst->dev);
+
+   if (BIT(rst->id) & priv->mask)
+   return 0;
+   else
+   return -EINVAL;
+}
+
+static int syscon_reset_assert(struct reset_ctl *rst)
+{
+   struct syscon_reset_priv *priv = dev_get_priv(rst->dev);
+
+   return regmap_update_bits(priv->regmap, priv->offset, BIT(rst->id),
+ priv->assert_high);
+}
+
+static int syscon_reset_deassert(struct reset_ctl *rst)
+{
+   struct syscon_reset_priv *priv = dev_get_priv(rst->dev);
+
+   return regmap_update_bits(priv->regmap, priv->offset, BIT(rst->id),
+ !priv->assert_high);
+}
+
+static const struct reset_ops syscon_reset_ops = {
+   .request = syscon_reset_request,
+   .rst_assert = syscon_reset_assert,
+   .rst_deassert = syscon_reset_deassert,
+};
+
+int syscon_reset_probe(struct udevice *dev)
+{
+   struct syscon_reset_priv *priv = dev_get_priv(dev);
+
+   priv->regmap = syscon_regmap_lookup_by_phandle(dev, "regmap");
+   if (IS_ERR(priv->regmap))
+   return -ENODEV;
+
+   priv->offset = dev_read_u32_default(dev, "offset", 0);
+   priv->mask = dev_read_u32_default(dev, "mask", 0);
+   priv->assert_high = 

[PATCH v3 03/12] clk: Unconditionally recursively en-/dis-able clocks

2020-02-02 Thread Sean Anderson
For clocks not in the CCF, their parents will not have UCLASS_CLK, so we just
enable them as normal. The enable count is local to the struct clk, but this
will never result in the actual en-/dis-able op being called (unless the same
struct clk is enabled twice).

For clocks in the CCF, we always traverse up the tree when enabling. Previously,
CCF clocks without id set would be skipped, stopping the traversal too early.

Signed-off-by: Sean Anderson 
---
  Changes for v3:
  - New.

 drivers/clk/clk-uclass.c | 58 +---
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 9aa8537004..87d101aab4 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -490,7 +490,6 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
 int clk_enable(struct clk *clk)
 {
const struct clk_ops *ops;
-   struct clk *clkp = NULL;
int ret;
 
debug("%s(clk=%p)\n", __func__, clk);
@@ -499,32 +498,28 @@ int clk_enable(struct clk *clk)
ops = clk_dev_ops(clk->dev);
 
if (CONFIG_IS_ENABLED(CLK_CCF)) {
-   /* Take id 0 as a non-valid clk, such as dummy */
-   if (clk->id && !clk_get_by_id(clk->id, )) {
-   if (clkp->enable_count) {
-   clkp->enable_count++;
-   return 0;
-   }
-   if (clkp->dev->parent &&
-   device_get_uclass_id(clkp->dev) == UCLASS_CLK) {
-   ret = 
clk_enable(dev_get_clk_ptr(clkp->dev->parent));
-   if (ret) {
-   printf("Enable %s failed\n",
-  clkp->dev->parent->name);
-   return ret;
-   }
+   if (clk->enable_count) {
+   clk->enable_count++;
+   return 0;
+   }
+   if (clk->dev->parent &&
+   device_get_uclass_id(clk->dev->parent) == UCLASS_CLK) {
+   ret = clk_enable(dev_get_clk_ptr(clk->dev->parent));
+   if (ret) {
+   printf("Enable %s failed\n",
+  clk->dev->parent->name);
+   return ret;
}
}
 
if (ops->enable) {
ret = ops->enable(clk);
if (ret) {
-   printf("Enable %s failed\n", clk->dev->name);
+   printf("Enable %s failed (error %d)\n", 
clk->dev->name, ret);
return ret;
}
}
-   if (clkp)
-   clkp->enable_count++;
+   clk->enable_count++;
} else {
if (!ops->enable)
return -ENOSYS;
@@ -550,7 +545,6 @@ int clk_enable_bulk(struct clk_bulk *bulk)
 int clk_disable(struct clk *clk)
 {
const struct clk_ops *ops;
-   struct clk *clkp = NULL;
int ret;
 
debug("%s(clk=%p)\n", __func__, clk);
@@ -559,29 +553,27 @@ int clk_disable(struct clk *clk)
ops = clk_dev_ops(clk->dev);
 
if (CONFIG_IS_ENABLED(CLK_CCF)) {
-   if (clk->id && !clk_get_by_id(clk->id, )) {
-   if (clkp->enable_count == 0) {
-   printf("clk %s already disabled\n",
-  clkp->dev->name);
-   return 0;
-   }
-
-   if (--clkp->enable_count > 0)
-   return 0;
+   if (clk->enable_count == 0) {
+   printf("clk %s already disabled\n",
+  clk->dev->name);
+   return 0;
}
 
+   if (--clk->enable_count > 0)
+   return 0;
+
if (ops->disable) {
ret = ops->disable(clk);
if (ret)
return ret;
}
 
-   if (clkp && clkp->dev->parent &&
-   device_get_uclass_id(clkp->dev) == UCLASS_CLK) {
-   ret = clk_disable(dev_get_clk_ptr(clkp->dev->parent));
+   if (clk->dev->parent &&
+   device_get_uclass_id(clk->dev) == UCLASS_CLK) {
+   ret = clk_disable(dev_get_clk_ptr(clk->dev->parent));
if (ret) {
-   printf("Disable %s failed\n",
-  clkp->dev->parent->name);
+   printf("Disable %s failed (error %d)\n",
+  

[PATCH v3 02/12] clk: Check that ops of composite clock components, exist before calling

2020-02-02 Thread Sean Anderson
clk_composite_ops was shared between all devices in the composite clock driver.
If one clock had a feature (such as supporting set_parent) which another clock
did not, it could call a null pointer dereference.

This patch does three things
1. It adds null-pointer checks to all composite clock functions.
2. It makes clk_composite_ops const and sets its functions at compile-time.
3. It adds some basic sanity checks to num_parents.

The combined effect of these changes is that any of mux, rate, or gate can be
NULL, and composite clocks will still function normally. Previously, at least
mux had to exist, since clk_composite_get_parent was used to determine the
parent for clk_register.

Signed-off-by: Sean Anderson 
---
  Changes for v3:
  - Don't return an error code where a no-op would be fine

 drivers/clk/clk-composite.c | 57 +++--
 1 file changed, 35 insertions(+), 22 deletions(-)

diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index d0f273d47f..5425f921ff 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -22,7 +22,10 @@ static u8 clk_composite_get_parent(struct clk *clk)
(struct clk *)dev_get_clk_ptr(clk->dev) : clk);
struct clk *mux = composite->mux;
 
-   return clk_mux_get_parent(mux);
+   if (mux)
+   return clk_mux_get_parent(mux);
+   else
+   return 0;
 }
 
 static int clk_composite_set_parent(struct clk *clk, struct clk *parent)
@@ -32,7 +35,10 @@ static int clk_composite_set_parent(struct clk *clk, struct 
clk *parent)
const struct clk_ops *mux_ops = composite->mux_ops;
struct clk *mux = composite->mux;
 
-   return mux_ops->set_parent(mux, parent);
+   if (mux && mux_ops)
+   return mux_ops->set_parent(mux, parent);
+   else
+   return -ENOSYS;
 }
 
 static unsigned long clk_composite_recalc_rate(struct clk *clk)
@@ -42,7 +48,10 @@ static unsigned long clk_composite_recalc_rate(struct clk 
*clk)
const struct clk_ops *rate_ops = composite->rate_ops;
struct clk *rate = composite->rate;
 
-   return rate_ops->get_rate(rate);
+   if (rate && rate_ops)
+   return rate_ops->get_rate(rate);
+   else
+   return clk_get_parent_rate(clk);
 }
 
 static ulong clk_composite_set_rate(struct clk *clk, unsigned long rate)
@@ -52,7 +61,10 @@ static ulong clk_composite_set_rate(struct clk *clk, 
unsigned long rate)
const struct clk_ops *rate_ops = composite->rate_ops;
struct clk *clk_rate = composite->rate;
 
-   return rate_ops->set_rate(clk_rate, rate);
+   if (rate && rate_ops)
+   return rate_ops->set_rate(clk_rate, rate);
+   else
+   return clk_get_rate(clk);
 }
 
 static int clk_composite_enable(struct clk *clk)
@@ -62,7 +74,10 @@ static int clk_composite_enable(struct clk *clk)
const struct clk_ops *gate_ops = composite->gate_ops;
struct clk *gate = composite->gate;
 
-   return gate_ops->enable(gate);
+   if (gate && gate_ops)
+   return gate_ops->enable(gate);
+   else
+   return 0;
 }
 
 static int clk_composite_disable(struct clk *clk)
@@ -72,15 +87,12 @@ static int clk_composite_disable(struct clk *clk)
const struct clk_ops *gate_ops = composite->gate_ops;
struct clk *gate = composite->gate;
 
-   gate_ops->disable(gate);
-
-   return 0;
+   if (gate && gate_ops)
+   return gate_ops->disable(gate);
+   else
+   return 0;
 }
 
-struct clk_ops clk_composite_ops = {
-   /* This will be set according to clk_register_composite */
-};
-
 struct clk *clk_register_composite(struct device *dev, const char *name,
   const char * const *parent_names,
   int num_parents, struct clk *mux,
@@ -94,7 +106,9 @@ struct clk *clk_register_composite(struct device *dev, const 
char *name,
struct clk *clk;
struct clk_composite *composite;
int ret;
-   struct clk_ops *composite_ops = _composite_ops;
+
+   if (!num_parents || (num_parents != 1 && !mux))
+   return ERR_PTR(-EINVAL);
 
composite = kzalloc(sizeof(*composite), GFP_KERNEL);
if (!composite)
@@ -103,8 +117,6 @@ struct clk *clk_register_composite(struct device *dev, 
const char *name,
if (mux && mux_ops) {
composite->mux = mux;
composite->mux_ops = mux_ops;
-   if (mux_ops->set_parent)
-   composite_ops->set_parent = clk_composite_set_parent;
mux->data = (ulong)composite;
}
 
@@ -113,11 +125,6 @@ struct clk *clk_register_composite(struct device *dev, 
const char *name,
clk = ERR_PTR(-EINVAL);
goto err;
}
-   composite_ops->get_rate = clk_composite_recalc_rate;
-
-

[PATCH v3 01/12] clk: Always use the supplied struct clk

2020-02-02 Thread Sean Anderson
CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could cause
problems with composite clocks. The individual clocks in a composite clock did
not have the ->dev field filled in. This was fine, because the device-specific
clock information would be used. However, since there was no ->dev, there was no
way to get the parent clock. This caused the recalc_rate method of the CCF
divider clock to fail. One option would be to use the clk->priv field to get the
composite clock and from there get the appropriate parent device. However, this
would tie the implementation to the composite clock. In general, different
devices should not rely on the contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied struct
clock. The composite clock now fills in the ->dev pointer of its child clocks.
This allows child clocks to make calls like clk_get_parent() without issue.

imx avoided the above problem by using a custom get_rate function with composite
clocks.

Signed-off-by: Sean Anderson 
---
  Changes for v3:
  - Documented new assumptions in the CCF
  - Wrapped docs to 80 columns

 doc/imx/clk/ccf.txt| 63 +-
 drivers/clk/clk-composite.c|  8 +
 drivers/clk/clk-divider.c  |  6 ++--
 drivers/clk/clk-fixed-factor.c |  3 +-
 drivers/clk/clk-gate.c |  6 ++--
 drivers/clk/clk-mux.c  | 12 +++
 drivers/clk/imx/clk-gate2.c|  4 +--
 7 files changed, 51 insertions(+), 51 deletions(-)

diff --git a/doc/imx/clk/ccf.txt b/doc/imx/clk/ccf.txt
index 36b60dc438..e40ac360e8 100644
--- a/doc/imx/clk/ccf.txt
+++ b/doc/imx/clk/ccf.txt
@@ -1,42 +1,37 @@
 Introduction:
 =
 
-This documentation entry describes the Common Clock Framework [CCF]
-port from Linux kernel (v5.1.12) to U-Boot.
+This documentation entry describes the Common Clock Framework [CCF] port from
+Linux kernel (v5.1.12) to U-Boot.
 
-This code is supposed to bring CCF to IMX based devices (imx6q, imx7
-imx8). Moreover, it also provides some common clock code, which would
-allow easy porting of CCF Linux code to other platforms.
+This code is supposed to bring CCF to IMX based devices (imx6q, imx7 imx8).
+Moreover, it also provides some common clock code, which would allow easy
+porting of CCF Linux code to other platforms.
 
 Design decisions:
 =
 
-* U-Boot's driver model [DM] for clk differs from Linux CCF. The most
-  notably difference is the lack of support for hierarchical clocks and
-  "clock as a manager driver" (single clock DTS node acts as a starting
-  point for all other clocks).
+* U-Boot's driver model [DM] for clk differs from Linux CCF. The most notably
+  difference is the lack of support for hierarchical clocks and "clock as a
+  manager driver" (single clock DTS node acts as a starting point for all other
+  clocks).
 
-* The clk_get_rate() caches the previously read data if CLK_GET_RATE_NOCACHE
-  is not set (no need for recursive access).
+* The clk_get_rate() caches the previously read data if CLK_GET_RATE_NOCACHE is
+  not set (no need for recursive access).
 
-* On purpose the "manager" clk driver (clk-imx6q.c) is not using large
-  table to store pointers to clocks - e.g. clk[IMX6QDL_CLK_USDHC2_SEL] = 
-  Instead we use udevice's linked list for the same class (UCLASS_CLK).
+* On purpose the "manager" clk driver (clk-imx6q.c) is not using large table to
+  store pointers to clocks - e.g. clk[IMX6QDL_CLK_USDHC2_SEL] =  Instead we
+  use udevice's linked list for the same class (UCLASS_CLK).
 
   Rationale:
   --
-When porting the code as is from Linux, one would need ~1KiB of RAM to
-store it. This is way too much if we do plan to use this driver in SPL.
+When porting the code as is from Linux, one would need ~1KiB of RAM to 
store
+it. This is way too much if we do plan to use this driver in SPL.
 
 * The "central" structure of this patch series is struct udevice and its
   uclass_priv field contains the struct clk pointer (to the originally created
   one).
 
-* Up till now U-Boot's driver model (DM) CLK operates on udevice (main
-  access to clock is by udevice ops)
-  In the CCF the access to struct clk (embodying pointer to *dev) is
-  possible via dev_get_clk_ptr() (it is a wrapper on dev_get_uclass_priv()).
-
 * To keep things simple the struct udevice's uclass_priv pointer is used to
   store back pointer to corresponding struct clk. However, it is possible to
   modify clk-uclass.c file and add there struct uc_clk_priv, which would have
@@ -45,13 +40,17 @@ Design decisions:
   setting .per_device_auto_alloc_size = sizeof(struct uc_clk_priv)) the
   uclass_priv stores the pointer to struct clk.
 
+* Non-CCF clocks do not have a pointer to a clock in clk->dev->priv. In the 
case
+  of composite 

[PATCH v3 00/12] riscv: Add Sipeed Maix support

2020-02-02 Thread Sean Anderson
This patch series adds support for Sipeed Maix boards and the
Kendryte K210 CPU. Currently, only the Maix Bit V2.0 is supported,
however other models are similar. This series depends on

(clk: Include missing headers for linux/clk-provider.h).
In addition, there are optional dependencies on

 and

(wdt: Add DM support for Designware WDT)
(riscv: Try to get cpu frequency from device tree)
(serial: Set baudrate on boot)

To flash u-boot to a maix bit, run
kflash -tp /dev/ -B bit_mic u-boot-dtb.bin

Boot output should look like the following:

U-Boot 2020.01-00455-gad03fd83e1 (Jan 15 2020 - 17:10:24 -0500)

DRAM:  8 MiB
MMC:   spi@5200:slot@0: 0
In:serial@3800
Out:   serial@3800
Err:   serial@3800
=> 

Note that spi does not work! I am trying to figure out what the problem is, but
for the moment the only way to boot something is to transfer it over serial.

Changes for v3:
  Remove patch to set RV64I as default.
  Remove patch for a separate sysctl driver.
  Split off cpu frequency patch into its own series.
  Reorder support/devicetree patches to come last.
  Add patch for reset driver.
  Add simple-pm-bus for busses with their own clocks.
  Add additional documentation.
  Reword mcounteren patch to refer to the RISC-V priv spec 1.9.1.
  Many devicetree changes
  Switch to "make savedefconfig" to generate the config

Changes for v2:
  Many bugfixes for the device tree.
  Modify the config to build without errors.
  Add support for keeping internal PLL frequencies in-range.
  Fix several rebase-induced artifacts.

Sean Anderson (12):
  clk: Always use the supplied struct clk
  clk: Check that ops of composite clock components exist before calling
  clk: Unconditionally recursively en-/dis-able clocks
  reset: Add generic reset driver
  dm: Add support for simple-pm-bus
  riscv: Add headers for asm/global_data.h
  riscv: Add option to support RISC-V privileged spec 1.9.1
  riscv: Allow use of reset drivers
  riscv: Add K210 pll support
  riscv: Add K210 clock support
  riscv: Add device tree for K210
  riscv: Add initial Sipeed Maix support

 arch/riscv/Kconfig|  14 +
 arch/riscv/cpu/cpu.c  |   6 +
 arch/riscv/dts/Makefile   |   1 +
 arch/riscv/dts/k210-maix-bit.dts  |  42 ++
 arch/riscv/dts/k210.dtsi  | 496 ++
 arch/riscv/include/asm/csr.h  |   6 +
 arch/riscv/include/asm/global_data.h  |   2 +
 arch/riscv/lib/reset.c|   2 +
 board/sipeed/maix/Kconfig |  51 ++
 board/sipeed/maix/MAINTAINERS |  10 +
 board/sipeed/maix/Makefile|   5 +
 board/sipeed/maix/maix.c  |   9 +
 configs/sipeed_maix_bitm_defconfig|  10 +
 doc/board/index.rst   |   1 +
 doc/board/kendryte/index.rst  |   9 +
 doc/board/kendryte/k210.rst   |  46 ++
 .../bus/simple-pm-bus.txt |  44 ++
 .../reset/syscon-reset.txt|  36 ++
 doc/imx/clk/ccf.txt   |  63 +-
 drivers/clk/Kconfig   |   1 +
 drivers/clk/Makefile  |   1 +
 drivers/clk/clk-composite.c   |  65 +-
 drivers/clk/clk-divider.c |   6 +-
 drivers/clk/clk-fixed-factor.c|   3 +-
 drivers/clk/clk-gate.c|   6 +-
 drivers/clk/clk-mux.c |  12 +-
 drivers/clk/clk-uclass.c  |  58 +-
 drivers/clk/imx/clk-gate2.c   |   4 +-
 drivers/clk/kendryte/Kconfig  |  12 +
 drivers/clk/kendryte/Makefile |   1 +
 drivers/clk/kendryte/clk.c| 390 +++
 drivers/clk/kendryte/clk.h|  27 +
 drivers/clk/kendryte/pll.c| 607 ++
 drivers/clk/kendryte/pll.h|  38 ++
 drivers/core/simple-bus.c |  57 +-
 drivers/reset/Kconfig |   6 +-
 drivers/reset/Makefile|   1 +
 drivers/reset/reset-syscon.c  |  79 +++
 include/configs/sipeed-maix.h |  19 +
 include/dt-bindings/clock/k210-sysctl.h   |  53 ++
 include/dt-bindings/mfd/k210-sysctl.h |  38 ++
 include/dt-bindings/reset/k210-sysctl.h   |  38 ++
 42 files changed, 2266 insertions(+), 109 deletions(-)
 create mode 100644 arch/riscv/dts/k210-maix-bit.dts
 create mode 100644 arch/riscv/dts/k210.dtsi
 create mode 100644 board/sipeed/maix/Kconfig
 create mode 100644 board/sipeed/maix/MAINTAINERS
 create mode 100644 board/sipeed/maix/Makefile
 create mode 

[PATCH] serial: Set baudrate on boot

2020-02-02 Thread Sean Anderson
Currently, the baud rate is never set on boot. This works ok when a previous
bootloader has configured the baudrate properly, or when the baudrate is set to
a reasonable default in the serial driver's probe(). However, when this is not
the case, we could be using a different baud rate than what was configured.

Signed-off-by: Sean Anderson 
---
 drivers/serial/serial-uclass.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index 0f5f1fa406..8aa542c32f 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -161,6 +161,7 @@ int serial_init(void)
 #if CONFIG_IS_ENABLED(SERIAL_PRESENT)
serial_find_console_or_panic();
gd->flags |= GD_FLG_SERIAL_READY;
+   serial_setbrg();
 #endif
 
return 0;
-- 
2.25.0



Re: [PATCH 1/4] wdt: Add CONFIG_DESIGNWARE_WATCHDOG to Kconfig

2020-02-02 Thread Sean Anderson
> btw what's the motivation for this series, are you hitting some issues
> with the WDT on SoCFPGA ?

This watchdog appears on the Kendryte K210 CPU, which I am adding
support for. The rest of the board uses devicetree to configure drivers,
so I wanted to add support for this watchdog as well.


Re: [PATCH 1/4] wdt: Add CONFIG_DESIGNWARE_WATCHDOG to Kconfig

2020-02-02 Thread Marek Vasut
On 2/2/20 6:48 PM, Sean Anderson wrote:
> On 2/2/20 12:40 PM, Marek Vasut wrote:
>> On 2/2/20 6:23 PM, Sean Anderson wrote:
>>> CONFIG_DESIGNWARE_WATCHDOG is only defined if CONFIG_HW_WATCHDOG is
>>> defined, and this is never defined in headers (or in the defconfigs).
>>
>> This is what I see in socfpga_soc64_common.h on u-boot/master:
>> 153 #ifdef CONFIG_SPL_BUILD
>> 154 #define CONFIG_HW_WATCHDOG
> 
> Huh, there it is. I guess I expected the usage to be the same as
> socfpga_common.h. Would it be best to add DESIGNWARE_WATCHDOG to the
> appropriate Kconfigs, defconfigs, or leave it in the header?

I also had to look around, because I knew it was somewhere and the WDT
should've generally been enabled on socfpga (at least the 32bit ones).

Kconfig is indeed the way to go. For bulk enabling config options, it is
better to put them as "select" entry in arch/arm/Kconfig or
arch/arm/mach-foo/Kconfig for the entire platform, so all the boards
pick the option up without any changes to zillion defconfigs.

 The patch is wrong, see above. Also, it's missing a SoB line.
>>>
>>> Ah, I just noticed that, thanks for pointing that out.
>>
>> Note that I updated u-boot-socfpga/master and sent a PR just now (thanks
>> for reminding me of that), it contains the DW WDT patches that were
>> posted to the ML some time ago. You want to rebase the series on top of
>> that.
> 
> Ok, I will do that for v2.

Thanks.

btw what's the motivation for this series, are you hitting some issues
with the WDT on SoCFPGA ?


Re: Pull request: u-boot-rockchip-20200130

2020-02-02 Thread Tom Rini
On Sat, Feb 01, 2020 at 01:16:12PM +0800, Kever Yang wrote:

> Hi Tom,
> 
> Please pull the rockchip updates:
> - Support redundant boot for rk3399
> - Support binman for rockchip platform
> - Update ram driver and add ddr4 support for rk3328
> 
> Travis:
> https://travis-ci.org/keveryang/u-boot/builds/629913727
> 
> This PR remove the SF support in distro bootcmd.
> 
> Thanks,
> - Kever
> 
> The following changes since commit e7ab1cb3f0421ad8e8435a8258790e238c623ea2:
> 
>   Merge tag 'for-v2020.04' of 
> https://gitlab.denx.de/u-boot/custodians/u-boot-i2c (2020-01-29 09:34:13 
> -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git 
> tags/u-boot-rockchip-20200130
> 
> for you to fetch changes up to c8343e93220a487f332441cff780a702ca2ce3a9:
> 
>   configs: firefly-rk3399: Enable CONFIG_MISC_INIT_R and ROCKCHIP_EFUSE 
> (2020-01-30 11:44:02 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/4] wdt: Add CONFIG_DESIGNWARE_WATCHDOG to Kconfig

2020-02-02 Thread Sean Anderson
On 2/2/20 12:40 PM, Marek Vasut wrote:
> On 2/2/20 6:23 PM, Sean Anderson wrote:
>> CONFIG_DESIGNWARE_WATCHDOG is only defined if CONFIG_HW_WATCHDOG is
>> defined, and this is never defined in headers (or in the defconfigs).
> 
> This is what I see in socfpga_soc64_common.h on u-boot/master:
> 153 #ifdef CONFIG_SPL_BUILD
> 154 #define CONFIG_HW_WATCHDOG

Huh, there it is. I guess I expected the usage to be the same as
socfpga_common.h. Would it be best to add DESIGNWARE_WATCHDOG to the
appropriate Kconfigs, defconfigs, or leave it in the header?

> 
>>> The patch is wrong, see above. Also, it's missing a SoB line.
>>
>> Ah, I just noticed that, thanks for pointing that out.
> 
> Note that I updated u-boot-socfpga/master and sent a PR just now (thanks
> for reminding me of that), it contains the DW WDT patches that were
> posted to the ML some time ago. You want to rebase the series on top of
> that.

Ok, I will do that for v2.

--Sean


Re: [PATCH 1/4] wdt: Add CONFIG_DESIGNWARE_WATCHDOG to Kconfig

2020-02-02 Thread Marek Vasut
On 2/2/20 6:23 PM, Sean Anderson wrote:
> On 2/2/20 12:15 PM, Marek Vasut wrote:
>> On 2/2/20 6:10 PM, Sean Anderson wrote:
>>> Currently this is set from headers. No board has this set by default
>>
>> Please check where socfpga_common.h and socfpga_soc64_common.h are
>> included. This should then make it clear that this statement in not true.
>>
>> , so we
>>> don't need to modify any configs.
> 
> CONFIG_DESIGNWARE_WATCHDOG is only defined if CONFIG_HW_WATCHDOG is
> defined, and this is never defined in headers (or in the defconfigs).

This is what I see in socfpga_soc64_common.h on u-boot/master:
153 #ifdef CONFIG_SPL_BUILD
154 #define CONFIG_HW_WATCHDOG

>> The patch is wrong, see above. Also, it's missing a SoB line.
> 
> Ah, I just noticed that, thanks for pointing that out.

Note that I updated u-boot-socfpga/master and sent a PR just now (thanks
for reminding me of that), it contains the DW WDT patches that were
posted to the ML some time ago. You want to rebase the series on top of
that.


[PATCH v2 2/2] riscv: Enable cpu clock if it is present

2020-02-02 Thread Sean Anderson
The cpu clock is probably already enabled if we are executing code
(though we could be executing from a different core). This patch
prevents the cpu clock or its parents from being disabled.

Signed-off-by: Sean Anderson 
---
  This doesn't strictly depend on the previous patch, but it doesn't
  make too much sense without it.

  Changes for v2:
- New
 drivers/cpu/riscv_cpu.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/cpu/riscv_cpu.c b/drivers/cpu/riscv_cpu.c
index 5309a49e60..52b74d9e69 100644
--- a/drivers/cpu/riscv_cpu.c
+++ b/drivers/cpu/riscv_cpu.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
  * Copyright (C) 2018, Bin Meng 
+ * Copyright (C) 2020, Sean Anderson 
  */
 
 #include 
@@ -116,6 +117,24 @@ static int riscv_cpu_bind(struct udevice *dev)
return 0;
 }
 
+static int riscv_cpu_probe(struct udevice *dev)
+{
+   int ret = 0;
+   struct clk clk;
+
+   /* Get a clock if it exists */
+   ret = clk_get_by_index(dev, 0, );
+   if (ret)
+   return 0;
+
+   ret = clk_enable();
+   clk_free();
+   if (ret == -ENOSYS || ret == -ENOTSUPP)
+   return 0;
+   else
+   return ret;
+}
+
 static const struct cpu_ops riscv_cpu_ops = {
.get_desc   = riscv_cpu_get_desc,
.get_info   = riscv_cpu_get_info,
@@ -132,6 +151,7 @@ U_BOOT_DRIVER(riscv_cpu) = {
.id = UCLASS_CPU,
.of_match = riscv_cpu_ids,
.bind = riscv_cpu_bind,
+   .probe = riscv_cpu_probe,
.ops = _cpu_ops,
.flags = DM_FLAG_PRE_RELOC,
 };
-- 
2.25.0


[PATCH v2 1/2] riscv: Try to get cpu frequency from device tree

2020-02-02 Thread Sean Anderson
Instead of always using the "clock-frequency" property to determine cpu
frequency, try using a clock in "clocks" if it exists. This patch also fixes a
bug where there could be spurious higher frequencies if sizeof(u32) !=
sizeof(ulong).

Signed-off-by: Sean Anderson 
---
  This patch is the combination of the patches
  https://patchwork.ozlabs.org/patch/1223933/
  https://patchwork.ozlabs.org/patch/1224957/
  "riscv: Fix incorrect cpu frequency on RV64"
  "riscv: Try to get cpu frequency from device tree"

  Changes for v2:
  - Renamed err to ret
 drivers/cpu/riscv_cpu.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/cpu/riscv_cpu.c b/drivers/cpu/riscv_cpu.c
index 28ad0aa30f..5309a49e60 100644
--- a/drivers/cpu/riscv_cpu.c
+++ b/drivers/cpu/riscv_cpu.c
@@ -3,6 +3,7 @@
  * Copyright (C) 2018, Bin Meng 
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -27,9 +28,24 @@ static int riscv_cpu_get_desc(struct udevice *dev, char 
*buf, int size)
 
 static int riscv_cpu_get_info(struct udevice *dev, struct cpu_info *info)
 {
+   int ret;
+   struct clk clk;
const char *mmu;
 
-   dev_read_u32(dev, "clock-frequency", (u32 *)>cpu_freq);
+   /* Zero out the frequency, in case sizeof(ulong) != sizeof(u32) */
+   info->cpu_freq = 0;
+
+   /* First try getting the frequency from the assigned clock */
+   ret = clk_get_by_index(dev, 0, );
+   if (!ret) {
+   ret = clk_get_rate();
+   if (!IS_ERR_VALUE(ret))
+   info->cpu_freq = ret;
+   clk_free();
+   }
+
+   if (!info->cpu_freq)
+   dev_read_u32(dev, "clock-frequency", (u32 *)>cpu_freq);
 
mmu = dev_read_string(dev, "mmu-type");
if (!mmu)
-- 
2.25.0



Re: [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R

2020-02-02 Thread Marek Vasut
On 1/31/20 9:15 AM, Patrick DELAUNAY wrote:
> Hi Marek,

Hi,

>> From: Marek Vasut 
>> Sent: jeudi 30 janvier 2020 03:23
>>
>> On 1/29/20 5:51 PM, Patrick DELAUNAY wrote:
>>> Hi Marek,
>>
>> Hi,
>>
 From: Marek Vasut 
 Sent: mardi 28 janvier 2020 13:16

 On 1/28/20 10:11 AM, Patrick Delaunay wrote:
> From: Antonio Borneo 
>
> LTDC modifies the clock frequency to adapt it to the display. Such
> frequency change is not detected by the FDCAN driver that instead
> cache the value at probe and pretend to use it later.
>
> Keep the LTDC alone on PLL4_Q by moving the FDCAN to PLL4_R.

 Now this looks like a grisly workaround. Can you fix the LTDC driver
 to do something sane on boards which didn't update bootloader yet ?
>>>
>>> In fact it more a issue in the initial clock-tree used when I upstream
>>> the ST board the first time... based on our delivery v1.0.0
>>>
>>> It is already corrected in downstream on v1.1.0:
>>> + For U-Boot =
>>> + https://github.com/STMicroelectronics/u-boot/commit/d62f14dece32e41c
>>> + 2854b9ff44aca7b8384aa8a0 For TF-A =
>>> + https://github.com/STMicroelectronics/arm-trusted-firmware/commit/9a
>>> + 24ceda6c3ba060d9acf2b26d069fedde9f0807
>>>
>>> The LTDC/DSI need to set the pixel clock according the panel configuration 
>>> and
>> settings: it is normal and needed.
>>>
>>> But If the pixel clock is shared with FDCAN, which expects that its input 
>>> clock is
>> fixed, an issue occur when the pixel clock change.
>>
>> I understand the problem you are trying to solve.
>>
>> What I think you are missing is that not everyone will update 
>> ATF/U-Boot/Linux in
>> lockstep. That is the problem you need to deal with here.
> 
> I understood the possible issue and I hope that I will be not the case
> (at least for the ST Microelectronics boards).

Do I understand it correctly that you expect the customers who buy the
ST chip to update bootloader in lockstep with the kernel in systems
which are deployed today ?

No, this does not work. If you have a working bootloader and your kernel
fails to start, that is something you can recover from, If your
bootloader fails to start and you need to dig an embedded system buried
who-knows-where or recall a lot of systems because of a failed
bootloader update, that would be a disaster.

> We are aware of the possible issue to fixe these clocks in first stage 
> bootloader but after a long
> debate, we don't found a better solution, with the constraints:
> - M4 firmware require clock initialization before start and it can be loaded 
> by U-Boot
> - clock tree is generated by CubeMX tools which generate device tree (for 
> bootloaders and kernel)
> - "assigned-clock" management in Linux kernel could lead us to a race 
> condition for shared clock
> 
> We spent a long time to found a clock tree which respect all the constraints 
> of the SOC
> before to our first release v1.0 and before I upstream the stm32mp1 support 
> in U-Boot.
> 
> Then I wait a year before to upstream the patches on clock tree 
> initialization (and the second
> release v1.2) to avoid too many iteration.
>  And this patch on FDCAN is the only issue found on the initial clock tree.
> 
> Today I think (hope?) it will be the last patch on this part.

You will keep finding clock issues and no , this will not be the last
patch which fixes a clock issue.

So what solution is there for those who can only update the kernel ?


Re: [PATCH 4/4] wdt: Add DM support for Designware WDT

2020-02-02 Thread Sean Anderson
On 2/2/20 12:13 PM, Sean Anderson wrote:
> The binding used is the same as Linux's.
> ---
>  doc/device-tree-bindings/watchdog/dw_wdt.txt | 24 +++
>  drivers/watchdog/designware_wdt.c| 67 
>  2 files changed, 91 insertions(+)
>  create mode 100644 doc/device-tree-bindings/watchdog/dw_wdt.txt

Signed-off-by: Sean Anderson 


Re: [PATCH 1/4] wdt: Add CONFIG_DESIGNWARE_WATCHDOG to Kconfig

2020-02-02 Thread Sean Anderson
On 2/2/20 12:10 PM, Sean Anderson wrote:
> Currently this is set from headers. No board has this set by default, so we
> don't need to modify any configs.
> ---
>  drivers/watchdog/Kconfig   | 7 +++
>  include/configs/socfpga_common.h   | 1 -
>  include/configs/socfpga_soc64_common.h | 1 -
>  3 files changed, 7 insertions(+), 2 deletions(-)

Signed-off-by: Sean Anderson 


Re: [PATCH 2/4] arm: Move asm/utils.h to log2.h

2020-02-02 Thread Sean Anderson
On 2/2/20 12:12 PM, Sean Anderson wrote:
> This header is needed outside of the arm architecture by the designware wdt
> driver.
> ---
>  arch/arm/cpu/armv7/cache_v7.c  | 2 +-
>  arch/arm/mach-davinci/spl.c| 2 +-
>  arch/arm/mach-omap2/clocks-common.c| 2 +-
>  arch/arm/mach-omap2/emif-common.c  | 2 +-
>  arch/arm/mach-omap2/omap4/emif.c   | 2 +-
>  arch/arm/mach-omap2/omap5/dra7xx_iodelay.c | 2 +-
>  arch/arm/mach-omap2/omap5/emif.c   | 2 +-
>  arch/arm/mach-omap2/omap5/hwinit.c | 2 +-
>  arch/arm/mach-socfpga/spl_a10.c| 2 +-
>  arch/arm/mach-socfpga/spl_agilex.c | 2 +-
>  arch/arm/mach-socfpga/spl_gen5.c   | 2 +-
>  arch/arm/mach-socfpga/spl_s10.c| 2 +-
>  drivers/watchdog/designware_wdt.c  | 4 ++--
>  arch/arm/include/asm/utils.h => include/log2.h | 4 ++--
>  14 files changed, 16 insertions(+), 16 deletions(-)
>  rename arch/arm/include/asm/utils.h => include/log2.h (93%)

Signed-off-by: Sean Anderson 


Re: [PATCH 3/4] wdt: Remove dependencies on CONFIG_DW_WDT_* from Designware WDT

2020-02-02 Thread Sean Anderson
On 2/2/20 12:12 PM, Sean Anderson wrote:
> Currently, the designware watchdog driver depends in several places on the
> values of CONFIG_DW_WDT_ defines. This patch moves these uses to just the
> functions hw_watchdog_*.
> ---
>  drivers/watchdog/designware_wdt.c | 65 ---
>  1 file changed, 42 insertions(+), 23 deletions(-)

Signed-off-by: Sean Anderson 


Re: [PATCH 1/4] wdt: Add CONFIG_DESIGNWARE_WATCHDOG to Kconfig

2020-02-02 Thread Sean Anderson
On 2/2/20 12:15 PM, Marek Vasut wrote:
> On 2/2/20 6:10 PM, Sean Anderson wrote:
>> Currently this is set from headers. No board has this set by default
> 
> Please check where socfpga_common.h and socfpga_soc64_common.h are
> included. This should then make it clear that this statement in not true.
> 
> , so we
>> don't need to modify any configs.

CONFIG_DESIGNWARE_WATCHDOG is only defined if CONFIG_HW_WATCHDOG is
defined, and this is never defined in headers (or in the defconfigs).

> The patch is wrong, see above. Also, it's missing a SoB line.

Ah, I just noticed that, thanks for pointing that out.


[PULL] u-boot-usb/master

2020-02-02 Thread Marek Vasut
The following changes since commit 80e99adbe47d1c8590f9b971ac52257fdc51a5ec:

  Merge tag 'uniphier-v2020.04-2' of
https://gitlab.denx.de/u-boot/custodians/u-boot-uniphier (2020-01-31
13:26:28 -0500)

are available in the Git repository at:

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

for you to fetch changes up to 13cb7cc9e8e48eb888b13743f79ff02420405044:

  dfu: Add option to skip empty pages when flashing UBI images to NAND
(2020-02-02 18:19:52 +0100)


Guillermo RodrĂ­guez (1):
  dfu: Add option to skip empty pages when flashing UBI images to NAND

Vignesh Raghavendra (1):
  usb: cdns3: ep0: Invalidate cache before reading Setup Packet

 drivers/dfu/Kconfig | 7 +++
 drivers/dfu/dfu_nand.c  | 7 ++-
 drivers/usb/cdns3/ep0.c | 4 
 3 files changed, 17 insertions(+), 1 deletion(-)


[PULL] u-boot-socfpga/master

2020-02-02 Thread Marek Vasut
The following changes since commit 80e99adbe47d1c8590f9b971ac52257fdc51a5ec:

  Merge tag 'uniphier-v2020.04-2' of
https://gitlab.denx.de/u-boot/custodians/u-boot-uniphier (2020-01-31
13:26:28 -0500)

are available in the Git repository at:

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

for you to fetch changes up to 56c24875d92adcf214d97f5798e11c1b7b5e27fa:

  ddr: altera: Add DDR2 support to Gen5 driver (2020-02-02 18:18:05 +0100)


Ley Foon Tan (1):
  reset: socfpga: Poll for reset status after deassert reset

Marek Vasut (5):
  ARM: socfpga: Drop last use of socfpga_reset_manager
  watchdog: designware: Migrate CONFIG_DESIGNWARE_WATCHDOG to Kconfig
  watchdog: designware: Convert to DM and DT probing
  watchdog: designware: Optionally fetch clock and reset from DT
  ddr: altera: Add DDR2 support to Gen5 driver

 arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi |   4 ++
 arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi  |   4 ++
 arch/arm/mach-socfpga/include/mach/sdram_gen5.h   |  46
+++
 arch/arm/mach-socfpga/qts-filter.sh   |   2 +-
 arch/arm/mach-socfpga/spl_gen5.c  |   5 +--
 arch/arm/mach-socfpga/wrap_sdram_config.c |  64
+-
 configs/socfpga_stratix10_defconfig   |   3 ++
 configs/socfpga_vining_fpga_defconfig |   2 +
 drivers/ddr/altera/sdram_gen5.c   |   6 ++-
 drivers/ddr/altera/sequencer.c| 193
---
 drivers/ddr/altera/sequencer.h|   1 +
 drivers/reset/reset-socfpga.c |   6 ++-
 drivers/watchdog/Kconfig  |   7 +++
 drivers/watchdog/designware_wdt.c | 150
+++--
 include/configs/socfpga_common.h  |   3 --
 include/configs/socfpga_soc64_common.h|   7 ++-
 scripts/config_whitelist.txt  |   1 -
 17 files changed, 399 insertions(+), 105 deletions(-)


Re: [PATCH 1/4] wdt: Add CONFIG_DESIGNWARE_WATCHDOG to Kconfig

2020-02-02 Thread Marek Vasut
On 2/2/20 6:10 PM, Sean Anderson wrote:
> Currently this is set from headers. No board has this set by default

Please check where socfpga_common.h and socfpga_soc64_common.h are
included. This should then make it clear that this statement in not true.

, so we
> don't need to modify any configs.

The patch is wrong, see above. Also, it's missing a SoB line.


[PATCH 4/4] wdt: Add DM support for Designware WDT

2020-02-02 Thread Sean Anderson
The binding used is the same as Linux's.
---
 doc/device-tree-bindings/watchdog/dw_wdt.txt | 24 +++
 drivers/watchdog/designware_wdt.c| 67 
 2 files changed, 91 insertions(+)
 create mode 100644 doc/device-tree-bindings/watchdog/dw_wdt.txt

diff --git a/doc/device-tree-bindings/watchdog/dw_wdt.txt 
b/doc/device-tree-bindings/watchdog/dw_wdt.txt
new file mode 100644
index 00..eb0914420c
--- /dev/null
+++ b/doc/device-tree-bindings/watchdog/dw_wdt.txt
@@ -0,0 +1,24 @@
+Synopsys Designware Watchdog Timer
+
+Required Properties:
+
+- compatible   : Should contain "snps,dw-wdt"
+- reg  : Base address and size of the watchdog timer registers.
+- clocks   : phandle + clock-specifier for the clock that drives the
+   watchdog timer.
+
+Optional Properties:
+
+- interrupts   : The interrupt used for the watchdog timeout warning.
+- resets   : phandle pointing to the system reset controller with
+   line index for the watchdog.
+
+Example:
+
+   watchdog0: wd@ffd02000 {
+   compatible = "snps,dw-wdt";
+   reg = <0xffd02000 0x1000>;
+   interrupts = <0 171 4>;
+   clocks = <_base_clk>;
+   resets = < WDT0_RESET>;
+   };
diff --git a/drivers/watchdog/designware_wdt.c 
b/drivers/watchdog/designware_wdt.c
index 61c4046f50..1f7f4f0103 100644
--- a/drivers/watchdog/designware_wdt.c
+++ b/drivers/watchdog/designware_wdt.c
@@ -5,8 +5,10 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 
 #define DW_WDT_CR  0x00
 #define DW_WDT_TORR0x04
@@ -90,3 +92,68 @@ void hw_watchdog_init(void)
designware_wdt_init(_priv, CONFIG_WATCHDOG_TIMEOUT_MSECS);
 }
 #endif
+
+#ifdef CONFIG_WDT
+static int dw_wdt_reset(struct udevice *dev)
+{
+   struct designware_wdt_priv *priv = dev_get_priv(dev);
+
+   designware_wdt_reset(priv);
+
+   return 0;
+}
+
+static int dw_wdt_start(struct udevice *dev, u64 timeout, ulong flags)
+{
+   struct designware_wdt_priv *priv = dev_get_priv(dev);
+
+   designware_wdt_init(priv, timeout);
+
+   return 0;
+}
+
+static int dw_wdt_probe(struct udevice *dev)
+{
+   int ret;
+   ulong rate;
+   struct clk clk;
+   struct designware_wdt_priv *priv = dev_get_priv(dev);
+
+   priv->base = dev_read_addr_ptr(dev);
+   if (!priv->base)
+   return -ENOENT;
+
+   ret = clk_get_by_index(dev, 0, );
+   if (ret)
+   return ret;
+
+   rate = clk_get_rate();
+   if (IS_ERR_VALUE(rate)) {
+   clk_free();
+   return rate;
+   }
+   priv->clock_khz = rate / 1000;
+
+   return 0;
+}
+
+static const struct wdt_ops dw_wdt_ops = {
+   .start  = dw_wdt_start,
+   .reset  = dw_wdt_reset,
+};
+
+static const struct udevice_id dw_wdt_ids[] = {
+   { .compatible = "snps,dw-wdt" },
+   { },
+};
+
+U_BOOT_DRIVER(designware_wdt) = {
+   .name   = "designware_wdt",
+   .id = UCLASS_WDT,
+   .of_match   = dw_wdt_ids,
+   .probe  = dw_wdt_probe,
+   .ops= _wdt_ops,
+   .priv_auto_alloc_size = sizeof(struct designware_wdt_priv),
+   .flags  = DM_FLAG_PRE_RELOC,
+};
+#endif /* WDT */
-- 
2.25.0



[PATCH 3/4] wdt: Remove dependencies on CONFIG_DW_WDT_* from Designware WDT

2020-02-02 Thread Sean Anderson
Currently, the designware watchdog driver depends in several places on the
values of CONFIG_DW_WDT_ defines. This patch moves these uses to just the
functions hw_watchdog_*.
---
 drivers/watchdog/designware_wdt.c | 65 ---
 1 file changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/watchdog/designware_wdt.c 
b/drivers/watchdog/designware_wdt.c
index 3b97db1256..61c4046f50 100644
--- a/drivers/watchdog/designware_wdt.c
+++ b/drivers/watchdog/designware_wdt.c
@@ -17,57 +17,76 @@
 #define DW_WDT_CR_RMOD_VAL 0x00
 #define DW_WDT_CRR_RESTART_VAL 0x76
 
+struct designware_wdt_priv {
+   void __iomem *base;
+   ulong clock_khz;
+};
+
 /*
  * Set the watchdog time interval.
  * Counter is 32 bit.
  */
-static int designware_wdt_settimeout(unsigned int timeout)
+static int designware_wdt_settimeout(struct designware_wdt_priv *priv,
+u64 timeout)
 {
signed int i;
 
/* calculate the timeout range value */
-   i = (log_2_n_round_up(timeout * CONFIG_DW_WDT_CLOCK_KHZ)) - 16;
+   i = log_2_n_round_up(timeout * priv->clock_khz) - 16;
if (i > 15)
i = 15;
if (i < 0)
i = 0;
 
-   writel((i | (i << 4)), (CONFIG_DW_WDT_BASE + DW_WDT_TORR));
+   writel(i | (i << 4), priv->base + DW_WDT_TORR);
return 0;
 }
 
-static void designware_wdt_enable(void)
+static void designware_wdt_enable(struct designware_wdt_priv *priv)
 {
-   writel(((DW_WDT_CR_RMOD_VAL << DW_WDT_CR_RMOD_OFFSET) |
- (0x1 << DW_WDT_CR_EN_OFFSET)),
- (CONFIG_DW_WDT_BASE + DW_WDT_CR));
+   writel((DW_WDT_CR_RMOD_VAL << DW_WDT_CR_RMOD_OFFSET) |
+  (0x1 << DW_WDT_CR_EN_OFFSET), priv->base + DW_WDT_CR);
 }
 
-static unsigned int designware_wdt_is_enabled(void)
+static unsigned int designware_wdt_is_enabled(struct designware_wdt_priv *priv)
 {
unsigned long val;
-   val = readl((CONFIG_DW_WDT_BASE + DW_WDT_CR));
-   return val & 0x1;
+   val = readl(priv->base + DW_WDT_CR);
+   return val & 1;
 }
 
-#if defined(CONFIG_HW_WATCHDOG)
+static void designware_wdt_reset(struct designware_wdt_priv *priv)
+{
+   if (designware_wdt_is_enabled(priv))
+   writel(DW_WDT_CRR_RESTART_VAL, priv->base + DW_WDT_CRR);
+}
+
+static void designware_wdt_init(struct designware_wdt_priv *priv, u64 timeout)
+{
+   /* reset to disable the watchdog */
+   designware_wdt_reset(priv);
+   /* set timer in miliseconds */
+   designware_wdt_settimeout(priv, timeout);
+   designware_wdt_enable(priv);
+   designware_wdt_reset(priv);
+}
+
+#ifdef CONFIG_HW_WATCHDOG
+static struct designware_wdt_priv wdt_priv = {
+   .base = CONFIG_DW_WDT_BASE,
+};
+
 void hw_watchdog_reset(void)
 {
-   if (designware_wdt_is_enabled())
-   /* restart the watchdog counter */
-   writel(DW_WDT_CRR_RESTART_VAL,
-  (CONFIG_DW_WDT_BASE + DW_WDT_CRR));
+   /* XXX: may contain a function call; must be done at runtime */
+   wdt_priv.clock_khz = CONFIG_DW_WDT_CLOCK_KHZ;
+   designware_wdt_reset(_priv);
 }
 
 void hw_watchdog_init(void)
 {
-   /* reset to disable the watchdog */
-   hw_watchdog_reset();
-   /* set timer in miliseconds */
-   designware_wdt_settimeout(CONFIG_WATCHDOG_TIMEOUT_MSECS);
-   /* enable the watchdog */
-   designware_wdt_enable();
-   /* reset the watchdog */
-   hw_watchdog_reset();
+   /* XXX: see above */
+   wdt_priv.clock_khz = CONFIG_DW_WDT_CLOCK_KHZ;
+   designware_wdt_init(_priv, CONFIG_WATCHDOG_TIMEOUT_MSECS);
 }
 #endif
-- 
2.25.0



[PATCH 2/4] arm: Move asm/utils.h to log2.h

2020-02-02 Thread Sean Anderson
This header is needed outside of the arm architecture by the designware wdt
driver.
---
 arch/arm/cpu/armv7/cache_v7.c  | 2 +-
 arch/arm/mach-davinci/spl.c| 2 +-
 arch/arm/mach-omap2/clocks-common.c| 2 +-
 arch/arm/mach-omap2/emif-common.c  | 2 +-
 arch/arm/mach-omap2/omap4/emif.c   | 2 +-
 arch/arm/mach-omap2/omap5/dra7xx_iodelay.c | 2 +-
 arch/arm/mach-omap2/omap5/emif.c   | 2 +-
 arch/arm/mach-omap2/omap5/hwinit.c | 2 +-
 arch/arm/mach-socfpga/spl_a10.c| 2 +-
 arch/arm/mach-socfpga/spl_agilex.c | 2 +-
 arch/arm/mach-socfpga/spl_gen5.c   | 2 +-
 arch/arm/mach-socfpga/spl_s10.c| 2 +-
 drivers/watchdog/designware_wdt.c  | 4 ++--
 arch/arm/include/asm/utils.h => include/log2.h | 4 ++--
 14 files changed, 16 insertions(+), 16 deletions(-)
 rename arch/arm/include/asm/utils.h => include/log2.h (93%)

diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
index 99eb7db342..049a27cc92 100644
--- a/arch/arm/cpu/armv7/cache_v7.c
+++ b/arch/arm/cpu/armv7/cache_v7.c
@@ -8,7 +8,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #define ARMV7_DCACHE_INVAL_RANGE   1
 #define ARMV7_DCACHE_CLEAN_INVAL_RANGE 2
diff --git a/arch/arm/mach-davinci/spl.c b/arch/arm/mach-davinci/spl.c
index be3daa9bc0..821324074c 100644
--- a/arch/arm/mach-davinci/spl.c
+++ b/arch/arm/mach-davinci/spl.c
@@ -7,7 +7,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-omap2/clocks-common.c 
b/arch/arm/mach-omap2/clocks-common.c
index 5932d694d3..7b91a39cdb 100644
--- a/arch/arm/mach-omap2/clocks-common.c
+++ b/arch/arm/mach-omap2/clocks-common.c
@@ -18,7 +18,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/arch/arm/mach-omap2/emif-common.c 
b/arch/arm/mach-omap2/emif-common.c
index 290f9dcdb0..758c2b3d11 100644
--- a/arch/arm/mach-omap2/emif-common.c
+++ b/arch/arm/mach-omap2/emif-common.c
@@ -14,7 +14,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/arch/arm/mach-omap2/omap4/emif.c b/arch/arm/mach-omap2/omap4/emif.c
index 35a51645be..d2b530535e 100644
--- a/arch/arm/mach-omap2/omap4/emif.c
+++ b/arch/arm/mach-omap2/omap4/emif.c
@@ -11,7 +11,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
 u32 *const T_num = (u32 *)OMAP_SRAM_SCRATCH_EMIF_T_NUM;
diff --git a/arch/arm/mach-omap2/omap5/dra7xx_iodelay.c 
b/arch/arm/mach-omap2/omap5/dra7xx_iodelay.c
index 9eda57c450..e541e729ef 100644
--- a/arch/arm/mach-omap2/omap5/dra7xx_iodelay.c
+++ b/arch/arm/mach-omap2/omap5/dra7xx_iodelay.c
@@ -7,7 +7,7 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-omap2/omap5/emif.c b/arch/arm/mach-omap2/omap5/emif.c
index f3661a0e74..a5c74261c0 100644
--- a/arch/arm/mach-omap2/omap5/emif.c
+++ b/arch/arm/mach-omap2/omap5/emif.c
@@ -11,7 +11,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
 #define print_timing_reg(reg) debug(#reg" - 0x%08x\n", (reg))
diff --git a/arch/arm/mach-omap2/omap5/hwinit.c 
b/arch/arm/mach-omap2/omap5/hwinit.c
index 56458ce495..ebd3b4903f 100644
--- a/arch/arm/mach-omap2/omap5/hwinit.c
+++ b/arch/arm/mach-omap2/omap5/hwinit.c
@@ -18,7 +18,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-socfpga/spl_a10.c
index 7c38c50981..a2b19e0f47 100644
--- a/arch/arm/mach-socfpga/spl_a10.c
+++ b/arch/arm/mach-socfpga/spl_a10.c
@@ -8,7 +8,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-socfpga/spl_agilex.c 
b/arch/arm/mach-socfpga/spl_agilex.c
index c745d64114..4e46d2bf5c 100644
--- a/arch/arm/mach-socfpga/spl_agilex.c
+++ b/arch/arm/mach-socfpga/spl_agilex.c
@@ -6,7 +6,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-socfpga/spl_gen5.c b/arch/arm/mach-socfpga/spl_gen5.c
index e19f55aa9b..48de2aceee 100644
--- a/arch/arm/mach-socfpga/spl_gen5.c
+++ b/arch/arm/mach-socfpga/spl_gen5.c
@@ -6,7 +6,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-socfpga/spl_s10.c b/arch/arm/mach-socfpga/spl_s10.c
index 8d96918cb4..44063b332a 100644
--- a/arch/arm/mach-socfpga/spl_s10.c
+++ b/arch/arm/mach-socfpga/spl_s10.c
@@ -6,7 +6,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/watchdog/designware_wdt.c 
b/drivers/watchdog/designware_wdt.c
index c668567c66..3b97db1256 100644
--- a/drivers/watchdog/designware_wdt.c
+++ b/drivers/watchdog/designware_wdt.c
@@ -4,9 +4,9 @@
  */
 
 

[PATCH 1/4] wdt: Add CONFIG_DESIGNWARE_WATCHDOG to Kconfig

2020-02-02 Thread Sean Anderson
Currently this is set from headers. No board has this set by default, so we
don't need to modify any configs.
---
 drivers/watchdog/Kconfig   | 7 +++
 include/configs/socfpga_common.h   | 1 -
 include/configs/socfpga_soc64_common.h | 1 -
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 8c16d69d33..b717eebe3c 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -176,6 +176,13 @@ config WDT_TANGIER
  Intel Tangier SoC. If you're using a board with Intel Tangier
  SoC, say Y here.
 
+config DESIGNWARE_WATCHDOG
+   bool "Synopsys Designware watchdog timer support"
+   select HW_WATCHDOG if !WDT
+   help
+ Enable support for the Synopsys Designware watchdog timer, which can
+ be found on Altera socfpgas, and on Kendryte CPUs.
+
 config SPL_WDT
bool "Enable driver model for watchdog timer drivers in SPL"
depends on SPL_DM
diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index 05bfef75c0..5329b19af2 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -105,7 +105,6 @@
  * L4 Watchdog
  */
 #ifdef CONFIG_HW_WATCHDOG
-#define CONFIG_DESIGNWARE_WATCHDOG
 #define CONFIG_DW_WDT_BASE SOCFPGA_L4WD0_ADDRESS
 #define CONFIG_DW_WDT_CLOCK_KHZ25000
 #endif
diff --git a/include/configs/socfpga_soc64_common.h 
b/include/configs/socfpga_soc64_common.h
index 4afadafd35..159e60ec6e 100644
--- a/include/configs/socfpga_soc64_common.h
+++ b/include/configs/socfpga_soc64_common.h
@@ -152,7 +152,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
  */
 #ifdef CONFIG_SPL_BUILD
 #define CONFIG_HW_WATCHDOG
-#define CONFIG_DESIGNWARE_WATCHDOG
 #define CONFIG_DW_WDT_BASE SOCFPGA_L4WD0_ADDRESS
 #ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
 #ifndef __ASSEMBLY__
-- 
2.25.0



Re: SDL 2.0 in gitlab

2020-02-02 Thread Tom Rini
On Sun, Feb 02, 2020 at 09:14:56AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 13 Jan 2020 at 14:27, Tom Rini  wrote:
> >
> > On Sun, Jan 12, 2020 at 09:01:18PM +1300, Simon Glass wrote:
> >
> > > Hi Tom,
> > >
> > > I have a series which changes sandbox over to use the newer SDL2. At
> > > present I cannot make it pass on gitlab since it seems to have SDL1.2
> > > (only).
> > >
> > > Is it possible to change that?
> >
> > Yes, change
> > https://gitlab.denx.de/u-boot/gitlab-ci-runner/blob/master/Dockerfile#L35
> > and also
> > https://gitlab.denx.de/u-boot/u-boot/blob/master/.travis.yml#L22
> > at the same time.  Testing will be a little hard as you'll need to
> > change your local .gitlab/.azure files to use your docker image to
> > confirm the changes.
> 
> OK thanks It's just a case of adding libsdl2-dev to the list. I put
> the travis change in the series already.
> 
> I created a commit. But how do I submit a change to the
> gitlib-ci-runner project? I don't seem to be able to fork it or push
> to it, but I see others have made changes.

Post to the regular ML, prefix it so it's clear that it's for the gitlab
file and I'll pick it up and sync things up.

-- 
Tom


signature.asc
Description: PGP signature


Re: SDL 2.0 in gitlab

2020-02-02 Thread Simon Glass
Hi Tom,

On Mon, 13 Jan 2020 at 14:27, Tom Rini  wrote:
>
> On Sun, Jan 12, 2020 at 09:01:18PM +1300, Simon Glass wrote:
>
> > Hi Tom,
> >
> > I have a series which changes sandbox over to use the newer SDL2. At
> > present I cannot make it pass on gitlab since it seems to have SDL1.2
> > (only).
> >
> > Is it possible to change that?
>
> Yes, change
> https://gitlab.denx.de/u-boot/gitlab-ci-runner/blob/master/Dockerfile#L35
> and also
> https://gitlab.denx.de/u-boot/u-boot/blob/master/.travis.yml#L22
> at the same time.  Testing will be a little hard as you'll need to
> change your local .gitlab/.azure files to use your docker image to
> confirm the changes.

OK thanks It's just a case of adding libsdl2-dev to the list. I put
the travis change in the series already.

I created a commit. But how do I submit a change to the
gitlib-ci-runner project? I don't seem to be able to fork it or push
to it, but I see others have made changes.

Regards,
Simon


Re: [PATCH] riscv: Remove unnecessary instruction

2020-02-02 Thread Bin Meng
On Tue, Jan 28, 2020 at 5:39 AM Sean Anderson  wrote:
>
> The add instruction on risc-v can have any three sources and targets, so there
> is no need for an intermediate mov.
>
> Signed-off-by: Sean Anderson 
> ---
>  arch/riscv/cpu/start.S | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH v2] cmd: Handle CONFIG_(SPL_|TPL_)ENV_SUPPORT for toggling nvedit object

2020-02-02 Thread Nathan Rossi
On Sun, 2 Feb 2020 at 23:52, Wolfgang Denk  wrote:
>
> Dear Nathan,
>
> In message <20200202130227.7755-1-nat...@nathanrossi.com> you wrote:
> > When CONFIG_SPL_ENV_SUPPORT is disabled, nvedit was still being included
> > as part of the build. Use the CONFIG_ENV_SUPPORT, CONFIG_SPL_ENV_SUPPORT
> > or CONFIG_TPL_ENV_SUPPORT values to enable/disable the inclusion of
> > nvedit.
>
> Why should the availability of these commands depend on any of these
> settings?  I think this is wrong - whether someone wants to have
> environment commands in SPL or TPM is an independent decision. You
> must not dictate it in such a way for all users.

This file is dependent on code from env/, specifically code that is
conditional on the various ENV_SUPPORT configs. As the underlying
compilation issue stems from nvedit providing what appears to be
common environment code (e.g. env_get), it made sense to have nvedit
conditional on the same config.

Regards,
Nathan


[PATCH 2/2] spl: get rid of SPL_LIBDISK_SUPPORT

2020-02-02 Thread Thomas Hebb
This option hasn't actually affected what's linked into the build since
commit 91ff6865629c ("blk: Rework guard around part_init call"), which
switched libdisk in SPL to depend on (CONFIG_SPL_FRAMEWORK &&
CONFIG_PARTITIONS). After removing one straggling reference that seems
to been authored before 91ff6865629c landed, there are absolutely no
references to this in the code. Let's remove it.

Signed-off-by: Thomas Hebb 

---

 arch/arm/Kconfig |  1 -
 arch/arm/mach-imx/mx6/Kconfig|  1 -
 arch/arm/mach-mvebu/Kconfig  |  2 --
 arch/arm/mach-omap2/Kconfig  |  3 ---
 arch/arm/mach-omap2/am33xx/Kconfig   |  2 --
 arch/arm/mach-stm32mp/Kconfig|  1 -
 arch/arm/mach-zynq/Kconfig   |  3 ---
 arch/arm/mach-zynqmp/Kconfig |  3 ---
 common/spl/Kconfig   | 19 ++-
 configs/am335x_baltos_defconfig  |  1 -
 configs/am335x_guardian_defconfig|  1 -
 configs/am335x_hs_evm_uart_defconfig |  1 -
 configs/am335x_igep003x_defconfig|  1 -
 configs/am335x_pdu001_defconfig  |  1 -
 configs/am335x_shc_defconfig |  1 -
 configs/am335x_shc_ict_defconfig |  1 -
 configs/am335x_shc_netboot_defconfig |  1 -
 configs/am335x_shc_sdboot_defconfig  |  1 -
 configs/am335x_sl50_defconfig|  1 -
 configs/am65x_evm_a53_defconfig  |  1 -
 configs/am65x_evm_r5_defconfig   |  1 -
 configs/am65x_hs_evm_a53_defconfig   |  1 -
 configs/am65x_hs_evm_r5_defconfig|  1 -
 configs/birdland_bav335a_defconfig   |  1 -
 configs/birdland_bav335b_defconfig   |  1 -
 configs/cgtqmx6eval_defconfig|  1 -
 configs/chiliboard_defconfig |  1 -
 configs/cm_t335_defconfig|  1 -
 configs/cm_t43_defconfig |  1 -
 configs/draco_defconfig  |  1 -
 configs/etamin_defconfig |  1 -
 configs/imx6qdl_icore_mipi_defconfig |  1 -
 configs/imx6qdl_icore_mmc_defconfig  |  1 -
 configs/imx6qdl_icore_rqs_defconfig  |  1 -
 configs/imx6ul_geam_mmc_defconfig|  1 -
 configs/imx6ul_isiot_emmc_defconfig  |  1 -
 configs/j721e_evm_a72_defconfig  |  1 -
 configs/j721e_evm_r5_defconfig   |  1 -
 configs/j721e_hs_evm_a72_defconfig   |  1 -
 configs/j721e_hs_evm_r5_defconfig|  1 -
 configs/mx6cuboxi_defconfig  |  1 -
 configs/mx6sabreauto_defconfig   |  1 -
 configs/mx6sabresd_defconfig |  1 -
 configs/mx6slevk_spl_defconfig   |  1 -
 configs/mx6sxsabresd_spl_defconfig   |  1 -
 configs/mx6ul_14x14_evk_defconfig|  1 -
 configs/mx6ul_9x9_evk_defconfig  |  1 -
 configs/novena_defconfig |  1 -
 configs/opos6uldev_defconfig |  1 -
 configs/pcm051_rev1_defconfig|  1 -
 configs/pcm051_rev3_defconfig|  1 -
 configs/pcm058_defconfig |  1 -
 configs/pengwyn_defconfig|  1 -
 configs/pepper_defconfig |  1 -
 configs/pfla02_defconfig |  1 -
 configs/phycore-am335x-r2-wega_defconfig |  1 -
 configs/pico-dwarf-imx6ul_defconfig  |  1 -
 configs/pico-hobbit-imx6ul_defconfig |  1 -
 configs/pico-imx6_defconfig  |  1 -
 configs/pico-imx6ul_defconfig|  1 -
 configs/pico-pi-imx6ul_defconfig |  1 -
 configs/picosam9g45_defconfig|  1 -
 configs/platinum_picon_defconfig |  1 -
 configs/platinum_titanium_defconfig  |  1 -
 configs/pxm2_defconfig   |  1 -
 configs/rastaban_defconfig   |  1 -
 configs/riotboard_spl_defconfig  |  1 -
 configs/rut_defconfig|  1 -
 configs/sama5d27_som1_ek_mmc1_defconfig  |  1 -
 configs/sama5d27_som1_ek_mmc_defconfig   |  1 -
 configs/sama5d27_som1_ek_qspiflash_defconfig |  1 -
 configs/sama5d27_wlsom1_ek_mmc_defconfig |  1 -
 configs/sama5d2_icp_mmc_defconfig|  1 -
 configs/sama5d2_xplained_emmc_defconfig  |  1 -
 configs/sama5d2_xplained_mmc_defconfig   |  1 -
 configs/sama5d2_xplained_qspiflash_defconfig |  1 -
 configs/sama5d3_xplained_mmc_defconfig   |  1 -
 configs/sama5d3xek_mmc_defconfig |  1 -
 configs/sama5d4_xplained_mmc_defconfig   |  1 -
 configs/sama5d4ek_mmc_defconfig  |  1 -
 configs/sksimx6_defconfig|  1 -
 configs/thuban_defconfig |  1 -
 configs/ti814x_evm_defconfig |  1 -
 configs/ti816x_evm_defconfig |  1 -
 configs/udoo_defconfig   |  1 -
 configs/udoo_neo_defconfig

Re: Fix for build error /uboot/driver/video/simplefb.c

2020-02-02 Thread ARJUN C R
Adding proper diff:

--- u-boot-2020.04-rc1/drivers/video/simplefb.c 2020-01-29
03:29:30.0 +0530
+++ u-boot-2020.04-rc1_new/drivers/video/simplefb.c 2020-02-02
16:31:57.416168719 +0530
@@ -26,7 +26,7 @@ static int simple_video_probe(struct ude
  return -EINVAL;
  }

- debug("%s: base=%llx, size=%llu\n", __func__, base, size);
+ debug("%s: base=%lx, size=%lu\n", __func__, base, size);

  /*
  * TODO is there some way to reserve the framebuffer

On Sun, Feb 2, 2020 at 4:35 PM ARJUN C R  wrote:

> Hi,
>
> diff:
>
> --- u-boot-2020.04-rc1_new/drivers/video/simplefb.c 2020-02-02
> 16:31:57.416168719 +0530
> +++ u-boot-2020.04-rc1/drivers/video/simplefb.c 2020-01-29
> 03:29:30.0 +0530
> @@ -26,7 +26,7 @@ static int simple_video_probe(struct ude
>   return -EINVAL;
>   }
>
> - debug("%s: base=%lx, size=%lu\n", __func__, base, size);
> + debug("%s: base=%llx, size=%llu\n", __func__, base, size);
>
>   /*
>   * TODO is there some way to reserve the framebuffer
>
> variables base and size is unsinged long int, so the format specifier
> should be %lx and %lu.
>
> Regards
> ARJUN C R
>


Fix for build error /uboot/driver/video/simplefb.c

2020-02-02 Thread ARJUN C R
Hi,

diff:

--- u-boot-2020.04-rc1_new/drivers/video/simplefb.c 2020-02-02
16:31:57.416168719 +0530
+++ u-boot-2020.04-rc1/drivers/video/simplefb.c 2020-01-29
03:29:30.0 +0530
@@ -26,7 +26,7 @@ static int simple_video_probe(struct ude
  return -EINVAL;
  }

- debug("%s: base=%lx, size=%lu\n", __func__, base, size);
+ debug("%s: base=%llx, size=%llu\n", __func__, base, size);

  /*
  * TODO is there some way to reserve the framebuffer

variables base and size is unsinged long int, so the format specifier
should be %lx and %lu.

Regards
ARJUN C R


Re: [PATCH v2] cmd: Handle CONFIG_(SPL_|TPL_)ENV_SUPPORT for toggling nvedit object

2020-02-02 Thread Wolfgang Denk
Dear Nathan,

In message <20200202130227.7755-1-nat...@nathanrossi.com> you wrote:
> When CONFIG_SPL_ENV_SUPPORT is disabled, nvedit was still being included
> as part of the build. Use the CONFIG_ENV_SUPPORT, CONFIG_SPL_ENV_SUPPORT
> or CONFIG_TPL_ENV_SUPPORT values to enable/disable the inclusion of
> nvedit.

Why should the availability of these commands depend on any of these
settings?  I think this is wrong - whether someone wants to have
environment commands in SPL or TPM is an independent decision. You
must not dictate it in such a way for all users.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Experience is that marvelous thing that enable  you  to  recognize  a
mistake when you make it again.   - Franklin P. Jones


[PATCH v2] cmd: Handle CONFIG_(SPL_|TPL_)ENV_SUPPORT for toggling nvedit object

2020-02-02 Thread Nathan Rossi
When CONFIG_SPL_ENV_SUPPORT is disabled, nvedit was still being included
as part of the build. Use the CONFIG_ENV_SUPPORT, CONFIG_SPL_ENV_SUPPORT
or CONFIG_TPL_ENV_SUPPORT values to enable/disable the inclusion of
nvedit.

Signed-off-by: Nathan Rossi 
---
Changes in v2:
* Changed $(SPL_) to $(SPL_TPL_) to cover CONFIG_TPL_ENV_SUPPORT
---
 cmd/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/Makefile b/cmd/Makefile
index 4f29b72c69..21b867d3a9 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -186,7 +186,7 @@ endif # !CONFIG_SPL_BUILD
 obj-$(CONFIG_$(SPL_)CMD_TLV_EEPROM) += tlv_eeprom.o
 
 # core command
-obj-y += nvedit.o
+obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += nvedit.o
 
 obj-$(CONFIG_TI_COMMON_CMD_OPTIONS) += ti/
 
---
2.24.1