Re: [PATCH v2 4/5] i2c: i2c_cdns: Enable i2c clock

[Heiko Schocher]

Hello Michal,

On 10.02.21 13:42, Michal Simek wrote:
> From: T Karthik Reddy 
> 
> Enable i2c controller clock from driver probe function
> by calling clk_enable().
> 
> Signed-off-by: T Karthik Reddy 
> Signed-off-by: Michal Simek 
> ---
> 
> (no changes since v1)
> 
>  drivers/i2c/i2c-cdns.c | 7 +++
>  1 file changed, 7 insertions(+)

Reviewed-by: Heiko Schocher 

Thanks!

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

Re: [PATCH 14/25] arm: Remove sheevaplug board

[Rick Thomas]

On Wed, Feb 10, 2021, at 8:57 PM, Vagrant Cascadian wrote:
> On 2021-02-10, Rick Thomas wrote:
> > I have not recently (since before 2019) done anything more than allow
> > aptitude to upgrade packages as it thinks best.  In particular, I have
> > not made any attempt to burn new firmware on the device.
> 
> The debian u-boot packages do not automatically upgrade the u-boot
> installed to the device; it requires manual intervention on the part of
> the system administrator above and beyond just upgrading the debian
> packages through apt, aptitude, etc.
> 
> I think u-boot upstream is talking about dropping it for 2021.04, so my
> guess is you would still have another entire debian release cycle with
> the available 2021.01 version of u-boot *if* that version still works...

If you can point me to instructions for doing that manual intervention, I'll be 
happy to test whatever version you recommend,  I hope the instructions also 
include how to recover if it *doesn't* work!

Enjoy!
Rick

Re: [PATCH 14/25] arm: Remove sheevaplug board

[Vagrant Cascadian]

On 2021-02-10, Rick Thomas wrote:
> On Wed, Feb 10, 2021, at 5:55 PM, Tom Rini wrote:
>> On Wed, Feb 10, 2021 at 05:01:47PM -0800, Rick Thomas wrote:
>> > On Wed, Feb 10, 2021, at 12:15 PM, Tom Rini wrote:
>> > > I assume that however you're building U-Boot the warnings that get
>> > > printed about conversion deadlines having come and gone are hidden in
>> > > some way or another.

I definitely see some warnings in the build logs, but try to get other
people to help with testing and maintaining them in Debian and for most
boards there is someone listed who has offered to test new versions:

  https://salsa.debian.org/debian/u-boot/-/blob/master/debian/targets

Unfortunately, mostly I only have evidence of boards I and a few other
people have tested:

  https://wiki.debian.org/U-boot/Status

If you use Debian and want the u-boot package to work for your favorite
platform working the next release, it would be a really good time to
test the packaged u-boot in Debian bullseye Real Soon Now. :)


>> > I used to have my sheevaplug's serial console hooked up to a nearby
>> > PC.  But the PC died a year or so ago, so I don't have any way to
>> > watch the messages at boot time.  If I need to reboot it, I just
>> > ssh to it, type "sudo shutdown -r now" and pray.  It hasn't failed
>> > me yet (knock wood!).  If it starts to fail, I'll have to find
>> > another PC to hook up the serial console to, but I figure I'll
>> > cross that bridge when I come to it.
>> > 
>> > Now, if anybody wanted me to test a new bit of software on it, I'd
>> > have some incentive.
>> 
>> To be clear, have you been updating U-Boot on the device?
>
> I'm not sure.  If it helps, here's what aptitude thinks is installed:
>
> rbthomas@sheeva:~$ aptitude versions u-boot
> i   2019.01+dfsg-7  stable  500 
>
> I have not recently (since before 2019) done anything more than allow
> aptitude to upgrade packages as it thinks best.  In particular, I have
> not made any attempt to burn new firmware on the device.

The debian u-boot packages do not automatically upgrade the u-boot
installed to the device; it requires manual intervention on the part of
the system administrator above and beyond just upgrading the debian
packages through apt, aptitude, etc.

I think u-boot upstream is talking about dropping it for 2021.04, so my
guess is you would still have another entire debian release cycle with
the available 2021.01 version of u-boot *if* that version still works...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: [V2 2/3] ARM: mvebu: helios4 dts changes to enable SPI

[Stefan Roese]

Hi Dennis,

On 10.02.21 20:28, Dennis Gilmore wrote:

could I please get someone to review this patch

Dennis


It's already included in mainline. I pulled it in a few days ago.
Please check if something else is missing.

Thanks,
Stefan


On Tue, Dec 8, 2020 at 9:07 PM  wrote:


From: Dennis Gilmore 

Move all aliases defintions into the main dts file
Add u-boot definiton to i2c0 based on clearfog
set spi1 status to okay

Signed-off-by: Dennis Gilmore 
---
  arch/arm/dts/armada-388-helios4-u-boot.dtsi | 23 -
  arch/arm/dts/armada-388-helios4.dts | 14 -
  2 files changed, 26 insertions(+), 11 deletions(-)

diff --git a/arch/arm/dts/armada-388-helios4-u-boot.dtsi 
b/arch/arm/dts/armada-388-helios4-u-boot.dtsi
index 0753889854..1047c1af23 100644
--- a/arch/arm/dts/armada-388-helios4-u-boot.dtsi
+++ b/arch/arm/dts/armada-388-helios4-u-boot.dtsi
@@ -1,13 +1,5 @@
  // SPDX-License-Identifier: GPL-2.0+

-/ {
-   aliases {
-   i2c0 = 
-   i2c1 = 
-   spi1 = 
-   };
-};
-
   {
 phy-reset-gpios = < 19 GPIO_ACTIVE_LOW>;
  };
@@ -20,7 +12,6 @@
  };

   {
-   status = "okay";
 u-boot,dm-spl;
  };

@@ -37,5 +28,17 @@
  };

   {
-   u-boot,dm-spl;
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+
+   eeprom@52 {
+   u-boot,dm-spl;
+   };
+
+   eeprom@53 {
+   u-boot,dm-spl;
+   };
  };
diff --git a/arch/arm/dts/armada-388-helios4.dts 
b/arch/arm/dts/armada-388-helios4.dts
index fb49df2a3b..cbc296a46c 100644
--- a/arch/arm/dts/armada-388-helios4.dts
+++ b/arch/arm/dts/armada-388-helios4.dts
@@ -22,10 +22,14 @@
 };

 aliases {
-   /* So that mvebu u-boot can update the MAC addresses */
+   /* So that mvebu u-boot can update the MAC address */
 ethernet1 = 
+   spi1 = 
+   i2c0 = 
+   i2c1 = 
 };

+
 chosen {
 stdout-path = "serial0:115200n8";
 };
@@ -306,3 +310,11 @@
 };
 };
  };
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
--
2.28.0




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 14/25] arm: Remove sheevaplug board

[Rick Thomas]

On Wed, Feb 10, 2021, at 5:55 PM, Tom Rini wrote:
> On Wed, Feb 10, 2021 at 05:01:47PM -0800, Rick Thomas wrote:
> > On Wed, Feb 10, 2021, at 12:15 PM, Tom Rini wrote:
> > > I assume that however you're building U-Boot the warnings that get
> > > printed about conversion deadlines having come and gone are hidden in
> > > some way or another.
> > 
> > I used to have my sheevaplug's serial console hooked up to a nearby PC.  
> > But the PC died a year or so ago, so I don't have any way to watch the 
> > messages at boot time.  If I need to reboot it, I just ssh to it,  type 
> > "sudo shutdown -r now" and pray.  It hasn't failed me yet (knock wood!).  
> > If it starts to fail, I'll have to find another PC to hook up the serial 
> > console to, but I figure I'll cross that bridge when I come to it.
> > 
> > Now, if anybody wanted me to test a new bit of software on it, I'd have 
> > some incentive.
> 
> To be clear, have you been updating U-Boot on the device?

I'm not sure.  If it helps, here's what aptitude thinks is installed:

rbthomas@sheeva:~$ aptitude versions u-boot
i   2019.01+dfsg-7
stable500 

I have not recently (since before 2019) done anything more than allow aptitude 
to upgrade packages as it thinks best.  In particular, I have not made any 
attempt to burn new firmware on the device.

Does that help?
Rick

Re: [PATCH 14/25] arm: Remove sheevaplug board

[Tom Rini]

On Wed, Feb 10, 2021 at 05:01:47PM -0800, Rick Thomas wrote:
> On Wed, Feb 10, 2021, at 12:15 PM, Tom Rini wrote:
> > I assume that however you're building U-Boot the warnings that get
> > printed about conversion deadlines having come and gone are hidden in
> > some way or another.
> 
> I used to have my sheevaplug's serial console hooked up to a nearby PC.  But 
> the PC died a year or so ago, so I don't have any way to watch the messages 
> at boot time.  If I need to reboot it, I just ssh to it,  type "sudo shutdown 
> -r now" and pray.  It hasn't failed me yet (knock wood!).  If it starts to 
> fail, I'll have to find another PC to hook up the serial console to, but I 
> figure I'll cross that bridge when I come to it.
> 
> Now, if anybody wanted me to test a new bit of software on it, I'd have some 
> incentive.

To be clear, have you been updating U-Boot on the device?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 14/25] arm: Remove sheevaplug board

[Rick Thomas]

On Wed, Feb 10, 2021, at 12:15 PM, Tom Rini wrote:
> I assume that however you're building U-Boot the warnings that get
> printed about conversion deadlines having come and gone are hidden in
> some way or another.

I used to have my sheevaplug's serial console hooked up to a nearby PC.  But 
the PC died a year or so ago, so I don't have any way to watch the messages at 
boot time.  If I need to reboot it, I just ssh to it,  type "sudo shutdown -r 
now" and pray.  It hasn't failed me yet (knock wood!).  If it starts to fail, 
I'll have to find another PC to hook up the serial console to, but I figure 
I'll cross that bridge when I come to it.

Now, if anybody wanted me to test a new bit of software on it, I'd have some 
incentive.

Enjoy!
Rick

Re: [PATCH 14/25] arm: Remove sheevaplug board

[Rick Thomas]

On Wed, Feb 10, 2021, at 12:15 PM, Tom Rini wrote:
> On Wed, Feb 10, 2021 at 12:09:06PM -0800, Rick Thomas wrote:
> 
> > If you decide to do this, please make sure you advertise it more
> > widely than just this list.
> > 
> > I have a sheevaplug that I'd be sad to have to decommission.  For the
> > last decade, with never a complaint, it's been happily  serving DHCP,
> > DNS, and NTP to about 20 machines in my home network.  I like it
> > because the slightly unusual architecture makes it slightly less
> > attractive as a target to the bad-guys out there.
> > 
> > Maybe I'll replace it with a Raspberry Pi.
> 
> I'm quite happy to keep the board, if someone will step up and maintain
> it.  It's had the initial conversion to DM done, but it needs a number
> of others still.  Almost all of the drivers it uses have been converted
> already (the IDE driver being the exception).
> 
> I assume that however you're building U-Boot the warnings that get
> printed about conversion deadlines having come and gone are hidden in
> some way or another.

Sad to say, I don't have the skills to step up and maintain it myself.  Though 
I'll be happy to participate in the effort as a willing (nay, eager) tester of 
new versions.  I've got a second sheevaplug sitting on a shelf that somehow 
bricked itself about 5-7 years ago.  I'd love to try to resurrect it, if 
somebody can point me to instructions for re-flashing the firmware.  If I can 
get it running, it will be perfect for use as a testing machine.

Thanks!
Rick

[PATCH] tools: fdtgrep: Use unsigned chars for arrays

[Samuel Dionne-Riel]

Otherwise, values over 127 end up prefixed with ff.

Signed-off-by: Samuel Dionne-Riel 
Cc: Simon Glass 
---

Minimal reproduction:

```
// repro.dts
/dts-v1/;

/ {
ra = [ 7f ];
rb = [ 80 ];
};
```

Steps used to compile:

 $ dtc repro.dts > repro.dtb

Without the fix:

 $ fdtgrep --include-node / repro.dtb
/ {
ra = [7f];
rb = [ff80];
};

With the fix:

 $ fdtgrep --include-node / repro.dtb
/ {
ra = [7f];
rb = [80];
};

---

 tools/fdtgrep.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/fdtgrep.c b/tools/fdtgrep.c
index e4112b8f69..db512465db 100644
--- a/tools/fdtgrep.c
+++ b/tools/fdtgrep.c
@@ -213,7 +213,7 @@ static void utilfdt_print_data(const char *data, int len)
} else {
printf(" = [");
for (i = 0; i < len; i++)
-   printf("%02x%s", *p++, i < len - 1 ? " " : "");
+   printf("%02x%s", (unsigned char)*p++, i < len - 1 ? " " 
: "");
printf("]");
}
 }
-- 
2.29.2

Re: [PATCH v2 1/1] timer: imx-gpt: Add timer support for i.MX SoCs family

[Giulio Benetti]

Hi Jesse, Sean,

On 2/10/21 9:13 PM, Giulio Benetti wrote:
[SNIP]

   >
   >
   >> +if ((int)rate <= 0) {
   >
   > This is a cast trying to solve the problem above but it's
   > not correct. clk_get_rate() returns ulong, not int, so modify "int rate"
   > into "ulong rate".
   >
   >> +dev_err(dev, "Could not get clock rate...\n");
   >> +return -EINVAL;
   >> +}
   >> +/* Only support 24MHz clock */
   >
   > Extend to /* Only support 24MHz crystal clock */ otherwise it seems that
   > every 24Mhz clock is accepted and it's not that way.
   >
   > I don't know a sure way to be bounded to crystal clock, suggestions are
   > welcome.

Why is it necessary? What are the constraints which require only using
the 24MHz reference?


To tell the truth there are no constraints, the reason is that I'm
trying to keep this driver compatible and reusable by imx6* and imx7*
since they setup the timer this way:
https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-imx/timer.c#L80-99

But if this timer needs to support any kind of clock source then let's
modify it, but it gets more complicated and I think it could be done if
needed.


This is the Linux way to make it work even if clock source is not 24Mhz:
https://github.com/torvalds/linux/blob/master/drivers/clocksource/timer-imx-gpt.c#L314-L329

It checks if clock source is 24Mhz and set CLKSRC(named V2_TPRER_PRE24M) 
to IPG_CLK_24M(named MXC_TPRER). Otherwise it uses peripheral clock and 
that's all.


At this point it's easier than I thought.

Jesse, can you please add that handling imitating Linux driver?

Best regards
--
Giulio Benetti
Benetti Engineering sas

Re: [PATCH u-boot] fs: btrfs: do not fail when offset of a ROOT_ITEM is not -1

[Qu Wenruo]

On 2021/2/11 上午12:21, Marek Behun wrote:

On Wed, 10 Feb 2021 09:20:11 +0800
Qu Wenruo  wrote:


You're correct, the kernel is using new schema, btrfs_get_fs_root(),
which only requires root objectid and completely get rid of the
offset/type, which is far less possible to call with wrong parameters.

It would be a good timing to sync the code between kernel and
progs/u-boot now.


So do you agree with this patch? If so, can you add Reviewed-by? Thanks.


I mean, to change btrfs-progs interface to follow kernel
btrfs_get_fs_root() schema, just pass objectid, without the need for
btrfs_key.

Thanks,
Qu

[PULL] u-boot-usb/master

[Marek Vasut]

The following changes since commit c7182c02cefb11431a79a8abb4d8a821e4a478b5:

  Merge tag 'u-boot-amlogic-20210210' of 
https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic (2021-02-10 
07:56:57 -0500)


are available in the Git repository at:

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

for you to fetch changes up to db8fb2ffc4f3f63b9005f676ab3879a06de6cdda:

  usb: dwc2: change compatible st,stm32mp1-hsotg to st,stm32mp15-hsotg 
(2021-02-10 22:23:35 +0100)



Chunfeng Yun (2):
  usb: xhci-mtk: support option to disable ports
  dt-bindings: usb: mtk-xhci: add optional properies to disable ports

Pali Rohár (1):
  usb: xhci-pci: Check for errors from dm_pci_map_bar()

Patrick Delaunay (1):
  usb: dwc2: change compatible st,stm32mp1-hsotg to st,stm32mp15-hsotg

Stefan Roese (1):
  usb: xhci: Fix compare to use physical addresses in xhci_bulk_tx()

 arch/arm/dts/stm32mp15-u-boot.dtsi |  3 ---
 doc/device-tree-bindings/usb/mediatek,mtk-xhci.txt |  4 
 drivers/usb/gadget/dwc2_udc_otg.c  |  2 +-
 drivers/usb/host/xhci-mtk.c| 23 
---

 drivers/usb/host/xhci-pci.c| 15 ---
 drivers/usb/host/xhci-ring.c   |  4 ++--
 6 files changed, 39 insertions(+), 12 deletions(-)

[PATCH] fpga: zynqpl: fix buffer alignment

[Michael Walle]

Due to pointer arithmetic, "sizeof(u32) * ARCH_DMA_MINALIGN" is
subtracted. It seems that the original intention was to just subtract
ARCH_DMA_MINALIGN. Fix it.

Signed-off-by: Michael Walle 
---
 drivers/fpga/zynqpl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/fpga/zynqpl.c b/drivers/fpga/zynqpl.c
index a11e485525..2de40109a8 100644
--- a/drivers/fpga/zynqpl.c
+++ b/drivers/fpga/zynqpl.c
@@ -315,7 +315,7 @@ static u32 *zynq_align_dma_buffer(u32 *buf, u32 len, u32 
swap)
if (new_buf > buf) {
debug("%s: Aligned buffer is after buffer start\n",
  __func__);
-   new_buf -= ARCH_DMA_MINALIGN;
+   new_buf = (u32 *)((u32)new_buf - ARCH_DMA_MINALIGN);
}
printf("%s: Align buffer at %x to %x(swap %d)\n", __func__,
   (u32)buf, (u32)new_buf, swap);
-- 
2.20.1

[PATCH] net: gem: unregister mdio bus if probe fails

[Michael Walle]

If probe fails, the mdio bus isn't unregistered. Fix it.

Signed-off-by: Michael Walle 
---
 drivers/net/zynq_gem.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 5cb02bb3a7..585c06d6bd 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -711,10 +711,12 @@ static int zynq_gem_probe(struct udevice *dev)
 
ret = zynq_phy_init(dev);
if (ret)
-   goto err2;
+   goto err3;
 
return ret;
 
+err3:
+   mdio_unregister(priv->bus);
 err2:
free(priv->rxbuffers);
 err1:
-- 
2.20.1

Re: [PATCH v2 1/1] sandbox: allow cross-compiling sandbox

[Simon Glass]

On Wed, 10 Feb 2021 at 10:59, Heinrich Schuchardt  wrote:
>
> UEFI test files like helloworld.efi require an architecture specific
> PE-COFF header.
>
> Currently this does not work for cross compiling. If $CROSS_COMPILE is set,
> use the first part of the architecture triplet from the variable to
> choose the PE-COFF header.
>
> Now we can cross-compile the sandbox, e.g.
>
> make sandbox_defconfig NO_SDL=1
> CROSS_COMPILE=/opt/bin/aarch64-linux-gnu- NO_SDL=1 MK_ARCH=aarch64 make
>
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
> use $CROSS_COMPILE instead of an extra environment variable
> ---
>  Makefile | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH 1/1] malloc: adjust memcpy() and memset() definitions.

[Simon Glass]

On Wed, 10 Feb 2021 at 10:59, Heinrich Schuchardt  wrote:
>
> Compiling the sandbox fails on armv7 due to conflicting definitions of
> memcpy() and memset() in include/malloc.h and include/linux/string.h.
>
> Use linux/string.h here.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/malloc.h | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Simon Glass 

Re: [PATCH u-boot] cmd: pinmux: depend on PINCTRL

[Simon Glass]

On Tue, 9 Feb 2021 at 13:24, Marek Behún  wrote:
>
> The pinmux command uses functions pinctrl_get_pin_*(), which are missing
> if PINCTRL config option is disabled.
>
> Signed-off-by: Marek Behún 
> Cc: Simon Glass 
> Cc: Tom Rini 
> ---
>  cmd/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>

Reviewed-by: Simon Glass 

Re: [PATCH] usb: dwc2: change compatible st,stm32mp1-hsotg to st,stm32mp15-hsotg

[Marek Vasut]

On 2/9/21 8:51 PM, Patrick DELAUNAY wrote:


On 2/9/21 11:39 AM, Marek Vasut wrote:

On 2/9/21 11:14 AM, Patrick Delaunay wrote:
Hi,

[...]

diff --git a/drivers/usb/gadget/dwc2_udc_otg.c 
b/drivers/usb/gadget/dwc2_udc_otg.c

index e3871e381e..ecac80fc11 100644
--- a/drivers/usb/gadget/dwc2_udc_otg.c
+++ b/drivers/usb/gadget/dwc2_udc_otg.c
@@ -1176,7 +1176,7 @@ static int dwc2_udc_otg_remove(struct udevice 
*dev)

  static const struct udevice_id dwc2_udc_otg_ids[] = {
  { .compatible = "snps,dwc2" },
  { .compatible = "brcm,bcm2835-usb" },
-    { .compatible = "st,stm32mp1-hsotg",
+    { .compatible = "st,stm32mp15-hsotg",
    .data = (ulong)dwc2_set_stm32mp1_hsotg_params },


I have to point out the obvious, DT is ABI, this breaks ABI. However, 
do we care about out-of-tree DTs here ?



I know that the binding backward compatibility and "binary compatible" 
the is a key element of DT


for the Linux kernel (for example the latest kernel image should work 
with a old device tree).



I don't see the same requirement for U-Boot as external DT (with EXT_DTB 
option) is not common .



So today I assume that U-Boot use only in-tree DT for stm32mp15 
platforms until we have a


100% upstream level of the stm32mp1 platform with binding aligned with 
Linux kernel bindings


(for example we have some other pending issue for USBPHYC binding).


But if backward compatibility is really blocking for U-Boot user, I can 
change my mind.



PS: I correct a issue here, because I upstream the stm32mp downstream 
binding for dwc2,


but this compatible had be modified before accepted by Linux kernel DT 
maintaineers


=> today USB in Linux kernel can't work with the DT used by U-Boot


All right, applied, thanks.

Re: [V2 2/3] ARM: mvebu: helios4 dts changes to enable SPI

[Tom Rini]

On Wed, Feb 10, 2021 at 01:28:33PM -0600, Dennis Gilmore wrote:

> could I please get someone to review this patch

Do the changes in armada-388-helios4.dts bring us more in sync with the
Linux kernel side?  Thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 14/25] arm: Remove sheevaplug board

[Rick Thomas]

If you decide to do this, please make sure you advertise it more widely than 
just this list.

I have a sheevaplug that I'd be sad to have to decommission.  For the last 
decade, with never a complaint, it's been happily  serving DHCP, DNS, and NTP 
to about 20 machines in my home network.  I like it because the slightly 
unusual architecture makes it slightly less attractive as a target to the 
bad-guys out there.

Maybe I'll replace it with a Raspberry Pi.

Oh well:  To everything there is a season...

Rick


