Re: [PATCH 04/18] stm32mp: add the command stm32prog

[Patrice CHOTARD]

Hi

On 3/18/20 9:24 AM, Patrick Delaunay wrote:
> Add a specific command stm32prog for STM32MP soc family
> witch allows to program the boot devices with the tool
> STM32CubeProgrammer (http://www.st.com/STM32CubeProg).
>
> This command uses the same UART STM32 protocol than MCU
> STM32 with or USB with DFU protocol v1.1 (ithe MCU ST
> extension are no supported).
>
> The executed actions are based on a tab separated value file
> with a stm32 header, the FlashLayout file
> (https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer_flashlayout).
>
> This file is parsed by the U-Boot command to:
> - initialize the devices
> - create the partition table on each device
> - initialize the DFU backend to access to not volatile memory
>   (NOR/NAND/SD/eMMC) or to virtual device (OTP/PMIC)
>
> Up to STM32PROG_MAX_DEV (5) devices can be updated with a FlashLayout.
>
> The communication between U-Boot and STM32CubeProgrammer is done with
> the specific alternate configuration (see "AN5275: USB DFU/USART protocols
> used in STM32MP1 Series bootloaders" for details).
>
> The command stm32prog is executed when a boot from USB is detected
> (selected with bootpins) and we can program the boot devices with
> a simple command (on Windows or Linux):
>
> PC $>  STM32_Programmer_CLI -c port=usb1 -w flaslayout.tsv
>
> 1/ the ROM code loads TF-A in embedded RAM (DFU or uart)
> 2/ TF-A loads flashlayout file and U-Boot in DDR (DFU or uart)
> 3/ U-Boot executes the stm32prog command (DFU or uart)
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  arch/arm/mach-stm32mp/Kconfig |  12 +
>  arch/arm/mach-stm32mp/Makefile|   1 +
>  arch/arm/mach-stm32mp/cmd_stm32prog/Makefile  |   8 +
>  .../cmd_stm32prog/cmd_stm32prog.c |  96 
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.c| 480 ++
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.h| 137 +
>  .../cmd_stm32prog/stm32prog_usb.c | 206 
>  .../arm/mach-stm32mp/include/mach/stm32prog.h |  12 +
>  board/st/common/stm32mp_dfu.c |  20 +
>  configs/stm32mp15_basic_defconfig |   3 +-
>  configs/stm32mp15_trusted_defconfig   |   3 +-
>  11 files changed, 974 insertions(+), 4 deletions(-)
>  create mode 100644 arch/arm/mach-stm32mp/cmd_stm32prog/Makefile
>  create mode 100644 arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
>  create mode 100644 arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
>  create mode 100644 arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
>  create mode 100644 arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_usb.c
>  create mode 100644 arch/arm/mach-stm32mp/include/mach/stm32prog.h
>
> diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
> index 1a5545b98d..61466f6125 100644
> --- a/arch/arm/mach-stm32mp/Kconfig
> +++ b/arch/arm/mach-stm32mp/Kconfig
> @@ -114,6 +114,18 @@ config STM32_ETZPC
>   help
> Say y to enable STM32 Extended TrustZone Protection
>  
> +config CMD_STM32PROG
> + bool "command stm32prog for STM32CudeProgrammer"
> + select DFU
> + select DFU_RAM
> + select DFU_VIRT
> + help
> + activate a specific command stm32prog for STM32MP soc family
> + witch update the device with the tools STM32CubeProgrammer,
> + using UART with STM32 protocol or USB with DFU protocol
> + NB: access to not volatile memory (NOR/NAND/SD/eMMC) is based
> + on U-Boot DFU framework
> +
>  config CMD_STM32KEY
>   bool "command stm32key to fuse public key hash"
>   default y
> diff --git a/arch/arm/mach-stm32mp/Makefile b/arch/arm/mach-stm32mp/Makefile
> index 19ca3b08a5..c6ab3cecf0 100644
> --- a/arch/arm/mach-stm32mp/Makefile
> +++ b/arch/arm/mach-stm32mp/Makefile
> @@ -10,6 +10,7 @@ obj-y += syscon.o
>  ifdef CONFIG_SPL_BUILD
>  obj-y += spl.o
>  else
> +obj-$(CONFIG_CMD_STM32PROG) += cmd_stm32prog/
>  obj-y += bsec.o
>  obj-$(CONFIG_CMD_STM32KEY) += cmd_stm32key.o
>  obj-$(CONFIG_ARMV7_PSCI) += psci.o
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/Makefile 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/Makefile
> new file mode 100644
> index 00..14f722759c
> --- /dev/null
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/Makefile
> @@ -0,0 +1,8 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (C) 2020, STMicroelectronics - All Rights Reserved
> +#
> +
> +obj-y += cmd_stm32prog.o
> +obj-y += stm32prog.o
> +obj-y += stm32prog_usb.o
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> new file mode 100644
> index 00..3e8b426444
> --- /dev/null
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> @@ -0,0 +1,96 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> +/*
> + * Copyright (C) 2020, STMicroelectronics - All Rights Reserved
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include "stm32prog.h"
> +
> +struct stm32prog_data *s

Re: [PATCH 05/18] stm32mp: stm32prog: add flash layout parsing

[Patrice CHOTARD]

Hi

On 3/18/20 9:24 AM, Patrick Delaunay wrote:
> Build the list of device and of partition with
> a tab separated value file with a stm32 header: the FlashLayout.tsv
> (https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer_flashlayout)
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.c| 372 +-
>  1 file changed, 371 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> index e2c6c43d88..11fe479072 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> @@ -24,6 +24,17 @@
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> +/* order of column in flash layout file */
> +enum stm32prog_col_t {
> + COL_OPTION,
> + COL_ID,
> + COL_NAME,
> + COL_TYPE,
> + COL_IP,
> + COL_OFFSET,
> + COL_NB_STM32
> +};
> +
>  char *stm32prog_get_error(struct stm32prog_data *data)
>  {
>   static const char error_msg[] = "Unspecified";
> @@ -34,11 +45,370 @@ char *stm32prog_get_error(struct stm32prog_data *data)
>   return data->error;
>  }
>  
> +u8 stm32prog_header_check(struct raw_header_s *raw_header,
> +   struct image_header_s *header)
> +{
> + unsigned int i;
> +
> + header->present = 0;
> + header->image_checksum = 0x0;
> + header->image_length = 0x0;
> +
> + if (!raw_header || !header) {
> + pr_debug("%s:no header data\n", __func__);
> + return -1;
> + }
> + if (raw_header->magic_number !=
> + (('S' << 0) | ('T' << 8) | ('M' << 16) | (0x32 << 24))) {
> + pr_debug("%s:invalid magic number : 0x%x\n",
> +  __func__, raw_header->magic_number);
> + return -2;
> + }
> + /* only header v1.0 supported */
> + if (raw_header->header_version != 0x0001) {
> + pr_debug("%s:invalid header version : 0x%x\n",
> +  __func__, raw_header->header_version);
> + return -3;
> + }
> + if (raw_header->reserved1 != 0x0 || raw_header->reserved2) {
> + pr_debug("%s:invalid reserved field\n", __func__);
> + return -4;
> + }
> + for (i = 0; i < (sizeof(raw_header->padding) / 4); i++) {
> + if (raw_header->padding[i] != 0) {
> + pr_debug("%s:invalid padding field\n", __func__);
> + return -5;
> + }
> + }
> + header->present = 1;
> + header->image_checksum = le32_to_cpu(raw_header->image_checksum);
> + header->image_length = le32_to_cpu(raw_header->image_length);
> +
> + return 0;
> +}
> +
> +static u32 stm32prog_header_checksum(u32 addr, struct image_header_s *header)
> +{
> + u32 i, checksum;
> + u8 *payload;
> +
> + /* compute checksum on payload */
> + payload = (u8 *)addr;
> + checksum = 0;
> + for (i = header->image_length; i > 0; i--)
> + checksum += *(payload++);
> +
> + return checksum;
> +}
> +
> +/* FLASHLAYOUT PARSING */
> +static int parse_option(struct stm32prog_data *data,
> + int i, char *p, struct stm32prog_part_t *part)
> +{
> + int result = 0;
> + char *c = p;
> +
> + part->option = 0;
> + if (!strcmp(p, "-"))
> + return 0;
> +
> + while (*c) {
> + switch (*c) {
> + case 'P':
> + part->option |= OPT_SELECT;
> + break;
> + case 'E':
> + part->option |= OPT_EMPTY;
> + break;
> + default:
> + result = -EINVAL;
> + stm32prog_err("Layout line %d: invalid option '%c' in 
> %s)",
> +   i, *c, p);
> + return -EINVAL;
> + }
> + c++;
> + }
> + if (!(part->option & OPT_SELECT)) {
> + stm32prog_err("Layout line %d: missing 'P' in option %s", i, p);
> + return -EINVAL;
> + }
> +
> + return result;
> +}
> +
> +static int parse_id(struct stm32prog_data *data,
> + int i, char *p, struct stm32prog_part_t *part)
> +{
> + int result = 0;
> + unsigned long value;
> +
> + result = strict_strtoul(p, 0, &value);
> + part->id = value;
> + if (result || value > PHASE_LAST_USER) {
> + stm32prog_err("Layout line %d: invalid phase value = %s", i, p);
> + result = -EINVAL;
> + }
> +
> + return result;
> +}
> +
> +static int parse_name(struct stm32prog_data *data,
> +   int i, char *p, struct stm32prog_part_t *part)
> +{
> + int result = 0;
> +
> + if (strlen(p) < sizeof(part->name)) {
> + strcpy(part->name, p);
> + } else {
> + stm32prog_err("Layout line %d: partition name too long [%d]: 
> %s

Re: [PATCH 06/18] stm32mp: stm32prog: add MMC device

[Patrice CHOTARD]

Hi

On 3/18/20 9:24 AM, Patrick Delaunay wrote:
> Add support of MMC device (based on DFU_MMC backend)
> for SD card and eMMC update.
>
> Create a GPT partitioning on the device.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  arch/arm/mach-stm32mp/Kconfig |   3 +
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.c| 204 +-
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.h|   3 +
>  configs/stm32mp15_basic_defconfig |   2 -
>  configs/stm32mp15_trusted_defconfig   |   2 -
>  5 files changed, 209 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
> index 61466f6125..39504e8540 100644
> --- a/arch/arm/mach-stm32mp/Kconfig
> +++ b/arch/arm/mach-stm32mp/Kconfig
> @@ -119,6 +119,9 @@ config CMD_STM32PROG
>   select DFU
>   select DFU_RAM
>   select DFU_VIRT
> + select PARTITION_TYPE_GUID
> + imply CMD_GPT if MMC
> + imply DFU_MMC if MMC
>   help
>   activate a specific command stm32prog for STM32MP soc family
>   witch update the device with the tools STM32CubeProgrammer,
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> index 11fe479072..feb83670b5 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> @@ -7,6 +7,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -14,6 +15,9 @@
>  
>  #include "stm32prog.h"
>  
> +/* Primary GPT header size for 128 entries : 17kB = 34 LBA of 512B */
> +#define GPT_HEADER_SZ34
> +
>  #define OPT_SELECT   BIT(0)
>  #define OPT_EMPTYBIT(1)
>  
> @@ -22,6 +26,32 @@
>  
>  #define ALT_BUF_LEN  SZ_1K
>  
> +#define ROOTFS_MMC0_UUID \
> + EFI_GUID(0xE91C4E10, 0x16E6, 0x4C0E, \
> +  0xBD, 0x0E, 0x77, 0xBE, 0xCF, 0x4A, 0x35, 0x82)
> +
> +#define ROOTFS_MMC1_UUID \
> + EFI_GUID(0x491F6117, 0x415D, 0x4F53, \
> +  0x88, 0xC9, 0x6E, 0x0D, 0xE5, 0x4D, 0xEA, 0xC6)
> +
> +#define ROOTFS_MMC2_UUID \
> + EFI_GUID(0xFD58F1C7, 0xBE0D, 0x4338, \
> +  0x88, 0xE9, 0xAD, 0x8F, 0x05, 0x0A, 0xEB, 0x18)
> +
> +/* RAW parttion (binary / bootloader) used Linux - reserved UUID */
> +#define LINUX_RESERVED_UUID "8DA63339-0007-60C0-C436-083AC8230908"
> +
> +/*
> + * unique partition guid (uuid) for partition named "rootfs"
> + * on each MMC instance = SD Card or eMMC
> + * allow fixed kernel bootcmd: "rootf=PARTUID=e91c4e10-..."
> + */
> +static const efi_guid_t uuid_mmc[3] = {
> + ROOTFS_MMC0_UUID,
> + ROOTFS_MMC1_UUID,
> + ROOTFS_MMC2_UUID
> +};
> +
>  DECLARE_GLOBAL_DATA_PTR;
>  
>  /* order of column in flash layout file */
> @@ -200,6 +230,9 @@ static int parse_ip(struct stm32prog_data *data,
>   part->dev_id = 0;
>   if (!strcmp(p, "none")) {
>   part->target = STM32PROG_NONE;
> + } else if (!strncmp(p, "mmc", 3)) {
> + part->target = STM32PROG_MMC;
> + len = 3;
>   } else {
>   result = -EINVAL;
>   }
> @@ -424,16 +457,50 @@ static int __init part_cmp(void *priv, struct list_head 
> *a, struct list_head *b)
>  static int init_device(struct stm32prog_data *data,
>  struct stm32prog_dev_t *dev)
>  {
> + struct mmc *mmc = NULL;
>   struct blk_desc *block_dev = NULL;
>   int part_id;
>   u64 first_addr = 0, last_addr = 0;
>   struct stm32prog_part_t *part, *next_part;
>  
>   switch (dev->target) {
> +#ifdef CONFIG_MMC
> + case STM32PROG_MMC:
> + mmc = find_mmc_device(dev->dev_id);
> + if (mmc_init(mmc)) {
> + stm32prog_err("mmc device %d not found", dev->dev_id);
> + return -ENODEV;
> + }
> + block_dev = mmc_get_blk_desc(mmc);
> + if (!block_dev) {
> + stm32prog_err("mmc device %d not probed", dev->dev_id);
> + return -ENODEV;
> + }
> + dev->erase_size = mmc->erase_grp_size * block_dev->blksz;
> + dev->mmc = mmc;
> +
> + /* reserve a full erase group for each GTP headers */
> + if (mmc->erase_grp_size > GPT_HEADER_SZ) {
> + first_addr = dev->erase_size;
> + last_addr = (u64)(block_dev->lba -
> +   mmc->erase_grp_size) *
> + block_dev->blksz;
> + } else {
> + first_addr = (u64)GPT_HEADER_SZ * block_dev->blksz;
> + last_addr = (u64)(block_dev->lba - GPT_HEADER_SZ - 1) *
> + block_dev->blksz;
> + }
> + pr_debug("MMC %d: lba=%ld blksz=%ld\n", dev->dev_id,
> +  block_dev->lba, block_dev->blksz);
> + pr_debug(" available address = 0x%

Re: [PATCH 06/18] stm32mp: stm32prog: add MMC device

[Patrice CHOTARD]

Hi

On 3/18/20 9:24 AM, Patrick Delaunay wrote:
> Add support of MMC device (based on DFU_MMC backend)
> for SD card and eMMC update.
>
> Create a GPT partitioning on the device.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  arch/arm/mach-stm32mp/Kconfig |   3 +
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.c| 204 +-
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.h|   3 +
>  configs/stm32mp15_basic_defconfig |   2 -
>  configs/stm32mp15_trusted_defconfig   |   2 -
>  5 files changed, 209 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
> index 61466f6125..39504e8540 100644
> --- a/arch/arm/mach-stm32mp/Kconfig
> +++ b/arch/arm/mach-stm32mp/Kconfig
> @@ -119,6 +119,9 @@ config CMD_STM32PROG
>   select DFU
>   select DFU_RAM
>   select DFU_VIRT
> + select PARTITION_TYPE_GUID
> + imply CMD_GPT if MMC
> + imply DFU_MMC if MMC
>   help
>   activate a specific command stm32prog for STM32MP soc family
>   witch update the device with the tools STM32CubeProgrammer,
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> index 11fe479072..feb83670b5 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> @@ -7,6 +7,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -14,6 +15,9 @@
>  
>  #include "stm32prog.h"
>  
> +/* Primary GPT header size for 128 entries : 17kB = 34 LBA of 512B */
> +#define GPT_HEADER_SZ34
> +
>  #define OPT_SELECT   BIT(0)
>  #define OPT_EMPTYBIT(1)
>  
> @@ -22,6 +26,32 @@
>  
>  #define ALT_BUF_LEN  SZ_1K
>  
> +#define ROOTFS_MMC0_UUID \
> + EFI_GUID(0xE91C4E10, 0x16E6, 0x4C0E, \
> +  0xBD, 0x0E, 0x77, 0xBE, 0xCF, 0x4A, 0x35, 0x82)
> +
> +#define ROOTFS_MMC1_UUID \
> + EFI_GUID(0x491F6117, 0x415D, 0x4F53, \
> +  0x88, 0xC9, 0x6E, 0x0D, 0xE5, 0x4D, 0xEA, 0xC6)
> +
> +#define ROOTFS_MMC2_UUID \
> + EFI_GUID(0xFD58F1C7, 0xBE0D, 0x4338, \
> +  0x88, 0xE9, 0xAD, 0x8F, 0x05, 0x0A, 0xEB, 0x18)
> +
> +/* RAW parttion (binary / bootloader) used Linux - reserved UUID */
> +#define LINUX_RESERVED_UUID "8DA63339-0007-60C0-C436-083AC8230908"
> +
> +/*
> + * unique partition guid (uuid) for partition named "rootfs"
> + * on each MMC instance = SD Card or eMMC
> + * allow fixed kernel bootcmd: "rootf=PARTUID=e91c4e10-..."
> + */
> +static const efi_guid_t uuid_mmc[3] = {
> + ROOTFS_MMC0_UUID,
> + ROOTFS_MMC1_UUID,
> + ROOTFS_MMC2_UUID
> +};
> +
>  DECLARE_GLOBAL_DATA_PTR;
>  
>  /* order of column in flash layout file */
> @@ -200,6 +230,9 @@ static int parse_ip(struct stm32prog_data *data,
>   part->dev_id = 0;
>   if (!strcmp(p, "none")) {
>   part->target = STM32PROG_NONE;
> + } else if (!strncmp(p, "mmc", 3)) {
> + part->target = STM32PROG_MMC;
> + len = 3;
>   } else {
>   result = -EINVAL;
>   }
> @@ -424,16 +457,50 @@ static int __init part_cmp(void *priv, struct list_head 
> *a, struct list_head *b)
>  static int init_device(struct stm32prog_data *data,
>  struct stm32prog_dev_t *dev)
>  {
> + struct mmc *mmc = NULL;
>   struct blk_desc *block_dev = NULL;
>   int part_id;
>   u64 first_addr = 0, last_addr = 0;
>   struct stm32prog_part_t *part, *next_part;
>  
>   switch (dev->target) {
> +#ifdef CONFIG_MMC
> + case STM32PROG_MMC:
> + mmc = find_mmc_device(dev->dev_id);
> + if (mmc_init(mmc)) {
> + stm32prog_err("mmc device %d not found", dev->dev_id);
> + return -ENODEV;
> + }
> + block_dev = mmc_get_blk_desc(mmc);
> + if (!block_dev) {
> + stm32prog_err("mmc device %d not probed", dev->dev_id);
> + return -ENODEV;
> + }
> + dev->erase_size = mmc->erase_grp_size * block_dev->blksz;
> + dev->mmc = mmc;
> +
> + /* reserve a full erase group for each GTP headers */
> + if (mmc->erase_grp_size > GPT_HEADER_SZ) {
> + first_addr = dev->erase_size;
> + last_addr = (u64)(block_dev->lba -
> +   mmc->erase_grp_size) *
> + block_dev->blksz;
> + } else {
> + first_addr = (u64)GPT_HEADER_SZ * block_dev->blksz;
> + last_addr = (u64)(block_dev->lba - GPT_HEADER_SZ - 1) *
> + block_dev->blksz;
> + }
> + pr_debug("MMC %d: lba=%ld blksz=%ld\n", dev->dev_id,
> +  block_dev->lba, block_dev->blksz);
> + pr_debug(" available address = 0x%

Re: [PATCH 07/18] stm32mp: stm32prog: add support of boot partition for eMMC device

[Patrice CHOTARD]

Hi

On 3/18/20 9:24 AM, Patrick Delaunay wrote:
> Add support of eMMC device boot partition with
> part_id = -1 for offset="boot1"
>  or = -2 for offset="boot2"
>
> The stm32prog command configures the MMC DFU backend with "mmcpart"
> and configure the eMMC (command "mmc bootbus" and "mmc partconf")
> when the update is done.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.c| 124 +-
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.h|   2 +-
>  2 files changed, 90 insertions(+), 36 deletions(-)
>
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> index feb83670b5..f63036606e 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> @@ -259,12 +259,30 @@ static int parse_offset(struct stm32prog_data *data,
>   char *tail;
>  
>   part->part_id = 0;
> + part->addr = 0;
>   part->size = 0;
> - part->addr = simple_strtoull(p, &tail, 0);
> - if (tail == p || *tail != '\0') {
> - stm32prog_err("Layout line %d: invalid offset '%s'",
> -   i, p);
> - result = -EINVAL;
> + /* eMMC boot parttion */
> + if (!strncmp(p, "boot", 4)) {
> + if (strlen(p) != 5) {
> + result = -EINVAL;
> + } else {
> + if (p[4] == '1')
> + part->part_id = -1;
> + else if (p[4] == '2')
> + part->part_id = -2;
> + else
> + result = -EINVAL;
> + }
> + if (result)
> + stm32prog_err("Layout line %d: invalid part '%s'",
> +   i, p);
> + } else {
> + part->addr = simple_strtoull(p, &tail, 0);
> + if (tail == p || *tail != '\0') {
> + stm32prog_err("Layout line %d: invalid offset '%s'",
> +   i, p);
> + result = -EINVAL;
> + }
>   }
>  
>   return result;
> @@ -451,7 +469,10 @@ static int __init part_cmp(void *priv, struct list_head 
> *a, struct list_head *b)
>   parta = container_of(a, struct stm32prog_part_t, list);
>   partb = container_of(b, struct stm32prog_part_t, list);
>  
> - return parta->addr > partb->addr ? 1 : -1;
> + if (parta->part_id != partb->part_id)
> + return parta->part_id - partb->part_id;
> + else
> + return parta->addr > partb->addr ? 1 : -1;
>  }
>  
>  static int init_device(struct stm32prog_data *data,
> @@ -520,44 +541,53 @@ static int init_device(struct stm32prog_data *data,
>part->dev_id, part->addr, part->size);
>   continue;
>   }
> -
> - part->part_id = part_id++;
> -
> - /* last partition : size to the end of the device */
> - if (part->list.next != &dev->part_list) {
> - next_part =
> - container_of(part->list.next,
> -  struct stm32prog_part_t,
> -  list);
> - if (part->addr < next_part->addr) {
> - part->size = next_part->addr -
> -  part->addr;
> + if (part->part_id < 0) { /* boot hw partition for eMMC */
> + if (mmc) {
> + part->size = mmc->capacity_boot;
>   } else {
> - stm32prog_err("%s (0x%x): same address : 0x%llx 
> == %s (0x%x): 0x%llx",
> + stm32prog_err("%s (0x%x): hw partition not 
> expected : %d",
> part->name, part->id,
> -   part->addr,
> -   next_part->name,
> -   next_part->id,
> -   next_part->addr);
> - return -EINVAL;
> +   part->part_id);
> + return -ENODEV;
>   }
>   } else {
> - if (part->addr <= last_addr) {
> - part->size = last_addr - part->addr;
> + part->part_id = part_id++;
> +
> + /* last partition : size to the end of the device */
> + if (part->list.next != &dev->part_list) {
> + next_part =
> + container_of(part->list.next,
> +  struct stm32prog_part_t,
> + 

Re: [PATCH 08/18] stm32mp: stm32prog: add upport of partial update

[Patrice CHOTARD]

Hi

On 3/18/20 9:24 AM, Patrick Delaunay wrote:
> Add support of partial update, update only some partitions,
> and check the coherence of the layout with the existing GPT
> partitions (offset and size).
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.c| 69 +++
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.h|  1 +
>  2 files changed, 70 insertions(+)
>
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> index f63036606e..787bcdef7d 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> @@ -481,8 +481,12 @@ static int init_device(struct stm32prog_data *data,
>   struct mmc *mmc = NULL;
>   struct blk_desc *block_dev = NULL;
>   int part_id;
> + int ret;
>   u64 first_addr = 0, last_addr = 0;
>   struct stm32prog_part_t *part, *next_part;
> + u64 part_addr, part_size;
> + bool part_found;
> + const char *part_name;
>  
>   switch (dev->target) {
>  #ifdef CONFIG_MMC
> @@ -515,6 +519,7 @@ static int init_device(struct stm32prog_data *data,
>block_dev->lba, block_dev->blksz);
>   pr_debug(" available address = 0x%llx..0x%llx\n",
>first_addr, last_addr);
> + pr_debug(" full_update = %d\n", dev->full_update);
>   break;
>  #endif
>   default:
> @@ -522,6 +527,7 @@ static int init_device(struct stm32prog_data *data,
>   return -ENODEV;
>   }
>   pr_debug(" erase size = 0x%x\n", dev->erase_size);
> + pr_debug(" full_update = %d\n", dev->full_update);
>  
>   /* order partition list in offset order */
>   list_sort(NULL, &dev->part_list, &part_cmp);
> @@ -598,6 +604,61 @@ static int init_device(struct stm32prog_data *data,
>part->part_id, part->option, part->id, part->name,
>part->part_type, part->target,
>part->dev_id, part->addr, part->size);
> +
> + part_addr = 0;
> + part_size = 0;
> + part_found = false;
> +
> + /* check coherency with existing partition */
> + if (block_dev) {
> + /*
> +  * block devices with GPT: check user partition size
> +  * only for partial update, the GPT partions are be
> +  * created for full update
> +  */
> + if (dev->full_update || part->part_id < 0) {
> + pr_debug("\n");
> + continue;
> + }
> + disk_partition_t partinfo;
> +
> + ret = part_get_info(block_dev, part->part_id,
> + &partinfo);
> +
> + if (ret) {
> + stm32prog_err("%s (0x%x):Couldn't find part %d 
> on device mmc %d",
> +   part->name, part->id,
> +   part_id, part->dev_id);
> + return -ENODEV;
> + }
> + part_addr = (u64)partinfo.start * partinfo.blksz;
> + part_size = (u64)partinfo.size * partinfo.blksz;
> + part_name = (char *)partinfo.name;
> + part_found = true;
> + }
> +
> + if (!part_found) {
> + stm32prog_err("%s (0x%x): Invalid partition",
> +   part->name, part->id);
> + pr_debug("\n");
> + continue;
> + }
> +
> + pr_debug(" %08llx %08llx\n", part_addr, part_size);
> +
> + if (part->addr != part_addr) {
> + stm32prog_err("%s (0x%x): Bad address for partition %d 
> (%s) = 0x%llx <> 0x%llx expected",
> +   part->name, part->id, part->part_id,
> +   part_name, part->addr, part_addr);
> + return -ENODEV;
> + }
> + if (part->size != part_size) {
> + stm32prog_err("%s (0x%x): Bad size for partition %d 
> (%s) at 0x%llx = 0x%llx <> 0x%llx expected",
> +   part->name, part->id, part->part_id,
> +   part_name, part->addr, part->size,
> +   part_size);
> + return -ENODEV;
> + }
>   }
>   return 0;
>  }
> @@ -644,6 +705,7 @@ static int treat_partition_list(struct stm32prog_data 
> *data)
>   /* new device found */
>   data->dev[j].target = part->target;
>   data->dev[j].dev_id = part->dev_id;
> +   

Re: [PATCH 10/18] stm32mp: stm32prog: adapt the MTD partitions

[Patrice CHOTARD]

Hi

On 3/18/20 9:24 AM, Patrick Delaunay wrote:
> Dynamically adapt the MTD partitions in NOR/NAND/SPI-NAND when stm32prog
> command detects in the parsed flash layout files:
> - a fsbl partition in NOR.
> - a tee partition in NOR/NAND/SPI-NAND
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  .../mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c  | 17 +
>  arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c | 17 +
>  arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h |  2 ++
>  arch/arm/mach-stm32mp/include/mach/stm32prog.h  |  4 
>  board/st/common/stm32mp_mtdparts.c  | 14 --
>  5 files changed, 52 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> index 3e8b426444..581f97e0b5 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "stm32prog.h"
>  
>  struct stm32prog_data *stm32prog_data;
> @@ -94,3 +95,19 @@ U_BOOT_CMD(stm32prog, 5, 0, do_stm32prog,
>  " = address of flashlayout\n"
>  " = size of flashlayout\n"
>  );
> +
> +bool stm32prog_get_tee_partitions(void)
> +{
> + if (stm32prog_data)
> + return stm32prog_data->tee_detected;
> +
> + return false;
> +}
> +
> +bool stm32prog_get_fsbl_nor(void)
> +{
> + if (stm32prog_data)
> + return stm32prog_data->fsbl_nor_detected;
> +
> + return false;
> +}
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> index 93ee6a55a1..0140fd479d 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> @@ -762,6 +762,8 @@ static int treat_partition_list(struct stm32prog_data 
> *data)
>   INIT_LIST_HEAD(&data->dev[j].part_list);
>   }
>  
> + data->tee_detected = false;
> + data->fsbl_nor_detected = false;
>   for (i = 0; i < data->part_nb; i++) {
>   part = &data->part_array[i];
>   part->alt_id = -1;
> @@ -806,6 +808,21 @@ static int treat_partition_list(struct stm32prog_data 
> *data)
>   stm32prog_err("Layout: too many device");
>   return -EINVAL;
>   }
> + switch (part->target)  {
> + case STM32PROG_NOR:
> + if (!data->fsbl_nor_detected &&
> + !strncmp(part->name, "fsbl", 4))
> + data->fsbl_nor_detected = true;
> + /* fallthrough */
> + case STM32PROG_NAND:
> + case STM32PROG_SPI_NAND:
> + if (!data->tee_detected &&
> + !strncmp(part->name, "tee", 3))
> + data->tee_detected = true;
> + break;
> + default:
> + break;
> + }
>   part->dev = &data->dev[j];
>   if (!IS_SELECT(part))
>   part->dev->full_update = false;
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
> index 8e635da3a4..7f06627ebc 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
> @@ -107,6 +107,8 @@ struct stm32prog_data {
>   struct stm32prog_dev_t  dev[STM32PROG_MAX_DEV]; /* array of device */
>   int part_nb;/* nb of partition */
>   struct stm32prog_part_t *part_array;/* array of partition */
> + booltee_detected;
> + boolfsbl_nor_detected;
>  
>   /* command internal information */
>   unsigned intphase;
> diff --git a/arch/arm/mach-stm32mp/include/mach/stm32prog.h 
> b/arch/arm/mach-stm32mp/include/mach/stm32prog.h
> index c10bff09c8..c080b9cc42 100644
> --- a/arch/arm/mach-stm32mp/include/mach/stm32prog.h
> +++ b/arch/arm/mach-stm32mp/include/mach/stm32prog.h
> @@ -10,3 +10,7 @@ int stm32prog_write_medium_virt(struct dfu_entity *dfu, u64 
> offset,
>  int stm32prog_read_medium_virt(struct dfu_entity *dfu, u64 offset,
>  void *buf, long *len);
>  int stm32prog_get_medium_size_virt(struct dfu_entity *dfu, u64 *size);
> +
> +bool stm32prog_get_tee_partitions(void);
> +
> +bool stm32prog_get_fsbl_nor(void);
> diff --git a/board/st/common/stm32mp_mtdparts.c 
> b/board/st/common/stm32mp_mtdparts.c
> index 5028511077..9f5897f8c8 100644
> --- a/board/st/common/stm32mp_mtdparts.c
> +++ b/board/st/common/stm32mp_mtdparts.c
> @@ -4,12 +4,14 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #define MTDPARTS_LEN 256
> @@ -66,7 +68,7 

Re: [PATCH 09/18] stm32mp: stm32prog: add MTD devices support

[Patrice CHOTARD]

Hi

On 3/18/20 9:24 AM, Patrick Delaunay wrote:
> Add support of MTD device (DFU_MTD backend) for
> NOR, NAND or SPI-NAND target.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  arch/arm/mach-stm32mp/Kconfig |   2 +
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.c| 114 +-
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.h|   4 +
>  configs/stm32mp15_basic_defconfig |   2 -
>  configs/stm32mp15_trusted_defconfig   |   2 -
>  5 files changed, 117 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
> index 39504e8540..af16393152 100644
> --- a/arch/arm/mach-stm32mp/Kconfig
> +++ b/arch/arm/mach-stm32mp/Kconfig
> @@ -121,7 +121,9 @@ config CMD_STM32PROG
>   select DFU_VIRT
>   select PARTITION_TYPE_GUID
>   imply CMD_GPT if MMC
> + imply CMD_MTD if MTD
>   imply DFU_MMC if MMC
> + imply DFU_MTD if MTD
>   help
>   activate a specific command stm32prog for STM32MP soc family
>   witch update the device with the tools STM32CubeProgrammer,
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> index 787bcdef7d..93ee6a55a1 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> @@ -8,9 +8,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "stm32prog.h"
> @@ -65,6 +68,11 @@ enum stm32prog_col_t {
>   COL_NB_STM32
>  };
>  
> +/* partition handling routines : CONFIG_CMD_MTDPARTS */
> +int mtdparts_init(void);
> +int find_dev_and_part(const char *id, struct mtd_device **dev,
> +   u8 *part_num, struct part_info **part);
> +
>  char *stm32prog_get_error(struct stm32prog_data *data)
>  {
>   static const char error_msg[] = "Unspecified";
> @@ -233,6 +241,15 @@ static int parse_ip(struct stm32prog_data *data,
>   } else if (!strncmp(p, "mmc", 3)) {
>   part->target = STM32PROG_MMC;
>   len = 3;
> + } else if (!strncmp(p, "nor", 3)) {
> + part->target = STM32PROG_NOR;
> + len = 3;
> + } else if (!strncmp(p, "nand", 4)) {
> + part->target = STM32PROG_NAND;
> + len = 4;
> + } else if (!strncmp(p, "spi-nand", 8)) {
> + part->target = STM32PROG_SPI_NAND;
> + len = 8;
>   } else {
>   result = -EINVAL;
>   }
> @@ -475,11 +492,37 @@ static int __init part_cmp(void *priv, struct list_head 
> *a, struct list_head *b)
>   return parta->addr > partb->addr ? 1 : -1;
>  }
>  
> +static void get_mtd_by_target(char *string, enum stm32prog_target target,
> +   int dev_id)
> +{
> + const char *dev_str;
> +
> + switch (target) {
> + case STM32PROG_NOR:
> + dev_str = "nor";
> + break;
> + case STM32PROG_NAND:
> + dev_str = "nand";
> + break;
> + case STM32PROG_SPI_NAND:
> + dev_str = "spi-nand";
> + break;
> + default:
> + dev_str = "invalid";
> + break;
> + }
> + sprintf(string, "%s%d", dev_str, dev_id);
> +}
> +
>  static int init_device(struct stm32prog_data *data,
>  struct stm32prog_dev_t *dev)
>  {
>   struct mmc *mmc = NULL;
>   struct blk_desc *block_dev = NULL;
> +#ifdef CONFIG_MTD
> + struct mtd_info *mtd = NULL;
> + char mtd_id[16];
> +#endif
>   int part_id;
>   int ret;
>   u64 first_addr = 0, last_addr = 0;
> @@ -521,6 +564,29 @@ static int init_device(struct stm32prog_data *data,
>first_addr, last_addr);
>   pr_debug(" full_update = %d\n", dev->full_update);
>   break;
> +#endif
> +#ifdef CONFIG_MTD
> + case STM32PROG_NOR:
> + case STM32PROG_NAND:
> + case STM32PROG_SPI_NAND:
> + get_mtd_by_target(mtd_id, dev->target, dev->dev_id);
> + pr_debug("%s\n", mtd_id);
> +
> + mtdparts_init();
> + mtd = get_mtd_device_nm(mtd_id);
> + if (IS_ERR(mtd)) {
> + stm32prog_err("MTD device %s not found", mtd_id);
> + return -ENODEV;
> + }
> + first_addr = 0;
> + last_addr = mtd->size;
> + dev->erase_size = mtd->erasesize;
> + pr_debug("MTD device %s: size=%lld erasesize=%d\n",
> +  mtd_id, mtd->size, mtd->erasesize);
> + pr_debug(" available address = 0x%llx..0x%llx\n",
> +  first_addr, last_addr);
> + dev->mtd = mtd;
> + break;
>  #endif
>   default:
>   stm32prog_err("unknown device type = %d", dev->target);
> @@ -637,6 +703,29 @@ static int init_device(struct stm32prog_data *data,
> 

Re: [PATCH 11/18] stm32mp: stm32prog: add support of ssbl copy

[Patrice CHOTARD]

Hi

On 3/18/20 9:24 AM, Patrick Delaunay wrote:
> For reliability of boot from NAND/SPI-NAND (with read-disturb issue)
> the SSBL can be present several time, when it is indicated in the
> flashlayout with "Binary(X)".
> The received binary is copied X times by U-Boot on the target.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.c| 98 ++-
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.h|  1 +
>  2 files changed, 94 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> index 0140fd479d..3e521d42f2 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> @@ -210,9 +210,24 @@ static int parse_type(struct stm32prog_data *data,
> int i, char *p, struct stm32prog_part_t *part)
>  {
>   int result = 0;
> + int len = 0;
>  
> - if (!strcmp(p, "Binary")) {
> + part->bin_nb = 0;
> + if (!strncmp(p, "Binary", 6)) {
>   part->part_type = PART_BINARY;
> +
> + /* search for Binary(X) case */
> + len = strlen(p);
> + part->bin_nb = 1;
> + if (len > 6) {
> + if (len < 8 ||
> + (p[6] != '(') ||
> + (p[len - 1] != ')'))
> + result = -EINVAL;
> + else
> + part->bin_nb =
> + simple_strtoul(&p[7], NULL, 10);
> + }
>   } else if (!strcmp(p, "System")) {
>   part->part_type = PART_SYSTEM;
>   } else if (!strcmp(p, "FileSystem")) {
> @@ -600,6 +615,17 @@ static int init_device(struct stm32prog_data *data,
>   part_id = 1;
>   pr_debug("id : Opt Phase Name target.n dev.n addr size 
> part_off part_size\n");
>   list_for_each_entry(part, &dev->part_list, list) {
> + if (part->bin_nb > 1) {
> + if ((dev->target != STM32PROG_NAND &&
> +  dev->target != STM32PROG_SPI_NAND) ||
> + part->id >= PHASE_FIRST_USER ||
> + strncmp(part->name, "fsbl", 4)) {
> + stm32prog_err("%s (0x%x): multiple binary %d 
> not supported",
> +   part->name, part->id,
> +   part->bin_nb);
> + return -EINVAL;
> + }
> + }
>   if (part->part_type == RAW_IMAGE) {
>   part->part_id = 0x0;
>   part->addr = 0x0;
> @@ -607,9 +633,9 @@ static int init_device(struct stm32prog_data *data,
>   part->size = block_dev->lba * block_dev->blksz;
>   else
>   part->size = last_addr;
> - pr_debug("-- : %1d %02x %14s %02d %02d.%02d %08llx 
> %08llx\n",
> + pr_debug("-- : %1d %02x %14s %02d.%d %02d.%02d %08llx 
> %08llx\n",
>part->option, part->id, part->name,
> -  part->part_type, part->target,
> +  part->part_type, part->bin_nb, part->target,
>part->dev_id, part->addr, part->size);
>   continue;
>   }
> @@ -666,9 +692,9 @@ static int init_device(struct stm32prog_data *data,
> part->dev->erase_size);
>   return -EINVAL;
>   }
> - pr_debug("%02d : %1d %02x %14s %02d %02d.%02d %08llx %08llx",
> + pr_debug("%02d : %1d %02x %14s %02d.%d %02d.%02d %08llx %08llx",
>part->part_id, part->option, part->id, part->name,
> -  part->part_type, part->target,
> +  part->part_type, part->bin_nb, part->target,
>part->dev_id, part->addr, part->size);
>  
>   part_addr = 0;
> @@ -1133,6 +1159,59 @@ static int dfu_init_entities(struct stm32prog_data 
> *data)
>   return ret;
>  }
>  
> +/* copy FSBL on NAND to improve reliability on NAND */
> +static int stm32prog_copy_fsbl(struct stm32prog_part_t *part)
> +{
> + int ret, i;
> + void *fsbl;
> + struct image_header_s header;
> + struct raw_header_s raw_header;
> + struct dfu_entity *dfu;
> + long size, offset;
> +
> + if (part->target != STM32PROG_NAND &&
> + part->target != STM32PROG_SPI_NAND)
> + return -1;
> +
> + dfu = dfu_get_entity(part->alt_id);
> +
> + /* read header */
> + dfu_transaction_cleanup(dfu);
> + size = BL_HEADER_SIZE;
> + ret = dfu->read_medium(dfu, 0, (void *)&raw_header, &size);
> + if (ret)
> + return ret;
> + if (stm32p

Re: [PATCH 12/18] stm32mp: stm32prog: add support for delete option in flashlayout

[Patrice CHOTARD]

Hi

On 3/18/20 9:24 AM, Patrick Delaunay wrote:
> Add support for delete option 'D' in flashlayout for
> full device or for partitions
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.c| 105 ++
>  1 file changed, 105 insertions(+)
>
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> index 3e521d42f2..3573c04d16 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> @@ -23,9 +23,11 @@
>  
>  #define OPT_SELECT   BIT(0)
>  #define OPT_EMPTYBIT(1)
> +#define OPT_DELETE   BIT(2)
>  
>  #define IS_SELECT(part)  ((part)->option & OPT_SELECT)
>  #define IS_EMPTY(part)   ((part)->option & OPT_EMPTY)
> +#define IS_DELETE(part)  ((part)->option & OPT_DELETE)
>  
>  #define ALT_BUF_LEN  SZ_1K
>  
> @@ -158,6 +160,9 @@ static int parse_option(struct stm32prog_data *data,
>   case 'E':
>   part->option |= OPT_EMPTY;
>   break;
> + case 'D':
> + part->option |= OPT_DELETE;
> + break;
>   default:
>   result = -EINVAL;
>   stm32prog_err("Layout line %d: invalid option '%c' in 
> %s)",
> @@ -1293,10 +1298,80 @@ void stm32prog_next_phase(struct stm32prog_data *data)
>   puts("Phase=END\n");
>  }
>  
> +static int part_delete(struct stm32prog_data *data,
> +struct stm32prog_part_t *part)
> +{
> + int ret = 0;
> +#ifdef CONFIG_MMC
> + unsigned long blks, blks_offset, blks_size;
> + struct blk_desc *block_dev = NULL;
> + #endif
> +#ifdef CONFIG_MTD
> + char cmdbuf[40];
> + char devstr[10];
> +#endif
> +
> + printf("Erasing %s ", part->name);
> + switch (part->target) {
> +#ifdef CONFIG_MMC
> + case STM32PROG_MMC:
> + printf("on mmc %d: ", part->dev->dev_id);
> + block_dev = mmc_get_blk_desc(part->dev->mmc);
> + blks_offset = lldiv(part->addr, part->dev->mmc->read_bl_len);
> + blks_size = lldiv(part->size, part->dev->mmc->read_bl_len);
> + /* -1 or -2 : delete boot partition of MMC
> +  * need to switch to associated hwpart 1 or 2
> +  */
> + if (part->part_id < 0)
> + if (blk_select_hwpart_devnum(IF_TYPE_MMC,
> +  part->dev->dev_id,
> +  -part->part_id))
> + return -1;
> +
> + blks = blk_derase(block_dev, blks_offset, blks_size);
> +
> + /* return to user partition */
> + if (part->part_id < 0)
> + blk_select_hwpart_devnum(IF_TYPE_MMC,
> +  part->dev->dev_id, 0);
> + if (blks != blks_size) {
> + ret = -1;
> + stm32prog_err("%s (0x%x): MMC erase failed",
> +   part->name, part->id);
> + }
> + break;
> +#endif
> +#ifdef CONFIG_MTD
> + case STM32PROG_NOR:
> + case STM32PROG_NAND:
> + case STM32PROG_SPI_NAND:
> + get_mtd_by_target(devstr, part->target, part->dev->dev_id);
> + printf("on %s: ", devstr);
> + sprintf(cmdbuf, "mtd erase %s 0x%llx 0x%llx",
> + devstr, part->addr, part->size);
> + if (run_command(cmdbuf, 0)) {
> + ret = -1;
> + stm32prog_err("%s (0x%x): MTD erase commands failed 
> (%s)",
> +   part->name, part->id, cmdbuf);
> + }
> + break;
> +#endif
> + default:
> + ret = -1;
> + stm32prog_err("%s (0x%x): erase invalid", part->name, part->id);
> + break;
> + }
> + if (!ret)
> + printf("done\n");
> +
> + return ret;
> +}
> +
>  static void stm32prog_devices_init(struct stm32prog_data *data)
>  {
>   int i;
>   int ret;
> + struct stm32prog_part_t *part;
>  
>   ret = treat_partition_list(data);
>   if (ret)
> @@ -1309,10 +1384,40 @@ static void stm32prog_devices_init(struct 
> stm32prog_data *data)
>   goto error;
>   }
>  
> + /* delete RAW partition before create partition */
> + for (i = 0; i < data->part_nb; i++) {
> + part = &data->part_array[i];
> +
> + if (part->part_type != RAW_IMAGE)
> + continue;
> +
> + if (!IS_SELECT(part) || !IS_DELETE(part))
> + continue;
> +
> + ret = part_delete(data, part);
> + if (ret)
> + goto error;
> + }
> +
>   ret = create_partitions(data);
>   if (ret)
>   goto error;
>  
> 

Re: [PATCH 13/18] stm32mp: stm32prog: add otp update support

[Patrice CHOTARD]

Hi

On 3/18/20 9:24 AM, Patrick Delaunay wrote:
> Add a virtual partition to update the STM32MP15x OTP based
> on SMC service provided by TF-A.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.c| 130 +-
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.h|  11 ++
>  .../cmd_stm32prog/stm32prog_usb.c |  11 ++
>  3 files changed, 151 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> index 3573c04d16..cd826dbb9c 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1106,7 +1107,7 @@ static int dfu_init_entities(struct stm32prog_data 
> *data)
>   struct dfu_entity *dfu;
>   int alt_nb;
>  
> - alt_nb = 1; /* number of virtual = CMD */
> + alt_nb = 2; /* number of virtual = CMD, OTP*/
>   if (data->part_nb == 0)
>   alt_nb++;  /* +1 for FlashLayout */
>   else
> @@ -1154,6 +1155,9 @@ static int dfu_init_entities(struct stm32prog_data 
> *data)
>   if (!ret)
>   ret = stm32prog_alt_add_virt(dfu, "virtual", PHASE_CMD, 512);
>  
> + if (!ret)
> + ret = stm32prog_alt_add_virt(dfu, "OTP", PHASE_OTP, 512);
> +
>   if (ret)
>   stm32prog_err("dfu init failed: %d", ret);
>   puts("done\n");
> @@ -1164,6 +1168,123 @@ static int dfu_init_entities(struct stm32prog_data 
> *data)
>   return ret;
>  }
>  
> +int stm32prog_otp_write(struct stm32prog_data *data, u32 offset, u8 *buffer,
> + long *size)
> +{
> + pr_debug("%s: %x %lx\n", __func__, offset, *size);
> +
> + if (!data->otp_part) {
> + data->otp_part = memalign(CONFIG_SYS_CACHELINE_SIZE, OTP_SIZE);
> + if (!data->otp_part)
> + return -ENOMEM;
> + }
> +
> + if (!offset)
> + memset(data->otp_part, 0, OTP_SIZE);
> +
> + if (offset + *size > OTP_SIZE)
> + *size = OTP_SIZE - offset;
> +
> + memcpy((void *)((u32)data->otp_part + offset), buffer, *size);
> +
> + return 0;
> +}
> +
> +int stm32prog_otp_read(struct stm32prog_data *data, u32 offset, u8 *buffer,
> +long *size)
> +{
> +#ifndef CONFIG_ARM_SMCCC
> + stm32prog_err("OTP update not supported");
> +
> + return -1;
> +#else
> + int result = 0;
> +
> + pr_debug("%s: %x %lx\n", __func__, offset, *size);
> + /* alway read for first packet */
> + if (!offset) {
> + if (!data->otp_part)
> + data->otp_part =
> + memalign(CONFIG_SYS_CACHELINE_SIZE, OTP_SIZE);
> +
> + if (!data->otp_part) {
> + result = -ENOMEM;
> + goto end_otp_read;
> + }
> +
> + /* init struct with 0 */
> + memset(data->otp_part, 0, OTP_SIZE);
> +
> + /* call the service */
> + result = stm32_smc_exec(STM32_SMC_BSEC, STM32_SMC_READ_ALL,
> + (u32)data->otp_part, 0);
> + if (result)
> + goto end_otp_read;
> + }
> +
> + if (!data->otp_part) {
> + result = -ENOMEM;
> + goto end_otp_read;
> + }
> +
> + if (offset + *size > OTP_SIZE)
> + *size = OTP_SIZE - offset;
> + memcpy(buffer, (void *)((u32)data->otp_part + offset), *size);
> +
> +end_otp_read:
> + pr_debug("%s: result %i\n", __func__, result);
> +
> + return result;
> +#endif
> +}
> +
> +int stm32prog_otp_start(struct stm32prog_data *data)
> +{
> +#ifndef CONFIG_ARM_SMCCC
> + stm32prog_err("OTP update not supported");
> +
> + return -1;
> +#else
> + int result = 0;
> + struct arm_smccc_res res;
> +
> + if (!data->otp_part) {
> + stm32prog_err("start OTP without data");
> + return -1;
> + }
> +
> + arm_smccc_smc(STM32_SMC_BSEC, STM32_SMC_WRITE_ALL,
> +   (u32)data->otp_part, 0, 0, 0, 0, 0, &res);
> +
> + if (!res.a0) {
> + switch (res.a1) {
> + case 0:
> + result = 0;
> + break;
> + case 1:
> + stm32prog_err("Provisioning");
> + result = 0;
> + break;
> + default:
> + pr_err("%s: OTP incorrect value (err = %ld)\n",
> +__func__, res.a1);
> + result = -EINVAL;
> + break;
> + }
> + } else {
> + pr_err("%s: Failed to exec svc=%x op=%x in secure mode (err = 
> %ld)\n",
> +__func__, STM32_SMC_BSEC, STM32_SMC_WRITE_ALL, res.a0);
> + result = -EINVAL;
> + }
> +
>

Re: [PATCH 14/18] stm32mp: stm32prog: add pmic NVM update support

[Patrice CHOTARD]

Hi

On 3/18/20 9:24 AM, Patrick Delaunay wrote:
> Add a virtual partition to update the pmic non volatile memory.
> (on ST board, STPMIC1).
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.c| 95 ++-
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.h| 10 ++
>  .../cmd_stm32prog/stm32prog_usb.c | 11 +++
>  3 files changed, 115 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> index cd826dbb9c..d127afefaa 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> @@ -7,6 +7,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1107,7 +1108,7 @@ static int dfu_init_entities(struct stm32prog_data 
> *data)
>   struct dfu_entity *dfu;
>   int alt_nb;
>  
> - alt_nb = 2; /* number of virtual = CMD, OTP*/
> + alt_nb = 3; /* number of virtual = CMD, OTP, PMIC*/
>   if (data->part_nb == 0)
>   alt_nb++;  /* +1 for FlashLayout */
>   else
> @@ -1158,6 +1159,9 @@ static int dfu_init_entities(struct stm32prog_data 
> *data)
>   if (!ret)
>   ret = stm32prog_alt_add_virt(dfu, "OTP", PHASE_OTP, 512);
>  
> + if (!ret && CONFIG_IS_ENABLED(DM_PMIC))
> + ret = stm32prog_alt_add_virt(dfu, "PMIC", PHASE_PMIC, 8);
> +
>   if (ret)
>   stm32prog_err("dfu init failed: %d", ret);
>   puts("done\n");
> @@ -1285,6 +1289,93 @@ int stm32prog_otp_start(struct stm32prog_data *data)
>  #endif
>  }
>  
> +int stm32prog_pmic_write(struct stm32prog_data *data, u32 offset, u8 *buffer,
> +  long *size)
> +{
> + pr_debug("%s: %x %lx\n", __func__, offset, *size);
> +
> + if (!offset)
> + memset(data->pmic_part, 0, PMIC_SIZE);
> +
> + if (offset + *size > PMIC_SIZE)
> + *size = PMIC_SIZE - offset;
> +
> + memcpy(&data->pmic_part[offset], buffer, *size);
> +
> + return 0;
> +}
> +
> +int stm32prog_pmic_read(struct stm32prog_data *data, u32 offset, u8 *buffer,
> + long *size)
> +{
> + int result = 0, ret;
> + struct udevice *dev;
> +
> + if (!CONFIG_IS_ENABLED(PMIC_STPMIC1)) {
> + stm32prog_err("PMIC update not supported");
> +
> + return -EOPNOTSUPP;
> + }
> +
> + pr_debug("%s: %x %lx\n", __func__, offset, *size);
> + ret = uclass_get_device_by_driver(UCLASS_MISC,
> +   DM_GET_DRIVER(stpmic1_nvm),
> +   &dev);
> + if (ret)
> + return ret;
> +
> + /* alway request PMIC for first packet */
> + if (!offset) {
> + /* init struct with 0 */
> + memset(data->pmic_part, 0, PMIC_SIZE);
> +
> + ret = uclass_get_device_by_driver(UCLASS_MISC,
> +   DM_GET_DRIVER(stpmic1_nvm),
> +   &dev);
> + if (ret)
> + return ret;
> +
> + ret = misc_read(dev, 0xF8, data->pmic_part, PMIC_SIZE);
> + if (ret < 0) {
> + result = ret;
> + goto end_pmic_read;
> + }
> + if (ret != PMIC_SIZE) {
> + result = -EACCES;
> + goto end_pmic_read;
> + }
> + }
> +
> + if (offset + *size > PMIC_SIZE)
> + *size = PMIC_SIZE - offset;
> +
> + memcpy(buffer, &data->pmic_part[offset], *size);
> +
> +end_pmic_read:
> + pr_debug("%s: result %i\n", __func__, result);
> + return result;
> +}
> +
> +int stm32prog_pmic_start(struct stm32prog_data *data)
> +{
> + int ret;
> + struct udevice *dev;
> +
> + if (!CONFIG_IS_ENABLED(PMIC_STPMIC1)) {
> + stm32prog_err("PMIC update not supported");
> +
> + return -EOPNOTSUPP;
> + }
> +
> + ret = uclass_get_device_by_driver(UCLASS_MISC,
> +   DM_GET_DRIVER(stpmic1_nvm),
> +   &dev);
> + if (ret)
> + return ret;
> +
> + return misc_write(dev, 0xF8, data->pmic_part, PMIC_SIZE);
> +}
> +
>  /* copy FSBL on NAND to improve reliability on NAND */
>  static int stm32prog_copy_fsbl(struct stm32prog_part_t *part)
>  {
> @@ -1585,6 +1676,8 @@ void dfu_flush_callback(struct dfu_entity *dfu)
>   if (dfu->dev_type == DFU_DEV_VIRT) {
>   if (dfu->data.virt.dev_num == PHASE_OTP)
>   stm32prog_otp_start(stm32prog_data);
> + else if (dfu->data.virt.dev_num == PHASE_PMIC)
> + stm32prog_pmic_start(stm32prog_data);
>   return;
>   }
>  
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
> ind

Re: [PATCH 15/18] stm32mp: stm32prog: add serial link support

[Patrice CHOTARD]

Hi

On 3/18/20 9:25 AM, Patrick Delaunay wrote:
> Add a support of UART, using the same protocol than MCU STM32.
>
> See "AN5275: USB DFU/USART protocols used in STM32MP1 Series
> bootloaders" for details.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  arch/arm/mach-stm32mp/cmd_stm32prog/Makefile  |   1 +
>  .../cmd_stm32prog/cmd_stm32prog.c |  11 +-
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.c|   4 +
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.h|  11 +
>  .../cmd_stm32prog/stm32prog_serial.c  | 993 ++
>  .../cmd_stm32prog/stm32prog_usb.c |   2 +
>  6 files changed, 1021 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
>
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/Makefile 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/Makefile
> index 14f722759c..548a378921 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/Makefile
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/Makefile
> @@ -5,4 +5,5 @@
>  
>  obj-y += cmd_stm32prog.o
>  obj-y += stm32prog.o
> +obj-y += stm32prog_serial.o
>  obj-y += stm32prog_usb.o
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> index 581f97e0b5..1769ba05f2 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> @@ -25,11 +25,14 @@ static int do_stm32prog(cmd_tbl_t *cmdtp, int flag, int 
> argc,
>  
>   if (!strcmp(argv[1], "usb"))
>   link = LINK_USB;
> + else if (!strcmp(argv[1], "serial"))
> + link = LINK_SERIAL;
>  
>   if (link == LINK_UNDEFINED) {
>   pr_err("not supported link=%s\n", argv[1]);
>   return CMD_RET_USAGE;
>   }
> +
>   dev = (int)simple_strtoul(argv[2], NULL, 10);
>  
>   addr = STM32_DDR_BASE;
> @@ -60,6 +63,12 @@ static int do_stm32prog(cmd_tbl_t *cmdtp, int flag, int 
> argc,
>   goto cleanup;
>  
>   switch (link) {
> + case LINK_SERIAL:
> + ret = stm32prog_serial_init(data, dev);
> + if (ret)
> + goto cleanup;
> + reset = stm32prog_serial_loop(data);
> + break;
>   case LINK_USB:
>   reset = stm32prog_usb_loop(data, dev);
>   break;
> @@ -90,7 +99,7 @@ cleanup:
>  U_BOOT_CMD(stm32prog, 5, 0, do_stm32prog,
>  "  [] []\n"
>  "start communication with tools STM32Cubeprogrammer on  with 
> Flashlayout at ",
> -" = usb\n"
> +" = serial|usb\n"
>  "  = device instance\n"
>  " = address of flashlayout\n"
>  " = size of flashlayout\n"
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> index d127afefaa..0967bbc11a 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> @@ -1486,6 +1486,7 @@ void stm32prog_next_phase(struct stm32prog_data *data)
>   }
>  
>   /* found next selected partition */
> + data->dfu_seq = 0;
>   data->cur_part = NULL;
>   data->phase = PHASE_END;
>   found = false;
> @@ -1653,6 +1654,7 @@ int stm32prog_dfu_init(struct stm32prog_data *data)
>  int stm32prog_init(struct stm32prog_data *data, ulong addr, ulong size)
>  {
>   memset(data, 0x0, sizeof(*data));
> + data->read_phase = PHASE_RESET;
>   data->phase = PHASE_FLASHLAYOUT;
>  
>   return parse_flash_layout(data, addr, size);
> @@ -1664,6 +1666,7 @@ void stm32prog_clean(struct stm32prog_data *data)
>   dfu_free_entities();
>   free(data->part_array);
>   free(data->otp_part);
> + free(data->buffer);
>   free(data->header_data);
>  }
>  
> @@ -1709,6 +1712,7 @@ void dfu_initiated_callback(struct dfu_entity *dfu)
>   /* force the saved offset for the current partition */
>   if (dfu->alt == stm32prog_data->cur_part->alt_id) {
>   dfu->offset = stm32prog_data->offset;
> + stm32prog_data->dfu_seq = 0;
>   pr_debug("dfu offset = 0x%llx\n", dfu->offset);
>   }
>  }
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
> index 83b27980f5..c4fdb5b8c3 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
> @@ -31,6 +31,7 @@ enum stm32prog_target {
>  };
>  
>  enum stm32prog_link_t {
> + LINK_SERIAL,
>   LINK_USB,
>   LINK_UNDEFINED,
>  };
> @@ -127,6 +128,14 @@ struct stm32prog_data {
>   /* STM32 header information */
>   struct raw_header_s *header_data;
>   struct image_header_s   header;
> +
> + /* SERIAL information */
> + u32 cursor;
> + u32 packet_number;
> + u32 checksum;
> + u8  *buffer; /* size = USART_RAM_BUFFER_SIZE*/
> + int dfu_seq;
> + u8  read_phas

Re: [PATCH 16/18] stm32mp: stm32prog: enable videoconsole

[Patrice CHOTARD]

Hi

On 3/18/20 9:25 AM, Patrick Delaunay wrote:
> Enable the videoconsole during the stm32prog command execution
> to have information without UART.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  .../cmd_stm32prog/cmd_stm32prog.c | 28 +++
>  1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> index 1769ba05f2..15bbdc2cb6 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> @@ -11,6 +11,32 @@
>  
>  struct stm32prog_data *stm32prog_data;
>  
> +static void enable_vidconsole(void)
> +{
> +#ifdef CONFIG_DM_VIDEO
> + char *stdname;
> + char buf[64];
> +
> + stdname = env_get("stdout");
> + if (!stdname || !strstr(stdname, "vidconsole")) {
> + if (!stdname)
> + snprintf(buf, sizeof(buf), "serial,vidconsole");
> + else
> + snprintf(buf, sizeof(buf), "%s,vidconsole", stdname);
> + env_set("stdout", buf);
> + }
> +
> + stdname = env_get("stderr");
> + if (!stdname || !strstr(stdname, "vidconsole")) {
> + if (!stdname)
> + snprintf(buf, sizeof(buf), "serial,vidconsole");
> + else
> + snprintf(buf, sizeof(buf), "%s,vidconsole", stdname);
> + env_set("stderr", buf);
> + }
> +#endif
> +}
> +
>  static int do_stm32prog(cmd_tbl_t *cmdtp, int flag, int argc,
>   char * const argv[])
>  {
> @@ -45,6 +71,8 @@ static int do_stm32prog(cmd_tbl_t *cmdtp, int flag, int 
> argc,
>   if (argc > 4)
>   size = simple_strtoul(argv[4], NULL, 16);
>  
> + enable_vidconsole();
> +
>   data = (struct stm32prog_data *)malloc(sizeof(*data));
>  
>   if (!data) {

Reviewed-by: Patrice Chotard 

Thanks

Patrice

Re: [PATCH 17/18] stm32mp: stm32prog: support for script

[Patrice CHOTARD]

Hi

On 3/18/20 9:25 AM, Patrick Delaunay wrote:
> Support an U-Boot script included in uimage instead of flashlayout file
> (text file in tsv format).
>
> This feature is used to execute this script directly when U-Boot is
> loaded in DDR (for update without STM32CubeProgrammer for example).
>
> A simple example with dfu-util only is:
>
> $> echo "dfu 0" > script.cmd
> $> mkimage -C none -A arm -T script -d script.cmd script.uimg
> $> mkimage -T stm32image -a 0xC000 -e 0xC000 -d script.uimg \
>   script.stm32
>
> $> dfu-util -d 0483:df11 -a 1 -D tf-a.stm32
> $> dfu-util -d 0483:df11 -a 0 -D script.stm32
> $> dfu-util -d 0483:df11 -a 0 -D u-boot.stm32
> $> dfu-util -d 0483:df11 -a 0 -e
>
> Then you can used dfu-utils to update your device
>
> To increase speed, you can also switch to fastboot protocol with:
>   echo "fastboot 0" > script.cmd
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  .../arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> index 15bbdc2cb6..baf9b6bd1e 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "stm32prog.h"
>  
> @@ -44,6 +45,7 @@ static int do_stm32prog(cmd_tbl_t *cmdtp, int flag, int 
> argc,
>   int dev, ret;
>   enum stm32prog_link_t link = LINK_UNDEFINED;
>   bool reset = false;
> + struct image_header_s header;
>   struct stm32prog_data *data;
>  
>   if (argc < 3 ||  argc > 5)
> @@ -71,6 +73,18 @@ static int do_stm32prog(cmd_tbl_t *cmdtp, int flag, int 
> argc,
>   if (argc > 4)
>   size = simple_strtoul(argv[4], NULL, 16);
>  
> + /* check STM32IMAGE presence */
> + if (size == 0 &&
> + !stm32prog_header_check((struct raw_header_s *)addr, &header)) {
> + size = header.image_length + BL_HEADER_SIZE;
> +
> + /* uImage detected in STM32IMAGE, execute the script */
> + if (IMAGE_FORMAT_LEGACY ==
> + genimg_get_format((void *)(addr + BL_HEADER_SIZE)))
> + return image_source_script(addr + BL_HEADER_SIZE,
> +"script@1");
> + }
> +
>   enable_vidconsole();
>  
>   data = (struct stm32prog_data *)malloc(sizeof(*data));

Reviewed-by: Patrice Chotard 

Thanks

Patrice

Re: [PATCH 18/18] stm32mp: stm32prog: add support of RAM target

[Patrice CHOTARD]

Hi

On 3/18/20 9:25 AM, Patrick Delaunay wrote:
> Add support of RAM target in flashlayout to load kernel image
> ("system") and device tree ("filesystem") in DDR with DFU and
> start these images.
>
> The flashlayout.tsv is:
>
> - 0x01fsblBinary  none0x  
> tf-a.stm32
> - 0x03ssblBinary  none0x  
> u-boot.stm32
> P 0x10kernel  System  ram00xC200  
> uImage.bin
> P 0x11dtb FileSystem  ram00xC400  dtb.bin
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  .../cmd_stm32prog/cmd_stm32prog.c | 28 ++
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.c| 29 ++-
>  .../mach-stm32mp/cmd_stm32prog/stm32prog.h|  7 -
>  3 files changed, 62 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> index baf9b6bd1e..6bebea7ad5 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
> @@ -47,6 +47,7 @@ static int do_stm32prog(cmd_tbl_t *cmdtp, int flag, int 
> argc,
>   bool reset = false;
>   struct image_header_s header;
>   struct stm32prog_data *data;
> + u32 uimage, dtb;
>  
>   if (argc < 3 ||  argc > 5)
>   return CMD_RET_USAGE;
> @@ -118,11 +119,38 @@ static int do_stm32prog(cmd_tbl_t *cmdtp, int flag, int 
> argc,
>   goto cleanup;
>   }
>  
> + uimage = data->uimage;
> + dtb = data->dtb;
> +
>   stm32prog_clean(data);
>   free(stm32prog_data);
>   stm32prog_data = NULL;
>  
>   puts("Download done\n");
> +
> + if (uimage) {
> + char boot_addr_start[20];
> + char dtb_addr[20];
> + char *bootm_argv[5] = {
> + "bootm", boot_addr_start, "-", dtb_addr, NULL
> + };
> + if (!dtb)
> + bootm_argv[3] = env_get("fdtcontroladdr");
> + else
> + snprintf(dtb_addr, sizeof(dtb_addr) - 1,
> +  "0x%x", dtb);
> +
> + snprintf(boot_addr_start, sizeof(boot_addr_start) - 1,
> +  "0x%x", uimage);
> + printf("Booting kernel at %s - %s...\n\n\n",
> +boot_addr_start, bootm_argv[3]);
> + /* Try bootm for legacy and FIT format image */
> + if (genimg_get_format((void *)uimage) != IMAGE_FORMAT_INVALID)
> + do_bootm(cmdtp, 0, 4, bootm_argv);
> + else if CONFIG_IS_ENABLED(CMD_BOOTZ)
> + do_bootz(cmdtp, 0, 4, bootm_argv);
> + }
> +
>   if (reset) {
>   puts("Reset...\n");
>   run_command("reset", 0);
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> index 0967bbc11a..cc303214cf 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> @@ -272,6 +272,9 @@ static int parse_ip(struct stm32prog_data *data,
>   } else if (!strncmp(p, "spi-nand", 8)) {
>   part->target = STM32PROG_SPI_NAND;
>   len = 8;
> + } else if (!strncmp(p, "ram", 3)) {
> + part->target = STM32PROG_RAM;
> + len = 0;
>   } else {
>   result = -EINVAL;
>   }
> @@ -610,6 +613,11 @@ static int init_device(struct stm32prog_data *data,
>   dev->mtd = mtd;
>   break;
>  #endif
> + case STM32PROG_RAM:
> + first_addr = gd->bd->bi_dram[0].start;
> + last_addr = first_addr + gd->bd->bi_dram[0].size;
> + dev->erase_size = 1;
> + break;
>   default:
>   stm32prog_err("unknown device type = %d", dev->target);
>   return -ENODEV;
> @@ -1022,7 +1030,11 @@ static int stm32prog_alt_add(struct stm32prog_data 
> *data,
> part->name, part->id,
> size, multiplier, type);
>  
> - if (part->part_type == RAW_IMAGE) {
> + if (part->target == STM32PROG_RAM) {
> + offset += snprintf(buf + offset, ALT_BUF_LEN - offset,
> +"ram 0x%llx 0x%llx",
> +part->addr, part->size);
> + } else if (part->part_type == RAW_IMAGE) {
>   u64 dfu_size;
>  
>   if (part->dev->target == STM32PROG_MMC)
> @@ -1073,6 +1085,10 @@ static int stm32prog_alt_add(struct stm32prog_data 
> *data,
>   get_mtd_by_target(devstr, part->target, part->dev_id);
>   break;
>  #endif
> + case STM32PROG_RAM:
> + sprintf(dfustr, "ram");
> + sprintf(devstr, "0");
> + break;
>   default:
>   stm32prog_err("invalid target: %d", part->targ

Re: [Uboot-stm32] [PATCH 1/3] stm32mp1: board: add support of CONFIG_ENV_IS_IN_MMC

[Patrice CHOTARD]

Hi

On 3/19/20 11:21 AM, Patrick Delaunay wrote:
> Add support of CONFIG_ENV_IS_IN_MMC in env_get_location, used for
> all mmc device (SD card and eMMC).
> The 2 configs CONFIG_ENV_IS_IN_MMC and CONFIG_ENV_IS_IN_EXT4 are
> incompatible.
>
> Add the weak function mmc_get_env_dev to select the mmc boot instance.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  board/st/stm32mp1/stm32mp1.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
> index c36e7655c0..effba41ad1 100644
> --- a/board/st/stm32mp1/stm32mp1.c
> +++ b/board/st/stm32mp1/stm32mp1.c
> @@ -785,6 +785,11 @@ enum env_location env_get_location(enum env_operation 
> op, int prio)
>   return ENVL_UNKNOWN;
>  
>   switch (bootmode & TAMP_BOOT_DEVICE_MASK) {
> +#ifdef CONFIG_ENV_IS_IN_MMC
> + case BOOT_FLASH_SD:
> + case BOOT_FLASH_EMMC:
> + return ENVL_MMC;
> +#endif
>  #ifdef CONFIG_ENV_IS_IN_EXT4
>   case BOOT_FLASH_SD:
>   case BOOT_FLASH_EMMC:
> @@ -826,6 +831,15 @@ const char *env_ext4_get_dev_part(void)
>  }
>  #endif
>  
> +#if defined(CONFIG_ENV_IS_IN_MMC)
> +int mmc_get_env_dev(void)
> +{
> + u32 bootmode = get_bootmode();
> +
> + return (bootmode & TAMP_BOOT_INSTANCE_MASK) - 1;
> +}
> +#endif
> +
>  #ifdef CONFIG_SYS_MTDPARTS_RUNTIME
>  
>  #define MTDPARTS_LEN 256

Reviewed-by: Patrice Chotard 

Thanks

Patrice

Re: [Uboot-stm32] [PATCH 2/3] stm32mp1: use a specific SD/eMMC partition for U-Boot enviromnent

[Patrice CHOTARD]

Hi

On 3/19/20 11:21 AM, Patrick Delaunay wrote:
> Save the environment at the end of the U-Boot partition, the GPT
> partition named "ssbl" in SD card or eMMC and avoid requirements
> on the "bootfs" file system generated via specific raw tools
> (like wic and genimage).
>
> With the previous configuration of the U-Boot environment saved in ext4
> file, U-Boot need to create/modify the file uenv.txt in the ext4 file
> system; so this EXT4 file system need to be generated without some
> functionality, like metadata_csum and dir_index, because they are not
> supported by U-Boot.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 1 +
>  arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi   | 1 +
>  arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi   | 1 +
>  configs/stm32mp15_basic_defconfig  | 5 +
>  configs/stm32mp15_optee_defconfig  | 5 +
>  configs/stm32mp15_trusted_defconfig| 5 +
>  6 files changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi 
> b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> index d6dc746365..8e49c47a1d 100644
> --- a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> @@ -20,6 +20,7 @@
>   config {
>   u-boot,boot-led = "led1";
>   u-boot,error-led = "led4";
> + u-boot,mmc-env-partition = "ssbl";
>   };
>  };
>  
> diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi 
> b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> index a5cc01dd19..e3f75208fd 100644
> --- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> @@ -16,6 +16,7 @@
>   config {
>   u-boot,boot-led = "heartbeat";
>   u-boot,error-led = "error";
> + u-boot,mmc-env-partition = "ssbl";
>   st,adc_usb_pd = <&adc1 18>, <&adc1 19>;
>   st,fastboot-gpios = <&gpioa 13 GPIO_ACTIVE_LOW>;
>   st,stm32prog-gpios = <&gpioa 14 GPIO_ACTIVE_LOW>;
> diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi 
> b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> index 347edf7e58..4d00ec618a 100644
> --- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> @@ -17,6 +17,7 @@
>   config {
>   u-boot,boot-led = "heartbeat";
>   u-boot,error-led = "error";
> + u-boot,mmc-env-partition = "ssbl";
>   st,fastboot-gpios = <&gpioa 13 GPIO_ACTIVE_LOW>;
>   st,stm32prog-gpios = <&gpioa 14 GPIO_ACTIVE_LOW>;
>   };
> diff --git a/configs/stm32mp15_basic_defconfig 
> b/configs/stm32mp15_basic_defconfig
> index 6d82365348..dd55a8b632 100644
> --- a/configs/stm32mp15_basic_defconfig
> +++ b/configs/stm32mp15_basic_defconfig
> @@ -55,13 +55,10 @@ CONFIG_CMD_UBI=y
>  CONFIG_DEFAULT_DEVICE_TREE="stm32mp157c-ev1"
>  CONFIG_OF_SPL_REMOVE_PROPS="interrupts interrupt-names interrupts-extended 
> interrupt-controller \\\#interrupt-cells interrupt-parent dmas dma-names 
> assigned-clocks assigned-clock-rates assigned-clock-parents hwlocks"
>  CONFIG_ENV_IS_NOWHERE=y
> -CONFIG_ENV_IS_IN_EXT4=y
> +CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_ENV_IS_IN_SPI_FLASH=y
>  CONFIG_ENV_IS_IN_UBI=y
>  CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
> -CONFIG_ENV_EXT4_INTERFACE="mmc"
> -CONFIG_ENV_EXT4_DEVICE_AND_PART="0:auto"
> -CONFIG_ENV_EXT4_FILE="/uboot.env"
>  CONFIG_ENV_UBI_PART="UBI"
>  CONFIG_ENV_UBI_VOLUME="uboot_config"
>  CONFIG_ENV_UBI_VOLUME_REDUND="uboot_config_r"
> diff --git a/configs/stm32mp15_optee_defconfig 
> b/configs/stm32mp15_optee_defconfig
> index 298611776d..1f40669872 100644
> --- a/configs/stm32mp15_optee_defconfig
> +++ b/configs/stm32mp15_optee_defconfig
> @@ -42,13 +42,10 @@ CONFIG_CMD_MTDPARTS=y
>  CONFIG_CMD_UBI=y
>  CONFIG_DEFAULT_DEVICE_TREE="stm32mp157c-ev1"
>  CONFIG_ENV_IS_NOWHERE=y
> -CONFIG_ENV_IS_IN_EXT4=y
> +CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_ENV_IS_IN_SPI_FLASH=y
>  CONFIG_ENV_IS_IN_UBI=y
>  CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
> -CONFIG_ENV_EXT4_INTERFACE="mmc"
> -CONFIG_ENV_EXT4_DEVICE_AND_PART="0:auto"
> -CONFIG_ENV_EXT4_FILE="/uboot.env"
>  CONFIG_ENV_UBI_PART="UBI"
>  CONFIG_ENV_UBI_VOLUME="uboot_config"
>  CONFIG_ENV_UBI_VOLUME_REDUND="uboot_config_r"
> diff --git a/configs/stm32mp15_trusted_defconfig 
> b/configs/stm32mp15_trusted_defconfig
> index 6928e9a65c..7dae7663b0 100644
> --- a/configs/stm32mp15_trusted_defconfig
> +++ b/configs/stm32mp15_trusted_defconfig
> @@ -41,13 +41,10 @@ CONFIG_CMD_MTDPARTS=y
>  CONFIG_CMD_UBI=y
>  CONFIG_DEFAULT_DEVICE_TREE="stm32mp157c-ev1"
>  CONFIG_ENV_IS_NOWHERE=y
> -CONFIG_ENV_IS_IN_EXT4=y
> +CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_ENV_IS_IN_SPI_FLASH=y
>  CONFIG_ENV_IS_IN_UBI=y
>  CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
> -CONFIG_ENV_EXT4_INTERFACE="mmc"
> -CONFIG_ENV_EXT4_DEVICE_AND_PART="0:auto"
> -CONFIG_ENV_EXT4_FILE="/uboot.env"
>  CONFIG_ENV_UBI_PART="UBI"
>  CONFIG_ENV_UBI_VOLUME="uboot

Re: [Uboot-stm32] [PATCH 3/3] configs:stm32mp1: activate env config in SPL

[Patrice CHOTARD]

Hi

On 3/19/20 11:21 AM, Patrick Delaunay wrote:
> Activate env config in SPL with CONFIG_SPL_ENV_SUPPORT
> and use CONFIG_IS_ENABLED macro to test the activated
> CONFIG_$(SPL_)ENV_IS_IN_... in env_get_location.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  board/st/stm32mp1/stm32mp1.c  | 8 
>  configs/stm32mp15_basic_defconfig | 3 +++
>  2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
> index effba41ad1..474033d640 100644
> --- a/board/st/stm32mp1/stm32mp1.c
> +++ b/board/st/stm32mp1/stm32mp1.c
> @@ -785,21 +785,21 @@ enum env_location env_get_location(enum env_operation 
> op, int prio)
>   return ENVL_UNKNOWN;
>  
>   switch (bootmode & TAMP_BOOT_DEVICE_MASK) {
> -#ifdef CONFIG_ENV_IS_IN_MMC
> +#if CONFIG_IS_ENABLED(ENV_IS_IN_MMC)
>   case BOOT_FLASH_SD:
>   case BOOT_FLASH_EMMC:
>   return ENVL_MMC;
>  #endif
> -#ifdef CONFIG_ENV_IS_IN_EXT4
> +#if CONFIG_IS_ENABLED(ENV_IS_IN_EXT4)
>   case BOOT_FLASH_SD:
>   case BOOT_FLASH_EMMC:
>   return ENVL_EXT4;
>  #endif
> -#ifdef CONFIG_ENV_IS_IN_UBI
> +#if CONFIG_IS_ENABLED(ENV_IS_IN_UBI)
>   case BOOT_FLASH_NAND:
>   return ENVL_UBI;
>  #endif
> -#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
> +#if CONFIG_IS_ENABLED(ENV_IS_IN_SPI_FLASH)
>   case BOOT_FLASH_NOR:
>   return ENVL_SPI_FLASH;
>  #endif
> diff --git a/configs/stm32mp15_basic_defconfig 
> b/configs/stm32mp15_basic_defconfig
> index dd55a8b632..c63002628c 100644
> --- a/configs/stm32mp15_basic_defconfig
> +++ b/configs/stm32mp15_basic_defconfig
> @@ -16,6 +16,7 @@ CONFIG_FIT=y
>  CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
>  CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION=y
>  CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=3
> +CONFIG_SPL_ENV_SUPPORT=y
>  CONFIG_SPL_I2C_SUPPORT=y
>  CONFIG_SPL_MTD_SUPPORT=y
>  CONFIG_SPL_POWER_SUPPORT=y
> @@ -63,6 +64,8 @@ CONFIG_ENV_UBI_PART="UBI"
>  CONFIG_ENV_UBI_VOLUME="uboot_config"
>  CONFIG_ENV_UBI_VOLUME_REDUND="uboot_config_r"
>  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +# CONFIG_SPL_ENV_IS_NOWHERE is not set
> +# CONFIG_SPL_ENV_IS_IN_SPI_FLASH is not set
>  CONFIG_STM32_ADC=y
>  CONFIG_DFU_MMC=y
>  CONFIG_DFU_RAM=y

Reviewed-by: Patrice Chotard 

Thanks

Patrice

Re: [PATCH] tiny-printf: Support %i

[Tom Rini]

On Tue, Apr 14, 2020 at 02:24:18PM +0200, Marek Vasut wrote:
> On 4/14/20 5:03 AM, Tom Rini wrote:
> > On Tue, Apr 14, 2020 at 03:17:16AM +0200, Marek Vasut wrote:
> >> On 4/14/20 1:27 AM, Tom Rini wrote:
> >>> On Fri, Apr 10, 2020 at 08:54:49PM +0200, Marek Vasut wrote:
> >>>
>  The most basic printf("%i", value) formating string was missing,
>  add it for the sake of convenience.
> 
>  Signed-off-by: Marek Vasut 
>  Cc: Simon Glass 
>  Cc: Stefan Roese 
>  ---
>   lib/tiny-printf.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
>  diff --git a/lib/tiny-printf.c b/lib/tiny-printf.c
>  index 1138c7012a..8fc7e48d99 100644
>  --- a/lib/tiny-printf.c
>  +++ b/lib/tiny-printf.c
>  @@ -242,6 +242,7 @@ static int _vprintf(struct printf_info *info, const 
>  char *fmt, va_list va)
>   goto abort;
>   case 'u':
>   case 'd':
>  +case 'i':
>   div = 10;
>   if (islong) {
>   num = va_arg(va, unsigned long);
>  @@ -251,7 +252,7 @@ static int _vprintf(struct printf_info *info, const 
>  char *fmt, va_list va)
>   num = va_arg(va, unsigned int);
>   }
>   
>  -if (ch == 'd') {
>  +if (ch != 'u') {
>   if (islong && (long)num < 0) {
>   num = -(long)num;
>   out(info, '-');
> >>>
> >>> How much does the size change and where do we see this as a problem?
> >>
> >> Any code which uses %i in SPL just misbehaves, e.g.
> >> printf("%s[%i] value=%x", __func__, __LINE__, val);
> >> prints function name and then incorrect value, because %i is ignored.
> >> This is also documented in the commit message.
> >>
> >> U-Boot grows in size massively due to all the DM/DT bloat which is being
> >> forced upon everyone, but there the uncontrolled growth is apparently OK
> >> even if it brings no obvious improvement, rather the opposite. And yet
> >> here, size increase suddenly matters? Sorry, that's not right.
> >>
> >> The code grows by 6 bytes.
> > 
> > Yes, it matters for _tiny-printf_ as that's where we have little to no
> > room for growth.
> 
> How many systems that use tiny-printf in SPL are also forced to use DM
> in SPL ?

I don't know how many times I've said no one is forced to switch to DM
in SPL.

> > So it's just debug prints you were doing that ran in
> > to a problem?  Thanks!
> 
> git grep %i indicates ~400 sites where %i is used, so no, not just debug
> prints. All of those are broken. And no, I'm not inclined to patch all
> the code to use %d instead of %i just because handling %i is a problem.

Not all 400 of them but the ones that are expected to be used in SPL and
with TINY_PRINTF need to, yes.  Go look at the git log of tiny-printf.c,
we've changed things around to avoid growth when at all possible.
Because yes, I don't want to grow a few hundred boards by 6 bytes when
we have a reasonable alternative.  There's 300 hits, of which a dozen
are non-debug and likely to ever be in SPL code.  And no, this isn't the
first time I've raised such an issue, it's just the first time you've
been hit by this, sorry.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] tiny-printf: Support %i

[Marek Vasut]

On 4/14/20 3:26 PM, Tom Rini wrote:
> On Tue, Apr 14, 2020 at 02:24:18PM +0200, Marek Vasut wrote:
>> On 4/14/20 5:03 AM, Tom Rini wrote:
>>> On Tue, Apr 14, 2020 at 03:17:16AM +0200, Marek Vasut wrote:
 On 4/14/20 1:27 AM, Tom Rini wrote:
> On Fri, Apr 10, 2020 at 08:54:49PM +0200, Marek Vasut wrote:
>
>> The most basic printf("%i", value) formating string was missing,
>> add it for the sake of convenience.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Simon Glass 
>> Cc: Stefan Roese 
>> ---
>>  lib/tiny-printf.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/lib/tiny-printf.c b/lib/tiny-printf.c
>> index 1138c7012a..8fc7e48d99 100644
>> --- a/lib/tiny-printf.c
>> +++ b/lib/tiny-printf.c
>> @@ -242,6 +242,7 @@ static int _vprintf(struct printf_info *info, const 
>> char *fmt, va_list va)
>>  goto abort;
>>  case 'u':
>>  case 'd':
>> +case 'i':
>>  div = 10;
>>  if (islong) {
>>  num = va_arg(va, unsigned long);
>> @@ -251,7 +252,7 @@ static int _vprintf(struct printf_info *info, const 
>> char *fmt, va_list va)
>>  num = va_arg(va, unsigned int);
>>  }
>>  
>> -if (ch == 'd') {
>> +if (ch != 'u') {
>>  if (islong && (long)num < 0) {
>>  num = -(long)num;
>>  out(info, '-');
>
> How much does the size change and where do we see this as a problem?

 Any code which uses %i in SPL just misbehaves, e.g.
 printf("%s[%i] value=%x", __func__, __LINE__, val);
 prints function name and then incorrect value, because %i is ignored.
 This is also documented in the commit message.

 U-Boot grows in size massively due to all the DM/DT bloat which is being
 forced upon everyone, but there the uncontrolled growth is apparently OK
 even if it brings no obvious improvement, rather the opposite. And yet
 here, size increase suddenly matters? Sorry, that's not right.

 The code grows by 6 bytes.
>>>
>>> Yes, it matters for _tiny-printf_ as that's where we have little to no
>>> room for growth.
>>
>> How many systems that use tiny-printf in SPL are also forced to use DM
>> in SPL ?
> 
> I don't know how many times I've said no one is forced to switch to DM
> in SPL.

This is beside the point, there are boards which use SPL and DM, because
the non-DM drivers are steadily going away. So the growth in SPL size is
there, either directly or as a side-effect.

>>> So it's just debug prints you were doing that ran in
>>> to a problem?  Thanks!
>>
>> git grep %i indicates ~400 sites where %i is used, so no, not just debug
>> prints. All of those are broken. And no, I'm not inclined to patch all
>> the code to use %d instead of %i just because handling %i is a problem.
> 
> Not all 400 of them but the ones that are expected to be used in SPL and
> with TINY_PRINTF need to, yes.  Go look at the git log of tiny-printf.c,
> we've changed things around to avoid growth when at all possible.

I appreciate that. However, I would also appreciate if printf() behaved
in a sane manner, and missing %i support is really weird.

> Because yes, I don't want to grow a few hundred boards by 6 bytes when
> we have a reasonable alternative.  There's 300 hits, of which a dozen
> are non-debug and likely to ever be in SPL code.

Why don't we instead replace %d with %i altogether then ? The %d seems
to be seldom used outside of U-Boot, where it is only used because of
this tiny-printf limitation, while %i is used quite often.

> And no, this isn't the
> first time I've raised such an issue, it's just the first time you've
> been hit by this, sorry.

Does this therefore set a precedent that we are allowed to block any and
all patches which grow SPL size, no matter how useful they might be ?

Re: [PATCH] tiny-printf: Support %i

[Tom Rini]

On Tue, Apr 14, 2020 at 03:40:14PM +0200, Marek Vasut wrote:
> On 4/14/20 3:26 PM, Tom Rini wrote:
> > On Tue, Apr 14, 2020 at 02:24:18PM +0200, Marek Vasut wrote:
> >> On 4/14/20 5:03 AM, Tom Rini wrote:
> >>> On Tue, Apr 14, 2020 at 03:17:16AM +0200, Marek Vasut wrote:
>  On 4/14/20 1:27 AM, Tom Rini wrote:
> > On Fri, Apr 10, 2020 at 08:54:49PM +0200, Marek Vasut wrote:
> >
> >> The most basic printf("%i", value) formating string was missing,
> >> add it for the sake of convenience.
> >>
> >> Signed-off-by: Marek Vasut 
> >> Cc: Simon Glass 
> >> Cc: Stefan Roese 
> >> ---
> >>  lib/tiny-printf.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/lib/tiny-printf.c b/lib/tiny-printf.c
> >> index 1138c7012a..8fc7e48d99 100644
> >> --- a/lib/tiny-printf.c
> >> +++ b/lib/tiny-printf.c
> >> @@ -242,6 +242,7 @@ static int _vprintf(struct printf_info *info, 
> >> const char *fmt, va_list va)
> >>goto abort;
> >>case 'u':
> >>case 'd':
> >> +  case 'i':
> >>div = 10;
> >>if (islong) {
> >>num = va_arg(va, unsigned long);
> >> @@ -251,7 +252,7 @@ static int _vprintf(struct printf_info *info, 
> >> const char *fmt, va_list va)
> >>num = va_arg(va, unsigned int);
> >>}
> >>  
> >> -  if (ch == 'd') {
> >> +  if (ch != 'u') {
> >>if (islong && (long)num < 0) {
> >>num = -(long)num;
> >>out(info, '-');
> >
> > How much does the size change and where do we see this as a problem?
> 
>  Any code which uses %i in SPL just misbehaves, e.g.
>  printf("%s[%i] value=%x", __func__, __LINE__, val);
>  prints function name and then incorrect value, because %i is ignored.
>  This is also documented in the commit message.
> 
>  U-Boot grows in size massively due to all the DM/DT bloat which is being
>  forced upon everyone, but there the uncontrolled growth is apparently OK
>  even if it brings no obvious improvement, rather the opposite. And yet
>  here, size increase suddenly matters? Sorry, that's not right.
> 
>  The code grows by 6 bytes.
> >>>
> >>> Yes, it matters for _tiny-printf_ as that's where we have little to no
> >>> room for growth.
> >>
> >> How many systems that use tiny-printf in SPL are also forced to use DM
> >> in SPL ?
> > 
> > I don't know how many times I've said no one is forced to switch to DM
> > in SPL.
> 
> This is beside the point, there are boards which use SPL and DM, because
> the non-DM drivers are steadily going away. So the growth in SPL size is
> there, either directly or as a side-effect.
> 
> >>> So it's just debug prints you were doing that ran in
> >>> to a problem?  Thanks!
> >>
> >> git grep %i indicates ~400 sites where %i is used, so no, not just debug
> >> prints. All of those are broken. And no, I'm not inclined to patch all
> >> the code to use %d instead of %i just because handling %i is a problem.
> > 
> > Not all 400 of them but the ones that are expected to be used in SPL and
> > with TINY_PRINTF need to, yes.  Go look at the git log of tiny-printf.c,
> > we've changed things around to avoid growth when at all possible.
> 
> I appreciate that. However, I would also appreciate if printf() behaved
> in a sane manner, and missing %i support is really weird.
> 
> > Because yes, I don't want to grow a few hundred boards by 6 bytes when
> > we have a reasonable alternative.  There's 300 hits, of which a dozen
> > are non-debug and likely to ever be in SPL code.
> 
> Why don't we instead replace %d with %i altogether then ? The %d seems
> to be seldom used outside of U-Boot, where it is only used because of
> this tiny-printf limitation, while %i is used quite often.
> 
> > And no, this isn't the
> > first time I've raised such an issue, it's just the first time you've
> > been hit by this, sorry.
> 
> Does this therefore set a precedent that we are allowed to block any and
> all patches which grow SPL size, no matter how useful they might be ?

This is following the precedent that was set for tiny printf a while ago
with some other "it would be nice if..." format that could instead be
handled differently, again for the case of tiny printf.  It is not
supposed to cover everything, or most things.  It is supposed to let
SPL/TPL still have printf in otherwise very tight situations.

And as a reminder, I throw every PR through a before/after size check
and flag growth that's global and not fi

Re: [PATCH v7 02/17] efi_loader: add signature verification functions

[Heinrich Schuchardt]

On 2020-04-14 04:51, AKASHI Takahiro wrote:
> In this commit, implemented are a couple of helper functions which will be
> used to materialize variable authentication as well as image authentication
> in later patches.
>
> Signed-off-by: AKASHI Takahiro 
> ---
>  include/efi_api.h  |  87 +
>  include/efi_loader.h   |  72 
>  lib/efi_loader/Makefile|   1 +
>  lib/efi_loader/efi_signature.c | 583 +
>  4 files changed, 743 insertions(+)
>  create mode 100644 lib/efi_loader/efi_signature.c
>
> diff --git a/include/efi_api.h b/include/efi_api.h
> index 1c40ffc4f56c..77d6bf2660b9 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -18,6 +18,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  #ifdef CONFIG_EFI_LOADER
>  #include 
> @@ -329,6 +330,10 @@ struct efi_runtime_services {
>   EFI_GUID(0x8be4df61, 0x93ca, 0x11d2, 0xaa, 0x0d, \
>0x00, 0xe0, 0x98, 0x03, 0x2b, 0x8c)
>
> +#define EFI_IMAGE_SECURITY_DATABASE_GUID \
> + EFI_GUID(0xd719b2cb, 0x3d3a, 0x4596, 0xa3, 0xbc, \
> +  0xda, 0xd0, 0x0e, 0x67, 0x65, 0x6f)
> +
>  #define EFI_FDT_GUID \
>   EFI_GUID(0xb1b621d5, 0xf19c, 0x41a5, \
>0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0)
> @@ -1682,4 +1687,86 @@ struct efi_load_file_protocol {
>  #define LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL_VENDOR_RANGE_MIN 0x1000
>  #define LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL_VENDOR_RANGE_MAX 0x4000
>
> +/* Certificate types in signature database */
> +#define EFI_CERT_SHA256_GUID \
> + EFI_GUID(0xc1c41626, 0x504c, 0x4092, 0xac, 0xa9, \
> +  0x41, 0xf9, 0x36, 0x93, 0x43, 0x28)
> +#define EFI_CERT_RSA2048_GUID \
> + EFI_GUID(0x3c5766e8, 0x269c, 0x4e34, 0xaa, 0x14, \
> +  0xed, 0x77, 0x6e, 0x85, 0xb3, 0xb6)
> +#define EFI_CERT_X509_GUID \
> + EFI_GUID(0xa5c059a1, 0x94e4, 0x4aa7, 0x87, 0xb5, \
> +  0xab, 0x15, 0x5c, 0x2b, 0xf0, 0x72)
> +#define EFI_CERT_X509_SHA256_GUID \
> + EFI_GUID(0x3bd2a492, 0x96c0, 0x4079, 0xb4, 0x20, \
> +  0xfc, 0xf9, 0x8e, 0xf1, 0x03, 0xed)
> +#define EFI_CERT_TYPE_PKCS7_GUID \
> + EFI_GUID(0x4aafd29d, 0x68df, 0x49ee, 0x8a, 0xa9, \
> +  0x34, 0x7d, 0x37, 0x56, 0x65, 0xa7)
> +
> +/**
> + * win_certificate_uefi_guid - A certificate that encapsulates
> + * a GUID-specific signature
> + *
> + * @hdr: Windows certificate header
> + * @cert_type:   Certificate type
> + * @cert_data:   Certificate data
> + */
> +struct win_certificate_uefi_guid {
> + WIN_CERTIFICATE hdr;
> + efi_guid_t  cert_type;
> + u8  cert_data[];
> +} __attribute__((__packed__));
> +
> +/**
> + * efi_variable_authentication_2 - A time-based authentication method
> + * descriptor
> + *
> + * This structure describes an authentication information for
> + * a variable with EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS
> + * and should be included as part of a variable's value.
> + * Only EFI_CERT_TYPE_PKCS7_GUID is accepted.
> + *
> + * @time_stamp:  Descriptor's time stamp
> + * @auth_info:   Authentication info
> + */
> +struct efi_variable_authentication_2 {
> + struct efi_time  time_stamp;
> + struct win_certificate_uefi_guid auth_info;
> +} __attribute__((__packed__));
> +
> +/**
> + * efi_signature_data - A format of signature
> + *
> + * This structure describes a single signature in signature database.
> + *
> + * @signature_owner: Signature owner
> + * @signature_data:  Signature data
> + */
> +struct efi_signature_data {
> + efi_guid_t  signature_owner;
> + u8  signature_data[];

Please, use [0].

> +} __attribute__((__packed__));
> +
> +/**
> + * efi_signature_list - A format of signature database
> + *
> + * This structure describes a list of signatures with the same type.
> + * An authenticated variable's value is a concatenation of one or more
> + * efi_signature_list's.
> + *
> + * @signature_type:  Signature type
> + * @signature_list_size: Size of signature list
> + * @signature_header_size:   Size of signature header
> + * @signature_size:  Size of signature
> + */
> +struct efi_signature_list {
> + efi_guid_t  signature_type;
> + u32 signature_list_size;
> + u32 signature_header_size;
> + u32 signature_size;
> +/*   u8  signature_header[signature_header_size]; */
> +/*   struct efi_signature_data signatures[...][signature_size]; */
> +} __attribute__((__packed__));
> +
>  #endif
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 3f2792892f34..8cf85d2fb7e2 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -26,6 +26,7 @@ static inline void *guidcpy(void *dst, const void *src)
>  #if CONFIG_IS_ENABLED(EFI_LOADER)
>
>  #include 
> +#include 
>
>  /* Maximum number of configuration tables */
>  #define EFI_MAX_CONFIGURATION_TABLES 16
> @@ -1

Re: [PATCH] tiny-printf: Support %i

[Simon Glass]

Hi Marek,

On Tue, 14 Apr 2020 at 07:41, Marek Vasut  wrote:
>
> On 4/14/20 3:26 PM, Tom Rini wrote:
> > On Tue, Apr 14, 2020 at 02:24:18PM +0200, Marek Vasut wrote:
> >> On 4/14/20 5:03 AM, Tom Rini wrote:
> >>> On Tue, Apr 14, 2020 at 03:17:16AM +0200, Marek Vasut wrote:
>  On 4/14/20 1:27 AM, Tom Rini wrote:
> > On Fri, Apr 10, 2020 at 08:54:49PM +0200, Marek Vasut wrote:
> >
> >> The most basic printf("%i", value) formating string was missing,
> >> add it for the sake of convenience.
> >>
> >> Signed-off-by: Marek Vasut 
> >> Cc: Simon Glass 
> >> Cc: Stefan Roese 
> >> ---
> >>  lib/tiny-printf.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/lib/tiny-printf.c b/lib/tiny-printf.c
> >> index 1138c7012a..8fc7e48d99 100644
> >> --- a/lib/tiny-printf.c
> >> +++ b/lib/tiny-printf.c
> >> @@ -242,6 +242,7 @@ static int _vprintf(struct printf_info *info, 
> >> const char *fmt, va_list va)
> >>  goto abort;
> >>  case 'u':
> >>  case 'd':
> >> +case 'i':
> >>  div = 10;
> >>  if (islong) {
> >>  num = va_arg(va, unsigned 
> >> long);
> >> @@ -251,7 +252,7 @@ static int _vprintf(struct printf_info *info, 
> >> const char *fmt, va_list va)
> >>  num = va_arg(va, unsigned 
> >> int);
> >>  }
> >>
> >> -if (ch == 'd') {
> >> +if (ch != 'u') {
> >>  if (islong && (long)num < 0) {
> >>  num = -(long)num;
> >>  out(info, '-');
> >
> > How much does the size change and where do we see this as a problem?
> 
>  Any code which uses %i in SPL just misbehaves, e.g.
>  printf("%s[%i] value=%x", __func__, __LINE__, val);
>  prints function name and then incorrect value, because %i is ignored.
>  This is also documented in the commit message.
> 
>  U-Boot grows in size massively due to all the DM/DT bloat which is being
>  forced upon everyone, but there the uncontrolled growth is apparently OK
>  even if it brings no obvious improvement, rather the opposite. And yet
>  here, size increase suddenly matters? Sorry, that's not right.
> 
>  The code grows by 6 bytes.
> >>>
> >>> Yes, it matters for _tiny-printf_ as that's where we have little to no
> >>> room for growth.
> >>
> >> How many systems that use tiny-printf in SPL are also forced to use DM
> >> in SPL ?
> >
> > I don't know how many times I've said no one is forced to switch to DM
> > in SPL.
>
> This is beside the point, there are boards which use SPL and DM, because
> the non-DM drivers are steadily going away. So the growth in SPL size is
> there, either directly or as a side-effect.

I think this is a good point. For serial we have a debug UART. I am
think it would be useful to have a 'simple bypass' for more
subsystems. For example, for I2C we could have a simple option to
access a single I2C driver directly, bypassing driver model. Of course
this is painful to do before we have completed I2C migration.

[..]

Regards,
Simon

Re: [PATCH v2 21/22] Use __ASSEMBLY__ as the assembly macros

[Simon Glass]

Hi Masahiro,

On Mon, 13 Apr 2020 at 11:10, Masahiro Yamada  wrote:
>
> On Fri, Apr 10, 2020 at 5:18 AM Simon Glass  wrote:
> >
> > Some places use __ASSEMBLER__ instead which does not work since the
> > Makefile does not define it. Fix them.
>
>
> In my understanding,
> __ASSEMBLER__ is passed by the compiler
> while building *.S files.
>
> On which compiler didn't this work for you?
>
>
>
>
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v2:
> > - Add new patch to fix occurances of __ASSEMBLER__
> >
> >  arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h | 2 +-
> >  arch/arm/include/asm/arch-mx27/regs-rtc.h  | 2 +-
> >  arch/arm/include/asm/arch-mx5/imx-regs.h   | 2 +-
> >  arch/arm/include/asm/arch-mx6/imx-regs.h   | 2 +-
> >  arch/arm/include/asm/arch-mx7/imx-regs.h   | 2 +-
> >  arch/arm/include/asm/arch-s32v234/imx-regs.h   | 2 +-
> >  arch/arm/include/asm/arch-vf610/imx-regs.h | 2 +-
> >  arch/arm/mach-socfpga/include/mach/clock_manager.h | 2 +-
> >  arch/arm/mach-socfpga/include/mach/clock_manager_arria10.h | 4 ++--
> >  arch/arm/mach-socfpga/include/mach/clock_manager_gen5.h| 4 ++--
> >  arch/arm/mach-socfpga/include/mach/sdram_arria10.h | 2 +-
> >  arch/arm/mach-stm32mp/include/mach/stm32.h | 2 +-
> >  arch/x86/include/asm/mtrr.h| 2 +-
> >  arch/x86/include/asm/sipi.h| 4 ++--
> >  include/atf_common.h   | 2 +-
> >  include/elf.h  | 4 ++--
> >  16 files changed, 20 insertions(+), 20 deletions(-)
> >

I think I hit this with device tree, but I would need to go back and
check. Anyway I think we should be consistent.

Regards,
Simon

Re: [PATCH v7 02/17] efi_loader: add signature verification functions

[Heinrich Schuchardt]

On 2020-04-14 04:51, AKASHI Takahiro wrote:
> In this commit, implemented are a couple of helper functions which will be
> used to materialize variable authentication as well as image authentication
> in later patches.
>
> Signed-off-by: AKASHI Takahiro 
> ---
>  include/efi_api.h  |  87 +
>  include/efi_loader.h   |  72 
>  lib/efi_loader/Makefile|   1 +
>  lib/efi_loader/efi_signature.c | 583 +
>  4 files changed, 743 insertions(+)
>  create mode 100644 lib/efi_loader/efi_signature.c
>
> diff --git a/include/efi_api.h b/include/efi_api.h
> index 1c40ffc4f56c..77d6bf2660b9 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -18,6 +18,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  #ifdef CONFIG_EFI_LOADER
>  #include 
> @@ -329,6 +330,10 @@ struct efi_runtime_services {
>   EFI_GUID(0x8be4df61, 0x93ca, 0x11d2, 0xaa, 0x0d, \
>0x00, 0xe0, 0x98, 0x03, 0x2b, 0x8c)
>
> +#define EFI_IMAGE_SECURITY_DATABASE_GUID \
> + EFI_GUID(0xd719b2cb, 0x3d3a, 0x4596, 0xa3, 0xbc, \
> +  0xda, 0xd0, 0x0e, 0x67, 0x65, 0x6f)
> +
>  #define EFI_FDT_GUID \
>   EFI_GUID(0xb1b621d5, 0xf19c, 0x41a5, \
>0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0)
> @@ -1682,4 +1687,86 @@ struct efi_load_file_protocol {
>  #define LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL_VENDOR_RANGE_MIN 0x1000
>  #define LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL_VENDOR_RANGE_MAX 0x4000
>
> +/* Certificate types in signature database */
> +#define EFI_CERT_SHA256_GUID \
> + EFI_GUID(0xc1c41626, 0x504c, 0x4092, 0xac, 0xa9, \
> +  0x41, 0xf9, 0x36, 0x93, 0x43, 0x28)
> +#define EFI_CERT_RSA2048_GUID \
> + EFI_GUID(0x3c5766e8, 0x269c, 0x4e34, 0xaa, 0x14, \
> +  0xed, 0x77, 0x6e, 0x85, 0xb3, 0xb6)
> +#define EFI_CERT_X509_GUID \
> + EFI_GUID(0xa5c059a1, 0x94e4, 0x4aa7, 0x87, 0xb5, \
> +  0xab, 0x15, 0x5c, 0x2b, 0xf0, 0x72)
> +#define EFI_CERT_X509_SHA256_GUID \
> + EFI_GUID(0x3bd2a492, 0x96c0, 0x4079, 0xb4, 0x20, \
> +  0xfc, 0xf9, 0x8e, 0xf1, 0x03, 0xed)
> +#define EFI_CERT_TYPE_PKCS7_GUID \
> + EFI_GUID(0x4aafd29d, 0x68df, 0x49ee, 0x8a, 0xa9, \
> +  0x34, 0x7d, 0x37, 0x56, 0x65, 0xa7)
> +
> +/**
> + * win_certificate_uefi_guid - A certificate that encapsulates
> + * a GUID-specific signature
> + *
> + * @hdr: Windows certificate header
> + * @cert_type:   Certificate type
> + * @cert_data:   Certificate data
> + */
> +struct win_certificate_uefi_guid {
> + WIN_CERTIFICATE hdr;
> + efi_guid_t  cert_type;
> + u8  cert_data[];
> +} __attribute__((__packed__));
> +
> +/**
> + * efi_variable_authentication_2 - A time-based authentication method
> + * descriptor
> + *
> + * This structure describes an authentication information for
> + * a variable with EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS
> + * and should be included as part of a variable's value.
> + * Only EFI_CERT_TYPE_PKCS7_GUID is accepted.
> + *
> + * @time_stamp:  Descriptor's time stamp
> + * @auth_info:   Authentication info
> + */
> +struct efi_variable_authentication_2 {
> + struct efi_time  time_stamp;
> + struct win_certificate_uefi_guid auth_info;
> +} __attribute__((__packed__));
> +
> +/**
> + * efi_signature_data - A format of signature
> + *
> + * This structure describes a single signature in signature database.
> + *
> + * @signature_owner: Signature owner
> + * @signature_data:  Signature data
> + */
> +struct efi_signature_data {
> + efi_guid_t  signature_owner;
> + u8  signature_data[];
> +} __attribute__((__packed__));
> +
> +/**
> + * efi_signature_list - A format of signature database
> + *
> + * This structure describes a list of signatures with the same type.
> + * An authenticated variable's value is a concatenation of one or more
> + * efi_signature_list's.
> + *
> + * @signature_type:  Signature type
> + * @signature_list_size: Size of signature list
> + * @signature_header_size:   Size of signature header
> + * @signature_size:  Size of signature
> + */
> +struct efi_signature_list {
> + efi_guid_t  signature_type;
> + u32 signature_list_size;
> + u32 signature_header_size;
> + u32 signature_size;
> +/*   u8  signature_header[signature_header_size]; */
> +/*   struct efi_signature_data signatures[...][signature_size]; */
> +} __attribute__((__packed__));
> +
>  #endif
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 3f2792892f34..8cf85d2fb7e2 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -26,6 +26,7 @@ static inline void *guidcpy(void *dst, const void *src)
>  #if CONFIG_IS_ENABLED(EFI_LOADER)
>
>  #include 
> +#include 
>
>  /* Maximum number of configuration tables */
>  #define EFI_MAX_CONFIGURATION_TABLES 16
> @@ -178,6 +179,11 @@ ext

Re: [PATCH v7 16/17] travis: add packages for UEFI secure boot test

[Heinrich Schuchardt]

On 2020-04-14 04:51, AKASHI Takahiro wrote:
> Pytest for UEFI secure boot will use several host commands.
> In particular, Test setup relies on efitools, whose version must be v1.5.2
> or later. So fetch a new version of deb package directly.
> Please note it has a dependency on mtools, which must also be installed
> along wih efitools.
>
> In addition, the path, '/sbin', is added to PATH for use of sgdisk and
> mkfs.
>
> Signed-off-by: AKASHI Takahiro 
> Reviewed-by: Tom Rini 
> ---
>  .travis.yml | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index c59bd7790b66..b08dd030ef02 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -40,6 +40,14 @@ addons:
>  - clang-7
>  - srecord
>  - graphviz
> +- coreutils
> +- util-linux
> +- dosfstools
> +- gdisk
> +- mount
> +- mtools
> +- openssl
> +- sbsigntool
>
>  install:
>   # Clone uboot-test-hooks
> @@ -60,10 +68,11 @@ install:
>   - mkdir ~/grub2-arm64
>   - ( cd ~/grub2-arm64; wget -O - 
> http://download.opensuse.org/ports/aarch64/distribution/leap/42.2/repo/oss/suse/aarch64/grub2-arm64-efi-2.02~beta2-87.1.aarch64.rpm
>  | rpm2cpio | cpio -di )
>   - wget 
> http://mirrors.kernel.org/ubuntu/pool/main/m/mpfr4/libmpfr4_3.1.4-1_amd64.deb 
> && sudo dpkg -i libmpfr4_3.1.4-1_amd64.deb && rm libmpfr4_3.1.4-1_amd64.deb
> + - wget 
> http://mirrors.kernel.org/ubuntu/pool/universe/e/efitools/efitools_1.8.1-0ubuntu2_amd64.deb
>  && sudo dpkg -i efitools_1.8.1-0ubuntu2_amd64.deb && rm 
> efitools_1.8.1-0ubuntu2_amd64.deb

Don't we need changes in the Gitlab CI and Azure CI configurations as well?

Best regards

Heinrich

>
>  env:
>global:
> -- 
> PATH=/tmp/qemu-install/bin:/tmp/uboot-test-hooks/bin:/usr/bin:/bin:/usr/local/bin
> +- 
> PATH=/tmp/qemu-install/bin:/tmp/uboot-test-hooks/bin:/sbin:/usr/bin:/bin:/usr/local/bin
>  - PYTHONPATH=/tmp/uboot-test-hooks/py/travis-ci
>  - BUILD_DIR=build
>  - HOSTCC="cc"
>

Re: [PATCH v2 21/22] Use __ASSEMBLY__ as the assembly macros

[Masahiro Yamada]

Hi Simon,

On Tue, Apr 14, 2020 at 11:41 PM Simon Glass  wrote:
>
> Hi Masahiro,
>
> On Mon, 13 Apr 2020 at 11:10, Masahiro Yamada  wrote:
> >
> > On Fri, Apr 10, 2020 at 5:18 AM Simon Glass  wrote:
> > >
> > > Some places use __ASSEMBLER__ instead which does not work since the
> > > Makefile does not define it. Fix them.
> >
> >
> > In my understanding,
> > __ASSEMBLER__ is passed by the compiler
> > while building *.S files.
> >
> > On which compiler didn't this work for you?
> >
> >
> >
> >
> > >
> > > Signed-off-by: Simon Glass 
> > > ---
> > >
> > > Changes in v2:
> > > - Add new patch to fix occurances of __ASSEMBLER__
> > >
>
> I think I hit this with device tree, but I would need to go back and
> check. Anyway I think we should be consistent.


DT files are pre-processed with  '-x assembler-with-cpp'.

So, __ASSEMBLER__ is pre-defined by the compiler.

You can easily confirm it by dumping the
compiler's pre-defined macros.



$ gcc -dM -E  - < /dev/null  | grep __ASSEMBLER__
$ gcc -dM -E -x assembler-with-cpp - < /dev/null  | grep __ASSEMBLER__
#define __ASSEMBLER__ 1




Since the following commit, DT started including U-Boot headers.
This project is progressively going strange.  :-/


commit b116aff27c56dbc9132d847f7134eb7e4cc26aa3
Author: Simon Glass 
Date:   Fri Nov 25 20:15:58 2016 -0700

binman: Allow configuration options to be used in .dts files





--
Best Regards
Masahiro Yamada

Re: [PATCH v7 02/17] efi_loader: add signature verification functions

[Heinrich Schuchardt]

On 2020-04-14 16:52, Heinrich Schuchardt wrote:
> On 2020-04-14 04:51, AKASHI Takahiro wrote:
>> In this commit, implemented are a couple of helper functions which will be
>> used to materialize variable authentication as well as image authentication
>> in later patches.
>>
>> Signed-off-by: AKASHI Takahiro 
>> ---
>>  include/efi_api.h  |  87 +
>>  include/efi_loader.h   |  72 
>>  lib/efi_loader/Makefile|   1 +
>>  lib/efi_loader/efi_signature.c | 583 +
>>  4 files changed, 743 insertions(+)
>>  create mode 100644 lib/efi_loader/efi_signature.c
>>
>> diff --git a/include/efi_api.h b/include/efi_api.h
>> index 1c40ffc4f56c..77d6bf2660b9 100644
>> --- a/include/efi_api.h
>> +++ b/include/efi_api.h
>> @@ -18,6 +18,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>
>>  #ifdef CONFIG_EFI_LOADER
>>  #include 
>> @@ -329,6 +330,10 @@ struct efi_runtime_services {
>>  EFI_GUID(0x8be4df61, 0x93ca, 0x11d2, 0xaa, 0x0d, \
>>   0x00, 0xe0, 0x98, 0x03, 0x2b, 0x8c)
>>
>> +#define EFI_IMAGE_SECURITY_DATABASE_GUID \
>> +EFI_GUID(0xd719b2cb, 0x3d3a, 0x4596, 0xa3, 0xbc, \
>> + 0xda, 0xd0, 0x0e, 0x67, 0x65, 0x6f)
>> +
>>  #define EFI_FDT_GUID \
>>  EFI_GUID(0xb1b621d5, 0xf19c, 0x41a5, \
>>   0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0)
>> @@ -1682,4 +1687,86 @@ struct efi_load_file_protocol {
>>  #define LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL_VENDOR_RANGE_MIN 0x1000
>>  #define LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL_VENDOR_RANGE_MAX 0x4000
>>
>> +/* Certificate types in signature database */
>> +#define EFI_CERT_SHA256_GUID \
>> +EFI_GUID(0xc1c41626, 0x504c, 0x4092, 0xac, 0xa9, \
>> + 0x41, 0xf9, 0x36, 0x93, 0x43, 0x28)
>> +#define EFI_CERT_RSA2048_GUID \
>> +EFI_GUID(0x3c5766e8, 0x269c, 0x4e34, 0xaa, 0x14, \
>> + 0xed, 0x77, 0x6e, 0x85, 0xb3, 0xb6)
>> +#define EFI_CERT_X509_GUID \
>> +EFI_GUID(0xa5c059a1, 0x94e4, 0x4aa7, 0x87, 0xb5, \
>> + 0xab, 0x15, 0x5c, 0x2b, 0xf0, 0x72)
>> +#define EFI_CERT_X509_SHA256_GUID \
>> +EFI_GUID(0x3bd2a492, 0x96c0, 0x4079, 0xb4, 0x20, \
>> + 0xfc, 0xf9, 0x8e, 0xf1, 0x03, 0xed)
>> +#define EFI_CERT_TYPE_PKCS7_GUID \
>> +EFI_GUID(0x4aafd29d, 0x68df, 0x49ee, 0x8a, 0xa9, \
>> + 0x34, 0x7d, 0x37, 0x56, 0x65, 0xa7)
>> +
>> +/**
>> + * win_certificate_uefi_guid - A certificate that encapsulates
>> + * a GUID-specific signature
>> + *
>> + * @hdr:Windows certificate header
>> + * @cert_type:  Certificate type
>> + * @cert_data:  Certificate data
>> + */
>> +struct win_certificate_uefi_guid {
>> +WIN_CERTIFICATE hdr;
>> +efi_guid_t  cert_type;
>> +u8  cert_data[];
>> +} __attribute__((__packed__));
>> +
>> +/**
>> + * efi_variable_authentication_2 - A time-based authentication method
>> + * descriptor
>> + *
>> + * This structure describes an authentication information for
>> + * a variable with EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS
>> + * and should be included as part of a variable's value.
>> + * Only EFI_CERT_TYPE_PKCS7_GUID is accepted.
>> + *
>> + * @time_stamp: Descriptor's time stamp
>> + * @auth_info:  Authentication info
>> + */
>> +struct efi_variable_authentication_2 {
>> +struct efi_time  time_stamp;
>> +struct win_certificate_uefi_guid auth_info;
>> +} __attribute__((__packed__));
>> +
>> +/**
>> + * efi_signature_data - A format of signature
>> + *
>> + * This structure describes a single signature in signature database.
>> + *
>> + * @signature_owner:Signature owner
>> + * @signature_data: Signature data
>> + */
>> +struct efi_signature_data {
>> +efi_guid_t  signature_owner;
>> +u8  signature_data[];
>> +} __attribute__((__packed__));
>> +
>> +/**
>> + * efi_signature_list - A format of signature database
>> + *
>> + * This structure describes a list of signatures with the same type.
>> + * An authenticated variable's value is a concatenation of one or more
>> + * efi_signature_list's.
>> + *
>> + * @signature_type: Signature type
>> + * @signature_list_size:Size of signature list
>> + * @signature_header_size:  Size of signature header
>> + * @signature_size: Size of signature
>> + */
>> +struct efi_signature_list {
>> +efi_guid_t  signature_type;
>> +u32 signature_list_size;
>> +u32 signature_header_size;
>> +u32 signature_size;
>> +/*  u8  signature_header[signature_header_size]; */
>> +/*  struct efi_signature_data signatures[...][signature_size]; */
>> +} __attribute__((__packed__));
>> +
>>  #endif
>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>> index 3f2792892f34..8cf85d2fb7e2 100644
>> --- a/include/efi_loader.h
>> +++ b/include/efi_loader.h
>> @@ -26,6 +26,7 @@ static inline void *guidcpy(void *dst, const void *src)
>>  #if CONFIG_IS_ENABLED(EFI_LOADER)

Re: [PATCH] tiny-printf: Support %i

[Marek Vasut]

On 4/14/20 4:41 PM, Simon Glass wrote:
> Hi Marek,
> 
> On Tue, 14 Apr 2020 at 07:41, Marek Vasut  wrote:
>>
>> On 4/14/20 3:26 PM, Tom Rini wrote:
>>> On Tue, Apr 14, 2020 at 02:24:18PM +0200, Marek Vasut wrote:
 On 4/14/20 5:03 AM, Tom Rini wrote:
> On Tue, Apr 14, 2020 at 03:17:16AM +0200, Marek Vasut wrote:
>> On 4/14/20 1:27 AM, Tom Rini wrote:
>>> On Fri, Apr 10, 2020 at 08:54:49PM +0200, Marek Vasut wrote:
>>>
 The most basic printf("%i", value) formating string was missing,
 add it for the sake of convenience.

 Signed-off-by: Marek Vasut 
 Cc: Simon Glass 
 Cc: Stefan Roese 
 ---
  lib/tiny-printf.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/lib/tiny-printf.c b/lib/tiny-printf.c
 index 1138c7012a..8fc7e48d99 100644
 --- a/lib/tiny-printf.c
 +++ b/lib/tiny-printf.c
 @@ -242,6 +242,7 @@ static int _vprintf(struct printf_info *info, 
 const char *fmt, va_list va)
  goto abort;
  case 'u':
  case 'd':
 +case 'i':
  div = 10;
  if (islong) {
  num = va_arg(va, unsigned 
 long);
 @@ -251,7 +252,7 @@ static int _vprintf(struct printf_info *info, 
 const char *fmt, va_list va)
  num = va_arg(va, unsigned 
 int);
  }

 -if (ch == 'd') {
 +if (ch != 'u') {
  if (islong && (long)num < 0) {
  num = -(long)num;
  out(info, '-');
>>>
>>> How much does the size change and where do we see this as a problem?
>>
>> Any code which uses %i in SPL just misbehaves, e.g.
>> printf("%s[%i] value=%x", __func__, __LINE__, val);
>> prints function name and then incorrect value, because %i is ignored.
>> This is also documented in the commit message.
>>
>> U-Boot grows in size massively due to all the DM/DT bloat which is being
>> forced upon everyone, but there the uncontrolled growth is apparently OK
>> even if it brings no obvious improvement, rather the opposite. And yet
>> here, size increase suddenly matters? Sorry, that's not right.
>>
>> The code grows by 6 bytes.
>
> Yes, it matters for _tiny-printf_ as that's where we have little to no
> room for growth.

 How many systems that use tiny-printf in SPL are also forced to use DM
 in SPL ?
>>>
>>> I don't know how many times I've said no one is forced to switch to DM
>>> in SPL.
>>
>> This is beside the point, there are boards which use SPL and DM, because
>> the non-DM drivers are steadily going away. So the growth in SPL size is
>> there, either directly or as a side-effect.
> 
> I think this is a good point. For serial we have a debug UART. I am
> think it would be useful to have a 'simple bypass' for more
> subsystems. For example, for I2C we could have a simple option to
> access a single I2C driver directly, bypassing driver model. Of course
> this is painful to do before we have completed I2C migration.

Right. Although it could be prototyped e.g. on the UART subssystem,
which is a good candidate.

Re: [PATCH] tiny-printf: Support %i

[Marek Vasut]

On 4/14/20 4:11 PM, Tom Rini wrote:
> On Tue, Apr 14, 2020 at 03:40:14PM +0200, Marek Vasut wrote:
>> On 4/14/20 3:26 PM, Tom Rini wrote:
>>> On Tue, Apr 14, 2020 at 02:24:18PM +0200, Marek Vasut wrote:
 On 4/14/20 5:03 AM, Tom Rini wrote:
> On Tue, Apr 14, 2020 at 03:17:16AM +0200, Marek Vasut wrote:
>> On 4/14/20 1:27 AM, Tom Rini wrote:
>>> On Fri, Apr 10, 2020 at 08:54:49PM +0200, Marek Vasut wrote:
>>>
 The most basic printf("%i", value) formating string was missing,
 add it for the sake of convenience.

 Signed-off-by: Marek Vasut 
 Cc: Simon Glass 
 Cc: Stefan Roese 
 ---
  lib/tiny-printf.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/lib/tiny-printf.c b/lib/tiny-printf.c
 index 1138c7012a..8fc7e48d99 100644
 --- a/lib/tiny-printf.c
 +++ b/lib/tiny-printf.c
 @@ -242,6 +242,7 @@ static int _vprintf(struct printf_info *info, 
 const char *fmt, va_list va)
goto abort;
case 'u':
case 'd':
 +  case 'i':
div = 10;
if (islong) {
num = va_arg(va, unsigned long);
 @@ -251,7 +252,7 @@ static int _vprintf(struct printf_info *info, 
 const char *fmt, va_list va)
num = va_arg(va, unsigned int);
}
  
 -  if (ch == 'd') {
 +  if (ch != 'u') {
if (islong && (long)num < 0) {
num = -(long)num;
out(info, '-');
>>>
>>> How much does the size change and where do we see this as a problem?
>>
>> Any code which uses %i in SPL just misbehaves, e.g.
>> printf("%s[%i] value=%x", __func__, __LINE__, val);
>> prints function name and then incorrect value, because %i is ignored.
>> This is also documented in the commit message.
>>
>> U-Boot grows in size massively due to all the DM/DT bloat which is being
>> forced upon everyone, but there the uncontrolled growth is apparently OK
>> even if it brings no obvious improvement, rather the opposite. And yet
>> here, size increase suddenly matters? Sorry, that's not right.
>>
>> The code grows by 6 bytes.
>
> Yes, it matters for _tiny-printf_ as that's where we have little to no
> room for growth.

 How many systems that use tiny-printf in SPL are also forced to use DM
 in SPL ?
>>>
>>> I don't know how many times I've said no one is forced to switch to DM
>>> in SPL.
>>
>> This is beside the point, there are boards which use SPL and DM, because
>> the non-DM drivers are steadily going away. So the growth in SPL size is
>> there, either directly or as a side-effect.
>>
> So it's just debug prints you were doing that ran in
> to a problem?  Thanks!

 git grep %i indicates ~400 sites where %i is used, so no, not just debug
 prints. All of those are broken. And no, I'm not inclined to patch all
 the code to use %d instead of %i just because handling %i is a problem.
>>>
>>> Not all 400 of them but the ones that are expected to be used in SPL and
>>> with TINY_PRINTF need to, yes.  Go look at the git log of tiny-printf.c,
>>> we've changed things around to avoid growth when at all possible.
>>
>> I appreciate that. However, I would also appreciate if printf() behaved
>> in a sane manner, and missing %i support is really weird.
>>
>>> Because yes, I don't want to grow a few hundred boards by 6 bytes when
>>> we have a reasonable alternative.  There's 300 hits, of which a dozen
>>> are non-debug and likely to ever be in SPL code.
>>
>> Why don't we instead replace %d with %i altogether then ? The %d seems
>> to be seldom used outside of U-Boot, where it is only used because of
>> this tiny-printf limitation, while %i is used quite often.
>>
>>> And no, this isn't the
>>> first time I've raised such an issue, it's just the first time you've
>>> been hit by this, sorry.
>>
>> Does this therefore set a precedent that we are allowed to block any and
>> all patches which grow SPL size, no matter how useful they might be ?
> 
> This is following the precedent that was set for tiny printf a while ago
> with some other "it would be nice if..." format that could instead be
> handled differently, again for the case of tiny printf.  It is not
> supposed to cover everything, or most things.  It is supposed to let
> SPL/TPL still have printf in otherwise very tight situations.

Except the way it is right now, a lot of output is 

Re: [PATCH v2 21/22] Use __ASSEMBLY__ as the assembly macros

[Simon Goldschmidt]

Masahiro Yamada  schrieb am Di., 14. Apr. 2020, 17:34:

> Hi Simon,
>
> On Tue, Apr 14, 2020 at 11:41 PM Simon Glass  wrote:
> >
> > Hi Masahiro,
> >
> > On Mon, 13 Apr 2020 at 11:10, Masahiro Yamada 
> wrote:
> > >
> > > On Fri, Apr 10, 2020 at 5:18 AM Simon Glass  wrote:
> > > >
> > > > Some places use __ASSEMBLER__ instead which does not work since the
> > > > Makefile does not define it. Fix them.
> > >
> > >
> > > In my understanding,
> > > __ASSEMBLER__ is passed by the compiler
> > > while building *.S files.
> > >
> > > On which compiler didn't this work for you?
> > >
> > >
> > >
> > >
> > > >
> > > > Signed-off-by: Simon Glass 
> > > > ---
> > > >
> > > > Changes in v2:
> > > > - Add new patch to fix occurances of __ASSEMBLER__
> > > >
> >
> > I think I hit this with device tree, but I would need to go back and
> > check. Anyway I think we should be consistent.
>
>
> DT files are pre-processed with  '-x assembler-with-cpp'.
>
> So, __ASSEMBLER__ is pre-defined by the compiler.
>

I have just seen this thread now. It touches socfpga headers but we're not
in CC (possibly the maintainers file needs updating).

Anyway, why do we have 2 defines for assembler? If one is predefined by the
compiler, why don't we use that? Can you explain that for someone not too
deeply involved?

Regards,
Simon


> You can easily confirm it by dumping the
> compiler's pre-defined macros.
>
>
>
> $ gcc -dM -E  - < /dev/null  | grep __ASSEMBLER__
> $ gcc -dM -E -x assembler-with-cpp - < /dev/null  | grep __ASSEMBLER__
> #define __ASSEMBLER__ 1
>
>
>
>
> Since the following commit, DT started including U-Boot headers.
> This project is progressively going strange.  :-/
>
>
> commit b116aff27c56dbc9132d847f7134eb7e4cc26aa3
> Author: Simon Glass 
> Date:   Fri Nov 25 20:15:58 2016 -0700
>
> binman: Allow configuration options to be used in .dts files
>
>
>
>
>
> --
> Best Regards
> Masahiro Yamada
>

Re: [PATCH v2 21/22] Use __ASSEMBLY__ as the assembly macros

[Tom Rini]

On Tue, Apr 14, 2020 at 10:38:47PM +0200, Simon Goldschmidt wrote:
> Masahiro Yamada  schrieb am Di., 14. Apr. 2020, 17:34:
> 
> > Hi Simon,
> >
> > On Tue, Apr 14, 2020 at 11:41 PM Simon Glass  wrote:
> > >
> > > Hi Masahiro,
> > >
> > > On Mon, 13 Apr 2020 at 11:10, Masahiro Yamada 
> > wrote:
> > > >
> > > > On Fri, Apr 10, 2020 at 5:18 AM Simon Glass  wrote:
> > > > >
> > > > > Some places use __ASSEMBLER__ instead which does not work since the
> > > > > Makefile does not define it. Fix them.
> > > >
> > > >
> > > > In my understanding,
> > > > __ASSEMBLER__ is passed by the compiler
> > > > while building *.S files.
> > > >
> > > > On which compiler didn't this work for you?
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > Signed-off-by: Simon Glass 
> > > > > ---
> > > > >
> > > > > Changes in v2:
> > > > > - Add new patch to fix occurances of __ASSEMBLER__
> > > > >
> > >
> > > I think I hit this with device tree, but I would need to go back and
> > > check. Anyway I think we should be consistent.
> >
> >
> > DT files are pre-processed with  '-x assembler-with-cpp'.
> >
> > So, __ASSEMBLER__ is pre-defined by the compiler.
> >
> 
> I have just seen this thread now. It touches socfpga headers but we're not
> in CC (possibly the maintainers file needs updating).
> 
> Anyway, why do we have 2 defines for assembler? If one is predefined by the
> compiler, why don't we use that? Can you explain that for someone not too
> deeply involved?

Generally and broadly speaking, the assembler will set __ASSEMBLER__.
That said, the Linux kernel has been setting __ASSEMBLY__ for
practically forever and we've copied that behavior also practically for
forever.  In both trees there are a handful of __ASSEMBLER__ tests and a
vast majority of __ASSEMBLY__ tests.  It doesn't normally matter which
is used as the only non-compiler in the Linux kernel that might care is
handled as shown above.  Under the assumption that the feature
Yamada-san pointed out in binman is used, it should also define
__ASSEMBLER__ I believe, to match other tooling.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] Revert "riscv: qemu: clear kernel-start/-end in device tree as workaround for BBL"

[Lukas Auer]

The commit was added as a workaround required in QEMU when using BBL as
the supervisor binary interface (SBI) for Linux. We are now using
OpenSBI to provide the SBI, the workaround is therefore not required
anymore and can be removed.

This reverts commit 897206c5cc5c6ac0dc2ab851044e42baada3785b.

Signed-off-by: Lukas Auer 
---

 board/emulation/qemu-riscv/Kconfig  |  1 -
 board/emulation/qemu-riscv/qemu-riscv.c | 39 -
 2 files changed, 40 deletions(-)

diff --git a/board/emulation/qemu-riscv/Kconfig 
b/board/emulation/qemu-riscv/Kconfig
index 7ce12018e7..ad99b08b44 100644
--- a/board/emulation/qemu-riscv/Kconfig
+++ b/board/emulation/qemu-riscv/Kconfig
@@ -43,7 +43,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply CMD_EXT4
imply CMD_FAT
imply BOARD_LATE_INIT
-   imply OF_BOARD_SETUP
imply SIFIVE_SERIAL
imply SMP
imply PCI
diff --git a/board/emulation/qemu-riscv/qemu-riscv.c 
b/board/emulation/qemu-riscv/qemu-riscv.c
index cbce5ffe6e..c3f96988b1 100644
--- a/board/emulation/qemu-riscv/qemu-riscv.c
+++ b/board/emulation/qemu-riscv/qemu-riscv.c
@@ -52,45 +52,6 @@ int board_late_init(void)
return 0;
 }
 
-/*
- * QEMU specifies the location of Linux (supplied with the -kernel argument)
- * in the device tree using the riscv,kernel-start and riscv,kernel-end
- * properties. We currently rely on the SBI implementation of BBL to run
- * Linux and therefore embed Linux as payload in BBL. This causes an issue,
- * because BBL detects the kernel properties in the device tree and ignores
- * the Linux payload as a result. To work around this issue, we clear the
- * kernel properties before booting Linux.
- *
- * This workaround can be removed, once we do not require BBL for its SBI
- * implementation anymore.
- */
-int ft_board_setup(void *blob, bd_t *bd)
-{
-   int chosen_offset, ret;
-
-   chosen_offset = fdt_path_offset(blob, "/chosen");
-   if (chosen_offset < 0)
-   return 0;
-
-#ifdef CONFIG_ARCH_RV64I
-   ret = fdt_setprop_u64(blob, chosen_offset, "riscv,kernel-start", 0);
-#else
-   ret = fdt_setprop_u32(blob, chosen_offset, "riscv,kernel-start", 0);
-#endif
-   if (ret)
-   return ret;
-
-#ifdef CONFIG_ARCH_RV64I
-   ret = fdt_setprop_u64(blob, chosen_offset, "riscv,kernel-end", 0);
-#else
-   ret = fdt_setprop_u32(blob, chosen_offset, "riscv,kernel-end", 0);
-#endif
-   if (ret)
-   return ret;
-
-   return 0;
-}
-
 #ifdef CONFIG_SPL
 u32 spl_boot_device(void)
 {
-- 
2.25.2

Re: [PATCH v2 2/2] efi_loader: identify EFI system partition

[AKASHI Takahiro]

Heinrich,

On Tue, Apr 14, 2020 at 09:41:51AM +0200, Heinrich Schuchardt wrote:
> On 2020-04-14 08:12, AKASHI Takahiro wrote:
> > On Tue, Apr 14, 2020 at 05:53:43AM +, Heinrich Schuchardt wrote:
> >> Am April 14, 2020 5:20:38 AM UTC schrieb AKASHI Takahiro 
> >> :
> >>> Heinrich,
> >>>
> >>> On Mon, Apr 06, 2020 at 02:31:35PM +0900, AKASHI Takahiro wrote:
>  On Mon, Apr 06, 2020 at 07:12:56AM +0200, Heinrich Schuchardt wrote:
> > On 4/6/20 6:21 AM, AKASHI Takahiro wrote:
> >> Heinrich,
> >>
> >> On Sun, Apr 05, 2020 at 11:28:18AM +0200, Heinrich Schuchardt
> >>> wrote:
> >>> For capsule updates we need to identify the EFI system
> >>> partition.
> >>
> >> Right, but
> >>
> >>> Signed-off-by: Heinrich Schuchardt 
> >>> ---
> >>> v2:
> >>>   no change
> >>> ---
> >>>  include/efi_loader.h  |  7 +++
> >>>  lib/efi_loader/efi_disk.c | 20 
> >>>  2 files changed, 27 insertions(+)
> >>>
> >>> diff --git a/include/efi_loader.h b/include/efi_loader.h
> >>> index 3f2792892f..4a45033476 100644
> >>> --- a/include/efi_loader.h
> >>> +++ b/include/efi_loader.h
> >>> @@ -45,6 +45,13 @@ static inline void *guidcpy(void *dst, const
> >>> void *src)
> >>>  /* Root node */
> >>>  extern efi_handle_t efi_root;
> >>>
> >>> +/* EFI system partition */
> >>> +extern struct efi_system_partition {
> >>> + enum if_type if_type;
> >>> + int devnum;
> >>> + u8 part;
> >>> +} efi_system_partition;
> >>> +
> >>>  int __efi_entry_check(void);
> >>>  int __efi_exit_check(void);
> >>>  const char *__efi_nesting(void);
> >>> diff --git a/lib/efi_loader/efi_disk.c
> >>> b/lib/efi_loader/efi_disk.c
> >>> index fc0682bc48..2f752a5e99 100644
> >>> --- a/lib/efi_loader/efi_disk.c
> >>> +++ b/lib/efi_loader/efi_disk.c
> >>> @@ -13,6 +13,8 @@
> >>>  #include 
> >>>  #include 
> >>>
> >>> +struct efi_system_partition efi_system_partition;
> >>> +
> >>>  const efi_guid_t efi_block_io_guid =
> >>> EFI_BLOCK_IO_PROTOCOL_GUID;
> >>>
> >>>  /**
> >>> @@ -372,6 +374,24 @@ static efi_status_t efi_disk_add_dev(
> >>>   diskobj->ops.media = &diskobj->media;
> >>>   if (disk)
> >>>   *disk = diskobj;
> >>> +
> >>> + /* Store first EFI system partition */
> >>
> >> I don't think that the policy, first comes first serves as system
> >> partition, is a right decision as
> >> - the order of device probe on U-Boot is indeterministic, and
> >
> > Indeterministic would mean that on two runs with the same media
> >>> provided
> > you will get different results. I cannot see any source for such
> > randomness in the U-Boot code. In dm_init_and_scan() the device
> >>> tree is
> > scanned and drivers and bound in the sequence of occurrence in the
> > device tree.
> >
> >> - there can be several partitions that hold a system partition
> >>> bit.
> >>   You may have OS installed on eMMC, but also may have bootable
> >>> DVD
> >>   on the system.
> >
> > This is a similar logic like finding the relevant boot.scr script
> >>> to run.
> >
> > What would be the alternative?
> 
>  I think that most UEFI systems have ability for user to specify
>  "boot order."
> >>>
> >>> Any comment?
> >>> The discussion and your patch will have some impact on
> >>> my efi capsule patch.
> >>
> >> Concerning capsules the spec says we should use the boot device. So my 
> >> patch doesn't help you there.
> >
> > Your commit message says,
> >   "For capsule updates we need to identify the EFI system partition."
> >
> > and then I made some counter comment.
> > So now you agreed with my comment, don't you?
> > (I need to confirm this to work on capsule patch.)
> 
> You can stick to your original design.

Thanks

> >
> >> For the storage of variables I still need this patch. I will adjust the 
> >> commit message.
> >
> > Even in this case, I believe that the first device detected in your logic
> > is not always a "valid" device for your purpose.
> 
> Do you have a better suggestion?

The root cause would be that there is no notion of "boot device"
in U-Boot. So I would suggest
1) we should add Kconfig option to specify it
just as we do for U-Boot environment (variables), and then
check if the partition has a system partition bit at boot time.
2) you would follow the similar way as I do in capsule support.
or
3) you would first examine what EDK2 does in this respect.

-Takahiro Akashi


> Best regards
> 
> Heinrich
> 
> >
> > -Takahiro Akashi
> >
> >>
> >> Best regards
> >>
> >> Heinrich
> >>
> >>>
> >>> -Takahiro Akashi
> >>>
>  -Takahiro Akashi
> >
> > Definition via Kconfig would mean that a Linux distribution like
> >>> Debian
> > would have to provide a separate U-Boot build for each boot medium
> >>> th

[PATCH u-boot-marvell 1/1] clk: armada-37xx-periph: fix DDR PHY clock divider values

[Marek Behún]

Register value table for DDR PHY clock divider are wrong. They should be
0 or 1 for divide-by-2 or divide-by-4, respectively. Not 1 or 2. Current
values do not make sense, since 2 cannot be achieved, because the
register is only 1 bit long (mask is set to 1).

This fixes clk dump reporting DDR PHY clock rate differently from Linux.

Signed-off-by: Marek Behún 
---
 drivers/clk/mvebu/armada-37xx-periph.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/mvebu/armada-37xx-periph.c 
b/drivers/clk/mvebu/armada-37xx-periph.c
index 068e48ea04..855f979b4f 100644
--- a/drivers/clk/mvebu/armada-37xx-periph.c
+++ b/drivers/clk/mvebu/armada-37xx-periph.c
@@ -89,8 +89,8 @@ static const struct clk_div_table div_table1[] = {
 };
 
 static const struct clk_div_table div_table2[] = {
-   { 2, 1 },
-   { 4, 2 },
+   { 2, 0 },
+   { 4, 1 },
{ 0, 0 },
 };
 
-- 
2.24.1

Re: [PATCH] tiny-printf: Support %i

[Tom Rini]

On Tue, Apr 14, 2020 at 05:22:19PM +0200, Marek Vasut wrote:
> On 4/14/20 4:11 PM, Tom Rini wrote:
> > On Tue, Apr 14, 2020 at 03:40:14PM +0200, Marek Vasut wrote:
> >> On 4/14/20 3:26 PM, Tom Rini wrote:
> >>> On Tue, Apr 14, 2020 at 02:24:18PM +0200, Marek Vasut wrote:
>  On 4/14/20 5:03 AM, Tom Rini wrote:
> > On Tue, Apr 14, 2020 at 03:17:16AM +0200, Marek Vasut wrote:
> >> On 4/14/20 1:27 AM, Tom Rini wrote:
> >>> On Fri, Apr 10, 2020 at 08:54:49PM +0200, Marek Vasut wrote:
> >>>
>  The most basic printf("%i", value) formating string was missing,
>  add it for the sake of convenience.
> 
>  Signed-off-by: Marek Vasut 
>  Cc: Simon Glass 
>  Cc: Stefan Roese 
>  ---
>   lib/tiny-printf.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
>  diff --git a/lib/tiny-printf.c b/lib/tiny-printf.c
>  index 1138c7012a..8fc7e48d99 100644
>  --- a/lib/tiny-printf.c
>  +++ b/lib/tiny-printf.c
>  @@ -242,6 +242,7 @@ static int _vprintf(struct printf_info *info, 
>  const char *fmt, va_list va)
>   goto abort;
>   case 'u':
>   case 'd':
>  +case 'i':
>   div = 10;
>   if (islong) {
>   num = va_arg(va, unsigned long);
>  @@ -251,7 +252,7 @@ static int _vprintf(struct printf_info *info, 
>  const char *fmt, va_list va)
>   num = va_arg(va, unsigned int);
>   }
>   
>  -if (ch == 'd') {
>  +if (ch != 'u') {
>   if (islong && (long)num < 0) {
>   num = -(long)num;
>   out(info, '-');
> >>>
> >>> How much does the size change and where do we see this as a problem?
> >>
> >> Any code which uses %i in SPL just misbehaves, e.g.
> >> printf("%s[%i] value=%x", __func__, __LINE__, val);
> >> prints function name and then incorrect value, because %i is ignored.
> >> This is also documented in the commit message.
> >>
> >> U-Boot grows in size massively due to all the DM/DT bloat which is 
> >> being
> >> forced upon everyone, but there the uncontrolled growth is apparently 
> >> OK
> >> even if it brings no obvious improvement, rather the opposite. And yet
> >> here, size increase suddenly matters? Sorry, that's not right.
> >>
> >> The code grows by 6 bytes.
> >
> > Yes, it matters for _tiny-printf_ as that's where we have little to no
> > room for growth.
> 
>  How many systems that use tiny-printf in SPL are also forced to use DM
>  in SPL ?
> >>>
> >>> I don't know how many times I've said no one is forced to switch to DM
> >>> in SPL.
> >>
> >> This is beside the point, there are boards which use SPL and DM, because
> >> the non-DM drivers are steadily going away. So the growth in SPL size is
> >> there, either directly or as a side-effect.
> >>
> > So it's just debug prints you were doing that ran in
> > to a problem?  Thanks!
> 
>  git grep %i indicates ~400 sites where %i is used, so no, not just debug
>  prints. All of those are broken. And no, I'm not inclined to patch all
>  the code to use %d instead of %i just because handling %i is a problem.
> >>>
> >>> Not all 400 of them but the ones that are expected to be used in SPL and
> >>> with TINY_PRINTF need to, yes.  Go look at the git log of tiny-printf.c,
> >>> we've changed things around to avoid growth when at all possible.
> >>
> >> I appreciate that. However, I would also appreciate if printf() behaved
> >> in a sane manner, and missing %i support is really weird.
> >>
> >>> Because yes, I don't want to grow a few hundred boards by 6 bytes when
> >>> we have a reasonable alternative.  There's 300 hits, of which a dozen
> >>> are non-debug and likely to ever be in SPL code.
> >>
> >> Why don't we instead replace %d with %i altogether then ? The %d seems
> >> to be seldom used outside of U-Boot, where it is only used because of
> >> this tiny-printf limitation, while %i is used quite often.
> >>
> >>> And no, this isn't the
> >>> first time I've raised such an issue, it's just the first time you've
> >>> been hit by this, sorry.
> >>
> >> Does this therefore set a precedent that we are allowed to block any and
> >> all patches which grow SPL size, no matter how useful they might be ?
> > 
> > This is following the precedent that was set for tiny printf a while ago
> > with some other "it would be nice if..." format that could instead be
>

Re: [PATCH v5 0/6] RISC-V DT related fixes for reserved memory & UEFI

[Atish Patra]

On Mon, Apr 13, 2020 at 3:42 PM Bin Meng  wrote:
>
> Hi Atish,
>
> On Tue, Apr 14, 2020 at 6:02 AM Atish Patra  wrote:
> >
> > On Tue, Apr 7, 2020 at 10:35 AM Atish Patra  wrote:
> > >
> > > On Mon, Apr 6, 2020 at 11:51 PM Ard Biesheuvel
> > >  wrote:
> > > >
> > > > On Tue, 7 Apr 2020 at 08:46, Heinrich Schuchardt  
> > > > wrote:
> > > > >
> > > > > On 4/6/20 11:01 PM, Ard Biesheuvel wrote:
> > > > > > On Mon, 6 Apr 2020 at 22:45, Atish Patra  
> > > > > > wrote:
> > > > > >>
> > > > > >> This series adds few DT related fixes required for Linux EFI stub 
> > > > > >> to work
> > > > > >> on RISC-V.
> > > > > >>
> > > > > >
> > > > > > I'm not sure how this is supposed to work, since DT reserved memory
> > > > > > regions are not used by EFI. If you want to reserve memory on a UEFI
> > > > > > system, you have to reserve it in the UEFI memory map from firmware.
> > > > > > The DT reserved-memory node is taken into account too late, the
> > > > > > /memreserve/ entries are ignored entirely.
> > > > >
> > > > > Hello Ard,
> > > > >
> > > > > thanks for reviewing.
> > > > >
> > > > > What do you mean by "The DT reserved-memory node is taken into account
> > > > > too late"?
> > > > >
> > > > > Cf. commit 7be64b885a36 ("cmd: bootefi: Parse reserved-memory node 
> > > > > from DT")
> > > > >
> > > >
> > > > What I mean is that the EFI stub in Linux uses memory allocation
> > > > functions, expecting the firmware to ensure that those allocations do
> > > > not conflict with memory descriptions and reservations in DT. So if
> > > > the firmware wants to express this redundantly, by passing
> > > > reservations in both reserved-memory and in the EFI memory map, that
> > > > is probably fine.
> > > >
> > > > Also, I must sheepishly admit that I only realize now that this patch
> > > > set is against u-boot not Linux :-)
> > > >
> > > :)
> > >
> > > > So if fixed reserved-memory regions are only being used to seed the
> > > > reserved regions in the EFI memory map, you can safely ignore me.
> > >
> > > Yeah. That's the purpose. Having reserved memory nodes in the final DT
> > > used by linux
> > > also ensures that proper Linux adds a reserved memory block or removes
> > > it from memblock
> > > entries depending on "no-map" property.
> > >
> > > > Apologies for the noise.
> > >
> > >
> > >
> > > --
> > > Regards,
> > > Atish
> >
> > Any other comments on the series ? It would be great if this series
> > could be merged before
> > v2020.07 release.
>
> I hope so if no one objects the proposed solution here in U-Boot vs.
> the PMP SBI extension. I need have another look at the latest version
> of patches though.
>

Thanks. As far as I know, there is no opposition to the current
approach adopted in U-Boot.
I am hoping EFI stub series can be merged before 5.8. If this series
can go in v2020.07,
RISC-V will have all required support to boot via EFI from Linux
kernel v5.8 and U-Boot v2020.07.

> Regards,
> Bin



-- 
Regards,
Atish

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

[Tom Rini]

On Mon, Apr 13, 2020 at 10:02:53PM +0200, Marek Vasut wrote:

> The following changes since commit 995972ddbbcc5fccd324ab384bca9af90e710755:
> 
>   Merge tag 'dm-pull9apr20' of git://git.denx.de/u-boot-dm (2020-04-10
> 11:40:28 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-socfpga.git master
> 
> for you to fetch changes up to 3958ef307e09a28ce649dd7d6e0cb398996dcaa5:
> 
>   arm: socfpga: arria10: Enable cache driver in SPL (2020-04-13 13:49:51
> +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

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

[Tom Rini]

On Mon, Apr 13, 2020 at 10:02:22PM +0200, Marek Vasut wrote:

> The following changes since commit 995972ddbbcc5fccd324ab384bca9af90e710755:
> 
>   Merge tag 'dm-pull9apr20' of git://git.denx.de/u-boot-dm (2020-04-10
> 11:40:28 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to 9cadf059589c8fd18b58b35d6b99489f2fd0bd3e:
> 
>   drivers: usb: host: Add BRCM xHCI driver (2020-04-13 13:48:41 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: Please pull u-boot-marvell/master

[Tom Rini]

On Tue, Apr 14, 2020 at 01:28:41PM +0200, Stefan Roese wrote:

> Hi Tom,
> 
> please pull the first batch of MVEBU related patches in this merge
> window. The major changes are:
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: latest u-boot branch for Marvell Armada 88F3720

[Marek Behun]

Hi Moritz,

could you please compile and test current u-boot master on your
EspressoBin? My patches regarding DDR size determination on A3700 were
applied and I would like to know if it works correctly for you.

Marek

On Mon, 6 Apr 2020 09:43:27 +
Moritz Berghof  wrote:

> Hi Marek,
> 
> we use the ESPRESSObin Version V5_0_1. We have 2GB-DDR3 memory size and two 
> chips. On of the one side and the other chip directly on the other side of 
> the board.
> 
> Have a good day,
> 
> --
> Moritz Berghof
> Software Engineer
> Tel. +49 30 921028-209
> Fax +49 30 921028-020
> mberg...@phoenixcontact.com
> www.phoenixcontact.com
> 
> PHOENIX CONTACT Cyber Security GmbH
> Richard-Willstätter-Straße 6
> D-12489 Berlin
> Register Court: AG Charlottenburg, HR B 202908
> Geschäftsführer/General Manager: Kilian Golm
> 
> Hi Moritz,
> 
> which version of EspressoBin do you have? How much RAM, is it DDR3 or
> DDR4? How many RAM chips are there?
> 
> Marek
> 
> 
> 
> ...
> PHOENIX CONTACT Cyber Security GmbH 
> Richard-Willstätter-Straße 6  
> D-12489 Berlin  
>  
> Register Court: AG Charlottenburg, HR B 202908 
> Geschäftsführer/General Manager: Kilian Golm

Re: [PATCH v7 16/17] travis: add packages for UEFI secure boot test

[AKASHI Takahiro]

Heinrich,

On Tue, Apr 14, 2020 at 05:33:18PM +0200, Heinrich Schuchardt wrote:
> On 2020-04-14 04:51, AKASHI Takahiro wrote:
> > Pytest for UEFI secure boot will use several host commands.
> > In particular, Test setup relies on efitools, whose version must be v1.5.2
> > or later. So fetch a new version of deb package directly.
> > Please note it has a dependency on mtools, which must also be installed
> > along wih efitools.
> >
> > In addition, the path, '/sbin', is added to PATH for use of sgdisk and
> > mkfs.
> >
> > Signed-off-by: AKASHI Takahiro 
> > Reviewed-by: Tom Rini 
> > ---
> >  .travis.yml | 11 ++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/.travis.yml b/.travis.yml
> > index c59bd7790b66..b08dd030ef02 100644
> > --- a/.travis.yml
> > +++ b/.travis.yml
> > @@ -40,6 +40,14 @@ addons:
> >  - clang-7
> >  - srecord
> >  - graphviz
> > +- coreutils
> > +- util-linux
> > +- dosfstools
> > +- gdisk
> > +- mount
> > +- mtools
> > +- openssl
> > +- sbsigntool
> >
> >  install:
> >   # Clone uboot-test-hooks
> > @@ -60,10 +68,11 @@ install:
> >   - mkdir ~/grub2-arm64
> >   - ( cd ~/grub2-arm64; wget -O - 
> > http://download.opensuse.org/ports/aarch64/distribution/leap/42.2/repo/oss/suse/aarch64/grub2-arm64-efi-2.02~beta2-87.1.aarch64.rpm
> >  | rpm2cpio | cpio -di )
> >   - wget 
> > http://mirrors.kernel.org/ubuntu/pool/main/m/mpfr4/libmpfr4_3.1.4-1_amd64.deb
> >  && sudo dpkg -i libmpfr4_3.1.4-1_amd64.deb && rm libmpfr4_3.1.4-1_amd64.deb
> > + - wget 
> > http://mirrors.kernel.org/ubuntu/pool/universe/e/efitools/efitools_1.8.1-0ubuntu2_amd64.deb
> >  && sudo dpkg -i efitools_1.8.1-0ubuntu2_amd64.deb && rm 
> > efitools_1.8.1-0ubuntu2_amd64.deb
> 
> Don't we need changes in the Gitlab CI and Azure CI configurations as well?

I think that this is a repeated question.
Please see Tom's reply in [1].

[1] https://lists.denx.de/pipermail/u-boot/2020-February/401424.html

Thanks,
-Takahiro Akashi

> 
> Best regards
> 
> Heinrich
> 
> >
> >  env:
> >global:
> > -- 
> > PATH=/tmp/qemu-install/bin:/tmp/uboot-test-hooks/bin:/usr/bin:/bin:/usr/local/bin
> > +- 
> > PATH=/tmp/qemu-install/bin:/tmp/uboot-test-hooks/bin:/sbin:/usr/bin:/bin:/usr/local/bin
> >  - PYTHONPATH=/tmp/uboot-test-hooks/py/travis-ci
> >  - BUILD_DIR=build
> >  - HOSTCC="cc"
> >
> 

Re: [PATCH] tiny-printf: Support %i

[Simon Glass]

Hi Marek,

On Tue, 14 Apr 2020 at 10:32, Marek Vasut  wrote:
>
> On 4/14/20 4:41 PM, Simon Glass wrote:
> > Hi Marek,
> >
> > On Tue, 14 Apr 2020 at 07:41, Marek Vasut  wrote:
> >>
> >> On 4/14/20 3:26 PM, Tom Rini wrote:
> >>> On Tue, Apr 14, 2020 at 02:24:18PM +0200, Marek Vasut wrote:
>  On 4/14/20 5:03 AM, Tom Rini wrote:
> > On Tue, Apr 14, 2020 at 03:17:16AM +0200, Marek Vasut wrote:
> >> On 4/14/20 1:27 AM, Tom Rini wrote:
> >>> On Fri, Apr 10, 2020 at 08:54:49PM +0200, Marek Vasut wrote:
> >>>
>  The most basic printf("%i", value) formating string was missing,
>  add it for the sake of convenience.
> 
>  Signed-off-by: Marek Vasut 
>  Cc: Simon Glass 
>  Cc: Stefan Roese 
>  ---
>   lib/tiny-printf.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
>  diff --git a/lib/tiny-printf.c b/lib/tiny-printf.c
>  index 1138c7012a..8fc7e48d99 100644
>  --- a/lib/tiny-printf.c
>  +++ b/lib/tiny-printf.c
>  @@ -242,6 +242,7 @@ static int _vprintf(struct printf_info *info, 
>  const char *fmt, va_list va)
>   goto abort;
>   case 'u':
>   case 'd':
>  +case 'i':
>   div = 10;
>   if (islong) {
>   num = va_arg(va, unsigned 
>  long);
>  @@ -251,7 +252,7 @@ static int _vprintf(struct printf_info *info, 
>  const char *fmt, va_list va)
>   num = va_arg(va, unsigned 
>  int);
>   }
> 
>  -if (ch == 'd') {
>  +if (ch != 'u') {
>   if (islong && (long)num < 
>  0) {
>   num = -(long)num;
>   out(info, '-');
> >>>
> >>> How much does the size change and where do we see this as a problem?
> >>
> >> Any code which uses %i in SPL just misbehaves, e.g.
> >> printf("%s[%i] value=%x", __func__, __LINE__, val);
> >> prints function name and then incorrect value, because %i is ignored.
> >> This is also documented in the commit message.
> >>
> >> U-Boot grows in size massively due to all the DM/DT bloat which is 
> >> being
> >> forced upon everyone, but there the uncontrolled growth is apparently 
> >> OK
> >> even if it brings no obvious improvement, rather the opposite. And yet
> >> here, size increase suddenly matters? Sorry, that's not right.
> >>
> >> The code grows by 6 bytes.
> >
> > Yes, it matters for _tiny-printf_ as that's where we have little to no
> > room for growth.
> 
>  How many systems that use tiny-printf in SPL are also forced to use DM
>  in SPL ?
> >>>
> >>> I don't know how many times I've said no one is forced to switch to DM
> >>> in SPL.
> >>
> >> This is beside the point, there are boards which use SPL and DM, because
> >> the non-DM drivers are steadily going away. So the growth in SPL size is
> >> there, either directly or as a side-effect.
> >
> > I think this is a good point. For serial we have a debug UART. I am
> > think it would be useful to have a 'simple bypass' for more
> > subsystems. For example, for I2C we could have a simple option to
> > access a single I2C driver directly, bypassing driver model. Of course
> > this is painful to do before we have completed I2C migration.
>
> Right. Although it could be prototyped e.g. on the UART subssystem,
> which is a good candidate.

Yes it is on my mind, once i get my lab working properly. Will have a
think about it...

Regards,
Simon

Re: [PATCH] fvp: Add support for loading Android boot images via semihosting

[Tom Rini]

On Tue, Apr 14, 2020 at 10:11:06AM -0700, Peter Collingbourne wrote:
> On Mon, Apr 6, 2020 at 11:30 AM Ryan Harkin  wrote:
> 
> >
> > On Mon, 6 Apr 2020 at 19:25, Peter Collingbourne  wrote:
> >
> >> On Mon, Apr 6, 2020 at 10:40 AM Ryan Harkin 
> >> wrote:
> >>
> >>> Hi Peter,
> >>>
> >>> This looks good to me, but I have a quick question below.
> >>>
> >>> On Sat, 4 Apr 2020 at 03:58, Peter Collingbourne  wrote:
> >>>
>  FVP now loads an Android boot image named boot.img if available,
>  otherwise it falls back to the existing code path.
> 
>  Signed-off-by: Peter Collingbourne 
>  ---
>   configs/vexpress_aemv8a_semi_defconfig |  2 ++
>   include/configs/vexpress_aemv8a.h  | 30 +-
>   2 files changed, 22 insertions(+), 10 deletions(-)
> 
>  diff --git a/configs/vexpress_aemv8a_semi_defconfig
>  b/configs/vexpress_aemv8a_semi_defconfig
>  index f31baab197..b52c761dee 100644
>  --- a/configs/vexpress_aemv8a_semi_defconfig
>  +++ b/configs/vexpress_aemv8a_semi_defconfig
>  @@ -14,6 +14,8 @@ CONFIG_BOOTARGS="console=ttyAMA0
>  earlycon=pl011,0x1c09 debug user_debug=31 l
>   # CONFIG_DISPLAY_CPUINFO is not set
>   # CONFIG_DISPLAY_BOARDINFO is not set
>   CONFIG_SYS_PROMPT="VExpress64# "
>  +CONFIG_ANDROID_BOOT_IMAGE=y
>  +CONFIG_CMD_ABOOTIMG=y
>   # CONFIG_CMD_CONSOLE is not set
>   # CONFIG_CMD_XIMG is not set
>   # CONFIG_CMD_EDITENV is not set
>  diff --git a/include/configs/vexpress_aemv8a.h
>  b/include/configs/vexpress_aemv8a.h
>  index 9a9cec414c..4f3a792f49 100644
>  --- a/include/configs/vexpress_aemv8a.h
>  +++ b/include/configs/vexpress_aemv8a.h
>  @@ -177,16 +177,26 @@
>  "initrd_addr=0x8800\0"  \
>  "fdtfile=devtree.dtb\0" \
>  "fdt_addr=0x8300\0" \
>  -   "fdt_high=0x\0" \
>  -   "initrd_high=0x\0"
> 
> >>>
> >>> Why did you move these two inside the 'if' statement below? Is it
> >>> because you explicitly don't want them set when booting Android?
> >>>
> >>
> >> Yes. We can't have these set when loading an Android boot image because
> >> they instruct the bootloader to use the device tree/initrd in place instead
> >> of copying them to another location, and since we're already using the
> >> kernel in place this may result in the kernel overwriting the device tree
> >> or initrd when it initializes its own BSS since they appear right after the
> >> kernel in the boot image format.
> >>
> >
> > Ok, thanks for the clarification. That's fine by me.
> >
> > Reviewed-by: Ryan Harkin 
> >
> 
> Thanks for the review! Do you know what is the next step for getting this
> patch landed in master? I read https://www.denx.de/wiki/U-Boot/Patches but
> unfortunately I did not get a clear idea of what the next step is.

It's on me to pick up and I will soon, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 1/2] arm: dts: bcm283x: Allow UARTs to work before relocation

[Simon Glass]

Hi,

On Sun, 22 Mar 2020 at 21:16, Simon Glass  wrote:
>
> At present the pinctrl nodes are not enabled in pre-relocation U-Boot so
> the UARTs do not correctly select the pinconfig to enable the UART pins.
> Fix this so that the U-Boot banner is printed.
>
> This fixes serial output on rpi_3b_32b with the following config.txt
> options:
>
>enable_uart=1
>gpu_freq=250
>
> Signed-off-by: Simon Glass 
> Fixes: 9821636b64 (bcm2835_pinctrl: Probe pre-reloc)
> ---
>
> Changes in v2:
> - Update commit message
>
>  arch/arm/dts/bcm283x-u-boot.dtsi | 8 
>  1 file changed, 8 insertions(+)

Any thoughts on this series? At present all my lab tests fail.

Regards,
Simon

Re: [RFC PATCH] powerpc, qe: add DTS support for parallel I/O ports

[Heiko Schocher]

Hello Qiang Zhao,

Am 09.04.2020 um 08:58 schrieb Qiang Zhao:

On 2020/2/18 17:05, Heiko Schocher mailto:h...@denx.de>> wrote:


-Original Message-



From: Heiko Schocher 



Sent: 2020年2月18日17:05



To: U-Boot Mailing List 



Cc: Heiko Schocher ; Holger Brunck



; Mario Six ; Qiang Zhao



; Wolfgang Denk 



Subject: [RFC PATCH] powerpc, qe: add DTS support for parallel I/O ports







add DM support for parallel I/O ports on QUICC Engine Block







Signed-off-by: Heiko Schocher mailto:h...@denx.de>>



---











 arch/powerpc/cpu/mpc83xx/cpu_init.c |   8 ++



 arch/powerpc/cpu/mpc83xx/qe_io.c    | 193



+++-



 include/fsl_qe.h    |   3 +



 3 files changed, 201 insertions(+), 3 deletions(-)







diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c



b/arch/powerpc/cpu/mpc83xx/cpu_init.c



index af8facad53..cfcc16607c 100644



--- a/arch/powerpc/cpu/mpc83xx/cpu_init.c



+++ b/arch/powerpc/cpu/mpc83xx/cpu_init.c


*//*

How about mpc85xx?


Yes, this is a Todo (one reason why this patch is RFC). I currently have 
reworked
this for the mpc83xx based keymile (now abb) boards (which are locally running 
with
complete DM/DTS support now).

I have one mpx85xx based board I can try, but may others are working on this
support, so I wanted to post my patches very early, so we can work together
on it...

As my first question in patch comment is:

may we should move this part to drivers/pinctrl ?


@@ -11,6 +11,9 @@



 #ifdef CONFIG_USB_EHCI_FSL



 #include 



 #endif



+#ifdef CONFIG_QE



+#include 



+#endif


*//*

If include this headfile, the function declaration for qe_init and qe_reset in this file should be 
removed as below:


extern void qe_init(uint qe_base);

extern void qe_reset(void);


Yes, of course! But this part of code I did not touch... may this needs
a cleanup at all.








 #include "lblaw/lblaw.h"



 #include "elbc/elbc.h"



@@ -27,6 +30,7 @@ extern void qe_config_iopin(u8 port, u8 pin, int dir,



extern void qe_init(uint qe_base);  extern void qe_reset(void);







+/**



+ * par_io_of_config_node  config



+ * @dev: pointer to pinctrl device



+ * @pio:  ofnode of pinconfig property



+ */



+static int par_io_of_config_node(struct udevice *dev, ofnode pio) {



+   struct qe_io_platdata  *plat = dev->platdata;



+   volatile qepio83xx_t    *par_io = plat->base;



+   const unsigned int *pio_map;



+   int pio_map_len;



+



+   pio_map = ofnode_get_property(pio, "pio-map", &pio_map_len);



+   if (pio_map == NULL)



+    return -ENOENT;



+



+   pio_map_len /= sizeof(unsigned int);



+   if ((pio_map_len % 6) != 0) {



+    printk(KERN_ERR "pio-map format wrong!\n");



+    return -EINVAL;



+   }



+



+   while (pio_map_len > 0) {



+    /*



+    * column pio_map[5] from linux (has_irq) not



+    * supported in u-boot yet.



+    */


*//*

remove or keep pio_map[5] in uboot dts, which is better?


I think we keep it as it is in linux dts. We simply ignore it (yet)
in U-Boot.




+



+const struct pinctrl_ops par_io_pinctrl_ops = {



+   .set_state = par_io_pinctrl_set_state, };



+



+static const struct udevice_id par_io_pinctrl_match[] = {



+   { .compatible = "fsl,mpc8360-par_io"},


*//*

Why is*//*fsl,mpc8360-par_io, maybe fsl,qe-par-io are more better.*//*


Yes, more common, but in Linux is already:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kmeter1.dts#n133

or
compatible = "fsl,mpc8323-qe-pario";

for board
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/mpc832x_rdb.dts#n163

Unfortunately, it is more or less a mess in linux, as each board scans
in board code for the node *name* not compatible entry ! See as an example:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/platforms/83xx/mpc832x_rdb.c#n198

So may we are free here, to add here a new compatible entry "fsl,qe-par-io" ?
(But I want to be compatible with linux and accept the same compatible strings
as linux has.)




+   { /* sentinel */ }



+};



+



+U_BOOT_DRIVER(par_io_pinctrl) = {



+   .name = "par-io-pinctrl",



+   .id = UCLASS_PINCTRL,



+   .of_match = of_match_ptr(par_io_pinctrl_match),



+   .probe = par_io_pinctrl_probe,



+   .ofdata_to_platdata = qe_io_ofdata_to_platdata,



+   .platdata_auto_alloc_size = sizeof(struct qe_io_platdata),



+   .ops = &par_io_pinctrl_ops,



+#if CONFIG_IS_ENABLED(OF_CONTROL)



&& !CONFIG_IS_ENABLED(OF_PLATDATA)



+   .flags    = DM_FLAG_PRE_RELOC,



+#endif



+};



+#endif



diff --git a/include/fsl_qe.h b/include/fsl_qe.h index d4eba82436..cb5c91bdf1



100644



--- a/include/fsl_qe.h



+++ b/include/fsl_qe.h



@@ -295,4 +295,7 @@ int u_qe_firmware_resume(const struct qe_firmware



*firmware,



     qe_map_t *qe_immrr);

Re: [PATCH v2 21/22] Use __ASSEMBLY__ as the assembly macros

[Simon Goldschmidt]

Am 14.04.2020 um 23:04 schrieb Tom Rini:
> On Tue, Apr 14, 2020 at 10:38:47PM +0200, Simon Goldschmidt wrote:
>> Masahiro Yamada  schrieb am Di., 14. Apr. 2020, 17:34:
>>
>>> Hi Simon,
>>>
>>> On Tue, Apr 14, 2020 at 11:41 PM Simon Glass  wrote:

 Hi Masahiro,

 On Mon, 13 Apr 2020 at 11:10, Masahiro Yamada 
>>> wrote:
>
> On Fri, Apr 10, 2020 at 5:18 AM Simon Glass  wrote:
>>
>> Some places use __ASSEMBLER__ instead which does not work since the
>> Makefile does not define it. Fix them.
>
>
> In my understanding,
> __ASSEMBLER__ is passed by the compiler
> while building *.S files.
>
> On which compiler didn't this work for you?
>
>
>
>
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>> Changes in v2:
>> - Add new patch to fix occurances of __ASSEMBLER__
>>

 I think I hit this with device tree, but I would need to go back and
 check. Anyway I think we should be consistent.
>>>
>>>
>>> DT files are pre-processed with  '-x assembler-with-cpp'.
>>>
>>> So, __ASSEMBLER__ is pre-defined by the compiler.
>>>
>>
>> I have just seen this thread now. It touches socfpga headers but we're not
>> in CC (possibly the maintainers file needs updating).
>>
>> Anyway, why do we have 2 defines for assembler? If one is predefined by the
>> compiler, why don't we use that? Can you explain that for someone not too
>> deeply involved?
> 
> Generally and broadly speaking, the assembler will set __ASSEMBLER__.
> That said, the Linux kernel has been setting __ASSEMBLY__ for
> practically forever and we've copied that behavior also practically for
> forever.  In both trees there are a handful of __ASSEMBLER__ tests and a
> vast majority of __ASSEMBLY__ tests.  It doesn't normally matter which
> is used as the only non-compiler in the Linux kernel that might care is
> handled as shown above.  Under the assumption that the feature
> Yamada-san pointed out in binman is used, it should also define
> __ASSEMBLER__ I believe, to match other tooling.  Thanks!

Ok, thanks for the explanation.

Regards,
Simon

Re: [RFC PATCH] net, qe: add DM support for QE UEC ethernet

[Heiko Schocher]

Hello Qiang Zhao,

Am 09.04.2020 um 10:00 schrieb Qiang Zhao:

On 2020/4/9 13:20, Heiko Schocher  wrote:



-Original Message-
From: Heiko Schocher 
Sent: 2020年4月9日 13:19
To: Priyanka Jain 
Cc: U-Boot Mailing List ; Holger Brunck
; Joe Hershberger ;
Mario Six ; Qiang Zhao 
Subject: Re: [RFC PATCH] net, qe: add DM support for QE UEC ethernet

Hello Priyanka,

Am 18.02.2020 um 10:05 schrieb Heiko Schocher:

add DM/DTS suppor for the UEC ethernet on QUICC Engine Block.

Signed-off-by: Heiko Schocher 
---
Travis build:

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrav


is-ci.org%2Fhsdenx%2Fu-boot-test%2Fbuilds%2F651400509&data=02%7C
01

%7Cqiang.zhao%40nxp.com%7C51477945d03e4b72383708d7dc458e7e%7C

686ea1d3b



c2b4c6fa92cd99c5c301635%7C0%7C0%7C637220063612830833&sdata
=MALxWjN

kO0lgq1b0gmk646eEI8HWZUXRqTHt6zaOQPk%3D&reserved=0

- I let the old none DM based implementation in code
so boards should work with old implementation.
This Code should be removed if all boards are converted
to DM/DTS.

- add the DM based qe uec driver under drivers/net/qe

- Therefore copied the files uccf.c uccf.h uec.h from
drivers/qe. So there are a lot of Codingstyle problems
currently. I fix them in next version if this RFC
patch is OK or it needs some changes.

- The dm based driver code is now under drivers/net/qe/dm_qe_uec.c
Used a lot of functions from drivers/qe/uec.c

- seperated the PHY specific code into seperate file
drivers/net/qe/dm_qe_uec_phy.c


There are so much duplicated codes.


Yes, as I do not want to break other boards, as I said in comment.

If all boards are moved to this new driver, we can remove the old code.


And what the dts node looks like?
Could you please give an example?


Uh, indeed, I did not add an entry in "doc/device-tree-bindings/"

I add this in next version.

Same as in linux:

MDIO:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kmeter1.dts#n426


mdio@3320 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0x3320 0x18>;
compatible = "fsl,ucc-mdio";

/* Piggy2 (UCC4, MDIO 0x00, RMII) */
phy_piggy2: ethernet-phy@0 {
reg = <0x0>;
};
[...]

Ethernet:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kmeter1.dts#n395

/* Eth-3 (UCC7, MDIO 0x0a, RMII) */
enet_eth3: ucc@2600 {
device_type = "network";
compatible = "ucc_geth";
cell-index = <7>;
reg = <0x2600 0x200>;
interrupts = <42>;
interrupt-parent = <&qeic>;
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock-name = "none";
tx-clock-name = "clk16";
phy-handle = <&phy_eth3>;
phy-connection-type = "rmii";
pio-handle = <&pio_ucc7>;
};

(And yes, compatible entry is ancient...)





   drivers/net/Kconfig|2 +
   drivers/net/Makefile   |1 +
   drivers/net/qe/Kconfig |9 +
   drivers/net/qe/Makefile|5 +
   drivers/net/qe/dm_qe_uec.c | 1161



   drivers/net/qe/dm_qe_uec.h |   22 +
   drivers/net/qe/dm_qe_uec_phy.c |  161 +
   drivers/net/qe/uccf.c  |  388 +++
   drivers/net/qe/uccf.h  |  117 
   drivers/net/qe/uec.h   |  742 
   drivers/qe/uccf.c  |2 +
   drivers/qe/uec.c   |2 +
   drivers/qe/uec_phy.c   |3 +
   13 files changed, 2615 insertions(+)
   create mode 100644 drivers/net/qe/Kconfig
   create mode 100644 drivers/net/qe/Makefile
   create mode 100644 drivers/net/qe/dm_qe_uec.c
   create mode 100644 drivers/net/qe/dm_qe_uec.h
   create mode 100644 drivers/net/qe/dm_qe_uec_phy.c
   create mode 100644 drivers/net/qe/uccf.c
   create mode 100644 drivers/net/qe/uccf.h
   create mode 100644 drivers/net/qe/uec.h


Any comments?

Thanks!

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

Best Regards
Qiang Zhao



bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-814

Re: [RFC PATCH] net, qe: add DM support for QE UEC ethernet

[Heiko Schocher]

Hello Qiang Zhao,

Am 15.04.2020 um 06:57 schrieb Heiko Schocher:

Hello Qiang Zhao,

Am 09.04.2020 um 10:00 schrieb Qiang Zhao:

On 2020/4/9 13:20, Heiko Schocher  wrote:



-Original Message-
From: Heiko Schocher 
Sent: 2020年4月9日 13:19
To: Priyanka Jain 
Cc: U-Boot Mailing List ; Holger Brunck
; Joe Hershberger ;
Mario Six ; Qiang Zhao 
Subject: Re: [RFC PATCH] net, qe: add DM support for QE UEC ethernet

Hello Priyanka,

Am 18.02.2020 um 10:05 schrieb Heiko Schocher:

add DM/DTS suppor for the UEC ethernet on QUICC Engine Block.

Signed-off-by: Heiko Schocher 
---
Travis build:

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrav


is-ci.org%2Fhsdenx%2Fu-boot-test%2Fbuilds%2F651400509&data=02%7C
01

%7Cqiang.zhao%40nxp.com%7C51477945d03e4b72383708d7dc458e7e%7C

686ea1d3b



c2b4c6fa92cd99c5c301635%7C0%7C0%7C637220063612830833&sdata
=MALxWjN

kO0lgq1b0gmk646eEI8HWZUXRqTHt6zaOQPk%3D&reserved=0

- I let the old none DM based implementation in code
    so boards should work with old implementation.
    This Code should be removed if all boards are converted
    to DM/DTS.

- add the DM based qe uec driver under drivers/net/qe

- Therefore copied the files uccf.c uccf.h uec.h from
    drivers/qe. So there are a lot of Codingstyle problems
    currently. I fix them in next version if this RFC
    patch is OK or it needs some changes.

- The dm based driver code is now under drivers/net/qe/dm_qe_uec.c
    Used a lot of functions from drivers/qe/uec.c

- seperated the PHY specific code into seperate file
    drivers/net/qe/dm_qe_uec_phy.c


There are so much duplicated codes.


Yes, as I do not want to break other boards, as I said in comment.

If all boards are moved to this new driver, we can remove the old code.


And what the dts node looks like?
Could you please give an example?


Uh, indeed, I did not add an entry in "doc/device-tree-bindings/"

I add this in next version.

Same as in linux:

MDIO:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kmeter1.dts#n426 




     mdio@3320 {
     #address-cells = <1>;
     #size-cells = <0>;
     reg = <0x3320 0x18>;
     compatible = "fsl,ucc-mdio";

     /* Piggy2 (UCC4, MDIO 0x00, RMII) */
     phy_piggy2: ethernet-phy@0 {
     reg = <0x0>;
     };
     [...]


Thanks for this question!

There is already a phy driver drivers/net/fsl_mdio.c which I can use
also for UEC. I reworked this patch and dropped
./drivers/net/qe/dm_qe_uec_phy.c

Just have to test it, when I get access to the hardware.

bye,
Heiko


Ethernet:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kmeter1.dts#n395 



     /* Eth-3 (UCC7, MDIO 0x0a, RMII) */
     enet_eth3: ucc@2600 {
     device_type = "network";
     compatible = "ucc_geth";
     cell-index = <7>;
     reg = <0x2600 0x200>;
     interrupts = <42>;
     interrupt-parent = <&qeic>;
     local-mac-address = [ 00 00 00 00 00 00 ];
     rx-clock-name = "none";
     tx-clock-name = "clk16";
     phy-handle = <&phy_eth3>;
     phy-connection-type = "rmii";
     pio-handle = <&pio_ucc7>;
     };

(And yes, compatible entry is ancient...)





   drivers/net/Kconfig    |    2 +
   drivers/net/Makefile   |    1 +
   drivers/net/qe/Kconfig |    9 +
   drivers/net/qe/Makefile    |    5 +
   drivers/net/qe/dm_qe_uec.c | 1161



   drivers/net/qe/dm_qe_uec.h |   22 +
   drivers/net/qe/dm_qe_uec_phy.c |  161 +
   drivers/net/qe/uccf.c  |  388 +++
   drivers/net/qe/uccf.h  |  117 
   drivers/net/qe/uec.h   |  742 
   drivers/qe/uccf.c  |    2 +
   drivers/qe/uec.c   |    2 +
   drivers/qe/uec_phy.c   |    3 +
   13 files changed, 2615 insertions(+)
   create mode 100644 drivers/net/qe/Kconfig
   create mode 100644 drivers/net/qe/Makefile
   create mode 100644 drivers/net/qe/dm_qe_uec.c
   create mode 100644 drivers/net/qe/dm_qe_uec.h
   create mode 100644 drivers/net/qe/dm_qe_uec_phy.c
   create mode 100644 drivers/net/qe/uccf.c
   create mode 100644 drivers/net/qe/uccf.h
   create mode 100644 drivers/net/qe/uec.h


Any comments?

Thanks!

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

Best Regards
Qiang Zhao



bye,
Heiko


--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-8

Re: [PATCH u-boot-marvell 1/1] clk: armada-37xx-periph: fix DDR PHY clock divider values

[Stefan Roese]

On 15.04.20 00:59, Marek Behún wrote:

Register value table for DDR PHY clock divider are wrong. They should be
0 or 1 for divide-by-2 or divide-by-4, respectively. Not 1 or 2. Current
values do not make sense, since 2 cannot be achieved, because the
register is only 1 bit long (mask is set to 1).

This fixes clk dump reporting DDR PHY clock rate differently from Linux.

Signed-off-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  drivers/clk/mvebu/armada-37xx-periph.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/mvebu/armada-37xx-periph.c 
b/drivers/clk/mvebu/armada-37xx-periph.c
index 068e48ea04..855f979b4f 100644
--- a/drivers/clk/mvebu/armada-37xx-periph.c
+++ b/drivers/clk/mvebu/armada-37xx-periph.c
@@ -89,8 +89,8 @@ static const struct clk_div_table div_table1[] = {
  };
  
  static const struct clk_div_table div_table2[] = {

-   { 2, 1 },
-   { 4, 2 },
+   { 2, 0 },
+   { 4, 1 },
{ 0, 0 },
  };
  




Viele Grüße,
Stefan

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

Re: Calling i2c set speed twice for i2c_mux_bus

[Michal Simek]

On 10. 04. 20 10:49, Heiko Schocher wrote:
> Hello Michal,
> 
> Am 10.04.2020 um 08:46 schrieb Michal Simek:
>> Hi Heiko,
>>
>> On 10. 04. 20 7:11, Heiko Schocher wrote:
>>> Hello Michal,
>>>
>>> Am 09.04.2020 um 16:03 schrieb Michal Simek:
 Hi Heiko and Simon,

 I have find out one bug in i2c class. I am using zcu104 revC board
 which
 has dts in mainline where i2c1 has i2c mux with some channels.
 In DT clock-frequency = <40>; is specified and it is read in
 i2c_post_probe(). But i2c_mux_bus_drv is also UCLASS_I2C which means
 that post probe is called for it too. And because clock-frequency
 property is not there default 100k is used.

 I think that is bug and should be fixed.
 Heiko: Are you aware about this issue?
>>>
>>> No :-(
>>>
>>> The question is, is this a bug?
>>
>> I have never seen clock-frequency property in i2c mux bus node. Also I
>> have looked at linux dt binding docs and nothing like that is specified
>> there. From quick look also pca954x driver is not reading it.
> 
> Indeed.
> 
>>> Should a i2c bus behind a mux not be able to set his own speed?
>>
>> Not sure if that make sense but Linux will likely ignore it. I am not
>> saying it doesn't make sense but I haven't seen this feature.
> 
> Ok.
> 
>>> But may as a feature (or bugfix?) if "clock-frequency" is not there,
>>> use the speed of the parent bus...?
>>
>> I was thinking about this too.
>> just c&p quick implementation would look like this. Because it is
>> i2c->i2c_mux->i2c. But maybe there is a better way how to do it.
>>
>> diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
>> index 2aa3efe8aaa0..982c467deba3 100644
>> --- a/drivers/i2c/i2c-uclass.c
>> +++ b/drivers/i2c/i2c-uclass.c
>> @@ -640,9 +640,21 @@ static int i2c_post_probe(struct udevice *dev)
>>   {
>>   #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
>>  struct dm_i2c_bus *i2c = dev_get_uclass_priv(dev);
>> +   int parent_speed = I2C_SPEED_STANDARD_RATE;
>> +
>> +   if (dev->parent &&
>> +   device_get_uclass_id(dev->parent) == UCLASS_I2C_MUX &&
>> +   dev->parent->parent &&
>> +   device_get_uclass_id(dev->parent->parent) == UCLASS_I2C) {
>> +   struct dm_i2c_bus *i2c_parent;
>> +
>> +   i2c_parent = dev_get_uclass_priv(dev->parent->parent);
>> +   parent_speed = i2c_parent->speed_hz;
>> +   /* Not sure if make sense to check that parent_speed is
>> not 0 */
> 
> I think this check is not needed.
> 
>> +   }
>>
>>  i2c->speed_hz = dev_read_u32_default(dev, "clock-frequency",
>> -    I2C_SPEED_STANDARD_RATE);
>> +    parent_speed);
> 
> Wow, a big if ... may this is clearer (not compile tested)?
> 
> udevice *parent = dev_get_parent(dev);
> 
> if (parent && device_get_uclass_id(parent) == UCLASS_I2C_MUX) {
> udevice *parent2 = dev_get_parent(parent);
> if (parent2 && device_get_uclass_id(parent2) == UCLASS_I2C) {
>     struct dm_i2c_bus *i2cp = dev_get_uclass_priv(parent2);
> 
>     parent_speed = i2cp->speed_hz;
> }
> }
> 
> but Simon has a deeper DM knowledge, may there is a better approach.

Simon: any comment on this one?

Thanks,
Michal

Re: [PATCH v3 1/9] dm: core: Add function to get child count of ofnode or device

[Weijie Gao]

On Thu, 2020-03-26 at 16:01 +0800, Chunfeng Yun wrote:
> This patch add function used to get the child count of
> a ofnode or a device
> 
> Signed-off-by: Chunfeng Yun 
> ---
> v3:
> 1. add non/inline function dev_get_child_count() instead of macro 
> suggested by Simon
> 
> v2:
> 1. move ofnode_get_child_count() into ofnode.c suggested by Simon
> 2. add a new macro dev_get_child_count()
> ---
>  drivers/core/ofnode.c | 11 +++
>  drivers/core/read.c   |  5 +
>  include/dm/ofnode.h   |  8 
>  include/dm/read.h | 13 +
>  4 files changed, 37 insertions(+)
> 

Reviewed-by: Weijie Gao 

Re: [PATCH v3 2/9] test: dm: add test item for ofnode_get_child_count()

[Weijie Gao]

On Thu, 2020-03-26 at 16:01 +0800, Chunfeng Yun wrote:
> Add a test item for ofnode_get_child_count()
> 
> Signed-off-by: Chunfeng Yun 
> Reviewed-by: Simon Glass 
> ---
> v3:
> 1. squash dts patch into this one suggested by Simon
> 2. add reviewed-by Simon
> 
> v2:
> a new patch to test ofnode_get_child_count() suggested by Simon
> ---
>  arch/sandbox/dts/test.dts | 18 ++
>  test/dm/ofnode.c  | 21 +
>  2 files changed, 39 insertions(+)
> 

Reviewed-by: Weijie Gao 

Re: [PATCH V3] ARM: dts: stm32: Add KS8851-16MLL ethernet on FMC2

[Christophe Kerello]

On 4/10/20 8:11 PM, Marek Vasut wrote:

On 4/9/20 7:38 PM, Patrick DELAUNAY wrote:
Hi,

[...]


That looks like a hack, it would collide with the actual FMC2 driver and it 
seems
the FMC2 DT compatible string is not even stable yet (cfr the Linux patches). 
So I
am reluctant to do anything like depending on the FMC DT bindings thus far.


You are aligned with Christophe, he push me to accept your temporarily solution.


Great, thanks.

I had a look into writing the bus driver in the meantime, but it's not
as simple as I originally anticipated. So, I'll wait until the Linux DT
bindings stabilize and revisit it then.

Thanks



Hi Marek,

I have already prepared a set of patches to add the full FMC2 support in 
U-Boot based on kernel drivers. I am currently waiting for the bindings 
and the drivers being reviewed on kernel side.


Regards,
Christophe Kerello.

Re: [PATCH v2 2/2] efi_loader: identify EFI system partition

[Heinrich Schuchardt]

On 2020-04-14 08:12, AKASHI Takahiro wrote:
> On Tue, Apr 14, 2020 at 05:53:43AM +, Heinrich Schuchardt wrote:
>> Am April 14, 2020 5:20:38 AM UTC schrieb AKASHI Takahiro 
>> :
>>> Heinrich,
>>>
>>> On Mon, Apr 06, 2020 at 02:31:35PM +0900, AKASHI Takahiro wrote:
 On Mon, Apr 06, 2020 at 07:12:56AM +0200, Heinrich Schuchardt wrote:
> On 4/6/20 6:21 AM, AKASHI Takahiro wrote:
>> Heinrich,
>>
>> On Sun, Apr 05, 2020 at 11:28:18AM +0200, Heinrich Schuchardt
>>> wrote:
>>> For capsule updates we need to identify the EFI system
>>> partition.
>>
>> Right, but
>>
>>> Signed-off-by: Heinrich Schuchardt 
>>> ---
>>> v2:
>>> no change
>>> ---
>>>  include/efi_loader.h  |  7 +++
>>>  lib/efi_loader/efi_disk.c | 20 
>>>  2 files changed, 27 insertions(+)
>>>
>>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>>> index 3f2792892f..4a45033476 100644
>>> --- a/include/efi_loader.h
>>> +++ b/include/efi_loader.h
>>> @@ -45,6 +45,13 @@ static inline void *guidcpy(void *dst, const
>>> void *src)
>>>  /* Root node */
>>>  extern efi_handle_t efi_root;
>>>
>>> +/* EFI system partition */
>>> +extern struct efi_system_partition {
>>> +   enum if_type if_type;
>>> +   int devnum;
>>> +   u8 part;
>>> +} efi_system_partition;
>>> +
>>>  int __efi_entry_check(void);
>>>  int __efi_exit_check(void);
>>>  const char *__efi_nesting(void);
>>> diff --git a/lib/efi_loader/efi_disk.c
>>> b/lib/efi_loader/efi_disk.c
>>> index fc0682bc48..2f752a5e99 100644
>>> --- a/lib/efi_loader/efi_disk.c
>>> +++ b/lib/efi_loader/efi_disk.c
>>> @@ -13,6 +13,8 @@
>>>  #include 
>>>  #include 
>>>
>>> +struct efi_system_partition efi_system_partition;
>>> +
>>>  const efi_guid_t efi_block_io_guid =
>>> EFI_BLOCK_IO_PROTOCOL_GUID;
>>>
>>>  /**
>>> @@ -372,6 +374,24 @@ static efi_status_t efi_disk_add_dev(
>>> diskobj->ops.media = &diskobj->media;
>>> if (disk)
>>> *disk = diskobj;
>>> +
>>> +   /* Store first EFI system partition */
>>
>> I don't think that the policy, first comes first serves as system
>> partition, is a right decision as
>> - the order of device probe on U-Boot is indeterministic, and
>
> Indeterministic would mean that on two runs with the same media
>>> provided
> you will get different results. I cannot see any source for such
> randomness in the U-Boot code. In dm_init_and_scan() the device
>>> tree is
> scanned and drivers and bound in the sequence of occurrence in the
> device tree.
>
>> - there can be several partitions that hold a system partition
>>> bit.
>>   You may have OS installed on eMMC, but also may have bootable
>>> DVD
>>   on the system.
>
> This is a similar logic like finding the relevant boot.scr script
>>> to run.
>
> What would be the alternative?

 I think that most UEFI systems have ability for user to specify
 "boot order."
>>>
>>> Any comment?
>>> The discussion and your patch will have some impact on
>>> my efi capsule patch.
>>
>> Concerning capsules the spec says we should use the boot device. So my patch 
>> doesn't help you there.
>
> Your commit message says,
>   "For capsule updates we need to identify the EFI system partition."
>
> and then I made some counter comment.
> So now you agreed with my comment, don't you?
> (I need to confirm this to work on capsule patch.)

You can stick to your original design.

>
>> For the storage of variables I still need this patch. I will adjust the 
>> commit message.
>
> Even in this case, I believe that the first device detected in your logic
> is not always a "valid" device for your purpose.

Do you have a better suggestion?

Best regards

Heinrich

>
> -Takahiro Akashi
>
>>
>> Best regards
>>
>> Heinrich
>>
>>>
>>> -Takahiro Akashi
>>>
 -Takahiro Akashi
>
> Definition via Kconfig would mean that a Linux distribution like
>>> Debian
> would have to provide a separate U-Boot build for each boot medium
>>> that
> a user might possibly use (eMMC, SD-card, USB, NVME, SCSI).
>
> Best regards
>
> Heinrich
>
>>
>> -Takahiro Akashi
>>
>>> +   if (part && !efi_system_partition.if_type) {
>>> +   int r;
>>> +   disk_partition_t info;
>>> +
>>> +   r = part_get_info(desc, part, &info);
>>> +   if (r)
>>> +   return EFI_DEVICE_ERROR;
>>> +   if (info.bootable & PART_EFI_SYSTEM_PARTITION) {
>>> +   efi_system_partition.if_type = desc->if_type;
>>> +   efi_system_partition.devnum = desc->devnum;
>>> +   efi_system_partition.part = part;
>>>

Re: [PATCH] common: Add Kconfig option for FDT mem alignment

[Michal Simek]

On 14. 04. 20 1:38, Heinrich Schuchardt wrote:
> On 4/13/20 10:03 AM, Michal Simek wrote:
>> From: Ashok Reddy Soma 
>>
>> FDT memory is aligned by 4KB. This is hardcoded in common/board_f.c.
>> Add Kconfig option, assign default value of 0x1000 and enable option to
>> change this value.
> 
> Please, describe why this patch is needed.
> 
>>
>> Signed-off-by: Ashok Reddy Soma 
>> Signed-off-by: Michal Simek 
>> ---
>>
>>  common/board_f.c | 3 ++-
>>  dts/Kconfig  | 7 +++
>>  2 files changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/common/board_f.c b/common/board_f.c
>> index 82a164752aa3..928874e03555 100644
>> --- a/common/board_f.c
>> +++ b/common/board_f.c
>> @@ -546,7 +546,8 @@ static int reserve_fdt(void)
>>   * will be relocated with other data.
>>   */
>>  if (gd->fdt_blob) {
>> -gd->fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob) + 0x1000, 32);
>> +gd->fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob) +
>> + CONFIG_FDT_MEM_ALIGN_SIZE, 32);
>>
>>  gd->start_addr_sp -= gd->fdt_size;
>>  gd->new_fdt = map_sysmem(gd->start_addr_sp, gd->fdt_size);
> 
> This change does not relate to the commit message. You are not adjusting
> the alignment of the device tree location. You are adjusting the size of
> the memory available for the device tree.

Let me correct that description in v2.
It is additional size for actual FDT size. I am also not sure why this
is needed.


> 
> reserve_fdt() is called after reserve_global_data() where we have:
> gd->start_addr_sp -= sizeof(gd_t).
> 
> A typical debug output from reserve_global_data() is:
> Reserving 544 Bytes for Global Data at: bf740d98
> 
> So in this case the device tree will have an alignment of 8 no matter
> what power of 2 (>= 8) you choose for CONFIG_FDT_MEM_ALIGN_SIZE.

fdt_size should be aligned by 32 bytes as is written above.


> 
> What about other places where we allocate memory for device trees like
> copy_fdt() in cmd/bootefi.?

This is interesting. You are using 0x3000 alignment.

This address is also interesting:
127 new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 +
128  fdt_size, 0);

Anyway. If you are happy to use 0x1000 here we can also include it.
Also if you are aware about any other location which is related to this
we are happy to include it.



> 
>> diff --git a/dts/Kconfig b/dts/Kconfig
>> index 046a54a17366..696c0b71afaf 100644
>> --- a/dts/Kconfig
>> +++ b/dts/Kconfig
>> @@ -121,6 +121,13 @@ config DEFAULT_DEVICE_TREE
>>It can be overridden from the command line:
>>$ make DEVICE_TREE=
>>
>> +config FDT_MEM_ALIGN_SIZE
>> +hex "FDT memory alignment size"
>> +default 0x1000
>> +help
>> +  This option is used to set the default alignment when reserving memory
> 
> %s/is used to set the default alignment/sets the alignment/
> 
> Please, mention if this value should be a power of 2.

And is it really necessary? I think the question is why there is 0x1000
additional space. It was added by Simon in 2013. Is this space even used
for something?
I expect that you don't run fdt resize on in this space anyway.

Thanks,
Michal

Re: [PATCH v1 u-boot-marvell 1/5] arm64: mvebu: armada-8k: move dram init code

[Stefan Roese]

On 08.04.20 19:25, Marek Behún wrote:

Move Armada-8k specific DRAM init code into armada-8k specific
directory.

Signed-off-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  arch/arm/mach-mvebu/arm64-common.c | 46 +--
  arch/arm/mach-mvebu/armada8k/Makefile  |  3 +-
  arch/arm/mach-mvebu/armada8k/dram.c| 52 ++
  arch/arm/mach-mvebu/include/mach/cpu.h |  4 ++
  4 files changed, 59 insertions(+), 46 deletions(-)
  create mode 100644 arch/arm/mach-mvebu/armada8k/dram.c

diff --git a/arch/arm/mach-mvebu/arm64-common.c 
b/arch/arm/mach-mvebu/arm64-common.c
index 40b98dbf08..244ea49d8a 100644
--- a/arch/arm/mach-mvebu/arm64-common.c
+++ b/arch/arm/mach-mvebu/arm64-common.c
@@ -45,54 +45,12 @@ const struct mbus_dram_target_info 
*mvebu_mbus_dram_info(void)
return NULL;
  }
  
-/* DRAM init code ... */

-
-#define MV_SIP_DRAM_SIZE   0x8210
-
-static u64 a8k_dram_scan_ap_sz(void)
-{
-   struct pt_regs pregs;
-
-   pregs.regs[0] = MV_SIP_DRAM_SIZE;
-   pregs.regs[1] = SOC_REGS_PHY_BASE;
-   smc_call(&pregs);
-
-   return pregs.regs[0];
-}
-
-static void a8k_dram_init_banksize(void)
-{
-   /*
-* The firmware (ATF) leaves a 1G whole above the 3G mark for IO
-* devices. Higher RAM is mapped at 4G.
-*
-* Config 2 DRAM banks:
-* Bank 0 - max size 4G - 1G
-* Bank 1 - ram size - 4G + 1G
-*/
-   phys_size_t max_bank0_size = SZ_4G - SZ_1G;
-
-   gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
-   if (gd->ram_size <= max_bank0_size) {
-   gd->bd->bi_dram[0].size = gd->ram_size;
-   return;
-   }
-
-   gd->bd->bi_dram[0].size = max_bank0_size;
-   if (CONFIG_NR_DRAM_BANKS > 1) {
-   gd->bd->bi_dram[1].start = SZ_4G;
-   gd->bd->bi_dram[1].size = gd->ram_size - max_bank0_size;
-   }
-}
-
  __weak int dram_init_banksize(void)
  {
if (CONFIG_IS_ENABLED(ARMADA_8K))
-   a8k_dram_init_banksize();
+   return a8k_dram_init_banksize();
else
-   fdtdec_setup_memory_banksize();
-
-   return 0;
+   return fdtdec_setup_memory_banksize();
  }
  
  __weak int dram_init(void)

diff --git a/arch/arm/mach-mvebu/armada8k/Makefile 
b/arch/arm/mach-mvebu/armada8k/Makefile
index 82cb25b417..0a4756717a 100644
--- a/arch/arm/mach-mvebu/armada8k/Makefile
+++ b/arch/arm/mach-mvebu/armada8k/Makefile
@@ -2,5 +2,4 @@
  #
  # Copyright (C) 2016 Stefan Roese 
  
-obj-y = cpu.o

-obj-y += cache_llc.o
+obj-y = cpu.o cache_llc.o dram.o
diff --git a/arch/arm/mach-mvebu/armada8k/dram.c 
b/arch/arm/mach-mvebu/armada8k/dram.c
new file mode 100644
index 00..265a8b0ae8
--- /dev/null
+++ b/arch/arm/mach-mvebu/armada8k/dram.c
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2016 Stefan Roese 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define MV_SIP_DRAM_SIZE   0x8210
+
+u64 a8k_dram_scan_ap_sz(void)
+{
+   struct pt_regs pregs;
+
+   pregs.regs[0] = MV_SIP_DRAM_SIZE;
+   pregs.regs[1] = SOC_REGS_PHY_BASE;
+   smc_call(&pregs);
+
+   return pregs.regs[0];
+}
+
+int a8k_dram_init_banksize(void)
+{
+   /*
+* The firmware (ATF) leaves a 1G whole above the 3G mark for IO
+* devices. Higher RAM is mapped at 4G.
+*
+* Config 2 DRAM banks:
+* Bank 0 - max size 4G - 1G
+* Bank 1 - ram size - 4G + 1G
+*/
+   phys_size_t max_bank0_size = SZ_4G - SZ_1G;
+
+   gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
+   if (gd->ram_size <= max_bank0_size) {
+   gd->bd->bi_dram[0].size = gd->ram_size;
+   return 0;
+   }
+
+   gd->bd->bi_dram[0].size = max_bank0_size;
+   if (CONFIG_NR_DRAM_BANKS > 1) {
+   gd->bd->bi_dram[1].start = SZ_4G;
+   gd->bd->bi_dram[1].size = gd->ram_size - max_bank0_size;
+   }
+
+   return 0;
+}
diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h 
b/arch/arm/mach-mvebu/include/mach/cpu.h
index 2e2d72aac8..7af8e5d09f 100644
--- a/arch/arm/mach-mvebu/include/mach/cpu.h
+++ b/arch/arm/mach-mvebu/include/mach/cpu.h
@@ -170,6 +170,10 @@ void mv_avs_init(void);
  static inline void mv_avs_init(void) {}
  #endif
  
+/* A8K dram functions */

+u64 a8k_dram_scan_ap_sz(void);
+int a8k_dram_init_banksize(void);
+
  /*
   * get_ref_clk
   *




Viele Grüße,
Stefan

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

Re: [PATCH v1 u-boot-marvell 2/5] arm64: mvebu: a37xx: improve code determining memory info structures

[Stefan Roese]

On 08.04.20 19:25, Marek Behún wrote:

Currently on Armada-37xx the mem_map structure is statically defined to
map first 2 GB of memory as RAM region, and system registers and PCIe
region device region.

This is insufficient for when there is more RAM or when for example the
PCIe windows is mapped to another address by the CPU Address Decoder.
In the case when the board has 4 GB RAM, on some boards the ARM Trusted
Firmware can move the PCIe window to another address, in order to
maximize possible usable RAM.

Also the dram_init and dram_init_banksize looks for information in
device-tree, and therefore different device trees are needed for boards
with different RAM sizes.

Therefore we add code that looks at how the ARM Trusted Firmware has
configured the CPU Address Decoder windows, and then we update the
mem_map structure and compute gd->ram_size and gd->bd->bi_dram bank
base addresses and sizes accordingly.

Signed-off-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  arch/arm/mach-mvebu/arm64-common.c |   5 +
  arch/arm/mach-mvebu/armada3700/cpu.c   | 252 ++---
  arch/arm/mach-mvebu/include/mach/cpu.h |   4 +
  3 files changed, 235 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-mvebu/arm64-common.c 
b/arch/arm/mach-mvebu/arm64-common.c
index 244ea49d8a..34cc0479a8 100644
--- a/arch/arm/mach-mvebu/arm64-common.c
+++ b/arch/arm/mach-mvebu/arm64-common.c
@@ -49,6 +49,8 @@ __weak int dram_init_banksize(void)
  {
if (CONFIG_IS_ENABLED(ARMADA_8K))
return a8k_dram_init_banksize();
+   else if (CONFIG_IS_ENABLED(ARMADA_3700))
+   return a3700_dram_init_banksize();
else
return fdtdec_setup_memory_banksize();
  }
@@ -61,6 +63,9 @@ __weak int dram_init(void)
return 0;
}
  
+	if (CONFIG_IS_ENABLED(ARMADA_3700))

+   return a3700_dram_init();
+
if (fdtdec_setup_mem_size_base() != 0)
return -EINVAL;
  
diff --git a/arch/arm/mach-mvebu/armada3700/cpu.c b/arch/arm/mach-mvebu/armada3700/cpu.c

index c83268181b..959a909d8a 100644
--- a/arch/arm/mach-mvebu/armada3700/cpu.c
+++ b/arch/arm/mach-mvebu/armada3700/cpu.c
@@ -1,6 +1,7 @@
  // SPDX-License-Identifier: GPL-2.0+
  /*
   * Copyright (C) 2016 Stefan Roese 
+ * Copyright (C) 2020 Marek Behun 
   */
  
  #include 

@@ -13,6 +14,7 @@
  #include 
  #include 
  #include 
+#include 
  
  /* Armada 3700 */

  #define MVEBU_GPIO_NB_REG_BASE(MVEBU_REGISTER(0x13800))
@@ -26,39 +28,237 @@
  #define MVEBU_NB_WARM_RST_REG (MVEBU_GPIO_NB_REG_BASE + 0x40)
  #define MVEBU_NB_WARM_RST_MAGIC_NUM   0x1d1e
  
-static struct mm_region mvebu_mem_map[] = {

-   {
-   /* RAM */
-   .phys = 0x0UL,
-   .virt = 0x0UL,
-   .size = 0x8000UL,
-   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
-   },
+/* Armada 3700 CPU Address Decoder registers */
+#define MVEBU_CPU_DEC_WIN_REG_BASE (size_t)(MVEBU_REGISTER(0xcf00))
+#define MVEBU_CPU_DEC_WIN_CTRL(w) \
+   (MVEBU_CPU_DEC_WIN_REG_BASE + ((w) << 4))
+#define MVEBU_CPU_DEC_WIN_CTRL_EN  BIT(0)
+#define MVEBU_CPU_DEC_WIN_CTRL_TGT_MASK0xf
+#define MVEBU_CPU_DEC_WIN_CTRL_TGT_OFFS4
+#define MVEBU_CPU_DEC_WIN_CTRL_TGT_DRAM0
+#define MVEBU_CPU_DEC_WIN_CTRL_TGT_PCIE2
+#define MVEBU_CPU_DEC_WIN_SIZE(w)  (MVEBU_CPU_DEC_WIN_CTRL(w) + 0x4)
+#define MVEBU_CPU_DEC_WIN_BASE(w)  (MVEBU_CPU_DEC_WIN_CTRL(w) + 0x8)
+#define MVEBU_CPU_DEC_WIN_REMAP(w) (MVEBU_CPU_DEC_WIN_CTRL(w) + 0xc)
+#define MVEBU_CPU_DEC_WIN_GRANULARITY  16
+#define MVEBU_CPU_DEC_WINS 5
+
+#define MAX_MEM_MAP_REGIONS(MVEBU_CPU_DEC_WINS + 2)
+
+#define A3700_PTE_BLOCK_NORMAL \
+   (PTE_BLOCK_MEMTYPE(MT_NORMAL) | PTE_BLOCK_INNER_SHARE)
+#define A3700_PTE_BLOCK_DEVICE \
+   (PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) | PTE_BLOCK_NON_SHARE)
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static struct mm_region mvebu_mem_map[MAX_MEM_MAP_REGIONS] = {
{
-   /* SRAM, MMIO regions */
-   .phys = 0xd000UL,
-   .virt = 0xd000UL,
+   /*
+* SRAM, MMIO regions
+* Don't remove this, a3700_build_mem_map needs it.
+*/
+   .phys = SOC_REGS_PHY_BASE,
+   .virt = SOC_REGS_PHY_BASE,
.size = 0x0200UL,   /* 32MiB internal registers */
-   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE
-   },
-   {
-   /* PCI regions */
-   .phys = 0xe800UL,
-   .virt = 0xe800UL,
-   .size = 0x0200UL,   /* 32MiB master PCI space */
-   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE
+   .attrs = A3700_PTE_BLOCK_DEVI

Re: [PATCH v1 u-boot-marvell 3/5] arm: mvebu: turris_mox: support devices with RAM > 1 GB

[Stefan Roese]

On 08.04.20 19:25, Marek Behún wrote:

In order to support MOX boards with 2 GB or 4 GB RAM, we use the new
Armada-3700 generic code for memory information structures. This is done
by removing dram_init and dram_init_banksize from turris_mox.c, in order
for the generic, weak definitions to be used.

Also for boards with 4 GB RAM it is needed to increase
CONFIG_NR_DRAM_BANKS to 2 in turris_mox_defconfig.

Signed-off-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  board/CZ.NIC/turris_mox/turris_mox.c | 16 
  configs/turris_mox_defconfig |  2 +-
  2 files changed, 1 insertion(+), 17 deletions(-)

diff --git a/board/CZ.NIC/turris_mox/turris_mox.c 
b/board/CZ.NIC/turris_mox/turris_mox.c
index 5bb53b1260..8e4c023103 100644
--- a/board/CZ.NIC/turris_mox/turris_mox.c
+++ b/board/CZ.NIC/turris_mox/turris_mox.c
@@ -43,22 +43,6 @@
  
  DECLARE_GLOBAL_DATA_PTR;
  
-int dram_init(void)

-{
-   gd->ram_base = 0;
-   gd->ram_size = (phys_size_t)get_ram_size(0, 0x4000);
-
-   return 0;
-}
-
-int dram_init_banksize(void)
-{
-   gd->bd->bi_dram[0].start = (phys_addr_t)0;
-   gd->bd->bi_dram[0].size = gd->ram_size;
-
-   return 0;
-}
-
  #if defined(CONFIG_OF_BOARD_FIXUP)
  int board_fix_fdt(void *blob)
  {
diff --git a/configs/turris_mox_defconfig b/configs/turris_mox_defconfig
index 3bc69cda4d..d786255d1d 100644
--- a/configs/turris_mox_defconfig
+++ b/configs/turris_mox_defconfig
@@ -8,7 +8,7 @@ CONFIG_ENV_SIZE=0x1
  CONFIG_ENV_SECT_SIZE=0x1
  CONFIG_ENV_OFFSET=0x18
  CONFIG_DM_GPIO=y
-CONFIG_NR_DRAM_BANKS=1
+CONFIG_NR_DRAM_BANKS=2
  CONFIG_DEBUG_UART_BASE=0xd0012000
  CONFIG_DEBUG_UART_CLOCK=25804800
  CONFIG_DEBUG_UART=y




Viele Grüße,
Stefan

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

Re: [PATCH v1 u-boot-marvell 4/5] arm64: mvebu: a37xx: add device-tree fixer for PCIe regions

[Stefan Roese]

On 08.04.20 19:25, Marek Behún wrote:

In case when ARM Trusted Firmware changes the default address of PCIe
regions (which can be done for devices with 4 GB RAM to maximize the
amount of RAM the device can use) we add code that looks at how ATF
changed the PCIe windows in the CPU Address Decoder and changes given
device-tree blob accordingly.

Signed-off-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  arch/arm/mach-mvebu/armada3700/cpu.c   | 52 ++
  arch/arm/mach-mvebu/include/mach/cpu.h |  3 ++
  2 files changed, 55 insertions(+)

diff --git a/arch/arm/mach-mvebu/armada3700/cpu.c 
b/arch/arm/mach-mvebu/armada3700/cpu.c
index 959a909d8a..17d2d43bab 100644
--- a/arch/arm/mach-mvebu/armada3700/cpu.c
+++ b/arch/arm/mach-mvebu/armada3700/cpu.c
@@ -50,6 +50,8 @@
  #define A3700_PTE_BLOCK_DEVICE \
(PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) | PTE_BLOCK_NON_SHARE)
  
+#define PCIE_PATH			"/soc/pcie@d007"

+
  DECLARE_GLOBAL_DATA_PTR;
  
  static struct mm_region mvebu_mem_map[MAX_MEM_MAP_REGIONS] = {

@@ -259,6 +261,56 @@ int a3700_dram_init_banksize(void)
return 0;
  }
  
+static u32 find_pcie_window_base(void)

+{
+   int win;
+
+   for (win = 0; win < MVEBU_CPU_DEC_WINS; ++win) {
+   u32 base, tgt;
+
+   /* skip disabled windows */
+   if (get_cpu_dec_win(win, &tgt, &base, NULL))
+   continue;
+
+   if (tgt == MVEBU_CPU_DEC_WIN_CTRL_TGT_PCIE)
+   return base;
+   }
+
+   return -1;
+}
+
+int a3700_fdt_fix_pcie_regions(void *blob)
+{
+   u32 new_ranges[14], base;
+   const u32 *ranges;
+   int node, len;
+
+   node = fdt_path_offset(blob, PCIE_PATH);
+   if (node < 0)
+   return node;
+
+   ranges = fdt_getprop(blob, node, "ranges", &len);
+   if (!ranges)
+   return -ENOENT;
+
+   if (len != sizeof(new_ranges))
+   return -EINVAL;
+
+   memcpy(new_ranges, ranges, len);
+
+   base = find_pcie_window_base();
+   if (base == -1)
+   return -ENOENT;
+
+   new_ranges[2] = cpu_to_fdt32(base);
+   new_ranges[4] = new_ranges[2];
+
+   new_ranges[9] = cpu_to_fdt32(base + 0x100);
+   new_ranges[11] = new_ranges[9];
+
+   return fdt_setprop_inplace(blob, node, "ranges", new_ranges, len);
+}
+
  void reset_cpu(ulong ignored)
  {
/*
diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h 
b/arch/arm/mach-mvebu/include/mach/cpu.h
index 2a53329420..1d619c4e49 100644
--- a/arch/arm/mach-mvebu/include/mach/cpu.h
+++ b/arch/arm/mach-mvebu/include/mach/cpu.h
@@ -178,6 +178,9 @@ int a8k_dram_init_banksize(void);
  int a3700_dram_init(void);
  int a3700_dram_init_banksize(void);
  
+/* A3700 PCIe regions fixer for device tree */

+int a3700_fdt_fix_pcie_regions(void *blob);
+
  /*
   * get_ref_clk
   *




Viele Grüße,
Stefan

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

Re: [PATCH v1 u-boot-marvell 5/5] arm: mvebu: turris_mox: fix PCIe ranges in device tree

[Stefan Roese]

On 08.04.20 19:25, Marek Behún wrote:

Use the new a3700_fdt_fix_pcie_regions function in turris_mox.c so that
MOX boards with 4 GB RAM are fully supported.

Signed-off-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  board/CZ.NIC/turris_mox/turris_mox.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/board/CZ.NIC/turris_mox/turris_mox.c 
b/board/CZ.NIC/turris_mox/turris_mox.c
index 8e4c023103..470ea32f9c 100644
--- a/board/CZ.NIC/turris_mox/turris_mox.c
+++ b/board/CZ.NIC/turris_mox/turris_mox.c
@@ -4,6 +4,7 @@
   */
  
  #include 

+#include 
  #include 
  #include 
  #include 
@@ -104,6 +105,11 @@ int board_fix_fdt(void *blob)
return 0;
}
  
+	if (a3700_fdt_fix_pcie_regions(blob) < 0) {

+   printf("Cannot fix PCIe regions in U-Boot's device tree!\n");
+   return 0;
+   }
+
return 0;
  }
  #endif
@@ -708,6 +714,11 @@ int ft_board_setup(void *blob, bd_t *bd)
res = fdt_setprop_string(blob, node, "status", "okay");
if (res < 0)
return res;
+
+   /* Fix PCIe regions for devices with 4 GB RAM */
+   res = a3700_fdt_fix_pcie_regions(blob);
+   if (res < 0)
+   return res;
}
  
  	/*





Viele Grüße,
Stefan

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

Re: [PATCH v1 u-boot-marvell 0/5] MVEBU ARM64 improvments + another Turris Mox patch

[Stefan Roese]

Hi Marek,

On 08.04.20 19:25, Marek Behún wrote:

Hi,

sorry for not sending these patches together with the others for Turris
Mox, but these make changes to generic arm64 mvebu code, so I thought it
would be better.

Currently U-Boot on Turris Mox discovers RAM size by calling
get_ram_size on the first gigabyte of memory. This is insufficient for
new prototypes with 2 GB and 4 GB RAM.

For the 2 GB variant it would be sufficient to simply call get_ram_size
on the first 2 GB of memory, but the 4 GB variant is more problematic,
because in order to support maximum usable RAM possible, ARM Trusted
Firmware can change the default address of PCIe regions and also the
DRAM memory windows are not consecutive.

This series adds code that looks at how ATF configured CPU Address
Decoder windows and accordingly changes mem_map regions for U-Boot's
virtual memory, and accordingly reports RAM size in dram_init and
RAM banks information in dram_init_banksize functions.

The first patch moves Armada-8k specific code into Armada-8k specific
directory.

The second patch adds that looks at the configuration of CPU Address
Decoder windows and does the above mentioned things.

The third patch removes dram_init and dram_init_banksize in Turris Mox
code so that the generic one which now works is used.

The fourth patch adds a function which fixes the PCIe ranges property
in the device-tree binary so that the driver will work even if ATF
changed the address of PCIe window.

The fifth patch calls this function on Turris Mox.

It would be nice if someone tested these on other A3700 boards, like
EspressoBIN.


Yes, I would very much like this too. I'll try to pull these changes
(and the other pending patches) pretty soon, so that people have time
to test this in this release cycle.

Thanks,
Stefan


Marek

Marek Behún (5):
   arm64: mvebu: armada-8k: move dram init code
   arm64: mvebu: a37xx: improve code determining memory info structures
   arm: mvebu: turris_mox: support devices with RAM > 1 GB
   arm64: mvebu: a37xx: add device-tree fixer for PCIe regions
   arm: mvebu: turris_mox: fix PCIe ranges in device tree

  arch/arm/mach-mvebu/arm64-common.c |  51 +
  arch/arm/mach-mvebu/armada3700/cpu.c   | 304 ++---
  arch/arm/mach-mvebu/armada8k/Makefile  |   3 +-
  arch/arm/mach-mvebu/armada8k/dram.c|  52 +
  arch/arm/mach-mvebu/include/mach/cpu.h |  11 +
  board/CZ.NIC/turris_mox/turris_mox.c   |  27 +--
  configs/turris_mox_defconfig   |   2 +-
  7 files changed, 361 insertions(+), 89 deletions(-)
  create mode 100644 arch/arm/mach-mvebu/armada8k/dram.c




Viele Grüße,
Stefan

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

Re: [PATCH v5 3/5] cmd: mvebu: bubt: verify A38x target device type

[Stefan Roese]

Hi Joel,

On 24.03.20 15:23, Joel Johnson wrote:

Ensure that the device to which an image is being written includes
header information indicating boot support for the destination
device.

This is derived from the support in the SolidRun master-a38x vendor
fork.

Signed-off-by: Joel Johnson 
Reviewed-by: Stefan Roese 

---

v2 changes:
   - none
v3 changes:
   - use ARRAY_SIZE instead of #define size
v4 changes:
   - none
v5 changes:
   - use if(IS_ENABLED()) for inline check instead of ifdef

---
  cmd/mvebu/bubt.c | 47 +--
  1 file changed, 45 insertions(+), 2 deletions(-)

diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index b80b81c82a..b03924ca06 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -107,6 +107,24 @@ struct a38x_main_hdr_v1 {
u8  ext;   /* 0x1E  */
u8  checksum;  /* 0x1F  */
  };
+
+struct a38x_boot_mode {
+   unsigned int id;
+   const char *name;
+};
+
+/* The blockid header field values used to indicate boot device of image */
+struct a38x_boot_mode a38x_boot_modes[] = {
+   { 0x4D, "i2c"  },
+   { 0x5A, "spi"  },
+   { 0x69, "uart" },
+   { 0x78, "sata" },
+   { 0x8B, "nand" },
+   { 0x9C, "pex"  },
+   { 0xAE, "mmc"  },
+   {},
+};
+
  #endif
  
  struct bubt_dev {

@@ -644,6 +662,23 @@ static int check_image_header(void)
return 0;
  }
  #elif defined(CONFIG_ARMADA_38X)
+static int a38x_check_boot_mode(const struct bubt_dev *dst)
+{
+   int mode;
+   const struct a38x_main_hdr_v1 *hdr =
+   (struct a38x_main_hdr_v1 *)get_load_addr();
+
+   for (mode = 0; mode < ARRAY_SIZE(a38x_boot_modes); mode++) {
+   if (strcmp(a38x_boot_modes[mode].name, dst->name) == 0)
+   break;
+   }
+
+   if (a38x_boot_modes[mode].id == hdr->blockid)
+   return 0;
+
+   return -ENOEXEC;
+}
+
  static size_t a38x_header_size(const struct a38x_main_hdr_v1 *h)
  {
if (h->version == 1)
@@ -697,7 +732,7 @@ static int check_image_header(void)
  }
  #endif
  
-static int bubt_verify(size_t image_size)

+static int bubt_verify(const struct bubt_dev *dst)
  {
int err;
  
@@ -708,6 +743,14 @@ static int bubt_verify(size_t image_size)

return err;
}
  
+	if (IS_ENABLED(CONFIG_ARMADA_38X)) {

+   err = a38x_check_boot_mode(dst);


Unfortunately this does not work. I'm getting this warning when
compiling for A37xx boards:

cmd/mvebu/bubt.c: In function ‘bubt_verify’:
cmd/mvebu/bubt.c:758:9: warning: implicit declaration of function 
‘a38x_check_boot_mode’ [-Wimplicit-function-declaration]

   err = a38x_check_boot_mode(dst);
 ^~~~

So we can't use #ifdef in the function desclaration and IS_ENABLED()
in the "if" line above.

It seems that we need to switch back to the #ifdef in the function
description again. Or unconditianally compile a38x_check_boot_mode().
This might be even better. Please give it a try.

Thanks,
Stefan


+   if (err) {
+   puts("Error: image not built for destination 
device!\n");
+   return err;
+   }
+   }
+
return 0;
  }
  
@@ -829,7 +872,7 @@ int do_bubt_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])

if (!image_size)
return -EIO;
  
-	err = bubt_verify(image_size);

+   err = bubt_verify(dst);
if (err)
return err;
  




Viele Grüße,
Stefan

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

Re: [PATCH] arm: stm32mp: cleanup test on eth_env_set_enetaddr result

[Patrice CHOTARD]

Hi

On 4/7/20 4:09 PM, Marek Vasut wrote:
> On 4/7/20 4:07 PM, Patrick Delaunay wrote:
>> Remove the unnecessary inversion on the eth_env_set_enetaddr() result which
>> only make complex the code of setup_mac_address() and display an invalid
>> value in the associated pr_err.
>>
>> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Marek Vasut 

Applied to u-boot-stm/next

Thanks

Patrice

Re: [PATCH v6 11/12] arm: mvebu: clearfog: don't always use SPL MMC

[Stefan Roese]

Hi Joel,

On 23.03.20 21:21, Joel Johnson wrote:

Move MMC booting assuptions from defconfig to Kconfig which
includes as needed based on dependent options.

Signed-off-by: Joel Johnson 
Reviewed-by: Stefan Roese 

---

v2 changes:
   - rebased on master to use Baruch's dynamic MMC/SD offset logic
   - update description, will revisit removal of
 CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC in separate future path if a
 more viable option is identified
v3 changes:
   - none
v4 changes:
   - none
v5 changes:
   - none
v6 changes:
   - none


This generates this warning on (at least) helios4:

...
include/configs/helios4.h:105:0: warning: "CONFIG_SPL_MMC_SUPPORT" redefined
 #define CONFIG_SPL_MMC_SUPPORT

In file included from ././include/linux/kconfig.h:4:0,
 from :0:
include/generated/autoconf.h:83:0: note: this is the location of the 
previous definition

 #define CONFIG_SPL_MMC_SUPPORT 1

In file included from include/config.h:5:0,
 from include/common.h:16,
 from drivers/ddr/marvell/a38x/ddr_ml_wrapper.h:9,
 from drivers/ddr/marvell/a38x/mv_ddr_topology.c:5:
include/configs/helios4.h:105:0: warning: "CONFIG_SPL_MMC_SUPPORT" redefined
 #define CONFIG_SPL_MMC_SUPPORT

In file included from ././include/linux/kconfig.h:4:0,
 from :0:
include/generated/autoconf.h:83:0: note: this is the location of the 
previous definition

 #define CONFIG_SPL_MMC_SUPPORT 1
...

Could you please check and send a new version of this patch?

Please make sure that at least all MVEBU based boards (arm and aarch64)
compile clean with your patches applied.

Thanks,
Stefan


---
  arch/arm/mach-mvebu/Kconfig | 1 +
  configs/clearfog_defconfig  | 2 --
  2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 32191e7157..4b381a2936 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -249,6 +249,7 @@ config MVEBU_SPL_BOOT_DEVICE_MMC
select SPL_DM_GPIO
select SPL_DM_MMC
select SPL_LIBDISK_SUPPORT
+   select SPL_MMC_SUPPORT
  
  config MVEBU_SPL_BOOT_DEVICE_SATA

bool "SATA"
diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
index 6db8b8acf6..601b1997ed 100644
--- a/configs/clearfog_defconfig
+++ b/configs/clearfog_defconfig
@@ -10,7 +10,6 @@ CONFIG_SYS_MALLOC_F_LEN=0x2000
  CONFIG_TARGET_CLEARFOG=y
  CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC=y
  CONFIG_DM_GPIO=y
-CONFIG_SPL_MMC_SUPPORT=y
  CONFIG_SPL_SERIAL_SUPPORT=y
  CONFIG_NR_DRAM_BANKS=2
  CONFIG_SPL=y
@@ -42,7 +41,6 @@ CONFIG_CMD_CACHE=y
  CONFIG_CMD_TIME=y
  # CONFIG_SPL_PARTITION_UUIDS is not set
  CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
-CONFIG_ENV_IS_IN_MMC=y
  CONFIG_NET_RANDOM_ETHADDR=y
  CONFIG_SPL_OF_TRANSLATE=y
  CONFIG_AHCI_MVEBU=y




Viele Grüße,
Stefan

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

Re: [Uboot-stm32] [PATCH 01/11] board: stm32mp1: move board_get_mtdparts in st common directory

[Patrice CHOTARD]

Hi Patrick

On 3/18/20 9:22 AM, Patrick Delaunay wrote:
> Move the stm32mp1 common code board_get_mtdparts() in common directory,
> this patch reduce the maintenance effort on this generic part (not board
> dependent).
>
> Signed-off-by: Patrick Delaunay 
> ---

Reviewed-by: Patrice Chotard 

Patrice


>
>  board/dhelectronics/dh_stm32mp1/Makefile |   1 +
>  board/dhelectronics/dh_stm32mp1/board.c  |  89 --
>  board/st/common/Makefile |   4 +
>  board/st/common/stm32mp_mtdparts.c   | 115 +++
>  board/st/stm32mp1/stm32mp1.c | 102 
>  5 files changed, 120 insertions(+), 191 deletions(-)
>  create mode 100644 board/st/common/stm32mp_mtdparts.c
>
> diff --git a/board/dhelectronics/dh_stm32mp1/Makefile 
> b/board/dhelectronics/dh_stm32mp1/Makefile
> index b42c4e4c04..c77a1e3a84 100644
> --- a/board/dhelectronics/dh_stm32mp1/Makefile
> +++ b/board/dhelectronics/dh_stm32mp1/Makefile
> @@ -8,3 +8,4 @@ obj-y += ../../st/stm32mp1/spl.o
>  endif
>  
>  obj-y += ../../st/stm32mp1/board.o board.o
> +obj-$(CONFIG_SYS_MTDPARTS_RUNTIME) += ../../st/common/stm32mp_mtdparts.o
> diff --git a/board/dhelectronics/dh_stm32mp1/board.c 
> b/board/dhelectronics/dh_stm32mp1/board.c
> index b663696983..2baa36278c 100644
> --- a/board/dhelectronics/dh_stm32mp1/board.c
> +++ b/board/dhelectronics/dh_stm32mp1/board.c
> @@ -519,95 +519,6 @@ enum env_location env_get_location(enum env_operation 
> op, int prio)
>  #endif
>  }
>  
> -#ifdef CONFIG_SYS_MTDPARTS_RUNTIME
> -
> -#define MTDPARTS_LEN 256
> -#define MTDIDS_LEN   128
> -
> -/**
> - * The mtdparts_nand0 and mtdparts_nor0 variable tends to be long.
> - * If we need to access it before the env is relocated, then we need
> - * to use our own stack buffer. gd->env_buf will be too small.
> - *
> - * @param buf temporary buffer pointer MTDPARTS_LEN long
> - * @return mtdparts variable string, NULL if not found
> - */
> -static const char *env_get_mtdparts(const char *str, char *buf)
> -{
> - if (gd->flags & GD_FLG_ENV_READY)
> - return env_get(str);
> - if (env_get_f(str, buf, MTDPARTS_LEN) != -1)
> - return buf;
> -
> - return NULL;
> -}
> -
> -/**
> - * update the variables "mtdids" and "mtdparts" with content of 
> mtdparts_
> - */
> -static void board_get_mtdparts(const char *dev,
> -char *mtdids,
> -char *mtdparts)
> -{
> - char env_name[32] = "mtdparts_";
> - char tmp_mtdparts[MTDPARTS_LEN];
> - const char *tmp;
> -
> - /* name of env variable to read = mtdparts_ */
> - strcat(env_name, dev);
> - tmp = env_get_mtdparts(env_name, tmp_mtdparts);
> - if (tmp) {
> - /* mtdids: "=, " */
> - if (mtdids[0] != '\0')
> - strcat(mtdids, ",");
> - strcat(mtdids, dev);
> - strcat(mtdids, "=");
> - strcat(mtdids, dev);
> -
> - /* mtdparts: "mtdparts=:>;..." */
> - if (mtdparts[0] != '\0')
> - strncat(mtdparts, ";", MTDPARTS_LEN);
> - else
> - strcat(mtdparts, "mtdparts=");
> - strncat(mtdparts, dev, MTDPARTS_LEN);
> - strncat(mtdparts, ":", MTDPARTS_LEN);
> - strncat(mtdparts, tmp, MTDPARTS_LEN);
> - }
> -}
> -
> -void board_mtdparts_default(const char **mtdids, const char **mtdparts)
> -{
> - struct udevice *dev;
> - static char parts[3 * MTDPARTS_LEN + 1];
> - static char ids[MTDIDS_LEN + 1];
> - static bool mtd_initialized;
> -
> - if (mtd_initialized) {
> - *mtdids = ids;
> - *mtdparts = parts;
> - return;
> - }
> -
> - memset(parts, 0, sizeof(parts));
> - memset(ids, 0, sizeof(ids));
> -
> - /* probe all MTD devices */
> - for (uclass_first_device(UCLASS_MTD, &dev);
> -  dev;
> -  uclass_next_device(&dev)) {
> - pr_debug("mtd device = %s\n", dev->name);
> - }
> -
> - if (!uclass_get_device(UCLASS_SPI_FLASH, 0, &dev))
> - board_get_mtdparts("nor0", ids, parts);
> -
> - mtd_initialized = true;
> - *mtdids = ids;
> - *mtdparts = parts;
> - debug("%s:mtdids=%s & mtdparts=%s\n", __func__, ids, parts);
> -}
> -#endif
> -
>  #if defined(CONFIG_OF_BOARD_SETUP)
>  int ft_board_setup(void *blob, bd_t *bd)
>  {
> diff --git a/board/st/common/Makefile b/board/st/common/Makefile
> index 8553606b90..4bb8b49867 100644
> --- a/board/st/common/Makefile
> +++ b/board/st/common/Makefile
> @@ -4,3 +4,7 @@
>  #
>  
>  obj-$(CONFIG_CMD_STBOARD) += cmd_stboard.o
> +
> +ifeq ($(CONFIG_ARCH_STM32MP),y)
> +obj-$(CONFIG_SYS_MTDPARTS_RUNTIME) += stm32mp_mtdparts.o
> +endif
> diff --git a/board/st/common/stm32mp_mtdparts.c 
> b/board/st/common/stm32mp_mtdparts.c
> new file mode 100644
> index 00..d77e075864
> --- /dev/null
> +++ b/board/st/common/stm32mp_

[RFC PATCH v2 1/2] arch: x86: apl: Only load VBT if CONFIG_HAVE_VBT is enabled

[Bernhard Messerklinger]

Only load VBT if it's present in the u-boot.rom.

Signed-off-by: Bernhard Messerklinger 
---

Changes in v2: None

 arch/x86/cpu/apollolake/fsp_s.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/x86/cpu/apollolake/fsp_s.c b/arch/x86/cpu/apollolake/fsp_s.c
index 1f22c1ea3c..458825bc49 100644
--- a/arch/x86/cpu/apollolake/fsp_s.c
+++ b/arch/x86/cpu/apollolake/fsp_s.c
@@ -327,16 +327,17 @@ int fsps_update_config(struct udevice *dev, ulong 
rom_offset,
 {
struct fsp_s_config *cfg = &upd->config;
struct apl_config *apl;
+#ifdef CONFIG_HAVE_VBT
struct binman_entry vbt;
-   void *buf;
int ret;
+   void *vbt_buf;
 
ret = binman_entry_find("intel-vbt", &vbt);
if (ret)
return log_msg_ret("Cannot find VBT", ret);
vbt.image_pos += rom_offset;
-   buf = malloc(vbt.size);
-   if (!buf)
+   vbt_buf = malloc(vbt.size);
+   if (!vbt_buf)
return log_msg_ret("Alloc VBT", -ENOMEM);
 
/*
@@ -344,11 +345,12 @@ int fsps_update_config(struct udevice *dev, ulong 
rom_offset,
 * memory-mapped SPI at present.
 */
bootstage_start(BOOTSTAGE_ID_ACCUM_MMAP_SPI, "mmap_spi");
-   memcpy(buf, (void *)vbt.image_pos, vbt.size);
+   memcpy(vbt_buf, (void *)vbt.image_pos, vbt.size);
bootstage_accum(BOOTSTAGE_ID_ACCUM_MMAP_SPI);
-   if (*(u32 *)buf != VBT_SIGNATURE)
+   if (*(u32 *)vbt_buf != VBT_SIGNATURE)
return log_msg_ret("VBT signature", -EINVAL);
-   cfg->graphics_config_ptr = (ulong)buf;
+   cfg->graphics_config_ptr = (ulong)vbt_buf;
+#endif
 
apl = malloc(sizeof(*apl));
if (!apl)
-- 
2.26.0

[RFC PATCH v2 0/2] Move FSP-S configuration to device-tree

[Bernhard Messerklinger]

This patch series moves the configuration of FPS-S for Apollo Lake
based SoCs from the code to the device-tree.

This is similar to the previous patch series for FSP-M.
If wanted, I can also send FSP-M and FSP-S patch as a single series.

Changes in v2:
Remove FSP-M binding file

Bernhard Messerklinger (2):
  arch: x86: apl: Only load VBT if CONFIG_HAVE_VBT is enabled
  arch: x86: apl: Read FSP-S configuration from device-tree

 arch/x86/cpu/apollolake/fsp_s.c   | 1084 +++--
 arch/x86/dts/chromebook_coral.dts |   35 +-
 .../asm/arch-apollolake/fsp/fsp_s_upd.h   |  268 
 .../fsp/fsp2/apollolake/fsp-s.txt |  485 
 4 files changed, 1497 insertions(+), 375 deletions(-)
 create mode 100644 doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-s.txt

-- 
2.26.0

[RFC PATCH v2 2/2] arch: x86: apl: Read FSP-S configuration from device-tree

[Bernhard Messerklinger]

Move FSP-S configuration to the device-tree like it's already done for
other SoCs (Baytrail).

Signed-off-by: Bernhard Messerklinger 
---

Changes in v2:
Remove FSP-M binding file

 arch/x86/cpu/apollolake/fsp_s.c   | 1070 +++--
 arch/x86/dts/chromebook_coral.dts |   35 +-
 .../asm/arch-apollolake/fsp/fsp_s_upd.h   |  268 +
 .../fsp/fsp2/apollolake/fsp-s.txt |  485 
 4 files changed, 1489 insertions(+), 369 deletions(-)
 create mode 100644 doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-s.txt

diff --git a/arch/x86/cpu/apollolake/fsp_s.c b/arch/x86/cpu/apollolake/fsp_s.c
index 458825bc49..7d516adc92 100644
--- a/arch/x86/cpu/apollolake/fsp_s.c
+++ b/arch/x86/cpu/apollolake/fsp_s.c
@@ -27,309 +27,90 @@
 #define INTEL_GSPI_MAX 3
 #define MAX_USB2_PORTS 8
 
-enum {
-   CHIPSET_LOCKDOWN_FSP = 0, /* FSP handles locking per UPDs */
-   CHIPSET_LOCKDOWN_COREBOOT, /* coreboot handles locking */
-};
-
-/* Serial IRQ control. SERIRQ_QUIET is the default (0) */
-enum serirq_mode {
-   SERIRQ_QUIET,
-   SERIRQ_CONTINUOUS,
-   SERIRQ_OFF,
-};
-
-struct gspi_cfg {
-   /* Bus speed in MHz */
-   u32 speed_mhz;
-   /* Bus should be enabled prior to ramstage with temporary base */
-   u8 early_init;
-};
-
-/*
- * This structure will hold data required by common blocks.
- * These are soc specific configurations which will be filled by soc.
- * We'll fill this structure once during init and use the data in common block.
- */
-struct soc_intel_common_config {
-   int chipset_lockdown;
-   struct gspi_cfg gspi[INTEL_GSPI_MAX];
-};
-
-enum pnp_settings {
-   PNP_PERF,
-   PNP_POWER,
-   PNP_PERF_POWER,
-};
-
-struct usb2_eye_per_port {
-   u8 per_port_tx_pe_half;
-   u8 per_port_pe_txi_set;
-   u8 per_port_txi_set;
-   u8 hs_skew_sel;
-   u8 usb_tx_emphasis_en;
-   u8 per_port_rxi_set;
-   u8 hs_npre_drv_sel;
-   u8 override_en;
-};
-
-struct apl_config {
-   /* Common structure containing soc config data required by common code*/
-   struct soc_intel_common_config common_soc_config;
-
-   /*
-* Mapping from PCIe root port to CLKREQ input on the SOC. The SOC has
-* four CLKREQ inputs, but six root ports. Root ports without an
-* associated CLKREQ signal must be marked with "CLKREQ_DISABLED"
-*/
-   u8 pcie_rp_clkreq_pin[MAX_PCIE_PORTS];
-
-   /* Enable/disable hot-plug for root ports (0 = disable, 1 = enable) */
-   u8 pcie_rp_hotplug_enable[MAX_PCIE_PORTS];
-
-   /* De-emphasis enable configuration for each PCIe root port */
-   u8 pcie_rp_deemphasis_enable[MAX_PCIE_PORTS];
-
-   /*
-* [14:8] DDR mode Number of dealy elements.Each = 125pSec.
-* [6:0] SDR mode Number of dealy elements.Each = 125pSec.
-*/
-   u32 emmc_tx_cmd_cntl;
-
-   /*
-* [14:8] HS400 mode Number of dealy elements.Each = 125pSec.
-* [6:0] SDR104/HS200 mode Number of dealy elements.Each = 125pSec.
-*/
-   u32 emmc_tx_data_cntl1;
-
-   /*
-* [30:24] SDR50 mode Number of dealy elements.Each = 125pSec.
-* [22:16] DDR50 mode Number of dealy elements.Each = 125pSec.
-* [14:8] SDR25/HS50 mode Number of dealy elements.Each = 125pSec.
-* [6:0] SDR12/Compatibility mode Number of dealy elements.
-*   Each = 125pSec.
-*/
-   u32 emmc_tx_data_cntl2;
-
-   /*
-* [30:24] SDR50 mode Number of dealy elements.Each = 125pSec.
-* [22:16] DDR50 mode Number of dealy elements.Each = 125pSec.
-* [14:8] SDR25/HS50 mode Number of dealy elements.Each = 125pSec.
-* [6:0] SDR12/Compatibility mode Number of dealy elements.
-*   Each = 125pSec.
-*/
-   u32 emmc_rx_cmd_data_cntl1;
-
-   /*
-* [14:8] HS400 mode 1 Number of dealy elements.Each = 125pSec.
-* [6:0] HS400 mode 2 Number of dealy elements.Each = 125pSec.
-*/
-   u32 emmc_rx_strobe_cntl;
-
-   /*
-* [13:8] Auto Tuning mode Number of dealy elements.Each = 125pSec.
-* [6:0] SDR104/HS200 Number of dealy elements.Each = 125pSec.
-*/
-   u32 emmc_rx_cmd_data_cntl2;
-
-   /* Select the eMMC max speed allowed */
-   u32 emmc_host_max_speed;
-
-   /* Specifies on which IRQ the SCI will internally appear */
-   u32 sci_irq;
-
-   /* Configure serial IRQ (SERIRQ) line */
-   enum serirq_mode serirq_mode;
-
-   /* Configure LPSS S0ix Enable */
-   bool lpss_s0ix_enable;
-
-   /* Enable DPTF support */
-   bool dptf_enable;
-
-   /* TCC activation offset value in degrees Celsius */
-   int tcc_offset;
-
-   /*
-* Configure Audio clk gate and power gate
-* IOSF-SB port ID 92 offset 0x530 [5] and [3]
-*/
-   bool hdaudio_clk_gate_enable;
-   bool hdaudio_pwr_gate_enable;
-   bool hdaudi

Re: [Uboot-stm32] [PATCH 02/11] board: stm32mp1: move set_dfu_alt_info in st common directory

[Patrice CHOTARD]

Hi

On 3/18/20 9:22 AM, Patrick Delaunay wrote:
> Move the stm32mp1 common code set_dfu_alt_info() in common directory,
> this patch reduce the maintenance effort on this generic part (not board
> dependent).
>
> Signed-off-by: Patrick Delaunay 
> ---


Reviewed-by: Patrice Chotard 

Patrice

>
>  board/dhelectronics/dh_stm32mp1/Makefile |   2 +
>  board/dhelectronics/dh_stm32mp1/board.c  |  50 
>  board/st/common/Makefile |   1 +
>  board/st/common/stm32mp_dfu.c| 151 +++
>  board/st/stm32mp1/stm32mp1.c | 145 --
>  5 files changed, 154 insertions(+), 195 deletions(-)
>  create mode 100644 board/st/common/stm32mp_dfu.c
>
> diff --git a/board/dhelectronics/dh_stm32mp1/Makefile 
> b/board/dhelectronics/dh_stm32mp1/Makefile
> index c77a1e3a84..e8f218da08 100644
> --- a/board/dhelectronics/dh_stm32mp1/Makefile
> +++ b/board/dhelectronics/dh_stm32mp1/Makefile
> @@ -8,4 +8,6 @@ obj-y += ../../st/stm32mp1/spl.o
>  endif
>  
>  obj-y += ../../st/stm32mp1/board.o board.o
> +
>  obj-$(CONFIG_SYS_MTDPARTS_RUNTIME) += ../../st/common/stm32mp_mtdparts.o
> +obj-$(CONFIG_SET_DFU_ALT_INFO) += ../../st/common/stm32mp_dfu.o
> diff --git a/board/dhelectronics/dh_stm32mp1/board.c 
> b/board/dhelectronics/dh_stm32mp1/board.c
> index 2baa36278c..bd6540a2aa 100644
> --- a/board/dhelectronics/dh_stm32mp1/board.c
> +++ b/board/dhelectronics/dh_stm32mp1/board.c
> @@ -526,56 +526,6 @@ int ft_board_setup(void *blob, bd_t *bd)
>  }
>  #endif
>  
> -#ifdef CONFIG_SET_DFU_ALT_INFO
> -#define DFU_ALT_BUF_LEN SZ_1K
> -
> -static void board_get_alt_info(const char *dev, char *buff)
> -{
> - char var_name[32] = "dfu_alt_info_";
> - int ret;
> -
> - ALLOC_CACHE_ALIGN_BUFFER(char, tmp_alt, DFU_ALT_BUF_LEN);
> -
> - /* name of env variable to read = dfu_alt_info_ */
> - strcat(var_name, dev);
> - ret = env_get_f(var_name, tmp_alt, DFU_ALT_BUF_LEN);
> - if (ret) {
> - if (buff[0] != '\0')
> - strcat(buff, "&");
> - strncat(buff, tmp_alt, DFU_ALT_BUF_LEN);
> - }
> -}
> -
> -void set_dfu_alt_info(char *interface, char *devstr)
> -{
> - struct udevice *dev;
> -
> - ALLOC_CACHE_ALIGN_BUFFER(char, buf, DFU_ALT_BUF_LEN);
> -
> - if (env_get("dfu_alt_info"))
> - return;
> -
> - memset(buf, 0, sizeof(buf));
> -
> - /* probe all MTD devices */
> - mtd_probe_devices();
> -
> - board_get_alt_info("ram", buf);
> -
> - if (!uclass_get_device(UCLASS_MMC, 0, &dev))
> - board_get_alt_info("mmc0", buf);
> -
> - if (!uclass_get_device(UCLASS_MMC, 1, &dev))
> - board_get_alt_info("mmc1", buf);
> -
> - if (!uclass_get_device(UCLASS_SPI_FLASH, 0, &dev))
> - board_get_alt_info("nor0", buf);
> -
> - env_set("dfu_alt_info", buf);
> - puts("DFU alt info setting: done\n");
> -}
> -#endif
> -
>  static void board_copro_image_process(ulong fw_image, size_t fw_size)
>  {
>   int ret, id = 0; /* Copro id fixed to 0 as only one coproc on mp1 */
> diff --git a/board/st/common/Makefile b/board/st/common/Makefile
> index 4bb8b49867..aa030bacd8 100644
> --- a/board/st/common/Makefile
> +++ b/board/st/common/Makefile
> @@ -7,4 +7,5 @@ obj-$(CONFIG_CMD_STBOARD) += cmd_stboard.o
>  
>  ifeq ($(CONFIG_ARCH_STM32MP),y)
>  obj-$(CONFIG_SYS_MTDPARTS_RUNTIME) += stm32mp_mtdparts.o
> +obj-$(CONFIG_SET_DFU_ALT_INFO) += stm32mp_dfu.o
>  endif
> diff --git a/board/st/common/stm32mp_dfu.c b/board/st/common/stm32mp_dfu.c
> new file mode 100644
> index 00..99ea21ce15
> --- /dev/null
> +++ b/board/st/common/stm32mp_dfu.c
> @@ -0,0 +1,151 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> +/*
> + * Copyright (C) 2020, STMicroelectronics - All Rights Reserved
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DFU_ALT_BUF_LEN SZ_1K
> +
> +static void board_get_alt_info(const char *dev, char *buff)
> +{
> + char var_name[32] = "dfu_alt_info_";
> + int ret;
> +
> + ALLOC_CACHE_ALIGN_BUFFER(char, tmp_alt, DFU_ALT_BUF_LEN);
> +
> + /* name of env variable to read = dfu_alt_info_ */
> + strcat(var_name, dev);
> + ret = env_get_f(var_name, tmp_alt, DFU_ALT_BUF_LEN);
> + if (ret) {
> + if (buff[0] != '\0')
> + strcat(buff, "&");
> + strncat(buff, tmp_alt, DFU_ALT_BUF_LEN);
> + }
> +}
> +
> +void set_dfu_alt_info(char *interface, char *devstr)
> +{
> + struct udevice *dev;
> + struct mtd_info *mtd;
> +
> + ALLOC_CACHE_ALIGN_BUFFER(char, buf, DFU_ALT_BUF_LEN);
> +
> + if (env_get("dfu_alt_info"))
> + return;
> +
> + memset(buf, 0, sizeof(buf));
> +
> + /* probe all MTD devices */
> + mtd_probe_devices();
> +
> + board_get_alt_info("ram", buf);
> +
> + if (!uclass_get_device(UCLASS_MMC, 0, &dev))
> + board_get_alt_info("mmc0", buf);

Re: [Uboot-stm32] [PATCH 03/11] stm32mp1: dynamically build DFU_ALT_INFO

[Patrice CHOTARD]

Hi

On 3/18/20 9:22 AM, Patrick Delaunay wrote:
> This patch reduces the stm32mp1 environment size and
> builds dynamically the DFU board configuration with gpt
> and mtd partitions and information from defconfig
> (CONFIG_DFU_ALT_RAM0).
>
> Signed-off-by: Patrick Delaunay 
> ---


Reviewed-by: Patrice Chotard 

Patrice

>
>  board/dhelectronics/dh_stm32mp1/Kconfig |   1 +
>  board/st/common/Kconfig |   7 ++
>  board/st/common/stm32mp_dfu.c   | 130 +++-
>  include/configs/stm32mp1.h  |  33 --
>  4 files changed, 110 insertions(+), 61 deletions(-)
>
> diff --git a/board/dhelectronics/dh_stm32mp1/Kconfig 
> b/board/dhelectronics/dh_stm32mp1/Kconfig
> index 8eab986640..69cc48f120 100644
> --- a/board/dhelectronics/dh_stm32mp1/Kconfig
> +++ b/board/dhelectronics/dh_stm32mp1/Kconfig
> @@ -18,4 +18,5 @@ config ENV_OFFSET
>  config ENV_OFFSET_REDUND
>   default 0x1F if ENV_IS_IN_SPI_FLASH
>  
> +source "board/st/common/Kconfig"
>  endif
> diff --git a/board/st/common/Kconfig b/board/st/common/Kconfig
> index af01ca4891..08df845982 100644
> --- a/board/st/common/Kconfig
> +++ b/board/st/common/Kconfig
> @@ -5,3 +5,10 @@ config CMD_STBOARD
>   help
> This compile the stboard command to
> read and write the board in the OTP.
> +
> +config DFU_ALT_RAM0
> + string "dfu for ram0"
> + default "uImage ram 0xc200 0x200;devicetree.dtb ram 0xc400 
> 0x10;uramdisk.image.gz ram 0xc440 0x1000"
> + depends on ARCH_STM32MP && SET_DFU_ALT_INFO
> + help
> +   This defines the partitions of ram used to build dfu dynamically.
> diff --git a/board/st/common/stm32mp_dfu.c b/board/st/common/stm32mp_dfu.c
> index 99ea21ce15..e129f8c8b5 100644
> --- a/board/st/common/stm32mp_dfu.c
> +++ b/board/st/common/stm32mp_dfu.c
> @@ -4,6 +4,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -13,20 +14,86 @@
>  
>  #define DFU_ALT_BUF_LEN SZ_1K
>  
> -static void board_get_alt_info(const char *dev, char *buff)
> +static void board_get_alt_info_mmc(struct udevice *dev, char *buf)
>  {
> - char var_name[32] = "dfu_alt_info_";
> - int ret;
> + disk_partition_t info;
> + int p, len, devnum;
> + bool first = true;
> + const char *name;
> + struct mmc *mmc;
> + struct blk_desc *desc;
> +
> + mmc = mmc_get_mmc_dev(dev);
> + if (!mmc)
> + return;
> +
> + if (mmc_init(mmc))
> + return;
> +
> + desc = mmc_get_blk_desc(mmc);
> + if (!desc)
> + return;
> +
> + name = blk_get_if_type_name(desc->if_type);
> + devnum = desc->devnum;
> + len = strlen(buf);
> +
> + if (buf[0] != '\0')
> + len += snprintf(buf + len,
> + DFU_ALT_BUF_LEN - len, "&");
> + len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
> +  "%s %d=", name, devnum);
> +
> + if (IS_MMC(mmc) && mmc->capacity_boot) {
> + len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
> + "%s%d_boot1 raw 0x0 0x%llx mmcpart 1;",
> + name, devnum, mmc->capacity_boot);
> + len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
> + "%s%d_boot2 raw 0x0 0x%llx mmcpart 2",
> + name, devnum, mmc->capacity_boot);
> + first = false;
> + }
>  
> - ALLOC_CACHE_ALIGN_BUFFER(char, tmp_alt, DFU_ALT_BUF_LEN);
> + for (p = 1; p < MAX_SEARCH_PARTITIONS; p++) {
> + if (part_get_info(desc, p, &info))
> + continue;
> + if (!first)
> + len += snprintf(buf + len, DFU_ALT_BUF_LEN - len, ";");
> + first = false;
> + len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
> + "%s%d_%s part %d %d",
> + name, devnum, info.name, devnum, p);
> + }
> +}
>  
> - /* name of env variable to read = dfu_alt_info_ */
> - strcat(var_name, dev);
> - ret = env_get_f(var_name, tmp_alt, DFU_ALT_BUF_LEN);
> - if (ret) {
> - if (buff[0] != '\0')
> - strcat(buff, "&");
> - strncat(buff, tmp_alt, DFU_ALT_BUF_LEN);
> +static void board_get_alt_info_mtd(struct mtd_info *mtd, char *buf)
> +{
> + struct mtd_info *part;
> + bool first = true;
> + const char *name;
> + int len, partnum = 0;
> +
> + name = mtd->name;
> + len = strlen(buf);
> +
> + if (buf[0] != '\0')
> + len += snprintf(buf + len, DFU_ALT_BUF_LEN - len, "&");
> + len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
> + "mtd %s=", name);
> +
> + len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
> + "%s raw 0x0 0x%llx ",
> + name, mtd->size);
> +
> + list_for_each_entry(part, &mtd->partitions, node) {
> +

Re: [Uboot-stm32] [PATCH 04/11] stm32mp1: move MTDPART configuration in Kconfig

[Patrice CHOTARD]

Hi

On 3/18/20 9:22 AM, Patrick Delaunay wrote:
> This patch reduces the stm32mp1 environment size and builds
> dynamically the MTD partitions with information from defconfig
> (CONFIG_MTDPARTS_...).
>
> Signed-off-by: Patrick Delaunay 
> ---

Reviewed-by: Patrice Chotard 

Patrice


>  board/st/common/Kconfig| 57 ++
>  board/st/common/stm32mp_mtdparts.c | 93 +++---
>  include/configs/stm32mp1.h | 22 ---
>  3 files changed, 104 insertions(+), 68 deletions(-)
>
> diff --git a/board/st/common/Kconfig b/board/st/common/Kconfig
> index 08df845982..015ba40939 100644
> --- a/board/st/common/Kconfig
> +++ b/board/st/common/Kconfig
> @@ -6,6 +6,63 @@ config CMD_STBOARD
> This compile the stboard command to
> read and write the board in the OTP.
>  
> +config MTDPARTS_NAND0_BOOT
> + string "mtd boot partitions for nand0"
> + default "2m(fsbl),2m(ssbl1),2m(ssbl2)"
> + depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP
> + help
> +   This define the partitions of nand0 used to build mtparts dynamically
> +   for boot from nand0.
> +   Each partition need to be aligned with the device erase block size,
> +   512KB is the max size for the NAND supported by stm32mp1 platform.
> +
> +config MTDPARTS_NAND0_TEE
> + string "mtd tee partitions for nand0"
> + default "512k(teeh),512k(teed),512k(teex)"
> + depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP
> + help
> +   This define the tee partitions added in mtparts dynamically
> +   when tee is supported with boot from nand0.
> +   Each partition need to be aligned with the device erase block size,
> +   512KB is the max size for the NAND supported by stm32mp1 platform.
> +
> +config MTDPARTS_NOR0_BOOT
> + string "mtd boot partitions for nor0"
> + default "256k(fsbl1),256k(fsbl2),2m(ssbl),512k(u-boot-env)"
> + depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP
> + help
> +   This define the partitions of nand0 used to build mtparts dynamically
> +   for boot from nor0.
> +   Each partition need to be aligned with the device erase block size,
> +   with 256KB we support all the NOR.
> +   U-Boot env partition (512kB) use 2 erase block for redundancy.
> +
> +config MTDPARTS_NOR0_TEE
> + string "mtd tee partitions for nor0"
> + default "256k(teeh),256k(teed),256k(teex)"
> + depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP
> + help
> +   This define the tee partitions added in mtparts dynamically
> +   when tee is supported with boot from nor0.
> +
> +config MTDPARTS_SPINAND0_BOOT
> + string "mtd boot partitions for spi-nand0"
> + default "2m(fsbl),2m(ssbl1),2m(ssbl2)"
> + depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP
> + help
> +   This define the partitions of nand0 used to build mtparts dynamically
> +   for boot from spi-nand0,
> +   512KB is the max size for the NAND supported by stm32mp1 platform.
> +
> +config MTDPARTS_SPINAND0_TEE
> + string "mtd tee partitions for spi-nand0"
> + default "512k(teeh),512k(teed),512k(teex)"
> + depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP
> + help
> +   This define the tee partitions added in mtparts dynamically
> +   when tee is supported with boot from spi-nand0,
> +   512KB is the max size for the NAND supported by stm32mp1 platform.
> +
>  config DFU_ALT_RAM0
>   string "dfu for ram0"
>   default "uImage ram 0xc200 0x200;devicetree.dtb ram 0xc400 
> 0x10;uramdisk.image.gz ram 0xc440 0x1000"
> diff --git a/board/st/common/stm32mp_mtdparts.c 
> b/board/st/common/stm32mp_mtdparts.c
> index d77e075864..d4c0a7db9f 100644
> --- a/board/st/common/stm32mp_mtdparts.c
> +++ b/board/st/common/stm32mp_mtdparts.c
> @@ -19,54 +19,42 @@
>  DECLARE_GLOBAL_DATA_PTR;
>  
>  /**
> - * The mtdparts_nand0 and mtdparts_nor0 variable tends to be long.
> - * If we need to access it before the env is relocated, then we need
> - * to use our own stack buffer. gd->env_buf will be too small.
> - *
> - * @param buf temporary buffer pointer MTDPARTS_LEN long
> - * @return mtdparts variable string, NULL if not found
> - */
> -static const char *env_get_mtdparts(const char *str, char *buf)
> -{
> - if (gd->flags & GD_FLG_ENV_READY)
> - return env_get(str);
> - if (env_get_f(str, buf, MTDPARTS_LEN) != -1)
> - return buf;
> -
> - return NULL;
> -}
> -
> -/**
> - * update the variables "mtdids" and "mtdparts" with content of 
> mtdparts_
> + * update the variables "mtdids" and "mtdparts" with boot, tee and user 
> strings
>   */
>  static void board_get_mtdparts(const char *dev,
>  char *mtdids,
> -char *mtdparts)
> +char *mtdparts,
> +const char *boot,
> +const char *tee,
> +const char 

Re: [Uboot-stm32] [PATCH 10/11] board: stm32mp1: adapt MTD partition for BOOT from NOR or NAND

[Patrice CHOTARD]

Hi

On 3/18/20 9:22 AM, Patrick Delaunay wrote:
> Dynamically adapt the MTD partitions in NAND and SPI-NAND when boot from
> NOR or NAND/SPI-NAND is detected.
>
> This patch avoids to define the save MTD partition name for NOR and NAND
> devices and issue with latest kernel: only the needed MTD partitions
> are defined.
>
> For boot from NOR
> 1/ bootloader (TF-A, U-Boot and OP-TE) in NOR
> 2/ one large UBI partition in NAND
>
> For boot from NAND
> 1/ bootloader (TF-A, U-Boot and OP-TE) in MTD raw partition
> 2/ one large UBI partition
>
> Signed-off-by: Patrick Delaunay 
>
> # Conflicts:
> # board/st/common/stm32mp_mtdparts.c
> ---
>
>  board/st/common/stm32mp_mtdparts.c | 81 ++
>  1 file changed, 60 insertions(+), 21 deletions(-)
>
> diff --git a/board/st/common/stm32mp_mtdparts.c 
> b/board/st/common/stm32mp_mtdparts.c
> index 2b6413be16..5028511077 100644
> --- a/board/st/common/stm32mp_mtdparts.c
> +++ b/board/st/common/stm32mp_mtdparts.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define MTDPARTS_LEN 256
>  #define MTDIDS_LEN   128
> @@ -22,7 +23,7 @@ DECLARE_GLOBAL_DATA_PTR;
>  /**
>   * update the variables "mtdids" and "mtdparts" with boot, tee and user 
> strings
>   */
> -static void board_get_mtdparts(const char *dev,
> +static void board_set_mtdparts(const char *dev,
>  char *mtdids,
>  char *mtdparts,
>  const char *boot,
> @@ -65,7 +66,7 @@ void board_mtdparts_default(const char **mtdids, const char 
> **mtdparts)
>   static char parts[3 * MTDPARTS_LEN + 1];
>   static char ids[MTDIDS_LEN + 1];
>   static bool mtd_initialized;
> - bool tee = false;
> + bool tee, nor, nand, spinand;
>  
>   if (mtd_initialized) {
>   *mtdids = ids;
> @@ -73,6 +74,28 @@ void board_mtdparts_default(const char **mtdids, const 
> char **mtdparts)
>   return;
>   }
>  
> + tee = false;
> + nor = false;
> + nand = false;
> + spinand = false;
> +
> + switch (get_bootmode() & TAMP_BOOT_DEVICE_MASK) {
> + case BOOT_SERIAL_UART:
> + case BOOT_SERIAL_USB:
> + break;
> + case BOOT_FLASH_NAND:
> + nand = true;
> + break;
> + case BOOT_FLASH_SPINAND:
> + spinand = true;
> + break;
> + case BOOT_FLASH_NOR:
> + nor = true;
> + break;
> + default:
> + break;
> + }
> +
>   if (CONFIG_IS_ENABLED(OPTEE) &&
>   tee_find_device(NULL, NULL, NULL, NULL))
>   tee = true;
> @@ -87,29 +110,45 @@ void board_mtdparts_default(const char **mtdids, const 
> char **mtdparts)
>   pr_debug("mtd device = %s\n", dev->name);
>   }
>  
> - mtd = get_mtd_device_nm("nand0");
> - if (!IS_ERR_OR_NULL(mtd)) {
> - board_get_mtdparts("nand0", ids, parts,
> -CONFIG_MTDPARTS_NAND0_BOOT,
> -tee ? CONFIG_MTDPARTS_NAND0_TEE : NULL,
> -"-(UBI)");
> - put_mtd_device(mtd);
> + if (nor || nand) {
> + mtd = get_mtd_device_nm("nand0");
> + if (!IS_ERR_OR_NULL(mtd)) {
> + const char *mtd_boot = CONFIG_MTDPARTS_NAND0_BOOT;
> + const char *mtd_tee = CONFIG_MTDPARTS_NAND0_TEE;
> +
> + board_set_mtdparts("nand0", ids, parts,
> +!nor ? mtd_boot : NULL,
> +!nor && tee ? mtd_tee : NULL,
> +"-(UBI)");
> + put_mtd_device(mtd);
> + }
>   }
>  
> - mtd = get_mtd_device_nm("spi-nand0");
> - if (!IS_ERR_OR_NULL(mtd)) {
> - board_get_mtdparts("spi-nand0", ids, parts,
> -CONFIG_MTDPARTS_SPINAND0_BOOT,
> -tee ? CONFIG_MTDPARTS_SPINAND0_TEE : NULL,
> -"-(UBI)");
> - put_mtd_device(mtd);
> + if (nor || spinand) {
> + mtd = get_mtd_device_nm("spi-nand0");
> + if (!IS_ERR_OR_NULL(mtd)) {
> + const char *mtd_boot = CONFIG_MTDPARTS_SPINAND0_BOOT;
> + const char *mtd_tee = CONFIG_MTDPARTS_SPINAND0_TEE;
> +
> + board_set_mtdparts("spi-nand0", ids, parts,
> +!nor ? mtd_boot : NULL,
> +!nor && tee ? mtd_tee : NULL,
> +"-(UBI)");
> + put_mtd_device(mtd);
> + }
>   }
>  
> - if (!uclass_get_device(UCLASS_SPI_FLASH, 0, &dev))
> - board_get_mtdparts("nor0", ids, parts,
> -CONFIG_MTDPARTS_NOR0_BOOT,
> -

Re: [PATCH 05/11] board: stm32mp1: reserve memory for OP-TEE in device tree

[Patrice CHOTARD]

Hi

On 3/18/20 9:22 AM, Patrick Delaunay wrote:
> Add reserve memory for OP-TEE in U-Boot and in kernel device tree:
> - no more reduce the DDR size in "memory" node:
>   CONFIG_SYS_MEM_TOP_HIDE is no more used
> - U-Boot device-tree defines the needed "reserved-memory" for OP-TEE
>   and U-Boot should not use this reserved memory: board_get_usable_ram_top
>   use lmb lib to found the first free region, the not reserved
>   memory, enough to relocate U-Boot: the needed size of U-Boot
>   is estimated with gd->mon_len + CONFIG_SYS_MALLOC_LEN.
> - the optee node ("optee@...": firmware with compatible "linaro,optee-tz")
>   and the associated "reserved-memory" are deactivated in kernel device
>   tree when OP-TEE is not detected by U-Boot to prevent kernel issue
>   (memory is reserved but not used, optee driver probe failed).
>
> Signed-off-by: Patrick Delaunay 
> ---
> This patch depends on "ARM: bootm: take into account gd->ram_top"
> http://patchwork.ozlabs.org/project/uboot/list/?series=158413
>
>  arch/arm/dts/stm32mp157a-dk1.dts  |  5 +
>  arch/arm/dts/stm32mp157c-ed1.dts  |  5 +
>  arch/arm/mach-stm32mp/dram_init.c | 18 ++
>  arch/arm/mach-stm32mp/fdt.c   | 23 +++
>  include/configs/stm32mp1.h|  4 
>  5 files changed, 51 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp157a-dk1.dts 
> b/arch/arm/dts/stm32mp157a-dk1.dts
> index 624bf6954b..70e7aa2fd7 100644
> --- a/arch/arm/dts/stm32mp157a-dk1.dts
> +++ b/arch/arm/dts/stm32mp157a-dk1.dts
> @@ -74,6 +74,11 @@
>   reg = <0xd400 0x400>;
>   no-map;
>   };
> +
> + optee@de00 {
> + reg = <0xde00 0x0200>;
> + no-map;
> + };
>   };
>  
>   led {
> diff --git a/arch/arm/dts/stm32mp157c-ed1.dts 
> b/arch/arm/dts/stm32mp157c-ed1.dts
> index ae4da39ce8..27a0d05d82 100644
> --- a/arch/arm/dts/stm32mp157c-ed1.dts
> +++ b/arch/arm/dts/stm32mp157c-ed1.dts
> @@ -68,6 +68,11 @@
>   reg = <0xe800 0x800>;
>   no-map;
>   };
> +
> + optee@fe00 {
> + reg = <0xfe00 0x0200>;
> + no-map;
> + };
>   };
>  
>   aliases {
> diff --git a/arch/arm/mach-stm32mp/dram_init.c 
> b/arch/arm/mach-stm32mp/dram_init.c
> index 7688b3e315..3233415eff 100644
> --- a/arch/arm/mach-stm32mp/dram_init.c
> +++ b/arch/arm/mach-stm32mp/dram_init.c
> @@ -5,6 +5,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
> @@ -31,3 +32,20 @@ int dram_init(void)
>  
>   return 0;
>  }
> +
> +ulong board_get_usable_ram_top(ulong total_size)
> +{
> + phys_addr_t reg;
> + struct lmb lmb;
> +
> + /* found enough not-reserved memory to relocated U-Boot */
> + lmb_init(&lmb);
> + lmb_add(&lmb, gd->ram_base, gd->ram_size);
> + boot_fdt_add_mem_rsv_regions(&lmb, (void *)gd->fdt_blob);
> + reg = lmb_alloc(&lmb, CONFIG_SYS_MALLOC_LEN + total_size, SZ_4K);
> +
> + if (reg)
> + return ALIGN(reg + CONFIG_SYS_MALLOC_LEN + total_size, SZ_4K);
> +
> + return gd->ram_top;
> +}
> diff --git a/arch/arm/mach-stm32mp/fdt.c b/arch/arm/mach-stm32mp/fdt.c
> index 3ee7d6a833..ae82270e42 100644
> --- a/arch/arm/mach-stm32mp/fdt.c
> +++ b/arch/arm/mach-stm32mp/fdt.c
> @@ -218,6 +218,26 @@ static void stm32_fdt_disable(void *fdt, int offset, u32 
> addr,
>  string, addr, name);
>  }
>  
> +static void stm32_fdt_disable_optee(void *blob)
> +{
> + int off, node;
> +
> + off = fdt_node_offset_by_compatible(blob, -1, "linaro,optee-tz");
> + if (off >= 0 && fdtdec_get_is_enabled(blob, off))
> + fdt_status_disabled(blob, off);
> +
> + /* Disabled "optee@..." reserved-memory node */
> + off = fdt_path_offset(blob, "/reserved-memory/");
> + if (off < 0)
> + return;
> + for (node = fdt_first_subnode(blob, off);
> +  node >= 0;
> +  node = fdt_next_subnode(blob, node)) {
> + if (!strncmp(fdt_get_name(blob, node, NULL), "optee@", 6))
> + fdt_status_disabled(blob, node);
> + }
> +}
> +
>  /*
>   * This function is called right before the kernel is booted. "blob" is the
>   * device tree that will be passed to the kernel.
> @@ -302,5 +322,8 @@ int ft_system_setup(void *blob, bd_t *bd)
>  "st,package", pkg, false);
>   }
>  
> + if (!CONFIG_IS_ENABLED(STM32MP1_OPTEE))
> + stm32_fdt_disable_optee(blob);
> +
>   return ret;
>  }
> diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
> index a80741f6a2..c5b09f1a2a 100644
> --- a/include/configs/stm32mp1.h
> +++ b/include/configs/stm32mp1.h
> @@ -23,10 +23,6 @@
>  #define CONFIG_SYS_SDRAM_BASESTM32_DDR_BASE
>  #define CONFIG_SYS_INIT_

Re: [PATCH 07/11] board: stm32mp1: use FDT address provided by TF-A at boot time

[Patrice CHOTARD]

Hi

On 3/18/20 9:22 AM, Patrick Delaunay wrote:
> Save and use the FDT address provided by TF-A in r2 at boot time
> (it is NT_FW_CONFIG = Non Trusted Firmware configuration file)
>
> Address is saved in save_boot_params(), called by start.S
> and the used DTB is gd->fdt_blob = board_fdt_blob_setup().
>
> If dtb is not provided or invalid, U-Boot use as fallback
> the builtin DTB.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  arch/arm/mach-stm32mp/Makefile  |  1 +
>  arch/arm/mach-stm32mp/boot_params.c | 45 +
>  2 files changed, 46 insertions(+)
>  create mode 100644 arch/arm/mach-stm32mp/boot_params.c
>
> diff --git a/arch/arm/mach-stm32mp/Makefile b/arch/arm/mach-stm32mp/Makefile
> index eee39c27c3..19ca3b08a5 100644
> --- a/arch/arm/mach-stm32mp/Makefile
> +++ b/arch/arm/mach-stm32mp/Makefile
> @@ -13,6 +13,7 @@ else
>  obj-y += bsec.o
>  obj-$(CONFIG_CMD_STM32KEY) += cmd_stm32key.o
>  obj-$(CONFIG_ARMV7_PSCI) += psci.o
> +obj-$(CONFIG_STM32MP1_TRUSTED) += boot_params.o
>  endif
>  
>  obj-$(CONFIG_$(SPL_)DM_REGULATOR) += pwr_regulator.o
> diff --git a/arch/arm/mach-stm32mp/boot_params.c 
> b/arch/arm/mach-stm32mp/boot_params.c
> new file mode 100644
> index 00..e4351de939
> --- /dev/null
> +++ b/arch/arm/mach-stm32mp/boot_params.c
> @@ -0,0 +1,45 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> +/*
> + * Copyright (C) 2019, STMicroelectronics - All Rights Reserved
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Force data-section, as .bss will not be valid
> + * when save_boot_params is invoked.
> + */
> +static unsigned long nt_fw_dtb __section(".data");
> +
> +/*
> + * Save the FDT address provided by TF-A in r2 at boot time
> + * This function is called from start.S
> + */
> +void save_boot_params(unsigned long r0, unsigned long r1, unsigned long r2,
> +   unsigned long r3)
> +{
> + nt_fw_dtb = r2;
> +
> + save_boot_params_ret();
> +}
> +
> +/*
> + * Use the saved FDT address provided by TF-A at boot time (NT_FW_CONFIG =
> + * Non Trusted Firmware configuration file) when the pointer is valid
> + */
> +void *board_fdt_blob_setup(void)
> +{
> + debug("%s: nt_fw_dtb=%lx\n", __func__, nt_fw_dtb);
> +
> + /* use external device tree only if address is valid */
> + if (nt_fw_dtb >= STM32_DDR_BASE) {
> + if (fdt_magic(nt_fw_dtb) == FDT_MAGIC)
> + return (void *)nt_fw_dtb;
> + debug("%s: DTB not found.\n", __func__);
> + }
> + debug("%s: fall back to builtin DTB, %p\n", __func__, &_end);
> +
> + return (void *)&_end;
> +}

Reviewed-by: Patrice Chotard 

Patrice

Re: [PATCH 06/11] stm32mp1: dynamically detect op-tee presence

[Patrice CHOTARD]

Hi

On 3/18/20 9:22 AM, Patrick Delaunay wrote:
> Activate OP-TEE driver for trusted and optee defconfig.
>
> This driver allows detection of TEE presence for boot from flash;
> CONFIG_STM32MP1_OPTEE is also removed.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  arch/arm/mach-stm32mp/Kconfig   | 10 --
>  arch/arm/mach-stm32mp/fdt.c |  4 +++-
>  board/dhelectronics/dh_stm32mp1/board.c |  4 +---
>  board/st/common/stm32mp_mtdparts.c  |  6 --
>  board/st/stm32mp1/stm32mp1.c|  4 +---
>  configs/stm32mp15_optee_defconfig   |  4 +++-
>  configs/stm32mp15_trusted_defconfig |  3 +++
>  7 files changed, 15 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
> index 96153693a7..1a5545b98d 100644
> --- a/arch/arm/mach-stm32mp/Kconfig
> +++ b/arch/arm/mach-stm32mp/Kconfig
> @@ -93,16 +93,6 @@ config STM32MP1_TRUSTED
>   BootRom => TF-A.stm32 (clock & DDR) => U-Boot.stm32
>   TF-A monitor provides proprietary SMC to manage secure devices
>  
> -config STM32MP1_OPTEE
> - bool "Support trusted boot with TF-A and OP-TEE"
> - depends on STM32MP1_TRUSTED
> - default n
> - help
> - Say Y here to enable boot with TF-A and OP-TEE
> - Trusted boot chain is :
> - BootRom => TF-A.stm32 (clock & DDR) => OP-TEE => U-Boot.stm32
> - OP-TEE monitor provides ST SMC to access to secure resources
> -
>  config SYS_TEXT_BASE
>   default 0xC010
>  
> diff --git a/arch/arm/mach-stm32mp/fdt.c b/arch/arm/mach-stm32mp/fdt.c
> index ae82270e42..21b5f09728 100644
> --- a/arch/arm/mach-stm32mp/fdt.c
> +++ b/arch/arm/mach-stm32mp/fdt.c
> @@ -5,6 +5,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -322,7 +323,8 @@ int ft_system_setup(void *blob, bd_t *bd)
>  "st,package", pkg, false);
>   }
>  
> - if (!CONFIG_IS_ENABLED(STM32MP1_OPTEE))
> + if (!CONFIG_IS_ENABLED(OPTEE) ||
> + !tee_find_device(NULL, NULL, NULL, NULL))
>   stm32_fdt_disable_optee(blob);
>  
>   return ret;
> diff --git a/board/dhelectronics/dh_stm32mp1/board.c 
> b/board/dhelectronics/dh_stm32mp1/board.c
> index bd6540a2aa..ea51b92282 100644
> --- a/board/dhelectronics/dh_stm32mp1/board.c
> +++ b/board/dhelectronics/dh_stm32mp1/board.c
> @@ -117,9 +117,7 @@ int checkboard(void)
>   const char *fdt_compat;
>   int fdt_compat_len;
>  
> - if (IS_ENABLED(CONFIG_STM32MP1_OPTEE))
> - mode = "trusted with OP-TEE";
> - else if (IS_ENABLED(CONFIG_STM32MP1_TRUSTED))
> + if (IS_ENABLED(CONFIG_STM32MP1_TRUSTED))
>   mode = "trusted";
>   else
>   mode = "basic";
> diff --git a/board/st/common/stm32mp_mtdparts.c 
> b/board/st/common/stm32mp_mtdparts.c
> index d4c0a7db9f..2b6413be16 100644
> --- a/board/st/common/stm32mp_mtdparts.c
> +++ b/board/st/common/stm32mp_mtdparts.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define MTDPARTS_LEN 256
>  #define MTDIDS_LEN   128
> @@ -49,7 +50,7 @@ static void board_get_mtdparts(const char *dev,
>   strncat(mtdparts, ",", MTDPARTS_LEN);
>   }
>  
> - if (CONFIG_IS_ENABLED(STM32MP1_OPTEE) && tee) {
> + if (tee) {
>   strncat(mtdparts, tee, MTDPARTS_LEN);
>   strncat(mtdparts, ",", MTDPARTS_LEN);
>   }
> @@ -72,7 +73,8 @@ void board_mtdparts_default(const char **mtdids, const char 
> **mtdparts)
>   return;
>   }
>  
> - if (CONFIG_IS_ENABLED(STM32MP1_OPTEE))
> + if (CONFIG_IS_ENABLED(OPTEE) &&
> + tee_find_device(NULL, NULL, NULL, NULL))
>   tee = true;
>  
>   memset(parts, 0, sizeof(parts));
> diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
> index 2ab3b5cc9a..14c56a0f24 100644
> --- a/board/st/stm32mp1/stm32mp1.c
> +++ b/board/st/stm32mp1/stm32mp1.c
> @@ -87,9 +87,7 @@ int checkboard(void)
>   const char *fdt_compat;
>   int fdt_compat_len;
>  
> - if (IS_ENABLED(CONFIG_STM32MP1_OPTEE))
> - mode = "trusted with OP-TEE";
> - else if (IS_ENABLED(CONFIG_STM32MP1_TRUSTED))
> + if (CONFIG_IS_ENABLED(STM32MP1_TRUSTED))
>   mode = "trusted";
>   else
>   mode = "basic";
> diff --git a/configs/stm32mp15_optee_defconfig 
> b/configs/stm32mp15_optee_defconfig
> index 317cd55862..f0d524d344 100644
> --- a/configs/stm32mp15_optee_defconfig
> +++ b/configs/stm32mp15_optee_defconfig
> @@ -4,7 +4,6 @@ CONFIG_SYS_MALLOC_F_LEN=0x3000
>  CONFIG_ENV_SECT_SIZE=0x4
>  CONFIG_ENV_OFFSET=0x28
>  CONFIG_TARGET_ST_STM32MP15x=y
> -CONFIG_STM32MP1_OPTEE=y
>  CONFIG_ENV_OFFSET_REDUND=0x2C
>  CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_FIT=y
> @@ -111,6 +110,9 @@ CONFIG_SPI=y
>  CONFIG_DM_SPI=y
>  CONFIG_STM32_QSPI=y
>  CONFIG_STM32_SPI=y
> +CONFIG_TEE=y
> +CONFIG_OPTE

Re: [PATCH 08/11] configs: stm32mp1: remove optee defconfig

[Patrice CHOTARD]

Hi

On 3/18/20 9:22 AM, Patrick Delaunay wrote:
> As the op-tee presence is detected by U-boot, the stm32mp15_optee_defconfig
> is identical to stm32mp15_trusted_defconfig and can be removed.
>
> Signed-off-by: Patrick Delaunay 
> ---

Reviewed-by: Patrice Chotard 

Patrice


>  board/st/stm32mp1/MAINTAINERS |   1 -
>  configs/stm32mp15_optee_defconfig | 134 --
>  doc/board/st/stm32mp1.rst |  32 ++-
>  3 files changed, 7 insertions(+), 160 deletions(-)
>  delete mode 100644 configs/stm32mp15_optee_defconfig
>
> diff --git a/board/st/stm32mp1/MAINTAINERS b/board/st/stm32mp1/MAINTAINERS
> index 2930947716..96c4559033 100644
> --- a/board/st/stm32mp1/MAINTAINERS
> +++ b/board/st/stm32mp1/MAINTAINERS
> @@ -6,6 +6,5 @@ S:Maintained
>  F:   arch/arm/dts/stm32mp15*
>  F:   board/st/stm32mp1/
>  F:   configs/stm32mp15_basic_defconfig
> -F:   configs/stm32mp15_optee_defconfig
>  F:   configs/stm32mp15_trusted_defconfig
>  F:   include/configs/stm32mp1.h
> diff --git a/configs/stm32mp15_optee_defconfig 
> b/configs/stm32mp15_optee_defconfig
> deleted file mode 100644
> index f0d524d344..00
> --- a/configs/stm32mp15_optee_defconfig
> +++ /dev/null
> @@ -1,134 +0,0 @@
> -CONFIG_ARM=y
> -CONFIG_ARCH_STM32MP=y
> -CONFIG_SYS_MALLOC_F_LEN=0x3000
> -CONFIG_ENV_SECT_SIZE=0x4
> -CONFIG_ENV_OFFSET=0x28
> -CONFIG_TARGET_ST_STM32MP15x=y
> -CONFIG_ENV_OFFSET_REDUND=0x2C
> -CONFIG_DISTRO_DEFAULTS=y
> -CONFIG_FIT=y
> -CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
> -CONFIG_SYS_PROMPT="STM32MP> "
> -# CONFIG_CMD_BOOTD is not set
> -# CONFIG_CMD_ELF is not set
> -# CONFIG_CMD_IMI is not set
> -# CONFIG_CMD_XIMG is not set
> -# CONFIG_CMD_EXPORTENV is not set
> -# CONFIG_CMD_IMPORTENV is not set
> -CONFIG_CMD_MEMINFO=y
> -CONFIG_CMD_MEMTEST=y
> -CONFIG_CMD_ADC=y
> -CONFIG_CMD_CLK=y
> -CONFIG_CMD_DFU=y
> -CONFIG_CMD_FUSE=y
> -CONFIG_CMD_GPIO=y
> -CONFIG_CMD_GPT=y
> -CONFIG_CMD_I2C=y
> -CONFIG_CMD_MMC=y
> -CONFIG_CMD_MTD=y
> -CONFIG_CMD_REMOTEPROC=y
> -CONFIG_CMD_SPI=y
> -CONFIG_CMD_USB=y
> -CONFIG_CMD_USB_MASS_STORAGE=y
> -CONFIG_CMD_BMP=y
> -CONFIG_CMD_CACHE=y
> -CONFIG_CMD_TIME=y
> -CONFIG_CMD_TIMER=y
> -CONFIG_CMD_PMIC=y
> -CONFIG_CMD_REGULATOR=y
> -CONFIG_CMD_EXT4_WRITE=y
> -CONFIG_CMD_MTDPARTS=y
> -CONFIG_CMD_UBI=y
> -CONFIG_DEFAULT_DEVICE_TREE="stm32mp157c-ev1"
> -CONFIG_ENV_IS_NOWHERE=y
> -CONFIG_ENV_IS_IN_EXT4=y
> -CONFIG_ENV_IS_IN_SPI_FLASH=y
> -CONFIG_ENV_IS_IN_UBI=y
> -CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
> -CONFIG_ENV_EXT4_INTERFACE="mmc"
> -CONFIG_ENV_EXT4_DEVICE_AND_PART="0:auto"
> -CONFIG_ENV_EXT4_FILE="/uboot.env"
> -CONFIG_ENV_UBI_PART="UBI"
> -CONFIG_ENV_UBI_VOLUME="uboot_config"
> -CONFIG_ENV_UBI_VOLUME_REDUND="uboot_config_r"
> -CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> -CONFIG_STM32_ADC=y
> -CONFIG_DFU_MMC=y
> -CONFIG_DFU_RAM=y
> -CONFIG_DFU_MTD=y
> -CONFIG_DFU_VIRT=y
> -CONFIG_SET_DFU_ALT_INFO=y
> -CONFIG_USB_FUNCTION_FASTBOOT=y
> -CONFIG_FASTBOOT_BUF_ADDR=0xC000
> -CONFIG_FASTBOOT_BUF_SIZE=0x0200
> -CONFIG_FASTBOOT_USB_DEV=1
> -CONFIG_FASTBOOT_FLASH=y
> -CONFIG_FASTBOOT_FLASH_MMC_DEV=1
> -CONFIG_DM_HWSPINLOCK=y
> -CONFIG_HWSPINLOCK_STM32=y
> -CONFIG_DM_I2C=y
> -CONFIG_SYS_I2C_STM32F7=y
> -CONFIG_LED=y
> -CONFIG_LED_GPIO=y
> -CONFIG_DM_MAILBOX=y
> -CONFIG_STM32_IPCC=y
> -CONFIG_DM_MMC=y
> -CONFIG_SUPPORT_EMMC_BOOT=y
> -CONFIG_STM32_SDMMC2=y
> -CONFIG_MTD=y
> -CONFIG_DM_MTD=y
> -CONFIG_SYS_MTDPARTS_RUNTIME=y
> -CONFIG_MTD_RAW_NAND=y
> -CONFIG_NAND_STM32_FMC2=y
> -CONFIG_MTD_SPI_NAND=y
> -CONFIG_DM_SPI_FLASH=y
> -CONFIG_SPI_FLASH_MACRONIX=y
> -CONFIG_SPI_FLASH_SPANSION=y
> -CONFIG_SPI_FLASH_STMICRO=y
> -CONFIG_SPI_FLASH_WINBOND=y
> -# CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
> -CONFIG_SPI_FLASH_MTD=y
> -CONFIG_DM_ETH=y
> -CONFIG_DWC_ETH_QOS=y
> -CONFIG_PHY=y
> -CONFIG_PHY_STM32_USBPHYC=y
> -CONFIG_PINCONF=y
> -CONFIG_PINCTRL_STMFX=y
> -CONFIG_DM_PMIC=y
> -CONFIG_PMIC_STPMIC1=y
> -CONFIG_DM_REGULATOR_FIXED=y
> -CONFIG_DM_REGULATOR_GPIO=y
> -CONFIG_DM_REGULATOR_STM32_VREFBUF=y
> -CONFIG_DM_REGULATOR_STPMIC1=y
> -CONFIG_REMOTEPROC_STM32_COPRO=y
> -CONFIG_DM_RNG=y
> -CONFIG_RNG_STM32MP1=y
> -CONFIG_DM_RTC=y
> -CONFIG_RTC_STM32=y
> -CONFIG_SERIAL_RX_BUFFER=y
> -CONFIG_SPI=y
> -CONFIG_DM_SPI=y
> -CONFIG_STM32_QSPI=y
> -CONFIG_STM32_SPI=y
> -CONFIG_TEE=y
> -CONFIG_OPTEE=y
> -# CONFIG_OPTEE_TA_AVB is not set
> -CONFIG_USB=y
> -CONFIG_DM_USB=y
> -CONFIG_DM_USB_GADGET=y
> -CONFIG_USB_EHCI_HCD=y
> -CONFIG_USB_EHCI_GENERIC=y
> -CONFIG_USB_GADGET=y
> -CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics"
> -CONFIG_USB_GADGET_VENDOR_NUM=0x0483
> -CONFIG_USB_GADGET_PRODUCT_NUM=0x5720
> -CONFIG_USB_GADGET_DWC2_OTG=y
> -CONFIG_DM_VIDEO=y
> -CONFIG_BACKLIGHT_GPIO=y
> -CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
> -CONFIG_VIDEO_LCD_RAYDIUM_RM68200=y
> -CONFIG_VIDEO_STM32=y
> -CONFIG_VIDEO_STM32_DSI=y
> -CONFIG_VIDEO_STM32_MAX_XRES=1280
> -CONFIG_VIDEO_STM32_MAX_YRES=800
> -CONFIG_FDT_FIXUP_PARTITIONS=y
> diff --git a/doc/board/st/stm32mp1.rst b/doc/board/st/stm32mp1.rst
> index b7

[PATCH 0/4] P1010RDB: Add device tree support and enable DM PCIe driver

[Zhiqiang Hou]

From: Hou Zhiqiang 

This patch set is to add device tree support and enable U-Boot Driver
Module PCIe driver on P1010RDB.

Hou Zhiqiang (4):
  powerpc: Enable device tree support for P1010RDB
  powerpc: P1010RDB: Compile legacy PCIe routines conditionally
  powerpc: P1010RDB: Disable legacy PCIe driver when DM_PCI is enabled
  configs: P1010RDB: Enable PCIe driver

 arch/powerpc/dts/Makefile|  2 +
 arch/powerpc/dts/p1010rdb-pa.dts | 17 
 arch/powerpc/dts/p1010rdb-pa_36b.dts | 17 
 arch/powerpc/dts/p1010rdb-pb.dts | 17 
 arch/powerpc/dts/p1010rdb-pb_36b.dts | 17 
 arch/powerpc/dts/p1010rdb_32b.dtsi   | 22 ++
 arch/powerpc/dts/p1010rdb_36b.dtsi   | 22 ++
 arch/powerpc/dts/p1010si-post.dtsi   | 46 
 arch/powerpc/dts/p1010si-pre.dtsi| 27 
 board/freescale/p1010rdb/p1010rdb.c  |  4 +-
 configs/P1010RDB-PA_36BIT_NAND_defconfig |  7 ++-
 configs/P1010RDB-PA_36BIT_NOR_defconfig  |  8 +++-
 configs/P1010RDB-PA_36BIT_SDCARD_defconfig   |  7 ++-
 configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig |  7 ++-
 configs/P1010RDB-PA_NAND_defconfig   |  7 ++-
 configs/P1010RDB-PA_NOR_defconfig|  8 +++-
 configs/P1010RDB-PA_SDCARD_defconfig |  7 ++-
 configs/P1010RDB-PA_SPIFLASH_defconfig   |  7 ++-
 configs/P1010RDB-PB_36BIT_NAND_defconfig |  7 ++-
 configs/P1010RDB-PB_36BIT_NOR_defconfig  |  8 +++-
 configs/P1010RDB-PB_36BIT_SDCARD_defconfig   |  7 ++-
 configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig |  7 ++-
 configs/P1010RDB-PB_NAND_defconfig   |  7 ++-
 configs/P1010RDB-PB_NOR_defconfig|  8 +++-
 configs/P1010RDB-PB_SDCARD_defconfig |  7 ++-
 configs/P1010RDB-PB_SPIFLASH_defconfig   |  7 ++-
 include/configs/P1010RDB.h   | 42 +++---
 27 files changed, 315 insertions(+), 34 deletions(-)
 create mode 100644 arch/powerpc/dts/p1010rdb-pa.dts
 create mode 100644 arch/powerpc/dts/p1010rdb-pa_36b.dts
 create mode 100644 arch/powerpc/dts/p1010rdb-pb.dts
 create mode 100644 arch/powerpc/dts/p1010rdb-pb_36b.dts
 create mode 100644 arch/powerpc/dts/p1010rdb_32b.dtsi
 create mode 100644 arch/powerpc/dts/p1010rdb_36b.dtsi
 create mode 100644 arch/powerpc/dts/p1010si-post.dtsi
 create mode 100644 arch/powerpc/dts/p1010si-pre.dtsi

-- 
2.17.1

Re: [PATCH v6 09/12] arm: mvebu: enable working default boot support

[Stefan Roese]

Hi Joel,

On 23.03.20 21:21, Joel Johnson wrote:

With the move to driver model usage, ensure that the required driver
support for SPI and MMC booting is available in SPL.

Tested on SolidRun ClearFog devices.

Signed-off-by: Joel Johnson 
Reviewed-by: Stefan Roese 

---

v2 changes:
   - change "select" for ENV_IS_IN_X to "imply" to allow disabling the
 default env location and configuring a different one if desired
   - remove SPL_DM_GPIO from defconfig, only include if needed for
 MMC booting
v3 changes:
   - none
v4 changes:
   - none
v5 changes:
   - none
v6 changes:
   - none


This patch generates multiple warnings on other MVEBU platforms. I've
dropped it for now in my upcoming pull request. Please rework the
problematic patches (missing in the pull request) and re-send.

Thanks,
Stefan



---
  arch/arm/mach-mvebu/Kconfig | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 161dee937f..32191e7157 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -235,9 +235,19 @@ choice
  
  config MVEBU_SPL_BOOT_DEVICE_SPI

bool "SPI NOR flash"
+   imply ENV_IS_IN_SPI_FLASH
+   select SPL_DM_SPI
+   select SPL_MTD_SUPPORT
+   select SPL_SPI_FLASH_SUPPORT
+   select SPL_SPI_LOAD
+   select SPL_SPI_SUPPORT
  
  config MVEBU_SPL_BOOT_DEVICE_MMC

bool "SDIO/MMC card"
+   imply ENV_IS_IN_MMC
+   # GPIO required for SD card presence detection line
+   select SPL_DM_GPIO
+   select SPL_DM_MMC
select SPL_LIBDISK_SUPPORT
  
  config MVEBU_SPL_BOOT_DEVICE_SATA





Viele Grüße,
Stefan

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

Re: [PATCH 11/11] doc: stm32mp1: update DFU support example

[Patrice CHOTARD]

Hi

On 3/18/20 9:22 AM, Patrick Delaunay wrote:
> Update stm32mp1 board documentation with new management of MMC and
> MTD partitions and new PID df11.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  doc/board/st/stm32mp1.rst | 115 ++
>  1 file changed, 54 insertions(+), 61 deletions(-)
>
> diff --git a/doc/board/st/stm32mp1.rst b/doc/board/st/stm32mp1.rst
> index 7fccdfbb94..41d0206d34 100644
> --- a/doc/board/st/stm32mp1.rst
> +++ b/doc/board/st/stm32mp1.rst
> @@ -518,61 +518,49 @@ On EV1 board, booting from SD card, without OP-TEE::
>dev: RAM alt: 0 name: uImage layout: RAM_ADDR
>dev: RAM alt: 1 name: devicetree.dtb layout: RAM_ADDR
>dev: RAM alt: 2 name: uramdisk.image.gz layout: RAM_ADDR
> -  dev: eMMC alt: 3 name: sdcard_fsbl1 layout: RAW_ADDR
> -  dev: eMMC alt: 4 name: sdcard_fsbl2 layout: RAW_ADDR
> -  dev: eMMC alt: 5 name: sdcard_ssbl layout: RAW_ADDR
> -  dev: eMMC alt: 6 name: sdcard_bootfs layout: RAW_ADDR
> -  dev: eMMC alt: 7 name: sdcard_vendorfs layout: RAW_ADDR
> -  dev: eMMC alt: 8 name: sdcard_rootfs layout: RAW_ADDR
> -  dev: eMMC alt: 9 name: sdcard_userfs layout: RAW_ADDR
> -  dev: eMMC alt: 10 name: emmc_fsbl1 layout: RAW_ADDR
> -  dev: eMMC alt: 11 name: emmc_fsbl2 layout: RAW_ADDR
> -  dev: eMMC alt: 12 name: emmc_ssbl layout: RAW_ADDR
> -  dev: eMMC alt: 13 name: emmc_bootfs layout: RAW_ADDR
> -  dev: eMMC alt: 14 name: emmc_vendorfs layout: RAW_ADDR
> -  dev: eMMC alt: 15 name: emmc_rootfs layout: RAW_ADDR
> -  dev: eMMC alt: 16 name: emmc_userfs layout: RAW_ADDR
> -  dev: MTD alt: 17 name: nor_fsbl1 layout: RAW_ADDR
> -  dev: MTD alt: 18 name: nor_fsbl2 layout: RAW_ADDR
> -  dev: MTD alt: 19 name: nor_ssbl layout: RAW_ADDR
> -  dev: MTD alt: 20 name: nor_env layout: RAW_ADDR
> -  dev: MTD alt: 21 name: nand_fsbl layout: RAW_ADDR
> -  dev: MTD alt: 22 name: nand_ssbl1 layout: RAW_ADDR
> -  dev: MTD alt: 23 name: nand_ssbl2 layout: RAW_ADDR
> -  dev: MTD alt: 24 name: nand_UBI layout: RAW_ADDR
> -  dev: VIRT alt: 25 name: OTP layout: RAW_ADDR
> -  dev: VIRT alt: 26 name: PMIC layout: RAW_ADDR
> +  dev: eMMC alt: 3 name: mmc0_fsbl1 layout: RAW_ADDR
> +  dev: eMMC alt: 4 name: mmc0_fsbl2 layout: RAW_ADDR
> +  dev: eMMC alt: 5 name: mmc0_ssbl layout: RAW_ADDR
> +  dev: eMMC alt: 6 name: mmc0_bootfs layout: RAW_ADDR
> +  dev: eMMC alt: 7 name: mmc0_vendorfs layout: RAW_ADDR
> +  dev: eMMC alt: 8 name: mmc0_rootfs layout: RAW_ADDR
> +  dev: eMMC alt: 9 name: mmc0_userfs layout: RAW_ADDR
> +  dev: eMMC alt: 10 name: mmc1_boot1 layout: RAW_ADDR
> +  dev: eMMC alt: 11 name: mmc1_boot2 layout: RAW_ADDR
> +  dev: eMMC alt: 12 name: mmc1_ssbl layout: RAW_ADDR
> +  dev: eMMC alt: 13 name: mmc1_bootfs layout: RAW_ADDR
> +  dev: eMMC alt: 14 name: mmc1_vendorfs layout: RAW_ADDR
> +  dev: eMMC alt: 15 name: mmc1_rootfs layout: RAW_ADDR
> +  dev: eMMC alt: 16 name: mmc1_userfs layout: RAW_ADDR
> +  dev: MTD alt: 17 name: nor0 layout: RAW_ADDR
> +  dev: MTD alt: 18 name: nand0 layout: RAW_ADDR
> +  dev: VIRT alt: 19 name: OTP layout: RAW_ADDR
> +  dev: VIRT alt: 20 name: PMIC layout: RAW_ADDR
>  
>  All the supported device are exported for dfu-util tool::
>  
>$> dfu-util -l
> -  Found DFU: [0483:5720] ver=, devnum=99, cfg=1, intf=0, alt=26, 
> name="PMIC", serial="00270038511934383330"
> -  Found DFU: [0483:5720] ver=, devnum=99, cfg=1, intf=0, alt=25, 
> name="OTP", serial="00270038511934383330"
> -  Found DFU: [0483:5720] ver=, devnum=99, cfg=1, intf=0, alt=24, 
> name="nand_UBI", serial="00270038511934383330"
> -  Found DFU: [0483:5720] ver=, devnum=99, cfg=1, intf=0, alt=23, 
> name="nand_ssbl2", serial="00270038511934383330"
> -  Found DFU: [0483:5720] ver=, devnum=99, cfg=1, intf=0, alt=22, 
> name="nand_ssbl1", serial="00270038511934383330"
> -  Found DFU: [0483:5720] ver=, devnum=99, cfg=1, intf=0, alt=21, 
> name="nand_fsbl", serial="00270038511934383330"
> -  Found DFU: [0483:5720] ver=, devnum=99, cfg=1, intf=0, alt=20, 
> name="nor_env", serial="00270038511934383330"
> -  Found DFU: [0483:5720] ver=, devnum=99, cfg=1, intf=0, alt=19, 
> name="nor_ssbl", serial="00270038511934383330"
> -  Found DFU: [0483:5720] ver=, devnum=99, cfg=1, intf=0, alt=18, 
> name="nor_fsbl2", serial="00270038511934383330"
> -  Found DFU: [0483:5720] ver=, devnum=99, cfg=1, intf=0, alt=17, 
> name="nor_fsbl1", serial="00270038511934383330"
> -  Found DFU: [0483:5720] ver=, devnum=99, cfg=1, intf=0, alt=16, 
> name="emmc_userfs", serial="00270038511934383330"
> -  Found DFU: [0483:5720] ver=, devnum=99, cfg=1, intf=0, alt=15, 
> name="emmc_rootfs", serial="00270038511934383330"
> -  Found DFU: [0483:5720] ver=, devnum=99, cfg=1, intf=0, alt=14, 
> name="emmc_vendorfs", serial="00270038511934383330"
> -  Found DFU: [0483:5720] ver=, devnum=99, cfg=1, intf=0, alt=13, 
> name="emmc_bootfs", serial="00270038511934383330"
> -  Found DFU: [0483:5720] 

Re: [PATCH 09/11] board: stm32mp1: support boot from spi-nand

[Patrice CHOTARD]

Hi

On 3/18/20 9:22 AM, Patrick Delaunay wrote:
> Manage BOOT_FLASH_SPINAND, with boot_device="spi-nand"
> and treat this value in bootcmd_stm32mp.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  arch/arm/mach-stm32mp/cpu.c| 4 
>  arch/arm/mach-stm32mp/include/mach/stm32.h | 3 +++
>  arch/arm/mach-stm32mp/spl.c| 2 ++
>  board/st/stm32mp1/stm32mp1.c   | 2 ++
>  include/configs/stm32mp1.h | 5 +++--
>  5 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
> index 9aa5794334..e14e3e47f2 100644
> --- a/arch/arm/mach-stm32mp/cpu.c
> +++ b/arch/arm/mach-stm32mp/cpu.c
> @@ -435,6 +435,10 @@ static void setup_boot_mode(void)
>   env_set("boot_device", "nand");
>   env_set("boot_instance", "0");
>   break;
> + case BOOT_FLASH_SPINAND:
> + env_set("boot_device", "spi-nand");
> + env_set("boot_instance", "0");
> + break;
>   case BOOT_FLASH_NOR:
>   env_set("boot_device", "nor");
>   env_set("boot_instance", "0");
> diff --git a/arch/arm/mach-stm32mp/include/mach/stm32.h 
> b/arch/arm/mach-stm32mp/include/mach/stm32.h
> index 6daf9f7121..a9bd5bdc1b 100644
> --- a/arch/arm/mach-stm32mp/include/mach/stm32.h
> +++ b/arch/arm/mach-stm32mp/include/mach/stm32.h
> @@ -79,6 +79,9 @@ enum boot_device {
>  
>   BOOT_SERIAL_USB = 0x60,
>   BOOT_SERIAL_USB_OTG = 0x62,
> +
> + BOOT_FLASH_SPINAND = 0x70,
> + BOOT_FLASH_SPINAND_1 = 0x71,
>  };
>  
>  /* TAMP registers */
> diff --git a/arch/arm/mach-stm32mp/spl.c b/arch/arm/mach-stm32mp/spl.c
> index ca4231cd0d..9cd7b418a4 100644
> --- a/arch/arm/mach-stm32mp/spl.c
> +++ b/arch/arm/mach-stm32mp/spl.c
> @@ -39,6 +39,8 @@ u32 spl_boot_device(void)
>   return BOOT_DEVICE_NAND;
>   case BOOT_FLASH_NOR_QSPI:
>   return BOOT_DEVICE_SPI;
> + case BOOT_FLASH_SPINAND_1:
> + return BOOT_DEVICE_NONE; /* SPINAND not supported in SPL */
>   }
>  
>   return BOOT_DEVICE_MMC1;
> diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
> index 14c56a0f24..423be23555 100644
> --- a/board/st/stm32mp1/stm32mp1.c
> +++ b/board/st/stm32mp1/stm32mp1.c
> @@ -789,6 +789,7 @@ enum env_location env_get_location(enum env_operation op, 
> int prio)
>  #endif
>  #ifdef CONFIG_ENV_IS_IN_UBI
>   case BOOT_FLASH_NAND:
> + case BOOT_FLASH_SPINAND:
>   return ENVL_UBI;
>  #endif
>  #ifdef CONFIG_ENV_IS_IN_SPI_FLASH
> @@ -829,6 +830,7 @@ int ft_board_setup(void *blob, bd_t *bd)
>  #ifdef CONFIG_FDT_FIXUP_PARTITIONS
>   struct node_info nodes[] = {
>   { "st,stm32f469-qspi",  MTD_DEV_TYPE_NOR,  },
> + { "st,stm32f469-qspi",  MTD_DEV_TYPE_SPINAND},
>   { "st,stm32mp15-fmc2",  MTD_DEV_TYPE_NAND, },
>   };
>   fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes));
> diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
> index c5b09f1a2a..c34a720e0c 100644
> --- a/include/configs/stm32mp1.h
> +++ b/include/configs/stm32mp1.h
> @@ -127,7 +127,7 @@
>   * bootcmd for stm32mp1:
>   * for serial/usb: execute the stm32prog command
>   * for mmc boot (eMMC, SD card), boot only on the same device
> - * for nand boot, boot with on ubifs partition on nand
> + * for nand or spi-nand boot, boot with on ubifs partition on UBI partition
>   * for nor boot, use the default order
>   */
>  #define STM32MP_BOOTCMD "bootcmd_stm32mp=" \
> @@ -138,7 +138,8 @@
>   "run env_check;" \
>   "if test ${boot_device} = mmc;" \
>   "then env set boot_targets \"mmc${boot_instance}\"; fi;" \
> - "if test ${boot_device} = nand;" \
> + "if test ${boot_device} = nand ||" \
> +   " test ${boot_device} = spi-nand ;" \
>   "then env set boot_targets ubifs0; fi;" \
>   "run distro_bootcmd;" \
>   "fi;\0"

Reviewed-by: Patrice Chotard 

Patrice

[PATCH 4/4] configs: P1010RDB: Enable PCIe driver

[Zhiqiang Hou]

From: Hou Zhiqiang 

Enable the DM PCIe driver in P1010RDB defconfigs.

Signed-off-by: Hou Zhiqiang 
---
 configs/P1010RDB-PA_36BIT_NAND_defconfig | 4 
 configs/P1010RDB-PA_36BIT_NOR_defconfig  | 4 
 configs/P1010RDB-PA_36BIT_SDCARD_defconfig   | 4 
 configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig | 4 
 configs/P1010RDB-PA_NAND_defconfig   | 4 
 configs/P1010RDB-PA_NOR_defconfig| 4 
 configs/P1010RDB-PA_SDCARD_defconfig | 4 
 configs/P1010RDB-PA_SPIFLASH_defconfig   | 4 
 configs/P1010RDB-PB_36BIT_NAND_defconfig | 4 
 configs/P1010RDB-PB_36BIT_NOR_defconfig  | 4 
 configs/P1010RDB-PB_36BIT_SDCARD_defconfig   | 4 
 configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig | 4 
 configs/P1010RDB-PB_NAND_defconfig   | 4 
 configs/P1010RDB-PB_NOR_defconfig| 4 
 configs/P1010RDB-PB_SDCARD_defconfig | 4 
 configs/P1010RDB-PB_SPIFLASH_defconfig   | 4 
 16 files changed, 64 insertions(+)

diff --git a/configs/P1010RDB-PA_36BIT_NAND_defconfig 
b/configs/P1010RDB-PA_36BIT_NAND_defconfig
index 414b6d1116..99a18e6a78 100644
--- a/configs/P1010RDB-PA_36BIT_NAND_defconfig
+++ b/configs/P1010RDB-PA_36BIT_NAND_defconfig
@@ -63,6 +63,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/P1010RDB-PA_36BIT_NOR_defconfig 
b/configs/P1010RDB-PA_36BIT_NOR_defconfig
index b083f19a92..bafe039c91 100644
--- a/configs/P1010RDB-PA_36BIT_NOR_defconfig
+++ b/configs/P1010RDB-PA_36BIT_NOR_defconfig
@@ -45,6 +45,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/P1010RDB-PA_36BIT_SDCARD_defconfig 
b/configs/P1010RDB-PA_36BIT_SDCARD_defconfig
index a4f68bc3fd..47fc959ab7 100644
--- a/configs/P1010RDB-PA_36BIT_SDCARD_defconfig
+++ b/configs/P1010RDB-PA_36BIT_SDCARD_defconfig
@@ -57,6 +57,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig 
b/configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig
index faf7b13396..e4d7ae0b63 100644
--- a/configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig
+++ b/configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig
@@ -59,6 +59,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/P1010RDB-PA_NAND_defconfig 
b/configs/P1010RDB-PA_NAND_defconfig
index c8dddc5f40..a350430f22 100644
--- a/configs/P1010RDB-PA_NAND_defconfig
+++ b/configs/P1010RDB-PA_NAND_defconfig
@@ -62,6 +62,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/P1010RDB-PA_NOR_defconfig 
b/configs/P1010RDB-PA_NOR_defconfig
index 1edcf75165..12723a29d4 100644
--- a/configs/P1010RDB-PA_NOR_defconfig
+++ b/configs/P1010RDB-PA_NOR_defconfig
@@ -44,6 +44,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/P1010RDB-PA_SDCARD_defconfig 
b/configs/P1010RDB-PA_SDCARD_defconfig
index b83d0e7528..b9c0a3f7c5 100644
--- a/configs/P1010RDB-PA_SDCARD_defconfig
+++ b/configs/P1010RDB-PA_SDCARD_defconfig
@@ -56,6 +56,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/P1010RDB-PA_SPIFLASH_defconfig 
b/configs/P1010RDB-PA_SPIFLASH_defconfig
index cf7f68c471..28ab1a9624 100644
--- a/configs/P1010RDB-PA_SPIFLASH_defconfig
+++ b/configs/P1010RDB-PA_SPIFLASH_defconfig
@@ -58,6 +58,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/P1010RDB-PB_36BIT_NAND_defconfig 
b/configs/P1010RDB-PB_36BIT_NAND_defconfig
index c1053a0781..4bb38737ca 100644
--- a/configs/P1010RDB-PB_36BIT_NAND_defconfig
+++ b/configs/P1010RDB-PB_36BIT_NAND_defconfig
@@ -63,6 +63,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y

[PATCH 3/4] powerpc: P1010RDB: Disable legacy PCIe driver when DM_PCI is enabled

[Zhiqiang Hou]

From: Hou Zhiqiang 

Disable legacy PCIe driver and unused PCIe macros when DM_PCI enabled
for P1010RDB board.

Signed-off-by: Hou Zhiqiang 
---
 include/configs/P1010RDB.h | 42 +++---
 1 file changed, 26 insertions(+), 16 deletions(-)

diff --git a/include/configs/P1010RDB.h b/include/configs/P1010RDB.h
index 60e8904d42..7c178ac53a 100644
--- a/include/configs/P1010RDB.h
+++ b/include/configs/P1010RDB.h
@@ -113,8 +113,6 @@
 #if defined(CONFIG_PCI)
 #define CONFIG_PCIE1   /* PCIE controller 1 (slot 1) */
 #define CONFIG_PCIE2   /* PCIE controller 2 (slot 2) */
-#define CONFIG_FSL_PCI_INIT/* Use common FSL init code */
-#define CONFIG_PCI_INDIRECT_BRIDGE /* indirect PCI bridge support */
 #define CONFIG_SYS_PCI_64BIT   /* enable 64-bit PCI resources */
 
 /*
@@ -122,19 +120,13 @@
  * Memory space is mapped 1-1, but I/O space must start from 0.
  */
 /* controller 1, Slot 1, tgtid 1, Base address a000 */
-#define CONFIG_SYS_PCIE1_NAME  "mini PCIe Slot"
 #define CONFIG_SYS_PCIE1_MEM_VIRT  0x8000
 #ifdef CONFIG_PHYS_64BIT
-#define CONFIG_SYS_PCIE1_MEM_BUS   0x8000
 #define CONFIG_SYS_PCIE1_MEM_PHYS  0xcull
 #else
-#define CONFIG_SYS_PCIE1_MEM_BUS   0x8000
 #define CONFIG_SYS_PCIE1_MEM_PHYS  0x8000
 #endif
-#define CONFIG_SYS_PCIE1_MEM_SIZE  0x2000  /* 512M */
 #define CONFIG_SYS_PCIE1_IO_VIRT   0xffc0
-#define CONFIG_SYS_PCIE1_IO_BUS0x
-#define CONFIG_SYS_PCIE1_IO_SIZE   0x0001  /* 64k */
 #ifdef CONFIG_PHYS_64BIT
 #define CONFIG_SYS_PCIE1_IO_PHYS   0xfffc0ull
 #else
@@ -142,27 +134,45 @@
 #endif
 
 /* controller 2, Slot 2, tgtid 2, Base address 9000 */
+#define CONFIG_SYS_PCIE2_MEM_VIRT  0xa000
+#ifdef CONFIG_PHYS_64BIT
+#define CONFIG_SYS_PCIE2_MEM_PHYS  0xc2000ull
+#else
+#define CONFIG_SYS_PCIE2_MEM_PHYS  0xa000
+#endif
+#define CONFIG_SYS_PCIE2_IO_VIRT   0xffc1
+#ifdef CONFIG_PHYS_64BIT
+#define CONFIG_SYS_PCIE2_IO_PHYS   0xfffc1ull
+#else
+#define CONFIG_SYS_PCIE2_IO_PHYS   0xffc1
+#endif
+
+#if !defined(CONFIG_DM_PCI)
+#define CONFIG_FSL_PCI_INIT/* Use common FSL init code */
+#define CONFIG_PCI_INDIRECT_BRIDGE /* indirect PCI bridge support */
+#define CONFIG_SYS_PCIE1_NAME  "mini PCIe Slot"
+#ifdef CONFIG_PHYS_64BIT
+#define CONFIG_SYS_PCIE1_MEM_BUS   0x8000
+#else
+#define CONFIG_SYS_PCIE1_MEM_BUS   0x8000
+#endif
+#define CONFIG_SYS_PCIE1_MEM_SIZE  0x2000  /* 512M */
+#define CONFIG_SYS_PCIE1_IO_BUS0x
+#define CONFIG_SYS_PCIE1_IO_SIZE   0x0001  /* 64k */
+
 #if defined(CONFIG_TARGET_P1010RDB_PA)
 #define CONFIG_SYS_PCIE2_NAME  "PCIe Slot"
 #elif defined(CONFIG_TARGET_P1010RDB_PB)
 #define CONFIG_SYS_PCIE2_NAME  "mini PCIe Slot"
 #endif
-#define CONFIG_SYS_PCIE2_MEM_VIRT  0xa000
 #ifdef CONFIG_PHYS_64BIT
 #define CONFIG_SYS_PCIE2_MEM_BUS   0xc000
-#define CONFIG_SYS_PCIE2_MEM_PHYS  0xc2000ull
 #else
 #define CONFIG_SYS_PCIE2_MEM_BUS   0xa000
-#define CONFIG_SYS_PCIE2_MEM_PHYS  0xa000
 #endif
 #define CONFIG_SYS_PCIE2_MEM_SIZE  0x2000  /* 512M */
-#define CONFIG_SYS_PCIE2_IO_VIRT   0xffc1
 #define CONFIG_SYS_PCIE2_IO_BUS0x
 #define CONFIG_SYS_PCIE2_IO_SIZE   0x0001  /* 64k */
-#ifdef CONFIG_PHYS_64BIT
-#define CONFIG_SYS_PCIE2_IO_PHYS   0xfffc1ull
-#else
-#define CONFIG_SYS_PCIE2_IO_PHYS   0xffc1
 #endif
 
 #define CONFIG_PCI_SCAN_SHOW   /* show pci devices on startup */
-- 
2.17.1

[PATCH 2/4] powerpc: P1010RDB: Compile legacy PCIe routines conditionally

[Zhiqiang Hou]

From: Hou Zhiqiang 

Compile the legacy PCIe initialization reoutines for P1010RDB
boards only when DM_PCI is not enabled.

Signed-off-by: Hou Zhiqiang 
---
 board/freescale/p1010rdb/p1010rdb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/freescale/p1010rdb/p1010rdb.c 
b/board/freescale/p1010rdb/p1010rdb.c
index a086692683..5057eac38a 100644
--- a/board/freescale/p1010rdb/p1010rdb.c
+++ b/board/freescale/p1010rdb/p1010rdb.c
@@ -124,7 +124,7 @@ int board_early_init_r(void)
return 0;
 }
 
-#ifdef CONFIG_PCI
+#if defined(CONFIG_PCI) && !defined(CONFIG_DM_PCI)
 void pci_init_board(void)
 {
fsl_pcie_init_board(0);
@@ -457,7 +457,7 @@ int ft_board_setup(void *blob, bd_t *bd)
base = env_get_bootm_low();
size = env_get_bootm_size();
 
-#if defined(CONFIG_PCI)
+#if defined(CONFIG_PCI) && !defined(CONFIG_DM_PCI)
FT_FSL_PCI_SETUP;
 #endif
 
-- 
2.17.1

[PATCH 1/4] powerpc: Enable device tree support for P1010RDB

[Zhiqiang Hou]

From: Hou Zhiqiang 

Add device tree for P1010RDB boards and enable CONFIG_OF_CONTROL
so that device tree can be compiled.

Signed-off-by: Hou Zhiqiang 
---
 arch/powerpc/dts/Makefile|  2 +
 arch/powerpc/dts/p1010rdb-pa.dts | 17 
 arch/powerpc/dts/p1010rdb-pa_36b.dts | 17 
 arch/powerpc/dts/p1010rdb-pb.dts | 17 
 arch/powerpc/dts/p1010rdb-pb_36b.dts | 17 
 arch/powerpc/dts/p1010rdb_32b.dtsi   | 22 ++
 arch/powerpc/dts/p1010rdb_36b.dtsi   | 22 ++
 arch/powerpc/dts/p1010si-post.dtsi   | 46 
 arch/powerpc/dts/p1010si-pre.dtsi| 27 
 configs/P1010RDB-PA_36BIT_NAND_defconfig |  3 +-
 configs/P1010RDB-PA_36BIT_NOR_defconfig  |  4 +-
 configs/P1010RDB-PA_36BIT_SDCARD_defconfig   |  3 +-
 configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig |  3 +-
 configs/P1010RDB-PA_NAND_defconfig   |  3 +-
 configs/P1010RDB-PA_NOR_defconfig|  4 +-
 configs/P1010RDB-PA_SDCARD_defconfig |  3 +-
 configs/P1010RDB-PA_SPIFLASH_defconfig   |  3 +-
 configs/P1010RDB-PB_36BIT_NAND_defconfig |  3 +-
 configs/P1010RDB-PB_36BIT_NOR_defconfig  |  4 +-
 configs/P1010RDB-PB_36BIT_SDCARD_defconfig   |  3 +-
 configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig |  3 +-
 configs/P1010RDB-PB_NAND_defconfig   |  3 +-
 configs/P1010RDB-PB_NOR_defconfig|  4 +-
 configs/P1010RDB-PB_SDCARD_defconfig |  3 +-
 configs/P1010RDB-PB_SPIFLASH_defconfig   |  3 +-
 25 files changed, 223 insertions(+), 16 deletions(-)
 create mode 100644 arch/powerpc/dts/p1010rdb-pa.dts
 create mode 100644 arch/powerpc/dts/p1010rdb-pa_36b.dts
 create mode 100644 arch/powerpc/dts/p1010rdb-pb.dts
 create mode 100644 arch/powerpc/dts/p1010rdb-pb_36b.dts
 create mode 100644 arch/powerpc/dts/p1010rdb_32b.dtsi
 create mode 100644 arch/powerpc/dts/p1010rdb_36b.dtsi
 create mode 100644 arch/powerpc/dts/p1010si-post.dtsi
 create mode 100644 arch/powerpc/dts/p1010si-pre.dtsi

diff --git a/arch/powerpc/dts/Makefile b/arch/powerpc/dts/Makefile
index 3195351c9c..7eb005f450 100644
--- a/arch/powerpc/dts/Makefile
+++ b/arch/powerpc/dts/Makefile
@@ -1,6 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0+
 
 dtb-$(CONFIG_TARGET_MPC8548CDS) += mpc8548cds.dtb mpc8548cds_36b.dtb
+dtb-$(CONFIG_TARGET_P1010RDB_PA) += p1010rdb-pa.dtb p1010rdb-pa_36b.dtb
+dtb-$(CONFIG_TARGET_P1010RDB_PB) += p1010rdb-pb.dtb p1010rdb-pb_36b.dtb
 dtb-$(CONFIG_TARGET_P1020RDB_PC) += p1020rdb-pc.dtb p1020rdb-pc_36b.dtb
 dtb-$(CONFIG_TARGET_P1020RDB_PD) += p1020rdb-pd.dtb
 dtb-$(CONFIG_TARGET_P2020RDB) += p2020rdb-pc.dtb p2020rdb-pc_36b.dtb
diff --git a/arch/powerpc/dts/p1010rdb-pa.dts b/arch/powerpc/dts/p1010rdb-pa.dts
new file mode 100644
index 00..c66c4923ac
--- /dev/null
+++ b/arch/powerpc/dts/p1010rdb-pa.dts
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * P1010 RDB Device Tree Source
+ *
+ * Copyright 2020 NXP
+ */
+
+/include/ "p1010si-pre.dtsi"
+
+/ {
+   model = "fsl,P1010RDB";
+   compatible = "fsl,P1010RDB";
+
+   /include/ "p1010rdb_32b.dtsi"
+};
+
+/include/ "p1010si-post.dtsi"
diff --git a/arch/powerpc/dts/p1010rdb-pa_36b.dts 
b/arch/powerpc/dts/p1010rdb-pa_36b.dts
new file mode 100644
index 00..b943de7cbb
--- /dev/null
+++ b/arch/powerpc/dts/p1010rdb-pa_36b.dts
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * P1010 RDB Device Tree Source (36-bit address map)
+ *
+ * Copyright 2020 NXP
+ */
+
+/include/ "p1010si-pre.dtsi"
+
+/ {
+   model = "fsl,P1010RDB";
+   compatible = "fsl,P1010RDB";
+
+   /include/ "p1010rdb_36b.dtsi"
+};
+
+/include/ "p1010si-post.dtsi"
diff --git a/arch/powerpc/dts/p1010rdb-pb.dts b/arch/powerpc/dts/p1010rdb-pb.dts
new file mode 100644
index 00..2675d5d92b
--- /dev/null
+++ b/arch/powerpc/dts/p1010rdb-pb.dts
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * P1010RDB Device Tree Source
+ *
+ * Copyright 2020 NXP
+ */
+
+/include/ "p1010si-pre.dtsi"
+
+/ {
+   model = "fsl,P1010RDB-PB";
+   compatible = "fsl,P1010RDB-PB";
+
+   /include/ "p1010rdb_32b.dtsi"
+};
+
+/include/ "p1010si-post.dtsi"
diff --git a/arch/powerpc/dts/p1010rdb-pb_36b.dts 
b/arch/powerpc/dts/p1010rdb-pb_36b.dts
new file mode 100644
index 00..45ccf91c41
--- /dev/null
+++ b/arch/powerpc/dts/p1010rdb-pb_36b.dts
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * P1010 RDB Device Tree Source (36-bit address map)
+ *
+ * Copyright 2020 NXP
+ */
+
+/include/ "p1010si-pre.dtsi"
+
+/ {
+   model = "fsl,P1010RDB-PB";
+   compatible = "fsl,P1010RDB-PB";
+
+   /include/ "p1010rdb_36b.dtsi"
+};
+
+/include/ "p1010si-post.dtsi"
diff --git a/arch/powerpc/dts/p1010rdb_32b.dtsi 
b/arch/powerpc/dts/p1010rdb_32b.dtsi
new file mode 100644
index 00..5da790da5e
--- /dev/null
+++ b/arch/powerpc/dts/p1010rdb_32b.dtsi
@@ -0,0 +1,22 @@
+// SPDX-L

[PATCH] armv8: ls1028a: define esdhc_status_fixup

[Xiaowei Bao]

From: Yinbo Zhu 

This patch is to define esdhc_status_fixup function for ls1028a to disable
SDHC1/SDHC2 status in device tree node if not selected.

Signed-off-by: Yinbo Zhu 
Signed-off-by: Xiaowei Bao 
Signed-off-by: Yangbo Lu 
---
 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  5 +++
 board/freescale/ls1028a/ls1028a.c  | 40 ++
 2 files changed, 45 insertions(+)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 299201b..c2fbc23 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -232,7 +232,12 @@
 #define DCFG_PORSR10x000
 #define DCFG_PORSR1_RCW_SRC0xff80
 #define DCFG_PORSR1_RCW_SRC_NOR0x12f0
+#define DCFG_RCWSR12   0x12c
+#define DCFG_RCWSR12_SDHC_SHIFT24
+#define DCFG_RCWSR12_SDHC_MASK 0x7
 #define DCFG_RCWSR13   0x130
+#define DCFG_RCWSR13_SDHC_SHIFT3
+#define DCFG_RCWSR13_SDHC_MASK 0x7
 #define DCFG_RCWSR13_DSPI  (0 << 8)
 #define DCFG_RCWSR15   0x138
 #define DCFG_RCWSR15_IFCGRPABASE_QSPI  0x3
diff --git a/board/freescale/ls1028a/ls1028a.c 
b/board/freescale/ls1028a/ls1028a.c
index aa93534..a8bdd12 100644
--- a/board/freescale/ls1028a/ls1028a.c
+++ b/board/freescale/ls1028a/ls1028a.c
@@ -135,6 +135,46 @@ void detail_board_ddr_info(void)
print_ddr_info(0);
 }
 
+int esdhc_status_fixup(void *blob, const char *compat)
+{
+   void __iomem *dcfg_ccsr = (void __iomem *)DCFG_BASE;
+   char esdhc1_path[] = "/soc/mmc@214";
+   char esdhc2_path[] = "/soc/mmc@215";
+   char dspi1_path[] = "/soc/spi@210";
+   char dspi2_path[] = "/soc/spi@211";
+   u32 mux_sdhc1, mux_sdhc2;
+   u32 io = 0;
+
+   /*
+* The PMUX IO-expander for mux select is used to control
+* the muxing of various onboard interfaces.
+*/
+
+   io = in_le32(dcfg_ccsr + DCFG_RCWSR12);
+   mux_sdhc1 = (io >> DCFG_RCWSR12_SDHC_SHIFT) & DCFG_RCWSR12_SDHC_MASK;
+
+   /* Disable esdhc1/dspi1 if not selected. */
+   if (mux_sdhc1 != 0)
+   do_fixup_by_path(blob, esdhc1_path, "status", "disabled",
+sizeof("disabled"), 1);
+   if (mux_sdhc1 != 2)
+   do_fixup_by_path(blob, dspi1_path, "status", "disabled",
+sizeof("disabled"), 1);
+
+   io = in_le32(dcfg_ccsr + DCFG_RCWSR13);
+   mux_sdhc2 = (io >> DCFG_RCWSR13_SDHC_SHIFT) & DCFG_RCWSR13_SDHC_MASK;
+
+   /* Disable esdhc2/dspi2 if not selected. */
+   if (mux_sdhc2 != 0)
+   do_fixup_by_path(blob, esdhc2_path, "status", "disabled",
+sizeof("disabled"), 1);
+   if (mux_sdhc2 != 2)
+   do_fixup_by_path(blob, dspi2_path, "status", "disabled",
+sizeof("disabled"), 1);
+
+   return 0;
+}
+
 #ifdef CONFIG_OF_BOARD_SETUP
 int ft_board_setup(void *blob, bd_t *bd)
 {
-- 
2.9.5

RE: [PATCH] powerpc: dts: p1010: add i2c node

[Biwen Li (OSS)]

> Hi Priyanka,
> 
> The patch depend on dts patch of zhiqiang.
The patch depend on dts patch(powerpc: Enable device tree support for P1010RDB) 
of zhiqiang as follows,
https://patchwork.ozlabs.org/project/uboot/patch/20200414093022.24132-2-zhiqiang@nxp.com
> 
> Best Regards,
> Biwen Li
> > -Original Message-
> > From: Biwen Li 
> > Sent: 2020年4月12日 17:05
> > To: Jagdish Gediya ; Priyanka Jain
> > ; h...@denx.de; ja...@amarulasolutions.com;
> > aford...@gmail.com; Alison Wang ;
> > jh80.ch...@samsung.com; Pramod Kumar ;
> Rajesh
> > Bhagat ; Ruchika Gupta
> ;
> > olte...@gmail.com
> > Cc: Xiaobo Xie ; Jiafei Pan ;
> > u-boot@lists.denx.de; Z.q. Hou ; Biwen Li
> > 
> > Subject: [PATCH] powerpc: dts: p1010: add i2c node
> >
> > From: Biwen Li 
> >
> > Add i2c node of p1010
> >
> > Signed-off-by: Biwen Li 
> > ---
> >  arch/powerpc/dts/p1010rdb-pb.dts |  1 +
> >  arch/powerpc/dts/p1010rdb-pb_36b.dts |  1 +
> >  arch/powerpc/dts/p1010rdb.dtsi   | 14 ++
> >  arch/powerpc/dts/p1010si-post.dtsi   |  2 ++
> >  4 files changed, 18 insertions(+)
> >  create mode 100644 arch/powerpc/dts/p1010rdb.dtsi
> >
> > diff --git a/arch/powerpc/dts/p1010rdb-pb.dts
> > b/arch/powerpc/dts/p1010rdb-pb.dts
> > index 2675d5d92b..9ca562534f 100644
> > --- a/arch/powerpc/dts/p1010rdb-pb.dts
> > +++ b/arch/powerpc/dts/p1010rdb-pb.dts
> > @@ -15,3 +15,4 @@
> >  };
> >
> >  /include/ "p1010si-post.dtsi"
> > +/include/ "p1010rdb.dtsi"
> > diff --git a/arch/powerpc/dts/p1010rdb-pb_36b.dts
> > b/arch/powerpc/dts/p1010rdb-pb_36b.dts
> > index 45ccf91c41..eeff2a8704 100644
> > --- a/arch/powerpc/dts/p1010rdb-pb_36b.dts
> > +++ b/arch/powerpc/dts/p1010rdb-pb_36b.dts
> > @@ -15,3 +15,4 @@
> >  };
> >
> >  /include/ "p1010si-post.dtsi"
> > +/include/ "p1010rdb.dtsi"
> > diff --git a/arch/powerpc/dts/p1010rdb.dtsi
> > b/arch/powerpc/dts/p1010rdb.dtsi new file mode 100644 index
> > 00..4f58ee2446
> > --- /dev/null
> > +++ b/arch/powerpc/dts/p1010rdb.dtsi
> > @@ -0,0 +1,14 @@
> > +// SPDX-License-Identifier: GPL-2.0+ OR X11
> > +/*
> > + * P1010RDB Device Tree Source
> > + *
> > + * Copyright 2020 NXP
> > + */
> > +&soc {
> > +   i2c@3000 {
> > +   rtc@68 {
> > +   compatible = "pericom,pt7c4338";
> > +   reg = <0x68>;
> > +   };
> > +   };
> > +};
> > diff --git a/arch/powerpc/dts/p1010si-post.dtsi
> > b/arch/powerpc/dts/p1010si-post.dtsi
> > index e24b5e4063..0289441381 100644
> > --- a/arch/powerpc/dts/p1010si-post.dtsi
> > +++ b/arch/powerpc/dts/p1010si-post.dtsi
> > @@ -23,6 +23,8 @@
> > single-cpu-affinity;
> > last-interrupt-source = <255>;
> > };
> > +/include/ "pq3-i2c-0.dtsi"
> > +/include/ "pq3-i2c-1.dtsi"
> >  };
> >
> >  /* controller at 0x9000 */
> > --
> > 2.17.1

Re: [PATCH] rockchip: rk3328: add rock-pi-e-rk3328_defconfig

[Kever Yang]

Hi banglang,

Does this board dts also upstream to kernel? If yes, please split the 
dts as a separate patch


and add the commit info in the message.

On 2020/4/13 下午4:23, banglang.huang wrote:

The ROCK-PI-E is a credit card size SBC based on Rockchip RK3328
Quad-Core ARM Cortex A53.

 Net - Dual ethernet port, 1 X Gbe, 1 X 100M
 USB - USB 3.0
 DC  - USB-Type C, 5V 2A
 Storage - TF card, eMMC

Just build u-boot-dtb.bin for Rockpi E board and follow the blow
steps to replace the relevant partition.

   ./rkbin/tools/loaderimage --pack --uboot u-boot-dtb.bin \
   uboot.img 0x20 --size 1024 1
   dd if=uboot.img of=/dev/sdcard seek=16384 conv=notrunc


RK3328 has enable the TPL support for dram init, could you enable 
TPL/SPL for this board?



Thanks,

- Kever



Signed-off-by: banglang.huang 
---

Changes for v3

 - rename to rock-pi-e

Changes for v2

 - add introduction for rockpie in doc/README.rockchip
 - enable CONFIG_MISC_INIT_R, CONFIG_SMBIOS_MANUFACTURER,
   and CONFIG_SMBIOS_PRODUCT_NAME

  arch/arm/dts/Makefile |   3 +-
  arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi |  12 +
  arch/arm/dts/rk3328-rock-pi-e.dts | 256 ++
  board/rockchip/evb_rk3328/MAINTAINERS |   7 +
  configs/rock-pi-e-rk3328_defconfig|  99 +
  doc/README.rockchip   |   3 +-
  6 files changed, 378 insertions(+), 2 deletions(-)
  create mode 100644 arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3328-rock-pi-e.dts
  create mode 100644 configs/rock-pi-e-rk3328_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 820ee9733a..f0897f2928 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -104,7 +104,8 @@ dtb-$(CONFIG_ROCKCHIP_RK3308) += \
  
  dtb-$(CONFIG_ROCKCHIP_RK3328) += \

rk3328-evb.dtb \
-   rk3328-rock64.dtb
+   rk3328-rock64.dtb \
+   rk3328-rock-pi-e.dtb
  
  dtb-$(CONFIG_ROCKCHIP_RK3368) += \

rk3368-lion.dtb \
diff --git a/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi 
b/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
new file mode 100644
index 00..012209110a
--- /dev/null
+++ b/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2020 Radxa
+ */
+
+#include "rk3328-u-boot.dtsi"
+#include "rk3328-sdram-ddr3-666.dtsi"
+
+&usb_host0_xhci {
+   vbus-supply = <&vcc5v0_host_xhci>;
+   status = "okay";
+};
diff --git a/arch/arm/dts/rk3328-rock-pi-e.dts 
b/arch/arm/dts/rk3328-rock-pi-e.dts
new file mode 100644
index 00..56b8c3f1e6
--- /dev/null
+++ b/arch/arm/dts/rk3328-rock-pi-e.dts
@@ -0,0 +1,256 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2020 Radxa
+ */
+
+/dts-v1/;
+#include "rk3328.dtsi"
+
+/ {
+   model = "Radxa Rockpi E";
+   compatible = "radxa,rockpie", "rockchip,rk3328";
+
+   chosen {
+   stdout-path = &uart2;
+   };
+
+   gmac_clkin: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "gmac_clkin";
+   #clock-cells = <0>;
+   };
+
+   vcc3v3_sdmmc: sdmmc-pwren {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3";
+   gpio = <&gpio0 30 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&sdmmc0m1_gpio>;
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <&vcc_io>;
+   };
+
+   vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   regulator-name = "vcc5v0_host_xhci";
+   gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+};
+
+&cpu0 {
+   cpu-supply = <&vdd_arm>;
+};
+
+&cpu1 {
+   cpu-supply = <&vdd_arm>;
+};
+
+&cpu2 {
+   cpu-supply = <&vdd_arm>;
+};
+
+&cpu3 {
+   cpu-supply = <&vdd_arm>;
+};
+
+&saradc {
+   status = "okay";
+};
+
+&uart2 {
+   status = "okay";
+};
+
+&sdmmc {
+   bus-width = <4>;
+   cap-mmc-highspeed;
+   cap-sd-highspeed;
+   card-detect-delay = <200>;
+   disable-wp;
+   max-frequency = <15000>;
+   num-slots = <1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&sdmmc0_clk>, <&sdmmc0_cmd>, <&sdmmc0_dectn>, 
<&sdmmc0_bus4>;
+   supports-sd;
+   vmmc-supply = <&vcc3v3_sdmmc>;
+   status = "okay";
+};
+
+&emmc {
+   bus-width = <8>;
+   cap-mmc-highspeed;
+   mmc-hs200-1_8v;
+   supports-emmc;
+   disable-wp;
+   non-removable;
+   num-slots = <1>;
+   pinctrl-names = "default";
+

Re: [PATCH 2/5] arm: dts: rockchip: px30: add and enable rng node

[Kever Yang]

On 2020/3/31 下午5:39, Lin Jinhan wrote:

Add enable rng node in px30-evb-u-boot.dtsi.

Signed-off-by: Lin Jinhan 



Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/px30-evb-u-boot.dtsi | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm/dts/px30-evb-u-boot.dtsi 
b/arch/arm/dts/px30-evb-u-boot.dtsi
index a2a2c07dcc..a73c215c05 100644
--- a/arch/arm/dts/px30-evb-u-boot.dtsi
+++ b/arch/arm/dts/px30-evb-u-boot.dtsi
@@ -12,6 +12,13 @@
chosen {
u-boot,spl-boot-order = &emmc, &sdmmc;
};
+
+   rng: rng@ff0b {
+   compatible = "rockchip,cryptov2-rng";
+   reg = <0x0 0xff0b 0x0 0x4000>;
+   status = "okay";
+   };
+
  };
  
  &dmc {

Re: [PATCH 1/5] arm: dts: rockchip: rk3399: add and enable rng node

[Kever Yang]

On 2020/3/31 下午5:39, Lin Jinhan wrote:

Add rng node in rk3399-u-boot.dtsi and enable it in
rk3399-evb-u-boot.dtsi.

Signed-off-by: Lin Jinhan 



Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/rk3399-evb-u-boot.dtsi | 5 +
  arch/arm/dts/rk3399-u-boot.dtsi | 6 ++
  2 files changed, 11 insertions(+)

diff --git a/arch/arm/dts/rk3399-evb-u-boot.dtsi 
b/arch/arm/dts/rk3399-evb-u-boot.dtsi
index ccb33d34d1..5b50c5ba30 100644
--- a/arch/arm/dts/rk3399-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-evb-u-boot.dtsi
@@ -11,3 +11,8 @@
u-boot,spl-boot-order = &sdhci, &sdmmc;
};
  };
+
+&rng {
+   status = "okay";
+};
+
diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index 8b857ccfc7..757b8c10a2 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -25,6 +25,12 @@
clock-names = "pclk_ddr_mon";
};
  
+	rng: rng@ff8b8000 {

+   compatible = "rockchip,cryptov1-rng";
+   reg = <0x0 0xff8b8000 0x0 0x1000>;
+   status = "disabled";
+   };
+
dmc: dmc {
u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-dmc";

Re: [PATCH 5/5] rockchip: px30: Enable CONFIG_RNG_ROCKCHIP

[Kever Yang]

On 2020/3/31 下午5:40, Lin Jinhan wrote:

CONFIG_RNG_ROCKCHIP/CONFIG_DM_RNG is enabled.

Signed-off-by: Lin Jinhan 



Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  configs/evb-px30_defconfig | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/configs/evb-px30_defconfig b/configs/evb-px30_defconfig
index b5ba75cc6e..d2cf13e54a 100644
--- a/configs/evb-px30_defconfig
+++ b/configs/evb-px30_defconfig
@@ -85,6 +85,8 @@ CONFIG_SPL_RAM=y
  CONFIG_TPL_RAM=y
  CONFIG_ROCKCHIP_SDRAM_COMMON=y
  CONFIG_DM_RESET=y
+CONFIG_DM_RNG=y
+CONFIG_RNG_ROCKCHIP=y
  # CONFIG_SPECIFY_CONSOLE_INDEX is not set
  CONFIG_DEBUG_UART_SHIFT=2
  CONFIG_DEBUG_UART_SKIP_INIT=y

Re: [PATCH 3/5] rockchip: rng: Add a driver for random number generator(rng) device

[Kever Yang]

On 2020/3/31 下午5:39, Lin Jinhan wrote:

Add a driver for the rng device found on rockchip platforms.
Support rng module of crypto v1 and crypto v2.

Signed-off-by: Lin Jinhan 



Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  drivers/rng/Kconfig|   8 ++
  drivers/rng/Makefile   |   1 +
  drivers/rng/rockchip_rng.c | 224 +
  3 files changed, 233 insertions(+)
  create mode 100644 drivers/rng/rockchip_rng.c

diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
index edb6152bb9..e4b22d79eb 100644
--- a/drivers/rng/Kconfig
+++ b/drivers/rng/Kconfig
@@ -31,4 +31,12 @@ config RNG_STM32MP1
help
  Enable STM32MP1 rng driver.
  
+config RNG_ROCKCHIP

+   bool "Enable random number generator for rockchip crypto rng"
+   depends on ARCH_ROCKCHIP && DM_RNG
+   default n
+   help
+ Enable random number generator for rockchip.This driver is
+ support rng module of crypto v1 and crypto v2.
+
  endif
diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
index 6a8a66779b..44a0003917 100644
--- a/drivers/rng/Makefile
+++ b/drivers/rng/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_DM_RNG) += rng-uclass.o
  obj-$(CONFIG_RNG_MESON) += meson-rng.o
  obj-$(CONFIG_RNG_SANDBOX) += sandbox_rng.o
  obj-$(CONFIG_RNG_STM32MP1) += stm32mp1_rng.o
+obj-$(CONFIG_RNG_ROCKCHIP) += rockchip_rng.o
diff --git a/drivers/rng/rockchip_rng.c b/drivers/rng/rockchip_rng.c
new file mode 100644
index 00..47fb140077
--- /dev/null
+++ b/drivers/rng/rockchip_rng.c
@@ -0,0 +1,224 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020 Fuzhou Rockchip Electronics Co., Ltd
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RK_HW_RNG_MAX 32
+
+#define _SBF(s, v) ((v) << (s))
+
+/* start of CRYPTO V1 register define */
+#define CRYPTO_V1_CTRL 0x0008
+#define CRYPTO_V1_RNG_STARTBIT(8)
+#define CRYPTO_V1_RNG_FLUSHBIT(9)
+
+#define CRYPTO_V1_TRNG_CTRL0x0200
+#define CRYPTO_V1_OSC_ENABLE   BIT(16)
+#define CRYPTO_V1_TRNG_SAMPLE_PERIOD(x)(x)
+
+#define CRYPTO_V1_TRNG_DOUT_0  0x0204
+/* end of CRYPTO V1 register define */
+
+/* start of CRYPTO V2 register define */
+#define CRYPTO_V2_RNG_CTL  0x0400
+#define CRYPTO_V2_RNG_64_BIT_LEN   _SBF(4, 0x00)
+#define CRYPTO_V2_RNG_128_BIT_LEN  _SBF(4, 0x01)
+#define CRYPTO_V2_RNG_192_BIT_LEN  _SBF(4, 0x02)
+#define CRYPTO_V2_RNG_256_BIT_LEN  _SBF(4, 0x03)
+#define CRYPTO_V2_RNG_FATESY_SOC_RING  _SBF(2, 0x00)
+#define CRYPTO_V2_RNG_SLOWER_SOC_RING_0_SBF(2, 0x01)
+#define CRYPTO_V2_RNG_SLOWER_SOC_RING_1_SBF(2, 0x02)
+#define CRYPTO_V2_RNG_SLOWEST_SOC_RING _SBF(2, 0x03)
+#define CRYPTO_V2_RNG_ENABLE   BIT(1)
+#define CRYPTO_V2_RNG_STARTBIT(0)
+#define CRYPTO_V2_RNG_SAMPLE_CNT   0x0404
+#define CRYPTO_V2_RNG_DOUT_0   0x0410
+/* end of CRYPTO V2 register define */
+
+#define RK_RNG_TIME_OUT5  /* max 50ms */
+
+struct rk_rng_soc_data {
+   int (*rk_rng_read)(struct udevice *dev, void *data, size_t len);
+};
+
+struct rk_rng_platdata {
+   fdt_addr_t base;
+   struct rk_rng_soc_data *soc_data;
+};
+
+static int rk_rng_read_regs(fdt_addr_t addr, void *buf, size_t size)
+{
+   u32 count = RK_HW_RNG_MAX / sizeof(u32);
+   u32 reg, tmp_len;
+
+   if (size > RK_HW_RNG_MAX)
+   return -EINVAL;
+
+   while (size && count) {
+   reg = readl(addr);
+   tmp_len = min(size, sizeof(u32));
+   memcpy(buf, ®, tmp_len);
+   addr += sizeof(u32);
+   buf += tmp_len;
+   size -= tmp_len;
+   count--;
+   }
+
+   return 0;
+}
+
+static int rk_v1_rng_read(struct udevice *dev, void *data, size_t len)
+{
+   struct rk_rng_platdata *pdata = dev_get_priv(dev);
+   u32 reg = 0;
+   int retval;
+
+   if (len > RK_HW_RNG_MAX)
+   return -EINVAL;
+
+   /* enable osc_ring to get entropy, sample period is set as 100 */
+   writel(CRYPTO_V1_OSC_ENABLE | CRYPTO_V1_TRNG_SAMPLE_PERIOD(100),
+  pdata->base + CRYPTO_V1_TRNG_CTRL);
+
+   rk_clrsetreg(pdata->base + CRYPTO_V1_CTRL, CRYPTO_V1_RNG_START,
+CRYPTO_V1_RNG_START);
+
+   retval = readl_poll_timeout(pdata->base + CRYPTO_V1_CTRL, reg,
+   !(reg & CRYPTO_V1_RNG_START),
+   RK_RNG_TIME_OUT);
+   if (retval)
+   goto exit;
+
+   rk_rng_read_regs(pdata->base + CRYPTO_V1_TRNG_DOUT_0, data, len);
+
+exit:
+   /* close TRNG */
+   rk_clrreg(pdata->base + CRYPTO_V1_CTRL, CRYPTO_V1_RNG_START);
+
+   return 0;
+}
+
+static int rk_v2_rng_read(stru

Re: [PATCH 4/5] rockchip: rk3399: Enable CONFIG_RNG_ROCKCHIP

[Kever Yang]

On 2020/3/31 下午5:40, Lin Jinhan wrote:

CONFIG_RNG_ROCKCHIP/CONFIG_DM_RNG is enabled.

Signed-off-by: Lin Jinhan 



Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  configs/evb-rk3399_defconfig | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index 3f74be3b3c..7f14e18b1b 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -39,6 +39,8 @@ CONFIG_PMIC_RK8XX=y
  CONFIG_REGULATOR_PWM=y
  CONFIG_REGULATOR_RK8XX=y
  CONFIG_PWM_ROCKCHIP=y
+CONFIG_DM_RNG=y
+CONFIG_RNG_ROCKCHIP=y
  CONFIG_BAUDRATE=150
  CONFIG_DEBUG_UART_SHIFT=2
  CONFIG_SYSRESET=y

Re: [Uboot-stm32] [PATCH 2/2] configs: migrate CONFIG_SYS_MTDPARTS_RUNTIME to defconfigs

[Patrice CHOTARD]

HI

On 2/26/20 10:28 AM, Patrick Delaunay wrote:
> Move CONFIG_SYS_MTDPARTS_RUNTIME into Kconfig done by moveconfig.py.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  configs/igep00x0_defconfig  | 1 +
>  configs/stm32mp15_basic_defconfig   | 1 +
>  configs/stm32mp15_dhcom_basic_defconfig | 1 +
>  configs/stm32mp15_optee_defconfig   | 1 +
>  configs/stm32mp15_trusted_defconfig | 1 +
>  drivers/mtd/Kconfig | 7 +++
>  include/configs/omap3_igep00x0.h| 2 --
>  include/configs/stm32mp1.h  | 5 -
>  scripts/config_whitelist.txt| 1 -
>  9 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/configs/igep00x0_defconfig b/configs/igep00x0_defconfig
> index e273f35e84..a5c301dbdb 100644
> --- a/configs/igep00x0_defconfig
> +++ b/configs/igep00x0_defconfig
> @@ -52,6 +52,7 @@ CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_DM_MMC=y
>  CONFIG_MMC_OMAP_HS=y
>  CONFIG_MTD=y
> +CONFIG_SYS_MTDPARTS_RUNTIME=y
>  CONFIG_MTD_RAW_NAND=y
>  CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
>  CONFIG_SPL_NAND_SIMPLE=y
> diff --git a/configs/stm32mp15_basic_defconfig 
> b/configs/stm32mp15_basic_defconfig
> index 4efb1bf9c2..85d0cd2b69 100644
> --- a/configs/stm32mp15_basic_defconfig
> +++ b/configs/stm32mp15_basic_defconfig
> @@ -91,6 +91,7 @@ CONFIG_SUPPORT_EMMC_BOOT=y
>  CONFIG_STM32_SDMMC2=y
>  CONFIG_MTD=y
>  CONFIG_DM_MTD=y
> +CONFIG_SYS_MTDPARTS_RUNTIME=y
>  CONFIG_MTD_RAW_NAND=y
>  CONFIG_NAND_STM32_FMC2=y
>  CONFIG_MTD_SPI_NAND=y
> diff --git a/configs/stm32mp15_dhcom_basic_defconfig 
> b/configs/stm32mp15_dhcom_basic_defconfig
> index 9b5e54748d..3b955cb8e6 100644
> --- a/configs/stm32mp15_dhcom_basic_defconfig
> +++ b/configs/stm32mp15_dhcom_basic_defconfig
> @@ -84,6 +84,7 @@ CONFIG_DM_MMC=y
>  CONFIG_SUPPORT_EMMC_BOOT=y
>  CONFIG_STM32_SDMMC2=y
>  CONFIG_MTD=y
> +CONFIG_SYS_MTDPARTS_RUNTIME=y
>  CONFIG_DM_SPI_FLASH=y
>  CONFIG_SPI_FLASH_MACRONIX=y
>  CONFIG_SPI_FLASH_SPANSION=y
> diff --git a/configs/stm32mp15_optee_defconfig 
> b/configs/stm32mp15_optee_defconfig
> index 54135b28aa..771381a7ad 100644
> --- a/configs/stm32mp15_optee_defconfig
> +++ b/configs/stm32mp15_optee_defconfig
> @@ -78,6 +78,7 @@ CONFIG_SUPPORT_EMMC_BOOT=y
>  CONFIG_STM32_SDMMC2=y
>  CONFIG_MTD=y
>  CONFIG_DM_MTD=y
> +CONFIG_SYS_MTDPARTS_RUNTIME=y
>  CONFIG_MTD_RAW_NAND=y
>  CONFIG_NAND_STM32_FMC2=y
>  CONFIG_MTD_SPI_NAND=y
> diff --git a/configs/stm32mp15_trusted_defconfig 
> b/configs/stm32mp15_trusted_defconfig
> index d7d0b6c296..d777978197 100644
> --- a/configs/stm32mp15_trusted_defconfig
> +++ b/configs/stm32mp15_trusted_defconfig
> @@ -77,6 +77,7 @@ CONFIG_SUPPORT_EMMC_BOOT=y
>  CONFIG_STM32_SDMMC2=y
>  CONFIG_MTD=y
>  CONFIG_DM_MTD=y
> +CONFIG_SYS_MTDPARTS_RUNTIME=y
>  CONFIG_MTD_RAW_NAND=y
>  CONFIG_NAND_STM32_FMC2=y
>  CONFIG_MTD_SPI_NAND=y
> diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
> index 5e7571cf3d..348b43e653 100644
> --- a/drivers/mtd/Kconfig
> +++ b/drivers/mtd/Kconfig
> @@ -22,6 +22,13 @@ config MTD_NOR_FLASH
>   help
> Enable support for parallel NOR flash.
>  
> +config SYS_MTDPARTS_RUNTIME
> + bool "Allow MTDPARTS to be configured at runtime"
> + depends on MTD
> + help
> +   This option allows to call the function board_mtdparts_default to
> +   dynamically build the variables mtdids and mtdparts at runtime.
> +
>  config FLASH_CFI_DRIVER
>   bool "Enable CFI Flash driver"
>   help
> diff --git a/include/configs/omap3_igep00x0.h 
> b/include/configs/omap3_igep00x0.h
> index 4ad7dc18b1..8dc30be8b7 100644
> --- a/include/configs/omap3_igep00x0.h
> +++ b/include/configs/omap3_igep00x0.h
> @@ -71,8 +71,6 @@
>  
>  #endif
>  
> -#define CONFIG_SYS_MTDPARTS_RUNTIME
> -
>  /* OneNAND config */
>  #define CONFIG_USE_ONENAND_BOARD_INIT
>  #define CONFIG_SYS_ONENAND_BASE  ONENAND_MAP
> diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
> index 592638072a..f451edad36 100644
> --- a/include/configs/stm32mp1.h
> +++ b/include/configs/stm32mp1.h
> @@ -85,11 +85,6 @@
>  #define CONFIG_SYS_AUTOLOAD  "no"
>  #endif
>  
> -/* Dynamic MTD partition support */
> -#if defined(CONFIG_STM32_QSPI) || defined(CONFIG_NAND_STM32_FMC2)
> -#define CONFIG_SYS_MTDPARTS_RUNTIME
> -#endif
> -
>  #ifdef CONFIG_DM_VIDEO
>  #define CONFIG_VIDEO_BMP_RLE8
>  #define CONFIG_BMP_16BPP
> diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
> index 85d55b182e..7c282cc976 100644
> --- a/scripts/config_whitelist.txt
> +++ b/scripts/config_whitelist.txt
> @@ -3198,7 +3198,6 @@ CONFIG_SYS_MRAM_SIZE
>  CONFIG_SYS_MSC0_VAL
>  CONFIG_SYS_MSC1_VAL
>  CONFIG_SYS_MSC2_VAL
> -CONFIG_SYS_MTDPARTS_RUNTIME
>  CONFIG_SYS_MX5_CLK32
>  CONFIG_SYS_MX5_HCLK
>  CONFIG_SYS_MX6_CLK32

Reviewed-by: Patrice Chotard 

Thanks

RE: [RFC PATCH] net, qe: add DM support for QE UEC ethernet

[Priyanka Jain]

>-Original Message-
>From: Heiko Schocher 
>Sent: Thursday, April 9, 2020 10:49 AM
>To: Priyanka Jain 
>Cc: U-Boot Mailing List ; Holger Brunck
>; Joe Hershberger ;
>Mario Six ; Qiang Zhao 
>Subject: Re: [RFC PATCH] net, qe: add DM support for QE UEC ethernet
>
>Hello Priyanka,
>
>Am 18.02.2020 um 10:05 schrieb Heiko Schocher:
>> add DM/DTS suppor for the UEC ethernet on QUICC Engine Block.
>>
>> Signed-off-by: Heiko Schocher 
>> ---
>> Travis build:
>>
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrav
>> is-ci.org%2Fhsdenx%2Fu-boot-
>test%2Fbuilds%2F651400509&data=02%7C01
>>
>%7Cpriyanka.jain%40nxp.com%7C51477945d03e4b72383708d7dc458e7e%7C
>686ea1
>>
>d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637220063612750872&sdat
>a=oV%2
>> BTyCsoQF17s4aQ1OGEIcMXWjB%2BhpiPunefUNtD6Fs%3D&reserved=0
>>
>> - I let the old none DM based implementation in code
>>so boards should work with old implementation.
>>This Code should be removed if all boards are converted
>>to DM/DTS.
>>
>> - add the DM based qe uec driver under drivers/net/qe
>>
>> - Therefore copied the files uccf.c uccf.h uec.h from
>>drivers/qe. So there are a lot of Codingstyle problems
>>currently. I fix them in next version if this RFC
>>patch is OK or it needs some changes.
>>
>> - The dm based driver code is now under drivers/net/qe/dm_qe_uec.c
>>Used a lot of functions from drivers/qe/uec.c
>>
>> - seperated the PHY specific code into seperate file
>>drivers/net/qe/dm_qe_uec_phy.c
>>
>>
>>   drivers/net/Kconfig|2 +
>>   drivers/net/Makefile   |1 +
>>   drivers/net/qe/Kconfig |9 +
>>   drivers/net/qe/Makefile|5 +
>>   drivers/net/qe/dm_qe_uec.c | 1161
>
>>   drivers/net/qe/dm_qe_uec.h |   22 +
>>   drivers/net/qe/dm_qe_uec_phy.c |  161 +
>>   drivers/net/qe/uccf.c  |  388 +++
>>   drivers/net/qe/uccf.h  |  117 
>>   drivers/net/qe/uec.h   |  742 
>>   drivers/qe/uccf.c  |2 +
>>   drivers/qe/uec.c   |2 +
>>   drivers/qe/uec_phy.c   |3 +
>>   13 files changed, 2615 insertions(+)
>>   create mode 100644 drivers/net/qe/Kconfig
>>   create mode 100644 drivers/net/qe/Makefile
>>   create mode 100644 drivers/net/qe/dm_qe_uec.c
>>   create mode 100644 drivers/net/qe/dm_qe_uec.h
>>   create mode 100644 drivers/net/qe/dm_qe_uec_phy.c
>>   create mode 100644 drivers/net/qe/uccf.c
>>   create mode 100644 drivers/net/qe/uccf.h
>>   create mode 100644 drivers/net/qe/uec.h
>
>Any comments?
>
>Thanks!
>
>bye,
>Heiko
Qiang Zhao is NXP Software IP expert for QE.  I am taking his help in review.

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

Re: [PATCH 08/11] Nokia RX-51: Enable CONFIG_CONSOLE_MUX

[Lokesh Vutla]

On 01/04/20 4:05 AM, Pali Rohár wrote:
> After this change both device display and serial console would contain
> U-Boto output automatically without any future configuration. This would

s/U-Boto/U-Boot

with that,
Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh

Re: [PATCH 00/11] Fixes for Nokia RX-51

[Lokesh Vutla]

On 13/04/20 4:11 PM, Pali Rohár wrote:
> On Wednesday 01 April 2020 00:35:07 Pali Rohár wrote:
>> This patch series contain fixes for Nokia RX-51 board (aka N900).
>> After these changes it is possible to run U-Boot in qemu emulator again.
>> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
>> problem.
>>
>> Pali Rohár (11):
>>   Nokia RX-51: Update my email address
>>   Nokia RX-51: Add README.nokia_rx51 file to MAINTAINERS
>>   Nokia RX-51: Move comment about CONFIG_SYS_TEXT_BASE to correct place
>>   Nokia RX-51: Move code from defconfig back to C header file
>>   Nokia RX-51: Revert back onenand defitions
>>   Nokia RX-51: Remove PART* macros
>>   Nokia RX-51: Remember setup_console_atag option
>>   Nokia RX-51: Enable CONFIG_CONSOLE_MUX
>>   Nokia RX-51: Disable some unused features to decrease size of u-boot
>> binary
>>   Nokia RX-51: Update README.nokia_rx51
>>   Nokia RX-51: Add automated test for running RX-51 build in qemu
> 
> Hello! Could you please review this patch series?

Series as such looks good to me. But as I see that thread, this series could not
boot on real hardware. Is that right?

Thanks and regards,
Lokesh

Re: [PATCH 00/11] Fixes for Nokia RX-51

[Pali Rohár]

On Tuesday 14 April 2020 15:53:14 Lokesh Vutla wrote:
> On 13/04/20 4:11 PM, Pali Rohár wrote:
> > On Wednesday 01 April 2020 00:35:07 Pali Rohár wrote:
> >> This patch series contain fixes for Nokia RX-51 board (aka N900).
> >> After these changes it is possible to run U-Boot in qemu emulator again.
> >> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> >> problem.
> >>
> >> Pali Rohár (11):
> >>   Nokia RX-51: Update my email address
> >>   Nokia RX-51: Add README.nokia_rx51 file to MAINTAINERS
> >>   Nokia RX-51: Move comment about CONFIG_SYS_TEXT_BASE to correct place
> >>   Nokia RX-51: Move code from defconfig back to C header file
> >>   Nokia RX-51: Revert back onenand defitions
> >>   Nokia RX-51: Remove PART* macros
> >>   Nokia RX-51: Remember setup_console_atag option
> >>   Nokia RX-51: Enable CONFIG_CONSOLE_MUX
> >>   Nokia RX-51: Disable some unused features to decrease size of u-boot
> >> binary
> >>   Nokia RX-51: Update README.nokia_rx51
> >>   Nokia RX-51: Add automated test for running RX-51 build in qemu
> > 
> > Hello! Could you please review this patch series?
> 
> Series as such looks good to me. But as I see that thread, this series could 
> not
> boot on real hardware. Is that right?

Without these patches U-Boot does not boot on both emulated and real HW.
With this patch series U-Boot boots at least on emulated env.

Older mainline U-Boot version worked fine on both emulated and real HW
so something was broken in U-Boot.

> Thanks and regards,
> Lokesh

Re: [PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

On Wednesday 01 April 2020 00:35:18 Pali Rohár wrote:
> This patch contains a script which automatically download and compile all
> needed tools to build a simple MTD images for booting Maemo kernel image by
> U-Boot from RAM, eMMC and OneNAND. MTD images are then run in virtual n900
> machine provided by qemu-linaro project.
> 
> It can be used to check that U-Boot for Nokia N900 is not broken and can be
> successfully booted in emulator.
> 
> Script is registered in to .travis.yml so it would be automatically run on
> Travi CI service.
> 
> Signed-off-by: Pali Rohár 

Tom Rini, in past you have asked me for N900 Travis test. So could you
please review this patch (including fixup at the bottom)?

> ---
>  .travis.yml   |  10 +++
>  test/rx51_test.sh | 208 ++
>  2 files changed, 218 insertions(+)
>  create mode 100755 test/rx51_test.sh
> 
> diff --git a/.travis.yml b/.travis.yml
> index c59bd7790b..d96811473c 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -40,6 +40,8 @@ addons:
>  - clang-7
>  - srecord
>  - graphviz
> +- mtools
> +- mtd-utils
>  
>  install:
>   # Clone uboot-test-hooks
> @@ -116,6 +118,11 @@ script:
>   # Comments must be outside the command strings below, or the Travis parser
>   # will get confused.
>   #
> + # Run tests for Nokia RX-51 (aka N900)
> + - if [[ -n "${NOKIA_RX51}" ]]; then
> + test/rx51_test.sh
> + exit $?;
> +   fi
>   # From buildman, exit code 129 means warnings only.  If we've been asked to
>   # use clang only do one configuration.
>   - if [[ "${BUILDMAN}" != "" ]]; then
> @@ -160,6 +167,9 @@ matrix:
>include:
># we need to build by vendor due to 50min time limit for builds
># each env setting here is a dedicated build
> +- name: "nokia rx51"
> +  env:
> +- NOKIA_RX51=1
>  - name: "buildman arc"
>env:
>  - BUILDMAN="arc"
> diff --git a/test/rx51_test.sh b/test/rx51_test.sh
> new file mode 100755
> index 00..43ecc07c08
> --- /dev/null
> +++ b/test/rx51_test.sh
> @@ -0,0 +1,208 @@
> +#!/bin/sh -e
> +# SPDX-License-Identifier: GPL-2.0+
> +# (C) 2020 Pali Rohár 
> +
> +# This test script depends on external tools:
> +# wget git truncate tar dpkg dd mcopy (from mtools) mkfs.ubifs (from 
> mtd-utils) ubinize (from mtd-utils)
> +
> +# Download and compile linaro version qemu which has support for n900 machine
> +# Last working commit is 8f8d8e0796efe1a6f34cdd83fb798f3c41217ec1
> +if ! test -f qemu-system-arm; then
> + test -d qemu-linaro || git clone 
> https://git.linaro.org/qemu/qemu-linaro.git
> + cd qemu-linaro
> + git checkout 8f8d8e0796efe1a6f34cdd83fb798f3c41217ec1
> + ./configure --enable-system --target-list=arm-softmmu --disable-sdl 
> --disable-gtk --disable-curses --audio-drv-list=pa,alsa --audio-card-list= 
> --disable-werror --disable-xen --disable-xen-pci-passthrough --disable-brlapi 
> --disable-vnc --disable-curl --disable-slirp --disable-kvm --disable-user 
> --disable-linux-user --disable-bsd-user --disable-guest-base --disable-uuid 
> --disable-vde --disable-linux-aio --disable-cap-ng --disable-attr 
> --disable-blobs --disable-docs --disable-spice --disable-libiscsi 
> --disable-smartcard-nss --disable-usb-redir --disable-guest-agent 
> --disable-seccomp --disable-glusterfs --disable-nptl --disable-fdt
> + make -j4
> + cd ..
> + ln -s qemu-linaro/arm-softmmu/qemu-system-arm .
> +fi
> +
> +# Download and compile dosfstools with mbr support
> +# Currently this support is in open pull request 95
> +if ! test -f mkfs.fat; then
> + test -d dosfstools || git clone 
> https://github.com/dosfstools/dosfstools.git
> + cd dosfstools
> + git fetch origin refs/pull/95/head
> + git checkout FETCH_HEAD
> + ./autogen.sh
> + ./configure
> + make -j4
> + cd ..
> + ln -s dosfstools/src/mkfs.fat .
> +fi
> +
> +# Download qflasher and nolo images
> +# This is proprietary qemu flasher tool with first stage images, but license 
> allows non-commercial redistribution
> +wget -c http://repository.maemo.org/qemu-n900/qemu-n900.tar.gz
> +tar -xf qemu-n900.tar.gz
> +
> +# Download Maemo script u-boot-gen-combined
> +if ! test -f u-boot-gen-combined; then
> + test -d u-boot-maemo || git clone 
> https://github.com/pali/u-boot-maemo.git
> + chmod +x u-boot-maemo/debian/u-boot-gen-combined
> + ln -s u-boot-maemo/debian/u-boot-gen-combined .
> +fi
> +
> +# Download Maemo fiasco kernel
> +wget -c 
> http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.28-20103103+0m5_armel.deb
> +dpkg -x kernel_2.6.28-20103103+0m5_armel.deb kernel_2.6.28
> +
> +# Download Maemo libc
> +wget -c 
> http://repository.maemo.org/pool/maemo5.0/free/g/glibc/libc6_2.5.1-1eglibc27+0m5_armel.deb
> +dpkg -x libc6_2.5.1-1eglibc27+0m5_armel.deb libc6_2.5.1
> +
> +# Download Maemo busybox
> +wget -c 
> http://repository.maemo.org/pool/maemo5.0/free/b/busybox/busybox_1.10.2.legal-1osso30+0m5_