Re: [PATCH] ARM: imx: imx8mn-ddr4-evk: Add ethernet support

2021-02-26 Thread Jagan Teki
Hi Marek,

On Sat, Feb 27, 2021 at 3:44 AM Marek Vasut  wrote:
>
> Add support for ethernet on the imx8mn-ddr4-evk.
>
> Signed-off-by: Marek Vasut 
> Cc: Fabio Estevam 
> Cc: Peng Fan 
> Cc: Stefano Babic 
> ---
>  arch/arm/dts/imx8mn-evk.dtsi|  1 +
>  board/freescale/imx8mn_evk/imx8mn_evk.c | 41 +++--
>  configs/imx8mn_ddr4_evk_defconfig   |  8 +
>  3 files changed, 47 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/dts/imx8mn-evk.dtsi b/arch/arm/dts/imx8mn-evk.dtsi
> index 76d042a4cf0..416fadb22b1 100644
> --- a/arch/arm/dts/imx8mn-evk.dtsi
> +++ b/arch/arm/dts/imx8mn-evk.dtsi
> @@ -53,6 +53,7 @@
> pinctrl-0 = <_fec1>;
> phy-mode = "rgmii-id";
> phy-handle = <>;
> +   phy-reset-gpios = < 22 GPIO_ACTIVE_LOW>;

I believe this is phy reset-gpio to be part of mdio child node. any
idea why it added in fec1 node?

Jagan.


Re: [EXT] [PATCH] ARM: imx: Add OCRAM_S into iMX8M MMU tables

2021-02-26 Thread Ye Li
Hi Marek,