On Tue, Feb 9, 2021, at 11:07 PM, Chris Packham wrote:
> On Wed, 10 Feb 2021, 2:07 AM Tom Rini,  wrote:
> 
> > This board has not been converted to CONFIG_DM_MMC by the deadline of
> > v2019.04, which is almost two years ago.  In addition there are other DM
> > migrations it is also missing.  Remove it.
> >
> 
> We did get the odd bug report from debian for sheevaplug. They were
> reasonably popular with enthusiasts at one point. Personally I wouldn't
> miss this board but it might be worth a heads up (hence adding Vagrant C.
> to the Cc).
> 
> 
> > Cc: Prafulla Wadaskar 
> > Signed-off-by: Tom Rini 
> > ---
> >  arch/arm/dts/Makefile|   3 +-
> >  arch/arm/dts/kirkwood-sheevaplug-common.dtsi | 104 --
> >  arch/arm/dts/kirkwood-sheevaplug.dts |  42 --
> >  arch/arm/mach-kirkwood/Kconfig   |   4 -
> >  board/Marvell/sheevaplug/Kconfig |  12 --
> >  board/Marvell/sheevaplug/MAINTAINERS |   6 -
> >  board/Marvell/sheevaplug/Makefile|   7 -
> >  board/Marvell/sheevaplug/kwbimage.cfg| 144 ---
> >  board/Marvell/sheevaplug/sheevaplug.c| 135 -
> >  board/Marvell/sheevaplug/sheevaplug.h|  24 
> >  configs/sheevaplug_defconfig |  55 ---
> >  include/configs/sheevaplug.h |  73 --
> >  12 files changed, 1 insertion(+), 608 deletions(-)
> >  delete mode 100644 arch/arm/dts/kirkwood-sheevaplug-common.dtsi
> >  delete mode 100644 arch/arm/dts/kirkwood-sheevaplug.dts
> >  delete mode 100644 board/Marvell/sheevaplug/Kconfig
> >  delete mode 100644 board/Marvell/sheevaplug/MAINTAINERS
> >  delete mode 100644 board/Marvell/sheevaplug/Makefile
> >  delete mode 100644 board/Marvell/sheevaplug/kwbimage.cfg
> >  delete mode 100644 board/Marvell/sheevaplug/sheevaplug.c
> >  delete mode 100644 board/Marvell/sheevaplug/sheevaplug.h
> >  delete mode 100644 configs/sheevaplug_defconfig
> >  delete mode 100644 include/configs/sheevaplug.h
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index b8f88bca0af9..12a74ed0eb08 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -58,8 +58,7 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += \
> > kirkwood-ns2lite.dtb \
> > kirkwood-ns2max.dtb \
> > kirkwood-ns2mini.dtb \
> > -   kirkwood-pogo_e02.dtb \
> > -   kirkwood-sheevaplug.dtb
> > +   kirkwood-pogo_e02.dtb
> >
> >  dtb-$(CONFIG_MACH_S900) += \
> > bubblegum_96.dtb
> > diff --git a/arch/arm/dts/kirkwood-sheevaplug-common.dtsi
> > b/arch/arm/dts/kirkwood-sheevaplug-common.dtsi
> > deleted file mode 100644
> > index 0a698d3b7393..
> > --- a/arch/arm/dts/kirkwood-sheevaplug-common.dtsi
> > +++ /dev/null
> > @@ -1,104 +0,0 @@
> > -// SPDX-License-Identifier: GPL-2.0
> > -/*
> > - * kirkwood-sheevaplug-common.dtsi - Common parts for Sheevaplugs
> > - *
> > - * Copyright (C) 2013 Simon Baatz 
> > - */
> > -
> > -#include "kirkwood.dtsi"
> > -#include "kirkwood-6281.dtsi"
> > -
> > -/ {
> > -   memory {
> > -   device_type = "memory";
> > -   reg = <0x 0x2000>;
> > -   };
> > -
> > -   chosen {
> > -   bootargs = "console=ttyS0,115200n8 earlyprintk";
> > -   stdout-path = 
> > -   };
> > -
> > -   ocp@f100 {
> > -   pinctrl: pin-controller@1 {
> > -
> > -   pmx_usb_power_enable: pmx-usb-power-enable {
> > -   marvell,pins = "mpp29";
> > -   marvell,function = "gpio";
> > -   };
> > -   pmx_led_red: pmx-led-red {
> > -   marvell,pins = "mpp46";
> > -   marvell,function = "gpio";
> > -   };
> > -   pmx_led_blue: pmx-led-blue {
> > -   marvell,pins = "mpp49";
> > -   marvell,function = "gpio";
> > -   };
> > -   pmx_sdio_cd: pmx-sdio-cd {
> > -   marvell,pins = "mpp44";
> > -   marvell,function = "gpio";
> > -   };
> > -   pmx_sdio_wp: pmx-sdio-wp {
> > -   marvell,pins = "mpp47";
> > -   marvell,function = 

Re: [PATCH v5 6/6] test/py: ecdsa: Add test for mkimage ECDSA signing

[Alex G.]

On 2/1/21 2:43 PM, Simon Glass wrote:

Hi Alexandru,


[snip]


As mentioned earlier, this does need a test that checks the U-Boot
code paths. This just seems to be checking the signing process. This
likely involves implementing the verification (or a fake of it) in
sandbox.

If I am missing something, please let me know.


Yes! The test runs mkimage -F, which tests the host paths we've added. 
There's no target u-boot code in this series.



Alex

Re: [PATCH 14/25] arm: Remove sheevaplug board

[Tom Rini]

On Wed, Feb 10, 2021 at 12:09:06PM -0800, Rick Thomas wrote:

> If you decide to do this, please make sure you advertise it more
> widely than just this list.
> 
> I have a sheevaplug that I'd be sad to have to decommission.  For the
> last decade, with never a complaint, it's been happily  serving DHCP,
> DNS, and NTP to about 20 machines in my home network.  I like it
> because the slightly unusual architecture makes it slightly less
> attractive as a target to the bad-guys out there.
> 
> Maybe I'll replace it with a Raspberry Pi.

I'm quite happy to keep the board, if someone will step up and maintain
it.  It's had the initial conversion to DM done, but it needs a number
of others still.  Almost all of the drivers it uses have been converted
already (the IDE driver being the exception).

I assume that however you're building U-Boot the warnings that get
printed about conversion deadlines having come and gone are hidden in
some way or another.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 1/1] timer: imx-gpt: Add timer support for i.MX SoCs family

[Giulio Benetti]

On 2/10/21 6:52 PM, Sean Anderson wrote:



On 2/10/21 12:49 PM, Giulio Benetti wrote:
  > On 2/10/21 1:04 AM, Jesse Taube wrote:
  >> This timer driver is using GPT Timer (General Purpose Timer) available
  >> on almost all i.MX SoCs family.
  >> Since this driver is only meant to provide u-boot's timer and counter,
  >> and most of the i.MX* SoCs use a 24Mhz crystal, let's only deal with
  >> that specific source.
  >
  > We have a problem with columns on commit log, they shouldn't be longer
  > than 72 cols, so please check the editor you're using for commit log
  > writing and set 72 cols costrains. I use nano and you only need to set
  > in .gitconfig under [core]:
  > editor = nano -b -r 72
  >
  > This way nano automatically put a CR.
  >
  >>
  >> Signed-off-by: Giulio Benetti 
  >> Signed-off-by: Jesse Taube 
  >>
  >> ---
  >>   drivers/timer/Kconfig |   7 ++
  >>   drivers/timer/Makefile|   1 +
  >>   drivers/timer/imx-gpt-timer.c | 132 ++
  >>   3 files changed, 140 insertions(+)
  >>   create mode 100644 drivers/timer/imx-gpt-timer.c
  >>
  >> diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
  >> index 80743a2551..ee81dfa776 100644
  >> --- a/drivers/timer/Kconfig
  >> +++ b/drivers/timer/Kconfig
  >> @@ -227,4 +227,11 @@ config MCHP_PIT64B_TIMER
  >> Select this to enable support for Microchip 64-bit periodic
  >> interval timer.
  >> +config IMX_GPT_TIMER
  >> +bool "NXP i.MX GPT timer support"
  >> +depends on TIMER
  >> +help
  >> +  Select this to enable support for the timer found on
  >> +  NXP i.MX devices.
  >> +
  >>   endmenu
  >> diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
  >> index eb5c48cc6c..e214ba7268 100644
  >> --- a/drivers/timer/Makefile
  >> +++ b/drivers/timer/Makefile
  >> @@ -25,3 +25,4 @@ obj-$(CONFIG_STM32_TIMER)+= stm32_timer.o
  >>   obj-$(CONFIG_X86_TSC_TIMER)+= tsc_timer.o
  >>   obj-$(CONFIG_MTK_TIMER)+= mtk_timer.o
  >>   obj-$(CONFIG_MCHP_PIT64B_TIMER)+= mchp-pit64b-timer.o
  >> +obj-$(CONFIG_IMX_GPT_TIMER)+= imx-gpt-timer.o
  >> diff --git a/drivers/timer/imx-gpt-timer.c
  >> b/drivers/timer/imx-gpt-timer.c
  >> new file mode 100644
  >> index 00..58c37db300
  >> --- /dev/null
  >> +++ b/drivers/timer/imx-gpt-timer.c
  >> @@ -0,0 +1,132 @@
  >> +// SPDX-License-Identifier: GPL-2.0+
  >> +/*
  >> + * Copyright (C) 2020
  >> + * Author(s): Giulio Benetti 
  >> + */
  >> +
  >> +#include 
  >> +#include 
  >> +#include 
  >> +#include 
  >> +#include 
  >> +#include 
  >> +
  >> +#include 
  >> +
  >> +#define GPT_CR_SWR0x8000
  >> +#define GPT_CR_CLKSRC0x01C0
  >> +#define GPT_CR_EN_24M0x4000
  >> +#define GPT_CR_EN0x0001
  >> +#define GPT_PR_PRESCALER0x0FFF
  >> +#define GPT_PR_PRESCALER24M0xF000
  >
  > Here ^^^ and
  >
  >> +#define NO_CLOCK(0)
  >> +#define IPG_CLK(1 << 6)
  >> +#define IPG_CLK_HF(2 << 6)
  >> +#define IPG_EXT(3 << 6)
  >> +#define IPG_CLK_32K(4 << 6)
  >> +#define IPG_CLK_24M(5 << 6)
  >
  > here you still have different tab numbers. Enable in your editor the
  > option to show whitespaces and tabs, that way everything it easier.
  >
  >> +
  >> +struct imx_gpt_timer_regs {
  >> +u32 cr;
  >> +u32 pr;
  >> +u32 sr;
  >> +u32 ir;
  >> +u32 ocr1;
  >> +u32 ocr2;
  >> +u32 ocr3;
  >> +u32 icr1;
  >> +u32 icr2;
  >> +u32 cnt;
  >> +};
  >> +
  >> +struct imx_gpt_timer_priv {
  >> +struct imx_gpt_timer_regs *base;
  >> +};
  >> +
  >> +static u64 imx_gpt_timer_get_count(struct udevice *dev)
  >> +{
  >> +struct imx_gpt_timer_priv *priv = dev_get_priv(dev);
  >> +struct imx_gpt_timer_regs *regs = priv->base;
  >> +
  >> +return readl(>cnt);
  >> +}
  >> +
  >> +static int imx_gpt_timer_probe(struct udevice *dev)
  >> +{
  >> +struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
  >> +struct imx_gpt_timer_priv *priv = dev_get_priv(dev);
  >> +struct imx_gpt_timer_regs *regs;
  >> +struct clk clk;
  >> +fdt_addr_t addr;
  >> +u32 prescaler;
  >> +u32 rate;
  >> +int ret;
  >> +
  >> +addr = dev_read_addr(dev);
  >> +if (addr == FDT_ADDR_T_NONE)
  >> +return -EINVAL;
  >> +
  >> +priv->base = (struct imx_gpt_timer_regs *)addr;
  >> +
  >> +ret = clk_get_by_index(dev, 0, );
  >> +if (ret < 0)
  >> +return ret;
  >> +
  >> +ret = clk_enable();
  >> +if (ret) {
  >> +dev_err(dev, "Failed to enable clock\n");
  >> +return ret;
  >> +}
  >> +
  >> +regs = priv->base;
  >> +
  >> +/* Reset the timer */
  >> +setbits_le32(>cr, GPT_CR_SWR);
  >> +
  >> +/* Wait for timer to finish reset */
  >> +while (readl(>cr) & GPT_CR_SWR)
  >> +;
 

Re: [PATCH v2 1/1] timer: imx-gpt: Add timer support for i.MX SoCs family

[Giulio Benetti]

Hi Jesse,

I re-add all people and ML in Cc so they can follow. Next time reply to all.

On 2/10/21 8:00 PM, Jesse Taube wrote:


On 2/10/21 12:49 PM, Giulio Benetti wrote:

On 2/10/21 1:04 AM, Jesse Taube wrote:

This timer driver is using GPT Timer (General Purpose Timer)
available on almost all i.MX SoCs family.
Since this driver is only meant to provide u-boot's timer and
counter, and most of the i.MX* SoCs use a 24Mhz crystal, let's only
deal with that specific source.


We have a problem with columns on commit log, they shouldn't be longer
than 72 cols, so please check the editor you're using for commit log
writing and set 72 cols costrains. I use nano and you only need to set
in .gitconfig under [core]:
editor = nano -b -r 72

This way nano automatically put a CR.



Signed-off-by: Giulio Benetti 
Signed-off-by: Jesse Taube 

---
   drivers/timer/Kconfig |   7 ++
   drivers/timer/Makefile    |   1 +
   drivers/timer/imx-gpt-timer.c | 132 ++
   3 files changed, 140 insertions(+)
   create mode 100644 drivers/timer/imx-gpt-timer.c

diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index 80743a2551..ee81dfa776 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -227,4 +227,11 @@ config MCHP_PIT64B_TIMER
     Select this to enable support for Microchip 64-bit periodic
     interval timer.
   +config IMX_GPT_TIMER
+    bool "NXP i.MX GPT timer support"
+    depends on TIMER
+    help
+  Select this to enable support for the timer found on
+  NXP i.MX devices.
+
   endmenu
diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
index eb5c48cc6c..e214ba7268 100644
--- a/drivers/timer/Makefile
+++ b/drivers/timer/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_STM32_TIMER)    += stm32_timer.o
   obj-$(CONFIG_X86_TSC_TIMER)    += tsc_timer.o
   obj-$(CONFIG_MTK_TIMER)    += mtk_timer.o
   obj-$(CONFIG_MCHP_PIT64B_TIMER)    += mchp-pit64b-timer.o
+obj-$(CONFIG_IMX_GPT_TIMER)    += imx-gpt-timer.o
diff --git a/drivers/timer/imx-gpt-timer.c
b/drivers/timer/imx-gpt-timer.c
new file mode 100644
index 00..58c37db300
--- /dev/null
+++ b/drivers/timer/imx-gpt-timer.c
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020
+ * Author(s): Giulio Benetti 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define GPT_CR_SWR    0x8000
+#define GPT_CR_CLKSRC    0x01C0
+#define GPT_CR_EN_24M    0x4000
+#define GPT_CR_EN    0x0001
+#define GPT_PR_PRESCALER    0x0FFF
+#define GPT_PR_PRESCALER24M    0xF000


Here ^^^ and


+#define NO_CLOCK    (0)
+#define IPG_CLK    (1 << 6)
+#define IPG_CLK_HF    (2 << 6)
+#define IPG_EXT    (3 << 6)
+#define IPG_CLK_32K    (4 << 6)
+#define IPG_CLK_24M    (5 << 6)

here you still have different tab numbers. Enable in your editor the
option to show whitespaces and tabs, that way everything it easier.

I still don't exactly understand what you mean here. Should I press tab
3 times exactly instead of making the values line up. 


You need to check using an editor with whitespaces and tabs options 
enabled and tabs set to 8 spaces how that code looks like.



In the commit log
it seems to change weirdly because of the '+' in front of the define.


Here it is the same, this should be due to the editor you use for commit 
log.



+
+struct imx_gpt_timer_regs {
+    u32 cr;
+    u32 pr;
+    u32 sr;
+    u32 ir;
+    u32 ocr1;
+    u32 ocr2;
+    u32 ocr3;
+    u32 icr1;
+    u32 icr2;
+    u32 cnt;
+};
+
+struct imx_gpt_timer_priv {
+    struct imx_gpt_timer_regs *base;
+};
+
+static u64 imx_gpt_timer_get_count(struct udevice *dev)
+{
+    struct imx_gpt_timer_priv *priv = dev_get_priv(dev);
+    struct imx_gpt_timer_regs *regs = priv->base;
+
+    return readl(>cnt);
+}
+
+static int imx_gpt_timer_probe(struct udevice *dev)
+{
+    struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+    struct imx_gpt_timer_priv *priv = dev_get_priv(dev);
+    struct imx_gpt_timer_regs *regs;
+    struct clk clk;
+    fdt_addr_t addr;
+    u32 prescaler;
+    u32 rate;
+    int ret;
+
+    addr = dev_read_addr(dev);
+    if (addr == FDT_ADDR_T_NONE)
+    return -EINVAL;
+
+    priv->base = (struct imx_gpt_timer_regs *)addr;
+
+    ret = clk_get_by_index(dev, 0, );
+    if (ret < 0)
+    return ret;
+
+    ret = clk_enable();
+    if (ret) {
+    dev_err(dev, "Failed to enable clock\n");
+    return ret;
+    }
+
+    regs = priv->base;
+
+    /* Reset the timer */
+    setbits_le32(>cr, GPT_CR_SWR);
+
+    /* Wait for timer to finish reset */
+    while (readl(>cr) & GPT_CR_SWR)
+    ;
+
+    /* Get timer clock rate */
+    rate = clk_get_rate();


clk_get_rate() has a wrong description in include/clk.h saying:
"@return clock rate in Hz, or -ve error code."

This

RE: [EXTERNAL] Re: U-Boot ECDSA Implementation Question

[Tim Romanski]

Hi Alex,

Thanks for the context! What are your plans for upstreaming your ECDSA signing 
implementation? I've currently dedicated the next four weeks to getting 
signing+verification implemented, so if you'd like a helping hand either with 
any leftover signing work or to get verification started I'm happy to 
collaborate.

All the best,
Tim

-Original Message-
From: Alex G.  
Sent: February 5, 2021 11:09 AM
To: Simon Glass ; Tim Romanski 
Cc: u-boot@lists.denx.de; Deskin Miller ; Dylan D'Silva 

Subject: [EXTERNAL] Re: U-Boot ECDSA Implementation Question

Hi Tim,

On 2/5/21 8:35 AM, Simon Glass wrote:
>> I'm a current intern at Microsoft, and one of my priorities is to enable 
>> ECDSA for U-Boot image signing/verification. Simon mentioned someone is 
>> already working on ECC, it would be great to get synced up with related 
>> progress. For signing, I will likely replicate the existing approach of 
>> using the openssl library. I'm aware that signing happens on a host machine 
>> and verification happens during boot, which implies verification should have 
>> a custom implementation to avoid the openssl overhead in the U-Boot binary. 
>> My thoughts are to copy an ECC verification implementation from a 
>> well-tested widely-used open source project. I was wondering, is U-Boot's 
>> current RSA verification copied from another project? If so, how are 
>> security patches between the two copies of code usually handled? I'm 
>> thinking of deriving from the ECDSA implementation currently in the Linux 
>> kernel, though I'd also appreciate suggestions if there's a better/more 
>> widely tested & used implementation.
> 

[snip]
> 
> Alexandru Gagniuc, on cc, has been looking at implementing the signing 
> side of this recently and has sent some patches that you could look 
> at.

I hope I can save you some effort on the signing side. Generally, you have two 
types of signed images. The first is the signed bootloader (BL2 or FSBL in ARM 
terms). The other one is the signed Flattened Image Tree
(FIT) that we use in u-boot. The first one is vendor-specific, so you'd usually 
use vendor tools or write your own. We use mkimage to deal with the latter.

I've implemented the signing part [1] for mkimage. mkimage has the ability to 
use hardware signing via the PKCS11 engine of openssl, which I did not 
implement. You can read more about it here [3].

The verification part is still being defined [4][5]. The idea is to define a 
UCLASS which abstracts the underlying implementation. For RSA, it's defined 
here [6].

My goal with ECDSA verification was to use the ROM API of the STM32MP1. 
This meant I don't have to write a software implementation of ECDSA. 
This would be useful in two ways. It would enable ECDSA verification on devices 
that don't support it in hardware, and would also allow us to add some unit 
tests for ECDSA.

I suspect what you could do from here, is try to build my branch with ECDSA 
signing, play around with mkimage, and let us know how we can point you to the 
correct documentation. There's a lot of it in doc/, but it's not always easy to 
find.

Alex



[1] 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmrnuke%2Fu-boot%2Fcommits%2Fpatch-mkimage-keyfile-v1data=04%7C01%7Ct-tromanski%40microsoft.com%7C4e326c48dc2f4e89df5d08d8c9f0536f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481381320581783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=NulehqeJPXmR%2BLhHzBagWc9Uum1iFS5%2BSVlRu0L9SUU%3Dreserved=0
[2]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmrnuke%2Fu-boot%2Fcommit%2Fa2ae016f2f80579962d4ab058137c8e1a4f4741fdata=04%7C01%7Ct-tromanski%40microsoft.com%7C4e326c48dc2f4e89df5d08d8c9f0536f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481381320581783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Sa06A5TDKVxJ7sd1Dj%2FCiztHPQ%2BJBuzVbpK9mMVwMsU%3Dreserved=0
[3]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmrnuke%2Fu-boot%2Fblob%2F3f447efcf8ad98d0eea349994810a66b453ac188%2Fdoc%2FuImage.FIT%2Fsignature.txt%23L488data=04%7C01%7Ct-tromanski%40microsoft.com%7C4e326c48dc2f4e89df5d08d8c9f0536f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481381320581783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ExeKMGFCC9QX6bGAyWztqMZqMqCqGWbhgZkF8odmcKM%3Dreserved=0
[4]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmrnuke%2Fu-boot%2Fcommit%2F31caceb0e28959881e96ea49a0b28fd44d13a947data=04%7C01%7Ct-tromanski%40microsoft.com%7C4e326c48dc2f4e89df5d08d8c9f0536f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481381320581783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=QMhDdKcxviXg%2FhmXIwxpgmUKsc2aezNb3L9kZOgX198%3Dreserved=0
[5] 

[PATCH 2/2] mtd: nand: spi: Support GigaDevice GD5F1GQ5UExxG

[Reto Schneider]

From: Reto Schneider 

The relevant changes to the already existing GD5F1GQ4UExxG support has
been determined by consulting the GigaDevice product change notice
AN-0392-10, version 1.0 from November 30, 2020.

As the overlaps are huge, variable names have been generalized
accordingly.

Apart form the lowered ECC strength (4 instead of 8 bits per 512 bytes),
the new device ID, and the extra quad IO dummy byte, no changes had to
be taken into account.

New hardware features are not supported, namely:
 - Power on reset
 - Unique ID
 - Double transfer rate (DTR)
 - Parameter page
 - Random data quad IO

The inverted semantic of the "driver strength" register bits, defaulting
to 100% instead of 50% for the Q5 devices, got ignored as the driver has
never touched them anyway.

The no longer supported "read from cache during block erase"
functionality I do not know how to reflect.

Implementation has been tested on MediaTek MT7688 based GARDENA smart
Gateways using both, GigaDevice GD5F1GQ5UEYIG and GD5F1GQ4UBYIG.

Signed-off-by: Reto Schneider 
CC: Stefan Roese 
---
 drivers/mtd/nand/spi/gigadevice.c | 79 +++
 1 file changed, 69 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/nand/spi/gigadevice.c 
b/drivers/mtd/nand/spi/gigadevice.c
index 5de0ebbb7b..a2c93486f4 100644
--- a/drivers/mtd/nand/spi/gigadevice.c
+++ b/drivers/mtd/nand/spi/gigadevice.c
@@ -17,9 +17,13 @@
 #define GD5FXGQ4XA_STATUS_ECC_1_7_BITFLIPS (1 << 4)
 #define GD5FXGQ4XA_STATUS_ECC_8_BITFLIPS   (3 << 4)
 
-#define GD5FXGQ4XEXXG_REG_STATUS2  0xf0
+#define GD5FXGQ5XE_STATUS_ECC_1_4_BITFLIPS (1 << 4)
+#define GD5FXGQ5XE_STATUS_ECC_4_BITFLIPS   (3 << 4)
 
-static SPINAND_OP_VARIANTS(read_cache_variants,
+#define GD5FXGQXXEXXG_REG_STATUS2  0xf0
+
+/* Q4 devices, QUADIO: Dummy bytes valid for 1 and 2 GBit variants */
+static SPINAND_OP_VARIANTS(gd5fxgq4_read_cache_variants,
SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 1, NULL, 0),
SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 1, NULL, 0),
@@ -27,6 +31,15 @@ static SPINAND_OP_VARIANTS(read_cache_variants,
SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
 
+/* Q5 devices, QUADIO: Dummy bytes only valid for 1 GBit variants */
+static SPINAND_OP_VARIANTS(gd5f1gq5_read_cache_variants,
+   SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 2, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
+
 static SPINAND_OP_VARIANTS(write_cache_variants,
SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
SPINAND_PROG_LOAD(true, 0, NULL, 0));
@@ -35,7 +48,7 @@ static SPINAND_OP_VARIANTS(update_cache_variants,
SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
SPINAND_PROG_LOAD(false, 0, NULL, 0));
 
-static int gd5fxgq4xexxg_ooblayout_ecc(struct mtd_info *mtd, int section,
+static int gd5fxgqxxexxg_ooblayout_ecc(struct mtd_info *mtd, int section,
   struct mtd_oob_region *region)
 {
if (section)
@@ -47,7 +60,7 @@ static int gd5fxgq4xexxg_ooblayout_ecc(struct mtd_info *mtd, 
int section,
return 0;
 }
 
-static int gd5fxgq4xexxg_ooblayout_free(struct mtd_info *mtd, int section,
+static int gd5fxgqxxexxg_ooblayout_free(struct mtd_info *mtd, int section,
struct mtd_oob_region *region)
 {
if (section)
@@ -64,7 +77,7 @@ static int gd5fxgq4xexxg_ecc_get_status(struct spinand_device 
*spinand,
u8 status)
 {
u8 status2;
-   struct spi_mem_op op = SPINAND_GET_FEATURE_OP(GD5FXGQ4XEXXG_REG_STATUS2,
+   struct spi_mem_op op = SPINAND_GET_FEATURE_OP(GD5FXGQXXEXXG_REG_STATUS2,
  );
int ret;
 
@@ -102,21 +115,67 @@ static int gd5fxgq4xexxg_ecc_get_status(struct 
spinand_device *spinand,
return -EINVAL;
 }
 
-static const struct mtd_ooblayout_ops gd5fxgq4xexxg_ooblayout = {
-   .ecc = gd5fxgq4xexxg_ooblayout_ecc,
-   .rfree = gd5fxgq4xexxg_ooblayout_free,
+static int gd5fxgq5xexxg_ecc_get_status(struct spinand_device *spinand,
+   u8 status)
+{
+   u8 status2;
+   struct spi_mem_op op = SPINAND_GET_FEATURE_OP(GD5FXGQXXEXXG_REG_STATUS2,
+ );
+   int ret;
+
+   switch (status & STATUS_ECC_MASK) {
+   case STATUS_ECC_NO_BITFLIPS:
+   return 0;
+
+   case 

[PATCH 1/2] mtd: nand: spi: Only one dummy byte in QUADIO

[Reto Schneider]

From: Reto Schneider 

The datasheet only lists one dummy byte in the 0xEH operation for the
following chips:
* GD5F1GQ4xBxxG
* GD5F1GQ4xExxG
* GD5F1GQ4xFxxG
* GD5F1GQ4UAYIG
* GD5F4GQ4UAYIG

This patch and its commit message reflects what has been done in Linux
and has not been tested by me.

Signed-off-by: Reto Schneider 
CC: Stefan Roese 
---
 drivers/mtd/nand/spi/gigadevice.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/spi/gigadevice.c 
b/drivers/mtd/nand/spi/gigadevice.c
index 0b228dcb5b..5de0ebbb7b 100644
--- a/drivers/mtd/nand/spi/gigadevice.c
+++ b/drivers/mtd/nand/spi/gigadevice.c
@@ -20,7 +20,7 @@
 #define GD5FXGQ4XEXXG_REG_STATUS2  0xf0
 
 static SPINAND_OP_VARIANTS(read_cache_variants,
-   SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 2, NULL, 0),
+   SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 1, NULL, 0),
SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 1, NULL, 0),
SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
-- 
2.29.2

Re: [PATCH v2 2/2] board: imx8mp: add boot.cmd for distro boot on iMX8MP

[Stefano Babic]

Hi everybody,

On 10.02.21 20:36, Fabio Estevam wrote:

On Wed, Feb 10, 2021 at 4:28 PM Dennis Gilmore
 wrote:


Hi Stefano,

I really do not think that this patch should have been merged. It is
not the preferred way to boot distros and is left in for legacy
support only.  We probably should make it as such.




Well, patch is already merged and to get back a post for a revert or a 
follow up patch is needed.




Yes, I agree with Dennis. We both provided feedback to Alice that this
is not the preferred way to deal with boot distro.


I tend to let freedom to the board maintainers how they want / need to 
setup the linked environment, because this does not affect common i.MX 
code - so Fabio and Peng (the board maintainers) decide here.


Regards,
Stefano



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

Re: [PATCH] usb: dwc2: change compatible st,stm32mp1-hsotg to st,stm32mp15-hsotg

[Tom Rini]

On Tue, Feb 09, 2021 at 08:51:26PM +0100, Patrick DELAUNAY wrote:
> 
> On 2/9/21 11:39 AM, Marek Vasut wrote:
> > On 2/9/21 11:14 AM, Patrick Delaunay wrote:
> > Hi,
> > 
> > [...]
> > 
> > > diff --git a/drivers/usb/gadget/dwc2_udc_otg.c
> > > b/drivers/usb/gadget/dwc2_udc_otg.c
> > > index e3871e381e..ecac80fc11 100644
> > > --- a/drivers/usb/gadget/dwc2_udc_otg.c
> > > +++ b/drivers/usb/gadget/dwc2_udc_otg.c
> > > @@ -1176,7 +1176,7 @@ static int dwc2_udc_otg_remove(struct udevice
> > > *dev)
> > >   static const struct udevice_id dwc2_udc_otg_ids[] = {
> > >   { .compatible = "snps,dwc2" },
> > >   { .compatible = "brcm,bcm2835-usb" },
> > > -    { .compatible = "st,stm32mp1-hsotg",
> > > +    { .compatible = "st,stm32mp15-hsotg",
> > >     .data = (ulong)dwc2_set_stm32mp1_hsotg_params },
> > 
> > I have to point out the obvious, DT is ABI, this breaks ABI. However, do
> > we care about out-of-tree DTs here ?
> 
> 
> I know that the binding backward compatibility and "binary compatible" the
> is a key element of DT
> 
> for the Linux kernel (for example the latest kernel image should work with a
> old device tree).

The way we use DTs in U-Boot we don't enforce ABI because we allow for
DTS and bindings to come in before they're fully stabilized in
linux-next/similar and then it's required to re-sync them once they are
final.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 2/2] board: imx8mp: add boot.cmd for distro boot on iMX8MP

[Fabio Estevam]

On Wed, Feb 10, 2021 at 4:28 PM Dennis Gilmore
 wrote:
>
> Hi Stefano,
>
> I really do not think that this patch should have been merged. It is
> not the preferred way to boot distros and is left in for legacy
> support only.  We probably should make it as such.

Yes, I agree with Dennis. We both provided feedback to Alice that this
is not the preferred way to deal with boot distro.

Thanks

Re: [V2 2/3] ARM: mvebu: helios4 dts changes to enable SPI

[Dennis Gilmore]

could I please get someone to review this patch

Dennis

On Tue, Dec 8, 2020 at 9:07 PM  wrote:
>
> From: Dennis Gilmore 
>
> Move all aliases defintions into the main dts file
> Add u-boot definiton to i2c0 based on clearfog
> set spi1 status to okay
>
> Signed-off-by: Dennis Gilmore 
> ---
>  arch/arm/dts/armada-388-helios4-u-boot.dtsi | 23 -
>  arch/arm/dts/armada-388-helios4.dts | 14 -
>  2 files changed, 26 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/dts/armada-388-helios4-u-boot.dtsi 
> b/arch/arm/dts/armada-388-helios4-u-boot.dtsi
> index 0753889854..1047c1af23 100644
> --- a/arch/arm/dts/armada-388-helios4-u-boot.dtsi
> +++ b/arch/arm/dts/armada-388-helios4-u-boot.dtsi
> @@ -1,13 +1,5 @@
>  // SPDX-License-Identifier: GPL-2.0+
>
> -/ {
> -   aliases {
> -   i2c0 = 
> -   i2c1 = 
> -   spi1 = 
> -   };
> -};
> -
>   {
> phy-reset-gpios = < 19 GPIO_ACTIVE_LOW>;
>  };
> @@ -20,7 +12,6 @@
>  };
>
>   {
> -   status = "okay";
> u-boot,dm-spl;
>  };
>
> @@ -37,5 +28,17 @@
>  };
>
>   {
> -   u-boot,dm-spl;
> +   u-boot,dm-spl;
> +};
> +
> + {
> +   u-boot,dm-spl;
> +
> +   eeprom@52 {
> +   u-boot,dm-spl;
> +   };
> +
> +   eeprom@53 {
> +   u-boot,dm-spl;
> +   };
>  };
> diff --git a/arch/arm/dts/armada-388-helios4.dts 
> b/arch/arm/dts/armada-388-helios4.dts
> index fb49df2a3b..cbc296a46c 100644
> --- a/arch/arm/dts/armada-388-helios4.dts
> +++ b/arch/arm/dts/armada-388-helios4.dts
> @@ -22,10 +22,14 @@
> };
>
> aliases {
> -   /* So that mvebu u-boot can update the MAC addresses */
> +   /* So that mvebu u-boot can update the MAC address */
> ethernet1 = 
> +   spi1 = 
> +   i2c0 = 
> +   i2c1 = 
> };
>
> +
> chosen {
> stdout-path = "serial0:115200n8";
> };
> @@ -306,3 +310,11 @@
> };
> };
>  };
> +
> + {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +};
> --
> 2.28.0
>

Re: [PATCH v2 2/2] board: imx8mp: add boot.cmd for distro boot on iMX8MP

[Dennis Gilmore]

Hi Stefano,

I really do not think that this patch should have been merged. It is
not the preferred way to boot distros and is left in for legacy
support only.  We probably should make it as such.

Dennis

On Sat, Jan 23, 2021 at 9:53 AM  wrote:
>
> > From: Alice Guo 
> > Distro Boot requires a U-Boot-specific script named boot.scr or
> > boot.scr.uimg which contains boot commands to boot the system. The
> > boot.cmd is such a file. Use mkimage to generate boot.scr or
> > boot.scr.uimg from boot.cmd, and the command is:
> > mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Distro Boot Script" 
> > -d boot.cmd boot.scr.uimg
> > The boot.cmd file is an example script and can be modified based on
> > needs. bootargs is set in this script and root uses the default value
> > "/dev/mmcblk1p2 rootwait rw" which can be changed by overriding mmcroot.
> > Signed-off-by: Alice Guo 
> Applied to u-boot-imx, master, thanks !
>
> Best regards,
> Stefano Babic
>
> --
> =
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
> =

Re: [PATCH 2/2] board: toradex: move RGMII delays to PHY side

[Fabio Estevam]

Hi Oleksandr,

On Tue, Feb 9, 2021 at 5:39 AM Oleksandr Suvorov
 wrote:
>
> The RGMII link delays can be set on either MAC or PHY side. Set the
> rgmii-id PHY mode for FEC and remove FEC_ENET_ENABLE_.XC_DELAY
> setting, so that these definitions aren't used anymore throughout
> the U-Boot.
>
> Signed-off-by: Oleksandr Suvorov 

Reviewed-by: Fabio Estevam 

Re: [PATCH 1/2] ARM: imx8: Add missing FEC ENET quirk for i.MX8/i.MX8X

[Fabio Estevam]

Hi Oleksandr,

On Tue, Feb 9, 2021 at 5:39 AM Oleksandr Suvorov
 wrote:
>
> Both NXP SoCs i.MX8 and i.MX8X have ENET gigabit MAC.
> Define FEC_QUIRK_ENET_MAC for the imx8 platform and remove this
> definition from configs of boards, based on MX8/MX8X.
>
> Signed-off-by: Oleksandr Suvorov 

Reviewed-by: Fabio Estevam 

[PATCH v4] armv8: Handle EL2 Host mode

[Mark Kettenis]

On implementations that support VHE, the layout of the CPTR_EL2
register depends on whether HCR_EL2.E2H is set.  If the bit is
set, CPTR_EL2 uses the same layout as CPACR_EL1 and can in fact
be accessed through that register.  In that case, jump to the
EL1 code to enable access to the FP/SIMD registers.  This allows
U-Boot to run on systems that pass control to U-Boot in EL2 with
EL2 Host mode enabled such as machines using Apple's M1 SoC.

Signed-off-by: Mark Kettenis 
---

v4: use EL1 codepath when HCR_EL2.E2H is set
suggested by Marc Zyngier 

v2: rename label

 arch/arm/cpu/armv8/start.S | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index 662449156b..9e9c6140cd 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -132,11 +132,13 @@ pie_fixup_done:
msr cntfrq_el0, x0  /* Initialize CNTFRQ */
 #endif
b   0f
-2: set_vbarvbar_el2, x0
+2: mrs x1, hcr_el2
+   tbnzx1, #34, 1f /* HCR_EL2.E2H */
+   set_vbar vbar_el2, x0
mov x0, #0x33ff
msr cptr_el2, x0/* Enable FP/SIMD */
b   0f
-1: set_vbarvbar_el1, x0
+1: set_vbar vbar_el1, x0
mov x0, #3 << 20
msr cpacr_el1, x0   /* Enable FP/SIMD */
 0:
-- 
2.30.0

Re: [PATCH v3] armv8: Handle EL2 Host mode

[Mark Kettenis]

> From: Mark Kettenis 
> Date: Wed, 10 Feb 2021 19:25:53 +0100
> 
> On implementations that support VHE, the layout of the CPTR_EL2
> register depends on whether HCR_EL2.E2H is set.  If the bit is
> set, CPTR_EL2 uses the same layout as CPACR_EL1 and can in fact
> be accessed through that register.  In that case, jump to the
> EL1 code to enable access to the FP/SIMD registers.  This allows
> U-Boot to run on systems that pass control to U-Boot in EL2 with
> EL2 Host mode enabled such as machines using Apple's M1 SoC.
> 
> Signed-off-by: Mark Kettenis 
> ---

Please disregard, I forgot to commit the actual change.


> v3: use EL1 codepath when HCR_EL2.E2H is set
> suggested by Marc Zyngier 
> 
> v2: rename label
> 
>  arch/arm/cpu/armv8/start.S | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
> index 662449156b..979dcfef35 100644
> --- a/arch/arm/cpu/armv8/start.S
> +++ b/arch/arm/cpu/armv8/start.S
> @@ -133,9 +133,15 @@ pie_fixup_done:
>  #endif
>   b   0f
>  2:   set_vbarvbar_el2, x0
> + mrs x0, hcr_el2
> + tbnzx0, #34, el2_vhe/* HCR_EL2.E2H */
>   mov x0, #0x33ff
>   msr cptr_el2, x0/* Enable FP/SIMD */
>   b   0f
> +el2_vhe:
> + mov x0, #3 << 20
> + msr cptr_el2, x0/* Enable FP/SIMD */
> + b   0f
>  1:   set_vbarvbar_el1, x0
>   mov x0, #3 << 20
>   msr cpacr_el1, x0   /* Enable FP/SIMD */
> -- 
> 2.30.0
> 
> 

Final of-platdata thing

[Simon Glass]

Hi Tom,

I have the dtoc changes ready to go but I was thinking it best to
apply the driver-model updates before sending a pull request.

But that is (currently) designed to set on top of the SPL test
improvements...have you had a look at that one? I can probably
separate them if needed.

Regards,
Simon

Re: [PATCH 1/2] ARM: imx8: Add missing FEC ENET quirk for i.MX8/i.MX8X

[Oliver Graute]

On 09/02/21, Oleksandr Suvorov wrote:
> Both NXP SoCs i.MX8 and i.MX8X have ENET gigabit MAC.
> Define FEC_QUIRK_ENET_MAC for the imx8 platform and remove this
> definition from configs of boards, based on MX8/MX8X.
> 
> Signed-off-by: Oleksandr Suvorov 

Acked-by: Oliver Graute 

Re: [PATCH v2 1/1] sandbox: allow cross-compiling sandbox

[Sean Anderson]

On 2/10/21 1:20 PM, Sean Anderson wrote:



On 2/10/21 12:54 PM, Heinrich Schuchardt wrote:
 > UEFI test files like helloworld.efi require an architecture specific
 > PE-COFF header.
 >
 > Currently this does not work for cross compiling. If $CROSS_COMPILE 
is set,

 > use the first part of the architecture triplet from the variable to
 > choose the PE-COFF header.
 >
 > Now we can cross-compile the sandbox, e.g.
 >
 >  make sandbox_defconfig NO_SDL=1
 >  CROSS_COMPILE=/opt/bin/aarch64-linux-gnu- NO_SDL=1 
MK_ARCH=aarch64 make

 >
 > Signed-off-by: Heinrich Schuchardt 
 > ---
 > v2:
 > use $CROSS_COMPILE instead of an extra environment variable
 > ---
 >   Makefile | 10 +++---
 >   1 file changed, 7 insertions(+), 3 deletions(-)
 >
 > diff --git a/Makefile b/Makefile
 > index ebbedb1fb1..6c256a23b6 100644
 > --- a/Makefile
 > +++ b/Makefile
 > @@ -17,9 +17,13 @@ NAME =
 >   # o Look for make include files relative to root of kernel src
 >   MAKEFLAGS += -rR --include-dir=$(CURDIR)
 >
 > -# Determine host architecture
 > +# Determine target architecture for the sandbox
 >   include include/host_arch.h
 > -MK_ARCH="${shell uname -m}"
 > +ifeq ("", "$(CROSS_COMPILE)")
 > +  MK_ARCH="${shell uname -m}"
 > +else
 > +  MK_ARCH="${shell echo $(CROSS_COMPILE) | sed -n 
's/^\s*\([^\/]*\/\)*\([^-]*\)-\S*/\2/p'}"

 > +endif

Won't this break cross-compiling? E.g. if on my x86_64 machine I run
"CROSS_COMPILE=arm-linux-gnueabihf- make" my HOST_ARCH will be
HOST_ARCH_ARM, even though it should be HOST_ARCH_X86_64.


And it seems I've confused HOSTARCH with HOST_ARCH...

(probably a good candidate for a rename)

--Sean



I think you need a separate variable for a "canadian cross." gcc uses
"build," "host," and "target," but as-is U-Boot's HOST_ARCH is gcc's
"build" arch.

--Sean

 >   unexport HOST_ARCH
 >   ifeq ("x86_64", $(MK_ARCH))
 > export HOST_ARCH=$(HOST_ARCH_X86_64)
 > @@ -27,7 +31,7 @@ else ifneq (,$(findstring $(MK_ARCH), "i386" "i486" 
"i586" "i686"))

 > export HOST_ARCH=$(HOST_ARCH_X86)
 >   else ifneq (,$(findstring $(MK_ARCH), "aarch64" "armv8l"))
 > export HOST_ARCH=$(HOST_ARCH_AARCH64)
 > -else ifeq ("armv7l", $(MK_ARCH))
 > +else ifneq (,$(findstring $(MK_ARCH), "arm" "armv7" "armv7l"))
 > export HOST_ARCH=$(HOST_ARCH_ARM)
 >   else ifeq ("riscv32", $(MK_ARCH))
 > export HOST_ARCH=$(HOST_ARCH_RISCV32)
 > --
 > 2.30.0
 >

[PATCH v3] armv8: Handle EL2 Host mode

[Mark Kettenis]

On implementations that support VHE, the layout of the CPTR_EL2
register depends on whether HCR_EL2.E2H is set.  If the bit is
set, CPTR_EL2 uses the same layout as CPACR_EL1 and can in fact
be accessed through that register.  In that case, jump to the
EL1 code to enable access to the FP/SIMD registers.  This allows
U-Boot to run on systems that pass control to U-Boot in EL2 with
EL2 Host mode enabled such as machines using Apple's M1 SoC.

Signed-off-by: Mark Kettenis 
---

v3: use EL1 codepath when HCR_EL2.E2H is set
suggested by Marc Zyngier 

v2: rename label

 arch/arm/cpu/armv8/start.S | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index 662449156b..979dcfef35 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -133,9 +133,15 @@ pie_fixup_done:
 #endif
b   0f
 2: set_vbarvbar_el2, x0
+   mrs x0, hcr_el2
+   tbnzx0, #34, el2_vhe/* HCR_EL2.E2H */
mov x0, #0x33ff
msr cptr_el2, x0/* Enable FP/SIMD */
b   0f
+el2_vhe:
+   mov x0, #3 << 20
+   msr cptr_el2, x0/* Enable FP/SIMD */
+   b   0f
 1: set_vbarvbar_el1, x0
mov x0, #3 << 20
msr cpacr_el1, x0   /* Enable FP/SIMD */
-- 
2.30.0

Re: [PATCH v2 1/1] sandbox: allow cross-compiling sandbox

[Sean Anderson]

On 2/10/21 12:54 PM, Heinrich Schuchardt wrote:
> UEFI test files like helloworld.efi require an architecture specific
> PE-COFF header.
>
> Currently this does not work for cross compiling. If $CROSS_COMPILE 
is set,

> use the first part of the architecture triplet from the variable to
> choose the PE-COFF header.
>
> Now we can cross-compile the sandbox, e.g.
>
>  make sandbox_defconfig NO_SDL=1
>  CROSS_COMPILE=/opt/bin/aarch64-linux-gnu- NO_SDL=1 
MK_ARCH=aarch64 make

>
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
>use $CROSS_COMPILE instead of an extra environment variable
> ---
>   Makefile | 10 +++---
>   1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index ebbedb1fb1..6c256a23b6 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -17,9 +17,13 @@ NAME =
>   # o Look for make include files relative to root of kernel src
>   MAKEFLAGS += -rR --include-dir=$(CURDIR)
>
> -# Determine host architecture
> +# Determine target architecture for the sandbox
>   include include/host_arch.h
> -MK_ARCH="${shell uname -m}"
> +ifeq ("", "$(CROSS_COMPILE)")
> +  MK_ARCH="${shell uname -m}"
> +else
> +  MK_ARCH="${shell echo $(CROSS_COMPILE) | sed -n 
's/^\s*\([^\/]*\/\)*\([^-]*\)-\S*/\2/p'}"

> +endif

Won't this break cross-compiling? E.g. if on my x86_64 machine I run
"CROSS_COMPILE=arm-linux-gnueabihf- make" my HOST_ARCH will be
HOST_ARCH_ARM, even though it should be HOST_ARCH_X86_64.

I think you need a separate variable for a "canadian cross." gcc uses
"build," "host," and "target," but as-is U-Boot's HOST_ARCH is gcc's
"build" arch.

--Sean

>   unexport HOST_ARCH
>   ifeq ("x86_64", $(MK_ARCH))
> export HOST_ARCH=$(HOST_ARCH_X86_64)
> @@ -27,7 +31,7 @@ else ifneq (,$(findstring $(MK_ARCH), "i386" "i486" 
"i586" "i686"))

> export HOST_ARCH=$(HOST_ARCH_X86)
>   else ifneq (,$(findstring $(MK_ARCH), "aarch64" "armv8l"))
> export HOST_ARCH=$(HOST_ARCH_AARCH64)
> -else ifeq ("armv7l", $(MK_ARCH))
> +else ifneq (,$(findstring $(MK_ARCH), "arm" "armv7" "armv7l"))
> export HOST_ARCH=$(HOST_ARCH_ARM)
>   else ifeq ("riscv32", $(MK_ARCH))
> export HOST_ARCH=$(HOST_ARCH_RISCV32)
> --
> 2.30.0
>

Re: [PATCH v3 3/3] dm: i2c: use CONFIG_IS_ENABLED macro for DM_I2C/DM_I2C_GPIO

[Tom Rini]

On Tue, Feb 09, 2021 at 01:52:45PM +0200, Igor Opaniuk wrote:

> From: Igor Opaniuk 
> 
> Use CONFIG_IS_ENABLED() macro, which provides more convenient
> way to check $(SPL)DM_I2C/$(SPL)DM_I2C_GPIO configs
> for both SPL and U-Boot proper.
> 
> CONFIG_IS_ENABLED(DM_I2C) expands to:
> - 1 if CONFIG_SPL_BUILD is undefined and CONFIG_DM_I2C is set to 'y',
> - 1 if CONFIG_SPL_BUILD is defined and CONFIG_SPL_DM_I2C is set to 'y',
> - 0 otherwise.
> 
> All occurences were replaced automatically using these bash cmds:
> $ find . -type f -exec sed -i
>  's/ifndef CONFIG_DM_I2C/if !CONFIG_IS_ENABLED(DM_I2C)/g' {} +
> $ find . -type f -exec sed -i
> 's/ifdef CONFIG_DM_I2C/if CONFIG_IS_ENABLED(DM_I2C)/g' {} +
> $ find . -type f -exec sed -i
> 's/defined(CONFIG_DM_I2C)/CONFIG_IS_ENABLED(DM_I2C)/g' {} +
> $ find . -type f -exec sed -i
> 's/ifndef CONFIG_DM_I2C_GPIO/if !CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} +
> $ find . -type f -exec sed -i
> 's/ifdef CONFIG_DM_I2C_GPIO/if CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} +
> $ find . -type f -exec sed -i
> 's/defined(CONFIG_DM_I2C_GPIO)/CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} +
> 
> Reviewed-by: Heiko Schocher 
> Reviewed-by: Simon Glass 
> Signed-off-by: Igor Opaniuk 
> 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 1/1] malloc: adjust memcpy() and memset() definitions.

[Heinrich Schuchardt]

Compiling the sandbox fails on armv7 due to conflicting definitions of
memcpy() and memset() in include/malloc.h and include/linux/string.h.

Use linux/string.h here.

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

diff --git a/include/malloc.h b/include/malloc.h
index f66c2e8617..e15e528a2e 100644
--- a/include/malloc.h
+++ b/include/malloc.h
@@ -361,8 +361,11 @@ extern "C" {
 #if (__STD_C || defined(HAVE_MEMCPY))

 #if __STD_C
+/* U-Boot defines memset() and memcpy in /include/linux/string.h
 void* memset(void*, int, size_t);
 void* memcpy(void*, const void*, size_t);
+*/
+#include 
 #else
 #ifdef WIN32
 /* On Win32 platforms, 'memset()' and 'memcpy()' are already declared in */
--
2.30.0

[PATCH v2 1/1] sandbox: allow cross-compiling sandbox

[Heinrich Schuchardt]

UEFI test files like helloworld.efi require an architecture specific
PE-COFF header.

Currently this does not work for cross compiling. If $CROSS_COMPILE is set,
use the first part of the architecture triplet from the variable to
choose the PE-COFF header.

Now we can cross-compile the sandbox, e.g.

make sandbox_defconfig NO_SDL=1
CROSS_COMPILE=/opt/bin/aarch64-linux-gnu- NO_SDL=1 MK_ARCH=aarch64 make

Signed-off-by: Heinrich Schuchardt 
---
v2:
use $CROSS_COMPILE instead of an extra environment variable
---
 Makefile | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index ebbedb1fb1..6c256a23b6 100644
--- a/Makefile
+++ b/Makefile
@@ -17,9 +17,13 @@ NAME =
 # o Look for make include files relative to root of kernel src
 MAKEFLAGS += -rR --include-dir=$(CURDIR)

-# Determine host architecture
+# Determine target architecture for the sandbox
 include include/host_arch.h
-MK_ARCH="${shell uname -m}"
+ifeq ("", "$(CROSS_COMPILE)")
+  MK_ARCH="${shell uname -m}"
+else
+  MK_ARCH="${shell echo $(CROSS_COMPILE) | sed -n 
's/^\s*\([^\/]*\/\)*\([^-]*\)-\S*/\2/p'}"
+endif
 unexport HOST_ARCH
 ifeq ("x86_64", $(MK_ARCH))
   export HOST_ARCH=$(HOST_ARCH_X86_64)
@@ -27,7 +31,7 @@ else ifneq (,$(findstring $(MK_ARCH), "i386" "i486" "i586" 
"i686"))
   export HOST_ARCH=$(HOST_ARCH_X86)
 else ifneq (,$(findstring $(MK_ARCH), "aarch64" "armv8l"))
   export HOST_ARCH=$(HOST_ARCH_AARCH64)
-else ifeq ("armv7l", $(MK_ARCH))
+else ifneq (,$(findstring $(MK_ARCH), "arm" "armv7" "armv7l"))
   export HOST_ARCH=$(HOST_ARCH_ARM)
 else ifeq ("riscv32", $(MK_ARCH))
   export HOST_ARCH=$(HOST_ARCH_RISCV32)
--
2.30.0

Re: [PATCH v2 1/1] timer: imx-gpt: Add timer support for i.MX SoCs family

[Sean Anderson]

On 2/10/21 12:49 PM, Giulio Benetti wrote:
> On 2/10/21 1:04 AM, Jesse Taube wrote:
>> This timer driver is using GPT Timer (General Purpose Timer) available
>> on almost all i.MX SoCs family.
>> Since this driver is only meant to provide u-boot's timer and counter,
>> and most of the i.MX* SoCs use a 24Mhz crystal, let's only deal with
>> that specific source.
>
> We have a problem with columns on commit log, they shouldn't be longer
> than 72 cols, so please check the editor you're using for commit log
> writing and set 72 cols costrains. I use nano and you only need to set
> in .gitconfig under [core]:
> editor = nano -b -r 72
>
> This way nano automatically put a CR.
>
>>
>> Signed-off-by: Giulio Benetti 
>> Signed-off-by: Jesse Taube 
>>
>> ---
>>   drivers/timer/Kconfig |   7 ++
>>   drivers/timer/Makefile|   1 +
>>   drivers/timer/imx-gpt-timer.c | 132 ++
>>   3 files changed, 140 insertions(+)
>>   create mode 100644 drivers/timer/imx-gpt-timer.c
>>
>> diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
>> index 80743a2551..ee81dfa776 100644
>> --- a/drivers/timer/Kconfig
>> +++ b/drivers/timer/Kconfig
>> @@ -227,4 +227,11 @@ config MCHP_PIT64B_TIMER
>> Select this to enable support for Microchip 64-bit periodic
>> interval timer.
>> +config IMX_GPT_TIMER
>> +bool "NXP i.MX GPT timer support"
>> +depends on TIMER
>> +help
>> +  Select this to enable support for the timer found on
>> +  NXP i.MX devices.
>> +
>>   endmenu
>> diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
>> index eb5c48cc6c..e214ba7268 100644
>> --- a/drivers/timer/Makefile
>> +++ b/drivers/timer/Makefile
>> @@ -25,3 +25,4 @@ obj-$(CONFIG_STM32_TIMER)+= stm32_timer.o
>>   obj-$(CONFIG_X86_TSC_TIMER)+= tsc_timer.o
>>   obj-$(CONFIG_MTK_TIMER)+= mtk_timer.o
>>   obj-$(CONFIG_MCHP_PIT64B_TIMER)+= mchp-pit64b-timer.o
>> +obj-$(CONFIG_IMX_GPT_TIMER)+= imx-gpt-timer.o
>> diff --git a/drivers/timer/imx-gpt-timer.c
>> b/drivers/timer/imx-gpt-timer.c
>> new file mode 100644
>> index 00..58c37db300
>> --- /dev/null
>> +++ b/drivers/timer/imx-gpt-timer.c
>> @@ -0,0 +1,132 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright (C) 2020
>> + * Author(s): Giulio Benetti 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +#define GPT_CR_SWR0x8000
>> +#define GPT_CR_CLKSRC0x01C0
>> +#define GPT_CR_EN_24M0x4000
>> +#define GPT_CR_EN0x0001
>> +#define GPT_PR_PRESCALER0x0FFF
>> +#define GPT_PR_PRESCALER24M0xF000
>
> Here ^^^ and
>
>> +#define NO_CLOCK(0)
>> +#define IPG_CLK(1 << 6)
>> +#define IPG_CLK_HF(2 << 6)
>> +#define IPG_EXT(3 << 6)
>> +#define IPG_CLK_32K(4 << 6)
>> +#define IPG_CLK_24M(5 << 6)
>
> here you still have different tab numbers. Enable in your editor the
> option to show whitespaces and tabs, that way everything it easier.
>
>> +
>> +struct imx_gpt_timer_regs {
>> +u32 cr;
>> +u32 pr;
>> +u32 sr;
>> +u32 ir;
>> +u32 ocr1;
>> +u32 ocr2;
>> +u32 ocr3;
>> +u32 icr1;
>> +u32 icr2;
>> +u32 cnt;
>> +};
>> +
>> +struct imx_gpt_timer_priv {
>> +struct imx_gpt_timer_regs *base;
>> +};
>> +
>> +static u64 imx_gpt_timer_get_count(struct udevice *dev)
>> +{
>> +struct imx_gpt_timer_priv *priv = dev_get_priv(dev);
>> +struct imx_gpt_timer_regs *regs = priv->base;
>> +
>> +return readl(>cnt);
>> +}
>> +
>> +static int imx_gpt_timer_probe(struct udevice *dev)
>> +{
>> +struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
>> +struct imx_gpt_timer_priv *priv = dev_get_priv(dev);
>> +struct imx_gpt_timer_regs *regs;
>> +struct clk clk;
>> +fdt_addr_t addr;
>> +u32 prescaler;
>> +u32 rate;
>> +int ret;
>> +
>> +addr = dev_read_addr(dev);
>> +if (addr == FDT_ADDR_T_NONE)
>> +return -EINVAL;
>> +
>> +priv->base = (struct imx_gpt_timer_regs *)addr;
>> +
>> +ret = clk_get_by_index(dev, 0, );
>> +if (ret < 0)
>> +return ret;
>> +
>> +ret = clk_enable();
>> +if (ret) {
>> +dev_err(dev, "Failed to enable clock\n");
>> +return ret;
>> +}
>> +
>> +regs = priv->base;
>> +
>> +/* Reset the timer */
>> +setbits_le32(>cr, GPT_CR_SWR);
>> +
>> +/* Wait for timer to finish reset */
>> +while (readl(>cr) & GPT_CR_SWR)
>> +;
>> +
>> +/* Get timer clock rate */
>> +rate = clk_get_rate();
>
> clk_get_rate() has a wrong description in include/clk.h saying:
> "@return clock rate in Hz, or -ve error code."
>
> This^^^ is wrong.
> If you dig into drivers/clk/clk-uclass.c and look for clk_get_rate(),
> you will see that it returns 0 on 

[PATCH 5/6] sh: Remove sh7757lcr board

[Tom Rini]

This board has not been converted to CONFIG_DM by the deadline of v2020.01
and is missing other conversions which depend on this as well.  Remove it.

As this is the last SH4A board, remove that support as well.

Cc: Marek Vasut 
Signed-off-by: Tom Rini 
---
 arch/sh/Kconfig  |  18 -
 arch/sh/include/asm/cpu_sh4.h|  25 --
 arch/sh/include/asm/system.h |  23 -
 arch/sh/include/asm/unaligned-sh4a.h | 258 ---
 arch/sh/include/asm/unaligned.h  |   7 +-
 board/renesas/sh7757lcr/Kconfig  |  12 -
 board/renesas/sh7757lcr/MAINTAINERS  |   6 -
 board/renesas/sh7757lcr/Makefile |   7 -
 board/renesas/sh7757lcr/README.sh7757lcr |  77 
 board/renesas/sh7757lcr/lowlevel_init.S  | 544 ---
 board/renesas/sh7757lcr/sh7757lcr.c  | 433 --
 board/renesas/sh7757lcr/spi-boot.c   | 108 -
 configs/sh7757lcr_defconfig  |  40 --
 drivers/net/sh_eth.h |   4 -
 include/configs/sh7757lcr.h  |  78 
 15 files changed, 1 insertion(+), 1639 deletions(-)
 delete mode 100644 arch/sh/include/asm/unaligned-sh4a.h
 delete mode 100644 board/renesas/sh7757lcr/Kconfig
 delete mode 100644 board/renesas/sh7757lcr/MAINTAINERS
 delete mode 100644 board/renesas/sh7757lcr/Makefile
 delete mode 100644 board/renesas/sh7757lcr/README.sh7757lcr
 delete mode 100644 board/renesas/sh7757lcr/lowlevel_init.S
 delete mode 100644 board/renesas/sh7757lcr/sh7757lcr.c
 delete mode 100644 board/renesas/sh7757lcr/spi-boot.c
 delete mode 100644 configs/sh7757lcr_defconfig
 delete mode 100644 include/configs/sh7757lcr.h

diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index d8d2a7ffe9d0..2e9ccf7632a6 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -4,19 +4,6 @@ menu "SuperH architecture"
 config CPU_SH4
bool
 
-config CPU_SH4A
-   bool
-   select CPU_SH4
-
-config SH_32BIT
-   bool "32bit mode"
-   depends on CPU_SH4A
-   default n
-   help
- SH4A has 2 physical memory maps. This use 32bit mode.
- And this is board specific. Please check your board if you
- want to use this.
-
 choice
prompt "Target select"
optional
@@ -25,10 +12,6 @@ config TARGET_R2DPLUS
bool "Renesas R2D-PLUS"
select CPU_SH4
 
-config TARGET_SH7757LCR
-   bool "SH7757LCR"
-   select CPU_SH4A
-
 config TARGET_SH7763RDP
bool "SH7763RDP"
select CPU_SH4
@@ -44,7 +27,6 @@ config SYS_CPU
 source "arch/sh/lib/Kconfig"
 
 source "board/renesas/r2dplus/Kconfig"
-source "board/renesas/sh7757lcr/Kconfig"
 source "board/renesas/sh7763rdp/Kconfig"
 
 endmenu
diff --git a/arch/sh/include/asm/cpu_sh4.h b/arch/sh/include/asm/cpu_sh4.h
index 5fc9c962d833..ed7c243b3bda 100644
--- a/arch/sh/include/asm/cpu_sh4.h
+++ b/arch/sh/include/asm/cpu_sh4.h
@@ -46,29 +46,4 @@
 # error "Unknown SH4 variant"
 #endif
 
-#if defined(CONFIG_SH_32BIT)
-#define PMB_ADDR_ARRAY 0xf610
-#define PMB_ADDR_ENTRY 8
-#define PMB_VPN24
-
-#define PMB_DATA_ARRAY 0xf710
-#define PMB_DATA_ENTRY 8
-#define PMB_PPN24
-#define PMB_UB 9   /* Buffered write */
-#define PMB_V  8   /* Valid */
-#define PMB_SZ17   /* Page size (upper 
bit) */
-#define PMB_SZ04   /* Page size (lower 
bit) */
-#define PMB_C  3   /* Cacheability */
-#define PMB_WT 0   /* Write-through */
-
-#define PMB_ADDR_BASE(entry)   (PMB_ADDR_ARRAY + (entry << PMB_ADDR_ENTRY))
-#define PMB_DATA_BASE(entry)   (PMB_DATA_ARRAY + (entry << PMB_DATA_ENTRY))
-#define mk_pmb_addr_val(vpn)   ((vpn << PMB_VPN))
-#define mk_pmb_data_val(ppn, ub, v, sz1, sz0, c, wt)   \
-   ((ppn << PMB_PPN) | (ub << PMB_UB) | \
-(v << PMB_V) | (sz1 << PMB_SZ1) | \
-(sz0 << PMB_SZ0) | (c << PMB_C) | \
-(wt << PMB_WT))
-#endif
-
 #endif /* _ASM_CPU_SH4_H_ */
diff --git a/arch/sh/include/asm/system.h b/arch/sh/include/asm/system.h
index 24b5ce8e3042..ccc79b3c9177 100644
--- a/arch/sh/include/asm/system.h
+++ b/arch/sh/include/asm/system.h
@@ -70,18 +70,6 @@ static inline void sched_cacheflush(void)
 {
 }
 
-#ifdef CONFIG_CPU_SH4A
-#define __icbi()   \
-{  \
-   unsigned long __addr;   \
-   __addr = 0xa800;\
-   __asm__ __volatile__(   \
-   "icbi   %0\n\t" \
-   : /* no output */   \
-   : "m" (__m(__addr)));   \
-}
-#endif
-
 static inline unsigned long tas(volatile int *m)
 {
unsigned long retval;
@@ -100,25 +88,14 @@ static inline unsigned long tas(volatile int *m)
  * 

Re: [PATCH 13/13] arm: stm32: Disable ATAGs support

[Tom Rini]

On Mon, Feb 08, 2021 at 05:34:50PM +0100, Patrick DELAUNAY wrote:

[snip]
> Just one question for other part of generic code which can be removed
> 
> bi_boot_params should be under compilation BOOTM_ENABLE_TAGS flags ?
> 
> In include/asm-generic/u-boot.h:70
>     struct bd_info {
> 
>     
>         ulong        bi_boot_params;    /* where this board expects
> params */
> 
>     ...
> 
>     };
> 
> 
> and also params global variables, only used in setup_XXX functions ?
> 
>     arch/arm/lib/bootm.c:44:
>         static struct tag *params;

With some further cleanup work to introduce a single symbol to say
yes/no to ATAGS support, we could then cleanly condition out a few more
bits of code and save some space, yes.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PULL u-boot] Please pull u-boot-amlogic-20210210

[Tom Rini]

On Wed, Feb 10, 2021 at 01:54:54PM +0100, Neil Armstrong wrote:

> Hi Tom,
> 
> These changes adds the plumbing to support MIPI D-PHYs, including the timings 
> helpers from
> Linux, the AXG Analog and Digital D-PHY drivers. Finally automatic detection 
> of model is added
> for the HardKernel Odroid N2 & C4 families.
> 
> The CI job is at 
> https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/6346
> 
> Thanks,
> Neil
> 
> The following changes since commit e14d5762de1db84cae6d84d59c1e40f3eb26c4c3:
> 
>   Merge git://git.denx.de/u-boot-marvell (2021-02-08 10:55:51 -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic.git 
> tags/u-boot-amlogic-20210210
> 
> for you to fetch changes up to 8bc780106c1399bd263c4283a8747889a613ca5d:
> 
>   board: amlogic: odroid: add runtime detection of the N2/N2+/C4/HC4 variants 
> (2021-02-10 10:00:51 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 6/6] sh: Remove sh7763rdp board

[Tom Rini]

This board has not been converted to CONFIG_DM by the deadline of v2020.01
and is missing other conversions which depend on this as well.  Remove it.

Cc: Nobuhiro Iwamatsu 
Signed-off-by: Tom Rini 
---
 arch/sh/Kconfig |   5 -
 board/renesas/sh7763rdp/Kconfig |  12 --
 board/renesas/sh7763rdp/MAINTAINERS |   7 -
 board/renesas/sh7763rdp/Makefile|  10 -
 board/renesas/sh7763rdp/lowlevel_init.S | 259 
 board/renesas/sh7763rdp/sh7763rdp.c |  54 -
 configs/sh7763rdp_defconfig |  42 
 include/configs/sh7763rdp.h |  66 --
 8 files changed, 455 deletions(-)
 delete mode 100644 board/renesas/sh7763rdp/Kconfig
 delete mode 100644 board/renesas/sh7763rdp/MAINTAINERS
 delete mode 100644 board/renesas/sh7763rdp/Makefile
 delete mode 100644 board/renesas/sh7763rdp/lowlevel_init.S
 delete mode 100644 board/renesas/sh7763rdp/sh7763rdp.c
 delete mode 100644 configs/sh7763rdp_defconfig
 delete mode 100644 include/configs/sh7763rdp.h

diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 2e9ccf7632a6..7836869c55dc 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -12,10 +12,6 @@ config TARGET_R2DPLUS
bool "Renesas R2D-PLUS"
select CPU_SH4
 
-config TARGET_SH7763RDP
-   bool "SH7763RDP"
-   select CPU_SH4
-
 endchoice
 
 config SYS_ARCH
@@ -27,6 +23,5 @@ config SYS_CPU
 source "arch/sh/lib/Kconfig"
 
 source "board/renesas/r2dplus/Kconfig"
-source "board/renesas/sh7763rdp/Kconfig"
 
 endmenu
diff --git a/board/renesas/sh7763rdp/Kconfig b/board/renesas/sh7763rdp/Kconfig
deleted file mode 100644
index 101d2b5a32e4..
--- a/board/renesas/sh7763rdp/Kconfig
+++ /dev/null
@@ -1,12 +0,0 @@
-if TARGET_SH7763RDP
-
-config SYS_BOARD
-   default "sh7763rdp"
-
-config SYS_VENDOR
-   default "renesas"
-
-config SYS_CONFIG_NAME
-   default "sh7763rdp"
-
-endif
diff --git a/board/renesas/sh7763rdp/MAINTAINERS 
b/board/renesas/sh7763rdp/MAINTAINERS
deleted file mode 100644
index 6ee8f9f87bc8..
--- a/board/renesas/sh7763rdp/MAINTAINERS
+++ /dev/null
@@ -1,7 +0,0 @@
-SH7763RDP BOARD
-M: Nobuhiro Iwamatsu 
-M: Nobuhiro Iwamatsu 
-S: Maintained
-F: board/renesas/sh7763rdp/
-F: include/configs/sh7763rdp.h
-F: configs/sh7763rdp_defconfig
diff --git a/board/renesas/sh7763rdp/Makefile b/board/renesas/sh7763rdp/Makefile
deleted file mode 100644
index 0db63c5d2bb8..
--- a/board/renesas/sh7763rdp/Makefile
+++ /dev/null
@@ -1,10 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-#
-# Copyright (C) 2008 Renesas Solutions Corp.
-# Copyright (C) 2008 Nobuhiro Iwamatsu 
-# Copyright (C) 2007 Kenati Technologies, Inc.
-#
-# board/sh7763rdp/Makefile
-
-obj-y  := sh7763rdp.o
-extra-y+= lowlevel_init.o
diff --git a/board/renesas/sh7763rdp/lowlevel_init.S 
b/board/renesas/sh7763rdp/lowlevel_init.S
deleted file mode 100644
index 80ef2580515e..
--- a/board/renesas/sh7763rdp/lowlevel_init.S
+++ /dev/null
@@ -1,259 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2008 Renesas Solutions Corp.
- * Copyright (C) 2008 Nobuhiro Iwamatsu 
- * Copyright (C) 2007 Kenati Technologies, Inc.
- *
- * board/sh7763rdp/lowlevel_init.S
- */
-
-#include 
-
-#include 
-#include 
-
-   .global lowlevel_init
-
-   .text
-   .align  2
-
-lowlevel_init:
-
-   write32 WDTCSR_A, WDTCSR_D  /* Watchdog Control / Status Register */
-
-   write32 WDTST_A, WDTST_D/* Watchdog Stop Time Register */
-
-   write32 WDTBST_A, WDTBST_D  /*
-* 0xFFCC0008
-* Watchdog Base Stop Time Register
-*/
-
-   write32 CCR_A, CCR_CACHE_ICI_D  /* Address of Cache Control Register */
-   /* Instruction Cache Invalidate */
-
-   write32 MMUCR_A, MMU_CONTROL_TI_D   /* MMU Control Register */
-   /* TI == TLB Invalidate bit */
-
-   write32 MSTPCR0_A, MSTPCR0_D/* Address of Power Control Register 0 
*/
-
-   write32 MSTPCR1_A, MSTPCR1_D/* Address of Power Control Register 1 
*/
-
-   write32 RAMCR_A, RAMCR_D
-
-   mov.l   MMSELR_A, r1
-   mov.l   MMSELR_D, r0
-   synco
-   mov.l   r0, @r1
-
-   mov.l   @r1, r2 /* execute two reads after setting MMSELR */
-   mov.l   @r1, r2
-   synco
-
-   /* issue memory read */
-   mov.l   DDRSD_START_A, r1   /* memory address to read*/
-   mov.l   @r1, r0
-   synco
-
-   write32 MIM8_A, MIM8_D
-
-   write32 MIMC_A, MIMC_D1
-
-   write32 STRC_A, STRC_D
-
-   write32 SDR4_A, SDR4_D
-
-   write32 MIMC_A, MIMC_D2
-
-   nop
-   nop
-   nop
-
-   write32 SCR4_A, SCR4_D3
-
-   write32 SCR4_A, SCR4_D2
-
-   write32 SDMR02000_A, SDMR02000_D
-
-   write32 SDMR00B08_A, SDMR00B08_D
-

[PATCH 4/6] sh: Remove sh7753evb board

[Tom Rini]

This board has not been converted to CONFIG_DM by the deadline of v2020.01
and is missing other conversions which depend on this as well.  Remove it.

Signed-off-by: Tom Rini 
---
 arch/sh/Kconfig |   5 -
 board/renesas/sh7753evb/Kconfig |  12 -
 board/renesas/sh7753evb/MAINTAINERS |   6 -
 board/renesas/sh7753evb/Makefile|   7 -
 board/renesas/sh7753evb/lowlevel_init.S | 414 
 board/renesas/sh7753evb/sh7753evb.c | 329 ---
 board/renesas/sh7753evb/spi-boot.c  | 133 
 configs/sh7753evb_defconfig |  38 ---
 doc/board/index.rst |   1 -
 doc/board/renesas/index.rst |   9 -
 doc/board/renesas/sh7753evb.rst |  79 -
 include/configs/sh7753evb.h |  65 
 12 files changed, 1098 deletions(-)
 delete mode 100644 board/renesas/sh7753evb/Kconfig
 delete mode 100644 board/renesas/sh7753evb/MAINTAINERS
 delete mode 100644 board/renesas/sh7753evb/Makefile
 delete mode 100644 board/renesas/sh7753evb/lowlevel_init.S
 delete mode 100644 board/renesas/sh7753evb/sh7753evb.c
 delete mode 100644 board/renesas/sh7753evb/spi-boot.c
 delete mode 100644 configs/sh7753evb_defconfig
 delete mode 100644 doc/board/renesas/index.rst
 delete mode 100644 doc/board/renesas/sh7753evb.rst
 delete mode 100644 include/configs/sh7753evb.h

diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 8446d9587ed5..d8d2a7ffe9d0 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -25,10 +25,6 @@ config TARGET_R2DPLUS
bool "Renesas R2D-PLUS"
select CPU_SH4
 
-config TARGET_SH7753EVB
-   bool "SH7753EVB"
-   select CPU_SH4
-
 config TARGET_SH7757LCR
bool "SH7757LCR"
select CPU_SH4A
@@ -48,7 +44,6 @@ config SYS_CPU
 source "arch/sh/lib/Kconfig"
 
 source "board/renesas/r2dplus/Kconfig"
-source "board/renesas/sh7753evb/Kconfig"
 source "board/renesas/sh7757lcr/Kconfig"
 source "board/renesas/sh7763rdp/Kconfig"
 
diff --git a/board/renesas/sh7753evb/Kconfig b/board/renesas/sh7753evb/Kconfig
deleted file mode 100644
index be889248a8e7..
--- a/board/renesas/sh7753evb/Kconfig
+++ /dev/null
@@ -1,12 +0,0 @@
-if TARGET_SH7753EVB
-
-config SYS_BOARD
-   default "sh7753evb"
-
-config SYS_VENDOR
-   default "renesas"
-
-config SYS_CONFIG_NAME
-   default "sh7753evb"
-
-endif
diff --git a/board/renesas/sh7753evb/MAINTAINERS 
b/board/renesas/sh7753evb/MAINTAINERS
deleted file mode 100644
index b6c85eedab75..
--- a/board/renesas/sh7753evb/MAINTAINERS
+++ /dev/null
@@ -1,6 +0,0 @@
-SH7753EVB BOARD
-#M:-
-S: Maintained
-F: board/renesas/sh7753evb/
-F: include/configs/sh7753evb.h
-F: configs/sh7753evb_defconfig
diff --git a/board/renesas/sh7753evb/Makefile b/board/renesas/sh7753evb/Makefile
deleted file mode 100644
index e1e099777c71..
--- a/board/renesas/sh7753evb/Makefile
+++ /dev/null
@@ -1,7 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-#
-# Copyright (C) 2012  Yoshihiro Shimoda 
-#
-
-obj-y  := sh7753evb.o spi-boot.o
-extra-y+= lowlevel_init.o
diff --git a/board/renesas/sh7753evb/lowlevel_init.S 
b/board/renesas/sh7753evb/lowlevel_init.S
deleted file mode 100644
index 901e9eb64887..
--- a/board/renesas/sh7753evb/lowlevel_init.S
+++ /dev/null
@@ -1,414 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2013  Renesas Solutions Corp.
- */
-
-#include 
-#include 
-#include 
-
-.macro or32, addr, data
-   mov.l \addr, r1
-   mov.l \data, r0
-   mov.l @r1, r2
-   orr2, r0
-   mov.l r0, @r1
-.endm
-
-.macro wait_DBCMD
-   mov.l   DBWAIT_A, r0
-   mov.l   @r0, r1
-.endm
-
-   .global lowlevel_init
-   .section.spiboot1.text
-   .align  2
-
-lowlevel_init:
-   mov #0, r14
-   mova2f, r0
-   mov.l   PC_MASK, r1
-   tst r0, r1
-   bf  2f
-
-   bra exit_pmb
-   nop
-
-   .align  2
-
-/* If CPU runs on SDRAM (PC=0x5???) or not. */
-PC_MASK:   .long   0x2000
-
-2:
-   mov #1, r14
-
-   mov.l   EXPEVT_A, r0
-   mov.l   @r0, r0
-   mov.l   EXPEVT_POWER_ON_RESET, r1
-   cmp/eq  r0, r1
-   bt  1f
-
-   /*
-* If EXPEVT value is manual reset or tlb multipul-hit,
-* initialization of DBSC3 is not necessary.
-*/
-   bra exit_ddr
-   nop
-
-1:
-   /*--- Reset ---*/
-   write32 MRSTCR0_A, MRSTCR0_D
-   write32 MRSTCR1_A, MRSTCR1_D
-
-   /* For Core Reset */
-   mov.l   DBACEN_A, r0
-   mov.l   @r0, r0
-   cmp/eq  #0, r0
-   bt  3f
-
-   /*
-* If DBACEN == 1(DBSC was already enabled), we have to avoid the
-* initialization of DDR3-SDRAM.
-*/
-   bra exit_ddr
-   nop
-
-3:
-   /*--- DBSC3 ---*/
-   /* oscillation stabilization time */
-   wait_timer  WAIT_OSC_TIME
-
-   /* step 3 */
-  

[PATCH 1/6] sh: Remove MigoR board

[Tom Rini]

This board has not been converted to CONFIG_DM by the deadline of v2020.01
and is missing other conversions which depend on this as well.  Remove it.

Signed-off-by: Tom Rini 
---
 arch/sh/Kconfig |   5 -
 board/renesas/MigoR/Kconfig |  12 --
 board/renesas/MigoR/MAINTAINERS |   6 -
 board/renesas/MigoR/Makefile|  13 --
 board/renesas/MigoR/lowlevel_init.S | 193 
 board/renesas/MigoR/migo_r.c|  43 ---
 configs/MigoR_defconfig |  34 -
 include/configs/MigoR.h |  82 
 8 files changed, 388 deletions(-)
 delete mode 100644 board/renesas/MigoR/Kconfig
 delete mode 100644 board/renesas/MigoR/MAINTAINERS
 delete mode 100644 board/renesas/MigoR/Makefile
 delete mode 100644 board/renesas/MigoR/lowlevel_init.S
 delete mode 100644 board/renesas/MigoR/migo_r.c
 delete mode 100644 configs/MigoR_defconfig
 delete mode 100644 include/configs/MigoR.h

diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 91002a9be08f..2cd153fbac0d 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -21,10 +21,6 @@ choice
prompt "Target select"
optional
 
-config TARGET_MIGOR
-   bool "Migo-R"
-   select CPU_SH4
-
 config TARGET_R2DPLUS
bool "Renesas R2D-PLUS"
select CPU_SH4
@@ -59,7 +55,6 @@ config SYS_CPU
 
 source "arch/sh/lib/Kconfig"
 
-source "board/renesas/MigoR/Kconfig"
 source "board/renesas/r2dplus/Kconfig"
 source "board/renesas/r7780mp/Kconfig"
 source "board/renesas/sh7752evb/Kconfig"
diff --git a/board/renesas/MigoR/Kconfig b/board/renesas/MigoR/Kconfig
deleted file mode 100644
index 25b170ac0712..
--- a/board/renesas/MigoR/Kconfig
+++ /dev/null
@@ -1,12 +0,0 @@
-if TARGET_MIGOR
-
-config SYS_BOARD
-   default "MigoR"
-
-config SYS_VENDOR
-   default "renesas"
-
-config SYS_CONFIG_NAME
-   default "MigoR"
-
-endif
diff --git a/board/renesas/MigoR/MAINTAINERS b/board/renesas/MigoR/MAINTAINERS
deleted file mode 100644
index 21ee5e275483..
--- a/board/renesas/MigoR/MAINTAINERS
+++ /dev/null
@@ -1,6 +0,0 @@
-MIGOR BOARD
-#M:-
-S: Maintained
-F: board/renesas/MigoR/
-F: include/configs/MigoR.h
-F: configs/MigoR_defconfig
diff --git a/board/renesas/MigoR/Makefile b/board/renesas/MigoR/Makefile
deleted file mode 100644
index 944a3bfe2cf6..
--- a/board/renesas/MigoR/Makefile
+++ /dev/null
@@ -1,13 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-#
-# Copyright (C) 2007
-# Nobuhiro Iwamatsu 
-#
-# Copyright (C) 2007
-# Kenati Technologies, Inc.
-#
-# board/MigoR/Makefile
-#
-
-obj-y  := migo_r.o
-extra-y+= lowlevel_init.o
diff --git a/board/renesas/MigoR/lowlevel_init.S 
b/board/renesas/MigoR/lowlevel_init.S
deleted file mode 100644
index 1b494faeb0e2..
--- a/board/renesas/MigoR/lowlevel_init.S
+++ /dev/null
@@ -1,193 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2007-2008
- * Nobuhiro Iwamatsu 
- *
- * Copyright (C) 2007
- * Kenati Technologies, Inc.
- *
- * board/MigoR/lowlevel_init.S
- */
-
-#include 
-
-#include 
-#include 
-
-/*
- * Board specific low level init code, called _very_ early in the
- * startup sequence. Relocation to SDRAM has not happened yet, no
- * stack is available, bss section has not been initialised, etc.
- *
- * (Note: As no stack is available, no subroutines can be called...).
- */
-
-   .global lowlevel_init
-
-   .text
-   .align  2
-
-lowlevel_init:
-   write32 CCR_A, CCR_D! Address of Cache Control Register
-   ! Instruction Cache Invalidate
-
-   write32 MMUCR_A, MMUCR_D! Address of MMU Control Register
-   ! TI == TLB Invalidate bit
-
-   write32 MSTPCR0_A, MSTPCR0_D! Address of Power Control Register 0
-
-   write32 MSTPCR2_A, MSTPCR2_D! Address of Power Control Register 2
-
-   write16 PFC_PULCR_A, PFC_PULCR_D
-
-   write16 PFC_DRVCR_A, PFC_DRVCR_D
-
-   write16 SBSCR_A, SBSCR_D
-
-   write16 PSCR_A, PSCR_D
-
-   write16 RWTCSR_A, RWTCSR_D_1! 0xA4520004 (Watchdog Control / Status 
Register)
-   ! 0xA507 -> timer_STOP / WDT_CLK = max
-
-   write16 RWTCNT_A, RWTCNT_D  ! 0xA452 (Watchdog Count Register)
-   ! 0x5A00 -> Clear
-
-   write16 RWTCSR_A, RWTCSR_D_2! 0xA4520004 (Watchdog Control / Status 
Register)
-   ! 0xA504 -> timer_STOP / CLK = 500ms
-
-   write32 DLLFRQ_A, DLLFRQ_D  ! 20080115
-   ! 20080115
-
-   write32 FRQCR_A, FRQCR_D! 0xA415 Frequency control register
-   ! 20080115
-
-   write32 CCR_A, CCR_D_2  ! Address of Cache Control Register
-   ! ??
-
-bsc_init:
-   write32 CMNCR_A, CMNCR_D
-
-   

[PATCH 3/6] sh: Remove sh7752evb board

[Tom Rini]

This board has not been converted to CONFIG_DM by the deadline of v2020.01
and is missing other conversions which depend on this as well.  Remove it.

Signed-off-by: Tom Rini 
---
 arch/sh/Kconfig |   5 -
 board/renesas/sh7752evb/Kconfig |  12 -
 board/renesas/sh7752evb/MAINTAINERS |   6 -
 board/renesas/sh7752evb/Makefile|   7 -
 board/renesas/sh7752evb/lowlevel_init.S | 445 
 board/renesas/sh7752evb/sh7752evb.c | 313 -
 board/renesas/sh7752evb/spi-boot.c  | 116 --
 configs/sh7752evb_defconfig |  39 ---
 doc/board/renesas/index.rst |   1 -
 doc/board/renesas/sh7752evb.rst |  79 -
 include/configs/sh7752evb.h |  65 
 11 files changed, 1088 deletions(-)
 delete mode 100644 board/renesas/sh7752evb/Kconfig
 delete mode 100644 board/renesas/sh7752evb/MAINTAINERS
 delete mode 100644 board/renesas/sh7752evb/Makefile
 delete mode 100644 board/renesas/sh7752evb/lowlevel_init.S
 delete mode 100644 board/renesas/sh7752evb/sh7752evb.c
 delete mode 100644 board/renesas/sh7752evb/spi-boot.c
 delete mode 100644 configs/sh7752evb_defconfig
 delete mode 100644 doc/board/renesas/sh7752evb.rst
 delete mode 100644 include/configs/sh7752evb.h

diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 2d7525e61db4..8446d9587ed5 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -25,10 +25,6 @@ config TARGET_R2DPLUS
bool "Renesas R2D-PLUS"
select CPU_SH4
 
-config TARGET_SH7752EVB
-   bool "SH7752EVB"
-   select CPU_SH4A
-
 config TARGET_SH7753EVB
bool "SH7753EVB"
select CPU_SH4
@@ -52,7 +48,6 @@ config SYS_CPU
 source "arch/sh/lib/Kconfig"
 
 source "board/renesas/r2dplus/Kconfig"
-source "board/renesas/sh7752evb/Kconfig"
 source "board/renesas/sh7753evb/Kconfig"
 source "board/renesas/sh7757lcr/Kconfig"
 source "board/renesas/sh7763rdp/Kconfig"
diff --git a/board/renesas/sh7752evb/Kconfig b/board/renesas/sh7752evb/Kconfig
deleted file mode 100644
index 7f40888336eb..
--- a/board/renesas/sh7752evb/Kconfig
+++ /dev/null
@@ -1,12 +0,0 @@
-if TARGET_SH7752EVB
-
-config SYS_BOARD
-   default "sh7752evb"
-
-config SYS_VENDOR
-   default "renesas"
-
-config SYS_CONFIG_NAME
-   default "sh7752evb"
-
-endif
diff --git a/board/renesas/sh7752evb/MAINTAINERS 
b/board/renesas/sh7752evb/MAINTAINERS
deleted file mode 100644
index 9840477d7dd2..
--- a/board/renesas/sh7752evb/MAINTAINERS
+++ /dev/null
@@ -1,6 +0,0 @@
-SH7752EVB BOARD
-#M:-
-S: Maintained
-F: board/renesas/sh7752evb/
-F: include/configs/sh7752evb.h
-F: configs/sh7752evb_defconfig
diff --git a/board/renesas/sh7752evb/Makefile b/board/renesas/sh7752evb/Makefile
deleted file mode 100644
index 658dc3bc6ded..
--- a/board/renesas/sh7752evb/Makefile
+++ /dev/null
@@ -1,7 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-#
-# Copyright (C) 2012  Yoshihiro Shimoda 
-#
-
-obj-y  := sh7752evb.o spi-boot.o
-extra-y+= lowlevel_init.o
diff --git a/board/renesas/sh7752evb/lowlevel_init.S 
b/board/renesas/sh7752evb/lowlevel_init.S
deleted file mode 100644
index 0f7b643ad8fe..
--- a/board/renesas/sh7752evb/lowlevel_init.S
+++ /dev/null
@@ -1,445 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2012  Renesas Solutions Corp.
- */
-
-#include 
-#include 
-#include 
-
-.macro or32, addr, data
-   mov.l \addr, r1
-   mov.l \data, r0
-   mov.l @r1, r2
-   orr2, r0
-   mov.l r0, @r1
-.endm
-
-.macro wait_DBCMD
-   mov.l   DBWAIT_A, r0
-   mov.l   @r0, r1
-.endm
-
-   .global lowlevel_init
-   .section.spiboot1.text
-   .align  2
-
-lowlevel_init:
-   /*--- GPIO ---*/
-   write16 PDCR_A, PDCR_D  ! SPI0
-   write16 PGCR_A, PGCR_D  ! SPI0, GETHER MDIO gate(PTG1)
-   write16 PJCR_A, PJCR_D  ! SCIF4
-   write16 PTCR_A, PTCR_D  ! STATUS
-   write16 PSEL1_A, PSEL1_D! SPI0
-   write16 PSEL2_A, PSEL2_D! SPI0
-   write16 PSEL5_A, PSEL5_D! STATUS
-
-   bra exit_gpio
-   nop
-
-   .align  2
-
-/*--- GPIO ---*/
-PDCR_A:.long   0xffec0006
-PGCR_A:.long   0xffec000c
-PJCR_A:.long   0xffec0012
-PTCR_A:.long   0xffec0026
-PSEL1_A:   .long   0xffec0072
-PSEL2_A:   .long   0xffec0074
-PSEL5_A:   .long   0xffec007a
-
-PDCR_D:.long   0x
-PGCR_D:.long   0x0004
-PJCR_D:.long   0x
-PTCR_D:.long   0x
-PSEL1_D:   .long   0x
-PSEL2_D:   .long   0x3000
-PSEL5_D:   .long   0x0ffc
-
-   .align  2
-
-exit_gpio:
-   mov #0, r14
-   mova2f, r0
-   mov.l   PC_MASK, r1
-   tst r0, r1
-   bf  2f
-
-   bra exit_pmb
-   nop
-
-   .align  2
-
-/* If CPU runs on 

[PATCH 2/6] sh: Remove r7780mp board

[Tom Rini]

This board has not been converted to CONFIG_DM by the deadline of v2020.01
and is missing other conversions which depend on this as well.  Remove it.

Patch-cc: Nobuhiro Iwamatsu 
Patch-cc: Nobuhiro Iwamatsu 
Signed-off-by: Tom Rini 
---
 arch/sh/Kconfig   |   5 -
 board/renesas/r7780mp/Kconfig |  12 -
 board/renesas/r7780mp/MAINTAINERS |   7 -
 board/renesas/r7780mp/Makefile|   9 -
 board/renesas/r7780mp/lowlevel_init.S | 356 --
 board/renesas/r7780mp/r7780mp.c   |  64 -
 board/renesas/r7780mp/r7780mp.h   |  40 ---
 configs/r7780mp_defconfig |  40 ---
 doc/arch/sh.rst   |  18 --
 drivers/net/Makefile  |   1 -
 drivers/net/ax88796.c | 144 ---
 drivers/net/ax88796.h |  66 -
 include/configs/r7780mp.h | 108 
 13 files changed, 870 deletions(-)
 delete mode 100644 board/renesas/r7780mp/Kconfig
 delete mode 100644 board/renesas/r7780mp/MAINTAINERS
 delete mode 100644 board/renesas/r7780mp/Makefile
 delete mode 100644 board/renesas/r7780mp/lowlevel_init.S
 delete mode 100644 board/renesas/r7780mp/r7780mp.c
 delete mode 100644 board/renesas/r7780mp/r7780mp.h
 delete mode 100644 configs/r7780mp_defconfig
 delete mode 100644 drivers/net/ax88796.c
 delete mode 100644 drivers/net/ax88796.h
 delete mode 100644 include/configs/r7780mp.h

diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 2cd153fbac0d..2d7525e61db4 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -25,10 +25,6 @@ config TARGET_R2DPLUS
bool "Renesas R2D-PLUS"
select CPU_SH4
 
-config TARGET_R7780MP
-   bool "R7780MP board"
-   select CPU_SH4A
-
 config TARGET_SH7752EVB
bool "SH7752EVB"
select CPU_SH4A
@@ -56,7 +52,6 @@ config SYS_CPU
 source "arch/sh/lib/Kconfig"
 
 source "board/renesas/r2dplus/Kconfig"
-source "board/renesas/r7780mp/Kconfig"
 source "board/renesas/sh7752evb/Kconfig"
 source "board/renesas/sh7753evb/Kconfig"
 source "board/renesas/sh7757lcr/Kconfig"
diff --git a/board/renesas/r7780mp/Kconfig b/board/renesas/r7780mp/Kconfig
deleted file mode 100644
index 050cc4cc0f6d..
--- a/board/renesas/r7780mp/Kconfig
+++ /dev/null
@@ -1,12 +0,0 @@
-if TARGET_R7780MP
-
-config SYS_BOARD
-   default "r7780mp"
-
-config SYS_VENDOR
-   default "renesas"
-
-config SYS_CONFIG_NAME
-   default "r7780mp"
-
-endif
diff --git a/board/renesas/r7780mp/MAINTAINERS 
b/board/renesas/r7780mp/MAINTAINERS
deleted file mode 100644
index 56ec21fd32f8..
--- a/board/renesas/r7780mp/MAINTAINERS
+++ /dev/null
@@ -1,7 +0,0 @@
-R7780MP BOARD
-M: Nobuhiro Iwamatsu 
-M: Nobuhiro Iwamatsu 
-S: Maintained
-F: board/renesas/r7780mp/
-F: include/configs/r7780mp.h
-F: configs/r7780mp_defconfig
diff --git a/board/renesas/r7780mp/Makefile b/board/renesas/r7780mp/Makefile
deleted file mode 100644
index 0a387db35d29..
--- a/board/renesas/r7780mp/Makefile
+++ /dev/null
@@ -1,9 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-#
-# Copyright (C) 2007,2008 Nobuhiro Iwamatsu
-#
-# board/r7780mp/Makefile
-#
-
-obj-y  := r7780mp.o
-extra-y+= lowlevel_init.o
diff --git a/board/renesas/r7780mp/lowlevel_init.S 
b/board/renesas/r7780mp/lowlevel_init.S
deleted file mode 100644
index 7be1a1bf0703..
--- a/board/renesas/r7780mp/lowlevel_init.S
+++ /dev/null
@@ -1,356 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2007,2008 Nobuhiro Iwamatsu
- *
- * u-boot/board/r7780mp/lowlevel_init.S
- */
-
-#include 
-#include 
-#include 
-
-/*
- * Board specific low level init code, called _very_ early in the
- * startup sequence. Relocation to SDRAM has not happened yet, no
- * stack is available, bss section has not been initialised, etc.
- *
- * (Note: As no stack is available, no subroutines can be called...).
- */
-
-   .global lowlevel_init
-
-   .text
-   .align  2
-
-lowlevel_init:
-
-   write32 CCR_A, CCR_D/* Address of Cache Control Register */
-   /* Instruction Cache Invalidate */
-
-   write32 FRQCR_A, FRQCR_D/* Frequency control register */
-
-   /* pin_multi_setting */
-   write32 BBG_PMMR_A, BBG_PMMR_D_PMSR1
-
-   write32 BBG_PMSR1_A, BBG_PMSR1_D
-
-   write32 BBG_PMMR_A, BBG_PMMR_D_PMSR2
-
-   write32 BBG_PMSR2_A, BBG_PMSR2_D
-
-   write32 BBG_PMMR_A, BBG_PMMR_D_PMSR3
-
-   write32 BBG_PMSR3_A, BBG_PMSR3_D
-
-   write32 BBG_PMMR_A, BBG_PMMR_D_PMSR4
-
-   write32 BBG_PMSR4_A, BBG_PMSR4_D
-
-   write32 BBG_PMMR_A, BBG_PMMR_D_PMSRG
-
-   write32 BBG_PMSRG_A, BBG_PMSRG_D
-
-   /* cpg_setting */
-   write32 FRQCR_A, FRQCR_D
-
-   write32 DLLCSR_A, DLLCSR_D
-
-   nop
-   nop
-   nop
-   nop
-   nop
-   nop
-   nop
-   nop
-   nop
-   nop
-
-   /* wait 200us */
-   mov.l   REPEAT0_R3, 

Re: [PULL] Pull request for u-boot master / v2021.04 = u-boot-stm32-20210209

[Tom Rini]

On Tue, Feb 09, 2021 at 04:02:30PM +0100, Patrick DELAUNAY wrote:

> 
> Hi Tom,
> 
> Please pull the STM32 related patches for u-boot/master, v2021.04:
> u-boot-stm32-20210209
> 
> - Enable the fastboot oem commands in stm32mp15 defconfig
> - Fixes pinctrol for stmfx and stm32
> - Add support of I2C6_K in stm32mp15 clock driver
> - Alignment with Linux kernel device tree v5.11-rc2 for ST boards
> 
> CI status:
> https://gitlab.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/6326
> 
> Thanks,
> Patric
> 
> git request-pull origin/master
> https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git
> u-boot-stm32-20210209
> 
> The following changes since commit e14d5762de1db84cae6d84d59c1e40f3eb26c4c3:
> 
>   Merge git://git.denx.de/u-boot-marvell (2021-02-08 10:55:51 -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git
> tags/u-boot-stm32-20210209
> 
> for you to fetch changes up to f050e3fe4552dc8e24b1f01d26b835eeb762c467:
> 
>   arm: dts: stm32mp15: alignment with v5.11-rc2 (2021-02-09 10:56:06 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 1/3] dm: i2c: allow disabling driver model in SPL

[Tom Rini]

On Tue, Feb 09, 2021 at 01:52:43PM +0200, Igor Opaniuk wrote:

> From: Igor Opaniuk 
> 
> At present if U-Boot proper uses driver model for I2C, then SPL has to
> also. While this is desirable, it places a significant barrier to moving
> to driver model in some cases. For example, with a space-constrained SPL
> it may be necessary to enable CONFIG_SPL_OF_PLATDATA which involves
> adjusting some drivers.
> 
> This patch introduces a separate Kconfig symbols for enabling DM_I2C and
> DM_I2C_GPIO support in SPL.
> 
> This will also help to get away from dirty workarounds to
> achieve non-DM I2C support for SPL, which is currently used in some
> board header files like:
> 
> ifdef CONFIG_SPL_BUILD
> undef CONFIG_DM_I2C
> endif
> 
> Reviewed-by: Simon Glass 
> Reviewed-by: Heiko Schocher 
> Signed-off-by: Igor Opaniuk 
> 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 2/3] board: freescale: drop CONFIG_DM_I2C undefs

[Tom Rini]

On Tue, Feb 09, 2021 at 01:52:44PM +0200, Igor Opaniuk wrote:

> From: Igor Opaniuk 
> 
> Drop CONFIG_DM_I2C undefs from board header files, and make them
> disabled on these boards in defconfigs instead.
> 
> Disabling on Kconfig symbol was done automatically with this script:
> 
> cd configs
> files=(*ls1046a*)
> files2=(*T104*RDB*)
> files3=(ls1021atwr_*)
> files4=("imx8mp_evk_defconfig phycore-imx8mp_defconfig")
> combine=("${files[@]}" "${files2[@]}" "${files3[@]}" "${files4[@]}")
> cd ..
> 
> for item in ${combine[*]}
> do
>echo "Adjusting  $item"
>echo "# CONFIG_SPL_DM_I2C is not set" >> configs/$item
>make $item && make savedefconfig && cp defconfig configs/$item
> done
> 
> Signed-off-by: Igor Opaniuk 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 1/1] timer: imx-gpt: Add timer support for i.MX SoCs family

[Giulio Benetti]

On 2/10/21 1:04 AM, Jesse Taube wrote:

This timer driver is using GPT Timer (General Purpose Timer) available on 
almost all i.MX SoCs family.
Since this driver is only meant to provide u-boot's timer and counter, and most 
of the i.MX* SoCs use a 24Mhz crystal, let's only deal with that specific 
source.


We have a problem with columns on commit log, they shouldn't be longer 
than 72 cols, so please check the editor you're using for commit log 
writing and set 72 cols costrains. I use nano and you only need to set 
in .gitconfig under [core]:

editor = nano -b -r 72

This way nano automatically put a CR.



Signed-off-by: Giulio Benetti 
Signed-off-by: Jesse Taube 

---
  drivers/timer/Kconfig |   7 ++
  drivers/timer/Makefile|   1 +
  drivers/timer/imx-gpt-timer.c | 132 ++
  3 files changed, 140 insertions(+)
  create mode 100644 drivers/timer/imx-gpt-timer.c

diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index 80743a2551..ee81dfa776 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -227,4 +227,11 @@ config MCHP_PIT64B_TIMER
  Select this to enable support for Microchip 64-bit periodic
  interval timer.
  
+config IMX_GPT_TIMER

+   bool "NXP i.MX GPT timer support"
+   depends on TIMER
+   help
+ Select this to enable support for the timer found on
+ NXP i.MX devices.
+
  endmenu
diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
index eb5c48cc6c..e214ba7268 100644
--- a/drivers/timer/Makefile
+++ b/drivers/timer/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_STM32_TIMER) += stm32_timer.o
  obj-$(CONFIG_X86_TSC_TIMER)   += tsc_timer.o
  obj-$(CONFIG_MTK_TIMER)   += mtk_timer.o
  obj-$(CONFIG_MCHP_PIT64B_TIMER)   += mchp-pit64b-timer.o
+obj-$(CONFIG_IMX_GPT_TIMER)+= imx-gpt-timer.o
diff --git a/drivers/timer/imx-gpt-timer.c b/drivers/timer/imx-gpt-timer.c
new file mode 100644
index 00..58c37db300
--- /dev/null
+++ b/drivers/timer/imx-gpt-timer.c
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020
+ * Author(s): Giulio Benetti 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define GPT_CR_SWR 0x8000
+#define GPT_CR_CLKSRC  0x01C0
+#define GPT_CR_EN_24M  0x4000
+#define GPT_CR_EN  0x0001
+#define GPT_PR_PRESCALER   0x0FFF
+#define GPT_PR_PRESCALER24M0xF000


Here ^^^ and


+#define NO_CLOCK   (0)
+#define IPG_CLK(1 << 6)
+#define IPG_CLK_HF (2 << 6)
+#define IPG_EXT(3 << 6)
+#define IPG_CLK_32K(4 << 6)
+#define IPG_CLK_24M(5 << 6)


here you still have different tab numbers. Enable in your editor the
option to show whitespaces and tabs, that way everything it easier.


+
+struct imx_gpt_timer_regs {
+   u32 cr;
+   u32 pr;
+   u32 sr;
+   u32 ir;
+   u32 ocr1;
+   u32 ocr2;
+   u32 ocr3;
+   u32 icr1;
+   u32 icr2;
+   u32 cnt;
+};
+
+struct imx_gpt_timer_priv {
+   struct imx_gpt_timer_regs *base;
+};
+
+static u64 imx_gpt_timer_get_count(struct udevice *dev)
+{
+   struct imx_gpt_timer_priv *priv = dev_get_priv(dev);
+   struct imx_gpt_timer_regs *regs = priv->base;
+
+   return readl(>cnt);
+}
+
+static int imx_gpt_timer_probe(struct udevice *dev)
+{
+   struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+   struct imx_gpt_timer_priv *priv = dev_get_priv(dev);
+   struct imx_gpt_timer_regs *regs;
+   struct clk clk;
+   fdt_addr_t addr;
+   u32 prescaler;
+   u32 rate;
+   int ret;
+
+   addr = dev_read_addr(dev);
+   if (addr == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   priv->base = (struct imx_gpt_timer_regs *)addr;
+
+   ret = clk_get_by_index(dev, 0, );
+   if (ret < 0)
+   return ret;
+
+   ret = clk_enable();
+   if (ret) {
+   dev_err(dev, "Failed to enable clock\n");
+   return ret;
+   }
+
+   regs = priv->base;
+
+   /* Reset the timer */
+   setbits_le32(>cr, GPT_CR_SWR);
+
+   /* Wait for timer to finish reset */
+   while (readl(>cr) & GPT_CR_SWR)
+   ;
+
+   /* Get timer clock rate */
+   rate = clk_get_rate();


clk_get_rate() has a wrong description in include/clk.h saying:
"@return clock rate in Hz, or -ve error code."

This^^^ is wrong.
If you dig into drivers/clk/clk-uclass.c and look for clk_get_rate(), 
you will see that it returns 0 on error and > 0 if succesfull.


I've just sent a patch for this:

[PATCH] arm: dts: allwinner: sync from linux for RGMII RX/TX delay fixes

[Peter Robinson]

Sync over a subset of the AllWinner dts changes from Linux 5.11
for the RGMII RX/TX delay network fixes.

This pulls other bits in needed to sync the whole files, the bits
are other minor fixes, or pieces of DT that don't affect U-Boot.

Signed-off-by: Peter Robinson 
---

When booting using EBBR with a 5.10 kernel we end up with network issues
on a number of the Allwinner devices as the U-Boot DT doesn't have the
RGMII fixups. This is a partial sync of the affected devices and the any
.dtsi bits needed so as to not tear up the linux DT's. Most of the rest
of the changes appear pretty benign so I didn't feel it was too much
of an issue.

 arch/arm/dts/axp81x.dtsi  |   9 +
 arch/arm/dts/sun50i-a64-bananapi-m64.dts  |  10 +-
 arch/arm/dts/sun50i-a64-orangepi-win.dts  |  10 +-
 arch/arm/dts/sun50i-a64-pine64-plus.dts   |   2 +-
 arch/arm/dts/sun50i-a64-sopine-baseboard.dts  |  10 +-
 arch/arm/dts/sun50i-a64.dtsi  |  34 +-
 .../dts/sun50i-h5-bananapi-m2-plus-v1.2.dts   |   1 +
 .../arm/dts/sun50i-h5-libretech-all-h5-cc.dts |   2 +-
 arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts   |   2 +-
 arch/arm/dts/sun50i-h5-orangepi-pc2.dts   |  23 +-
 arch/arm/dts/sun50i-h5-orangepi-prime.dts |   2 +-
 .../arm/dts/sun50i-h5-orangepi-zero-plus2.dts |  38 +++
 arch/arm/dts/sun7i-a20-bananapi-m1-plus.dts   |  14 +-
 arch/arm/dts/sun7i-a20-bananapi.dts   |  24 +-
 arch/arm/dts/sun7i-a20-bananapro.dts  |  14 +-
 arch/arm/dts/sun7i-a20-cubieboard2.dts|  24 +-
 arch/arm/dts/sun7i-a20-cubietruck.dts |  14 +-
 arch/arm/dts/sun7i-a20-hummingbird.dts|  21 +-
 arch/arm/dts/sun7i-a20-i12-tvbox.dts  |  12 +-
 arch/arm/dts/sun7i-a20-icnova-swac.dts|  15 +-
 arch/arm/dts/sun7i-a20-itead-ibox.dts |   4 +-
 arch/arm/dts/sun7i-a20-lamobo-r1.dts  |  14 +-
 arch/arm/dts/sun7i-a20-m3.dts |  12 +-
 arch/arm/dts/sun7i-a20-olimex-som-evb.dts |  12 +-
 arch/arm/dts/sun7i-a20-olimex-som204-evb.dts  |  24 +-
 arch/arm/dts/sun7i-a20-olinuxino-lime.dts |  30 +-
 arch/arm/dts/sun7i-a20-olinuxino-lime2.dts|  44 +--
 arch/arm/dts/sun7i-a20-olinuxino-micro.dts|  30 +-
 arch/arm/dts/sun7i-a20-orangepi-mini.dts  |  24 +-
 arch/arm/dts/sun7i-a20-orangepi.dts   |  24 +-
 arch/arm/dts/sun7i-a20-pcduino3-nano.dts  |  28 +-
 arch/arm/dts/sun7i-a20-pcduino3.dts   |  24 +-
 arch/arm/dts/sun7i-a20-wexler-tab7200.dts |  12 +-
 arch/arm/dts/sun7i-a20-wits-pro-a20-dkt.dts   |  24 +-
 arch/arm/dts/sun7i-a20.dtsi   | 218 +++-
 arch/arm/dts/sun8i-a83t-bananapi-m3.dts   |  53 ++-
 arch/arm/dts/sun8i-a83t-cubietruck-plus.dts   |  71 +++-
 arch/arm/dts/sun8i-a83t.dtsi  | 310 --
 arch/arm/dts/sun8i-h3-orangepi-pc-plus.dts|   5 -
 arch/arm/dts/sun8i-h3-orangepi-plus2e.dts |   2 +-
 arch/arm/dts/sun8i-h3-orangepi-zero-plus2.dts |  38 +++
 arch/arm/dts/sun8i-v40-bananapi-m2-berry.dts  |  12 +-
 arch/arm/dts/sunxi-bananapi-m2-plus.dtsi  |   2 +-
 43 files changed, 947 insertions(+), 351 deletions(-)

diff --git a/arch/arm/dts/axp81x.dtsi b/arch/arm/dts/axp81x.dtsi
index 043c717dce..1dfeeceabf 100644
--- a/arch/arm/dts/axp81x.dtsi
+++ b/arch/arm/dts/axp81x.dtsi
@@ -48,6 +48,11 @@
interrupt-controller;
#interrupt-cells = <1>;
 
+   ac_power_supply: ac-power-supply {
+   compatible = "x-powers,axp813-ac-power-supply";
+   status = "disabled";
+   };
+
axp_adc: adc {
compatible = "x-powers,axp813-adc";
#io-channel-cells = <1>;
@@ -166,4 +171,8 @@
status = "disabled";
};
};
+
+   usb_power_supply: usb-power-supply {
+   compatible = "x-powers,axp813-usb-power-supply";
+   };
 };
diff --git a/arch/arm/dts/sun50i-a64-bananapi-m64.dts 
b/arch/arm/dts/sun50i-a64-bananapi-m64.dts
index 883f217efb..e5e840b9fb 100644
--- a/arch/arm/dts/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm/dts/sun50i-a64-bananapi-m64.dts
@@ -105,7 +105,7 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-   phy-mode = "rgmii";
+   phy-mode = "rgmii-id";
phy-handle = <_rgmii_phy>;
phy-supply = <_dc1sw>;
status = "okay";
@@ -331,10 +331,10 @@
"Microphone", "Microphone Jack",
"Microphone", "Onboard Microphone";
simple-audio-card,routing =
-   "Left DAC", "AIF1 Slot 0 Left",
-   "Right DAC", "AIF1 Slot 0 Right",
-   "AIF1 Slot 0 Left ADC", "Left ADC",
-   "AIF1 Slot 0 Right ADC", "Right ADC",
+   "Left DAC", "DACL",
+   "Right DAC", "DACR",
+   "ADCL", "Left ADC",
+   "ADCR", "Right ADC",
"Headphone 

[PATCH] clk: fix clk_get_rate() documentation

[Giulio Benetti]

clk_get_rate() can't and doesn't return -ve on error, it actually returns 0
on error or a value greater than 0 on success. So let's fix its
documentation.

Signed-off-by: Giulio Benetti 
---
 include/clk.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/clk.h b/include/clk.h
index ca6b85fa6f..a833d6a27b 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -344,7 +344,7 @@ int clk_free(struct clk *clk);
  *
  * @clk:   A clock struct that was previously successfully requested by
  * clk_request/get_by_*().
- * @return clock rate in Hz, or -ve error code.
+ * @return clock rate in Hz on success, or 0 on error.
  */
 ulong clk_get_rate(struct clk *clk);
 
-- 
2.25.1

Re: [PATCH 16/25] arm: Remove gwventana boards

[Tom Rini]

On Wed, Feb 10, 2021 at 09:29:44AM -0800, Tim Harvey wrote:
> On Tue, Feb 9, 2021 at 5:03 AM Tom Rini  wrote:
> >
> > These boards have not been converted to CONFIG_DM_MMC by the deadline of
> > v2019.04, which is almost two years ago.  In addition there are other DM
> > migrations it is also missing.  Remove them.
> >
> > Cc: Tim Harvey 
> > Signed-off-by: Tom Rini 
> > ---
> >  arch/arm/mach-imx/mx6/Kconfig   |1 -
> >  board/gateworks/gw_ventana/Kconfig  |   28 -
> >  board/gateworks/gw_ventana/MAINTAINERS  |8 -
> >  board/gateworks/gw_ventana/Makefile |   11 -
> >  board/gateworks/gw_ventana/README   |  320 
> >  board/gateworks/gw_ventana/common.c | 1760 ---
> >  board/gateworks/gw_ventana/common.h |   99 --
> >  board/gateworks/gw_ventana/eeprom.c |  266 ---
> >  board/gateworks/gw_ventana/gsc.c|  283 ---
> >  board/gateworks/gw_ventana/gsc.h|   71 -
> >  board/gateworks/gw_ventana/gw_ventana.c | 1381 ---
> >  board/gateworks/gw_ventana/gw_ventana_spl.c |  779 
> >  board/gateworks/gw_ventana/ventana_eeprom.h |  140 --
> >  configs/gwventana_emmc_defconfig|  111 --
> >  configs/gwventana_gw5904_defconfig  |  115 --
> >  configs/gwventana_nand_defconfig|  115 --
> >  include/configs/gw_ventana.h|  298 
> >  17 files changed, 5786 deletions(-)
> >  delete mode 100644 board/gateworks/gw_ventana/Kconfig
> >  delete mode 100644 board/gateworks/gw_ventana/MAINTAINERS
> >  delete mode 100644 board/gateworks/gw_ventana/Makefile
> >  delete mode 100644 board/gateworks/gw_ventana/README
> >  delete mode 100644 board/gateworks/gw_ventana/common.c
> >  delete mode 100644 board/gateworks/gw_ventana/common.h
> >  delete mode 100644 board/gateworks/gw_ventana/eeprom.c
> >  delete mode 100644 board/gateworks/gw_ventana/gsc.c
> >  delete mode 100644 board/gateworks/gw_ventana/gsc.h
> >  delete mode 100644 board/gateworks/gw_ventana/gw_ventana.c
> >  delete mode 100644 board/gateworks/gw_ventana/gw_ventana_spl.c
> >  delete mode 100644 board/gateworks/gw_ventana/ventana_eeprom.h
> >  delete mode 100644 configs/gwventana_emmc_defconfig
> >  delete mode 100644 configs/gwventana_gw5904_defconfig
> >  delete mode 100644 configs/gwventana_nand_defconfig
> >  delete mode 100644 include/configs/gw_ventana.h
> >
> 
> Tom,
> 
> I will submit a patchset to convert the gw_ventana IMX6 based boards
> to DM. I started this effort over a year ago and got stuck at some
> point but I think I know how to get through that now.
> 
> I hope to be able to submit something by the end of next week.

Thanks!  Their conversion will help unblock a few of the older
migrations.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 16/25] arm: Remove gwventana boards

