date:20230718

On devices with multiple USB mass storage devices errors like

Path /../USB(0x0,0x0)/USB(0x1,0x0)/Ctrl(0x0)
already installed.

are seen. This is due to creating non-unique device paths. To uniquely
identify devices we must provide path nodes for all devices on the path
from the root device.

Add support for generating device path nodes for all uclasses.

Reported-by: Suniel Mahesh 
Signed-off-by: Heinrich Schuchardt 
---
 include/efi_api.h|  7 
 lib/efi_loader/efi_device_path.c | 56 ++--
 2 files changed, 32 insertions(+), 31 deletions(-)

diff --git a/include/efi_api.h b/include/efi_api.h
index 55a4c989fc..8f5ef5f680 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -579,6 +579,13 @@ struct efi_device_path_vendor {
u8 vendor_data[];
 } __packed;
 
+struct efi_device_path_udevice {
+   struct efi_device_path dp;
+   efi_guid_t guid;
+   int uclass_id;
+   int dev_number;
+} __packed;
+
 struct efi_device_path_controller {
struct efi_device_path dp;
u32 controller_number;
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index 04ebb449ca..d0be869d94 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -38,16 +39,6 @@ const struct efi_device_path END = {
.length   = sizeof(END),
 };
 
-/* template ROOT node: */
-static const struct efi_device_path_vendor ROOT = {
-   .dp = {
-   .type = DEVICE_PATH_TYPE_HARDWARE_DEVICE,
-   .sub_type = DEVICE_PATH_SUB_TYPE_VENDOR,
-   .length   = sizeof(ROOT),
-   },
-   .guid = U_BOOT_GUID,
-};
-
 #if defined(CONFIG_MMC)
 /*
  * Determine if an MMC device is an SD card.
@@ -497,13 +488,12 @@ bool efi_dp_is_multi_instance(const struct 
efi_device_path *dp)
 __maybe_unused static unsigned int dp_size(struct udevice *dev)
 {
if (!dev || !dev->driver)
-   return sizeof(ROOT);
+   return sizeof(struct efi_device_path_udevice);
 
switch (device_get_uclass_id(dev)) {
case UCLASS_ROOT:
-   case UCLASS_SIMPLE_BUS:
/* stop traversing parents at this point: */
-   return sizeof(ROOT);
+   return sizeof(struct efi_device_path_udevice);
case UCLASS_ETH:
return dp_size(dev->parent) +
sizeof(struct efi_device_path_mac_addr);
@@ -582,8 +572,8 @@ __maybe_unused static unsigned int dp_size(struct udevice 
*dev)
return dp_size(dev->parent) +
sizeof(struct efi_device_path_usb);
default:
-   /* just skip over unknown classes: */
-   return dp_size(dev->parent);
+   return dp_size(dev->parent) +
+   sizeof(struct efi_device_path_udevice);
}
 }
 
@@ -600,13 +590,6 @@ __maybe_unused static void *dp_fill(void *buf, struct 
udevice *dev)
return buf;
 
switch (device_get_uclass_id(dev)) {
-   case UCLASS_ROOT:
-   case UCLASS_SIMPLE_BUS: {
-   /* stop traversing parents at this point: */
-   struct efi_device_path_vendor *vdp = buf;
-   *vdp = ROOT;
-   return &vdp[1];
-   }
 #ifdef CONFIG_NETDEVICES
case UCLASS_ETH: {
struct efi_device_path_mac_addr *dp =
@@ -811,11 +794,24 @@ __maybe_unused static void *dp_fill(void *buf, struct 
udevice *dev)
 
return &udp[1];
}
-   default:
-   /* If the uclass driver is missing, this will show NULL */
-   log_debug("unhandled device class: %s (%s)\n", dev->name,
- dev_get_uclass_name(dev));
-   return dp_fill(buf, dev->parent);
+   default: {
+   struct efi_device_path_udevice *vdp;
+   enum uclass_id uclass_id = device_get_uclass_id(dev);
+
+   if (uclass_id == UCLASS_ROOT)
+   vdp = buf;
+   else
+   vdp = dp_fill(buf, dev->parent);
+
+   vdp->dp.type = DEVICE_PATH_TYPE_HARDWARE_DEVICE;
+   vdp->dp.sub_type = DEVICE_PATH_SUB_TYPE_VENDOR;
+   vdp->dp.length = sizeof(*vdp);
+   memcpy(&vdp->guid, &efi_u_boot_guid, sizeof(efi_guid_t));
+   vdp->uclass_id = uclass_id;
+   vdp->dev_number = dev->seq_;
+
+   return &vdp[1];
+   }
}
 }
 
@@ -1052,14 +1048,12 @@ struct efi_device_path *efi_dp_from_uart(void)
 {
void *buf, *pos;
struct efi_device_path_uart *uart;
-   size_t dpsize = sizeof(ROOT) + sizeof(*uart) + sizeof(END);
+   size_t dpsize = dp_size(dm_root()) + sizeof(*uart) + sizeof(END);
 
buf = efi_alloc(dpsize);
if (!buf)
return NULL;
-   pos = buf;
-

Re: [PATCH] menu: Ignore prompt variable if timeout is != 0

2023-07-18 Thread FUKAUMI Naoki


hi,

thank you for your reply!

On 7/18/23 23:08, Jonas Karlman wrote:

On 2023-07-14 09:36, FUKAUMI Naoki wrote:

From: Manuel Traut 

Since 739e8361f3fe78038251216df6096a32bc2d5839, a system with the following
/boot/extlinux/extlinux.conf (which sets timeout to 50) immediately boots the
first entry in the config without displaying a boot menu.  According to the
description, that should only happen if both prompt and timeout are set to zero
in the config, but it also happens with timeout set to a non-zero value.

Reported-by: Karsten Merker 
Signed-off-by: Manuel Traut 
---
  common/menu.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/common/menu.c b/common/menu.c
index 8fe00965c0..8eab87 100644
--- a/common/menu.c
+++ b/common/menu.c
@@ -277,6 +277,9 @@ int menu_get_choice(struct menu *m, void **choice)
if (!m->item_cnt)
return -ENOENT;
  
+	if (m->timeout)

+   return menu_interactive_choice(m, choice);


This should not be needed, if the user wants to prompt the menu there is
the PROMPT keyword that can be used in extlinux.conf, e.g.:

   PROMPT 1
   TIMEOUT 50

See https://wiki.archlinux.org/title/Syslinux#Boot_prompt

That should set pxe cfg->prompt = 1 and that in turn menu m->prompt = 1.


 https://source.denx.de/u-boot/u-boot/-/blob/master/common/menu.c#L346-351

this description is unclear for me if (timeout > 0) && (prompt == 0)

Best regards,

--
FUKAUMI Naoki
Radxa


Regards,
Jonas


+
if (!m->prompt)
return menu_default_choice(m, choice);

Re: [PATCH v2 1/5] rockchip: Support OP-TEE for ARM in FIT images created by binman

2023-07-18 Thread Kever Yang




On 2023/7/18 22:57, Alex Bee wrote:

CONFIG_SPL_OPTEE_IMAGE option is used during DRAM size detection for
Rockchip ARM platform to indicate that an OP-TEE binary was already loaded
and a Trusted Execution Environment (TEE) is available in order to
block/reserve a memory-region for it.

This adds a bunch of new `#if's` to u-boot-rockchip.dtsi to include the
OP-TEE binary in the FIT image for ARM SOCs if CONFIG_SPL_OPTEE_IMAGE is
selected.
That makes it a little harder to read, but I opted for that, because all
the duplicates in an extra ARM-OP-TEE-specfic .dtsi would be the greater
evil, IMHO. Besides it's more likley being "forgotten" to sync when changes
in u-boot-rockchip.dtsi are made.

The no longer required rockchip-optee.dtsi and it's inclusions are dropped.

The hardcoded load address is common across all OP-TEE implemenations for
Rockchip (vendor and upstream).

The OP-TEE-binary is non-optional if CONFIG_SPL_OPTEE_IMAGE is selected and
there will be an error if the file does not exist and/or `TEE=` build
option is missing.

Signed-off-by: Alex Bee 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/rk3288-u-boot.dtsi   |  1 -
  arch/arm/dts/rockchip-optee.dtsi  | 64 ---
  arch/arm/dts/rockchip-u-boot.dtsi | 38 --
  3 files changed, 35 insertions(+), 68 deletions(-)
  delete mode 100644 arch/arm/dts/rockchip-optee.dtsi

diff --git a/arch/arm/dts/rk3288-u-boot.dtsi b/arch/arm/dts/rk3288-u-boot.dtsi
index 1920698884..c4c5a2d225 100644
--- a/arch/arm/dts/rk3288-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-u-boot.dtsi
@@ -4,7 +4,6 @@
   */
  
  #include "rockchip-u-boot.dtsi"

-#include "rockchip-optee.dtsi"
  
  / {

aliases {
diff --git a/arch/arm/dts/rockchip-optee.dtsi b/arch/arm/dts/rockchip-optee.dtsi
deleted file mode 100644
index d84c10cf43..00
--- a/arch/arm/dts/rockchip-optee.dtsi
+++ /dev/null
@@ -1,64 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright 2020 Google LLC
- */
-
-#include 
-
-#if defined(CONFIG_HAS_ROM) && defined(CONFIG_FIT)
-&binman {
-   itb {
-   filename = "u-boot.itb";
-   fit {
-   fit,external-offset = ;
-   description = "FIT image with OP-TEE support";
-   #address-cells = <1>;
-
-   images {
-   uboot {
-   description = "U-Boot";
-   type = "standalone";
-   os = "U-Boot";
-   arch = "arm";
-   compression = "none";
-   load = ;
-
-   u-boot-nodtb {
-   };
-   };
-   optee {
-   description = "OP-TEE";
-   type = "firmware";
-   arch = "arm";
-   os = "tee";
-   compression = "none";
-   load = <(CFG_SYS_SDRAM_BASE + 
0x840)>;
-   entry = <(CFG_SYS_SDRAM_BASE + 
0x840)>;
-
-   blob-ext {
-   filename = "tee.bin";
-   };
-   };
-   fdt {
-   description = CONFIG_SYS_BOARD;
-   type = "flat_dt";
-   compression = "none";
-
-   u-boot-dtb {
-   };
-   };
-   };
-
-   configurations {
-   default = "conf";
-   conf {
-   description = CONFIG_SYS_BOARD;
-   firmware = "optee";
-   loadables = "uboot";
-   fdt = "fdt";
-   };
-   };
-   };
-   };
-};
-#endif
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi 
b/arch/arm/dts/rockchip-u-boot.dtsi
index 2878b80926..be2658e8ef 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -33,9 +33,13 @@
};
};
  
-#if defined(CONFIG_SPL_FIT) && defined(CONFIG_ARM64)

+#if defined(CONFIG_SPL_FIT) && (defined(CONFIG_ARM64) || 
defined(CONFIG_SPL_OPTEE_IMAGE))
fit: fit {
+#ifdef CONFIG_ARM64
description = "FIT image for U-Boot with bl31 (TF-A)";
+#else

Re: EFI breaks USB dual port detection - our observations


On 7/19/23 02:55, Da Xue wrote:

On Tue, Jul 18, 2023 at 3:13 PM Heinrich Schuchardt mailto:xypron.g...@gmx.de>> wrote:



Am 18. Juli 2023 20:37:04 MESZ schrieb Suniel Mahesh
mailto:su...@amarulasolutions.com>>:
 >Hi,
 >
 >I am testing the USB infrastructure on a Rockchip RK3328 based
 >roc-rk3328-cc target.
 >
 >The USB tree on the device is as follows:
 >
 >=> usb tree
 >USB device tree:
 >  1  Hub (480 Mb/s, 0mA)
 >     u-boot EHCI Host Controller
 >
 >  1  Hub (12 Mb/s, 0mA)
 >      U-Boot Root Hub   (OHCI)
 >
 >  1  Hub (5 Gb/s, 0mA)
 >     U-Boot XHCI Host Controller
 >
 >  1  Hub (480 Mb/s, 0mA)
 >      U-Boot Root Hub (DWC2)
 >
 >For some reason I am unable to detect storage device on DWC2 when
two USB
 >drives
 >are simultaneously connected on EHCI and DWC2. Though it shows 2
storage
 >devices
 >when i do a "usb start/reset" and it gives usb_mass_storage.lun0
failed
 >message as
 >shown below.

On which U-Boot version are you?


This is replicated on v2023.07.


We need to model the UCLASS_USB device in the EFI device path to make
the device paths of the two USB sticks unique.

Best regards

Heinrich




Cf.
https://github.com/trini/u-boot/commit/180b7118bed8433f9cfe4b5ad62c6b0d901924f5 


Best regards

Heinrich



 >
 >=> usb start
 >starting USB...
 >Bus usb@ff5c: USB EHCI 1.00
 >Bus usb@ff5d: USB OHCI 1.0
 >Bus usb@ff60: generic_phy_get_bulk : no phys property
 >Register 2000140 NbrPorts 2
 >Starting the controller
 >USB XHCI 1.10
 >Bus usb@ff58: USB DWC2
 >scanning bus usb@ff5c for devices...
 >2 USB Device(s) found
 >scanning bus usb@ff5d for devices... 1 USB Device(s) found
 >scanning bus usb@ff60 for devices... 1 USB Device(s) found
 >scanning bus usb@ff58 for devices...
 >Adding disk for usb_mass_storage.lun0 failed
 >(err=-9223372036854775788/0x8014)
 >device 'usb_mass_storage.lun0' failed to unbind
 >1 USB Device(s) found
 >device 'usb_mass_storage.lun0' failed to unbind
 >       scanning usb for storage devices... 2 Storage Device(s) found
 >
 >=> usb tree
 >USB device tree:
 >  1  Hub (480 Mb/s, 0mA)
 >  |  u-boot EHCI Host Controller
 >  |
 >  +-2  Mass Storage (480 Mb/s, 224mA)
 >       SanDisk Dual Drive 040130e3ee554b7078843f4eb331646
 >
 >  1  Hub (12 Mb/s, 0mA)
 >      U-Boot Root Hub
 >
 >  1  Hub (5 Gb/s, 0mA)
 >     U-Boot XHCI Host Controller
 >
 >  1  Hub (480 Mb/s, 0mA)
 >      U-Boot Root Hub
 >
 >call trace: (detailed log:
 >https://gist.github.com/sunielmahesh/10088ea7b536cc9898ef787d9db43721 
)
 >
 >efi_install_multiple_protocol_interfaces_int
 >device path
 
>/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x0,0x0)/USB(0x1,0x0)/Ctrl(0x0)
 >09576e91-6d3f-11d2-8e39-00a0c969723b, fcf1bae8,
 >fcf1bae0efi_locate_device_path: ret = EFI_SUCCESS
 >efi_install_multiple_protocol_interfaces_int: ret=0, dp->type:7f
 >Path
 
>/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x0,0x0)/USB(0x1,0x0)/Ctrl(0x0)
 >already installed
 >install failed 8014
 >
 >However, an interesting observation is that if i disable
CONFIG_EFI_LOADER,
 >then I am able to detect the storage devices
 >without any usb_mass_storage.lun0 failed message:
 >
 >=> usb reset
 >resetting USB...
 >Bus usb@ff5c: USB EHCI 1.00
 >Bus usb@ff5d: USB OHCI 1.0
 >Bus usb@ff60: generic_phy_get_bulk : no phys property
 >Register 2000140 NbrPorts 2
 >Starting the controller
 >USB XHCI 1.10
 >Bus usb@ff58: USB DWC2
 >scanning bus usb@ff5c for devices... 2 USB Device(s) found
 >scanning bus usb@ff5d for devices... 1 USB Device(s) found
 >scanning bus usb@ff60 for devices... 1 USB Device(s) found
 >scanning bus usb@ff58 for devices... 2 USB Device(s) found
 >       scanning usb for storage devices... 2 Storage Device(s) found
 >=> usb tree
 >USB device tree:
 >  1  Hub (480 Mb/s, 0mA)
 >  |  u-boot EHCI Host Controller
 >  |
 >  +-2  Mass Storage (480 Mb/s, 224mA)
 >       SanDisk Dual Drive 040130e3ee554b7078843f4eb331646
 >
 >  1  Hub (12 Mb/s, 0mA)
 >      U-Boot Root Hub
 >
 >  1  Hub (5 Gb/s, 0mA)
 >     U-Boot XHCI Host Controller
 >
 >  1  Hub (480 Mb/s, 0mA)
 >  |   U-Boot Root Hub
 >  |
 >  +-2  Mass Storage (480 Mb/s, 224mA)
 >       SanDisk Dual Drive 04019c9b2e1a58f24ee318c3c123aa5
 >
 >Please share you thoughts.
 >
 >Thanks and Regards

Re: [PATCH 1/1] part: eliminate part_get_info_by_name_type()





On 7/19/23 03:08, Simon Glass wrote:

Hi Heinrich,

On Sun, 16 Jul 2023 at 05:34, Heinrich Schuchardt
 wrote:


Since commit 56670d6fb83f ("disk: part: use common api to lookup part
driver") part_get_info_by_name_type() ignores the part_type parameter
used to restrict the partition table type.

omap_mmc_get_part_size() and part_get_info_by_name() are the only
consumers.

omap_mmc_get_part_size() calls with part_type = PART_TYPE_EFI because at
the time of implementation a speed up could be gained by passing the
partition table type. After 5 years experience without this restriction
it looks safe to keep it that way.

part_get_info_by_name() uses PART_TYPE_ALL.

Move the logic of part_get_info_by_name_type() to part_get_info_by_name()
and replace the function in omap_mmc_get_part_size().

Fixes: 56670d6fb83f ("disk: part: use common api to lookup part driver")
Signed-off-by: Heinrich Schuchardt 
---
  arch/arm/mach-omap2/utils.c |  3 +--
  disk/part.c | 10 ++
  include/part.h  | 23 ---
  3 files changed, 3 insertions(+), 33 deletions(-)


That explains the strange behaviour I saw when fiddling with this a
month or so back, thanks.

Reviewed-by: Simon Glass 

Is there a test to update for this?


Thanks for reviewing.

As we don't change any existing behavior there is no test to update.

Best regards

Heinrich

Re: [RFC] efi_driver: fix a parent issue in efi-created block devices


On 7/19/23 03:08, Simon Glass wrote:

Hi AKASHI,

On Tue, 18 Jul 2023 at 18:22, AKASHI Takahiro
 wrote:


An EFI application may create an EFI block device (EFI_BLOCK_IO_PROTOCOL) in
EFI world, which in turn generates a corresponding U-Boot block device based on
U-Boot's Driver Model.
The latter device, however, doesn't work as U-Boot proper block device
due to an issue in efi_driver's implementation. We saw discussions in the past,
most recently in [1].

   [1] https://lists.denx.de/pipermail/u-boot/2023-July/522565.html

This RFC patch tries to address (part of) the issue.
If it is considered acceptable, I will create a formal patch.

Withtout this patch,
===8<===
=> env set efi_selftest 'block device'
=> bootefi selftest
  ...

Summary: 0 failures

=> dm tree
  Class Index  Probed  DriverName
---
  root  0  [ + ]   root_driver   root_driver
  ...
  bootmeth  7  [   ]   vbe_simple|   `-- vbe_simple
  blk   0  [ + ]   efi_blk   `-- efiblk#0
  partition 0  [ + ]   blk_partition `-- efiblk#0:1
=> ls efiloader 0:1
** Bad device specification efiloader 0 **
Couldn't find partition efiloader 0:1
===>8===

With this patch applied, efiblk#0(:1) now gets accessible.

===8<===
=> env set efi_selftest 'block device'
=> bootefi selftest
  ...

Summary: 0 failures

=> dm tree
  Class Index  Probed  DriverName
---
  root  0  [ + ]   root_driver   root_driver
  ...
  bootmeth  7  [   ]   vbe_simple|   `-- vbe_simple
  efi   0  [ + ]   EFI block driver  `-- 
/VenHw(dbca4c98-6cb0-694d-0872-819c650cb7b8)
  blk   0  [ + ]   efi_blk   `-- efiblk#0
  partition 0  [ + ]   blk_partition `-- efiblk#0:1
=> ls efiloader 0:1
13   hello.txt
 7   u-boot.txt

2 file(s), 0 dir(s)
===>8===

Signed-off-by: AKASHI Takahiro 
---
  include/efi_driver.h |  2 +-
  lib/efi_driver/efi_block_device.c| 17 -
  lib/efi_driver/efi_uclass.c  |  8 +++-
  lib/efi_selftest/efi_selftest_block_device.c |  2 ++
  4 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/include/efi_driver.h b/include/efi_driver.h
index 63a95e4cf800..ed66796f3519 100644
--- a/include/efi_driver.h
+++ b/include/efi_driver.h
@@ -42,7 +42,7 @@ struct efi_driver_ops {
 const efi_guid_t *child_protocol;
 efi_status_t (*init)(struct efi_driver_binding_extended_protocol 
*this);
 efi_status_t (*bind)(struct efi_driver_binding_extended_protocol *this,
-efi_handle_t handle, void *interface);
+efi_handle_t handle, void *interface, char *name);
  };

  #endif /* _EFI_DRIVER_H */
diff --git a/lib/efi_driver/efi_block_device.c 
b/lib/efi_driver/efi_block_device.c
index add00eeebbea..43b7ed7c973c 100644
--- a/lib/efi_driver/efi_block_device.c
+++ b/lib/efi_driver/efi_block_device.c
@@ -115,9 +115,9 @@ static ulong efi_bl_write(struct udevice *dev, lbaint_t 
blknr, lbaint_t blkcnt,
   * Return: status code
   */
  static efi_status_t
-efi_bl_create_block_device(efi_handle_t handle, void *interface)
+efi_bl_create_block_device(efi_handle_t handle, void *interface, struct 
udevice *parent)
  {
-   struct udevice *bdev = NULL, *parent = dm_root();
+   struct udevice *bdev = NULL;
 efi_status_t ret;
 int devnum;
 char *name;
@@ -181,7 +181,7 @@ err:
   */
  static efi_status_t efi_bl_bind(
 struct efi_driver_binding_extended_protocol *this,
-   efi_handle_t handle, void *interface)
+   efi_handle_t handle, void *interface, char *name)
  {
 efi_status_t ret = EFI_SUCCESS;
 struct efi_object *obj = efi_search_obj(handle);
@@ -191,8 +191,15 @@ static efi_status_t efi_bl_bind(
 if (!obj || !interface)
 return EFI_INVALID_PARAMETER;

-   if (!handle->dev)
-   ret = efi_bl_create_block_device(handle, interface);
+   if (!handle->dev) {
+   struct udevice *parent;
+
+   ret = device_bind_driver(dm_root(), "EFI block driver", name, 
&parent);


Can you use a non-root device as the parent?


The parent of an iSCSI drive handled by iPXE will be a network
interface. For a RAM drive there will be no physical parent at all.

The design bug is in blk_get_devnum_by_uclass_idname() which instead of
looking at blk_desc->uclass_id looks at the parent.

When will you fix this Simon?

Best regards

Heinrich




+   if (!ret)
+   ret = efi_bl_create_block_device(handle, interface, 
parent);
+   else
+   ret = EFI_DEVICE_ERROR;
+   }

 return ret;
  }
diff --git a/lib/efi_driver/efi_u

Re: [RFC] efi_driver: fix a parent issue in efi-created block devices

2023-07-18 Thread AKASHI Takahiro

Hi Simon,

On Tue, Jul 18, 2023 at 07:08:45PM -0600, Simon Glass wrote:
> Hi AKASHI,
> 
> On Tue, 18 Jul 2023 at 18:22, AKASHI Takahiro
>  wrote:
> >
> > An EFI application may create an EFI block device (EFI_BLOCK_IO_PROTOCOL) in
> > EFI world, which in turn generates a corresponding U-Boot block device 
> > based on
> > U-Boot's Driver Model.
> > The latter device, however, doesn't work as U-Boot proper block device
> > due to an issue in efi_driver's implementation. We saw discussions in the 
> > past,
> > most recently in [1].
> >
> >   [1] https://lists.denx.de/pipermail/u-boot/2023-July/522565.html
> >
> > This RFC patch tries to address (part of) the issue.
> > If it is considered acceptable, I will create a formal patch.
> >
> > Withtout this patch,
> > ===8<===
> > => env set efi_selftest 'block device'
> > => bootefi selftest
> >  ...
> >
> > Summary: 0 failures
> >
> > => dm tree
> >  Class Index  Probed  DriverName
> > ---
> >  root  0  [ + ]   root_driver   root_driver
> >  ...
> >  bootmeth  7  [   ]   vbe_simple|   `-- vbe_simple
> >  blk   0  [ + ]   efi_blk   `-- efiblk#0
> >  partition 0  [ + ]   blk_partition `-- efiblk#0:1
> > => ls efiloader 0:1
> > ** Bad device specification efiloader 0 **
> > Couldn't find partition efiloader 0:1
> > ===>8===
> >
> > With this patch applied, efiblk#0(:1) now gets accessible.
> >
> > ===8<===
> > => env set efi_selftest 'block device'
> > => bootefi selftest
> >  ...
> >
> > Summary: 0 failures
> >
> > => dm tree
> >  Class Index  Probed  DriverName
> > ---
> >  root  0  [ + ]   root_driver   root_driver
> >  ...
> >  bootmeth  7  [   ]   vbe_simple|   `-- vbe_simple
> >  efi   0  [ + ]   EFI block driver  `-- 
> > /VenHw(dbca4c98-6cb0-694d-0872-819c650cb7b8)
> >  blk   0  [ + ]   efi_blk   `-- efiblk#0
> >  partition 0  [ + ]   blk_partition `-- efiblk#0:1
> > => ls efiloader 0:1
> >13   hello.txt
> > 7   u-boot.txt
> >
> > 2 file(s), 0 dir(s)
> > ===>8===
> >
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  include/efi_driver.h |  2 +-
> >  lib/efi_driver/efi_block_device.c| 17 -
> >  lib/efi_driver/efi_uclass.c  |  8 +++-
> >  lib/efi_selftest/efi_selftest_block_device.c |  2 ++
> >  4 files changed, 22 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/efi_driver.h b/include/efi_driver.h
> > index 63a95e4cf800..ed66796f3519 100644
> > --- a/include/efi_driver.h
> > +++ b/include/efi_driver.h
> > @@ -42,7 +42,7 @@ struct efi_driver_ops {
> > const efi_guid_t *child_protocol;
> > efi_status_t (*init)(struct efi_driver_binding_extended_protocol 
> > *this);
> > efi_status_t (*bind)(struct efi_driver_binding_extended_protocol 
> > *this,
> > -efi_handle_t handle, void *interface);
> > +efi_handle_t handle, void *interface, char 
> > *name);
> >  };
> >
> >  #endif /* _EFI_DRIVER_H */
> > diff --git a/lib/efi_driver/efi_block_device.c 
> > b/lib/efi_driver/efi_block_device.c
> > index add00eeebbea..43b7ed7c973c 100644
> > --- a/lib/efi_driver/efi_block_device.c
> > +++ b/lib/efi_driver/efi_block_device.c
> > @@ -115,9 +115,9 @@ static ulong efi_bl_write(struct udevice *dev, lbaint_t 
> > blknr, lbaint_t blkcnt,
> >   * Return: status code
> >   */
> >  static efi_status_t
> > -efi_bl_create_block_device(efi_handle_t handle, void *interface)
> > +efi_bl_create_block_device(efi_handle_t handle, void *interface, struct 
> > udevice *parent)
> >  {
> > -   struct udevice *bdev = NULL, *parent = dm_root();
> > +   struct udevice *bdev = NULL;
> > efi_status_t ret;
> > int devnum;
> > char *name;
> > @@ -181,7 +181,7 @@ err:
> >   */
> >  static efi_status_t efi_bl_bind(
> > struct efi_driver_binding_extended_protocol *this,
> > -   efi_handle_t handle, void *interface)
> > +   efi_handle_t handle, void *interface, char *name)
> >  {
> > efi_status_t ret = EFI_SUCCESS;
> > struct efi_object *obj = efi_search_obj(handle);
> > @@ -191,8 +191,15 @@ static efi_status_t efi_bl_bind(
> > if (!obj || !interface)
> > return EFI_INVALID_PARAMETER;
> >
> > -   if (!handle->dev)
> > -   ret = efi_bl_create_block_device(handle, interface);
> > +   if (!handle->dev) {
> > +   struct udevice *parent;
> > +
> > +   ret = device_bind_driver(dm_root(), "EFI block driver", 
> > name, &parent);
> 
> Can you use a non-root device as the parent?

I have no idea what else can be the parent in this case.

Please note:
> > =>

[PATCH] mxs: Kconfig: Remove TARGET_XFI3 symbol

2023-07-18 Thread Fabio Estevam

From: Fabio Estevam 

The xfi3 target has been removed by commit 539fba2c10e7 ("arm:
Remove xfi3 board"), but it missed to remove an entry from the
mxs Kconfig.

Remove it.

Signed-off-by: Fabio Estevam 
---
 arch/arm/mach-imx/mxs/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/mach-imx/mxs/Kconfig b/arch/arm/mach-imx/mxs/Kconfig
index d3233d8d14f3..ccce6a78caa2 100644
--- a/arch/arm/mach-imx/mxs/Kconfig
+++ b/arch/arm/mach-imx/mxs/Kconfig
@@ -18,9 +18,6 @@ config TARGET_MX23EVK
select PL01X_SERIAL
select BOARD_EARLY_INIT_F
 
-config TARGET_XFI3
-   bool "Support xfi3"
-
 endchoice
 
 config SYS_SOC
-- 
2.34.1

Re: [PATCH v2 3/7] binman: Report missing external blobs using error level

On Tue, 18 Jul 2023 at 14:34, Jonas Karlman  wrote:
>
> Print missing external blobs using error level and missing optional
> external blobs using warning level. Also change to only print the header
> line in color, red for missing and yellow for optional.
>
> Signed-off-by: Jonas Karlman 
> ---
> v2:
> - New patch
>
>  tools/binman/control.py | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)

Reviewed-by: Simon Glass

Re: [PATCH v6 2/3] binman: Allow cipher node as special section

On Mon, 17 Jul 2023 at 01:06,  wrote:
>
> From: Christian Taedcke 
>
> The new encrypted etype generates a cipher node in the device tree
> that should not be evaluated by binman, but still be kept in the
> output device tree.
>
> Signed-off-by: Christian Taedcke 
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - rebase on u-boot-dm/mkim-working
>
>  tools/binman/etype/section.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 

(don't forget to add review tags when sending out the next version -
"patman status" can collect these for you)

Re: [PATCH] arm: sunxi: Correct warning in board_fit_config_name_match

Hi Tom,

On Mon, 17 Jul 2023 at 13:29, Tom Rini  wrote:
>
> When building this with clang, we get a warning about having excess
> parenthesis here, or that we're incorrectly using "==" when we want "=".
> Correct these by using parenthesis around our multiplication of
> constants as this is what was likely intended originally, even if not
> strictly required.
>
> Signed-off-by: Tom Rini 
> ---
> Cc: Andre Przywara 
> ---
>  board/sunxi/board.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index f321cd58a6e6..643e8db185b4 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -957,7 +957,7 @@ int board_fit_config_name_match(const char *name)
>  #ifdef CONFIG_PINE64_DT_SELECTION
> if (strstr(best_dt_name, "-pine64-plus")) {
> /* Differentiate the Pine A64 boards by their DRAM size. */
> -   if ((gd->ram_size == 512 * 1024 * 1024))
> +   if (gd->ram_size == (512 * 1024 * 1024))

Reviewed-by: Simon Glass 

But I suggest:

if (gd->ram_size == 512 * 1024 * 1024)// or SZ_512M

since the extra brackets might confuse people about the operator precedence.

> best_dt_name = "sun50i-a64-pine64";
> }
>  #endif
> --
> 2.34.1
>

Regards,
Simon

Re: [PATCH 01/10] Makefile: Add support to generate GZIP compressed raw u-boot binary

Hi Manoj,

On Tue, 18 Jul 2023 at 01:13, Manoj Sai
 wrote:
>
> Hi Simon,
>
> Can you please suggest or briefly explain to me the steps to be
> followed to generate the compressed u-boot-nodtb.bin.gz and
> u-boot-nodtb.bin.lzma file  with the help of binman  ,
> when compression support is enabled . Can you provide me with any
> reference patch to get it done?

Yes, please see here:

https://u-boot.readthedocs.io/en/latest/develop/package/binman.html#compression

Regards,
Simon


>
> Thanks and regards,
> Manoj sai
> Amarula Solutions India Pvt. Ltd
>
> On Sun, Jul 2, 2023 at 9:04 PM Simon Glass  wrote:
> >
> > Hi Manoj,
> >
> > On Fri, 30 Jun 2023 at 13:12, Manoj Sai
> >  wrote:
> > >
> > > Add support for generating a GZIP-compressed raw U-boot binary.
> > >
> > > Signed-off-by: Manoj Sai 
> > > Signed-off-by: Suniel Mahesh 
> > > ---
> > >  Makefile | 3 +++
> > >  1 file changed, 3 insertions(+)
> >
> > Please can you use binman to do that?
> >
> > We are trying to remove the extra build rules in the Makefile.
> >
> > >
> > > diff --git a/Makefile b/Makefile
> > > index 444baaefd0..6e15ebd116 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -1312,6 +1312,9 @@ endif
> > >  u-boot-nodtb.bin: u-boot FORCE
> > > $(call if_changed,objcopy_uboot)
> > > $(BOARD_SIZE_CHECK)
> > > +ifeq ($(CONFIG_SPL_GZIP),y)
> > > +   @gzip -k u-boot-nodtb.bin
> > > +endif
> > >
> > >  u-boot.ldr:u-boot
> > > $(CREATE_LDR_ENV)
> > > --
> > > 2.25.1
> > >
> >
> > Regards,
> > Simon

Re: [PATCH 3/7] xes: Remove leftover code

On Tue, 18 Jul 2023 at 17:34, Tom Rini  wrote:
>
> The platforms here have been removed, but the common code directory was
> forgotten.  Clean up.
>
> Signed-off-by: Tom Rini 
> ---
>  board/xes/common/Makefile|  9 -
>  board/xes/common/board.c | 67 
>  board/xes/common/fsl_8xxx_clk.c  | 54 -
>  board/xes/common/fsl_8xxx_misc.c | 43 
>  board/xes/common/fsl_8xxx_misc.h | 11 --
>  5 files changed, 184 deletions(-)
>  delete mode 100644 board/xes/common/Makefile
>  delete mode 100644 board/xes/common/board.c
>  delete mode 100644 board/xes/common/fsl_8xxx_clk.c
>  delete mode 100644 board/xes/common/fsl_8xxx_misc.c
>  delete mode 100644 board/xes/common/fsl_8xxx_misc.h

Reviewed-by: Simon Glass

Re: [PATCH v3 00/11] Sign Xilinx ZynqMP SPL/FSBL boot images using binman

Hi,

On Tue, 18 Jul 2023 at 05:53,  wrote:
>
> From: Lukas Funke 
>
>
> This series adds two etypes to create a verified boot chain for
> Xilinx ZynqMP devices. The first etype 'xilinx-fsbl-auth' is used to
> create a bootable, signed image for ZynqMP boards using the Xilinx
> Bootgen tool. The second etype 'u-boot-spl-pubkey-dtb' is used to add
> a '/signature' node to the SPL. The public key in the signature is read
> from a certificate file and added using the 'fdt_add_pubkey' tool. The
> series also contains the corresponding btool for calling 'bootgen' and
> 'fdt_add_pubkey'.
>
> The following block shows an example on how to use this functionality:
>
> spl {
> filename = "boot.signed.bin";
>
> xilinx-fsbl-auth {
> psk-key-name-hint = "psk0";
> ssk-key-name-hint = "ssk0";
> auth-params = "ppk_select=0", "spk_id=0x";
>
> u-boot-spl-nodtb {
> };
> u-boot-spl-pubkey-dtb {
> algo = "sha384,rsa4096";
> required = "conf";
> key-name-hint = "dev";
> };
> };
> };
>
>
> Changes in v3:
> - Improved test coverage regarding missing libelf
> - Align error message
> - Fix rst headline length
> - Add newline before main
> - Adapted test due to property renaming
> - Fixed minor python doc typo in u-boot-spl-pubkey-dtb etype
> - Renamed key property from 'key-name' to 'key-name-hint'
> - Fixed an issue where the build result was not found
> - Fixed an issue where the version string was not reported correctly
> - Improved test coverage for xilinx-fsbl-auth etype
> - Changed etype from entry to section
> - Changed property name "psk-filename" to "psk-key-name-hint"
> - Changed property name "ssk-filename" to "ssk-key-name-hint"
> - Decode spl elf file instead of reading start symbol
> - Improved test coverage
> - Improved documentation
>
> Changes in v2:
> - Changed u_boot_spl_pubkey_dtb to u-boot-spl-pubkey-dtb
> - Improved rst/python documentation
> - Changed u_boot_spl_pubkey_dtb to u-boot-spl-pubkey-dtb in example
> - Pass additional 'keysrc_enc' parameter to Bootgen
> - Added more information and terms to documentation
> - Fixed typo in dts name
> - Add 'keysrc-enc' property to pass down to Bootgen
> - Improved documentation
> - Use predictable output names for intermediated results
>
> Lukas Funke (11):
>   binman: elf: Check for ELF_TOOLS availability and remove extra
> semicolon
>   binman: Don't decompress data while signing
>   binman: blob_dtb: Add fake_size argument to ObtainContents()
>   binman: doc: Add documentation for fdt_add_pubkey bintool
>   binman: ftest: Add test for u_boot_spl_pubkey_dtb
>   binman: btool: Add fdt_add_pubkey as btool
>   binman: etype: Add u-boot-spl-pubkey-dtb etype
>   binman: doc: Add documentation for Xilinx Bootgen bintool
>   binman: btool: Add Xilinx Bootgen btool
>   binman: ftest: Add test for xilinx_fsbl_auth etype
>   binman: etype: Add xilinx_fsbl_auth etype
>
>  tools/binman/bintools.rst |  22 ++
>  tools/binman/btool/bootgen.py | 136 +++
>  tools/binman/btool/fdt_add_pubkey.py  |  67 ++
>  tools/binman/control.py   |   2 +-
>  tools/binman/elf.py   |  14 +-
>  tools/binman/elf_test.py  |  11 +
>  tools/binman/entries.rst  | 110 +
>  tools/binman/etype/blob_dtb.py|   2 +-
>  tools/binman/etype/u_boot_spl_pubkey_dtb.py   | 109 +
>  tools/binman/etype/xilinx_fsbl_auth.py| 221 ++
>  tools/binman/ftest.py |  94 
>  tools/binman/test/280_xilinx_fsbl_auth.dts|  21 ++
>  .../binman/test/280_xilinx_fsbl_auth_enc.dts  |  23 ++
>  tools/binman/test/281_spl_pubkey_dtb.dts  |  16 ++
>  14 files changed, 839 insertions(+), 9 deletions(-)
>  create mode 100644 tools/binman/btool/bootgen.py
>  create mode 100644 tools/binman/btool/fdt_add_pubkey.py
>  create mode 100644 tools/binman/etype/u_boot_spl_pubkey_dtb.py
>  create mode 100644 tools/binman/etype/xilinx_fsbl_auth.py
>  create mode 100644 tools/binman/test/280_xilinx_fsbl_auth.dts
>  create mode 100644 tools/binman/test/280_xilinx_fsbl_auth_enc.dts
>  create mode 100644 tools/binman/test/281_spl_pubkey_dtb.dts
>
> --
> 2.30.2
>

With this I get test failures:

==
ERROR: binman.ftest.TestFunctional.testXilinxFsblAuthAndEncryption
(subunit.RemotedTestCase)
binman.ftest.TestFunctional.testXilinxFsblAuthAndEncryption
--
testtools.testresult.real._StringException: Traceback (most recent call last):
  File 
"/scratch/sglass/cosarm/src/third_party/u-boot/files/tools/binman/ftest.py",
line 6932, in testXilinxFsblAuthAndEncryption
self._DoReadFileRealDtb('280_xilinx_fsbl_auth_enc.dts')
  File

Re: [PATCH 2/7] arm: Remove leftover MAINTAINERS files

On Tue, 18 Jul 2023 at 17:34, Tom Rini  wrote:
>
> These platforms have been removed, but the MAINTAINERS file was missed,
> clean up.
>
> Signed-off-by: Tom Rini 
> ---
>  board/birdland/bav335x/MAINTAINERS   | 13 -
>  board/broadcom/bcm11130/MAINTAINERS  |  6 --
>  board/broadcom/bcm11130_nand/MAINTAINERS |  6 --
>  board/broadcom/bcm28155_w1d/MAINTAINERS  |  6 --
>  4 files changed, 31 deletions(-)
>  delete mode 100644 board/birdland/bav335x/MAINTAINERS
>  delete mode 100644 board/broadcom/bcm11130/MAINTAINERS
>  delete mode 100644 board/broadcom/bcm11130_nand/MAINTAINERS
>  delete mode 100644 board/broadcom/bcm28155_w1d/MAINTAINERS

Reviewed-by: Simon Glass

Re: [PATCH v3 09/11] binman: btool: Add Xilinx Bootgen btool

Hi,

On Tue, 18 Jul 2023 at 05:53,  wrote:
>
> From: Lukas Funke 
>
> Add the Xilinx Bootgen as bintool. Xilinx Bootgen is used to create
> bootable SPL (FSBL in Xilinx terms) images for Zynq/ZynqMP devices. The
> btool creates a signed version of the SPL. Additionally to signing the
> key source for the decryption engine can be passend to the boot image.
>
> Signed-off-by: Lukas Funke 
>
> ---
>
> Changes in v3:
> - Fixed an issue where the build result was not found
> - Fixed an issue where the version string was not reported correctly
>
> Changes in v2:
> - Pass additional 'keysrc_enc' parameter to Bootgen
> - Added more information and terms to documentation
>
>  tools/binman/bintools.rst |   2 +-
>  tools/binman/btool/bootgen.py | 136 ++
>  2 files changed, 137 insertions(+), 1 deletion(-)
>  create mode 100644 tools/binman/btool/bootgen.py
>
> diff --git a/tools/binman/bintools.rst b/tools/binman/bintools.rst
> index c6c9a88c21..8f58aaebf7 100644
> --- a/tools/binman/bintools.rst
> +++ b/tools/binman/bintools.rst
> @@ -197,7 +197,7 @@ Using `fdt_add_pubkey` the key can be injected to the SPL 
> independent of
>
>
>  Bintool: bootgen: Sign ZynqMP FSBL image
> --
> +
>
>  This bintool supports running `bootgen` in order to sign a SPL for ZynqMP
>  devices.
> diff --git a/tools/binman/btool/bootgen.py b/tools/binman/btool/bootgen.py
> new file mode 100644
> index 00..83bbe124dc
> --- /dev/null
> +++ b/tools/binman/btool/bootgen.py
> @@ -0,0 +1,136 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +# Copyright (C) 2023 Weidmüller Interface GmbH & Co. KG
> +# Lukas Funke 
> +#
> +"""Bintool implementation for bootgen
> +
> +bootgen allows creating bootable SPL for Zynq(MP)
> +
> +Documentation is available via::
> +https://www.xilinx.com/support/documents/sw_manuals/xilinx2022_1/ug1283-bootgen-user-guide.pdf
> +
> +Source code is available at:
> +
> +https://github.com/Xilinx/bootgen
> +
> +"""
> +import tempfile
> +
> +from binman import bintool
> +from u_boot_pylib import tools
> +
> +# pylint: disable=C0103
> +class Bintoolbootgen(bintool.Bintool):
> +"""Generate bootable fsbl image for zynq/zynqmp
> +
> +This bintools supports running Xilinx "bootgen" in order
> +to generate a bootable, authenticated image form an SPL.
> +
> +"""
> +def __init__(self, name):
> +super().__init__(name, 'Xilinx Bootgen',
> + version_regex=r'^\*\*\*\*\*\* *Xilinx Bootgen 
> *(.*)',
> + version_args='-help')
> +
> +# pylint: disable=R0913
> +def sign(self, arch, spl_elf_fname, pmufw_elf_fname,
> + psk_fname, ssk_fname, fsbl_config, auth_params, keysrc_enc,
> + output_fname):
> +""" Sign SPL elf file and bundle it PMU firmware into an image
> +
> +The method bundels the SPL together with a 'Platform Management Unit'
> +(PMU)[1] firmware into a single bootable image. The image in turn is
> +signed with the provided 'secondary secret key' (ssk), which in turn 
> is
> +signed with the 'primary secret key' (ppk). In order to verify the
> +authenticity of the ppk, it's hash has to be fused into the device
> +itself.

Please regen the entry-docs in the same patch, so that entries.rst is
updated. Also check your references like [1]. Looking at the docs
output you should be able to click on the link, i.e. you should use
rST style
[..]

Regards,
Simon

Re: [PATCH 4/7] MAINTAINERS: Add a number of "common" directories

On Tue, 18 Jul 2023 at 17:34, Tom Rini  wrote:
>
> A number of platforms have "common" directories that are in turn not
> listed by the board MAINTAINERS file.  Add these directories in many
> cases.
>
> Signed-off-by: Tom Rini 
> ---
> An alternative in some cases may be to have a
> board/$(VENDOR)/MAINTAINERS file instead and rework the listings that
> way.
> ---
>  MAINTAINERS  | 1 +
>  board/BuR/brppt1/MAINTAINERS | 1 +
>  board/BuR/brppt2/MAINTAINERS | 1 +
>  board/BuR/brsmarc1/MAINTAINERS   | 1 +
>  board/BuR/brxre1/MAINTAINERS | 1 +
>  board/LaCie/net2big_v2/MAINTAINERS   | 1 +
>  board/LaCie/netspace_v2/MAINTAINERS  | 1 +
>  board/Synology/ds109/MAINTAINERS | 1 +
>  board/Synology/ds116/MAINTAINERS | 1 +
>  board/Synology/ds414/MAINTAINERS | 1 +
>  board/avionic-design/medcom-wide/MAINTAINERS | 1 +
>  board/avionic-design/plutux/MAINTAINERS  | 1 +
>  board/avionic-design/tec-ng/MAINTAINERS  | 1 +
>  board/avionic-design/tec/MAINTAINERS | 1 +
>  board/emulation/qemu-arm/MAINTAINERS | 1 +
>  board/emulation/qemu-ppce500/MAINTAINERS | 1 +
>  board/emulation/qemu-riscv/MAINTAINERS   | 1 +
>  board/emulation/qemu-x86/MAINTAINERS | 2 ++
>  board/engicam/imx6q/MAINTAINERS  | 1 +
>  board/engicam/imx6ul/MAINTAINERS | 1 +
>  board/engicam/imx8mm/MAINTAINERS | 1 +
>  board/engicam/imx8mp/MAINTAINERS | 1 +
>  board/engicam/px30_core/MAINTAINERS  | 1 +
>  board/engicam/stm32mp1/MAINTAINERS   | 1 +
>  board/gdsys/a38x/MAINTAINERS | 1 +
>  board/gdsys/mpc8308/MAINTAINERS  | 1 +
>  board/keymile/km83xx/MAINTAINERS | 2 ++
>  board/keymile/kmcent2/MAINTAINERS| 2 ++
>  board/keymile/pg-wcom-ls102xa/MAINTAINERS| 2 ++
>  board/keymile/secu1/MAINTAINERS  | 2 ++
>  board/toradex/apalis-imx8/MAINTAINERS| 1 +
>  board/toradex/apalis-tk1/MAINTAINERS | 1 +
>  board/toradex/apalis_imx6/MAINTAINERS| 1 +
>  board/toradex/apalis_t30/MAINTAINERS | 1 +
>  board/toradex/colibri-imx6ull/MAINTAINERS| 1 +
>  board/toradex/colibri-imx8x/MAINTAINERS  | 1 +
>  board/toradex/colibri_imx6/MAINTAINERS   | 1 +
>  board/toradex/colibri_imx7/MAINTAINERS   | 1 +
>  board/toradex/colibri_t20/MAINTAINERS| 1 +
>  board/toradex/colibri_t30/MAINTAINERS| 1 +
>  board/toradex/colibri_vf/MAINTAINERS | 1 +
>  board/toradex/verdin-imx8mm/MAINTAINERS  | 1 +
>  board/toradex/verdin-imx8mp/MAINTAINERS  | 1 +
>  43 files changed, 48 insertions(+)

Reviewed-by: Simon Glass

Re: [PATCH v4 06/12] binman: capsule: Add support for generating capsules

Hi Sughosh,

On Mon, 17 Jul 2023 at 04:44, Sughosh Ganu  wrote:
>
> hi Simon,
>
> On Sun, 16 Jul 2023 at 05:12, Simon Glass  wrote:
> >
> > Hi Sughosh,
> >
> > On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu  wrote:
> > >
> > > Add support in binman for generating capsules. The capsule parameters
> > > can be specified either through a config file or through the capsule
> > > binman entry. Also add test cases in binman for capsule generation,
> > > and enable this testing on the sandbox_spl variant.
> >
> > Can you use sandbox instead, or perhaps sandbox_spl? SPL is really for
> > SPL testing.
>
> Er, I am actually using the sandbox_spl variant.
>
> >
> > >
> > > Signed-off-by: Sughosh Ganu 
> > > ---
> > > Changes since V3:
> > > * Add test cases for covering the various capsule generation
> > >   scenarios.
> > > * Add function comments in the mkeficapsule bintool.
> > > * Fix the fetch method of the mkeficapsule bintool to enable building
> > >   the tool.
> > > * Add more details about the capsule parameters in the documentation
> > >   as well as the code.
> > > * Fix order of module imports, and addition of blank lines in the
> > >   capsule.py file.
> > > * Use SetContents in the ObtainContents method.
> > >
> > >  configs/sandbox_spl_defconfig |   1 +
> > >  tools/binman/btool/mkeficapsule.py| 158 ++
> > >  tools/binman/entries.rst  |  37 
> > >  tools/binman/etype/capsule.py | 132 +++
> > >  tools/binman/ftest.py | 127 ++
> > >  tools/binman/test/282_capsule.dts |  18 ++
> > >  tools/binman/test/283_capsule_signed.dts  |  20 +++
> > >  tools/binman/test/284_capsule_conf.dts|  14 ++
> > >  tools/binman/test/285_capsule_missing_key.dts |  19 +++
> > >  .../binman/test/286_capsule_missing_index.dts |  17 ++
> > >  .../binman/test/287_capsule_missing_guid.dts  |  17 ++
> > >  .../test/288_capsule_missing_payload.dts  |  17 ++
> > >  tools/binman/test/289_capsule_missing.dts |  17 ++
> > >  tools/binman/test/290_capsule_version.dts |  19 +++
> > >  tools/binman/test/capsule_cfg.txt |   6 +
> > >  15 files changed, 619 insertions(+)
> > >  create mode 100644 tools/binman/btool/mkeficapsule.py
> > >  create mode 100644 tools/binman/etype/capsule.py
> > >  create mode 100644 tools/binman/test/282_capsule.dts
> > >  create mode 100644 tools/binman/test/283_capsule_signed.dts
> > >  create mode 100644 tools/binman/test/284_capsule_conf.dts
> > >  create mode 100644 tools/binman/test/285_capsule_missing_key.dts
> > >  create mode 100644 tools/binman/test/286_capsule_missing_index.dts
> > >  create mode 100644 tools/binman/test/287_capsule_missing_guid.dts
> > >  create mode 100644 tools/binman/test/288_capsule_missing_payload.dts
> > >  create mode 100644 tools/binman/test/289_capsule_missing.dts
> > >  create mode 100644 tools/binman/test/290_capsule_version.dts
> > >  create mode 100644 tools/binman/test/capsule_cfg.txt
> >
> > This looks pretty good to me. Some nits below
> >
> > >
> > > diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig
> > > index dd848c57c6..2fcc789347 100644
> > > --- a/configs/sandbox_spl_defconfig
> > > +++ b/configs/sandbox_spl_defconfig
> > > @@ -248,3 +248,4 @@ CONFIG_UNIT_TEST=y
> > >  CONFIG_SPL_UNIT_TEST=y
> > >  CONFIG_UT_TIME=y
> > >  CONFIG_UT_DM=y
> > > +CONFIG_TOOLS_MKEFICAPSULE=y
> >
> > Why enabling this here? I don't think it is needed in sandbox_spl, but
> > in any case it should be in a different patch if needed.
>
> The binman tests run on the sandbox_spl variant. When running the
> capsule generation tests, the mkeficapsule tool should be present on
> the board variant no?

Can we run this on the 'sandbox' variant instead?

[..]

> >
> > > +
> > > +def ReadNode(self):
> > > +super().ReadNode()
> > > +
> > > +self.cfg_file = fdt_util.GetString(self._node, 'cfg-file')
> > > +if not self.cfg_file:
> > > +self.image_index = fdt_util.GetInt(self._node, 'image-index')
> > > +if not self.image_index:
> > > +self.Raise('mkeficapsule must be provided an Image 
> > > Index')
> > > +
> > > +self.image_guid = fdt_util.GetString(self._node, 
> > > 'image-type-id')
> > > +if not self.image_guid:
> > > +self.Raise('mkeficapsule must be provided an Image GUID')
> >
> > Use self.required_props = ['image-type-id', ...] in your __init__().
> > Then this is automatic
>
> I should have clarified this during the earlier version itself. So
> these parameters are mandatory only when not using the config file. In
> the scenario of generating the capsules through config files, all
> these parameters are provided through the config file. Hence these
> explicit checks.

Hmm, I think we should consider having two different etypes, then. It
seems in fact that your entry type is doing 2-3 diffe

Re: [RFC] efi_driver: fix a parent issue in efi-created block devices

Hi AKASHI,

On Tue, 18 Jul 2023 at 18:22, AKASHI Takahiro
 wrote:
>
> An EFI application may create an EFI block device (EFI_BLOCK_IO_PROTOCOL) in
> EFI world, which in turn generates a corresponding U-Boot block device based 
> on
> U-Boot's Driver Model.
> The latter device, however, doesn't work as U-Boot proper block device
> due to an issue in efi_driver's implementation. We saw discussions in the 
> past,
> most recently in [1].
>
>   [1] https://lists.denx.de/pipermail/u-boot/2023-July/522565.html
>
> This RFC patch tries to address (part of) the issue.
> If it is considered acceptable, I will create a formal patch.
>
> Withtout this patch,
> ===8<===
> => env set efi_selftest 'block device'
> => bootefi selftest
>  ...
>
> Summary: 0 failures
>
> => dm tree
>  Class Index  Probed  DriverName
> ---
>  root  0  [ + ]   root_driver   root_driver
>  ...
>  bootmeth  7  [   ]   vbe_simple|   `-- vbe_simple
>  blk   0  [ + ]   efi_blk   `-- efiblk#0
>  partition 0  [ + ]   blk_partition `-- efiblk#0:1
> => ls efiloader 0:1
> ** Bad device specification efiloader 0 **
> Couldn't find partition efiloader 0:1
> ===>8===
>
> With this patch applied, efiblk#0(:1) now gets accessible.
>
> ===8<===
> => env set efi_selftest 'block device'
> => bootefi selftest
>  ...
>
> Summary: 0 failures
>
> => dm tree
>  Class Index  Probed  DriverName
> ---
>  root  0  [ + ]   root_driver   root_driver
>  ...
>  bootmeth  7  [   ]   vbe_simple|   `-- vbe_simple
>  efi   0  [ + ]   EFI block driver  `-- 
> /VenHw(dbca4c98-6cb0-694d-0872-819c650cb7b8)
>  blk   0  [ + ]   efi_blk   `-- efiblk#0
>  partition 0  [ + ]   blk_partition `-- efiblk#0:1
> => ls efiloader 0:1
>13   hello.txt
> 7   u-boot.txt
>
> 2 file(s), 0 dir(s)
> ===>8===
>
> Signed-off-by: AKASHI Takahiro 
> ---
>  include/efi_driver.h |  2 +-
>  lib/efi_driver/efi_block_device.c| 17 -
>  lib/efi_driver/efi_uclass.c  |  8 +++-
>  lib/efi_selftest/efi_selftest_block_device.c |  2 ++
>  4 files changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/include/efi_driver.h b/include/efi_driver.h
> index 63a95e4cf800..ed66796f3519 100644
> --- a/include/efi_driver.h
> +++ b/include/efi_driver.h
> @@ -42,7 +42,7 @@ struct efi_driver_ops {
> const efi_guid_t *child_protocol;
> efi_status_t (*init)(struct efi_driver_binding_extended_protocol 
> *this);
> efi_status_t (*bind)(struct efi_driver_binding_extended_protocol 
> *this,
> -efi_handle_t handle, void *interface);
> +efi_handle_t handle, void *interface, char 
> *name);
>  };
>
>  #endif /* _EFI_DRIVER_H */
> diff --git a/lib/efi_driver/efi_block_device.c 
> b/lib/efi_driver/efi_block_device.c
> index add00eeebbea..43b7ed7c973c 100644
> --- a/lib/efi_driver/efi_block_device.c
> +++ b/lib/efi_driver/efi_block_device.c
> @@ -115,9 +115,9 @@ static ulong efi_bl_write(struct udevice *dev, lbaint_t 
> blknr, lbaint_t blkcnt,
>   * Return: status code
>   */
>  static efi_status_t
> -efi_bl_create_block_device(efi_handle_t handle, void *interface)
> +efi_bl_create_block_device(efi_handle_t handle, void *interface, struct 
> udevice *parent)
>  {
> -   struct udevice *bdev = NULL, *parent = dm_root();
> +   struct udevice *bdev = NULL;
> efi_status_t ret;
> int devnum;
> char *name;
> @@ -181,7 +181,7 @@ err:
>   */
>  static efi_status_t efi_bl_bind(
> struct efi_driver_binding_extended_protocol *this,
> -   efi_handle_t handle, void *interface)
> +   efi_handle_t handle, void *interface, char *name)
>  {
> efi_status_t ret = EFI_SUCCESS;
> struct efi_object *obj = efi_search_obj(handle);
> @@ -191,8 +191,15 @@ static efi_status_t efi_bl_bind(
> if (!obj || !interface)
> return EFI_INVALID_PARAMETER;
>
> -   if (!handle->dev)
> -   ret = efi_bl_create_block_device(handle, interface);
> +   if (!handle->dev) {
> +   struct udevice *parent;
> +
> +   ret = device_bind_driver(dm_root(), "EFI block driver", name, 
> &parent);

Can you use a non-root device as the parent?

> +   if (!ret)
> +   ret = efi_bl_create_block_device(handle, interface, 
> parent);
> +   else
> +   ret = EFI_DEVICE_ERROR;
> +   }
>
> return ret;
>  }
> diff --git a/lib/efi_driver/efi_uclass.c b/lib/efi_driver/efi_uclass.c
> index 45f935198874..bf669742783e 100644
> --- a/lib/efi_driver/efi_uclass.c
> +++ b/lib/efi_driver/efi_u

Re: [PATCH 1/5] MAINTAINERS: Correct minor mistakes on some file listings

On Tue, 18 Jul 2023 at 10:20, Tom Rini  wrote:
>
> There are a few entries where minor mistakes mean that we don't match up
> with obviously expected files, correct those.
>
> Signed-off-by: Tom Rini 
> ---
>  board/amlogic/u200/MAINTAINERS| 2 +-
>  board/broadcom/bcmns/MAINTAINERS  | 2 +-
>  board/freescale/imx93_evk/MAINTAINERS | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>

Reviewed-by: Simon Glass

Re: [PATCH v2 1/4] cmd: bind: Add unbind command with driver filter

On Mon, 17 Jul 2023 at 05:21, Marek Vasut  wrote:
>
> Extend the driver core to perform lookup by both OF node and driver
> bound to the node. Use this to look up specific device instances to
> unbind from nodes in the unbind command. One example where this is
> needed is USB peripheral controller, which may have multiple gadget
> drivers bound to it. The unbind command has to select that specific
> gadget driver instance to unbind from the controller, not unbind the
> controller driver itself from the controller.
>
> USB ethernet gadget usage looks as follows with this change. Notice
> the extra 'usb_ether' addition in the 'unbind' command at the end.
> "
> bind /soc/usb-otg@4900 usb_ether
> setenv ethact usb_ether
> setenv loadaddr 0xc200
> setenv ipaddr 10.0.0.2
> setenv serverip 10.0.0.1
> setenv netmask 255.255.255.0
> tftpboot 0xc200 10.0.0.1:test.file
> unbind /soc/usb-otg@4900 usb_ether
> "
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Kevin Hilman 
> Cc: Lukasz Majewski 
> Cc: Marek Vasut 
> Cc: Simon Glass 
> ---
> V2: No change
> ---
>  cmd/bind.c| 10 +-
>  drivers/core/device.c | 20 +++-
>  include/dm/device.h   | 17 +
>  3 files changed, 37 insertions(+), 10 deletions(-)

Can we have a test?

Regards,
Simon

Re: fdt_high default value causes unbootable kernel due to misalignment

Hi Tim,

On Tue, 18 Jul 2023 at 09:59, Tim van der Staaij | Zign
 wrote:
>
> Hello,
>
> When I was using U-Boot with a dart_6ul board I occasionally had fitimages 
> that U-Boot would attempt to boot just fine, but the kernel wouldn't actually 
> boot. Debugging found that this was correlated with the header length of the 
> fitImage. Then I noticed this remark in doc/usage/environment.rst about 
> fdt_high:
>
> >If this is set to the special value 0x (32-bit machines) or
> >0x (64-bit machines) then the fdt will not be copied at
> >all on boot. For this to work it must reside in writable memory, have
> >sufficient padding on the end of it for u-boot to add the information
> >it needs into it, and the memory must be accessible by the kernel.
> >This usage is strongly discouraged however as it also stops U-Boot
> >from ensuring the device tree starting address is properly aligned
> >and a misaligned tree will cause OS failures.
>
> And indeed, fdt_high is set to 0x in the include/configs/dart_6ul.h 
> that I was using. Since mkimage only guarantees 32-bit alignment of the 
> device tree blob within the fitimage, and not the 64-bit alignment that Linux 
> requires, this is basically a 50/50 coin flip. Something simple like adding a 
> few characters to the description string in the fitimage header can make or 
> break the alignment.
>
> Personally I fixed this by removing the fdt_high altogether, which makes 
> U-Boot copy the device tree to an appropriate location. I assume this only 
> works in my situation because I only have half a GiB of RAM and therefore do 
> not have any high memory. I can imagine my fix would be problematic for board 
> variants with more RAM, the setting doesn't exist without a reason of course.
>
> It looks like this issue is not limited to my board; the same usage of 
> fdt_high can be found in many other board configs. I'm not going to suggest 
> what the best fix is because I lack detailed knowledge, but I will pitch that 
> perhaps omitting fdt_high by default is at least preferable to a value that 
> is "strongly discouraged" and causes Linux boot failures somewhat arbitrarily.

I wonder if we should adjust mkimage to use -B 8 as the default?

Regards,
Simon

Re: [PATCH V6 07/10] common: spl: spl: Remove video driver

On Tue, 18 Jul 2023 at 02:57, Nikhil M Jain  wrote:
>
> Use config SPL_VIDEO_REMOVE to remove video driver at SPL stage before
> jumping to next stage, in place of CONFIG_SPL_VIDEO, to allow user to
> remove video if required.
>
> Signed-off-by: Nikhil M Jain 
> Reviewed-by: Devarsh Thakkar 
> ---
> V6:
> - No change.
>
> V5:
> - No change.
>
> V4:
> - No change.
>
> V3:
> - Replace #if defined(CONFIG_SPL_VIDEO_REMOVE) with
>   if (IS_ENABLED(CONFIG_SPL_VIDEO_REMOVE).
>
> V2:
> - Add Reviewed-by tag.
>
>  common/spl/spl.c | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)

Reviewed-by: Simon Glass

Re: Double free on xhci_register failure.

+Marek Vasut

On Tue, 18 Jul 2023 at 16:14, Richard Habeeb  wrote:
>
> Hi all,
>
> drivers/core/device.c will call `device_free()` after xhci_register already
> frees the private device data. This causes a memory corruption and crash on
> my RPI4B. I believe the solution is to remove the free call in
> xhci_register (
> https://github.com/u-boot/u-boot/blob/master/drivers/usb/host/xhci.c#L1421),
> thoughts?
>
> -Richard Habeeb

Re: [PATCH v2 2/7] binman: Update missing optional external blob warning text

On Tue, 18 Jul 2023 at 14:34, Jonas Karlman  wrote:
>
> Make it more clear that the missing external blob is optional in the
> printed warning message.
>
> Signed-off-by: Jonas Karlman 
> ---
> v2:
> - New patch
>
>  tools/binman/control.py | 2 +-
>  tools/binman/ftest.py   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/binman/control.py b/tools/binman/control.py
> index 25e66814837d..3560cadba4c2 100644
> --- a/tools/binman/control.py
> +++ b/tools/binman/control.py
> @@ -674,7 +674,7 @@ def ProcessImage(image, update_fdt, write_map, 
> get_contents=True,
>  image.CheckOptional(optional_list)
>  if optional_list:
>  tout.warning(
> -"Image '%s' is missing external blobs but is still functional: 
> %s" %
> +"Image '%s' is missing optional external blobs but is still 
> functional: %s" %
>  (image.name, ' '.join([e.name for e in optional_list])))
>  _ShowHelpForMissingBlobs(optional_list)
>
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> index e53181afb78a..152f800c676c 100644
> --- a/tools/binman/ftest.py
> +++ b/tools/binman/ftest.py
> @@ -6330,7 +6330,7 @@ fdt fdtmapExtract the 
> devicetree blob from the fdtmap
>  err = stderr.getvalue()
>  self.assertRegex(
>  err,
> -"Image '.*' is missing external blobs but is still functional: 
> missing")
> +"Image '.*' is missing optional external blobs but is still 
> functional: missing")
>
>  def testSectionInner(self):
>  """Test an inner section with a size"""
> --
> 2.41.0
>

Reviewed-by: Simon Glass

Re: [PATCH v4 12/12] sandbox: capsule: Generate capsule related files through binman

Hi Sughosh,

On Mon, 17 Jul 2023 at 05:18, Sughosh Ganu  wrote:
>
> hi Simon,
>
> On Sun, 16 Jul 2023 at 05:12, Simon Glass  wrote:
> >
> > Hi Sughosh,
> >
> > On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu  wrote:
> > >
> > > The EFI capsule files can now be generated as part of u-boot
> > > build. This is done through binman. Add capsule entry nodes in the
> > > u-boot.dtsi for the sandbox architecture for generating the
> > > capsules. Remove the corresponding generation of capsules from the
> > > capsule update conftest file.
> > >
> > > The capsules are generated through the config file for the sandbox
> > > variant, and through explicit parameters for the sandbox_flattree
> > > variant.
> > >
> > > Also generate the FIT image used for testing the capsule update
> > > feature on the sandbox_flattree variant through binman. Remove the now
> > > superfluous its file which was used for generating this FIT image.
> > >
> > > Signed-off-by: Sughosh Ganu 
> > > ---
> > > Changes since V3:
> > > * Use blob nodes instead of incbin for including the binaries in FIT
> > >   image.
> > > * Enable generation of capsules with versioning support.
> > >
> > >  arch/sandbox/dts/u-boot.dtsi  | 265 ++
> > >  test/py/tests/test_efi_capsule/conftest.py| 127 -
> > >  .../tests/test_efi_capsule/uboot_bin_env.its  |  36 ---
> > >  3 files changed, 265 insertions(+), 163 deletions(-)
> > >  delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its
> > >
> > > diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
> > > index 60bd004937..7b0250ac81 100644
> > > --- a/arch/sandbox/dts/u-boot.dtsi
> > > +++ b/arch/sandbox/dts/u-boot.dtsi
> > > @@ -13,5 +13,270 @@
> > > capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
> > > };
> > >  #endif
> > > +
> > > +   binman: binman {
> > > +   multiple-images;
> > > +   };
> > > +};
> > > +
> > > +&binman {
> > > +   itb {
> > > +   filename = "/tmp/capsules/uboot_bin_env.itb";
> > > +
> > > +   fit {
> > > +   description = "Automatic U-Boot environment 
> > > update";
> > > +   #address-cells = <2>;
> > > +
> > > +   images {
> > > +   u-boot-bin {
> > > +   description = "U-Boot binary on 
> > > SPI Flash";
> > > +   compression = "none";
> > > +   type = "firmware";
> > > +   arch = "sandbox";
> > > +   load = <0>;
> > > +   blob {
> > > +   filename = 
> > > "/tmp/capsules/u-boot.bin.new";
> > > +   };
> > > +
> > > +   hash-1 {
> > > +   algo = "sha1";
> > > +   };
> > > +   };
> > > +   u-boot-env {
> > > +   description = "U-Boot environment 
> > > on SPI Flash";
> > > +   compression = "none";
> > > +   type = "firmware";
> > > +   arch = "sandbox";
> > > +   load = <0>;
> > > +   blob {
> > > +   filename = 
> > > "/tmp/capsules/u-boot.env.new";
> > > +   };
> > > +
> > > +   hash-1 {
> > > +   algo = "sha1";
> > > +   };
> > > +   };
> > > +   };
> > > +   };
> > > +   };
> > > +
> > > +#ifdef CONFIG_EFI_USE_CAPSULE_CFG_FILE
> > > +   capsule1 {
> > > +   capsule {
> > > +   cfg-file = CONFIG_EFI_CAPSULE_CFG_FILE;
> > > +   };
> > > +   };
> > > +#else
> > > +   capsule2 {
> > > +   capsule {
> > > +   image-index = <0x1>;
> > > +   image-type-id = 
> > > "09D7CF52-0720-4710-91D1-08469B7FE9C8";
> >
> > We seem to have a persistent problem with these appearing in the source 
> > code.
> >
> > Perhaps you could add them to a header file and use
> > GUID_MEANINGFUL_NAME here instead (also below).
> >
> > In general, GUIDs should not be open-coded.
>
> Okay. Will it be okay if I add these to a sandbox_capule.h. Earlier, I
> had similar GUID macros in the sandbox config header, and you had
> asked me to move them to the board file.

These are littered all over the place. Perhaps a new 'efi_guid.h'
header file that has all

Re: [PATCH 7/7] MAINTAINERS: Add some missing directories or files

On Tue, 18 Jul 2023 at 17:34, Tom Rini  wrote:
>
> In a few cases we have MAINTAINERS entries that are missing obvious
> paths or files. Typically this means a board directory that did not list
> itself, but in a few cases we have a Kconfig file or similar.
>
> Signed-off-by: Tom Rini 
> ---
>  MAINTAINERS  | 1 +
>  board/coreboot/coreboot/MAINTAINERS  | 4 +---
>  board/devboards/dbm-soc1/MAINTAINERS | 1 +
>  board/efi/efi-x86_app/MAINTAINERS| 2 ++
>  board/efi/efi-x86_payload/MAINTAINERS| 1 +
>  board/firefly/firefly-rk3308/MAINTAINERS | 3 ++-
>  board/freescale/ls1043ardb/MAINTAINERS   | 1 -
>  board/keymile/secu1/MAINTAINERS  | 1 +
>  board/softing/vining_fpga/MAINTAINERS| 1 +
>  board/terasic/de0-nano-soc/MAINTAINERS   | 1 +
>  board/terasic/de1-soc/MAINTAINERS| 1 +
>  board/terasic/de10-nano/MAINTAINERS  | 1 +
>  board/terasic/de10-standard/MAINTAINERS  | 1 +
>  board/terasic/sockit/MAINTAINERS | 1 +
>  14 files changed, 15 insertions(+), 5 deletions(-)

Reviewed-by: Simon Glass

Re: [PATCH 5/7] MAINTAINERS: Fix path typos and similar

On Tue, 18 Jul 2023 at 17:34, Tom Rini  wrote:
>
> We have a number of cases where the in-tree path of files and where
> they presumably were when the first version of a patch were posted
> differ slightly.  Correct these to point at where the files are now.
>
> Signed-off-by: Tom Rini 
> ---
>  board/anbernic/rgxx3_rk3566/MAINTAINERS   | 4 ++--
>  board/broadcom/bcmns/MAINTAINERS  | 4 ++--
>  board/bsh/imx6ulz_smm_m2/MAINTAINERS  | 2 +-
>  board/cei/cei-tk1-som/MAINTAINERS | 2 +-
>  board/comtrend/ar5315u/MAINTAINERS| 2 +-
>  board/comtrend/ar5387un/MAINTAINERS   | 2 +-
>  board/comtrend/ct5361/MAINTAINERS | 2 +-
>  board/comtrend/vr3032u/MAINTAINERS| 2 +-
>  board/comtrend/wap5813n/MAINTAINERS   | 2 +-
>  board/data_modul/imx8mm_edm_sbc/MAINTAINERS   | 2 +-
>  board/data_modul/imx8mp_edm_sbc/MAINTAINERS   | 2 +-
>  board/google/chromebox_panther/MAINTAINERS| 2 +-
>  board/hardkernel/odroid_go2/MAINTAINERS   | 2 +-
>  board/pine64/pinebook-pro-rk3399/MAINTAINERS  | 2 +-
>  board/pine64/pinephone-pro-rk3399/MAINTAINERS | 2 +-
>  board/ronetix/imx7-cm/MAINTAINERS | 6 +++---
>  board/seeed/npi_imx6ull/MAINTAINERS   | 2 +-
>  board/solidrun/clearfog/MAINTAINERS   | 2 +-
>  board/vamrs/rock960_rk3399/MAINTAINERS| 2 +-
>  19 files changed, 23 insertions(+), 23 deletions(-)

Reviewed-by: Simon Glass

Re: [PATCH v2 5/7] binman: Fix blank line usage for invalid images warning text

Hi Jonas,

On Tue, 18 Jul 2023 at 14:34, Jonas Karlman  wrote:
>
> There is no blank line between last missing blob help message and the
> header line for optional blob help messages.
>
>   Image 'simple-bin' is missing external blobs and is non-functional: atf-bl31
>
>   /binman/simple-bin/fit/images/@atf-SEQ/atf-bl31:
>  See the documentation for your board. You may need to build ARM Trusted
>  Firmware and build with BL31=/path/to/bl31.bin
>   Image 'simple-bin' is missing external blobs but is still functional: tee-os
>
>   /binman/simple-bin/fit/images/@tee-SEQ/tee-os:
>  See the documentation for your board. You may need to build Open Portable
>  Trusted Execution Environment (OP-TEE) and build with 
> TEE=/path/to/tee.bin
>
>   Some images are invalid
>
> With this a blank line is inserted to make the text more readable.
>
> Signed-off-by: Jonas Karlman 
> Reviewed-by: Simon Glass 
> ---
> v2:
> - Collect r-b tag

IMO you don't need to do this...just collect them and say 'no changes'.

'patman status' is your friend.

Regards,
Simon

Re: [PATCH 4/5] sunxi: Add MAINTAINERS entry for Lctech Pi F1C200s

On Tue, 18 Jul 2023 at 10:21, Tom Rini  wrote:
>
> This defconfig was added without a MAINTAINERS entry, add one.
>
> Signed-off-by: Tom Rini 
> ---
>  board/sunxi/MAINTAINERS | 5 +
>  1 file changed, 5 insertions(+)

Reviewed-by: Simon Glass

Re: [PATCH v3 11/11] binman: etype: Add xilinx_fsbl_auth etype

On Tue, 18 Jul 2023 at 05:53,  wrote:
>
> From: Lukas Funke 
>
> This adds a new etype 'xilinx-fsbl-auth'. By using this etype it is
> possible to created an authenticated SPL (FSBL in Xilinx terms) for
> ZynqMP boards.
>
> The etype uses Xilinx Bootgen tools in order to transform the SPL into
> a bootable image and sign the image with a given primary and secondary
> public key. For more information to signing the FSBL please refer to the
> Xilinx Bootgen documentation.
>
> Here is an example of the etype in use:
>
> spl {
> filename = "boot.signed.bin";
>
> xilinx-fsbl-auth {
> psk-key-name-hint = "psk0";
> ssk-key-name-hint = "ssk0";
> auth-params = "ppk_select=0", "spk_id=0x";
>
> u-boot-spl-nodtb {
> };
> u-boot-spl-dtb {
> };
> };
> };
>
> For this to work the hash of the primary public key has to be fused
> into the ZynqMP device and authentication (RSA_EN) has to be set.
>
> For testing purposes: if ppk hash check should be skipped one can add
> the property 'fsbl_config = "bh_auth_enable";' to the etype. However,
> this should only be used for testing(!).
>
> Signed-off-by: Lukas Funke 
>
> ---
>
> Changes in v3:
> - Changed etype from entry to section
> - Changed property name "psk-filename" to "psk-key-name-hint"
> - Changed property name "ssk-filename" to "ssk-key-name-hint"
> - Decode spl elf file instead of reading start symbol
> - Improved test coverage
> - Improved documentation
>
> Changes in v2:
> - Add 'keysrc-enc' property to pass down to Bootgen
> - Improved documentation
> - Use predictable output names for intermediated results
>
>  tools/binman/entries.rst   |  71 
>  tools/binman/etype/xilinx_fsbl_auth.py | 221 +
>  2 files changed, 292 insertions(+)
>  create mode 100644 tools/binman/etype/xilinx_fsbl_auth.py

Reviewed-by: Simon Glass

Re: [PATCH 1/7] arm: Remove more remnants of bcmcygnus

On Tue, 18 Jul 2023 at 17:33, Tom Rini  wrote:
>
> Remove some leftover files from the bcmcygnus platform.
>
> Signed-off-by: Tom Rini 
> ---
>  arch/arm/Kconfig   | 15 +-
>  board/broadcom/bcm_ep/Makefile |  5 --
>  board/broadcom/bcm_ep/board.c  | 86 --
>  3 files changed, 1 insertion(+), 105 deletions(-)
>  delete mode 100644 board/broadcom/bcm_ep/Makefile
>  delete mode 100644 board/broadcom/bcm_ep/board.c

Reviewed-by: Simon Glass

Re: [PATCH v4 32/45] fs: fat: Support reading from a larger block size

Hi Bin,

On Sun, 16 Jul 2023 at 09:19, Bin Meng  wrote:
>
> Hi Simon,
>
> On Sun, Jul 16, 2023 at 7:42 AM Simon Glass  wrote:
> >
> > Hi Bin,
> >
> > On Thu, 13 Jul 2023 at 04:49, Bin Meng  wrote:
> > >
> > > Hi Simon,
> > >
> > > On Mon, Jun 19, 2023 at 8:02 PM Simon Glass  wrote:
> > > >
> > > > At present it is not possible to read from some CDROM drives since the
> > > > FAT sector size does not match the media's block size. Add a conversion
> > > > option for this, so that reading is possible.
> > >
> > > I am completely confused. The CDROM uses iso9660 file system. This has
> > > nothing to do with FAT.
> >
> > It actually can use both - this is the -cdrom option in QEMU which can
> > emulate an old-style CDROM, with a FAT filesystem on it!
> >
>
> What QEMU command line is this to enable a CDROM with FAT file system?
>
> If that is the case, what you changed in this commit only works with
> QEMU, not with any real-world devices, I believe?
>
> Could you use iso9660 instead?

Sure, but the image I am using has an MSDOS partition name, an EFI
partition table, a FAT filesystem and an ISO9660 filesystem! I was
trying to look at the FAT filesystem via the MSDOS partition table.

Regards,
Simon

Re: [PATCH v6 1/3] binman: Add support for externally encrypted blobs

On Mon, 17 Jul 2023 at 01:06,  wrote:
>
> From: Christian Taedcke 
>
> This adds a new etype encrypted.
>
> It creates a new cipher node in the related image similar to the
> cipher node used by u-boot, see boot/image-cipher.c.
>
> Signed-off-by: Christian Taedcke 
> ---
>
> Changes in v6:
> - fix documentation of encrypted etype
>
> Changes in v5:
> - encrypted entry now inherits from Entry
> - remove unnecessary methods ObtainContents and ProcessContents
>
> Changes in v3:
> - rebase on u-boot-dm/mkim-working
> - update doc for functions ObtainContents and ProcessContents
> - update entries.rst
>
> Changes in v2:
> - add entry documentation
> - remove global /cipher node
> - replace key-name-hint with key-source property
>
>  tools/binman/entries.rst|  86 
>  tools/binman/etype/encrypted.py | 138 
>  2 files changed, 224 insertions(+)
>  create mode 100644 tools/binman/etype/encrypted.py

Reviewed-by: Simon Glass

Re: [PATCH v3 10/11] binman: ftest: Add test for xilinx_fsbl_auth etype

On Tue, 18 Jul 2023 at 05:53,  wrote:
>
> From: Lukas Funke 
>
> Add test for the 'xilinx_fsbl_auth' etype
>
> Signed-off-by: Lukas Funke 
>
> ---
>
> Changes in v3:
> - Improved test coverage for xilinx-fsbl-auth etype
>
> Changes in v2:
> - Fixed typo in dts name
>
>  tools/binman/ftest.py | 61 +++
>  tools/binman/test/280_xilinx_fsbl_auth.dts| 21 +++
>  .../binman/test/280_xilinx_fsbl_auth_enc.dts  | 23 +++
>  3 files changed, 105 insertions(+)
>  create mode 100644 tools/binman/test/280_xilinx_fsbl_auth.dts
>  create mode 100644 tools/binman/test/280_xilinx_fsbl_auth_enc.dts

Reviewed-by: Simon Glass 

Nice job on the test coverage!

Re: [PATCH v6 3/3] binman: Add tests for etype encrypted

On Mon, 17 Jul 2023 at 01:06,  wrote:
>
> From: Christian Taedcke 
>
> Add tests to reach 100% code coverage for the added etype encrypted.
>
> Signed-off-by: Christian Taedcke 
> ---
>
> (no changes since v5)
>
> Changes in v5:
> - add comments to test functions
>
> Changes in v4:
> - fix failing test testEncryptedKeyFile
>
> Changes in v3:
> - rebase on u-boot-dm/mkim-working
> - remove unnecessary test testEncryptedNoContent
> - wrap some lines at 80 cols
>
> Changes in v2:
> - adapt tests for changed entry implementation
>
>  tools/binman/ftest.py | 58 +++
>  tools/binman/test/291_encrypted_no_algo.dts   | 15 +
>  .../test/292_encrypted_invalid_iv_file.dts| 18 ++
>  .../binman/test/293_encrypted_missing_key.dts | 23 
>  .../binman/test/294_encrypted_key_source.dts  | 24 
>  tools/binman/test/295_encrypted_key_file.dts  | 24 
>  6 files changed, 162 insertions(+)
>  create mode 100644 tools/binman/test/291_encrypted_no_algo.dts
>  create mode 100644 tools/binman/test/292_encrypted_invalid_iv_file.dts
>  create mode 100644 tools/binman/test/293_encrypted_missing_key.dts
>  create mode 100644 tools/binman/test/294_encrypted_key_source.dts
>  create mode 100644 tools/binman/test/295_encrypted_key_file.dts

Reviewed-by: Simon Glass

Re: [PATCH 6/7] MAINTAINERS: Deal with '+' in paths

Hi Tom,

On Tue, 18 Jul 2023 at 17:34, Tom Rini  wrote:
>
> The listed paths are allowed to contain wildcards.  This includes the
> '+' character which we have as a literal part of the path in a few
> cases. Escape the '+' here so that files are matched.
>
> Signed-off-by: Tom Rini 
> ---
>  board/k+p/kp_imx53/MAINTAINERS | 3 ++-
>  board/k+p/kp_imx6q_tpc/MAINTAINERS | 3 ++-
>  board/l+g/vinco/MAINTAINERS| 2 +-
>  3 files changed, 5 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass 

Ug.

Re: [PATCH 2/5] MAINTAINERS: Add some missing defconfig files to existing entries

On Tue, 18 Jul 2023 at 10:20, Tom Rini  wrote:
>
> We have a few places where defconfigs were added (or renamed) and not
> included in their previously listed MAINTAINERS entry, correct this.
>
> Signed-off-by: Tom Rini 
> ---
> Cc: Adam Ford 
> Cc: Chris Packham 
> Cc: Jan Kiszka 
> Cc: Neil Armstrong 
> Cc: Stefan Roese 
> ---
>  board/Marvell/db-88f6820-amc/MAINTAINERS | 1 +
>  board/amlogic/w400/MAINTAINERS   | 1 +
>  board/beacon/imx8mm/MAINTAINERS  | 1 +
>  board/beacon/imx8mn/MAINTAINERS  | 1 +
>  board/siemens/iot2050/MAINTAINERS| 3 ++-
>  board/solidrun/clearfog/MAINTAINERS  | 2 ++
>  6 files changed, 8 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass

Re: [PATCH 1/1] part: eliminate part_get_info_by_name_type()

Hi Heinrich,

On Sun, 16 Jul 2023 at 05:34, Heinrich Schuchardt
 wrote:
>
> Since commit 56670d6fb83f ("disk: part: use common api to lookup part
> driver") part_get_info_by_name_type() ignores the part_type parameter
> used to restrict the partition table type.
>
> omap_mmc_get_part_size() and part_get_info_by_name() are the only
> consumers.
>
> omap_mmc_get_part_size() calls with part_type = PART_TYPE_EFI because at
> the time of implementation a speed up could be gained by passing the
> partition table type. After 5 years experience without this restriction
> it looks safe to keep it that way.
>
> part_get_info_by_name() uses PART_TYPE_ALL.
>
> Move the logic of part_get_info_by_name_type() to part_get_info_by_name()
> and replace the function in omap_mmc_get_part_size().
>
> Fixes: 56670d6fb83f ("disk: part: use common api to lookup part driver")
> Signed-off-by: Heinrich Schuchardt 
> ---
>  arch/arm/mach-omap2/utils.c |  3 +--
>  disk/part.c | 10 ++
>  include/part.h  | 23 ---
>  3 files changed, 3 insertions(+), 33 deletions(-)

That explains the strange behaviour I saw when fiddling with this a
month or so back, thanks.

Reviewed-by: Simon Glass 

Is there a test to update for this?

Regards,
Simon

Re: [PATCH 3/5] rockchip: Add MAINTAINERS entry for Radxa Rock 4C+

On Tue, 18 Jul 2023 at 10:21, Tom Rini  wrote:
>
> This defconfig was added without a MAINTAINERS entry, add one.
>
> Signed-off-by: Tom Rini 
> ---
>  board/rockchip/evb_rk3399/MAINTAINERS | 6 ++
>  1 file changed, 6 insertions(+)
>

Reviewed-by: Simon Glass

Re: [PATCH v2 1/7] binman: Update tee-os missing blob help text

On Tue, 18 Jul 2023 at 14:34, Jonas Karlman  wrote:
>
> Make it a little bit more clear that it is U-Boot that should be built
> with TEE=/path/to/tee.bin and not OP-TEE itself.
>
> Signed-off-by: Jonas Karlman 
> ---
> v2:
> - New patch
>
>  tools/binman/missing-blob-help | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass

Re: [PATCH 5/5] MAINTAINERS: Re-order CAAM section

On Tue, 18 Jul 2023 at 10:21, Tom Rini  wrote:
>
> This file is in alphabetical order, move CAAM up to where it should be.
>
> Signed-off-by: Tom Rini 
> ---
>  MAINTAINERS | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)

Reviewed-by: Simon Glass 

Please we should add a CI check for this too?

Re: [PATCH v2 2/2] power: pmic: fix regulators behaviour

Hi Svyatoslav,

On Sun, 16 Jul 2023 at 07:20, Svyatoslav Ryhel  wrote:
>
>
>
> 16 липня 2023 р. 16:08:10 GMT+03:00, Simon Glass  
> написав(-ла):
> >Hi Svyatoslav,
> >
> >On Sat, 15 Jul 2023 at 22:08, Svyatoslav Ryhel  wrote:
> >>
> >>
> >>
> >> 16 липня 2023 р. 02:40:37 GMT+03:00, Simon Glass  
> >> написав(-ла):
> >> >Hi Svyatoslav,
> >> >
> >> >On Sat, 15 Jul 2023 at 12:34, Svyatoslav Ryhel  wrote:
> >> >>
> >> >> Currently device tree entries of regulators are completely
> >> >> ignored and regulators are probed only if they are called
> >> >> by the device which uses it. This results into two issues:
> >> >> regulators which must run under boot-on or always-on mode
> >> >> are ignored and not enabled; dts props like voltage are
> >> >> not applied to the regulator so the regulator may be enabled
> >> >> with random actual voltage, which may have unexpected
> >> >> consequences.
> >> >>
> >> >> This patch changes this behavior. Post-probe function is
> >> >> introduced which performs probing of each pmics child and if
> >> >> it is a regulator, regulator_autoset function is called, which
> >> >> handles always-on and boot-on regulators, but if none of those
> >> >> props are set, the regulator is disabled.
> >> >>
> >> >> Later disabled regulators can be re-enabled by devices which
> >> >> use them without issues.
> >> >>
> >> >> Signed-off-by: Svyatoslav Ryhel 
> >> >> ---
> >> >>  drivers/power/pmic/pmic-uclass.c | 18 ++
> >> >>  1 file changed, 18 insertions(+)
> >> >
> >> >Can you add a test for this to test/dm/pmic.c ?
> >> >
> >>
> >> Sure, may you specify what I should add to tests/dm/pmic.c? Which behavior 
> >> is needed?
> >
> >Just for the change you are making...you should be able to check that
> >it sets the regulators if you make sure there are some autoset ones in
> >sandbox.
>
> Easier to tell then to do. I am basically interfering into device 
> establishment process. If smth goes wrong, any regulator related test should 
> fail. At least my devices refused to boot/gave unexpected behavior while 
> developing. I will look if I can find anything meaningful.

Something like this in test/dm/regulator.c:

struct udevice *pmic, *reg;

// This should automatically probe the
ut_asserok(pmic_get("pmic@41"), &pmic);

// Check that the regulators are probed and on
ut_assertok(regulator_get_by_devname("ldo2", ®));
ut_assert(regulator_get_enable(reg));

See test.dtsi and sandbox_pmic.dtsi for the DT nodes. You'll need to
update ldo2 t too add the properties to cause an autoset.

Regards,
Simon

Re: [PATCH v1 1/4] power: regulator: expand basic reference counter onto all uclass

Hi,

On Tue, 18 Jul 2023 at 01:39, Svyatoslav Ryhel  wrote:
>
> вт, 18 лип. 2023 р. о 10:36 Eugen Hristev  пише:
> >
> > Hi Svyatoslav,
> >
> >
> > On 7/18/23 10:05, Svyatoslav Ryhel wrote:
> > > Commit is based on 4fcba5d ("regulator: implement basic reference
> > > counter") but expands the idea to all regulators instead of just
> > > fixed/gpio regulators.
> > >
> > > Signed-off-by: Svyatoslav Ryhel 
> > > ---
> > >   drivers/power/regulator/regulator-uclass.c | 22 ++
> > >   drivers/power/regulator/regulator_common.c | 22 --
> > >   drivers/power/regulator/regulator_common.h | 21 -
> > >   include/power/regulator.h  |  2 ++
> > >   4 files changed, 24 insertions(+), 43 deletions(-)

Does this affect tests? Can you make sure that there is test coverage
in test/dm/...

Regards,
Simon

Re: [PATCH 3/5] m68k: dts: add watchdog node

On Tue, 18 Jul 2023 at 08:00, Angelo Dureghello  wrote:
>
> Hi Stefan,
>
> On 18/07/23 2:26 PM, Stefan Roese wrote:
> > On 6/25/23 21:35, Angelo Dureghello wrote:
> >> Add watchdog node for the implemented mcf_wdt driver.
> >>
> >> Signed-off-by: Angelo Dureghello 
> >> ---
> >>   arch/m68k/dts/M5208EVBE.dts | 5 +
> >>   arch/m68k/dts/mcf5208.dtsi  | 7 +++
> >>   arch/m68k/dts/mcf523x.dtsi  | 7 +++
> >>   arch/m68k/dts/mcf5271.dtsi  | 7 +++
> >>   arch/m68k/dts/mcf5275.dtsi  | 7 +++
> >>   arch/m68k/dts/mcf5282.dtsi  | 7 +++
> >>   arch/m68k/dts/mcf5329.dtsi  | 7 +++
> >>   arch/m68k/dts/mcf537x.dtsi  | 7 +++
> >>   8 files changed, 54 insertions(+)

Reviewed-by: Simon Glass

Re: [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../

Hi,

On Sun, 16 Jul 2023 at 09:12, Tom Rini  wrote:
>
> On Sat, Jul 15, 2023 at 05:40:35PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 13 Jul 2023 at 16:54, Tom Rini  wrote:
> > >
> > > On Wed, Jul 12, 2023 at 08:00:28AM -0600, Simon Glass wrote:
> > > > Hi Jason,
> > > >
> > > > On Tue, 11 Jul 2023 at 16:29, Jason Kacines  wrote:
> > > > >
> > > > > Add support to config fragments (.config) located in the /board
> > > > > directory. This will allow only base defconfigs to live in /configs 
> > > > > and
> > > >
> > > > Does this mean defconfigs?
> > >
> > > This looks like it would cover defconfig files too, but the initial
> > > motivation is config fragments.  See
> > > https://patchwork.ozlabs.org/project/uboot/patch/20230606071850.270001-5-clamo...@gmail.com/
> > > for another example.
> > >
> > > > > all fragments to live in their respective device directory in 
> > > > > /board/..
> > > >
> > > > Why do we want this? The patch should have a motivation.
> > >
> > > I've asked a few people to look in to this because we have a lot of
> > > cases today of N _defconfig files where we could really instead have 1
> > > _defconfig file and N config fragment files.  But I do not want them
> > > living in the top level configs directory as that will get even more
> > > unmanageable.
> >
> > OK I see, thank you. The patch still needs this motivation though.
>
> So you're saying you want the message re-worded?

Yes, to explain why.

Could we also get some docs in doc/build/gcc.rst or similar?

>
> > > What's not in this patch (and not an ask at this point) is figuring out
> > > how buildman could handle "foo_defconfig bar.config" as the required
> > > config target.
> >
> > Indeed. Also, should they appear in the boards.cfg list?
>
> I doubt it? I'm not sure yet how we address getting buildman to know
> about valid additional combinations. Take the example of something like:
> som_vendor_carrier_defconfig + som_vendor_imx7_som.config +
> emmc_boot_instead.config + customer_production_tweaks.config
>
> How would you want buildman to know about that? Does it even really need
> to, on the other hand?  And that's not I think an uncommon example, it's
> just splitting colibri_imx7_emmc_defconfig in to how it would be used by
> someone taking that carrier+som to production, with their own
> touchscreen and a few other tweaks in the dtb that needs to be passed to
> linux.  Or the mnt reform with whatever SOM/COM you happen to have for
> it.

Well firstly we should only worry about things that are in-tree.

The thing is, if we don't validate that the configs at least build,
then someone could change a config (anywhere in Kconfig or in a 'base'
defconfig) and break the build for these 'add-on' configs. Also if
there is no record of what fragments can be built with what, it could
get awfully confusing.

I would suggest an interface where you can query which fragments are
available for a board, and that buildman support building them. For
that to work, we need some sort of structure. For example the config
fragment could have a line listing the defconfig / .config filename it
is intended to augment.

Regards,
Simon

Re: EFI breaks USB dual port detection - our observations

2023-07-18 Thread Da Xue

On Tue, Jul 18, 2023 at 3:13 PM Heinrich Schuchardt 
wrote:

>
>
> Am 18. Juli 2023 20:37:04 MESZ schrieb Suniel Mahesh <
> su...@amarulasolutions.com>:
> >Hi,
> >
> >I am testing the USB infrastructure on a Rockchip RK3328 based
> >roc-rk3328-cc target.
> >
> >The USB tree on the device is as follows:
> >
> >=> usb tree
> >USB device tree:
> >  1  Hub (480 Mb/s, 0mA)
> > u-boot EHCI Host Controller
> >
> >  1  Hub (12 Mb/s, 0mA)
> >  U-Boot Root Hub   (OHCI)
> >
> >  1  Hub (5 Gb/s, 0mA)
> > U-Boot XHCI Host Controller
> >
> >  1  Hub (480 Mb/s, 0mA)
> >  U-Boot Root Hub (DWC2)
> >
> >For some reason I am unable to detect storage device on DWC2 when two USB
> >drives
> >are simultaneously connected on EHCI and DWC2. Though it shows 2 storage
> >devices
> >when i do a "usb start/reset" and it gives usb_mass_storage.lun0 failed
> >message as
> >shown below.
>
> On which U-Boot version are you?
>

This is replicated on v2023.07.


>
> Cf.
> https://github.com/trini/u-boot/commit/180b7118bed8433f9cfe4b5ad62c6b0d901924f5
>
> Best regards
>
> Heinrich
>
>
>
> >
> >=> usb start
> >starting USB...
> >Bus usb@ff5c: USB EHCI 1.00
> >Bus usb@ff5d: USB OHCI 1.0
> >Bus usb@ff60: generic_phy_get_bulk : no phys property
> >Register 2000140 NbrPorts 2
> >Starting the controller
> >USB XHCI 1.10
> >Bus usb@ff58: USB DWC2
> >scanning bus usb@ff5c for devices...
> >2 USB Device(s) found
> >scanning bus usb@ff5d for devices... 1 USB Device(s) found
> >scanning bus usb@ff60 for devices... 1 USB Device(s) found
> >scanning bus usb@ff58 for devices...
> >Adding disk for usb_mass_storage.lun0 failed
> >(err=-9223372036854775788/0x8014)
> >device 'usb_mass_storage.lun0' failed to unbind
> >1 USB Device(s) found
> >device 'usb_mass_storage.lun0' failed to unbind
> >   scanning usb for storage devices... 2 Storage Device(s) found
> >
> >=> usb tree
> >USB device tree:
> >  1  Hub (480 Mb/s, 0mA)
> >  |  u-boot EHCI Host Controller
> >  |
> >  +-2  Mass Storage (480 Mb/s, 224mA)
> >   SanDisk Dual Drive 040130e3ee554b7078843f4eb331646
> >
> >  1  Hub (12 Mb/s, 0mA)
> >  U-Boot Root Hub
> >
> >  1  Hub (5 Gb/s, 0mA)
> > U-Boot XHCI Host Controller
> >
> >  1  Hub (480 Mb/s, 0mA)
> >  U-Boot Root Hub
> >
> >call trace: (detailed log:
> >https://gist.github.com/sunielmahesh/10088ea7b536cc9898ef787d9db43721)
> >
> >efi_install_multiple_protocol_interfaces_int
> >device path
>
> >/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x0,0x0)/USB(0x1,0x0)/Ctrl(0x0)
> >09576e91-6d3f-11d2-8e39-00a0c969723b, fcf1bae8,
> >fcf1bae0efi_locate_device_path: ret = EFI_SUCCESS
> >efi_install_multiple_protocol_interfaces_int: ret=0, dp->type:7f
> >Path
>
> >/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x0,0x0)/USB(0x1,0x0)/Ctrl(0x0)
> >already installed
> >install failed 8014
> >
> >However, an interesting observation is that if i disable
> CONFIG_EFI_LOADER,
> >then I am able to detect the storage devices
> >without any usb_mass_storage.lun0 failed message:
> >
> >=> usb reset
> >resetting USB...
> >Bus usb@ff5c: USB EHCI 1.00
> >Bus usb@ff5d: USB OHCI 1.0
> >Bus usb@ff60: generic_phy_get_bulk : no phys property
> >Register 2000140 NbrPorts 2
> >Starting the controller
> >USB XHCI 1.10
> >Bus usb@ff58: USB DWC2
> >scanning bus usb@ff5c for devices... 2 USB Device(s) found
> >scanning bus usb@ff5d for devices... 1 USB Device(s) found
> >scanning bus usb@ff60 for devices... 1 USB Device(s) found
> >scanning bus usb@ff58 for devices... 2 USB Device(s) found
> >   scanning usb for storage devices... 2 Storage Device(s) found
> >=> usb tree
> >USB device tree:
> >  1  Hub (480 Mb/s, 0mA)
> >  |  u-boot EHCI Host Controller
> >  |
> >  +-2  Mass Storage (480 Mb/s, 224mA)
> >   SanDisk Dual Drive 040130e3ee554b7078843f4eb331646
> >
> >  1  Hub (12 Mb/s, 0mA)
> >  U-Boot Root Hub
> >
> >  1  Hub (5 Gb/s, 0mA)
> > U-Boot XHCI Host Controller
> >
> >  1  Hub (480 Mb/s, 0mA)
> >  |   U-Boot Root Hub
> >  |
> >  +-2  Mass Storage (480 Mb/s, 224mA)
> >   SanDisk Dual Drive 04019c9b2e1a58f24ee318c3c123aa5
> >
> >Please share you thoughts.
> >
> >Thanks and Regards
>

[RFC] efi_driver: fix a parent issue in efi-created block devices

2023-07-18 Thread AKASHI Takahiro

An EFI application may create an EFI block device (EFI_BLOCK_IO_PROTOCOL) in
EFI world, which in turn generates a corresponding U-Boot block device based on
U-Boot's Driver Model.
The latter device, however, doesn't work as U-Boot proper block device
due to an issue in efi_driver's implementation. We saw discussions in the past,
most recently in [1].

  [1] https://lists.denx.de/pipermail/u-boot/2023-July/522565.html

This RFC patch tries to address (part of) the issue.
If it is considered acceptable, I will create a formal patch.

Withtout this patch,
===8<===
=> env set efi_selftest 'block device'
=> bootefi selftest
 ...

Summary: 0 failures

=> dm tree
 Class Index  Probed  DriverName
---
 root  0  [ + ]   root_driver   root_driver
 ...
 bootmeth  7  [   ]   vbe_simple|   `-- vbe_simple
 blk   0  [ + ]   efi_blk   `-- efiblk#0
 partition 0  [ + ]   blk_partition `-- efiblk#0:1
=> ls efiloader 0:1
** Bad device specification efiloader 0 **
Couldn't find partition efiloader 0:1
===>8===

With this patch applied, efiblk#0(:1) now gets accessible.

===8<===
=> env set efi_selftest 'block device'
=> bootefi selftest
 ...

Summary: 0 failures

=> dm tree
 Class Index  Probed  DriverName
---
 root  0  [ + ]   root_driver   root_driver
 ...
 bootmeth  7  [   ]   vbe_simple|   `-- vbe_simple
 efi   0  [ + ]   EFI block driver  `-- 
/VenHw(dbca4c98-6cb0-694d-0872-819c650cb7b8)
 blk   0  [ + ]   efi_blk   `-- efiblk#0
 partition 0  [ + ]   blk_partition `-- efiblk#0:1
=> ls efiloader 0:1
   13   hello.txt
7   u-boot.txt

2 file(s), 0 dir(s)
===>8===

Signed-off-by: AKASHI Takahiro 
---
 include/efi_driver.h |  2 +-
 lib/efi_driver/efi_block_device.c| 17 -
 lib/efi_driver/efi_uclass.c  |  8 +++-
 lib/efi_selftest/efi_selftest_block_device.c |  2 ++
 4 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/include/efi_driver.h b/include/efi_driver.h
index 63a95e4cf800..ed66796f3519 100644
--- a/include/efi_driver.h
+++ b/include/efi_driver.h
@@ -42,7 +42,7 @@ struct efi_driver_ops {
const efi_guid_t *child_protocol;
efi_status_t (*init)(struct efi_driver_binding_extended_protocol *this);
efi_status_t (*bind)(struct efi_driver_binding_extended_protocol *this,
-efi_handle_t handle, void *interface);
+efi_handle_t handle, void *interface, char *name);
 };
 
 #endif /* _EFI_DRIVER_H */
diff --git a/lib/efi_driver/efi_block_device.c 
b/lib/efi_driver/efi_block_device.c
index add00eeebbea..43b7ed7c973c 100644
--- a/lib/efi_driver/efi_block_device.c
+++ b/lib/efi_driver/efi_block_device.c
@@ -115,9 +115,9 @@ static ulong efi_bl_write(struct udevice *dev, lbaint_t 
blknr, lbaint_t blkcnt,
  * Return: status code
  */
 static efi_status_t
-efi_bl_create_block_device(efi_handle_t handle, void *interface)
+efi_bl_create_block_device(efi_handle_t handle, void *interface, struct 
udevice *parent)
 {
-   struct udevice *bdev = NULL, *parent = dm_root();
+   struct udevice *bdev = NULL;
efi_status_t ret;
int devnum;
char *name;
@@ -181,7 +181,7 @@ err:
  */
 static efi_status_t efi_bl_bind(
struct efi_driver_binding_extended_protocol *this,
-   efi_handle_t handle, void *interface)
+   efi_handle_t handle, void *interface, char *name)
 {
efi_status_t ret = EFI_SUCCESS;
struct efi_object *obj = efi_search_obj(handle);
@@ -191,8 +191,15 @@ static efi_status_t efi_bl_bind(
if (!obj || !interface)
return EFI_INVALID_PARAMETER;
 
-   if (!handle->dev)
-   ret = efi_bl_create_block_device(handle, interface);
+   if (!handle->dev) {
+   struct udevice *parent;
+
+   ret = device_bind_driver(dm_root(), "EFI block driver", name, 
&parent);
+   if (!ret)
+   ret = efi_bl_create_block_device(handle, interface, 
parent);
+   else
+   ret = EFI_DEVICE_ERROR;
+   }
 
return ret;
 }
diff --git a/lib/efi_driver/efi_uclass.c b/lib/efi_driver/efi_uclass.c
index 45f935198874..bf669742783e 100644
--- a/lib/efi_driver/efi_uclass.c
+++ b/lib/efi_driver/efi_uclass.c
@@ -145,7 +145,13 @@ static efi_status_t EFIAPI efi_uc_start(
ret = check_node_type(controller_handle);
if (ret != EFI_SUCCESS)
goto err;
-   ret = bp->ops->bind(bp, controller_handle, interface);
+
+   struct efi_handler *handler;
+   char tmpname[256] = "AppName";
+   ret = efi_search_protocol(controller_handle, &efi

[PATCH 7/7] MAINTAINERS: Add some missing directories or files

In a few cases we have MAINTAINERS entries that are missing obvious
paths or files. Typically this means a board directory that did not list
itself, but in a few cases we have a Kconfig file or similar.

Signed-off-by: Tom Rini 
---
 MAINTAINERS  | 1 +
 board/coreboot/coreboot/MAINTAINERS  | 4 +---
 board/devboards/dbm-soc1/MAINTAINERS | 1 +
 board/efi/efi-x86_app/MAINTAINERS| 2 ++
 board/efi/efi-x86_payload/MAINTAINERS| 1 +
 board/firefly/firefly-rk3308/MAINTAINERS | 3 ++-
 board/freescale/ls1043ardb/MAINTAINERS   | 1 -
 board/keymile/secu1/MAINTAINERS  | 1 +
 board/softing/vining_fpga/MAINTAINERS| 1 +
 board/terasic/de0-nano-soc/MAINTAINERS   | 1 +
 board/terasic/de1-soc/MAINTAINERS| 1 +
 board/terasic/de10-nano/MAINTAINERS  | 1 +
 board/terasic/de10-standard/MAINTAINERS  | 1 +
 board/terasic/sockit/MAINTAINERS | 1 +
 14 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 89e373813981..4a24a92460c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -272,6 +272,7 @@ M:  Fabio Estevam 
 R: NXP i.MX U-Boot Team 
 S: Maintained
 T: git https://source.denx.de/u-boot/custodians/u-boot-imx.git
+F: arch/Kconfig.nxp
 F: arch/arm/cpu/arm1136/mx*/
 F: arch/arm/cpu/arm926ejs/mx*/
 F: arch/arm/cpu/armv7/vf610/
diff --git a/board/coreboot/coreboot/MAINTAINERS 
b/board/coreboot/coreboot/MAINTAINERS
index ee12d32ce7cd..f77736580006 100644
--- a/board/coreboot/coreboot/MAINTAINERS
+++ b/board/coreboot/coreboot/MAINTAINERS
@@ -1,13 +1,11 @@
 COREBOOT BOARD
 M: Simon Glass 
 S: Maintained
-F: board/coreboot/coreboot/
+F: board/coreboot/
 F: include/configs/coreboot.h
 F: configs/coreboot_defconfig
 
 COREBOOT64 BOARD
 M: Simon Glass 
 S: Maintained
-F: board/coreboot/coreboot/
-F: include/configs/coreboot.h
 F: configs/coreboot64_defconfig
diff --git a/board/devboards/dbm-soc1/MAINTAINERS 
b/board/devboards/dbm-soc1/MAINTAINERS
index 625f2c889964..577eba5a281a 100644
--- a/board/devboards/dbm-soc1/MAINTAINERS
+++ b/board/devboards/dbm-soc1/MAINTAINERS
@@ -1,5 +1,6 @@
 Devboards.de DBM-SoC1 BOARD
 M: Marek Vasut 
 S: Maintained
+F: board/devboards/dbm-soc1/
 F: include/configs/socfpga_dbm_soc1.h
 F: configs/socfpga_dbm_soc1_defconfig
diff --git a/board/efi/efi-x86_app/MAINTAINERS 
b/board/efi/efi-x86_app/MAINTAINERS
index b292811a8f08..584619c51dff 100644
--- a/board/efi/efi-x86_app/MAINTAINERS
+++ b/board/efi/efi-x86_app/MAINTAINERS
@@ -1,6 +1,7 @@
 EFI-X86_APP32 BOARD
 M: Simon Glass 
 S: Maintained
+F: board/efi/Kconfig
 F: board/efi/efi-x86_app/
 F: include/configs/efi-x86_app.h
 F: configs/efi-x86_app32_defconfig
@@ -8,6 +9,7 @@ F:  configs/efi-x86_app32_defconfig
 EFI-X86_APP64 BOARD
 M: Simon Glass 
 S: Maintained
+F: board/efi/Kconfig
 F: board/efi/efi-x86_app/
 F: include/configs/efi-x86_app.h
 F: configs/efi-x86_app64_defconfig
diff --git a/board/efi/efi-x86_payload/MAINTAINERS 
b/board/efi/efi-x86_payload/MAINTAINERS
index abf3a1574b0f..d795d60e09e4 100644
--- a/board/efi/efi-x86_payload/MAINTAINERS
+++ b/board/efi/efi-x86_payload/MAINTAINERS
@@ -1,6 +1,7 @@
 EFI-X86_PAYLOAD BOARD
 M: Bin Meng 
 S: Maintained
+F: board/efi/Kconfig
 F: board/efi/efi-x86_payload/
 F: include/configs/efi-x86_payload.h
 F: configs/efi-x86_payload32_defconfig
diff --git a/board/firefly/firefly-rk3308/MAINTAINERS 
b/board/firefly/firefly-rk3308/MAINTAINERS
index 199079717e73..e584038a2033 100644
--- a/board/firefly/firefly-rk3308/MAINTAINERS
+++ b/board/firefly/firefly-rk3308/MAINTAINERS
@@ -1,5 +1,6 @@
 ROC-RK3308-CC
 M:  Andy Yan 
 S:  Maintained
-F:  board/firefly/firefly-rk3308/roc_cc_rk3308.c
+F:  board/firefly/firefly-rk3308/
 F:  configs/roc-cc-rk3308_defconfig
+F:  include/configs/firefly_rk3308.h
diff --git a/board/freescale/ls1043ardb/MAINTAINERS 
b/board/freescale/ls1043ardb/MAINTAINERS
index 36e7331538f8..8e14ba3608be 100644
--- a/board/freescale/ls1043ardb/MAINTAINERS
+++ b/board/freescale/ls1043ardb/MAINTAINERS
@@ -3,7 +3,6 @@ M:  Mingkai Hu 
 M: Rajesh Bhagat 
 S: Maintained
 F: board/freescale/ls1043ardb/
-F: board/freescale/ls1043ardb/ls1043ardb.c
 F: include/configs/ls1043ardb.h
 F: configs/ls1043ardb_defconfig
 F: configs/ls1043ardb_nand_defconfig
diff --git a/board/keymile/secu1/MAINTAINERS b/board/keymile/secu1/MAINTAINERS
index 8df25f8123e7..e441f252aa23 100644
--- a/board/keymile/secu1/MAINTAINERS
+++ b/board/keymile/secu1/MAINTAINERS
@@ -1,6 +1,7 @@
 Hitachi Power Grids SECU1 BOARD
 M: Holger Brunck 
 S: Maintained
+F: board/keymile/secu1/
 F: board/keymile/common/
 F: board/keymile/scripts/
 F: include/configs/socfpga_arria5_secu1.h
diff --git a/board/softing/vining_fpga/MAINTAINERS 
b/board/softing/vining_fpga/MAINTAINERS
index c2002fe3cefc..ed44b09f32

[PATCH 5/7] MAINTAINERS: Fix path typos and similar

We have a number of cases where the in-tree path of files and where
they presumably were when the first version of a patch were posted
differ slightly.  Correct these to point at where the files are now.

Signed-off-by: Tom Rini 
---
 board/anbernic/rgxx3_rk3566/MAINTAINERS   | 4 ++--
 board/broadcom/bcmns/MAINTAINERS  | 4 ++--
 board/bsh/imx6ulz_smm_m2/MAINTAINERS  | 2 +-
 board/cei/cei-tk1-som/MAINTAINERS | 2 +-
 board/comtrend/ar5315u/MAINTAINERS| 2 +-
 board/comtrend/ar5387un/MAINTAINERS   | 2 +-
 board/comtrend/ct5361/MAINTAINERS | 2 +-
 board/comtrend/vr3032u/MAINTAINERS| 2 +-
 board/comtrend/wap5813n/MAINTAINERS   | 2 +-
 board/data_modul/imx8mm_edm_sbc/MAINTAINERS   | 2 +-
 board/data_modul/imx8mp_edm_sbc/MAINTAINERS   | 2 +-
 board/google/chromebox_panther/MAINTAINERS| 2 +-
 board/hardkernel/odroid_go2/MAINTAINERS   | 2 +-
 board/pine64/pinebook-pro-rk3399/MAINTAINERS  | 2 +-
 board/pine64/pinephone-pro-rk3399/MAINTAINERS | 2 +-
 board/ronetix/imx7-cm/MAINTAINERS | 6 +++---
 board/seeed/npi_imx6ull/MAINTAINERS   | 2 +-
 board/solidrun/clearfog/MAINTAINERS   | 2 +-
 board/vamrs/rock960_rk3399/MAINTAINERS| 2 +-
 19 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/board/anbernic/rgxx3_rk3566/MAINTAINERS 
b/board/anbernic/rgxx3_rk3566/MAINTAINERS
index 647e49d28ab3..1c0d3fe7b5bf 100644
--- a/board/anbernic/rgxx3_rk3566/MAINTAINERS
+++ b/board/anbernic/rgxx3_rk3566/MAINTAINERS
@@ -1,6 +1,6 @@
 RGXX3-RK3566
 M: Chris Morgan 
 S: Maintained
-F: board/anbernic/rgxx3-rk3566
-F: include/configs/anbernic-rgxx3-rk3566
+F: board/anbernic/rgxx3_rk3566
+F: include/configs/anbernic-rgxx3-rk3566.h
 F: configs/anbernic-rgxx3_defconfig
diff --git a/board/broadcom/bcmns/MAINTAINERS b/board/broadcom/bcmns/MAINTAINERS
index 86b68c989cd4..63c6d8bb4aca 100644
--- a/board/broadcom/bcmns/MAINTAINERS
+++ b/board/broadcom/bcmns/MAINTAINERS
@@ -1,6 +1,6 @@
 BCMNS BOARD
 M: Linus Walleij 
 S: Maintained
-F: board/broadcom/bcmnsp/
+F: board/broadcom/bcmns/
 F: configs/bcmns_defconfig
-F: include/configs/bcmnsp.h
+F: include/configs/bcmns.h
diff --git a/board/bsh/imx6ulz_smm_m2/MAINTAINERS 
b/board/bsh/imx6ulz_smm_m2/MAINTAINERS
index 8f3d79dbb840..77a033c6cbb6 100644
--- a/board/bsh/imx6ulz_smm_m2/MAINTAINERS
+++ b/board/bsh/imx6ulz_smm_m2/MAINTAINERS
@@ -1,6 +1,6 @@
 MX6ULZ_SMM_M2 BOARD
 M: Michael Trimarchi 
 S: Maintained
-F: board/bsh/mx6ulz_smm_m2/
+F: board/bsh/imx6ulz_smm_m2/
 F: include/configs/imx6ulz_smm_m2.h
 F: configs/imx6ulz_smm_m2_defconfig
diff --git a/board/cei/cei-tk1-som/MAINTAINERS 
b/board/cei/cei-tk1-som/MAINTAINERS
index 192e1a34a762..f1817401a5df 100644
--- a/board/cei/cei-tk1-som/MAINTAINERS
+++ b/board/cei/cei-tk1-som/MAINTAINERS
@@ -1,6 +1,6 @@
 TK1-SOM BOARD
 M: peter.ch...@data61.csiro.au
 S: Maintained
-F: board/cei/tk1-som/
+F: board/cei/cei-tk1-som/
 F: include/configs/cei-tk1-som.h
 F: configs/cei-tk1-som_defconfig
diff --git a/board/comtrend/ar5315u/MAINTAINERS 
b/board/comtrend/ar5315u/MAINTAINERS
index 048073cb422b..0515e03f6065 100644
--- a/board/comtrend/ar5315u/MAINTAINERS
+++ b/board/comtrend/ar5315u/MAINTAINERS
@@ -1,6 +1,6 @@
 COMTREND AR-5315U BOARD
 M: Álvaro Fernández Rojas 
 S: Maintained
-F: board/comtrend/ar-5315u/
+F: board/comtrend/ar5315u/
 F: include/configs/comtrend_ar5315u.h
 F: configs/comtrend_ar5315u_ram_defconfig
diff --git a/board/comtrend/ar5387un/MAINTAINERS 
b/board/comtrend/ar5387un/MAINTAINERS
index bcaac64db09b..48757c9fd754 100644
--- a/board/comtrend/ar5387un/MAINTAINERS
+++ b/board/comtrend/ar5387un/MAINTAINERS
@@ -1,6 +1,6 @@
 COMTREND AR-5387UN BOARD
 M: Álvaro Fernández Rojas 
 S: Maintained
-F: board/comtrend/ar-5387un/
+F: board/comtrend/ar5387un/
 F: include/configs/comtrend_ar5387un.h
 F: configs/comtrend_ar5387un_ram_defconfig
diff --git a/board/comtrend/ct5361/MAINTAINERS 
b/board/comtrend/ct5361/MAINTAINERS
index aea737a0bbda..3373e5036be6 100644
--- a/board/comtrend/ct5361/MAINTAINERS
+++ b/board/comtrend/ct5361/MAINTAINERS
@@ -1,6 +1,6 @@
 COMTREND CT-5361 BOARD
 M: Álvaro Fernández Rojas 
 S: Maintained
-F: board/comtrend/ct-5361/
+F: board/comtrend/ct5361/
 F: include/configs/comtrend_ct5361.h
 F: configs/comtrend_ct5361_ram_defconfig
diff --git a/board/comtrend/vr3032u/MAINTAINERS 
b/board/comtrend/vr3032u/MAINTAINERS
index 833d7da4afa7..132101f4cd0c 100644
--- a/board/comtrend/vr3032u/MAINTAINERS
+++ b/board/comtrend/vr3032u/MAINTAINERS
@@ -1,6 +1,6 @@
 COMTREND VR-3032U BOARD
 M: Álvaro Fernández Rojas 
 S: Maintained
-F: board/comtrend/vr-3032u/
+F: board/comtrend/vr3032u/
 F: include/configs/comtrend_vr-3032u.h
 F: configs/comtrend_vr3032u_ram_defconfig
diff --git a/board/comtrend/wap5813n/MAINTAINERS

[PATCH 6/7] MAINTAINERS: Deal with '+' in paths

The listed paths are allowed to contain wildcards.  This includes the
'+' character which we have as a literal part of the path in a few
cases. Escape the '+' here so that files are matched.

Signed-off-by: Tom Rini 
---
 board/k+p/kp_imx53/MAINTAINERS | 3 ++-
 board/k+p/kp_imx6q_tpc/MAINTAINERS | 3 ++-
 board/l+g/vinco/MAINTAINERS| 2 +-
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/board/k+p/kp_imx53/MAINTAINERS b/board/k+p/kp_imx53/MAINTAINERS
index c105a93e7075..daf861160a41 100644
--- a/board/k+p/kp_imx53/MAINTAINERS
+++ b/board/k+p/kp_imx53/MAINTAINERS
@@ -1,6 +1,7 @@
 KP_IMX53_HSC BOARD
 M: Lukasz Majewski 
 S: Maintained
-F: board/k+p/kp_imx53/
+F: board/k\+p/kp_imx53/
+F: board/k\+p/bootscripts/tpcboot.cmd
 F: include/configs/kp_imx53.h
 F: configs/kp_imx53_defconfig
diff --git a/board/k+p/kp_imx6q_tpc/MAINTAINERS 
b/board/k+p/kp_imx6q_tpc/MAINTAINERS
index 6c4c8dd28e39..e54f4604c38b 100644
--- a/board/k+p/kp_imx6q_tpc/MAINTAINERS
+++ b/board/k+p/kp_imx6q_tpc/MAINTAINERS
@@ -1,6 +1,7 @@
 KP_IMX6Q_TPC BOARD
 M: Lukasz Majewski 
 S: Maintained
-F: board/k+p/kp_imx6q_tpc/
+F: board/k\+p/kp_imx6q_tpc/
+F: board/k\+p/bootscripts/tpcboot.cmd
 F: include/configs/kp_imx6q_tpc.h
 F: configs/kp_imx6q_tpc_defconfig
diff --git a/board/l+g/vinco/MAINTAINERS b/board/l+g/vinco/MAINTAINERS
index 0cd6044172a7..14b76b14d846 100644
--- a/board/l+g/vinco/MAINTAINERS
+++ b/board/l+g/vinco/MAINTAINERS
@@ -1,6 +1,6 @@
 VInCo Platform
 M: Gregory CLEMENT 
 S: Maintained
-F: board/l+g/vinco
+F: board/l\+g/vinco/
 F: include/configs/vinco.h
 F: configs/vinco_defconfig
-- 
2.34.1

[PATCH 4/7] MAINTAINERS: Add a number of "common" directories

A number of platforms have "common" directories that are in turn not
listed by the board MAINTAINERS file.  Add these directories in many
cases.

Signed-off-by: Tom Rini 
---
An alternative in some cases may be to have a
board/$(VENDOR)/MAINTAINERS file instead and rework the listings that
way.
---
 MAINTAINERS  | 1 +
 board/BuR/brppt1/MAINTAINERS | 1 +
 board/BuR/brppt2/MAINTAINERS | 1 +
 board/BuR/brsmarc1/MAINTAINERS   | 1 +
 board/BuR/brxre1/MAINTAINERS | 1 +
 board/LaCie/net2big_v2/MAINTAINERS   | 1 +
 board/LaCie/netspace_v2/MAINTAINERS  | 1 +
 board/Synology/ds109/MAINTAINERS | 1 +
 board/Synology/ds116/MAINTAINERS | 1 +
 board/Synology/ds414/MAINTAINERS | 1 +
 board/avionic-design/medcom-wide/MAINTAINERS | 1 +
 board/avionic-design/plutux/MAINTAINERS  | 1 +
 board/avionic-design/tec-ng/MAINTAINERS  | 1 +
 board/avionic-design/tec/MAINTAINERS | 1 +
 board/emulation/qemu-arm/MAINTAINERS | 1 +
 board/emulation/qemu-ppce500/MAINTAINERS | 1 +
 board/emulation/qemu-riscv/MAINTAINERS   | 1 +
 board/emulation/qemu-x86/MAINTAINERS | 2 ++
 board/engicam/imx6q/MAINTAINERS  | 1 +
 board/engicam/imx6ul/MAINTAINERS | 1 +
 board/engicam/imx8mm/MAINTAINERS | 1 +
 board/engicam/imx8mp/MAINTAINERS | 1 +
 board/engicam/px30_core/MAINTAINERS  | 1 +
 board/engicam/stm32mp1/MAINTAINERS   | 1 +
 board/gdsys/a38x/MAINTAINERS | 1 +
 board/gdsys/mpc8308/MAINTAINERS  | 1 +
 board/keymile/km83xx/MAINTAINERS | 2 ++
 board/keymile/kmcent2/MAINTAINERS| 2 ++
 board/keymile/pg-wcom-ls102xa/MAINTAINERS| 2 ++
 board/keymile/secu1/MAINTAINERS  | 2 ++
 board/toradex/apalis-imx8/MAINTAINERS| 1 +
 board/toradex/apalis-tk1/MAINTAINERS | 1 +
 board/toradex/apalis_imx6/MAINTAINERS| 1 +
 board/toradex/apalis_t30/MAINTAINERS | 1 +
 board/toradex/colibri-imx6ull/MAINTAINERS| 1 +
 board/toradex/colibri-imx8x/MAINTAINERS  | 1 +
 board/toradex/colibri_imx6/MAINTAINERS   | 1 +
 board/toradex/colibri_imx7/MAINTAINERS   | 1 +
 board/toradex/colibri_t20/MAINTAINERS| 1 +
 board/toradex/colibri_t30/MAINTAINERS| 1 +
 board/toradex/colibri_vf/MAINTAINERS | 1 +
 board/toradex/verdin-imx8mm/MAINTAINERS  | 1 +
 board/toradex/verdin-imx8mp/MAINTAINERS  | 1 +
 43 files changed, 48 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 697190558efe..89e373813981 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -282,6 +282,7 @@ F:  arch/arm/include/asm/arch-mx*/
 F: arch/arm/include/asm/arch-vf610/
 F: arch/arm/include/asm/mach-imx/
 F: board/freescale/*mx*/
+F: board/freescale/common/
 F: drivers/serial/serial_mxc.c
 
 ARM HISILICON
diff --git a/board/BuR/brppt1/MAINTAINERS b/board/BuR/brppt1/MAINTAINERS
index 6b45508f0f08..a974a97c1572 100644
--- a/board/BuR/brppt1/MAINTAINERS
+++ b/board/BuR/brppt1/MAINTAINERS
@@ -2,6 +2,7 @@ BRPPT1 BOARD
 M: Wolfgang Wallner 
 S: Maintained
 F: board/BuR/brppt1/
+F: board/BuR/common/
 F: include/configs/brppt1.h
 F: configs/brppt1_mmc_defconfig
 F: configs/brppt1_nand_defconfig
diff --git a/board/BuR/brppt2/MAINTAINERS b/board/BuR/brppt2/MAINTAINERS
index fe65188f3d83..bfeaa571a82c 100644
--- a/board/BuR/brppt2/MAINTAINERS
+++ b/board/BuR/brppt2/MAINTAINERS
@@ -2,5 +2,6 @@ BUR_PPT2 BOARD
 M: Wolfgang Wallner 
 S: Maintained
 F: board/BuR/brppt2/
+F: board/BuR/common/
 F: include/configs/brppt2.h
 F: configs/brppt2_defconfig
diff --git a/board/BuR/brsmarc1/MAINTAINERS b/board/BuR/brsmarc1/MAINTAINERS
index 8d1fe216a44a..7421f61fc43f 100644
--- a/board/BuR/brsmarc1/MAINTAINERS
+++ b/board/BuR/brsmarc1/MAINTAINERS
@@ -2,5 +2,6 @@ BRSMARC1 BOARD
 M: Wolfgang Wallner 
 S: Maintained
 F: board/BuR/brsmarc1/
+F: board/BuR/common/
 F: include/configs/brsmarc1.h
 F: configs/brsmarc1_defconfig
diff --git a/board/BuR/brxre1/MAINTAINERS b/board/BuR/brxre1/MAINTAINERS
index 5aa36713d4ee..f826a44b6ac2 100644
--- a/board/BuR/brxre1/MAINTAINERS
+++ b/board/BuR/brxre1/MAINTAINERS
@@ -2,6 +2,7 @@ BRXRE1 BOARD
 M: Wolfgang Wallner 
 S: Maintained
 F: board/BuR/brxre1/
+F: board/BuR/common/
 F: include/configs/brxre1.h
 F: configs/brxre1_defconfig
 F: arch/arm/dts/am335x-brxre1.dts
diff --git a/board/LaCie/net2big_v2/MAINTAINERS 
b/board/LaCie/net2big_v2/MAINTAINERS
index 7046e1b2c5c7..66e82196794e 100644
--- a/board/LaCie/net2big_v2/MAINTAINERS
+++ b/board/LaCie/net2big_v2/MAINTAINERS
@@ -7,6 +7,7 @@ F:  arch/arm/dts/kirkwood-d2net.dtsi
 F: arch/arm/dts/kirkwood-net2big.dts
 F: arch/arm/dts/kirkwood-net2big-u-boot.dtsi
 F: arch/arm/dts/kirkwood-netxbig.dtsi
+F: board/LaCie/common/
 F: board/LaCie/net2big_v

[PATCH 2/7] arm: Remove leftover MAINTAINERS files

These platforms have been removed, but the MAINTAINERS file was missed,
clean up.

Signed-off-by: Tom Rini 
---
 board/birdland/bav335x/MAINTAINERS   | 13 -
 board/broadcom/bcm11130/MAINTAINERS  |  6 --
 board/broadcom/bcm11130_nand/MAINTAINERS |  6 --
 board/broadcom/bcm28155_w1d/MAINTAINERS  |  6 --
 4 files changed, 31 deletions(-)
 delete mode 100644 board/birdland/bav335x/MAINTAINERS
 delete mode 100644 board/broadcom/bcm11130/MAINTAINERS
 delete mode 100644 board/broadcom/bcm11130_nand/MAINTAINERS
 delete mode 100644 board/broadcom/bcm28155_w1d/MAINTAINERS

diff --git a/board/birdland/bav335x/MAINTAINERS 
b/board/birdland/bav335x/MAINTAINERS
deleted file mode 100644
index 45dcfcb1e6ed..
--- a/board/birdland/bav335x/MAINTAINERS
+++ /dev/null
@@ -1,13 +0,0 @@
-BAV335x BOARD
-M: Gilles Gameiro 
-S: Maintained
-F: include/configs/bav335x.h
-F: board/birdland/bav335x/Kconfig
-F: board/birdland/bav335x/Makefile
-F: board/birdland/bav335x/README
-F: board/birdland/bav335x/board.c
-F: board/birdland/bav335x/board.h
-F: board/birdland/bav335x/mux.c
-F: board/birdland/bav335x/u-boot.lds
-F: configs/birdland_bav335a_defconfig
-F: configs/birdland_bav335b_defconfig
diff --git a/board/broadcom/bcm11130/MAINTAINERS 
b/board/broadcom/bcm11130/MAINTAINERS
deleted file mode 100644
index 54783501e6d5..
--- a/board/broadcom/bcm11130/MAINTAINERS
+++ /dev/null
@@ -1,6 +0,0 @@
-BCM11130 BOARD
-M: Steve Rae 
-S: Maintained
-F: board/broadcom/bcm28155_ap/
-F: include/configs/bcm_ep_board.h
-F: configs/bcm11130_defconfig
diff --git a/board/broadcom/bcm11130_nand/MAINTAINERS 
b/board/broadcom/bcm11130_nand/MAINTAINERS
deleted file mode 100644
index 4cf66b7e4a6a..
--- a/board/broadcom/bcm11130_nand/MAINTAINERS
+++ /dev/null
@@ -1,6 +0,0 @@
-BCM11130_NAND BOARD
-M: Steve Rae 
-S: Maintained
-F: board/broadcom/bcm28155_ap/
-F: include/configs/bcm_ep_board.h
-F: configs/bcm11130_nand_defconfig
diff --git a/board/broadcom/bcm28155_w1d/MAINTAINERS 
b/board/broadcom/bcm28155_w1d/MAINTAINERS
deleted file mode 100644
index c0558e7f2554..
--- a/board/broadcom/bcm28155_w1d/MAINTAINERS
+++ /dev/null
@@ -1,6 +0,0 @@
-BCM28155_W1D BOARD
-M: Steve Rae 
-S: Maintained
-F: board/broadcom/bcm28155_ap/
-F: include/configs/bcm28155_ap.h
-F: configs/bcm28155_w1d_defconfig
-- 
2.34.1

[PATCH 3/7] xes: Remove leftover code

The platforms here have been removed, but the common code directory was
forgotten.  Clean up.

Signed-off-by: Tom Rini 
---
 board/xes/common/Makefile|  9 -
 board/xes/common/board.c | 67 
 board/xes/common/fsl_8xxx_clk.c  | 54 -
 board/xes/common/fsl_8xxx_misc.c | 43 
 board/xes/common/fsl_8xxx_misc.h | 11 --
 5 files changed, 184 deletions(-)
 delete mode 100644 board/xes/common/Makefile
 delete mode 100644 board/xes/common/board.c
 delete mode 100644 board/xes/common/fsl_8xxx_clk.c
 delete mode 100644 board/xes/common/fsl_8xxx_misc.c
 delete mode 100644 board/xes/common/fsl_8xxx_misc.h

diff --git a/board/xes/common/Makefile b/board/xes/common/Makefile
deleted file mode 100644
index b00accca1be0..
--- a/board/xes/common/Makefile
+++ /dev/null
@@ -1,9 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-#
-# (C) Copyright 2006
-# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-
-obj-$(CONFIG_MPC86xx)  += fsl_8xxx_clk.o
-obj-$(CONFIG_ARCH_P2020)   += fsl_8xxx_clk.o
-obj-$(CONFIG_MPC85xx)  += fsl_8xxx_misc.o board.o
-obj-$(CONFIG_MPC86xx)  += fsl_8xxx_misc.o board.o
diff --git a/board/xes/common/board.c b/board/xes/common/board.c
deleted file mode 100644
index 053b07a0b70f..
--- a/board/xes/common/board.c
+++ /dev/null
@@ -1,67 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright 2009 Extreme Engineering Solutions, Inc.
- */
-
-#include 
-#include 
-#include "fsl_8xxx_misc.h"
-#include 
-
-int checkboard(void)
-{
-   char name[] = CONFIG_SYS_BOARD_NAME;
-   char buf[64];
-   char *s;
-   int i;
-
-#ifdef CONFIG_SYS_FORM_CUSTOM
-   s = "Custom";
-#elif CONFIG_SYS_FORM_6U_CPCI
-   s = "6U CompactPCI";
-#elif CONFIG_SYS_FORM_ATCA_PMC
-   s = "ATCA w/PMC";
-#elif CONFIG_SYS_FORM_ATCA_AMC
-   s = "ATCA w/AMC";
-#elif CONFIG_SYS_FORM_VME
-   s = "VME";
-#elif CONFIG_SYS_FORM_6U_VPX
-   s = "6U VPX";
-#elif CONFIG_SYS_FORM_PMC
-   s = "PMC";
-#elif CONFIG_SYS_FORM_PCI
-   s = "PCI";
-#elif CONFIG_SYS_FORM_3U_CPCI
-   s = "3U CompactPCI";
-#elif CONFIG_SYS_FORM_AMC
-   s = "AdvancedMC";
-#elif CONFIG_SYS_FORM_XMC
-   s = "XMC";
-#elif CONFIG_SYS_FORM_PMC_XMC
-   s = "PMC/XMC";
-#elif CONFIG_SYS_FORM_PCI_EXPRESS
-   s = "PCI Express";
-#elif CONFIG_SYS_FORM_3U_VPX
-   s = "3U VPX";
-#else
-#error "Form factor not defined"
-#endif
-
-   name[strlen(name) - 1] += get_board_derivative();
-   printf("Board: X-ES %s %s SBC\n", name, s);
-
-   /* Display board specific information */
-   puts("   ");
-   i = env_get_f("board_rev", buf, sizeof(buf));
-   if (i > 0)
-   printf("Rev %s, ", buf);
-   i = env_get_f("serial#", buf, sizeof(buf));
-   if (i > 0)
-   printf("Serial# %s, ", buf);
-   i = env_get_f("board_cfg", buf, sizeof(buf));
-   if (i > 0)
-   printf("Cfg %s", buf);
-   puts("\n");
-
-   return 0;
-}
diff --git a/board/xes/common/fsl_8xxx_clk.c b/board/xes/common/fsl_8xxx_clk.c
deleted file mode 100644
index c36b2afd50ed..
--- a/board/xes/common/fsl_8xxx_clk.c
+++ /dev/null
@@ -1,54 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright 2008 Extreme Engineering Solutions, Inc.
- */
-
-#include 
-#include 
-#include 
-
-/*
- * Return SYSCLK input frequency - 50 MHz or 66 MHz depending on POR config
- */
-unsigned long get_board_sys_clk(void)
-{
-#if defined(CONFIG_MPC85xx)
-   volatile ccsr_gur_t *gur = (void *)(CFG_SYS_MPC85xx_GUTS_ADDR);
-#elif defined(CONFIG_MPC86xx)
-   immap_t *immap = (immap_t *)CONFIG_SYS_IMMR;
-   volatile ccsr_gur_t *gur = &immap->im_gur;
-#endif
-
-   if (in_be32(&gur->gpporcr) & 0x1)
-   return ;
-   else
-#ifdef CONFIG_ARCH_P2020
-   return 1;
-#else
-   return 5000;
-#endif
-}
-
-#ifdef CONFIG_MPC85xx
-/*
- * Return DDR input clock - synchronous with SYSCLK or 66 MHz
- * Note: 86xx doesn't support asynchronous DDR clk
- */
-unsigned long get_board_ddr_clk(void)
-{
-   volatile ccsr_gur_t *gur = (void *)(CFG_SYS_MPC85xx_GUTS_ADDR);
-   u32 ddr_ratio = (in_be32(&gur->porpllsr) & 0x3e00) >> 9;
-
-   if (ddr_ratio == 0x7)
-   return get_board_sys_clk();
-
-#ifdef CONFIG_ARCH_P2020
-   if (in_be32(&gur->gpporcr) & 0x2)
-   return ;
-   else
-   return 1;
-#else
-   return ;
-#endif
-}
-#endif
diff --git a/board/xes/common/fsl_8xxx_misc.c b/board/xes/common/fsl_8xxx_misc.c
deleted file mode 100644
index bc7e5c5764f8..
--- a/board/xes/common/fsl_8xxx_misc.c
+++ /dev/null
@@ -1,43 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright 2008 Extreme Engineering Solutions, Inc.
- */
-
-#include 
-#include 
-#ifdef CONFIG_PCA953X
-#include 
-
-/*
- * Determ

[PATCH 1/7] arm: Remove more remnants of bcmcygnus

Remove some leftover files from the bcmcygnus platform.

Signed-off-by: Tom Rini 
---
 arch/arm/Kconfig   | 15 +-
 board/broadcom/bcm_ep/Makefile |  5 --
 board/broadcom/bcm_ep/board.c  | 86 --
 3 files changed, 1 insertion(+), 105 deletions(-)
 delete mode 100644 board/broadcom/bcm_ep/Makefile
 delete mode 100644 board/broadcom/bcm_ep/board.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b3115b054c8c..3c0cf3c9ae21 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -357,7 +357,7 @@ config SYS_ARM_ARCH
 
 choice
prompt "Select the ARM data write cache policy"
-   default SYS_ARM_CACHE_WRITETHROUGH if TARGET_BCMCYGNUS || TARGET_BCMNS 
|| RZA1
+   default SYS_ARM_CACHE_WRITETHROUGH if TARGET_BCMNS || RZA1
default SYS_ARM_CACHE_WRITEBACK
 
 config SYS_ARM_CACHE_WRITEBACK
@@ -668,19 +668,6 @@ config TARGET_VEXPRESS_CA9X4
select CPU_V7A
select PL011_SERIAL
 
-config TARGET_BCMCYGNUS
-   bool "Support bcmcygnus"
-   select CPU_V7A
-   select GPIO_EXTRA_HEADER
-   select IPROC
-   imply BCM_SF2_ETH
-   imply BCM_SF2_ETH_GMAC
-   imply CMD_HASH
-   imply CRC32_VERIFY
-   imply FAT_WRITE
-   imply HASH_VERIFY
-   imply NETDEVICES
-
 config TARGET_BCMNS
bool "Support Broadcom Northstar"
select CPU_V7A
diff --git a/board/broadcom/bcm_ep/Makefile b/board/broadcom/bcm_ep/Makefile
deleted file mode 100644
index 29a3ea7eda17..
--- a/board/broadcom/bcm_ep/Makefile
+++ /dev/null
@@ -1,5 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-#
-# Copyright 2014 Broadcom Corporation.
-
-obj-y  += board.o
diff --git a/board/broadcom/bcm_ep/board.c b/board/broadcom/bcm_ep/board.c
deleted file mode 100644
index e91fa40e640c..
--- a/board/broadcom/bcm_ep/board.c
+++ /dev/null
@@ -1,86 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright 2014 Broadcom Corporation.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-DECLARE_GLOBAL_DATA_PTR;
-
-/*
- * board_init - early hardware init
- */
-int board_init(void)
-{
-   /*
-* Address of boot parameters passed to kernel
-* Use default offset 0x100
-*/
-   gd->bd->bi_boot_params = CFG_SYS_SDRAM_BASE + 0x100;
-
-   return 0;
-}
-
-/*
- * dram_init - sets u-boot's idea of sdram size
- */
-int dram_init(void)
-{
-   gd->ram_size = get_ram_size((long *)CFG_SYS_SDRAM_BASE,
-   CFG_SYS_SDRAM_SIZE);
-   return 0;
-}
-
-int dram_init_banksize(void)
-{
-   gd->bd->bi_dram[0].start = CFG_SYS_SDRAM_BASE;
-   gd->bd->bi_dram[0].size = gd->ram_size;
-
-   return 0;
-}
-
-int board_early_init_f(void)
-{
-   uint32_t status = 0;
-
-   /* Setup PLL if required */
-#if defined(CONFIG_ARMCLK)
-   armpll_config(CONFIG_ARMCLK);
-#endif
-
-   return status;
-}
-
-#ifdef CONFIG_ARMV7_NONSEC
-void smp_set_core_boot_addr(unsigned long addr, int corenr)
-{
-}
-
-void smp_kick_all_cpus(void)
-{
-}
-
-void smp_waitloop(unsigned previous_address)
-{
-}
-#endif
-
-#ifdef CONFIG_BCM_SF2_ETH
-int board_eth_init(struct bd_info *bis)
-{
-   int rc = -1;
-   printf("Registering BCM sf2 eth\n");
-   rc = bcm_sf2_eth_register(bis, 0);
-   return rc;
-}
-#endif
-- 
2.34.1

Double free on xhci_register failure.

2023-07-18 Thread Richard Habeeb

Hi all,

drivers/core/device.c will call `device_free()` after xhci_register already
frees the private device data. This causes a memory corruption and crash on
my RPI4B. I believe the solution is to remove the free call in
xhci_register (
https://github.com/u-boot/u-boot/blob/master/drivers/usb/host/xhci.c#L1421),
thoughts?

-Richard Habeeb

fdt_high default value causes unbootable kernel due to misalignment

2023-07-18 Thread Tim van der Staaij | Zign

Hello,

When I was using U-Boot with a dart_6ul board I occasionally had fitimages that 
U-Boot would attempt to boot just fine, but the kernel wouldn't actually boot. 
Debugging found that this was correlated with the header length of the 
fitImage. Then I noticed this remark in doc/usage/environment.rst about 
fdt_high:

>If this is set to the special value 0x (32-bit machines) or
>0x (64-bit machines) then the fdt will not be copied at
>all on boot. For this to work it must reside in writable memory, have
>sufficient padding on the end of it for u-boot to add the information
>it needs into it, and the memory must be accessible by the kernel.
>This usage is strongly discouraged however as it also stops U-Boot
>from ensuring the device tree starting address is properly aligned
>and a misaligned tree will cause OS failures.

And indeed, fdt_high is set to 0x in the include/configs/dart_6ul.h 
that I was using. Since mkimage only guarantees 32-bit alignment of the device 
tree blob within the fitimage, and not the 64-bit alignment that Linux 
requires, this is basically a 50/50 coin flip. Something simple like adding a 
few characters to the description string in the fitimage header can make or 
break the alignment.

Personally I fixed this by removing the fdt_high altogether, which makes U-Boot 
copy the device tree to an appropriate location. I assume this only works in my 
situation because I only have half a GiB of RAM and therefore do not have any 
high memory. I can imagine my fix would be problematic for board variants with 
more RAM, the setting doesn't exist without a reason of course.

It looks like this issue is not limited to my board; the same usage of fdt_high 
can be found in many other board configs. I'm not going to suggest what the 
best fix is because I lack detailed knowledge, but I will pitch that perhaps 
omitting fdt_high by default is at least preferable to a value that is 
"strongly discouraged" and causes Linux boot failures somewhat arbitrarily.

Kind regards,

Tim

Re: [PATCH 0/8] Some fixes for the rockchip dw_mipi_dsi driver

2023-07-18 Thread Christopher Morgan

I’ve been on holiday and not able to add my Tested-By yet, I do apologize. It 
will probably be another week and a half before I can, but I will check these 
out and if they cause problems I’ll let you know/start work on a fix.

Thank you.

> On Jul 17, 2023, at 11:01 AM, Anatolij Gustschin  wrote:
> 
> On Thu, 13 Jul 2023 18:03:48 +0200
> Ondřej Jirman m...@xff.cz wrote:
> 
>>> On Thu, Jul 13, 2023 at 05:47:47PM +0200, Anatolij Gustschin wrote:
>>> 
>>> On Thu, 13 Jul 2023 16:51:36 +0200
>>> Ondřej Jirman m...@xff.cz wrote:
>>> 
 Hi,
 
 On Mon, May 22, 2023 at 11:47:00PM +0200, megi xff wrote:  
> 
> 
> From: Ondrej Jirman 
> 
> These are just random fixes for bugs I found while eyeballing the code 
> and porting
> it to work with RK3399.
 
 It would be nice if somebody merged this. I'd like to add display support 
 for
 a few boards, and these patches are just fairly obvious bugfixes in new 
 code
 added in 2023.07 that I hoped would get merged in the bugfix part of the 
 merge
 window.  
>>> 
>>> I hoped to get a Tested-by for this series to make sure it does not break
>>> current users.  
>> 
>> It's a miracle it even works for the current users, given the wrong
>> way the current code writes to GRF registers, which makes it to have
>> no intended effect, etc.
>> 
>> Anyway, is there some upper limit to wait for Tested-by? 2 months seems
>> excessive. Just so I can remind myself sooner next time. :)
>> 
>> I can understand a few weeks, but 2 months just deters contributions.
> 
> I usually apply new patches during the merge window (we have three months
> release cycle) and this patch series was sent when the merge window was
> closed. If patches are bug fixes (like in this case) I prefer to get them
> tested by someone who has the actual hardware. When there is an Acked-by
> or Tested-by, then I apply the fixes for -rcX. We already had several cases
> in the past where simple and obvious timing fixes in the driver broke
> display support for in tree boards, therefore I'm somewhat reluctant to
> apply fixes for -rcX without Tested-by.
> 
> --
> Anatolij

Re: [PATCH v10 3/4] Boot var automatic management for removable medias

2023-07-18 Thread Raymond Mao

Hi Heinrich,

I checkouted the 'origin/removable_medias' branch from the 'EFI U-Boot
Custodian Tree'.
Run the secureboot test suite on the sandbox locally by './test/py/test.py
--bd sandbox --build -k efi_secboot'.
But there are no errors observed for 'test_signed.py'.
Below is the output logs:
```
./test/py/test.py --bd sandbox --build -k efi_secboot
+make O=/home/raymond/upstream/U-Boot-custodian/u-boot-efi/build-sandbox -s
sandbox_defconfig
+make O=/home/raymond/upstream/U-Boot-custodian/u-boot-efi/build-sandbox -s
-j2
===
test session starts
===
platform linux -- Python 3.10.9, pytest-6.2.5, py-1.10.0, pluggy-0.13.0
rootdir: /home/raymond/upstream/U-Boot-custodian/u-boot-efi/test/py,
configfile: pytest.ini
plugins: xdist-2.5.0, forked-1.6.0
collected 1147 items / 1128 deselected / 19 selected



test/py/tests/test_efi_secboot/test_authvar.py .

 [ 26%]
test/py/tests/test_efi_secboot/test_signed.py 

 [ 68%]
test/py/tests/test_efi_secboot/test_signed_intca.py ...

[ 84%]
test/py/tests/test_efi_secboot/test_unsigned.py ...

[100%]

=
19 passed, 1128 deselected in 78.28s (0:01:18)
==
```
Is it a pipeline issue? I didn't find a button to retrigger the failed
jobs. Do I have the permissions?


The HEAD of my testing workspace is on:
```
commit c88c134c29934654a696aef61ba63ff2c9a8481e (HEAD -> removable_medias,
origin/removable_medias)
Author: Raymond Mao 
Date:   Mon Jun 19 14:23:00 2023 -0700

Boot var automatic management for removable medias
```
Same as the one for pipeline:
https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/16948

Thanks!
Regards,
Raymond

On Tue, 18 Jul 2023 at 11:35, Heinrich Schuchardt 
wrote:

> On 18.07.23 11:03, Masahisa Kojima wrote:
> > Hi Raymond,
> >
> > On Tue, 18 Jul 2023 at 05:23, Raymond Mao 
> wrote:
> >>
> >> Hi Heinrich,
> >>
> >> I run 'make tests' with the patches locally but no errors observed from
> 'test_signed.py', below are few lines from the output console:
> >> ```
> >> test/py/tests/test_efi_secboot/test_signed.py 
>
> [  90%]
> >> ```
> >
> > I think the test cases are just skipped, not executed.
> >
> > I guess that some required packages are missing on the host machine,
> > such as sbsigntool, efitools and libguestfs-tools.
> > build-sandbox/test-log.html will help to analyze why the tests are
> skipped.
> >
> > The following document describes prerequisites to run python tests.
> > https://u-boot.readthedocs.io/en/latest/develop/py_testing.html
> >
> > 'make tests' runs many test cases and takes time.
> > './test/py/test.py --bd sandbox --build -k efi_secboot' will run only
> > the efi_secboot test
> > and it will be useful for debugging purposes.
> >
> > Thanks,
> > Masahisa Kojima
>
> To get more output describing why tests are skipped or fail use
>
> export PYTEST_ADDOPTS="-ra"
>
> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/16948
> shows the errors with the suggested patch.
>
> Best regards
>
> Heinrich
>
> >
> >
> >>
> >> Regards,
> >> Raymond
> >>
> >> On Sat, 15 Jul 2023 at 05:19, Heinrich Schuchardt 
> wrote:
> >>>
> >>> On 7/9/23 10:56, Heinrich Schuchardt wrote:
>  On 6/19/23 23:23, Raymond Mao wrote:
> > Changes for complying to EFI spec §3.5.1.1
> > 'Removable Media Boot Behavior'.
> > Boot variables can be automatically generated during a removable
> > media is probed. At the same time, unused boot variables will be
> > detected and removed.
> >
> > Please note that currently the function 'efi_disk_remove' has no
> > ability to distinguish below two scenarios
> > a) Unplugging of a removable media under U-Boot
> > b) U-Boot exiting and booting an OS
> > Thus currently the boot variables management is not added into
> > 'efi_disk_remove' to avoid boot options being added/erased
> > repeatedly under scenario b) during power cycles
> > See TODO comments under function 'efi_disk_remove' for more details
> >
> > Signed-off-by: Raymond Mao 
> > ---
> > Changes in v3
> > - Split the patch into moving and renaming functions and
> > individual patches for each changed functionality
> > Changes in v5
> > - Move function call of efi_bootmgr_update_media_device_boot_option()
> > from efi_init_variables() to efi_init_obj_list()
> > Changes in v6
> > - Revert unrelated changes
> > Changes in v7
> > - adapt the return code of function

Re: [PATCH 12/18] include: armv7: Enable distroboot across all configs

Hi,

On Mon, 17 Jul 2023 at 07:45, Nishanth Menon  wrote:
>
> On 13:39-20230717, Manorit Chawdhry wrote:
>
> [...]
>
> > > > +
> > > > +#define BOOT_TARGET_DEVICES(func) \
> > > > +   BOOT_TARGET_MMC(func) \
> > > > +   BOOT_TARGET_USB(func) \
> > > > +   BOOT_TARGET_PXE(func) \
> > > > +   BOOT_TARGET_DHCP(func)
> > > > +
> > > > +#include 
> > >
> > > With standard boot you should be able to drop all of the above, since
> > > the normal order is mmc, usb, pxe, dhcp by default. But you can add a
> > > "boot_targets" env var if you like.
> > >
> > > The one exception is TI_MMC. What is that, exactly?
> > >
> >
> > TI_MMC is our custom boot mechanism that we actually support as a part
> > of our SDK, we had been using this in am62ax like the way I have done
> > here, am not really sure why we hooked it into the distroboot if that is
> > the question that you are asking, maybe Nishanth/Bryan can help with
> > that as Bryan had done it for am62ax [0] but we do this boot mechanism
> > for sure.
> >
> > [0]: https://lore.kernel.org/u-boot/20221224011525.4696-5...@ti.com/
> >
>
> 2 cents:
> There is no reason for us to have our own TI_MMC option. we should just
> go standard_boot. all the SDK stuff really should be fixed if they dont
> work with standard_boot.

If for some reason you do need something special, it could be
implemented as a new bootmeth, as has been done for ChromeOS.

Regards,
Simon

[PATCH v2 7/7] Makefile: Show binman missing blob message

When binman is invoked during a build of U-Boot and an external blob is
missing, the user is usually presented with a generic file not found in
input path message.

Invoke binman with --allow-missing so that binman can show relevant
missing blob help messages. Build continue to fail with missing blobs
unless BINMAN_ALLOW_MISSING=1 is used, same as before.

This changes the following error message during a normal build:

  binman: Filename 'atf-bl31' not found in input path (...)

to the following:

  Image 'itb' is missing external blobs and is non-functional: atf-blob

  /binman/itb/fit/images/atf/atf-blob (bl31.bin):
 See the documentation for your board. You may need to build ARM Trusted
 Firmware and build with BL31=/path/to/bl31.bin

Signed-off-by: Jonas Karlman 
Reviewed-by: Simon Glass 
---
v2:
- Collect r-b tag

 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 87f9fc786e8c..7850c171a042 100644
--- a/Makefile
+++ b/Makefile
@@ -1334,7 +1334,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if 
$(BINMAN_DEBUG),-D) \
 --toolpath $(objtree)/tools \
$(if $(BINMAN_VERBOSE),-v$(BINMAN_VERBOSE)) \
build -u -d u-boot.dtb -O . -m \
-   $(if $(BINMAN_ALLOW_MISSING),--allow-missing --ignore-missing) \
+   --allow-missing $(if $(BINMAN_ALLOW_MISSING),--ignore-missing) \
-I . -I $(srctree) -I $(srctree)/board/$(BOARDDIR) \
-I arch/$(ARCH)/dts -a of-list=$(CONFIG_OF_LIST) \
$(foreach f,$(BINMAN_INDIRS),-I $(f)) \
-- 
2.41.0

[PATCH v2 6/7] binman: Show filename in missing blob help message

Show the filename next to the node path in missing blob help messages,
also show a generic missing blob message when there was no help message
for the help tag.

Signed-off-by: Jonas Karlman 
Reviewed-by: Simon Glass 
---
v2:
- Add test
- Collect r-b tag

 tools/binman/control.py | 13 ++---
 tools/binman/ftest.py   |  2 ++
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/tools/binman/control.py b/tools/binman/control.py
index fe5d704c4048..048d74a0b786 100644
--- a/tools/binman/control.py
+++ b/tools/binman/control.py
@@ -112,8 +112,8 @@ def _ReadMissingBlobHelp():
 _FinishTag(tag, msg, result)
 return result
 
-def _ShowBlobHelp(level, path, text):
-tout.do_output(level, '%s:' % path)
+def _ShowBlobHelp(level, path, text, fname):
+tout.do_output(level, '%s (%s):' % (path, fname))
 for line in text.splitlines():
 tout.do_output(level, '   %s' % line)
 tout.do_output(level, '')
@@ -133,10 +133,17 @@ def _ShowHelpForMissingBlobs(level, missing_list):
 tags = entry.GetHelpTags()
 
 # Show the first match help message
+shown_help = False
 for tag in tags:
 if tag in missing_blob_help:
-_ShowBlobHelp(level, entry._node.path, missing_blob_help[tag])
+_ShowBlobHelp(level, entry._node.path, missing_blob_help[tag],
+  entry.GetDefaultFilename())
+shown_help = True
 break
+# Or a generic help message
+if not shown_help:
+_ShowBlobHelp(level, entry._node.path, "Missing blob",
+  entry.GetDefaultFilename())
 
 def GetEntryModules(include_testing=True):
 """Get a set of entry class implementations
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 40ef6e5dce99..b2f78d3d0adb 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -3781,6 +3781,7 @@ class TestFunctional(unittest.TestCase):
allow_missing=True)
 self.assertEqual(103, ret)
 err = stderr.getvalue()
+self.assertIn('(missing-file)', err)
 self.assertRegex(err, "Image 'image'.*missing.*: blob-ext")
 self.assertIn('Some images are invalid', err)
 
@@ -3791,6 +3792,7 @@ class TestFunctional(unittest.TestCase):
allow_missing=True, ignore_missing=True)
 self.assertEqual(0, ret)
 err = stderr.getvalue()
+self.assertIn('(missing-file)', err)
 self.assertRegex(err, "Image 'image'.*missing.*: blob-ext")
 self.assertIn('Some images are invalid', err)
 
-- 
2.41.0

[PATCH v2 5/7] binman: Fix blank line usage for invalid images warning text

There is no blank line between last missing blob help message and the
header line for optional blob help messages.

  Image 'simple-bin' is missing external blobs and is non-functional: atf-bl31

  /binman/simple-bin/fit/images/@atf-SEQ/atf-bl31:
 See the documentation for your board. You may need to build ARM Trusted
 Firmware and build with BL31=/path/to/bl31.bin
  Image 'simple-bin' is missing external blobs but is still functional: tee-os

  /binman/simple-bin/fit/images/@tee-SEQ/tee-os:
 See the documentation for your board. You may need to build Open Portable
 Trusted Execution Environment (OP-TEE) and build with TEE=/path/to/tee.bin

  Some images are invalid

With this a blank line is inserted to make the text more readable.

Signed-off-by: Jonas Karlman 
Reviewed-by: Simon Glass 
---
v2:
- Collect r-b tag

 tools/binman/control.py | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/tools/binman/control.py b/tools/binman/control.py
index e5682bf2d3db..fe5d704c4048 100644
--- a/tools/binman/control.py
+++ b/tools/binman/control.py
@@ -113,9 +113,10 @@ def _ReadMissingBlobHelp():
 return result
 
 def _ShowBlobHelp(level, path, text):
-tout.do_output(level, '\n%s:' % path)
+tout.do_output(level, '%s:' % path)
 for line in text.splitlines():
 tout.do_output(level, '   %s' % line)
+tout.do_output(level, '')
 
 def _ShowHelpForMissingBlobs(level, missing_list):
 """Show help for each missing blob to help the user take action
@@ -658,7 +659,7 @@ def ProcessImage(image, update_fdt, write_map, 
get_contents=True,
 missing_list = []
 image.CheckMissing(missing_list)
 if missing_list:
-tout.error("Image '%s' is missing external blobs and is 
non-functional: %s" %
+tout.error("Image '%s' is missing external blobs and is 
non-functional: %s\n" %
(image.name, ' '.join([e.name for e in missing_list])))
 _ShowHelpForMissingBlobs(tout.ERROR, missing_list)
 
@@ -666,7 +667,7 @@ def ProcessImage(image, update_fdt, write_map, 
get_contents=True,
 image.CheckFakedBlobs(faked_list)
 if faked_list:
 tout.warning(
-"Image '%s' has faked external blobs and is non-functional: %s" %
+"Image '%s' has faked external blobs and is non-functional: %s\n" %
 (image.name, ' '.join([os.path.basename(e.GetDefaultFilename())
for e in faked_list])))
 
@@ -674,7 +675,7 @@ def ProcessImage(image, update_fdt, write_map, 
get_contents=True,
 image.CheckOptional(optional_list)
 if optional_list:
 tout.warning(
-"Image '%s' is missing optional external blobs but is still 
functional: %s" %
+"Image '%s' is missing optional external blobs but is still 
functional: %s\n" %
 (image.name, ' '.join([e.name for e in optional_list])))
 _ShowHelpForMissingBlobs(tout.WARNING, optional_list)
 
@@ -682,7 +683,7 @@ def ProcessImage(image, update_fdt, write_map, 
get_contents=True,
 image.check_missing_bintools(missing_bintool_list)
 if missing_bintool_list:
 tout.warning(
-"Image '%s' has missing bintools and is non-functional: %s" %
+"Image '%s' has missing bintools and is non-functional: %s\n" %
 (image.name, ' '.join([os.path.basename(bintool.name)
for bintool in missing_bintool_list])))
 return any([missing_list, faked_list, missing_bintool_list])
@@ -827,7 +828,7 @@ def Binman(args):
 # This can only be True if -M is provided, since otherwise binman
 # would have raised an error already
 if invalid:
-msg = '\nSome images are invalid'
+msg = 'Some images are invalid'
 if args.ignore_missing:
 tout.warning(msg)
 else:
-- 
2.41.0

[PATCH v2 4/7] binman: Override CheckOptional in fit entry

Missing optional blobs was not reported for generated entries, e.g.
tee-os on rockchip targets. Implement a CheckOptional to fix this.

After this the following can be shown:

  Image 'simple-bin' is missing optional external blobs but is still 
functional: tee-os

  /binman/simple-bin/fit/images/@tee-SEQ/tee-os (tee-os):
 See the documentation for your board. You may need to build Open Portable
 Trusted Execution Environment (OP-TEE) and build with TEE=/path/to/tee.bin

Signed-off-by: Jonas Karlman 
Reviewed-by: Simon Glass 
---
v2:
- Add test
- Collect r-b tag

 tools/binman/etype/fit.py| 7 +++
 tools/binman/ftest.py| 7 +++
 tools/binman/test/264_tee_os_opt_fit.dts | 1 +
 3 files changed, 15 insertions(+)

diff --git a/tools/binman/etype/fit.py b/tools/binman/etype/fit.py
index ef4d0667578d..2c14b15b03cd 100644
--- a/tools/binman/etype/fit.py
+++ b/tools/binman/etype/fit.py
@@ -842,6 +842,13 @@ class Entry_fit(Entry_section):
 for entry in self._priv_entries.values():
 entry.CheckMissing(missing_list)
 
+def CheckOptional(self, optional_list):
+# We must use our private entry list for this since generator nodes
+# which are removed from self._entries will otherwise not show up as
+# optional
+for entry in self._priv_entries.values():
+entry.CheckOptional(optional_list)
+
 def CheckEntries(self):
 pass
 
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 152f800c676c..40ef6e5dce99 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -6298,6 +6298,13 @@ fdt fdtmapExtract the devicetree 
blob from the fdtmap
  fdt_util.fdt32_to_cpu(node.props['entry'].value))
 self.assertEqual(U_BOOT_DATA, node.props['data'].bytes)
 
+with test_util.capture_sys_output() as (stdout, stderr):
+self.checkFitTee('264_tee_os_opt_fit.dts', '')
+err = stderr.getvalue()
+self.assertRegex(
+err,
+"Image '.*' is missing optional external blobs but is still 
functional: tee-os")
+
 def testFitTeeOsOptionalFitBad(self):
 """Test an image with a FIT with an optional OP-TEE binary"""
 with self.assertRaises(ValueError) as exc:
diff --git a/tools/binman/test/264_tee_os_opt_fit.dts 
b/tools/binman/test/264_tee_os_opt_fit.dts
index ae44b433edf1..e9634d3ccdcd 100644
--- a/tools/binman/test/264_tee_os_opt_fit.dts
+++ b/tools/binman/test/264_tee_os_opt_fit.dts
@@ -25,6 +25,7 @@
fit,data;
 
tee-os {
+   optional;
};
};
};
-- 
2.41.0

[PATCH v2 1/7] binman: Update tee-os missing blob help text

Make it a little bit more clear that it is U-Boot that should be built
with TEE=/path/to/tee.bin and not OP-TEE itself.

Signed-off-by: Jonas Karlman 
---
v2:
- New patch

 tools/binman/missing-blob-help | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/binman/missing-blob-help b/tools/binman/missing-blob-help
index f013367ac36b..ab0023eb9fb5 100644
--- a/tools/binman/missing-blob-help
+++ b/tools/binman/missing-blob-help
@@ -43,7 +43,7 @@ for the external TPL binary is 
https://github.com/rockchip-linux/rkbin.
 
 tee-os:
 See the documentation for your board. You may need to build Open Portable
-Trusted Execution Environment (OP-TEE) with TEE=/path/to/tee.bin
+Trusted Execution Environment (OP-TEE) and build with TEE=/path/to/tee.bin
 
 opensbi:
 See the documentation for your board. The OpenSBI git repo is at
-- 
2.41.0

[PATCH v2 2/7] binman: Update missing optional external blob warning text

Make it more clear that the missing external blob is optional in the
printed warning message.

Signed-off-by: Jonas Karlman 
---
v2:
- New patch

 tools/binman/control.py | 2 +-
 tools/binman/ftest.py   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/binman/control.py b/tools/binman/control.py
index 25e66814837d..3560cadba4c2 100644
--- a/tools/binman/control.py
+++ b/tools/binman/control.py
@@ -674,7 +674,7 @@ def ProcessImage(image, update_fdt, write_map, 
get_contents=True,
 image.CheckOptional(optional_list)
 if optional_list:
 tout.warning(
-"Image '%s' is missing external blobs but is still functional: %s" 
%
+"Image '%s' is missing optional external blobs but is still 
functional: %s" %
 (image.name, ' '.join([e.name for e in optional_list])))
 _ShowHelpForMissingBlobs(optional_list)
 
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index e53181afb78a..152f800c676c 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -6330,7 +6330,7 @@ fdt fdtmapExtract the devicetree 
blob from the fdtmap
 err = stderr.getvalue()
 self.assertRegex(
 err,
-"Image '.*' is missing external blobs but is still functional: 
missing")
+"Image '.*' is missing optional external blobs but is still 
functional: missing")
 
 def testSectionInner(self):
 """Test an inner section with a size"""
-- 
2.41.0

[PATCH v2 3/7] binman: Report missing external blobs using error level

Print missing external blobs using error level and missing optional
external blobs using warning level. Also change to only print the header
line in color, red for missing and yellow for optional.

Signed-off-by: Jonas Karlman 
---
v2:
- New patch

 tools/binman/control.py | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/tools/binman/control.py b/tools/binman/control.py
index 3560cadba4c2..e5682bf2d3db 100644
--- a/tools/binman/control.py
+++ b/tools/binman/control.py
@@ -112,12 +112,12 @@ def _ReadMissingBlobHelp():
 _FinishTag(tag, msg, result)
 return result
 
-def _ShowBlobHelp(path, text):
-tout.warning('\n%s:' % path)
+def _ShowBlobHelp(level, path, text):
+tout.do_output(level, '\n%s:' % path)
 for line in text.splitlines():
-tout.warning('   %s' % line)
+tout.do_output(level, '   %s' % line)
 
-def _ShowHelpForMissingBlobs(missing_list):
+def _ShowHelpForMissingBlobs(level, missing_list):
 """Show help for each missing blob to help the user take action
 
 Args:
@@ -134,7 +134,7 @@ def _ShowHelpForMissingBlobs(missing_list):
 # Show the first match help message
 for tag in tags:
 if tag in missing_blob_help:
-_ShowBlobHelp(entry._node.path, missing_blob_help[tag])
+_ShowBlobHelp(level, entry._node.path, missing_blob_help[tag])
 break
 
 def GetEntryModules(include_testing=True):
@@ -658,9 +658,9 @@ def ProcessImage(image, update_fdt, write_map, 
get_contents=True,
 missing_list = []
 image.CheckMissing(missing_list)
 if missing_list:
-tout.warning("Image '%s' is missing external blobs and is 
non-functional: %s" %
- (image.name, ' '.join([e.name for e in missing_list])))
-_ShowHelpForMissingBlobs(missing_list)
+tout.error("Image '%s' is missing external blobs and is 
non-functional: %s" %
+   (image.name, ' '.join([e.name for e in missing_list])))
+_ShowHelpForMissingBlobs(tout.ERROR, missing_list)
 
 faked_list = []
 image.CheckFakedBlobs(faked_list)
@@ -676,7 +676,7 @@ def ProcessImage(image, update_fdt, write_map, 
get_contents=True,
 tout.warning(
 "Image '%s' is missing optional external blobs but is still 
functional: %s" %
 (image.name, ' '.join([e.name for e in optional_list])))
-_ShowHelpForMissingBlobs(optional_list)
+_ShowHelpForMissingBlobs(tout.WARNING, optional_list)
 
 missing_bintool_list = []
 image.check_missing_bintools(missing_bintool_list)
-- 
2.41.0

[PATCH v2 0/7] binman: Show missing blob message when building U-Boot

binman currently support showing a helpful missing blob message, however
only when the badly named --allow-missing flag is used.

This changes so that binman is invoked with the --allow-missing flag
and the helpful message can be shown by default when building U-Boot.

Using the following:

make rockpro64-rk3399_defconfig
make CROSS_COMPILE="aarch64-linux-gnu-"

Before this series a build fails with:

binman: Filename 'atf-bl31' not found in input path (...)

After this series a build fails with:

Image 'simple-bin' is missing external blobs and is non-functional: atf-bl31

/binman/simple-bin/fit/images/@atf-SEQ/atf-bl31 (atf-bl31):
See the documentation for your board. You may need to build ARM Trusted
Firmware and build with BL31=/path/to/bl31.bin

Image 'simple-bin' is missing optional external blobs but is still
functional: tee-os

/binman/simple-bin/fit/images/@tee-SEQ/tee-os (tee-os):
See the documentation for your board. You may need to build Open Portable
Trusted Execution Environment (OP-TEE) and build with TEE=/path/to/tee.bin

Some images are invalid

Builds will continue to fail when there is missing blobs, and the use of
BINMAN_ALLOW_MISSING=1 now only enables the --ignore-missing flag.

Changes in v2:
- Drop merged patches.
- Add patches to improve help text.
- Add tests.
- Collect r-b tags.

In v1 there was discussion regarding the name of binman --ignore-missing
flag, see [1]. The flag is kept as-is in v2 and a rename or change of
default behavior is something that someone can do in a follow up series.

The series is based on top of Simon's "binman: Simple templating feature
and mkimage conversion" v5 series. This series can also be found at [2].

[1]
https://patchwork.ozlabs.org/project/uboot/patch/20230219220158.4160763-10-jo...@kwiboo.se/
[2] https://github.com/Kwiboo/u-boot-rockchip/commits/binman-missing-v2

Jonas Karlman (7):
binman: Update tee-os missing blob help text
binman: Update missing optional external blob warning text
binman: Report missing external blobs using error level
binman: Override CheckOptional in fit entry
binman: Fix blank line usage for invalid images warning text
binman: Show filename in missing blob help message
Makefile: Show binman missing blob message

--
2.41.0

Re: EFI breaks USB dual port detection - our observations




Am 18. Juli 2023 20:37:04 MESZ schrieb Suniel Mahesh 
:
>Hi,
>
>I am testing the USB infrastructure on a Rockchip RK3328 based
>roc-rk3328-cc target.
>
>The USB tree on the device is as follows:
>
>=> usb tree
>USB device tree:
>  1  Hub (480 Mb/s, 0mA)
> u-boot EHCI Host Controller
>
>  1  Hub (12 Mb/s, 0mA)
>  U-Boot Root Hub   (OHCI)
>
>  1  Hub (5 Gb/s, 0mA)
> U-Boot XHCI Host Controller
>
>  1  Hub (480 Mb/s, 0mA)
>  U-Boot Root Hub (DWC2)
>
>For some reason I am unable to detect storage device on DWC2 when two USB
>drives
>are simultaneously connected on EHCI and DWC2. Though it shows 2 storage
>devices
>when i do a "usb start/reset" and it gives usb_mass_storage.lun0 failed
>message as
>shown below.

On which U-Boot version are you?

Cf. 
https://github.com/trini/u-boot/commit/180b7118bed8433f9cfe4b5ad62c6b0d901924f5

Best regards

Heinrich



>
>=> usb start
>starting USB...
>Bus usb@ff5c: USB EHCI 1.00
>Bus usb@ff5d: USB OHCI 1.0
>Bus usb@ff60: generic_phy_get_bulk : no phys property
>Register 2000140 NbrPorts 2
>Starting the controller
>USB XHCI 1.10
>Bus usb@ff58: USB DWC2
>scanning bus usb@ff5c for devices...
>2 USB Device(s) found
>scanning bus usb@ff5d for devices... 1 USB Device(s) found
>scanning bus usb@ff60 for devices... 1 USB Device(s) found
>scanning bus usb@ff58 for devices...
>Adding disk for usb_mass_storage.lun0 failed
>(err=-9223372036854775788/0x8014)
>device 'usb_mass_storage.lun0' failed to unbind
>1 USB Device(s) found
>device 'usb_mass_storage.lun0' failed to unbind
>   scanning usb for storage devices... 2 Storage Device(s) found
>
>=> usb tree
>USB device tree:
>  1  Hub (480 Mb/s, 0mA)
>  |  u-boot EHCI Host Controller
>  |
>  +-2  Mass Storage (480 Mb/s, 224mA)
>   SanDisk Dual Drive 040130e3ee554b7078843f4eb331646
>
>  1  Hub (12 Mb/s, 0mA)
>  U-Boot Root Hub
>
>  1  Hub (5 Gb/s, 0mA)
> U-Boot XHCI Host Controller
>
>  1  Hub (480 Mb/s, 0mA)
>  U-Boot Root Hub
>
>call trace: (detailed log:
>https://gist.github.com/sunielmahesh/10088ea7b536cc9898ef787d9db43721)
>
>efi_install_multiple_protocol_interfaces_int
>device path
>/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x0,0x0)/USB(0x1,0x0)/Ctrl(0x0)
>09576e91-6d3f-11d2-8e39-00a0c969723b, fcf1bae8,
>fcf1bae0efi_locate_device_path: ret = EFI_SUCCESS
>efi_install_multiple_protocol_interfaces_int: ret=0, dp->type:7f
>Path
>/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x0,0x0)/USB(0x1,0x0)/Ctrl(0x0)
>already installed
>install failed 8014
>
>However, an interesting observation is that if i disable CONFIG_EFI_LOADER,
>then I am able to detect the storage devices
>without any usb_mass_storage.lun0 failed message:
>
>=> usb reset
>resetting USB...
>Bus usb@ff5c: USB EHCI 1.00
>Bus usb@ff5d: USB OHCI 1.0
>Bus usb@ff60: generic_phy_get_bulk : no phys property
>Register 2000140 NbrPorts 2
>Starting the controller
>USB XHCI 1.10
>Bus usb@ff58: USB DWC2
>scanning bus usb@ff5c for devices... 2 USB Device(s) found
>scanning bus usb@ff5d for devices... 1 USB Device(s) found
>scanning bus usb@ff60 for devices... 1 USB Device(s) found
>scanning bus usb@ff58 for devices... 2 USB Device(s) found
>   scanning usb for storage devices... 2 Storage Device(s) found
>=> usb tree
>USB device tree:
>  1  Hub (480 Mb/s, 0mA)
>  |  u-boot EHCI Host Controller
>  |
>  +-2  Mass Storage (480 Mb/s, 224mA)
>   SanDisk Dual Drive 040130e3ee554b7078843f4eb331646
>
>  1  Hub (12 Mb/s, 0mA)
>  U-Boot Root Hub
>
>  1  Hub (5 Gb/s, 0mA)
> U-Boot XHCI Host Controller
>
>  1  Hub (480 Mb/s, 0mA)
>  |   U-Boot Root Hub
>  |
>  +-2  Mass Storage (480 Mb/s, 224mA)
>   SanDisk Dual Drive 04019c9b2e1a58f24ee318c3c123aa5
>
>Please share you thoughts.
>
>Thanks and Regards

EFI breaks USB dual port detection - our observations

2023-07-18 Thread Suniel Mahesh

Hi,

I am testing the USB infrastructure on a Rockchip RK3328 based
roc-rk3328-cc target.

The USB tree on the device is as follows:

=> usb tree
USB device tree:
  1  Hub (480 Mb/s, 0mA)
 u-boot EHCI Host Controller

  1  Hub (12 Mb/s, 0mA)
  U-Boot Root Hub   (OHCI)

  1  Hub (5 Gb/s, 0mA)
 U-Boot XHCI Host Controller

  1  Hub (480 Mb/s, 0mA)
  U-Boot Root Hub (DWC2)

For some reason I am unable to detect storage device on DWC2 when two USB
drives
are simultaneously connected on EHCI and DWC2. Though it shows 2 storage
devices
when i do a "usb start/reset" and it gives usb_mass_storage.lun0 failed
message as
shown below.

=> usb start
starting USB...
Bus usb@ff5c: USB EHCI 1.00
Bus usb@ff5d: USB OHCI 1.0
Bus usb@ff60: generic_phy_get_bulk : no phys property
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Bus usb@ff58: USB DWC2
scanning bus usb@ff5c for devices...
2 USB Device(s) found
scanning bus usb@ff5d for devices... 1 USB Device(s) found
scanning bus usb@ff60 for devices... 1 USB Device(s) found
scanning bus usb@ff58 for devices...
Adding disk for usb_mass_storage.lun0 failed
(err=-9223372036854775788/0x8014)
device 'usb_mass_storage.lun0' failed to unbind
1 USB Device(s) found
device 'usb_mass_storage.lun0' failed to unbind
   scanning usb for storage devices... 2 Storage Device(s) found

=> usb tree
USB device tree:
  1  Hub (480 Mb/s, 0mA)
  |  u-boot EHCI Host Controller
  |
  +-2  Mass Storage (480 Mb/s, 224mA)
   SanDisk Dual Drive 040130e3ee554b7078843f4eb331646

  1  Hub (12 Mb/s, 0mA)
  U-Boot Root Hub

  1  Hub (5 Gb/s, 0mA)
 U-Boot XHCI Host Controller

  1  Hub (480 Mb/s, 0mA)
  U-Boot Root Hub

call trace: (detailed log:
https://gist.github.com/sunielmahesh/10088ea7b536cc9898ef787d9db43721)

efi_install_multiple_protocol_interfaces_int
device path
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x0,0x0)/USB(0x1,0x0)/Ctrl(0x0)
09576e91-6d3f-11d2-8e39-00a0c969723b, fcf1bae8,
fcf1bae0efi_locate_device_path: ret = EFI_SUCCESS
efi_install_multiple_protocol_interfaces_int: ret=0, dp->type:7f
Path
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x0,0x0)/USB(0x1,0x0)/Ctrl(0x0)
already installed
install failed 8014

However, an interesting observation is that if i disable CONFIG_EFI_LOADER,
then I am able to detect the storage devices
without any usb_mass_storage.lun0 failed message:

=> usb reset
resetting USB...
Bus usb@ff5c: USB EHCI 1.00
Bus usb@ff5d: USB OHCI 1.0
Bus usb@ff60: generic_phy_get_bulk : no phys property
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Bus usb@ff58: USB DWC2
scanning bus usb@ff5c for devices... 2 USB Device(s) found
scanning bus usb@ff5d for devices... 1 USB Device(s) found
scanning bus usb@ff60 for devices... 1 USB Device(s) found
scanning bus usb@ff58 for devices... 2 USB Device(s) found
   scanning usb for storage devices... 2 Storage Device(s) found
=> usb tree
USB device tree:
  1  Hub (480 Mb/s, 0mA)
  |  u-boot EHCI Host Controller
  |
  +-2  Mass Storage (480 Mb/s, 224mA)
   SanDisk Dual Drive 040130e3ee554b7078843f4eb331646

  1  Hub (12 Mb/s, 0mA)
  U-Boot Root Hub

  1  Hub (5 Gb/s, 0mA)
 U-Boot XHCI Host Controller

  1  Hub (480 Mb/s, 0mA)
  |   U-Boot Root Hub
  |
  +-2  Mass Storage (480 Mb/s, 224mA)
   SanDisk Dual Drive 04019c9b2e1a58f24ee318c3c123aa5

Please share you thoughts.

Thanks and Regards
-- 
Suniel Mahesh
Embedded Linux and Kernel Engineer
Amarula Solutions India

Re: [PATCH 2/5] MAINTAINERS: Add some missing defconfig files to existing entries

2023-07-18 Thread Adam Ford

On Tue, Jul 18, 2023 at 11:20 AM Tom Rini  wrote:
>
> We have a few places where defconfigs were added (or renamed) and not
> included in their previously listed MAINTAINERS entry, correct this.
>

For the beacon boards:

Acked-by:  Adam Ford 

> Signed-off-by: Tom Rini 
> ---
> Cc: Adam Ford 
> Cc: Chris Packham 
> Cc: Jan Kiszka 
> Cc: Neil Armstrong 
> Cc: Stefan Roese 
> ---
>  board/Marvell/db-88f6820-amc/MAINTAINERS | 1 +
>  board/amlogic/w400/MAINTAINERS   | 1 +
>  board/beacon/imx8mm/MAINTAINERS  | 1 +
>  board/beacon/imx8mn/MAINTAINERS  | 1 +
>  board/siemens/iot2050/MAINTAINERS| 3 ++-
>  board/solidrun/clearfog/MAINTAINERS  | 2 ++
>  6 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/board/Marvell/db-88f6820-amc/MAINTAINERS 
> b/board/Marvell/db-88f6820-amc/MAINTAINERS
> index abf5b7efdc93..d519eb47b84c 100644
> --- a/board/Marvell/db-88f6820-amc/MAINTAINERS
> +++ b/board/Marvell/db-88f6820-amc/MAINTAINERS
> @@ -4,3 +4,4 @@ S:  Maintained
>  F: board/Marvell/db-88f6820-amc/
>  F: include/configs/db-88f6820-amc.h
>  F: configs/db-88f6820-amc_defconfig
> +F: configs/db-88f6820-amc_nand_defconfig
> diff --git a/board/amlogic/w400/MAINTAINERS b/board/amlogic/w400/MAINTAINERS
> index 117f79ea047b..19b1f30e6213 100644
> --- a/board/amlogic/w400/MAINTAINERS
> +++ b/board/amlogic/w400/MAINTAINERS
> @@ -5,6 +5,7 @@ L:  u-boot-amlo...@groups.io
>  F: board/amlogic/w400/
>  F: configs/bananapi-cm4-cm4io_defconfig
>  F: configs/bananapi-m2s_defconfig
> +F: configs/odroid-n2l_defconfig
>  F: configs/radxa-zero2_defconfig
>  F: doc/board/amlogic/w400.rst
>  F: doc/board/amlogic/bananapi-cm4io.rst
> diff --git a/board/beacon/imx8mm/MAINTAINERS b/board/beacon/imx8mm/MAINTAINERS
> index d48ba8605bba..d8a5d0973694 100644
> --- a/board/beacon/imx8mm/MAINTAINERS
> +++ b/board/beacon/imx8mm/MAINTAINERS
> @@ -5,4 +5,5 @@ S:  Maintained
>  F: board/beacon/imx8mm/
>  F: include/configs/imx8mm_beacon.h
>  F: configs/imx8mm_beacon_defconfig
> +F: configs/imx8mm_beacon_fspi_defconfig
>  F: doc/board/beacon/
> diff --git a/board/beacon/imx8mn/MAINTAINERS b/board/beacon/imx8mn/MAINTAINERS
> index 4805cb255cc0..6dcef21a65e9 100644
> --- a/board/beacon/imx8mn/MAINTAINERS
> +++ b/board/beacon/imx8mn/MAINTAINERS
> @@ -5,3 +5,4 @@ F:  board/beacon/imx8mn/
>  F: include/configs/imx8mn_beacon.h
>  F: configs/imx8mn_beacon_defconfig
>  F: configs/imx8mn_beacon_2g_defconfig
> +F: configs/imx8mn_beacon_fspi_defconfig
> diff --git a/board/siemens/iot2050/MAINTAINERS 
> b/board/siemens/iot2050/MAINTAINERS
> index 1b525356c2d6..aa21de2099f7 100644
> --- a/board/siemens/iot2050/MAINTAINERS
> +++ b/board/siemens/iot2050/MAINTAINERS
> @@ -4,6 +4,7 @@ M:  Jan Kiszka 
>  S: Maintained
>  F: board/siemens/iot2050/
>  F: include/configs/iot2050.h
> -F: configs/iot2050_defconfig
> +F: configs/iot2050_pg1_defconfig
> +F: configs/iot2050_pg2_defconfig
>  F: arch/arm/dts/iot2050-*
>  F: doc/board/siemens/iot2050.rst
> diff --git a/board/solidrun/clearfog/MAINTAINERS 
> b/board/solidrun/clearfog/MAINTAINERS
> index 6646d96206bf..55bd1278049a 100644
> --- a/board/solidrun/clearfog/MAINTAINERS
> +++ b/board/solidrun/clearfog/MAINTAINERS
> @@ -5,3 +5,5 @@ F:  board/soldrun/clearfog/
>  F: include/configs/clearfog.h
>  F: configs/clearfog_defconfig
>  F: configs/clearfog_gt_8k_defconfig
> +F: configs/clearfog_sata_defconfig
> +F: configs/clearfog_spi_defconfig
> --
> 2.34.1
>

Re: [PATCH 2/5] MAINTAINERS: Add some missing defconfig files to existing entries

2023-07-18 Thread Jan Kiszka

On 18.07.23 18:20, Tom Rini wrote:
> We have a few places where defconfigs were added (or renamed) and not
> included in their previously listed MAINTAINERS entry, correct this.
> 
> Signed-off-by: Tom Rini 
> ---
> Cc: Adam Ford 
> Cc: Chris Packham 
> Cc: Jan Kiszka 
> Cc: Neil Armstrong 
> Cc: Stefan Roese 
> ---
>  board/Marvell/db-88f6820-amc/MAINTAINERS | 1 +
>  board/amlogic/w400/MAINTAINERS   | 1 +
>  board/beacon/imx8mm/MAINTAINERS  | 1 +
>  board/beacon/imx8mn/MAINTAINERS  | 1 +
>  board/siemens/iot2050/MAINTAINERS| 3 ++-
>  board/solidrun/clearfog/MAINTAINERS  | 2 ++
>  6 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/board/Marvell/db-88f6820-amc/MAINTAINERS 
> b/board/Marvell/db-88f6820-amc/MAINTAINERS
> index abf5b7efdc93..d519eb47b84c 100644
> --- a/board/Marvell/db-88f6820-amc/MAINTAINERS
> +++ b/board/Marvell/db-88f6820-amc/MAINTAINERS
> @@ -4,3 +4,4 @@ S:Maintained
>  F:   board/Marvell/db-88f6820-amc/
>  F:   include/configs/db-88f6820-amc.h
>  F:   configs/db-88f6820-amc_defconfig
> +F:   configs/db-88f6820-amc_nand_defconfig
> diff --git a/board/amlogic/w400/MAINTAINERS b/board/amlogic/w400/MAINTAINERS
> index 117f79ea047b..19b1f30e6213 100644
> --- a/board/amlogic/w400/MAINTAINERS
> +++ b/board/amlogic/w400/MAINTAINERS
> @@ -5,6 +5,7 @@ L:u-boot-amlo...@groups.io
>  F:   board/amlogic/w400/
>  F:   configs/bananapi-cm4-cm4io_defconfig
>  F:   configs/bananapi-m2s_defconfig
> +F:   configs/odroid-n2l_defconfig
>  F:   configs/radxa-zero2_defconfig
>  F:   doc/board/amlogic/w400.rst
>  F:   doc/board/amlogic/bananapi-cm4io.rst
> diff --git a/board/beacon/imx8mm/MAINTAINERS b/board/beacon/imx8mm/MAINTAINERS
> index d48ba8605bba..d8a5d0973694 100644
> --- a/board/beacon/imx8mm/MAINTAINERS
> +++ b/board/beacon/imx8mm/MAINTAINERS
> @@ -5,4 +5,5 @@ S:Maintained
>  F:   board/beacon/imx8mm/
>  F:   include/configs/imx8mm_beacon.h
>  F:   configs/imx8mm_beacon_defconfig
> +F:   configs/imx8mm_beacon_fspi_defconfig
>  F:   doc/board/beacon/
> diff --git a/board/beacon/imx8mn/MAINTAINERS b/board/beacon/imx8mn/MAINTAINERS
> index 4805cb255cc0..6dcef21a65e9 100644
> --- a/board/beacon/imx8mn/MAINTAINERS
> +++ b/board/beacon/imx8mn/MAINTAINERS
> @@ -5,3 +5,4 @@ F:board/beacon/imx8mn/
>  F:   include/configs/imx8mn_beacon.h
>  F:   configs/imx8mn_beacon_defconfig
>  F:   configs/imx8mn_beacon_2g_defconfig
> +F:   configs/imx8mn_beacon_fspi_defconfig
> diff --git a/board/siemens/iot2050/MAINTAINERS 
> b/board/siemens/iot2050/MAINTAINERS
> index 1b525356c2d6..aa21de2099f7 100644
> --- a/board/siemens/iot2050/MAINTAINERS
> +++ b/board/siemens/iot2050/MAINTAINERS
> @@ -4,6 +4,7 @@ M:Jan Kiszka 
>  S:   Maintained
>  F:   board/siemens/iot2050/
>  F:   include/configs/iot2050.h
> -F:   configs/iot2050_defconfig
> +F:   configs/iot2050_pg1_defconfig
> +F:   configs/iot2050_pg2_defconfig

Hehe, I'm sitting on patches to revert that again, but I don't object to
fix this first to the current reality.

Jan

>  F:   arch/arm/dts/iot2050-*
>  F:   doc/board/siemens/iot2050.rst
> diff --git a/board/solidrun/clearfog/MAINTAINERS 
> b/board/solidrun/clearfog/MAINTAINERS
> index 6646d96206bf..55bd1278049a 100644
> --- a/board/solidrun/clearfog/MAINTAINERS
> +++ b/board/solidrun/clearfog/MAINTAINERS
> @@ -5,3 +5,5 @@ F:board/soldrun/clearfog/
>  F:   include/configs/clearfog.h
>  F:   configs/clearfog_defconfig
>  F:   configs/clearfog_gt_8k_defconfig
> +F:   configs/clearfog_sata_defconfig
> +F:   configs/clearfog_spi_defconfig

-- 
Siemens AG, Technology
Competence Center Embedded Linux

[PATCH 5/5] MAINTAINERS: Re-order CAAM section

This file is in alphabetical order, move CAAM up to where it should be.

Signed-off-by: Tom Rini 
---
 MAINTAINERS | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 87991cccddb6..697190558efe 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -840,6 +840,13 @@ M: Simon Glass 
 S: Maintained
 F: tools/buildman/
 
+CAAM
+M: Gaurav Jain 
+S: Maintained
+F: arch/arm/dts/ls1021a-twr-u-boot.dtsi
+F: drivers/crypto/fsl/
+F: include/fsl_sec.h
+
 CAT
 M: Roger Knecht 
 S: Maintained
@@ -1627,10 +1634,3 @@ T:   git https://source.denx.de/u-boot/u-boot.git
 F: configs/tools-only_defconfig
 F: *
 F: */
-
-CAAM
-M: Gaurav Jain 
-S: Maintained
-F: arch/arm/dts/ls1021a-twr-u-boot.dtsi
-F: drivers/crypto/fsl/
-F: include/fsl_sec.h
-- 
2.34.1

[PATCH 4/5] sunxi: Add MAINTAINERS entry for Lctech Pi F1C200s

This defconfig was added without a MAINTAINERS entry, add one.

Signed-off-by: Tom Rini 
---
 board/sunxi/MAINTAINERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 80e3f4be4b96..98bbd2dd25dd 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -211,6 +211,11 @@ M: Aleksandr Aleksandrov 
 S: Maintained
 F: configs/emlid_neutis_n5_devboard_defconfig
 
+LCTECH PI F1C200S
+M: Andre Przywara 
+S: Maintained
+F: configs/lctech_pi_f1c200s_defconfig
+
 GEMEI-G9 TABLET
 M: Priit Laes 
 S: Maintained
-- 
2.34.1

[PATCH 3/5] rockchip: Add MAINTAINERS entry for Radxa Rock 4C+

This defconfig was added without a MAINTAINERS entry, add one.

Signed-off-by: Tom Rini 
---
 board/rockchip/evb_rk3399/MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/board/rockchip/evb_rk3399/MAINTAINERS 
b/board/rockchip/evb_rk3399/MAINTAINERS
index 5be58f80f9ba..de1dc64a962d 100644
--- a/board/rockchip/evb_rk3399/MAINTAINERS
+++ b/board/rockchip/evb_rk3399/MAINTAINERS
@@ -80,6 +80,12 @@ F:   configs/orangepi-rk3399_defconfig
 F: arch/arm/dts/rk3399-u-boot.dtsi
 F: arch/arm/dts/rk3399-orangepi-u-boot.dtsi
 
+RADXA ROCK 4C+
+M: FUKAUMI Naoki 
+S: Maintained
+F: configs/rock-4c-plus-rk3399_defconfig
+F: arch/arm/dts/rk3399-rock-4c-plus.dts
+
 ROCK-PI-4
 M: Akash Gajjar 
 M: Jagan Teki 
-- 
2.34.1

[PATCH 2/5] MAINTAINERS: Add some missing defconfig files to existing entries

We have a few places where defconfigs were added (or renamed) and not
included in their previously listed MAINTAINERS entry, correct this.

Signed-off-by: Tom Rini 
---
Cc: Adam Ford 
Cc: Chris Packham 
Cc: Jan Kiszka 
Cc: Neil Armstrong 
Cc: Stefan Roese 
---
 board/Marvell/db-88f6820-amc/MAINTAINERS | 1 +
 board/amlogic/w400/MAINTAINERS   | 1 +
 board/beacon/imx8mm/MAINTAINERS  | 1 +
 board/beacon/imx8mn/MAINTAINERS  | 1 +
 board/siemens/iot2050/MAINTAINERS| 3 ++-
 board/solidrun/clearfog/MAINTAINERS  | 2 ++
 6 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/board/Marvell/db-88f6820-amc/MAINTAINERS 
b/board/Marvell/db-88f6820-amc/MAINTAINERS
index abf5b7efdc93..d519eb47b84c 100644
--- a/board/Marvell/db-88f6820-amc/MAINTAINERS
+++ b/board/Marvell/db-88f6820-amc/MAINTAINERS
@@ -4,3 +4,4 @@ S:  Maintained
 F: board/Marvell/db-88f6820-amc/
 F: include/configs/db-88f6820-amc.h
 F: configs/db-88f6820-amc_defconfig
+F: configs/db-88f6820-amc_nand_defconfig
diff --git a/board/amlogic/w400/MAINTAINERS b/board/amlogic/w400/MAINTAINERS
index 117f79ea047b..19b1f30e6213 100644
--- a/board/amlogic/w400/MAINTAINERS
+++ b/board/amlogic/w400/MAINTAINERS
@@ -5,6 +5,7 @@ L:  u-boot-amlo...@groups.io
 F: board/amlogic/w400/
 F: configs/bananapi-cm4-cm4io_defconfig
 F: configs/bananapi-m2s_defconfig
+F: configs/odroid-n2l_defconfig
 F: configs/radxa-zero2_defconfig
 F: doc/board/amlogic/w400.rst
 F: doc/board/amlogic/bananapi-cm4io.rst
diff --git a/board/beacon/imx8mm/MAINTAINERS b/board/beacon/imx8mm/MAINTAINERS
index d48ba8605bba..d8a5d0973694 100644
--- a/board/beacon/imx8mm/MAINTAINERS
+++ b/board/beacon/imx8mm/MAINTAINERS
@@ -5,4 +5,5 @@ S:  Maintained
 F: board/beacon/imx8mm/
 F: include/configs/imx8mm_beacon.h
 F: configs/imx8mm_beacon_defconfig
+F: configs/imx8mm_beacon_fspi_defconfig
 F: doc/board/beacon/
diff --git a/board/beacon/imx8mn/MAINTAINERS b/board/beacon/imx8mn/MAINTAINERS
index 4805cb255cc0..6dcef21a65e9 100644
--- a/board/beacon/imx8mn/MAINTAINERS
+++ b/board/beacon/imx8mn/MAINTAINERS
@@ -5,3 +5,4 @@ F:  board/beacon/imx8mn/
 F: include/configs/imx8mn_beacon.h
 F: configs/imx8mn_beacon_defconfig
 F: configs/imx8mn_beacon_2g_defconfig
+F: configs/imx8mn_beacon_fspi_defconfig
diff --git a/board/siemens/iot2050/MAINTAINERS 
b/board/siemens/iot2050/MAINTAINERS
index 1b525356c2d6..aa21de2099f7 100644
--- a/board/siemens/iot2050/MAINTAINERS
+++ b/board/siemens/iot2050/MAINTAINERS
@@ -4,6 +4,7 @@ M:  Jan Kiszka 
 S: Maintained
 F: board/siemens/iot2050/
 F: include/configs/iot2050.h
-F: configs/iot2050_defconfig
+F: configs/iot2050_pg1_defconfig
+F: configs/iot2050_pg2_defconfig
 F: arch/arm/dts/iot2050-*
 F: doc/board/siemens/iot2050.rst
diff --git a/board/solidrun/clearfog/MAINTAINERS 
b/board/solidrun/clearfog/MAINTAINERS
index 6646d96206bf..55bd1278049a 100644
--- a/board/solidrun/clearfog/MAINTAINERS
+++ b/board/solidrun/clearfog/MAINTAINERS
@@ -5,3 +5,5 @@ F:  board/soldrun/clearfog/
 F: include/configs/clearfog.h
 F: configs/clearfog_defconfig
 F: configs/clearfog_gt_8k_defconfig
+F: configs/clearfog_sata_defconfig
+F: configs/clearfog_spi_defconfig
-- 
2.34.1

[PATCH 1/5] MAINTAINERS: Correct minor mistakes on some file listings

There are a few entries where minor mistakes mean that we don't match up
with obviously expected files, correct those.

Signed-off-by: Tom Rini 
---
 board/amlogic/u200/MAINTAINERS| 2 +-
 board/broadcom/bcmns/MAINTAINERS  | 2 +-
 board/freescale/imx93_evk/MAINTAINERS | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/board/amlogic/u200/MAINTAINERS b/board/amlogic/u200/MAINTAINERS
index f429c212ba3d..88c5038d9445 100644
--- a/board/amlogic/u200/MAINTAINERS
+++ b/board/amlogic/u200/MAINTAINERS
@@ -4,7 +4,7 @@ S:  Maintained
 L: u-boot-amlo...@groups.io
 F: board/amlogic/u200/
 F: configs/u200_defconfig
-F: configs/bananapi-m2pro_defconfig
+F: configs/bananapi-m2-pro_defconfig
 F: configs/bananapi-m5_defconfig
 F: configs/radxa-zero_defconfig
 F: doc/board/amlogic/u200.rst
diff --git a/board/broadcom/bcmns/MAINTAINERS b/board/broadcom/bcmns/MAINTAINERS
index fd37c334a5b1..86b68c989cd4 100644
--- a/board/broadcom/bcmns/MAINTAINERS
+++ b/board/broadcom/bcmns/MAINTAINERS
@@ -2,5 +2,5 @@ BCMNS BOARD
 M: Linus Walleij 
 S: Maintained
 F: board/broadcom/bcmnsp/
-F: configs/bcmnsp_defconfig
+F: configs/bcmns_defconfig
 F: include/configs/bcmnsp.h
diff --git a/board/freescale/imx93_evk/MAINTAINERS 
b/board/freescale/imx93_evk/MAINTAINERS
index 8ca4646f20fe..34ba278fcdfd 100644
--- a/board/freescale/imx93_evk/MAINTAINERS
+++ b/board/freescale/imx93_evk/MAINTAINERS
@@ -4,4 +4,4 @@ S:  Maintained
 F: board/freescale/imx93_evk/
 F: include/configs/imx93_evk.h
 F: configs/imx93_11x11_evk_defconfig
-   configs/imx93_11x11_evk_ld_defconfig
+F: configs/imx93_11x11_evk_ld_defconfig
-- 
2.34.1

[PATCH] ARM: imx: Update MAINTAINERS file on DH electronics i.MX8M Plus DHCOM

2023-07-18 Thread Marek Vasut

Make use of globs to cover all the DTs and defconfigs.
Fill in missing DH u-boot list name.

Signed-off-by: Marek Vasut 
---
Cc: Andreas Geisreiter 
Cc: Christoph Niedermaier 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Stefano Babic 
Cc: u-b...@dh-electronics.com
Cc: u-boot@lists.denx.de
---
 board/dhelectronics/dh_imx8mp/MAINTAINERS | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/board/dhelectronics/dh_imx8mp/MAINTAINERS 
b/board/dhelectronics/dh_imx8mp/MAINTAINERS
index 7c70cfdd949..db69781a852 100644
--- a/board/dhelectronics/dh_imx8mp/MAINTAINERS
+++ b/board/dhelectronics/dh_imx8mp/MAINTAINERS
@@ -1,8 +1,8 @@
-DH electronics DHCOM Premium Developer Kit (2) i.MX8M Plus
+DH electronics DHCOM i.MX8M Plus and matching carrier boards
 M: Marek Vasut 
+L: u-b...@dh-electronics.com
 S: Maintained
-F: arch/arm/dts/imx8mp-dhcom-pdk2.dts
-F: arch/arm/dts/imx8mp-dhcom-pdk2-u-boot.dtsi
-F: board/dhelectronics/imx8mp_dhcom_pdk2/
-F: configs/imx8mp_dhcom_pdk2_defconfig
-F: include/configs/imx8mp_dhcom_pdk2.h
+F: arch/arm/dts/imx8mp-dhcom*
+F: board/dhelectronics/dh_imx8mp/
+F: configs/imx8mp_dhcom*defconfig
+F: include/configs/imx8mp_dhcom*
-- 
2.40.1

Re: [PATCH v10 3/4] Boot var automatic management for removable medias

2023-07-18 Thread Raymond Mao

Hi Masahisa,

Thanks for the hints. Found that I was missing 'guestfs-tools' for
'virt-make-fs'.
Now I am able to reproduce the failure logs that Heinrich pointed out.

Thanks!
Regards,
Raymond

On Tue, 18 Jul 2023 at 05:03, Masahisa Kojima 
wrote:

> Hi Raymond,
>
> On Tue, 18 Jul 2023 at 05:23, Raymond Mao  wrote:
> >
> > Hi Heinrich,
> >
> > I run 'make tests' with the patches locally but no errors observed from
> 'test_signed.py', below are few lines from the output console:
> > ```
> > test/py/tests/test_efi_secboot/test_signed.py 
>
> [  90%]
> > ```
>
> I think the test cases are just skipped, not executed.
>
> I guess that some required packages are missing on the host machine,
> such as sbsigntool, efitools and libguestfs-tools.
> build-sandbox/test-log.html will help to analyze why the tests are skipped.
>
> The following document describes prerequisites to run python tests.
> https://u-boot.readthedocs.io/en/latest/develop/py_testing.html
>
> 'make tests' runs many test cases and takes time.
> './test/py/test.py --bd sandbox --build -k efi_secboot' will run only
> the efi_secboot test
> and it will be useful for debugging purposes.
>
> Thanks,
> Masahisa Kojima
>
>
> >
> > Regards,
> > Raymond
> >
> > On Sat, 15 Jul 2023 at 05:19, Heinrich Schuchardt 
> wrote:
> >>
> >> On 7/9/23 10:56, Heinrich Schuchardt wrote:
> >> > On 6/19/23 23:23, Raymond Mao wrote:
> >> >> Changes for complying to EFI spec §3.5.1.1
> >> >> 'Removable Media Boot Behavior'.
> >> >> Boot variables can be automatically generated during a removable
> >> >> media is probed. At the same time, unused boot variables will be
> >> >> detected and removed.
> >> >>
> >> >> Please note that currently the function 'efi_disk_remove' has no
> >> >> ability to distinguish below two scenarios
> >> >> a) Unplugging of a removable media under U-Boot
> >> >> b) U-Boot exiting and booting an OS
> >> >> Thus currently the boot variables management is not added into
> >> >> 'efi_disk_remove' to avoid boot options being added/erased
> >> >> repeatedly under scenario b) during power cycles
> >> >> See TODO comments under function 'efi_disk_remove' for more details
> >> >>
> >> >> Signed-off-by: Raymond Mao 
> >> >> ---
> >> >> Changes in v3
> >> >> - Split the patch into moving and renaming functions and
> >> >>individual patches for each changed functionality
> >> >> Changes in v5
> >> >> - Move function call of efi_bootmgr_update_media_device_boot_option()
> >> >>from efi_init_variables() to efi_init_obj_list()
> >> >> Changes in v6
> >> >> - Revert unrelated changes
> >> >> Changes in v7
> >> >> - adapt the return code of function
> >> >>efi_bootmgr_update_media_device_boot_option()
> >> >> Changes in v8
> >> >> - add a note in the commit message for future reference
> >> >> Changes in v9
> >> >> - amend the note text in the commit message
> >> >> - add a TODO comment in 'efi_disk_remove'
> >> >> Changes in v10
> >> >> - fix typo and build failures with 'CONFIG_CMD_BOOTEFI_BOOTMGR=n'
> >> >>
> >> >>   lib/efi_loader/efi_disk.c  | 18 ++
> >> >>   lib/efi_loader/efi_setup.c |  7 +++
> >> >>   2 files changed, 25 insertions(+)
> >> >>
> >> >> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> >> >> index d2256713a8..911a4adfb1 100644
> >> >> --- a/lib/efi_loader/efi_disk.c
> >> >> +++ b/lib/efi_loader/efi_disk.c
> >> >> @@ -687,6 +687,13 @@ int efi_disk_probe(void *ctx, struct event
> *event)
> >> >>   return -1;
> >> >>   }
> >> >> +/* only do the boot option management when UEFI sub-system is
> >> >> initialized */
> >> >> +if (IS_ENABLED(CONFIG_CMD_BOOTEFI_BOOTMGR) &&
> >> >> efi_obj_list_initialized == EFI_SUCCESS) {
> >> >> +ret = efi_bootmgr_update_media_device_boot_option();
> >> >> +if (ret != EFI_SUCCESS)
> >> >> +return -1;
> >> >> +}
> >> >> +
> >> >>   return 0;
> >> >>   }
> >> >> @@ -773,6 +780,17 @@ int efi_disk_remove(void *ctx, struct event
> *event)
> >> >>   return efi_disk_delete_part(dev);
> >> >>   else
> >> >>   return 0;
> >> >> +
> >> >> +/*
> >> >> + * TODO A flag to distinguish below 2 different scenarios of
> this
> >> >> + * function call is needed:
> >> >> + * a) Unplugging of a removable media under U-Boot
> >> >> + * b) U-Boot exiting and booting an OS
> >> >> + * In case of scenario a),
> >> >> efi_bootmgr_update_media_device_boot_option()
> >> >> + * needs to be invoked here to update the boot options and
> remove
> >> >> the
> >> >> + * unnecessary ones.
> >> >> + */
> >> >
> >> > As in future we want to integrate more EFI drivers with the driver
> model
> >> > such a status should be in a global variable. It will have to be set
> in
> >> > ExitBootServices() before invoking dm_remove_devices_flags().
> >> >
> >> > Reviewed-by: Heinrich Schuchardt 
> >> >
> >> >> +
> >> >>   }
> >> >>   /**

Re: [PATCH] efi_loader: Allow also empty capsule to be process


On 13.07.23 16:35, Michal Simek wrote:

Empty capsule are also allowed to be process. Without it updated images
can't change their Image Acceptance state from no to yes.


Is there any documentation describing the usage of empty capsule to set
the image acceptance state?

Best regards

Heinrich



Signed-off-by: Michal Simek 
---

  lib/efi_loader/efi_capsule.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 7a6f195cbc02..93e83e5f04c3 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -752,7 +752,8 @@ efi_status_t EFIAPI efi_update_capsule(
log_debug("Capsule[%d] (guid:%pUs)\n",
  i, &capsule->capsule_guid);
if (!guidcmp(&capsule->capsule_guid,
-&efi_guid_firmware_management_capsule_id)) {
+&efi_guid_firmware_management_capsule_id) ||
+   fwu_empty_capsule(capsule)) {
ret  = efi_capsule_update_firmware(capsule);
} else {
log_err("Unsupported capsule type: %pUs\n",

Re: [PATCH v10 3/4] Boot var automatic management for removable medias


On 18.07.23 11:03, Masahisa Kojima wrote:

Hi Raymond,

On Tue, 18 Jul 2023 at 05:23, Raymond Mao  wrote:


Hi Heinrich,

I run 'make tests' with the patches locally but no errors observed from 
'test_signed.py', below are few lines from the output console:
```
test/py/tests/test_efi_secboot/test_signed.py   

[  90%]
```


I think the test cases are just skipped, not executed.

I guess that some required packages are missing on the host machine,
such as sbsigntool, efitools and libguestfs-tools.
build-sandbox/test-log.html will help to analyze why the tests are skipped.

The following document describes prerequisites to run python tests.
https://u-boot.readthedocs.io/en/latest/develop/py_testing.html

'make tests' runs many test cases and takes time.
'./test/py/test.py --bd sandbox --build -k efi_secboot' will run only
the efi_secboot test
and it will be useful for debugging purposes.

Thanks,
Masahisa Kojima


To get more output describing why tests are skipped or fail use

   export PYTEST_ADDOPTS="-ra"

https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/16948
shows the errors with the suggested patch.

Best regards

Heinrich






Regards,
Raymond

On Sat, 15 Jul 2023 at 05:19, Heinrich Schuchardt  wrote:


On 7/9/23 10:56, Heinrich Schuchardt wrote:

On 6/19/23 23:23, Raymond Mao wrote:

Changes for complying to EFI spec §3.5.1.1
'Removable Media Boot Behavior'.
Boot variables can be automatically generated during a removable
media is probed. At the same time, unused boot variables will be
detected and removed.

Please note that currently the function 'efi_disk_remove' has no
ability to distinguish below two scenarios
a) Unplugging of a removable media under U-Boot
b) U-Boot exiting and booting an OS
Thus currently the boot variables management is not added into
'efi_disk_remove' to avoid boot options being added/erased
repeatedly under scenario b) during power cycles
See TODO comments under function 'efi_disk_remove' for more details

Signed-off-by: Raymond Mao 
---
Changes in v3
- Split the patch into moving and renaming functions and
individual patches for each changed functionality
Changes in v5
- Move function call of efi_bootmgr_update_media_device_boot_option()
from efi_init_variables() to efi_init_obj_list()
Changes in v6
- Revert unrelated changes
Changes in v7
- adapt the return code of function
efi_bootmgr_update_media_device_boot_option()
Changes in v8
- add a note in the commit message for future reference
Changes in v9
- amend the note text in the commit message
- add a TODO comment in 'efi_disk_remove'
Changes in v10
- fix typo and build failures with 'CONFIG_CMD_BOOTEFI_BOOTMGR=n'

   lib/efi_loader/efi_disk.c  | 18 ++
   lib/efi_loader/efi_setup.c |  7 +++
   2 files changed, 25 insertions(+)

diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index d2256713a8..911a4adfb1 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -687,6 +687,13 @@ int efi_disk_probe(void *ctx, struct event *event)
   return -1;
   }
+/* only do the boot option management when UEFI sub-system is
initialized */
+if (IS_ENABLED(CONFIG_CMD_BOOTEFI_BOOTMGR) &&
efi_obj_list_initialized == EFI_SUCCESS) {
+ret = efi_bootmgr_update_media_device_boot_option();
+if (ret != EFI_SUCCESS)
+return -1;
+}
+
   return 0;
   }