On Fri, 2021-02-26 at 13:44 +0100, Marek Vasut wrote:
> Caution: EXT Email
> 
> On 2/26/21 8:15 AM, Ye Li wrote:
> > 
> > Hi Marek,
> > 
> > On Thu, 2021-02-25 at 21:52 +0100, Marek Vasut wrote:
> > > 
> > > Caution: EXT Email
> > > 
> > > The OCRAM_S is regular memory, just like the OCRAM, add it to the
> > > MMU
> > > tables so it can be used and cached.
> > > 
> > > Signed-off-by: Marek Vasut 
> > > Cc: Fabio Estevam 
> > > Cc: Peng Fan 
> > > Cc: Stefano Babic 
> > > ---
> > >   arch/arm/mach-imx/imx8m/soc.c | 7 +++
> > >   1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-
> > > imx/imx8m/soc.c
> > > index 5456c10fb17..225e4e12500 100644
> > > --- a/arch/arm/mach-imx/imx8m/soc.c
> > > +++ b/arch/arm/mach-imx/imx8m/soc.c
> > > @@ -104,6 +104,13 @@ static struct mm_region imx8m_mem_map[] = {
> > >  .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> > >   PTE_BLOCK_NON_SHARE |
> > >   PTE_BLOCK_PXN | PTE_BLOCK_UXN
> > > +   }, {
> > > +   /* OCRAM_S */
> > > +   .virt = 0x18UL,
> > > +   .phys = 0x18UL,
> > > +   .size = 0x8000UL,
> > > +   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> > > +PTE_BLOCK_OUTER_SHARE
> > >  }, {
> > >  /* TCM */
> > >  .virt = 0x7CUL,
> > > --
> > > 2.30.0
> > > 
> > OCRAM_S is used by ATF and SPL to pass DDR CSR data.
> Where is this implemented ?

See below definition in drivers/ddr/imx/imx8m/Kconfig

config SAVED_DRAM_TIMING_BASE
hex "Define the base address for saved dram timing"
help
  after DRAM is trained, need to save the dram related timming
  info into memory for low power use. OCRAM_S is used for this
  purpose on i.MX8MM.
default 0x18
> 
> > 
> > It is better not
> > use it in u-boot to avoid any DDR issue.
> The MMU table entry does not trigger any IO to the OCRAM_S , it
> merely
> makes it cacheable .
> 
That's fine to add a map, just remind to use it carefully since it
already used by ATF.

> > 
> > And this imx8m_mem_map will be modified at runtime to get rid of
> > optee
> > memory. When OCRAM_S is added, the index used in enable_caches and
> > dram_init need update as well.
> I'm not sure I understand this. What kind of modification are you
> talking about ? The DRAM entry offset should be determined
> automatically, so there shouldn't be any need to hand-tune ad-hoc
> offsets.

You also need below change, the index for DRAM1 is used in codes to
help remove the OPTEE space from MMU table.

--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -167,10 +167,10 @@ void enable_caches(void)
 * please make sure that entry initial value matches
 * imx8m_mem_map for DRAM1
 */
-   int entry = 5;
+   int entry = 6;
u64 attrs = imx8m_mem_map[entry].attrs;
 
-   while (i < CONFIG_NR_DRAM_BANKS && entry < 8) {
+   while (i < CONFIG_NR_DRAM_BANKS && entry < 9) {
if (gd->bd->bi_dram[i].start == 0)
break;
imx8m_mem_map[entry].phys = gd->bd-
>bi_dram[i].start;
@@ -212,7 +212,7 @@ int dram_init(void)
gd->ram_size = sdram_size;
 
/* also update the SDRAM size in the mem_map used externally */
-   imx8m_mem_map[5].size = sdram_size;
+   imx8m_mem_map[6].size = sdram_size;
 
 #ifdef PHYS_SDRAM_2_SIZE
gd->ram_size += PHYS_SDRAM_2_SIZE;

Best regards,
Ye Li

Re: [EXT] Re: [PATCH 4/4] imx8mq_evk: Enable the USB3.0 host port

2021-02-26 Thread Ye Li
Hi Fabio,

On Thu, 2021-02-25 at 10:49 -0300, Fabio Estevam wrote:
> Caution: EXT Email
> 
> Hi Ye Li,
> 
> On Thu, Feb 25, 2021 at 10:34 AM Ye Li  wrote:
> 
> > 
> > Sure, I have tested it on 8mq evk. I can reproduce the two issues
> > you
> > met.
> > The first issue is caused by the ALIGN. The implementation of
> > standard
> > ALIGN requires the aligned size to be power of 2. But the ALIGN in
> > imx8mimage does not have this requirement. So below result is wrong
> > by
> > using the standard ALIGN. Your fix should be OK for this issue.
> Good, could you please reply to my ALIGN macro patch with your
> Tested-by tag then?
> 
Replied it.

> > 
> > For the second issue, I did not debug into it. But our vendor tree
> > also
> > uses off-on-delay-us in both u-boot and kernel. So it is likely
> > caused
> > by other change.
> Considering we are already at 2021.04-rc2, I think it would be safer
> to go with my patch that removes off-on-delay-us.
> 
> What do you think?
> 
> Thanks
My debug shows the issue is triggered by below commit:

commit 9098682200e6cca4b776638a51200dafa16f50fb
Author: Haibo Chen 
Date:   Tue Sep 22 18:11:43 2020 +0800

mmc: fsl_esdhc_imx: remove the 1ms delay before sending command

This 1ms delay before sending command already exist from the
beginning
of the fsl_esdhc driver added in year 2008. Now this driver has
been
split for two files: fsl_esdhc.c and fsl_esdhc_imx.c.
fsl_esdhc_imx.c
only for i.MX series. i.MX series esdhc/usdhc do not need this 1ms
delay
before sending any command. So remove this 1ms, this will save a
lot
time if handling a large mmc data.

Signed-off-by: Haibo Chen 


The first "go idle" command in mmc_get_op_cond seems not put SD card to
idle status, but if adding a delay before it (like 1ms delay), then
everything works. This commit removed 1ms delay in sending command, so
the issue is triggered.  The root cause might be "startup-delay-us"
needed for this regulator to reach a threshold voltage for SD working.
Below change also can fix the issue.

--- a/arch/arm/dts/imx8mq-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mq-evk-u-boot.dtsi
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: (GPL-2.0 OR MIT)
 
 _usdhc2_vmmc {
+       startup-delay-us = <1000>;
u-boot,off-on-delay-us = <2>;
 };


@Haibo, Could you help looking into the issue. What's your opinion to
add the startup-delay-us or revert your commit?

Best regards,
Ye Li

Pull request for efi-2021-04-rc3-2

2021-02-26 Thread Heinrich Schuchardt

Dear Tom,

The following changes since commit c28d5d704d3347fcbe5e49ab561973c00bf9337f:

  Merge branch '2021-02-25-remove-platforms' (2021-02-25 13:18:27 -0500)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
tags/efi-2021-04-rc3-2

for you to fetch changes up to a2c3f1bca4bf21371d041d1de589039aa3459e91:

  cmd/efidebug: add firmware management protocol GUID (2021-02-26
16:17:43 +0100)

Gitlab CI reported no issues:
https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/6536


Pull request for efi-2021-04-rc3-2

Bug fixes:
* debug build for mkeficapsule
* limit output length for VenHw, VenMedia
* ACPI tables must be in EfiACPIReclaimMemory


Heinrich Schuchardt (5):
  efi_loader: ACPI tables must be in EfiACPIReclaimMemory
  MAINTAINERS: assign tools/mkeficapsule.c to EFI PAYLOAD
  efi_loader: limit output length for VenHw, VenMedia
  efi_loader: fix documentation in efi_loader.h
  cmd/efidebug: add firmware management protocol GUID

Klaus Heinrich Kiwi (1):
  tools/mkeficapsule.c: fix DEBUG build

 MAINTAINERS  |  1 +
 cmd/efidebug.c   |  4 
 include/efi_loader.h | 20 +---
 lib/efi_loader/efi_acpi.c|  3 +--
 lib/efi_loader/efi_device_path_to_text.c |  6 --
 tools/mkeficapsule.c |  2 +-
 6 files changed, 24 insertions(+), 12 deletions(-)


[PATCH 1/1] cmd/efidebug: add firmware management protocol GUID

2021-02-26 Thread Heinrich Schuchardt
Add missing GUID short text used in the efidebug tables and efidebug dh
sub-commands.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/efidebug.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index bbbcb0a546..e4030f514a 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -507,6 +507,10 @@ static const struct {
"System Partition",
PARTITION_SYSTEM_GUID
},
+   {
+   "Firmware Management",
+   EFI_FIRMWARE_MANAGEMENT_PROTOCOL_GUID
+   },
/* Configuration table GUIDs */
{
"ACPI table",
--
2.30.0



Re: [PATCH v2 1/3] cmd: mvebu: Implement the Marvell hw_info command

2021-02-26 Thread Pali Rohár
On Monday 15 February 2021 20:59:32 Luka Kovacic wrote:
> The hw_info command is implemented to enable parsing Marvell hw_info
> formatted environments. This format is often used on Marvell Armada A37XX
> based devices to store parameters like the board serial number, factory
> MAC addresses and some other information.
> These parameters are usually written to the flash in the factory.

CCing Marek, as he does not like introduction of another vendor custom
command into mainline U-Boot.

> Currently the command supports reading/writing parameters and dumping the
> current hw_info parameters.
> EEPROM config pattern and checksum aren't supported.
> 
> This functionality has been tested on the GST ESPRESSOBin-Ultra board
> successfully, both reading the stock U-Boot parameters in mainline U-Boot
> and reading the parameters written by this command in the stock U-Boot.
> 
> Usage example:
>  => hw_info load
>  => saveenv

I'm looking at the code and it loads MAC addresses for espressobin
ultra variant. But for other espressobin variants there is already code
which sets correct eth*addr and fdtfile variables in board_late_init()
function.

I think it should be relatively easy to implement reading these
variables from SPI to ENV in board_late_init() function. Which would
mean that it completely replaces this custom 'hw_info load' command.

Could you look at it? This would have a benefit that 'env default -a'
would always load correct mac addresses stored in SPI, so it would work
just via default u-boot commands without need to use something vendor
specific.

> Signed-off-by: Luka Kovacic 
> Cc: Luka Perkov 
> Cc: Robert Marko 
> Reviewed-by: Tom Rini 
> ---
>  cmd/mvebu/Kconfig   |  23 
>  cmd/mvebu/Makefile  |   1 +
>  cmd/mvebu/hw_info.c | 312 
>  lib/hashtable.c |   2 +-
>  4 files changed, 337 insertions(+), 1 deletion(-)
>  create mode 100644 cmd/mvebu/hw_info.c
> 
> diff --git a/cmd/mvebu/Kconfig b/cmd/mvebu/Kconfig
> index ad10a572a3..a8e958e7c8 100644
> --- a/cmd/mvebu/Kconfig
> +++ b/cmd/mvebu/Kconfig
> @@ -9,6 +9,29 @@ config CMD_MVEBU_BUBT
> For details about bubt command please see the documentation
> in doc/mvebu/cmd/bubt.txt
>  
> +config CMD_MVEBU_HW_INFO
> + bool "hw_info"
> + depends on SPI_FLASH && ENV_IS_IN_SPI_FLASH && ARCH_MVEBU
> + default n
> + help
> +   Enable loading of the Marvell hw_info parameters from the
> +   SPI flash hw_info area. Parameters (usually the board serial
> +   number and MAC addresses) are then imported into the
> +   existing U-Boot environment.
> +   Implementation of this command is compatible with the
> +   original Marvell U-Boot command. Reading and writing is
> +   supported.
> +   EEPROM config pattern and checksum aren't supported.
> +
> +config CMD_MVEBU_HW_INFO_OFFSET
> + hex "Marvell hw_info SPI flash offset"
> + depends on CMD_MVEBU_HW_INFO
> + default 0x3E
> + help
> +   This option defines the SPI flash offset of the Marvell
> +   hw_info area. This defaults to 0x3E on most Armada
> +   A3720 platforms.
> +
>  choice
>   prompt "Flash for image"
>   default MVEBU_SPI_BOOT
> diff --git a/cmd/mvebu/Makefile b/cmd/mvebu/Makefile
> index 96829c48eb..2b5a8b37be 100644
> --- a/cmd/mvebu/Makefile
> +++ b/cmd/mvebu/Makefile
> @@ -6,3 +6,4 @@
>  
>  
>  obj-$(CONFIG_CMD_MVEBU_BUBT) += bubt.o
> +obj-$(CONFIG_CMD_MVEBU_HW_INFO) += hw_info.o
> diff --git a/cmd/mvebu/hw_info.c b/cmd/mvebu/hw_info.c
> new file mode 100644
> index 00..1ef49d78d4
> --- /dev/null
> +++ b/cmd/mvebu/hw_info.c
> @@ -0,0 +1,312 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Marvell hw_info command
> + * Helper command for interfacing with the Marvell hw_info parameters
> + *
> + * Copyright (c) 2021 Sartura Ltd.
> + * Copyright (c) 2018 Marvell International Ltd.
> + *
> + * Author: Luka Kovacic 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define HW_INFO_SPI_FLASH_OFFSET CONFIG_CMD_MVEBU_HW_INFO_OFFSET
> +
> +#define HW_INFO_MAX_ENV_SIZE 0x1F0
> +#define HW_INFO_ENV_OFFSET   0xA
> +#define HW_INFO_ENV_SEP  0x20
> +
> +#define HW_INFO_MAX_NAME_LEN 32
> +
> +static char hw_info_allowed_parameters[][HW_INFO_MAX_NAME_LEN] = {
> + "pcb_slm",
> + "pcb_rev",
> + "eco_rev",
> + "pcb_sn",
> + "ethaddr",
> + "eth1addr",
> + "eth2addr",
> + "eth3addr",
> + "eth4addr",
> + "eth5addr",
> + "eth6addr",
> + "eth7addr",
> + "eth8addr",
> + "eth9addr",
> +};
> +
> +static int hw_info_allowed_param_count = (sizeof(hw_info_allowed_parameters) 
> /
> + sizeof(hw_info_allowed_parameters[0]));
> +
> +static int hw_info_check_parameter(char *name)
> +{
> + int idx;
> +
> + for (idx = 0; idx < hw_info_allowed_param_count; idx++) {
> +

Re: [PATCH 3/5] Azure/GitLab: Ensure we use requirements.txt for testsuites

2021-02-26 Thread Bin Meng
On Fri, Feb 26, 2021 at 10:31 PM Tom Rini  wrote:
>
> On Fri, Feb 26, 2021 at 10:25:30PM +0800, Bin Meng wrote:
> > On Fri, Feb 26, 2021 at 8:53 PM Tom Rini  wrote:
> > >
> > > Given that test/py/requirements.txt has all required test modules, make
> > > use of that rather than a manual pip install list before running our
> > > assorted tool testsuites.
> > >
> > > Signed-off-by: Tom Rini 
> > > ---
> > >  .azure-pipelines.yml | 2 +-
> > >  .gitlab-ci.yml   | 2 +-
> > >  2 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> > > index a6279427e138..0a4f90f75f3b 100644
> > > --- a/.azure-pipelines.yml
> > > +++ b/.azure-pipelines.yml
> > > @@ -144,7 +144,7 @@ jobs:
> > >export USER=azure
> > >virtualenv -p /usr/bin/python3 /tmp/venv
> > >. /tmp/venv/bin/activate
> > > -  pip install pyelftools pytest pygit2
> > > +  pip install -r test/py/requirements.txt
> >
> > It seems only pytest is listed in test/py/requirements.txt?
>
> Not since:
> commit f4a60b036308ca4a0a3ad08587b7f9b72d3565d5
> Author: Igor Opaniuk 
> Date:   Mon Jan 25 14:28:41 2021 +0200
>
> test: py: add pygit2 and pyelftools to requirements.txt

Ah, yes! Was looking at an old branch.

Reviewed-by: Bin Meng 


Re: [PATCH v2 3/3] arm: mvebu: Initial ESPRESSOBin-Ultra board support

2021-02-26 Thread Pali Rohár
On Monday 15 February 2021 20:59:34 Luka Kovacic wrote:
> Add initial support for the ESPRESSOBin-Ultra board from Globalscale
> Technologies, Inc.
> 
> The board is based on the 64-bit dual-core Marvell Armada 3720 SoC.
> Peripherals:
>  - 5 Gigabit Ethernet ports (WAN has PoE, up to 30W, Topaz 6341 switch)
>  - RTC clock (PCF8563)
>  - USB 3.0 port
>  - USB 2.0 port
>  - 4x LED
>  - UART over Micro-USB
>  - M.2 slot (2280)
>  - Mini PCI-E slot
> 
> Additionally, automatic import of the Marvell hw_info parameters is
> enabled via the recently added hw_info command.
> The parameters stored in Marvell hw_info are usually the board serial
> number and MAC addresses.

Hello Luka!

Few months ago I have de-duplicated all existing espressobin setups
supported in uboot to use just one DTS file and one defconfig file and
do board detection at runtime.

So I do not think it is a good idea to again define another espressobin
DTS and defconfig file.

Linux kernel also is using one common DTS file for all espressobin
boards (including ultra variant).

So could you please try to rework this patch to use existing files
armada-3720-espressobin.dts and mvebu_espressobin-88f3720_defconfig
(with probably some board code which detects for ultra variant)?

> Signed-off-by: Luka Kovacic 
> Cc: Luka Perkov 
> Cc: Robert Marko 
> ---
>  arch/arm/dts/Makefile |   1 +
>  .../arm/dts/armada-3720-espressobin-ultra.dts | 202 ++
>  board/Marvell/mvebu_armada-37xx/MAINTAINERS   |   8 +
>  board/Marvell/mvebu_armada-37xx/board.c   |  92 +++-
>  .../mvebu_espressobin-ultra-88f3720_defconfig |  92 
>  5 files changed, 389 insertions(+), 6 deletions(-)
>  create mode 100644 arch/arm/dts/armada-3720-espressobin-ultra.dts
>  create mode 100644 configs/mvebu_espressobin-ultra-88f3720_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 33e483f4fb..9f544b1caf 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -208,6 +208,7 @@ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
>  dtb-$(CONFIG_ARCH_MVEBU) +=  \
>   armada-3720-db.dtb  \
>   armada-3720-espressobin.dtb \
> + armada-3720-espressobin-ultra.dtb   \
>   armada-3720-turris-mox.dtb  \
>   armada-3720-uDPU.dtb\
>   armada-375-db.dtb   \
> diff --git a/arch/arm/dts/armada-3720-espressobin-ultra.dts 
> b/arch/arm/dts/armada-3720-espressobin-ultra.dts
> new file mode 100644
> index 00..70f97fe239
> --- /dev/null
> +++ b/arch/arm/dts/armada-3720-espressobin-ultra.dts
> @@ -0,0 +1,202 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Device Tree file for ESPRESSObin-Ultra board
> + * Copyright (C) 2016 Marvell
> + * Copyright (C) 2019 Globalscale technologies, Inc.
> + * Copyright (C) 2020 Sartura Ltd.
> + *
> + * Author: Jason Hung 
> + * Author: Luka Kovacic 
> + * Author: Vladimir Vid 
> + */
> +
> +/dts-v1/;
> +
> +#include "armada-372x.dtsi"
> +
> +/ {
> + model = "Globalscale Marvell ESPRESSOBin Ultra Board";
> + compatible = "globalscale,espressobin-ultra", "marvell,armada3720", 
> "marvell,armada3710";
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + aliases {
> + ethernet0 = 
> + i2c0 = 
> + spi0 = 
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x 0x 0x 0x2000>;
> + };
> +
> + vcc_sd_reg0: regulator@0 {
> + compatible = "regulator-gpio";
> + regulator-name = "vcc_sd0";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> + regulator-type = "voltage";
> + states = <180 0x1
> +   330 0x0>;
> + gpios = < 4 GPIO_ACTIVE_HIGH>;
> + };
> +
> + gpio-leds {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>, <_pins>, <_pins>, 
> <_pins>;
> + compatible = "gpio-leds";
> +
> + led1 {
> + label = "led1";
> + gpios = < 11 GPIO_ACTIVE_LOW>;
> + default-state = "on";
> + };
> + led2 {
> + label = "led2";
> + gpios = < 12 GPIO_ACTIVE_LOW>;
> + default-state = "on";
> + };
> + led3 {
> + label = "led3";
> + gpios = < 13 GPIO_ACTIVE_LOW>;
> + default-state = "on";
> + };
> + led4 {
> + label = "led4";
> + gpios = < 14 GPIO_ACTIVE_LOW>;
> + default-state = "on";
> + };
> + };
> +};
> +
> +_nb {
> + led1_pins: led1-pins {
> + groups = "pwm0";

Re: [PATCH v2 2/3] arm: mvebu: mvebu_armada-37xx: Define the loadaddr environment variable

2021-02-26 Thread Pali Rohár
On Monday 15 February 2021 20:59:33 Luka Kovacic wrote:
> Add the loadaddr U-Boot environment variable, as this is available in
> the stock Marvell U-Boot by default on Marvell Armada A37XX platforms.

Hello Luka! Why is this change needed? mvebu_armada-37xx.h already
defines CONFIG_SYS_LOAD_ADDR macro with its default value 0x0600.
So defining loadaddr variable should not be needed at all. And it is
suspicious for me why definition is to the same default value.

> Signed-off-by: Luka Kovacic 
> Cc: Luka Perkov 
> Cc: Robert Marko 
> ---
>  include/configs/mvebu_armada-37xx.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/configs/mvebu_armada-37xx.h 
> b/include/configs/mvebu_armada-37xx.h
> index 2ad4325eaf..1041df8d91 100644
> --- a/include/configs/mvebu_armada-37xx.h
> +++ b/include/configs/mvebu_armada-37xx.h
> @@ -103,6 +103,7 @@
>  
>  /* fdt_addr and kernel_addr are needed for existing distribution boot 
> scripts */
>  #define CONFIG_EXTRA_ENV_SETTINGS\
> + "loadaddr=0x600\0"  \
>   "scriptaddr=0x6d0\0"\
>   "pxefile_addr_r=0x6e0\0"\
>   "fdt_addr=0x6f0\0"  \


Re: [PULL] u-boot-usb/master

2021-02-26 Thread Tom Rini
On Fri, Feb 26, 2021 at 06:56:18PM +0100, Marek Vasut wrote:

> The following changes since commit c28d5d704d3347fcbe5e49ab561973c00bf9337f:
> 
>   Merge branch '2021-02-25-remove-platforms' (2021-02-25 13:18:27 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to 0a7e5e5f103867789328067f87e34b25b26fc3b0:
> 
>   usb: gadget: dwc2_udc_otg: Fix dwc2_gadget_start() and
> usb_gadget_register_driver() (2021-02-26 15:30:55 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH] ARM: imx: imx8mn-ddr4-evk: Add ethernet support

2021-02-26 Thread Marek Vasut
Add support for ethernet on the imx8mn-ddr4-evk.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
---
 arch/arm/dts/imx8mn-evk.dtsi|  1 +
 board/freescale/imx8mn_evk/imx8mn_evk.c | 41 +++--
 configs/imx8mn_ddr4_evk_defconfig   |  8 +
 3 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/imx8mn-evk.dtsi b/arch/arm/dts/imx8mn-evk.dtsi
index 76d042a4cf0..416fadb22b1 100644
--- a/arch/arm/dts/imx8mn-evk.dtsi
+++ b/arch/arm/dts/imx8mn-evk.dtsi
@@ -53,6 +53,7 @@
pinctrl-0 = <_fec1>;
phy-mode = "rgmii-id";
phy-handle = <>;
+   phy-reset-gpios = < 22 GPIO_ACTIVE_LOW>;
fsl,magic-packet;
status = "okay";
 
diff --git a/board/freescale/imx8mn_evk/imx8mn_evk.c 
b/board/freescale/imx8mn_evk/imx8mn_evk.c
index 9a0a0488bf4..8c4bb6c5b8e 100644
--- a/board/freescale/imx8mn_evk/imx8mn_evk.c
+++ b/board/freescale/imx8mn_evk/imx8mn_evk.c
@@ -6,18 +6,53 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
-int board_init(void)
+int board_mmc_get_env_dev(int devno)
+{
+   return devno;
+}
+
+#if IS_ENABLED(CONFIG_FEC_MXC)
+static int setup_fec(void)
 {
+   struct iomuxc_gpr_base_regs *gpr =
+   (struct iomuxc_gpr_base_regs *)IOMUXC_GPR_BASE_ADDR;
+
+   /* Use 125M anatop REF_CLK1 for ENET1, not from external */
+   clrsetbits_le32(>gpr[1], 0x2000, 0);
+
return 0;
 }
 
-int board_mmc_get_env_dev(int devno)
+int board_phy_config(struct phy_device *phydev)
 {
-   return devno;
+   /* enable rgmii rxc skew and phy mode select to RGMII copper */
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x1f);
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x8);
+
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x00);
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x82ee);
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05);
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x100);
+
+   if (phydev->drv->config)
+   phydev->drv->config(phydev);
+   return 0;
+}
+#endif
+
+int board_init(void)
+{
+   if (IS_ENABLED(CONFIG_FEC_MXC))
+   setup_fec();
+
+   return 0;
 }
 
 int board_late_init(void)
diff --git a/configs/imx8mn_ddr4_evk_defconfig 
b/configs/imx8mn_ddr4_evk_defconfig
index f7ea65886d5..c9a00bf2c2f 100644
--- a/configs/imx8mn_ddr4_evk_defconfig
+++ b/configs/imx8mn_ddr4_evk_defconfig
@@ -43,6 +43,9 @@ CONFIG_CMD_FUSE=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_REGULATOR=y
 CONFIG_CMD_EXT2=y
@@ -71,7 +74,12 @@ CONFIG_MMC_HS400_ES_SUPPORT=y
 CONFIG_MMC_HS400_SUPPORT=y
 CONFIG_FSL_ESDHC_IMX=y
 CONFIG_PHYLIB=y
+CONFIG_PHY_ATHEROS=y
 CONFIG_DM_ETH=y
+CONFIG_DM_ETH_PHY=y
+CONFIG_PHY_GIGE=y
+CONFIG_FEC_MXC=y
+CONFIG_MII=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
 CONFIG_PINCTRL_IMX8M=y
-- 
2.30.0



Re: [PATCH] rk3399: Add basic support for helios64

2021-02-26 Thread Uwe Kleine-König

Hi Peter,

On 2/26/21 3:56 PM, Peter Robinson wrote:

On Fri, Feb 26, 2021 at 1:45 PM Uwe Kleine-König  wrote:

On 2/26/21 12:23 AM, Dennis Gilmore wrote:

Thanks for submitting, I have been meaning to do so myself, I have
been meaning to go through and try get the dts files in a decent
shape. I think that most of what is in
arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi  belongs in
arch/arm/dts/rk3399-kobol-helios64.dts


I understood that the intention of the separation into two files is that
the one should track the Linux dts. Is that wrong?


No, that's correct, but it should also likely then be submitted for
upstream Linux inclusion.


Yeah, that's the eventual plan. For now I want to get a booting system 
into Debian and so several interfaces are not included. After that I 
intend to improve the support in both Linux and U-Boot.


Best regards
Uwe



OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH] arm64: rk3399: Add support NanoPi R4s

2021-02-26 Thread Patrick Wildt
Am Fri, Feb 26, 2021 at 09:37:58PM +0100 schrieb Patrick Wildt:
> Am Mon, Feb 08, 2021 at 04:56:35PM +0800 schrieb xiaobo:
> > From: Xiaobo Tian 
> > 
> > NanoPi R4s is SBC base on Rockchip RK3399 hexa-core processor with
> > dual-Core Cortex-A72 and Mali-T864 GPU with 4GiB(LPDDR4) of RAM, SD card 
> > support,
> > including 2 gigabit ethernet(RTL8211E 1Gbps - RTL8111H 1Gbps) and 2 USB 3.0 
> > port.
> > port.It also has two GPIO headers which allows further peripherals to be 
> > used.
> > 
> > The devicetree file is taken of the rk3399 nanopi4 Linux kernel [1].
> > 
> > [1] 
> > https://github.com/torvalds/linux/commit/e7a095908227fb3ccc86d001d9e13c9ae2bef8e6
> > 
> > Signed-off-by: xiaobo 
> > ---
> >  arch/arm/dts/Makefile  |   1 +
> >  arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi |  17 +++
> >  arch/arm/dts/rk3399-nanopi-r4s.dts | 138 +
> >  board/rockchip/evb_rk3399/MAINTAINERS  |   6 +
> >  configs/nanopi-r4s-rk3399_defconfig|  62 +
> >  5 files changed, 224 insertions(+)
> >  create mode 100644 arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
> >  create mode 100644 arch/arm/dts/rk3399-nanopi-r4s.dts
> >  create mode 100644 configs/nanopi-r4s-rk3399_defconfig
> > 
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 858b79ac97..528dfe069e 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -92,6 +92,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3288) += \
> > rk3288-evb.dtb \
> > rk3288-firefly.dtb \
> > rk3288-miqi.dtb \
> > +   rk3399-nanopi-r4s.dtb \
> 
> This is in the wrong list.  You need to put it into the RK3399 list, not
> RK3288.
> 
> > rk3288-phycore-rdk.dtb \
> > rk3288-popmetal.dtb \
> > rk3288-rock2-square.dtb \
> > diff --git a/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi 
> > b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
> > new file mode 100644
> > index 00..3f97867cc5
> > --- /dev/null
> > +++ b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
> > @@ -0,0 +1,17 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * RK3399-based FriendlyElec boards device tree source
> > + *
> > + * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
> > + *
> > + * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
> > + * (http://www.friendlyarm.com)
> > + *
> > + * Copyright (c) 2018 Collabora Ltd.
> > + * Copyright (c) 2019 Arm Ltd.
> > + * Copyright (C) 2020 Xiaobo 
> > + */
> > +
> > +#include "rk3399-nanopi4-u-boot.dtsi"
> > +#include "rk3399-sdram-lpddr4-100.dtsi"
> > +#include "rk3399-sdram-ddr3-1866.dtsi"
> 
> This is wrong as well.  I think there can only be lpddr4 *or* ddr3.  I
> think the last one has precedence.  I have a 4G machine, and it doesn't
> work with this.  If I remove the ddr3 (since 4G machine has lpddr4),
> it works.
> 
> > diff --git a/arch/arm/dts/rk3399-nanopi-r4s.dts 
> > b/arch/arm/dts/rk3399-nanopi-r4s.dts
> > new file mode 100644
> > index 00..6f2cf17bf1
> > --- /dev/null
> > +++ b/arch/arm/dts/rk3399-nanopi-r4s.dts
> > @@ -0,0 +1,138 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
> > + *
> > + * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
> > + * (http://www.friendlyarm.com)
> > + *
> > + * Copyright (c) 2018 Collabora Ltd.
> > + * Copyright (c) 2019 Arm Ltd.
> > + * Copyright (C) 2020 Xiaobo 
> > + */
> > +
> > +/dts-v1/;
> > +#include "rk3399-nanopi4.dtsi"
> > +
> > +/ {
> > +   model = "FriendlyElec NanoPi R4S";
> > +   compatible = "friendlyarm,nanopi-r4s", "rockchip,rk3399";
> > +
> > +   aliases {
> > +   ethernet1 = 
> > +   };
> > +
> > +   vdd_5v: vdd-5v {
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "vdd_5v";
> > +   regulator-always-on;
> > +   regulator-boot-on;
> > +   };
> > +
> > +   fan: pwm-fan {
> > +   compatible = "pwm-fan";
> > +   cooling-levels = <0 12 18 255>;
> > +   #cooling-cells = <2>;
> > +   fan-supply = <_5v>;
> > +   pwms = < 0 5 0>;
> > +   };
> > +};
> > +
> > +_thermal {
> > +   trips {
> > +   cpu_warm: cpu_warm {
> > +   temperature = <55000>;
> > +   hysteresis = <2000>;
> > +   type = "active";
> > +   };
> > +
> > +   cpu_hot: cpu_hot {
> > +   temperature = <65000>;
> > +   hysteresis = <2000>;
> > +   type = "active";
> > +   };
> > +   };
> > +
> > +   cooling-maps {
> > +   map2 {
> > +   trip = <_warm>;
> > +   cooling-device = < THERMAL_NO_LIMIT 1>;
> > +   };
> > +
> > +   map3 {
> > +   trip = <_hot>;
> > +   cooling-device = < 2 THERMAL_NO_LIMIT>;
> > +   };
> > +   };
> > +};
> > +
> > +_phy {
> > +   status = "disabled";
> > +};
> > +
> > + {
> > +   status = 

Re: [PATCH] arm64: rk3399: Add support NanoPi R4s

2021-02-26 Thread Patrick Wildt
Am Mon, Feb 08, 2021 at 04:56:35PM +0800 schrieb xiaobo:
> From: Xiaobo Tian 
> 
> NanoPi R4s is SBC base on Rockchip RK3399 hexa-core processor with
> dual-Core Cortex-A72 and Mali-T864 GPU with 4GiB(LPDDR4) of RAM, SD card 
> support,
> including 2 gigabit ethernet(RTL8211E 1Gbps - RTL8111H 1Gbps) and 2 USB 3.0 
> port.
> port.It also has two GPIO headers which allows further peripherals to be used.
> 
> The devicetree file is taken of the rk3399 nanopi4 Linux kernel [1].
> 
> [1] 
> https://github.com/torvalds/linux/commit/e7a095908227fb3ccc86d001d9e13c9ae2bef8e6
> 
> Signed-off-by: xiaobo 
> ---
>  arch/arm/dts/Makefile  |   1 +
>  arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi |  17 +++
>  arch/arm/dts/rk3399-nanopi-r4s.dts | 138 +
>  board/rockchip/evb_rk3399/MAINTAINERS  |   6 +
>  configs/nanopi-r4s-rk3399_defconfig|  62 +
>  5 files changed, 224 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-nanopi-r4s.dts
>  create mode 100644 configs/nanopi-r4s-rk3399_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 858b79ac97..528dfe069e 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -92,6 +92,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3288) += \
>   rk3288-evb.dtb \
>   rk3288-firefly.dtb \
>   rk3288-miqi.dtb \
> + rk3399-nanopi-r4s.dtb \

This is in the wrong list.  You need to put it into the RK3399 list, not
RK3288.

>   rk3288-phycore-rdk.dtb \
>   rk3288-popmetal.dtb \
>   rk3288-rock2-square.dtb \
> diff --git a/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi 
> b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
> new file mode 100644
> index 00..3f97867cc5
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
> @@ -0,0 +1,17 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * RK3399-based FriendlyElec boards device tree source
> + *
> + * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
> + * (http://www.friendlyarm.com)
> + *
> + * Copyright (c) 2018 Collabora Ltd.
> + * Copyright (c) 2019 Arm Ltd.
> + * Copyright (C) 2020 Xiaobo 
> + */
> +
> +#include "rk3399-nanopi4-u-boot.dtsi"
> +#include "rk3399-sdram-lpddr4-100.dtsi"
> +#include "rk3399-sdram-ddr3-1866.dtsi"

This is wrong as well.  I think there can only be lpddr4 *or* ddr3.  I
think the last one has precedence.  I have a 4G machine, and it doesn't
work with this.  If I remove the ddr3 (since 4G machine has lpddr4),
it works.

> diff --git a/arch/arm/dts/rk3399-nanopi-r4s.dts 
> b/arch/arm/dts/rk3399-nanopi-r4s.dts
> new file mode 100644
> index 00..6f2cf17bf1
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-nanopi-r4s.dts
> @@ -0,0 +1,138 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
> + * (http://www.friendlyarm.com)
> + *
> + * Copyright (c) 2018 Collabora Ltd.
> + * Copyright (c) 2019 Arm Ltd.
> + * Copyright (C) 2020 Xiaobo 
> + */
> +
> +/dts-v1/;
> +#include "rk3399-nanopi4.dtsi"
> +
> +/ {
> + model = "FriendlyElec NanoPi R4S";
> + compatible = "friendlyarm,nanopi-r4s", "rockchip,rk3399";
> +
> + aliases {
> + ethernet1 = 
> + };
> +
> + vdd_5v: vdd-5v {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd_5v";
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + fan: pwm-fan {
> + compatible = "pwm-fan";
> + cooling-levels = <0 12 18 255>;
> + #cooling-cells = <2>;
> + fan-supply = <_5v>;
> + pwms = < 0 5 0>;
> + };
> +};
> +
> +_thermal {
> + trips {
> + cpu_warm: cpu_warm {
> + temperature = <55000>;
> + hysteresis = <2000>;
> + type = "active";
> + };
> +
> + cpu_hot: cpu_hot {
> + temperature = <65000>;
> + hysteresis = <2000>;
> + type = "active";
> + };
> + };
> +
> + cooling-maps {
> + map2 {
> + trip = <_warm>;
> + cooling-device = < THERMAL_NO_LIMIT 1>;
> + };
> +
> + map3 {
> + trip = <_hot>;
> + cooling-device = < 2 THERMAL_NO_LIMIT>;
> + };
> + };
> +};
> +
> +_phy {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + lan_led: led-1 {
> + gpios = < RK_PA1 GPIO_ACTIVE_HIGH>;
> + label = "nanopi-r4s:green:lan";
> + };
> +
> + wan_led: led-2 {
> + gpios = < RK_PA0 GPIO_ACTIVE_HIGH>;
> + label = 

Re: Pull request: u-boot-spi/master

2021-02-26 Thread Tom Rini
On Fri, Feb 26, 2021 at 10:52:12PM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> Please pull this PR.
> 
> Summary:
> - new GigaDevice flash ids
> - fixes for imx, nxp_spi drivers
> 
> GitLab CI:
> https://gitlab.denx.de/u-boot/custodians/u-boot-spi/-/pipelines/6528
> 
> The following changes since commit c28d5d704d3347fcbe5e49ab561973c00bf9337f:
> 
>   Merge branch '2021-02-25-remove-platforms' (2021-02-25 13:18:27 -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-spi master
> 
> for you to fetch changes up to 783a15b35131abc599ec6deca55cf841d2e7c208:
> 
>   mtd: nand: spi: Support GigaDevice GD5F1GQ5UExxG (2021-02-26 16:01:37 +0530)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


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

2021-02-26 Thread Tom Rini
On Fri, Feb 26, 2021 at 06:17:33PM +0100, Patrick DELAUNAY wrote:

> 
> Hi Tom,
> 
> Please pull the STM32 related patches for u-boot/master, v2021.04:
> u-boot-stm32-20210226
> 
> - Add USB host boot support in stm32mp1 config
> - Enable uefi related commands for STMicroelectronics STM32MP15 boards
> - Remove duplicate uart nodes in stm32mp15 device tree
> 
> CI status:
> https://gitlab.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/6533
> 
> Thanks,
> Patrick
> 
> 
> git request-pull origin/master
> https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git
> u-boot-stm32-20210226
> 
> The following changes since commit c28d5d704d3347fcbe5e49ab561973c00bf9337f:
> 
>   Merge branch '2021-02-25-remove-platforms' (2021-02-25 13:18:27 -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git
> u-boot-stm32-20210226
> 
> for you to fetch changes up to 1b3db349c011e7905a03126d9a78e1fb9886efb7:
> 
>   configs: stm32mp1: enable uefi related commands (2021-02-26 15:45:22
> +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 00/14] spi: dw: Add support for DUAL/QUAD/OCTAL modes

2021-02-26 Thread Sean Anderson

On 2/26/21 5:25 AM, Jagan Teki wrote:

On Fri, Feb 5, 2021 at 9:41 AM Sean Anderson  wrote:


This series adds support for enhanced SPI modes. It was tested on a K210 (DWC
SSI with QSPI flash).

If anyone has a designware device with QSPI flash attached (especially a DW SSI
APB device), I'd greatly appreciate them testing out this patch series.

Many of the earlier patches in this series are general fixups and can be split
off/merged separately if desired.

Changes in v2:
- Add more information to exec_op debug message
- Actually mask interrupts
- Merge CAP_{DUAL,QUAD,OCTAL} into CAP_ENHANCED
- Fix some inconsistencies in register naming and usage
- Moved some hunks between commits so things make more sense

Sean Anderson (14):
   cmd: sf: Display errno on erase failure
   cmd: sf: Print error on test failure
   mtd: spi-nor-core: Fix typo in documentation


Applied to u-boot-spi/master


   mtd: spi-mem: Export spi_mem_default_supports_op
   spi: spi-mem: Add debug message for spi-mem ops


Commented.


   spi: dw: Log status register on timeout
   spi: dw: Actually mask interrupts
   spi: dw: Switch to capabilities
   spi: dw: Rewrite poll_transfer logic
   spi: dw: Add ENHANCED cap
   spi: dw: Define registers for enhanced mode
   spi: dw: Support enhanced SPI
   spi: dw: Support clock stretching


Any testing on these? it's better to have an Ack from respective
driver authors or users. Once done, please send a series for dw-spi
patches.


+CC some people who have authored commits for this driver in the past.
They probably should have been CC'd for the original series, but it
looks like I forgot.

--Sean




   riscv: k210: Enable QSPI for spi3


I think Rick can pick this via risc-v tree.

Jagan.





Re: Broken build on OpenBSD

2021-02-26 Thread Alex G.

On 2/25/21 1:31 PM, Simon Glass wrote:

Hi Alex,


To the extent that it is unconventional, that reflects the decision to
avoid adding U-Boot-specific error numbers and perhaps also to avoid
having a different error number for each possible failure in U-Boot.


The set of errno codes is much smaller than the set of possible 
failures. It is objectively impossible to map the set of possible 
failures onto the set of errno codes. And that's why I think this 
decision is wrong.



The following arguments are subjective:

Compared to TF-A and OP-TEE, I find u-boot sources more difficult to 
work with. One of the reasons is that different parts have different 
idiosyncrasies. TF-A and OP-TEE are bad in their own ways, but they are 
at the very least, consistent wrt conventions of the C language. Now 
we're talking about every u-boot function potentially having its own 
semantics. This is going from bad to worse. And now the code is 
returning error codes that don't even make sense in context.


What you're describing (not quoted in this reply) is a mechanism to 
allow users to handle failures. We first need to define user and how the 
user interfaces with the software product. For example, is someone who 
presses the power button also expected to resolve storage media 
corruption? Only then can we spec out the requirements for this 
mechanism. We somehow have the solution to a problem that isn't properly 
defined yet.


This is a textbook example of when all you have is a hammer, everything 
looks like a nail.


Alex


[PATCH v2] cmd: gpt: Add option to write GPT partitions to environment variable

2021-02-26 Thread Farhan Ali
This change would enhance the existing 'gpt read' command to allow
(optionally) writing of the read GPT partitions to an environment
variable in the UBOOT partitions layout format. This would allow users
to easily change the overall partition settings by editing said variable
and then using the variable in the 'gpt write' and 'gpt verify' commands.

Signed-off-by: Farhan Ali 
Cc: Simon Glass 
Cc: Heinrich Schuchardt 
Cc: Corneliu Doban 
Cc: Rayagonda Kokatanur 
Cc: Rasmus Villemoes 

---
Changes for v2:
   - Checked for argv[4] existence before calling do_get_gpt_info
   - Added missing update to doc/README.gpt
---
 cmd/gpt.c  | 46 ++
 doc/README.gpt | 17 +
 2 files changed, 55 insertions(+), 8 deletions(-)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index 76a95ad..17f2b83 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -350,17 +350,46 @@ static int get_gpt_info(struct blk_desc *dev_desc)
 }
 
 /* a wrapper to test get_gpt_info */
-static int do_get_gpt_info(struct blk_desc *dev_desc)
+static int do_get_gpt_info(struct blk_desc *dev_desc, char * const namestr)
 {
-   int ret;
+   int numparts;
+
+   numparts = get_gpt_info(dev_desc);
+
+   if (numparts > 0) {
+   if (namestr) {
+   char disk_guid[UUID_STR_LEN + 1];
+   char *partitions_list;
+   int partlistlen;
+   int ret = -1;
+
+   ret = get_disk_guid(dev_desc, disk_guid);
+   if (ret < 0)
+   return ret;
+
+   partlistlen = calc_parts_list_len(numparts);
+   partitions_list = malloc(partlistlen);
+   if (!partitions_list) {
+   del_gpt_info();
+   return -ENOMEM;
+   }
+   memset(partitions_list, '\0', partlistlen);
+
+   ret = create_gpt_partitions_list(numparts, disk_guid,
+partitions_list);
+   if (ret < 0)
+   printf("Error: Could not create partition list 
string!\n");
+   else
+   env_set(namestr, partitions_list);
 
-   ret = get_gpt_info(dev_desc);
-   if (ret > 0) {
-   print_gpt_info();
+   free(partitions_list);
+   } else {
+   print_gpt_info();
+   }
del_gpt_info();
return 0;
}
-   return ret;
+   return numparts;
 }
 #endif
 
@@ -982,7 +1011,7 @@ static int do_gpt(struct cmd_tbl *cmdtp, int flag, int 
argc, char *const argv[])
ret = do_disk_guid(blk_dev_desc, argv[4]);
 #ifdef CONFIG_CMD_GPT_RENAME
} else if (strcmp(argv[1], "read") == 0) {
-   ret = do_get_gpt_info(blk_dev_desc);
+   ret = do_get_gpt_info(blk_dev_desc, (argc == 5) ? argv[4] : 
NULL);
} else if ((strcmp(argv[1], "swap") == 0) ||
   (strcmp(argv[1], "rename") == 0)) {
ret = do_rename_gpt_parts(blk_dev_desc, argv[1], argv[4], 
argv[5]);
@@ -1028,8 +1057,9 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
" gpt guid mmc 0 varname\n"
 #ifdef CONFIG_CMD_GPT_RENAME
"gpt partition renaming commands:\n"
-   " gpt read  \n"
+   " gpt read   []\n"
"- read GPT into a data structure for manipulation\n"
+   "- read GPT partitions into environment variable\n"
" gpt swap\n"
"- change all partitions named name1 to name2\n"
"  and vice-versa\n"
diff --git a/doc/README.gpt b/doc/README.gpt
index ac975f6..91e397d 100644
--- a/doc/README.gpt
+++ b/doc/README.gpt
@@ -237,6 +237,23 @@ doc/arch/index.rst:
 => gpt swap host 0 name othername
 [ . . . ]
 
+Modifying GPT partition layout from U-Boot:
+===
+
+The entire GPT partition layout can be exported to an environment
+variable and then modified enmasse. Users can change the partition
+numbers, offsets, names and sizes. The resulting variable can used to
+reformat the device. Here is an example of reading the GPT partitions
+into a variable and then modifying them:
+
+U-BOOT> gpt read mmc 0 current_partitions
+U-BOOT> env edit current_partitions
+edit: uuid_disk=[...];name=part1,start=0x4000,size=0x4000,uuid=[...];
+name=part2,start=0xc000,size=0xc000,uuid=[...];[ . . . ]
+
+U-BOOT> gpt write mmc 0 $current_partitions
+U-BOOT> gpt verify mmc 0 $current_partitions
+
 Partition type GUID:
 
 
-- 
1.8.3.1



[PULL] u-boot-usb/master

2021-02-26 Thread Marek Vasut

The following changes since commit c28d5d704d3347fcbe5e49ab561973c00bf9337f:

  Merge branch '2021-02-25-remove-platforms' (2021-02-25 13:18:27 -0500)

are available in the Git repository at:

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

for you to fetch changes up to 0a7e5e5f103867789328067f87e34b25b26fc3b0:

  usb: gadget: dwc2_udc_otg: Fix dwc2_gadget_start() and 
usb_gadget_register_driver() (2021-02-26 15:30:55 +0100)



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

Patrice Chotard (1):
  usb: gadget: dwc2_udc_otg: Fix dwc2_gadget_start() and 
usb_gadget_register_driver()


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

Stefan Brüns (1):
  usb: kbd: Also accept keyboards with Interrupt OUT endpoint

 cmd/ab_select.c   |   3 +-
 common/usb_kbd.c  |  23 ++-
 configs/sandbox64_defconfig   |   2 +
 configs/sandbox_defconfig |   2 +
 disk/part.c   |  90 
---

 doc/android/fastboot-protocol.rst |   5 +++
 doc/android/fastboot.rst  |   6 +++
 doc/board/sipeed/maix.rst |   4 +-
 doc/usage/index.rst   |   1 +
 doc/usage/partitions.rst  |  80 
++

 drivers/fastboot/Kconfig  |   9 +
 drivers/fastboot/fb_command.c |  68 
 drivers/fastboot/fb_mmc.c | 210 
+--

 drivers/mmc/sandbox_mmc.c |  43 ++---
 drivers/usb/gadget/dwc2_udc_otg.c |   8 +---
 drivers/usb/gadget/f_fastboot.c   |  17 
 include/fastboot.h|   7 
 include/part.h|   6 ++-
 test/dm/Makefile  |   3 ++
 test/dm/fastboot.c|  95 
+

 test/dm/mmc.c |  19 ++---
 21 files changed, 543 insertions(+), 158 deletions(-)
 create mode 100644 doc/usage/partitions.rst
 create mode 100644 test/dm/fastboot.c


Re: Please pull u-boot-marvell/master

2021-02-26 Thread Tom Rini
On Fri, Feb 26, 2021 at 12:14:07PM +0100, Stefan Roese wrote:

> Hi Tom,
> 
> please pull the next batch of Marvell MVEBU related patches. Here the
> summary log:
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: Pull request: u-boot-samsung master

2021-02-26 Thread Tom Rini
On Fri, Feb 26, 2021 at 03:39:58PM +0900, Minkyu Kang wrote:

> Dear Tom,
> 
> The following changes since commit 8f7a16aac36c2a38956bd04b53cb7b94b7a70180:
> 
>   Merge tag 'u-boot-amlogic-20210222' of 
> https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic (2021-02-22 12:37:02 
> -0500)
> 
> are available in the git repository at:
> 
> 
>   g...@gitlab.denx.de:u-boot/custodians/u-boot-samsung.git master
> 
> for you to fetch changes up to 0b547b40b149cf76c9f857fc9df2223aa88759e7:
> 
>   samsung: origen: change maintainer (2021-02-23 15:43:27 +0900)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [GIT PULL] u-boot-riscv/master

2021-02-26 Thread Tom Rini
On Fri, Feb 26, 2021 at 09:53:24AM +0800, Leo Liang wrote:

> Hi Tom,
> 
> Please pull some RISC-V updates.
> CI result: 
> https://gitlab.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/6505
> 
> The following changes since commit cbe607b920bc0827d8fe379ed4f5ae4e2058513e:
> 
>   Merge tag 'xilinx-for-v2021.04-rc3' of 
> https://gitlab.denx.de/u-boot/custodians/u-boot-microblaze (2021-02-23 
> 10:45:55 -0500)
> 
> are available in the Git repository at:
> 
>   g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git
> 
> for you to fetch changes up to 5540294fa48598bf1aa8aa4d9084506a19bbd64c:
> 
>   riscv: k210: Enable QSPI for spi3 (2021-02-25 18:06:08 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] RFC: spl: fit: Use libfdt functions to read stringlist

2021-02-26 Thread Tom Rini
On Thu, Feb 25, 2021 at 02:31:23PM -0500, Simon Glass wrote:

> At present the code here reimplements a few libfdt functions and does not
> always respect the property length. The !str check is unlikely to fire
> since 1 is added to the string address. If strchr() returns NULL then the
> code produces (void*)1 instead. Also it might extend beyond the property
> value since strchr() does not have a maximum length.
> 
> In any case it does not seem worthwhile to implement the libfdt functions
> again, despite small code-size advantages. There is no function to return
> the count after a failed get, but we can call two functions. We could add
> one if code size is considered critical here.
> 
> Update the code to use libfdt directly.
> 
> For lion-rk3368 (aarch64) this adds 68 bytes of code.
> For am57xx_hs_evm (arm) it adds 134 bytes.
> 
> Signed-off-by: Simon Glass 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


Pull request: u-boot-spi/master

2021-02-26 Thread Jagan Teki
Hi Tom,

Please pull this PR.

Summary:
- new GigaDevice flash ids
- fixes for imx, nxp_spi drivers

GitLab CI:
https://gitlab.denx.de/u-boot/custodians/u-boot-spi/-/pipelines/6528

The following changes since commit c28d5d704d3347fcbe5e49ab561973c00bf9337f:

  Merge branch '2021-02-25-remove-platforms' (2021-02-25 13:18:27 -0500)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-spi master

for you to fetch changes up to 783a15b35131abc599ec6deca55cf841d2e7c208:

  mtd: nand: spi: Support GigaDevice GD5F1GQ5UExxG (2021-02-26 16:01:37 +0530)


Adam Ford (1):
  spi: nxp_fspi: Fix error reporting

Alper Nebi Yasak (1):
  mtd: spi-nor-ids: Add Gigadevice GD25LQ64C

Bin Meng (1):
  mtd: spi-nor.h: Change spaces to tabs

Hauke Mehrtens (1):
  mtd: nand: spi: Only one dummy byte in QUADIO

Marek Vasut (1):
  spi: imx: Implement set_speed

Reto Schneider (1):
  mtd: nand: spi: Support GigaDevice GD5F1GQ5UExxG

Sean Anderson (3):
  cmd: sf: Display errno on erase failure
  cmd: sf: Print error on test failure
  mtd: spi-nor-core: Fix typo in documentation

Su Baocheng (1):
  mtd: spi-nor-ids: Add support of flash protection to w25q128

 cmd/sf.c  | 29 --
 drivers/mtd/nand/spi/gigadevice.c | 79 ++-
 drivers/mtd/spi/spi-nor-ids.c | 10 -
 drivers/spi/mxc_spi.c |  5 ++-
 drivers/spi/nxp_fspi.c|  4 +-
 include/linux/mtd/spi-nor.h   | 22 +--
 6 files changed, 113 insertions(+), 36 deletions(-)


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

2021-02-26 Thread Patrick DELAUNAY



Hi Tom,

Please pull the STM32 related patches for u-boot/master, v2021.04: 
u-boot-stm32-20210226


- Add USB host boot support in stm32mp1 config
- Enable uefi related commands for STMicroelectronics STM32MP15 boards
- Remove duplicate uart nodes in stm32mp15 device tree

CI status: 
https://gitlab.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/6533


Thanks,
Patrick


git request-pull origin/master 
https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git 
u-boot-stm32-20210226


The following changes since commit c28d5d704d3347fcbe5e49ab561973c00bf9337f:

  Merge branch '2021-02-25-remove-platforms' (2021-02-25 13:18:27 -0500)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git 
u-boot-stm32-20210226


for you to fetch changes up to 1b3db349c011e7905a03126d9a78e1fb9886efb7:

  configs: stm32mp1: enable uefi related commands (2021-02-26 15:45:22 
+0100)



- Add USB host boot support in stm32mp1 config
- Enable uefi related commands for STMicroelectronics STM32MP15 boards
- Remove duplicate uart nodes in stm32mp15 device tree


Ilias Apalodimas (1):
  configs: stm32mp1: enable uefi related commands

Marek Vasut (1):
  ARM: stm32: Add USB host boot support

Patrick Delaunay (1):
  arm: dts: stm32mp15: remove duplicate uart nodes

 arch/arm/dts/stm32mp15-pinctrl.dtsi | 80 
---

 configs/stm32mp15_basic_defconfig   |  3 +++
 configs/stm32mp15_trusted_defconfig |  3 +++
 include/configs/stm32mp1.h  |  7 ++
 4 files changed, 13 insertions(+), 80 deletions(-)



RE: [v4 0/7] Add Vendor Authorized Boot (VAB) support

2021-02-26 Thread Lim, Elly Siew Chin
Hi All,

Please ignore this series, I accidentally create this series based on older 
master branch which causes patch [v4 2/7] conflict with latest master branch 
due to new commit about asm/global_data.h. I have rebased to latest master 
branch and resend the VAB series with prefix " [RESEND,v4,1/7] ...".

Thanks,
Siew Chin

> -Original Message-
> From: Lim, Elly Siew Chin 
> Sent: Saturday, February 27, 2021 12:11 AM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Tan, Ley Foon
> ; See, Chin Liang ;
> Simon Goldschmidt ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan,
> Yau Wai ; Lim, Elly Siew Chin
> 
> Subject: [v4 0/7] Add Vendor Authorized Boot (VAB) support
> 
> This is the 4th version of patchset to add Vendor Authorized Boot (VAB)
> support for Intel Agilex SoC device.
> 
> Vendor Authorized Boot is a security feature for authenticating the images
> such as U-Boot, ARM trusted Firmware, Linux kernel, device tree blob and
> etc loaded from FIT. After those images are loaded from FIT, the VAB
> certificate and signature block appended at the end of each image are sent
> to Secure Device Manager (SDM) for authentication. U-Boot will validate the
> SHA384 of the image against the SHA384 hash stored in the VAB certificate
> before sending the image to SDM for authentication.
> 
> Patch status:
> Have changes: Patch 2, 7
> Other patches unchanged.
> 
> Detail changelog can find in commit message.
> 
> v3->v4:
> 
> Patch 2:
> - Move function 'board_fit_image_post_process' and 'board_prep_linux'
> from
>   secure_vab.c to board.c
> 
> Patch 7:
> - Replace CONFIG_TARGET_SOCFPGA_STRATIX10/AGILEX with
> CONFIG_TARGET_SOCFPGA_SOC64.
> - Add this patch into 'VAB' series because it is depending on
>   CONFIG_TARGET_SOCFPGA_SOC64 patch.
> 
> History:
> 
> [v1]:
> https://patchwork.ozlabs.org/project/uboot/cover/20201110070505.26935-
> 1-elly.siew.chin@intel.com/
> [v2]:
> https://patchwork.ozlabs.org/project/uboot/cover/20210107100337.45293-
> 1-elly.siew.chin@intel.com/
> [v3]:
> https://patchwork.ozlabs.org/project/uboot/cover/20210205105212.16510-
> 1-elly.siew.chin@intel.com/
> 
> 
> Dalon Westergreen (1):
>   Makefile: socfpga: Add target to generate hex output for combined spl
> and dtb
> 
> Siew Chin Lim (6):
>   arm: socfpga: Move Stratix10 and Agilex to use TARGET_SOCFPGA_SOC64
>   arm: socfpga: soc64: Support Vendor Authorized Boot (VAB)
>   arm: socfpga: cmd: Support 'vab' command
>   arm: socfpga: dts: soc64: Update filename in binman node of FIT image
> with VAB support
>   configs: socfpga: soc64: Move CONFIG_BOOTCOMMAND to defconfig
>   configs: socfpga: Add defconfig for Agilex with VAB support
> 
>  Makefile   |  11 +-
>  arch/arm/Kconfig   |   6 +-
>  arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi |  22 +++
>  arch/arm/mach-socfpga/Kconfig  |  20 +++
>  arch/arm/mach-socfpga/Makefile |   3 +
>  arch/arm/mach-socfpga/board.c  |  43 -
>  arch/arm/mach-socfpga/include/mach/mailbox_s10.h   |   1 +
>  arch/arm/mach-socfpga/include/mach/reset_manager.h |   3 +-
>  arch/arm/mach-socfpga/include/mach/secure_vab.h|  63 +++
>  .../arm/mach-socfpga/include/mach/system_manager.h |   3 +-
>  arch/arm/mach-socfpga/secure_vab.c | 186
> +
>  arch/arm/mach-socfpga/vab.c|  34 
>  common/Kconfig.boot|   2 +-
>  configs/socfpga_agilex_atf_defconfig   |   2 +
>  configs/socfpga_agilex_defconfig   |   2 +
>  ..._atf_defconfig => socfpga_agilex_vab_defconfig} |   4 +
>  configs/socfpga_stratix10_atf_defconfig|   2 +
>  configs/socfpga_stratix10_defconfig|   2 +
>  drivers/ddr/altera/Kconfig |   6 +-
>  drivers/fpga/Kconfig   |   2 +-
>  drivers/sysreset/Kconfig   |   2 +-
>  include/configs/socfpga_soc64_common.h |  10 +-
>  scripts/Makefile.spl   |   7 +
>  23 files changed, 406 insertions(+), 30 deletions(-)  create mode 100644
> arch/arm/mach-socfpga/include/mach/secure_vab.h
>  create mode 100644 arch/arm/mach-socfpga/secure_vab.c
>  create mode 100644 arch/arm/mach-socfpga/vab.c  copy
> configs/{socfpga_agilex_atf_defconfig => socfpga_agilex_vab_defconfig}
> (91%)
> 
> --
> 2.13.0



[RESEND v4 7/7] Makefile: socfpga: Add target to generate hex output for combined spl and dtb

2021-02-26 Thread Siew Chin Lim
From: Dalon Westergreen 

Add target to Makefile to generate "u-boot-spl-dtb.hex" for Intel
SOCFPGA SOC64 devices (Stratix 10 and Agilex). "u-boot-spl-dtb.hex"
is hex formatted spl with and offset of CONFIG_SPL_TEXT_BASE. It
combines the spl image and dtb. "u-boot-spl-dtb.hex" is needed to
generate the final configuration bitstream for Intel SOCFPGA SOC64
devices.

Signed-off-by: Dalon Westergreen 
Signed-off-by: Siew Chin Lim 

---
v4:
- Replace CONFIG_TARGET_SOCFPGA_STRATIX10/AGILEX with 
CONFIG_TARGET_SOCFPGA_SOC64.
- Add this patch into 'VAB' series because it is depending on
  CONFIG_TARGET_SOCFPGA_SOC64 patch.
---
 Makefile   | 11 ++-
 include/configs/socfpga_soc64_common.h |  2 +-
 scripts/Makefile.spl   |  7 +++
 3 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/Makefile b/Makefile
index 079881b62a..c788f12bf4 100644
--- a/Makefile
+++ b/Makefile
@@ -1263,11 +1263,6 @@ OBJCOPYFLAGS_u-boot-nodtb.bin := -O binary \
$(if $(CONFIG_X86_16BIT_INIT),-R .start16 -R .resetvec) \
$(if $(CONFIG_MPC85XX_HAVE_RESET_VECTOR),-R .bootpg -R 
.resetvec)
 
-OBJCOPYFLAGS_u-boot-spl.hex = $(OBJCOPYFLAGS_u-boot.hex)
-
-spl/u-boot-spl.hex: spl/u-boot-spl FORCE
-   $(call if_changed,objcopy)
-
 binary_size_check: u-boot-nodtb.bin FORCE
@file_size=$(shell wc -c u-boot-nodtb.bin | awk '{print $$1}') ; \
map_size=$(shell cat u-boot.map | \
@@ -1936,6 +1931,12 @@ spl/u-boot-spl.bin: spl/u-boot-spl
@:
$(SPL_SIZE_CHECK)
 
+spl/u-boot-spl-dtb.bin: spl/u-boot-spl
+   @:
+
+spl/u-boot-spl-dtb.hex: spl/u-boot-spl
+   @:
+
 spl/u-boot-spl: tools prepare \
$(if 
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SPL_OF_PLATDATA),dts/dt.dtb) \
$(if 
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_TPL_OF_PLATDATA),dts/dt.dtb)
diff --git a/include/configs/socfpga_soc64_common.h 
b/include/configs/socfpga_soc64_common.h
index 0e54601257..1cfa190047 100644
--- a/include/configs/socfpga_soc64_common.h
+++ b/include/configs/socfpga_soc64_common.h
@@ -194,7 +194,7 @@ unsigned int cm_get_l4_sys_free_clk_hz(void);
  * 0x8000_ .. End of SDRAM_1 (assume 2GB)
  *
  */
-#define CONFIG_SPL_TARGET  "spl/u-boot-spl.hex"
+#define CONFIG_SPL_TARGET  "spl/u-boot-spl-dtb.hex"
 #define CONFIG_SPL_MAX_SIZECONFIG_SYS_INIT_RAM_SIZE
 #define CONFIG_SPL_STACK   CONFIG_SYS_INIT_SP_ADDR
 #define CONFIG_SPL_BSS_MAX_SIZE0x10/* 1 MB */
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index ea4e045769..1fd63efdfd 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -229,6 +229,8 @@ ifneq 
($(CONFIG_TARGET_SOCFPGA_GEN5)$(CONFIG_TARGET_SOCFPGA_ARRIA10),)
 INPUTS-y   += $(obj)/$(SPL_BIN).sfp
 endif
 
+INPUTS-$(CONFIG_TARGET_SOCFPGA_SOC64) += $(obj)/u-boot-spl-dtb.hex
+
 ifdef CONFIG_ARCH_SUNXI
 INPUTS-y   += $(obj)/sunxi-spl.bin
 
@@ -389,6 +391,11 @@ $(obj)/$(SPL_BIN).sfp: $(obj)/$(SPL_BIN).bin FORCE
 MKIMAGEFLAGS_sunxi-spl.bin = -T sunxi_egon \
-n $(CONFIG_DEFAULT_DEVICE_TREE)
 
+OBJCOPYFLAGS_u-boot-spl-dtb.hex := -I binary -O ihex 
--change-address=$(CONFIG_SPL_TEXT_BASE)
+
+$(obj)/u-boot-spl-dtb.hex: $(obj)/u-boot-spl-dtb.bin FORCE
+   $(call if_changed,objcopy)
+
 $(obj)/sunxi-spl.bin: $(obj)/$(SPL_BIN).bin FORCE
$(call if_changed,mkimage)
 
-- 
2.13.0



[RESEND v4 6/7] configs: socfpga: Add defconfig for Agilex with VAB support

2021-02-26 Thread Siew Chin Lim
Booting Agilex with Vendor Authorized Boot.

Signed-off-by: Siew Chin Lim 
---
 .../{socfpga_agilex_atf_defconfig => socfpga_agilex_vab_defconfig}| 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
 copy configs/{socfpga_agilex_atf_defconfig => socfpga_agilex_vab_defconfig} 
(92%)

diff --git a/configs/socfpga_agilex_atf_defconfig 
b/configs/socfpga_agilex_vab_defconfig
similarity index 92%
copy from configs/socfpga_agilex_atf_defconfig
copy to configs/socfpga_agilex_vab_defconfig
index 7adda02b00..bca663ed61 100644
--- a/configs/socfpga_agilex_atf_defconfig
+++ b/configs/socfpga_agilex_vab_defconfig
@@ -9,6 +9,7 @@ CONFIG_ENV_OFFSET=0x200
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x0200
 CONFIG_DM_GPIO=y
 CONFIG_SPL_TEXT_BASE=0xFFE0
+CONFIG_SOCFPGA_SECURE_VAB_AUTH=y
 CONFIG_TARGET_SOCFPGA_AGILEX_SOCDK=y
 CONFIG_IDENT_STRING="socfpga_agilex"
 CONFIG_SPL_FS_FAT=y
@@ -17,11 +18,12 @@ CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_LOAD_FIT_ADDRESS=0x0200
 # CONFIG_USE_SPL_FIT_GENERATOR is not set
+# CONFIG_LEGACY_IMAGE_FORMAT is not set
 CONFIG_BOOTDELAY=5
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="earlycon"
 CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="run fatscript; run mmcfitload; run linux_qspi_enable; run 
mmcfitboot"
+CONFIG_BOOTCOMMAND="run fatscript; run mmcfitload; run mmcfitboot"
 CONFIG_SPL_CACHE=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SPL_ATF=y
-- 
2.13.0



[RESEND v4 5/7] configs: socfpga: soc64: Move CONFIG_BOOTCOMMAND to defconfig

2021-02-26 Thread Siew Chin Lim
CONFIG_BOOTCOMMAND have been moved to Kconfig.boot. This patch
move the CONFIG_BOOTCOMMAND macro from socfpga_soc64_common.h to
*_defconfig file for both Stratix 10 and Agilex.

Signed-off-by: Siew Chin Lim 
---
 configs/socfpga_agilex_atf_defconfig| 2 ++
 configs/socfpga_agilex_defconfig| 2 ++
 configs/socfpga_stratix10_atf_defconfig | 2 ++
 configs/socfpga_stratix10_defconfig | 2 ++
 include/configs/socfpga_soc64_common.h  | 8 +---
 5 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/configs/socfpga_agilex_atf_defconfig 
b/configs/socfpga_agilex_atf_defconfig
index ebe6ce63a4..7adda02b00 100644
--- a/configs/socfpga_agilex_atf_defconfig
+++ b/configs/socfpga_agilex_atf_defconfig
@@ -20,6 +20,8 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x0200
 CONFIG_BOOTDELAY=5
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="earlycon"
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="run fatscript; run mmcfitload; run linux_qspi_enable; run 
mmcfitboot"
 CONFIG_SPL_CACHE=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SPL_ATF=y
diff --git a/configs/socfpga_agilex_defconfig b/configs/socfpga_agilex_defconfig
index 230d3c2ce5..3d5d39fe0f 100644
--- a/configs/socfpga_agilex_defconfig
+++ b/configs/socfpga_agilex_defconfig
@@ -18,6 +18,8 @@ CONFIG_DEFAULT_DEVICE_TREE="socfpga_agilex_socdk"
 CONFIG_BOOTDELAY=5
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="earlycon"
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="run fatscript; run mmcload; run linux_qspi_enable; run 
mmcboot"
 CONFIG_SPL_CACHE=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_HUSH_PARSER=y
diff --git a/configs/socfpga_stratix10_atf_defconfig 
b/configs/socfpga_stratix10_atf_defconfig
index d1b12113ab..8dbb7424ba 100644
--- a/configs/socfpga_stratix10_atf_defconfig
+++ b/configs/socfpga_stratix10_atf_defconfig
@@ -20,6 +20,8 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x0200
 CONFIG_BOOTDELAY=5
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="earlycon"
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="run fatscript; run mmcfitload; run linux_qspi_enable; run 
mmcfitboot"
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SPL_ATF=y
 CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
diff --git a/configs/socfpga_stratix10_defconfig 
b/configs/socfpga_stratix10_defconfig
index 3df44bb88d..2d145e1a5f 100644
--- a/configs/socfpga_stratix10_defconfig
+++ b/configs/socfpga_stratix10_defconfig
@@ -20,6 +20,8 @@ CONFIG_SPL_OPTIMIZE_INLINING=y
 CONFIG_BOOTDELAY=5
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="earlycon"
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="run fatscript; run mmcload; run linux_qspi_enable; run 
mmcboot"
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="SOCFPGA_STRATIX10 # "
diff --git a/include/configs/socfpga_soc64_common.h 
b/include/configs/socfpga_soc64_common.h
index fdcd7d3e9a..0e54601257 100644
--- a/include/configs/socfpga_soc64_common.h
+++ b/include/configs/socfpga_soc64_common.h
@@ -79,19 +79,13 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
 #endif /* CONFIG_CADENCE_QSPI */
 
 /*
- * Boot arguments passed to the boot command. The value of
- * CONFIG_BOOTARGS goes into the environment value "bootargs".
- * Do note the value will override also the chosen node in FDT blob.
+ * Environment variable
  */
 
 #ifdef CONFIG_FIT
 #define CONFIG_BOOTFILE "kernel.itb"
-#define CONFIG_BOOTCOMMAND "run fatscript; run mmcfitload;run 
linux_qspi_enable;" \
-  "run mmcfitboot"
 #else
 #define CONFIG_BOOTFILE "Image"
-#define CONFIG_BOOTCOMMAND "run fatscript; run mmcload;run linux_qspi_enable;" 
\
-  "run mmcboot"
 #endif
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
-- 
2.13.0



[RESEND v4 4/7] arm: socfpga: dts: soc64: Update filename in binman node of FIT image with VAB support

2021-02-26 Thread Siew Chin Lim
FIT image of Vendor Authentication Coot (VAB) contains signed images.

Signed-off-by: Siew Chin Lim 
---
 arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi 
b/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi
index cf365590a8..4b30473743 100644
--- a/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi
+++ b/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi
@@ -117,4 +117,26 @@
};
 };
 
+#if defined(CONFIG_SOCFPGA_SECURE_VAB_AUTH)
+_blob {
+   filename = "signed-u-boot-nodtb.bin";
+};
+
+_blob {
+   filename = "signed-bl31.bin";
+};
+
+_fdt_blob {
+   filename = "signed-u-boot.dtb";
+};
+
+_blob {
+   filename = "signed-Image";
+};
+
+_fdt_blob {
+   filename = "signed-linux.dtb";
+};
+#endif
+
 #endif
-- 
2.13.0



[RESEND v4 3/7] arm: socfpga: cmd: Support 'vab' command

2021-02-26 Thread Siew Chin Lim
Support 'vab' command to perform vendor authentication.

Command format: vab addr len
Authorize 'len' bytes starting at 'addr' via vendor public key

Signed-off-by: Siew Chin Lim 
---
 arch/arm/mach-socfpga/Makefile |  1 +
 arch/arm/mach-socfpga/vab.c| 34 ++
 2 files changed, 35 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/vab.c

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 1f1e21766d..9e63296b38 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -51,6 +51,7 @@ obj-y += reset_manager_s10.o
 obj-$(CONFIG_SOCFPGA_SECURE_VAB_AUTH)  += secure_vab.o
 obj-y  += system_manager_s10.o
 obj-y  += timer_s10.o
+obj-$(CONFIG_SOCFPGA_SECURE_VAB_AUTH)  += vab.o
 obj-y  += wrap_pinmux_config_s10.o
 obj-y  += wrap_pll_config_s10.o
 endif
diff --git a/arch/arm/mach-socfpga/vab.c b/arch/arm/mach-socfpga/vab.c
new file mode 100644
index 00..85b3f30211
--- /dev/null
+++ b/arch/arm/mach-socfpga/vab.c
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Intel Corporation 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static int do_vab(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+   unsigned long addr, len;
+
+   if (argc < 3)
+   return CMD_RET_USAGE;
+
+   addr = simple_strtoul(argv[1], NULL, 16);
+   len = simple_strtoul(argv[2], NULL, 16);
+
+   if (socfpga_vendor_authentication((void *), (size_t *)) != 0)
+   return CMD_RET_FAILURE;
+
+   return 0;
+}
+
+U_BOOT_CMD(
+   vab,3,  2,  do_vab,
+   "perform vendor authorization",
+   "addr len   - authorize 'len' bytes starting at\n"
+   " 'addr' via vendor public key"
+);
-- 
2.13.0



[RESEND v4 2/7] arm: socfpga: soc64: Support Vendor Authorized Boot (VAB)

2021-02-26 Thread Siew Chin Lim
Vendor Authorized Boot is a security feature for authenticating
the images such as U-Boot, ARM trusted Firmware, Linux kernel,
device tree blob and etc loaded from FIT. After those images are
loaded from FIT, the VAB certificate and signature block appended
at the end of each image are sent to Secure Device Manager (SDM)
for authentication. U-Boot will validate the SHA384 of the image
against the SHA384 hash stored in the VAB certificate before
sending the image to SDM for authentication.

Signed-off-by: Siew Chin Lim 

---
v4:
- Move function 'board_fit_image_post_process' and 'board_prep_linux'
  from secure_vab.c to board.c.
---
 arch/arm/mach-socfpga/Kconfig|  15 ++
 arch/arm/mach-socfpga/Makefile   |   2 +
 arch/arm/mach-socfpga/board.c|  43 +-
 arch/arm/mach-socfpga/include/mach/mailbox_s10.h |   1 +
 arch/arm/mach-socfpga/include/mach/secure_vab.h  |  63 
 arch/arm/mach-socfpga/secure_vab.c   | 186 +++
 common/Kconfig.boot  |   2 +-
 7 files changed, 307 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/include/mach/secure_vab.h
 create mode 100644 arch/arm/mach-socfpga/secure_vab.c

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 9b1abdaabd..0c35406232 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -6,6 +6,21 @@ config ERR_PTR_OFFSET
 config NR_DRAM_BANKS
default 1
 
+config SOCFPGA_SECURE_VAB_AUTH
+   bool "Enable boot image authentication with Secure Device Manager"
+   depends on TARGET_SOCFPGA_AGILEX
+   select FIT_IMAGE_POST_PROCESS
+   select SHA384
+   select SHA512_ALGO
+   select SPL_FIT_IMAGE_POST_PROCESS
+   help
+All images loaded from FIT will be authenticated by Secure Device
+Manager.
+
+config SOCFPGA_SECURE_VAB_AUTH_ALLOW_NON_FIT_IMAGE
+   bool "Allow non-FIT VAB signed images"
+   depends on SOCFPGA_SECURE_VAB_AUTH
+
 config SPL_SIZE_LIMIT
default 0x1 if TARGET_SOCFPGA_GEN5
 
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 82b681d870..1f1e21766d 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -4,6 +4,7 @@
 # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
 #
 # Copyright (C) 2012-2017 Altera Corporation 
+# Copyright (C) 2017-2020 Intel Corporation 
 
 obj-y  += board.o
 obj-y  += clock_manager.o
@@ -47,6 +48,7 @@ obj-y += mailbox_s10.o
 obj-y  += misc_s10.o
 obj-y  += mmu-arm64_s10.o
 obj-y  += reset_manager_s10.o
+obj-$(CONFIG_SOCFPGA_SECURE_VAB_AUTH)  += secure_vab.o
 obj-y  += system_manager_s10.o
 obj-y  += timer_s10.o
 obj-y  += wrap_pinmux_config_s10.o
diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach-socfpga/board.c
index 2a6af9d1f8..f3d15450e7 100644
--- a/arch/arm/mach-socfpga/board.c
+++ b/arch/arm/mach-socfpga/board.c
@@ -6,14 +6,17 @@
  */
 
 #include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -98,3 +101,35 @@ __weak int board_fit_config_name_match(const char *name)
return 0;
 }
 #endif
+
+#if IS_ENABLED(CONFIG_SOCFPGA_SECURE_VAB_AUTH)
+void board_fit_image_post_process(void **p_image, size_t *p_size)
+{
+   if (socfpga_vendor_authentication(p_image, p_size))
+   hang();
+}
+
+void board_prep_linux(bootm_headers_t *images)
+{
+   if (!IS_ENABLED(CONFIG_SPL_BUILD)) {
+   if (!IS_ENABLED(CONFIG_SECURE_VAB_AUTH_ALLOW_NON_FIT_IMAGE)) {
+   /*
+* Ensure the OS is always booted from FIT and with
+* VAB signed certificate
+*/
+   if (!images->fit_uname_cfg) {
+   printf("Please use FIT with VAB signed 
images!\n");
+   hang();
+   }
+
+   env_set_hex("fdt_addr", (ulong)images->ft_addr);
+   debug("images->ft_addr = 0x%08lx\n", 
(ulong)images->ft_addr);
+   }
+
+   if (IS_ENABLED(CONFIG_CADENCE_QSPI)) {
+   if (env_get("linux_qspi_enable"))
+   run_command(env_get("linux_qspi_enable"), 0);
+   }
+   }
+}
+#endif
diff --git a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h 
b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
index 4d783119ea..fbaf11597e 100644
--- a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
+++ b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
@@ -118,6 +118,7 @@ enum ALT_SDM_MBOX_RESP_CODE {
 #define MBOX_RECONFIG_MSEL 7
 #define MBOX_RECONFIG_DATA 8
 #define MBOX_RECONFIG_STATUS   9
+#define MBOX_VAB_SRC_CERT  11
 #define MBOX_QSPI_OPEN 50
 

[RESEND v4 1/7] arm: socfpga: Move Stratix10 and Agilex to use TARGET_SOCFPGA_SOC64

2021-02-26 Thread Siew Chin Lim
Create common macro TARGET_SOCFPGA_SOC64 for Stratix10 and Agilex.

Signed-off-by: Siew Chin Lim 
---
 arch/arm/Kconfig| 6 +++---
 arch/arm/mach-socfpga/Kconfig   | 5 +
 arch/arm/mach-socfpga/include/mach/reset_manager.h  | 3 +--
 arch/arm/mach-socfpga/include/mach/system_manager.h | 3 +--
 drivers/ddr/altera/Kconfig  | 6 +++---
 drivers/fpga/Kconfig| 2 +-
 drivers/sysreset/Kconfig| 2 +-
 7 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d51abbeaf0..3307f2b3fc 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -970,7 +970,7 @@ config ARCH_SOCFPGA
bool "Altera SOCFPGA family"
select ARCH_EARLY_INIT_R
select ARCH_MISC_INIT if !TARGET_SOCFPGA_ARRIA10
-   select ARM64 if TARGET_SOCFPGA_STRATIX10 || TARGET_SOCFPGA_AGILEX
+   select ARM64 if TARGET_SOCFPGA_SOC64
select CPU_V7A if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
select DM
select DM_SERIAL
@@ -982,7 +982,7 @@ config ARCH_SOCFPGA
select SPL_LIBGENERIC_SUPPORT
select SPL_NAND_SUPPORT if SPL_NAND_DENALI
select SPL_OF_CONTROL
-   select SPL_SEPARATE_BSS if TARGET_SOCFPGA_STRATIX10 || 
TARGET_SOCFPGA_AGILEX
+   select SPL_SEPARATE_BSS if TARGET_SOCFPGA_SOC64
select SPL_SERIAL_SUPPORT
select SPL_SYSRESET
select SPL_WATCHDOG_SUPPORT
@@ -991,7 +991,7 @@ config ARCH_SOCFPGA
select SYS_THUMB_BUILD if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
select SYSRESET
select SYSRESET_SOCFPGA if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
-   select SYSRESET_SOCFPGA_SOC64 if TARGET_SOCFPGA_STRATIX10 || 
TARGET_SOCFPGA_AGILEX
+   select SYSRESET_SOCFPGA_SOC64 if TARGET_SOCFPGA_SOC64
imply CMD_DM
imply CMD_MTDPARTS
imply CRC32_VERIFY
diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 4d4ff16337..9b1abdaabd 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -38,6 +38,7 @@ config TARGET_SOCFPGA_AGILEX
select FPGA_INTEL_SDM_MAILBOX
select NCORE_CACHE
select SPL_CLK if SPL
+   select TARGET_SOCFPGA_SOC64
 
 config TARGET_SOCFPGA_ARRIA5
bool
@@ -75,12 +76,16 @@ config TARGET_SOCFPGA_GEN5
imply SPL_SYS_MALLOC_SIMPLE
imply SPL_USE_TINY_PRINTF
 
+config TARGET_SOCFPGA_SOC64
+   bool
+
 config TARGET_SOCFPGA_STRATIX10
bool
select ARMV8_MULTIENTRY
select ARMV8_SET_SMPEN
select BINMAN if SPL_ATF
select FPGA_INTEL_SDM_MAILBOX
+   select TARGET_SOCFPGA_SOC64
 
 choice
prompt "Altera SOCFPGA board select"
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h 
b/arch/arm/mach-socfpga/include/mach/reset_manager.h
index 7844ad14cb..8c25325e45 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
@@ -43,8 +43,7 @@ void socfpga_per_reset_all(void);
 #include 
 #elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
 #include 
-#elif defined(CONFIG_TARGET_SOCFPGA_STRATIX10) || \
-   defined(CONFIG_TARGET_SOCFPGA_AGILEX)
+#elif defined(CONFIG_TARGET_SOCFPGA_SOC64)
 #include 
 #endif
 
diff --git a/arch/arm/mach-socfpga/include/mach/system_manager.h 
b/arch/arm/mach-socfpga/include/mach/system_manager.h
index f816954717..5603eaa3d0 100644
--- a/arch/arm/mach-socfpga/include/mach/system_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/system_manager.h
@@ -8,8 +8,7 @@
 
 phys_addr_t socfpga_get_sysmgr_addr(void);
 
-#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10) || \
-   defined(CONFIG_TARGET_SOCFPGA_AGILEX)
+#if defined(CONFIG_TARGET_SOCFPGA_SOC64)
 #include 
 #else
 #define SYSMGR_ROMCODEGRP_CTRL_WARMRSTCFGPINMUXBIT(0)
diff --git a/drivers/ddr/altera/Kconfig b/drivers/ddr/altera/Kconfig
index 8f590dc5f6..4660d20def 100644
--- a/drivers/ddr/altera/Kconfig
+++ b/drivers/ddr/altera/Kconfig
@@ -1,8 +1,8 @@
 config SPL_ALTERA_SDRAM
bool "SoCFPGA DDR SDRAM driver in SPL"
depends on SPL
-   depends on TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10 || 
TARGET_SOCFPGA_STRATIX10 || TARGET_SOCFPGA_AGILEX
-   select RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_STRATIX10 || 
TARGET_SOCFPGA_AGILEX
-   select SPL_RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_STRATIX10 || 
TARGET_SOCFPGA_AGILEX
+   depends on TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10 || 
TARGET_SOCFPGA_SOC64
+   select RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_SOC64
+   select SPL_RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_SOC64
help
  Enable DDR SDRAM controller for the SoCFPGA devices.
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 425b52a926..dc0b3dd31b 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -33,7 +33,7 @@ config 

[RESEND v4 0/7] Add Vendor Authorized Boot (VAB) support

2021-02-26 Thread Siew Chin Lim
This is the 4th version of patchset to add Vendor Authorized Boot (VAB)
support for Intel Agilex SoC device.

Vendor Authorized Boot is a security feature for authenticating
the images such as U-Boot, ARM trusted Firmware, Linux kernel,
device tree blob and etc loaded from FIT. After those images are
loaded from FIT, the VAB certificate and signature block appended
at the end of each image are sent to Secure Device Manager (SDM)
for authentication. U-Boot will validate the SHA384 of the image
against the SHA384 hash stored in the VAB certificate before
sending the image to SDM for authentication.

Patch status:
Have changes: Patch 2, 7
Other patches unchanged.

Detail changelog can find in commit message.

v3->v4:

Patch 2:
- Move function 'board_fit_image_post_process' and 'board_prep_linux' from
  secure_vab.c to board.c

Patch 7:
- Replace CONFIG_TARGET_SOCFPGA_STRATIX10/AGILEX with 
CONFIG_TARGET_SOCFPGA_SOC64.
- Add this patch into 'VAB' series because it is depending on
  CONFIG_TARGET_SOCFPGA_SOC64 patch.

History:

[v1]: 
https://patchwork.ozlabs.org/project/uboot/cover/20201110070505.26935-1-elly.siew.chin@intel.com/
[v2]: 
https://patchwork.ozlabs.org/project/uboot/cover/20210107100337.45293-1-elly.siew.chin@intel.com/
[v3]: 
https://patchwork.ozlabs.org/project/uboot/cover/20210205105212.16510-1-elly.siew.chin@intel.com/


Dalon Westergreen (1):
  Makefile: socfpga: Add target to generate hex output for combined spl
and dtb

Siew Chin Lim (6):
  arm: socfpga: Move Stratix10 and Agilex to use TARGET_SOCFPGA_SOC64
  arm: socfpga: soc64: Support Vendor Authorized Boot (VAB)
  arm: socfpga: cmd: Support 'vab' command
  arm: socfpga: dts: soc64: Update filename in binman node of FIT image
with VAB support
  configs: socfpga: soc64: Move CONFIG_BOOTCOMMAND to defconfig
  configs: socfpga: Add defconfig for Agilex with VAB support

 Makefile   |  11 +-
 arch/arm/Kconfig   |   6 +-
 arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi |  22 +++
 arch/arm/mach-socfpga/Kconfig  |  20 +++
 arch/arm/mach-socfpga/Makefile |   3 +
 arch/arm/mach-socfpga/board.c  |  43 -
 arch/arm/mach-socfpga/include/mach/mailbox_s10.h   |   1 +
 arch/arm/mach-socfpga/include/mach/reset_manager.h |   3 +-
 arch/arm/mach-socfpga/include/mach/secure_vab.h|  63 +++
 .../arm/mach-socfpga/include/mach/system_manager.h |   3 +-
 arch/arm/mach-socfpga/secure_vab.c | 186 +
 arch/arm/mach-socfpga/vab.c|  34 
 common/Kconfig.boot|   2 +-
 configs/socfpga_agilex_atf_defconfig   |   2 +
 configs/socfpga_agilex_defconfig   |   2 +
 ..._atf_defconfig => socfpga_agilex_vab_defconfig} |   4 +
 configs/socfpga_stratix10_atf_defconfig|   2 +
 configs/socfpga_stratix10_defconfig|   2 +
 drivers/ddr/altera/Kconfig |   6 +-
 drivers/fpga/Kconfig   |   2 +-
 drivers/sysreset/Kconfig   |   2 +-
 include/configs/socfpga_soc64_common.h |  10 +-
 scripts/Makefile.spl   |   7 +
 23 files changed, 406 insertions(+), 30 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/include/mach/secure_vab.h
 create mode 100644 arch/arm/mach-socfpga/secure_vab.c
 create mode 100644 arch/arm/mach-socfpga/vab.c
 copy configs/{socfpga_agilex_atf_defconfig => socfpga_agilex_vab_defconfig} 
(91%)

-- 
2.13.0



Re: [PATCH v2] usb: dfu: Migrate CONFIG_SYS_DFU_DATA_BUF_SIZE and CONFIG_SYS_DFU_MAX_FILE_SIZE to Kconfig

2021-02-26 Thread Oleksandr Suvorov
Hi Aswath,

On Fri, Feb 26, 2021 at 3:44 PM Aswath Govindraju  wrote:
>
> Currently the config options CONFIG_SYS_DFU_DATA_BUF_SIZE and
> CONFIG_SYS_DFU_MAX_FILE_SIZE are being set in include/configs/.h
> files and also in _defconfig files without a Kconfig option. It
> is easier for users to set these configs in defconfig files than in config
> header files as they are a part of the source code.
>
> Add Kconfig symbols, and update the defconfigs by using tools/moveconfig.py
> script.
>
> Suggested-by: Pratyush Yadav 
> Signed-off-by: Aswath Govindraju 

For colibri-imx6ull and colibri_vf
Reviewed-by: Oleksandr Suvorov 
And for the rest
Acked-by: Oleksandr Suvorov 


> ---
>
> Changes since v1:
> - Removed CONFIG_SYS_DFU_MAX_FILE_SIZE in defconfig files, where it was
>   not defined previously. The list of files in which this change is made
>   are listed below,
>   configs/colibri-imx6ull_defconfig
>   configs/colibri_vf_defconfig
>   configs/corvus_defconfig
>   configs/dh_imx6_defconfig
>   configs/draco_defconfig
>   configs/etamin_defconfig
>   configs/odroid-xu3_defconfig
>   configs/odroid_defconfig
>   configs/origen_defconfig
>   configs/pico-dwarf-imx6ul_defconfig
>   configs/pico-hobbit-imx6ul_defconfig
>   configs/pico-imx6_defconfig
>   configs/pico-imx6ul_defconfig
>   configs/pico-pi-imx6ul_defconfig
>   configs/pxm2_defconfig
>   configs/rastaban_defconfig
>   configs/rut_defconfig
>   configs/s5p_goni_defconfig
>   configs/s5pc210_universal_defconfig
>   configs/smartweb_defconfig
>   configs/socfpga_arria5_defconfig
>   configs/socfpga_cyclone5_defconfig
>   configs/socfpga_dbm_soc1_defconfig
>   configs/socfpga_de0_nano_soc_defconfig
>   configs/socfpga_de10_nano_defconfig
>   configs/socfpga_mcvevk_defconfig
>   configs/socfpga_sockit_defconfig
>   configs/socfpga_socrates_defconfig
>   configs/socfpga_vining_fpga_defconfig
>   configs/taurus_defconfig
>   configs/thuban_defconfig
>   configs/topic_miami_defconfig
>   configs/topic_miamilite_defconfig
>   configs/topic_miamiplus_defconfig
>   configs/trats2_defconfig
>   configs/trats_defconfig
>   configs/warp7_bl33_defconfig
>   configs/warp7_defconfig
>   configs/warp_defconfig
>   configs/xilinx_versal_virt_defconfig
>   configs/xilinx_zynq_virt_defconfig
>   configs/xilinx_zynqmp_virt_defconfig
>
> Link to v1,
> https://patchwork.ozlabs.org/project/uboot/patch/20210223061427.20742-1-a-govindr...@ti.com/
>
>  configs/am65x_evm_a53_defconfig   |  2 ++
>  configs/am65x_evm_r5_usbdfu_defconfig |  2 ++
>  configs/am65x_hs_evm_a53_defconfig|  2 ++
>  configs/beaver_defconfig  |  2 ++
>  configs/cei-tk1-som_defconfig |  2 ++
>  configs/colibri-imx6ull_defconfig |  1 +
>  configs/colibri_vf_defconfig  |  1 +
>  configs/corvus_defconfig  |  1 +
>  configs/dalmore_defconfig |  2 ++
>  configs/dh_imx6_defconfig |  1 +
>  configs/draco_defconfig   |  1 +
>  configs/e2220-1170_defconfig  |  2 ++
>  configs/etamin_defconfig  |  1 +
>  configs/jetson-tk1_defconfig  |  2 ++
>  configs/nyan-big_defconfig|  2 ++
>  configs/odroid-xu3_defconfig  |  1 +
>  configs/odroid_defconfig  |  1 +
>  configs/origen_defconfig  |  1 +
>  configs/p2371-_defconfig  |  2 ++
>  configs/p2371-2180_defconfig  |  2 ++
>  configs/p2571_defconfig   |  2 ++
>  configs/p3450-_defconfig  |  2 ++
>  configs/pico-dwarf-imx6ul_defconfig   |  1 +
>  configs/pico-hobbit-imx6ul_defconfig  |  1 +
>  configs/pico-imx6_defconfig   |  1 +
>  configs/pico-imx6ul_defconfig |  1 +
>  configs/pico-pi-imx6ul_defconfig  |  1 +
>  configs/pxm2_defconfig|  1 +
>  configs/rastaban_defconfig|  1 +
>  configs/rpi_4_32b_defconfig   |  2 ++
>  configs/rpi_4_defconfig   |  2 ++
>  configs/rut_defconfig |  1 +
>  configs/s5p_goni_defconfig|  1 +
>  configs/s5pc210_universal_defconfig   |  1 +
>  configs/smartweb_defconfig|  1 +
>  configs/socfpga_arria5_defconfig  |  1 +
>  configs/socfpga_cyclone5_defconfig|  1 +
>  configs/socfpga_dbm_soc1_defconfig|  1 +
>  configs/socfpga_de0_nano_soc_defconfig|  1 +
>  configs/socfpga_de10_nano_defconfig   |  1 +
>  configs/socfpga_mcvevk_defconfig  |  1 +
>  configs/socfpga_sockit_defconfig  |  1 +
>  configs/socfpga_socrates_defconfig|  1 +
>  configs/socfpga_vining_fpga_defconfig |  1 +
>  configs/taurus_defconfig  |  1 +
>  configs/thuban_defconfig  |  1 +
>  configs/topic_miami_defconfig |  1 +
>  configs/topic_miamilite_defconfig |  1 +
>  configs/topic_miamiplus_defconfig |  1 +
>  

Re: [PATCH 0/2] pinctrl: at91-pio4: add support for slew-rate

2021-02-26 Thread Eugen.Hristev
On 27.01.2021 15:00, Claudiu Beznea wrote:
> Hi,
> 
> This series adds support for slew rate on AT91 PIO4 driver.
> The support is enabled on SAMA7G5.
> 
> Thank you,
> Claudiu Beznea
> 
> Claudiu Beznea (2):
>dt-bindings: pinctrl: at91-pio4: add slew-rate
>pinctrl: at91-pio4: add support for slew-rate
> 
>   arch/arm/mach-at91/include/mach/atmel_pio4.h   |  1 +
>   .../pinctrl/atmel,at91-pio4-pinctrl.txt|  7 +++---
>   drivers/pinctrl/pinctrl-at91-pio4.c| 26 
> +++---
>   3 files changed, 28 insertions(+), 6 deletions(-)
> 

Applied both to u-boot-atmel/next, thanks !


Re: [RFC PATCH] nvme: Always invalidate whole cqes[] array

2021-02-26 Thread Suniel Mahesh
On Fri, Feb 26, 2021 at 8:12 PM Jagan Teki  wrote:
>
> Hi Suniel,
>
> On Mon, Feb 8, 2021 at 7:02 PM Andre Przywara  wrote:
> >
> > At the moment nvme_read_completion_status() tries to invidate a single
> > member of the cqes[] array, which is shady as just a single entry is
> > not cache line aligned.
> > The structure is dictated by hardware, and with 16 bytes is smaller than
> > any cache line we usually deal with. Also multiple entries need to be
> > consecutive in memory, so we can't pad them to cover a whole cache line.
> >
> > As a consequence we can only always invalidate all of them - U-Boot just
> > uses two of them anyway. This is fine, as they are only ever read by the
> > CPU (apart from the initial zeroing), so they can't become dirty.
> >
> > Make this obvious by always invalidating the whole array, regardless of
> > the entry number we are about to read.
> > Also blow up the allocation size to cover whole cache lines, to avoid
> > other heap allocations to sneak in.
> >
> > Signed-off-by: Andre Przywara 
> > ---
> > Hi,
> >
> > this is just compile tested, and should fix the only questionable
> > cache invalidate call in this driver.
> > Please verify if this fixes any issues!
>
> Can you test this on RK3399?

Hi Jagan/All

Here are the test results after applying this patch on mainline. The
patch has been tested on
roc-rk3399-pc an RK3399 based SBC. It looks fine, below is the log:

U-Boot TPL 2021.04-rc2-00169-g958c213e3f (Feb 26 2021 - 21:38:32)
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2021.04-rc2-00169-g958c213e3f (Feb 26 2021 - 21:38:32 +0530)
Loading Environment from SPIFlash... *** Warning -
spi_flash_probe_bus_cs() failed, using default environment

Trying to boot from MMC1

U-Boot 2021.04-rc2-00169-g958c213e3f (Feb 26 2021 - 21:38:32 +0530)

SoC: Rockchip rk3399
Reset cause: POR
Model: Firefly ROC-RK3399-PC Mezzanine Board
DRAM:  3.9 GiB
PMIC:  RK808
MMC:   mmc@fe31: 2, mmc@fe32: 1, sdhci@fe33: 0
Loading Environment from SPIFlash... jedec_spi_nor flash@0:
unrecognized JEDEC id bytes: ff, ff, ff
*** Warning - spi_flash_probe_bus_cs() failed, using default environment

In:serial
Out:   serial
Err:   serial
Model: Firefly ROC-RK3399-PC Mezzanine Board
Net:
Error: ethernet@fe30 address not set.
No ethernet found.

Hit any key to stop autoboot:  0
=>
=>
=> pci
Scanning PCI devices on bus 0
BusDevFun  VendorId   DeviceId   Device Class   Sub-Class
_
00.00.00   0x1d87 0x0100 Bridge device   0x04

=> nvme scan

=> nvme info
Device 0: Vendor: 0x15b7 Rev: 21110001 Prod: 2031C2440521
Type: Hard Disk
Capacity: 244198.3 MB = 238.4 GB (500118192 x 512)
=> nvme device

IDE device 0: Vendor: 0x15b7 Rev: 21110001 Prod: 2031C2440521
Type: Hard Disk
Capacity: 244198.3 MB = 238.4 GB (500118192 x 512)


Tested-by: Suniel Mahesh 

>
> Jagan.


RE: [v2] Makefile: socfpga: Add target to generate hex output for combined spl and dtb

2021-02-26 Thread Lim, Elly Siew Chin
Hi Ley Foon,

> -Original Message-
> From: Tan, Ley Foon 
> Sent: Friday, February 26, 2021 5:38 PM
> To: Lim, Elly Siew Chin ; u-boot@lists.denx.de
> Cc: Marek Vasut ; See, Chin Liang
> ; Simon Goldschmidt
> ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan,
> Yau Wai 
> Subject: RE: [v2] Makefile: socfpga: Add target to generate hex output for
> combined spl and dtb
> 
> 
> 
> > -Original Message-
> > From: Lim, Elly Siew Chin 
> > Sent: Wednesday, February 24, 2021 9:54 AM
> > To: u-boot@lists.denx.de
> > Cc: Marek Vasut ; Tan, Ley Foon
> > ; See, Chin Liang ;
> > Simon Goldschmidt ; Chee, Tien Fong
> > ; Westergreen, Dalon
> > ; Simon Glass ; Gan,
> > Yau Wai ; Lim, Elly Siew Chin
> > 
> > Subject: [v2] Makefile: socfpga: Add target to generate hex output for
> > combined spl and dtb
> >
> > From: Dalon Westergreen 
> >
> > Add target to Makefile to generate "u-boot-spl-dtb.hex" for Intel
> > SOCFPGA
> > SOC64 devices (Stratix 10 and Agilex). "u-boot-spl-dtb.hex" is hex
> > formatted spl with and offset of CONFIG_SPL_TEXT_BASE. It combines the
> > spl image and dtb.
> > "u-boot-spl-dtb.hex" is needed to generate the final configuration
> > bitstream for Intel SOCFPGA SOC64 devices.
> >
> > Signed-off-by: Dalon Westergreen 
> > Signed-off-by: Siew Chin Lim 
> >
> > ---
> > v2: Update commit message
> > ---
> > ---
> >  Makefile   | 11 ++-
> >  include/configs/socfpga_soc64_common.h |  2 +-
> >  scripts/Makefile.spl   |  8 
> >  3 files changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 4da46dea39..f1adc9aa23 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1263,11 +1263,6 @@ OBJCOPYFLAGS_u-boot-nodtb.bin := -O binary \
> > $(if $(CONFIG_X86_16BIT_INIT),-R .start16 -R .resetvec) \
> > $(if $(CONFIG_MPC85XX_HAVE_RESET_VECTOR),-R .bootpg
> -R .resetvec)
> >
> > -OBJCOPYFLAGS_u-boot-spl.hex = $(OBJCOPYFLAGS_u-boot.hex)
> > -
> > -spl/u-boot-spl.hex: spl/u-boot-spl FORCE
> > -   $(call if_changed,objcopy)
> > -
> >  binary_size_check: u-boot-nodtb.bin FORCE
> > @file_size=$(shell wc -c u-boot-nodtb.bin | awk '{print $$1}') ; \
> > map_size=$(shell cat u-boot.map | \
> > @@ -1935,6 +1930,12 @@ spl/u-boot-spl.bin: spl/u-boot-spl
> > @:
> > $(SPL_SIZE_CHECK)
> >
> > +spl/u-boot-spl-dtb.bin: spl/u-boot-spl
> > +   @:
> > +
> > +spl/u-boot-spl-dtb.hex: spl/u-boot-spl
> > +   @:
> > +
> >  spl/u-boot-spl: tools prepare \
> > $(if
> >
> $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SPL_OF_PLATD
> > ATA),dts/dt.dtb) \
> > $(if
> >
> $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_TPL_OF_PLATD
> > ATA),dts/dt.dtb)
> > diff --git a/include/configs/socfpga_soc64_common.h
> > b/include/configs/socfpga_soc64_common.h
> > index fdcd7d3e9a..1af359466c 100644
> > --- a/include/configs/socfpga_soc64_common.h
> > +++ b/include/configs/socfpga_soc64_common.h
> > @@ -200,7 +200,7 @@ unsigned int cm_get_l4_sys_free_clk_hz(void);
> >   * 0x8000_ .. End of SDRAM_1 (assume 2GB)
> >   *
> >   */
> > -#define CONFIG_SPL_TARGET  "spl/u-boot-spl.hex"
> > +#define CONFIG_SPL_TARGET  "spl/u-boot-spl-dtb.hex"
> >  #define CONFIG_SPL_MAX_SIZECONFIG_SYS_INIT_RAM_SIZE
> >  #define CONFIG_SPL_STACK   CONFIG_SYS_INIT_SP_ADDR
> >  #define CONFIG_SPL_BSS_MAX_SIZE0x10/* 1
> MB */
> > diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl index
> > ea4e045769..625e06d0d9 100644
> > --- a/scripts/Makefile.spl
> > +++ b/scripts/Makefile.spl
> > @@ -229,6 +229,9 @@ ifneq
> >
> ($(CONFIG_TARGET_SOCFPGA_GEN5)$(CONFIG_TARGET_SOCFPGA_ARRIA
> > 10),)
> >  INPUTS-y   += $(obj)/$(SPL_BIN).sfp
> >  endif
> >
> > +INPUTS-$(CONFIG_TARGET_SOCFPGA_STRATIX10)  += $(obj)/u-boot-spl-
> > dtb.hex
> > +INPUTS-$(CONFIG_TARGET_SOCFPGA_AGILEX) += $(obj)/u-
> > boot-spl-dtb.hex
> 
> Can use CONFIG_TARGET_SOCFPGA_SOC64.

I have changed to use TARGET_SOCFPGA_SOC64.

I have included this patch in 4th version of VAB series because it is depending 
on TARGET_SOCFPGA_SOC64 patch in VAB series. Thanks.

> 
> Regards
> Ley Foon


RE: [v3 2/6] arm: socfpga: soc64: Support Vendor Authorized Boot (VAB)

2021-02-26 Thread Lim, Elly Siew Chin
Hi Ley Foon,

> -Original Message-
> From: Tan, Ley Foon 
> Sent: Friday, February 26, 2021 5:56 PM
> To: Lim, Elly Siew Chin ; u-boot@lists.denx.de
> Cc: Marek Vasut ; See, Chin Liang
> ; Simon Goldschmidt
> ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan,
> Yau Wai 
> Subject: RE: [v3 2/6] arm: socfpga: soc64: Support Vendor Authorized Boot
> (VAB)
> 
> 
> 
> > -Original Message-
> > From: Lim, Elly Siew Chin 
> > Sent: Friday, February 5, 2021 6:52 PM
> > To: u-boot@lists.denx.de
> > Cc: Marek Vasut ; Tan, Ley Foon
> > ; See, Chin Liang ;
> > Simon Goldschmidt ; Chee, Tien Fong
> > ; Westergreen, Dalon
> > ; Simon Glass ; Gan,
> > Yau Wai ; Lim, Elly Siew Chin
> > 
> > Subject: [v3 2/6] arm: socfpga: soc64: Support Vendor Authorized Boot
> > (VAB)
> >
> > Vendor Authorized Boot is a security feature for authenticating the
> > images such as U-Boot, ARM trusted Firmware, Linux kernel, device tree
> > blob and etc loaded from FIT. After those images are loaded from FIT,
> > the VAB certificate and signature block appended at the end of each
> > image are sent to Secure Device Manager (SDM) for authentication.
> > U-Boot will validate the
> > SHA384 of the image against the SHA384 hash stored in the VAB
> > certificate before sending the image to SDM for authentication.
> >
> > Signed-off-by: Siew Chin Lim 
> >
> > ---
> > v3
> > ---
> > - Add description for function 'socfpga_vendor_authentication'.
> > - Relocate vab certificate to first memory bank before trigger SMC call
> >   to send mailbox command because ATF only able to access first memory
> > bank.
> > - Report error instead of bypass the authentication in SPL if
> >   Secure Device Manager (SDM) does not support VAB.
> > - Print success string if VAB success.
> > - Replace #ifdef with if(IS_ENABLED(CONFIG_...)).
> > ---
> >  arch/arm/mach-socfpga/Kconfig|  15 ++
> >  arch/arm/mach-socfpga/Makefile   |   2 +
> >  arch/arm/mach-socfpga/include/mach/mailbox_s10.h |   1 +
> >  arch/arm/mach-socfpga/include/mach/secure_vab.h  |  63 +++
> >  arch/arm/mach-socfpga/secure_vab.c   | 218
> > +++
> 
> [...]
> 
> 
> > +void board_fit_image_post_process(void **p_image, size_t *p_size) {
> > +   if (socfpga_vendor_authentication(p_image, p_size))
> > +   hang();
> > +}
> > +
> > +void board_prep_linux(bootm_headers_t *images) {
> > +   if (!IS_ENABLED(CONFIG_SPL_BUILD)) {
> > +   if
> > (!IS_ENABLED(CONFIG_SECURE_VAB_AUTH_ALLOW_NON_FIT_IMAGE)) {
> > +   /*
> > +* Ensure the OS is always booted from FIT and with
> > +* VAB signed certificate
> > +*/
> > +   if (!images->fit_uname_cfg) {
> > +   printf("Please use FIT with VAB signed
> > images!\n");
> > +   hang();
> > +   }
> > +
> > +   env_set_hex("fdt_addr", (ulong)images->ft_addr);
> > +   debug("images->ft_addr = 0x%08lx\n",
> > (ulong)images->ft_addr);
> > +   }
> > +
> > +   if (IS_ENABLED(CONFIG_CADENCE_QSPI)) {
> > +   if (env_get("linux_qspi_enable"))
> > +
> > run_command(env_get("linux_qspi_enable"), 0);
> > +   }
> > +   }
> > +}
> 
> Move board_fit_image_post_process() and board_prep_linux() outside of
> this file, can be in a new file.
> These 2 functions should be common, and can be used without VAB is
> enabled.

I have moved both of these board_* functions to arch/arm/mach-socfpga/board.c. 
I have send 4th version of VAB series for review. Thanks.

> 
> Regards
> Ley Foon



Re: [RFC PATCH] nvme: Always invalidate whole cqes[] array

2021-02-26 Thread Neil Armstrong
On 08/02/2021 14:31, Andre Przywara wrote:
> At the moment nvme_read_completion_status() tries to invidate a single
> member of the cqes[] array, which is shady as just a single entry is
> not cache line aligned.
> The structure is dictated by hardware, and with 16 bytes is smaller than
> any cache line we usually deal with. Also multiple entries need to be
> consecutive in memory, so we can't pad them to cover a whole cache line.
> 
> As a consequence we can only always invalidate all of them - U-Boot just
> uses two of them anyway. This is fine, as they are only ever read by the
> CPU (apart from the initial zeroing), so they can't become dirty.
> 
> Make this obvious by always invalidating the whole array, regardless of
> the entry number we are about to read.
> Also blow up the allocation size to cover whole cache lines, to avoid
> other heap allocations to sneak in.
> 
> Signed-off-by: Andre Przywara 
> ---
> Hi,
> 
> this is just compile tested, and should fix the only questionable
> cache invalidate call in this driver.
> Please verify if this fixes any issues!
> 
> Cheers,
> Andre
> 
>  drivers/nvme/nvme.c | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> index 5d6331ad346..c9efeff4bc9 100644
> --- a/drivers/nvme/nvme.c
> +++ b/drivers/nvme/nvme.c
> @@ -22,6 +22,8 @@
>  #define NVME_AQ_DEPTH2
>  #define NVME_SQ_SIZE(depth)  (depth * sizeof(struct nvme_command))
>  #define NVME_CQ_SIZE(depth)  (depth * sizeof(struct nvme_completion))
> +#define NVME_CQ_ALLOCATION   ALIGN(NVME_CQ_SIZE(NVME_Q_DEPTH), \
> +   ARCH_DMA_MINALIGN)
>  #define ADMIN_TIMEOUT60
>  #define IO_TIMEOUT   30
>  #define MAX_PRP_POOL 512
> @@ -144,8 +146,14 @@ static __le16 nvme_get_cmd_id(void)
>  
>  static u16 nvme_read_completion_status(struct nvme_queue *nvmeq, u16 index)
>  {
> - u64 start = (ulong)>cqes[index];
> - u64 stop = start + sizeof(struct nvme_completion);
> + /*
> +  * Single CQ entries are always smaller than a cache line, so we
> +  * can't invalidate them individually. However CQ entries are
> +  * read only by the CPU, so it's safe to always invalidate all of them,
> +  * as the cache line should never become dirty.
> +  */
> + ulong start = (ulong)>cqes[0];
> + ulong stop = start + NVME_CQ_ALLOCATION;
>  
>   invalidate_dcache_range(start, stop);
>  
> @@ -241,7 +249,7 @@ static struct nvme_queue *nvme_alloc_queue(struct 
> nvme_dev *dev,
>   return NULL;
>   memset(nvmeq, 0, sizeof(*nvmeq));
>  
> - nvmeq->cqes = (void *)memalign(4096, NVME_CQ_SIZE(depth));
> + nvmeq->cqes = (void *)memalign(4096, NVME_CQ_ALLOCATION);
>   if (!nvmeq->cqes)
>   goto free_nvmeq;
>   memset((void *)nvmeq->cqes, 0, NVME_CQ_SIZE(depth));
> @@ -339,7 +347,7 @@ static void nvme_init_queue(struct nvme_queue *nvmeq, u16 
> qid)
>   nvmeq->q_db = >dbs[qid * 2 * dev->db_stride];
>   memset((void *)nvmeq->cqes, 0, NVME_CQ_SIZE(nvmeq->q_depth));
>   flush_dcache_range((ulong)nvmeq->cqes,
> -(ulong)nvmeq->cqes + NVME_CQ_SIZE(nvmeq->q_depth));
> +(ulong)nvmeq->cqes + NVME_CQ_ALLOCATION);
>   dev->online_queues++;
>  }
>  
> 

On Amlogic A311D, fixes timeout on nvme scan:

Tested-by: Neil Armstrong 


[v4 7/7] Makefile: socfpga: Add target to generate hex output for combined spl and dtb

2021-02-26 Thread Siew Chin Lim
From: Dalon Westergreen 

Add target to Makefile to generate "u-boot-spl-dtb.hex" for Intel SOCFPGA
SOC64 devices (Stratix 10 and Agilex). "u-boot-spl-dtb.hex" is hex formatted
spl with and offset of CONFIG_SPL_TEXT_BASE. It combines the spl image and dtb.
"u-boot-spl-dtb.hex" is needed to generate the final configuration bitstream
for Intel SOCFPGA SOC64 devices.

Signed-off-by: Dalon Westergreen 
Signed-off-by: Siew Chin Lim 

---
v4
---
- Replace CONFIG_TARGET_SOCFPGA_STRATIX10/AGILEX with 
CONFIG_TARGET_SOCFPGA_SOC64.
- Add this patch into 'VAB' series because it is depending on
  CONFIG_TARGET_SOCFPGA_SOC64 patch.
---
 Makefile   | 11 ++-
 include/configs/socfpga_soc64_common.h |  2 +-
 scripts/Makefile.spl   |  7 +++
 3 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/Makefile b/Makefile
index 23dd11f723..dd7781b43c 100644
--- a/Makefile
+++ b/Makefile
@@ -1263,11 +1263,6 @@ OBJCOPYFLAGS_u-boot-nodtb.bin := -O binary \
$(if $(CONFIG_X86_16BIT_INIT),-R .start16 -R .resetvec) \
$(if $(CONFIG_MPC85XX_HAVE_RESET_VECTOR),-R .bootpg -R 
.resetvec)
 
-OBJCOPYFLAGS_u-boot-spl.hex = $(OBJCOPYFLAGS_u-boot.hex)
-
-spl/u-boot-spl.hex: spl/u-boot-spl FORCE
-   $(call if_changed,objcopy)
-
 binary_size_check: u-boot-nodtb.bin FORCE
@file_size=$(shell wc -c u-boot-nodtb.bin | awk '{print $$1}') ; \
map_size=$(shell cat u-boot.map | \
@@ -1931,6 +1926,12 @@ spl/u-boot-spl.bin: spl/u-boot-spl
@:
$(SPL_SIZE_CHECK)
 
+spl/u-boot-spl-dtb.bin: spl/u-boot-spl
+   @:
+
+spl/u-boot-spl-dtb.hex: spl/u-boot-spl
+   @:
+
 spl/u-boot-spl: tools prepare \
$(if 
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SPL_OF_PLATDATA),dts/dt.dtb) \
$(if 
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_TPL_OF_PLATDATA),dts/dt.dtb)
diff --git a/include/configs/socfpga_soc64_common.h 
b/include/configs/socfpga_soc64_common.h
index 0e54601257..1cfa190047 100644
--- a/include/configs/socfpga_soc64_common.h
+++ b/include/configs/socfpga_soc64_common.h
@@ -194,7 +194,7 @@ unsigned int cm_get_l4_sys_free_clk_hz(void);
  * 0x8000_ .. End of SDRAM_1 (assume 2GB)
  *
  */
-#define CONFIG_SPL_TARGET  "spl/u-boot-spl.hex"
+#define CONFIG_SPL_TARGET  "spl/u-boot-spl-dtb.hex"
 #define CONFIG_SPL_MAX_SIZECONFIG_SYS_INIT_RAM_SIZE
 #define CONFIG_SPL_STACK   CONFIG_SYS_INIT_SP_ADDR
 #define CONFIG_SPL_BSS_MAX_SIZE0x10/* 1 MB */
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index ea4e045769..1fd63efdfd 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -229,6 +229,8 @@ ifneq 
($(CONFIG_TARGET_SOCFPGA_GEN5)$(CONFIG_TARGET_SOCFPGA_ARRIA10),)
 INPUTS-y   += $(obj)/$(SPL_BIN).sfp
 endif
 
+INPUTS-$(CONFIG_TARGET_SOCFPGA_SOC64) += $(obj)/u-boot-spl-dtb.hex
+
 ifdef CONFIG_ARCH_SUNXI
 INPUTS-y   += $(obj)/sunxi-spl.bin
 
@@ -389,6 +391,11 @@ $(obj)/$(SPL_BIN).sfp: $(obj)/$(SPL_BIN).bin FORCE
 MKIMAGEFLAGS_sunxi-spl.bin = -T sunxi_egon \
-n $(CONFIG_DEFAULT_DEVICE_TREE)
 
+OBJCOPYFLAGS_u-boot-spl-dtb.hex := -I binary -O ihex 
--change-address=$(CONFIG_SPL_TEXT_BASE)
+
+$(obj)/u-boot-spl-dtb.hex: $(obj)/u-boot-spl-dtb.bin FORCE
+   $(call if_changed,objcopy)
+
 $(obj)/sunxi-spl.bin: $(obj)/$(SPL_BIN).bin FORCE
$(call if_changed,mkimage)
 
-- 
2.13.0



[v4 6/7] configs: socfpga: Add defconfig for Agilex with VAB support

2021-02-26 Thread Siew Chin Lim
Booting Agilex with Vendor Authorized Boot.

Signed-off-by: Siew Chin Lim 
---
 .../{socfpga_agilex_atf_defconfig => socfpga_agilex_vab_defconfig}| 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
 copy configs/{socfpga_agilex_atf_defconfig => socfpga_agilex_vab_defconfig} 
(92%)

diff --git a/configs/socfpga_agilex_atf_defconfig 
b/configs/socfpga_agilex_vab_defconfig
similarity index 92%
copy from configs/socfpga_agilex_atf_defconfig
copy to configs/socfpga_agilex_vab_defconfig
index 7adda02b00..bca663ed61 100644
--- a/configs/socfpga_agilex_atf_defconfig
+++ b/configs/socfpga_agilex_vab_defconfig
@@ -9,6 +9,7 @@ CONFIG_ENV_OFFSET=0x200
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x0200
 CONFIG_DM_GPIO=y
 CONFIG_SPL_TEXT_BASE=0xFFE0
+CONFIG_SOCFPGA_SECURE_VAB_AUTH=y
 CONFIG_TARGET_SOCFPGA_AGILEX_SOCDK=y
 CONFIG_IDENT_STRING="socfpga_agilex"
 CONFIG_SPL_FS_FAT=y
@@ -17,11 +18,12 @@ CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_LOAD_FIT_ADDRESS=0x0200
 # CONFIG_USE_SPL_FIT_GENERATOR is not set
+# CONFIG_LEGACY_IMAGE_FORMAT is not set
 CONFIG_BOOTDELAY=5
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="earlycon"
 CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="run fatscript; run mmcfitload; run linux_qspi_enable; run 
mmcfitboot"
+CONFIG_BOOTCOMMAND="run fatscript; run mmcfitload; run mmcfitboot"
 CONFIG_SPL_CACHE=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SPL_ATF=y
-- 
2.13.0



[v4 5/7] configs: socfpga: soc64: Move CONFIG_BOOTCOMMAND to defconfig

2021-02-26 Thread Siew Chin Lim
CONFIG_BOOTCOMMAND have been moved to Kconfig.boot. This patch
move the CONFIG_BOOTCOMMAND macro from socfpga_soc64_common.h to
*_defconfig file for both Stratix 10 and Agilex.

Signed-off-by: Siew Chin Lim 
---
 configs/socfpga_agilex_atf_defconfig| 2 ++
 configs/socfpga_agilex_defconfig| 2 ++
 configs/socfpga_stratix10_atf_defconfig | 2 ++
 configs/socfpga_stratix10_defconfig | 2 ++
 include/configs/socfpga_soc64_common.h  | 8 +---
 5 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/configs/socfpga_agilex_atf_defconfig 
b/configs/socfpga_agilex_atf_defconfig
index ebe6ce63a4..7adda02b00 100644
--- a/configs/socfpga_agilex_atf_defconfig
+++ b/configs/socfpga_agilex_atf_defconfig
@@ -20,6 +20,8 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x0200
 CONFIG_BOOTDELAY=5
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="earlycon"
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="run fatscript; run mmcfitload; run linux_qspi_enable; run 
mmcfitboot"
 CONFIG_SPL_CACHE=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SPL_ATF=y
diff --git a/configs/socfpga_agilex_defconfig b/configs/socfpga_agilex_defconfig
index 230d3c2ce5..3d5d39fe0f 100644
--- a/configs/socfpga_agilex_defconfig
+++ b/configs/socfpga_agilex_defconfig
@@ -18,6 +18,8 @@ CONFIG_DEFAULT_DEVICE_TREE="socfpga_agilex_socdk"
 CONFIG_BOOTDELAY=5
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="earlycon"
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="run fatscript; run mmcload; run linux_qspi_enable; run 
mmcboot"
 CONFIG_SPL_CACHE=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_HUSH_PARSER=y
diff --git a/configs/socfpga_stratix10_atf_defconfig 
b/configs/socfpga_stratix10_atf_defconfig
index d1b12113ab..8dbb7424ba 100644
--- a/configs/socfpga_stratix10_atf_defconfig
+++ b/configs/socfpga_stratix10_atf_defconfig
@@ -20,6 +20,8 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x0200
 CONFIG_BOOTDELAY=5
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="earlycon"
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="run fatscript; run mmcfitload; run linux_qspi_enable; run 
mmcfitboot"
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SPL_ATF=y
 CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
diff --git a/configs/socfpga_stratix10_defconfig 
b/configs/socfpga_stratix10_defconfig
index 3df44bb88d..2d145e1a5f 100644
--- a/configs/socfpga_stratix10_defconfig
+++ b/configs/socfpga_stratix10_defconfig
@@ -20,6 +20,8 @@ CONFIG_SPL_OPTIMIZE_INLINING=y
 CONFIG_BOOTDELAY=5
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="earlycon"
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="run fatscript; run mmcload; run linux_qspi_enable; run 
mmcboot"
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="SOCFPGA_STRATIX10 # "
diff --git a/include/configs/socfpga_soc64_common.h 
b/include/configs/socfpga_soc64_common.h
index fdcd7d3e9a..0e54601257 100644
--- a/include/configs/socfpga_soc64_common.h
+++ b/include/configs/socfpga_soc64_common.h
@@ -79,19 +79,13 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
 #endif /* CONFIG_CADENCE_QSPI */
 
 /*
- * Boot arguments passed to the boot command. The value of
- * CONFIG_BOOTARGS goes into the environment value "bootargs".
- * Do note the value will override also the chosen node in FDT blob.
+ * Environment variable
  */
 
 #ifdef CONFIG_FIT
 #define CONFIG_BOOTFILE "kernel.itb"
-#define CONFIG_BOOTCOMMAND "run fatscript; run mmcfitload;run 
linux_qspi_enable;" \
-  "run mmcfitboot"
 #else
 #define CONFIG_BOOTFILE "Image"
-#define CONFIG_BOOTCOMMAND "run fatscript; run mmcload;run linux_qspi_enable;" 
\
-  "run mmcboot"
 #endif
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
-- 
2.13.0



[v4 4/7] arm: socfpga: dts: soc64: Update filename in binman node of FIT image with VAB support

2021-02-26 Thread Siew Chin Lim
FIT image of Vendor Authentication Coot (VAB) contains signed images.

Signed-off-by: Siew Chin Lim 
---
 arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi 
b/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi
index cf365590a8..4b30473743 100644
--- a/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi
+++ b/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi
@@ -117,4 +117,26 @@
};
 };
 
+#if defined(CONFIG_SOCFPGA_SECURE_VAB_AUTH)
+_blob {
+   filename = "signed-u-boot-nodtb.bin";
+};
+
+_blob {
+   filename = "signed-bl31.bin";
+};
+
+_fdt_blob {
+   filename = "signed-u-boot.dtb";
+};
+
+_blob {
+   filename = "signed-Image";
+};
+
+_fdt_blob {
+   filename = "signed-linux.dtb";
+};
+#endif
+
 #endif
-- 
2.13.0



[v4 3/7] arm: socfpga: cmd: Support 'vab' command

2021-02-26 Thread Siew Chin Lim
Support 'vab' command to perform vendor authentication.

Command format: vab addr len
Authorize 'len' bytes starting at 'addr' via vendor public key

Signed-off-by: Siew Chin Lim 

---
v3
---
- Remove the print in 'vab' command to avoid duplicated print out.
  The 'socfpga_vendor_authntication' function in secure_vab.c will
  print out the string if VAB success.
---
 arch/arm/mach-socfpga/Makefile |  1 +
 arch/arm/mach-socfpga/vab.c| 34 ++
 2 files changed, 35 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/vab.c

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 1f1e21766d..9e63296b38 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -51,6 +51,7 @@ obj-y += reset_manager_s10.o
 obj-$(CONFIG_SOCFPGA_SECURE_VAB_AUTH)  += secure_vab.o
 obj-y  += system_manager_s10.o
 obj-y  += timer_s10.o
+obj-$(CONFIG_SOCFPGA_SECURE_VAB_AUTH)  += vab.o
 obj-y  += wrap_pinmux_config_s10.o
 obj-y  += wrap_pll_config_s10.o
 endif
diff --git a/arch/arm/mach-socfpga/vab.c b/arch/arm/mach-socfpga/vab.c
new file mode 100644
index 00..85b3f30211
--- /dev/null
+++ b/arch/arm/mach-socfpga/vab.c
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Intel Corporation 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static int do_vab(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+   unsigned long addr, len;
+
+   if (argc < 3)
+   return CMD_RET_USAGE;
+
+   addr = simple_strtoul(argv[1], NULL, 16);
+   len = simple_strtoul(argv[2], NULL, 16);
+
+   if (socfpga_vendor_authentication((void *), (size_t *)) != 0)
+   return CMD_RET_FAILURE;
+
+   return 0;
+}
+
+U_BOOT_CMD(
+   vab,3,  2,  do_vab,
+   "perform vendor authorization",
+   "addr len   - authorize 'len' bytes starting at\n"
+   " 'addr' via vendor public key"
+);
-- 
2.13.0



[v4 2/7] arm: socfpga: soc64: Support Vendor Authorized Boot (VAB)

2021-02-26 Thread Siew Chin Lim
Vendor Authorized Boot is a security feature for authenticating
the images such as U-Boot, ARM trusted Firmware, Linux kernel,
device tree blob and etc loaded from FIT. After those images are
loaded from FIT, the VAB certificate and signature block appended
at the end of each image are sent to Secure Device Manager (SDM)
for authentication. U-Boot will validate the SHA384 of the image
against the SHA384 hash stored in the VAB certificate before
sending the image to SDM for authentication.

Signed-off-by: Siew Chin Lim 

---
v4:
- Move function 'board_fit_image_post_process' and 'board_prep_linux' to
  arch/arm/mach-socfpga/board.c

v3:
- Add description for function 'socfpga_vendor_authentication'.
- Relocate vab certificate to first memory bank before trigger SMC call
  to send mailbox command because ATF only able to access first memory bank.
- Report error instead of bypass the authentication in SPL if
  Secure Device Manager (SDM) does not support VAB.
- Print success string if VAB success.
- Replace #ifdef with if(IS_ENABLED(CONFIG_...)).
---
 arch/arm/mach-socfpga/Kconfig|  15 ++
 arch/arm/mach-socfpga/Makefile   |   2 +
 arch/arm/mach-socfpga/board.c|  43 +-
 arch/arm/mach-socfpga/include/mach/mailbox_s10.h |   1 +
 arch/arm/mach-socfpga/include/mach/secure_vab.h  |  63 
 arch/arm/mach-socfpga/secure_vab.c   | 186 +++
 common/Kconfig.boot  |   2 +-
 7 files changed, 307 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/include/mach/secure_vab.h
 create mode 100644 arch/arm/mach-socfpga/secure_vab.c

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 9b1abdaabd..0c35406232 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -6,6 +6,21 @@ config ERR_PTR_OFFSET
 config NR_DRAM_BANKS
default 1
 
+config SOCFPGA_SECURE_VAB_AUTH
+   bool "Enable boot image authentication with Secure Device Manager"
+   depends on TARGET_SOCFPGA_AGILEX
+   select FIT_IMAGE_POST_PROCESS
+   select SHA384
+   select SHA512_ALGO
+   select SPL_FIT_IMAGE_POST_PROCESS
+   help
+All images loaded from FIT will be authenticated by Secure Device
+Manager.
+
+config SOCFPGA_SECURE_VAB_AUTH_ALLOW_NON_FIT_IMAGE
+   bool "Allow non-FIT VAB signed images"
+   depends on SOCFPGA_SECURE_VAB_AUTH
+
 config SPL_SIZE_LIMIT
default 0x1 if TARGET_SOCFPGA_GEN5
 
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 82b681d870..1f1e21766d 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -4,6 +4,7 @@
 # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
 #
 # Copyright (C) 2012-2017 Altera Corporation 
+# Copyright (C) 2017-2020 Intel Corporation 
 
 obj-y  += board.o
 obj-y  += clock_manager.o
@@ -47,6 +48,7 @@ obj-y += mailbox_s10.o
 obj-y  += misc_s10.o
 obj-y  += mmu-arm64_s10.o
 obj-y  += reset_manager_s10.o
+obj-$(CONFIG_SOCFPGA_SECURE_VAB_AUTH)  += secure_vab.o
 obj-y  += system_manager_s10.o
 obj-y  += timer_s10.o
 obj-y  += wrap_pinmux_config_s10.o
diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach-socfpga/board.c
index 7993c27646..9f60f2fc05 100644
--- a/arch/arm/mach-socfpga/board.c
+++ b/arch/arm/mach-socfpga/board.c
@@ -6,13 +6,16 @@
  */
 
 #include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -97,3 +100,35 @@ __weak int board_fit_config_name_match(const char *name)
return 0;
 }
 #endif
+
+#if IS_ENABLED(CONFIG_SOCFPGA_SECURE_VAB_AUTH)
+void board_fit_image_post_process(void **p_image, size_t *p_size)
+{
+   if (socfpga_vendor_authentication(p_image, p_size))
+   hang();
+}
+
+void board_prep_linux(bootm_headers_t *images)
+{
+   if (!IS_ENABLED(CONFIG_SPL_BUILD)) {
+   if (!IS_ENABLED(CONFIG_SECURE_VAB_AUTH_ALLOW_NON_FIT_IMAGE)) {
+   /*
+* Ensure the OS is always booted from FIT and with
+* VAB signed certificate
+*/
+   if (!images->fit_uname_cfg) {
+   printf("Please use FIT with VAB signed 
images!\n");
+   hang();
+   }
+
+   env_set_hex("fdt_addr", (ulong)images->ft_addr);
+   debug("images->ft_addr = 0x%08lx\n", 
(ulong)images->ft_addr);
+   }
+
+   if (IS_ENABLED(CONFIG_CADENCE_QSPI)) {
+   if (env_get("linux_qspi_enable"))
+   run_command(env_get("linux_qspi_enable"), 0);
+   }
+   }
+}
+#endif
diff --git a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h 

[v4 1/7] arm: socfpga: Move Stratix10 and Agilex to use TARGET_SOCFPGA_SOC64

2021-02-26 Thread Siew Chin Lim
Create common macro TARGET_SOCFPGA_SOC64 for Stratix10 and Agilex.

Signed-off-by: Siew Chin Lim 
---
 arch/arm/Kconfig| 6 +++---
 arch/arm/mach-socfpga/Kconfig   | 5 +
 arch/arm/mach-socfpga/include/mach/reset_manager.h  | 3 +--
 arch/arm/mach-socfpga/include/mach/system_manager.h | 3 +--
 drivers/ddr/altera/Kconfig  | 6 +++---
 drivers/fpga/Kconfig| 2 +-
 drivers/sysreset/Kconfig| 2 +-
 7 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 95557d6ed6..f4299ae692 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -975,7 +975,7 @@ config ARCH_SOCFPGA
bool "Altera SOCFPGA family"
select ARCH_EARLY_INIT_R
select ARCH_MISC_INIT if !TARGET_SOCFPGA_ARRIA10
-   select ARM64 if TARGET_SOCFPGA_STRATIX10 || TARGET_SOCFPGA_AGILEX
+   select ARM64 if TARGET_SOCFPGA_SOC64
select CPU_V7A if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
select DM
select DM_SERIAL
@@ -987,7 +987,7 @@ config ARCH_SOCFPGA
select SPL_LIBGENERIC_SUPPORT
select SPL_NAND_SUPPORT if SPL_NAND_DENALI
select SPL_OF_CONTROL
-   select SPL_SEPARATE_BSS if TARGET_SOCFPGA_STRATIX10 || 
TARGET_SOCFPGA_AGILEX
+   select SPL_SEPARATE_BSS if TARGET_SOCFPGA_SOC64
select SPL_SERIAL_SUPPORT
select SPL_SYSRESET
select SPL_WATCHDOG_SUPPORT
@@ -996,7 +996,7 @@ config ARCH_SOCFPGA
select SYS_THUMB_BUILD if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
select SYSRESET
select SYSRESET_SOCFPGA if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
-   select SYSRESET_SOCFPGA_SOC64 if TARGET_SOCFPGA_STRATIX10 || 
TARGET_SOCFPGA_AGILEX
+   select SYSRESET_SOCFPGA_SOC64 if TARGET_SOCFPGA_SOC64
imply CMD_DM
imply CMD_MTDPARTS
imply CRC32_VERIFY
diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 4d4ff16337..9b1abdaabd 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -38,6 +38,7 @@ config TARGET_SOCFPGA_AGILEX
select FPGA_INTEL_SDM_MAILBOX
select NCORE_CACHE
select SPL_CLK if SPL
+   select TARGET_SOCFPGA_SOC64
 
 config TARGET_SOCFPGA_ARRIA5
bool
@@ -75,12 +76,16 @@ config TARGET_SOCFPGA_GEN5
imply SPL_SYS_MALLOC_SIMPLE
imply SPL_USE_TINY_PRINTF
 
+config TARGET_SOCFPGA_SOC64
+   bool
+
 config TARGET_SOCFPGA_STRATIX10
bool
select ARMV8_MULTIENTRY
select ARMV8_SET_SMPEN
select BINMAN if SPL_ATF
select FPGA_INTEL_SDM_MAILBOX
+   select TARGET_SOCFPGA_SOC64
 
 choice
prompt "Altera SOCFPGA board select"
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h 
b/arch/arm/mach-socfpga/include/mach/reset_manager.h
index 7844ad14cb..8c25325e45 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
@@ -43,8 +43,7 @@ void socfpga_per_reset_all(void);
 #include 
 #elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
 #include 
-#elif defined(CONFIG_TARGET_SOCFPGA_STRATIX10) || \
-   defined(CONFIG_TARGET_SOCFPGA_AGILEX)
+#elif defined(CONFIG_TARGET_SOCFPGA_SOC64)
 #include 
 #endif
 
diff --git a/arch/arm/mach-socfpga/include/mach/system_manager.h 
b/arch/arm/mach-socfpga/include/mach/system_manager.h
index f816954717..5603eaa3d0 100644
--- a/arch/arm/mach-socfpga/include/mach/system_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/system_manager.h
@@ -8,8 +8,7 @@
 
 phys_addr_t socfpga_get_sysmgr_addr(void);
 
-#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10) || \
-   defined(CONFIG_TARGET_SOCFPGA_AGILEX)
+#if defined(CONFIG_TARGET_SOCFPGA_SOC64)
 #include 
 #else
 #define SYSMGR_ROMCODEGRP_CTRL_WARMRSTCFGPINMUXBIT(0)
diff --git a/drivers/ddr/altera/Kconfig b/drivers/ddr/altera/Kconfig
index 8f590dc5f6..4660d20def 100644
--- a/drivers/ddr/altera/Kconfig
+++ b/drivers/ddr/altera/Kconfig
@@ -1,8 +1,8 @@
 config SPL_ALTERA_SDRAM
bool "SoCFPGA DDR SDRAM driver in SPL"
depends on SPL
-   depends on TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10 || 
TARGET_SOCFPGA_STRATIX10 || TARGET_SOCFPGA_AGILEX
-   select RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_STRATIX10 || 
TARGET_SOCFPGA_AGILEX
-   select SPL_RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_STRATIX10 || 
TARGET_SOCFPGA_AGILEX
+   depends on TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10 || 
TARGET_SOCFPGA_SOC64
+   select RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_SOC64
+   select SPL_RAM if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_SOC64
help
  Enable DDR SDRAM controller for the SoCFPGA devices.
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 425b52a926..dc0b3dd31b 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -33,7 +33,7 @@ config 

[v4 0/7] Add Vendor Authorized Boot (VAB) support

2021-02-26 Thread Siew Chin Lim
This is the 4th version of patchset to add Vendor Authorized Boot (VAB)
support for Intel Agilex SoC device.

Vendor Authorized Boot is a security feature for authenticating
the images such as U-Boot, ARM trusted Firmware, Linux kernel,
device tree blob and etc loaded from FIT. After those images are
loaded from FIT, the VAB certificate and signature block appended
at the end of each image are sent to Secure Device Manager (SDM)
for authentication. U-Boot will validate the SHA384 of the image
against the SHA384 hash stored in the VAB certificate before
sending the image to SDM for authentication.

Patch status:
Have changes: Patch 2, 7
Other patches unchanged.

Detail changelog can find in commit message.

v3->v4:

Patch 2:
- Move function 'board_fit_image_post_process' and 'board_prep_linux' from
  secure_vab.c to board.c

Patch 7:
- Replace CONFIG_TARGET_SOCFPGA_STRATIX10/AGILEX with 
CONFIG_TARGET_SOCFPGA_SOC64.
- Add this patch into 'VAB' series because it is depending on
  CONFIG_TARGET_SOCFPGA_SOC64 patch.

History:

[v1]: 
https://patchwork.ozlabs.org/project/uboot/cover/20201110070505.26935-1-elly.siew.chin@intel.com/
[v2]: 
https://patchwork.ozlabs.org/project/uboot/cover/20210107100337.45293-1-elly.siew.chin@intel.com/
[v3]: 
https://patchwork.ozlabs.org/project/uboot/cover/20210205105212.16510-1-elly.siew.chin@intel.com/


Dalon Westergreen (1):
  Makefile: socfpga: Add target to generate hex output for combined spl
and dtb

Siew Chin Lim (6):
  arm: socfpga: Move Stratix10 and Agilex to use TARGET_SOCFPGA_SOC64
  arm: socfpga: soc64: Support Vendor Authorized Boot (VAB)
  arm: socfpga: cmd: Support 'vab' command
  arm: socfpga: dts: soc64: Update filename in binman node of FIT image
with VAB support
  configs: socfpga: soc64: Move CONFIG_BOOTCOMMAND to defconfig
  configs: socfpga: Add defconfig for Agilex with VAB support

 Makefile   |  11 +-
 arch/arm/Kconfig   |   6 +-
 arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi |  22 +++
 arch/arm/mach-socfpga/Kconfig  |  20 +++
 arch/arm/mach-socfpga/Makefile |   3 +
 arch/arm/mach-socfpga/board.c  |  43 -
 arch/arm/mach-socfpga/include/mach/mailbox_s10.h   |   1 +
 arch/arm/mach-socfpga/include/mach/reset_manager.h |   3 +-
 arch/arm/mach-socfpga/include/mach/secure_vab.h|  63 +++
 .../arm/mach-socfpga/include/mach/system_manager.h |   3 +-
 arch/arm/mach-socfpga/secure_vab.c | 186 +
 arch/arm/mach-socfpga/vab.c|  34 
 common/Kconfig.boot|   2 +-
 configs/socfpga_agilex_atf_defconfig   |   2 +
 configs/socfpga_agilex_defconfig   |   2 +
 ..._atf_defconfig => socfpga_agilex_vab_defconfig} |   4 +
 configs/socfpga_stratix10_atf_defconfig|   2 +
 configs/socfpga_stratix10_defconfig|   2 +
 drivers/ddr/altera/Kconfig |   6 +-
 drivers/fpga/Kconfig   |   2 +-
 drivers/sysreset/Kconfig   |   2 +-
 include/configs/socfpga_soc64_common.h |  10 +-
 scripts/Makefile.spl   |   7 +
 23 files changed, 406 insertions(+), 30 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/include/mach/secure_vab.h
 create mode 100644 arch/arm/mach-socfpga/secure_vab.c
 create mode 100644 arch/arm/mach-socfpga/vab.c
 copy configs/{socfpga_agilex_atf_defconfig => socfpga_agilex_vab_defconfig} 
(91%)

-- 
2.13.0



Re: [PATCH] nvme: add cache flush in get/set_features

2021-02-26 Thread Neil Armstrong
Hi Andre, Bin,

On 26/02/2021 16:22, André Przywara wrote:
> On 26/02/2021 14:13, Neil Armstrong wrote:
> 
> Hi,
> 
[..]

> 
> And if this seems to fix something, how?

Good question... sorry for the noise my patch is totally wrong, but it fixed 
something somehow.

But, "nvme: Always invalidate whole cqes[] array" fixes (correctly) the issue !

Thanks,

Neil

> 
> Cheers,
> Andre
> 
>>  
>>  return nvme_submit_admin_cmd(dev, , result);
>>  }
>>
> 



