[PATCH] soc: soc_ti_k3: identify j7200 SR2.0 SoCs

2022-06-21 Thread Bryan Brattlof
Anytime a new revision of a chip is produced, Texas Instruments
will increment the 4 bit VARIANT section of the CTRLMMR_WKUP_JTAGID
register by one. Typically this will be decoded as SR1.0 -> SR2.0 ...
however a few TI SoCs do not follow this convention.

Rather than defining a revision string array for each SoC, use a
default revision string array for all TI SoCs that continue to follow
the typical 1.0 -> 2.0 revision scheme.

Signed-off-by: Bryan Brattlof 
---
 drivers/soc/soc_ti_k3.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/soc/soc_ti_k3.c b/drivers/soc/soc_ti_k3.c
index 965728e8185a0..88bf153d9f6a6 100644
--- a/drivers/soc/soc_ti_k3.c
+++ b/drivers/soc/soc_ti_k3.c
@@ -60,8 +60,8 @@ static char *j721e_rev_string_map[] = {
"1.0", "1.1",
 };
 
-static char *am65x_rev_string_map[] = {
-   "1.0", "2.0",
+static char *typical_rev_string_map[] = {
+   "1.0", "2.0", "3.0",
 };
 
 static const char *get_rev_string(u32 idreg)
@@ -78,16 +78,10 @@ static const char *get_rev_string(u32 idreg)
goto bail;
return j721e_rev_string_map[rev];
 
-   case AM65X:
-   if (rev > ARRAY_SIZE(am65x_rev_string_map))
-   goto bail;
-   return am65x_rev_string_map[rev];
-
-   case AM64X:
-   case J7200:
default:
-   if (!rev)
-   return "1.0";
+   if (rev > ARRAY_SIZE(typical_rev_string_map))
+   goto bail;
+   return typical_rev_string_map[rev];
};
 
 bail:
-- 
2.17.1



Re: [PATCH V2] imx: imx93_11x11_evk: using binman to pack images