@@ -773,6 +780,17 @@ int efi_disk_remove(void *ctx, struct event *event)
   return efi_disk_delete_part(dev);
   else
   return 0;
+
+/*
+ * TODO A flag to distinguish below 2 different scenarios of this
+ * function call is needed:
+ * a) Unplugging of a removable media under U-Boot
+ * b) U-Boot exiting and booting an OS
+ * In case of scenario a),
efi_bootmgr_update_media_device_boot_option()
+ * needs to be invoked here to update the boot options and remove
the
+ * unnecessary ones.
+ */


As in future we want to integrate more EFI drivers with the driver model
such a status should be in a global variable. It will have to be set in
ExitBootServices() before invoking dm_remove_devices_flags().

Reviewed-by: Heinrich Schuchardt 


+
   }
   /**
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index 58d4e13402..69c8b27730 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -245,6 +245,13 @@ efi_status_t efi_init_obj_list(void)
   if (ret != EFI_SUCCESS)
   goto out;
+if (IS_ENABLED(CONFIG_CMD_BOOTEFI_BOOTMGR)) {
+/* update boot option after variable service initialized */
+ret = efi_bootmgr_update_media_device_boot_option();
+if (ret != EFI_SUCCESS)
+goto out;
+}
+
   /* Define supported languages */
   ret = efi_init_platform_lang();
   if (ret !

Re: [PATCH] sunxi: H6: Enable Ethernet on Orange Pi One Plus

2023-07-18 Thread Anne Macedo

On Sun, Jul 16, 2023 at 08:14:50AM +0200, Corentin Labbe wrote:
> Le Sun, Jul 16, 2023 at 01:35:02AM +0100, Andre Przywara a écrit :
> > On Tue, 11 Jul 2023 19:40:21 +
> > Anne Macedo  wrote:
> > 
> > Hi Anne,
> > 
> > thanks for reaching out to the list! But please try to avoid
> > pushing any patches downstream (Yocto) before they are accepted
> > or at least discussed upstream, see below.
> > 
> > > On 11.07.2023 02:39, Anne Macedo wrote:
> > > > Enable Ethernet on Orange Pi One Plus by using the correct phy for
> > > > Realtek RTL8211E instead of the Generic One. Also use CONFIG_MACPWR to
> > > > turn on ethernet on startup.
> > > > 
> > > > After this patch is applied, a few issues can be seen:
> > > > 
> > > > - there's still a PHY reset timed out error that doesn't seem to cause
> > > >   any impacts to the overall connection
> > > > 
> > > > - sometimes the emac driver times out after reset (yellow LED turns on
> > > >   and never blinks)
> > > > 
> > > > For future patches: for now, CONFIG_MACPWR is the only way to enable
> > > > Ethernet on boot. There's already code on the dts for using the 
> > > > 3v3-gmac
> > > > regulator. However, it is not probed on boot, so it only starts after a
> > > > "regulator status" command is issued.
> > 
> > MACPWR is going to go away (probably in the next two weeks), so please
> > have a look at this patch and see if that works for you:
> > https://github.com/apritzel/u-boot/commit/be1fdb42968
> > 
> > > > 
> > > > More details about the troubleshooting on [1].
> > > > 
> > > > [1]
> > > > https://lore.kernel.org/u-boot/4wsvwgy56e2xfgtvioru2tf2ofkqprlts36qggivxogww6pn5j@4jk63zxhzhag/
> > > > 
> > > > Signed-off-by: Anne Macedo 
> > > > ---
> > > >  arch/arm/dts/sun50i-h6-orangepi-one-plus.dts | 2 +-
> > > >  configs/orangepi_one_plus_defconfig  | 4 
> > > >  2 files changed, 5 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/arch/arm/dts/sun50i-h6-orangepi-one-plus.dts
> > > > b/arch/arm/dts/sun50i-h6-orangepi-one-plus.dts
> > > > index 29a081e72a..6427c58f8a 100644
> > > > --- a/arch/arm/dts/sun50i-h6-orangepi-one-plus.dts
> > > > +++ b/arch/arm/dts/sun50i-h6-orangepi-one-plus.dts
> > > > @@ -37,7 +37,7 @@
> > > > 
> > > >  &mdio {
> > > > ext_rgmii_phy: ethernet-phy@1 {
> > > > -   compatible = "ethernet-phy-ieee802.3-c22";
> > > > +   compatible = "ethernet-phy-id001c.c915", 
> > > > "ethernet-phy-ieee802.3-c22" ;
> > 
> > So this is really odd, why would you need that? 001c.c915 is the ID for
> > the normal standard Realtek 8211E PHY, which would be auto-detected via
> > MDIO. You just need to define CONFIG_PHY_REALTEK to include support.
> > Forcing this in the DT is not necessary and smells wrong.
> > 
> > But I suppose you needed that to get it to work, so could this be a
> > timing issue? Maybe the PHY doesn't come up quick enough after just
> > pulling PD6 high, so the auto-detection wouldn't work? The DT has a
> > "startup-delay-us = <10>;" property, which MACPWR doesn't know
> > about and wouldn't observe.
> > So could you check whether just applying the "Remove MACPWR" patch, plus
> > adding "CONFIG_SUN8I_EMAC=y" and "CONFIG_PHY_REALTEK=y" to defconfig
> > fixes the issue? You may need to enable CONFIG_DM_REGULATOR_FIXED=y as
> > well, although this would become standard for all sunxi boards soon.
> > 
> > And you must NOT use SUNXI_SETUP_REGULATORS=0 in TF-A, as you need
> > ALDO2 to be set up by TF-A. We introduced this build option to
> > accommodate the OrangePi 3 board, which requires a specifically timed
> > regulator setup, which both TF-A and U-Boot would not observe. To not
> > crash the PHY with any incorrect regulator setup, we use this option to
> > make at least Linux work. The side effect is that some peripherals
> > (HDMI, Ethernet) will not work in U-Boot.
> > Also please note that a reset from Linux might not affect the PMIC, so
> > there might be different behaviour between and cold and warm boot.
> > 
> > Cheers,
> > Andre
> > 
> > > > reg = <1>;
> > > > };
> > > >  };
> > > > diff --git a/configs/orangepi_one_plus_defconfig
> > > > b/configs/orangepi_one_plus_defconfig
> > > > index aa5f540eb1..a1835492db 100644
> > > > --- a/configs/orangepi_one_plus_defconfig
> > > > +++ b/configs/orangepi_one_plus_defconfig
> > > > @@ -8,3 +8,7 @@ CONFIG_SUNXI_DRAM_H6_LPDDR3=y
> > > >  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> > > >  CONFIG_USB_EHCI_HCD=y
> > > >  CONFIG_USB_OHCI_HCD=y
> > > > +CONFIG_SUN8I_EMAC=y
> > > > +CONFIG_PHY_REALTEK=y
> > > > +CONFIG_PHY_ETHERNET_ID=y
> > > > +CONFIG_MACPWR="PD6"  
> > > 
> > > Adding linux-sunxi to the thread (I unfortunately forgot this list)
> > > 
> > 
> > 
> 
> Hello
> 
> Note that there is already a try to fix this in upstream linux:
> The v4 can be found at 
> https://lore.kernel.org/linux-arm-kernel/y3rdumclnkew6...@lunn.ch/T/
> 
> And that I will send soon my last version 
> https://github.com/montjoie/l

Re: [PATCH] sunxi: H6: Enable Ethernet on Orange Pi One Plus

2023-07-18 Thread Anne Macedo

On Sun, Jul 16, 2023 at 01:35:02AM +0100, Andre Przywara wrote:
> On Tue, 11 Jul 2023 19:40:21 +
> Anne Macedo  wrote:
> 
> Hi Anne,
> 
> thanks for reaching out to the list! But please try to avoid
> pushing any patches downstream (Yocto) before they are accepted
> or at least discussed upstream, see below.

Hey Andre! Apologies for the mess! I'll let folks from meta-sunxi know
and remove the patch for now from their layer.
> 
> > On 11.07.2023 02:39, Anne Macedo wrote:
> > > Enable Ethernet on Orange Pi One Plus by using the correct phy for
> > > Realtek RTL8211E instead of the Generic One. Also use CONFIG_MACPWR to
> > > turn on ethernet on startup.
> > > 
> > > After this patch is applied, a few issues can be seen:
> > > 
> > > - there's still a PHY reset timed out error that doesn't seem to cause
> > >   any impacts to the overall connection
> > > 
> > > - sometimes the emac driver times out after reset (yellow LED turns on
> > >   and never blinks)
> > > 
> > > For future patches: for now, CONFIG_MACPWR is the only way to enable
> > > Ethernet on boot. There's already code on the dts for using the 
> > > 3v3-gmac
> > > regulator. However, it is not probed on boot, so it only starts after a
> > > "regulator status" command is issued.
> 
> MACPWR is going to go away (probably in the next two weeks), so please
> have a look at this patch and see if that works for you:
> https://github.com/apritzel/u-boot/commit/be1fdb42968

Thanks! Will take a look.
> 
> > > 
> > > More details about the troubleshooting on [1].
> > > 
> > > [1]
> > > https://lore.kernel.org/u-boot/4wsvwgy56e2xfgtvioru2tf2ofkqprlts36qggivxogww6pn5j@4jk63zxhzhag/
> > > 
> > > Signed-off-by: Anne Macedo 
> > > ---
> > >  arch/arm/dts/sun50i-h6-orangepi-one-plus.dts | 2 +-
> > >  configs/orangepi_one_plus_defconfig  | 4 
> > >  2 files changed, 5 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm/dts/sun50i-h6-orangepi-one-plus.dts
> > > b/arch/arm/dts/sun50i-h6-orangepi-one-plus.dts
> > > index 29a081e72a..6427c58f8a 100644
> > > --- a/arch/arm/dts/sun50i-h6-orangepi-one-plus.dts
> > > +++ b/arch/arm/dts/sun50i-h6-orangepi-one-plus.dts
> > > @@ -37,7 +37,7 @@
> > > 
> > >  &mdio {
> > >   ext_rgmii_phy: ethernet-phy@1 {
> > > - compatible = "ethernet-phy-ieee802.3-c22";
> > > + compatible = "ethernet-phy-id001c.c915", 
> > > "ethernet-phy-ieee802.3-c22" ;
> 
> So this is really odd, why would you need that? 001c.c915 is the ID for
> the normal standard Realtek 8211E PHY, which would be auto-detected via
> MDIO. You just need to define CONFIG_PHY_REALTEK to include support.
> Forcing this in the DT is not necessary and smells wrong.

Interesting, I really tried using CONFIG_PHY_REALTEK but it never
reached the code that detected the PHY, making it only detect the
Generic PHY.
> 
> But I suppose you needed that to get it to work, so could this be a
> timing issue? Maybe the PHY doesn't come up quick enough after just
> pulling PD6 high, so the auto-detection wouldn't work? The DT has a
> "startup-delay-us = <10>;" property, which MACPWR doesn't know
> about and wouldn't observe.

That sounds like it! When I was troubleshooting, I noticed that PHY
detection (for the Generic PHY) was really intermittent. 

> So could you check whether just applying the "Remove MACPWR" patch, plus
> adding "CONFIG_SUN8I_EMAC=y" and "CONFIG_PHY_REALTEK=y" to defconfig
> fixes the issue? You may need to enable CONFIG_DM_REGULATOR_FIXED=y as
> well, although this would become standard for all sunxi boards soon.

Will take a look! Unfortunately I lost my PC :( so I will probably take
a little why to resume my troubleshooting.
> 
> And you must NOT use SUNXI_SETUP_REGULATORS=0 in TF-A, as you need
> ALDO2 to be set up by TF-A. We introduced this build option to
> accommodate the OrangePi 3 board, which requires a specifically timed
> regulator setup, which both TF-A and U-Boot would not observe. To not
> crash the PHY with any incorrect regulator setup, we use this option to
> make at least Linux work. The side effect is that some peripherals
> (HDMI, Ethernet) will not work in U-Boot.
> Also please note that a reset from Linux might not affect the PMIC, so
> there might be different behaviour between and cold and warm boot.
> 
> Cheers,
> Andre
> 
> > >   reg = <1>;
> > >   };
> > >  };
> > > diff --git a/configs/orangepi_one_plus_defconfig
> > > b/configs/orangepi_one_plus_defconfig
> > > index aa5f540eb1..a1835492db 100644
> > > --- a/configs/orangepi_one_plus_defconfig
> > > +++ b/configs/orangepi_one_plus_defconfig
> > > @@ -8,3 +8,7 @@ CONFIG_SUNXI_DRAM_H6_LPDDR3=y
> > >  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> > >  CONFIG_USB_EHCI_HCD=y
> > >  CONFIG_USB_OHCI_HCD=y
> > > +CONFIG_SUN8I_EMAC=y
> > > +CONFIG_PHY_REALTEK=y
> > > +CONFIG_PHY_ETHERNET_ID=y
> > > +CONFIG_MACPWR="PD6"  
> > 
> > Adding linux-sunxi to the thread (I unfortunately forgot this list)
> > 
>

[PATCH v2 5/5] optee: Support Rockchip OP-TEE binaries

Currently the only ARM Rockchip SoC which is supported by upstream
optee-os is RK322x. For all other ARM SoCs a
vendor-provided OP-TEE binary has to be used to have a TEE available.
Those are using a calling convension different from upstream optee-os.

This introduces CONFIG_ROCKCHIP_OPTEE_BINARY which signals that any
of those vendor binaries is used and changes the calling convension
accordingly.

Signed-off-by: Alex Bee 
---
 arch/arm/mach-rockchip/Kconfig | 8 
 common/spl/spl_optee.S | 4 
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 17dd43155d..83d8a2a056 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -449,6 +449,14 @@ config ROCKCHIP_BOOT_MODE_REG
  The Soc will enter to different boot mode(defined in 
asm/arch-rockchip/boot_mode.h)
  according to the value from this register.
 
+config ROCKCHIP_OPTEE_BINARY
+   bool "Use a OP-TEE binary provided by Rockchip"
+   depends on SPL_OPTEE_IMAGE
+   default y if ROCKCHIP_RK3036 || ROCKCHIP_RK3128 || ROCKCHIP_RK3288
+   help
+ This option enables the usage of vendor-provided OP-TEE binaries.
+ Say Y if you are using OP-TEE binary provided by Rockchip.
+
 config ROCKCHIP_RK8XX_DISABLE_BOOT_ON_POWERON
bool "Disable device boot on power plug-in"
depends on PMIC_RK8XX
diff --git a/common/spl/spl_optee.S b/common/spl/spl_optee.S
index a269904d38..ea41d8adb6 100644
--- a/common/spl/spl_optee.S
+++ b/common/spl/spl_optee.S
@@ -7,6 +7,10 @@
 #include 
 
 ENTRY(spl_optee_entry)
+#ifdef CONFIG_ROCKCHIP_OPTEE_BINARY
+   ldr r1, =CONFIG_TEXT_BASE
+#else
ldr lr, =CONFIG_TEXT_BASE
+#endif
mov pc, r3
 ENDPROC(spl_optee_entry)
-- 
2.41.0

[PATCH v2 4/5] rockchip: evb_rk3229: Update/fix README

This updates the evb_rk3229's README on howto create / use the FIT image
created by binman.
Also fix some wrong paths and update filenames which have changed in recent
upstream optee-os versions.

Signed-off-by: Alex Bee 
---
 board/rockchip/evb_rk3229/README | 72 +---
 1 file changed, 48 insertions(+), 24 deletions(-)

diff --git a/board/rockchip/evb_rk3229/README b/board/rockchip/evb_rk3229/README
index 9068225e27..a8dcc40f09 100644
--- a/board/rockchip/evb_rk3229/README
+++ b/board/rockchip/evb_rk3229/README
@@ -13,25 +13,23 @@ Compile the OP-TEE
 
   > cd optee_os
   > make clean
-  > make CROSS_COMPILE_ta_arm32=arm-none-eabi- PLATFORM=rockchip-rk322x
-  Get tee.bin in this step, copy it to U-Boot root dir:
-  > cp out/arm-plat-rockchip/core/tee-pager.bin ../u-boot/tee.bin
+  > make CROSS_COMPILE=arm-none-eabi- PLATFORM=rockchip-rk322x
+  Get tee-raw.bin in this step, copy it to U-Boot root dir:
+  > cp out/arm-plat-rockchip/core/tee-raw.bin ../u-boot/tee.bin
 
 Compile the U-Boot
 ==
 
   > cd ../u-boot
-  > export CROSS_COMPILE=arm-linux-gnueabihf-
   > make evb-rk3229_defconfig
-  > make
-  > make u-boot.itb
+  > TEE=tee.bin CROSS_COMPILE=arm-linux-gnueabihf- make
 
-  Get tpl/u-boot-tpl.bin, spl/u-boot-spl.bin and u-boot.itb in this step.
+  Get u-boot-rockchip.bin in this step.
 
 Compile the rkdeveloptool
 ===
   Follow instructions in latest README
-  > cd ../rkflashtool
+  > cd ../rkdeveloptool
   > autoreconf -i
   > ./configure
   > make
@@ -42,30 +40,56 @@ Compile the rkdeveloptool
 Both origin binaries and Tool are ready now, choose either option 1 or
 option 2 to deploy U-Boot.
 
-Package the image
-=
-
-  > cd ../u-boot
-  > tools/mkimage -n rk322x -T rksd -d tpl/u-boot-spl.bin idbloader.img
-  > cat spl/u-boot-spl.bin >> idbloader.img
-
-  Get idbloader.img in this step.
-
 Flash the image to eMMC
 ===
 Power on(or reset with RESET KEY) with MASKROM KEY preesed, and then:
   > cd ..
-  > rkdeveloptool db rkbin/rk32/rk322x_loader_v1.04.232.bin
-  > rkdeveloptool wl 64 u-boot/idbloader.img
-  > rkdeveloptool wl 0x4000 u-boot/u-boot.itb
-  > rkdeveloptool rd
+  > rkdeveloptool/rkdeveloptool db rkbin/rk32/rk322x_loader_v1.04.232.bin
+  > rkdeveloptool/rkdeveloptool wl 64 u-boot/u-boot-rockchip.bin
+  > rkdeveloptool/rkdeveloptool rd
 
 Flash the image to SD card
 ==
-  > dd if=u-boot/idbloader.img of=/dev/sdb seek=64
-  > dd if=u-boot/u-boot.itb of=/dev/sdb seek=16384
+  > dd if=u-boot/u-boot-rockchip.bin of=/dev/sdb seek=64
+
+You should be able to get U-Boot log message with OP-TEE boot info:
+
+U-Boot TPL 2023.07-00524-gf5346eba55-dirty (Jul 15 2023 - 14:22:51)
+Trying to boot from BOOTROM
+Returning to boot ROM...
+
+U-Boot SPL 2023.07-00524-gf5346eba55-dirty (Jul 15 2023 - 14:22:51 +0200)
+Trying to boot from MMC1
+I/TC:
+I/TC: Non-secure external DT found
+I/TC: Switching console to device: /serial@1103
+I/TC: OP-TEE version: 3.22.0-27-g893a762d1 (gcc version 10.3.1 20210621 
(release) (15:10.3-2021.07-4)) #1 Sat Jul 15 12:14:36 UTC 2023 arm
+I/TC: WARNING: This OP-TEE configuration might be insecure!
+I/TC: WARNING: Please check 
https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
+I/TC: Primary CPU initializing
+M/TC: Not protecting region 1: 0x6840-0x6860
+I/TC: Primary CPU switching to normal world boot
+
+
+U-Boot 2023.07-00524-gf5346eba55-dirty (Jul 15 2023 - 14:22:51 +0200)
+
+Model: Rockchip RK3229 Evaluation board
+DRAM:  1 GiB (effective 992 MiB)
+Core:  113 devices, 16 uclasses, devicetree: separate
+MMC:   mmc@3000: 1, mmc@3002: 0
+Loading Environment from MMC... Card did not respond to voltage select! : -110
+*** Warning - No block device, using default environment
+
+In:serial@1103
+Out:   serial@1103
+Err:   serial@1103
+Model: Rockchip RK3229 Evaluation board
+Net:
+Warning: ethernet@3020 (eth0) using random MAC address - 72:65:2b:f1:c5:0a
+eth0: ethernet@3020
+Hit any key to stop autoboot:  0
+=>
 
-You should be able to get U-Boot log message with OP-TEE boot info.
 
 For more detail, please reference to:
 http://opensource.rock-chips.com/wiki_Boot_option
-- 
2.41.0

[PATCH v2 3/5] rockchip: RK322x: Select SPL_OPTEE_IMAGE

For RK322x series ARM SoCs the OP-TEE is non-optional, as besides the TEE
it also provides the PSCI implementation, which is expected to be available
by upstream linux.

Select CONFIG_SPL_OPTEE_IMAGE if an FIT image is built.

Signed-off-by: Alex Bee 
---
 arch/arm/mach-rockchip/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 9d6d20bf8e..17dd43155d 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -106,6 +106,7 @@ config ROCKCHIP_RK322X
imply ROCKCHIP_COMMON_BOARD
imply SPL_SERIAL
imply SPL_ROCKCHIP_COMMON_BOARD
+   select SPL_OPTEE_IMAGE if SPL_FIT
imply TPL_SERIAL
imply TPL_ROCKCHIP_COMMON_BOARD
select TPL_LIBCOMMON_SUPPORT
-- 
2.41.0

[PATCH v2 2/5] configs: evb-rk3229: Increase SPL_STACK_R_MALLOC_SIMPLE_LEN

An OP-TEE FIT image will fail to extract in SPL because the malloc stack
size is currently limited to 0x2000 for evb-rk3229 board.

In SPL we do not have to care about size limitations, since we are no
longer bound to SRAM limits after DRAM initialization has been done in TPL.

Use the default value for CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN in order
successfully unpack the FIT image.

Signed-off-by: Alex Bee 
---
 configs/evb-rk3229_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/evb-rk3229_defconfig b/configs/evb-rk3229_defconfig
index cf73afeded..73015f098c 100644
--- a/configs/evb-rk3229_defconfig
+++ b/configs/evb-rk3229_defconfig
@@ -31,7 +31,7 @@ CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_NO_BSS_LIMIT=y
 # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 CONFIG_SPL_STACK_R=y
-CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10
 CONFIG_SPL_OPTEE_IMAGE=y
 CONFIG_SYS_BOOTM_LEN=0x400
 CONFIG_CMD_GPT=y
-- 
2.41.0

[PATCH v2 1/5] rockchip: Support OP-TEE for ARM in FIT images created by binman

CONFIG_SPL_OPTEE_IMAGE option is used during DRAM size detection for
Rockchip ARM platform to indicate that an OP-TEE binary was already loaded
and a Trusted Execution Environment (TEE) is available in order to
block/reserve a memory-region for it.

This adds a bunch of new `#if's` to u-boot-rockchip.dtsi to include the
OP-TEE binary in the FIT image for ARM SOCs if CONFIG_SPL_OPTEE_IMAGE is
selected.
That makes it a little harder to read, but I opted for that, because all
the duplicates in an extra ARM-OP-TEE-specfic .dtsi would be the greater
evil, IMHO. Besides it's more likley being "forgotten" to sync when changes
in u-boot-rockchip.dtsi are made.

The no longer required rockchip-optee.dtsi and it's inclusions are dropped.

The hardcoded load address is common across all OP-TEE implemenations for
Rockchip (vendor and upstream).

The OP-TEE-binary is non-optional if CONFIG_SPL_OPTEE_IMAGE is selected and
there will be an error if the file does not exist and/or `TEE=` build
option is missing.

Signed-off-by: Alex Bee 
---
 arch/arm/dts/rk3288-u-boot.dtsi   |  1 -
 arch/arm/dts/rockchip-optee.dtsi  | 64 ---
 arch/arm/dts/rockchip-u-boot.dtsi | 38 --
 3 files changed, 35 insertions(+), 68 deletions(-)
 delete mode 100644 arch/arm/dts/rockchip-optee.dtsi

diff --git a/arch/arm/dts/rk3288-u-boot.dtsi b/arch/arm/dts/rk3288-u-boot.dtsi
index 1920698884..c4c5a2d225 100644
--- a/arch/arm/dts/rk3288-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-u-boot.dtsi
@@ -4,7 +4,6 @@
  */
 
 #include "rockchip-u-boot.dtsi"
-#include "rockchip-optee.dtsi"
 
 / {
aliases {
diff --git a/arch/arm/dts/rockchip-optee.dtsi b/arch/arm/dts/rockchip-optee.dtsi
deleted file mode 100644
index d84c10cf43..00
--- a/arch/arm/dts/rockchip-optee.dtsi
+++ /dev/null
@@ -1,64 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright 2020 Google LLC
- */
-
-#include 
-
-#if defined(CONFIG_HAS_ROM) && defined(CONFIG_FIT)
-&binman {
-   itb {
-   filename = "u-boot.itb";
-   fit {
-   fit,external-offset = ;
-   description = "FIT image with OP-TEE support";
-   #address-cells = <1>;
-
-   images {
-   uboot {
-   description = "U-Boot";
-   type = "standalone";
-   os = "U-Boot";
-   arch = "arm";
-   compression = "none";
-   load = ;
-
-   u-boot-nodtb {
-   };
-   };
-   optee {
-   description = "OP-TEE";
-   type = "firmware";
-   arch = "arm";
-   os = "tee";
-   compression = "none";
-   load = <(CFG_SYS_SDRAM_BASE + 
0x840)>;
-   entry = <(CFG_SYS_SDRAM_BASE + 
0x840)>;
-
-   blob-ext {
-   filename = "tee.bin";
-   };
-   };
-   fdt {
-   description = CONFIG_SYS_BOARD;
-   type = "flat_dt";
-   compression = "none";
-
-   u-boot-dtb {
-   };
-   };
-   };
-
-   configurations {
-   default = "conf";
-   conf {
-   description = CONFIG_SYS_BOARD;
-   firmware = "optee";
-   loadables = "uboot";
-   fdt = "fdt";
-   };
-   };
-   };
-   };
-};
-#endif
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi 
b/arch/arm/dts/rockchip-u-boot.dtsi
index 2878b80926..be2658e8ef 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -33,9 +33,13 @@
};
};
 
-#if defined(CONFIG_SPL_FIT) && defined(CONFIG_ARM64)
+#if defined(CONFIG_SPL_FIT) && (defined(CONFIG_ARM64) || 
defined(CONFIG_SPL_OPTEE_IMAGE))
fit: fit {
+#ifdef CONFIG_ARM64
description = "FIT image for U-Boot with bl31 (TF-A)";
+#else
+   description = "FIT image with OP-TEE";
+#endif
#ad

[PATCH v2 0/5] rockchip: Support OP-TEE binaries in ARM FIT images

This adds support for OP-TEE binaries to Rockchip's ARM FIT image 
generation by binman.

Currently there is an extra (and outdated) rockchip-optee.dtsi which can
create an u-boot.itb which can also hold the OP-TEE binary. It has to be
included manually in the respective SoC-specific device trees. But even if
that is done, it won't be merged in rockchip-u-boot.bin, which aims to be 
platform-consistent.
The bootable FIT image must therefore currently be created manually.

This will be done automatically with this patch-set and a single
u-boot-rockchip.bin file with an bootable FIT image containing all
binaries will be generated.

Additionally this series adds a configuration option which has to be
set if a vendor-provided OP-TEE binary is used. This is required as those
use a different calling convention.
For RK3036, RK3128 and RK3288 SoCs this currently the only option to get an
TEE, as no upstream implementation exists for them.
Those binaries can be found at [1]

There are also some adaptions for RK322x in order to successfully use that
FIT image and some changes to the documenation.

This series has been tested on RK3229 (both vendor and upstream OP-TEE) and
RK3288 (vendor implementation only).

[1] https://github.com/rockchip-linux/rkbin

Changes in v2:

1/5:
 * whitespace fixes in rockchip-u-boot.dtsi
2/5:
 * instead of dropping CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN, set it to the
   current default value
3/5:
 * fix: `select SPL_OPTEE_IMAGE` instead of `select CONFIG_SPL_OPTEE_IMAGE`
   in Kconfig
4/5:
 * refer to use "tee-raw.bin" instead of "tee-pager_v2.bin" in README
   (Jerome Forissier)
5/5:
 * drop empty line in Kconfig help text
 * fix subject "OPTEE" -> "OP-TEE"
 * ROCKCHIP_OPTEE_BINARY should depend on SPL_OPTEE_IMAGE only, as the
   latter depends on SPL_FIT already
   (via `depends on SPL_LOAD_FIT || SPL_LOAD_FIT_FULL`)

Alex Bee (5):
  rockchip: Support OP-TEE for ARM in FIT images created by binman
  configs: evb-rk3229: Increase SPL_STACK_R_MALLOC_SIMPLE_LEN
  rockchip: RK322x: Select SPL_OPTEE_IMAGE
  rockchip: evb_rk3229: Update/fix README
  optee: Support Rockchip OP-TEE binaries

 arch/arm/dts/rk3288-u-boot.dtsi   |  1 -
 arch/arm/dts/rockchip-optee.dtsi  | 64 ---
 arch/arm/dts/rockchip-u-boot.dtsi | 38 ++--
 arch/arm/mach-rockchip/Kconfig|  9 
 board/rockchip/evb_rk3229/README  | 72 ---
 common/spl/spl_optee.S|  4 ++
 configs/evb-rk3229_defconfig  |  2 +-
 7 files changed, 97 insertions(+), 93 deletions(-)
 delete mode 100644 arch/arm/dts/rockchip-optee.dtsi


base-commit: 890233ca5569e5787d8407596a12b9fca80952bf
-- 
2.41.0

Re: [PATCH 3/5] m68k: dts: add watchdog node

2023-07-18 Thread Stefan Roese


Hi Angelo,

On 7/18/23 15:58, Angelo Dureghello wrote:

Hi Stefan,

On 18/07/23 2:26 PM, Stefan Roese wrote:

On 6/25/23 21:35, Angelo Dureghello wrote:

Add watchdog node for the implemented mcf_wdt driver.

Signed-off-by: Angelo Dureghello 
---
  arch/m68k/dts/M5208EVBE.dts | 5 +
  arch/m68k/dts/mcf5208.dtsi  | 7 +++
  arch/m68k/dts/mcf523x.dtsi  | 7 +++
  arch/m68k/dts/mcf5271.dtsi  | 7 +++
  arch/m68k/dts/mcf5275.dtsi  | 7 +++
  arch/m68k/dts/mcf5282.dtsi  | 7 +++
  arch/m68k/dts/mcf5329.dtsi  | 7 +++
  arch/m68k/dts/mcf537x.dtsi  | 7 +++
  8 files changed, 54 insertions(+)

diff --git a/arch/m68k/dts/M5208EVBE.dts b/arch/m68k/dts/M5208EVBE.dts
index 1c32718af4..ec203e8b69 100644
--- a/arch/m68k/dts/M5208EVBE.dts
+++ b/arch/m68k/dts/M5208EVBE.dts
@@ -15,6 +15,11 @@
  };
  };