Re: [PATCH] nvme: add cache flush in get/set_features

2021-02-26 Thread André Przywara
On 26/02/2021 14:13, Neil Armstrong wrote:

Hi,

> On Amlogic G12A platforms, the NVME probe timeouts at get/set_feature(),
> adding a cache flush solves the timeout.

I am puzzled how this is supposed to work ...

> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/nvme/nvme.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> index 5d6331ad34..44c00a0309 100644
> --- a/drivers/nvme/nvme.c
> +++ b/drivers/nvme/nvme.c
> @@ -487,11 +487,11 @@ int nvme_get_features(struct nvme_dev *dev, unsigned 
> fid, unsigned nsid,
>   c.features.nsid = cpu_to_le32(nsid);
>   c.features.prp1 = cpu_to_le64(dma_addr);
>   c.features.fid = cpu_to_le32(fid);
> -
>   /*
> -  * TODO: add cache invalidate operation when the size of
> +  * TODO: add better cache invalidate operation when the size of
>* the DMA buffer is known
>*/
> + invalidate_dcache_all();

Why is this? Isn't it totally dangerous, because we kill all the
information in dirty cache lines? We have extra checks in place to
prevent invalidating extra cache lines, when invalidating a single
buffer, but this is blanketly killing all of the cache?

And just ignoring for a minute that cache operations by set/way are
mostly wrong anyway? They are just meant to initialise the cache after
power state changes.

But more importantly: I don't see a single user of nvme_get_features()
in the tree? So this would never be called?

>  
>   return nvme_submit_admin_cmd(dev, , result);
>  }
> @@ -508,9 +508,10 @@ int nvme_set_features(struct nvme_dev *dev, unsigned 
> fid, unsigned dword11,
>   c.features.dword11 = cpu_to_le32(dword11);
>  
>   /*
> -  * TODO: add cache flush operation when the size of
> +  * TODO: add better cache flush operation when the size of
>* the DMA buffer is known
>*/
> + invalidate_dcache_all();

Same comment as above, first part: Dangerous and mostly wrong.
Besides: the comment speaks of "flush", not invalidate. So would be
extra wrong.
Also: there is exactly one caller in the whole tree, in this very same
file. And this one is passing a dma_addr of 0, apparently because it
doesn't actually use any buffer, instead passes the single piece of
information (the queue count) in the dword11 field.

So how is this supposed to work?

And if this seems to fix something, how?

Cheers,
Andre

>  
>   return nvme_submit_admin_cmd(dev, , result);
>  }
> 