[Tim Harvey]

On Tue, Feb 9, 2021 at 5:03 AM Tom Rini  wrote:
>
> These boards have not been converted to CONFIG_DM_MMC by the deadline of
> v2019.04, which is almost two years ago.  In addition there are other DM
> migrations it is also missing.  Remove them.
>
> Cc: Tim Harvey 
> Signed-off-by: Tom Rini 
> ---
>  arch/arm/mach-imx/mx6/Kconfig   |1 -
>  board/gateworks/gw_ventana/Kconfig  |   28 -
>  board/gateworks/gw_ventana/MAINTAINERS  |8 -
>  board/gateworks/gw_ventana/Makefile |   11 -
>  board/gateworks/gw_ventana/README   |  320 
>  board/gateworks/gw_ventana/common.c | 1760 ---
>  board/gateworks/gw_ventana/common.h |   99 --
>  board/gateworks/gw_ventana/eeprom.c |  266 ---
>  board/gateworks/gw_ventana/gsc.c|  283 ---
>  board/gateworks/gw_ventana/gsc.h|   71 -
>  board/gateworks/gw_ventana/gw_ventana.c | 1381 ---
>  board/gateworks/gw_ventana/gw_ventana_spl.c |  779 
>  board/gateworks/gw_ventana/ventana_eeprom.h |  140 --
>  configs/gwventana_emmc_defconfig|  111 --
>  configs/gwventana_gw5904_defconfig  |  115 --
>  configs/gwventana_nand_defconfig|  115 --
>  include/configs/gw_ventana.h|  298 
>  17 files changed, 5786 deletions(-)
>  delete mode 100644 board/gateworks/gw_ventana/Kconfig
>  delete mode 100644 board/gateworks/gw_ventana/MAINTAINERS
>  delete mode 100644 board/gateworks/gw_ventana/Makefile
>  delete mode 100644 board/gateworks/gw_ventana/README
>  delete mode 100644 board/gateworks/gw_ventana/common.c
>  delete mode 100644 board/gateworks/gw_ventana/common.h
>  delete mode 100644 board/gateworks/gw_ventana/eeprom.c
>  delete mode 100644 board/gateworks/gw_ventana/gsc.c
>  delete mode 100644 board/gateworks/gw_ventana/gsc.h
>  delete mode 100644 board/gateworks/gw_ventana/gw_ventana.c
>  delete mode 100644 board/gateworks/gw_ventana/gw_ventana_spl.c
>  delete mode 100644 board/gateworks/gw_ventana/ventana_eeprom.h
>  delete mode 100644 configs/gwventana_emmc_defconfig
>  delete mode 100644 configs/gwventana_gw5904_defconfig
>  delete mode 100644 configs/gwventana_nand_defconfig
>  delete mode 100644 include/configs/gw_ventana.h
>

