Re: [EXT] Re: [PATCH] usb: ehci-hcd: Add IAA handshake for removing async QH

2021-03-09 Thread Marek Vasut

On 3/9/21 4:18 AM, Ye Li wrote:

Hi Marek,


Hi,

[...]



+ 10 * 1000); /* 10ms timeout */
+ if (ret < 0)
+ printf("EHCI fail timeout STS_IAA set\n");

Shouldn't there be some abort ^ if ret < 0 ?
Also, add the return value into the printf, it is useful for
debugging.

I don't think need to abort anything when ret < 0. The ret value is
very simple in handshake, when ret < 0, it must be -1.
Actually the codes refer the ehci_enable_async for the usage of
handshake.


If the handshake timed out, that indicates a problem and that problem 
shouldn't be ignored, but rather propagated, no ? Maybe the entire ehci 
transfer should be aborted ?


[...]



+ ehci_writel(&ctrl->hcor->or_usbsts, STS_IAA);
+
+ return ret;
+}

Is this a bugfix for this release or is this for next release ?
We're in rc3 already, so I would suggest to be careful.

It is ok to add the fix for next release. From our tests, the issue is
not very easy to reproduce by just using usb read/write.  In
SCT, generally we need to run about 1 hour to see the issue.


Can you add details on how to reproduce the issue into the commit 
message ? That would be highly helpful.


Re: [EXT] Re: [PATCH] usb: ehci-hcd: Add IAA handshake for removing async QH

2021-03-09 Thread Ye Li
Hi Marek,

On Tue, 2021-03-09 at 09:08 +0100, Marek Vasut wrote:
> Caution: EXT Email
> 
> On 3/9/21 4:18 AM, Ye Li wrote:
> > 
> > Hi Marek,
> Hi,
> 
> [...]
> 
> > 
> > > 
> > > > 
> > > > 
> > > > + 10 * 1000); /* 10ms timeout */
> > > > + if (ret < 0)
> > > > + printf("EHCI fail timeout STS_IAA set\n");
> > > Shouldn't there be some abort ^ if ret < 0 ?
> > > Also, add the return value into the printf, it is useful for
> > > debugging.
> > I don't think need to abort anything when ret < 0. The ret value is
> > very simple in handshake, when ret < 0, it must be -1.
> > Actually the codes refer the ehci_enable_async for the usage of
> > handshake.
> If the handshake timed out, that indicates a problem and that problem
> shouldn't be ignored, but rather propagated, no ? Maybe the entire
> ehci
> transfer should be aborted ?
> 
I supposed the problem means QH does not advance, so next submit of
async transfer will have QTD timeout. But it is ok to abort transfer as
the error handling.


> [...]
> 
> > 
> > > 
> > > > 
> > > > 
> > > > + ehci_writel(&ctrl->hcor->or_usbsts, STS_IAA);
> > > > +
> > > > + return ret;
> > > > +}
> > > Is this a bugfix for this release or is this for next release ?
> > > We're in rc3 already, so I would suggest to be careful.
> > It is ok to add the fix for next release. From our tests, the issue
> > is
> > not very easy to reproduce by just using usb read/write.  In
> > SCT, generally we need to run about 1 hour to see the issue.
> Can you add details on how to reproduce the issue into the commit
> message ? That would be highly helpful.
ok. I will add more.

Best regards,
Ye Li




Re: [PATCH] disk: gpt: verify alternate LBA points to last usable LBA

2021-03-09 Thread Stefan Herbrechtsmeier

Hi Heinrich,

Am 08.03.2021 um 18:38 schrieb Heinrich Schuchardt:

On 08.03.21 17:07, Stefan Herbrechtsmeier wrote:

From: Stefan Herbrechtsmeier 

The gpt command require the GPT backup header at the standard location
at the end of the device.Check the alternate LBA value before reading
the GPT backup header from the last usable LBA of the device.


If there is a bug in the gpt command, please, fix it instead of
introducing constraints that don't exist in the UEFI specification.


The constraints already exists because the command only supports backup 
header at the end. At the moment the command blindly check the backup 
header at the end even if the primary header points to an other position.



The UEFI specification has:

"The backup GPT Partition Entry Array must be located after the Last
Usable LBA and end before the backup GPT Header."


A lot of tools complain a backup head outside of the last LBA and move 
the header with the next write.



And of course the backup GPT header has to reside within the disk size.

There may be good reasons not to place the GPT header on the last LBA.
E.g. if the last sector is defective.


At the moment the command only supports a backup header at the end but 
doesn't check if the primary header points to the last LBA.



Signed-off-by: Stefan Herbrechtsmeier 

---

  disk/part_efi.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/disk/part_efi.c b/disk/part_efi.c
index e5636ea7e6..0fb7ff0b6b 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -692,6 +692,15 @@ int gpt_verify_headers(struct blk_desc *dev_desc, 
gpt_header *gpt_head,
/* Free pte before allocating again */
free(*gpt_pte);

+   /*
+* Check that the alternate_lba entry points to the last LBA
+*/
+   if (le64_to_cpu(gpt_head->alternate_lba) != (dev_desc->lba - 1)) {


This is wrong. You may check:

le64_to_cpu(gpt_head->alternate_lba) < dev_desc->lba

and

AlternateLBA > LastUsableLBA +
ceil(NumberOfPartitionEntries * SizeOfPartitionEntry / SizeOfLBA)


Why you need this checks? Doesn't this belongs to the check of the gpt 
itself?



+   printf("%s: *** ERROR: Misplaced Backup GPT ***\n",
+  __func__);
+   return -1;
+   }
+
if (is_gpt_valid(dev_desc, (dev_desc->lba - 1),


This seems to be one of the buggy lines. You must use the alternate_lba
field here.

find_valid_gpt() should be corrected, too.


Okay, I will rework the verify command to support backup headers outside 
of the last LBA.


But I need a command to check if the backup header is at the last LBA. 
Do you have any suggestion?





 gpt_head, gpt_pte) != 1) {
printf("%s: *** ERROR: Invalid Backup GPT ***\n",



Regards
  Stefan


bug report : /drivers/pci/pcie_layerscape_rc.c "pcie->ctrl used without being initialised"

2021-03-09 Thread florian.man...@siemens.com
Hi,

I would like to report a bug I got, while updating my u-boot version.

Configuration :
CPU : NXP LS1043a
u-boot version : v2020.10  (I didn't see a fix for this issue in the latest 
u-boot version)


What was happening :
Function "unsigned int ctrl_readl(struct ls_pcie *pcie, unsigned int offset)" 
in "/drivers/pci/pcie_layerscape.c" was leading to a panic due to a read at an 
incorrect address.

What was wrong :
The address to read at, is extracted from the DTB, in my case, the nodes 
'pcie', name 'ctrl' from the 'reg-name' list. This is done in the function 
"static int ls_pcie_probe(struct udevice *dev)" in 
"/drivers/pci/pcie_layerscape_rc.c"
In some case (mine at least), the DTB doesn't contain the name 'ctrl' in the 
list 'reg-names' for the pcie nodes, causing 'fdt_get_named_resource()' to 
return (-1).
This (-1) avoid the variable 'pcie->ctrl'  to be initialized. This variable is 
not directly declared but a pointer 'pcie' to a structure ls_pcie is declared 
instead.
Because the value of 'pcie->ctrl'  is not initialized, there is a non-zero 
random value inside that passes the test "if (!pcie->ctrl)" and leads to the 
panic while given to the ctrl_read() as address to read.

How I fixed it :
Initialize the value of "pcie->ctrl" to NULL at the beginning of the function 
ls_pcie_probe()
This make the check "if (!pcie->ctrl)" to fail and the variable "pcie->ctrl" is 
then initialized.

How to reproduce it :
Not sure...
We load a FIT image containing a kernel, ramdisk and a DTB from an NOR memory 
through a QSPI interface. The checksum are OK.
Then, we boot from it using the command 'bootm'. Once the FIT element are 
loaded, some checks (link) are done on the PCIe and the issue happens here.
But,
If I start another firmware, using the same DTB, from an eMMC memory. I have no 
issue at all, "pcie->ctrl" is initialized to NULL directly without need of a 
fix.


Let me know if you want more information.


Mit freundlichen Grüßen
Florian Manoël

Siemens AG
Digital Industries
Process Automation
DI PA DCP R&D 2
Östliche Rheinbrückenstr. 50
76187 Karlsruhe, Deutschland
Tel.: +49 721 667-20051
mailto:florian.man...@siemens.com

www.siemens.com

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann Snabe; 
Vorstand: Roland Busch, Vorsitzender; Klaus Helmrich, Cedrik Neike, Matthias 
Rebellius, Ralf P. Thomas, Judith Wiese; Sitz der Gesellschaft: Berlin und 
München, Deutschland; Registergericht: Berlin-Charlottenburg, HRB 12300, 
München, HRB 6684; WEEE-Reg.-Nr. DE 23691322


Re: [EXT] Re: [PATCH] usb: ehci-hcd: Add IAA handshake for removing async QH

2021-03-09 Thread Marek Vasut

On 3/9/21 10:32 AM, Ye Li wrote:

Hi Marek,


Hi,

[...]


+ 10 * 1000); /* 10ms timeout */
+ if (ret < 0)
+ printf("EHCI fail timeout STS_IAA set\n");

Shouldn't there be some abort ^ if ret < 0 ?
Also, add the return value into the printf, it is useful for
debugging.

I don't think need to abort anything when ret < 0. The ret value is
very simple in handshake, when ret < 0, it must be -1.
Actually the codes refer the ehci_enable_async for the usage of
handshake.

If the handshake timed out, that indicates a problem and that problem
shouldn't be ignored, but rather propagated, no ? Maybe the entire
ehci
transfer should be aborted ?


I supposed the problem means QH does not advance, so next submit of
async transfer will have QTD timeout. But it is ok to abort transfer as
the error handling.


If this is an error which would always cause subsequent error, abort 
here already.



+ ehci_writel(&ctrl->hcor->or_usbsts, STS_IAA);
+
+ return ret;
+}

Is this a bugfix for this release or is this for next release ?
We're in rc3 already, so I would suggest to be careful.

It is ok to add the fix for next release. From our tests, the issue
is
not very easy to reproduce by just using usb read/write.  In
SCT, generally we need to run about 1 hour to see the issue.

Can you add details on how to reproduce the issue into the commit
message ? That would be highly helpful.

ok. I will add more.


Thank you


Re: [PATCH u-boot 16/39] build: use thin archives instead of incremental linking

2021-03-09 Thread Marek Behun
On Tue, 9 Mar 2021 11:42:08 +0800
Bin Meng  wrote:

> Hi Marek,
> 
> On Tue, Mar 9, 2021 at 9:24 AM Bin Meng  wrote:
> >
> > Hi Marek,
> >
> > On Mon, Mar 8, 2021 at 11:22 PM Marek Behún  wrote:  
> > >
> > > On Mon, 8 Mar 2021 22:30:17 +0800
> > > Bin Meng  wrote:
> > >  
> > > > Hi Marek,
> > > >
> > > > On Mon, Mar 8, 2021 at 9:24 PM Marek Behún  wrote:  
> > > > >
> > > > > On Mon, 8 Mar 2021 19:32:10 +0800
> > > > > Bin Meng  wrote:
> > > > >  
> > > > > > On Mon, Mar 8, 2021 at 7:18 PM Marek Behun 
> > > > > > wrote:  
> > > > > > >
> > > > > > > On Mon, 8 Mar 2021 18:44:58 +0800
> > > > > > > Bin Meng  wrote:
> > > > > > >  
> > > > > > > > Could you investigate why?  
> > > > > > >
> > > > > > > I could, but I don't understand why exactly I should
> > > > > > > - Linux is also using --whole-archive
> > > > > > > - it is working
> > > > > > > - I have other things I would like to work on
> > > > > > >
> > > > > > > Maybe you could look into this? :)  
> > > > > >
> > > > > > Yes, I can look into this. I wonder if you already knew this which
> > > > > > could save some time as this is a normal review process, asking
> > > > > > for clarifications if something isn't clear.  
> > > > >
> > > > > Bin, CI is failing without the --whole-archive option.
> > > > >
> > > > > What is interesting is that the binaries build successfully, but
> > > > > testing them fails :)
> > > > >
> > > > > You can try this (with and without the --whole-archive options)
> > > > > (note that this is without LTO)
> > > > >   make qemu_arm_defconfig
> > > > >   CROSS_COMPILE=arm-compiler- make -j8
> > > > >   qemu-system-arm -M virt -nographic \
> > > > > -netdev user,id=net0,tftp=$(pwd) \
> > > > > -device e1000,netdev=net0 -device virtio-rng-pci \
> > > > > -bios u-boot.bin -serial mon:stdio
> > > > >
> > > > > With --whole-archive option this boots successfully into U-Boot,
> > > > > without --whole-archive it just hangs.  
> > > >
> > > > Thanks for reporting. My initnial build testing on qemu_arm_defconfig
> > > > with this series succeeded but there are some warnings:
> > > >
> > > > /opt/armv7-linux/bin/arm-linux-ld.bfd:
> > > > lib/efi_selftest/efi_selftest_miniapp_exception.o: plugin needed to
> > > > handle lto object
> > > > /opt/armv7-linux/bin/arm-linux-ld.bfd:
> > > > examples/standalone/hello_world.o: plugin needed to handle lto object
> > > > /opt/armv7-linux/bin/arm-linux-ld.bfd: examples/standalone/libstubs.o:
> > > > plugin needed to handle lto object
> > > > /opt/armv7-linux/bin/arm-linux-ld.bfd: warning: cannot find entry
> > > > symbol hello_world; defaulting to 0c10
> > > >
> > > > It looks we should update the make rules to remove "-flto" for these
> > > > targets.
> > > >
> > > > Applying the following diff to remove --whole-archive, I got a build
> > > > error:
> > > >
> > > > diff --git a/Makefile b/Makefile
> > > > index 0f538270d7..127630e060 100644
> > > > --- a/Makefile
> > > > +++ b/Makefile
> > > > @@ -1780,7 +1780,7 @@ quiet_cmd_u-boot__ ?= LTO $@
> > > > $(LTO_FINAL_CFLAGS) $(c_flags)
> > > >  \
> > > > $(KBUILD_LDFLAGS:%=-Wl,%) $(LDFLAGS_u-boot:%=-Wl,%) -o
> > > > $@   \
> > > > -T u-boot.lds $(u-boot-init)
> > > >  \
> > > > -   -Wl,--start-group -Wl,--whole-archive
> > > >  \
> > > > +   -Wl,--start-group
> > > >  \
> > > > $(u-boot-main)
> > > >  \
> > > > $(PLATFORM_LIBS)
> > > >  \
> > > > -Wl,--no-whole-archive -Wl,--end-group
> > > >  \
> > > > @@ -1790,9 +1790,9 @@ else
> > > >  quiet_cmd_u-boot__ ?= LD  $@
> > > >cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@
> > > >  \
> > > > -T u-boot.lds $(u-boot-init)
> > > >  \
> > > > -   --start-group --whole-archive
> > > >  \
> > > > +   --start-group
> > > >  \
> > > > $(u-boot-main)
> > > >  \
> > > > -   --no-whole-archive --end-group
> > > >  \
> > > > +   --end-group
> > > >  \
> > > > $(PLATFORM_LIBS) -Map u-boot.map;
> > > >  \
> > > > $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK)
> > > > $@, true) endif
> > > >
> > > >   LTO u-boot
> > > > /opt/armv7-linux/bin/../lib/gcc/arm-buildroot-linux-gnueabihf/9.3.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld:
> > > > arch/arm/lib/lib.a(lib1funcs.o): in function `Ldiv0':
> > > > arch/arm/lib/lib1funcs.S:360: undefined reference to `__div0'
> > > >
> > > > I am using a pre-built armv7 toolchain from
> > > > https://toolchains.bootlin.com/  
> > >
> > > The
> > >   plugin needed to handle lto object
> > > need another change in Makefiles, I will look into this.
> > >
> > > As for the __div0 availability, that happens when compiling with LTO
> > > and no

Re: [PATCH 1/4] watchdog: Set/unset GD_FLG_WDT_READY flag in wdt_start()/wdt_stop()

2021-03-09 Thread Stefan Roese

On 05.03.21 22:36, Pali Rohár wrote:

Watchdog is ready after successful call of ops->start() callback in
wdt_start() function. And is stopped after successful call of ops->stop()
callback in wdt_stop function.

So move setting of GD_FLG_WDT_READY flag from initr_watchdog() function to
wdt_start() and ensure that GD_FLG_WDT_READY flag is unset in wdt_stop()
function.

This change ensures that GD_FLG_WDT_READY flag is set only when watchdog is
running. And ensures that flag is also also when watchdog was started not
only by initr_watchdog() call (e.g. by U-Boot 'wdt' command).

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  drivers/watchdog/wdt-uclass.c | 15 ---
  1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
index 28f7918c4673..3f707f61f74f 100644
--- a/drivers/watchdog/wdt-uclass.c
+++ b/drivers/watchdog/wdt-uclass.c
@@ -51,7 +51,6 @@ int initr_watchdog(void)
}
  
  	wdt_start(gd->watchdog_dev, timeout * 1000, 0);

-   gd->flags |= GD_FLG_WDT_READY;
printf("WDT:   Started with%s servicing (%ds timeout)\n",
   IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out", timeout);
  
@@ -61,21 +60,31 @@ int initr_watchdog(void)

  int wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags)
  {
const struct wdt_ops *ops = device_get_ops(dev);
+   int ret;
  
  	if (!ops->start)

return -ENOSYS;
  
-	return ops->start(dev, timeout_ms, flags);

+   ret = ops->start(dev, timeout_ms, flags);
+   if (ret == 0)
+   gd->flags |= GD_FLG_WDT_READY;
+
+   return ret;
  }
  
  int wdt_stop(struct udevice *dev)

  {
const struct wdt_ops *ops = device_get_ops(dev);
+   int ret;
  
  	if (!ops->stop)

return -ENOSYS;
  
-	return ops->stop(dev);

+   ret = ops->stop(dev);
+   if (ret == 0)
+   gd->flags &= ~GD_FLG_WDT_READY;
+
+   return ret;
  }
  
  int wdt_reset(struct udevice *dev)





Viele Grüße,
Stefan

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


Re: [PATCH 2/4] watchdog: Show error message when initr_watchdog() cannot start watchdog

2021-03-09 Thread Stefan Roese

On 05.03.21 22:36, Pali Rohár wrote:

Function wdt_start() may fail. So in initr_watchdog() function check return
value of wdt_start() call and print error message when watchdog starting
failed.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  drivers/watchdog/wdt-uclass.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
index 3f707f61f74f..7500b3ed90e3 100644
--- a/drivers/watchdog/wdt-uclass.c
+++ b/drivers/watchdog/wdt-uclass.c
@@ -27,6 +27,7 @@ static ulong reset_period = 1000;
  int initr_watchdog(void)
  {
u32 timeout = WATCHDOG_TIMEOUT_SECS;
+   int ret;
  
  	/*

 * Init watchdog: This will call the probe function of the
@@ -50,7 +51,12 @@ int initr_watchdog(void)
4 * reset_period) / 4;
}
  
-	wdt_start(gd->watchdog_dev, timeout * 1000, 0);

+   ret = wdt_start(gd->watchdog_dev, timeout * 1000, 0);
+   if (ret != 0) {
+   printf("WDT:   Failed to start\n");
+   return 0;
+   }
+
printf("WDT:   Started with%s servicing (%ds timeout)\n",
   IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out", timeout);
  




Viele Grüße,
Stefan

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


Re: [PATCH 3/4] watchdog: Allow to use CONFIG_WDT without starting watchdog

2021-03-09 Thread Stefan Roese

On 05.03.21 22:36, Pali Rohár wrote:

In some cases it is useful to compile support for U-Boot command 'wdt'
without starting HW watchdog in early U-Boot phase. For example when user


Nitpicking:
  when "the" user


want to start watchdog only on demand by some boot script.

This change adds a new compile option WATCHDOG_AUTOSTART to control whether
U-Boot should automatically start watchdog during init phase or not.


  start "the" watchdog



This option is enabled by default as it was was default behavior prior


  as it was the default


introducing this new change. When compiling U-Boot users can decide to turn
this option off.

Signed-off-by: Pali Rohár 
---
  drivers/watchdog/Kconfig  | 13 +
  drivers/watchdog/wdt-uclass.c |  7 +++
  2 files changed, 20 insertions(+)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 602ccbe41c00..aa76a8f2d239 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -9,6 +9,19 @@ config WATCHDOG
  this option if you want to service enabled watchdog by U-Boot. Disable
  this option if you want U-Boot to start watchdog but never service it.
  
+config WATCHDOG_AUTOSTART

+   bool "Automatically start watchdog timer"
+   depends on WDT
+   default y
+   help
+ Automatically start watchdog timer and start servicing it during
+ init phase. Enabled by default. Disable this option if you want
+ to compile U-Boot with CONFIG_WDT support but do not want to
+ activate watchdog, like when CONFIG_WDT option is disabled. You
+ would be able to start watchdog manually by 'wdt' command. Useful
+ when you want to have support for 'wdt' command but do not want
+ to have watchdog enabled by default.
+
  config WATCHDOG_TIMEOUT_MSECS
int "Watchdog timeout in msec"
default 128000 if ARCH_MX25 || ARCH_MX31 || ARCH_MX5 || ARCH_MX6
diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
index 7500b3ed90e3..00a408bf5cc5 100644
--- a/drivers/watchdog/wdt-uclass.c
+++ b/drivers/watchdog/wdt-uclass.c
@@ -27,7 +27,9 @@ static ulong reset_period = 1000;
  int initr_watchdog(void)
  {
u32 timeout = WATCHDOG_TIMEOUT_SECS;
+#ifdef CONFIG_WATCHDOG_AUTOSTART
int ret;
+#endif


Please don't add more #ifdef's if possible, see below...

  
  	/*

 * Init watchdog: This will call the probe function of the
@@ -51,6 +53,10 @@ int initr_watchdog(void)
4 * reset_period) / 4;
}
  
+#ifndef CONFIG_WATCHDOG_AUTOSTART

+   printf("WDT:   Not starting\n");
+   return 0;
+#else
ret = wdt_start(gd->watchdog_dev, timeout * 1000, 0);
if (ret != 0) {
printf("WDT:   Failed to start\n");
@@ -61,6 +67,7 @@ int initr_watchdog(void)
   IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out", timeout);
  
  	return 0;

+#endif


Please use this instead here:

if (CONFIG_IS_ENABLED(WATCHDOG_AUTOSTART)) {
...

Thanks,
Stefan


  }
  
  int wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags)





Viele Grüße,
Stefan

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


Re: [PATCH 4/4] arm: mvebu: Espressobin: Enable watchdog support but do not start it

2021-03-09 Thread Stefan Roese

On 05.03.21 22:36, Pali Rohár wrote:

Espressobin had disabled watchdog support (CONFIG_WDT) because older stable
Linux kernel versions (which are used by current stable OpenWRT and Debian
versions) do not have support for Armada 3700 watchdog driver. Therefore
they are not able to periodically kick watchdog so Espressobin enter into
boot loop.

This change enable CONFIG_WDT, CONFIG_WDT_ARMADA_37XX and CONFIG_CMD_WDT
options which add support for U-Boot 'wdt' command. And unset new
CONFIG_WATCHDOG_AUTOSTART option which cause that watchdog is not
automatically started by U-Boot during init phase, like when CONFIG_WDT
option is not set at all.

So with this change, U-Boot on Espressobin would have working 'wdt' command
which can be used from boot scripts (e.g. for enabling watchdog prior new
Linux booting kernel). But default behavior of watchdog status stays
unchanged, U-Boot does not start watchdog on Espressobin during its init
phase.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  configs/mvebu_espressobin-88f3720_defconfig | 4 
  1 file changed, 4 insertions(+)

diff --git a/configs/mvebu_espressobin-88f3720_defconfig 
b/configs/mvebu_espressobin-88f3720_defconfig
index c791f98dfea5..20aa21b06b3d 100644
--- a/configs/mvebu_espressobin-88f3720_defconfig
+++ b/configs/mvebu_espressobin-88f3720_defconfig
@@ -32,6 +32,7 @@ CONFIG_CMD_MMC=y
  CONFIG_CMD_PCI=y
  CONFIG_CMD_SPI=y
  CONFIG_CMD_USB=y
+CONFIG_CMD_WDT=y
  CONFIG_CMD_TFTPPUT=y
  CONFIG_CMD_CACHE=y
  CONFIG_CMD_TIME=y
@@ -88,5 +89,8 @@ CONFIG_USB_ETHER_ASIX=y
  CONFIG_USB_ETHER_MCS7830=y
  CONFIG_USB_ETHER_RTL8152=y
  CONFIG_USB_ETHER_SMSC95XX=y
+# CONFIG_WATCHDOG_AUTOSTART is not set
+CONFIG_WDT=y
+CONFIG_WDT_ARMADA_37XX=y
  CONFIG_SHA1=y
  CONFIG_SHA256=y




Viele Grüße,
Stefan

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


Re: [PATCH 1/2] board: gateworks: venice: fix gsc_get_dev

2021-03-09 Thread Fabio Estevam
Hi Tim,

On Mon, Mar 8, 2021 at 6:52 PM Tim Harvey  wrote:
>
> use dm_i2c_probe instead of i2c_get_chip which appears to be more
> reliable.
>
> Signed-off-by: Tim Harvey 

Reviewed-by: Fabio Estevam 


Re: [PATCH 2/2] board: gateworks: venice: increase CONFIG_SYS_SPL_MALLOC_SIZE

2021-03-09 Thread Fabio Estevam
On Mon, Mar 8, 2021 at 6:52 PM Tim Harvey  wrote:
>
> commit 03f1f78a9b44 ("spl: fit: Prefer a malloc()'d buffer for loading 
> images")'
> changed the way buffer allocation worked for SPL to a more flexible
> method.
>
> For venice this caused breakage that is resolved by increasing the size
> of CONFIG_SYS_SPL_MALLOC_SIZE as the current FIT slighly exceeds 512KiB.
>
> Additionally remove the unnecessary comment on CONFIG_SPL_BSS_MAX_SIZE
> and CONFIG_SYS_SPL_MALLOC_SIZE as the size is obvious from the define.
>
> Signed-off-by: Tim Harvey 

Reviewed-by: Fabio Estevam 


[PATCH 00/16] TI/Cadence: Add Sierra/Torrent SERDES driver

2021-03-09 Thread Kishon Vijay Abraham I
Patch series adds Sierra and Torrent SERDES driver for the SERDES
used in TI's K3 platforms. This SERDES is used by USB3, PCIe and
Ethernet. This series is mostly an adaptation of drivers added in
upstream Linux kernel.

Alan Douglas (1):
  phy: cadence: Add driver for Sierra PHY

Aswath Govindraju (7):
  dt-bindings: phy: Add definitions for additional phy types
  phy: cadence: Add driver for Torrent SERDES
  board: ti: j721e: Add support for probing and configuring Torrent
serdes on J7200
  arm: dts: k3-j7200-main: Add DT node for torrent serdes
  arm: dts: k3-j7200-common-proc-board: Enable SERDES DT
  arm: dts: k3-j7200-common-proc-board-u-boot: Add u-boot tags for
torrent serdes
  configs: j7200_evm_a72_defconfig: Add config for torrent serdes and
common clock framework

Jean-Jacques Hiblot (3):
  drivers: reset: Handle gracefully NULL pointers
  phy: ti: j721e-wiz: Add support for WIZ module present in TI J721E SoC
  configs: j721e_evm_a72: Enable the drivers required for the USB3
support

Kishon Vijay Abraham I (5):
  dm: core: Add helper to compare node names
  usb: cdns3: cdns3-ti: Fix clk_get_by_name() to get the correct name
  ARM: dts: k3-j721e: Add the entries required for USB3 support on USB0
  env: ti: j721e-evm: Add env variable to power on & reset QSGMII PHY in
J7200 EVM
  configs: j7200_evm_a72: Enhance bootcmd to configure ethernet PHY

 .../k3-j7200-common-proc-board-u-boot.dtsi|   12 +
 arch/arm/dts/k3-j7200-common-proc-board.dts   |   23 +
 arch/arm/dts/k3-j7200-main.dtsi   |   63 +
 .../k3-j721e-common-proc-board-u-boot.dtsi|   19 +-
 board/ti/j721e/evm.c  |   34 +-
 configs/j7200_evm_a72_defconfig   |9 +-
 configs/j721e_evm_a72_defconfig   |6 +
 drivers/core/ofnode.c |   13 +
 drivers/phy/Kconfig   |3 +
 drivers/phy/Makefile  |2 +
 drivers/phy/cadence/Kconfig   |   11 +
 drivers/phy/cadence/Makefile  |2 +
 drivers/phy/cadence/phy-cadence-sierra.c  |  757 +
 drivers/phy/cadence/phy-cadence-torrent.c | 2456 +
 drivers/phy/ti/Kconfig|9 +
 drivers/phy/ti/Makefile   |1 +
 drivers/phy/ti/phy-j721e-wiz.c|  985 +++
 drivers/reset/reset-uclass.c  |   30 +-
 drivers/usb/cdns3/cdns3-ti.c  |2 +-
 include/configs/j721e_evm.h   |   16 +-
 include/dm/ofnode.h   |9 +
 include/dt-bindings/phy/phy.h |1 +
 22 files changed, 4445 insertions(+), 18 deletions(-)
 create mode 100644 drivers/phy/cadence/Kconfig
 create mode 100644 drivers/phy/cadence/Makefile
 create mode 100644 drivers/phy/cadence/phy-cadence-sierra.c
 create mode 100644 drivers/phy/cadence/phy-cadence-torrent.c
 create mode 100644 drivers/phy/ti/Kconfig
 create mode 100644 drivers/phy/ti/Makefile
 create mode 100644 drivers/phy/ti/phy-j721e-wiz.c

-- 
2.17.1



[PATCH 01/16] dm: core: Add helper to compare node names

2021-03-09 Thread Kishon Vijay Abraham I
Add helper to compare node names.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/core/ofnode.c | 13 +
 include/dm/ofnode.h   |  9 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index fa0bd2a9c4..4e196d680e 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -18,6 +18,19 @@
 #include 
 #include 
 
+bool ofnode_name_eq(ofnode node, const char *name)
+{
+   const char *node_name;
+   size_t len;
+
+   assert(ofnode_valid(node));
+
+   node_name = ofnode_get_name(node);
+   len = strchrnul(node_name, '@') - node_name;
+
+   return (strlen(name) == len) && (strncmp(node_name, name, len) == 0);
+}
+
 int ofnode_read_u32(ofnode node, const char *propname, u32 *outp)
 {
return ofnode_read_u32_index(node, propname, 0, outp);
diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
index 2c0597c407..86a139276b 100644
--- a/include/dm/ofnode.h
+++ b/include/dm/ofnode.h
@@ -231,6 +231,15 @@ static inline ofnode ofnode_root(void)
return node;
 }
 
+/**
+ * ofnode_name_eq() - Check if the node name is equivalent to a given name
+ *
+ * @node:  valid node reference that has to be compared
+ * @name:  name that has to be compared with the node name
+ * @return 1 if matches, 0 if it doesn't match
+ */
+bool ofnode_name_eq(ofnode node, const char *name);
+
 /**
  * ofnode_read_u32() - Read a 32-bit integer from a property
  *
-- 
2.17.1



[PATCH 02/16] drivers: reset: Handle gracefully NULL pointers

2021-03-09 Thread Kishon Vijay Abraham I
From: Jean-Jacques Hiblot 

Prepare the way for a managed reset API by handling NULL pointers without
crashing nor failing.

Signed-off-by: Jean-Jacques Hiblot 
Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/reset/reset-uclass.c | 30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/drivers/reset/reset-uclass.c b/drivers/reset/reset-uclass.c
index 071c389ca0..98304bc0ee 100644
--- a/drivers/reset/reset-uclass.c
+++ b/drivers/reset/reset-uclass.c
@@ -13,9 +13,12 @@
 #include 
 #include 
 
-static inline struct reset_ops *reset_dev_ops(struct udevice *dev)
+struct reset_ops nop_reset_ops = {
+};
+
+static inline struct reset_ops *reset_dev_ops(struct reset_ctl *r)
 {
-   return (struct reset_ops *)dev->driver->ops;
+   return r ? (struct reset_ops *)r->dev->driver->ops : &nop_reset_ops;
 }
 
 static int reset_of_xlate_default(struct reset_ctl *reset_ctl,
@@ -54,9 +57,10 @@ static int reset_get_by_index_tail(int ret, ofnode node,
debug("%s %d\n", ofnode_get_name(args->node), args->args[0]);
return ret;
}
-   ops = reset_dev_ops(dev_reset);
 
reset_ctl->dev = dev_reset;
+   ops = reset_dev_ops(reset_ctl);
+
if (ops->of_xlate)
ret = ops->of_xlate(reset_ctl, args);
else
@@ -162,29 +166,29 @@ int reset_get_by_name(struct udevice *dev, const char 
*name,
 
 int reset_request(struct reset_ctl *reset_ctl)
 {
-   struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
+   struct reset_ops *ops = reset_dev_ops(reset_ctl);
 
debug("%s(reset_ctl=%p)\n", __func__, reset_ctl);
 
-   return ops->request(reset_ctl);
+   return ops->request ? ops->request(reset_ctl) : 0;
 }
 
 int reset_free(struct reset_ctl *reset_ctl)
 {
-   struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
+   struct reset_ops *ops = reset_dev_ops(reset_ctl);
 
debug("%s(reset_ctl=%p)\n", __func__, reset_ctl);
 
-   return ops->rfree(reset_ctl);
+   return ops->rfree ? ops->rfree(reset_ctl) : 0;
 }
 
 int reset_assert(struct reset_ctl *reset_ctl)
 {
-   struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
+   struct reset_ops *ops = reset_dev_ops(reset_ctl);
 
debug("%s(reset_ctl=%p)\n", __func__, reset_ctl);
 
-   return ops->rst_assert(reset_ctl);
+   return ops->rst_assert ? ops->rst_assert(reset_ctl) : 0;
 }
 
 int reset_assert_bulk(struct reset_ctl_bulk *bulk)
@@ -202,11 +206,11 @@ int reset_assert_bulk(struct reset_ctl_bulk *bulk)
 
 int reset_deassert(struct reset_ctl *reset_ctl)
 {
-   struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
+   struct reset_ops *ops = reset_dev_ops(reset_ctl);
 
debug("%s(reset_ctl=%p)\n", __func__, reset_ctl);
 
-   return ops->rst_deassert(reset_ctl);
+   return ops->rst_deassert ? ops->rst_deassert(reset_ctl) : 0;
 }
 
 int reset_deassert_bulk(struct reset_ctl_bulk *bulk)
@@ -224,11 +228,11 @@ int reset_deassert_bulk(struct reset_ctl_bulk *bulk)
 
 int reset_status(struct reset_ctl *reset_ctl)
 {
-   struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
+   struct reset_ops *ops = reset_dev_ops(reset_ctl);
 
debug("%s(reset_ctl=%p)\n", __func__, reset_ctl);
 
-   return ops->rst_status(reset_ctl);
+   return ops->rst_status ? ops->rst_status(reset_ctl) : 0;
 }
 
 int reset_release_all(struct reset_ctl *reset_ctl, int count)
-- 
2.17.1



[PATCH 03/16] dt-bindings: phy: Add definitions for additional phy types

2021-03-09 Thread Kishon Vijay Abraham I
From: Aswath Govindraju 

Add definitions for additional phy types that's used specifically for
Torrent SERDES.

Signed-off-by: Aswath Govindraju 
Signed-off-by: Kishon Vijay Abraham I 
---
 include/dt-bindings/phy/phy.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/phy/phy.h b/include/dt-bindings/phy/phy.h
index 7e657da454..d3714edd4b 100644
--- a/include/dt-bindings/phy/phy.h
+++ b/include/dt-bindings/phy/phy.h
@@ -19,5 +19,6 @@
 #define PHY_TYPE_DP6
 #define PHY_TYPE_XPCS  7
 #define PHY_TYPE_SGMII 8
+#define PHY_TYPE_QSGMII9
 
 #endif /* _DT_BINDINGS_PHY */
-- 
2.17.1



[PATCH 04/16] phy: cadence: Add driver for Sierra PHY

2021-03-09 Thread Kishon Vijay Abraham I
From: Alan Douglas 

Add a Sierra PHY driver with PCIe and USB support.
This driver is a port from the mainline linux driver.

The PHY has multiple lanes, which can be configured into
groups, and a generic PHY device is created for each group.

There are two resets controlling the overall PHY block, one
to enable the APB interface for programming registers, and
another to enable the PHY itself.  Additionally there are
resets for each PHY lane.

The PHY can be configured in hardware to read register
settings from ROM, or they can be written by the driver.

The sequence of operation on startup is to enable the APB
bus, write the PHY registers (if required)  for each lane
group, and then enable the PHY.  Each group of lanes
can then be individually controlled using the power_on()/
power_off() function for that generic PHY

One difference with the linux driver is that the PHY is
always reset after it is powered-on. This is because role
switching is not supported in u-boot and the cable
orientation is handled by the PHY reset.

Signed-off-by: Jean-Jacques Hiblot 
Signed-off-by: Alan Douglas 
Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Vignesh Raghavendra 
---
 drivers/phy/Kconfig  |   2 +
 drivers/phy/Makefile |   1 +
 drivers/phy/cadence/Kconfig  |   5 +
 drivers/phy/cadence/Makefile |   1 +
 drivers/phy/cadence/phy-cadence-sierra.c | 757 +++
 5 files changed, 766 insertions(+)
 create mode 100644 drivers/phy/cadence/Kconfig
 create mode 100644 drivers/phy/cadence/Makefile
 create mode 100644 drivers/phy/cadence/phy-cadence-sierra.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 008186a10d..9208e430a6 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -269,4 +269,6 @@ config PHY_MTK_TPHY
  so you can easily distinguish them by banks layout.
 
 source "drivers/phy/rockchip/Kconfig"
+source "drivers/phy/cadence/Kconfig"
+
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 3c4a673a83..4736c5eadb 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -31,3 +31,4 @@ obj-$(CONFIG_MT7620_USB_PHY) += mt7620-usb-phy.o
 obj-$(CONFIG_MT76X8_USB_PHY) += mt76x8-usb-phy.o
 obj-$(CONFIG_PHY_DA8XX_USB) += phy-da8xx-usb.o
 obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
+obj-y += cadence/
diff --git a/drivers/phy/cadence/Kconfig b/drivers/phy/cadence/Kconfig
new file mode 100644
index 00..18a04819f5
--- /dev/null
+++ b/drivers/phy/cadence/Kconfig
@@ -0,0 +1,5 @@
+config PHY_CADENCE_SIERRA
+   tristate "Cadence Sierra PHY Driver"
+   depends on DM_RESET
+   help
+ Enable this to support the Cadence Sierra PHY driver
diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile
new file mode 100644
index 00..d57856152a
--- /dev/null
+++ b/drivers/phy/cadence/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_$(SPL_)PHY_CADENCE_SIERRA)+= phy-cadence-sierra.o
diff --git a/drivers/phy/cadence/phy-cadence-sierra.c 
b/drivers/phy/cadence/phy-cadence-sierra.c
new file mode 100644
index 00..66c671aded
--- /dev/null
+++ b/drivers/phy/cadence/phy-cadence-sierra.c
@@ -0,0 +1,757 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Cadence Sierra PHY Driver
+ *
+ * Based on the linux driver provided by Cadence
+ *
+ * Copyright (c) 2018 Cadence Design Systems
+ * Author: Alan Douglas 
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Jean-Jacques Hiblot 
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* PHY register offsets */
+#define SIERRA_COMMON_CDB_OFFSET   0x0
+#define SIERRA_MACRO_ID_REG0x0
+#define SIERRA_CMN_PLLLC_MODE_PREG 0x48
+#define SIERRA_CMN_PLLLC_LF_COEFF_MODE1_PREG   0x49
+#define SIERRA_CMN_PLLLC_LF_COEFF_MODE0_PREG   0x4A
+#define SIERRA_CMN_PLLLC_LOCK_CNTSTART_PREG0x4B
+#define SIERRA_CMN_PLLLC_BWCAL_MODE1_PREG  0x4F
+#define SIERRA_CMN_PLLLC_BWCAL_MODE0_PREG  0x50
+#define SIERRA_CMN_PLLLC_SS_TIME_STEPSIZE_MODE_PREG0x62
+
+#define SIERRA_LANE_CDB_OFFSET(ln, offset) \
+   (0x4000 + ((ln) * (0x800 >> (2 - (offset)
+
+#define SIERRA_DET_STANDEC_A_PREG  0x000
+#define SIERRA_DET_STANDEC_B_PREG  0x001
+#define SIERRA_DET_STANDEC_C_PREG  0x002
+#define SIERRA_DET_STANDEC_D_PREG  0x003
+#define SIERRA_DET_STANDEC_E_PREG  0x004
+#define SIERRA_PSM_LANECAL_DLY_A1_RESETS_PREG  0x008
+#define SIERRA_PSM_A0IN_TMR_PREG   0x009
+#define SIERRA_PSM_DIAG_PREG   0x015
+#define SIERRA_PSC_TX_A0_PREG  0x028
+#define SIERRA_PSC_TX_A1_PREG  

[PATCH 07/16] usb: cdns3: cdns3-ti: Fix clk_get_by_name() to get the correct name

2021-03-09 Thread Kishon Vijay Abraham I
Upstream device tree got updated to use clock name as "ref" instead of
"usb2_refclk". Fix cdns3-ti.c to use the correct name.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/cdns3/cdns3-ti.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/cdns3/cdns3-ti.c b/drivers/usb/cdns3/cdns3-ti.c
index 7b205c5656..43171678ee 100644
--- a/drivers/usb/cdns3/cdns3-ti.c
+++ b/drivers/usb/cdns3/cdns3-ti.c
@@ -101,7 +101,7 @@ static int cdns_ti_probe(struct udevice *dev)
if (!data->usbss)
return -EINVAL;
 
-   ret = clk_get_by_name(dev, "usb2_refclk", &usb2_refclk);
+   ret = clk_get_by_name(dev, "ref", &usb2_refclk);
if (ret) {
dev_err(dev, "Failed to get usb2_refclk\n");
return ret;
-- 
2.17.1



[PATCH 05/16] phy: cadence: Add driver for Torrent SERDES

2021-03-09 Thread Kishon Vijay Abraham I
From: Aswath Govindraju 

Add driver for Torrent SERDES.

Signed-off-by: Aswath Govindraju 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/cadence/Kconfig   |6 +
 drivers/phy/cadence/Makefile  |1 +
 drivers/phy/cadence/phy-cadence-torrent.c | 2456 +
 3 files changed, 2463 insertions(+)
 create mode 100644 drivers/phy/cadence/phy-cadence-torrent.c

diff --git a/drivers/phy/cadence/Kconfig b/drivers/phy/cadence/Kconfig
index 18a04819f5..549ddbf504 100644
--- a/drivers/phy/cadence/Kconfig
+++ b/drivers/phy/cadence/Kconfig
@@ -3,3 +3,9 @@ config PHY_CADENCE_SIERRA
depends on DM_RESET
help
  Enable this to support the Cadence Sierra PHY driver
+
+config PHY_CADENCE_TORRENT
+   tristate "Cadence Torrent PHY Driver"
+   depends on DM_RESET
+   help
+ Enable this to support the Cadence Torrent PHY driver
diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile
index d57856152a..af63b32d9f 100644
--- a/drivers/phy/cadence/Makefile
+++ b/drivers/phy/cadence/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_$(SPL_)PHY_CADENCE_SIERRA)+= phy-cadence-sierra.o
+obj-$(CONFIG_$(SPL_)PHY_CADENCE_TORRENT) += phy-cadence-torrent.o
diff --git a/drivers/phy/cadence/phy-cadence-torrent.c 
b/drivers/phy/cadence/phy-cadence-torrent.c
new file mode 100644
index 00..daaefdd570
--- /dev/null
+++ b/drivers/phy/cadence/phy-cadence-torrent.c
@@ -0,0 +1,2456 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Cadence Torrent SD0801 PHY driver.
+ *
+ * Based on the linux driver provided by Cadence
+ *
+ * Copyright (c) 2018 Cadence Design Systems
+ *
+ * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REF_CLK_19_2MHz1920
+#define REF_CLK_25MHz  2500
+
+#define MAX_NUM_LANES  4
+#define DEFAULT_MAX_BIT_RATE   8100 /* in Mbps*/
+
+#define NUM_SSC_MODE   3
+#define NUM_PHY_TYPE   6
+
+#define POLL_TIMEOUT_US5000
+#define PLL_LOCK_TIMEOUT   10
+
+#define TORRENT_COMMON_CDB_OFFSET  0x0
+
+#define TORRENT_TX_LANE_CDB_OFFSET(ln, block_offset, reg_offset)   \
+   ((0x4000 << (block_offset)) +   \
+   (((ln) << 9) << (reg_offset)))
+#define TORRENT_RX_LANE_CDB_OFFSET(ln, block_offset, reg_offset)   \
+   ((0x8000 << (block_offset)) +   \
+   (((ln) << 9) << (reg_offset)))
+
+#define TORRENT_PHY_PCS_COMMON_OFFSET(block_offset)\
+   (0xC000 << (block_offset))
+
+#define TORRENT_PHY_PMA_COMMON_OFFSET(block_offset)\
+   (0xE000 << (block_offset))
+
+/*
+ * register offsets from SD0801 PHY register block base (i.e MHDP
+ * register base + 0x50)
+ */
+#define CMN_SSM_BANDGAP_TMR0x0021U
+#define CMN_SSM_BIAS_TMR   0x0022U
+#define CMN_PLLSM0_PLLPRE_TMR  0x002AU
+#define CMN_PLLSM0_PLLLOCK_TMR 0x002CU
+#define CMN_PLLSM1_PLLPRE_TMR  0x0032U
+#define CMN_PLLSM1_PLLLOCK_TMR 0x0034U
+#define CMN_CDIAG_CDB_PWRI_OVRD0x0041U
+#define CMN_CDIAG_XCVRC_PWRI_OVRD  0x0047U
+#define CMN_BGCAL_INIT_TMR 0x0064U
+#define CMN_BGCAL_ITER_TMR 0x0065U
+#define CMN_IBCAL_INIT_TMR 0x0074U
+#define CMN_PLL0_VCOCAL_TCTRL  0x0082U
+#define CMN_PLL0_VCOCAL_INIT_TMR   0x0084U
+#define CMN_PLL0_VCOCAL_ITER_TMR   0x0085U
+#define CMN_PLL0_VCOCAL_REFTIM_START   0x0086U
+#define CMN_PLL0_VCOCAL_PLLCNT_START   0x0088U
+#define CMN_PLL0_INTDIV_M0 0x0090U
+#define CMN_PLL0_FRACDIVL_M0   0x0091U
+#define CMN_PLL0_FRACDIVH_M0   0x0092U
+#define CMN_PLL0_HIGH_THR_M0   0x0093U
+#define CMN_PLL0_DSM_DIAG_M0   0x0094U
+#define CMN_PLL0_SS_CTRL1_M0   0x0098U
+#define CMN_PLL0_SS_CTRL2_M0   0x0099U
+#define CMN_PLL0_SS_CTRL3_M0   0x009AU
+#define CMN_PLL0_SS_CTRL4_M0   0x009BU
+#define CMN_PLL0_LOCK_REFCNT_START 0x009CU
+#define CMN_PLL0_LOCK_PLLCNT_START 0x009EU
+#define CMN_PLL0_LOCK_PLLCNT_THR   0x009FU
+#define CMN_PLL0_INTDIV_M1 0x00A0U
+#define CMN_PLL0_FRACDIVH_M1   0x00A2U
+#define CMN_PLL0_HIGH_THR_M1   0x00A3U
+#define CMN_PLL0_DSM_DIAG_M1   0x00A4U
+#define CMN_PLL0_SS_CTRL1_M1   0x00A8U
+#define CMN_PLL0_SS_CTRL2_M1   0x00A9U
+#define CMN_PLL0_SS_CTRL3_M1   0x00AAU
+#define CMN_PLL0_SS_CTRL4_M1   0x00ABU
+#define CMN_PLL1_VCOCAL_TCTRL  0x00C2U
+#define CMN_PLL1_VCOCAL_INIT_TMR   0x00C4U
+#define CMN_PLL1_VCOCAL_ITER_TMR   0x00C5U
+#define CMN_PLL1_VCOCAL_REFTIM_START   0x00C6U
+#def

[PATCH 06/16] phy: ti: j721e-wiz: Add support for WIZ module present in TI J721E SoC

2021-03-09 Thread Kishon Vijay Abraham I
From: Jean-Jacques Hiblot 

Add support for WIZ module present in TI's J721E SoC. WIZ is a SERDES
wrapper used to configure some of the input signals to the SERDES. It is
used with both Sierra(16G) and Torrent(10G) SERDES. This driver configures
three clock selects (pll0, pll1, dig) and supports resets for each of the
lanes.

This is an adaptation of the linux driver.

Signed-off-by: Jean-Jacques Hiblot 
Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/Kconfig|   1 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/ti/Kconfig |   9 +
 drivers/phy/ti/Makefile|   1 +
 drivers/phy/ti/phy-j721e-wiz.c | 985 +
 5 files changed, 997 insertions(+)
 create mode 100644 drivers/phy/ti/Kconfig
 create mode 100644 drivers/phy/ti/Makefile
 create mode 100644 drivers/phy/ti/phy-j721e-wiz.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 9208e430a6..7821161e3c 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -270,5 +270,6 @@ config PHY_MTK_TPHY
 
 source "drivers/phy/rockchip/Kconfig"
 source "drivers/phy/cadence/Kconfig"
+source "drivers/phy/ti/Kconfig"
 
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 4736c5eadb..2efaa8827b 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -32,3 +32,4 @@ obj-$(CONFIG_MT76X8_USB_PHY) += mt76x8-usb-phy.o
 obj-$(CONFIG_PHY_DA8XX_USB) += phy-da8xx-usb.o
 obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
 obj-y += cadence/
+obj-y += ti/
diff --git a/drivers/phy/ti/Kconfig b/drivers/phy/ti/Kconfig
new file mode 100644
index 00..111085f235
--- /dev/null
+++ b/drivers/phy/ti/Kconfig
@@ -0,0 +1,9 @@
+config PHY_J721E_WIZ
+   tristate "TI J721E WIZ (SERDES Wrapper) support"
+   depends on ARCH_K3
+   help
+ This option enables support for WIZ module present in TI's J721E
+ SoC. WIZ is a serdes wrapper used to configure some of the input
+ signals to the SERDES (Sierra/Torrent). This driver configures
+ three clock selects (pll0, pll1, dig) and resets for each of the
+ lanes.
diff --git a/drivers/phy/ti/Makefile b/drivers/phy/ti/Makefile
new file mode 100644
index 00..873ddbf036
--- /dev/null
+++ b/drivers/phy/ti/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_$(SPL_)PHY_J721E_WIZ) += phy-j721e-wiz.o
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
new file mode 100644
index 00..39384f87b8
--- /dev/null
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -0,0 +1,985 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Jean-Jacques Hiblot 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define WIZ_MAX_LANES  4
+#define WIZ_MUX_NUM_CLOCKS 3
+#define WIZ_DIV_NUM_CLOCKS_16G 2
+#define WIZ_DIV_NUM_CLOCKS_10G 1
+
+#define WIZ_SERDES_CTRL0x404
+#define WIZ_SERDES_TOP_CTRL0x408
+#define WIZ_SERDES_RST 0x40c
+#define WIZ_SERDES_TYPEC   0x410
+#define WIZ_LANECTL(n) (0x480 + (0x40 * (n)))
+#define WIZ_LANEDIV(n) (0x484 + (0x40 * (n)))
+
+#define WIZ_MAX_LANES  4
+#define WIZ_MUX_NUM_CLOCKS 3
+#define WIZ_DIV_NUM_CLOCKS_16G 2
+#define WIZ_DIV_NUM_CLOCKS_10G 1
+
+#define WIZ_SERDES_TYPEC_LN10_SWAP BIT(30)
+
+enum wiz_lane_standard_mode {
+   LANE_MODE_GEN1,
+   LANE_MODE_GEN2,
+   LANE_MODE_GEN3,
+   LANE_MODE_GEN4,
+};
+
+enum wiz_refclk_mux_sel {
+   PLL0_REFCLK,
+   PLL1_REFCLK,
+   REFCLK_DIG,
+};
+
+enum wiz_refclk_div_sel {
+   CMN_REFCLK,
+   CMN_REFCLK1,
+};
+
+static const struct reg_field por_en = REG_FIELD(WIZ_SERDES_CTRL, 31, 31);
+static const struct reg_field phy_reset_n = REG_FIELD(WIZ_SERDES_RST, 31, 31);
+static const struct reg_field pll1_refclk_mux_sel =
+   REG_FIELD(WIZ_SERDES_RST, 29, 29);
+static const struct reg_field pll0_refclk_mux_sel =
+   REG_FIELD(WIZ_SERDES_RST, 28, 28);
+static const struct reg_field refclk_dig_sel_16g =
+   REG_FIELD(WIZ_SERDES_RST, 24, 25);
+static const struct reg_field refclk_dig_sel_10g =
+   REG_FIELD(WIZ_SERDES_RST, 24, 24);
+static const struct reg_field pma_cmn_refclk_int_mode =
+   REG_FIELD(WIZ_SERDES_TOP_CTRL, 28, 29);
+static const struct reg_field pma_cmn_refclk_mode =
+   REG_FIELD(WIZ_SERDES_TOP_CTRL, 30, 31);
+static const struct reg_field pma_cmn_refclk_dig_div =
+   REG_FIELD(WIZ_SERDES_TOP_CTRL, 26, 27);
+static const struct reg_field pma_cmn_refclk1_dig_div =
+   REG_FIELD(WIZ_SERDES_TOP_CTRL, 24, 25);
+
+static const struct reg_field p_enable[WIZ_MAX_LAN

[PATCH 08/16] board: ti: j721e: Add support for probing and configuring Torrent serdes on J7200

2021-03-09 Thread Kishon Vijay Abraham I
From: Aswath Govindraju 

Add support for probing and configuring Torrent serdes on J7200.

Signed-off-by: Aswath Govindraju 
Signed-off-by: Kishon Vijay Abraham I 
---
 board/ti/j721e/evm.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index b9a9f19552..580f13c3ab 100644
--- a/board/ti/j721e/evm.c
+++ b/board/ti/j721e/evm.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,7 +30,8 @@
 #define board_is_j721e_som()   (board_ti_k3_is("J721EX-PM1-SOM") || \
 board_ti_k3_is("J721EX-PM2-SOM"))
 
-#define board_is_j7200_som()   board_ti_k3_is("J7200X-PM1-SOM")
+#define board_is_j7200_som()   (board_ti_k3_is("J7200X-PM1-SOM") || \
+board_ti_k3_is("J7200X-PM2-SOM"))
 
 /* Max number of MAC addresses that are parsed/processed per daughter card */
 #define DAUGHTER_CARD_NO_OF_MAC_ADDR   8
@@ -384,6 +386,33 @@ static int probe_daughtercards(void)
 }
 #endif
 
+void configure_serdes_torrent(void)
+{
+   struct udevice *dev;
+   struct phy serdes;
+   int ret;
+
+   if (!IS_ENABLED(CONFIG_PHY_CADENCE_TORRENT))
+   return;
+
+   ret = uclass_get_device_by_driver(UCLASS_PHY,
+ DM_DRIVER_GET(torrent_phy_provider),
+ &dev);
+   if (ret)
+   printf("Torrent init failed:%d\n", ret);
+
+   serdes.dev = dev;
+   serdes.id = 0;
+
+   ret = generic_phy_init(&serdes);
+   if (ret)
+   printf("phy_init failed!!\n");
+
+   ret = generic_phy_power_on(&serdes);
+   if (ret)
+   printf("phy_power_on failed !!\n");
+}
+
 int board_late_init(void)
 {
if (IS_ENABLED(CONFIG_TI_I2C_BOARD_DETECT)) {
@@ -394,6 +423,9 @@ int board_late_init(void)
probe_daughtercards();
}
 
+   if (board_is_j7200_som())
+   configure_serdes_torrent();
+
return 0;
 }
 
-- 
2.17.1



[PATCH 09/16] ARM: dts: k3-j721e: Add the entries required for USB3 support on USB0

2021-03-09 Thread Kishon Vijay Abraham I
Partially sync with Linux's dts to add the entries required for USB3
support on USB0.
Note that the default mode is still "peripheral" not "host". USB3 is
supported only for the host mode.

Signed-off-by: Jean-Jacques Hiblot 
Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Kishon Vijay Abraham I 
---
 .../k3-j721e-common-proc-board-u-boot.dtsi| 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi 
b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
index 3384ed9f3a..3b2e40c13d 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
@@ -115,13 +115,17 @@
u-boot,dm-spl;
 };
 