2022-06-21 Thread Alper Nebi Yasak
On 13/06/2022 09:13, Peng Fan (OSS) wrote:
> From: Peng Fan 
> 
> Use BINMAN to generate flash.bin
> 
> Signed-off-by: Peng Fan 
> ---
> 
> Based on
> https://patchwork.ozlabs.org/project/uboot/cover/20220611132035.32698-1-peng@oss.nxp.com/
> 
>  V2:
>   Typo correct
> 
>  arch/arm/dts/imx93-11x11-evk-u-boot.dtsi |  2 +
>  arch/arm/dts/imx93-u-boot.dtsi   | 84 
>  arch/arm/mach-imx/Makefile   | 24 +++
>  arch/arm/mach-imx/imx9/Kconfig   |  1 +
>  arch/arm/mach-imx/imx9/container.cfg | 11 
>  arch/arm/mach-imx/imx9/imximage.cfg  | 15 +
>  board/freescale/imx93_evk/Kconfig|  6 ++
>  7 files changed, 143 insertions(+)
>  create mode 100644 arch/arm/dts/imx93-u-boot.dtsi
>  create mode 100644 arch/arm/mach-imx/imx9/container.cfg
>  create mode 100644 arch/arm/mach-imx/imx9/imximage.cfg
> 
> diff --git a/arch/arm/dts/imx93-11x11-evk-u-boot.dtsi 
> b/arch/arm/dts/imx93-11x11-evk-u-boot.dtsi
> index 6f02b389893..e5912a85ca2 100644
> --- a/arch/arm/dts/imx93-11x11-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx93-11x11-evk-u-boot.dtsi
> @@ -3,6 +3,8 @@
>   * Copyright 2022 NXP
>   */
>  
> +#include "imx93-u-boot.dtsi"
> +
>  / {
>   wdt-reboot {
>   compatible = "wdt-reboot";
> diff --git a/arch/arm/dts/imx93-u-boot.dtsi b/arch/arm/dts/imx93-u-boot.dtsi
> new file mode 100644
> index 000..2b6bfd0cb44
> --- /dev/null
> +++ b/arch/arm/dts/imx93-u-boot.dtsi
> @@ -0,0 +1,84 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright 2022 NXP
> + * Peng Fan 
> + */
> +
> +/ {
> + binman: binman {
> + multiple-images;
> + };
> +};
> +
> +&binman {
> +  u-boot-spl-ddr {
> + filename = "u-boot-spl-ddr.bin";
> + pad-byte = <0xff>;
> + align-size = <4>;
> + align = <4>;
> +
> + u-boot-spl {
> + align-end = <4>;
> + };
> +
> + blob_1: blob-ext@1 {
> + filename = "lpddr4_imem_1d_v202201.bin";
> + size = <0x8000>;
> + };
> +
> + blob_2: blob-ext@2 {
> + filename = "lpddr4_dmem_1d_v202201.bin";
> + size = <0x4000>;
> + };
> +
> + blob_3: blob-ext@3 {
> + filename = "lpddr4_imem_2d_v202201.bin";
> + size = <0x8000>;
> + };
> +
> + blob_4: blob-ext@4 {
> + filename = "lpddr4_dmem_2d_v202201.bin";
> + size = <0x4000>;
> + };

These look like the same kind of files as those in your i.MX8M binman
symbols series. So I suggest these can be named like 'ddr-1d-imem-fw' as
well.

> + };
> +
> + spl {
> + filename = "spl.bin";
> +
> + mkimage {
> + args = "-n spl/u-boot-spl.cfgout -T imx8image -e 
> 0x2049a000";
> +
> + blob {
> + filename = "u-boot-spl-ddr.bin";
> + };
> + };
> + };
> +
> + u-boot-container {
> + filename = "u-boot-container.bin";
> +
> + mkimage {
> + args = "-n u-boot-container.cfgout -T imx8image -e 0x0";
> +
> + blob {
> + filename = "u-boot.bin";
> + };
> + };
> + };

The entire thing looks similar to i.MX8M, except for this custom
container. Why not a FIT image here?

> +
> + imx-boot {
> + filename = "flash.bin";
> + pad-byte = <0x00>;
> +
> + spl: blob-ext@1 {
> + filename = "spl.bin";
> + offset = <0x0>;
> + align-size = <0x400>;
> + align = <0x400>;
> + };
> +
> + uboot: blob-ext@2 {
> + filename = "u-boot-container.bin";
> + };
> + };
> +};
> diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> index 71ac8e6ffde..2f51226e0d9 100644
> --- a/arch/arm/mach-imx/Makefile
> +++ b/arch/arm/mach-imx/Makefile
> @@ -120,6 +120,9 @@ DEPFILE_EXISTS := $(shell $(CPP) $(cpp_flags) -x c -o 
> u-boot-dtb.cfgout $(srctre
>  else ifeq ($(CONFIG_ARCH_IMX8M), y)
>  IMAGE_TYPE := imx8mimage
>  DEPFILE_EXISTS := 0
> +else ifeq ($(CONFIG_ARCH_IMX9), y)
> +IMAGE_TYPE := imx8image
> +DEPFILE_EXISTS := 0
>  else
>  IMAGE_TYPE := imximage
>  DEPFILE_EXISTS := 0
> @@ -171,6 +174,27 @@ flash.bin: spl/u-boot-spl-ddr.bin u-boot.itb FORCE
>   $(call if_changed,mkimage)
>  endif
>  
> +ifeq ($(CONFIG_ARCH_IMX9), y)
> +
> +SPL: spl/u-boot-spl.bin spl/u-boot-spl.cfgout u-boot-container.cfgout FORCE
> +
> +MKIMAGEFLAGS_flash.bin = -n spl/u-boot-spl.cfgout -T $(IMAGE_TYPE) -e 
> $(CONFIG_SPL_TEXT_BASE)
> +flash.bin: MKIMAGEOUTPUT = flash.log
> +
> +spl/u-boot-spl.cfgout: $(IMX_CONFIG) FORCE
> + $(Q)mkdir

[PATCH] mtd: mxs_nand_spl: fix nand_command protocol violation

2022-06-21 Thread Michael Trimarchi
From: Andrea Scian 

mxs_nand_command() implementation assume that it's working with a
LP NAND, which is a common case nowadays and thus uses two bytes
for column address.

However this is wrong for NAND_CMD_READID and NAND_CMD_PARAM, which
expects only one byte of column address, even for LP NANDs.
This leads to ONFI detection problem with some NAND manufacturer (like
Winbond) but not with others (like Samsung and Spansion)

We fix this with a simple workaround to avoid the 2nd byte column address
for those two commands.

Also align the code with nand_base to support 16 bit devices.

Tested on an iMX6SX device with:
* Winbond W29N04GVSIAA
* Spansion S34ML04G100TF100
* Samsung K9F4G08U00

Tested on imx8mn device with:
* Windbond W29N04GV

Signed-off-by: Andrea Scian 
CC: Stefano Babic 
Signed-off-by: Michael Trimarchi 
---
 drivers/mtd/nand/raw/mxs_nand_spl.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/raw/mxs_nand_spl.c 
b/drivers/mtd/nand/raw/mxs_nand_spl.c
index 2bfb181007..3daacbb330 100644
--- a/drivers/mtd/nand/raw/mxs_nand_spl.c
+++ b/drivers/mtd/nand/raw/mxs_nand_spl.c
@@ -29,8 +29,20 @@ static void mxs_nand_command(struct mtd_info *mtd, unsigned 
int command,
 
/* Serially input address */
if (column != -1) {
+   /* Adjust columns for 16 bit buswidth */
+   if (chip->options & NAND_BUSWIDTH_16 &&
+   !nand_opcode_8bits(command))
+   column >>= 1;
chip->cmd_ctrl(mtd, column, NAND_ALE);
-   chip->cmd_ctrl(mtd, column >> 8, NAND_ALE);
+
+   /*
+* Assume LP NAND here, so use two bytes column address
+* but not for CMD_READID and CMD_PARAM, which require
+* only one byte column address
+*/
+   if (command != NAND_CMD_READID &&
+   command != NAND_CMD_PARAM)
+   chip->cmd_ctrl(mtd, column >> 8, NAND_ALE);
}
if (page_addr != -1) {
chip->cmd_ctrl(mtd, page_addr, NAND_ALE);
-- 
2.25.1



Open-Source Firmware Conference 2022 in Sweden - September 19 - 21

2022-06-21 Thread Christian Walter

Dead u-boot community,

The Open-Source Firmware Conference is *the* biggest conference 
worldwide around open-source firmware. We would like to invite all of 
you to be part of the OSFC this year again. For this year's OSFC, we 
will move to Sweden, Gothenburg from September 19th until the 21st. So 
if you like to join in grab some early-bird tickets at https://www.osfc.io .


Currently our Call for Participation is ongoing, and will close end of 
this week.


Additionally we set up a scholarship program for developers 
(non-business) that want to attend the OSFC but need financial support. 
You can fill out the form here: 
https://docs.google.com/forms/d/e/1FAIpQLSeo15lVbdQ1VV_vONW5L2BO7cvcyD2POQr6VPRpRz56CjlIrg/viewform


We are looking forward to welcome you in Sweden, and would love to see 
some contributions from the u-boot community!


Best Regards,

Chris

PS: If you have any questions - feel free to ping me!

--
*Christian Walter*
*Head of Firmware Development / Cyber Security *



9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Email: christian.wal...@9elements.com
Phone: _+49 234 68 94 188 _
Mobile: _+49 176 70845047 _

Sitz der Gesellschaft: Bochum
Handelsregister: Amtsgericht Bochum, HRB 17519
Geschäftsführung: Sebastian Deutsch, Eray Basar

Datenschutzhinweise nach Art. 13 DSGVO 


Re: [PATCH v3 8/8] board: gw_ventana: enable MV88E61XX DSA support

2022-06-21 Thread Tim Harvey
On Mon, Jun 20, 2022 at 4:42 AM Vladimir Oltean  wrote:
>
> On Mon, May 23, 2022 at 11:25:49AM -0700, Tim Harvey wrote:
> > Add MV88E61XX DSA support:
> >  - update dt: U-Boot dsa driver requires different device-tree syntax
> >than the linux driver in order to link the dsa ports to the mdio bus.
> >  - update defconfig
> >  - replace mv88e61xx_hw_reset weak override with board_phy_config support
> >for mv88e61xx configuration that is outside the scope of the DSA driver
> >
> > Signed-off-by: Tim Harvey 
> > ---
> > v3:
> >  - move mdio's mdio@0 subnode
> > v2: no changes
> > ---
> >  arch/arm/dts/imx6qdl-gw5904.dtsi| 41 
> >  board/gateworks/gw_ventana/gw_ventana.c | 50 +
> >  configs/gwventana_gw5904_defconfig  |  7 ++--
> >  3 files changed, 62 insertions(+), 36 deletions(-)
> >
> > diff --git a/arch/arm/dts/imx6qdl-gw5904.dtsi 
> > b/arch/arm/dts/imx6qdl-gw5904.dtsi
> > index 286c7a9924c2..1b2f70d1ccb2 100644
> > --- a/arch/arm/dts/imx6qdl-gw5904.dtsi
> > +++ b/arch/arm/dts/imx6qdl-gw5904.dtsi
> > @@ -219,6 +219,33 @@
> >   compatible = "marvell,mv88e6085";
> >   reg = <0>;
> >
> > + mdios {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + mdio@0 {
> > + reg = <0>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + sw_phy0: ethernet-phy@0 {
> > + reg = <0x0>;
> > + };
> > +
> > + sw_phy1: ethernet-phy@1 {
> > + reg = <0x1>;
> > + };
> > +
> > + sw_phy2: ethernet-phy@2 {
> > + reg = <0x2>;
> > + };
> > +
> > + sw_phy3: ethernet-phy@3 {
> > + reg = <0x3>;
> > + };
> > + };
> > + };
> > +
> >   ports {
> >   #address-cells = <1>;
> >   #size-cells = <0>;
> > @@ -226,27 +253,41 @@
> >   port@0 {
> >   reg = <0>;
> >   label = "lan4";
> > + phy-mode = "internal";
> > + phy-handle = <&sw_phy0>;
> >   };
> >
> >   port@1 {
> >   reg = <1>;
> >   label = "lan3";
> > + phy-mode = "internal";
> > + phy-handle = <&sw_phy1>;
> >   };
> >
> >   port@2 {
> >   reg = <2>;
> >   label = "lan2";
> > + phy-mode = "internal";
> > + phy-handle = <&sw_phy2>;
> >   };
> >
> >   port@3 {
> >   reg = <3>;
> >   label = "lan1";
> > + phy-mode = "internal";
> > + phy-handle = <&sw_phy3>;
> >   };
> >
> >   port@5 {
> >   reg = <5>;
> >   label = "cpu";
> >   ethernet = <&fec>;
> > + phy-mode = "rgmii-id";
> > +
> > + fixed-link {
> > + speed = <1000>;
> > + full-duplex;
> > + };
> >   };
> >   };
> >   };
> > diff --git a/board/gateworks/gw_ventana/gw_ventana.c 
> > b/board/gateworks/gw_ventana/gw_ventana.c
> > index c06630a66b66..bef3f7ef0d2b 100644
> > --- a/board/gateworks/gw_ventana/gw_ventana.c
> > +++ b/board/gateworks/gw_ventana/gw_ventana.c
> > @@ -68,44 +68,30 @@ int board_phy_config(struct phy_device *phydev)
> >   phy_write(phydev, MDIO_DEVAD_NONE, 14, val);
> >   }
> >
> > + /* Fixed PHY: for GW5904/GW5909 this is Marvell 88E6176 GbE Switch */
> > + else if (phydev->phy_id == 0xa5a55a5a &&
>
> PHY_FIXED_ID, 

Re: [PATCH v3 7/8] net: add MV88E61xx DSA driver

2022-06-21 Thread Tim Harvey
On Tue, Jun 21, 2022 at 12:21 AM Vladimir Oltean
 wrote:
>
> On Mon, Jun 20, 2022 at 04:37:45PM -0700, Tim Harvey wrote:
> > On Mon, Jun 20, 2022 at 4:58 AM Vladimir Oltean
> >  wrote:
> > >
> > > On Mon, May 23, 2022 at 11:25:48AM -0700, Tim Harvey wrote:
> > > > +/* bind and probe the switch mdios */
> > > > +static int mv88e61xx_dsa_probe_mdio(struct udevice *dev)
> > > > +{
> > > > + struct udevice *pdev;
> > > > + ofnode node, mdios;
> > > > + const char *name;
> > > > + int ret;
> > > > +
> > > > + /* bind phy ports of mdios child node to mv88e61xx_mdio device */
> > > > + mdios = dev_read_subnode(dev, "mdios");
> > > > + if (ofnode_valid(mdios)) {
> > > > + ofnode_for_each_subnode(node, mdios) {
> > > > + name = ofnode_get_name(node);
> > > > + ret = device_bind_driver_to_node(dev,
> > > > +  "mv88e61xx_mdio",
> > > > +  name, node, 
> > > > &pdev);
> > > > + if (ret) {
> > > > + dev_err(dev, "failed to bind %s: %d\n", 
> > > > name, ret);
> > > > + continue;
> > > > + }
> > > > +
> > > > + /* need to probe it as there is no compatible to 
> > > > do so */
> > > > + ret = uclass_get_device_by_ofnode(UCLASS_MDIO, 
> > > > node, &pdev);
> > > > + if (ret) {
> > > > + dev_err(dev, "failed to probe %s: %d\n", 
> > > > name, ret);
> > > > + continue;
> > > > + }
> > >
> > > What do you do with this pdev once you get it? Are you missing a 
> > > device_probe() call?
> > > Also, why "pdev" and not "dev"? What does the "p" stand for?
> >
> > struct udevice *dev is passed into the function so I use pdev to
> > iterate over the ports in the mdios node so 'pdev' means 'port' here.
>
> Yes, but those under the mdios node aren't ports, they're MDIO
> controllers, hence my comment.

how about devp (dev pointer) or subdev or mdio?

Tim

>
> > I do not need to do anything with pdev but I must use
> > uclass_get_device_by_ofnode() to probe it and that function requires
> > it. I don't need to call device_probe because
> > uclass_get_device_by_ofnode does it for me
>
> Ok, I didn't notice they all call uclass_get_device_tail() which calls
> device_probe().


Re: [PATCH] arm: dts: imx8mn: sync dts from Linux Kernel

2022-06-21 Thread Tim Harvey
On Tue, Jun 21, 2022 at 6:06 AM Fabio Estevam  wrote:
>
> Hi Heiko,
>
> On Tue, Jun 21, 2022 at 4:06 AM Heiko Thiery  wrote:
>
> > > I think the way to sync dts is to choose one linux release RC to sync.
> > > not just sync partial.
> >
> > It is not partial .. I just wanted to show what changes are made.
>
> I also had the impression that this was a partial sync.
>
> Could you please send a v2 stating the kernel version where you synced
> from in the commit log?
>
> Thanks

Heiko,

Please update the short commit message as well to indicate you are
updating the imx8mn-evk - I found 'arm: dts: imx8mn: sync dts from
Linux Kernel' to think you were updating the imx8mn dtsi.

Best Regards,

Tim


Re: [PATCH v2 8/8] ARM: imxrt1170_defconfig: Add i.MXRT1170 defconfig

2022-06-21 Thread Fabio Estevam
Hi Giulio,

On Sat, Jun 18, 2022 at 11:32 AM Giulio Benetti
 wrote:

> This is due to missing DCACHE function mmu_set_region_dcache_behaviour()
> there is only an empty stub for it and so in the case of i.MXRT1050 when
> using mxsfb.c, that calls that function, I've preferred to disable
> until one day I had time to make it work correctly, but I have no time.

Thanks for the explanation.

Just wanted to check if this option was left by mistake. It is clear now.

Regards,

Fabio Estevam


Migrating drivers/usb/host/ohci-lpc32xx.c in U-Boot to DM?

2022-06-21 Thread Tom Rini
Hey,

As part of migrating more CONFIG symbols to Kconfig, I ran in to
drivers/usb/host/ohci-lpc32xx.c not being migrated to DM yet.  As the
symbols weren't migrated yet, that the deadline for this driver
migration was v2019.07 and otherwise enforced in v2021.07 is probably a
bit of a surprise here.

The good news is that I believe drivers/usb/host/ohci-da8xx.c is a
reasonable template for how the DM conversion should look and it's just
needing the probe written and the data structures added.  Can someone
please look in to doing this conversion?  Thanks!

-- 
Tom


signature.asc
Description: PGP signature


Migrating drivers/usb/host/ohci-at91.c in U-Boot to DM?

2022-06-21 Thread Tom Rini
Hey,

As part of migrating more CONFIG symbols to Kconfig, I ran in to
drivers/usb/host/ohci-at91.c not being migrated to DM yet.  As the
symbols weren't migrated yet, that the deadline for this driver
migration was v2019.07 and otherwise enforced in v2021.07 is probably a
bit of a surprise here.

The good news is that I believe drivers/usb/host/ohci-da8xx.c is a
reasonable template for how the DM conversion should look and it's just
needing the probe written and the data structures added.  Can someone
please look in to doing this conversion?  Thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] i2c: fix stack buffer overflow vulnerability in i2c md command

2022-06-21 Thread Nicolas IOOSS
Hello,

I sent some days ago the vulnerability fix below. I have not received any reply 
yet. Could a maintainer take a look at it, please?

Best regards,
Nicolas

--- Original Message ---
Le vendredi 10 juin 2022 à 4:50 PM,  a écrit :


> From: Nicolas Iooss nicolas.iooss+ub...@ledger.fr
>
>
> When running "i2c md 0 0 8100", the function do_i2c_md parses the
> length into an unsigned int variable named length. The value is then
> moved to a signed variable:
>
> int nbytes = length;
> #define DISP_LINE_LEN 16
> int linebytes = (nbytes > DISP_LINE_LEN) ? DISP_LINE_LEN : nbytes;
>
> ret = dm_i2c_read(dev, addr, linebuf, linebytes);
>
> On systems where integers are 32 bits wide, 0x8100 is a negative
> value to "nbytes > DISP_LINE_LEN" is false and linebytes gets assigned
>
> 0x8100 instead of 16.
>
> The consequence is that the function which reads from the i2c device
> (dm_i2c_read or i2c_read) is called with a 16-byte stack buffer to fill
> but with a size parameter which is too large. In some cases, this could
> trigger a crash. But with some i2c drivers, such as drivers/i2c/nx_i2c.c
> (used with "nexell,s5pxx18-i2c" bus), the size is actually truncated to
> a 16-bit integer. This is because function i2c_transfer expects an
> unsigned short length. In such a case, an attacker who can control the
> response of an i2c device can overwrite the return address of a function
> and execute arbitrary code through Return-Oriented Programming.
>
> Fix this issue by using unsigned integers types in do_i2c_md. While at
> it, make also alen unsigned, as signed sizes can cause vulnerabilities
> when people forgot to check that they can be negative.
>
> Signed-off-by: Nicolas Iooss nicolas.iooss+ub...@ledger.fr
>
> ---
> cmd/i2c.c | 24 
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/cmd/i2c.c b/cmd/i2c.c
> index 9050b2b8d27a..bd04b14024be 100644
> --- a/cmd/i2c.c
> +++ b/cmd/i2c.c
> @@ -200,10 +200,10 @@ void i2c_init_board(void)
> *
> * Returns the address length.
> */
> -static uint get_alen(char *arg, int default_len)
> +static uint get_alen(char *arg, uint default_len)
> {
> - int j;
> - int alen;
> + uint j;
> + uint alen;
>
> alen = default_len;
> for (j = 0; j < 8; j++) {
> @@ -247,7 +247,7 @@ static int do_i2c_read(struct cmd_tbl *cmdtp, int flag, 
> int argc,
> {
> uint chip;
> uint devaddr, length;
> - int alen;
> + uint alen;
> u_char *memaddr;
> int ret;
> #if CONFIG_IS_ENABLED(DM_I2C)
> @@ -301,7 +301,7 @@ static int do_i2c_write(struct cmd_tbl *cmdtp, int flag, 
> int argc,
> {
> uint chip;
> uint devaddr, length;
> - int alen;
> + uint alen;
> u_char *memaddr;
> int ret;
> #if CONFIG_IS_ENABLED(DM_I2C)
> @@ -469,8 +469,8 @@ static int do_i2c_md(struct cmd_tbl *cmdtp, int flag, int 
> argc,
> {
> uint chip;
> uint addr, length;
> - int alen;
> - int j, nbytes, linebytes;
> + uint alen;
> + uint j, nbytes, linebytes;
> int ret;
> #if CONFIG_IS_ENABLED(DM_I2C)
> struct udevice *dev;
> @@ -589,9 +589,9 @@ static int do_i2c_mw(struct cmd_tbl *cmdtp, int flag, int 
> argc,
> {
> uint chip;
> ulong addr;
> - int alen;
> + uint alen;
> uchar byte;
> - int count;
> + uint count;
> int ret;
> #if CONFIG_IS_ENABLED(DM_I2C)
> struct udevice *dev;
> @@ -676,8 +676,8 @@ static int do_i2c_crc(struct cmd_tbl *cmdtp, int flag, 
> int argc,
> {
> uint chip;
> ulong addr;
> - int alen;
> - int count;
> + uint alen;
> + uint count;
> uchar byte;
> ulong crc;
> ulong err;
> @@ -985,7 +985,7 @@ static int do_i2c_loop(struct cmd_tbl *cmdtp, int flag, 
> int argc,
> char *const argv[])
> {
> uint chip;
> - int alen;
> + uint alen;
> uint addr;
> uint length;
> u_char bytes[16];
> --
> 2.32.0


Re: [PATCH] arm: dts: imx8mn: sync dts from Linux Kernel

2022-06-21 Thread Fabio Estevam
Hi Heiko,

On Tue, Jun 21, 2022 at 4:06 AM Heiko Thiery  wrote:

> > I think the way to sync dts is to choose one linux release RC to sync.
> > not just sync partial.
>
> It is not partial .. I just wanted to show what changes are made.

I also had the impression that this was a partial sync.

Could you please send a v2 stating the kernel version where you synced
from in the commit log?

Thanks


Re: [PATCH v5 15/23] tools: Add mkfwumdata tool for FWU metadata image

2022-06-21 Thread Michal Simek




On 6/21/22 12:57, Etienne Carriere wrote:

On Thu, 9 Jun 2022 at 14:31, Sughosh Ganu  wrote:


From: Masami Hiramatsu 

Add 'mkfwumdata' tool which can generate an image of the FWU metadata
which is required for initializing the platform.

Usage:
   mkfwumdata -i NR_IMAGES -b NR_BANKS [--guid] \
 LOCATION_UUID0,IMAGE_TYPE_UUID0,BANK0_IMAGE_UUID[,BANK1_IMAGE_UUID[,...]] \
 LOCATION_UUID1,... \
 IMAGE_FILE

'-i' takes the number of images and '-b' takes the number of
banks. This takes lists of uuids for the images on arguments,
and the last argument must be the output image file name.

'--guid' (or '-g' in short) allows user to specify the location UUID
and image IDs in GUID instead of UUID. This option is useful if the
platform uses GPT partiotion. In this case, the UUID list
(for an image) becomes;

 DiskGUID,ParitionTypeGUID,UniquePartitionGUID,...

Signed-off-by: Masami Hiramatsu 
Signed-off-by: Sughosh Ganu 
---
  tools/Kconfig  |   9 ++
  tools/Makefile |   4 +
  tools/mkfwumdata.c | 298 +
  3 files changed, 311 insertions(+)
  create mode 100644 tools/mkfwumdata.c

diff --git a/tools/Kconfig b/tools/Kconfig
index 117c921da3..3484be99d0 100644
--- a/tools/Kconfig
+++ b/tools/Kconfig
@@ -98,4 +98,13 @@ config TOOLS_MKEFICAPSULE
   optionally sign that file. If you want to enable UEFI capsule
   update feature on your target, you certainly need this.

+config TOOLS_MKFWUMDATA
+   bool "Build mkfwumdata command"
+   default y if FWU_MULTI_BANK_UPDATE
+   help
+ This command allows users to create a raw image of the FWU
+ metadata for initial installation of the FWU multi bank
+ update on the board. The installation method depends on
+ the platform.
+
  endmenu
diff --git a/tools/Makefile b/tools/Makefile
index 9f2339666a..cd39e5ff6f 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -245,6 +245,10 @@ HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include
  HOSTLDLIBS_mkeficapsule += -lgnutls -luuid
  hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule

+mkfwumdata-objs := mkfwumdata.o lib/crc32.o
+HOSTLDLIBS_mkfwumdata += -luuid
+hostprogs-$(CONFIG_TOOLS_MKFWUMDATA) += mkfwumdata
+
  # We build some files with extra pedantic flags to try to minimize things
  # that won't build on some weird host compiler -- though there are lots of
  # exceptions for files that aren't complaint.
diff --git a/tools/mkfwumdata.c b/tools/mkfwumdata.c
new file mode 100644
index 00..4eb304cae3
--- /dev/null
+++ b/tools/mkfwumdata.c
@@ -0,0 +1,298 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* This will dynamically allocate the fwu_mdata */
+#define CONFIG_FWU_NUM_BANKS   0
+#define CONFIG_FWU_NUM_IMAGES_PER_BANK 0
+
+/* Since we can not include fwu.h, redefine version here. */
+#define FWU_MDATA_VERSION  1
+
+typedef uint8_t u8;
+typedef int16_t s16;
+typedef uint16_t u16;
+typedef uint32_t u32;
+typedef uint64_t u64;
+
+#include 
+
+/* TODO: Endianess conversion may be required for some arch. */
+
+static const char *opts_short = "b:i:a:gh";
+
+static struct option options[] = {
+   {"banks", required_argument, NULL, 'b'},
+   {"images", required_argument, NULL, 'i'},
+   {"guid", required_argument, NULL, 'g'},
+   {"active-bank", required_argument, NULL, 'a'},
+   {"help", no_argument, NULL, 'h'},
+   {NULL, 0, NULL, 0},
+};
+
+static void print_usage(void)
+{
+   fprintf(stderr, "Usage: mkfwumdata [options]  [...] 
\n");
+   fprintf(stderr, "Options:\n"
+   "\t-i, --images   Number of images\n"
+   "\t-b, --banksNumber of banks\n"
+   "\t-a, --active-bank  Active bank\n"
+   "\t-g, --guid  Use GUID instead of UUID\n"
+   "\t-h, --help  print a help message\n"
+   );
+   fprintf(stderr, "UUIDs list syntax:\n"
+   "\t,,[,]\n"
+   "\n\tYou must specify # of banks of image-uuid and # of images of 
the lists.\n"


It's not really explicit how many ',' occurrences are needed.
Maybe:
In a  item, there must be as many 
occurrences as the given number of banks.
There must be as many  items as the given number of images.


+1 on this.
I was trying 2 bank 2 image configuration and it is not clear how it should be 
specified. Better description would be good.


Thanks,
Michal



Re: [PATCH v5 15/23] tools: Add mkfwumdata tool for FWU metadata image

2022-06-21 Thread Patrick DELAUNAY

Hi,

one minor remark.

On 6/9/22 14:30, Sughosh Ganu wrote:

From: Masami Hiramatsu 

Add 'mkfwumdata' tool which can generate an image of the FWU metadata
which is required for initializing the platform.

Usage:
   mkfwumdata -i NR_IMAGES -b NR_BANKS [--guid] \
 LOCATION_UUID0,IMAGE_TYPE_UUID0,BANK0_IMAGE_UUID[,BANK1_IMAGE_UUID[,...]] \
 LOCATION_UUID1,... \
 IMAGE_FILE

'-i' takes the number of images and '-b' takes the number of
banks. This takes lists of uuids for the images on arguments,
and the last argument must be the output image file name.

'--guid' (or '-g' in short) allows user to specify the location UUID
and image IDs in GUID instead of UUID. This option is useful if the
platform uses GPT partiotion. In this case, the UUID list
(for an image) becomes;

 DiskGUID,ParitionTypeGUID,UniquePartitionGUID,...

Signed-off-by: Masami Hiramatsu 
Signed-off-by: Sughosh Ganu 
---
  tools/Kconfig  |   9 ++
  tools/Makefile |   4 +
  tools/mkfwumdata.c | 298 +
  3 files changed, 311 insertions(+)
  create mode 100644 tools/mkfwumdata.c

diff --git a/tools/Kconfig b/tools/Kconfig
index 117c921da3..3484be99d0 100644
--- a/tools/Kconfig
+++ b/tools/Kconfig
@@ -98,4 +98,13 @@ config TOOLS_MKEFICAPSULE
  optionally sign that file. If you want to enable UEFI capsule
  update feature on your target, you certainly need this.
  
+config TOOLS_MKFWUMDATA

+   bool "Build mkfwumdata command"
+   default y if FWU_MULTI_BANK_UPDATE
+   help
+ This command allows users to create a raw image of the FWU
+ metadata for initial installation of the FWU multi bank
+ update on the board. The installation method depends on
+ the platform.
+
  endmenu
diff --git a/tools/Makefile b/tools/Makefile
index 9f2339666a..cd39e5ff6f 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -245,6 +245,10 @@ HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include
  HOSTLDLIBS_mkeficapsule += -lgnutls -luuid
  hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
  
+mkfwumdata-objs := mkfwumdata.o lib/crc32.o

+HOSTLDLIBS_mkfwumdata += -luuid
+hostprogs-$(CONFIG_TOOLS_MKFWUMDATA) += mkfwumdata
+
  # We build some files with extra pedantic flags to try to minimize things
  # that won't build on some weird host compiler -- though there are lots of
  # exceptions for files that aren't complaint.
diff --git a/tools/mkfwumdata.c b/tools/mkfwumdata.c
new file mode 100644
index 00..4eb304cae3
--- /dev/null
+++ b/tools/mkfwumdata.c
@@ -0,0 +1,298 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* This will dynamically allocate the fwu_mdata */
+#define CONFIG_FWU_NUM_BANKS   0
+#define CONFIG_FWU_NUM_IMAGES_PER_BANK 0
+
+/* Since we can not include fwu.h, redefine version here. */
+#define FWU_MDATA_VERSION  1
+


adding typedef should be avoided

can you include "asm/types.h"  or "linux/types.h" to use the generic define


+typedef uint8_t u8;
+typedef int16_t s16;
+typedef uint16_t u16;
+typedef uint32_t u32;
+typedef uint64_t u64;
+
+#include 
+
+/* TODO: Endianess conversion may be required for some arch. */
+
+static const char *opts_short = "b:i:a:gh";
+
+static struct option options[] = {
+   {"banks", required_argument, NULL, 'b'},
+   {"images", required_argument, NULL, 'i'},
+   {"guid", required_argument, NULL, 'g'},
+   {"active-bank", required_argument, NULL, 'a'},
+   {"help", no_argument, NULL, 'h'},
+   {NULL, 0, NULL, 0},
+};
+


[...]

Regards

Patrick



Re: [PATCH v5 13/23] FWU: Add FWU metadata access driver for non-GPT MTD devices

2022-06-21 Thread Patrick DELAUNAY

Hi,

On 6/9/22 14:30, Sughosh Ganu wrote:

From: Masami Hiramatsu 

For the platform which doesn't have GPT partitions for the firmware
but on MTD devices, the FWU metadata is stored on MTD device as raw
image at specific offset. This driver gives the access methods
for the FWU metadata information on such MTD devices.

Signed-off-by: Masami Hiramatsu 
Signed-off-by: Sughosh Ganu 
---
  drivers/fwu-mdata/Kconfig |   8 +
  drivers/fwu-mdata/Makefile|   1 +
  drivers/fwu-mdata/fwu_mdata_mtd.c | 308 ++
  3 files changed, 317 insertions(+)
  create mode 100644 drivers/fwu-mdata/fwu_mdata_mtd.c

diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig
index d5edef19d6..a8fa9ad783 100644
--- a/drivers/fwu-mdata/Kconfig
+++ b/drivers/fwu-mdata/Kconfig
@@ -14,3 +14,11 @@ config FWU_MDATA_GPT_BLK
help
  Enable support for accessing FWU Metadata on GPT partitioned
  block devices.
+
+config FWU_MDATA_MTD
+   bool "FWU Metadata access for non-GPT MTD devices"
+   depends on DM_FWU_MDATA && MTD
+   help
+ Enable support for accessing FWU Metadata on non-partitioned
+ (or non-GPT partitioned, e.g. partition nodes in devicetree)
+ MTD devices.
diff --git a/drivers/fwu-mdata/Makefile b/drivers/fwu-mdata/Makefile
index 12a5b4fe04..c574c59be2 100644
--- a/drivers/fwu-mdata/Makefile
+++ b/drivers/fwu-mdata/Makefile
@@ -5,3 +5,4 @@
  
  obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata-uclass.o

  obj-$(CONFIG_FWU_MDATA_GPT_BLK) += fwu_mdata_gpt_blk.o
+obj-$(CONFIG_FWU_MDATA_MTD) += fwu_mdata_mtd.o
diff --git a/drivers/fwu-mdata/fwu_mdata_mtd.c 
b/drivers/fwu-mdata/fwu_mdata_mtd.c
new file mode 100644
index 00..9eb471e73e
--- /dev/null
+++ b/drivers/fwu-mdata/fwu_mdata_mtd.c
@@ -0,0 +1,308 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2022, Linaro Limited
+ */
+


+ #define LOG_CATEGORY UCLASS_FWU_MDATA

it is requested for log command to filter by uclass


the next include is not needed ?

#include 


+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+struct fwu_mdata_mtd_priv {
+   struct mtd_info *mtd;
+   u32 pri_offset;
+   u32 sec_offset;
+};
+
+enum fwu_mtd_op {
+   FWU_MTD_READ,
+   FWU_MTD_WRITE,
+};
+
+static bool mtd_is_aligned_with_block_size(struct mtd_info *mtd, u64 size)
+{
+   return !do_div(size, mtd->erasesize);
+}
+
+static int mtd_io_data(struct mtd_info *mtd, u32 offs, u32 size, void *data,
+  enum fwu_mtd_op op)
+{
+   struct mtd_oob_ops io_op ={};



missing space : ' = {};'


+   u64 lock_offs, lock_len;
+   size_t len;
+   void *buf;
+   int ret;
+
+   if (!mtd_is_aligned_with_block_size(mtd, offs))
+   return -EINVAL;
+   lock_offs = offs;
+   lock_len = round_up(size, mtd->erasesize);
+
+   ret = mtd_unlock(mtd, lock_offs, lock_len);
+   if (ret && ret != -EOPNOTSUPP)
+   return ret;
+
+   if (op == FWU_MTD_WRITE) {
+   struct erase_info erase_op = {};
+
+   /* This will expand erase size to align with the block size */
+   erase_op.mtd = mtd;
+   erase_op.addr = lock_offs;
+   erase_op.len = lock_len;
+   erase_op.scrub = 0;
+
+   ret = mtd_erase(mtd, &erase_op);
+   if (ret)
+   goto lock_out;
+   }
+
+   /* Also, expand the write size to align with the write size */
+   len = round_up(size, mtd->writesize);
+
+   buf = memalign(ARCH_DMA_MINALIGN, len);
+   if (!buf) {
+   ret = -ENOMEM;
+   goto lock_out;
+   }
+   io_op.mode = MTD_OPS_AUTO_OOB;
+   io_op.len = len;
+   io_op.ooblen = 0;
+   io_op.datbuf = buf;
+   io_op.oobbuf = NULL;
+
+   if (op == FWU_MTD_WRITE) {
+   memcpy(buf, data, size);
+   ret = mtd_write_oob(mtd, offs, &io_op);
+   } else {
+   ret = mtd_read_oob(mtd, offs, &io_op);
+   if (!ret)
+   memcpy(data, buf, size);
+   }
+   free(buf);
+
+lock_out:
+   mtd_lock(mtd, lock_offs, lock_len);
+
+   return ret;
+}
+
+static int fwu_mtd_load_mdata(struct mtd_info *mtd, struct fwu_mdata **mdata,
+ u32 offs, bool primary)
+{
+   size_t size = sizeof(struct fwu_mdata);
+   int ret;
+
+   *mdata = malloc(size);
+   if (!*mdata)
+   return -ENOMEM;
+
+   ret = mtd_io_data(mtd, offs, size, (void *)*mdata, FWU_MTD_READ);
+   if (ret >= 0) {
+   ret = fwu_verify_mdata(*mdata, primary);
+   if (ret < 0) {
+   free(*mdata);
+   *mdata = NULL;
+   }
+   }
+
+   return ret;
+}
+
+static int fwu_mtd_load_primary_mdata(struct fwu_mdata_mtd_priv *mtd_priv,
+   

Re: [PATCH v5 14/23] dt/bindings: firmware: Add FWU metadata on MTD devices binding

2022-06-21 Thread Patrick DELAUNAY

Hi,

On 6/9/22 14:30, Sughosh Ganu wrote:

From: Masami Hiramatsu 

Add a devicetree-binding YAML file for the FWU metadata on MTD
devices without GPT.

Signed-off-by: Masami Hiramatsu 
Signed-off-by: Sughosh Ganu 
---
  .../firmware/uboot,fwu-mdata-mtd.yaml | 38 +++
  1 file changed, 38 insertions(+)
  create mode 100644 doc/device-tree-bindings/firmware/uboot,fwu-mdata-mtd.yaml

diff --git a/doc/device-tree-bindings/firmware/uboot,fwu-mdata-mtd.yaml 
b/doc/device-tree-bindings/firmware/uboot,fwu-mdata-mtd.yaml
new file mode 100644
index 00..4f5404f999
--- /dev/null
+++ b/doc/device-tree-bindings/firmware/uboot,fwu-mdata-mtd.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/u-boot,fwu-mdata-sf.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: FWU metadata on MTD device without GPT
+
+maintainers:
+ - Masami Hiramatsu 
+
+properties:
+  compatible:
+items:
+  - const: u-boot,fwu-mdata-mtd
+
+  fwu-mdata-store:
+maxItems: 1
+description: Phandle of the MTD device which contains the FWU medatata.
+
+  mdata-offsets:
+minItems: 2
+description: Offsets of the primary and secondary FWU metadata in the NOR 
flash.
+
+required:
+  - compatible
+  - fwu-mdata-store
+  - mdata-offsets
+
+additionalProperties: false
+
+examples:
+  - |
+fwu-mdata {
+compatible = "u-boot,fwu-mdata-mtd";
+fwu-mdata-store = <&spi-flash>;
+mdata-offsets = <0x50 0x53>;
+};


Do you need to have offset her => normally it is already managed by mtd 
partition



    spi-flash@0 {
    #address-cells = <1>;
    #size-cells = <1>;
    compatible = "spi-flash", "jedec,spi-nor";

    metadata1: partition@metadata1 {
        reg = <0x50 0x3>;
        label = "metadata1";
    };
    metadata2: partition@metadata2 {
        reg = <0x53 0x3>;
        label = "metadata2";
    };

    };


So the needed offset information can be found with 2 handles

to the MTD partitions in the device tree !

+fwu-mdata {
+compatible = "u-boot,fwu-mdata-mtd";
+fwu-mdata-store = <&metadata1>, <&metadata2>;
+};


This proposal can simplify the binding

+  fwu-mdata-store:
+maxItems: 2
+description: Phandle of the two MTD partitions which contains the FWU 
medatata.

+required:
+  - compatible
+  - fwu-mdata-store

Patrick



Re: [PATCH v5 12/23] FWU: doc: Add documentation for the FWU feature

2022-06-21 Thread Patrick DELAUNAY

Hi,


Two minor issues.


On 6/9/22 14:29, Sughosh Ganu wrote:

Add documentattion for the FWU Multi Bank Update feature. The document


s/documentattio/documentation



describes the steps needed for setting up the platform for the
feature, as well as steps for enabling the feature on the platform.

Signed-off-by: Sughosh Ganu 
---
  doc/develop/uefi/fwu_updates.rst | 142 +++
  doc/develop/uefi/index.rst   |   1 +
  doc/develop/uefi/uefi.rst|   2 +
  3 files changed, 145 insertions(+)
  create mode 100644 doc/develop/uefi/fwu_updates.rst

diff --git a/doc/develop/uefi/fwu_updates.rst b/doc/develop/uefi/fwu_updates.rst
new file mode 100644
index 00..1c34beb7d5
--- /dev/null
+++ b/doc/develop/uefi/fwu_updates.rst
@@ -0,0 +1,142 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (c) 2022 Linaro Limited
+
+FWU Multi Bank Updates in U-Boot
+
+
+The FWU Multi Bank Update feature implements the firmware update
+mechanism described in the PSA Firmware Update for A-profile Arm
+Architecture specification[1]. Certain aspects of the Dependable
+Boot specification[2] are also implemented. The feature provides a
+mechanism to have multiple banks of updatable firmware images and for
+updating the firmware images on the non-booted bank. On a successful
+update, the platform boots from the updated bank on subsequent
+boot. The UEFI capsule-on-disk update feature is used for performing
+the actual updates of the updatable firmware images.
+
+The bookkeeping of the updatable images is done through a structure
+called metadata. Currently, the FWU metadata supports identification
+of images based on image GUIDs stored on a GPT partitioned storage
+media. There are plans to extend the metadata structure for non GPT
+partitioned devices as well.
+
+Accessing the FWU metadata is done through generic API's which are
+defined in a driver which complies with the u-boot's driver model. A
+new uclass UCLASS_FWU_MDATA has been added for accessing the FWU
+metadata. Individual drivers can be added based on the type of storage
+media, and it's partitioning method. Details of the storage device
+containing the FWU metadata partitions are specified through a U-Boot
+specific device tree property `fwu-mdata-store`. Please refer to
+U-Boot `doc `__ for
+the device tree bindings.
+
+Enabling the FWU Multi Bank Update feature
+--
+
+The feature can be enabled by specifying the following configs::
+
+CONFIG_EFI_CAPSULE_ON_DISK=y
+CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT=y
+CONFIG_EFI_CAPSULE_FIRMWARE=y
+CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
+
+CONFIG_FWU_MULTI_BANK_UPDATE=y
+CONFIG_CMD_FWU_METADATA=y
+CONFIG_DM_FWU_MDATA=y
+CONFIG_FWU_MDATA_GPT_BLK=y
+CONFIG_FWU_NUM_BANKS=
+CONFIG_FWU_NUM_IMAGES_PER_BANK=
+
+in the .config file
+
+The first group of configs enable the UEFI capsule-on-disk update
+functionality. The second group of configs enable the FWU Multi Bank
+Update functionality. Please refer to the section
+:ref:`uefi_capsule_update_ref` for more details on generation of the
+UEFI capsule.
+
+Setting up the device for GPT partitioned storage
+-
+
+Before enabling the functionality in U-Boot, certain changes are
+required to be done on the storage device. Assuming a GPT partitioned
+storage device, the storage media needs to be partitioned with the
+correct number of partitions, given the number of banks and number of
+images per bank that the platform is going to support. Each updatable
+firmware image will be stored on an separate partition. In addition,
+the two copies of the FWU metadata will be stored on two separate
+partitions.
+
+As an example, a platform supporting two banks with each bank
+containing three images would need to have 2 * 3 = 6 parititions plus


s/parititions/partitions/



+the two metadata partitions, or 8 partitions. In addition the storage
+media can have additional partitions of non-updatable images, like the
+EFI System Partition(ESP), a partition for the root file system etc.
+
+When generating the partitions, a few aspects need to be taken care
+of. Each GPT partition entry in the GPT header has two GUIDs::
+
+*PartitionTypeGUID*
+*UniquePartitionGUID*
+
+The PartitionTypeGUID value should correspond to the *image_type_uuid*
+field of the FWU metadata. This field is used to identify a given type
+of updatable firmware image, e.g. u-boot, op-tee, FIP etc. This GUID
+should also be used for specifying the `--guid` parameter when
+generating the capsule.
+
+The UniquePartitionGUID value should correspond to the *image_uuid*
+field in the FWU metadata. This GUID is used to identify images of a
+given image type in different banks.
+
+Similarly, the FWU specifications defines the GUID value to be used
+for the metadata partitions. This would be the PartitionTypeGUID for
+the metadata partitions.
+

Re: [PATCH v5 10/23] FWU: cmd: Add a command to read FWU metadata

2022-06-21 Thread Patrick DELAUNAY



On 6/9/22 14:29, Sughosh Ganu wrote:

Add a command to read the metadata as specified in the FWU
specification and print the fields of the metadata.

Signed-off-by: Sughosh Ganu 
---
  cmd/Kconfig |  7 +
  cmd/Makefile|  1 +
  cmd/fwu_mdata.c | 74 +
  3 files changed, 82 insertions(+)
  create mode 100644 cmd/fwu_mdata.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 09193b61b9..275becd837 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -144,6 +144,13 @@ config CMD_CPU
  internal name) and clock frequency. Other information may be
  available depending on the CPU driver.
  
+config CMD_FWU_METADATA

+   bool "fwu metadata read"
+   depends on FWU_MULTI_BANK_UPDATE
+   default y if FWU_MULTI_BANK_UPDATE


+ default y

it is enough with the depends on


+   help
+ Command to read the metadata and dump it's contents
+
  config CMD_LICENSE
bool "license"
select BUILD_BIN2C
diff --git a/cmd/Makefile b/cmd/Makefile
index 5e43a1e022..259a93bc65 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_CMD_FPGA) += fpga.o
  obj-$(CONFIG_CMD_FPGAD) += fpgad.o
  obj-$(CONFIG_CMD_FS_GENERIC) += fs.o
  obj-$(CONFIG_CMD_FUSE) += fuse.o
+obj-$(CONFIG_CMD_FWU_METADATA) += fwu_mdata.o
  obj-$(CONFIG_CMD_GETTIME) += gettime.o
  obj-$(CONFIG_CMD_GPIO) += gpio.o
  obj-$(CONFIG_CMD_HVC) += smccc.o
diff --git a/cmd/fwu_mdata.c b/cmd/fwu_mdata.c
new file mode 100644
index 00..bc20ca26a3
--- /dev/null
+++ b/cmd/fwu_mdata.c
@@ -0,0 +1,74 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2022, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static void print_mdata(struct fwu_mdata *mdata)
+{
+   int i, j;
+   struct fwu_image_entry *img_entry;
+   struct fwu_image_bank_info *img_info;
+   u32 nimages, nbanks;
+
+   printf("\tFWU Metadata\n");
+   printf("crc32: %#x\n", mdata->crc32);
+   printf("version: %#x\n", mdata->version);
+   printf("active_index: %#x\n", mdata->active_index);
+   printf("previous_active_index: %#x\n", mdata->previous_active_index);
+
+   nimages = CONFIG_FWU_NUM_IMAGES_PER_BANK;
+   nbanks = CONFIG_FWU_NUM_BANKS;
+   printf("\tImage Info\n");
+   for (i = 0; i < nimages; i++) {
+   img_entry = &mdata->img_entry[i];
+   printf("\nImage Type Guid: %pUL\n", 
&img_entry->image_type_uuid);
+   printf("Location Guid: %pUL\n", &img_entry->location_uuid);
+   for (j = 0; j < nbanks; j++) {
+   img_info = &img_entry->img_bank_info[j];
+   printf("Image Guid:  %pUL\n", &img_info->image_uuid);
+   printf("Image Acceptance: %#x\n", img_info->accepted);
+   }
+   }
+}
+
+int do_fwu_mdata_read(struct cmd_tbl *cmdtp, int flag,
+int argc, char * const argv[])
+{
+   struct udevice *dev;
+   int ret = CMD_RET_SUCCESS;
+   struct fwu_mdata *mdata = NULL;
+
+   if (uclass_get_device(UCLASS_FWU_MDATA, 0, &dev) || !dev) {
+   log_err("Unable to get FWU metadata device\n");
+   return CMD_RET_FAILURE;
+   }
+


ret is reused here ?

so the default value is overwrite

I think it is better to have 2 variables

ret => cmd result

res => result of fwu_get_mdata() ?


+   ret = fwu_get_mdata(&mdata);
+   if (ret < 0) {
+   log_err("Unable to get valid FWU metadata\n");
+   ret = CMD_RET_FAILURE;
+   goto out;
+   }


+   res = fwu_get_mdata(&mdata);
+   if (res < 0) {
+   log_err("Unable to get valid FWU metadata\n");
+   ret = CMD_RET_FAILURE;
+   goto out;
+   }




+
+   print_mdata(mdata);
+
+out:
+   free(mdata);
+   return ret;
+}
+
+U_BOOT_CMD(
+   fwu_mdata_read, 1,  1,  do_fwu_mdata_read,
+   "Read and print FWU metadata",
+   ""
+);


regards

Patrick



Re: [PATCH v5 09/23] FWU: Add support for the FWU Multi Bank Update feature

2022-06-21 Thread Patrick DELAUNAY

Hi,

On 6/9/22 14:29, Sughosh Ganu wrote:

The FWU Multi Bank Update feature supports updation of firmware images
to one of multiple sets(also called banks) of images. The firmware
images are clubbed together in banks, with the system booting images
from the active bank. Information on the images such as which bank
they belong to is stored as part of the metadata structure, which is
stored on the same storage media as the firmware images on a dedicated
partition.

At the time of update, the metadata is read to identify the bank to
which the images need to be flashed(update bank). On a successful
update, the metadata is modified to set the updated bank as active
bank to subsequently boot from.

Signed-off-by: Sughosh Ganu 
---
  include/fwu.h|  12 +-
  lib/Kconfig  |   6 +
  lib/Makefile |   1 +
  lib/efi_loader/efi_capsule.c | 231 ++-
  lib/efi_loader/efi_setup.c   |   3 +-
  lib/fwu_updates/Kconfig  |  31 +
  lib/fwu_updates/Makefile |   6 +
  lib/fwu_updates/fwu.c|  26 
  8 files changed, 309 insertions(+), 7 deletions(-)
  create mode 100644 lib/fwu_updates/Kconfig
  create mode 100644 lib/fwu_updates/Makefile



[...]



diff --git a/lib/fwu_updates/fwu.c b/lib/fwu_updates/fwu.c
index af884439fb..422ef58661 100644
--- a/lib/fwu_updates/fwu.c
+++ b/lib/fwu_updates/fwu.c
@@ -112,6 +112,32 @@ u8 fwu_update_checks_pass(void)
return !trial_state && boottime_check;
  }
  
+int fwu_trial_state_ctr_start(void)

+{
+   int ret;
+   u32 var_attributes;
+   efi_status_t status;
+   efi_uintn_t var_size;
+   u16 trial_state_ctr;
+
+   var_size = (efi_uintn_t)sizeof(trial_state_ctr);
+   var_attributes = EFI_VARIABLE_NON_VOLATILE |
+   EFI_VARIABLE_BOOTSERVICE_ACCESS;
+
+   trial_state_ctr = ret = 0;
+   status = efi_set_variable_int(L"TrialStateCtr",
+ &efi_global_variable_guid,
+ var_attributes,
+ var_size,
+ &trial_state_ctr, false);



u"TrialStateCtr",

if USC2 is not mandatory.


+   if (status != EFI_SUCCESS) {
+   log_err("Unable to increment TrialStateCtr variable\n");
+   ret = -1;
+   }
+
+   return ret;
+}
+
  int fwu_boottime_checks(void)
  {
int ret;



Regards



[PATCH] toradex: tdx-cfg-block: add 0068 i.mx 8m mini sku

2022-06-21 Thread Philippe Schenker
From: Philippe Schenker 

Add new i.MX 8M Mini SKU to ConfigBlock handling.

0068: Verdin iMX8M Mini Quad 2GB Wi-Fi / BT IT (No CAN)

This SKU is identical to 0055 but without CAN. Mention this in brackets
so those modules can be distinguished.

Signed-off-by: Philippe Schenker 
Reviewed-by: Francesco Dolcini 

---

 board/toradex/common/tdx-cfg-block.c | 13 -
 board/toradex/common/tdx-cfg-block.h |  1 +
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/board/toradex/common/tdx-cfg-block.c 
b/board/toradex/common/tdx-cfg-block.c
index 6c8cf4592d..fa54208ce9 100644
--- a/board/toradex/common/tdx-cfg-block.c
+++ b/board/toradex/common/tdx-cfg-block.c
@@ -145,6 +145,7 @@ const char * const toradex_modules[] = {
[65] = "Verdin iMX8M Plus QuadLite 1GB IT",
[66] = "Verdin iMX8M Plus Quad 8GB Wi-Fi / BT",
[67] = "Apalis iMX8 QuadMax 8GB Wi-Fi / BT IT",
+   [68] = "Verdin iMX8M Mini Quad 2GB Wi-Fi / BT IT (No CAN)",
 };
 
 const char * const toradex_carrier_boards[] = {
@@ -361,6 +362,7 @@ static int get_cfgblock_interactive(void)
char it = 'n';
char wb = 'n';
char mem8g = 'n';
+   char can = 'y';
int len = 0;
 
/* Unknown module by default */
@@ -387,6 +389,13 @@ static int get_cfgblock_interactive(void)
mem8g = console_buffer[0];
}
 #endif
+#if defined(CONFIG_TARGET_VERDIN_IMX8MM)
+   if (is_cpu_type(MXC_CPU_IMX8MM) && (wb == 'y' || wb == 'Y')) {
+   sprintf(message, "Does your module have CAN? [y/N] ");
+   len = cli_readline(message);
+   can = console_buffer[0];
+   }
+#endif
 #endif
 
soc = env_get("soc");
@@ -474,7 +483,9 @@ static int get_cfgblock_interactive(void)
else
tdx_hw_tag.prodid = VERDIN_IMX8MMDL;
} else if (is_cpu_type(MXC_CPU_IMX8MM)) {
-   if (wb == 'y' || wb == 'Y')
+   if (can == 'n' || can == 'N')
+   tdx_hw_tag.prodid = VERDIN_IMX8MMQ_WIFI_BT_IT_NO_CAN;
+   else if (wb == 'y' || wb == 'Y')
tdx_hw_tag.prodid = VERDIN_IMX8MMQ_WIFI_BT_IT;
else
tdx_hw_tag.prodid = VERDIN_IMX8MMQ_IT;
diff --git a/board/toradex/common/tdx-cfg-block.h 
b/board/toradex/common/tdx-cfg-block.h
index 43e662e41d..9697447158 100644
--- a/board/toradex/common/tdx-cfg-block.h
+++ b/board/toradex/common/tdx-cfg-block.h
@@ -88,6 +88,7 @@ enum {
VERDIN_IMX8MPQL_IT, /* 65 */
VERDIN_IMX8MPQ_8GB_WIFI_BT,
APALIS_IMX8QM_8GB_WIFI_BT_IT,
+   VERDIN_IMX8MMQ_WIFI_BT_IT_NO_CAN,
 };
 
 enum {
-- 
2.36.1



Re: [PATCH v5 08/23] FWU: Add boot time checks as highlighted by the FWU specification

2022-06-21 Thread Patrick DELAUNAY

Hi,


On 6/9/22 14:29, Sughosh Ganu wrote:

The FWU Multi Bank Update specification requires the Update Agent to
carry out certain checks at the time of platform boot. The Update
Agent is the component which is responsible for updating the firmware
components and maintaining and keeping the metadata in sync.

The spec requires that the Update Agent perform the following checks
at the time of boot
* Sanity check of both the metadata copies maintained by the platform.
* Get the boot index passed to U-Boot by the prior stage bootloader
   and use this value for metadata bookkeeping.
* Check if the system is booting in Trial State. If the system boots
   in the Trial State for more than a specified number of boot counts,
   change the Active Bank to be booting the platform from.

Add these checks in the board initialisation sequence, invoked after
relocation.

Signed-off-by: Sughosh Ganu 
---
  common/board_r.c  |   5 ++
  include/fwu.h |   3 +
  lib/fwu_updates/fwu.c | 170 ++
  3 files changed, 178 insertions(+)
  create mode 100644 lib/fwu_updates/fwu.c

diff --git a/common/board_r.c b/common/board_r.c
index 6f4aca2077..33a600715d 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -15,6 +15,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -797,6 +798,10 @@ static init_fnc_t init_sequence_r[] = {
  #if defined(CONFIG_PRAM)
initr_mem,
  #endif
+
+#ifdef CONFIG_FWU_MULTI_BANK_UPDATE
+   fwu_boottime_checks,
+#endif
run_main_loop,
  };
  
diff --git a/include/fwu.h b/include/fwu.h

index 41774ff9e2..8fbd91b463 100644
--- a/include/fwu.h
+++ b/include/fwu.h
@@ -33,6 +33,9 @@ struct fwu_mdata_ops {
EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \
 0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23)
  
+int fwu_boottime_checks(void);

+u8 fwu_update_checks_pass(void);
+
  int fwu_get_mdata(struct fwu_mdata **mdata);
  int fwu_update_mdata(struct fwu_mdata *mdata);
  int fwu_get_active_index(u32 *active_idx);
diff --git a/lib/fwu_updates/fwu.c b/lib/fwu_updates/fwu.c
new file mode 100644
index 00..af884439fb
--- /dev/null
+++ b/lib/fwu_updates/fwu.c
@@ -0,0 +1,170 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2022, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static u8 trial_state;
+static u8 boottime_check;
+
+static int fwu_trial_state_check(void)
+{
+   int ret, i;
+   efi_status_t status;
+   efi_uintn_t var_size;
+   u16 trial_state_ctr;
+   u32 nimages, active_bank, var_attributes, active_idx;
+   struct fwu_mdata *mdata = NULL;
+   struct fwu_image_entry *img_entry;
+   struct fwu_image_bank_info *img_bank_info;
+
+   ret = fwu_get_mdata(&mdata);
+   if (ret)
+   return ret;
+
+   ret = 0;
+   nimages = CONFIG_FWU_NUM_IMAGES_PER_BANK;
+   active_bank = mdata->active_index;
+   img_entry = &mdata->img_entry[0];
+   for (i = 0; i < nimages; i++) {
+   img_bank_info = &img_entry[i].img_bank_info[active_bank];
+   if (!img_bank_info->accepted) {
+   trial_state = 1;
+   break;
+   }
+   }
+
+   if (trial_state) {
+   var_size = (efi_uintn_t)sizeof(trial_state_ctr);
+   log_info("System booting in Trial State\n");
+   var_attributes = EFI_VARIABLE_NON_VOLATILE |
+   EFI_VARIABLE_BOOTSERVICE_ACCESS;
+   status = efi_get_variable_int(L"TrialStateCtr",
+ &efi_global_variable_guid,
+ &var_attributes,
+ &var_size, &trial_state_ctr,
+ NULL);


for 'L"TrialStateCtr"' => wide characters for unicode

L string is really needed here ?

cf= 
http://patchwork.ozlabs.org/project/uboot/patch/20220123195514.3152022-5-...@chromium.org/


same for all the other string L"TrialStateCtr" in the file...



+   if (status != EFI_SUCCESS) {
+   log_err("Unable to read TrialStateCtr variable\n");
+   ret = -1;
+   goto out;
+   }
+
+   ++trial_state_ctr;
+   if (trial_state_ctr > CONFIG_FWU_TRIAL_STATE_CNT) {
+   log_info("Trial State count exceeded. Revert back to 
previous_active_index\n");
+   active_idx = mdata->active_index;
+   ret = fwu_revert_boot_index();
+   if (ret) {
+   log_err("Unable to revert active_index\n");
+   goto out;
+   }
+
+   trial_state_ctr = 0;
+   status = efi_set_variable_int(L"TrialStat

Re: [PATCH v5 07/23] FWU: STM32MP1: Add support to read boot index from backup register

2022-06-21 Thread Patrick DELAUNAY

Hi,

On 6/9/22 14:29, Sughosh Ganu wrote:

The FWU Multi Bank Update feature allows the platform to boot the
firmware images from one of the partitions(banks). The first stage
bootloader(fsbl) passes the value of the boot index, i.e. the bank
from which the firmware images were booted from to U-Boot. On the
STM32MP157C-DK2 board, this value is passed through one of the SoC's
backup register. Add a function to read the boot index value from the
backup register.

Signed-off-by: Sughosh Ganu 
---
  arch/arm/mach-stm32mp/include/mach/stm32.h | 4 
  board/st/stm32mp1/stm32mp1.c   | 7 +++
  include/fwu.h  | 2 +-
  3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-stm32mp/include/mach/stm32.h 
b/arch/arm/mach-stm32mp/include/mach/stm32.h
index 47e88fc3dc..40995ee142 100644
--- a/arch/arm/mach-stm32mp/include/mach/stm32.h
+++ b/arch/arm/mach-stm32mp/include/mach/stm32.h
@@ -100,6 +100,7 @@ enum boot_device {
  #define TAMP_BACKUP_REGISTER(x)   (STM32_TAMP_BASE + 0x100 + 4 * 
x)
  #define TAMP_BACKUP_MAGIC_NUMBER  TAMP_BACKUP_REGISTER(4)
  #define TAMP_BACKUP_BRANCH_ADDRESSTAMP_BACKUP_REGISTER(5)
+#define TAMP_FWU_BOOT_INFO_REG TAMP_BACKUP_REGISTER(10)
  #define TAMP_COPRO_RSC_TBL_ADDRESSTAMP_BACKUP_REGISTER(17)
  #define TAMP_COPRO_STATE  TAMP_BACKUP_REGISTER(18)
  #define TAMP_BOOT_CONTEXT TAMP_BACKUP_REGISTER(20)
@@ -118,6 +119,9 @@ enum boot_device {
  #define TAMP_BOOT_INSTANCE_MASK   GENMASK(3, 0)
  #define TAMP_BOOT_FORCED_MASK GENMASK(7, 0)
  #define TAMP_BOOT_DEBUG_ONBIT(16)
+#define TAMP_FWU_BOOT_IDX_MASK GENMASK(3, 0)
+
+#define TAMP_FWU_BOOT_IDX_OFFSET   0
  



please don't mix the 2 TAMP_FWU defines with define and enum for TAMP_BOOT

=> move the 2 defines before TAMP_COPRO defines.


#define TAMP_BACKUP_MAGIC_NUMBER    TAMP_BACKUP_REGISTER(4)
#define TAMP_BACKUP_BRANCH_ADDRESS    TAMP_BACKUP_REGISTER(5)
+ #define TAMP_FWU_BOOT_INFO_REG        TAMP_BACKUP_REGISTER(10)
#define TAMP_COPRO_RSC_TBL_ADDRESS    TAMP_BACKUP_REGISTER(17)
#define TAMP_COPRO_STATE        TAMP_BACKUP_REGISTER(18)
#define TAMP_BOOT_CONTEXT        TAMP_BACKUP_REGISTER(20)
#define TAMP_BOOTCOUNT            TAMP_BACKUP_REGISTER(21)

+

+#define TAMP_FWU_BOOT_IDX_MASK GENMASK(3, 0)

+ #define TAMP_FWU_BOOT_IDX_OFFSET 0


#define TAMP_COPRO_STATE_OFF        0
#define TAMP_COPRO_STATE_INIT        1



  enum forced_boot_mode {
BOOT_NORMAL = 0x00,
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index e68bf09955..dff41ed6f6 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -1081,4 +1081,11 @@ int fwu_plat_get_update_index(u32 *update_idx)
return ret;
  }
  
+void fwu_plat_get_bootidx(void *boot_idx)

+{
+   u32 *bootidx = boot_idx;
+
+   *bootidx = (readl(TAMP_FWU_BOOT_INFO_REG) >>
+   TAMP_FWU_BOOT_IDX_OFFSET) & TAMP_FWU_BOOT_IDX_MASK;
+}
  #endif /* CONFIG_FWU_MULTI_BANK_UPDATE */
diff --git a/include/fwu.h b/include/fwu.h
index 36e58afa29..41774ff9e2 100644
--- a/include/fwu.h
+++ b/include/fwu.h
@@ -46,7 +46,7 @@ int fwu_revert_boot_index(void);
  int fwu_accept_image(efi_guid_t *img_type_id, u32 bank);
  int fwu_clear_accept_image(efi_guid_t *img_type_id, u32 bank);
  
-

+void fwu_plat_get_bootidx(void *boot_idx);
  int fwu_plat_get_alt_num(struct udevice *dev, efi_guid_t *image_guid,
 int *alt_num);
  int fwu_plat_get_update_index(u32 *update_idx);


With the modifications:

Reviewed-by: Patrick Delaunay 

Thanks
Patrick




Re: [PATCH v5 11/23] mkeficapsule: Add support for generating empty capsules

2022-06-21 Thread Etienne Carriere
On Thu, 9 Jun 2022 at 14:31, Sughosh Ganu  wrote:
>
> The Dependable Boot specification[1] describes the structure of the
> firmware accept and revert capsules. These are empty capsules which
> are used for signalling the acceptance or rejection of the updated
> firmware by the OS. Add support for generating these empty capsules.
>
> [1] - 
> https://git.codelinaro.org/linaro/dependable-boot/mbfw/uploads/6f7ddfe3be24e18d4319e108a758d02e/mbfw.pdf
>
> Signed-off-by: Sughosh Ganu 
> ---
>  doc/mkeficapsule.1   |  29 ++---
>  tools/eficapsule.h   |   8 +++
>  tools/mkeficapsule.c | 139 +--
>  3 files changed, 151 insertions(+), 25 deletions(-)
>
> diff --git a/doc/mkeficapsule.1 b/doc/mkeficapsule.1
> index 09bdc24295..77ca061efd 100644
> --- a/doc/mkeficapsule.1
> +++ b/doc/mkeficapsule.1
> @@ -8,7 +8,7 @@ mkeficapsule \- Generate EFI capsule file for U-Boot
>
>  .SH SYNOPSIS
>  .B mkeficapsule
> -.RI [ options "] " image-blob " " capsule-file
> +.RI [ options ] " " [ image-blob ] " " capsule-file
>
>  .SH "DESCRIPTION"
>  .B mkeficapsule
> @@ -23,8 +23,13 @@ Optionally, a capsule file can be signed with a given 
> private key.
>  In this case, the update will be authenticated by verifying the signature
>  before applying.
>
> +Additionally, an empty capsule file can be generated for acceptance or
> +rejection of firmware images by a governing component like an Operating
> +System. The empty capsules do not require an image-blob input file.
> +
> +
>  .B mkeficapsule
> -takes any type of image files, including:
> +takes any type of image files when generating non empty capsules, including:
>  .TP
>  .I raw image
>  format is a single binary blob of any type of firmware.
> @@ -36,18 +41,16 @@ multiple binary blobs in a single capsule file.
>  This type of image file can be generated by
>  .BR mkimage .
>
> -.PP
> -If you want to use other types than above two, you should explicitly
> -specify a guid for the FMP driver.
> -
>  .SH "OPTIONS"
> +
>  .TP
>  .BI "-g\fR,\fB --guid " guid-string
>  Specify guid for image blob type. The format is:
>  ----
>
>  The first three elements are in little endian, while the rest
> -is in big endian.
> +is in big endian. The option must be specified for all non empty and
> +image acceptance capsules
>
>  .TP
>  .BI "-i\fR,\fB --index " index
> @@ -57,6 +60,18 @@ Specify an image index
>  .BI "-I\fR,\fB --instance " instance
>  Specify a hardware instance
>
> +.PP
> +For generation of firmware accept empty capsule
> +.BR --guid
> +is mandatory
> +.TP
> +.BI "-A\fR,\fB --fw-accept "
> +Generate a firmware acceptance empty capsule
> +
> +.TP
> +.BI "-R\fR,\fB --fw-revert "
> +Generate a firmware revert empty capsule
> +
>  .TP
>  .BR -h ", " --help
>  Print a help message
> diff --git a/tools/eficapsule.h b/tools/eficapsule.h
> index d63b831443..072a4b5598 100644
> --- a/tools/eficapsule.h
> +++ b/tools/eficapsule.h
> @@ -41,6 +41,14 @@ typedef struct {
> EFI_GUID(0x4aafd29d, 0x68df, 0x49ee, 0x8a, 0xa9, \
>  0x34, 0x7d, 0x37, 0x56, 0x65, 0xa7)
>
> +#define FW_ACCEPT_OS_GUID \
> +   EFI_GUID(0x0c996046, 0xbcc0, 0x4d04, 0x85, 0xec, \
> +0xe1, 0xfc, 0xed, 0xf1, 0xc6, 0xf8)
> +
> +#define FW_REVERT_OS_GUID \
> +   EFI_GUID(0xacd58b4b, 0xc0e8, 0x475f, 0x99, 0xb5, \
> +0x6b, 0x3f, 0x7e, 0x07, 0xaa, 0xf0)
> +
>  /* flags */
>  #define CAPSULE_FLAGS_PERSIST_ACROSS_RESET  0x0001
>
> diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
> index 5f74d23b9e..e8eb6b070d 100644
> --- a/tools/mkeficapsule.c
> +++ b/tools/mkeficapsule.c
> @@ -29,7 +29,16 @@ static const char *tool_name = "mkeficapsule";
>  efi_guid_t efi_guid_fm_capsule = EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
>  efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
>
> -static const char *opts_short = "g:i:I:v:p:c:m:dh";
> +static const char *opts_short = "g:i:I:v:p:c:m:dhAR";
> +
> +static bool empty_capsule;
> +static unsigned char capsule;

Local function create_fwbin() defines a local variable with that same label.
Should be ok to remove this 'capsule' variable if only using
'capsule_type' as suggested by Takahiro-san.


> +
> +enum {
> +   CAPSULE_NORMAL_BLOB = 0,
> +   CAPSULE_ACCEPT,
> +   CAPSULE_REVERT,
> +} capsule_type;
>
>  static struct option options[] = {
> {"guid", required_argument, NULL, 'g'},
> @@ -39,24 +48,47 @@ static struct option options[] = {
> {"certificate", required_argument, NULL, 'c'},
> {"monotonic-count", required_argument, NULL, 'm'},
> {"dump-sig", no_argument, NULL, 'd'},
> +   {"fw-accept", no_argument, NULL, 'A'},
> +   {"fw-revert", no_argument, NULL, 'R'},
> {"help", no_argument, NULL, 'h'},
> {NULL, 0, NULL, 0},
>  };
>
>  static void print_usage(void)
>  {
> -   fprintf(stderr, "Usage: %s [options]  \n"
> -   "Options:\n"
> -
> -

Re: [PATCH v5 15/23] tools: Add mkfwumdata tool for FWU metadata image

2022-06-21 Thread Etienne Carriere
On Thu, 9 Jun 2022 at 14:31, Sughosh Ganu  wrote:
>
> From: Masami Hiramatsu 
>
> Add 'mkfwumdata' tool which can generate an image of the FWU metadata
> which is required for initializing the platform.
>
> Usage:
>   mkfwumdata -i NR_IMAGES -b NR_BANKS [--guid] \
> LOCATION_UUID0,IMAGE_TYPE_UUID0,BANK0_IMAGE_UUID[,BANK1_IMAGE_UUID[,...]] 
> \
> LOCATION_UUID1,... \
> IMAGE_FILE
>
> '-i' takes the number of images and '-b' takes the number of
> banks. This takes lists of uuids for the images on arguments,
> and the last argument must be the output image file name.
>
> '--guid' (or '-g' in short) allows user to specify the location UUID
> and image IDs in GUID instead of UUID. This option is useful if the
> platform uses GPT partiotion. In this case, the UUID list
> (for an image) becomes;
>
> DiskGUID,ParitionTypeGUID,UniquePartitionGUID,...
>
> Signed-off-by: Masami Hiramatsu 
> Signed-off-by: Sughosh Ganu 
> ---
>  tools/Kconfig  |   9 ++
>  tools/Makefile |   4 +
>  tools/mkfwumdata.c | 298 +
>  3 files changed, 311 insertions(+)
>  create mode 100644 tools/mkfwumdata.c
>
> diff --git a/tools/Kconfig b/tools/Kconfig
> index 117c921da3..3484be99d0 100644
> --- a/tools/Kconfig
> +++ b/tools/Kconfig
> @@ -98,4 +98,13 @@ config TOOLS_MKEFICAPSULE
>   optionally sign that file. If you want to enable UEFI capsule
>   update feature on your target, you certainly need this.
>
> +config TOOLS_MKFWUMDATA
> +   bool "Build mkfwumdata command"
> +   default y if FWU_MULTI_BANK_UPDATE
> +   help
> + This command allows users to create a raw image of the FWU
> + metadata for initial installation of the FWU multi bank
> + update on the board. The installation method depends on
> + the platform.
> +
>  endmenu
> diff --git a/tools/Makefile b/tools/Makefile
> index 9f2339666a..cd39e5ff6f 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -245,6 +245,10 @@ HOSTCFLAGS_asn1_compiler.o = -idirafter 
> $(srctree)/include
>  HOSTLDLIBS_mkeficapsule += -lgnutls -luuid
>  hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
>
> +mkfwumdata-objs := mkfwumdata.o lib/crc32.o
> +HOSTLDLIBS_mkfwumdata += -luuid
> +hostprogs-$(CONFIG_TOOLS_MKFWUMDATA) += mkfwumdata
> +
>  # We build some files with extra pedantic flags to try to minimize things
>  # that won't build on some weird host compiler -- though there are lots of
>  # exceptions for files that aren't complaint.
> diff --git a/tools/mkfwumdata.c b/tools/mkfwumdata.c
> new file mode 100644
> index 00..4eb304cae3
> --- /dev/null
> +++ b/tools/mkfwumdata.c
> @@ -0,0 +1,298 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* This will dynamically allocate the fwu_mdata */
> +#define CONFIG_FWU_NUM_BANKS   0
> +#define CONFIG_FWU_NUM_IMAGES_PER_BANK 0
> +
> +/* Since we can not include fwu.h, redefine version here. */
> +#define FWU_MDATA_VERSION  1
> +
> +typedef uint8_t u8;
> +typedef int16_t s16;
> +typedef uint16_t u16;
> +typedef uint32_t u32;
> +typedef uint64_t u64;
> +
> +#include 
> +
> +/* TODO: Endianess conversion may be required for some arch. */
> +
> +static const char *opts_short = "b:i:a:gh";
> +
> +static struct option options[] = {
> +   {"banks", required_argument, NULL, 'b'},
> +   {"images", required_argument, NULL, 'i'},
> +   {"guid", required_argument, NULL, 'g'},
> +   {"active-bank", required_argument, NULL, 'a'},
> +   {"help", no_argument, NULL, 'h'},
> +   {NULL, 0, NULL, 0},
> +};
> +
> +static void print_usage(void)
> +{
> +   fprintf(stderr, "Usage: mkfwumdata [options]  [ list>...] \n");
> +   fprintf(stderr, "Options:\n"
> +   "\t-i, --images   Number of images\n"
> +   "\t-b, --banksNumber of banks\n"
> +   "\t-a, --active-bank  Active bank\n"
> +   "\t-g, --guid  Use GUID instead of UUID\n"
> +   "\t-h, --help  print a help message\n"
> +   );
> +   fprintf(stderr, "UUIDs list syntax:\n"
> +   "\t,,[, uuid>]\n"
> +   "\n\tYou must specify # of banks of image-uuid and # of 
> images of the lists.\n"

It's not really explicit how many ',' occurrences are needed.
Maybe:
   In a  item, there must be as many 
occurrences as the given number of banks.
   There must be as many  items as the given number of images.

> +   "\tIf the location uuid and image uuid are '0', those are 
> filled with null uuid.\n"
> +  );
> +}
> +
> +static bool __use_guid;
> +static u32 active_bank;
> +
> +struct fwu_mdata_object {
> +   size_t images;
> +   size_t banks;
> +   size_t size;
> +   struct fwu_mdata *mdata;
> +};
> +
> +struct fwu_mdata_object *fwu_alloc_md

Re: [PATCH v5 14/23] dt/bindings: firmware: Add FWU metadata on MTD devices binding

2022-06-21 Thread Etienne Carriere
On Thu, 9 Jun 2022 at 14:31, Sughosh Ganu  wrote:
>
> From: Masami Hiramatsu 
>
> Add a devicetree-binding YAML file for the FWU metadata on MTD
> devices without GPT.
>
> Signed-off-by: Masami Hiramatsu 
> Signed-off-by: Sughosh Ganu 
> ---
>  .../firmware/uboot,fwu-mdata-mtd.yaml | 38 +++
>  1 file changed, 38 insertions(+)
>  create mode 100644 doc/device-tree-bindings/firmware/uboot,fwu-mdata-mtd.yaml
>
> diff --git a/doc/device-tree-bindings/firmware/uboot,fwu-mdata-mtd.yaml 
> b/doc/device-tree-bindings/firmware/uboot,fwu-mdata-mtd.yaml
> new file mode 100644
> index 00..4f5404f999
> --- /dev/null
> +++ b/doc/device-tree-bindings/firmware/uboot,fwu-mdata-mtd.yaml
> @@ -0,0 +1,38 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/u-boot,fwu-mdata-sf.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: FWU metadata on MTD device without GPT
> +
> +maintainers:
> + - Masami Hiramatsu 
> +
> +properties:
> +  compatible:
> +items:
> +  - const: u-boot,fwu-mdata-mtd
> +
> +  fwu-mdata-store:
> +maxItems: 1
> +description: Phandle of the MTD device which contains the FWU medatata.
> +
> +  mdata-offsets:
> +minItems: 2
> +description: Offsets of the primary and secondary FWU metadata in the 
> NOR flash.
> +
> +required:
> +  - compatible
> +  - fwu-mdata-store
> +  - mdata-offsets
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +fwu-mdata {
> +compatible = "u-boot,fwu-mdata-mtd";
> +fwu-mdata-store = <&spi-flash>;
> +mdata-offsets = <0x50 0x53>;

Is a single 32bit value sufficient to define a block offset in an MTD
device? I was thinking of NAND with a density > 4GByte.

> +};

> --
> 2.25.1
>


Re: [PATCH v5 13/23] FWU: Add FWU metadata access driver for non-GPT MTD devices

2022-06-21 Thread Etienne Carriere
On Thu, 9 Jun 2022 at 14:31, Sughosh Ganu  wrote:
>
> From: Masami Hiramatsu 
>
> For the platform which doesn't have GPT partitions for the firmware
> but on MTD devices, the FWU metadata is stored on MTD device as raw
> image at specific offset. This driver gives the access methods
> for the FWU metadata information on such MTD devices.
>
> Signed-off-by: Masami Hiramatsu 
> Signed-off-by: Sughosh Ganu 
> ---
>  drivers/fwu-mdata/Kconfig |   8 +
>  drivers/fwu-mdata/Makefile|   1 +
>  drivers/fwu-mdata/fwu_mdata_mtd.c | 308 ++
>  3 files changed, 317 insertions(+)
>  create mode 100644 drivers/fwu-mdata/fwu_mdata_mtd.c
>
> diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig
> index d5edef19d6..a8fa9ad783 100644
> --- a/drivers/fwu-mdata/Kconfig
> +++ b/drivers/fwu-mdata/Kconfig
> @@ -14,3 +14,11 @@ config FWU_MDATA_GPT_BLK
> help
>   Enable support for accessing FWU Metadata on GPT partitioned
>   block devices.
> +
> +config FWU_MDATA_MTD
> +   bool "FWU Metadata access for non-GPT MTD devices"
> +   depends on DM_FWU_MDATA && MTD
> +   help
> + Enable support for accessing FWU Metadata on non-partitioned
> + (or non-GPT partitioned, e.g. partition nodes in devicetree)
> + MTD devices.
> diff --git a/drivers/fwu-mdata/Makefile b/drivers/fwu-mdata/Makefile
> index 12a5b4fe04..c574c59be2 100644
> --- a/drivers/fwu-mdata/Makefile
> +++ b/drivers/fwu-mdata/Makefile
> @@ -5,3 +5,4 @@
>
>  obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata-uclass.o
>  obj-$(CONFIG_FWU_MDATA_GPT_BLK) += fwu_mdata_gpt_blk.o
> +obj-$(CONFIG_FWU_MDATA_MTD) += fwu_mdata_mtd.o
> diff --git a/drivers/fwu-mdata/fwu_mdata_mtd.c 
> b/drivers/fwu-mdata/fwu_mdata_mtd.c
> new file mode 100644
> index 00..9eb471e73e
> --- /dev/null
> +++ b/drivers/fwu-mdata/fwu_mdata_mtd.c
> @@ -0,0 +1,308 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2022, Linaro Limited
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +struct fwu_mdata_mtd_priv {
> +   struct mtd_info *mtd;
> +   u32 pri_offset;
> +   u32 sec_offset;
> +};

Add an inline description of the fields.

> +
> +enum fwu_mtd_op {
> +   FWU_MTD_READ,
> +   FWU_MTD_WRITE,
> +};
> +
> +static bool mtd_is_aligned_with_block_size(struct mtd_info *mtd, u64 size)
> +{
> +   return !do_div(size, mtd->erasesize);
> +}
> +
> +static int mtd_io_data(struct mtd_info *mtd, u32 offs, u32 size, void *data,
> +  enum fwu_mtd_op op)
> +{
> +   struct mtd_oob_ops io_op ={};
> +   u64 lock_offs, lock_len;
> +   size_t len;
> +   void *buf;
> +   int ret;
> +
> +   if (!mtd_is_aligned_with_block_size(mtd, offs))
> +   return -EINVAL;
> +   lock_offs = offs;
> +   lock_len = round_up(size, mtd->erasesize);
> +
> +   ret = mtd_unlock(mtd, lock_offs, lock_len);
> +   if (ret && ret != -EOPNOTSUPP)
> +   return ret;
> +
> +   if (op == FWU_MTD_WRITE) {
> +   struct erase_info erase_op = {};
> +
> +   /* This will expand erase size to align with the block size */
> +   erase_op.mtd = mtd;
> +   erase_op.addr = lock_offs;
> +   erase_op.len = lock_len;
> +   erase_op.scrub = 0;
> +
> +   ret = mtd_erase(mtd, &erase_op);
> +   if (ret)
> +   goto lock_out;
> +   }
> +
> +   /* Also, expand the write size to align with the write size */
> +   len = round_up(size, mtd->writesize);
> +
> +   buf = memalign(ARCH_DMA_MINALIGN, len);
> +   if (!buf) {
> +   ret = -ENOMEM;
> +   goto lock_out;
> +   }
> +   io_op.mode = MTD_OPS_AUTO_OOB;
> +   io_op.len = len;
> +   io_op.ooblen = 0;
> +   io_op.datbuf = buf;
> +   io_op.oobbuf = NULL;
> +
> +   if (op == FWU_MTD_WRITE) {
> +   memcpy(buf, data, size);
> +   ret = mtd_write_oob(mtd, offs, &io_op);
> +   } else {
> +   ret = mtd_read_oob(mtd, offs, &io_op);
> +   if (!ret)
> +   memcpy(data, buf, size);
> +   }
> +   free(buf);
> +
> +lock_out:
> +   mtd_lock(mtd, lock_offs, lock_len);
> +
> +   return ret;
> +}
> +
> +static int fwu_mtd_load_mdata(struct mtd_info *mtd, struct fwu_mdata **mdata,
> + u32 offs, bool primary)
> +{
> +   size_t size = sizeof(struct fwu_mdata);
> +   int ret;
> +
> +   *mdata = malloc(size);
> +   if (!*mdata)
> +   return -ENOMEM;
> +
> +   ret = mtd_io_data(mtd, offs, size, (void *)*mdata, FWU_MTD_READ);
> +   if (ret >= 0) {
> +   ret = fwu_verify_mdata(*mdata, primary);
> +   if (ret < 0) {
> +   free(*mdata);

Re: [PATCH v5 09/23] FWU: Add support for the FWU Multi Bank Update feature

2022-06-21 Thread Etienne Carriere
On Thu, 9 Jun 2022 at 14:31, Sughosh Ganu  wrote:
>
> The FWU Multi Bank Update feature supports updation of firmware images
> to one of multiple sets(also called banks) of images. The firmware
> images are clubbed together in banks, with the system booting images
> from the active bank. Information on the images such as which bank
> they belong to is stored as part of the metadata structure, which is
> stored on the same storage media as the firmware images on a dedicated
> partition.
>
> At the time of update, the metadata is read to identify the bank to
> which the images need to be flashed(update bank). On a successful
> update, the metadata is modified to set the updated bank as active
> bank to subsequently boot from.
>
> Signed-off-by: Sughosh Ganu 
> ---
>  include/fwu.h|  12 +-
>  lib/Kconfig  |   6 +
>  lib/Makefile |   1 +
>  lib/efi_loader/efi_capsule.c | 231 ++-
>  lib/efi_loader/efi_setup.c   |   3 +-
>  lib/fwu_updates/Kconfig  |  31 +
>  lib/fwu_updates/Makefile |   6 +
>  lib/fwu_updates/fwu.c|  26 
>  8 files changed, 309 insertions(+), 7 deletions(-)
>  create mode 100644 lib/fwu_updates/Kconfig
>  create mode 100644 lib/fwu_updates/Makefile
>
> diff --git a/include/fwu.h b/include/fwu.h
> index 8fbd91b463..9c8012407b 100644
> --- a/include/fwu.h
> +++ b/include/fwu.h
> @@ -28,13 +28,23 @@ struct fwu_mdata_ops {
>  };
>
>  #define FWU_MDATA_VERSION  0x1
> +#define FWU_IMAGE_ACCEPTED 0x1
>
>  #define FWU_MDATA_GUID \
> EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \
>  0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23)
>
> -int fwu_boottime_checks(void);
> +#define FWU_OS_REQUEST_FW_REVERT_GUID \
> +   EFI_GUID(0xacd58b4b, 0xc0e8, 0x475f, 0x99, 0xb5, \
> +0x6b, 0x3f, 0x7e, 0x07, 0xaa, 0xf0)
> +
> +#define FWU_OS_REQUEST_FW_ACCEPT_GUID \
> +   EFI_GUID(0x0c996046, 0xbcc0, 0x4d04, 0x85, 0xec, \
> +0xe1, 0xfc, 0xed, 0xf1, 0xc6, 0xf8)
> +
>  u8 fwu_update_checks_pass(void);
> +int fwu_boottime_checks(void);
> +int fwu_trial_state_ctr_start(void);
>
>  int fwu_get_mdata(struct fwu_mdata **mdata);
>  int fwu_update_mdata(struct fwu_mdata *mdata);
> diff --git a/lib/Kconfig b/lib/Kconfig
> index acc0ac081a..4ca6ea226b 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -966,3 +966,9 @@ config PHANDLE_CHECK_SEQ
>   phandles in fdtdec_get_alias_seq() function.
>
>  endmenu
> +
> +menu "FWU Multi Bank Updates"
> +
> +source lib/fwu_updates/Kconfig
> +
> +endmenu
> diff --git a/lib/Makefile b/lib/Makefile
> index d9b1811f75..0cf8527c2d 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_EFI) += efi/
>  obj-$(CONFIG_EFI_LOADER) += efi_driver/
>  obj-$(CONFIG_EFI_LOADER) += efi_loader/
>  obj-$(CONFIG_CMD_BOOTEFI_SELFTEST) += efi_selftest/
> +obj-$(CONFIG_FWU_MULTI_BANK_UPDATE) += fwu_updates/
>  obj-$(CONFIG_LZMA) += lzma/
>  obj-$(CONFIG_BZIP2) += bzip2/
>  obj-$(CONFIG_TIZEN) += tizen/
> diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> index c76a5f3570..8ca041e6a2 100644
> --- a/lib/efi_loader/efi_capsule.c
> +++ b/lib/efi_loader/efi_capsule.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -32,6 +33,17 @@ static const efi_guid_t 
> efi_guid_firmware_management_capsule_id =
> EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
>  const efi_guid_t efi_guid_firmware_management_protocol =
> EFI_FIRMWARE_MANAGEMENT_PROTOCOL_GUID;
> +const efi_guid_t fwu_guid_os_request_fw_revert =
> +   FWU_OS_REQUEST_FW_REVERT_GUID;
> +const efi_guid_t fwu_guid_os_request_fw_accept =
> +   FWU_OS_REQUEST_FW_ACCEPT_GUID;
> +
> +#define FW_ACCEPT_OS   (u32)0x8000
> +
> +__maybe_unused static u32 update_index;
> +__maybe_unused static bool capsule_update;
> +__maybe_unused static bool fw_accept_os;
> +static bool image_index_check = true;
>
>  #ifdef CONFIG_EFI_CAPSULE_ON_DISK
>  /* for file system access */
> @@ -205,7 +217,8 @@ efi_fmp_find(efi_guid_t *image_type, u8 image_index, u64 
> instance,
> log_debug("+++ desc[%d] index: %d, name: %ls\n",
>   j, desc->image_index, desc->image_id_name);
> if (!guidcmp(&desc->image_type_id, image_type) &&
> -   (desc->image_index == image_index) &&
> +   (!image_index_check ||
> +desc->image_index == image_index) &&
> (!instance ||
>  !desc->hardware_instance ||
>   desc->hardware_instance == instance))
> @@ -388,6 +401,87 @@ efi_status_t efi_capsule_authenticate(const void 
> *capsule, efi_uintn_t capsule_s
>  }
>  #endif /* CONFIG_EFI_CAPSULE_AUTHENTICATE */
>
> +static bool fwu_empty_capsule(struct efi_capsul

Re: [PATCH v5 08/23] FWU: Add boot time checks as highlighted by the FWU specification

2022-06-21 Thread Etienne Carriere
Hi Sughosh,

On Thu, 9 Jun 2022 at 14:31, Sughosh Ganu  wrote:
>
> The FWU Multi Bank Update specification requires the Update Agent to
> carry out certain checks at the time of platform boot. The Update
> Agent is the component which is responsible for updating the firmware
> components and maintaining and keeping the metadata in sync.
>
> The spec requires that the Update Agent perform the following checks
> at the time of boot
> * Sanity check of both the metadata copies maintained by the platform.
> * Get the boot index passed to U-Boot by the prior stage bootloader
>   and use this value for metadata bookkeeping.
> * Check if the system is booting in Trial State. If the system boots
>   in the Trial State for more than a specified number of boot counts,
>   change the Active Bank to be booting the platform from.
>
> Add these checks in the board initialisation sequence, invoked after
> relocation.
>
> Signed-off-by: Sughosh Ganu 
> ---
>  common/board_r.c  |   5 ++
>  include/fwu.h |   3 +
>  lib/fwu_updates/fwu.c | 170 ++
>  3 files changed, 178 insertions(+)
>  create mode 100644 lib/fwu_updates/fwu.c
>
> diff --git a/common/board_r.c b/common/board_r.c
> index 6f4aca2077..33a600715d 100644
> --- a/common/board_r.c
> +++ b/common/board_r.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -797,6 +798,10 @@ static init_fnc_t init_sequence_r[] = {
>  #if defined(CONFIG_PRAM)
> initr_mem,
>  #endif
> +
> +#ifdef CONFIG_FWU_MULTI_BANK_UPDATE
> +   fwu_boottime_checks,
> +#endif
> run_main_loop,
>  };
>
> diff --git a/include/fwu.h b/include/fwu.h
> index 41774ff9e2..8fbd91b463 100644
> --- a/include/fwu.h
> +++ b/include/fwu.h
> @@ -33,6 +33,9 @@ struct fwu_mdata_ops {
> EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \
>  0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23)
>
> +int fwu_boottime_checks(void);
> +u8 fwu_update_checks_pass(void);
> +
>  int fwu_get_mdata(struct fwu_mdata **mdata);
>  int fwu_update_mdata(struct fwu_mdata *mdata);
>  int fwu_get_active_index(u32 *active_idx);
> diff --git a/lib/fwu_updates/fwu.c b/lib/fwu_updates/fwu.c
> new file mode 100644
> index 00..af884439fb
> --- /dev/null
> +++ b/lib/fwu_updates/fwu.c
> @@ -0,0 +1,170 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2022, Linaro Limited
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +static u8 trial_state;
> +static u8 boottime_check;
> +
> +static int fwu_trial_state_check(void)
> +{
> +   int ret, i;
> +   efi_status_t status;
> +   efi_uintn_t var_size;
> +   u16 trial_state_ctr;
> +   u32 nimages, active_bank, var_attributes, active_idx;
> +   struct fwu_mdata *mdata = NULL;
> +   struct fwu_image_entry *img_entry;
> +   struct fwu_image_bank_info *img_bank_info;
> +
> +   ret = fwu_get_mdata(&mdata);
> +   if (ret)
> +   return ret;
> +
> +   ret = 0;
> +   nimages = CONFIG_FWU_NUM_IMAGES_PER_BANK;
> +   active_bank = mdata->active_index;
> +   img_entry = &mdata->img_entry[0];
> +   for (i = 0; i < nimages; i++) {
> +   img_bank_info = &img_entry[i].img_bank_info[active_bank];
> +   if (!img_bank_info->accepted) {
> +   trial_state = 1;
> +   break;
> +   }
> +   }
> +
> +   if (trial_state) {
> +   var_size = (efi_uintn_t)sizeof(trial_state_ctr);
> +   log_info("System booting in Trial State\n");
> +   var_attributes = EFI_VARIABLE_NON_VOLATILE |
> +   EFI_VARIABLE_BOOTSERVICE_ACCESS;
> +   status = efi_get_variable_int(L"TrialStateCtr",
> + &efi_global_variable_guid,
> + &var_attributes,
> + &var_size, &trial_state_ctr,
> + NULL);
> +   if (status != EFI_SUCCESS) {
> +   log_err("Unable to read TrialStateCtr variable\n");
> +   ret = -1;
> +   goto out;
> +   }
> +
> +   ++trial_state_ctr;
> +   if (trial_state_ctr > CONFIG_FWU_TRIAL_STATE_CNT) {
> +   log_info("Trial State count exceeded. Revert back to 
> previous_active_index\n");
> +   active_idx = mdata->active_index;
> +   ret = fwu_revert_boot_index();
> +   if (ret) {
> +   log_err("Unable to revert active_index\n");
> +   goto out;
> +   }
> +
> +   trial_state_ctr = 0;
> +   status = efi_set_vari

Re: [PATCH v5 03/23] FWU: Add FWU metadata access driver for GPT partitioned block devices

2022-06-21 Thread Etienne Carriere
Hello Sughosh,

On Thu, 9 Jun 2022 at 14:30, Sughosh Ganu  wrote:
>
> In the FWU Multi Bank Update feature, the information about the
> updatable images is stored as part of the metadata, on a separate
> partition. Add a driver for reading from and writing to the metadata
> when the updatable images and the metadata are stored on a block
> device which is formated with GPT based partition scheme.
>
> Signed-off-by: Sughosh Ganu 
> ---
>  drivers/fwu-mdata/Kconfig |   9 +
>  drivers/fwu-mdata/Makefile|   1 +
>  drivers/fwu-mdata/fwu_mdata_gpt_blk.c | 404 ++
>  include/fwu.h |   2 +
>  4 files changed, 416 insertions(+)
>  create mode 100644 drivers/fwu-mdata/fwu_mdata_gpt_blk.c
>
> diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig
> index d6a21c8e19..d5edef19d6 100644
> --- a/drivers/fwu-mdata/Kconfig
> +++ b/drivers/fwu-mdata/Kconfig
> @@ -5,3 +5,12 @@ config DM_FWU_MDATA
>   Enable support for accessing FWU Metadata partitions. The
>   FWU Metadata partitions reside on the same storage device
>   which contains the other FWU updatable firmware images.
> +
> +config FWU_MDATA_GPT_BLK
> +   bool "FWU Metadata access for GPT partitioned Block devices"
> +   select PARTITION_TYPE_GUID
> +   select PARTITION_UUIDS
> +   depends on DM && HAVE_BLOCK_DEVICE && EFI_PARTITION
> +   help
> + Enable support for accessing FWU Metadata on GPT partitioned
> + block devices.
> diff --git a/drivers/fwu-mdata/Makefile b/drivers/fwu-mdata/Makefile
> index 7fec7171f4..12a5b4fe04 100644
> --- a/drivers/fwu-mdata/Makefile
> +++ b/drivers/fwu-mdata/Makefile
> @@ -4,3 +4,4 @@
>  #
>
>  obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata-uclass.o
> +obj-$(CONFIG_FWU_MDATA_GPT_BLK) += fwu_mdata_gpt_blk.o
> diff --git a/drivers/fwu-mdata/fwu_mdata_gpt_blk.c 
> b/drivers/fwu-mdata/fwu_mdata_gpt_blk.c
> new file mode 100644
> index 00..329bd3779b
> --- /dev/null
> +++ b/drivers/fwu-mdata/fwu_mdata_gpt_blk.c
> @@ -0,0 +1,404 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2022, Linaro Limited
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define PRIMARY_PART   BIT(0)
> +#define SECONDARY_PART BIT(1)
> +#define BOTH_PARTS (PRIMARY_PART | SECONDARY_PART)
> +
> +#define MDATA_READ BIT(0)
> +#define MDATA_WRITEBIT(1)
> +
> +static int gpt_get_mdata_partitions(struct blk_desc *desc,
> +   u16 *primary_mpart,
> +   u16 *secondary_mpart)
> +{
> +   int i, ret;
> +   u32 mdata_parts;
> +   efi_guid_t part_type_guid;
> +   struct disk_partition info;
> +   const efi_guid_t fwu_mdata_guid = FWU_MDATA_GUID;
> +
> +   mdata_parts = 0;
> +   for (i = 1; i < MAX_SEARCH_PARTITIONS; i++) {
> +   if (part_get_info(desc, i, &info))
> +   continue;
> +   uuid_str_to_bin(info.type_guid, part_type_guid.b,
> +   UUID_STR_FORMAT_GUID);
> +
> +   if (!guidcmp(&fwu_mdata_guid, &part_type_guid)) {
> +   ++mdata_parts;
> +   if (!*primary_mpart)
> +   *primary_mpart = i;
> +   else
> +   *secondary_mpart = i;
> +   }
> +   }
> +
> +   if (mdata_parts != 2) {
> +   log_err("Expect two copies of the FWU metadata instead of 
> %d\n",
> +   mdata_parts);
> +   ret = -EINVAL;
> +   } else {
> +   ret = 0;
> +   }
> +
> +   return ret;
> +}
> +
> +static int gpt_get_mdata_disk_part(struct blk_desc *desc,
> +  struct disk_partition *info,
> +  u32 part_num)
> +{
> +   int ret;
> +   char *mdata_guid_str = "8a7a84a0-8387-40f6-ab41-a8b9a5a60d23";
> +
> +   ret = part_get_info(desc, part_num, info);
> +   if (ret < 0) {
> +   log_err("Unable to get the partition info for the FWU 
> metadata part %d",
> +   part_num);
> +   return -1;
> +   }
> +
> +   /* Check that it is indeed the FWU metadata partition */
> +   if (!strncmp(info->type_guid, mdata_guid_str, UUID_STR_LEN)) {
> +   /* Found the FWU metadata partition */
> +   return 0;
> +   }
> +
> +   return -1;
> +}
> +
> +static int gpt_read_write_mdata(struct blk_desc *desc,
> +   struct fwu_mdata *mdata,
> +   u8 access, u32 part_num)
> +{
> +   int ret;
> +   u32 len, blk_start, blkcnt;
> +   struct disk_partition info;
> +
> +   ALLOC_CA

Re: [PATCH v5 02/23] FWU: Add FWU metadata structure and driver for accessing metadata

2022-06-21 Thread Etienne Carriere
Hello Sughosh,



On Thu, 9 Jun 2022 at 14:30, Sughosh Ganu  wrote:
>
> In the FWU Multi Bank Update feature, the information about the
> updatable images is stored as part of the metadata, which is stored on
> a dedicated partition. Add the metadata structure, and a driver model
> uclass which provides functions to access the metadata. These are
> generic API's, and implementations can be added based on parameters
> like how the metadata partition is accessed and what type of storage
> device houses the metadata.
>
> Signed-off-by: Sughosh Ganu 
> ---
>  drivers/Kconfig  |   2 +
>  drivers/Makefile |   1 +
>  drivers/fwu-mdata/Kconfig|   7 +
>  drivers/fwu-mdata/Makefile   |   6 +
>  drivers/fwu-mdata/fwu-mdata-uclass.c | 459 +++
>  include/dm/uclass-id.h   |   1 +
>  include/fwu.h|  49 +++
>  include/fwu_mdata.h  |  67 
>  8 files changed, 592 insertions(+)
>  create mode 100644 drivers/fwu-mdata/Kconfig
>  create mode 100644 drivers/fwu-mdata/Makefile
>  create mode 100644 drivers/fwu-mdata/fwu-mdata-uclass.c
>  create mode 100644 include/fwu.h
>  create mode 100644 include/fwu_mdata.h
>
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index b26ca8cf70..adc6079ecf 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -42,6 +42,8 @@ source "drivers/firmware/Kconfig"
>
>  source "drivers/fpga/Kconfig"
>
> +source "drivers/fwu-mdata/Kconfig"
> +
>  source "drivers/gpio/Kconfig"
>
>  source "drivers/hwspinlock/Kconfig"
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 67c8af7442..901150bb35 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -83,6 +83,7 @@ obj-y += cache/
>  obj-$(CONFIG_CPU) += cpu/
>  obj-y += crypto/
>  obj-$(CONFIG_FASTBOOT) += fastboot/
> +obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata/
>  obj-y += misc/
>  obj-$(CONFIG_MMC) += mmc/
>  obj-$(CONFIG_NVME) += nvme/
> diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig
> new file mode 100644
> index 00..d6a21c8e19
> --- /dev/null
> +++ b/drivers/fwu-mdata/Kconfig
> @@ -0,0 +1,7 @@
> +config DM_FWU_MDATA
> +   bool "Driver support for accessing FWU Metadata"
> +   depends on DM
> +   help
> + Enable support for accessing FWU Metadata partitions. The
> + FWU Metadata partitions reside on the same storage device
> + which contains the other FWU updatable firmware images.
> diff --git a/drivers/fwu-mdata/Makefile b/drivers/fwu-mdata/Makefile
> new file mode 100644
> index 00..7fec7171f4
> --- /dev/null
> +++ b/drivers/fwu-mdata/Makefile
> @@ -0,0 +1,6 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (c) 2022, Linaro Limited
> +#
> +
> +obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata-uclass.o
> diff --git a/drivers/fwu-mdata/fwu-mdata-uclass.c 
> b/drivers/fwu-mdata/fwu-mdata-uclass.c
> new file mode 100644
> index 00..1530ceb01d
> --- /dev/null
> +++ b/drivers/fwu-mdata/fwu-mdata-uclass.c
> @@ -0,0 +1,459 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2022, Linaro Limited
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#define IMAGE_ACCEPT_SET   BIT(0)
> +#define IMAGE_ACCEPT_CLEAR BIT(1)
> +
> +static int fwu_get_dev_ops(struct udevice **dev,
> +  const struct fwu_mdata_ops **ops)
> +{
> +   int ret;
> +
> +   ret = uclass_get_device(UCLASS_FWU_MDATA, 0, dev);
> +   if (ret) {
> +   log_debug("Cannot find fwu device\n");
> +   return ret;
> +   }
> +
> +   if ((*ops = device_get_ops(*dev)) == NULL) {
> +   log_debug("Cannot get fwu device ops\n");
> +   return -ENOSYS;
> +   }
> +
> +   return 0;
> +}
> +
> +/**
> + * fwu_verify_mdata() - Verify the FWU metadata
> + * @mdata: FWU metadata structure
> + * @pri_part: FWU metadata partition is primary or secondary
> + *
> + * Verify the FWU metadata by computing the CRC32 for the metadata
> + * structure and comparing it against the CRC32 value stored as part
> + * of the structure.
> + *
> + * Return: 0 if OK, -ve on error
> + *
> + */
> +int fwu_verify_mdata(struct fwu_mdata *mdata, bool pri_part)
> +{
> +   u32 calc_crc32;
> +   void *buf;
> +
> +   buf = &mdata->version;
> +   calc_crc32 = crc32(0, buf, sizeof(*mdata) - sizeof(u32));
> +
> +   if (calc_crc32 != mdata->crc32) {
> +   log_err("crc32 check failed for %s FWU metadata partition\n",
> +   pri_part ? "primary" : "secondary");
> +   return -1;
> +   }
> +
> +   return 0;
> +}
> +
> +/**
> + * fwu_get_active_index() - Get active_index from the FWU metadata
> + * @active_idx: active_index value to be read
> + *
> + * Read the active_index field from the FWU metadata and place it in
> + * the variab

[PATCH 3/3] ram: rk3399: Conduct memory training at 400MHz

2022-06-21 Thread Lee Jones
Currently the default initialisation frequency is 50MHz.  Although
this does appear to be suitable for some LPDDR4 RAM chips, training at
this low frequency has been seen to cause Column errors, leading to
Capacity check errors on others.

Here we force RAM initialisation to happen at 400MHz before ramping up
to the final value running value of 800MHz after everything has been
successfully configured.

Link: https://lore.kernel.org/u-boot/yo4v3juehxtov...@google.com/
Suggested-by: YouMin Chen 
Signed-off-by: Lee Jones 
---
 drivers/ram/rockchip/sdram_rk3399.c | 36 +
 1 file changed, 21 insertions(+), 15 deletions(-)

diff --git a/drivers/ram/rockchip/sdram_rk3399.c 
b/drivers/ram/rockchip/sdram_rk3399.c
index 34d6c93f95..b05c5925d5 100644
--- a/drivers/ram/rockchip/sdram_rk3399.c
+++ b/drivers/ram/rockchip/sdram_rk3399.c
@@ -85,7 +85,7 @@ struct sdram_rk3399_ops {
int (*data_training_first)(struct dram_info *dram, u32 channel, u8 rank,
   struct rk3399_sdram_params *sdram);
int (*set_rate_index)(struct dram_info *dram,
- struct rk3399_sdram_params *params);
+ struct rk3399_sdram_params *params, u32 ctl_fn);
void (*modify_param)(const struct chan_info *chan,
 struct rk3399_sdram_params *params);
struct rk3399_sdram_params *
@@ -1644,7 +1644,8 @@ static int data_training_first(struct dram_info *dram, 
u32 channel, u8 rank,
 }
 
 static int switch_to_phy_index1(struct dram_info *dram,
-   struct rk3399_sdram_params *params)
+   struct rk3399_sdram_params *params,
+   u32 unused)
 {
u32 channel;
u32 *denali_phy;
@@ -2539,26 +2540,25 @@ static int lpddr4_set_ctl(struct dram_info *dram,
 }
 
 static int lpddr4_set_rate(struct dram_info *dram,
-  struct rk3399_sdram_params *params)
+   struct rk3399_sdram_params *params,
+   u32 ctl_fn)
 {
-   u32 ctl_fn;
u32 phy_fn;
 
-   for (ctl_fn = 0; ctl_fn < 2; ctl_fn++) {
-   phy_fn = lpddr4_get_phy_fn(params, ctl_fn);
+   phy_fn = lpddr4_get_phy_fn(params, ctl_fn);
 
-   lpddr4_set_phy(dram, params, phy_fn, &dfs_cfgs_lpddr4[ctl_fn]);
-   lpddr4_set_ctl(dram, params, ctl_fn,
-  dfs_cfgs_lpddr4[ctl_fn].base.ddr_freq);
+   lpddr4_set_phy(dram, params, phy_fn, &dfs_cfgs_lpddr4[ctl_fn]);
+   lpddr4_set_ctl(dram, params, ctl_fn,
+  dfs_cfgs_lpddr4[ctl_fn].base.ddr_freq);
 
-   if (IS_ENABLED(CONFIG_RAM_ROCKCHIP_DEBUG))
-   printf("%s: change freq to %dMHz %d, %d\n", __func__,
-  dfs_cfgs_lpddr4[ctl_fn].base.ddr_freq / MHz,
-  ctl_fn, phy_fn);
-   }
+   if (IS_ENABLED(CONFIG_RAM_ROCKCHIP_DEBUG))
+   printf("%s: change freq to %dMHz %d, %d\n", __func__,
+  dfs_cfgs_lpddr4[ctl_fn].base.ddr_freq / MHz,
+  ctl_fn, phy_fn);
 
return 0;
 }
+
 #endif /* CONFIG_RAM_RK3399_LPDDR4 */
 
 /* CS0,n=1
@@ -2955,6 +2955,12 @@ static int sdram_init(struct dram_info *dram,
params->ch[ch].cap_info.rank = rank;
}
 
+#if defined(CONFIG_RAM_RK3399_LPDDR4)
+   /* LPDDR4 needs to be trained at 400MHz */
+   lpddr4_set_rate(dram, params, 0);
+   params->base.ddr_freq = dfs_cfgs_lpddr4[0].base.ddr_freq / MHz;
+#endif
+
params->base.num_channels = 0;
for (channel = 0; channel < 2; channel++) {
const struct chan_info *chan = &dram->chan[channel];
@@ -3005,7 +3011,7 @@ static int sdram_init(struct dram_info *dram,
params->base.stride = calculate_stride(params);
dram_all_config(dram, params);
 
-   ret = dram->ops->set_rate_index(dram, params);
+   ret = dram->ops->set_rate_index(dram, params, 1);
if (ret)
return ret;
 
-- 
2.37.0.rc0.104.g0611611a94-goog



[PATCH 2/3] ram: rk3399: Fix faulty frequency change reports

2022-06-21 Thread Lee Jones
Frequency changes to 400MHz are presently reported as:

  lpddr4_set_rate_0: change freq to 4 mhz 0, 1

This is obviously wrong by 6 orders of magnitude.

Ensure frequency changes are reported accurately.

Signed-off-by: Lee Jones 
---
 drivers/ram/rockchip/sdram_rk3399.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/ram/rockchip/sdram_rk3399.c 
b/drivers/ram/rockchip/sdram_rk3399.c
index 0af0fa9e7b..34d6c93f95 100644
--- a/drivers/ram/rockchip/sdram_rk3399.c
+++ b/drivers/ram/rockchip/sdram_rk3399.c
@@ -2552,8 +2552,8 @@ static int lpddr4_set_rate(struct dram_info *dram,
   dfs_cfgs_lpddr4[ctl_fn].base.ddr_freq);
 
if (IS_ENABLED(CONFIG_RAM_ROCKCHIP_DEBUG))
-   printf("%s: change freq to %d mhz %d, %d\n", __func__,
-  dfs_cfgs_lpddr4[ctl_fn].base.ddr_freq,
+   printf("%s: change freq to %dMHz %d, %d\n", __func__,
+  dfs_cfgs_lpddr4[ctl_fn].base.ddr_freq / MHz,
   ctl_fn, phy_fn);
}
 
-- 
2.37.0.rc0.104.g0611611a94-goog



[PATCH 1/3] ram: rk3399: Fix .set_rate_index() error handling

2022-06-21 Thread Lee Jones
Functions pointed to by this op pointer can return non-zero values
indicating an error.  Ensure any error value is propagated back up the
call-chain.

Signed-off-by: Lee Jones 
---
 drivers/ram/rockchip/sdram_rk3399.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/ram/rockchip/sdram_rk3399.c 
b/drivers/ram/rockchip/sdram_rk3399.c
index c0a06dcaed..0af0fa9e7b 100644
--- a/drivers/ram/rockchip/sdram_rk3399.c
+++ b/drivers/ram/rockchip/sdram_rk3399.c
@@ -3005,7 +3005,9 @@ static int sdram_init(struct dram_info *dram,
params->base.stride = calculate_stride(params);
dram_all_config(dram, params);
 
-   dram->ops->set_rate_index(dram, params);
+   ret = dram->ops->set_rate_index(dram, params);
+   if (ret)
+   return ret;
 
debug("Finish SDRAM initialization...\n");
return 0;
-- 
2.37.0.rc0.104.g0611611a94-goog



Re: [PATCH v5 06/23] FWU: stm32mp1: Add helper functions for accessing FWU metadata

2022-06-21 Thread Patrick DELAUNAY

Hi,

On 6/9/22 14:29, Sughosh Ganu wrote:

Add helper functions needed for accessing the FWU metadata which
contains information on the updatable images. These functions have
been added for the STM32MP157C-DK2 board which has the updatable
images on the uSD card, formatted as GPT partitions.

Signed-off-by: Sughosh Ganu 
---
  board/st/stm32mp1/stm32mp1.c | 115 +++
  include/fwu.h|   2 +
  2 files changed, 117 insertions(+)

diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 62d98ad776..e68bf09955 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -7,9 +7,11 @@
  
  #include 

  #include 
+#include 
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -25,9 +27,11 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -967,3 +971,114 @@ static void board_copro_image_process(ulong fw_image, 
size_t fw_size)
  }
  
  U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_COPRO, board_copro_image_process);

+
+#if defined(CONFIG_FWU_MULTI_BANK_UPDATE)
+#include 
+#include 
+

[...]

+
+#endif /* CONFIG_FWU_MULTI_BANK_UPDATE */
diff --git a/include/fwu.h b/include/fwu.h
index 3b1ee4e83e..36e58afa29 100644
--- a/include/fwu.h
+++ b/include/fwu.h
@@ -46,6 +46,8 @@ int fwu_revert_boot_index(void);
  int fwu_accept_image(efi_guid_t *img_type_id, u32 bank);
  int fwu_clear_accept_image(efi_guid_t *img_type_id, u32 bank);
  
+



Added empty line



  int fwu_plat_get_alt_num(struct udevice *dev, efi_guid_t *image_guid,
 int *alt_num);
+int fwu_plat_get_update_index(u32 *update_idx);
  #endif /* _FWU_H_ */



And I am agree with Ilias remark, should be generic

=> search on the current UCLASS_FWU_MDATA

   perhaps need a new ops in u-class ? as implementation can be 
different for GPT and MTD.



Patrick



Re: [PATCH v5 04/23] stm32mp1: dk2: Add a node for the FWU metadata device

2022-06-21 Thread Patrick DELAUNAY

Hi,

On 6/9/22 14:29, Sughosh Ganu wrote:

The FWU metadata structure is accessed through the driver model
interface. On the stm32mp157c-dk2 board, the FWU metadata is stored on
the uSD card. Add the fwu-mdata node on the u-boot specifc dtsi file
for accessing the metadata structure.

Signed-off-by: Sughosh Ganu 
---
  arch/arm/dts/stm32mp157c-dk2-u-boot.dtsi | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm/dts/stm32mp157c-dk2-u-boot.dtsi 
b/arch/arm/dts/stm32mp157c-dk2-u-boot.dtsi
index 06ef3a4095..24f86209db 100644
--- a/arch/arm/dts/stm32mp157c-dk2-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-dk2-u-boot.dtsi
@@ -4,3 +4,10 @@
   */
  
  #include "stm32mp157a-dk1-u-boot.dtsi"

+
+/ {
+   fwu-mdata {
+   compatible = "u-boot,fwu-mdata-gpt";
+   fwu-mdata-store = <&sdmmc1>;
+   };
+};



Reviewed-by: Patrick Delaunay 

Thanks
Patrick



Re: [PATCH v5 03/23] FWU: Add FWU metadata access driver for GPT partitioned block devices

2022-06-21 Thread Patrick DELAUNAY

Hi,

On 6/9/22 14:29, Sughosh Ganu wrote:

In the FWU Multi Bank Update feature, the information about the
updatable images is stored as part of the metadata, on a separate
partition. Add a driver for reading from and writing to the metadata
when the updatable images and the metadata are stored on a block
device which is formated with GPT based partition scheme.

Signed-off-by: Sughosh Ganu 
---
  drivers/fwu-mdata/Kconfig |   9 +
  drivers/fwu-mdata/Makefile|   1 +
  drivers/fwu-mdata/fwu_mdata_gpt_blk.c | 404 ++
  include/fwu.h |   2 +
  4 files changed, 416 insertions(+)
  create mode 100644 drivers/fwu-mdata/fwu_mdata_gpt_blk.c

diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig
index d6a21c8e19..d5edef19d6 100644
--- a/drivers/fwu-mdata/Kconfig
+++ b/drivers/fwu-mdata/Kconfig
@@ -5,3 +5,12 @@ config DM_FWU_MDATA
  Enable support for accessing FWU Metadata partitions. The
  FWU Metadata partitions reside on the same storage device
  which contains the other FWU updatable firmware images.
+
+config FWU_MDATA_GPT_BLK
+   bool "FWU Metadata access for GPT partitioned Block devices"
+   select PARTITION_TYPE_GUID
+   select PARTITION_UUIDS
+   depends on DM && HAVE_BLOCK_DEVICE && EFI_PARTITION
+   help
+ Enable support for accessing FWU Metadata on GPT partitioned
+ block devices.
diff --git a/drivers/fwu-mdata/Makefile b/drivers/fwu-mdata/Makefile
index 7fec7171f4..12a5b4fe04 100644
--- a/drivers/fwu-mdata/Makefile
+++ b/drivers/fwu-mdata/Makefile
@@ -4,3 +4,4 @@
  #
  
  obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata-uclass.o

+obj-$(CONFIG_FWU_MDATA_GPT_BLK) += fwu_mdata_gpt_blk.o



It is strange to have '_' and '-' in file name for the same directory

=> to be coherent = fwu-mdata-gpt-blk.c



diff --git a/drivers/fwu-mdata/fwu_mdata_gpt_blk.c 
b/drivers/fwu-mdata/fwu_mdata_gpt_blk.c
new file mode 100644
index 00..329bd3779b
--- /dev/null
+++ b/drivers/fwu-mdata/fwu_mdata_gpt_blk.c
@@ -0,0 +1,404 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2022, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define PRIMARY_PART   BIT(0)
+#define SECONDARY_PART BIT(1)
+#define BOTH_PARTS (PRIMARY_PART | SECONDARY_PART)
+
+#define MDATA_READ BIT(0)
+#define MDATA_WRITEBIT(1)
+
+



[...]


+
+int fwu_gpt_mdata_check(struct udevice *dev)
+{
+   /*
+* Check if both the copies of the FWU metadata are
+* valid. If one has gone bad, restore it from the
+* other good copy.
+*/
+   return gpt_check_mdata_validity(dev);
+}
+
+int fwu_gpt_get_mdata(struct udevice *dev, struct fwu_mdata **mdata)
+{
+   struct blk_desc *desc;
+
+   desc = dev_get_uclass_plat(dev_get_priv(dev));


as dev = fwu_mdata_gpt_blk(UCLASS_FWU_MDATA)

dev_get_priv(dev) => get value saved in dev_set_priv(dev, mdata_dev);

even if it is OK, it not clear here.

can you add a struct to prepare addition of other elements in privdata:

struct fwu_mdata_gpt_blk_priv {
struct udevice *blk_dev;
}


+ struct fwu_mdata_gpt_blk_priv *priv = dev_get_priv(dev);

+ struct blk_desc *desc;

+ desc = dev_get_uclass_plat(priv->blk_dev);



+   if (!desc) {
+   log_err("Block device not found\n");
+   return -ENODEV;
+   }
+
+   return gpt_get_mdata(desc, mdata);
+}
+
+int fwu_get_mdata_device(struct udevice *dev, struct udevice **mdata_dev)
+{
+   u32 phandle;
+   int ret, size;
+   struct udevice *parent, *child;
+   const fdt32_t *phandle_p = NULL;
+
+   phandle_p = ofnode_get_property(dev_ofnode(dev), "fwu-mdata-store",
+   &size);


phandle_p = dev_read_prop(dev, "fwu-mdata-store", &size);


it is more simple



+   if (!phandle_p) {
+   log_err("fwu-mdata-store property not found\n");
+   return -ENOENT;
+   }
+
+   phandle = fdt32_to_cpu(*phandle_p);



or phandle can be read directly by

+ ret =dev_read_phandle_with_args(dev, "fwu-mdata-store", NULL, 0, 0, 
phandle_p)


+   if (ret) {
+   log_err("fwu-mdata-store property not found\n");
+   return ret;
+   }


+
+   ret = device_get_global_by_ofnode(ofnode_get_by_phandle(phandle),
+ &parent);
+   if (ret)
+   return ret;
+
+   ret = -ENODEV;
+   for (device_find_first_child(parent, &child); child;
+device_find_next_child(&child)) {
+   if (device_get_uclass_id(child) == UCLASS_BLK) {
+   *mdata_dev = child;
+   ret = 0;
+   }
+   }
+
+   return ret;
+}
+
+static int fwu_mdata_gpt_blk_probe(struct udevice *de

Re: [PATCH v5 00/23] FWU: Add FWU Multi Bank Update feature support

2022-06-21 Thread Sughosh Ganu
hi,

On Mon, 20 Jun 2022 at 23:42, Patrick DELAUNAY
 wrote:
>
> Hi,
>
> On 6/9/22 14:29, Sughosh Ganu wrote:
> > The patchset adds support for the FWU Multi Bank Update[1]
> > feature. Certain aspects of the Dependable Boot[2] specification have
> > also been implemented.
> >
> > The FWU multi bank update feature is used for supporting multiple
> > sets(also called banks) of firmware image(s), allowing the platform to
> > boot from a different bank, in case it fails to boot from the active
> > bank. This functionality is supported by keeping the relevant
> > information in a structure called metadata, which provides information
> > on the images. Among other parameters, the metadata structure contains
> > information on the currect active bank that is being used to boot
> > image(s).
> >
> > Functionality is being added to work with the UEFI capsule driver in
> > u-boot. The metadata is read to gather information on the update bank,
> > which is the bank to which the firmware images would be flashed to. On
> > a successful completion of the update of all components, the active
> > bank field in the metadata is updated, to reflect the bank from which
> > the platform will boot on the subsequent boots.
> >
> > Currently, the feature is being enabled on the STM32MP157C-DK2 and
> > Synquacer boards. The DK2 board boots a FIP image from a uSD card
> > partitioned with the GPT partioning scheme, while the Synquacer board
> > boots a FIP image from a MTD partitioned SPI NOR flash device.
> >
> > This feature also requires changes in a previous stage of
> > bootloader, which parses the metadata and selects the bank to boot the
> > image(s) from. Support has being added in tf-a(BL2 stage) for the
> > STM32MP157C-DK2 board to boot the active bank images. These changes
> > have been merged to the upstream tf-a repository.
> >
> > Earlier, two separate patchsets were being sent. The patchset sent by
> > me was adding support for the feature, and enabling the feature on the
> > ST board. The other set of patches were being sent by Masami
> > Hiramatsu, which were enabling the feature on the Synquacer
> > platform. This patchset contains both set of patches, along with the
> > associated documentation and the python test script for testing the
> > feature.
> >
> > The upstreaming effort for this feature had been put on a temporary
> > hold to address the fixing of some issues in the capsule update code,
> > primarily using a per platform image GUID for the updatable
> > images. Now that the series has been merged, upstreaming effort for
> > the FWU update feature is being resumed. Hence, this version does not
> > have any review comments being addressed.
> >
> >
> > [1] - https://developer.arm.com/documentation/den0118/a
> > [2] - 
> > https://git.codelinaro.org/linaro/dependable-boot/mbfw/uploads/6f7ddfe3be24e18d4319e108a758d02e/mbfw.pdf
> >
> > Jassi Brar (1):
> >developerbox: synquacer: Use FIP as the updatable image
> >
> > Masami Hiramatsu (9):
> >FWU: Add FWU metadata access driver for non-GPT MTD devices
> >dt/bindings: firmware: Add FWU metadata on MTD devices binding
> >tools: Add mkfwumdata tool for FWU metadata image
> >FWU: doc: Update documentation for the FWU non-GPT MTD
> >synquacer: Update for TBBR (BL2) based new FIP layout
> >FWU: synquacer: Add FWU Multi bank update support for DeveloperBox
> >FWU: synquacer: Generate dfu_alt_info from devicetree partition
> >doc: synquacer: Add how to enable FWU Multi Bank Update
> >[TEMP]configs: synquacer: Add FWU support for DeveloperBox
> >
> > Sughosh Ganu (13):
> >dt/bindings: Add bindings for FWU Metadata storage device
> >FWU: Add FWU metadata structure and driver for accessing metadata
> >FWU: Add FWU metadata access driver for GPT partitioned block devices
> >stm32mp1: dk2: Add a node for the FWU metadata device
> >stm32mp1: dk2: Add image information for capsule updates
> >FWU: stm32mp1: Add helper functions for accessing FWU metadata
> >FWU: STM32MP1: Add support to read boot index from backup register
> >FWU: Add boot time checks as highlighted by the FWU specification
> >FWU: Add support for the FWU Multi Bank Update feature
> >FWU: cmd: Add a command to read FWU metadata
> >mkeficapsule: Add support for generating empty capsules
> >FWU: doc: Add documentation for the FWU feature
> >sandbox: fwu: Add support for testing FWU feature on sandbox
> >
> >   arch/arm/dts/stm32mp157c-dk2-u-boot.dtsi  |   7 +
> >   .../synquacer-sc2a11-developerbox-u-boot.dtsi |  40 +-
> >   arch/arm/mach-stm32mp/include/mach/stm32.h|   4 +
> >   arch/sandbox/Kconfig  |   6 +
> >   arch/sandbox/dts/test.dts |  45 +-
> >   board/sandbox/sandbox.c   |  49 ++
> >   board/socionext/developerbox/Kconfig  |  14 +
> >   board/socionext/developerbox/Makefile |   1 +
> >   board/socionext/developerbox/develope

Re: [PATCH v2] watchdog: add amlogic watchdog support

2022-06-21 Thread Neil Armstrong

Hi Stefan,

On 20/06/2022 16:55, Stefan Roese wrote:

On 13.06.22 16:00, Philippe Boos wrote:

Add support for hardware watchdog timer for Amlogic SoCs.
This driver has been heavily inspired by his Linux equivalent
(meson_gxbb_wdt.c).

Reviewed-by: Jerome Brunet 
Reviewed-by: Neil Armstrong 

Signed-off-by: Philippe Boos 



Reviewed-by: Stefan Roese 


Should I take it into my tree ?

Thanks,
Neil



Thanks,
Stefan


---

Your recommendations have been implemented. I let you check this version 2.
The reset works well when triggered by the wdt command in u-boot.

This watchdog driver has been tested on a GXL libretech-cc board and also on
a custom G12a board. I did the following test cases:
  * boot with a faulty boot command, then we reach watchdog reset successfully,
  * boot a Linux kernel with and without watchdog support, and check if it is
    working as expected.


  MAINTAINERS   |   1 +
  doc/board/amlogic/index.rst   |   2 +
  drivers/watchdog/Kconfig  |   7 ++
  drivers/watchdog/Makefile |   1 +
  drivers/watchdog/meson_gxbb_wdt.c | 136 ++
  5 files changed, 147 insertions(+)
  create mode 100644 drivers/watchdog/meson_gxbb_wdt.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 28e4d38238..ab3ef041f7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -160,6 +160,7 @@ F:    drivers/spi/meson_spifc.c
  F:    drivers/pinctrl/meson/
  F:    drivers/power/domain/meson-gx-pwrc-vpu.c
  F:    drivers/video/meson/
+F:    drivers/watchdog/meson_gxbb_wdt.c
  F:    include/configs/meson64.h
  F:    include/configs/meson64_android.h
  F:    doc/board/amlogic/
diff --git a/doc/board/amlogic/index.rst b/doc/board/amlogic/index.rst
index 9c7fadf2c0..cc2ba50889 100644
--- a/doc/board/amlogic/index.rst
+++ b/doc/board/amlogic/index.rst
@@ -73,6 +73,8 @@ This matrix concerns the actual source code version.
  
+---+---+-+--+-++-+--+
  | PCIe (+NVMe)  | *N/A* | *N/A*   | *N/A*    
| **Yes** | **Yes**    | **Yes** | **Yes**  |
  
+---+---+-+--+-++-+--+
+| Watchdog  | *N/A* | **Yes** | *N/A*    | 
*N/A*   | *N/A*  | *N/A*   | *N/A*    |
++---+---+-+--+-++-+--+
  Boot Documentation
  --
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index c3eb8a8aec..da0fa5396f 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -175,6 +175,13 @@ config WDT_MAX6370
  help
    Select this to enable max6370 watchdog timer.
+config WDT_MESON_GXBB
+    bool "Amlogic watchdog timer support"
+    depends on WDT
+    help
+  Select this to enable Meson watchdog timer,
+  which can be found on some Amlogic platforms.
+
  config WDT_MPC8xx
  bool "MPC8xx watchdog timer support"
  depends on WDT && MPC8xx
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 1f6199beca..0e2f582a5f 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_WDT_ORION) += orion_wdt.o
  obj-$(CONFIG_WDT_CDNS) += cdns_wdt.o
  obj-$(CONFIG_WDT_GPIO) += gpio_wdt.o
  obj-$(CONFIG_WDT_MAX6370) += max6370_wdt.o
+obj-$(CONFIG_WDT_MESON_GXBB) += meson_gxbb_wdt.o
  obj-$(CONFIG_WDT_MPC8xx) += mpc8xx_wdt.o
  obj-$(CONFIG_WDT_MT7620) += mt7620_wdt.o
  obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o
diff --git a/drivers/watchdog/meson_gxbb_wdt.c 
b/drivers/watchdog/meson_gxbb_wdt.c
new file mode 100644
index 00..6ab005813f
--- /dev/null
+++ b/drivers/watchdog/meson_gxbb_wdt.c
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2022 BayLibre, SAS.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GXBB_WDT_CTRL_REG    0x0
+#define GXBB_WDT_TCNT_REG    0x8
+#define GXBB_WDT_RSET_REG    0xc
+
+#define GXBB_WDT_CTRL_SYS_RESET_NOW    BIT(26)
+#define GXBB_WDT_CTRL_CLKDIV_EN    BIT(25)
+#define GXBB_WDT_CTRL_CLK_EN    BIT(24)
+#define GXBB_WDT_CTRL_EE_RESET    BIT(21)
+#define GXBB_WDT_CTRL_EN    BIT(18)
+
+#define GXBB_WDT_CTRL_DIV_MASK    GENMASK(17, 0)
+#define GXBB_WDT_TCNT_SETUP_MASK    GENMASK(15, 0)
+
+
+struct amlogic_wdt_priv {
+    void __iomem *reg_base;
+};
+
+static int amlogic_wdt_set_timeout(struct udevice *dev, u64 timeout_ms)
+{
+    struct amlogic_wdt_priv *data = dev_get_priv(dev);
+
+    if (timeout_ms > GXBB_WDT_TCNT_SETUP_MASK) {
+    dev_warn(dev, "%s: timeout_ms=%llu: maximum watchdog timeout 
exceeded\n",
+ __func__, timeout_ms);
+    timeout_ms = GXBB_WDT_TCNT_SETUP_MASK;
+

[PATCH v1] usb: host: nuvoton: Add nuvoton NPCM7xx ehci/ohci driver

2022-06-21 Thread Jim Liu
Add nuvoton BMC NPCM750 ehci/ohci driver

Signed-off-by: Jim Liu 
---
 drivers/usb/host/Kconfig |  16 +
 drivers/usb/host/Makefile|   2 +
 drivers/usb/host/ehci-npcm.c | 119 +++
 drivers/usb/host/ohci-npcm.c | 108 +++
 4 files changed, 245 insertions(+)
 create mode 100644 drivers/usb/host/ehci-npcm.c
 create mode 100644 drivers/usb/host/ohci-npcm.c

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 8f77412cc7..e2a16cb186 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -188,6 +188,14 @@ config USB_EHCI_MXS
  Enables support for the on-chip EHCI controller on i.MX23 and
  i.MX28 SoCs.
 
+config USB_EHCI_NPCM
+   bool "Support for Nuvoton NPCM on-chip EHCI USB controller"
+   depends on ARCH_NPCM
+   default n
+   ---help---
+ Enables support for the on-chip EHCI controller on
+ Nuvoton NPCM chips.
+
 config USB_EHCI_OMAP
bool "Support for OMAP3+ on-chip EHCI USB controller"
depends on ARCH_OMAP2PLUS
@@ -290,6 +298,14 @@ config USB_OHCI_DA8XX
help
  Enable support for the da850 USB controller.
 
+config USB_OHCI_NPCM
+   bool "Support for Nuvoton NPCM on-chip OHCI USB controller"
+   depends on ARCH_NPCM
+   default n
+   ---help---
+ Enables support for the on-chip OHCI controller on
+ Nuvoton NPCM chips.
+
 endif # USB_OHCI_HCD
 
 config USB_UHCI_HCD
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 7785b3744e..a1de788d8c 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_USB_SL811HS) += sl811-hcd.o
 obj-$(CONFIG_USB_OHCI_LPC32XX) += ohci-lpc32xx.o
 obj-$(CONFIG_USB_OHCI_PCI) += ohci-pci.o
 obj-$(CONFIG_USB_OHCI_GENERIC) += ohci-generic.o
+obj-$(CONFIG_USB_OHCI_NPCM) += ohci-npcm.o
 
 # echi
 obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
@@ -35,6 +36,7 @@ obj-$(CONFIG_USB_EHCI_MXS) += ehci-mxs.o
 obj-$(CONFIG_USB_EHCI_MX5) += ehci-mx5.o
 obj-$(CONFIG_USB_EHCI_MX6) += ehci-mx6.o
 obj-$(CONFIG_USB_EHCI_MX7) += ehci-mx6.o
+obj-$(CONFIG_USB_EHCI_NPCM) += ehci-npcm.o
 obj-$(CONFIG_USB_EHCI_OMAP) += ehci-omap.o
 obj-$(CONFIG_USB_EHCI_MARVELL) += ehci-marvell.o
 obj-$(CONFIG_USB_EHCI_MSM) += ehci-msm.o
diff --git a/drivers/usb/host/ehci-npcm.c b/drivers/usb/host/ehci-npcm.c
new file mode 100644
index 00..357a5614ed
--- /dev/null
+++ b/drivers/usb/host/ehci-npcm.c
@@ -0,0 +1,119 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2021 Nuvoton Technology Corp.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "ehci.h"
+
+struct npcm_ehci_priv {
+   struct ehci_ctrl ctrl;
+   struct ehci_hccr *hcd;
+   struct phy phy;
+};
+
+static int npcm_ehci_setup_phy(struct udevice *dev, struct phy *phy)
+{
+   int ret;
+
+   if (!phy)
+   return 0;
+
+   ret = generic_phy_get_by_index(dev, 0, phy);
+   if (ret) {
+   if (ret != -ENOENT) {
+   dev_err(dev, "failed to get usb phy\n");
+   return ret;
+   }
+   } else {
+   ret = generic_phy_init(phy);
+   if (ret) {
+   dev_err(dev, "failed to init usb phy\n");
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
+static int npcm_ehci_init(struct udevice *dev)
+{
+   struct npcm_ehci_priv *priv = dev_get_priv(dev);
+   struct reset_ctl reset;
+   int ret;
+
+   ret = reset_get_by_index(dev, 0, &reset);
+   if (ret && ret != -ENOENT && ret != -ENOTSUPP) {
+   dev_err(dev, "failed to get reset\n");
+   return ret;
+   }
+
+   /* reset controller */
+   if (reset_valid(&reset))
+   reset_assert(&reset);
+
+   /* setup phy */
+   ret = npcm_ehci_setup_phy(dev, &priv->phy);
+   if (ret)
+   return ret;
+
+   /* release controller from reset */
+   if (reset_valid(&reset))
+   reset_deassert(&reset);
+
+   return 0;
+}
+
+static int npcm_ehci_probe(struct udevice *dev)
+{
+   struct npcm_ehci_priv *priv = dev_get_priv(dev);
+   struct ehci_hcor *hcor;
+   enum usb_init_type type = dev_get_driver_data(dev);
+   int ret;
+
+   ret = npcm_ehci_init(dev);
+   if (ret)
+   return ret;
+
+   priv->hcd = (struct ehci_hccr *)dev_read_addr_ptr(dev);
+   debug("USB HCD @0x%p\n", priv->hcd);
+   hcor = (struct ehci_hcor *)((uintptr_t)priv->hcd +
+   HC_LENGTH(ehci_readl(&priv->hcd->cr_capbase)));
+
+   return ehci_register(dev, priv->hcd, hcor, NULL, 0, type);
+}
+
+static int npcm_ehci_remove(struct udevice *dev)
+{
+   struct npcm_ehci_priv *priv = dev_get_priv(dev);
+
+   generic_phy_exit(&priv->phy);
+
+   return ehci_deregister(dev);
+}
+
+static const str

[PATCH v1] phy: nuvoton: add NPCM7xx phy control driver

2022-06-21 Thread Jim Liu
add BMC NPCM750 phy control driver

Signed-off-by: Jim Liu 
---
 drivers/phy/Kconfig|   7 ++
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-npcm-usb.c | 215 +
 3 files changed, 223 insertions(+)
 create mode 100644 drivers/phy/phy-npcm-usb.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index c01d9e09b9..4a3856d3c2 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -274,6 +274,13 @@ config PHY_MTK_TPHY
  multi-ports is first version, otherwise is second veriosn,
  so you can easily distinguish them by banks layout.
 
+config PHY_NPCM_USB
+   bool "Nuvoton NPCM USB PHY support"
+   depends on PHY
+   depends on ARCH_NPCM
+   help
+ Support the USB PHY in NPCM SoCs
+
 config PHY_IMX8MQ_USB
bool "NXP i.MX8MQ/i.MX8MP USB PHY Driver"
depends on PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index bf9b40932f..d95439c425 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_MT7620_USB_PHY) += mt7620-usb-phy.o
 obj-$(CONFIG_MT76X8_USB_PHY) += mt76x8-usb-phy.o
 obj-$(CONFIG_PHY_DA8XX_USB) += phy-da8xx-usb.o
 obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
+obj-$(CONFIG_PHY_NPCM_USB) += phy-npcm-usb.o
 obj-$(CONFIG_PHY_IMX8MQ_USB) += phy-imx8mq-usb.o
 obj-$(CONFIG_PHY_XILINX_ZYNQMP) += phy-zynqmp.o
 obj-y += cadence/
diff --git a/drivers/phy/phy-npcm-usb.c b/drivers/phy/phy-npcm-usb.c
new file mode 100644
index 00..24eba66554
--- /dev/null
+++ b/drivers/phy/phy-npcm-usb.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2021 Nuvoton Technology Corp.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* GCR Register Offsets */
+#define GCR_INTCR3 0x9C
+#define GCR_USB1PHYCTL 0x140
+#define GCR_USB2PHYCTL 0x144
+#define GCR_USB3PHYCTL 0x148
+
+/* USBnPHYCTL bit fields */
+#define PHYCTL_RS  BIT(28)
+
+#define USBPHY2SW  GENMASK(13, 12)
+#define USBPHY3SW  GENMASK(15, 14)
+
+#define USBPHY2SW_DEV9_PHY1FIELD_PREP(USBPHY2SW, 0)
+#define USBPHY2SW_HOST1FIELD_PREP(USBPHY2SW, 1)
+#define USBPHY2SW_DEV9_PHY2FIELD_PREP(USBPHY2SW, 3)
+#define USBPHY3SW_DEV8_PHY1FIELD_PREP(USBPHY3SW, 0)
+#define USBPHY3SW_HOST2FIELD_PREP(USBPHY3SW, 1)
+#define USBPHY3SW_DEV8_PHY3FIELD_PREP(USBPHY3SW, 3)
+
+enum controller_id {
+   UDC0_7,
+   UDC8,
+   UDC9,
+   USBH1,
+   USBH2,
+};
+
+enum phy_id {
+   PHY1 = 1,
+   PHY2,
+   PHY3,
+};
+
+/* Phy Switch Settings */
+#define USBDPHY1   ((PHY1 << 8) | UDC0_7)  /* Connect UDC0~7 to PHY1 */
+#define USBD8PHY1  ((PHY1 << 8) | UDC8)/* Connect UDC8 to PHY1 */
+#define USBD9PHY1  ((PHY1 << 8) | UDC9)/* Connect UDC9 to PHY1 */
+#define USBD9PHY2  ((PHY2 << 8) | UDC9)/* Connect UDC9 to PHY2 */
+#define USBH1PHY2  ((PHY2 << 8) | USBH1)   /* Connect USBH1 to PHY2 */
+#define USBD8PHY3  ((PHY3 << 8) | UDC8)/* Connect UDC8 to PHY3 */
+#define USBH2PHY3  ((PHY3 << 8) | USBH2)   /* Connect USBH2 to PHY3 */
+
+struct npcm_usbphy {
+   struct regmap *syscon;
+   u8 id;
+   u16 phy_switch; /* (phy_id << 8) | controller_id */
+};
+
+static int npcm_usb_phy_init(struct phy *phy)
+{
+   struct npcm_usbphy *priv = dev_get_priv(phy->dev);
+   struct reset_ctl reset;
+   int ret;
+
+   ret = reset_get_by_index(phy->dev, 0, &reset);
+   if (ret && ret != -ENOENT && ret != -ENOTSUPP) {
+   dev_err(phy->dev, "can't get phy reset ctrl (err %d)", ret);
+   return ret;
+   }
+
+   /* setup PHY switch */
+   switch (priv->phy_switch) {
+   case USBD8PHY1:
+   regmap_update_bits(priv->syscon, GCR_INTCR3, USBPHY3SW,
+  USBPHY3SW_DEV8_PHY1);
+   break;
+   case USBD8PHY3:
+   regmap_update_bits(priv->syscon, GCR_INTCR3, USBPHY3SW,
+  USBPHY3SW_DEV8_PHY3);
+   break;
+   case USBD9PHY1:
+   regmap_update_bits(priv->syscon, GCR_INTCR3, USBPHY2SW,
+  USBPHY2SW_DEV9_PHY1);
+   break;
+   case USBD9PHY2:
+   regmap_update_bits(priv->syscon, GCR_INTCR3, USBPHY2SW,
+  USBPHY2SW_DEV9_PHY2);
+   break;
+   case USBH1PHY2:
+   regmap_update_bits(priv->syscon, GCR_INTCR3, USBPHY2SW,
+  USBPHY2SW_HOST1);
+   break;
+   case USBH2PHY3:
+   regmap_update_bits(priv->syscon, GCR_INTCR3, USBPHY3SW,
+  USBPHY3SW_HOST2);
+   break;
+   default:
+   break;
+   }
+   /* reset phy */
+   if (reset_valid(&reset))
+   reset_assert(&reset);
+
+   /* Wait for PHY clocks to stablize for 5

RE: [PATCH 08/10] i2c/aspeed: Add AST2600 compatible

2022-06-21 Thread Ryan Chen
> -Original Message-
> From: joel.s...@gmail.com  On Behalf Of Joel Stanley
> Sent: Monday, June 20, 2022 3:25 PM
> To: Ryan Chen ; BMC-SW
> ; Heiko Schocher 
> Cc: u-boot@lists.denx.de; Cédric Le Goater 
> Subject: [PATCH 08/10] i2c/aspeed: Add AST2600 compatible
> 
> Signed-off-by: Joel Stanley 
Reviewed-by: Ryan Chen 
> ---
>  drivers/i2c/ast_i2c.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/i2c/ast_i2c.c b/drivers/i2c/ast_i2c.c index
> 0a93d7c82911..c9ffe2d62820 100644
> --- a/drivers/i2c/ast_i2c.c
> +++ b/drivers/i2c/ast_i2c.c
> @@ -351,6 +351,7 @@ static const struct dm_i2c_ops ast_i2c_ops = {  static
> const struct udevice_id ast_i2c_ids[] = {
>   { .compatible = "aspeed,ast2400-i2c-bus" },
>   { .compatible = "aspeed,ast2500-i2c-bus" },
> + { .compatible = "aspeed,ast2600-i2c-bus" },
>   { },
>  };
> 
> --
> 2.35.1



RE: [PATCH 07/10] i2c/aspeed: Fix reset control

2022-06-21 Thread Ryan Chen
> -Original Message-
> From: joel.s...@gmail.com  On Behalf Of Joel Stanley
> Sent: Monday, June 20, 2022 3:25 PM
> To: Ryan Chen ; BMC-SW
> ; Heiko Schocher 
> Cc: u-boot@lists.denx.de; Cédric Le Goater 
> Subject: [PATCH 07/10] i2c/aspeed: Fix reset control
> 
> The reset control was written for the ast2500 and directly programs the
> clocking register.
> 
> So we can share the code with other SoC generations use the reset device to
> deassert the I2C reset line.
> 
> Signed-off-by: Joel Stanley 
Reviewed-by: Ryan Chen 
> ---
>  drivers/i2c/ast_i2c.c | 22 +++---
>  1 file changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/i2c/ast_i2c.c b/drivers/i2c/ast_i2c.c index
> 2d3fecaa14ea..0a93d7c82911 100644
> --- a/drivers/i2c/ast_i2c.c
> +++ b/drivers/i2c/ast_i2c.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "ast_i2c.h"
> 
> @@ -108,19 +109,26 @@ static int ast_i2c_of_to_plat(struct udevice *dev)
> 
>  static int ast_i2c_probe(struct udevice *dev)  {
> - struct ast2500_scu *scu;
> + struct reset_ctl reset_ctl;
> + int rc;
> 
>   debug("Enabling I2C%u\n", dev_seq(dev));
> 
>   /*
>* Get all I2C devices out of Reset.
> -  * Only needs to be done once, but doing it for every
> -  * device does not hurt.
> +  *
> +  * Only needs to be done once so test before performing reset.
>*/
> - scu = ast_get_scu();
> - ast_scu_unlock(scu);
> - clrbits_le32(&scu->sysreset_ctrl1, SCU_SYSRESET_I2C);
> - ast_scu_lock(scu);
> + rc = reset_get_by_index(dev, 0, &reset_ctl);
> + if (rc) {
> + printf("%s: Failed to get reset signal\n", __func__);
> + return rc;
> + }
> +
> + if (reset_status(&reset_ctl) > 0) {
> + reset_assert(&reset_ctl);
> + reset_deassert(&reset_ctl);
> + }
> 
>   ast_i2c_init_bus(dev);
> 
> --
> 2.35.1



RE: [PATCH 06/10] reset/aspeed: Implement status callback

2022-06-21 Thread Ryan Chen


> -Original Message-
> From: joel.s...@gmail.com  On Behalf Of Joel Stanley
> Sent: Monday, June 20, 2022 3:25 PM
> To: Ryan Chen ; BMC-SW
> ; Heiko Schocher 
> Cc: u-boot@lists.denx.de; Cédric Le Goater 
> Subject: [PATCH 06/10] reset/aspeed: Implement status callback
> 
> The I2C driver shares a reset line between buses, so allow it to test the 
> state of
> the reset line before resetting it.
> 
> Signed-off-by: Joel Stanley 
Reviewed-by: Ryan Chen 
> ---
>  drivers/reset/reset-ast2500.c | 19 +++
> drivers/reset/reset-ast2600.c | 17 +
>  2 files changed, 36 insertions(+)
> 
> diff --git a/drivers/reset/reset-ast2500.c b/drivers/reset/reset-ast2500.c 
> index
> 0a1dd236aff3..d9cecf3a72e8 100644
> --- a/drivers/reset/reset-ast2500.c
> +++ b/drivers/reset/reset-ast2500.c
> @@ -48,6 +48,24 @@ static int ast2500_reset_deassert(struct reset_ctl
> *reset_ctl)
>   return 0;
>  }
> 
> +static int ast2500_reset_status(struct reset_ctl *reset_ctl) {
> + struct ast2500_reset_priv *priv = dev_get_priv(reset_ctl->dev);
> + struct ast2500_scu *scu = priv->scu;
> + int status;
> +
> + debug("%s: reset_ctl->id: %lu\n", __func__, reset_ctl->id);
> +
> + if (reset_ctl->id < 32)
> + status = BIT(reset_ctl->id) & readl(&scu->sysreset_ctrl1);
> + else
> + status = BIT(reset_ctl->id - 32) & readl(&scu->sysreset_ctrl2);
> +
> + return !!status;
> +}
> +
> +
> +
>  static int ast2500_reset_probe(struct udevice *dev)  {
>   int rc;
> @@ -79,6 +97,7 @@ static const struct udevice_id ast2500_reset_ids[] =
> {  struct reset_ops ast2500_reset_ops = {
>   .rst_assert = ast2500_reset_assert,
>   .rst_deassert = ast2500_reset_deassert,
> + .rst_status = ast2500_reset_status,
>  };
> 
>  U_BOOT_DRIVER(ast2500_reset) = {
> diff --git a/drivers/reset/reset-ast2600.c b/drivers/reset/reset-ast2600.c 
> index
> 985235a3ac46..1732a450efc0 100644
> --- a/drivers/reset/reset-ast2600.c
> +++ b/drivers/reset/reset-ast2600.c
> @@ -47,6 +47,22 @@ static int ast2600_reset_deassert(struct reset_ctl
> *reset_ctl)
>   return 0;
>  }
> 
> +static int ast2600_reset_status(struct reset_ctl *reset_ctl) {
> + struct ast2600_reset_priv *priv = dev_get_priv(reset_ctl->dev);
> + struct ast2600_scu *scu = priv->scu;
> + int status;
> +
> + debug("%s: reset_ctl->id: %lu\n", __func__, reset_ctl->id);
> +
> + if (reset_ctl->id < 32)
> + status = BIT(reset_ctl->id) & readl(&scu->modrst_ctrl1);
> + else
> + status = BIT(reset_ctl->id - 32) & readl(&scu->modrst_ctrl2);
> +
> + return !!status;
> +}
> +
>  static int ast2600_reset_probe(struct udevice *dev)  {
>   int rc;
> @@ -78,6 +94,7 @@ static const struct udevice_id ast2600_reset_ids[] =
> {  struct reset_ops ast2600_reset_ops = {
>   .rst_assert = ast2600_reset_assert,
>   .rst_deassert = ast2600_reset_deassert,
> + .rst_status = ast2600_reset_status,
>  };
> 
>  U_BOOT_DRIVER(ast2600_reset) = {
> --
> 2.35.1



Re: [PATCH v3 7/8] net: add MV88E61xx DSA driver

2022-06-21 Thread Vladimir Oltean
On Mon, Jun 20, 2022 at 04:37:45PM -0700, Tim Harvey wrote:
> On Mon, Jun 20, 2022 at 4:58 AM Vladimir Oltean
>  wrote:
> >
> > On Mon, May 23, 2022 at 11:25:48AM -0700, Tim Harvey wrote:
> > > +/* bind and probe the switch mdios */
> > > +static int mv88e61xx_dsa_probe_mdio(struct udevice *dev)
> > > +{
> > > + struct udevice *pdev;
> > > + ofnode node, mdios;
> > > + const char *name;
> > > + int ret;
> > > +
> > > + /* bind phy ports of mdios child node to mv88e61xx_mdio device */
> > > + mdios = dev_read_subnode(dev, "mdios");
> > > + if (ofnode_valid(mdios)) {
> > > + ofnode_for_each_subnode(node, mdios) {
> > > + name = ofnode_get_name(node);
> > > + ret = device_bind_driver_to_node(dev,
> > > +  "mv88e61xx_mdio",
> > > +  name, node, &pdev);
> > > + if (ret) {
> > > + dev_err(dev, "failed to bind %s: %d\n", 
> > > name, ret);
> > > + continue;
> > > + }
> > > +
> > > + /* need to probe it as there is no compatible to do 
> > > so */
> > > + ret = uclass_get_device_by_ofnode(UCLASS_MDIO, 
> > > node, &pdev);
> > > + if (ret) {
> > > + dev_err(dev, "failed to probe %s: %d\n", 
> > > name, ret);
> > > + continue;
> > > + }
> >
> > What do you do with this pdev once you get it? Are you missing a 
> > device_probe() call?
> > Also, why "pdev" and not "dev"? What does the "p" stand for?
> 
> struct udevice *dev is passed into the function so I use pdev to
> iterate over the ports in the mdios node so 'pdev' means 'port' here.

Yes, but those under the mdios node aren't ports, they're MDIO
controllers, hence my comment.

> I do not need to do anything with pdev but I must use
> uclass_get_device_by_ofnode() to probe it and that function requires
> it. I don't need to call device_probe because
> uclass_get_device_by_ofnode does it for me

Ok, I didn't notice they all call uclass_get_device_tail() which calls
device_probe().

Re: [PATCH] arm: dts: imx8mn: sync dts from Linux Kernel

2022-06-21 Thread Heiko Thiery
Hi,

Am Di., 21. Juni 2022 um 09:03 Uhr schrieb Peng Fan (OSS)
:
>
>
>
> 在 2022/6/21 1:33, Heiko Thiery 写道:
> > Sync dts for imx8mn-evk with Linux Kernel and change name for PMIC used in 
> > SPL.
> >
> > commit 1cfa1e68af8d40ab233d5d27bc8446e4c5107571("arm64: dts: imx8mn-evk: 
> > fix the min/max voltages of the PMIC")
> > commit bc046b952a5494b0dc53be28779460cee1214a3f("arm64: dts: imx8mn-evk: 
> > use proper names for PMIC outputs")
>
> I think the way to sync dts is to choose one linux release RC to sync.
> not just sync partial.

It is not partial .. I just wanted to show what changes are made.

>
> Thanks,
> Peng.
> >
> > Signed-off-by: Heiko Thiery 
> > ---
> >   arch/arm/dts/imx8mn-evk.dts  | 56 
> >   board/freescale/imx8mn_evk/spl.c |  4 +--
> >   2 files changed, 30 insertions(+), 30 deletions(-)
> >
> > diff --git a/arch/arm/dts/imx8mn-evk.dts b/arch/arm/dts/imx8mn-evk.dts
> > index cd11fb28f5..4eb467df5b 100644
> > --- a/arch/arm/dts/imx8mn-evk.dts
> > +++ b/arch/arm/dts/imx8mn-evk.dts
> > @@ -31,7 +31,7 @@
> >   };
> >
> >   &i2c1 {
> > - pmic: pca9450@25 {
> > + pmic: pmic@25 {
> >   compatible = "nxp,pca9450b";
> >   reg = <0x25>;
> >   pinctrl-names = "default";
> > @@ -41,18 +41,18 @@
> >
> >   regulators {I think the way to sync dts is to choose one 
> > linux release RC to sync.
not just sync partial.
> >   buck1: BUCK1{
> > - regulator-name = "BUCK1";
> > - regulator-min-microvolt = <60>;
> > - regulator-max-microvolt = <2187500>;
> > + regulator-name = "VDD_SOC";
> > + regulator-min-microvolt = <85>;
> > + regulator-max-microvolt = <95>;
> >   regulator-boot-on;
> >   regulator-always-on;
> >   regulator-ramp-delay = <3125>;
> >   };
> >
> >   buck2: BUCK2 {
> > - regulator-name = "BUCK2";
> > - regulator-min-microvolt = <60>;
> > - regulator-max-microvolt = <2187500>;
> > + regulator-name = "VDD_ARM_0V9";
> > + regulator-min-microvolt = <85>;
> > + regulator-max-microvolt = <100>;
> >   regulator-boot-on;
> >   regulator-always-on;
> >   regulator-ramp-delay = <3125>;
> > @@ -61,63 +61,63 @@
> >   };
> >
> >   buck4: BUCK4{
> > - regulator-name = "BUCK4";
> > - regulator-min-microvolt = <60>;
> > - regulator-max-microvolt = <340>;
> > + regulator-name = "VDD_3V3";
> > + regulator-min-microvolt = <330>;
> > + regulator-max-microvolt = <330>;
> >   regulator-boot-on;
> >   regulator-always-on;
> >   };
> >
> >   buck5: BUCK5{
> > - regulator-name = "BUCK5";
> > - regulator-min-microvolt = <60>;
> > - regulator-max-microvolt = <340>;
> > + regulator-name = "VDD_1V8";
> > + regulator-min-microvolt = <180>;
> > + regulator-max-microvolt = <180>;
> >   regulator-boot-on;
> >   regulator-always-on;
> >   };
> >
> >   buck6: BUCK6 {
> > - regulator-name = "BUCK6";
> > - regulator-min-microvolt = <60>;
> > - regulator-max-microvolt = <340>;
> > + regulator-name = "NVCC_DRAM_1V1";
> > + regulator-min-microvolt = <110>;
> > + regulator-max-microvolt = <110>;
> >   regulator-boot-on;
> >   regulator-always-on;
> >   };
> >
> >   ldo1: LDO1 {
> > - regulator-name = "LDO1";
> > - regulator-min-microvolt = <160>;
> > - regulator-max-microvolt = <330>;
> > + regulator-name = "NVCC_SNVS_1V8";
> > + regulator-min-microvolt = <180>;
> > + regulator-max-microvolt = <180>;
> >  

Re: [PATCH] arm: dts: imx8mn: sync dts from Linux Kernel

2022-06-21 Thread Peng Fan (OSS)




在 2022/6/21 1:33, Heiko Thiery 写道:

Sync dts for imx8mn-evk with Linux Kernel and change name for PMIC used in SPL.

commit 1cfa1e68af8d40ab233d5d27bc8446e4c5107571("arm64: dts: imx8mn-evk: fix the 
min/max voltages of the PMIC")
commit bc046b952a5494b0dc53be28779460cee1214a3f("arm64: dts: imx8mn-evk: use proper 
names for PMIC outputs")


I think the way to sync dts is to choose one linux release RC to sync. 
not just sync partial.


Thanks,
Peng.


Signed-off-by: Heiko Thiery 
---
  arch/arm/dts/imx8mn-evk.dts  | 56 
  board/freescale/imx8mn_evk/spl.c |  4 +--
  2 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/arch/arm/dts/imx8mn-evk.dts b/arch/arm/dts/imx8mn-evk.dts
index cd11fb28f5..4eb467df5b 100644
--- a/arch/arm/dts/imx8mn-evk.dts
+++ b/arch/arm/dts/imx8mn-evk.dts
@@ -31,7 +31,7 @@
  };
  
  &i2c1 {

-   pmic: pca9450@25 {
+   pmic: pmic@25 {
compatible = "nxp,pca9450b";
reg = <0x25>;
pinctrl-names = "default";
@@ -41,18 +41,18 @@
  
  		regulators {

buck1: BUCK1{
-   regulator-name = "BUCK1";
-   regulator-min-microvolt = <60>;
-   regulator-max-microvolt = <2187500>;
+   regulator-name = "VDD_SOC";
+   regulator-min-microvolt = <85>;
+   regulator-max-microvolt = <95>;
regulator-boot-on;
regulator-always-on;
regulator-ramp-delay = <3125>;
};
  
  			buck2: BUCK2 {

-   regulator-name = "BUCK2";
-   regulator-min-microvolt = <60>;
-   regulator-max-microvolt = <2187500>;
+   regulator-name = "VDD_ARM_0V9";
+   regulator-min-microvolt = <85>;
+   regulator-max-microvolt = <100>;
regulator-boot-on;
regulator-always-on;
regulator-ramp-delay = <3125>;
@@ -61,63 +61,63 @@
};
  
  			buck4: BUCK4{

-   regulator-name = "BUCK4";
-   regulator-min-microvolt = <60>;
-   regulator-max-microvolt = <340>;
+   regulator-name = "VDD_3V3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
regulator-boot-on;
regulator-always-on;
};
  
  			buck5: BUCK5{

-   regulator-name = "BUCK5";
-   regulator-min-microvolt = <60>;
-   regulator-max-microvolt = <340>;
+   regulator-name = "VDD_1V8";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
regulator-boot-on;
regulator-always-on;
};
  
  			buck6: BUCK6 {

-   regulator-name = "BUCK6";
-   regulator-min-microvolt = <60>;
-   regulator-max-microvolt = <340>;
+   regulator-name = "NVCC_DRAM_1V1";
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <110>;
regulator-boot-on;
regulator-always-on;
};
  
  			ldo1: LDO1 {

-   regulator-name = "LDO1";
-   regulator-min-microvolt = <160>;
-   regulator-max-microvolt = <330>;
+   regulator-name = "NVCC_SNVS_1V8";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
regulator-boot-on;
regulator-always-on;
};
  
  			ldo2: LDO2 {

-   regulator-name = "LDO2";
+   regulator-name = "VDD_SNVS_0V8";
regulator-min-microvolt = <80>;
-   regulator-max-microvolt = <115>;
+   regulator-max-microvolt = <80>;
regulator-boot-on;
regulator-always-on;