date:20220120

Hi Sughosh,

2022年1月20日(木) 3:56 Sughosh Ganu :

> +static int fwu_gpt_update_mdata(struct fwu_mdata *mdata)
> +{
> +   int ret;
> +   struct blk_desc *desc;
> +   u16 primary_mpart = 0, secondary_mpart = 0;
> +

I think this update_mdata() method (or fwu_update_mdata() wrapper)
should always update mdata::crc32. calculate crc32 at each call site is
inefficient and easy to introduce bugs.

> +   ret = fwu_plat_get_blk_desc(&desc);
> +   if (ret < 0) {
> +   log_err("Block device not found\n");
> +   return -ENODEV;
> +   }
> +
> +   ret = gpt_get_mdata_partitions(desc, &primary_mpart,
> + &secondary_mpart);
> +
> +   if (ret < 0) {
> +   log_err("Error getting the FWU metadata partitions\n");
> +   return -ENODEV;
> +   }
> +
> +   /* First write the primary partition*/
> +   ret = gpt_write_mdata_partition(desc, mdata, primary_mpart);
> +   if (ret < 0) {
> +   log_err("Updating primary FWU metadata partition failed\n");
> +   return ret;
> +   }
> +
> +   /* And now the replica */
> +   ret = gpt_write_mdata_partition(desc, mdata, secondary_mpart);
> +   if (ret < 0) {
> +   log_err("Updating secondary FWU metadata partition failed\n");
> +   return ret;
> +   }
> +
> +   return 0;
> +}
> +
> +static int gpt_get_mdata(struct fwu_mdata **mdata)
> +{
> +   int ret;
> +   struct blk_desc *desc;
> +   u16 primary_mpart = 0, secondary_mpart = 0;
> +
> +   ret = fwu_plat_get_blk_desc(&desc);
> +   if (ret < 0) {
> +   log_err("Block device not found\n");
> +   return -ENODEV;
> +   }
> +
> +   ret = gpt_get_mdata_partitions(desc, &primary_mpart,
> +  &secondary_mpart);
> +
> +   if (ret < 0) {
> +   log_err("Error getting the FWU metadata partitions\n");
> +   return -ENODEV;
> +   }
> +
> +   *mdata = malloc(sizeof(struct fwu_mdata));
> +   if (!*mdata) {
> +   log_err("Unable to allocate memory for reading FWU 
> metadata\n");
> +   return -ENOMEM;
> +   }
> +
> +   ret = gpt_read_mdata(desc, *mdata, primary_mpart);
> +   if (ret < 0) {
> +   log_err("Failed to read the FWU metadata from the device\n");

Also, please release mdata inside the gpt_get_mdata() itself.

I think it is not a good design to ask caller to free mdata if get_mdata()
operation is failed because mdata may or may not allocated in error case.

In success case, user must free it because it is allocated (user accessed it),
and in error case, user can ignore it because it should not be allocated.
This is simpler mind model and less memory leak chance.

Thank you,
-- 
Masami Hiramatsu

[PULL u-boot] Please pull u-boot-amlogic-20220120

2022-01-20 Thread Neil Armstrong

Hi Tom,

Here's a few changes :
- CONFIG_NET_RANDOM_ETHADDR cleanup for VIM3/L Android configs I missed
- raw parts for bootloader to flash bootloader with fastboot with Android 
configs
- Add missing serial# like sei510/610 in order to satisfy fastboot

The CI job is at 
https://source.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/10491

Thanks,
Neil

The following changes since commit 068415eadefbbc81f14d4ce61fcf7a7eb39650d4:

  Merge tag 'xilinx-for-v2022.04-rc1' of 
https://source.denx.de/u-boot/custodians/u-boot-microblaze (2022-01-19 11:43:44 
-0500)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-amlogic.git 
tags/u-boot-amlogic-20220120

for you to fetch changes up to 09c2debab70271fdb3b1ff89e0e7d186502c548d:

  board: amlogic: vim3: configure serial# from ethaddr (2022-01-20 09:50:54 
+0100)


- Disable CONFIG_NET_RANDOM_ETHADDR for android configs
- meson64_android: define raw parts for bootloader to permit flashing with 
fastboot
- vim3: configure serial# from ethaddr to permit using fastboot like sei510/610


Mattijs Korpershoek (3):
  configs: amlogic: Disable CONFIG_NET_RANDOM_ETHADDR for android
  configs: meson64_android: define raw parts for bootloader
  board: amlogic: vim3: configure serial# from ethaddr

 board/amlogic/vim3/vim3.c | 9 +
 configs/khadas-vim3_android_ab_defconfig  | 1 -
 configs/khadas-vim3_android_defconfig | 1 -
 configs/khadas-vim3l_android_ab_defconfig | 1 -
 configs/khadas-vim3l_android_defconfig| 1 -
 include/configs/meson64_android.h | 2 ++
 6 files changed, 11 insertions(+), 4 deletions(-)

Re: [RFC PATCH v3 0/9] FWU: Add support for FWU Multi Bank Update feature


On 1/19/22 19:55, Sughosh Ganu wrote:

The patchset adds support for the FWU Multi Bank Update[1]
feature. Certain aspects of the Dependable Boot[2] specification have
also been implemented.


The document "Platform Security Firmware Update for the A-profile Arm
Architecture Beta" [1] that you relate to describes updating using FF-A
[5] as a communication protocol between a normal world client and an
update agent in the secure world. [1] further describes an API for this
communication. I cannot see that you are implementing this:

* U-Boot is living in the normal world, so it cannot be the update agent
of [1].
* Implementing the client of [1] in U-Boot would not require board
specific changes.

This patch set comes without any documentation update. We need a patch
which adds documents to U-Boot describing

* the design of the update mechanism
* the usage of the update mechanism

before we can start the review of the patches.

Best regards

Heinrich

[1] Platform Security Firmware Update for the A-profile Arm Architecture
Beta
https://developer.arm.com/documentation/den0118/a

[5] Arm Firmware Framework for Arm A-profile
https://developer.arm.com/documentation/den0077/latest



The FWU multi bank update feature is used for supporting multiple
sets(also called banks) of firmware image(s), allowing the platform to
boot from a different bank, in case it fails to boot from the active
bank. This functionality is supported by keeping the relevant
information in a structure called metadata, which provides information
on the images. Among other parameters, the metadata structure contains
information on the currect active bank that is being used to boot
image(s).

Functionality is being added to work with the UEFI capsule driver in
u-boot. The metadata is read to gather information on the update bank,
which is the bank to which the firmware images would be flashed to. On
a successful completion of the update of all components, the active
bank field in the metadata is updated, to reflect the bank from which
the platform will boot on the subsequent boots.

Currently, the feature is being enabled on the STM32MP157C-DK2
board which boots a FIP image from a uSD card partitioned with the GPT
partioning scheme. This also requires changes in the previous stage of
bootloader, which parses the metadata and selects the bank to boot the
image(s) from. Support is being added in tf-a(BL2 stage) for the
STM32MP157C-DK2 board to boot the active bank images. These changes
are under review currently[3].

 >

These patches are based on top of the series from Takahiro to add
Authentication support to mkeficapsule utility[4]

[1] - https://developer.arm.com/documentation/den0118/a
[2] - 
https://staging-git.codelinaro.org/linaro/firmware-dual-banked-updates/test
[3] - https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/12566
[4] - https://patchwork.ozlabs.org/project/uboot/list/?series=281549

Changes since V2:
* Use uint*_t types in fwu_mdata.h since the file is to be reused in
   other projects
* Keep only the FWU metadata structures in fwu_mdata.h
* Move all other function and macro declarations in fwu.h
* Keep common implementations of fwu_update_active_index and
   fwu_revert_boot_index in fwu_mdata.c
* Add a update_mdata function pointer in the fwu_mdata_ops structure
* Move the function definition of fwu_verify_mdata to fwu_mdata.c to
   facilitate reuse
* Remove the block device specific desc->devnum parameter for the
   fwu_plat_get_alt_num function call
* Change the implementation of fwu_plat_get_alt_num to get the devnum
   in the function before calling gpt_plat_get_alt_num
* Add logic to delete the TrialStateCtr variable if system is not in
   Trial State
* Add logic to check if bit 15(OS Acceptance) of the Flags member in
   the capsule header is set
* Add logic to set the accept bit of all images from a capsule if the
   OS Acceptance bit in the capsule header is not set
* Include the log.h and stdio.h header files

Sughosh Ganu (9):
   FWU: Add FWU metadata structure and functions for accessing metadata
   FWU: Add FWU metadata access functions for GPT partitioned block
 devices
   FWU: stm32mp1: Add helper functions for accessing FWU metadata
   FWU: STM32MP1: Add support to read boot index from backup register
   EFI: FMP: Add provision to update image's ImageTypeId in image
 descriptor
   FWU: Add boot time checks as highlighted by the FWU specification
   FWU: Add support for FWU Multi Bank Update feature
   FWU: cmd: Add a command to read FWU metadata
   mkeficapsule: Add support for generating empty capsules

  board/st/stm32mp1/stm32mp1.c| 183 ++
  cmd/Kconfig |   7 +
  cmd/Makefile|   1 +
  cmd/fwu_mdata.c |  67 
  common/board_r.c|   6 +
  include/fwu.h   |  81 +
  include/fwu_mdata.h |  69 
  lib/Kconfig |   6 +
  lib/

Re: [PATCH v3 31/31] RFC: Switch rpi over to use bootstd

2022-01-20 Thread Mark Kettenis

> From: Michael Walle 
> Date: Thu, 20 Jan 2022 09:35:44 +0100
> 
> > The bootdevs have a natural priority, based on the assumed speed of
> > the device, so the board would only need to intervene (with an env var
> > or a devicetree property) when that is wrong.
> 
> Does this make sense in general? The default boot order for a
> board should depend on what is available on board (or on the
> carrier board) and what is pluggable. I doubt there can be a sane
> default, so almost all boards will have to define its own
> boot order anyway.
> 
> So it doesn't really matter how the general list is sorted, but
> sorting by the speed of the interface sounds.. strange.

>From a security standpoint "removable" vs. "non-removable" is what
really matters.  You don't really want someone to plug a usb key or
SD card into your device and accidentally boot from it.

Also, changing the default boot order for an already supported device
is probably going to cause problems.  Something to keep in mind when
devices get converted to the new mechanism.

Re: [RFC PATCH v3 3/9] FWU: stm32mp1: Add helper functions for accessing FWU metadata


On 1/19/22 19:55, Sughosh Ganu wrote:

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

Signed-off-by: Sughosh Ganu 


It is unclear why you are creating platform specific code here.

All of this metadata can be put into the control devicetree? If not
create a driver class for it.

Unfortunately you don't provide any design document.


Best regards

Heinrich



---

Changes since V2:
* Change the implementation of fwu_plat_get_alt_num to get the devnum
   in the function before calling gpt_plat_get_alt_num

  board/st/stm32mp1/stm32mp1.c| 176 
  include/fwu.h   |   5 +
  lib/fwu_updates/fwu_mdata_gpt_blk.c |   7 +-
  3 files changed, 185 insertions(+), 3 deletions(-)

diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 84592677e4..66cbe3f798 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -7,10 +7,13 @@

  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
+#include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -23,9 +26,11 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -938,3 +943,174 @@ static void board_copro_image_process(ulong fw_image, 
size_t fw_size)
  }

  U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_COPRO, board_copro_image_process);
+
+#if defined(CONFIG_FWU_MULTI_BANK_UPDATE)
+#include 
+#include 
+
+static int gpt_plat_get_alt_num(int dev_num, void *identifier)
+{
+   int i;
+   int ret = -1;
+   u32 part;
+   int alt_num = dfu_get_alt_number();
+   struct dfu_entity *dfu;
+
+   part = *(u32 *)identifier;
+   dfu_init_env_entities(NULL, NULL);
+
+   for (i = 0; i < alt_num; i++) {
+   dfu = dfu_get_entity(i);
+
+   if (!dfu)
+   continue;
+
+   /*
+* Currently, Multi Bank update
+* feature is being supported
+* only on GPT partitioned
+* MMC/SD devices.
+*/
+   if (dfu->dev_type != DFU_DEV_MMC)
+   continue;
+
+   if (dfu->layout == DFU_RAW_ADDR &&
+   dfu->data.mmc.dev_num == dev_num &&
+   dfu->data.mmc.part == part) {
+   ret = dfu->alt;
+   break;
+   }
+   }
+
+   dfu_free_entities();
+
+   return ret;
+}
+
+int fwu_plat_get_alt_num(void *identifier)
+{
+   int ret;
+   struct blk_desc *desc;
+
+   ret = fwu_plat_get_blk_desc(&desc);
+   if (ret < 0) {
+   log_err("Block device not found\n");
+   return -ENODEV;
+   }
+
+   return gpt_plat_get_alt_num(desc->devnum, identifier);
+}
+
+static int plat_fill_gpt_partition_guids(struct blk_desc *desc,
+efi_guid_t **part_guid_arr)
+{
+   int i, ret = 0;
+   u32 part;
+   struct dfu_entity *dfu;
+   struct disk_partition info;
+   efi_guid_t part_type_guid;
+   int alt_num = dfu_get_alt_number();
+
+   dfu_init_env_entities(NULL, NULL);
+
+   for (i = 0, part = 1; i < alt_num; i++) {
+   dfu = dfu_get_entity(i);
+
+   if (!dfu)
+   continue;
+
+   /*
+* Currently, Multi Bank update
+* feature is being supported
+* only on GPT partitioned
+* MMC/SD devices.
+*/
+   if (dfu->dev_type != DFU_DEV_MMC)
+   continue;
+
+   if (part_get_info(desc, part, &info)) {
+   part++;
+   continue;
+   }
+
+   uuid_str_to_bin(info.type_guid, part_type_guid.b,
+   UUID_STR_FORMAT_GUID);
+   guidcpy((*part_guid_arr + i), &part_type_guid);
+   part++;
+   }
+
+   dfu_free_entities();
+
+   return ret;
+}
+
+int fwu_plat_fill_partition_guids(efi_guid_t **part_guid_arr)
+{
+   int ret;
+   struct blk_desc *desc;
+
+   ret = fwu_plat_get_blk_desc(&desc);
+   if (ret < 0) {
+   log_err("Block device not found\n");
+   return -ENODEV;
+   }
+
+   return plat_fill_gpt_partition_guids(desc, part_guid_arr);
+}
+
+int fwu_plat_get_update_index(u32 *update_idx)
+{
+   int ret;
+   u32 active_idx;
+
+   ret = fwu_get_active_index(&active_idx);
+
+   if (ret < 0)
+   return -1;
+
+   *update_idx = active_idx ^= 0x1;
+
+   return ret;
+}
+
+int fwu_plat_get_blk_desc(struct blk_desc **desc)
+{
+   int ret;
+   struct mmc *mmc;
+   struct

Re: [PATCH] cmd: mmc: Consider GP partitions in mmc hwpartition user enh start -

2022-01-20 Thread Fabio Estevam

Hi Marek,

On Mon, Jan 17, 2022 at 6:54 PM Marek Vasut  wrote:
>
> In case the eMMC contains any GP partitions or user sets up new GP
> partitions, the size of these GP partitions reduce the size of the
> USER partition. Subtract the size of those GP partitions from the
> calculated size of USER partition when using `user enh start -`.
>
> The following test used to fail before:
> ```
> u-boot=> mmc hwpartition gp1 524288 enh user enh 0 - wrrel on check
> Partition configuration:
> User Enhanced Start: 0 Bytes
> User Enhanced Size: 1.8 GiB
> User partition write reliability: on
> GP1 Capacity: 256 MiB ENH
> No GP2 partition
> No GP3 partition
> No GP4 partition
> Total enhanced size exceeds maximum (261 > 229)
> Failed!
> ```
> The test now passes:
> ```
> u-boot=> mmc hwpartition gp1 524288 enh user enh 0 - wrrel on check
> Partition configuration:
> User Enhanced Start: 0 Bytes
> User Enhanced Size: 1.5 GiB
> User partition write reliability: on
> GP1 Capacity: 256 MiB ENH
> No GP2 partition
> No GP3 partition
> No GP4 partition
> ```
>
> Signed-off-by: Marek Vasut 
> Cc: Fabio Estevam 
> Cc: Jaehoon Chung 
> Cc: Peng Fan 
> Cc: Stefano Babic 

Reviewed-by: Fabio Estevam

Re: [RFC PATCH v3 2/9] FWU: Add FWU metadata access functions for GPT partitioned block devices


On 1/19/22 19:55, Sughosh Ganu wrote:

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

Signed-off-by: Sughosh Ganu 


Will a GPT partition remain the only place to store that information?
Should this be implemented according to the dirver model?


---

Changes since V2:
* Move the function definition of fwu_verify_mdata to fwu_mdata.c to
   facilitate reuse
* Remove the block device specific desc->devnum parameter for the
   fwu_plat_get_alt_num function call

  include/fwu.h   |   1 +
  include/fwu_mdata.h |   2 +
  lib/fwu_updates/fwu_mdata.c |  29 ++
  lib/fwu_updates/fwu_mdata_gpt_blk.c | 520 
  4 files changed, 552 insertions(+)
  create mode 100644 lib/fwu_updates/fwu_mdata_gpt_blk.c

diff --git a/include/fwu.h b/include/fwu.h
index acba725bc8..12f7eecdb0 100644
--- a/include/fwu.h
+++ b/include/fwu.h
@@ -53,6 +53,7 @@ int fwu_get_active_index(u32 *active_idx);
  int fwu_update_active_index(u32 active_idx);
  int fwu_get_image_alt_num(efi_guid_t image_type_id, u32 update_bank,
  int *alt_num);
+int fwu_verify_mdata(struct fwu_mdata *mdata, bool pri_part);
  int fwu_mdata_check(void);
  int fwu_revert_boot_index(void);
  int fwu_accept_image(efi_guid_t *img_type_id, u32 bank);
diff --git a/include/fwu_mdata.h b/include/fwu_mdata.h
index d788eb69e7..53e39f9af6 100644
--- a/include/fwu_mdata.h
+++ b/include/fwu_mdata.h
@@ -64,4 +64,6 @@ struct fwu_mdata {
struct fwu_image_entry img_entry[CONFIG_FWU_NUM_IMAGES_PER_BANK];
  } __attribute__((__packed__));

+extern struct fwu_mdata_ops fwu_gpt_blk_ops;
+
  #endif /* _FWU_MDATA_H_ */
diff --git a/lib/fwu_updates/fwu_mdata.c b/lib/fwu_updates/fwu_mdata.c
index 58e838fe28..252fcf50f6 100644
--- a/lib/fwu_updates/fwu_mdata.c
+++ b/lib/fwu_updates/fwu_mdata.c
@@ -25,6 +25,35 @@ static struct fwu_mdata_ops *get_fwu_mdata_ops(void)
return ops;
  }

+/**
+ * fwu_verify_mdata() - Verify the FWU metadata
+ * @mdata: FWU metadata structure
+ * @pri_part: FWU metadata partition is primary or secondary
+ *
+ * Verify the FWU metadata by computing the CRC32 for the metadata
+ * structure and comparing it against the CRC32 value stored as part
+ * of the structure.
+ *
+ * Return: 0 if OK, -ve on error
+ *
+ */
+int fwu_verify_mdata(struct fwu_mdata *mdata, bool pri_part)
+{
+   u32 calc_crc32;
+   void *buf;
+
+   buf = &mdata->version;
+   calc_crc32 = crc32(0, buf, sizeof(*mdata) - sizeof(u32));


CRC32 does not offer any security against manipulation.
What are the security implications?

Best regards

Heinrich


+
+   if (calc_crc32 != mdata->crc32) {
+   log_err("crc32 check failed for %s FWU metadata partition\n",
+   pri_part ? "primary" : "secondary");
+   return -1;
+   }
+
+   return 0;
+}
+
  /**
   * fwu_get_active_index() - Get active_index from the FWU metadata
   * @active_idx: active_index value to be read
diff --git a/lib/fwu_updates/fwu_mdata_gpt_blk.c 
b/lib/fwu_updates/fwu_mdata_gpt_blk.c
new file mode 100644
index 00..cb47ddf4a7
--- /dev/null
+++ b/lib/fwu_updates/fwu_mdata_gpt_blk.c
@@ -0,0 +1,520 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2021, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define PRIMARY_PART   BIT(0)
+#define SECONDARY_PART BIT(1)
+#define BOTH_PARTS (PRIMARY_PART | SECONDARY_PART)
+
+#define MDATA_READ BIT(0)
+#define MDATA_WRITEBIT(1)
+
+#define IMAGE_ACCEPT_SET   BIT(0)
+#define IMAGE_ACCEPT_CLEAR BIT(1)
+
+static int gpt_get_mdata_partitions(struct blk_desc *desc,
+   u16 *primary_mpart,
+   u16 *secondary_mpart)
+{
+   int i, ret;
+   u32 mdata_parts;
+   efi_guid_t part_type_guid;
+   struct disk_partition info;
+   const efi_guid_t fwu_mdata_guid = FWU_MDATA_GUID;
+
+   for (i = 1; i < MAX_SEARCH_PARTITIONS; i++) {
+   if (part_get_info(desc, i, &info))
+   continue;
+   uuid_str_to_bin(info.type_guid, part_type_guid.b,
+   UUID_STR_FORMAT_GUID);
+
+   if (!guidcmp(&fwu_mdata_guid, &part_type_guid)) {
+   ++mdata_parts;
+   if (!*primary_mpart)
+   *primary_mpart = i;
+   else
+   *secondary_mpart = i;
+   }
+   }
+
+   if (mdata_parts != 2) {
+   log_err("Expe

UDC driver implementation

2022-01-20 Thread Oleh Kravchenko


Hello all,
I'm working on a new USB device controller driver for U-Boot.
And I need some advice how to properly implement it.

Could you please describe what is gadget.ep0?
- Why ep0 defined separetly (not included in end points list)?
- Why other end-points has "in" and "out" `struct usb_ep` descriptor, but not 
ep0?

--
Best regards,
Oleh Kravchenko

Re: [RESEND PATCH v3 4/4] arm: kirkwood: Pogoplug V4 : Add board include header and defconfig files


Hi Tony,

On 1/20/22 01:28, Tony Dinh wrote:

Add board include header and defconfig files for Pogoplug V4

Signed-off-by: Tony Dinh 
---

Changes in v3:
- Migrate config symbols from board include header to defconfig
- Remove obsolete config symbols from header file
- Don't use ifdefs for unselectable config symbols in header file

Changes in v2:
- Use canonical format for defconfig file

  configs/pogo_v4_defconfig | 79 +++
  include/configs/pogo_v4.h | 56 +++
  2 files changed, 135 insertions(+)
  create mode 100644 configs/pogo_v4_defconfig
  create mode 100644 include/configs/pogo_v4.h

diff --git a/configs/pogo_v4_defconfig b/configs/pogo_v4_defconfig
new file mode 100644
index 00..5490067b9e
--- /dev/null
+++ b/configs/pogo_v4_defconfig
@@ -0,0 +1,79 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_SYS_DCACHE_OFF=y
+CONFIG_ARCH_CPU_INIT=y
+CONFIG_SYS_THUMB_BUILD=y
+CONFIG_ARCH_KIRKWOOD=y
+CONFIG_SYS_KWD_CONFIG="board/cloudengines/pogo_v4/kwbimage.cfg"
+CONFIG_SYS_TEXT_BASE=0x60
+CONFIG_TARGET_POGO_V4=y
+CONFIG_ENV_SIZE=0x2
+CONFIG_ENV_OFFSET=0xC
+CONFIG_DEFAULT_DEVICE_TREE="kirkwood-pogoplug-series-4"
+CONFIG_IDENT_STRING="\nPogoplug V4"
+CONFIG_SYS_LOAD_ADDR=0x80
+CONFIG_BOOTSTAGE=y
+CONFIG_SHOW_BOOT_PROGRESS=y
+CONFIG_BOOTDELAY=10
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="setenv bootargs ${bootargs_console}; run bootcmd_usb; bootm 
0x0080 0x0110 0x2c0"
+CONFIG_USE_PREBOOT=y
+CONFIG_BOARD_LATE_INIT=y
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_PROMPT="Pogo_V4> "
+CONFIG_CMD_BOOTZ=y
+# CONFIG_BOOTM_PLAN9 is not set
+# CONFIG_BOOTM_RTEMS is not set
+# CONFIG_BOOTM_VXWORKS is not set
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_MTD=y
+CONFIG_CMD_NAND=y
+CONFIG_CMD_PCI=y
+CONFIG_CMD_SATA=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_SNTP=y
+CONFIG_CMD_DNS=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_JFFS2=y
+CONFIG_CMD_MTDPARTS=y
+CONFIG_MTDIDS_DEFAULT="nand0=orion_nand"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=orion_nand:2M(u-boot),3M(uImage),3M(uImage2),8M(failsafe),112M(root)"
+CONFIG_CMD_UBI=y
+CONFIG_ISO_PARTITION=y
+CONFIG_EFI_PARTITION=y
+CONFIG_PARTITION_TYPE_GUID=y
+CONFIG_OF_CONTROL=y
+CONFIG_ENV_OVERWRITE=y
+CONFIG_ENV_IS_IN_NAND=y
+CONFIG_VERSION_VARIABLE=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_NETCONSOLE=y
+CONFIG_DM=y
+CONFIG_SATA_MV=y
+CONFIG_KIRKWOOD_GPIO=y
+# CONFIG_MMC_HW_PARTITIONING is not set
+CONFIG_MVEBU_MMC=y
+CONFIG_MTD=y
+CONFIG_MTD_RAW_NAND=y
+CONFIG_DM_ETH=y
+CONFIG_MVGBE=y
+CONFIG_MII=y
+CONFIG_PCI=y
+CONFIG_PCI_MVEBU=y
+CONFIG_DM_RTC=y
+CONFIG_RTC_EMULATION=y
+CONFIG_SYS_NS16550=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_PCI=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_STORAGE=y
+CONFIG_JFFS2_LZO=y
+CONFIG_JFFS2_NAND=y
diff --git a/include/configs/pogo_v4.h b/include/configs/pogo_v4.h
new file mode 100644
index 00..d94d49505a
--- /dev/null
+++ b/include/configs/pogo_v4.h
@@ -0,0 +1,56 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2014-2022 Tony Dinh 
+ *
+ * Based on
+ * Copyright (C) 2012
+ * David Purdy 
+ *
+ * Based on Kirkwood support:
+ * (C) Copyright 2009
+ * Marvell Semiconductor 
+ * Written-by: Prafulla Wadaskar 
+ */
+
+#ifndef _CONFIG_POGO_V4_H
+#define _CONFIG_POGO_V4_H
+
+/*
+ * mv-common.h should be defined after CMD configs since it used them
+ * to enable certain macros
+ */
+#include "mv-common.h"
+
+/*
+ * Default environment variables
+ */
+#define CONFIG_EXTRA_ENV_SETTINGS \
+   "dtb_file=/boot/dts/" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
+   "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0"\
+   "mtdids=nand0=orion_nand\0"\
+   "bootargs_console=console=ttyS0,115200\0" \
+   "bootcmd_usb=usb start; load usb 0:1 0x0080 /boot/uImage; " \
+   "load usb 0:1 0x0110 /boot/uInitrd; " \
+   "load usb 0:1 0x2c0 $dtb_file\0"
+
+/*
+ * Ethernet Driver configuration
+ */
+#ifdef CONFIG_CMD_NET


Will this ever be build without CONFIG_CMD_NET? If not, then please
remove the #ifdef here as well.


+#define CONFIG_FEATURE_COMMAND_EDITING /* for netconsole */


And here the main problem:

[stefan@ryzen u-boot-marvell (master)]$ make pogo_v4_defconfig
#
# configuration written to .config
#
[stefan@ryzen u-boot-marvell (master)]$ make -s -j20
= WARNING ==
This board does not use CONFIG_TIMER (Driver Model
for Timer drivers). Please update the board to use
CONFIG_TIMER before the v2023.01 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.

Error: You must add new CONFIG options using Kconfig
The following new ad-hoc CONFIG options were detected:
CONFIG_FEATURE_COMMAND_EDITING

Please add these via Kconfig instead. Find a suitable Kconfig
file and add a

Re: [RFC PATCH v3 1/9] FWU: Add FWU metadata structure and functions for accessing metadata


On 1/19/22 19:55, Sughosh Ganu wrote:

In the FWU Multi Bank Update feature, the information about the
updatable images is stored as part of the metadata, which is stored on
a dedicated partition. Add the metadata structure, and functions to
access the metadata. These are generic API's, and implementations can
be added based on parameters like how the metadata partition is
accessed and what type of storage device houses the metadata.

Signed-off-by: Sughosh Ganu 


I would have expected a new uclass implementing

* FFA_PARTITION_INFO_GET()

as defined in [1] and suggested by [2].

Reading the data from a partition could be implemented in one of the
drivers.

Please, have a look at
https://u-boot.readthedocs.io/en/latest/develop/driver-model/index.html

[1] Arm Firmware Framework for Arm A-profile
(https://developer.arm.com/documentation/den0077/latest)
[2] Platform Security Firmware Update for the A-profile Arm Architecture
Beta
(https://developer.arm.com/documentation/den0118/a)

Best regards

Heinrich


---

Changes since V2:
* Use uint*_t types in fwu_mdata.h since the file is to be reused in
   other projects
* Keep only the FWU metadata structures in fwu_mdata.h
* Move all other function and macro declarations in fwu.h
* Keep common implementations of fwu_update_active_index and
   fwu_revert_boot_index in fwu_mdata.c
* Add a update_mdata function pointer in the fwu_mdata_ops structure

  include/fwu.h   |  61 +++
  include/fwu_mdata.h |  67 
  lib/fwu_updates/fwu_mdata.c | 329 
  3 files changed, 457 insertions(+)
  create mode 100644 include/fwu.h
  create mode 100644 include/fwu_mdata.h
  create mode 100644 lib/fwu_updates/fwu_mdata.c

diff --git a/include/fwu.h b/include/fwu.h
new file mode 100644
index 00..acba725bc8
--- /dev/null
+++ b/include/fwu.h
@@ -0,0 +1,61 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2021, Linaro Limited
+ */
+
+#if !defined _FWU_H_
+#define _FWU_H_
+
+#include 
+#include 
+
+#include 
+
+struct fwu_mdata;
+
+/**
+ * @get_active_index: get the current active_index value
+ * @get_image_alt_num: get the alt number to be used for the image
+ * @mdata_check: check the validity of the FWU metadata partitions
+ * @set_accept_image: set the accepted bit for the image
+ * @clear_accept_image: clear the accepted bit for the image
+ * @get_mdata() - Get a FWU metadata copy
+ * @update_mdata() - Update the FWU metadata copy
+ */
+struct fwu_mdata_ops {
+   int (*get_active_index)(u32 *active_idx);
+
+   int (*get_image_alt_num)(efi_guid_t image_type_id, u32 update_bank,
+int *alt_num);
+
+   int (*mdata_check)(void);
+
+   int (*set_accept_image)(efi_guid_t *img_type_id, u32 bank);
+
+   int (*clear_accept_image)(efi_guid_t *img_type_id, u32 bank);
+
+   int (*get_mdata)(struct fwu_mdata **mdata);
+
+   int (*update_mdata)(struct fwu_mdata *mdata);
+};
+
+struct fwu_mdata_ops *get_plat_fwu_mdata_ops(void);
+
+#define FWU_MDATA_VERSION  0x1
+
+#define FWU_MDATA_GUID \
+   EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \
+0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23)
+
+int fwu_get_mdata(struct fwu_mdata **mdata);
+int fwu_update_mdata(struct fwu_mdata *mdata);
+int fwu_get_active_index(u32 *active_idx);
+int fwu_update_active_index(u32 active_idx);
+int fwu_get_image_alt_num(efi_guid_t image_type_id, u32 update_bank,
+ int *alt_num);
+int fwu_mdata_check(void);
+int fwu_revert_boot_index(void);
+int fwu_accept_image(efi_guid_t *img_type_id, u32 bank);
+int fwu_clear_accept_image(efi_guid_t *img_type_id, u32 bank);
+
+#endif /* _FWU_H_ */
diff --git a/include/fwu_mdata.h b/include/fwu_mdata.h
new file mode 100644
index 00..d788eb69e7
--- /dev/null
+++ b/include/fwu_mdata.h
@@ -0,0 +1,67 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2021, Linaro Limited
+ */
+
+#if !defined _FWU_MDATA_H_
+#define _FWU_MDATA_H_
+
+#include 
+
+/**
+ * struct fwu_image_bank_info - firmware image information
+ * @image_uuid: Guid value of the image in this bank
+ * @accepted: Acceptance status of the image
+ * @reserved: Reserved
+ *
+ * The structure contains image specific fields which are
+ * used to identify the image and to specify the image's
+ * acceptance status
+ */
+struct fwu_image_bank_info {
+   efi_guid_t  image_uuid;
+   uint32_t accepted;
+   uint32_t reserved;
+} __attribute__((__packed__));
+
+/**
+ * struct fwu_image_entry - information for a particular type of image
+ * @image_type_uuid: Guid value for identifying the image type
+ * @location_uuid: Guid of the storage volume where the image is located
+ * @img_bank_info: Array containing properties of images
+ *
+ * This structure contains information on various types of updatable
+ * firmware images. Each image type then contains an array of image
+ * information per bank.
+ */
+struct fwu_image_entry

Re: [RFC PATCH v3 4/9] FWU: STM32MP1: Add support to read boot index from backup register


On 1/19/22 19:55, Sughosh Ganu wrote:

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

Signed-off-by: Sughosh Ganu 
---

Changes since V2: None

  board/st/stm32mp1/stm32mp1.c | 7 +++
  include/fwu.h| 1 +
  2 files changed, 8 insertions(+)

diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 66cbe3f798..6e78a4 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -1104,6 +1104,13 @@ int fwu_plat_get_blk_desc(struct blk_desc **desc)
return 0;
  }

+void fwu_plat_get_bootidx(void *boot_idx)
+{
+   u32 *bootidx = boot_idx;
+
+   *bootidx = readl(TAMP_BOOTCOUNT);
+}
+


Please, follow the driver model in your implementation.

https://u-boot.readthedocs.io/en/latest/develop/driver-model/index.html

Best regards

Heinrich


  struct fwu_mdata_ops *get_plat_fwu_mdata_ops(void)
  {
if (CONFIG_IS_ENABLED(TARGET_ST_STM32MP15x) &&
diff --git a/include/fwu.h b/include/fwu.h
index b23a93ac40..6393a1dbb5 100644
--- a/include/fwu.h
+++ b/include/fwu.h
@@ -63,5 +63,6 @@ int fwu_plat_get_update_index(u32 *update_idx);
  int fwu_plat_get_blk_desc(struct blk_desc **desc);
  int fwu_plat_get_alt_num(void *identifier);
  int fwu_plat_fill_partition_guids(efi_guid_t **part_guid_arr);
+void fwu_plat_get_bootidx(void *boot_idx);

  #endif /* _FWU_H_ */

Re: [RFC PATCH v3 8/9] FWU: cmd: Add a command to read FWU metadata


On 1/19/22 19:55, Sughosh Ganu wrote:

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

Signed-off-by: Sughosh Ganu 
---

Changes since V2:
* Include the log.h and stdio.h header files

  cmd/Kconfig |  7 ++
  cmd/Makefile|  1 +
  cmd/fwu_mdata.c | 67 +
  3 files changed, 75 insertions(+)
  create mode 100644 cmd/fwu_mdata.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 02c298fdbe..c8eb12e00f 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -137,6 +137,13 @@ config CMD_CPU
  internal name) and clock frequency. Other information may be
  available depending on the CPU driver.

+config CMD_FWU_METADATA
+   bool "fwu metadata read"
+   depends on FWU_MULTI_BANK_UPDATE
+   default y if FWU_MULTI_BANK_UPDATE
+   help
+ Command to read the metadata and dump it's contents
+
  config CMD_LICENSE
bool "license"
select BUILD_BIN2C
diff --git a/cmd/Makefile b/cmd/Makefile
index e31ac15ef7..b917527965 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_CMD_FPGA) += fpga.o
  obj-$(CONFIG_CMD_FPGAD) += fpgad.o
  obj-$(CONFIG_CMD_FS_GENERIC) += fs.o
  obj-$(CONFIG_CMD_FUSE) += fuse.o
+obj-$(CONFIG_CMD_FWU_METADATA) += fwu_mdata.o
  obj-$(CONFIG_CMD_GETTIME) += gettime.o
  obj-$(CONFIG_CMD_GPIO) += gpio.o
  obj-$(CONFIG_CMD_HVC) += smccc.o
diff --git a/cmd/fwu_mdata.c b/cmd/fwu_mdata.c
new file mode 100644
index 00..81e4850442
--- /dev/null
+++ b/cmd/fwu_mdata.c
@@ -0,0 +1,67 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2021, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static void print_mdata(struct fwu_mdata *mdata)
+{
+   int i, j;
+   struct fwu_image_entry *img_entry;
+   struct fwu_image_bank_info *img_info;
+   u32 nimages, nbanks;
+
+   printf("\tFWU Metadata Read\n");


:%/ Read//

Nobody expects that this is data written.


+   printf("crc32: %#x\n", mdata->crc32);
+   printf("version: %#x\n", mdata->version);
+   printf("active_index: %#x\n", mdata->active_index);
+   printf("previous_active_index: %#x\n", mdata->previous_active_index);
+
+   nimages = CONFIG_FWU_NUM_IMAGES_PER_BANK;
+   nbanks = CONFIG_FWU_NUM_BANKS;
+   printf("\tImage Info\n");
+   for (i = 0; i < nimages; i++) {
+   img_entry = &mdata->img_entry[i];
+   printf("\nImage Type Guid: %pUL\n", 
&img_entry->image_type_uuid);
+   printf("Location Guid: %pUL\n", &img_entry->location_uuid);
+   for (j = 0; j < nbanks; j++) {
+   img_info = &img_entry->img_bank_info[j];
+   printf("Image Guid:  %pUL\n", &img_info->image_uuid);
+   printf("Image Acceptance: %#x\n", img_info->accepted);
+   }
+   }
+}
+
+int do_fwu_mdata_read(struct cmd_tbl *cmdtp, int flag,
+int argc, char * const argv[])
+{
+   int ret = CMD_RET_SUCCESS;
+   struct fwu_mdata *mdata = NULL;
+
+   ret = fwu_get_mdata(&mdata);
+   if (ret < 0) {
+   log_err("Unable to get valid FWU metadata\n");
+   ret = CMD_RET_FAILURE;
+   goto out;
+   }
+
+   print_mdata(mdata);
+
+out:
+   free(mdata);
+   return ret;
+}
+
+U_BOOT_CMD(
+   fwu_mdata_read, 1,  1,  do_fwu_mdata_read,
+   "Read and print FWU metadata",
+   ""
+);