Tom,

I will submit a patchset to convert the gw_ventana IMX6 based boards
to DM. I started this effort over a year ago and got stuck at some
point but I think I know how to get through that now.

I hope to be able to submit something by the end of next week.

Best regards,

Tim

[PATCH v2] config: hikey: convert to DM_USB and DM_ETH

[Peter Robinson]

Convert the hikey to use DM_USB and DM_ETH.

Conversion based on rpi as it has a similar DWC config.

Signed-off-by: Peter Robinson 
---

v2: fix copy paste error

 configs/hikey_defconfig | 2 ++
 include/configs/hikey.h | 4 +---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/configs/hikey_defconfig b/configs/hikey_defconfig
index 5fb48238ec..280a59a748 100644
--- a/configs/hikey_defconfig
+++ b/configs/hikey_defconfig
@@ -25,7 +25,9 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_K3=y
 CONFIG_CONS_INDEX=4
+CONFIG_DM_ETH=y
 CONFIG_USB=y
+CONFIG_DM_USB=y
 CONFIG_USB_DWC2=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
diff --git a/include/configs/hikey.h b/include/configs/hikey.h
index a323a0bf69..659fbee052 100644
--- a/include/configs/hikey.h
+++ b/include/configs/hikey.h
@@ -47,9 +47,7 @@
 /* Size of malloc() pool */
 #define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + SZ_8M)
 