+&wdog0 {
+    timeout-sec = <32>;
+    status = "okay";
+};
+
  &uart0 {
  bootph-all;
  status = "okay";
diff --git a/arch/m68k/dts/mcf5208.dtsi b/arch/m68k/dts/mcf5208.dtsi
index 9392facfa8..b06dc4bb26 100644
--- a/arch/m68k/dts/mcf5208.dtsi
+++ b/arch/m68k/dts/mcf5208.dtsi
@@ -16,6 +16,13 @@
  #address-cells = <1>;
  #size-cells = <1>;
+    wdog0: watchdog@fc08c000 {
+    compatible = "fsl,mcf5208-wdt";
+    reg = <0xfc08c000 0x10>;
+    big-endian;
+    status = "disabled";
+    };


I was not able to find this compatible property in the Linux Kernel
source tree. Is this the official version of the Coldfire WDT DT node?
Just checking..



there is no fdt support for m68k in Linux, after discussing the need in 
u-boot, i implemented fdt here the best i could.


Ok, I see. BTW: Is "big-endian" necessary here?

Thanks,
Stefan


Thanks,
Stefan


+
  uart0: uart@fc06 {
  compatible = "fsl,mcf-uart";
  reg = <0xfc06 0x40>;
diff --git a/arch/m68k/dts/mcf523x.dtsi b/arch/m68k/dts/mcf523x.dtsi
index 41c7b9b2d1..fb5a4cdc21 100644
--- a/arch/m68k/dts/mcf523x.dtsi
+++ b/arch/m68k/dts/mcf523x.dtsi
@@ -23,6 +23,13 @@
  ranges = <0x 0x4000 0x4000>;
  reg = <0x4000 0x4000>;
+    wdog0: watchdog@14 {
+    compatible = "fsl,mcf5208-wdt";
+    reg = <0x14 0x10>;
+    big-endian;
+    status = "disabled";
+    };
+
  uart0: uart@200 {
  compatible = "fsl,mcf-uart";
  reg = <0x200 0x40>;
diff --git a/arch/m68k/dts/mcf5271.dtsi b/arch/m68k/dts/mcf5271.dtsi
index fc82bd3c24..0884c13ab1 100644
--- a/arch/m68k/dts/mcf5271.dtsi
+++ b/arch/m68k/dts/mcf5271.dtsi
@@ -23,6 +23,13 @@
  ranges = <0x 0x4000 0x4000>;
  reg = <0x4000 0x4000>;
+    wdog0: watchdog@14 {
+    compatible = "fsl,mcf5208-wdt";
+    reg = <0x14 0x10>;
+    big-endian;
+    status = "disabled";
+    };
+
  uart0: uart@200 {
  compatible = "fsl,mcf-uart";
  reg = <0x200 0x40>;
diff --git a/arch/m68k/dts/mcf5275.dtsi b/arch/m68k/dts/mcf5275.dtsi
index 402517cdec..78210569da 100644
--- a/arch/m68k/dts/mcf5275.dtsi
+++ b/arch/m68k/dts/mcf5275.dtsi
@@ -24,6 +24,13 @@
  ranges = <0x 0x4000 0x4000>;
  reg = <0x4000 0x4000>;
+    wdog0: watchdog@14 {
+    compatible = "fsl,mcf5208-wdt";
+    reg = <0x14 0x10>;
+    big-endian;
+    status = "disabled";
+    };
+
  uart0: uart@200 {
  compatible = "fsl,mcf-uart";
  reg = <0x200 0x40>;
diff --git a/arch/m68k/dts/mcf5282.dtsi b/arch/m68k/dts/mcf5282.dtsi
index 883c0d0324..40704c5202 100644
--- a/arch/m68k/dts/mcf5282.dtsi
+++ b/arch/m68k/dts/mcf5282.dtsi
@@ -23,6 +23,13 @@
  ranges = <0x 0x4000 0x4000>;
  reg = <0x4000 0x4000>;
+    wdog0: watchdog@14 {
+    compatible = "fsl,mcf5282-wdt";
+    reg = <0x14 0x10>;
+    big-endian;
+    status = "disabled";
+    };
+
  uart0: uart@200 {
  compatible = "fsl,mcf-uart";
  reg = <0x200 0x40>;
diff --git a/arch/m68k/dts/mcf5329.dtsi b/arch/m68k/dts/mcf5329.dtsi
index 7501cc4b01..50ff73bca7 100644
--- a/arch/m68k/dts/mcf5329.dtsi
+++ b/arch/m68k/dts/mcf5329.dtsi
@@ -16,6 +16,13 @@
  #address-cells = <1>;
  #size-cells = <1>;
+    wdog0: watchdog@fc098000 {
+    compatible = "fsl,mcf5208-wdt";
+    reg = <0xfc08c000 0x10>;
+    big-endian;
+    status = "disabled";
+    };
+
  uart0: uart@fc06 {
  compatible = "fsl,mcf-uart";
  reg = <0xfc06 0x40>;
diff --git a/arch/m68k/dts/mcf537x.dtsi b/arch/m68k/dts/mcf537x.dtsi
index 338b8b4

Re: [PATCH] menu: Ignore prompt variable if timeout is != 0

On 2023-07-14 09:36, FUKAUMI Naoki wrote:
> From: Manuel Traut 
> 
> Since 739e8361f3fe78038251216df6096a32bc2d5839, a system with the following
> /boot/extlinux/extlinux.conf (which sets timeout to 50) immediately boots the
> first entry in the config without displaying a boot menu.  According to the
> description, that should only happen if both prompt and timeout are set to 
> zero
> in the config, but it also happens with timeout set to a non-zero value.
> 
> Reported-by: Karsten Merker 
> Signed-off-by: Manuel Traut 
> ---
>  common/menu.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/common/menu.c b/common/menu.c
> index 8fe00965c0..8eab87 100644
> --- a/common/menu.c
> +++ b/common/menu.c
> @@ -277,6 +277,9 @@ int menu_get_choice(struct menu *m, void **choice)
>   if (!m->item_cnt)
>   return -ENOENT;
>  
> + if (m->timeout)
> + return menu_interactive_choice(m, choice);

This should not be needed, if the user wants to prompt the menu there is
the PROMPT keyword that can be used in extlinux.conf, e.g.:

  PROMPT 1
  TIMEOUT 50

See https://wiki.archlinux.org/title/Syslinux#Boot_prompt

That should set pxe cfg->prompt = 1 and that in turn menu m->prompt = 1.

Regards,
Jonas

> +
>   if (!m->prompt)
>   return menu_default_choice(m, choice);
>

Re: [PATCH 1/5] drivers: watchdog: add mcf watchdog support

2023-07-18 Thread Angelo Dureghello


Hi Stefan,

thanks for the feedbacks,

On 18/07/23 2:23 PM, Stefan Roese wrote:

On 6/25/23 21:35, Angelo Dureghello wrote:

This watchdog driver applies to the following
mcf families:

- mcf52x2 (5271 5275 5282)
- mcf532x (5329 5373)
- mcf523x (5235)

Cpu's not listed for each family does not have WDT module.

Note, after some attempts testing by qemu on 5208 i
finally abandoned, watchdog seems not implemented properly.

The driver has been tested in a real M5282EVM.

Signed-off-by: Angelo Dureghello 
---
  drivers/watchdog/Kconfig   |   7 ++
  drivers/watchdog/Makefile  |   1 +
  drivers/watchdog/mcf_wdt.c | 162 +
  3 files changed, 170 insertions(+)
  create mode 100644 drivers/watchdog/mcf_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 646663528a..07fc4940e9 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -178,6 +178,13 @@ config WDT_MAX6370
  help
    Select this to enable max6370 watchdog timer.
+config WDT_MCF
+    bool "ColdFire family watchdog timer support"
+    depends on WDT
+    help
+  Select this to enable ColdFire watchdog timer,
+  which supports mcf52x2 mcf532x mcf523x families.
+
  config WDT_MESON_GXBB
  bool "Amlogic watchdog timer support"
  depends on WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index fd5d9c7376..eef786f5e7 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_WDT_CDNS) += cdns_wdt.o
  obj-$(CONFIG_WDT_FTWDT010) += ftwdt010_wdt.o
  obj-$(CONFIG_WDT_GPIO) += gpio_wdt.o
  obj-$(CONFIG_WDT_MAX6370) += max6370_wdt.o
+obj-$(CONFIG_WDT_MCF) += mcf_wdt.o
  obj-$(CONFIG_WDT_MESON_GXBB) += meson_gxbb_wdt.o
  obj-$(CONFIG_WDT_MPC8xxx) += mpc8xxx_wdt.o
  obj-$(CONFIG_WDT_MT7620) += mt7620_wdt.o
diff --git a/drivers/watchdog/mcf_wdt.c b/drivers/watchdog/mcf_wdt.c
new file mode 100644
index 00..03842135c5
--- /dev/null
+++ b/drivers/watchdog/mcf_wdt.c
@@ -0,0 +1,162 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * mcf_wdt.c - driver for ColdFire on-chip watchdog
+ *
+ * Author: Angelo Dureghello 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TIMEOUT_MAX    3360
+#define TIMEOUT_MIN    500


Those 2 defines above are not used in this source. Please drop.


ok

+
+#define DIVIDER_5XXX    4096
+#define DIVIDER_5282    8192
+
+#define WCR_EN  BIT(0)
+#define WCR_HALTED  BIT(1)
+#define WCR_DOZE    BIT(2)
+#define WCR_WAIT    BIT(3)
+
+struct watchdog_regs {
+    u16 wcr;    /* Control */
+    u16 wmr;    /* Service */
+    u16 wcntr;  /* Counter */
+    u16 wsr;    /* Reset Status */
+};
+
+#if defined(CONFIG_WDT_MCF)


Is it possible to drop this "#if" somehow?


will try

+static void mcf_watchdog_reset(struct watchdog_regs *wdog)
+{
+#ifndef CONFIG_WATCHDOG_RESET_DISABLE
+    writew(0x, &wdog->wsr);
+    writew(0x, &wdog->wsr);
+#endif /* CONFIG_WATCHDOG_RESET_DISABLE*/


checkpatch.pl warning:

WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' 
where possible

#37: FILE: drivers/watchdog/mcf_wdt.c:37:
+#ifndef CONFIG_WATCHDOG_RESET_DISABLE


ok will try to use if (IS_ENABLED

 +}

+
+static void mcf_watchdog_init(struct watchdog_regs *wdog, u32 
fixed_divider,

+  u64 timeout_msecs)
+{
+    u32 wdog_module;
+
+    /*
+ * The timer watchdog can be set between
+ * 0.5 and 128 Seconds.
+ */
+
+    /* set timeout and enable watchdog */
+    wdog_module = ((CFG_SYS_CLK / 1000) * timeout_msecs);
+
+    writew((u16)(wdog_module / fixed_divider), &wdog->wmr);
+    writew(WCR_EN, &wdog->wcr);
+
+    mcf_watchdog_reset(wdog);
+}
+
+#if !CONFIG_IS_ENABLED(WDT)
+void hw_watchdog_reset(void)
+{
+    struct watchdog_regs *wdog = (struct watchdog_regs *)MMAP_WDOG;
+
+    mcf_watchdog_reset(wdog);
+}


Can you perhaps completely remove this hw_watchdog stuff? Is it really
needed on these Coldfire platforms?


Will recheck, maybe yes,

+
+void hw_watchdog_init(void)
+{
+    struct watchdog_regs *wdog = (struct watchdog_regs *)MMAP_WDOG;
+
+    if (IS_ENABLED(CONFIG_MCF5282))
+    writew(&wdog->wmr, wdog_module / DIVIDER_5282);
+    else
+    writew(&wdog->wmr, wdog_module / DIVIDER_5XXX);
+
+    mcf_watchdog_init(wdog, CONFIG_WATCHDOG_TIMEOUT_MSECS);
+}
+
+#else /* CONFIG_WDT */
+
+struct mcf_wdt_priv {
+    void __iomem *base;
+    u32 fixed_divider;
+};
+
+static int mcf_wdt_expire_now(struct udevice *dev, ulong flags)
+{
+    hang();
+
+    return 0;
+}
+
+static int mcf_wdt_reset(struct udevice *dev)
+{
+    struct mcf_wdt_priv *priv = dev_get_priv(dev);
+
+    mcf_watchdog_reset(priv->base);
+
+    return 0;
+}
+
+static int mcf_wdt_start(struct udevice *dev, u64 timeout, ulong flags)
+{
+    struct mcf_wdt_priv *priv = dev_get_priv(dev);
+
+    /* Timeout from fdt is in second, driver works in msecs */


I'm a bit confused here. AFAIK, the time passed into th

Re: [PATCH] env: Fix default environment saving issue

On Tue, Jul 04, 2023 at 12:16:07AM -0600, Ashok Reddy Soma wrote:

> When CONFIG_SYS_REDUNDAND_ENVIRONMENT is enabled, by default env is
> getting saved to redundant environment irrespective of primary env is
> present or not.
> 
> It means even if primary and redundant environment are not present, by
> default, env is getting stored to redundant environment. Even if primary
> env is present, it is choosing to store in redudndant env.
> 
> Ideally it should look for primary env and choose to store in primary env
> if it is present. If both primary and redundant env are not present then
> it should save in to primary env area.
> 
> Fix the issue by making env_valid = ENV_INVALID when both the
> environments are not present.
> 
> Signed-off-by: Ashok Reddy Soma 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] android_ab: Try backup booloader_message

On Mon, Jul 03, 2023 at 10:07:13AM -0500, Joshua Watt wrote:

> Some devices keep 2 copies of the bootloader_message in the misc
> partition and write each in sequence when updating. This ensures that
> there is always one valid copy of the bootloader_message. Teach u-boot
> to optionally try a backup bootloader_message from a specified offset if
> the primary one fails its CRC check.
> 
> Signed-off-by: Joshua Watt 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 5/5] cmd: mbr: Force DOS driver to be used for verify