+&wiz3_pll1_refclk {
+   assigned-clocks = <&wiz3_pll1_refclk>, <&wiz3_pll0_refclk>;
+   assigned-clock-parents = <&k3_clks 295 0>, <&k3_clks 295 9>;
+};
+
 &main_usbss0_pins_default {
u-boot,dm-spl;
 };
 
 &usbss0 {
u-boot,dm-spl;
-   ti,usb2-only;
 };
 
 &usb0 {
@@ -193,3 +197,16 @@
 &mcu_fss0_ospi1_pins_default {
u-boot,dm-spl;
 };
+
+&wiz3_pll1_refclk {
+   assigned-clocks = <&wiz3_pll1_refclk>, <&wiz3_pll0_refclk>;
+   assigned-clock-parents = <&k3_clks 295 0>, <&k3_clks 295 9>;
+};
+
+&serdes_ln_ctrl {
+   u-boot,mux-autoprobe;
+};
+
+&usb_serdes_mux {
+   u-boot,mux-autoprobe;
+};
-- 
2.17.1



[PATCH 10/16] arm: dts: k3-j7200-main: Add DT node for torrent serdes

2021-03-09 Thread Kishon Vijay Abraham I
From: Aswath Govindraju 

Add DT node for torrent serdes.

Signed-off-by: Aswath Govindraju 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/dts/k3-j7200-main.dtsi | 63 +
 1 file changed, 63 insertions(+)

diff --git a/arch/arm/dts/k3-j7200-main.dtsi b/arch/arm/dts/k3-j7200-main.dtsi
index 1131464075..138702cf9d 100644
--- a/arch/arm/dts/k3-j7200-main.dtsi
+++ b/arch/arm/dts/k3-j7200-main.dtsi
@@ -5,6 +5,13 @@
  * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/
  */
 
+/ {
+   serdes_refclk: serdes-refclk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   };
+};
+
 &cbass_main {
msmc_ram: sram@7000 {
compatible = "mmio-sram";
@@ -554,6 +561,62 @@
clock-names = "gpio";
};
 
+   serdes_wiz0: wiz@506 {
+   compatible = "ti,j721e-wiz-10g";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   power-domains = <&k3_pds 292 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <&k3_clks 292 11>, <&k3_clks 292 85>, <&serdes_refclk>;
+   clock-names = "fck", "core_ref_clk", "ext_ref_clk";
+   num-lanes = <4>;
+   #reset-cells = <1>;
+   ranges = <0x506 0x0 0x506 0x1>;
+
+   assigned-clocks = <&k3_clks 292 85>;
+   assigned-clock-parents = <&k3_clks 292 89>;
+
+   wiz0_pll0_refclk: pll0-refclk {
+   clocks = <&k3_clks 292 85>, <&serdes_refclk>;
+   clock-output-names = "wiz0_pll0_refclk";
+   #clock-cells = <0>;
+   assigned-clocks = <&wiz0_pll0_refclk>;
+   assigned-clock-parents = <&k3_clks 292 85>;
+   };
+
+   wiz0_pll1_refclk: pll1-refclk {
+   clocks = <&k3_clks 292 85>, <&serdes_refclk>;
+   clock-output-names = "wiz0_pll1_refclk";
+   #clock-cells = <0>;
+   assigned-clocks = <&wiz0_pll1_refclk>;
+   assigned-clock-parents = <&k3_clks 292 85>;
+   };
+
+   wiz0_refclk_dig: refclk-dig {
+   clocks = <&k3_clks 292 85>, <&serdes_refclk>;
+   clock-output-names = "wiz0_refclk_dig";
+   #clock-cells = <0>;
+   assigned-clocks = <&wiz0_refclk_dig>;
+   assigned-clock-parents = <&k3_clks 292 85>;
+   };
+
+   wiz0_cmn_refclk_dig_div: cmn-refclk-dig-div {
+   clocks = <&wiz0_refclk_dig>;
+   #clock-cells = <0>;
+   };
+
+   serdes0: serdes@506 {
+   compatible = "ti,j721e-serdes-10g";
+   reg = <0x0506 0x0001>;
+   reg-names = "torrent_phy";
+   resets = <&serdes_wiz0 0>;
+   reset-names = "torrent_reset";
+   clocks = <&wiz0_pll0_refclk>;
+   clock-names = "refclk";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+   };
+
usbss0: cdns-usb@4104000 {
compatible = "ti,j721e-usb";
reg = <0x00 0x4104000 0x00 0x100>;
-- 
2.17.1



[PATCH 11/16] arm: dts: k3-j7200-common-proc-board: Enable SERDES DT

2021-03-09 Thread Kishon Vijay Abraham I
From: Aswath Govindraju 

Add default lane function for torrent serdes.

Signed-off-by: Aswath Govindraju 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/dts/k3-j7200-common-proc-board.dts | 23 +
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/dts/k3-j7200-common-proc-board.dts 
b/arch/arm/dts/k3-j7200-common-proc-board.dts
index 5120711d4f..f0440cda1a 100644
--- a/arch/arm/dts/k3-j7200-common-proc-board.dts
+++ b/arch/arm/dts/k3-j7200-common-proc-board.dts
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
chosen {
@@ -281,3 +282,25 @@
ti,adc-channels = <0 1 2 3 4 5 6 7>;
};
 };
+
+&serdes_refclk {
+   clock-frequency = <1>;
+};
+
+&serdes0 {
+   serdes0_pcie_link: link@0 {
+   reg = <0>;
+   cdns,num-lanes = <2>;
+   #phy-cells = <0>;
+   cdns,phy-type = ;
+   resets = <&serdes_wiz0 1>, <&serdes_wiz0 2>;
+   };
+
+   serdes0_qsgmii_link: link@1 {
+   reg = <2>;
+   cdns,num-lanes = <1>;
+   #phy-cells = <0>;
+   cdns,phy-type = ;
+   resets = <&serdes_wiz0 3>;
+   };
+};
-- 
2.17.1



[PATCH 12/16] arm: dts: k3-j7200-common-proc-board-u-boot: Add u-boot tags for torrent serdes

2021-03-09 Thread Kishon Vijay Abraham I
From: Aswath Govindraju 

Add u-boot tags for torrent serdes.

Signed-off-by: Aswath Govindraju 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi 
b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
index bd037be350..bfe1ef5409 100644
--- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
@@ -160,3 +160,15 @@
 &hbmc_mux {
u-boot,dm-spl;
 };
+
+&serdes_ln_ctrl {
+   u-boot,mux-autoprobe;
+};
+
+&usb_serdes_mux {
+   u-boot,mux-autoprobe;
+};
+
+&serdes0 {
+   u-boot,dm-spl;
+};
-- 
2.17.1



[PATCH 13/16] configs: j721e_evm_a72: Enable the drivers required for the USB3 support

2021-03-09 Thread Kishon Vijay Abraham I
From: Jean-Jacques Hiblot 

Enable the mmio mux driver, the J721E-wiz PHy driver and the cadence sierra
phy driver. All of them are required for USB3 support

Signed-off-by: Jean-Jacques Hiblot 
Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Kishon Vijay Abraham I 
---
 configs/j721e_evm_a72_defconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index e14005c39d..5b46f2d53f 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -136,9 +136,15 @@ CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_PHY_TI_DP83867=y
+CONFIG_MULTIPLEXER=y
+CONFIG_MUX_MMIO=y
 CONFIG_PHY_FIXED=y
 CONFIG_DM_ETH=y
 CONFIG_TI_AM65_CPSW_NUSS=y
+CONFIG_PHY=y
+CONFIG_SPL_PHY=y
+CONFIG_PHY_CADENCE_SIERRA=y
+CONFIG_PHY_J721E_WIZ=y
 CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_GENERIC is not set
 CONFIG_SPL_PINCTRL=y
-- 
2.17.1



[PATCH 14/16] configs: j7200_evm_a72_defconfig: Add config for torrent serdes and common clock framework

2021-03-09 Thread Kishon Vijay Abraham I
From: Aswath Govindraju 

Add config for torrent serdes and common clock framework.

Signed-off-by: Aswath Govindraju 
Signed-off-by: Kishon Vijay Abraham I 
---
 configs/j7200_evm_a72_defconfig | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig
index 162bcc8753..bf78b36d22 100644
--- a/configs/j7200_evm_a72_defconfig
+++ b/configs/j7200_evm_a72_defconfig
@@ -96,6 +96,7 @@ CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_CLK=y
 CONFIG_SPL_CLK=y
 CONFIG_CLK_TI_SCI=y
+CONFIG_CLK_CCF=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DFU_SF=y
@@ -138,9 +139,15 @@ CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_SPI_FLASH_MTD=y
+CONFIG_MULTIPLEXER=y
+CONFIG_MUX_MMIO=y
 CONFIG_PHY_FIXED=y
 CONFIG_DM_ETH=y
 CONFIG_TI_AM65_CPSW_NUSS=y
+CONFIG_PHY=y
+CONFIG_SPL_PHY=y
+CONFIG_PHY_CADENCE_TORRENT=y
+CONFIG_PHY_J721E_WIZ=y
 CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_GENERIC is not set
 CONFIG_SPL_PINCTRL=y
-- 
2.17.1



[PATCH 15/16] env: ti: j721e-evm: Add env variable to power on & reset QSGMII PHY in J7200 EVM

2021-03-09 Thread Kishon Vijay Abraham I
MAIN CPSW0 requires the PHY to be powered on and reset for QSGMII
operation. Add a env variable to configure driving "0" on ENET_EXP_PWRDN
controlled by GPIO EXPANDER2 (I2C Addr: 0x22), PIN: 17 and driving "1"
on ENET_EXP_RESETZ controlled by GPIO EXPANDER2 (I2C Addr: 0x22),
PIN: 18.

Signed-off-by: Kishon Vijay Abraham I 
---
 include/configs/j721e_evm.h | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/include/configs/j721e_evm.h b/include/configs/j721e_evm.h
index b707fc4e89..00d0a18a68 100644
--- a/include/configs/j721e_evm.h
+++ b/include/configs/j721e_evm.h
@@ -139,11 +139,24 @@
 #endif /* CONFIG_TARGET_J721E_A72_EVM */
 
 #ifdef CONFIG_TARGET_J7200_A72_EVM
+#define EXTRA_ENV_CONFIG_MAIN_CPSW0_QSGMII_PHY \
+   "do_main_cpsw0_qsgmii_phyinit=1\0"  \
+   "init_main_cpsw0_qsgmii_phy=gpio set gpio@22_17;"   \
+"gpio clear gpio@22_16\0"  \
+   "main_cpsw0_qsgmii_phyinit="\
+   "if test ${do_main_cpsw0_qsgmii_phyinit} -eq 1 && test ${dorprocboot} 
-eq 1 && " \
+   "test ${boot} = mmc; then " \
+   "run init_main_cpsw0_qsgmii_phy;"   \
+   "fi;\0"
 #define DEFAULT_RPROCS ""  \
"2 /lib/firmware/j7200-main-r5f0_0-fw " \
"3 /lib/firmware/j7200-main-r5f0_1-fw "
 #endif /* CONFIG_TARGET_J7200_A72_EVM */
 
+#ifndef EXTRA_ENV_CONFIG_MAIN_CPSW0_QSGMII_PHY
+#define EXTRA_ENV_CONFIG_MAIN_CPSW0_QSGMII_PHY
+#endif
+
 /* set default dfu_bufsiz to 128KB (sector size of OSPI) */
 #define EXTRA_ENV_DFUARGS \
"dfu_bufsiz=0x2\0" \
@@ -170,7 +183,8 @@
EXTRA_ENV_RPROC_SETTINGS\
EXTRA_ENV_DFUARGS   \
DEFAULT_UFS_TI_ARGS \
-   EXTRA_ENV_J721E_BOARD_SETTINGS_MTD
+   EXTRA_ENV_J721E_BOARD_SETTINGS_MTD  \
+   EXTRA_ENV_CONFIG_MAIN_CPSW0_QSGMII_PHY
 
 /* Now for the remaining common defines */
 #include 
-- 
2.17.1



[PATCH 16/16] configs: j7200_evm_a72: Enhance bootcmd to configure ethernet PHY

2021-03-09 Thread Kishon Vijay Abraham I
Update the default BOOTCOMMAND to provide an automatic and easier way
to configure ethernet PHY before loading the firmware.

Signed-off-by: Kishon Vijay Abraham I 
---
 configs/j7200_evm_a72_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig
index bf78b36d22..5929bba82a 100644
--- a/configs/j7200_evm_a72_defconfig
+++ b/configs/j7200_evm_a72_defconfig
@@ -30,7 +30,7 @@ CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
 # CONFIG_USE_SPL_FIT_GENERATOR is not set
 CONFIG_OF_BOARD_SETUP=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run 
boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run 
get_overlay_${boot}; run run_kern"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run 
main_cpsw0_qsgmii_phyinit; run boot_rprocs; run get_kern_${boot}; run 
get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
 CONFIG_LOGLEVEL=7
 CONFIG_SPL_BOARD_INIT=y
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
-- 
2.17.1



Re: [PATCH 1/6] ARM: dts: stm32mp1: explicit clock reference needed by RCC clock driver

2021-03-09 Thread Patrice CHOTARD
Hi Patrick

On 2/24/21 11:19 AM, Patrick Delaunay wrote:
> From: Etienne Carriere 
> 
> Define in the RCC clock provider node which root clocks the driver
> depends on. These are root oscillators, which may be present or
> not, upon FDT content.
> 
> This update binding is introduced in Linux kernel device tree by patch
> "ARM: dts: stm32: move clocks/resets to SCMI resources for stm32mp15"
> 
> This patch is a preliminary step for SCMI support of stm32mp15
> boards with trusted boot chain, based on TF-A or OP-TEE.
> 
> Signed-off-by: Etienne Carriere 
> Signed-off-by: Patrick Delaunay 
> ---
> 
> Reference:
> 
> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210126090120.19900-13-gabriel.fernan...@foss.st.com/
> 
> 
>  arch/arm/dts/stm32mp151.dtsi | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/dts/stm32mp151.dtsi b/arch/arm/dts/stm32mp151.dtsi
> index eedea6f4b8..b564fc6269 100644
> --- a/arch/arm/dts/stm32mp151.dtsi
> +++ b/arch/arm/dts/stm32mp151.dtsi
> @@ -1136,6 +1136,10 @@
>   reg = <0x5000 0x1000>;
>   #clock-cells = <1>;
>   #reset-cells = <1>;
> +
> + clock-names = "hse", "hsi", "csi", "lse", "lsi";
> + clocks = <&clk_hse>, <&clk_hsi>, <&clk_csi>,
> +  <&clk_lse>, <&clk_lsi>;
>   };
>  
>   pwr_regulators: pwr@50001000 {
> 

Reviewed-by: Patrice Chotard 


Re: [PATCH u-boot 16/39] build: use thin archives instead of incremental linking

2021-03-09 Thread Bin Meng
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún  wrote:
>
> Currently we use incremental linking (ld -r) to link several object
> files from one directory into one built-in.o object file containing the
> linked code from that directory (and its subdirectories).
>
> Linux has, some time ago, moved to thin archives instead.
>
> Thin archives are archives (.a) that do not really contain the object
> files, only references to them.
>
> Using thin archives instead of incremental linking
> - saves disk space
> - apparently works better with dead code elimination
> - makes things easier for LTO
>
> The third point is the important one for us. With incremental linking
> there are several options how to do LTO, and that would unnecessarily
> complicate things.
>
> On the other hand, by using thin archives we can make (via the
> --whole-archive use flag) the final linking behave as if we passed all
> the object files from the archives to the linking program as arguments.
>
> We also need to use the P flag for ar, otherwise final linking may fail.
>
> Signed-off-by: Marek Behún 
> ---
>  Makefile   |  4 ++--
>  arch/sandbox/config.mk | 10 +++---
>  scripts/Makefile.build | 16 
>  scripts/Makefile.spl   |  4 ++--
>  4 files changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 7b0ba9df9a..6dc47810ea 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1754,9 +1754,9 @@ ARCH_POSTLINK := $(wildcard 
> $(srctree)/arch/$(ARCH)/Makefile.postlink)
>  quiet_cmd_u-boot__ ?= LD  $@
>cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@
>   \
> -T u-boot.lds $(u-boot-init)  
>   \
> -   --start-group 
>   \
> +   --start-group --whole-archive 
>   \

--start-group is useless now.

> $(u-boot-main)
>   \
> -   --end-group   
>   \
> +   --no-whole-archive --end-group
>   \

and --end-group

> $(PLATFORM_LIBS) -Map u-boot.map; 
>   \
> $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
>
> diff --git a/arch/sandbox/config.mk b/arch/sandbox/config.mk
> index 189e9c2b0c..d11b9c63c9 100644
> --- a/arch/sandbox/config.mk
> +++ b/arch/sandbox/config.mk
> @@ -17,13 +17,17 @@ PLATFORM_CPPFLAGS += $(shell $(SDL_CONFIG) --cflags)
>  endif
>
>  cmd_u-boot__ = $(CC) -o $@ -Wl,-T u-boot.lds $(u-boot-init) \
> -   -Wl,--start-group $(u-boot-main) -Wl,--end-group \
> +   -Wl,--start-group -Wl,--whole-archive \
> +   $(u-boot-main) \
> +   -Wl,--no-whole-archive -Wl,--end-group \
> $(PLATFORM_LIBS) -Wl,-Map -Wl,u-boot.map
>
>  cmd_u-boot-spl = (cd $(obj) && $(CC) -o $(SPL_BIN) -Wl,-T u-boot-spl.lds \
> $(patsubst $(obj)/%,%,$(u-boot-spl-init)) \
> -   -Wl,--start-group $(patsubst $(obj)/%,%,$(u-boot-spl-main)) \
> -   $(patsubst $(obj)/%,%,$(u-boot-spl-platdata)) -Wl,--end-group \
> +   -Wl,--start-group -Wl,--whole-archive \
> +   $(patsubst $(obj)/%,%,$(u-boot-spl-main)) \
> +   $(patsubst $(obj)/%,%,$(u-boot-spl-platdata)) \
> +   -Wl,--no-whole-archive -Wl,--end-group \
> $(PLATFORM_LIBS) -Wl,-Map -Wl,u-boot-spl.map -Wl,--gc-sections)
>
>  CONFIG_ARCH_DEVICE_TREE := sandbox
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index 705a886cb9..a9a02d7d33 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -331,12 +331,11 @@ $(sort $(subdir-obj-y)): $(subdir-ym) ;
>  # Rule to compile a set of .o files into one .o file
>  #
>  ifdef builtin-target
> -quiet_cmd_link_o_target = LD  $@
> +quiet_cmd_link_o_target = AR  $@
>  # If the list of objects to link is empty, just create an empty built-in.o
>  cmd_link_o_target = $(if $(strip $(obj-y)),\
> - $(LD) $(ld_flags) -r -o $@ $(filter $(obj-y), $^) \
> - $(cmd_secanalysis),\
> - rm -f $@; $(AR) rcs$(KBUILD_ARFLAGS) $@)
> + rm -f $@; $(AR) cDPrsT $@ $(filter $(obj-y), $^), \
> + rm -f $@; $(AR) cPrsT$(KBUILD_ARFLAGS) $@)

nits: should we use D for the empty one for consistency?

>
>  $(builtin-target): $(obj-y) FORCE
> $(call if_changed,link_o_target)
> @@ -362,7 +361,7 @@ $(modorder-target): $(subdir-ym) FORCE
>  #
>  ifdef lib-target
>  quiet_cmd_link_l_target = AR  $@
> -cmd_link_l_target = rm -f $@; $(AR) rcs$(KBUILD_ARFLAGS) $@ $(lib-y)
> +cmd_link_l_target = rm -f $@; $(AR) cPrs$(KBUILD_ARFLAGS) $@ $(lib-y)

It looks this line change is not needed

>
>  $(lib-target): $(lib-y) FORCE
> $(call if_changed,link_l_target)
> @@ -382,10 +381,11 @@ $(filter $(addprefix $(obj)/, 

Re: [PATCH 2/6] clk: stm32mp1: gets root clocks from fdt

2021-03-09 Thread Patrice CHOTARD
Hi Patrick

On 2/24/21 11:19 AM, Patrick Delaunay wrote:
> From: Etienne Carriere 
> 
> This change makes stm32mp1 clock driver to get the root clocks
> reference from the device node in the FDT rather than fetching
> straight these clocks by their name. Driver now stores the
> clock reference and use it to know if a root clock is present,
> get its rate or gets its related udevice reference.
> 
> Signed-off-by: Etienne Carriere 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  drivers/clk/clk_stm32mp1.c | 62 ++
>  1 file changed, 23 insertions(+), 39 deletions(-)
> 
> diff --git a/drivers/clk/clk_stm32mp1.c b/drivers/clk/clk_stm32mp1.c
> index 848e33f4e8..0c0ef366a1 100644
> --- a/drivers/clk/clk_stm32mp1.c
> +++ b/drivers/clk/clk_stm32mp1.c
> @@ -250,7 +250,7 @@ DECLARE_GLOBAL_DATA_PTR;
>  enum stm32mp1_parent_id {
>  /*
>   * _HSI, _HSE, _CSI, _LSI, _LSE should not be moved
> - * they are used as index in osc[] as entry point
> + * they are used as index in osc_clk[] as clock reference
>   */
>   _HSI,
>   _HSE,
> @@ -430,8 +430,7 @@ struct stm32mp1_clk_data {
>  struct stm32mp1_clk_priv {
>   fdt_addr_t base;
>   const struct stm32mp1_clk_data *data;
> - ulong osc[NB_OSC];
> - struct udevice *osc_dev[NB_OSC];
> + struct clk osc_clk[NB_OSC];
>  };
>  
>  #define STM32MP1_CLK(off, b, idx, s) \
> @@ -790,7 +789,7 @@ static ulong stm32mp1_clk_get_fixed(struct 
> stm32mp1_clk_priv *priv, int idx)
>   return 0;
>   }
>  
> - return priv->osc[idx];
> + return clk_get_rate(&priv->osc_clk[idx]);
>  }
>  
>  static int stm32mp1_clk_get_id(struct stm32mp1_clk_priv *priv, unsigned long 
> id)
> @@ -1545,7 +1544,7 @@ static int stm32mp1_hsidiv(fdt_addr_t rcc, ulong 
> hsifreq)
>   break;
>  
>   if (hsidiv == 4) {
> - log_err("clk-hsi frequency invalid");
> + log_err("hsi frequency invalid");
>   return -1;
>   }
>  
> @@ -1952,13 +1951,13 @@ static int stm32mp1_clktree(struct udevice *dev)
>* switch ON oscillator found in device-tree,
>* HSI already ON after bootrom
>*/
> - if (priv->osc[_LSI])
> + if (clk_valid(&priv->osc_clk[_LSI]))
>   stm32mp1_lsi_set(rcc, 1);
>  
> - if (priv->osc[_LSE]) {
> + if (clk_valid(&priv->osc_clk[_LSE])) {
>   int bypass, digbyp;
>   u32 lsedrv;
> - struct udevice *dev = priv->osc_dev[_LSE];
> + struct udevice *dev = priv->osc_clk[_LSE].dev;
>  
>   bypass = dev_read_bool(dev, "st,bypass");
>   digbyp = dev_read_bool(dev, "st,digbypass");
> @@ -1969,9 +1968,9 @@ static int stm32mp1_clktree(struct udevice *dev)
>   stm32mp1_lse_enable(rcc, bypass, digbyp, lsedrv);
>   }
>  
> - if (priv->osc[_HSE]) {
> + if (clk_valid(&priv->osc_clk[_HSE])) {
>   int bypass, digbyp, css;
> - struct udevice *dev = priv->osc_dev[_HSE];
> + struct udevice *dev = priv->osc_clk[_HSE].dev;
>  
>   bypass = dev_read_bool(dev, "st,bypass");
>   digbyp = dev_read_bool(dev, "st,digbypass");
> @@ -1996,8 +1995,8 @@ static int stm32mp1_clktree(struct udevice *dev)
>  
>   /* configure HSIDIV */
>   dev_dbg(dev, "configure HSIDIV\n");
> - if (priv->osc[_HSI]) {
> - stm32mp1_hsidiv(rcc, priv->osc[_HSI]);
> + if (clk_valid(&priv->osc_clk[_HSI])) {
> + stm32mp1_hsidiv(rcc, clk_get_rate(&priv->osc_clk[_HSI]));
>   stgen_config(priv);
>   }
>  
> @@ -2043,7 +2042,7 @@ static int stm32mp1_clktree(struct udevice *dev)
>   }
>  
>   /* wait LSE ready before to use it */
> - if (priv->osc[_LSE])
> + if (clk_valid(&priv->osc_clk[_LSE]))
>   stm32mp1_lse_wait(rcc);
>  
>   /* configure with expected clock source */
> @@ -2082,7 +2081,7 @@ static int stm32mp1_clktree(struct udevice *dev)
>  
>   dev_dbg(dev, "oscillator off\n");
>   /* switch OFF HSI if not found in device-tree */
> - if (!priv->osc[_HSI])
> + if (!clk_valid(&priv->osc_clk[_HSI]))
>   stm32mp1_hsi_set(rcc, 0);
>  
>   /* Software Self-Refresh mode (SSR) during DDR initilialization */
> @@ -2178,40 +2177,25 @@ static ulong stm32mp1_clk_set_rate(struct clk *clk, 
> unsigned long clk_rate)
>   return -EINVAL;
>  }
>  
> -static void stm32mp1_osc_clk_init(const char *name,
> -   struct stm32mp1_clk_priv *priv,
> -   int index)
> -{
> - struct clk clk;
> - struct udevice *dev = NULL;
> -
> - priv->osc[index] = 0;
> - clk.id = 0;
> - if (!uclass_get_device_by_name(UCLASS_CLK, name, &dev)) {
> - if (clk_request(dev, &clk))
> - log_err("%s request", name);
> - else
> - priv->osc[index] = clk_get_rate(&clk);
> - }
> - priv->osc_dev[index] = d

Re: [Uboot-stm32] [PATCH 3/6] scmi: Include device_compat.h

2021-03-09 Thread Patrice CHOTARD
Hi Patrick

On 2/24/21 11:19 AM, Patrick Delaunay wrote:
> Include the file needed for log function prototype, this patch solves the
> compilation issue for undefined reference to `dev_err'.
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  drivers/firmware/scmi/smccc_agent.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/firmware/scmi/smccc_agent.c 
> b/drivers/firmware/scmi/smccc_agent.c
> index 64d0929f69..81c2884bb7 100644
> --- a/drivers/firmware/scmi/smccc_agent.c
> +++ b/drivers/firmware/scmi/smccc_agent.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> 

Reviewed-by: Patrice Chotard 

Thanks
Patrice


Re: [Uboot-stm32] [PATCH 4/6] scmi: define LOG_CATEGORY

2021-03-09 Thread Patrice CHOTARD
Hi Patrick

On 2/24/21 11:19 AM, Patrick Delaunay wrote:
> Define LOG_CATEGORY to allow filtering with log command.
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  drivers/firmware/scmi/mailbox_agent.c| 2 ++
>  drivers/firmware/scmi/sandbox-scmi_agent.c   | 2 ++
>  drivers/firmware/scmi/sandbox-scmi_devices.c | 2 ++
>  drivers/firmware/scmi/scmi_agent-uclass.c| 2 ++
>  drivers/firmware/scmi/smccc_agent.c  | 2 ++
>  drivers/firmware/scmi/smt.c  | 2 ++
>  6 files changed, 12 insertions(+)
> 
> diff --git a/drivers/firmware/scmi/mailbox_agent.c 
> b/drivers/firmware/scmi/mailbox_agent.c
> index 3f4b04a4ae..8043e2c2de 100644
> --- a/drivers/firmware/scmi/mailbox_agent.c
> +++ b/drivers/firmware/scmi/mailbox_agent.c
> @@ -3,6 +3,8 @@
>   * Copyright (C) 2020 Linaro Limited.
>   */
>  
> +#define LOG_CATEGORY UCLASS_SCMI_AGENT
> +
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/firmware/scmi/sandbox-scmi_agent.c 
> b/drivers/firmware/scmi/sandbox-scmi_agent.c
> index 35de68c75d..97a5dace15 100644
> --- a/drivers/firmware/scmi/sandbox-scmi_agent.c
> +++ b/drivers/firmware/scmi/sandbox-scmi_agent.c
> @@ -3,6 +3,8 @@
>   * Copyright (C) 2020, Linaro Limited
>   */
>  
> +#define LOG_CATEGORY UCLASS_SCMI_AGENT
> +
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/firmware/scmi/sandbox-scmi_devices.c 
> b/drivers/firmware/scmi/sandbox-scmi_devices.c
> index 1a6fafbf53..69239a198f 100644
> --- a/drivers/firmware/scmi/sandbox-scmi_devices.c
> +++ b/drivers/firmware/scmi/sandbox-scmi_devices.c
> @@ -3,6 +3,8 @@
>   * Copyright (C) 2020, Linaro Limited
>   */
>  
> +#define LOG_CATEGORY UCLASS_MISC
> +
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c 
> b/drivers/firmware/scmi/scmi_agent-uclass.c
> index 516e690ac2..2491e0a747 100644
> --- a/drivers/firmware/scmi/scmi_agent-uclass.c
> +++ b/drivers/firmware/scmi/scmi_agent-uclass.c
> @@ -3,6 +3,8 @@
>   * Copyright (C) 2020 Linaro Limited.
>   */
>  
> +#define LOG_CATEGORY UCLASS_SCMI_AGENT
> +
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/firmware/scmi/smccc_agent.c 
> b/drivers/firmware/scmi/smccc_agent.c
> index 81c2884bb7..f185891e8f 100644
> --- a/drivers/firmware/scmi/smccc_agent.c
> +++ b/drivers/firmware/scmi/smccc_agent.c
> @@ -3,6 +3,8 @@
>   * Copyright (C) 2020 Linaro Limited.
>   */
>  
> +#define LOG_CATEGORY UCLASS_SCMI_AGENT
> +
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/firmware/scmi/smt.c b/drivers/firmware/scmi/smt.c
> index d25478796a..60b9d499b7 100644
> --- a/drivers/firmware/scmi/smt.c
> +++ b/drivers/firmware/scmi/smt.c
> @@ -4,6 +4,8 @@
>   * Copyright (C) 2019-2020 Linaro Limited.
>   */
>  
> +#define LOG_CATEGORY UCLASS_SCMI_AGENT
> +
>  #include 
>  #include 
>  #include 
> 

Reviewed-by: Patrice Chotard 

Thanks
Patrice


Re: [Uboot-stm32] [PATCH 3/6] scmi: Include device_compat.h

2021-03-09 Thread Patrice CHOTARD
Hi Patrick

On 2/24/21 11:19 AM, Patrick Delaunay wrote:
> Include the file needed for log function prototype, this patch solves the
> compilation issue for undefined reference to `dev_err'.
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  drivers/firmware/scmi/smccc_agent.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/firmware/scmi/smccc_agent.c 
> b/drivers/firmware/scmi/smccc_agent.c
> index 64d0929f69..81c2884bb7 100644
> --- a/drivers/firmware/scmi/smccc_agent.c
> +++ b/drivers/firmware/scmi/smccc_agent.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> 


Reviewed-by: Patrice Chotard 

Thanks
Patrice


Re: [Uboot-stm32] [PATCH 5/6] scmi: cosmetic: reorder include files

2021-03-09 Thread Patrice CHOTARD
Hi Patrick

On 2/24/21 11:19 AM, Patrick Delaunay wrote:
> Reorder include files in expected order.
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  drivers/firmware/scmi/mailbox_agent.c | 2 +-
>  drivers/firmware/scmi/scmi_agent-uclass.c | 3 +--
>  2 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/firmware/scmi/mailbox_agent.c 
> b/drivers/firmware/scmi/mailbox_agent.c
> index 8043e2c2de..ea35e7e09e 100644
> --- a/drivers/firmware/scmi/mailbox_agent.c
> +++ b/drivers/firmware/scmi/mailbox_agent.c
> @@ -7,11 +7,11 @@
>  
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c 
> b/drivers/firmware/scmi/scmi_agent-uclass.c
> index 2491e0a747..527163b5ce 100644
> --- a/drivers/firmware/scmi/scmi_agent-uclass.c
> +++ b/drivers/firmware/scmi/scmi_agent-uclass.c
> @@ -7,11 +7,10 @@
>  
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> -
> +#include 
>  #include 
>  #include 
>  
> 


Reviewed-by: Patrice Chotard 

Thanks
Patrice


Re: [PATCH 6/6] configs: stm32mp1_trusted_defconfig rely on SCMI support

2021-03-09 Thread Patrice CHOTARD
Hi Patrick

On 2/24/21 11:19 AM, Patrick Delaunay wrote:
> Enable SCMI clock and reset domain support for stm32mp1 platform
> and ARM SMC mailbox driver used as communication channel for
> SCMI messages between non-secure world and secure SCMI server.
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  configs/stm32mp15_trusted_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/configs/stm32mp15_trusted_defconfig 
> b/configs/stm32mp15_trusted_defconfig
> index da31b74cde..e1746332e6 100644
> --- a/configs/stm32mp15_trusted_defconfig
> +++ b/configs/stm32mp15_trusted_defconfig
> @@ -51,6 +51,7 @@ CONFIG_ENV_UBI_VOLUME="uboot_config"
>  CONFIG_ENV_UBI_VOLUME_REDUND="uboot_config_r"
>  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>  CONFIG_STM32_ADC=y
> +CONFIG_CLK_SCMI=y
>  CONFIG_SET_DFU_ALT_INFO=y
>  CONFIG_USB_FUNCTION_FASTBOOT=y
>  CONFIG_FASTBOOT_BUF_ADDR=0xC000
> @@ -107,6 +108,7 @@ CONFIG_DM_REGULATOR_GPIO=y
>  CONFIG_DM_REGULATOR_STM32_VREFBUF=y
>  CONFIG_DM_REGULATOR_STPMIC1=y
>  CONFIG_REMOTEPROC_STM32_COPRO=y
> +CONFIG_RESET_SCMI=y
>  CONFIG_DM_RNG=y
>  CONFIG_RNG_STM32MP1=y
>  CONFIG_DM_RTC=y
> 



Reviewed-by: Patrice Chotard 

Thanks
Patrice


Re: [PATCH] board: st: remove the nand MTD configuration for NOR boot in stm32mp1 board

2021-03-09 Thread Patrice CHOTARD
Hi Patrick

On 2/25/21 11:49 AM, Patrick Delaunay wrote:
> Since commit d5d726d3cc47 ("configs: stm32mp1: only support SD card after
> NOR in bootcmd_stm32mp"), the stm32mp1 boards only support SD card after
> NOR boot device, so the MTD partitions for nand0 or spi-nand0 are useless
> (no need of "UBI" partition in nand0 or spi-nand0).
> 
> This patch removes these nand MTD update for nor boot and simplify nand0
> and spi-nand0 support (remove the mtd_boot variable).
> 
> Signed-off-by: Patrick Delaunay 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  board/st/common/stm32mp_mtdparts.c | 16 +---
>  1 file changed, 5 insertions(+), 11 deletions(-)
> 
> diff --git a/board/st/common/stm32mp_mtdparts.c 
> b/board/st/common/stm32mp_mtdparts.c
> index 69eb10844d..f074fc189d 100644
> --- a/board/st/common/stm32mp_mtdparts.c
> +++ b/board/st/common/stm32mp_mtdparts.c
> @@ -122,28 +122,24 @@ void board_mtdparts_default(const char **mtdids, const 
> char **mtdparts)
>   log_debug("mtd device = %s\n", dev->name);
>   }
>  
> - if (nor || nand) {
> + if (nand) {
>   mtd = get_mtd_device_nm("nand0");
>   if (!IS_ERR_OR_NULL(mtd)) {
> - const char *mtd_boot = CONFIG_MTDPARTS_NAND0_BOOT;
>   const char *mtd_tee = CONFIG_MTDPARTS_NAND0_TEE;
> -
>   board_set_mtdparts("nand0", ids, parts,
> -!nor ? mtd_boot : NULL,
> +CONFIG_MTDPARTS_NAND0_BOOT,
>  !nor && tee ? mtd_tee : NULL,
>  "-(UBI)");
>   put_mtd_device(mtd);
>   }
>   }
>  
> - if (nor || spinand) {
> + if (spinand) {
>   mtd = get_mtd_device_nm("spi-nand0");
>   if (!IS_ERR_OR_NULL(mtd)) {
> - const char *mtd_boot = CONFIG_MTDPARTS_SPINAND0_BOOT;
>   const char *mtd_tee = CONFIG_MTDPARTS_SPINAND0_TEE;
> -
>   board_set_mtdparts("spi-nand0", ids, parts,
> -!nor ? mtd_boot : NULL,
> +CONFIG_MTDPARTS_SPINAND0_BOOT,
>  !nor && tee ? mtd_tee : NULL,
>  "-(UBI)");
>   put_mtd_device(mtd);
> @@ -152,11 +148,9 @@ void board_mtdparts_default(const char **mtdids, const 
> char **mtdparts)
>  
>   if (nor) {
>   if (!uclass_get_device(UCLASS_SPI_FLASH, 0, &dev)) {
> - const char *mtd_boot = CONFIG_MTDPARTS_NOR0_BOOT;
>   const char *mtd_tee = CONFIG_MTDPARTS_NOR0_TEE;
> -
>   board_set_mtdparts("nor0", ids, parts,
> -mtd_boot,
> +CONFIG_MTDPARTS_NOR0_BOOT,
>  tee ? mtd_tee : NULL,
>  "-(nor_user)");
>   }
> 



Reviewed-by: Patrice Chotard 

Thanks
Patrice


Re: [PATCH 1/4] stm32mp: stm32prog: Add Kconfig file for stm32prog command

2021-03-09 Thread Patrice CHOTARD
Hi Patrick

On 2/25/21 1:37 PM, Patrick Delaunay wrote:
> Move CONFIG_CMD_STM32PROG in a specific Kconfig file for stm32prog command.
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  arch/arm/mach-stm32mp/Kconfig   | 18 +-
>  arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig | 18 ++
>  2 files changed, 19 insertions(+), 17 deletions(-)
>  create mode 100644 arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
> 
> diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
> index f538d7cb83..079d66a80c 100644
> --- a/arch/arm/mach-stm32mp/Kconfig
> +++ b/arch/arm/mach-stm32mp/Kconfig
> @@ -121,23 +121,6 @@ config STM32_ETZPC
>   help
> Say y to enable STM32 Extended TrustZone Protection
>  
> -config CMD_STM32PROG
> - bool "command stm32prog for STM32CudeProgrammer"
> - select DFU
> - select DFU_RAM
> - select DFU_VIRT
> - select PARTITION_TYPE_GUID
> - imply CMD_GPT if MMC
> - imply CMD_MTD if MTD
> - imply DFU_MMC if MMC
> - imply DFU_MTD if MTD
> - help
> - activate a specific command stm32prog for STM32MP soc family
> - witch update the device with the tools STM32CubeProgrammer,
> - using UART with STM32 protocol or USB with DFU protocol
> - NB: access to not volatile memory (NOR/NAND/SD/eMMC) is based
> - on U-Boot DFU framework
> -
>  config CMD_STM32KEY
>   bool "command stm32key to fuse public key hash"
>   default y
> @@ -177,6 +160,7 @@ config DEBUG_UART_CLOCK
>   default 6400
>  endif
>  
> +source "arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig"
>  source "board/st/stm32mp1/Kconfig"
>  source "board/dhelectronics/dh_stm32mp1/Kconfig"
>  
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
> new file mode 100644
> index 00..609a678793
> --- /dev/null
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
> @@ -0,0 +1,18 @@
> +
> +config CMD_STM32PROG
> + bool "command stm32prog for STM32CudeProgrammer"
> + select DFU
> + select DFU_RAM
> + select DFU_VIRT
> + select PARTITION_TYPE_GUID
> + imply CMD_GPT if MMC
> + imply CMD_MTD if MTD
> + imply DFU_MMC if MMC
> + imply DFU_MTD if MTD
> + help
> + activate a specific command stm32prog for STM32MP soc family
> + witch update the device with the tools STM32CubeProgrammer,
> + using UART with STM32 protocol or USB with DFU protocol
> + NB: access to not volatile memory (NOR/NAND/SD/eMMC) is based
> + on U-Boot DFU framework
> +
> 


Reviewed-by: Patrice Chotard 

Thanks
Patrice


Re: [PATCH 2/4] stm32mp: stm32prog: Add CONFIG_CMD_STM32PROG_SERIAL and _USB

2021-03-09 Thread Patrice CHOTARD
Hi Patrick

On 2/25/21 1:37 PM, Patrick Delaunay wrote:
> Add CONFIG_CMD_STM32PROG_SERIAL and CONFIG_CMD_STM32PROG_USB to
> independently select the support of UART or USB communication for
> STM32CubeProgrammer.
> 
> For serial boot over UART, user can deactivate CONFIG_CMD_STM32PROG_SERIAL
> to use U-Boot console of binary loaded by UART (for board bring-up for
> example).
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  arch/arm/mach-stm32mp/Makefile|  2 +-
>  arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig   | 20 ++--
>  arch/arm/mach-stm32mp/cmd_stm32prog/Makefile  |  8 +++
>  .../cmd_stm32prog/cmd_stm32prog.c |  4 ++--
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.h| 23 ++-
>  arch/arm/mach-stm32mp/cpu.c   |  5 ++--
>  board/st/common/stm32mp_dfu.c |  9 
>  7 files changed, 55 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/arm/mach-stm32mp/Makefile b/arch/arm/mach-stm32mp/Makefile
> index c8aa24d489..aa39867080 100644
> --- a/arch/arm/mach-stm32mp/Makefile
> +++ b/arch/arm/mach-stm32mp/Makefile
> @@ -11,7 +11,7 @@ obj-y += bsec.o
>  ifdef CONFIG_SPL_BUILD
>  obj-y += spl.o
>  else
> -obj-$(CONFIG_CMD_STM32PROG) += cmd_stm32prog/
> +obj-y += cmd_stm32prog/
>  obj-$(CONFIG_CMD_STM32KEY) += cmd_stm32key.o
>  obj-$(CONFIG_ARMV7_PSCI) += psci.o
>  obj-$(CONFIG_TFABOOT) += boot_params.o
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
> index 609a678793..f4c0d18d4d 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
> @@ -11,8 +11,24 @@ config CMD_STM32PROG
>   imply DFU_MTD if MTD
>   help
>   activate a specific command stm32prog for STM32MP soc family
> - witch update the device with the tools STM32CubeProgrammer,
> - using UART with STM32 protocol or USB with DFU protocol
> + witch update the device with the tools STM32CubeProgrammer
>   NB: access to not volatile memory (NOR/NAND/SD/eMMC) is based
>   on U-Boot DFU framework
>  
> +config CMD_STM32PROG_USB
> + bool "support stm32prog over USB"
> + depends on CMD_STM32PROG
> + default y
> + help
> + activate the command "stm32prog usb" for STM32MP soc family
> + witch update the device with the tools STM32CubeProgrammer,
> + using USB with DFU protocol
> +
> +config CMD_STM32PROG_SERIAL
> + bool "support stm32prog over UART"
> + depends on CMD_STM32PROG
> + default y
> + help
> + activate the command "stm32prog serial" for STM32MP soc family
> + with the tools STM32CubeProgrammer using U-Boot serial device
> + and UART protocol.
> \ No newline at end of file
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/Makefile 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/Makefile
> index 548a378921..b57e1bf870 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/Makefile
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/Makefile
> @@ -3,7 +3,7 @@
>  # Copyright (C) 2020, STMicroelectronics - All Rights Reserved
>  #
>  
> -obj-y += cmd_stm32prog.o
> -obj-y += stm32prog.o
> -obj-y += stm32prog_serial.o
> -obj-y += stm32prog_usb.o
> +obj-$(CONFIG_CMD_STM32PROG) += cmd_stm32prog.o
> +obj-$(CONFIG_CMD_STM32PROG) += stm32prog.o
> +obj-$(CONFIG_CMD_STM32PROG_SERIAL) += stm32prog_serial.o
> +obj-$(CONFIG_CMD_STM32PROG_USB) += stm32prog_usb.o
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> index 34a6be66c3..a7e2861764 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> @@ -50,9 +50,9 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag, 
> int argc,
>   if (argc < 3 ||  argc > 5)
>   return CMD_RET_USAGE;
>  
> - if (!strcmp(argv[1], "usb"))
> + if (IS_ENABLED(CONFIG_CMD_STM32PROG_USB) && !strcmp(argv[1], "usb"))
>   link = LINK_USB;
> - else if (!strcmp(argv[1], "serial"))
> + else if (IS_ENABLED(CONFIG_CMD_STM32PROG_SERIAL) && !strcmp(argv[1], 
> "serial"))
>   link = LINK_SERIAL;
>  
>   if (link == LINK_UNDEFINED) {
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
> index be482c3402..18af99c78b 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
> @@ -177,9 +177,30 @@ char *stm32prog_get_error(struct stm32prog_data *data);
>  
>  /* Main function */
>  int stm32prog_init(struct stm32prog_data *data, ulong addr, ulong size);
> +void stm32prog_clean(struct stm32prog_data *data);
> +
> +#ifdef CONFIG_CMD_STM32PROG_SERIAL
>  int stm32prog_serial_init(struct stm32prog_data *data, int link_dev);
>  bool stm32prog_serial_loop(struct

Re: [PATCH 3/4] stm32mp: stm32prog: reactivate console and display serial error

2021-03-09 Thread Patrice CHOTARD
Hi Patrick

On 2/25/21 1:37 PM, Patrick Delaunay wrote:
> When serial instance is not found in device tree, the console
> should be enabled and the error should be indicated.
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  arch/arm/mach-stm32mp/cpu.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
> index a453f89d02..527b6290de 100644
> --- a/arch/arm/mach-stm32mp/cpu.c
> +++ b/arch/arm/mach-stm32mp/cpu.c
> @@ -476,11 +476,17 @@ static void setup_boot_mode(void)
>   break;
>   /* serial : search associated alias in devicetree */
>   sprintf(cmd, "serial@%x", serial_addr[instance]);
> - if (uclass_get_device_by_name(UCLASS_SERIAL, cmd, &dev))
> - break;
> - if (fdtdec_get_alias_seq(gd->fdt_blob, "serial",
> -  dev_of_offset(dev), &alias))
> + if (uclass_get_device_by_name(UCLASS_SERIAL, cmd, &dev) ||
> + fdtdec_get_alias_seq(gd->fdt_blob, "serial",
> +  dev_of_offset(dev), &alias)) {
> + /* restore console on error */
> + if (IS_ENABLED(CONFIG_CMD_STM32PROG_SERIAL))
> + gd->flags &= ~(GD_FLG_SILENT |
> +GD_FLG_DISABLE_CONSOLE);
> + printf("serial%d = %s not found in device tree!\n",
> +instance, cmd);
>   break;
> + }
>   sprintf(cmd, "%d", alias);
>   env_set("boot_device", "serial");
>   env_set("boot_instance", cmd);
> 


Reviewed-by: Patrice Chotard 

Thanks
Patrice


Re: [PATCH 4/4] stm32mp: stm32prog: replace alias by serial device sequence number

2021-03-09 Thread Patrice CHOTARD
Hi Patrick

On 2/25/21 1:37 PM, Patrick Delaunay wrote:
> The command "stm32prog serial " can directly use the device sequence
> number of serial uclass as this sequence number is egual to alias when it
> exist; this assumption simplify the code and avoid access to gd->fdt_blob
> and the device tree parsing.
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  .../cmd_stm32prog/stm32prog_serial.c  | 29 ---
>  arch/arm/mach-stm32mp/cpu.c   | 11 +++
>  2 files changed, 10 insertions(+), 30 deletions(-)
> 
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
> index 373ca20886..a51e5e3ec8 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
> @@ -187,36 +187,19 @@ static int stm32prog_read(struct stm32prog_data *data, 
> u8 phase, u32 offset,
>  int stm32prog_serial_init(struct stm32prog_data *data, int link_dev)
>  {
>   struct udevice *dev = NULL;
> - int node;
> - char alias[10];
> - const char *path;
>   struct dm_serial_ops *ops;
>   /* no parity, 8 bits, 1 stop */
>   u32 serial_config = SERIAL_DEFAULT_CONFIG;
>  
>   down_serial_dev = NULL;
>  
> - sprintf(alias, "serial%d", link_dev);
> - path = fdt_get_alias(gd->fdt_blob, alias);
> - if (!path) {
> - log_err("%s alias not found", alias);
> - return -ENODEV;
> - }
> - node = fdt_path_offset(gd->fdt_blob, path);
> - if (!uclass_get_device_by_of_offset(UCLASS_SERIAL, node,
> - &dev)) {
> - down_serial_dev = dev;
> - } else if (node > 0 &&
> -!lists_bind_fdt(gd->dm_root, offset_to_ofnode(node),
> -&dev, false)) {
> - if (!device_probe(dev))
> - down_serial_dev = dev;
> - }
> - if (!down_serial_dev) {
> - log_err("%s = %s device not found", alias, path);
> + if (uclass_get_device_by_seq(UCLASS_SERIAL, link_dev, &dev)) {
> + log_err("serial %d device not found\n", link_dev);
>   return -ENODEV;
>   }
>  
> + down_serial_dev = dev;
> +
>   /* force silent console on uart only when used */
>   if (gd->cur_serial_dev == down_serial_dev)
>   gd->flags |= GD_FLG_DISABLE_CONSOLE | GD_FLG_SILENT;
> @@ -226,11 +209,11 @@ int stm32prog_serial_init(struct stm32prog_data *data, 
> int link_dev)
>   ops = serial_get_ops(down_serial_dev);
>  
>   if (!ops) {
> - log_err("%s = %s missing ops", alias, path);
> + log_err("serial %d = %s missing ops\n", link_dev, dev->name);
>   return -ENODEV;
>   }
>   if (!ops->setconfig) {
> - log_err("%s = %s missing setconfig", alias, path);
> + log_err("serial %d = %s missing setconfig\n", link_dev, 
> dev->name);
>   return -ENODEV;
>   }
>  
> diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
> index 527b6290de..9a76b5633b 100644
> --- a/arch/arm/mach-stm32mp/cpu.c
> +++ b/arch/arm/mach-stm32mp/cpu.c
> @@ -466,7 +466,6 @@ static void setup_boot_mode(void)
>   unsigned int instance = (boot_mode & TAMP_BOOT_INSTANCE_MASK) - 1;
>   u32 forced_mode = (boot_ctx & TAMP_BOOT_FORCED_MASK);
>   struct udevice *dev;
> - int alias;
>  
>   log_debug("%s: boot_ctx=0x%x => boot_mode=%x, instance=%d forced=%x\n",
> __func__, boot_ctx, boot_mode, instance, forced_mode);
> @@ -474,20 +473,18 @@ static void setup_boot_mode(void)
>   case BOOT_SERIAL_UART:
>   if (instance > ARRAY_SIZE(serial_addr))
>   break;
> - /* serial : search associated alias in devicetree */
> + /* serial : search associated node in devicetree */
>   sprintf(cmd, "serial@%x", serial_addr[instance]);
> - if (uclass_get_device_by_name(UCLASS_SERIAL, cmd, &dev) ||
> - fdtdec_get_alias_seq(gd->fdt_blob, "serial",
> -  dev_of_offset(dev), &alias)) {
> + if (uclass_get_device_by_name(UCLASS_SERIAL, cmd, &dev)) {
>   /* restore console on error */
>   if (IS_ENABLED(CONFIG_CMD_STM32PROG_SERIAL))
>   gd->flags &= ~(GD_FLG_SILENT |
>  GD_FLG_DISABLE_CONSOLE);
> - printf("serial%d = %s not found in device tree!\n",
> + printf("uart%d = %s not found in device tree!\n",
>  instance, cmd);
>   break;
>   }
> - sprintf(cmd, "%d", alias);
> + sprintf(cmd, "%d", dev_seq(dev));
>   env_set("boot_device", "serial");
>   env_set("boot_instance", cmd);
>  
> 

Review

[PATCH v2 1/4] watchdog: Set/unset GD_FLG_WDT_READY flag in wdt_start()/wdt_stop()

2021-03-09 Thread Pali Rohár
Watchdog is ready after successful call of ops->start() callback in
wdt_start() function. And is stopped after successful call of ops->stop()
callback in wdt_stop function.

So move setting of GD_FLG_WDT_READY flag from initr_watchdog() function to
wdt_start() and ensure that GD_FLG_WDT_READY flag is unset in wdt_stop()
function.

This change ensures that GD_FLG_WDT_READY flag is set only when watchdog is
running. And ensures that flag is also also when watchdog was started not
only by initr_watchdog() call (e.g. by U-Boot 'wdt' command).

Signed-off-by: Pali Rohár 
---
 drivers/watchdog/wdt-uclass.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
index 28f7918c4673..3f707f61f74f 100644
--- a/drivers/watchdog/wdt-uclass.c
+++ b/drivers/watchdog/wdt-uclass.c
@@ -51,7 +51,6 @@ int initr_watchdog(void)
}
 
wdt_start(gd->watchdog_dev, timeout * 1000, 0);
-   gd->flags |= GD_FLG_WDT_READY;
printf("WDT:   Started with%s servicing (%ds timeout)\n",
   IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out", timeout);
 
@@ -61,21 +60,31 @@ int initr_watchdog(void)
 int wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags)
 {
const struct wdt_ops *ops = device_get_ops(dev);
+   int ret;
 
if (!ops->start)
return -ENOSYS;
 
-   return ops->start(dev, timeout_ms, flags);
+   ret = ops->start(dev, timeout_ms, flags);
+   if (ret == 0)
+   gd->flags |= GD_FLG_WDT_READY;
+
+   return ret;
 }
 
 int wdt_stop(struct udevice *dev)
 {
const struct wdt_ops *ops = device_get_ops(dev);
+   int ret;
 
if (!ops->stop)
return -ENOSYS;
 
-   return ops->stop(dev);
+   ret = ops->stop(dev);
+   if (ret == 0)
+   gd->flags &= ~GD_FLG_WDT_READY;
+
+   return ret;
 }
 
 int wdt_reset(struct udevice *dev)
-- 
2.20.1



Re: [PATCH] stm32mp: bsec: manage clock when present in device tree

2021-03-09 Thread Patrice CHOTARD
Hi Patrick

On 2/25/21 1:43 PM, Patrick Delaunay wrote:
> Enable the clocks during bsec probe when they are present in device tree.
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  arch/arm/mach-stm32mp/bsec.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/mach-stm32mp/bsec.c b/arch/arm/mach-stm32mp/bsec.c
> index 88c7aec8b4..fe39bd80cf 100644
> --- a/arch/arm/mach-stm32mp/bsec.c
> +++ b/arch/arm/mach-stm32mp/bsec.c
> @@ -6,6 +6,7 @@
>  #define LOG_CATEGORY UCLASS_MISC
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -490,6 +491,15 @@ static int stm32mp_bsec_probe(struct udevice *dev)
>  {
>   int otp;
>   struct stm32mp_bsec_plat *plat;
> + struct clk_bulk clk_bulk;
> + int ret;
> +
> + ret = clk_get_bulk(dev, &clk_bulk);
> + if (!ret) {
> + ret = clk_enable_bulk(&clk_bulk);
> + if (ret)
> + return ret;
> + }
>  
>   /*
>* update unlocked shadow for OTP cleared by the rom code
> 

Reviewed-by: Patrice Chotard 
Thanks
Patrice


[PATCH v2 4/4] arm: mvebu: Espressobin: Enable watchdog support but do not start it

2021-03-09 Thread Pali Rohár
Espressobin had disabled watchdog support (CONFIG_WDT) because older stable
Linux kernel versions (which are used by current stable OpenWRT and Debian
versions) do not have support for Armada 3700 watchdog driver. Therefore
they are not able to periodically kick watchdog so Espressobin enter into
boot loop.

This change enable CONFIG_WDT, CONFIG_WDT_ARMADA_37XX and CONFIG_CMD_WDT
options which add support for U-Boot 'wdt' command. And unset new
CONFIG_WATCHDOG_AUTOSTART option which cause that watchdog is not
automatically started by U-Boot during init phase, like when CONFIG_WDT
option is not set at all.

So with this change, U-Boot on Espressobin would have working 'wdt' command
which can be used from boot scripts (e.g. for enabling watchdog prior new
Linux booting kernel). But default behavior of watchdog status stays
unchanged, U-Boot does not start watchdog on Espressobin during its init
phase.

Signed-off-by: Pali Rohár 
---
 configs/mvebu_espressobin-88f3720_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/configs/mvebu_espressobin-88f3720_defconfig 
b/configs/mvebu_espressobin-88f3720_defconfig
index c791f98dfea5..20aa21b06b3d 100644
--- a/configs/mvebu_espressobin-88f3720_defconfig
+++ b/configs/mvebu_espressobin-88f3720_defconfig
@@ -32,6 +32,7 @@ CONFIG_CMD_MMC=y
 CONFIG_CMD_PCI=y
 CONFIG_CMD_SPI=y
 CONFIG_CMD_USB=y
+CONFIG_CMD_WDT=y
 CONFIG_CMD_TFTPPUT=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
@@ -88,5 +89,8 @@ CONFIG_USB_ETHER_ASIX=y
 CONFIG_USB_ETHER_MCS7830=y
 CONFIG_USB_ETHER_RTL8152=y
 CONFIG_USB_ETHER_SMSC95XX=y
+# CONFIG_WATCHDOG_AUTOSTART is not set
+CONFIG_WDT=y
+CONFIG_WDT_ARMADA_37XX=y
 CONFIG_SHA1=y
 CONFIG_SHA256=y
-- 
2.20.1



[PATCH v2 2/4] watchdog: Show error message when initr_watchdog() cannot start watchdog

2021-03-09 Thread Pali Rohár
Function wdt_start() may fail. So in initr_watchdog() function check return
value of wdt_start() call and print error message when watchdog starting
failed.

Signed-off-by: Pali Rohár 
---
 drivers/watchdog/wdt-uclass.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
index 3f707f61f74f..7500b3ed90e3 100644
--- a/drivers/watchdog/wdt-uclass.c
+++ b/drivers/watchdog/wdt-uclass.c
@@ -27,6 +27,7 @@ static ulong reset_period = 1000;
 int initr_watchdog(void)
 {
u32 timeout = WATCHDOG_TIMEOUT_SECS;
+   int ret;
 
/*
 * Init watchdog: This will call the probe function of the
@@ -50,7 +51,12 @@ int initr_watchdog(void)
4 * reset_period) / 4;
}
 
-   wdt_start(gd->watchdog_dev, timeout * 1000, 0);
+   ret = wdt_start(gd->watchdog_dev, timeout * 1000, 0);
+   if (ret != 0) {
+   printf("WDT:   Failed to start\n");
+   return 0;
+   }
+
printf("WDT:   Started with%s servicing (%ds timeout)\n",
   IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out", timeout);
 
-- 
2.20.1



[PATCH v2 3/4] watchdog: Allow to use CONFIG_WDT without starting watchdog

2021-03-09 Thread Pali Rohár
In some cases it is useful to compile support for U-Boot command 'wdt'
without starting HW watchdog in early U-Boot phase. For example when the
user want to start the watchdog only on demand by some boot script.

This change adds a new compile option WATCHDOG_AUTOSTART to control whether
U-Boot should automatically start the watchdog during init phase or not.

This option is enabled by default as it was the default behavior prior
introducing this new change. When compiling U-Boot users can decide to turn
this option off.

Signed-off-by: Pali Rohár 
---
 drivers/watchdog/Kconfig  | 13 +
 drivers/watchdog/wdt-uclass.c |  5 +
 2 files changed, 18 insertions(+)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 602ccbe41c00..aa76a8f2d239 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -9,6 +9,19 @@ config WATCHDOG
  this option if you want to service enabled watchdog by U-Boot. Disable
  this option if you want U-Boot to start watchdog but never service it.
 
+config WATCHDOG_AUTOSTART
+   bool "Automatically start watchdog timer"
+   depends on WDT
+   default y
+   help
+ Automatically start watchdog timer and start servicing it during
+ init phase. Enabled by default. Disable this option if you want
+ to compile U-Boot with CONFIG_WDT support but do not want to
+ activate watchdog, like when CONFIG_WDT option is disabled. You
+ would be able to start watchdog manually by 'wdt' command. Useful
+ when you want to have support for 'wdt' command but do not want
+ to have watchdog enabled by default.
+
 config WATCHDOG_TIMEOUT_MSECS
int "Watchdog timeout in msec"
default 128000 if ARCH_MX25 || ARCH_MX31 || ARCH_MX5 || ARCH_MX6
diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
index 7500b3ed90e3..0603ffbd36d9 100644
--- a/drivers/watchdog/wdt-uclass.c
+++ b/drivers/watchdog/wdt-uclass.c
@@ -51,6 +51,11 @@ int initr_watchdog(void)
4 * reset_period) / 4;
}
 
+   if (!CONFIG_IS_ENABLED(WATCHDOG_AUTOSTART)) {
+   printf("WDT:   Not starting\n");
+   return 0;
+   }
+
ret = wdt_start(gd->watchdog_dev, timeout * 1000, 0);
if (ret != 0) {
printf("WDT:   Failed to start\n");
-- 
2.20.1



Re: [PATCH 3/4] watchdog: Allow to use CONFIG_WDT without starting watchdog

2021-03-09 Thread Pali Rohár
On Tuesday 09 March 2021 12:33:24 Stefan Roese wrote:
> On 05.03.21 22:36, Pali Rohár wrote:
> > In some cases it is useful to compile support for U-Boot command 'wdt'
> > without starting HW watchdog in early U-Boot phase. For example when user
> 
> Nitpicking:
>   when "the" user
> 
> > want to start watchdog only on demand by some boot script.
> > 
> > This change adds a new compile option WATCHDOG_AUTOSTART to control whether
> > U-Boot should automatically start watchdog during init phase or not.
> 
>   start "the" watchdog
> 
> > 
> > This option is enabled by default as it was was default behavior prior
> 
>   as it was the default
> 
> > introducing this new change. When compiling U-Boot users can decide to turn
> > this option off.
> > 
> > Signed-off-by: Pali Rohár 
> > ---
> >   drivers/watchdog/Kconfig  | 13 +
> >   drivers/watchdog/wdt-uclass.c |  7 +++
> >   2 files changed, 20 insertions(+)
> > 
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> > index 602ccbe41c00..aa76a8f2d239 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> > @@ -9,6 +9,19 @@ config WATCHDOG
> >   this option if you want to service enabled watchdog by U-Boot. Disable
> >   this option if you want U-Boot to start watchdog but never service it.
> > +config WATCHDOG_AUTOSTART
> > +   bool "Automatically start watchdog timer"
> > +   depends on WDT
> > +   default y
> > +   help
> > + Automatically start watchdog timer and start servicing it during
> > + init phase. Enabled by default. Disable this option if you want
> > + to compile U-Boot with CONFIG_WDT support but do not want to
> > + activate watchdog, like when CONFIG_WDT option is disabled. You
> > + would be able to start watchdog manually by 'wdt' command. Useful
> > + when you want to have support for 'wdt' command but do not want
> > + to have watchdog enabled by default.
> > +
> >   config WATCHDOG_TIMEOUT_MSECS
> > int "Watchdog timeout in msec"
> > default 128000 if ARCH_MX25 || ARCH_MX31 || ARCH_MX5 || ARCH_MX6
> > diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
> > index 7500b3ed90e3..00a408bf5cc5 100644
> > --- a/drivers/watchdog/wdt-uclass.c
> > +++ b/drivers/watchdog/wdt-uclass.c
> > @@ -27,7 +27,9 @@ static ulong reset_period = 1000;
> >   int initr_watchdog(void)
> >   {
> > u32 timeout = WATCHDOG_TIMEOUT_SECS;
> > +#ifdef CONFIG_WATCHDOG_AUTOSTART
> > int ret;
> > +#endif
> 
> Please don't add more #ifdef's if possible, see below...
> 
> > /*
> >  * Init watchdog: This will call the probe function of the
> > @@ -51,6 +53,10 @@ int initr_watchdog(void)
> > 4 * reset_period) / 4;
> > }
> > +#ifndef CONFIG_WATCHDOG_AUTOSTART
> > +   printf("WDT:   Not starting\n");
> > +   return 0;
> > +#else
> > ret = wdt_start(gd->watchdog_dev, timeout * 1000, 0);
> > if (ret != 0) {
> > printf("WDT:   Failed to start\n");
> > @@ -61,6 +67,7 @@ int initr_watchdog(void)
> >IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out", timeout);
> > return 0;
> > +#endif
> 
> Please use this instead here:
> 
>   if (CONFIG_IS_ENABLED(WATCHDOG_AUTOSTART)) {
>   ...
> 
> Thanks,
> Stefan
> 
> >   }
> >   int wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags)
> > 
> 
> 
> Viele Grüße,
> Stefan

I have fixed these issues in V2.


Re: [PATCH u-boot 17/39] build: support building with Link Time Optimizations

2021-03-09 Thread Bin Meng
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún  wrote:
>
> Add plumbing for building U-Boot with Link Time Optimizations.
>
> Signed-off-by: Marek Behún 
> ---
>  Kbuild   |  2 ++
>  Kconfig  | 19 +++
>  Makefile | 36 
>  scripts/Makefile.lib |  3 +++
>  scripts/Makefile.spl | 14 ++
>  5 files changed, 74 insertions(+)
>
> diff --git a/Kbuild b/Kbuild
> index 1eac091594..bf52e54051 100644
> --- a/Kbuild
> +++ b/Kbuild
> @@ -10,6 +10,8 @@ generic-offsets-file := 
> include/generated/generic-asm-offsets.h
>  always  := $(generic-offsets-file)
>  targets := lib/asm-offsets.s
>
> +CFLAGS_REMOVE_asm-offsets.o := $(LTO_CFLAGS)
> +
>  $(obj)/$(generic-offsets-file): $(obj)/lib/asm-offsets.s FORCE
> $(call filechk,offsets,__GENERIC_ASM_OFFSETS_H__)
>
> diff --git a/Kconfig b/Kconfig
> index 86f0a39bb0..ceba53926f 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -85,6 +85,25 @@ config SPL_OPTIMIZE_INLINING
>   do what it thinks is best, which is desirable in some cases for size
>   reasons.
>
> +config ARCH_SUPPORTS_LTO
> +   bool
> +
> +config LTO
> +   bool "Enable Link Time Optimizations"
> +   depends on ARCH_SUPPORTS_LTO
> +   default n

nits: this line is not needed as the default value is n if omitted

> +   help
> + This option enables Link Time Optimization (LTO), a mechanism which
> + allows the compiler to optimize between different compilation units.
> +
> + This can optimize away dead code paths, resulting in smaller binary
> + size (if CC_OPTIMIZE_FOR_SIZE is enabled).
> +
> + This option is not available for every architecture and may
> + introduce bugs.
> +
> + If unsure, say n.
> +
>  config TPL_OPTIMIZE_INLINING
> bool "Allow compiler to uninline functions marked 'inline' in TPL"
> depends on TPL
> diff --git a/Makefile b/Makefile
> index 6dc47810ea..4eee0c4196 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -677,6 +677,28 @@ else
>  KBUILD_CFLAGS  += -O2
>  endif
>
> +LTO_CFLAGS :=
> +LTO_FINAL_LDFLAGS :=
> +export LTO_CFLAGS LTO_FINAL_LDFLAGS
> +ifdef CONFIG_LTO
> +   LTO_CFLAGS  := -flto
> +   LTO_FINAL_LDFLAGS   := -fwhole-program

This one should not be necessary per my read of the GCC doc. Also in
your patch, it is only used in the SPL build.

> +
> +   CFLAGS_NON_EFI  += $(LTO_CFLAGS)
> +
> +   ifeq ($(cc-name),clang)
> +   LTO_FINAL_LDFLAGS   += -flto
> +   else
> +   LTO_FINAL_LDFLAGS   += -fuse-linker-plugin -flto=jobserver
> +
> +   # use plugin aware tools
> +   AR  = $(CROSS_COMPILE)gcc-ar
> +   NM  = $(CROSS_COMPILE)gcc-nm
> +   endif
> +
> +   KBUILD_CFLAGS   += $(LTO_CFLAGS)
> +endif
> +
>  KBUILD_CFLAGS += $(call cc-option,-fno-stack-protector)
>  KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks)
>
> @@ -1751,6 +1773,19 @@ ARCH_POSTLINK := $(wildcard 
> $(srctree)/arch/$(ARCH)/Makefile.postlink)
>
>  # Rule to link u-boot
>  # May be overridden by arch/$(ARCH)/config.mk
> +ifdef CONFIG_LTO
> +quiet_cmd_u-boot__ ?= LTO $@
> +  cmd_u-boot__ ?=
>   \
> +   $(CC) -nostdlib -nostartfiles 
>   \
> +   $(LTO_FINAL_CFLAGS) $(c_flags)
>   \

LTO_FINAL_CFLAGS is not defined anywhere. I guess you wanted to use
LTO_FINAL_LDFLAGS?

> +   $(KBUILD_LDFLAGS:%=-Wl,%) $(LDFLAGS_u-boot:%=-Wl,%) -o $@ 
>   \
> +   -T u-boot.lds $(u-boot-init)  
>   \
> +   -Wl,--start-group -Wl,--whole-archive 
>   \

--start-group should be dropped

> +   $(u-boot-main)
>   \
> +   -Wl,--no-whole-archive -Wl,--end-group
>   \
> +   $(PLATFORM_LIBS) -Wl,-Map,u-boot.map; 
>   \
> +   $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
> +else
>  quiet_cmd_u-boot__ ?= LD  $@
>cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@
>   \
> -T u-boot.lds $(u-boot-init)  
>   \
> @@ -1759,6 +1794,7 @@ quiet_cmd_u-boot__ ?= LD  $@
> --no-whole-archive --end-group
>   \
> $(PLATFORM_LIBS) -Map u-boot.map; 
>   \
> $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
> +endif
>
>  quiet_cmd_smap = GEN common/system_map.o
>  cmd_smap = \
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 78543c6dd1..78bbeb

Re: [PATCH 1/9] ARM: dts: stm32: Add Engicam i.Core STM32MP1 SoM

2021-03-09 Thread Patrice CHOTARD
Hi Jagan

On 2/28/21 4:52 PM, Jagan Teki wrote:
> i.Core STM32MP1 is an EDIMM SoM based on STM32MP157A from Engicam.
> 
> General features:
> - STM32MP157A
> - Up to 1GB DDR3L
> - 4GB eMMC
> - 10/100 Ethernet
> - USB 2.0 Host/OTG
> - I2S
> - MIPI DSI to LVDS
> - rest of STM32MP157A features
> 
> i.Core STM32MP1 needs to mount on top of Engicam baseboards
> for creating complete platform solutions.
> 
> Add support for it.
> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/stm32mp157a-icore-stm32mp1.dtsi | 196 +++
>  1 file changed, 196 insertions(+)
>  create mode 100644 arch/arm/dts/stm32mp157a-icore-stm32mp1.dtsi
> 
> diff --git a/arch/arm/dts/stm32mp157a-icore-stm32mp1.dtsi 
> b/arch/arm/dts/stm32mp157a-icore-stm32mp1.dtsi
> new file mode 100644
> index 00..01166ccacf
> --- /dev/null
> +++ b/arch/arm/dts/stm32mp157a-icore-stm32mp1.dtsi
> @@ -0,0 +1,196 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> +/*
> + * Copyright (c) STMicroelectronics 2019 - All Rights Reserved
> + * Copyright (c) 2020 Engicam srl
> + * Copyright (c) 2020 Amarula Solutons(India)
> + */
> +
> +/ {
> + compatible = "engicam,icore-stm32mp1", "st,stm32mp157";
> +
> + memory@c000 {
> + device_type = "memory";
> + reg = <0xc000 0x2000>;
> + };
> +
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + mcuram2: mcuram2@1000 {
> + compatible = "shared-dma-pool";
> + reg = <0x1000 0x4>;
> + no-map;
> + };
> +
> + vdev0vring0: vdev0vring0@1004 {
> + compatible = "shared-dma-pool";
> + reg = <0x1004 0x1000>;
> + no-map;
> + };
> +
> + vdev0vring1: vdev0vring1@10041000 {
> + compatible = "shared-dma-pool";
> + reg = <0x10041000 0x1000>;
> + no-map;
> + };
> +
> + vdev0buffer: vdev0buffer@10042000 {
> + compatible = "shared-dma-pool";
> + reg = <0x10042000 0x4000>;
> + no-map;
> + };
> +
> + mcuram: mcuram@3000 {
> + compatible = "shared-dma-pool";
> + reg = <0x3000 0x4>;
> + no-map;
> + };
> +
> + retram: retram@3800 {
> + compatible = "shared-dma-pool";
> + reg = <0x3800 0x1>;
> + no-map;
> + };
> + };
> +
> + vddcore: regulator-vddcore {
> + compatible = "regulator-fixed";
> + regulator-name = "vddcore";
> + regulator-min-microvolt = <120>;
> + regulator-max-microvolt = <120>;
> + regulator-always-on;
> + };
> +
> + vdd: regulator-vdd {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + };
> +
> + vdd_usb: regulator-vdd-usb {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd_usb";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + };
> +
> + vdda: regulator-vdda {
> + compatible = "regulator-fixed";
> + regulator-name = "vdda";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + };
> +
> + vdd_ddr: regulator-vdd-ddr {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd_ddr";
> + regulator-min-microvolt = <135>;
> + regulator-max-microvolt = <135>;
> + regulator-always-on;
> + };
> +
> + vtt_ddr: regulator-vtt-ddr {
> + compatible = "regulator-fixed";
> + regulator-name = "vtt_ddr";
> + regulator-min-microvolt = <675000>;
> + regulator-max-microvolt = <675000>;
> + regulator-always-on;
> + vin-supply = <&vdd>;
> + };
> +
> + vref_ddr: regulator-vref-ddr {
> + compatible = "regulator-fixed";
> + regulator-name = "vref_ddr";
> + regulator-min-microvolt = <675000>;
> + regulator-max-microvolt = <675000>;
> + regulator-always-on;
> + vin-supply = <&vdd>;
> + };
> +
> + vdd_sd: regulator-vdd-sd {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd_sd";
> + regulator-min-microvolt = <330>;
> + regulator-max-micr

Re: [PATCH 2/9] ARM: dts: stm32: Add Engicam i.Core STM32MP1 1X4Gb DDR3

2021-03-09 Thread Patrice CHOTARD
Hi Jagan

On 2/28/21 4:52 PM, Jagan Teki wrote:
> Engicam i.Core STM32MP1 SODIMM SoM has mounted 1x4Gb DDR3
> which has 32bits width 528000Khz frequency.
> 
> Add DDR configuration via dtsi.
> 
> Signed-off-by: Jagan Teki 
> ---
>  .../stm32mp15-ddr3-icore-1x4Gb-1066-binG.dtsi | 119 ++
>  1 file changed, 119 insertions(+)
>  create mode 100644 arch/arm/dts/stm32mp15-ddr3-icore-1x4Gb-1066-binG.dtsi
> 
> diff --git a/arch/arm/dts/stm32mp15-ddr3-icore-1x4Gb-1066-binG.dtsi 
> b/arch/arm/dts/stm32mp15-ddr3-icore-1x4Gb-1066-binG.dtsi
> new file mode 100644
> index 00..1a45c6fc63
> --- /dev/null
> +++ b/arch/arm/dts/stm32mp15-ddr3-icore-1x4Gb-1066-binG.dtsi
> @@ -0,0 +1,119 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> +/*
> + * Copyright (C) 2015-2018, STMicroelectronics - All Rights Reserved
> + */
> +
> +/*
> + * File generated by STMicroelectronics STM32CubeMX DDR Tool for MPUs
> + * DDR type: DDR3 / DDR3L
> + * DDR width: 32bits
> + * DDR density: 4Gb
> + * System frequency: 528000Khz
> + * Relaxed Timing Mode: false
> + * Address mapping type: RBC
> + *
> + * Save Date: 2019.05.14, save Time: 11:25:16
> + */
> +#define DDR_MEM_COMPATIBLE ddr3-icore-1066-888-bin-g-1x4gb-528mhz
> +#define DDR_MEM_NAME "DDR3-DDR3L 32bits 528000Khz"
> +#define DDR_MEM_SPEED528000
> +#define DDR_MEM_SIZE 0x2000
> +
> +#define DDR_MSTR 0x00040401
> +#define DDR_MRCTRL0 0x0010
> +#define DDR_MRCTRL1 0x
> +#define DDR_DERATEEN 0x
> +#define DDR_DERATEINT 0x0080
> +#define DDR_PWRCTL 0x
> +#define DDR_PWRTMG 0x00400010
> +#define DDR_HWLPCTL 0x
> +#define DDR_RFSHCTL0 0x0021
> +#define DDR_RFSHCTL3 0x
> +#define DDR_RFSHTMG 0x0080008A
> +#define DDR_CRCPARCTL0 0x
> +#define DDR_DRAMTMG0 0x121B2414
> +#define DDR_DRAMTMG1 0x000A041B
> +#define DDR_DRAMTMG2 0x0607080F
> +#define DDR_DRAMTMG3 0x0050400C
> +#define DDR_DRAMTMG4 0x07040607
> +#define DDR_DRAMTMG5 0x06060403
> +#define DDR_DRAMTMG6 0x02020002
> +#define DDR_DRAMTMG7 0x0202
> +#define DDR_DRAMTMG8 0x1005
> +#define DDR_DRAMTMG14 0x00A0
> +#define DDR_ZQCTL0 0xC240
> +#define DDR_DFITMG0 0x02050105
> +#define DDR_DFITMG1 0x0202
> +#define DDR_DFILPCFG0 0x0700
> +#define DDR_DFIUPD0 0xC043
> +#define DDR_DFIUPD1 0x
> +#define DDR_DFIUPD2 0x
> +#define DDR_DFIPHYMSTR 0x
> +#define DDR_ODTCFG 0x06000600
> +#define DDR_ODTMAP 0x0001
> +#define DDR_SCHED 0x0C01
> +#define DDR_SCHED1 0x
> +#define DDR_PERFHPR1 0x0101
> +#define DDR_PERFLPR1 0x08000200
> +#define DDR_PERFWR1 0x08000400
> +#define DDR_DBG0 0x
> +#define DDR_DBG1 0x
> +#define DDR_DBGCMD 0x
> +#define DDR_POISONCFG 0x
> +#define DDR_PCCFG 0x0010
> +#define DDR_PCFGR_0 0x0001
> +#define DDR_PCFGW_0 0x
> +#define DDR_PCFGQOS0_0 0x02100C03
> +#define DDR_PCFGQOS1_0 0x00800100
> +#define DDR_PCFGWQOS0_0 0x01100C03
> +#define DDR_PCFGWQOS1_0 0x01000200
> +#define DDR_PCFGR_1 0x0001
> +#define DDR_PCFGW_1 0x
> +#define DDR_PCFGQOS0_1 0x02100C03
> +#define DDR_PCFGQOS1_1 0x00800040
> +#define DDR_PCFGWQOS0_1 0x01100C03
> +#define DDR_PCFGWQOS1_1 0x01000200
> +#define DDR_ADDRMAP1 0x00080808
> +#define DDR_ADDRMAP2 0x
> +#define DDR_ADDRMAP3 0x
> +#define DDR_ADDRMAP4 0x1F1F
> +#define DDR_ADDRMAP5 0x07070707
> +#define DDR_ADDRMAP6 0x0F0F0707
> +#define DDR_ADDRMAP9 0x
> +#define DDR_ADDRMAP10 0x
> +#define DDR_ADDRMAP11 0x
> +#define DDR_PGCR 0x01442E02
> +#define DDR_PTR0 0x0022A41B
> +#define DDR_PTR1 0x047C0740
> +#define DDR_PTR2 0x042D9C80
> +#define DDR_ACIOCR 0x10400812
> +#define DDR_DXCCR 0x0C40
> +#define DDR_DSGCR 0xF21F
> +#define DDR_DCR 0x000B
> +#define DDR_DTPR0 0x36D477D0
> +#define DDR_DTPR1 0x098A00D8
> +#define DDR_DTPR2 0x10023600
> +#define DDR_MR0 0x0830
> +#define DDR_MR1 0x
> +#define DDR_MR2 0x0208
> +#define DDR_MR3 0x
> +#define DDR_ODTCR 0x0001
> +#define DDR_ZQ0CR1 0x0038
> +#define DDR_DX0GCR 0xCE81
> +#define DDR_DX0DLLCR 0x4000
> +#define DDR_DX0DQTR 0x
> +#define DDR_DX0DQSTR 0x3DB02000
> +#define DDR_DX1GCR 0xCE81
> +#define DDR_DX1DLLCR 0x4000
> +#define DDR_DX1DQTR 0x
> +#define DDR_DX1DQSTR 0x3DB02000
> +#define DDR_DX2GCR 0xCE81
> +#define DDR_DX2DLLCR 0x4000
> +#define DDR_DX2DQTR 0x
> +#define DDR_DX2DQSTR 0x3DB02000
> +#define DDR_DX3GCR 0xCE81
> +#define DDR_DX3DLLCR 0x4000
> +#define DDR_DX3DQTR 0x
> +#define DDR_DX3DQSTR 0x3DB02000
> +
> +#include "stm32mp15-ddr.dtsi"
> 


Reviewed-by: Patrice Chotard 
Thanks
Patrice


[PATCH] rtc: add support for rv3028 rtc

2021-03-09 Thread Heiko Schocher
add support for rtc3028 rtc from microcrystal.
based on linux dirver:
commit a38fd8748464: ("Linux 5.12-rc2")

Signed-off-by: Heiko Schocher 

---
driver is based on code in linux, but with already
corrected weekday usage. linux codes the weekday
bitwise, while the weekday register has only 3 valid
bits as the app manual [1] says:

This register holds the current day of the week. Each value represents
one weekday that is assigned by the user. Values will range from 0 to 6
The weekday counter is simply a 3-bit counter which counts up to 6
and then resets to 0.

[1] 
https://www.microcrystal.com/fileadmin/Media/Products/RTC/App.Manual/RV-3028-C7_App-Manual.pdf

This is not a big problem, as userspace never use weekday.
Nevertheless, I will also send an update for the linux driver.

Also the nvram can be used for bootcounter purposes.

Tested this driver on "PHYTEC phyBOARD-Pollux i.MX8MP" board.

azure build:
https://dev.azure.com/hs0298/hs/_build/results?buildId=63&view=results

 drivers/rtc/Kconfig  |   6 ++
 drivers/rtc/Makefile |   1 +
 drivers/rtc/rv3028.c | 215 +++
 3 files changed, 222 insertions(+)
 create mode 100644 drivers/rtc/rv3028.c

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index aa6d90158c..e451308b40 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -95,6 +95,12 @@ config RTC_PCF8563
  If you say yes here you get support for the Philips PCF8563 RTC
  and compatible chips.
 
+config RTC_RV3028
+   bool "Enable RV3028 driver"
+   depends on DM_RTC
+   help
+ The MicroCrystal RV3028 is a I2C Real Time Clock (RTC)
+
 config RTC_RV3029
bool "Enable RV3029 driver"
depends on DM_RTC
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 6a45a9c874..e7acd76266 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_RTC_PCF2127) += pcf2127.o
 obj-$(CONFIG_RTC_PL031) += pl031.o
 obj-$(CONFIG_RTC_PT7C4338) += pt7c4338.o
 obj-$(CONFIG_RTC_RS5C372A) += rs5c372.o
+obj-$(CONFIG_RTC_RV3028) += rv3028.o
 obj-$(CONFIG_RTC_RV3029) += rv3029.o
 obj-$(CONFIG_RTC_RV8803) += rv8803.o
 obj-$(CONFIG_RTC_RX8025) += rx8025.o
diff --git a/drivers/rtc/rv3028.c b/drivers/rtc/rv3028.c
new file mode 100644
index 00..8d8336c5f1
--- /dev/null
+++ b/drivers/rtc/rv3028.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * RTC driver for the Micro Crystal RV3028
+ *
+ * based on linux driver from
+ * Copyright (C) 2019 Micro Crystal SA
+ *
+ * Alexandre Belloni 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RV3028_SEC 0x00
+#define RV3028_MIN 0x01
+#define RV3028_HOUR0x02
+#define RV3028_WDAY0x03
+#define RV3028_DAY 0x04
+#define RV3028_MONTH   0x05
+#define RV3028_YEAR0x06
+#define RV3028_ALARM_MIN   0x07
+#define RV3028_ALARM_HOUR  0x08
+#define RV3028_ALARM_DAY   0x09
+#define RV3028_STATUS  0x0E
+#define RV3028_CTRL1   0x0F
+#define RV3028_CTRL2   0x10
+#define RV3028_EVT_CTRL0x13
+#define RV3028_TS_COUNT0x14
+#define RV3028_TS_SEC  0x15
+#define RV3028_RAM10x1F
+#define RV3028_EEPROM_ADDR 0x25
+#define RV3028_EEPROM_DATA 0x26
+#define RV3028_EEPROM_CMD  0x27
+#define RV3028_CLKOUT  0x35
+#define RV3028_OFFSET  0x36
+#define RV3028_BACKUP  0x37
+
+#define RV3028_STATUS_PORF BIT(0)
+#define RV3028_STATUS_EVF  BIT(1)
+#define RV3028_STATUS_AF   BIT(2)
+#define RV3028_STATUS_TF   BIT(3)
+#define RV3028_STATUS_UF   BIT(4)
+#define RV3028_STATUS_BSF  BIT(5)
+#define RV3028_STATUS_CLKF BIT(6)
+#define RV3028_STATUS_EEBUSY   BIT(7)
+
+#define RV3028_CLKOUT_FD_MASK  GENMASK(2, 0)
+#define RV3028_CLKOUT_PORIEBIT(3)
+#define RV3028_CLKOUT_CLKSYBIT(6)
+#define RV3028_CLKOUT_CLKOEBIT(7)
+
+#define RV3028_CTRL1_EERD  BIT(3)
+#define RV3028_CTRL1_WADA  BIT(5)
+
+#define RV3028_CTRL2_RESET BIT(0)
+#define RV3028_CTRL2_12_24 BIT(1)
+#define RV3028_CTRL2_EIE   BIT(2)
+#define RV3028_CTRL2_AIE   BIT(3)
+#define RV3028_CTRL2_TIE   BIT(4)
+#define RV3028_CTRL2_UIE   BIT(5)
+#define RV3028_CTRL2_TSE   BIT(7)
+
+#define RV3028_EVT_CTRL_TSRBIT(2)
+
+#define RV3028_EEPROM_CMD_UPDATE   0x11
+#define RV3028_EEPROM_CMD_WRITE0x21
+#define RV3028_EEPROM_CMD_READ 0x22
+
+#define RV3028_EEBUSY_POLL 1
+#define RV3028_E

Re: [PATCH 3/9] ARM: stm32: Imply SPL_SPI_LOAD

2021-03-09 Thread Patrice CHOTARD
Hi Jagan

On 2/28/21 4:52 PM, Jagan Teki wrote:
> SPI Load isn't mandatory for STM32 builds.
> 
> Let's imply instead of select it to get rid of build
> issues for non-SPI defconfigs.
> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/mach-stm32mp/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
> index f538d7cb83..79ffd5191d 100644
> --- a/arch/arm/mach-stm32mp/Kconfig
> +++ b/arch/arm/mach-stm32mp/Kconfig
> @@ -16,13 +16,13 @@ config SPL
>   select SPL_REGMAP
>   select SPL_DM_RESET
>   select SPL_SERIAL_SUPPORT
> - select SPL_SPI_LOAD
>   select SPL_SYSCON
>   select SPL_WATCHDOG_SUPPORT if WATCHDOG
>   imply BOOTSTAGE_STASH if SPL_BOOTSTAGE
>   imply SPL_BOOTSTAGE if BOOTSTAGE
>   imply SPL_DISPLAY_PRINT
>   imply SPL_LIBDISK_SUPPORT
> + imply SPL_SPI_LOAD
>  
>  config SYS_SOC
>   default "stm32mp"
> 

Reviewed-by: Patrice Chotard 

Thanks
Patrice


Re: [PATCH u-boot-marvell 02/39] ddr: marvell: axp: fix array types have different bounds warning

2021-03-09 Thread Tom Rini
On Mon, Mar 08, 2021 at 07:50:59AM +0100, Stefan Roese wrote:
> On 08.03.21 07:45, Marek Behun wrote:
> > > Reviewed-by: Stefan Roese 
> > 
> > Thanks, Stefan.
> > Do you want to merge this into your repo u-boot-marvell, or shall Tom
> > merge this once this series is mature?
> 
> AFAIU, your patch series touches many architectures / platforms. It'
> currently assigned to Tom in patchwork and it perhaps makes more sense
> to pull it as one patchset.
> 
> If it is preferred that I shall pull the 2 Marvell related patches
> via the Marvell repo, I can definitely do so. But for now I'm waiting
> for Tom to handle this.

If it's not exposing problems prior to LTO, I'll take it as the series,
if it's exposing problems today and it should go in now rather than for
v2021.07, please pick it up for the marvell tree.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 4/9] board: stm32: Add Engicam i.Core STM32MP1 EDIMM2.2 Starter Kit

2021-03-09 Thread Patrice CHOTARD
Hi Jagan

one remark below

On 2/28/21 4:52 PM, Jagan Teki wrote:
> Engicam EDIMM2.2 Starter Kit is an EDIMM 2.2 Form Factor Capacitive
> Evaluation Board.
> 
> Genaral features:
> - LCD 7" C.Touch
> - microSD slot
> - Ethernet 1Gb
> - Wifi/BT
> - 2x LVDS Full HD interfaces
> - 3x USB 2.0
> - 1x USB 3.0
> - HDMI Out
> - Mini PCIe
> - MIPI CSI
> - 2x CAN
> - Audio Out
> 
> i.Core STM32MP1 is an EDIMM SoM based on STM32MP157A from Engicam.
> 
> i.Core STM32MP1 needs to mount on top of this Evaluation board for
> creating complete i.Core STM32MP1 EDIMM2.2 Starter Kit.
> 
> Add support for it.
> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/Makefile |   1 +
>  ...mp157a-icore-stm32mp1-edimm2.2-u-boot.dtsi |  51 ++
>  .../stm32mp157a-icore-stm32mp1-edimm2.2.dts   |  47 ++
>  .../stm32mp157a-icore-stm32mp1-u-boot.dtsi| 146 ++
>  arch/arm/mach-stm32mp/Kconfig |  20 +++
>  board/engicam/stm32mp1/Kconfig|  12 ++
>  board/engicam/stm32mp1/MAINTAINERS|   6 +
>  board/engicam/stm32mp1/Makefile   |  10 ++
>  board/engicam/stm32mp1/spl.c  |  48 ++
>  board/engicam/stm32mp1/stm32mp1.c | 131 
>  ...tm32mp15-icore-stm32mp1-edimm2.2_defconfig |  80 ++
>  11 files changed, 552 insertions(+)
>  create mode 100644 
> arch/arm/dts/stm32mp157a-icore-stm32mp1-edimm2.2-u-boot.dtsi
>  create mode 100644 arch/arm/dts/stm32mp157a-icore-stm32mp1-edimm2.2.dts
>  create mode 100644 arch/arm/dts/stm32mp157a-icore-stm32mp1-u-boot.dtsi
>  create mode 100644 board/engicam/stm32mp1/Kconfig
>  create mode 100644 board/engicam/stm32mp1/MAINTAINERS
>  create mode 100644 board/engicam/stm32mp1/Makefile
>  create mode 100644 board/engicam/stm32mp1/spl.c
>  create mode 100644 board/engicam/stm32mp1/stm32mp1.c
>  create mode 100644 configs/stm32mp15-icore-stm32mp1-edimm2.2_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index f478f6f18f..f4a48c65e8 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -979,6 +979,7 @@ dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb
>  dtb-$(CONFIG_STM32MP15x) += \
>   stm32mp157a-dk1.dtb \
>   stm32mp157a-avenger96.dtb \
> + stm32mp157a-icore-stm32mp1-edimm2.2.dtb \
>   stm32mp157c-dk2.dtb \
>   stm32mp157c-ed1.dtb \
>   stm32mp157c-ev1.dtb \
> diff --git a/arch/arm/dts/stm32mp157a-icore-stm32mp1-edimm2.2-u-boot.dtsi 
> b/arch/arm/dts/stm32mp157a-icore-stm32mp1-edimm2.2-u-boot.dtsi
> new file mode 100644
> index 00..96fe461235
> --- /dev/null
> +++ b/arch/arm/dts/stm32mp157a-icore-stm32mp1-edimm2.2-u-boot.dtsi
> @@ -0,0 +1,51 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> +/*
> + * Copyright (C) STMicroelectronics 2019 - All Rights Reserved
> + * Copyright (c) 2020 Amarula Solutions(India)
> + * Author: Jagan Teki 
> + */
> +
> +#include "stm32mp157a-icore-stm32mp1-u-boot.dtsi"
> +
> +/{
> + aliases {
> + mmc0 = &sdmmc1;
> + };
> +
> + chosen {
> + stdout-path = &uart4;
> + };
> +};
> +
> +&sdmmc1 {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&sdmmc1_b4_pins_a {
> + u-boot,dm-pre-reloc;
> +
> + pins1 {
> + u-boot,dm-pre-reloc;
> + };
> +
> + pins2 {
> + u-boot,dm-pre-reloc;
> + };
> +};
> +
> +&uart4 {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&uart4_pins_a {
> + u-boot,dm-pre-reloc;
> +
> + pins1 {
> + u-boot,dm-pre-reloc;
> + };
> +
> + pins2 {
> + u-boot,dm-pre-reloc;
> + bias-pull-up;
> + };
> +};
> diff --git a/arch/arm/dts/stm32mp157a-icore-stm32mp1-edimm2.2.dts 
> b/arch/arm/dts/stm32mp157a-icore-stm32mp1-edimm2.2.dts
> new file mode 100644
> index 00..ec9f1d1cd5
> --- /dev/null
> +++ b/arch/arm/dts/stm32mp157a-icore-stm32mp1-edimm2.2.dts
> @@ -0,0 +1,47 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> +/*
> + * Copyright (c) STMicroelectronics 2019 - All Rights Reserved
> + * Copyright (c) 2020 Engicam srl
> + * Copyright (c) 2020 Amarula Solutons(India)
> + */
> +
> +/dts-v1/;
> +#include "stm32mp157.dtsi"
> +#include "stm32mp157a-icore-stm32mp1.dtsi"
> +#include "stm32mp15-pinctrl.dtsi"
> +#include "stm32mp15xxaa-pinctrl.dtsi"
> +#include 
> +
> +/ {
> + model = "Engicam i.Core STM32MP1 EDIMM2.2 Starter Kit";
> + compatible = "engicam,icore-stm32mp1-edimm2.2",
> +  "engicam,icore-stm32mp1", "st,stm32mp157";
> +
> + aliases {
> + serial0 = &uart4;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&sdmmc1 {
> + bus-width = <4>;
> + disable-wp;
> + pinctrl-names = "default", "opendrain", "sleep";
> + pinctrl-0 = <&sdmmc1_b4_pins_a>;
> + pinctrl-1 = <&sdmmc1_b4_od_pins_a>;
> + pinctrl-2 = <&sdmmc1_b4_sleep_pins_a>;
> + st,neg-edge;
> + vmmc-supply = <&v3v3>;
> + statu

Re: [PATCH 5/9] board: stm32: Add Engicam i.Core STM32MP1 C.TOUCH 2.0

2021-03-09 Thread Patrice CHOTARD
Hi Jagan

On 2/28/21 4:52 PM, Jagan Teki wrote:
> Engicam C.TOUCH 2.0 is an EDIMM compliant general purpose Carrier
> board.
> 
> Genaral features:
> - Ethernet 10/100
> - Wifi/BT
> - USB Type A/OTG
> - Audio Out
> - CAN
> - LVDS panel connector
> 
> i.Core STM32MP1 is an EDIMM SoM based on STM32MP157A from Engicam.
> 
> i.Core STM32MP1 needs to mount on top of this Carrier board for
> creating complete i.Core STM32MP1 C.TOUCH 2.0 board.
> 
> Add support for it.
> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/Makefile |  1 +
>  ...2mp157a-icore-stm32mp1-ctouch2-u-boot.dtsi | 51 
>  .../stm32mp157a-icore-stm32mp1-ctouch2.dts| 47 +++
>  arch/arm/mach-stm32mp/Kconfig |  5 ++
>  board/engicam/stm32mp1/MAINTAINERS|  6 ++
>  ...stm32mp15-icore-stm32mp1-ctouch2_defconfig | 80 +++
>  6 files changed, 190 insertions(+)
>  create mode 100644 
> arch/arm/dts/stm32mp157a-icore-stm32mp1-ctouch2-u-boot.dtsi
>  create mode 100644 arch/arm/dts/stm32mp157a-icore-stm32mp1-ctouch2.dts
>  create mode 100644 configs/stm32mp15-icore-stm32mp1-ctouch2_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index f4a48c65e8..7e0fae8cf0 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -979,6 +979,7 @@ dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb
>  dtb-$(CONFIG_STM32MP15x) += \
>   stm32mp157a-dk1.dtb \
>   stm32mp157a-avenger96.dtb \
> + stm32mp157a-icore-stm32mp1-ctouch2.dtb \
>   stm32mp157a-icore-stm32mp1-edimm2.2.dtb \
>   stm32mp157c-dk2.dtb \
>   stm32mp157c-ed1.dtb \
> diff --git a/arch/arm/dts/stm32mp157a-icore-stm32mp1-ctouch2-u-boot.dtsi 
> b/arch/arm/dts/stm32mp157a-icore-stm32mp1-ctouch2-u-boot.dtsi
> new file mode 100644
> index 00..96fe461235
> --- /dev/null
> +++ b/arch/arm/dts/stm32mp157a-icore-stm32mp1-ctouch2-u-boot.dtsi
> @@ -0,0 +1,51 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> +/*
> + * Copyright (C) STMicroelectronics 2019 - All Rights Reserved
> + * Copyright (c) 2020 Amarula Solutions(India)
> + * Author: Jagan Teki 
> + */
> +
> +#include "stm32mp157a-icore-stm32mp1-u-boot.dtsi"
> +
> +/{
> + aliases {
> + mmc0 = &sdmmc1;
> + };
> +
> + chosen {
> + stdout-path = &uart4;
> + };
> +};
> +
> +&sdmmc1 {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&sdmmc1_b4_pins_a {
> + u-boot,dm-pre-reloc;
> +
> + pins1 {
> + u-boot,dm-pre-reloc;
> + };
> +
> + pins2 {
> + u-boot,dm-pre-reloc;
> + };
> +};
> +
> +&uart4 {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&uart4_pins_a {
> + u-boot,dm-pre-reloc;
> +
> + pins1 {
> + u-boot,dm-pre-reloc;
> + };
> +
> + pins2 {
> + u-boot,dm-pre-reloc;
> + bias-pull-up;
> + };
> +};
> diff --git a/arch/arm/dts/stm32mp157a-icore-stm32mp1-ctouch2.dts 
> b/arch/arm/dts/stm32mp157a-icore-stm32mp1-ctouch2.dts
> new file mode 100644
> index 00..d3058a036c
> --- /dev/null
> +++ b/arch/arm/dts/stm32mp157a-icore-stm32mp1-ctouch2.dts
> @@ -0,0 +1,47 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> +/*
> + * Copyright (c) STMicroelectronics 2019 - All Rights Reserved
> + * Copyright (c) 2020 Engicam srl
> + * Copyright (c) 2020 Amarula Solutons(India)
> + */
> +
> +/dts-v1/;
> +#include "stm32mp157.dtsi"
> +#include "stm32mp157a-icore-stm32mp1.dtsi"
> +#include "stm32mp15-pinctrl.dtsi"
> +#include "stm32mp15xxaa-pinctrl.dtsi"
> +#include 
> +
> +/ {
> + model = "Engicam i.Core STM32MP1 C.TOUCH 2.0";
> + compatible = "engicam,icore-stm32mp1-ctouch2",
> +  "engicam,icore-stm32mp1", "st,stm32mp157";
> +
> + aliases {
> + serial0 = &uart4;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&sdmmc1 {
> + bus-width = <4>;
> + disable-wp;
> + pinctrl-names = "default", "opendrain", "sleep";
> + pinctrl-0 = <&sdmmc1_b4_pins_a>;
> + pinctrl-1 = <&sdmmc1_b4_od_pins_a>;
> + pinctrl-2 = <&sdmmc1_b4_sleep_pins_a>;
> + st,neg-edge;
> + vmmc-supply = <&v3v3>;
> + status = "okay";
> +};
> +
> +&uart4 {
> + pinctrl-names = "default", "sleep", "idle";
> + pinctrl-0 = <&uart4_pins_a>;
> + pinctrl-1 = <&uart4_sleep_pins_a>;
> + pinctrl-2 = <&uart4_idle_pins_a>;
> + status = "okay";
> +};
> diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
> index 5a2123063a..15c832b16b 100644
> --- a/arch/arm/mach-stm32mp/Kconfig
> +++ b/arch/arm/mach-stm32mp/Kconfig
> @@ -96,6 +96,11 @@ config TARGET_ICORE_STM32MP1
> * i.Core STM32MP1 needs to mount on top of EDIMM2.2 for
>   creating complete i.Core STM32MP1 EDIMM2.2 Starter Kit.
>  
> +   i.Core STM32MP1 C.TOUCH 2.0
> +   * C.TOUCH 2.0 is a general purpose Carrier board.
> +   * i.Core STM32MP1 needs to mount on top of this Carrier boar

Re: [PATCH 6/9] ARM: dts: stm32: Add Engicam MicroGEA STM32MP1 Micro SoM

2021-03-09 Thread Patrice CHOTARD
Hi Jagan

On 2/28/21 4:52 PM, Jagan Teki wrote:
> MicroGEA STM32MP1 is a STM32MP157A based Micro SoM.
> 
> General features:
> - STM32MP157AAC
> - Up to 1GB DDR3L-800
> - 512MB Nand flash
> - I2S
> 
> MicroGEA STM32MP1 needs to mount on top of Engicam MicroDev carrier
> boards for creating complete platform solutions.
> 
> Add support for it.
> 
> Signed-off-by: Jagan Teki 
> ---
>  .../dts/stm32mp157a-microgea-stm32mp1.dtsi| 148 ++
>  1 file changed, 148 insertions(+)
>  create mode 100644 arch/arm/dts/stm32mp157a-microgea-stm32mp1.dtsi
> 
> diff --git a/arch/arm/dts/stm32mp157a-microgea-stm32mp1.dtsi 
> b/arch/arm/dts/stm32mp157a-microgea-stm32mp1.dtsi
> new file mode 100644
> index 00..0b85175f15
> --- /dev/null
> +++ b/arch/arm/dts/stm32mp157a-microgea-stm32mp1.dtsi
> @@ -0,0 +1,148 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> +/*
> + * Copyright (c) STMicroelectronics 2019 - All Rights Reserved
> + * Copyright (c) 2020 Engicam srl
> + * Copyright (c) 2020 Amarula Solutons(India)
> + */
> +
> +/ {
> + compatible = "engicam,microgea-stm32mp1", "st,stm32mp157";
> +
> + memory@c000 {
> + device_type = "memory";
> + reg = <0xc000 0x1000>;
> + };
> +
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + mcuram2: mcuram2@1000 {
> + compatible = "shared-dma-pool";
> + reg = <0x1000 0x4>;
> + no-map;
> + };
> +
> + vdev0vring0: vdev0vring0@1004 {
> + compatible = "shared-dma-pool";
> + reg = <0x1004 0x1000>;
> + no-map;
> + };
> +
> + vdev0vring1: vdev0vring1@10041000 {
> + compatible = "shared-dma-pool";
> + reg = <0x10041000 0x1000>;
> + no-map;
> + };
> +
> + vdev0buffer: vdev0buffer@10042000 {
> + compatible = "shared-dma-pool";
> + reg = <0x10042000 0x4000>;
> + no-map;
> + };
> +
> + mcuram: mcuram@3000 {
> + compatible = "shared-dma-pool";
> + reg = <0x3000 0x4>;
> + no-map;
> + };
> +
> + retram: retram@3800 {
> + compatible = "shared-dma-pool";
> + reg = <0x3800 0x1>;
> + no-map;
> + };
> + };
> +
> + vin: regulator-vin {
> + compatible = "regulator-fixed";
> + regulator-name = "vin";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + regulator-always-on;
> + };
> +
> + vddcore: regulator-vddcore {
> + compatible = "regulator-fixed";
> + regulator-name = "vddcore";
> + regulator-min-microvolt = <120>;
> + regulator-max-microvolt = <120>;
> + regulator-always-on;
> + vin-supply = <&vin>;
> + };
> +
> + vdd: regulator-vdd {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + vin-supply = <&vin>;
> + };
> +
> + vddq_ddr: regulator-vddq-ddr {
> + compatible = "regulator-fixed";
> + regulator-name = "vddq_ddr";
> + regulator-min-microvolt = <135>;
> + regulator-max-microvolt = <135>;
> + regulator-always-on;
> + vin-supply = <&vin>;
> + };
> +};
> +
> +&dts {
> + status = "okay";
> +};
> +
> +&fmc {
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&fmc_pins_a>;
> + pinctrl-1 = <&fmc_sleep_pins_a>;
> + status = "okay";
> +
> + nand-controller@4,0 {
> + status = "okay";
> +
> + nand@0 {
> + reg = <0>;
> + nand-on-flash-bbt;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + };
> + };
> +};
> +
> +&ipcc {
> + status = "okay";
> +};
> +
> +&iwdg2{
> + timeout-sec = <32>;
> + status = "okay";
> +};
> +
> +&m4_rproc{
> + memory-region = <&retram>, <&mcuram>, <&mcuram2>, <&vdev0vring0>,
> + <&vdev0vring1>, <&vdev0buffer>;
> + mboxes = <&ipcc 0>, <&ipcc 1>, <&ipcc 2>;
> + mbox-names = "vq0", "vq1", "shutdown";
> + interrupt-parent = <&exti>;
> + interrupts = <68 1>;
> + status = "okay";
> +};
> +
> +&rng1 {
> + status = "okay";
> +};
> +
> +&rtc{
> + status = "okay";
> +};
> +
> +&vrefbuf {
> + regulator-min-microv

Re: [PATCH 7/9] ARM: dts: stm32: Add Engicam MicroGEA STM32MP1 1X4Gb DDR3

2021-03-09 Thread Patrice CHOTARD
Hi Jagan

On 2/28/21 4:52 PM, Jagan Teki wrote:
> Engicam MicroGEA STM32MP1 Micro SOM has mounted 1x4Gb DDR3
> which has 16bits width 533Mhz frequency.
> 
> Add DDR configurations via dtsi.
> 
> Signed-off-by: Jagan Teki 
> ---
>  ...m32mp15-ddr3-microgea-1x4Gb-1066-binG.dtsi | 121 ++
>  1 file changed, 121 insertions(+)
>  create mode 100644 arch/arm/dts/stm32mp15-ddr3-microgea-1x4Gb-1066-binG.dtsi
> 
> diff --git a/arch/arm/dts/stm32mp15-ddr3-microgea-1x4Gb-1066-binG.dtsi 
> b/arch/arm/dts/stm32mp15-ddr3-microgea-1x4Gb-1066-binG.dtsi
> new file mode 100644
> index 00..950f292abb
> --- /dev/null
> +++ b/arch/arm/dts/stm32mp15-ddr3-microgea-1x4Gb-1066-binG.dtsi
> @@ -0,0 +1,121 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> +/*
> + * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
> + *
> + * STM32MP157C DK1/DK2 BOARD configuration
> + * 1x DDR3L 4Gb, 16-bit, 533MHz.
> + * Reference used NT5CC256M16DP-DI from NANYA
> + *
> + * DDR type / Platform   DDR3/3L
> + * freq  533MHz
> + * width 16
> + * datasheet 0  = MT41J256M16-187 / DDR3-1066 bin G
> + * DDR density   4
> + * timing mode   optimized
> + * Scheduling/QoS options : type = 2
> + * address mapping : RBC
> + * Tc > + 85C : N
> + */
> +#define DDR_MEM_COMPATIBLE ddr3-microgea-1066-888-bin-g-1x4gb-533mhz
> +#define DDR_MEM_NAME "DDR3-1066/888 bin G 1x4Gb 533MHz v1.45"
> +#define DDR_MEM_SPEED 533000
> +#define DDR_MEM_SIZE 0x2000
> +
> +#define DDR_MSTR 0x00041401
> +#define DDR_MRCTRL0 0x0010
> +#define DDR_MRCTRL1 0x
> +#define DDR_DERATEEN 0x
> +#define DDR_DERATEINT 0x0080
> +#define DDR_PWRCTL 0x
> +#define DDR_PWRTMG 0x00400010
> +#define DDR_HWLPCTL 0x
> +#define DDR_RFSHCTL0 0x0021
> +#define DDR_RFSHCTL3 0x
> +#define DDR_RFSHTMG 0x0081008B
> +#define DDR_CRCPARCTL0 0x
> +#define DDR_DRAMTMG0 0x121B2414
> +#define DDR_DRAMTMG1 0x000A041C
> +#define DDR_DRAMTMG2 0x0608090F
> +#define DDR_DRAMTMG3 0x0050400C
> +#define DDR_DRAMTMG4 0x08040608
> +#define DDR_DRAMTMG5 0x06060403
> +#define DDR_DRAMTMG6 0x02020002
> +#define DDR_DRAMTMG7 0x0202
> +#define DDR_DRAMTMG8 0x1005
> +#define DDR_DRAMTMG14 0x00A0
> +#define DDR_ZQCTL0 0xC240
> +#define DDR_DFITMG0 0x02060105
> +#define DDR_DFITMG1 0x0202
> +#define DDR_DFILPCFG0 0x0700
> +#define DDR_DFIUPD0 0xC043
> +#define DDR_DFIUPD1 0x
> +#define DDR_DFIUPD2 0x
> +#define DDR_DFIPHYMSTR 0x
> +#define DDR_ADDRMAP1 0x00070707
> +#define DDR_ADDRMAP2 0x
> +#define DDR_ADDRMAP3 0x1F00
> +#define DDR_ADDRMAP4 0x1F1F
> +#define DDR_ADDRMAP5 0x06060606
> +#define DDR_ADDRMAP6 0x0F060606
> +#define DDR_ADDRMAP9 0x
> +#define DDR_ADDRMAP10 0x
> +#define DDR_ADDRMAP11 0x
> +#define DDR_ODTCFG 0x06000600
> +#define DDR_ODTMAP 0x0001
> +#define DDR_SCHED 0x0C01
> +#define DDR_SCHED1 0x
> +#define DDR_PERFHPR1 0x0101
> +#define DDR_PERFLPR1 0x08000200
> +#define DDR_PERFWR1 0x08000400
> +#define DDR_DBG0 0x
> +#define DDR_DBG1 0x
> +#define DDR_DBGCMD 0x
> +#define DDR_POISONCFG 0x
> +#define DDR_PCCFG 0x0010
> +#define DDR_PCFGR_0 0x0001
> +#define DDR_PCFGW_0 0x
> +#define DDR_PCFGQOS0_0 0x02100C03
> +#define DDR_PCFGQOS1_0 0x00800100
> +#define DDR_PCFGWQOS0_0 0x01100C03
> +#define DDR_PCFGWQOS1_0 0x01000200
> +#define DDR_PCFGR_1 0x0001
> +#define DDR_PCFGW_1 0x
> +#define DDR_PCFGQOS0_1 0x02100C03
> +#define DDR_PCFGQOS1_1 0x00800040
> +#define DDR_PCFGWQOS0_1 0x01100C03
> +#define DDR_PCFGWQOS1_1 0x01000200
> +#define DDR_PGCR 0x01442E02
> +#define DDR_PTR0 0x0022AA5B
> +#define DDR_PTR1 0x04841104
> +#define DDR_PTR2 0x042DA068
> +#define DDR_ACIOCR 0x10400812
> +#define DDR_DXCCR 0x0C40
> +#define DDR_DSGCR 0xF200011F
> +#define DDR_DCR 0x000B
> +#define DDR_DTPR0 0x38D488D0
> +#define DDR_DTPR1 0x098B00D8
> +#define DDR_DTPR2 0x10023600
> +#define DDR_MR0 0x0840
> +#define DDR_MR1 0x
> +#define DDR_MR2 0x0208
> +#define DDR_MR3 0x
> +#define DDR_ODTCR 0x0001
> +#define DDR_ZQ0CR1 0x0038
> +#define DDR_DX0GCR 0xCE81
> +#define DDR_DX0DLLCR 0x4000
> +#define DDR_DX0DQTR 0x
> +#define DDR_DX0DQSTR 0x3DB02000
> +#define DDR_DX1GCR 0xCE81
> +#define DDR_DX1DLLCR 0x4000
> +#define DDR_DX1DQTR 0x
> +#define DDR_DX1DQSTR 0x3DB02000
> +#define DDR_DX2GCR 0xCE80
> +#define DDR_DX2DLLCR 0x4000
> +#define DDR_DX2DQTR 0x
> +#define DDR_DX2DQSTR 0x3DB02000
> +#define DDR_DX3GCR 0xCE80
> +#define DDR_DX3DLLCR 0x4000
> +#define DDR_DX3DQTR 0x
> +#define DDR_DX3DQSTR 0x3DB02000
> +
> +#include "stm32mp15-ddr.dtsi"
> 
Reviewed-by: Patrice Chotard 

Thanks 

Patrice


Re: [PATCH 8/9] board: stm32: Add Engicam MicroGEA STM32MP1 MicroDev 2.0 board

2021-03-09 Thread Patrice CHOTARD
Hi Jagan

one minor remard below

On 2/28/21 4:52 PM, Jagan Teki wrote:
> MicroDev 2.0 is a general purpose miniature carrier board with CAN,
> LTE and LVDS panel interfaces.
> 
> Genaral features:
> - Ethernet 10/100
> - USB Type A
> - Audio Out
> - microSD
> - LVDS panel connector
> - Wifi/BT (option)
> - UMTS LTE with sim connector (option)
> 
> MicroGEA STM32MP1 is a STM32MP157A based Micro SoM.
> 
> MicroGEA STM32MP1 needs to mount on top of this MicroDev 2.0 board
> for creating complete MicroGEA STM32MP1 MicroDev 2.0 Carrier board.
> 
> Add support for it.
> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/Makefile |   1 +
>  ...-microgea-stm32mp1-microdev2.0-u-boot.dtsi |  51 
>  ...32mp157a-microgea-stm32mp1-microdev2.0.dts |  55 
>  .../stm32mp157a-microgea-stm32mp1-u-boot.dtsi | 118 ++
>  arch/arm/mach-stm32mp/Kconfig |  20 +++
>  board/engicam/stm32mp1/Kconfig|   2 +-
>  board/engicam/stm32mp1/MAINTAINERS|   6 +
>  ...mp15-microgea-stm32mp1-microdev2_defconfig |  80 
>  8 files changed, 332 insertions(+), 1 deletion(-)
>  create mode 100644 
> arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-u-boot.dtsi
>  create mode 100644 arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0.dts
>  create mode 100644 arch/arm/dts/stm32mp157a-microgea-stm32mp1-u-boot.dtsi
>  create mode 100644 configs/stm32mp15-microgea-stm32mp1-microdev2_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 7e0fae8cf0..7b275fe46c 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -979,6 +979,7 @@ dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb
>  dtb-$(CONFIG_STM32MP15x) += \
>   stm32mp157a-dk1.dtb \
>   stm32mp157a-avenger96.dtb \
> + stm32mp157a-microgea-stm32mp1-microdev2.0.dtb \

follow alphabetical order, should be located below 
stm32mp157a-icore-stm32mp1-edimm2.2.dtb

>   stm32mp157a-icore-stm32mp1-ctouch2.dtb \
>   stm32mp157a-icore-stm32mp1-edimm2.2.dtb \
>   stm32mp157c-dk2.dtb \
> diff --git 
> a/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-u-boot.dtsi 
> b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-u-boot.dtsi
> new file mode 100644
> index 00..e4bd215812
> --- /dev/null
> +++ b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-u-boot.dtsi
> @@ -0,0 +1,51 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> +/*
> + * Copyright (C) STMicroelectronics 2019 - All Rights Reserved
> + * Copyright (c) 2020 Amarula Solutions(India)
> + * Author: Jagan Teki 
> + */
> +
> +#include "stm32mp157a-microgea-stm32mp1-u-boot.dtsi"
> +
> +/{
> + aliases {
> + mmc0 = &sdmmc1;
> + };
> +
> + chosen {
> + stdout-path = &uart4;
> + };
> +};
> +
> +&sdmmc1 {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&sdmmc1_b4_pins_a {
> + u-boot,dm-pre-reloc;
> +
> + pins1 {
> + u-boot,dm-pre-reloc;
> + };
> +
> + pins2 {
> + u-boot,dm-pre-reloc;
> + };
> +};
> +
> +&uart4 {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&uart4_pins_a {
> + u-boot,dm-pre-reloc;
> +
> + pins1 {
> + u-boot,dm-pre-reloc;
> + };
> +
> + pins2 {
> + u-boot,dm-pre-reloc;
> + bias-pull-up;
> + };
> +};
> diff --git a/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0.dts 
> b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0.dts
> new file mode 100644
> index 00..7a75868164
> --- /dev/null
> +++ b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0.dts
> @@ -0,0 +1,55 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> +/*
> + * Copyright (c) STMicroelectronics 2019 - All Rights Reserved
> + * Copyright (c) 2020 Engicam srl
> + * Copyright (c) 2020 Amarula Solutons(India)
> + */
> +
> +/dts-v1/;
> +#include "stm32mp157.dtsi"
> +#include "stm32mp157a-microgea-stm32mp1.dtsi"
> +#include "stm32mp15-pinctrl.dtsi"
> +#include "stm32mp15xxaa-pinctrl.dtsi"
> +#include 
> +
> +/ {
> + model = "Engicam MicroGEA STM32MP1 MicroDev 2.0 Carrier Board";
> + compatible = "engicam,microgea-stm32mp1-microdev2.0",
> +  "engicam,microgea-stm32mp1", "st,stm32mp157";
> +
> + aliases {
> + serial0 = &uart4;
> + serial1 = &uart8;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&sdmmc1 {
> + bus-width = <4>;
> + disable-wp;
> + pinctrl-names = "default", "opendrain", "sleep";
> + pinctrl-0 = <&sdmmc1_b4_pins_a>;
> + pinctrl-1 = <&sdmmc1_b4_od_pins_a>;
> + pinctrl-2 = <&sdmmc1_b4_sleep_pins_a>;
> + st,neg-edge;
> + vmmc-supply = <&vdd>;
> + status = "okay";
> +};
> +
> +&uart4 {
> + pinctrl-names = "default", "sleep", "idle";
> + pinctrl-0 = <&uart4_pins_a>;
> + pinctrl-1 = <&uart4_sleep_pins_a>;
> + pinctrl-2 = <&uart4_idle_pins_a>;
> + s

Re: [PATCH 9/9] board: stm32: Add Engicam MicroGEA STM32MP1 MicroDev 2.0 7" OF

2021-03-09 Thread Patrice CHOTARD
Hi Jagan

On 2/28/21 4:52 PM, Jagan Teki wrote:
> 7" OF is a capacitive touch 7" Open Frame panel solutions with
> - 7" AUO B101AW03 LVDS panel
> - EDT, FT5526 Touch
> 
> MicroGEA STM32MP1 is a STM32MP157A based Micro SoM.
> 
> MicroDev 2.0 is a general purpose miniature carrier board with CAN,
> LTE and LVDS panel interfaces.
> 
> MicroGEA STM32MP1 needs to mount on top of MicroDev 2.0 board with
> pluged 7" OF for creating complete MicroGEA STM32MP1 MicroDev 2.0
> 7" Open Frame Solution board.
> 
> Add support for it.
> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/Makefile |   1 +
>  ...rogea-stm32mp1-microdev2.0-of7-u-boot.dtsi |  51 ++
>  ...157a-microgea-stm32mp1-microdev2.0-of7.dts | 154 ++
>  arch/arm/mach-stm32mp/Kconfig |   7 +
>  board/engicam/stm32mp1/MAINTAINERS|   6 +
>  ...-microgea-stm32mp1-microdev2-of7_defconfig |  80 +
>  6 files changed, 299 insertions(+)
>  create mode 100644 
> arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7-u-boot.dtsi
>  create mode 100644 
> arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts
>  create mode 100644 
> configs/stm32mp15-microgea-stm32mp1-microdev2-of7_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 7b275fe46c..7a9a05310d 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -980,6 +980,7 @@ dtb-$(CONFIG_STM32MP15x) += \
>   stm32mp157a-dk1.dtb \
>   stm32mp157a-avenger96.dtb \
>   stm32mp157a-microgea-stm32mp1-microdev2.0.dtb \
> + stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dtb \
>   stm32mp157a-icore-stm32mp1-ctouch2.dtb \
>   stm32mp157a-icore-stm32mp1-edimm2.2.dtb \
>   stm32mp157c-dk2.dtb \
> diff --git 
> a/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7-u-boot.dtsi 
> b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7-u-boot.dtsi
> new file mode 100644
> index 00..e4bd215812
> --- /dev/null
> +++ b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7-u-boot.dtsi
> @@ -0,0 +1,51 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> +/*
> + * Copyright (C) STMicroelectronics 2019 - All Rights Reserved
> + * Copyright (c) 2020 Amarula Solutions(India)
> + * Author: Jagan Teki 
> + */
> +
> +#include "stm32mp157a-microgea-stm32mp1-u-boot.dtsi"
> +
> +/{
> + aliases {
> + mmc0 = &sdmmc1;
> + };
> +
> + chosen {
> + stdout-path = &uart4;
> + };
> +};
> +
> +&sdmmc1 {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&sdmmc1_b4_pins_a {
> + u-boot,dm-pre-reloc;
> +
> + pins1 {
> + u-boot,dm-pre-reloc;
> + };
> +
> + pins2 {
> + u-boot,dm-pre-reloc;
> + };
> +};
> +
> +&uart4 {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&uart4_pins_a {
> + u-boot,dm-pre-reloc;
> +
> + pins1 {
> + u-boot,dm-pre-reloc;
> + };
> +
> + pins2 {
> + u-boot,dm-pre-reloc;
> + bias-pull-up;
> + };
> +};
> diff --git a/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts 
> b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts
> new file mode 100644
> index 00..674b2d330d
> --- /dev/null
> +++ b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts
> @@ -0,0 +1,154 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> +/*
> + * Copyright (c) STMicroelectronics 2019 - All Rights Reserved
> + * Copyright (c) 2020 Engicam srl
> + * Copyright (c) 2020 Amarula Solutons(India)
> + */
> +
> +/dts-v1/;
> +#include "stm32mp157.dtsi"
> +#include "stm32mp157a-microgea-stm32mp1.dtsi"
> +#include "stm32mp15-pinctrl.dtsi"
> +#include "stm32mp15xxaa-pinctrl.dtsi"
> +#include 
> +
> +/ {
> + model = "Engicam MicroGEA STM32MP1 MicroDev 2.0 7\" Open Frame";
> + compatible = "engicam,microgea-stm32mp1-microdev2.0-of7",
> +  "engicam,microgea-stm32mp1", "st,stm32mp157";
> +
> + aliases {
> + serial0 = &uart4;
> + serial1 = &uart8;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + backlight: backlight {
> + compatible = "gpio-backlight";
> + gpios = <&gpiod 13 GPIO_ACTIVE_HIGH>;
> + default-on;
> + };
> +
> + lcd_3v3: regulator-lcd-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd_3v3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = <&gpiof 10 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + regulator-always-on;
> + power-supply = <&panel_pwr>;
> + };
> +
> + panel_pwr: regulator-panel-pwr {
> + compatible = "regulator-fixed";
> + regulator-name = "panel_pwr";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <33000

Re: [PATCH 9/9] board: stm32: Add Engicam MicroGEA STM32MP1 MicroDev 2.0 7" OF

2021-03-09 Thread Patrice CHOTARD
Hi Jagan

On 2/28/21 4:52 PM, Jagan Teki wrote:
> 7" OF is a capacitive touch 7" Open Frame panel solutions with
> - 7" AUO B101AW03 LVDS panel
> - EDT, FT5526 Touch
> 
> MicroGEA STM32MP1 is a STM32MP157A based Micro SoM.
> 
> MicroDev 2.0 is a general purpose miniature carrier board with CAN,
> LTE and LVDS panel interfaces.
> 
> MicroGEA STM32MP1 needs to mount on top of MicroDev 2.0 board with
> pluged 7" OF for creating complete MicroGEA STM32MP1 MicroDev 2.0
> 7" Open Frame Solution board.
> 
> Add support for it.
> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/Makefile |   1 +
>  ...rogea-stm32mp1-microdev2.0-of7-u-boot.dtsi |  51 ++
>  ...157a-microgea-stm32mp1-microdev2.0-of7.dts | 154 ++
>  arch/arm/mach-stm32mp/Kconfig |   7 +
>  board/engicam/stm32mp1/MAINTAINERS|   6 +
>  ...-microgea-stm32mp1-microdev2-of7_defconfig |  80 +
>  6 files changed, 299 insertions(+)
>  create mode 100644 
> arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7-u-boot.dtsi
>  create mode 100644 
> arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts
>  create mode 100644 
> configs/stm32mp15-microgea-stm32mp1-microdev2-of7_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 7b275fe46c..7a9a05310d 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -980,6 +980,7 @@ dtb-$(CONFIG_STM32MP15x) += \
>   stm32mp157a-dk1.dtb \
>   stm32mp157a-avenger96.dtb \
>   stm32mp157a-microgea-stm32mp1-microdev2.0.dtb \
> + stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dtb \
>   stm32mp157a-icore-stm32mp1-ctouch2.dtb \
>   stm32mp157a-icore-stm32mp1-edimm2.2.dtb \
>   stm32mp157c-dk2.dtb \
> diff --git 
> a/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7-u-boot.dtsi 
> b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7-u-boot.dtsi
> new file mode 100644
> index 00..e4bd215812
> --- /dev/null
> +++ b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7-u-boot.dtsi
> @@ -0,0 +1,51 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> +/*
> + * Copyright (C) STMicroelectronics 2019 - All Rights Reserved
> + * Copyright (c) 2020 Amarula Solutions(India)
> + * Author: Jagan Teki 
> + */
> +
> +#include "stm32mp157a-microgea-stm32mp1-u-boot.dtsi"
> +
> +/{
> + aliases {
> + mmc0 = &sdmmc1;
> + };
> +
> + chosen {
> + stdout-path = &uart4;
> + };
> +};
> +
> +&sdmmc1 {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&sdmmc1_b4_pins_a {
> + u-boot,dm-pre-reloc;
> +
> + pins1 {
> + u-boot,dm-pre-reloc;
> + };
> +
> + pins2 {
> + u-boot,dm-pre-reloc;
> + };
> +};
> +
> +&uart4 {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&uart4_pins_a {
> + u-boot,dm-pre-reloc;
> +
> + pins1 {
> + u-boot,dm-pre-reloc;
> + };
> +
> + pins2 {
> + u-boot,dm-pre-reloc;
> + bias-pull-up;
> + };
> +};
> diff --git a/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts 
> b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts
> new file mode 100644
> index 00..674b2d330d
> --- /dev/null
> +++ b/arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts
> @@ -0,0 +1,154 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> +/*
> + * Copyright (c) STMicroelectronics 2019 - All Rights Reserved
> + * Copyright (c) 2020 Engicam srl
> + * Copyright (c) 2020 Amarula Solutons(India)
> + */
> +
> +/dts-v1/;
> +#include "stm32mp157.dtsi"
> +#include "stm32mp157a-microgea-stm32mp1.dtsi"
> +#include "stm32mp15-pinctrl.dtsi"
> +#include "stm32mp15xxaa-pinctrl.dtsi"
> +#include 
> +
> +/ {
> + model = "Engicam MicroGEA STM32MP1 MicroDev 2.0 7\" Open Frame";
> + compatible = "engicam,microgea-stm32mp1-microdev2.0-of7",
> +  "engicam,microgea-stm32mp1", "st,stm32mp157";
> +
> + aliases {
> + serial0 = &uart4;
> + serial1 = &uart8;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + backlight: backlight {
> + compatible = "gpio-backlight";
> + gpios = <&gpiod 13 GPIO_ACTIVE_HIGH>;
> + default-on;
> + };
> +
> + lcd_3v3: regulator-lcd-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd_3v3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = <&gpiof 10 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + regulator-always-on;
> + power-supply = <&panel_pwr>;
> + };
> +
> + panel_pwr: regulator-panel-pwr {
> + compatible = "regulator-fixed";
> + regulator-name = "panel_pwr";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <33000

Re: [PATCH] board: stm32mp1: use CONFIG_SYS_MMC_ENV_DEV when available

2021-03-09 Thread Patrice CHOTARD
Hi Patrick

On 3/1/21 1:17 PM, Patrick Delaunay wrote:
> Check whether user has explicitly defined the mmc device to use
> in mmc_get_env_dev() with CONFIG_SYS_MMC_ENV_DEV.
> 
> On STMicroelectronics boards the used mmc device for environment is
> the instance of boot device provided by the ROM code; the mmc instance
> is configured by alias in device tree. The used partition is defined in
> device tree with u-boot,mmc-env-partition = "ssbl".
> 
> This patch allows to override this selection for the support of customer
> boards without alias; for example when SDMMC1 is not used and ENV in
> mmc0=SDMMC2, user can force the value: CONFIG_SYS_MMC_ENV_DEV = 0.
> 
> On STMicroelectronics boards, the current behavior is kept with
> CONFIG_SYS_MMC_ENV_DEV = -1.
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  board/st/stm32mp1/stm32mp1.c| 8 +++-
>  configs/stm32mp15_basic_defconfig   | 1 +
>  configs/stm32mp15_trusted_defconfig | 1 +
>  3 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
> index ab85d8ba68..759181fb5d 100644
> --- a/board/st/stm32mp1/stm32mp1.c
> +++ b/board/st/stm32mp1/stm32mp1.c
> @@ -862,8 +862,14 @@ const char *env_ext4_get_dev_part(void)
>  
>  int mmc_get_env_dev(void)
>  {
> - u32 bootmode = get_bootmode();
> + u32 bootmode;
> +
> + if (CONFIG_SYS_MMC_ENV_DEV >= 0)
> + return CONFIG_SYS_MMC_ENV_DEV;
> +
> + bootmode = get_bootmode();
>  
> + /* use boot instance to select the correct mmc device identifier */
>   return (bootmode & TAMP_BOOT_INSTANCE_MASK) - 1;
>  }
>  
> diff --git a/configs/stm32mp15_basic_defconfig 
> b/configs/stm32mp15_basic_defconfig
> index 1c680984b8..a2f745099e 100644
> --- a/configs/stm32mp15_basic_defconfig
> +++ b/configs/stm32mp15_basic_defconfig
> @@ -71,6 +71,7 @@ CONFIG_ENV_UBI_PART="UBI"
>  CONFIG_ENV_UBI_VOLUME="uboot_config"
>  CONFIG_ENV_UBI_VOLUME_REDUND="uboot_config_r"
>  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_SYS_MMC_ENV_DEV=-1
>  # CONFIG_SPL_ENV_IS_NOWHERE is not set
>  # CONFIG_SPL_ENV_IS_IN_SPI_FLASH is not set
>  CONFIG_STM32_ADC=y
> diff --git a/configs/stm32mp15_trusted_defconfig 
> b/configs/stm32mp15_trusted_defconfig
> index 107041119f..f41aaa750f 100644
> --- a/configs/stm32mp15_trusted_defconfig
> +++ b/configs/stm32mp15_trusted_defconfig
> @@ -52,6 +52,7 @@ CONFIG_ENV_UBI_PART="UBI"
>  CONFIG_ENV_UBI_VOLUME="uboot_config"
>  CONFIG_ENV_UBI_VOLUME_REDUND="uboot_config_r"
>  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_SYS_MMC_ENV_DEV=-1
>  CONFIG_STM32_ADC=y
>  CONFIG_SET_DFU_ALT_INFO=y
>  CONFIG_USB_FUNCTION_FASTBOOT=y
> 

Reviewed-by: Patrice Chotard 
Thanks
Patrice


Re: [PATCH] video: stm32: remove all child of DSI bridge when its probe failed

2021-03-09 Thread Patrice CHOTARD
Hi Patrick

On 3/4/21 1:10 PM, Patrick Delaunay wrote:
> From: Patrick Delaunay 
> 
> Remove the child device of the STM32 DSI bridge when the driver probe
> failed to stop futher probe request on panels used with STMicroelectronics
> board (orisetech_otm8009a.c or raydium-rm68200.c driver).
> 
> This patch avoid the trace "cannot get reset GPIO" when
> STM32MP157 device tree is used on stm32MP151 SOC without DSI support.
> 
> In this hw_version value is 0, as DSI bridge is absent and the panel
> ofdata_to_platdata is called for each try of panel probe,
> the gpio reset pin is requested but after dsi father probe failed).
> 
> For the next request, the PANEL ofdata_to_platdata failed as the gpio
> is already used.
> 
> Signed-off-by: Patrick Delaunay 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  drivers/video/stm32/stm32_dsi.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/video/stm32/stm32_dsi.c b/drivers/video/stm32/stm32_dsi.c
> index 8891ca4b78..4027e978c8 100644
> --- a/drivers/video/stm32/stm32_dsi.c
> +++ b/drivers/video/stm32/stm32_dsi.c
> @@ -483,6 +483,9 @@ static int stm32_dsi_probe(struct udevice *dev)
>   if (priv->hw_version != HWVER_130 &&
>   priv->hw_version != HWVER_131) {
>   dev_err(dev, "DSI version 0x%x not supported\n", 
> priv->hw_version);
> + dev_dbg(dev, "remove and unbind all DSI child\n");
> + device_chld_remove(dev, NULL, DM_REMOVE_NORMAL);
> + device_chld_unbind(dev, NULL);
>   ret = -ENODEV;
>   goto err_clk;
>   }
> 
Reviewed-by: Patrice Chotard 
Thanks
Patrice


Re: [PATCH] configs: stm32mp15: move bootdelay configuration in defconfig

2021-03-09 Thread Patrice CHOTARD
Hi Patrick

On 3/1/21 7:40 PM, Patrick Delaunay wrote:
> The STM32MP15 boards have no reason to configure bootdelay in stm32mp1.h
> as it is already done with CONFIG_BOOTDELAY (default = 2) and in
> include/env_default.h.
> 
> This patch allows configuration for customers which reuse stm32mp1.h
> and reduce the size of the default environment.
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  configs/stm32mp15_basic_defconfig   | 1 +
>  configs/stm32mp15_dhcom_basic_defconfig | 1 +
>  configs/stm32mp15_dhcor_basic_defconfig | 1 +
>  configs/stm32mp15_trusted_defconfig | 1 +
>  include/configs/stm32mp1.h  | 1 -
>  5 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/configs/stm32mp15_basic_defconfig 
> b/configs/stm32mp15_basic_defconfig
> index 1c680984b8..0864d4f252 100644
> --- a/configs/stm32mp15_basic_defconfig
> +++ b/configs/stm32mp15_basic_defconfig
> @@ -20,6 +20,7 @@ CONFIG_SPL_SPI_SUPPORT=y
>  CONFIG_DEFAULT_DEVICE_TREE="stm32mp157c-ev1"
>  CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_FIT=y
> +CONFIG_BOOTDELAY=1
>  CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
>  CONFIG_SPL_LOG=y
>  CONFIG_BOARD_EARLY_INIT_F=y
> diff --git a/configs/stm32mp15_dhcom_basic_defconfig 
> b/configs/stm32mp15_dhcom_basic_defconfig
> index ed285e9161..e36d34d001 100644
> --- a/configs/stm32mp15_dhcom_basic_defconfig
> +++ b/configs/stm32mp15_dhcom_basic_defconfig
> @@ -19,6 +19,7 @@ CONFIG_FIT=y
>  CONFIG_SPL_LOAD_FIT=y
>  CONFIG_SPL_FIT_SOURCE="board/dhelectronics/dh_stm32mp1/u-boot-dhcom.its"
>  # CONFIG_USE_SPL_FIT_GENERATOR is not set
> +CONFIG_BOOTDELAY=1
>  CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
>  CONFIG_BOARD_EARLY_INIT_F=y
>  CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y
> diff --git a/configs/stm32mp15_dhcor_basic_defconfig 
> b/configs/stm32mp15_dhcor_basic_defconfig
> index a6620561ac..4794b1a14d 100644
> --- a/configs/stm32mp15_dhcor_basic_defconfig
> +++ b/configs/stm32mp15_dhcor_basic_defconfig
> @@ -17,6 +17,7 @@ CONFIG_FIT=y
>  CONFIG_SPL_LOAD_FIT=y
>  CONFIG_SPL_FIT_SOURCE="board/dhelectronics/dh_stm32mp1/u-boot-dhcor.its"
>  # CONFIG_USE_SPL_FIT_GENERATOR is not set
> +CONFIG_BOOTDELAY=1
>  CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
>  CONFIG_BOARD_EARLY_INIT_F=y
>  CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y
> diff --git a/configs/stm32mp15_trusted_defconfig 
> b/configs/stm32mp15_trusted_defconfig
> index 107041119f..4becdbb238 100644
> --- a/configs/stm32mp15_trusted_defconfig
> +++ b/configs/stm32mp15_trusted_defconfig
> @@ -13,6 +13,7 @@ CONFIG_ENV_OFFSET_REDUND=0x2C
>  CONFIG_DEFAULT_DEVICE_TREE="stm32mp157c-ev1"
>  CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_FIT=y
> +CONFIG_BOOTDELAY=1
>  CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
>  CONFIG_SYS_PROMPT="STM32MP> "
>  CONFIG_CMD_ADTIMG=y
> diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
> index 36e400453e..db2117a3d7 100644
> --- a/include/configs/stm32mp1.h
> +++ b/include/configs/stm32mp1.h
> @@ -160,7 +160,6 @@
>   * and the ramdisk at the end.
>   */
>  #define CONFIG_EXTRA_ENV_SETTINGS \
> - "bootdelay=1\0" \
>   "kernel_addr_r=0xc200\0" \
>   "fdt_addr_r=0xc400\0" \
>   "scriptaddr=0xc410\0" \
> 

Reviewed-by: Patrice Chotard 
Thanks
Patrice


Re: [Uboot-stm32] [PATCH 1/2] video: dw_mipi_dsi: missing device to log debug

2021-03-09 Thread Patrice CHOTARD
Hi Patrick

On 3/4/21 1:14 PM, Patrick Delaunay wrote:
> From: Yannick Fertre 
> 
> Missing udevice to struct dw_mipi_dsi to log trace.
> 
> Signed-off-by: Yannick Fertre 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  drivers/video/dw_mipi_dsi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/video/dw_mipi_dsi.c b/drivers/video/dw_mipi_dsi.c
> index 4dde648814..a5beed3514 100644
> --- a/drivers/video/dw_mipi_dsi.c
> +++ b/drivers/video/dw_mipi_dsi.c
> @@ -797,6 +797,7 @@ static int dw_mipi_dsi_init(struct udevice *dev,
>   dsi->phy_ops = phy_ops;
>   dsi->max_data_lanes = max_data_lanes;
>   dsi->device = device;
> + dsi->dsi_host.dev = (struct device *)dev;
>   dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
>   device->host = &dsi->dsi_host;
>  
> 
Reviewed-by: Patrice Chotard 
Thanks
Patrice


Re: [Uboot-stm32] [PATCH 2/2] video: dw_mipi_dsi: update log of dphy_enable

2021-03-09 Thread Patrice CHOTARD
HI Patrick

On 3/4/21 1:14 PM, Patrick Delaunay wrote:
> From: Yannick Fertre 
> 
> The DSI phy can be turned on from the DSI digital interface in
> the dphy_enable() function or from a dedicated DSI phy "wrapper"
> in phy_ops->init() function. If the STM32MP1 case, the wrapper
> is used then the dphy_enable() "warning" traces are not relevant.
> 
> This patch moves these "warning" traces to "debug" traces so
> they are still available for DSI phy based on the digital
> interface in debug logging mode, but not there in normal mode
> for both cases.
> Note: The related Linux kernel driver uses a "debug"
> message too.
> 
> Signed-off-by: Yannick Fertre 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  drivers/video/dw_mipi_dsi.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/video/dw_mipi_dsi.c b/drivers/video/dw_mipi_dsi.c
> index a5beed3514..9ae09eec12 100644
> --- a/drivers/video/dw_mipi_dsi.c
> +++ b/drivers/video/dw_mipi_dsi.c
> @@ -721,15 +721,15 @@ static void dw_mipi_dsi_dphy_enable(struct dw_mipi_dsi 
> *dsi)
>   ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS, val,
>val & PHY_LOCK, PHY_STATUS_TIMEOUT_US);
>   if (ret)
> - dev_warn(dsi->dsi_host.dev,
> -  "failed to wait phy lock state\n");
> + dev_dbg(dsi->dsi_host.dev,
> + "failed to wait phy lock state\n");
>  
>   ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS,
>val, val & PHY_STOP_STATE_CLK_LANE,
>PHY_STATUS_TIMEOUT_US);
>   if (ret)
> - dev_warn(dsi->dsi_host.dev,
> -  "failed to wait phy clk lane stop state\n");
> + dev_dbg(dsi->dsi_host.dev,
> + "failed to wait phy clk lane stop state\n");
>  }
>  
>  static void dw_mipi_dsi_clear_err(struct dw_mipi_dsi *dsi)
> 

Reviewed-by: Patrice Chotard 
Thanks
Patrice


Re: [PATCH] arm: stm32mp1: Set soc_type, soc_pkg, soc_rev env variables

2021-03-09 Thread Patrice CHOTARD
Hi Marek

On 3/5/21 3:18 PM, Marek Vasut wrote:
> Split up get_soc_name(), clean the decoding up a bit, and set up
> environment variables which contain the SoC type, package, revision.
> This is useful on SoMs, where multiple SoC options are populated.
> 
> Signed-off-by: Marek Vasut 
> Cc: Patrick Delaunay 
> Cc: Patrice Chotard 
> ---
>  arch/arm/mach-stm32mp/cpu.c | 105 ++--
>  1 file changed, 53 insertions(+), 52 deletions(-)
> 
> diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
> index 3faa4ec18a4..887db9b5b0c 100644
> --- a/arch/arm/mach-stm32mp/cpu.c
> +++ b/arch/arm/mach-stm32mp/cpu.c
> @@ -349,89 +349,78 @@ u32 get_cpu_package(void)
>   return get_otp(BSEC_OTP_PKG, PKG_SHIFT, PKG_MASK);
>  }
>  
> -void get_soc_name(char name[SOC_NAME_SIZE])
> +static const char * const soc_type[] = {
> + "",
> + "151C", "151A", "151F", "151D",
> + "153C", "153A", "153F", "153D",
> + "157C", "157A", "157F", "157D"
> +};
> +
> +static const char * const soc_pkg[] = { "??", "AD", "AC", "AB", "AA" };
> +static const char * const soc_rev[] = { "?", "A", "B", "Z" };
> +
> +static void get_cpu_string_offsets(unsigned int *type, unsigned int *pkg,
> +unsigned int *rev)
>  {
> - char *cpu_s, *cpu_r, *pkg;
> + u32 cpu_type = get_cpu_type();
> + u32 ct = cpu_type & ~(BIT(7) | BIT(0));
> + u32 cm = ((cpu_type & BIT(7)) >> 6) | (cpu_type & BIT(0));
> + u32 cp = get_cpu_package();
>  
> - /* MPUs Part Numbers */
> - switch (get_cpu_type()) {
> - case CPU_STM32MP157Fxx:
> - cpu_s = "157F";
> - break;
> - case CPU_STM32MP157Dxx:
> - cpu_s = "157D";
> - break;
> - case CPU_STM32MP157Cxx:
> - cpu_s = "157C";
> - break;
> - case CPU_STM32MP157Axx:
> - cpu_s = "157A";
> - break;
> - case CPU_STM32MP153Fxx:
> - cpu_s = "153F";
> - break;
> - case CPU_STM32MP153Dxx:
> - cpu_s = "153D";
> + /* Bits 0 and 7 are the ACDF, 00:C 01:A 10:F 11:D */
> + switch (ct) {
> + case CPU_STM32MP151Cxx:
> + *type = cm + 1;
>   break;
>   case CPU_STM32MP153Cxx:
> - cpu_s = "153C";
> - break;
> - case CPU_STM32MP153Axx:
> - cpu_s = "153A";
> - break;
> - case CPU_STM32MP151Fxx:
> - cpu_s = "151F";
> - break;
> - case CPU_STM32MP151Dxx:
> - cpu_s = "151D";
> + *type = cm + 5;
>   break;
> - case CPU_STM32MP151Cxx:
> - cpu_s = "151C";
> - break;
> - case CPU_STM32MP151Axx:
> - cpu_s = "151A";
> + case CPU_STM32MP157Cxx:
> + *type = cm + 9;
>   break;
>   default:
> - cpu_s = "";
> + *type = 0;
>   break;
>   }
>  
>   /* Package */
> - switch (get_cpu_package()) {
> + switch (cp) {
>   case PKG_AA_LBGA448:
> - pkg = "AA";
> - break;
>   case PKG_AB_LBGA354:
> - pkg = "AB";
> - break;
>   case PKG_AC_TFBGA361:
> - pkg = "AC";
> - break;
>   case PKG_AD_TFBGA257:
> - pkg = "AD";
> + *pkg = cp;
>   break;
>   default:
> - pkg = "??";
> + pkg = 0;
>   break;
>   }
>  
> - /* REVISION */
> + /* Revision */
>   switch (get_cpu_rev()) {
>   case CPU_REVA:
> - cpu_r = "A";
> + *rev = 1;
>   break;
>   case CPU_REVB:
> - cpu_r = "B";
> + *rev = 2;
>   break;
>   case CPU_REVZ:
> - cpu_r = "Z";
> + *rev = 3;
>   break;
>   default:
> - cpu_r = "?";
> + *rev = 0;
>   break;
>   }
> +}
> +
> +void get_soc_name(char name[SOC_NAME_SIZE])
> +{
> + unsigned int type, pkg, rev;
>  
> - snprintf(name, SOC_NAME_SIZE, "STM32MP%s%s Rev.%s", cpu_s, pkg, cpu_r);
> + get_cpu_string_offsets(&type, &pkg, &rev);
> +
> + snprintf(name, SOC_NAME_SIZE, "STM32MP%s%s Rev.%s",
> +  soc_type[type], soc_pkg[pkg], soc_rev[rev]);
>  }
>  
>  #if defined(CONFIG_DISPLAY_CPUINFO)
> @@ -620,11 +609,23 @@ static int setup_serial_number(void)
>   return 0;
>  }
>  
> +static void setup_soc_type_pkg_rev(void)
> +{
> + unsigned int type, pkg, rev;
> +
> + get_cpu_string_offsets(&type, &pkg, &rev);
> +
> + env_set("soc_type", soc_type[type]);
> + env_set("soc_pkg", soc_pkg[pkg]);
> + env_set("soc_rev", soc_rev[rev]);
> +}
> +
>  int arch_misc_init(void)
>  {
>   setup_boot_mode();
>   setup_mac_address();
>   setup_serial_number();
> + setup_soc_type_pkg_rev();
>  
>   return 0;
>  }
> 

Reviewed-by: Patrice Chotard

Re: [PATCH] doc: stm32mp1: Use u-boot.itb if CONFIG_SPL_LOAD_FIT=y

2021-03-09 Thread Patrice CHOTARD
Hi Marek

On 3/6/21 9:44 PM, Marek Vasut wrote:
> For systems where SPL loads fitImage, i.e. CONFIG_SPL_LOAD_FIT=y, use
> u-boot.itb in the relevant documentation parts. Otherwise use u-boot.img.
> 
> Signed-off-by: Marek Vasut 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> ---
>  doc/board/st/stm32mp1.rst | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/doc/board/st/stm32mp1.rst b/doc/board/st/stm32mp1.rst
> index 20f5c9e301e..f0c2b09b988 100644
> --- a/doc/board/st/stm32mp1.rst
> +++ b/doc/board/st/stm32mp1.rst
> @@ -237,7 +237,8 @@ Build Procedure
>- For Basic boot
>  
>   - FSBL = spl/u-boot-spl.stm32
> - - SSBL = u-boot.img
> + - SSBL = u-boot.img (without CONFIG_SPL_LOAD_FIT) or
> +  u-boot.itb (with CONFIG_SPL_LOAD_FIT=y)
>  
>  Switch Setting for Boot Mode
>  
> @@ -347,7 +348,9 @@ c) copy the FSBL (2 times) and SSBL file on the correct 
> partition.
>  
>  # dd if=u-boot-spl.stm32 of=/dev/mmcblk0p1
>  # dd if=u-boot-spl.stm32 of=/dev/mmcblk0p2
> -# dd if=u-boot.img of=/dev/mmcblk0p3
> +# dd if=u-boot.img of=/dev/mmcblk0p3 # Without CONFIG_SPL_LOAD_FIT
> +  OR
> +  dd if=u-boot.itb of=/dev/mmcblk0p3 # With CONFIG_SPL_LOAD_FIT=y
>  
> for trusted boot mode: ::
>  
> @@ -363,8 +366,9 @@ Prepare eMMC
>  You can use U-Boot to copy binary in eMMC.
>  
>  In the next example, you need to boot from SD card and the images
> -(u-boot-spl.stm32, u-boot.img) are presents on SD card (mmc 0)
> -in ext4 partition 4 (bootfs).
> +(u-boot-spl.stm32, u-boot.img for systems without CONFIG_SPL_LOAD_FIT
> +or u-boot.itb for systems with CONFIG_SPL_LOAD_FIT=y) are presents on
> +SD card (mmc 0) in ext4 partition 4 (bootfs).
>  
>  To boot from SD card, select BootPinMode = 1 0 1 and reset.
>  
> @@ -387,7 +391,9 @@ b) copy SPL on eMMC on firts boot partition
>  
>  c) copy U-Boot in first GPT partition of eMMC::
>  
> -# ext4load mmc 0:4 0xC000 u-boo  t.img
> +# ext4load mmc 0:4 0xC000 u-boot.img # Without CONFIG_SPL_LOAD_FIT
> +  OR
> +  ext4load mmc 0:4 0xC000 u-boot.itb # With CONFIG_SPL_LOAD_FIT=y
>  # mmc dev 1
>  # part start mmc 1 1 partstart
>  # mmc write ${fileaddr} ${partstart} ${filesize}
> 

Reviewed-by: Patrice Chotard 
Thanks
Patrice


Re: [PATCH u-boot 18/39] build: LTO: move platform libs into --start-group list

2021-03-09 Thread Bin Meng
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún  wrote:
>
> When building with LTO, move $(PLATFORM_LIBS) into the --start-group /
> --end-group list.

This should be --whole-archive

> Otherwise some functions declared in assembly may not be resolved and
> linking may fail.

I am not sure if this is caused by we build these lib functions with -flto?

>
> Signed-off-by: Marek Behún 
> ---
>  Makefile | 3 ++-
>  scripts/Makefile.spl | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
>

Regards,
Bin


Re: [PATCH u-boot 19/39] sandbox: errno: avoid conflict with libc's errno

2021-03-09 Thread Bin Meng
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún  wrote:
>
> When building with LTO, the system libc's `errno` variable used in
> arch/sandbox/cpu/os.c conflicts with U-Boot's `errno` (defined in
> lib/errno.c) with the following error:
>  .../ld: errno@@GLIBC_PRIVATE: TLS definition in /lib64/libc.so.6
>  section .tbss mismatches non-TLS reference in
>  /tmp/u-boot.EQlEXz.ltrans0.ltrans.o
>
> To avoid this conflict use different asm label for this variable when
> CONFIG_SANDBOX is enabled.
>
> Signed-off-by: Marek Behún 
> ---
>  include/errno.h | 8 +++-
>  lib/errno.c | 4 +++-
>  2 files changed, 10 insertions(+), 2 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH] rtc: add support for rv3028 rtc

2021-03-09 Thread Stefan Roese

Hi Heiko,

On 09.03.21 14:45, Heiko Schocher wrote:

add support for rtc3028 rtc from microcrystal.
based on linux dirver:
commit a38fd8748464: ("Linux 5.12-rc2")


Nitpicking: You might want to start a sentence in upper-case? ;)

Another minor comment below...


Signed-off-by: Heiko Schocher 

---
driver is based on code in linux, but with already
corrected weekday usage. linux codes the weekday
bitwise, while the weekday register has only 3 valid
bits as the app manual [1] says:

This register holds the current day of the week. Each value represents
one weekday that is assigned by the user. Values will range from 0 to 6
The weekday counter is simply a 3-bit counter which counts up to 6
and then resets to 0.

[1] 
https://www.microcrystal.com/fileadmin/Media/Products/RTC/App.Manual/RV-3028-C7_App-Manual.pdf

This is not a big problem, as userspace never use weekday.
Nevertheless, I will also send an update for the linux driver.

Also the nvram can be used for bootcounter purposes.

Tested this driver on "PHYTEC phyBOARD-Pollux i.MX8MP" board.

azure build:
https://dev.azure.com/hs0298/hs/_build/results?buildId=63&view=results

  drivers/rtc/Kconfig  |   6 ++
  drivers/rtc/Makefile |   1 +
  drivers/rtc/rv3028.c | 215 +++
  3 files changed, 222 insertions(+)
  create mode 100644 drivers/rtc/rv3028.c

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index aa6d90158c..e451308b40 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -95,6 +95,12 @@ config RTC_PCF8563
  If you say yes here you get support for the Philips PCF8563 RTC
  and compatible chips.
  
+config RTC_RV3028

+   bool "Enable RV3028 driver"
+   depends on DM_RTC
+   help
+ The MicroCrystal RV3028 is a I2C Real Time Clock (RTC)
+
  config RTC_RV3029
bool "Enable RV3029 driver"
depends on DM_RTC
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 6a45a9c874..e7acd76266 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_RTC_PCF2127) += pcf2127.o
  obj-$(CONFIG_RTC_PL031) += pl031.o
  obj-$(CONFIG_RTC_PT7C4338) += pt7c4338.o
  obj-$(CONFIG_RTC_RS5C372A) += rs5c372.o
+obj-$(CONFIG_RTC_RV3028) += rv3028.o
  obj-$(CONFIG_RTC_RV3029) += rv3029.o
  obj-$(CONFIG_RTC_RV8803) += rv8803.o
  obj-$(CONFIG_RTC_RX8025) += rx8025.o
diff --git a/drivers/rtc/rv3028.c b/drivers/rtc/rv3028.c
new file mode 100644
index 00..8d8336c5f1
--- /dev/null
+++ b/drivers/rtc/rv3028.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * RTC driver for the Micro Crystal RV3028
+ *
+ * based on linux driver from
+ * Copyright (C) 2019 Micro Crystal SA
+ *
+ * Alexandre Belloni 
+ *
+ */
+
+#include 


Please don't include "common.h" any more. It's deprecated.


+#include 


Do you really need "command.h" ...


+#include 
+#include 


... and this one? Please check and only inlude the necessary headers.

Other that that:

Reviewed-by: Stefan Roese 

Thanks,
Stefan


+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RV3028_SEC 0x00
+#define RV3028_MIN 0x01
+#define RV3028_HOUR0x02
+#define RV3028_WDAY0x03
+#define RV3028_DAY 0x04
+#define RV3028_MONTH   0x05
+#define RV3028_YEAR0x06
+#define RV3028_ALARM_MIN   0x07
+#define RV3028_ALARM_HOUR  0x08
+#define RV3028_ALARM_DAY   0x09
+#define RV3028_STATUS  0x0E
+#define RV3028_CTRL1   0x0F
+#define RV3028_CTRL2   0x10
+#define RV3028_EVT_CTRL0x13
+#define RV3028_TS_COUNT0x14
+#define RV3028_TS_SEC  0x15
+#define RV3028_RAM10x1F
+#define RV3028_EEPROM_ADDR 0x25
+#define RV3028_EEPROM_DATA 0x26
+#define RV3028_EEPROM_CMD  0x27
+#define RV3028_CLKOUT  0x35
+#define RV3028_OFFSET  0x36
+#define RV3028_BACKUP  0x37
+
+#define RV3028_STATUS_PORF BIT(0)
+#define RV3028_STATUS_EVF  BIT(1)
+#define RV3028_STATUS_AF   BIT(2)
+#define RV3028_STATUS_TF   BIT(3)
+#define RV3028_STATUS_UF   BIT(4)
+#define RV3028_STATUS_BSF  BIT(5)
+#define RV3028_STATUS_CLKF BIT(6)
+#define RV3028_STATUS_EEBUSY   BIT(7)
+
+#define RV3028_CLKOUT_FD_MASK  GENMASK(2, 0)
+#define RV3028_CLKOUT_PORIEBIT(3)
+#define RV3028_CLKOUT_CLKSYBIT(6)
+#define RV3028_CLKOUT_CLKOEBIT(7)
+
+#define RV3028_CTRL1_EERD  BIT(3)
+#define RV3028_CTRL1_WADA  BIT(5)
+
+#define RV3028_CTRL2_RESET BIT(0)
+#define RV3028_CTRL2_12_24 BIT(1)
+#define RV3028_CTRL2_EIE   BIT(2)
+#define RV3028_CTRL2_AIE   B

Re: [PATCH 3/4] watchdog: Allow to use CONFIG_WDT without starting watchdog

2021-03-09 Thread Stefan Roese

On 09.03.21 14:27, Pali Rohár wrote:

On Tuesday 09 March 2021 12:33:24 Stefan Roese wrote:

On 05.03.21 22:36, Pali Rohár wrote:

In some cases it is useful to compile support for U-Boot command 'wdt'
without starting HW watchdog in early U-Boot phase. For example when user


Nitpicking:
   when "the" user


want to start watchdog only on demand by some boot script.

This change adds a new compile option WATCHDOG_AUTOSTART to control whether
U-Boot should automatically start watchdog during init phase or not.


   start "the" watchdog



This option is enabled by default as it was was default behavior prior


   as it was the default


introducing this new change. When compiling U-Boot users can decide to turn
this option off.

Signed-off-by: Pali Rohár 
---
   drivers/watchdog/Kconfig  | 13 +
   drivers/watchdog/wdt-uclass.c |  7 +++
   2 files changed, 20 insertions(+)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 602ccbe41c00..aa76a8f2d239 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -9,6 +9,19 @@ config WATCHDOG
  this option if you want to service enabled watchdog by U-Boot. Disable
  this option if you want U-Boot to start watchdog but never service it.
+config WATCHDOG_AUTOSTART
+   bool "Automatically start watchdog timer"
+   depends on WDT
+   default y
+   help
+ Automatically start watchdog timer and start servicing it during
+ init phase. Enabled by default. Disable this option if you want
+ to compile U-Boot with CONFIG_WDT support but do not want to
+ activate watchdog, like when CONFIG_WDT option is disabled. You
+ would be able to start watchdog manually by 'wdt' command. Useful
+ when you want to have support for 'wdt' command but do not want
+ to have watchdog enabled by default.
+
   config WATCHDOG_TIMEOUT_MSECS
int "Watchdog timeout in msec"
default 128000 if ARCH_MX25 || ARCH_MX31 || ARCH_MX5 || ARCH_MX6
diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
index 7500b3ed90e3..00a408bf5cc5 100644
--- a/drivers/watchdog/wdt-uclass.c
+++ b/drivers/watchdog/wdt-uclass.c
@@ -27,7 +27,9 @@ static ulong reset_period = 1000;
   int initr_watchdog(void)
   {
u32 timeout = WATCHDOG_TIMEOUT_SECS;
+#ifdef CONFIG_WATCHDOG_AUTOSTART
int ret;
+#endif


Please don't add more #ifdef's if possible, see below...


/*
 * Init watchdog: This will call the probe function of the
@@ -51,6 +53,10 @@ int initr_watchdog(void)
4 * reset_period) / 4;
}
+#ifndef CONFIG_WATCHDOG_AUTOSTART
+   printf("WDT:   Not starting\n");
+   return 0;
+#else
ret = wdt_start(gd->watchdog_dev, timeout * 1000, 0);
if (ret != 0) {
printf("WDT:   Failed to start\n");
@@ -61,6 +67,7 @@ int initr_watchdog(void)
   IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out", timeout);
return 0;
+#endif


Please use this instead here:

if (CONFIG_IS_ENABLED(WATCHDOG_AUTOSTART)) {
...

Thanks,
Stefan


   }
   int wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags)




Viele Grüße,
Stefan


I have fixed these issues in V2.


Thanks.

Could you please next time when sending an updated patch series /
version include the tags, like my RB tag? As patchwork collects
these automatically and now I need to re-send them again - which I
will do this time. ;)

Thanks,
Stefan


Re: [PATCH v2 1/4] watchdog: Set/unset GD_FLG_WDT_READY flag in wdt_start()/wdt_stop()

2021-03-09 Thread Stefan Roese

On 09.03.21 14:26, Pali Rohár wrote:

Watchdog is ready after successful call of ops->start() callback in
wdt_start() function. And is stopped after successful call of ops->stop()
callback in wdt_stop function.

So move setting of GD_FLG_WDT_READY flag from initr_watchdog() function to
wdt_start() and ensure that GD_FLG_WDT_READY flag is unset in wdt_stop()
function.

This change ensures that GD_FLG_WDT_READY flag is set only when watchdog is
running. And ensures that flag is also also when watchdog was started not
only by initr_watchdog() call (e.g. by U-Boot 'wdt' command).

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  drivers/watchdog/wdt-uclass.c | 15 ---
  1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
index 28f7918c4673..3f707f61f74f 100644
--- a/drivers/watchdog/wdt-uclass.c
+++ b/drivers/watchdog/wdt-uclass.c
@@ -51,7 +51,6 @@ int initr_watchdog(void)
}
  
  	wdt_start(gd->watchdog_dev, timeout * 1000, 0);

-   gd->flags |= GD_FLG_WDT_READY;
printf("WDT:   Started with%s servicing (%ds timeout)\n",
   IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out", timeout);
  
@@ -61,21 +60,31 @@ int initr_watchdog(void)

  int wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags)
  {
const struct wdt_ops *ops = device_get_ops(dev);
+   int ret;
  
  	if (!ops->start)

return -ENOSYS;
  
-	return ops->start(dev, timeout_ms, flags);

+   ret = ops->start(dev, timeout_ms, flags);
+   if (ret == 0)
+   gd->flags |= GD_FLG_WDT_READY;
+
+   return ret;
  }
  
  int wdt_stop(struct udevice *dev)

  {
const struct wdt_ops *ops = device_get_ops(dev);
+   int ret;
  
  	if (!ops->stop)

return -ENOSYS;
  
-	return ops->stop(dev);

+   ret = ops->stop(dev);
+   if (ret == 0)
+   gd->flags &= ~GD_FLG_WDT_READY;
+
+   return ret;
  }
  
  int wdt_reset(struct udevice *dev)





Viele Grüße,
Stefan

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


Re: [PATCH v2 2/4] watchdog: Show error message when initr_watchdog() cannot start watchdog

2021-03-09 Thread Stefan Roese

On 09.03.21 14:26, Pali Rohár wrote:

Function wdt_start() may fail. So in initr_watchdog() function check return
value of wdt_start() call and print error message when watchdog starting
failed.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  drivers/watchdog/wdt-uclass.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
index 3f707f61f74f..7500b3ed90e3 100644
--- a/drivers/watchdog/wdt-uclass.c
+++ b/drivers/watchdog/wdt-uclass.c
@@ -27,6 +27,7 @@ static ulong reset_period = 1000;
  int initr_watchdog(void)
  {
u32 timeout = WATCHDOG_TIMEOUT_SECS;
+   int ret;
  
  	/*

 * Init watchdog: This will call the probe function of the
@@ -50,7 +51,12 @@ int initr_watchdog(void)
4 * reset_period) / 4;
}
  
-	wdt_start(gd->watchdog_dev, timeout * 1000, 0);

+   ret = wdt_start(gd->watchdog_dev, timeout * 1000, 0);
+   if (ret != 0) {
+   printf("WDT:   Failed to start\n");
+   return 0;
+   }
+
printf("WDT:   Started with%s servicing (%ds timeout)\n",
   IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out", timeout);
  




Viele Grüße,
Stefan

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


Re: [PATCH v2 3/4] watchdog: Allow to use CONFIG_WDT without starting watchdog

2021-03-09 Thread Stefan Roese

On 09.03.21 14:26, Pali Rohár wrote:

In some cases it is useful to compile support for U-Boot command 'wdt'
without starting HW watchdog in early U-Boot phase. For example when the
user want to start the watchdog only on demand by some boot script.

This change adds a new compile option WATCHDOG_AUTOSTART to control whether
U-Boot should automatically start the watchdog during init phase or not.

This option is enabled by default as it was the default behavior prior
introducing this new change. When compiling U-Boot users can decide to turn
this option off.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  drivers/watchdog/Kconfig  | 13 +
  drivers/watchdog/wdt-uclass.c |  5 +
  2 files changed, 18 insertions(+)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 602ccbe41c00..aa76a8f2d239 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -9,6 +9,19 @@ config WATCHDOG
  this option if you want to service enabled watchdog by U-Boot. Disable
  this option if you want U-Boot to start watchdog but never service it.
  
+config WATCHDOG_AUTOSTART

+   bool "Automatically start watchdog timer"
+   depends on WDT
+   default y
+   help
+ Automatically start watchdog timer and start servicing it during
+ init phase. Enabled by default. Disable this option if you want
+ to compile U-Boot with CONFIG_WDT support but do not want to
+ activate watchdog, like when CONFIG_WDT option is disabled. You
+ would be able to start watchdog manually by 'wdt' command. Useful
+ when you want to have support for 'wdt' command but do not want
+ to have watchdog enabled by default.
+
  config WATCHDOG_TIMEOUT_MSECS
int "Watchdog timeout in msec"
default 128000 if ARCH_MX25 || ARCH_MX31 || ARCH_MX5 || ARCH_MX6
diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
index 7500b3ed90e3..0603ffbd36d9 100644
--- a/drivers/watchdog/wdt-uclass.c
+++ b/drivers/watchdog/wdt-uclass.c
@@ -51,6 +51,11 @@ int initr_watchdog(void)
4 * reset_period) / 4;
}
  
+	if (!CONFIG_IS_ENABLED(WATCHDOG_AUTOSTART)) {

+   printf("WDT:   Not starting\n");
+   return 0;
+   }
+
ret = wdt_start(gd->watchdog_dev, timeout * 1000, 0);
if (ret != 0) {
printf("WDT:   Failed to start\n");




Viele Grüße,
Stefan

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


Re: [PATCH v2 4/4] arm: mvebu: Espressobin: Enable watchdog support but do not start it

2021-03-09 Thread Stefan Roese

On 09.03.21 14:26, Pali Rohár wrote:

Espressobin had disabled watchdog support (CONFIG_WDT) because older stable
Linux kernel versions (which are used by current stable OpenWRT and Debian
versions) do not have support for Armada 3700 watchdog driver. Therefore
they are not able to periodically kick watchdog so Espressobin enter into
boot loop.

This change enable CONFIG_WDT, CONFIG_WDT_ARMADA_37XX and CONFIG_CMD_WDT
options which add support for U-Boot 'wdt' command. And unset new
CONFIG_WATCHDOG_AUTOSTART option which cause that watchdog is not
automatically started by U-Boot during init phase, like when CONFIG_WDT
option is not set at all.

So with this change, U-Boot on Espressobin would have working 'wdt' command
which can be used from boot scripts (e.g. for enabling watchdog prior new
Linux booting kernel). But default behavior of watchdog status stays
unchanged, U-Boot does not start watchdog on Espressobin during its init
phase.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  configs/mvebu_espressobin-88f3720_defconfig | 4 
  1 file changed, 4 insertions(+)

diff --git a/configs/mvebu_espressobin-88f3720_defconfig 
b/configs/mvebu_espressobin-88f3720_defconfig
index c791f98dfea5..20aa21b06b3d 100644
--- a/configs/mvebu_espressobin-88f3720_defconfig
+++ b/configs/mvebu_espressobin-88f3720_defconfig
@@ -32,6 +32,7 @@ CONFIG_CMD_MMC=y
  CONFIG_CMD_PCI=y
  CONFIG_CMD_SPI=y
  CONFIG_CMD_USB=y
+CONFIG_CMD_WDT=y
  CONFIG_CMD_TFTPPUT=y
  CONFIG_CMD_CACHE=y
  CONFIG_CMD_TIME=y
@@ -88,5 +89,8 @@ CONFIG_USB_ETHER_ASIX=y
  CONFIG_USB_ETHER_MCS7830=y
  CONFIG_USB_ETHER_RTL8152=y
  CONFIG_USB_ETHER_SMSC95XX=y
+# CONFIG_WATCHDOG_AUTOSTART is not set
+CONFIG_WDT=y
+CONFIG_WDT_ARMADA_37XX=y
  CONFIG_SHA1=y
  CONFIG_SHA256=y




Viele Grüße,
Stefan

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


Re: [PATCH 3/4] watchdog: Allow to use CONFIG_WDT without starting watchdog

2021-03-09 Thread Pali Rohár
On Tuesday 09 March 2021 17:12:40 Stefan Roese wrote:
> On 09.03.21 14:27, Pali Rohár wrote:
> > On Tuesday 09 March 2021 12:33:24 Stefan Roese wrote:
> > > On 05.03.21 22:36, Pali Rohár wrote:
> > > > In some cases it is useful to compile support for U-Boot command 'wdt'
> > > > without starting HW watchdog in early U-Boot phase. For example when 
> > > > user
> > > 
> > > Nitpicking:
> > >when "the" user
> > > 
> > > > want to start watchdog only on demand by some boot script.
> > > > 
> > > > This change adds a new compile option WATCHDOG_AUTOSTART to control 
> > > > whether
> > > > U-Boot should automatically start watchdog during init phase or not.
> > > 
> > >start "the" watchdog
> > > 
> > > > 
> > > > This option is enabled by default as it was was default behavior prior
> > > 
> > >as it was the default
> > > 
> > > > introducing this new change. When compiling U-Boot users can decide to 
> > > > turn
> > > > this option off.
> > > > 
> > > > Signed-off-by: Pali Rohár 
> > > > ---
> > > >drivers/watchdog/Kconfig  | 13 +
> > > >drivers/watchdog/wdt-uclass.c |  7 +++
> > > >2 files changed, 20 insertions(+)
> > > > 
> > > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> > > > index 602ccbe41c00..aa76a8f2d239 100644
> > > > --- a/drivers/watchdog/Kconfig
> > > > +++ b/drivers/watchdog/Kconfig
> > > > @@ -9,6 +9,19 @@ config WATCHDOG
> > > >   this option if you want to service enabled watchdog by 
> > > > U-Boot. Disable
> > > >   this option if you want U-Boot to start watchdog but never 
> > > > service it.
> > > > +config WATCHDOG_AUTOSTART
> > > > +   bool "Automatically start watchdog timer"
> > > > +   depends on WDT
> > > > +   default y
> > > > +   help
> > > > + Automatically start watchdog timer and start servicing it 
> > > > during
> > > > + init phase. Enabled by default. Disable this option if you 
> > > > want
> > > > + to compile U-Boot with CONFIG_WDT support but do not want to
> > > > + activate watchdog, like when CONFIG_WDT option is disabled. 
> > > > You
> > > > + would be able to start watchdog manually by 'wdt' command. 
> > > > Useful
> > > > + when you want to have support for 'wdt' command but do not 
> > > > want
> > > > + to have watchdog enabled by default.
> > > > +
> > > >config WATCHDOG_TIMEOUT_MSECS
> > > > int "Watchdog timeout in msec"
> > > > default 128000 if ARCH_MX25 || ARCH_MX31 || ARCH_MX5 || ARCH_MX6
> > > > diff --git a/drivers/watchdog/wdt-uclass.c 
> > > > b/drivers/watchdog/wdt-uclass.c
> > > > index 7500b3ed90e3..00a408bf5cc5 100644
> > > > --- a/drivers/watchdog/wdt-uclass.c
> > > > +++ b/drivers/watchdog/wdt-uclass.c
> > > > @@ -27,7 +27,9 @@ static ulong reset_period = 1000;
> > > >int initr_watchdog(void)
> > > >{
> > > > u32 timeout = WATCHDOG_TIMEOUT_SECS;
> > > > +#ifdef CONFIG_WATCHDOG_AUTOSTART
> > > > int ret;
> > > > +#endif
> > > 
> > > Please don't add more #ifdef's if possible, see below...
> > > 
> > > > /*
> > > >  * Init watchdog: This will call the probe function of the
> > > > @@ -51,6 +53,10 @@ int initr_watchdog(void)
> > > > 4 * reset_period) / 
> > > > 4;
> > > > }
> > > > +#ifndef CONFIG_WATCHDOG_AUTOSTART
> > > > +   printf("WDT:   Not starting\n");
> > > > +   return 0;
> > > > +#else
> > > > ret = wdt_start(gd->watchdog_dev, timeout * 1000, 0);
> > > > if (ret != 0) {
> > > > printf("WDT:   Failed to start\n");
> > > > @@ -61,6 +67,7 @@ int initr_watchdog(void)
> > > >IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out", timeout);
> > > > return 0;
> > > > +#endif
> > > 
> > > Please use this instead here:
> > > 
> > >   if (CONFIG_IS_ENABLED(WATCHDOG_AUTOSTART)) {
> > >   ...
> > > 
> > > Thanks,
> > > Stefan
> > > 
> > > >}
> > > >int wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags)
> > > > 
> > > 
> > > 
> > > Viele Grüße,
> > > Stefan
> > 
> > I have fixed these issues in V2.
> 
> Thanks.
> 
> Could you please next time when sending an updated patch series /
> version include the tags, like my RB tag? As patchwork collects
> these automatically and now I need to re-send them again - which I
> will do this time. ;)
> 
> Thanks,
> Stefan

Ok, no problem!


Re: [PATCH] rtc: add support for rv3028 rtc

2021-03-09 Thread Alexandre Belloni
On 09/03/2021 17:10:21+0100, Stefan Roese wrote:
> Hi Heiko,
> 
> On 09.03.21 14:45, Heiko Schocher wrote:
> > add support for rtc3028 rtc from microcrystal.
> > based on linux dirver:
> > commit a38fd8748464: ("Linux 5.12-rc2")
> 
> Nitpicking: You might want to start a sentence in upper-case? ;)
> 
> Another minor comment below...
> 
> > Signed-off-by: Heiko Schocher 
> > 
> > ---
> > driver is based on code in linux, but with already
> > corrected weekday usage. linux codes the weekday
> > bitwise, while the weekday register has only 3 valid
> > bits as the app manual [1] says:
> > 
> > This register holds the current day of the week. Each value represents
> > one weekday that is assigned by the user. Values will range from 0 to 6
> > The weekday counter is simply a 3-bit counter which counts up to 6
> > and then resets to 0.
> > 
> > [1] 
> > https://www.microcrystal.com/fileadmin/Media/Products/RTC/App.Manual/RV-3028-C7_App-Manual.pdf
> > 
> > This is not a big problem, as userspace never use weekday.
> > Nevertheless, I will also send an update for the linux driver.
> > 
> > Also the nvram can be used for bootcounter purposes.
> > 
> > Tested this driver on "PHYTEC phyBOARD-Pollux i.MX8MP" board.
> > 
> > azure build:
> > https://dev.azure.com/hs0298/hs/_build/results?buildId=63&view=results
> > 
> >   drivers/rtc/Kconfig  |   6 ++
> >   drivers/rtc/Makefile |   1 +
> >   drivers/rtc/rv3028.c | 215 +++
> >   3 files changed, 222 insertions(+)
> >   create mode 100644 drivers/rtc/rv3028.c
> > 
> > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> > index aa6d90158c..e451308b40 100644
> > --- a/drivers/rtc/Kconfig
> > +++ b/drivers/rtc/Kconfig
> > @@ -95,6 +95,12 @@ config RTC_PCF8563
> >   If you say yes here you get support for the Philips PCF8563 RTC
> >   and compatible chips.
> > +config RTC_RV3028
> > +   bool "Enable RV3028 driver"
> > +   depends on DM_RTC
> > +   help
> > + The MicroCrystal RV3028 is a I2C Real Time Clock (RTC)
> > +
> >   config RTC_RV3029
> > bool "Enable RV3029 driver"
> > depends on DM_RTC
> > diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> > index 6a45a9c874..e7acd76266 100644
> > --- a/drivers/rtc/Makefile
> > +++ b/drivers/rtc/Makefile
> > @@ -46,6 +46,7 @@ obj-$(CONFIG_RTC_PCF2127) += pcf2127.o
> >   obj-$(CONFIG_RTC_PL031) += pl031.o
> >   obj-$(CONFIG_RTC_PT7C4338) += pt7c4338.o
> >   obj-$(CONFIG_RTC_RS5C372A) += rs5c372.o
> > +obj-$(CONFIG_RTC_RV3028) += rv3028.o
> >   obj-$(CONFIG_RTC_RV3029) += rv3029.o
> >   obj-$(CONFIG_RTC_RV8803) += rv8803.o
> >   obj-$(CONFIG_RTC_RX8025) += rx8025.o
> > diff --git a/drivers/rtc/rv3028.c b/drivers/rtc/rv3028.c
> > new file mode 100644
> > index 00..8d8336c5f1
> > --- /dev/null
> > +++ b/drivers/rtc/rv3028.c
> > @@ -0,0 +1,215 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * RTC driver for the Micro Crystal RV3028
> > + *
> > + * based on linux driver from
> > + * Copyright (C) 2019 Micro Crystal SA
> > + *
> > + * Alexandre Belloni 
> > + *
> > + */
> > +
> > +#include 
> 
> Please don't include "common.h" any more. It's deprecated.
> 
> > +#include 
> 
> Do you really need "command.h" ...
> 
> > +#include 
> > +#include 
> 
> ... and this one? Please check and only inlude the necessary headers.
> 

Wouldn't that be needed to expose the on board NVRAM or EEPROM? However
I don't see any code to access that right now.


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: [PATCH] disk: gpt: verify alternate LBA points to last usable LBA

2021-03-09 Thread Stefan Herbrechtsmeier

Hi Heinrich,

Am 08.03.2021 um 18:38 schrieb Heinrich Schuchardt:

On 08.03.21 17:07, Stefan Herbrechtsmeier wrote:

From: Stefan Herbrechtsmeier 

The gpt command require the GPT backup header at the standard location
at the end of the device.Check the alternate LBA value before reading
the GPT backup header from the last usable LBA of the device.


If there is a bug in the gpt command, please, fix it instead of
introducing constraints that don't exist in the UEFI specification.

The UEFI specification has:

"The backup GPT Partition Entry Array must be located after the Last
Usable LBA and end before the backup GPT Header."


"If the primary GPT is invalid, the backup GPT is used instead and it is 
located on the last logical block on the disk." [UEFI specification 2.8, 
S. 120]


"Note that UEFI standard requires the backup header at the end of the 
device and partitioning tools can automatically relocate the header to 
follow the standard." [sfdisk man page, --relocate, gpt-bak-mini]


What should U-Boot do? I have a patch to use the backup GPT header if 
only the header itself is valid but I don't know if this behavior is 
correct.


Regards,
  Stefan


Re: [PATCH] disk: gpt: verify alternate LBA points to last usable LBA

2021-03-09 Thread Heinrich Schuchardt
On 09.03.21 17:24, Stefan Herbrechtsmeier wrote:
> Hi Heinrich,
>
> Am 08.03.2021 um 18:38 schrieb Heinrich Schuchardt:
>> On 08.03.21 17:07, Stefan Herbrechtsmeier wrote:
>>> From: Stefan Herbrechtsmeier 
>>>
>>> The gpt command require the GPT backup header at the standard location
>>> at the end of the device.Check the alternate LBA value before reading
>>> the GPT backup header from the last usable LBA of the device.
>>
>> If there is a bug in the gpt command, please, fix it instead of
>> introducing constraints that don't exist in the UEFI specification.
>>
>> The UEFI specification has:
>>
>> "The backup GPT Partition Entry Array must be located after the Last
>> Usable LBA and end before the backup GPT Header."
>
> "If the primary GPT is invalid, the backup GPT is used instead and it is
> located on the last logical block on the disk." [UEFI specification 2.8,
> S. 120]

Thank you for pointing me to this sentence which I missed.

Reviewed-by: Heinrich Schuchardt 

>
> "Note that UEFI standard requires the backup header at the end of the
> device and partitioning tools can automatically relocate the header to
> follow the standard." [sfdisk man page, --relocate, gpt-bak-mini]
>
> What should U-Boot do? I have a patch to use the backup GPT header if
> only the header itself is valid but I don't know if this behavior is
> correct.
>
> Regards,
>   Stefan



[PATCH 2/2] configs: am65x_evm_r5: Enable checks for spl and stack sizes

2021-03-09 Thread Lokesh Vutla
Enable relevant configs that checks for the size of image and stack:

 BSS: 3KB
 Initial MALLOC: ~22KB
 Initial Stack: 8K
 SPL Image size can be: ~215KB

Signed-off-by: Lokesh Vutla 
---
 configs/am65x_evm_r5_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configs/am65x_evm_r5_defconfig b/configs/am65x_evm_r5_defconfig
index b9b11010a1..57f3300380 100644
--- a/configs/am65x_evm_r5_defconfig
+++ b/configs/am65x_evm_r5_defconfig
@@ -17,6 +17,8 @@ CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
 CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_SIZE_LIMIT=0x7ec00
+CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x2000
 CONFIG_SPL_FS_FAT=y
 CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
@@ -27,6 +29,9 @@ CONFIG_SPL_LOAD_FIT=y
 # CONFIG_USE_SPL_FIT_GENERATOR is not set
 CONFIG_USE_BOOTCOMMAND=y
 # CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y
+CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
+CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SPL_EARLY_BSS=y
-- 
2.30.0



[PATCH 1/2] include: configs: am65x_evm: Optimize size of SPL BSS

2021-03-09 Thread Lokesh Vutla
Current BSS allocation of SPL is as below:
$ size spl/u-boot-spl
   textdata bss dec hex filename
 13236978521496  141717   22995 spl/u-boot-spl

But 20KB is allocated currently for BSS. Reduce it to 3KB and save some
space for stack.

Signed-off-by: Lokesh Vutla 
---
 include/configs/am65x_evm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
index b39a5b4ca4..76d73086fb 100644
--- a/include/configs/am65x_evm.h
+++ b/include/configs/am65x_evm.h
@@ -30,7 +30,7 @@
  * our memory footprint. The less we use for BSS the more we have available
  * for everything else.
  */
-#define CONFIG_SPL_BSS_MAX_SIZE0x5000
+#define CONFIG_SPL_BSS_MAX_SIZE0xc00
 /*
  * Link BSS to be within SPL in a dedicated region located near the top of
  * the MCU SRAM, this way making it available also before relocation. Note
-- 
2.30.0



[PATCH v2] Nokia RX-51: Enable CONFIG_WDT to remove deprecation warning

2021-03-09 Thread Pali Rohár
Also convert CONFIG_HW_WATCHDOG to CONFIG_WATCHDOG.

Signed-off-by: Pali Rohár 
---
This patch increase u-boot.bin binary size above maximal limit. So this
patch cannot be applied yet. But it can be applied on top of the LTO
patches. So please put this patch into the queue and include it into
U-Boot after LTO patches are merged.

Changes in v2:
* converted CONFIG_HW_WATCHDOG to CONFIG_WATCHDOG
---
 board/nokia/rx51/rx51.c  | 37 
 configs/nokia_rx51_defconfig |  2 ++
 include/configs/nokia_rx51.h |  3 ---
 3 files changed, 35 insertions(+), 7 deletions(-)

diff --git a/board/nokia/rx51/rx51.c b/board/nokia/rx51/rx51.c
index 7bd5fbd71520..fd3cec8358aa 100644
--- a/board/nokia/rx51/rx51.c
+++ b/board/nokia/rx51/rx51.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -487,20 +488,20 @@ static unsigned long int twl_wd_time; /* last time of 
watchdog reset */
 static unsigned long int twl_i2c_lock;
 
 /*
- * Routine: hw_watchdog_reset
+ * Routine: rx51_watchdog_reset
  * Description: Reset timeout of twl4030 watchdog.
  */
-void hw_watchdog_reset(void)
+static int rx51_watchdog_reset(struct udevice *dev)
 {
u8 timeout = 0;
 
/* do not reset watchdog too often - max every 4s */
if (get_timer(twl_wd_time) < 4 * CONFIG_SYS_HZ)
-   return;
+   return 0;
 
/* localy lock twl4030 i2c bus */
if (test_and_set_bit(0, &twl_i2c_lock))
-   return;
+   return 0;
 
/* read actual watchdog timeout */
twl4030_i2c_read_u8(TWL4030_CHIP_PM_RECEIVER,
@@ -517,8 +518,32 @@ void hw_watchdog_reset(void)
 
/* localy unlock twl4030 i2c bus */
test_and_clear_bit(0, &twl_i2c_lock);
+
+   return 0;
+}
+
+static int rx51_watchdog_start(struct udevice *dev, u64 timeout_ms, ulong 
flags)
+{
+   return 0;
 }
 
+static int rx51_watchdog_probe(struct udevice *dev)
+{
+   return 0;
+}
+
+static const struct wdt_ops rx51_watchdog_ops = {
+   .start = rx51_watchdog_start,
+   .reset = rx51_watchdog_reset,
+};
+
+U_BOOT_DRIVER(rx51_watchdog) = {
+   .name = "rx51_watchdog",
+   .id = UCLASS_WDT,
+   .ops = &rx51_watchdog_ops,
+   .probe = rx51_watchdog_probe,
+};
+
 /*
  * TWL4030 keypad handler for cfb_console
  */
@@ -722,3 +747,7 @@ U_BOOT_DRVINFOS(rx51_i2c) = {
{ "i2c_omap", &rx51_i2c[1] },
{ "i2c_omap", &rx51_i2c[2] },
 };
+
+U_BOOT_DRVINFOS(rx51_watchdog) = {
+   { "rx51_watchdog" },
+};
diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
index 312ca3a1a991..80b18e435105 100644
--- a/configs/nokia_rx51_defconfig
+++ b/configs/nokia_rx51_defconfig
@@ -67,4 +67,6 @@ CONFIG_CFB_CONSOLE=y
 CONFIG_CFB_CONSOLE_ANSI=y
 # CONFIG_VGA_AS_SINGLE_DEVICE is not set
 CONFIG_SPLASH_SCREEN=y
+CONFIG_WATCHDOG_TIMEOUT_MSECS=31000
+CONFIG_WDT=y
 # CONFIG_GZIP is not set
diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h
index 23368de624e1..fe991ea03991 100644
--- a/include/configs/nokia_rx51.h
+++ b/include/configs/nokia_rx51.h
@@ -85,9 +85,6 @@
 
 #define CONFIG_SYS_ONENAND_BASEONENAND_MAP
 
-/* Watchdog support */
-#define CONFIG_HW_WATCHDOG
-
 /*
  * Framebuffer
  */
-- 
2.20.1



[PATCH] cmd: fs: Use part_get_info_by_dev_and_name_or_num to parse partitions

2021-03-09 Thread Sean Anderson
This allows using dev#partlabel syntax.

Signed-off-by: Sean Anderson 
---

 fs/fs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/fs.c b/fs/fs.c
index 900928c394..b7936fd4cf 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -385,8 +385,8 @@ int fs_set_blk_dev(const char *ifname, const char 
*dev_part_str, int fstype)
}
 #endif
 
-   part = blk_get_device_part_str(ifname, dev_part_str, &fs_dev_desc,
-   &fs_partition, 1);
+   part = part_get_info_by_dev_and_name_or_num(ifname, dev_part_str, 
&fs_dev_desc,
+   &fs_partition, 1);
if (part < 0)
return -1;
 
-- 
2.25.1



Re: [PATCH] cmd: fs: Use part_get_info_by_dev_and_name_or_num to parse partitions

2021-03-09 Thread Heinrich Schuchardt
Am 9. März 2021 21:56:24 MEZ schrieb Sean Anderson :
>This allows using dev#partlabel syntax.

Allowing more widespread use of that syntax makes sense to me.

Unfortunately you do not mention which commands and devices are affected.

>
>Signed-off-by: Sean Anderson 
>---
>
> fs/fs.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/fs/fs.c b/fs/fs.c
>index 900928c394..b7936fd4cf 100644
>--- a/fs/fs.c
>+++ b/fs/fs.c
>@@ -385,8 +385,8 @@ int fs_set_blk_dev(const char *ifname, const char
>*dev_part_str, int fstype)
>   }
> #endif
> 
>-  part = blk_get_device_part_str(ifname, dev_part_str, &fs_dev_desc,
>-  &fs_partition, 1);
>+  part = part_get_info_by_dev_and_name_or_num(ifname, dev_part_str,
>&fs_dev_desc,
>+  &fs_partition, 1);
>   if (part < 0)
>   return -1;
> 

It would be good if we could test the new capabilities. Can we make use of 
sandbox_mmc.c?

Best regards

Heinrich






Re: [PATCH] cmd: fs: Use part_get_info_by_dev_and_name_or_num to parse partitions

2021-03-09 Thread Sean Anderson




On 3/9/21 4:21 PM, Heinrich Schuchardt wrote:
> Am 9. März 2021 21:56:24 MEZ schrieb Sean Anderson :
>> This allows using dev#partlabel syntax.
>
> Allowing more widespread use of that syntax makes sense to me.
>
> Unfortunately you do not mention which commands and devices are affected.

I enabled it so that cmd/fs.c can use it (e.g. CMD_FS_GENERIC).

It seems like I overlooked that this was in fs/fs.c and not cmd/fs.c.

Affected functionality should be most filesystem commands (due to
do_load), DFU, fastboot, and splash screen. I suspect this affects
almost every device using U-Boot.

>
>>
>> Signed-off-by: Sean Anderson 
>> ---
>>
>> fs/fs.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/fs.c b/fs/fs.c
>> index 900928c394..b7936fd4cf 100644
>> --- a/fs/fs.c
>> +++ b/fs/fs.c
>> @@ -385,8 +385,8 @@ int fs_set_blk_dev(const char *ifname, const char
>> *dev_part_str, int fstype)
>>}
>> #endif
>>
>> -  part = blk_get_device_part_str(ifname, dev_part_str, &fs_dev_desc,
>> -  &fs_partition, 1);
>> +  part = part_get_info_by_dev_and_name_or_num(ifname, dev_part_str,
>> &fs_dev_desc,
>> +  &fs_partition, 1);
>>if (part < 0)
>>return -1;
>>
>
> It would be good if we could test the new capabilities. Can we make use of 
sandbox_mmc.c?

I suppose. There are already some tests in test/dm/fastboot.c along
these lines. Fastboot calls into part_get_info_by_dev_and_name_or_num,
so I think that is testing the same sort of thing. Perhaps they should
be broken out into general partition tests. IMO this code path already
has adequate tests.

--Sean


Re: [PATCH v4 1/5] firmware: scmi: voltage regulator

2021-03-09 Thread Jaehoon Chung
On 3/9/21 6:38 AM, Etienne Carriere wrote:
> Implement voltage regulators interfaced by the SCMI voltage domain
> protocol. The DT bindings are defined in the Linux kernel since
> SCMI voltage domain and regulators patches [1] and [2] integration
> in v5.11-rc7.
> 
> Link: [1] 
> https://protect2.fireeye.com/v1/url?k=4762535a-18f96b93-4763d815-0cc47a336fae-3c00cacbc555f86e&q=1&e=d232145a-df26-46c6-b2ed-fd2b665c4b71&u=https%3A%2F%2Fgithub.com%2Ftorvalds%2Flinux%2Fcommit%2F0f80fcec08e9c50b8d2992cf26495673765ebaba
> Link: [2] 
> https://protect2.fireeye.com/v1/url?k=3da6e589-623ddd40-3da76ec6-0cc47a336fae-8f68d44282000af5&q=1&e=d232145a-df26-46c6-b2ed-fd2b665c4b71&u=https%3A%2F%2Fgithub.com%2Ftorvalds%2Flinux%2Fcommit%2F2add5cacff3531e54c50b0832128299faa9f0563
> Signed-off-by: Etienne Carriere 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
> Changes in v4:
> - define a device for SCMI voltage protocol that binds the SCMI regulators
>   as suggested by Patrick.
> - removed Simon and Jaehoon tags since changes.
> 
> Changes in v3:
> - applied review tags
> 
> Changes in v2:
> - no change
> ---
>  doc/device-tree-bindings/arm/arm,scmi.txt |  34 
>  drivers/firmware/scmi/scmi_agent-uclass.c |  10 ++
>  drivers/power/regulator/Kconfig   |   8 +
>  drivers/power/regulator/Makefile  |   1 +
>  drivers/power/regulator/scmi_regulator.c  | 195 ++
>  include/scmi_protocols.h  | 113 +
>  6 files changed, 361 insertions(+)
>  create mode 100644 drivers/power/regulator/scmi_regulator.c
> 
> diff --git a/doc/device-tree-bindings/arm/arm,scmi.txt 
> b/doc/device-tree-bindings/arm/arm,scmi.txt
> index 1f293ea24..a76124f4a 100644
> --- a/doc/device-tree-bindings/arm/arm,scmi.txt
> +++ b/doc/device-tree-bindings/arm/arm,scmi.txt
> @@ -62,6 +62,20 @@ Required properties:
>   - #power-domain-cells : Should be 1. Contains the device or the power
>domain ID value used by SCMI commands.
>  
> +Regulator bindings for the SCMI Regulator based on SCMI Message Protocol
> +
> +An SCMI Regulator is permanently bound to a well defined SCMI Voltage Domain,
> +and should be always positioned as a root regulator.
> +It does not support any current operation.
> +
> +SCMI Regulators are grouped under a 'regulators' node which in turn is a 
> child
> +of the SCMI Voltage protocol node inside the desired SCMI instance node.
> +
> +This binding uses the common regulator binding[6].
> +
> +Required properties:
> + - reg : shall identify an existent SCMI Voltage Domain.
> +
>  Sensor bindings for the sensors based on SCMI Message Protocol
>  --
>  SCMI provides an API to access the various sensors on the SoC.
> @@ -105,6 +119,7 @@ Required sub-node properties:
>  [3] Documentation/devicetree/bindings/thermal/thermal.txt
>  [4] Documentation/devicetree/bindings/sram/sram.yaml
>  [5] Documentation/devicetree/bindings/reset/reset.txt
> +[6] Documentation/devicetree/bindings/regulator/regulator.yaml
>  
>  Example:
>  
> @@ -169,6 +184,25 @@ firmware {
>   reg = <0x16>;
>   #reset-cells = <1>;
>   };
> +
> + scmi_voltage: protocol@17 {
> + reg = <0x17>;
> +
> + regulators {
> + regulator_devX: regulator@0 {
> + reg = <0x0>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + regulator_devY: regulator@9 {
> + reg = <0x9>;
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <420>;
> + };
> +
> + ...
> + };
> + };
>   };
>  };
>  
> diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c 
> b/drivers/firmware/scmi/scmi_agent-uclass.c
> index 516e690ac..f13e46c36 100644
> --- a/drivers/firmware/scmi/scmi_agent-uclass.c
> +++ b/drivers/firmware/scmi/scmi_agent-uclass.c
> @@ -79,6 +79,16 @@ static int scmi_bind_protocols(struct udevice *dev)
>   if (IS_ENABLED(CONFIG_RESET_SCMI))
>   drv = DM_DRIVER_GET(scmi_reset_domain);
>   break;
> + case SCMI_PROTOCOL_ID_VOLTAGE_DOMAIN:
> + if (IS_ENABLED(CONFIG_DM_REGULATOR_SCMI)) {
> + node = ofnode_find_subnode(node, "regulators");
> + if (!ofnode_valid(node)) {
> + dev_err(dev, "no regulators node\n");
> + return -ENXIO;
> + }
> + drv =

[PATCH v2] spl: Add callback for preprocessing loaded FIT header before parsing

2021-03-09 Thread Farhan Ali
This change adds a callback for preprocessing the FIT header before
it is parsed. There are 3 main reasons for this callback:

(1) If a vulnerability is discovered in the FIT parsing/loading code,
or libfdt, this callback allows users to scan the FIT header for
specific exploit signatures and prevent flashing/booting of the image

(2) If users want to implement a single signature which covers the
entire FIT header, which is then appended to the end of the header,
then this callback can be used to authenticate that signature.

(3) If users want to check the FIT header contents against specific
metadata stored outside the FIT header, then this callback allows
them to do that.

Signed-off-by: Farhan Ali 
Cc: Simon Glass 
Cc: Alexandru Gagniuc 
Cc: Marek Vasut 
Cc: Michal Simek 
Cc: Philippe Reynes 
Cc: Samuel Holland 

---
Changes for v2:
   - Callback now returns a value
   - Added a log message on failure
---
 common/spl/spl_fit.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 75c8ff0..01aee1c 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -43,6 +43,14 @@ __weak ulong board_spl_fit_size_align(ulong size)
return size;
 }
 
+__weak int board_spl_fit_pre_load(struct spl_load_info *load_info,
+ const void *fit,
+ ulong start_sector,
+ ulong loaded_sector_count)
+{
+   return 0;
+}
+
 static int find_node_from_desc(const void *fit, int node, const char *str)
 {
int child;
@@ -527,6 +535,7 @@ static int spl_simple_fit_read(struct spl_fit_info *ctx,
unsigned long count, size;
int sectors;
void *buf;
+   int rc = 0;
 
/*
 * For FIT with external data, figure out where the external images
@@ -552,7 +561,18 @@ static int spl_simple_fit_read(struct spl_fit_info *ctx,
debug("fit read sector %lx, sectors=%d, dst=%p, count=%lu, 
size=0x%lx\n",
  sector, sectors, buf, count, size);
 
-   return (count == 0) ? -EIO : 0;
+   if (count) {
+   /* preprocess loaded fit header before parsing and loading 
binaries */
+   rc = board_spl_fit_pre_load(info, fit_header, sector, sectors);
+   if (rc) {
+   debug("%s: fit header pre processing failed. rc=%d\n",
+ __func__, rc);
+   }
+   } else {
+   rc = -EIO;
+   }
+
+   return rc;
 }
 
 static int spl_simple_fit_parse(struct spl_fit_info *ctx)
-- 
1.8.3.1



Re: [PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build

2021-03-09 Thread Bin Meng
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún  wrote:
>
> When building with LTO, using -ffunction-sections/-fdata-sections is not
> useful anymore.
>
> Signed-off-by: Marek Behún 
> ---
>  arch/arm/config.mk | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>

I believe we should also remove --gc-sections.

Regards,
Bin


Re: Please pull u-boot-x86

2021-03-09 Thread Tom Rini
On Tue, Mar 09, 2021 at 01:15:22PM +0800, Bin Meng wrote:

> Hi Tom,
> 
> This PR includes the following x86 changes for v2021.04:
> 
> - Various minor fixes for x86
> 
> Azure results: PASS
> https://dev.azure.com/bmeng/GitHub/_build/results?buildId=337&view=results
> 
> The following changes since commit 472c5484bca41a477f8b86a263e559f6e992c7f8:
> 
>   Merge tag 'u-boot-amlogic-20210308' of
> https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic (2021-03-08
> 07:41:50 -0500)
> 
> are available in the git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-x86
> 
> for you to fetch changes up to 736ecc643de4b329e2edcb3207edd58bf7ed0d9d:
> 
>   x86: Select advanced Intel code only if allowed (2021-03-09 09:42:12 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] rtc: add support for rv3028 rtc

2021-03-09 Thread Heiko Schocher
Hi stefan,

On 09.03.21 17:10, Stefan Roese wrote:
> Hi Heiko,
> 
> On 09.03.21 14:45, Heiko Schocher wrote:
>> add support for rtc3028 rtc from microcrystal.
>> based on linux dirver:
>> commit a38fd8748464: ("Linux 5.12-rc2")
> 
> Nitpicking: You might want to start a sentence in upper-case? ;)

Yup.

> 
> Another minor comment below...
> 
>> Signed-off-by: Heiko Schocher 
>>
>> ---
>> driver is based on code in linux, but with already
>> corrected weekday usage. linux codes the weekday
>> bitwise, while the weekday register has only 3 valid
>> bits as the app manual [1] says:
>>
>> This register holds the current day of the week. Each value represents
>> one weekday that is assigned by the user. Values will range from 0 to 6
>> The weekday counter is simply a 3-bit counter which counts up to 6
>> and then resets to 0.
>>
>> [1] 
>> https://www.microcrystal.com/fileadmin/Media/Products/RTC/App.Manual/RV-3028-C7_App-Manual.pdf
>>
>> This is not a big problem, as userspace never use weekday.
>> Nevertheless, I will also send an update for the linux driver.
>>
>> Also the nvram can be used for bootcounter purposes.
>>
>> Tested this driver on "PHYTEC phyBOARD-Pollux i.MX8MP" board.
>>
>> azure build:
>> https://dev.azure.com/hs0298/hs/_build/results?buildId=63&view=results
>>
>>   drivers/rtc/Kconfig  |   6 ++
>>   drivers/rtc/Makefile |   1 +
>>   drivers/rtc/rv3028.c | 215 +++
>>   3 files changed, 222 insertions(+)
>>   create mode 100644 drivers/rtc/rv3028.c
>>
>> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
>> index aa6d90158c..e451308b40 100644
>> --- a/drivers/rtc/Kconfig
>> +++ b/drivers/rtc/Kconfig
>> @@ -95,6 +95,12 @@ config RTC_PCF8563
>>     If you say yes here you get support for the Philips PCF8563 RTC
>>     and compatible chips.
>>   +config RTC_RV3028
>> +    bool "Enable RV3028 driver"
>> +    depends on DM_RTC
>> +    help
>> +  The MicroCrystal RV3028 is a I2C Real Time Clock (RTC)
>> +
>>   config RTC_RV3029
>>   bool "Enable RV3029 driver"
>>   depends on DM_RTC
>> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
>> index 6a45a9c874..e7acd76266 100644
>> --- a/drivers/rtc/Makefile
>> +++ b/drivers/rtc/Makefile
>> @@ -46,6 +46,7 @@ obj-$(CONFIG_RTC_PCF2127) += pcf2127.o
>>   obj-$(CONFIG_RTC_PL031) += pl031.o
>>   obj-$(CONFIG_RTC_PT7C4338) += pt7c4338.o
>>   obj-$(CONFIG_RTC_RS5C372A) += rs5c372.o
>> +obj-$(CONFIG_RTC_RV3028) += rv3028.o
>>   obj-$(CONFIG_RTC_RV3029) += rv3029.o
>>   obj-$(CONFIG_RTC_RV8803) += rv8803.o
>>   obj-$(CONFIG_RTC_RX8025) += rx8025.o
>> diff --git a/drivers/rtc/rv3028.c b/drivers/rtc/rv3028.c
>> new file mode 100644
>> index 00..8d8336c5f1
>> --- /dev/null
>> +++ b/drivers/rtc/rv3028.c
>> @@ -0,0 +1,215 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * RTC driver for the Micro Crystal RV3028
>> + *
>> + * based on linux driver from
>> + * Copyright (C) 2019 Micro Crystal SA
>> + *
>> + * Alexandre Belloni 
>> + *
>> + */
>> +
>> +#include 
> 
> Please don't include "common.h" any more. It's deprecated.
> 
>> +#include 
> 
> Do you really need "command.h" ...
> 
>> +#include 
>> +#include 
> 
> ... and this one? Please check and only inlude the necessary headers.

Of course, will check them, thanks!

> Other that that:
> 
> Reviewed-by: Stefan Roese 

bye,
Heiko
> 
> Thanks,
> Stefan
> 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define RV3028_SEC    0x00
>> +#define RV3028_MIN    0x01
>> +#define RV3028_HOUR    0x02
>> +#define RV3028_WDAY    0x03
>> +#define RV3028_DAY    0x04
>> +#define RV3028_MONTH    0x05
>> +#define RV3028_YEAR    0x06
>> +#define RV3028_ALARM_MIN    0x07
>> +#define RV3028_ALARM_HOUR    0x08
>> +#define RV3028_ALARM_DAY    0x09
>> +#define RV3028_STATUS    0x0E
>> +#define RV3028_CTRL1    0x0F
>> +#define RV3028_CTRL2    0x10
>> +#define RV3028_EVT_CTRL    0x13
>> +#define RV3028_TS_COUNT    0x14
>> +#define RV3028_TS_SEC    0x15
>> +#define RV3028_RAM1    0x1F
>> +#define RV3028_EEPROM_ADDR    0x25
>> +#define RV3028_EEPROM_DATA    0x26
>> +#define RV3028_EEPROM_CMD    0x27
>> +#define RV3028_CLKOUT    0x35
>> +#define RV3028_OFFSET    0x36
>> +#define RV3028_BACKUP    0x37
>> +
>> +#define RV3028_STATUS_PORF    BIT(0)
>> +#define RV3028_STATUS_EVF    BIT(1)
>> +#define RV3028_STATUS_AF    BIT(2)
>> +#define RV3028_STATUS_TF    BIT(3)
>> +#define RV3028_STATUS_UF    BIT(4)
>> +#define RV3028_STATUS_BSF    BIT(5)
>> +#define RV3028_STATUS_CLKF    BIT(6)
>> +#define RV3028_STATUS_EEBUSY    BIT(7)
>> +
>> +#define RV3028_CLKOUT_FD_MASK    GENMASK(2, 0)
>> +#define RV3028_CLKOUT_PORIE    BIT(3)
>> +#define RV3028_CLKOUT_CLKSY    BIT(6)
>> +#define RV3028_CLKOUT_CLKOE    BIT(7)
>> +
>> +#defi

Re: [PATCH u-boot 35/39] ata: ahci: fix ahci_link_up() type mismatch for LTO

2021-03-09 Thread Bin Meng
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún  wrote:
>
> When building highbank_defconfig with LTO, the compiler complains about
> type mismatch of function ahci_link_up().
>
> The third parameter of this function is of type u8 in
> drivers/ata/ahci.c, but of type int in board/highbank/ahci.c.
>
> There is no reason in using u8, and the code using this function
> actually passes an int variable into the function (so it is implicitly
> converted to u8).
>
> Change the type of this parameter to int in drivers/ata/ahci.c.
>
> Signed-off-by: Marek Behún 
> ---
>  drivers/ata/ahci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH u-boot 32/39] ARM: fix LTO for rockchip and samsung

2021-03-09 Thread Bin Meng
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún  wrote:
>
> When building with LTO, the compiler complains about type mismatch of
> function usb_gadget_handle_interrupts(). This function is defined
> without parameters in files
>   arch/arm/mach-rockchip/board.c
>   board/samsung/common/exynos5-dt.c
> but it should have one parameter, int index.
>
> Fix this.
>
> Signed-off-by: Marek Behún 
> ---
>  arch/arm/mach-rockchip/board.c| 2 +-
>  board/samsung/common/exynos5-dt.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH u-boot 30/39] ARM: imx6m: fix imx_eqos_txclk_set_rate() type mismatch for LTO

2021-03-09 Thread Bin Meng
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún  wrote:
>
> When building imx8mp_evk_defconfig with LTO, the compiler complains
> about type mismatch of function imx_eqos_txclk_set_rate() in file
>   drivers/net/dwc_eth_qos.c:845:12
> which contains a weak definition of this function, vs file
>   arch/arm/mach-imx/imx8m/clock_imx8mm.c
> which contains an implementation.
>
> Change the type of this function in the implementation to fix this.
>
> Signed-off-by: Marek Behún 
> ---
>  arch/arm/mach-imx/imx8m/clock_imx8mm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH u-boot 29/39] ARM: kona: fix clk_bsc_enable() type mismatch for LTO

2021-03-09 Thread Bin Meng
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún  wrote:
>
> When building with LTO, the compiler complains about type mismatch of
> function clk_bsc_enable() in file:
>   arch/arm/cpu/armv7/kona-common/clk-stubs.c
> vs other files that define or use this function:
>   warning: type of ‘clk_bsc_enable’ does not match original declaration.
>
> Change the type of this function to that of the other usages.
>
> Signed-off-by: Marek Behún 
> ---
>  arch/arm/cpu/armv7/kona-common/clk-stubs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH u-boot 26/39] ARM: fix LTO for imx28_xea

2021-03-09 Thread Bin Meng
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún  wrote:
>
> When imx28_xea_defconfig is built with LTO, the compiler complains about
> the two different declarations of _start:
>include/asm-generic/sections.has  extern void _start(void);
>arch/arm/cpu/arm926ejs/mxs/mxs.c  as  extern uint32_t _start;
>
> Fix this.
>
> Signed-off-by: Marek Behún 
> ---
>  arch/arm/cpu/arm926ejs/mxs/mxs.c  | 2 +-
>  arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH u-boot 22/39] sandbox: enable LTO by default

2021-03-09 Thread Bin Meng
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún  wrote:
>
> Build sandbox targets with LTO by default.
>
> Signed-off-by: Marek Behún 
> ---
>  arch/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>

Reviewed-by: Bin Meng 


Re: [PATCH u-boot 21/39] sandbox: make LTO available

2021-03-09 Thread Bin Meng
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún  wrote:
>
> Make LTO available for sandbox architecture.
>
> Signed-off-by: Marek Behún 
> ---
>  arch/Kconfig   | 1 +
>  arch/sandbox/config.mk | 2 ++
>  2 files changed, 3 insertions(+)
>

Reviewed-by: Bin Meng 


[PATCH v2] rtc: add support for rv3028 rtc

2021-03-09 Thread Heiko Schocher
Add support for rtc3028 rtc from microcrystal.
based on linux dirver:
commit a38fd8748464: ("Linux 5.12-rc2")

Signed-off-by: Heiko Schocher 

Reviewed-by: Stefan Roese 
---
Driver is based on code in linux, but with already
corrected weekday usage. Linux codes the weekday
bitwise, while the weekday register has only 3 valid
bits as the app manual [1] says:

This register holds the current day of the week. Each value represents
one weekday that is assigned by the user. Values will range from 0 to 6
The weekday counter is simply a 3-bit counter which counts up to 6
and then resets to 0.

[1] 
https://www.microcrystal.com/fileadmin/Media/Products/RTC/App.Manual/RV-3028-C7_App-Manual.pdf

This is not a big problem, as userspace never use weekday.
Nevertheless, sent an update for the linux driver also:

https://marc.info/?l=linux-rtc&m=161529769106774&w=2

azure build:
https://dev.azure.com/hs0298/hs/_build/results?buildId=64&view=results

Changes in v2:
- add comments from Stefan
  - start sentence with upper-case
  - remove not needed includes, thanks!
- add Reviewed-by from Stefan

 drivers/rtc/Kconfig  |   6 ++
 drivers/rtc/Makefile |   1 +
 drivers/rtc/rv3028.c | 208 +++
 3 files changed, 215 insertions(+)
 create mode 100644 drivers/rtc/rv3028.c

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index aa6d90158c..e451308b40 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -95,6 +95,12 @@ config RTC_PCF8563
  If you say yes here you get support for the Philips PCF8563 RTC
  and compatible chips.
 
+config RTC_RV3028
+   bool "Enable RV3028 driver"
+   depends on DM_RTC
+   help
+ The MicroCrystal RV3028 is a I2C Real Time Clock (RTC)
+
 config RTC_RV3029
bool "Enable RV3029 driver"
depends on DM_RTC
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 6a45a9c874..e7acd76266 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_RTC_PCF2127) += pcf2127.o
 obj-$(CONFIG_RTC_PL031) += pl031.o
 obj-$(CONFIG_RTC_PT7C4338) += pt7c4338.o
 obj-$(CONFIG_RTC_RS5C372A) += rs5c372.o
+obj-$(CONFIG_RTC_RV3028) += rv3028.o
 obj-$(CONFIG_RTC_RV3029) += rv3029.o
 obj-$(CONFIG_RTC_RV8803) += rv8803.o
 obj-$(CONFIG_RTC_RX8025) += rx8025.o
diff --git a/drivers/rtc/rv3028.c b/drivers/rtc/rv3028.c
new file mode 100644
index 00..9f63afc14a
--- /dev/null
+++ b/drivers/rtc/rv3028.c
@@ -0,0 +1,208 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * RTC driver for the Micro Crystal RV3028
+ *
+ * based on linux driver from
+ * Copyright (C) 2019 Micro Crystal SA
+ *
+ * Alexandre Belloni 
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#define RV3028_SEC 0x00
+#define RV3028_MIN 0x01
+#define RV3028_HOUR0x02
+#define RV3028_WDAY0x03
+#define RV3028_DAY 0x04
+#define RV3028_MONTH   0x05
+#define RV3028_YEAR0x06
+#define RV3028_ALARM_MIN   0x07
+#define RV3028_ALARM_HOUR  0x08
+#define RV3028_ALARM_DAY   0x09
+#define RV3028_STATUS  0x0E
+#define RV3028_CTRL1   0x0F
+#define RV3028_CTRL2   0x10
+#define RV3028_EVT_CTRL0x13
+#define RV3028_TS_COUNT0x14
+#define RV3028_TS_SEC  0x15
+#define RV3028_RAM10x1F
+#define RV3028_EEPROM_ADDR 0x25
+#define RV3028_EEPROM_DATA 0x26
+#define RV3028_EEPROM_CMD  0x27
+#define RV3028_CLKOUT  0x35
+#define RV3028_OFFSET  0x36
+#define RV3028_BACKUP  0x37
+
+#define RV3028_STATUS_PORF BIT(0)
+#define RV3028_STATUS_EVF  BIT(1)
+#define RV3028_STATUS_AF   BIT(2)
+#define RV3028_STATUS_TF   BIT(3)
+#define RV3028_STATUS_UF   BIT(4)
+#define RV3028_STATUS_BSF  BIT(5)
+#define RV3028_STATUS_CLKF BIT(6)
+#define RV3028_STATUS_EEBUSY   BIT(7)
+
+#define RV3028_CLKOUT_FD_MASK  GENMASK(2, 0)
+#define RV3028_CLKOUT_PORIEBIT(3)
+#define RV3028_CLKOUT_CLKSYBIT(6)
+#define RV3028_CLKOUT_CLKOEBIT(7)
+
+#define RV3028_CTRL1_EERD  BIT(3)
+#define RV3028_CTRL1_WADA  BIT(5)
+
+#define RV3028_CTRL2_RESET BIT(0)
+#define RV3028_CTRL2_12_24 BIT(1)
+#define RV3028_CTRL2_EIE   BIT(2)
+#define RV3028_CTRL2_AIE   BIT(3)
+#define RV3028_CTRL2_TIE   BIT(4)
+#define RV3028_CTRL2_UIE   BIT(5)
+#define RV3028_CTRL2_TSE   BIT(7)
+
+#define RV3028_EVT_CTRL_TSRBIT(2)
+
+#define RV3028_EEPROM_CMD_UPDATE   0x11
+#define RV3028_EEPROM_CMD_WRITE0x21
+#define RV3028_EEPROM_CMD_READ 0x22
+
+#define RV3028_EEBUSY_POLL

Re: [IMPORTANT] gitlab relocation / rename

2021-03-09 Thread Wolfgang Denk
Dear Henning,

In message <20210308083457.76db0...@md1za8fc.ad001.siemens.net> you wrote:
>
> I do not understand why this is not just gitlab (proper) or github. I
> hope this discussion was held with the communities of the affected
> projects involved. While being disruptive i would suggest for Xenomai
> to move away from denx. For the git side of the operations. To be more
> open and welcoming to users/contributers etc.

Are you positively sure that moving to any otherhosting environment
will have any positive effect on how the Xenomai community works?

We use the very same setup for U-Boot as well, which has a _much_
bigger and _much_ more active community.  We have regular releases
every 3 months, and most releases include commits from >200
developers from >30 employers.  And the CI setup for U-Boot is in no
respect (number of supported architectures / processors / boards /
tool chains) less challenging than what you do in Xenomai, on
contrary.  Not to mention the development rate - U-Boot sees > 20
commits per day in mainline.

Sorry, but I don't buy your "more open and welcoming to users/contri-
buters" comment.  THe existing environment has proven to work fine
for a FOSS community project.

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
Someone who thinks logically is a nice contrast to the real world.


  1   2   >