-#ifdef CONFIG_CMD_USB
-#define CONFIG_USB_DWC2_REG_ADDR 0xF72C
-/*#define CONFIG_DWC2_DFLT_SPEED_FULL*/
+#ifdef CONFIG_USB_DWC2
 #define CONFIG_DWC2_ENABLE_DYNAMIC_FIFO
 #endif
 
-- 
2.29.2

Re: [PATCH v2 0/1] Add driver support for the IMX General Purpose Timer (GPT) available

[Giulio Benetti]

On 2/10/21 1:04 AM, Jesse Taube wrote:

Giulio Benetti (3):
   timer: imx-gpt: Add timer support for i.MX SoCs family

Jesse Taube (1):
   timer: imx-gpt: Add timer support for i.MX SoCs family


There's something strange here, patchset is malformed since above there 
are 4 patches listed while subject speaks about only 1 patch 0/1.


So please, try to fix it while sending to yourself with git send-mail 
--to "you", otherwise you spam ML.



  drivers/timer/Kconfig |   7 ++
  drivers/timer/Makefile|   1 +
  drivers/timer/imx-gpt-timer.c | 132 ++
  3 files changed, 140 insertions(+)
  create mode 100644 drivers/timer/imx-gpt-timer.c

---
V1->V2:
* Fixed indentation
* Fixed capitals
* Made timer work on only 24MHz clock


This is the right way.

Best regards
--
Giulio Benetti
Benetti Engineering sas

[PATCH] config: hikey: convert to DM_USB and DM_ETH

[Peter Robinson]

Convert the hikey to use DM_USB and DM_ETH.

Conversion based on rpi as it has a similar DWC config.

Signed-off-by: Peter Robinson 
---
 configs/hikey_defconfig | 2 ++
 include/configs/hikey.h | 4 +---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/configs/hikey_defconfig b/configs/hikey_defconfig
index 5fb48238ec..280a59a748 100644
--- a/configs/hikey_defconfig
+++ b/configs/hikey_defconfig
@@ -25,7 +25,9 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_K3=y
 CONFIG_CONS_INDEX=4
+CONFIG_DM_ETH=y
 CONFIG_USB=y
+CONFIG_DM_USB=y
 CONFIG_USB_DWC2=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
diff --git a/include/configs/hikey.h b/include/configs/hikey.h
index a323a0bf69..058e4d7830 100644
--- a/include/configs/hikey.h
+++ b/include/configs/hikey.h
@@ -47,9 +47,7 @@
 /* Size of malloc() pool */
 #define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + SZ_8M)
 
-#ifdef CONFIG_CMD_USB
-#define CONFIG_USB_DWC2_REG_ADDR 0xF72C
-/*#define CONFIG_DWC2_DFLT_SPEED_FULL*/
+#ifdef CONFIG_USB_DWC2=y
 #define CONFIG_DWC2_ENABLE_DYNAMIC_FIFO
 #endif
 
-- 
2.29.2

Re: [PATCH u-boot] fs: btrfs: do not fail when offset of a ROOT_ITEM is not -1

[Marek Behun]

On Wed, 10 Feb 2021 09:20:11 +0800
Qu Wenruo  wrote:

> You're correct, the kernel is using new schema, btrfs_get_fs_root(), 
> which only requires root objectid and completely get rid of the 
> offset/type, which is far less possible to call with wrong parameters.
> 
> It would be a good timing to sync the code between kernel and 
> progs/u-boot now.

So do you agree with this patch? If so, can you add Reviewed-by? Thanks.

Re: [PATCH] efidebug: Introduce bootmgr command

[Wolfgang Denk]

Dear Heinrich,

In message <9966b14a-43ef-42ad-dda4-d40b5e3b9...@gmx.de> you wrote:
>
> > For backward compatibility e. g. 'efidebug' could be kept, but the
> > new name would be 'efi debug'; likewise, your new command would be
> > 'efi bootmgr' [or just 'efi boot' ?]
...
>
> what is the benefit for the user to have a single command with an
> endless list of options?
>
> I can't see any.

You miss the point.  The complexisty for the user will be the
same; as is, we already have a single command whichimplements a
number of different functions as one big monolithig block of code.

What we are discussing here is to split this into logical
components, each implementing one specific function only.

The suggested change will not make things any harder to the user, on
contrary, it has the chance to make it easier andmore consistent to
use.

Also, it's not options, but separate commands grouped into one topic.

Advantages are:

- maintenance: it is much easier to maintain and debug a number of
  separate functions than monster spaghetti code
- configurability: you can select needed / unselect unnecessary sub
  commands
- memory footprint: comes with configurability
- style: it follows existing practise.

Just to name a few.

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
When the tide of life turns against you
And the current upsets your boat
Don't waste tears on what might have been
Just lie on your back and float.

Re: [PATCH] efidebug: Introduce bootmgr command

[Wolfgang Denk]

Dear Ilias,

In message  you wrote:
>
> > In this case, "debug" would just be a sub-command of the "efi"
> > command, with more sub-commands under efi (like bootmgr or such)
> > following, same as we did for example with "env" (where many
> > commands maintain backward compatibility, but here this was
> > necessary because these have been in use forever):
> > 
> > env print   -> printenv
> > env save-> saveenv
> > env set -> setenv
> > 
>
> Yes, but it would still look a bit strange, because the efidebug command was
> overloaded in our case. So you could test capsules, set EFI bootmgr variables,
> dump EFI tables amongst other things. The saveenv & friends had a tightly
> defined scope already. 
> So that would require a lot of code to keep the convention running, but since 
> it's rarely used, I don't think it's worth the effort or the additional
> complexity (once again unless someone has a valid reason), hence my suggestion
> to define it properly while we still have time.

Indeed - if it was rarely used before, it makes a lot of sense to
break combined functionality into separate subcommands (probably
also with separate Kconfig options so you can select what you really
need only).

Thanks!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The biggest difference between time and space is that you can't reuse
time. - Merrick Furst

Re: [PATCH] efidebug: Introduce bootmgr command

[Ilias Apalodimas]

Hi Akashi, 

On Wed, Feb 10, 2021 at 09:50:33PM +0900, AKASHI Takahiro wrote:
> On Wed, Feb 10, 2021 at 01:53:55PM +0200, Ilias Apalodimas wrote:
> > Hi Wolfgang,
> > 
> > Thanks for having a look, 
> > 
> > On Wed, Feb 10, 2021 at 12:23:47PM +0100, Wolfgang Denk wrote:
> > > Dear Ilias,
> > > 
> > > In message <20210210105425.356131-1-ilias.apalodi...@linaro.org> you 
> > > wrote:
> > > > Up to now we've been adding all the efi related configuration to
> > > > 'efidebug' command.  The command name feels a bit weird to configure 
> > > > boot
> > > > manager related commands.  Since the bootmanager is growing and we 
> > > > intend
> 
> I developed the command as a poorman's "efishell" as, at that time,
> EDK2's shell didn't work well on U-Boot UEFI subsystem.
> 
> As far as I remember, Alex (ex-maintainer) didn't like to take this
> command, including "efidebug boot" subcommand, as a standard U-Boot command.
> 

UEFI has grown substantially since then though and we can now use it to
install full distros. Having a command named 'efidebug' is the last place some
would look to configure boot options. Does it only feel weird to me?

> > > > to extend it with features like defining the initrd we want to expose to
> > > > the kernel, it would make sense to split it on a command of it's own.
> > > >
> > > > So let's introduce a new command called bootmgr and move all of the
> > > > existing Boot manager functionality there.
> > > 
> > > As this is EFI specific, I would appreciate to have "efi" in the
> > > command name, too.
> > > 
> > > Maybe all EFi related commands should be collected as "efi "
> > > like we did it with the "env" commands long ago.
> > 
> > We could, I'll discuss this with Heinrich and see what he thinks.
> > 
> > > 
> > > For backward compatibility e. g. 'efidebug' could be kept, but the
> > > new name would be 'efi debug'; likewise, your new command would be
> > > 'efi bootmgr' [or just 'efi boot' ?]
> 
> As a matter of fact, "efi" is even now recognized as "efidebug" thanks to
> command name completion as there is no other "efi*" command.
> 
> Then,
>   efidebug boot ..., and
>   [efi]bootmgr boot ...
> can be invoked literally as
>   efi boot ...
> 
> So I don't see much advantage to Ilias' proposal.
> 

Breaking the code in smaller, readable files, looked like a better option.
I'd much prefer it over a single huge file implementing a variety of
commands completely unrelated to each other, just because 'everything belongs
to the efi spec'.
It would also make our life and readability a lot easier in case we want to
include specific commands on a built. The alternative you propose implies a 
file full of ifdefs, while we could just control them with Kconfig options 
and makefiles.

> My suggestions are:
> * alias "efi" to "efidebug" (if preferred),
> * add new configuration options for efidebug's subcommands,
> * only enable "boot"-related options by default (if needed)
> 
> Personally, I don't like to move the portion of code from one file
> to another since it will break git history.
> 

How? The commit message clearly says "move the bootmgr functions to a diffrent 
file" 
and the git log on efidebug will clear that up. It will even show the file that 
was
moved to.

> In addition, I have proposed to make "bootefi bootmgr" a standalone
> command/application, but Heinrich rejected it.

That's a different discussion, but if you go down that road you'd have to move
the 'bootefi selftest' as well?

> Given Ilias' concern(?), I still believe that the change is logical
> and makes more sense.

My concern here is to help people wanting to use the bootmgr. I don't have a
strong opinion on how that eventually can be implemented and that's why I am
open to suggestions.  For the record I do prefer seperate commands, maybe even
prefixed by efi to make the distinction clear between u-boot native and EFI
related commands.

Cheers
/Ilias
> 
> -Takahiro Akashi
> 
> > 
> > The efidebug for boot options wasn't introduced that long ago and I don't
> > think anyone uses it in production.  If someone would want to have it 
> > backwards 
> > compatible, please shout and we'll see what we can do, but I'd strongly 
> > prefer 
> > replacing it overall. If we truly want backwards compatibility though we 
> > must keep
> > efidebug, changing the name to something like 'efi debug' just for the name
> > similarity wouldn't help much as it would break things regardless.
> > 
> > Heinrich feel free to ignore the followup patch fixing the documentation of
> > efidebug.  I'll change the name to something we all agree and fold in the 
> > doc
> > changes in v2.
> > 
> > Thanks
> > /Ilias
> > > 
> > > Thanks!
> > > 
> > > 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
> > > In my experience the best way to get 

Re: [PATCH u-boot-dm + u-boot-spi v2 0/7] Support SPI NORs and OF partitions in `mtd list`

[Marek Behun]

On Wed, 10 Feb 2021 15:31:56 +0100
Patrice CHOTARD  wrote:

> and what about @ as shown in my previous email 
> ?

And there is a second problem with this: this can be bad for automatic
U-Boot scripts.

For example on Turris Omnia there are boards which were manufactured
with a Macronix SPI-NOR, and boards which were manufactured with
Winbond SPI-NOR (or Spansion or something different from Macronix).

So I think that there should be some mechanism available via the mtd
command to select the SPI-NOR by its chip select somehow, without
knowing the SPI ID.

Re: [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"

[Marek Vasut]

On 2/10/21 3:48 PM, Tom Rini wrote:

On Wed, Feb 10, 2021 at 03:27:22PM +0100, Marek Vasut wrote:

On 2/10/21 3:13 PM, Tom Rini wrote:

On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:

Hi Simon,

On Sun, Feb 7, 2021 at 11:34 PM Simon Glass  wrote:


Hi Bin,

On Sun, 7 Feb 2021 at 08:11, Bin Meng  wrote:


This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.

Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
changes 'struct pci_controller'.regions from pre-allocated array of
regions to dynamically allocated, which unfortunately broken lots of
boards that still use the non-DM PCI driver.

We may update every non-DM PCI board codes to do the dynamical
allocation of PCI regions but that's a lot of work (e.g.: almost
all Freescale PowerPC boards are broken now and need to be fixed).
Let's do the easy way.


No one has noticed since July, apparently. I think it would be better
to disable PCI on these boards, until either someone migrates them or
they are removed. The PCI deadline was about 18 months ago.



Yep, but I'd like to keep this revert instead of just fixing the
qemu-ppce500 here, to give people a chance to test their original
non-DM version of PCI driver before the DM conversion.

Once all boards have converted to DM PCI, we can revert this revert patch again.


Tom, do you know the situation here?


So, I made a lack of DM_PCI migration be fatal and got a build done
here:
https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348

Of note, MIPS malta fails, so I had to drop that from pytest to complete
the world build.  There's then a handful of ARM boards, another large
chunk of PowerPC, and then a few others such as r7780mp.  SH is the big
what to do here to me, other than PowerPC, as other than r2dplus
everything is missing the main "convert to DM" migration deadline as
well.


Anything SH except r2dplus is likely dead.


Shall I send a series to remove most of the boards then?


You can.

Re: [PATCH u-boot-dm + u-boot-spi v2 0/7] Support SPI NORs and OF partitions in `mtd list`

[Marek Behun]

On Wed, 10 Feb 2021 15:31:56 +0100
Patrice CHOTARD  wrote:

> > So one solution is to use device-tree name to select the NOR, but still
> > print the name determined from SPI ID somewhere.
> > 
> > Second solution is to allow selecting the SPI by number, i.e. (the n-th
> > enumerated SPI).  
> 
> and what about @ as shown in my previous email 
> ?

That could be one solution, but there would still be a collision if
there were multiple SPI controllers. It is possible to have two
identical SPI-NORs connected to 2 different SPI controllers on the same
chip select. But maybe this situation is rare enough that we can ignore
it.

Re: [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"

[Tom Rini]

On Wed, Feb 10, 2021 at 03:27:22PM +0100, Marek Vasut wrote:
> On 2/10/21 3:13 PM, Tom Rini wrote:
> > On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
> > > Hi Simon,
> > > 
> > > On Sun, Feb 7, 2021 at 11:34 PM Simon Glass  wrote:
> > > > 
> > > > Hi Bin,
> > > > 
> > > > On Sun, 7 Feb 2021 at 08:11, Bin Meng  wrote:
> > > > > 
> > > > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> > > > > 
> > > > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI 
> > > > > regions")
> > > > > changes 'struct pci_controller'.regions from pre-allocated array of
> > > > > regions to dynamically allocated, which unfortunately broken lots of
> > > > > boards that still use the non-DM PCI driver.
> > > > > 
> > > > > We may update every non-DM PCI board codes to do the dynamical
> > > > > allocation of PCI regions but that's a lot of work (e.g.: almost
> > > > > all Freescale PowerPC boards are broken now and need to be fixed).
> > > > > Let's do the easy way.
> > > > 
> > > > No one has noticed since July, apparently. I think it would be better
> > > > to disable PCI on these boards, until either someone migrates them or
> > > > they are removed. The PCI deadline was about 18 months ago.
> > > > 
> > > 
> > > Yep, but I'd like to keep this revert instead of just fixing the
> > > qemu-ppce500 here, to give people a chance to test their original
> > > non-DM version of PCI driver before the DM conversion.
> > > 
> > > Once all boards have converted to DM PCI, we can revert this revert patch 
> > > again.
> > > 
> > > > Tom, do you know the situation here?
> > 
> > So, I made a lack of DM_PCI migration be fatal and got a build done
> > here:
> > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
> > 
> > Of note, MIPS malta fails, so I had to drop that from pytest to complete
> > the world build.  There's then a handful of ARM boards, another large
> > chunk of PowerPC, and then a few others such as r7780mp.  SH is the big
> > what to do here to me, other than PowerPC, as other than r2dplus
> > everything is missing the main "convert to DM" migration deadline as
> > well.
> 
> Anything SH except r2dplus is likely dead.

Shall I send a series to remove most of the boards then?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH u-boot-dm + u-boot-spi v2 0/7] Support SPI NORs and OF partitions in `mtd list`

[Patrice CHOTARD]

Hi Marek

On 2/10/21 3:14 PM, Marek Behun wrote:
> On Wed, 10 Feb 2021 14:48:23 +0100
> Patrice CHOTARD  wrote:
> 
>> +Patrick
>>
>> Hi All
>>
>> I have tested this series on stm32mp1-ev1 board which embeds 1 nand and 2 
>> identical spi-nor. 
>> spi-nor DT node is the following:
>>
>>  {
>>  pinctrl-names = "default", "sleep";
>>  pinctrl-0 = <_clk_pins_a _bk1_pins_a _bk2_pins_a>;
>>  pinctrl-1 = <_clk_sleep_pins_a _bk1_sleep_pins_a 
>> _bk2_sleep_pins_a>;
>>  reg = <0x58003000 0x1000>, <0x7000 0x400>;
>>  #address-cells = <1>;
>>  #size-cells = <0>;
>>  status = "okay";
>>
>>  flash0: mx66l51235l@0 {
>>  compatible = "jedec,spi-nor";
>>  reg = <0>;
>>  spi-rx-bus-width = <4>;
>>  spi-max-frequency = <10800>;
>>  #address-cells = <1>;
>>  #size-cells = <1>;
>>  };
>>
>>  flash1: mx66l51235l@1 {
>>  compatible = "jedec,spi-nor";
>>  reg = <1>;
>>  spi-rx-bus-width = <4>;
>>  spi-max-frequency = <10800>;
>>  #address-cells = <1>;
>>  #size-cells = <1>;
>>  };
>> };
>>
>> As is, this series is not able to differentiate the both identical spi-nor 
>> using the MTD framework. 
>> Both spi-nor have the same name "mx66l51235l" as shown below, and usage of 
>> mtd command is not possible to reach
>> both spi-nor:
>>
>> STM32MP> mtd list  
>> List of MTD devices:
>> * nand0
>>   - type: NAND flash
>>   - block size: 0x4 bytes
>>   - min I/O: 0x1000 bytes
>>   - OOB size: 224 bytes
>>   - OOB available: 118 bytes
>>   - ECC strength: 8 bits
>>   - ECC step size: 512 bytes
>>   - bitflip threshold: 6 bits
>>   - 0x-0x4000 : "nand0"
>> * mx66l51235l
>>   - device: mx66l51235l@0
>>   - parent: spi@58003000
>>   - driver: jedec_spi_nor
>>   - type: NOR flash
>>   - block size: 0x1 bytes
>>   - min I/O: 0x1 bytes
>>   - 0x-0x0400 : "mx66l51235l"
>> * mx66l51235l
>>   - device: mx66l51235l@1
>>   - parent: spi@58003000
>>   - driver: jedec_spi_nor
>>   - type: NOR flash
>>   - block size: 0x1 bytes
>>   - min I/O: 0x1 bytes
>>   - 0x-0x0400 : "mx66l51235l"
>>
>> The following patch fix it :
>>
>> @@ -2528,11 +2528,11 @@ int spi_nor_scan(struct spi_nor *nor)
>>  ret = spi_nor_init_params(nor, info, );
>>  if (ret)
>>  return ret;
>>  
>>  if (!mtd->name)
>> -mtd->name = info->name;
>> +mtd->name = (char *)nor->dev->name;
>>  mtd->dev = nor->dev;
>>  mtd->priv = nor;
>>  mtd->type = MTD_NORFLASH;
>>  mtd->writesize = 1;
>>  mtd->flags = MTD_CAP_NORFLASH;
>>
>>
>>
>> Now it looks like :
>>
>> STM32MP> mtd list  
>> List of MTD devices:
>> * nand0
>>   - type: NAND flash
>>   - block size: 0x4 bytes
>>   - min I/O: 0x1000 bytes
>>   - OOB size: 224 bytes
>>   - OOB available: 118 bytes
>>   - ECC strength: 8 bits
>>   - ECC step size: 512 bytes
>>   - bitflip threshold: 6 bits
>>   - 0x-0x4000 : "nand0"
>> * mx66l51235l@0
>>   - device: mx66l51235l@0
>>   - parent: spi@58003000
>>   - driver: jedec_spi_nor
>>   - type: NOR flash
>>   - block size: 0x1 bytes
>>   - min I/O: 0x1 bytes
>>   - 0x-0x0400 : "mx66l51235l@0"
>> * mx66l51235l@1
>>   - device: mx66l51235l@1
>>   - parent: spi@58003000
>>   - driver: jedec_spi_nor
>>   - type: NOR flash
>>   - block size: 0x1 bytes
>>   - min I/O: 0x1 bytes
>>   - 0x-0x0400 : "mx66l51235l@1"
>> STM32MP>   
>>
>> Everything goes fine, i observed one side effect regarding "sf probe" 
>> command:
>>
>> STM32MP> sf probe  
>> SF: Detected mx66l51235l@0 with page size 256 Bytes, erase size 64 KiB, 
>> total 64 MiB
>> STM32MP> sf probe 1
>> SF: Detected mx66l51235l@1 with page size 256 Bytes, erase size 64 KiB, 
>> total 64 MiB
>>
>> Here the flash name is mx66l51235l@0 or mx66l51235l@1 and no more 
>> mx66l51235l.
> 
> I too tried that change (using (char *)nor->dev->name as mtd name).
> 
> The thing is that the name "mx66l51235l" is determined from the SPI NOR
> ID (not the device-tree), so if you solder a different NOR, the name
> will be different. Meanwhile dts name is always the same.