Re: [PATCH] rk3399: Add basic support for helios64

2021-02-26 Thread Peter Robinson
On Fri, Feb 26, 2021 at 1:45 PM Uwe Kleine-König  wrote:
>
> Hi Dennis,
>
> thanks for your feedback.
>
> On 2/26/21 12:23 AM, Dennis Gilmore wrote:
> > Thanks for submitting, I have been meaning to do so myself, I have
> > been meaning to go through and try get the dts files in a decent
> > shape. I think that most of what is in
> > arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi  belongs in
> > arch/arm/dts/rk3399-kobol-helios64.dts
>
> I understood that the intention of the separation into two files is that
> the one should track the Linux dts. Is that wrong?

No, that's correct, but it should also likely then be submitted for
upstream Linux inclusion.

> > I also wonder if we shouldn't
> > default to building an image for use in the SPI flash since the system
> > has it available.
>
> I didn't test that but expected that I can write the resulting image to
> the spi flash and it works just fine. If you want something else here I
> need some direction about what to change.
>
> Best regards
> Uwe
>


Re: [PATCH 1/2 v4] efi: Add ESRT to the EFI system table

2021-02-26 Thread Heinrich Schuchardt
On 23.02.21 17:50, Jose Marinho wrote:
> The ESRT is initialised during efi_init_objlist after
> efi_initialize_system_table().
>
> The ESRT is recreated from scratch at the following events:
> - successful UpdateCapsule;
> - FMP instance install.
>
> The code ensures that every ESRT entry has a unique fw_class value.
>
> Limitations:
> - The ESRT is not updated when an FMP instance is uninstalled;
> - the fields image_type and flags are currently set to UNKNOWN and 0
> respectively. The mapping between fw_class and the image_type/flags
> fields is platform specific. A mapping function is lacking from the
> current implementation but should be added in the future.
>
> Signed-off-by: Jose Marinho 
>
> CC: Heinrich Schuchardt   
> CC: Sughosh Ganu 
> CC: AKASHI Takahiro 
> CC: Ilias Apalodimas 
> CC: Andre Przywara 
> CC: Alexander Graf 
> CC: n...@arm.com
>
> ---
>  cmd/efidebug.c   |   4 +
>  include/efi_api.h|  21 ++
>  include/efi_loader.h |  20 ++
>  lib/efi_loader/Kconfig   |   7 +
>  lib/efi_loader/Makefile  |   1 +
>  lib/efi_loader/efi_capsule.c |   8 +
>  lib/efi_loader/efi_esrt.c| 518 +++
>  lib/efi_loader/efi_setup.c   |   6 +
>  8 files changed, 585 insertions(+)
>  create mode 100644 lib/efi_loader/efi_esrt.c
>
> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> index bbbcb0a546..a7dace2f80 100644
> --- a/cmd/efidebug.c
> +++ b/cmd/efidebug.c
> @@ -459,6 +459,10 @@ static const struct {
>   "Block IO",
>   EFI_BLOCK_IO_PROTOCOL_GUID,
>   },
> + {
> + "EFI System Resource Table",
> + EFI_SYSTEM_RESOURCE_TABLE_GUID,
> + },
>   {
>   "Simple File System",
>   EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID,
> diff --git a/include/efi_api.h b/include/efi_api.h
> index 48e48a6263..fb53637419 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -1722,6 +1722,23 @@ struct efi_load_file_protocol {
>void *buffer);
>  };
>
> +struct efi_system_resource_entry {
> + efi_guid_t fw_class;
> + u32 fw_type;
> + u32 fw_version;
> + u32 lowest_supported_fw_version;
> + u32 capsule_flags;
> + u32 last_attempt_version;
> + u32 last_attempt_status;
> +} __packed;
> +
> +struct efi_system_resource_table {
> + u32 fw_resource_count;
> + u32 fw_resource_count_max;
> + u64 fw_resource_version;
> + struct efi_system_resource_entry entries[];
> +} __packed;
> +
>  /* Boot manager load options */
>  #define LOAD_OPTION_ACTIVE   0x0001
>  #define LOAD_OPTION_FORCE_RECONNECT  0x0002
> @@ -1740,6 +1757,10 @@ struct efi_load_file_protocol {
>  #define ESRT_FW_TYPE_DEVICEFIRMWARE  0x0002
>  #define ESRT_FW_TYPE_UEFIDRIVER  0x0003
>
> +#define EFI_SYSTEM_RESOURCE_TABLE_GUID\
> + EFI_GUID(0xb122a263, 0x3661, 0x4f68,\
> + 0x99, 0x29, 0x78, 0xf8, 0xb0, 0xd6, 0x21, 0x80)
> +
>  /* Last Attempt Status Values */
>  #define LAST_ATTEMPT_STATUS_SUCCESS  0x
>  #define LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL   0x0001
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index f470bbd636..c2720f2823 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -214,6 +214,8 @@ extern const efi_guid_t efi_guid_rng_protocol;
>  extern const efi_guid_t efi_guid_capsule_report;
>  /* GUID of firmware management protocol */
>  extern const efi_guid_t efi_guid_firmware_management_protocol;
> +/* GUID for the ESRT */
> +extern const efi_guid_t efi_esrt_guid;
>
>  extern unsigned int __efi_runtime_start, __efi_runtime_stop;
>  extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
> @@ -884,4 +886,22 @@ static inline efi_status_t efi_launch_capsules(void)
>
>  #endif /* CONFIG_IS_ENABLED(EFI_LOADER) */
>
> +/**
> + * Install the ESRT system table.
> + *
> + * @return   status code
> + */
> +efi_status_t efi_esrt_register(void);
> +
> +/**
> + * efi_esrt_populate() - Populates the ESRT entries from the FMP instances
> + * present in the system.
> + * If an ESRT already exists, the old ESRT is replaced in the system table.
> + * The memory of the old ESRT is deallocated.
> + *
> + * Return:
> + * - EFI_SUCCESS if the ESRT is correctly created
> + * - error code otherwise.
> + */
> +efi_status_t efi_esrt_populate(void);
>  #endif /* _EFI_LOADER_H */
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index e729f727df..a96014ce18 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -347,4 +347,11 @@ config EFI_SECURE_BOOT
> it is signed with a trusted key. To do that, you need to install,
> at least, PK, KEK and db.
>
> +config EFI_ESRT
> + bool "Enable the UEFI ESRT generation"
> + depends on EFI_CAPSULE_FIRMWARE_MANAGEMENT
> + default y
> + help
> +   Enabling this option creates the ESRT UEFI system table.
> +
>  

Re: [PATCH v2] configs: stm32mp1: enable uefi related commands

2021-02-26 Thread Patrick DELAUNAY



On 2/26/21 2:09 PM, Patrick DELAUNAY wrote:

Hi,

On 2/26/21 1:52 PM, Ilias Apalodimas wrote:

The board can boot with UEFI. With the latest changes in U-Boot's
EFI subsystem we also have support for EFI runtime variables, without
SetVariable support.  We can also store the EFI variables in a file 
on the

ESP partition and preserve them across reboots.
The env and efidebug commands are missing in order to configure
EFI variables and the efibootmgr though.  Since U-Boot's default config
enables other EFI related commands (e.g bootefi), let's add the env 
related

and efidebug commands and allow users to do that

Signed-off-by: Ilias Apalodimas 
---
Changes since v1:
- Apply identical changes on stm32mp15_basic_defconfig
  configs/stm32mp15_basic_defconfig   | 3 +++
  configs/stm32mp15_trusted_defconfig | 3 +++
  2 files changed, 6 insertions(+)




Reviewed-by: Patrick Delaunay 

Thanks
Patrick




Applied to u-boot-stm/master, thanks!

Regards
Patrick



Re: [PATCH] arm: dts: stm32mp15: remove duplicate uart nodes

2021-02-26 Thread Patrick DELAUNAY

Hi,

On 2/24/21 11:00 AM, Patrick Delaunay wrote:

Remove duplicated uart nodes introduced with commit 62f95af92a3f
("ARM: dts: stm32mp1: DT alignment with Linux kernel v5.9-rc4"),
because the uart nodes wasn't correctly ordered in alphabetic order.

Only cosmetic: the generated device tree don't change.

Signed-off-by: Patrick Delaunay 
---

  arch/arm/dts/stm32mp15-pinctrl.dtsi | 80 -
  1 file changed, 80 deletions(-)



Applied to u-boot-stm/master, thanks!

Regards
Patrick



Re: [RFC PATCH] nvme: Always invalidate whole cqes[] array

2021-02-26 Thread Jagan Teki
Hi Suniel,

On Mon, Feb 8, 2021 at 7:02 PM Andre Przywara  wrote:
>
> At the moment nvme_read_completion_status() tries to invidate a single
> member of the cqes[] array, which is shady as just a single entry is
> not cache line aligned.
> The structure is dictated by hardware, and with 16 bytes is smaller than
> any cache line we usually deal with. Also multiple entries need to be
> consecutive in memory, so we can't pad them to cover a whole cache line.
>
> As a consequence we can only always invalidate all of them - U-Boot just
> uses two of them anyway. This is fine, as they are only ever read by the
> CPU (apart from the initial zeroing), so they can't become dirty.
>
> Make this obvious by always invalidating the whole array, regardless of
> the entry number we are about to read.
> Also blow up the allocation size to cover whole cache lines, to avoid
> other heap allocations to sneak in.
>
> Signed-off-by: Andre Przywara 
> ---
> Hi,
>
> this is just compile tested, and should fix the only questionable
> cache invalidate call in this driver.
> Please verify if this fixes any issues!

Can you test this on RK3399?

Jagan.


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

2021-02-26 Thread Patrick DELAUNAY

Hi,

On 2/12/21 1:50 PM, Marek Vasut wrote:

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(+)



Applied to u-boot-stm/master, thanks!

Regards
Patrick



Re: [PATCH] arm: dts: stm32mp15: remove duplicate uart nodes

2021-02-26 Thread Patrice CHOTARD
Hi Patrick

On 2/24/21 11:00 AM, Patrick Delaunay wrote:
> Remove duplicated uart nodes introduced with commit 62f95af92a3f
> ("ARM: dts: stm32mp1: DT alignment with Linux kernel v5.9-rc4"),
> because the uart nodes wasn't correctly ordered in alphabetic order.
> 
> Only cosmetic: the generated device tree don't change.
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  arch/arm/dts/stm32mp15-pinctrl.dtsi | 80 -
>  1 file changed, 80 deletions(-)
> 
> diff --git a/arch/arm/dts/stm32mp15-pinctrl.dtsi 
> b/arch/arm/dts/stm32mp15-pinctrl.dtsi
> index dd4bd1e554..20a59e8f7a 100644
> --- a/arch/arm/dts/stm32mp15-pinctrl.dtsi
> +++ b/arch/arm/dts/stm32mp15-pinctrl.dtsi
> @@ -1971,86 +1971,6 @@
>   };
>   };
>  
> - uart4_pins_a: uart4-0 {
> - pins1 {
> - pinmux = ; /* UART4_TX */
> - bias-disable;
> - drive-push-pull;
> - slew-rate = <0>;
> - };
> - pins2 {
> - pinmux = ; /* UART4_RX */
> - bias-disable;
> - };
> - };
> -
> - uart4_pins_b: uart4-1 {
> - pins1 {
> - pinmux = ; /* UART4_TX */
> - bias-disable;
> - drive-push-pull;
> - slew-rate = <0>;
> - };
> - pins2 {
> - pinmux = ; /* UART4_RX */
> - bias-disable;
> - };
> - };
> -
> - uart4_pins_c: uart4-2 {
> - pins1 {
> - pinmux = ; /* UART4_TX */
> - bias-disable;
> - drive-push-pull;
> - slew-rate = <0>;
> - };
> - pins2 {
> - pinmux = ; /* UART4_RX */
> - bias-disable;
> - };
> - };
> -
> - uart7_pins_a: uart7-0 {
> - pins1 {
> - pinmux = ; /* UART4_TX */
> - bias-disable;
> - drive-push-pull;
> - slew-rate = <0>;
> - };
> - pins2 {
> - pinmux = , /* UART4_RX */
> -  , /* UART4_CTS */
> -  ; /* UART4_RTS */
> - bias-disable;
> - };
> - };
> -
> - uart7_pins_b: uart7-1 {
> - pins1 {
> - pinmux = ; /* UART7_TX */
> - bias-disable;
> - drive-push-pull;
> - slew-rate = <0>;
> - };
> - pins2 {
> - pinmux = ; /* UART7_RX */
> - bias-disable;
> - };
> - };
> -
> - uart8_pins_a: uart8-0 {
> - pins1 {
> - pinmux = ; /* UART8_TX */
> - bias-disable;
> - drive-push-pull;
> - slew-rate = <0>;
> - };
> - pins2 {
> - pinmux = ; /* UART8_RX */
> - bias-disable;
> - };
> - };
> -
>   usbotg_hs_pins_a: usbotg-hs-0 {
>   pins {
>   pinmux = ; /* OTG_ID */
> 

Reviewed-by: Patrice Chotard 

Thanks

Patrice


Re: [PATCH 2/2] sunxi: enable dual rank memory on R40

2021-02-26 Thread Ivan Uvarov
I have tested this patchset on both OKA40i-C and our custom carrier
board which uses the same SoM (Forlinx FETA40i-C), and can confirm that:
1) It does enable functioning of U-Boot on the FETA40i SoM, and
2) I have not experienced any immediately apparent problems with DRAM in
either U-Boot itself or the loaded OS during my testing.


