RE: [PATCH] cmd: mmc: Print life time info

[ZHIZHIKIN Andrey]

Hello all,

> -Original Message-
> From: U-Boot  On Behalf Of Jaehoon Chung
> Sent: Wednesday, November 2, 2022 11:49 PM
> To: Robert Krikke ; u-boot@lists.denx.de
> Cc: Robert Krikke ; Harm Berntsen
> 
> Subject: Re: [PATCH] cmd: mmc: Print life time info
> 
> Hi,
> 
> On 11/2/22 23:17, Robert Krikke wrote:
> > Added life time info:
> > -EXT_CSD_PRE_EOL_INFO
> > -EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A
> > -EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B
> 
> I'm not sure that it really needs to display this information as mmc info.
> I hope that mmc info command should be displayed essential information.
> 
> >
> > Signed-off-by: Robert Krikke 
> > Reviewed-by: Harm Berntsen 
> > ---
> >  cmd/mmc.c | 6 ++
> >  include/mmc.h | 3 +++
> >  2 files changed, 9 insertions(+)
> >
> > diff --git a/cmd/mmc.c b/cmd/mmc.c
> > index 7bd4cd9e016..b940e320295 100644
> > --- a/cmd/mmc.c
> > +++ b/cmd/mmc.c
> > @@ -127,6 +127,12 @@ static void print_mmcinfo(struct mmc *mmc)
> > }
> > wp >>= 2;
> > }
> > +
> > +   if (mmc->version >= MMC_VERSION_5_0) {
> 
> Move to outside of MMC_VERSION_4_41 if statement.
> 
> > +   printf("Pre EOL Information: 0x%02X\n",
> ext_csd[EXT_CSD_PRE_EOL_INFO]);
> > +   printf("Life Time Estimation A: 0x%02X\n",
> ext_csd[EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]);
> > +   printf("Life Time Estimation B: 0x%02X\n",
> ext_csd[EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]);
> 
> It's not a readable value. If didn't check the eMMC5.0 spec, it's difficult to
> know what means 0x01, 0x02..etc..

According to JEDEC spec, this value shows the "used lifetime of the
device in  x 10%".

PRE_EOL_INFO [267] provides indication about device life time
reflected by average reserved blocks, and it can take only values:
- 0x00 [Not Defined]
- 0x01 [Normal Normal]
- 0x02 [Warning: Consumed 80% of reserved block]
- 0x03 [Urgent]
Everything else is Reserved.

I would also have the same comment here as Jaehoon, as from the
commit message it is not clear what is the Use Case you're trying
to solve?

If it is designed for automation - then the output is a bit cluttered
and hard to parse. If it is designed for user readability, then I
would rather suggest to convert it to what the field in ExtCSD really
shows: percentage and status accordingly.

A bit more context would be appreciated here, preferably in commit
message.

All-in-all, I really doubt that this info is useful in U-Boot. Linux
has a full readout of the ExtCSD, where the same value can be obtained.
If it is designed to stop the update and report that eMMC is at the end
of its life - then it is rather "automation" Use Case, and as I said
above - the output is way too cluttered to parse.

> 
> Best Regards,
> Jaehoon Chung
> 
> > +   }
> > }
> >  }
> >
> > diff --git a/include/mmc.h b/include/mmc.h
> > index f519d869725..d0c3e684595 100644
> > --- a/include/mmc.h
> > +++ b/include/mmc.h
> > @@ -242,6 +242,9 @@ static inline bool mmc_is_tuning_cmd(uint cmdidx)
> >  #define EXT_CSD_HC_ERASE_GRP_SIZE  224 /* RO */
> >  #define EXT_CSD_BOOT_MULT  226 /* RO */
> >  #define EXT_CSD_GENERIC_CMD6_TIME   248 /* RO */
> > +#define EXT_CSD_PRE_EOL_INFO   267 /* RO */
> > +#define EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A 268 /* RO */
> > +#define EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B 269 /* RO */
> >  #define EXT_CSD_BKOPS_SUPPORT  502 /* RO */
> >
> >  /*

Regards,
Andrey

RE: [EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on imx8m series with CAAM enabled

[ZHIZHIKIN Andrey]

Hello Fabio,

> -Original Message-
> From: U-Boot  On Behalf Of Fabio Estevam
> Sent: Friday, October 14, 2022 9:38 PM
> To: ZHIZHIKIN Andrey 
> Cc: Rasmus Villemoes ; Peng Fan
> ; Gaurav Jain ; 
> u-boot@lists.denx.de;
> feste...@denx.de; sba...@denx.de; Michael Walle ; Tommaso
> Merciai ; Michael Trimarchi
> ; Marek Vasut ; Simon Glass
> ; Patrick Delaunay ; Stefan 
> Roese
> ; Horia Geanta ; Pankaj Gupta
> ; Varun Sethi ; Ye Li ; 
> dl-
> uboot-imx ; trini 
> Subject: Re: [EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on imx8m 
> series
> with CAAM enabled
> 
> Hi Andrey,
> 
> On Fri, Oct 14, 2022 at 3:53 PM ZHIZHIKIN Andrey
>  wrote:
> 
> > `imx8mp.dtsi` however was not sync'd in, so the JR0 disabling is left out. 
> > :(
> > This does explain why the SHA calculation are not operable for that SoC.
> 
> Marcel has submitted the dts sync patch:
> https://lists.denx.de/pipermail/u-boot/2022-August/492834.html

Yes, but this was not picked up... At least, I do not see it applied on the 
master.

From the entire series [1], the patch that shall solve the issue is [2], and it 
is
the one I do not see applied onto master.

Regards,
Andrey

Link: [1]: 
https://lore.kernel.org/u-boot/20220826183141.789236-1-mar...@ziswiler.com/
Link: [2]: 
https://lore.kernel.org/u-boot/20220826183141.789236-7-mar...@ziswiler.com/

RE: [EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on imx8m series with CAAM enabled

[ZHIZHIKIN Andrey]

Hello all,

> -Original Message-
> From: U-Boot  On Behalf Of Rasmus Villemoes
> Sent: Friday, October 14, 2022 7:50 PM
> To: Peng Fan ; ZHIZHIKIN Andrey  geosystems.com>; Gaurav Jain 
> Cc: u-boot@lists.denx.de; feste...@denx.de; sba...@denx.de; Michael Walle
> ; Tommaso Merciai ;
> Michael Trimarchi ; Marek Vasut ;
> Simon Glass ; Patrick Delaunay 
> ;
> Stefan Roese ; Horia Geanta ; Pankaj Gupta
> ; Varun Sethi ; Ye Li ; 
> dl-
> uboot-imx ; trini 
> Subject: Re: [EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on imx8m 
> series
> with CAAM enabled
> 
> On 14/10/2022 03.00, Peng Fan wrote:
> >
> >>> Right now I am not sure what could cause the issue.
> >>> As per our previous discussions, JR0 can not be used in uboot, so you
> >>> need to
> >>> mark it as disabled until kernel device tree is not sync.
> >>
> >> Actually, I've given this a try by setting `status = "disabled"` in
> >> sec_jr0 node,
> >> and then the hash calculation was working again!
> >
> > Did you enable optee? If disabling sec_jr0 to make it work, i think
> > there is issue somewhere.
> >
> > With optee enabled, optee will take JR0. If optee not enabled, JR0 could
> > be used by U-Boot.
> 
> I can't speak for Andrey, but no, I don't enable/use optee on my imx8mp.

I also do not have an OP-TEE in my setup, but since upstream TF-A commit
77850c96f23b ("feat(plat/imx8m): do not release JR0 to NS if HAB is using
it") [1] this makes no difference, as JR0 would be permanently held in
S-World.

Downstream fork has the same implementation done in commit 961f90418874
("TEE-639 plat: imx8m: Do not release JR0 to NS if HAB is using it"), so it
is now consistent behavior across upstream and downstream.

This means that JR0 has to be permanently disabled in the DTB, with Kernel
being the first followed by the U-Boot sync.

This work has been already accomplished by Fabio in Kernel via commit
dc9c1ceb555f ("arm64: dts: imx8m: Disable job ring 0 nodes") [3], and sync'd
in for `imx8mm.dtsi` in commit 05996f350d48 ("imx8mm: Sync device tree with
linux-next 20220711") [4].

`imx8mp.dtsi` however was not sync'd in, so the JR0 disabling is left out. :(
This does explain why the SHA calculation are not operable for that SoC.

> 
> Rasmus

-- andrey

Link: [1]: 
http://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=77850c96f23bcdc76ecb0ecd27a982c00fde5d9d
Link: [2]: 
https://source.codeaurora.org/external/imx/imx-atf/commit/plat/imx/imx8m/imx8m_caam.c?id=961f904188746ce495af67a40f300f5b0bd50ca4
Link: [3]: 
https://github.com/torvalds/linux/commit/dc9c1ceb555ff661e6fc1081434600771f29657c
Link: [4]: 
https://source.denx.de/u-boot/u-boot/-/commit/05996f350d482d2a450173ce3340ee69c8f74ad4

RE: [PATCH v2] crypto/fsl: Add support for black key blob

[ZHIZHIKIN Andrey]

Hello Gaurav,

> -Original Message-
> From: U-Boot  On Behalf Of Gaurav Jain
> Sent: Wednesday, September 28, 2022 12:40 PM
> To: u-boot@lists.denx.de; Stefano Babic 
> Cc: Fabio Estevam ; Peng Fan ; Ye Li
> ; NXP i . MX U-Boot Team ; Horia Geanta
> ; Varun Sethi ; Gaurav Jain
> 
> Subject: [PATCH v2] crypto/fsl: Add support for black key blob
> 
> modified caam descriptor to support black key blob.

A bit more context on this change in appreciated. How shall this
can/be used, what is the benefit, how the "black" blob needs to
be wrapped, and which mechanism shall be used for wrapping?

> 
> Signed-off-by: Gaurav Jain 
> ---
> changes in v2:
> - rebase to latest
> 
>  cmd/blob.c| 12 

Nitpick: This file is missing copyright note since initial
Submission, which was done with commit c5de15cbc8a8
("crypto/fsl: Add command for encapsulating/decapsulating
blobs").

Does it make sense that you add it?

>  drivers/crypto/fsl/desc.h |  1 +
>  drivers/crypto/fsl/fsl_blob.c | 21 +
>  drivers/crypto/fsl/jobdesc.c  | 24 +++-
>  drivers/crypto/fsl/jobdesc.h  |  8 ++--
>  5 files changed, 47 insertions(+), 19 deletions(-)
> 
> diff --git a/cmd/blob.c b/cmd/blob.c
> index e2efae7a11..5c459b6f19 100644
> --- a/cmd/blob.c
> +++ b/cmd/blob.c
> @@ -21,10 +21,12 @@
>   * @src: - Address of data to be decapsulated
>   * @dst: - Address of data to be decapsulated
>   * @len: - Size of data to be decapsulated
> + * @keycolor- Determines if the source data is covered (black key) or
> + *plaintext.
>   *
>   * Returns zero on success,and negative on error.
>   */
> -__weak int blob_decap(u8 *key_mod, u8 *src, u8 *dst, u32 len)
> +__weak int blob_decap(u8 *key_mod, u8 *src, u8 *dst, u32 len, u8 keycolor)

Is the only intention to indicate if the blob is "black/red" 
(wrapped/unwrapped)?
In this case, perhaps the `bool` is sufficient.

>  {
>   return 0;
>  }
> @@ -35,10 +37,12 @@ __weak int blob_decap(u8 *key_mod, u8 *src, u8 *dst, u32 
> len)
>   * @src: - Address of data to be encapsulated
>   * @dst: - Address of data to be encapsulated
>   * @len: - Size of data to be encapsulated
> + * @keycolor- Determines if the source data is covered (black key) or
> + *plaintext.
>   *
>   * Returns zero on success,and negative on error.
>   */
> -__weak int blob_encap(u8 *key_mod, u8 *src, u8 *dst, u32 len)
> +__weak int blob_encap(u8 *key_mod, u8 *src, u8 *dst, u32 len, u8 keycolor)

Ditto.

>  {
>   return 0;
>  }
> @@ -91,9 +95,9 @@ static int do_blob(struct cmd_tbl *cmdtp, int flag, int 
> argc,
>  #endif
> 
>   if (enc)
> - ret = blob_encap(km_ptr, src_ptr, dst_ptr, len);
> + ret = blob_encap(km_ptr, src_ptr, dst_ptr, len, 0);

Key type deserves either its own type, or at least a define. 0 - is just
a "magic number".

This is already done in drivers/crypto/fsl/jobdesc.h below, so shall be
reflected here.

>   else
> - ret = blob_decap(km_ptr, src_ptr, dst_ptr, len);
> + ret = blob_decap(km_ptr, src_ptr, dst_ptr, len, 0);

Same as above.

In addition, this implementation suggests that there is no
support to use wrapped keys with this command as there is
no additional parameter to it indicating type, no logic to
check if the key is wrapped, and default value passed
suggests that only plain keys can be used (0 implies it).

Does it make sense that you extend the command here as well
to let the user pass the type?

> 
>   return ret;
>  }
> diff --git a/drivers/crypto/fsl/desc.h b/drivers/crypto/fsl/desc.h
> index 5705c4f944..4c148a2fc4 100644
> --- a/drivers/crypto/fsl/desc.h
> +++ b/drivers/crypto/fsl/desc.h
> @@ -435,6 +435,7 @@
>  /* Assuming OP_TYPE = OP_TYPE_UNI_PROTOCOL */
>  #define OP_PCLID_SECMEM  0x08
>  #define OP_PCLID_BLOB(0x0d << OP_PCLID_SHIFT)
> +#define OP_PCL_BLOB_BLACK0x0004

BIT() macro?

>  #define OP_PCLID_SECRETKEY   (0x11 << OP_PCLID_SHIFT)
>  #define OP_PCLID_PUBLICKEYPAIR   (0x14 << OP_PCLID_SHIFT)
>  #define OP_PCLID_DSA_SIGN(0x15 << OP_PCLID_SHIFT)
> diff --git a/drivers/crypto/fsl/fsl_blob.c b/drivers/crypto/fsl/fsl_blob.c
> index 9b6e4bca06..034e6ae5df 100644
> --- a/drivers/crypto/fsl/fsl_blob.c
> +++ b/drivers/crypto/fsl/fsl_blob.c
> @@ -1,6 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
>   * Copyright 2014 Freescale Semiconductor, Inc.
> + * Copyright 2022 NXP
>   *
>   */
> 
> @@ -22,13 +23,15 @@
>   * @src:- Source address (blob)
>   * @dst:- Destination address (data)
>   * @len:- Size of decapsulated data
> + * @keycolor- Determines if the source data is covered (black key) or
> + *plaintext.
>   *
>   * Note: Start and end of the key_mod, src and dst buffers have to be 
> aligned to
>   * the cache line size (ARCH_DMA_MINALIGN) for the CAAM operation to succeed.
>   *
>   * Returns zero on 

RE: [PATCH 2/2] imx8mm_evk: Add Serial Download Protocol support

[ZHIZHIKIN Andrey]

Hello Michael,

> -Original Message-
> From: U-Boot  On Behalf Of Michael Nazzareno
> Trimarchi
> Sent: Tuesday, September 20, 2022 7:46 AM
> To: Fabio Estevam 
> Cc: sba...@denx.de; peng@nxp.com; ma...@denx.de; u-boot@lists.denx.de
> Subject: Re: [PATCH 2/2] imx8mm_evk: Add Serial Download Protocol support
> 
> Hi
> 
> On Tue, Sep 20, 2022 at 2:21 AM Fabio Estevam  wrote:
> >
> > Add Serial Download Protocol support as it is a useful method to
> > load flash.bin to RAM and run it via 'uuu'.
> >
> > With this patch, it is possible to start both U-Boot SPL and U-Boot
> > proper using the following 'uuu'command:
> >
> > $ uuu -brun spl flash.bin
> >
> > Based on a patch from Marek Vasut for the imx8mm-mx8menlo board.
> >
> > Also, to fit the SPL binary into the internal RAM, select CONFIG_LTO
> > to reduce its size.
> >
> > Signed-off-by: Fabio Estevam 
> > ---
> >  arch/arm/dts/imx8mm-evk-u-boot.dtsi | 16 
> >  configs/imx8mm_evk_defconfig| 21 +
> >  2 files changed, 37 insertions(+)
> >
> > diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi 
> > b/arch/arm/dts/imx8mm-evk-u-
> boot.dtsi
> > index 36fbf56bc5..d82428f8fe 100644
> > --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> > +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> > @@ -20,6 +20,10 @@
> > };
> >  };
> >
> > + {
> > +   u-boot,dm-spl;
> > +};
> > +
> >  _usdhc2_vmmc {
> > u-boot,off-on-delay-us = <2>;
> >  };
> > @@ -84,6 +88,18 @@
> > u-boot,dm-spl;
> >  };
> >
> > + {
> > +   u-boot,dm-spl;
> > +};
> > +
> > + {
> > +   u-boot,dm-spl;
> > +};
> > +
> > + {
> > +   u-boot,dm-spl;
> > +};
> > +
> >   {
> > u-boot,dm-spl;
> >  };
> > diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig
> > index 7bcedcd51f..2dff26b3eb 100644
> > --- a/configs/imx8mm_evk_defconfig
> > +++ b/configs/imx8mm_evk_defconfig
> > @@ -17,6 +17,7 @@ CONFIG_SPL_SERIAL=y
> >  CONFIG_SPL_DRIVERS_MISC=y
> >  CONFIG_SPL=y
> >  CONFIG_SYS_LOAD_ADDR=0x4048
> > +CONFIG_LTO=y
> 
> Is the entry required? or part of the series. If so could you explain
> in the commit message?

While not being strictly part of the series, Fabio did explained the
LTO enablement in the commit message above. This reduces the size of
SPL, which in turn allows it to fit into IRAM.

-- andrey

> 
> Michael
> 
> >  CONFIG_DISTRO_DEFAULTS=y
> >  CONFIG_FIT=y
> >  CONFIG_FIT_EXTERNAL_OFFSET=0x3000
> > @@ -38,6 +39,9 @@ CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
> >  CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x300
> >  CONFIG_SPL_I2C=y
> >  CONFIG_SPL_POWER=y
> > +CONFIG_SPL_USB_HOST=y
> > +CONFIG_SPL_USB_GADGET=y
> > +CONFIG_SPL_USB_SDP_SUPPORT=y
> >  CONFIG_SPL_WATCHDOG=y
> >  CONFIG_SYS_MAXARGS=64
> >  CONFIG_SYS_CBSIZE=2048
> > @@ -50,6 +54,8 @@ CONFIG_CMD_FUSE=y
> >  CONFIG_CMD_GPIO=y
> >  CONFIG_CMD_I2C=y
> >  CONFIG_CMD_MMC=y
> > +CONFIG_CMD_USB_SDP=y
> > +CONFIG_CMD_USB_MASS_STORAGE=y
> >  CONFIG_CMD_CACHE=y
> >  CONFIG_CMD_REGULATOR=y
> >  CONFIG_CMD_EXT4_WRITE=y
> > @@ -80,9 +86,13 @@ CONFIG_PHY_ATHEROS=y
> >  CONFIG_PHY_GIGE=y
> >  CONFIG_FEC_MXC=y
> >  CONFIG_MII=y
> > +CONFIG_SPL_PHY=y
> > +CONFIG_SPL_NOP_PHY=y
> >  CONFIG_PINCTRL=y
> >  CONFIG_SPL_PINCTRL=y
> >  CONFIG_PINCTRL_IMX8M=y
> > +CONFIG_POWER_DOMAIN=y
> > +CONFIG_IMX8M_POWER_DOMAIN=y
> >  CONFIG_DM_PMIC=y
> >  CONFIG_SPL_DM_PMIC_PCA9450=y
> >  CONFIG_DM_REGULATOR=y
> > @@ -97,4 +107,15 @@ CONFIG_SPL_SYSRESET=y
> >  CONFIG_SYSRESET_PSCI=y
> >  CONFIG_SYSRESET_WATCHDOG=y
> >  CONFIG_DM_THERMAL=y
> > +CONFIG_USB=y
> > +CONFIG_USB_EHCI_HCD=y
> > +CONFIG_MXC_USB_OTG_HACTIVE=y
> > +# CONFIG_USB_STORAGE is not set
> > +CONFIG_USB_GADGET=y
> > +CONFIG_USB_GADGET_MANUFACTURER="FSL"
> > +CONFIG_USB_GADGET_VENDOR_NUM=0x0525
> > +CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
> > +CONFIG_CI_UDC=y
> > +CONFIG_SDP_LOADADDR=0x4040
> > +CONFIG_USB_GADGET_DOWNLOAD=y
> >  CONFIG_IMX_WATCHDOG=y
> > --
> > 2.25.1
> >
> 
> 
> --
> Michael Nazzareno Trimarchi
> Co-Founder & Chief Executive Officer
> M. +39 347 913 2170
> mich...@amarulasolutions.com
> __
> 
> Amarula Solutions BV
> Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
> T. +31 (0)85 111 9172
> i...@amarulasolutions.com
> www.amarulasolutions.com

RE: [PATCH v1 0/2] serial_mxc: fixing reception

[ZHIZHIKIN Andrey]

Hello Fabio,

> -Original Message-
> From: U-Boot  On Behalf Of Fabio Estevam
> Sent: Monday, September 5, 2022 1:20 PM
> To: ZHIZHIKIN Andrey 
> Cc: Pali Rohár ; u-boot@lists.denx.de; trini
> ; Peng Fan (OSS) ; Fabio Estevam
> ; Stefano Babic 
> Subject: Re: [PATCH v1 0/2] serial_mxc: fixing reception
> 
> Hi Andrey,
> 
> On Mon, Sep 5, 2022 at 6:21 AM ZHIZHIKIN Andrey
>  wrote:
> 
> > I cannot modify this part since removing you from maintainer list would
> > require a transfer of maintainership of this component to another name,
> > which I do not know.
> >
> > I've Cc:'d Tom and people from imx world here so they can make a decision
> > on who shall continue the maintenance of this file when your entry is 
> > removed.
> 
> I have added the imx serial driver to the "ARM FREESCALE IMX" list:
> https://lore.kernel.org/u-boot/20220905105700.3209658-1-feste...@gmail.com/T/#u

I've seen your patch on the ML already, thanks a lot for taking care of this!

Regards,
Andrey

RE: [PATCH v1 0/2] serial_mxc: fixing reception

[ZHIZHIKIN Andrey]

Hello Pali,

> -Original Message-
> From: U-Boot  On Behalf Of Pali Rohar
> Sent: Monday, September 5, 2022 11:14 AM
> To: ZHIZHIKIN Andrey 
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH v1 0/2] serial_mxc: fixing reception
> 
> On Monday 05 September 2022 09:12:49 ZHIZHIKIN Andrey wrote:
> > Hello Pali,
> >
> > > -Original Message-
> > > From: U-Boot  On Behalf Of Pali Rohar
> > > Sent: Monday, September 5, 2022 10:59 AM
> > > To: u-boot@lists.denx.de
> > > Subject: Re: [PATCH v1 0/2] serial_mxc: fixing reception
> > >
> > > On Monday 05 September 2022 10:53:58 Johannes Schneider wrote:
> > > > while writing to a imx-serial device is probably thoroughly tested - and
> > > obviosly works for the debug-serial - using a serial driver to read data
> received
> > > over the serial interface does not work reliably.
> > > >
> > > > the patches in this series address issues found during the 
> > > > implementation
> of a
> > > custom uboot-command to query a coprocessor, connected to an imx8mm over
> uart4,
> > > for mainboard-identification strings
> > > >
> > > >
> > > > Johannes Schneider (2):
> > > >   serial: mxc: enable the RX pipeline
> > > >   serial: mxc: have putc use the TXFIFO
> > > >
> > > >  drivers/serial/serial_mxc.c | 13 -
> > > >  1 file changed, 12 insertions(+), 1 deletion(-)
> > >
> > > Hello! I'm really not maintainer of mxc and I do not have time to review
> > > those patches. So please do not send me them as I'm spammed with tons of
> > > unrelated emails/patches.
> >
> > Then there is a problem with having your name as a maintainer for this file.
> >
> > If I execute:
> > $ ./scripts/get_maintainer.pl drivers/serial/serial_mxc.c
> > "Pali Rohár" 
> (commit_signer:1/1=100%,authored:1/1=100%,added_lines:2/2=100%,removed_lines:2/2=
> 100%)
> > u-boot@lists.denx.de (open list)
> >
> > I guess this has to be corrected then, right?
> >
> > Regards,
> > Andrey
> 
> Yes, please correct it. I have not added myself to the list of mxc
> maintainers and I a really do not have time for reviewing mxc patches.

I cannot modify this part since removing you from maintainer list would
require a transfer of maintainership of this component to another name,
which I do not know.

I've Cc:'d Tom and people from imx world here so they can make a decision
on who shall continue the maintenance of this file when your entry is removed.

-- andrey

RE: [PATCH v1 0/2] serial_mxc: fixing reception

[ZHIZHIKIN Andrey]

Hello Pali,

> -Original Message-
> From: U-Boot  On Behalf Of Pali Rohar
> Sent: Monday, September 5, 2022 10:59 AM
> To: u-boot@lists.denx.de
> Subject: Re: [PATCH v1 0/2] serial_mxc: fixing reception
> 
> On Monday 05 September 2022 10:53:58 Johannes Schneider wrote:
> > while writing to a imx-serial device is probably thoroughly tested - and
> obviosly works for the debug-serial - using a serial driver to read data 
> received
> over the serial interface does not work reliably.
> >
> > the patches in this series address issues found during the implementation 
> > of a
> custom uboot-command to query a coprocessor, connected to an imx8mm over 
> uart4,
> for mainboard-identification strings
> >
> >
> > Johannes Schneider (2):
> >   serial: mxc: enable the RX pipeline
> >   serial: mxc: have putc use the TXFIFO
> >
> >  drivers/serial/serial_mxc.c | 13 -
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> Hello! I'm really not maintainer of mxc and I do not have time to review
> those patches. So please do not send me them as I'm spammed with tons of
> unrelated emails/patches.

Then there is a problem with having your name as a maintainer for this file.

If I execute:
$ ./scripts/get_maintainer.pl drivers/serial/serial_mxc.c
"Pali Rohár"  
(commit_signer:1/1=100%,authored:1/1=100%,added_lines:2/2=100%,removed_lines:2/2=100%)
u-boot@lists.denx.de (open list)

I guess this has to be corrected then, right?

Regards,
Andrey

RE: [PATCH] imx8mm: Sync device tree with linux-next 20220711

[ZHIZHIKIN Andrey]

Hello Fabio,

> -Original Message-
> From: U-Boot  On Behalf Of Fabio Estevam
> Sent: Friday, July 15, 2022 6:57 PM
> To: sba...@denx.de
> Cc: andrey.zhizhi...@leica-geosystems.com; u-boot@lists.denx.de; uboot-
> i...@nxp.com; gaurav.j...@nxp.com; Fabio Estevam 
> Subject: [PATCH] imx8mm: Sync device tree with linux-next 20220711
> 
> From: Fabio Estevam 
> 
> Sync imx8mm.dtsi device tree with linux-next 20220711.
> 
> The main motivation for doing this sync is the sha256 regression
> reported by Andrey Zhizhikin [1].
> 

First of, thanks a lot for the quick response and the patch!

While this solves the SHA computations for i.MX8MM, I just tested and
confirmed that the same issue persists on i.MX8MN and i.MX8MP as well...

It looks like the same is required for all other derivatives of i.MX8M
family which have CAAM enables by default...

> The linux-next kernel has the following commit, which disables
> the job ring 0 and fixes the problem:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-
> next.git/commit/?h=next-20220715=dc9c1ceb555ff661e6fc1081434600771f29657c
> 
> [1] https://lore.kernel.org/u-
> boot/am6pr06mb46912207d9460cd9924f35daa6...@am6pr06mb4691.eurprd06.prod.outlook.c
> om/T/#t
> 
> Signed-off-by: Fabio Estevam 
> ---
>  arch/arm/dts/imx8mm.dtsi | 653 ---
>  include/dt-bindings/power/imx8mm-power.h |   9 +
>  2 files changed, 456 insertions(+), 206 deletions(-)
> 
> diff --git a/arch/arm/dts/imx8mm.dtsi b/arch/arm/dts/imx8mm.dtsi
> index 724f6ddbf397..afb90f59c83c 100644
> --- a/arch/arm/dts/imx8mm.dtsi
> +++ b/arch/arm/dts/imx8mm.dtsi
> @@ -4,11 +4,11 @@
>   */
> 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
> 
>  #include "imx8mm-pinfunc.h"
> @@ -65,6 +65,12 @@
>   clock-latency = <61036>; /* two CLK32 periods */
>   clocks = < IMX8MM_CLK_ARM>;
>   enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
>   next-level-cache = <_L2>;
>   operating-points-v2 = <_opp_table>;
>   nvmem-cells = <_speed_grade>;
> @@ -80,6 +86,12 @@
>   clock-latency = <61036>; /* two CLK32 periods */
>   clocks = < IMX8MM_CLK_ARM>;
>   enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
>   next-level-cache = <_L2>;
>   operating-points-v2 = <_opp_table>;
>   cpu-idle-states = <_pd_wait>;
> @@ -93,6 +105,12 @@
>   clock-latency = <61036>; /* two CLK32 periods */
>   clocks = < IMX8MM_CLK_ARM>;
>   enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
>   next-level-cache = <_L2>;
>   operating-points-v2 = <_opp_table>;
>   cpu-idle-states = <_pd_wait>;
> @@ -106,6 +124,12 @@
>   clock-latency = <61036>; /* two CLK32 periods */
>   clocks = < IMX8MM_CLK_ARM>;
>   enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
>   next-level-cache = <_L2>;
>   operating-points-v2 = <_opp_table>;
>   cpu-idle-states = <_pd_wait>;
> @@ -114,6 +138,10 @@
> 
>   A53_L2: l2-cache0 {
>   compatible = "cache";
> + cache-level = <2>;
> + cache-size = <0x8>;
> + cache-line-size = <64>;
> + cache-sets = <512>;
>   };
>   };
> 
> @@ -184,7 +212,7 @@
>   clk_ext4: clock-ext4 {
>   compatible = "fixed-clock";
>   #clock-cells = <0>;
> - clock-frequency= <13300>;
> + clock-frequency = <13300>;
>   clock-output-names = 

RE: [EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on imx8m series with CAAM enabled

[ZHIZHIKIN Andrey]

Hello Gaurav,

Cc: Tom here for integration points.

> -Original Message-
> From: U-Boot  On Behalf Of Gaurav Jain
> Sent: Friday, July 15, 2022 4:01 PM
> To: ZHIZHIKIN Andrey 
> Cc: u-boot@lists.denx.de; feste...@denx.de; sba...@denx.de; Michael Walle
> ; Tommaso Merciai ;
> Michael Trimarchi ; Marek Vasut ;
> Simon Glass ; Patrick Delaunay 
> ;
> Stefan Roese ; Horia Geanta ; Pankaj Gupta
> ; Varun Sethi ; Ye Li ; 
> dl-
> uboot-imx 
> Subject: RE: [EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on imx8m 
> series
> with CAAM enabled
> 
> Hello Andrey
> 
> Right now I am not sure what could cause the issue.
> As per our previous discussions, JR0 can not be used in uboot, so you need to
> mark it as disabled until kernel device tree is not sync.

Actually, I've given this a try by setting `status = "disabled"` in sec_jr0 
node,
and then the hash calculation was working again!

This has puzzled me a lot, since JR ID used to enqueue the SHA hashing 
descriptor
is hard-coded to `0`, see the [1] for code reference. I was expecting that the
call would fail but it somehow worked, perhaps by picking up the JR which is not
disabled (JR1?)...

This is a bit that needs more explanation, perhaps you can shed some light here
on how this JR assignments are working in case when nodes are enabled/disabled?


Stefano/Tom,

From what I can see, since patch from Fabio [2] is planned for inclusion to
linux-5.20.y (see [3] for PR) - it might be that the SHA computation will stay
broken on i.MX8M derivatives until v2022.10 at least, or the HW hash
computations are replaced with SW alternative until the JR configuration is
not synced into U-Boot.

Any advice on how to proceed here? I guess this would affect some people who are
relying on FIT boot via `bootm`...

> To debug more, can you run hash command with HASH_VERIFY.

This did not solve the problem when JR0 node was still enabled, and had no 
effect
when I disabled the node.

> 
> Regards
> Gaurav Jain
> 
> > -Original Message-
> > From: ZHIZHIKIN Andrey 
> > Sent: Friday, July 15, 2022 7:04 PM
> > To: Gaurav Jain 
> > Cc: u-boot@lists.denx.de; feste...@denx.de; sba...@denx.de; Michael
> > Walle ; Tommaso Merciai
> > ; Michael Trimarchi
> > ; Marek Vasut ; Simon
> > Glass ; Patrick Delaunay
> > ; Stefan Roese ; Horia Geanta
> > ; Pankaj Gupta ; Varun
> > Sethi ; Ye Li ; dl-uboot-imx  > i...@nxp.com>
> > Subject: RE: [EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on imx8m
> > series with CAAM enabled
> >
> > Caution: EXT Email
> >
> > Hello Gaurav,
> >
> > > -Original Message-
> > > From: U-Boot  On Behalf Of Gaurav Jain
> > > Sent: Friday, July 15, 2022 2:56 PM
> > > To: ZHIZHIKIN Andrey 
> > > Cc: u-boot@lists.denx.de; feste...@denx.de; sba...@denx.de; Michael
> > > Walle ; Tommaso Merciai
> > > ;
> > > Michael Trimarchi ; Marek Vasut
> > > ; Simon Glass ; Patrick Delaunay
> > > ; Stefan Roese ; Horia
> > > Geanta ; Pankaj Gupta ;
> > > Varun Sethi ; Ye Li ; dl- uboot-imx
> > > 
> > > Subject: RE: [EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on
> > > imx8m series with CAAM enabled
> > >
> > > Hello Andrey
> > >
> > > There is a patch in review related caam hash.
> > > Please check if it fixes your problem.
> > > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
> > >
> > work.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F20220616101009.809953-
> > 1-
> > >
> > mp;data=05%7C01%7Cgaurav.jain%40nxp.com%7C4e78116cfe2b4487fdc208
> > da
> > >
> > aa79%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637934888408
> > 633266%7
> > >
> > CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
> > TiI6Ik1
> > >
> > haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Dwe%2FOgeLeH
> > mWD7tKcmmJbV
> > > %2F0D5cOZvH3kpCx%2FO%2FvMRg%3Dreserved=0
> > > gaurav.j...@nxp.com/
> >
> > No, unfortunately this patch did not solve the issue, behavior is still the
> same.
> >
> > >
> > > Regards
> > > Gaurav Jain
> > >
> > > > -Original Message-
> > > > From: ZHIZHIKIN Andrey 
> > > > Sent: Friday, July 15, 2022 6:11 PM
> > > > To: Gaurav Jain 
> > > > Cc: u-boot@lists.denx.de; feste...@denx.de; sba...@denx.de; Michael
> > > > Walle ; Tommaso Merciai
> > > > ; Michael Trimarchi
> > > > ; Marek Vasut ;
> > Simon
> > > > Glass ; Patrick Delaunay
> >

RE: [EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on imx8m series with CAAM enabled

[ZHIZHIKIN Andrey]

Hello Gaurav,

> -Original Message-
> From: U-Boot  On Behalf Of Gaurav Jain
> Sent: Friday, July 15, 2022 2:56 PM
> To: ZHIZHIKIN Andrey 
> Cc: u-boot@lists.denx.de; feste...@denx.de; sba...@denx.de; Michael Walle
> ; Tommaso Merciai ;
> Michael Trimarchi ; Marek Vasut ;
> Simon Glass ; Patrick Delaunay 
> ;
> Stefan Roese ; Horia Geanta ; Pankaj Gupta
> ; Varun Sethi ; Ye Li ; 
> dl-
> uboot-imx 
> Subject: RE: [EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on imx8m 
> series
> with CAAM enabled
> 
> Hello Andrey
> 
> There is a patch in review related caam hash.
> Please check if it fixes your problem.
> http://patchwork.ozlabs.org/project/uboot/patch/20220616101009.809953-1-
> gaurav.j...@nxp.com/

No, unfortunately this patch did not solve the issue, behavior is still the 
same.

> 
> Regards
> Gaurav Jain
> 
> > -Original Message-
> > From: ZHIZHIKIN Andrey 
> > Sent: Friday, July 15, 2022 6:11 PM
> > To: Gaurav Jain 
> > Cc: u-boot@lists.denx.de; feste...@denx.de; sba...@denx.de; Michael
> > Walle ; Tommaso Merciai
> > ; Michael Trimarchi
> > ; Marek Vasut ; Simon
> > Glass ; Patrick Delaunay
> > ; Stefan Roese ; Horia Geanta
> > ; Pankaj Gupta ; Varun
> > Sethi ; Ye Li ; dl-uboot-imx  > i...@nxp.com>
> > Subject: [EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on imx8m
> > series with CAAM enabled
> >
> > Caution: EXT Email
> >
> > Hello Gaurav,
> >
> > In the new v2022.07, I've stumbled upon the issue with calculating the
> > SHA256 of memory blocks with CAAM hashing. This causes the FIT image not
> > to pass the hash validation, and also `sha256` command not operable.
> >
> > I'm also wondering if any i.MX8M-based board maintainers have seen the
> > same issues at their end?
> >
> > I've made a small test executing the following command sequence (with
> > corresponding serial output):
> >
> > U-Boot 2022.07 (Jul 15 2022 - 14:36:00 +0200)
> >
> > CPU:   Freescale i.MX8MMQ rev1.0 at 1200 MHz
> > Reset cause: POR
> > Model: FSL i.MX8MM EVK board
> > DRAM:  2 GiB
> > Core:  153 devices, 19 uclasses, devicetree: separate
> > WDT:   Started watchdog@3028 with servicing (60s timeout)
> > MMC:   FSL_SDHC: 1, FSL_SDHC: 2
> > Loading Environment from MMC... *** Warning - bad CRC, using default
> > environment
> >
> > In:serial@3089
> > Out:   serial@3089
> > Err:   serial@3089
> > SEC0:  RNG instantiated
> > Net:   eth0: ethernet@30be
> > Hit any key to stop autoboot:  0
> > u-boot=> mw.b ${kernel_addr_r} DE 100
> > u-boot=> md.b ${kernel_addr_r} 100
> > 4048: dededede dededede dededede dededede  
> > 40480010: dededede dededede dededede dededede  
> > 40480020: dededede dededede dededede dededede  
> > 40480030: dededede dededede dededede dededede  
> > 40480040: dededede dededede dededede dededede  
> > 40480050: dededede dededede dededede dededede  
> > 40480060: dededede dededede dededede dededede  
> > 40480070: dededede dededede dededede dededede  
> > 40480080: dededede dededede dededede dededede  
> > 40480090: dededede dededede dededede dededede  
> > 404800a0: dededede dededede dededede dededede  
> > 404800b0: dededede dededede dededede dededede  
> > 404800c0: dededede dededede dededede dededede  
> > 404800d0: dededede dededede dededede dededede  
> > 404800e0: dededede dededede dededede dededede  
> > 404800f0: dededede dededede dededede dededede  
> >
> > u-boot=> hash sha256 ${kernel_addr_r} 100 CAAM was not setup properly or
> > it is faulty
> > sha256 for 4048 ... 404800ff ==>
> > 736372697074616464727d0a626f6f745f6566695f62696e6172793d6c6f6164
> >
> > Running `sha256` commands several times in a row also produces different
> > Results, sometimes it comes out as all 0's.
> >
> > For comparison purposes, I've did similar on the desktop:
> > $ while true ; do printf "\xDE"; done | dd of=./test_data bs=1 count=256
> > 256+0 records in
> > 256+0 records out
> > 256 bytes copied, 0.000484 s, 529 kB/s
> >
> > $ hexdump -C -v ./test_data
> >   de de de de de de de de  de de de de de de de de  
> > ||
> > 0010  de de de de de de de de  de de de de de de de de

[REGRESSION]: v2022.07: SHA256 hash is broken on imx8m series with CAAM enabled

[ZHIZHIKIN Andrey]

Hello Gaurav,

In the new v2022.07, I've stumbled upon the issue with calculating the SHA256 of
memory blocks with CAAM hashing. This causes the FIT image not to pass the hash
validation, and also `sha256` command not operable.

I'm also wondering if any i.MX8M-based board maintainers have seen the same 
issues
at their end?

I've made a small test executing the following command sequence (with 
corresponding
serial output):

U-Boot 2022.07 (Jul 15 2022 - 14:36:00 +0200)

CPU:   Freescale i.MX8MMQ rev1.0 at 1200 MHz
Reset cause: POR
Model: FSL i.MX8MM EVK board
DRAM:  2 GiB
Core:  153 devices, 19 uclasses, devicetree: separate
WDT:   Started watchdog@3028 with servicing (60s timeout)
MMC:   FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:serial@3089
Out:   serial@3089
Err:   serial@3089
SEC0:  RNG instantiated
Net:   eth0: ethernet@30be
Hit any key to stop autoboot:  0
u-boot=> mw.b ${kernel_addr_r} DE 100
u-boot=> md.b ${kernel_addr_r} 100
4048: dededede dededede dededede dededede  
40480010: dededede dededede dededede dededede  
40480020: dededede dededede dededede dededede  
40480030: dededede dededede dededede dededede  
40480040: dededede dededede dededede dededede  
40480050: dededede dededede dededede dededede  
40480060: dededede dededede dededede dededede  
40480070: dededede dededede dededede dededede  
40480080: dededede dededede dededede dededede  
40480090: dededede dededede dededede dededede  
404800a0: dededede dededede dededede dededede  
404800b0: dededede dededede dededede dededede  
404800c0: dededede dededede dededede dededede  
404800d0: dededede dededede dededede dededede  
404800e0: dededede dededede dededede dededede  
404800f0: dededede dededede dededede dededede  

u-boot=> hash sha256 ${kernel_addr_r} 100
CAAM was not setup properly or it is faulty
sha256 for 4048 ... 404800ff ==> 
736372697074616464727d0a626f6f745f6566695f62696e6172793d6c6f6164

Running `sha256` commands several times in a row also produces different
Results, sometimes it comes out as all 0's.

For comparison purposes, I've did similar on the desktop:
$ while true ; do printf "\xDE"; done | dd of=./test_data bs=1 count=256
256+0 records in
256+0 records out
256 bytes copied, 0.000484 s, 529 kB/s

$ hexdump -C -v ./test_data
  de de de de de de de de  de de de de de de de de  ||
0010  de de de de de de de de  de de de de de de de de  ||
0020  de de de de de de de de  de de de de de de de de  ||
0030  de de de de de de de de  de de de de de de de de  ||
0040  de de de de de de de de  de de de de de de de de  ||
0050  de de de de de de de de  de de de de de de de de  ||
0060  de de de de de de de de  de de de de de de de de  ||
0070  de de de de de de de de  de de de de de de de de  ||
0080  de de de de de de de de  de de de de de de de de  ||
0090  de de de de de de de de  de de de de de de de de  ||
00a0  de de de de de de de de  de de de de de de de de  ||
00b0  de de de de de de de de  de de de de de de de de  ||
00c0  de de de de de de de de  de de de de de de de de  ||
00d0  de de de de de de de de  de de de de de de de de  ||
00e0  de de de de de de de de  de de de de de de de de  ||
00f0  de de de de de de de de  de de de de de de de de  ||
0100

$ sha256sum ./test_data
8b11bcdc65d5f1af0fa1edfa7b5db089dba40d4e8d29b455295d58ab2b314e76  ./test_data

As one can see, the SHA256 has a totally different value, with desktop
produces a rather correct one.

Since the CAAM is enabled per default for all i.MX8M derivatives, there is no
way to target SHA hash calculations back to SW implementation, therefore it
blocks a lot of people to boot FIT images that has `hash` nodes in them.

Looking a bit deeper into why it fails, I saw that the JR used for hash
calculations is hard-coded to `0` in run_descriptor_jr() call, which is now
reserved in S-World for HAB operations. But changing it to `1` did not change
the behavior, the SHA256 is still not calculated proper.

Can you please advise how this can be solved?

And more conceptually: why is SHA hashing now hardwired to HW CAAM module,
while it was perfectly executed in SW via `lib/sha.c`?

Thanks a lot!

Regards,
Andrey

RE: [PATCH v4 1/7] tools: mkimage: Add support to generate FlexSPI Header for i.MX8m

[ZHIZHIKIN Andrey]

Hello Mamta,

> -Original Message-
> From: Mamta Shukla 
> Sent: Thursday, July 7, 2022 2:45 PM
> To: u-boot@lists.denx.de
> Cc: sba...@denx.de; peng@nxp.com; aford...@gmail.com; GEO-CHHER-bsp-
> development ; feste...@denx.de; 
> SHUKLA
> Mamta Ramendra ; HAEMMERLE Thomas
> 
> Subject: [PATCH v4 1/7] tools: mkimage: Add support to generate FlexSPI Header
> for i.MX8m
> 
> Add struct with Flex SPI Configuration Block and enable generating
> fspi header using mkimage.
> 
> Refer i.MX 8M Mini Application Processor Reference Manual for
> detailed information about parameters for FlexSPI Configuration block.
> 
> Signed-off-by: Mamta Shukla 
> Signed-off-by: Thomas Haemmerle 
> Tested-by: Adam Ford 
> Reviewed-by: Fabio Estevam 
> ---
> v2:
> -Add check for error in case open() for fspi_fd in imx8mkimage.c fails
> 
> v3:
> -No changes
> 
> v4:
> -No changes
> 
>  include/imximage.h | 38 ++
>  tools/Kconfig  | 59 +
>  tools/imx8mimage.c | 81 +++---
>  3 files changed, 174 insertions(+), 4 deletions(-)
> 
> diff --git a/include/imximage.h b/include/imximage.h
> index 5a812f5a10..c1ecc0b7cb 100644
> --- a/include/imximage.h
> +++ b/include/imximage.h
> @@ -201,6 +201,44 @@ struct imx_header {
>   } header;
>  };
> 
> +typedef struct {
> + uint8_t tag[4];
> + uint8_t version[4];
> + uint8_t reserved_1[4];
> + uint8_t read_sample;
> + uint8_t datahold;
> + uint8_t datasetup;
> + uint8_t coladdrwidth;
> + uint8_t devcfgenable;
> + uint8_t reserved_2[3];
> + uint8_t devmodeseq[4];
> + uint8_t devmodearg[4];
> + uint8_t cmd_enable;
> + uint8_t reserved_3[3];
> + uint8_t cmd_seq[16] ;
> + uint8_t cmd_arg[16];
> + uint8_t controllermisc[4];
> + uint8_t dev_type;
> + uint8_t sflash_pad;
> + uint8_t serial_clk;
> + uint8_t lut_custom ;
> + uint8_t reserved_4[8];
> + uint8_t sflashA1[4];
> + uint8_t sflashA2[4];
> + uint8_t sflashB1[4];
> + uint8_t sflashB2[4];
> + uint8_t cspadover[4];
> + uint8_t sclkpadover[4];
> + uint8_t datapadover[4];
> + uint8_t dqspadover[4];
> + uint8_t timeout[4];
> + uint8_t commandInt[4];
> + uint8_t datavalid[4];
> + uint8_t busyoffset[2];
> + uint8_t busybitpolarity[2];
> + uint8_t lut[256];
> +} __attribute__((packed)) fspi_conf;
> +
>  typedef void (*set_dcd_val_t)(struct imx_header *imxhdr,
>   char *name, int lineno,
>   int fld, uint32_t value,
> diff --git a/tools/Kconfig b/tools/Kconfig
> index 117c921da3..539708f277 100644
> --- a/tools/Kconfig
> +++ b/tools/Kconfig
> @@ -98,4 +98,63 @@ config TOOLS_MKEFICAPSULE
> optionally sign that file. If you want to enable UEFI capsule
> update feature on your target, you certainly need this.
> 
> +menuconfig FSPI_CONF_HEADER
> + bool "FlexSPI Header Configuration"
> + help
> +   FSPI Header Configuration
> +
> +config FSPI_CONF_FILE
> + string "FlexSPI Header File"
> + depends on FSPI_CONF_HEADER
> + help
> +   FlexSPI Header File name
> +
> +config READ_CLK_SOURCE
> + hex "Sampling Clock Source"
> + default 0x00
> + depends on FSPI_CONF_HEADER
> + help
> +   Sample Clock source for Flash, default is internal loopback clock
> +
> +config DEVICE_TYPE
> + hex "Flash Type"
> + default 0x01
> + depends on FSPI_CONF_HEADER
> + help
> +   Flash type: Serial NOR (0X01) and Serial NAND (0x02)
> +
> +config FLASH_PAD_TYPE
> + hex "Flash Pad Type"
> + default 0x01
> + depends on FSPI_CONF_HEADER
> + help
> +   Flash Pad type :
> +   Single Pad 0x01
> +   Dual Pads  0x02
> +   Quad Pad   0x04
> +   Octal Pad  0x08
> +
> +config SERIAL_CLK_FREQUENCY
> + hex "Serial Clock Frequency"
> + default 0x02
> + depends on FSPI_CONF_HEADER
> + help
> +   Chip specific frequency: other value 30MHz
> +   1-30MHz  2-50MHz 3-60MHz 4-75MHz 5-80MHz 6-100MHz 7-133MHz 8-166MHz
> +
> +config LUT_CUSTOM_SEQUENCE
> + hex "Enable Custom Look Up Table(LUT) Sequence"
> + default 0x00
> + depends on FSPI_CONF_HEADER
> + help
> +   0 - Use predefined LUT Sequence
> +   1 - Use LUT Sequence provided
> +
> +config LUT_SEQUENCE
> + string "Look Up Table Sequence"
> + default "0x0b, 0x04, 0x18, 0x08, 0x08, 0x30, 0x04, 0x24"
> + depends on FSPI_CONF_HEADER
> + help
> +   Look Up Table Sequence
> +
>  endmenu
> diff --git a/tools/imx8mimage.c b/tools/imx8mimage.c
> index 4eed683396..facf8887a1 100644
> --- a/tools/imx8mimage.c
> +++ b/tools/imx8mimage.c
> @@ -12,7 +12,7 @@
>  #include "compiler.h"
> 
>  static uint32_t ap_start_addr, sld_start_addr, sld_src_off;
> -static char *ap_img, *sld_img, *signed_hdmi;
> +static char *ap_img, *sld_img, *signed_hdmi, *fspi;
>  static 

RE: [PATCH v4 3/7] configs: Add config for enabling FSPI boot option for i.MX8m

[ZHIZHIKIN Andrey]

Hello Mamta,

> -Original Message-
> From: Mamta Shukla 
> Sent: Thursday, July 7, 2022 2:45 PM
> To: u-boot@lists.denx.de
> Cc: sba...@denx.de; peng@nxp.com; aford...@gmail.com; GEO-CHHER-bsp-
> development ; feste...@denx.de; 
> SHUKLA
> Mamta Ramendra ; HAEMMERLE Thomas
> 
> Subject: [PATCH v4 3/7] configs: Add config for enabling FSPI boot option for
> i.MX8m
> 
> Add imx8mm_evk_fspi_defconfig to build QSPI boot image.
> This config is based on imx8mm_evk_defconfig with addtional config options for
> FSPI Header,SPL offset and imx-image config to boot from FSPI.
> 
> Signed-off-by: Mamta Shukla 
> Signed-off-by: Thomas Haemmerle 
> Tested-by: Adam Ford 
> Reviewed-by: Fabio Estevam 
> ---
> v2:
> -Remove extra line in commit message
> -Remove extra line in imx8mm_evk_fspi_defconfig
> -New patch in series to add an entry for imx8mm_evk_fspi_defconfig in
> board/freescale/imx8mm_evk/MAINTAINERS
> 
> v3:
> -No changes
> 
> v4:
> -No changes
> 
>  .../imx8mm_evk/imximage-8mm-lpddr4-fspi.cfg   |   9 ++
>  configs/imx8mm_evk_fspi_defconfig | 115 ++
>  2 files changed, 124 insertions(+)
>  create mode 100644 board/freescale/imx8mm_evk/imximage-8mm-lpddr4-fspi.cfg
>  create mode 100644 configs/imx8mm_evk_fspi_defconfig
> 
> diff --git a/board/freescale/imx8mm_evk/imximage-8mm-lpddr4-fspi.cfg
> b/board/freescale/imx8mm_evk/imximage-8mm-lpddr4-fspi.cfg
> new file mode 100644
> index 00..ddcbd11eea
> --- /dev/null
> +++ b/board/freescale/imx8mm_evk/imximage-8mm-lpddr4-fspi.cfg
> @@ -0,0 +1,9 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright 2021 NXP
> + */
> +
> +#define __ASSEMBLY__

Usage of __ASSEMBLY__ has been dropped in commit 5c86a8f7a191 ("imx: Don't 
define __ASSEMBLY__ in source files"), therefore build produces the warning. 
Please remove this one.

> +
> +BOOT_FROMfspi
> +LOADER   u-boot-spl-ddr.bin  0x7E2000
> diff --git a/configs/imx8mm_evk_fspi_defconfig
> b/configs/imx8mm_evk_fspi_defconfig
> new file mode 100644
> index 00..50f6e4779b
> --- /dev/null
> +++ b/configs/imx8mm_evk_fspi_defconfig

New config file needs a re-sync to what is included on the master, specifically 
those 2 commits from Tom:
d46e86d25c2a ("configs: Resync with savedefconfig")
bfdb30559c76 ("configs: Resync with savedefconfig")

> @@ -0,0 +1,115 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_IMX8M=y
> +CONFIG_SYS_TEXT_BASE=0x4020
> +CONFIG_SYS_MALLOC_LEN=0x200
> +CONFIG_SPL_GPIO=y
> +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> +CONFIG_ENV_SIZE=0x1000
> +CONFIG_ENV_OFFSET=0x40
> +CONFIG_DM_GPIO=y
> +CONFIG_DEFAULT_DEVICE_TREE="imx8mm-evk"
> +CONFIG_SPL_TEXT_BASE=0x7E2000
> +CONFIG_TARGET_IMX8MM_EVK=y
> +CONFIG_IMX_CONFIG="board/freescale/imx8mm_evk/imximage-8mm-lpddr4-fspi.cfg"
> +CONFIG_SPL_NOR_SUPPORT=y
> +CONFIG_SPL_SERIAL_SUPPORT=y
> +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
> +CONFIG_SPL_MMC=y
> +CONFIG_SPL_SERIAL=y
> +CONFIG_SPL_DRIVERS_MISC=y
> +CONFIG_SPL=y
> +CONFIG_SYS_LOAD_ADDR=0x4048
> +CONFIG_DISTRO_DEFAULTS=y
> +CONFIG_FIT=y
> +CONFIG_FIT_EXTERNAL_OFFSET=0x3000
> +CONFIG_SPL_LOAD_FIT=y
> +# CONFIG_USE_SPL_FIT_GENERATOR is not set
> +CONFIG_OF_SYSTEM_SETUP=y
> +CONFIG_BOARD_EARLY_INIT=y
> +CONFIG_BOARD_LATE_INIT=y
> +CONFIG_SPL_BOARD_INIT=y
> +CONFIG_SPL_SEPARATE_BSS=y
> +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
> +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x300
> +CONFIG_SPL_I2C=y
> +CONFIG_SPL_POWER=y
> +CONFIG_SPL_WATCHDOG=y
> +CONFIG_SYS_PROMPT="u-boot=> "
> +# CONFIG_CMD_EXPORTENV is not set
> +# CONFIG_CMD_IMPORTENV is not set
> +# CONFIG_CMD_CRC32 is not set
> +CONFIG_CMD_CLK=y
> +CONFIG_CMD_FUSE=y
> +CONFIG_CMD_GPIO=y
> +CONFIG_CMD_I2C=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_CACHE=y
> +CONFIG_CMD_REGULATOR=y
> +CONFIG_CMD_EXT4_WRITE=y
> +CONFIG_OF_CONTROL=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_ENV_OVERWRITE=y
> +CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_SYS_MMC_ENV_DEV=1
> +CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> +CONFIG_USE_ETHPRIME=y
> +CONFIG_ETHPRIME="FEC"
> +CONFIG_SPL_DM=y
> +CONFIG_SPL_CLK_COMPOSITE_CCF=y
> +CONFIG_CLK_COMPOSITE_CCF=y
> +CONFIG_SPL_CLK_IMX8MM=y
> +CONFIG_CLK_IMX8MM=y
> +CONFIG_MXC_GPIO=y
> +CONFIG_DM_I2C=y
> +CONFIG_DM_MMC=y
> +CONFIG_SUPPORT_EMMC_BOOT=y
> +CONFIG_MMC_IO_VOLTAGE=y
> +CONFIG_MMC_UHS_SUPPORT=y
> +CONFIG_MMC_HS400_ES_SUPPORT=y
> +CONFIG_MMC_HS400_SUPPORT=y
> +CONFIG_FSL_USDHC=y
> +CONFIG_PHYLIB=y
> +CONFIG_PHY_ATHEROS=y
> +CONFIG_DM_ETH=y
> +CONFIG_PHY_GIGE=y
> +CONFIG_FEC_MXC=y
> +CONFIG_MII=y
> +CONFIG_PINCTRL=y
> +CONFIG_SPL_PINCTRL=y
> +CONFIG_PINCTRL_IMX8M=y
> +CONFIG_DM_PMIC=y
> +CONFIG_SPL_DM_PMIC_PCA9450=y
> +CONFIG_DM_REGULATOR=y
> +CONFIG_DM_REGULATOR_FIXED=y
> +CONFIG_DM_REGULATOR_GPIO=y
> +CONFIG_DM_PWM=y
> +CONFIG_DM_SERIAL=y
> +CONFIG_PWM_IMX=y
> +CONFIG_MXC_UART=y
> +CONFIG_SYSRESET=y
> +CONFIG_SPL_SYSRESET=y
> +CONFIG_SYSRESET_PSCI=y
> +CONFIG_SYSRESET_WATCHDOG=y
> +CONFIG_DM_THERMAL=y
> +CONFIG_IMX_WATCHDOG=y
> 

RE: [PATCH] clk: imx8mp: Fix 32k clock name

[ZHIZHIKIN Andrey]

Hello Marek,

> -Original Message-
> From: U-Boot  On Behalf Of Marek Vasut
> Sent: Monday, June 13, 2022 3:22 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Fabio Estevam ; Peng Fan
> ; Stefano Babic 
> Subject: [PATCH] clk: imx8mp: Fix 32k clock name
> 
> The 32 kHz oscillator clock name is 'clock-osc-32k' instead of 'osc_32k'.
> Fix the name to prevent the following warning:
> 
> "
> clk_register: failed to get osc_32k device (parent of usb_root_clk)
> "
> 
> Fixes: 7a2c3be95a5 ("clk: imx8mp: Fill in DWC3 USB, USB PHY, HSIOMIX clock")
> Signed-off-by: Marek Vasut 
> Cc: Fabio Estevam 
> Cc: Peng Fan 
> Cc: Stefano Babic 

I've already submitted a series to address this issue and the one for
ECSPI clocks, see [1].

You're also on Cc: to that series, so you can take a look at it and
decide whether it is suitable or not.

> ---
>  drivers/clk/imx/clk-imx8mp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
> index cbed86a6843..9c7857bbb3a 100644
> --- a/drivers/clk/imx/clk-imx8mp.c
> +++ b/drivers/clk/imx/clk-imx8mp.c
> @@ -300,7 +300,7 @@ static int imx8mp_clk_probe(struct udevice *dev)
>   clk_dm(IMX8MP_CLK_UART2_ROOT, imx_clk_gate4("uart2_root_clk", "uart2",
> base + 0x44a0, 0));
>   clk_dm(IMX8MP_CLK_UART3_ROOT, imx_clk_gate4("uart3_root_clk", "uart3",
> base + 0x44b0, 0));
>   clk_dm(IMX8MP_CLK_UART4_ROOT, imx_clk_gate4("uart4_root_clk", "uart4",
> base + 0x44c0, 0));
> - clk_dm(IMX8MP_CLK_USB_ROOT, imx_clk_gate4("usb_root_clk", "osc_32k", 
> base
> + 0x44d0, 0));
> + clk_dm(IMX8MP_CLK_USB_ROOT, imx_clk_gate4("usb_root_clk", 
> "clock-osc-32k",
> base + 0x44d0, 0));
>   clk_dm(IMX8MP_CLK_USB_PHY_ROOT, imx_clk_gate4("usb_phy_root_clk",
> "usb_phy_ref", base + 0x44f0, 0));
>   clk_dm(IMX8MP_CLK_USDHC1_ROOT, imx_clk_gate4("usdhc1_root_clk", 
> "usdhc1",
> base + 0x4510, 0));
>   clk_dm(IMX8MP_CLK_USDHC2_ROOT, imx_clk_gate4("usdhc2_root_clk", 
> "usdhc2",
> base + 0x4520, 0));
> --
> 2.35.1

-- andrey

Link: [1]: 
https://lore.kernel.org/u-boot/20220603151522.6643-1-andrey.zhizhi...@leica-geosystems.com/

RE: [EXT] RE: [PATCH] i.MX8M: crypto: disable JR0 in SPL, U-Boot

[ZHIZHIKIN Andrey]

Hello Gaurav,

> -Original Message-
> From: U-Boot  On Behalf Of Gaurav Jain
> Sent: Thursday, June 9, 2022 3:13 PM
> To: ZHIZHIKIN Andrey ; u-
> b...@lists.denx.de; Stefano Babic ; Fabio Estevam
> ; Tommaso Merciai ;
> Michael Trimarchi ; Marek Vasut ;
> Simon Glass ; Patrick Delaunay 
> ;
> Stefan Roese ; Horia Geanta ; Pankaj Gupta
> ; Varun Sethi ; Ye Li ;
> Michael Walle 
> Cc: dl-uboot-imx 
> Subject: RE: [EXT] RE: [PATCH] i.MX8M: crypto: disable JR0 in SPL, U-Boot
> 
> Hello Andrey
> 
> > -Original Message-
> > From: ZHIZHIKIN Andrey 
> > Sent: Wednesday, June 8, 2022 8:31 PM
> > To: Gaurav Jain ; u-boot@lists.denx.de; Stefano Babic
> > ; Fabio Estevam ; Tommaso Merciai
> > ; Michael Trimarchi
> > ; Marek Vasut ; Simon
> > Glass ; Patrick Delaunay ;
> > Stefan Roese ; Horia Geanta ; Pankaj
> > Gupta ; Varun Sethi ; Ye Li
> > ; Michael Walle 
> > Cc: dl-uboot-imx 
> > Subject: [EXT] RE: [PATCH] i.MX8M: crypto: disable JR0 in SPL, U-Boot
> >
> > Caution: EXT Email
> >
> > Hello Gaurav,
> >
> > Cc: Michael Walle here.
> >
> > I guess this is a re-incarnation of the previous discussions we had 
> > regarding
> the
> > JR reservation, see [1].
> >
> > > -Original Message-
> > > From: Gaurav Jain 
> > > Sent: Wednesday, June 8, 2022 3:34 PM
> > > To: u-boot@lists.denx.de; Stefano Babic ; Fabio
> > > Estevam ; Tommaso Merciai
> > > ;
> > > ZHIZHIKIN Andrey ; Michael
> > > Trimarchi ; Marek Vasut ;
> > > Simon Glass ; Patrick Delaunay
> > > ; Stefan Roese ; Horia
> > > Geanta ; Pankaj Gupta ;
> > > Varun Sethi ; Ye Li 
> > > Cc: NXP i . MX U-Boot Team ; Gaurav Jain
> > > 
> > > Subject: [PATCH] i.MX8M: crypto: disable JR0 in SPL, U-Boot
> > >
> > > disabled use of JR0 in SPL and uboot, as JR0 is reserved for HAB in
> > > TF-A.
> > >
> > > Signed-off-by: Gaurav Jain 
> > > ---
> > >  arch/arm/dts/imx8mm-evk-u-boot.dtsi|  1 +
> > >  arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi   |  1 +
> > >  arch/arm/dts/imx8mp-evk-u-boot.dtsi|  1 +
> > >  arch/arm/dts/imx8mq-evk-u-boot.dtsi|  4 
> >
> > Shall those DTB changes be sync'd with Kernel?
> >
> > Now that the JR0 reservation is done in both upstream and downstream TF-A -
> > Kernel would fail to initialize the JR0.
> >
> > This is what Fabio just noted and posted as a comment. :-)
> >
> > I suggest that this is submitted into Kernel, and then picked up during the
> next
> > DTB re-sync.
> 
> Ok. Fabio has already submitted a patch for this.

Great! Then I think DTB part will not be required in this patch.

> >
> > >  arch/arm/include/asm/arch-imx8m/imx-regs.h |  1 +
> > >  drivers/crypto/fsl/jr.c| 14 +++---
> > >  scripts/config_whitelist.txt   |  1 +
> > >  7 files changed, 20 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> > > b/arch/arm/dts/imx8mm-evk-u- boot.dtsi index e9fbf7b802..8cd37b5205
> > > 100644
> > > --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> > > +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> > > @@ -74,6 +74,7 @@
> > >
> > >  _jr0 {
> > > u-boot,dm-spl;
> > > +   status = "disabled";
> > >  };
> > >
> > >  _jr1 {
> > > diff --git a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> > > b/arch/arm/dts/imx8mn-ddr4- evk-u-boot.dtsi index
> > > 4d0ecb07d4..0c31f2737a 100644
> > > --- a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> > > +++ b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> > > @@ -114,6 +114,7 @@
> > >
> > >  _jr0 {
> > > u-boot,dm-spl;
> > > +   status = "disabled";
> > >  };
> > >
> > >  _jr1 {
> > > diff --git a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> > > b/arch/arm/dts/imx8mp-evk-u- boot.dtsi index f43eb6238d..28dce55fb9
> > > 100644
> > > --- a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> > > +++ b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> > > @@ -77,6 +77,7 @@
> > >
> > >  _jr0 {
> > > u-boot,dm-spl;
> > > +   status = "disabled";
> > >  };
> > >
> > >  _jr1 {
> > > diff --git a/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> > > b/arch/arm/dts/imx8mq-evk-u- boot.dtsi index 67da6

RE: [PATCH] kontron-sl-mx8mm: Add CAAM support

[ZHIZHIKIN Andrey]

Hello Fabio,

> -Original Message-
> From: U-Boot  On Behalf Of Fabio Estevam
> Sent: Wednesday, June 8, 2022 5:04 PM
> To: sba...@denx.de
> Cc: frieder.schre...@kontron.de; u-boot@lists.denx.de; Fabio Estevam
> 
> Subject: [PATCH] kontron-sl-mx8mm: Add CAAM support
> 
> Add CAAM support, which is required when enabling HAB secure boot.
> 
> Select CONFIG_SPL_DRIVERS_MISC so that CONFIG_IMX_HAB could
> build successfully, if selected.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi | 17 +
>  arch/arm/mach-imx/imx8m/Kconfig   |  3 +++
>  board/kontron/sl-mx8mm/spl.c  |  9 +
>  configs/kontron-sl-mx8mm_defconfig|  1 +
>  4 files changed, 30 insertions(+)
> 
> diff --git a/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi 
> b/arch/arm/dts/imx8mm-
> kontron-n801x-u-boot.dtsi
> index 22d18e6f1cf8..11d915310f74 100644
> --- a/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
> @@ -25,6 +25,23 @@
>   };
>  };
> 
> + {
> + u-boot,dm-spl;
> +};
> +
> +_jr0 {
> + u-boot,dm-spl;
> + status = "disabled";

If this board is supported by upstream Kernel, then perhaps this
reservation shall be included there before, and then sync'd back
into U-Boot?

This is similar to what EVKs from NXP are undergoing now, with your
help of up-steaming Kernel DTB changes in front of U-Boot DTB ones.

> +};
> +
> +_jr1 {
> + u-boot,dm-spl;
> +};
> +
> +_jr2 {
> + u-boot,dm-spl;
> +};
> +
>   {
>   phy-mode = "rgmii-rxid";
>  };
> diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig
> index 61397bf88d13..5c59422ecb79 100644
> --- a/arch/arm/mach-imx/imx8m/Kconfig
> +++ b/arch/arm/mach-imx/imx8m/Kconfig
> @@ -106,6 +106,9 @@ config TARGET_KONTRON_MX8MM
>   select IMX8MM
>   select SUPPORT_SPL
>   select IMX8M_LPDDR4
> + select FSL_CAAM
> + select ARCH_MISC_INIT
> + select SPL_CRYPTO if SPL
> 
>  config TARGET_IMX8MN_BSH_SMM_S2
>   bool "imx8mn-bsh-smm-s2"
> diff --git a/board/kontron/sl-mx8mm/spl.c b/board/kontron/sl-mx8mm/spl.c
> index 4ef03c8c172f..5a513722c5d5 100644
> --- a/board/kontron/sl-mx8mm/spl.c
> +++ b/board/kontron/sl-mx8mm/spl.c
> @@ -13,6 +13,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -213,6 +216,12 @@ void spl_board_init(void)
>   struct udevice *dev;
>   int ret;
> 
> + if (IS_ENABLED(CONFIG_FSL_CAAM)) {
> + ret = uclass_get_device_by_driver(UCLASS_MISC,
> DM_DRIVER_GET(caam_jr), );
> + if (ret)
> + printf("Failed to initialize %s: %d\n", dev->name, ret);
> + }
> +
>   puts("Normal Boot\n");
> 
>   ret = uclass_get_device_by_name(UCLASS_CLK,
> diff --git a/configs/kontron-sl-mx8mm_defconfig b/configs/kontron-sl-
> mx8mm_defconfig
> index 2e9d52522b21..eae9ac0dbebf 100644
> --- a/configs/kontron-sl-mx8mm_defconfig
> +++ b/configs/kontron-sl-mx8mm_defconfig
> @@ -16,6 +16,7 @@ CONFIG_SPL_TEXT_BASE=0x7E1000
>  CONFIG_TARGET_KONTRON_MX8MM=y
>  CONFIG_SPL_MMC=y
>  CONFIG_SPL_SERIAL=y
> +CONFIG_SPL_DRIVERS_MISC=y
>  CONFIG_BOOTCOUNT_BOOTLIMIT=3
>  CONFIG_SPL=y
>  CONFIG_SYS_LOAD_ADDR=0x4200
> --
> 2.25.1

Regards,
Andrey

RE: [PATCH] crypto: fsl_hash: Remove unnecessary alignment check in caam_hash()

[ZHIZHIKIN Andrey]

Hello Fabio,

> -Original Message-
> From: Fabio Estevam 
> Sent: Wednesday, June 8, 2022 2:14 PM
> To: ZHIZHIKIN Andrey 
> Cc: Heiko Thiery ; Stefan Roese ; 
> U-Boot-Denx
> ; Gaurav Jain ; dullf...@yahoo.com;
> Rasmus Villemoes ; Schrempf Frieder
> ; Horia Geanta Neag ; 
> Thomas
> Schaefer ; Ye Li ; Peng Fan
> 
> Subject: Re: [PATCH] crypto: fsl_hash: Remove unnecessary alignment check in
> caam_hash()
> 
> 
> Hi Andrey,
> 
> On Wed, Jun 8, 2022 at 4:46 AM ZHIZHIKIN Andrey
>  wrote:
> 
> > > The problem seems to be related to the TF-A version.
> > >
> > > If I use the older imx_5.4.47_2.2.0 TF-A then the sha256 calculation
> > > via CAAM does not fail.
> >
> > I just tried the imx8mp_evk and with CONFIG_IMX_HAB=y the board
> > does not pass the SPL.
> >
> > I used the upstream TF-A for my build, without HAB support
> > enabled the board boots:
> > 
> > U-Boot SPL 2022.07-rc4-3-g9eca6cc66a (Jun 08 2022 - 08:21:41 +0200)
> > SEC0:  RNG instantiated
> > Normal Boot
> > WDT:   Started watchdog@3028 with servicing (60s timeout)
> > Trying to boot from BOOTROM
> > image offset 0x8000, pagesize 0x200, ivt offset 0x0
> > NOTICE:  BL31: v2.7(release):v2.7.0-17-g65a5e1c04-dirty
> > NOTICE:  BL31: Built : 06:19:26, Jun  8 2022
> >
> >
> > U-Boot 2022.07-rc4-3-g9eca6cc66a (Jun 08 2022 - 08:21:41 +0200)
> >
> > CPU:   Freescale i.MX8MP[8] rev1.0 at 1200 MHz
> > Reset cause: POR
> > Model: NXP i.MX8MPlus EVK board
> > DRAM:  6 GiB
> > Core:  176 devices, 22 uclasses, devicetree: separate
> > WDT:   Started watchdog@3028 with servicing (60s timeout)
> > MMC:   FSL_SDHC: 1, FSL_SDHC: 2
> > Loading Environment from MMC... *** Warning - bad CRC, using default
> environment
> >
> > In:serial@3089
> > Out:   serial@3089
> > Err:   serial@3089
> > SEC0:  RNG instantiated
> > Net:   eth0: ethernet@30be, eth1: ethernet@30bf [PRIME]
> > Hit any key to stop autoboot:  0
> > u-boot=>
> > 
> >
> > When HAB in enabled, the only thing that can be observed in the
> > console is:
> > 
> > U-Boot SPL 2022.07-rc4-3-g9eca6cc66a-dirty (Jun 08 2022 - 09:40:52 
> > +0200)
> 
> My understanding, at least for the i.MX8MM case, is that mainline TF-A
> does not support HAB,
> so the NXP TF-A should be used if HAB support is required.
> 
> Please check:
> https://lists.trustedfirmware.org/archives/list/t...@lists.trustedfirmware.org/message/5UYYI4CNLQ5OWWHU466JBK6I5QIQ2VRS/
> 

Thanks for the hint!

That would be understandable, but I would at least be expecting
to have some error messages. But I do not get any - the board just
does not pass SPL at all, as like SEC0 hangs during RNG instantiation
(my rough speculations here).

> Does the board boot with IMX_HAB=y with NXP TF-A?

Nope, unfortunately also not. Once HAB config is enabled on the
i.MX8MP - the board does not pass the SPL, even with NXP TF-A.

> 
> Regards,
> 
> Fabio Estevam

-- andrey

RE: [PATCH] i.MX8M: crypto: disable JR0 in SPL, U-Boot

[ZHIZHIKIN Andrey]

Hello Gaurav,

Cc: Michael Walle here.

I guess this is a re-incarnation of the previous discussions we had
regarding the JR reservation, see [1].

> -Original Message-
> From: Gaurav Jain 
> Sent: Wednesday, June 8, 2022 3:34 PM
> To: u-boot@lists.denx.de; Stefano Babic ; Fabio Estevam
> ; Tommaso Merciai ;
> ZHIZHIKIN Andrey ; Michael Trimarchi
> ; Marek Vasut ; Simon Glass
> ; Patrick Delaunay ; Stefan 
> Roese
> ; Horia Geanta ; Pankaj Gupta
> ; Varun Sethi ; Ye Li 
> Cc: NXP i . MX U-Boot Team ; Gaurav Jain 
> 
> Subject: [PATCH] i.MX8M: crypto: disable JR0 in SPL, U-Boot
> 
> disabled use of JR0 in SPL and uboot, as JR0 is reserved
> for HAB in TF-A.
> 
> Signed-off-by: Gaurav Jain 
> ---
>  arch/arm/dts/imx8mm-evk-u-boot.dtsi|  1 +
>  arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi   |  1 +
>  arch/arm/dts/imx8mp-evk-u-boot.dtsi|  1 +
>  arch/arm/dts/imx8mq-evk-u-boot.dtsi|  4 

Shall those DTB changes be sync'd with Kernel?

Now that the JR0 reservation is done in both upstream and
downstream TF-A - Kernel would fail to initialize the JR0.

This is what Fabio just noted and posted as a comment. :-)

I suggest that this is submitted into Kernel, and then picked
up during the next DTB re-sync.

>  arch/arm/include/asm/arch-imx8m/imx-regs.h |  1 +
>  drivers/crypto/fsl/jr.c| 14 +++---
>  scripts/config_whitelist.txt   |  1 +
>  7 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi b/arch/arm/dts/imx8mm-evk-u-
> boot.dtsi
> index e9fbf7b802..8cd37b5205 100644
> --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> @@ -74,6 +74,7 @@
> 
>  _jr0 {
> u-boot,dm-spl;
> +   status = "disabled";
>  };
> 
>  _jr1 {
> diff --git a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi 
> b/arch/arm/dts/imx8mn-ddr4-
> evk-u-boot.dtsi
> index 4d0ecb07d4..0c31f2737a 100644
> --- a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> @@ -114,6 +114,7 @@
> 
>  _jr0 {
> u-boot,dm-spl;
> +   status = "disabled";
>  };
> 
>  _jr1 {
> diff --git a/arch/arm/dts/imx8mp-evk-u-boot.dtsi b/arch/arm/dts/imx8mp-evk-u-
> boot.dtsi
> index f43eb6238d..28dce55fb9 100644
> --- a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> @@ -77,6 +77,7 @@
> 
>  _jr0 {
> u-boot,dm-spl;
> +   status = "disabled";
>  };
> 
>  _jr1 {
> diff --git a/arch/arm/dts/imx8mq-evk-u-boot.dtsi b/arch/arm/dts/imx8mq-evk-u-
> boot.dtsi
> index 67da69a2eb..37364eb6b4 100644
> --- a/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> @@ -18,3 +18,7 @@
>   {
> u-boot,dm-spl;
>  };
> +
> +_jr0 {
> +   status = "disabled";
> +};
> diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h
> b/arch/arm/include/asm/arch-imx8m/imx-regs.h
> index 1da75528d4..e6e2974df3 100644
> --- a/arch/arm/include/asm/arch-imx8m/imx-regs.h
> +++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h
> @@ -89,6 +89,7 @@
>  #define CONFIG_SYS_FSL_SEC_ADDR (CAAM_IPS_BASE_ADDR + \
>  CONFIG_SYS_FSL_SEC_OFFSET)
>  #define CONFIG_SYS_FSL_JR0_OFFSET   (0x1000)
> +#define CONFIG_SYS_FSL_JR1_OFFSET  (0x2000)
>  #define CONFIG_SYS_FSL_JR0_ADDR (CONFIG_SYS_FSL_SEC_ADDR + \
>  CONFIG_SYS_FSL_JR0_OFFSET)
>  #define CONFIG_SYS_FSL_MAX_NUM_OF_SEC   1
> diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
> index acd29924f7..66dd9cf365 100644
> --- a/drivers/crypto/fsl/jr.c
> +++ b/drivers/crypto/fsl/jr.c
> @@ -44,9 +44,17 @@ struct udevice *caam_dev;
>  #define SEC_ADDR(idx)  \
> (ulong)((CONFIG_SYS_FSL_SEC_ADDR + sec_offset[idx]))
> 
> -#define SEC_JR0_ADDR(idx)  \
> +#ifndef CONFIG_IMX8M
> +#define SEC_JR_ADDR(idx)   \
> (ulong)(SEC_ADDR(idx) + \
>  (CONFIG_SYS_FSL_JR0_OFFSET - CONFIG_SYS_FSL_SEC_OFFSET))
> +#define JR_ID 0
> +#else
> +#define SEC_JR_ADDR(idx)   \
> +   (ulong)(SEC_ADDR(idx) + \
> +   (CONFIG_SYS_FSL_JR1_OFFSET - CONFIG_SYS_FSL_SEC_OFFSET))
> +#define JR_ID 1
> +#endif

I believe this whole macro can be simplified, isn't it?

>  struct caam_regs caam_st;
>  #endif
> 
> @@ -685,8 +693,8 @@ int sec_init_idx(uint8_t sec_idx)
> caam = dev_get_priv(caam_dev);
>  #else
> caam_st.sec = (void *)SEC_ADDR(sec_idx);
> -   caam_st.regs = (struct jr_regs *)SEC_JR0_ADDR(sec_idx);
> -   caam_st.jrid = 0;
> +   

RE: [PATCH] crypto: fsl_hash: Remove unnecessary alignment check in caam_hash()

[ZHIZHIKIN Andrey]

Hello Fabio et al.,

> -Original Message-
> From: Fabio Estevam 
> Sent: Wednesday, June 8, 2022 12:50 AM
> To: Heiko Thiery 
> Cc: Stefan Roese ; U-Boot-Denx ; Gaurav 
> Jain
> ; dullf...@yahoo.com; Rasmus Villemoes
> ; Schrempf Frieder ;
> ZHIZHIKIN Andrey ; Horia Geanta Neag
> ; Thomas Schaefer ; Ye Li
> ; Peng Fan 
> Subject: Re: [PATCH] crypto: fsl_hash: Remove unnecessary alignment check in
> caam_hash()
> 
> On Tue, Jun 7, 2022 at 2:27 PM Fabio Estevam  wrote:
> >
> > Hi Heiko,
> >
> > On Tue, Jun 7, 2022 at 4:48 AM Heiko Thiery  wrote:
> >
> > >> Thomas Schäfer sees this behavior also on an imx8mn NXP evk board.
> > >> Thus I added him to this thread.
> >
> > Thanks for the feedback.
> >
> > I managed to reproduce the problem on an imx8mm-evk board.
> >
> > On top of tree U-Boot I added:
> >
> > --- a/configs/imx8mm_evk_defconfig
> > +++ b/configs/imx8mm_evk_defconfig
> > @@ -87,3 +87,4 @@ CONFIG_SYSRESET_PSCI=y
> >  CONFIG_SYSRESET_WATCHDOG=y
> >  CONFIG_DM_THERMAL=y
> >  CONFIG_IMX_WATCHDOG=y
> > +CONFIG_IMX_HAB=y
> >
> > Then I try to load the fitImage and the sha256 calculation via CAAM fails:
> >
> > U-Boot SPL 2022.07-rc3-00093-g7d3acf08ec60-dirty (Jun 07 2022 - 14:20:02 
> > -0300)
> > SEC0:  RNG instantiated
> > Normal Boot
> > WDT:   Started watchdog@3028 with servicing (60s timeout)
> > Trying to boot from MMC1
> > hab fuse not enabled
> >
> > Authenticate image from DDR location 0x401fcdc0...
> > bad magic magic=0x0 length=0x00 version=0x0
> > bad length magic=0x0 length=0x00 version=0x0
> > bad version magic=0x0 length=0x00 version=0x0
> > Error: Invalid IVT structure
> > NOTICE:  BL31: v2.4(release):lf-5.15.5-1.0.0-10-gcb51a0faa4b6
> 
> The problem seems to be related to the TF-A version.
> 
> If I use the older imx_5.4.47_2.2.0 TF-A then the sha256 calculation
> via CAAM does not fail.

I just tried the imx8mp_evk and with CONFIG_IMX_HAB=y the board
does not pass the SPL.

I used the upstream TF-A for my build, without HAB support
enabled the board boots:

U-Boot SPL 2022.07-rc4-3-g9eca6cc66a (Jun 08 2022 - 08:21:41 +0200)
SEC0:  RNG instantiated
Normal Boot
WDT:   Started watchdog@3028 with servicing (60s timeout)
Trying to boot from BOOTROM
image offset 0x8000, pagesize 0x200, ivt offset 0x0
NOTICE:  BL31: v2.7(release):v2.7.0-17-g65a5e1c04-dirty
NOTICE:  BL31: Built : 06:19:26, Jun  8 2022


U-Boot 2022.07-rc4-3-g9eca6cc66a (Jun 08 2022 - 08:21:41 +0200)

CPU:   Freescale i.MX8MP[8] rev1.0 at 1200 MHz
Reset cause: POR
Model: NXP i.MX8MPlus EVK board
DRAM:  6 GiB
Core:  176 devices, 22 uclasses, devicetree: separate
WDT:   Started watchdog@3028 with servicing (60s timeout)
MMC:   FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:serial@3089
Out:   serial@3089
Err:   serial@3089
SEC0:  RNG instantiated
Net:   eth0: ethernet@30be, eth1: ethernet@30bf [PRIME]
Hit any key to stop autoboot:  0
u-boot=>


When HAB in enabled, the only thing that can be observed in the
console is:

U-Boot SPL 2022.07-rc4-3-g9eca6cc66a-dirty (Jun 08 2022 - 09:40:52 +0200)


I believe there is a common problem with the CAAM configuration
here and usage of HAB, perhaps due to JR reservations.


Gaurav,

Can you please advise on what could be causing this behavior on i.MX8MP?

Thanks a lot!

> 
> Regards,
> 
> Fabio Estevam

-- andrey

RE: [EXT] Re: [PATCH] crypto: fsl_hash: Remove unnecessary alignment check in caam_hash()

[ZHIZHIKIN Andrey]

Hello Gaurav,

> -Original Message-
> From: U-Boot  On Behalf Of Gaurav Jain
> Sent: Wednesday, June 8, 2022 7:45 AM
> To: Fabio Estevam ; Heiko Thiery 
> Cc: Stefan Roese ; U-Boot-Denx ;
> dullf...@yahoo.com; Rasmus Villemoes ; Schrempf
> Frieder ; ZHIZHIKIN Andrey 
>  geosystems.com>; Horia Geanta ; Thomas Schäfer
> ; Ye Li ; Peng Fan 
> 
> Subject: RE: [EXT] Re: [PATCH] crypto: fsl_hash: Remove unnecessary alignment
> check in caam_hash()
> 
> Hi Fabio
> 
> > -Original Message-
> > From: Fabio Estevam 
> > Sent: Wednesday, June 8, 2022 4:20 AM
> > To: Heiko Thiery 
> > Cc: Stefan Roese ; U-Boot-Denx ; Gaurav
> > Jain ; dullf...@yahoo.com; Rasmus Villemoes
> > ; Schrempf Frieder
> > ; ZHIZHIKIN Andrey  > geosystems.com>; Horia Geanta ; Thomas Schäfer
> > ; Ye Li ; Peng Fan
> > 
> > Subject: [EXT] Re: [PATCH] crypto: fsl_hash: Remove unnecessary alignment
> > check in caam_hash()
> >
> > Caution: EXT Email
> >
> > On Tue, Jun 7, 2022 at 2:27 PM Fabio Estevam  wrote:
> > >
> > > Hi Heiko,
> > >
> > > On Tue, Jun 7, 2022 at 4:48 AM Heiko Thiery  
> > > wrote:
> > >
> > > >> Thomas Schäfer sees this behavior also on an imx8mn NXP evk board.
> > > >> Thus I added him to this thread.
> > >
> > > Thanks for the feedback.
> > >
> > > I managed to reproduce the problem on an imx8mm-evk board.
> > >
> > > On top of tree U-Boot I added:
> > >
> > > --- a/configs/imx8mm_evk_defconfig
> > > +++ b/configs/imx8mm_evk_defconfig
> > > @@ -87,3 +87,4 @@ CONFIG_SYSRESET_PSCI=y
> > CONFIG_SYSRESET_WATCHDOG=y
> > > CONFIG_DM_THERMAL=y  CONFIG_IMX_WATCHDOG=y
> > > +CONFIG_IMX_HAB=y
> > >
> > > Then I try to load the fitImage and the sha256 calculation via CAAM fails:
> > >
> > > U-Boot SPL 2022.07-rc3-00093-g7d3acf08ec60-dirty (Jun 07 2022 -
> > > 14:20:02 -0300)
> > > SEC0:  RNG instantiated
> > > Normal Boot
> > > WDT:   Started watchdog@3028 with servicing (60s timeout)
> > > Trying to boot from MMC1
> > > hab fuse not enabled
> > >
> > > Authenticate image from DDR location 0x401fcdc0...
> > > bad magic magic=0x0 length=0x00 version=0x0 bad length magic=0x0
> > > length=0x00 version=0x0 bad version magic=0x0 length=0x00 version=0x0
> > > Error: Invalid IVT structure
> > > NOTICE:  BL31: v2.4(release):lf-5.15.5-1.0.0-10-gcb51a0faa4b6
> >
> > The problem seems to be related to the TF-A version.
> >
> > If I use the older imx_5.4.47_2.2.0 TF-A then the sha256 calculation via 
> > CAAM
> > does not fail.
> 
> I think you are right.  Patch submitted in TFA for not releasing JR0 to non-
> secure which is causing this issue.
> https://git.trustedfirmware.org/TF-A/trusted-firmware-
> a.git/commit/?h=refs/heads/integration=77850c96f23bcdc76ecb0ecd27a982c00fde5d9
> d
> 

I believe that Fabio used NXP TF-A for booting, while you're referring to 
upstream
TF-A commit.

Coming back to our discussion that we had with CAAM support series, which JRs 
are
now used for which purposes? Does upstream TF-A (so as NXP TF-A) reserves JR0 
for
HAB operations, hence JR1 is required in U-Boot for crypto operations?

Is it possible that you provide a clear picture of JR reservations in all
combinations of SPL -> TF-A (upstream or NXP) -> U-Boot?

> I will share a patch for switching to JR1 in uboot.
> 
> Regards
> Gaurav Jain
> >
> > Regards,
> >
> > Fabio Estevam

Regards,
Andrey

RE: [PATCH] imx: imx8m: drop uneeded check

[ZHIZHIKIN Andrey]

> -Original Message-
> From: U-Boot  On Behalf Of Peng Fan
> Sent: Monday, May 16, 2022 9:25 AM
> To: ZHIZHIKIN Andrey ; Peng Fan (OSS)
> ; sba...@denx.de; feste...@gmail.com; dl-uboot-imx 
>  i...@nxp.com>
> Cc: u-boot@lists.denx.de
> Subject: RE: [PATCH] imx: imx8m: drop uneeded check
> 
> > Subject: RE: [PATCH] imx: imx8m: drop uneeded check
> >
> > Hello Peng,
> >
> > > -Original Message-
> > > From: U-Boot  On Behalf Of Peng Fan
> > > (OSS)
> > > Sent: Friday, April 29, 2022 10:19 AM
> > > To: sba...@denx.de; feste...@gmail.com; NXP i.MX U-Boot Team
> > > 
> > > Cc: u-boot@lists.denx.de; Peng Fan 
> > > Subject: [PATCH] imx: imx8m: drop uneeded check
> > >
> > > From: Peng Fan 
> > >
> > > All i.MX8M needs TZASC ID SWAP set and locked, no need the check to
> > > waste cpu cycles.
> > >
> > > Signed-off-by: Peng Fan 
> > > ---
> > >  arch/arm/mach-imx/imx8m/soc.c | 6 ++
> > >  1 file changed, 2 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-imx/imx8m/soc.c
> > > b/arch/arm/mach-imx/imx8m/soc.c index 8e23e6da326..5240dc11363
> > 100644
> > > --- a/arch/arm/mach-imx/imx8m/soc.c
> > > +++ b/arch/arm/mach-imx/imx8m/soc.c
> > > @@ -72,15 +72,13 @@ void enable_tzc380(void)
> > >* According to TRM, TZASC_ID_SWAP_BYPASS should be set in
> > >* order to avoid AXI Bus errors when GPU is in use
> > >*/
> > > - if (is_imx8mq() || is_imx8mm() || is_imx8mn() || is_imx8mp())
> > > - setbits_le32(>gpr[10], GPR_TZASC_ID_SWAP_BYPASS);
> > > + setbits_le32(>gpr[10], GPR_TZASC_ID_SWAP_BYPASS);
> >
> > Since you've dropped the SoC-specific check, perhaps you can combine bits 
> > set
> > that are done by setbits_le32 together with one below?
> 
> Let’s separate them, first set, then lock.

OK, sounds logical.

> >
> > >
> > >   /*
> > >* imx8mn and imx8mp implements the lock bit for
> > >* TZASC_ID_SWAP_BYPASS, enable it to lock settings
> > >*/
> > > - if (is_imx8mn() || is_imx8mp())
> > > - setbits_le32(>gpr[10],
> > GPR_TZASC_ID_SWAP_BYPASS_LOCK);
> > > + setbits_le32(>gpr[10], GPR_TZASC_ID_SWAP_BYPASS_LOCK);
> >
> > BYPASS_LOCK is not present in i.MX8MM TRM, but I guess you've checked that 
> > it
> > is implemented already, right?
> 
> Yes. It is implemented. RM needs update.

Understood, thanks for clarifications!

Reviewed-by: Andrey Zhizhikin 

> 
> Regards,
> Peng.
> 
> >
> > >
> > >   /*
> > >* set Region 0 attribute to allow secure and non-secure
> > > --
> > > 2.36.0
> >
> > -- andrey

-- andrey

RE: [PATCH] imx: imx8m: drop uneeded check

[ZHIZHIKIN Andrey]

Hello Peng,

> -Original Message-
> From: U-Boot  On Behalf Of Peng Fan (OSS)
> Sent: Friday, April 29, 2022 10:19 AM
> To: sba...@denx.de; feste...@gmail.com; NXP i.MX U-Boot Team 
> 
> Cc: u-boot@lists.denx.de; Peng Fan 
> Subject: [PATCH] imx: imx8m: drop uneeded check
> 
> From: Peng Fan 
> 
> All i.MX8M needs TZASC ID SWAP set and locked, no need the check to
> waste cpu cycles.
> 
> Signed-off-by: Peng Fan 
> ---
>  arch/arm/mach-imx/imx8m/soc.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
> index 8e23e6da326..5240dc11363 100644
> --- a/arch/arm/mach-imx/imx8m/soc.c
> +++ b/arch/arm/mach-imx/imx8m/soc.c
> @@ -72,15 +72,13 @@ void enable_tzc380(void)
>* According to TRM, TZASC_ID_SWAP_BYPASS should be set in
>* order to avoid AXI Bus errors when GPU is in use
>*/
> - if (is_imx8mq() || is_imx8mm() || is_imx8mn() || is_imx8mp())
> - setbits_le32(>gpr[10], GPR_TZASC_ID_SWAP_BYPASS);
> + setbits_le32(>gpr[10], GPR_TZASC_ID_SWAP_BYPASS);

Since you've dropped the SoC-specific check, perhaps you can combine
bits set that are done by setbits_le32 together with one below?

> 
>   /*
>* imx8mn and imx8mp implements the lock bit for
>* TZASC_ID_SWAP_BYPASS, enable it to lock settings
>*/
> - if (is_imx8mn() || is_imx8mp())
> - setbits_le32(>gpr[10], GPR_TZASC_ID_SWAP_BYPASS_LOCK);
> + setbits_le32(>gpr[10], GPR_TZASC_ID_SWAP_BYPASS_LOCK);

BYPASS_LOCK is not present in i.MX8MM TRM, but I guess you've checked
that it is implemented already, right?

> 
>   /*
>* set Region 0 attribute to allow secure and non-secure
> --
> 2.36.0

-- andrey

RE: [EXT] Re: [PATCH v8 01/15] crypto/fsl: Add support for CAAM Job ring driver model

[ZHIZHIKIN Andrey]

Hello Gaurav,

> -Original Message-
> From: U-Boot  On Behalf Of Gaurav Jain
> Sent: Monday, March 7, 2022 3:10 PM
> To: ZHIZHIKIN Andrey ; Stefano Babic
> ; u-boot@lists.denx.de; Marek Vasut 
> Cc: Fabio Estevam ; Peng Fan ; Simon 
> Glass
> ; Priyanka Jain ; Ye Li 
> ;
> Horia Geanta ; Ji Luo ; Franck Lenormand
> ; Silvano Di Ninno ; Sahil
> Malhotra ; Pankaj Gupta ; Varun
> Sethi ; dl-uboot-imx ; Shengzhou Liu
> ; Mingkai Hu ; Rajesh Bhagat
> ; Meenakshi Aggarwal ; 
> Wasim
> Khan ; Alison Wang ; Pramod Kumar
> ; Andy Tang ; Adrian Alonso
> ; Vladimir Oltean 
> Subject: RE: [EXT] Re: [PATCH v8 01/15] crypto/fsl: Add support for CAAM Job 
> ring
> driver model
> 
> Hello Andrey
> 
> 
> Ok, I will follow the approach suggested by you. First a patch will be 
> submitted
> to ATF and then the one for uboot will follow.

Perfect, thanks a lot for following it up here!

> Will send a V11 after removing the JR0 reservation code. Any other concern?

Besides the one above, I have no further concerns on the series.

> 
> Gaurav
> 
> >

-- andrey

RE: [EXT] Re: [PATCH v8 01/15] crypto/fsl: Add support for CAAM Job ring driver model

[ZHIZHIKIN Andrey]

Hello Stefano,

> -Original Message-
> From: U-Boot  On Behalf Of Stefano Babic
> Sent: Thursday, March 3, 2022 4:30 PM
> To: Gaurav Jain ; Stefano Babic ; u-
> b...@lists.denx.de; Marek Vasut 
> Cc: Fabio Estevam ; Peng Fan ; Simon 
> Glass
> ; Priyanka Jain ; Ye Li 
> ;
> Horia Geanta ; Ji Luo ; Franck Lenormand
> ; Silvano Di Ninno ; Sahil
> Malhotra ; Pankaj Gupta ; Varun
> Sethi ; dl-uboot-imx ; Shengzhou Liu
> ; Mingkai Hu ; Rajesh Bhagat
> ; Meenakshi Aggarwal ; 
> Wasim
> Khan ; Alison Wang ; Pramod Kumar
> ; Andy Tang ; Adrian Alonso
> ; Vladimir Oltean 
> Subject: Re: [EXT] Re: [PATCH v8 01/15] crypto/fsl: Add support for CAAM Job 
> ring
> driver model
> 
> Hi,
> 
> On 03.03.22 14:41, Gaurav Jain wrote:
> > Hi Stefano
> >
> > As we have not received any response from imx6dl_mamoj board maintainer.
> > I propose the below solution
> >
> > --- a/arch/arm/mach-imx/Kconfig
> > +++ b/arch/arm/mach-imx/Kconfig
> > @@ -49,8 +49,8 @@ config USE_IMXIMG_PLUGIN  config IMX_HAB
> > -   select FSL_CAAM if HAS_CAAM
> > -   imply CMD_DEKBLOB if HAS_CAAM
> > +   imply FSL_CAAM if HAS_CAAM
> > +   imply CMD_DEKBLOB if FSL_CAAM
> >   Help
> >
> 
> IMO this is ok, I was also wrong, Marek is not the maintainer of this
> board. This was the only board with broken build - let's say, I will
> still wait a couple of days, and if there is no comments, I will apply
> your series (but then V10). I can apply this fix myself, no need to post
> the series again (I have not seen any other comment or request to change).

I had a couple of concerns which I raised in V10 without any follow-up. 

Main thing is the JR reservation, which (if applied) would lead to
misconfiguration when upstream TF-A is used, see [1].

> 
> Regards,
> Stefano
> 

Link: [1]: 
https://lore.kernel.org/u-boot/am6pr06mb4691178347827cb77f44f537a6...@am6pr06mb4691.eurprd06.prod.outlook.com/

-- andrey

RE: [EXT] RE: [PATCH v10 02/14] i.MX8M: crypto: updated device tree for supporting DM in SPL

[ZHIZHIKIN Andrey]

Hello Gaurav,

Sorry, I somehow missed you last reply here.

Cc: Rouven

> -Original Message-
> From: U-Boot  On Behalf Of Gaurav Jain
> Sent: Friday, February 11, 2022 10:48 AM
> To: ZHIZHIKIN Andrey ; u-
> b...@lists.denx.de
> Cc: Stefano Babic ; Fabio Estevam ; Peng 
> Fan
> ; Simon Glass ; Michael Walle
> ; Priyanka Jain ; Ye Li 
> ;
> Horia Geanta ; Ji Luo ; Franck Lenormand
> ; Silvano Di Ninno ; Sahil
> Malhotra ; Pankaj Gupta ; Varun
> Sethi ; dl-uboot-imx ; Shengzhou Liu
> ; Mingkai Hu ; Rajesh Bhagat
> ; Meenakshi Aggarwal ; 
> Wasim
> Khan ; Alison Wang ; Pramod Kumar
> ; Andy Tang ; Adrian Alonso
> ; Vladimir Oltean 
> Subject: RE: [EXT] RE: [PATCH v10 02/14] i.MX8M: crypto: updated device tree 
> for
> supporting DM in SPL
> 
> Hello Andrey
> 
> I responded to your comments on this patch.
> If you are good, can this patch series merged?
> 
> Regards
> Gaurav Jain
> 
> > -Original Message-
> > From: Gaurav Jain
> > Sent: Thursday, February 3, 2022 10:58 AM
> > To: ZHIZHIKIN Andrey ; u-
> > b...@lists.denx.de
> > Cc: Stefano Babic ; Fabio Estevam ;
> > Peng Fan ; Simon Glass ; Michael
> > Walle ; Priyanka Jain ; Ye Li
> > ; Horia Geanta ; Ji Luo
> > ; Franck Lenormand ; Silvano Di
> > Ninno ; Sahil Malhotra ;
> > Pankaj Gupta ; Varun Sethi ; dl-
> > uboot-imx ; Shengzhou Liu ;
> > Mingkai Hu ; Rajesh Bhagat ;
> > Meenakshi Aggarwal ; Wasim Khan
> > ; Alison Wang ; Pramod
> > Kumar ; Andy Tang ;
> > Adrian Alonso ; Vladimir Oltean 
> > Subject: RE: [EXT] RE: [PATCH v10 02/14] i.MX8M: crypto: updated device tree
> > for supporting DM in SPL
> >
> > Hello Andrey
> >
> > > -Original Message-
> > > From: ZHIZHIKIN Andrey 
> > > Sent: Tuesday, February 1, 2022 3:15 AM
> > > To: Gaurav Jain ; u-boot@lists.denx.de
> > > Cc: Stefano Babic ; Fabio Estevam
> > > ; Peng Fan ; Simon Glass
> > > ; Michael Walle ; Priyanka Jain
> > > ; Ye Li ; Horia Geanta
> > > ; Ji Luo ; Franck Lenormand
> > > ; Silvano Di Ninno
> > > ; Sahil Malhotra ;
> > > Pankaj Gupta ; Varun Sethi ;
> > > dl- uboot-imx ; Shengzhou Liu
> > > ; Mingkai Hu ; Rajesh
> > > Bhagat ; Meenakshi Aggarwal
> > > ; Wasim Khan ;
> > Alison
> > > Wang ; Pramod Kumar
> > ;
> > > Andy Tang ; Adrian Alonso ;
> > > Vladimir Oltean 
> > > Subject: [EXT] RE: [PATCH v10 02/14] i.MX8M: crypto: updated device
> > > tree for supporting DM in SPL
> > >
> > > Caution: EXT Email
> > >
> > > Hello Gaurav,
> > >
> > > > -Original Message-
> > > > From: U-Boot  On Behalf Of Gaurav Jain
> > > > Sent: Wednesday, January 12, 2022 2:31 PM
> > > > To: u-boot@lists.denx.de
> > > > Cc: Stefano Babic ; Fabio Estevam
> > > > ; Peng Fan ; Simon Glass
> > > > ; Michael Walle ; Priyanka Jain
> > > > ; Ye Li ; Horia Geanta
> > > > ; Ji Luo ; Franck Lenormand
> > > > ; Silvano Di Ninno
> > > > ; Sahil malhotra ;
> > > > Pankaj Gupta ; Varun Sethi ;
> > > > NXP i . MX U-Boot Team ; Shengzhou Liu
> > > > ; Mingkai Hu ; Rajesh
> > > > Bhagat ; Meenakshi Aggarwal
> > > > ; Wasim Khan ;
> > > Alison
> > > > Wang ; Pramod Kumar
> > > ;
> > > > Tang Yuantian ; Adrian Alonso
> > > > ; Vladimir Oltean ; Gaurav
> > > > Jain 
> > > > Subject: [PATCH v10 02/14] i.MX8M: crypto: updated device tree for
> > > > supporting DM in SPL
> > > >
> > > > disabled use of JR0 in SPL and uboot, as JR0 is reserved for secure
> > > > boot.
> > >
> > > I'd like to return the original question here, which was not
> > > completely clarified during previous reviews: where does the reservation
> > restriction is coming from?
> >
> > As mentioned earlier JR0 is being used by high assurance boot (HAB). This
> > prevents JR0 being used by any other software layer.

From what I understood reading AN4581 and companion AN12056, HAB requires
JR only in case when Encrypted Boot is performed. For image signature
verification it is not required, hence this reservation does sound a bit
artificial to me. Please correct me here if my understanding is not complete,
I was not able to get this information from all the answers you provided
before on the purpose of this reservation.

This fact, coupled with the one that upstream TF-A does release all JR to

RE: [PATCH v10 02/14] i.MX8M: crypto: updated device tree for supporting DM in SPL

[ZHIZHIKIN Andrey]

Hello Gaurav,

> -Original Message-
> From: U-Boot  On Behalf Of Gaurav Jain
> Sent: Wednesday, January 12, 2022 2:31 PM
> To: u-boot@lists.denx.de
> Cc: Stefano Babic ; Fabio Estevam ; Peng 
> Fan
> ; Simon Glass ; Michael Walle
> ; Priyanka Jain ; Ye Li 
> ;
> Horia Geanta ; Ji Luo ; Franck Lenormand
> ; Silvano Di Ninno ; Sahil
> malhotra ; Pankaj Gupta ; Varun
> Sethi ; NXP i . MX U-Boot Team ; Shengzhou
> Liu ; Mingkai Hu ; Rajesh Bhagat
> ; Meenakshi Aggarwal ; 
> Wasim
> Khan ; Alison Wang ; Pramod Kumar
> ; Tang Yuantian ; Adrian Alonso
> ; Vladimir Oltean ; Gaurav Jain
> 
> Subject: [PATCH v10 02/14] i.MX8M: crypto: updated device tree for supporting 
> DM
> in SPL
> 
> disabled use of JR0 in SPL and uboot, as JR0 is reserved
> for secure boot.

I'd like to return the original question here, which was not completely 
clarified
during previous reviews: where does the reservation restriction is coming from?

BootROM does reserve the JR0 and JR1, which are later released by ATF. NXP 
downstream
ATF keeps the JR0 reserved, but upstream ATF does release *all* JRs to NS World.

If this reservation is taken like the patch proposes and U-Boot is built with 
upstream
ATF - this would eventually lead to the situation where the HW configuration is 
not
aligned with what DTB indicates.

Please note, that recent OP-TEE release has also re-mapped the JR it uses from 
JR0 to
JR2, which can also lead to usage of the JR which is already taken by OP-TEE. 
There is
an ongoing PR in OP-TEE to disable JR nodes via DT overlay for Linux [1], but 
I'm not
sure if the same applies to U-Boot as well.

> 
> Signed-off-by: Gaurav Jain 
> Reviewed-by: Ye Li 
> ---
>  arch/arm/dts/imx8mm-evk-u-boot.dtsi  | 19 ++-
>  arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi | 19 ++-
>  arch/arm/dts/imx8mp-evk-u-boot.dtsi  | 19 ++-
>  arch/arm/dts/imx8mq-evk-u-boot.dtsi  |  4 
>  4 files changed, 58 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi b/arch/arm/dts/imx8mm-evk-u-
> boot.dtsi
> index 6b459831e7..e5682ca165 100644
> --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> @@ -1,6 +1,6 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
> - * Copyright 2019 NXP
> + * Copyright 2019, 2021 NXP
>   */
> 
>  #include "imx8mm-u-boot.dtsi"
> @@ -68,6 +68,23 @@
>   u-boot,dm-spl;
>  };
> 
> + {
> + u-boot,dm-spl;
> +};
> +
> +_jr0 {
> + u-boot,dm-spl;
> + status = "disabled";
> +};
> +
> +_jr1 {
> + u-boot,dm-spl;
> +};
> +
> +_jr2 {
> + u-boot,dm-spl;
> +};
> +
>   {
>   u-boot,dm-spl;
>  };
> diff --git a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi 
> b/arch/arm/dts/imx8mn-ddr4-
> evk-u-boot.dtsi
> index 1d3844437d..d8df863083 100644
> --- a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> @@ -1,6 +1,6 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
> - * Copyright 2019 NXP
> + * Copyright 2019, 2021 NXP
>   */
> 
>  / {
> @@ -104,6 +104,23 @@
>   u-boot,dm-spl;
>  };
> 
> + {
> + u-boot,dm-spl;
> +};
> +
> +_jr0 {
> + u-boot,dm-spl;
> + status = "disabled";
> +};
> +
> +_jr1 {
> + u-boot,dm-spl;
> +};
> +
> +_jr2 {
> + u-boot,dm-spl;
> +};
> +
>   {
>   u-boot,dm-spl;
>  };
> diff --git a/arch/arm/dts/imx8mp-evk-u-boot.dtsi b/arch/arm/dts/imx8mp-evk-u-
> boot.dtsi
> index ab849ebaac..f3f83ba303 100644
> --- a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> @@ -1,6 +1,6 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
> - * Copyright 2019 NXP
> + * Copyright 2019, 2021 NXP
>   */
> 
>  #include "imx8mp-u-boot.dtsi"
> @@ -67,6 +67,23 @@
>   u-boot,dm-spl;
>  };
> 
> + {
> + u-boot,dm-spl;
> +};
> +
> +_jr0 {
> + u-boot,dm-spl;
> + status = "disabled";
> +};
> +
> +_jr1 {
> + u-boot,dm-spl;
> +};
> +
> +_jr2 {
> + u-boot,dm-spl;
> +};
> +
>   {
>   u-boot,dm-spl;
>  };
> diff --git a/arch/arm/dts/imx8mq-evk-u-boot.dtsi b/arch/arm/dts/imx8mq-evk-u-
> boot.dtsi
> index 6f9c81462e..8f1f942215 100644
> --- a/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> @@ -10,3 +10,7 @@
>   sd-uhs-sdr104;
>   sd-uhs-ddr50;
>  };
> +
> +_jr0 {
> + status = "disabled";
> +};
> --
> 2.17.1

Link: [1]: https://github.com/OP-TEE/optee_os/pull/5143

RE: [PATCH] imx: ventana: correct splashimage load address

[ZHIZHIKIN Andrey]

Hello Tim,

> -Original Message-
> From: Tim Harvey 
> Sent: Friday, January 28, 2022 12:20 AM
> To: ZHIZHIKIN Andrey 
> Cc: u-boot 
> Subject: Re: [PATCH] imx: ventana: correct splashimage load address
> 
> 
> On Tue, Jan 18, 2022 at 8:40 AM Tim Harvey  wrote:
> >
> > On Mon, Jan 17, 2022 at 3:32 AM Andrey Zhizhikin
> >  wrote:
> > >
> > > Commit 72d81360aabd ("global: Convert CONFIG_LOADADDR to
> > > CONFIG_SYS_LOADADDR") dropped the usage of LOADADDR and replaced it with
> > > SYS_LOADADDR.
> > >
> > > Use the correct macro in environment by replacing CONFIG_LOADADDR with
> > > CONFIG_SYS_LOADADDR.
> > >
> > > Fixes: d75ebf3482c3 ("imx: ventana: fix splash logo drawing")
> > > Signed-off-by: Andrey Zhizhikin 
> > > Cc: Tim Harvey 
> > > ---
> > >  include/configs/gw_ventana.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/configs/gw_ventana.h b/include/configs/gw_ventana.h
> > > index 513b2d4679..acd495f234 100644
> > > --- a/include/configs/gw_ventana.h
> > > +++ b/include/configs/gw_ventana.h
> > > @@ -105,7 +105,7 @@
> > >
> > >  #define CONFIG_EXTRA_ENV_SETTINGS_COMMON \
> > > "splashpos=m,m\0" \
> > > -   "splashimage=" __stringify(CONFIG_LOADADDR) "\0" \
> > > +   "splashimage=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
> > > "usb_pgood_delay=2000\0" \
> > > "console=ttymxc1\0" \
> > > "bootdevs=usb mmc sata flash\0" \
> > >
> > > base-commit: d71dbe657c3c22f50ecb3df133e5cdd884daae7d
> > > --
> > > 2.25.1
> > >
> >
> > Acked-By: Tim Harvey 
> >
> 
> Andrey,
> 
> While this does restore the custom logo on the gwventana boards there
> is now a default U-Boot logo in the top left corner. I assume this is
> some new addition... how do I disable the U-Boot logo?

THB, this I do not know. I stumbled upon the incorrect variable while
I was working on imx8mq-evk, and thought that this patch would be
beneficial for gwventana since this was the only place where the old
variable name was used.

I guess the question of suppression of default U-Boot logo is for a
bigger audience here.

> 
> Best Regards,
> 
> Tim

-- andrey

RE: [PATCH v2] imx8mq_evk: configs: add/cleanup variables for distro boot

[ZHIZHIKIN Andrey]

Hello Stefano,

> -Original Message-
> From: U-Boot  On Behalf Of Andrey Zhizhikin
> Sent: Tuesday, January 11, 2022 11:50 AM
> To: u-boot@lists.denx.de
> Cc: sba...@denx.de; alice@nxp.com; an...@akkea.ca; feste...@gmail.com;
> h...@denx.de; jh80.ch...@samsung.com; peng@nxp.com; r...@andestech.com;
> s...@chromium.org; tr...@konsulko.com; Andrey Zhizhikin 
>  geosystems.com>
> Subject: [PATCH v2] imx8mq_evk: configs: add/cleanup variables for distro boot
> 

Please discard this patch, I've sent the updated version already.

I also managed to mess up the In-Reply-To field, so the updated version comes
also as V2, so this one should be dropped completely.

Sincere apologies for this mess...

>  Add fdt_addr_r fdtfile which used by distro boot, and cleanup legacy
>  environment variables.
> 
> Signed-off-by: Andrey Zhizhikin 
> ---

-- andrey

RE: [PATCH] imx8mm_beacon/imx8mn_beacon: Update build instructions

[ZHIZHIKIN Andrey]

Hello Marcel,

> -Original Message-
> From: U-Boot  On Behalf Of Marcel Ziswiler
> Sent: Wednesday, January 12, 2022 10:28 AM
> To: aford...@gmail.com; u-boot@lists.denx.de; andrey.zhizhikin@leica-
> geosystems.com
> Cc: tr...@konsulko.com; af...@beaconembedded.com; sba...@denx.de
> Subject: Re: [PATCH] imx8mm_beacon/imx8mn_beacon: Update build instructions
> 
> Hi Andrey
> 
> On Tue, 2022-01-11 at 14:23 +, ZHIZHIKIN Andrey wrote:
> > Hello Adam,
> >
> > > -Original Message-
> > > From: U-Boot  On Behalf Of Adam Ford
> > > Sent: Tuesday, January 11, 2022 2:51 PM
> > > To: u-boot@lists.denx.de
> > > Cc: sba...@denx.de; tr...@konsulko.com; af...@beaconembedded.com; Adam 
> > > Ford
> > > 
> > > Subject: [PATCH] imx8mm_beacon/imx8mn_beacon: Update build instructions
> > >
> > > With binman generating flash.bin, it's not longer necessary to
> > > specify either the location of ATF nor is it necessary to
> > > specify building flash.bin, so let's update the build instructions
> > > to remove those.  While in here, update the revision of ATF and
> > > DDR firmware so both Mini and Nano reference the same revision.
> > >
> > > Signed-off-by: Adam Ford 
> > >
> > > diff --git a/board/beacon/imx8mm/README b/board/beacon/imx8mm/README
> > > index 03d9412f0d..200549d924 100644
> > > --- a/board/beacon/imx8mm/README
> > > +++ b/board/beacon/imx8mm/README
> > > @@ -12,21 +12,21 @@ Get and Build the ARM Trusted firmware
> > >  Note: $(srctree) is U-Boot source directory
> > >
> > >  $ git clone https://source.codeaurora.org/external/imx/imx-atf
> > > -$ git checkout imx_5.4.70_2.3.0
> > > +$ git checkout lf_v2.4
> >
> > Perhaps, it's better to advise the [lf-5.10.72-2.2.0] tag here instead of
> branch?
> >
> > >  $ make PLAT=imx8mm bl31 CROSS_COMPILE=aarch64-linux-gnu-
> > >  $ cp build/imx8mm/release/bl31.bin $(srctree)
> > >
> > >  Get the DDR firmware
> > >  
> > > -$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.5.bin
> > > -$ chmod +x firmware-imx-8.5.bin
> > > -$ ./firmware-imx-8.5
> > > -$ cp firmware-imx-8.5/firmware/ddr/synopsys/lpddr4*.bin $(srctree)
> > > +$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.9.bin
> >
> > There is a newer version of DDR firmware available from NXP (8.14), perhaps
> > you can recommend it here instead of 8.9.
> >
> > Link: https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.14.bin
> 
> I don't think anything about the DDR firmware actually changed in a long time.
> There are other parts within
> that firmware-imx package which did change. However, they are irrelevant for 
> U-
> Boot.

True, I've just compared SHA256 for all lpddr4* files from 8.5, 8.9 and 8.14 - 
they
do match.

This suggestion would be valid only if the consistency with Yocto image is 
desired
(Yocto does use the firmware version based on the archive name), but 
technically it
is not required to use the latest drop from NXP here. If this is not needed - 
this
comment of mine is irrelevant here.

> 
> > > +$ chmod +x firmware-imx-8.9.bin
> > > +$ ./firmware-imx-8.9
> > > +$ cp firmware-imx-8.9/firmware/ddr/synopsys/lpddr4*.bin $(srctree)
> > >
> > >  Build U-Boot
> > >  
> > >  $ make imx8mm_beacon_defconfig
> > > -$ make flash.bin CROSS_COMPILE=aarch64-linux-gnu-
> > > +$ make CROSS_COMPILE=aarch64-linux-gnu-
> > >
> > >  Burn U-Boot to microSD Card
> > >  ===
> > > diff --git a/board/beacon/imx8mn/README b/board/beacon/imx8mn/README
> > > index a9eddd4e64..7e5d1545e6 100644
> > > --- a/board/beacon/imx8mn/README
> > > +++ b/board/beacon/imx8mn/README
> > > @@ -12,7 +12,7 @@ Get and Build the ARM Trusted firmware
> > >  Note: $(srctree) is U-Boot source directory
> > >
> > >  $ git clone https://source.codeaurora.org/external/imx/imx-atf
> > > -$ git checkout imx_5.4.47_2.2.0
> > > +$ git checkout lf_v2.4
> >
> > Same as for Mini above.
> >
> > >  $ make PLAT=imx8mn bl31 CROSS_COMPILE=aarch64-linux-gnu-
> > >  $ cp build/imx8mm/release/bl31.bin $(srctree)
> > >
> > > @@ -26,7 +26,7 @@ $ cp firmware-imx-8.9/firmware/ddr/synopsys/lpddr4*.bin
> > > $(srctree)
> > >  Build U-Boot
> > >  
> > >  $ make imx8mn_beacon_defconfig
> > > -$ make flash.bin CROSS_COMPILE=aarch64-linux-gnu- ATF_LOAD_ADDR=0x96
> > > +$ make CROSS_COMPILE=aarch64-linux-gnu-
> > >
> > >  Burn U-Boot to microSD Card
> > >  ===
> > > --
> > > 2.32.0
> >
> > -- andrey
> 
> Cheers
> 
> Marcel

-- andrey

RE: [PATCH] imx8mm_beacon/imx8mn_beacon: Update build instructions

[ZHIZHIKIN Andrey]

Hello Adam,

> -Original Message-
> From: U-Boot  On Behalf Of Adam Ford
> Sent: Tuesday, January 11, 2022 2:51 PM
> To: u-boot@lists.denx.de
> Cc: sba...@denx.de; tr...@konsulko.com; af...@beaconembedded.com; Adam Ford
> 
> Subject: [PATCH] imx8mm_beacon/imx8mn_beacon: Update build instructions
> 
> With binman generating flash.bin, it's not longer necessary to
> specify either the location of ATF nor is it necessary to
> specify building flash.bin, so let's update the build instructions
> to remove those.  While in here, update the revision of ATF and
> DDR firmware so both Mini and Nano reference the same revision.
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/board/beacon/imx8mm/README b/board/beacon/imx8mm/README
> index 03d9412f0d..200549d924 100644
> --- a/board/beacon/imx8mm/README
> +++ b/board/beacon/imx8mm/README
> @@ -12,21 +12,21 @@ Get and Build the ARM Trusted firmware
>  Note: $(srctree) is U-Boot source directory
> 
>  $ git clone https://source.codeaurora.org/external/imx/imx-atf
> -$ git checkout imx_5.4.70_2.3.0
> +$ git checkout lf_v2.4

Perhaps, it's better to advise the [lf-5.10.72-2.2.0] tag here instead of 
branch?

>  $ make PLAT=imx8mm bl31 CROSS_COMPILE=aarch64-linux-gnu-
>  $ cp build/imx8mm/release/bl31.bin $(srctree)
> 
>  Get the DDR firmware
>  
> -$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.5.bin
> -$ chmod +x firmware-imx-8.5.bin
> -$ ./firmware-imx-8.5
> -$ cp firmware-imx-8.5/firmware/ddr/synopsys/lpddr4*.bin $(srctree)
> +$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.9.bin

There is a newer version of DDR firmware available from NXP (8.14), perhaps
you can recommend it here instead of 8.9.

Link: https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.14.bin

> +$ chmod +x firmware-imx-8.9.bin
> +$ ./firmware-imx-8.9
> +$ cp firmware-imx-8.9/firmware/ddr/synopsys/lpddr4*.bin $(srctree)
> 
>  Build U-Boot
>  
>  $ make imx8mm_beacon_defconfig
> -$ make flash.bin CROSS_COMPILE=aarch64-linux-gnu-
> +$ make CROSS_COMPILE=aarch64-linux-gnu-
> 
>  Burn U-Boot to microSD Card
>  ===
> diff --git a/board/beacon/imx8mn/README b/board/beacon/imx8mn/README
> index a9eddd4e64..7e5d1545e6 100644
> --- a/board/beacon/imx8mn/README
> +++ b/board/beacon/imx8mn/README
> @@ -12,7 +12,7 @@ Get and Build the ARM Trusted firmware
>  Note: $(srctree) is U-Boot source directory
> 
>  $ git clone https://source.codeaurora.org/external/imx/imx-atf
> -$ git checkout imx_5.4.47_2.2.0
> +$ git checkout lf_v2.4

Same as for Mini above.

>  $ make PLAT=imx8mn bl31 CROSS_COMPILE=aarch64-linux-gnu-
>  $ cp build/imx8mm/release/bl31.bin $(srctree)
> 
> @@ -26,7 +26,7 @@ $ cp firmware-imx-8.9/firmware/ddr/synopsys/lpddr4*.bin
> $(srctree)
>  Build U-Boot
>  
>  $ make imx8mn_beacon_defconfig
> -$ make flash.bin CROSS_COMPILE=aarch64-linux-gnu- ATF_LOAD_ADDR=0x96
> +$ make CROSS_COMPILE=aarch64-linux-gnu-
> 
>  Burn U-Boot to microSD Card
>  ===
> --
> 2.32.0

-- andrey

RE: [RFC] imx: imx8qm-rom7720: switch to binman

[ZHIZHIKIN Andrey]

Hello Oliver,

> -Original Message-
> From: Oliver Graute 
> Sent: Monday, January 10, 2022 11:31 AM
> To: Oliver Graute ; Stefano Babic
> ; Fabio Estevam ; NXP i.MX U-Boot Team
> 
> Cc: aford...@gmail.com; peng@nxp.com; marcel.ziswi...@toradex.com;
> thar...@gateworks.com; ZHIZHIKIN Andrey 
> ;
> u-boot@lists.denx.de
> Subject: [RFC] imx: imx8qm-rom7720: switch to binman
> 
> Switch to use binman to pack images

Please don't forget S-o-B, checkpatch does complain about it. ;)
> 
> ---
> 
> Run into this issue on the first try to get binman working:
> 
> make[1]: Nothing to be done for 'SPL'.
>   BINMAN  flash.bin
>   MKIMAGE flash.bin
> Error: spl/u-boot-spl.cfgout[16] - Invalid command (LOADER)
> arch/arm/mach-imx/Makefile:190: recipe for target 'flash.bin' failed
> make[1]: *** [flash.bin] Error 1
> make[1]: *** Deleting file 'flash.bin'
> Makefile:1519: recipe for target 'flash.bin' failed
> make: *** [flash.bin] Error 2
> 
> Some clue howto fix that?

This might be due to the fact that you're using the same u-boot-nodtb.bin 
binary twice: once in binman section, and once in ITB. You can try to rename 
the binman entry to a different name, this might do the trick. See [1] for 
sample of imx8mq_evk conversion.

> 
>  arch/arm/dts/imx8qm-rom7720-a1.dts|  1 +
>  arch/arm/dts/imx8qm-u-boot.dtsi   | 95 +++
>  arch/arm/mach-imx/imx8/Kconfig|  1 +
>  .../advantech/imx8qm_rom7720_a1/imximage.cfg  | 16 +---
>  configs/imx8qm_rom7720_a1_4G_defconfig|  2 +-

Is there any documentation available for this board that
needs adaptions with new build instructions? I was not able
to locate any doc for this board at all...

>  5 files changed, 100 insertions(+), 15 deletions(-)
>  create mode 100644 arch/arm/dts/imx8qm-u-boot.dtsi
> 
> diff --git a/arch/arm/dts/imx8qm-rom7720-a1.dts b/arch/arm/dts/imx8qm-rom7720-
> a1.dts
> index d1f2fff869..332d441c6d 100644
> --- a/arch/arm/dts/imx8qm-rom7720-a1.dts
> +++ b/arch/arm/dts/imx8qm-rom7720-a1.dts
> @@ -10,6 +10,7 @@
>  /memreserve/ 0x8000 0x0002;
> 
>  #include "fsl-imx8qm.dtsi"
> +#include "imx8qm-u-boot.dtsi"
> 
>  / {
> model = "Advantech iMX8QM Qseven series";
> diff --git a/arch/arm/dts/imx8qm-u-boot.dtsi b/arch/arm/dts/imx8qm-u-boot.dtsi
> new file mode 100644
> index 00..77e5cd6989
> --- /dev/null
> +++ b/arch/arm/dts/imx8qm-u-boot.dtsi
> @@ -0,0 +1,95 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2021 NXP
> + */
> +
> +/ {
> +   binman: binman {
> +   multiple-images;
> +   };
> +
> +};
> +
> + {
> +   u-boot-nodtb {
> +   filename = "u-boot-nodtb.bin";
> +   pad-byte = <0xff>;
> +   align-size = <4>;
> +   align = <4>;
> +
> +   u-boot-spl {
> +   align-end = <4>;
> +   };

What I see is missing in this section is SECO and SCFW binaries.

Can i.MX8QM boot without those? Otherwise generated image will be unusable.

> +
> +   };
> +
> +   flash {
> +   mkimage {
> +   args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e
> 0x10";
> +
> +   blob {
> +   filename = "u-boot-nodtb.bin";
> +   };
> +
> +   };
> +
> +   };
> +
> +   itb {
> +   filename = "u-boot.itb";
> +
> +   fit {
> +   description = "Configuration to load ATF before 
> U-Boot";
> +   #address-cells = <1>;
> +   fit,external-offset = ;
> +
> +   images {
> +   uboot {
> +   description = "U-Boot (64-bit)";
> +   type = "standalone";
> +   arch = "arm64";
> +   compression = "none";
> +   load = ;
> +
> +   uboot_blob: blob-ext {
> +   filename = "u-boot-nodtb.bin";
> +   };
> +   };
> +
> +   atf {
> +   description = "ARM Trusted Firmware";
> +   t

RE: [PATCH v8 10/15] crypto/fsl: Improve hwrng performance in kernel

[ZHIZHIKIN Andrey]

Hello Gaurav,

Cc: Michael Walle

> -Original Message-
> From: U-Boot  On Behalf Of Gaurav Jain
> Sent: Monday, January 10, 2022 1:27 PM
> To: u-boot@lists.denx.de
> Cc: Stefano Babic ; Fabio Estevam ; Peng 
> Fan
> ; Simon Glass ; Priyanka Jain
> ; Ye Li ; Horia Geanta
> ; Ji Luo ; Franck Lenormand
> ; Silvano Di Ninno ; Sahil
> malhotra ; Pankaj Gupta ; Varun
> Sethi ; NXP i . MX U-Boot Team ; Shengzhou
> Liu ; Mingkai Hu ; Rajesh Bhagat
> ; Meenakshi Aggarwal ; 
> Wasim
> Khan ; Alison Wang ; Pramod Kumar
> ; Tang Yuantian ; Adrian Alonso
> ; Vladimir Oltean 
> Subject: [PATCH v8 10/15] crypto/fsl: Improve hwrng performance in kernel
> 
> From: Ye Li 
> 
> RNG parameters are reconfigured.
> - For TRNG to generate 256 bits of entropy, RNG TRNG Seed Control register
>   is configured to have reduced SAMP_SIZE from default 2500 to 512. it is
>   number of entropy samples that will be taken during Entropy generation.
> - self-test registers(Monobit Limit, Poker Range, Run Length Limit)
>   are synchronized with new RTSDCTL[SAMP_SIZE] of 512.
> 
> TRNG time is caluculated based on sample size.

Typo: caluculated -> calculated

> time required to generate entropy is reduced and
> hwrng performance improved from 0.3 kB/s to 1.3 kB/s.

Is there any degradation in passed/failed FIPS 140-2 test count? Can you
provide some results from at least rngtest run?

> 
> Signed-off-by: Ye Li 
> Acked-by: Gaurav Jain >
> ---
>  drivers/crypto/fsl/jr.c | 102 +---
>  include/fsl_sec.h   |   1 +
>  2 files changed, 87 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
> index a84440ab10..e5346a84a4 100644
> --- a/drivers/crypto/fsl/jr.c
> +++ b/drivers/crypto/fsl/jr.c
> @@ -603,30 +603,100 @@ static u8 get_rng_vid(ccsr_sec_t *sec)
>   */
>  static void kick_trng(int ent_delay, ccsr_sec_t *sec)
>  {
> + u32 samples  = 512; /* number of bits to generate and test */
> + u32 mono_min = 195;
> + u32 mono_max = 317;
> + u32 mono_range  = mono_max - mono_min;
> + u32 poker_min = 1031;
> + u32 poker_max = 1600;
> + u32 poker_range = poker_max - poker_min + 1;
> + u32 retries= 2;
> + u32 lrun_max   = 32;
> + s32 run_1_min   = 27;
> + s32 run_1_max   = 107;
> + s32 run_1_range = run_1_max - run_1_min;
> + s32 run_2_min   = 7;
> + s32 run_2_max   = 62;
> + s32 run_2_range = run_2_max - run_2_min;
> + s32 run_3_min   = 0;
> + s32 run_3_max   = 39;
> + s32 run_3_range = run_3_max - run_3_min;
> + s32 run_4_min   = -1;
> + s32 run_4_max   = 26;
> + s32 run_4_range = run_4_max - run_4_min;
> + s32 run_5_min   = -1;
> + s32 run_5_max   = 18;
> + s32 run_5_range = run_5_max - run_5_min;
> + s32 run_6_min   = -1;
> + s32 run_6_max   = 17;
> + s32 run_6_range = run_6_max - run_6_min;

I have a feeling that this whole block of local variables can be
simplified. I'm not sure it is required to list this so detailed.

You can attempt to define those values in header file and use
macros to compute bound conditions, rather than allocating this on
the stack here.

> + u32 val;
> +
>   struct rng4tst __iomem *rng =
>   (struct rng4tst __iomem *)>rng;
> - u32 val;
> 
> - /* put RNG4 into program mode */
> - sec_setbits32(>rtmctl, RTMCTL_PRGM);
> - /* rtsdctl bits 0-15 contain "Entropy Delay, which defines the
> -  * length (in system clocks) of each Entropy sample taken
> -  * */
> + /* Put RNG in program mode */
> + /* Setting both RTMCTL:PRGM and RTMCTL:TRNG_ACC causes TRNG to
> +  * properly invalidate the entropy in the entropy register and
> +  * force re-generation.
> +  */
> + sec_setbits32(>rtmctl, RTMCTL_PRGM | RTMCTL_ACC);
> +
> + /* Configure the RNG Entropy Delay
> +  * Performance-wise, it does not make sense to
> +  * set the delay to a value that is lower
> +  * than the last one that worked (i.e. the state handles
> +  * were instantiated properly. Thus, instead of wasting
> +  * time trying to set the values controlling the sample
> +  * frequency, the function simply returns.
> +  */
>   val = sec_in32(>rtsdctl);
> - val = (val & ~RTSDCTL_ENT_DLY_MASK) |
> -   (ent_delay << RTSDCTL_ENT_DLY_SHIFT);
> + val &= RTSDCTL_ENT_DLY_MASK;
> + val >>= RTSDCTL_ENT_DLY_SHIFT;
> + if (ent_delay < val) {
> + /* Put RNG4 into run mode */
> + sec_clrbits32(>rtmctl, RTMCTL_PRGM | RTMCTL_ACC);
> + return;
> + }
> +
> + val = (ent_delay << RTSDCTL_ENT_DLY_SHIFT) | samples;
>   sec_out32(>rtsdctl, val);
> - /* min. freq. count, equal to 1/4 of the entropy sample length */
> - sec_out32(>rtfreqmin, ent_delay >> 2);
> - /* disable maximum frequency count */
> - sec_out32(>rtfreqmax, RTFRQMAX_DISABLE);
> +
> + /*
> +  * Recommended margins (min,max) 

RE: [PATCH v2] imx8mq_evk: switch board to use binman for images

[ZHIZHIKIN Andrey]

Hello Tom,

> -Original Message-
> From: U-Boot  On Behalf Of Andrey Zhizhikin
> Sent: Friday, December 3, 2021 5:18 PM
> To: u-boot@lists.denx.de
> Cc: sba...@denx.de; feste...@gmail.com; uboot-...@nxp.com; peng@nxp.com;
> h...@denx.de; t.rem...@phytec.de; ja...@amarulasolutions.com;
> marcel.ziswi...@toradex.com; il...@ronetix.at; xypron.g...@gmx.de; Andrey
> Zhizhikin 
> Subject: [PATCH v2] imx8mq_evk: switch board to use binman for images
> 
> Currently i.MX8MQ EVK board still targeting the old image generation
> approach for image generation, which relies on the FIT generator that
> has been dropped from the tree.
> 
> Switch the board to use binman instead, which is a standard image
> generator now.
> 
> Update board documentation to correct build command, and advise latest
> firmware and TF-A versions to use.
> 
> NOTE: New image produced by binman does not have Signed HDMI FW support,
> this has been left on the side and does not interfere with the general
> boot flow.
> 
> Tested on: [i.MX8MQ rev2.0]
> 
> Signed-off-by: Andrey Zhizhikin 
> ---
> 
> Changes in V2:
> - Modify binman and documentation to use single flash.bin file instead
>   of flash.bin+u-boot.itb combination, suggested by Fabio Estevam.

Since you've applied similar patch from Peng, this one is not needed
anymore and can be dropped.

There are however few pieces that are present in this patch not picked
up in any other patch like doc update, single flash.bin, etc.

I saw that Patrick Wildt had "single flash.bin" part submitted in [1],
which would also be beneficial to have in 2022.01 for consistency, and
would allow me to update imx8mq_evk machine in meta-freescale Yocto
layer so it can be finally built with upstream BSP and 2022.01. If you
can pick it up saw well - that would be ideal!

The rest I will extract and send as separate patches after 2022.01. 

> 
>  arch/arm/dts/imx8mq-evk-u-boot.dtsi   | 124 ++
>  arch/arm/mach-imx/imx8m/Kconfig   |   1 +
>  board/freescale/imx8mq_evk/Kconfig|   2 +-
>  .../imx8mq_evk/imximage-8mq-lpddr4.cfg|   9 ++
>  configs/imx8mq_evk_defconfig  |   2 +-
>  doc/board/nxp/imx8mq_evk.rst  |  21 +--
>  6 files changed, 148 insertions(+), 11 deletions(-)
>  create mode 100644 board/freescale/imx8mq_evk/imximage-8mq-lpddr4.cfg
> 
> diff --git a/arch/arm/dts/imx8mq-evk-u-boot.dtsi b/arch/arm/dts/imx8mq-evk-u-
> boot.dtsi
> index 2cfc12b7e0..e3f780ca75 100644
> --- a/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> @@ -1,5 +1,129 @@
>  // SPDX-License-Identifier: (GPL-2.0 OR MIT)
> 
> +/ {
> + binman: binman {
> + multiple-images;
> + };
> +};
> +
> + {
> + 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_pmu_train_1d_imem.bin";
> + size = <0x8000>;
> + };
> +
> + blob_2: blob-ext@2 {
> + filename = "lpddr4_pmu_train_1d_dmem.bin";
> + size = <0x4000>;
> + };
> +
> + blob_3: blob-ext@3 {
> + filename = "lpddr4_pmu_train_2d_imem.bin";
> + size = <0x8000>;
> + };
> +
> + blob_4: blob-ext@4 {
> + filename = "lpddr4_pmu_train_2d_dmem.bin";
> + size = <0x4000>;
> + };
> + };
> +
> + spl {
> + filename = "spl.bin";
> +
> + mkimage {
> + args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e 
> 0x7e1000";
> +
> + blob {
> + filename = "u-boot-spl-ddr.bin";
> + };
> + };
> + };
> +
> + itb {
> + filename = "u-boot.itb";
> +
> + fit {
> + description = "Configuration to load ATF before U-Boot";
> + #address-cells = <1>;
> + fit,external-offset = ;
> +
> + images {
> + uboot {
> + description = "U-Boot (64-bit)";
> + type = "standalone";
> + arch = "arm64";
> + compression = "none";
> + load = ;
> +
> + uboot_blob: blob-ext {
> + filename = "u-boot-nodtb.bin";
> + };
> + };
> +
> + atf {
> + description = "ARM 

RE: [PATCH] Revert "tree: imx: remove old fit generator script"

[ZHIZHIKIN Andrey]

Hello Tom,

> -Original Message-
> From: U-Boot  On Behalf Of Tom Rini
> Sent: Thursday, January 6, 2022 7:52 PM
> To: u-boot@lists.denx.de
> Cc: Tim Harvey 
> Subject: [PATCH] Revert "tree: imx: remove old fit generator script"
> 
> This reverts commit d9a6f0eed66a39206b13513ec914f14084c3bb73.
> 
> For right now, it's too close to the release to merge the series that
> allows for binman to be used to generate the final images, and also not
> break CI, and then also merge all of the series that convert currently
> broken platforms to use binman instead.  So, bring back this script now
> and remove it again for real after the release.

Please note that this might not work, as the FIT generator script would
generate ITS with '@' symbols which are not compatible with mkimage due
to CVE-2021-27138. This revert should be complemented with the fix to
remove those '@' symbols as well.

> 
> Suggested-by: Tim Harvey 
> Signed-off-by: Tom Rini 
> ---
>  Makefile |   3 +
>  arch/arm/mach-imx/mkimage_fit_atf.sh | 143 +++
>  2 files changed, 146 insertions(+)
>  create mode 100755 arch/arm/mach-imx/mkimage_fit_atf.sh
> 
> diff --git a/Makefile b/Makefile
> index ae9bfab91acf..0c478645c3a7 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1343,6 +1343,9 @@ $(U_BOOT_ITS): $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
>  else
>  ifneq ($(CONFIG_USE_SPL_FIT_GENERATOR),)
>  U_BOOT_ITS := u-boot.its
> +ifeq ($(CONFIG_SPL_FIT_GENERATOR),"arch/arm/mach-imx/mkimage_fit_atf.sh")
> +U_BOOT_ITS_DEPS += u-boot-nodtb.bin
> +endif
>  ifeq ($(CONFIG_SPL_FIT_GENERATOR),"arch/arm/mach-rockchip/make_fit_atf.py")
>  U_BOOT_ITS_DEPS += u-boot
>  endif
> diff --git a/arch/arm/mach-imx/mkimage_fit_atf.sh b/arch/arm/mach-
> imx/mkimage_fit_atf.sh
> new file mode 100755
> index ..2a17968794c1
> --- /dev/null
> +++ b/arch/arm/mach-imx/mkimage_fit_atf.sh
> @@ -0,0 +1,143 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# script to generate FIT image source for i.MX8MQ boards with
> +# ARM Trusted Firmware and multiple device trees (given on the command line)
> +#
> +# usage: $0  [ [ +
> +[ -z "$BL31" ] && BL31="bl31.bin"
> +[ -z "$TEE_LOAD_ADDR" ] && TEE_LOAD_ADDR="0xfe00"
> +[ -z "$ATF_LOAD_ADDR" ] && ATF_LOAD_ADDR="0x0091"
> +[ -z "$BL33_LOAD_ADDR" ] && BL33_LOAD_ADDR="0x4020"
> +
> +if [ ! -f $BL31 ]; then
> + echo "ERROR: BL31 file $BL31 NOT found" >&2
> + exit 0
> +else
> + echo "$BL31 size: " >&2
> + stat -c %s $BL31 >&2
> +fi
> +
> +BL32="tee.bin"
> +
> +if [ ! -f $BL32 ]; then
> + BL32=/dev/null
> +else
> + echo "Building with TEE support, make sure your $BL31 is compiled with
> spd. If you do not want tee, please delete $BL31" >&2
> + echo "$BL32 size: " >&2
> + stat -c %s $BL32 >&2
> +fi
> +
> +BL33="u-boot-nodtb.bin"
> +
> +if [ ! -f $BL33 ]; then
> + echo "ERROR: $BL33 file NOT found" >&2
> + exit 0
> +else
> + echo "u-boot-nodtb.bin size: " >&2
> + stat -c %s u-boot-nodtb.bin >&2
> +fi
> +
> +for dtname in $*
> +do
> + echo "$dtname size: " >&2
> + stat -c %s $dtname >&2
> +done
> +
> +
> +cat << __HEADER_EOF
> +/dts-v1/;
> +
> +/ {
> + description = "Configuration to load ATF before U-Boot";
> +
> + images {
> + uboot@1 {

This (and all other similar places) would be rejected by mkimage... :(

> + description = "U-Boot (64-bit)";
> + os = "u-boot";
> + data = /incbin/("$BL33");
> + type = "standalone";
> + arch = "arm64";
> + compression = "none";
> + load = <$BL33_LOAD_ADDR>;
> + };
> +__HEADER_EOF
> +
> +cnt=1
> +for dtname in $*
> +do
> + cat << __FDT_IMAGE_EOF
> + fdt@$cnt {
> + description = "$(basename $dtname .dtb)";
> + data = /incbin/("$dtname");
> + type = "flat_dt";
> + compression = "none";
> + };
> +__FDT_IMAGE_EOF
> +cnt=$((cnt+1))
> +done
> +
> +cat << __HEADER_EOF
> + atf@1 {
> + description = "ARM Trusted Firmware";
> + os = "arm-trusted-firmware";
> + data = /incbin/("$BL31");
> + type = "firmware";
> + arch = "arm64";
> + compression = "none";
> + load = <$ATF_LOAD_ADDR>;
> + entry = <$ATF_LOAD_ADDR>;
> + };
> +__HEADER_EOF
> +
> +if [ -f $BL32 ]; then
> +cat << __HEADER_EOF
> + tee@1 {
> + description = "TEE firmware";
> + data = /incbin/("$BL32");
> + type = "firmware";
> + arch = "arm64";
> + compression = "none";
> + load = <$TEE_LOAD_ADDR>;
> + entry = 

RE: mkimage_fit_atf.sh: not found

[ZHIZHIKIN Andrey]

Hello Tim,

> -Original Message-
> From: U-Boot  On Behalf Of Tim Harvey
> Sent: Thursday, January 6, 2022 6:10 PM
> To: ZHIZHIKIN Andrey 
> Cc: u-boot ; Stefano Babic ; Fabio 
> Estevam
> ; Schrempf Frieder ; Adam 
> Ford
> ; Marcel Ziswiler ; Jagan Teki
> ; Oliver Graute 
> Subject: Re: mkimage_fit_atf.sh: not found
> 
> On Thu, Jan 6, 2022 at 2:07 AM ZHIZHIKIN Andrey
>  wrote:
> >
> > Hello Tim,
> >
> > > -Original Message-
> > > From: U-Boot  On Behalf Of Tim Harvey
> > > Sent: Wednesday, January 5, 2022 8:08 PM
> > > To: ZHIZHIKIN Andrey 
> > > Cc: u-boot ; Stefano Babic ; Fabio
> Estevam
> > > ; Schrempf Frieder ; Adam
> Ford
> > > ; Marcel Ziswiler ; Jagan Teki
> > > 
> > > Subject: Re: mkimage_fit_atf.sh: not found
> > >
> > > On Wed, Jan 5, 2022 at 3:34 AM ZHIZHIKIN Andrey
> > >  wrote:
> > > >
> > > > Hello Tim,
> > > >
> > > > > -Original Message-
> > > > > From: U-Boot  On Behalf Of Tim Harvey
> > > > > Sent: Tuesday, January 4, 2022 11:48 PM
> > > > > To: u-boot ; Stefano Babic ; 
> > > > > Fabio
> > > Estevam
> > > > > 
> > > > > Cc: Schrempf Frieder ; Adam Ford
> > > > > ; Marcel Ziswiler ; Jagan 
> > > > > Teki
> > > > > 
> > > > > Subject: mkimage_fit_atf.sh: not found
> > > > >
> > > > > Stefano and Fabio,
> > > > >
> > > > > I'm seeing the imx8mm_venice_defconfig target failing to build on
> > > > > master due to mkimage_fit_atf.sh not found:
> > > > > ./"arch/arm/mach-imx/mkimage_fit_atf.sh" \
> > > > > arch/arm/dts/imx8mm-venice-gw71xx-0x.dtb
> > > > > arch/arm/dts/imx8mm-venice-gw72xx-0x.dtb
> > > > > arch/arm/dts/imx8mm-venice-gw73xx-0x.dtb
> > > > > arch/arm/dts/imx8mm-venice-gw7901.dtb
> > > > > arch/arm/dts/imx8mm-venice-gw7902.dtb > u-boot.its
> > > > > /bin/sh: 1: ./arch/arm/mach-imx/mkimage_fit_atf.sh: not found
> > > > >
> > > >
> > > > This has been dropped in d9a6f0eed6 ("tree: imx: remove old fit 
> > > > generator
> > > script")
> > >
> > > So why was that merged when it breaks several boards that are not
> > > switched to binman because of the CI issue?
> >
> > Because the FIT generator script has been broken after commit 3f04db891a
> > ("image: Check for unit addresses in FITs"), which has covered 
> > CVE-2021-27138.
> > You can see the reasoning of merging d9a6f0eed6 ("tree: imx: remove old fit
> > generator script") in the commit message.
> >
> > In addition, d9a6f0eed6 ("tree: imx: remove old fit generator script") has
> > been introduced as a part of discussion stemmed from [1], where it has been
> > pointed out that certain boards are still using old FIT generator which is
> > not working, and I've listed those board config files for maintainers to 
> > react.
> >
> 
> Andrey,
> 
> I agree removing the old fit generator is the right path but I am very
> surprised it was merged when it broke boards that had not moved to
> binman yet. There has been a warning to migrate to binman but there
> was never a deadline.

I totally agree that there was no deadline set for this, hence I submitted
the patch as RFC in a good faith that board maintainers (which were all
included in the patch submission mail) would take a look and comment on
this removal. Since nobody complained about that removal at the submission
time - the patch has been accepted.

If you take a look at the discussion that originated this removal patch -
you would see more background and insights on why it has been introduced,
and I saw no objections there either. I've listed those board configs there
which would be affected by the removal, and even included Oliver as I did
not see any binman conversion series from him at that time. Even that did
not trigger any red flag at the time...

This all may come from the fact that board maintainers (like you) had already
patches prepared to move to binman, and I do believe that at the time of
submission there has been no checks in CI about those missing binaries,
hence the submission came clean.

> 
> > Binman CI missing binaries verification came later I believe, that is the
> > reason we are seeing those conversions pending. But this is unrelated to the
> > FIT generator script removal, which was broken anyways.
> >
>

RE: mkimage_fit_atf.sh: not found

[ZHIZHIKIN Andrey]

Hello Tim,

> -Original Message-
> From: U-Boot  On Behalf Of Tim Harvey
> Sent: Wednesday, January 5, 2022 8:08 PM
> To: ZHIZHIKIN Andrey 
> Cc: u-boot ; Stefano Babic ; Fabio 
> Estevam
> ; Schrempf Frieder ; Adam 
> Ford
> ; Marcel Ziswiler ; Jagan Teki
> 
> Subject: Re: mkimage_fit_atf.sh: not found
> 
> On Wed, Jan 5, 2022 at 3:34 AM ZHIZHIKIN Andrey
>  wrote:
> >
> > Hello Tim,
> >
> > > -Original Message-
> > > From: U-Boot  On Behalf Of Tim Harvey
> > > Sent: Tuesday, January 4, 2022 11:48 PM
> > > To: u-boot ; Stefano Babic ; Fabio
> Estevam
> > > 
> > > Cc: Schrempf Frieder ; Adam Ford
> > > ; Marcel Ziswiler ; Jagan Teki
> > > 
> > > Subject: mkimage_fit_atf.sh: not found
> > >
> > > Stefano and Fabio,
> > >
> > > I'm seeing the imx8mm_venice_defconfig target failing to build on
> > > master due to mkimage_fit_atf.sh not found:
> > > ./"arch/arm/mach-imx/mkimage_fit_atf.sh" \
> > > arch/arm/dts/imx8mm-venice-gw71xx-0x.dtb
> > > arch/arm/dts/imx8mm-venice-gw72xx-0x.dtb
> > > arch/arm/dts/imx8mm-venice-gw73xx-0x.dtb
> > > arch/arm/dts/imx8mm-venice-gw7901.dtb
> > > arch/arm/dts/imx8mm-venice-gw7902.dtb > u-boot.its
> > > /bin/sh: 1: ./arch/arm/mach-imx/mkimage_fit_atf.sh: not found
> > >
> >
> > This has been dropped in d9a6f0eed6 ("tree: imx: remove old fit generator
> script")
> 
> So why was that merged when it breaks several boards that are not
> switched to binman because of the CI issue?

Because the FIT generator script has been broken after commit 3f04db891a
("image: Check for unit addresses in FITs"), which has covered CVE-2021-27138.
You can see the reasoning of merging d9a6f0eed6 ("tree: imx: remove old fit
generator script") in the commit message.

In addition, d9a6f0eed6 ("tree: imx: remove old fit generator script") has
been introduced as a part of discussion stemmed from [1], where it has been
pointed out that certain boards are still using old FIT generator which is
not working, and I've listed those board config files for maintainers to react.

Binman CI missing binaries verification came later I believe, that is the
reason we are seeing those conversions pending. But this is unrelated to the
FIT generator script removal, which was broken anyways.

> 
> >
> > > As far as I can tell the other boards that are still using
> > > SPL_FIT_GENERATOR also fail due to this (ie imx8mm_beacon_defconfig,
> > > imx8mq_evk_defconfig, imx8mm-icore-mx8mm-edimm2.2_defconfig, etc).
> >
> > imx8mq_evk is already converted and I've sent a patch for it, see [1].
> >
> > >
> > > What is the state of the binman conversion? I submitted a series to
> > > convert my boards to binman and it has just been sitting without any
> > > response for months now [1].
> >
> > I believe that the reason for your series sitting in the queue is the same 
> > as
> > for imx8mq_evk: missing binary blobs (ATF and DDR) are failing CI builds.
> >
> 
> Right, so imx8mq_evk (and others) are completely broken for the
> pending release correct?

That is correct, and there are patches to address this.

There is also a patch series from Heiko to address the "missing binary" CI 
issue, see [2].

> 
> Sounds like we need to revert d9a6f0eed6 ("tree: imx: remove old fit
> generator script")

No, because reverting this patch would bring the FIT generator which
does not produce correct images due to reasons stated above.

If there are plans to revert it - then it should also be complemented with
the patch that fixes the FIT generator. I'm not sure if this is a desired
behavior to bring back old functionality and fix it for the sake of removing
it at the later stage.

> 
> Tim
> 
> > >
> > > I'm not sure when the above breakage occurred but the conversion to
> > > binman resolves it and other things.
> > >
> > > Please let me know what you expect me to do to resolve this as there
> > > is a release pending.
> > >
> > > Best regards,
> > >
> > > Tim
> > > [1] 
> > > https://patchwork.ozlabs.org/project/uboot/patch/20211006201700.3018-1-
> > > thar...@gateworks.com/
> >
> > -- andrey
> >
> > Link: [1]:
> http://patchwork.ozlabs.org/project/uboot/patch/20211203161802.12699-1-
> andrey.zhizhi...@leica-geosystems.com/

-- andrey

Link: [1]: 
https://lore.kernel.org/u-boot/am6pr06mb46912c898e0d6ea797d1eb5ea6...@am6pr06mb4691.eurprd06.prod.outlook.com/
Link: [2]: 
https://lore.kernel.org/u-boot/20220105125816.197045-1-heiko.thi...@gmail.com/

RE: mkimage_fit_atf.sh: not found

[ZHIZHIKIN Andrey]

Hello Tim,

> -Original Message-
> From: U-Boot  On Behalf Of Tim Harvey
> Sent: Tuesday, January 4, 2022 11:48 PM
> To: u-boot ; Stefano Babic ; Fabio 
> Estevam
> 
> Cc: Schrempf Frieder ; Adam Ford
> ; Marcel Ziswiler ; Jagan Teki
> 
> Subject: mkimage_fit_atf.sh: not found
> 
> Stefano and Fabio,
> 
> I'm seeing the imx8mm_venice_defconfig target failing to build on
> master due to mkimage_fit_atf.sh not found:
> ./"arch/arm/mach-imx/mkimage_fit_atf.sh" \
> arch/arm/dts/imx8mm-venice-gw71xx-0x.dtb
> arch/arm/dts/imx8mm-venice-gw72xx-0x.dtb
> arch/arm/dts/imx8mm-venice-gw73xx-0x.dtb
> arch/arm/dts/imx8mm-venice-gw7901.dtb
> arch/arm/dts/imx8mm-venice-gw7902.dtb > u-boot.its
> /bin/sh: 1: ./arch/arm/mach-imx/mkimage_fit_atf.sh: not found
> 

This has been dropped in d9a6f0eed6 ("tree: imx: remove old fit generator 
script")

> As far as I can tell the other boards that are still using
> SPL_FIT_GENERATOR also fail due to this (ie imx8mm_beacon_defconfig,
> imx8mq_evk_defconfig, imx8mm-icore-mx8mm-edimm2.2_defconfig, etc).

imx8mq_evk is already converted and I've sent a patch for it, see [1].

> 
> What is the state of the binman conversion? I submitted a series to
> convert my boards to binman and it has just been sitting without any
> response for months now [1].

I believe that the reason for your series sitting in the queue is the same as
for imx8mq_evk: missing binary blobs (ATF and DDR) are failing CI builds.

> 
> I'm not sure when the above breakage occurred but the conversion to
> binman resolves it and other things.
> 
> Please let me know what you expect me to do to resolve this as there
> is a release pending.
> 
> Best regards,
> 
> Tim
> [1] https://patchwork.ozlabs.org/project/uboot/patch/20211006201700.3018-1-
> thar...@gateworks.com/

-- andrey

Link: [1]: 
http://patchwork.ozlabs.org/project/uboot/patch/20211203161802.12699-1-andrey.zhizhi...@leica-geosystems.com/

RE: [PATCH 1/2] fsl-layerscape: add dtb overlay feature

[ZHIZHIKIN Andrey]

Hello Sahil,

> -Original Message-
> From: Sahil Malhotra (OSS) 
> Sent: Wednesday, December 8, 2021 7:12 AM
> To: Michael Walle ; Sahil Malhotra (OSS)
> 
> Cc: Clément Faure ; Gaurav Jain ;
> Pankaj Gupta ; Priyanka Jain ; u-
> b...@lists.denx.de; Varun Sethi ; Ye Li ;
> ZHIZHIKIN Andrey 
> Subject: RE: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
> 
> 
> Hi Michael,
> 
> -Original Message-
> From: Michael Walle 
> Sent: Monday, November 29, 2021 11:17 PM
> To: Sahil Malhotra (OSS) 
> Cc: Clément Faure ; Gaurav Jain ;
> Pankaj Gupta ; Priyanka Jain ; u-
> b...@lists.denx.de; Varun Sethi ; Ye Li ;
> ZHIZHIKIN Andrey 
> Subject: Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
> 
> Hi Sahil,
> 
> Am 2021-11-29 12:55, schrieb Sahil Malhotra (OSS):
> > Am 2021-11-17 19:11, schrieb Sahil Malhotra (OSS):
> >>> Could you please add some description what this is doing and for
> >>> what this is intended? To have a "DTB overlay feature", it is enough
> >>> to just enable CONFIG_OF_LIBFDT_OVERLAY.
> >> I will add some description, and yes for DTB overlay feature, it is
> >> enough to enable CONFIG_OF_LIBFDT_OVERLAY but we need to do this step
> >> before booting the kernel that's why also have to enable
> >> CONFIG_OF_SYSTEM_SETUP.
> >
> >> Ok. What will the overlay do? Could you give an example?
> > This overlay will be disabling the crypto nodes which will be used by
> > optee in secure world, so that linux should not use it.
> >
> >
> >>> Apparently you're adding an overlay passed by optee. Doesn't this
> >>> have to be applied to u-boot's control dtb too?
> >> Yes, we will be applying the overlay passed by optee, yes it will be
> >> applied to dtb which will be passed to uboot for kernel booting.
> >
> >> If I read this patch correctly, you're modifying the DT before you
> >> jump to linux. But I was asking whether you also have to modify the
> >> DT which is used by u-boot. Eg. if you disable some kind of crypto
> >> nodes (because optee will use them in secure world), this also have
> >> to communicated to u-boot, not only linux, no?
> > Yes, I got your point now, and is very valid, but as of now for u-boot
> > we are just using the first available node for communicating with CAAM
> > leaving other job rings as it is.
> > So we need not to apply overlay to DTB used by uboot.
> 
> > But we should do the correct thing, so that u-boot and linux doesn't see a
> different version of the device tree.
> 
> > Also what do you mean with "the first available node"?
> > There is already a new CAAM driver for u-boot pending, see 
> > https://lore.kernel.org/u-boot/2025070014.17586-1-gaurav.j...@nxp.com/
> 
> Very first CAAM Job Ring is always used by u-boot, OP-TEE does not use this 
> job
> ring. Same job ring can be used by Linux once it boots up.

Just for clarification: by saying "Very first CAAM Job Ring" do you
actually mean JR0?

If the BootROM logic with respect to JR reservation for LS family does
not differ from i.MX8M family (which I assume does not), then why can't
the logic be implemented in the same way proposed by Gaurav [1] here as
well?

DT nodes can be statically disabled if we know that they are held by HAB
and are not released to NS World.

OP-TEE does set the status itself via dt_enable_secure_status(), which
should present the properly configured FDT when U-Boot takes over.

This is however valid only if OP-TEE implementation for LS matches to
one from i.MX8M family.

If it OP-TEE does differ, then I suggest this should be rather addressed
there before U-Boot, since OP-TEE have all facilities in place to
reserve JR nodes as they are needed.

> 
> Regards,
> Sahil Malhotra

-- andrey
Link: [1]: 
https://lore.kernel.org/u-boot/20211207074129.10955-9-gaurav.j...@nxp.com

RE: [PATCH] imx8mq_evk: switch board to use binman for images

[ZHIZHIKIN Andrey]

Hello Fabio,

> -Original Message-
> From: Fabio Estevam 
> Sent: Friday, December 3, 2021 4:54 PM
> To: ZHIZHIKIN Andrey 
> Cc: U-Boot-Denx ; Stefano Babic ; 
> dl-uboot-
> imx ; Peng Fan ; Heiko Schocher
> ; Teresa Remmet ; Jagan Teki
> ; Marcel Ziswiler ; 
> Ilko
> Iliev ; Heinrich Schuchardt 
> Subject: Re: [PATCH] imx8mq_evk: switch board to use binman for images
> 
> 
> Hi Andrey,
> 
> Thanks for the patch.
> 
> On Fri, Dec 3, 2021 at 12:30 PM Andrey Zhizhikin
>  wrote:
> 
> > -Burn the flash.bin to MicroSD card offset 33KB:
> > +Burn the flash.bin (offset 33KB) and u-boot.itb (offset 384KB) to MicroSD
> card:
> 
> Could you please use the single flash.bin approach here too?
> 
> Please see commit:
> 028abfd9b157 ("imx8mm-evk: Generate a single bootable flash.bin again")

Sure thing! Thanks for pointing this out, I do remember there has
been quite a discussion regarding this point, but I totally missed
what was the outcome. Now I can see it in this commit quite clear. :)


I'll change the binman DT node now and push a V2.

> 
> Thanks

-- andrey

RE: [RFC PATCH 0/3] imx8m: move env_get_location for imx8mn and imx8mp at board level

[ZHIZHIKIN Andrey]

Hello Michael,

> -Original Message-
> From: Michael Nazzareno Trimarchi 
> Sent: Monday, November 29, 2021 9:40 AM
> To: ZHIZHIKIN Andrey 
> Cc: Tommaso Merciai ; Stefano Babic ;
> Fabio Estevam ; NXP i.MX U-Boot Team ;
> Peng Fan ; Ye Li ; Marek Vasut 
> ;
> Simon Glass ; Frieder Schrempf 
> ;
> Marek Behún ; Ying-Chun Liu (PaulLiu) 
> ;
> u-boot@lists.denx.de
> Subject: Re: [RFC PATCH 0/3] imx8m: move env_get_location for imx8mn and 
> imx8mp
> at board level
> 
> 
> HI
> 
> On Mon, Nov 29, 2021 at 9:38 AM ZHIZHIKIN Andrey
>  wrote:
> >
> > Hello Tommaso,
> >
> > > -Original Message-
> > > From: Tommaso Merciai 
> > > Sent: Friday, November 26, 2021 6:43 PM
> > > Cc: mich...@amarulasolutions.com; ZHIZHIKIN Andrey 
> > >  > > geosystems.com>; Tommaso Merciai ; Stefano Babic
> > > ; Fabio Estevam ; NXP i.MX U-Boot Team
> > > ; Peng Fan ; Ye Li ;
> Marek
> > > Vasut ; Simon Glass ; Frieder Schrempf
> > > ; Marek Behún ; Ying-Chun
> Liu
> > > (PaulLiu) ; u-boot@lists.denx.de
> > > Subject: [RFC PATCH 0/3] imx8m: move env_get_location for imx8mn and 
> > > imx8mp
> at
> > > board level
> > >
> > >
> > > This series move env_get_location from soc to board level. As suggested
> > > by Michael  make no sense to define an
> > > unique way for multiple board. One board can boot from emmc and having
> > > env on spi flash etc.. Anyways, this function is kept in both imx8mn
> > > and imx8mp evk boards instead of being completely dropped.
> > > (as suggested by Andrey )
> >
> > I believe there has been another suggestion from my side regarding this 
> > patch:
> > Since it look like that Michael Trimarchi submitted another part to drop
> > env_get_offset() in [1], combined with the first patch in this series - it 
> > is
> > a complete revert of 2707faf01f ("imx8mn/imx8mp: override env_get_offset and
> > env_get_location").
> >
> > I suggest you to submit a revert instead of your first patch and deprecate 
> > the
> > patch from Michael, instead of having 2 separate patches for this.
> >
> 
> I think they are totally different problems. One is code not used and
> the other moves that implementation
> in specific parts.

They might be logically different, but 2 commits combined together - is a full
revert to me.

I'd leave this up to maintainer to decide, but for me it would be logical to see
a revert instead of 2 separate commits - this makes tracking more transparent.

> 
> Michael
> 
> > >
> > > Tommaso Merciai (3):
> > >   imx8m: drop env_get_location for imx8mn and imx8mp
> > >   imx: imx8mn_evk: override env_get_location
> > >   imx: imx8mp_evk: override env_get_location
> > >
> > >  arch/arm/mach-imx/imx8m/soc.c   | 39 ---
> > >  board/freescale/imx8mn_evk/imx8mn_evk.c | 42 +
> > >  board/freescale/imx8mp_evk/imx8mp_evk.c | 41 
> > >  3 files changed, 83 insertions(+), 39 deletions(-)
> > >
> > > --
> > > 2.25.1
> >
> > Link: [1]: 
> > http://patchwork.ozlabs.org/project/uboot/patch/2027143456.34441-1-mich...@amarulasolutions.com/
> >
> > -- andrey
> 
> 
> 
> --
> Michael Nazzareno Trimarchi
> Co-Founder & Chief Executive Officer
> M. +39 347 913 2170
> mich...@amarulasolutions.com
> __
> 
> Amarula Solutions BV
> Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
> T. +31 (0)85 111 9172
> i...@amarulasolutions.com
> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.amarulasolut
> ions.com%2Fdata=04%7C01%7C%7C666e97d4bb5f425c9a0408d9b313dd84%7C1b16ab3eb8f6
> 4fe39f3e2db7fe549f6a%7C0%7C0%7C637737720180120994%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=NJQ7
> qjpMWu%2BhGoIcqwmD%2BLc4Ekq1oHjqPSCqkiCr4DA%3Dreserved=0

-- andrey

RE: [RFC PATCH 0/3] imx8m: move env_get_location for imx8mn and imx8mp at board level

[ZHIZHIKIN Andrey]

Hello Tommaso,

> -Original Message-
> From: Tommaso Merciai 
> Sent: Friday, November 26, 2021 6:43 PM
> Cc: mich...@amarulasolutions.com; ZHIZHIKIN Andrey  geosystems.com>; Tommaso Merciai ; Stefano Babic
> ; Fabio Estevam ; NXP i.MX U-Boot Team
> ; Peng Fan ; Ye Li ; Marek
> Vasut ; Simon Glass ; Frieder Schrempf
> ; Marek Behún ; Ying-Chun Liu
> (PaulLiu) ; u-boot@lists.denx.de
> Subject: [RFC PATCH 0/3] imx8m: move env_get_location for imx8mn and imx8mp at
> board level
> 
> 
> This series move env_get_location from soc to board level. As suggested
> by Michael  make no sense to define an
> unique way for multiple board. One board can boot from emmc and having
> env on spi flash etc.. Anyways, this function is kept in both imx8mn
> and imx8mp evk boards instead of being completely dropped.
> (as suggested by Andrey )

I believe there has been another suggestion from my side regarding this patch:
Since it look like that Michael Trimarchi submitted another part to drop
env_get_offset() in [1], combined with the first patch in this series - it is
a complete revert of 2707faf01f ("imx8mn/imx8mp: override env_get_offset and
env_get_location").

I suggest you to submit a revert instead of your first patch and deprecate the
patch from Michael, instead of having 2 separate patches for this.

> 
> Tommaso Merciai (3):
>   imx8m: drop env_get_location for imx8mn and imx8mp
>   imx: imx8mn_evk: override env_get_location
>   imx: imx8mp_evk: override env_get_location
> 
>  arch/arm/mach-imx/imx8m/soc.c   | 39 ---
>  board/freescale/imx8mn_evk/imx8mn_evk.c | 42 +
>  board/freescale/imx8mp_evk/imx8mp_evk.c | 41 
>  3 files changed, 83 insertions(+), 39 deletions(-)
> 
> --
> 2.25.1

Link: [1]: 
http://patchwork.ozlabs.org/project/uboot/patch/2027143456.34441-1-mich...@amarulasolutions.com/

-- andrey

RE: [EXT] RE: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job ring driver model

[ZHIZHIKIN Andrey]

Hello Gaurav,

> -Original Message-
> From: Gaurav Jain 
> Sent: Tuesday, November 23, 2021 8:22 AM
> To: ZHIZHIKIN Andrey ; u-
> b...@lists.denx.de
> Cc: Stefano Babic ; Fabio Estevam ; Peng 
> Fan
> ; Simon Glass ; Priyanka Jain
> ; Ye Li ; Horia Geanta
> ; Ji Luo ; Franck Lenormand
> ; Silvano Di Ninno ; Sahil
> Malhotra ; Pankaj Gupta ; Varun
> Sethi ; dl-uboot-imx ; Shengzhou Liu
> ; Mingkai Hu ; Rajesh Bhagat
> ; Meenakshi Aggarwal ; 
> Wasim
> Khan ; Alison Wang ; Pramod Kumar
> ; Andy Tang ; Adrian Alonso
> ; Vladimir Oltean ; Michael Walle
> 
> Subject: RE: [EXT] RE: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job 
> ring
> driver model
> 
> 
> Hello Andrey
> 

[snip]

> > >
> > > HAB is a code that is part of the ROM code which set the JR DID for all
> i.mx8M.
> > > I took the dumps on SPL boot which actually shows the JR DID set by HAB.
> > > Dump taken by you on kernel boot does not show the values set by ROM.
> > > IMX8MM
> > > JR0DID_MS = 0x8011
> > > JR1DID_MS = 0x8011
> > > JR2DID_MS = 0x0
> > >
> > > IMX8MN
> > > JR0DID_MS = 0x8011
> > > JR1DID_MS = 0x8011
> > > JR2DID_MS = 0x0
> > >
> > > IMX8MP
> > > JR0DID_MS = 0x8011
> > > JR1DID_MS = 0x8011
> > > JR2DID_MS = 0x0
> >
> > This is an interesting piece of information, thanks a lot for the readout! 
> > So
> it
> > does look like that BootROM on all derivatives reserves JR0 and JR1 at the
> > beginning, letting the ATF to release only JR1 to NS world...
> >
> > Does IMX8MQ have the same reservation as well?
> >
> > > >
> > > > > With New implementation CAAM is enabled for i.MX8M derivative. Any
> > > > > JR whose DID is written in ATF, can be used in Uboot.
> > > > > JR0 is reserved for HAB so JR1 will be used for all i.MX8M 
> > > > > derivatives.
> > > > >
> > > > > >
> > > > > > I'm wondering about several points here:
> > > > > > 1. Why does current implementation on have this reservation done
> > > > > > on imx8mm and
> > > > > >where does this happen? None of the code pieces suggests that
> > > > > > it is
> > > > done in
> > > > > >U-Boot, is it performed in BootROM?
> > > > >
> > > > > I cannot see if current implementation(SPL/Uboot) has reservation
> > > > > done for imx8mm.
> > > > > In ATF, we are reserving the JR0.
> > > >
> > > > I was not able to identify which part of ATF code is responsible to
> > > > program JR0DID_MS on imx8mm, the only thing I saw was the part where
> > > > the JR0 is held in S World *if* the JR0DID_MS is set to 0x8011. Can
> > > > you point out where is this performed in ATF code?
> > > >
> > > > If it is not in the ATF, then my question above still stands: which
> > > > component (HW or SW) programs JR0DID_MS, and why is it only done on
> > > > imx8mm derivative?
> > > HAB which is part of the ROM code sets the JR DID for all i.mx8M.
> > > >
> > > > >
> > > > > > 2. What is the intention of having JR0 reserved for all
> > > > > > derivatives? Is
> > > this
> > > > > >the part of a bigger change that stretches across different
> > > > > > SW
> > > > components
> > > > > >(e.g. ATF, OP-TEE, etc.)? If that is the case - then a more 
> > > > > > detailed
> > > > > >description would be appreciated here.
> > > > > >
> > > > > > ATF code already accounts for this reservation in commit:
> > > > > > a83a7c65e ("TEE-639 plat: imx8m: Do not release JR0 to NS if HAB
> > > > > > is using it") [1], but there is no description on why is this 
> > > > > > required
> though.
> > > > > >
> > > > > > If this is required for HAB feature, then the question is:
> > > > > > should it be kept in
> > > > > S
> > > > > > World when U-Boot starts, or SPL can release it after the binary
> > > > > > is verified
> > > > > and
> > > > > > crypto facilities are not in use anymore?
> > > > >
> > > > > Commit: a83a7c65e reserves JR0 for HAB and not released to NS but
> &g

RE: [PATCH v5 11/16] crypto/fsl: Fix kick_trng

[ZHIZHIKIN Andrey]

Hello Gaurav,

> -Original Message-
> From: U-Boot  On Behalf Of Gaurav Jain
> Sent: Monday, November 15, 2021 8:00 AM
> To: u-boot@lists.denx.de
> Cc: Stefano Babic ; Fabio Estevam ; Peng 
> Fan
> ; Simon Glass ; Priyanka Jain
> ; Ye Li ; Horia Geanta
> ; Ji Luo ; Franck Lenormand
> ; Silvano Di Ninno ; Sahil
> malhotra ; Pankaj Gupta ; Varun
> Sethi ; NXP i . MX U-Boot Team ; Shengzhou
> Liu ; Mingkai Hu ; Rajesh Bhagat
> ; Meenakshi Aggarwal ; 
> Wasim
> Khan ; Alison Wang ; Pramod Kumar
> ; Tang Yuantian ; Adrian Alonso
> ; Vladimir Oltean 
> Subject: [PATCH v5 11/16] crypto/fsl: Fix kick_trng
> 
> 
> From: Ye Li 
> 
> fix hwrng performance issue in kernel.

This patch is missing some context information, specifically which performance
issue does exist in the Kernel (with some quantification), and how is it 
addressed
here.

This function introduced with this patch already exist in the Kernel [1], and 
the
implementation does differ from Kernel one. Specifically, this patch lowers the
number of test samples that are run to decide whether the entropy generated by
TRNG is sufficiently random: it reduces the monobit count range, poker test 
limits,
and number or runs for consecutive 0's and 1's.

Considering the fact that after TRNG is initialized - JDKEK, TDKEK and TDSK are
preloaded from the RNG and are locked until the next PoR, Kernel will not
re-initialize the TRNG (in fact, there is a check that is done in the Kernel 
not to
touch RNG if it is already initialized [2]), and this would leave the Crypto 
facilities
running in the Kernel to use entropy model that is defined here. In this case, 
at
least a justification of this change should be made clear - e.g. significant 
speed
improvement over reduced entropy (with quantifiable numbers).

In addition, with those new parameter set, would the RNG pass FIPS 140-2 test?

> 
> Signed-off-by: Ye Li 
> Acked-by: Gaurav Jain >
> ---
>  drivers/crypto/fsl/jr.c | 109 ++--
>  include/fsl_sec.h   |   1 +
>  2 files changed, 94 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
> index 9b751aca9b..ef136988b6 100644
> --- a/drivers/crypto/fsl/jr.c
> +++ b/drivers/crypto/fsl/jr.c
> @@ -602,30 +602,107 @@ static u8 get_rng_vid(ccsr_sec_t *sec)
>   */
>  static void kick_trng(int ent_delay, ccsr_sec_t *sec)
>  {
> +   u32 samples  = 512; /* number of bits to generate and test */
> +   u32 mono_min = 195;
> +   u32 mono_max = 317;
> +   u32 mono_range  = mono_max - mono_min;
> +   u32 poker_min = 1031;
> +   u32 poker_max = 1600;
> +   u32 poker_range = poker_max - poker_min + 1;
> +   u32 retries= 2;
> +   u32 lrun_max   = 32;
> +   s32 run_1_min   = 27;
> +   s32 run_1_max   = 107;
> +   s32 run_1_range = run_1_max - run_1_min;
> +   s32 run_2_min   = 7;
> +   s32 run_2_max   = 62;
> +   s32 run_2_range = run_2_max - run_2_min;
> +   s32 run_3_min   = 0;
> +   s32 run_3_max   = 39;
> +   s32 run_3_range = run_3_max - run_3_min;
> +   s32 run_4_min   = -1;
> +   s32 run_4_max   = 26;
> +   s32 run_4_range = run_4_max - run_4_min;
> +   s32 run_5_min   = -1;
> +   s32 run_5_max   = 18;
> +   s32 run_5_range = run_5_max - run_5_min;
> +   s32 run_6_min   = -1;
> +   s32 run_6_max   = 17;
> +   s32 run_6_range = run_6_max - run_6_min;
> +   u32 val;

Why does those values are lowered with respect to what is provided by
default? A bit more explanation on why those primes are chosen here
would be good to have, together with documenting default values (so
people can compare).

> +
> struct rng4tst __iomem *rng =
> (struct rng4tst __iomem *)>rng;
> -   u32 val;
> 
> -   /* put RNG4 into program mode */
> -   sec_setbits32(>rtmctl, RTMCTL_PRGM);
> -   /* rtsdctl bits 0-15 contain "Entropy Delay, which defines the
> -* length (in system clocks) of each Entropy sample taken
> -* */
> +   /* Put RNG in program mode */
> +   /* Setting both RTMCTL:PRGM and RTMCTL:TRNG_ACC causes TRNG to
> +* properly invalidate the entropy in the entropy register and
> +* force re-generation.
> +*/
> +   sec_setbits32(>rtmctl, RTMCTL_PRGM | RTMCTL_ACC);
> +
> +   /* Configure the RNG Entropy Delay
> +* Performance-wise, it does not make sense to
> +* set the delay to a value that is lower
> +* than the last one that worked (i.e. the state handles
> +* were instantiated properly. Thus, instead of wasting
> +* time trying to set the values controlling the sample
> +* frequency, the function simply returns.
> +*/
> val = sec_in32(>rtsdctl);
> -   val = (val & ~RTSDCTL_ENT_DLY_MASK) |
> - (ent_delay << RTSDCTL_ENT_DLY_SHIFT);
> +   val &= RTSDCTL_ENT_DLY_MASK;
> +   val >>= RTSDCTL_ENT_DLY_SHIFT;
> +   

RE: [EXT] RE: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job ring driver model

[ZHIZHIKIN Andrey]

Hello Gaurav,

> -Original Message-
> From: Gaurav Jain 
> Sent: Monday, November 22, 2021 8:29 AM
> To: ZHIZHIKIN Andrey ; u-
> b...@lists.denx.de
> Cc: Stefano Babic ; Fabio Estevam ; Peng 
> Fan
> ; Simon Glass ; Priyanka Jain
> ; Ye Li ; Horia Geanta
> ; Ji Luo ; Franck Lenormand
> ; Silvano Di Ninno ; Sahil
> Malhotra ; Pankaj Gupta ; Varun
> Sethi ; dl-uboot-imx ; Shengzhou Liu
> ; Mingkai Hu ; Rajesh Bhagat
> ; Meenakshi Aggarwal ; 
> Wasim
> Khan ; Alison Wang ; Pramod Kumar
> ; Andy Tang ; Adrian Alonso
> ; Vladimir Oltean 
> Subject: RE: [EXT] RE: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job 
> ring
> driver model
> 
> 
> Hello Andrey
> 
> > -Original Message-
> > From: ZHIZHIKIN Andrey 
> > Sent: Wednesday, November 17, 2021 6:33 PM
> > To: Gaurav Jain ; u-boot@lists.denx.de
> > Cc: Stefano Babic ; Fabio Estevam ;
> > Peng Fan ; Simon Glass ; Priyanka
> > Jain ; Ye Li ; Horia Geanta
> > ; Ji Luo ; Franck Lenormand
> > ; Silvano Di Ninno
> > ; Sahil Malhotra ;
> > Pankaj Gupta ; Varun Sethi ;
> > dl-uboot-imx ; Shengzhou Liu
> > ; Mingkai Hu ; Rajesh
> > Bhagat ; Meenakshi Aggarwal
> > ; Wasim Khan ;
> > Alison Wang ; Pramod Kumar
> > ; Andy Tang ; Adrian
> > Alonso ; Vladimir Oltean 
> > Subject: RE: [EXT] RE: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job
> > ring driver model
> >
> > Caution: EXT Email
> >
> > Hello Gaurav,
> >
> > > -Original Message-
> > > From: Gaurav Jain 
> > > Sent: Wednesday, November 17, 2021 12:26 PM
> > > To: ZHIZHIKIN Andrey ; u-
> > > b...@lists.denx.de
> > > Cc: Stefano Babic ; Fabio Estevam
> > > ; Peng Fan ; Simon Glass
> > > ; Priyanka Jain ; Ye Li
> > > ; Horia Geanta ; Ji Luo
> > > ; Franck Lenormand ;
> > Silvano
> > > Di Ninno ; Sahil Malhotra
> > > ; Pankaj Gupta ;
> > Varun
> > > Sethi ; dl-uboot-imx ;
> > Shengzhou
> > > Liu ; Mingkai Hu ;
> > Rajesh
> > > Bhagat ; Meenakshi Aggarwal
> > > ; Wasim Khan ;
> > Alison
> > > Wang ; Pramod Kumar
> > ;
> > > Andy Tang ; Adrian Alonso
> > ;
> > > Vladimir Oltean 
> > > Subject: RE: [EXT] RE: [PATCH v5 01/16] crypto/fsl: Add support for
> > > CAAM Job ring driver model
> > >
> > >
> > > Hello Andrey
> > >
> > > > -Original Message-
> > > > From: ZHIZHIKIN Andrey 
> > > > Sent: Tuesday, November 16, 2021 9:24 PM
> > > > To: Gaurav Jain ; u-boot@lists.denx.de
> > > > Cc: Stefano Babic ; Fabio Estevam
> > > > ; Peng Fan ; Simon Glass
> > > > ; Priyanka Jain ; Ye Li
> > > > ; Horia Geanta ; Ji Luo
> > > > ; Franck Lenormand ;
> > > > Silvano Di Ninno ; Sahil Malhotra
> > > > ; Pankaj Gupta ;
> > Varun
> > > > Sethi ; dl-uboot-imx ;
> > Shengzhou
> > > > Liu ; Mingkai Hu ;
> > Rajesh
> > > > Bhagat ; Meenakshi Aggarwal
> > > > ; Wasim Khan ;
> > > > Alison Wang ; Pramod Kumar
> > > > ; Andy Tang ;
> > Adrian
> > > > Alonso ; Vladimir Oltean 
> > > > Subject: [EXT] RE: [PATCH v5 01/16] crypto/fsl: Add support for CAAM
> > > > Job ring driver model
> > > >
> > > > Caution: EXT Email
> > > >
> > > > Hello Gaurav,
> > > >
> > > > > -Original Message-
> > > > > From: U-Boot  On Behalf Of Gaurav
> > > > > Jain
> > > > > Sent: Monday, November 15, 2021 8:00 AM
> > > > > To: u-boot@lists.denx.de
> > > > > Cc: Stefano Babic ; Fabio Estevam
> > > > > ; Peng Fan ; Simon Glass
> > > > > ; Priyanka Jain ; Ye Li
> > > > > ; Horia Geanta ; Ji Luo
> > > > > ; Franck Lenormand ;
> > > > > Silvano Di Ninno ; Sahil malhotra
> > > > > ; Pankaj Gupta ;
> > > > > Varun Sethi ; NXP i . MX U-Boot Team
> > > > > ; Shengzhou Liu ;
> > > > > Mingkai Hu ; Rajesh Bhagat
> > > > > ;
> > > > Meenakshi
> > > > > Aggarwal ; Wasim Khan
> > > > > ; Alison Wang ;
> > Pramod
> > > > Kumar
> > > > > ; Tang Yuantian ;
> > > > > Adrian Alonso ; Vladimir Oltean
> > > > > ; Gaurav Jain 
> > > > > Subject: [PATCH v5 01/16] crypto/fsl: Add 

RE: [RFC PATCH] imx8m: Drop env_get_location for imx8mn and imx8mp

[ZHIZHIKIN Andrey]

Hello Michael,

> -Original Message-
> From: Michael Nazzareno Trimarchi 
> Sent: Thursday, November 18, 2021 10:48 PM
> To: ZHIZHIKIN Andrey 
> Cc: Ye Li ; Stefano Babic ; Fabio Estevam
> ; u-boot@lists.denx.de; Ariel D'Alessandro
> ; linux-amar...@amarulasolutions.com; Anthony
> Brandon 
> Subject: Re: [RFC PATCH] imx8m: Drop env_get_location for imx8mn and imx8mp
> 
> 
> Hi ZHIZHIKIN

It's Andrey, mail client swaps last and first names. :)

> 
> On Thu, Nov 18, 2021 at 7:53 PM ZHIZHIKIN Andrey
>  wrote:
> >
> > Hello Michael,
> >
> > > -Original Message-
> > > From: U-Boot  On Behalf Of Michael Trimarchi
> > > Sent: Thursday, November 18, 2021 2:58 PM
> > > To: Ye Li ; Stefano Babic ; Fabio Estevam
> > > 
> > > Cc: u-boot@lists.denx.de; Ariel D'Alessandro
> ;
> > > linux-amar...@amarulasolutions.com; Anthony Brandon
> > > 
> > > Subject: [RFC PATCH] imx8m: Drop env_get_location for imx8mn and imx8mp
> > >
> > >
> > > This function defined for two architecture is not really clean
> > > and can be generate problem when people add a new board
> >
> > Not sure what you mean by "not clean" and "can generate problems" here,
> > perhaps you can elaborate that more in commit message?
> >
> 
> Sorry, I will adjust the commit message. This should be done at board
> level, that
> would like to define the enviroment from it's own config or from some specific
> setup.

From your other patch I've seen on ML [1], combined with this one - it looks
like you're trying to revert 2707faf01f ("imx8mn/imx8mp: override env_get_offset
and env_get_location"). If you go ahead with both patches, then I suggest you
submit a revert instead.

> 
> > >
> > > Signed-off-by: Michael Trimarchi 
> > > ---
> > >  arch/arm/mach-imx/imx8m/soc.c | 42 ---
> >
> > Quick git grep shows that there are boards that have it implemented,
> > but only two CPU families have them:
> > - arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> > - arch/arm/mach-imx/imx8m/soc.c
> >
> > - board/aristainetos/aristainetos.c
> > - board/engicam/stm32mp1/stm32mp1.c
> >  -board/renesas/alt/alt.c
> > - board/renesas/gose/gose.c
> > - board/renesas/koelsch/koelsch.c
> > - board/renesas/lager/lager.c
> > - board/renesas/porter/porter.c
> > - board/renesas/silk/silk.c
> > - board/renesas/stout/stout.c
> > - board/sandbox/sandbox.c
> > - board/st/stm32mp1/stm32mp1.c
> > - board/sunxi/board.c
> > - board/xilinx/versal/board.c
> > - board/xilinx/zynq/board.c
> > - board/xilinx/zynqmp/zynqmp.c
> >
> > If it does interfere with certain things you do - why not moving
> > it to imx8mn-evk and imx8mp-evk instead? At least this would give
> > adopters a hint, as EVKs are normally a reference target.
> 
> Yes, the patch is only involve the imx8mp and imx8mn.
> For the problem is that make no sense to define an unique way for multiple
> board. One board can boot from emmc and having env on spi flash etc

I see, but this is rather a specialization to me. How can one ensure
that the env deployed on another storage device is valid for the media
you're booting from?

Anyways, I suggest that this function is kept in both imx8mn and imx8mp
evk boards instead of being completely dropped.

> 
> Michael
> >
> > -- andrey
> 
> 
> 
> --
> Michael Nazzareno Trimarchi
> Co-Founder & Chief Executive Officer
> M. +39 347 913 2170
> mich...@amarulasolutions.com
> __
> 
> Amarula Solutions BV
> Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
> T. +31 (0)85 111 9172
> i...@amarulasolutions.com

Link: [1]: 
http://patchwork.ozlabs.org/project/uboot/patch/2027143456.34441-1-mich...@amarulasolutions.com/

-- andrey

RE: [RFC PATCH] imx8m: Drop env_get_location for imx8mn and imx8mp

[ZHIZHIKIN Andrey]

Hello Michael,

> -Original Message-
> From: U-Boot  On Behalf Of Michael Trimarchi
> Sent: Thursday, November 18, 2021 2:58 PM
> To: Ye Li ; Stefano Babic ; Fabio Estevam
> 
> Cc: u-boot@lists.denx.de; Ariel D'Alessandro 
> ;
> linux-amar...@amarulasolutions.com; Anthony Brandon
> 
> Subject: [RFC PATCH] imx8m: Drop env_get_location for imx8mn and imx8mp
> 
> 
> This function defined for two architecture is not really clean
> and can be generate problem when people add a new board

Not sure what you mean by "not clean" and "can generate problems" here,
perhaps you can elaborate that more in commit message?

> 
> Signed-off-by: Michael Trimarchi 
> ---
>  arch/arm/mach-imx/imx8m/soc.c | 42 ---

Quick git grep shows that there are boards that have it implemented,
but only two CPU families have them:
- arch/arm/cpu/armv8/fsl-layerscape/cpu.c
- arch/arm/mach-imx/imx8m/soc.c

- board/aristainetos/aristainetos.c
- board/engicam/stm32mp1/stm32mp1.c
 -board/renesas/alt/alt.c
- board/renesas/gose/gose.c
- board/renesas/koelsch/koelsch.c
- board/renesas/lager/lager.c
- board/renesas/porter/porter.c
- board/renesas/silk/silk.c
- board/renesas/stout/stout.c
- board/sandbox/sandbox.c
- board/st/stm32mp1/stm32mp1.c
- board/sunxi/board.c
- board/xilinx/versal/board.c
- board/xilinx/zynq/board.c
- board/xilinx/zynqmp/zynqmp.c

If it does interfere with certain things you do - why not moving
it to imx8mn-evk and imx8mp-evk instead? At least this would give
adopters a hint, as EVKs are normally a reference target.

-- andrey

RE: [EXT] RE: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job ring driver model

[ZHIZHIKIN Andrey]

Hello Gaurav,

> -Original Message-
> From: ZHIZHIKIN Andrey
> Sent: Wednesday, November 17, 2021 2:03 PM
> To: Gaurav Jain ; u-boot@lists.denx.de
> Cc: Stefano Babic ; Fabio Estevam ; Peng 
> Fan
> ; Simon Glass ; Priyanka Jain
> ; Ye Li ; Horia Geanta
> ; Ji Luo ; Franck Lenormand
> ; Silvano Di Ninno ; Sahil
> Malhotra ; Pankaj Gupta ; Varun
> Sethi ; dl-uboot-imx ; Shengzhou Liu
> ; Mingkai Hu ; Rajesh Bhagat
> ; Meenakshi Aggarwal ; 
> Wasim
> Khan ; Alison Wang ; Pramod Kumar
> ; Andy Tang ; Adrian Alonso
> ; Vladimir Oltean 
> Subject: RE: [EXT] RE: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job 
> ring
> driver model
> 
> Hello Gaurav,
> 
> > -Original Message-
> > From: Gaurav Jain 
> > Sent: Wednesday, November 17, 2021 12:26 PM
> > To: ZHIZHIKIN Andrey ; u-
> > b...@lists.denx.de
> > Cc: Stefano Babic ; Fabio Estevam ; Peng
> Fan
> > ; Simon Glass ; Priyanka Jain
> > ; Ye Li ; Horia Geanta
> > ; Ji Luo ; Franck Lenormand
> > ; Silvano Di Ninno ; 
> > Sahil
> > Malhotra ; Pankaj Gupta ; 
> > Varun
> > Sethi ; dl-uboot-imx ; Shengzhou Liu
> > ; Mingkai Hu ; Rajesh Bhagat
> > ; Meenakshi Aggarwal ; 
> > Wasim
> > Khan ; Alison Wang ; Pramod Kumar
> > ; Andy Tang ; Adrian Alonso
> > ; Vladimir Oltean 
> > Subject: RE: [EXT] RE: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job
> ring
> > driver model
> >
> >
> > Hello Andrey
> >
> > > -Original Message-
> > > From: ZHIZHIKIN Andrey 
> > > Sent: Tuesday, November 16, 2021 9:24 PM
> > > To: Gaurav Jain ; u-boot@lists.denx.de
> > > Cc: Stefano Babic ; Fabio Estevam ;
> > > Peng Fan ; Simon Glass ; Priyanka
> > > Jain ; Ye Li ; Horia Geanta
> > > ; Ji Luo ; Franck Lenormand
> > > ; Silvano Di Ninno ;
> > > Sahil Malhotra ; Pankaj Gupta
> > > ; Varun Sethi ; dl-uboot-imx
> > > ; Shengzhou Liu ; Mingkai Hu
> > > ; Rajesh Bhagat ; Meenakshi
> > > Aggarwal ; Wasim Khan
> > > ; Alison Wang ; Pramod
> > > Kumar ; Andy Tang ;
> > > Adrian Alonso ; Vladimir Oltean 
> > > Subject: [EXT] RE: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job 
> > > ring
> > > driver model
> > >
> > > Caution: EXT Email
> > >
> > > Hello Gaurav,
> > >
> > > > -Original Message-
> > > > From: U-Boot  On Behalf Of Gaurav Jain
> > > > Sent: Monday, November 15, 2021 8:00 AM
> > > > To: u-boot@lists.denx.de
> > > > Cc: Stefano Babic ; Fabio Estevam
> > > > ; Peng Fan ; Simon Glass
> > > > ; Priyanka Jain ; Ye Li
> > > > ; Horia Geanta ; Ji Luo
> > > > ; Franck Lenormand ; Silvano
> > > > Di Ninno ; Sahil malhotra
> > > > ; Pankaj Gupta ; Varun
> > > > Sethi ; NXP i . MX U-Boot Team ;
> > > > Shengzhou Liu ; Mingkai Hu
> > > > ; Rajesh Bhagat ;
> > > Meenakshi
> > > > Aggarwal ; Wasim Khan
> > > > ; Alison Wang ; Pramod
> > > Kumar
> > > > ; Tang Yuantian ; Adrian
> > > > Alonso ; Vladimir Oltean ;
> > > > Gaurav Jain 
> > > > Subject: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job ring
> > > > driver model
> > > >
> > > >
> > > > added device tree support for job ring driver.
> > > > sec is initialized based on job ring information processed from device
> > > > tree.
> > > >
> > > > Signed-off-by: Gaurav Jain 
> > > > Reviewed-by: Ye Li 
> > > > ---
> > > >  cmd/Kconfig |   1 +
> > > >  drivers/crypto/fsl/Kconfig  |   7 +
> > > >  drivers/crypto/fsl/Makefile |   4 +-
> > > >  drivers/crypto/fsl/jr.c | 316 +++-
> > > >  drivers/crypto/fsl/jr.h |  14 ++
> > > >  5 files changed, 232 insertions(+), 110 deletions(-)
> > > >
> 
> [snip]
> 
> > > > sec_out32(>mcfgr, mcr);
> > > > +#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_IMX8M)
> > >
> > > This would effectively reserve the JR0 on _all_ i.MX8M derivatives is S
> World.
> > This code is to set any JR DID in SPL so that the job ring can be 
> > configured.
> >
> > >
> > > Current implementation only has JR0 reserved in S World on imx8mm 
> > > derivative,
> > > but this new addition extends this to

RE: [EXT] RE: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job ring driver model

[ZHIZHIKIN Andrey]

Hello Gaurav,

> -Original Message-
> From: Gaurav Jain 
> Sent: Wednesday, November 17, 2021 12:26 PM
> To: ZHIZHIKIN Andrey ; u-
> b...@lists.denx.de
> Cc: Stefano Babic ; Fabio Estevam ; Peng 
> Fan
> ; Simon Glass ; Priyanka Jain
> ; Ye Li ; Horia Geanta
> ; Ji Luo ; Franck Lenormand
> ; Silvano Di Ninno ; Sahil
> Malhotra ; Pankaj Gupta ; Varun
> Sethi ; dl-uboot-imx ; Shengzhou Liu
> ; Mingkai Hu ; Rajesh Bhagat
> ; Meenakshi Aggarwal ; 
> Wasim
> Khan ; Alison Wang ; Pramod Kumar
> ; Andy Tang ; Adrian Alonso
> ; Vladimir Oltean 
> Subject: RE: [EXT] RE: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job 
> ring
> driver model
> 
> 
> Hello Andrey
> 
> > -Original Message-
> > From: ZHIZHIKIN Andrey 
> > Sent: Tuesday, November 16, 2021 9:24 PM
> > To: Gaurav Jain ; u-boot@lists.denx.de
> > Cc: Stefano Babic ; Fabio Estevam ;
> > Peng Fan ; Simon Glass ; Priyanka
> > Jain ; Ye Li ; Horia Geanta
> > ; Ji Luo ; Franck Lenormand
> > ; Silvano Di Ninno ;
> > Sahil Malhotra ; Pankaj Gupta
> > ; Varun Sethi ; dl-uboot-imx
> > ; Shengzhou Liu ; Mingkai Hu
> > ; Rajesh Bhagat ; Meenakshi
> > Aggarwal ; Wasim Khan
> > ; Alison Wang ; Pramod
> > Kumar ; Andy Tang ;
> > Adrian Alonso ; Vladimir Oltean 
> > Subject: [EXT] RE: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job 
> > ring
> > driver model
> >
> > Caution: EXT Email
> >
> > Hello Gaurav,
> >
> > > -Original Message-
> > > From: U-Boot  On Behalf Of Gaurav Jain
> > > Sent: Monday, November 15, 2021 8:00 AM
> > > To: u-boot@lists.denx.de
> > > Cc: Stefano Babic ; Fabio Estevam
> > > ; Peng Fan ; Simon Glass
> > > ; Priyanka Jain ; Ye Li
> > > ; Horia Geanta ; Ji Luo
> > > ; Franck Lenormand ; Silvano
> > > Di Ninno ; Sahil malhotra
> > > ; Pankaj Gupta ; Varun
> > > Sethi ; NXP i . MX U-Boot Team ;
> > > Shengzhou Liu ; Mingkai Hu
> > > ; Rajesh Bhagat ;
> > Meenakshi
> > > Aggarwal ; Wasim Khan
> > > ; Alison Wang ; Pramod
> > Kumar
> > > ; Tang Yuantian ; Adrian
> > > Alonso ; Vladimir Oltean ;
> > > Gaurav Jain 
> > > Subject: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job ring
> > > driver model
> > >
> > >
> > > added device tree support for job ring driver.
> > > sec is initialized based on job ring information processed from device
> > > tree.
> > >
> > > Signed-off-by: Gaurav Jain 
> > > Reviewed-by: Ye Li 
> > > ---
> > >  cmd/Kconfig |   1 +
> > >  drivers/crypto/fsl/Kconfig  |   7 +
> > >  drivers/crypto/fsl/Makefile |   4 +-
> > >  drivers/crypto/fsl/jr.c | 316 +++-
> > >  drivers/crypto/fsl/jr.h |  14 ++
> > >  5 files changed, 232 insertions(+), 110 deletions(-)
> > >

[snip]

> > > sec_out32(>mcfgr, mcr);
> > > +#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_IMX8M)
> >
> > This would effectively reserve the JR0 on _all_ i.MX8M derivatives is S 
> > World.
> This code is to set any JR DID in SPL so that the job ring can be configured.
> 
> >
> > Current implementation only has JR0 reserved in S World on imx8mm 
> > derivative,
> > but this new addition extends this to imx8mn, imx8mp and imx8mq.
> Current implementation do not initialize CAAM for i.MX8M derivatives. It is 
> not
> based on driver model approach and only using JR0.

OK, but then I do not have on explanation on why do I see following results from
reading JRaDID_MS registers on imx8m derivatives:
- imx8mm:
JR0DID_MS = 0x8011
JR1DID_MS = 0x0
JR2DID_MS = 0x0
- imx8mn:
JR0DID_MS = 0x0
JR1DID_MS = 0x0
JR2DID_MS = 0x0
- imx8mp:
JR0DID_MS = 0x0
JR1DID_MS = 0x0
JR2DID_MS = 0x0

This readout is taken at Kernel boot, and it clearly shows that only JR0 has
TZ_OWN, PRIM_TZ and PRIM_DID bits set, and it is only done on imx8mm.

> With New implementation CAAM is enabled for i.MX8M derivative. Any JR whose 
> DID
> is written in ATF, can be used in Uboot.
> JR0 is reserved for HAB so JR1 will be used for all i.MX8M derivatives.
> 
> >
> > I'm wondering about several points here:
> > 1. Why does current implementation on have this reservation done on imx8mm
> > and
> >where does this happen? None of the code pieces suggests that it is done 
> > in
> >U-Boot, is it performed in BootROM?
> 
> I canno

RE: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job ring driver model

[ZHIZHIKIN Andrey]

Hello Gaurav,

> -Original Message-
> From: U-Boot  On Behalf Of Gaurav Jain
> Sent: Monday, November 15, 2021 8:00 AM
> To: u-boot@lists.denx.de
> Cc: Stefano Babic ; Fabio Estevam ; Peng 
> Fan
> ; Simon Glass ; Priyanka Jain
> ; Ye Li ; Horia Geanta
> ; Ji Luo ; Franck Lenormand
> ; Silvano Di Ninno ; Sahil
> malhotra ; Pankaj Gupta ; Varun
> Sethi ; NXP i . MX U-Boot Team ; Shengzhou
> Liu ; Mingkai Hu ; Rajesh Bhagat
> ; Meenakshi Aggarwal ; 
> Wasim
> Khan ; Alison Wang ; Pramod Kumar
> ; Tang Yuantian ; Adrian Alonso
> ; Vladimir Oltean ; Gaurav Jain
> 
> Subject: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job ring driver 
> model
> 
> 
> added device tree support for job ring driver.
> sec is initialized based on job ring information processed
> from device tree.
> 
> Signed-off-by: Gaurav Jain 
> Reviewed-by: Ye Li 
> ---
>  cmd/Kconfig |   1 +
>  drivers/crypto/fsl/Kconfig  |   7 +
>  drivers/crypto/fsl/Makefile |   4 +-
>  drivers/crypto/fsl/jr.c | 316 +++-
>  drivers/crypto/fsl/jr.h |  14 ++
>  5 files changed, 232 insertions(+), 110 deletions(-)
> 
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 5b30b13e43..2b24672505 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -2009,6 +2009,7 @@ config CMD_AES
> 
>  config CMD_BLOB
> bool "Enable the 'blob' command"
> +   select FSL_BLOB
> depends on !MX6ULL && !MX6SLL && !MX6SL
> select IMX_HAB if ARCH_MX6 || ARCH_MX7 || ARCH_MX7ULP || ARCH_IMX8M
> help
> diff --git a/drivers/crypto/fsl/Kconfig b/drivers/crypto/fsl/Kconfig
> index 94ff540111..ab59d516f8 100644
> --- a/drivers/crypto/fsl/Kconfig
> +++ b/drivers/crypto/fsl/Kconfig
> @@ -66,4 +66,11 @@ config FSL_CAAM_RNG
>   using the prediction resistance flag which means the DRGB is
>   reseeded from the TRNG every time random data is generated.
> 
> +config FSL_BLOB
> +bool "Enable Blob Encap/Decap, Blob KEK support"
> +   help
> + Enable support for the hardware based crytographic blob encap/decap
> + module of the CAAM. blobs can be safely placed into non-volatile
> + storage. blobs can only be decapsulated by the SoC that created it.
> + Enable support for blob key encryption key generation.
>  endif
> diff --git a/drivers/crypto/fsl/Makefile b/drivers/crypto/fsl/Makefile
> index f9c3ccecfc..738535b8e4 100644
> --- a/drivers/crypto/fsl/Makefile
> +++ b/drivers/crypto/fsl/Makefile
> @@ -1,10 +1,12 @@
>  # SPDX-License-Identifier: GPL-2.0+
>  #
>  # Copyright 2014 Freescale Semiconductor, Inc.
> +# Copyright 2021 NXP
> 
>  obj-y += sec.o
>  obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o
> -obj-$(CONFIG_CMD_BLOB)$(CONFIG_IMX_CAAM_DEK_ENCAP) += fsl_blob.o
> +obj-$(CONFIG_FSL_BLOB) += fsl_blob.o
> +obj-$(CONFIG_IMX_CAAM_DEK_ENCAP) += fsl_blob.o
>  obj-$(CONFIG_RSA_FREESCALE_EXP) += fsl_rsa.o
>  obj-$(CONFIG_FSL_CAAM_RNG) += rng.o
>  obj-$(CONFIG_FSL_MFGPROT) += fsl_mfgprot.o
> diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
> index 22b649219e..eea2225a1e 100644
> --- a/drivers/crypto/fsl/jr.c
> +++ b/drivers/crypto/fsl/jr.c
> @@ -1,7 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
>   * Copyright 2008-2014 Freescale Semiconductor, Inc.
> - * Copyright 2018 NXP
> + * Copyright 2018, 2021 NXP
>   *
>   * Based on CAAM driver in drivers/crypto/caam in Linux
>   */
> @@ -11,7 +11,6 @@
>  #include 
>  #include 
>  #include 
> -#include "fsl_sec.h"
>  #include "jr.h"
>  #include "jobdesc.h"
>  #include "desc_constr.h"
> @@ -21,8 +20,11 @@
>  #include 
>  #include 
>  #endif
> +#include 
>  #include 
>  #include 
> +#include 
> +#include 
> 
>  #define CIRC_CNT(head, tail, size) (((head) - (tail)) & (size - 1))
>  #define CIRC_SPACE(head, tail, size)   CIRC_CNT((tail), (head) + 1, (size))
> @@ -35,20 +37,30 @@ uint32_t sec_offset[CONFIG_SYS_FSL_MAX_NUM_OF_SEC] = {
>  #endif
>  };
> 
> +#if CONFIG_IS_ENABLED(DM)
> +struct udevice *caam_dev;
> +#else
>  #define SEC_ADDR(idx)  \
> (ulong)((CONFIG_SYS_FSL_SEC_ADDR + sec_offset[idx]))
> 
>  #define SEC_JR0_ADDR(idx)  \
> (ulong)(SEC_ADDR(idx) + \
>  (CONFIG_SYS_FSL_JR0_OFFSET - CONFIG_SYS_FSL_SEC_OFFSET))
> +struct caam_regs caam_st;
> +#endif
> 
> -struct jobring jr0[CONFIG_SYS_FSL_MAX_NUM_OF_SEC];
> +static inline u32 jr_start_reg(u8 jrid)
> +{
> +   return (1 << jrid);
> +}
> 
> -static inline void start_jr0(uint8_t sec_idx)
> +#ifndef CONFIG_ARCH_IMX8
> +static inline void start_jr(struct caam_regs *caam)
>  {
> -   ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
> +   ccsr_sec_t *sec = caam->sec;
> u32 ctpr_ms = sec_in32(>ctpr_ms);
> u32 scfgr = sec_in32(>scfgr);
> +   u32 jrstart = jr_start_reg(caam->jrid);
> 
> if (ctpr_ms & SEC_CTPR_MS_VIRT_EN_INCL) {
> /* VIRT_EN_INCL = 1 & VIRT_EN_POR = 1 or
> @@ -56,23 +68,17 @@ static inline void start_jr0(uint8_t sec_idx)
>

RE: [EXT] Re: [PATCH v4 03/16] i.MX8M: crypto: updated device tree for supporting DM in SPL

[ZHIZHIKIN Andrey]

Hello Gurav,

I'll Cc: Michael Walle here for the reason described below.

> -Original Message-
> From: Gaurav Jain 
> Sent: Monday, November 8, 2021 9:21 AM
> To: ZHIZHIKIN Andrey ; Adam Ford
> 
> Cc: U-Boot Mailing List ; Stefano Babic
> ; Fabio Estevam ; Peng Fan
> ; Simon Glass ; Priyanka Jain
> ; Ye Li ; Horia Geanta
> ; Ji Luo ; Franck Lenormand
> ; Silvano Di Ninno ;
> Sahil Malhotra ; Pankaj Gupta
> ; Varun Sethi ; dl-uboot-imx
> ; Shengzhou Liu ; Mingkai Hu
> ; Rajesh Bhagat ; Meenakshi
> Aggarwal ; Wasim Khan
> ; Alison Wang ; Pramod Kumar
> ; Andy Tang ; Adrian
> Alonso ; Vladimir Oltean 
> Subject: RE: [EXT] Re: [PATCH v4 03/16] i.MX8M: crypto: updated device tree 
> for
> supporting DM in SPL
>  
> 
> Hello Andrey
> 
> > -Original Message-
> > From: ZHIZHIKIN Andrey 
> > Sent: Wednesday, November 3, 2021 5:05 PM
> > To: Adam Ford ; Gaurav Jain 
> > Cc: U-Boot Mailing List ; Stefano Babic
> > ; Fabio Estevam ; Peng Fan
> > ; Simon Glass ; Priyanka Jain
> > ; Ye Li ; Horia Geanta
> > ; Ji Luo ; Franck Lenormand
> > ; Silvano Di Ninno
> > ; Sahil Malhotra ;
> > Pankaj Gupta ; Varun Sethi ;
> > dl-uboot-imx ; Shengzhou Liu
> > ; Mingkai Hu ; Rajesh
> > Bhagat ; Meenakshi Aggarwal
> > ; Wasim Khan ;
> Alison
> > Wang ; Pramod Kumar ;
> > Andy Tang ; Adrian Alonso ;
> > Vladimir Oltean 
> > Subject: RE: [EXT] Re: [PATCH v4 03/16] i.MX8M: crypto: updated device
> > tree for supporting DM in SPL
> >
> > Caution: EXT Email
> >
> > Hello Gurav/Adam ,
> >
> > > -Original Message-
> > > From: U-Boot  On Behalf Of Adam Ford
> > > Sent: Tuesday, November 2, 2021 12:19 PM
> > > To: Gaurav Jain 
> > > Cc: U-Boot Mailing List ; Stefano Babic
> > > ; Fabio Estevam ; Peng Fan
> > > ; Simon Glass ; Priyanka Jain
> > > ; Ye Li ; Horia Geanta
> > > ; Ji Luo ; Franck Lenormand
> > > ; Silvano Di Ninno
> > > ; Sahil Malhotra ;
> > > Pankaj Gupta ; Varun Sethi ;
> > > dl-uboot-imx ; Shengzhou Liu
> > > ; Mingkai Hu ; Rajesh
> > > Bhagat ; Meenakshi Aggarwal
> > > ; Wasim Khan ;
> > Alison
> > > Wang ; Pramod Kumar
> > ;
> > > Andy Tang ; Adrian Alonso
> > > ; Vladimir Oltean 
> > > Subject: Re: [EXT] Re: [PATCH v4 03/16] i.MX8M: crypto: updated
> > > device tree for supporting DM in SPL
> > >
> > >
> > > On Tue, Nov 2, 2021 at 3:17 AM Gaurav Jain  wrote:
> > > >
> > > > Hello Adam
> > > >
> > > > > -Original Message-
> > > > > From: Adam Ford 
> > > > > Sent: Monday, November 1, 2021 6:30 PM
> > > > > To: Gaurav Jain 
> > > > > Cc: U-Boot Mailing List ; Stefano Babic
> > > > > ; Fabio Estevam ; Peng Fan
> > > > > ; Simon Glass ; Priyanka
> > > > > Jain ; Ye Li ; Horia
> > > > > Geanta ; Ji Luo ; Franck
> > > > > Lenormand ; Silvano Di Ninno
> > > > > ; Sahil Malhotra
> > > > > ; Pankaj Gupta ;
> > > > > Varun Sethi ; dl-uboot-imx ;
> > > > > Shengzhou Liu ; Mingkai Hu
> > > > > ; Rajesh Bhagat ;
> > > > > Meenakshi Aggarwal ; Wasim Khan
> > > > > ; Alison Wang ; Pramod
> > > > > Kumar ; Andy Tang ;
> > > > > Adrian Alonso ; Vladimir Oltean
> > > > > 
> > > > > Subject: [EXT] Re: [PATCH v4 03/16] i.MX8M: crypto: updated
> > > > > device tree for supporting DM in SPL
> > > > >
> > > > > Caution: EXT Email
> > > > >
> > > > > On Tue, Oct 26, 2021 at 1:57 AM Gaurav Jain
> > > > > 
> > wrote:
> > > > > >
> > > > > > disabled use of JR0 in SPL and uboot, as JR0 is reserved for
> > > > > > secure boot.
> > > > > >
> > > > > > Signed-off-by: Gaurav Jain 
> > > > > > Reviewed-by: Ye Li 
> > > > > > ---
> > > > > >  arch/arm/dts/imx8mm-evk-u-boot.dtsi  | 18 +-
> > > > > >  arch/arm/dts/imx8mm.dtsi |  1 +
> > > > > >  arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi | 18
> +-
> > > > > >  arch/arm/dts/imx8mn.dtsi |  1 +
> > > > > >  arch/arm/dts/imx8mp-evk-u-boot.dtsi   

RE: [EXT] Re: [PATCH v4 03/16] i.MX8M: crypto: updated device tree for supporting DM in SPL

[ZHIZHIKIN Andrey]

Hello Gurav/Adam ,

> -Original Message-
> From: U-Boot  On Behalf Of Adam Ford
> Sent: Tuesday, November 2, 2021 12:19 PM
> To: Gaurav Jain 
> Cc: U-Boot Mailing List ; Stefano Babic
> ; Fabio Estevam ; Peng Fan
> ; Simon Glass ; Priyanka Jain
> ; Ye Li ; Horia Geanta
> ; Ji Luo ; Franck Lenormand
> ; Silvano Di Ninno ;
> Sahil Malhotra ; Pankaj Gupta
> ; Varun Sethi ; dl-uboot-imx
> ; Shengzhou Liu ; Mingkai Hu
> ; Rajesh Bhagat ; Meenakshi
> Aggarwal ; Wasim Khan
> ; Alison Wang ; Pramod Kumar
> ; Andy Tang ; Adrian
> Alonso ; Vladimir Oltean 
> Subject: Re: [EXT] Re: [PATCH v4 03/16] i.MX8M: crypto: updated device tree 
> for
> supporting DM in SPL
> 
> 
> On Tue, Nov 2, 2021 at 3:17 AM Gaurav Jain  wrote:
> >
> > Hello Adam
> >
> > > -Original Message-
> > > From: Adam Ford 
> > > Sent: Monday, November 1, 2021 6:30 PM
> > > To: Gaurav Jain 
> > > Cc: U-Boot Mailing List ; Stefano Babic
> > > ; Fabio Estevam ; Peng Fan
> > > ; Simon Glass ; Priyanka Jain
> > > ; Ye Li ; Horia Geanta
> > > ; Ji Luo ; Franck Lenormand
> > > ; Silvano Di Ninno
> > > ; Sahil Malhotra ;
> > > Pankaj Gupta ; Varun Sethi ;
> > > dl-uboot-imx ; Shengzhou Liu
> > > ; Mingkai Hu ; Rajesh
> > > Bhagat ; Meenakshi Aggarwal
> > > ; Wasim Khan ;
> > > Alison Wang ; Pramod Kumar
> > > ; Andy Tang ; Adrian
> > > Alonso ; Vladimir Oltean 
> > > Subject: [EXT] Re: [PATCH v4 03/16] i.MX8M: crypto: updated device
> > > tree for supporting DM in SPL
> > >
> > > Caution: EXT Email
> > >
> > > On Tue, Oct 26, 2021 at 1:57 AM Gaurav Jain  wrote:
> > > >
> > > > disabled use of JR0 in SPL and uboot, as JR0 is reserved for
> > > > secure boot.
> > > >
> > > > Signed-off-by: Gaurav Jain 
> > > > Reviewed-by: Ye Li 
> > > > ---
> > > >  arch/arm/dts/imx8mm-evk-u-boot.dtsi  | 18 +-
> > > >  arch/arm/dts/imx8mm.dtsi |  1 +
> > > >  arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi | 18 +-
> > > >  arch/arm/dts/imx8mn.dtsi |  1 +
> > > >  arch/arm/dts/imx8mp-evk-u-boot.dtsi  | 18 +-
> > > >  arch/arm/dts/imx8mp.dtsi |  1 +
> > > >  arch/arm/dts/imx8mq.dtsi |  1 +
> > > >  7 files changed, 55 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> > > > b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> > > > index 3c75415e8f..40f5cfda9a 100644
> > > > --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> > > > +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> > > > @@ -1,6 +1,6 @@
> > > >  // SPDX-License-Identifier: GPL-2.0+
> > > >  /*
> > > > - * Copyright 2019 NXP
> > > > + * Copyright 2019, 2021 NXP
> > > >   */
> > > >
> > > >  #include "imx8mm-u-boot.dtsi"
> > > > @@ -72,6 +72,22 @@
> > > > u-boot,dm-spl;
> > > >  };
> > > >
> > > > + {
> > > > +   u-boot,dm-spl;
> > > > +};
> > > > +
> > > > +_jr0 {
> > > > +   u-boot,dm-spl;
> > > > +};
> > > > +
> > > > +_jr1 {
> > > > +   u-boot,dm-spl;
> > > > +};
> > > > +
> > > > +_jr2 {
> > > > +   u-boot,dm-spl;
> > > > +};
> > > > +
> > > >   {
> > > > u-boot,dm-spl;
> > > >  };
> > > > diff --git a/arch/arm/dts/imx8mm.dtsi b/arch/arm/dts/imx8mm.dtsi
> > > > index b142b80734..00bf3a 100644
> > > > --- a/arch/arm/dts/imx8mm.dtsi
> > > > +++ b/arch/arm/dts/imx8mm.dtsi
> > > > @@ -824,6 +824,7 @@
> > > > compatible = 
> > > > "fsl,sec-v4.0-job-ring";
> > > > reg = <0x1000 0x1000>;
> > > > interrupts =  > > > IRQ_TYPE_LEVEL_HIGH>;
> > > > +   status = "disabled";
> > >
> > > Changing the SoC DTSI files makes future re-synchronizing difficult.
> > > If you mark these as disabled in the respective u-boot.dtsi files,
> > > it will create less work in the future.  You're already enabling a
> > > bunch of new features in the respective -u-boot.dtsi files, I would 
> > > suggest
> doing the disable in the same way.
> >
> > JR0 status is marked as disabled, as it is reserved in ATF and cannot be 
> > accessed
> in SPL and Uboot.
> > For JR driver model(new feature) to work, at least one Jobring has to be
> initialized, which is not possible with JR0.
> > JR1 will be initialized.
> 
> I wasn't suggesting that it should not be disabled.  I was asking that it be 
> disabled
> in the -u-boot.dtsi file instead of the imx8mm.dtsi file because when the
> imx8mm.dtsi file gets resync'd with Linux, it might be lost.  Having it done 
> in the -
> u-boot.dtsi file instead helps reduce the likelihood of being undone later, 
> and
> that is the purpose of the -u-boot.dtsi files.

If I may add my 2c here:
It seems to me that this patch should be split into at least 2 separate 
patches: one that disables the JR0 node, and one - for the rest.

The reason being: if the JR0 node is reserved for ATF and should not be 
available - then it should be disabled in the Kernel DTB as well as here.

This 

RE: [PATCH] arm: dts: imx8mp: Delete default clocks for clock controller node

[ZHIZHIKIN Andrey]

Hello Stefano,

> -Original Message-
> From: U-Boot  On Behalf Of Teresa Remmet
> Sent: Thursday, August 26, 2021 9:20 AM
> To: feste...@gmail.com; u-boot@lists.denx.de; sba...@denx.de;
> ye...@nxp.com; peng@nxp.com
> Cc: uboot-...@nxp.com
> Subject: Re: [PATCH] arm: dts: imx8mp: Delete default clocks for clock 
> controller
> node
> 
> Am Dienstag, den 17.08.2021, 14:32 +0800 schrieb Ye Li:
> > Since SPL has initialized clocks for bus and core. We don't need to
> > set the default clocks for clock controller node.

Just a ping on this patch, it seems that without this path uSDHC controllers 
are not being correctly probed, hence the boot sequence is blocked.
Applying this patch does solve the probing.

Can you please consider taking this patch?

> >
> > Signed-off-by: Ye Li 
> 
> Tested-by: Teresa Remmet 

Tested-by: Andrey Zhizhikin 

> 
> > ---
> >  arch/arm/dts/imx8mp-u-boot.dtsi | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm/dts/imx8mp-u-boot.dtsi b/arch/arm/dts/imx8mp-u-
> > boot.dtsi index d61346d..a6ede2e 100644
> > --- a/arch/arm/dts/imx8mp-u-boot.dtsi
> > +++ b/arch/arm/dts/imx8mp-u-boot.dtsi
> > @@ -18,6 +18,9 @@
> >   {
> >   u-boot,dm-spl;
> >   u-boot,dm-pre-reloc;
> > + /delete-property/ assigned-clocks;
> > + /delete-property/ assigned-clock-parents;
> > + /delete-property/ assigned-clock-rates;
> >  };
> >
> >  _32k {

RE: [PATCH v1 1/7] imx: mkimage_fit_atf: fix legacy image generation

[ZHIZHIKIN Andrey]

Hello Fabio,

> -Original Message-
> From: Fabio Estevam 
> Sent: Monday, August 23, 2021 1:00 PM
> To: ZHIZHIKIN Andrey 
> Cc: Marcel Ziswiler ; u-boot@lists.denx.de;
> peng@nxp.com; uboot-...@nxp.com; sba...@denx.de;
> frieder.schre...@kontron.de; heiko.thi...@gmail.com; Oliver Graute
> 
> Subject: Re: [PATCH v1 1/7] imx: mkimage_fit_atf: fix legacy image generation
> 
> 
>  Hi Andrey,
> 
> >
> > Verdin gets converted with your other patch, while for all the others I'm 
> > not
> sure what the status is.
> >
> 
> Peng sent a patch series converting imx8mq_evk, pico-imx8mq and
> imx8mq_phanbell to  binman:
> https://www.mail-archive.com/u-boot@lists.denx.de/msg414962.html
> 

Thanks for pointing it out!

I guess the short list of affected candidates when mkimage_fit_atf.sh FIT 
generator gets deleted then would be:

configs/cgtqmx8_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8mm-icore-mx8mm-ctouch2_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8mm-icore-mx8mm-edimm2.2_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8mm_beacon_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8mm_venice_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8mn_beacon_2g_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8mn_beacon_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8qm_rom7720_a1_4G_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/phycore-imx8mm_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"

Should I send out an RFC to have the FIT generator script removed for 
'mach-imx'?

This would trigger the build failures for those derivatives, but since it is 
broken anyway - this would need to be solved by maintainers migrating them to 
binman.

> Regards,
> 
> Fabio Estevam

Regards,
Andrey

RE: [PATCH v1 1/7] imx: mkimage_fit_atf: fix legacy image generation

[ZHIZHIKIN Andrey]

Hello Marcel!

> -Original Message-
> From: Marcel Ziswiler 
> Sent: Monday, August 23, 2021 8:57 AM
> To: u-boot@lists.denx.de; ZHIZHIKIN Andrey  geosystems.com>
> Cc: feste...@gmail.com; peng@nxp.com; uboot-...@nxp.com;
> sba...@denx.de; frieder.schre...@kontron.de; heiko.thi...@gmail.com
> Subject: Re: [PATCH v1 1/7] imx: mkimage_fit_atf: fix legacy image generation
> 
> 
> Hi Andrey
> 
> Long time no see (;-p).

Indeed! :D

> 
> On Sun, 2021-08-22 at 10:07 +, ZHIZHIKIN Andrey wrote:
> > Hello Marcel,
> >
> > > -Original Message-
> > > From: U-Boot  On Behalf Of Marcel
> > > Ziswiler
> > > Sent: Friday, August 20, 2021 10:52 PM
> > > To: u-boot@lists.denx.de
> > > Cc: Heiko Thiery ; Stefano Babic
> > > ; Fabio Estevam ; Frieder
> > > Schrempf ; Marcel Ziswiler
> > > ; NXP i.MX U-Boot Team  > > i...@nxp.com>; Peng Fan 
> > > Subject: [PATCH v1 1/7] imx: mkimage_fit_atf: fix legacy image
> > > generation
> > >
> > >
> > > From: Marcel Ziswiler 
> > >
> > > While most boards meanwhile migrated to using binman a few like the
> > > verdin- imx8mm are still using the legacy image generation.
> > > Unfortunately, the legacy image generation is currently broken which
> > > is especially bad for any kind of bisection attempts.
> > > Anyway, this fixes it even though we will also migrate to using binman 
> > > shortly.
> >
> > This change has been already proposed in [1],
> 
> Well, what I do not get is how one can move forward and leave all kinds of 
> stuff
> just broken. Fact is, that the legacy image creation has been and still is 
> plain
> simply broken!
> 
> > but the discussion went into the direction of monolithic "flash.bin" rather 
> > than a
> migration to use binman.
> 
> Well, those two do actually not rule each other out. Remember, later in this 
> patch
> set I am migrating to using binman which I instruct to generate a monolithic
> "flash.bin" again.
> 
> > I guess if this change is really needed due to the fact that the
> > migration of some boards is really difficult
> > - the original patch can be taken.
> 
> What I found extremely problematic is, as mentioned initially, stuff is 
> currently
> broken which makes e.g.
> bisecting other issues extremely cumbersome. But in theory, as I propose now 
> to
> migrate anyway, we could just not care and leave it broken for anybody else. I
> just feel this is not really too nice of a gesture!

Totally agree, keeping the broken implementation is not a nice thing as people 
unaware of this might base their work on it and wonder why it does not build on 
the first place...

Actually, I wanted to propose to remove this script from the tree and let 
derivatives that rely on it to fail to being forcibly converted to binman. But 
I was humble enough to do it through...

There are still those boards that use FIT generator script:
configs/cgtqmx8_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8mm-icore-mx8mm-ctouch2_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8mm-icore-mx8mm-edimm2.2_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8mm_beacon_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8mm_venice_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8mn_beacon_2g_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8mn_beacon_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8mq_evk_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8mq_phanbell_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8qm_rom7720_a1_4G_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/phycore-imx8mm_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/pico-imx8mq_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/verdin-imx8mm_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"

Verdin gets converted with your other patch, while for all the others I'm not 
sure what the status is.

There is however one board which has been introduced quite recent (Cc'ing 
Oliver here) and didn't went for binman implementation from the start. This is 
a clear indication that people are still relying on old FIT generator, even 
though ther

RE: [PATCH v1 1/7] imx: mkimage_fit_atf: fix legacy image generation

[ZHIZHIKIN Andrey]

Hello Marcel,

> -Original Message-
> From: U-Boot  On Behalf Of Marcel Ziswiler
> Sent: Friday, August 20, 2021 10:52 PM
> To: u-boot@lists.denx.de
> Cc: Heiko Thiery ; Stefano Babic ;
> Fabio Estevam ; Frieder Schrempf
> ; Marcel Ziswiler
> ; NXP i.MX U-Boot Team  i...@nxp.com>; Peng Fan 
> Subject: [PATCH v1 1/7] imx: mkimage_fit_atf: fix legacy image generation
> 
> 
> From: Marcel Ziswiler 
> 
> While most boards meanwhile migrated to using binman a few like the verdin-
> imx8mm are still using the legacy image generation.
> Unfortunately, the legacy image generation is currently broken which is 
> especially
> bad for any kind of bisection attempts.
> Anyway, this fixes it even though we will also migrate to using binman 
> shortly.

This change has been already proposed in [1], but the discussion went into the 
direction of monolithic "flash.bin" rather than a migration to use binman.

I guess if this change is really needed due to the fact that the migration of 
some boards is really difficult - the original patch can be taken.

However, I've commented out in that thread that there is a warning regarding 
the usage of scripts and migration notice, so maybe it does make sense to spend 
extra effort to migrate away from this script at all?

> 
> Fixes: commit cb9faa6f98ae
>  ("tools: Use a single target-independent config to enable OpenSSL")
> Signed-off-by: Marcel Ziswiler 
> ---
> 
>  arch/arm/mach-imx/mkimage_fit_atf.sh | 26 +-
>  1 file changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/mkimage_fit_atf.sh b/arch/arm/mach-
> imx/mkimage_fit_atf.sh
> index 2a17968794c..2d6c46633c7 100755
> --- a/arch/arm/mach-imx/mkimage_fit_atf.sh
> +++ b/arch/arm/mach-imx/mkimage_fit_atf.sh
> @@ -53,7 +53,7 @@ cat << __HEADER_EOF
> description = "Configuration to load ATF before U-Boot";
> 
> images {
> -   uboot@1 {
> +   uboot_1 {
> description = "U-Boot (64-bit)";
> os = "u-boot";
> data = /incbin/("$BL33"); @@ -68,7 +68,7 @@ cnt=1  
> for dtname in $*
> do
> cat << __FDT_IMAGE_EOF
> -   fdt@$cnt {
> +   fdt_$cnt {
> description = "$(basename $dtname .dtb)";
> data = /incbin/("$dtname");
> type = "flat_dt"; @@ -79,7 +79,7 @@ cnt=$((cnt+1))  
> done
> 
>  cat << __HEADER_EOF
> -   atf@1 {
> +   atf_1 {
> description = "ARM Trusted Firmware";
> os = "arm-trusted-firmware";
> data = /incbin/("$BL31"); @@ -93,7 +93,7 @@ 
> __HEADER_EOF
> 
>  if [ -f $BL32 ]; then
>  cat << __HEADER_EOF
> -   tee@1 {
> +   tee_1 {
> description = "TEE firmware";
> data = /incbin/("$BL32");
> type = "firmware"; @@ -108,7 +108,7 @@ fi  cat <<
> __CONF_HEADER_EOF
> };
> configurations {
> -   default = "config@1";
> +   default = "config_1";
> 
>  __CONF_HEADER_EOF
> 
> @@ -117,20 +117,20 @@ for dtname in $*
>  do
>  if [ -f $BL32 ]; then
>  cat << __CONF_SECTION_EOF
> -   config@$cnt {
> +   config_$cnt {
> description = "$(basename $dtname .dtb)";
> -   firmware = "uboot@1";
> -   loadables = "atf@1", "tee@1";
> -   fdt = "fdt@$cnt";
> +   firmware = "uboot_1";
> +   loadables = "atf_1", "tee_1";
> +   fdt = "fdt_$cnt";
> };
>  __CONF_SECTION_EOF
>  else
>  cat << __CONF_SECTION1_EOF
> -   config@$cnt {
> +   config_$cnt {
> description = "$(basename $dtname .dtb)";
> -   firmware = "uboot@1";
> -   loadables = "atf@1";
> -   fdt = "fdt@$cnt";
> +   firmware = "uboot_1";
> +   loadables = "atf_1";
> +   fdt = "fdt_$cnt";
> };
>  __CONF_SECTION1_EOF
>  fi
> --
> 2.26.2

Link: [1]: 
https://lore.kernel.org/u-boot/20210505120053.9466-1-oliver.gra...@kococonnector.com/

Regards,
Andrey

RE: [PATCH 1/3] imx8mm: configs: enable distro default features

[ZHIZHIKIN Andrey]

Hello Stefano,

> -Original Message-
> From: Stefano Babic 
> Sent: Monday, June 21, 2021 1:36 PM
> To: ZHIZHIKIN Andrey ;
> sba...@denx.de
> Cc: U-Boot-Denx ; Peng Fan ;
> Fabio Estevam 
> Subject: Re: [PATCH 1/3] imx8mm: configs: enable distro default features
> 
> On 17.06.21 18:03, ZHIZHIKIN Andrey wrote:
> > Hello Stefano,
> >
> > I believe the following patch is missing from the series that I've submitted
> earlier.
> >
> >  From the entire series named "Correct and extend distro boot support for
> imx8m" [1], there were 3 patches included, namely:
> > [2]  imx8mm: configs: enable distro default features [3]  imx8mp:
> > configs: enable distro default features [4]  imx8mn: configs: add
> > support for distro boot commands
> >
> > I see that only [4] is actually got merged, the rest 2 patches are left in
> "Superseded" state in Patchwork.
> >
> > I'm not sure what happened here, I believe that was due to the fact that the
> patch which targeted "imx8mn" has been updated to V2 which caused the entire
> series to be dropped.
> >
> > Should I re-submit the rest of 2 patches from the original series, or 
> > perhaps you
> can take them from the Patchwork directly?
> >
> 
> I picked up the two missing patches, just take a look at u-boot-imx, -master.

I've checked the [master] branch of u-boot-imx and I can see those two missing 
patches in it.

This now completed the original series, thanks for taking care of this.

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

-- andrey

RE: [PATCH 1/3] imx8mm: configs: enable distro default features

[ZHIZHIKIN Andrey]

Hello Stefano,

I believe the following patch is missing from the series that I've submitted 
earlier.

From the entire series named "Correct and extend distro boot support for imx8m" 
[1], there were 3 patches included, namely:
[2]  imx8mm: configs: enable distro default features
[3]  imx8mp: configs: enable distro default features
[4]  imx8mn: configs: add support for distro boot commands

I see that only [4] is actually got merged, the rest 2 patches are left in 
"Superseded" state in Patchwork.

I'm not sure what happened here, I believe that was due to the fact that the 
patch which targeted "imx8mn" has been updated to V2 which caused the entire 
series to be dropped.

Should I re-submit the rest of 2 patches from the original series, or perhaps 
you can take them from the Patchwork directly?

> -Original Message-
> From: Fabio Estevam 
> Sent: Sunday, May 2, 2021 12:00 AM
> To: ZHIZHIKIN Andrey 
> Cc: U-Boot-Denx ; Peng Fan 
> Subject: Re: [PATCH 1/3] imx8mm: configs: enable distro default features
> 
> Hi Andrey,
> 
> On Sat, May 1, 2021 at 5:24 PM Andrey Zhizhikin  geosystems.com> wrote:
> >
> > imx8mm ekv has been switched to use distro boot commands, but had no
> > correct options enabled to support sysboot.
> > According to the README.distro, sysboot is consindered to be a
> > recommended way of using distro boot commands, it required default
> > distro features to be enabled instead of only those that are relevant
> > to the boot script.
> >
> > Replace the boot script specific options in the config to a default
> > distro option.
> >
> > Signed-off-by: Andrey Zhizhikin
> > 
> > Cc: Peng Fan 
> > Fixes: 2df8930bf9 ("imx8mm: configs: add support for distro boot
> > commands")
> 
> Reviewed-by: Fabio Estevam 

Link: [1]: http://patchwork.ozlabs.org/project/uboot/list/?series=241695
Link: [2]: 
http://patchwork.ozlabs.org/project/uboot/patch/20210501202306.5254-2-andrey.zhizhi...@leica-geosystems.com/
Link: [3]: 
http://patchwork.ozlabs.org/project/uboot/patch/20210501202306.5254-3-andrey.zhizhi...@leica-geosystems.com/
Link: [4]: 
http://patchwork.ozlabs.org/project/uboot/patch/20210501202306.5254-4-andrey.zhizhi...@leica-geosystems.com/

-- Andrey

RE: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board

[ZHIZHIKIN Andrey]

Hello Vanessa,

> -Original Message-
> From: Vanessa Maegima 
> Sent: Tuesday, May 18, 2021 3:15 PM
> To: ZHIZHIKIN Andrey 
> Cc: Ricardo Salveti ; Fabio Estevam
> ; Peng Fan (OSS) ;
> sba...@denx.de; u-boot@lists.denx.de; uboot-...@nxp.com; Ye Li
> ; igor.opan...@foundries.io
> Subject: Re: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board
> 
> 
> Hi Andrey,
> 
> On Sun, May 16, 2021 at 11:31 AM ZHIZHIKIN Andrey  geosystems.com> wrote:
> >
> > Hello Ricardo,
> >
> > > -Original Message-
> > > From: Ricardo Salveti 
> > > Sent: Friday, May 14, 2021 5:29 PM
> > > To: Fabio Estevam 
> > > Cc: ZHIZHIKIN Andrey ; Peng
> > > Fan
> > > (OSS) ; sba...@denx.de; u-boot@lists.denx.de;
> > > uboot- i...@nxp.com; Ye Li ;
> > > vanessa.maeg...@foundries.io; igor.opan...@foundries.io
> > > Subject: Re: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk
> > > board
> > >
> > >
> > > Hi Fabio,
> > >
> > > On Fri, May 14, 2021 at 9:30 AM Fabio Estevam 
> wrote:
> > > >
> > > > Hi Andrey,
> > > >
> > > > On Wed, May 12, 2021 at 6:47 PM ZHIZHIKIN Andrey
> > > >  wrote:
> > > >
> > > > > > Update PMIC to use PCA9540, the legacy board not supported by
> > > > > > NXP
> > > > >
> > > > > This commit seems rather a "nuclear" to me, as de-facto it drops
> > > > > the
> > > initialization of ROMH PMIC in
> > > > > favor of PCA one, leaving all the previous board revisions not
> > > > > to be properly
> > > sourced.
> > > > >
> > > > > I know that there might be no intention to provide a support for
> > > > > earlier
> > > revisions of i.MX8M Mini
> > > > > EVKs from NXP, but providing no backward compatibility to those
> > > > > boards
> > > which are still in use by
> > > > > a lot of people for development purposes is highly undesirable either.
> > > > >
> > > > > TBH, I've tested this patch on the old EVK where ROMH PMIC is
> > > > > present, and
> > > apart from having some
> > > > > error messages in SPL regarding the register writes - it does
> > > > > boots. What
> > > worries me the most though
> > > > > is that DTS changes some voltage settings, which I'm not sure
> > > > > how the SOC
> > > would react on.
> > > > >
> > > > > To my opinion, this patch should either be complemented with the
> > > mechanism to provide a
> > > > > level of backward compatibility (where the PMIC can be
> > > > > dynamically
> > > identified and instantiated),
> > > > > or the separate implementation should be presented which would
> > > > > make the
> > > old board type not to
> > > > > be bootable at all if it is considered not to be supported any
> > > > > longer. Or this
> > > patch should be reverted
> > > > > in an effort to come up with a solution which covers new
> > > > > revision without
> > > "damaging" the currently
> > > > > integrated one.
> > > > >
> > > > > Fabio / Stefano,
> > > > > Do you have any thoughts here on how this should be handled
> > > > > further,
> > > considering the fact that the
> > > > > backward compatibility of 2021.07 release is not kept for this
> > > > > board type
> > > across multiple revisions?
> > > > >
> > > > > I'd really like to get your opinion here as I do have those
> > > > > boards in
> > > development and would need to
> > > > > come up with the idea on what to do with them.
> > > > >
> > > > > Also, this should be taken care of in the Yocto, since there is
> > > > > only one
> > > definition of the i.MX8MM EVK
> > > > > machine which does not make any distinction regarding the revision.
> > > >
> > > > You bring a good point.
> > > >
> > > > What about adding a new defconfig to support the old imx8mm-evk
> > > > with the Rohm PMIC?
> > > >
> > > > Then we could have imx8mm_evk_defconfig for the new version and
> > > > imx8mm_evk_rohm_defconfig for the old one.
&

RE: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board

[ZHIZHIKIN Andrey]

Hello Ricardo,

> -Original Message-
> From: Ricardo Salveti 
> Sent: Friday, May 14, 2021 5:29 PM
> To: Fabio Estevam 
> Cc: ZHIZHIKIN Andrey ; Peng Fan
> (OSS) ; sba...@denx.de; u-boot@lists.denx.de; uboot-
> i...@nxp.com; Ye Li ; vanessa.maeg...@foundries.io;
> igor.opan...@foundries.io
> Subject: Re: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board
> 
> 
> Hi Fabio,
> 
> On Fri, May 14, 2021 at 9:30 AM Fabio Estevam  wrote:
> >
> > Hi Andrey,
> >
> > On Wed, May 12, 2021 at 6:47 PM ZHIZHIKIN Andrey
> >  wrote:
> >
> > > > Update PMIC to use PCA9540, the legacy board not supported by NXP
> > >
> > > This commit seems rather a "nuclear" to me, as de-facto it drops the
> initialization of ROMH PMIC in
> > > favor of PCA one, leaving all the previous board revisions not to be 
> > > properly
> sourced.
> > >
> > > I know that there might be no intention to provide a support for earlier
> revisions of i.MX8M Mini
> > > EVKs from NXP, but providing no backward compatibility to those boards
> which are still in use by
> > > a lot of people for development purposes is highly undesirable either.
> > >
> > > TBH, I've tested this patch on the old EVK where ROMH PMIC is present, and
> apart from having some
> > > error messages in SPL regarding the register writes - it does boots. What
> worries me the most though
> > > is that DTS changes some voltage settings, which I'm not sure how the SOC
> would react on.
> > >
> > > To my opinion, this patch should either be complemented with the
> mechanism to provide a
> > > level of backward compatibility (where the PMIC can be dynamically
> identified and instantiated),
> > > or the separate implementation should be presented which would make the
> old board type not to
> > > be bootable at all if it is considered not to be supported any longer. Or 
> > > this
> patch should be reverted
> > > in an effort to come up with a solution which covers new revision without
> "damaging" the currently
> > > integrated one.
> > >
> > > Fabio / Stefano,
> > > Do you have any thoughts here on how this should be handled further,
> considering the fact that the
> > > backward compatibility of 2021.07 release is not kept for this board type
> across multiple revisions?
> > >
> > > I'd really like to get your opinion here as I do have those boards in
> development and would need to
> > > come up with the idea on what to do with them.
> > >
> > > Also, this should be taken care of in the Yocto, since there is only one
> definition of the i.MX8MM EVK
> > > machine which does not make any distinction regarding the revision.
> >
> > You bring a good point.
> >
> > What about adding a new defconfig to support the old imx8mm-evk with
> > the Rohm PMIC?
> >
> > Then we could have imx8mm_evk_defconfig for the new version and
> > imx8mm_evk_rohm_defconfig for the old one.
> >
> > What do you think?
> 
> Maybe a dynamic way to identify if BD71837 or PCA9450 (by probing i2c)
> would work better?

This might be solution given that there is an implementation in SPL which
can be used to query I2C to determine the PMIC type and get it dynamically.

I'm not aware if this functionality exist, I would need to search for the 
reference
in the U-Boot tree for this.

But still, as I previously replied to Fabio, it would still need to have 2 
separate
entries in DTS for both PMICs, and SPL power_init_board(void) code should be
extended to request the PMIC based on the type detected.

I guess this can be done in 2 steps: first make the PMIC selection based on the
config option in SPL, and then - replace it with dynamic query (if possible).

> 
> Different configs would imply different builds and binaries, which is
> a problem when trying to support a single build for both the old EVK
> and EVKB (and the main difference is the PMIC, nothing really major).

This is especially true for Yocto builds, but there would be a way to define
separate U-Boot config based on the type, so having 2 separate config files
would not be technically impossible to achieve.

However, I totally agree with you - one build for both revisions would be the
best solution here.

> 
> I also share Andrey's concerns, as we do have several EVKs in hands,
> and having one single build would facilitate quite a bit.
> 
> Cheers,
> --
> Ricardo Salveti de Araujo

-- andrey

RE: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board

[ZHIZHIKIN Andrey]

Hello Fabio,

> -Original Message-
> From: Fabio Estevam 
> Sent: Friday, May 14, 2021 2:31 PM
> To: ZHIZHIKIN Andrey 
> Cc: Peng Fan (OSS) ; sba...@denx.de; u-
> b...@lists.denx.de; uboot-...@nxp.com; Ye Li 
> Subject: Re: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board
> 
> 
> Hi Andrey,
> 
> On Wed, May 12, 2021 at 6:47 PM ZHIZHIKIN Andrey  geosystems.com> wrote:
> 
> > > Update PMIC to use PCA9540, the legacy board not supported by NXP
> >
> > This commit seems rather a "nuclear" to me, as de-facto it drops the
> > initialization of ROMH PMIC in favor of PCA one, leaving all the previous 
> > board
> revisions not to be properly sourced.
> >
> > I know that there might be no intention to provide a support for
> > earlier revisions of i.MX8M Mini EVKs from NXP, but providing no
> > backward compatibility to those boards which are still in use by a lot of 
> > people
> for development purposes is highly undesirable either.
> >
> > TBH, I've tested this patch on the old EVK where ROMH PMIC is present,
> > and apart from having some error messages in SPL regarding the
> > register writes - it does boots. What worries me the most though is that DTS
> changes some voltage settings, which I'm not sure how the SOC would react on.
> >
> > To my opinion, this patch should either be complemented with the
> > mechanism to provide a level of backward compatibility (where the PMIC
> > can be dynamically identified and instantiated), or the separate
> > implementation should be presented which would make the old board type
> > not to be bootable at all if it is considered not to be supported any
> > longer. Or this patch should be reverted in an effort to come up with a 
> > solution
> which covers new revision without "damaging" the currently integrated one.
> >
> > Fabio / Stefano,
> > Do you have any thoughts here on how this should be handled further,
> > considering the fact that the backward compatibility of 2021.07 release is 
> > not
> kept for this board type across multiple revisions?
> >
> > I'd really like to get your opinion here as I do have those boards in
> > development and would need to come up with the idea on what to do with
> them.
> >
> > Also, this should be taken care of in the Yocto, since there is only
> > one definition of the i.MX8MM EVK machine which does not make any
> distinction regarding the revision.
> 
> You bring a good point.
> 
> What about adding a new defconfig to support the old imx8mm-evk with the
> Rohm PMIC?

This would not be the only change that is necessary to provide support for both
ROMH and PCA PMIC ICs. From the commit, it seems that also the "duplication"
should be done in DTS and SPL PMIC code in power_init_board(void) should also
be adapted to get PMIC based on the config option.

I'm not saying it is not feasible - it is perfectly doable, but would require 
some
verification afterwards.

I can try to come up with the patch set for this but cannot commit to test the
change since I do not own a updated EVK board.

I guess an ideal situation would be that NXP can step in here to provide the 
better
version of this patch where both revisions are supported, and they can verify 
the
change on both EVK revisions.

> 
> Then we could have imx8mm_evk_defconfig for the new version and
> imx8mm_evk_rohm_defconfig for the old one.

Yes, ultimately this would be possible provided that both DTS and SPL code are
made in a way to provide implementation for both PMIC types.

> 
> What do you think?
> 
> Thanks

-- andrey

RE: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board

[ZHIZHIKIN Andrey]

Hello Peng,

> -Original Message-
> From: U-Boot  On Behalf Of Peng Fan (OSS)
> Sent: Friday, March 19, 2021 8:57 AM
> To: sba...@denx.de; feste...@gmail.com
> Cc: u-boot@lists.denx.de; uboot-...@nxp.com; Ye Li 
> Subject: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board
> 
> From: Ye Li 
> 
> Update PMIC to use PCA9540, the legacy board not supported by NXP

This commit seems rather a "nuclear" to me, as de-facto it drops the 
initialization of ROMH PMIC in
favor of PCA one, leaving all the previous board revisions not to be properly 
sourced.

I know that there might be no intention to provide a support for earlier 
revisions of i.MX8M Mini
EVKs from NXP, but providing no backward compatibility to those boards which 
are still in use by
a lot of people for development purposes is highly undesirable either.

TBH, I've tested this patch on the old EVK where ROMH PMIC is present, and 
apart from having some
error messages in SPL regarding the register writes - it does boots. What 
worries me the most though
is that DTS changes some voltage settings, which I'm not sure how the SOC would 
react on.

To my opinion, this patch should either be complemented with the mechanism to 
provide a
level of backward compatibility (where the PMIC can be dynamically identified 
and instantiated),
or the separate implementation should be presented which would make the old 
board type not to
be bootable at all if it is considered not to be supported any longer. Or this 
patch should be reverted
in an effort to come up with a solution which covers new revision without 
"damaging" the currently
integrated one.

Fabio / Stefano,
Do you have any thoughts here on how this should be handled further, 
considering the fact that the
backward compatibility of 2021.07 release is not kept for this board type 
across multiple revisions?

I'd really like to get your opinion here as I do have those boards in 
development and would need to
come up with the idea on what to do with them.

Also, this should be taken care of in the Yocto, since there is only one 
definition of the i.MX8MM EVK
machine which does not make any distinction regarding the revision.

Thanks a lot!

> 
> Signed-off-by: Ye Li 
> ---
>  arch/arm/dts/imx8mm-evk-u-boot.dtsi |   4 +-
>  arch/arm/dts/imx8mm-evk.dtsi| 127 +++-
>  board/freescale/imx8mm_evk/spl.c|  33 
>  configs/imx8mm_evk_defconfig|   2 +-
>  4 files changed, 86 insertions(+), 80 deletions(-)
> 
> diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi b/arch/arm/dts/imx8mm-evk-
> u-boot.dtsi
> index e843a5648e..7f48912b49 100644
> --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> @@ -114,11 +114,11 @@
> u-boot,dm-spl;
>  };
> 
> -&{/soc@0/bus@3080/i2c@30a2/pmic@4b} {
> +&{/soc@0/bus@3080/i2c@30a2/pca9450@25} {
> u-boot,dm-spl;
>  };
> 
> -&{/soc@0/bus@3080/i2c@30a2/pmic@4b/regulators} {
> +&{/soc@0/bus@3080/i2c@30a2/pca9450@25/regulators} {
> u-boot,dm-spl;
>  };
> 
> diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi
> index 6518f088b2..60179e006d 100644
> --- a/arch/arm/dts/imx8mm-evk.dtsi
> +++ b/arch/arm/dts/imx8mm-evk.dtsi
> @@ -126,115 +126,120 @@
> pinctrl-0 = <_i2c1>;
> status = "okay";
> 
> -   pmic@4b {
> -   compatible = "rohm,bd71847";
> -   reg = <0x4b>;
> -   pinctrl-names = "default";
> +   pmic: pca9450@25 {
> +   reg = <0x25>;
> +   compatible = "nxp,pca9450a";
> +   /* PMIC PCA9450 PMIC_nINT GPIO1_IO3 */
> pinctrl-0 = <_pmic>;
> -   interrupt-parent = <>;
> -   interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> -   rohm,reset-snvs-powered;
> -
> -   #clock-cells = <0>;
> -   clocks = <_32k 0>;
> -   clock-output-names = "clk-32k-out";
> +   gpio_intr = < 3 GPIO_ACTIVE_LOW>;
> 
> regulators {
> -   buck1_reg: BUCK1 {
> -   regulator-name = "buck1";
> -   regulator-min-microvolt = <70>;
> -   regulator-max-microvolt = <130>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   pca9450,pmic-buck2-uses-i2c-dvs;
> +   /* Run/Standby voltage */
> +   pca9450,pmic-buck2-dvs-voltage = <95>,
> + <85>;
> +
> +   buck1_reg: regulator@0 {
> +   reg = <0>;
> +   regulator-compatible = "buck1";
> +   regulator-min-microvolt = <60>;
> +   regulator-max-microvolt = <2187500>;
> regulator-boot-on;
> 

RE: [PATCH v1] imx: mkimage_fit_atf: replace @ with hyphen

[ZHIZHIKIN Andrey]

Hello Oliver,

> -Original Message-
> From: U-Boot  On Behalf Of Oliver Graute
> Sent: Wednesday, May 5, 2021 2:01 PM
> To: sba...@denx.de
> Cc: feste...@gmail.com; peng@nxp.com;
> oliver.gra...@kococonnector.com; u-boot@lists.denx.de; Simon Glass
> ; uboot-imx 
> Subject: [PATCH v1] imx: mkimage_fit_atf: replace @ with hyphen
> 
> 
> Unit addresses are not allowed anymore in a FIT image since
> 
> commit 3f04db891a35 ("image: Check for unit addresses in FITs")
> 
> This caused this error on mkimage creation:
> 
> ./tools/mkimage: verify_header failed for FIT Image support with exit code 1
> Makefile:1393: recipe for target 'u-boot.itb' failed
> make: *** [u-boot.itb] Error 1

IIRC, this error comes from the derivatives which are not (yet) migrated to use 
'binman' and have CONFIG_SPL_FIT_GENERATOR set.

It is triggered by 79af75f777 ("fit: Don't allow verification of images with @ 
nodes"), which is totally correct behavior and should be
corrected on the FIT generator end, so the patch itself solves the problem.

TBH, I had introduced the same change to NXP U-Boot fork that is built for NXP 
Yocto BSP [1], and was not sure it is relevant for the
master since it uses 'binman' instead of FIT generator.

From the other point of view, which imx8m board do you experience this build 
problem with?

Currently, there are following boards that need to be migrated from FIT 
generator to 'binman':
configs/imx8mm_beacon_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8mm_venice_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8mn_beacon_2g_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8mn_beacon_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8mq_evk_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8mq_phanbell_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/imx8qm_rom7720_a1_4G_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/phycore-imx8mm_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/phycore-imx8mp_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/pico-imx8mq_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
configs/verdin-imx8mm_defconfig:CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"

I know it's a long shot, but the question is: should the FIT generator be 
adapted here, or maybe those boards that are
still using it - to be migrated to binman directly?

There is already a warning in root Makefile regarding usage of FIT generator:
"= WARNING =="
"This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate"
"to binman instead, to avoid the proliferation of"
"arch-specific scripts with no tests."
""

So maybe it makes sense to adapt affected boards instead?

> 
> replacing @ with hyphen solved the issue
> 
> Signed-off-by: Oliver Graute 
> Cc: Stefano Babic 
> Cc: Fabio Estevam 
> Cc: Peng Fan 
> Cc: Simon Glass 
> Cc: uboot-imx 
> ---
>  arch/arm/mach-imx/mkimage_fit_atf.sh | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/mkimage_fit_atf.sh b/arch/arm/mach-
> imx/mkimage_fit_atf.sh
> index fe12b7bb4b..c5fb9b0fc3 100755
> --- a/arch/arm/mach-imx/mkimage_fit_atf.sh
> +++ b/arch/arm/mach-imx/mkimage_fit_atf.sh
> @@ -53,7 +53,7 @@ cat << __HEADER_EOF
> description = "Configuration to load ATF before U-Boot";
> 
> images {
> -   uboot@1 {
> +   uboot-1 {
> description = "U-Boot (64-bit)";
> os = "u-boot";
> data = /incbin/("$BL33"); @@ -68,7 +68,7 @@ cnt=1  
> for dtname in $*
> do
> cat << __FDT_IMAGE_EOF
> -   fdt@$cnt {
> +   fdt-$cnt {
> description = "$(basename $dtname .dtb)";
> data = /incbin/("$dtname");
> type = "flat_dt"; @@ -79,7 +79,7 @@ cnt=$((cnt+1))  
> done
> 
>  cat << __HEADER_EOF
> -   atf@1 {
> +   atf-1 {
> description = "ARM Trusted Firmware";
> os = "arm-trusted-firmware";
> data = /incbin/("$BL31"); @@ -93,7 +93,7 @@ 
> __HEADER_EOF
> 
>  if [ -f $BL32 ]; then
>  cat << __HEADER_EOF
> -   tee@1 {
> +   tee-1 {
> description = "TEE firmware";
> data = /incbin/("$BL32");
> type = "firmware"; @@ -108,7 +108,7 @@ fi  cat <<
> __CONF_HEADER_EOF
> };
> configurations {
> -   default = "config@1";
> +   default = "config-1";
> 
>  

RE: [PATCH] arm: imx: imx8mm: correct unrecognized fracpll frequency

[ZHIZHIKIN Andrey]

Hello Fabio,

> -Original Message-
> From: Fabio Estevam 
> Sent: Sunday, May 2, 2021 11:45 PM
> To: ZHIZHIKIN Andrey 
> Cc: U-Boot-Denx ; Stefano Babic ;
> NXP i.MX U-Boot Team ; Peng Fan
> ; Simon Glass ; Ye Li 
> Subject: Re: [PATCH] arm: imx: imx8mm: correct unrecognized fracpll frequency
> 
> 
> Hi Andrey,
> 
> After re-reading the patch I have some comments:
> 
> On Sat, May 1, 2021 at 5:13 PM Andrey Zhizhikin  geosystems.com> wrote:
> >
> > Frequency requested by ddrphy_init_set_dfi_clk from fracpll uses MHZ()
> > macro, which expands the value provided to the Hz range without taking
> > into account the precise Hz setting. This causes the frequency of 266
> > MHz not ot be found in the imx8mm_fracpll_tbl, since it is entered
> > there with a precise Hz value. This in turn causes the boot hang in
> > SPL, as proper DDR fracpll frequency cannot be determined.
> >
> > Correct the value in imx8mm_fracpll_tbl to match the one expanded by
> > MHZ(266) macro, rounding it down to MHz range only.
> >
> > Signed-off-by: Andrey Zhizhikin
> > 
> > Cc: Stefano Babic 
> > Cc: Fabio Estevam 
> > Cc: "NXP i.MX U-Boot Team" 
> > Cc: Peng Fan 
> > Cc: Simon Glass 
> > Cc: Ye Li 
> > Fixes: 825ab6b406 ("driver: ddr: Refine the ddr init driver on imx8m")
> > ---
> >  arch/arm/mach-imx/imx8m/clock_imx8mm.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mm.c
> > b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
> > index 029d06f27f..86ff2b9cc9 100644
> > --- a/arch/arm/mach-imx/imx8m/clock_imx8mm.c
> > +++ b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
> > @@ -54,7 +54,7 @@ static struct imx_int_pll_rate_table imx8mm_fracpll_tbl[]
> = {
> > PLL_1443X_RATE(6U, 300, 3, 2, 0),
> > PLL_1443X_RATE(59400U, 99, 1, 2, 0),
> > PLL_1443X_RATE(4U, 300, 9, 1, 0),
> > -   PLL_1443X_RATE(26667U, 400, 9, 2, 0),
> > +   PLL_1443X_RATE(26600U, 400, 9, 2, 0),
> 
> This change looks good.
> 
> > PLL_1443X_RATE(16700U, 334, 3, 4, 0),
> > PLL_1443X_RATE(1U, 300, 9, 3, 0),  }; @@ -72,7 +72,7
> > @@ static int fracpll_configure(enum pll_clocks pll, u32 freq)
> > }
> >
> > if (i == ARRAY_SIZE(imx8mm_fracpll_tbl)) {
> > -   printf("No matched freq table %u\n", freq);
> > +   printf("%s: No matched freq table %u\n", __func__,
> > + freq);
> > return -EINVAL;
> > }
> >
> > @@ -148,7 +148,7 @@ void dram_enable_bypass(ulong clk_val)
> > }
> >
> > if (i == ARRAY_SIZE(imx8mm_dram_bypass_tbl)) {
> > -   printf("No matched freq table %lu\n", clk_val);
> > +   printf("%s: No matched freq table %lu\n", __func__,
> > + clk_val);
> 
> , but these two I would put them on a separate patch.

Fair enough, thanks for pointing this out!

Even though this helped me originally to pinpoint the issue, looking at this 
change now I see it does indeed belong to the separate patch as it does not 
relate to the PLL fix per se.

I would split this into a separate patch, send it separate, and send a V2 for 
the PLL fix.

> 
> Thanks

Cheers,
Andrey

RE: [PATCH 7/7] doc: imx8mp-evk: update after using binman

[ZHIZHIKIN Andrey]

> -Original Message-
> From: U-Boot  On Behalf Of Peter Bergin
> Sent: Tuesday, April 6, 2021 8:59 AM
> To: u-boot@lists.denx.de
> Subject: Re: [PATCH 7/7] doc: imx8mp-evk: update after using binman
>  
> 
> Hi,
> 
> On 2021-04-06 05:59, Peng Fan (OSS) wrote:
> >   Burn the flash.bin to the MicroSD card at offset 32KB:
> >
> >   .. code-block:: bash
> >
> >  $sudo dd if=build/flash.bin of=/dev/sd[x] bs=1K seek=32
> > conv=notrunc; sync
> > +   $sudo dd if=build/u-boot.itb of=/dev/sd[x] bs=1K seek=384
> > + conv=notrunc; sync
> 
> Why is this changed to 'seek=384'? Comment still states 'offset 32KB'
> and reference manual states that Primary Image Offset for SD card shall be 
> 32KB.
> Can you explain a bit more around this?

I'd also be interested in a more detailed explanation of this change, since the 
documentation is not quite descriptive about this added step.

How the magic new offset is handled and why is it chosen to be 384?

I see this change was made *exactly in the same way* across Mini, Nano and Plus 
SOCs of i.MX8M family, hence I believe it does deserve a good description.

> 
> Thanks,
> /Peter

Thanks a lot!

-- andrey

RE: [PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11 related code.

[ZHIZHIKIN Andrey]

Hello Haibo,

> -Original Message-
> From: Bough Chen 
> Sent: Wednesday, March 3, 2021 12:27 PM
> To: ZHIZHIKIN Andrey ; Peng Fan
> ; u-boot@lists.denx.de; sba...@denx.de
> Cc: dl-uboot-imx ; thar...@gateworks.com;
> feste...@gmail.com; Ye Li 
> Subject: RE: [PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11 related
> code.
> 
> > -Original Message-
> > From: ZHIZHIKIN Andrey [mailto:andrey.zhizhi...@leica-geosystems.com]
> > Sent: 2021年3月3日 19:00
> > To: Bough Chen ; Peng Fan ;
> > u-boot@lists.denx.de; sba...@denx.de
> > Cc: dl-uboot-imx ; thar...@gateworks.com;
> > feste...@gmail.com; Ye Li 
> > Subject: RE: [PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11
> > related code.
> >
> >
> >
> > > -Original Message-
> > > From: haibo.c...@nxp.com 
> > > Sent: Wednesday, March 3, 2021 10:06 AM
> > > To: peng....@nxp.com; u-boot@lists.denx.de; sba...@denx.de
> > > Cc: haibo.c...@nxp.com; uboot-...@nxp.com; thar...@gateworks.com;
> > > ZHIZHIKIN Andrey ;
> > > feste...@gmail.com; ye...@nxp.com
> > > Subject: [PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11
> > > related code.
> > >
> > > From: Haibo Chen 
> > >
> > > Common code already handle the voltage switch sequence based on spec,
> > > so remove the redundant voltage switch code.
> > >
> > > Signed-off-by: Haibo Chen 
> > > ---
> > >  drivers/mmc/fsl_esdhc_imx.c | 10 +-
> > >  1 file changed, 1 insertion(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
> > > index
> > > af36558b3c..a199cf3df6 100644
> > > --- a/drivers/mmc/fsl_esdhc_imx.c
> > > +++ b/drivers/mmc/fsl_esdhc_imx.c
> > > @@ -515,15 +515,6 @@ static int esdhc_send_cmd_common(struct
> > > fsl_esdhc_priv *priv, struct mmc *mmc,
> > > goto out;
> > > }
> > >
> > > -   /* Switch voltage to 1.8V if CMD11 succeeded */
> > > -   if (cmd->cmdidx == SD_CMD_SWITCH_UHS18V) {
> > > -   esdhc_setbits32(>vendorspec,
> > ESDHC_VENDORSPEC_VSELECT);
> > > -
> > > -   printf("Run CMD11 1.8V switch\n");
> > > -   /* Sleep for 5 ms - max time for card to switch to 1.8V */
> > > -   udelay(5000);
> > > -   }
> > > -
> > > /* Workaround for ESDHC errata ENGcm03648 */
> > > if (!data && (cmd->resp_type & MMC_RSP_BUSY)) {
> > > int timeout = 5;
> > > @@ -839,6 +830,7 @@ static int esdhc_set_voltage(struct mmc *mmc)
> > > }
> > >  #endif
> > > esdhc_setbits32(>vendorspec,
> > > ESDHC_VENDORSPEC_VSELECT);
> > > +   mdelay(5);
> >
> > Why is this delay introduced here? It is not clear from the commit message
> > whether and why it is required here.
> >
> > If this is kept from the removed block - maybe it is better to move the
> > corresponding comment here as well.
> 
> Hi Andrev,
> 
> Thanks for your careful review!

Thanks for the patch series on the first place! This allows to switch uSDHC 
into high-speed modes, which is quite valuable.

> Without this 5ms delay, with patch1 and remove the upper redundant cmd11
> related code,
> mmc_switch_voltage() will fail, due to the second mmc_wait_dat0() return
> timeout. Seems for usdhc,
> gate off clock for 10ms is not enough. If total delay 15ms, then the second
> mmc_wait_dat0() can return normal.
> So I add 5ms delay here. Yes, I should add a comment for this 5ms in the code.

Exactly this information is missing with the patch, as later on it would be 
quite difficult to grasp on why this mdelay() was added on the first place.

> You can also do the test on your side.

I've already did and reported with the boot log, mmc info, and my Tested-by: 
tag.

> 
> Best Regards
> Haibo
> 
> >
> > > if (esdhc_read32(>vendorspec) &
> > ESDHC_VENDORSPEC_VSELECT)
> > > return 0;
> > >
> > > --
> > > 2.17.1
> >
> > -- andrey

-- andrey

RE: [PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11 related code.

[ZHIZHIKIN Andrey]

> -Original Message-
> From: haibo.c...@nxp.com 
> Sent: Wednesday, March 3, 2021 10:06 AM
> To: peng@nxp.com; u-boot@lists.denx.de; sba...@denx.de
> Cc: haibo.c...@nxp.com; uboot-...@nxp.com; thar...@gateworks.com;
> ZHIZHIKIN Andrey ;
> feste...@gmail.com; ye...@nxp.com
> Subject: [PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11 related
> code.
> 
> From: Haibo Chen 
> 
> Common code already handle the voltage switch sequence based on spec, so
> remove the redundant voltage switch code.
> 
> Signed-off-by: Haibo Chen 
> ---
>  drivers/mmc/fsl_esdhc_imx.c | 10 +-
>  1 file changed, 1 insertion(+), 9 deletions(-)
> 
> diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c index
> af36558b3c..a199cf3df6 100644
> --- a/drivers/mmc/fsl_esdhc_imx.c
> +++ b/drivers/mmc/fsl_esdhc_imx.c
> @@ -515,15 +515,6 @@ static int esdhc_send_cmd_common(struct
> fsl_esdhc_priv *priv, struct mmc *mmc,
> goto out;
> }
> 
> -   /* Switch voltage to 1.8V if CMD11 succeeded */
> -   if (cmd->cmdidx == SD_CMD_SWITCH_UHS18V) {
> -   esdhc_setbits32(>vendorspec, ESDHC_VENDORSPEC_VSELECT);
> -
> -   printf("Run CMD11 1.8V switch\n");
> -   /* Sleep for 5 ms - max time for card to switch to 1.8V */
> -   udelay(5000);
> -   }
> -
> /* Workaround for ESDHC errata ENGcm03648 */
> if (!data && (cmd->resp_type & MMC_RSP_BUSY)) {
> int timeout = 5;
> @@ -839,6 +830,7 @@ static int esdhc_set_voltage(struct mmc *mmc)
> }
>  #endif
> esdhc_setbits32(>vendorspec, ESDHC_VENDORSPEC_VSELECT);
> +   mdelay(5);

Why is this delay introduced here? It is not clear from the commit message 
whether and why it is required here.

If this is kept from the removed block - maybe it is better to move the 
corresponding comment here as well.

> if (esdhc_read32(>vendorspec) & 
> ESDHC_VENDORSPEC_VSELECT)
> return 0;
> 
> --
> 2.17.1

-- andrey

RE: [PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11 related code.

[ZHIZHIKIN Andrey]

Hello Haibo,

> -Original Message-
> From: haibo.c...@nxp.com 
> Sent: Wednesday, March 3, 2021 10:06 AM
> To: peng@nxp.com; u-boot@lists.denx.de; sba...@denx.de
> Cc: haibo.c...@nxp.com; uboot-...@nxp.com; thar...@gateworks.com;
> ZHIZHIKIN Andrey ;
> feste...@gmail.com; ye...@nxp.com
> Subject: [PATCH 2/2] mmc: fsl_esdhc_imx: remove redundant cmd11 related
> code.
> 
> From: Haibo Chen 
> 
> Common code already handle the voltage switch sequence based on spec, so
> remove the redundant voltage switch code.
> 
> Signed-off-by: Haibo Chen 
> ---
>  drivers/mmc/fsl_esdhc_imx.c | 10 +-
>  1 file changed, 1 insertion(+), 9 deletions(-)
> 
> diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c index
> af36558b3c..a199cf3df6 100644
> --- a/drivers/mmc/fsl_esdhc_imx.c
> +++ b/drivers/mmc/fsl_esdhc_imx.c
> @@ -515,15 +515,6 @@ static int esdhc_send_cmd_common(struct
> fsl_esdhc_priv *priv, struct mmc *mmc,
> goto out;
> }
> 
> -   /* Switch voltage to 1.8V if CMD11 succeeded */
> -   if (cmd->cmdidx == SD_CMD_SWITCH_UHS18V) {
> -   esdhc_setbits32(>vendorspec, ESDHC_VENDORSPEC_VSELECT);
> -
> -   printf("Run CMD11 1.8V switch\n");
> -   /* Sleep for 5 ms - max time for card to switch to 1.8V */
> -   udelay(5000);
> -   }
> -
> /* Workaround for ESDHC errata ENGcm03648 */
> if (!data && (cmd->resp_type & MMC_RSP_BUSY)) {
> int timeout = 5;
> @@ -839,6 +830,7 @@ static int esdhc_set_voltage(struct mmc *mmc)
> }
>  #endif
> esdhc_setbits32(>vendorspec, ESDHC_VENDORSPEC_VSELECT);
> +   mdelay(5);
> if (esdhc_read32(>vendorspec) & 
> ESDHC_VENDORSPEC_VSELECT)
> return 0;
> 
> --
> 2.17.1

Just tested the whole series on i.MX8M Mini EVK, boot log with MMC info:
---
U-Boot SPL 2021.04-rc3-9-g1333570cee (Mar 03 2021 - 11:34:24 +0100)
Normal Boot
WDT:   Started with servicing (60s timeout)
Trying to boot from MMC1
NOTICE:  BL31: v2.2(release):rel_imx_5.4.70_2.3.0-0-gf1d7187f2
NOTICE:  BL31: Built : 22:29:05, Jan 17 2021


U-Boot 2021.04-rc3-9-g1333570cee (Mar 03 2021 - 11:34:24 +0100)

CPU:   Freescale i.MX8MMQ rev1.0 at 1200 MHz
Reset cause: POR
Model: FSL i.MX8MM EVK board
DRAM:  2 GiB
WDT:   Started with servicing (60s timeout)
MMC:   FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@30be
Hit any key to stop autoboot:  0
u-boot=> mmc dev 1
switch to partitions #0, OK
mmc1 is current device
u-boot=> mmc info
Device: FSL_SDHC
Manufacturer ID: 41
OEM: 3432
Name: SD32G
Bus Speed: 2
Mode: UHS SDR104 (208MHz)
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 29.3 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
u-boot=> mmc dev 2
switch to partitions #0, OK
mmc2(part 0) is current device
u-boot=> mmc info
Device: FSL_SDHC
Manufacturer ID: 45
OEM: 100
Name: DG401
Bus Speed: 2
Mode: HS400ES (200MHz)
Rd Block Len: 512
MMC version 5.1
High Capacity: Yes
Capacity: 14.7 GiB
Bus Width: 8-bit DDR
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 14.7 GiB WRREL
Boot Capacity: 4 MiB ENH
RPMB Capacity: 4 MiB ENH
Boot area 0 is not write protected
Boot area 1 is not write protected
u-boot=>


For the series:
Tested-by: Andrey Zhizhikin  # imx8mm_evk

-- andrey

RE: [PATCH 1/2] mmc: fsl_esdhc_imx: use VENDORSPEC_FRC_SDCLK_ON to control card clock output

[ZHIZHIKIN Andrey]

Hello Haibo,

> -Original Message-
> From: haibo.c...@nxp.com 
> Sent: Wednesday, March 3, 2021 10:06 AM
> To: peng@nxp.com; u-boot@lists.denx.de; sba...@denx.de
> Cc: haibo.c...@nxp.com; uboot-...@nxp.com; thar...@gateworks.com;
> ZHIZHIKIN Andrey ;
> feste...@gmail.com; ye...@nxp.com
> Subject: [PATCH 1/2] mmc: fsl_esdhc_imx: use VENDORSPEC_FRC_SDCLK_ON to
> control card clock output
> 
> From: Haibo Chen 
> 
> For FSL_USDHC, it do not implement VENDORSPEC_CKEN/PEREN/HCKEN/IPGEN,
> these are reserved bits. Instead, use VENDORSPEC_FRC_SDCLK_ON to gate
> on/off the card clock output.
> 
> After commit b5874b552ffa ("mmc: fsl_esdhc_imx: add wait_dat0() support"),
> we meet SD3.0 card can't work at UHS mode, mmc_switch_voltage() fail because
> the second mmc_wait_dat0 return -ETIMEDOUT. According to SD spec, during
> voltage switch, need to gate off/on the card clock. If not set the 
> FRC_SDCLK_ON,
> after CMD11, hardware will gate off the card clock automatically, so card do 
> not
> detect the clock off/on behavior, so will draw the data0 line low until next
> command.

I believe this patch is a RESEND of the previous one, right? I do recall I was 
trying to test the same patch, but was missing the second one from this series.

Maybe it make sense to deprecate the old submission then, so it's not dangling 
in Patchwork.

> 
> Fixes: b5874b552ffa ("mmc: fsl_esdhc_imx: add wait_dat0() support")
> Tested-by: Tim Harvey 
> Signed-off-by: Haibo Chen 
> ---
>  drivers/mmc/fsl_esdhc_imx.c | 29 +
>  include/fsl_esdhc_imx.h |  2 ++
>  2 files changed, 23 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c index
> e0e132698e..af36558b3c 100644
> --- a/drivers/mmc/fsl_esdhc_imx.c
> +++ b/drivers/mmc/fsl_esdhc_imx.c
> @@ -654,7 +654,10 @@ static void set_sysctl(struct fsl_esdhc_priv *priv, 
> struct
> mmc *mmc, uint clock)
> clk = (pre_div << 8) | (div << 4);
> 
>  #ifdef CONFIG_FSL_USDHC
> -   esdhc_clrbits32(>vendorspec, VENDORSPEC_CKEN);
> +   esdhc_clrbits32(>vendorspec, VENDORSPEC_FRC_SDCLK_ON);
> +   ret = readx_poll_timeout(esdhc_read32, >prsstat, tmp, tmp &
> PRSSTAT_SDOFF, 100);
> +   if (ret)
> +   pr_warn("fsl_esdhc_imx: Internal clock never gate
> + off.\n");
>  #else
> esdhc_clrbits32(>sysctl, SYSCTL_CKEN);  #endif @@ -666,7 +669,7 
> @@
> static void set_sysctl(struct fsl_esdhc_priv *priv, struct mmc *mmc, uint 
> clock)
> pr_warn("fsl_esdhc_imx: Internal clock never stabilised.\n");
> 
>  #ifdef CONFIG_FSL_USDHC
> -   esdhc_setbits32(>vendorspec, VENDORSPEC_PEREN |
> VENDORSPEC_CKEN);
> +   esdhc_setbits32(>vendorspec, VENDORSPEC_FRC_SDCLK_ON);
>  #else
> esdhc_setbits32(>sysctl, SYSCTL_PEREN | SYSCTL_CKEN);  #endif 
> @@ -
> 721,8 +724,14 @@ static void esdhc_set_strobe_dll(struct mmc *mmc)
> struct fsl_esdhc_priv *priv = dev_get_priv(mmc->dev);
> struct fsl_esdhc *regs = priv->esdhc_regs;
> u32 val;
> +   u32 tmp;
> +   int ret;
> 
> if (priv->clock > ESDHC_STROBE_DLL_CLK_FREQ) {
> +   esdhc_clrbits32(>vendorspec, VENDORSPEC_FRC_SDCLK_ON);
> +   ret = readx_poll_timeout(esdhc_read32, >prsstat, tmp, 
> tmp &
> PRSSTAT_SDOFF, 100);
> +   if (ret)
> +   pr_warn("fsl_esdhc_imx: Internal clock never
> + gate off.\n");
> esdhc_write32(>strobe_dllctrl, 
> ESDHC_STROBE_DLL_CTRL_RESET);
> 
> /*
> @@ -740,6 +749,7 @@ static void esdhc_set_strobe_dll(struct mmc *mmc)
> pr_warn("HS400 strobe DLL status REF not lock!\n");
> if (!(val & ESDHC_STROBE_DLL_STS_SLV_LOCK))
> pr_warn("HS400 strobe DLL status SLV not lock!\n");
> +   esdhc_setbits32(>vendorspec,
> + VENDORSPEC_FRC_SDCLK_ON);
> }
>  }
> 
> @@ -963,14 +973,18 @@ static int esdhc_set_ios_common(struct fsl_esdhc_priv
> *priv, struct mmc *mmc)  #ifdef MMC_SUPPORTS_TUNING
> if (mmc->clk_disable) {
>  #ifdef CONFIG_FSL_USDHC
> -   esdhc_clrbits32(>vendorspec, VENDORSPEC_CKEN);
> +   u32 tmp;
> +
> +   esdhc_clrbits32(>vendorspec, VENDORSPEC_FRC_SDCLK_ON);
> +   ret = readx_poll_timeout(esdhc_read32, >prsstat, tmp, 
> tmp &
> PRSSTAT_SDOFF, 100);
> +   if (ret)
> +   pr_warn("fsl_esdhc_imx: Internal clock never
> + 

RE: [PATCH] ARM: dts: imx8mq-evk: Remove u-boot,off-on-delay-us property

[ZHIZHIKIN Andrey]

Hello Fabio,

Thanks for taking care of this!

I believe this fix still applies to mx8m mini series, as without it - some SD 
Cards are failed to be recognized.

> -Original Message-
> From: Fabio Estevam 
> Sent: Monday, February 22, 2021 6:41 PM
> To: sba...@denx.de
> Cc: u-boot@lists.denx.de; trini ; loru...@gmail.com;
> ZHIZHIKIN Andrey ;
> peng@nxp.com; Fabio Estevam 
> Subject: [PATCH] ARM: dts: imx8mq-evk: Remove u-boot,off-on-delay-us
> property
> 
> 
> Commit 247bbeb74c18 ("ARM: dts: imx8m: increase off-on delay on the SD Vcc
> regulator") caused the imx8mq-evk board to not be able to store the
> environment variables in the SD card.
> 
> Remove the u-boot,off-on-delay-us property to fix the regression.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  arch/arm/dts/imx8mq-evk-u-boot.dtsi | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/arch/arm/dts/imx8mq-evk-u-boot.dtsi b/arch/arm/dts/imx8mq-evk-
> u-boot.dtsi
> index 44af66372712..2cfc12b7e0a4 100644
> --- a/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> @@ -1,9 +1,5 @@
>  // SPDX-License-Identifier: (GPL-2.0 OR MIT)
> 
> -_usdhc2_vmmc {
> -   u-boot,off-on-delay-us = <2>;
> -};
> -
>   {
> mmc-hs400-1_8v;
>  };
> --
> 2.25.1

Reviewed-by: Andrey Zhizhikin 

RE: i.MX8MQ EVK not booting with latest mainline U-Boot

[ZHIZHIKIN Andrey]

Hello Fabio,

> -Original Message-
> From: Fabio Estevam 
> Sent: Monday, February 22, 2021 3:45 AM
> To: Peng Fan ; ZHIZHIKIN Andrey  geosystems.com>
> Cc: Lukas Rusak ; U-Boot-Denx 
> Subject: i.MX8MQ EVK not booting with latest mainline U-Boot
> 
> This email is not from Hexagon’s Office 365 instance. Please be careful while
> clicking links, opening attachments, or replying to this email.
> 
> 
> Hi Peng and Andrey,
> 
> Lukas reported that i.MX8MQ EVK does not boot with the latest U-Boot and I
> confirm the same here too.

Unfortunately, I do not poses the i.MX8MQ EVK HW so I never tested the boot 
process. There is not much I can contribute here.

> 
> We are following the instructions from doc/board/freescale/imx8mq_evk.rst

Perhaps the only thing I can suggest here is to check the documentation (ATF, 
OP-TEE and DDR firmware version and placement) and align it with `imx-boot` 
Makefile to see if they match.

Can somebody maybe share more info on which errors are observed during the 
boot? Any boot log would be helpful here as well.

> 
> I haven't debugged this yet and I am wondering if you have any suggestions.
> 
> Thanks,
> 
> Fabio Estevam

-- Andrey

RE: [PATCH v2] doc: board: freescale: imx8mp_evk: update to newer versions and change ATF_LOAD_ADDR

[ZHIZHIKIN Andrey]

Hello Peter,

> -Original Message-
> From: Peter Bergin 
> Sent: Sunday, February 14, 2021 8:19 PM
> To: u-boot@lists.denx.de
> Cc: Peter Bergin ; ZHIZHIKIN Andrey
> 
> Subject: [PATCH v2] doc: board: freescale: imx8mp_evk: update to newer
> versions and change ATF_LOAD_ADDR
> 
> 
> Update imx-atf and firmware-imx to latest released versions.
> 
> Update address of ATF_LOAD_ADDR that has changed to 0x97 in imx-atf
> commit 48733cb4e773a7584ced601de9d717efa3d73815.
> 
> Add 'O=' to make and build in separate directory as one issue has been noticed
> where it was trouble building directly inside u-boot source dir. Restructure 
> the
> workflow
> and copy binaries after defconfig to ensure that build directory is created.
> 
> Signed-off-by: Peter Bergin 
> Cc: Andrey Zhizhikin 
> ---
> v2:
>   - Corrected ATF_LOAD_ADDR in commit message
>   - Changed workflow to copy binaries after build directory is created
> 
>  doc/board/freescale/imx8mp_evk.rst | 27 +--
>  1 file changed, 13 insertions(+), 14 deletions(-)
> 
> diff --git a/doc/board/freescale/imx8mp_evk.rst
> b/doc/board/freescale/imx8mp_evk.rst
> index ccffcf7257..796a7611d0 100644
> --- a/doc/board/freescale/imx8mp_evk.rst
> +++ b/doc/board/freescale/imx8mp_evk.rst
> @@ -16,27 +16,21 @@ Quick Start
>  Get and Build the ARM Trusted firmware
>  --
> 
> -Note: $(srctree) is the U-Boot source directory
>  Get ATF from: https://source.codeaurora.org/external/imx/imx-atf
> -branch: imx_5.4.47_2.2.0
> +branch: imx_5.4.70_2.3.0
> 
>  .. code-block:: bash
> 
> $ make PLAT=imx8mp bl31
> -   $ cp build/imx8mp/release/bl31.bin $(srctree)
> 
>  Get the ddr firmware
>  
> 
>  .. code-block:: bash
> 
> -   $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.9.bin
> -   $ chmod +x firmware-imx-8.9.bin
> -   $ ./firmware-imx-8.9.bin
> -   $ cp 
> firmware-imx-8.9/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_201904.bin 
> $(srctree)/lpddr4_pmu_train_1d_dmem.bin
> -   $ cp 
> firmware-imx-8.9/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_201904.bin 
> $(srctree)/lpddr4_pmu_train_1d_imem.bin
> -   $ cp 
> firmware-imx-8.9/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_201904.bin 
> $(srctree)/lpddr4_pmu_train_2d_dmem.bin
> -   $ cp 
> firmware-imx-8.9/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_201904.bin 
> $(srctree)/lpddr4_pmu_train_2d_imem.bin
> +   $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.10.bin
> +   $ chmod +x firmware-imx-8.10.bin
> +   $ ./firmware-imx-8.10.bin
> 
>  Build U-Boot
>  
> @@ -44,15 +38,20 @@ Build U-Boot
>  .. code-block:: bash
> 
> $ export CROSS_COMPILE=aarch64-poky-linux-
> -   $ make imx8mp_evk_defconfig
> -   $ export ATF_LOAD_ADDR=0x96
> -   $ make flash.bin
> +   $ make O=build imx8mp_evk_defconfig
> +   $ cp ../imx-atf/build/imx8mp/release/bl31.bin ./build/bl31.bin
> +   $ cp 
> ../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_202006.bin
>  ./build/lpddr4_pmu_train_1d_dmem.bin
> +   $ cp 
> ../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_202006.bin
>  ./build/lpddr4_pmu_train_1d_imem.bin
> +   $ cp 
> ../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_202006.bin
>  ./build/lpddr4_pmu_train_2d_dmem.bin
> +   $ cp 
> ../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_202006.bin
>  ./build/lpddr4_pmu_train_2d_imem.bin
> +   $ export ATF_LOAD_ADDR=0x97
> +   $ make O=build flash.bin
> 
>  Burn the flash.bin to the MicroSD card at offset 32KB:
> 
>  .. code-block:: bash
> 
> -   $sudo dd if=flash.bin of=/dev/sd[x] bs=1K seek=32 conv=notrunc; sync
> +   $sudo dd if=build/flash.bin of=/dev/sd[x] bs=1K seek=32 conv=notrunc; sync
> 
>  Boot
>  
> --
> 2.25.1

Reviewed-by: Andrey Zhizhikin 

RE: [PATCH] doc: board: freescale: imx8mp_evk: update to newer versions and change ATF_LOAD_ADDR

[ZHIZHIKIN Andrey]

Hello Peter,

> -Original Message-
> From: Peter Bergin 
> Sent: Friday, February 12, 2021 2:57 PM
> To: u-boot@lists.denx.de
> Cc: Peter Bergin ; ZHIZHIKIN Andrey
> 
> Subject: [PATCH] doc: board: freescale: imx8mp_evk: update to newer versions
> and change ATF_LOAD_ADDR
> 
> Update imx-atf and firmware-imx to latest released versions.
> 
> Update address of ATF_LOAD_ADDR that has changed to 0x49 in imx-atf
> commit 48733cb4e773a7584ced601de9d717efa3d73815.

Commit message is incorrect, ATF_LOAD_ADDR is actually set to 0x97

> 
> Add 'O=' to make instructions as one issue has been noticed where it was 
> trouble
> building directly inside u-boot source dir.
> 
> Signed-off-by: Peter Bergin 
> Cc: Andrey Zhizhikin 
> ---
>  doc/board/freescale/imx8mp_evk.rst | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/doc/board/freescale/imx8mp_evk.rst
> b/doc/board/freescale/imx8mp_evk.rst
> index ccffcf7257..5ca3bb8199 100644
> --- a/doc/board/freescale/imx8mp_evk.rst
> +++ b/doc/board/freescale/imx8mp_evk.rst
> @@ -18,7 +18,7 @@ Get and Build the ARM Trusted firmware
> 
>  Note: $(srctree) is the U-Boot source directory  Get ATF from: 
> https://source.codeaurora.org/external/imx/imx-atf
> -branch: imx_5.4.47_2.2.0
> +branch: imx_5.4.70_2.3.0
> 
>  .. code-block:: bash
> 
> @@ -30,13 +30,13 @@ Get the ddr firmware
> 
>  .. code-block:: bash
> 
> -   $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.9.bin
> -   $ chmod +x firmware-imx-8.9.bin
> -   $ ./firmware-imx-8.9.bin
> -   $ cp firmware-imx-
> 8.9/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_201904.bin
> $(srctree)/lpddr4_pmu_train_1d_dmem.bin
> -   $ cp firmware-imx-
> 8.9/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_201904.bin
> $(srctree)/lpddr4_pmu_train_1d_imem.bin
> -   $ cp firmware-imx-
> 8.9/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_201904.bin
> $(srctree)/lpddr4_pmu_train_2d_dmem.bin
> -   $ cp firmware-imx-
> 8.9/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_201904.bin
> $(srctree)/lpddr4_pmu_train_2d_imem.bin
> +   $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.10.bin
> +   $ chmod +x firmware-imx-8.10.bin
> +   $ ./firmware-imx-8.10.bin
> +   $ cp firmware-imx-
> 8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_202006.bin
> $(srctree)/lpddr4_pmu_train_1d_dmem.bin
> +   $ cp firmware-imx-
> 8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_202006.bin
> $(srctree)/lpddr4_pmu_train_1d_imem.bin
> +   $ cp firmware-imx-
> 8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_202006.bin
> $(srctree)/lpddr4_pmu_train_2d_dmem.bin
> +   $ cp
> + firmware-imx-
> 8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_20200
> + 6.bin $(srctree)/lpddr4_pmu_train_2d_imem.bin
> 
>  Build U-Boot
>  
> @@ -44,15 +44,15 @@ Build U-Boot
>  .. code-block:: bash
> 
> $ export CROSS_COMPILE=aarch64-poky-linux-
> -   $ make imx8mp_evk_defconfig
> -   $ export ATF_LOAD_ADDR=0x96
> -   $ make flash.bin
> +   $ make O=build imx8mp_evk_defconfig

As a suggestion: maybe it is better to change the order here when `make O=build 
imx8mp_evk_defconfig` called first, followed by copy of DDR firmware and ATF 
binary.

This would make sure that the ./build folder would already exist at the time 
copy operations are executed, and should make step-by-step instructions more 
transparent.

> +   $ export ATF_LOAD_ADDR=0x97
> +   $ make O=build flash.bin
> 
>  Burn the flash.bin to the MicroSD card at offset 32KB:
> 
>  .. code-block:: bash
> 
> -   $sudo dd if=flash.bin of=/dev/sd[x] bs=1K seek=32 conv=notrunc; sync
> +   $sudo dd if=build/flash.bin of=/dev/sd[x] bs=1K seek=32
> + conv=notrunc; sync
> 
>  Boot
>  
> --
> 2.25.1

Otherwise:
Reviewed-by: Andrey Zhizhikin 

Cheers,
Andrey

RE: Boot problems imx8mp_evk

[ZHIZHIKIN Andrey]

Hello Peter,

> -Original Message-
> From: Peter Bergin 
> Sent: Friday, February 12, 2021 9:01 AM
> To: ZHIZHIKIN Andrey ; Adam Ford
> 
> Cc: U-Boot Mailing List ; NXP Linux Team  i...@nxp.com>
> Subject: Re: Boot problems imx8mp_evk
> 
> Hi,
> 
> this has been put aside for a while but tested this again and problem still 
> remains
> for me.
> 
> 
> >>> Hi,
> >>>
> >>> I'm following the README
> >>> to bring up u-boot on a imx8mp EVK board. My boot ends up in this on
> >>> the
> >>> console:
> >>>
> >>>   U-Boot SPL 2020.10-rc5-00049-gd44d46e9fa (Sep 30 2020 - 11:46:20 
> >>> +0200)
> >>>   Normal Boot
> >>>   WDT:   Started with servicing (60s timeout)
> >>>   Trying to boot from BOOTROM
> >>>   image offset 0x8000, pagesize 0x200, ivt offset 0x0
> >>>   Can't support legacy image
> >>>   SPL: failed to boot from all boot devices
> >>>   ### ERROR ### Please RESET the board ###
> >>>
> >>> Any ideas what is going wrong? How to debug further?
> >>>
> >> I am trying to port U-Boot to an i.MX8M Nano and I am getting the same
> result.
> > This might not be related, but looking at the ATF branch [imx_5.4.3_2.0.0] 
> > - it
> appears to be too old, at least for i.MX8M Plus. I was able to run the U-Boot
> 2020.10 with ATF built from [imx_5.4.47_2.2.0] on the i.MX8M Plus and it does
> boot successful.
> >
> > Boot log show the following banner when BOOTROM finishes up the copy:
> > NOTICE:  BL31: v2.2(release):rel_imx_5.4.47_2.2.0-0-gc949a888e-dirty
> > NOTICE:  BL31: Built : 05:51:50, Sep  9 2020
> >
> > Peter,
> > i.MX8M Plus support in NXP ATF fork appears to be added by commit
> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsour
> > ce.codeaurora.org%2Fexternal%2Fimx%2Fimx-
> atf%2Fcommit%2F%3Fid%3D6b8249
> >
> ff58cc8853396498a074535dcd7f81beafdata=04%7C01%7C%7C719a95122be
> 04
> >
> 757a8b208d8cf2c3dff%7C1b16ab3eb8f64fe39f3e2db7fe549f6a%7C0%7C0%7C637
> 48
> >
> 7136220734827%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2lu
> >
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=tGc0fgRB0LmDF9
> WPNU
> > EMMzjVidBLyf3exwHHN1W15Pk%3Dreserved=0, and that came in ATF
> > revision far newer than indicated in
> > doc/board/freescale/imx8mp_evk.rst
> >
> > Try to rebase your ATF to [c949a888e909811db191500c51456391dff61284] and
> build according to the board doc file.
> >
> Andrey, Thanks for advice about the commit in imx-atf. Unfortunately it does 
> not
> seem to solve the issue.
> 
> This is what I tested today and where I ended up today:
> 
>  $ cd imx-atf
>  $ git checkout imx_5.4.70_2.3.0
>  $ make PLAT=imx8mp bl31
>  $ cd ../u-boot
>  $ git checkout master (80c7e4cf76d204d4b726b0cc57a557a9d9c1c453)
>  $ cp ../imx-atf/build/imx8mp/release/bl31.bin .
>  $ cp
> ../firmware-imx-
> 8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_202006.bin
> lpddr4_pmu_train_1d_dmem.bin
>  $ cp
> ../firmware-imx-
> 8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_202006.bin
> lpddr4_pmu_train_1d_imem.bin
>  $ cp
> ../firmware-imx-
> 8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_202006.bin
> lpddr4_pmu_train_2d_dmem.bin
>  $ cp
> ../firmware-imx-
> 8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_202006.bin
> lpddr4_pmu_train_2d_imem.bin
>  $ export ATF_LOAD_ADDR=0x96

In the latest ATF, the LOAD_ADDR has been changed from 0x96 to 0x97. 
This was done by commit 48733cb4e ("MLK-24913: plat: imx8mp: change the bl31 
physical load address").

>  $ make imx8mp_evk_defconfig
>  $ make flash.bin
>  $ sudo dd if=flash.bin of=/dev/mmcblk0 bs=1024 seek=32

I have the following build script file, which works for me:
===
#!/usr/bin/env bash

set -o xtrace# print commands and their arguments as they are executed
set -o errexit   # exit immediately if a command exits with a non-zero status

build_dir="/development/imx-boot/build/nxp/imx8mpevk"

rm -rf $build_dir
make O=$build_dir imx8mp_evk_defconfig

# Copy auxilary needed files
cp ../imx-atf/build/imx8mp/release/bl31.bin "$build_dir/"
cp 
../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_201904.bin 
"$build_dir/lpddr4_pmu_train_1d_dmem.bin"
cp 
../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_201904.bin 
"$build_dir/lpddr4_pmu_train_1d_imem.bin"
cp 
../firmware-imx-8.10/firmware/ddr/synopsys/

RE: [PATCH] mmc: fsl_esdhc_imx: use VENDORSPEC_FRC_SDCLK_ON to control card clock output

[ZHIZHIKIN Andrey]

Hello Haibo,

> -Original Message-
> From: Bough Chen 
> Sent: Friday, February 5, 2021 8:24 AM
> To: ZHIZHIKIN Andrey ; Peng Fan
> ; u-boot@lists.denx.de
> Cc: dl-uboot-imx ; thar...@gateworks.com
> Subject: RE: [PATCH] mmc: fsl_esdhc_imx: use VENDORSPEC_FRC_SDCLK_ON to
> control card clock output
> 
> > -Original Message-
> > From: ZHIZHIKIN Andrey [mailto:andrey.zhizhi...@leica-geosystems.com]
> > Sent: 2021年2月1日 19:41
> > To: Bough Chen ; Peng Fan ;
> > u-boot@lists.denx.de
> > Cc: dl-uboot-imx ; thar...@gateworks.com
> > Subject: RE: [PATCH] mmc: fsl_esdhc_imx: use VENDORSPEC_FRC_SDCLK_ON
> > to control card clock output
> >
> > Hello Haibo,
> >
> > > -Original Message-
> > > From: Bough Chen 
> > > Sent: Monday, February 1, 2021 11:10 AM
> > > To: ZHIZHIKIN Andrey ; Peng
> > > Fan ; u-boot@lists.denx.de
> > > Cc: dl-uboot-imx ; thar...@gateworks.com
> > > Subject: RE: [PATCH] mmc: fsl_esdhc_imx: use
> > VENDORSPEC_FRC_SDCLK_ON
> > > to control card clock output
> > >
> > > > -Original Message-
> > > > From: ZHIZHIKIN Andrey
> > > > [mailto:andrey.zhizhi...@leica-geosystems.com]
> > > > Sent: 2021年2月1日 17:52
> > > > To: Bough Chen ; Peng Fan ;
> > > > u-boot@lists.denx.de
> > > > Cc: dl-uboot-imx ; thar...@gateworks.com
> > > > Subject: RE: [PATCH] mmc: fsl_esdhc_imx: use
> > VENDORSPEC_FRC_SDCLK_ON
> > > > to control card clock output
> > > >
> > > > Hello Haibo,
> > > >
> > > > > -Original Message-
> > > > > From: haibo.c...@nxp.com 
> > > > > Sent: Wednesday, January 27, 2021 11:47 AM
> > > > > To: peng@nxp.com; u-boot@lists.denx.de
> > > > > Cc: haibo.c...@nxp.com; uboot-...@nxp.com;
> > thar...@gateworks.com;
> > > > > ZHIZHIKIN Andrey 
> > > > > Subject: [PATCH] mmc: fsl_esdhc_imx: use VENDORSPEC_FRC_SDCLK_ON
> > > > > to control card clock output
> > > > >
> > > > > From: Haibo Chen 
> > > > >
> > > > > For FSL_USDHC, it do not implement
> > > > VENDORSPEC_CKEN/PEREN/HCKEN/IPGEN,
> > > > > these are reserved bits. Instead, use VENDORSPEC_FRC_SDCLK_ON to
> > > > > gate on/off the card clock output.
> > > > >
> > > > > After commit b5874b552ffa ("mmc: fsl_esdhc_imx: add wait_dat0()
> > > > > support"), we meet SD3.0 card can't work at UHS mode,
> > > > > mmc_switch_voltage() fail because the second mmc_wait_dat0
> > > > > return -ETIMEDOUT. According to SD spec, during voltage switch,
> > > > > need to gate off/on the card clock. If not set the FRC_SDCLK_ON,
> > > > > after CMD11, hardware will gate off the card clock
> > > > > automatically, so card do not detect the clock off/on behavior,
> > > > > so will draw the
> > > > > data0 line low until next
> > > > command.
> > > > >
> > > > > Fixes: b5874b552ffa ("mmc: fsl_esdhc_imx: add wait_dat0()
> > > > > support")
> > > >
> > > > This patch does not fix the switch of uSDHC to 1v8...
> > > >
> > > > I've applied it locally on the imx8mmevk, and had following log
> > > > during the boot when tried to query SD Card info:
> > > > ---
> > > > U-Boot SPL 2021.01-01004-gb852007333 (Feb 01 2021 - 09:45:42
> > > > +0100) Normal Boot
> > > > WDT:   Started with servicing (60s timeout)
> > > > Trying to boot from MMC1
> > > > NOTICE:  BL31: v2.2(release):rel_imx_5.4.70_2.3.0-0-gf1d7187f2
> > > > NOTICE:  BL31: Built : 22:29:05, Jan 17 2021
> > > >
> > > >
> > > > U-Boot 2021.01-01004-gb852007333 (Feb 01 2021 - 09:45:42 +0100)
> > > >
> > > > CPU:   Freescale i.MX8MMQ rev1.0 at 1200 MHz
> > > > Reset cause: POR
> > > > Model: FSL i.MX8MM EVK board
> > > > DRAM:  2 GiB
> > > > WDT:   Started with servicing (60s timeout)
> > > > MMC:   FSL_SDHC: 1, FSL_SDHC: 2
> > > > Loading Environment from MMC... Run CMD11 1.8V switch Card did not
> > > > respond to voltage select! : -110
> > >
> > > This do not align with my test result. Can you help identify which
> > > function first return the 

RE: [PATCH] mmc: fsl_esdhc_imx: use VENDORSPEC_FRC_SDCLK_ON to control card clock output

[ZHIZHIKIN Andrey]

Hello Haibo,

> -Original Message-
> From: Bough Chen 
> Sent: Monday, February 1, 2021 11:10 AM
> To: ZHIZHIKIN Andrey ; Peng Fan
> ; u-boot@lists.denx.de
> Cc: dl-uboot-imx ; thar...@gateworks.com
> Subject: RE: [PATCH] mmc: fsl_esdhc_imx: use VENDORSPEC_FRC_SDCLK_ON to
> control card clock output
> 
> > -Original Message-
> > From: ZHIZHIKIN Andrey [mailto:andrey.zhizhi...@leica-geosystems.com]
> > Sent: 2021年2月1日 17:52
> > To: Bough Chen ; Peng Fan ;
> > u-boot@lists.denx.de
> > Cc: dl-uboot-imx ; thar...@gateworks.com
> > Subject: RE: [PATCH] mmc: fsl_esdhc_imx: use VENDORSPEC_FRC_SDCLK_ON
> > to control card clock output
> >
> > Hello Haibo,
> >
> > > -Original Message-
> > > From: haibo.c...@nxp.com 
> > > Sent: Wednesday, January 27, 2021 11:47 AM
> > > To: peng@nxp.com; u-boot@lists.denx.de
> > > Cc: haibo.c...@nxp.com; uboot-...@nxp.com; thar...@gateworks.com;
> > > ZHIZHIKIN Andrey 
> > > Subject: [PATCH] mmc: fsl_esdhc_imx: use VENDORSPEC_FRC_SDCLK_ON to
> > > control card clock output
> > >
> > > From: Haibo Chen 
> > >
> > > For FSL_USDHC, it do not implement
> > VENDORSPEC_CKEN/PEREN/HCKEN/IPGEN,
> > > these are reserved bits. Instead, use VENDORSPEC_FRC_SDCLK_ON to
> > > gate on/off the card clock output.
> > >
> > > After commit b5874b552ffa ("mmc: fsl_esdhc_imx: add wait_dat0()
> > > support"), we meet SD3.0 card can't work at UHS mode,
> > > mmc_switch_voltage() fail because the second mmc_wait_dat0 return
> > > -ETIMEDOUT. According to SD spec, during voltage switch, need to
> > > gate off/on the card clock. If not set the FRC_SDCLK_ON, after
> > > CMD11, hardware will gate off the card clock automatically, so card
> > > do not detect the clock off/on behavior, so will draw the data0 line
> > > low until next
> > command.
> > >
> > > Fixes: b5874b552ffa ("mmc: fsl_esdhc_imx: add wait_dat0() support")
> >
> > This patch does not fix the switch of uSDHC to 1v8...
> >
> > I've applied it locally on the imx8mmevk, and had following log during
> > the boot when tried to query SD Card info:
> > ---
> > U-Boot SPL 2021.01-01004-gb852007333 (Feb 01 2021 - 09:45:42 +0100)
> > Normal Boot
> > WDT:   Started with servicing (60s timeout)
> > Trying to boot from MMC1
> > NOTICE:  BL31: v2.2(release):rel_imx_5.4.70_2.3.0-0-gf1d7187f2
> > NOTICE:  BL31: Built : 22:29:05, Jan 17 2021
> >
> >
> > U-Boot 2021.01-01004-gb852007333 (Feb 01 2021 - 09:45:42 +0100)
> >
> > CPU:   Freescale i.MX8MMQ rev1.0 at 1200 MHz
> > Reset cause: POR
> > Model: FSL i.MX8MM EVK board
> > DRAM:  2 GiB
> > WDT:   Started with servicing (60s timeout)
> > MMC:   FSL_SDHC: 1, FSL_SDHC: 2
> > Loading Environment from MMC... Run CMD11 1.8V switch Card did not
> > respond to voltage select! : -110
> 
> This do not align with my test result. Can you help identify which function 
> first
> return the timeout on your side?

I would have a look at the exact function, but it seems to me that it would be 
wait_dat0()
since if I revert the patch introducing it - high speed mode switch is not 
timing out.

> Or can you try a different SD card?

It is rather strange, it seems like it is dependent on the SD Card used.

So far, I've tried 3 SD Cards I had on hands, one of which being operable:
== Working:
"Transcend 32GB"
Manufacturer ID: 74
OEM: 4a60
Name: USDU1

== Failed:
1. (Kingston 32GB)
Manufacturer ID: 41
OEM: 3432
Name: SD32G

2. (Intenso 32 GB)
Manufacturer ID: 9f
OEM: 5449
Name: 0

This raises a concern that a regular off-the-shelf SD Card might exhibit this 
issue or might not -
it is not tight to a one specific SD Card. Hence I believe it is quite 
important to look at it further,
as there might be a lot of reports from various users.

Please note, that for all SD Cards I've tested NVCC_SD2 is indeed physically 
switched to 1v8.

> 
> Best Regards
> Haibo
> 
> > *** Warning - No block device, using default environment
> >
> > In:serial
> > Out:   serial
> > Err:   serial
> > Net:   eth0: ethernet@30be
> > Hit any key to stop autoboot:  0
> > u-boot=> mmc dev 1
> > Card did not respond to voltage select! : -110 u-boot=> mmc info MMC
> > Device
> > 0 not found no mmc device at slot 0 u-boot=> mmc dev 2 switch to
> > partitions #0, OK mmc2(part 0) is current device u-boot=> mmc info
> > Device: FSL_SDHC
> > Manufacturer ID: 45
> &

RE: [PATCH] mmc: fsl_esdhc_imx: use VENDORSPEC_FRC_SDCLK_ON to control card clock output

[ZHIZHIKIN Andrey]

Hello Haibo,

> -Original Message-
> From: haibo.c...@nxp.com 
> Sent: Wednesday, January 27, 2021 11:47 AM
> To: peng@nxp.com; u-boot@lists.denx.de
> Cc: haibo.c...@nxp.com; uboot-...@nxp.com; thar...@gateworks.com;
> ZHIZHIKIN Andrey 
> Subject: [PATCH] mmc: fsl_esdhc_imx: use VENDORSPEC_FRC_SDCLK_ON to
> control card clock output
> 
> This email is not from Hexagon’s Office 365 instance. Please be careful while
> clicking links, opening attachments, or replying to this email.
> 
> 
> From: Haibo Chen 
> 
> For FSL_USDHC, it do not implement VENDORSPEC_CKEN/PEREN/HCKEN/IPGEN,
> these are reserved bits. Instead, use VENDORSPEC_FRC_SDCLK_ON to gate
> on/off the card clock output.
> 
> After commit b5874b552ffa ("mmc: fsl_esdhc_imx: add wait_dat0() support"),
> we meet SD3.0 card can't work at UHS mode, mmc_switch_voltage() fail because
> the second mmc_wait_dat0 return -ETIMEDOUT. According to SD spec, during
> voltage switch, need to gate off/on the card clock. If not set the 
> FRC_SDCLK_ON,
> after CMD11, hardware will gate off the card clock automatically, so card do 
> not
> detect the clock off/on behavior, so will draw the data0 line low until next
> command.
> 
> Fixes: b5874b552ffa ("mmc: fsl_esdhc_imx: add wait_dat0() support")

This patch does not fix the switch of uSDHC to 1v8...

I've applied it locally on the imx8mmevk, and had following log during the boot 
when tried
to query SD Card info:
---
U-Boot SPL 2021.01-01004-gb852007333 (Feb 01 2021 - 09:45:42 +0100)
Normal Boot
WDT:   Started with servicing (60s timeout)
Trying to boot from MMC1
NOTICE:  BL31: v2.2(release):rel_imx_5.4.70_2.3.0-0-gf1d7187f2
NOTICE:  BL31: Built : 22:29:05, Jan 17 2021


U-Boot 2021.01-01004-gb852007333 (Feb 01 2021 - 09:45:42 +0100)

CPU:   Freescale i.MX8MMQ rev1.0 at 1200 MHz
Reset cause: POR
Model: FSL i.MX8MM EVK board
DRAM:  2 GiB
WDT:   Started with servicing (60s timeout)
MMC:   FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... Run CMD11 1.8V switch
Card did not respond to voltage select! : -110
*** Warning - No block device, using default environment

In:serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@30be
Hit any key to stop autoboot:  0
u-boot=> mmc dev 1
Card did not respond to voltage select! : -110
u-boot=> mmc info
MMC Device 0 not found
no mmc device at slot 0
u-boot=> mmc dev 2
switch to partitions #0, OK
mmc2(part 0) is current device
u-boot=> mmc info
Device: FSL_SDHC
Manufacturer ID: 45
OEM: 100
Name: DG401
Bus Speed: 2
Mode: HS400ES (200MHz)
Rd Block Len: 512
MMC version 5.1
High Capacity: Yes
Capacity: 14.7 GiB
Bus Width: 8-bit DDR
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 14.7 GiB WRREL
Boot Capacity: 4 MiB ENH
RPMB Capacity: 4 MiB ENH
Boot area 0 is not write protected
Boot area 1 is not write protected
---

Note, that eMMC is not affected and is operating in HS400ES mode without any 
issues.

Reverting patch b5874b552ffa ("mmc: fsl_esdhc_imx: add wait_dat0() support") 
with this
patch applied in tree does switch the SD Card to high-speed mode, following log 
is produced:
---
U-Boot SPL 2021.01-01005-gb8aeb689a2 (Feb 01 2021 - 10:38:01 +0100)
Normal Boot
WDT:   Started with servicing (60s timeout)
Trying to boot from MMC1
NOTICE:  BL31: v2.2(release):rel_imx_5.4.70_2.3.0-0-gf1d7187f2
NOTICE:  BL31: Built : 22:29:05, Jan 17 2021


U-Boot 2021.01-01005-gb8aeb689a2 (Feb 01 2021 - 10:38:01 +0100)

CPU:   Freescale i.MX8MMQ rev1.0 at 1200 MHz
Reset cause: POR
Model: FSL i.MX8MM EVK board
DRAM:  2 GiB
WDT:   Started with servicing (60s timeout)
MMC:   FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... Run CMD11 1.8V switch
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@30be
Hit any key to stop autoboot:  0
u-boot=> mmc dev 1
Run CMD11 1.8V switch
switch to partitions #0, OK
mmc1 is current device
u-boot=> mmc info
Device: FSL_SDHC
Manufacturer ID: 41
OEM: 3432
Name: SD32G
Bus Speed: 2
Mode: UHS SDR104 (208MHz)
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 29.3 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
u-boot=> mmc dev 2
switch to partitions #0, OK
mmc2(part 0) is current device
u-boot=> mmc info
Device: FSL_SDHC
Manufacturer ID: 45
OEM: 100
Name: DG401
Bus Speed: 2
Mode: HS400ES (200MHz)
Rd Block Len: 512
MMC version 5.1
High Capacity: Yes
Capacity: 14.7 GiB
Bus Width: 8-bit DDR
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 14.7 GiB WRREL
Boot Capacity: 4 MiB ENH
RPMB Capacity: 4 MiB ENH
Boot area 0 is not write protected
Boot area 1 is not write protected
---

I guess high-

RE: IMX8MM SD UHS support

[ZHIZHIKIN Andrey]

Hello Tim,

> -Original Message-
> From: Tim Harvey 
> Sent: Tuesday, January 19, 2021 6:32 PM
> To: ZHIZHIKIN Andrey 
> Cc: haibo.c...@nxp.com; Adam Ford ; Fabio Estevam
> ; Peng Fan ; u-boot  b...@lists.denx.de>; Stefano Babic ; Jaehoon Chung
> 
> Subject: Re: IMX8MM SD UHS support
> 
> On Mon, Jan 18, 2021 at 11:38 AM ZHIZHIKIN Andrey
>  wrote:
> >
> > Hello Tim,
> >
> > Sorry it took me quite some time to get this sorted out, but I believe I 
> > was able
> to identify an offending commit that is preventing the USDHC to switch to 
> higher
> speed modes.
> >
> > It is in fact b5874b552f ("mmc: fsl_esdhc_imx: add wait_dat0() support"),
> reverting it makes SD Card to properly report capabilities and switch to high
> speed modes.
> >
> > Can you try to revert this on your end to see if the SD Card would start to
> operate in high speed mode?
> >
> > I'm still investigating why this addition of wait_dat0() caused this, I 
> > believe this
> is due to the fact that the same wait is already performed while voltage 
> switch to
> handle the errata, thus this addition wait might erroneously timeout.
> >
> > ++ Haibo Chen 
> >
> > Haibo,
> >
> > Can you please explain the purpose of adding wait_dat0() Introduced with
> commit b5874b552f? It is not clear from the commit message what was the
> purpose of adding it. Have you tested the USDHC switch to higher modes with
> this change?
> 
> Andrey,
> 
> Reverting b5874b552f ("mmc: fsl_esdhc_imx: add wait_dat0() support")
> does not resolve the issue. That function waits for a specified
> timeout for the card to assert DAT[0] either high or low depending on
> arg and is used to check for command busy or failure. The patch in
> question adds that function so that the common mmc code can utilize
> it. If the function does not exist in the host controller driver any
> call to mmc_wait_dat0 returns -ENOSYS so it must be there to support
> UHS anyway.

Perhaps, this is due to the fact that the same wait cycle is already
executed during the invocation of mmc_send_cmd above the
mmc_wait_dat0() in drivers/mmc/mmc.c.

mmc_send_cmd calls esdhc_send_cmd_common in
drivers/mmc/fsl_esdhc_imx.c, which already has a wait loop
implemented to cover the "Workaround for ESDHC errata ENGcm03648"
(as seen from the comment), which might explain why consecutive
wait fails to return within timeout value.

> 
> What is not clear to me is why the card would hold DAT[0] low on the
> voltage switch indicating a failure as it does not in the Linux driver
> which appears to me to be doing the same thing.

This behavior might be explained by the implementation I traced above.

> Again, if we ignore the return code UHS works fine and I'm not at all clear 
> why you
> wouldn't run into this issue:
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index a6394bc..5ea3cd2 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -579,10 +579,12 @@ static int mmc_switch_voltage(struct mmc *mmc,
> int signal_voltage)
>  * dat[0:3] low. Wait for at least 1 ms according to spec
>  */
> err = mmc_wait_dat0(mmc, 1, 1000);
> +#if 0 // hack: not clear why card always holds DAT[0] high here on
> fsl_esdhc_imx
> if (err == -ENOSYS)
> udelay(1000);
> else if (err)
> return -ETIMEDOUT;
> +#endif
> 
> return 0;
>  }

This is expected. When the wait_dat0 callback is undefined in dm_mmc_ops
structure - it defaults to return -ENOSYS, which effectively just inhibit a 
delay
in mmc_switch_voltage and returns 0 indicating that call was successful. This
all can be seen from the code snippet you've posted above and had commented
out under #if0 block.

Looking at the change you've posted, it seems to me that you haven't attempted
to revert the patch I mentioned, as by reverting it - the "if (err == -ENOSYS)"
path would've been taken and the desired return 0; would've been called.

> 
> Honestly I don't have the time to keep delving into this. I don't have
> any reason to believe that UHS has ever worked with fsl_esdhc_imx and
> because my boards boot from eMMC (and HS200/HS400 works) I'm not
> missing out on much by having a slow microSD.

I still believe (and witnessed it myself) that the original implementation was
indeed capable of successfully switching the USDHC to high speed modes.

At this point in time it might not be relevant for your implementation,
but could help those who has a severe impact from the microSD RW
performance in U-Boot.

Anyways, thanks a lot for writing back on the findings you have!

As for me, it would still be beneficial if the patch author (Haibo) could
comment on the intention of its introduction, because I clearly see
that reverting it on the current master branch does improve the behavior.

> 
> Best regards,
> 
> Tim

Cheers,
Andrey

RE: IMX8MM SD UHS support

[ZHIZHIKIN Andrey]

Hello Tim,

Sorry it took me quite some time to get this sorted out, but I believe I was 
able to identify an offending commit that is preventing the USDHC to switch to 
higher speed modes.

It is in fact b5874b552f ("mmc: fsl_esdhc_imx: add wait_dat0() support"), 
reverting it makes SD Card to properly report capabilities and switch to high 
speed modes.

Can you try to revert this on your end to see if the SD Card would start to 
operate in high speed mode?

I'm still investigating why this addition of wait_dat0() caused this, I believe 
this is due to the fact that the same wait is already performed while voltage 
switch to handle the errata, thus this addition wait might erroneously timeout.

++ Haibo Chen 

Haibo,

Can you please explain the purpose of adding wait_dat0() Introduced with commit 
b5874b552f? It is not clear from the commit message what was the purpose of 
adding it. Have you tested the USDHC switch to higher modes with this change?

> -Original Message-
> From: Tim Harvey 
> Sent: Wednesday, January 6, 2021 12:10 AM
> To: ZHIZHIKIN Andrey 
> Cc: Adam Ford ; Fabio Estevam ;
> Peng Fan ; u-boot ; Stefano Babic
> 
> Subject: Re: IMX8MM SD UHS support
> 
> This email is not from Hexagon’s Office 365 instance. Please be careful while
> clicking links, opening attachments, or replying to this email.
> 
> 
> On Wed, Dec 30, 2020 at 1:00 PM ZHIZHIKIN Andrey  geosystems.com> wrote:
> >
> > Hello Tim,
> >
> > > -Original Message-
> > > From: Tim Harvey 
> > > Sent: Wednesday, December 30, 2020 7:48 PM
> > > To: Adam Ford 
> > > Cc: Fabio Estevam ; ZHIZHIKIN Andrey
> > > ; Peng Fan
> > > ; u- boot ; Stefano Babic
> > > 
> > > Subject: Re: IMX8MM SD UHS support
> > >
> > >
> > > On Wed, Dec 30, 2020 at 10:22 AM Adam Ford  wrote:
> > > >
> > > > On Wed, Dec 30, 2020 at 11:50 AM Fabio Estevam
> > > > 
> > > wrote:
> > > > >
> > > > > Hi Tim,
> > > > >
> > > > > On Wed, Dec 30, 2020 at 1:54 PM Tim Harvey
> > > > > 
> > > wrote:
> > > > >
> > > > > > Andrey,
> > > > > >
> > > > > > I did mention that I am using the imx8mm-evk. When I saw that
> > > > > > my custom board was having issues with sd_get_capabilities() I
> > > > > > switched to the imx8mm-evk and confirmed my findings there.
> >
> > I've missed the part that you've tested the same behavior on i.MX8M Mini EVK
> in your original message, sorry for that.
> >
> > > > > >
> > > > > > I'm using master (ab865a8ee5c1) with imx8mm_evk_defconfig
> > > > > > running on an imx8mm-evk board configured via dip switches to
> > > > > > boot from eMMC. I have a SDR104 microSD which detects and
> > > > > > operates as such in Linux and this is what I see in U-Boot:
> > > > > >
> > > > > > U-Boot SPL 2021.01-rc4-00029-gab865a8 (Dec 30 2020 - 08:29:24
> > > > > > -0800) Normal Boot
> > > > > > WDT:   Started with servicing (60s timeout)
> > > > > > Trying to boot from MMC2
> > > > > >
> > > > > >
> > > > > > U-Boot 2021.01-rc4-00029-gab865a8 (Dec 30 2020 - 08:29:24
> > > > > > -0800)
> > > > > >
> > > > > > CPU:   Freescale i.MX8MMQ rev1.0 at 1200 MHz
> > > > > > Reset cause: POR
> > > > > > Model: FSL i.MX8MM EVK board
> > > > > > DRAM:  2 GiB
> > > > > > WDT:   Started with servicing (60s timeout)
> > > > > > MMC:   FSL_SDHC: 1, FSL_SDHC: 2
> > > > > > Loading Environment from MMC... OK
> > > > > > In:serial
> > > > > > Out:   serial
> > > > > > Err:   serial
> > > > > > Net:   eth0: ethernet@30be
> > > > > > Hit any key to stop autoboot:  0 u-boot=> mmc dev 1 Run CMD11
> > > > > > 1.8V switch switch to partitions #0, OK
> > > > > > mmc1 is current device
> > > > > > u-boot=> mmc info
> > > > > > Device: FSL_SDHC
> > > > > > Manufacturer ID: 1b
> > > > > > OEM: 534d
> > > > > > Name: 0
> > > > > > Bus Speed: 5000
> > > > > > Mode: SD High Speed (50MHz)
> > > > > > Rd Block Len: 512
> > > > > > SD version 3.0
> > >

RE: IMX8MM SD UHS support

[ZHIZHIKIN Andrey]

Hello Tim,

> -Original Message-
> From: Tim Harvey 
> Sent: Wednesday, December 30, 2020 7:48 PM
> To: Adam Ford 
> Cc: Fabio Estevam ; ZHIZHIKIN Andrey
> ; Peng Fan ; u-
> boot ; Stefano Babic 
> Subject: Re: IMX8MM SD UHS support
> 
> 
> On Wed, Dec 30, 2020 at 10:22 AM Adam Ford  wrote:
> >
> > On Wed, Dec 30, 2020 at 11:50 AM Fabio Estevam 
> wrote:
> > >
> > > Hi Tim,
> > >
> > > On Wed, Dec 30, 2020 at 1:54 PM Tim Harvey 
> wrote:
> > >
> > > > Andrey,
> > > >
> > > > I did mention that I am using the imx8mm-evk. When I saw that my
> > > > custom board was having issues with sd_get_capabilities() I
> > > > switched to the imx8mm-evk and confirmed my findings there.

I've missed the part that you've tested the same behavior on i.MX8M Mini EVK in 
your original message, sorry for that.

> > > >
> > > > I'm using master (ab865a8ee5c1) with imx8mm_evk_defconfig running
> > > > on an imx8mm-evk board configured via dip switches to boot from
> > > > eMMC. I have a SDR104 microSD which detects and operates as such
> > > > in Linux and this is what I see in U-Boot:
> > > >
> > > > U-Boot SPL 2021.01-rc4-00029-gab865a8 (Dec 30 2020 - 08:29:24
> > > > -0800) Normal Boot
> > > > WDT:   Started with servicing (60s timeout)
> > > > Trying to boot from MMC2
> > > >
> > > >
> > > > U-Boot 2021.01-rc4-00029-gab865a8 (Dec 30 2020 - 08:29:24 -0800)
> > > >
> > > > CPU:   Freescale i.MX8MMQ rev1.0 at 1200 MHz
> > > > Reset cause: POR
> > > > Model: FSL i.MX8MM EVK board
> > > > DRAM:  2 GiB
> > > > WDT:   Started with servicing (60s timeout)
> > > > MMC:   FSL_SDHC: 1, FSL_SDHC: 2
> > > > Loading Environment from MMC... OK
> > > > In:serial
> > > > Out:   serial
> > > > Err:   serial
> > > > Net:   eth0: ethernet@30be
> > > > Hit any key to stop autoboot:  0
> > > > u-boot=> mmc dev 1
> > > > Run CMD11 1.8V switch
> > > > switch to partitions #0, OK
> > > > mmc1 is current device
> > > > u-boot=> mmc info
> > > > Device: FSL_SDHC
> > > > Manufacturer ID: 1b
> > > > OEM: 534d
> > > > Name: 0
> > > > Bus Speed: 5000
> > > > Mode: SD High Speed (50MHz)
> > > > Rd Block Len: 512
> > > > SD version 3.0
> > > > High Capacity: Yes
> > > > Capacity: 14.9 GiB
> > > > Bus Width: 4-bit
> > > > Erase Group Size: 512 Bytes
> > > >
> > > > You can see that the 1.8V switch succeeds and the card is
> > > > recognized as high-speed but does not show the SDR104 capability.

Did you actually measured that the signaling voltages are switched to 1v8
on the test point I've mentioned in my mail?

> > >
> > > Could you please test this patch from Adam?
> > > https://patchwork.ozlabs.org/project/uboot/patch/20201230173907.2891555-1-aford...@gmail.com/
> >

If voltages are not actually switched - then probably another patch from Adam
might help: 
http://patchwork.ozlabs.org/project/uboot/patch/20201230141421.2860212-1-aford...@gmail.com/

This is my pure guess, as neither I tested it myself nor I have a fixed 
regulator option enabled in my
build for SPL, but still I see that SD Card I have is switched into SDR104 mode.

> > My patch probably won't do much more than the one from Andrey.  From
> > what I could gather, the generic mmc driver uses those flags to enable
> > the host caps.  My enables the same host caps by checking the
> > structure so the device tree flags are not needed.
> >
> > The UHS and HS200/HS400 config options need to be enabled in Kconfig
> > for them to make a difference.  Part of me wonders if they should be
> > implied-on if USHDC is set, but that's a different issue.
> >
> > If Tim is not seeing the SDR104 negotiated from Andrey's patch, it
> > probably won't change with mine.
> >
> 
> Right, the issue is not the host caps.
> 
> If I enable the calls to mmc_dump_capabilities() I see:
> u-boot=> mmc info
> Device: FSL_SDHC
> Manufacturer ID: 3
> OEM: 5344
> Name: SL16G
> Bus Speed: 5000
> Mode: SD High Speed (50MHz)
> card capabilities: widths [4, 1] modes [MMC legacy, SD High Speed (50MHz), UHS
> SDR12 (25MHz), UHS SDR25 (50MHz)]

I actually don't see that the card reports an SDR104 mode support here, and 
clocks can only be
configu

RE: IMX8MM SD UHS support

[ZHIZHIKIN Andrey]

Hello Tim,

> -Original Message-
> From: Tim Harvey 
> Sent: Wednesday, December 30, 2020 12:22 AM
> To: ZHIZHIKIN Andrey ; Peng Fan
> ; u-boot 
> Cc: Fabio Estevam ; Stefano Babic 
> Subject: IMX8MM SD UHS support
> 
> 
> Greetings,
> 
> In 50b1a69cee0d ("ARM: dts: imx8m: add UHS or HS400/HS400ES
> properties") u-boot dt props were added to enable UHS and HS400 on a couple of
> IMX8MM boards including the imx8mm-evk and in the subsequent patch
> enabled the config items.
> 
> While I see this making a huge difference for eMMC performance in U-Boot I 
> find
> it doesn't do anything for microSD performance.
> 
> The issue appears to be that sd_get_capabilities() is not appropriately 
> detecting
> UHS speeds on cards that appropriately detect as SDR104/DDR50 in Linux:
> 
> u-boot=> mmc info
> Device: FSL_SDHC
> Manufacturer ID: 1b
> OEM: 534d
> Name: 0
> Bus Speed: 5000
> Mode: SD High Speed (50MHz)
> card capabilities: widths [4, 1] modes [MMC legacy, SD High Speed (50MHz)] 
> 
> no SDR104 detected for this card host capabilities: widths [4, 1] modes [MMC
> legacy, MMC High Speed (26MHz), SD High Speed (50MHz), MMC High Speed
> (52MHz), UHS DDR50 (50MHz), UHS SDR104 (208MHz)] Rd Block Len: 512 SD
> version 3.0 High Capacity: Yes
> Capacity: 14.9 GiB
> Bus Width: 4-bit
> Erase Group Size: 512 Bytes
> 
> The same card in Linux shows the following upon insertion and performance 
> tests
> show that it is operating at SDR104 speeds:
> mmc1: new ultra high speed SDR104 SDHC card at address 0001
> 
> I haven't found very good documentation on the SD switch settings to
> understand if something is wrong in the U-Boot implementation of of
> sd_get_capabilities() and I suppose it also could be an issue in 
> sdhci-esdhc-imx.c.

In order to SD Card to operate in High Speed modes, the signaling voltage should
be switched from 3v3 to 1v8. Otherwise, higher clock rates cannot be applied and
card continues to be operating with lower speed modes.

Have you verified that the NVCC_SD2 is switched to 1v8 in your case?

Since you did not indicate which board you're using - it is hard for me to 
suggest
on how measure this voltages. If you're using i.MX8M Mini EVK, then you can
verify this by measuring the voltage at the test point called "NVCC_SD2" located
on the Core Module in the PMIC area.

> 
> Any ideas where to look?
> 
> Anyone see SDR104 cards being detected properly for other platforms?

Yes, in fact I do see that SD Card is recognized for me as UHS SD104:

u-boot=> mmc dev 1
Run CMD11 1.8V switch
switch to partitions #0, OK
mmc1 is current device
u-boot=> mmc info
Device: FSL_SDHC
Manufacturer ID: 9f
OEM: 5449
Name: 0
Bus Speed: 2
Mode: UHS SDR104 (208MHz)
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 29.8 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes

Please pay attention to the output, which says "Run CMD11 1.8V switch".

Do you also observe the same output?

> 
> Best regards,
> 
> Tim

-- andrey

RE: [PATCH 07/13] imx: imx8mn: add i.MX8MN LPDDR4 EVK support

[ZHIZHIKIN Andrey]

Hello Peng,

> -Original Message-
> From: U-Boot  On Behalf Of Peng Fan (OSS)
> Sent: Monday, December 28, 2020 1:17 PM
> To: sba...@denx.de; feste...@gmail.com
> Cc: uboot-...@nxp.com; u-boot@lists.denx.de; Peng Fan 
> Subject: [PATCH 07/13] imx: imx8mn: add i.MX8MN LPDDR4 EVK support
> 
> From: Peng Fan 
> 
> i.MX8MN LPDDR4 EVK reuses most code of i.MX8MN DDR4 EVK code,
> with adding a new ddr script.
> 
> Signed-off-by: Peng Fan 
> ---
>  arch/arm/dts/Makefile |1 +
>  arch/arm/dts/imx8mn-evk-u-boot.dtsi   |6 +
>  arch/arm/dts/imx8mn-evk.dts   |  128 ++
>  arch/arm/mach-imx/imx8m/Kconfig   |6 +
>  .../mach-imx/imx8m/imximage-8mn-lpddr4.cfg|   17 +
>  board/freescale/imx8mn_evk/Kconfig|2 +-
>  board/freescale/imx8mn_evk/Makefile   |1 +
>  board/freescale/imx8mn_evk/lpddr4_timing.c| 1585 +
>  configs/imx8mn_evk_defconfig  |   80 +
>  9 files changed, 1825 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/imx8mn-evk-u-boot.dtsi
>  create mode 100644 arch/arm/dts/imx8mn-evk.dts
>  create mode 100644 arch/arm/mach-imx/imx8m/imximage-8mn-lpddr4.cfg
>  create mode 100644 board/freescale/imx8mn_evk/lpddr4_timing.c
>  create mode 100644 configs/imx8mn_evk_defconfig

Any chance that the documentation for this derivative is added, or a current 
[doc/board/freescale/imx8mn_evk.rst]
is updated to include the information on how to assemble both DDR and LPDDR 
derivatives?

> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index fd47e408f8..eb7fef9257 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -775,6 +775,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
> imx8mm-verdin.dtb \
> phycore-imx8mm.dtb \
> imx8mn-ddr4-evk.dtb \
> +   imx8mn-evk.dtb \
> imx8mq-evk.dtb \
> imx8mm-beacon-kit.dtb \
> imx8mq-phanbell.dtb \
> diff --git a/arch/arm/dts/imx8mn-evk-u-boot.dtsi b/arch/arm/dts/imx8mn-evk-
> u-boot.dtsi
> new file mode 100644
> index 00..617a6603cb
> --- /dev/null
> +++ b/arch/arm/dts/imx8mn-evk-u-boot.dtsi
> @@ -0,0 +1,6 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2020 NXP
> + */
> +
> +#include "imx8mn-ddr4-evk-u-boot.dtsi"
> diff --git a/arch/arm/dts/imx8mn-evk.dts b/arch/arm/dts/imx8mn-evk.dts
> new file mode 100644
> index 00..b4225cfcb6
> --- /dev/null
> +++ b/arch/arm/dts/imx8mn-evk.dts
> @@ -0,0 +1,128 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2019 NXP
> + */
> +
> +/dts-v1/;
> +
> +#include "imx8mn.dtsi"
> +#include "imx8mn-evk.dtsi"
> +#include 
> +
> +/ {
> +   model = "NXP i.MX8MNano EVK board";
> +   compatible = "fsl,imx8mn-evk", "fsl,imx8mn";
> +};
> +
> +_0 {
> +   cpu-supply = <>;
> +};
> +
> +_1 {
> +   cpu-supply = <>;
> +};
> +
> +_2 {
> +   cpu-supply = <>;
> +};
> +
> +_3 {
> +   cpu-supply = <>;
> +};
> +
> + {
> +   pmic: pmic@25 {
> +   compatible = "nxp,pca9450b";
> +   reg = <0x25>;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_pmic>;
> +   interrupt-parent = <>;
> +   interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> +
> +   regulators {
> +   buck1: BUCK1{
> +   regulator-name = "BUCK1";
> +   regulator-min-microvolt = <60>;
> +   regulator-max-microvolt = <2187500>;
> +   regulator-boot-on;
> +   regulator-always-on;
> +   regulator-ramp-delay = <3125>;
> +   };
> +
> +   buck2: BUCK2 {
> +   regulator-name = "BUCK2";
> +   regulator-min-microvolt = <60>;
> +   regulator-max-microvolt = <2187500>;
> +   regulator-boot-on;
> +   regulator-always-on;
> +   regulator-ramp-delay = <3125>;
> +   nxp,dvs-run-voltage = <95>;
> +   nxp,dvs-standby-voltage = <85>;
> +   };
> +
> +   buck4: BUCK4{
> +   regulator-name = "BUCK4";
> +   regulator-min-microvolt = <60>;
> +   regulator-max-microvolt = <340>;
> +   regulator-boot-on;
> +   regulator-always-on;
> +   };
> +
> +   buck5: BUCK5{
> +   regulator-name = "BUCK5";
> +   regulator-min-microvolt = <60>;
> +   regulator-max-microvolt = <340>;
> + 

RE: [PATCH 05/13] imx: imx8mn_evk: correct stack/malloc adress

[ZHIZHIKIN Andrey]

Hello Peng,

> -Original Message-
> From: U-Boot  On Behalf Of Peng Fan (OSS)
> Sent: Monday, December 28, 2020 1:17 PM
> To: sba...@denx.de; feste...@gmail.com
> Cc: uboot-...@nxp.com; u-boot@lists.denx.de; Peng Fan 
> Subject: [PATCH 05/13] imx: imx8mn_evk: correct stack/malloc adress
> 
> From: Peng Fan 
> 
> Move SP to end of OCRAM space. Drop MALLOC_F to make it alloc from
> stack space.
> 
> Signed-off-by: Peng Fan 
> ---
>  drivers/power/power_i2c.c| 8 
>  include/configs/imx8mn_evk.h | 9 +++--
>  2 files changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
> index 5a0455e119..b67ac2f027 100644
> --- a/drivers/power/power_i2c.c
> +++ b/drivers/power/power_i2c.c
> @@ -23,7 +23,7 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
> 
> if (check_reg(p, reg))
> return -EINVAL;
> -#if defined(CONFIG_DM_I2C)
> +#if CONFIG_IS_ENABLED(DM_I2C)
> struct udevice *dev;
> int ret;
> 
> @@ -67,7 +67,7 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
> return -EINVAL;
> }
> 
> -#if defined(CONFIG_DM_I2C)
> +#if CONFIG_IS_ENABLED(DM_I2C)
> return dm_i2c_write(dev, reg, buf, pmic_i2c_tx_num);
>  #else
> return i2c_write(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num);
> @@ -83,7 +83,7 @@ int pmic_reg_read(struct pmic *p, u32 reg, u32 *val)
> if (check_reg(p, reg))
> return -EINVAL;
> 
> -#if defined(CONFIG_DM_I2C)
> +#if CONFIG_IS_ENABLED(DM_I2C)
> struct udevice *dev;
> 
> ret = i2c_get_chip_for_busnum(p->bus, pmic_i2c_addr,
> @@ -131,7 +131,7 @@ int pmic_reg_read(struct pmic *p, u32 reg, u32 *val)
>  int pmic_probe(struct pmic *p)
>  {
> debug("Bus: %d PMIC:%s probed!\n", p->bus, p->name);
> -#if defined(CONFIG_DM_I2C)
> +#if CONFIG_IS_ENABLED(DM_I2C)
> struct udevice *dev;
> int ret;
> 
> diff --git a/include/configs/imx8mn_evk.h b/include/configs/imx8mn_evk.h
> index a6333085fe..61db244e98 100644
> --- a/include/configs/imx8mn_evk.h
> +++ b/include/configs/imx8mn_evk.h
> @@ -20,17 +20,14 @@
> (QSPI0_AMBA_BASE +
> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512)
> 
>  #ifdef CONFIG_SPL_BUILD
> -#define CONFIG_SPL_STACK   0x95fff0
> -#define CONFIG_SPL_BSS_START_ADDR  0x0095
> -#define CONFIG_SPL_BSS_MAX_SIZESZ_8K   /* 8 KB */
> +#define CONFIG_SPL_STACK   0x98
> +#define CONFIG_SPL_BSS_START_ADDR  0x95
> +#define CONFIG_SPL_BSS_MAX_SIZESZ_4K   /* 8 KB */

This does not read right... SZ_4K is 4 KB, while comment says - it's 8 KB.

>  #define CONFIG_SYS_SPL_MALLOC_START0x4220
>  #define CONFIG_SYS_SPL_MALLOC_SIZE SZ_512K /* 512 KB */
>  #define CONFIG_SYS_ICACHE_OFF
>  #define CONFIG_SYS_DCACHE_OFF
> 
> -/* malloc f used before GD_FLG_FULL_MALLOC_INIT set */
> -#define CONFIG_MALLOC_F_ADDR   0x0094
> -
>  /* For RAW image gives a error info not panic */
>  #define CONFIG_SPL_ABORT_ON_RAW_IMAGE
> 
> --
> 2.28.0

-- andrey

RE: [PATCH 01/13] imx: imx8mp_evk: enable eth support

[ZHIZHIKIN Andrey]

Hello Peng,

> -Original Message-
> From: U-Boot  On Behalf Of Peng Fan (OSS)
> Sent: Monday, December 28, 2020 1:17 PM
> To: sba...@denx.de; feste...@gmail.com
> Cc: uboot-...@nxp.com; u-boot@lists.denx.de; Peng Fan 
> Subject: [PATCH 01/13] imx: imx8mp_evk: enable eth support
> 
> 
> From: Peng Fan 
> 
> Add board code to configure the network interface
> Add net defconfig
> 
> Signed-off-by: Peng Fan 
> ---
>  arch/arm/include/asm/arch-imx8m/imx-regs.h |  2 +
>  board/freescale/imx8mp_evk/imx8mp_evk.c| 81 ++
>  configs/imx8mp_evk_defconfig   | 11 +++
>  include/configs/imx8mp_evk.h   | 16 +
>  4 files changed, 110 insertions(+)
> 
> diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h
> b/arch/arm/include/asm/arch-imx8m/imx-regs.h
> index f1c410ec78..f5711155b7 100644
> --- a/arch/arm/include/asm/arch-imx8m/imx-regs.h
> +++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h
> @@ -62,6 +62,8 @@
>  #define DDRC_IPS_BASE_ADDR(X)  (0x3d40 + ((X) * 0x200))
>  #define DDR_CSD1_BASE_ADDR 0x4000
> 
> +#define IOMUXC_GPR_GPR1_GPR_ENET_QOS_INTF_SEL_MASK 0x7
> +
>  #if !defined(__ASSEMBLY__)
>  #include 
>  #include 
> diff --git a/board/freescale/imx8mp_evk/imx8mp_evk.c
> b/board/freescale/imx8mp_evk/imx8mp_evk.c
> index 034a349236..d6b863df84 100644
> --- a/board/freescale/imx8mp_evk/imx8mp_evk.c
> +++ b/board/freescale/imx8mp_evk/imx8mp_evk.c
> @@ -7,9 +7,13 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> 
> @@ -40,8 +44,85 @@ int board_early_init_f(void)
> return 0;
>  }
> 
> +#define FEC_RST_PAD IMX_GPIO_NR(4, 2)
> +static iomux_v3_cfg_t const fec1_rst_pads[] = {
> +   MX8MP_PAD_SAI1_RXD0__GPIO4_IO02 |
> MUX_PAD_CTRL(NO_PAD_CTRL),
> +};
> +
> +static void setup_iomux_fec(void)
> +{
> +   imx_iomux_v3_setup_multiple_pads(fec1_rst_pads,
> +ARRAY_SIZE(fec1_rst_pads));
> +
> +   gpio_request(FEC_RST_PAD, "fec1_rst");
> +   gpio_direction_output(FEC_RST_PAD, 0);
> +   mdelay(15);
> +   gpio_direction_output(FEC_RST_PAD, 1);
> +   mdelay(100);
> +}
> +
> +static int setup_fec(void)
> +{
> +   struct iomuxc_gpr_base_regs *gpr =
> +   (struct iomuxc_gpr_base_regs *)IOMUXC_GPR_BASE_ADDR;
> +
> +   setup_iomux_fec();
> +
> +   /* Enable RGMII TX clk output */
> +   setbits_le32(>gpr[1], BIT(22));
> +
> +   return 0;

There is only one return code here (and it is 0), and it is not checked 
anywhere below.

Can this function be made "static void setup_fec(void)"?

Besides, return code is not checked in board_init below...

> +}
> +
> +#define EQOS_RST_PAD IMX_GPIO_NR(4, 22)
> +static iomux_v3_cfg_t const eqos_rst_pads[] = {
> +   MX8MP_PAD_SAI2_RXC__GPIO4_IO22 | MUX_PAD_CTRL(NO_PAD_CTRL),
> +};
> +
> +static void setup_iomux_eqos(void)
> +{
> +   imx_iomux_v3_setup_multiple_pads(eqos_rst_pads,
> +ARRAY_SIZE(eqos_rst_pads));
> +
> +   gpio_request(EQOS_RST_PAD, "eqos_rst");
> +   gpio_direction_output(EQOS_RST_PAD, 0);
> +   mdelay(15);
> +   gpio_direction_output(EQOS_RST_PAD, 1);
> +   mdelay(100);
> +}
> +
> +static int setup_eqos(void)
> +{
> +   struct iomuxc_gpr_base_regs *gpr =
> +   (struct iomuxc_gpr_base_regs *)IOMUXC_GPR_BASE_ADDR;
> +
> +   setup_iomux_eqos();
> +
> +   /* set INTF as RGMII, enable RGMII TXC clock */
> +   clrsetbits_le32(>gpr[1],
> +   IOMUXC_GPR_GPR1_GPR_ENET_QOS_INTF_SEL_MASK, BIT(16));
> +   setbits_le32(>gpr[1], BIT(19) | BIT(21));
> +
> +   return set_clk_eqos(ENET_125MHZ);
> +}

Function does return a value, but return code is never checked in board_init 
below.

Perhaps, either make it as void, or check the return code?

> +
> +#if CONFIG_IS_ENABLED(NET)
> +int board_phy_config(struct phy_device *phydev)
> +{
> +   if (phydev->drv->config)
> +   phydev->drv->config(phydev);
> +   return 0;
> +}
> +#endif
> +
>  int board_init(void)
>  {
> +   if (CONFIG_IS_ENABLED(FEC_MXC))
> +   setup_fec();
> +
> +   if (CONFIG_IS_ENABLED(DWC_ETH_QOS))
> +   setup_eqos();
> +

Does it make sense to setup ETH QOS if FEC is not enabled?

> return 0;
>  }
> 
> diff --git a/configs/imx8mp_evk_defconfig b/configs/imx8mp_evk_defconfig
> index cd5724e811..de9db697e8 100644
> --- a/configs/imx8mp_evk_defconfig
> +++ b/configs/imx8mp_evk_defconfig
> @@ -73,6 +73,14 @@ CONFIG_MMC_IO_VOLTAGE=y
>  CONFIG_FSL_ESDHC_IMX=y
>  CONFIG_PHYLIB=y
>  CONFIG_DM_ETH=y
> +CONFIG_DWC_ETH_QOS=y
> +

Are those blanks needed in defconfig (here and one below)? 

> +CONFIG_PHY_GIGE=y
> +CONFIG_FEC_MXC=y
> +CONFIG_MII=y
> +CONFIG_PHYLIB=y
> +CONFIG_PHY_REALTEK=y
> +
>  CONFIG_PINCTRL=y
>  CONFIG_SPL_PINCTRL=y
>  CONFIG_PINCTRL_IMX8M=y
> @@ -85,3 +93,6 @@ 

RE: [PATCH] imx8mp_evk: Increase CONFIG_SYS_MALLOC_F_LEN

[ZHIZHIKIN Andrey]

Hello Fabio,

> -Original Message-
> From: Fabio Estevam 
> Sent: Monday, December 21, 2020 7:41 PM
> To: sba...@denx.de
> Cc: peng@nxp.com; u-boot@lists.denx.de; ZHIZHIKIN Andrey
> ; uboot-...@nxp.com; Fabio Estevam
> 
> Subject: [PATCH] imx8mp_evk: Increase CONFIG_SYS_MALLOC_F_LEN
> 
> 
> When booting imx8mp-evk the following allocation error message is seen:
> 
> U-Boot 2021.01-rc3-00200-ge668bec96a5f (Dec 21 2020 - 14:36:42 -0300)
> 
> alloc space exhausted
> 
> Fix it by increasing CONFIG_SYS_MALLOC_F_LEN to 0x1 like it is done on
> other i.MX8MM/8MN boards.

It would be really great to get a review from Peng here, as his commit 
28fff3fa1c
("imx: imx8mp_evk: fix boot issue") changed exactly this option from 0x1 to 
0x8000.

I've tested my local build with your patch and it boots OK, hence I cannot seem 
to find a
reasoning why the early malloc area size has been halved with above commit.

> 
> Reported-by: Andrey Zhizhikin 
> Signed-off-by: Fabio Estevam 
> ---
>  configs/imx8mp_evk_defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configs/imx8mp_evk_defconfig b/configs/imx8mp_evk_defconfig
> index cd5724e811ab..c34a10c2d906 100644
> --- a/configs/imx8mp_evk_defconfig
> +++ b/configs/imx8mp_evk_defconfig
> @@ -4,7 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x4020
> CONFIG_SPL_GPIO_SUPPORT=y  CONFIG_SPL_LIBCOMMON_SUPPORT=y
> CONFIG_SPL_LIBGENERIC_SUPPORT=y
> -CONFIG_SYS_MALLOC_F_LEN=0x8000
> +CONFIG_SYS_MALLOC_F_LEN=0x1
>  CONFIG_ENV_SIZE=0x1000
>  CONFIG_ENV_OFFSET=0x40
>  CONFIG_SYS_I2C_MXC_I2C1=y
> --
> 2.17.1

Tested-by: Andrey Zhizhikin 

RE: [PATCH] doc: board: freescale: advise to use newer atf and firmware

[ZHIZHIKIN Andrey]

Hello Tom,

> -Original Message-
> From: Tom Rini 
> Sent: Monday, December 21, 2020 10:41 PM
> To: Fabio Estevam ; Stefano Babic 
> Cc: ZHIZHIKIN Andrey ; U-Boot-Denx
> ; Peng Fan 
> Subject: Re: [PATCH] doc: board: freescale: advise to use newer atf and 
> firmware
> 
> On Mon, Dec 21, 2020 at 06:31:08PM -0300, Fabio Estevam wrote:
> > Hi Andrey,
> >
> > On Sun, Dec 13, 2020 at 5:36 PM Andrey Zhizhikin
> >  wrote:
> > >
> > > Update branch and version information of ATF and DDR firmware files
> > > to point to latest releases provided by NXP.
> > >
> > > This is especially critical for imx8mp evk, as the ATF support for
> > > that SoC is only available in latest releases.
> > >
> > > Align all SoCs from imx8m family to use identical revisions of ATF
> > > and DDR firmware.
> > >
> > > Signed-off-by: Andrey Zhizhikin
> > > 
> >
> > Reviewed-by: Fabio Estevam 
> 
> Is this something that should get pulled in for v2021.01?  It kinda sounds 
> like yes.
> Should I take this directly if so?

I'd suggest this docs update to be taken, as the combination of ATF and DDR 
firmware
recorded there is known to be working for those i.MX8M derivatives.

I've also realized that there is a newer version of ATF available from NXP on 
codeaurora,
but according to the last mail from Fabio - it is not bootable, and I haven't 
tried it
myself yet.

I guess for the upcoming 2021.01 this documentation update would be quite 
helpful,
as there has been few reports on the list that people tried to use outdated 
instructions
and were not able to produce a boot container for i.MX8M Nano and Plus SOCs due 
to
a newer version of ATF was required.

> 
> --
> Tom

-- andrey

RE: imx8mp_evk: boot error "alloc space exhausted"

[ZHIZHIKIN Andrey]

Hello Peng,

Just a gentle ping here: can you take a look at the failure reported below?

I've also added Alice Guo since there was some work done om imx8mp_evk board,
and uboot-imx list here.

Thanks a lot!

> -Original Message-
> From: ZHIZHIKIN Andrey
> Sent: Tuesday, December 8, 2020 2:40 PM
> To: Peng Fan 
> Cc: U-Boot Mailing List ; feste...@gmail.com; Stefano
> Babic 
> Subject: imx8mp_evk: boot error "alloc space exhausted"
> 
> Hello Peng,
> 
> I've tried to boot the i.MX8M Plus EVK with U-Boot 2020.10 and faced the error
> message during the boot process, which indicates that the allocation space in
> early malloc area is exhausted.
> 
> Looking at the log, I was able to bisect it to the commit 28fff3fa1c ("imx:
> imx8mp_evk: fix boot issue"), where the CONFIG_SYS_MALLOC_F_LEN has been
> reduced from 0x1 to 0x8000 and CONFIG_SPL_SYS_MALLOC_SIMPLE was
> enabled.
> 
> Extract from the patch shows the following diff:
> -CONFIG_SYS_MALLOC_F_LEN=0x1
> +CONFIG_SYS_MALLOC_F_LEN=0x8000
> +CONFIG_SPL_SYS_MALLOC_SIMPLE=y
> 
> 
> If the CONFIG_SYS_MALLOC_F_LEN is returned to the original value - error
> message disappears, and I can observe that the total occupation of early 
> malloc
> area (reported via bdinfo) contains following count:
> -
> u-boot=> bdinfo
> 
> Early malloc usage: a648 / 1
> -
> 
> As it can be seen, the value 0xa648 overflows the imposed limit of 0x8000,
> causing 2 allocations after ATF execution to fail.
> 
> According to the Patchwork [1], this has been already reported by Fabio but
> there was no resolution provided to address this further. Neither the commit
> message in 28fff3fa1c provides any additional hint on why those config options
> were setup with those values.
> 
> V1 of this patch series did not have any config options in it, and the 
> changelog of
> v2 is also missing to advise why those options were added to the series.
> 
> Can you please explain why CONFIG_SYS_MALLOC_F_LEN and
> CONFIG_SPL_SYS_MALLOC_SIMPLE config options were added with that patch,
> and if it is safe to have them reverted to the original values?
> 
> Another
> 
> 
> Thanks a lot!
> 
> Regards,
> Andrey
> 
> 
> Link: [1]:
> http://patchwork.ozlabs.org/project/uboot/patch/20200512093901.14831-2-
> peng@nxp.com/

-- Andrey

RE: [PATCH v1 1/2] imx8mp: configs: add support for distro boot commands

[ZHIZHIKIN Andrey]

Hello Alice,

> -Original Message-
> From: U-Boot  On Behalf Of Alice Guo (OSS)
> Sent: Thursday, December 17, 2020 11:29 AM
> To: sba...@denx.de; feste...@gmail.com; peng@nxp.com
> Cc: uboot-...@nxp.com; ye...@nxp.com; u-boot@lists.denx.de; Alice Guo
> 
> Subject: [PATCH v1 1/2] imx8mp: configs: add support for distro boot commands
> 
> From: Alice Guo 
> 
> Supported boot device types in iMX8MP: MMC.
> 
> CONFIG_CMD_PART is added for command part and CONFIG_CMD_FS_GENERIC
> is for command fstype.
> 
> scriptaddr is the location in RAM where boot.scr.uimg/boot.scr will be loaded 
> to
> prior to execution. kernel_addr_r is the location in RAM where the kernel 
> will be
> loaded to. Delete unnecessary environment variables because "run
> distro_bootcmd" is set to be the default boot mode.
> 
> On the iMX8MP platform I used, "mmc1" represents SD card and "mmc2"
> represents eMMC.
> 
> Signed-off-by: Alice Guo 
> ---
>  configs/imx8mp_evk_defconfig |  2 ++
>  include/configs/imx8mp_evk.h | 66 ++--
>  2 files changed, 13 insertions(+), 55 deletions(-)
> 
> diff --git a/configs/imx8mp_evk_defconfig b/configs/imx8mp_evk_defconfig
> index cd5724e811..7831a940a3 100644
> --- a/configs/imx8mp_evk_defconfig
> +++ b/configs/imx8mp_evk_defconfig
> @@ -51,6 +51,8 @@ CONFIG_CMD_EXT2=y
>  CONFIG_CMD_EXT4=y
>  CONFIG_CMD_EXT4_WRITE=y
>  CONFIG_CMD_FAT=y
> +CONFIG_CMD_PART=y
> +CONFIG_CMD_FS_GENERIC=y
>  CONFIG_OF_CONTROL=y
>  CONFIG_SPL_OF_CONTROL=y
>  CONFIG_ENV_OVERWRITE=y
> diff --git a/include/configs/imx8mp_evk.h b/include/configs/imx8mp_evk.h
> index 8253c6aa2f..70f5fb2928 100644
> --- a/include/configs/imx8mp_evk.h
> +++ b/include/configs/imx8mp_evk.h
> @@ -44,69 +44,25 @@
> 
>  #endif
> 
> +#ifndef CONFIG_SPL_BUILD
> +#define BOOT_TARGET_DEVICES(func) \
> +   func(MMC, mmc, 1) \
> +   func(MMC, mmc, 2)
> +
> +#include 
> +#endif
> +
>  /* Initial environment variables */
>  #define CONFIG_EXTRA_ENV_SETTINGS  \
> -   "script=boot.scr\0" \
> +   BOOTENV \
> +   "scriptaddr=0x4350\0" \
> +   "kernel_addr_r=0x4088\0" \
> "image=Image\0" \
> "console=ttymxc1,115200 earlycon=ec_imx6q,0x3089,115200\0" \
> "fdt_addr=0x4300\0" \
> -   "boot_fdt=try\0" \
> "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
> -   "initrd_addr=0x4380\0"  \
> -   "bootm_size=0x1000\0" \

I believe that without proper bootm_size set, FIT image cannot be loaded 
correctly.

Commit acbc1d86f1 ("imx8m: config: convert to bootm_size") had this addressed, 
and removing
the "bootm_size" would break FIT load again.

Have you tested your implementation with "bootm" in boot script? So far, I see 
that only
"booti" has been used.

> -   "mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \
> "mmcpart=" __stringify(CONFIG_SYS_MMC_IMG_LOAD_PART) "\0" \
> "mmcroot=" CONFIG_MMCROOT " rootwait rw\0" \
> -   "mmcautodetect=yes\0" \
> -   "mmcargs=setenv bootargs ${jh_clk} console=${console} 
> root=${mmcroot}\0
> " \
> -   "loadbootscript=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr}
> ${script};\0" \
> -   "bootscript=echo Running bootscript from mmc ...; " \
> -   "source\0" \
> -   "loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
> -   "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
> -   "mmcboot=echo Booting from mmc ...; " \
> -   "run mmcargs; " \
> -   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
> -   "if run loadfdt; then " \
> -   "booti ${loadaddr} - ${fdt_addr}; " \
> -   "else " \
> -   "echo WARN: Cannot load the DT; " \
> -   "fi; " \
> -   "else " \
> -   "echo wait for boot; " \
> -   "fi;\0" \
> -   "netargs=setenv bootargs ${jh_clk} console=${console} " \
> -   "root=/dev/nfs " \
> -   "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
> -   "netboot=echo Booting from net ...; " \
> -   "run netargs;  " \
> -   "if test ${ip_dyn} = yes; then " \
> -   "setenv get_cmd dhcp; " \
> -   "else " \
> -   "setenv get_cmd tftp; " \
> -   "fi; " \
> -   "${get_cmd} ${loadaddr} ${image}; " \
> -   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
> -   "if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \
> -   "booti ${loadaddr} - ${fdt_addr}; " \
> -   "else " \
> -   "echo WARN: Cannot load the DT; " \
> -   "fi; " \
> -   "else " \
> -   "booti; " \
> -   "fi;\0"
> -
> 

RE: [PATCH] imx: Add support for i.MX8MN Beacon EmbeddedWorks devkit.

[ZHIZHIKIN Andrey]

Hello Adam,

> -Original Message-
> From: U-Boot  On Behalf Of Adam Ford
> Sent: Thursday, December 10, 2020 5:08 PM
> To: u-boot@lists.denx.de
> Cc: af...@beaconembedded.com; Adam Ford ; Stefano
> Babic ; Fabio Estevam ; NXP i.MX U-
> Boot Team 
> Subject: [PATCH] imx: Add support for i.MX8MN Beacon EmbeddedWorks devkit.
> 
> 
> Beacon EmbeddedWorks is releasing a devkit based on the i.MX8M
> Nano SoC consisting of baseboard + SOM.
> 
> The kit is based on the same design as the Beacon dev kit with
> the i.MX8M Mini.
> 
> Signed-off-by: Adam Ford 
> 



> diff --git a/board/beacon/imx8mn/README b/board/beacon/imx8mn/README
> new file mode 100644
> index 00..b1d7a19a39
> --- /dev/null
> +++ b/board/beacon/imx8mn/README
> @@ -0,0 +1,39 @@
> +U-Boot for the Beacon EmbeddedWorks i.MX8M Nano Devkit
> +
> +Quick Start
> +===
> +- Build the ARM Trusted firmware binary
> +- Get ddr firmware
> +- Build U-Boot
> +- Boot
> +
> +Get and Build the ARM Trusted firmware
> +==
> +Note: $(srctree) is U-Boot source directory
> +
> +$ git clone https://source.codeaurora.org/external/imx/imx-atf
> +$ git checkout imx_5.4.47_2.2.0
> +$ make PLAT=imx8mn bl31 CROSS_COMPILE=aarch64-linux-gnu-
> +$ cp build/imx8mm/release/bl31.bin $(srctree)
> +
> +Get the DDR firmware
> +
> +$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.5.bin

There is a newer version of DDR firmware available from NXP:
https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.9.bin

It is also aligned with imx_5.4.47_2.2.0 ATF release, so for completeness 
purposes
I would recommend you to include the updated link into README file.

Yocto meta-freescale layer is already using this firmware version for mx8m 
series [1],
and it is operable.

I believe it would be beneficial to recommend users to pull the latest version 
available.

> +$ chmod +x firmware-imx-8.5.bin
> +$ ./firmware-imx-8.5
> +$ cp firmware-imx-8.5/firmware/ddr/synopsys/lpddr4*.bin $(srctree)
> +
> +Build U-Boot
> +
> +$ make imx8mn_beacon_defconfig
> +$ make flash.bin CROSS_COMPILE=aarch64-linux-gnu-
> ATF_LOAD_ADDR=0x96
> +
> +Burn U-Boot to microSD Card
> +===
> +$ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32
> +
> +Boot
> +
> +Set baseboard DIP switch:
> +S17: 1100
> +



> 2.25.1

Link: [1]: 
https://github.com/Freescale/meta-freescale/blob/master/recipes-bsp/firmware-imx/firmware-imx-8m_8.9.bb

-- andrey

RE: Boot problems imx8mp_evk

[ZHIZHIKIN Andrey]

Hello Adam/Peter,

> -Original Message-
> From: U-Boot  On Behalf Of Adam Ford
> Sent: Tuesday, December 8, 2020 2:48 PM
> To: Peter Bergin 
> Cc: U-Boot Mailing List ; NXP Linux Team  i...@nxp.com>
> Subject: Re: Boot problems imx8mp_evk
> 
> This email is not from Hexagon’s Office 365 instance. Please be careful while
> clicking links, opening attachments, or replying to this email.
> 
> 
> On Wed, Sep 30, 2020 at 6:06 AM Peter Bergin  wrote:
> >
> > Hi,
> >
> > I'm following the README
> > to bring up u-boot on a imx8mp EVK board. My
> > boot ends up in this on the
> > console:
> >
> >  U-Boot SPL 2020.10-rc5-00049-gd44d46e9fa (Sep 30 2020 - 11:46:20 +0200)
> >  Normal Boot
> >  WDT:   Started with servicing (60s timeout)
> >  Trying to boot from BOOTROM
> >  image offset 0x8000, pagesize 0x200, ivt offset 0x0
> >  Can't support legacy image
> >  SPL: failed to boot from all boot devices
> >  ### ERROR ### Please RESET the board ###
> >
> > Any ideas what is going wrong? How to debug further?
> >
> 
> I am trying to port U-Boot to an i.MX8M Nano and I am getting the same result.

This might not be related, but looking at the ATF branch [imx_5.4.3_2.0.0] - it 
appears to be too old, at least for i.MX8M Plus. I was able to run the U-Boot 
2020.10 with ATF built from [imx_5.4.47_2.2.0] on the i.MX8M Plus and it does 
boot successful.

Boot log show the following banner when BOOTROM finishes up the copy:
NOTICE:  BL31: v2.2(release):rel_imx_5.4.47_2.2.0-0-gc949a888e-dirty
NOTICE:  BL31: Built : 05:51:50, Sep  9 2020

Peter,
i.MX8M Plus support in NXP ATF fork appears to be added by commit 
https://source.codeaurora.org/external/imx/imx-atf/commit/?id=6b8249ff58cc8853396498a074535dcd7f81beaf,
 and that came in ATF revision far newer than indicated in 
doc/board/freescale/imx8mp_evk.rst

Try to rebase your ATF to [c949a888e909811db191500c51456391dff61284] and build 
according to the board doc file.

> 
> > Thanks,
> > /Peter
> >

-- Andrey

imx8mp_evk: boot error "alloc space exhausted"

[ZHIZHIKIN Andrey]

Hello Peng,

I've tried to boot the i.MX8M Plus EVK with U-Boot 2020.10 and faced the
error message during the boot process, which indicates that the allocation
space in early malloc area is exhausted.

Looking at the log, I was able to bisect it to the commit 28fff3fa1c ("imx:
imx8mp_evk: fix boot issue"), where the CONFIG_SYS_MALLOC_F_LEN has been
reduced from 0x1 to 0x8000 and CONFIG_SPL_SYS_MALLOC_SIMPLE was enabled.

Extract from the patch shows the following diff:
-CONFIG_SYS_MALLOC_F_LEN=0x1
+CONFIG_SYS_MALLOC_F_LEN=0x8000
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y


If the CONFIG_SYS_MALLOC_F_LEN is returned to the original value - error
message disappears, and I can observe that the total occupation of early malloc
area (reported via bdinfo) contains following count:
-
u-boot=> bdinfo

Early malloc usage: a648 / 1
-

As it can be seen, the value 0xa648 overflows the imposed limit of 0x8000,
causing 2 allocations after ATF execution to fail.

According to the Patchwork [1], this has been already reported by Fabio but
there was no resolution provided to address this further. Neither the commit
message in 28fff3fa1c provides any additional hint on why those config options
were setup with those values.

V1 of this patch series did not have any config options in it, and the
changelog of v2 is also missing to advise why those options were added to the
series.

Can you please explain why CONFIG_SYS_MALLOC_F_LEN and 
CONFIG_SPL_SYS_MALLOC_SIMPLE
config options were added with that patch, and if it is safe to have them
reverted to the original values?

Another 


Thanks a lot!

Regards,
Andrey


Link: [1]: 
http://patchwork.ozlabs.org/project/uboot/patch/20200512093901.14831-2-peng@nxp.com/

RE: [PATCH 2/2] ARM: dts: imx8m: add UHS or HS400/HS400ES properties

[ZHIZHIKIN Andrey]

Hello Adam,

> -Original Message-
> From: U-Boot  On Behalf Of ZHIZHIKIN Andrey
> Sent: Saturday, December 5, 2020 4:09 PM
> To: Adam Ford 
> Cc: U-Boot Mailing List ; Stefano Babic
> ; Ye Li 
> Subject: RE: [PATCH 2/2] ARM: dts: imx8m: add UHS or HS400/HS400ES properties
> 
> Hello Adam,
> 
> > -Original Message-
> > From: Adam Ford 
> > Sent: Saturday, December 5, 2020 3:31 PM
> > To: ZHIZHIKIN Andrey 
> > Cc: U-Boot Mailing List ; Stefano Babic
> > ; Ye Li 
> > Subject: Re: [PATCH 2/2] ARM: dts: imx8m: add UHS or HS400/HS400ES
> > properties
> >
> >
> > On Sat, Dec 5, 2020 at 8:21 AM ZHIZHIKIN Andrey
> >  wrote:
> > >
> > > Hello Adam,
> > >
> > > > -Original Message-
> > > > From: Adam Ford 
> > > > Sent: Saturday, December 5, 2020 1:43 AM
> > > > To: ZHIZHIKIN Andrey 
> > > > Cc: U-Boot Mailing List ; Stefano Babic
> > > > ; Ye Li 
> > > > Subject: Re: [PATCH 2/2] ARM: dts: imx8m: add UHS or HS400/HS400ES
> > > > properties
> > > >
> > > > On Tue, Dec 1, 2020 at 7:32 AM Andrey Zhizhikin
> > > >  wrote:
> > > > >
> > > > > i.MX8M series provide support for high speed grades in their
> > > > > usdhc controllers, which has eMMC and SDHC connected to them.
> > > > >
> > > > > Enable this support across the entire i.MX8M family by providing
> > > > > quirks to usdhc controllers designated by storage media connected to
> them.
> > > > >
> > > > > Signed-off-by: Andrey Zhizhikin
> > > > > 
> > > > > Cc: Stefano Babic 
> > > > > Cc: Ye Li 
> > > > > ---
> > > > >  arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi  | 3 +++
> > > > > arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi | 3 +++
> > > > >  arch/arm/dts/imx8mm-evk-u-boot.dtsi  | 4 
> > > > >  arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi | 4 
> > > > >  arch/arm/dts/imx8mp-evk-u-boot.dtsi  | 4 
> > > > >  arch/arm/dts/imx8mq-evk.dts  | 3 +++
> > > > >  6 files changed, 21 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> > > > > b/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> > > > > index 80d6475b7c..2f86fcce3e 100644
> > > > > --- a/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> > > > > +++ b/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> > > > > @@ -118,8 +118,11 @@
> > > > >
> > > > >   {
> > > > > u-boot,dm-spl;
> > > > > +   u-boot,mmc-hs400-1_8v;
> > > > >  };
> > > > >
> > > >
> > > > I don't think the "u-boot," prefix is needed.  Looking at other
> > > > boards' device trees, they don't seem to have this.
> > >
> > > Correct, I've already realized that and currently working on V3 of the 
> > > series:
> > > 
> > >
> >
> > Awesome!
> >
> > > Thanks a lot for testing it though!
> > >
> > > > I tried it on the beacon imx8mm-beacon-kit, and it didn't work
> > > > until I removed the "u-boot,"
> > >
> > > I believe you had it tested with your patches on top, since it would
> > > also require additional config options to be set, which you
> > > introduced for
> > imx8mm-beacon-kit.
> > >
> > I wouldn't have even thought about it until I saw your patch, so
> > thanks for bringing it to my attention.  :-)
> >
> > > As I see it now - those changes might be useful and applicable to
> > > all
> > > imx8m* derivatives and I'm thinking to move those binding to base
> > > dtsi files
> > then.
> > >
> > > Would there be any objections here?
> >
> > None from me.
> 
> Great!
> 
> >
> > If I understand correctly, we could add a imx8mm-u-boot-dtsi with
> > these U-Boot additions, and all imx8mm boards would include them
> > instead of modifying each board's u-boot-dtsi.
> 
> I would make this change in the V3 then.

This unfortunately would not work, since build system does not automatically
pick up '-uboot.dtsi' if it does not match to the entry in Makefile. Only those
DTS file names, which are explicitly present in the Makefile are searched for
corresponding '-u-boot.dtsi' to be auto-included.

I would have to abandon this i

RE: [PATCH] imx8mm_beacon: Enable HS400 on MMC controller

[ZHIZHIKIN Andrey]

> -Original Message-
> From: Adam Ford 
> Sent: Saturday, December 5, 2020 4:01 PM
> To: ZHIZHIKIN Andrey 
> Cc: u-boot@lists.denx.de; af...@beaconembedded.com
> Subject: Re: [PATCH] imx8mm_beacon: Enable HS400 on MMC controller
> 
> On Sat, Dec 5, 2020 at 8:54 AM ZHIZHIKIN Andrey  geosystems.com> wrote:
> >
> > Hello Adam,
> >
> > > -Original Message-
> > > From: U-Boot  On Behalf Of Adam Ford
> > > Sent: Saturday, December 5, 2020 2:00 AM
> > > To: u-boot@lists.denx.de
> > > Cc: af...@beaconembedded.com; Adam Ford 
> > > Subject: [PATCH] imx8mm_beacon: Enable HS400 on MMC controller
> > >
> > >
> > > The i.MX8MM is capable of HS400.  Enable it in both U-Boot and SPL
> > > for faster throughput.
> >
> > I'm not quite sure if those high-speed modes would be required to be
> > enabled for SPL...
> There are separate SPL flags, so we could leave them off.
> 
> >
> > Even though the support for those modes is provided in SPL build,
> > there might be a little benefit of having it enabled as the only thing
> > SPL would need to fetch from storage medias would be U-Boot itself,
> > and the difference in access time between high speed modes enabled or
> > disabled for this task is quite negligible. The downside there would rather 
> > be an
> increase in SPL size to accommodate enabled code paths.
> >
> > I was contemplating myself to have those included, but decided to
> > op-out from it as I could not justify the benefit of it.
> >
> > Do you see any particular use-case where it would be beneficial to
> > enable those modes in SPL? If so - can you please share them, as if it
> > would turn out to be beneficial - I might also turn them on in EVK configs.
> 
> I turned them on because I could and it fit into SPL.  In theory the impy 
> could be
> deactivated for people who don't have the room.  I didn't do any time
> measurements so I don't know of the higher speed made it load u-boot any
> faster since it takes a little more time to do the extra initialization, I 
> can see the
> argument to leave them off.

OK, got it! Since you've introduced it for a specific derivative and you know 
that
from the size perspective it fits - then I believe it is OK to have them 
enabled. 

> 
> Maybe it's best to default the configs to leave them off in SPL, and let 
> people
> decide on what's best for their boards.  For the Beacon board, I'll probably 
> leave it
> on, but if SPL size constraints become an issue, I might turn them off later.

For EVK configs I would leave SPL configs OFF.

> 
> adam
> >
> > >
> > > Signed-off-by: Adam Ford 
> > >
> > > diff --git a/configs/imx8mm_beacon_defconfig
> > > b/configs/imx8mm_beacon_defconfig index c5d331f617..49d5453078
> > > 100644
> > > --- a/configs/imx8mm_beacon_defconfig
> > > +++ b/configs/imx8mm_beacon_defconfig
> > > @@ -70,6 +70,13 @@ CONFIG_DM_I2C=y
> > >  CONFIG_SYS_I2C_MXC=y
> > >  CONFIG_DM_MMC=y
> > >  CONFIG_SUPPORT_EMMC_BOOT=y
> > > +CONFIG_MMC_IO_VOLTAGE=y
> > > +CONFIG_SPL_MMC_IO_VOLTAGE=y
> > > +CONFIG_MMC_UHS_SUPPORT=y
> > > +CONFIG_SPL_MMC_UHS_SUPPORT=y
> > > +CONFIG_MMC_HS400_ES_SUPPORT=y
> > > +CONFIG_MMC_HS400_SUPPORT=y
> > > +CONFIG_SPL_MMC_HS400_SUPPORT=y
> > >  CONFIG_FSL_USDHC=y
> > >  CONFIG_PHYLIB=y
> > >  CONFIG_PHY_ATHEROS=y
> > > --
> > > 2.25.1
> >
> > -- andrey

-- andrey

RE: [PATCH 2/2] ARM: dts: imx8m: add UHS or HS400/HS400ES properties

[ZHIZHIKIN Andrey]

Hello Adam,

> -Original Message-
> From: Adam Ford 
> Sent: Saturday, December 5, 2020 3:31 PM
> To: ZHIZHIKIN Andrey 
> Cc: U-Boot Mailing List ; Stefano Babic
> ; Ye Li 
> Subject: Re: [PATCH 2/2] ARM: dts: imx8m: add UHS or HS400/HS400ES properties
> 
> 
> On Sat, Dec 5, 2020 at 8:21 AM ZHIZHIKIN Andrey  geosystems.com> wrote:
> >
> > Hello Adam,
> >
> > > -Original Message-
> > > From: Adam Ford 
> > > Sent: Saturday, December 5, 2020 1:43 AM
> > > To: ZHIZHIKIN Andrey 
> > > Cc: U-Boot Mailing List ; Stefano Babic
> > > ; Ye Li 
> > > Subject: Re: [PATCH 2/2] ARM: dts: imx8m: add UHS or HS400/HS400ES
> > > properties
> > >
> > > On Tue, Dec 1, 2020 at 7:32 AM Andrey Zhizhikin
> > >  wrote:
> > > >
> > > > i.MX8M series provide support for high speed grades in their usdhc
> > > > controllers, which has eMMC and SDHC connected to them.
> > > >
> > > > Enable this support across the entire i.MX8M family by providing
> > > > quirks to usdhc controllers designated by storage media connected to 
> > > > them.
> > > >
> > > > Signed-off-by: Andrey Zhizhikin
> > > > 
> > > > Cc: Stefano Babic 
> > > > Cc: Ye Li 
> > > > ---
> > > >  arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi  | 3 +++
> > > > arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi | 3 +++
> > > >  arch/arm/dts/imx8mm-evk-u-boot.dtsi  | 4 
> > > >  arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi | 4 
> > > >  arch/arm/dts/imx8mp-evk-u-boot.dtsi  | 4 
> > > >  arch/arm/dts/imx8mq-evk.dts  | 3 +++
> > > >  6 files changed, 21 insertions(+)
> > > >
> > > > diff --git a/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> > > > b/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> > > > index 80d6475b7c..2f86fcce3e 100644
> > > > --- a/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> > > > +++ b/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> > > > @@ -118,8 +118,11 @@
> > > >
> > > >   {
> > > > u-boot,dm-spl;
> > > > +   u-boot,mmc-hs400-1_8v;
> > > >  };
> > > >
> > >
> > > I don't think the "u-boot," prefix is needed.  Looking at other
> > > boards' device trees, they don't seem to have this.
> >
> > Correct, I've already realized that and currently working on V3 of the 
> > series:
> > https://lists.denx.de/pipermail/u-boot/2020-December/434159.html
> >
> 
> Awesome!
> 
> > Thanks a lot for testing it though!
> >
> > > I tried it on the beacon imx8mm-beacon-kit, and it didn't work until
> > > I removed the "u-boot,"
> >
> > I believe you had it tested with your patches on top, since it would
> > also require additional config options to be set, which you introduced for
> imx8mm-beacon-kit.
> >
> I wouldn't have even thought about it until I saw your patch, so thanks for
> bringing it to my attention.  :-)
> 
> > As I see it now - those changes might be useful and applicable to all
> > imx8m* derivatives and I'm thinking to move those binding to base dtsi files
> then.
> >
> > Would there be any objections here?
> 
> None from me.

Great!

> 
> If I understand correctly, we could add a imx8mm-u-boot-dtsi with these U-Boot
> additions, and all imx8mm boards would include them instead of modifying each
> board's u-boot-dtsi.

I would make this change in the V3 then.

> 
> My only concern there is whether or not enabling hs400, hs200 or
> sdh104 on boards that don't have devices compatible with such flags.
> I would expect them to autonegotiate, but I have no way to test it.

According to the specification, the speed mode should be auto-negotiated
so it should be safe to include those binding across.

> 
> In theory, we could also make those Kconfig options 'imply' HS400, HS200, etc.
> automatically in the Kconfig which would eliminate the need to modify each
> defconfig file.  Implying that option would allow users to remove them in 
> their
> respective defconfig files if they don't want the feature.

Looking at the way how high speed modes are enabled in U-Boot, it does require
that both config options and DT bindings are to be turned on, with bindings
providing a fine-grained control over which modes are supported.

I might look into this part further on, but would rather leave it outside of 
this series.

> 
> adam
> 
> >
> > >
> > > With tha

RE: [PATCH] imx8mm_beacon: Enable HS400 on MMC controller

[ZHIZHIKIN Andrey]

Hello Adam,

> -Original Message-
> From: U-Boot  On Behalf Of Adam Ford
> Sent: Saturday, December 5, 2020 2:00 AM
> To: u-boot@lists.denx.de
> Cc: af...@beaconembedded.com; Adam Ford 
> Subject: [PATCH] imx8mm_beacon: Enable HS400 on MMC controller
> 
> 
> The i.MX8MM is capable of HS400.  Enable it in both U-Boot and SPL for faster
> throughput.

I'm not quite sure if those high-speed modes would be required to be enabled for
SPL...

Even though the support for those modes is provided in SPL build, there might be
a little benefit of having it enabled as the only thing SPL would need to fetch 
from 
storage medias would be U-Boot itself, and the difference in access time between
high speed modes enabled or disabled for this task is quite negligible. The 
downside
there would rather be an increase in SPL size to accommodate enabled code paths.

I was contemplating myself to have those included, but decided to op-out from it
as I could not justify the benefit of it.

Do you see any particular use-case where it would be beneficial to enable those 
modes
in SPL? If so - can you please share them, as if it would turn out to be 
beneficial - I might
also turn them on in EVK configs.

> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/configs/imx8mm_beacon_defconfig
> b/configs/imx8mm_beacon_defconfig index c5d331f617..49d5453078 100644
> --- a/configs/imx8mm_beacon_defconfig
> +++ b/configs/imx8mm_beacon_defconfig
> @@ -70,6 +70,13 @@ CONFIG_DM_I2C=y
>  CONFIG_SYS_I2C_MXC=y
>  CONFIG_DM_MMC=y
>  CONFIG_SUPPORT_EMMC_BOOT=y
> +CONFIG_MMC_IO_VOLTAGE=y
> +CONFIG_SPL_MMC_IO_VOLTAGE=y
> +CONFIG_MMC_UHS_SUPPORT=y
> +CONFIG_SPL_MMC_UHS_SUPPORT=y
> +CONFIG_MMC_HS400_ES_SUPPORT=y
> +CONFIG_MMC_HS400_SUPPORT=y
> +CONFIG_SPL_MMC_HS400_SUPPORT=y
>  CONFIG_FSL_USDHC=y
>  CONFIG_PHYLIB=y
>  CONFIG_PHY_ATHEROS=y
> --
> 2.25.1

-- andrey

RE: [PATCH 2/2] ARM: dts: imx8m: add UHS or HS400/HS400ES properties

[ZHIZHIKIN Andrey]

Hello Adam,

> -Original Message-
> From: Adam Ford 
> Sent: Saturday, December 5, 2020 1:43 AM
> To: ZHIZHIKIN Andrey 
> Cc: U-Boot Mailing List ; Stefano Babic
> ; Ye Li 
> Subject: Re: [PATCH 2/2] ARM: dts: imx8m: add UHS or HS400/HS400ES properties
> 
> On Tue, Dec 1, 2020 at 7:32 AM Andrey Zhizhikin  geosystems.com> wrote:
> >
> > i.MX8M series provide support for high speed grades in their usdhc
> > controllers, which has eMMC and SDHC connected to them.
> >
> > Enable this support across the entire i.MX8M family by providing
> > quirks to usdhc controllers designated by storage media connected to them.
> >
> > Signed-off-by: Andrey Zhizhikin
> > 
> > Cc: Stefano Babic 
> > Cc: Ye Li 
> > ---
> >  arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi  | 3 +++
> > arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi | 3 +++
> >  arch/arm/dts/imx8mm-evk-u-boot.dtsi  | 4 
> >  arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi | 4 
> >  arch/arm/dts/imx8mp-evk-u-boot.dtsi  | 4 
> >  arch/arm/dts/imx8mq-evk.dts  | 3 +++
> >  6 files changed, 21 insertions(+)
> >
> > diff --git a/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> > b/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> > index 80d6475b7c..2f86fcce3e 100644
> > --- a/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> > +++ b/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> > @@ -118,8 +118,11 @@
> >
> >   {
> > u-boot,dm-spl;
> > +   u-boot,mmc-hs400-1_8v;
> >  };
> >
> 
> I don't think the "u-boot," prefix is needed.  Looking at other boards' device
> trees, they don't seem to have this.

Correct, I've already realized that and currently working on V3 of the series:
https://lists.denx.de/pipermail/u-boot/2020-December/434159.html

Thanks a lot for testing it though!

> I tried it on the beacon imx8mm-beacon-kit, and it didn't work until I removed
> the "u-boot,"

I believe you had it tested with your patches on top, since it would also 
require
additional config options to be set, which you introduced for imx8mm-beacon-kit.

As I see it now - those changes might be useful and applicable to all imx8m* 
derivatives
and I'm thinking to move those binding to base dtsi files then.

Would there be any objections here?

> 
> With that removed, I can get the following:
> 
> u-boot=> mmc info
> Device: FSL_SDHC
> Manufacturer ID: 27
> OEM: 5048
> Name: SD32G
> Bus Speed: 2
> Mode: UHS SDR104 (208MHz)
> Rd Block Len: 512
> SD version 3.0
> High Capacity: Yes
> Capacity: 29 GiB
> Bus Width: 4-bit
> Erase Group Size: 512 Bytes
> u-boot=>
> 
> and
> 
> u-boot=> mmc info
> Device: FSL_SDHC
> Manufacturer ID: 45
> OEM: 100
> Name: DG403
> Bus Speed: 2
> Mode: HS400 (200MHz)
> Rd Block Len: 512
> MMC version 5.1
> High Capacity: Yes
> Capacity: 29.1 GiB
> Bus Width: 8-bit DDR
> Erase Group Size: 512 KiB
> HC WP Group Size: 8 MiB
> User Capacity: 29.1 GiB WRREL
> Boot Capacity: 4 MiB ENH
> RPMB Capacity: 4 MiB ENH
> Boot area 0 is not write protected
> Boot area 1 is not write protected
> u-boot=>
> 
> adam
> 
> >   {
> > u-boot,dm-spl;
> > +   u-boot,sd-uhs-sdr104;
> > +   u-boot,sd-uhs-ddr50;
> >  };
> > diff --git a/arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi
> > b/arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi
> > index 771ab635f1..f4332edac5 100644
> > --- a/arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi
> > +++ b/arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi
> > @@ -118,8 +118,11 @@
> >
> >   {
> > u-boot,dm-spl;
> > +   u-boot,mmc-hs400-1_8v;
> >  };
> >
> >   {
> > u-boot,dm-spl;
> > +   u-boot,sd-uhs-sdr104;
> > +   u-boot,sd-uhs-ddr50;
> >  };
> > diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> > b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> > index 9f77d3c6ff..67666a08ec 100644
> > --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> > +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> > @@ -100,10 +100,14 @@
> >
> >   {
> > u-boot,dm-spl;
> > +   u-boot,sd-uhs-sdr104;
> > +   u-boot,sd-uhs-ddr50;
> >  };
> >
> >   {
> > u-boot,dm-spl;
> > +   u-boot,mmc-hs400-1_8v;
> > +   u-boot,mmc-hs400-enhanced-strobe;
> >  };
> >
> >   {
> > diff --git a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> > b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> > index 98b0b9891b..e03e635213 100644
> > --- a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> > ++

RE: [PATCH v2 2/2] ARM: dts: imx8m: add UHS or HS400/HS400ES properties

[ZHIZHIKIN Andrey]

Hello,

I've realized that this patch contains wrong bindings, "u-boot," prefix should 
be dropped.

Also, configuration values to enable high speed modes in eSDHC are missing from 
defconfigs - those has to be added as well.

Would sent a V3 for this series, please hold the review of this one.

Sorry for the miss and noise.

> -Original Message-
> From: U-Boot  On Behalf Of Andrey Zhizhikin
> Sent: Wednesday, December 2, 2020 7:01 PM
> To: u-boot@lists.denx.de
> Cc: Stefano Babic ; Ye Li 
> Subject: [PATCH v2 2/2] ARM: dts: imx8m: add UHS or HS400/HS400ES properties
> 
> This email is not from Hexagon’s Office 365 instance. Please be careful while
> clicking links, opening attachments, or replying to this email.
> 
> 
> i.MX8M series provide support for high speed grades in their usdhc 
> controllers,
> which has eMMC and SDHC connected to them.
> 
> Enable this support across the entire i.MX8M family by providing quirks to 
> usdhc
> controllers designated by storage media connected to them.
> 
> Signed-off-by: Andrey Zhizhikin 
> Cc: Stefano Babic 
> Cc: Ye Li 
> ---
> Changes in v2:
> - Moved u-boot binding for imx8mq-evk to separate autoincluded dtsi
>   files
> 
>  arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi  | 3 +++  arch/arm/dts/fsl-imx8qxp-
> mek-u-boot.dtsi | 3 +++
>  arch/arm/dts/imx8mm-evk-u-boot.dtsi  | 4 
>  arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi | 4 
>  arch/arm/dts/imx8mp-evk-u-boot.dtsi  | 4 
>  arch/arm/dts/imx8mq-evk-u-boot.dtsi  | 9 +
>  6 files changed, 27 insertions(+)
> 
> diff --git a/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi b/arch/arm/dts/fsl-
> imx8qm-mek-u-boot.dtsi
> index 80d6475b7c..2f86fcce3e 100644
> --- a/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> +++ b/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> @@ -118,8 +118,11 @@
> 
>   {
> u-boot,dm-spl;
> +   u-boot,mmc-hs400-1_8v;
>  };
> 
>   {
> u-boot,dm-spl;
> +   u-boot,sd-uhs-sdr104;
> +   u-boot,sd-uhs-ddr50;
>  };
> diff --git a/arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi b/arch/arm/dts/fsl-
> imx8qxp-mek-u-boot.dtsi
> index 771ab635f1..f4332edac5 100644
> --- a/arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi
> +++ b/arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi
> @@ -118,8 +118,11 @@
> 
>   {
> u-boot,dm-spl;
> +   u-boot,mmc-hs400-1_8v;
>  };
> 
>   {
> u-boot,dm-spl;
> +   u-boot,sd-uhs-sdr104;
> +   u-boot,sd-uhs-ddr50;
>  };
> diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi b/arch/arm/dts/imx8mm-evk-
> u-boot.dtsi
> index 9f77d3c6ff..67666a08ec 100644
> --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> @@ -100,10 +100,14 @@
> 
>   {
> u-boot,dm-spl;
> +   u-boot,sd-uhs-sdr104;
> +   u-boot,sd-uhs-ddr50;
>  };
> 
>   {
> u-boot,dm-spl;
> +   u-boot,mmc-hs400-1_8v;
> +   u-boot,mmc-hs400-enhanced-strobe;
>  };
> 
>   {
> diff --git a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi b/arch/arm/dts/imx8mn-
> ddr4-evk-u-boot.dtsi
> index 98b0b9891b..e03e635213 100644
> --- a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> @@ -97,10 +97,14 @@
> 
>   {
> u-boot,dm-spl;
> +   u-boot,sd-uhs-sdr104;
> +   u-boot,sd-uhs-ddr50;
>  };
> 
>   {
> u-boot,dm-spl;
> +   u-boot,mmc-hs400-1_8v;
> +   u-boot,mmc-hs400-enhanced-strobe;
>  };
> 
>   {
> diff --git a/arch/arm/dts/imx8mp-evk-u-boot.dtsi b/arch/arm/dts/imx8mp-evk-
> u-boot.dtsi
> index 2452e9175c..0776b24a6e 100644
> --- a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> @@ -126,10 +126,14 @@
> 
>   {
> u-boot,dm-spl;
> +   u-boot,sd-uhs-sdr104;
> +   u-boot,sd-uhs-ddr50;
>  };
> 
>   {
> u-boot,dm-spl;
> +   u-boot,mmc-hs400-1_8v;
> +   u-boot,mmc-hs400-enhanced-strobe;
>  };
> 
>   {
> diff --git a/arch/arm/dts/imx8mq-evk-u-boot.dtsi b/arch/arm/dts/imx8mq-evk-
> u-boot.dtsi
> index 4712cf6a44..d0fc64c433 100644
> --- a/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> @@ -3,3 +3,12 @@
>  _usdhc2_vmmc {
> u-boot,off-on-delay-us = <2>;  };
> +
> + {
> +   u-boot,mmc-hs400-1_8v;
> +};
> +
> + {
> +   u-boot,sd-uhs-sdr104;
> +   u-boot,sd-uhs-ddr50;
> +};
> --
> 2.17.1

-- andrey

RE: [PATCH 1/2] ARM: dts: imx8m: increase off-on delay on the SD Vcc regulator

[ZHIZHIKIN Andrey]

Hello Peter,

> -Original Message-
> From: Peter Robinson 
> Sent: Wednesday, December 2, 2020 9:45 AM
> To: ZHIZHIKIN Andrey 
> Cc: u-boot@lists.denx.de; sba...@denx.de
> Subject: Re: [PATCH 1/2] ARM: dts: imx8m: increase off-on delay on the SD Vcc
> regulator
> 
> 
> On Tue, Dec 1, 2020 at 1:31 PM Andrey Zhizhikin  geosystems.com> wrote:
> >
> > Some SD Card controller and power circuitry has increased capacitance,
> > which keeps the internal logic remains powered after regulator is
> > switch off. This is generally the case when card is switched to SD104
> > mode, where a power cycle should be performed. In case if the card
> > internal logic remains powered, it causes a subsequent failure of mode
> > transition, effectively leading to failed enumeration.
> >
> > Introduce a delay of 20 msec in order to provide a possibility for
> > internal card circuitry to drain voltages and perform a power cycle
> > correctly.
> >
> > Similar fix is done in commit c49d0ac38a76 ("ARM: dts: rmobile:
> > Increase off-on delay on the SD Vcc regulator") targeted Renesas SOCs.
> >
> > Signed-off-by: Andrey Zhizhikin
> > 
> > Cc: Stefano Babic 
> > ---
> >  arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi | 4 
> >  arch/arm/dts/imx8mm-evk-u-boot.dtsi| 4 
> >  arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi   | 4 
> >  arch/arm/dts/imx8mp-evk-u-boot.dtsi| 4 
> >  arch/arm/dts/imx8mq-evk.dts| 1 +
> >  arch/arm/dts/imx8mq-phanbell.dts   | 1 +
> >  6 files changed, 18 insertions(+)
> >
> > diff --git a/arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi
> > b/arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi
> > index fc1aebb2fe..6d80a529ae 100644
> > --- a/arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi
> > +++ b/arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi
> > @@ -37,6 +37,10 @@
> > /delete-property/ assigned-clock-rates;  };
> >
> > +_usdhc2_vmmc {
> > +   u-boot,off-on-delay-us = <2>; };
> > +
> >   {
> > phy-reset-gpios = < 22 GPIO_ACTIVE_LOW>;  }; diff --git
> > a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> > b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> > index b5c12105a9..9f77d3c6ff 100644
> > --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> > +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> > @@ -46,6 +46,10 @@
> > u-boot,dm-spl;
> >  };
> >
> > +_usdhc2_vmmc {
> > +   u-boot,off-on-delay-us = <2>; };
> > +
> >  _reg_usdhc2_vmmc {
> > u-boot,dm-spl;
> >  };
> > diff --git a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> > b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> > index 4419679d4c..98b0b9891b 100644
> > --- a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> > +++ b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> > @@ -47,6 +47,10 @@
> > u-boot,dm-spl;
> >  };
> >
> > +_usdhc2_vmmc {
> > +   u-boot,off-on-delay-us = <2>; };
> > +
> >  _uart2 {
> > u-boot,dm-spl;
> >  };
> > diff --git a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> > b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> > index 24a93ac2d6..2452e9175c 100644
> > --- a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> > +++ b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> > @@ -48,6 +48,10 @@
> > u-boot,dm-spl;
> >  };
> >
> > +_usdhc2_vmmc {
> > +   u-boot,off-on-delay-us = <2>; };
> > +
> >  _usdhc2_vmmc {
> > u-boot,dm-spl;
> >  };
> > diff --git a/arch/arm/dts/imx8mq-evk.dts b/arch/arm/dts/imx8mq-evk.dts
> > index 55294ba9c8..9663683f69 100644
> > --- a/arch/arm/dts/imx8mq-evk.dts
> > +++ b/arch/arm/dts/imx8mq-evk.dts
> > @@ -39,6 +39,7 @@
> > regulator-max-microvolt = <330>;
> > gpio = < 19 GPIO_ACTIVE_HIGH>;
> > enable-active-high;
> > +   u-boot,off-on-delay-us = <2>;
> 
> These should be going in the -u-boot.dtsi like the devices above. Why the two
> different ways of doing it?

imx8mq-evk-u-boot.dtsi is not provided in the source tree. Do you suggest I
should create one and move those bindings there?

> Also if all devices based on the imx8m[mnpq ] need
> this change it might be better putting it in the imx8m[mnpq]-u-boot.dtsi so 
> any
> new boards that get added, like the recently posted imx8mm IoT Gate
> automatically benefit from this fix.

This might depend on the layout of the particular board. Some boards might 
include
additional HW components to aid in