Re: [PATCHv5 6/6] test: py: add initial coverage for scp03 cmd

2021-02-12 Thread Simon Glass
Hi Jorge,

On Tue, 9 Feb 2021 at 13:10, Jorge Ramirez-Ortiz  wrote:
>
> From: Igor Opaniuk 
>
> Add initial test coverage for SCP03 command.
>
> Signed-off-by: Igor Opaniuk 
> ---
>  test/py/tests/test_scp03.py | 27 +++
>  1 file changed, 27 insertions(+)
>  create mode 100644 test/py/tests/test_scp03.py

Reviewed-by: Simon Glass 

This is fine, but note you can also write this test in C for sandbox,
and this might be easier if it gets more complicated. For example you
can check the state of devices from C.

Regards,
Simon


Re: [PATCH v4 10/16] dm: gpio: Add a way to update flags

2021-02-12 Thread Simon Glass
Hi Patrick,

On Wed, 10 Feb 2021 at 01:38, Patrick DELAUNAY
 wrote:
>
>
> On 2/9/21 5:28 AM, Simon Glass wrote:
> > Hi Patrick,
> >
> > On Mon, 8 Feb 2021 at 10:33, Patrick DELAUNAY
> >  wrote:
> >> Hi Simon,
> >>
> >> 2 minor remarks,
> >>
> >> On 2/5/21 5:22 AM, Simon Glass wrote:
> >>> It is convenient to be able to adjust some of the flags for a GPIO while
> >>> leaving others alone. Add a function for this.
> >>>
> >>> Update dm_gpio_set_dir_flags() to make use of this.
> >>>
> >>> Also update dm_gpio_set_value() to use this also, since this allows the
> >>> open-drain / open-source features to be implemented directly in the
> >>> driver, rather than using the uclass workaround.
> >>>
> >>> Update the sandbox tests accordingly. This involves a lot of changes to
> >>> dm_test_gpio_opendrain_opensource() since we no-longer have the direciion
> >>> being reported differently depending on the open drain/open source flags.
> >>>
> >>> Also update the STM32 drivers to let the uclass handle the active low/high
> >>> logic.
> >>>
> >>> Drop the GPIOD_FLAGS_OUTPUT() macro which is no-longer used.
> >>>
> >>> Signed-off-by: Simon Glass 
> >>> ---
> >>>
> >>> Changes in v4:
> >>> - Update dm_gpio_set_dir_flags() to clear direction flags first
> >>>
> >>> Changes in v3:
> >>> - Incorporate GPIOD_FLAGS_OUTPUT() changes from Patrick Delaunay
> >>>
> >>>drivers/gpio/gpio-uclass.c  |  75 ++
> >>>drivers/gpio/stm32_gpio.c   |   3 +-
> >>>drivers/pinctrl/pinctrl-stmfx.c |   5 +-
> >>>include/asm-generic/gpio.h  |  31 ++--
> >>>test/dm/gpio.c  | 132 
> >>>5 files changed, 203 insertions(+), 43 deletions(-)
> >> (...)
> >>
> >>> diff --git a/drivers/gpio/stm32_gpio.c b/drivers/gpio/stm32_gpio.c
> >>> index c2d7046c0dd..125c237551c 100644
> >>> --- a/drivers/gpio/stm32_gpio.c
> >>> +++ b/drivers/gpio/stm32_gpio.c
> >>> @@ -203,12 +203,13 @@ static int stm32_gpio_set_flags(struct udevice 
> >>> *dev, unsigned int offset,
> >>>return idx;
> >>>
> >>>if (flags & GPIOD_IS_OUT) {
> >>> - int value = GPIOD_FLAGS_OUTPUT(flags);
> >>> + bool value = flags & GPIOD_IS_OUT_ACTIVE;
> >> here the bool variable valeu can be 0 or GPIOD_IS_OUT_ACTIVE = BIT(4),
> >> so it should have
> >>
> >> + bool value = !!(flags & GPIOD_IS_OUT_ACTIVE);
> >>
> >> or
> >>
> >> + int value = flags & GPIOD_IS_OUT_ACTIVE;
> >>
> >> PS: not functional impact as
> >>
> >> #define BSRR_BIT(gpio_pin, value)BIT((gpio_pin) + (value ? 0 : 16))
> >>
> >>>if (flags & GPIOD_OPEN_DRAIN)
> >>>stm32_gpio_set_otype(regs, idx, 
> >>> STM32_GPIO_OTYPE_OD);
> >>>else
> >>>stm32_gpio_set_otype(regs, idx, 
> >>> STM32_GPIO_OTYPE_PP);
> >>> +
> >>>stm32_gpio_set_moder(regs, idx, STM32_GPIO_MODE_OUT);
> >>>writel(BSRR_BIT(idx, value), >bsrr);
> >>>
> >>> diff --git a/drivers/pinctrl/pinctrl-stmfx.c 
> >>> b/drivers/pinctrl/pinctrl-stmfx.c
> >>> index 8ddbc3dc281..711b1a5d8c4 100644
> >>> --- a/drivers/pinctrl/pinctrl-stmfx.c
> >>> +++ b/drivers/pinctrl/pinctrl-stmfx.c
> >>> @@ -169,6 +169,8 @@ static int stmfx_gpio_set_flags(struct udevice *dev, 
> >>> unsigned int offset,
> >>>int ret = -ENOTSUPP;
> >>>
> >>>if (flags & GPIOD_IS_OUT) {
> >>> + bool value = flags & GPIOD_IS_OUT_ACTIVE;
> >>> +
> >>
> >> same here
> >>
> >> +   int value = flags & GPIOD_IS_OUT_ACTIVE;
> >> or
> >> +   bool value = !!(flags & GPIOD_IS_OUT_ACTIVE);
> > The bool type should do this automatically. I tested this and it seems
> > to do the right thing.
> >
> I confirmed that it is working, forget my remarks.
>
> for information: I tested it in stm32MP157C-DK2 board (with gcc 9.2)
>
>
> After check, it is my old habit / coding rule, when the bool type
>
> don't exist in C (it was a typedef to int)
>
> but, since C++ introducing a proper bool type,
>
> the cast to 'bool' is enough with current compilers .

Yes I am still getting used to it myself!

>
> Reviewed-by: Patrick Delaunay 
>
> Tested-by: Patrick Delaunay 

Regards,
Simon


Re: [PATCH] clk: fix clk_get_rate() documentation

2021-02-12 Thread Simon Glass
On Fri, 12 Feb 2021 at 18:17, Giulio Benetti
 wrote:
>
> On 2/13/21 12:25 AM, Sean Anderson wrote:
> > On 2/10/21 12:37 PM, Giulio Benetti wrote:
> >> clk_get_rate() can't and doesn't return -ve on error, it actually returns 0
> >> on error or a value greater than 0 on success. So let's fix its
> >> documentation.
> >>
> >> Signed-off-by: Giulio Benetti 
> >> ---
> >>include/clk.h | 2 +-
> >>1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 


Re: [PATCHv5 5/6] sandbox: imply SCP03 and CMD_SCP03

2021-02-12 Thread Simon Glass
On Tue, 9 Feb 2021 at 13:10, Jorge Ramirez-Ortiz  wrote:
>
> From: Igor Opaniuk 
>
> Enable by default SCP_03/CMD_SCP03 for sandbox target.
>
> Signed-off-by: Igor Opaniuk 
> ---
>  arch/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
>

Reviewed-by: Simon Glass 


Re: [PATCHv5 4/6] doc: describe the scp03 command

2021-02-12 Thread Simon Glass
On Tue, 9 Feb 2021 at 13:10, Jorge Ramirez-Ortiz  wrote:
>
> The Secure Channel Protocol 03 command sends control requests
> (enable/provision) to the TEE implementing the protocol between the
> processor and the secure element.
>
> Signed-off-by: Jorge Ramirez-Ortiz 
> ---
>  doc/usage/index.rst |  1 +
>  doc/usage/scp03.rst | 33 +
>  2 files changed, 34 insertions(+)
>  create mode 100644 doc/usage/scp03.rst
>

Reviewed-by: Simon Glass 


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

2021-02-12 Thread Simon Glass
On Wed, 10 Feb 2021 at 17:43, Samuel Dionne-Riel  wrote:
>
> Otherwise, values over 127 end up prefixed with ff.
>
> Signed-off-by: Samuel Dionne-Riel 
> Cc: Simon Glass 
> ---
>
> Minimal reproduction:
>
> ```
> // repro.dts
> /dts-v1/;
>
> / {
> ra = [ 7f ];
> rb = [ 80 ];
> };
> ```
>
> Steps used to compile:
>
>  $ dtc repro.dts > repro.dtb
>
> Without the fix:
>
>  $ fdtgrep --include-node / repro.dtb
> / {
> ra = [7f];
> rb = [ff80];
> };
>
> With the fix:
>
>  $ fdtgrep --include-node / repro.dtb
> / {
> ra = [7f];
> rb = [80];
> };
>
> ---
>
>  tools/fdtgrep.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 


Re: [PATCH 1/1] buildman: 'Thread' object has no attribute 'isAlive'

2021-02-12 Thread Simon Glass
On Thu, 11 Feb 2021 at 04:03, Heinrich Schuchardt  wrote:
>
> The isAlive() method was deprecated in Python 3.8 and has been removed in
> Python 3.9. See https://bugs.python.org/issue37804. Use is_alive() instead.
>
> Since Python 2.6 is_alive() has been a synonym for isAlive(). So there
> should be no problems for users using elder Python 3 versions.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  tools/buildman/builder.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 


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

2021-02-12 Thread Jesse T
sry for top posting I'm on my phone just b4 bed. any way the comment in the
header file says it returns an int. I don't remember what it actually
returns but it should have more clarity. as for moving all the bit
manipulation to a separate init function , I would essentially have to
remake the poll function without the clock driver stuff. I'm assuming u did
this so that it could be made more portable to other soc's. What I'm going
to do is declare the function with the parameters being the timers udevice
struct. and define it based on the soc family. similar to how the Linux
kernel does it

On Fri, Feb 12, 2021, 8:22 PM Giulio Benetti <
giulio.bene...@benettiengineering.com> wrote:

> Hi Jesse,
>
> On 2/11/21 7:54 PM, Jesse T wrote:
> [SNIP]
>
> >  >>> +static int imx_gpt_timer_probe(struct udevice *dev)
> >  >>> +{
> >  >>> +struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
> >  >>> +struct imx_gpt_timer_priv *priv = dev_get_priv(dev);
> >  >>> +struct imx_gpt_timer_regs *regs;
> >  >>> +struct clk clk;
> >  >>> +fdt_addr_t addr;
> >  >>> +u32 prescaler;
> >  >>> +u32 rate;
> >  >>> +int ret;
> >  >>> +
> >  >>> +addr = dev_read_addr(dev);
> >  >>> +if (addr == FDT_ADDR_T_NONE)
> >  >>> +return -EINVAL;
> >  >>> +
> >  >>> +priv->base = (struct imx_gpt_timer_regs *)addr;
> >  >>> +
> >  >>> +ret = clk_get_by_index(dev, 0, );
> >  >>> +if (ret < 0)
> >  >>> +return ret;
> >  >>> +
> >  >>> +ret = clk_enable();
> >  >>> +if (ret) {
> >  >>> +dev_err(dev, "Failed to enable clock\n");
> >  >>> +return ret;
> >  >>> +}
> >  >>> +
> >  >>> +regs = priv->base;
> >  >>> +
> >  >>> +/* Reset the timer */
> >  >>> +setbits_le32(>cr, GPT_CR_SWR);
> >  >>> +
> >  >>> +/* Wait for timer to finish reset */
> >  >>> +while (readl(>cr) & GPT_CR_SWR)
> >  >>> +;
> >  >>> +
> >  >>> +/* Get timer clock rate */
> >  >>> +rate = clk_get_rate();
> >  >>
> >  >> clk_get_rate() has a wrong description in include/clk.h saying:
> >  >> "@return clock rate in Hz, or -ve error code."
> >  >>
> >  >> This^^^ is wrong.
> >  >> If you dig into drivers/clk/clk-uclass.c and look for
> > clk_get_rate(),
> >  >> you will see that it returns 0 on error and > 0 if succesfull.
> >  >>
> >  >> I've just sent a patch for this:
> >  >>
> >
> https://patchwork.ozlabs.org/project/uboot/patch/20210210173722.4823-1-giulio.bene...@benettiengineering.com/
> >  >>
> >  >>
> >  >>> +if ((int)rate <= 0) {
> >  >>
> >  >> This is a cast trying to solve the problem above but
> > it's
> >  >> not correct. clk_get_rate() returns ulong, not int, so modify
> "int
> >  >> rate" into "ulong rate".
> >  > Ah this makes sense now.
>
> Here it's my bad, clk_get_rate() really returns ulong but can return a
> negative number too, so my patch has been dropped. You can verify it in
> clk-uclass.c where function is implemented, in get_rate() function
> pointer is null the return -ENOSYS. Then please declare rate as ulong
> and check it in if statement with IS_ERR_VALUE(). That way you're sure
> it's not negative.
>
> Thank you
> Best regards
>
> --
> Giulio Benetti
> Benetti Engineering sas
>
>
>
>


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

2021-02-12 Thread Giulio Benetti

Hi Jesse,

On 2/11/21 7:54 PM, Jesse T wrote:
[SNIP]


 >>> +static int imx_gpt_timer_probe(struct udevice *dev)
 >>> +{
 >>> +    struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
 >>> +    struct imx_gpt_timer_priv *priv = dev_get_priv(dev);
 >>> +    struct imx_gpt_timer_regs *regs;
 >>> +    struct clk clk;
 >>> +    fdt_addr_t addr;
 >>> +    u32 prescaler;
 >>> +    u32 rate;
 >>> +    int ret;
 >>> +
 >>> +    addr = dev_read_addr(dev);
 >>> +    if (addr == FDT_ADDR_T_NONE)
 >>> +    return -EINVAL;
 >>> +
 >>> +    priv->base = (struct imx_gpt_timer_regs *)addr;
 >>> +
 >>> +    ret = clk_get_by_index(dev, 0, );
 >>> +    if (ret < 0)
 >>> +    return ret;
 >>> +
 >>> +    ret = clk_enable();
 >>> +    if (ret) {
 >>> +    dev_err(dev, "Failed to enable clock\n");
 >>> +    return ret;
 >>> +    }
 >>> +
 >>> +    regs = priv->base;
 >>> +
 >>> +    /* Reset the timer */
 >>> +    setbits_le32(>cr, GPT_CR_SWR);
 >>> +
 >>> +    /* Wait for timer to finish reset */
 >>> +    while (readl(>cr) & GPT_CR_SWR)
 >>> +    ;
 >>> +
 >>> +    /* Get timer clock rate */
 >>> +    rate = clk_get_rate();
 >>
 >> clk_get_rate() has a wrong description in include/clk.h saying:
 >> "@return clock rate in Hz, or -ve error code."
 >>
 >> This    ^^^ is wrong.
 >> If you dig into drivers/clk/clk-uclass.c and look for
clk_get_rate(),
 >> you will see that it returns 0 on error and > 0 if succesfull.
 >>
 >> I've just sent a patch for this:
 >>

https://patchwork.ozlabs.org/project/uboot/patch/20210210173722.4823-1-giulio.bene...@benettiengineering.com/
 >>
 >>
 >>> +    if ((int)rate <= 0) {
 >>
 >> This     is a cast trying to solve the problem above but
it's
 >> not correct. clk_get_rate() returns ulong, not int, so modify "int
 >> rate" into "ulong rate".
 > Ah this makes sense now.


Here it's my bad, clk_get_rate() really returns ulong but can return a 
negative number too, so my patch has been dropped. You can verify it in 
clk-uclass.c where function is implemented, in get_rate() function 
pointer is null the return -ENOSYS. Then please declare rate as ulong 
and check it in if statement with IS_ERR_VALUE(). That way you're sure 
it's not negative.


Thank you
Best regards

--
Giulio Benetti
Benetti Engineering sas





Re: [PATCH] clk: fix clk_get_rate() documentation

2021-02-12 Thread Giulio Benetti

On 2/13/21 12:25 AM, Sean Anderson wrote:

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

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

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

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



NAK. This function *does* return negative errors (see e.g.
drivers/clk/clk-uclass.c). However, it may return 0 if passed an invalid
clock (see clk_valid).


Oops, I didn't dig enough, sorry. It must pass negative value to signal 
if get_rate() pointer.


Best regards
--
Giulio Benetti
Benetti Engineering sas


Re: [PATCH] clk: fix clk_get_rate() documentation

2021-02-12 Thread Sean Anderson

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

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

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

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



NAK. This function *does* return negative errors (see e.g.
drivers/clk/clk-uclass.c). However, it may return 0 if passed an invalid
clock (see clk_valid).

--Sean


Re: [GIT] Pull request: u-boot-dfu (12.02.2021)

2021-02-12 Thread Marek Vasut

On 2/12/21 7:25 PM, Lukasz Majewski wrote:

Dear Marek,

Please find this PR with fastboot improvement code rebased on top of
u-boot-denx-usb tree.

CI:
https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=28=results

(There shall be at least one follow up PR with work done by Sean).

Merge tag data/information:
https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/-/tags/u-boot-dfu-12Feb2021

The following changes since commit
db8fb2ffc4f3f63b9005f676ab3879a06de6cdda:

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

are available in the Git repository at:

   u-boot-dfu/master


Applied, thanks

[...]


[PATCH v2] serial: s5p: Allow independent selection

2021-02-12 Thread Mark Kettenis
Currently support for the Samsung serial port driver is part
of CONFIG_S5P which controls selection of several drivers for
the S5P family.  Give it its own config option such that we
can use it on other SoCs as well.

Signed-off-by: Mark Kettenis 
---

v2: fix Kconfig

 drivers/serial/Kconfig  | 7 +++
 drivers/serial/Makefile | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 9db4cae1df..2ada150526 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -722,6 +722,13 @@ config ROCKCHIP_SERIAL
  This uses the ns16550 driver, converting the platdata from of-platdata
  to the ns16550 format.
 
+config S5P_SERIAL
+   bool "Support for Samsung S5P UART"
+   depends on ARCH_EXYNOS || ARCH_S5PC1XX
+   default y
+   help
+ Select this to enable Samsung S5P UART support.
+
 config SANDBOX_SERIAL
bool "Sandbox UART support"
depends on SANDBOX
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 0c3810f5d5..92bcb30b85 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -41,7 +41,7 @@ obj-$(CONFIG_EFI_APP) += serial_efi.o
 obj-$(CONFIG_LPC32XX_HSUART) += lpc32xx_hsuart.o
 obj-$(CONFIG_MCFUART) += serial_mcf.o
 obj-$(CONFIG_SYS_NS16550) += ns16550.o
-obj-$(CONFIG_S5P) += serial_s5p.o
+obj-$(CONFIG_S5P_SERIAL) += serial_s5p.o
 obj-$(CONFIG_MXC_UART) += serial_mxc.o
 obj-$(CONFIG_PXA_SERIAL) += serial_pxa.o
 obj-$(CONFIG_MESON_SERIAL) += serial_meson.o
-- 
2.30.0



Re: [PULL] u-boot-atmel-fixes-2021.04-a

2021-02-12 Thread Tom Rini
On Fri, Feb 12, 2021 at 09:14:59AM +, eugen.hris...@microchip.com wrote:

> Hello Tom,
> 
> Please pull tag u-boot-atmel-fixes-2021.04-a , the first set of fixes 
> for atmel for 2021.04 cycle.
> 
> This small PR includes just two fixes but very important: one revert in 
> the clk subsystem which fixes the boot on many old boards 
> (sama5d2_xplained, sama5d4_xplained), which currently crash at boot; and 
> one small fix related to debug serial on sama7g5ek board.
> 
> Thanks!
> Eugen
> 
> 
> The following changes since commit c7182c02cefb11431a79a8abb4d8a821e4a478b5:
> 
>Merge tag 'u-boot-amlogic-20210210' of 
> https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic (2021-02-10 
> 07:56:57 -0500)
> 
> are available in the Git repository at:
> 
>https://gitlab.denx.de/u-boot/custodians/u-boot-atmel.git 
> tags/u-boot-atmel-fixes-2021.04-a
> 
> for you to fetch changes up to 65bde1c087f847a2e279501e27eeaddba16e3b51:
> 
>clk: at91: compat: partially revert "dm: Remove uses of 
> device_bind_offset()" (2021-02-11 09:26:40 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] fs: ext4: Add metadata checksums support

2021-02-12 Thread Tom Rini
On Fri, Feb 12, 2021 at 05:57:47PM +0100, Fredrik Hallenberg wrote:

> Support crc32c checksums in ext4 filesystems with metadata_csum flag
> active. This includes superblock, inodes, inode and block group tables,
> directory blocks and journal.
> 
> Signed-off-by: Fredrik Hallenberg 

I've initially put this in a local branch and run the fs tests on
sandbox both with default options and forcing metadata_csum to be
enabled, and it worked in both cases.  Thanks for posting the patch!
Can you let us know on what systems you've tested this?

-- 
Tom


signature.asc
Description: PGP signature


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

2021-02-12 Thread Peter Bergin

Hi Andrey,

thanks for the review!

On 2021-02-12 19:16, ZHIZHIKIN Andrey wrote:

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

Good catch and it is indeed wrong.

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.

Good suggestion.

+   $ 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


Will update and send a v2 on this.

Best regards,
/Peter



Re: Final of-platdata thing

2021-02-12 Thread Simon Glass
Hi Tom,

On Fri, 12 Feb 2021 at 11:23, Tom Rini  wrote:
>
> On Fri, Feb 12, 2021 at 11:18:22AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 11 Feb 2021 at 14:51, Tom Rini  wrote:
> > >
> > > On Wed, Feb 10, 2021 at 11:39:54AM -0700, Simon Glass wrote:
> > >
> > > > Hi Tom,
> > > >
> > > > I have the dtoc changes ready to go but I was thinking it best to
> > > > apply the driver-model updates before sending a pull request.
> > > >
> > > > But that is (currently) designed to set on top of the SPL test
> > > > improvements...have you had a look at that one? I can probably
> > > > separate them if needed.
> > >
> > > I think both are going to need to wait for the next merge window to
> > > open, to start with.  So I don't have a strong feeling about needing to
> > > split it up further.
> >
> > That's unfortunate, given the long cycle time at the moment. The test
> > stuff definitely came in very near the end of the merge window, but it
> > does tidy up SPL testing. Still, like of-platdata-inst, nothing
> > depends on it.
>
> Well, -rc2 is Monday.  I should open -next with either -rc3 on March
> 1st, or -rc4 on the 15th.  I don't think I've been consistent enough, so
> I should probably try and formalize opening -next the month before, so
> that would be -rc3.  I hope that's not too far off.

Yes -next is a big help. Anyway I have mostly caught up on my patch
backlog so I hope there won't be as much code to land as this time.

Regards,
Simon


[GIT] Pull request: u-boot-dfu (12.02.2021)

2021-02-12 Thread Lukasz Majewski
Dear Marek,

Please find this PR with fastboot improvement code rebased on top of
u-boot-denx-usb tree.

CI:
https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=28=results

(There shall be at least one follow up PR with work done by Sean).

Merge tag data/information:
https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/-/tags/u-boot-dfu-12Feb2021

The following changes since commit
db8fb2ffc4f3f63b9005f676ab3879a06de6cdda:

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

are available in the Git repository at:

  u-boot-dfu/master 

for you to fetch changes up to a7d1b66d65972965ffbf002277bac99b0e290aee:

  fastboot: add UUU command UCmd and ACmd support (2021-02-11 22:54:11
  +0100)


Heiko Schocher (1):
  fastboot: add UUU command UCmd and ACmd support

Sean Anderson (10):
  mmc: sandbox: Add support for writing
  test: dm: Add test for fastboot mmc partition naming
  part: Give several functions more useful return values
  part: Support getting whole disk from
part_get_info_by_dev_and_name_or_num part: Support string block devices
in part_get_info_by_dev_and_name fastboot: Remove mmcpart argument from
raw_part_get_info_by_name fastboot: Move part_get_info_by_name_or_alias
after raw_part_get_info_by_name fastboot: Allow u-boot-style partitions
  doc: Rename k210 partitions anchor
  doc: Document partition specifications



Best regards,

Lukasz Majewski

--

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


pgptD4kxEEexr.pgp
Description: OpenPGP digital signature


Re: Final of-platdata thing

2021-02-12 Thread Tom Rini
On Fri, Feb 12, 2021 at 11:18:22AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 11 Feb 2021 at 14:51, Tom Rini  wrote:
> >
> > On Wed, Feb 10, 2021 at 11:39:54AM -0700, Simon Glass wrote:
> >
> > > Hi Tom,
> > >
> > > I have the dtoc changes ready to go but I was thinking it best to
> > > apply the driver-model updates before sending a pull request.
> > >
> > > But that is (currently) designed to set on top of the SPL test
> > > improvements...have you had a look at that one? I can probably
> > > separate them if needed.
> >
> > I think both are going to need to wait for the next merge window to
> > open, to start with.  So I don't have a strong feeling about needing to
> > split it up further.
> 
> That's unfortunate, given the long cycle time at the moment. The test
> stuff definitely came in very near the end of the merge window, but it
> does tidy up SPL testing. Still, like of-platdata-inst, nothing
> depends on it.

Well, -rc2 is Monday.  I should open -next with either -rc3 on March
1st, or -rc4 on the 15th.  I don't think I've been consistent enough, so
I should probably try and formalize opening -next the month before, so
that would be -rc3.  I hope that's not too far off.

-- 
Tom


signature.asc
Description: PGP signature


Re: Final of-platdata thing

2021-02-12 Thread Simon Glass
Hi Tom,

On Thu, 11 Feb 2021 at 14:51, Tom Rini  wrote:
>
> On Wed, Feb 10, 2021 at 11:39:54AM -0700, Simon Glass wrote:
>
> > Hi Tom,
> >
> > I have the dtoc changes ready to go but I was thinking it best to
> > apply the driver-model updates before sending a pull request.
> >
> > But that is (currently) designed to set on top of the SPL test
> > improvements...have you had a look at that one? I can probably
> > separate them if needed.
>
> I think both are going to need to wait for the next merge window to
> open, to start with.  So I don't have a strong feeling about needing to
> split it up further.

That's unfortunate, given the long cycle time at the moment. The test
stuff definitely came in very near the end of the merge window, but it
does tidy up SPL testing. Still, like of-platdata-inst, nothing
depends on it.

Regards,
Simon


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

2021-02-12 Thread 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


[PATCH] fs: ext4: Add metadata checksums support

2021-02-12 Thread Fredrik Hallenberg
Support crc32c checksums in ext4 filesystems with metadata_csum flag
active. This includes superblock, inodes, inode and block group tables,
directory blocks and journal.

Signed-off-by: Fredrik Hallenberg 
---
 fs/ext4/Kconfig   |   1 +
 fs/ext4/ext4_common.c |  91 ++---
 fs/ext4/ext4_common.h |   7 +-
 fs/ext4/ext4_journal.c| 135 -
 fs/ext4/ext4_journal.h|  40 +++-
 fs/ext4/ext4_write.c  | 162 --
 include/ext4fs.h  |   7 ++
 include/ext_common.h  |  77 +-
 test/py/tests/test_env.py |   3 -
 test/py/tests/test_fs/conftest.py |   4 -
 10 files changed, 441 insertions(+), 86 deletions(-)

diff --git a/fs/ext4/Kconfig b/fs/ext4/Kconfig
index 1a913d2b6d..da033428b2 100644
--- a/fs/ext4/Kconfig
+++ b/fs/ext4/Kconfig
@@ -8,6 +8,7 @@ config FS_EXT4
 config EXT4_WRITE
bool "Enable ext4 filesystem write support"
depends on FS_EXT4
+   select CRC32C
help
  This provides support for creating and writing new files to an
  existing ext4 filesystem partition.
diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index c52cc400e1..6e23e47c97 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -45,6 +45,8 @@ __le32 *ext4fs_indir3_block;
 int ext4fs_indir3_size;
 int ext4fs_indir3_blkno = -1;
 struct ext2_inode *g_parent_inode;
+int g_parent_inode_no;
+
 static int symlinknest;
 
 #if defined(CONFIG_EXT4_WRITE)
@@ -416,32 +418,6 @@ void ext4fs_reset_inode_bmap(int inode_no, unsigned char 
*buffer, int index)
*ptr = *ptr & ~(operand);
 }
 
-uint16_t ext4fs_checksum_update(uint32_t i)
-{
-   struct ext2_block_group *desc;
-   struct ext_filesystem *fs = get_fs();
-   uint16_t crc = 0;
-   __le32 le32_i = cpu_to_le32(i);
-
-   desc = ext4fs_get_group_descriptor(fs, i);
-   if (le32_to_cpu(fs->sb->feature_ro_compat) & 
EXT4_FEATURE_RO_COMPAT_GDT_CSUM) {
-   int offset = offsetof(struct ext2_block_group, bg_checksum);
-
-   crc = ext2fs_crc16(~0, fs->sb->unique_id,
-  sizeof(fs->sb->unique_id));
-   crc = ext2fs_crc16(crc, _i, sizeof(le32_i));
-   crc = ext2fs_crc16(crc, desc, offset);
-   offset += sizeof(desc->bg_checksum);/* skip checksum */
-   assert(offset == sizeof(*desc));
-   if (offset < fs->gdsize) {
-   crc = ext2fs_crc16(crc, (__u8 *)desc + offset,
-  fs->gdsize - offset);
-   }
-   }
-
-   return crc;
-}
-
 static int check_void_in_dentry(struct ext2_dirent *dir, char *filename)
 {
int dentry_length;
@@ -472,6 +448,33 @@ static int check_void_in_dentry(struct ext2_dirent *dir, 
char *filename)
return 0;
 }
 
+static void ext4fs_set_dirent_tail_csum(struct ext_filesystem *fs, uint8_t 
*block)
+{
+   struct ext4_dir_entry_tail *tail;
+   uint32_t crc32;
+   uint32_t inode_seed;
+   __le32 inum = cpu_to_le32(g_parent_inode_no);
+   __le32 gen = g_parent_inode->generation;
+   int size;
+
+   if (!(le32_to_cpu(fs->sb->feature_ro_compat) & 
EXT4_FEATURE_RO_COMPAT_METADATA_CSUM))
+   return;
+
+   tail = (struct ext4_dir_entry_tail *)(block + fs->blksz
+ - sizeof(struct 
ext4_dir_entry_tail));
+   if (tail->det_reserved_ft != 0xde) {
+   printf("Bad dirent tail\n");
+   return;
+   }
+
+   inode_seed = ext4_csum(fs->csum_seed, (uint8_t *), sizeof(inum));
+   inode_seed = ext4_csum(inode_seed, (uint8_t *), sizeof(gen));
+
+   size = (uint8_t *)tail - block;
+   crc32 = ext4_csum(inode_seed, block, size);
+   tail->det_checksum = cpu_to_le32(crc32);
+}
+
 int ext4fs_update_parent_dentry(char *filename, int file_type)
 {
unsigned int *zero_buffer = NULL;
@@ -492,6 +495,10 @@ int ext4fs_update_parent_dentry(char *filename, int 
file_type)
uint32_t new_size;
uint32_t new_blockcnt;
uint32_t directory_blocks;
+   struct ext4_dir_entry_tail *tail;
+   int has_metadata_chksum = le32_to_cpu(fs->sb->feature_ro_compat) &
+   EXT4_FEATURE_RO_COMPAT_METADATA_CSUM ? 1 : 0;
+   uint32_t max_size = fs->blksz;
 
zero_buffer = zalloc(fs->blksz);
if (!zero_buffer) {
@@ -529,12 +536,20 @@ restart_read:
dir = (struct ext2_dirent *)root_first_block_buffer;
totalbytes = 0;
 
+   if (has_metadata_chksum) {
+   tail = (struct ext4_dir_entry_tail *)(root_first_block_buffer + 
fs->blksz
+ - sizeof(struct 
ext4_dir_entry_tail));
+   if (tail->det_reserved_ft != 0xde)
+   printf("Bad dirent tail\n");
+   max_size 

[PATCH] sunxi: support boot console on uart1 for sun8i

2021-02-12 Thread Tobias Schramm
From: Tobias Schramm 

This commit adds support for using uart1 as boot console on sun8i.

Signed-off-by: Tobias Schramm 
---
 arch/arm/include/asm/arch-sunxi/gpio.h | 1 +
 arch/arm/mach-sunxi/board.c| 4 
 include/configs/sunxi-common.h | 2 ++
 3 files changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h 
b/arch/arm/include/asm/arch-sunxi/gpio.h
index de77bf638e..2969a530ae 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -190,6 +190,7 @@ enum sunxi_gpio_number {
 #define SUN5I_GPG_SDC1 2
 #define SUN6I_GPG_SDC1 2
 #define SUN8I_GPG_SDC1 2
+#define SUN8I_GPG_UART12
 #define SUN6I_GPG_TWI3 2
 #define SUN5I_GPG_UART14
 
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index ae6bc656d9..febec0ae03 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -144,6 +144,10 @@ static int gpio_init(void)
sunxi_gpio_set_cfgpin(SUNXI_GPL(2), SUN8I_GPL_R_UART);
sunxi_gpio_set_cfgpin(SUNXI_GPL(3), SUN8I_GPL_R_UART);
sunxi_gpio_set_pull(SUNXI_GPL(3), SUNXI_GPIO_PULL_UP);
+#elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUN8I)
+   sunxi_gpio_set_cfgpin(SUNXI_GPG(6), SUN8I_GPG_UART1);
+   sunxi_gpio_set_cfgpin(SUNXI_GPG(7), SUN8I_GPG_UART1);
+   sunxi_gpio_set_pull(SUNXI_GPL(7), SUNXI_GPIO_PULL_UP);
 #else
 #error Unsupported console port number. Please fix pin mux settings in board.c
 #endif
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 000f386470..19f0026888 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -251,6 +251,8 @@ extern int soft_i2c_gpio_scl;
 #define OF_STDOUT_PATH "/soc@01c0/serial@01c28800:115200"
 #elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN8I)
 #define OF_STDOUT_PATH "/soc@01c0/serial@01f02800:115200"
+#elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUN8I)
+#define OF_STDOUT_PATH "/soc@01c0/serial@01c28400:115200"
 #else
 #error Unsupported console port nr. Please fix stdout-path in sunxi-common.h.
 #endif
-- 
2.30.0



Re: [PATCH] spi: zynqmp_gqspi: fix set_speed bug on multiple runs

2021-02-12 Thread Michal Simek
Hi Ashok

On 1/20/21 9:28 PM, Brandon Maier wrote:
> If zynqmp_qspi_set_speed() is called multiple times with the same speed,
> then on the second call it will skip recalculating the baud_rate_val as
> it assumes the speed is already configured correctly. But it will still
> write the baud_rate_val to the configuration register and call
> zynqmp_gqspi_set_tapdelay(). Because it skipped recalculating the
> baud_rate_val, it will use the initial value of 0 . This causes the
> driver to run at maximum speed which for many spi flashes is too fast and
> causes data corruption.
> 
> Instead only write out a new baud_rate_val if we have calculated the
> correct baud_rate_val.
> 
> This opens up another issue with the "if (speed == 0)", we don't save
> off the new plat->speed_hz value when setting the baud rate on the
> speed=0 path. Instead mimic what the Linux zynqmp gqspi driver does, and
> have speed==0 just use the same calculation as a normal speed. That will
> cause the baud_rate_val to use the slowest speed possible, which is the
> safest option.
> 
> Signed-off-by: Brandon Maier 
> CC: ja...@amarulasolutions.com
> CC: michal.si...@xilinx.com
> CC: Ashok Reddy Soma 
> ---
>  drivers/spi/zynqmp_gqspi.c | 23 +++
>  1 file changed, 11 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/spi/zynqmp_gqspi.c b/drivers/spi/zynqmp_gqspi.c
> index c7db43a09a..6641c2e9d5 100644
> --- a/drivers/spi/zynqmp_gqspi.c
> +++ b/drivers/spi/zynqmp_gqspi.c
> @@ -320,12 +320,9 @@ static int zynqmp_qspi_set_speed(struct udevice *bus, 
> uint speed)
>   if (speed > plat->frequency)
>   speed = plat->frequency;
>  
> - /* Set the clock frequency */
> - confr = readl(>confr);
> - if (speed == 0) {
> - /* Set baudrate x8, if the freq is 0 */
> - baud_rate_val = GQSPI_DFLT_BAUD_RATE_VAL;
> - } else if (plat->speed_hz != speed) {
> + if (plat->speed_hz != speed) {
> + /* Set the clock frequency */
> + /* If speed == 0, default to lowest speed */
>   while ((baud_rate_val < 8) &&
>  ((plat->frequency /
>  (2 << baud_rate_val)) > speed))
> @@ -335,13 +332,15 @@ static int zynqmp_qspi_set_speed(struct udevice *bus, 
> uint speed)
>   baud_rate_val = GQSPI_DFLT_BAUD_RATE_VAL;
>  
>   plat->speed_hz = plat->frequency / (2 << baud_rate_val);
> - }
> - confr &= ~GQSPI_BAUD_DIV_MASK;
> - confr |= (baud_rate_val << 3);
> - writel(confr, >confr);
>  
> - zynqmp_qspi_set_tapdelay(bus, baud_rate_val);
> - debug("regs=%p, speed=%d\n", priv->regs, plat->speed_hz);
> + confr = readl(>confr);
> + confr &= ~GQSPI_BAUD_DIV_MASK;
> + confr |= (baud_rate_val << 3);
> + writel(confr, >confr);
> + zynqmp_qspi_set_tapdelay(bus, baud_rate_val);
> +
> + debug("regs=%p, speed=%d\n", priv->regs, plat->speed_hz);
> + }
>  
>   return 0;
>  }
> 

Ashok: Can you please review this patch?

Thanks,
Michal


Re: [RFC RESEND 1/2] efi: Add ESRT to the EFI system table

2021-02-12 Thread Heinrich Schuchardt
On 29.01.21 06:26, AKASHI Takahiro wrote:
> First of all, one comment:
> It would be nice to have a list of what features are supported
> and what are not in this patch series.
> For example, with this patch, I suspect
> - FwVersion in ESRT entry will never be updated at capsule update

According to the UEFI specification the ESRT should be updated

* at EFI_EVENT_GROUP_READY_TO_BOOT
* when a device (with a Firmware Management Protocol) is added or removed
* after Update Capsule
* at EFI_EVENT_GROUP_EXIT_BOOT_SERVICES

At each of these events we can call the same function collection the
information for a new ESRT by calling
EFI_FIRMWARE_MANAGEMENT_PROTOCOL.GetImageInfo() and freeing the memory
of the old instance.

Monitoring EFI_EVENT_GROUP_READY_TO_BOOT and
EFI_EVENT_GROUP_EXIT_BOOT_SERVICESs seems redundant if we catch the
other two.

> - LastAttemptVersion/LastAttemptStatus will not be sustained across reboots.

This information is provided by the Firmware Management Protocol (see
23.4.3 Mapping Firmware Management Protocol Descriptors to ESRT
Entries). Jose's patches can only use the information provided by the
code that Sughosh and you created.

If update status persistence is missing in the current implementation of
the firmware management protocol, what are your plans for adding it?

Best regards

Heinrich

>
> So I'm not sure that the proposed implementation is useful
> in a practical manner.
>



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

2021-02-12 Thread Ahmad Fatoum
On 11.02.21 14:02, Tom Rini wrote:
> On Thu, Feb 11, 2021 at 12:14:51PM +0100, Ahmad Fatoum wrote:
>> I think platforms like the STM32MP1 should be handled specially, because
>> they support having an external device tree passed from the FSBL at runtime.
>> See 
>> https://github.com/trini/u-boot/blob/master/arch/arm/mach-stm32mp/boot_params.c#L32
>>
>> @Patrick, wouldn't this change break booting newer U-Boot with older TF-A in
>> some configurations? Or is this reusing-fsbl-fdt feature unused?
> 
> The long stated policy of U-Boot is to allow non-final bindings to be
> used until they're finalized in Linux in order to address the "chicken
> and egg" problem, since it's already a terrible idea to go to production
> with a Linux kernel that's using non-final bindings.  Any older TF-A
> that doesn't work with this newer binding should be on a developer board
> and they can just upgrade.  Linux says "DT is ABI" and allows the ABI to
> break when there's a bug in the DT.  We don't say "DT is ABI" we say "we
> use the Linux kernel binding".

I see. Thanks for the clarification.

I am still curious what configurations use the TF-A-provided device tree
for U-Boot. Patrick?

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


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

2021-02-12 Thread Peter Bergin
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.

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_202006.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
+   $ 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



[PULL] u-boot-atmel-fixes-2021.04-a

2021-02-12 Thread Eugen.Hristev
Hello Tom,

Please pull tag u-boot-atmel-fixes-2021.04-a , the first set of fixes 
for atmel for 2021.04 cycle.

This small PR includes just two fixes but very important: one revert in 
the clk subsystem which fixes the boot on many old boards 
(sama5d2_xplained, sama5d4_xplained), which currently crash at boot; and 
one small fix related to debug serial on sama7g5ek board.

Thanks!
Eugen


The following changes since commit c7182c02cefb11431a79a8abb4d8a821e4a478b5:

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

are available in the Git repository at:

   https://gitlab.denx.de/u-boot/custodians/u-boot-atmel.git 
tags/u-boot-atmel-fixes-2021.04-a

for you to fetch changes up to 65bde1c087f847a2e279501e27eeaddba16e3b51:

   clk: at91: compat: partially revert "dm: Remove uses of 
device_bind_offset()" (2021-02-11 09:26:40 +0200)


First set of u-boot-atmel fixes for 2021.04 cycle


Eugen Hristev (2):
   ARM: dts: at91: sama7g5ek: enable pull-up for serial debug line
   clk: at91: compat: partially revert "dm: Remove uses of 
device_bind_offset()"

  arch/arm/dts/sama7g5ek.dts |  2 +-
  drivers/clk/at91/compat.c  | 20 
  2 files changed, 13 insertions(+), 9 deletions(-)


[PATCH] ARM: stm32: Add USB host boot support

2021-02-12 Thread Marek Vasut
Add support for booting from USB pen drive, since USB host port is
available on the STM32MP1.

Signed-off-by: Marek Vasut 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
---
 include/configs/stm32mp1.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
index c5539285af1..36e400453ea 100644
--- a/include/configs/stm32mp1.h
+++ b/include/configs/stm32mp1.h
@@ -102,11 +102,18 @@
 #define BOOT_TARGET_UBIFS(func)
 #endif
 
+#ifdef CONFIG_USB
+#define BOOT_TARGET_USB(func)  func(USB, usb, 0)
+#else
+#define BOOT_TARGET_USB(func)
+#endif
+
 #define BOOT_TARGET_DEVICES(func)  \
BOOT_TARGET_MMC1(func)  \
BOOT_TARGET_UBIFS(func) \
BOOT_TARGET_MMC0(func)  \
BOOT_TARGET_MMC2(func)  \
+   BOOT_TARGET_USB(func)   \
BOOT_TARGET_PXE(func)
 
 /*
-- 
2.30.0



Re: [PATCH] fpga: zynqpl: fix buffer alignment

2021-02-12 Thread Michal Simek



On 2/10/21 10:42 PM, Michael Walle wrote:
> Due to pointer arithmetic, "sizeof(u32) * ARCH_DMA_MINALIGN" is
> subtracted. It seems that the original intention was to just subtract
> ARCH_DMA_MINALIGN. Fix it.
> 
> Signed-off-by: Michael Walle 
> ---
>  drivers/fpga/zynqpl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/fpga/zynqpl.c b/drivers/fpga/zynqpl.c
> index a11e485525..2de40109a8 100644
> --- a/drivers/fpga/zynqpl.c
> +++ b/drivers/fpga/zynqpl.c
> @@ -315,7 +315,7 @@ static u32 *zynq_align_dma_buffer(u32 *buf, u32 len, u32 
> swap)
>   if (new_buf > buf) {
>   debug("%s: Aligned buffer is after buffer start\n",
> __func__);
> - new_buf -= ARCH_DMA_MINALIGN;
> + new_buf = (u32 *)((u32)new_buf - ARCH_DMA_MINALIGN);
>   }
>   printf("%s: Align buffer at %x to %x(swap %d)\n", __func__,
>  (u32)buf, (u32)new_buf, swap);
> 

applied.
M


[PATCH] cmd: mmc: add mmc partboot

2021-02-12 Thread grygorii tertychnyi
This patch allows to determine active boot partition in boot script:

if mmc partboot ${mmcdev} 2; then
echo "booted from eMMC boot1 partition"
fi

Signed-off-by: Grygorii Tertychnyi 
---
 cmd/mmc.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/cmd/mmc.c b/cmd/mmc.c
index 1529a3e05ddd..010d6ab9aa19 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -771,6 +771,41 @@ static int do_mmc_boot_resize(struct cmd_tbl *cmdtp, int 
flag,
return CMD_RET_SUCCESS;
 }
 
+static int do_mmc_partboot(struct cmd_tbl *cmdtp, int flag,
+  int argc, char *const argv[])
+{
+   int dev;
+   struct mmc *mmc;
+   u8 part_args, part_emmc;
+
+   if (argc != 3)
+   return CMD_RET_USAGE;
+
+   dev = simple_strtoul(argv[1], NULL, 10);
+
+   mmc = init_mmc_device(dev, false);
+   if (!mmc)
+   return CMD_RET_FAILURE;
+
+   if (IS_SD(mmc)) {
+   puts("PARTITION_CONFIG only exists on eMMC\n");
+   return CMD_RET_FAILURE;
+   }
+
+   if (mmc->part_config == MMCPART_NOAVAILABLE) {
+   printf("No part_config info for ver. 0x%x\n", mmc->version);
+   return CMD_RET_FAILURE;
+   }
+
+   part_emmc = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
+   part_args = simple_strtoul(argv[2], NULL, 10);
+
+   if (part_emmc == part_args)
+   return CMD_RET_SUCCESS;
+   else
+   return CMD_RET_FAILURE;
+}
+
 static int mmc_partconf_print(struct mmc *mmc)
 {
u8 ack, access, part;
@@ -953,6 +988,7 @@ static struct cmd_tbl cmd_mmc[] = {
 #ifdef CONFIG_SUPPORT_EMMC_BOOT
U_BOOT_CMD_MKENT(bootbus, 5, 0, do_mmc_bootbus, "", ""),
U_BOOT_CMD_MKENT(bootpart-resize, 4, 0, do_mmc_boot_resize, "", ""),
+   U_BOOT_CMD_MKENT(partboot, 3, 0, do_mmc_partboot, "", ""),
U_BOOT_CMD_MKENT(partconf, 5, 0, do_mmc_partconf, "", ""),
U_BOOT_CMD_MKENT(rst-function, 3, 0, do_mmc_rst_func, "", ""),
 #endif
@@ -1021,6 +1057,9 @@ U_BOOT_CMD(
" - Set the BOOT_BUS_WIDTH field of the specified device\n"
"mmc bootpart-resize   \n"
" - Change sizes of boot and RPMB partitions of specified device\n"
+   "mmc partboot dev boot_partition\n"
+   " - Return success if the given boot_partition value matches 
BOOT_PARTITION_ENABLE\n"
+   "   bit field of the specified device\n"
"mmc partconf dev [boot_ack boot_partition partition_access]\n"
" - Show or change the bits of the PARTITION_CONFIG field of the 
specified device\n"
"mmc rst-function dev value\n"
-- 
2.25.1



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

2021-02-12 Thread Giulio Benetti

+Cc Sean

On 2/12/21 2:11 AM, Jesse wrote:

From: Jesse Taube 

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

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


Here it should go what you've listed in cover letter. Changes must be 
listed patch per patch. So here you add:


V1->V2:
...
V2->3:
...

---

Note that lines between triple dashes are ignored when applying patch, 
so that doesn't impact the final result of the patch.



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

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

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


this ^^^ and


+#define IPG_CLK_HF (2 << 6)
+#define IPG_EXT(3 << 6)


this ^^^ have wrong tab number. Check editor settings to tabs=8 spaces.
I use mceditor and there tabs and spaces are highlighted, try to check 
with that for example.



+#define IPG_CLK_32K(4 << 6)
+#define IPG_CLK_24M(5 << 6)


Here ^^^ it would be better to add a prefix like GPT_CLKSRC_ to any 
value. Also, please don't list macros that are not used. So you should 
only define GPT_CLKSRC_IPG_CLK and GPT_CLKSRC_IPG_CLK_24M.



+
+struct imx_gpt_timer_regs {
+   u32 cr;
+   u32 pr;
+   u32 sr;
+   u32 ir;
+   u32 ocr1;
+   u32 ocr2;
+   u32 ocr3;
+   u32 icr1;
+   u32 icr2;
+   u32 cnt;
+};
+
+struct imx_gpt_timer_priv {
+   struct imx_gpt_timer_regs *base;
+};
+
+static u64 imx_gpt_timer_get_count(struct udevice *dev)
+{
+   struct imx_gpt_timer_priv *priv = dev_get_priv(dev);
+   struct imx_gpt_timer_regs *regs = priv->base;
+
+   return readl(>cnt);
+}
+
+u32 imxrt_gpt_setup_ctrl(u32 rate)


imxrt_gpt_ should be imx_gpt_timer_ and must be static since it's private.


+{
+   u32 ctlr = 0;
+
+   if (rate == 2400UL) {
+   ctlr |= IPG_CLK_24M;
+   ctlr |= GPT_CR_EN_24M;


This should be a one line OR. And that way you can remove brackets since 
there are only 1 statement per case.



+   } else {
+   ctlr |= IPG_CLK;
+   }


see above for brackets


+
+   return ctlr;
+}
+
+static int imx_gpt_timer_probe(struct udevice *dev)
+{
+   struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+   struct imx_gpt_timer_priv *priv = dev_get_priv(dev);
+   struct imx_gpt_timer_regs *regs;
+   struct clk clk;
+   fdt_addr_t addr;
+   u32 prescaler;
+   u32 rate;
+   u32 ctlr;
+   int ret;
+
+   addr = dev_read_addr(dev);
+   if (addr == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   priv->base = (struct imx_gpt_timer_regs *)addr;
+
+   ret = clk_get_by_index(dev, 0, );
+   if (ret < 0)
+   return ret;
+
+   ret = clk_enable();
+   if (ret) {
+   dev_err(dev, "Failed to enable clock\n");
+   return ret;
+   }
+
+   regs = priv->base;
+
+   /* Reset the timer */
+   setbits_le32(>cr, GPT_CR_SWR);
+
+   /* Wait for timer to 

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

2021-02-12 Thread Giulio Benetti




On 2/12/21 2:11 AM, Jesse wrote:

From: Jesse Taube 

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

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

  drivers/timer/Kconfig |   7 ++
  drivers/timer/Makefile|   1 +
  drivers/timer/imx-gpt-timer.c | 149 ++
  3 files changed, 157 insertions(+)
  create mode 100644 drivers/timer/imx-gpt-timer.c
---
V1->V2:
* Fixed indentation
* Fixed capitals
* Made timer work on only 24MHz clock
---
---


Don't need these 2 dashes lines, only first and last


V1->V3:


Typo V1(V2)


* Fixed indentation
* Made implementation imatate the Linux kernel
* Fix wrong definition
---



For the rest it seems good :-)

--
Giulio Benetti
Benetti Engineering sas


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

2021-02-12 Thread Giulio Benetti

Hi Jesse,

On 2/12/21 2:29 AM, Jesse T wrote:

I'm very sorry for my email issues I some how mess it up each time.


You can try git send-mail with --to "Jesse T ".
This way you can check the result and only when sure you send to 
everybody and ML.


Kind regards
--
Giulio Benetti
Benetti Engineering sas

On Thu, Feb 11, 2021, 8:11 PM Jesse > wrote:


From: Jesse Taube mailto:mr.bossman...@gmail.com>>

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

Signed-off-by: Giulio Benetti mailto:giulio.bene...@benettiengineering.com>>
Signed-off-by: Jesse Taube mailto:mr.bossman...@gmail.com>>
---
  drivers/timer/Kconfig         |   7 ++
  drivers/timer/Makefile        |   1 +
  drivers/timer/imx-gpt-timer.c | 149 ++
  3 files changed, 157 insertions(+)
  create mode 100644 drivers/timer/imx-gpt-timer.c

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

+config IMX_GPT_TIMER
+       bool "NXP i.MX GPT timer support"
+       depends on TIMER
+       help
+         Select this to enable support for the timer found on
+         NXP i.MX devices.
+
  endmenu
diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
index eb5c48cc6c..e214ba7268 100644
--- a/drivers/timer/Makefile
+++ b/drivers/timer/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_STM32_TIMER)     += stm32_timer.o
  obj-$(CONFIG_X86_TSC_TIMER)    += tsc_timer.o
  obj-$(CONFIG_MTK_TIMER)                += mtk_timer.o
  obj-$(CONFIG_MCHP_PIT64B_TIMER)        += mchp-pit64b-timer.o
+obj-$(CONFIG_IMX_GPT_TIMER)    += imx-gpt-timer.o
diff --git a/drivers/timer/imx-gpt-timer.c
b/drivers/timer/imx-gpt-timer.c
new file mode 100644
index 00..62db6e663a
--- /dev/null
+++ b/drivers/timer/imx-gpt-timer.c
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020
+ * Author(s): Giulio Benetti mailto:giulio.bene...@benettiengineering.com>>
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define GPT_CR_SWR             0x8000
+#define GPT_CR_CLKSRC          0x01C0
+#define GPT_CR_EN_24M          0x0400
+#define GPT_CR_EN              0x0001
+#define GPT_PR_PRESCALER       0x0FFF
+#define GPT_PR_PRESCALER24M    0xF000
+
+#define NO_CLOCK               (0)
+#define IPG_CLK                        (1 << 6)
+#define IPG_CLK_HF             (2 << 6)
+#define IPG_EXT                        (3 << 6)
+#define IPG_CLK_32K            (4 << 6)
+#define IPG_CLK_24M            (5 << 6)
+
+struct imx_gpt_timer_regs {
+       u32 cr;
+       u32 pr;
+       u32 sr;
+       u32 ir;
+       u32 ocr1;
+       u32 ocr2;
+       u32 ocr3;
+       u32 icr1;
+       u32 icr2;
+       u32 cnt;
+};
+
+struct imx_gpt_timer_priv {
+       struct imx_gpt_timer_regs *base;
+};
+
+static u64 imx_gpt_timer_get_count(struct udevice *dev)
+{
+       struct imx_gpt_timer_priv *priv = dev_get_priv(dev);
+       struct imx_gpt_timer_regs *regs = priv->base;
+
+       return readl(>cnt);
+}
+
+u32 imxrt_gpt_setup_ctrl(u32 rate)
+{
+       u32 ctlr = 0;
+
+       if (rate == 2400UL) {
+               ctlr |= IPG_CLK_24M;
+               ctlr |= GPT_CR_EN_24M;
+       } else {
+               ctlr |= IPG_CLK;
+       }
+
+       return ctlr;
+}
+
+static int imx_gpt_timer_probe(struct udevice *dev)
+{
+       struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+       struct imx_gpt_timer_priv *priv = dev_get_priv(dev);
+       struct imx_gpt_timer_regs *regs;
+       struct clk clk;
+       fdt_addr_t addr;
+       u32 prescaler;
+       u32 rate;
+       u32 ctlr;
+       int ret;
+
+       addr = dev_read_addr(dev);
+       if (addr == FDT_ADDR_T_NONE)
+               return -EINVAL;
+
+       priv->base = (struct imx_gpt_timer_regs *)addr;
+
+       ret = clk_get_by_index(dev, 0, );
+       if (ret < 0)
+               return ret;
+
+       ret = clk_enable();
+       if (ret) {
+               dev_err(dev, "Failed to enable clock\n");
+    

Re: Boot problems imx8mp_evk

2021-02-12 Thread Peter Bergin

Hi Andrey,

On 2021-02-12 09:22, ZHIZHIKIN Andrey wrote:

Hello Peter,
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").
Thanks for the notice! I hadn't seen that. Unfortunately it didn't solve 
it by itself.

  $ 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/lpddr4_pmu_train_2d_dmem_201904.bin 
"$build_dir/lpddr4_pmu_train_2d_dmem.bin"
cp ../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_201904.bin 
"$build_dir/lpddr4_pmu_train_2d_imem.bin"

make O=$build_dir flash.bin ATF_LOAD_ADDR=0x97 -j 16
dd if=$build_dir/flash.bin of=$build_dir/sdcard.img bs=1024 seek=32 conv=notrunc
===i


Looking in to and using your script solved my problem. I'm really unsure 
why. It came down to the conclusion that building inside u-boot source 
base dir gives me the error but when I build outside with -O to make the 
target boots fine. I have not found a good explanation to that.


    $ cd u-boot
    $ 
    $ make imx8mp_evk_defconfig
    $ make flash.bin ATF_LOAD_ADDR=0x97

    This flash.bin programmed to a SD card ends up in "Can't support 
legacy image".


    $ make distclean
    $ mkdir build
    $ 
    $ make O=build imx8mp_evk_defconfig
    $ make O=build flash.bin ATF_LOAD_ADDR=0x97

    This build/flash.bin programmed to SD card boot normally to u-boot 
console.


I will not spent time on searching for this now as I have a way forward.


I guess you're using NXP fork of the U-Boot, and not the mainline one. Commit 
633977d904 Is not present in the mainline tree, and additional DDR output gives 
a hint that you're trying to build NXP fork of U-Boot.


I tested both vanilla and imx-fork but cut'n'pasted the console from 
when I booted nxp. Now I have only worked on vanilla master and I think 
I'll stay there.


Andrey, thanks for sharing your script and workflow. Now I'm on track 
again.


Best regards,
/Peter




RE: Boot problems imx8mp_evk

2021-02-12 Thread 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/lpddr4_pmu_train_2d_dmem_201904.bin 
"$build_dir/lpddr4_pmu_train_2d_dmem.bin"
cp 
../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_201904.bin 
"$build_dir/lpddr4_pmu_train_2d_imem.bin"

make O=$build_dir flash.bin ATF_LOAD_ADDR=0x97 -j 16
dd if=$build_dir/flash.bin of=$build_dir/sdcard.img bs=1024 seek=32 conv=notrunc
===

> 
> When booting on a imx8mp EVK from NXP the console shows me this:
> 
>  U-Boot SPL 2020.04-00033-g633977d904 (Feb 12 2021 - 08:12:50 +0100)

I guess you're using NXP fork of the U-Boot, and not the mainline one. Commit 
633977d904 Is 

Re: [PATCHv5 1/6] common: SCP03 control (enable and provision of keys)

2021-02-12 Thread Jorge Ramirez-Ortiz, Foundries
On 09/02/21, Jorge Ramirez-Ortiz wrote:
> This Trusted Application allows enabling SCP03 as well as provisioning
> the keys on TEE controlled secure element (ie, NXP SE050).
> 
> All the information flowing on buses (ie I2C) between the processor
> and the secure element must be encrypted. Secure elements are
> pre-provisioned with a set of keys known to the user so that the
> secure channel protocol (encryption) can be enforced on the first
> boot. This situation is however unsafe since the keys are publically
> available.
> 
> For example, in the case of the NXP SE050, these keys would be
> available in the OP-TEE source tree [2] and of course in the
> documentation corresponding to the part.
> 
> To address that, users are required to rotate/provision those keys
> (ie, generate new keys and write them in the secure element's
> persistent memory).
> 
> For information on SCP03, check the Global Platform HomePage and
> google for that term [1]
> [1] globalplatform.org
> [2] https://github.com/OP-TEE/optee_os/
> check:
> core/drivers/crypto/se050/adaptors/utils/scp_config.c
>

hi Simon, we added the tests that you asked for. all ok with this
series?

thanks!


> Signed-off-by: Jorge Ramirez-Ortiz 
> Reviewed-by: Simon Glass 
> ---
>  common/Kconfig   |  8 ++
>  common/Makefile  |  1 +
>  common/scp03.c   | 53 
>  include/scp03.h  | 21 ++
>  include/tee/optee_ta_scp03.h | 21 ++
>  5 files changed, 104 insertions(+)
>  create mode 100644 common/scp03.c
>  create mode 100644 include/scp03.h
>  create mode 100644 include/tee/optee_ta_scp03.h
> 
> diff --git a/common/Kconfig b/common/Kconfig
> index 2bb3798f80..482f123534 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -588,6 +588,14 @@ config AVB_BUF_SIZE
>  
>  endif # AVB_VERIFY
>  
> +config SCP03
> + bool "Build SCP03 - Secure Channel Protocol O3 - controls"
> + depends on OPTEE || SANDBOX
> + depends on TEE
> + help
> +   This option allows U-Boot to enable and or provision SCP03 on an OPTEE
> +   controlled Secured Element.
> +
>  config SPL_HASH
>   bool # "Support hashing API (SHA1, SHA256, etc.)"
>   help
> diff --git a/common/Makefile b/common/Makefile
> index daeea67cf2..215b8b26fd 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -137,3 +137,4 @@ obj-$(CONFIG_CMD_LOADB) += xyzModem.o
>  obj-$(CONFIG_$(SPL_TPL_)YMODEM_SUPPORT) += xyzModem.o
>  
>  obj-$(CONFIG_AVB_VERIFY) += avb_verify.o
> +obj-$(CONFIG_SCP03) += scp03.o
> diff --git a/common/scp03.c b/common/scp03.c
> new file mode 100644
> index 00..09ef7b5ba3
> --- /dev/null
> +++ b/common/scp03.c
> @@ -0,0 +1,53 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2021, Foundries.IO
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static int scp03_enable(bool provision)
> +{
> + const struct tee_optee_ta_uuid uuid = PTA_SCP03_UUID;
> + struct tee_open_session_arg session;
> + struct tee_invoke_arg invoke;
> + struct tee_param param;
> + struct udevice *tee = NULL;
> +
> + tee = tee_find_device(tee, NULL, NULL, NULL);
> + if (!tee)
> + return -ENODEV;
> +
> + memset(, 0, sizeof(session));
> + tee_optee_ta_uuid_to_octets(session.uuid, );
> + if (tee_open_session(tee, , 0, NULL))
> + return -ENXIO;
> +
> + memset(, 0, sizeof(param));
> + param.attr = TEE_PARAM_ATTR_TYPE_VALUE_INPUT;
> + param.u.value.a = provision;
> +
> + memset(, 0, sizeof(invoke));
> + invoke.func = PTA_CMD_ENABLE_SCP03;
> + invoke.session = session.session;
> +
> + if (tee_invoke_func(tee, , 1, ))
> + return -EIO;
> +
> + tee_close_session(tee, session.session);
> +
> + return 0;
> +}
> +
> +int tee_enable_scp03(void)
> +{
> + return scp03_enable(false);
> +}
> +
> +int tee_provision_scp03(void)
> +{
> + return scp03_enable(true);
> +}
> diff --git a/include/scp03.h b/include/scp03.h
> new file mode 100644
> index 00..729667ccd1
> --- /dev/null
> +++ b/include/scp03.h
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * (C) Copyright 2021, Foundries.IO
> + *
> + */
> +
> +#ifndef _SCP03_H
> +#define _SCP03_H
> +
> +/*
> + * Requests to OPTEE to enable or provision the Secure Channel Protocol on 
> its
> + * Secure Element
> + *
> + *  If key provisioning is requested, OPTEE shall generate new SCP03 keys and
> + *  write them to the Secure Element.
> + *
> + *  Both functions return < 0 on error else 0.
> + */
> +int tee_enable_scp03(void);
> +int tee_provision_scp03(void);
> +#endif /* _SCP03_H */
> diff --git a/include/tee/optee_ta_scp03.h b/include/tee/optee_ta_scp03.h
> new file mode 100644
> index 00..13f9956d98
> --- /dev/null
> +++ b/include/tee/optee_ta_scp03.h
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: BSD-3-Clause */
> +/*
> + * (C) 

Re: Boot problems imx8mp_evk

2021-02-12 Thread Peter Bergin

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://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.

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
    $ make imx8mp_evk_defconfig
    $ make flash.bin
    $ sudo dd if=flash.bin of=/dev/mmcblk0 bs=1024 seek=32

When booting on a imx8mp EVK from NXP the console shows me this:

    U-Boot SPL 2020.04-00033-g633977d904 (Feb 12 2021 - 08:12:50 +0100)
    DDRINFO: start DRAM init
    DDRINFO: DRAM rate 4000MTS
    DDRINFO:ddrphy calibration done
    DDRINFO: ddrmix config done
    Normal Boot
    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 ###

The code that fails is in arch/arm/mach-imx/spl_imx_romapi.c

    if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
        image_get_magic(header) == FDT_MAGIC) {
    
    } else {
        /* TODO */
        puts("Can't support legacy image\n");
        return -1;
    }

I have traced out 'image_get_magic(header)' on the console and it is a 
new random value at each power on. I can also note that I have tested 
branch imx_v2020.04_5.4.70_2.3.0 from from uboot-imx ending up in the 
same result on the console.


Anyone that have ideas here how to proceed and where the problem can be? 
Anyone with a imx8mp EVK on the desk that succeed with building and 
deploying u-boot on a SD card and can share the workflow?


Best regards,
/Peter