Ok got it, i didn't pay attention to the fact nor->dev->name doesn't come from 
spi-nor-ids but from DT  :-(

> 
> I think the mtd command should at least inform the user what kind of SPI
> NOR is soldered on the board.

Fully agree

> 
> So one solution is to use device-tree name to select the NOR, but still
> print the name determined from SPI ID somewhere.
> 
> Second solution is to allow selecting the SPI by number, i.e. (the n-th
> enumerated SPI).

and what about @ as shown in my previous email ?

> 
> (BTW regarding your dts node names, the node names should be spi-nor@0
>  and spi-nor@1. Yes, I know that spi-nor is not documented in
>  device-tree bindings yet, but this would be 

Re: [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"

[Marek Vasut]

On 2/10/21 3:13 PM, Tom Rini wrote:

On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:

Hi Simon,

On Sun, Feb 7, 2021 at 11:34 PM Simon Glass  wrote:


Hi Bin,

On Sun, 7 Feb 2021 at 08:11, Bin Meng  wrote:


This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.

Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
changes 'struct pci_controller'.regions from pre-allocated array of
regions to dynamically allocated, which unfortunately broken lots of
boards that still use the non-DM PCI driver.

We may update every non-DM PCI board codes to do the dynamical
allocation of PCI regions but that's a lot of work (e.g.: almost
all Freescale PowerPC boards are broken now and need to be fixed).
Let's do the easy way.


No one has noticed since July, apparently. I think it would be better
to disable PCI on these boards, until either someone migrates them or
they are removed. The PCI deadline was about 18 months ago.



Yep, but I'd like to keep this revert instead of just fixing the
qemu-ppce500 here, to give people a chance to test their original
non-DM version of PCI driver before the DM conversion.

Once all boards have converted to DM PCI, we can revert this revert patch again.


Tom, do you know the situation here?


So, I made a lack of DM_PCI migration be fatal and got a build done
here:
https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348

Of note, MIPS malta fails, so I had to drop that from pytest to complete
the world build.  There's then a handful of ARM boards, another large
chunk of PowerPC, and then a few others such as r7780mp.  SH is the big
what to do here to me, other than PowerPC, as other than r2dplus
everything is missing the main "convert to DM" migration deadline as
well.


Anything SH except r2dplus is likely dead.

[PATCH] configs: meson64: add fdtoverlay_addr_r

[Neil Armstrong]

In order to support loading FTD Overlays when booting with the pxe
command (or extlinux.conf), supported with [1], add the missing
fdtoverlay_addr_r used to load the overlay before applying it to
the FDT loaded at fdt_addr_r.

[1] 
https://patchwork.ozlabs.org/project/uboot/patch/20210120085453.2783678-1-narmstr...@baylibre.com/

Signed-off-by: Neil Armstrong 
---
 include/configs/meson64.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/meson64.h b/include/configs/meson64.h
index 52cc01f73d..7e97f89052 100644
--- a/include/configs/meson64.h
+++ b/include/configs/meson64.h
@@ -80,6 +80,7 @@
"scriptaddr=0x0800\0" \
"kernel_addr_r=0x0808\0" \
"pxefile_addr_r=0x0108\0" \
+   "fdtoverlay_addr_r=0x0100\0" \
"ramdisk_addr_r=0x1300\0" \
"fdtfile=amlogic/" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
BOOTENV
-- 
2.25.1

Re: [PATCH] usb: gadget: dwc2_udc_otg: Fix dwc2_gadget_start()

[Marek Vasut]

On 2/10/21 3:17 PM, Patrice Chotard wrote:

Since commit 8745b9ebccae ("usb: gadget: add super speed support")
ums was no more functional on platform which use dwc2_udc_otg driver.

Remove the speed test in dwc2_gadget_start() to fix it.
Tested on stm32mp157c-ev1 board.


Isn't the speed check correct though ?

What is really going on when this fails ?


Fixes: c791c8431c34 ("usb: dwc2: convert driver to DM_USB_GADGET")

Signed-off-by: Patrice Chotard 
---

  drivers/usb/gadget/dwc2_udc_otg.c | 10 ++
  1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/gadget/dwc2_udc_otg.c 
b/drivers/usb/gadget/dwc2_udc_otg.c
index e3871e381e..4f3d761eb1 100644
--- a/drivers/usb/gadget/dwc2_udc_otg.c
+++ b/drivers/usb/gadget/dwc2_udc_otg.c
@@ -248,10 +248,7 @@ int usb_gadget_register_driver(struct usb_gadget_driver 
*driver)
  
  	debug_cond(DEBUG_SETUP != 0, "%s: %s\n", __func__, "no name");
  
-	if (!driver

-   || (driver->speed != USB_SPEED_FULL
-   && driver->speed != USB_SPEED_HIGH)
-   || !driver->bind || !driver->disconnect || !driver->setup)
+   if (!driver || !driver->bind || !driver->disconnect || !driver->setup)
return -EINVAL;
if (!dev)
return -ENODEV;
@@ -320,10 +317,7 @@ static int dwc2_gadget_start(struct usb_gadget *g,
  
  	debug_cond(DEBUG_SETUP != 0, "%s: %s\n", __func__, "no name");
  
-	if (!driver ||

-   (driver->speed != USB_SPEED_FULL &&
-driver->speed != USB_SPEED_HIGH) ||
-   !driver->bind || !driver->disconnect || !driver->setup)
+   if (!driver || !driver->bind || !driver->disconnect || !driver->setup)
return -EINVAL;
  
  	if (!dev)





[...]

[PATCH] usb: gadget: dwc2_udc_otg: Fix dwc2_gadget_start()

[Patrice Chotard]

Since commit 8745b9ebccae ("usb: gadget: add super speed support")
ums was no more functional on platform which use dwc2_udc_otg driver.

Remove the speed test in dwc2_gadget_start() to fix it.
Tested on stm32mp157c-ev1 board.

Fixes: c791c8431c34 ("usb: dwc2: convert driver to DM_USB_GADGET")

Signed-off-by: Patrice Chotard 
---

 drivers/usb/gadget/dwc2_udc_otg.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/gadget/dwc2_udc_otg.c 
b/drivers/usb/gadget/dwc2_udc_otg.c
index e3871e381e..4f3d761eb1 100644
--- a/drivers/usb/gadget/dwc2_udc_otg.c
+++ b/drivers/usb/gadget/dwc2_udc_otg.c
@@ -248,10 +248,7 @@ int usb_gadget_register_driver(struct usb_gadget_driver 
*driver)
 
debug_cond(DEBUG_SETUP != 0, "%s: %s\n", __func__, "no name");
 
-   if (!driver
-   || (driver->speed != USB_SPEED_FULL
-   && driver->speed != USB_SPEED_HIGH)
-   || !driver->bind || !driver->disconnect || !driver->setup)
+   if (!driver || !driver->bind || !driver->disconnect || !driver->setup)
return -EINVAL;
if (!dev)
return -ENODEV;
@@ -320,10 +317,7 @@ static int dwc2_gadget_start(struct usb_gadget *g,
 
debug_cond(DEBUG_SETUP != 0, "%s: %s\n", __func__, "no name");
 
-   if (!driver ||
-   (driver->speed != USB_SPEED_FULL &&
-driver->speed != USB_SPEED_HIGH) ||
-   !driver->bind || !driver->disconnect || !driver->setup)
+   if (!driver || !driver->bind || !driver->disconnect || !driver->setup)
return -EINVAL;
 
if (!dev)
-- 
2.17.1

Re: [PATCH u-boot-dm + u-boot-spi v2 0/7] Support SPI NORs and OF partitions in `mtd list`

[Marek Behun]

On Wed, 10 Feb 2021 14:48:23 +0100
Patrice CHOTARD  wrote:

> +Patrick
> 
> Hi All
> 
> I have tested this series on stm32mp1-ev1 board which embeds 1 nand and 2 
> identical spi-nor. 
> spi-nor DT node is the following:
> 
>  {
>   pinctrl-names = "default", "sleep";
>   pinctrl-0 = <_clk_pins_a _bk1_pins_a _bk2_pins_a>;
>   pinctrl-1 = <_clk_sleep_pins_a _bk1_sleep_pins_a 
> _bk2_sleep_pins_a>;
>   reg = <0x58003000 0x1000>, <0x7000 0x400>;
>   #address-cells = <1>;
>   #size-cells = <0>;
>   status = "okay";
> 
>   flash0: mx66l51235l@0 {
>   compatible = "jedec,spi-nor";
>   reg = <0>;
>   spi-rx-bus-width = <4>;
>   spi-max-frequency = <10800>;
>   #address-cells = <1>;
>   #size-cells = <1>;
>   };
> 
>   flash1: mx66l51235l@1 {
>   compatible = "jedec,spi-nor";
>   reg = <1>;
>   spi-rx-bus-width = <4>;
>   spi-max-frequency = <10800>;
>   #address-cells = <1>;
>   #size-cells = <1>;
>   };
> };
> 
> As is, this series is not able to differentiate the both identical spi-nor 
> using the MTD framework. 
> Both spi-nor have the same name "mx66l51235l" as shown below, and usage of 
> mtd command is not possible to reach
> both spi-nor:
> 
> STM32MP> mtd list  
> List of MTD devices:
> * nand0
>   - type: NAND flash
>   - block size: 0x4 bytes
>   - min I/O: 0x1000 bytes
>   - OOB size: 224 bytes
>   - OOB available: 118 bytes
>   - ECC strength: 8 bits
>   - ECC step size: 512 bytes
>   - bitflip threshold: 6 bits
>   - 0x-0x4000 : "nand0"
> * mx66l51235l
>   - device: mx66l51235l@0
>   - parent: spi@58003000
>   - driver: jedec_spi_nor
>   - type: NOR flash
>   - block size: 0x1 bytes
>   - min I/O: 0x1 bytes
>   - 0x-0x0400 : "mx66l51235l"
> * mx66l51235l
>   - device: mx66l51235l@1
>   - parent: spi@58003000
>   - driver: jedec_spi_nor
>   - type: NOR flash
>   - block size: 0x1 bytes
>   - min I/O: 0x1 bytes
>   - 0x-0x0400 : "mx66l51235l"
> 
> The following patch fix it :
> 
> @@ -2528,11 +2528,11 @@ int spi_nor_scan(struct spi_nor *nor)
>   ret = spi_nor_init_params(nor, info, );
>   if (ret)
>   return ret;
>  
>   if (!mtd->name)
> - mtd->name = info->name;
> + mtd->name = (char *)nor->dev->name;
>   mtd->dev = nor->dev;
>   mtd->priv = nor;
>   mtd->type = MTD_NORFLASH;
>   mtd->writesize = 1;
>   mtd->flags = MTD_CAP_NORFLASH;
> 
> 
> 
> Now it looks like :
> 
> STM32MP> mtd list  
> List of MTD devices:
> * nand0
>   - type: NAND flash
>   - block size: 0x4 bytes
>   - min I/O: 0x1000 bytes
>   - OOB size: 224 bytes
>   - OOB available: 118 bytes
>   - ECC strength: 8 bits
>   - ECC step size: 512 bytes
>   - bitflip threshold: 6 bits
>   - 0x-0x4000 : "nand0"
> * mx66l51235l@0
>   - device: mx66l51235l@0
>   - parent: spi@58003000
>   - driver: jedec_spi_nor
>   - type: NOR flash
>   - block size: 0x1 bytes
>   - min I/O: 0x1 bytes
>   - 0x-0x0400 : "mx66l51235l@0"
> * mx66l51235l@1
>   - device: mx66l51235l@1
>   - parent: spi@58003000
>   - driver: jedec_spi_nor
>   - type: NOR flash
>   - block size: 0x1 bytes
>   - min I/O: 0x1 bytes
>   - 0x-0x0400 : "mx66l51235l@1"
> STM32MP>   
> 
> Everything goes fine, i observed one side effect regarding "sf probe" command:
> 
> STM32MP> sf probe  
> SF: Detected mx66l51235l@0 with page size 256 Bytes, erase size 64 KiB, total 
> 64 MiB
> STM32MP> sf probe 1
> SF: Detected mx66l51235l@1 with page size 256 Bytes, erase size 64 KiB, total 
> 64 MiB
> 
> Here the flash name is mx66l51235l@0 or mx66l51235l@1 and no more mx66l51235l.

I too tried that change (using (char *)nor->dev->name as mtd name).

The thing is that the name "mx66l51235l" is determined from the SPI NOR
ID (not the device-tree), so if you solder a different NOR, the name
will be different. Meanwhile dts name is always the same.

I think the mtd command should at least inform the user what kind of SPI
NOR is soldered on the board.

So one solution is to use device-tree name to select the NOR, but still
print the name determined from SPI ID somewhere.

Second solution is to allow selecting the SPI by number, i.e. (the n-th
enumerated SPI).

(BTW regarding your dts node names, the node names should be spi-nor@0
 and spi-nor@1. Yes, I know that spi-nor is not documented in
 device-tree bindings yet, but this would be consistent with other
 device-tree bindings in Linux.)

Marek

Re: [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"

[Tom Rini]

On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
> Hi Simon,
> 
> On Sun, Feb 7, 2021 at 11:34 PM Simon Glass  wrote:
> >
> > Hi Bin,
> >
> > On Sun, 7 Feb 2021 at 08:11, Bin Meng  wrote:
> > >
> > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> > >
> > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI 
> > > regions")
> > > changes 'struct pci_controller'.regions from pre-allocated array of
> > > regions to dynamically allocated, which unfortunately broken lots of
> > > boards that still use the non-DM PCI driver.
> > >
> > > We may update every non-DM PCI board codes to do the dynamical
> > > allocation of PCI regions but that's a lot of work (e.g.: almost
> > > all Freescale PowerPC boards are broken now and need to be fixed).
> > > Let's do the easy way.
> >
> > No one has noticed since July, apparently. I think it would be better
> > to disable PCI on these boards, until either someone migrates them or
> > they are removed. The PCI deadline was about 18 months ago.
> >
> 
> Yep, but I'd like to keep this revert instead of just fixing the
> qemu-ppce500 here, to give people a chance to test their original
> non-DM version of PCI driver before the DM conversion.
> 
> Once all boards have converted to DM PCI, we can revert this revert patch 
> again.
> 
> > Tom, do you know the situation here?

So, I made a lack of DM_PCI migration be fatal and got a build done
here:
https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348

Of note, MIPS malta fails, so I had to drop that from pytest to complete
the world build.  There's then a handful of ARM boards, another large
chunk of PowerPC, and then a few others such as r7780mp.  SH is the big
what to do here to me, other than PowerPC, as other than r2dplus
everything is missing the main "convert to DM" migration deadline as
well.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH u-boot-dm + u-boot-spi v2 0/7] Support SPI NORs and OF partitions in `mtd list`

[Patrice CHOTARD]

+Patrick

Hi All

I have tested this series on stm32mp1-ev1 board which embeds 1 nand and 2 
identical spi-nor. 
spi-nor DT node is the following:

 {
pinctrl-names = "default", "sleep";
pinctrl-0 = <_clk_pins_a _bk1_pins_a _bk2_pins_a>;
pinctrl-1 = <_clk_sleep_pins_a _bk1_sleep_pins_a 
_bk2_sleep_pins_a>;
reg = <0x58003000 0x1000>, <0x7000 0x400>;
#address-cells = <1>;
#size-cells = <0>;
status = "okay";

flash0: mx66l51235l@0 {
compatible = "jedec,spi-nor";
reg = <0>;
spi-rx-bus-width = <4>;
spi-max-frequency = <10800>;
#address-cells = <1>;
#size-cells = <1>;
};

flash1: mx66l51235l@1 {
compatible = "jedec,spi-nor";
reg = <1>;
spi-rx-bus-width = <4>;
spi-max-frequency = <10800>;
#address-cells = <1>;
#size-cells = <1>;
};
};

As is, this series is not able to differentiate the both identical spi-nor 
using the MTD framework. 
Both spi-nor have the same name "mx66l51235l" as shown below, and usage of mtd 
command is not possible to reach
both spi-nor:

STM32MP> mtd list
List of MTD devices:
* nand0
  - type: NAND flash
  - block size: 0x4 bytes
  - min I/O: 0x1000 bytes
  - OOB size: 224 bytes
  - OOB available: 118 bytes
  - ECC strength: 8 bits
  - ECC step size: 512 bytes
  - bitflip threshold: 6 bits
  - 0x-0x4000 : "nand0"
* mx66l51235l
  - device: mx66l51235l@0
  - parent: spi@58003000
  - driver: jedec_spi_nor
  - type: NOR flash
  - block size: 0x1 bytes
  - min I/O: 0x1 bytes
  - 0x-0x0400 : "mx66l51235l"
* mx66l51235l
  - device: mx66l51235l@1
  - parent: spi@58003000
  - driver: jedec_spi_nor
  - type: NOR flash
  - block size: 0x1 bytes
  - min I/O: 0x1 bytes
  - 0x-0x0400 : "mx66l51235l"

The following patch fix it :

@@ -2528,11 +2528,11 @@ int spi_nor_scan(struct spi_nor *nor)
ret = spi_nor_init_params(nor, info, );
if (ret)
return ret;
 
if (!mtd->name)
-   mtd->name = info->name;
+   mtd->name = (char *)nor->dev->name;
mtd->dev = nor->dev;
mtd->priv = nor;
mtd->type = MTD_NORFLASH;
mtd->writesize = 1;
mtd->flags = MTD_CAP_NORFLASH;



Now it looks like :

STM32MP> mtd list
List of MTD devices:
* nand0
  - type: NAND flash
  - block size: 0x4 bytes
  - min I/O: 0x1000 bytes
  - OOB size: 224 bytes
  - OOB available: 118 bytes
  - ECC strength: 8 bits
  - ECC step size: 512 bytes
  - bitflip threshold: 6 bits
  - 0x-0x4000 : "nand0"
* mx66l51235l@0
  - device: mx66l51235l@0
  - parent: spi@58003000
  - driver: jedec_spi_nor
  - type: NOR flash
  - block size: 0x1 bytes
  - min I/O: 0x1 bytes
  - 0x-0x0400 : "mx66l51235l@0"
* mx66l51235l@1
  - device: mx66l51235l@1
  - parent: spi@58003000
  - driver: jedec_spi_nor
  - type: NOR flash
  - block size: 0x1 bytes
  - min I/O: 0x1 bytes
  - 0x-0x0400 : "mx66l51235l@1"
STM32MP> 

Everything goes fine, i observed one side effect regarding "sf probe" command:

STM32MP> sf probe
SF: Detected mx66l51235l@0 with page size 256 Bytes, erase size 64 KiB, total 
64 MiB
STM32MP> sf probe 1  
SF: Detected mx66l51235l@1 with page size 256 Bytes, erase size 64 KiB, total 
64 MiB

Here the flash name is mx66l51235l@0 or mx66l51235l@1 and no more mx66l51235l.

Thanks

Patrice



On 2/9/21 3:44 PM, Marek Behún wrote:
> Hello,
> 
> this is v2 of patchset that adds support for U-Boot to parse MTD
> partitions from device-tree, and also improves support for SPI NOR
> access via the `mtd` command.
> 
> Since mtd subsystem is unmaintained, who shall apply the mtd patches?
> I put an u-boot-spi tag into the subject prefix, but am not sure if
> this is correct.
> 
> Changes since v1:
> - added tests of ofnode_get_addr_size_index() and
>   ofnode_get_addr_size_index_notrans() as requested by Simon
> - the last patch now probes SPI NORs in both versions of
>   mtd_probe_devices(), that is when MTDPARTS is enabled or disabled
> 
> Marek
> 
> Marek Behún (7):
>   dm: core: add test for ofnode_get_addr_size_index()
>   dm: core: add non-translating version of ofnode_get_addr_size_index()
>   mtd: add support for parsing partitions defined in OF
>   mtd: spi-nor: allow registering multiple MTDs when DM is enabled
>   mtd: spi-nor: fill-in mtd->dev member
>   mtd: remove mtd_probe function
>   mtd: probe SPI NOR devices in mtd_probe_devices()
> 
>  drivers/core/ofnode.c  |  19 -
>  drivers/mtd/mtd-uclass.c   |  15 
>  drivers/mtd/mtd_uboot.c| 129 -
>  drivers/mtd/mtdpart.c  |  60 +++
>  drivers/mtd/spi/sf_internal.h  |   4 +-
>  drivers/mtd/spi/sf_mtd.c   |  

Re: [ADDRESS CONVERTED] [PATCH 07/25] arm: Remove apx4devkit board

[Lauri Hintsala]

Acked-by: Lauri Hintsala 
mailto:lauri.hints...@silabs.com>>


On 9 Feb 2021, at 15.02, Tom Rini 
mailto:tr...@konsulko.com>> wrote:

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


This board has not been converted to CONFIG_DM_MMC by the deadline of
v2019.04, which is almost two years ago.  In addition there are other DM
migrations it is also missing.  Remove it.

Cc: Lauri Hintsala 
mailto:lauri.hints...@bluegiga.com>>
Signed-off-by: Tom Rini mailto:tr...@konsulko.com>>
---
arch/arm/mach-imx/mxs/Kconfig  |   4 -
board/bluegiga/apx4devkit/Kconfig  |  15 ---
board/bluegiga/apx4devkit/MAINTAINERS  |   6 -
board/bluegiga/apx4devkit/Makefile |  10 --
board/bluegiga/apx4devkit/apx4devkit.c | 142 ---
board/bluegiga/apx4devkit/spl_boot.c   | 152 -
configs/apx4devkit_defconfig   |  50 
include/configs/apx4devkit.h   |  77 -
8 files changed, 456 deletions(-)
delete mode 100644 board/bluegiga/apx4devkit/Kconfig
delete mode 100644 board/bluegiga/apx4devkit/MAINTAINERS
delete mode 100644 board/bluegiga/apx4devkit/Makefile
delete mode 100644 board/bluegiga/apx4devkit/apx4devkit.c
delete mode 100644 board/bluegiga/apx4devkit/spl_boot.c
delete mode 100644 configs/apx4devkit_defconfig
delete mode 100644 include/configs/apx4devkit.h

diff --git a/arch/arm/mach-imx/mxs/Kconfig b/arch/arm/mach-imx/mxs/Kconfig
index 6a6e6ebecf0b..40d74c93b305 100644
--- a/arch/arm/mach-imx/mxs/Kconfig
+++ b/arch/arm/mach-imx/mxs/Kconfig
@@ -8,9 +8,6 @@ choice
   prompt "MX28 board select"
   optional

-config TARGET_APX4DEVKIT
-   bool "Support apx4devkit"
-
config TARGET_BG0900
   bool "Support bg0900"

@@ -28,7 +25,6 @@ endchoice
config SYS_SOC
   default "mxs"

-source "board/bluegiga/apx4devkit/Kconfig"
source "board/liebherr/xea/Kconfig"
source "board/ppcag/bg0900/Kconfig"
source "board/schulercontrol/sc_sps_1/Kconfig"
diff --git a/board/bluegiga/apx4devkit/Kconfig 
b/board/bluegiga/apx4devkit/Kconfig
deleted file mode 100644
index f327fa15cf07..
--- a/board/bluegiga/apx4devkit/Kconfig
+++ /dev/null
@@ -1,15 +0,0 @@
-if TARGET_APX4DEVKIT
-
-config SYS_BOARD
-   default "apx4devkit"
-
-config SYS_VENDOR
-   default "bluegiga"
-
-config SYS_SOC
-   default "mxs"
-
-config SYS_CONFIG_NAME
-   default "apx4devkit"
-
-endif
diff --git a/board/bluegiga/apx4devkit/MAINTAINERS 
b/board/bluegiga/apx4devkit/MAINTAINERS
deleted file mode 100644
index 286e9e9f063e..
--- a/board/bluegiga/apx4devkit/MAINTAINERS
+++ /dev/null
@@ -1,6 +0,0 @@
-APX4DEVKIT BOARD
-M: Lauri Hintsala 
mailto:lauri.hints...@bluegiga.com>>
-S: Maintained
-F: board/bluegiga/apx4devkit/
-F: include/configs/apx4devkit.h
-F: configs/apx4devkit_defconfig
diff --git a/board/bluegiga/apx4devkit/Makefile 
b/board/bluegiga/apx4devkit/Makefile
deleted file mode 100644
index 039d62dda2ad..
--- a/board/bluegiga/apx4devkit/Makefile
+++ /dev/null
@@ -1,10 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-#
-# (C) Copyright 2000-2006
-# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-
-ifndef CONFIG_SPL_BUILD
-obj-y  := apx4devkit.o
-else
-obj-y  := spl_boot.o
-endif
diff --git a/board/bluegiga/apx4devkit/apx4devkit.c 
b/board/bluegiga/apx4devkit/apx4devkit.c
deleted file mode 100644
index 739f71f5c4d1..
--- a/board/bluegiga/apx4devkit/apx4devkit.c
+++ /dev/null
@@ -1,142 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Bluegiga APX4 Development Kit
- *
- * Copyright (C) 2012 Bluegiga Technologies Oy
- *
- * Authors:
- * Veli-Pekka Peltola 
mailto:veli-pekka.pelt...@bluegiga.com>>
- * Lauri Hintsala 
mailto:lauri.hints...@bluegiga.com>>
- *
- * Based on m28evk.c:
- * Copyright (C) 2011 Marek Vasut 
mailto:marek.va...@gmail.com>>
- * on behalf of DENX Software Engineering GmbH
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-DECLARE_GLOBAL_DATA_PTR;
-
-/* Functions */
-int board_early_init_f(void)
-{
-   /* IO0 clock at 480MHz */
-   mxs_set_ioclk(MXC_IOCLK0, 48);
-   /* IO1 clock at 480MHz */
-   mxs_set_ioclk(MXC_IOCLK1, 48);
-
-   /* SSP0 clock at 96MHz */
-   mxs_set_sspclk(MXC_SSPCLK0, 96000, 0);
-
-   return 0;
-}
-
-int dram_init(void)
-{
-   return mxs_dram_init();
-}
-
-int board_init(void)
-{
-   /* Adress of boot parameters */
-   gd->bd->bi_boot_params = PHYS_SDRAM_1 + 0x100;
-
-   return 0;
-}
-
-#ifdef CONFIG_CMD_MMC
-int board_mmc_init(struct bd_info *bis)
-{
-   return mxsmmc_initialize(bis, 0, NULL, NULL);
-}
-#endif
-
-
-#ifdef CONFIG_CMD_NET
-
-#define MII_PHY_CTRL2 0x1f
-int fecmxc_mii_postcall(int phy)
-{
-   /* change PHY RMII clock to 

Uboot - SPL issue imx6

[Deepanraj]

Hi,

We are trying to run SPL in our custom board. So we have integrated the 
code changes in our custom board.


Our custom board is based on imx6ull . All the changes are done 
properly. But when we try to boot it is stuck in "Trying to boot from MMC1".


Please help us resolve this issue.

Thankyou,

Deepanraj.A

[PULL u-boot] Please pull u-boot-amlogic-20210210

[Neil Armstrong]

Hi Tom,

These changes adds the plumbing to support MIPI D-PHYs, including the timings 
helpers from
Linux, the AXG Analog and Digital D-PHY drivers. Finally automatic detection of 
model is added
for the HardKernel Odroid N2 & C4 families.

The CI job is at 
https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/6346

Thanks,
Neil

The following changes since commit e14d5762de1db84cae6d84d59c1e40f3eb26c4c3:

  Merge git://git.denx.de/u-boot-marvell (2021-02-08 10:55:51 -0500)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic.git 
tags/u-boot-amlogic-20210210

for you to fetch changes up to 8bc780106c1399bd263c4283a8747889a613ca5d:

  board: amlogic: odroid: add runtime detection of the N2/N2+/C4/HC4 variants 
(2021-02-10 10:00:51 +0100)


- Add configuration helpers for MIPI D-PHY
- generic-phy: add configure op
- Add Amlogic AXG MIPI D-PHY driver & MIPI PCIe Analog PHY driver
- odroid: add runtime detection of the N2/N2+/C4/HC4 variants


Marek Szyprowski (1):
  board: amlogic: odroid: add runtime detection of the N2/N2+/C4/HC4 
variants

Neil Armstrong (4):
  phy: dphy: Add configuration helpers
  generic-phy: add configure op
  phy: Add Amlogic AXG MIPI D-PHY driver
  phy: Add Amlogic AXG MIPI PCIe Analog PHY driver

 arch/arm/dts/meson-g12b-odroid-n2-u-boot.dtsi |   6 +
 arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi  |   6 +
 board/amlogic/odroid-n2/odroid-n2.c   |  80 ++
 configs/odroid-c4_defconfig   |   4 +-
 configs/odroid-n2_defconfig   |   4 +-
 drivers/phy/Kconfig   |  23 ++
 drivers/phy/Makefile  |   3 +
 drivers/phy/meson-axg-mipi-dphy.c | 393 ++
 drivers/phy/meson-axg-mipi-pcie-analog.c  | 233 +++
 drivers/phy/phy-core-mipi-dphy.c  | 161 +++
 drivers/phy/phy-uclass.c  |  11 +
 include/generic-phy.h |  23 ++
 include/phy-mipi-dphy.h   | 284 +++
 13 files changed, 1229 insertions(+), 2 deletions(-)
 create mode 100644 drivers/phy/meson-axg-mipi-dphy.c
 create mode 100644 drivers/phy/meson-axg-mipi-pcie-analog.c
 create mode 100644 drivers/phy/phy-core-mipi-dphy.c
 create mode 100644 include/phy-mipi-dphy.h

Re: [PATCH] efidebug: Introduce bootmgr command

[Heinrich Schuchardt]

On 10.02.21 12:23, Wolfgang Denk wrote:
> Dear Ilias,
>
> In message <20210210105425.356131-1-ilias.apalodi...@linaro.org> you wrote:
>> Up to now we've been adding all the efi related configuration to
>> 'efidebug' command.  The command name feels a bit weird to configure boot
>> manager related commands.  Since the bootmanager is growing and we intend
>> to extend it with features like defining the initrd we want to expose to
>> the kernel, it would make sense to split it on a command of it's own.
>>
>> So let's introduce a new command called bootmgr and move all of the
>> existing Boot manager functionality there.
>
> As this is EFI specific, I would appreciate to have "efi" in the
> command name, too.
>
> Maybe all EFi related commands should be collected as "efi "
> like we did it with the "env" commands long ago.
>
> For backward compatibility e. g. 'efidebug' could be kept, but the
> new name would be 'efi debug'; likewise, your new command would be
> 'efi bootmgr' [or just 'efi boot' ?]
>
> Thanks!
>
> Wolfgang Denk
>

Hello Wolfgang,

what is the benefit for the user to have a single command with an
endless list of options?

I can't see any.

Best regards

Heinrich

Re: [PATCH] efidebug: Introduce bootmgr command

[AKASHI Takahiro]

On Wed, Feb 10, 2021 at 01:53:55PM +0200, Ilias Apalodimas wrote:
> Hi Wolfgang,
> 
> Thanks for having a look, 
> 
> On Wed, Feb 10, 2021 at 12:23:47PM +0100, Wolfgang Denk wrote:
> > Dear Ilias,
> > 
> > In message <20210210105425.356131-1-ilias.apalodi...@linaro.org> you wrote:
> > > Up to now we've been adding all the efi related configuration to
> > > 'efidebug' command.  The command name feels a bit weird to configure boot
> > > manager related commands.  Since the bootmanager is growing and we intend

I developed the command as a poorman's "efishell" as, at that time,
EDK2's shell didn't work well on U-Boot UEFI subsystem.

As far as I remember, Alex (ex-maintainer) didn't like to take this
command, including "efidebug boot" subcommand, as a standard U-Boot command.

> > > to extend it with features like defining the initrd we want to expose to
> > > the kernel, it would make sense to split it on a command of it's own.
> > >
> > > So let's introduce a new command called bootmgr and move all of the
> > > existing Boot manager functionality there.
> > 
> > As this is EFI specific, I would appreciate to have "efi" in the
> > command name, too.
> > 
> > Maybe all EFi related commands should be collected as "efi "
> > like we did it with the "env" commands long ago.
> 
> We could, I'll discuss this with Heinrich and see what he thinks.
> 
> > 
> > For backward compatibility e. g. 'efidebug' could be kept, but the
> > new name would be 'efi debug'; likewise, your new command would be
> > 'efi bootmgr' [or just 'efi boot' ?]

As a matter of fact, "efi" is even now recognized as "efidebug" thanks to
command name completion as there is no other "efi*" command.

Then,
  efidebug boot ..., and
  [efi]bootmgr boot ...
can be invoked literally as
  efi boot ...

So I don't see much advantage to Ilias' proposal.

My suggestions are:
* alias "efi" to "efidebug" (if preferred),
* add new configuration options for efidebug's subcommands,
* only enable "boot"-related options by default (if needed)

Personally, I don't like to move the portion of code from one file
to another since it will break git history.

In addition, I have proposed to make "bootefi bootmgr" a standalone
command/application, but Heinrich rejected it.
Given Ilias' concern(?), I still believe that the change is logical
and makes more sense.

-Takahiro Akashi

> 
> The efidebug for boot options wasn't introduced that long ago and I don't
> think anyone uses it in production.  If someone would want to have it 
> backwards 
> compatible, please shout and we'll see what we can do, but I'd strongly 
> prefer 
> replacing it overall. If we truly want backwards compatibility though we must 
> keep
> efidebug, changing the name to something like 'efi debug' just for the name
> similarity wouldn't help much as it would break things regardless.
> 
> Heinrich feel free to ignore the followup patch fixing the documentation of
> efidebug.  I'll change the name to something we all agree and fold in the doc
> changes in v2.
> 
> Thanks
> /Ilias
> > 
> > Thanks!
> > 
> > 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
> > In my experience the best way to get something done  is to give it to
> > someone who is busy.   - Terry Pratchett, _Going_Postal_

Re: [PATCH] efidebug: Introduce bootmgr command

[Ilias Apalodimas]

Dear Wolfgang,

On Wed, Feb 10, 2021 at 01:26:15PM +0100, Wolfgang Denk wrote:
> Dear Ilias,
> 
> In message  you wrote:
> >
> > The efidebug for boot options wasn't introduced that long ago and I don't
> > think anyone uses it in production.  If someone would want to have it 
> > backwards 
> > compatible, please shout and we'll see what we can do, but I'd strongly 
> > prefer 
> > replacing it overall. If we truly want backwards compatibility though we 
> > must keep
> > efidebug, changing the name to something like 'efi debug' just for the name
> > similarity wouldn't help much as it would break things regardless.
> 
> In this case, "debug" would just be a sub-command of the "efi"
> command, with more sub-commands under efi (like bootmgr or such)
> following, same as we did for example with "env" (where many
> commands maintain backward compatibility, but here this was
> necessary because these have been in use forever):
> 
>   env print   -> printenv
>   env save-> saveenv
>   env set -> setenv
> 

Yes, but it would still look a bit strange, because the efidebug command was
overloaded in our case. So you could test capsules, set EFI bootmgr variables,
dump EFI tables amongst other things. The saveenv & friends had a tightly
defined scope already. 
So that would require a lot of code to keep the convention running, but since 
it's rarely used, I don't think it's worth the effort or the additional
complexity (once again unless someone has a valid reason), hence my suggestion
to define it properly while we still have time.

> etc.
> 
> Maybe a similar approach makes sense for "efi" (with or without
> backward compatibility, as you like - after all, this is just a
> little name space pollution ;-) :
> 
> efi:
>   efi debug
>   efi bootmgr
>   efi ...
> 

Exactly

Thanks
/Ilias

> 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
> If you believe that feeling bad or worrying long enough will change a
> past or future event, then you are residing on another planet with  a
> different reality system.

[PATCH v2 5/5] net: gem: Enable ethernet rx clock for versal

[Michal Simek]

From: T Karthik Reddy 

Enable rx clock along with tx clock for versal platform. Use compatible
data to enable/disable clocks in the driver.

Signed-off-by: T Karthik Reddy 
Signed-off-by: Michal Simek 
Reviewed-By: Ramon Fried 
---

Changes in v2:
- Use compatible data instead of CONFIG_

 drivers/net/zynq_gem.c | 33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 22237de66bc7..d6f58d87c873 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -129,6 +129,8 @@
 #define ZYNQ_GEM_FREQUENCY_100 2500UL
 #define ZYNQ_GEM_FREQUENCY_100012500UL
 
+#define RXCLK_EN   BIT(0)
+
 /* Device registers */
 struct zynq_gem_regs {
u32 nwctrl; /* 0x0 - Network Control reg */
@@ -205,10 +207,12 @@ struct zynq_gem_priv {
struct phy_device *phydev;
ofnode phy_of_node;
struct mii_dev *bus;
-   struct clk clk;
+   struct clk rx_clk;
+   struct clk tx_clk;
u32 max_speed;
bool int_pcs;
bool dma_64bit;
+   u32 clk_en_info;
 };
 
 static int phy_setup_op(struct zynq_gem_priv *priv, u32 phy_addr, u32 regnum,
@@ -476,18 +480,25 @@ static int zynq_gem_init(struct udevice *dev)
break;
}
 
-   ret = clk_set_rate(>clk, clk_rate);
+   ret = clk_set_rate(>tx_clk, clk_rate);
if (IS_ERR_VALUE(ret)) {
dev_err(dev, "failed to set tx clock rate\n");
return ret;
}
 
-   ret = clk_enable(>clk);
+   ret = clk_enable(>tx_clk);
if (ret) {
dev_err(dev, "failed to enable tx clock\n");
return ret;
}
 
+   if (priv->clk_en_info & RXCLK_EN) {
+   ret = clk_enable(>rx_clk);
+   if (ret) {
+   dev_err(dev, "failed to enable rx clock\n");
+   return ret;
+   }
+   }
setbits_le32(>nwctrl, ZYNQ_GEM_NWCTRL_RXEN_MASK |
ZYNQ_GEM_NWCTRL_TXEN_MASK);
 
@@ -694,12 +705,20 @@ static int zynq_gem_probe(struct udevice *dev)
priv->tx_bd = (struct emac_bd *)bd_space;
priv->rx_bd = (struct emac_bd *)((ulong)bd_space + BD_SEPRN_SPACE);
 
-   ret = clk_get_by_name(dev, "tx_clk", >clk);
+   ret = clk_get_by_name(dev, "tx_clk", >tx_clk);
if (ret < 0) {
-   dev_err(dev, "failed to get clock\n");
+   dev_err(dev, "failed to get tx_clock\n");
goto err1;
}
 
+   if (priv->clk_en_info & RXCLK_EN) {
+   ret = clk_get_by_name(dev, "rx_clk", >rx_clk);
+   if (ret < 0) {
+   dev_err(dev, "failed to get rx_clock\n");
+   goto err1;
+   }
+   }
+
priv->bus = mdio_alloc();
priv->bus->read = zynq_gem_miiphy_read;
priv->bus->write = zynq_gem_miiphy_write;
@@ -792,11 +811,13 @@ static int zynq_gem_of_to_plat(struct udevice *dev)
   (ulong)priv->iobase, (ulong)priv->mdiobase, priv->phyaddr,
   phy_string_for_interface(priv->interface));
 
+   priv->clk_en_info = dev_get_driver_data(dev);
+
return 0;
 }
 
 static const struct udevice_id zynq_gem_ids[] = {
-   { .compatible = "cdns,versal-gem" },
+   { .compatible = "cdns,versal-gem", .data = RXCLK_EN },
{ .compatible = "cdns,zynqmp-gem" },
{ .compatible = "cdns,zynq-gem" },
{ .compatible = "cdns,gem" },
-- 
2.30.0

[PATCH v2 4/5] i2c: i2c_cdns: Enable i2c clock

[Michal Simek]

From: T Karthik Reddy 

Enable i2c controller clock from driver probe function
by calling clk_enable().

Signed-off-by: T Karthik Reddy 
Signed-off-by: Michal Simek 
---

(no changes since v1)

 drivers/i2c/i2c-cdns.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/i2c/i2c-cdns.c b/drivers/i2c/i2c-cdns.c
index db3c04fa6e75..a650dd69b89f 100644
--- a/drivers/i2c/i2c-cdns.c
+++ b/drivers/i2c/i2c-cdns.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -481,6 +482,12 @@ static int cdns_i2c_of_to_plat(struct udevice *dev)
 
i2c_bus->input_freq = clk_get_rate();
 
+   ret = clk_enable();
+   if (ret) {
+   dev_err(dev, "failed to enable clock\n");
+   return ret;
+   }
+
return 0;
 }
 
-- 
2.30.0

[PATCH v2 2/5] clk: zynqmp: Add support to enable clocks

[Michal Simek]

From: T Karthik Reddy 

Add clock enable functionality in zynqmp clock driver to enable
clocks from peripheral drivers using clk_ops.

Signed-off-by: T Karthik Reddy 
Signed-off-by: Michal Simek 
---

(no changes since v1)

 drivers/clk/clk_zynqmp.c | 49 
 1 file changed, 49 insertions(+)

diff --git a/drivers/clk/clk_zynqmp.c b/drivers/clk/clk_zynqmp.c
index e8acca00660d..609d8e3b2fff 100644
--- a/drivers/clk/clk_zynqmp.c
+++ b/drivers/clk/clk_zynqmp.c
@@ -199,6 +199,8 @@ static u32 zynqmp_clk_get_register(enum zynqmp_clk id)
return CRF_APB_DDR_CTRL;
case qspi_ref:
return CRL_APB_QSPI_REF_CTRL;
+   case usb3_dual_ref:
+   return CRL_APB_USB3_DUAL_REF_CTRL;
case gem0_ref:
return CRL_APB_GEM0_REF_CTRL;
case gem1_ref:
@@ -207,6 +209,10 @@ static u32 zynqmp_clk_get_register(enum zynqmp_clk id)
return CRL_APB_GEM2_REF_CTRL;
case gem3_ref:
return CRL_APB_GEM3_REF_CTRL;
+   case usb0_bus_ref:
+   return CRL_APB_USB0_BUS_REF_CTRL;
+   case usb1_bus_ref:
+   return CRL_APB_USB1_BUS_REF_CTRL;
case uart0_ref:
return CRL_APB_UART0_REF_CTRL;
case uart1_ref:
@@ -699,9 +705,52 @@ static int zynqmp_clk_probe(struct udevice *dev)
return 0;
 }
 
+static int zynqmp_clk_enable(struct clk *clk)
+{
+   enum zynqmp_clk id = clk->id;
+   u32 reg, clk_ctrl, clkact_shift, mask;
+   int ret;
+
+   reg = zynqmp_clk_get_register(id);
+   debug("%s, clk_id:%x, clk_base:0x%x\n", __func__, id, reg);
+
+   switch (id) {
+   case usb0_bus_ref ... usb1:
+   clkact_shift = 25;
+   mask = 0x1;
+   break;
+   case gem0_ref ... gem3_ref:
+   clkact_shift = 25;
+   mask = 0x3;
+   break;
+   case qspi_ref ... can1_ref:
+   clkact_shift = 24;
+   mask = 0x1;
+   break;
+   default:
+   return -ENXIO;
+   }
+
+   ret = zynqmp_mmio_read(reg, _ctrl);
+   if (ret) {
+   printf("%s mio read fail\n", __func__);
+   return -EIO;
+   }
+
+   clk_ctrl |= (mask << clkact_shift);
+   ret = zynqmp_mmio_write(reg, mask << clkact_shift, clk_ctrl);
+   if (ret) {
+   printf("%s mio write fail\n", __func__);
+   return -EIO;
+   }
+
+   return ret;
+}
+
 static struct clk_ops zynqmp_clk_ops = {
.set_rate = zynqmp_clk_set_rate,
.get_rate = zynqmp_clk_get_rate,
+   .enable = zynqmp_clk_enable,
 };
 
 static const struct udevice_id zynqmp_clk_ids[] = {
-- 
2.30.0

[PATCH v2 3/5] clk: versal: Add support to enable clocks

[Michal Simek]

From: T Karthik Reddy 

Add clock enable functionality in versal clock driver to enable
clocks from peripheral drivers using clk_ops.

Signed-off-by: T Karthik Reddy 
Signed-off-by: Michal Simek 
---

Changes in v2:
- change patch possition

 drivers/clk/clk_versal.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/clk/clk_versal.c b/drivers/clk/clk_versal.c
index 908bc7519c42..62523d290999 100644
--- a/drivers/clk/clk_versal.c
+++ b/drivers/clk/clk_versal.c
@@ -718,9 +718,20 @@ static ulong versal_clk_set_rate(struct clk *clk, ulong 
rate)
return clk_rate;
 }
 
+static int versal_clk_enable(struct clk *clk)
+{
+   struct versal_clk_priv *priv = dev_get_priv(clk->dev);
+   u32 clk_id;
+
+   clk_id = priv->clk[clk->id].clk_id;
+
+   return xilinx_pm_request(PM_CLOCK_ENABLE, clk_id, 0, 0, 0, NULL);
+}
+
 static struct clk_ops versal_clk_ops = {
.set_rate = versal_clk_set_rate,
.get_rate = versal_clk_get_rate,
+   .enable = versal_clk_enable,
 };
 
 static const struct udevice_id versal_clk_ids[] = {
-- 
2.30.0

[PATCH v2 1/5] clk: zynq: Add dummy clock enable function

[Michal Simek]

A lot of Xilinx drivers are checking -ENOSYS which means that clock driver
doesn't have enable function. Remove this checking from drivers and create
dummy enable function as was done for clk_fixed_rate driver by
commit 6bf6d81c1112 ("clk: fixed_rate: add dummy enable() function").

Signed-off-by: Michal Simek 
---

Changes in v2:
- New patch is series

 drivers/clk/clk_zynq.c | 11 +++
 drivers/mmc/zynq_sdhci.c   |  2 +-
 drivers/net/zynq_gem.c |  4 ++--
 drivers/serial/serial_zynq.c   |  2 +-
 drivers/spi/zynq_qspi.c|  2 +-
 drivers/spi/zynq_spi.c |  2 +-
 drivers/spi/zynqmp_gqspi.c |  2 +-
 drivers/watchdog/xilinx_wwdt.c |  3 +--
 8 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/drivers/clk/clk_zynq.c b/drivers/clk/clk_zynq.c
index bf32d8317ab2..03a2f1991a08 100644
--- a/drivers/clk/clk_zynq.c
+++ b/drivers/clk/clk_zynq.c
@@ -422,6 +422,16 @@ static ulong zynq_clk_set_rate(struct clk *clk, ulong rate)
return -ENXIO;
}
 }
+
+static int dummy_enable(struct clk *clk)
+{
+   /*
+* Add implementation but by default all clocks are enabled
+* after power up which is only one supported case now.
+*/
+   return 0;
+}
+
 #else
 static ulong zynq_clk_get_rate(struct clk *clk)
 {
@@ -448,6 +458,7 @@ static struct clk_ops zynq_clk_ops = {
.get_rate = zynq_clk_get_rate,
 #ifndef CONFIG_SPL_BUILD
.set_rate = zynq_clk_set_rate,
+   .enable = dummy_enable,
 #endif
 };
 
diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index d9ad0ff199d7..b79c4021b6a5 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -577,7 +577,7 @@ static int arasan_sdhci_probe(struct udevice *dev)
debug("%s: CLK %ld\n", __func__, clock);
 
ret = clk_enable();
-   if (ret && ret != -ENOSYS) {
+   if (ret) {
dev_err(dev, "failed to enable clock\n");
return ret;
}
diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 5cb02bb3a7d2..22237de66bc7 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -477,13 +477,13 @@ static int zynq_gem_init(struct udevice *dev)
}
 
ret = clk_set_rate(>clk, clk_rate);
-   if (IS_ERR_VALUE(ret) && ret != (unsigned long)-ENOSYS) {
+   if (IS_ERR_VALUE(ret)) {
dev_err(dev, "failed to set tx clock rate\n");
return ret;
}
 
ret = clk_enable(>clk);
-   if (ret && ret != -ENOSYS) {
+   if (ret) {
dev_err(dev, "failed to enable tx clock\n");
return ret;
}
diff --git a/drivers/serial/serial_zynq.c b/drivers/serial/serial_zynq.c
index 2883e2466f8b..799d5240473c 100644
--- a/drivers/serial/serial_zynq.c
+++ b/drivers/serial/serial_zynq.c
@@ -127,7 +127,7 @@ static int zynq_serial_setbrg(struct udevice *dev, int 
baudrate)
debug("%s: CLK %ld\n", __func__, clock);
 
ret = clk_enable();
-   if (ret && ret != -ENOSYS) {
+   if (ret) {
dev_err(dev, "failed to enable clock\n");
return ret;
}
diff --git a/drivers/spi/zynq_qspi.c b/drivers/spi/zynq_qspi.c
index 845f2d2f5f41..29dbbf555776 100644
--- a/drivers/spi/zynq_qspi.c
+++ b/drivers/spi/zynq_qspi.c
@@ -193,7 +193,7 @@ static int zynq_qspi_probe(struct udevice *bus)
}
 
ret = clk_enable();
-   if (ret && ret != -ENOSYS) {
+   if (ret) {
dev_err(bus, "failed to enable clock\n");
return ret;
}
diff --git a/drivers/spi/zynq_spi.c b/drivers/spi/zynq_spi.c
index 2971e55f41b1..650d4d71d925 100644
--- a/drivers/spi/zynq_spi.c
+++ b/drivers/spi/zynq_spi.c
@@ -143,7 +143,7 @@ static int zynq_spi_probe(struct udevice *bus)
}
 
ret = clk_enable();
-   if (ret && ret != -ENOSYS) {
+   if (ret) {
dev_err(bus, "failed to enable clock\n");
return ret;
}
diff --git a/drivers/spi/zynqmp_gqspi.c b/drivers/spi/zynqmp_gqspi.c
index c7db43a09a52..bd25511aae6a 100644
--- a/drivers/spi/zynqmp_gqspi.c
+++ b/drivers/spi/zynqmp_gqspi.c
@@ -373,7 +373,7 @@ static int zynqmp_qspi_probe(struct udevice *bus)
debug("%s: CLK %ld\n", __func__, clock);
 
ret = clk_enable();
-   if (ret && ret != -ENOSYS) {
+   if (ret) {
dev_err(bus, "failed to enable clock\n");
return ret;
}
diff --git a/drivers/watchdog/xilinx_wwdt.c b/drivers/watchdog/xilinx_wwdt.c
index 9137d87697d4..11b30ae85df0 100644
--- a/drivers/watchdog/xilinx_wwdt.c
+++ b/drivers/watchdog/xilinx_wwdt.c
@@ -90,9 +90,8 @@ static int xlnx_wwdt_start(struct udevice *dev, u64 timeout, 
ulong flags)
/* Calculate timeout count */
count = timeout * clock_f;
 
-   /* clk_enable will return -ENOSYS when it is not implemented */
ret = clk_enable(>clk);
-   if (ret && ret != -ENOSYS) {
+   if (ret) {
 

[PATCH v2 0/5] clk: Add support to enable clocks

[Michal Simek]

Hi,

Add support to enable clocks using clock subsystem ops for
zynqmp & versal platforms. Enable rx clock in ethernet driver
for versal platform. Add clock enable feature in i2c-cdns
driver.

Thanks,
Karthik, Michal

Changes in v2:
- New patch is series
- change patch possition
- Use compatible data instead of CONFIG_

Michal Simek (1):
  clk: zynq: Add dummy clock enable function

T Karthik Reddy (4):
  clk: zynqmp: Add support to enable clocks
  clk: versal: Add support to enable clocks
  i2c: i2c_cdns: Enable i2c clock
  net: gem: Enable ethernet rx clock for versal

 drivers/clk/clk_versal.c   | 11 
 drivers/clk/clk_zynq.c | 11 
 drivers/clk/clk_zynqmp.c   | 49 ++
 drivers/i2c/i2c-cdns.c |  7 +
 drivers/mmc/zynq_sdhci.c   |  2 +-
 drivers/net/zynq_gem.c | 37 +++--
 drivers/serial/serial_zynq.c   |  2 +-
 drivers/spi/zynq_qspi.c|  2 +-
 drivers/spi/zynq_spi.c |  2 +-
 drivers/spi/zynqmp_gqspi.c |  2 +-
 drivers/watchdog/xilinx_wwdt.c |  3 +--
 11 files changed, 113 insertions(+), 15 deletions(-)

-- 
2.30.0

Re: [PATCH] efidebug: Introduce bootmgr command

[Wolfgang Denk]

Dear Ilias,

In message  you wrote:
>
> The efidebug for boot options wasn't introduced that long ago and I don't
> think anyone uses it in production.  If someone would want to have it 
> backwards 
> compatible, please shout and we'll see what we can do, but I'd strongly 
> prefer 
> replacing it overall. If we truly want backwards compatibility though we must 
> keep
> efidebug, changing the name to something like 'efi debug' just for the name
> similarity wouldn't help much as it would break things regardless.

In this case, "debug" would just be a sub-command of the "efi"
command, with more sub-commands under efi (like bootmgr or such)
following, same as we did for example with "env" (where many
commands maintain backward compatibility, but here this was
necessary because these have been in use forever):

env print   -> printenv
env save-> saveenv
env set -> setenv

etc.

Maybe a similar approach makes sense for "efi" (with or without
backward compatibility, as you like - after all, this is just a
little name space pollution ;-) :

efi:
efi debug
efi bootmgr
efi ...

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
If you believe that feeling bad or worrying long enough will change a
past or future event, then you are residing on another planet with  a
different reality system.

Re: [PATCH] xilinx: Show silicon version in SPL

[Michal Simek]

út 2. 2. 2021 v 16:51 odesílatel Michal Simek  napsal:
>
> Both Zynq and ZynqMP can show silicon versions in SPL boot flow. It is
> useful to be aware.
> The patch is also fixing possition of these bits on ZynqMP.
>
> Signed-off-by: Michal Simek 
> ---
>
>  arch/arm/mach-zynqmp/include/mach/hardware.h | 4 ++--
>  board/xilinx/zynq/board.c| 3 +++
>  board/xilinx/zynqmp/zynqmp.c | 1 +
>  3 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-zynqmp/include/mach/hardware.h 
> b/arch/arm/mach-zynqmp/include/mach/hardware.h
> index b328837c694f..3d3c48e24731 100644
> --- a/arch/arm/mach-zynqmp/include/mach/hardware.h
> +++ b/arch/arm/mach-zynqmp/include/mach/hardware.h
> @@ -128,8 +128,8 @@ struct apu_regs {
>
>  #define ZYNQMP_CSU_VERSION_EMPTY_SHIFT 20
>
> -#define ZYNQMP_SILICON_VER_MASK0xF000
> -#define ZYNQMP_SILICON_VER_SHIFT   12
> +#define ZYNQMP_SILICON_VER_MASK0xF
> +#define ZYNQMP_SILICON_VER_SHIFT   0
>
>  struct csu_regs {
> u32 reserved0[4];
> diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
> index 7ac069aaafdf..0fc11a48f14c 100644
> --- a/board/xilinx/zynq/board.c
> +++ b/board/xilinx/zynq/board.c
> @@ -24,6 +24,9 @@ DECLARE_GLOBAL_DATA_PTR;
>
>  int board_init(void)
>  {
> +   if (IS_ENABLED(CONFIG_SPL_BUILD))
> +   printf("Silicon version:\t%d\n", zynq_get_silicon_version());
> +
> return 0;
>  }
>
> diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
> index d18c992e3f8f..8968cf90760f 100644
> --- a/board/xilinx/zynqmp/zynqmp.c
> +++ b/board/xilinx/zynqmp/zynqmp.c
> @@ -328,6 +328,7 @@ int board_init(void)
> if (sizeof(CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE) > 1)
> zynqmp_pmufw_load_config_object(zynqmp_pm_cfg_obj,
> zynqmp_pm_cfg_obj_size);
> +   printf("Silicon version:\t%d\n", zynqmp_get_silicon_version());
>  #else
> if (CONFIG_IS_ENABLED(DM_I2C) && CONFIG_IS_ENABLED(I2C_EEPROM))
> xilinx_read_eeprom();
> --
> 2.30.0
>

Applied.
M

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH] xilinx: common: Fix CONFIG_XILINX_OF_BOARD_DTB_ADDR handling for ZynqMP

[Michal Simek]

út 2. 2. 2021 v 13:40 odesílatel Michal Simek  napsal:
>
> Fix bug introduced by commit listed below. It is for cases where Versal or
> ZynqMP don't have DDR mapped. Later SPL was also excluded by
> commit a672b9871b57 ("xilinx: common: Do not touch
> CONFIG_XILINX_OF_BOARD_DTB_ADDR in SPL").
>
> Fixes: 506009fc1022 ("xilinx: common: Change macro handling in 
> board_fdt_blob_setup()")
> Signed-off-by: Michal Simek 
> ---
>
>  board/xilinx/common/board.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
> index 4df10bf18941..a2f2fde64b65 100644
> --- a/board/xilinx/common/board.c
> +++ b/board/xilinx/common/board.c
> @@ -326,7 +326,7 @@ void *board_fdt_blob_setup(void)
>
> if (!IS_ENABLED(CONFIG_SPL_BUILD) &&
> !IS_ENABLED(CONFIG_VERSAL_NO_DDR) &&
> -   !IS_ENABLED(CONFIG_VERSAL_NO_DDR)) {
> +   !IS_ENABLED(CONFIG_ZYNQMP_NO_DDR)) {
> fdt_blob = (void *)CONFIG_XILINX_OF_BOARD_DTB_ADDR;
>
> if (fdt_magic(fdt_blob) == FDT_MAGIC)
> --
> 2.30.0
>

Applied.
M

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH 0/4] clk: Add support to enable clocks

[Michal Simek]

st 3. 2. 2021 v 13:18 odesílatel Michal Simek  napsal:
>
> Hi,
>
> Add support to enable clocks using clock subsystem ops for
> zynqmp & versal platforms. Enable rx clock in ethernet driver
> for versal platform. Add clock enable feature in i2c-cdns
> driver.
>
> Thanks,
> Karthik, Michal
>
>
> T Karthik Reddy (4):
>   clk: zynqmp: Add support to enable clocks
>   i2c: i2c_cdns: Enable i2c clock
>   clk: versal: Add support to enable clocks
>   net: gem: Enable ethernet rx clock for versal
>
>  drivers/clk/clk_versal.c | 11 +
>  drivers/clk/clk_zynqmp.c | 49 
>  drivers/i2c/i2c-cdns.c   |  7 ++
>  drivers/net/zynq_gem.c   | 26 -
>  4 files changed, 87 insertions(+), 6 deletions(-)
>
> --
> 2.30.0
>

Please ignore this series. It needs to be redone.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH] efidebug: Introduce bootmgr command

[Ilias Apalodimas]

Hi Wolfgang,

Thanks for having a look, 

On Wed, Feb 10, 2021 at 12:23:47PM +0100, Wolfgang Denk wrote:
> Dear Ilias,
> 
> In message <20210210105425.356131-1-ilias.apalodi...@linaro.org> you wrote:
> > Up to now we've been adding all the efi related configuration to
> > 'efidebug' command.  The command name feels a bit weird to configure boot
> > manager related commands.  Since the bootmanager is growing and we intend
> > to extend it with features like defining the initrd we want to expose to
> > the kernel, it would make sense to split it on a command of it's own.
> >
> > So let's introduce a new command called bootmgr and move all of the
> > existing Boot manager functionality there.
> 
> As this is EFI specific, I would appreciate to have "efi" in the
> command name, too.
> 
> Maybe all EFi related commands should be collected as "efi "
> like we did it with the "env" commands long ago.

We could, I'll discuss this with Heinrich and see what he thinks.

> 
> For backward compatibility e. g. 'efidebug' could be kept, but the
> new name would be 'efi debug'; likewise, your new command would be
> 'efi bootmgr' [or just 'efi boot' ?]

The efidebug for boot options wasn't introduced that long ago and I don't
think anyone uses it in production.  If someone would want to have it backwards 
compatible, please shout and we'll see what we can do, but I'd strongly prefer 
replacing it overall. If we truly want backwards compatibility though we must 
keep
efidebug, changing the name to something like 'efi debug' just for the name
similarity wouldn't help much as it would break things regardless.

Heinrich feel free to ignore the followup patch fixing the documentation of
efidebug.  I'll change the name to something we all agree and fold in the doc
changes in v2.

Thanks
/Ilias
> 
> Thanks!
> 
> 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
> In my experience the best way to get something done  is to give it to
> someone who is busy.   - Terry Pratchett, _Going_Postal_

Re: [PATCH] efidebug: Introduce bootmgr command

[Wolfgang Denk]

Dear Ilias,

In message <20210210105425.356131-1-ilias.apalodi...@linaro.org> you wrote:
> Up to now we've been adding all the efi related configuration to
> 'efidebug' command.  The command name feels a bit weird to configure boot
> manager related commands.  Since the bootmanager is growing and we intend
> to extend it with features like defining the initrd we want to expose to
> the kernel, it would make sense to split it on a command of it's own.
>
> So let's introduce a new command called bootmgr and move all of the
> existing Boot manager functionality there.

As this is EFI specific, I would appreciate to have "efi" in the
command name, too.

Maybe all EFi related commands should be collected as "efi "
like we did it with the "env" commands long ago.

For backward compatibility e. g. 'efidebug' could be kept, but the
new name would be 'efi debug'; likewise, your new command would be
'efi bootmgr' [or just 'efi boot' ?]

Thanks!

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
In my experience the best way to get something done  is to give it to
someone who is busy.   - Terry Pratchett, _Going_Postal_

[PATCH] doc: update efidebug command

[Ilias Apalodimas]

We moved the variable related functionality from efidebug to bootmgr
command. Change the relevant documentation to indicate the new command

Signed-off-by: Ilias Apalodimas 
---
 doc/api/efi.rst   | 5 ++---
 doc/uefi/uefi.rst | 2 +-
 doc/usage/bootefi.rst | 4 ++--
 3 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/doc/api/efi.rst b/doc/api/efi.rst
index cb2a1c897e69..2ecb3ffe324f 100644
--- a/doc/api/efi.rst
+++ b/doc/api/efi.rst
@@ -47,9 +47,8 @@ The relevant variables are:
 Efidebug command
 
 
-The efidebug command is used to set and display boot options as well as to
-display information about internal data of the UEFI subsystem (devices,
-drivers, handles, loaded images, and the memory map).
+The efidebug command is used display information about internal data of the 
UEFI 
+subsystem (devices, drivers, handles, loaded images, and the memory map).
 
 .. kernel-doc:: cmd/efidebug.c
:internal:
diff --git a/doc/uefi/uefi.rst b/doc/uefi/uefi.rst
index 02a377b834f0..bc20e2813fa2 100644
--- a/doc/uefi/uefi.rst
+++ b/doc/uefi/uefi.rst
@@ -224,7 +224,7 @@ UEFI variables. Booting according to these variables is 
possible via::
 bootefi bootmgr [fdt address]
 
 As of U-Boot v2020.10 UEFI variables cannot be set at runtime. The U-Boot
-command 'efidebug' can be used to set the variables.
+command 'bootmgr' can be used to set the variables.
 
 Executing the built in hello world application
 ~~
diff --git a/doc/usage/bootefi.rst b/doc/usage/bootefi.rst
index 282f22aac966..89117806a8d8 100644
--- a/doc/usage/bootefi.rst
+++ b/doc/usage/bootefi.rst
@@ -66,7 +66,7 @@ option to execute next. If no binary can be loaded via 
*BootNext* the variable
 *BootOrder* specifies in which sequence boot options shalled be tried.
 
 The values of these variables can be managed using the U-Boot command
-*efidebug*.
+*bootmgr*.
 
 UEFI hello world application
 
@@ -132,4 +132,4 @@ See also
 * *bootm* for launching UEFI binaries packed in FIT images
 * *booti*, *bootm*, *bootz* for launching a Linux kernel without using the
   UEFI sub-system
-* *efidebug* for setting UEFI boot variables
+* *bootmgr* for setting UEFI boot variables
-- 
2.30.0

[PATCH] efidebug: Introduce bootmgr command

[Ilias Apalodimas]

Up to now we've been adding all the efi related configuration to
'efidebug' command.  The command name feels a bit weird to configure boot
manager related commands.  Since the bootmanager is growing and we intend
to extend it with features like defining the initrd we want to expose to
the kernel, it would make sense to split it on a command of it's own.

So let's introduce a new command called bootmgr and move all of the
existing Boot manager functionality there.

Signed-off-by: Ilias Apalodimas 
---
 cmd/Makefile  |   1 +
 cmd/bootmgr.c | 640 ++
 cmd/efidebug.c| 580 +---
 doc/board/emulation/qemu_capsule_update.rst   |   8 +-
 doc/uefi/uefi.rst |   2 +-
 .../test_efi_capsule/test_capsule_firmware.py |  12 +-
 test/py/tests/test_efi_secboot/test_signed.py |  48 +-
 .../test_efi_secboot/test_signed_intca.py |  22 +-
 .../tests/test_efi_secboot/test_unsigned.py   |  22 +-
 9 files changed, 699 insertions(+), 636 deletions(-)
 create mode 100644 cmd/bootmgr.c

diff --git a/cmd/Makefile b/cmd/Makefile
index 176bf925fdc4..c50fe9204757 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_CMD_BLOCK_CACHE) += blkcache.o
 obj-$(CONFIG_CMD_BMP) += bmp.o
 obj-$(CONFIG_CMD_BOOTCOUNT) += bootcount.o
 obj-$(CONFIG_CMD_BOOTEFI) += bootefi.o
+obj-$(CONFIG_CMD_BOOTEFI_BOOTMGR) += bootmgr.o
 obj-$(CONFIG_CMD_BOOTMENU) += bootmenu.o
 obj-$(CONFIG_CMD_BOOTSTAGE) += bootstage.o
 obj-$(CONFIG_CMD_BOOTZ) += bootz.o
diff --git a/cmd/bootmgr.c b/cmd/bootmgr.c
new file mode 100644
index ..332aac4198bc
--- /dev/null
+++ b/cmd/bootmgr.c
@@ -0,0 +1,640 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  UEFI Bootmanager configuration
+ *
+ *  Copyright (c) 2018 AKASHI Takahiro, Linaro Limited
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static char bootmgr_help_text[] =
+   "  - UEFI Shell-like interface to configure UEFI Boot Manager\n"
+   "bootmgr boot add[:]  []\n"
+   "  - set UEFI Boot variable\n"
+   " will be passed to UEFI application\n"
+   "bootmgr boot rm  [ [ [...]]]\n"
+   "  - delete UEFI Boot variables\n"
+   "bootmgr boot dump\n"
+   "  - dump all UEFI Boot variables\n"
+   "bootmgr boot next \n"
+   "  - set UEFI BootNext variable\n"
+   "bootmgr boot order [ [ [ [...\n"
+   "  - set/show UEFI boot order\n"
+   "\n";
+
+static int u16_tohex(u16 c)
+{
+   if (c >= '0' && c <= '9')
+   return c - '0';
+   if (c >= 'A' && c <= 'F')
+   return c - 'A' + 10;
+
+   /* not hexadecimal */
+   return -1;
+}
+
+/**
+ * show_efi_boot_opt_data() - dump UEFI load option
+ *
+ * @varname16: variable name
+ * @data:  value of UEFI load option variable
+ * @size:  size of the boot option
+ *
+ * Decode the value of UEFI load option variable and print information.
+ */
+static void show_efi_boot_opt_data(u16 *varname16, void *data, size_t *size)
+{
+   struct efi_load_option lo;
+   char *label, *p;
+   size_t label_len16, label_len;
+   u16 *dp_str;
+   efi_status_t ret;
+
+   ret = efi_deserialize_load_option(, data, size);
+   if (ret != EFI_SUCCESS) {
+   printf("%ls: invalid load option\n", varname16);
+   return;
+   }
+
+   label_len16 = u16_strlen(lo.label);
+   label_len = utf16_utf8_strnlen(lo.label, label_len16);
+   label = malloc(label_len + 1);
+   if (!label)
+   return;
+   p = label;
+   utf16_utf8_strncpy(, lo.label, label_len16);
+
+   printf("%ls:\nattributes: %c%c%c (0x%08x)\n",
+  varname16,
+  /* ACTIVE */
+  lo.attributes & LOAD_OPTION_ACTIVE ? 'A' : '-',
+  /* FORCE RECONNECT */
+  lo.attributes & LOAD_OPTION_FORCE_RECONNECT ? 'R' : '-',
+  /* HIDDEN */
+  lo.attributes & LOAD_OPTION_HIDDEN ? 'H' : '-',
+  lo.attributes);
+   printf("  label: %s\n", label);
+
+   dp_str = efi_dp_str(lo.file_path);
+   printf("  file_path: %ls\n", dp_str);
+   efi_free_pool(dp_str);
+
+   printf("  data:\n");
+   print_hex_dump("", DUMP_PREFIX_OFFSET, 16, 1,
+  lo.optional_data, *size, true);
+   free(label);
+}
+
+/**
+ * show_efi_boot_opt() - dump UEFI load option
+ *
+ * @varname16: variable name
+ *
+ * Dump information defined by UEFI load option.
+ */
+static void show_efi_boot_opt(u16 *varname16)
+{
+   void *data;
+   efi_uintn_t size;
+   efi_status_t ret;
+
+   size = 0;
+   ret = EFI_CALL(efi_get_variable(varname16, _global_variable_guid,
+   NULL, , NULL));
+   if (ret == EFI_BUFFER_TOO_SMALL) {
+   data = malloc(size);
+   if (!data) {
+