For any new command, please, add documentation in /doc/usage/.

Best regards

Heinrich

Re: [PATCH v3] drivers: spi-nor: Add JEDEC id for W25Q16JV

On Mon, Jan 17, 2022 at 7:27 PM Angus Ainslie  wrote:
>
> Add a JEDEC id for the Winbond W25Q16JV 16M-BIT serial flash memory with
> DUAL/QUAD SPI
>
> Changes since v2:
>
> Chagned the name to follow "DTR" parts
>
> Changes since v1:
>
> Updated the name for more suffixes
>
> Signed-off-by: Angus Ainslie 
> ---
>  drivers/mtd/spi/spi-nor-ids.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> index b551ebd75e..08e386fbf5 100644
> --- a/drivers/mtd/spi/spi-nor-ids.c
> +++ b/drivers/mtd/spi/spi-nor-ids.c
> @@ -314,6 +314,11 @@ const struct flash_info spi_nor_ids[] = {
> SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
> },
> +   {
> +   INFO("w25q16jvm", 0xef7015, 0, 64 * 1024,  32,

Can this name as "w25q16jv-im/jm" ?

Jagan.

Re: [PATCH v11] driver: spi: add bcm iproc qspi support

On Sat, Dec 18, 2021 at 1:52 AM Roman Bacik  wrote:
>
> From: Rayagonda Kokatanur 
>
> IPROC qspi driver supports both BSPI and MSPI modes.
>
> Signed-off-by: Rayagonda Kokatanur 
> Signed-off-by: Bharat Gooty 
> Acked-by: Rayagonda Kokatanur 
>
> Signed-off-by: Roman Bacik 
> ---
>
> Changes in v11:
> - fix condition for readl_poll_timeout in bspi_read_via_raf
>
> Changes in v10:
> - remove binding document
> - use defined values for delays and timeouts
> - replace timer-based logic with readl_poll_timeout
> - format selected commands to single line
> - remove unnecessary entries from struct bcmspi_priv
> - simplify and move bspi strap override to bspi_set_flex_mode
>
> Changes in v9:
> - merge bspi_set_4byte_mode to bspi_set_flex_mode
> - simplify bspi_set_flex_mode using data from spi_mem_op
> - rename mode_4byte to bspi_4byte
> - use BIT(x) istead of 1<
> Changes in v8:
> - add 4-byte address support
>
> Changes in v7:
> - remove hardcorded IPROC_BSPI_READ_DUMMY_CYCLES
> - remove unnecessary flags from bspi_read
> - fix BSPI supported operation condition
>
> Changes in v6:
> - remove priv->mode_4byte
> - remove IPROC_BSPI_READ_SUPPORTED
>
> Changes in v5:
> - add binding document
> - implement spi-mem interface for bspi mode
> - use op->cmd.opcode for BSPI_CMD_AND_MODE_BYTE_REG
> - move iproc_qspi.c to spi
>
> Changes in v4:
> - move iproc_qspi.c from spi to mtd/spi
> - remove iproc_qspi.h
> - rename IPROC_QSPI to SPI_FLASH_IPROC
>
> Changes in v3:
> - fix warning by including linux/delay.h
> - change ofdata_to_platdata to of_to_plat
> - change priv_auto_alloc_size to priv_auto
>
> Changes in v2:
> - remove include spi-nor.h
> - define and use named BITs for writing register values
> - remove bspi_set_4byte_mode() method
>
>  drivers/spi/Kconfig  |   6 +
>  drivers/spi/Makefile |   1 +
>  drivers/spi/iproc_qspi.c | 573 +++
>  3 files changed, 580 insertions(+)
>  create mode 100644 drivers/spi/iproc_qspi.c
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index d07e9a28af82..faebc212753e 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -178,6 +178,12 @@ config ICH_SPI
>   access the SPI NOR flash on platforms embedding this Intel
>   ICH IP core.
>
> +config IPROC_QSPI
> +   bool "Broadcom iProc QSPI Flash Controller driver"
> +   help
> + Enable Broadcom iProc QSPI Flash Controller driver.
> + This driver can be used to access the SPI NOR flash.
> +
>  config KIRKWOOD_SPI
> bool "Marvell Kirkwood SPI Driver"
> help
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index d2f24bccefd3..869763187062 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_FSL_DSPI) += fsl_dspi.o
>  obj-$(CONFIG_FSL_ESPI) += fsl_espi.o
>  obj-$(CONFIG_SYNQUACER_SPI) += spi-synquacer.o
>  obj-$(CONFIG_ICH_SPI) +=  ich.o
> +obj-$(CONFIG_IPROC_QSPI) += iproc_qspi.o
>  obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
>  obj-$(CONFIG_MESON_SPIFC) += meson_spifc.o
>  obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
> diff --git a/drivers/spi/iproc_qspi.c b/drivers/spi/iproc_qspi.c
> new file mode 100644
> index ..0f9c2f9729c4
> --- /dev/null
> +++ b/drivers/spi/iproc_qspi.c
> @@ -0,0 +1,573 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2020-2021 Broadcom
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Delay required to change the mode of operation */
> +#define BUSY_DELAY_US  1
> +#define BUSY_TIMEOUT_US20
> +#define DWORD_ALIGNED(a)   (!(((ulong)(a)) & 3))
> +
> +/* Chip attributes */
> +#define QSPI_AXI_CLK   17500
> +#define SPBR_MIN   8U
> +#define SPBR_MAX   255U
> +#define NUM_CDRAM  16U
> +
> +#define CDRAM_PCS0 2
> +#define CDRAM_CONT BIT(7)
> +#define CDRAM_BITS_EN  BIT(6)
> +#define CDRAM_QUAD_MODEBIT(8)
> +#define CDRAM_RBIT_INPUT   BIT(10)
> +#define MSPI_SPE   BIT(6)
> +#define MSPI_CONT_AFTER_CMDBIT(7)
> +
> +/* Register fields */
> +#define MSPI_SPCR0_MSB_BITS_8  0x0020
> +#define BSPI_RAF_CONTROL_START_MASK0x0001
> +#define BSPI_RAF_STATUS_SESSION_BUSY_MASK  0x0001
> +#define BSPI_RAF_STATUS_FIFO_EMPTY_MASK0x0002
> +#define BSPI_STRAP_OVERRIDE_DATA_QUAD_SHIFT3
> +#define BSPI_STRAP_OVERRIDE_4BYTE_SHIFT2
> +#define BSPI_STRAP_OVERRIDE_DATA_DUAL_SHIFT1
> +#define BSPI_STRAP_OVERRIDE_SHIFT  0
> +#define BSPI_BPC_DATA_SHIFT0
> +#define BSPI_BPC_MODE_SHIFT

Re: [PATCH v4 0/3] mtd: Support slc-mode for NTC CHIP

On Fri, Dec 17, 2021 at 12:14 AM Chris Morgan  wrote:
>
> From: Chris Morgan 
>
> Add support for slc-mode implemented in Linux for the Toshiba
> TC58TEG5DCLTA00 NAND and Hynix H27UCG8T2ETR NAND flash found on the NTC
> CHIP. This requires the addition of a paired-pages scheme, a new
> parameter for MTD partitions of slc-mode, and setting the correct
> paired-pages scheme for the TC58TEG5DCLTA00  and H27UCG8T2ETR flash
> chips.
>
> Changes since V3:
>   - Rebased against master branch as of 2021-12-16.
>   - Added slc mode support for mtdparts command.
>
> Changes since V2:
>  - Copied upstream Linux implementation of mtd_erase to fix an issue
>with creating new ubi partitions.
>  - Implemented paired page scheme and added support for Hynix flash
>chip. Based on a cursory reading of the datasheet it appears to use
>the same pairing scheme as the Toshiba chip.
>
> Changes since V1:
>
>  - Updated mtd_read and mtd_write to match upstream Linux.
>  - Additional mtd_get_master to match upstream Linux.
>  - Removed notes about ubifs not working, because it is now.
>
> Signed-off-by: Chris Morgan 
>
> Chris Morgan (3):
>   mtd: Add support for Linux slc-mode for MLC NAND
>   mtd: Add pairing info for Toshiba TC58TEG5DCLTA00 NAND
>   mtd: Add pairing info for Hynix H27UCG8T2ETR NAND

Patch series updating most of MTD core code, any user from parallel
nand or nor can make test or ack would help to merge this code.

Thanks,
Jagan.

Re: [PATCH v3] drivers: spi-nor: Add JEDEC id for W25Q16JV

2022-01-20 Thread Michael Walle

>> +   {
>> +   INFO("w25q16jvm", 0xef7015, 0, 64 * 1024,  32,
>
> Can this name as "w25q16jv-im/jm" ?

FWIW, "w25q15jvm" would be the "correct" name in linux. Although for this
particular flash the name in linux is "w25q16jv-im/jm"..

Anyhow, see [1] for a lengthy discussion on that name. That being said, I
still don't share Tudors opinion on using that made up name, just because
no one will find any flash if one searches for w25q16jvm in the internet.

-michael

[1] https://lore.kernel.org/linux-mtd/20200103223423.14025-1-mich...@walle.cc/

Re: [PATCH 7/7] sunxi: H6: Enable SPI0 in DT when no eMMC is used

On Tue, Jan 11, 2022 at 6:16 PM Andre Przywara  wrote:
>
> On the Allwinner H6 SoC both the SPI0 and the eMMC device share one pin,
> so cannot be used simultaneously. On Linux this is a showstopper, since
> only one of them would be able to claim the pin, and the probe order is
> somewhat random. The DT consequently disables SPI0 in favour of the more
> useful eMMC.
>
> But a comment in the DT actually suggests that this could be reversed by
> U-Boot, if no eMMC is actually connected. Let's now implement this:
> When we fix up the device tree before booting a kernel, we iterate over
> all MMC devices, and check if there is an eMMC device among them. If none
> can be found, we enable SPI0 instead, to allow Linux access to the SPI
> flash.

> Since this fixup is not really universally applicable to all boards,
> let's hide it behind a Kconfig option, and enable it only on the one
> supported board where this makes sense: the Pine H64.
>
> Please note that the SPI functionality is still disabled in U-Boot
> proper, the pinmux clash affects us too: it would always disable the eMMC
> and so spoil this algorithm here.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/mach-sunxi/Kconfig | 10 
>  board/sunxi/board.c | 50 +
>  configs/pine_h64_defconfig  |  1 +
>  3 files changed, 61 insertions(+)
>
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 56ff1e197c..ce66453029 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -1047,6 +1047,16 @@ config BLUETOOTH_DT_DEVICE_FIXUP
>   The used address is "bdaddr" if set, and "ethaddr" with the LSB
>   flipped elsewise.
>
> +config SUNXI_H6_ENABLE_SPIFLASH
> +   bool "Enable H6 SPI flash vs. eMMC enablement"
> +   depends on MACH_SUN50I_H6
> +   default n
> +   help
> + Enable this option if you want U-Boot check for an eMMC device
> + on Allwinner H6 boards, and enable the SPI flash if none is found.
> + SPI0 and MMC2 share one pin, so cannot coexist in Linux. The
> + DT prefers eMMC, but if none is used, we can safely enable SPI.

Why we need a separate macro, cannot we check it H6 globally as it SoC design?

Jagan.

Re: [PATCH 1/1] drivers: octeon: get rid of Unicode in code


On 1/16/22 23:11, Heinrich Schuchardt wrote:

Placing Unicode control codes  in the middle of a comment
does not make much sense. Let's get rid of all Unicode in
drivers/ram/octeon/octeon3_lmc.c.

Signed-off-by: Heinrich Schuchardt 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  drivers/ram/octeon/octeon3_lmc.c | 34 
  1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/ram/octeon/octeon3_lmc.c b/drivers/ram/octeon/octeon3_lmc.c
index 349abc179f..eaef0fa5c1 100644
--- a/drivers/ram/octeon/octeon3_lmc.c
+++ b/drivers/ram/octeon/octeon3_lmc.c
@@ -2050,7 +2050,7 @@ static int compute_vref_val(struct ddr_priv *priv, int 
if_num, int rankx,
lmc_control.u64 = lmc_rd(priv, CVMX_LMCX_CONTROL(if_num));
  
  		/*

-*  New computed vref = existing computed vref – X
+*  New computed vref = existing computed vref - X
 *
 * The value of X is depending on different conditions.
 * Both #122 and #139 are 2Rx4 RDIMM, while #124 is stacked
@@ -2058,7 +2058,7 @@ static int compute_vref_val(struct ddr_priv *priv, int 
if_num, int rankx,
 *
 * 1. Stacked Die: 2Rx4
 * 1-slot: offset = 7. i, e New computed vref = existing
-* computed vref – 7
+* computed vref - 7
 * 2-slot: offset = 6
 *
 * 2. Regular: 2Rx4
@@ -9941,11 +9941,11 @@ static int test_dram_byte_hw(struct ddr_priv *priv, int 
if_num, u64 p,
 * NOTE: this step done in the calling routine(s)...
 * 3) Setup GENERAL_PURPOSE[0-2] registers with the data pattern
 * of choice.
-* a. GENERAL_PURPOSE0[DATA<63:0>] – sets the initial lower
+* a. GENERAL_PURPOSE0[DATA<63:0>] - sets the initial lower
 * (rising edge) 64 bits of data.
-* b. GENERAL_PURPOSE1[DATA<63:0>] – sets the initial upper
+* b. GENERAL_PURPOSE1[DATA<63:0>] - sets the initial upper
 * (falling edge) 64 bits of data.
-* c. GENERAL_PURPOSE2[DATA<15:0>] – sets the initial lower
+* c. GENERAL_PURPOSE2[DATA<15:0>] - sets the initial lower
 * (rising edge <7:0>) and upper (falling edge <15:8>) ECC data.
 */
  
@@ -9980,8 +9980,8 @@ static int test_dram_byte_hw(struct ddr_priv *priv, int if_num, u64 p,
  
  	/*

 * 7) Set PHY_CTL[PHY_RESET] = 1 (LMC automatically clears this as
-* it’s a one-shot operation). This is to get into the habit of
-* resetting PHY’s SILO to the original 0 location.
+* it's a one-shot operation). This is to get into the habit of
+* resetting PHY's SILO to the original 0 location.
 */
phy_ctl.u64 = lmc_rd(priv, CVMX_LMCX_PHY_CTL(if_num));
phy_ctl.s.phy_reset = 1;
@@ -10013,9 +10013,9 @@ static int test_dram_byte_hw(struct ddr_priv *priv, int 
if_num, u64 p,
 * a. COL, ROW, BA, BG, PRANK points to the starting point
 * of the address.
 * You can just set them to all 0.
-* b. RW_TRAIN – set this to 1.
-* c. TCCD_L – set this to 0.
-* d. READ_CMD_COUNT – instruct the sequence to the how many
+* b. RW_TRAIN - set this to 1.
+* c. TCCD_L - set this to 0.
+* d. READ_CMD_COUNT - instruct the sequence to the how many
 * writes/reads.
 * It is 5 bits field, so set to 31 of maximum # of r/w.
 */
@@ -10063,9 +10063,9 @@ static int test_dram_byte_hw(struct ddr_priv *priv, int 
if_num, u64 p,
  
  			/*

 * 6) Read MPR_DATA0 and MPR_DATA1 for results.
-* a. MPR_DATA0[MPR_DATA<63:0>] – comparison results
+* a. MPR_DATA0[MPR_DATA<63:0>] - comparison results
 *for DQ63:DQ0. (1 means MATCH, 0 means FAIL).
-* b. MPR_DATA1[MPR_DATA<7:0>] – comparison results
+* b. MPR_DATA1[MPR_DATA<7:0>] - comparison results
 *for ECC bit7:0.
 */
mpr_data0 = lmc_rd(priv, CVMX_LMCX_MPR_DATA0(if_num));
@@ -10073,8 +10073,8 @@ static int test_dram_byte_hw(struct ddr_priv *priv, int 
if_num, u64 p,
  
  			/*

 * 7) Set PHY_CTL[PHY_RESET] = 1 (LMC automatically
-* clears this as it’s a one-shot operation).
-* This is to get into the habit of resetting PHY’s
+* clears this as it's a one-shot operation).
+* This is to get into the habit of resetting PHY's
 * SILO to the original 0 location.
 */
phy_ctl.u64 = lmc_rd(priv, CVMX_LMCX_PHY_CTL(if_num));
@@ -10163,11 +10163,11 @@ static void setup_hw_p

Re: Commit 4f2e2280862a ("RFC: arm: pci: Add PCI cam support to PCI-E ecam driver")

2022-01-20 Thread Pali Rohár

Hello Alistair!

On Wednesday 19 January 2022 14:48:21 Alistair Delva wrote:
> Hi Pali,
> 
> Sorry for the late reply..
> 
> On Thu, Jan 13, 2022 at 4:34 AM Pali Rohár  wrote:
> >
> > Hello!
> >
> > Now I see that you have merged commit 4f2e2280862a ("RFC: arm: pci: Add
> > PCI cam support to PCI-E ecam driver"). It adds some "PCI cam support"
> > with generic DT binding "pci-host-cam-generic".
> >
> > I have tried to find some information about it, but in PCIe
> > specification there is nothing like PCI CAM. And neither in old PCI
> > local bus 2.x or 3.x specs.
> 
> I can't really help you with documentation, but "pci-host-cam-generic"
> isn't something we made up, it is the same name used upstream by
> Linux: 
> https://elixir.bootlin.com/linux/latest/source/drivers/pci/controller/pci-host-generic.c#L60

Ou, I did not know about it.

> We don't have specs, we just reverse engineered what was happening in
> the crosvm vm manager emulation of this device
> (https://chromium.googlesource.com/chromiumos/platform/crosvm/+/refs/heads/master/aarch64/src/fdt.rs).

Hm... And could you in Google contact authors of this code (as it is
hosted in Google too) if they could provide specification for it? It
could really help to understand how it is suppose to do...

> > This access looks like a mix of "PCI Configuration Mechanism #1" and
> > "PCI Configuration Mechanism #2" from PCI Local Bus Specification
> > (rev 2.1, sections 3.7.4.1 and 3.7.4.2) and incompatible with both of
> > them. It has layout similar to Mechanism #1 and access similar to #2.
> >
> > PCI Configuration Mechanism #1 uses two registers, one which select
> > config address and second for accessing config space (selected address).
> > But that U-Boot "PCI CAM" is implemented as memory mapped address space,
> > something similar to PCI Configuration Mechanism #2 but with different
> > layout. Also that "PCI CAM" does not set "enable" bit which is per PCI
> > Configuration Mechanism #1 required to access PCI config space.
> >
> > Recently I converted all PCI drivers in U-Boot which uses PCI
> > Configuration Mechanism #1 to use PCI_CONF1_ADDRESS() macro for
> > accessing PCI config space. Basically every HW which uses PCI
> > Configuration Mechanism #1 requires to set "enable" bit like it is
> > described in PCI local bus spec. There is only one exception pci_msc01.c
> > which requires to have "enable" bit unset. And I'm not sure if this is
> > not rather bug in U-Boot driver (but it is in U-Boot in this state for a
> > long time).
> >
> > Do you have some references to this "PCI CAM" specification? Because for
> > me it looks like some vendor/proprietary undocumented API and
> > incompatible with everything which I saw.
> >
> > Therefore I would suggest to not call it "pci-host-cam-generic" or
> > TYPE_PCI as it is not generic for sure (like PCIe ECAM which is
> > documented in PCIe base spec) and also because it is not PCI type (does
> > not match neither PCI Mechanism #1 nor Mechanism #2).
> >
> > Anyway, I would like to know, which hardware uses this unusual PCI
> > config space access?
> 
> I don't know what real hardware uses it, but it is used by crosvm
> (https://chromium.googlesource.com/chromiumos/platform/crosvm)

I did not know about crosvm project. But seems that this is really used,
but just only in emulated hardware?

> > Btw, that commit probably does not work. It uses construction:
> >
> >   (PCI_FUNC(bdf) << 8) | offset
> >
> > offset passed by U-Boot is number between 0..4095 and therefore it
> > overlaps with PCI function number. Either shift by 8 is wrong and it
> > should be shift by 12 or offset needs to be limited just to 0..255. But
> > then there would be no access to PCIe extended space (256..4095), only
> > PCI and I doubt that somebody in 2022 is still doing new development for
> > Conventional PCI local bus hardware.
> 
> I think that's the case for this device, unfortunately. Perhaps we
> should cap offset between 0..255.
> 
> Our change does work; without it, U-Boot can't see any PCI devices.
> With it, they are all shown.

Well, in that commit is overlapping offset and function. So accessing
offsets above 255 would overwrite also function number and so, register
access goes into different function/device. U-Boot would see PCI device
but content in registers above 255 would be just garbage.

If your (emulated) hw has really function number starting at bit 8, and
not 12 then offset has to be limited just to 0..255. Meaning that for
offsets above 255, u-boot driver has to return fabricated value zeros
for any read attempts (and ignores write attempts).

> The other shifts in the change look the same as the Linux driver which
> adjusts the shift from 20 to 16 here:
> https://elixir.bootlin.com/linux/latest/source/drivers/pci/controller/pci-host-generic.c#L18
> 
> I admit, the added logic looks different though:
> https://elixir.bootlin.com/linux/latest/source/drivers/pci/ecam.c#L187
> 
> > Also in my opinion as this "PCI

Re: Commit 4f2e2280862a ("RFC: arm: pci: Add PCI cam support to PCI-E ecam driver")

2022-01-20 Thread Pali Rohár

Hello Mark!

On Thursday 20 January 2022 00:23:02 Mark Kettenis wrote:
> CAM is just a version of ECAM that only gives you access to the
> classic PCI config space (register offsets < 256).  This has very
> little to do with the classic "mode 1" and "mode 2" config space
> access methods of the x86 PCI host bridges.

Interesting... as I have not found anything about CAM in specs... That
is why I thought it must be some proprietary, vendor-specific or
non-standard access method.

"mode 1" is indirect access method and "mode 2" has mapped config space
into (io) memory space. But this "CAM" is neither "mode 1" nor "mode 2".
That is why it looked suspicious to me.

> I don't think there is a
> CAM standard at all, but some of the PCI host bridges found on PowerPC
> and SPARC hardware implemented a straight mapping of PCI config space
> into mmio space like that.

Interesting... But at least it looks like that U-Boot does not have
support for these kind of hardware.

Anyway, is not that mapping in that old hardware of PCI config space
into mmio space according to "mode 2" layout? I know that both "mode 1"
and "mode 2" are IO-space orientated, but on non-x86 HW there probably
does not have to be IO-space and same layout can be used also for
memory-space mapping.

> It is a little bit strange that crosvm implements CAM instead of ECAM,
> but I guess they don't care about passthrough of arbitrary PCIe
> devices.  And as long as all (emulated) PCIe devices only have
> registers with offsets < 256, this will work just fine.
> 
> And yes, you should check that the register offset is limited to
> 0..255.

Re: [PATCH] mxc_gpio: on imx8m read the DR instead of the PSR

2022-01-20 Thread Angus Ainslie


Hi Fabio,

On 2022-01-18 08:59, Fabio Estevam wrote:

Hi Angus,

On Sun, Nov 28, 2021 at 12:42 PM Angus Ainslie  wrote:


[1]
diff --git a/arch/arm/dts/imx8mq-librem5.dts
b/arch/arm/dts/imx8mq-librem5.dts
index b28420654f..b60a8538af 100644
--- a/arch/arm/dts/imx8mq-librem5.dts
+++ b/arch/arm/dts/imx8mq-librem5.dts
@@ -56,29 +56,29 @@
  &iomuxc {
 pinctrl_hog1: hoggrp1 {


I suspect the hog groups are not getting initialized.

Please try:

&iomuxc {
 pinctrl-names = "default";
 pinctrl-0 = <&pinctrl_hog>;

 pinctrl_hog: hoggrp {
 fsl,pins = <
 ..
>;
};

and then group all the hog pins under the same group.

Then check IOMUXC_SW_MUX_CTL_PAD to make sure the SION bit is set.


I decided to bypass the devicetree to test it on the imx8mq

static const iomux_v3_cfg_t configure_pads[] = {
  IMX8MQ_PAD_GPIO1_IO03__GPIO1_IO3 | MUX_PAD_CTRL(PAD_CTL_DSE6) 
| MUX_MODE_SION,
  IMX8MQ_PAD_GPIO1_IO14__GPIO1_IO14 | MUX_PAD_CTRL(PAD_CTL_DSE6) 
| MUX_MODE_SION,
  IMX8MQ_PAD_ENET_MDC__GPIO1_IO16 | MUX_PAD_CTRL(PAD_CTL_PUE) | 
MUX_MODE_SION,
  IMX8MQ_PAD_ENET_MDIO__GPIO1_IO17 | MUX_PAD_CTRL(PAD_CTL_PUE) | 
MUX_MODE_SION,

};

static inline void init_pinmux(void)
{
imx_iomux_v3_setup_multiple_pads(configure_pads, 
ARRAY_SIZE(configure_pads));

}

And this works so I need to figure out what is wrong with my devicetree 
configuration.


Thanks
Angus

Re: [PATCH] mxc_gpio: on imx8m read the DR instead of the PSR

2022-01-20 Thread Fabio Estevam

Hi Angus,

On Thu, Jan 20, 2022 at 10:56 AM Angus Ainslie  wrote:

> I decided to bypass the devicetree to test it on the imx8mq
>
> static const iomux_v3_cfg_t configure_pads[] = {
>IMX8MQ_PAD_GPIO1_IO03__GPIO1_IO3 | MUX_PAD_CTRL(PAD_CTL_DSE6)
> | MUX_MODE_SION,
>IMX8MQ_PAD_GPIO1_IO14__GPIO1_IO14 | MUX_PAD_CTRL(PAD_CTL_DSE6)
> | MUX_MODE_SION,
>IMX8MQ_PAD_ENET_MDC__GPIO1_IO16 | MUX_PAD_CTRL(PAD_CTL_PUE) |
> MUX_MODE_SION,
>IMX8MQ_PAD_ENET_MDIO__GPIO1_IO17 | MUX_PAD_CTRL(PAD_CTL_PUE) |
> MUX_MODE_SION,
> };
>
> static inline void init_pinmux(void)
> {
>  imx_iomux_v3_setup_multiple_pads(configure_pads,
> ARRAY_SIZE(configure_pads));
> }
>
> And this works so I need to figure out what is wrong with my devicetree
> configuration.

Ok, great :-)

The issue with your dts is that the hog pinctrl group is not
referenced anywhere.

The example I sent in my last email should fix the problem:

 pinctrl-names = "default";
 pinctrl-0 = <&pinctrl_hog>;

Re: [PATCH v3] drivers: spi-nor: Add JEDEC id for W25Q16JV

2022-01-20 Thread Angus Ainslie


Hi Jagan,

On 2022-01-20 04:55, Jagan Teki wrote:

On Mon, Jan 17, 2022 at 7:27 PM Angus Ainslie  wrote:


Add a JEDEC id for the Winbond W25Q16JV 16M-BIT serial flash memory 
with

DUAL/QUAD SPI

Changes since v2:

Chagned the name to follow "DTR" parts

Changes since v1:

Updated the name for more suffixes

Signed-off-by: Angus Ainslie 
---
 drivers/mtd/spi/spi-nor-ids.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c 
b/drivers/mtd/spi/spi-nor-ids.c

index b551ebd75e..08e386fbf5 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -314,6 +314,11 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | SPI_NOR_DUAL_READ | 
SPI_NOR_QUAD_READ |

SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
},
+   {
+   INFO("w25q16jvm", 0xef7015, 0, 64 * 1024,  32,


Can this name as "w25q16jv-im/jm" ?



I sent a v2 with that name and there was one comment to change it to 
this name.


If you prefer please use v2 instead.

https://lists.denx.de/pipermail/u-boot/2022-January/471874.html

Thanks
Angus


Jagan.

Re: [PATCH 7/7] sunxi: H6: Enable SPI0 in DT when no eMMC is used

On Thu, 20 Jan 2022 19:08:57 +0530
Jagan Teki  wrote:

Hi,

> On Tue, Jan 11, 2022 at 6:16 PM Andre Przywara  wrote:
> >
> > On the Allwinner H6 SoC both the SPI0 and the eMMC device share one pin,
> > so cannot be used simultaneously. On Linux this is a showstopper, since
> > only one of them would be able to claim the pin, and the probe order is
> > somewhat random. The DT consequently disables SPI0 in favour of the more
> > useful eMMC.
> >
> > But a comment in the DT actually suggests that this could be reversed by
> > U-Boot, if no eMMC is actually connected. Let's now implement this:
> > When we fix up the device tree before booting a kernel, we iterate over
> > all MMC devices, and check if there is an eMMC device among them. If none
> > can be found, we enable SPI0 instead, to allow Linux access to the SPI
> > flash.  
> 
> > Since this fixup is not really universally applicable to all boards,
> > let's hide it behind a Kconfig option, and enable it only on the one
> > supported board where this makes sense: the Pine H64.
> >
> > Please note that the SPI functionality is still disabled in U-Boot
> > proper, the pinmux clash affects us too: it would always disable the eMMC
> > and so spoil this algorithm here.
> >
> > Signed-off-by: Andre Przywara 
> > ---
> >  arch/arm/mach-sunxi/Kconfig | 10 
> >  board/sunxi/board.c | 50 +
> >  configs/pine_h64_defconfig  |  1 +
> >  3 files changed, 61 insertions(+)
> >
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index 56ff1e197c..ce66453029 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -1047,6 +1047,16 @@ config BLUETOOTH_DT_DEVICE_FIXUP
> >   The used address is "bdaddr" if set, and "ethaddr" with the LSB
> >   flipped elsewise.
> >
> > +config SUNXI_H6_ENABLE_SPIFLASH
> > +   bool "Enable H6 SPI flash vs. eMMC enablement"
> > +   depends on MACH_SUN50I_H6
> > +   default n
> > +   help
> > + Enable this option if you want U-Boot check for an eMMC device
> > + on Allwinner H6 boards, and enable the SPI flash if none is found.
> > + SPI0 and MMC2 share one pin, so cannot coexist in Linux. The
> > + DT prefers eMMC, but if none is used, we can safely enable SPI.  
> 
> Why we need a separate macro, cannot we check it H6 globally as it SoC design?

This "hack" is board dependent. We don't know if there is a SPI flash or
eMMC in the first place, and this whole concept is weird enough that it
warrants a separate config option.
Probably due to this hardware issue the PineH64 is actually the only board
in mainline that has both SPI flash and eMMC, and I don't want to enable
SPI flash on every eMMC less board. Also it simplifies the code if we can
assume that both DT nodes exist, when that config is enabled.

Cheers,
Andre

P.S. Actually I wanted to forgot to mark this one as RFC, as I am not sure
that it's justified. The comment in the mainline DT suggests this
solution, and I was curious what it would take to make it work, as
apparently some people are interested in it.

Re: [PATCH 7/7] sunxi: H6: Enable SPI0 in DT when no eMMC is used

On Thu, Jan 20, 2022 at 7:36 PM Andre Przywara  wrote:
>
> On Thu, 20 Jan 2022 19:08:57 +0530
> Jagan Teki  wrote:
>
> Hi,
>
> > On Tue, Jan 11, 2022 at 6:16 PM Andre Przywara  
> > wrote:
> > >
> > > On the Allwinner H6 SoC both the SPI0 and the eMMC device share one pin,
> > > so cannot be used simultaneously. On Linux this is a showstopper, since
> > > only one of them would be able to claim the pin, and the probe order is
> > > somewhat random. The DT consequently disables SPI0 in favour of the more
> > > useful eMMC.
> > >
> > > But a comment in the DT actually suggests that this could be reversed by
> > > U-Boot, if no eMMC is actually connected. Let's now implement this:
> > > When we fix up the device tree before booting a kernel, we iterate over
> > > all MMC devices, and check if there is an eMMC device among them. If none
> > > can be found, we enable SPI0 instead, to allow Linux access to the SPI
> > > flash.
> >
> > > Since this fixup is not really universally applicable to all boards,
> > > let's hide it behind a Kconfig option, and enable it only on the one
> > > supported board where this makes sense: the Pine H64.
> > >
> > > Please note that the SPI functionality is still disabled in U-Boot
> > > proper, the pinmux clash affects us too: it would always disable the eMMC
> > > and so spoil this algorithm here.
> > >
> > > Signed-off-by: Andre Przywara 
> > > ---
> > >  arch/arm/mach-sunxi/Kconfig | 10 
> > >  board/sunxi/board.c | 50 +
> > >  configs/pine_h64_defconfig  |  1 +
> > >  3 files changed, 61 insertions(+)
> > >
> > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > > index 56ff1e197c..ce66453029 100644
> > > --- a/arch/arm/mach-sunxi/Kconfig
> > > +++ b/arch/arm/mach-sunxi/Kconfig
> > > @@ -1047,6 +1047,16 @@ config BLUETOOTH_DT_DEVICE_FIXUP
> > >   The used address is "bdaddr" if set, and "ethaddr" with the LSB
> > >   flipped elsewise.
> > >
> > > +config SUNXI_H6_ENABLE_SPIFLASH
> > > +   bool "Enable H6 SPI flash vs. eMMC enablement"
> > > +   depends on MACH_SUN50I_H6
> > > +   default n
> > > +   help
> > > + Enable this option if you want U-Boot check for an eMMC device
> > > + on Allwinner H6 boards, and enable the SPI flash if none is 
> > > found.
> > > + SPI0 and MMC2 share one pin, so cannot coexist in Linux. The
> > > + DT prefers eMMC, but if none is used, we can safely enable SPI.
> >
> > Why we need a separate macro, cannot we check it H6 globally as it SoC 
> > design?
>
> This "hack" is board dependent. We don't know if there is a SPI flash or
> eMMC in the first place, and this whole concept is weird enough that it
> warrants a separate config option.
> Probably due to this hardware issue the PineH64 is actually the only board
> in mainline that has both SPI flash and eMMC, and I don't want to enable
> SPI flash on every eMMC less board. Also it simplifies the code if we can
> assume that both DT nodes exist, when that config is enabled.
>
> Cheers,
> Andre
>
> P.S. Actually I wanted to forgot to mark this one as RFC, as I am not sure
> that it's justified. The comment in the mainline DT suggests this
> solution, and I was curious what it would take to make it work, as
> apparently some people are interested in it.

If it board-specific, better switch to RFC or load the overlay by
checking on board specific boot script.

Thanks,
Jagan.

Re: [PATCH v3] drivers: spi-nor: Add JEDEC id for W25Q16JV

On Thu, Jan 20, 2022 at 7:53 PM  wrote:
>
> On 1/20/22 3:20 PM, Michael Walle wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
> > content is safe
> >
> >>> +   {
> >>> +   INFO("w25q16jvm", 0xef7015, 0, 64 * 1024,  32,
> >>
> >> Can this name as "w25q16jv-im/jm" ?
> >
> > FWIW, "w25q15jvm" would be the "correct" name in linux. Although for this
> > particular flash the name in linux is "w25q16jv-im/jm"..
>
> would you fix it? :D
>
> >
> > Anyhow, see [1] for a lengthy discussion on that name. That being said, I
> > still don't share Tudors opinion on using that made up name, just because
> > no one will find any flash if one searches for w25q16jvm in the internet.
>
> The temperature range "I/J" is skipped in the name because it does not have
> any influence on the jedec-id. That's why we don't include the "Package Type"
> field in the naming convention as well.

Okay, I'm merging v3. let me know if you have any questions?

Thanks,
Jagan.

Re: [PATCH v9 03/11] tools: build mkeficapsule with tools-only_defconfig

On Thu, Jan 20, 2022 at 10:39:03AM +0900, AKASHI Takahiro wrote:
> Heinrich,
> 
> On Wed, Jan 19, 2022 at 05:08:14PM +0100, Heinrich Schuchardt wrote:
> > On 1/18/22 05:39, AKASHI Takahiro wrote:
> > > Add CONFIG_TOOLS_MKEFICAPSULE. Then we want to always build mkeficapsule
> > > if tools-only_defconfig is used.
> > > 
> > > Signed-off-by: AKASHI Takahiro 
> > > Reviewed-by: Simon Glass 
> > > ---
> > >   configs/tools-only_defconfig | 1 +
> > >   tools/Kconfig| 8 
> > >   tools/Makefile   | 3 +--
> > >   3 files changed, 10 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/configs/tools-only_defconfig b/configs/tools-only_defconfig
> > > index f482c9a1c1b0..5427797dd4c3 100644
> > > --- a/configs/tools-only_defconfig
> > > +++ b/configs/tools-only_defconfig
> > > @@ -31,3 +31,4 @@ CONFIG_I2C_EDID=y
> > >   # CONFIG_VIRTIO_MMIO is not set
> > >   # CONFIG_VIRTIO_PCI is not set
> > >   # CONFIG_VIRTIO_SANDBOX is not set
> > > +CONFIG_TOOLS_MKEFICAPSULE=y
> > > diff --git a/tools/Kconfig b/tools/Kconfig
> > > index 91ce8ae3e516..117c921da3fe 100644
> > > --- a/tools/Kconfig
> > > +++ b/tools/Kconfig
> > > @@ -90,4 +90,12 @@ config TOOLS_SHA512
> > >   help
> > > Enable SHA512 support in the tools builds
> > > 
> > > +config TOOLS_MKEFICAPSULE
> > > + bool "Build efimkcapsule command"
> > > + default y if EFI_CAPSULE_ON_DISK
> > 
> > We discussed this with Tom before. Building of tools should not depend
> > on board options. Can we make this 'default y'?
> 
> No.
> I think we have different opinions here.
> 
> I think that any of *board* configs should build only all the binaries
> that are need to run U-Boot on that board.
> For distros' case that you have mentioned before, we should
> encourage them to use tools-only_defconfig for packaging U-Boot
> host tools rather than using any particular *board* config.
> 
> # In either case, the resulting binary, as far as mkeficapsule is
> concerned, is the exact same without any dependency of target configs.

For "mkimage" we go very very far in the direction of "this tool needs
to be the same for all boards" because so many times not doing so has
come back to be a problem for users and developers and distros.

This is adding a new tool, yes?  We have many examples of only building
a tool given a CONFIG option, and so long as the tool itself doesn't
change based on CONFIG options, that's fine.  tools-only_defconfig needs
to enable this, and is enabling this.

-- 
Tom


signature.asc
Description: PGP signature

[RFC PATCH 00/14] FWU: Add FWU Multi Bank Update for DeveloerBox

Hi,

Here is an RFC series of patches for the FWU Multi Bank Update
support for the DeveloperBox platform. This series depends on
Sughosh's Multi Bank Update v3 [1]. Thus if that is updated,
this must be rebased and updated too.

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=281875

This series includes my previous DFU updates[2] as [01/14]-[05/14],
which is still under review in the U-Boot ML. For "nicely" indent
the dfu_alt_info lines, I need that series. :-)

[2] https://patchwork.ozlabs.org/project/uboot/list/?series=275293

I also added some patches which updates Sughosh's series as [06/14]
- [08/14]. Thus the [09/14] - [14/14] are the changes for DeveloperBox.

Unlike the STM32MP board, DeveloperBox (SynQuacer) loads the firmware
from SPI NOR flash. Thus it doesn't use GPT partitions to store the
firmware banks and the FWU metadata. Instead, it stores those data
at fixed address areas on SPI NOR flash. I carefully chose the areas
which doesn't overlap the previous firmware and EDK2.

I introduced fwu_metadata_sf.c driver for this FWU multi bank support
on SPI flash, which does not use GPT too.

Since there is no GPT, the location GUID for images and the image
GUID for banks are Null GUID. Anyway, for managing firmware image
banks, we only need the ImageType GUID.

And the SynQuacer also does not have any non-volatile register.
Thus this allocates the platform defined boot index on the SPI flash
too.

So, in summary, on the DeveloperBox, this FWU Multi Bank update is
only for avoidance of unexpected bricking by firmware update. If there
are multiple banks, when the user (or firmware developer) update it
with a wrong image, they can revert the wrong one. Even if it does
not boot, SCP firmware can detect it and roll back to the previous
bank. But please note that this is not "security" enhancement at all
at least on the DeveloperBox because all images are still on normal
SPI NOR flash. This is rather like a "safety" feature like a fool proof.

NOTE: To use this series, you also need to update SCP firmware[3] and
TF-A[4] on the DeveloperBox. Those are under cleaning up.

[3] https://git.linaro.org/people/masami.hiramatsu/SCP-firmware.git/
[4] https://git.linaro.org/people/masami.hiramatsu/arm-trusted-firmware.git/

Thank you,

---

Masami Hiramatsu (14):
  DFU: Do not copy the entity name over the buffer size
  DFU: Accept redundant spaces and tabs in dfu_alt_info
  DFU: Check the number of arguments and argument string strictly
  doc: usage: DFU: Fix dfu_alt_info document
  cmd/dfu: Enable 'dfu list' command without DFU_OVER_USB
  FWU: Calculate CRC32 in gpt_update_mdata()
  FWU: Free metadata copy if gpt_get_mdata() failed
  FWU: Move FWU metadata operation code in fwu_mdata.c
  synquacer: Update for TBBR based new FIP layout
  FWU: Reboot soon after successfully install the new firmware
  FWU: Add FWU Multi Bank Update on SPI Flash
  FWU: synquacer: Add FWU Multi bank update support for DeveloperBox
  FWU: synquacer: Initialize broken metadata
  configs: synquacer: Add FWU support for DeveloperBox


 .../dts/synquacer-sc2a11-developerbox-u-boot.dtsi  |   26 +-
 board/socionext/developerbox/Kconfig   |   31 +++
 board/socionext/developerbox/Makefile  |1 
 board/socionext/developerbox/fwu_plat.c|  217 ++
 cmd/dfu.c  |6 
 configs/synquacer_developerbox_defconfig   |   12 +
 doc/usage/dfu.rst  |   45 +++-
 drivers/dfu/dfu.c  |   37 ++-
 drivers/dfu/dfu_mmc.c  |   55 +++--
 drivers/dfu/dfu_mtd.c  |   34 ++-
 drivers/dfu/dfu_nand.c |   34 ++-
 drivers/dfu/dfu_ram.c  |   24 +-
 drivers/dfu/dfu_sf.c   |   34 ++-
 drivers/dfu/dfu_virt.c |5 
 include/configs/synquacer.h|   14 +
 include/dfu.h  |   33 ++-
 include/efi_loader.h   |3 
 include/fwu.h  |   22 +-
 lib/efi_loader/efi_capsule.c   |   10 +
 lib/efi_loader/efi_firmware.c  |   14 +
 lib/fwu_updates/Kconfig|   43 
 lib/fwu_updates/Makefile   |5 
 lib/fwu_updates/fwu_mdata.c|  123 ++
 lib/fwu_updates/fwu_mdata_gpt_blk.c|  109 +
 lib/fwu_updates/fwu_mdata_sf.c |  241 
 25 files changed, 888 insertions(+), 290 deletions(-)
 create mode 100644 board/socionext/developerbox/fwu_plat.c
 create mode 100644 lib/fwu_updates/fwu_mdata_sf.c

--
Masami Hiramatsu

[RFC PATCH 01/14] DFU: Do not copy the entity name over the buffer size

Use strlcpy() instead of strcpy() to prevent copying the
entity name over the name buffer size.

Signed-off-by: Masami Hiramatsu 
---
 drivers/dfu/dfu.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index af3975925a..66c41b5e76 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -503,7 +503,7 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char *s, 
int alt,
 
debug("%s: %s interface: %s dev: %s\n", __func__, s, interface, devstr);
st = strsep(&s, " ");
-   strcpy(dfu->name, st);
+   strlcpy(dfu->name, st, DFU_NAME_SIZE);
 
dfu->alt = alt;
dfu->max_buf_size = 0;

[RFC PATCH 02/14] DFU: Accept redundant spaces and tabs in dfu_alt_info

If dfu_alt_info has repeated spaces or tab (for indentation or
readability), the dfu fails to parse it. For example, if
dfu_alt_info="mtd nor1=image raw  10 20" (double spaces
after "raw"), the image entity start address is '0' and the size
'0x10'. This is because the repeated space is not skipped.

Use space and tab as a separater and apply skip_spaces() to
skip redundant spaces and tabs.

Signed-off-by: Masami Hiramatsu 
---
 drivers/dfu/dfu.c  |6 --
 drivers/dfu/dfu_mmc.c  |   11 ---
 drivers/dfu/dfu_mtd.c  |8 ++--
 drivers/dfu/dfu_nand.c |   11 ---
 drivers/dfu/dfu_ram.c  |3 ++-
 drivers/dfu/dfu_sf.c   |   12 +---
 6 files changed, 37 insertions(+), 14 deletions(-)

diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 66c41b5e76..18154774f9 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -123,9 +123,10 @@ int dfu_config_interfaces(char *env)
s = env;
while (s) {
ret = -EINVAL;
-   i = strsep(&s, " ");
+   i = strsep(&s, " \t");
if (!i)
break;
+   s = skip_spaces(s);
d = strsep(&s, "=");
if (!d)
break;
@@ -502,8 +503,9 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char *s, 
int alt,
char *st;
 
debug("%s: %s interface: %s dev: %s\n", __func__, s, interface, devstr);
-   st = strsep(&s, " ");
+   st = strsep(&s, " \t");
strlcpy(dfu->name, st, DFU_NAME_SIZE);
+   s = skip_spaces(s);
 
dfu->alt = alt;
dfu->max_buf_size = 0;
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 3dab5a5f63..d747ede66c 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -351,11 +351,12 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu, char 
*devstr, char *s)
dfu->data.mmc.dev_num = dectoul(devstr, NULL);
 
for (; parg < argv + sizeof(argv) / sizeof(*argv); ++parg) {
-   *parg = strsep(&s, " ");
+   *parg = strsep(&s, " \t");
if (*parg == NULL) {
pr_err("Invalid number of arguments.\n");
return -ENODEV;
}
+   s = skip_spaces(s);
}
 
entity_type = argv[0];
@@ -390,9 +391,11 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu, char 
*devstr, char *s)
 * specifying the mmc HW defined partition number
 */
if (s)
-   if (!strcmp(strsep(&s, " "), "mmcpart"))
+   if (!strcmp(strsep(&s, " \t"), "mmcpart")) {
+   s = skip_spaces(s);
dfu->data.mmc.hw_partition =
simple_strtoul(s, NULL, 0);
+   }
 
} else if (!strcmp(entity_type, "part")) {
struct disk_partition partinfo;
@@ -412,8 +415,10 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu, char 
*devstr, char *s)
 * specifying the mmc HW defined partition number
 */
if (s)
-   if (!strcmp(strsep(&s, " "), "offset"))
+   if (!strcmp(strsep(&s, " \t"), "offset")) {
+   s = skip_spaces(s);
offset = simple_strtoul(s, NULL, 0);
+   }
 
dfu->layout = DFU_RAW_ADDR;
dfu->data.mmc.lba_start = partinfo.start + offset;
diff --git a/drivers/dfu/dfu_mtd.c b/drivers/dfu/dfu_mtd.c
index 0b7f17761f..ee534a9d10 100644
--- a/drivers/dfu/dfu_mtd.c
+++ b/drivers/dfu/dfu_mtd.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static bool mtd_is_aligned_with_block_size(struct mtd_info *mtd, u64 size)
 {
@@ -265,11 +266,14 @@ int dfu_fill_entity_mtd(struct dfu_entity *dfu, char 
*devstr, char *s)
dfu->data.mtd.info = mtd;
dfu->max_buf_size = mtd->erasesize;
 
-   st = strsep(&s, " ");
+   st = strsep(&s, " \t");
+   s = skip_spaces(s);
if (!strcmp(st, "raw")) {
dfu->layout = DFU_RAW_ADDR;
dfu->data.mtd.start = hextoul(s, &s);
-   s++;
+   if (!isspace(*s))
+   return -1;
+   s = skip_spaces(s);
dfu->data.mtd.size = hextoul(s, &s);
} else if ((!strcmp(st, "part")) || (!strcmp(st, "partubi"))) {
char mtd_id[32];
diff --git a/drivers/dfu/dfu_nand.c b/drivers/dfu/dfu_nand.c
index e53b35e42b..76761939ab 100644
--- a/drivers/dfu/dfu_nand.c
+++ b/drivers/dfu/dfu_nand.c
@@ -201,11 +201,14 @@ int dfu_fill_entity_nand(struct dfu_entity *dfu, char 
*devstr, char *s)
 
dfu->data.nand.ubi = 0;
dfu->dev_type = DFU_DEV_NAND;
-   st = strsep(&s, " ");
+   st = strsep(&s, " \t");
+   s = skip_spaces(s);

[RFC PATCH 03/14] DFU: Check the number of arguments and argument string strictly

When parsing the dfu_alt_info, check the number of arguments
and argument string strictly. If there is any garbage data
(which is not able to be parsed correctly) in dfu_alt_info,
that means something wrong and user may make a typo or mis-
understanding about the syntax. Since the dfu_alt_info is
used for updating the firmware, this mistake may lead to
brick the hardware.
Thus it should be checked strictly for making sure there
is no mistake.

Signed-off-by: Masami Hiramatsu 
---
 drivers/dfu/dfu.c  |   31 +--
 drivers/dfu/dfu_mmc.c  |   56 ++--
 drivers/dfu/dfu_mtd.c  |   36 +++
 drivers/dfu/dfu_nand.c |   39 ++---
 drivers/dfu/dfu_ram.c  |   25 ++---
 drivers/dfu/dfu_sf.c   |   38 +
 drivers/dfu/dfu_virt.c |5 +++-
 include/dfu.h  |   33 ++--
 8 files changed, 154 insertions(+), 109 deletions(-)

diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 18154774f9..516dda6179 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -500,12 +500,29 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size, 
int blk_seq_num)
 static int dfu_fill_entity(struct dfu_entity *dfu, char *s, int alt,
   char *interface, char *devstr)
 {
+   char *argv[DFU_MAX_ENTITY_ARGS];
+   int argc;
char *st;
 
debug("%s: %s interface: %s dev: %s\n", __func__, s, interface, devstr);
st = strsep(&s, " \t");
strlcpy(dfu->name, st, DFU_NAME_SIZE);
-   s = skip_spaces(s);
+
+   /* Parse arguments */
+   for (argc = 0; s && argc < DFU_MAX_ENTITY_ARGS; argc++) {
+   s = skip_spaces(s);
+   if (!*s)
+   break;
+   argv[argc] = strsep(&s, " \t");
+   }
+
+   if (argc == DFU_MAX_ENTITY_ARGS && s) {
+   s = skip_spaces(s);
+   if (*s) {
+   log_err("Too many arguments for %s\n", dfu->name);
+   return -EINVAL;
+   }
+   }
 
dfu->alt = alt;
dfu->max_buf_size = 0;
@@ -513,22 +530,22 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char 
*s, int alt,
 
/* Specific for mmc device */
if (strcmp(interface, "mmc") == 0) {
-   if (dfu_fill_entity_mmc(dfu, devstr, s))
+   if (dfu_fill_entity_mmc(dfu, devstr, argv, argc))
return -1;
} else if (strcmp(interface, "mtd") == 0) {
-   if (dfu_fill_entity_mtd(dfu, devstr, s))
+   if (dfu_fill_entity_mtd(dfu, devstr, argv, argc))
return -1;
} else if (strcmp(interface, "nand") == 0) {
-   if (dfu_fill_entity_nand(dfu, devstr, s))
+   if (dfu_fill_entity_nand(dfu, devstr, argv, argc))
return -1;
} else if (strcmp(interface, "ram") == 0) {
-   if (dfu_fill_entity_ram(dfu, devstr, s))
+   if (dfu_fill_entity_ram(dfu, devstr, argv, argc))
return -1;
} else if (strcmp(interface, "sf") == 0) {
-   if (dfu_fill_entity_sf(dfu, devstr, s))
+   if (dfu_fill_entity_sf(dfu, devstr, argv, argc))
return -1;
} else if (strcmp(interface, "virt") == 0) {
-   if (dfu_fill_entity_virt(dfu, devstr, s))
+   if (dfu_fill_entity_virt(dfu, devstr, argv, argc))
return -1;
} else {
printf("%s: Device %s not (yet) supported!\n",
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index d747ede66c..a91da972d4 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -337,35 +337,34 @@ void dfu_free_entity_mmc(struct dfu_entity *dfu)
  * 4th (optional):
  * mmcpart  (access to HW eMMC partitions)
  */
-int dfu_fill_entity_mmc(struct dfu_entity *dfu, char *devstr, char *s)
+int dfu_fill_entity_mmc(struct dfu_entity *dfu, char *devstr, char **argv, int 
argc)
 {
const char *entity_type;
ssize_t second_arg;
size_t third_arg;
-
struct mmc *mmc;
+   char *s;
 
-   const char *argv[3];
-   const char **parg = argv;
-
-   dfu->data.mmc.dev_num = dectoul(devstr, NULL);
-
-   for (; parg < argv + sizeof(argv) / sizeof(*argv); ++parg) {
-   *parg = strsep(&s, " \t");
-   if (*parg == NULL) {
-   pr_err("Invalid number of arguments.\n");
-   return -ENODEV;
-   }
-   s = skip_spaces(s);
+   if (argc < 3) {
+   pr_err("The number of parameters are not enough.\n");
+   return -EINVAL;
}
 
+   dfu->data.mmc.dev_num = dectoul(devstr, &s);
+   if (*s)
+   return -EINVAL;
+
entity_type = argv[0];
/*

[RFC PATCH 04/14] doc: usage: DFU: Fix dfu_alt_info document

Fix some typo and wrong information about dfu_alt_info.

Signed-off-by: Masami Hiramatsu 
---
 doc/usage/dfu.rst |   45 +
 1 file changed, 33 insertions(+), 12 deletions(-)

diff --git a/doc/usage/dfu.rst b/doc/usage/dfu.rst
index 11c88072b8..25517637ae 100644
--- a/doc/usage/dfu.rst
+++ b/doc/usage/dfu.rst
@@ -113,9 +113,9 @@ mmc
 each element in *dfu_alt_info* being
 
 *  raw   [mmcpart ]   raw access to mmc device
-*  part   [mmcpart ]  raw access to partition
-*  fat   [mmcpart ]   file in FAT partition
-*  ext4   [mmcpart ]  file in EXT4 partition
+*  part   [offset ]  raw access to partition
+*  fat file in FAT partition
+*  ext4file in EXT4 partition
 *  skip 0 0  ignore flashed data
 *  script 0 0execute commands in shell
 
@@ -169,14 +169,20 @@ nand
 
 each element in *dfu_alt_info* being either of
 
-*  raw raw access to mmc device
-*  partraw acces to partition
-*  partubiraw acces to ubi partition
+*  raw  raw access to nand device
+*  part   raw access to partition
+*  partubiraw access to ubi partition
 
 with
 
+offset
+is the offset in the nand device (hexadecimal without "0x")
+size
+is the size of the access area (hexadecimal without "0x")
+devid
+is the NAND device index (decimal only)
 partid
-is the MTD partition index
+is the NAND partition index (decimal only)
 
 ram
 raw access to ram::
@@ -190,6 +196,13 @@ ram
 
ramraw access to ram
 
+with
+
+offset
+is the offset in the ram device (hexadecimal without "0x")
+size
+is the size of the access area (hexadecimal without "0x")
+
 sf
 serial flash : NOR::
 
@@ -203,8 +216,12 @@ sf
 
 with
 
+offset
+is the offset in the mtd device (hexadecimal without "0x")
+size
+is the size of the access area (hexadecimal without "0x")
 partid
-is the MTD partition index
+is the MTD partition index (decimal)
 
 mtd
 all MTD device: NAND, SPI-NOR, SPI-NAND,...::
@@ -219,14 +236,18 @@ mtd
 
 each element in *dfu_alt_info* being either of:
 
-*  raw   forraw access to mtd device
-*  part   for raw acces to partition
-*  partubi   for raw acces to ubi partition
+*  rawfor raw access to mtd device
+*  partfor raw access to partition
+*  partubi for raw access to ubi partition
 
 with
 
+offset
+is the offset in the mtd device (hexadecimal without "0x")
+size
+is the size of the access area (hexadecimal without "0x")
 partid
-is the MTD partition index
+is the MTD partition index (decimal only)
 
 virt
 virtual flash back end for DFU

[RFC PATCH 05/14] cmd/dfu: Enable 'dfu list' command without DFU_OVER_USB

Since dfu is not only used for USB, and some platform only
supports DFU_OVER_TFTP or EFI capsule update, dfu_alt_info
is defined on such platforms too.

For such platform, 'dfu list' command is useful to check
how the current dfu_alt_info setting is parsed.

Signed-off-by: Masami Hiramatsu 
---
 cmd/dfu.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/cmd/dfu.c b/cmd/dfu.c
index 4a288f74c2..208555c888 100644
--- a/cmd/dfu.c
+++ b/cmd/dfu.c
@@ -50,7 +50,6 @@ static int do_dfu(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
if (!strcmp(argv[1], "tftp"))
return update_tftp(value, interface, devstring);
 #endif
-#ifdef CONFIG_DFU_OVER_USB
ret = dfu_init_env_entities(interface, devstring);
if (ret)
goto done;
@@ -65,6 +64,7 @@ static int do_dfu(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
goto done;
}
 
+#ifdef CONFIG_DFU_OVER_USB
int controller_index = simple_strtoul(usb_controller, NULL, 0);
bool retry = false;
do {
@@ -79,9 +79,9 @@ static int do_dfu(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
}
} while (retry);
 
+#endif
 done:
dfu_free_entities();
-#endif
return ret;
 }
 
@@ -100,8 +100,8 @@ U_BOOT_CMD(dfu, CONFIG_SYS_MAXARGS, 1, do_dfu,
 #ifdef CONFIG_DFU_TIMEOUT
"[] - specify inactivity timeout in seconds\n"
 #endif
-   "[list] - list available alt settings\n"
 #endif
+   "[list] - list available alt settings\n"
 #ifdef CONFIG_DFU_OVER_TFTP
 #ifdef CONFIG_DFU_OVER_USB
"dfu "

[RFC PATCH 06/14] FWU: Calculate CRC32 in gpt_update_mdata()

To avoid calculating crc32 in several places, do it in
gpt_update_mdata(). This also ensures the mdata crc32
is always sane.

Signed-off-by: Masami Hiramatsu 
---
 lib/fwu_updates/fwu_mdata.c |   18 --
 lib/fwu_updates/fwu_mdata_gpt_blk.c |   13 -
 2 files changed, 8 insertions(+), 23 deletions(-)

diff --git a/lib/fwu_updates/fwu_mdata.c b/lib/fwu_updates/fwu_mdata.c
index 252fcf50f6..1324771a71 100644
--- a/lib/fwu_updates/fwu_mdata.c
+++ b/lib/fwu_updates/fwu_mdata.c
@@ -92,7 +92,6 @@ int fwu_get_active_index(u32 *active_idx)
 int fwu_update_active_index(u32 active_idx)
 {
int ret;
-   void *buf;
struct fwu_mdata *mdata = NULL;
 
if (active_idx > CONFIG_FWU_NUM_BANKS) {
@@ -113,14 +112,6 @@ int fwu_update_active_index(u32 active_idx)
mdata->previous_active_index = mdata->active_index;
mdata->active_index = active_idx;
 
-   /*
-* Calculate the crc32 for the updated FWU metadata
-* and put the updated value in the FWU metadata crc32
-* field
-*/
-   buf = &mdata->version;
-   mdata->crc32 = crc32(0, buf, sizeof(*mdata) - sizeof(u32));
-
/*
 * Now write this updated FWU metadata to both the
 * FWU metadata partitions
@@ -205,7 +196,6 @@ int fwu_mdata_check(void)
 int fwu_revert_boot_index(void)
 {
int ret;
-   void *buf;
u32 cur_active_index;
struct fwu_mdata *mdata = NULL;
 
@@ -223,14 +213,6 @@ int fwu_revert_boot_index(void)
mdata->active_index = mdata->previous_active_index;
mdata->previous_active_index = cur_active_index;
 
-   /*
-* Calculate the crc32 for the updated FWU metadata
-* and put the updated value in the FWU metadata crc32
-* field
-*/
-   buf = &mdata->version;
-   mdata->crc32 = crc32(0, buf, sizeof(*mdata) - sizeof(u32));
-
/*
 * Now write this updated FWU metadata to both the
 * FWU metadata partitions
diff --git a/lib/fwu_updates/fwu_mdata_gpt_blk.c 
b/lib/fwu_updates/fwu_mdata_gpt_blk.c
index 796b08e76f..0259da37c3 100644
--- a/lib/fwu_updates/fwu_mdata_gpt_blk.c
+++ b/lib/fwu_updates/fwu_mdata_gpt_blk.c
@@ -161,6 +161,14 @@ static int fwu_gpt_update_mdata(struct fwu_mdata *mdata)
return -ENODEV;
}
 
+   /*
+* Calculate the crc32 for the updated FWU metadata
+* and put the updated value in the FWU metadata crc32
+* field
+*/
+   mdata->crc32 = crc32(0, (void *)&mdata->version,
+sizeof(*mdata) - sizeof(u32));
+
/* First write the primary partition*/
ret = gpt_write_mdata_partition(desc, mdata, primary_mpart);
if (ret < 0) {
@@ -457,7 +465,6 @@ int fwu_gpt_get_mdata(struct fwu_mdata **mdata)
 static int fwu_gpt_set_clear_image_accept(efi_guid_t *img_type_id,
  u32 bank, u8 action)
 {
-   void *buf;
int ret, i;
u32 nimages;
struct fwu_mdata *mdata = NULL;
@@ -480,10 +487,6 @@ static int fwu_gpt_set_clear_image_accept(efi_guid_t 
*img_type_id,
else
img_bank_info->accepted = 0;
 
-   buf = &mdata->version;
-   mdata->crc32 = crc32(0, buf, sizeof(*mdata) -
-sizeof(u32));
-
ret = fwu_gpt_update_mdata(mdata);
goto out;
}

[RFC PATCH 07/14] FWU: Free metadata copy if gpt_get_mdata() failed

It is better if a function which returns an error then release
all allocated memory resources. This simplifies the mind model
and less chance to forgot to free memory and double free.

Signed-off-by: Masami Hiramatsu 
---
 lib/fwu_updates/fwu_mdata_gpt_blk.c |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/lib/fwu_updates/fwu_mdata_gpt_blk.c 
b/lib/fwu_updates/fwu_mdata_gpt_blk.c
index 0259da37c3..7f8b8b68fc 100644
--- a/lib/fwu_updates/fwu_mdata_gpt_blk.c
+++ b/lib/fwu_updates/fwu_mdata_gpt_blk.c
@@ -215,7 +215,8 @@ static int gpt_get_mdata(struct fwu_mdata **mdata)
ret = gpt_read_mdata(desc, *mdata, primary_mpart);
if (ret < 0) {
log_err("Failed to read the FWU metadata from the device\n");
-   return -EIO;
+   ret = -EIO;
+   goto out;
}
 
ret = fwu_verify_mdata(*mdata, 1);
@@ -230,7 +231,8 @@ static int gpt_get_mdata(struct fwu_mdata **mdata)
ret = gpt_read_mdata(desc, *mdata, secondary_mpart);
if (ret < 0) {
log_err("Failed to read the FWU metadata from the device\n");
-   return -EIO;
+   ret = -EIO;
+   goto out;
}
 
ret = fwu_verify_mdata(*mdata, 0);
@@ -238,7 +240,10 @@ static int gpt_get_mdata(struct fwu_mdata **mdata)
return 0;
 
/* Both the FWU metadata copies are corrupted. */
-   return -1;
+   ret = -1;
+out:
+   free(*mdata);
+   return ret;
 }
 
 static int gpt_check_mdata_validity(void)

[RFC PATCH 08/14] FWU: Move FWU metadata operation code in fwu_mdata.c

Remove some FWU metadata operations which only access or
modify the metadata itself from fwu_mdata_ops and move
it in fwu_mdata.c.

Signed-off-by: Masami Hiramatsu 
---
 include/fwu.h   |9 ---
 lib/fwu_updates/fwu_mdata.c |  105 ---
 lib/fwu_updates/fwu_mdata_gpt_blk.c |   85 
 3 files changed, 71 insertions(+), 128 deletions(-)

diff --git a/include/fwu.h b/include/fwu.h
index 6c9b64a9f1..7af94988b7 100644
--- a/include/fwu.h
+++ b/include/fwu.h
@@ -14,26 +14,17 @@
 struct fwu_mdata;
 
 /**
- * @get_active_index: get the current active_index value
  * @get_image_alt_num: get the alt number to be used for the image
  * @mdata_check: check the validity of the FWU metadata partitions
- * @set_accept_image: set the accepted bit for the image
- * @clear_accept_image: clear the accepted bit for the image
  * @get_mdata() - Get a FWU metadata copy
  * @update_mdata() - Update the FWU metadata copy
  */
 struct fwu_mdata_ops {
-   int (*get_active_index)(u32 *active_idx);
-
int (*get_image_alt_num)(efi_guid_t image_type_id, u32 update_bank,
 int *alt_num);
 
int (*mdata_check)(void);
 
-   int (*set_accept_image)(efi_guid_t *img_type_id, u32 bank);
-
-   int (*clear_accept_image)(efi_guid_t *img_type_id, u32 bank);
-
int (*get_mdata)(struct fwu_mdata **mdata);
 
int (*update_mdata)(struct fwu_mdata *mdata);
diff --git a/lib/fwu_updates/fwu_mdata.c b/lib/fwu_updates/fwu_mdata.c
index 1324771a71..505f4f3630 100644
--- a/lib/fwu_updates/fwu_mdata.c
+++ b/lib/fwu_updates/fwu_mdata.c
@@ -3,6 +3,7 @@
  * Copyright (c) 2021, Linaro Limited
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -12,6 +13,9 @@
 #include 
 #include 
 
+#define IMAGE_ACCEPT_SET   BIT(0)
+#define IMAGE_ACCEPT_CLEAR BIT(1)
+
 static struct fwu_mdata_ops *get_fwu_mdata_ops(void)
 {
struct fwu_mdata_ops *ops;
@@ -66,18 +70,28 @@ int fwu_verify_mdata(struct fwu_mdata *mdata, bool pri_part)
  */
 int fwu_get_active_index(u32 *active_idx)
 {
-   struct fwu_mdata_ops *ops;
+   int ret;
+   struct fwu_mdata *mdata = NULL;
 
-   ops = get_fwu_mdata_ops();
-   if (!ops)
-   return -EPROTONOSUPPORT;
+   ret = fwu_get_mdata(&mdata);
+   if (ret < 0) {
+   log_err("Unable to get valid FWU metadata\n");
+   return ret;
+   }
 
-   if (!ops->get_active_index) {
-   log_err("get_active_index() method not defined for the 
platform\n");
-   return -ENOSYS;
+   /*
+* Found the FWU metadata partition, now read the active_index
+* value
+*/
+   *active_idx = mdata->active_index;
+   if (*active_idx > CONFIG_FWU_NUM_BANKS - 1) {
+   printf("Active index value read is incorrect\n");
+   ret = -EINVAL;
}
 
-   return ops->get_active_index(active_idx);
+   free(mdata);
+
+   return ret;
 }
 
 /**
@@ -197,12 +211,12 @@ int fwu_revert_boot_index(void)
 {
int ret;
u32 cur_active_index;
-   struct fwu_mdata *mdata = NULL;
+   struct fwu_mdata *mdata;
 
ret = fwu_get_mdata(&mdata);
if (ret < 0) {
log_err("Unable to get valid FWU metadata\n");
-   goto out;
+   return ret;
}
 
/*
@@ -223,6 +237,49 @@ int fwu_revert_boot_index(void)
ret = -EIO;
}
 
+   free(mdata);
+
+   return ret;
+}
+
+static int fwu_set_clear_image_accept(efi_guid_t *img_type_id,
+ u32 bank, u8 action)
+{
+   void *buf;
+   int ret, i;
+   u32 nimages;
+   struct fwu_mdata *mdata = NULL;
+   struct fwu_image_entry *img_entry;
+   struct fwu_image_bank_info *img_bank_info;
+
+   ret = fwu_get_mdata(&mdata);
+   if (ret < 0) {
+   log_err("Unable to get valid FWU metadata\n");
+   return ret;
+   }
+
+   nimages = CONFIG_FWU_NUM_IMAGES_PER_BANK;
+   img_entry = &mdata->img_entry[0];
+   for (i = 0; i < nimages; i++) {
+   if (!guidcmp(&img_entry[i].image_type_uuid, img_type_id)) {
+   img_bank_info = &img_entry[i].img_bank_info[bank];
+   if (action == IMAGE_ACCEPT_SET)
+   img_bank_info->accepted |= FWU_IMAGE_ACCEPTED;
+   else
+   img_bank_info->accepted = 0;
+
+   buf = &mdata->version;
+   mdata->crc32 = crc32(0, buf, sizeof(*mdata) -
+sizeof(u32));
+
+   ret = fwu_update_mdata(mdata);
+   goto out;
+   }
+   }
+
+   /* Image not found */
+   ret = -EINVAL;
+
 out:
free(mdata);
 
@@ -244,18 +301,8 @@ out:
  */
 int fwu_accept_image(efi_gu

[RFC PATCH 09/14] synquacer: Update for TBBR based new FIP layout

This changes SPI NOR flash partition layout for TBBR and
also make the U-Boot as position independent executable
again because BL33 is loaded on the memory.

With enabling TBBR, TF-A BL2 loads all BL3x images from
FIP image, and the U-Boot image is added to the FIP image
as BL33, and loaded to memory when boot instead of XIP
on SPI NOR flash. To avoid mixing up with the legacy images,
this new FIP image is stored on unused area (0x60-) and
the U-Boot env vars are also stored at 0x58 so that
it will not break existing EDK2 area.

Signed-off-by: Masami Hiramatsu 
---
 .../dts/synquacer-sc2a11-developerbox-u-boot.dtsi  |   26 ++--
 configs/synquacer_developerbox_defconfig   |5 ++--
 include/configs/synquacer.h|4 +--
 3 files changed, 22 insertions(+), 13 deletions(-)

diff --git a/arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi 
b/arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi
index 7a56116d6f..095727e03c 100644
--- a/arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi
+++ b/arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi
@@ -56,7 +56,7 @@
};
 
partition@18 {
-   label = "FIP-TFA";
+   label = "LegacyFIP";
reg = <0x18 0x78000>;
};
 
@@ -66,18 +66,28 @@
};
 
partition@20 {
-   label = "U-Boot";
-   reg = <0x20 0x10>;
+   label = "EDK2";
+   reg = <0x20 0x20>;
};
 
-   partition@30 {
-   label = "UBoot-Env";
-   reg = <0x30 0x10>;
+   partition@40 {
+   label = "EDK2-Env";
+   reg = <0x40 0x10>;
};
 
partition@50 {
-   label = "Ex-OPTEE";
-   reg = <0x50 0x20>;
+   label = "Metadata";
+   reg = <0x50 0x8>;
+   };
+
+   partition@58 {
+   label = "UBoot-Env";
+   reg = <0x58 0x8>;
+   };
+
+   partition@60 {
+   label = "FIP";
+   reg = <0x60 0x40>;
};
};
};
diff --git a/configs/synquacer_developerbox_defconfig 
b/configs/synquacer_developerbox_defconfig
index da57dc288f..484f6b7336 100644
--- a/configs/synquacer_developerbox_defconfig
+++ b/configs/synquacer_developerbox_defconfig
@@ -1,9 +1,10 @@
 CONFIG_ARM=y
 CONFIG_ARCH_SYNQUACER=y
-CONFIG_SYS_TEXT_BASE=0x0820
+CONFIG_POSITION_INDEPENDENT=y
+CONFIG_SYS_TEXT_BASE=0
 CONFIG_SYS_MALLOC_LEN=0x100
 CONFIG_ENV_SIZE=0x3
-CONFIG_ENV_OFFSET=0x30
+CONFIG_ENV_OFFSET=0x58
 CONFIG_ENV_SECT_SIZE=0x1
 CONFIG_DM_GPIO=y
 CONFIG_DEFAULT_DEVICE_TREE="synquacer-sc2a11-developerbox"
diff --git a/include/configs/synquacer.h b/include/configs/synquacer.h
index 0409589152..6d67bd2af5 100644
--- a/include/configs/synquacer.h
+++ b/include/configs/synquacer.h
@@ -48,9 +48,7 @@
 /* Since U-Boot 64bit PCIe support is limited, disable 64bit MMIO support */
 
 #define DEFAULT_DFU_ALT_INFO "dfu_alt_info="   \
-   "mtd nor1=u-boot.bin raw 20 10;"\
-   "fip.bin raw 18 78000;" \
-   "optee.bin raw 50 10\0"
+   "mtd nor1=fip.bin raw 60 40\0"
 
 /* Distro boot settings */
 #ifndef CONFIG_SPL_BUILD

[RFC PATCH 10/14] FWU: Reboot soon after successfully install the new firmware

Reboot to the trial state soon after successfully installing
the new firmware to the next bank and updating the active_index.
This is enabled by CONFIG_FWU_REBOOT_AFTER_UPDATE and is a
recommended option.

Signed-off-by: Masami Hiramatsu 
---
 lib/efi_loader/efi_capsule.c |   10 --
 lib/fwu_updates/Kconfig  |9 +
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 83c89a0cbb..0928425b5f 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -1355,10 +1355,16 @@ efi_status_t efi_launch_capsules(void)
} else {
log_debug("Successfully updated the 
active_index\n");
status = fwu_trial_state_ctr_start();
-   if (status < 0)
+   if (status < 0) {
ret = EFI_DEVICE_ERROR;
-   else
+   } else {
ret = EFI_SUCCESS;
+   if 
(IS_ENABLED(CONFIG_FWU_REBOOT_AFTER_UPDATE)) {
+   log_info("New firmware is 
installed in bank#%d. Reboot from that bank.\n",
+update_index);
+   do_reset(NULL, 0, 0, NULL);
+   }
+   }
}
} else if (capsule_update == true && update_status == false) {
log_err("All capsules were not updated. Not updating 
FWU metadata\n");
diff --git a/lib/fwu_updates/Kconfig b/lib/fwu_updates/Kconfig
index 6de28e0c9c..0940a90747 100644
--- a/lib/fwu_updates/Kconfig
+++ b/lib/fwu_updates/Kconfig
@@ -29,3 +29,12 @@ config FWU_TRIAL_STATE_CNT
  With FWU Multi Bank Update feature enabled, number of times
  the platform is allowed to boot in Trial State after an
  update.
+
+config FWU_REBOOT_AFTER_UPDATE
+   bool "Reboot soon after installing new firmware"
+   depends on FWU_MULTI_BANK_UPDATE
+   default y
+   help
+ Reboot the machine soon after installing a new firmware
+ and start trial boot. You can disable this option for
+ debugging or FWU development, but recommended to enable it.

[RFC PATCH 11/14] FWU: Add FWU Multi Bank Update on SPI Flash

Signed-off-by: Masami Hiramatsu 
---
 include/fwu.h  |   13 ++
 lib/fwu_updates/Kconfig|   34 ++
 lib/fwu_updates/Makefile   |5 -
 lib/fwu_updates/fwu_mdata_sf.c |  241 
 4 files changed, 288 insertions(+), 5 deletions(-)
 create mode 100644 lib/fwu_updates/fwu_mdata_sf.c

diff --git a/include/fwu.h b/include/fwu.h
index 7af94988b7..a013170321 100644
--- a/include/fwu.h
+++ b/include/fwu.h
@@ -64,9 +64,18 @@ int fwu_accept_image(efi_guid_t *img_type_id, u32 bank);
 int fwu_clear_accept_image(efi_guid_t *img_type_id, u32 bank);
 
 int fwu_plat_get_update_index(u32 *update_idx);
-int fwu_plat_get_blk_desc(struct blk_desc **desc);
-int fwu_plat_get_alt_num(void *identifier);
 int fwu_plat_fill_partition_guids(efi_guid_t **part_guid_arr);
 void fwu_plat_get_bootidx(void *boot_idx);
 
+#ifdef CONFIG_FWU_MULTI_BANK_UPDATE_GPT_BLK
+int fwu_plat_get_blk_desc(struct blk_desc **desc);
+int fwu_plat_get_alt_num(void *identifier);
+#endif
+
+#ifdef CONFIG_FWU_MULTI_BANK_UPDATE_SF
+struct fwu_mdata_ops *fwu_sf_get_fwu_mdata_ops(void);
+int fwu_plat_get_image_alt_num(efi_guid_t image_type_id, u32 update_bank,
+  int *alt_no);
+#endif
+
 #endif /* _FWU_H_ */
diff --git a/lib/fwu_updates/Kconfig b/lib/fwu_updates/Kconfig
index 0940a90747..8a369b9872 100644
--- a/lib/fwu_updates/Kconfig
+++ b/lib/fwu_updates/Kconfig
@@ -38,3 +38,37 @@ config FWU_REBOOT_AFTER_UPDATE
  Reboot the machine soon after installing a new firmware
  and start trial boot. You can disable this option for
  debugging or FWU development, but recommended to enable it.
+
+config FWU_MULTI_BANK_UPDATE_GPT_BLK
+   bool "Enable FWU Multi Bank Update for GPT on blockdev"
+   depends on FWU_MULTI_BANK_UPDATE
+   select EFI_PARTITION
+   help
+ Enable FWU Multi Bank Update for GPT on a block device. This
+ driver depends on GPT and the block device. FWU meatadata and
+ firmware will be stored on a block device with GPT.
+
+config FWU_MULTI_BANK_UPDATE_SF
+   bool "Enable FWU Multi Bank Update for SPI Flash"
+   depends on FWU_MULTI_BANK_UPDATE
+   help
+ Enable FWU Multi Bank Update for SPI flash driver. This
+ driver does not depend on GPT. Instead, the platform must
+ provide some APIs and define the offset of the primary and
+ the secondary metadata.
+
+config FWU_SF_PRIMARY_MDATA_OFFSET
+   hex "The offset of the primary metadata"
+   depends on FWU_MULTI_BANK_UPDATE_SF
+   help
+ The offset of the primary metadata on SPI Flash in
+ hexadecimal.
+
+config FWU_SF_SECONDARY_MDATA_OFFSET
+   hex "The offset of the secondary metadata"
+   depends on FWU_MULTI_BANK_UPDATE_SF
+   help
+ The offset of the secondary metadata on SPI Flash in
+ hexadecimal.
+ This must NOT be the same offset of the primary
+ metadata.
diff --git a/lib/fwu_updates/Makefile b/lib/fwu_updates/Makefile
index 73099a30cb..80669344f2 100644
--- a/lib/fwu_updates/Makefile
+++ b/lib/fwu_updates/Makefile
@@ -6,6 +6,5 @@
 obj-$(CONFIG_FWU_MULTI_BANK_UPDATE) += fwu_mdata.o
 obj-$(CONFIG_FWU_MULTI_BANK_UPDATE) += fwu.o
 
-ifdef CONFIG_EFI_PARTITION
-obj-$(CONFIG_FWU_MULTI_BANK_UPDATE) += fwu_mdata_gpt_blk.o
-endif
+obj-$(CONFIG_FWU_MULTI_BANK_UPDATE_GPT_BLK) += fwu_mdata_gpt_blk.o
+obj-$(CONFIG_FWU_MULTI_BANK_UPDATE_SF) += fwu_mdata_sf.o
diff --git a/lib/fwu_updates/fwu_mdata_sf.c b/lib/fwu_updates/fwu_mdata_sf.c
new file mode 100644
index 00..9e3cae7b68
--- /dev/null
+++ b/lib/fwu_updates/fwu_mdata_sf.c
@@ -0,0 +1,241 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2021, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/*
+ * For the FWU SPI flash driver, the platform must define below functions
+ * according to its dfu_alt_info.
+ */
+extern int fwu_plat_get_image_alt_num(efi_guid_t image_type_id,
+ u32 update_bank, int *alt_no);
+
+static struct spi_flash *fwu_spi_flash;
+
+static int __fwu_sf_get_flash(void)
+{
+   if (IS_ENABLED(CONFIG_DM_SPI_FLASH)) {
+   struct udevice *new;
+   int ret;
+
+   ret = spi_flash_probe_bus_cs(CONFIG_SF_DEFAULT_BUS, 
CONFIG_SF_DEFAULT_CS,
+CONFIG_SF_DEFAULT_SPEED, 
CONFIG_SF_DEFAULT_MODE,
+&new);
+   if (ret)
+   return ret;
+
+   fwu_spi_flash = dev_get_uclass_priv(new);
+   } else {
+   fwu_spi_flash = spi_flash_probe(CONFIG_SF_DEFAULT_BUS, 
CONFIG_SF_DEFAULT_CS,
+   CONFIG_SF_DEFAULT_SPEED, 
CONFIG_SF_DEFAULT_MODE);
+   if (!fwu_spi_flash)
+   return -EIO;
+

[RFC PATCH 12/14] FWU: synquacer: Add FWU Multi bank update support for DeveloperBox

The DeveloperBox platform can support the FWU Multi bank
update. SCP firmware will switch the boot mode by DSW3-4
and load the Multi bank update supported TF-A BL2 from
0x60 offset on the SPI flash. Thus it can co-exist
with the legacy boot mode (legacy U-Boot or EDK2).

Signed-off-by: Masami Hiramatsu 
---
 board/socionext/developerbox/Kconfig|   19 
 board/socionext/developerbox/Makefile   |1 
 board/socionext/developerbox/fwu_plat.c |  158 +++
 include/configs/synquacer.h |   10 ++
 include/efi_loader.h|3 +
 lib/efi_loader/efi_firmware.c   |   14 +--
 6 files changed, 198 insertions(+), 7 deletions(-)
 create mode 100644 board/socionext/developerbox/fwu_plat.c

diff --git a/board/socionext/developerbox/Kconfig 
b/board/socionext/developerbox/Kconfig
index c181d26a44..4e2c341aad 100644
--- a/board/socionext/developerbox/Kconfig
+++ b/board/socionext/developerbox/Kconfig
@@ -32,4 +32,23 @@ config SYS_CONFIG_NAME
default "synquacer"
 
 endif
+
+config FWU_MULTI_BANK_UPDATE
+   select FWU_MULTI_BANK_UPDATE_SF
+
+config FWU_MULTI_BANK_UPDATE_SF
+   select DM_SPI_FLASH
+
+config FWU_NUM_BANKS
+   default 6
+
+config FWU_NUM_IMAGES_PER_BANK
+   default 1
+
+config FWU_SF_PRIMARY_MDATA_OFFSET
+   default 0x50
+
+config FWU_SF_SECONDARY_MDATA_OFFSET
+   default 0x52
+
 endif
diff --git a/board/socionext/developerbox/Makefile 
b/board/socionext/developerbox/Makefile
index 4a46de995a..15cce9c57e 100644
--- a/board/socionext/developerbox/Makefile
+++ b/board/socionext/developerbox/Makefile
@@ -7,3 +7,4 @@
 #
 
 obj-y  := developerbox.o
+obj-$(CONFIG_FWU_MULTI_BANK_UPDATE_SF) += fwu_plat.o
diff --git a/board/socionext/developerbox/fwu_plat.c 
b/board/socionext/developerbox/fwu_plat.c
new file mode 100644
index 00..dbb814f1fd
--- /dev/null
+++ b/board/socionext/developerbox/fwu_plat.c
@@ -0,0 +1,158 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2021, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/* SPI Flash accessors */
+static struct spi_flash *plat_spi_flash;
+
+static int __plat_sf_get_flash(void)
+{
+   struct udevice *new;
+   int ret;
+
+   //TODO: use CONFIG_FWU_SPI_*
+   ret = spi_flash_probe_bus_cs(CONFIG_SF_DEFAULT_BUS, 
CONFIG_SF_DEFAULT_CS,
+CONFIG_SF_DEFAULT_SPEED, 
CONFIG_SF_DEFAULT_MODE,
+&new);
+   if (ret)
+   return ret;
+
+   plat_spi_flash = dev_get_uclass_priv(new);
+   return 0;
+}
+
+static int plat_sf_get_flash(struct spi_flash **flash)
+{
+   int ret = 0;
+
+   if (!plat_spi_flash)
+   ret = __plat_sf_get_flash();
+
+   *flash = plat_spi_flash;
+
+   return ret;
+}
+
+static int sf_load_data(u32 offs, u32 size, void **data)
+{
+   struct spi_flash *flash;
+   int ret;
+
+   ret = plat_sf_get_flash(&flash);
+   if (ret < 0)
+   return ret;
+
+   *data = memalign(ARCH_DMA_MINALIGN, size);
+   if (!*data)
+   return -ENOMEM;
+
+   ret = spi_flash_read(flash, offs, size, *data);
+   if (ret < 0) {
+   free(*data);
+   *data = NULL;
+   }
+
+   return ret;
+}
+
+/* Platform dependent GUIDs */
+
+/* The GUID for the SNI FIP image type GUID */
+#define FWU_IMAGE_TYPE_DEVBOX_FIP_GUID \
+   EFI_GUID(0x7d6dc310, 0x52ca, 0x43b8, 0xb7, 0xb9, \
+0xf9, 0xd6, 0xc5, 0x01, 0xd1, 0x08)
+
+#define PLAT_METADATA_OFFSET   0x51
+#define PLAT_METADATA_SIZE (sizeof(struct devbox_metadata))
+
+struct __packed devbox_metadata {
+   u32 boot_index;
+   u32 boot_count;
+   u32 invert_dual;
+} *devbox_plat_metadata;
+
+static const efi_guid_t devbox_fip_image_type_guid = 
FWU_IMAGE_TYPE_DEVBOX_FIP_GUID;
+
+int fwu_plat_get_image_alt_num(efi_guid_t image_type_id, u32 update_bank,
+  int *alt_no)
+{
+   /* DeveloperBox FWU Multi bank only supports FIP image. */
+   if (guidcmp(&image_type_id, &devbox_fip_image_type_guid))
+   return -EOPNOTSUPP;
+
+   /*
+* DeveloperBox FWU expects Bank:Image = 1:1, and the dfu_alt_info
+* only has the entries for banks. Thus the alt_no should be equal
+* to the update_bank.
+*/
+   update_bank %= CONFIG_FWU_NUM_BANKS;
+   *alt_no = update_bank;
+
+   return 0;
+}
+
+/* SPI flash doesn't have GPT, and it's not blk device */
+int fwu_plat_fill_partition_guids(efi_guid_t **part_guid_arr)
+{
+   efi_status_t ret;
+
+   free(*part_guid_arr);
+
+   ret = efi_fill_part_guid_array(&devbox_fip_image_type_guid, 
part_guid_arr);
+   return (ret != EFI_SUCCESS) ? -ENOMEM : 0;
+}
+
+/* TBD: add a usage counter for wear leveling */
+int fwu_plat_get_update_index(u32 *update_

[RFC PATCH 13/14] FWU: synquacer: Initialize broken metadata

Since the FWU metadata is not initialized at the installation,
if it is broken, it should be initialized. Usually, the FWU
metadata is not covered by capsule update, so it is safe to
initialize the metadata portion if it seems broken.

But for the production device, usually firmware will be installed
with initialized metadata, and the broken metadata means the
device can be compromized. In that case, build U-Boot without
this option.

Signed-off-by: Masami Hiramatsu 
---
 board/socionext/developerbox/Kconfig|   12 ++
 board/socionext/developerbox/fwu_plat.c |   59 +++
 2 files changed, 71 insertions(+)

diff --git a/board/socionext/developerbox/Kconfig 
b/board/socionext/developerbox/Kconfig
index 4e2c341aad..1b36e10f3b 100644
--- a/board/socionext/developerbox/Kconfig
+++ b/board/socionext/developerbox/Kconfig
@@ -51,4 +51,16 @@ config FWU_SF_PRIMARY_MDATA_OFFSET
 config FWU_SF_SECONDARY_MDATA_OFFSET
default 0x52
 
+config FWU_INIT_BROKEN_METADATA
+   bool "Initialize FWU metadata if broken"
+   select BOARD_LATE_INIT
+   default n
+   help
+ Initialize FWU metadata if the metadata is broken.
+ This option is only for the development environment, since if the
+ metadata is broken, it means someone may compromize it. In that case
+ the production device must be bricked.
+ But for the development environment, or initial installation of the
+ FWU multi-bank update firmware, this will be useful.
+
 endif
diff --git a/board/socionext/developerbox/fwu_plat.c 
b/board/socionext/developerbox/fwu_plat.c
index dbb814f1fd..2982e47a16 100644
--- a/board/socionext/developerbox/fwu_plat.c
+++ b/board/socionext/developerbox/fwu_plat.c
@@ -156,3 +156,62 @@ struct fwu_mdata_ops *get_plat_fwu_mdata_ops(void)
return fwu_sf_get_fwu_mdata_ops();
 }
 
+#ifdef CONFIG_FWU_INIT_BROKEN_METADATA
+
+static void devbox_init_fwu_mdata(void)
+{
+   const efi_guid_t null_guid = NULL_GUID;
+   struct fwu_image_bank_info *bank;
+   struct fwu_mdata *metadata;
+   int i, j, ret;
+
+   metadata = memalign(ARCH_DMA_MINALIGN, sizeof(*metadata));
+   if (!metadata) {
+   log_err("Failed to allocate initial metadata.\n");
+   return;
+   }
+
+   metadata->version = 1;
+   metadata->active_index = 0;
+   metadata->previous_active_index = 0;
+
+   /*
+* Since the DeveloperBox doesn't use GPT, both of
+* fwu_image_entry::location_uuid and
+* fwu_img_bank_info::image_uuid are null GUID.
+*/
+   for (i = 0; i < CONFIG_FWU_NUM_IMAGES_PER_BANK; i++) {
+   guidcpy(&metadata->img_entry[i].image_type_uuid,
+   &devbox_fip_image_type_guid);
+   guidcpy(&metadata->img_entry[i].location_uuid,
+   &null_guid);
+   bank = metadata->img_entry[i].img_bank_info;
+
+   for (j = 0; j < CONFIG_FWU_NUM_BANKS; j++) {
+   guidcpy(&bank[j].image_uuid, &null_guid);
+   bank[j].accepted = (j == 0) ? 1 : 0;
+   bank[j].reserved = 0;
+   }
+   }
+
+   ret = fwu_update_mdata(metadata);
+   if (ret < 0)
+   log_err("Failed to initialize FWU metadata\n");
+   else
+   log_err("Initialized FWU metadata\n");
+   free(metadata);
+}
+
+int board_late_init(void)
+{
+   struct fwu_mdata *metadata;
+
+   if (fwu_get_mdata(&metadata) < 0) {
+   // Initialize FWU metadata if broken
+   log_err("Unable to get a valid metadata. Initialize it.\n");
+   devbox_init_fwu_mdata();
+   }
+   return 0;
+}
+
+#endif

[RFC PATCH 14/14] configs: synquacer: Add FWU support for DeveloperBox

Enable FWU Multi-Bank support for DeveloperBox SynQuacer platform.
This also enables fwu_metadata_read command and "reboot soon after
update" option.

Signed-off-by: Masami Hiramatsu 
---
 configs/synquacer_developerbox_defconfig |7 +++
 1 file changed, 7 insertions(+)

diff --git a/configs/synquacer_developerbox_defconfig 
b/configs/synquacer_developerbox_defconfig
index 484f6b7336..02d87bc403 100644
--- a/configs/synquacer_developerbox_defconfig
+++ b/configs/synquacer_developerbox_defconfig
@@ -91,3 +91,10 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
 CONFIG_EFI_CAPSULE_ON_DISK=y
 CONFIG_EFI_IGNORE_OSINDICATIONS=y
 CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
+CONFIG_EFI_SECURE_BOOT=y
+CONFIG_FWU_MULTI_BANK_UPDATE=y
+CONFIG_FWU_MULTI_BANK_UPDATE_SF=y
+CONFIG_FWU_MULTI_BANK_UPDATE_GPT_BLK=n
+CONFIG_CMD_FWU_METADATA=y
+CONFIG_FWU_REBOOT_AFTER_UPDATE=y
+CONFIG_FWU_INIT_BROKEN_METADATA=y

Re: [PATCH u-boot-dm v4] fdt_support: Add fdt_for_each_node_by_compatible() helper macro


On 1/20/22 01:04, Marek Behún wrote:

From: Marek Behún 

Add macro fdt_for_each_node_by_compatible() to allow iterating over
fdt nodes by compatible string.

Convert various usages of
 off = fdt_node_offset_by_compatible(fdt, start, compat);
 while (off > 0) {
 code();
 off = fdt_node_offset_by_compatible(fdt, off, compat);
 }
and similar, to
 fdt_for_each_node_by_compatible(off, fdt, start, compat)
 code();

Signed-off-by: Marek Behún 
Reviewed-by: Stefan Roese 
Reviewed-by: Simon Glass 


Applied to u-boot-marvell/master

Thanks,
Stefan


---
Dear Stefan, fixed and tested on GitHub CI:
   https://github.com/u-boot/u-boot/pull/105
Hopefully this time it works :-)

As in v3, to resolve conflict with Tom's master, change
   CONFIG_SYS_CLK_FREQ
to
   get_board_sys_clk()
---
  arch/arm/cpu/armv8/fsl-layerscape/fdt.c|  9 ++---
  arch/arm/cpu/armv8/fsl-layerscape/icid.c   |  5 +
  arch/arm/mach-tegra/gpu.c  |  5 +
  arch/mips/mach-octeon/octeon_fdt.c | 11 ++-
  arch/powerpc/cpu/mpc85xx/liodn.c   |  9 ++---
  board/Marvell/octeon_ebb7304/board.c   |  9 +++--
  board/congatec/cgtqmx8/spl.c   |  8 +++-
  board/freescale/lx2160a/lx2160a.c  |  5 +
  common/fdt_support.c   | 22 --
  drivers/misc/fsl_portals.c |  6 +-
  drivers/net/fm/fdt.c   |  3 +--
  drivers/pci/pcie_layerscape_fixup_common.c | 12 ++--
  drivers/phy/marvell/comphy_a3700.c | 12 ++--
  drivers/video/meson/simplefb_common.c  |  9 +++--
  drivers/video/sunxi/simplefb_common.c  |  7 +++
  include/fdt_support.h  |  6 ++
  16 files changed, 45 insertions(+), 93 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index 4354aa251e..2fa7ebf163 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -161,14 +161,9 @@ void fsl_fdt_disable_usb(void *blob)
 * controller is used, SYSCLK must meet the additional requirement
 * of 100 MHz.
 */
-   if (CONFIG_SYS_CLK_FREQ != 1) {
-   off = fdt_node_offset_by_compatible(blob, -1, "snps,dwc3");
-   while (off != -FDT_ERR_NOTFOUND) {
+   if (CONFIG_SYS_CLK_FREQ != 1)
+   fdt_for_each_node_by_compatible(off, blob, -1, "snps,dwc3")
fdt_status_disabled(blob, off);
-   off = fdt_node_offset_by_compatible(blob, off,
-   "snps,dwc3");
-   }
-   }
  }
  
  #ifdef CONFIG_HAS_FEATURE_GIC64K_ALIGN

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/icid.c 
b/arch/arm/cpu/armv8/fsl-layerscape/icid.c
index 82c5a8b123..25cd82f16e 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/icid.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/icid.c
@@ -116,8 +116,7 @@ void fdt_fixup_fman_port_icid_by_compat(void *blob, int 
smmu_ph,
int noff, len, icid;
const u32 *prop;
  
-	noff = fdt_node_offset_by_compatible(blob, -1, compat);

-   while (noff > 0) {
+   fdt_for_each_node_by_compatible(noff, blob, -1, compat) {
prop = fdt_getprop(blob, noff, "cell-index", &len);
if (!prop) {
printf("WARNING missing cell-index for fman port\n");
@@ -137,8 +136,6 @@ void fdt_fixup_fman_port_icid_by_compat(void *blob, int 
smmu_ph,
}
  
  		fdt_set_iommu_prop(blob, noff, smmu_ph, (u32 *)&icid, 1);

-
-   noff = fdt_node_offset_by_compatible(blob, noff, compat);
}
  }
  
diff --git a/arch/arm/mach-tegra/gpu.c b/arch/arm/mach-tegra/gpu.c

index 13ffade040..36538e7f96 100644
--- a/arch/arm/mach-tegra/gpu.c
+++ b/arch/arm/mach-tegra/gpu.c
@@ -46,11 +46,8 @@ int tegra_gpu_enable_node(void *blob, const char *compat)
if (!_configured)
return 0;
  
-	offset = fdt_node_offset_by_compatible(blob, -1, compat);

-   while (offset != -FDT_ERR_NOTFOUND) {
+   fdt_for_each_node_by_compatible(offset, blob, -1, compat)
fdt_status_okay(blob, offset);
-   offset = fdt_node_offset_by_compatible(blob, offset, compat);
-   }
  
  	return 0;

  }
diff --git a/arch/mips/mach-octeon/octeon_fdt.c 
b/arch/mips/mach-octeon/octeon_fdt.c
index 199f692516..5c5a14e87a 100644
--- a/arch/mips/mach-octeon/octeon_fdt.c
+++ b/arch/mips/mach-octeon/octeon_fdt.c
@@ -424,12 +424,8 @@ void __octeon_fixup_fdt_mac_addr(void)
}
  
  	/* Assign 78XX addresses in the order they appear in the device tree. */

-   node = fdt_node_offset_by_compatible(working_fdt, -1, 
"cavium,octeon-7890-bgx-port");
-   while (node != -FDT_ERR_NOTFOUND) {
+   fdt_for_each_node_by_compatible(node, working_fdt, -1, 
"cavium,octeon-7890-bgx-port")

Re: [PATCH u-boot-marvell v2] arm: mvebu: turris_omnia: Fixup SATA or PCIe nodes at runtime in DT blob


On 1/10/22 11:47, Marek Behún wrote:

From: Pali Rohár 

On of the MiniPCIe ports on Turris Omnia is also a mSATA port. Whether
it works in SATA or PCIe mode is determined by a strapping pin, which
value is read from the MCU.

We already determine which type of card is connected when configuring
SerDeses.

But until now we left both SATA and PCIe port 0 nodes in device tree
enabled, and so the SATA driver is probed in U-Boot / Linux even if we
know there is no mSATA card, and similarly PCIe driver tries to link on
port 0 even if we know there is mSATA card, not a PCIe card.

Fixup device tree blob to disable SATA node if mSATA card is not
present, and to disable PCIe port 0 node if mSATA card is present.

Do this for U-Boot's DT blob before relocation and also for kernel DT
blob before booting.

This ensures that software does not try to use SATA or PCIe HW when
corresponding PHY is not configured.

Signed-off-by: Pali Rohár 
[ refactored and fixed some issues ]
Signed-off-by: Marek Behún 


Applied to u-boot-marvell/master

Thanks,
Stefan


---
Changes since v1:
- removed extra space after macro name:
 fdt_for_each_node_by_compatible (...)
   to
 fdt_for_each_node_by_compatible(...)
   as requested by Stefan
---
  board/CZ.NIC/turris_omnia/turris_omnia.c | 91 +++-
  configs/turris_omnia_defconfig   |  1 +
  2 files changed, 90 insertions(+), 2 deletions(-)

diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index ae24d14b76..33cec6587e 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -490,6 +490,86 @@ void spl_board_init(void)
}
  }
  
+#if IS_ENABLED(CONFIG_OF_BOARD_FIXUP) || IS_ENABLED(CONFIG_OF_BOARD_SETUP)

+
+static void fixup_serdes_0_nodes(void *blob)
+{
+   bool mode_sata;
+   int node;
+
+   /*
+* Determine if SerDes 0 is configured to SATA mode.
+* We do this instead of calling omnia_detect_sata() to avoid another
+* call to the MCU. By this time the common PHYs are initialized (it is
+* done in SPL), so we can read this common PHY register.
+*/
+   mode_sata = (readl(MVEBU_REGISTER(0x183fc)) & GENMASK(3, 0)) == 2;
+
+   /*
+* We're either adding status = "disabled" property, or changing
+* status = "okay" to status = "disabled". In both cases we'll need more
+* space. Increase the size a little.
+*/
+   if (fdt_increase_size(blob, 32) < 0) {
+   printf("Cannot increase FDT size!\n");
+   return;
+   }
+
+   /* If mSATA card is not present, disable SATA DT node */
+   if (!mode_sata) {
+   fdt_for_each_node_by_compatible(node, blob, -1,
+   "marvell,armada-380-ahci") {
+   if (!fdtdec_get_is_enabled(blob, node))
+   continue;
+
+   if (fdt_status_disabled(blob, node) < 0)
+   printf("Cannot disable SATA DT node!\n");
+   else
+   debug("Disabled SATA DT node\n");
+
+   break;
+   }
+
+   return;
+   }
+
+   /* Otherwise disable PCIe port 0 DT node (MiniPCIe / mSATA port) */
+   fdt_for_each_node_by_compatible(node, blob, -1,
+   "marvell,armada-370-pcie") {
+   int port;
+
+   if (!fdtdec_get_is_enabled(blob, node))
+   continue;
+
+   fdt_for_each_subnode (port, blob, node) {
+   if (!fdtdec_get_is_enabled(blob, port))
+   continue;
+
+   if (fdtdec_get_int(blob, port, "marvell,pcie-port",
+  -1) != 0)
+   continue;
+
+   if (fdt_status_disabled(blob, port) < 0)
+   printf("Cannot disable PCIe port 0 DT node!\n");
+   else
+   debug("Disabled PCIe port 0 DT node\n");
+
+   return;
+   }
+   }
+}
+
+#endif
+
+#if IS_ENABLED(CONFIG_OF_BOARD_FIXUP)
+int board_fix_fdt(void *blob)
+{
+   fixup_serdes_0_nodes(blob);
+
+   return 0;
+}
+#endif
+
  int board_init(void)
  {
/* address of boot parameters */
@@ -694,7 +774,7 @@ static bool fixup_mtd_partitions(void *blob, int offset, 
struct mtd_info *mtd)
return true;
  }
  
-int ft_board_setup(void *blob, struct bd_info *bd)

+static void fixup_spi_nor_partitions(void *blob)
  {
struct mtd_info *mtd;
int node;
@@ -711,12 +791,19 @@ int ft_board_setup(void *blob, struct bd_info *bd)
goto fail;
  
  	put_mtd_device(mtd);

-   return 0;
+   return;
  
  fail:

printf("Failed fixing SPI NOR partitions!\n");

Re: [PATCH] pci: pci_mvebu: Add support for Kirkwood PCIe controllers


On 1/13/22 14:28, Pali Rohár wrote:

Kirkwood uses macros KW_DEFADR_PCI_MEM and KW_DEFADR_PCI_IO for base
address of PCIe mappings. Size of PCIe windows is not defined in any macro
yet, so export them in new KW_DEFADR_PCI_MEM_SIZE and KW_DEFADR_PCI_IO_SIZE
macros.

Kirkwood arch code already maps mbus windows for io and mem, so avoid
calling mvebu_mbus_add_window_by_id() function which would try to do
duplicate window mapping.

Kirkwood PCIe controllers already use "marvell,kirkwood-pcie" DT compatible
string, so mark pci_mvebu.c driver as compatible for it.

Signed-off-by: Pali Rohár 


Applied to u-boot-marvell/master

Thanks,
Stefan


---
This patch depends on series "mvebu: Move PCIe code from serdes to PCIe driver":
https://patchwork.ozlabs.org/project/uboot/list/?series=277906&state=*

Tony, could you please test it in Kirwood hardware?
---
  arch/arm/mach-kirkwood/cpu.c  |  4 ++--
  arch/arm/mach-kirkwood/include/mach/cpu.h |  3 +++
  drivers/pci/Kconfig   |  6 +++---
  drivers/pci/pci_mvebu.c   | 16 
  4 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-kirkwood/cpu.c b/arch/arm/mach-kirkwood/cpu.c
index e9571298a824..80f893ab369a 100644
--- a/arch/arm/mach-kirkwood/cpu.c
+++ b/arch/arm/mach-kirkwood/cpu.c
@@ -54,11 +54,11 @@ unsigned int kw_winctrl_calcsize(unsigned int sizeval)
  
  static struct mbus_win windows[] = {

/* Window 0: PCIE MEM address space */
-   { KW_DEFADR_PCI_MEM, 1024 * 1024 * 256,
+   { KW_DEFADR_PCI_MEM, KW_DEFADR_PCI_MEM_SIZE,
  KWCPU_TARGET_PCIE, KWCPU_ATTR_PCIE_MEM },
  
  	/* Window 1: PCIE IO address space */

-   { KW_DEFADR_PCI_IO, 1024 * 64,
+   { KW_DEFADR_PCI_IO, KW_DEFADR_PCI_IO_SIZE,
  KWCPU_TARGET_PCIE, KWCPU_ATTR_PCIE_IO },
  
  	/* Window 2: NAND Flash address space */

diff --git a/arch/arm/mach-kirkwood/include/mach/cpu.h 
b/arch/arm/mach-kirkwood/include/mach/cpu.h
index ea42182cf9c6..71c546f9acf6 100644
--- a/arch/arm/mach-kirkwood/include/mach/cpu.h
+++ b/arch/arm/mach-kirkwood/include/mach/cpu.h
@@ -68,6 +68,9 @@ enum kwcpu_attrib {
  #define KW_DEFADR_SPIF0xE800
  #define KW_DEFADR_BOOTROM 0xF800
  
+#define KW_DEFADR_PCI_MEM_SIZE	(1024 * 1024 * 256)

+#define KW_DEFADR_PCI_IO_SIZE  (1024 * 64)
+
  struct mbus_win {
u32 base;
u32 size;
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 630d6e6cc5ee..69141344c869 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -262,13 +262,13 @@ config PCIE_IPROC
  Say Y here if you want to enable Broadcom iProc PCIe controller,
  
  config PCI_MVEBU

-   bool "Enable Armada XP/38x PCIe driver"
-   depends on ARCH_MVEBU
+   bool "Enable Kirkwood / Armada 370/XP/375/38x PCIe driver"
+   depends on (ARCH_KIRKWOOD || ARCH_MVEBU)
select MISC
select DM_RESET
help
  Say Y here if you want to enable PCIe controller support on
- Armada XP/38x SoCs.
+ Kirkwood and Armada 370/XP/375/38x SoCs.
  
  config PCIE_DW_COMMON

bool
diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index b3ea034a2847..d99a99bae940 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -498,6 +498,13 @@ static int mvebu_pcie_probe(struct udevice *dev)
mvebu_pcie_set_local_bus_nr(pcie, 0);
mvebu_pcie_set_local_dev_nr(pcie, 1);
  
+	/*

+* Kirkwood arch code already maps mbus windows for PCIe IO and MEM.
+* So skip calling mvebu_mbus_add_window_by_id() function as it would
+* fail on error "conflicts with another window" which means conflict
+* with existing PCIe window mappings.
+*/
+#ifndef CONFIG_ARCH_KIRKWOOD
if (resource_size(&pcie->mem) &&
mvebu_mbus_add_window_by_id(pcie->mem_target, pcie->mem_attr,
(phys_addr_t)pcie->mem.start,
@@ -519,6 +526,7 @@ static int mvebu_pcie_probe(struct udevice *dev)
pcie->io.start = 0;
pcie->io.end = -1;
}
+#endif
  
  	/* Setup windows and configure host bridge */

mvebu_pcie_setup_wins(pcie);
@@ -725,10 +733,17 @@ static int mvebu_pcie_bind(struct udevice *parent)
}
ports_count = 0;
  
+#ifdef CONFIG_ARCH_KIRKWOOD

+   mem.start = KW_DEFADR_PCI_MEM;
+   mem.end = KW_DEFADR_PCI_MEM + KW_DEFADR_PCI_MEM_SIZE - 1;
+   io.start = KW_DEFADR_PCI_IO;
+   io.end = KW_DEFADR_PCI_IO + KW_DEFADR_PCI_IO_SIZE - 1;
+#else
mem.start = MBUS_PCI_MEM_BASE;
mem.end = MBUS_PCI_MEM_BASE + MBUS_PCI_MEM_SIZE - 1;
io.start = MBUS_PCI_IO_BASE;
io.end = MBUS_PCI_IO_BASE + MBUS_PCI_IO_SIZE - 1;
+#endif
  
  	/* First phase: Fill mvebu_pcie struct for each port */

ofnode_for_each_subnode(subnode, dev_ofnode(parent)) {
@@ -809,6 +824,7 @@ static int mvebu_pcie_bind(struct udevice *parent)
  static const struct udev

Re: [PATCH] xilinx: common: change bootm_size to not go beyond ram_top

2022-01-20 Thread Ricardo Salveti

On Thu, Jan 20, 2022 at 4:33 AM Michal Simek  wrote:
> On 1/19/22 23:52, Ricardo Salveti wrote:
> > The available ram can be limited by ram_top as that depends on the
> > reserved memory nodes provided by the device-tree (via
> > board_get_usable_ram_top), so make sure to respect ram_top when setting
> > up bootm_size to avoid overlapping reserved memory regions (e.g. memory
> > used by OP-TEE).
> >
> > The same logic is available in env_get_bootm_size when bootm_size is
> > not defined by the default environment.
> >
> > Signed-off-by: Ricardo Salveti 
> > ---
> >   board/xilinx/common/board.c | 3 +++
> >   1 file changed, 3 insertions(+)
> >
> > diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
> > index 78a5d0efa86..4928fab2c96 100644
> > --- a/board/xilinx/common/board.c
> > +++ b/board/xilinx/common/board.c
> > @@ -389,6 +389,9 @@ int board_late_init_xilinx(void)
> >   if (CONFIG_IS_ENABLED(ARCH_ZYNQ) || CONFIG_IS_ENABLED(MICROBLAZE))
> >   bootm_size = min(bootm_size, (phys_size_t)(SZ_512M + 
> > SZ_256M));
> >
> > + if (gd->ram_base + bootm_size > gd->ram_top)
> > + bootm_size = gd->ram_top - gd->ram_base;
> > +
> >   ret |= env_set_hex("script_offset_f", CONFIG_BOOT_SCRIPT_OFFSET);
> >
> >   ret |= env_set_addr("bootm_low", (void *)gd->ram_base);
>
> Isn't it easier to directly setup bootm_size like this?
>
> phys_size_t bootm_size = gd->ram_top - gd->ram_base;

Yup, that should work better, will send a v2.

Thanks,
-- 
Ricardo Salveti

Re: [PATCH u-boot-marvell v4 0/9] More verifications for kwbimage in SPL


On 1/14/22 14:31, Pali Rohár wrote:

Hello Stefan,

this is v4 of series that adds more checks for kwbimage validity and
consistency to SPL, mainly checking image data checksum.

Patches now passed Github CI testing:
https://github.com/u-boot/u-boot/pull/106

Changes since v3:
- fix compile erros detected by CI (patch 2)
- print addresses in hex format instead of dec format (patch 1,3,6)
- rebase on master branch as v3 does not apply (patch 8)

Changes since v2:
- changed the error message in patch 6 according to Pali's suggestion
- added R-B tags

Changes since v1:
- updated error messages as requested by Stefan
- fixed checkpatch warnings for uintN_t types (converted to preferred
   uN)
- added more checkpatch fixes


Applied to u-boot-marvell/master

Thanks,
Stefan



Marek Behún (4):
   arm: mvebu: spl: Print srcaddr in error message
   arm: mvebu: spl: Use preferred types u8/u16/u32 instead of uintN_t
   arm: mvebu: spl: Use IS_ENABLED() instead of #ifdef where possible
   arm: mvebu: spl: Fix 100 column exceeds

Pali Rohár (5):
   arm: mvebu: Check that kwbimage offset and blocksize are valid
   SPL: Add struct spl_boot_device parameter into
 spl_parse_board_header()
   arm: mvebu: Check that kwbimage blockid matches boot mode
   SPL: Add support for checking board / BootROM specific image types
   arm: mvebu: Check for kwbimage data checksum

  arch/arm/mach-mvebu/spl.c   | 133 +++-
  arch/arm/mach-sunxi/spl_spi_sunxi.c |   2 +-
  common/spl/spl.c|  13 ++-
  common/spl/spl_ext.c|   9 +-
  common/spl/spl_fat.c|  11 ++-
  common/spl/spl_legacy.c |   3 +-
  common/spl/spl_mmc.c|  43 +
  common/spl/spl_nand.c   |  13 +--
  common/spl/spl_net.c|   2 +-
  common/spl/spl_nor.c|   4 +-
  common/spl/spl_onenand.c|   2 +-
  common/spl/spl_ram.c|   2 +-
  common/spl/spl_sata.c   |   9 +-
  common/spl/spl_sdp.c|   2 +-
  common/spl/spl_spi.c|   9 +-
  common/spl/spl_ubi.c|   4 +-
  common/spl/spl_usb.c|   4 +-
  common/spl/spl_xip.c|   4 +-
  common/spl/spl_ymodem.c |   4 +-
  drivers/usb/gadget/f_sdp.c  |  13 +--
  include/sdp.h   |   3 +-
  include/spl.h   |   7 ++
  22 files changed, 196 insertions(+), 100 deletions(-)



Viele Grüße,
Stefan Roese

--
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 1/1] drivers: octeon: get rid of Unicode in code


On 1/16/22 23:11, Heinrich Schuchardt wrote:

Placing Unicode control codes  in the middle of a comment
does not make much sense. Let's get rid of all Unicode in
drivers/ram/octeon/octeon3_lmc.c.

Signed-off-by: Heinrich Schuchardt 


Applied to u-boot-marvell/master

Thanks,
Stefan


---
  drivers/ram/octeon/octeon3_lmc.c | 34 
  1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/ram/octeon/octeon3_lmc.c b/drivers/ram/octeon/octeon3_lmc.c
index 349abc179f..eaef0fa5c1 100644
--- a/drivers/ram/octeon/octeon3_lmc.c
+++ b/drivers/ram/octeon/octeon3_lmc.c
@@ -2050,7 +2050,7 @@ static int compute_vref_val(struct ddr_priv *priv, int 
if_num, int rankx,
lmc_control.u64 = lmc_rd(priv, CVMX_LMCX_CONTROL(if_num));
  
  		/*

-*  New computed vref = existing computed vref – X
+*  New computed vref = existing computed vref - X
 *
 * The value of X is depending on different conditions.
 * Both #122 and #139 are 2Rx4 RDIMM, while #124 is stacked
@@ -2058,7 +2058,7 @@ static int compute_vref_val(struct ddr_priv *priv, int 
if_num, int rankx,
 *
 * 1. Stacked Die: 2Rx4
 * 1-slot: offset = 7. i, e New computed vref = existing
-* computed vref – 7
+* computed vref - 7
 * 2-slot: offset = 6
 *
 * 2. Regular: 2Rx4
@@ -9941,11 +9941,11 @@ static int test_dram_byte_hw(struct ddr_priv *priv, int 
if_num, u64 p,
 * NOTE: this step done in the calling routine(s)...
 * 3) Setup GENERAL_PURPOSE[0-2] registers with the data pattern
 * of choice.
-* a. GENERAL_PURPOSE0[DATA<63:0>] – sets the initial lower
+* a. GENERAL_PURPOSE0[DATA<63:0>] - sets the initial lower
 * (rising edge) 64 bits of data.
-* b. GENERAL_PURPOSE1[DATA<63:0>] – sets the initial upper
+* b. GENERAL_PURPOSE1[DATA<63:0>] - sets the initial upper
 * (falling edge) 64 bits of data.
-* c. GENERAL_PURPOSE2[DATA<15:0>] – sets the initial lower
+* c. GENERAL_PURPOSE2[DATA<15:0>] - sets the initial lower
 * (rising edge <7:0>) and upper (falling edge <15:8>) ECC data.
 */
  
@@ -9980,8 +9980,8 @@ static int test_dram_byte_hw(struct ddr_priv *priv, int if_num, u64 p,
  
  	/*

 * 7) Set PHY_CTL[PHY_RESET] = 1 (LMC automatically clears this as
-* it’s a one-shot operation). This is to get into the habit of
-* resetting PHY’s SILO to the original 0 location.
+* it's a one-shot operation). This is to get into the habit of
+* resetting PHY's SILO to the original 0 location.
 */
phy_ctl.u64 = lmc_rd(priv, CVMX_LMCX_PHY_CTL(if_num));
phy_ctl.s.phy_reset = 1;
@@ -10013,9 +10013,9 @@ static int test_dram_byte_hw(struct ddr_priv *priv, int 
if_num, u64 p,
 * a. COL, ROW, BA, BG, PRANK points to the starting point
 * of the address.
 * You can just set them to all 0.
-* b. RW_TRAIN – set this to 1.
-* c. TCCD_L – set this to 0.
-* d. READ_CMD_COUNT – instruct the sequence to the how many
+* b. RW_TRAIN - set this to 1.
+* c. TCCD_L - set this to 0.
+* d. READ_CMD_COUNT - instruct the sequence to the how many
 * writes/reads.
 * It is 5 bits field, so set to 31 of maximum # of r/w.
 */
@@ -10063,9 +10063,9 @@ static int test_dram_byte_hw(struct ddr_priv *priv, int 
if_num, u64 p,
  
  			/*

 * 6) Read MPR_DATA0 and MPR_DATA1 for results.
-* a. MPR_DATA0[MPR_DATA<63:0>] – comparison results
+* a. MPR_DATA0[MPR_DATA<63:0>] - comparison results
 *for DQ63:DQ0. (1 means MATCH, 0 means FAIL).
-* b. MPR_DATA1[MPR_DATA<7:0>] – comparison results
+* b. MPR_DATA1[MPR_DATA<7:0>] - comparison results
 *for ECC bit7:0.
 */
mpr_data0 = lmc_rd(priv, CVMX_LMCX_MPR_DATA0(if_num));
@@ -10073,8 +10073,8 @@ static int test_dram_byte_hw(struct ddr_priv *priv, int 
if_num, u64 p,
  
  			/*

 * 7) Set PHY_CTL[PHY_RESET] = 1 (LMC automatically
-* clears this as it’s a one-shot operation).
-* This is to get into the habit of resetting PHY’s
+* clears this as it's a one-shot operation).
+* This is to get into the habit of resetting PHY's
 * SILO to the original 0 location.
 */
phy_ctl.u64 = lmc_rd(priv, CVMX_LMCX_PHY_CTL(if_num));
@@ -10163,11 +10163,11 @@ static void setu

Re: [PATCH 0/2] arm: mvebu: Remove comphy_update_map()


On 1/18/22 10:33, Pali Rohár wrote:

Convert Turris MOX's comphy_update_map() to board_fix_fdt() and then
remove it.

Pali Rohár (2):
   arm: mvebu: turris_mox: Convert comphy_update_map() to board_fix_fdt()
   phy: marvell: Remove unused function comphy_update_map()

  board/CZ.NIC/turris_mox/turris_mox.c | 48 +---
  drivers/phy/marvell/comphy_core.c|  9 --
  drivers/phy/marvell/comphy_core.h|  9 ++
  include/mvebu/comphy.h   | 11 ---
  4 files changed, 24 insertions(+), 53 deletions(-)



Applied to u-boot-marvell/master

Thanks,
Stefan

Re: [PATCH] arm: a37xx: Disable CONFIG_DEBUG_UART_ANNOUNCE


On 1/18/22 10:43, Pali Rohár wrote:

After next branch was merged to v2022.01 release, U-Boot on A3720 started
printing "" line on UART during booting. There is no need to
print this debug line by default, so disable it via config option
CONFIG_DEBUG_UART_ANNOUNCE in all config files for Armada 3720 boards.

Signed-off-by: Pali Rohár 


Applied to u-boot-marvell/master

Thanks,
Stefan


---
  configs/mvebu_db-88f3720_defconfig  | 1 -
  configs/mvebu_espressobin-88f3720_defconfig | 1 -
  configs/turris_mox_defconfig| 1 -
  configs/uDPU_defconfig  | 1 -
  4 files changed, 4 deletions(-)

diff --git a/configs/mvebu_db-88f3720_defconfig 
b/configs/mvebu_db-88f3720_defconfig
index 459750f6e748..6cc90fa54266 100644
--- a/configs/mvebu_db-88f3720_defconfig
+++ b/configs/mvebu_db-88f3720_defconfig
@@ -66,7 +66,6 @@ CONFIG_PHY=y
  CONFIG_MVEBU_COMPHY_SUPPORT=y
  CONFIG_PINCTRL=y
  CONFIG_PINCTRL_ARMADA_37XX=y
-CONFIG_DEBUG_UART_ANNOUNCE=y
  CONFIG_MVEBU_A3700_UART=y
  CONFIG_MVEBU_A3700_SPI=y
  CONFIG_USB=y
diff --git a/configs/mvebu_espressobin-88f3720_defconfig 
b/configs/mvebu_espressobin-88f3720_defconfig
index 76096992f3c2..6ba91f425128 100644
--- a/configs/mvebu_espressobin-88f3720_defconfig
+++ b/configs/mvebu_espressobin-88f3720_defconfig
@@ -83,7 +83,6 @@ CONFIG_MVEBU_COMPHY_SUPPORT=y
  CONFIG_PINCTRL=y
  CONFIG_PINCTRL_ARMADA_37XX=y
  CONFIG_DM_REGULATOR_GPIO=y
-CONFIG_DEBUG_UART_ANNOUNCE=y
  CONFIG_MVEBU_A3700_UART=y
  CONFIG_MVEBU_A3700_SPI=y
  CONFIG_USB=y
diff --git a/configs/turris_mox_defconfig b/configs/turris_mox_defconfig
index 02a4687a14bc..195cebe765d0 100644
--- a/configs/turris_mox_defconfig
+++ b/configs/turris_mox_defconfig
@@ -93,7 +93,6 @@ CONFIG_DM_RTC=y
  CONFIG_RTC_DS1307=y
  CONFIG_SCSI=y
  CONFIG_DM_SCSI=y
-CONFIG_DEBUG_UART_ANNOUNCE=y
  CONFIG_MVEBU_A3700_UART=y
  CONFIG_MVEBU_A3700_SPI=y
  CONFIG_USB=y
diff --git a/configs/uDPU_defconfig b/configs/uDPU_defconfig
index bb1f14902290..7698e080e2a2 100644
--- a/configs/uDPU_defconfig
+++ b/configs/uDPU_defconfig
@@ -82,7 +82,6 @@ CONFIG_PINCTRL=y
  CONFIG_PINCTRL_ARMADA_37XX=y
  CONFIG_DM_REGULATOR_FIXED=y
  CONFIG_DM_REGULATOR_GPIO=y
-CONFIG_DEBUG_UART_ANNOUNCE=y
  CONFIG_MVEBU_A3700_UART=y
  CONFIG_MVEBU_A3700_SPI=y
  CONFIG_SYSINFO=y



Viele Grüße,
Stefan Roese

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

Please pull u-boot-marvell/master


Hi Tom,

please pull the next batch of mostly Marvell MVEBU related patches:


- fdt_support: Add fdt_for_each_node_by_compatible() helper macro (Marek)
- turris_omnia: Fixup SATA or PCIe nodes at runtime in DT blob (Pali)
- pci_mvebu: Add support for Kirkwood PCIe controllers (Pali)
- SPL: More verifications for kwbimage in SPL (Pali)
- mvebu: Remove comphy_update_map() (Pali)
- Minor misc stuff


Here the Azure build, without any issues:

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

Thanks,
Stefan

The following changes since commit 068415eadefbbc81f14d4ce61fcf7a7eb39650d4:

  Merge tag 'xilinx-for-v2022.04-rc1' of 
https://source.denx.de/u-boot/custodians/u-boot-microblaze (2022-01-19 
11:43:44 -0500)


are available in the Git repository at:

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

for you to fetch changes up to 8f880c3d89432e9988b23bb7099d6360c14a206f:

  arm: a37xx: Disable CONFIG_DEBUG_UART_ANNOUNCE (2022-01-20 14:46:03 
+0100)



Heinrich Schuchardt (1):
  drivers: octeon: get rid of Unicode in code

Marek Behún (5):
  fdt_support: Add fdt_for_each_node_by_compatible() helper macro
  arm: mvebu: spl: Print srcaddr in error message
  arm: mvebu: spl: Use preferred types u8/u16/u32 instead of uintN_t
  arm: mvebu: spl: Use IS_ENABLED() instead of #ifdef where possible
  arm: mvebu: spl: Fix 100 column exceeds

Pali Rohár (10):
  arm: mvebu: turris_omnia: Fixup SATA or PCIe nodes at runtime in 
DT blob

  pci: pci_mvebu: Add support for Kirkwood PCIe controllers
  arm: mvebu: Check that kwbimage offset and blocksize are valid
  SPL: Add struct spl_boot_device parameter into 
spl_parse_board_header()

  arm: mvebu: Check that kwbimage blockid matches boot mode
  SPL: Add support for checking board / BootROM specific image types
  arm: mvebu: Check for kwbimage data checksum
  arm: mvebu: turris_mox: Convert comphy_update_map() to 
board_fix_fdt()

  phy: marvell: Remove unused function comphy_update_map()
  arm: a37xx: Disable CONFIG_DEBUG_UART_ANNOUNCE

 arch/arm/cpu/armv8/fsl-layerscape/fdt.c |   9 +-
 arch/arm/cpu/armv8/fsl-layerscape/icid.c|   5 +-
 arch/arm/mach-kirkwood/cpu.c|   4 +-
 arch/arm/mach-kirkwood/include/mach/cpu.h   |   3 +
 arch/arm/mach-mvebu/spl.c   | 133 
+++-

 arch/arm/mach-sunxi/spl_spi_sunxi.c |   2 +-
 arch/arm/mach-tegra/gpu.c   |   5 +-
 arch/mips/mach-octeon/octeon_fdt.c  |  11 +--
 arch/powerpc/cpu/mpc85xx/liodn.c|   9 +-
 board/CZ.NIC/turris_mox/turris_mox.c|  48 --
 board/CZ.NIC/turris_omnia/turris_omnia.c|  91 ++-
 board/Marvell/octeon_ebb7304/board.c|   9 +-
 board/congatec/cgtqmx8/spl.c|   8 +-
 board/freescale/lx2160a/lx2160a.c   |   5 +-
 common/fdt_support.c|  22 ++---
 common/spl/spl.c|  13 ++-
 common/spl/spl_ext.c|   9 +-
 common/spl/spl_fat.c|  11 ++-
 common/spl/spl_legacy.c |   3 +-
 common/spl/spl_mmc.c|  43 +
 common/spl/spl_nand.c   |  13 +--
 common/spl/spl_net.c|   2 +-
 common/spl/spl_nor.c|   4 +-
 common/spl/spl_onenand.c|   2 +-
 common/spl/spl_ram.c|   2 +-
 common/spl/spl_sata.c   |   9 +-
 common/spl/spl_sdp.c|   2 +-
 common/spl/spl_spi.c|   9 +-
 common/spl/spl_ubi.c|   4 +-
 common/spl/spl_usb.c|   4 +-
 common/spl/spl_xip.c|   4 +-
 common/spl/spl_ymodem.c |   4 +-
 configs/mvebu_db-88f3720_defconfig  |   1 -
 configs/mvebu_espressobin-88f3720_defconfig |   1 -
 configs/turris_mox_defconfig|   1 -
 configs/turris_omnia_defconfig  |   1 +
 configs/uDPU_defconfig  |   1 -
 drivers/misc/fsl_portals.c  |   6 +-
 drivers/net/fm/fdt.c|   3 +-
 drivers/pci/Kconfig |   6 +-
 drivers/pci/pci_mvebu.c |  16 
 drivers/pci/pcie_layerscape_fixup_common.c  |  12 +--
 drivers/phy/marvell/comphy_a3700.c  |  12 +--
 drivers/phy/marvell/comphy_core.c   |   9 --
 drivers/phy/marvell/comphy_core.h   |   9 ++
 drivers/ram/octeon/octeon3_lmc.c|  34 +++
 drivers/usb/gadget/f_sdp.c  |  13 +--
 drivers/video/meson/simplefb_common.c   |   9 +-
 drivers/video/sunxi/simplefb_comm

Re: Pull request doc-2022-04-rc1

On Thu, Jan 20, 2022 at 08:23:24AM +0100, Heinrich Schuchardt wrote:

> Dear Tom,
> 
> I put the patch to replace @return by Return: in code comments into a
> separate pull request at it is touching so many files. As we have a lot of
> churn in U-Boot we have to put in the patch close after preparation
> otherwise rebasing will be an endless story.
> 
> Gitlab CI showed no issues:
> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/10699
> 
> The following changes since commit 6a685753ce8b6b02b67d64b239143bf19eda63c9:
> 
>   Merge branch '2022-01-18-platform-updates' (2022-01-18 16:07:33 -0500)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-efi.git
> tags/doc-2022-04-rc1
> 
> for you to fetch changes up to 185f812c419f1b4f0d10d9787d59cf9f11a2a600:
> 
>   doc: replace @return by Return: (2022-01-19 18:11:34 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PULL u-boot] Please pull u-boot-amlogic-20220120

On Thu, Jan 20, 2022 at 09:55:49AM +0100, Neil Armstrong wrote:

> Hi Tom,
> 
> Here's a few changes :
> - CONFIG_NET_RANDOM_ETHADDR cleanup for VIM3/L Android configs I missed
> - raw parts for bootloader to flash bootloader with fastboot with Android 
> configs
> - Add missing serial# like sei510/610 in order to satisfy fastboot
> 
> The CI job is at 
> https://source.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/10491
> 
> Thanks,
> Neil
> 
> The following changes since commit 068415eadefbbc81f14d4ce61fcf7a7eb39650d4:
> 
>   Merge tag 'xilinx-for-v2022.04-rc1' of 
> https://source.denx.de/u-boot/custodians/u-boot-microblaze (2022-01-19 
> 11:43:44 -0500)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-amlogic.git 
> tags/u-boot-amlogic-20220120
> 
> for you to fetch changes up to 09c2debab70271fdb3b1ff89e0e7d186502c548d:
> 
>   board: amlogic: vim3: configure serial# from ethaddr (2022-01-20 09:50:54 
> +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 00/11] Add support for SUNIV and F1C100s.

2022-01-20 Thread Chris Morgan

On Sat, Jan 15, 2022 at 04:02:05PM -0500, Jesse Taube wrote:
> 
> 
> On 1/10/22 00:13, Tnze Jdao wrote:
> > I tested this patch and tried to run it on my LicheePi Nano. It works, but 
> > I found there is WARNINGs when compile the code:
> > ---
> > include/configs/sunxi-common.h:128:0: warning: "CONFIG_ENV_SECT_SIZE" 
> > redefined
> >   #define CONFIG_ENV_SECT_SIZE 0x1000
> Ah I will move this it should be moved to defconfig thx for pointing this
> out.
> > 
> > In file included from ././include/linux/kconfig.h:4:0,
> >   from :0:
> > include/generated/autoconf.h:296:0: note: this is the location of the 
> > previous definition
> >   #define CONFIG_ENV_SECT_SIZE 0x1
> Not entirely sure how it got defined here, it doesn't get defined in my
> generated config.
> > 
> > In file included from include/configs/suniv.h:12:0,
> >   from include/config.h:4,
> >   from include/common.h:16,
> >   from lib/slre.c:24:
> > 
> > And I think the problem is the CONFIG_ENV_SECT_SIZE should be (and required 
> > to) defined in the config file rather than at 
> > include/configs/sunxi-common.h:128
> 
> Im sorry for the late reply the email got lost.

I have tested the patch on master (pulled 2022-01-20).
licheepi_nano_defconfig compiles and builds just fine for me, and I am
able to run it on the device without incident via FEL mode.

licheepi_nano_spiflash_defconfig however gives me multiple warnings,
and when the warnings are addressed it boots but gives me errors
regarding the SPI controller in U-Boot.

"make licheepi_nano_spiflash_defconfig" warning:
WARNING: unmet direct dependencies detected for SPI_MEM
  Depends on [n]: SPI [=n]
  Selected by [y]:
  - SPI_FLASH [=y]

When I specify CONFIG_SPI=y I get the following when I try to compile:
Environment Sector-Size (ENV_SECT_SIZE) [] (NEW)
When I provide a value of 0x1000 which corresponds to the block size
of the SPI chip I use I then get the following warnings repeated and it
fails to compile:
include/configs/sunxi-common.h:60: warning: "CONFIG_SYS_LOAD_ADDR" redefined

When I work through the remaining errors and get it to compile, I get
this error in U-Boot when attempting to use the SPI controller:
sun4i_spi spi@1c05000: failed to get ahb clock

I presume the issue is that the defconfig is both incomplete for the
SPI booting method and the SUN6I_SPI which is specified in the SPI
defconfig is not in mainline yet.

Until the SPI driver is present it's probably best to just drop the
licheepi_nano_spiflash_defconfig.

Tested-By: Chris Morgan

Re: [PATCH v3 31/31] RFC: Switch rpi over to use bootstd

Hi Mark,

On Thu, 20 Jan 2022 at 03:29, Mark Kettenis  wrote:
>
> > From: Michael Walle 
> > Date: Thu, 20 Jan 2022 09:35:44 +0100
> >
> > > The bootdevs have a natural priority, based on the assumed speed of
> > > the device, so the board would only need to intervene (with an env var
> > > or a devicetree property) when that is wrong.
> >
> > Does this make sense in general? The default boot order for a
> > board should depend on what is available on board (or on the
> > carrier board) and what is pluggable. I doubt there can be a sane
> > default, so almost all boards will have to define its own
> > boot order anyway.

Please can you be more specific about what you the problem is here? If
the board does not have a device then it will not exist in driver
model (or will not probe) and it won't have a bootdev (or it won't
probe). That seems to be equivalent to me.

> >
> > So it doesn't really matter how the general list is sorted, but
> > sorting by the speed of the interface sounds.. strange.
>
> From a security standpoint "removable" vs. "non-removable" is what
> really matters.  You don't really want someone to plug a usb key or
> SD card into your device and accidentally boot from it.

Yes, this should be easy enough to set up. From what I've seen so far,
people tend to put the MMC devices next to each other in priority,
with USB and network later.

But I still think having a sane default makes sense rather than making
every board do this explicitly.

>
> Also, changing the default boot order for an already supported device
> is probably going to cause problems.  Something to keep in mind when
> devices get converted to the new mechanism.

Well conversion is a different thing. We should be able to make sure
the order is the same as before, perhaps with a runtime check, e.g.
adding an env variable which provides the expected order.

Regards,
Simon

Re: [PATCH v3 00/31] Initial implementation of standard boot

Hi Michael,

On Thu, 20 Jan 2022 at 01:38, Michael Walle  wrote:
>
> Hi,
>
> Am 2022-01-19 15:56, schrieb Simon Glass:
> > On Wed, 19 Jan 2022 at 01:09, Michael Walle  wrote:
> >>
> >>
> >> > The bootflow feature provide a built-in way for U-Boot to automatically
> >> > boot an Operating System without custom scripting and other 
> >> > customisation.
> >> > This is called 'standard boot' since it provides a standard way for
> >> > U-Boot to boot a distro, without scripting.
> >> >
> >> > It introduces the following concepts:
> >> >
> >> >- bootdev - a device which can hold a distro
> >> >- bootmeth - a method to scan a bootdev to find bootflows (owned by
> >> > U-Boot)
> >> >- bootflow - a description of how to boot (owned by the distro)
> >> >
> >> > This series provides an implementation of these, enabled to scan for
> >> > bootflows from MMC, USB and Ethernet. It supports the existing distro
> >> > boot as well as the EFI loader flow (bootefi/bootmgr). It works
> >> > similiarly to the existing script-based approach, but is native to
> >> > U-Boot.
> >> >
> >> > With this we can boot on a Raspberry Pi 3 with just one command:
> >> >
> >> >bootflow scan -lb
> >> >
> >> > which means to scan, listing (-l) each bootflow and trying to boot each
> >> > one (-b). The final patch shows this.
> >>
> >> I wanted to give this a try, but I only get the following output:
> >>
> >> => setenv boot_targets usb0
> >> => bootflow scan -lb
> >> Scanning for bootflows in all bootdevs
> >> Seq  Method   State   UclassPart  Name
> >> Filename
> >> ---  ---  --      
> >> 
> >> Unknown seq 0 for label 'usb0'
> >> ---  ---  --      
> >> 
> >> (0 bootflows, 0 valid)
> >>
> >> where usb0 is a debian installation medium.
> >
> > Yes that's not working yet. Can you try an mmc device for testing?
>
> Ok thanks for confirming. Yes I can test with a sd card,
> but I'll probably do it when there is support for loading
> a device tree by the fdtfile.

Yes I need to look at that one.

Regards,
SImon

Re: [PATCH v3 31/31] RFC: Switch rpi over to use bootstd

On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote:
> Hi Mark,
> 
> On Thu, 20 Jan 2022 at 03:29, Mark Kettenis  wrote:
> >
> > > From: Michael Walle 
> > > Date: Thu, 20 Jan 2022 09:35:44 +0100
> > >
> > > > The bootdevs have a natural priority, based on the assumed speed of
> > > > the device, so the board would only need to intervene (with an env var
> > > > or a devicetree property) when that is wrong.
> > >
> > > Does this make sense in general? The default boot order for a
> > > board should depend on what is available on board (or on the
> > > carrier board) and what is pluggable. I doubt there can be a sane
> > > default, so almost all boards will have to define its own
> > > boot order anyway.
> 
> Please can you be more specific about what you the problem is here? If
> the board does not have a device then it will not exist in driver
> model (or will not probe) and it won't have a bootdev (or it won't
> probe). That seems to be equivalent to me.

So, I'm not sure how much of a problem it is, since the board can still
define the default probe order via environment.  But pick any random SoC
with more than 1 SD/MMC set of lines on the chip.  Youboard may put the
first as SD slot and second as eMMC and Myboard may do the opposite and
both are going to probe in the same order since it's the same chip.

That's what I think Mark is getting at with it not really making sense
to just rely on probe order as what to try.

-- 
Tom

signature.asc
Description: PGP signature

Re: [PATCH 00/11] Add support for SUNIV and F1C100s.

2022-01-20 Thread Jesse Taube





On 1/20/22 13:12, Chris Morgan wrote:

On Sat, Jan 15, 2022 at 04:02:05PM -0500, Jesse Taube wrote:



On 1/10/22 00:13, Tnze Jdao wrote:

I tested this patch and tried to run it on my LicheePi Nano. It works, but I 
found there is WARNINGs when compile the code:
---
include/configs/sunxi-common.h:128:0: warning: "CONFIG_ENV_SECT_SIZE" redefined
   #define CONFIG_ENV_SECT_SIZE 0x1000

Ah I will move this it should be moved to defconfig thx for pointing this
out.


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

Not entirely sure how it got defined here, it doesn't get defined in my
generated config.


In file included from include/configs/suniv.h:12:0,
   from include/config.h:4,
   from include/common.h:16,
   from lib/slre.c:24:

And I think the problem is the CONFIG_ENV_SECT_SIZE should be (and required to) 
defined in the config file rather than at include/configs/sunxi-common.h:128


Im sorry for the late reply the email got lost.


I have tested the patch on master (pulled 2022-01-20).
licheepi_nano_defconfig compiles and builds just fine for me, and I am
able to run it on the device without incident via FEL mode.

licheepi_nano_spiflash_defconfig however gives me multiple warnings,
and when the warnings are addressed it boots but gives me errors
regarding the SPI controller in U-Boot.

"make licheepi_nano_spiflash_defconfig" warning:
WARNING: unmet direct dependencies detected for SPI_MEM
   Depends on [n]: SPI [=n]
   Selected by [y]:
   - SPI_FLASH [=y]

When I specify CONFIG_SPI=y I get the following when I try to compile:
Environment Sector-Size (ENV_SECT_SIZE) [] (NEW)
When I provide a value of 0x1000 which corresponds to the block size
of the SPI chip I use I then get the following warnings repeated and it
fails to compile:
include/configs/sunxi-common.h:60: warning: "CONFIG_SYS_LOAD_ADDR" redefined

When I work through the remaining errors and get it to compile, I get
this error in U-Boot when attempting to use the SPI controller:
sun4i_spi spi@1c05000: failed to get ahb clock

I presume the issue is that the defconfig is both incomplete for the
SPI booting method and the SUN6I_SPI which is specified in the SPI
defconfig is not in mainline yet.

It has under a different name i have yet to make it work though.


Until the SPI driver is present it's probably best to just drop the
licheepi_nano_spiflash_defconfig.

Tested-By: Chris Morgan 

Thank you for testing!!

I will be fixing the issues brought up thx for the input.
The issues are DRAM using the device tree.
Clocks in the device tree.
Pinmuxing doesn't work for device tree.
And SPI boot.

Most of the issues im encountering stem from SUNXI being a mix of DT and 
non-DT code. which is frustrating to work with.


Thanks,
Jesse Taube.

Re: Please pull u-boot-marvell/master

On Thu, Jan 20, 2022 at 05:31:09PM +0100, Stefan Roese wrote:

> Hi Tom,
> 
> please pull the next batch of mostly Marvell MVEBU related patches:
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 1/1] efi_loader: correct function comment style

Replace @return and @param.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_file.c  |  2 +-
 lib/efi_loader/efi_freestanding.c  |  8 
 lib/efi_loader/efi_gop.c   |  2 +-
 lib/efi_loader/helloworld.c|  2 +-
 lib/efi_selftest/dtbdump.c |  2 +-
 lib/efi_selftest/efi_selftest.c|  4 ++--
 lib/efi_selftest/efi_selftest_bitblt.c |  6 +++---
 lib/efi_selftest/efi_selftest_block_device.c   |  6 +++---
 lib/efi_selftest/efi_selftest_config_table.c   |  4 ++--
 lib/efi_selftest/efi_selftest_console.c|  2 +-
 lib/efi_selftest/efi_selftest_crc32.c  |  4 ++--
 lib/efi_selftest/efi_selftest_devicepath_util.c|  2 +-
 lib/efi_selftest/efi_selftest_esrt.c   |  6 +++---
 lib/efi_selftest/efi_selftest_event_groups.c   |  4 ++--
 lib/efi_selftest/efi_selftest_events.c |  6 +++---
 lib/efi_selftest/efi_selftest_exception.c  |  4 ++--
 lib/efi_selftest/efi_selftest_exitbootservices.c   |  4 ++--
 lib/efi_selftest/efi_selftest_fdt.c|  4 ++--
 lib/efi_selftest/efi_selftest_gop.c|  6 +++---
 lib/efi_selftest/efi_selftest_hii.c|  4 ++--
 lib/efi_selftest/efi_selftest_load_file.c  |  6 +++---
 lib/efi_selftest/efi_selftest_loadimage.c  |  6 +++---
 lib/efi_selftest/efi_selftest_miniapp_exit.c   |  4 ++--
 lib/efi_selftest/efi_selftest_reset.c  |  4 ++--
 lib/efi_selftest/efi_selftest_rng.c|  4 ++--
 lib/efi_selftest/efi_selftest_rtc.c|  4 ++--
 .../efi_selftest_set_virtual_address_map.c |  4 ++--
 lib/efi_selftest/efi_selftest_snp.c|  8 
 lib/efi_selftest/efi_selftest_startimage_exit.c|  6 +++---
 lib/efi_selftest/efi_selftest_startimage_return.c  |  6 +++---
 lib/efi_selftest/efi_selftest_tcg2.c   |  4 ++--
 lib/efi_selftest/efi_selftest_textinput.c  |  4 ++--
 lib/efi_selftest/efi_selftest_textinputex.c|  6 +++---
 lib/efi_selftest/efi_selftest_textoutput.c |  2 +-
 lib/efi_selftest/efi_selftest_tpl.c|  6 +++---
 lib/efi_selftest/efi_selftest_unaligned.c  |  4 ++--
 lib/efi_selftest/efi_selftest_watchdog.c   | 10 +-
 lib/efi_selftest/initrddump.c  |  2 +-
 38 files changed, 86 insertions(+), 86 deletions(-)

diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index 6299fcbbf4..8d01f9ed84 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -1084,7 +1084,7 @@ static const struct efi_file_handle 
efi_file_handle_protocol = {
  * efi_file_from_path() - open file via device path
  *
  * @fp:device path
- * @return:EFI_FILE_PROTOCOL for the file or NULL
+ * Return: EFI_FILE_PROTOCOL for the file or NULL
  */
 struct efi_file_handle *efi_file_from_path(struct efi_device_path *fp)
 {
diff --git a/lib/efi_loader/efi_freestanding.c 
b/lib/efi_loader/efi_freestanding.c
index bd0dff162f..c85df026f0 100644
--- a/lib/efi_loader/efi_freestanding.c
+++ b/lib/efi_loader/efi_freestanding.c
@@ -97,8 +97,8 @@ void *memset(void *s, int c, size_t n)
  *
  * We do nothing here.
  *
- * @param func_ptr Pointer to function being entered
- * @param caller   Pointer to function which called this function
+ * func_ptr:   Pointer to function being entered
+ * caller: Pointer to function which called this function
  */
 void __attribute__((no_instrument_function))
 __cyg_profile_func_enter(void *func_ptr, void *caller)
@@ -113,8 +113,8 @@ __cyg_profile_func_enter(void *func_ptr, void *caller)
  *
  * We do nothing here.
  *
- * @param func_ptr Pointer to function being entered
- * @param caller   Pointer to function which called this function
+ * func_ptr:   Pointer to function being entered
+ * caller: Pointer to function which called this function
  */
 void __attribute__((no_instrument_function))
 __cyg_profile_func_exit(void *func_ptr, void *caller)
diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c
index 7683a34a96..2c81859807 100644
--- a/lib/efi_loader/efi_gop.c
+++ b/lib/efi_loader/efi_gop.c
@@ -407,7 +407,7 @@ out:
  * @width: width of rectangle
  * @height:height of rectangle
  * @delta: length in bytes of a line in the pixel buffer (optional)
- * @return:status code
+ * Return: status code
  */
 efi_status_t EFIAPI gop_blt(struct efi_gop *this, struct efi_gop_pixel *buffer,
u32 operation, efi_uintn_t sx,
diff --git a/lib/efi_loader/helloworld.c b/lib/efi_loader/helloworld.c
index 3f215e2a46..33e4fbc7c8 100644
--- a/lib/efi_loader/helloworld.c
+++ b/lib/efi_loader/helloworld.c
@@ -133,7

Re: [PATCH v3 31/31] RFC: Switch rpi over to use bootstd

2022-01-20 Thread Mark Kettenis

> Date: Thu, 20 Jan 2022 13:30:47 -0500
> From: Tom Rini 
> 
> On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote:
> > Hi Mark,
> > 
> > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis  wrote:
> > >
> > > > From: Michael Walle 
> > > > Date: Thu, 20 Jan 2022 09:35:44 +0100
> > > >
> > > > > The bootdevs have a natural priority, based on the assumed speed of
> > > > > the device, so the board would only need to intervene (with an env var
> > > > > or a devicetree property) when that is wrong.
> > > >
> > > > Does this make sense in general? The default boot order for a
> > > > board should depend on what is available on board (or on the
> > > > carrier board) and what is pluggable. I doubt there can be a sane
> > > > default, so almost all boards will have to define its own
> > > > boot order anyway.
> > 
> > Please can you be more specific about what you the problem is here? If
> > the board does not have a device then it will not exist in driver
> > model (or will not probe) and it won't have a bootdev (or it won't
> > probe). That seems to be equivalent to me.
> 
> So, I'm not sure how much of a problem it is, since the board can still
> define the default probe order via environment.  But pick any random SoC
> with more than 1 SD/MMC set of lines on the chip.  Youboard may put the
> first as SD slot and second as eMMC and Myboard may do the opposite and
> both are going to probe in the same order since it's the same chip.
> 
> That's what I think Mark is getting at with it not really making sense
> to just rely on probe order as what to try.

Something like that.  I remember a lot of issues when boards were
switched over to DM_MMC and the boot order changed.  I believe this
ended up beging solved by having aliases in the device tree.

Re: [PATCH v9 04/11] tools: mkeficapsule: add firmware image signing


On 1/18/22 05:39, AKASHI Takahiro wrote:

With this enhancement, mkeficapsule will be able to sign a capsule
file when it is created. A signature added will be used later
in the verification at FMP's SetImage() call.

To do that, we need specify additional command parameters:
   -monotonic-cout  : monotonic count
   -private-key  : private key file
   -certificate  : certificate file
Only when all of those parameters are given, a signature will be added
to a capsule file.

Users are expected to maintain and increment the monotonic count at
every time of the update for each firmware image.

Signed-off-by: AKASHI Takahiro 
Reviewed-by: Simon Glass 
Acked-by: Ilias Apalodimas 
---
  tools/Makefile   |   4 +
  tools/eficapsule.h   | 115 +
  tools/mkeficapsule.c | 398 +++
  3 files changed, 487 insertions(+), 30 deletions(-)
  create mode 100644 tools/eficapsule.h

diff --git a/tools/Makefile b/tools/Makefile
index 766c0674f4a0..afca08e2941a 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -238,6 +238,10 @@ hostprogs-$(CONFIG_MIPS) += mips-relocs
  hostprogs-$(CONFIG_ASN1_COMPILER) += asn1_compiler
  HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include

+ifeq ($(CONFIG_TOOLS_LIBCRYPTO),y)


This does not make sense.

You have put mkeficapsule.c under GPL-2.0. Nobody will be able to
distribute the tool compiled with OpenSSL.

According to the changelog only you and Sugosh have made contributions
that are copyrightable.

Either agree with Sughosh to change that license to be OpenSSL
compatible or drop this patch. The BSD license would work. Or you could
use libtls.


Once you have changed the license rethink if we really need the
CONFIG_TOOLS_LIBCRYPTO dependency.

Best regards

Heinrich



+HOSTLDLIBS_mkeficapsule += \
+   $(shell pkg-config --libs libssl libcrypto 2> /dev/null || echo "-lssl 
-lcrypto")
+endif
  hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule

  # We build some files with extra pedantic flags to try to minimize things
diff --git a/tools/eficapsule.h b/tools/eficapsule.h
new file mode 100644
index ..8c1560bb0671
--- /dev/null
+++ b/tools/eficapsule.h
@@ -0,0 +1,115 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2021 Linaro Limited
+ * Author: AKASHI Takahiro
+ *
+ * derived from efi.h and efi_api.h to make the file POSIX-compliant
+ */
+
+#ifndef _EFI_CAPSULE_H
+#define _EFI_CAPSULE_H
+
+#include 
+#include  /* WIN_CERTIFICATE */
+
+/*
+ * Gcc's predefined attributes are not recognized by clang.
+ */
+#ifndef __packed
+#define __packed   __attribute__((__packed__))
+#endif
+
+#ifndef __aligned
+#define __aligned(x)   __attribute__((__aligned__(x)))
+#endif
+
+typedef struct {
+   uint8_t b[16];
+} efi_guid_t __aligned(8);
+
+#define EFI_GUID(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) \
+   {{ (a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, \
+   ((a) >> 24) & 0xff, \
+   (b) & 0xff, ((b) >> 8) & 0xff, \
+   (c) & 0xff, ((c) >> 8) & 0xff, \
+   (d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7) } }
+
+#define EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID \
+   EFI_GUID(0x6dcbd5ed, 0xe82d, 0x4c44, 0xbd, 0xa1, \
+0x71, 0x94, 0x19, 0x9a, 0xd9, 0x2a)
+
+#define EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID \
+   EFI_GUID(0xae13ff2d, 0x9ad4, 0x4e25, 0x9a, 0xc8, \
+0x6d, 0x80, 0xb3, 0xb2, 0x21, 0x47)
+
+#define EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID \
+   EFI_GUID(0xe2bb9c06, 0x70e9, 0x4b14, 0x97, 0xa3, \
+0x5a, 0x79, 0x13, 0x17, 0x6e, 0x3f)
+
+#define EFI_CERT_TYPE_PKCS7_GUID \
+   EFI_GUID(0x4aafd29d, 0x68df, 0x49ee, 0x8a, 0xa9, \
+0x34, 0x7d, 0x37, 0x56, 0x65, 0xa7)
+
+/* flags */
+#define CAPSULE_FLAGS_PERSIST_ACROSS_RESET  0x0001
+
+struct efi_capsule_header {
+   efi_guid_t capsule_guid;
+   uint32_t header_size;
+   uint32_t flags;
+   uint32_t capsule_image_size;
+} __packed;
+
+struct efi_firmware_management_capsule_header {
+   uint32_t version;
+   uint16_t embedded_driver_count;
+   uint16_t payload_item_count;
+   uint32_t item_offset_list[];
+} __packed;
+
+/* image_capsule_support */
+#define CAPSULE_SUPPORT_AUTHENTICATION  0x0001
+
+struct efi_firmware_management_capsule_image_header {
+   uint32_t version;
+   efi_guid_t update_image_type_id;
+   uint8_t update_image_index;
+   uint8_t reserved[3];
+   uint32_t update_image_size;
+   uint32_t update_vendor_code_size;
+   uint64_t update_hardware_instance;
+   uint64_t image_capsule_support;
+} __packed;
+
+/**
+ * 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_t

[PATCH v2] xilinx: common: change bootm_size to not go beyond ram_top

2022-01-20 Thread Ricardo Salveti

The available ram can be limited by ram_top as that depends on the
reserved memory nodes provided by the device-tree (via
board_get_usable_ram_top), so make sure to respect ram_top when setting
up bootm_size to avoid overlapping reserved memory regions (e.g. memory
used by OP-TEE).

The same logic is available in env_get_bootm_size when bootm_size is
not defined by the default environment.

Signed-off-by: Ricardo Salveti 
---

Change in v2:
- Declare bootm_size based on ram top and base

 board/xilinx/common/board.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 78a5d0efa86..6fce23197a4 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -377,7 +377,7 @@ int board_late_init_xilinx(void)
u32 ret = 0;
int i, id, macid = 0;
struct xilinx_board_description *desc;
-   phys_size_t bootm_size = gd->ram_size;
+   phys_size_t bootm_size = gd->ram_top - gd->ram_base;
 
if (!CONFIG_IS_ENABLED(MICROBLAZE)) {
ulong scriptaddr;
-- 
2.34.1

Re: [PATCH v3 31/31] RFC: Switch rpi over to use bootstd

Hi Mark,

On Thu, 20 Jan 2022 at 11:56, Mark Kettenis  wrote:
>
> > Date: Thu, 20 Jan 2022 13:30:47 -0500
> > From: Tom Rini 
> >
> > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote:
> > > Hi Mark,
> > >
> > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis  
> > > wrote:
> > > >
> > > > > From: Michael Walle 
> > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100
> > > > >
> > > > > > The bootdevs have a natural priority, based on the assumed speed of
> > > > > > the device, so the board would only need to intervene (with an env 
> > > > > > var
> > > > > > or a devicetree property) when that is wrong.
> > > > >
> > > > > Does this make sense in general? The default boot order for a
> > > > > board should depend on what is available on board (or on the
> > > > > carrier board) and what is pluggable. I doubt there can be a sane
> > > > > default, so almost all boards will have to define its own
> > > > > boot order anyway.
> > >
> > > Please can you be more specific about what you the problem is here? If
> > > the board does not have a device then it will not exist in driver
> > > model (or will not probe) and it won't have a bootdev (or it won't
> > > probe). That seems to be equivalent to me.
> >
> > So, I'm not sure how much of a problem it is, since the board can still
> > define the default probe order via environment.  But pick any random SoC
> > with more than 1 SD/MMC set of lines on the chip.  Youboard may put the
> > first as SD slot and second as eMMC and Myboard may do the opposite and
> > both are going to probe in the same order since it's the same chip.
> >
> > That's what I think Mark is getting at with it not really making sense
> > to just rely on probe order as what to try.
>
> Something like that.  I remember a lot of issues when boards were
> switched over to DM_MMC and the boot order changed.  I believe this
> ended up beging solved by having aliases in the device tree.

The bootdevs use the same aliases so the ordering should remain the
same in that sense.

Regards,
Simon

Re: [PATCH v3 31/31] RFC: Switch rpi over to use bootstd

Hi Tom,

On Thu, 20 Jan 2022 at 11:30, Tom Rini  wrote:
>
> On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote:
> > Hi Mark,
> >
> > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis  wrote:
> > >
> > > > From: Michael Walle 
> > > > Date: Thu, 20 Jan 2022 09:35:44 +0100
> > > >
> > > > > The bootdevs have a natural priority, based on the assumed speed of
> > > > > the device, so the board would only need to intervene (with an env var
> > > > > or a devicetree property) when that is wrong.
> > > >
> > > > Does this make sense in general? The default boot order for a
> > > > board should depend on what is available on board (or on the
> > > > carrier board) and what is pluggable. I doubt there can be a sane
> > > > default, so almost all boards will have to define its own
> > > > boot order anyway.
> >
> > Please can you be more specific about what you the problem is here? If
> > the board does not have a device then it will not exist in driver
> > model (or will not probe) and it won't have a bootdev (or it won't
> > probe). That seems to be equivalent to me.
>
> So, I'm not sure how much of a problem it is, since the board can still
> define the default probe order via environment.  But pick any random SoC
> with more than 1 SD/MMC set of lines on the chip.  Youboard may put the
> first as SD slot and second as eMMC and Myboard may do the opposite and
> both are going to probe in the same order since it's the same chip.
>
> That's what I think Mark is getting at with it not really making sense
> to just rely on probe order as what to try.

Doesn't the 'non-removable' flag describe this feature of the hardware?

If you don't want to rely on the normal ordering, you can set the
boot_targets variable. I'd just like to avoid that being required for
'normal' boards and situations.

Regards,
Simon

Re: [PATCH v3 31/31] RFC: Switch rpi over to use bootstd

On Thu, Jan 20, 2022 at 12:56:55PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 20 Jan 2022 at 11:30, Tom Rini  wrote:
> >
> > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote:
> > > Hi Mark,
> > >
> > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis  
> > > wrote:
> > > >
> > > > > From: Michael Walle 
> > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100
> > > > >
> > > > > > The bootdevs have a natural priority, based on the assumed speed of
> > > > > > the device, so the board would only need to intervene (with an env 
> > > > > > var
> > > > > > or a devicetree property) when that is wrong.
> > > > >
> > > > > Does this make sense in general? The default boot order for a
> > > > > board should depend on what is available on board (or on the
> > > > > carrier board) and what is pluggable. I doubt there can be a sane
> > > > > default, so almost all boards will have to define its own
> > > > > boot order anyway.
> > >
> > > Please can you be more specific about what you the problem is here? If
> > > the board does not have a device then it will not exist in driver
> > > model (or will not probe) and it won't have a bootdev (or it won't
> > > probe). That seems to be equivalent to me.
> >
> > So, I'm not sure how much of a problem it is, since the board can still
> > define the default probe order via environment.  But pick any random SoC
> > with more than 1 SD/MMC set of lines on the chip.  Youboard may put the
> > first as SD slot and second as eMMC and Myboard may do the opposite and
> > both are going to probe in the same order since it's the same chip.
> >
> > That's what I think Mark is getting at with it not really making sense
> > to just rely on probe order as what to try.
> 
> Doesn't the 'non-removable' flag describe this feature of the hardware?
> 
> If you don't want to rely on the normal ordering, you can set the
> boot_targets variable. I'd just like to avoid that being required for
> 'normal' boards and situations.

I think setting things via the environment to have correct defaults is a
must.  I mean, yes, OK, if there's some device tree binding that we can
use that describes this, sure, that's choice A.  But choice B would
probably be environment strings.  Probe and hope is choice C, or more
like last resort, imho.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 31/31] RFC: Switch rpi over to use bootstd

Hi Tom,

On Thu, 20 Jan 2022 at 13:08, Tom Rini  wrote:
>
> On Thu, Jan 20, 2022 at 12:56:55PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 20 Jan 2022 at 11:30, Tom Rini  wrote:
> > >
> > > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote:
> > > > Hi Mark,
> > > >
> > > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis  
> > > > wrote:
> > > > >
> > > > > > From: Michael Walle 
> > > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100
> > > > > >
> > > > > > > The bootdevs have a natural priority, based on the assumed speed 
> > > > > > > of
> > > > > > > the device, so the board would only need to intervene (with an 
> > > > > > > env var
> > > > > > > or a devicetree property) when that is wrong.
> > > > > >
> > > > > > Does this make sense in general? The default boot order for a
> > > > > > board should depend on what is available on board (or on the
> > > > > > carrier board) and what is pluggable. I doubt there can be a sane
> > > > > > default, so almost all boards will have to define its own
> > > > > > boot order anyway.
> > > >
> > > > Please can you be more specific about what you the problem is here? If
> > > > the board does not have a device then it will not exist in driver
> > > > model (or will not probe) and it won't have a bootdev (or it won't
> > > > probe). That seems to be equivalent to me.
> > >
> > > So, I'm not sure how much of a problem it is, since the board can still
> > > define the default probe order via environment.  But pick any random SoC
> > > with more than 1 SD/MMC set of lines on the chip.  Youboard may put the
> > > first as SD slot and second as eMMC and Myboard may do the opposite and
> > > both are going to probe in the same order since it's the same chip.
> > >
> > > That's what I think Mark is getting at with it not really making sense
> > > to just rely on probe order as what to try.
> >
> > Doesn't the 'non-removable' flag describe this feature of the hardware?
> >
> > If you don't want to rely on the normal ordering, you can set the
> > boot_targets variable. I'd just like to avoid that being required for
> > 'normal' boards and situations.
>
> I think setting things via the environment to have correct defaults is a
> must.  I mean, yes, OK, if there's some device tree binding that we can
> use that describes this, sure, that's choice A.  But choice B would
> probably be environment strings.  Probe and hope is choice C, or more
> like last resort, imho.

Well the boot_targets var is implemented in this series.

The question is whether we force platforms to define it, or have a way
to handle things gracefully by default.

Regards,
Simon

Re: [RESEND PATCH v3 4/4] arm: kirkwood: Pogoplug V4 : Add board include header and defconfig files

Hi Stefan,

On Thu, Jan 20, 2022 at 3:55 AM Stefan Roese  wrote:
>
> Hi Tony,
>
> On 1/20/22 01:28, Tony Dinh wrote:
> > Add board include header and defconfig files for Pogoplug V4
> >
> > Signed-off-by: Tony Dinh 
> > ---
> >
> > Changes in v3:
> > - Migrate config symbols from board include header to defconfig
> > - Remove obsolete config symbols from header file
> > - Don't use ifdefs for unselectable config symbols in header file
> >
> > Changes in v2:
> > - Use canonical format for defconfig file
> >
> >   configs/pogo_v4_defconfig | 79 +++
> >   include/configs/pogo_v4.h | 56 +++
> >   2 files changed, 135 insertions(+)
> >   create mode 100644 configs/pogo_v4_defconfig
> >   create mode 100644 include/configs/pogo_v4.h
> >
> > diff --git a/configs/pogo_v4_defconfig b/configs/pogo_v4_defconfig
> > new file mode 100644
> > index 00..5490067b9e
> > --- /dev/null
> > +++ b/configs/pogo_v4_defconfig
> > @@ -0,0 +1,79 @@
> > +CONFIG_ARM=y
> > +CONFIG_SKIP_LOWLEVEL_INIT=y
> > +CONFIG_SYS_DCACHE_OFF=y
> > +CONFIG_ARCH_CPU_INIT=y
> > +CONFIG_SYS_THUMB_BUILD=y
> > +CONFIG_ARCH_KIRKWOOD=y
> > +CONFIG_SYS_KWD_CONFIG="board/cloudengines/pogo_v4/kwbimage.cfg"
> > +CONFIG_SYS_TEXT_BASE=0x60
> > +CONFIG_TARGET_POGO_V4=y
> > +CONFIG_ENV_SIZE=0x2
> > +CONFIG_ENV_OFFSET=0xC
> > +CONFIG_DEFAULT_DEVICE_TREE="kirkwood-pogoplug-series-4"
> > +CONFIG_IDENT_STRING="\nPogoplug V4"
> > +CONFIG_SYS_LOAD_ADDR=0x80
> > +CONFIG_BOOTSTAGE=y
> > +CONFIG_SHOW_BOOT_PROGRESS=y
> > +CONFIG_BOOTDELAY=10
> > +CONFIG_USE_BOOTCOMMAND=y
> > +CONFIG_BOOTCOMMAND="setenv bootargs ${bootargs_console}; run bootcmd_usb; 
> > bootm 0x0080 0x0110 0x2c0"
> > +CONFIG_USE_PREBOOT=y
> > +CONFIG_BOARD_LATE_INIT=y
> > +CONFIG_HUSH_PARSER=y
> > +CONFIG_SYS_PROMPT="Pogo_V4> "
> > +CONFIG_CMD_BOOTZ=y
> > +# CONFIG_BOOTM_PLAN9 is not set
> > +# CONFIG_BOOTM_RTEMS is not set
> > +# CONFIG_BOOTM_VXWORKS is not set
> > +# CONFIG_CMD_FLASH is not set
> > +CONFIG_CMD_MMC=y
> > +CONFIG_CMD_MTD=y
> > +CONFIG_CMD_NAND=y
> > +CONFIG_CMD_PCI=y
> > +CONFIG_CMD_SATA=y
> > +CONFIG_CMD_USB=y
> > +CONFIG_CMD_DHCP=y
> > +CONFIG_CMD_MII=y
> > +CONFIG_CMD_PING=y
> > +CONFIG_CMD_SNTP=y
> > +CONFIG_CMD_DNS=y
> > +CONFIG_CMD_EXT2=y
> > +CONFIG_CMD_EXT4=y
> > +CONFIG_CMD_FAT=y
> > +CONFIG_CMD_FS_GENERIC=y
> > +CONFIG_CMD_JFFS2=y
> > +CONFIG_CMD_MTDPARTS=y
> > +CONFIG_MTDIDS_DEFAULT="nand0=orion_nand"
> > +CONFIG_MTDPARTS_DEFAULT="mtdparts=orion_nand:2M(u-boot),3M(uImage),3M(uImage2),8M(failsafe),112M(root)"
> > +CONFIG_CMD_UBI=y
> > +CONFIG_ISO_PARTITION=y
> > +CONFIG_EFI_PARTITION=y
> > +CONFIG_PARTITION_TYPE_GUID=y
> > +CONFIG_OF_CONTROL=y
> > +CONFIG_ENV_OVERWRITE=y
> > +CONFIG_ENV_IS_IN_NAND=y
> > +CONFIG_VERSION_VARIABLE=y
> > +CONFIG_NET_RANDOM_ETHADDR=y
> > +CONFIG_NETCONSOLE=y
> > +CONFIG_DM=y
> > +CONFIG_SATA_MV=y
> > +CONFIG_KIRKWOOD_GPIO=y
> > +# CONFIG_MMC_HW_PARTITIONING is not set
> > +CONFIG_MVEBU_MMC=y
> > +CONFIG_MTD=y
> > +CONFIG_MTD_RAW_NAND=y
> > +CONFIG_DM_ETH=y
> > +CONFIG_MVGBE=y
> > +CONFIG_MII=y
> > +CONFIG_PCI=y
> > +CONFIG_PCI_MVEBU=y
> > +CONFIG_DM_RTC=y
> > +CONFIG_RTC_EMULATION=y
> > +CONFIG_SYS_NS16550=y
> > +CONFIG_USB=y
> > +CONFIG_USB_XHCI_HCD=y
> > +CONFIG_USB_XHCI_PCI=y
> > +CONFIG_USB_EHCI_HCD=y
> > +CONFIG_USB_STORAGE=y
> > +CONFIG_JFFS2_LZO=y
> > +CONFIG_JFFS2_NAND=y
> > diff --git a/include/configs/pogo_v4.h b/include/configs/pogo_v4.h
> > new file mode 100644
> > index 00..d94d49505a
> > --- /dev/null
> > +++ b/include/configs/pogo_v4.h
> > @@ -0,0 +1,56 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright (C) 2014-2022 Tony Dinh 
> > + *
> > + * Based on
> > + * Copyright (C) 2012
> > + * David Purdy 
> > + *
> > + * Based on Kirkwood support:
> > + * (C) Copyright 2009
> > + * Marvell Semiconductor 
> > + * Written-by: Prafulla Wadaskar 
> > + */
> > +
> > +#ifndef _CONFIG_POGO_V4_H
> > +#define _CONFIG_POGO_V4_H
> > +
> > +/*
> > + * mv-common.h should be defined after CMD configs since it used them
> > + * to enable certain macros
> > + */
> > +#include "mv-common.h"
> > +
> > +/*
> > + * Default environment variables
> > + */
> > +#define CONFIG_EXTRA_ENV_SETTINGS \
> > + "dtb_file=/boot/dts/" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
> > + "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0"\
> > + "mtdids=nand0=orion_nand\0"\
> > + "bootargs_console=console=ttyS0,115200\0" \
> > + "bootcmd_usb=usb start; load usb 0:1 0x0080 /boot/uImage; " \
> > + "load usb 0:1 0x0110 /boot/uInitrd; " \
> > + "load usb 0:1 0x2c0 $dtb_file\0"
> > +
> > +/*
> > + * Ethernet Driver configuration
> > + */
> > +#ifdef CONFIG_CMD_NET
>
> Will this ever be build without CONFIG_CMD_NET? If not, then please
> remove the #ifdef here as well.
>
> > +#define CONFIG_FEATURE_COMMAND_EDITING   /* for netconsole */
>
> And here the main problem:
>
> [stefan@ryzen u-boot-marvell (master)]$ make pogo_v4_defconfig
>

Re: [PATCH v3] drivers: spi-nor: Add JEDEC id for W25Q16JV

2022-01-20 Thread Dhananjay Phadke

On 1/20/2022 7:46 AM, tudor.amba...@microchip.com wrote:

FWIW, "w25q15jvm" would be the "correct" name in linux. Although for this
particular flash the name in linux is "w25q16jv-im/jm"..

would you fix it? :D

Anyhow, see [1] for a lengthy discussion on that name. That being said, I
still don't share Tudors opinion on using that made up name, just because
no one will find any flash if one searches for w25q16jvm in the internet.

The temperature range "I/J" is skipped in the name because it does not have
any influence on the jedec-id. That's why we don't include the "Package Type"
field in the naming convention as well.

Okay, I'm merging v3. let me know if you have any questions?

For now it should be fine. But if anyone is feeling brave enough maybe we should
fix the naming scheme for winbond once and for all. It seems that the flashes
were we append "m" support DTR, and in fact winbond names them blabla-dtr [1].
So instead of "w25q16jvm" maybe it's better to convert to "w25q16jv-dtr".
Are there any volunteers to check if my assumption is correct?

[1]
https://www.winbond.com/hq/product/code-storage-flash-memory/serial-nor-flash/?__locale=en&selected=128Mb#Density

I would be happy to do it if there's consensus that we can break
downstream device-tree users that hold older compatible string :-).

I thought of w25q512jv-dtr for my patch [1] but saw "m" suffix used for
other dtr parts.

On related note, that array can be sorted by Device ID.

[1]
https://lore.kernel.org/u-boot/0c3e4727-0997-a4c5-dab1-b09ea8781...@linux.microsoft.com/

Dhananjay

Re: [PATCH 2/8] net: ti: am65-cpsw: Add support for multi port independent MAC mode

2022-01-20 Thread Ramon Fried

On Mon, Jan 17, 2022 at 8:37 PM Tom Rini  wrote:
>
> On Fri, Dec 24, 2021 at 12:55:30PM +0530, Vignesh Raghavendra wrote:
>
> > On certain TI SoC, like AM64x there is a CPSW3G which supports 2
> > external independent MAC ports for single CPSW instance.
> > It is not possible for Ethernet driver to register more than one port
> > for given instance.
> >
> > This patch modifies top level CPSW NUSS as UCLASS_MISC and binds
> > UCLASS_ETH to individual ports so as to support bring up more than one
> > Ethernet interface in U-Boot.
> >
> > Note that there is no isolation in the since, CPSW NUSS is in promisc
> > mode and forwards all packets to host.
> >
> > Since top level driver is now UCLASS_MISC, board files would need to
> > instantiate this driver explicitly.
> >
> > Signed-off-by: Vignesh Raghavendra 
>
> Applied to u-boot/master, thanks!
why ? comments were not addressed.
>
> --
> Tom

[PATCH 1/3] net: xilinx: fix load access fault

From: Greentime Hu 

phy_connect() may fail by returning a NULL pointer. Thus,
axiemac_phy_init() should handle the case or we may get an access
fault when it tries to dereference it.

Signed-off-by: Greentime Hu 
Reviewed-by: Andy Chiu 
Signed-off-by: Andy Chiu 
---

 drivers/net/xilinx_axi_emac.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/xilinx_axi_emac.c b/drivers/net/xilinx_axi_emac.c
index 2ec76d0f52..3117dae05e 100644
--- a/drivers/net/xilinx_axi_emac.c
+++ b/drivers/net/xilinx_axi_emac.c
@@ -312,6 +312,10 @@ static int axiemac_phy_init(struct udevice *dev)
 
/* Interface - look at tsec */
phydev = phy_connect(priv->bus, priv->phyaddr, dev, priv->interface);
+   if (!phydev) {
+   printf("phy_connect failed\n");
+   return -ENODEV;
+   }
 
phydev->supported &= supported;
phydev->advertising = phydev->supported;
-- 
2.34.1

[PATCH 2/3] net: xilinx: Move setup of 1G MAC to a function

Separate the flow out so that it would be easiler to implement error
handling logic.

Signed-off-by: Andy Chiu 
---

 drivers/net/xilinx_axi_emac.c | 50 +--
 1 file changed, 30 insertions(+), 20 deletions(-)

diff --git a/drivers/net/xilinx_axi_emac.c b/drivers/net/xilinx_axi_emac.c
index 3117dae05e..dbda6c70d8 100644
--- a/drivers/net/xilinx_axi_emac.c
+++ b/drivers/net/xilinx_axi_emac.c
@@ -763,38 +763,48 @@ static int axiemac_miiphy_write(struct mii_dev *bus, int 
addr, int devad,
return phywrite(bus->priv, addr, reg, value);
 }
 
-static int axi_emac_probe(struct udevice *dev)
+static int axiemac_setup_emac(struct udevice *dev)
 {
struct axidma_plat *plat = dev_get_plat(dev);
struct eth_pdata *pdata = &plat->eth_pdata;
struct axidma_priv *priv = dev_get_priv(dev);
int ret;
 
+   priv->eth_hasnobuf = plat->eth_hasnobuf;
+   priv->phyaddr = plat->phyaddr;
+   priv->phy_of_handle = plat->phy_of_handle;
+   priv->interface = pdata->phy_interface;
+
+   priv->bus = mdio_alloc();
+   priv->bus->read = axiemac_miiphy_read;
+   priv->bus->write = axiemac_miiphy_write;
+   priv->bus->priv = priv;
+
+   ret = mdio_register_seq(priv->bus, dev_seq(dev));
+   if (ret)
+   return ret;
+
+   axiemac_phy_init(dev);
+
+   return ret;
+}
+
+static int axi_emac_probe(struct udevice *dev)
+{
+   struct axidma_plat *plat = dev_get_plat(dev);
+   struct eth_pdata *pdata = &plat->eth_pdata;
+   struct axidma_priv *priv = dev_get_priv(dev);
+
priv->iobase = (struct axi_regs *)pdata->iobase;
priv->dmatx = plat->dmatx;
/* RX channel offset is 0x30 */
priv->dmarx = (struct axidma_reg *)((phys_addr_t)priv->dmatx + 0x30);
priv->mactype = plat->mactype;
 
-   if (priv->mactype == EMAC_1G) {
-   priv->eth_hasnobuf = plat->eth_hasnobuf;
-   priv->phyaddr = plat->phyaddr;
-   priv->phy_of_handle = plat->phy_of_handle;
-   priv->interface = pdata->phy_interface;
-
-   priv->bus = mdio_alloc();
-   priv->bus->read = axiemac_miiphy_read;
-   priv->bus->write = axiemac_miiphy_write;
-   priv->bus->priv = priv;
-
-   ret = mdio_register_seq(priv->bus, dev_seq(dev));
-   if (ret)
-   return ret;
-
-   axiemac_phy_init(dev);
-   }
-
-   return 0;
+   if (priv->mactype == EMAC_1G)
+   return axiemac_setup_emac(dev);
+   else
+   return 0;
 }
 
 static int axi_emac_remove(struct udevice *dev)
-- 
2.34.1

[PATCH 3/3] net: xilinx: Force a probe failure if it cannot setup phy

Or we may get load access faults afterward.

The `phydev` field on axi-ethernet’s private struct is not set on a
failed phy_connect():

axi_emac_probe()
=> axiemac_phy_init()
   => priv->phydev = phy_connect() <--- may fail

However, all of the following calls on `axi_emac_ops` assume a valid
`phydev` pointer. For example:

axiemac_start()
=> setup_phy()
   => phy_startup()
  => if (phydev->drv->startup) <--- deref of phydev
   return phydev->drv->startup(phydev);

Thus, it would be better to fail at the driver probe and let u-boot
handle the rest (e.g. probe the driver again if needed), rather than
having access faults.

Signed-off-by: Andy Chiu 
Reviewed-by: Greentime Hu 
---

 drivers/net/xilinx_axi_emac.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/net/xilinx_axi_emac.c b/drivers/net/xilinx_axi_emac.c
index dbda6c70d8..08322aff88 100644
--- a/drivers/net/xilinx_axi_emac.c
+++ b/drivers/net/xilinx_axi_emac.c
@@ -782,10 +782,16 @@ static int axiemac_setup_emac(struct udevice *dev)
 
ret = mdio_register_seq(priv->bus, dev_seq(dev));
if (ret)
-   return ret;
+   goto fail;
 
-   axiemac_phy_init(dev);
+   ret = axiemac_phy_init(dev);
+   if (ret)
+   goto fail_free_mdio;
 
+fail_free_mdio:
+   mdio_unregister(priv->bus);
+   mdio_free(priv->bus);
+fail:
return ret;
 }
 
-- 
2.34.1

[PATCH] net: xilinx: fix the wrong dma base address issue

From: Greentime Hu 

If we just use fdtdec_get_addr_size_fixed to get "reg" it will use
64bit address cell to get the base address.

soc {
   #address-cells = <1>;
   #size-cells = <1>;
   compatible ="SiFive,FU500-soc", "fu500-soc", "sifive-soc", "simple-bus";
   ranges;
   L28: axidma@3001 {
   #dma-cells = <1>;
   compatible = "xlnx,axi-dma-1.00.a";
   axistream-connected = <&L27>;
   axistream-control-connected = <&L27>;
   clocks = <&L1>;
   interrupt-parent = <&L6>;
   interrupts = <32 33>;
   reg = <0x3001 0x4000>;

fdtdec_get_addr_size_fixed: reg: addr=30014000

We should get the base address through its parent's address-cells and
size-cells settings. So we should use fdtdec_get_addr_size_auto_parent()
to get correct base address.

After applying this patch, we can get the correct base address of dma by
replacing fdtdec_get_addr_size_fixed() with
fdtdec_get_addr_size_auto_parent().

fdtdec_get_addr_size_auto_parent:
 na=1, ns=1, fdtdec_get_addr_size_fixed: reg: addr=3001

Signed-off-by: Greentime Hu 
Signed-off-by: Andy Chiu 
---

 drivers/net/xilinx_axi_emac.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/xilinx_axi_emac.c b/drivers/net/xilinx_axi_emac.c
index 2ec76d0f52..f21addb4d0 100644
--- a/drivers/net/xilinx_axi_emac.c
+++ b/drivers/net/xilinx_axi_emac.c
@@ -832,8 +832,8 @@ static int axi_emac_of_to_plat(struct udevice *dev)
printf("%s: axistream is not found\n", __func__);
return -EINVAL;
}
-   plat->dmatx = (struct axidma_reg *)fdtdec_get_addr(gd->fdt_blob,
- offset, "reg");
+   plat->dmatx = (struct axidma_reg *)fdtdec_get_addr_size_auto_parent
+ (gd->fdt_blob, 0, offset, "reg", 0, NULL, false);
if (!plat->dmatx) {
printf("%s: axi_dma register space not found\n", __func__);
return -EINVAL;
-- 
2.34.1

Re: [PATCH 2/8] net: ti: am65-cpsw: Add support for multi port independent MAC mode

On Fri, Jan 21, 2022 at 01:13:54AM +0200, Ramon Fried wrote:
> On Mon, Jan 17, 2022 at 8:37 PM Tom Rini  wrote:
> >
> > On Fri, Dec 24, 2021 at 12:55:30PM +0530, Vignesh Raghavendra wrote:
> >
> > > On certain TI SoC, like AM64x there is a CPSW3G which supports 2
> > > external independent MAC ports for single CPSW instance.
> > > It is not possible for Ethernet driver to register more than one port
> > > for given instance.
> > >
> > > This patch modifies top level CPSW NUSS as UCLASS_MISC and binds
> > > UCLASS_ETH to individual ports so as to support bring up more than one
> > > Ethernet interface in U-Boot.
> > >
> > > Note that there is no isolation in the since, CPSW NUSS is in promisc
> > > mode and forwards all packets to host.
> > >
> > > Since top level driver is now UCLASS_MISC, board files would need to
> > > instantiate this driver explicitly.
> > >
> > > Signed-off-by: Vignesh Raghavendra 
> >
> > Applied to u-boot/master, thanks!
> why ? comments were not addressed.

I missed that you had comments, sorry.  Shall I revert this one for now?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 31/31] RFC: Switch rpi over to use bootstd

On Thu, Jan 20, 2022 at 01:47:41PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 20 Jan 2022 at 13:08, Tom Rini  wrote:
> >
> > On Thu, Jan 20, 2022 at 12:56:55PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 20 Jan 2022 at 11:30, Tom Rini  wrote:
> > > >
> > > > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote:
> > > > > Hi Mark,
> > > > >
> > > > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis  
> > > > > wrote:
> > > > > >
> > > > > > > From: Michael Walle 
> > > > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100
> > > > > > >
> > > > > > > > The bootdevs have a natural priority, based on the assumed 
> > > > > > > > speed of
> > > > > > > > the device, so the board would only need to intervene (with an 
> > > > > > > > env var
> > > > > > > > or a devicetree property) when that is wrong.
> > > > > > >
> > > > > > > Does this make sense in general? The default boot order for a
> > > > > > > board should depend on what is available on board (or on the
> > > > > > > carrier board) and what is pluggable. I doubt there can be a sane
> > > > > > > default, so almost all boards will have to define its own
> > > > > > > boot order anyway.
> > > > >
> > > > > Please can you be more specific about what you the problem is here? If
> > > > > the board does not have a device then it will not exist in driver
> > > > > model (or will not probe) and it won't have a bootdev (or it won't
> > > > > probe). That seems to be equivalent to me.
> > > >
> > > > So, I'm not sure how much of a problem it is, since the board can still
> > > > define the default probe order via environment.  But pick any random SoC
> > > > with more than 1 SD/MMC set of lines on the chip.  Youboard may put the
> > > > first as SD slot and second as eMMC and Myboard may do the opposite and
> > > > both are going to probe in the same order since it's the same chip.
> > > >
> > > > That's what I think Mark is getting at with it not really making sense
> > > > to just rely on probe order as what to try.
> > >
> > > Doesn't the 'non-removable' flag describe this feature of the hardware?
> > >
> > > If you don't want to rely on the normal ordering, you can set the
> > > boot_targets variable. I'd just like to avoid that being required for
> > > 'normal' boards and situations.
> >
> > I think setting things via the environment to have correct defaults is a
> > must.  I mean, yes, OK, if there's some device tree binding that we can
> > use that describes this, sure, that's choice A.  But choice B would
> > probably be environment strings.  Probe and hope is choice C, or more
> > like last resort, imho.
> 
> Well the boot_targets var is implemented in this series.
> 
> The question is whether we force platforms to define it, or have a way
> to handle things gracefully by default.

I think we need to force it to be defined until / unless there's some
agreed on standard to provide that information at run time.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 31/31] RFC: Switch rpi over to use bootstd

Hi Tom,

On Thu, 20 Jan 2022 at 16:23, Tom Rini  wrote:
>
> On Thu, Jan 20, 2022 at 01:47:41PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 20 Jan 2022 at 13:08, Tom Rini  wrote:
> > >
> > > On Thu, Jan 20, 2022 at 12:56:55PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 20 Jan 2022 at 11:30, Tom Rini  wrote:
> > > > >
> > > > > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote:
> > > > > > Hi Mark,
> > > > > >
> > > > > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis 
> > > > > >  wrote:
> > > > > > >
> > > > > > > > From: Michael Walle 
> > > > > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100
> > > > > > > >
> > > > > > > > > The bootdevs have a natural priority, based on the assumed 
> > > > > > > > > speed of
> > > > > > > > > the device, so the board would only need to intervene (with 
> > > > > > > > > an env var
> > > > > > > > > or a devicetree property) when that is wrong.
> > > > > > > >
> > > > > > > > Does this make sense in general? The default boot order for a
> > > > > > > > board should depend on what is available on board (or on the
> > > > > > > > carrier board) and what is pluggable. I doubt there can be a 
> > > > > > > > sane
> > > > > > > > default, so almost all boards will have to define its own
> > > > > > > > boot order anyway.
> > > > > >
> > > > > > Please can you be more specific about what you the problem is here? 
> > > > > > If
> > > > > > the board does not have a device then it will not exist in driver
> > > > > > model (or will not probe) and it won't have a bootdev (or it won't
> > > > > > probe). That seems to be equivalent to me.
> > > > >
> > > > > So, I'm not sure how much of a problem it is, since the board can 
> > > > > still
> > > > > define the default probe order via environment.  But pick any random 
> > > > > SoC
> > > > > with more than 1 SD/MMC set of lines on the chip.  Youboard may put 
> > > > > the
> > > > > first as SD slot and second as eMMC and Myboard may do the opposite 
> > > > > and
> > > > > both are going to probe in the same order since it's the same chip.
> > > > >
> > > > > That's what I think Mark is getting at with it not really making sense
> > > > > to just rely on probe order as what to try.
> > > >
> > > > Doesn't the 'non-removable' flag describe this feature of the hardware?
> > > >
> > > > If you don't want to rely on the normal ordering, you can set the
> > > > boot_targets variable. I'd just like to avoid that being required for
> > > > 'normal' boards and situations.
> > >
> > > I think setting things via the environment to have correct defaults is a
> > > must.  I mean, yes, OK, if there's some device tree binding that we can
> > > use that describes this, sure, that's choice A.  But choice B would
> > > probably be environment strings.  Probe and hope is choice C, or more
> > > like last resort, imho.
> >
> > Well the boot_targets var is implemented in this series.
> >
> > The question is whether we force platforms to define it, or have a way
> > to handle things gracefully by default.
>
> I think we need to force it to be defined until / unless there's some
> agreed on standard to provide that information at run time.

Well we can do that with a cut-down distro header with some macros, I suppose?

Regards,
Simon

Re: [PATCH v3 31/31] RFC: Switch rpi over to use bootstd

On Thu, Jan 20, 2022 at 05:59:53PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 20 Jan 2022 at 16:23, Tom Rini  wrote:
> >
> > On Thu, Jan 20, 2022 at 01:47:41PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 20 Jan 2022 at 13:08, Tom Rini  wrote:
> > > >
> > > > On Thu, Jan 20, 2022 at 12:56:55PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 20 Jan 2022 at 11:30, Tom Rini  wrote:
> > > > > >
> > > > > > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote:
> > > > > > > Hi Mark,
> > > > > > >
> > > > > > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > > From: Michael Walle 
> > > > > > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100
> > > > > > > > >
> > > > > > > > > > The bootdevs have a natural priority, based on the assumed 
> > > > > > > > > > speed of
> > > > > > > > > > the device, so the board would only need to intervene (with 
> > > > > > > > > > an env var
> > > > > > > > > > or a devicetree property) when that is wrong.
> > > > > > > > >
> > > > > > > > > Does this make sense in general? The default boot order for a
> > > > > > > > > board should depend on what is available on board (or on the
> > > > > > > > > carrier board) and what is pluggable. I doubt there can be a 
> > > > > > > > > sane
> > > > > > > > > default, so almost all boards will have to define its own
> > > > > > > > > boot order anyway.
> > > > > > >
> > > > > > > Please can you be more specific about what you the problem is 
> > > > > > > here? If
> > > > > > > the board does not have a device then it will not exist in driver
> > > > > > > model (or will not probe) and it won't have a bootdev (or it won't
> > > > > > > probe). That seems to be equivalent to me.
> > > > > >
> > > > > > So, I'm not sure how much of a problem it is, since the board can 
> > > > > > still
> > > > > > define the default probe order via environment.  But pick any 
> > > > > > random SoC
> > > > > > with more than 1 SD/MMC set of lines on the chip.  Youboard may put 
> > > > > > the
> > > > > > first as SD slot and second as eMMC and Myboard may do the opposite 
> > > > > > and
> > > > > > both are going to probe in the same order since it's the same chip.
> > > > > >
> > > > > > That's what I think Mark is getting at with it not really making 
> > > > > > sense
> > > > > > to just rely on probe order as what to try.
> > > > >
> > > > > Doesn't the 'non-removable' flag describe this feature of the 
> > > > > hardware?
> > > > >
> > > > > If you don't want to rely on the normal ordering, you can set the
> > > > > boot_targets variable. I'd just like to avoid that being required for
> > > > > 'normal' boards and situations.
> > > >
> > > > I think setting things via the environment to have correct defaults is a
> > > > must.  I mean, yes, OK, if there's some device tree binding that we can
> > > > use that describes this, sure, that's choice A.  But choice B would
> > > > probably be environment strings.  Probe and hope is choice C, or more
> > > > like last resort, imho.
> > >
> > > Well the boot_targets var is implemented in this series.
> > >
> > > The question is whether we force platforms to define it, or have a way
> > > to handle things gracefully by default.
> >
> > I think we need to force it to be defined until / unless there's some
> > agreed on standard to provide that information at run time.
> 
> Well we can do that with a cut-down distro header with some macros, I suppose?

Sorry?  I mean, when I said standard above, and since you had mentioned
from the device tree before (I thought..) I mean get some property
defined and accepted and use that for first best path.  Then keep using
boot_targets and make sure it's documented (and in help, etc) that
boards should define that in their default environment for a preferred
fallback default boot order.  The final fall back of "probe and guess"
might need an off switch for securing systems, I'm not sure.

-- 
Tom


signature.asc
Description: PGP signature

Re: [RFC PATCH 10/14] FWU: Reboot soon after successfully install the new firmware

2022-01-20 Thread AKASHI Takahiro

On Fri, Jan 21, 2022 at 12:31:00AM +0900, Masami Hiramatsu wrote:
> Reboot to the trial state soon after successfully installing
> the new firmware to the next bank and updating the active_index.
> This is enabled by CONFIG_FWU_REBOOT_AFTER_UPDATE and is a
> recommended option.

EFI_CAPSULE_HEADER.Flags may have a flag, CAPSULE_FLAGS_INITIATE_RESET.
See Section "8.5.3 Update Capsule" in the UEFI specification.

I think that we'd better implement the feature rather than adding
CONFIG_FWU_REBOOT_AFTER_UPDATE.

-Takahiro Akashi

> Signed-off-by: Masami Hiramatsu 
> ---
>  lib/efi_loader/efi_capsule.c |   10 --
>  lib/fwu_updates/Kconfig  |9 +
>  2 files changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> index 83c89a0cbb..0928425b5f 100644
> --- a/lib/efi_loader/efi_capsule.c
> +++ b/lib/efi_loader/efi_capsule.c
> @@ -1355,10 +1355,16 @@ efi_status_t efi_launch_capsules(void)
>   } else {
>   log_debug("Successfully updated the 
> active_index\n");
>   status = fwu_trial_state_ctr_start();
> - if (status < 0)
> + if (status < 0) {
>   ret = EFI_DEVICE_ERROR;
> - else
> + } else {
>   ret = EFI_SUCCESS;
> + if 
> (IS_ENABLED(CONFIG_FWU_REBOOT_AFTER_UPDATE)) {
> + log_info("New firmware is 
> installed in bank#%d. Reboot from that bank.\n",
> +  update_index);
> + do_reset(NULL, 0, 0, NULL);
> + }
> + }
>   }
>   } else if (capsule_update == true && update_status == false) {
>   log_err("All capsules were not updated. Not updating 
> FWU metadata\n");
> diff --git a/lib/fwu_updates/Kconfig b/lib/fwu_updates/Kconfig
> index 6de28e0c9c..0940a90747 100644
> --- a/lib/fwu_updates/Kconfig
> +++ b/lib/fwu_updates/Kconfig
> @@ -29,3 +29,12 @@ config FWU_TRIAL_STATE_CNT
> With FWU Multi Bank Update feature enabled, number of times
> the platform is allowed to boot in Trial State after an
> update.
> +
> +config FWU_REBOOT_AFTER_UPDATE
> + bool "Reboot soon after installing new firmware"
> + depends on FWU_MULTI_BANK_UPDATE
> + default y
> + help
> +   Reboot the machine soon after installing a new firmware
> +   and start trial boot. You can disable this option for
> +   debugging or FWU development, but recommended to enable it.
>

[PATCH v4 0/4] arm: kirkwood: Add support for Pogoplug V4



Pogoplug V4 specifications:

Kirkwood 88F6192 SoC
800 MHz CPU
1Gbs Ethernet
128 MB RAM
128 MB NAND
1x USB 2.0
2x USB 3.0 (on PCIe bus)
1 SDHC slot
1x External SATA port (USM enclosure form factor slot)


Changes in v4:
- Remove CONFIG_FEATURE_COMMAND_EDITING and ifdefs for CMD_NET
in include header

Changes in v3:
- Migrate symbols from board include header to Kconfig
- Squash board file small patches into one patch
- Migrate config symbols from board include header to defconfig
- Remove obsolete config symbols from header file
- Don't use ifdefs for unselectable config symbols in header file

Changes in v2:
- Use mainline Linux DTS version
- Move constants to .c file and remove header file
- Use canonical format for defconfig file

Tony Dinh (4):
  arm: kirkwood: Pogoplug-V4 : Add DTS files
  arm: kirkwood: Pogoplug-V4 : Add Kconfig files
  arm: kirkwood: Pogoplug-V4 : Add board implementation files
  arm: kirkwood: Pogoplug V4 : Add board include header and defconfig
files

 arch/arm/dts/Makefile   |   1 +
 arch/arm/dts/kirkwood-pogoplug-series-4.dts | 180 
 arch/arm/mach-kirkwood/Kconfig  |   6 +
 board/cloudengines/pogo_v4/Kconfig  |  16 ++
 board/cloudengines/pogo_v4/MAINTAINERS  |   6 +
 board/cloudengines/pogo_v4/Makefile |  10 +
 board/cloudengines/pogo_v4/kwbimage.cfg | 148 +
 board/cloudengines/pogo_v4/pogo_v4.c| 220 
 configs/pogo_v4_defconfig   |  79 +++
 include/configs/pogo_v4.h   |  53 +
 10 files changed, 719 insertions(+)
 create mode 100644 arch/arm/dts/kirkwood-pogoplug-series-4.dts
 create mode 100644 board/cloudengines/pogo_v4/Kconfig
 create mode 100644 board/cloudengines/pogo_v4/MAINTAINERS
 create mode 100644 board/cloudengines/pogo_v4/Makefile
 create mode 100644 board/cloudengines/pogo_v4/kwbimage.cfg
 create mode 100644 board/cloudengines/pogo_v4/pogo_v4.c
 create mode 100644 configs/pogo_v4_defconfig
 create mode 100644 include/configs/pogo_v4.h

-- 
2.30.2

[PATCH v4 1/4] arm: kirkwood: Pogoplug-V4 : Add DTS files

Add DTS files for Pogoplug V4 board

Reviewed-by: Stefan Roese 
Signed-off-by: Tony Dinh 
---

(no changes since v2)

Changes in v2:
- Use mainline Linux DTS version

 arch/arm/dts/Makefile   |   1 +
 arch/arm/dts/kirkwood-pogoplug-series-4.dts | 180 
 2 files changed, 181 insertions(+)
 create mode 100644 arch/arm/dts/kirkwood-pogoplug-series-4.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 1b65e65eb8..ce33a4b52b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -71,6 +71,7 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += \
kirkwood-openrd-client.dtb \
kirkwood-openrd-ultimate.dtb \
kirkwood-pogo_e02.dtb \
+   kirkwood-pogoplug-series-4.dtb \
kirkwood-sheevaplug.dtb
 
 dtb-$(CONFIG_MACH_S900) += \
diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts 
b/arch/arm/dts/kirkwood-pogoplug-series-4.dts
new file mode 100644
index 00..5aa4669ae2
--- /dev/null
+++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * kirkwood-pogoplug-series-4.dts - Device tree file for PogoPlug Series 4
+ * inspired by the board files made by Kevin Mihelich for ArchLinux,
+ * and their DTS file.
+ *
+ * Copyright (C) 2015 Linus Walleij 
+ */
+
+/dts-v1/;
+
+#include "kirkwood.dtsi"
+#include "kirkwood-6192.dtsi"
+#include 
+
+/ {
+   model = "Cloud Engines PogoPlug Series 4";
+   compatible = "cloudengines,pogoplugv4", "marvell,kirkwood-88f6192",
+"marvell,kirkwood";
+
+   memory {
+   device_type = "memory";
+   reg = <0x 0x0800>;
+   };
+
+   chosen {
+   stdout-path = "uart0:115200n8";
+   };
+
+   gpio_keys {
+   compatible = "gpio-keys";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-0 = <&pmx_button_eject>;
+   pinctrl-names = "default";
+
+   eject {
+   debounce-interval = <50>;
+   wakeup-source;
+   linux,code = ;
+   label = "Eject Button";
+   gpios = <&gpio0 29 GPIO_ACTIVE_LOW>;
+   };
+   };
+
+   gpio-leds {
+   compatible = "gpio-leds";
+   pinctrl-0 = <&pmx_led_green &pmx_led_red>;
+   pinctrl-names = "default";
+
+   health {
+   label = "pogoplugv4:green:health";
+   gpios = <&gpio0 22 GPIO_ACTIVE_LOW>;
+   default-state = "on";
+   };
+   fault {
+   label = "pogoplugv4:red:fault";
+   gpios = <&gpio0 24 GPIO_ACTIVE_LOW>;
+   };
+   };
+};
+
+&pinctrl {
+   pmx_sata0: pmx-sata0 {
+   marvell,pins = "mpp21";
+   marvell,function = "sata0";
+   };
+
+   pmx_sata1: pmx-sata1 {
+   marvell,pins = "mpp20";
+   marvell,function = "sata1";
+   };
+
+   pmx_sdio_cd: pmx-sdio-cd {
+   marvell,pins = "mpp27";
+   marvell,function = "gpio";
+   };
+
+   pmx_sdio_wp: pmx-sdio-wp {
+   marvell,pins = "mpp28";
+   marvell,function = "gpio";
+   };
+
+   pmx_button_eject: pmx-button-eject {
+   marvell,pins = "mpp29";
+   marvell,function = "gpio";
+   };
+
+   pmx_led_green: pmx-led-green {
+   marvell,pins = "mpp22";
+   marvell,function = "gpio";
+   };
+
+   pmx_led_red: pmx-led-red {
+   marvell,pins = "mpp24";
+   marvell,function = "gpio";
+   };
+};
+
+&uart0 {
+   status = "okay";
+};
+
+/*
+ * This PCIE controller has a USB 3.0 XHCI controller at 1,0
+ */
+&pciec {
+   status = "okay";
+};
+
+&pcie0 {
+   status = "okay";
+};
+
+&sata {
+   status = "okay";
+   pinctrl-0 = <&pmx_sata0 &pmx_sata1>;
+   pinctrl-names = "default";
+   nr-ports = <1>;
+};
+
+&sdio {
+   status = "okay";
+   pinctrl-0 = <&pmx_sdio &pmx_sdio_cd &pmx_sdio_wp>;
+   pinctrl-names = "default";
+   cd-gpios = <&gpio0 27 GPIO_ACTIVE_LOW>;
+   wp-gpios = <&gpio0 28 GPIO_ACTIVE_HIGH>;
+};
+
+&nand {
+   /* 128 MiB of NAND flash */
+   chip-delay = <40>;
+   status = "okay";
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x 0x20>;
+   read-only;
+   };
+
+   partition@20 {
+   label = "uImage";
+   reg = <0x0020 0x30>;
+   };
+
+   partition@50 {
+   label = "uImage2";
+

[PATCH v4 2/4] arm: kirkwood: Pogoplug-V4 : Add Kconfig files

Add Kconfig files for Pogoplug V4 board

Signed-off-by: Tony Dinh 
---

(no changes since v3)

Changes in v3:
- Migrate symbols from board include header to Kconfig

 arch/arm/mach-kirkwood/Kconfig |  6 ++
 board/cloudengines/pogo_v4/Kconfig | 16 
 2 files changed, 22 insertions(+)
 create mode 100644 board/cloudengines/pogo_v4/Kconfig

diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index c060cc8546..382b836267 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -51,6 +51,11 @@ config TARGET_POGO_E02
select FEROCEON_88FR131
select KW88F6281
 
+config TARGET_POGO_V4
+   bool "Pogoplug V4 Board"
+   select FEROCEON_88FR131
+   select KW88F6192
+
 config TARGET_DNS325
bool "dns325 Board"
select FEROCEON_88FR131
@@ -123,6 +128,7 @@ source "board/Marvell/guruplug/Kconfig"
 source "board/Marvell/sheevaplug/Kconfig"
 source "board/buffalo/lsxl/Kconfig"
 source "board/cloudengines/pogo_e02/Kconfig"
+source "board/cloudengines/pogo_v4/Kconfig"
 source "board/d-link/dns325/Kconfig"
 source "board/iomega/iconnect/Kconfig"
 source "board/keymile/Kconfig"
diff --git a/board/cloudengines/pogo_v4/Kconfig 
b/board/cloudengines/pogo_v4/Kconfig
new file mode 100644
index 00..db3b76b4d4
--- /dev/null
+++ b/board/cloudengines/pogo_v4/Kconfig
@@ -0,0 +1,16 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# (C) Copyright 2014-2021 Tony Dinh 
+#
+if TARGET_POGO_V4
+
+config SYS_BOARD
+   default "pogo_v4"
+
+config SYS_VENDOR
+   default "cloudengines"
+
+config SYS_CONFIG_NAME
+   default "pogo_v4"
+
+endif
-- 
2.30.2

[PATCH v4 3/4] arm: kirkwood: Pogoplug-V4 : Add board implementation files

Note: currently the fdt_get_phy_addr function in this file is
duplicate in this board and many other Kirkwood boards
(eg. Sheevaplug, GoFlex Home, etc.). This function is being
factored out into common area by another patch. And because it
was written for flattree only, the patch is being rewritten to
use livetree calls.

Signed-off-by: Tony Dinh 
---

(no changes since v3)

Changes in v3:
- Squash board file small patches into one patch

Changes in v2:
- Move constants to .c file and remove header file

 board/cloudengines/pogo_v4/MAINTAINERS  |   6 +
 board/cloudengines/pogo_v4/Makefile |  10 ++
 board/cloudengines/pogo_v4/kwbimage.cfg | 148 
 board/cloudengines/pogo_v4/pogo_v4.c| 220 
 4 files changed, 384 insertions(+)
 create mode 100644 board/cloudengines/pogo_v4/MAINTAINERS
 create mode 100644 board/cloudengines/pogo_v4/Makefile
 create mode 100644 board/cloudengines/pogo_v4/kwbimage.cfg
 create mode 100644 board/cloudengines/pogo_v4/pogo_v4.c

diff --git a/board/cloudengines/pogo_v4/MAINTAINERS 
b/board/cloudengines/pogo_v4/MAINTAINERS
new file mode 100644
index 00..35fd7858b7
--- /dev/null
+++ b/board/cloudengines/pogo_v4/MAINTAINERS
@@ -0,0 +1,6 @@
+POGO_V4 BOARD
+M: Tony Dinh 
+S: Maintained
+F: board/cloudengines/pogo_v4/
+F: include/configs/pogo_v4.h
+F: configs/pogo_v4_defconfig
diff --git a/board/cloudengines/pogo_v4/Makefile 
b/board/cloudengines/pogo_v4/Makefile
new file mode 100644
index 00..511bf5ff7e
--- /dev/null
+++ b/board/cloudengines/pogo_v4/Makefile
@@ -0,0 +1,10 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# (C) Copyright 2014-2021 Tony Dinh 
+#
+# Based on
+# Marvell Semiconductor 
+# Written-by: Prafulla Wadaskar 
+#
+
+obj-y  := pogo_v4.o
diff --git a/board/cloudengines/pogo_v4/kwbimage.cfg 
b/board/cloudengines/pogo_v4/kwbimage.cfg
new file mode 100644
index 00..f6294fe313
--- /dev/null
+++ b/board/cloudengines/pogo_v4/kwbimage.cfg
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2012
+# David Purdy 
+#
+# Based on Kirkwood support:
+# (C) Copyright 2009
+# Marvell Semiconductor 
+# Written-by: Prafulla Wadaskar  marvell.com>
+
+# Boot Media configurations   (DONE)
+BOOT_FROM  nand
+NAND_ECC_MODE  default
+NAND_PAGE_SIZE 0x0800
+
+# SOC registers configuration using bootrom header extension
+# Maximum KWBIMAGE_MAX_CONFIG configurations allowed
+
+# Configure RGMII-0 interface pad voltage to 1.8V (SHOULD BE SAME)
+DATA 0xffd100e0 0x1b1b1b9b
+
+#Dram initalization for SINGLE x16 CL=3 @ 200MHz   (need CL=3 @ 200MHz?)
+DATA 0xffd01400 0x43000618 # DDR Configuration register
+# bit13-0:  0x200 (200 DDR2 clks refresh rate)
+# bit23-14: zero
+# bit24: 1= enable exit self refresh mode on DDR access
+# bit25: 1 required
+# bit29-26: zero
+# bit31-30: 01
+
+DATA 0xffd01404 0x34143000 # DDR Controller Control Low
+# bit 4:0=addr/cmd in smame cycle
+# bit 5:0=clk is driven during self refresh, we don't care for APX
+# bit 6:0=use recommended falling edge of clk for addr/cmd
+# bit14:0=input buffer always powered up
+# bit18:1=cpu lock transaction enabled
+# bit23-20: 3=recommended value for CL=3 and STARTBURST_DEL disabled bit31=0
+# bit27-24: 6= CL+3, STARTBURST sample stages, for freqs 400MHz, unbuffered 
DIMM
+# bit30-28: 3 required
+# bit31:0=no additional STARTBURST delay
+
+DATA 0xffd01408 0x11012227 # DDR Timing (Low) (active cycles value +1)
+# bit3-0:   TRAS lsbs
+# bit7-4:   TRCD
+# bit11- 8: TRP
+# bit15-12: TWR
+# bit19-16: TWTR
+# bit20:TRAS msb
+# bit23-21: 0x0
+# bit27-24: TRRD
+# bit31-28: TRTP
+
+DATA 0xffd0140c 0x0819 #  DDR Timing (High)
+# bit6-0:   TRFC
+# bit8-7:   TR2R
+# bit10-9:  TR2W
+# bit12-11: TW2W
+# bit31-13: zero required
+
+DATA 0xffd01410 0x0001 #  DDR Address Control  (changed to Dockstar 
vals)
+# bit1-0:   00, Cs0width=x16
+# bit3-2:   10, Cs0size=512Mb
+# bit5-4:   00, Cs2width=nonexistent
+# bit7-6:   00, Cs1size =nonexistent
+# bit9-8:   00, Cs2width=nonexistent
+# bit11-10: 00, Cs2size =nonexistent
+# bit13-12: 00, Cs3width=nonexistent
+# bit15-14: 00, Cs3size =nonexistent
+# bit16:0,  Cs0AddrSel
+# bit17:0,  Cs1AddrSel
+# bit18:0,  Cs2AddrSel
+# bit19:0,  Cs3AddrSel
+# bit31-20: 0 required
+
+DATA 0xffd01414 0x #  DDR Open Pages Control
+# bit0:0,  OpenPage enabled
+# bit31-1: 0 required
+
+DATA 0xffd01418 0x #  DDR Operation
+# bit3-0:   0x0, DDR cmd
+# bit31-4:  0 required
+
+DATA 0xffd0141c 0x0632 #  DDR Mode
+# bit2-0:   2, BurstLen=2 required
+# bit3: 0, BurstType=0 required
+# bit6-4:   4, CL=5(<= change to CL=3 ?)
+# bit7: 0, TestMode=0 normal
+# bit8: 0, DLL reset=0 normal
+# bit11-9:  6, auto-precharge write recovery 
+# bit12:0, PD must be zero
+# bit31-13: 0 required
+
+DATA 0xffd01420 0x0040 #  DDR Extended Mode
+# bit0:0,  DDR DLL enabled

[PATCH v4 4/4] arm: kirkwood: Pogoplug V4 : Add board include header and defconfig files

Add board include header and defconfig files for Pogoplug V4

Signed-off-by: Tony Dinh 
---

Changes in v4:
- Remove CONFIG_FEATURE_COMMAND_EDITING and ifdefs for CMD_NET
in include header

Changes in v3:
- Migrate config symbols from board include header to defconfig
- Remove obsolete config symbols from header file
- Don't use ifdefs for unselectable config symbols in header file

Changes in v2:
- Use canonical format for defconfig file

 configs/pogo_v4_defconfig | 79 +++
 include/configs/pogo_v4.h | 53 ++
 2 files changed, 132 insertions(+)
 create mode 100644 configs/pogo_v4_defconfig
 create mode 100644 include/configs/pogo_v4.h

diff --git a/configs/pogo_v4_defconfig b/configs/pogo_v4_defconfig
new file mode 100644
index 00..5490067b9e
--- /dev/null
+++ b/configs/pogo_v4_defconfig
@@ -0,0 +1,79 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_SYS_DCACHE_OFF=y
+CONFIG_ARCH_CPU_INIT=y
+CONFIG_SYS_THUMB_BUILD=y
+CONFIG_ARCH_KIRKWOOD=y
+CONFIG_SYS_KWD_CONFIG="board/cloudengines/pogo_v4/kwbimage.cfg"
+CONFIG_SYS_TEXT_BASE=0x60
+CONFIG_TARGET_POGO_V4=y
+CONFIG_ENV_SIZE=0x2
+CONFIG_ENV_OFFSET=0xC
+CONFIG_DEFAULT_DEVICE_TREE="kirkwood-pogoplug-series-4"
+CONFIG_IDENT_STRING="\nPogoplug V4"
+CONFIG_SYS_LOAD_ADDR=0x80
+CONFIG_BOOTSTAGE=y
+CONFIG_SHOW_BOOT_PROGRESS=y
+CONFIG_BOOTDELAY=10
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="setenv bootargs ${bootargs_console}; run bootcmd_usb; 
bootm 0x0080 0x0110 0x2c0"
+CONFIG_USE_PREBOOT=y
+CONFIG_BOARD_LATE_INIT=y
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_PROMPT="Pogo_V4> "
+CONFIG_CMD_BOOTZ=y
+# CONFIG_BOOTM_PLAN9 is not set
+# CONFIG_BOOTM_RTEMS is not set
+# CONFIG_BOOTM_VXWORKS is not set
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_MTD=y
+CONFIG_CMD_NAND=y
+CONFIG_CMD_PCI=y
+CONFIG_CMD_SATA=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_SNTP=y
+CONFIG_CMD_DNS=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_JFFS2=y
+CONFIG_CMD_MTDPARTS=y
+CONFIG_MTDIDS_DEFAULT="nand0=orion_nand"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=orion_nand:2M(u-boot),3M(uImage),3M(uImage2),8M(failsafe),112M(root)"
+CONFIG_CMD_UBI=y
+CONFIG_ISO_PARTITION=y
+CONFIG_EFI_PARTITION=y
+CONFIG_PARTITION_TYPE_GUID=y
+CONFIG_OF_CONTROL=y
+CONFIG_ENV_OVERWRITE=y
+CONFIG_ENV_IS_IN_NAND=y
+CONFIG_VERSION_VARIABLE=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_NETCONSOLE=y
+CONFIG_DM=y
+CONFIG_SATA_MV=y
+CONFIG_KIRKWOOD_GPIO=y
+# CONFIG_MMC_HW_PARTITIONING is not set
+CONFIG_MVEBU_MMC=y
+CONFIG_MTD=y
+CONFIG_MTD_RAW_NAND=y
+CONFIG_DM_ETH=y
+CONFIG_MVGBE=y
+CONFIG_MII=y
+CONFIG_PCI=y
+CONFIG_PCI_MVEBU=y
+CONFIG_DM_RTC=y
+CONFIG_RTC_EMULATION=y
+CONFIG_SYS_NS16550=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_PCI=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_STORAGE=y
+CONFIG_JFFS2_LZO=y
+CONFIG_JFFS2_NAND=y
diff --git a/include/configs/pogo_v4.h b/include/configs/pogo_v4.h
new file mode 100644
index 00..0c51343637
--- /dev/null
+++ b/include/configs/pogo_v4.h
@@ -0,0 +1,53 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2014-2022 Tony Dinh 
+ *
+ * Based on
+ * Copyright (C) 2012
+ * David Purdy 
+ *
+ * Based on Kirkwood support:
+ * (C) Copyright 2009
+ * Marvell Semiconductor 
+ * Written-by: Prafulla Wadaskar 
+ */
+
+#ifndef _CONFIG_POGO_V4_H
+#define _CONFIG_POGO_V4_H
+
+/*
+ * mv-common.h should be defined after CMD configs since it used them
+ * to enable certain macros
+ */
+#include "mv-common.h"
+
+/*
+ * Default environment variables
+ */
+#define CONFIG_EXTRA_ENV_SETTINGS \
+   "dtb_file=/boot/dts/" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
+   "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0"\
+   "mtdids=nand0=orion_nand\0"\
+   "bootargs_console=console=ttyS0,115200\0" \
+   "bootcmd_usb=usb start; load usb 0:1 0x0080 /boot/uImage; " \
+   "load usb 0:1 0x0110 /boot/uInitrd; " \
+   "load usb 0:1 0x2c0 $dtb_file\0"
+
+/*
+ * Ethernet Driver configuration
+ */
+#define CONFIG_MVGBE_PORTS {1, 0}  /* enable port 0 only */
+#define CONFIG_PHY_BASE_ADR0
+
+/*
+ *  SATA Driver configuration
+ */
+#define CONFIG_SYS_SATA_MAX_DEVICE 1
+
+/*
+ * Support large disk for SATA and USB
+ */
+#define CONFIG_SYS_64BIT_LBA
+#define CONFIG_LBA48
+
+#endif /* _CONFIG_POGO_V4_H */
-- 
2.30.2

Re: [PATCH 01/11] arm: arm926ej-s: start.S: port save_boot_params support from armv7 code

On Tue,  4 Jan 2022 19:34:58 -0500
Jesse Taube  wrote:

Hi,

> From: Icenowy Zheng 
> 
> The ARMv7 start code has support for saving some boot params at the
> entry point, which is used by some SoCs to return to BROM.
> 
> Port this to ARM926EJ-S start code.
> 
> Signed-off-by: Icenowy Zheng 
> Signed-off-by: Jesse Taube 

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  arch/arm/cpu/arm926ejs/start.S | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
> index 0afcc47aad..aca7793c57 100644
> --- a/arch/arm/cpu/arm926ejs/start.S
> +++ b/arch/arm/cpu/arm926ejs/start.S
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /*
>   *
> @@ -32,8 +33,13 @@
>   */
>  
>   .globl  reset
> + .globl  save_boot_params_ret
> + .type   save_boot_params_ret,%function
>  
>  reset:
> + /* Allow the board to save important registers */
> + b   save_boot_params
> +save_boot_params_ret:
>   /*
>* set the cpu to SVC32 mode
>*/
> @@ -110,3 +116,16 @@ flush_dcache:
>  #endif
>   mov pc, lr  /* back to my caller */
>  #endif /* CONFIG_IS_ENABLED(SKIP_LOWLEVEL_INIT) */
> +
> +/*
> + *
> + * void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3)
> + *   __attribute__((weak));
> + *
> + * Stack pointer is not yet initialized at this moment
> + * Don't save anything to stack even if compiled with -O0
> + *
> + */
> +WEAK(save_boot_params)
> + b   save_boot_params_ret/* back to my caller */
> +ENDPROC(save_boot_params)

Re: [PATCH 03/11] dt-bindings: clock: Add initial suniv headers

On Tue,  4 Jan 2022 19:35:00 -0500
Jesse Taube  wrote:

> From: Icenowy Zheng 
> 
> This commit introduces suniv dt-bindings headers needed for
> device tree files.
> 
> Signed-off-by: Icenowy Zheng 
> Signed-off-by: Jesse Taube 

This seems to be some old copy, it doesn't match with what's in the
Linux kernel (different name, plus clock IDs off-by-one).
Please use a verbatim copy (under the same name) from the Linux kernel.

Cheers,
Andre

> ---
>  include/dt-bindings/clock/suniv-ccu.h | 68 +++
>  1 file changed, 68 insertions(+)
>  create mode 100644 include/dt-bindings/clock/suniv-ccu.h
> 
> diff --git a/include/dt-bindings/clock/suniv-ccu.h 
> b/include/dt-bindings/clock/suniv-ccu.h
> new file mode 100644
> index 00..83d3c18ac0
> --- /dev/null
> +++ b/include/dt-bindings/clock/suniv-ccu.h
> @@ -0,0 +1,68 @@
> +/* SPDX-License-Identifier: (GPL-2.0+ or MIT) */
> +/*
> + * Copyright (c) 2018 Icenowy Zheng 
> + */
> +
> +#ifndef _DT_BINDINGS_CLK_SUNIV_H_
> +#define _DT_BINDINGS_CLK_SUNIV_H_
> +
> +#define CLK_CPU  11
> +
> +#define CLK_BUS_MMC0 14
> +#define CLK_BUS_MMC1 15
> +#define CLK_BUS_DRAM 16
> +#define CLK_BUS_SPI0 17
> +#define CLK_BUS_SPI1 18
> +#define CLK_BUS_OTG  19
> +#define CLK_BUS_VE   20
> +#define CLK_BUS_LCD  21
> +#define CLK_BUS_DEINTERLACE  22
> +#define CLK_BUS_CSI  23
> +#define CLK_BUS_TVD  24
> +#define CLK_BUS_TVE  25
> +#define CLK_BUS_DE_BE26
> +#define CLK_BUS_DE_FE27
> +#define CLK_BUS_CODEC28
> +#define CLK_BUS_SPDIF29
> +#define CLK_BUS_IR   30
> +#define CLK_BUS_RSB  31
> +#define CLK_BUS_I2S0 32
> +#define CLK_BUS_I2C0 33
> +#define CLK_BUS_I2C1 34
> +#define CLK_BUS_I2C2 35
> +#define CLK_BUS_PIO  36
> +#define CLK_BUS_UART037
> +#define CLK_BUS_UART138
> +#define CLK_BUS_UART239
> +
> +#define CLK_MMC0 40
> +#define CLK_MMC0_SAMPLE  41
> +#define CLK_MMC0_OUTPUT  42
> +#define CLK_MMC1 43
> +#define CLK_MMC1_SAMPLE  44
> +#define CLK_MMC1_OUTPUT  45
> +#define CLK_I2S  46
> +#define CLK_SPDIF47
> +
> +#define CLK_USB_PHY0 48
> +
> +#define CLK_DRAM_VE  49
> +#define CLK_DRAM_CSI 50
> +#define CLK_DRAM_DEINTERLACE 51
> +#define CLK_DRAM_TVD 52
> +#define CLK_DRAM_DE_FE   53
> +#define CLK_DRAM_DE_BE   54
> +
> +#define CLK_DE_BE55
> +#define CLK_DE_FE56
> +#define CLK_TCON 57
> +#define CLK_DEINTERLACE  58
> +#define CLK_TVE2_CLK 59
> +#define CLK_TVE1_CLK 60
> +#define CLK_TVD  61
> +#define CLK_CSI  62
> +#define CLK_VE   63
> +#define CLK_CODEC64
> +#define CLK_AVS  65
> +
> +#endif

Re: [PATCH 04/11] dt-bindings: reset: Add initial suniv headers

On Tue,  4 Jan 2022 19:35:01 -0500
Jesse Taube  wrote:

> From: Icenowy Zheng 
> 
> This commit introduces suniv dt-bindings headers
> needed for device tree files.
> 
> Signed-off-by: Icenowy Zheng 
> Signed-off-by: Jesse Taube 

This seems to be some old copy, it doesn't match with what's in the
Linux kernel (different name, plus clock IDs off-by-one).
Please use a verbatim copy (under the same name) from the Linux kernel.

Cheers,
Andre

> ---
>  include/dt-bindings/reset/suniv-ccu.h | 36 +++
>  1 file changed, 36 insertions(+)
>  create mode 100644 include/dt-bindings/reset/suniv-ccu.h
> 
> diff --git a/include/dt-bindings/reset/suniv-ccu.h 
> b/include/dt-bindings/reset/suniv-ccu.h
> new file mode 100644
> index 00..d556a8dba0
> --- /dev/null
> +++ b/include/dt-bindings/reset/suniv-ccu.h
> @@ -0,0 +1,36 @@
> +/* SPDX-License-Identifier: (GPL-2.0+ or MIT) */
> +/*
> + * Copyright (C) 2018 Icenowy Zheng 
> + */
> +
> +#ifndef _DT_BINDINGS_RST_SUNIV_H_
> +#define _DT_BINDINGS_RST_SUNIV_H_
> +
> +#define RST_USB_PHY0 0
> +#define RST_BUS_MMC0 1
> +#define RST_BUS_MMC1 2
> +#define RST_BUS_DRAM 3
> +#define RST_BUS_SPI0 4
> +#define RST_BUS_SPI1 5
> +#define RST_BUS_OTG  6
> +#define RST_BUS_VE   7
> +#define RST_BUS_LCD  8
> +#define RST_BUS_DEINTERLACE  9
> +#define RST_BUS_CSI  10
> +#define RST_BUS_TVD  11
> +#define RST_BUS_TVE  12
> +#define RST_BUS_DE_BE13
> +#define RST_BUS_DE_FE14
> +#define RST_BUS_CODEC15
> +#define RST_BUS_SPDIF16
> +#define RST_BUS_IR   17
> +#define RST_BUS_RSB  18
> +#define RST_BUS_I2S0 19
> +#define RST_BUS_I2C0 20
> +#define RST_BUS_I2C1 21
> +#define RST_BUS_I2C2 22
> +#define RST_BUS_UART023
> +#define RST_BUS_UART124
> +#define RST_BUS_UART225
> +
> +#endif /* _DT_BINDINGS_RST_SUNIV_H_ */

Re: [PATCH 07/11] sunxi: board: Add support for SUNIV

On Tue,  4 Jan 2022 19:35:04 -0500
Jesse Taube  wrote:

Hi,

> From: Icenowy Zheng 
> 
> Generic Timer Extension is not available on SUNIV.

Well, that, plus there are no ID registers with which we could query
this. But that has the same effect, so:

> Signed-off-by: Icenowy Zheng 
> Signed-off-by: Jesse Taube 

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  board/sunxi/board.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 2790a0f9e8..59eb195c26 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -197,7 +197,7 @@ int board_init(void)
>  
>   gd->bd->bi_boot_params = (PHYS_SDRAM_0 + 0x100);
>  
> -#ifndef CONFIG_ARM64
> +#if !defined(CONFIG_ARM64) && !defined(CONFIG_MACH_SUNIV)
>   asm volatile("mrc p15, 0, %0, c0, c1, 1" : "=r"(id_pfr1));
>   debug("id_pfr1: 0x%08x\n", id_pfr1);
>   /* Generic Timer Extension available? */
> @@ -224,7 +224,7 @@ int board_init(void)
>  #endif
>   }
>   }
> -#endif /* !CONFIG_ARM64 */
> +#endif /* !CONFIG_ARM64 && !CONFIG_MACH_SUNIV */
>  
>   ret = axp_gpio_init();
>   if (ret)

Re: [PATCH 10/11] ARM: dts: suniv: Add device tree files for F1C100s

On Tue,  4 Jan 2022 19:35:07 -0500
Jesse Taube  wrote:

Hi,

> From: Icenowy Zheng 
> 
> Add device tree files for suniv and
> Lichee Pi Nano it is a board based on F1C100s.
> 
> Signed-off-by: Icenowy Zheng 
> Signed-off-by: Jesse Taube 

Those files differ significantly from the kernel. It looks like the
copies here enable MMC, SPI and USB, which are missing from the Linux
tree. At the same time both seem to be coming from a slightly different
base. So I'd suggest to fix this up (create a minimal diff between
Linux and this, changing this version if needed), then sending this to
the kernel. Meanwhile we could go with the mainline Linux versions. I
am willing to merge them once the updates reach some maintainer tree.

Cheers,
Andre

> ---
>  arch/arm/dts/Makefile|   2 +
>  arch/arm/dts/suniv-f1c100s-licheepi-nano.dts |  64 ++
>  arch/arm/dts/suniv-f1c100s.dtsi  |   6 +
>  arch/arm/dts/suniv.dtsi  | 224 +++
>  4 files changed, 296 insertions(+)
>  create mode 100644 arch/arm/dts/suniv-f1c100s-licheepi-nano.dts
>  create mode 100644 arch/arm/dts/suniv-f1c100s.dtsi
>  create mode 100644 arch/arm/dts/suniv.dtsi
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 453e2fd1a9..07030deeca 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -497,6 +497,8 @@ dtb-$(CONFIG_STM32H7) += stm32h743i-disco.dtb \
>   stm32h743i-eval.dtb \
>   stm32h750i-art-pi.dtb
>  
> +dtb-$(CONFIG_MACH_SUNIV) += \
> + suniv-f1c100s-licheepi-nano.dtb
>  dtb-$(CONFIG_MACH_SUN4I) += \
>   sun4i-a10-a1000.dtb \
>   sun4i-a10-ba10-tvbox.dtb \
> diff --git a/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts 
> b/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts
> new file mode 100644
> index 00..919fc01b0e
> --- /dev/null
> +++ b/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts
> @@ -0,0 +1,64 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR X11)
> +/*
> + * Copyright 2018 Icenowy Zheng 
> + */
> +
> +/dts-v1/;
> +#include "suniv-f1c100s.dtsi"
> +
> +#include 
> +
> +/ {
> + model = "Lichee Pi Nano";
> + compatible = "licheepi,licheepi-nano", "allwinner,suniv-f1c100s",
> +  "allwinner,suniv";
> +
> + aliases {
> + serial0 = &uart0;
> + spi0 = &spi0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&otg_sram {
> + status = "okay";
> +};
> +
> +&mmc0 {
> + bus-width = <4>;
> + cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
> + status = "okay";
> +};
> +
> +&spi0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi0_pins_a>;
> + status = "okay";
> +
> + flash@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "winbond,w25q128", "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <4000>;
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_pins_a>;
> + status = "okay";
> +};
> +
> +&usb_otg {
> + dr_mode = "otg";
> + status = "okay";
> +};
> +
> +&usbphy {
> + usb0_id_det-gpio = <&pio 4 2 GPIO_ACTIVE_HIGH>; /* PE2 */
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/suniv-f1c100s.dtsi b/arch/arm/dts/suniv-f1c100s.dtsi
> new file mode 100644
> index 00..f084bc8dd1
> --- /dev/null
> +++ b/arch/arm/dts/suniv-f1c100s.dtsi
> @@ -0,0 +1,6 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR X11)
> +/*
> + * Copyright 2018 Icenowy Zheng 
> + */
> +
> +#include "suniv.dtsi"
> diff --git a/arch/arm/dts/suniv.dtsi b/arch/arm/dts/suniv.dtsi
> new file mode 100644
> index 00..a4e933505d
> --- /dev/null
> +++ b/arch/arm/dts/suniv.dtsi
> @@ -0,0 +1,224 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR X11)
> +/*
> + * Copyright 2018 Icenowy Zheng 
> + */
> +
> +#include 
> +#include 
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + interrupt-parent = <&intc>;
> +
> + clocks {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + osc24M: clk-24M {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <2400>;
> + clock-output-names = "osc24M";
> + };
> +
> + osc32k: clk-32k {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <32768>;
> + clock-output-names = "osc32k";
> + };
> +
> + fake100M: clk-100M {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <1>;
> + clock-output-names = "fake-100M";
> + };
> + };
> +
> + cpus {
> + #address-cel

Re: [PATCH v2 00/38] binman: Add support for bintools and missing tools

Hi custodians,

On Sun, 9 Jan 2022 at 20:14, Simon Glass  wrote:
>
>
> At present binman uses binary tools (like cbfstool, futiltiy, lz4) in an
> ad-hoc manner. Various parts of binman use tools.Run() to run tools as
> needed. If a tool is missing, an error is produced and binman stops.
>
> However this is not ideal. CI systems want to be able to complete the
> build, even if tools are missing. Ideally binman would deal with missing
> binary tools the same way it deals with missing binary blobs: make a note
> of it and move on.
>
> This series introduces this feature to binman.
>
> `Bintool` is the name binman gives to a binary tool which it uses to
> create and manipulate binaries that binman cannot handle itself.
>
> Binman provides various features to manage bintools:
>
> - Determining whether the tool is currently installed
> - Downloading or building the tool
> - Determining the version of the tool that is installed
> - Deciding which tools are needed to build an image
>
> As with external blobs, bintools (which are like 'external' tools) can be
> missing. When building an image requires a bintool and it is not
> installed, binman detects this and reports the problem, but continues to
> build an image.
>
> Of course the image will not work, but binman reports which bintools are 
> needed
> and also provide a way to fetch them.
>
> The final patch shows how this works in practice with a chosen board. The
> Odroid-C2 is quite a complicated image with many steps. It is an ideal
> example for how Binman can be used.
>
> The series is available at u-boot-dm/bin-working
>
> Changes in v2:
> - Substantial rewrite, introducing the concept of bintools

I'm just wondering if people have had a chance to look at this and
might have feedback?

Also, I am wondering about adding the ability to download binary blobs
where they are missing.

Regards,
Simon

Regards,
Simon

Re: [PATCH 10/11] ARM: dts: suniv: Add device tree files for F1C100s

2022-01-20 Thread Jesse Taube





On 1/20/22 20:59, Andre Przywara wrote:

On Tue,  4 Jan 2022 19:35:07 -0500
Jesse Taube  wrote:

Hi,


From: Icenowy Zheng 

Add device tree files for suniv and
Lichee Pi Nano it is a board based on F1C100s.

Signed-off-by: Icenowy Zheng 
Signed-off-by: Jesse Taube 


Those files differ significantly from the kernel. It looks like the
copies here enable MMC, SPI and USB, which are missing from the Linux
tree.
Thx for pointing this out I will fix it. Although SPI and MMC are the 
two boot devices so they will be needed. I'm confused as to why and how 
they arent' in Linux as they have drivers, USB even has a driver.

Thanks for the Reviews!

Kindly,
Jesse Taube
 At the same time both seem to be coming from a slightly different

base. So I'd suggest to fix this up (create a minimal diff between
Linux and this, changing this version if needed), then sending this to
the kernel. Meanwhile we could go with the mainline Linux versions. I
am willing to merge them once the updates reach some maintainer tree.

Cheers,
Andre


---
  arch/arm/dts/Makefile|   2 +
  arch/arm/dts/suniv-f1c100s-licheepi-nano.dts |  64 ++
  arch/arm/dts/suniv-f1c100s.dtsi  |   6 +
  arch/arm/dts/suniv.dtsi  | 224 +++
  4 files changed, 296 insertions(+)
  create mode 100644 arch/arm/dts/suniv-f1c100s-licheepi-nano.dts
  create mode 100644 arch/arm/dts/suniv-f1c100s.dtsi
  create mode 100644 arch/arm/dts/suniv.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 453e2fd1a9..07030deeca 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -497,6 +497,8 @@ dtb-$(CONFIG_STM32H7) += stm32h743i-disco.dtb \
stm32h743i-eval.dtb \
stm32h750i-art-pi.dtb
  
+dtb-$(CONFIG_MACH_SUNIV) += \

+   suniv-f1c100s-licheepi-nano.dtb
  dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-a1000.dtb \
sun4i-a10-ba10-tvbox.dtb \
diff --git a/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts 
b/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts
new file mode 100644
index 00..919fc01b0e
--- /dev/null
+++ b/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR X11)
+/*
+ * Copyright 2018 Icenowy Zheng 
+ */
+
+/dts-v1/;
+#include "suniv-f1c100s.dtsi"
+
+#include 
+
+/ {
+   model = "Lichee Pi Nano";
+   compatible = "licheepi,licheepi-nano", "allwinner,suniv-f1c100s",
+"allwinner,suniv";
+
+   aliases {
+   serial0 = &uart0;
+   spi0 = &spi0;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+&otg_sram {
+   status = "okay";
+};
+
+&mmc0 {
+   bus-width = <4>;
+   cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
+   status = "okay";
+};
+
+&spi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&spi0_pins_a>;
+   status = "okay";
+
+   flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "winbond,w25q128", "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <4000>;
+   };
+};
+
+&uart0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&uart0_pins_a>;
+   status = "okay";
+};
+
+&usb_otg {
+   dr_mode = "otg";
+   status = "okay";
+};
+
+&usbphy {
+   usb0_id_det-gpio = <&pio 4 2 GPIO_ACTIVE_HIGH>; /* PE2 */
+   status = "okay";
+};
diff --git a/arch/arm/dts/suniv-f1c100s.dtsi b/arch/arm/dts/suniv-f1c100s.dtsi
new file mode 100644
index 00..f084bc8dd1
--- /dev/null
+++ b/arch/arm/dts/suniv-f1c100s.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR X11)
+/*
+ * Copyright 2018 Icenowy Zheng 
+ */
+
+#include "suniv.dtsi"
diff --git a/arch/arm/dts/suniv.dtsi b/arch/arm/dts/suniv.dtsi
new file mode 100644
index 00..a4e933505d
--- /dev/null
+++ b/arch/arm/dts/suniv.dtsi
@@ -0,0 +1,224 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR X11)
+/*
+ * Copyright 2018 Icenowy Zheng 
+ */
+
+#include 
+#include 
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   interrupt-parent = <&intc>;
+
+   clocks {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   osc24M: clk-24M {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2400>;
+   clock-output-names = "osc24M";
+   };
+
+   osc32k: clk-32k {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <32768>;
+   clock-output-names = "osc32k";
+   };
+
+   fake100M: clk-100M {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <1>;
+

Re: [RFC PATCH 11/14] FWU: Add FWU Multi Bank Update on SPI Flash

2022-01-20 Thread AKASHI Takahiro

On Fri, Jan 21, 2022 at 12:31:10AM +0900, Masami Hiramatsu wrote:
> Signed-off-by: Masami Hiramatsu 
> ---
>  include/fwu.h  |   13 ++
>  lib/fwu_updates/Kconfig|   34 ++
>  lib/fwu_updates/Makefile   |5 -
>  lib/fwu_updates/fwu_mdata_sf.c |  241 
> 
>  4 files changed, 288 insertions(+), 5 deletions(-)
>  create mode 100644 lib/fwu_updates/fwu_mdata_sf.c
> 
> diff --git a/include/fwu.h b/include/fwu.h
> index 7af94988b7..a013170321 100644
> --- a/include/fwu.h
> +++ b/include/fwu.h
> @@ -64,9 +64,18 @@ int fwu_accept_image(efi_guid_t *img_type_id, u32 bank);
>  int fwu_clear_accept_image(efi_guid_t *img_type_id, u32 bank);
>  
>  int fwu_plat_get_update_index(u32 *update_idx);
> -int fwu_plat_get_blk_desc(struct blk_desc **desc);
> -int fwu_plat_get_alt_num(void *identifier);
>  int fwu_plat_fill_partition_guids(efi_guid_t **part_guid_arr);
>  void fwu_plat_get_bootidx(void *boot_idx);
>  
> +#ifdef CONFIG_FWU_MULTI_BANK_UPDATE_GPT_BLK
> +int fwu_plat_get_blk_desc(struct blk_desc **desc);
> +int fwu_plat_get_alt_num(void *identifier);
> +#endif

We can (and should) remove "#ifdef ..." from headers.

-Takahiro Akashi

> +#ifdef CONFIG_FWU_MULTI_BANK_UPDATE_SF
> +struct fwu_mdata_ops *fwu_sf_get_fwu_mdata_ops(void);
> +int fwu_plat_get_image_alt_num(efi_guid_t image_type_id, u32 update_bank,
> +int *alt_no);
> +#endif
> +
>  #endif /* _FWU_H_ */
> diff --git a/lib/fwu_updates/Kconfig b/lib/fwu_updates/Kconfig
> index 0940a90747..8a369b9872 100644
> --- a/lib/fwu_updates/Kconfig
> +++ b/lib/fwu_updates/Kconfig
> @@ -38,3 +38,37 @@ config FWU_REBOOT_AFTER_UPDATE
> Reboot the machine soon after installing a new firmware
> and start trial boot. You can disable this option for
> debugging or FWU development, but recommended to enable it.
> +
> +config FWU_MULTI_BANK_UPDATE_GPT_BLK
> + bool "Enable FWU Multi Bank Update for GPT on blockdev"
> + depends on FWU_MULTI_BANK_UPDATE
> + select EFI_PARTITION
> + help
> +   Enable FWU Multi Bank Update for GPT on a block device. This
> +   driver depends on GPT and the block device. FWU meatadata and
> +   firmware will be stored on a block device with GPT.
> +
> +config FWU_MULTI_BANK_UPDATE_SF
> + bool "Enable FWU Multi Bank Update for SPI Flash"
> + depends on FWU_MULTI_BANK_UPDATE
> + help
> +   Enable FWU Multi Bank Update for SPI flash driver. This
> +   driver does not depend on GPT. Instead, the platform must
> +   provide some APIs and define the offset of the primary and
> +   the secondary metadata.
> +
> +config FWU_SF_PRIMARY_MDATA_OFFSET
> + hex "The offset of the primary metadata"
> + depends on FWU_MULTI_BANK_UPDATE_SF
> + help
> +   The offset of the primary metadata on SPI Flash in
> +   hexadecimal.
> +
> +config FWU_SF_SECONDARY_MDATA_OFFSET
> + hex "The offset of the secondary metadata"
> + depends on FWU_MULTI_BANK_UPDATE_SF
> + help
> +   The offset of the secondary metadata on SPI Flash in
> +   hexadecimal.
> +   This must NOT be the same offset of the primary
> +   metadata.
> diff --git a/lib/fwu_updates/Makefile b/lib/fwu_updates/Makefile
> index 73099a30cb..80669344f2 100644
> --- a/lib/fwu_updates/Makefile
> +++ b/lib/fwu_updates/Makefile
> @@ -6,6 +6,5 @@
>  obj-$(CONFIG_FWU_MULTI_BANK_UPDATE) += fwu_mdata.o
>  obj-$(CONFIG_FWU_MULTI_BANK_UPDATE) += fwu.o
>  
> -ifdef CONFIG_EFI_PARTITION
> -obj-$(CONFIG_FWU_MULTI_BANK_UPDATE) += fwu_mdata_gpt_blk.o
> -endif
> +obj-$(CONFIG_FWU_MULTI_BANK_UPDATE_GPT_BLK) += fwu_mdata_gpt_blk.o
> +obj-$(CONFIG_FWU_MULTI_BANK_UPDATE_SF) += fwu_mdata_sf.o
> diff --git a/lib/fwu_updates/fwu_mdata_sf.c b/lib/fwu_updates/fwu_mdata_sf.c
> new file mode 100644
> index 00..9e3cae7b68
> --- /dev/null
> +++ b/lib/fwu_updates/fwu_mdata_sf.c
> @@ -0,0 +1,241 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2021, Linaro Limited
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * For the FWU SPI flash driver, the platform must define below functions
> + * according to its dfu_alt_info.
> + */
> +extern int fwu_plat_get_image_alt_num(efi_guid_t image_type_id,
> +   u32 update_bank, int *alt_no);
> +
> +static struct spi_flash *fwu_spi_flash;
> +
> +static int __fwu_sf_get_flash(void)
> +{
> + if (IS_ENABLED(CONFIG_DM_SPI_FLASH)) {
> + struct udevice *new;
> + int ret;
> +
> + ret = spi_flash_probe_bus_cs(CONFIG_SF_DEFAULT_BUS, 
> CONFIG_SF_DEFAULT_CS,
> +  CONFIG_SF_DEFAULT_SPEED, 
> CONFIG_SF_DEFAULT_MODE,
> +  &new);
> + if (ret)
> + return ret;
> +
> +

Re: [RFC PATCH 12/14] FWU: synquacer: Add FWU Multi bank update support for DeveloperBox

2022-01-20 Thread AKASHI Takahiro

On Fri, Jan 21, 2022 at 12:31:20AM +0900, Masami Hiramatsu wrote:
> The DeveloperBox platform can support the FWU Multi bank
> update. SCP firmware will switch the boot mode by DSW3-4
> and load the Multi bank update supported TF-A BL2 from
> 0x60 offset on the SPI flash. Thus it can co-exist
> with the legacy boot mode (legacy U-Boot or EDK2).
> 
> Signed-off-by: Masami Hiramatsu 
> ---
>  board/socionext/developerbox/Kconfig|   19 
>  board/socionext/developerbox/Makefile   |1 
>  board/socionext/developerbox/fwu_plat.c |  158 
> +++
>  include/configs/synquacer.h |   10 ++
>  include/efi_loader.h|3 +
>  lib/efi_loader/efi_firmware.c   |   14 +--
>  6 files changed, 198 insertions(+), 7 deletions(-)
>  create mode 100644 board/socionext/developerbox/fwu_plat.c
> 
> diff --git a/board/socionext/developerbox/Kconfig 
> b/board/socionext/developerbox/Kconfig
> index c181d26a44..4e2c341aad 100644
> --- a/board/socionext/developerbox/Kconfig
> +++ b/board/socionext/developerbox/Kconfig
> @@ -32,4 +32,23 @@ config SYS_CONFIG_NAME
>   default "synquacer"
>  
>  endif
> +
> +config FWU_MULTI_BANK_UPDATE
> + select FWU_MULTI_BANK_UPDATE_SF
> +
> +config FWU_MULTI_BANK_UPDATE_SF
> + select DM_SPI_FLASH
> +
> +config FWU_NUM_BANKS
> + default 6
> +
> +config FWU_NUM_IMAGES_PER_BANK
> + default 1
> +
> +config FWU_SF_PRIMARY_MDATA_OFFSET
> + default 0x50
> +
> +config FWU_SF_SECONDARY_MDATA_OFFSET
> + default 0x52

Are those configs DeveloperBox-specific?

-Takahiro Akashi

> +
>  endif
> diff --git a/board/socionext/developerbox/Makefile 
> b/board/socionext/developerbox/Makefile
> index 4a46de995a..15cce9c57e 100644
> --- a/board/socionext/developerbox/Makefile
> +++ b/board/socionext/developerbox/Makefile
> @@ -7,3 +7,4 @@
>  #
>  
>  obj-y:= developerbox.o
> +obj-$(CONFIG_FWU_MULTI_BANK_UPDATE_SF) += fwu_plat.o
> diff --git a/board/socionext/developerbox/fwu_plat.c 
> b/board/socionext/developerbox/fwu_plat.c
> new file mode 100644
> index 00..dbb814f1fd
> --- /dev/null
> +++ b/board/socionext/developerbox/fwu_plat.c
> @@ -0,0 +1,158 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2021, Linaro Limited
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +/* SPI Flash accessors */
> +static struct spi_flash *plat_spi_flash;
> +
> +static int __plat_sf_get_flash(void)
> +{
> + struct udevice *new;
> + int ret;
> +
> + //TODO: use CONFIG_FWU_SPI_*
> + ret = spi_flash_probe_bus_cs(CONFIG_SF_DEFAULT_BUS, 
> CONFIG_SF_DEFAULT_CS,
> +  CONFIG_SF_DEFAULT_SPEED, 
> CONFIG_SF_DEFAULT_MODE,
> +  &new);
> + if (ret)
> + return ret;
> +
> + plat_spi_flash = dev_get_uclass_priv(new);
> + return 0;
> +}
> +
> +static int plat_sf_get_flash(struct spi_flash **flash)
> +{
> + int ret = 0;
> +
> + if (!plat_spi_flash)
> + ret = __plat_sf_get_flash();
> +
> + *flash = plat_spi_flash;
> +
> + return ret;
> +}
> +
> +static int sf_load_data(u32 offs, u32 size, void **data)
> +{
> + struct spi_flash *flash;
> + int ret;
> +
> + ret = plat_sf_get_flash(&flash);
> + if (ret < 0)
> + return ret;
> +
> + *data = memalign(ARCH_DMA_MINALIGN, size);
> + if (!*data)
> + return -ENOMEM;
> +
> + ret = spi_flash_read(flash, offs, size, *data);
> + if (ret < 0) {
> + free(*data);
> + *data = NULL;
> + }
> +
> + return ret;
> +}
> +
> +/* Platform dependent GUIDs */
> +
> +/* The GUID for the SNI FIP image type GUID */
> +#define FWU_IMAGE_TYPE_DEVBOX_FIP_GUID \
> + EFI_GUID(0x7d6dc310, 0x52ca, 0x43b8, 0xb7, 0xb9, \
> +  0xf9, 0xd6, 0xc5, 0x01, 0xd1, 0x08)
> +
> +#define PLAT_METADATA_OFFSET 0x51
> +#define PLAT_METADATA_SIZE   (sizeof(struct devbox_metadata))
> +
> +struct __packed devbox_metadata {
> + u32 boot_index;
> + u32 boot_count;
> + u32 invert_dual;
> +} *devbox_plat_metadata;
> +
> +static const efi_guid_t devbox_fip_image_type_guid = 
> FWU_IMAGE_TYPE_DEVBOX_FIP_GUID;
> +
> +int fwu_plat_get_image_alt_num(efi_guid_t image_type_id, u32 update_bank,
> +int *alt_no)
> +{
> + /* DeveloperBox FWU Multi bank only supports FIP image. */
> + if (guidcmp(&image_type_id, &devbox_fip_image_type_guid))
> + return -EOPNOTSUPP;
> +
> + /*
> +  * DeveloperBox FWU expects Bank:Image = 1:1, and the dfu_alt_info
> +  * only has the entries for banks. Thus the alt_no should be equal
> +  * to the update_bank.
> +  */
> + update_bank %= CONFIG_FWU_NUM_BANKS;
> + *alt_no = update_bank;
> +
> + return 0;
> +}
> +
> +/* SPI flash doesn't have GPT, and it's not

Re: [PATCH 02/11] arm: arm926ej-s: add sunxi code

On Tue,  4 Jan 2022 19:34:59 -0500
Jesse Taube  wrote:

Hi,

> From: Icenowy Zheng 
> 
> Some Allwinner SoCs use ARM926EJ-S core.
> 
> Add Allwinner/sunXi specific code to ARM926EJ-S CPU dircetory.
> 
> Signed-off-by: Icenowy Zheng 
> Signed-off-by: Jesse Taube 
> ---
>  arch/arm/cpu/arm926ejs/Makefile  |   1 +
>  arch/arm/cpu/arm926ejs/sunxi/Makefile|  15 +++
>  arch/arm/cpu/arm926ejs/sunxi/config.mk   |   6 +
>  arch/arm/cpu/arm926ejs/sunxi/fel_utils.S |  37 ++
>  arch/arm/cpu/arm926ejs/sunxi/lowlevel_init.S |  67 +++
>  arch/arm/cpu/arm926ejs/sunxi/start.c |   1 +
>  arch/arm/cpu/arm926ejs/sunxi/timer.c | 114 +++
>  arch/arm/cpu/arm926ejs/sunxi/u-boot-spl.lds  |  62 ++
>  8 files changed, 303 insertions(+)
>  create mode 100644 arch/arm/cpu/arm926ejs/sunxi/Makefile
>  create mode 100644 arch/arm/cpu/arm926ejs/sunxi/config.mk
>  create mode 100644 arch/arm/cpu/arm926ejs/sunxi/fel_utils.S
>  create mode 100644 arch/arm/cpu/arm926ejs/sunxi/lowlevel_init.S
>  create mode 100644 arch/arm/cpu/arm926ejs/sunxi/start.c
>  create mode 100644 arch/arm/cpu/arm926ejs/sunxi/timer.c
>  create mode 100644 arch/arm/cpu/arm926ejs/sunxi/u-boot-spl.lds
> 
> diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile
> index b901b7c5c9..7f1436d76e 100644
> --- a/arch/arm/cpu/arm926ejs/Makefile
> +++ b/arch/arm/cpu/arm926ejs/Makefile
> @@ -15,6 +15,7 @@ endif
>  obj-$(CONFIG_MX27) += mx27/
>  obj-$(if $(filter mxs,$(SOC)),y) += mxs/
>  obj-$(if $(filter spear,$(SOC)),y) += spear/
> +obj-$(CONFIG_ARCH_SUNXI) += sunxi/
>  
>  # some files can only build in ARM or THUMB2, not THUMB1
>  
> diff --git a/arch/arm/cpu/arm926ejs/sunxi/Makefile 
> b/arch/arm/cpu/arm926ejs/sunxi/Makefile
> new file mode 100644
> index 00..894c461c50
> --- /dev/null
> +++ b/arch/arm/cpu/arm926ejs/sunxi/Makefile
> @@ -0,0 +1,15 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# (C) Copyright 2012 Henrik Nordstrom 
> +#
> +# Based on some other Makefile
> +# (C) Copyright 2000-2003
> +# Wolfgang Denk, DENX Software Engineering, w...@denx.de.

Please remove this heritage. I appreciate the effort to give credit,
but for a trivial Makefile stub (which even differs significantly) this
is surely overkill.
Just one line with some current copyright should be enough.

> +
> +obj-y+= timer.o
> +obj-y+= lowlevel_init.o
> +
> +ifdef CONFIG_SPL_BUILD
> +obj-y+= fel_utils.o
> +CFLAGS_fel_utils.o := -marm
> +endif
> diff --git a/arch/arm/cpu/arm926ejs/sunxi/config.mk 
> b/arch/arm/cpu/arm926ejs/sunxi/config.mk
> new file mode 100644
> index 00..76ffec9df6
> --- /dev/null
> +++ b/arch/arm/cpu/arm926ejs/sunxi/config.mk
> @@ -0,0 +1,6 @@
> +# Build a combined spl + u-boot image
> +ifdef CONFIG_SPL
> +ifndef CONFIG_SPL_BUILD
> +ALL-y += u-boot-sunxi-with-spl.bin
> +endif
> +endif
> diff --git a/arch/arm/cpu/arm926ejs/sunxi/fel_utils.S 
> b/arch/arm/cpu/arm926ejs/sunxi/fel_utils.S
> new file mode 100644
> index 00..0997a2dc65
> --- /dev/null
> +++ b/arch/arm/cpu/arm926ejs/sunxi/fel_utils.S
> @@ -0,0 +1,37 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Utility functions for FEL mode.
> + *
> + * Copyright (c) 2015 Google, Inc
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +ENTRY(save_boot_params)
> + ldr r0, =fel_stash
> + str sp, [r0, #0]
> + str lr, [r0, #4]
> + mrs lr, cpsr@ Read CPSR
> + str lr, [r0, #8]
> + mrc p15, 0, lr, c1, c0, 0   @ Read CP15 SCTLR Register
> + str lr, [r0, #12]
> + mrc p15, 0, lr, c1, c0, 0   @ Read CP15 Control Register
> + str lr, [r0, #16]

This is the very same register twice, also written to the wrong offset.
Please remove the last two lines.
Yes, this is a bug in armv7/sunxi/fel_utils.S as well, I will send a
fix.

> + b   save_boot_params_ret
> +ENDPROC(save_boot_params)
> +
> +ENTRY(return_to_fel)
> + mov sp, r0
> + mov lr, r1
> + ldr r0, =fel_stash
> + ldr r1, [r0, #16]
> + mcr p15, 0, r1, c1, c0, 0   @ Write CP15 Control Register

Same here, those two lines can be removed.

> + ldr r1, [r0, #12]
> + mcr p15, 0, r1, c1, c0, 0   @ Write CP15 SCTLR Register
> + ldr r1, [r0, #8]
> + msr cpsr, r1@ Write CPSR
> + bx  lr
> +ENDPROC(return_to_fel)
> diff --git a/arch/arm/cpu/arm926ejs/sunxi/lowlevel_init.S 
> b/arch/arm/cpu/arm926ejs/sunxi/lowlevel_init.S
> new file mode 100644
> index 00..db09bcc4d0
> --- /dev/null
> +++ b/arch/arm/cpu/arm926ejs/sunxi/lowlevel_init.S
> @@ -0,0 +1,67 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * A lowlevel_init function that sets up the stack to call a C function to
> + * perform further init.
> + *
> + * Based on lowlevel_init.S in armv7 directory, which is:
> + *   (C) Copyright 2010 Texas Instruments, 
> + */
> +
> +#includ

Re: [PATCH v3 31/31] RFC: Switch rpi over to use bootstd

Hi Tom,

On Thu, 20 Jan 2022 at 18:08, Tom Rini  wrote:
>
> On Thu, Jan 20, 2022 at 05:59:53PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 20 Jan 2022 at 16:23, Tom Rini  wrote:
> > >
> > > On Thu, Jan 20, 2022 at 01:47:41PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 20 Jan 2022 at 13:08, Tom Rini  wrote:
> > > > >
> > > > > On Thu, Jan 20, 2022 at 12:56:55PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, 20 Jan 2022 at 11:30, Tom Rini  wrote:
> > > > > > >
> > > > > > > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote:
> > > > > > > > Hi Mark,
> > > > > > > >
> > > > > > > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > > From: Michael Walle 
> > > > > > > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100
> > > > > > > > > >
> > > > > > > > > > > The bootdevs have a natural priority, based on the 
> > > > > > > > > > > assumed speed of
> > > > > > > > > > > the device, so the board would only need to intervene 
> > > > > > > > > > > (with an env var
> > > > > > > > > > > or a devicetree property) when that is wrong.
> > > > > > > > > >
> > > > > > > > > > Does this make sense in general? The default boot order for 
> > > > > > > > > > a
> > > > > > > > > > board should depend on what is available on board (or on the
> > > > > > > > > > carrier board) and what is pluggable. I doubt there can be 
> > > > > > > > > > a sane
> > > > > > > > > > default, so almost all boards will have to define its own
> > > > > > > > > > boot order anyway.
> > > > > > > >
> > > > > > > > Please can you be more specific about what you the problem is 
> > > > > > > > here? If
> > > > > > > > the board does not have a device then it will not exist in 
> > > > > > > > driver
> > > > > > > > model (or will not probe) and it won't have a bootdev (or it 
> > > > > > > > won't
> > > > > > > > probe). That seems to be equivalent to me.
> > > > > > >
> > > > > > > So, I'm not sure how much of a problem it is, since the board can 
> > > > > > > still
> > > > > > > define the default probe order via environment.  But pick any 
> > > > > > > random SoC
> > > > > > > with more than 1 SD/MMC set of lines on the chip.  Youboard may 
> > > > > > > put the
> > > > > > > first as SD slot and second as eMMC and Myboard may do the 
> > > > > > > opposite and
> > > > > > > both are going to probe in the same order since it's the same 
> > > > > > > chip.
> > > > > > >
> > > > > > > That's what I think Mark is getting at with it not really making 
> > > > > > > sense
> > > > > > > to just rely on probe order as what to try.
> > > > > >
> > > > > > Doesn't the 'non-removable' flag describe this feature of the 
> > > > > > hardware?
> > > > > >
> > > > > > If you don't want to rely on the normal ordering, you can set the
> > > > > > boot_targets variable. I'd just like to avoid that being required 
> > > > > > for
> > > > > > 'normal' boards and situations.
> > > > >
> > > > > I think setting things via the environment to have correct defaults 
> > > > > is a
> > > > > must.  I mean, yes, OK, if there's some device tree binding that we 
> > > > > can
> > > > > use that describes this, sure, that's choice A.  But choice B would
> > > > > probably be environment strings.  Probe and hope is choice C, or more
> > > > > like last resort, imho.
> > > >
> > > > Well the boot_targets var is implemented in this series.
> > > >
> > > > The question is whether we force platforms to define it, or have a way
> > > > to handle things gracefully by default.
> > >
> > > I think we need to force it to be defined until / unless there's some
> > > agreed on standard to provide that information at run time.
> >
> > Well we can do that with a cut-down distro header with some macros, I 
> > suppose?
>
> Sorry?  I mean, when I said standard above, and since you had mentioned
> from the device tree before (I thought..) I mean get some property
> defined and accepted and use that for first best path.  Then keep using

I think this discussion is a bit beyond the scope of this series. You
are talking about the policy for the bootdev selection. So far,
implemented in this series, we have, in order of preference:

- boot_targets env var
- bootdev-order device tree property (which you are referring to here)
- priority order (as announced by each bootdev, i.e. it can depend on
removable flags, etc.)
- alias order (using device tree)
- simple sequence order (position in device tree, or order in which
devices were bound)

I think that is enough to be getting on with. My point above was that
if we want to define the boot_targets env var in a header file as now,
we could.

> boot_targets and make sure it's documented (and in help, etc) that
> boards should define that in their default environment for a preferred
> fallback default boot order.  The final fall back of "probe and guess"
> might need an off switch for securing systems, I'm not sure.

Yes we need

Re: [PATCH 02/11] arm: arm926ej-s: add sunxi code

2022-01-20 Thread Jesse Taube





On 1/20/22 21:25, Andre Przywara wrote:

On Tue,  4 Jan 2022 19:34:59 -0500
Jesse Taube  wrote:

Hi,


From: Icenowy Zheng 

Some Allwinner SoCs use ARM926EJ-S core.

Add Allwinner/sunXi specific code to ARM926EJ-S CPU dircetory.

Signed-off-by: Icenowy Zheng 
Signed-off-by: Jesse Taube 
---
  arch/arm/cpu/arm926ejs/Makefile  |   1 +
  arch/arm/cpu/arm926ejs/sunxi/Makefile|  15 +++
  arch/arm/cpu/arm926ejs/sunxi/config.mk   |   6 +
  arch/arm/cpu/arm926ejs/sunxi/fel_utils.S |  37 ++
  arch/arm/cpu/arm926ejs/sunxi/lowlevel_init.S |  67 +++
  arch/arm/cpu/arm926ejs/sunxi/start.c |   1 +
  arch/arm/cpu/arm926ejs/sunxi/timer.c | 114 +++
  arch/arm/cpu/arm926ejs/sunxi/u-boot-spl.lds  |  62 ++
  8 files changed, 303 insertions(+)
  create mode 100644 arch/arm/cpu/arm926ejs/sunxi/Makefile
  create mode 100644 arch/arm/cpu/arm926ejs/sunxi/config.mk
  create mode 100644 arch/arm/cpu/arm926ejs/sunxi/fel_utils.S
  create mode 100644 arch/arm/cpu/arm926ejs/sunxi/lowlevel_init.S
  create mode 100644 arch/arm/cpu/arm926ejs/sunxi/start.c
  create mode 100644 arch/arm/cpu/arm926ejs/sunxi/timer.c
  create mode 100644 arch/arm/cpu/arm926ejs/sunxi/u-boot-spl.lds

diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile
index b901b7c5c9..7f1436d76e 100644
--- a/arch/arm/cpu/arm926ejs/Makefile
+++ b/arch/arm/cpu/arm926ejs/Makefile
@@ -15,6 +15,7 @@ endif
  obj-$(CONFIG_MX27) += mx27/
  obj-$(if $(filter mxs,$(SOC)),y) += mxs/
  obj-$(if $(filter spear,$(SOC)),y) += spear/
+obj-$(CONFIG_ARCH_SUNXI) += sunxi/
  
  # some files can only build in ARM or THUMB2, not THUMB1
  
diff --git a/arch/arm/cpu/arm926ejs/sunxi/Makefile b/arch/arm/cpu/arm926ejs/sunxi/Makefile

new file mode 100644
index 00..894c461c50
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/sunxi/Makefile
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# (C) Copyright 2012 Henrik Nordstrom 
+#
+# Based on some other Makefile
+# (C) Copyright 2000-2003
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.


Please remove this heritage. I appreciate the effort to give credit,
but for a trivial Makefile stub (which even differs significantly) this
is surely overkill.
Just one line with some current copyright should be enough.


Fixed.

+
+obj-y  += timer.o
+obj-y  += lowlevel_init.o
+
+ifdef CONFIG_SPL_BUILD
+obj-y  += fel_utils.o
+CFLAGS_fel_utils.o := -marm
+endif
diff --git a/arch/arm/cpu/arm926ejs/sunxi/config.mk 
b/arch/arm/cpu/arm926ejs/sunxi/config.mk
new file mode 100644
index 00..76ffec9df6
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/sunxi/config.mk
@@ -0,0 +1,6 @@
+# Build a combined spl + u-boot image
+ifdef CONFIG_SPL
+ifndef CONFIG_SPL_BUILD
+ALL-y += u-boot-sunxi-with-spl.bin
+endif
+endif
diff --git a/arch/arm/cpu/arm926ejs/sunxi/fel_utils.S 
b/arch/arm/cpu/arm926ejs/sunxi/fel_utils.S
new file mode 100644
index 00..0997a2dc65
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/sunxi/fel_utils.S
@@ -0,0 +1,37 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Utility functions for FEL mode.
+ *
+ * Copyright (c) 2015 Google, Inc
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+ENTRY(save_boot_params)
+   ldr r0, =fel_stash
+   str sp, [r0, #0]
+   str lr, [r0, #4]
+   mrs lr, cpsr@ Read CPSR
+   str lr, [r0, #8]
+   mrc p15, 0, lr, c1, c0, 0   @ Read CP15 SCTLR Register
+   str lr, [r0, #12]
+   mrc p15, 0, lr, c1, c0, 0   @ Read CP15 Control Register
+   str lr, [r0, #16]


This is the very same register twice, also written to the wrong offset.
Please remove the last two lines.
Yes, this is a bug in armv7/sunxi/fel_utils.S as well, I will send a
fix.

Please CC me.



+   b   save_boot_params_ret
+ENDPROC(save_boot_params)
+
+ENTRY(return_to_fel)
+   mov sp, r0
+   mov lr, r1
+   ldr r0, =fel_stash
+   ldr r1, [r0, #16]
+   mcr p15, 0, r1, c1, c0, 0   @ Write CP15 Control Register


Same here, those two lines can be removed.


+   ldr r1, [r0, #12]
+   mcr p15, 0, r1, c1, c0, 0   @ Write CP15 SCTLR Register
+   ldr r1, [r0, #8]
+   msr cpsr, r1@ Write CPSR
+   bx  lr
+ENDPROC(return_to_fel)
diff --git a/arch/arm/cpu/arm926ejs/sunxi/lowlevel_init.S 
b/arch/arm/cpu/arm926ejs/sunxi/lowlevel_init.S
new file mode 100644
index 00..db09bcc4d0
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/sunxi/lowlevel_init.S
@@ -0,0 +1,67 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * A lowlevel_init function that sets up the stack to call a C function to
+ * perform further init.
+ *
+ * Based on lowlevel_init.S in armv7 directory, which is:
+ *   (C) Copyright 2010 Texas Instruments, 
+ */
+
+#include 
+#include 
+#include 
+
+.pushsection .text.s_init, "ax"
+WEAK(s_init)
+   bx  lr
+ENDPROC(s_init)
+.popsection


I would say we don't ne

Re: [PATCH v3 0/4] rockchip: sdhci: Fix reinit and add HS400 Enhanced Strobe support

Hi Alper,

On Sun, 16 Jan 2022 at 13:18, Alper Nebi Yasak  wrote:
>
> My rk3399-gru-kevin has some problems with the eMMC. The board can boot
> to U-Boot proper with the eMMC working at a low speed, but trying to
> reinitialize it with "mmc dev 0" or "mmc rescan" makes it unusable. If
> the HS400 mode is enabled, it times out while executing tuning and
> doesn't even start at a working state.
>
> To work around these errors, I had implemented support for the HS400
> Enhanced Strobe mode as the first version of this series. I have also
> managed the fix the issue above (related to power-cycling the eMMC PHY),
> which exposed another one with this series: reinitialization at lower
> speeds fail if the ES bit is set. Since fixing that needed changes to
> this series I decided to send the previous fix as part of this instead
> of as an independent patch.
>
> To test, I'm building with the following configs enabled:
>
> +CONFIG_MMC_SPEED_MODE_SET=y
>  [...]
>  CONFIG_MMC_PWRSEQ=y
> +CONFIG_MMC_IO_VOLTAGE=y
> +CONFIG_MMC_UHS_SUPPORT=y
> +CONFIG_MMC_HS400_ES_SUPPORT=y
> +CONFIG_MMC_HS400_SUPPORT=y
>  CONFIG_MMC_DW=y
>  CONFIG_MMC_DW_ROCKCHIP=y
>  CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_SDMA=y
>  CONFIG_MMC_SDHCI_ROCKCHIP=y
>
> and running roughly:
>
> $ mmc rescan [0|1|3|10|11|12]
> $ mmc info
> $ mmc part
> $ load mmc 0:1 0xd000 256MiB.bin
> $ load mmc 0:1 0xd000 16MiB.bin
> $ load mmc 0:1 0xd000 8MiB.bin
>
> I used to test by loading different sizes from a very big file (~7GiB),
> but that's slower than reading fixed-size files for some reason I don't
> know. I thought loading full files would be a better test so I switched
> to those. Here's the differences in info and speeds I get with this:
>
> Mode   | Bus Speed| Bus Width
> ---+--+--
> MMC Legacy | 2500 | 8-bit
> MMC High Speed (26MHz) | 2600 | 8-bit
> MMC High Speed (52MHz) | 5200 | 8-bit
> HS200 (200MHz) | 2| 8-bit
> HS400 (200MHz) | 2| 8-bit DDR
> HS400ES (200MHz)   | 2| 8-bit DDR
>
> Mode   | 256 MiB Load | 16 MiB Load  | 8 MiB Load
> ---+--+--+--
> MMC Legacy | ~22.1  MiB/s | ~21.9  MiB/s | ~21.6  MiB/s
> MMC High Speed (26MHz) | ~22.1  MiB/s | ~21.9  MiB/s | ~21.6  MiB/s
> MMC High Speed (52MHz) | ~43.7  MiB/s | ~42.8  MiB/s | ~41.7  MiB/s
> HS200 (200MHz) | ~161.2 MiB/s | ~149.5 MiB/s | ~137.9 MiB/s
> HS400 (200MHz) | ~254.5 MiB/s | ~235.3 MiB/s | ~216.2 MiB/s
> HS400ES (200MHz)   | ~254.7 MiB/s | ~238.8 MiB/s | ~216.2 MiB/s
>
> Hope I haven't missed anything. Enabling the configs above for each
> board is left to board maintainers as I can't test on those boards.
>
> As an aside, I want to further clean up this driver when I have the time
> (it's a weird combination of what could be three different drivers), but
> wanted to send this as it at least gets the driver to a working state.
>
> Changes in v3:
> - Set DWCMSHC_CARD_IS_EMMC bit in rk3568_emmc_phy_init()
>
> v2: https://patchwork.ozlabs.org/project/uboot/list/?series=280494
>
> Changes in v2:
> - Add patch to fix PHY power cycling at higher speeds
> - Unset ES bit in rk3399 set_control_reg() to fix a reinit issue
> - Don't use unnecessary & for function pointer in ops struct
> - Rename rk3399_set_enhanced_strobe -> rk3399_sdhci_set_enhanced_strobe
> - Rename rk3568_set_enhanced_strobe -> rk3568_sdhci_set_enhanced_strobe
> - Let set_enhanced_strobe() unset the ES bit if mode is not HS400_ES
> - Rewrote cover letter
>
> v1: https://patchwork.ozlabs.org/project/uboot/list/?series=269768
>
> Alper Nebi Yasak (4):
>   mmc: sdhci: Add HS400 Enhanced Strobe support
>   rockchip: sdhci: Fix RK3399 eMMC PHY power cycling
>   rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3399
>   rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3568
>
>  drivers/mmc/rockchip_sdhci.c | 136 ---
>  drivers/mmc/sdhci.c  |  18 +
>  include/sdhci.h  |   1 +
>  3 files changed, 145 insertions(+), 10 deletions(-)

This looks great, but your 'kevin' patches do not seem to be applied
on master. What gives?

Regards,
Simon

[PATCH v3] gitlab: x86: Add a coreboot test