Re: [PATCH v4 2/6] tpm: Support boot measurements

2023-01-25 Thread Ilias Apalodimas
Hi Eddie,

Thanks for the cleanup! Unfortunately this doesn't compile with EFI
selected, but in general it looks pretty good.

On Wed, Jan 25, 2023 at 11:18:06AM -0600, Eddie James wrote:
> Add TPM2 functions to support boot measurement. This includes
> starting up the TPM, initializing/appending the event log, and
> measuring the U-Boot version. Much of the code was used in the
> EFI subsystem, so remove it there and use the common functions.
>
> Signed-off-by: Eddie James 
> ---
>  include/efi_tcg2.h|  44 --
>  include/tpm-v2.h  | 254 ++
>  lib/efi_loader/efi_tcg2.c | 975 +++---
>  lib/tpm-v2.c  | 799 +++
>  4 files changed, 1129 insertions(+), 943 deletions(-)
>
>   HR_NV_INDEX = TPM_HT_NV_INDEX << HR_SHIFT,
>  };
>

[...]

>   }
>
> +}
> +
> +int tcg2_measure_data(struct udevice *dev, struct tcg2_event_log *elog,
> +   u32 pcr_index, u32 size, const u8 *data, u32 event_type,
> +   u32 event_size, const u8 *event)
> +{
> + struct tpml_digest_values digest_list;
> + int rc;
> +
> + rc = tcg2_create_digest(dev, data, size, &digest_list);
> + if (rc)
> + return rc;
> +
> + rc = tcg2_pcr_extend(dev, pcr_index, &digest_list);
> + if (rc)
> + return rc;
> +
> + return tcg2_log_append_check(elog, pcr_index, event_type, &digest_list,
> +  event_size, event);
> +}
> +
> +int tcg2_measure_event(struct udevice *dev, struct tcg2_event_log *elog,
> +u32 pcr_index, u32 event_type, u32 size,
> +const u8 *event)
> +{
> + struct tpml_digest_values digest_list;
> + int rc;
> +
> + rc = tcg2_create_digest(dev, event, size, &digest_list);
> + if (rc)
> + return rc;
> +
> + rc = tcg2_pcr_extend(dev, pcr_index, &digest_list);
> + if (rc)
> + return rc;
> +
> + return tcg2_log_append_check(elog, pcr_index, event_type, &digest_list,
> +  size, event);
> +}

The only difference between these 2 is the measured data.  Can't we make
one function?  If data = NULL we could just measure the event