Tested-by: Ivan Uvarov 


On 2/25/21 7:13 PM, Icenowy Zheng wrote:
> Previously we do not have proper dual rank memory detection on R40
> (because we omitted PIR_QSGATE, which does not work on R40 with our
> configuration), and dual rank memory is just simply disabled as early
> R40 boards available (Banana Pi M2 Ultra and Berry) have single rank
> memory.
> 
> As a board with dual rank memory (Forlinx OKA40i-C) is now known to us,
> we need to have a way to do memory rank detection to support that board.
> 
> Add some routine to detect memory rank by trying to access the memory
> in rank 1 and check for error status of the memory controller, and then
> enable dual rank memory on R40.
> 
> Similar routine can be used to detect half DQ width (which is also
> detected by PIR_QSGATE on other SoCs), but it's left unimplemented
> because there's no known R40 board with half DQ width now.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/mach-sunxi/dram_sunxi_dw.c | 55 +
>  1 file changed, 49 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c 
> b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> index 2b9d631d49..b86ae7cdf3 100644
> --- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
> +++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> @@ -414,11 +414,9 @@ static void mctl_set_cr(uint16_t socid, struct dram_para 
> *para)
>   }
>  
>   if (socid == SOCID_R40) {
> - if (para->dual_rank)
> - panic("Dual rank memory not supported\n");
> -
>   /* Mux pin to A15 address line for single rank memory. */
> - setbits_le32(_com->cr_r1, MCTL_CR_R1_MUX_A15);
> + if (!para->dual_rank)
> + setbits_le32(_com->cr_r1, MCTL_CR_R1_MUX_A15);
>   }
>  }
>  
> @@ -702,8 +700,55 @@ static unsigned long mctl_calc_rank_size(struct 
> rank_para *rank)
>   return (1UL << (rank->row_bits + rank->bank_bits)) * rank->page_size;
>  }
>  
> +/*
> + * Because we cannot do mctl_phy_init(PIR_QSGATE) on R40 now (which leads
> + * to failure), it's needed to detect the rank count of R40 in another way.
> + *
> + * The code here is modelled after time_out_detect() in BSP, which tries to
> + * access the memory and check for error code.
> + *
> + * TODO: auto detect half DQ width here
> + */
> +static void mctl_r40_detect_rank_count(struct dram_para *para)
> +{
> + ulong rank1_base = (ulong) CONFIG_SYS_SDRAM_BASE +
> +mctl_calc_rank_size(>ranks[0]);
> + struct sunxi_mctl_ctl_reg * const mctl_ctl =
> + (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
> +
> + /* Enable read time out */
> + setbits_le32(_ctl->pgcr[0], 0x1 << 25);
> +
> + (void) readl((void *) rank1_base);
> + udelay(10);
> +
> + if (readl(_ctl->pgsr[0]) & (0x1 << 13)) {
> + clrsetbits_le32(_ctl->dtcr, 0xf << 24, 0x1 << 24);
> + para->dual_rank = 0;
> + }
> +
> + /* Reset PHY FIFO to clear it */
> + clrbits_le32(_ctl->pgcr[0], 0x1 << 26);
> + udelay(100);
> + setbits_le32(_ctl->pgcr[0], 0x1 << 26);
> +
> + /* Clear error status */
> + setbits_le32(_ctl->pgcr[0], 0x1 << 24);
> +
> + /* Clear time out flag */
> + clrbits_le32(_ctl->pgsr[0], 0x1 << 13);
> +
> + /* Disable read time out */
> + clrbits_le32(_ctl->pgcr[0], 0x1 << 25);
> +}
> +
>  static void mctl_auto_detect_dram_size(uint16_t socid, struct dram_para 
> *para)
>  {
> + if (socid == SOCID_R40) {
> + mctl_r40_detect_rank_count(para);
> + mctl_set_cr(socid, para);
> + }
> +
>   mctl_auto_detect_dram_size_rank(socid, para, 
> (ulong)CONFIG_SYS_SDRAM_BASE, >ranks[0]);
>  
>   if ((socid == SOCID_A64 || socid == SOCID_R40) && para->dual_rank) {
> @@ -854,8 +899,6 @@ unsigned long sunxi_dram_init(void)
>   uint16_t socid = SOCID_H3;
>  #elif defined(CONFIG_MACH_SUN8I_R40)
>   uint16_t socid = SOCID_R40;
> - /* Currently we cannot support R40 with dual rank memory */
> - para.dual_rank = 0;
>  #elif defined(CONFIG_MACH_SUN8I_V3S)
>   uint16_t socid = SOCID_V3S;
>  #elif defined(CONFIG_MACH_SUN50I)
> 


Re: [PATCH 3/5] Azure/GitLab: Ensure we use requirements.txt for testsuites

2021-02-26 Thread Tom Rini
On Fri, Feb 26, 2021 at 10:25:30PM +0800, Bin Meng wrote:
> On Fri, Feb 26, 2021 at 8:53 PM Tom Rini  wrote:
> >
> > Given that test/py/requirements.txt has all required test modules, make
> > use of that rather than a manual pip install list before running our
> > assorted tool testsuites.
> >
> > Signed-off-by: Tom Rini 
> > ---
> >  .azure-pipelines.yml | 2 +-
> >  .gitlab-ci.yml   | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> > index a6279427e138..0a4f90f75f3b 100644
> > --- a/.azure-pipelines.yml
> > +++ b/.azure-pipelines.yml
> > @@ -144,7 +144,7 @@ jobs:
> >export USER=azure
> >virtualenv -p /usr/bin/python3 /tmp/venv
> >. /tmp/venv/bin/activate
> > -  pip install pyelftools pytest pygit2
> > +  pip install -r test/py/requirements.txt
> 
> It seems only pytest is listed in test/py/requirements.txt?

Not since:
commit f4a60b036308ca4a0a3ad08587b7f9b72d3565d5
Author: Igor Opaniuk 
Date:   Mon Jan 25 14:28:41 2021 +0200

test: py: add pygit2 and pyelftools to requirements.txt

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 3/5] Azure/GitLab: Ensure we use requirements.txt for testsuites

2021-02-26 Thread Bin Meng
On Fri, Feb 26, 2021 at 8:53 PM Tom Rini  wrote:
>
> Given that test/py/requirements.txt has all required test modules, make
> use of that rather than a manual pip install list before running our
> assorted tool testsuites.
>
> Signed-off-by: Tom Rini 
> ---
>  .azure-pipelines.yml | 2 +-
>  .gitlab-ci.yml   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> index a6279427e138..0a4f90f75f3b 100644
> --- a/.azure-pipelines.yml
> +++ b/.azure-pipelines.yml
> @@ -144,7 +144,7 @@ jobs:
>export USER=azure
>virtualenv -p /usr/bin/python3 /tmp/venv
>. /tmp/venv/bin/activate
> -  pip install pyelftools pytest pygit2
> +  pip install -r test/py/requirements.txt

It seems only pytest is listed in test/py/requirements.txt?

>export UBOOT_TRAVIS_BUILD_DIR=/tmp/sandbox_spl
>export PYTHONPATH=${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc/pylibfdt
>export PATH=${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc:${PATH}
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index ceba5ce7a905..ce0e63481a11 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -151,7 +151,7 @@ Run binman, buildman, dtoc, Kconfig and patman testsuites:
>export USER=gitlab;
>virtualenv -p /usr/bin/python3 /tmp/venv;
>. /tmp/venv/bin/activate;
> -  pip install pyelftools pytest pygit2;
> +  pip install -r test/py/requirements.txt;
>export UBOOT_TRAVIS_BUILD_DIR=/tmp/sandbox_spl;
>export PYTHONPATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc/pylibfdt";
>export PATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc:${PATH}";
> --

Regards,
Bin


[PATCH V2] spi: Update speed/mode on change

2021-02-26 Thread Marek Vasut
The spi_get_bus_and_cs() may be called on the same bus and chipselect
with different frequency or mode. This is valid usecase, but the code
fails to notify the controller of such a configuration change. Call
spi_set_speed_mode() in case bus frequency or bus mode changed to let
the controller update the configuration.

The problem can easily be triggered using the sspi command:
=> sspi 0:0@1000
=> sspi 0:0@2000
Without this patch, both transfers happen at 1000 Hz. With this patch,
the later transfer happens correctly at 2000 Hz.

Signed-off-by: Marek Vasut 
Cc: Jagan Teki 
Cc: Patrick Delaunay 
---
V2: - Use bus_data->speed for the check
- Release the bus on error
---
 drivers/spi/spi-uclass.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index 7155d4aebd6..5617f6645ee 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -405,12 +405,22 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int 
mode,
goto err;
}
 
+   /* In case bus frequency or mode changed, update it. */
+   if ((speed && bus_data->speed && bus_data->speed != speed) ||
+   (plat->mode != mode)) {
+   ret = spi_set_speed_mode(bus, speed, mode);
+   if (ret)
+   goto err_speed_mode;
+   }
+
*busp = bus;
*devp = slave;
log_debug("%s: bus=%p, slave=%p\n", __func__, bus, *devp);
 
return 0;
 
+err_speed_mode:
+   spi_release_bus(slave);
 err:
log_debug("%s: Error path, created=%d, device '%s'\n", __func__,
  created, dev->name);
-- 
2.30.0



Re: [PATCH] nvme: add cache flush in get/set_features

2021-02-26 Thread Bin Meng
Hi Neil,

On Fri, Feb 26, 2021 at 10:13 PM Neil Armstrong  wrote:
>
> On Amlogic G12A platforms, the NVME probe timeouts at get/set_feature(),
> adding a cache flush solves the timeout.
>
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/nvme/nvme.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>

Does below patch fix your issue?
http://patchwork.ozlabs.org/project/uboot/patch/20210208133154.12645-1-andre.przyw...@arm.com/

REgards,
Bin


Re: [PATCH 2/2 v4] efi: ESRT creation tests

2021-02-26 Thread Heinrich Schuchardt
On 26.02.21 14:55, Heinrich Schuchardt wrote:
> On 23.02.21 17:50, Jose Marinho wrote:
>> This commmit exercises the ESRT creation -- introduced in the previous
>> commit -- in two tests.
>>
>> test 1:
>>  A fake FMP, with TEST_ESRT_NUM_ENTRIES FW images, is installed in the
>>  system leading to the corresponding ESRT entries being populated.
>>  The ESRT entries are checked against the datastructure used to
>>  initialize the FMP.
>>
>> test 1 invocation:
>>  make sandbox_capsule_defconfig all
>>  ./u-boot -d arch/sandbox/dts/test.dtb
>>  ut lib
>>
>> test 2:
>>  The test is part of test_efi_capsule_fw3.
>>
>>  In order to run the test the following must be added to
>>  sandbox_defconfig:
>>   +CONFIG_CMD_SF=y
>>   +CONFIG_CMD_MEMORY=y
>>   +CONFIG_CMD_FAT=y
>>   +CONFIG_DFU=y
>>
>>  The ESRT is printed in the u-boot shell by calling efidebug esrt.
>>  The test ensures that, after the capsule is installed, the  ESRT
>>  contains entries with the GUIDs:
>>   - EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID;
>>   - EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID;
>>
>> test 2 invocation:
>>  sudo ./test/py/test.py --bd sandbox -k capsule_fw3 -l --build
>>
>> Signed-off-by: Jose Marinho 
>>
>> CC: Heinrich Schuchardt  
>> CC: Sughosh Ganu 
>> CC: AKASHI Takahiro 
>> CC: Ilias Apalodimas 
>> CC: Andre Przywara 
>> CC: Alexander Graf 
>> CC: n...@arm.com
>>
>> ---
>>  cmd/efidebug.c|  64 ++
>>  test/lib/Makefile |   1 +
>>  test/lib/efi_esrt.c   | 191 ++
>>  .../test_efi_capsule/test_capsule_firmware.py |   4 +
>>  4 files changed, 260 insertions(+)
>>  create mode 100644 test/lib/efi_esrt.c
>>
>> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
>> index a7dace2f80..5a9ff2bd9a 100644
>> --- a/cmd/efidebug.c
>> +++ b/cmd/efidebug.c
>> @@ -129,6 +129,61 @@ static int do_efi_capsule_show(struct cmd_tbl *cmdtp, 
>> int flag,
>>  return CMD_RET_SUCCESS;
>>  }
>>
>> +#ifdef CONFIG_EFI_ESRT
>> +/**
>> + * do_efi_capsule_esrt() - manage UEFI capsules
>> + *
>> + * @cmdtp:  Command table
>> + * @flag:   Command flag
>> + * @argc:   Number of arguments
>> + * @argv:   Argument array
>> + * Return:  CMD_RET_SUCCESS on success,
>> + *  CMD_RET_USAGE or CMD_RET_RET_FAILURE on failure
>> + *
>> + * Implement efidebug "capsule esrt" sub-command.
>> + * The prints the current ESRT table.
>> + *
>> + * efidebug capsule esrt
>> + */
>> +static int do_efi_capsule_esrt(struct cmd_tbl *cmdtp, int flag,
>> +   int argc, char * const argv[])
>> +{
>> +struct efi_system_resource_table *esrt = NULL;
>> +
>> +if (argc != 1)
>> +return CMD_RET_USAGE;
>> +
>> +for (int idx = 0; idx < systab.nr_tables; idx++)
>> +if (!guidcmp(_esrt_guid, [idx].guid))
>> +esrt = (struct efi_system_resource_table 
>> *)systab.tables[idx].table;
>> +
>> +if (!esrt)
>> +return CMD_RET_FAILURE;
>> +
>> +printf("\n");
>> +printf("ESRT: fw_resource_count=%d\n", esrt->fw_resource_count);
>> +printf("ESRT: fw_resource_count_max=%d\n", esrt->fw_resource_count_max);
>> +printf("ESRT: fw_resource_version=%lld\n", esrt->fw_resource_version);
>> +
>> +for (int idx = 0; idx < esrt->fw_resource_count; idx++) {
>> +printf("[entry %d]==\n", idx);
>> +printf("ESRT: fw_class=%pUL\n", >entries[idx].fw_class);
>> +printf("ESRT: fw_type=%d\n", esrt->entries[idx].fw_type);
>> +printf("ESRT: fw_version=%d\n", esrt->entries[idx].fw_version);
>> +printf("ESRT: lowest_supported_fw_version=%d\n",
>> +   esrt->entries[idx].lowest_supported_fw_version);
>> +printf("ESRT: capsule_flags=%d\n",
>> +   esrt->entries[idx].capsule_flags);
>> +printf("ESRT: last_attempt_version=%d\n",
>> +   esrt->entries[idx].last_attempt_version);
>> +printf("ESRT: last_attempt_status=%d\n",
>> +   esrt->entries[idx].last_attempt_status);
>> +}
>> +printf("\n");
>> +
>> +return CMD_RET_SUCCESS;
>
> With which configuration do we see any entry in the list?
>
> I only got:
>
> => efidebug capsule esrt
> 
> ESRT: fw_resource_count=0
> ESRT: fw_resource_count_max=0
> ESRT: fw_resource_version=1
> 
> =>
>
> with
>
> CONFIG_EFI_HAVE_CAPSULE_SUPPORT=y
> CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
> CONFIG_EFI_CAPSULE_ON_DISK=y
> # CONFIG_EFI_CAPSULE_ON_DISK_EARLY is not set
> CONFIG_EFI_CAPSULE_FIRMWARE=y
> CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT=y
> # CONFIG_EFI_CAPSULE_AUTHENTICATE is not set
> CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
> CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
>
> efidebug dh does not show any FMP protocol installed:
>
> => efidebug dh
> Handle 

Re: [PATCH v3 04/38] ppc: qemu: Support non-identity PCI bus address

2021-02-26 Thread Bin Meng
Hi Priyanka,

On Fri, Feb 26, 2021 at 5:29 PM Priyanka Jain (OSS)
 wrote:
>
>
>
> >-Original Message-
> >From: U-Boot  On Behalf Of Bin Meng
> >Sent: Thursday, February 25, 2021 2:52 PM
> >To: Simon Glass ; Alexander Graf ;
> >Priyanka Jain 
> >Cc: U-Boot Mailing List ; Tom Rini 
> >Subject: [PATCH v3 04/38] ppc: qemu: Support non-identity PCI bus address
> >
> >When QEMU originally supported the ppce500 machine back in Jan 2014, it was
> >created with a 1:1 mapping of PCI bus address. Things seemed to change 
> >rapidly
> >that in Nov 2014 with the following QEMU commits:
> >
> >commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of
> >address space")
> >
> >and
> >
> >commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs")
> >
> >the PCI memory and IO physical address were moved to beyond 4 GiB, but PCI 
> >bus
> >address remained below 4 GiB, hence a non-identity mapping was created.
> >Unfortunately corresponding U-Boot updates were missed along with the QEMU
> >changes and the U-Boot QEMU ppce500 PCI support has been broken since then.
> >
> >This commit makes the PCI (non-DM version) work again.
> >
> >Signed-off-by: Bin Meng 
> >---
> >
> >(no changes since v1)
> >
> > board/freescale/qemu-ppce500/qemu-ppce500.c | 29 ++---
> >
> > 1 file changed, 14 insertions(+), 15 deletions(-)
> >
> >diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c
> >b/board/freescale/qemu-ppce500/qemu-ppce500.c
> >index aa5774f..1d68d30 100644
> >--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
> >+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
> >@@ -85,20 +85,24 @@ int checkboard(void)  }
> >
> > static int pci_map_region(void *fdt, int pci_node, int range_id,
> >-phys_size_t *ppaddr, pci_addr_t *pvaddr,
> >-pci_size_t *psize, ulong *pmap_addr)
> >+phys_addr_t *pbaddr, phys_size_t *ppaddr,
> >+pci_addr_t *pvaddr, pci_size_t *psize,
> >+ulong *pmap_addr)
> > {
> >-  uint64_t addr;
> >+  uint64_t baddr;
> >+  uint64_t paddr;
> >   uint64_t size;
> >   ulong map_addr;
> >   int r;
> >
> >-  r = fdt_read_range(fdt, pci_node, range_id, NULL, , );
> >+  r = fdt_read_range(fdt, pci_node, range_id, , , );
> >   if (r)
> >   return r;
> >
> >+  if (pbaddr)
> >+  *pbaddr = baddr;
> >   if (ppaddr)
> >-  *ppaddr = addr;
> >+  *ppaddr = paddr;
> >   if (psize)
> >   *psize = size;
> >
> >@@ -115,7 +119,7 @@ static int pci_map_region(void *fdt, int pci_node, int
> >range_id,
> >   return -1;
> >
> >   /* Map virtual memory for range */
> >-  assert(!tlb_map_range(map_addr, addr, size, TLB_MAP_IO));
> >+  assert(!tlb_map_range(map_addr, paddr, size, TLB_MAP_IO));
> >   *pmap_addr = map_addr + size;
> >
> >   if (pvaddr)
> >@@ -166,24 +170,19 @@ void pci_init_board(void)
> >   pci_info.regs = fdt_translate_address(fdt, pci_node, reg);
> >
> >   /* Map MMIO range */
> >-  r = pci_map_region(fdt, pci_node, 0, _info.mem_phys, NULL,
> >+  r = pci_map_region(fdt, pci_node, 0, _info.mem_bus,
> >+ _info.mem_phys, NULL,
> >  _info.mem_size, _addr);
> >   if (r)
> >   break;
> >
> >   /* Map PIO range */
> >-  r = pci_map_region(fdt, pci_node, 1, _info.io_phys, NULL,
> >+  r = pci_map_region(fdt, pci_node, 1, _info.io_bus,
> >+ _info.io_phys, NULL,
> >  _info.io_size, _addr);
> >   if (r)
> >   break;
> >
> >-  /*
> >-   * The PCI framework finds virtual addresses for the buses
> >-   * through our address map, so tell it the physical addresses.
> >-   */
> >-  pci_info.mem_bus = pci_info.mem_phys;
> >-  pci_info.io_bus = pci_info.io_phys;
> >-
> >   /* Instantiate */
> >   pci_info.pci_num = pci_num + 1;
> >
> >--
> >2.7.4
>
> Kindly fix below checkpatch warnings, checks:
> WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per 
> line)
> #10:
> commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of 
> address space")
>
> WARNING: Unknown commit id 'e6b4e5f4795b', maybe rebased or not pulled?
> #10:
> commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of 
> address space")
>
> WARNING: Unknown commit id 'cb3778a0455a', maybe rebased or not pulled?
> #14:
> commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs")
>
> CHECK: Prefer kernel type 'u64' over 'uint64_t'
> #45: FILE: board/freescale/qemu-ppce500/qemu-ppce500.c:92:
> +   uint64_t baddr;
>
> CHECK: Prefer kernel type 'u64' 

[PATCH] nvme: add cache flush in get/set_features

2021-02-26 Thread Neil Armstrong
On Amlogic G12A platforms, the NVME probe timeouts at get/set_feature(),
adding a cache flush solves the timeout.

Signed-off-by: Neil Armstrong 
---
 drivers/nvme/nvme.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index 5d6331ad34..44c00a0309 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -487,11 +487,11 @@ int nvme_get_features(struct nvme_dev *dev, unsigned fid, 
unsigned nsid,
c.features.nsid = cpu_to_le32(nsid);
c.features.prp1 = cpu_to_le64(dma_addr);
c.features.fid = cpu_to_le32(fid);
-
/*
-* TODO: add cache invalidate operation when the size of
+* TODO: add better cache invalidate operation when the size of
 * the DMA buffer is known
 */
+   invalidate_dcache_all();
 
return nvme_submit_admin_cmd(dev, , result);
 }
@@ -508,9 +508,10 @@ int nvme_set_features(struct nvme_dev *dev, unsigned fid, 
unsigned dword11,
c.features.dword11 = cpu_to_le32(dword11);
 
/*
-* TODO: add cache flush operation when the size of
+* TODO: add better cache flush operation when the size of
 * the DMA buffer is known
 */
+   invalidate_dcache_all();
 
return nvme_submit_admin_cmd(dev, , result);
 }
-- 
2.25.1



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

2021-02-26 Thread Neil Armstrong
On 17/02/2021 10:17, Patrice Chotard wrote:
> Since commit 8745b9ebccae ("usb: gadget: add super speed support")
> ums was no more functional on platform which use dwc2_udc_otg driver.
> 
> This was due to a too restrictive test which checked that the gadget
> driver speed was either FS or HS.
> 
> So all gadget driver with max speed set to speed higher than
> HS (SS in case of composite gadget driver in our case) are not
> allowed, which is wrong.
> 
> Update the speed test in usb_gadget_register_driver() and in
> dwc2_gadget_start() to allow all gadget driver speed equal or higher
> than FS.
> 
> Tested on stm32mp157c-ev1 board.
> 
> Fixes: c791c8431c34 ("usb: dwc2: convert driver to DM_USB_GADGET")
> 
> Signed-off-by: Patrice Chotard 
> 
> ---
> 
> Changes in v2:
>  - update gadget driver speed test in usb_gadget_register_driver()
>and in dwc2_gadget_start() instead of removing it completely.
> 
>  drivers/usb/gadget/dwc2_udc_otg.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/gadget/dwc2_udc_otg.c 
> b/drivers/usb/gadget/dwc2_udc_otg.c
> index ecac80fc11..2f31814442 100644
> --- a/drivers/usb/gadget/dwc2_udc_otg.c
> +++ b/drivers/usb/gadget/dwc2_udc_otg.c
> @@ -248,9 +248,7 @@ int usb_gadget_register_driver(struct usb_gadget_driver 
> *driver)
>  
>   debug_cond(DEBUG_SETUP != 0, "%s: %s\n", __func__, "no name");
>  
> - if (!driver
> - || (driver->speed != USB_SPEED_FULL
> - && driver->speed != USB_SPEED_HIGH)
> + if (!driver || driver->speed < USB_SPEED_FULL
>   || !driver->bind || !driver->disconnect || !driver->setup)
>   return -EINVAL;
>   if (!dev)
> @@ -320,9 +318,7 @@ static int dwc2_gadget_start(struct usb_gadget *g,
>  
>   debug_cond(DEBUG_SETUP != 0, "%s: %s\n", __func__, "no name");
>  
> - if (!driver ||
> - (driver->speed != USB_SPEED_FULL &&
> -  driver->speed != USB_SPEED_HIGH) ||
> + if (!driver || driver->speed < USB_SPEED_FULL ||
>   !driver->bind || !driver->disconnect || !driver->setup)
>   return -EINVAL;
>  
> 

Thx for the fix !

Tested-by: Neil Armstrong 


Re: [PATCH] serial: ns16550: Correct the base address type

2021-02-26 Thread Simon Glass
Hi Bin,

On Fri, 26 Feb 2021 at 02:32, Bin Meng  wrote:
>
> Hi Simon,
>
> On Sun, Feb 7, 2021 at 8:16 AM Simon Glass  wrote:
> >
> > On Wed, 3 Feb 2021 at 06:22, Bin Meng  wrote:
> > >
> > > Currently ns16550_serial_assign_base() treats the argument 'base'
> > > with type `ulong`. This is incorrect because the base address was
> > > obtained from device tree with type `fdt_addr_t` that can represent
> > > a physical address larger than 32-bit in a 32-bit system.
> > >
> > > Fixes: 9e6ce62190b7 ("serial: ns16550: Fix ordering of getting base 
> > > address")
> > > Signed-off-by: Bin Meng 
> > > ---
> > >
> > >  drivers/serial/ns16550.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Reviewed-by: Simon Glass 
> >
> > Applied to u-boot-dm, thanks!
>
> It looks like this is still not in u-boot/master yet?

Yes we hit a snag as Tom wants the  of-platdata stuff in -next
instead. I'll make a note to mess around with dm/master a bit and send
a pull request with just a few fixes, including this one.

Regards,
Simon


Re: [PATCH 2/2 v4] efi: ESRT creation tests

2021-02-26 Thread Heinrich Schuchardt
On 23.02.21 17:50, Jose Marinho wrote:
> This commmit exercises the ESRT creation -- introduced in the previous
> commit -- in two tests.
>
> test 1:
>  A fake FMP, with TEST_ESRT_NUM_ENTRIES FW images, is installed in the
>  system leading to the corresponding ESRT entries being populated.
>  The ESRT entries are checked against the datastructure used to
>  initialize the FMP.
>
> test 1 invocation:
>  make sandbox_capsule_defconfig all
>  ./u-boot -d arch/sandbox/dts/test.dtb
>  ut lib
>
> test 2:
>  The test is part of test_efi_capsule_fw3.
>
>  In order to run the test the following must be added to
>  sandbox_defconfig:
>   +CONFIG_CMD_SF=y
>   +CONFIG_CMD_MEMORY=y
>   +CONFIG_CMD_FAT=y
>   +CONFIG_DFU=y
>
>  The ESRT is printed in the u-boot shell by calling efidebug esrt.
>  The test ensures that, after the capsule is installed, the  ESRT
>  contains entries with the GUIDs:
>   - EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID;
>   - EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID;
>
> test 2 invocation:
>  sudo ./test/py/test.py --bd sandbox -k capsule_fw3 -l --build
>
> Signed-off-by: Jose Marinho 
>
> CC: Heinrich Schuchardt   
> CC: Sughosh Ganu 
> CC: AKASHI Takahiro 
> CC: Ilias Apalodimas 
> CC: Andre Przywara 
> CC: Alexander Graf 
> CC: n...@arm.com
>
> ---
>  cmd/efidebug.c|  64 ++
>  test/lib/Makefile |   1 +
>  test/lib/efi_esrt.c   | 191 ++
>  .../test_efi_capsule/test_capsule_firmware.py |   4 +
>  4 files changed, 260 insertions(+)
>  create mode 100644 test/lib/efi_esrt.c
>
> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> index a7dace2f80..5a9ff2bd9a 100644
> --- a/cmd/efidebug.c
> +++ b/cmd/efidebug.c
> @@ -129,6 +129,61 @@ static int do_efi_capsule_show(struct cmd_tbl *cmdtp, 
> int flag,
>   return CMD_RET_SUCCESS;
>  }
>
> +#ifdef CONFIG_EFI_ESRT
> +/**
> + * do_efi_capsule_esrt() - manage UEFI capsules
> + *
> + * @cmdtp:   Command table
> + * @flag:Command flag
> + * @argc:Number of arguments
> + * @argv:Argument array
> + * Return:   CMD_RET_SUCCESS on success,
> + *   CMD_RET_USAGE or CMD_RET_RET_FAILURE on failure
> + *
> + * Implement efidebug "capsule esrt" sub-command.
> + * The prints the current ESRT table.
> + *
> + * efidebug capsule esrt
> + */
> +static int do_efi_capsule_esrt(struct cmd_tbl *cmdtp, int flag,
> +int argc, char * const argv[])
> +{
> + struct efi_system_resource_table *esrt = NULL;
> +
> + if (argc != 1)
> + return CMD_RET_USAGE;
> +
> + for (int idx = 0; idx < systab.nr_tables; idx++)
> + if (!guidcmp(_esrt_guid, [idx].guid))
> + esrt = (struct efi_system_resource_table 
> *)systab.tables[idx].table;
> +
> + if (!esrt)
> + return CMD_RET_FAILURE;
> +
> + printf("\n");
> + printf("ESRT: fw_resource_count=%d\n", esrt->fw_resource_count);
> + printf("ESRT: fw_resource_count_max=%d\n", esrt->fw_resource_count_max);
> + printf("ESRT: fw_resource_version=%lld\n", esrt->fw_resource_version);
> +
> + for (int idx = 0; idx < esrt->fw_resource_count; idx++) {
> + printf("[entry %d]==\n", idx);
> + printf("ESRT: fw_class=%pUL\n", >entries[idx].fw_class);
> + printf("ESRT: fw_type=%d\n", esrt->entries[idx].fw_type);
> + printf("ESRT: fw_version=%d\n", esrt->entries[idx].fw_version);
> + printf("ESRT: lowest_supported_fw_version=%d\n",
> +esrt->entries[idx].lowest_supported_fw_version);
> + printf("ESRT: capsule_flags=%d\n",
> +esrt->entries[idx].capsule_flags);
> + printf("ESRT: last_attempt_version=%d\n",
> +esrt->entries[idx].last_attempt_version);
> + printf("ESRT: last_attempt_status=%d\n",
> +esrt->entries[idx].last_attempt_status);
> + }
> + printf("\n");
> +
> + return CMD_RET_SUCCESS;

With which configuration do we see any entry in the list?

I only got:

=> efidebug capsule esrt

ESRT: fw_resource_count=0
ESRT: fw_resource_count_max=0
ESRT: fw_resource_version=1

=>

with

CONFIG_EFI_HAVE_CAPSULE_SUPPORT=y
CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
CONFIG_EFI_CAPSULE_ON_DISK=y
# CONFIG_EFI_CAPSULE_ON_DISK_EARLY is not set
CONFIG_EFI_CAPSULE_FIRMWARE=y
CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT=y
# CONFIG_EFI_CAPSULE_AUTHENTICATE is not set
CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y

efidebug dh does not show any FMP protocol installed:

=> efidebug dh
Handle   Protocols
 
7eef19c0 Device Path, Device Path To Text, Device Path
Utilities, Device-Tree Fixup, Unicode Collation 2, HII 

Re: [PATCH] spi: Update speed/mode on change

2021-02-26 Thread Marek Vasut

On 2/26/21 2:07 PM, Patrick DELAUNAY wrote:

Hi Marek,

On 2/25/21 9:52 PM, Marek Vasut wrote:

The spi_get_bus_and_cs() may be called on the same bus and chipselect
with different frequency or mode. This is valid usecase, but the code
fails to notify the controller of such a configuration change. Call
spi_set_speed_mode() in case bus frequency or bus mode changed to let
the controller update the configuration.

The problem can easily be triggered using the sspi command:
=> sspi 0:0@1000
=> sspi 0:0@2000
Without this patch, both transfers happen at 1000 Hz. With this patch,
the later transfer happens correctly at 2000 Hz.

Signed-off-by: Marek Vasut 
Cc: Jagan Teki 
Cc: Patrick Delaunay 
---
  drivers/spi/spi-uclass.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index 7155d4aebd6..96c9a83e761 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -405,12 +405,22 @@ int spi_get_bus_and_cs(int busnum, int cs, int 
speed, int mode,

  goto err;
  }
+    /* In case bus frequency or mode changed, update it. */
+    if ((speed && slave->speed && slave->speed != speed) ||
+    (plat->mode != mode)) {
+    ret = spi_set_speed_mode(bus, speed, mode);
+    if (ret)
+    goto err_speed_mode;
+    }
+


We compare bus (with lastest configured value ) or slave (value 
requested) here ?


Argh, this should in fact be bus_data->speed , it seems I sent 
un-rebased patches.



in dm_spi_claim_bus() it is compared with bus :

spi->speed and spi->mode and spi = dev_get_uclass_priv(bus);

+    /* In case bus frequency or mode changed, update it. */
+    if ((speed && bus->speed != speed) || (bus->mode != mode)) {
+    ret = spi_set_speed_mode(bus, speed, mode);
+    if (ret)
+    goto err_speed_mode;
+    bus->speed = speed;
+    bus->mode = mode;
+    }

NB: bus->speed can't be 0 here after previous spi_claim_bus()

PS: the update of spi->speed and spi->mode can be done in 
spi_set_speed_mode() function


I don't think you want to do this every time you call dm_spi_claim_bus()


  *busp = bus;
  *devp = slave;
  log_debug("%s: bus=%p, slave=%p\n", __func__, bus, *devp);
  return 0;
+err_speed_mode:
+    spi_claim_bus(slave);



here I think it is:

spi_release_bus(slave);

called after previous spi_claim_bus().


Right


[PATCH] Fix data abort in startup for at91 machines based on ARM926EJS

2021-02-26 Thread Martin Townsend
The startup code in arm/cpu/arm926ejs preserves the link register across
the call to lowlevel_init by using r4:

mov r4, lr  /* perserve link reg across call */
bl  lowlevel_init   /* go setup pll,mux,memory */
mov lr, r4  /* restore link */

The lowlevel_init function for at91 machines based on the same CPU uses r4
and hence corrupts it causing a data abort when it returns to the startup
code. This patch fixes this by using r6 instead of r4 in the lowlevel_init
function.

Discovered and the fix was tested on a AT91SAM9261 based board.

Signed-off-by: Martin Townsend 
---
 arch/arm/mach-at91/arm926ejs/lowlevel_init.S | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-at91/arm926ejs/lowlevel_init.S 
b/arch/arm/mach-at91/arm926ejs/lowlevel_init.S
index 71d7582ce0..994f42eb4a 100644
--- a/arch/arm/mach-at91/arm926ejs/lowlevel_init.S
+++ b/arch/arm/mach-at91/arm926ejs/lowlevel_init.S
@@ -71,10 +71,10 @@ POS1:
str r0, [r1]
 
/* Reading the PMC Status to detect when the Main Oscillator is enabled 
*/
-   mov r4, #AT91_PMC_IXR_MOSCS
+   mov r6, #AT91_PMC_IXR_MOSCS
 MOSCS_Loop:
ldr r3, [r2]
-   and r3, r4, r3
+   and r3, r6, r3
cmp r3, #AT91_PMC_IXR_MOSCS
bne MOSCS_Loop
 
@@ -89,10 +89,10 @@ MOSCS_Loop:
str r0, [r1]
 
/* Reading the PMC Status register to detect when the PLLA is locked */
-   mov r4, #AT91_PMC_IXR_LOCKA
+   mov r6, #AT91_PMC_IXR_LOCKA
 MOSCS_Loop1:
ldr r3, [r2]
-   and r3, r4, r3
+   and r3, r6, r3
cmp r3, #AT91_PMC_IXR_LOCKA
bne MOSCS_Loop1
 
@@ -109,10 +109,10 @@ MOSCS_Loop1:
str r0, [r1]
 
/* Reading the PMC Status to detect when the Master clock is ready */
-   mov r4, #AT91_PMC_IXR_MCKRDY
+   mov r6, #AT91_PMC_IXR_MCKRDY
 MCKRDY_Loop:
ldr r3, [r2]
-   and r3, r4, r3
+   and r3, r6, r3
cmp r3, #AT91_PMC_IXR_MCKRDY
bne MCKRDY_Loop
 
@@ -120,10 +120,10 @@ MCKRDY_Loop:
str r0, [r1]
 
/* Reading the PMC Status to detect when the Master clock is ready */
-   mov r4, #AT91_PMC_IXR_MCKRDY
+   mov r6, #AT91_PMC_IXR_MCKRDY
 MCKRDY_Loop1:
ldr r3, [r2]
-   and r3, r4, r3
+   and r3, r6, r3
cmp r3, #AT91_PMC_IXR_MCKRDY
bne MCKRDY_Loop1
 PLL_setup_end:
-- 
2.25.1


Re: [PATCH] rk3399: Add basic support for helios64

2021-02-26 Thread Uwe Kleine-König

Hi Dennis,

thanks for your feedback.

On 2/26/21 12:23 AM, Dennis Gilmore wrote:

Thanks for submitting, I have been meaning to do so myself, I have
been meaning to go through and try get the dts files in a decent
shape. I think that most of what is in
arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi  belongs in
arch/arm/dts/rk3399-kobol-helios64.dts


I understood that the intention of the separation into two files is that 
the one should track the Linux dts. Is that wrong?



I also wonder if we shouldn't
default to building an image for use in the SPI flash since the system
has it available.


I didn't test that but expected that I can write the resulting image to 
the spi flash and it works just fine. If you want something else here I 
need some direction about what to change.


Best regards
Uwe



OpenPGP_signature
Description: OpenPGP digital signature


[PATCH] pxe_utils: add localcmd defination

2021-02-26 Thread Artem Lapkin
pxe localboot usage too much limited, i think be useful improve it
welcome for any suggestions and feedbacks...

1) add localcmd defination which can used with localboot by default
localboot get from env, now we can define it in pxe script
2) localcmd can use without localboot
3) multiline usage for localcmd
4) add short alias ! for localcmd
5) localcmd eval as uboot script (run_command_list)
6) label + localcmd simple usage uboot pxe menu with uboot commands

Usage examples

# standalone usage
LABEL update_uboot
 LOCALCMD   ip=$tftpip && tftpboot $ip:boot.scr.uimg && script

LABEL reset
# multiline usage
 LOCALCMD   echo RESET
 LOCALCMD   reset

LABEL reset again
# multiline alias usage
 ! echo RESET
 ! reset

LABEL localboot
# redefile localcmd for localboot
 LOCALBOOT 1
 LOCALCMD   echo temporary redefine localcmd

Signed-off-by: Artem Lapkin 
---
 cmd/pxe_utils.c | 29 -
 cmd/pxe_utils.h |  1 +
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
index f1ed671a..fdf532ec 100644
--- a/cmd/pxe_utils.c
+++ b/cmd/pxe_utils.c
@@ -271,6 +271,9 @@ static void label_destroy(struct pxe_label *label)
if (label->kernel)
free(label->kernel);
 
+   if (label->localcmd)
+   free(label->localcmd);
+
if (label->config)
free(label->config);
 
@@ -322,7 +325,10 @@ static int label_localboot(struct pxe_label *label)
 {
char *localcmd;
 
-   localcmd = from_env("localcmd");
+   if (label->localcmd)
+   localcmd = label->localcmd;
+   else
+   localcmd = from_env("localcmd");
 
if (!localcmd)
return -ENOENT;
@@ -470,6 +477,11 @@ static int label_boot(struct cmd_tbl *cmdtp, struct 
pxe_label *label)
return 0;
}
 
+   if (label->localcmd) {
+   if (!label->localboot_val)
+   return run_command_list(label->localcmd, 
strlen(label->localcmd), 0);
+   }
+
if (!label->kernel) {
printf("No kernel given, skipping %s\n",
   label->name);
@@ -687,6 +699,8 @@ enum token_type {
T_APPEND,
T_INITRD,
T_LOCALBOOT,
+   T_LOCALCMD,
+   T_LOCALCMD2,
T_DEFAULT,
T_PROMPT,
T_INCLUDE,
@@ -721,6 +735,8 @@ static const struct token keywords[] = {
{"kernel", T_KERNEL},
{"linux", T_LINUX},
{"localboot", T_LOCALBOOT},
+   {"localcmd", T_LOCALCMD},
+   {"!", T_LOCALCMD2},
{"append", T_APPEND},
{"initrd", T_INITRD},
{"include", T_INCLUDE},
@@ -1102,6 +1118,7 @@ static int parse_label(char **c, struct pxe_menu *cfg)
int len;
char *s = *c;
struct pxe_label *label;
+   char *add;
int err;
 
label = label_create();
@@ -1177,6 +1194,16 @@ static int parse_label(char **c, struct pxe_menu *cfg)
err = parse_integer(c, >localboot_val);
break;
 
+   case T_LOCALCMD:
+   case T_LOCALCMD2:
+   if (label->localcmd) {
+   if (parse_sliteral(c, ))
+   sprintf(label->localcmd, "%s\n%s", 
label->localcmd, add);
+   } else {
+   err = parse_sliteral(c, >localcmd);
+   }
+   break;
+
case T_IPAPPEND:
err = parse_integer(c, >ipappend);
break;
diff --git a/cmd/pxe_utils.h b/cmd/pxe_utils.h
index bbdc606b..cdac1327 100644
--- a/cmd/pxe_utils.h
+++ b/cmd/pxe_utils.h
@@ -49,6 +49,7 @@ struct pxe_label {
int attempted;
int localboot;
int localboot_val;
+   char *localcmd;
struct list_head list;
 };
 
-- 
2.25.1



[PATCH] pxe_utils: improve dftoverlay path

2021-02-26 Thread Artem Lapkin
I think be useful improve dftoverlay path logic, welcome for any suggestions.

Fdtoverlaydir definition usage example

LABEL linux
...
FDTOVERLAYDIR fdt
FDTOVERLAYS ethmac_disable.dtbo pcie_disable.dtbo vpu_disable.dtbo
# same as 
# FDTOVERLAYS fdt/ethmac_disable.dtbo fdt/pcie_disable.dtbo fdt/vpu_disable.dtbo

Usage without overlayfile extension (.dtbo)

LABEL linux
...
FDTOVERLAYS fdt/ethmac_disable fdt/pcie_disable fdt/vpu_disable
# same as 
# FDTOVERLAYS fdt/ethmac_disable.dtbo fdt/pcie_disable.dtbo fdt/vpu_disable.dtbo

Complex usage

LABEL linux
...
FDTOVERLAYDIR fdt
FDTOVERLAYS ethmac_disable pcie_disable vpu_disable
# same as 
# FDTOVERLAYS fdt/ethmac_disable.dtbo fdt/pcie_disable.dtbo fdt/vpu_disable.dtbo

Signed-off-by: Artem Lapkin 
---
 cmd/pxe_utils.c | 22 --
 cmd/pxe_utils.h |  1 +
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
index 333f2073..a657fde6 100644
--- a/cmd/pxe_utils.c
+++ b/cmd/pxe_utils.c
@@ -289,6 +289,9 @@ static void label_destroy(struct pxe_label *label)
if (label->fdtoverlays)
free(label->fdtoverlays);
 
+   if (label->fdtoverlaydir)
+   free(label->fdtoverlaydir);
+
free(label);
 }
 
@@ -352,6 +355,8 @@ static void label_boot_fdtoverlay(struct cmd_tbl *cmdtp, 
struct pxe_label *label
ulong fdtoverlay_addr;
ulong fdt_addr;
int err;
+   char overlayext[] = ".dtbo";
+   char path[MAX_TFTP_PATH_LEN + 1];
 
/* Get the main fdt and map it */
fdt_addr = simple_strtoul(env_get("fdt_addr_r"), NULL, 16);
@@ -393,9 +398,15 @@ static void label_boot_fdtoverlay(struct cmd_tbl *cmdtp, 
struct pxe_label *label
if (!strlen(overlayfile))
goto skip_overlay;
 
+   /* make overlay path */
+   sprintf(path, "%s%s%s%s",
+   label->fdtoverlaydir ? label->fdtoverlaydir : "",
+   label->fdtoverlaydir ? "/" : "",
+   overlayfile,
+   strstr(fdtoverlay, overlayext) ? "" : overlayext);
+
/* Load overlay file */
-   err = get_relfile_envaddr(cmdtp, overlayfile,
- "fdtoverlay_addr_r");
+   err = get_relfile_envaddr(cmdtp, path, "fdtoverlay_addr_r");
if (err < 0) {
printf("Failed loading overlay %s\n", overlayfile);
goto skip_overlay;
@@ -693,6 +704,7 @@ enum token_type {
T_FDT,
T_FDTDIR,
T_FDTOVERLAYS,
+   T_FDTOVERLAYDIR,
T_ONTIMEOUT,
T_IPAPPEND,
T_BACKGROUND,
@@ -730,6 +742,7 @@ static const struct token keywords[] = {
{"devicetreedir", T_FDTDIR},
{"fdtdir", T_FDTDIR},
{"fdtoverlays", T_FDTOVERLAYS},
+   {"fdtoverlaydir", T_FDTOVERLAYDIR},
{"ontimeout", T_ONTIMEOUT,},
{"ipappend", T_IPAPPEND,},
{"background", T_BACKGROUND,},
@@ -1168,6 +1181,11 @@ static int parse_label(char **c, struct pxe_menu *cfg)
err = parse_sliteral(c, >fdtoverlays);
break;
 
+   case T_FDTOVERLAYDIR:
+   if (!label->fdtoverlaydir)
+   err = parse_sliteral(c, >fdtoverlaydir);
+   break;
+
case T_LOCALBOOT:
label->localboot = 1;
err = parse_integer(c, >localboot_val);
diff --git a/cmd/pxe_utils.h b/cmd/pxe_utils.h
index d5475e84..cdac1327 100644
--- a/cmd/pxe_utils.h
+++ b/cmd/pxe_utils.h
@@ -44,6 +44,7 @@ struct pxe_label {
char *fdt;
char *fdtdir;
char *fdtoverlays;
+   char *fdtoverlaydir;
int ipappend;
int attempted;
int localboot;
-- 
2.25.1



Re: [PATCH] usb: dfu: Migrate CONFIG_SYS_DFU_DATA_BUF_SIZE and CONFIG_SYS_DFU_MAX_FILE_SIZE to Kconfig

2021-02-26 Thread Aswath Govindraju
On 23/02/21 11:44 am, Aswath Govindraju wrote:
> Currently the config options CONFIG_SYS_DFU_DATA_BUF_SIZE and
> CONFIG_SYS_DFU_MAX_FILE_SIZE are being set in include/configs/.h
> files and also in _defconfig files without a Kconfig option. It
> is easier for users to set these configs in defconfig files than in config
> header files as they are a part of the source code.
> 
> Add Kconfig symbols, and update the defconfigs by using tools/moveconfig.py
> script.
> 
> Suggested-by: Pratyush Yadav 
> Signed-off-by: Aswath Govindraju 
> ---

Posted v2 for this patch.

Thanks,
Aswath

>  configs/am65x_evm_a53_defconfig   |  2 ++
>  configs/am65x_evm_r5_usbdfu_defconfig |  2 ++
>  configs/am65x_hs_evm_a53_defconfig|  2 ++
>  configs/beaver_defconfig  |  2 ++
>  configs/cei-tk1-som_defconfig |  2 ++
>  configs/colibri-imx6ull_defconfig |  2 ++
>  configs/colibri_vf_defconfig  |  2 ++
>  configs/corvus_defconfig  |  2 ++
>  configs/dalmore_defconfig |  2 ++
>  configs/dh_imx6_defconfig |  2 ++
>  configs/draco_defconfig   |  2 ++
>  configs/e2220-1170_defconfig  |  2 ++
>  configs/etamin_defconfig  |  2 ++
>  configs/jetson-tk1_defconfig  |  2 ++
>  configs/nyan-big_defconfig|  2 ++
>  configs/odroid-xu3_defconfig  |  2 ++
>  configs/odroid_defconfig  |  2 ++
>  configs/origen_defconfig  |  2 ++
>  configs/p2371-_defconfig  |  2 ++
>  configs/p2371-2180_defconfig  |  2 ++
>  configs/p2571_defconfig   |  2 ++
>  configs/p3450-_defconfig  |  2 ++
>  configs/pico-dwarf-imx6ul_defconfig   |  2 ++
>  configs/pico-hobbit-imx6ul_defconfig  |  2 ++
>  configs/pico-imx6_defconfig   |  2 ++
>  configs/pico-imx6ul_defconfig |  2 ++
>  configs/pico-pi-imx6ul_defconfig  |  2 ++
>  configs/pxm2_defconfig|  2 ++
>  configs/rastaban_defconfig|  2 ++
>  configs/rpi_4_32b_defconfig   |  2 ++
>  configs/rpi_4_defconfig   |  2 ++
>  configs/rut_defconfig |  2 ++
>  configs/s5p_goni_defconfig|  2 ++
>  configs/s5pc210_universal_defconfig   |  2 ++
>  configs/smartweb_defconfig|  2 ++
>  configs/socfpga_arria5_defconfig  |  2 ++
>  configs/socfpga_cyclone5_defconfig|  2 ++
>  configs/socfpga_dbm_soc1_defconfig|  2 ++
>  configs/socfpga_de0_nano_soc_defconfig|  2 ++
>  configs/socfpga_de10_nano_defconfig   |  2 ++
>  configs/socfpga_mcvevk_defconfig  |  2 ++
>  configs/socfpga_sockit_defconfig  |  2 ++
>  configs/socfpga_socrates_defconfig|  2 ++
>  configs/socfpga_vining_fpga_defconfig |  2 ++
>  configs/taurus_defconfig  |  2 ++
>  configs/thuban_defconfig  |  2 ++
>  configs/topic_miami_defconfig |  2 ++
>  configs/topic_miamilite_defconfig |  2 ++
>  configs/topic_miamiplus_defconfig |  2 ++
>  configs/trats2_defconfig  |  2 ++
>  configs/trats_defconfig   |  2 ++
>  configs/venice2_defconfig |  2 ++
>  configs/warp7_bl33_defconfig  |  2 ++
>  configs/warp7_defconfig   |  2 ++
>  configs/warp_defconfig|  2 ++
>  configs/xilinx_versal_virt_defconfig  |  2 ++
>  configs/xilinx_zynq_virt_defconfig|  2 ++
>  configs/xilinx_zynqmp_virt_defconfig  |  2 ++
>  drivers/dfu/Kconfig   | 20 
>  include/configs/am65x_evm.h   |  8 
>  include/configs/colibri-imx6ull.h |  1 -
>  include/configs/colibri_vf.h  |  1 -
>  include/configs/corvus.h  |  1 -
>  include/configs/dh_imx6.h |  1 -
>  include/configs/exynos4-common.h  |  1 -
>  include/configs/odroid_xu3.h  |  1 -
>  include/configs/pico-imx6.h   |  1 -
>  include/configs/pico-imx6ul.h |  1 -
>  include/configs/rpi.h |  3 ---
>  include/configs/s5p_goni.h|  1 -
>  include/configs/siemens-am33x-common.h|  1 -
>  include/configs/smartweb.h|  1 -
>  include/configs/socfpga_common.h  |  1 -
>  include/configs/taurus.h  |  1 -
>  include/configs/tegra-common-usb-gadget.h |  2 --
>  include/configs/warp.h|  1 -
>  include/configs/warp7.h   |  1 -
>  include/configs/xilinx_versal.h   |  1 -
>  include/configs/xilinx_zynqmp.h   |  1 -
>  include/configs/zynq-common.h |  1 -
>  include/dfu.h |  6 --
>  scripts/config_whitelist.txt  |  2 --
>  82 files changed, 136 insertions(+), 39 

[PATCH v2] usb: dfu: Migrate CONFIG_SYS_DFU_DATA_BUF_SIZE and CONFIG_SYS_DFU_MAX_FILE_SIZE to Kconfig

2021-02-26 Thread Aswath Govindraju
Currently the config options CONFIG_SYS_DFU_DATA_BUF_SIZE and
CONFIG_SYS_DFU_MAX_FILE_SIZE are being set in include/configs/.h
files and also in _defconfig files without a Kconfig option. It
is easier for users to set these configs in defconfig files than in config
header files as they are a part of the source code.

Add Kconfig symbols, and update the defconfigs by using tools/moveconfig.py
script.

Suggested-by: Pratyush Yadav 
Signed-off-by: Aswath Govindraju 
---

Changes since v1:
- Removed CONFIG_SYS_DFU_MAX_FILE_SIZE in defconfig files, where it was
  not defined previously. The list of files in which this change is made
  are listed below,
  configs/colibri-imx6ull_defconfig
  configs/colibri_vf_defconfig
  configs/corvus_defconfig
  configs/dh_imx6_defconfig
  configs/draco_defconfig
  configs/etamin_defconfig 
  configs/odroid-xu3_defconfig
  configs/odroid_defconfig
  configs/origen_defconfig
  configs/pico-dwarf-imx6ul_defconfig
  configs/pico-hobbit-imx6ul_defconfig
  configs/pico-imx6_defconfig
  configs/pico-imx6ul_defconfig
  configs/pico-pi-imx6ul_defconfig
  configs/pxm2_defconfig
  configs/rastaban_defconfig 
  configs/rut_defconfig
  configs/s5p_goni_defconfig
  configs/s5pc210_universal_defconfig
  configs/smartweb_defconfig  
  configs/socfpga_arria5_defconfig
  configs/socfpga_cyclone5_defconfig
  configs/socfpga_dbm_soc1_defconfig
  configs/socfpga_de0_nano_soc_defconfig
  configs/socfpga_de10_nano_defconfig 
  configs/socfpga_mcvevk_defconfig
  configs/socfpga_sockit_defconfig
  configs/socfpga_socrates_defconfig
  configs/socfpga_vining_fpga_defconfig
  configs/taurus_defconfig
  configs/thuban_defconfig
  configs/topic_miami_defconfig
  configs/topic_miamilite_defconfig
  configs/topic_miamiplus_defconfig 
  configs/trats2_defconfig 
  configs/trats_defconfig
  configs/warp7_bl33_defconfig
  configs/warp7_defconfig
  configs/warp_defconfig
  configs/xilinx_versal_virt_defconfig
  configs/xilinx_zynq_virt_defconfig
  configs/xilinx_zynqmp_virt_defconfig

Link to v1,
https://patchwork.ozlabs.org/project/uboot/patch/20210223061427.20742-1-a-govindr...@ti.com/
 

 configs/am65x_evm_a53_defconfig   |  2 ++
 configs/am65x_evm_r5_usbdfu_defconfig |  2 ++
 configs/am65x_hs_evm_a53_defconfig|  2 ++
 configs/beaver_defconfig  |  2 ++
 configs/cei-tk1-som_defconfig |  2 ++
 configs/colibri-imx6ull_defconfig |  1 +
 configs/colibri_vf_defconfig  |  1 +
 configs/corvus_defconfig  |  1 +
 configs/dalmore_defconfig |  2 ++
 configs/dh_imx6_defconfig |  1 +
 configs/draco_defconfig   |  1 +
 configs/e2220-1170_defconfig  |  2 ++
 configs/etamin_defconfig  |  1 +
 configs/jetson-tk1_defconfig  |  2 ++
 configs/nyan-big_defconfig|  2 ++
 configs/odroid-xu3_defconfig  |  1 +
 configs/odroid_defconfig  |  1 +
 configs/origen_defconfig  |  1 +
 configs/p2371-_defconfig  |  2 ++
 configs/p2371-2180_defconfig  |  2 ++
 configs/p2571_defconfig   |  2 ++
 configs/p3450-_defconfig  |  2 ++
 configs/pico-dwarf-imx6ul_defconfig   |  1 +
 configs/pico-hobbit-imx6ul_defconfig  |  1 +
 configs/pico-imx6_defconfig   |  1 +
 configs/pico-imx6ul_defconfig |  1 +
 configs/pico-pi-imx6ul_defconfig  |  1 +
 configs/pxm2_defconfig|  1 +
 configs/rastaban_defconfig|  1 +
 configs/rpi_4_32b_defconfig   |  2 ++
 configs/rpi_4_defconfig   |  2 ++
 configs/rut_defconfig |  1 +
 configs/s5p_goni_defconfig|  1 +
 configs/s5pc210_universal_defconfig   |  1 +
 configs/smartweb_defconfig|  1 +
 configs/socfpga_arria5_defconfig  |  1 +
 configs/socfpga_cyclone5_defconfig|  1 +
 configs/socfpga_dbm_soc1_defconfig|  1 +
 configs/socfpga_de0_nano_soc_defconfig|  1 +
 configs/socfpga_de10_nano_defconfig   |  1 +
 configs/socfpga_mcvevk_defconfig  |  1 +
 configs/socfpga_sockit_defconfig  |  1 +
 configs/socfpga_socrates_defconfig|  1 +
 configs/socfpga_vining_fpga_defconfig |  1 +
 configs/taurus_defconfig  |  1 +
 configs/thuban_defconfig  |  1 +
 configs/topic_miami_defconfig |  1 +
 configs/topic_miamilite_defconfig |  1 +
 configs/topic_miamiplus_defconfig |  1 +
 configs/trats2_defconfig  |  1 +
 configs/trats_defconfig   |  1 +
 configs/venice2_defconfig |  2 ++
 configs/warp7_bl33_defconfig  |  1 +
 configs/warp7_defconfig   |  1 +
 configs/warp_defconfig|  1 +
 configs/xilinx_versal_virt_defconfig  |  1 +
 configs/xilinx_zynq_virt_defconfig|  1 +
 

Re: [PATCH v2] configs: stm32mp1: enable uefi related commands

2021-02-26 Thread Patrick DELAUNAY

Hi,

On 2/26/21 1:52 PM, Ilias Apalodimas wrote:

The board can boot with UEFI. With the latest changes in U-Boot's
EFI subsystem we also have support for EFI runtime variables, without
SetVariable support.  We can also store the EFI variables in a file on the
ESP partition and preserve them across reboots.
The env and efidebug commands are missing in order to configure
EFI variables and the efibootmgr though.  Since U-Boot's default config
enables other EFI related commands (e.g bootefi), let's add the env related
and efidebug commands and allow users to do that

Signed-off-by: Ilias Apalodimas 
---
Changes since v1:
- Apply identical changes on stm32mp15_basic_defconfig
  configs/stm32mp15_basic_defconfig   | 3 +++
  configs/stm32mp15_trusted_defconfig | 3 +++
  2 files changed, 6 insertions(+)




Reviewed-by: Patrick Delaunay 

Thanks
Patrick




Re: [PATCH] spi: Update speed/mode on change

2021-02-26 Thread Patrick DELAUNAY

Hi Marek,

On 2/25/21 9:52 PM, Marek Vasut wrote:

The spi_get_bus_and_cs() may be called on the same bus and chipselect
with different frequency or mode. This is valid usecase, but the code
fails to notify the controller of such a configuration change. Call
spi_set_speed_mode() in case bus frequency or bus mode changed to let
the controller update the configuration.

The problem can easily be triggered using the sspi command:
=> sspi 0:0@1000
=> sspi 0:0@2000
Without this patch, both transfers happen at 1000 Hz. With this patch,
the later transfer happens correctly at 2000 Hz.

Signed-off-by: Marek Vasut 
Cc: Jagan Teki 
Cc: Patrick Delaunay 
---
  drivers/spi/spi-uclass.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index 7155d4aebd6..96c9a83e761 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -405,12 +405,22 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int 
mode,
goto err;
}
  
+	/* In case bus frequency or mode changed, update it. */

+   if ((speed && slave->speed && slave->speed != speed) ||
+   (plat->mode != mode)) {
+   ret = spi_set_speed_mode(bus, speed, mode);
+   if (ret)
+   goto err_speed_mode;
+   }
+


We compare bus (with lastest configured value ) or slave (value 
requested) here ?


in dm_spi_claim_bus() it is compared with bus :

spi->speed and spi->mode and spi = dev_get_uclass_priv(bus);

+   /* In case bus frequency or mode changed, update it. */
+   if ((speed && bus->speed != speed) || (bus->mode != mode)) {
+   ret = spi_set_speed_mode(bus, speed, mode);
+   if (ret)
+   goto err_speed_mode;
+   bus->speed = speed;
+   bus->mode = mode;
+   }

NB: bus->speed can't be 0 here after previous spi_claim_bus()

PS: the update of spi->speed and spi->mode can be done in 
spi_set_speed_mode() function




*busp = bus;
*devp = slave;
log_debug("%s: bus=%p, slave=%p\n", __func__, bus, *devp);
  
  	return 0;
  
+err_speed_mode:

+   spi_claim_bus(slave);



here I think it is:

spi_release_bus(slave);

called after previous spi_claim_bus().


  err:
log_debug("%s: Error path, created=%d, device '%s'\n", __func__,
  created, dev->name);


Regards

Patrick



Re: [PATCH u-boot-dm + u-boot-spi v3 00/11] Support SPI NORs and OF partitions in `mtd list`

2021-02-26 Thread Patrice CHOTARD
Hi All

On 2/25/21 3:13 PM, Marek Behún wrote:
> Hello,
> 
> this is v3 of patchset that adds support for U-Boot to parse MTD
> partitions from device-tree, and also improves support for SPI NOR
> access via the `mtd` command.
> 
> Changes since v2:
> - addressed Pali's comments in patch that adds partition parsing (4/7 in
>   this version): no check for whether the `compatible` property is
>   present in a partition node and added comment explaining mask flags)
> - added 4 more patches:
>   1) adding ofnode_get_path() function
>   2) printing OF path in `mtd list`
>   3) in `mtd read  ...`,  can now also be DM's device name
>  or OF path
>   4) the fact from 3) is added to `mtd help`
> 
> Changes since v1:
> - added tests of ofnode_get_addr_size_index() and
>   ofnode_get_addr_size_index_notrans() as requested by Simon
> - the last patch now probes SPI NORs in both versions of
>   mtd_probe_devices(), that is when MTDPARTS is enabled or disabled
> 
> Marek
> 
> Cc: Jagan Teki 
> Cc: Priyanka Jain 
> Cc: Simon Glass 
> Cc: Heiko Schocher 
> Cc: Jagan Teki 
> Cc: Patrick Delaunay 
> Cc: Patrice CHOTARD 
> Cc: Miquel Raynal 
> 
> Marek Behún (11):
>   dm: core: add test for ofnode_get_addr_size_index()
>   dm: core: add non-translating version of ofnode_get_addr_size_index()
>   dm: core: add ofnode_get_path()
>   mtd: add support for parsing partitions defined in OF
>   mtd: spi-nor: allow registering multiple MTDs when DM is enabled
>   mtd: spi-nor: fill-in mtd->dev member
>   mtd: remove mtd_probe() function
>   mtd: probe SPI NOR devices in mtd_probe_devices()
>   cmd: mtd: print device OF path in listing
>   mtd: compare also with OF path and device name in get_mtd_device_nm()
>   cmd: mtd: expand  argument definition in command help
> 
>  cmd/mtd.c  |  11 ++-
>  drivers/core/ofnode.c  |  44 ++-
>  drivers/mtd/mtd-uclass.c   |  15 
>  drivers/mtd/mtd_uboot.c| 129 -
>  drivers/mtd/mtdcore.c  |  29 
>  drivers/mtd/mtdpart.c  |  63 
>  drivers/mtd/spi/sf_internal.h  |   4 +-
>  drivers/mtd/spi/sf_mtd.c   |  19 -
>  drivers/mtd/spi/sf_probe.c |   6 +-
>  drivers/mtd/spi/spi-nor-core.c |   1 +
>  drivers/mtd/spi/spi-nor-tiny.c |   1 +
>  include/dm/ofnode.h|  27 +++
>  include/linux/mtd/mtd.h|   9 +++
>  include/mtd.h  |   1 -
>  test/dm/ofnode.c   |  50 +
>  15 files changed, 334 insertions(+), 75 deletions(-)
> 

Tested-by: Patrice Chotard 
on stm32mp1-ev1 

Thanks
Patrice



Re: make O=directory parameter

2021-02-26 Thread Tom Rini
On Fri, Feb 26, 2021 at 10:27:46PM +1100, Fred 1 wrote:
> On 26/2/21 2:35 am, Tom Rini wrote:
> > On Thu, Feb 25, 2021 at 12:50:47PM +1100, Fred 1 wrote:
> > 
> > > like in the linux kernel build
> > > 
> > > make O=builds/arm
> > > 
> > > builds the result to the specified output directory
> > > 
> > > 
> > > is this supposed to work for uboot also ?
> > > 
> > > doesn't seem to work for me, i've fetched older tar files and same problem
> > > 
> > > maybe my environment?
> > > 
> > >      fedora32
> > > 
> > >      5.10.13-100.fc32.x86_64
> > > 
> > >      GNU Make 4.2.1
> > > 
> > > the O=  does mostly work on older uboot like from ~2010 though
> > > 
> > > 
> > > thought i'd ask as debugging the make process is,well umm...horrible,
> > > 
> > > (i've inserted some extra debug print codes in gnu make (it self no code 
> > > to
> > > be praised about!
> > > 
> > > esp when so much open source depends on it!!)
> > > 
> > > so atm, a bit of a rabbit holeshould I persist?
> > Can you provide a sample failure?  The last "make O=... fails" I saw was
> > because they were passing ARCH= which isn't valid for U-Boot and
> > specifically breaks if you're say building for an aarch64 platform as in
> > the linux kernel you would do ARCH=arm64 but it's all "arm" here.
> > Thanks!
> > 
> so ok, i'v dropped using the ARCH=
> still
> 
> All the configs i tried failed:
> 
> make O=builds/rpi2  rpi_2_defconfig
> make O=builds/rpi2 mrproper   <==tried this too
> 
> make O=builds/rpi2 -w -d V=1 CROSS_COMPILE=arm-none-eabi-
> qemu_mips_defconfig
> orangepi_zero_defconfig
> 
> qemu_arm_defconfig
> 
> 
> Of course the builds all work just fine without O=, and results in the main
> directory.
> 
> So this is not just a problem on my machine?, i guess everyone just uses it
> like so ?
> 
> anyway i am sufficiently annoyed with it, i'll have a go at finding out
> why..

I don't know what's going on with your local environment.  For me, I
just now did:
make O=builds/rpi2 -w -d V=1 CROSS_COMPILE= rpi_2_defconfig all
and it completed.  Perhaps you have something set in your environment?
It's hard to say without seeing your error message.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 05/14] spi: spi-mem: Add debug message for spi-mem ops

2021-02-26 Thread Sean Anderson



On 2/26/21 5:12 AM, Jagan Teki wrote:

On Fri, Feb 5, 2021 at 9:41 AM Sean Anderson  wrote:


This prints some basic metadata about the SPI memory op. This information
may be used to debug SPI drivers (e.g. determining the expected SPI mode).
It is also helpful for verifying that the data on the wire matches the data
intended to be transmitted (e.g. with a logic analyzer). The opcode is
printed with a format of %02Xh to match the notation commonly used in flash
datasheets.

Signed-off-by: Sean Anderson 
Reviewed-by: Pratyush Yadav 
---

Changes in v2:
- Add more information to exec_op debug message

  drivers/spi/spi-mem.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index c095ae9505..6772367ef7 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -220,6 +220,13 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct 
spi_mem_op *op)
 int ret;
 int i;

+   dev_dbg(slave->dev,
+   "exec %02Xh %u-%u-%u addr=%llx dummy cycles=%u data bytes=%u\n",
+   op->cmd.opcode, op->cmd.buswidth, op->addr.buswidth,
+   op->data.buswidth, op->addr.val,
+   op->dummy.buswidth ? op->dummy.nbytes * 8 / op->dummy.buswidth 
: 0,
+   op->data.nbytes);


This looks unnecessary to me, we have debug prints at the end of the
function, which indeed sufficient.



This is insufficient. First, that information is printed after the op
is executed. This is too late if one is trying to debug (e.g.) a hang in
the spi driver. It's also missing opcode, widths, address, and dummy
bytes. The only duplicated info here is nbytes. Since this is debugging
information, I think we should print what is most useful for people
debugging this subsystem.

--Sean


Re: Commit 401d1c4f5d2 ("common: Drop asm/global_data.h from common header") broke CONFIG_CMD_SQUASHFS=y

2021-02-26 Thread Pali Rohár
On Friday 26 February 2021 07:51:53 Tom Rini wrote:
> On Fri, Feb 26, 2021 at 01:34:29PM +0100, Pali Rohár wrote:
> 
> > Hello!
> > 
> > Commit 401d1c4f5d2d29c4bc4beaec95402ca23eb63295 ("common: Drop
> > asm/global_data.h from common header") broke compilation of
> > squashfs filesystem when CONFIG_CMD_SQUASHFS=y is enabled.
> > 
> > Here is console output:
> > 
> > fs/squashfs/sqfs_inode.c: In function ‘sqfs_find_inode’:
> > fs/squashfs/sqfs_inode.c:121:18: warning: implicit declaration of function 
> > ‘le32_to_cpu’ [-Wimplicit-function-declaration]
> >   for (k = 0; k < le32_to_cpu(inode_count); k++) {
> >   ^~~
> >   LD  u-boot
> > aarch64-linux-gnu-ld.bfd: fs/built-in.o: in function `sqfs_find_inode':
> > /u-boot/fs/squashfs/sqfs_inode.c:126: undefined reference to `le32_to_cpu'
> > aarch64-linux-gnu-ld.bfd: /u-boot/fs/squashfs/sqfs_inode.c:121: undefined 
> > reference to `le32_to_cpu'
> > Segmentation fault
> > make: *** [Makefile:1765: u-boot] Error 139
> > make: *** Deleting file 'u-boot'
> > 
> > When compiling U-Boot prior that commit, there is no error.
> > 
> > Simon and Tom: you have signed problematic mentioned commit. Could you
> > please look at it?
> 
> Yes, that file probably needs , please check.
> 
> -- 
> Tom

Perfect, including  fixed it!


[PATCH v2] configs: stm32mp1: enable uefi related commands

2021-02-26 Thread Ilias Apalodimas
The board can boot with UEFI. With the latest changes in U-Boot's
EFI subsystem we also have support for EFI runtime variables, without
SetVariable support.  We can also store the EFI variables in a file on the
ESP partition and preserve them across reboots.
The env and efidebug commands are missing in order to configure
EFI variables and the efibootmgr though.  Since U-Boot's default config
enables other EFI related commands (e.g bootefi), let's add the env related
and efidebug commands and allow users to do that

Signed-off-by: Ilias Apalodimas 
---
Changes since v1:
- Apply identical changes on stm32mp15_basic_defconfig
 configs/stm32mp15_basic_defconfig   | 3 +++
 configs/stm32mp15_trusted_defconfig | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/configs/stm32mp15_basic_defconfig 
b/configs/stm32mp15_basic_defconfig
index def6a51b4031..1c680984b876 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -34,6 +34,7 @@ CONFIG_SPL_SPI_FLASH_MTD=y
 CONFIG_SYS_PROMPT="STM32MP> "
 CONFIG_CMD_ADTIMG=y
 CONFIG_CMD_ERASEENV=y
+CONFIG_CMD_NVEDIT_EFI=y
 CONFIG_CMD_MEMINFO=y
 CONFIG_CMD_MEMTEST=y
 CONFIG_CMD_ADC=y
@@ -49,6 +50,7 @@ CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
 CONFIG_CMD_BMP=y
 CONFIG_CMD_CACHE=y
+CONFIG_CMD_EFIDEBUG=y
 CONFIG_CMD_TIME=y
 CONFIG_CMD_TIMER=y
 CONFIG_CMD_PMIC=y
@@ -164,4 +166,5 @@ CONFIG_BMP_32BPP=y
 CONFIG_WDT=y
 CONFIG_WDT_STM32MP=y
 CONFIG_ERRNO_STR=y
+# CONFIG_HEXDUMP is not set
 CONFIG_FDT_FIXUP_PARTITIONS=y
diff --git a/configs/stm32mp15_trusted_defconfig 
b/configs/stm32mp15_trusted_defconfig
index da31b74cdeb6..107041119f1d 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -17,6 +17,7 @@ CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
 CONFIG_SYS_PROMPT="STM32MP> "
 CONFIG_CMD_ADTIMG=y
 CONFIG_CMD_ERASEENV=y
+CONFIG_CMD_NVEDIT_EFI=y
 CONFIG_CMD_MEMINFO=y
 CONFIG_CMD_MEMTEST=y
 CONFIG_CMD_ADC=y
@@ -32,6 +33,7 @@ CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
 CONFIG_CMD_BMP=y
 CONFIG_CMD_CACHE=y
+CONFIG_CMD_EFIDEBUG=y
 CONFIG_CMD_TIME=y
 CONFIG_CMD_TIMER=y
 CONFIG_CMD_PMIC=y
@@ -144,4 +146,5 @@ CONFIG_BMP_32BPP=y
 CONFIG_WDT=y
 CONFIG_WDT_STM32MP=y
 CONFIG_ERRNO_STR=y
+# CONFIG_HEXDUMP is not set
 CONFIG_FDT_FIXUP_PARTITIONS=y
-- 
2.30.1



[PATCH 5/5] patman: Assume we always have pygit2 for tests

2021-02-26 Thread Tom Rini
Given that we have tests that require pygit2 and it can be installed
like any other python module, fail much more loudly if it is missing.

Cc: Simon Glass 
Signed-off-by: Tom Rini 
---
 tools/patman/func_test.py | 19 ++-
 1 file changed, 2 insertions(+), 17 deletions(-)

diff --git a/tools/patman/func_test.py b/tools/patman/func_test.py
index 89072b1ae7fa..b956fb96f396 100644
--- a/tools/patman/func_test.py
+++ b/tools/patman/func_test.py
@@ -25,13 +25,8 @@ from patman import terminal
 from patman import tools
 from patman.test_util import capture_sys_output
 
-try:
-import pygit2
-HAVE_PYGIT2 = True
-from patman import status
-except ModuleNotFoundError:
-HAVE_PYGIT2 = False
-
+import pygit2
+from patman import status
 
 class TestFunctional(unittest.TestCase):
 """Functional tests for checking that patman behaves correctly"""
@@ -458,7 +453,6 @@ complicated as possible''')
 repo.branches.local.create('base', base_target)
 return repo
 
-@unittest.skipIf(not HAVE_PYGIT2, 'Missing python3-pygit2')
 def testBranch(self):
 """Test creating patches from a branch"""
 repo = self.make_git_tree()
@@ -604,7 +598,6 @@ diff --git a/lib/efi_loader/efi_memory.c 
b/lib/efi_loader/efi_memory.c
 ["Found possible blank line(s) at end of file 'lib/fdtdec.c'"],
 pstrm.commit.warn)
 
-@unittest.skipIf(not HAVE_PYGIT2, 'Missing python3-pygit2')
 def testNoUpstream(self):
 """Test CountCommitsToBranch when there is no upstream"""
 repo = self.make_git_tree()
@@ -642,7 +635,6 @@ diff --git a/lib/efi_loader/efi_memory.c 
b/lib/efi_loader/efi_memory.c
 {'id': '1', 'name': 'Some patch'}]}
 raise ValueError('Fake Patchwork does not understand: %s' % subpath)
 
-@unittest.skipIf(not HAVE_PYGIT2, 'Missing python3-pygit2')
 def testStatusMismatch(self):
 """Test Patchwork patches not matching the series"""
 series = Series()
@@ -652,7 +644,6 @@ diff --git a/lib/efi_loader/efi_memory.c 
b/lib/efi_loader/efi_memory.c
 self.assertIn('Warning: Patchwork reports 1 patches, series has 0',
   err.getvalue())
 
-@unittest.skipIf(not HAVE_PYGIT2, 'Missing python3-pygit2')
 def testStatusReadPatch(self):
 """Test handling a single patch in Patchwork"""
 series = Series()
@@ -665,7 +656,6 @@ diff --git a/lib/efi_loader/efi_memory.c 
b/lib/efi_loader/efi_memory.c
 self.assertEqual('1', patch.id)
 self.assertEqual('Some patch', patch.raw_subject)
 
-@unittest.skipIf(not HAVE_PYGIT2, 'Missing python3-pygit2')
 def testParseSubject(self):
 """Test parsing of the patch subject"""
 patch = status.Patch('1')
@@ -728,7 +718,6 @@ diff --git a/lib/efi_loader/efi_memory.c 
b/lib/efi_loader/efi_memory.c
 self.assertEqual('RESEND', patch.prefix)
 self.assertEqual(None, patch.version)
 
-@unittest.skipIf(not HAVE_PYGIT2, 'Missing python3-pygit2')
 def testCompareSeries(self):
 """Test operation of compare_with_series()"""
 commit1 = Commit('abcd')
@@ -831,7 +820,6 @@ diff --git a/lib/efi_loader/efi_memory.c 
b/lib/efi_loader/efi_memory.c
 return patch.comments
 raise ValueError('Fake Patchwork does not understand: %s' % subpath)
 
-@unittest.skipIf(not HAVE_PYGIT2, 'Missing python3-pygit2')
 def testFindNewResponses(self):
 """Test operation of find_new_responses()"""
 commit1 = Commit('abcd')
@@ -970,7 +958,6 @@ diff --git a/lib/efi_loader/efi_memory.c 
b/lib/efi_loader/efi_memory.c
 return patch.comments
 raise ValueError('Fake Patchwork does not understand: %s' % subpath)
 
-@unittest.skipIf(not HAVE_PYGIT2, 'Missing python3-pygit2')
 def testCreateBranch(self):
 """Test operation of create_branch()"""
 repo = self.make_git_tree()
@@ -1058,7 +1045,6 @@ diff --git a/lib/efi_loader/efi_memory.c 
b/lib/efi_loader/efi_memory.c
 self.assertEqual('Reviewed-by: %s' % self.mary, next(lines))
 self.assertEqual('Tested-by: %s' % self.leb, next(lines))
 
-@unittest.skipIf(not HAVE_PYGIT2, 'Missing python3-pygit2')
 def testParseSnippets(self):
 """Test parsing of review snippets"""
 text = '''Hi Fred,
@@ -1142,7 +1128,6 @@ line8
   'line2', 'line3', 'line4', 'line5', 'line6', 'line7', 'line8']],
 pstrm.snippets)
 
-@unittest.skipIf(not HAVE_PYGIT2, 'Missing python3-pygit2')
 def testReviewSnippets(self):
 """Test showing of review snippets"""
 def _to_submitter(who):
-- 
2.17.1



[PATCH 3/5] Azure/GitLab: Ensure we use requirements.txt for testsuites

2021-02-26 Thread Tom Rini
Given that test/py/requirements.txt has all required test modules, make
use of that rather than a manual pip install list before running our
assorted tool testsuites.

Signed-off-by: Tom Rini 
---
 .azure-pipelines.yml | 2 +-
 .gitlab-ci.yml   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index a6279427e138..0a4f90f75f3b 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -144,7 +144,7 @@ jobs:
   export USER=azure
   virtualenv -p /usr/bin/python3 /tmp/venv
   . /tmp/venv/bin/activate
-  pip install pyelftools pytest pygit2
+  pip install -r test/py/requirements.txt
   export UBOOT_TRAVIS_BUILD_DIR=/tmp/sandbox_spl
   export PYTHONPATH=${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc/pylibfdt
   export PATH=${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc:${PATH}
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index ceba5ce7a905..ce0e63481a11 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -151,7 +151,7 @@ Run binman, buildman, dtoc, Kconfig and patman testsuites:
   export USER=gitlab;
   virtualenv -p /usr/bin/python3 /tmp/venv;
   . /tmp/venv/bin/activate;
-  pip install pyelftools pytest pygit2;
+  pip install -r test/py/requirements.txt;
   export UBOOT_TRAVIS_BUILD_DIR=/tmp/sandbox_spl;
   export PYTHONPATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc/pylibfdt";
   export PATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc:${PATH}";
-- 
2.17.1



[PATCH 4/5] tests: patman: Add requests to the module list

2021-02-26 Thread Tom Rini
The patman tests require the requests module, add it.

Cc: Simon Glass 
Signed-off-by: Tom Rini 
---
 test/py/requirements.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/test/py/requirements.txt b/test/py/requirements.txt
index 89ca259b213b..f396eb646362 100644
--- a/test/py/requirements.txt
+++ b/test/py/requirements.txt
@@ -16,6 +16,7 @@ pyparsing==2.4.2
 pytest==5.2.1
 python-mimeparse==1.6.0
 python-subunit==1.3.0
+requests==2.25.1
 six==1.12.0
 testtools==2.3.0
 traceback2==1.4.0
-- 
2.17.1



[PATCH 2/5] pytest: Lower pygit2 requirement

2021-02-26 Thread Tom Rini
The latest versions of pygit2 are not available in practically any
distribution at this time.  Furthermore, we don't need the latest in
order to run all of our testsuites.  Reduce this version requirement to
something older that meets our needs while still supporting running our
tests on older hosts (and so, test labs).

Reported-by: Tom Warren 
Signed-off-by: Tom Rini 
---
 test/py/requirements.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/py/requirements.txt b/test/py/requirements.txt
index 926bccad694f..89ca259b213b 100644
--- a/test/py/requirements.txt
+++ b/test/py/requirements.txt
@@ -11,7 +11,7 @@ pbr==5.4.3
 pluggy==0.13.0
 py==1.8.0
 pyelftools==0.27
-pygit2==1.4.0
+pygit2==0.28.2
 pyparsing==2.4.2
 pytest==5.2.1
 python-mimeparse==1.6.0
-- 
2.17.1



[PATCH 1/5] GitLab: Remove "tags" stanzas

2021-02-26 Thread Tom Rini
Given the structure of our current GitLab tests, we don't make real use
of the tags.  Furthermore, these tags prevent the automatic usage of the
default GitLab runners.  Remove these tags.

Reported-by: Roger Meier 
Signed-off-by: Tom Rini 
---
 .gitlab-ci.yml | 46 --
 1 file changed, 46 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 2cdcd864c86a..ceba5ce7a905 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -11,7 +11,6 @@ stages:
   - world build
 
 .buildman_and_testpy_template: _and_testpy_dfn
-  tags: [ 'all' ]
   stage: test.py
   before_script:
 # Clone uboot-test-hooks
@@ -53,7 +52,6 @@ stages:
 --build-dir "$UBOOT_TRAVIS_BUILD_DIR"
 
 build all 32bit ARM platforms:
-  tags: [ 'all' ]
   stage: world build
   script:
 - ret=0;
@@ -64,7 +62,6 @@ build all 32bit ARM platforms:
   fi;
 
 build all 64bit ARM platforms:
-  tags: [ 'all' ]
   stage: world build
   script:
 - virtualenv -p /usr/bin/python3 /tmp/venv
@@ -78,7 +75,6 @@ build all 64bit ARM platforms:
   fi;
 
 build all PowerPC platforms:
-  tags: [ 'all' ]
   stage: world build
   script:
 - ret=0;
@@ -89,7 +85,6 @@ build all PowerPC platforms:
   fi;
 
 build all other platforms:
-  tags: [ 'all' ]
   stage: world build
   script:
 - ret=0;
@@ -102,14 +97,12 @@ build all other platforms:
 # QA jobs for code analytics
 # static code analysis with cppcheck (we can add --enable=all later)
 cppcheck:
-  tags: [ 'all' ]
   stage: testsuites
   script:
 - cppcheck -j$(nproc) --force --quiet --inline-suppr .
 
 # search for TODO within source tree
 grep TODO/FIXME/HACK:
-  tags: [ 'all' ]
   stage: testsuites
   script:
 - grep -r TODO .
@@ -119,7 +112,6 @@ grep TODO/FIXME/HACK:
 
 # build HTML documentation
 htmldocs:
-  tags: [ 'all' ]
   stage: testsuites
   script:
 - virtualenv -p /usr/bin/python3 /tmp/venvhtml
@@ -129,34 +121,29 @@ htmldocs:
 
 # some statistics about the code base
 sloccount:
-  tags: [ 'all' ]
   stage: testsuites
   script:
 - sloccount .
 
 # ensure all configs have MAINTAINERS entries
 Check for configs without MAINTAINERS entry:
-  tags: [ 'all' ]
   stage: testsuites
   script:
 - if [ `./tools/genboardscfg.py -f 2>&1 | wc -l` -ne 0 ]; then exit 1; fi
 
 # Ensure host tools build
 Build tools-only:
-  tags: [ 'all' ]
   stage: testsuites
   script:
 - make tools-only_config tools-only -j$(nproc)
 
 # Ensure env tools build
 Build envtools:
-  tags: [ 'all' ]
   stage: testsuites
   script:
 - make tools-only_config envtools -j$(nproc)
 
 Run binman, buildman, dtoc, Kconfig and patman testsuites:
-  tags: [ 'all' ]
   stage: testsuites
   script:
 - git config --global user.name "GitLab CI Runner";
@@ -176,7 +163,6 @@ Run binman, buildman, dtoc, Kconfig and patman testsuites:
   make testconfig
 
 Run tests for Nokia RX-51 (aka N900):
-  tags: [ 'all' ]
   stage: testsuites
   script:
 - ./tools/buildman/buildman --fetch-arch arm;
@@ -185,54 +171,46 @@ Run tests for Nokia RX-51 (aka N900):
 
 # Test sandbox with test.py
 sandbox test.py:
-  tags: [ 'all' ]
   variables:
 TEST_PY_BD: "sandbox"
   <<: *buildman_and_testpy_dfn
 
 sandbox with clang test.py:
-  tags: [ 'all' ]
   variables:
 TEST_PY_BD: "sandbox"
 OVERRIDE: "-O clang-10"
   <<: *buildman_and_testpy_dfn
 
 sandbox_spl test.py:
-  tags: [ 'all' ]
   variables:
 TEST_PY_BD: "sandbox_spl"
 TEST_PY_TEST_SPEC: "test_ofplatdata or test_handoff or test_spl"
   <<: *buildman_and_testpy_dfn
 
 evb-ast2500 test.py:
-  tags: [ 'all' ]
   variables:
 TEST_PY_BD: "evb-ast2500"
 TEST_PY_ID: "--id qemu"
   <<: *buildman_and_testpy_dfn
 
 sandbox_flattree test.py:
-  tags: [ 'all' ]
   variables:
 TEST_PY_BD: "sandbox_flattree"
   <<: *buildman_and_testpy_dfn
 
 vexpress_ca15_tc2 test.py:
-  tags: [ 'all' ]
   variables:
 TEST_PY_BD: "vexpress_ca15_tc2"
 TEST_PY_ID: "--id qemu"
   <<: *buildman_and_testpy_dfn
 
 vexpress_ca9x4 test.py:
-  tags: [ 'all' ]
   variables:
 TEST_PY_BD: "vexpress_ca9x4"
 TEST_PY_ID: "--id qemu"
   <<: *buildman_and_testpy_dfn
 
 integratorcp_cm926ejs test.py:
-  tags: [ 'all' ]
   variables:
 TEST_PY_BD: "integratorcp_cm926ejs"
 TEST_PY_TEST_SPEC: "not sleep"
@@ -240,49 +218,42 @@ integratorcp_cm926ejs test.py:
   <<: *buildman_and_testpy_dfn
 
 qemu_arm test.py:
-  tags: [ 'all' ]
   variables:
 TEST_PY_BD: "qemu_arm"
 TEST_PY_TEST_SPEC: "not sleep"
   <<: *buildman_and_testpy_dfn
 
 qemu_arm64 test.py:
-  tags: [ 'all' ]
   variables:
 TEST_PY_BD: "qemu_arm64"
 TEST_PY_TEST_SPEC: "not sleep"
   <<: *buildman_and_testpy_dfn
 
 qemu_mips test.py:
-  tags: [ 'all' ]
   variables:
 TEST_PY_BD: "qemu_mips"
 TEST_PY_TEST_SPEC: "not sleep"
   <<: *buildman_and_testpy_dfn
 
 qemu_mipsel test.py:
-  tags: [ 'all' ]
   variables:
 TEST_PY_BD: "qemu_mipsel"
 TEST_PY_TEST_SPEC: "not sleep"
   <<: *buildman_and_testpy_dfn
 
 

Re: Commit 401d1c4f5d2 ("common: Drop asm/global_data.h from common header") broke CONFIG_CMD_SQUASHFS=y

2021-02-26 Thread Tom Rini
On Fri, Feb 26, 2021 at 01:34:29PM +0100, Pali Rohár wrote:

> Hello!
> 
> Commit 401d1c4f5d2d29c4bc4beaec95402ca23eb63295 ("common: Drop
> asm/global_data.h from common header") broke compilation of
> squashfs filesystem when CONFIG_CMD_SQUASHFS=y is enabled.
> 
> Here is console output:
> 
> fs/squashfs/sqfs_inode.c: In function ‘sqfs_find_inode’:
> fs/squashfs/sqfs_inode.c:121:18: warning: implicit declaration of function 
> ‘le32_to_cpu’ [-Wimplicit-function-declaration]
>   for (k = 0; k < le32_to_cpu(inode_count); k++) {
>   ^~~
>   LD  u-boot
> aarch64-linux-gnu-ld.bfd: fs/built-in.o: in function `sqfs_find_inode':
> /u-boot/fs/squashfs/sqfs_inode.c:126: undefined reference to `le32_to_cpu'
> aarch64-linux-gnu-ld.bfd: /u-boot/fs/squashfs/sqfs_inode.c:121: undefined 
> reference to `le32_to_cpu'
> Segmentation fault
> make: *** [Makefile:1765: u-boot] Error 139
> make: *** Deleting file 'u-boot'
> 
> When compiling U-Boot prior that commit, there is no error.
> 
> Simon and Tom: you have signed problematic mentioned commit. Could you
> please look at it?

Yes, that file probably needs , please check.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 04/14] mtd: spi-mem: Export spi_mem_default_supports_op

2021-02-26 Thread Sean Anderson

On 2/26/21 5:22 AM, Jagan Teki wrote:

On Fri, Feb 5, 2021 at 9:41 AM Sean Anderson  wrote:


This is useful for extending the default functionality. This mirrors the
change in Linux commit 46109648052f ("spi: spi-mem: export
spi_mem_default_supports_op()").

Signed-off-by: Sean Anderson 
Reviewed-by: Bin Meng 
Reviewed-by: Pratyush Yadav 
---

(no changes since v1)

  include/spi-mem.h | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/include/spi-mem.h b/include/spi-mem.h
index ca0f55c8fd..1dd556b6cf 100644
--- a/include/spi-mem.h
+++ b/include/spi-mem.h
@@ -236,6 +236,9 @@ spi_controller_dma_unmap_mem_op_data(struct spi_controller 
*ctlr,

  int spi_mem_adjust_op_size(struct spi_slave *slave, struct spi_mem_op *op);

+bool spi_mem_default_supports_op(struct spi_slave *slave,
+const struct spi_mem_op *op);
+


But, does it used anywhere now? if not it's better to add when it requires.

Jagan.



Yes, it is used in this driver later in this series.

--Sean


[PATCH] arm64: Update memcpy_{from, to}io() helpers

2021-02-26 Thread Patrice Chotard
At early U-Boot stage, before relocation, MMU is not yet configured
and disabled. DDR may not be configured with the correct memory
attributes (can be configured in MT_DEVICE instead of MT_MEMORY).

In this case, usage of memcpy_{from, to}io() may leads to synchronous
abort in AARCH64 in case the normal memory address is not 64Bits aligned.

To avoid such situation, forbid usage of normal memory cast to (u64 *) in
case MMU is not enabled.

Signed-off-by: Patrice Chotard 
Cc: mark.kette...@xs4all.nl
---

 arch/arm/cpu/armv8/cache_v8.c | 10 ++
 arch/arm/include/asm/io.h | 25 +++--
 include/cpu_func.h|  1 +
 3 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index 15cecb5e0b..3de18c7675 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -719,6 +719,11 @@ int icache_status(void)
return (get_sctlr() & CR_I) != 0;
 }
 
+int mmu_status(void)
+{
+   return (get_sctlr() & CR_M) != 0;
+}
+
 void invalidate_icache_all(void)
 {
__asm_invalidate_icache_all();
@@ -740,6 +745,11 @@ int icache_status(void)
return 0;
 }
 
+int mmu_status(void)
+{
+   return 0;
+}
+
 void invalidate_icache_all(void)
 {
 }
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index df264a170b..36b840378a 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -338,6 +338,7 @@ extern void __readwrite_bug(const char *fn);
 
 /* Optimized copy functions to read from/write to IO sapce */
 #ifdef CONFIG_ARM64
+#include 
 /*
  * Copy data from IO memory space to "real" memory space.
  */
@@ -351,11 +352,13 @@ void __memcpy_fromio(void *to, const volatile void 
__iomem *from, size_t count)
count--;
}
 
-   while (count >= 8) {
-   *(u64 *)to = __raw_readq(from);
-   from += 8;
-   to += 8;
-   count -= 8;
+   if (mmu_status()) {
+   while (count >= 8) {
+   *(u64 *)to = __raw_readq(from);
+   from += 8;
+   to += 8;
+   count -= 8;
+   }
}
 
while (count) {
@@ -379,11 +382,13 @@ void __memcpy_toio(volatile void __iomem *to, const void 
*from, size_t count)
count--;
}
 
-   while (count >= 8) {
-   __raw_writeq(*(u64 *)from, to);
-   from += 8;
-   to += 8;
-   count -= 8;
+   if (mmu_status()) {
+   while (count >= 8) {
+   __raw_writeq(*(u64 *)from, to);
+   from += 8;
+   to += 8;
+   count -= 8;
+   }
}
 
while (count) {
diff --git a/include/cpu_func.h b/include/cpu_func.h
index 8aa825daa4..a8806dd295 100644
--- a/include/cpu_func.h
+++ b/include/cpu_func.h
@@ -59,6 +59,7 @@ int dcache_status(void);
 void dcache_enable(void);
 void dcache_disable(void);
 void mmu_disable(void);
+int mmu_status(void);
 
 /* arch/$(ARCH)/lib/cache.c */
 void enable_caches(void);
-- 
2.17.1



Re: [PATCH] configs: stm32mp1: enable uefi related commands

2021-02-26 Thread Ilias Apalodimas
On Fri, Feb 26, 2021 at 01:38:21PM +0100, Patrick DELAUNAY wrote:
> Hi Ilias
> 
> On 2/25/21 8:37 PM, Ilias Apalodimas wrote:
> > The board can boot with UEFI. With the latest changes in U-Boot's
> > EFI subsystem we also have support for EFI runtime variables, without
> > SetVariable support.  We can also store the EFI variables in a file on the
> > ESP partition and preserve them across reboots.
> > The env and efidebug commands are missing in order to configure
> > EFI variables and the efibootmgr though.  Since U-Boot's default config
> > enables other EFI related commands (e.g bootefi), let's add the env related
> > and efidebug commands and allow users to do that
> > 
> > Signed-off-by: Ilias Apalodimas 
> > ---
> >   configs/stm32mp15_trusted_defconfig | 3 +++
> >   1 file changed, 3 insertions(+)
> > 
> > diff --git a/configs/stm32mp15_trusted_defconfig 
> > b/configs/stm32mp15_trusted_defconfig
> > index da31b74cdeb6..107041119f1d 100644
> > --- a/configs/stm32mp15_trusted_defconfig
> > +++ b/configs/stm32mp15_trusted_defconfig
> > @@ -17,6 +17,7 @@ CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
> >   CONFIG_SYS_PROMPT="STM32MP> "
> >   CONFIG_CMD_ADTIMG=y
> >   CONFIG_CMD_ERASEENV=y
> > +CONFIG_CMD_NVEDIT_EFI=y
> >   CONFIG_CMD_MEMINFO=y
> >   CONFIG_CMD_MEMTEST=y
> >   CONFIG_CMD_ADC=y
> > @@ -32,6 +33,7 @@ CONFIG_CMD_USB=y
> >   CONFIG_CMD_USB_MASS_STORAGE=y
> >   CONFIG_CMD_BMP=y
> >   CONFIG_CMD_CACHE=y
> > +CONFIG_CMD_EFIDEBUG=y
> >   CONFIG_CMD_TIME=y
> >   CONFIG_CMD_TIMER=y
> >   CONFIG_CMD_PMIC=y
> > @@ -144,4 +146,5 @@ CONFIG_BMP_32BPP=y
> >   CONFIG_WDT=y
> >   CONFIG_WDT_STM32MP=y
> >   CONFIG_ERRNO_STR=y
> > +# CONFIG_HEXDUMP is not set
> >   CONFIG_FDT_FIXUP_PARTITIONS=y
> 
> 
> I am ok with tha added configs.
> 
> 
> But can you update also the stm32_basic_defconfig:
> 
> for STMicroelectronics boards, we want to have the the same
> 
> configuation between basic and trusted boot chain
> 
> (except SPL or OP-TEE related config).

Yea sure, 

Cheers
/Ilias
> 
> 
> Thanks
> 
> 
> Patrick
> 


Re: [EXT] [PATCH] ARM: imx: Add OCRAM_S into iMX8M MMU tables

2021-02-26 Thread Marek Vasut

On 2/26/21 8:15 AM, Ye Li wrote:

Hi Marek,

On Thu, 2021-02-25 at 21:52 +0100, Marek Vasut wrote:

Caution: EXT Email

The OCRAM_S is regular memory, just like the OCRAM, add it to the MMU
tables so it can be used and cached.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
---
  arch/arm/mach-imx/imx8m/soc.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-
imx/imx8m/soc.c
index 5456c10fb17..225e4e12500 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -104,6 +104,13 @@ static struct mm_region imx8m_mem_map[] = {
 .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
  PTE_BLOCK_NON_SHARE |
  PTE_BLOCK_PXN | PTE_BLOCK_UXN
+   }, {
+   /* OCRAM_S */
+   .virt = 0x18UL,
+   .phys = 0x18UL,
+   .size = 0x8000UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_OUTER_SHARE
 }, {
 /* TCM */
 .virt = 0x7CUL,
--
2.30.0


OCRAM_S is used by ATF and SPL to pass DDR CSR data.


Where is this implemented ?


It is better not
use it in u-boot to avoid any DDR issue.


The MMU table entry does not trigger any IO to the OCRAM_S , it merely 
makes it cacheable .



And this imx8m_mem_map will be modified at runtime to get rid of optee
memory. When OCRAM_S is added, the index used in enable_caches and
dram_init need update as well.


I'm not sure I understand this. What kind of modification are you 
talking about ? The DRAM entry offset should be determined 
automatically, so there shouldn't be any need to hand-tune ad-hoc offsets.


Re: [PATCH] configs: stm32mp1: enable uefi related commands

2021-02-26 Thread Patrick DELAUNAY

Hi Ilias

On 2/25/21 8:37 PM, Ilias Apalodimas wrote:

The board can boot with UEFI. With the latest changes in U-Boot's
EFI subsystem we also have support for EFI runtime variables, without
SetVariable support.  We can also store the EFI variables in a file on the
ESP partition and preserve them across reboots.
The env and efidebug commands are missing in order to configure
EFI variables and the efibootmgr though.  Since U-Boot's default config
enables other EFI related commands (e.g bootefi), let's add the env related
and efidebug commands and allow users to do that

Signed-off-by: Ilias Apalodimas 
---
  configs/stm32mp15_trusted_defconfig | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/configs/stm32mp15_trusted_defconfig 
b/configs/stm32mp15_trusted_defconfig
index da31b74cdeb6..107041119f1d 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -17,6 +17,7 @@ CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
  CONFIG_SYS_PROMPT="STM32MP> "
  CONFIG_CMD_ADTIMG=y
  CONFIG_CMD_ERASEENV=y
+CONFIG_CMD_NVEDIT_EFI=y
  CONFIG_CMD_MEMINFO=y
  CONFIG_CMD_MEMTEST=y
  CONFIG_CMD_ADC=y
@@ -32,6 +33,7 @@ CONFIG_CMD_USB=y
  CONFIG_CMD_USB_MASS_STORAGE=y
  CONFIG_CMD_BMP=y
  CONFIG_CMD_CACHE=y
+CONFIG_CMD_EFIDEBUG=y
  CONFIG_CMD_TIME=y
  CONFIG_CMD_TIMER=y
  CONFIG_CMD_PMIC=y
@@ -144,4 +146,5 @@ CONFIG_BMP_32BPP=y
  CONFIG_WDT=y
  CONFIG_WDT_STM32MP=y
  CONFIG_ERRNO_STR=y
+# CONFIG_HEXDUMP is not set
  CONFIG_FDT_FIXUP_PARTITIONS=y



I am ok with tha added configs.


But can you update also the stm32_basic_defconfig:

for STMicroelectronics boards, we want to have the the same

configuation between basic and trusted boot chain

(except SPL or OP-TEE related config).


Thanks


Patrick



Commit 401d1c4f5d2 ("common: Drop asm/global_data.h from common header") broke CONFIG_CMD_SQUASHFS=y

2021-02-26 Thread Pali Rohár
Hello!

Commit 401d1c4f5d2d29c4bc4beaec95402ca23eb63295 ("common: Drop
asm/global_data.h from common header") broke compilation of
squashfs filesystem when CONFIG_CMD_SQUASHFS=y is enabled.

Here is console output:

fs/squashfs/sqfs_inode.c: In function ‘sqfs_find_inode’:
fs/squashfs/sqfs_inode.c:121:18: warning: implicit declaration of function 
‘le32_to_cpu’ [-Wimplicit-function-declaration]
  for (k = 0; k < le32_to_cpu(inode_count); k++) {
  ^~~
  LD  u-boot
aarch64-linux-gnu-ld.bfd: fs/built-in.o: in function `sqfs_find_inode':
/u-boot/fs/squashfs/sqfs_inode.c:126: undefined reference to `le32_to_cpu'
aarch64-linux-gnu-ld.bfd: /u-boot/fs/squashfs/sqfs_inode.c:121: undefined 
reference to `le32_to_cpu'
Segmentation fault
make: *** [Makefile:1765: u-boot] Error 139
make: *** Deleting file 'u-boot'

When compiling U-Boot prior that commit, there is no error.

Simon and Tom: you have signed problematic mentioned commit. Could you
please look at it?


Re: make O=directory parameter

2021-02-26 Thread Fred 1

On 26/2/21 2:35 am, Tom Rini wrote:

On Thu, Feb 25, 2021 at 12:50:47PM +1100, Fred 1 wrote:


like in the linux kernel build

make O=builds/arm

builds the result to the specified output directory


is this supposed to work for uboot also ?

doesn't seem to work for me, i've fetched older tar files and same problem

maybe my environment?

     fedora32

     5.10.13-100.fc32.x86_64

     GNU Make 4.2.1

the O=  does mostly work on older uboot like from ~2010 though


thought i'd ask as debugging the make process is,well umm...horrible,

(i've inserted some extra debug print codes in gnu make (it self no code to
be praised about!

esp when so much open source depends on it!!)

so atm, a bit of a rabbit holeshould I persist?

Can you provide a sample failure?  The last "make O=... fails" I saw was
because they were passing ARCH= which isn't valid for U-Boot and
specifically breaks if you're say building for an aarch64 platform as in
the linux kernel you would do ARCH=arm64 but it's all "arm" here.
Thanks!


so ok, i'v dropped using the ARCH=
still

All the configs i tried failed:

make O=builds/rpi2  rpi_2_defconfig
make O=builds/rpi2 mrproper   <==tried this too

make O=builds/rpi2 -w -d V=1 CROSS_COMPILE=arm-none-eabi-
qemu_mips_defconfig
orangepi_zero_defconfig

qemu_arm_defconfig


Of course the builds all work just fine without O=, and results in the 
main directory.


So this is not just a problem on my machine?, i guess everyone just uses 
it like so ?


anyway i am sufficiently annoyed with it, i'll have a go at finding out 
why..





Re: [PATCH] mips: mt7628: fix ddr_type for MT7688KN

2021-02-26 Thread Stefan Roese

Hi Weijie,

On 23.02.21 08:12, Weijie Gao wrote:

The MT7688KN is a multi-chip package with 8MiB DDR1 KGD. So the DDR type
from bootstrap register must be ignored, and always be assumed as DDR1.

This patch fixes an issue that mt7628_ddr_pad_ldo_config() may be passed
with a wrong ddr_type in MT7688KN.

Signed-off-by: Weijie Gao 
---
  arch/mips/mach-mtmips/mt7628/ddr.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/mips/mach-mtmips/mt7628/ddr.c 
b/arch/mips/mach-mtmips/mt7628/ddr.c
index b091f2ecff..4e72459906 100644
--- a/arch/mips/mach-mtmips/mt7628/ddr.c
+++ b/arch/mips/mach-mtmips/mt7628/ddr.c
@@ -140,6 +140,9 @@ void mt7628_ddr_init(void)
lspd = readl(sysc + SYSCTL_CLKCFG0_REG) &
   (CPU_PLL_FROM_BBP | CPU_PLL_FROM_XTAL);
  
+	if (pkg_type == PKG_ID_KN)

+   ddr_type = DRAM_DDR1;
+
mt7628_memc_reset(1);
__udelay(200);
  
@@ -152,9 +155,6 @@ void mt7628_ddr_init(void)

param.memsize = 0;
param.bus_width = 0;
  
-	if (pkg_type == PKG_ID_KN)

-   ddr_type = DRAM_DDR1;
-
if (ddr_type == DRAM_DDR1) {
if (lspd)
param.cfgs = ddr1_cfgs_160mhz;



Reviewed-by: Stefan Roese 

Just out of interest. How did you spot this issue?

Thanks,
Stefan


Re: [PATCH u-boot-marvell v2 00/18] Upgrade A38x DDR3 training to version 14.0.0

2021-02-26 Thread Marek Behun
On Fri, 26 Feb 2021 12:13:14 +0100
Stefan Roese  wrote:

> Applied to u-boot-marvell/master
> 
> Only this series for now. If we need some follow-up patches, please
> let me know after this is merged in master.

Very well.


Re: [RFC PATCH] doc: mmc man-page

2021-02-26 Thread Jaehoon Chung
Hi Heinrich,

On 2/26/21 7:32 PM, Heinrich Schuchardt wrote:
> On 2/26/21 11:01 AM, Jaehoon Chung wrote:
>> Provide a man-pages for the mmc command.
>>
>> Signed-off-by: Jaehoon Chung 
>> ---
>>   doc/usage/mmc.rst | 149 ++
> 
> Thanks a lot for providing a man-page for the mmc command.
> 
> You have to change doc/usage/index.rst too.

Thanks for reviewing.

> 
>>   1 file changed, 149 insertions(+)
>>   create mode 100644 doc/usage/mmc.rst
>>
>> diff --git a/doc/usage/mmc.rst b/doc/usage/mmc.rst
>> new file mode 100644
>> index ..30fee447d409
>> --- /dev/null
>> +++ b/doc/usage/mmc.rst
>> @@ -0,0 +1,149 @@
>> +.. SPDX-License-Identifier: GPL-2.0+:
>> +
>> +mmc command
>> +
>> +
>> +Synopsis
>> +
>> +
>> +::
>> +
>> +    mmc info
>> +    mmc read addr blk# cnt
>> +    mmc write addr blk# cnt
>> +    mmc erase blk# cnt
>> +    mmc rescan
>> +    mmc part
>> +    mmc dev [dev] [part]
>> +    mmc list
>> +    mmc wp
>> +    mmc bootbus
>> +    mmc bootpart-resize   
>> +    mmc partconf  [boot_ack boot_partition partition_access]
> 
> This sub-command is missing below.
> 
>> +    mmc rst-function  
>> +
>> +Description
>> +---
>> +
>> +The mmc command is used to control MMC(eMMC/SD) device
> 
> Please, add missing full stops '.'.

Okay.

> 
>> +
>> +The *mmc info* displays information (Manufacturer ID, OEM, Name, Bus Speed, 
>> Mode, ...) of MMC device
>> +
>> +The *mmc read* command reads raw data to memory address from MMC device 
>> with block offset and count
>> +
>> +The *mmc write* write raw data to MMC device from memory address with block 
>> offset and count
>> +    addr - memory address
> 
> Please format arguments like this:
> 
> addr
> memory address
> 
> You can check the formatting using 'make htmldocs'.

Okay. I will check with 'make htmldocs'

> 
>> +
>> +    blk# - start block offset
>> +
>> +    cnt - block count
>> +
>> +The *mmc erase* erases MMC device from block offset until count
>> +    blk# - start block offset
>> +
>> +    cnt - block count
>> +
>> +The *mmc rescan* scans the available MMC device
>> +
>> +The *mmc part* displays the list available partition on current mmc device
>> +
>> +The *mmc dev* show or set current mmc device
>> +    [dev]
> 
> Please, remove the brackets.

Will remove.

> 
>> +    device number to change
>> +    [part]
>> +    partition number to change
>> +
>> +The *mmc list* displays the list avaiable devices
> 
> The *mmc list* command ...
> 
>> +
>> +The *mmc wp* enables "power on write protect" function about boot partitions
> 
> The *mmc wp* command ...
> 
> %s/about/for/

I will update other things according to your comments.

> 
> Please, mention that power cycling is needed to lift the write protection.
> 
>> +
>> +The *mmc bootbus* sets the BOOT_BUS_WIDTH feild
> 
> The *mmc bootbus* command ...
> 
> %s/feild/field/
> 
>> +    BOOTU_BUS_WIDTH[177] is one of EXT_CSD register. (*Refer to eMMC 
>> specification*)
>> +
>> +The *mmc-bootpart-resize* changes sizes of boot and RPMB partition
> 
> partitions.
> 
>> +    dev - device number
>> +
>> +    boot part size MB - Size to change boot partition
> 
> How about:
> 
> target size of boot partition
> 
>> +
>> +    RPMB part size MB - Size to chagne RPMB partition
> 
> %s/chagne/change/
> 
> target size of RPMB partition
> 
>> +
>> +The *mmc rst-function* change the RST_n_FUNCTION filed
> 
> field?
> 
> I think we should describe what a RST_n_FUNCTION is.
> 
> We should enumerate the allowable values. The eMMC specification (JEDEC
> Standard No. 84-B51, 2014) has:
> 
> 0x0: RST_n signal is temporarily disabled (default)
> 0x1: RST_n signal is permanently enabled
> 0x2: RST_n signal is permanently disabled

I thought  that we don't need to describe in more detail and 
user has to read eMMC Specification to understand what a RST_n_FUCTION is.

Because it's dangerous to use without exact understanding.

But I agreed yours..I will add description in more detail.

> 
>> +    **WARNING**: This is a write-once filed. (*Refer to eMMC specification*)
> 
> %s/filed/field/
> 
>> +
>> +Example
>> +---
>> +
>> +The *mmc info* command displays device's capabilities:
>> +::
>> +
>> +    => mmc info
>> +    Device: EXYNOS DWMMC
>> +    Manufacturer ID: 45
>> +    OEM: 100
>> +    Name: SDW16
>> +    Bus Speed: 5200
>> +    Mode: MMC DDR52 (52MHz)
>> +    Rd Block Len: 512
>> +    MMC version 5.0
>> +    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
>> +
>> +The raw data can be read/written via *mmc read/write* command:
>> +::
>> +
>> +    => mmc read 0x4000 0x5000 0x100
>> +    MMC read: dev # 0, block # 20480, count 256 ... 256 

Please pull u-boot-marvell/master

2021-02-26 Thread Stefan Roese

Hi Tom,

please pull the next batch of Marvell MVEBU related patches. Here the
summary log:


- turris_mox: Enhancements, mostlly defconfig changes (Pali)
- pci-aardvark: Set Max Payload Size and Max Read Request Size
to 512 bytes (Pali)
- pci_mvebu: Minor cleanup and refactoring (Marek)
- Upgrade A38x DDR3 training to version 14.0.0 (Marek)


Here the Azure build, without any issues:

https://dev.azure.com/sr0718/u-boot/_build/results?buildId=72=results

Thanks,
Stefan

The following changes since commit c28d5d704d3347fcbe5e49ab561973c00bf9337f:

  Merge branch '2021-02-25-remove-platforms' (2021-02-25 13:18:27 -0500)

are available in the Git repository at:

  g...@gitlab.denx.de:u-boot/custodians/u-boot-marvell.git

for you to fetch changes up to 2f0c18b1584129d8386f5a18390996f6bea78065:

  ddr: marvell: a38x: fix comment in conditional macro (2021-02-26 
10:22:29 +0100)



Alex Leibovich (2):
  ddr: marvell: a38x: add ddr32 support
  ddr: marvell: a38x: add ddr 32bit ECC support

Baruch Siach (1):
  ddr: marvell: a38x: allow board specific ODT configuration

Marek Behún (14):
  arm: mvebu: turris_mox: Enable NVMe support
  pci: pci_mvebu: use dev_seq instead of static variable
  pci: pci_mvebu: cosmetic fix
  pci: pci_mvebu: debug rd/wr config as other drivers do
  pci: pci_mvebu: refactor validation of addresses for config access
  pci: pci_mvebu: set local dev to number 1
  ARM: dts: armada-385-turris-omnia: rename node in -u-boot.dtsi file
  ddr: marvell: a38x: import header change from upstream
  ddr: marvell: a38x: import header change from upstream
  ddr: marvell: a38x: import header change from upstream
  ddr: marvell: a38x: import header change from upstream
  ddr: marvell: a38x: import code change from upstream
  ddr: marvell: a38x: bump version to 14.0.0
  ddr: marvell: a38x: fix comment in conditional macro

Moti Buskila (7):
  ddr: marvell: a38x: fix write leveling suplementary algo
  ddr: marvell: a38x: fix 32bit
  ddr: marvell: a38x: fix memory size calculation using 32bit bus width
  ddr: marvell: a38x: add 16Gbit memory devices support
  ddr: marvell: a38x: add support for twin-die combined memory device
  ddr: marvell: a38x: disable WL phase correction stage in case of 
bus_width=16bit

  ddr: marvell: a38x: fix memory cs size function

Pali Rohár (3):
  arm: a37xx: pci: Set Max Payload Size and Max Read Request Size 
to 512 bytes

  arm: mvebu: turris_mox: Enable CONFIG_PCI_PNP
  arm: mvebu: turris_mox: Enable CONFIG_USB_XHCI_PCI

heaterC (1):
  ddr: marvell: a38x: enum mv_ddr_twin_die: change order

 arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi   |  5 +-
 board/CZ.NIC/turris_omnia/turris_omnia.c   |  2 +
 board/Marvell/db-88f6820-amc/db-88f6820-amc.c  |  1 +
 board/Marvell/db-88f6820-gp/db-88f6820-gp.c|  1 +
 board/alliedtelesis/x530/x530.c|  1 +
 board/gdsys/a38x/controlcenterdc.c |  1 +
 board/kobol/helios4/helios4.c  |  1 +
 board/solidrun/clearfog/clearfog.c |  1 +
 configs/turris_mox_defconfig   |  3 +-
 drivers/ddr/marvell/a38x/ddr3_init.c   |  5 ++
 drivers/ddr/marvell/a38x/ddr3_training.c   |  5 +-
 drivers/ddr/marvell/a38x/ddr3_training_db.c|  3 +
 drivers/ddr/marvell/a38x/ddr3_training_ip_def.h|  2 +
 drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c |  5 +-
 drivers/ddr/marvell/a38x/ddr_topology_def.h| 23 ++-
 drivers/ddr/marvell/a38x/mv_ddr_build_message.c|  2 +-
 drivers/ddr/marvell/a38x/mv_ddr_plat.c |  9 ++-
 drivers/ddr/marvell/a38x/mv_ddr_topology.c | 14 +++-
 drivers/ddr/marvell/a38x/mv_ddr_topology.h |  2 +
 drivers/ddr/marvell/a38x/xor.c |  6 +-
 drivers/pci/pci-aardvark.c |  8 +++
 drivers/pci/pci_mvebu.c| 76 
--

 22 files changed, 123 insertions(+), 53 deletions(-)


  1   2   >