> +
> +int tcg2_init_log(struct udevice *dev, struct tcg2_event_log *elog)
> +{
> + int rc;
> +
> + rc = tcg2_platform_get_log(dev, (void **)&elog->log, &elog->log_size);
> + if (rc)
> + return rc;
> +
> + elog->log_position = 0;
> + elog->found = false;
> + rc = tcg2_log_parse(dev, elog);
> + if (rc)
> + return rc;
> +
> + if (!elog->found) {
> + rc = tcg2_log_init(dev, elog);
> + if (rc)
> + return rc;

You can get rid of this if and just return rc on the function

> + }
> +
> + return 0;
> +}
> +
> +int tcg2_measurement_init(struct udevice **dev, struct tcg2_event_log *elog)
> +{
> + int rc;
> +
> + rc = tcg2_platform_get_tpm2(dev);
> + if (rc)
> + return rc;
> +
> + rc = tpm_init(*dev);
> + if (rc)
> + return rc;
> +
> + rc = tpm2_startup(*dev, TPM2_SU_CLEAR);
> + if (rc) {
> + tcg2_platform_startup_error(*dev, rc);
> + return rc;
> + }
> +
> + rc = tpm2_self_test(*dev, TPMI_YES);
> + if (rc)
> + printf("%s: self test error, continuing.\n", __func__);

This is the correct init sequence of the TPM.  I was trying to solve
something similar a few days ago [0].  I haven't merged that patch yet,
but I will send a new version that also calls tpm_init() and doesn't exit
on -EBUSY.  Can you use that patch instead of open coding the init
sequence?
Also we should be bailing out on selftest errors?

The problem here is that with U-Boot's lazy binding we might need to init
the TPM in other subsystems and at the very least we can have a function
doing that for us reliably.

> +
> + rc = tcg2_init_log(*dev, elog);
> + if (rc) {
> + tcg2_measurement_term(*dev, elog, true);
> + return rc;
> + }
> +
> + rc = tcg2_measure_event(*dev, elog, 0, EV_S_CRTM_VERSION,
> + strlen(version_string) + 1,
> + (u8 *)version_string);
> + if (rc) {
> + tcg2_measurement_term(*dev, elog, true);
> + return rc;
> + }
> +
> + return 0;
> +}
> +
> +void tcg2_measurement_term(struct udevice *dev, struct tcg2_event_log *elog,
> +bool error)
> +{
> + u32 event = error ? 0x1 : 0x;
> + int i;
> +
> + for (i = 0; i < 8; ++i)
> + tcg2_measure_event(dev, elog, i, EV_SEPARATOR, sizeof(event),
> +(const u8 *)&event);

Is the separator event at the end of the eventlog described in the spec?

> +
> + if (elog->log)
> + unmap_physmem(elog->log, MAP_NOCACHE);
> +}
> +
> +__weak int tcg2_platform_get_log(s

[PATCH] powerpc/mpc85xx: use board env file for socrates board

2023-01-25 Thread Heiko Schocher
as Tom suggested get rid of CFG_EXTRA_ENV_SETTINGS and
enable CONFIG_ENV_SOURCE_FILE and use text file

board/socrates/socrates.env

which contains the default environment. While at it,
cleanup the default Environment.

Signed-off-by: Heiko Schocher 
Suggested-by: Tom Rini 

---
This patch is a follow up as requested from Tom to socrates series
posted here:

https://lists.denx.de/pipermail/u-boot/2023-January/506030.html


 board/socrates/socrates.env | 51 ++
 configs/socrates_defconfig  |  5 +--
 include/configs/socrates.h  | 62 -
 3 files changed, 54 insertions(+), 64 deletions(-)
 create mode 100644 board/socrates/socrates.env

diff --git a/board/socrates/socrates.env b/board/socrates/socrates.env
new file mode 100644
index 00..14c6ada34d
--- /dev/null
+++ b/board/socrates/socrates.env
@@ -0,0 +1,51 @@
+addcons=setenv bootargs $bootargs console=$consdev,$baudrate
+addip=setenv bootargs $bootargs 
ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off panic=1
+addmtd=setenv bootargs ${bootargs} ${mtdparts}
+baudrate=CONFIG_BAUDRATE
+boot_nor=run ramargs addcons addmtd;
+   if test -n ${RescueSystemJumper} ;then
+   run rescueargs;
+   else
+   if imi ${system1_addr};then
+   bootm ${system1_addr};
+   else
+   setenv RescueSystemJumper 1;run rescueargs;
+   fi;
+   fi;
+   if imi ${system2_addr}; then
+   bootm ${system2_addr};
+   fi;
+boot_usb=usb start;
+   ext2load usb 0 ${usb_boot_script_r} ${usb_boot_script};
+   if imi ${usb_boot_script_r};then
+   source ${usb_boot_script_r}#conf;
+   fi;
+bootcmd=CONFIG_BOOTCOMMAND
+bootdelay=CONFIG_BOOTDELAY
+clean_data=era FFA0 FFFE
+clean_uboot_env=protect off FFF0 FFF3;era FFF0 FFF3
+consdev=ttyS0
+ethprime=eTSEC0
+initrd_high=0x0300
+loadaddr=0x0200
+loads_echo=1
+mtdids=CONFIG_MTDIDS_DEFAULT
+mtdparts=CONFIG_MTDPARTS_DEFAULT
+netdev=eth0
+nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath
+preboot=echo;echo Welcome on the Socrates Board;echo
+ramargs=setenv bootargs root=/dev/ram rw
+rescueargs=setenv bootargs $bootargs RescueSystemJumper=$RescueSystemJumper
+rootpath=/opt/poky/3.1.17
+system1_addr=FE00
+system1_file=system1.itb
+system2_addr=FED0
+system2_file=system2.itb
+uboot_addr=FFF4
+uboot_file=u-boot.bin
+update_system1=tftp 11 ${system1_file};era ${system1_addr} FECF;cp.b 
11 ${system1_addr} ${filesize};setenv filesize
+update_system2=tftp 11 ${system2_file};era ${system2_addr} FF9F;cp.b 
11 ${system2_addr} ${filesize};setenv filesize
+update_uboot=tftp 11 ${uboot_file};protect off ${uboot_addr} ;era 
${uboot_addr} ;cp.b 11 ${uboot_addr} ${filesize};setenv filesize
+usb_boot_script=/boot/socrates_boot.autoscr
+usb_boot_script_r=10
+verify=1
diff --git a/configs/socrates_defconfig b/configs/socrates_defconfig
index e03c971b5e..0f4786958b 100644
--- a/configs/socrates_defconfig
+++ b/configs/socrates_defconfig
@@ -31,9 +31,9 @@ CONFIG_BOOT_RETRY=y
 CONFIG_BOOT_RETRY_TIME=120
 CONFIG_RESET_TO_RETRY=y
 CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="run boot_nor"
+CONFIG_BOOTCOMMAND="run boot_usb;run boot_nor"
 CONFIG_USE_PREBOOT=y
-CONFIG_PREBOOT="echo;echo Welcome on the ABB Socrates Board;echo"
+CONFIG_PREBOOT="echo;echo Welcome on the Socrates Board;echo"
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_BOARD_EARLY_INIT_R=y
 # CONFIG_HWCONFIG is not set
@@ -70,6 +70,7 @@ 
CONFIG_MTDIDS_DEFAULT="nor0=fe00.nor_flash,nand0=socrates_nand"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=fe00.nor_flash:13312k(system1),13312k(system2),5120k(data),128k(env),128k(env-red),768k(u-boot);socrates_nand:256M(ubi-data1),-(ubi-data2)"
 # CONFIG_CMD_IRQ is not set
 CONFIG_OF_CONTROL=y
+CONFIG_ENV_SOURCE_FILE="socrates"
 CONFIG_ENV_IS_NOWHERE=y
 CONFIG_ENV_IS_IN_FLASH=y
 CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
diff --git a/include/configs/socrates.h b/include/configs/socrates.h
index 305914de85..64cc17ca7c 100644
--- a/include/configs/socrates.h
+++ b/include/configs/socrates.h
@@ -109,68 +109,6 @@
  */
 #define CFG_SYS_BOOTMAPSZ  (8 << 20)   /* Initial Memory map for Linux 
*/
 
-#define SOCRATES_ENV_MTD \
-   "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \
-   "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
-   "addmtd=setenv bootargs ${bootargs} ${mtdparts}\0"
-
-#defineCFG_EXTRA_ENV_SETTINGS  \
-   "netdev=eth0\0" \
-   "consdev=ttyS0\0"   \
-   "initrd_high=0x0300\0"  \
-   "uboot_file=/home/tftp/syscon3/u-boot.bin\0"\
-   "bootfile=/home/tftp/syscon3/uImage\0"  \
-   "fdt_file=/home/tftp/syscon3/socrates.d

Re: [PATCH v4 3/6] bootm: Support boot measurement

2023-01-25 Thread Ilias Apalodimas
Hi Eddie,

On Wed, Jan 25, 2023 at 11:18:07AM -0600, Eddie James wrote:
> Add a configuration option to measure the boot through the bootm
> function. Add the measurement state to the booti and bootz paths
> as well.
>
> Signed-off-by: Eddie James 
> ---
>  boot/Kconfig| 23 
>  boot/bootm.c| 70 +
>  cmd/booti.c |  1 +
>  cmd/bootm.c |  2 ++
>  cmd/bootz.c |  1 +
>  include/bootm.h |  2 ++
>  include/image.h |  1 +
>  7 files changed, 100 insertions(+)
>
> diff --git a/boot/Kconfig b/boot/Kconfig
> index fdcfbae7b2..831b9e954c 100644
> --- a/boot/Kconfig
> +++ b/boot/Kconfig
> @@ -601,6 +601,29 @@ config LEGACY_IMAGE_FORMAT
> loaded. If a board needs the legacy image format support in this
> case, enable it here.
>
> +config MEASURED_BOOT
> + bool "Measure boot images and configuration to TPM and event log"
> + depends on HASH && TPM_V2
> + help
> +   This option enables measurement of the boot process. Measurement
> +   involves creating cryptographic hashes of the binary images that
> +   are booting and storing them in the TPM. In addition, a log of
> +   these hashes is stored in memory for the OS to verify the booted
> +   images and configuration. Enable this if the OS has configured
> +   some memory area for the event log and you intend to use some
> +   attestation tools on your system.
> +
> +if MEASURED_BOOT
> + config MEASURE_DEVICETREE
> + bool "Measure the devicetree image"
> + default y if MEASURED_BOOT
> + help
> +   On some platforms, the devicetree is not static as it may contain
> +   random MAC addresses or other such data that changes each boot.
> +   Therefore, it should not be measured into the TPM. In that case,
> +   disable the measurement here.
> +endif # MEASURED_BOOT
> +
>  config SUPPORT_RAW_INITRD
>   bool "Enable raw initrd images"
>   help
> diff --git a/boot/bootm.c b/boot/bootm.c
> index 15fce8ad95..c8423f2c60 100644
> --- a/boot/bootm.c
> +++ b/boot/bootm.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #if defined(CONFIG_CMD_USB)
>  #include 
>  #endif
> @@ -659,6 +660,72 @@ int bootm_process_cmdline_env(int flags)
>   return 0;
>  }
>
> +int bootm_measure(struct bootm_headers *images)
> +{
> + int ret = 0;
> +
> + /* Skip measurement if EFI is going to do it */
> + if (images->os.os == IH_OS_EFI &&
> + IS_ENABLED(CONFIG_EFI_TCG2_PROTOCOL) &&
> + IS_ENABLED(CONFIG_BOOTM_EFI))
> + return ret;
> +
> + if (IS_ENABLED(CONFIG_MEASURED_BOOT)) {
> + struct tcg2_event_log elog;
> + struct udevice *dev;
> + void *initrd_buf;
> + void *image_buf;
> + const char *s;
> + u32 rd_len;
> +
> + ret = tcg2_measurement_init(&dev, &elog);
> + if (ret)
> + return ret;
> +
> + image_buf = map_sysmem(images->os.image_start,
> +images->os.image_len);
> + ret = tcg2_measure_data(dev, &elog, 8, images->os.image_len,
> + image_buf, EV_COMPACT_HASH,
> + strlen("linux") + 1, (u8 *)"linux");
> + if (ret)
> + goto unmap_image;
> +
> + rd_len = images->rd_end - images->rd_start;
> + initrd_buf = map_sysmem(images->rd_start, rd_len);
> + ret = tcg2_measure_data(dev, &elog, 8, rd_len, initrd_buf,
> + EV_COMPACT_HASH, strlen("initrd") + 1,
> + (u8 *)"initrd");

The kernel, if loaded with EFI,  measures the initrd data into PCR9.
Although it's not important can we please use the same PCR here?

> + if (ret)
> + goto unmap_initrd;
> +
> + if (IS_ENABLED(CONFIG_MEASURE_DEVICETREE)) {
> + ret = tcg2_measure_data(dev, &elog, 9, images->ft_len,
> + (u8 *)images->ft_addr,
> + EV_TABLE_OF_DEVICES,
> + strlen("dts") + 1,
> + (u8 *)"dts");

The PC client spec describes how ACPI data should be measured.  Although it
has no wording on the DTB, I think it should be treated in a similar
fashion.  This [0] was trying to do the same thing for EFI.  Any reason we
can't use PCR0 here?

> + if (ret)
> + goto unmap_initrd;
> + }
> +
> + s = env_get("bootargs");
> + if (!s)
> + s = "";
> + ret = tcg2_measure_data(dev, &elog, 1, strlen(s) + 1, (u8 *)s,
> + EV_PLATFORM_CONFIG_FLAGS,
> + 

Re: [PATCH v4 4/6] tpm: sandbox: Update for needed TPM2 capabilities

2023-01-25 Thread Ilias Apalodimas
On Wed, Jan 25, 2023 at 11:18:08AM -0600, Eddie James wrote:
> The driver needs to support getting the PCRs in the capabilities
> command. Fix various other things and support the max number
> of PCRs for TPM2.
>
> Signed-off-by: Eddie James 
> Reviewed-by: Simon Glass 
> ---
>  drivers/tpm/tpm2_tis_sandbox.c | 100 -
>  1 file changed, 72 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/tpm/tpm2_tis_sandbox.c b/drivers/tpm/tpm2_tis_sandbox.c
> index dd94bdc31f..ea7fb5e3cb 100644
> --- a/drivers/tpm/tpm2_tis_sandbox.c
> +++ b/drivers/tpm/tpm2_tis_sandbox.c
> @@ -22,11 +22,6 @@ enum tpm2_hierarchy {
>   TPM2_HIERARCHY_NB,
>  };
>
> -/* Subset of supported capabilities */
> -enum tpm2_capability {
> - TPM_CAP_TPM_PROPERTIES = 0x6,
> -};
> -
>  /* Subset of supported properties */
>  #define TPM2_PROPERTIES_OFFSET 0x020E
>
> @@ -38,7 +33,8 @@ enum tpm2_cap_tpm_property {
>   TPM2_PROPERTY_NB,
>  };
>
> -#define SANDBOX_TPM_PCR_NB 1
> +#define SANDBOX_TPM_PCR_NB TPM2_MAX_PCRS
> +#define SANDBOX_TPM_PCR_SELECT_MAX   ((SANDBOX_TPM_PCR_NB + 7) / 8)
>
>  /*
>   * Information about our TPM emulation. This is preserved in the sandbox
> @@ -433,7 +429,7 @@ static int sandbox_tpm2_xfer(struct udevice *dev, const 
> u8 *sendbuf,
>   int i, j;
>
>   /* TPM2_GetProperty */
> - u32 capability, property, property_count;
> + u32 capability, property, property_count, val;
>
>   /* TPM2_PCR_Read/Extend variables */
>   int pcr_index = 0;
> @@ -542,19 +538,32 @@ static int sandbox_tpm2_xfer(struct udevice *dev, const 
> u8 *sendbuf,
>   case TPM2_CC_GET_CAPABILITY:
>   capability = get_unaligned_be32(sent);
>   sent += sizeof(capability);
> - if (capability != TPM_CAP_TPM_PROPERTIES) {
> - printf("Sandbox TPM only support TPM_CAPABILITIES\n");
> - return TPM2_RC_HANDLE;
> - }
> -
>   property = get_unaligned_be32(sent);
>   sent += sizeof(property);
> - property -= TPM2_PROPERTIES_OFFSET;
> -
>   property_count = get_unaligned_be32(sent);
>   sent += sizeof(property_count);
> - if (!property_count ||
> - property + property_count > TPM2_PROPERTY_NB) {
> +
> + switch (capability) {
> + case TPM2_CAP_PCRS:
> + break;
> + case TPM2_CAP_TPM_PROPERTIES:
> + if (!property_count) {
> + rc = TPM2_RC_HANDLE;
> + return sandbox_tpm2_fill_buf(recv, recv_len,
> +  tag, rc);
> + }
> +
> + if (property > TPM2_PROPERTIES_OFFSET &&
> + ((property - TPM2_PROPERTIES_OFFSET) +
> +  property_count > TPM2_PROPERTY_NB)) {
> + rc = TPM2_RC_HANDLE;
> + return sandbox_tpm2_fill_buf(recv, recv_len,
> +  tag, rc);
> + }
> + break;
> + default:
> + printf("Sandbox TPM2 only supports TPM2_CAP_PCRS or "
> +"TPM2_CAP_TPM_PROPERTIES\n");
>   rc = TPM2_RC_HANDLE;
>   return sandbox_tpm2_fill_buf(recv, recv_len, tag, rc);
>   }
> @@ -578,18 +587,53 @@ static int sandbox_tpm2_xfer(struct udevice *dev, const 
> u8 *sendbuf,
>   put_unaligned_be32(capability, recv);
>   recv += sizeof(capability);
>
> - /* Give the number of properties that follow */
> - put_unaligned_be32(property_count, recv);
> - recv += sizeof(property_count);
> -
> - /* Fill with the properties */
> - for (i = 0; i < property_count; i++) {
> - put_unaligned_be32(TPM2_PROPERTIES_OFFSET + property +
> -i, recv);
> - recv += sizeof(property);
> - put_unaligned_be32(tpm->properties[property + i],
> -recv);
> - recv += sizeof(property);
> + switch (capability) {
> + case TPM2_CAP_PCRS:
> + /* Give the number of algorithms supported - just 
> SHA256 */
> + put_unaligned_be32(1, recv);
> + recv += sizeof(u32);
> +
> + /* Give SHA256 algorithm */
> + put_unaligned_be16(TPM2_ALG_SHA256, recv);
> + recv += sizeof(u16);
> +
> + /* Select the PCRs supported */
> + *recv = SANDBOX_TPM_PCR_SELECT_MAX;
> + recv++;
> +
> + /* Activate all the PCR bits */
> +

Re: [PATCH v3] watchdog: Add a watchdog driver for Raspberry Pi boards

2023-01-25 Thread Stefan Roese

On 1/25/23 10:57, ETIENNE DUBLE wrote:

This driver supports the bcm2835 watchdog found on
Raspberry Pi boards.
It is derived from the Linux driver and was tested
on two Raspberry Pi board versions (B+ and 3B+).

Signed-off-by: Etienne Dublé 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
Changes for v2:
- fixed whitespaces in email
- moved a static variable to the priv struct
Changes for v3:
- used the max timeout value the hardware supports
- turned the warning to a one-line message

  drivers/watchdog/Kconfig   |   9 +++
  drivers/watchdog/Makefile  |   1 +
  drivers/watchdog/bcm2835_wdt.c | 132 +
  3 files changed, 142 insertions(+)
  create mode 100644 drivers/watchdog/bcm2835_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index f1b1cf63ca..06c0d630c8 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -30,6 +30,7 @@ config WATCHDOG_TIMEOUT_MSECS
default 128000 if ARCH_MX7 || ARCH_VF610
default 3 if ARCH_SOCFPGA
default 16000 if ARCH_SUNXI
+   default 15000 if ARCH_BCM283X
default 6
help
  Watchdog timeout in msec
@@ -326,6 +327,14 @@ config WDT_SUNXI
help
  Enable support for the watchdog timer in Allwinner sunxi SoCs.
  
+config WDT_BCM2835

+   bool "Broadcom 2835 watchdog timer support"
+   depends on WDT && ARCH_BCM283X
+   default y
+   help
+ Enable support for the watchdog timer in Broadcom 283X SoCs such
+ as Raspberry Pi boards.
+
  config XILINX_TB_WATCHDOG
bool "Xilinx Axi watchdog timer support"
depends on WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 446d961d7d..f99915960c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_WDT_APPLE) += apple_wdt.o
  obj-$(CONFIG_WDT_ARMADA_37XX) += armada-37xx-wdt.o
  obj-$(CONFIG_WDT_ASPEED) += ast_wdt.o
  obj-$(CONFIG_WDT_AST2600) += ast2600_wdt.o
+obj-$(CONFIG_WDT_BCM2835) += bcm2835_wdt.o
  obj-$(CONFIG_WDT_BCM6345) += bcm6345_wdt.o
  obj-$(CONFIG_WDT_BOOKE) += booke_wdt.o
  obj-$(CONFIG_WDT_CORTINA) += cortina_wdt.o
diff --git a/drivers/watchdog/bcm2835_wdt.c b/drivers/watchdog/bcm2835_wdt.c
new file mode 100644
index 00..3c1ead3dda
--- /dev/null
+++ b/drivers/watchdog/bcm2835_wdt.c
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2013 Lubomir Rintel 
+ * Copyright (C) 2023 Etienne Dublé (CNRS) 
+ *
+ * This code is mostly derived from the linux driver.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define PM_RSTC0x1c
+#define PM_WDOG0x24
+
+#define PM_PASSWORD0x5a00
+
+/* The hardware supports a maximum timeout value of 0xf ticks
+ * (just below 16 seconds).
+ */
+#define PM_WDOG_MAX_TICKS  0x000f
+#define PM_RSTC_WRCFG_CLR  0xffcf
+#define PM_RSTC_WRCFG_FULL_RESET   0x0020
+#define PM_RSTC_RESET  0x0102
+
+#define MS_TO_WDOG_TICKS(x) (((x) << 16) / 1000)
+
+struct bcm2835_wdt_priv {
+   void __iomem *base;
+   u64 timeout_ticks;
+};
+
+static int bcm2835_wdt_start_ticks(struct udevice *dev,
+  u64 timeout_ticks, ulong flags)
+{
+   struct bcm2835_wdt_priv *priv = dev_get_priv(dev);
+   void __iomem *base = priv->base;
+   u32 cur;
+
+   writel(PM_PASSWORD | timeout_ticks, base + PM_WDOG);
+   cur = readl(base + PM_RSTC);
+   writel(PM_PASSWORD | (cur & PM_RSTC_WRCFG_CLR) | 
PM_RSTC_WRCFG_FULL_RESET,
+  base + PM_RSTC);
+
+   return 0;
+}
+
+static int bcm2835_wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags)
+{
+   struct bcm2835_wdt_priv *priv = dev_get_priv(dev);
+
+   priv->timeout_ticks = MS_TO_WDOG_TICKS(timeout_ms);
+
+   if (priv->timeout_ticks > PM_WDOG_MAX_TICKS) {
+   printf("bcm2835_wdt: the timeout value is too high, using ~16s 
instead.\n");
+   priv->timeout_ticks = PM_WDOG_MAX_TICKS;
+   }
+
+   return bcm2835_wdt_start_ticks(dev, priv->timeout_ticks, flags);
+}
+
+static int bcm2835_wdt_reset(struct udevice *dev)
+{
+   struct bcm2835_wdt_priv *priv = dev_get_priv(dev);
+
+   /* restart the timer with the value of priv->timeout_ticks
+* saved from the last bcm2835_wdt_start() call.
+*/
+   return bcm2835_wdt_start_ticks(dev, priv->timeout_ticks, 0);
+}
+
+static int bcm2835_wdt_stop(struct udevice *dev)
+{
+   struct bcm2835_wdt_priv *priv = dev_get_priv(dev);
+   void __iomem *base = priv->base;
+
+   writel(PM_PASSWORD | PM_RSTC_RESET, base + PM_RSTC);
+
+   return 0;
+}
+
+static int bcm2835_wdt_expire_now(struct udevice *dev, ulong flags)
+{
+   int ret;
+
+   /* use a timeout of 10 ticks (~150us) */
+

[PATCH] efi_loader: leave attribute check to StMM variable service

2023-01-25 Thread Masahisa Kojima
Current U-Boot supports two EFI variable service, U-Boot own
implementation and op-tee based StMM variable service.
For latter case, parameter check should leave to StMM.
This commit removes the attribute check from the common
function(efi_query_variable_info) and moves it to
lib/efi_loader/efi_variable.c.

Signed-off-by: Masahisa Kojima 
---
 lib/efi_loader/efi_var_common.c | 10 +-
 lib/efi_loader/efi_variable.c   | 10 ++
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/lib/efi_loader/efi_var_common.c b/lib/efi_loader/efi_var_common.c
index eb83702781..ad50bffd2b 100644
--- a/lib/efi_loader/efi_var_common.c
+++ b/lib/efi_loader/efi_var_common.c
@@ -165,17 +165,9 @@ efi_status_t EFIAPI efi_query_variable_info(
 
if (!maximum_variable_storage_size ||
!remaining_variable_storage_size ||
-   !maximum_variable_size ||
-   !(attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS))
+   !maximum_variable_size)
return EFI_EXIT(EFI_INVALID_PARAMETER);
 
-   if ((attributes & ~(u32)EFI_VARIABLE_MASK) ||
-   (attributes & EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS) ||
-   (attributes & EFI_VARIABLE_HARDWARE_ERROR_RECORD) ||
-   (!IS_ENABLED(CONFIG_EFI_SECURE_BOOT) &&
-(attributes & EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS)))
-   return EFI_EXIT(EFI_UNSUPPORTED);
-
ret = efi_query_variable_info_int(attributes,
  maximum_variable_storage_size,
  remaining_variable_storage_size,
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 7c32adf6e5..86f39181e0 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -349,6 +349,16 @@ efi_status_t efi_query_variable_info_int(u32 attributes,
 u64 *remaining_variable_storage_size,
 u64 *maximum_variable_size)
 {
+   if (!(attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS))
+   return EFI_EXIT(EFI_INVALID_PARAMETER);
+
+   if ((attributes & ~(u32)EFI_VARIABLE_MASK) ||
+   (attributes & EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS) ||
+   (attributes & EFI_VARIABLE_HARDWARE_ERROR_RECORD) ||
+   (!IS_ENABLED(CONFIG_EFI_SECURE_BOOT) &&
+(attributes & EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS)))
+   return EFI_EXIT(EFI_UNSUPPORTED);
+
*maximum_variable_storage_size = EFI_VAR_BUF_SIZE -
 sizeof(struct efi_var_file);
*remaining_variable_storage_size = efi_var_mem_free();
-- 
2.17.1



Re: [PATCH] Revert "config: tools only: add VIDEO to build bmp_logo"

2023-01-25 Thread Fabio Estevam
Hi Rasmus,

On Wed, Jan 25, 2023 at 11:59 AM Rasmus Villemoes
 wrote:

> So I also got curious about that part, because when I build
> tools-only_defconfig with older U-Boot releases I don't get a bmp_logo
> tool built.
>
> I think I figured that out (but only after it's been revealed that this
> was about Fedora's packaging of u-boot-tools). Fedora seems to do
>
> %make_build HOSTCC="gcc $RPM_OPT_FLAGS" CROSS_COMPILE=""
> tools-only_defconfig O=builds/
>
> %make_build HOSTCC="gcc $RPM_OPT_FLAGS" CROSS_COMPILE="" tools-all O=builds/
>
> so unlike the Yocto case, the build target is tools-all and not
> cross_tools. Hence the top Makefile sets HOST_TOOLS_ALL=y, which in
> tools/Makefile then hits
>
> ifneq ($(HOST_TOOLS_ALL),)
> CONFIG_ARCH_KIRKWOOD = y
> ...
> endif
>
> and that block used to, until 1dc6517649f2, contain
>
> CONFIG_LCD_LOGO = y
>
> with the corresponding
>
> hostprogs-$(CONFIG_LCD_LOGO) += bmp_logo
>
> further down.
>
> IOW, it wasn't really tools-only_defconfig per se that used to cause
> bmp_logo to get built, it was the tools-all target.

Thanks for the in-depth investigation, appreciated it.


RE: [0/4] Add eMMC 5.1 support for Versal NET

2023-01-25 Thread Jaehoon Chung
Hi,

> -Original Message-
> From: Michal Simek 
> Sent: Tuesday, January 24, 2023 10:02 PM
> To: Ashok Reddy Soma ; u-boot@lists.denx.de; 
> Jaehoon Chung
> 
> Cc: peng@nxp.com; kever.y...@rock-chips.com; 
> hayashi.kunih...@socionext.com;
> alpernebiya...@gmail.com; xypron.g...@gmx.de; g...@amd.com
> Subject: Re: [0/4] Add eMMC 5.1 support for Versal NET
> 
> Hi Jaehoon,
> 
> On 1/10/23 12:31, Ashok Reddy Soma wrote:
> > This patch series,
> >   - Add support for eMMC5.1 on Versal NET platform by adding new compatible
> > string and PHY support.
> >   - Add support for input and output tap delays for eMMC
> >   - Add support for enabling HS400 in host capabilities by checking quirk.
> >   - Add quirk to support HS400 for Versal NET
> >
> > Ashok Reddy Soma (4):
> >mmc: zynq_sdhci: Add support for eMMC5.1 for Versal NET platform
> >mmc: sdhci: Check and call config_dll callback functions
> >mmc: sdhci: Enable HS400 support if available in caps
> >mmc: zynq_sdhci: Add support and quirk for HS400
> >
> >   drivers/mmc/sdhci.c  |  20 +++
> >   drivers/mmc/zynq_sdhci.c | 292 ++-
> >   include/sdhci.h  |   5 +
> >   3 files changed, 314 insertions(+), 3 deletions(-)
> >
> 
> Can you please review this series?

Sorry for too late. I will review them. 

Best Regards,
Jaehoon Chung

> 
> Thanks,
> Michal



Re: [PATCH] tools: mkimage: Allow changing U-Boot image magic

2023-01-25 Thread Simon Glass
Hi Hauke,

On Mon, 23 Jan 2023 at 15:45, Hauke Mehrtens  wrote:
>
> On 1/23/23 19:49, Simon Glass wrote:
> > Hi,
> >
> > On Sun, 22 Jan 2023 at 07:20, Hauke Mehrtens  wrote:
> >>
> >> Extend mkimage with a new optional option -M to specify a special U-Boot
> >> image magic number. OpenWrt ships images for about 30 different boards
> >> with vendor boot loaders which are expecting the mkimage format, but
> >> with a different image magic.
> >>
> >> OpenWrt includes this patch for mkimage more than 10 years.
> >> It was added by Gabor Juhos in this commit:
> >> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=f3d2056b81b7a92d28402c22736534d84fe23cfe
> >>
> >> Cc: Gabor Juhos 
> >> Signed-off-by: Hauke Mehrtens 
> >> ---
> >>   tools/default_image.c |  4 ++--
> >>   tools/imagetool.h |  1 +
> >>   tools/mkimage.c   | 14 --
> >>   3 files changed, 15 insertions(+), 4 deletions(-)
> >
> > Strange...what is the different magic for?
>
> I do not know really know why some vendors do this. With Openwrt we
> create images which user can install on their devices. We normally do
> not change the vendor bootloader and create an image which is compatible
> with the vendor boot loader.
>
> I assume the vendors want to prevent users from installing "unsupported"
> images, but still want to use something close to the U-Boot image. With
> a different magic their boot loader (often vendor modified U-Boot) can
> prevent the user from installing "wrong" images.
>
> I saw this on many devices sold by NetGear for example these devices:
> NETGEAR WNDR4300
> NETGEAR WNDR4500
> NETGEAR WNR1000
> NETGEAR WNR612 v2
>
> I have also seen it from other vendors, probably some ODM or OEM does this.
>

OK, but I think it would be better to use a FIT, thus allowing the
vendor to add more info into the file.

Are the vendor bootloaders upstreamed?

Anyway, I don't see a big problem with doing this. Can you please
update the mkimage man page? Do we need to update dumpimage also?

Regards,
Simon


Re: [PATCH 1/7] README: correct path to sandbox.rst

2023-01-25 Thread Simon Glass
On Wed, 25 Jan 2023 at 11:15, Heinrich Schuchardt
 wrote:
>
> sandbox.rst was moved.
>
> Fixes: 2851cc94f301 ("dm: Add documentation for host command and 
> implementation")
> Signed-off-by: Heinrich Schuchardt 
> ---
>  README | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH v4 5/6] test: Add sandbox TPM boot measurement

2023-01-25 Thread Simon Glass
Hi Eddie,

On Wed, 25 Jan 2023 at 10:18, Eddie James  wrote:
>
> Use the sandbox TPM driver to measure some boot images in a unit
> test case.
>
> Signed-off-by: Eddie James 
> ---
>  arch/sandbox/dts/sandbox.dtsi | 14 
>  arch/sandbox/dts/test.dts | 13 +++
>  configs/sandbox_defconfig |  1 +
>  include/test/suites.h |  1 +
>  test/boot/Makefile|  1 +
>  test/boot/measurement.c   | 66 +++
>  test/cmd_ut.c |  2 ++
>  7 files changed, 98 insertions(+)
>  create mode 100644 test/boot/measurement.c

Reviewed-by: Simon Glass 

Please see below

>
> diff --git a/arch/sandbox/dts/sandbox.dtsi b/arch/sandbox/dts/sandbox.dtsi
> index 18bf1cb5b6..3f0e192a83 100644
> --- a/arch/sandbox/dts/sandbox.dtsi
> +++ b/arch/sandbox/dts/sandbox.dtsi
> @@ -4,9 +4,22 @@
>   * and sandbox64 builds.
>   */
>
> +#include 
> +
>  #define USB_CLASS_HUB  9
>
>  / {
> +   reserved-memory {
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   ranges;
> +
> +   event_log: tcg_event_log {
> +   no-map;
> +   reg = <(CFG_SYS_SDRAM_SIZE - 0x2000) 0x2000>;
> +   };
> +   };
> +
> binman {
> };
>
> @@ -332,6 +345,7 @@
>
> tpm2 {
> compatible = "sandbox,tpm2";
> +   memory-region = <&event_log>;
> };
>
> triangle {
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index 9d96e479ca..c334b89faa 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -9,6 +9,7 @@
>
>  /dts-v1/;
>
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -66,6 +67,17 @@
> osd0 = "/osd";
> };
>
> +   reserved-memory {
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   ranges;
> +
> +   event_log: tcg_event_log {
> +   no-map;
> +   reg = <(CFG_SYS_SDRAM_SIZE - 0x2000) 0x2000>;
> +   };
> +   };
> +
> binman: binman {
> };
>
> @@ -1343,6 +1355,7 @@
>
> tpm2 {
> compatible = "sandbox,tpm2";
> +   memory-region = <&event_log>;
> };
>
> uart0: serial {
> diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> index 34c342b6f5..9c4985adcf 100644
> --- a/configs/sandbox_defconfig
> +++ b/configs/sandbox_defconfig
> @@ -337,3 +337,4 @@ CONFIG_TEST_FDTDEC=y
>  CONFIG_UNIT_TEST=y
>  CONFIG_UT_TIME=y
>  CONFIG_UT_DM=y
> +CONFIG_MEASURED_BOOT=y
> diff --git a/include/test/suites.h b/include/test/suites.h
> index 9ce49cbb03..4c284bbeaa 100644
> --- a/include/test/suites.h
> +++ b/include/test/suites.h
> @@ -44,6 +44,7 @@ int do_ut_font(struct cmd_tbl *cmdtp, int flag, int argc, 
> char *const argv[]);
>  int do_ut_lib(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
>  int do_ut_loadm(struct cmd_tbl *cmdtp, int flag, int argc, char *const 
> argv[]);
>  int do_ut_log(struct cmd_tbl *cmdtp, int flag, int argc, char * const 
> argv[]);
> +int do_ut_measurement(struct cmd_tbl *cmdtp, int flag, int argc, char * 
> const argv[]);
>  int do_ut_mem(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
>  int do_ut_optee(struct cmd_tbl *cmdtp, int flag, int argc, char *const 
> argv[]);
>  int do_ut_overlay(struct cmd_tbl *cmdtp, int flag, int argc,
> diff --git a/test/boot/Makefile b/test/boot/Makefile
> index 22ed61c8fa..2dbb032a7e 100644
> --- a/test/boot/Makefile
> +++ b/test/boot/Makefile
> @@ -4,6 +4,7 @@
>
>  obj-$(CONFIG_BOOTSTD) += bootdev.o bootstd_common.o bootflow.o bootmeth.o
>  obj-$(CONFIG_FIT) += image.o
> +obj-$(CONFIG_MEASURED_BOOT) += measurement.o
>
>  obj-$(CONFIG_EXPO) += expo.o
>
> diff --git a/test/boot/measurement.c b/test/boot/measurement.c
> new file mode 100644
> index 00..2155208894
> --- /dev/null
> +++ b/test/boot/measurement.c
> @@ -0,0 +1,66 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Test for measured boot functions
> + *
> + * Copyright 2023 IBM Corp.
> + * Written by Eddie James 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MEASUREMENT_TEST(_name, _flags)\
> +   UNIT_TEST(_name, _flags, measurement_test)
> +
> +static int measure(struct unit_test_state *uts)
> +{
> +   struct bootm_headers images;
> +   const size_t size = 1024;
> +   u8 *kernel;
> +   u8 *initrd;
> +   size_t i;
> +
> +   kernel = malloc(size);
> +   initrd = malloc(size);
> +
> +   images.os.image_start = map_to_sysmem(kernel);
> +   images.os.image_len = size;
> +
> +   images.rd_start = map_to_sysmem(initrd);
> +   images.rd_end = images.rd_start + size;
> +
> +   images.ft_addr = malloc(size);


> +   images.ft_len = size;
> +
> +   env_set("bootargs", 

Re: [PATCH 2/2] mmc: erase: Use TRIM erase when available

2023-01-25 Thread Simon Glass
Hi Loic,

On Wed, 25 Jan 2023 at 10:31, Loic Poulain  wrote:
>
> The default erase command applies on erase group unit, and
> simply round down to erase group size. When the start block
> is not aligned to erase group size (e.g. erasing partition)
> it causes unwanted erasing of the previous blocks, part of
> the same erase group (e.g. owned by other logical partition,
> or by the partition table itself).
>
> To prevent this issue, a simple solution is to use TRIM as
> argument of the Erase command, which is usually supported
> with eMMC > 4.0, and allow to apply erase operation to write
> blocks instead of erase group
>
> Signed-off-by: Loic Poulain 
> ---
>  drivers/mmc/mmc_write.c | 34 +++---
>  1 file changed, 23 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/mmc/mmc_write.c b/drivers/mmc/mmc_write.c
> index 5b7aeeb012..a6f93380dd 100644
> --- a/drivers/mmc/mmc_write.c
> +++ b/drivers/mmc/mmc_write.c
> @@ -15,7 +15,7 @@
>  #include 
>  #include "mmc_private.h"
>
> -static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt)
> +static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt, u32 
> args)
>  {
> struct mmc_cmd cmd;
> ulong end;
> @@ -52,7 +52,7 @@ static ulong mmc_erase_t(struct mmc *mmc, ulong start, 
> lbaint_t blkcnt)
> goto err_out;
>
> cmd.cmdidx = MMC_CMD_ERASE;
> -   cmd.cmdarg = MMC_ERASE_ARG;
> +   cmd.cmdarg = args ? args : MMC_ERASE_ARG;
> cmd.resp_type = MMC_RSP_R1b;
>
> err = mmc_send_cmd(mmc, &cmd, NULL);
> @@ -77,7 +77,7 @@ ulong mmc_berase(struct blk_desc *block_dev, lbaint_t 
> start, lbaint_t blkcnt)
>  #endif
> int dev_num = block_dev->devnum;
> int err = 0;
> -   u32 start_rem, blkcnt_rem;
> +   u32 start_rem, blkcnt_rem, erase_args = 0;
> struct mmc *mmc = find_mmc_device(dev_num);
> lbaint_t blk = 0, blk_r = 0;
> int timeout_ms = 1000;
> @@ -97,13 +97,25 @@ ulong mmc_berase(struct blk_desc *block_dev, lbaint_t 
> start, lbaint_t blkcnt)
>  */
> err = div_u64_rem(start, mmc->erase_grp_size, &start_rem);
> err = div_u64_rem(blkcnt, mmc->erase_grp_size, &blkcnt_rem);
> -   if (start_rem || blkcnt_rem)
> -   printf("\n\nCaution! Your devices Erase group is 0x%x\n"
> -  "The erase range would be change to "
> -  "0x" LBAF "~0x" LBAF "\n\n",
> -  mmc->erase_grp_size, start & ~(mmc->erase_grp_size - 
> 1),
> -  ((start + blkcnt + mmc->erase_grp_size - 1)
> -  & ~(mmc->erase_grp_size - 1)) - 1);
> +   if (start_rem || blkcnt_rem) {
> +   if (mmc->can_trim) {
> +   /* Trim function applies the erase operation to write
> +* blocks instead of erase groups.
> +*/
> +   erase_args = MMC_TRIM_ARG;
> +   } else {
> +   /* The card ignores all LSB's below the erase group
> +* size, rounding down the addess to a erase group
> +* boundary.
> +*/
> +   printf("\n\nCaution! Your devices Erase group is 
> 0x%x\n"
> +  "The erase range would be change to "
> +  "0x" LBAF "~0x" LBAF "\n\n",
> +  mmc->erase_grp_size, start & 
> ~(mmc->erase_grp_size - 1),
> +  ((start + blkcnt + mmc->erase_grp_size - 1)
> +  & ~(mmc->erase_grp_size - 1)) - 1);
> +   }
> +   }
>
> while (blk < blkcnt) {
> if (IS_SD(mmc) && mmc->ssr.au) {
> @@ -113,7 +125,7 @@ ulong mmc_berase(struct blk_desc *block_dev, lbaint_t 
> start, lbaint_t blkcnt)
> blk_r = ((blkcnt - blk) > mmc->erase_grp_size) ?
> mmc->erase_grp_size : (blkcnt - blk);
> }
> -   err = mmc_erase_t(mmc, start + blk, blk_r);
> +   err = mmc_erase_t(mmc, start + blk, blk_r, erase_args);
> if (err)
> break;
>
> --
> 2.34.1
>

Can you please add a sandbox test for this in test/dm/mmc.c?

Regards,
Simon


Re: [PATCH 1/6] drivers: core: ofnode: Add panel timing decode.

2023-01-25 Thread Simon Glass
Hi Nikhl,

On Tue, 24 Jan 2023 at 22:14, Nikhl M Jain  wrote:
>
> Hi Simon,
>
> On 24/01/23 00:12, Simon Glass wrote:
> > Hi Nikhil,
> >
> > On Mon, 23 Jan 2023 at 01:07, Nikhil M Jain  wrote:
> >>
> >> ofnode_decode_display_timing supports reading timing parameters from
> >> subnode of display-timings node, for displays supporting multiple
> >> resolution, in case if a display supports single resolution, it fails
> >> reading directly from display-timings node, to support it
> >> ofnode_decode_panel_timing is added.
> >>
> >> Signed-off-by: Nikhil M Jain 
> >> ---
> >>  drivers/core/ofnode.c | 53 +++
> >>  include/dm/ofnode.h   | 12 ++
> >>  2 files changed, 65 insertions(+)
> >>
> >> diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
> >> index 4d56b1a767..d06b947516 100644
> >> --- a/drivers/core/ofnode.c
> >> +++ b/drivers/core/ofnode.c
> >> @@ -991,6 +991,59 @@ int ofnode_decode_display_timing(ofnode parent, int 
> >> index,
> >> return ret;
> >>  }
> >>
> >> +int ofnode_decode_panel_timing(ofnode parent,
> >> +  struct display_timing *dt)
> >> +{
> >> +   ofnode timings;
> >> +   u32 val = 0;
> >> +   int ret = 0;
> >> +
> >> +   timings = ofnode_find_subnode(parent, "panel-timings");
> >> +
> >> +   if (!ofnode_valid(timings))
> >> +   return -EINVAL;
> >> +   memset(dt, 0, sizeof(*dt));
> >> +   ret |= decode_timing_property(timings, "hback-porch", 
> >> &dt->hback_porch);
> >> +   ret |= decode_timing_property(timings, "hfront-porch", 
> >> &dt->hfront_porch);
> >> +   ret |= decode_timing_property(timings, "hactive", &dt->hactive);
> >> +   ret |= decode_timing_property(timings, "hsync-len", 
> >> &dt->hsync_len);
> >> +   ret |= decode_timing_property(timings, "vback-porch", 
> >> &dt->vback_porch);
> >> +   ret |= decode_timing_property(timings, "vfront-porch", 
> >> &dt->vfront_porch);
> >> +   ret |= decode_timing_property(timings, "vactive", &dt->vactive);
> >> +   ret |= decode_timing_property(timings, "vsync-len", 
> >> &dt->vsync_len);
> >> +   ret |= decode_timing_property(timings, "clock-frequency", 
> >> &dt->pixelclock);
> >> +   dt->flags = 0;
> >> +   val = ofnode_read_u32_default(timings, "vsync-active", -1);
> >> +   if (val != -1) {
> >
> > if (!ofnode_read_u32(timings, "vsync-active", &val)) {
> >
> > Please fix below also
> >
> >> +   dt->flags |= val ? DISPLAY_FLAGS_VSYNC_HIGH :
> >> +   DISPLAY_FLAGS_VSYNC_LOW;
> >> +   }
> >> +   val = ofnode_read_u32_default(timings, "hsync-active", -1);
> >> +   if (val != -1) {
> >> +   dt->flags |= val ? DISPLAY_FLAGS_HSYNC_HIGH :
> >> +   DISPLAY_FLAGS_HSYNC_LOW;
> >> +   }
> >> +   val = ofnode_read_u32_default(timings, "de-active", -1);
> >> +   if (val != -1) {
> >> +   dt->flags |= val ? DISPLAY_FLAGS_DE_HIGH :
> >> +   DISPLAY_FLAGS_DE_LOW;
> >> +   }
> >> +   val = ofnode_read_u32_default(timings, "pixelclk-active", -1);
> >> +   if (val != -1) {
> >> +   dt->flags |= val ? DISPLAY_FLAGS_PIXDATA_POSEDGE :
> >> +   DISPLAY_FLAGS_PIXDATA_NEGEDGE;
> >> +   }
> >> +
> >> +   if (ofnode_read_bool(timings, "interlaced"))
> >> +   dt->flags |= DISPLAY_FLAGS_INTERLACED;
> >> +   if (ofnode_read_bool(timings, "doublescan"))
> >> +   dt->flags |= DISPLAY_FLAGS_DOUBLESCAN;
> >> +   if (ofnode_read_bool(timings, "doubleclk"))
> >> +   dt->flags |= DISPLAY_FLAGS_DOUBLECLK;
> >> +
> >> +   return ret;
> >> +}
> >> +
> >>  const void *ofnode_get_property(ofnode node, const char *propname, int 
> >> *lenp)
> >>  {
> >> if (ofnode_is_np(node))
> >> diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
> >> index fa9865602d..3f6b0843c5 100644
> >> --- a/include/dm/ofnode.h
> >> +++ b/include/dm/ofnode.h
> >> @@ -974,6 +974,18 @@ struct display_timing;
> >>  int ofnode_decode_display_timing(ofnode node, int index,
> >>  struct display_timing *config);
> >>
> >> +/**
> >> + * ofnode_decode_panel_timing() - decode display timings
> >> + *
> >> + * Decode panel timings from the supplied 'panel-timings' node.
> >> + *
> >> + * @node:  'display-timing' node containing the timing subnodes
> >> + * @config:Place to put timings
> >> + * Return: 0 if OK, -FDT_ERR_NOTFOUND if not found
> >> + */
> >> +int ofnode_decode_panel_timing(ofnode node,
> >> +  struct display_timing *config);
> >> +
> >>  /**
> >>   * ofnode_get_property() - get a pointer to the value of a node property
> >>   *
> >> --
> >> 2.17.1
> >>
> >
> > Please add a test to test/dm/ofnode.c
> >
> Wanted to confirm whether I need to add a test for ofnode_get_property
> or for the ofnode_decode_panel

Re: [PATCH v4 3/6] bootm: Support boot measurement

2023-01-25 Thread Simon Glass
Hi Eddie,

On Wed, 25 Jan 2023 at 10:18, Eddie James  wrote:
>
> Add a configuration option to measure the boot through the bootm
> function. Add the measurement state to the booti and bootz paths
> as well.
>
> Signed-off-by: Eddie James 
> ---
>  boot/Kconfig| 23 
>  boot/bootm.c| 70 +
>  cmd/booti.c |  1 +
>  cmd/bootm.c |  2 ++
>  cmd/bootz.c |  1 +
>  include/bootm.h |  2 ++
>  include/image.h |  1 +
>  7 files changed, 100 insertions(+)

Can you please add a change log? I recall making comments but cannot
see the changes here.

Regards,
Simon


Re: [PATCH 01/14] trace: Use notrace for short

2023-01-25 Thread Simon Glass
Hi Stefan,

On Wed, 25 Jan 2023 at 00:53, Stefan Herbrechtsmeier
 wrote:
>
> Hi Simon,
>
> Am 24.01.2023 um 23:44 schrieb Simon Glass:
> > Hi Stefan,
> >
> > On Tue, 24 Jan 2023 at 05:14, Stefan Herbrechtsmeier
> >  wrote:
> >> Hi Simon,
> >>
> >> Am 24.01.2023 um 11:55 schrieb Simon Glass:
> >>> Hi Stefan,
> >>>
> >>> On Tue, 24 Jan 2023 at 01:12, Stefan Herbrechtsmeier
> >>>  wrote:
>  Hi Simon,
> 
>  Am 22.12.2022 um 00:08 schrieb Simon Glass:
> > The attribute syntax is quite verbose. Use the macro provided for this
> > purpose.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > arch/arm/cpu/armv7/s5p-common/timer.c   |  2 +-
> > arch/arm/mach-exynos/include/mach/cpu.h |  6 +++---
> > arch/x86/include/asm/global_data.h  |  2 +-
> > arch/x86/include/asm/msr.h  |  2 +-
> > arch/x86/include/asm/u-boot-x86.h   |  2 +-
> > common/spl/spl_fit.c|  1 +
> > doc/develop/trace.rst   |  2 +-
> > lib/efi_loader/efi_freestanding.c   |  4 ++--
> > lib/trace.c | 26 
> > +++--
> > 9 files changed, 22 insertions(+), 25 deletions(-)
> >
>  [snip]
> 
> > diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> > index 08da7fed88e..0e026bb3d8e 100644
> > --- a/common/spl/spl_fit.c
> > +++ b/common/spl/spl_fit.c
> > @@ -599,6 +599,7 @@ static int spl_fit_upload_fpga(struct spl_fit_info 
> > *ctx, int node,
> > debug("Ignoring compatible = %s property\n",
> >   compatible);
> > }
> > + return 0;
> >
> > ret = fpga_load(devnum, (void *)fpga_image->load_addr,
> > fpga_image->size, BIT_FULL, flags);
>  This return makes the spl_fit_upload_fpga function useless. I assume
>  this change was by accident.
> >>> Yes that was a mistake. I'll send a patch.
> >> Thanks.
> >>
> >>> Do you think it would be possible to create a sandbox driver for the
> >>> FPGA uclass? Then we could add some tests for this code.
> >> A sandbox driver exists but the uclass is only an empty dummy.
> >>
> >> The fpga subsystem use its own structs to describe the hardware and the
> >> fpga_load function for example is a wrapper for xilinx_load, altera_load
> >> and lattice_load.
> > Yes, I think fpga_load should become a uclass operation. See how this
> > is done for other uclasses.
>
> The problem is that the fpga subsystem doesn't use uclass at the moment.
> The fpga is init and added by the cpu code (see
> arch/arm/mach-zynq/cpu.c). The subsystem functions use the devnum
> (index) to select the added structure.
>
> Is it possible to add a ulcass device from cpu code as a first step to
> convert the functions into uclass functions.

OK that sounds good, thanks. It should be specified in the DT.

Regards,
Simon


Re: [PATCH v2 2/4] sunxi: binman: Move BL31 and SCP firmware addresses to Kconfig

2023-01-25 Thread Simon Glass
Hi Andre,

On Wed, 25 Jan 2023 at 05:24, Andre Przywara  wrote:
>
> On Tue, 24 Jan 2023 15:44:30 -0700
> Simon Glass  wrote:
>
> > Hi Samuel,
> >
> > On Mon, 23 Jan 2023 at 22:22, Samuel Holland  wrote:
> > >
> > > Hi Simon,
> > >
> > > On 1/23/23 12:42, Simon Glass wrote:
> > > > HI Samuel,
> > > >
> > > > On Sun, 22 Jan 2023 at 14:16, Samuel Holland  
> > > > wrote:
> > > >>
> > > >> This is easier to read than the #ifdef staircase, provides better
> > > >> visibility into the memory map (alongside the other Kconfig
> > > >> definitions), and allows these addresses to be reused from code.
> > > >>
> > > >> Signed-off-by: Samuel Holland 
> > > >> ---
> > > >>
> > > >> Changes in v2:
> > > >>  - New patch for v2, split from the .dtsi changes
> > > >>
> > > >>  arch/arm/dts/sunxi-u-boot.dtsi | 24 +++-
> > > >>  arch/arm/mach-sunxi/Kconfig| 17 +
> > > >>  2 files changed, 24 insertions(+), 17 deletions(-)
> > > >
> > > > Reviewed-by: Simon Glass 
> > > >
> > > > Is this info not in the device tree?
> > >
> > > It is not. These values do not correspond to any hardware property. For
> > > example, on A64/H5/H6, BL31 and SCP share a single "SRAM A2" region. The
> > > division of the SRAM between them was chosen arbitrarily (though now it
> > > is ABI). How would you represent this in the devicetree?
> >
> > I would probably add a new node for the SRAM, with partition
> > information within that, as is done for MTD.
>
> I am probably missing something, but why would we want to do that? Looks a
> bit like a solution looking for a problem to me.
> The split and assignment of the SRAM regions is an agreement between BL31,
> crust and U-Boot, with U-Boot taking the lead here, because it's the
> initial loader of those components, and does the packaging.
> So what would putting those addresses in the generic DT bring us, aside
> from more complicated code to look them up?

Well I just answered the question. I'm not necessarily advocating for it.

We could perhaps use the new Transfer List to pass this info instead.
But if separate projects have implicit hard-coded values it is going
to lead to pain when they conflict. It is better to set this all up at
packaging time.

Regards,
Simon


Re: [PATCH v2 2/2] usb: move CONFIG_USB_HUB_DEBOUNCE_TIMEOUT to USB

2023-01-25 Thread Marek Vasut

On 1/25/23 19:40, Heinrich Schuchardt wrote:

This configuration setting is only relevant if the board supports USB.
It should not be in the main menu but in the USB menu.

The setting is only relevant in USB host mode.

Fixes: 5454dea3137d ("usb: hub: allow to increase HUB_DEBOUNCE_TIMEOUT")
Signed-off-by: Heinrich Schuchardt 


Reviewed-by: Marek Vasut 


Re: [PATCH v2 1/2] usb: USB hubs require host mode

2023-01-25 Thread Marek Vasut

On 1/25/23 19:40, Heinrich Schuchardt wrote:

USB hubs run in host mode not in gadget mode. Hence, compiling usb_hub.c
should not be selected by CONFIG_USB_GADGET.

Suggested-by: Marek Vasut 
Signed-off-by: Heinrich Schuchardt 


Reviewed-by: Marek Vasut 


Re: [PATCH] mtd: rawnand: nand_base: Handle algorithm selection

2023-01-25 Thread William Zhang

Hi Linus,

On 01/21/2023 03:43 PM, Linus Walleij wrote:

For BRCMNAND with 1-bit BCH ECC (BCH-1) such as used on the
D-Link DIR-885L and DIR-890L routers, we need to explicitly
select the ECC like this in the device tree:

   nand-ecc-algo = "bch";
   nand-ecc-strength = <1>;
   nand-ecc-step-size = <512>;

This is handled by the Linux kernel but U-Boot core does
not respect this. Fix it up by parsing the algorithm and
preserve the behaviour using this property to select
software BCH as far as possible.


For 1 bit HW ECC, the BRCMNAND driver only uses HAMMING ECC.  The 
brcmnand_setup_dev function should take care of it with just these two 
properties in the device tress without any code changes:

nand-ecc-strength = <1>;
nand-ecc-step-size = <512>;
unless these D-Link device has always been using software BCH-1 and 
wants to continue to use software BCH-1.


BTW,  I didn't see this change from master branch of linux nand base 
driver. The "nand-ecc-algo" is only used by the ecc engine code(ecc.c) 
but this code is not in the u-boot obviously. Were you porting this from 
a different version of linux nand driver?




Signed-off-by: Linus Walleij 
---
  drivers/mtd/nand/raw/nand_base.c | 13 ++---
  1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 9eba360d55f3..872b58ec5f23 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -4487,6 +4487,7 @@ EXPORT_SYMBOL(nand_detect);
  static int nand_dt_init(struct mtd_info *mtd, struct nand_chip *chip, ofnode 
node)
  {
int ret, ecc_mode = -1, ecc_strength, ecc_step;
+   int ecc_algo = NAND_ECC_UNKNOWN;
const char *str;
  
  	ret = ofnode_read_s32_default(node, "nand-bus-width", -1);

@@ -4512,10 +4513,13 @@ static int nand_dt_init(struct mtd_info *mtd, struct 
nand_chip *chip, ofnode nod
ecc_mode = NAND_ECC_SOFT_BCH;
}
  
-	if (ecc_mode == NAND_ECC_SOFT) {

-   str = ofnode_read_string(node, "nand-ecc-algo");
-   if (str && !strcmp(str, "bch"))
+   str = ofnode_read_string(node, "nand-ecc-algo");
+   if (str && !strcmp(str, "bch")) {
+   ecc_algo = NAND_ECC_BCH;
+   if (ecc_mode == NAND_ECC_SOFT)
ecc_mode = NAND_ECC_SOFT_BCH;
+   } else if (!strcmp(str, "hamming")) {
+   ecc_algo = NAND_ECC_HAMMING;
}
  
  	ecc_strength = ofnode_read_s32_default(node,

@@ -4529,6 +4533,9 @@ static int nand_dt_init(struct mtd_info *mtd, struct 
nand_chip *chip, ofnode nod
return -EINVAL;
}
  
+	if (ecc_algo >= 0)

+   chip->ecc.algo = ecc_algo;
+
if (ecc_mode >= 0)
chip->ecc.mode = ecc_mode;
  



smime.p7s
Description: S/MIME Cryptographic Signature


Re: [PATCH 01/14] mtd: nand: brcm: switch to mtd_ooblayout_ops

2023-01-25 Thread William Zhang

Hi Linus,

Unfortunately the u-boot nand base code still uses nand_ecclayout 
structure because it was based on old kernel nand driver.  Your change 
cause bugcheck in the nand_scan_tail at line 4978 when mtd->oobsize is 
not one of the default size (i.e. some large nand with BCH-8 ecc 
requirement and has 224 bytes oobsize per 4K page) because ecc->layout 
is never set. Also certainly any data built based on nand_cclayout like 
mtd->oobavail will not be correct.


I actually converted back to nand_ecclayout structure from mtd_ooblayout 
with this fix to solve the above issues.
Fixes: e365de90517b ("drivers: nand: brcmnand: fix nand_chip ecc layout 
structure")


I can see your point to get the latest from the brcmnand linux kernel 
driver but this requires updating the u-boot nand base driver to use 
mtd_ooblayout as well and all others nand controller drivers too. I am 
not sure if this is something you want to tackle right now.


As far as I can see, all other oob/ecc layout setting patches you back 
ported in this series are not in the original brcmstb_choose_ecc_layout 
code you replaced. So I am not worried about that we must switch to 
mtd_ooblayout_ops at this point.  If indeed there is bug in 
brcmstb_choose_ecc_layout, we can port and convert the fix to 
nand_ecclayout structure from kernel code.


Was the bug you were hunting down in the code related to this patch?

Thanks,
William


On 01/15/2023 11:52 AM, Linus Walleij wrote:

From: Boris Brezillon 

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon 
[Ported to U-Boot from the Linux kernel]
Signed-off-by: Linus Walleij 
---
  drivers/mtd/nand/raw/brcmnand/brcmnand.c | 260 ++-
  1 file changed, 156 insertions(+), 104 deletions(-)

diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c 
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index 74c9348f7fc4..8ea33e861354 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -894,131 +894,183 @@ static inline bool is_hamming_ecc(struct 
brcmnand_controller *ctrl,
  }
  
  /*

- * Returns a nand_ecclayout strucutre for the given layout/configuration.
- * Returns NULL on failure.
+ * Set mtd->ooblayout to the appropriate mtd_ooblayout_ops given
+ * the layout/configuration.
+ * Returns -ERRCODE on failure.
   */
-static struct nand_ecclayout *brcmnand_create_layout(int ecc_level,
-struct brcmnand_host *host)
+static int brcmnand_hamming_ooblayout_ecc(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
  {
+   struct nand_chip *chip = mtd_to_nand(mtd);
+   struct brcmnand_host *host = nand_get_controller_data(chip);
struct brcmnand_cfg *cfg = &host->hwcfg;
-   int i, j;
-   struct nand_ecclayout *layout;
-   int req;
-   int sectors;
-   int sas;
-   int idx1, idx2;
  
-#ifndef __UBOOT__

-   layout = devm_kzalloc(&host->pdev->dev, sizeof(*layout), GFP_KERNEL);
-#else
-   layout = devm_kzalloc(host->pdev, sizeof(*layout), GFP_KERNEL);
-#endif
-   if (!layout)
-   return NULL;
-
-   sectors = cfg->page_size / (512 << cfg->sector_size_1k);
-   sas = cfg->spare_area_size << cfg->sector_size_1k;
-
-   /* Hamming */
-   if (is_hamming_ecc(host->ctrl, cfg)) {
-   for (i = 0, idx1 = 0, idx2 = 0; i < sectors; i++) {
-   /* First sector of each page may have BBI */
-   if (i == 0) {
-   layout->oobfree[idx2].offset = i * sas + 1;
-   /* Small-page NAND use byte 6 for BBI */
-   if (cfg->page_size == 512)
-   layout->oobfree[idx2].offset--;
-   layout->oobfree[idx2].length = 5;
-   } else {
-   layout->oobfree[idx2].offset = i * sas;
-   layout->oobfree[idx2].length = 6;
-   }
-   idx2++;
-   layout->eccpos[idx1++] = i * sas + 6;
-   layout->eccpos[idx1++] = i * sas + 7;
-   layout->eccpos[idx1++] = i * sas + 8;
-   layout->oobfree[idx2].offset = i * sas + 9;
-   layout->oobfree[idx2].length = 7;
-   idx2++;
-   /* Leave zero-terminated entry for OOBFREE */
-   if (idx1 >= MTD_MAX_ECCPOS_ENTRIES_LARGE ||
-   idx2 >= MTD_MAX_OOBFREE_ENTRIES_LARGE - 1)
-   break;
-   }
+   int sas = cfg->spare_area_size << cfg->sector_size_1k;
+   int sectors = cfg->page_size / (512 << cfg->sector_size_1k);
  
-		return layout;

-   }
+   if (section >= s

Re: [PATCH 1/1] README: remove 'U-Boot Porting Guide' section

2023-01-25 Thread Simon Glass
Hi Heinrich,

On Wed, 25 Jan 2023 at 12:00, Heinrich Schuchardt
 wrote:
>
> This section does not match the standards of our documentation.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  README | 74 --
>  1 file changed, 74 deletions(-)
>

It seems fairly accurate to me, and includes some good advice.

Regards,
Simon


[PATCH] ti: j721e_evm: Add USB to the default boot order

2023-01-25 Thread Tom Rini
This family of platforms typically has a USB port, and so attempting to
boot from it, and making it first, will provide a better overall user
experience.

Signed-off-by: Tom Rini 
---
 include/configs/j721e_evm.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/configs/j721e_evm.h b/include/configs/j721e_evm.h
index a7210b5cf3ae..48b1cea6e394 100644
--- a/include/configs/j721e_evm.h
+++ b/include/configs/j721e_evm.h
@@ -161,7 +161,14 @@
 # define BOOT_TARGET_DHCP(func)
 #endif
 
+#ifdef CONFIG_CMD_USB
+# define BOOT_TARGET_USB(func) func(USB, usb, 0)
+#else
+# define BOOT_TARGET_USB(func)
+#endif
+
 #define BOOT_TARGET_DEVICES(func) \
+   BOOT_TARGET_USB(func) \
func(MMC, mmc, 1) \
func(MMC, mmc, 0) \
BOOT_TARGET_PXE(func) \
-- 
2.34.1



[PATCH] lmb: Default to not-LMB_USE_MAX_REGIONS

2023-01-25 Thread Tom Rini
The LMB code allows for picking a hard limit on the number of regions it
can know of, or to dynamically allocate these regions. The reason for
this choice is to allow for the compiler to perform a size optimization
in the common case. This optimization however, is very small, ranging
from 196 bytes to 15 bytes saved, or in some cases, being larger. Now
that we also have more regions covered by LMB (in order to protect
various parts of our self at run time), the default of 8 is also much
easier to hit and leads to non-obvious error messages (which imply that
an area is protected, not that we're out of areas to add to the list).

Switch to the dynamic use as the default.

Signed-off-by: Tom Rini 
---
 configs/a3y17lte_defconfig   | 1 -
 configs/a5y17lte_defconfig   | 1 -
 configs/a7y17lte_defconfig   | 1 -
 configs/dragonboard845c_defconfig| 1 -
 configs/mt7981_emmc_rfb_defconfig| 1 -
 configs/mt7981_rfb_defconfig | 1 -
 configs/mt7981_sd_rfb_defconfig  | 1 -
 configs/mt7986_rfb_defconfig | 1 -
 configs/mt7986a_bpir3_emmc_defconfig | 1 -
 configs/mt7986a_bpir3_sd_defconfig   | 1 -
 configs/qcs404evb_defconfig  | 1 -
 configs/starqltechn_defconfig| 1 -
 lib/Kconfig  | 1 -
 13 files changed, 13 deletions(-)

diff --git a/configs/a3y17lte_defconfig b/configs/a3y17lte_defconfig
index 124fb8d47617..0215c5f234bb 100644
--- a/configs/a3y17lte_defconfig
+++ b/configs/a3y17lte_defconfig
@@ -24,4 +24,3 @@ CONFIG_SYS_BOOTM_LEN=0x200
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_DM_I2C_GPIO=y
-CONFIG_LMB_MAX_REGIONS=64
diff --git a/configs/a5y17lte_defconfig b/configs/a5y17lte_defconfig
index ffb0b3f474a6..d1cd97baf512 100644
--- a/configs/a5y17lte_defconfig
+++ b/configs/a5y17lte_defconfig
@@ -24,4 +24,3 @@ CONFIG_SYS_BOOTM_LEN=0x200
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_DM_I2C_GPIO=y
-CONFIG_LMB_MAX_REGIONS=64
diff --git a/configs/a7y17lte_defconfig b/configs/a7y17lte_defconfig
index 8c1229d8d5ec..bef2d0945aec 100644
--- a/configs/a7y17lte_defconfig
+++ b/configs/a7y17lte_defconfig
@@ -24,4 +24,3 @@ CONFIG_SYS_BOOTM_LEN=0x200
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_DM_I2C_GPIO=y
-CONFIG_LMB_MAX_REGIONS=64
diff --git a/configs/dragonboard845c_defconfig 
b/configs/dragonboard845c_defconfig
index a69d82761a8d..cef82f56108e 100644
--- a/configs/dragonboard845c_defconfig
+++ b/configs/dragonboard845c_defconfig
@@ -26,4 +26,3 @@ CONFIG_DM_PMIC=y
 CONFIG_PMIC_QCOM=y
 CONFIG_MSM_GENI_SERIAL=y
 CONFIG_SPMI_MSM=y
-CONFIG_LMB_MAX_REGIONS=64
diff --git a/configs/mt7981_emmc_rfb_defconfig 
b/configs/mt7981_emmc_rfb_defconfig
index b3b37b6e5ed4..4832a2264395 100644
--- a/configs/mt7981_emmc_rfb_defconfig
+++ b/configs/mt7981_emmc_rfb_defconfig
@@ -62,4 +62,3 @@ CONFIG_MTK_SERIAL=y
 CONFIG_FAT_WRITE=y
 CONFIG_HEXDUMP=y
 # CONFIG_EFI_LOADER is not set
-CONFIG_LMB_MAX_REGIONS=64
diff --git a/configs/mt7981_rfb_defconfig b/configs/mt7981_rfb_defconfig
index b7ffb4dfa74d..c3975278871e 100644
--- a/configs/mt7981_rfb_defconfig
+++ b/configs/mt7981_rfb_defconfig
@@ -64,4 +64,3 @@ CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_MTK_SPIM=y
 CONFIG_HEXDUMP=y
-CONFIG_LMB_MAX_REGIONS=64
diff --git a/configs/mt7981_sd_rfb_defconfig b/configs/mt7981_sd_rfb_defconfig
index 85be9bbc5030..17592dc22b9a 100644
--- a/configs/mt7981_sd_rfb_defconfig
+++ b/configs/mt7981_sd_rfb_defconfig
@@ -62,4 +62,3 @@ CONFIG_MTK_SERIAL=y
 CONFIG_FAT_WRITE=y
 CONFIG_HEXDUMP=y
 # CONFIG_EFI_LOADER is not set
-CONFIG_LMB_MAX_REGIONS=64
diff --git a/configs/mt7986_rfb_defconfig b/configs/mt7986_rfb_defconfig
index ac91c93efb42..1363f9dc6d0b 100644
--- a/configs/mt7986_rfb_defconfig
+++ b/configs/mt7986_rfb_defconfig
@@ -64,4 +64,3 @@ CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_MTK_SPIM=y
 CONFIG_HEXDUMP=y
-CONFIG_LMB_MAX_REGIONS=64
diff --git a/configs/mt7986a_bpir3_emmc_defconfig 
b/configs/mt7986a_bpir3_emmc_defconfig
index 2d4876f299f4..354159df9b2e 100644
--- a/configs/mt7986a_bpir3_emmc_defconfig
+++ b/configs/mt7986a_bpir3_emmc_defconfig
@@ -62,4 +62,3 @@ CONFIG_MTK_SERIAL=y
 CONFIG_FAT_WRITE=y
 CONFIG_HEXDUMP=y
 # CONFIG_EFI_LOADER is not set
-CONFIG_LMB_MAX_REGIONS=64
diff --git a/configs/mt7986a_bpir3_sd_defconfig 
b/configs/mt7986a_bpir3_sd_defconfig
index 08edfe7ac409..db7ef98d807b 100644
--- a/configs/mt7986a_bpir3_sd_defconfig
+++ b/configs/mt7986a_bpir3_sd_defconfig
@@ -62,4 +62,3 @@ CONFIG_MTK_SERIAL=y
 CONFIG_FAT_WRITE=y
 CONFIG_HEXDUMP=y
 # CONFIG_EFI_LOADER is not set
-CONFIG_LMB_MAX_REGIONS=64
diff --git a/configs/qcs404evb_defconfig b/configs/qcs404evb_defconfig
index dae155141152..d3608cae9f90 100644
--- a/configs/qcs404evb_defconfig
+++ b/configs/qcs404evb_defconfig
@@ -51,4 +51,3 @@ CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC3_GENERIC=y
 CONFIG_USB_STORAGE=y
-CONFIG_LMB_MAX_REGIONS=64
diff --git a/configs/starqltechn_defconfig b/configs/starqltechn_defconfig
index 7a64f2a7a088..81fd7b22676e 100644
--- a/configs/starqltechn_defconfig
+++

Re: [PATCH v2] usb: gadget: ether: split start/stop from init/halt

2023-01-25 Thread Kevin Hilman
Niel Fourie  writes:

> Split out _usb_eth_start() from _usb_eth_init() and
> usb_eth_stop() from _usb_eth_halt(). Now _usb_eth_init() only
> initialises and registers the gadget device, which _usb_eth_halt()
> reverses, and together are used for probing and removing the
> device. The _usb_eth_start() and _usb_eth_stop() functions connect
> and disconnect the gadget as expected by the start()/stop()
> callbacks.
>
> Previously the gadget device was probed on every start() and
> removed on every stop(), which is inconsistent with other DM_ETH
> drivers.

By suggestion from Marek, I was testing this patch and discovered that
it broke fastboot over USB support.  With this patch applied on top of
v2022.10, I'm seeing:

=> fastboot 0
couldn't find an available UDC
g_dnl_register: failed!, error: -19

Kevin


Re: [RFC PATCH 00/16] arm: Add Rockchip RK3588 support

2023-01-25 Thread Jonas Karlman
Hi Jagan,

On 2023-01-25 23:27, Jagan Teki wrote:
> This series support Rockchip RK3588. All the device tree files are
> synced from linux-next with the proper SHA1 mentioned in the commit
> messages.
> 
> Unfortunately, the BL31 from rkbin is not compatible with U-Boot so
> it is failing to load ATF entry from SPL and hang. 
> 
> Verified below BL31 versions,
>   bl31-v1.15
>   bl31-v1.21
>   bl31-v1.22
>   bl31-v1.23
>   bl31-v1.24
>   bl31-v1.25
>   bl31-v1.26
> 
> Rever-engineered with respect to rockchip u-boot by using the same
> FIT_GENERATOR being used in Mainline, rockchip u-boot is booting but
> mainline showing the same issue.
> 
> Log:
> 
> LPDDR4X, 2112MHz01-00642-g6bdfd31756-dirty (Jan 26 2023 ���3:44:34 +0530)
> channel[0] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB
> channel[1] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB
> channel[2] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB
> channel[3] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB
> change to F1: 528MHz
> change to F2: 1068MHz
> change to F3: 1560MHz
> change to F0: 2112MHz
> out
> 
> U-Boot SPL 2023.01-00642-g6bdfd31756-dirty (Jan 26 2023 - 03:44:34 +0530)
> Trying to boot from MMC1
> bl31_entry: atf_entry start
> << hang >>
> 
> Any information on BL31 for RK3588 please share.

I had a similar strange booing issue with RK3568 and mainline U-Boot,
turned out to be related to all parts of ATF not being properly loaded
into PMU SRAM.

Using my series at [1] I managed to get ATF to be fully loaded into
PMU SRAM. Using CONFIG_SPL_FIT_SIGNATURE=y helped me finding out that
the segment being loaded ended up corrupted.

The use of 512 bytes alignment of the FIT helped mitigate that issue.
Vendor U-Boot use a bounce buffer for all parts that is written into
SRAM (anything loaded outside the gd->ram_base to gd->ram_top range).

You can also find newer bl31 at [2], up to version v1.32.

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=337891
[2] 
https://gitlab.com/rk3588_linux/rk/rkbin/-/tree/linux-5.10-gen-rkr3.5/bin/rk35

Regards,
Jonas

> 
> Any inputs?
> Jagan.
> 
> Jagan Teki (16):
>   rockchip: mkimage: Add rk3588 support
>   arm: rockchip: Add cru header for rk3588
>   arm: rockchip: Add grf header for rk3588
>   dt-bindings: clk: Add dt-binding header for RK3588
>   clk: rockchip: Add rk3588 clk support
>   clk: rockchip: pll: Add pll_rk3588 type for rk3588
>   ram: rockchip: Add rk3588 ddr driver support
>   dt-bindings: power: Add power-domain header for rk3588
>   dt-bindings: reset: add rk3588 reset definitions
>   arm: rockchip: Add ioc header for rk3588
>   arm64: dts: rockchip: Add base DT for rk3588 SoC
>   arm64: dts: rockchip: rk3588: Add Edgeble Neu6 Model A SoM
>   arm64: dts: rockchip: rk3588: Add Edgeble Neu6 Model A IO
>   arm: rockchip: Add RK3588 arch core support
>   ARM: dts: rockchip: Add rk3588-u-boot.dtsi
>   board: rockchip: Add Edgeble Neural Compute Module 6
> 
>  arch/arm/dts/Makefile |3 +
>  .../dts/rk3588-edgeble-neu6a-io-u-boot.dtsi   |   23 +
>  arch/arm/dts/rk3588-edgeble-neu6a-io.dts  |   27 +
>  arch/arm/dts/rk3588-edgeble-neu6a.dtsi|   32 +
>  arch/arm/dts/rk3588-pinctrl.dtsi  |  516 +++
>  arch/arm/dts/rk3588-u-boot.dtsi   |  101 +
>  arch/arm/dts/rk3588.dtsi  |   58 +
>  arch/arm/dts/rk3588s-pinctrl.dtsi | 3403 +
>  arch/arm/dts/rk3588s.dtsi | 1703 +
>  arch/arm/include/asm/arch-rk3588/boot0.h  |   11 +
>  arch/arm/include/asm/arch-rk3588/gpio.h   |   11 +
>  arch/arm/include/asm/arch-rockchip/clock.h|   24 +
>  .../include/asm/arch-rockchip/cru_rk3588.h|  451 +++
>  .../include/asm/arch-rockchip/grf_rk3588.h|   35 +
>  .../include/asm/arch-rockchip/ioc_rk3588.h|  102 +
>  arch/arm/mach-rockchip/Kconfig|   20 +
>  arch/arm/mach-rockchip/Makefile   |1 +
>  arch/arm/mach-rockchip/rk3588/Kconfig |   30 +
>  arch/arm/mach-rockchip/rk3588/Makefile|9 +
>  arch/arm/mach-rockchip/rk3588/clk_rk3588.c|   33 +
>  arch/arm/mach-rockchip/rk3588/rk3588.c|  162 +
>  arch/arm/mach-rockchip/rk3588/syscon_rk3588.c |   32 +
>  board/edgeble/neural-compute-module-6/Kconfig |   15 +
>  .../neural-compute-module-6/MAINTAINERS   |6 +
>  .../edgeble/neural-compute-module-6/Makefile  |7 +
>  board/edgeble/neural-compute-module-6/neu6.c  |4 +
>  configs/neu6a-io-rk3588_defconfig |   68 +
>  doc/board/rockchip/rockchip.rst   |2 +
>  drivers/clk/rockchip/Makefile |1 +
>  drivers/clk/rockchip/clk_pll.c|  267 +-
>  drivers/clk/rockchip/clk_rk3588.c | 2019 ++
>  drivers/ram/rockchip/Makefile |1 +
>  drivers/ram/rockchip/sdram_rk3588.c   |   56 +
>  include/configs/neural-compute-module-6

Re: [PATCH 5/7] doc: move 'Reproducible builds'

2023-01-25 Thread Simon Glass
On Wed, 25 Jan 2023 at 11:15, Heinrich Schuchardt
 wrote:
>
> Move the README section to the HTML documentation.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  README | 11 ---
>  doc/build/index.rst|  1 +
>  doc/build/reproducible.rst | 25 +
>  3 files changed, 26 insertions(+), 11 deletions(-)
>  create mode 100644 doc/build/reproducible.rst

Reviewed-by: Simon Glass 


Re: [PATCH 7/7] doc: move directory hierarchy to HTML

2023-01-25 Thread Simon Glass
On Wed, 25 Jan 2023 at 11:15, Heinrich Schuchardt
 wrote:
>
> Move section 'Directory hierarchy' from file README to the HTML
> documentation.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  README  | 38 ---
>  doc/develop/directories.rst | 76 +
>  doc/develop/index.rst   |  1 +
>  3 files changed, 77 insertions(+), 38 deletions(-)
>  create mode 100644 doc/develop/directories.rst
>

Reviewed-by: Simon Glass 


Re: [PATCH 6/7] README: remove section 'Versioning'

2023-01-25 Thread Simon Glass
On Wed, 25 Jan 2023 at 11:15, Heinrich Schuchardt
 wrote:
>
> The information is already maintained in doc/develop/release_cycle.rst.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  README | 16 
>  1 file changed, 16 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH 4/7] README: replace references to CHANGELOG

2023-01-25 Thread Simon Glass
On Wed, 25 Jan 2023 at 11:15, Heinrich Schuchardt
 wrote:
>
> Board configurations are in configs/ and not in the Makefile.
>
> git log is the adequate way to identify who contributed to our source.
> scripts/get_maintainer.pl is the correct way to identify maintainers.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  README | 16 ++--
>  1 file changed, 6 insertions(+), 10 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH 3/7] README: remove NetBSD section

2023-01-25 Thread Simon Glass
On Wed, 25 Jan 2023 at 11:15, Heinrich Schuchardt
 wrote:
>
> The information in this section is outdated.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  README | 29 -
>  1 file changed, 29 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH 2/7] README: rework contribution advices

2023-01-25 Thread Simon Glass
On Wed, 25 Jan 2023 at 11:15, Heinrich Schuchardt
 wrote:
>
> Remove description of coding standards and patch submission process.
> Link to the relevant HTML documentation instead.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  README | 110 -
>  1 file changed, 6 insertions(+), 104 deletions(-)
>

Reviewed-by: Simon Glass 

Suggestion below

> diff --git a/README b/README
> index 24e91b9a1f..f5db75d913 100644
> --- a/README
> +++ b/README
> @@ -2862,108 +2862,10 @@ void no_more_time (int sig)
>  }
>
>
> -Coding Standards:
> --
> -
> -All contributions to U-Boot should conform to the Linux kernel
> -coding style; see the kernel coding style guide at
> -https://www.kernel.org/doc/html/latest/process/coding-style.html, and the
> -script "scripts/Lindent" in your Linux kernel source directory.
> -
> -Source files originating from a different project (for example the
> -MTD subsystem) are generally exempt from these guidelines and are not
> -reformatted to ease subsequent migration to newer versions of those
> -sources.
> -
> -Please note that U-Boot is implemented in C (and to some small parts in
> -Assembler); no C++ is used, so please do not use C++ style comments (//)
> -in your code.
> -
> -Please also stick to the following formatting rules:
> -- remove any trailing white space
> -- use TAB characters for indentation and vertical alignment, not spaces
> -- make sure NOT to use DOS '\r\n' line feeds
> -- do not add more than 2 consecutive empty lines to source files
> -- do not add trailing empty lines to source files
> -
> -Submissions which do not conform to the standards may be returned
> -with a request to reformat the changes.
> -
> -
> -Submitting Patches:
> 
> -
> -Since the number of patches for U-Boot is growing, we need to
> -establish some rules. Submissions which do not conform to these rules
> -may be rejected, even when they contain important and valuable stuff.
> -
> -Please see https://www.denx.de/wiki/U-Boot/Patches for details.
> -
> -Patches shall be sent to the u-boot mailing list ;
> -see https://lists.denx.de/listinfo/u-boot
> -
> -When you send a patch, please include the following information with
> -it:
> -
> -* For bug fixes: a description of the bug and how your patch fixes
> -  this bug. Please try to include a way of demonstrating that the
> -  patch actually fixes something.
> -
> -* For new features: a description of the feature and your
> -  implementation.
> -
> -* For major contributions, add a MAINTAINERS file with your
> -  information and associated file and directory references.
> -
> -* When you add support for a new board, don't forget to add a
> -  maintainer e-mail address to the boards.cfg file, too.
> -
> -* If your patch adds new configuration options, don't forget to
> -  document these in the README file.
> -
> -* The patch itself. If you are using git (which is *strongly*
> -  recommended) you can easily generate the patch using the
> -  "git format-patch". If you then use "git send-email" to send it to
> -  the U-Boot mailing list, you will avoid most of the common problems
> -  with some other mail clients.
> -
> -  If you cannot use git, use "diff -purN OLD NEW". If your version of
> -  diff does not support these options, then get the latest version of
> -  GNU diff.
> -
> -  The current directory when running this command shall be the parent
> -  directory of the U-Boot source tree (i. e. please make sure that
> -  your patch includes sufficient directory information for the
> -  affected files).
> -
> -  We prefer patches as plain text. MIME attachments are discouraged,
> -  and compressed attachments must not be used.
> -
> -* If one logical set of modifications affects or creates several
> -  files, all these changes shall be submitted in a SINGLE patch file.
> -
> -* Changesets that contain different, unrelated modifications shall be
> -  submitted as SEPARATE patches, one patch per changeset.
> -
> -
> -Notes:
> -
> -* Before sending the patch, run the buildman script on your patched
> -  source tree and make sure that no errors or warnings are reported
> -  for any of the boards.
> -
> -* Keep your modifications to the necessary minimum: A patch
> -  containing several unrelated changes or arbitrary reformats will be
> -  returned with a request to re-formatting / split it.
> -
> -* If you modify existing code, make sure that your new code does not
> -  add to the memory footprint of the code ;-) Small is beautiful!
> -  When adding new features, these should compile conditionally only
> -  (using #ifdef), and the resulting code with the new feature
> -  disabled must not need more memory than the old code without your
> -  modification.
> +Contributing
> +
>
> -* Remember that there is a size limit of 100 kB per message on the
> -  u-boot mailing list. Bigger patches will be moderated. If they are
> -  reasonable and not too big, they will be

[RFC PATCH 11/16] arm64: dts: rockchip: Add base DT for rk3588 SoC

2023-01-25 Thread Jagan Teki
This initial version supports CPU, dma, interrupts, timers, UART and
SDHCI (everything necessary to boot Linux on this system on chip) as
well as Ethernet, I2C, PWM and SPI.

The DT is split into rk3588 and rk3588s, which is a reduced version
(i.e. with less peripherals) of the former.

commit <9fb232e9911f> (" arm64: dts: rockchip: Add base DT for rk3588
SoC")
commit  ("arm64: dts: rockchip: Add rk3588 pinctrl data")

Signed-off-by: Jianqun Xu 
Signed-off-by: Kever Yang 
Signed-off-by: Jagan Teki 
---
 arch/arm/dts/rk3588-pinctrl.dtsi  |  516 +
 arch/arm/dts/rk3588.dtsi  |   58 +
 arch/arm/dts/rk3588s-pinctrl.dtsi | 3403 +
 arch/arm/dts/rk3588s.dtsi | 1703 +++
 4 files changed, 5680 insertions(+)
 create mode 100644 arch/arm/dts/rk3588-pinctrl.dtsi
 create mode 100644 arch/arm/dts/rk3588.dtsi
 create mode 100644 arch/arm/dts/rk3588s-pinctrl.dtsi
 create mode 100644 arch/arm/dts/rk3588s.dtsi

diff --git a/arch/arm/dts/rk3588-pinctrl.dtsi b/arch/arm/dts/rk3588-pinctrl.dtsi
new file mode 100644
index 00..244c66faa1
--- /dev/null
+++ b/arch/arm/dts/rk3588-pinctrl.dtsi
@@ -0,0 +1,516 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+#include 
+#include "rockchip-pinconf.dtsi"
+
+/*
+ * This file is auto generated by pin2dts tool, please keep these code
+ * by adding changes at end of this file.
+ */
+&pinctrl {
+   clk32k {
+   /omit-if-no-ref/
+   clk32k_out1: clk32k-out1 {
+   rockchip,pins =
+   /* clk32k_out1 */
+   <2 RK_PC5 1 &pcfg_pull_none>;
+   };
+
+   };
+
+   eth0 {
+   /omit-if-no-ref/
+   eth0_pins: eth0-pins {
+   rockchip,pins =
+   /* eth0_refclko_25m */
+   <2 RK_PC3 1 &pcfg_pull_none>;
+   };
+
+   };
+
+   fspi {
+   /omit-if-no-ref/
+   fspim1_pins: fspim1-pins {
+   rockchip,pins =
+   /* fspi_clk_m1 */
+   <2 RK_PB3 3 &pcfg_pull_up_drv_level_2>,
+   /* fspi_cs0n_m1 */
+   <2 RK_PB4 3 &pcfg_pull_up_drv_level_2>,
+   /* fspi_d0_m1 */
+   <2 RK_PA6 3 &pcfg_pull_up_drv_level_2>,
+   /* fspi_d1_m1 */
+   <2 RK_PA7 3 &pcfg_pull_up_drv_level_2>,
+   /* fspi_d2_m1 */
+   <2 RK_PB0 3 &pcfg_pull_up_drv_level_2>,
+   /* fspi_d3_m1 */
+   <2 RK_PB1 3 &pcfg_pull_up_drv_level_2>;
+   };
+
+   /omit-if-no-ref/
+   fspim1_cs1: fspim1-cs1 {
+   rockchip,pins =
+   /* fspi_cs1n_m1 */
+   <2 RK_PB5 3 &pcfg_pull_up_drv_level_2>;
+   };
+   };
+
+   gmac0 {
+   /omit-if-no-ref/
+   gmac0_miim: gmac0-miim {
+   rockchip,pins =
+   /* gmac0_mdc */
+   <4 RK_PC4 1 &pcfg_pull_none>,
+   /* gmac0_mdio */
+   <4 RK_PC5 1 &pcfg_pull_none>;
+   };
+
+   /omit-if-no-ref/
+   gmac0_clkinout: gmac0-clkinout {
+   rockchip,pins =
+   /* gmac0_mclkinout */
+   <4 RK_PC3 1 &pcfg_pull_none>;
+   };
+
+   /omit-if-no-ref/
+   gmac0_rx_bus2: gmac0-rx-bus2 {
+   rockchip,pins =
+   /* gmac0_rxd0 */
+   <2 RK_PC1 1 &pcfg_pull_none>,
+   /* gmac0_rxd1 */
+   <2 RK_PC2 1 &pcfg_pull_none>,
+   /* gmac0_rxdv_crs */
+   <4 RK_PC2 1 &pcfg_pull_none>;
+   };
+
+   /omit-if-no-ref/
+   gmac0_tx_bus2: gmac0-tx-bus2 {
+   rockchip,pins =
+   /* gmac0_txd0 */
+   <2 RK_PB6 1 &pcfg_pull_none>,
+   /* gmac0_txd1 */
+   <2 RK_PB7 1 &pcfg_pull_none>,
+   /* gmac0_txen */
+   <2 RK_PC0 1 &pcfg_pull_none>;
+   };
+
+   /omit-if-no-ref/
+   gmac0_rgmii_clk: gmac0-rgmii-clk {
+   rockchip,pins =
+   /* gmac0_rxclk */
+   <2 RK_PB0 1 &pcfg_pull_none>,
+ 

Re: [PATCH 6/7] README: remove section 'Versioning'

2023-01-25 Thread Tom Rini
On Wed, Jan 25, 2023 at 07:15:01PM +0100, Heinrich Schuchardt wrote:

> The information is already maintained in doc/develop/release_cycle.rst.
> 
> Signed-off-by: Heinrich Schuchardt 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 7/7] doc: move directory hierarchy to HTML

2023-01-25 Thread Tom Rini
On Wed, Jan 25, 2023 at 07:15:02PM +0100, Heinrich Schuchardt wrote:

> Move section 'Directory hierarchy' from file README to the HTML
> documentation.
> 
> Signed-off-by: Heinrich Schuchardt 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 5/7] doc: move 'Reproducible builds'

2023-01-25 Thread Tom Rini
On Wed, Jan 25, 2023 at 07:15:00PM +0100, Heinrich Schuchardt wrote:

> Move the README section to the HTML documentation.
> 
> Signed-off-by: Heinrich Schuchardt 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 4/7] README: replace references to CHANGELOG

2023-01-25 Thread Tom Rini
On Wed, Jan 25, 2023 at 07:14:59PM +0100, Heinrich Schuchardt wrote:

> Board configurations are in configs/ and not in the Makefile.
> 
> git log is the adequate way to identify who contributed to our source.
> scripts/get_maintainer.pl is the correct way to identify maintainers.
> 
> Signed-off-by: Heinrich Schuchardt 

Reviewed-by: Tom Rini 

But is there some rST doc this should be in as well?  Long term and high
level, the README should just tell people how to build the documentation
or to read the markdown files directly, starting with the top level
index.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 3/7] README: remove NetBSD section

2023-01-25 Thread Tom Rini
On Wed, Jan 25, 2023 at 07:14:58PM +0100, Heinrich Schuchardt wrote:

> The information in this section is outdated.
> 
> Signed-off-by: Heinrich Schuchardt 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/7] README: rework contribution advices

2023-01-25 Thread Tom Rini
On Wed, Jan 25, 2023 at 07:14:57PM +0100, Heinrich Schuchardt wrote:

> Remove description of coding standards and patch submission process.
> Link to the relevant HTML documentation instead.
> 
> Signed-off-by: Heinrich Schuchardt 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] README: remove 'U-Boot Porting Guide' section

2023-01-25 Thread Tom Rini
On Wed, Jan 25, 2023 at 08:00:23PM +0100, Heinrich Schuchardt wrote:

> This section does not match the standards of our documentation.
> 
> Signed-off-by: Heinrich Schuchardt 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


[RFC PATCH 16/16] board: rockchip: Add Edgeble Neural Compute Module 6

2023-01-25 Thread Jagan Teki
Neural Compute Module 6(Neu2) is a 96boards SoM-CB compute module
based on Rockchip RK3588 from Edgeble AI.

General features:
- Rockchip RK3588
- up to 32GB LPDDR4x
- up to 128GB eMMC
- 2x MIPI CSI2 FPC

On module WiFi6/BT5 is available in the following Neu6 variants.

Neural Compute Module 6(Neu6) IO board is an industrial form factor
ready-to-use IO board from Edgeble AI.

IO board offers plenty of peripherals and connectivity options and
this patch enables basic eMMC and UART which is enough to successfully
boot Linux.

Neu6 needs to mount on top of this IO board in order to create a
complete Edgeble Neural Compute Module 6(Neu6) IO platform.

Add support for Edgeble Neu6 Model A IO Board.

Signed-off-by: Jagan Teki 
---
 .../dts/rk3588-edgeble-neu6a-io-u-boot.dtsi   | 23 +++
 arch/arm/mach-rockchip/rk3588/Kconfig | 15 
 board/edgeble/neural-compute-module-6/Kconfig | 15 
 .../neural-compute-module-6/MAINTAINERS   |  6 ++
 .../edgeble/neural-compute-module-6/Makefile  |  7 ++
 board/edgeble/neural-compute-module-6/neu6.c  |  4 ++
 configs/neu6a-io-rk3588_defconfig | 68 +++
 doc/board/rockchip/rockchip.rst   |  2 +
 include/configs/neural-compute-module-6.h | 15 
 9 files changed, 155 insertions(+)
 create mode 100644 arch/arm/dts/rk3588-edgeble-neu6a-io-u-boot.dtsi
 create mode 100644 board/edgeble/neural-compute-module-6/Kconfig
 create mode 100644 board/edgeble/neural-compute-module-6/MAINTAINERS
 create mode 100644 board/edgeble/neural-compute-module-6/Makefile
 create mode 100644 board/edgeble/neural-compute-module-6/neu6.c
 create mode 100644 configs/neu6a-io-rk3588_defconfig
 create mode 100644 include/configs/neural-compute-module-6.h

diff --git a/arch/arm/dts/rk3588-edgeble-neu6a-io-u-boot.dtsi 
b/arch/arm/dts/rk3588-edgeble-neu6a-io-u-boot.dtsi
new file mode 100644
index 00..dc94ff9ef0
--- /dev/null
+++ b/arch/arm/dts/rk3588-edgeble-neu6a-io-u-boot.dtsi
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2022 Edgeble AI Technologies Pvt. Ltd.
+ */
+
+#include "rk3588-u-boot.dtsi"
+
+/ {
+   aliases {
+   mmc0 = &sdmmc;
+   };
+
+   chosen {
+   stdout-path = &uart2;
+   u-boot,spl-boot-order = &sdmmc;
+   };
+};
+
+&sdmmc {
+   bus-width = <4>;
+   u-boot,dm-spl;
+   status = "okay";
+};
diff --git a/arch/arm/mach-rockchip/rk3588/Kconfig 
b/arch/arm/mach-rockchip/rk3588/Kconfig
index e8c14e4187..def4094e2e 100644
--- a/arch/arm/mach-rockchip/rk3588/Kconfig
+++ b/arch/arm/mach-rockchip/rk3588/Kconfig
@@ -1,5 +1,18 @@
 if ROCKCHIP_RK3588
 
+config TARGET_RK3588_NEU6
+   bool "Edgeble Neural Compute Module 6(Neu6) SoM"
+   select BOARD_LATE_INIT
+   help
+ Neu6:
+ Neural Compute Module 6A(Neu6a) is a 96boards SoM-CB compute module
+ based on Rockchip RK3588 from Edgeble AI.
+
+ Neu6-IO:
+ Neural Compute Module 6(Neu6) IO board is an industrial form factor
+ IO board and Neu6a needs to mount on top of this IO board in order to
+ create complete Edgeble Neural Compute Module 6(Neu6) IO platform.
+
 config ROCKCHIP_BOOT_MODE_REG
default 0xfd588080
 
@@ -12,4 +25,6 @@ config SYS_SOC
 config SYS_MALLOC_F_LEN
default 0x8
 
+source board/edgeble/neural-compute-module-6/Kconfig
+
 endif
diff --git a/board/edgeble/neural-compute-module-6/Kconfig 
b/board/edgeble/neural-compute-module-6/Kconfig
new file mode 100644
index 00..c445454dde
--- /dev/null
+++ b/board/edgeble/neural-compute-module-6/Kconfig
@@ -0,0 +1,15 @@
+if TARGET_RK3588_NEU6
+
+config SYS_BOARD
+   default "neural-compute-module-6"
+
+config SYS_VENDOR
+   default "edgeble"
+
+config SYS_CONFIG_NAME
+   default "neural-compute-module-6"
+
+config BOARD_SPECIFIC_OPTIONS # dummy
+   def_bool y
+
+endif
diff --git a/board/edgeble/neural-compute-module-6/MAINTAINERS 
b/board/edgeble/neural-compute-module-6/MAINTAINERS
new file mode 100644
index 00..249df957f1
--- /dev/null
+++ b/board/edgeble/neural-compute-module-6/MAINTAINERS
@@ -0,0 +1,6 @@
+RK3588-NEU6
+M: Jagan Teki 
+S: Maintained
+F: board/edgeble/neural-compute-module-6
+F: include/configs/neural-compute-module-6.h
+F: configs/neu6a-io-rk3588_defconfig
diff --git a/board/edgeble/neural-compute-module-6/Makefile 
b/board/edgeble/neural-compute-module-6/Makefile
new file mode 100644
index 00..28310b1b34
--- /dev/null
+++ b/board/edgeble/neural-compute-module-6/Makefile
@@ -0,0 +1,7 @@
+#
+# Copyright (c) 2022 Edgeble AI Technologies Pvt. Ltd.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y += neu6.o
diff --git a/board/edgeble/neural-compute-module-6/neu6.c 
b/board/edgeble/neural-compute-module-6/neu6.c
new file mode 100644
index 00..3d2262ce97
--- /dev/null
+++ b/board/edgeble/neural-compute-module-6/neu6.c
@@ -0,0 +1,4 @@
+// SPDX-License-Identifier: 

[RFC PATCH 14/16] arm: rockchip: Add RK3588 arch core support

2023-01-25 Thread Jagan Teki
The Rockchip RK3588 is a ARM-based SoC with quad-core Cortex-A76
and quad-core Cortex-A55 including NEON and GPU, 6TOPS NPU,
Mali-G610 MP4, HDMI Out, HDMI In, DP, eDP, MIPI DSI, MIPI CSI2,
LPDDR4/4X/5, eMMC5.1, SD3.0/MMC4.5, USB OTG 3.0, Type-C, USB 2.0,
PCIe 3.0, SATA 3, Ethernet, SDIO3.0 I2C, UART, SPI, GPIO and PWM.

Add arch core support for it.

Signed-off-by: Jagan Teki 
---
 arch/arm/include/asm/arch-rk3588/boot0.h  |  11 ++
 arch/arm/include/asm/arch-rk3588/gpio.h   |  11 ++
 arch/arm/mach-rockchip/Kconfig|  20 +++
 arch/arm/mach-rockchip/Makefile   |   1 +
 arch/arm/mach-rockchip/rk3588/Kconfig |  15 ++
 arch/arm/mach-rockchip/rk3588/Makefile|   9 +
 arch/arm/mach-rockchip/rk3588/clk_rk3588.c|  33 
 arch/arm/mach-rockchip/rk3588/rk3588.c| 162 ++
 arch/arm/mach-rockchip/rk3588/syscon_rk3588.c |  32 
 include/configs/rk3588_common.h   |  32 
 10 files changed, 326 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-rk3588/boot0.h
 create mode 100644 arch/arm/include/asm/arch-rk3588/gpio.h
 create mode 100644 arch/arm/mach-rockchip/rk3588/Kconfig
 create mode 100644 arch/arm/mach-rockchip/rk3588/Makefile
 create mode 100644 arch/arm/mach-rockchip/rk3588/clk_rk3588.c
 create mode 100644 arch/arm/mach-rockchip/rk3588/rk3588.c
 create mode 100644 arch/arm/mach-rockchip/rk3588/syscon_rk3588.c
 create mode 100644 include/configs/rk3588_common.h

diff --git a/arch/arm/include/asm/arch-rk3588/boot0.h 
b/arch/arm/include/asm/arch-rk3588/boot0.h
new file mode 100644
index 00..dea2b20252
--- /dev/null
+++ b/arch/arm/include/asm/arch-rk3588/boot0.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * (C) Copyright 2021 Rockchip Electronics Co., Ltd
+ */
+
+#ifndef __ASM_ARCH_BOOT0_H__
+#define __ASM_ARCH_BOOT0_H__
+
+#include 
+
+#endif
diff --git a/arch/arm/include/asm/arch-rk3588/gpio.h 
b/arch/arm/include/asm/arch-rk3588/gpio.h
new file mode 100644
index 00..b48c0a5cf8
--- /dev/null
+++ b/arch/arm/include/asm/arch-rk3588/gpio.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * (C) Copyright 2021 Rockchip Electronics Co., Ltd
+ */
+
+#ifndef __ASM_ARCH_GPIO_H__
+#define __ASM_ARCH_GPIO_H__
+
+#include 
+
+#endif
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index b678ec4131..71774a5f2e 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -294,6 +294,25 @@ config ROCKCHIP_RK3568
  and video codec support. Peripherals include Gigabit Ethernet,
  USB2 host and OTG, SDIO, I2S, UARTs, SPI, I2C and PWMs.
 
+config ROCKCHIP_RK3588
+   bool "Support Rockchip RK3588"
+   select ARM64
+   select SUPPORT_SPL
+   select SPL
+   select CLK
+   select PINCTRL
+   select RAM
+   select REGMAP
+   select SYSCON
+   select BOARD_LATE_INIT
+   imply ROCKCHIP_COMMON_BOARD
+   help
+ The Rockchip RK3588 is a ARM-based SoC with quad-core Cortex-A76 and
+ quad-core Cortex-A55 including NEON and GPU, 6TOPS NPU, Mali-G610 MP4,
+ HDMI Out, HDMI In, DP, eDP, MIPI DSI, MIPI CSI2, LPDDR4/4X/5, eMMC5.1,
+ SD3.0/MMC4.5, USB OTG 3.0, Type-C, USB 2.0, PCIe 3.0, SATA 3, 
Ethernet,
+ SDIO3.0 I2C, UART, SPI, GPIO and PWM.
+
 config ROCKCHIP_RV1108
bool "Support Rockchip RV1108"
select CPU_V7A
@@ -491,6 +510,7 @@ source "arch/arm/mach-rockchip/rk3328/Kconfig"
 source "arch/arm/mach-rockchip/rk3368/Kconfig"
 source "arch/arm/mach-rockchip/rk3399/Kconfig"
 source "arch/arm/mach-rockchip/rk3568/Kconfig"
+source "arch/arm/mach-rockchip/rk3588/Kconfig"
 source "arch/arm/mach-rockchip/rv1108/Kconfig"
 source "arch/arm/mach-rockchip/rv1126/Kconfig"
 endif
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 32138fa723..bee4fa4b5a 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_ROCKCHIP_RK3328) += rk3328/
 obj-$(CONFIG_ROCKCHIP_RK3368) += rk3368/
 obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399/
 obj-$(CONFIG_ROCKCHIP_RK3568) += rk3568/
+obj-$(CONFIG_ROCKCHIP_RK3588) += rk3588/
 obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108/
 obj-$(CONFIG_ROCKCHIP_RV1126) += rv1126/
 
diff --git a/arch/arm/mach-rockchip/rk3588/Kconfig 
b/arch/arm/mach-rockchip/rk3588/Kconfig
new file mode 100644
index 00..e8c14e4187
--- /dev/null
+++ b/arch/arm/mach-rockchip/rk3588/Kconfig
@@ -0,0 +1,15 @@
+if ROCKCHIP_RK3588
+
+config ROCKCHIP_BOOT_MODE_REG
+   default 0xfd588080
+
+config ROCKCHIP_STIMER_BASE
+   default 0xfd8c8000
+
+config SYS_SOC
+   default "rk3588"
+
+config SYS_MALLOC_F_LEN
+   default 0x8
+
+endif
diff --git a/arch/arm/mach-rockchip/rk3588/Makefile 
b/arch/arm/mach-rockchip/rk3588/Makefile
new file mode 100644
index 00..4003eea87a
--- /dev/null
+++ b/arch/arm/mach-rockchip/rk3588/Makefile
@@ -0,0 +1,9 @@
+#
+#

[RFC PATCH 15/16] ARM: dts: rockchip: Add rk3588-u-boot.dtsi

2023-01-25 Thread Jagan Teki
Add u-boot,dm-spl and u-boot,dm-pre-reloc related properties
for Rockchip RK3588 SoC.

Signed-off-by: Jagan Teki 
---
 arch/arm/dts/rk3588-u-boot.dtsi | 101 
 1 file changed, 101 insertions(+)
 create mode 100644 arch/arm/dts/rk3588-u-boot.dtsi

diff --git a/arch/arm/dts/rk3588-u-boot.dtsi b/arch/arm/dts/rk3588-u-boot.dtsi
new file mode 100644
index 00..b5cc4dcc60
--- /dev/null
+++ b/arch/arm/dts/rk3588-u-boot.dtsi
@@ -0,0 +1,101 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2022 Edgeble AI Technologies Pvt. Ltd.
+ */
+
+#include "rockchip-u-boot.dtsi"
+#include 
+
+/ {
+   dmc {
+   compatible = "rockchip,rk3588-dmc";
+   u-boot,dm-pre-reloc;
+   status = "okay";
+   };
+
+   pmu1_grf: syscon@fd58a000 {
+   u-boot,dm-pre-reloc;
+   compatible = "rockchip,rk3588-pmu1-grf", "syscon";
+   reg = <0x0 0xfd58a000 0x0 0x2000>;
+   };
+
+   sdmmc: mmc@fe2c {
+   compatible = "rockchip,rk3588-dw-mshc", 
"rockchip,rk3288-dw-mshc";
+   reg = <0x0 0xfe2c 0x0 0x4000>;
+   interrupts = ;
+   clocks = <&cru SCLK_SDMMC_SAMPLE>, <&cru SCLK_SDMMC_DRV>,
+<&scmi_clk SCMI_HCLK_SD>, <&scmi_clk SCMI_CCLK_SD>;
+   clock-names = "ciu", "biu", "ciu-drive", "ciu-sample";
+   fifo-depth = <0x100>;
+   max-frequency = <2>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_det &sdmmc_bus4>;
+   status = "disabled";
+   };
+};
+
+&gpio0 {
+   u-boot,dm-spl;
+   status = "okay";
+};
+
+&gpio1 {
+   u-boot,dm-pre-reloc;
+   status = "okay";
+};
+
+&gpio2 {
+   u-boot,dm-pre-reloc;
+   status = "okay";
+};
+
+&gpio3 {
+   u-boot,dm-pre-reloc;
+   status = "okay";
+};
+
+&gpio4 {
+   u-boot,dm-pre-reloc;
+   status = "okay";
+};
+
+&scmi {
+   u-boot,dm-spl;
+};
+
+&scmi_clk {
+   u-boot,dm-spl;
+};
+
+&xin24m {
+   u-boot,dm-pre-reloc;
+   status = "okay";
+};
+
+&cru {
+   u-boot,dm-spl;
+   status = "okay";
+};
+
+&sys_grf {
+   u-boot,dm-spl;
+   status = "okay";
+};
+
+&uart2 {
+   clock-frequency = <2400>;
+   u-boot,dm-spl;
+   status = "okay";
+};
+
+&sdhci {
+   bus-width = <8>;
+   u-boot,dm-spl;
+   mmc-hs200-1_8v;
+   non-removable;
+   status = "okay";
+};
+
+&ioc {
+   u-boot,dm-spl;
+};
-- 
2.25.1



[RFC PATCH 13/16] arm64: dts: rockchip: rk3588: Add Edgeble Neu6 Model A IO

2023-01-25 Thread Jagan Teki
Neural Compute Module 6(Neu6) IO board is an industrial form factor
ready-to-use IO board from Edgeble AI.

IO board offers plenty of peripherals and connectivity options and
this patch enables basic eMMC and UART which is enough to successfully
boot Linux.

Neu6 needs to mount on top of this IO board in order to create a
complete Edgeble Neural Compute Module 6(Neu6) IO platform.

commit  ("arm64: dts: rockchip: rk3588: Add Edgeble Neu6
Model A IO")

Add support for Edgeble Neu6 Model A IO Board.

Signed-off-by: Jagan Teki 
---
 arch/arm/dts/Makefile|  3 +++
 arch/arm/dts/rk3588-edgeble-neu6a-io.dts | 27 
 2 files changed, 30 insertions(+)
 create mode 100644 arch/arm/dts/rk3588-edgeble-neu6a-io.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 103af9b99c..760b1abf3f 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -168,6 +168,9 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
rk3566-radxa-cm3-io.dtb \
rk3568-evb.dtb
 
+dtb-$(CONFIG_ROCKCHIP_RK3588) += \
+   rk3588-edgeble-neu6a-io.dtb
+
 dtb-$(CONFIG_ROCKCHIP_RV1108) += \
rv1108-elgin-r1.dtb \
rv1108-evb.dtb
diff --git a/arch/arm/dts/rk3588-edgeble-neu6a-io.dts 
b/arch/arm/dts/rk3588-edgeble-neu6a-io.dts
new file mode 100644
index 00..b515438920
--- /dev/null
+++ b/arch/arm/dts/rk3588-edgeble-neu6a-io.dts
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2022 Edgeble AI Technologies Pvt. Ltd.
+ */
+
+/dts-v1/;
+#include "rk3588.dtsi"
+#include "rk3588-edgeble-neu6a.dtsi"
+
+/ {
+   model = "Edgeble Neu6A IO Board";
+   compatible = "edgeble,neural-compute-module-6a-io",
+"edgeble,neural-compute-module-6a", "rockchip,rk3588";
+
+   aliases {
+   serial2 = &uart2;
+   };
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+};
+
+&uart2 {
+   pinctrl-0 = <&uart2m0_xfer>;
+   status = "okay";
+};
-- 
2.25.1



[RFC PATCH 12/16] arm64: dts: rockchip: rk3588: Add Edgeble Neu6 Model A SoM

2023-01-25 Thread Jagan Teki
Neural Compute Module 6(Neu2) is a 96boards SoM-CB compute module
based on Rockchip RK3588 from Edgeble AI.

General features:
- Rockchip RK3588
- up to 32GB LPDDR4x
- up to 128GB eMMC
- 2x MIPI CSI2 FPC

On module WiFi6/BT5 is available in the following Neu6 variants.

Neu6 needs to mount on top of associated Edgeble IO boards for
creating complete platform solutions.

Enable eMMC for now to boot Linux successfully.

commit <3d9a2f7e7c5e> ("arm64: dts: rockchip: rk3588: Add Edgeble Neu6
Model A SoM")

Add support for Edgeble Neu6 Model A SoM.

Signed-off-by: Jagan Teki 
---
 arch/arm/dts/rk3588-edgeble-neu6a.dtsi | 32 ++
 1 file changed, 32 insertions(+)
 create mode 100644 arch/arm/dts/rk3588-edgeble-neu6a.dtsi

diff --git a/arch/arm/dts/rk3588-edgeble-neu6a.dtsi 
b/arch/arm/dts/rk3588-edgeble-neu6a.dtsi
new file mode 100644
index 00..38e1a1e25f
--- /dev/null
+++ b/arch/arm/dts/rk3588-edgeble-neu6a.dtsi
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2022 Edgeble AI Technologies Pvt. Ltd.
+ */
+
+/ {
+   compatible = "edgeble,neural-compute-module-6a", "rockchip,rk3588";
+
+   aliases {
+   mmc0 = &sdhci;
+   };
+
+   vcc12v_dcin: vcc12v-dcin-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc12v_dcin";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+};
+
+&sdhci {
+   bus-width = <8>;
+   no-sdio;
+   no-sd;
+   non-removable;
+   max-frequency = <2>;
+   mmc-hs400-1_8v;
+   mmc-hs400-enhanced-strobe;
+   status = "okay";
+};
-- 
2.25.1



[RFC PATCH 09/16] dt-bindings: reset: add rk3588 reset definitions

2023-01-25 Thread Jagan Teki
Add reset ID defines for rk3588.

commit <0a8eb7dae617> ("dt-bindings: reset: add rk3588 reset
definitions")

Signed-off-by: Sebastian Reichel 
Signed-off-by: Jagan Teki 
---
 .../dt-bindings/reset/rockchip,rk3588-cru.h   | 754 ++
 1 file changed, 754 insertions(+)
 create mode 100644 include/dt-bindings/reset/rockchip,rk3588-cru.h

diff --git a/include/dt-bindings/reset/rockchip,rk3588-cru.h 
b/include/dt-bindings/reset/rockchip,rk3588-cru.h
new file mode 100644
index 00..738e56aead
--- /dev/null
+++ b/include/dt-bindings/reset/rockchip,rk3588-cru.h
@@ -0,0 +1,754 @@
+/* SPDX-License-Identifier: (GPL-2.0 or MIT) */
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co. Ltd.
+ * Copyright (c) 2022 Collabora Ltd.
+ *
+ * Author: Elaine Zhang 
+ * Author: Sebastian Reichel 
+ */
+
+#ifndef _DT_BINDINGS_RESET_ROCKCHIP_RK3588_H
+#define _DT_BINDINGS_RESET_ROCKCHIP_RK3588_H
+
+#define SRST_A_TOP_BIU 0
+#define SRST_P_TOP_BIU 1
+#define SRST_P_CSIPHY0 2
+#define SRST_CSIPHY0   3
+#define SRST_P_CSIPHY1 4
+#define SRST_CSIPHY1   5
+#define SRST_A_TOP_M500_BIU6
+
+#define SRST_A_TOP_M400_BIU7
+#define SRST_A_TOP_S200_BIU8
+#define SRST_A_TOP_S400_BIU9
+#define SRST_A_TOP_M300_BIU10
+#define SRST_USBDP_COMBO_PHY0_INIT 11
+#define SRST_USBDP_COMBO_PHY0_CMN  12
+#define SRST_USBDP_COMBO_PHY0_LANE 13
+#define SRST_USBDP_COMBO_PHY0_PCS  14
+#define SRST_USBDP_COMBO_PHY1_INIT 15
+
+#define SRST_USBDP_COMBO_PHY1_CMN  16
+#define SRST_USBDP_COMBO_PHY1_LANE 17
+#define SRST_USBDP_COMBO_PHY1_PCS  18
+#define SRST_DCPHY019
+#define SRST_P_MIPI_DCPHY0 20
+#define SRST_P_MIPI_DCPHY0_GRF 21
+
+#define SRST_DCPHY122
+#define SRST_P_MIPI_DCPHY1 23
+#define SRST_P_MIPI_DCPHY1_GRF 24
+#define SRST_P_APB2ASB_SLV_CDPHY   25
+#define SRST_P_APB2ASB_SLV_CSIPHY  26
+#define SRST_P_APB2ASB_SLV_VCCIO3_527
+#define SRST_P_APB2ASB_SLV_VCCIO6  28
+#define SRST_P_APB2ASB_SLV_EMMCIO  29
+#define SRST_P_APB2ASB_SLV_IOC_TOP 30
+#define SRST_P_APB2ASB_SLV_IOC_RIGHT   31
+
+#define SRST_P_CRU 32
+#define SRST_A_CHANNEL_SECURE2VO1USB   33
+#define SRST_A_CHANNEL_SECURE2CENTER   34
+#define SRST_H_CHANNEL_SECURE2VO1USB   35
+#define SRST_H_CHANNEL_SECURE2CENTER   36
+
+#define SRST_P_CHANNEL_SECURE2VO1USB   37
+#define SRST_P_CHANNEL_SECURE2CENTER   38
+
+#define SRST_H_AUDIO_BIU   39
+#define SRST_P_AUDIO_BIU   40
+#define SRST_H_I2S0_8CH41
+#define SRST_M_I2S0_8CH_TX 42
+#define SRST_M_I2S0_8CH_RX 43
+#define SRST_P_ACDCDIG 44
+#define SRST_H_I2S2_2CH45
+#define SRST_H_I2S3_2CH46
+
+#define SRST_M_I2S2_2CH47
+#define SRST_M_I2S3_2CH48
+#define SRST_DAC_ACDCDIG   49
+#define SRST_H_SPDIF0  50
+
+#define SRST_M_SPDIF0  51
+#define SRST_H_SPDIF1  52
+#define SRST_M_SPDIF1  53
+#define SRST_H_PDM154
+#define SRST_PDM1  55
+
+#define SRST_A_BUS_BIU 56
+#define SRST_P_BUS_BIU 57
+#define SRST_A_GIC 58
+#define SRST_A_GIC_DBG 59
+#define SRST_A_DMAC0   60
+#define SRST_A_DMAC1   61
+#define SRST_A_DMAC2   62
+#define SRST_P_I2C163
+#define SRST_P_I2C264
+#define SRST_P_I2C365
+#define SRST_P_I2C466
+#define SRST_P_I2C567
+#define SRST_P_I2C668
+#define SRST_P_I2C769
+#define SRST_P_I2C870
+
+#define SRST_I2C1  71
+#define SRST_I2C2  72
+#define SRST_I2C3  73
+#define SRST_I2C4  74
+#define SRST_I2C5  75
+#define SRST_I2C6  76
+#define SRST_I2C7  77
+#define SRST_I2C8  78
+#define SRST_P_CAN079
+#define SRST_CAN0  80
+#define SRST_P_CAN181
+#define SRST_CAN1  82
+#define SRST_P_CAN283
+#define SRST_CAN2  84
+#define SRST_P_SARADC  85
+
+#define SRST_P_TSADC   86
+#define SRST_TSADC 87
+#define SRST_P_UART1   88
+#define SRST_P_UART2   89
+#define SRST_P_UART3   90
+#define SRST_P_UART4   91
+#define SRST_P_UART5   92
+#define SRST_P_UART6   93

[RFC PATCH 10/16] arm: rockchip: Add ioc header for rk3588

2023-01-25 Thread Jagan Teki
Add IOC unit header include for rk3588.

Signed-off-by: Steven Liu 
Signed-off-by: Joseph Chen 
Signed-off-by: Jagan Teki 
---
 .../include/asm/arch-rockchip/ioc_rk3588.h| 102 ++
 1 file changed, 102 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-rockchip/ioc_rk3588.h

diff --git a/arch/arm/include/asm/arch-rockchip/ioc_rk3588.h 
b/arch/arm/include/asm/arch-rockchip/ioc_rk3588.h
new file mode 100644
index 00..2fd47b5d1c
--- /dev/null
+++ b/arch/arm/include/asm/arch-rockchip/ioc_rk3588.h
@@ -0,0 +1,102 @@
+/*
+ * (C) Copyright 2021 Rockchip Electronics Co., Ltd.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+#ifndef _ASM_ARCH_IOC_RK3588_H
+#define _ASM_ARCH_IOC_RK3588_H
+
+#include 
+
+struct rk3588_bus_ioc {
+   uint32_t reserved[3];  /* Address Offset: 0x */
+   uint32_t gpio0b_iomux_sel_h;   /* Address Offset: 0x000C */
+   uint32_t gpio0c_iomux_sel_l;   /* Address Offset: 0x0010 */
+   uint32_t gpio0c_iomux_sel_h;   /* Address Offset: 0x0014 */
+   uint32_t gpio0d_iomux_sel_l;   /* Address Offset: 0x0018 */
+   uint32_t gpio0d_iomux_sel_h;   /* Address Offset: 0x001C */
+   uint32_t gpio1a_iomux_sel_l;   /* Address Offset: 0x0020 */
+   uint32_t gpio1a_iomux_sel_h;   /* Address Offset: 0x0024 */
+   uint32_t gpio1b_iomux_sel_l;   /* Address Offset: 0x0028 */
+   uint32_t gpio1b_iomux_sel_h;   /* Address Offset: 0x002C */
+   uint32_t gpio1c_iomux_sel_l;   /* Address Offset: 0x0030 */
+   uint32_t gpio1c_iomux_sel_h;   /* Address Offset: 0x0034 */
+   uint32_t gpio1d_iomux_sel_l;   /* Address Offset: 0x0038 */
+   uint32_t gpio1d_iomux_sel_h;   /* Address Offset: 0x003C */
+   uint32_t gpio2a_iomux_sel_l;   /* Address Offset: 0x0040 */
+   uint32_t gpio2a_iomux_sel_h;   /* Address Offset: 0x0044 */
+   uint32_t gpio2b_iomux_sel_l;   /* Address Offset: 0x0048 */
+   uint32_t gpio2b_iomux_sel_h;   /* Address Offset: 0x004C */
+   uint32_t gpio2c_iomux_sel_l;   /* Address Offset: 0x0050 */
+   uint32_t gpio2c_iomux_sel_h;   /* Address Offset: 0x0054 */
+   uint32_t gpio2d_iomux_sel_l;   /* Address Offset: 0x0058 */
+   uint32_t gpio2d_iomux_sel_h;   /* Address Offset: 0x005C */
+   uint32_t gpio3a_iomux_sel_l;   /* Address Offset: 0x0060 */
+   uint32_t gpio3a_iomux_sel_h;   /* Address Offset: 0x0064 */
+   uint32_t gpio3b_iomux_sel_l;   /* Address Offset: 0x0068 */
+   uint32_t gpio3b_iomux_sel_h;   /* Address Offset: 0x006C */
+   uint32_t gpio3c_iomux_sel_l;   /* Address Offset: 0x0070 */
+   uint32_t gpio3c_iomux_sel_h;   /* Address Offset: 0x0074 */
+   uint32_t gpio3d_iomux_sel_l;   /* Address Offset: 0x0078 */
+   uint32_t gpio3d_iomux_sel_h;   /* Address Offset: 0x007C */
+   uint32_t gpio4a_iomux_sel_l;   /* Address Offset: 0x0080 */
+   uint32_t gpio4a_iomux_sel_h;   /* Address Offset: 0x0084 */
+   uint32_t gpio4b_iomux_sel_l;   /* Address Offset: 0x0088 */
+   uint32_t gpio4b_iomux_sel_h;   /* Address Offset: 0x008C */
+   uint32_t gpio4c_iomux_sel_l;   /* Address Offset: 0x0090 */
+   uint32_t gpio4c_iomux_sel_h;   /* Address Offset: 0x0094 */
+   uint32_t gpio4d_iomux_sel_l;   /* Address Offset: 0x0098 */
+   uint32_t gpio4d_iomux_sel_h;   /* Address Offset: 0x009C */
+};
+check_member(rk3588_bus_ioc, gpio4d_iomux_sel_h, 0x009C);
+
+
+struct rk3588_pmu1_ioc {
+   uint32_t gpio0a_iomux_sel_l;   /* Address Offset: 0x */
+   uint32_t gpio0a_iomux_sel_h;   /* Address Offset: 0x0004 */
+   uint32_t gpio0b_iomux_sel_l;   /* Address Offset: 0x0008 */
+   uint32_t reserved0012; /* Address Offset: 0x000C */
+   uint32_t gpio0a_ds_l;  /* Address Offset: 0x0010 */
+   uint32_t gpio0a_ds_h;  /* Address Offset: 0x0014 */
+   uint32_t gpio0b_ds_l;  /* Address Offset: 0x0018 */
+   uint32_t reserved0028; /* Address Offset: 0x001C */
+   uint32_t gpio0a_p; /* Address Offset: 0x0020 */
+   uint32_t gpio0b_p; /* Address Offset: 0x0024 */
+   uint32_t gpio0a_ie;/* Address Offset: 0x0028 */
+   uint32_t gpio0b_ie;/* Address Offset: 0x002C */
+   uint32_t gpio0a_smt;   /* Address Offset: 0x0030 */
+   uint32_t gpio0b_smt;   /* Address Offset: 0x0034 */
+   uint32_t gpio0a_pdis;  /* Address Offset: 0x0038 */
+   uint32_t gpio0b_pdis;  /* Address Offset: 0x003C */
+   uint32_t xin_con;  /* Address Offset: 0x0040 */
+};
+check_member(rk3588_pmu1_ioc, xin_con, 0x0040);
+
+struct rk3588_pmu2_ioc {
+   uint32_t gpio0b_iomux_sel_h;  /* Address Offset: 0x */
+   uint32_t gpio0c_iomux_sel_l;  /* Address Offset: 0x0004 */
+   uint32_t gpio0c_iomux_sel_h;  /* Address Offset: 0x0008 */
+   uint32_t gpio0d_iomux_sel_l;  /* Address Offset: 0x000C */
+   uint32_t gpio0d_iomux_sel_h;  /* Address Offs

[RFC PATCH 08/16] dt-bindings: power: Add power-domain header for rk3588

2023-01-25 Thread Jagan Teki
Add power-domain header for RK3588 SoC from description in TRM.

commit <67944950c2d0> ("dt-bindings: power: add power-domain header for
rk3588")

Signed-off-by: Finley Xiao 
Signed-off-by: Jagan Teki 
---
 include/dt-bindings/power/rk3588-power.h | 69 
 1 file changed, 69 insertions(+)
 create mode 100644 include/dt-bindings/power/rk3588-power.h

diff --git a/include/dt-bindings/power/rk3588-power.h 
b/include/dt-bindings/power/rk3588-power.h
new file mode 100644
index 00..1b92fec013
--- /dev/null
+++ b/include/dt-bindings/power/rk3588-power.h
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: (GPL-2.0 or MIT) */
+#ifndef __DT_BINDINGS_POWER_RK3588_POWER_H__
+#define __DT_BINDINGS_POWER_RK3588_POWER_H__
+
+/* VD_LITDSU */
+#define RK3588_PD_CPU_00
+#define RK3588_PD_CPU_11
+#define RK3588_PD_CPU_22
+#define RK3588_PD_CPU_33
+
+/* VD_BIGCORE0 */
+#define RK3588_PD_CPU_44
+#define RK3588_PD_CPU_55
+
+/* VD_BIGCORE1 */
+#define RK3588_PD_CPU_66
+#define RK3588_PD_CPU_77
+
+/* VD_NPU */
+#define RK3588_PD_NPU  8
+#define RK3588_PD_NPUTOP   9
+#define RK3588_PD_NPU1 10
+#define RK3588_PD_NPU2 11
+
+/* VD_GPU */
+#define RK3588_PD_GPU  12
+
+/* VD_VCODEC */
+#define RK3588_PD_VCODEC   13
+#define RK3588_PD_RKVDEC0  14
+#define RK3588_PD_RKVDEC1  15
+#define RK3588_PD_VENC016
+#define RK3588_PD_VENC117
+
+/* VD_DD01 */
+#define RK3588_PD_DDR0118
+
+/* VD_DD23 */
+#define RK3588_PD_DDR2319
+
+/* VD_LOGIC */
+#define RK3588_PD_CENTER   20
+#define RK3588_PD_VDPU 21
+#define RK3588_PD_RGA3022
+#define RK3588_PD_AV1  23
+#define RK3588_PD_VOP  24
+#define RK3588_PD_VO0  25
+#define RK3588_PD_VO1  26
+#define RK3588_PD_VI   27
+#define RK3588_PD_ISP1 28
+#define RK3588_PD_FEC  29
+#define RK3588_PD_RGA3130
+#define RK3588_PD_USB  31
+#define RK3588_PD_PHP  32
+#define RK3588_PD_GMAC 33
+#define RK3588_PD_PCIE 34
+#define RK3588_PD_NVM  35
+#define RK3588_PD_NVM0 36
+#define RK3588_PD_SDIO 37
+#define RK3588_PD_AUDIO38
+#define RK3588_PD_SECURE   39
+#define RK3588_PD_SDMMC40
+#define RK3588_PD_CRYPTO   41
+#define RK3588_PD_BUS  42
+
+/* VD_PMU */
+#define RK3588_PD_PMU1 43
+
+#endif
-- 
2.25.1



[RFC PATCH 05/16] clk: rockchip: Add rk3588 clk support

2023-01-25 Thread Jagan Teki
Add clock driver support for Rockchip RK3588 SoC.

Signed-off-by: Elaine Zhang 
Signed-off-by: Jagan Teki 
---
 drivers/clk/rockchip/Makefile |1 +
 drivers/clk/rockchip/clk_rk3588.c | 2019 +
 2 files changed, 2020 insertions(+)
 create mode 100644 drivers/clk/rockchip/clk_rk3588.c

diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index f719f4e379..9e379cc2e3 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -16,5 +16,6 @@ obj-$(CONFIG_ROCKCHIP_RK3328) += clk_rk3328.o
 obj-$(CONFIG_ROCKCHIP_RK3368) += clk_rk3368.o
 obj-$(CONFIG_ROCKCHIP_RK3399) += clk_rk3399.o
 obj-$(CONFIG_ROCKCHIP_RK3568) += clk_rk3568.o
+obj-$(CONFIG_ROCKCHIP_RK3588) += clk_rk3588.o
 obj-$(CONFIG_ROCKCHIP_RV1108) += clk_rv1108.o
 obj-$(CONFIG_ROCKCHIP_RV1126) += clk_rv1126.o
diff --git a/drivers/clk/rockchip/clk_rk3588.c 
b/drivers/clk/rockchip/clk_rk3588.c
new file mode 100644
index 00..55532b5c2a
--- /dev/null
+++ b/drivers/clk/rockchip/clk_rk3588.c
@@ -0,0 +1,2019 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 Fuzhou Rockchip Electronics Co., Ltd
+ * Author: Elaine Zhang 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define DIV_TO_RATE(input_rate, div)   ((input_rate) / ((div) + 1))
+
+static struct rockchip_pll_rate_table rk3588_pll_rates[] = {
+   /* _mhz, _p, _m, _s, _k */
+   RK3588_PLL_RATE(15, 2, 250, 1, 0),
+   RK3588_PLL_RATE(12, 2, 200, 1, 0),
+   RK3588_PLL_RATE(118800, 2, 198, 1, 0),
+   RK3588_PLL_RATE(11, 3, 550, 2, 0),
+   RK3588_PLL_RATE(100800, 2, 336, 2, 0),
+   RK3588_PLL_RATE(10, 3, 500, 2, 0),
+   RK3588_PLL_RATE(9, 2, 300, 2, 0),
+   RK3588_PLL_RATE(85000, 3, 425, 2, 0),
+   RK3588_PLL_RATE(81600, 2, 272, 2, 0),
+   RK3588_PLL_RATE(786432000, 2, 262, 2, 9437),
+   RK3588_PLL_RATE(78600, 1, 131, 2, 0),
+   RK3588_PLL_RATE(722534400, 8, 963, 2, 24850),
+   RK3588_PLL_RATE(6, 2, 200, 2, 0),
+   RK3588_PLL_RATE(59400, 2, 198, 2, 0),
+   RK3588_PLL_RATE(2, 3, 400, 4, 0),
+   RK3588_PLL_RATE(1, 3, 400, 5, 0),
+   { /* sentinel */ },
+};
+
+static struct rockchip_pll_clock rk3588_pll_clks[] = {
+   [B0PLL] = PLL(pll_rk3588, PLL_B0PLL, RK3588_B0_PLL_CON(0),
+ RK3588_B0_PLL_MODE_CON, 0, 15, 0,
+ rk3588_pll_rates),
+   [B1PLL] = PLL(pll_rk3588, PLL_B1PLL, RK3588_B1_PLL_CON(8),
+ RK3588_B1_PLL_MODE_CON, 0, 15, 0,
+ rk3588_pll_rates),
+   [LPLL] = PLL(pll_rk3588, PLL_LPLL, RK3588_LPLL_CON(16),
+RK3588_LPLL_MODE_CON, 0, 15, 0, rk3588_pll_rates),
+   [V0PLL] = PLL(pll_rk3588, PLL_V0PLL, RK3588_PLL_CON(88),
+ RK3588_MODE_CON0, 4, 15, 0, rk3588_pll_rates),
+   [AUPLL] = PLL(pll_rk3588, PLL_AUPLL, RK3588_PLL_CON(96),
+ RK3588_MODE_CON0, 6, 15, 0, rk3588_pll_rates),
+   [CPLL] = PLL(pll_rk3588, PLL_CPLL, RK3588_PLL_CON(104),
+RK3588_MODE_CON0, 8, 15, 0, rk3588_pll_rates),
+   [GPLL] = PLL(pll_rk3588, PLL_GPLL, RK3588_PLL_CON(112),
+RK3588_MODE_CON0, 2, 15, 0, rk3588_pll_rates),
+   [NPLL] = PLL(pll_rk3588, PLL_NPLL, RK3588_PLL_CON(120),
+RK3588_MODE_CON0, 0, 15, 0, rk3588_pll_rates),
+   [PPLL] = PLL(pll_rk3588, PLL_PPLL, RK3588_PMU_PLL_CON(128),
+RK3588_MODE_CON0, 10, 15, 0, rk3588_pll_rates),
+};
+
+#ifndef CONFIG_SPL_BUILD
+/*
+ *
+ * rational_best_approximation(31415, 1,
+ * (1 << 8) - 1, (1 << 5) - 1, &n, &d);
+ *
+ * you may look at given_numerator as a fixed point number,
+ * with the fractional part size described in given_denominator.
+ *
+ * for theoretical background, see:
+ * http://en.wikipedia.org/wiki/Continued_fraction
+ */
+static void rational_best_approximation(unsigned long given_numerator,
+   unsigned long given_denominator,
+   unsigned long max_numerator,
+   unsigned long max_denominator,
+   unsigned long *best_numerator,
+   unsigned long *best_denominator)
+{
+   unsigned long n, d, n0, d0, n1, d1;
+
+   n = given_numerator;
+   d = given_denominator;
+   n0 = 0;
+   d1 = 0;
+   n1 = 1;
+   d0 = 1;
+   for (;;) {
+   unsigned long t, a;
+
+   if (n1 > max_numerator || d1 > max_denominator) {
+   n1 = n0;
+   d1 = d0;
+   break;
+   }
+   if (d == 0)
+   break;
+   t = d;
+  

[RFC PATCH 07/16] ram: rockchip: Add rk3588 ddr driver support

2023-01-25 Thread Jagan Teki
Add ddr driver for rk3588 to get the ram capacity.

Signed-off-by: Jagan Teki 
---
 drivers/ram/rockchip/Makefile   |  1 +
 drivers/ram/rockchip/sdram_rk3588.c | 56 +
 2 files changed, 57 insertions(+)
 create mode 100644 drivers/ram/rockchip/sdram_rk3588.c

diff --git a/drivers/ram/rockchip/Makefile b/drivers/ram/rockchip/Makefile
index 98839ad6a6..36dc0500da 100644
--- a/drivers/ram/rockchip/Makefile
+++ b/drivers/ram/rockchip/Makefile
@@ -14,5 +14,6 @@ obj-$(CONFIG_ROCKCHIP_RK3308) = sdram_rk3308.o
 obj-$(CONFIG_ROCKCHIP_RK3328) = sdram_rk3328.o sdram_pctl_px30.o 
sdram_phy_px30.o
 obj-$(CONFIG_ROCKCHIP_RK3399) += sdram_rk3399.o
 obj-$(CONFIG_ROCKCHIP_RK3568) += sdram_rk3568.o
+obj-$(CONFIG_ROCKCHIP_RK3588) += sdram_rk3588.o
 obj-$(CONFIG_ROCKCHIP_RV1126) += sdram_rv1126.o sdram_pctl_px30.o
 obj-$(CONFIG_ROCKCHIP_SDRAM_COMMON) += sdram_common.o
diff --git a/drivers/ram/rockchip/sdram_rk3588.c 
b/drivers/ram/rockchip/sdram_rk3588.c
new file mode 100644
index 00..16fcea595a
--- /dev/null
+++ b/drivers/ram/rockchip/sdram_rk3588.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021 Rockchip Electronics Co., Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct dram_info {
+   struct ram_info info;
+   struct rk3588_pmu1grf *pmugrf;
+};
+
+static int rk3588_dmc_probe(struct udevice *dev)
+{
+   struct dram_info *priv = dev_get_priv(dev);
+
+   priv->pmugrf = syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF);
+   priv->info.base = CFG_SYS_SDRAM_BASE;
+   priv->info.size =
+   rockchip_sdram_size((phys_addr_t)&priv->pmugrf->os_reg[2]);
+
+   return 0;
+}
+
+static int rk3588_dmc_get_info(struct udevice *dev, struct ram_info *info)
+{
+   struct dram_info *priv = dev_get_priv(dev);
+
+   *info = priv->info;
+
+   return 0;
+}
+
+static struct ram_ops rk3588_dmc_ops = {
+   .get_info = rk3588_dmc_get_info,
+};
+
+static const struct udevice_id rk3588_dmc_ids[] = {
+   { .compatible = "rockchip,rk3588-dmc" },
+   { }
+};
+
+U_BOOT_DRIVER(dmc_rk3588) = {
+   .name = "rockchip_rk3588_dmc",
+   .id = UCLASS_RAM,
+   .of_match = rk3588_dmc_ids,
+   .ops = &rk3588_dmc_ops,
+   .probe = rk3588_dmc_probe,
+   .priv_auto = sizeof(struct dram_info),
+};
-- 
2.25.1



[RFC PATCH 06/16] clk: rockchip: pll: Add pll_rk3588 type for rk3588

2023-01-25 Thread Jagan Teki
Add RK3588 pll set and get rate clock support.

Signed-off-by: Elaine Zhang 
Signed-off-by: Jagan Teki 
---
 arch/arm/include/asm/arch-rockchip/clock.h |  24 ++
 drivers/clk/rockchip/clk_pll.c | 267 -
 2 files changed, 288 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/clock.h 
b/arch/arm/include/asm/arch-rockchip/clock.h
index 566bdcc4fa..90e66c7da0 100644
--- a/arch/arm/include/asm/arch-rockchip/clock.h
+++ b/arch/arm/include/asm/arch-rockchip/clock.h
@@ -22,6 +22,14 @@ enum {
ROCKCHIP_SYSCON_PMUSGRF,
ROCKCHIP_SYSCON_CIC,
ROCKCHIP_SYSCON_MSCH,
+   ROCKCHIP_SYSCON_USBGRF,
+   ROCKCHIP_SYSCON_PCIE30_PHY_GRF,
+   ROCKCHIP_SYSCON_PHP_GRF,
+   ROCKCHIP_SYSCON_PIPE_PHY0_GRF,
+   ROCKCHIP_SYSCON_PIPE_PHY1_GRF,
+   ROCKCHIP_SYSCON_PIPE_PHY2_GRF,
+   ROCKCHIP_SYSCON_VOP_GRF,
+   ROCKCHIP_SYSCON_VO_GRF,
 };
 
 /* Standard Rockchip clock numbers */
@@ -61,6 +69,15 @@ enum rk_clk_id {
.frac = _frac,  \
 }
 
+#define RK3588_PLL_RATE(_rate, _p, _m, _s, _k) \
+{  \
+   .rate   = _rate##U, \
+   .p = _p,\
+   .m = _m,\
+   .s = _s,\
+   .k = _k,\
+}
+
 struct rockchip_pll_rate_table {
unsigned long rate;
unsigned int nr;
@@ -74,6 +91,11 @@ struct rockchip_pll_rate_table {
unsigned int postdiv2;
unsigned int dsmpd;
unsigned int frac;
+   /* for RK3588 */
+   unsigned int m;
+   unsigned int p;
+   unsigned int s;
+   unsigned int k;
 };
 
 enum rockchip_pll_type {
@@ -82,6 +104,7 @@ enum rockchip_pll_type {
pll_rk3328,
pll_rk3366,
pll_rk3399,
+   pll_rk3588,
 };
 
 struct rockchip_pll_clock {
@@ -171,5 +194,6 @@ int rockchip_get_clk(struct udevice **devp);
  * Return: 0 success, or error value
  */
 int rockchip_reset_bind(struct udevice *pdev, u32 reg_offset, u32 reg_number);
+int rockchip_get_scmi_clk(struct udevice **devp);
 
 #endif
diff --git a/drivers/clk/rockchip/clk_pll.c b/drivers/clk/rockchip/clk_pll.c
index 09b97cf57a..d657ef38f3 100644
--- a/drivers/clk/rockchip/clk_pll.c
+++ b/drivers/clk/rockchip/clk_pll.c
@@ -45,6 +45,10 @@ enum {
 
 #define MIN_FOUTVCO_FREQ   (800 * MHZ)
 #define MAX_FOUTVCO_FREQ   (2000 * MHZ)
+#define RK3588_VCO_MIN_HZ  (2250UL * MHZ)
+#define RK3588_VCO_MAX_HZ  (4500UL * MHZ)
+#define RK3588_FOUT_MIN_HZ (37UL * MHZ)
+#define RK3588_FOUT_MAX_HZ (4500UL * MHZ)
 
 int gcd(int m, int n)
 {
@@ -164,6 +168,65 @@ rockchip_pll_clk_set_by_auto(ulong fin_hz,
return rate_table;
 }
 
+static struct rockchip_pll_rate_table *
+rk3588_pll_clk_set_by_auto(unsigned long fin_hz,
+  unsigned long fout_hz)
+{
+   struct rockchip_pll_rate_table *rate_table = &rockchip_auto_table;
+   u32 p, m, s;
+   ulong fvco, fref, fout, ffrac;
+
+   if (fin_hz == 0 || fout_hz == 0 || fout_hz == fin_hz)
+   return NULL;
+
+   if (fout_hz > RK3588_FOUT_MAX_HZ || fout_hz < RK3588_FOUT_MIN_HZ)
+   return NULL;
+
+   if (fin_hz / MHZ * MHZ == fin_hz && fout_hz / MHZ * MHZ == fout_hz) {
+   for (s = 0; s <= 6; s++) {
+   fvco = fout_hz << s;
+   if (fvco < RK3588_VCO_MIN_HZ ||
+   fvco > RK3588_VCO_MAX_HZ)
+   continue;
+   for (p = 2; p <= 4; p++) {
+   for (m = 64; m <= 1023; m++) {
+   if (fvco == m * fin_hz / p) {
+   rate_table->p = p;
+   rate_table->m = m;
+   rate_table->s = s;
+   rate_table->k = 0;
+   return rate_table;
+   }
+   }
+   }
+   }
+   pr_err("CANNOT FIND Fout by auto,fout = %lu\n", fout_hz);
+   } else {
+   for (s = 0; s <= 6; s++) {
+   fvco = fout_hz << s;
+   if (fvco < RK3588_VCO_MIN_HZ ||
+   fvco > RK3588_VCO_MAX_HZ)
+   continue;
+   for (p = 1; p <= 4; p++) {
+   for (m = 64; m <= 1023; m++) {
+   if ((fvco >= m * fin_hz / p) && (fvco < 
(m + 1) * fin_hz / p)) {
+   rate_table->p = p;

[RFC PATCH 04/16] dt-bindings: clk: Add dt-binding header for RK3588

2023-01-25 Thread Jagan Teki
Add the dt-bindings header for the Rockchip RK3588, that gets
shared between the clock controller and the clock references
in the dts.

commit  ("dt-bindings: clock: add rk3588 clock
definitions")

Signed-off-by: Jagan Teki 
---
 .../dt-bindings/clock/rockchip,rk3588-cru.h   | 766 ++
 1 file changed, 766 insertions(+)
 create mode 100644 include/dt-bindings/clock/rockchip,rk3588-cru.h

diff --git a/include/dt-bindings/clock/rockchip,rk3588-cru.h 
b/include/dt-bindings/clock/rockchip,rk3588-cru.h
new file mode 100644
index 00..b5616bca7b
--- /dev/null
+++ b/include/dt-bindings/clock/rockchip,rk3588-cru.h
@@ -0,0 +1,766 @@
+/* SPDX-License-Identifier: (GPL-2.0 or MIT) */
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co. Ltd.
+ * Copyright (c) 2022 Collabora Ltd.
+ *
+ * Author: Elaine Zhang 
+ * Author: Sebastian Reichel 
+ */
+
+#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3588_H
+#define _DT_BINDINGS_CLK_ROCKCHIP_RK3588_H
+
+/* cru-clocks indices */
+
+#define PLL_B0PLL  0
+#define PLL_B1PLL  1
+#define PLL_LPLL   2
+#define PLL_V0PLL  3
+#define PLL_AUPLL  4
+#define PLL_CPLL   5
+#define PLL_GPLL   6
+#define PLL_NPLL   7
+#define PLL_PPLL   8
+#define ARMCLK_L   9
+#define ARMCLK_B01 10
+#define ARMCLK_B23 11
+#define PCLK_BIGCORE0_ROOT 12
+#define PCLK_BIGCORE0_PVTM 13
+#define PCLK_BIGCORE1_ROOT 14
+#define PCLK_BIGCORE1_PVTM 15
+#define PCLK_DSU_S_ROOT16
+#define PCLK_DSU_ROOT  17
+#define PCLK_DSU_NS_ROOT   18
+#define PCLK_LITCORE_PVTM  19
+#define PCLK_DBG   20
+#define PCLK_DSU   21
+#define PCLK_S_DAPLITE 22
+#define PCLK_M_DAPLITE 23
+#define MBIST_MCLK_PDM124
+#define MBIST_CLK_ACDCDIG  25
+#define HCLK_I2S2_2CH  26
+#define HCLK_I2S3_2CH  27
+#define CLK_I2S2_2CH_SRC   28
+#define CLK_I2S2_2CH_FRAC  29
+#define CLK_I2S2_2CH   30
+#define MCLK_I2S2_2CH  31
+#define I2S2_2CH_MCLKOUT   32
+#define CLK_DAC_ACDCDIG33
+#define CLK_I2S3_2CH_SRC   34
+#define CLK_I2S3_2CH_FRAC  35
+#define CLK_I2S3_2CH   36
+#define MCLK_I2S3_2CH  37
+#define I2S3_2CH_MCLKOUT   38
+#define PCLK_ACDCDIG   39
+#define HCLK_I2S0_8CH  40
+#define CLK_I2S0_8CH_TX_SRC41
+#define CLK_I2S0_8CH_TX_FRAC   42
+#define MCLK_I2S0_8CH_TX   43
+#define CLK_I2S0_8CH_TX44
+#define CLK_I2S0_8CH_RX_SRC45
+#define CLK_I2S0_8CH_RX_FRAC   46
+#define MCLK_I2S0_8CH_RX   47
+#define CLK_I2S0_8CH_RX48
+#define I2S0_8CH_MCLKOUT   49
+#define HCLK_PDM1  50
+#define MCLK_PDM1  51
+#define HCLK_AUDIO_ROOT52
+#define PCLK_AUDIO_ROOT53
+#define HCLK_SPDIF054
+#define CLK_SPDIF0_SRC 55
+#define CLK_SPDIF0_FRAC56
+#define MCLK_SPDIF057
+#define CLK_SPDIF0 58
+#define CLK_SPDIF1 59
+#define HCLK_SPDIF160
+#define CLK_SPDIF1_SRC 61
+#define CLK_SPDIF1_FRAC62
+#define MCLK_SPDIF163
+#define ACLK_AV1_ROOT  64
+#define ACLK_AV1   65
+#define PCLK_AV1_ROOT  66
+#define PCLK_AV1   67
+#define PCLK_MAILBOX0  68
+#define PCLK_MAILBOX1  69
+#define PCLK_MAILBOX2  70
+#define PCLK_PMU2  71
+#define PCLK_PMUCM0_INTMUX 72
+#define PCLK_DDRCM0_INTMUX 73
+#define PCLK_TOP   74
+#define PCLK_PWM1  75
+#define CLK_PWM1   76
+#define CLK_PWM1_CAPTURE   77
+#define PCLK_PWM2  78
+#define CLK_PWM2   79
+#define CLK_PWM2_CAPTURE   80
+#define PCLK_PWM3  81
+#define CLK_PWM3   82
+#define CLK_PWM3_CAPTURE   83
+#define PCLK_BUSTIMER0 84
+#define PCLK_BUSTIMER1 85
+#define CLK_BUS_TIMER_ROOT 86
+#define CLK_BUSTIMER0  87
+#define CLK_BUSTIMER1  88
+#define CLK_BUSTIMER2  89
+#define CLK_BUSTIMER3  90
+#define CLK_BUSTIMER4  9

[RFC PATCH 03/16] arm: rockchip: Add grf header for rk3588

2023-01-25 Thread Jagan Teki
Add GRF header for Rockchip RK3588.

Signed-off-by: Jagan Teki 
---
 .../include/asm/arch-rockchip/grf_rk3588.h| 35 +++
 1 file changed, 35 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-rockchip/grf_rk3588.h

diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3588.h 
b/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
new file mode 100644
index 00..e0694068bb
--- /dev/null
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * (C) Copyright 2021 Rockchip Electronics Co., Ltd
+ */
+
+#ifndef __SOC_ROCKCHIP_RK3588_GRF_H__
+#define __SOC_ROCKCHIP_RK3588_GRF_H__
+
+struct rk3588_pmu1grf {
+   unsigned int soc_con[12];
+   unsigned int reserved0[(0x0050 - 0x002c) / 4 - 1];
+   unsigned int biu_con;
+   unsigned int biu_sts;
+   unsigned int reserved1[(0x0060 - 0x0054) / 4 - 1];
+   unsigned int soc_sts;
+   unsigned int reserved2[(0x0080 - 0x0060) / 4 - 1];
+   unsigned int mem_con[4];
+   unsigned int reserved3[(0x0200 - 0x008c) / 4 - 1];
+   unsigned int os_reg[8];
+   unsigned int reserved4[(0x0230 - 0x021c) / 4 - 1];
+   unsigned int rst_sts;
+   unsigned int rst_clr;
+   unsigned int reserved5[(0x0380 - 0x0234) / 4 - 1];
+   unsigned int sd_detect_con;
+   unsigned int reserved6[(0x0390 - 0x0380) / 4 - 1];
+   unsigned int sd_detect_sts;
+   unsigned int reserved7[(0x03a0 - 0x0390) / 4 - 1];
+   unsigned int sd_detect_clr;
+   unsigned int reserved8[(0x03b0 - 0x03a0) / 4 - 1];
+   unsigned int sd_detect_cnt;
+};
+
+check_member(rk3588_pmu1grf, sd_detect_cnt, 0x03b0);
+
+#endif /*__SOC_ROCKCHIP_RK3588_GRF_H__ */
-- 
2.25.1



[RFC PATCH 02/16] arm: rockchip: Add cru header for rk3588

2023-01-25 Thread Jagan Teki
Add clock and reset unit header include for rk3588.

Signed-off-by: Elaine Zhang 
Signed-off-by: Jagan Teki 
---
 .../include/asm/arch-rockchip/cru_rk3588.h| 451 ++
 1 file changed, 451 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-rockchip/cru_rk3588.h

diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3588.h 
b/arch/arm/include/asm/arch-rockchip/cru_rk3588.h
new file mode 100644
index 00..3ea59e9008
--- /dev/null
+++ b/arch/arm/include/asm/arch-rockchip/cru_rk3588.h
@@ -0,0 +1,451 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2020 Rockchip Electronics Co. Ltd.
+ * Author: Elaine Zhang 
+ */
+
+#ifndef _ASM_ARCH_CRU_RK3588_H
+#define _ASM_ARCH_CRU_RK3588_H
+
+#define MHz100
+#define KHz1000
+#define OSC_HZ (24 * MHz)
+
+#define CPU_PVTPLL_HZ  (1008 * MHz)
+#define LPLL_HZ(816 * MHz)
+#define GPLL_HZ(1188 * MHz)
+#define CPLL_HZ(1500 * MHz)
+#define NPLL_HZ (850 * MHz)
+#define PPLL_HZ(1100 * MHz)
+
+/* RK3588 pll id */
+enum rk3588_pll_id {
+   B0PLL,
+   B1PLL,
+   LPLL,
+   CPLL,
+   GPLL,
+   NPLL,
+   V0PLL,
+   AUPLL,
+   PPLL,
+   PLL_COUNT,
+};
+
+struct rk3588_clk_info {
+   unsigned long id;
+   char *name;
+   bool is_cru;
+};
+
+struct rk3588_clk_priv {
+   struct rk3588_cru *cru;
+   struct rk3588_grf *grf;
+   ulong ppll_hz;
+   ulong gpll_hz;
+   ulong cpll_hz;
+   ulong npll_hz;
+   ulong v0pll_hz;
+   ulong aupll_hz;
+   ulong armclk_hz;
+   ulong armclk_enter_hz;
+   ulong armclk_init_hz;
+   bool sync_kernel;
+   bool set_armclk_rate;
+};
+
+struct rk3588_pll {
+   unsigned int con0;
+   unsigned int con1;
+   unsigned int con2;
+   unsigned int con3;
+   unsigned int con4;
+   unsigned int reserved0[3];
+};
+
+struct rk3588_cru {
+   struct rk3588_pll pll[18];
+   unsigned int reserved0[16];/* Address Offset: 0x0240 */
+   unsigned int mode_con00;/* Address Offset: 0x0280 */
+   unsigned int reserved1[31];/* Address Offset: 0x0284 */
+   unsigned int clksel_con[178]; /* Address Offset: 0x0300 */
+   unsigned int reserved2[142];/* Address Offset: 0x05c8 */
+   unsigned int clkgate_con[78];/* Address Offset: 0x0800 */
+   unsigned int reserved3[50];/* Address Offset: 0x0938 */
+   unsigned int softrst_con[78];/* Address Offset: 0x0400 */
+   unsigned int reserved4[50];/* Address Offset: 0x0b38 */
+   unsigned int glb_cnt_th;/* Address Offset: 0x0c00 */
+   unsigned int glb_rst_st;/* Address Offset: 0x0c04 */
+   unsigned int glb_srst_fst;/* Address Offset: 0x0c08 */
+   unsigned int glb_srsr_snd; /* Address Offset: 0x0c0c */
+   unsigned int glb_rst_con;/* Address Offset: 0x0c10 */
+   unsigned int reserved5[4];/* Address Offset: 0x0c14 */
+   unsigned int sdio_con[2];/* Address Offset: 0x0c24 */
+   unsigned int reserved7;/* Address Offset: 0x0c2c */
+   unsigned int sdmmc_con[2];/* Address Offset: 0x0c30 */
+   unsigned int reserved8[48562];/* Address Offset: 0x0c38 */
+   unsigned int pmuclksel_con[21]; /* Address Offset: 0x0100 */
+   unsigned int reserved9[299];/* Address Offset: 0x0c38 */
+   unsigned int pmuclkgate_con[9]; /* Address Offset: 0x0100 */
+};
+
+check_member(rk3588_cru, mode_con00, 0x280);
+check_member(rk3588_cru, pmuclksel_con[1], 0x30304);
+
+struct pll_rate_table {
+   unsigned long rate;
+   unsigned int m;
+   unsigned int p;
+   unsigned int s;
+   unsigned int k;
+};
+
+#define RK3588_PLL_CON(x)  ((x) * 0x4)
+#define RK3588_MODE_CON0x280
+
+#define RK3588_PHP_CRU_BASE0x8000
+#define RK3588_PMU_CRU_BASE0x3
+#define RK3588_BIGCORE0_CRU_BASE   0x5
+#define RK3588_BIGCORE1_CRU_BASE   0x52000
+#define RK3588_DSU_CRU_BASE0x58000
+
+#define RK3588_PLL_CON(x)  ((x) * 0x4)
+#define RK3588_MODE_CON0   0x280
+#define RK3588_CLKSEL_CON(x)   ((x) * 0x4 + 0x300)
+#define RK3588_CLKGATE_CON(x)  ((x) * 0x4 + 0x800)
+#define RK3588_SOFTRST_CON(x)  ((x) * 0x4 + 0xa00)
+#define RK3588_GLB_CNT_TH  0xc00
+#define RK3588_GLB_SRST_FST0xc08
+#define RK3588_GLB_SRST_SND0xc0c
+#define RK3588_GLB_RST_CON 0xc10
+#define RK3588_GLB_RST_ST  0xc04
+#define RK3588_SDIO_CON0   0xC24
+#define RK3588_SDIO_CON1   0xC28
+#define RK3588_SDMMC_CON0  0xC30
+#define RK3588_SDMMC_CON1  0xC34
+
+#define RK3588_PHP_CLKGATE_CON(x)  ((x) * 0x4 + RK3588_PHP_CRU_BASE + 
0x800)
+#define RK3588_PHP_SOFTRST_CON(x)  ((x) * 0x4 + RK3588_PHP_CRU_BASE + 
0xa00)
+
+#define RK3588_PMU_PLL_CON(x)  ((x) * 0x4 + RK3588_PHP_CRU_BASE)
+#define RK3588_PMU_CLKSEL_

[RFC PATCH 01/16] rockchip: mkimage: Add rk3588 support

2023-01-25 Thread Jagan Teki
Add support for rk3588 package header in mkimage tool.

Signed-off-by: Jagan Teki 
---
 tools/rkcommon.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/rkcommon.c b/tools/rkcommon.c
index 1f1eaa1675..2e22a1bf8a 100644
--- a/tools/rkcommon.c
+++ b/tools/rkcommon.c
@@ -135,6 +135,7 @@ static struct spl_info spl_infos[] = {
{ "rv1108", "RK11", 0x1800, false, RK_HEADER_V1 },
{ "rv1126", "110B", 0x1 - 0x1000, false, RK_HEADER_V1 },
{ "rk3568", "RK35", 0x14000 - 0x1000, false, RK_HEADER_V2 },
+   { "rk3588", "RK35", 0x10 - 0x1000, false, RK_HEADER_V2 },
 };
 
 /**
-- 
2.25.1



[RFC PATCH 00/16] arm: Add Rockchip RK3588 support

2023-01-25 Thread Jagan Teki
This series support Rockchip RK3588. All the device tree files are
synced from linux-next with the proper SHA1 mentioned in the commit
messages.

Unfortunately, the BL31 from rkbin is not compatible with U-Boot so
it is failing to load ATF entry from SPL and hang. 

Verified below BL31 versions,
  bl31-v1.15
  bl31-v1.21
  bl31-v1.22
  bl31-v1.23
  bl31-v1.24
  bl31-v1.25
  bl31-v1.26

Rever-engineered with respect to rockchip u-boot by using the same
FIT_GENERATOR being used in Mainline, rockchip u-boot is booting but
mainline showing the same issue.

Log:

LPDDR4X, 2112MHz01-00642-g6bdfd31756-dirty (Jan 26 2023 ���3:44:34 +0530)
channel[0] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB
channel[1] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB
channel[2] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB
channel[3] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB
change to F1: 528MHz
change to F2: 1068MHz
change to F3: 1560MHz
change to F0: 2112MHz
out

U-Boot SPL 2023.01-00642-g6bdfd31756-dirty (Jan 26 2023 - 03:44:34 +0530)
Trying to boot from MMC1
bl31_entry: atf_entry start
<< hang >>

Any information on BL31 for RK3588 please share.

Any inputs?
Jagan.

Jagan Teki (16):
  rockchip: mkimage: Add rk3588 support
  arm: rockchip: Add cru header for rk3588
  arm: rockchip: Add grf header for rk3588
  dt-bindings: clk: Add dt-binding header for RK3588
  clk: rockchip: Add rk3588 clk support
  clk: rockchip: pll: Add pll_rk3588 type for rk3588
  ram: rockchip: Add rk3588 ddr driver support
  dt-bindings: power: Add power-domain header for rk3588
  dt-bindings: reset: add rk3588 reset definitions
  arm: rockchip: Add ioc header for rk3588
  arm64: dts: rockchip: Add base DT for rk3588 SoC
  arm64: dts: rockchip: rk3588: Add Edgeble Neu6 Model A SoM
  arm64: dts: rockchip: rk3588: Add Edgeble Neu6 Model A IO
  arm: rockchip: Add RK3588 arch core support
  ARM: dts: rockchip: Add rk3588-u-boot.dtsi
  board: rockchip: Add Edgeble Neural Compute Module 6

 arch/arm/dts/Makefile |3 +
 .../dts/rk3588-edgeble-neu6a-io-u-boot.dtsi   |   23 +
 arch/arm/dts/rk3588-edgeble-neu6a-io.dts  |   27 +
 arch/arm/dts/rk3588-edgeble-neu6a.dtsi|   32 +
 arch/arm/dts/rk3588-pinctrl.dtsi  |  516 +++
 arch/arm/dts/rk3588-u-boot.dtsi   |  101 +
 arch/arm/dts/rk3588.dtsi  |   58 +
 arch/arm/dts/rk3588s-pinctrl.dtsi | 3403 +
 arch/arm/dts/rk3588s.dtsi | 1703 +
 arch/arm/include/asm/arch-rk3588/boot0.h  |   11 +
 arch/arm/include/asm/arch-rk3588/gpio.h   |   11 +
 arch/arm/include/asm/arch-rockchip/clock.h|   24 +
 .../include/asm/arch-rockchip/cru_rk3588.h|  451 +++
 .../include/asm/arch-rockchip/grf_rk3588.h|   35 +
 .../include/asm/arch-rockchip/ioc_rk3588.h|  102 +
 arch/arm/mach-rockchip/Kconfig|   20 +
 arch/arm/mach-rockchip/Makefile   |1 +
 arch/arm/mach-rockchip/rk3588/Kconfig |   30 +
 arch/arm/mach-rockchip/rk3588/Makefile|9 +
 arch/arm/mach-rockchip/rk3588/clk_rk3588.c|   33 +
 arch/arm/mach-rockchip/rk3588/rk3588.c|  162 +
 arch/arm/mach-rockchip/rk3588/syscon_rk3588.c |   32 +
 board/edgeble/neural-compute-module-6/Kconfig |   15 +
 .../neural-compute-module-6/MAINTAINERS   |6 +
 .../edgeble/neural-compute-module-6/Makefile  |7 +
 board/edgeble/neural-compute-module-6/neu6.c  |4 +
 configs/neu6a-io-rk3588_defconfig |   68 +
 doc/board/rockchip/rockchip.rst   |2 +
 drivers/clk/rockchip/Makefile |1 +
 drivers/clk/rockchip/clk_pll.c|  267 +-
 drivers/clk/rockchip/clk_rk3588.c | 2019 ++
 drivers/ram/rockchip/Makefile |1 +
 drivers/ram/rockchip/sdram_rk3588.c   |   56 +
 include/configs/neural-compute-module-6.h |   15 +
 include/configs/rk3588_common.h   |   32 +
 .../dt-bindings/clock/rockchip,rk3588-cru.h   |  766 
 include/dt-bindings/power/rk3588-power.h  |   69 +
 .../dt-bindings/reset/rockchip,rk3588-cru.h   |  754 
 tools/rkcommon.c  |1 +
 39 files changed, 10867 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/dts/rk3588-edgeble-neu6a-io-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3588-edgeble-neu6a-io.dts
 create mode 100644 arch/arm/dts/rk3588-edgeble-neu6a.dtsi
 create mode 100644 arch/arm/dts/rk3588-pinctrl.dtsi
 create mode 100644 arch/arm/dts/rk3588-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3588.dtsi
 create mode 100644 arch/arm/dts/rk3588s-pinctrl.dtsi
 create mode 100644 arch/arm/dts/rk3588s.dtsi
 create mode 100644 arch/arm/include/asm/arch-rk3588/boot0.h
 create mode 100644 arch/arm/include/asm/arch-rk3588/gpio.h
 create mode 100644 arch/arm/include/asm/arch-rockchip/cru_rk3588.h
 create mode 100644 arch/arm/inclu

Re: [PATCH v4] mtd: parsers: ofpart: add workaround for #size-cells 0

2023-01-25 Thread Francesco Dolcini
Hello Miquel, Greg and all

On Tue, Jan 24, 2023 at 04:38:59PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 24, 2023 at 11:44:44AM +0100, Francesco Dolcini wrote:
> > From: Francesco Dolcini 
> > 
> > Add a mechanism to handle the case in which partitions are present as
> > direct child of the nand controller node and #size-cells is set to <0>.
> > 
> > This could happen if the nand-controller node in the DTS is supposed to
> > have #size-cells set to 0, but for some historical reason/bug it was set
> > to 1 in the past, and the firmware (e.g. U-Boot) is adding the partition
> > as direct children of the nand-controller defaulting to #size-cells
> > being to 1.
> > 
> > This prevents a real boot failure on colibri-imx7 that happened during v6.1
> > development cycles.
> > 
> > Link: 
> > https://lore.kernel.org/all/y4dgbtgnwpm6s...@francesco-nb.int.toradex.com/
> > Link: 
> > https://lore.kernel.org/all/20221202071900.1143950-1-france...@dolcini.it/
> > Signed-off-by: Francesco Dolcini 
> > Reviewed-by: Greg Kroah-Hartman 
> > ---
> > I do not expect this patch to be backported to stable, however I would 
> > expect
> > that we do not backport nand-controller dts cleanups neither.
> > 
> > v4:
> >  fixed wrong English spelling in the comment
> > 
> > v3:
> >  minor formatting change, removed not needed new-line and space. 
> > 
> > v2:
> >  fixup size-cells only when partitions are direct children of the 
> > nand-controller
> >  completely revised commit message, comments and warning print
> >  use pr_warn instead of pr_warn_once
> >  added Reviewed-by Greg
> >  removed cc:stable@ and fixes tag, since the problematic commit was reverted
> > ---
> >  drivers/mtd/parsers/ofpart_core.c | 19 +++
> >  1 file changed, 19 insertions(+)
> > 
> > diff --git a/drivers/mtd/parsers/ofpart_core.c 
> > b/drivers/mtd/parsers/ofpart_core.c
> > index 192190c42fc8..e7b8e9d0a910 100644
> > --- a/drivers/mtd/parsers/ofpart_core.c
> > +++ b/drivers/mtd/parsers/ofpart_core.c
> > @@ -122,6 +122,25 @@ static int parse_fixed_partitions(struct mtd_info 
> > *master,
> >  
> > a_cells = of_n_addr_cells(pp);
> > s_cells = of_n_size_cells(pp);
> > +   if (!dedicated && s_cells == 0) {
> > +   /*
> > +* This is a ugly workaround to not create
> > +* regression on devices that are still creating
> > +* partitions as direct children of the nand controller.
> > +* This can happen in case the nand controller node has
> > +* #size-cells equal to 0 and the firmware (e.g.
> > +* U-Boot) just add the partitions there assuming
> > +* 32-bit addressing.
> > +*
> > +* If you get this warning your firmware and/or DTS
> > +* should be really fixed.
> > +*
> > +* This is working only for devices smaller than 4GiB.
> > +*/
> > +   pr_warn("%s: ofpart partition %pOF (%pOF) #size-cells 
> > is wrongly set to <0>, assuming <1> for parsing partitions.\n",
> > +   master->name, pp, mtd_node);
> 
> This is a driver, always use dev_*() calls, not pr_*() calls so that we
> know what is being referred to exactly.

Is this reasonable here? Where can I get the struct device?

In general this file uses only pr_* debug API and messages are about OF
nodes/properties, not about a device.

> I take back my "reviewed-by" line above, please fix this up to not need
> pr_warn, but to use dev_warn() instead.

Francesco


[PATCH 1/1] README: remove 'U-Boot Porting Guide' section

2023-01-25 Thread Heinrich Schuchardt
This section does not match the standards of our documentation.

Signed-off-by: Heinrich Schuchardt 
---
 README | 74 --
 1 file changed, 74 deletions(-)

diff --git a/README b/README
index 8b395356dc..edce7890c0 100644
--- a/README
+++ b/README
@@ -2690,80 +2690,6 @@ running from ROM, and because the code will have to be 
relocated to a
 new address in RAM.
 
 
-U-Boot Porting Guide:
---
-
-[Based on messages by Jerry Van Baren in the U-Boot-Users mailing
-list, October 2002]
-
-
-int main(int argc, char *argv[])
-{
-   sighandler_t no_more_time;
-
-   signal(SIGALRM, no_more_time);
-   alarm(PROJECT_DEADLINE - toSec (3 * WEEK));
-
-   if (available_money > available_manpower) {
-   Pay consultant to port U-Boot;
-   return 0;
-   }
-
-   Download latest U-Boot source;
-
-   Subscribe to u-boot mailing list;
-
-   if (clueless)
-   email("Hi, I am new to U-Boot, how do I get started?");
-
-   while (learning) {
-   Read the README file in the top level directory;
-   Read https://www.denx.de/wiki/bin/view/DULG/Manual;
-   Read applicable doc/README.*;
-   Read the source, Luke;
-   /* find . -name "*.[chS]" | xargs grep -i  */
-   }
-
-   if (available_money > toLocalCurrency ($2500))
-   Buy a BDI3000;
-   else
-   Add a lot of aggravation and time;
-
-   if (a similar board exists) {   /* hopefully... */
-   cp -a board/ board/
-   cp include/configs/.h include/configs/.h
-   } else {
-   Create your own board support subdirectory;
-   Create your own board include/configs/.h file;
-   }
-   Edit new board/ files
-   Edit new include/configs/.h
-
-   while (!accepted) {
-   while (!running) {
-   do {
-   Add / modify source code;
-   } until (compiles);
-   Debug;
-   if (clueless)
-   email("Hi, I am having problems...");
-   }
-   Send patch file to the U-Boot email list;
-   if (reasonable critiques)
-   Incorporate improvements from email list code review;
-   else
-   Defend code as written;
-   }
-
-   return 0;
-}
-
-void no_more_time (int sig)
-{
-  hire_a_guru();
-}
-
-
 Contributing
 
 
-- 
2.38.1



Re: [PATCH] ARM: imx: Fix parsing of ROM log event IDs on iMX8M

2023-01-25 Thread Fedor Ross
Hello Stefano,

do you know why this is in the state 'Superseded' ?

Thanks in advance.

Best regards,
Fedor

On Fri, May 6, 2022 at 5:17 PM Fedor Ross  wrote:
>
> Hello Peng,
>
> just a gentle ping -- did you already had a chance to check the mentioned
> parameter of event 0x82?
>
> Thanks in advance.
>
> Best regards,
> Fedor
>
> On Thu, Apr 14, 2022 at 8:00 PM Fedor Ross  wrote:
> >
> > Hello Peng,
> >
> > can you please check the parameter of event 0x82 internally? The AN12853
> > doesn't mention a parameter for ID 0x82, but we see something else coming
> > out of the bootrom of iMX8MN.
> >
> > Best regards,
> > Fedor


Re: [PATCH v4 6/6] doc: Add measured boot documentation

2023-01-25 Thread Heinrich Schuchardt

On 1/25/23 18:18, Eddie James wrote:

Briefly describe the feature and specify the requirements.

Signed-off-by: Eddie James 
---
  doc/usage/index.rst |  1 +
  doc/usage/measured_boot.rst | 23 +++
  2 files changed, 24 insertions(+)
  create mode 100644 doc/usage/measured_boot.rst

diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index 7d4a1cbc10..c3efdf61df 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -12,6 +12,7 @@ Use U-Boot
 partitions
 cmdline
 semihosting
+   measured_boot

  Shell commands
  --
diff --git a/doc/usage/measured_boot.rst b/doc/usage/measured_boot.rst
new file mode 100644
index 00..13fd42a2fb
--- /dev/null
+++ b/doc/usage/measured_boot.rst
@@ -0,0 +1,23 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Measured Boot
+=
+
+U-Boot can perform a measured boot, the process of hashing various components
+of the boot process, extending the results in the TPM and logging the
+component's measurement in memory for the operating system to consume.
+
+Requirements
+-
+
+A hardware TPM 2.0 supported by the U-Boot drivers
+CONFIG_TPM=y
+CONFIG_MEASURED_BOOT=y


I guess this should be a bullet list instead of unformatted text.

https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#lists-and-quote-like-blocks
shows how to create a bullet list.

Please, use 'make htmldocs' to check the output. See
https://u-boot.readthedocs.io/en/latest/build/documentation.html
for setting up a build environment.

Best regards

Heinrich


+Device-tree configuration of the TPM device to specify the memory area
+for event logging. The TPM device node must either contain a phandle to
+a reserved memory region or "linux,sml-base" and "linux,sml-size"
+indicating the address and size of the memory region. An example can be
+found in arch/sandbox/dts/test.dts
+The operating system must also be configured to use the memory regions
+specified in the U-Boot device-tree in order to make use of the event
+log.




[PATCH v2 2/2] usb: move CONFIG_USB_HUB_DEBOUNCE_TIMEOUT to USB

2023-01-25 Thread Heinrich Schuchardt
This configuration setting is only relevant if the board supports USB.
It should not be in the main menu but in the USB menu.

The setting is only relevant in USB host mode.

Fixes: 5454dea3137d ("usb: hub: allow to increase HUB_DEBOUNCE_TIMEOUT")
Signed-off-by: Heinrich Schuchardt 
---
v2:
let CONFIG_USB_HUB_DEBOUNCE_TIMEOUT depend on CONFIG_USB_HOST
---
 common/Kconfig  | 12 
 drivers/usb/Kconfig | 11 +++
 2 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/common/Kconfig b/common/Kconfig
index e3a5e1be1e..0afc01b759 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -1106,15 +1106,3 @@ config FDT_SIMPLEFB
 
 config IO_TRACE
bool
-
-config USB_HUB_DEBOUNCE_TIMEOUT
-   int "Timeout in milliseconds for USB HUB connection"
-   depends on USB
-   default 1000
-   help
- Value in milliseconds of the USB connection timeout, the max delay to
- wait the hub port status to be connected steadily after being powered
- off and powered on in the usb hub driver.
- This define allows to increase the HUB_DEBOUNCE_TIMEOUT default
- value = 1s because some usb device needs around 1.5s to be initialized
- and a 2s value should solve detection issue on problematic USB keys.
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index ebe6bf9498..94fb32d107 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -115,6 +115,17 @@ config USB_ONBOARD_HUB
  power regulator. An example for such a hub is the Microchip
  USB2514B.
 
+config USB_HUB_DEBOUNCE_TIMEOUT
+   int "Timeout in milliseconds for USB HUB connection"
+   default 1000
+   help
+ Value in milliseconds of the USB connection timeout, the max delay to
+ wait the hub port status to be connected steadily after being powered
+ off and powered on in the usb hub driver.
+ This define allows to increase the HUB_DEBOUNCE_TIMEOUT default
+ value = 1s because some usb device needs around 1.5s to be initialized
+ and a 2s value should solve detection issue on problematic USB keys.
+
 if USB_KEYBOARD
 
 config USB_KEYBOARD_FN_KEYS
-- 
2.38.1



[PATCH v2 1/2] usb: USB hubs require host mode

2023-01-25 Thread Heinrich Schuchardt
USB hubs run in host mode not in gadget mode. Hence, compiling usb_hub.c
should not be selected by CONFIG_USB_GADGET.

Suggested-by: Marek Vasut 
Signed-off-by: Heinrich Schuchardt 
---
v2:
new patch
---
 common/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/Makefile b/common/Makefile
index 252e9656df..a50302d8b5 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -24,7 +24,7 @@ obj-$(CONFIG_CMD_MII) += miiphyutil.o
 obj-$(CONFIG_PHYLIB) += miiphyutil.o
 
 obj-$(CONFIG_USB_HOST) += usb.o usb_hub.o
-obj-$(CONFIG_USB_GADGET) += usb.o usb_hub.o
+obj-$(CONFIG_USB_GADGET) += usb.o
 obj-$(CONFIG_USB_STORAGE) += usb_storage.o
 obj-$(CONFIG_USB_ONBOARD_HUB) += usb_onboard_hub.o
 
-- 
2.38.1



[PATCH v2 0/2] usb: USB hubs require host mode

2023-01-25 Thread Heinrich Schuchardt
USB hub code and settings are only relevant in host mode not in
gadget mode.

v2:
don't compile usb_hub.o without host mode
let CONFIG_USB_HUB_DEBOUNCE_TIMEOUT depend on CONFIG_USB_HOST

Heinrich Schuchardt (2):
  usb: USB hubs require host mode
  usb: move CONFIG_USB_HUB_DEBOUNCE_TIMEOUT to USB

 common/Kconfig  | 12 
 common/Makefile |  2 +-
 drivers/usb/Kconfig | 11 +++
 3 files changed, 12 insertions(+), 13 deletions(-)

-- 
2.38.1



[PATCH 5/7] doc: move 'Reproducible builds'

2023-01-25 Thread Heinrich Schuchardt
Move the README section to the HTML documentation.

Signed-off-by: Heinrich Schuchardt 
---
 README | 11 ---
 doc/build/index.rst|  1 +
 doc/build/reproducible.rst | 25 +
 3 files changed, 26 insertions(+), 11 deletions(-)
 create mode 100644 doc/build/reproducible.rst

diff --git a/README b/README
index a969fc7a97..48db535556 100644
--- a/README
+++ b/README
@@ -1713,17 +1713,6 @@ This firmware often needs to be loaded during U-Boot 
booting.
 - CONFIG_SYS_MC_RSV_MEM_ALIGN
Define alignment of reserved memory MC requires
 
-Reproducible builds

-
-In order to achieve reproducible builds, timestamps used in the U-Boot build
-process have to be set to a fixed value.
-
-This is done using the SOURCE_DATE_EPOCH environment variable.
-SOURCE_DATE_EPOCH is to be set on the build host's shell, not as a 
configuration
-option for U-Boot or an environment variable in U-Boot.
-
-SOURCE_DATE_EPOCH should be set to a number of seconds since the epoch, in UTC.
 
 Building the Software:
 ==
diff --git a/doc/build/index.rst b/doc/build/index.rst
index dc9cde4001..64e66491bd 100644
--- a/doc/build/index.rst
+++ b/doc/build/index.rst
@@ -9,6 +9,7 @@ Build U-Boot
source
gcc
clang
+   reproducible
docker
tools
buildman
diff --git a/doc/build/reproducible.rst b/doc/build/reproducible.rst
new file mode 100644
index 00..5423080633
--- /dev/null
+++ b/doc/build/reproducible.rst
@@ -0,0 +1,25 @@
+Reproducible builds
+===
+
+In order to achieve reproducible builds, timestamps used in the U-Boot build
+process have to be set to a fixed value.
+
+This is done using the SOURCE_DATE_EPOCH environment variable which specifies
+the number of seconds since 1970-01-01T00:00:00Z.
+
+Example
+---
+
+To build the sandbox with 2023-01-01T00:00:00Z as timestamp we can use:
+
+.. code-block:: bash
+
+make sandbox_defconfig
+SOURCE_DATE_EPOCH=1672531200 make
+
+This date is shown when we launch U-Boot:
+
+.. code-block:: console
+
+./u-boot -T
+U-Boot 2023.01 (Jan 01 2023 - 00:00:00 +)
-- 
2.38.1



[PATCH 7/7] doc: move directory hierarchy to HTML

2023-01-25 Thread Heinrich Schuchardt
Move section 'Directory hierarchy' from file README to the HTML
documentation.

Signed-off-by: Heinrich Schuchardt 
---
 README  | 38 ---
 doc/develop/directories.rst | 76 +
 doc/develop/index.rst   |  1 +
 3 files changed, 77 insertions(+), 38 deletions(-)
 create mode 100644 doc/develop/directories.rst

diff --git a/README b/README
index 5437a1bdc2..8b395356dc 100644
--- a/README
+++ b/README
@@ -105,44 +105,6 @@ the string "u_boot" or on "U_BOOT". Example:
IH_OS_U_BOOTu_boot_hush_start
 
 
-Directory Hierarchy:
-
-
-/arch  Architecture-specific files
-  /arc Files generic to ARC architecture
-  /arm Files generic to ARM architecture
-  /m68kFiles generic to m68k architecture
-  /microblaze  Files generic to microblaze architecture
-  /mipsFiles generic to MIPS architecture
-  /nios2   Files generic to Altera NIOS2 architecture
-  /powerpc Files generic to PowerPC architecture
-  /riscv   Files generic to RISC-V architecture
-  /sandbox Files generic to HW-independent "sandbox"
-  /sh  Files generic to SH architecture
-  /x86 Files generic to x86 architecture
-  /xtensa  Files generic to Xtensa architecture
-/api   Machine/arch-independent API for external apps
-/board Board-dependent files
-/boot  Support for images and booting
-/cmd   U-Boot commands functions
-/commonMisc architecture-independent functions
-/configs   Board default configuration files
-/disk  Code for disk drive partition handling
-/doc   Documentation (a mix of ReST and READMEs)
-/drivers   Device drivers
-/dts   Makefile for building internal U-Boot fdt.
-/env   Environment support
-/examples  Example code for standalone applications, etc.
-/fsFilesystem code (cramfs, ext2, jffs2, etc.)
-/include   Header Files
-/lib   Library routines generic to all architectures
-/Licenses  Various license files
-/net   Networking code
-/post  Power On Self Test
-/scripts   Various build scripts and Makefiles
-/test  Various unit test files
-/tools Tools to build and sign FIT images, etc.
-
 Software Configuration:
 ===
 
diff --git a/doc/develop/directories.rst b/doc/develop/directories.rst
new file mode 100644
index 00..112b5655f6
--- /dev/null
+++ b/doc/develop/directories.rst
@@ -0,0 +1,76 @@
+Directory hierarchy
+===
+
+.. list-table::
+   :header-rows: 1
+
+   * - Directory path
+ - Usage
+   * - /arch
+ - Architecture-specific files
+   * - /arch/arc
+ - Files relating to ARC architecture
+   * - /arch/arm
+ - Files relating to ARM architecture
+   * - /arch/m68k
+ - Files relating to m68k architecture
+   * - /arch/microblaze
+ - Files relating to microblaze architecture
+   * - /arch/mips
+ - Files relating to MIPS architecture
+   * - /arch/nios2
+ - Files relating to Altera NIOS2 architecture
+   * - /arch/powerpc
+ - Files relating to PowerPC architecture
+   * - /arch/riscv
+ - Files relating to RISC-V architecture
+   * - /arch/sandbox
+ - Files relating to HW-independent "sandbox"
+   * - /arch/sh
+ - Files relating to SH architecture
+   * - /arch/x86
+ - Files relating to x86 architecture
+   * - /arch/xtensa
+ - Files relating to Xtensa architecture
+   * - /api
+ - Machine/arch-independent API for external apps
+   * - /board
+ - Board-dependent files
+   * - /boot
+ - Support for images and booting
+   * - /cmd
+ - U-Boot commands functions
+   * - /common
+ - Misc architecture-independent functions
+   * - /configs
+ - Board default configuration files
+   * - /disk
+ - Code for disk drive partition handling
+   * - /doc
+ - Documentation (a mix of ReST and READMEs)
+   * - /drivers
+ - Device drivers
+   * - /dts
+ - Makefile for building internal U-Boot fdt.
+   * - /env
+ - Environment support
+   * - /examples
+ - Example code for standalone applications, etc.
+   * - /fs
+ - Filesystem code (cramfs, ext2, jffs2, etc.)
+   * - /include
+ - Header Files
+   * - /lib
+ - Library routines relating to all architectures
+   * - /Licenses
+ - Various license files
+   * - /net
+ - Networking code
+   * - /post
+ - Power On Self Test
+   * - /scripts
+ - Various build scripts and Makefiles
+   * - /test
+ - Various unit test files
+   * - /tools
+ - Tools to build and sign FIT images, etc.
diff --git a/doc/develop/index.rst b

[PATCH 6/7] README: remove section 'Versioning'

2023-01-25 Thread Heinrich Schuchardt
The information is already maintained in doc/develop/release_cycle.rst.

Signed-off-by: Heinrich Schuchardt 
---
 README | 16 
 1 file changed, 16 deletions(-)

diff --git a/README b/README
index 48db535556..5437a1bdc2 100644
--- a/README
+++ b/README
@@ -105,22 +105,6 @@ the string "u_boot" or on "U_BOOT". Example:
IH_OS_U_BOOTu_boot_hush_start
 
 
-Versioning:
-===
-
-Starting with the release in October 2008, the names of the releases
-were changed from numerical release numbers without deeper meaning
-into a time stamp based numbering. Regular releases are identified by
-names consisting of the calendar year and month of the release date.
-Additional fields (if present) indicate release candidates or bug fix
-releases in "stable" maintenance trees.
-
-Examples:
-   U-Boot v2009.11 - Release November 2009
-   U-Boot v2009.11.1   - Release 1 in version November 2009 stable tree
-   U-Boot v2010.09-rc1 - Release candidate 1 for September 2010 release
-
-
 Directory Hierarchy:
 
 
-- 
2.38.1



[PATCH 4/7] README: replace references to CHANGELOG

2023-01-25 Thread Heinrich Schuchardt
Board configurations are in configs/ and not in the Makefile.

git log is the adequate way to identify who contributed to our source.
scripts/get_maintainer.pl is the correct way to identify maintainers.

Signed-off-by: Heinrich Schuchardt 
---
 README | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/README b/README
index b4bfe39f81..a969fc7a97 100644
--- a/README
+++ b/README
@@ -28,20 +28,16 @@ load and run it dynamically.
 Status:
 ===
 
-In general, all boards for which a configuration option exists in the
-Makefile have been tested to some extent and can be considered
+In general, all boards for which a default configuration file exists in the
+configs/ directory have been tested to some extent and can be considered
 "working". In fact, many of them are used in production systems.
 
-In case of problems see the CHANGELOG file to find out who contributed
-the specific port. In addition, there are various MAINTAINERS files
-scattered throughout the U-Boot source identifying the people or
-companies responsible for various boards and subsystems.
+In case of problems you can use
 
-Note: As of August, 2010, there is no longer a CHANGELOG file in the
-actual U-Boot source tree; however, it can be created dynamically
-from the Git log using:
+ scripts/get_maintainer.pl 
 
-   make CHANGELOG
+to identify the people or companies responsible for various boards and
+subsystems. Or have a look at the git log.
 
 
 Where to get help:
-- 
2.38.1



[PATCH 2/7] README: rework contribution advices

2023-01-25 Thread Heinrich Schuchardt
Remove description of coding standards and patch submission process.
Link to the relevant HTML documentation instead.

Signed-off-by: Heinrich Schuchardt 
---
 README | 110 -
 1 file changed, 6 insertions(+), 104 deletions(-)

diff --git a/README b/README
index 24e91b9a1f..f5db75d913 100644
--- a/README
+++ b/README
@@ -2862,108 +2862,10 @@ void no_more_time (int sig)
 }
 
 
-Coding Standards:
--
-
-All contributions to U-Boot should conform to the Linux kernel
-coding style; see the kernel coding style guide at
-https://www.kernel.org/doc/html/latest/process/coding-style.html, and the
-script "scripts/Lindent" in your Linux kernel source directory.
-
-Source files originating from a different project (for example the
-MTD subsystem) are generally exempt from these guidelines and are not
-reformatted to ease subsequent migration to newer versions of those
-sources.
-
-Please note that U-Boot is implemented in C (and to some small parts in
-Assembler); no C++ is used, so please do not use C++ style comments (//)
-in your code.
-
-Please also stick to the following formatting rules:
-- remove any trailing white space
-- use TAB characters for indentation and vertical alignment, not spaces
-- make sure NOT to use DOS '\r\n' line feeds
-- do not add more than 2 consecutive empty lines to source files
-- do not add trailing empty lines to source files
-
-Submissions which do not conform to the standards may be returned
-with a request to reformat the changes.
-
-
-Submitting Patches:

-
-Since the number of patches for U-Boot is growing, we need to
-establish some rules. Submissions which do not conform to these rules
-may be rejected, even when they contain important and valuable stuff.
-
-Please see https://www.denx.de/wiki/U-Boot/Patches for details.
-
-Patches shall be sent to the u-boot mailing list ;
-see https://lists.denx.de/listinfo/u-boot
-
-When you send a patch, please include the following information with
-it:
-
-* For bug fixes: a description of the bug and how your patch fixes
-  this bug. Please try to include a way of demonstrating that the
-  patch actually fixes something.
-
-* For new features: a description of the feature and your
-  implementation.
-
-* For major contributions, add a MAINTAINERS file with your
-  information and associated file and directory references.
-
-* When you add support for a new board, don't forget to add a
-  maintainer e-mail address to the boards.cfg file, too.
-
-* If your patch adds new configuration options, don't forget to
-  document these in the README file.
-
-* The patch itself. If you are using git (which is *strongly*
-  recommended) you can easily generate the patch using the
-  "git format-patch". If you then use "git send-email" to send it to
-  the U-Boot mailing list, you will avoid most of the common problems
-  with some other mail clients.
-
-  If you cannot use git, use "diff -purN OLD NEW". If your version of
-  diff does not support these options, then get the latest version of
-  GNU diff.
-
-  The current directory when running this command shall be the parent
-  directory of the U-Boot source tree (i. e. please make sure that
-  your patch includes sufficient directory information for the
-  affected files).
-
-  We prefer patches as plain text. MIME attachments are discouraged,
-  and compressed attachments must not be used.
-
-* If one logical set of modifications affects or creates several
-  files, all these changes shall be submitted in a SINGLE patch file.
-
-* Changesets that contain different, unrelated modifications shall be
-  submitted as SEPARATE patches, one patch per changeset.
-
-
-Notes:
-
-* Before sending the patch, run the buildman script on your patched
-  source tree and make sure that no errors or warnings are reported
-  for any of the boards.
-
-* Keep your modifications to the necessary minimum: A patch
-  containing several unrelated changes or arbitrary reformats will be
-  returned with a request to re-formatting / split it.
-
-* If you modify existing code, make sure that your new code does not
-  add to the memory footprint of the code ;-) Small is beautiful!
-  When adding new features, these should compile conditionally only
-  (using #ifdef), and the resulting code with the new feature
-  disabled must not need more memory than the old code without your
-  modification.
+Contributing
+
 
-* Remember that there is a size limit of 100 kB per message on the
-  u-boot mailing list. Bigger patches will be moderated. If they are
-  reasonable and not too big, they will be acknowledged. But patches
-  bigger than the size limit should be avoided.
+The U-Boot projects depends on contributions from the user community.
+If you want to participate, please, have a look at the 'General'
+section of https://u-boot.readthedocs.io/en/latest/develop/index.html
+where we describe coding standards and the patch submissi

[PATCH 3/7] README: remove NetBSD section

2023-01-25 Thread Heinrich Schuchardt
The information in this section is outdated.

Signed-off-by: Heinrich Schuchardt 
---
 README | 29 -
 1 file changed, 29 deletions(-)

diff --git a/README b/README
index f5db75d913..b4bfe39f81 100644
--- a/README
+++ b/README
@@ -2526,35 +2526,6 @@ configuration to your "File transfer protocols" section:
Y  kermit  /usr/bin/kermit -i -l %l -r   NDY   N  N
 
 
-NetBSD Notes:
-=
-
-Starting at version 0.9.2, U-Boot supports NetBSD both as host
-(build U-Boot) and target system (boots NetBSD/mpc8xx).
-
-Building requires a cross environment; it is known to work on
-NetBSD/i386 with the cross-powerpc-netbsd-1.3 package (you will also
-need gmake since the Makefiles are not compatible with BSD make).
-Note that the cross-powerpc package does not install include files;
-attempting to build U-Boot will fail because  is
-missing.  This file has to be installed and patched manually:
-
-   # cd /usr/pkg/cross/powerpc-netbsd/include
-   # mkdir powerpc
-   # ln -s powerpc machine
-   # cp /usr/src/sys/arch/powerpc/include/ansi.h powerpc/ansi.h
-   # ${EDIT} powerpc/ansi.h## must remove __va_list, _BSD_VA_LIST
-
-Native builds *don't* work due to incompatibilities between native
-and U-Boot include files.
-
-Booting assumes that (the first part of) the image booted is a
-stage-2 loader which in turn loads and then invokes the kernel
-proper. Loader sources will eventually appear in the NetBSD source
-tree (probably in sys/arc/mpc8xx/stand/u-boot_stage2/); in the
-meantime, see ftp://ftp.denx.de/pub/u-boot/ppcboot_stage2.tar.gz
-
-
 Implementation Internals:
 =
 
-- 
2.38.1



[PATCH 1/7] README: correct path to sandbox.rst

2023-01-25 Thread Heinrich Schuchardt
sandbox.rst was moved.

Fixes: 2851cc94f301 ("dm: Add documentation for host command and 
implementation")
Signed-off-by: Heinrich Schuchardt 
---
 README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README b/README
index 40619ee40c..24e91b9a1f 100644
--- a/README
+++ b/README
@@ -189,7 +189,7 @@ board. This allows feature development which is not board- 
or architecture-
 specific to be undertaken on a native platform. The sandbox is also used to
 run some of U-Boot's tests.
 
-See doc/arch/sandbox.rst for more details.
+See doc/arch/sandbox/sandbox.rst for more details.
 
 
 Board Initialisation Flow:
-- 
2.38.1



[PATCH 0/7] README: start cleanup

2023-01-25 Thread Heinrich Schuchardt
Our main README file contains information that

* is outdated
* should be moved to the HTML documentation
* is redundant to existing HTML documenation

Let's start cleaning up.

Heinrich Schuchardt (7):
  README: correct path to sandbox.rst
  README: rework contribution advices
  README: remove NetBSD section
  README: replace references to CHANGELOG
  doc: move 'Reproducible builds'
  README: remove section 'Versioning'
  doc: move directory hierarchy to HTML

 README  | 222 +++-
 doc/build/index.rst |   1 +
 doc/build/reproducible.rst  |  25 
 doc/develop/directories.rst |  76 
 doc/develop/index.rst   |   1 +
 5 files changed, 116 insertions(+), 209 deletions(-)
 create mode 100644 doc/build/reproducible.rst
 create mode 100644 doc/develop/directories.rst

-- 
2.38.1



Re: [PATCH 1/1] usb: move CONFIG_USB_HUB_DEBOUNCE_TIMEOUT to USB

2023-01-25 Thread Marek Vasut

On 1/25/23 19:05, Heinrich Schuchardt wrote:

On 1/25/23 19:00, Marek Vasut wrote:

On 1/25/23 18:32, Heinrich Schuchardt wrote:

This configuration setting is only relevant if the board supports USB.
It should not be in the main menu but in the USB menu.

Fixes: 5454dea3137d ("usb: hub: allow to increase HUB_DEBOUNCE_TIMEOUT")
Signed-off-by: Heinrich Schuchardt 
---
  common/Kconfig  | 12 
  drivers/usb/Kconfig | 11 +++
  2 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/common/Kconfig b/common/Kconfig
index e3a5e1be1e..0afc01b759 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -1106,15 +1106,3 @@ config FDT_SIMPLEFB
  config IO_TRACE
  bool
-
-config USB_HUB_DEBOUNCE_TIMEOUT
-    int "Timeout in milliseconds for USB HUB connection"
-    depends on USB
-    default 1000
-    help
-  Value in milliseconds of the USB connection timeout, the max 
delay to
-  wait the hub port status to be connected steadily after being 
powered

-  off and powered on in the usb hub driver.
-  This define allows to increase the HUB_DEBOUNCE_TIMEOUT default
-  value = 1s because some usb device needs around 1.5s to be 
initialized
-  and a 2s value should solve detection issue on problematic USB 
keys.

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index ebe6bf9498..8b957793ff 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -53,6 +53,17 @@ config SPL_DM_USB
  default n if ARCH_MVEBU
  default y
+config USB_HUB_DEBOUNCE_TIMEOUT
+    int "Timeout in milliseconds for USB HUB connection"
+    default 1000
+    help
+  Value in milliseconds of the USB connection timeout, the max 
delay to
+  wait the hub port status to be connected steadily after being 
powered

+  off and powered on in the usb hub driver.
+  This define allows to increase the HUB_DEBOUNCE_TIMEOUT default
+  value = 1s because some usb device needs around 1.5s to be 
initialized
+  and a 2s value should solve detection issue on problematic USB 
keys.

+


Should this be in 'if USB_HOST' too , i.e. past 'config USB_ONBOARD_HUB'?


With CONFIG_USB_GADGET=y usb_hub.o is built, too.
CONFIG_USB_GADGET=y does not imply CONFIG_USB_HOST=y.

This is why I did not create such a dependency.


I think that's bogus, can you send a patch which drops the usb_hub.o 
from USB_GADGET in common/Makefile ?


Re: [PATCH 1/1] usb: move CONFIG_USB_HUB_DEBOUNCE_TIMEOUT to USB

2023-01-25 Thread Heinrich Schuchardt

On 1/25/23 19:00, Marek Vasut wrote:

On 1/25/23 18:32, Heinrich Schuchardt wrote:

This configuration setting is only relevant if the board supports USB.
It should not be in the main menu but in the USB menu.

Fixes: 5454dea3137d ("usb: hub: allow to increase HUB_DEBOUNCE_TIMEOUT")
Signed-off-by: Heinrich Schuchardt 
---
  common/Kconfig  | 12 
  drivers/usb/Kconfig | 11 +++
  2 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/common/Kconfig b/common/Kconfig
index e3a5e1be1e..0afc01b759 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -1106,15 +1106,3 @@ config FDT_SIMPLEFB
  config IO_TRACE
  bool
-
-config USB_HUB_DEBOUNCE_TIMEOUT
-    int "Timeout in milliseconds for USB HUB connection"
-    depends on USB
-    default 1000
-    help
-  Value in milliseconds of the USB connection timeout, the max 
delay to
-  wait the hub port status to be connected steadily after being 
powered

-  off and powered on in the usb hub driver.
-  This define allows to increase the HUB_DEBOUNCE_TIMEOUT default
-  value = 1s because some usb device needs around 1.5s to be 
initialized
-  and a 2s value should solve detection issue on problematic USB 
keys.

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index ebe6bf9498..8b957793ff 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -53,6 +53,17 @@ config SPL_DM_USB
  default n if ARCH_MVEBU
  default y
+config USB_HUB_DEBOUNCE_TIMEOUT
+    int "Timeout in milliseconds for USB HUB connection"
+    default 1000
+    help
+  Value in milliseconds of the USB connection timeout, the max 
delay to
+  wait the hub port status to be connected steadily after being 
powered

+  off and powered on in the usb hub driver.
+  This define allows to increase the HUB_DEBOUNCE_TIMEOUT default
+  value = 1s because some usb device needs around 1.5s to be 
initialized
+  and a 2s value should solve detection issue on problematic USB 
keys.

+


Should this be in 'if USB_HOST' too , i.e. past 'config USB_ONBOARD_HUB'?


With CONFIG_USB_GADGET=y usb_hub.o is built, too.
CONFIG_USB_GADGET=y does not imply CONFIG_USB_HOST=y.

This is why I did not create such a dependency.

Best regards

Heinrich




Re: [PATCH] imx: kontron-sl-mx8mm: Fix SD card IO voltage level

2023-01-25 Thread Marek Vasut

On 1/25/23 18:30, Frieder Schrempf wrote:

Hi Marek,


Hi,


On 25.01.23 18:15, Marek Vasut wrote:

On 1/25/23 14:41, Frieder Schrempf wrote:

From: Frieder Schrempf 


Subject tags should be ARM: dts: imx:


Ok, how do I know? Because "git log arch/arm/dts" shows me that
": :" is used quite often and it's what I used in the
past. But I'm happy to change it if "ARM: dts: imx:" is the way the
prefix should look like.


I just do what Linux does to keep things aligned.


The LDO5 of the PCA9450 PMIC can be switched between two different
voltage settings (defaulting to 1.8V and 3.3V) using an external
signal SD_VSEL that is connected to the VSELECT signal of the SD
card interface.

As the regulator driver can't deal with both LDO registers (LDO5CTRL_H
and LDO5CTRL_L) it only uses one of them, which means reading the
voltage from the regulator can potentially return a value that does not
reflect the actual state of the LDO5 output.


Can you fix the regulator driver ?


So far, I didn't see a way how to do it, but with your suggestion below
it might work.




In our case, after booting U-Boot we read 1.8V from the regulator
while in fact as the VSELECT signal is still low the regulator outputs
3.3V. This confusion causes the MMC driver to think it is dealing with
a 1.8V-only device. This in turn leads to SD cards being addressed
with 1.8V IO levels even if UHS support is not available or disabled.

Some cards with UHS support still work even if they are addressed
with 1.8V levels in non-UHS modes, but a lot of cards also fail with
timeout errors like:

    Card did not respond to voltage select! : -110

As a workaorund we disable the vqmmc regulator for now so we can make
sure no wrong values are read from the regulator. The switching
between 1.8V and 3.3V still works as the ESDHC driver sets the
VSELECT signal accordingly.

Signed-off-by: Frieder Schrempf 
---
By the way: I suspect that other boards using the PCA9450 might also
be affected
by this. I didn't find a nice generic solution so far. It would be
possible to
patch the pca9450 driver to use the PCA9450_LDO5CTRL_L instead of the
PCA9450_LDO5CTRL_H register for LDO5. This would fix this particular
case,
but still not the root problem of the regulator driver returning wrong
values.
So if anyone got some idea how to properly handle this, let me know.
The same issue is also present in Linux. While I didn't notice any
problems
with the SD card being addressed with incorrect voltage levels so far,
reading the regulator doesn't return the correct value if VSELECT is low.


Configure VSELECT pinmux such that it is a function, as it is right now,
MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT or similar, (so SD controller
driver can operate the pin via SD controller), but set SION bit so GPIO
controller can read its state (activate bit 30), i.e.:
MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0x4004

Use sd-vsel-gpios property of PMIC, claim the VSELECT as GPIO in PMIC
driver (this won't change pinmux, the pin would still be configured as
function, but SION bit would allow you to read its state), read its
state, and return the correct LDO5CTRL_H/LDO5CTRL_L value based on that.


Good idea, I will try that.



If this works, then:
     arm64: dts: imx8mp: Drop sd-vsel-gpios from *
Linux kernel patches should not be applied.


Yes, but we could also just revert this change once the fix suggested
above works and is in place. Until then the sd-vsel-gpios doesn't do
anything.


Please give it a go, let's see if that's the way to go.


Re: [PATCH 1/1] usb: move CONFIG_USB_HUB_DEBOUNCE_TIMEOUT to USB

2023-01-25 Thread Marek Vasut

On 1/25/23 18:32, Heinrich Schuchardt wrote:

This configuration setting is only relevant if the board supports USB.
It should not be in the main menu but in the USB menu.

Fixes: 5454dea3137d ("usb: hub: allow to increase HUB_DEBOUNCE_TIMEOUT")
Signed-off-by: Heinrich Schuchardt 
---
  common/Kconfig  | 12 
  drivers/usb/Kconfig | 11 +++
  2 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/common/Kconfig b/common/Kconfig
index e3a5e1be1e..0afc01b759 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -1106,15 +1106,3 @@ config FDT_SIMPLEFB
  
  config IO_TRACE

bool
-
-config USB_HUB_DEBOUNCE_TIMEOUT
-   int "Timeout in milliseconds for USB HUB connection"
-   depends on USB
-   default 1000
-   help
- Value in milliseconds of the USB connection timeout, the max delay to
- wait the hub port status to be connected steadily after being powered
- off and powered on in the usb hub driver.
- This define allows to increase the HUB_DEBOUNCE_TIMEOUT default
- value = 1s because some usb device needs around 1.5s to be initialized
- and a 2s value should solve detection issue on problematic USB keys.
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index ebe6bf9498..8b957793ff 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -53,6 +53,17 @@ config SPL_DM_USB
default n if ARCH_MVEBU
default y
  
+config USB_HUB_DEBOUNCE_TIMEOUT

+   int "Timeout in milliseconds for USB HUB connection"
+   default 1000
+   help
+ Value in milliseconds of the USB connection timeout, the max delay to
+ wait the hub port status to be connected steadily after being powered
+ off and powered on in the usb hub driver.
+ This define allows to increase the HUB_DEBOUNCE_TIMEOUT default
+ value = 1s because some usb device needs around 1.5s to be initialized
+ and a 2s value should solve detection issue on problematic USB keys.
+


Should this be in 'if USB_HOST' too , i.e. past 'config USB_ONBOARD_HUB'?


Re: [PATCH] bootstd: Replicate the dtb-filename quirks of distroboot

2023-01-25 Thread Tom Rini
On Wed, Jan 25, 2023 at 06:04:56PM +0100, Heinrich Schuchardt wrote:
> On 1/25/23 17:15, Tom Rini wrote:
> > On Wed, Jan 25, 2023 at 04:38:53PM +0100, Heinrich Schuchardt wrote:
> > > On 1/25/23 04:11, Simon Glass wrote:
> > > > For EFI, the distro boot scripts search in three different directories
> > > > for the .dtb file. The SOC-based filename fallback is supported only for
> > > > 32-bit ARM.
> > > > 
> > > > Adjust the code to mirror this behaviour.
> > > > 
> > > > Signed-off-by: Simon Glass 
> > > > Suggested-by: Mark Kettenis 
> > > > ---
> > > > 
> > > >boot/bootmeth_efi.c | 63 
> > > > ++---
> > > >1 file changed, 54 insertions(+), 9 deletions(-)
> > > > 
> > > > diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c
> > > > index 67c972e3fe4..f9544846e68 100644
> > > > --- a/boot/bootmeth_efi.c
> > > > +++ b/boot/bootmeth_efi.c
> > > > @@ -147,25 +147,57 @@ static int distro_efi_check(struct udevice *dev, 
> > > > struct bootflow_iter *iter)
> > > > return 0;
> > > >}
> > > > -static void distro_efi_get_fdt_name(char *fname, int size)
> > > > +/**
> > > > + * distro_efi_get_fdt_name() - Get the filename for reading the .dtb 
> > > > file
> > > > + *
> > > > + * @fname: Place to put filename
> > > > + * @size: Max size of filename
> > > > + * @seq: Sequence number, to cycle through options (0=first)
> > > > + * Returns: 0 on success, -ENOENT if the "fdtfile" env var does not 
> > > > exist,
> > > > + * -EINVAL if there are no more options
> > > > + */
> > > > +static int distro_efi_get_fdt_name(char *fname, int size, int seq)
> > > >{
> > > > const char *fdt_fname;
> > > > +   const char *prefix;
> > > > +
> > > > +   /* select the prefix */
> > > > +   switch (seq) {
> > > > +   case 0:
> > > > +   /* this is the default */
> > > > +   prefix = "/dtb";
> > > > +   break;
> > > > +   case 1:
> > > > +   prefix = "";
> > > > +   break;
> > > > +   case 2:
> > > > +   prefix = "/dtb/current";
> > > > +   break;
> > > > +   default:
> > > > +   return log_msg_ret("pref", -EINVAL);
> > > > +   }
> > > > fdt_fname = env_get("fdtfile");
> > > > if (fdt_fname) {
> > > > -   snprintf(fname, size, "dtb/%s", fdt_fname);
> > > > +   snprintf(fname, size, "%s/%s", prefix, fdt_fname);
> > > > log_debug("Using device tree: %s\n", fname);
> > > > -   } else {
> > > > +
> > > > +   /* Use this fallback only for 32-bit ARM */
> > > > +   } else if (IS_ENABLED(CONFIG_ARM) && !IS_ENABLED(CONFIG_ARM64)) 
> > > > {
> > > > const char *soc = env_get("soc");
> > > > const char *board = env_get("board");
> > > > const char *boardver = env_get("boardver");
> > > > /* cf the code in label_boot() which seems very complex 
> > > > */
> > > > -   snprintf(fname, size, "dtb/%s%s%s%s.dtb",
> > > > +   snprintf(fname, size, "%s/%s%s%s%s.dtb", prefix,
> > > >  soc ? soc : "", soc ? "-" : "", board ? board 
> > > > : "",
> > > >  boardver ? boardver : "");
> > > > log_debug("Using default device tree: %s\n", fname);
> > > > +   } else {
> > > > +   return log_msg_ret("env", -ENOENT);
> > > > }
> > > > +
> > > > +   return 0;
> > > >}
> > > >static int distro_efi_read_bootflow_file(struct udevice *dev,
> > > > @@ -174,7 +206,7 @@ static int distro_efi_read_bootflow_file(struct 
> > > > udevice *dev,
> > > > struct blk_desc *desc = NULL;
> > > > ulong fdt_addr, size;
> > > > char fname[256];
> > > > -   int ret;
> > > > +   int ret, seq;
> > > > /* We require a partition table */
> > > > if (!bflow->part)
> > > > @@ -196,13 +228,22 @@ static int distro_efi_read_bootflow_file(struct 
> > > > udevice *dev,
> > > > if (ret)
> > > > return log_msg_ret("read", -EINVAL);
> > > > -   distro_efi_get_fdt_name(fname, sizeof(fname));
> > > > +   fdt_addr = env_get_hex("fdt_addr_r", 0);
> > > > +
> > > > +   /* try the various available names */
> > > > +   ret = -ENOENT;
> > > > +   for (seq = 0; ret; seq++)
> > > 
> > > There are boards that don't have a dtb file available and that is ok. 
> > > Don't
> > > loop past seq = 2.
> > > 
> > > {
> > > > +   ret = distro_efi_get_fdt_name(fname, sizeof(fname), 
> > > > seq);
> > > > +   if (ret)
> > > > +   return log_msg_ret("nam", ret);
> > > > +   ret = bootmeth_common_read_file(dev, bflow, fname, 
> > > > fdt_addr,
> > > > +   &size);
> > > > +   }
> > > > +
> > > > bflow->fdt_fname = strdup(fname);
> > > > if (!bflow->fdt_fname)
> > > > 

[PATCH 1/1] usb: move CONFIG_USB_HUB_DEBOUNCE_TIMEOUT to USB

2023-01-25 Thread Heinrich Schuchardt
This configuration setting is only relevant if the board supports USB.
It should not be in the main menu but in the USB menu.

Fixes: 5454dea3137d ("usb: hub: allow to increase HUB_DEBOUNCE_TIMEOUT")
Signed-off-by: Heinrich Schuchardt 
---
 common/Kconfig  | 12 
 drivers/usb/Kconfig | 11 +++
 2 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/common/Kconfig b/common/Kconfig
index e3a5e1be1e..0afc01b759 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -1106,15 +1106,3 @@ config FDT_SIMPLEFB
 
 config IO_TRACE
bool
-
-config USB_HUB_DEBOUNCE_TIMEOUT
-   int "Timeout in milliseconds for USB HUB connection"
-   depends on USB
-   default 1000
-   help
- Value in milliseconds of the USB connection timeout, the max delay to
- wait the hub port status to be connected steadily after being powered
- off and powered on in the usb hub driver.
- This define allows to increase the HUB_DEBOUNCE_TIMEOUT default
- value = 1s because some usb device needs around 1.5s to be initialized
- and a 2s value should solve detection issue on problematic USB keys.
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index ebe6bf9498..8b957793ff 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -53,6 +53,17 @@ config SPL_DM_USB
default n if ARCH_MVEBU
default y
 
+config USB_HUB_DEBOUNCE_TIMEOUT
+   int "Timeout in milliseconds for USB HUB connection"
+   default 1000
+   help
+ Value in milliseconds of the USB connection timeout, the max delay to
+ wait the hub port status to be connected steadily after being powered
+ off and powered on in the usb hub driver.
+ This define allows to increase the HUB_DEBOUNCE_TIMEOUT default
+ value = 1s because some usb device needs around 1.5s to be initialized
+ and a 2s value should solve detection issue on problematic USB keys.
+
 config DM_USB_GADGET
bool "Enable driver model for USB Gadget"
depends on DM_USB
-- 
2.38.1



[PATCH 2/2] mmc: erase: Use TRIM erase when available

2023-01-25 Thread Loic Poulain
The default erase command applies on erase group unit, and
simply round down to erase group size. When the start block
is not aligned to erase group size (e.g. erasing partition)
it causes unwanted erasing of the previous blocks, part of
the same erase group (e.g. owned by other logical partition,
or by the partition table itself).

To prevent this issue, a simple solution is to use TRIM as
argument of the Erase command, which is usually supported
with eMMC > 4.0, and allow to apply erase operation to write
blocks instead of erase group

Signed-off-by: Loic Poulain 
---
 drivers/mmc/mmc_write.c | 34 +++---
 1 file changed, 23 insertions(+), 11 deletions(-)

diff --git a/drivers/mmc/mmc_write.c b/drivers/mmc/mmc_write.c
index 5b7aeeb012..a6f93380dd 100644
--- a/drivers/mmc/mmc_write.c
+++ b/drivers/mmc/mmc_write.c
@@ -15,7 +15,7 @@
 #include 
 #include "mmc_private.h"
 
-static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt)
+static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt, u32 
args)
 {
struct mmc_cmd cmd;
ulong end;
@@ -52,7 +52,7 @@ static ulong mmc_erase_t(struct mmc *mmc, ulong start, 
lbaint_t blkcnt)
goto err_out;
 
cmd.cmdidx = MMC_CMD_ERASE;
-   cmd.cmdarg = MMC_ERASE_ARG;
+   cmd.cmdarg = args ? args : MMC_ERASE_ARG;
cmd.resp_type = MMC_RSP_R1b;
 
err = mmc_send_cmd(mmc, &cmd, NULL);
@@ -77,7 +77,7 @@ ulong mmc_berase(struct blk_desc *block_dev, lbaint_t start, 
lbaint_t blkcnt)
 #endif
int dev_num = block_dev->devnum;
int err = 0;
-   u32 start_rem, blkcnt_rem;
+   u32 start_rem, blkcnt_rem, erase_args = 0;
struct mmc *mmc = find_mmc_device(dev_num);
lbaint_t blk = 0, blk_r = 0;
int timeout_ms = 1000;
@@ -97,13 +97,25 @@ ulong mmc_berase(struct blk_desc *block_dev, lbaint_t 
start, lbaint_t blkcnt)
 */
err = div_u64_rem(start, mmc->erase_grp_size, &start_rem);
err = div_u64_rem(blkcnt, mmc->erase_grp_size, &blkcnt_rem);
-   if (start_rem || blkcnt_rem)
-   printf("\n\nCaution! Your devices Erase group is 0x%x\n"
-  "The erase range would be change to "
-  "0x" LBAF "~0x" LBAF "\n\n",
-  mmc->erase_grp_size, start & ~(mmc->erase_grp_size - 1),
-  ((start + blkcnt + mmc->erase_grp_size - 1)
-  & ~(mmc->erase_grp_size - 1)) - 1);
+   if (start_rem || blkcnt_rem) {
+   if (mmc->can_trim) {
+   /* Trim function applies the erase operation to write
+* blocks instead of erase groups.
+*/
+   erase_args = MMC_TRIM_ARG;
+   } else {
+   /* The card ignores all LSB's below the erase group
+* size, rounding down the addess to a erase group
+* boundary.
+*/
+   printf("\n\nCaution! Your devices Erase group is 0x%x\n"
+  "The erase range would be change to "
+  "0x" LBAF "~0x" LBAF "\n\n",
+  mmc->erase_grp_size, start & 
~(mmc->erase_grp_size - 1),
+  ((start + blkcnt + mmc->erase_grp_size - 1)
+  & ~(mmc->erase_grp_size - 1)) - 1);
+   }
+   }
 
while (blk < blkcnt) {
if (IS_SD(mmc) && mmc->ssr.au) {
@@ -113,7 +125,7 @@ ulong mmc_berase(struct blk_desc *block_dev, lbaint_t 
start, lbaint_t blkcnt)
blk_r = ((blkcnt - blk) > mmc->erase_grp_size) ?
mmc->erase_grp_size : (blkcnt - blk);
}
-   err = mmc_erase_t(mmc, start + blk, blk_r);
+   err = mmc_erase_t(mmc, start + blk, blk_r, erase_args);
if (err)
break;
 
-- 
2.34.1



[PATCH 1/2] mmc: Check support for TRIM operations

2023-01-25 Thread Loic Poulain
When secure/insecure TRIM operations are supported.
When used as erase command argument it applies the
erase operation to write blocks instead of erase
groups.

Signed-off-by: Loic Poulain 
---
 drivers/mmc/mmc.c | 3 +++
 include/mmc.h | 4 
 2 files changed, 7 insertions(+)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 210703ea46..e5f5ccb5f4 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -2432,6 +2432,9 @@ static int mmc_startup_v4(struct mmc *mmc)
 
mmc->wr_rel_set = ext_csd[EXT_CSD_WR_REL_SET];
 
+   mmc->can_trim =
+   !!(ext_csd[EXT_CSD_SEC_FEATURE] & EXT_CSD_SEC_FEATURE_TRIM_EN);
+
return 0;
 error:
if (mmc->ext_csd) {
diff --git a/include/mmc.h b/include/mmc.h
index 571fa625d0..f6e23625ca 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -241,6 +241,7 @@ static inline bool mmc_is_tuning_cmd(uint cmdidx)
 #define EXT_CSD_HC_WP_GRP_SIZE 221 /* RO */
 #define EXT_CSD_HC_ERASE_GRP_SIZE  224 /* RO */
 #define EXT_CSD_BOOT_MULT  226 /* RO */
+#define EXT_CSD_SEC_FEATURE231 /* RO */
 #define EXT_CSD_GENERIC_CMD6_TIME   248 /* RO */
 #define EXT_CSD_BKOPS_SUPPORT  502 /* RO */
 
@@ -315,6 +316,8 @@ static inline bool mmc_is_tuning_cmd(uint cmdidx)
 #define EXT_CSD_WR_DATA_REL_USR(1 << 0)/* user data 
area WR_REL */
 #define EXT_CSD_WR_DATA_REL_GP(x)  (1 << ((x)+1))  /* GP part (x+1) WR_REL 
*/
 
+#define EXT_CSD_SEC_FEATURE_TRIM_EN(1 << 4) /* Support secure & insecure 
trim */
+
 #define R1_ILLEGAL_COMMAND (1 << 22)
 #define R1_APP_CMD (1 << 5)
 
@@ -687,6 +690,7 @@ struct mmc {
uint tran_speed;
uint legacy_speed; /* speed for the legacy mode provided by the card */
uint read_bl_len;
+   bool can_trim;
 #if CONFIG_IS_ENABLED(MMC_WRITE)
uint write_bl_len;
uint erase_grp_size;/* in 512-byte sectors */
-- 
2.34.1



Re: [PATCH] imx: kontron-sl-mx8mm: Fix SD card IO voltage level

2023-01-25 Thread Frieder Schrempf
Hi Marek,

On 25.01.23 18:15, Marek Vasut wrote:
> On 1/25/23 14:41, Frieder Schrempf wrote:
>> From: Frieder Schrempf 
> 
> Subject tags should be ARM: dts: imx:

Ok, how do I know? Because "git log arch/arm/dts" shows me that
": :" is used quite often and it's what I used in the
past. But I'm happy to change it if "ARM: dts: imx:" is the way the
prefix should look like.

> 
>> The LDO5 of the PCA9450 PMIC can be switched between two different
>> voltage settings (defaulting to 1.8V and 3.3V) using an external
>> signal SD_VSEL that is connected to the VSELECT signal of the SD
>> card interface.
>>
>> As the regulator driver can't deal with both LDO registers (LDO5CTRL_H
>> and LDO5CTRL_L) it only uses one of them, which means reading the
>> voltage from the regulator can potentially return a value that does not
>> reflect the actual state of the LDO5 output.
> 
> Can you fix the regulator driver ?

So far, I didn't see a way how to do it, but with your suggestion below
it might work.

> 
>> In our case, after booting U-Boot we read 1.8V from the regulator
>> while in fact as the VSELECT signal is still low the regulator outputs
>> 3.3V. This confusion causes the MMC driver to think it is dealing with
>> a 1.8V-only device. This in turn leads to SD cards being addressed
>> with 1.8V IO levels even if UHS support is not available or disabled.
>>
>> Some cards with UHS support still work even if they are addressed
>> with 1.8V levels in non-UHS modes, but a lot of cards also fail with
>> timeout errors like:
>>
>>    Card did not respond to voltage select! : -110
>>
>> As a workaorund we disable the vqmmc regulator for now so we can make
>> sure no wrong values are read from the regulator. The switching
>> between 1.8V and 3.3V still works as the ESDHC driver sets the
>> VSELECT signal accordingly.
>>
>> Signed-off-by: Frieder Schrempf 
>> ---
>> By the way: I suspect that other boards using the PCA9450 might also
>> be affected
>> by this. I didn't find a nice generic solution so far. It would be
>> possible to
>> patch the pca9450 driver to use the PCA9450_LDO5CTRL_L instead of the
>> PCA9450_LDO5CTRL_H register for LDO5. This would fix this particular
>> case,
>> but still not the root problem of the regulator driver returning wrong
>> values.
>> So if anyone got some idea how to properly handle this, let me know.
>> The same issue is also present in Linux. While I didn't notice any
>> problems
>> with the SD card being addressed with incorrect voltage levels so far,
>> reading the regulator doesn't return the correct value if VSELECT is low.
> 
> Configure VSELECT pinmux such that it is a function, as it is right now,
> MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT or similar, (so SD controller
> driver can operate the pin via SD controller), but set SION bit so GPIO
> controller can read its state (activate bit 30), i.e.:
> MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0x4004
> 
> Use sd-vsel-gpios property of PMIC, claim the VSELECT as GPIO in PMIC
> driver (this won't change pinmux, the pin would still be configured as
> function, but SION bit would allow you to read its state), read its
> state, and return the correct LDO5CTRL_H/LDO5CTRL_L value based on that.

Good idea, I will try that.

> 
> If this works, then:
>     arm64: dts: imx8mp: Drop sd-vsel-gpios from *
> Linux kernel patches should not be applied.

Yes, but we could also just revert this change once the fix suggested
above works and is in place. Until then the sd-vsel-gpios doesn't do
anything.

Thanks
Frieder


Re: [PATCH v9 0/8] Add MV88E6xxx DSA driver and use on gwventana

2023-01-25 Thread Tim Harvey
On Wed, Nov 30, 2022 at 4:26 PM Vladimir Oltean  wrote:
>
> On Wed, Nov 30, 2022 at 03:27:04PM -0800, Tim Harvey wrote:
> > That's the same head that I based them off of and I just did the
> > following and it worked fine:
> > cd /tmp
> > git clone git://git.denx.de/u-boot.git
> > cd u-boot
> > wget https://patchwork.ozlabs.org/series/330704/mbox/ -O mbox
> > git am mbox
> >
> > Looks like only the last patch failed right?
>
> Yeah, only the last patch failed. I converted them again to mbox format
> using my super awkward procmail-based mail-to-mbox scripts, and now it
> seems that git-am eats them just fine. I had taken a look at the last
> patch context, and it looked identical to what was in tree, so I didn't
> understand what was wrong.
>
> Anyway, I just wanted to make sure that the dsa sandbox tests still
> pass, which they do. I'm away from my boards right now, so I won't be
> able to change U-Boot remotely to do a live check.

Joe,

These have been lingering for some time. Will you pick up at least the first 7?

Best Regards,

Tim


[PATCH 1/1] efi_loader: don't use HandleProtocol

2023-01-25 Thread Heinrich Schuchardt
HandleProtocol() is deprecrated. According to the UEFI specification it
should be implemented as a call to  OpenProtocolInterface() with a hard
coded agent handle. This implies that we would have to call
CloseProtocolInterfaces() after usage with the same handle.

Getting rid of an EFI_CALL() is also appreciated.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_boottime.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index e65ca6a4cb..ba28989f36 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1949,6 +1949,7 @@ efi_status_t efi_load_image_from_path(bool boot_policy,
efi_uintn_t buffer_size;
uint64_t addr, pages;
const efi_guid_t *guid;
+   struct efi_handler *handler;
 
/* In case of failure nothing is returned */
*buffer = NULL;
@@ -1970,11 +1971,11 @@ efi_status_t efi_load_image_from_path(bool boot_policy,
}
if (ret != EFI_SUCCESS)
return EFI_NOT_FOUND;
-   ret = EFI_CALL(efi_handle_protocol(device, guid,
-  (void **)&load_file_protocol));
+   ret = efi_search_protocol(device, guid, &handler);
if (ret != EFI_SUCCESS)
return EFI_NOT_FOUND;
buffer_size = 0;
+   load_file_protocol = handler->protocol_interface;
ret = EFI_CALL(load_file_protocol->load_file(
load_file_protocol, rem, boot_policy,
&buffer_size, NULL));
-- 
2.38.1



[PATCH v4 4/6] tpm: sandbox: Update for needed TPM2 capabilities

2023-01-25 Thread Eddie James
The driver needs to support getting the PCRs in the capabilities
command. Fix various other things and support the max number
of PCRs for TPM2.

Signed-off-by: Eddie James 
Reviewed-by: Simon Glass 
---
 drivers/tpm/tpm2_tis_sandbox.c | 100 -
 1 file changed, 72 insertions(+), 28 deletions(-)

diff --git a/drivers/tpm/tpm2_tis_sandbox.c b/drivers/tpm/tpm2_tis_sandbox.c
index dd94bdc31f..ea7fb5e3cb 100644
--- a/drivers/tpm/tpm2_tis_sandbox.c
+++ b/drivers/tpm/tpm2_tis_sandbox.c
@@ -22,11 +22,6 @@ enum tpm2_hierarchy {
TPM2_HIERARCHY_NB,
 };
 
-/* Subset of supported capabilities */
-enum tpm2_capability {
-   TPM_CAP_TPM_PROPERTIES = 0x6,
-};
-
 /* Subset of supported properties */
 #define TPM2_PROPERTIES_OFFSET 0x020E
 
@@ -38,7 +33,8 @@ enum tpm2_cap_tpm_property {
TPM2_PROPERTY_NB,
 };
 
-#define SANDBOX_TPM_PCR_NB 1
+#define SANDBOX_TPM_PCR_NB TPM2_MAX_PCRS
+#define SANDBOX_TPM_PCR_SELECT_MAX ((SANDBOX_TPM_PCR_NB + 7) / 8)
 
 /*
  * Information about our TPM emulation. This is preserved in the sandbox
@@ -433,7 +429,7 @@ static int sandbox_tpm2_xfer(struct udevice *dev, const u8 
*sendbuf,
int i, j;
 
/* TPM2_GetProperty */
-   u32 capability, property, property_count;
+   u32 capability, property, property_count, val;
 
/* TPM2_PCR_Read/Extend variables */
int pcr_index = 0;
@@ -542,19 +538,32 @@ static int sandbox_tpm2_xfer(struct udevice *dev, const 
u8 *sendbuf,
case TPM2_CC_GET_CAPABILITY:
capability = get_unaligned_be32(sent);
sent += sizeof(capability);
-   if (capability != TPM_CAP_TPM_PROPERTIES) {
-   printf("Sandbox TPM only support TPM_CAPABILITIES\n");
-   return TPM2_RC_HANDLE;
-   }
-
property = get_unaligned_be32(sent);
sent += sizeof(property);
-   property -= TPM2_PROPERTIES_OFFSET;
-
property_count = get_unaligned_be32(sent);
sent += sizeof(property_count);
-   if (!property_count ||
-   property + property_count > TPM2_PROPERTY_NB) {
+
+   switch (capability) {
+   case TPM2_CAP_PCRS:
+   break;
+   case TPM2_CAP_TPM_PROPERTIES:
+   if (!property_count) {
+   rc = TPM2_RC_HANDLE;
+   return sandbox_tpm2_fill_buf(recv, recv_len,
+tag, rc);
+   }
+
+   if (property > TPM2_PROPERTIES_OFFSET &&
+   ((property - TPM2_PROPERTIES_OFFSET) +
+property_count > TPM2_PROPERTY_NB)) {
+   rc = TPM2_RC_HANDLE;
+   return sandbox_tpm2_fill_buf(recv, recv_len,
+tag, rc);
+   }
+   break;
+   default:
+   printf("Sandbox TPM2 only supports TPM2_CAP_PCRS or "
+  "TPM2_CAP_TPM_PROPERTIES\n");
rc = TPM2_RC_HANDLE;
return sandbox_tpm2_fill_buf(recv, recv_len, tag, rc);
}
@@ -578,18 +587,53 @@ static int sandbox_tpm2_xfer(struct udevice *dev, const 
u8 *sendbuf,
put_unaligned_be32(capability, recv);
recv += sizeof(capability);
 
-   /* Give the number of properties that follow */
-   put_unaligned_be32(property_count, recv);
-   recv += sizeof(property_count);
-
-   /* Fill with the properties */
-   for (i = 0; i < property_count; i++) {
-   put_unaligned_be32(TPM2_PROPERTIES_OFFSET + property +
-  i, recv);
-   recv += sizeof(property);
-   put_unaligned_be32(tpm->properties[property + i],
-  recv);
-   recv += sizeof(property);
+   switch (capability) {
+   case TPM2_CAP_PCRS:
+   /* Give the number of algorithms supported - just 
SHA256 */
+   put_unaligned_be32(1, recv);
+   recv += sizeof(u32);
+
+   /* Give SHA256 algorithm */
+   put_unaligned_be16(TPM2_ALG_SHA256, recv);
+   recv += sizeof(u16);
+
+   /* Select the PCRs supported */
+   *recv = SANDBOX_TPM_PCR_SELECT_MAX;
+   recv++;
+
+   /* Activate all the PCR bits */
+   for (i = 0; i < SANDBOX_TPM_PCR_SELECT_MAX; ++i) {
+   *recv = 0xff;
+   rec

[PATCH v4 2/6] tpm: Support boot measurements

2023-01-25 Thread Eddie James
Add TPM2 functions to support boot measurement. This includes
starting up the TPM, initializing/appending the event log, and
measuring the U-Boot version. Much of the code was used in the
EFI subsystem, so remove it there and use the common functions.

Signed-off-by: Eddie James 
---
 include/efi_tcg2.h|  44 --
 include/tpm-v2.h  | 254 ++
 lib/efi_loader/efi_tcg2.c | 975 +++---
 lib/tpm-v2.c  | 799 +++
 4 files changed, 1129 insertions(+), 943 deletions(-)

diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
index 874306dc11..23016773f4 100644
--- a/include/efi_tcg2.h
+++ b/include/efi_tcg2.h
@@ -129,50 +129,6 @@ struct efi_tcg2_boot_service_capability {
 #define BOOT_SERVICE_CAPABILITY_MIN \
offsetof(struct efi_tcg2_boot_service_capability, number_of_pcr_banks)
 
-#define TCG_EFI_SPEC_ID_EVENT_SIGNATURE_03 "Spec ID Event03"
-#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_MAJOR_TPM2 2
-#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_MINOR_TPM2 0
-#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_ERRATA_TPM2 2
-
-/**
- *  struct TCG_EfiSpecIdEventAlgorithmSize - hashing algorithm information
- *
- *  @algorithm_id: algorithm defined in enum tpm2_algorithms
- *  @digest_size:  size of the algorithm
- */
-struct tcg_efi_spec_id_event_algorithm_size {
-   u16  algorithm_id;
-   u16  digest_size;
-} __packed;
-
-/**
- * struct TCG_EfiSpecIDEventStruct - content of the event log header
- *
- * @signature: signature, set to Spec ID Event03
- * @platform_class:class defined in TCG ACPI Specification
- * Client  Common Header.
- * @spec_version_minor:minor version
- * @spec_version_major:major version
- * @spec_version_errata:   major version
- * @uintn_size:size of the efi_uintn_t fields used in 
various
- * data structures used in this specification.
- * 0x01 indicates u32  and 0x02  indicates u64
- * @number_of_algorithms:  hashing algorithms used in this event log
- * @digest_sizes:  array of number_of_algorithms pairs
- * 1st member defines the algorithm id
- * 2nd member defines the algorithm size
- */
-struct tcg_efi_spec_id_event {
-   u8 signature[16];
-   u32 platform_class;
-   u8 spec_version_minor;
-   u8 spec_version_major;
-   u8 spec_errata;
-   u8 uintn_size;
-   u32 number_of_algorithms;
-   struct tcg_efi_spec_id_event_algorithm_size digest_sizes[];
-} __packed;
-
 /**
  * struct tdEFI_TCG2_FINAL_EVENTS_TABLE - log entries after Get Event Log
  * @version:   version number for this structure
diff --git a/include/tpm-v2.h b/include/tpm-v2.h
index 85feda3e06..7057f67176 100644
--- a/include/tpm-v2.h
+++ b/include/tpm-v2.h
@@ -214,6 +214,50 @@ struct tcg_pcr_event2 {
u8 event[];
 } __packed;
 
+/**
+ *  struct TCG_EfiSpecIdEventAlgorithmSize - hashing algorithm information
+ *
+ *  @algorithm_id: algorithm defined in enum tpm2_algorithms
+ *  @digest_size:  size of the algorithm
+ */
+struct tcg_efi_spec_id_event_algorithm_size {
+   u16  algorithm_id;
+   u16  digest_size;
+} __packed;
+
+#define TCG_EFI_SPEC_ID_EVENT_SIGNATURE_03 "Spec ID Event03"
+#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_MAJOR_TPM2 2
+#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_MINOR_TPM2 0
+#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_ERRATA_TPM2 2
+
+/**
+ * struct TCG_EfiSpecIDEventStruct - content of the event log header
+ *
+ * @signature: signature, set to Spec ID Event03
+ * @platform_class:class defined in TCG ACPI Specification
+ * Client  Common Header.
+ * @spec_version_minor:minor version
+ * @spec_version_major:major version
+ * @spec_version_errata:   major version
+ * @uintn_size:size of the efi_uintn_t fields used in 
various
+ * data structures used in this specification.
+ * 0x01 indicates u32  and 0x02  indicates u64
+ * @number_of_algorithms:  hashing algorithms used in this event log
+ * @digest_sizes:  array of number_of_algorithms pairs
+ * 1st member defines the algorithm id
+ * 2nd member defines the algorithm size
+ */
+struct tcg_efi_spec_id_event {
+   u8 signature[16];
+   u32 platform_class;
+   u8 spec_version_minor;
+   u8 spec_version_major;
+   u8 spec_errata;
+   u8 uintn_size;
+   u32 number_of_algorithms;
+   struct tcg_efi_spec_id_event_algorithm_size digest_sizes[];
+} __packed;
+
 /**
  * TPM2 Structure Tags for command/response buffers.
  *
@@ -340,6 +384,26 @@ enum tpm2_algorithms {
TPM2_AL

[PATCH v4 5/6] test: Add sandbox TPM boot measurement

2023-01-25 Thread Eddie James
Use the sandbox TPM driver to measure some boot images in a unit
test case.

Signed-off-by: Eddie James 
---
 arch/sandbox/dts/sandbox.dtsi | 14 
 arch/sandbox/dts/test.dts | 13 +++
 configs/sandbox_defconfig |  1 +
 include/test/suites.h |  1 +
 test/boot/Makefile|  1 +
 test/boot/measurement.c   | 66 +++
 test/cmd_ut.c |  2 ++
 7 files changed, 98 insertions(+)
 create mode 100644 test/boot/measurement.c

diff --git a/arch/sandbox/dts/sandbox.dtsi b/arch/sandbox/dts/sandbox.dtsi
index 18bf1cb5b6..3f0e192a83 100644
--- a/arch/sandbox/dts/sandbox.dtsi
+++ b/arch/sandbox/dts/sandbox.dtsi
@@ -4,9 +4,22 @@
  * and sandbox64 builds.
  */
 
+#include 
+
 #define USB_CLASS_HUB  9
 
 / {
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   event_log: tcg_event_log {
+   no-map;
+   reg = <(CFG_SYS_SDRAM_SIZE - 0x2000) 0x2000>;
+   };
+   };
+
binman {
};
 
@@ -332,6 +345,7 @@
 
tpm2 {
compatible = "sandbox,tpm2";
+   memory-region = <&event_log>;
};
 
triangle {
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 9d96e479ca..c334b89faa 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -9,6 +9,7 @@
 
 /dts-v1/;
 
+#include 
 #include 
 #include 
 #include 
@@ -66,6 +67,17 @@
osd0 = "/osd";
};
 
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   event_log: tcg_event_log {
+   no-map;
+   reg = <(CFG_SYS_SDRAM_SIZE - 0x2000) 0x2000>;
+   };
+   };
+
binman: binman {
};
 
@@ -1343,6 +1355,7 @@
 
tpm2 {
compatible = "sandbox,tpm2";
+   memory-region = <&event_log>;
};
 
uart0: serial {
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 34c342b6f5..9c4985adcf 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -337,3 +337,4 @@ CONFIG_TEST_FDTDEC=y
 CONFIG_UNIT_TEST=y
 CONFIG_UT_TIME=y
 CONFIG_UT_DM=y
+CONFIG_MEASURED_BOOT=y
diff --git a/include/test/suites.h b/include/test/suites.h
index 9ce49cbb03..4c284bbeaa 100644
--- a/include/test/suites.h
+++ b/include/test/suites.h
@@ -44,6 +44,7 @@ int do_ut_font(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[]);
 int do_ut_lib(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_loadm(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_log(struct cmd_tbl *cmdtp, int flag, int argc, char * const argv[]);
+int do_ut_measurement(struct cmd_tbl *cmdtp, int flag, int argc, char * const 
argv[]);
 int do_ut_mem(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_optee(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_overlay(struct cmd_tbl *cmdtp, int flag, int argc,
diff --git a/test/boot/Makefile b/test/boot/Makefile
index 22ed61c8fa..2dbb032a7e 100644
--- a/test/boot/Makefile
+++ b/test/boot/Makefile
@@ -4,6 +4,7 @@
 
 obj-$(CONFIG_BOOTSTD) += bootdev.o bootstd_common.o bootflow.o bootmeth.o
 obj-$(CONFIG_FIT) += image.o
+obj-$(CONFIG_MEASURED_BOOT) += measurement.o
 
 obj-$(CONFIG_EXPO) += expo.o
 
diff --git a/test/boot/measurement.c b/test/boot/measurement.c
new file mode 100644
index 00..2155208894
--- /dev/null
+++ b/test/boot/measurement.c
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Test for measured boot functions
+ *
+ * Copyright 2023 IBM Corp.
+ * Written by Eddie James 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MEASUREMENT_TEST(_name, _flags)\
+   UNIT_TEST(_name, _flags, measurement_test)
+
+static int measure(struct unit_test_state *uts)
+{
+   struct bootm_headers images;
+   const size_t size = 1024;
+   u8 *kernel;
+   u8 *initrd;
+   size_t i;
+
+   kernel = malloc(size);
+   initrd = malloc(size);
+
+   images.os.image_start = map_to_sysmem(kernel);
+   images.os.image_len = size;
+
+   images.rd_start = map_to_sysmem(initrd);
+   images.rd_end = images.rd_start + size;
+
+   images.ft_addr = malloc(size);
+   images.ft_len = size;
+
+   env_set("bootargs", "measurement testing");
+
+   for (i = 0; i < size; ++i) {
+   kernel[i] = (u8)(0xf0 | (i & 0xf));
+   initrd[i] = (u8)((i & 0xf0) | 0xf);
+   ((u8 *)images.ft_addr)[i] = (u8)(i & 0xff);
+   }
+
+   ut_assertok(bootm_measure(&images));
+
+   free(images.ft_addr);
+   free(initrd);
+   free(kernel);
+
+   return 0;
+}
+MEASUREMENT_TEST(measure, 0);
+
+int do_ut_m

[PATCH v4 3/6] bootm: Support boot measurement

2023-01-25 Thread Eddie James
Add a configuration option to measure the boot through the bootm
function. Add the measurement state to the booti and bootz paths
as well.

Signed-off-by: Eddie James 
---
 boot/Kconfig| 23 
 boot/bootm.c| 70 +
 cmd/booti.c |  1 +
 cmd/bootm.c |  2 ++
 cmd/bootz.c |  1 +
 include/bootm.h |  2 ++
 include/image.h |  1 +
 7 files changed, 100 insertions(+)

diff --git a/boot/Kconfig b/boot/Kconfig
index fdcfbae7b2..831b9e954c 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -601,6 +601,29 @@ config LEGACY_IMAGE_FORMAT
  loaded. If a board needs the legacy image format support in this
  case, enable it here.
 
+config MEASURED_BOOT
+   bool "Measure boot images and configuration to TPM and event log"
+   depends on HASH && TPM_V2
+   help
+ This option enables measurement of the boot process. Measurement
+ involves creating cryptographic hashes of the binary images that
+ are booting and storing them in the TPM. In addition, a log of
+ these hashes is stored in memory for the OS to verify the booted
+ images and configuration. Enable this if the OS has configured
+ some memory area for the event log and you intend to use some
+ attestation tools on your system.
+
+if MEASURED_BOOT
+   config MEASURE_DEVICETREE
+   bool "Measure the devicetree image"
+   default y if MEASURED_BOOT
+   help
+ On some platforms, the devicetree is not static as it may contain
+ random MAC addresses or other such data that changes each boot.
+ Therefore, it should not be measured into the TPM. In that case,
+ disable the measurement here.
+endif # MEASURED_BOOT
+
 config SUPPORT_RAW_INITRD
bool "Enable raw initrd images"
help
diff --git a/boot/bootm.c b/boot/bootm.c
index 15fce8ad95..c8423f2c60 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #if defined(CONFIG_CMD_USB)
 #include 
 #endif
@@ -659,6 +660,72 @@ int bootm_process_cmdline_env(int flags)
return 0;
 }
 
+int bootm_measure(struct bootm_headers *images)
+{
+   int ret = 0;
+
+   /* Skip measurement if EFI is going to do it */
+   if (images->os.os == IH_OS_EFI &&
+   IS_ENABLED(CONFIG_EFI_TCG2_PROTOCOL) &&
+   IS_ENABLED(CONFIG_BOOTM_EFI))
+   return ret;
+
+   if (IS_ENABLED(CONFIG_MEASURED_BOOT)) {
+   struct tcg2_event_log elog;
+   struct udevice *dev;
+   void *initrd_buf;
+   void *image_buf;
+   const char *s;
+   u32 rd_len;
+
+   ret = tcg2_measurement_init(&dev, &elog);
+   if (ret)
+   return ret;
+
+   image_buf = map_sysmem(images->os.image_start,
+  images->os.image_len);
+   ret = tcg2_measure_data(dev, &elog, 8, images->os.image_len,
+   image_buf, EV_COMPACT_HASH,
+   strlen("linux") + 1, (u8 *)"linux");
+   if (ret)
+   goto unmap_image;
+
+   rd_len = images->rd_end - images->rd_start;
+   initrd_buf = map_sysmem(images->rd_start, rd_len);
+   ret = tcg2_measure_data(dev, &elog, 8, rd_len, initrd_buf,
+   EV_COMPACT_HASH, strlen("initrd") + 1,
+   (u8 *)"initrd");
+   if (ret)
+   goto unmap_initrd;
+
+   if (IS_ENABLED(CONFIG_MEASURE_DEVICETREE)) {
+   ret = tcg2_measure_data(dev, &elog, 9, images->ft_len,
+   (u8 *)images->ft_addr,
+   EV_TABLE_OF_DEVICES,
+   strlen("dts") + 1,
+   (u8 *)"dts");
+   if (ret)
+   goto unmap_initrd;
+   }
+
+   s = env_get("bootargs");
+   if (!s)
+   s = "";
+   ret = tcg2_measure_data(dev, &elog, 1, strlen(s) + 1, (u8 *)s,
+   EV_PLATFORM_CONFIG_FLAGS,
+   strlen(s) + 1, (u8 *)s);
+
+unmap_initrd:
+   unmap_sysmem(initrd_buf);
+
+unmap_image:
+   unmap_sysmem(image_buf);
+   tcg2_measurement_term(dev, &elog, ret != 0);
+   }
+
+   return ret;
+}
+
 /**
  * Execute selected states of the bootm command.
  *
@@ -710,6 +777,9 @@ int do_bootm_states(struct cmd_tbl *cmdtp, int flag, int 
argc,
if (!ret && (states & BOOTM_STATE_FINDOTHER))
ret = bootm_find_other(cmdtp, flag, argc, argv);
 
+   if (IS_ENABLED(CONFIG_ME

[PATCH v4 6/6] doc: Add measured boot documentation

2023-01-25 Thread Eddie James
Briefly describe the feature and specify the requirements.

Signed-off-by: Eddie James 
---
 doc/usage/index.rst |  1 +
 doc/usage/measured_boot.rst | 23 +++
 2 files changed, 24 insertions(+)
 create mode 100644 doc/usage/measured_boot.rst

diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index 7d4a1cbc10..c3efdf61df 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -12,6 +12,7 @@ Use U-Boot
partitions
cmdline
semihosting
+   measured_boot
 
 Shell commands
 --
diff --git a/doc/usage/measured_boot.rst b/doc/usage/measured_boot.rst
new file mode 100644
index 00..13fd42a2fb
--- /dev/null
+++ b/doc/usage/measured_boot.rst
@@ -0,0 +1,23 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Measured Boot
+=
+
+U-Boot can perform a measured boot, the process of hashing various components
+of the boot process, extending the results in the TPM and logging the
+component's measurement in memory for the operating system to consume.
+
+Requirements
+-
+
+A hardware TPM 2.0 supported by the U-Boot drivers
+CONFIG_TPM=y
+CONFIG_MEASURED_BOOT=y
+Device-tree configuration of the TPM device to specify the memory area
+for event logging. The TPM device node must either contain a phandle to
+a reserved memory region or "linux,sml-base" and "linux,sml-size"
+indicating the address and size of the memory region. An example can be
+found in arch/sandbox/dts/test.dts
+The operating system must also be configured to use the memory regions
+specified in the U-Boot device-tree in order to make use of the event
+log.
-- 
2.31.1



[PATCH v4 1/6] tpm: Fix spelling for tpmu_ha union

2023-01-25 Thread Eddie James
tmpu -> tpmu

Signed-off-by: Eddie James 
Reviewed-by: Ilias Apalodimas 
---
 include/tpm-v2.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/tpm-v2.h b/include/tpm-v2.h
index 737e57551d..85feda3e06 100644
--- a/include/tpm-v2.h
+++ b/include/tpm-v2.h
@@ -167,7 +167,7 @@ struct tcg_pcr_event {
 /**
  * Definition of TPMU_HA Union
  */
-union tmpu_ha {
+union tpmu_ha {
u8 sha1[TPM2_SHA1_DIGEST_SIZE];
u8 sha256[TPM2_SHA256_DIGEST_SIZE];
u8 sm3_256[TPM2_SM3_256_DIGEST_SIZE];
@@ -183,7 +183,7 @@ union tmpu_ha {
  */
 struct tpmt_ha {
u16 hash_alg;
-   union tmpu_ha digest;
+   union tpmu_ha digest;
 } __packed;
 
 /**
-- 
2.31.1



[PATCH v4 0/6] tpm: Support boot measurements

2023-01-25 Thread Eddie James
This series adds support for measuring the boot images more generically
than the existing EFI support. Several EFI functions have been moved to
the TPM layer. The series includes optional measurement from the bootm 
command.
A new test case has been added for the bootm measurement to test the new
path, and the sandbox TPM2 driver has been updated to support this use
case.

Changes since v3:
 - Reordered headers
 - Refactored more of EFI code into common code
Removed digest_info structure and instead used the common alg_to_mask
  and alg_to_len
Improved event log parsing in common code to get it equivalent to EFI
  Common code now extends PCR if previous bootloader stage couldn't
  No need to allocate memory in the common code, so EFI copies the
  discovered buffer like it did before
Rename efi measure_event function

Changes since v2:
 - Add documentation.
 - Changed reserved memory address to the top of the RAM for sandbox dts.
 - Add measure state to booti and bootz.
 - Skip measurement for EFI images that should be measured

Changes since v1:
 - Refactor TPM layer functions to allow EFI system to use them, and
   remove duplicate EFI functions.
 - Add test case
 - Drop #ifdefs for bootm
 - Add devicetree measurement config option
 - Update sandbox TPM driver

Eddie James (6):
  tpm: Fix spelling for tpmu_ha union
  tpm: Support boot measurements
  bootm: Support boot measurement
  tpm: sandbox: Update for needed TPM2 capabilities
  test: Add sandbox TPM boot measurement
  doc: Add measured boot documentation

 arch/sandbox/dts/sandbox.dtsi  |  14 +
 arch/sandbox/dts/test.dts  |  13 +
 boot/Kconfig   |  23 +
 boot/bootm.c   |  70 +++
 cmd/booti.c|   1 +
 cmd/bootm.c|   2 +
 cmd/bootz.c|   1 +
 configs/sandbox_defconfig  |   1 +
 doc/usage/index.rst|   1 +
 doc/usage/measured_boot.rst|  23 +
 drivers/tpm/tpm2_tis_sandbox.c | 100 +++-
 include/bootm.h|   2 +
 include/efi_tcg2.h |  44 --
 include/image.h|   1 +
 include/test/suites.h  |   1 +
 include/tpm-v2.h   | 258 -
 lib/efi_loader/efi_tcg2.c  | 975 +++--
 lib/tpm-v2.c   | 799 +++
 test/boot/Makefile |   1 +
 test/boot/measurement.c|  66 +++
 test/cmd_ut.c  |   2 +
 21 files changed, 1425 insertions(+), 973 deletions(-)
 create mode 100644 doc/usage/measured_boot.rst
 create mode 100644 test/boot/measurement.c

-- 
2.31.1



Re: [PATCH] imx: kontron-sl-mx8mm: Fix SD card IO voltage level

2023-01-25 Thread Marek Vasut

On 1/25/23 14:41, Frieder Schrempf wrote:

From: Frieder Schrempf 


Subject tags should be ARM: dts: imx:


The LDO5 of the PCA9450 PMIC can be switched between two different
voltage settings (defaulting to 1.8V and 3.3V) using an external
signal SD_VSEL that is connected to the VSELECT signal of the SD
card interface.

As the regulator driver can't deal with both LDO registers (LDO5CTRL_H
and LDO5CTRL_L) it only uses one of them, which means reading the
voltage from the regulator can potentially return a value that does not
reflect the actual state of the LDO5 output.


Can you fix the regulator driver ?


In our case, after booting U-Boot we read 1.8V from the regulator
while in fact as the VSELECT signal is still low the regulator outputs
3.3V. This confusion causes the MMC driver to think it is dealing with
a 1.8V-only device. This in turn leads to SD cards being addressed
with 1.8V IO levels even if UHS support is not available or disabled.

Some cards with UHS support still work even if they are addressed
with 1.8V levels in non-UHS modes, but a lot of cards also fail with
timeout errors like:

   Card did not respond to voltage select! : -110

As a workaorund we disable the vqmmc regulator for now so we can make
sure no wrong values are read from the regulator. The switching
between 1.8V and 3.3V still works as the ESDHC driver sets the
VSELECT signal accordingly.

Signed-off-by: Frieder Schrempf 
---
By the way: I suspect that other boards using the PCA9450 might also be affected
by this. I didn't find a nice generic solution so far. It would be possible to
patch the pca9450 driver to use the PCA9450_LDO5CTRL_L instead of the
PCA9450_LDO5CTRL_H register for LDO5. This would fix this particular case,
but still not the root problem of the regulator driver returning wrong values.
So if anyone got some idea how to properly handle this, let me know.
The same issue is also present in Linux. While I didn't notice any problems
with the SD card being addressed with incorrect voltage levels so far,
reading the regulator doesn't return the correct value if VSELECT is low.


Configure VSELECT pinmux such that it is a function, as it is right now, 
MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT or similar, (so SD controller 
driver can operate the pin via SD controller), but set SION bit so GPIO 
controller can read its state (activate bit 30), i.e.:

MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0x4004

Use sd-vsel-gpios property of PMIC, claim the VSELECT as GPIO in PMIC 
driver (this won't change pinmux, the pin would still be configured as 
function, but SION bit would allow you to read its state), read its 
state, and return the correct LDO5CTRL_H/LDO5CTRL_L value based on that.


If this works, then:
arm64: dts: imx8mp: Drop sd-vsel-gpios from *
Linux kernel patches should not be applied.

[...]


Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver

2023-01-25 Thread Sudeep Holla
On Wed, Jan 25, 2023 at 04:44:34PM +, Abdellatif El Khlifi wrote:

[...]

> Future SW features using SMC can be discovered by arm_smccc as well.
> We can document this approach in U-Boot/Linux so future developments
> will follow this approach.
>

OK as discussed in private, you must not need any new binding. Also looking
(a very quick glance) at the U-Boot and in particular

"Commit 2fbe47b7e771 ("firmware: psci: bind arm smccc features when 
discovered")"

It looks like you have most of what you need already. Etienne has already
added mechanism for SMCCC discovery. You just need to extend things from
there if you need to support other features using SMCCC and discoverable
via SMCCC. Hope that helps.

-- 
Regards,
Sudeep


Re: [PATCH] bootstd: Replicate the dtb-filename quirks of distroboot

2023-01-25 Thread Heinrich Schuchardt

On 1/25/23 17:15, Tom Rini wrote:

On Wed, Jan 25, 2023 at 04:38:53PM +0100, Heinrich Schuchardt wrote:

On 1/25/23 04:11, Simon Glass wrote:

For EFI, the distro boot scripts search in three different directories
for the .dtb file. The SOC-based filename fallback is supported only for
32-bit ARM.

Adjust the code to mirror this behaviour.

Signed-off-by: Simon Glass 
Suggested-by: Mark Kettenis 
---

   boot/bootmeth_efi.c | 63 ++---
   1 file changed, 54 insertions(+), 9 deletions(-)

diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c
index 67c972e3fe4..f9544846e68 100644
--- a/boot/bootmeth_efi.c
+++ b/boot/bootmeth_efi.c
@@ -147,25 +147,57 @@ static int distro_efi_check(struct udevice *dev, struct 
bootflow_iter *iter)
return 0;
   }
-static void distro_efi_get_fdt_name(char *fname, int size)
+/**
+ * distro_efi_get_fdt_name() - Get the filename for reading the .dtb file
+ *
+ * @fname: Place to put filename
+ * @size: Max size of filename
+ * @seq: Sequence number, to cycle through options (0=first)
+ * Returns: 0 on success, -ENOENT if the "fdtfile" env var does not exist,
+ * -EINVAL if there are no more options
+ */
+static int distro_efi_get_fdt_name(char *fname, int size, int seq)
   {
const char *fdt_fname;
+   const char *prefix;
+
+   /* select the prefix */
+   switch (seq) {
+   case 0:
+   /* this is the default */
+   prefix = "/dtb";
+   break;
+   case 1:
+   prefix = "";
+   break;
+   case 2:
+   prefix = "/dtb/current";
+   break;
+   default:
+   return log_msg_ret("pref", -EINVAL);
+   }
fdt_fname = env_get("fdtfile");
if (fdt_fname) {
-   snprintf(fname, size, "dtb/%s", fdt_fname);
+   snprintf(fname, size, "%s/%s", prefix, fdt_fname);
log_debug("Using device tree: %s\n", fname);
-   } else {
+
+   /* Use this fallback only for 32-bit ARM */
+   } else if (IS_ENABLED(CONFIG_ARM) && !IS_ENABLED(CONFIG_ARM64)) {
const char *soc = env_get("soc");
const char *board = env_get("board");
const char *boardver = env_get("boardver");
/* cf the code in label_boot() which seems very complex */
-   snprintf(fname, size, "dtb/%s%s%s%s.dtb",
+   snprintf(fname, size, "%s/%s%s%s%s.dtb", prefix,
 soc ? soc : "", soc ? "-" : "", board ? board : "",
 boardver ? boardver : "");
log_debug("Using default device tree: %s\n", fname);
+   } else {
+   return log_msg_ret("env", -ENOENT);
}
+
+   return 0;
   }
   static int distro_efi_read_bootflow_file(struct udevice *dev,
@@ -174,7 +206,7 @@ static int distro_efi_read_bootflow_file(struct udevice 
*dev,
struct blk_desc *desc = NULL;
ulong fdt_addr, size;
char fname[256];
-   int ret;
+   int ret, seq;
/* We require a partition table */
if (!bflow->part)
@@ -196,13 +228,22 @@ static int distro_efi_read_bootflow_file(struct udevice 
*dev,
if (ret)
return log_msg_ret("read", -EINVAL);
-   distro_efi_get_fdt_name(fname, sizeof(fname));
+   fdt_addr = env_get_hex("fdt_addr_r", 0);
+
+   /* try the various available names */
+   ret = -ENOENT;
+   for (seq = 0; ret; seq++)


There are boards that don't have a dtb file available and that is ok. Don't
loop past seq = 2.

{

+   ret = distro_efi_get_fdt_name(fname, sizeof(fname), seq);
+   if (ret)
+   return log_msg_ret("nam", ret);
+   ret = bootmeth_common_read_file(dev, bflow, fname, fdt_addr,
+   &size);
+   }
+
bflow->fdt_fname = strdup(fname);
if (!bflow->fdt_fname)
return log_msg_ret("fil", -ENOMEM);


This should not be an error. The Distroboot fallback is the device-tree at
$fdtcontroladdr.


But it should note that it's using that because that's still quite often
an unexpected feature to people.



On QEMU it is just what is needed. Other boards supply the device-tree 
via TF-A or OpenSBI. We should not start breaking boards.


A message "fil: returning err= -12" signals not caring about users.

Best regards

Heinrich


Re: Pull request: u-boot-sunxi/master for 2023.04

2023-01-25 Thread Tom Rini
On Wed, Jan 25, 2023 at 01:59:40AM +, Andre Przywara wrote:

> Hi Tom,
> 
> please pull the first part of the sunxi pull request for this cycle.
> This contains some fixes, and the first bunch of some clean up patches
> to get rid of legacy GPIO and PMIC code.
> Highlight is the DM AXP PMIC driver, which is required to convert some
> drivers over to use DM regulators, and also is required to get rid
> of some less optimal PMIC setup code in Trusted Firmware. This isn't
> enabled by any defconfig yet, but can be enabled manually and works. For
> the full glory some patches are still missing, and this requires more
> testing, which would be simpler if the core code is upstream.
> 
> I couldn't get the gitlab CI to pass, it seemed to time out in the last
> step, when building all ARM(32) boards. I built all sunxi boards with
> buildman locally, without issues, so this should be fine.
> Tested on an H3, A64, R40, A20 and H6 board.

Note that you likely need to change the default timeout from 1h to
something like 4h, in case you get one of the slower runners.

> If everything goes well, I will send a second part later this week, some
> patches still need some review and testing.

OK.

> Thanks,
> Andre
> 
> 
> The following changes since commit dd31cd58b02729807934cb699b164b1f8736620f:
> 
>   Merge tag 'efi-2023-04-rc1-2' of 
> https://source.denx.de/u-boot/custodians/u-boot-efi (2023-01-20 14:23:20 
> -0500)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master
> 
> for you to fetch changes up to cd108f2795777d3cca1d0f00c50bb92f766f6591:
> 
>   video: sunxi: dw-hdmi: Read address from DT node (2023-01-23 01:18:31 +)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver

2023-01-25 Thread Abdellatif El Khlifi
On Wed, Jan 25, 2023 at 10:00:58AM -0600, Rob Herring wrote:
> On Tue, Jan 24, 2023 at 9:56 AM Abdellatif El Khlifi
>  wrote:
> >
> > On Mon, Jan 23, 2023 at 09:32:28AM -0700, Simon Glass wrote:
> > > Hi Rob,
> > >
> > > On Mon, 23 Jan 2023 at 08:13, Rob Herring  wrote:
> > > >
> > > > On Fri, Jan 20, 2023 at 4:04 PM Simon Glass  wrote:
> > > > >
> > > > > Hi Rob,
> > > > >
> > > > > On Thu, 19 Jan 2023 at 11:11, Rob Herring  wrote:
> > > > > >
> > > > > > On Thu, Jan 19, 2023 at 10:41 AM Simon Glass  
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi Abdellatif,
> > > > > > >
> > > > > > > On Thu, 19 Jan 2023 at 09:32, Abdellatif El Khlifi
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Wed, Jan 18, 2023 at 08:59:32AM -0500, Tom Rini wrote:
> > > > > > > > > On Wed, Jan 18, 2023 at 01:46:54PM +, Sudeep Holla wrote:
> > > > > > > > > > On Wed, Jan 18, 2023 at 12:49 PM Tom Rini 
> > > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I guess the problem comes down to, can we have one 
> > > > > > > > > > > discovery method that
> > > > > > > > > > > everyone shares, or do we have to let everyone invent a 
> > > > > > > > > > > new discovery
> > > > > > > > > > > method every time?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > No one needs to invent any discovery method every time if 
> > > > > > > > > > the firmware
> > > > > > > > > > specification
> > > > > > > > > > provides one and as Rob mentioned many times in the thread, 
> > > > > > > > > > all new firmware
> > > > > > > > > > specification must provide one and we are trying to make 
> > > > > > > > > > sure that is
> > > > > > > > > > the case with all new
> > > > > > > > > > specs from Arm.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > FF-A, Op-tee, U-Boot, coreboot, barebox (and
> > > > > > > > > > > everyone else I'm unintentionally forgetting) could just 
> > > > > > > > > > > discover these
> > > > > > > > > > > things via device tree.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I leave that to the individual projects to decide and agree 
> > > > > > > > > > but
> > > > > > > > > > fundamentally if
> > > > > > > > > > the specification provides a way to discover, not sure why 
> > > > > > > > > > we are even
> > > > > > > > > > discussing
> > > > > > > > > > an alternative method here.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > Or, we could all write our own code to perform
> > > > > > > > > > > the discovery.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > For what reason ? I can understand if there is no discovery 
> > > > > > > > > > mechanism but
> > > > > > > > > > that's not the
> > > > > > > > > > case in $subject.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > And when RISC-V comes along with similar functionality,
> > > > > > > > > > > we could probe their device tree and see they've 
> > > > > > > > > > > implemented the same
> > > > > > > > > > > concept, but a little differently, but still have the 
> > > > > > > > > > > discovery portion
> > > > > > > > > > > be in the device tree. To which it sounds like your 
> > > > > > > > > > > answer is "not in
> > > > > > > > > > > the device tree".
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I see U-boot seem to have made a decision to create DT node 
> > > > > > > > > > for each and
> > > > > > > > > > everything
> > > > > > > > > > that needs to be added to DM which seems bit unfortunate 
> > > > > > > > > > but I don't
> > > > > > > > > > understand the
> > > > > > > > > > history/motive/background for it but I respect the decision 
> > > > > > > > > > if it is
> > > > > > > > > > already made.
> > > > > > > > > >
> > > > > > > > > > These firmware interfaces are standard on all Arm platforms 
> > > > > > > > > > and can be
> > > > > > > > > > discovered
> > > > > > > > > > based on PSCI/SMCCC. Not using the same and use DT node 
> > > > > > > > > > needs unnecessary
> > > > > > > > > > addition of DT nodes for all the f/w i/f on all the 
> > > > > > > > > > platforms that need the
> > > > > > > > > > support when
> > > > > > > > > > one can be just discovered.
> > > > > > > > > >
> > > > > > > > > > Sorry for the sudden appearance on this thread, I was 
> > > > > > > > > > avoiding getting into
> > > > > > > > > > this but thought
> > > > > > > > > > I will at least express my opinion and also the way the 
> > > > > > > > > > firmware
> > > > > > > > > > specifications from Arm is
> > > > > > > > > > expected to be evolved from now on. With that I will leave 
> > > > > > > > > > it to you and
> > > > > > > > > > other U-boot
> > > > > > > > > > maintainers and the community in general to decide the 
> > > > > > > > > > right course in this
> > > > > > > > > > case.
> > > > > > > > >
> > > > > > > > > To be clear, if the position is that "this is what everyone 
> > > > > > > > > else will
> > > > > > > > > use, really" then yes, w

[PATCH v2 3/3] microblaze: spl: disable falcon mode by default

2023-01-25 Thread Ovidiu Panait
Drop falcon mode configs from microblaze-generic_defconfig, so that a
defconfig build will still boot into u-boot proper.

Signed-off-by: Ovidiu Panait 
---

Changes in v2:
New patch.

 configs/microblaze-generic_defconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/configs/microblaze-generic_defconfig 
b/configs/microblaze-generic_defconfig
index be34941805..438540fbe4 100644
--- a/configs/microblaze-generic_defconfig
+++ b/configs/microblaze-generic_defconfig
@@ -33,9 +33,6 @@ CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
 CONFIG_SPL_STACK=0x10
 CONFIG_SPL_NOR_SUPPORT=y
-CONFIG_SPL_OS_BOOT=y
-CONFIG_SYS_SPL_ARGS_ADDR=0x2a00
-CONFIG_SYS_OS_BASE=0x2c06
 CONFIG_SYS_MAXARGS=15
 CONFIG_SYS_CBSIZE=512
 CONFIG_SYS_PBSIZE=544
-- 
2.25.1



[PATCH v2 2/3] microblaze: spl: drop boot_linux

2023-01-25 Thread Ovidiu Panait
Drop boot_linux variable as it is not assigned anywhere. Now that there is
no variable controlling linux boot in spl_start_uboot(), make this
function always return false when falcon mode is enabled.

Signed-off-by: Ovidiu Panait 
---

Changes in v2:
New patch.

 arch/microblaze/cpu/spl.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/microblaze/cpu/spl.c b/arch/microblaze/cpu/spl.c
index b9ff9c3702..eaa095ba99 100644
--- a/arch/microblaze/cpu/spl.c
+++ b/arch/microblaze/cpu/spl.c
@@ -14,8 +14,6 @@
 #include 
 #include 
 
-bool boot_linux;
-
 void board_boot_order(u32 *spl_boot_list)
 {
spl_boot_list[0] = BOOT_DEVICE_NOR;
@@ -44,10 +42,7 @@ void __noreturn jump_to_image_linux(struct spl_image_info 
*spl_image)
 
 int spl_start_uboot(void)
 {
-   if (boot_linux)
-   return 0;
-
-   return 1;
+   return 0;
 }
 #endif /* CONFIG_SPL_OS_BOOT */
 
-- 
2.25.1



[PATCH v2 1/3] microblaze: spl: wrap spl_start_uboot() in SPL_OS_BOOT ifdefs

2023-01-25 Thread Ovidiu Panait
Make spl_start_uboot() available only if CONFIG_SPL_OS_BOOT is enabled,
since it is only used for falcon mode.

Signed-off-by: Ovidiu Panait 
---

Changes in v2:
New patch.

 arch/microblaze/cpu/spl.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/microblaze/cpu/spl.c b/arch/microblaze/cpu/spl.c
index cea6d56f16..b9ff9c3702 100644
--- a/arch/microblaze/cpu/spl.c
+++ b/arch/microblaze/cpu/spl.c
@@ -41,17 +41,15 @@ void __noreturn jump_to_image_linux(struct spl_image_info 
*spl_image)
 
image_entry(NULL, 0, (ulong)spl_image->arg);
 }
-#endif /* CONFIG_SPL_OS_BOOT */
 
 int spl_start_uboot(void)
 {
-#ifdef CONFIG_SPL_OS_BOOT
if (boot_linux)
return 0;
-#endif
 
return 1;
 }
+#endif /* CONFIG_SPL_OS_BOOT */
 
 int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 {
-- 
2.25.1



Re: [PATCH v6 0/3] Timer support for ARM Tegra

2023-01-25 Thread Thierry Reding
On Tue, Jan 24, 2023 at 08:57:48AM +0200, Svyatoslav Ryhel wrote:
> - ARM: tegra: remap clock_osc_freq for all Tegra family
> Enum clock_osc_freq was designed to use only with T20.
> This patch remaps it to use additional frequencies, added in
> T30+ SoC while maintaining backwards compatibility with T20.
> 
> - drivers: timer: add timer driver for ARMv7 based Tegra devices
> Add timer support for T20/T30/T114 and T124 based devices.
> Driver is based on DM, has device tree support and can be
> used on SPL and early boot stage.
> 
> - ARM: tegra: include timer as default option
> Enable TIMER as default option for all Tegra devices and
> enable TEGRA_TIMER for TEGRA_ARMV7_COMMON. Additionally
> enable SPL_TIMER if build as SPL part and drop deprecated
> configs from common header.
> 
> P. S. I have no arm64 Tegra and according to comment in 
> tegra-common.h
> Use the Tegra US timer on ARMv7, but the architected timer on ARMv8.
> 
> Svyatoslav Ryhel (3):
>   ARM: tegra: remap clock_osc_freq for all Tegra family
>   drivers: timer: add timer driver for ARMv7 based Tegra devices
>   ARM: tegra: include timer as default option

This causes a regression on Tegra210 (Jetson TX1). I'm trying to
investigate, but it's complicated by the fact that I'm not getting out
any debug prints, so I suspect the issue is happening quite early.

Thierry

> 
>  arch/arm/Kconfig|   1 +
>  arch/arm/include/asm/arch-tegra/clock.h |   9 +-
>  arch/arm/mach-tegra/Kconfig |   2 +
>  arch/arm/mach-tegra/clock.c |  17 +++-
>  arch/arm/mach-tegra/cpu.c   |  70 ++---
>  arch/arm/mach-tegra/tegra114/clock.c|  13 +--
>  arch/arm/mach-tegra/tegra124/clock.c|  13 +--
>  arch/arm/mach-tegra/tegra20/clock.c |   4 +-
>  arch/arm/mach-tegra/tegra210/clock.c|  22 +
>  arch/arm/mach-tegra/tegra30/clock.c |  10 +-
>  drivers/timer/Kconfig   |   8 ++
>  drivers/timer/Makefile  |   1 +
>  drivers/timer/tegra-timer.c | 126 
>  drivers/usb/host/ehci-tegra.c   |  46 +++--
>  include/configs/tegra-common.h  |   6 --
>  15 files changed, 269 insertions(+), 79 deletions(-)
>  create mode 100644 drivers/timer/tegra-timer.c
> 
> -- 
> 2.37.2
> 


signature.asc
Description: PGP signature


Re: [PATCH] bootstd: Replicate the dtb-filename quirks of distroboot

2023-01-25 Thread Tom Rini
On Wed, Jan 25, 2023 at 04:38:53PM +0100, Heinrich Schuchardt wrote:
> On 1/25/23 04:11, Simon Glass wrote:
> > For EFI, the distro boot scripts search in three different directories
> > for the .dtb file. The SOC-based filename fallback is supported only for
> > 32-bit ARM.
> > 
> > Adjust the code to mirror this behaviour.
> > 
> > Signed-off-by: Simon Glass 
> > Suggested-by: Mark Kettenis 
> > ---
> > 
> >   boot/bootmeth_efi.c | 63 ++---
> >   1 file changed, 54 insertions(+), 9 deletions(-)
> > 
> > diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c
> > index 67c972e3fe4..f9544846e68 100644
> > --- a/boot/bootmeth_efi.c
> > +++ b/boot/bootmeth_efi.c
> > @@ -147,25 +147,57 @@ static int distro_efi_check(struct udevice *dev, 
> > struct bootflow_iter *iter)
> > return 0;
> >   }
> > -static void distro_efi_get_fdt_name(char *fname, int size)
> > +/**
> > + * distro_efi_get_fdt_name() - Get the filename for reading the .dtb file
> > + *
> > + * @fname: Place to put filename
> > + * @size: Max size of filename
> > + * @seq: Sequence number, to cycle through options (0=first)
> > + * Returns: 0 on success, -ENOENT if the "fdtfile" env var does not exist,
> > + * -EINVAL if there are no more options
> > + */
> > +static int distro_efi_get_fdt_name(char *fname, int size, int seq)
> >   {
> > const char *fdt_fname;
> > +   const char *prefix;
> > +
> > +   /* select the prefix */
> > +   switch (seq) {
> > +   case 0:
> > +   /* this is the default */
> > +   prefix = "/dtb";
> > +   break;
> > +   case 1:
> > +   prefix = "";
> > +   break;
> > +   case 2:
> > +   prefix = "/dtb/current";
> > +   break;
> > +   default:
> > +   return log_msg_ret("pref", -EINVAL);
> > +   }
> > fdt_fname = env_get("fdtfile");
> > if (fdt_fname) {
> > -   snprintf(fname, size, "dtb/%s", fdt_fname);
> > +   snprintf(fname, size, "%s/%s", prefix, fdt_fname);
> > log_debug("Using device tree: %s\n", fname);
> > -   } else {
> > +
> > +   /* Use this fallback only for 32-bit ARM */
> > +   } else if (IS_ENABLED(CONFIG_ARM) && !IS_ENABLED(CONFIG_ARM64)) {
> > const char *soc = env_get("soc");
> > const char *board = env_get("board");
> > const char *boardver = env_get("boardver");
> > /* cf the code in label_boot() which seems very complex */
> > -   snprintf(fname, size, "dtb/%s%s%s%s.dtb",
> > +   snprintf(fname, size, "%s/%s%s%s%s.dtb", prefix,
> >  soc ? soc : "", soc ? "-" : "", board ? board : "",
> >  boardver ? boardver : "");
> > log_debug("Using default device tree: %s\n", fname);
> > +   } else {
> > +   return log_msg_ret("env", -ENOENT);
> > }
> > +
> > +   return 0;
> >   }
> >   static int distro_efi_read_bootflow_file(struct udevice *dev,
> > @@ -174,7 +206,7 @@ static int distro_efi_read_bootflow_file(struct udevice 
> > *dev,
> > struct blk_desc *desc = NULL;
> > ulong fdt_addr, size;
> > char fname[256];
> > -   int ret;
> > +   int ret, seq;
> > /* We require a partition table */
> > if (!bflow->part)
> > @@ -196,13 +228,22 @@ static int distro_efi_read_bootflow_file(struct 
> > udevice *dev,
> > if (ret)
> > return log_msg_ret("read", -EINVAL);
> > -   distro_efi_get_fdt_name(fname, sizeof(fname));
> > +   fdt_addr = env_get_hex("fdt_addr_r", 0);
> > +
> > +   /* try the various available names */
> > +   ret = -ENOENT;
> > +   for (seq = 0; ret; seq++)
> 
> There are boards that don't have a dtb file available and that is ok. Don't
> loop past seq = 2.
> 
> {
> > +   ret = distro_efi_get_fdt_name(fname, sizeof(fname), seq);
> > +   if (ret)
> > +   return log_msg_ret("nam", ret);
> > +   ret = bootmeth_common_read_file(dev, bflow, fname, fdt_addr,
> > +   &size);
> > +   }
> > +
> > bflow->fdt_fname = strdup(fname);
> > if (!bflow->fdt_fname)
> > return log_msg_ret("fil", -ENOMEM);
> 
> This should not be an error. The Distroboot fallback is the device-tree at
> $fdtcontroladdr.

But it should note that it's using that because that's still quite often
an unexpected feature to people.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver

2023-01-25 Thread Rob Herring
On Tue, Jan 24, 2023 at 9:56 AM Abdellatif El Khlifi
 wrote:
>
> On Mon, Jan 23, 2023 at 09:32:28AM -0700, Simon Glass wrote:
> > Hi Rob,
> >
> > On Mon, 23 Jan 2023 at 08:13, Rob Herring  wrote:
> > >
> > > On Fri, Jan 20, 2023 at 4:04 PM Simon Glass  wrote:
> > > >
> > > > Hi Rob,
> > > >
> > > > On Thu, 19 Jan 2023 at 11:11, Rob Herring  wrote:
> > > > >
> > > > > On Thu, Jan 19, 2023 at 10:41 AM Simon Glass  
> > > > > wrote:
> > > > > >
> > > > > > Hi Abdellatif,
> > > > > >
> > > > > > On Thu, 19 Jan 2023 at 09:32, Abdellatif El Khlifi
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Wed, Jan 18, 2023 at 08:59:32AM -0500, Tom Rini wrote:
> > > > > > > > On Wed, Jan 18, 2023 at 01:46:54PM +, Sudeep Holla wrote:
> > > > > > > > > On Wed, Jan 18, 2023 at 12:49 PM Tom Rini 
> > > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I guess the problem comes down to, can we have one 
> > > > > > > > > > discovery method that
> > > > > > > > > > everyone shares, or do we have to let everyone invent a new 
> > > > > > > > > > discovery
> > > > > > > > > > method every time?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > No one needs to invent any discovery method every time if the 
> > > > > > > > > firmware
> > > > > > > > > specification
> > > > > > > > > provides one and as Rob mentioned many times in the thread, 
> > > > > > > > > all new firmware
> > > > > > > > > specification must provide one and we are trying to make sure 
> > > > > > > > > that is
> > > > > > > > > the case with all new
> > > > > > > > > specs from Arm.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > FF-A, Op-tee, U-Boot, coreboot, barebox (and
> > > > > > > > > > everyone else I'm unintentionally forgetting) could just 
> > > > > > > > > > discover these
> > > > > > > > > > things via device tree.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I leave that to the individual projects to decide and agree 
> > > > > > > > > but
> > > > > > > > > fundamentally if
> > > > > > > > > the specification provides a way to discover, not sure why we 
> > > > > > > > > are even
> > > > > > > > > discussing
> > > > > > > > > an alternative method here.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > Or, we could all write our own code to perform
> > > > > > > > > > the discovery.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > For what reason ? I can understand if there is no discovery 
> > > > > > > > > mechanism but
> > > > > > > > > that's not the
> > > > > > > > > case in $subject.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > And when RISC-V comes along with similar functionality,
> > > > > > > > > > we could probe their device tree and see they've 
> > > > > > > > > > implemented the same
> > > > > > > > > > concept, but a little differently, but still have the 
> > > > > > > > > > discovery portion
> > > > > > > > > > be in the device tree. To which it sounds like your answer 
> > > > > > > > > > is "not in
> > > > > > > > > > the device tree".
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I see U-boot seem to have made a decision to create DT node 
> > > > > > > > > for each and
> > > > > > > > > everything
> > > > > > > > > that needs to be added to DM which seems bit unfortunate but 
> > > > > > > > > I don't
> > > > > > > > > understand the
> > > > > > > > > history/motive/background for it but I respect the decision 
> > > > > > > > > if it is
> > > > > > > > > already made.
> > > > > > > > >
> > > > > > > > > These firmware interfaces are standard on all Arm platforms 
> > > > > > > > > and can be
> > > > > > > > > discovered
> > > > > > > > > based on PSCI/SMCCC. Not using the same and use DT node needs 
> > > > > > > > > unnecessary
> > > > > > > > > addition of DT nodes for all the f/w i/f on all the platforms 
> > > > > > > > > that need the
> > > > > > > > > support when
> > > > > > > > > one can be just discovered.
> > > > > > > > >
> > > > > > > > > Sorry for the sudden appearance on this thread, I was 
> > > > > > > > > avoiding getting into
> > > > > > > > > this but thought
> > > > > > > > > I will at least express my opinion and also the way the 
> > > > > > > > > firmware
> > > > > > > > > specifications from Arm is
> > > > > > > > > expected to be evolved from now on. With that I will leave it 
> > > > > > > > > to you and
> > > > > > > > > other U-boot
> > > > > > > > > maintainers and the community in general to decide the right 
> > > > > > > > > course in this
> > > > > > > > > case.
> > > > > > > >
> > > > > > > > To be clear, if the position is that "this is what everyone 
> > > > > > > > else will
> > > > > > > > use, really" then yes, we'll follow this in U-Boot.
> > > > > > >
> > > > > > > Hi Simon, Tom,
> > > > > > >
> > > > > > > The FF-A transport is a SW bus and is not associated to any HW 
> > > > > > > peripheral or
> > > > > > > undiscoverable base address.
> > > > > > >
> > > > > > > There is only 1 way of discoverin

Re: [PATCH 1/7] board: rockchip: Add rk3588 evb board support

2023-01-25 Thread Jagan Teki
On Wed, 25 Jan 2023 at 21:14, "瘦橘猫" <19983723...@189.cn> wrote:
>
> Hi
>
> The board configuration file for the rk3588 evb does not contain atf, or even 
> tpl and spl. What I am going to do now is add some configuration items for 
> rk3588s based on rk3588, if successful, to verify that the ATF is available. 
> Thank  you for your comments

For your information, ATF can be part of rkbin and export BL31 in
u-boot in order to build as part of it. are you checking this step?

Jagan.


  1   2   >