Re: [PATCH] board/km: remove kirkwood boards

2022-08-16 Thread Stefan Roese

On 15.08.22 08:35, Holger Brunck wrote:

These boards are out of maintenance and can be removed.

Signed-off-by: Holger Brunck 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  arch/arm/dts/Makefile  |   1 -
  arch/arm/dts/kirkwood-km_common.dtsi   |  48 ---
  arch/arm/dts/kirkwood-km_kirkwood.dts  |  53 ---
  board/keymile/Kconfig  |   1 -
  board/keymile/km_arm/Kconfig   |  86 -
  board/keymile/km_arm/MAINTAINERS   |  11 -
  board/keymile/km_arm/Makefile  |  11 -
  board/keymile/km_arm/fpga_config.c | 255 --
  board/keymile/km_arm/km_arm.c  | 520 -
  board/keymile/km_arm/kwbimage-memphis.cfg  | 179 --
  board/keymile/km_arm/kwbimage.cfg  | 161 -
  board/keymile/km_arm/kwbimage_128M16_1.cfg | 257 --
  board/keymile/km_arm/kwbimage_256M8_1.cfg  | 257 --
  board/keymile/scripts/develop-common.txt   |   2 +-
  configs/km_kirkwood_128m16_defconfig   |  81 -
  configs/km_kirkwood_defconfig  |  81 -
  configs/km_kirkwood_pci_defconfig  |  81 -
  configs/kmcoge5un_defconfig|  84 -
  configs/kmnusa_defconfig   |  85 -
  configs/kmsuse2_defconfig  |  85 -
  include/configs/km/km_arm.h| 158 -
  include/configs/km_kirkwood.h  | 118 ---
  scripts/config_whitelist.txt   |   1 -
  23 files changed, 1 insertion(+), 2615 deletions(-)
  delete mode 100644 arch/arm/dts/kirkwood-km_common.dtsi
  delete mode 100644 arch/arm/dts/kirkwood-km_kirkwood.dts
  delete mode 100644 board/keymile/km_arm/Kconfig
  delete mode 100644 board/keymile/km_arm/MAINTAINERS
  delete mode 100644 board/keymile/km_arm/Makefile
  delete mode 100644 board/keymile/km_arm/fpga_config.c
  delete mode 100644 board/keymile/km_arm/km_arm.c
  delete mode 100644 board/keymile/km_arm/kwbimage-memphis.cfg
  delete mode 100644 board/keymile/km_arm/kwbimage.cfg
  delete mode 100644 board/keymile/km_arm/kwbimage_128M16_1.cfg
  delete mode 100644 board/keymile/km_arm/kwbimage_256M8_1.cfg
  delete mode 100644 configs/km_kirkwood_128m16_defconfig
  delete mode 100644 configs/km_kirkwood_defconfig
  delete mode 100644 configs/km_kirkwood_pci_defconfig
  delete mode 100644 configs/kmcoge5un_defconfig
  delete mode 100644 configs/kmnusa_defconfig
  delete mode 100644 configs/kmsuse2_defconfig
  delete mode 100644 include/configs/km/km_arm.h
  delete mode 100644 include/configs/km_kirkwood.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7330121..3f5bfca 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -58,7 +58,6 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += \
kirkwood-ib62x0.dtb \
kirkwood-iconnect.dtb \
kirkwood-is2.dtb \
-   kirkwood-km_kirkwood.dtb \
kirkwood-lsxhl.dtb \
kirkwood-lschlv2.dtb \
kirkwood-net2big.dtb \
diff --git a/arch/arm/dts/kirkwood-km_common.dtsi 
b/arch/arm/dts/kirkwood-km_common.dtsi
deleted file mode 100644
index 9d0fc51..000
--- a/arch/arm/dts/kirkwood-km_common.dtsi
+++ /dev/null
@@ -1,48 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/ {
-   chosen {
-   bootargs = "console=ttyS0,115200n8 earlyprintk";
-   stdout-path = &uart0;
-   };
-
-   ocp@f100 {
-   pinctrl: pin-controller@1 {
-   pinctrl-0 = < &pmx_i2c_gpio_sda &pmx_i2c_gpio_scl >;
-   pinctrl-names = "default";
-
-   pmx_i2c_gpio_sda: pmx-gpio-sda {
-   marvell,pins = "mpp8";
-   marvell,function = "gpio";
-   };
-   pmx_i2c_gpio_scl: pmx-gpio-scl {
-   marvell,pins = "mpp9";
-   marvell,function = "gpio";
-   };
-   };
-
-   serial@12000 {
-   status = "okay";
-   clock-frequency = <2>;
-   };
-   };
-
-   i2c {
-   compatible = "i2c-gpio";
-   gpios = < &gpio0 8 GPIO_ACTIVE_HIGH  /* sda */
- &gpio0 9 GPIO_ACTIVE_HIGH>;/* scl */
-   i2c-gpio,delay-us = <2>;  /* ~100 kHz */
-   };
-};
-
-&nand {
-   status = "okay";
-   chip-delay = <25>;
-};
-
-&pciec {
-status = "okay";
-};
-
-&pcie0 {
-   status = "okay";
-};
diff --git a/arch/arm/dts/kirkwood-km_kirkwood.dts 
b/arch/arm/dts/kirkwood-km_kirkwood.dts
deleted file mode 100644
index b2c0209..000
--- a/arch/arm/dts/kirkwood-km_kirkwood.dts
+++ /dev/null
@@ -1,53 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/dts-v1/;
-
-#include "kirkwood.dtsi"
-#include "kirkwood-98dx4122.dtsi"
-#include "kirkwood-km_common.dtsi"
-
-/ {
-   model

Re: [PATCH] arm: mvebu: mbus: Fix mbus driver to work also after U-Boot relocation

2022-08-16 Thread Stefan Roese

On 10.08.22 14:46, Pali Rohár wrote:

mbus driver is initialized from arch_cpu_init() callback which is called
before relocation. This driver stores lot of functions and structure
pointers into global variables, so it is data position dependent.

Therefore after relocations all pointers are invalid and driver does not
work anymore as all pointers referes to the old memory, which overlaps with
CONFIG_SYS_LOAD_ADDR and ${loadaddr}.

For example U-Boot fuse command crashes if loadaddr memory is cleared or
rewritten by some image loaded by U-Boot load command.

   mw.w ${loadaddr} 0x0 1
   fuse read 0 1 2

Fix this issue by removing of all mbus global variables in which are stored
pointers to structures or functions which changes during relocation. And
replace it by direct function calls (not via pointers). With this change
fuse command finally works.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  arch/arm/mach-kirkwood/include/mach/cpu.h |   3 -
  arch/arm/mach-mvebu/include/mach/cpu.h|   3 -
  arch/arm/mach-mvebu/mbus.c| 167 +-
  board/alliedtelesis/x530/x530.c   |   2 +-
  board/maxbcm/maxbcm.c |   8 +-
  board/theadorable/theadorable.c   |   4 +-
  include/linux/mbus.h  |  13 +-
  7 files changed, 75 insertions(+), 125 deletions(-)

diff --git a/arch/arm/mach-kirkwood/include/mach/cpu.h 
b/arch/arm/mach-kirkwood/include/mach/cpu.h
index 71c546f9acf6..d8639c60352b 100644
--- a/arch/arm/mach-kirkwood/include/mach/cpu.h
+++ b/arch/arm/mach-kirkwood/include/mach/cpu.h
@@ -144,9 +144,6 @@ struct kwgpio_registers {
u32 irq_level;
  };
  
-/* Needed for dynamic (board-specific) mbus configuration */

-extern struct mvebu_mbus_state mbus_state;
-
  /*
   * functions
   */
diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h 
b/arch/arm/mach-mvebu/include/mach/cpu.h
index 689c96bd4eac..d9fa1f32aa52 100644
--- a/arch/arm/mach-mvebu/include/mach/cpu.h
+++ b/arch/arm/mach-mvebu/include/mach/cpu.h
@@ -122,9 +122,6 @@ struct sar_freq_modes {
u32 d_clk;
  };
  
-/* Needed for dynamic (board-specific) mbus configuration */

-extern struct mvebu_mbus_state mbus_state;
-
  /*
   * functions
   */
diff --git a/arch/arm/mach-mvebu/mbus.c b/arch/arm/mach-mvebu/mbus.c
index 3b1b9f73ebf6..7092f6cc10c2 100644
--- a/arch/arm/mach-mvebu/mbus.c
+++ b/arch/arm/mach-mvebu/mbus.c
@@ -88,31 +88,34 @@
  
  #define DOVE_DDR_BASE_CS_OFF(n) ((n) << 4)
  
-struct mvebu_mbus_state;

-
-struct mvebu_mbus_soc_data {
-   unsigned int num_wins;
-   unsigned int num_remappable_wins;
-   unsigned int (*win_cfg_offset)(const int win);
-   void (*setup_cpu_target)(struct mvebu_mbus_state *s);
-};
-
-struct mvebu_mbus_state mbus_state
-   __section(".data");
  static struct mbus_dram_target_info mbus_dram_info
__section(".data");
  
+#if defined(CONFIG_ARCH_MVEBU)

+   #define MVEBU_MBUS_NUM_WINS 20
+   #define MVEBU_MBUS_NUM_REMAPPABLE_WINS 8
+   #define MVEBU_MBUS_WIN_CFG_OFFSET(win) 
armada_370_xp_mbus_win_offset(win)
+#elif defined(CONFIG_ARCH_KIRKWOOD)
+   #define MVEBU_MBUS_NUM_WINS 8
+   #define MVEBU_MBUS_NUM_REMAPPABLE_WINS 4
+   #define MVEBU_MBUS_WIN_CFG_OFFSET(win) orion5x_mbus_win_offset(win)
+#else
+   #error "No supported architecture"
+#endif
+
+static unsigned int armada_370_xp_mbus_win_offset(int win);
+static unsigned int orion5x_mbus_win_offset(int win);
+
  /*
   * Functions to manipulate the address decoding windows
   */
  
-static void mvebu_mbus_read_window(struct mvebu_mbus_state *mbus,

-  int win, int *enabled, u64 *base,
+static void mvebu_mbus_read_window(int win, int *enabled, u64 *base,
   u32 *size, u8 *target, u8 *attr,
   u64 *remap)
  {
-   void __iomem *addr = mbus->mbuswins_base +
-   mbus->soc->win_cfg_offset(win);
+   void __iomem *addr = (void __iomem *)MVEBU_CPU_WIN_BASE +
+   MVEBU_MBUS_WIN_CFG_OFFSET(win);
u32 basereg = readl(addr + WIN_BASE_OFF);
u32 ctrlreg = readl(addr + WIN_CTRL_OFF);
  
@@ -133,7 +136,7 @@ static void mvebu_mbus_read_window(struct mvebu_mbus_state *mbus,

*attr = (ctrlreg & WIN_CTRL_ATTR_MASK) >> WIN_CTRL_ATTR_SHIFT;
  
  	if (remap) {

-   if (win < mbus->soc->num_remappable_wins) {
+   if (win < MVEBU_MBUS_NUM_REMAPPABLE_WINS) {
u32 remap_low = readl(addr + WIN_REMAP_LO_OFF);
u32 remap_hi  = readl(addr + WIN_REMAP_HI_OFF);
*remap = ((u64)remap_hi << 32) | remap_low;
@@ -143,27 +146,25 @@ static void mvebu_mbus_read_window(struct 
mvebu_mbus_state *mbus,
}
  }
  
-static void mvebu_mbus_disable_window(struct mvebu_mbus_state *mbus,

- int win)
+static void mvebu_mbus_disable_window(int win

Re: [PATCH] arm: mvebu: turris_mox: Set "sfp" label in eth1 DT node when only Mox SFP is detected

2022-08-16 Thread Stefan Roese

On 10.08.22 12:54, Pali Rohár wrote:

When Mox SFP module is connected after Topaz or Peridot module then port DT
node already contains "sfp" label. But Mox SFP module can be connected also
without Topaz or Peridot module in which case it is connected directly into
he eth1 DT node, which is without any label. So add "sfp" label into eth1
DT node in this case.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan

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

diff --git a/board/CZ.NIC/turris_mox/turris_mox.c 
b/board/CZ.NIC/turris_mox/turris_mox.c
index 28259e71405f..3dbd68e52366 100644
--- a/board/CZ.NIC/turris_mox/turris_mox.c
+++ b/board/CZ.NIC/turris_mox/turris_mox.c
@@ -821,6 +821,11 @@ int ft_board_setup(void *blob, struct bd_info *bd)
 "sgmii");
if (res < 0)
return res;
+
+   res = fdt_setprop_string(blob, node, "label",
+"sfp");
+   if (res < 0)
+   return res;
}
  
  		res = fdt_status_okay_by_compatible(blob, "cznic,moxtet-gpio");


Viele Grüße,
Stefan Roese

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


Re: [PATCH] arm: mvebu: turris_omnia: Show MCU version

2022-08-16 Thread Stefan Roese

On 10.08.22 11:00, Pali Rohár wrote:

There are already more MCU firmware versions for Turris Omnia in
production, so display git commit (version) of the MCU firmware during
U-Boot startup. It will help to identify what version of MCU firmware is
Turris Omnia using.

MCU firmware for Turris Omnia is open source and available at website:
https://gitlab.nic.cz/turris/hw/omnia_hw_ctrl

It can be updated from running system via i2c bus with this tool:
https://gitlab.nic.cz/turris/omnia-mcutool

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


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

diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 5ddd873d0250..caae8ce44695 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -21,6 +21,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -61,7 +62,9 @@ DECLARE_GLOBAL_DATA_PTR;
  enum mcu_commands {
CMD_GET_STATUS_WORD = 0x01,
CMD_GET_RESET   = 0x09,
+   CMD_GET_FW_VERSION_APP  = 0x0a,
CMD_WATCHDOG_STATE  = 0x0b,
+   CMD_GET_FW_VERSION_BOOT = 0x0e,
  
  	/* available if STS_FEATURES_SUPPORTED bit set in status word */

CMD_GET_FEATURES= 0x10,
@@ -428,6 +431,38 @@ static const char * const omnia_get_mcu_type(void)
return mcu_types[stsword & STS_MCU_TYPE_MASK];
  }
  
+static const char * const omnia_get_mcu_version(void)

+{
+   static char version[82];
+   u8 version_app[20];
+   u8 version_boot[20];
+   int ret;
+
+   ret = omnia_mcu_read(CMD_GET_FW_VERSION_APP, &version_app, 
sizeof(version_app));
+   if (ret)
+   return "unknown";
+
+   ret = omnia_mcu_read(CMD_GET_FW_VERSION_BOOT, &version_boot, 
sizeof(version_boot));
+   if (ret)
+   return "unknown";
+
+   /*
+* If git commits of MCU bootloader and MCU application are same then
+* show version only once. If they are different then show both commits.
+*/
+   if (!memcmp(version_app, version_boot, 20)) {
+   bin2hex(version, version_app, 20);
+   version[40] = '\0';
+   } else {
+   bin2hex(version, version_boot, 20);
+   version[40] = '/';
+   bin2hex(version + 41, version_app, 20);
+   version[81] = '\0';
+   }
+
+   return version;
+}
+
  /*
   * Define the DDR layout / topology here in the board file. This will
   * be used by the DDR3 init code in the SPL U-Boot version to configure
@@ -944,6 +979,7 @@ int show_board_info(void)
err = turris_atsha_otp_get_serial_number(&version_num, &serial_num);
printf("Model: Turris Omnia\n");
printf("  MCU type: %s\n", omnia_get_mcu_type());
+   printf("  MCU version: %s\n", omnia_get_mcu_version());
printf("  RAM size: %i MiB\n", omnia_get_ram_size_gb() * 1024);
if (err)
printf("  Serial Number: unknown\n");


Viele Grüße,
Stefan Roese

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


Re: [PATCH v2 2/2] cmd: mvebu/bubt: Check for A38x/A37xx OTP secure bits and secure boot

2022-08-16 Thread Stefan Roese

On 09.08.22 21:42, Pali Rohár wrote:

For obvious reasons BootROMS rejects unsigned images when secure boot is
enabled in OTP secure bits. So check for OPT secure bits and do not allow
flashing unsigned images when secure boot is enabled. Access to OTP via
U-Boot fuse API is currently implemented only for A38x and A37xx SoCs.

Additionally Armada 3700 BootROM rejects signed trusted image when secure
boot is not enabled in OTP. So add also check for this case. On the other
hand Armada 38x BootROM acceps images with secure boot header when secure
boot is not enabled in OTP.

OTP secure bits may have burned also boot device source. Check it also and
reject flashing images to target storage which does not match OTP.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
Changes in v2:
* Add missing dependency on MVEBU_EFUSE
* Use only for A38x and A37xx
---
  cmd/mvebu/Kconfig |   1 +
  cmd/mvebu/bubt.c  | 127 +++---
  2 files changed, 120 insertions(+), 8 deletions(-)

diff --git a/cmd/mvebu/Kconfig b/cmd/mvebu/Kconfig
index 120397d6d4d0..9ec3aa983a51 100644
--- a/cmd/mvebu/Kconfig
+++ b/cmd/mvebu/Kconfig
@@ -5,6 +5,7 @@ config CMD_MVEBU_BUBT
bool "bubt"
select SHA256 if ARMADA_3700
select SHA512 if ARMADA_3700
+   select MVEBU_EFUSE if ARMADA_38X || ARMADA_3700
help
  bubt - Burn a u-boot image to flash
  For details about bubt command please see the documentation
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 3b6ffb7ffd1f..feb1e778a98c 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -13,6 +13,8 @@
  #include 
  #include 
  #include 
+#include 
+#include 
  
  #include 

  #include 
@@ -121,6 +123,17 @@ struct a38x_main_hdr_v1 {
u8  checksum;  /* 0x1F  */
  };
  
+/*

+ * Header for the optional headers, version 1 (Armada 370/XP/375/38x/39x)
+ */
+struct a38x_opt_hdr_v1 {
+   u8  headertype;
+   u8  headersz_msb;
+   u16 headersz_lsb;
+   u8  data[0];
+};
+#define A38X_OPT_HDR_V1_SECURE_TYPE0x1
+
  struct a38x_boot_mode {
unsigned int id;
const char *name;
@@ -706,6 +719,7 @@ static int check_image_header(void)
  {
u8 checksum;
u32 checksum32, exp_checksum32;
+   u32 offset, size;
const struct a38x_main_hdr_v1 *hdr =
(struct a38x_main_hdr_v1 *)get_load_addr();
const size_t image_size = a38x_header_size(hdr);
@@ -752,6 +766,38 @@ static int check_image_header(void)
printf("Image checksum...OK!\n");
return 0;
  }
+
+#if defined(CONFIG_ARMADA_38X)
+static int a38x_image_is_secure(const struct a38x_main_hdr_v1 *hdr)
+{
+   u32 image_size = a38x_header_size(hdr);
+   struct a38x_opt_hdr_v1 *ohdr;
+   u32 ohdr_size;
+
+   if (hdr->version != 1)
+   return 0;
+
+   if (!hdr->ext)
+   return 0;
+
+   ohdr = (struct a38x_opt_hdr_v1 *)(hdr + 1);
+   do {
+   if (ohdr->headertype == A38X_OPT_HDR_V1_SECURE_TYPE)
+   return 1;
+
+   ohdr_size = (ohdr->headersz_msb << 16) | 
le16_to_cpu(ohdr->headersz_lsb);
+
+   if (!*((u8 *)ohdr + ohdr_size - 4))
+   break;
+
+   ohdr = (struct a38x_opt_hdr_v1 *)((u8 *)ohdr + ohdr_size);
+   if ((u8 *)ohdr >= (u8 *)hdr + image_size)
+   break;
+   } while (1);
+
+   return 0;
+}
+#endif
  #else /* Not ARMADA? */
  static int check_image_header(void)
  {
@@ -760,20 +806,58 @@ static int check_image_header(void)
  }
  #endif
  
+static u64 fuse_read_u64(u32 bank)

+{
+   u32 val[2];
+   int ret;
+
+   ret = fuse_read(bank, 0, &val[0]);
+   if (ret < 0)
+   return -1;
+
+   ret = fuse_read(bank, 1, &val[1]);
+   if (ret < 0)
+   return -1;
+
+   return ((u64)val[1] << 32) | val[0];
+}
+
+#if defined(CONFIG_ARMADA_3700)
+static inline u8 maj3(u8 val)
+{
+   /* return majority vote of 3 bits */
+   return ((val & 0x7) == 3 || (val & 0x7) > 4) ? 1 : 0;
+}
+#endif
+
  static int bubt_check_boot_mode(const struct bubt_dev *dst)
  {
  #if defined(CONFIG_ARMADA_3700) || defined(CONFIG_ARMADA_32BIT)
-   int mode;
+   int mode, secure_mode;
  #if defined(CONFIG_ARMADA_3700)
const struct tim_boot_flash_sign *boot_modes = tim_boot_flash_signs;
const struct common_tim_data *hdr =
(struct common_tim_data *)get_load_addr();
u32 id = hdr->boot_flash_sign;
+   int is_secure = hdr->trusted != 0;
+   u64 otp_secure_bits = fuse_read_u64(1);
+   int otp_secure_boot = ((maj3(otp_secure_bits >> 0) << 0) |
+  (maj3(otp_secure_bits >> 4) << 1)) == 2;
+   unsigned int otp_boot_device = (maj3(otp_secure_bits >> 48) << 0) |
+  (maj3(otp_secure_bits >> 52) << 1) |
+   

Re: [PATCH v2 1/2] cmd: mvebu/bubt: Check for A38x image data checksum

2022-08-16 Thread Stefan Roese

On 09.08.22 21:42, Pali Rohár wrote:

Currently for A38x image is checked only header checksum.
So check also for image data checksum to prevent flashing broken image.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
Changes in v2:
* Compile fix (move code chunk from patch 2/2 to 1/2)
---
  cmd/mvebu/bubt.c | 45 -
  1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 2136af64163c..3b6ffb7ffd1f 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -688,9 +688,24 @@ static uint8_t image_checksum8(const void *start, size_t 
len)
return csum;
  }
  
+static uint32_t image_checksum32(const void *start, size_t len)

+{
+   u32 csum = 0;
+   const u32 *p = start;
+
+   while (len) {
+   csum += *p;
+   ++p;
+   len -= sizeof(u32);
+   }
+
+   return csum;
+}
+
  static int check_image_header(void)
  {
u8 checksum;
+   u32 checksum32, exp_checksum32;
const struct a38x_main_hdr_v1 *hdr =
(struct a38x_main_hdr_v1 *)get_load_addr();
const size_t image_size = a38x_header_size(hdr);
@@ -701,11 +716,39 @@ static int check_image_header(void)
checksum = image_checksum8(hdr, image_size);
checksum -= hdr->checksum;
if (checksum != hdr->checksum) {
-   printf("Error: Bad A38x image checksum. 0x%x != 0x%x\n",
+   printf("Error: Bad A38x image header checksum. 0x%x != 0x%x\n",
   checksum, hdr->checksum);
return -ENOEXEC;
}
  
+	offset = le32_to_cpu(hdr->srcaddr);

+   size = le32_to_cpu(hdr->blocksize);
+
+   if (hdr->blockid == 0x78) { /* SATA id */
+   if (offset < 1) {
+   printf("Error: Bad A38x image srcaddr.\n");
+   return -ENOEXEC;
+   }
+   offset -= 1;
+   offset *= 512;
+   }
+
+   if (hdr->blockid == 0xAE) /* SDIO id */
+   offset *= 512;
+
+   if (offset % 4 != 0 || size < 4 || size % 4 != 0) {
+   printf("Error: Bad A38x image blocksize.\n");
+   return -ENOEXEC;
+   }
+
+   checksum32 = image_checksum32((u8 *)hdr + offset, size - 4);
+   exp_checksum32 = *(u32 *)((u8 *)hdr + offset + size - 4);
+   if (checksum32 != exp_checksum32) {
+   printf("Error: Bad A38x image data checksum. 0x%08x != 
0x%08x\n",
+  checksum32, exp_checksum32);
+   return -ENOEXEC;
+   }
+
printf("Image checksum...OK!\n");
return 0;
  }


Viele Grüße,
Stefan Roese

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


Re: [PATCH 0/3] sam9x60_curiosity PDA detection support

2022-08-16 Thread Eugen.Hristev
On 7/7/22 2:10 PM, Durai Manickam KR wrote:
> This patch series adds the PDA detection support for sam9x60_curiosity rev4
> boards. In rev4, the raspberry-pi display is replaced by PDA display.
> 
> Durai Manickam KR (3):
>configs: sama9x60_curiosity: add onewire and eeprom drivers
>board: sam9x60_curiosity: add pda detect call at init time
>ARM: dts: at91: sam9x60_curiosity: add onewire support
> 
>   arch/arm/dts/at91-sam9x60_curiosity.dts | 17 +
>   .../atmel/sam9x60_curiosity/sam9x60_curiosity.c |  4 
>   configs/sam9x60_curiosity_mmc_defconfig |  4 
>   3 files changed, 25 insertions(+)
> 

Applied series to u-boot-at91/next , thanks !


Re: [PATCH] mmc: atmel_sdhci: re-enable sdhci after SD Card re-insertion

2022-08-16 Thread Eugen.Hristev
On 7/8/22 3:40 PM, Eugen Hristev - M18282 wrote:
> On 6/22/22 4:30 PM, Sergiu Moga wrote:
>> Whenever the SD Card would be removed and then re-inserted while in the
>> U-Boot command line, the `SDBPWR` bit of the `SDMMC_PCR` register would
>> remain unset afterwards. In order for the bit to be set again after
>> re-insertion, register an additional `deferred_probe` method that the
>> DM would then transparently call. This method will call the generic
>> `sdhci_probe` which will, during its execution flow, set this bit to 1.
>>
>> Signed-off-by: Sergiu Moga 
>> Reported-by: Mihai Sain 
>> Reviewed-by: Eugen Hristev 
>> ---
> 
> Hi Peng,
> 
> To take this patch into my tree I would be happy if you had a look or
> reviewed it first.
> 
> Thanks,
> Eugen
> 

Applied to u-boot-at91/next , thanks !



[GIT PULL] please pull fsl-qoriq-2022-8-17

2022-08-16 Thread Peng Fan (OSS)
Hi Tom,

Please pull fsl-qoriq-2022-8-17

CI: https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq/-/pipelines/13155

Enable SPL authentication for ls1021atwr
Fdt fixups for ls1043ardb v7.0 board


Thanks,
Peng.

The following changes since commit 20d4c6052fe5826b3421e86b2f0e76a6c22581a7:

  Merge tag 'efi-2022-10-rc3' of 
https://source.denx.de/u-boot/custodians/u-boot-efi (2022-08-13 07:37:48 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq.git 
tags/fsl-qoriq-2022-8-17

for you to fetch changes up to dfea459f20133c89d666f3778e551b50c7e966f0:

  board: ls1043ardb: fdt fixups for revision v7.0 boards (2022-08-16 17:07:33 
+0800)


Camelia Groza (1):
  board: ls1043ardb: fdt fixups for revision v7.0 boards

Gaurav Jain (1):
  ls1021atwr: caam: Enable Uboot validaion in SPL.

 MAINTAINERS |  1 +
 arch/arm/dts/ls1021a-twr-u-boot.dtsi| 29 
+
 arch/arm/dts/ls1021a-twr.dtsi   |  1 +
 board/freescale/common/fsl_chain_of_trust.c |  6 +-
 board/freescale/common/fsl_validate.c   | 10 +-
 board/freescale/ls1021atwr/ls1021atwr.c | 13 +++--
 board/freescale/ls1043ardb/ls1043ardb.c | 44 
+++-
 configs/ls1043ardb_SECURE_BOOT_defconfig|  1 +
 configs/ls1043ardb_defconfig|  1 +
 configs/ls1043ardb_nand_SECURE_BOOT_defconfig   |  1 +
 configs/ls1043ardb_nand_defconfig   |  1 +
 configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig |  1 +
 configs/ls1043ardb_sdcard_defconfig |  1 +
 configs/ls1043ardb_tfa_SECURE_BOOT_defconfig|  1 +
 configs/ls1043ardb_tfa_defconfig|  1 +
 include/configs/ls1043ardb.h|  5 -
 16 files changed, 107 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm/dts/ls1021a-twr-u-boot.dtsi


[PATCH] xilinx: zynqmp: Fix AES with a user provided key

2022-08-16 Thread Janne Ylalehto
The user provided key address was not flushed in struct aes because of
the flushing location in the function.

Signed-off-by: Janne Ylalehto 
---

 board/xilinx/zynqmp/cmds.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/board/xilinx/zynqmp/cmds.c b/board/xilinx/zynqmp/cmds.c
index 2ab9596248..e20030ecda 100644
--- a/board/xilinx/zynqmp/cmds.c
+++ b/board/xilinx/zynqmp/cmds.c
@@ -142,9 +142,6 @@ static int do_zynqmp_aes(struct cmd_tbl *cmdtp, int flag, 
int argc,
aes->keysrc = hextoul(argv[6], NULL);
aes->dstaddr = hextoul(argv[7], NULL);
 
-   flush_dcache_range((ulong)aes, (ulong)(aes) +
-  roundup(sizeof(struct aes), ARCH_DMA_MINALIGN));
-
if (aes->srcaddr && aes->ivaddr && aes->dstaddr) {
flush_dcache_range(aes->srcaddr,
   (aes->srcaddr +
@@ -169,6 +166,9 @@ static int do_zynqmp_aes(struct cmd_tbl *cmdtp, int flag, 
int argc,
ARCH_DMA_MINALIGN)));
}
 
+   flush_dcache_range((ulong)aes, (ulong)(aes) +
+  roundup(sizeof(struct aes), ARCH_DMA_MINALIGN));
+
ret = xilinx_pm_request(PM_SECURE_AES, upper_32_bits((ulong)aes),
lower_32_bits((ulong)aes), 0, 0, ret_payload);
if (ret || ret_payload[1])
-- 
2.25.1



Re: [PATCH] arm: kirkwood: 88f6281: Detect CONFIG_SYS_TCLK from SAR register

2022-08-16 Thread Michael Walle

Am 2022-08-17 00:39, schrieb Pali Rohár:

On Wednesday 17 August 2022 00:14:20 Pali Rohár wrote:

On Tuesday 16 August 2022 23:34:13 Michael Walle wrote:
> Am 2022-08-16 22:00, schrieb Pali Rohár:
> > Bit 21 in SAR register specifies if TCLK is running at 166 MHz or 200
> > MHz.
> > This information is undocumented in public Marvell Kirkwood Functional
> > Specifications [2], but is available in Linux v3.15 kirkwood code [1].
> >
> > Commit 8ac303d49f89 ("arm: kirkwood: Do not overwrite CONFIG_SYS_TCLK")
> > broke support for Marvell 88F6281 SoCs because it was expected that all
> > those SoCs have TCLK running at 200 MHz as specified in Marvell 88F6281
> > Hardware Specifications [3].
> >
> > Fix broken support for 88F6281 by detecting CONFIG_SYS_TCLK from SAR
> > register, like it was doing Linux v3.15.
> >
> > [1] -
> > 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/mach-kirkwood/common.c?h=v3.15#n542
> > [2] -
> > 
https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
> > [3] -
> > 
https://web.archive.org/web/20120620073511/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
> >
> > Fixes: 8ac303d49f89 ("arm: kirkwood: Do not overwrite CONFIG_SYS_TCLK")
> > Signed-off-by: Pali Rohár 
> > ---
> > Michael, please test this patch, if it fixes your boards.
>
> Thanks, but this doesn't compile:
>
> In file included from lib/time.c:19:
> lib/time.c: In function ‘timer_get_boot_us’:
> ./arch/arm/include/asm/io.h:108:19: error: token "{" is not valid in
> preprocessor expressions
>   108 | #define readl(c) ({ u32 __v = __arch_getl(c); __iormb(); __v; })
>   |   ^
> ./arch/arm/include/asm/arch/kw88f6281.h:18:29: note: in expansion of macro
> ‘readl’
>18 | #define CONFIG_SYS_TCLK   ((readl(CONFIG_SAR_REG) & BIT(21)) ? \
>   | ^
> ./arch/arm/include/asm/arch/config.h:56:32: note: in expansion of macro
> ‘CONFIG_SYS_TCLK’
>56 | #define CONFIG_SYS_TIMER_RATE  CONFIG_SYS_TCLK
>   |^~~
> lib/time.c:50:5: note: in expansion of macro ‘CONFIG_SYS_TIMER_RATE’
>50 | #if CONFIG_SYS_TIMER_RATE == 100
>   | ^
> ./arch/arm/include/asm/io.h:108:19: error: token "{" is not valid in
> preprocessor expressions
>   108 | #define readl(c) ({ u32 __v = __arch_getl(c); __iormb(); __v; })
>   |   ^
> ./arch/arm/include/asm/arch/kw88f6281.h:18:29: note: in expansion of macro
> ‘readl’
>18 | #define CONFIG_SYS_TCLK   ((readl(CONFIG_SAR_REG) & BIT(21)) ? \
>   | ^
> ./arch/arm/include/asm/arch/config.h:56:32: note: in expansion of macro
> ‘CONFIG_SYS_TCLK’
>56 | #define CONFIG_SYS_TIMER_RATE  CONFIG_SYS_TCLK
>   |^~~
> lib/time.c:52:7: note: in expansion of macro ‘CONFIG_SYS_TIMER_RATE’
>52 | #elif CONFIG_SYS_TIMER_RATE > 100
>   |   ^
> make[1]: *** [scripts/Makefile.build:257: lib/time.o] Fehler 1
>
> -michael

Ah :-( And why it works on other Armada mvebu boards? Because of this:

$ git grep CONFIG_SYS_TIMER_RATE arch/arm/mach-mvebu
arch/arm/mach-mvebu/include/mach/config.h:#define 
CONFIG_SYS_TIMER_RATE 2500


I have looked how is this option used and it is unit for
CONFIG_SYS_TIMER_COUNTER option. On all kirkwood and mvebu platforms 
is
that register set to SoC Global Timer 0 which on Armada 38x uses 
either

fixed 25MHz clock or NBCLK clock, together with SoC Global Timer 0
Ratio. When NBCLK then the frequency of that timer register is:
NBCLK / 2 / (2 ^ ratio). Default ratio is 0 (but can be configured up 
to

7). By default fixed 25MHz clock is used.

Hence for mvebu it is OK as U-Boot does not change default values of 
SoC

Global Timer 0.

For kirkwood it looks like that those timers are based on TCLK (page 
283

in Functional Specifications).

How to fix it? I do not know right now. I have just quirk & dirty
solution by moving code from preprocessor to compiler:

diff --git a/lib/time.c b/lib/time.c
index 96074b84af69..f2ffc0498d39 100644
--- a/lib/time.c
+++ b/lib/time.c
@@ -46,13 +46,15 @@ unsigned long notrace timer_read_counter(void)
 ulong timer_get_boot_us(void)
 {
ulong count = timer_read_counter();
-
-#if CONFIG_SYS_TIMER_RATE == 100
-   return count;
-#elif CONFIG_SYS_TIMER_RATE > 100
-   return lldiv(count, CONFIG_SYS_TIMER_RATE / 100);
-#elif defined(CONFIG_SYS_TIMER_RATE)
-   return (unsigned long long)count * 100 / CONFIG_SYS_TIMER_RATE;
+#ifdef CONFIG_SYS_TIMER_RATE
+   const ulong timer_rate = CONFIG_SYS_TIMER_RATE;
+
+   if (timer_rate)

~~
Here needs to be if (timer_rate == 100)


+   return count;
+   else if (timer_rate > 100)
+   return lldiv(count, timer_rate 

Re: [PATCH] arm: kirkwood: 88f6281: Detect CONFIG_SYS_TCLK from SAR register

2022-08-16 Thread Pali Rohár
On Wednesday 17 August 2022 00:14:20 Pali Rohár wrote:
> On Tuesday 16 August 2022 23:34:13 Michael Walle wrote:
> > Am 2022-08-16 22:00, schrieb Pali Rohár:
> > > Bit 21 in SAR register specifies if TCLK is running at 166 MHz or 200
> > > MHz.
> > > This information is undocumented in public Marvell Kirkwood Functional
> > > Specifications [2], but is available in Linux v3.15 kirkwood code [1].
> > > 
> > > Commit 8ac303d49f89 ("arm: kirkwood: Do not overwrite CONFIG_SYS_TCLK")
> > > broke support for Marvell 88F6281 SoCs because it was expected that all
> > > those SoCs have TCLK running at 200 MHz as specified in Marvell 88F6281
> > > Hardware Specifications [3].
> > > 
> > > Fix broken support for 88F6281 by detecting CONFIG_SYS_TCLK from SAR
> > > register, like it was doing Linux v3.15.
> > > 
> > > [1] -
> > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/mach-kirkwood/common.c?h=v3.15#n542
> > > [2] -
> > > https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
> > > [3] -
> > > https://web.archive.org/web/20120620073511/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
> > > 
> > > Fixes: 8ac303d49f89 ("arm: kirkwood: Do not overwrite CONFIG_SYS_TCLK")
> > > Signed-off-by: Pali Rohár 
> > > ---
> > > Michael, please test this patch, if it fixes your boards.
> > 
> > Thanks, but this doesn't compile:
> > 
> > In file included from lib/time.c:19:
> > lib/time.c: In function ‘timer_get_boot_us’:
> > ./arch/arm/include/asm/io.h:108:19: error: token "{" is not valid in
> > preprocessor expressions
> >   108 | #define readl(c) ({ u32 __v = __arch_getl(c); __iormb(); __v; })
> >   |   ^
> > ./arch/arm/include/asm/arch/kw88f6281.h:18:29: note: in expansion of macro
> > ‘readl’
> >18 | #define CONFIG_SYS_TCLK   ((readl(CONFIG_SAR_REG) & BIT(21)) ? \
> >   | ^
> > ./arch/arm/include/asm/arch/config.h:56:32: note: in expansion of macro
> > ‘CONFIG_SYS_TCLK’
> >56 | #define CONFIG_SYS_TIMER_RATE  CONFIG_SYS_TCLK
> >   |^~~
> > lib/time.c:50:5: note: in expansion of macro ‘CONFIG_SYS_TIMER_RATE’
> >50 | #if CONFIG_SYS_TIMER_RATE == 100
> >   | ^
> > ./arch/arm/include/asm/io.h:108:19: error: token "{" is not valid in
> > preprocessor expressions
> >   108 | #define readl(c) ({ u32 __v = __arch_getl(c); __iormb(); __v; })
> >   |   ^
> > ./arch/arm/include/asm/arch/kw88f6281.h:18:29: note: in expansion of macro
> > ‘readl’
> >18 | #define CONFIG_SYS_TCLK   ((readl(CONFIG_SAR_REG) & BIT(21)) ? \
> >   | ^
> > ./arch/arm/include/asm/arch/config.h:56:32: note: in expansion of macro
> > ‘CONFIG_SYS_TCLK’
> >56 | #define CONFIG_SYS_TIMER_RATE  CONFIG_SYS_TCLK
> >   |^~~
> > lib/time.c:52:7: note: in expansion of macro ‘CONFIG_SYS_TIMER_RATE’
> >52 | #elif CONFIG_SYS_TIMER_RATE > 100
> >   |   ^
> > make[1]: *** [scripts/Makefile.build:257: lib/time.o] Fehler 1
> > 
> > -michael
> 
> Ah :-( And why it works on other Armada mvebu boards? Because of this:
> 
> $ git grep CONFIG_SYS_TIMER_RATE arch/arm/mach-mvebu
> arch/arm/mach-mvebu/include/mach/config.h:#define CONFIG_SYS_TIMER_RATE   
>   2500
> 
> I have looked how is this option used and it is unit for
> CONFIG_SYS_TIMER_COUNTER option. On all kirkwood and mvebu platforms is
> that register set to SoC Global Timer 0 which on Armada 38x uses either
> fixed 25MHz clock or NBCLK clock, together with SoC Global Timer 0
> Ratio. When NBCLK then the frequency of that timer register is:
> NBCLK / 2 / (2 ^ ratio). Default ratio is 0 (but can be configured up to
> 7). By default fixed 25MHz clock is used.
> 
> Hence for mvebu it is OK as U-Boot does not change default values of SoC
> Global Timer 0.
> 
> For kirkwood it looks like that those timers are based on TCLK (page 283
> in Functional Specifications).
> 
> How to fix it? I do not know right now. I have just quirk & dirty
> solution by moving code from preprocessor to compiler:
> 
> diff --git a/lib/time.c b/lib/time.c
> index 96074b84af69..f2ffc0498d39 100644
> --- a/lib/time.c
> +++ b/lib/time.c
> @@ -46,13 +46,15 @@ unsigned long notrace timer_read_counter(void)
>  ulong timer_get_boot_us(void)
>  {
>   ulong count = timer_read_counter();
> -
> -#if CONFIG_SYS_TIMER_RATE == 100
> - return count;
> -#elif CONFIG_SYS_TIMER_RATE > 100
> - return lldiv(count, CONFIG_SYS_TIMER_RATE / 100);
> -#elif defined(CONFIG_SYS_TIMER_RATE)
> - return (unsigned long long)count * 100 / CONFIG_SYS_TIMER_RATE;
> +#ifdef CONFIG_SYS_TIMER_RATE
> + const ulong timer_rate = CONFIG_SYS_TIMER_RATE;
> +
> + if (timer_rate)
~~
Here needs 

Re: [PATCH] arm: kirkwood: 88f6281: Detect CONFIG_SYS_TCLK from SAR register

2022-08-16 Thread Pali Rohár
On Tuesday 16 August 2022 23:34:13 Michael Walle wrote:
> Am 2022-08-16 22:00, schrieb Pali Rohár:
> > Bit 21 in SAR register specifies if TCLK is running at 166 MHz or 200
> > MHz.
> > This information is undocumented in public Marvell Kirkwood Functional
> > Specifications [2], but is available in Linux v3.15 kirkwood code [1].
> > 
> > Commit 8ac303d49f89 ("arm: kirkwood: Do not overwrite CONFIG_SYS_TCLK")
> > broke support for Marvell 88F6281 SoCs because it was expected that all
> > those SoCs have TCLK running at 200 MHz as specified in Marvell 88F6281
> > Hardware Specifications [3].
> > 
> > Fix broken support for 88F6281 by detecting CONFIG_SYS_TCLK from SAR
> > register, like it was doing Linux v3.15.
> > 
> > [1] -
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/mach-kirkwood/common.c?h=v3.15#n542
> > [2] -
> > https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
> > [3] -
> > https://web.archive.org/web/20120620073511/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
> > 
> > Fixes: 8ac303d49f89 ("arm: kirkwood: Do not overwrite CONFIG_SYS_TCLK")
> > Signed-off-by: Pali Rohár 
> > ---
> > Michael, please test this patch, if it fixes your boards.
> 
> Thanks, but this doesn't compile:
> 
> In file included from lib/time.c:19:
> lib/time.c: In function ‘timer_get_boot_us’:
> ./arch/arm/include/asm/io.h:108:19: error: token "{" is not valid in
> preprocessor expressions
>   108 | #define readl(c) ({ u32 __v = __arch_getl(c); __iormb(); __v; })
>   |   ^
> ./arch/arm/include/asm/arch/kw88f6281.h:18:29: note: in expansion of macro
> ‘readl’
>18 | #define CONFIG_SYS_TCLK   ((readl(CONFIG_SAR_REG) & BIT(21)) ? \
>   | ^
> ./arch/arm/include/asm/arch/config.h:56:32: note: in expansion of macro
> ‘CONFIG_SYS_TCLK’
>56 | #define CONFIG_SYS_TIMER_RATE  CONFIG_SYS_TCLK
>   |^~~
> lib/time.c:50:5: note: in expansion of macro ‘CONFIG_SYS_TIMER_RATE’
>50 | #if CONFIG_SYS_TIMER_RATE == 100
>   | ^
> ./arch/arm/include/asm/io.h:108:19: error: token "{" is not valid in
> preprocessor expressions
>   108 | #define readl(c) ({ u32 __v = __arch_getl(c); __iormb(); __v; })
>   |   ^
> ./arch/arm/include/asm/arch/kw88f6281.h:18:29: note: in expansion of macro
> ‘readl’
>18 | #define CONFIG_SYS_TCLK   ((readl(CONFIG_SAR_REG) & BIT(21)) ? \
>   | ^
> ./arch/arm/include/asm/arch/config.h:56:32: note: in expansion of macro
> ‘CONFIG_SYS_TCLK’
>56 | #define CONFIG_SYS_TIMER_RATE  CONFIG_SYS_TCLK
>   |^~~
> lib/time.c:52:7: note: in expansion of macro ‘CONFIG_SYS_TIMER_RATE’
>52 | #elif CONFIG_SYS_TIMER_RATE > 100
>   |   ^
> make[1]: *** [scripts/Makefile.build:257: lib/time.o] Fehler 1
> 
> -michael

Ah :-( And why it works on other Armada mvebu boards? Because of this:

$ git grep CONFIG_SYS_TIMER_RATE arch/arm/mach-mvebu
arch/arm/mach-mvebu/include/mach/config.h:#define CONFIG_SYS_TIMER_RATE 
2500

I have looked how is this option used and it is unit for
CONFIG_SYS_TIMER_COUNTER option. On all kirkwood and mvebu platforms is
that register set to SoC Global Timer 0 which on Armada 38x uses either
fixed 25MHz clock or NBCLK clock, together with SoC Global Timer 0
Ratio. When NBCLK then the frequency of that timer register is:
NBCLK / 2 / (2 ^ ratio). Default ratio is 0 (but can be configured up to
7). By default fixed 25MHz clock is used.

Hence for mvebu it is OK as U-Boot does not change default values of SoC
Global Timer 0.

For kirkwood it looks like that those timers are based on TCLK (page 283
in Functional Specifications).

How to fix it? I do not know right now. I have just quirk & dirty
solution by moving code from preprocessor to compiler:

diff --git a/lib/time.c b/lib/time.c
index 96074b84af69..f2ffc0498d39 100644
--- a/lib/time.c
+++ b/lib/time.c
@@ -46,13 +46,15 @@ unsigned long notrace timer_read_counter(void)
 ulong timer_get_boot_us(void)
 {
ulong count = timer_read_counter();
-
-#if CONFIG_SYS_TIMER_RATE == 100
-   return count;
-#elif CONFIG_SYS_TIMER_RATE > 100
-   return lldiv(count, CONFIG_SYS_TIMER_RATE / 100);
-#elif defined(CONFIG_SYS_TIMER_RATE)
-   return (unsigned long long)count * 100 / CONFIG_SYS_TIMER_RATE;
+#ifdef CONFIG_SYS_TIMER_RATE
+   const ulong timer_rate = CONFIG_SYS_TIMER_RATE;
+
+   if (timer_rate)
+   return count;
+   else if (timer_rate > 100)
+   return lldiv(count, timer_rate / 100);
+   else
+   return (unsigned long long)count * 100 / timer_rate;
 #else
/* Assume the counter is in microseconds */
return cou

Re: [PATCH v2 6/6] test: py: fru: add a test for the fru command

2022-08-16 Thread Jae Hyun Yoo

Hi Simon,

On 8/16/2022 1:42 PM, Simon Glass wrote:

Hi Jae,

On Mon, 15 Aug 2022 at 16:58, Jae Hyun Yoo  wrote:


Add a simple test for the 'fru' command.

Signed-off-by: Jae Hyun Yoo 
---
Changes from v1:
  * Newly added in v2. (Heinrich)

  configs/sandbox64_defconfig|  1 +
  configs/sandbox_defconfig  |  1 +
  configs/sandbox_flattree_defconfig |  1 +
  configs/sandbox_noinst_defconfig   |  1 +
  configs/sandbox_spl_defconfig  |  1 +
  configs/sandbox_vpl_defconfig  |  1 +
  test/py/tests/test_fru.py  | 47 ++
  7 files changed, 53 insertions(+)
  create mode 100644 test/py/tests/test_fru.py


Could this be written in C? Also, enabling it in just
sandbox_defconfig should be enough.


Okay. I'll try to write it in C and will touch just sandbox_defconfig
in the next version.

Thanks,
Jae



https://u-boot.readthedocs.io/en/latest/develop/tests_writing.html

Regards,
Simon




diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index 6553568e7684..9059e3c1c91d 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -83,6 +83,7 @@ CONFIG_CMD_CBFS=y
  CONFIG_CMD_CRAMFS=y
  CONFIG_CMD_EXT4_WRITE=y
  CONFIG_CMD_MTDPARTS=y
+CONFIG_CMD_FRU=y
  CONFIG_MAC_PARTITION=y
  CONFIG_AMIGA_PARTITION=y
  CONFIG_OF_CONTROL=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index eba7bcbb483b..293e39706cf2 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -115,6 +115,7 @@ CONFIG_CMD_EXT4_WRITE=y
  CONFIG_CMD_SQUASHFS=y
  CONFIG_CMD_MTDPARTS=y
  CONFIG_CMD_STACKPROTECTOR_TEST=y
+CONFIG_CMD_FRU=y
  CONFIG_MAC_PARTITION=y
  CONFIG_AMIGA_PARTITION=y
  CONFIG_OF_CONTROL=y
diff --git a/configs/sandbox_flattree_defconfig 
b/configs/sandbox_flattree_defconfig
index 6d62feeb08a9..e71379599140 100644
--- a/configs/sandbox_flattree_defconfig
+++ b/configs/sandbox_flattree_defconfig
@@ -66,6 +66,7 @@ CONFIG_CMD_REGULATOR=y
  CONFIG_CMD_TPM=y
  CONFIG_CMD_TPM_TEST=y
  CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FRU=y
  CONFIG_MAC_PARTITION=y
  CONFIG_AMIGA_PARTITION=y
  CONFIG_OF_CONTROL=y
diff --git a/configs/sandbox_noinst_defconfig b/configs/sandbox_noinst_defconfig
index 9ee70c29c1a5..0b7f8bd9b3cc 100644
--- a/configs/sandbox_noinst_defconfig
+++ b/configs/sandbox_noinst_defconfig
@@ -84,6 +84,7 @@ CONFIG_CMD_TPM_TEST=y
  CONFIG_CMD_CBFS=y
  CONFIG_CMD_CRAMFS=y
  CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FRU=y
  CONFIG_MAC_PARTITION=y
  CONFIG_AMIGA_PARTITION=y
  CONFIG_OF_CONTROL=y
diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig
index ec2d26d4436b..05235ec1c493 100644
--- a/configs/sandbox_spl_defconfig
+++ b/configs/sandbox_spl_defconfig
@@ -84,6 +84,7 @@ CONFIG_CMD_TPM_TEST=y
  CONFIG_CMD_CBFS=y
  CONFIG_CMD_CRAMFS=y
  CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FRU=y
  CONFIG_MAC_PARTITION=y
  CONFIG_AMIGA_PARTITION=y
  CONFIG_OF_CONTROL=y
diff --git a/configs/sandbox_vpl_defconfig b/configs/sandbox_vpl_defconfig
index 0d946b4ad779..7d4b808a5b49 100644
--- a/configs/sandbox_vpl_defconfig
+++ b/configs/sandbox_vpl_defconfig
@@ -96,6 +96,7 @@ CONFIG_CMD_TPM_TEST=y
  CONFIG_CMD_CBFS=y
  CONFIG_CMD_CRAMFS=y
  CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FRU=y
  CONFIG_MAC_PARTITION=y
  CONFIG_AMIGA_PARTITION=y
  CONFIG_OF_CONTROL=y
diff --git a/test/py/tests/test_fru.py b/test/py/tests/test_fru.py
new file mode 100644
index ..e5e1d7d00639
--- /dev/null
+++ b/test/py/tests/test_fru.py
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved.
+
+import pytest
+import u_boot_utils
+
+@pytest.mark.buildconfigspec('cmd_fru')
+def test_fru_board(u_boot_console):
+"""Test that fru command generates and captures board FRU information as
+expected."""
+
+ram_base = u_boot_utils.find_ram_base(u_boot_console)
+addr = '0x%x' % ram_base
+expected_response = 'rc:0'
+response = u_boot_console.run_command('fru generate -b ' + addr + ' abcd 
efgh ijkl mnop qrst uvwx; echo rc:$?')
+assert(expected_response in response)
+response = u_boot_console.run_command('fru capture ' + addr + '; echo 
rc:$?')
+assert(expected_response in response)
+response = u_boot_console.run_command('fru display')
+assert('Manufacturer Name: abcd' in response)
+assert('Product Name: efgh' in response)
+assert('Serial Number: ijkl' in response)
+assert('Part Number: mnop' in response)
+assert('File ID: qrst' in response)
+assert('Custom Type/Length: 0xc4' in response)
+
+@pytest.mark.buildconfigspec('cmd_fru')
+def test_fru_product(u_boot_console):
+"""Test that fru command generates and captures product FRU information as
+expected."""
+
+ram_base = u_boot_utils.find_ram_base(u_boot_console)
+addr = '0x%x' % ram_base
+expected_response = 'rc:0'
+response = u_boot_console.run_command('fru generate -p ' + addr + ' abcd 
efgh ijkl mnop qrst uvwx yz01 2345; echo rc:$?')
+   

Re: [PATCH v2 3/6] cmd: fru: fix a sandbox segfault issue

2022-08-16 Thread Jae Hyun Yoo

Hi Simon,

On 8/16/2022 1:42 PM, Simon Glass wrote:

[...]



Reviewed-by: Simon Glass 



Thanks for your review!

[...]


  int fru_display(int verbose);
-int fru_capture(unsigned long addr);
-int fru_generate(unsigned long addr, int argc, char *const argv[]);
+int fru_capture(const void *addr);
+int fru_generate(const void *addr, int argc, char *const argv[]);


Please add proper comments to these here.


Sure. I'll add comments to describe these prototypes in the next spin.

Thanks,
Jae



Re: [PATCH] arm: kirkwood: 88f6281: Detect CONFIG_SYS_TCLK from SAR register

2022-08-16 Thread Michael Walle

Am 2022-08-16 22:00, schrieb Pali Rohár:
Bit 21 in SAR register specifies if TCLK is running at 166 MHz or 200 
MHz.

This information is undocumented in public Marvell Kirkwood Functional
Specifications [2], but is available in Linux v3.15 kirkwood code [1].

Commit 8ac303d49f89 ("arm: kirkwood: Do not overwrite CONFIG_SYS_TCLK")
broke support for Marvell 88F6281 SoCs because it was expected that all
those SoCs have TCLK running at 200 MHz as specified in Marvell 88F6281
Hardware Specifications [3].

Fix broken support for 88F6281 by detecting CONFIG_SYS_TCLK from SAR
register, like it was doing Linux v3.15.

[1] -
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/mach-kirkwood/common.c?h=v3.15#n542
[2] -
https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
[3] -
https://web.archive.org/web/20120620073511/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf

Fixes: 8ac303d49f89 ("arm: kirkwood: Do not overwrite CONFIG_SYS_TCLK")
Signed-off-by: Pali Rohár 
---
Michael, please test this patch, if it fixes your boards.


Thanks, but this doesn't compile:

In file included from lib/time.c:19:
lib/time.c: In function ‘timer_get_boot_us’:
./arch/arm/include/asm/io.h:108:19: error: token "{" is not valid in 
preprocessor expressions

  108 | #define readl(c) ({ u32 __v = __arch_getl(c); __iormb(); __v; })
  |   ^
./arch/arm/include/asm/arch/kw88f6281.h:18:29: note: in expansion of 
macro ‘readl’

   18 | #define CONFIG_SYS_TCLK   ((readl(CONFIG_SAR_REG) & BIT(21)) ? \
  | ^
./arch/arm/include/asm/arch/config.h:56:32: note: in expansion of macro 
‘CONFIG_SYS_TCLK’

   56 | #define CONFIG_SYS_TIMER_RATE  CONFIG_SYS_TCLK
  |^~~
lib/time.c:50:5: note: in expansion of macro ‘CONFIG_SYS_TIMER_RATE’
   50 | #if CONFIG_SYS_TIMER_RATE == 100
  | ^
./arch/arm/include/asm/io.h:108:19: error: token "{" is not valid in 
preprocessor expressions

  108 | #define readl(c) ({ u32 __v = __arch_getl(c); __iormb(); __v; })
  |   ^
./arch/arm/include/asm/arch/kw88f6281.h:18:29: note: in expansion of 
macro ‘readl’

   18 | #define CONFIG_SYS_TCLK   ((readl(CONFIG_SAR_REG) & BIT(21)) ? \
  | ^
./arch/arm/include/asm/arch/config.h:56:32: note: in expansion of macro 
‘CONFIG_SYS_TCLK’

   56 | #define CONFIG_SYS_TIMER_RATE  CONFIG_SYS_TCLK
  |^~~
lib/time.c:52:7: note: in expansion of macro ‘CONFIG_SYS_TIMER_RATE’
   52 | #elif CONFIG_SYS_TIMER_RATE > 100
  |   ^
make[1]: *** [scripts/Makefile.build:257: lib/time.o] Fehler 1

-michael


Re: [PATCH] [RFC] cmd: i2c: fix default address len for DM_I2C

2022-08-16 Thread Simon Glass
Hi Tim,

On Tue, 16 Aug 2022 at 13:50, Tim Harvey  wrote:
>
> On Mon, Aug 15, 2022 at 3:16 PM Simon Glass  wrote:
> >
> > Hi Tim,
> >
> > On Mon, 15 Aug 2022 at 11:48, Tim Harvey  wrote:
> > >
> > > On Sat, Aug 13, 2022 at 7:59 AM Simon Glass  wrote:
> > > >
> > > > Hi Tim,
> > > >
> > > > On Thu, 11 Aug 2022 at 11:57, Tim Harvey  wrote:
> > > > >
> > > > > According to the comment block "The default {addr} parameter is one 
> > > > > byte
> > > > > (.1) which works well for memories and registers with 8 bits of 
> > > > > address
> > > > > space."
> > > > >
> > > > > While this is true for legacy I2C a default length of -1 is being 
> > > > > passed
> > > > > for DM_I2C which results in a usage error.
> > > > >
> > > > > Restore the documented behavior by always using a default alen of 1.
> > > > >
> > > > > Signed-off-by: Tim Harvey 
> > > > >
> > > > > This is an RFC as I'm unclear if we want to restore the legacy usage 
> > > > > or
> > > > > enforce a new usage (in which case the comment block should be 
> > > > > updated)
> > > > > and I'm not clear if this is documented in other places. If the 
> > > > > decision
> > > > > is to enforce a new usage then it is unclear to me how to specifiy the
> > > > > default alen as there is no command for that (i2c alen [len]?).
> > > > > ---
> > > > >  cmd/i2c.c | 10 --
> > > > >  1 file changed, 10 deletions(-)
> > > > >
> > > >
> > > > Can you dig into this a little more on your board? DEFAULT_ADDR_LEN is
> > > > set to -1 so that by default it does not get set by the command, and
> > > > the existing alen is used.
> > > >
> > > > This is necessary for driver model, since the alen can be set by the
> > > > peripheral device and we don't want to overwrite it:
> > > >
> > > > if (!ret && alen != -1)
> > > > ret = i2c_set_chip_offset_len(dev, alen);
> > > >
> > >
> > > Simon,
> > >
> > > Here's some annotated debug prints added where chip_offset is passed/set:
> > > Model: Gateworks Venice GW73xx-0x i.MX8MM Development Kit
> > > DRAM:  1 GiB
> > > i2c_chip_of_to_plat gsc@20 offset_len=1
> > > i2c_chip_of_to_plat pmic@69 offset_len=1
> > > i2c_get_chip i2c@30a2 0x51 offset_len=1
> > > i2c_bind_driver i2c@30a2 offset_len=1
> > > i2c_set_chip_offset_len generic_51 offset_len=1
> > > dm_i2c_read generic_51 offset=0 offset_len=1
> > > i2c_setup_offset 0x51 offset=0 offset_len=1
> > > Core:  209 devices, 27 uclasses, devicetree: separate
> > > ...
> > > u-boot=> i2c dev 0 && i2c md 0x51 0 50
> > > Setting bus to 0
> > > i2c - I2C sub-system
> > >
> > > Usage:
> > > i2c bus [muxtype:muxaddr:muxchannel] - show I2C bus info
> > > ...
> > >
> > > So the chip I noticed this issue with is 0x51 which an atmel,24c02
> > > compatible eeprom which imx8mm-venice-gw700x.dtsi defines 4 of
> > > (i2c1-0x50, i2c1-0x51, i2c1-0x52, i2c1-0x53). You can see above
> > > i2c1-0x51 (i2c1=i2c@30a2) is accessed early as it holds the board
> > > model information and at that point in time it's accessed with alen=1
> > > (which I specify in board/gateworks/venice/eeprom.c:eeprom_read()) but
> > > by the time the 'i2c md 0x51 0 50' comes around
> > > i2c_get_chip_offset_len() returns 0 for this device. The other eeprom
> > > devices on i2c1 are never accessed by a driver so they would never
> > > have a 'default' alen set.
> >
> > OK I see,
> >
> > >
> > > Where is the initial setting of alen supposed to have come?
> >
> > The "u-boot,i2c-offset-len" property in the device tree.
> >
>
> Simon,
>
> I see what happened here. The issue is caused by commit 8f8c04bf1ebbd
> ("i2c: fix stack buffer overflow vulnerability in i2c md command")
> which changed alen from int to uint (yet its still getting set to
> DEFAULT_ADDR_LEN which is -1) thus the 'if (alen > 3)'  now returns
> CMD_RET_USAGE.
>
> I'm not sure what the best fix is at this point - revert all or part
> of 8f8c04bf1ebbd
>
> Nicolas, what is your opinion? To summarize commit 8f8c04bf1ebbd broke
> the ability to pass a -1 default address length to do_i2c_* such that
> something as common as 'i2c md 0x50 0 50' fails with a usage error.

Ah, ok. Well first we should add a test to dm/test/i2c.c to cover they
failure you are seeing.

Yes, revert part of it and then add checks for -ve values?

Regards,
Simon


Re: [PATCH v2 6/6] test: py: fru: add a test for the fru command

2022-08-16 Thread Simon Glass
Hi Jae,

On Mon, 15 Aug 2022 at 16:58, Jae Hyun Yoo  wrote:
>
> Add a simple test for the 'fru' command.
>
> Signed-off-by: Jae Hyun Yoo 
> ---
> Changes from v1:
>  * Newly added in v2. (Heinrich)
>
>  configs/sandbox64_defconfig|  1 +
>  configs/sandbox_defconfig  |  1 +
>  configs/sandbox_flattree_defconfig |  1 +
>  configs/sandbox_noinst_defconfig   |  1 +
>  configs/sandbox_spl_defconfig  |  1 +
>  configs/sandbox_vpl_defconfig  |  1 +
>  test/py/tests/test_fru.py  | 47 ++
>  7 files changed, 53 insertions(+)
>  create mode 100644 test/py/tests/test_fru.py

Could this be written in C? Also, enabling it in just
sandbox_defconfig should be enough.

https://u-boot.readthedocs.io/en/latest/develop/tests_writing.html

Regards,
Simon


>
> diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
> index 6553568e7684..9059e3c1c91d 100644
> --- a/configs/sandbox64_defconfig
> +++ b/configs/sandbox64_defconfig
> @@ -83,6 +83,7 @@ CONFIG_CMD_CBFS=y
>  CONFIG_CMD_CRAMFS=y
>  CONFIG_CMD_EXT4_WRITE=y
>  CONFIG_CMD_MTDPARTS=y
> +CONFIG_CMD_FRU=y
>  CONFIG_MAC_PARTITION=y
>  CONFIG_AMIGA_PARTITION=y
>  CONFIG_OF_CONTROL=y
> diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> index eba7bcbb483b..293e39706cf2 100644
> --- a/configs/sandbox_defconfig
> +++ b/configs/sandbox_defconfig
> @@ -115,6 +115,7 @@ CONFIG_CMD_EXT4_WRITE=y
>  CONFIG_CMD_SQUASHFS=y
>  CONFIG_CMD_MTDPARTS=y
>  CONFIG_CMD_STACKPROTECTOR_TEST=y
> +CONFIG_CMD_FRU=y
>  CONFIG_MAC_PARTITION=y
>  CONFIG_AMIGA_PARTITION=y
>  CONFIG_OF_CONTROL=y
> diff --git a/configs/sandbox_flattree_defconfig 
> b/configs/sandbox_flattree_defconfig
> index 6d62feeb08a9..e71379599140 100644
> --- a/configs/sandbox_flattree_defconfig
> +++ b/configs/sandbox_flattree_defconfig
> @@ -66,6 +66,7 @@ CONFIG_CMD_REGULATOR=y
>  CONFIG_CMD_TPM=y
>  CONFIG_CMD_TPM_TEST=y
>  CONFIG_CMD_EXT4_WRITE=y
> +CONFIG_CMD_FRU=y
>  CONFIG_MAC_PARTITION=y
>  CONFIG_AMIGA_PARTITION=y
>  CONFIG_OF_CONTROL=y
> diff --git a/configs/sandbox_noinst_defconfig 
> b/configs/sandbox_noinst_defconfig
> index 9ee70c29c1a5..0b7f8bd9b3cc 100644
> --- a/configs/sandbox_noinst_defconfig
> +++ b/configs/sandbox_noinst_defconfig
> @@ -84,6 +84,7 @@ CONFIG_CMD_TPM_TEST=y
>  CONFIG_CMD_CBFS=y
>  CONFIG_CMD_CRAMFS=y
>  CONFIG_CMD_EXT4_WRITE=y
> +CONFIG_CMD_FRU=y
>  CONFIG_MAC_PARTITION=y
>  CONFIG_AMIGA_PARTITION=y
>  CONFIG_OF_CONTROL=y
> diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig
> index ec2d26d4436b..05235ec1c493 100644
> --- a/configs/sandbox_spl_defconfig
> +++ b/configs/sandbox_spl_defconfig
> @@ -84,6 +84,7 @@ CONFIG_CMD_TPM_TEST=y
>  CONFIG_CMD_CBFS=y
>  CONFIG_CMD_CRAMFS=y
>  CONFIG_CMD_EXT4_WRITE=y
> +CONFIG_CMD_FRU=y
>  CONFIG_MAC_PARTITION=y
>  CONFIG_AMIGA_PARTITION=y
>  CONFIG_OF_CONTROL=y
> diff --git a/configs/sandbox_vpl_defconfig b/configs/sandbox_vpl_defconfig
> index 0d946b4ad779..7d4b808a5b49 100644
> --- a/configs/sandbox_vpl_defconfig
> +++ b/configs/sandbox_vpl_defconfig
> @@ -96,6 +96,7 @@ CONFIG_CMD_TPM_TEST=y
>  CONFIG_CMD_CBFS=y
>  CONFIG_CMD_CRAMFS=y
>  CONFIG_CMD_EXT4_WRITE=y
> +CONFIG_CMD_FRU=y
>  CONFIG_MAC_PARTITION=y
>  CONFIG_AMIGA_PARTITION=y
>  CONFIG_OF_CONTROL=y
> diff --git a/test/py/tests/test_fru.py b/test/py/tests/test_fru.py
> new file mode 100644
> index ..e5e1d7d00639
> --- /dev/null
> +++ b/test/py/tests/test_fru.py
> @@ -0,0 +1,47 @@
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved.
> +
> +import pytest
> +import u_boot_utils
> +
> +@pytest.mark.buildconfigspec('cmd_fru')
> +def test_fru_board(u_boot_console):
> +"""Test that fru command generates and captures board FRU information as
> +expected."""
> +
> +ram_base = u_boot_utils.find_ram_base(u_boot_console)
> +addr = '0x%x' % ram_base
> +expected_response = 'rc:0'
> +response = u_boot_console.run_command('fru generate -b ' + addr + ' abcd 
> efgh ijkl mnop qrst uvwx; echo rc:$?')
> +assert(expected_response in response)
> +response = u_boot_console.run_command('fru capture ' + addr + '; echo 
> rc:$?')
> +assert(expected_response in response)
> +response = u_boot_console.run_command('fru display')
> +assert('Manufacturer Name: abcd' in response)
> +assert('Product Name: efgh' in response)
> +assert('Serial Number: ijkl' in response)
> +assert('Part Number: mnop' in response)
> +assert('File ID: qrst' in response)
> +assert('Custom Type/Length: 0xc4' in response)
> +
> +@pytest.mark.buildconfigspec('cmd_fru')
> +def test_fru_product(u_boot_console):
> +"""Test that fru command generates and captures product FRU information 
> as
> +expected."""
> +
> +ram_base = u_boot_utils.find_ram_base(u_boot_console)
> +addr = '0x%x' % ram_base
> +expected_response = 'rc:0'
> +response = u_boot_console.run_command('fru generate -p ' + addr + ' 

Re: [PATCH v4 03/13] binman: Disable compressed data header

2022-08-16 Thread Simon Glass
Hi Stefan,

On Tue, 16 Aug 2022 at 06:03, Stefan Herbrechtsmeier
 wrote:
>
> Hi Simon,
>
> Am 16.08.2022 um 13:48 schrieb Simon Glass:
> > Hi Stefan,
> >
> > On Tue, 16 Aug 2022 at 02:42, Stefan Herbrechtsmeier
> >  wrote:
> >>
> >> From: Stefan Herbrechtsmeier 
> >>
> >> Disable the compressed data header of the utilities to compress and
> >> decompress data. The header is uncommon, not supported by U-Boot and
> >> incompatible with external compressed artifacts.
> >>
> >> The header was introduced as part of commit eb0f4a4cb402 ("binman:
> >> Support replacing data in a cbfs") to allow device tree entries to be
> >> larger than the compressed contents.
> >>
> >> Signed-off-by: Stefan Herbrechtsmeier 
> >> 
> >>
> >> ---
> >>
> >> (no changes since v3)
> >>
> >> Changes in v3:
> >> - Added
> >>
> >>   tools/binman/entry.py |  2 +-
> >>   tools/binman/etype/section.py |  3 ++-
> >>   tools/binman/ftest.py | 18 +++---
> >>   3 files changed, 14 insertions(+), 9 deletions(-)
> >
> > This seems strange to me.
> >
> > I would expect this patch to make every call set with_header to False,
> > then the next patch remove the parameters. That would allow later
> > bisecting to see where a problem occurs.
> >
> > But at present this patch and the next seem to be mixed together.
>
> I skipped the following calls because it doesn't matter:
> comp_util.compress(b'',  'invalid')
> comp_util.decompress(b'1234', 'invalid')

I still think it is worth it, because the default is True.

>
> Do I miss a call?

Everything should pass False in this patch I think.

>
> The cbfs_util.py file doesn't use the header.
OK

Regards,
SImon


Re: [RESEND PATCH v2 6/6] net: fm: Add support for FIT firmware

2022-08-16 Thread Simon Glass
On Tue, 16 Aug 2022 at 09:16, Sean Anderson  wrote:
>
> Fman microcode is executable code (AFAICT) loaded into a
> coprocessor. As such, if verified boot is enabled, it must be verified
> like other executable code. However, this is not currently done.
>
> This commit adds verified boot functionality by encapsulating the
> microcode in a FIT, which can then be signed/verified as normal. By
> default we allow fallback to unencapsulated firmware, but if
> CONFIG_FIT_SIGNATURE is enabled, then we make it mandatory. Because
> existing Layerscape do not use this config (instead enabling
> CONFIG_CHAIN_OF_TRUST), this should not break any existing boards.
>
> An example (mildly-abbreviated) its is provided below:
>
> / {
> #address-cells = <1>;
>
> images {
> firmware {
> data = /incbin/(/path/to/firmware);
> type = "firmware";
> arch = "arm64";
> compression = "none";
> signature {
> algo = "sha256,rsa2048";
> key-name-hint = "your key name";
> };
> };
> };
>
> configurations {
> default = "conf";
> conf {
> description = "Load FMAN microcode";
> fman = "firmware";
> };
> };
> };
>
> Signed-off-by: Sean Anderson 
> ---
>
> (no changes since v1)
>
>  drivers/net/fm/fm.c | 18 ++
>  1 file changed, 18 insertions(+)

Reviewed-by: Simon Glass 


Re: [PATCH v2 3/6] cmd: fru: fix a sandbox segfault issue

2022-08-16 Thread Simon Glass
Hi Jae,

On Mon, 15 Aug 2022 at 16:58, Jae Hyun Yoo  wrote:
>
> This command doesn't work with sandbox because direct memory access
> causes a segfault error. Fix it up using map_sysmem().
>
> Signed-off-by: Jae Hyun Yoo 
> ---
> Changes from v1:
>  * Newly added in v2.
>
>  board/xilinx/common/board.c |  2 +-
>  cmd/fru.c   | 20 +---
>  include/fru.h   |  4 ++--
>  lib/fru_ops.c   | 17 -
>  4 files changed, 28 insertions(+), 15 deletions(-)

Reviewed-by: Simon Glass 

>
> diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
> index e58b11d7f757..3292083c5250 100644
> --- a/board/xilinx/common/board.c
> +++ b/board/xilinx/common/board.c
> @@ -241,7 +241,7 @@ static int xilinx_read_eeprom_fru(struct udevice *dev, 
> char *name,
> goto end;
> }
>
> -   fru_capture((unsigned long)fru_content);
> +   fru_capture(fru_content);
> if (gd->flags & GD_FLG_RELOC || (_DEBUG && 
> CONFIG_IS_ENABLED(DTB_RESELECT))) {
> printf("Xilinx I2C FRU format at %s:\n", name);
> ret = fru_display(0);
> diff --git a/cmd/fru.c b/cmd/fru.c
> index 2ec5012af5ac..11466339da6a 100644
> --- a/cmd/fru.c
> +++ b/cmd/fru.c
> @@ -9,12 +9,15 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  static int do_fru_capture(struct cmd_tbl *cmdtp, int flag, int argc,
>   char *const argv[])
>  {
> unsigned long addr;
> +   const void *buf;
> char *endp;
> +   int ret;
>
> if (argc < cmdtp->maxargs)
> return CMD_RET_USAGE;
> @@ -23,7 +26,11 @@ static int do_fru_capture(struct cmd_tbl *cmdtp, int flag, 
> int argc,
> if (*argv[1] == 0 || *endp != 0)
> return -1;
>
> -   return fru_capture(addr);
> +   buf = map_sysmem(addr, 0);
> +   ret = fru_capture(buf);
> +   unmap_sysmem(buf);
> +
> +   return ret;
>  }
>
>  static int do_fru_display(struct cmd_tbl *cmdtp, int flag, int argc,
> @@ -36,14 +43,21 @@ static int do_fru_display(struct cmd_tbl *cmdtp, int 
> flag, int argc,
>  static int do_fru_generate(struct cmd_tbl *cmdtp, int flag, int argc,
>char *const argv[])
>  {
> +   int (*fru_generate)(const void *addr, int argc, char *const argv[]);
> unsigned long addr;
> +   const void *buf;
> +   int ret;
>
> if (argc < cmdtp->maxargs)
> return CMD_RET_USAGE;
>
> -   addr = hextoul(argv[2], NULL);
> +   addr = hextoul(argv[3], NULL);
> +
> +   buf = map_sysmem(addr, 0);
> +   ret = fru_generate(buf, argc - 3, argv + 3);
> +   unmap_sysmem(buf);
>
> -   return fru_generate(addr, argc - 3, argv + 3);
> +   return ret;
>  }
>
>  static struct cmd_tbl cmd_fru_sub[] = {
> diff --git a/include/fru.h b/include/fru.h
> index 41655864dbf5..b158b80b5866 100644
> --- a/include/fru.h
> +++ b/include/fru.h
> @@ -107,8 +107,8 @@ struct fru_table {
>  #define FRU_TYPELEN_TYPE_ASCII83
>
>  int fru_display(int verbose);
> -int fru_capture(unsigned long addr);
> -int fru_generate(unsigned long addr, int argc, char *const argv[]);
> +int fru_capture(const void *addr);
> +int fru_generate(const void *addr, int argc, char *const argv[]);

Please add proper comments to these here.

>  u8 fru_checksum(u8 *addr, u8 len);
>  int fru_check_type_len(u8 type_len, u8 language, u8 *type);
>  const struct fru_table *fru_get_fru_data(void);
> diff --git a/lib/fru_ops.c b/lib/fru_ops.c
> index c0360f219c37..6ed1388b2fc8 100644
> --- a/lib/fru_ops.c
> +++ b/lib/fru_ops.c
> @@ -91,7 +91,7 @@ static u8 fru_gen_type_len(u8 *addr, char *name)
> return 1 + len;
>  }
>
> -int fru_generate(unsigned long addr, int argc, char *const argv[])
> +int fru_generate(const void *addr, int argc, char *const argv[])
>  {
> struct fru_common_hdr *header = (struct fru_common_hdr *)addr;
> struct fru_board_info_header *board_info;
> @@ -155,8 +155,8 @@ int fru_generate(unsigned long addr, int argc, char 
> *const argv[])
>
> debug("checksum %x(addr %x)\n", *member, len);
>
> -   env_set_hex("fru_addr", addr);
> -   env_set_hex("filesize", (unsigned long)member - addr + 1);
> +   env_set_hex("fru_addr", (ulong)addr);
> +   env_set_hex("filesize", (ulong)member - (ulong)addr + 1);
>
> return 0;
>  }
> @@ -171,7 +171,7 @@ static void fru_delete_custom_fields(struct list_head 
> *custom_fields)
> }
>  }
>
> -static int fru_append_custom_info(unsigned long addr,
> +static int fru_append_custom_info(const void *addr,
>   struct list_head *custom_fields)
>  {
> struct fru_custom_info *info = (struct fru_custom_info *)addr;
> @@ -190,7 +190,7 @@ static int fru_append_custom_info(unsigned long addr,
> return 0;
>  }
>
> -static int fru_parse_board(unsigned long addr)
> +static int fru_parse_board(const void *add

Re: [RESEND PATCH v2 2/6] image: fit: Add some helpers for getting data

2022-08-16 Thread Simon Glass
On Tue, 16 Aug 2022 at 09:16, Sean Anderson  wrote:
>
> Several different firmware users have repetitive code to extract the
> firmware data from a FIT. Add some helper functions to reduce the amount
> of repetition. fit_conf_get_prop_node (eventually) calls
> fdt_check_node_offset_, so we can avoid an explicit if. In general, this
> version avoids printing on error because the callers are typically
> library functions, and because the FIT code generally has (debug)
> prints of its own. One difference in these helpers is that they use
> fit_image_get_data_and_size instead of fit_image_get_data, as the former
> handles external data correctly.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v2:
> - Document helpers
>
>  boot/image-fit.c | 37 +
>  include/image.h  | 70 
>  2 files changed, 107 insertions(+)
>

Reviewed-by: Simon Glass 


Re: [RESEND PATCH v2 5/6] net: Convert fit verification to use fit_get_data_*

2022-08-16 Thread Simon Glass
On Tue, 16 Aug 2022 at 09:16, Sean Anderson  wrote:
>
> Several ethernet drivers load firmware from FIT images. Convert them to
> use the fit_get_data helpers.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v2:
> - New
>
>  drivers/net/fsl-mc/mc.c| 30 +++---
>  drivers/net/pfe_eth/pfe_firmware.c | 40 +-
>  2 files changed, 4 insertions(+), 66 deletions(-)

Reviewed-by: Simon Glass 


Re: [RESEND PATCH v2 4/6] cmd: fpga: Convert to use fit_get_data_node

2022-08-16 Thread Simon Glass
On Tue, 16 Aug 2022 at 09:16, Sean Anderson  wrote:
>
> This converts the FIT loading process of the fpga command to use

s/This converts/Convert/

> fit_get_data_node.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v2:
> - New
>
>  cmd/fpga.c | 24 ++--
>  1 file changed, 6 insertions(+), 18 deletions(-)

Reviewed-by: Simon Glass 


>
> diff --git a/cmd/fpga.c b/cmd/fpga.c
> index c4651dd403e..9cf7651d8c5 100644
> --- a/cmd/fpga.c
> +++ b/cmd/fpga.c
> @@ -322,7 +322,7 @@ static int do_fpga_loadmk(struct cmd_tbl *cmdtp, int 
> flag, int argc,
> case IMAGE_FORMAT_FIT:
> {
> const void *fit_hdr = (const void *)fpga_data;
> -   int noffset;
> +   int err;
> const void *fit_data;
>
> if (!fit_uname) {
> @@ -335,23 +335,11 @@ static int do_fpga_loadmk(struct cmd_tbl *cmdtp, int 
> flag, int argc,
> return CMD_RET_FAILURE;
> }
>
> -   /* get fpga component image node offset */
> -   noffset = fit_image_get_node(fit_hdr, fit_uname);
> -   if (noffset < 0) {
> -   printf("Can't find '%s' FIT subimage\n", fit_uname);
> -   return CMD_RET_FAILURE;
> -   }
> -
> -   /* verify integrity */
> -   if (!fit_image_verify(fit_hdr, noffset)) {
> -   puts("Bad Data Hash\n");
> -   return CMD_RET_FAILURE;
> -   }
> -
> -   /* get fpga subimage/external data address and length */
> -   if (fit_image_get_data_and_size(fit_hdr, noffset,
> -  &fit_data, &data_size)) {
> -   puts("Fpga subimage data not found\n");
> +   err = fit_get_data_node(fit_hdr, fit_uname, &fit_data,
> +   &data_size);
> +   if (err) {
> +   printf("Could not load '%s' subimage (err %d)\n",
> +  fit_uname, err);
> return CMD_RET_FAILURE;
> }
>
> --
> 2.35.1.1320.gc452695387.dirty
>


Re: [PATCH 5/5] arm: kirkwood: Do not overwrite CONFIG_SYS_TCLK

2022-08-16 Thread Michael Walle

Am 2022-08-16 21:38, schrieb Pali Rohár:

On Tuesday 16 August 2022 20:17:08 Pali Rohár wrote:

Hello!

On Tuesday 16 August 2022 11:37:48 Michael Walle wrote:
> Hi!
>
> > On Sunday 01 August 2021 20:07:16 Chris Packham wrote:
> > > On Sun, Aug 1, 2021 at 12:23 AM Pali Rohár  wrote:
> > > >
> > > > Config option CONFIG_SYS_TCLK is set by kw88f6281.h and kw88f6192.h 
files
> > > > to correct SOC/platform value. So do not overwrite it in board config
> > > > include files.
> > > >
> > > > Kirkwood 88F6180 and 88F6192 uses 166 MHz TCLK and Kirkwood 88F6281 uses
> > > > 200 MHz TCLK.
> > > >
> > >
> > > It's been a while since I worked with kirkwood but I thought that
> > > there was hardware strapping for the TCLK.
> >
> > Interesting... Because I took above information from Kirkwood hardware 
specifications...
> >
> > 88F6180: 
https://web.archive.org/web/20130730091654/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf
> > 88F6192: 
https://web.archive.org/web/20121021182835/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf
> > 88F6281: 
https://web.archive.org/web/20120620073511/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
> >
> > And there are specified fixed TCLK values.
>
> Nope, this breaks my lsxl (specifically the LSCHLv2) board. The TCLK is
> 166MHz there.

Ou, sorry for that.

> > > If I understand correctly
> > > the defines in kw88f6281.h/kw88f6192.h were sensible defaults but
> > > boards were able to override it to reflect the hardware configuration.
> >
> > Anyway, I think that this patch should not cause issue as it is changing
> > only two board config files and removing redefinition of CONFIG_SYS_TCLK
> > macro which is set to the same value as in kw88f61**.h files.
>
> At least for the lsxl and the NET2BIG_V2 this is not correct. Both have
> the 88F6281 and both use have a 166MHz TCLK clock.

Interesting... because this contradicts publicly available
documentation. Maybe in NDA doc is some more details?

> Anyway, I'm reverting this patch. The only open question is, should I
> convert the TCLK to a Kconfig option?

In this case it would be better to detect TCLK from some SAR register,
like it is already implemented for other Armada SoCs.

Just by a chance, do you have some "better" 88F6281 documentation? If
there is some TCLK information or SAR register description. In 
publicly

available FS_88F6180_9x_6281_OpenSource.pdf there is 0x10030 Sample at
Reset Register, but nothing TCLK related.

At least BootROM has to detect TCLK because UART clock is derived from
TCLK and BootROM supports UART booting via 115200 baudrate. In case 
you

can provide me 88F6281 BootROM dump from your board, I can try to find
code which configures UART and detect TCLK. I have already did it for
88F6820 (A385) to verify that U-Boot code detects TCLK in the same way
as BootROM.


Meanwhile I have found following email thread:
https://lore.kernel.org/linux-arm-kernel/20121020113800.gc21...@lunn.ch/t/#u

Where are more 6281 boards with 166 MHz TCLK and there is interesting 
output:

$ dmesg | grep -i tclk
[5.851008] Kirkwood: MV88F6281-A0, TCLK=2

Which means that old kernel version had TCLK detection code. I grepped
git linux history and I successfully found it:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/mach-kirkwood/common.c?h=v3.15#n542

#define  SAMPLE_AT_RESET   (DEV_BUS_VIRT_BASE + 0x0030)

static int __init kirkwood_find_tclk(void)
{
u32 dev, rev;

kirkwood_pcie_id(&dev, &rev);

if (dev == MV88F6281_DEV_ID || dev == MV88F6282_DEV_ID)
if (((readl(SAMPLE_AT_RESET) >> 21) & 1) == 0)
return 2;

return 16667;
}

So for TCLK detection is used BIT 21 of already mentioned 0x10030 
Sample

at Reset Register.


Seems like you beat me, while I was typing my former mail ;)

-michael


Re: [PATCH 5/5] arm: kirkwood: Do not overwrite CONFIG_SYS_TCLK

2022-08-16 Thread Michael Walle

Am 2022-08-16 20:17, schrieb Pali Rohár:

> > If I understand correctly
> > the defines in kw88f6281.h/kw88f6192.h were sensible defaults but
> > boards were able to override it to reflect the hardware configuration.
>
> Anyway, I think that this patch should not cause issue as it is changing
> only two board config files and removing redefinition of CONFIG_SYS_TCLK
> macro which is set to the same value as in kw88f61**.h files.

At least for the lsxl and the NET2BIG_V2 this is not correct. Both 
have

the 88F6281 and both use have a 166MHz TCLK clock.


Interesting... because this contradicts publicly available
documentation. Maybe in NDA doc is some more details?


No, the board support was entirely done by reverse engineering the
original bootloader, back in 2012..


Anyway, I'm reverting this patch. The only open question is, should I
convert the TCLK to a Kconfig option?


In this case it would be better to detect TCLK from some SAR register,
like it is already implemented for other Armada SoCs.


Maybe a bit of a background: The LS-XHL and the LS-CHLv2 share the same
PCB, labeled LSXL (thus the board name). the LS-CHLv2 being the 
low-budget

version, i.e. only 64MiB of memory and a slower CPU clock. The LS-XHL
has 256MiB memory.

I have both boards and I've dumped the SAR:

On the LS-XHL (TCLK 200MHz):
# busybox devmem 0xf1010030 32
0x0093CE96

On the LS-CHLv2 (TCLK 166MHz):
# busybox devmem 0xf1010030 32
0x00B2CA4C


md f104 1

f104: 628111ab


Just by a chance, do you have some "better" 88F6281 documentation? If
there is some TCLK information or SAR register description. In publicly
available FS_88F6180_9x_6281_OpenSource.pdf there is 0x10030 Sample at
Reset Register, but nothing TCLK related.


This made me look closer, and linux is reporting:
[0.17] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps 
every 21474836475ns

and on the other board:
[0.15] sched_clock: 32 bits at 166MHz, resolution 6ns, wraps 
every 12884901885ns


I've digged into it and the kirkwood-core-clock has more information:
https://elixir.bootlin.com/linux/v5.19.1/source/drivers/clk/mvebu/kirkwood.c#L59

I'll take a look at how this could then be determined at runtime.


At least BootROM has to detect TCLK because UART clock is derived from
TCLK and BootROM supports UART booting via 115200 baudrate. In case you
can provide me 88F6281 BootROM dump from your board, I can try to find
code which configures UART and detect TCLK. I have already did it for
88F6820 (A385) to verify that U-Boot code detects TCLK in the same way
as BootROM.


If you still need the bootrom and it is readable in u-boot, I can 
provide

you the dump.

-michael


Re: [PATCH 5/5] arm: kirkwood: Do not overwrite CONFIG_SYS_TCLK

2022-08-16 Thread Pali Rohár
On Tuesday 16 August 2022 21:38:51 Pali Rohár wrote:
> Meanwhile I have found following email thread:
> https://lore.kernel.org/linux-arm-kernel/20121020113800.gc21...@lunn.ch/t/#u
> 
> Where are more 6281 boards with 166 MHz TCLK and there is interesting output:
> $ dmesg | grep -i tclk
> [5.851008] Kirkwood: MV88F6281-A0, TCLK=2
> 
> Which means that old kernel version had TCLK detection code. I grepped
> git linux history and I successfully found it:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/mach-kirkwood/common.c?h=v3.15#n542
> 
> #define  SAMPLE_AT_RESET   (DEV_BUS_VIRT_BASE + 0x0030)
> 
> static int __init kirkwood_find_tclk(void)
> {
>   u32 dev, rev;
> 
>   kirkwood_pcie_id(&dev, &rev);
> 
>   if (dev == MV88F6281_DEV_ID || dev == MV88F6282_DEV_ID)
>   if (((readl(SAMPLE_AT_RESET) >> 21) & 1) == 0)
>   return 2;
> 
>   return 16667;
> }
> 
> So for TCLK detection is used BIT 21 of already mentioned 0x10030 Sample
> at Reset Register.
> 
> I'm going to prepare a patch which will fix this issue for 88F6281 SoCs.

Done! Please test it!
https://patchwork.ozlabs.org/project/uboot/patch/20220816200016.18288-1-p...@kernel.org/


[PATCH] arm: kirkwood: 88f6281: Detect CONFIG_SYS_TCLK from SAR register

2022-08-16 Thread Pali Rohár
Bit 21 in SAR register specifies if TCLK is running at 166 MHz or 200 MHz.
This information is undocumented in public Marvell Kirkwood Functional
Specifications [2], but is available in Linux v3.15 kirkwood code [1].

Commit 8ac303d49f89 ("arm: kirkwood: Do not overwrite CONFIG_SYS_TCLK")
broke support for Marvell 88F6281 SoCs because it was expected that all
those SoCs have TCLK running at 200 MHz as specified in Marvell 88F6281
Hardware Specifications [3].

Fix broken support for 88F6281 by detecting CONFIG_SYS_TCLK from SAR
register, like it was doing Linux v3.15.

[1] - 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/mach-kirkwood/common.c?h=v3.15#n542
[2] - 
https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
[3] - 
https://web.archive.org/web/20120620073511/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf

Fixes: 8ac303d49f89 ("arm: kirkwood: Do not overwrite CONFIG_SYS_TCLK")
Signed-off-by: Pali Rohár 
---
Michael, please test this patch, if it fixes your boards.
---
 arch/arm/mach-kirkwood/include/mach/kw88f6281.h | 3 ++-
 arch/arm/mach-kirkwood/include/mach/soc.h   | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-kirkwood/include/mach/kw88f6281.h 
b/arch/arm/mach-kirkwood/include/mach/kw88f6281.h
index 87406081cf54..f86cd0bb6013 100644
--- a/arch/arm/mach-kirkwood/include/mach/kw88f6281.h
+++ b/arch/arm/mach-kirkwood/include/mach/kw88f6281.h
@@ -15,6 +15,7 @@
 #define KW_REGS_PHY_BASE   KW88F6281_REGS_PHYS_BASE
 
 /* TCLK Core Clock definition */
-#define CONFIG_SYS_TCLK2 /* 200MHz */
+#define CONFIG_SYS_TCLK((readl(CONFIG_SAR_REG) & 
BIT(21)) ? \
+   16667 : 2)
 
 #endif /* _ASM_ARCH_KW88F6281_H */
diff --git a/arch/arm/mach-kirkwood/include/mach/soc.h 
b/arch/arm/mach-kirkwood/include/mach/soc.h
index 1d7f2828cd38..5f545c6f4349 100644
--- a/arch/arm/mach-kirkwood/include/mach/soc.h
+++ b/arch/arm/mach-kirkwood/include/mach/soc.h
@@ -62,6 +62,8 @@
 #define MVCPU_WIN_ENABLE   KWCPU_WIN_ENABLE
 #define MVCPU_WIN_DISABLE  KWCPU_WIN_DISABLE
 
+#define CONFIG_SAR_REG (KW_MPP_BASE + 0x0030)
+
 #if defined (CONFIG_KW88F6281)
 #include 
 #elif defined (CONFIG_KW88F6192)
-- 
2.20.1



Re: [PATCH] [RFC] cmd: i2c: fix default address len for DM_I2C

2022-08-16 Thread Tim Harvey
On Mon, Aug 15, 2022 at 3:16 PM Simon Glass  wrote:
>
> Hi Tim,
>
> On Mon, 15 Aug 2022 at 11:48, Tim Harvey  wrote:
> >
> > On Sat, Aug 13, 2022 at 7:59 AM Simon Glass  wrote:
> > >
> > > Hi Tim,
> > >
> > > On Thu, 11 Aug 2022 at 11:57, Tim Harvey  wrote:
> > > >
> > > > According to the comment block "The default {addr} parameter is one byte
> > > > (.1) which works well for memories and registers with 8 bits of address
> > > > space."
> > > >
> > > > While this is true for legacy I2C a default length of -1 is being passed
> > > > for DM_I2C which results in a usage error.
> > > >
> > > > Restore the documented behavior by always using a default alen of 1.
> > > >
> > > > Signed-off-by: Tim Harvey 
> > > >
> > > > This is an RFC as I'm unclear if we want to restore the legacy usage or
> > > > enforce a new usage (in which case the comment block should be updated)
> > > > and I'm not clear if this is documented in other places. If the decision
> > > > is to enforce a new usage then it is unclear to me how to specifiy the
> > > > default alen as there is no command for that (i2c alen [len]?).
> > > > ---
> > > >  cmd/i2c.c | 10 --
> > > >  1 file changed, 10 deletions(-)
> > > >
> > >
> > > Can you dig into this a little more on your board? DEFAULT_ADDR_LEN is
> > > set to -1 so that by default it does not get set by the command, and
> > > the existing alen is used.
> > >
> > > This is necessary for driver model, since the alen can be set by the
> > > peripheral device and we don't want to overwrite it:
> > >
> > > if (!ret && alen != -1)
> > > ret = i2c_set_chip_offset_len(dev, alen);
> > >
> >
> > Simon,
> >
> > Here's some annotated debug prints added where chip_offset is passed/set:
> > Model: Gateworks Venice GW73xx-0x i.MX8MM Development Kit
> > DRAM:  1 GiB
> > i2c_chip_of_to_plat gsc@20 offset_len=1
> > i2c_chip_of_to_plat pmic@69 offset_len=1
> > i2c_get_chip i2c@30a2 0x51 offset_len=1
> > i2c_bind_driver i2c@30a2 offset_len=1
> > i2c_set_chip_offset_len generic_51 offset_len=1
> > dm_i2c_read generic_51 offset=0 offset_len=1
> > i2c_setup_offset 0x51 offset=0 offset_len=1
> > Core:  209 devices, 27 uclasses, devicetree: separate
> > ...
> > u-boot=> i2c dev 0 && i2c md 0x51 0 50
> > Setting bus to 0
> > i2c - I2C sub-system
> >
> > Usage:
> > i2c bus [muxtype:muxaddr:muxchannel] - show I2C bus info
> > ...
> >
> > So the chip I noticed this issue with is 0x51 which an atmel,24c02
> > compatible eeprom which imx8mm-venice-gw700x.dtsi defines 4 of
> > (i2c1-0x50, i2c1-0x51, i2c1-0x52, i2c1-0x53). You can see above
> > i2c1-0x51 (i2c1=i2c@30a2) is accessed early as it holds the board
> > model information and at that point in time it's accessed with alen=1
> > (which I specify in board/gateworks/venice/eeprom.c:eeprom_read()) but
> > by the time the 'i2c md 0x51 0 50' comes around
> > i2c_get_chip_offset_len() returns 0 for this device. The other eeprom
> > devices on i2c1 are never accessed by a driver so they would never
> > have a 'default' alen set.
>
> OK I see,
>
> >
> > Where is the initial setting of alen supposed to have come?
>
> The "u-boot,i2c-offset-len" property in the device tree.
>

Simon,

I see what happened here. The issue is caused by commit 8f8c04bf1ebbd
("i2c: fix stack buffer overflow vulnerability in i2c md command")
which changed alen from int to uint (yet its still getting set to
DEFAULT_ADDR_LEN which is -1) thus the 'if (alen > 3)'  now returns
CMD_RET_USAGE.

I'm not sure what the best fix is at this point - revert all or part
of 8f8c04bf1ebbd

Nicolas, what is your opinion? To summarize commit 8f8c04bf1ebbd broke
the ability to pass a -1 default address length to do_i2c_* such that
something as common as 'i2c md 0x50 0 50' fails with a usage error.

Best Regards,

Tim


Tim


> Regards,
> Simon
>
>
> >
> > Best Regards,
> >
> > Tim
> >
> > >
> > > > diff --git a/cmd/i2c.c b/cmd/i2c.c
> > > > index bd04b14024be..c57271479e81 100644
> > > > --- a/cmd/i2c.c
> > > > +++ b/cmd/i2c.c
> > > > @@ -118,17 +118,7 @@ static uchar i2c_no_probes[] = 
> > > > CONFIG_SYS_I2C_NOPROBES;
> > > >  #endif
> > > >
> > > >  #define DISP_LINE_LEN  16
> > > > -
> > > > -/*
> > > > - * Default for driver model is to use the chip's existing address 
> > > > length.
> > > > - * For legacy code, this is not stored, so we need to use a suitable
> > > > - * default.
> > > > - */
> > > > -#if CONFIG_IS_ENABLED(DM_I2C)
> > > > -#define DEFAULT_ADDR_LEN   (-1)
> > > > -#else
> > > >  #define DEFAULT_ADDR_LEN   1
> > > > -#endif
> > > >
> > > >  #if CONFIG_IS_ENABLED(DM_I2C)
> > > >  static struct udevice *i2c_cur_bus;
> > > > --
> > > > 2.25.1
> > > >
> > >
> > > Regards,
> > > Simon


Re: [PATCH 5/5] arm: kirkwood: Do not overwrite CONFIG_SYS_TCLK

2022-08-16 Thread Pali Rohár
On Tuesday 16 August 2022 20:17:08 Pali Rohár wrote:
> Hello!
> 
> On Tuesday 16 August 2022 11:37:48 Michael Walle wrote:
> > Hi!
> > 
> > > On Sunday 01 August 2021 20:07:16 Chris Packham wrote:
> > > > On Sun, Aug 1, 2021 at 12:23 AM Pali Rohár  wrote:
> > > > >
> > > > > Config option CONFIG_SYS_TCLK is set by kw88f6281.h and kw88f6192.h 
> > > > > files
> > > > > to correct SOC/platform value. So do not overwrite it in board config
> > > > > include files.
> > > > >
> > > > > Kirkwood 88F6180 and 88F6192 uses 166 MHz TCLK and Kirkwood 88F6281 
> > > > > uses
> > > > > 200 MHz TCLK.
> > > > >
> > > > 
> > > > It's been a while since I worked with kirkwood but I thought that
> > > > there was hardware strapping for the TCLK.
> > > 
> > > Interesting... Because I took above information from Kirkwood hardware 
> > > specifications...
> > > 
> > > 88F6180: 
> > > https://web.archive.org/web/20130730091654/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf
> > > 88F6192: 
> > > https://web.archive.org/web/20121021182835/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf
> > > 88F6281: 
> > > https://web.archive.org/web/20120620073511/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
> > > 
> > > And there are specified fixed TCLK values.
> > 
> > Nope, this breaks my lsxl (specifically the LSCHLv2) board. The TCLK is
> > 166MHz there.
> 
> Ou, sorry for that.
> 
> > > > If I understand correctly
> > > > the defines in kw88f6281.h/kw88f6192.h were sensible defaults but
> > > > boards were able to override it to reflect the hardware configuration.
> > > 
> > > Anyway, I think that this patch should not cause issue as it is changing
> > > only two board config files and removing redefinition of CONFIG_SYS_TCLK
> > > macro which is set to the same value as in kw88f61**.h files.
> > 
> > At least for the lsxl and the NET2BIG_V2 this is not correct. Both have
> > the 88F6281 and both use have a 166MHz TCLK clock.
> 
> Interesting... because this contradicts publicly available
> documentation. Maybe in NDA doc is some more details?
> 
> > Anyway, I'm reverting this patch. The only open question is, should I
> > convert the TCLK to a Kconfig option?
> 
> In this case it would be better to detect TCLK from some SAR register,
> like it is already implemented for other Armada SoCs.
> 
> Just by a chance, do you have some "better" 88F6281 documentation? If
> there is some TCLK information or SAR register description. In publicly
> available FS_88F6180_9x_6281_OpenSource.pdf there is 0x10030 Sample at
> Reset Register, but nothing TCLK related.
> 
> At least BootROM has to detect TCLK because UART clock is derived from
> TCLK and BootROM supports UART booting via 115200 baudrate. In case you
> can provide me 88F6281 BootROM dump from your board, I can try to find
> code which configures UART and detect TCLK. I have already did it for
> 88F6820 (A385) to verify that U-Boot code detects TCLK in the same way
> as BootROM.

Meanwhile I have found following email thread:
https://lore.kernel.org/linux-arm-kernel/20121020113800.gc21...@lunn.ch/t/#u

Where are more 6281 boards with 166 MHz TCLK and there is interesting output:
$ dmesg | grep -i tclk
[5.851008] Kirkwood: MV88F6281-A0, TCLK=2

Which means that old kernel version had TCLK detection code. I grepped
git linux history and I successfully found it:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/mach-kirkwood/common.c?h=v3.15#n542

#define  SAMPLE_AT_RESET   (DEV_BUS_VIRT_BASE + 0x0030)

static int __init kirkwood_find_tclk(void)
{
u32 dev, rev;

kirkwood_pcie_id(&dev, &rev);

if (dev == MV88F6281_DEV_ID || dev == MV88F6282_DEV_ID)
if (((readl(SAMPLE_AT_RESET) >> 21) & 1) == 0)
return 2;

return 16667;
}

So for TCLK detection is used BIT 21 of already mentioned 0x10030 Sample
at Reset Register.

I'm going to prepare a patch which will fix this issue for 88F6281 SoCs.

> > -michael
> > 
> > > > Signed-off-by: Pali Rohár 
> > > > ---
> > > >  arch/arm/mach-kirkwood/include/mach/kw88f6281.h | 2 --
> > > >  include/configs/lacie_kw.h  | 5 -
> > > >  include/configs/lsxl.h  | 2 --
> > > >  3 files changed, 9 deletions(-)
> > > >
> > > > diff --git a/arch/arm/mach-kirkwood/include/mach/kw88f6281.h 
> > > > b/arch/arm/mach-kirkwood/include/mach/kw88f6281.h
> > > > index 33e741420781..87406081cf54 100644
> > > > --- a/arch/arm/mach-kirkwood/include/mach/kw88f6281.h
> > > > +++ b/arch/arm/mach-kirkwood/include/mach/kw88f6281.h
> > > > @@ -15,8 +15,6 @@
> > > >  #define KW_REGS_PHY_BASE   KW88F6281_REGS_PHYS_BASE
> > > >
> > > >  /* TCLK Core Clock definition */
> > > > -#ifndef CONFIG_SYS_TCLK
> > > >  #define CONFIG_SYS_TCLK2 /* 200MHz */
> > > > -#endif
> > > >
> > > >  #end

Fix KWBOOT_MSG_RSP_TIMEO_AXP in kwboot for Armada XP

2022-08-16 Thread Pali Rohár
On Wednesday 01 June 2022 12:54:28 Pali Rohár wrote:
> On Wednesday 01 June 2022 12:44:01 Stefan Roese wrote:
> > Hi Pali,
> > 
> > On 01.06.22 12:27, Pali Rohár wrote:
> > > On Friday 06 May 2022 14:44:48 Pali Rohár wrote:
> > > > On Friday 06 May 2022 14:35:55 Stefan Roese wrote:
> > > > > While doing this I noticed though, that kwboot UART booting only 
> > > > > worked
> > > > > in roughly 1 out of 2 cases. With no progress after this line:
> > > > > 
> > > > > Sending boot message. Please reboot the target...\
> > > > > 
> > > > > IIRC, this worked more reliable a few weeks ago. Any idea, what might
> > > > > have caused this regression - if I am correct here?
> > > > 
> > > > There were changes in handling of bootrom boot message. There is option
> > > > -s which can change default timeout option. And plus there is option -a
> > > > which sets this timeout option to AXP value.
> > > > 
> > > > Default value is 50 and for AXP default value is 1000.
> > > > 
> > > > Maybe it is needed to tune AXP value... Try to call with -s option
> > > > between 50 and 1000...
> > > 
> > > Hello Stefan! Have you tried to tune kwboot's -s or -a option for AXP 
> > > board?
> > 
> > Thanks for getting back on this. I totally forgot about it.
> > 
> > '-a' makes it actually worse. Zero success with 5 tries. '-s 10' worked
> > 5 out of 5 times. So I'll stick with this version I think.
> > 
> > Thanks,
> > Stefan
> 
> Ok! So I think that you could change KWBOOT_MSG_RSP_TIMEO_AXP value in
> tools/kwboot.c to 10 if it works fine for your AXP board. So '-a' option
> would work better.

Hello! I would like to remind this issue. Could you look at it, so we do
not have broken '-a' option in kwboot?


Re: [PATCH 5/5] arm: kirkwood: Do not overwrite CONFIG_SYS_TCLK

2022-08-16 Thread Pali Rohár
Hello!

On Tuesday 16 August 2022 11:37:48 Michael Walle wrote:
> Hi!
> 
> > On Sunday 01 August 2021 20:07:16 Chris Packham wrote:
> > > On Sun, Aug 1, 2021 at 12:23 AM Pali Rohár  wrote:
> > > >
> > > > Config option CONFIG_SYS_TCLK is set by kw88f6281.h and kw88f6192.h 
> > > > files
> > > > to correct SOC/platform value. So do not overwrite it in board config
> > > > include files.
> > > >
> > > > Kirkwood 88F6180 and 88F6192 uses 166 MHz TCLK and Kirkwood 88F6281 uses
> > > > 200 MHz TCLK.
> > > >
> > > 
> > > It's been a while since I worked with kirkwood but I thought that
> > > there was hardware strapping for the TCLK.
> > 
> > Interesting... Because I took above information from Kirkwood hardware 
> > specifications...
> > 
> > 88F6180: 
> > https://web.archive.org/web/20130730091654/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf
> > 88F6192: 
> > https://web.archive.org/web/20121021182835/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf
> > 88F6281: 
> > https://web.archive.org/web/20120620073511/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
> > 
> > And there are specified fixed TCLK values.
> 
> Nope, this breaks my lsxl (specifically the LSCHLv2) board. The TCLK is
> 166MHz there.

Ou, sorry for that.

> > > If I understand correctly
> > > the defines in kw88f6281.h/kw88f6192.h were sensible defaults but
> > > boards were able to override it to reflect the hardware configuration.
> > 
> > Anyway, I think that this patch should not cause issue as it is changing
> > only two board config files and removing redefinition of CONFIG_SYS_TCLK
> > macro which is set to the same value as in kw88f61**.h files.
> 
> At least for the lsxl and the NET2BIG_V2 this is not correct. Both have
> the 88F6281 and both use have a 166MHz TCLK clock.

Interesting... because this contradicts publicly available
documentation. Maybe in NDA doc is some more details?

> Anyway, I'm reverting this patch. The only open question is, should I
> convert the TCLK to a Kconfig option?

In this case it would be better to detect TCLK from some SAR register,
like it is already implemented for other Armada SoCs.

Just by a chance, do you have some "better" 88F6281 documentation? If
there is some TCLK information or SAR register description. In publicly
available FS_88F6180_9x_6281_OpenSource.pdf there is 0x10030 Sample at
Reset Register, but nothing TCLK related.

At least BootROM has to detect TCLK because UART clock is derived from
TCLK and BootROM supports UART booting via 115200 baudrate. In case you
can provide me 88F6281 BootROM dump from your board, I can try to find
code which configures UART and detect TCLK. I have already did it for
88F6820 (A385) to verify that U-Boot code detects TCLK in the same way
as BootROM.

> -michael
> 
> > > Signed-off-by: Pali Rohár 
> > > ---
> > >  arch/arm/mach-kirkwood/include/mach/kw88f6281.h | 2 --
> > >  include/configs/lacie_kw.h  | 5 -
> > >  include/configs/lsxl.h  | 2 --
> > >  3 files changed, 9 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-kirkwood/include/mach/kw88f6281.h 
> > > b/arch/arm/mach-kirkwood/include/mach/kw88f6281.h
> > > index 33e741420781..87406081cf54 100644
> > > --- a/arch/arm/mach-kirkwood/include/mach/kw88f6281.h
> > > +++ b/arch/arm/mach-kirkwood/include/mach/kw88f6281.h
> > > @@ -15,8 +15,6 @@
> > >  #define KW_REGS_PHY_BASE   KW88F6281_REGS_PHYS_BASE
> > >
> > >  /* TCLK Core Clock definition */
> > > -#ifndef CONFIG_SYS_TCLK
> > >  #define CONFIG_SYS_TCLK2 /* 200MHz */
> > > -#endif
> > >
> > >  #endif /* _ASM_ARCH_KW88F6281_H */
> > > diff --git a/include/configs/lacie_kw.h b/include/configs/lacie_kw.h
> > > index 420c1d49b08e..88f784f1f0fd 100644
> > > --- a/include/configs/lacie_kw.h
> > > +++ b/include/configs/lacie_kw.h
> > > @@ -39,11 +39,6 @@
> > >  #endif
> > >  #define CONFIG_SKIP_LOWLEVEL_INIT  /* disable board lowlevel_init */
> > >
> > > -/*
> > > - * Core clock definition
> > > - */
> > > -#define CONFIG_SYS_TCLK16600 /* 166MHz */
> > > -
> > >  /*
> > >   * SDRAM configuration
> > >   */
> > > diff --git a/include/configs/lsxl.h b/include/configs/lsxl.h
> > > index 0c0ab2486e23..a4a4739d0dd7 100644
> > > --- a/include/configs/lsxl.h
> > > +++ b/include/configs/lsxl.h
> > > @@ -13,11 +13,9 @@
> > >  #if defined(CONFIG_LSCHLV2)
> > >  #define CONFIG_SYS_KWD_CONFIG $(CONFIG_BOARDDIR)/kwbimage-lschl.cfg
> > >  #define CONFIG_MACH_TYPE 3006
> > > -#define CONFIG_SYS_TCLK 16667 /* 166 MHz */
> > >  #elif defined(CONFIG_LSXHL)
> > >  #define CONFIG_SYS_KWD_CONFIG $(CONFIG_BOARDDIR)/kwbimage-lsxhl.cfg
> > >  #define CONFIG_MACH_TYPE 2663
> > > -/* CONFIG_SYS_TCLK is 2 by default */
> > >  #else
> > >  #error "unknown board"
> > >  #endif
> > > --
> > > 2.20.1
> > >
> 


Re: [PATCH] arm: ARMv4 assembly compatibility

2022-08-16 Thread Ralph Siemsen
On Tue, Aug 16, 2022 at 12:17 PM Andre Przywara  wrote:
>
> So what is the story here? This commit seems to suggest U-Boot doesn't support
> even ARMv5 without "T", has this changed? There are probably other code
> places which would need adjustment to run on ARMv4?

Note that gcc 6.0 and later considers armv4 (non-Thumb) support to be
deprecated. [1] [2]

[1] https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
[2] https://lkml.iu.edu/hypermail/linux/kernel/1712.2/05158.html

On Wed, 10 Aug 2022 12:04:46 +0300 Sergei Antonov  wrote:
>
> A working preprocessor-based solution to this problem is found in
> arch/arm/lib/relocate.S. Move it to the "ret" macro in
> arch/arm/include/asm/assembler.h and change all "bx lr" code
> to "ret lr" in functions that may run on ARMv4. Linux source code
> deals with this problem in the same manner.

Just wanted to point out another option: the linker has a --fix-v4bx
flat, which performs the same conversion of "bx lr" to "mov pc lr".
Although it is kind of an unusual place for such a transformation, it
has the advantage that one does not need to fixup the source code of
every piece of code you might like to compile. I used this some years
ago [3], and it seems it still works in 2020 [4]

[3] http://lists.infradead.org/pipermail/netwinder/2017-August/000267.html
[4] https://lists.gnu.org/archive/html/bug-binutils/2020-02/msg00174.html

Ralph


Re: [PATCH] arm: ARMv4 assembly compatibility

2022-08-16 Thread Andre Przywara
On Wed, 10 Aug 2022 12:04:46 +0300
Sergei Antonov  wrote:

Hi,

> There is currently a problem that U-Boot can not work on ARMv4
> because assembly imlementations of memcpy() and some other functions
> use "bx lr" instruction that is not available on ARMv4 ("mov pc, lr"
> should be used instead).

So there is a comment in the current code, right above what's shown here in
the first hunk, which says:
/*
 * We only support cores that support at least Thumb-1 and thus we use
 * 'bx lr'
 */
This was added by Tom in commit 431afb4ef9fe, when he removed some code
very close to what you are adding back now.

So what is the story here? This commit seems to suggest U-Boot doesn't support
even ARMv5 without "T", has this changed? There are probably other code
places which would need adjustment to run on ARMv4?

Tom, can you say why support for Thumb-less code / older architectures was
dropped? No users, I guess?

Sergei, can you say what is this for? Are you adding support for a SoC
with an ARM810 core from 1996?

Cheers,
Andre



> 
> A working preprocessor-based solution to this problem is found in
> arch/arm/lib/relocate.S. Move it to the "ret" macro in
> arch/arm/include/asm/assembler.h and change all "bx lr" code
> to "ret lr" in functions that may run on ARMv4. Linux source code
> deals with this problem in the same manner.
> 
> Signed-off-by: Sergei Antonov 
> CC: Samuel Holland 
> CC: Ye Li 
> CC: Simon Glass 
> CC: Andre Przywara 
> CC: Marek Vasut 
> CC: Sean Anderson 
> CC: Tom Rini 
> CC: Wolfgang Denk 
> ---
>  arch/arm/include/asm/assembler.h |  6 ++
>  arch/arm/lib/lib1funcs.S |  8 
>  arch/arm/lib/memcpy.S|  6 +++---
>  arch/arm/lib/relocate.S  | 10 ++
>  arch/arm/lib/setjmp.S|  4 ++--
>  5 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/arch/arm/include/asm/assembler.h 
> b/arch/arm/include/asm/assembler.h
> index b146918586..911f7a1b49 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -63,11 +63,17 @@
>   */
>   .irpc,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
>   .macro  ret\c, reg
> +
> + /* ARMv4- don't know bx lr but the assembler fails to see that */
> +#ifdef __ARM_ARCH_4__
> + mov\c   pc, \reg
> +#else
>   .ifeqs  "\reg", "lr"
>   bx\c\reg
>   .else
>   mov\c   pc, \reg
>   .endif
> +#endif
>   .endm
>   .endr
>  
> diff --git a/arch/arm/lib/lib1funcs.S b/arch/arm/lib/lib1funcs.S
> index 700eee5fbb..7ff4446dd6 100644
> --- a/arch/arm/lib/lib1funcs.S
> +++ b/arch/arm/lib/lib1funcs.S
> @@ -377,7 +377,7 @@ ENTRY(__gnu_thumb1_case_sqi)
>   lslsr1, r1, #1
>   add lr, lr, r1
>   pop {r1}
> - bx  lr
> + ret lr
>  ENDPROC(__gnu_thumb1_case_sqi)
>  .popsection
>  
> @@ -391,7 +391,7 @@ ENTRY(__gnu_thumb1_case_uqi)
>   lslsr1, r1, #1
>   add lr, lr, r1
>   pop {r1}
> - bx  lr
> + ret lr
>  ENDPROC(__gnu_thumb1_case_uqi)
>  .popsection
>  
> @@ -406,7 +406,7 @@ ENTRY(__gnu_thumb1_case_shi)
>   lslsr1, r1, #1
>   add lr, lr, r1
>   pop {r0, r1}
> - bx  lr
> + ret lr
>  ENDPROC(__gnu_thumb1_case_shi)
>  .popsection
>  
> @@ -421,7 +421,7 @@ ENTRY(__gnu_thumb1_case_uhi)
>   lslsr1, r1, #1
>   add lr, lr, r1
>   pop {r0, r1}
> - bx  lr
> + ret lr
>  ENDPROC(__gnu_thumb1_case_uhi)
>  .popsection
>  #endif
> diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
> index eee7a219ce..a1c996f94e 100644
> --- a/arch/arm/lib/memcpy.S
> +++ b/arch/arm/lib/memcpy.S
> @@ -59,7 +59,7 @@
>  #endif
>  ENTRY(memcpy)
>   cmp r0, r1
> - bxeqlr
> + reteq   lr
>  
>   enter   r4, lr
>  
> @@ -148,7 +148,7 @@ ENTRY(memcpy)
>   str1b   r0, ip, cs, abort=21f
>  
>   exitr4, lr
> - bx  lr
> + ret lr
>  
>  9:   rsb ip, ip, #4
>   cmp ip, #2
> @@ -258,7 +258,7 @@ ENTRY(memcpy)
>  
>   .macro  copy_abort_end
>   ldmfd   sp!, {r4, lr}
> - bx  lr
> + ret lr
>   .endm
>  
>  ENDPROC(memcpy)
> diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
> index 5102bfabde..dd6f2e3bd5 100644
> --- a/arch/arm/lib/relocate.S
> +++ b/arch/arm/lib/relocate.S
> @@ -61,7 +61,7 @@ ENTRY(relocate_vectors)
>   stmia   r1!, {r2-r8,r10}
>  #endif
>  #endif
> - bx  lr
> + ret lr
>  
>  ENDPROC(relocate_vectors)
>  
> @@ -127,13 +127,7 @@ relocate_done:
>   mcr p15, 0, r0, c7, c10, 4  /* drain write buffer */
>  #endif
>  
> - /* ARMv4- don't know bx lr but the assembler fails to see that */
> -
> -#ifdef __ARM_ARCH_4__
> - mov pc, lr
> -#else
> - bx  lr
> -#endif
> + ret lr
>  
>  ENDPROC(relocate_code)
>  
> diff --git a/arch/arm/lib/setjmp.S b/arch/arm/lib/setjmp.S
> index 176a1d5

[PATCHv3] drivers: tee: i2c: support the NXP SE05x probe errata

2022-08-16 Thread Jorge Ramirez-Ortiz
Early instantiation of this I2C device would lock up when being
probed.

 https://www.nxp.com/docs/en/errata/SE050_Erratasheet.pdf
 3.2.2
   In scenarios of detecting I2C ICs on the bus using an empty
   I2C frame containing only the address the SE050 will block
   the I2C bus.

Tested on STM32MP1

Signed-off-by: Jorge Ramirez-Ortiz 
Acked-by: Oleksandr Suvorov 

---
 drivers/tee/optee/Kconfig | 14 +
 drivers/tee/optee/i2c.c   | 44 +++
 2 files changed, 54 insertions(+), 4 deletions(-)

diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
index d03028070b..a80ddaed2c 100644
--- a/drivers/tee/optee/Kconfig
+++ b/drivers/tee/optee/Kconfig
@@ -37,6 +37,20 @@ config OPTEE_TA_SCP03
help
  Enables support for controlling (enabling, provisioning) the
  Secure Channel Protocol 03 operation in the OP-TEE SCP03 TA.
+
+config TEE_I2C_NXP_SE05X_ERRATA
+   bool "Enable NXP SE05X Errata"
+   select TEE_I2C_NXP_SE05X_ERRATA_IN_BUS
+   default n
+   help
+ This config prevents the I2C trampoline driver from probing
+ on every transfer.
+
+config TEE_I2C_NXP_SE05X_ERRATA_IN_BUS
+   int "I2C bus where to apply the NXP SE05X errata"
+   depends on TEE_I2C_NXP_SE05X_ERRATA
+   default 0
+
 endmenu
 
 endif
diff --git a/drivers/tee/optee/i2c.c b/drivers/tee/optee/i2c.c
index ef4e10f991..a3ea34d4a2 100644
--- a/drivers/tee/optee/i2c.c
+++ b/drivers/tee/optee/i2c.c
@@ -3,13 +3,18 @@
  * Copyright (c) 2020 Foundries.io Ltd
  */
 
+#define LOG_CATEGORY UCLASS_I2C
+
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "optee_msg.h"
 #include "optee_private.h"
 
+#define NXP_SE05X_ADDR 0x48
+
 static int check_xfer_flags(struct udevice *chip, uint tee_flags)
 {
uint flags;
@@ -30,6 +35,30 @@ static int check_xfer_flags(struct udevice *chip, uint 
tee_flags)
return 0;
 }
 
+static struct udevice *get_chip_dev(int bnum, int addr)
+{
+   struct udevice *chip;
+   struct udevice *bus;
+
+   if (IS_ENABLED(CONFIG_TEE_I2C_NXP_SE05X_ERRATA)) {
+   if (bnum == CONFIG_TEE_I2C_NXP_SE05X_ERRATA_IN_BUS &&
+   addr == NXP_SE05X_ADDR) {
+   if (uclass_get_device_by_seq(UCLASS_I2C, bnum, &bus))
+   return NULL;
+
+   if (i2c_get_chip(bus, addr, 0, &chip))
+   return NULL;
+
+   return chip;
+   }
+   }
+
+   if (i2c_get_chip_for_busnum(bnum, addr, 0, &chip))
+   return NULL;
+
+   return chip;
+}
+
 void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg *arg)
 {
const u8 attr[] = {
@@ -38,7 +67,8 @@ void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg *arg)
OPTEE_MSG_ATTR_TYPE_RMEM_INOUT,
OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT,
};
-   struct udevice *chip_dev;
+   struct udevice *chip_dev = NULL;
+
struct tee_shm *shm;
u8 *buf;
int ret;
@@ -56,9 +86,9 @@ void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg *arg)
if (!buf)
goto bad;
 
-   if (i2c_get_chip_for_busnum((int)arg->params[0].u.value.b,
-   (int)arg->params[0].u.value.c,
-   0, &chip_dev))
+   chip_dev = get_chip_dev((int)arg->params[0].u.value.b,
+   (int)arg->params[0].u.value.c);
+   if (!chip_dev)
goto bad;
 
if (check_xfer_flags(chip_dev, arg->params[1].u.value.a))
@@ -66,10 +96,16 @@ void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg *arg)
 
switch (arg->params[0].u.value.a) {
case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD:
+   log_debug("OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD %d\n",
+ (size_t)arg->params[2].u.rmem.size);
+
ret = dm_i2c_read(chip_dev, 0, buf,
  (size_t)arg->params[2].u.rmem.size);
break;
case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR:
+   log_debug("OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR %d\n",
+ (size_t)arg->params[2].u.rmem.size);
+
ret = dm_i2c_write(chip_dev, 0, buf,
   (size_t)arg->params[2].u.rmem.size);
break;
-- 
2.34.1



Re: [PATCH] drivers: tee: i2c: support the NXP SE05x probe errata

2022-08-16 Thread Jorge Ramirez-Ortiz, Foundries
On 16/08/22, Oleksandr Suvorov wrote:
> Hi Jorge,
> 
> On Tue, Aug 16, 2022 at 2:28 PM Jorge Ramirez-Ortiz  
> wrote:
> >
> > Early instantiation of this I2C device would lock up when being
> > probed.
> >
> > Signed-off-by: Jorge Ramirez-Ortiz 
> 
> With a small note below,
> Acked-by: Oleksandr Suvorov 
> 
> > ---
> >  drivers/tee/optee/Kconfig | 14 +
> >  drivers/tee/optee/i2c.c   | 44 +++
> >  2 files changed, 54 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
> > index d03028070b..05dfe2c9a8 100644
> > --- a/drivers/tee/optee/Kconfig
> > +++ b/drivers/tee/optee/Kconfig
> > @@ -37,6 +37,20 @@ config OPTEE_TA_SCP03
> > help
> >   Enables support for controlling (enabling, provisioning) the
> >   Secure Channel Protocol 03 operation in the OP-TEE SCP03 TA.
> > +
> > +config TEE_I2C_NXP_SE05X_ERRATA
> > +   bool "Enable NXP SE05X Errata"
> > +   select TEE_I2C_NXP_SE05X_ERRATA_IN_BUS
> > +   default y
> 
> I doubt this should be enabled by default.

you are probably right (was just fixing the problem as was being reported by
some user).

will remove the active default

> 
> > +   help
> > + This config prevents the I2C trampoline driver from probing
> > + on every transfer.
> > +
> > +config TEE_I2C_NXP_SE05X_ERRATA_IN_BUS
> > +   int "I2C bus where to apply the NXP SE05X errata"
> > +   depends on TEE_I2C_NXP_SE05X_ERRATA
> > +   default 0
> > +
> >  endmenu
> >
> >  endif
> > diff --git a/drivers/tee/optee/i2c.c b/drivers/tee/optee/i2c.c
> > index ef4e10f991..a3ea34d4a2 100644
> > --- a/drivers/tee/optee/i2c.c
> > +++ b/drivers/tee/optee/i2c.c
> > @@ -3,13 +3,18 @@
> >   * Copyright (c) 2020 Foundries.io Ltd
> >   */
> >
> > +#define LOG_CATEGORY UCLASS_I2C
> > +
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include "optee_msg.h"
> >  #include "optee_private.h"
> >
> > +#define NXP_SE05X_ADDR 0x48
> > +
> >  static int check_xfer_flags(struct udevice *chip, uint tee_flags)
> >  {
> > uint flags;
> > @@ -30,6 +35,30 @@ static int check_xfer_flags(struct udevice *chip, uint 
> > tee_flags)
> > return 0;
> >  }
> >
> > +static struct udevice *get_chip_dev(int bnum, int addr)
> > +{
> > +   struct udevice *chip;
> > +   struct udevice *bus;
> > +
> > +   if (IS_ENABLED(CONFIG_TEE_I2C_NXP_SE05X_ERRATA)) {
> > +   if (bnum == CONFIG_TEE_I2C_NXP_SE05X_ERRATA_IN_BUS &&
> > +   addr == NXP_SE05X_ADDR) {
> > +   if (uclass_get_device_by_seq(UCLASS_I2C, bnum, 
> > &bus))
> > +   return NULL;
> > +
> > +   if (i2c_get_chip(bus, addr, 0, &chip))
> > +   return NULL;
> > +
> > +   return chip;
> > +   }
> > +   }
> > +
> > +   if (i2c_get_chip_for_busnum(bnum, addr, 0, &chip))
> > +   return NULL;
> > +
> > +   return chip;
> > +}
> > +
> >  void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg *arg)
> >  {
> > const u8 attr[] = {
> > @@ -38,7 +67,8 @@ void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg 
> > *arg)
> > OPTEE_MSG_ATTR_TYPE_RMEM_INOUT,
> > OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT,
> > };
> > -   struct udevice *chip_dev;
> > +   struct udevice *chip_dev = NULL;
> > +
> > struct tee_shm *shm;
> > u8 *buf;
> > int ret;
> > @@ -56,9 +86,9 @@ void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg 
> > *arg)
> > if (!buf)
> > goto bad;
> >
> > -   if (i2c_get_chip_for_busnum((int)arg->params[0].u.value.b,
> > -   (int)arg->params[0].u.value.c,
> > -   0, &chip_dev))
> > +   chip_dev = get_chip_dev((int)arg->params[0].u.value.b,
> > +   (int)arg->params[0].u.value.c);
> > +   if (!chip_dev)
> > goto bad;
> >
> > if (check_xfer_flags(chip_dev, arg->params[1].u.value.a))
> > @@ -66,10 +96,16 @@ void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg 
> > *arg)
> >
> > switch (arg->params[0].u.value.a) {
> > case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD:
> > +   log_debug("OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD %d\n",
> > + (size_t)arg->params[2].u.rmem.size);
> > +
> > ret = dm_i2c_read(chip_dev, 0, buf,
> >   (size_t)arg->params[2].u.rmem.size);
> > break;
> > case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR:
> > +   log_debug("OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR %d\n",
> > + (size_t)arg->params[2].u.rmem.size);
> > +
> > ret = dm_i2c_write(chip_dev, 0, buf,
> >(size_t)arg->params[2].u.rmem.size

Re: [PATCH v2 1/6] ARMv8/sec_firmware: Remove SEC_FIRMWARE_FIT_CNF_NAME

2022-08-16 Thread Sean Anderson
Hi Peng,

On 8/16/22 4:22 AM, Peng Fan wrote:
> Hi Sean,
> 
> On 4/23/2022 1:38 AM, Sean Anderson wrote:
>> The config to use for FIT images can be better specified by enabling
>> CONFIG_MULTI_DTB_FIT and implementing board_fit_config_name_match.
>>
>> Signed-off-by: Sean Anderson 
>> ---
> 
> This patchset not able to apply, could you please repost?

I resent, but please note the following comment from the cover letter:

> This series depends on [1]. There is no logical dependency, but they
> modify adjacent #includes, so the last patch will not apply cleanly
> unless that series is applied.
> 
> [1] 
> https://lore.kernel.org/u-boot/20220422173032.2259019-1-sean.ander...@seco.com/

I can rebase things either way, but there is an unavoidable conflict.

--Sean


[RESEND PATCH v2 6/6] net: fm: Add support for FIT firmware

2022-08-16 Thread Sean Anderson
Fman microcode is executable code (AFAICT) loaded into a
coprocessor. As such, if verified boot is enabled, it must be verified
like other executable code. However, this is not currently done.

This commit adds verified boot functionality by encapsulating the
microcode in a FIT, which can then be signed/verified as normal. By
default we allow fallback to unencapsulated firmware, but if
CONFIG_FIT_SIGNATURE is enabled, then we make it mandatory. Because
existing Layerscape do not use this config (instead enabling
CONFIG_CHAIN_OF_TRUST), this should not break any existing boards.

An example (mildly-abbreviated) its is provided below:

/ {
#address-cells = <1>;

images {
firmware {
data = /incbin/(/path/to/firmware);
type = "firmware";
arch = "arm64";
compression = "none";
signature {
algo = "sha256,rsa2048";
key-name-hint = "your key name";
};
};
};

configurations {
default = "conf";
conf {
description = "Load FMAN microcode";
fman = "firmware";
};
};
};

Signed-off-by: Sean Anderson 
---

(no changes since v1)

 drivers/net/fm/fm.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/net/fm/fm.c b/drivers/net/fm/fm.c
index 4f5d51251e5..894a5e29fa4 100644
--- a/drivers/net/fm/fm.c
+++ b/drivers/net/fm/fm.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -537,6 +538,23 @@ int fm_init_common(int index, struct ccsr_fman *reg, const 
char *firmware_name)
void *addr = NULL;
 #endif
 
+   rc = fit_check_format(addr, CONFIG_SYS_QE_FMAN_FW_LENGTH);
+   if (!rc) {
+   size_t unused;
+   const void *new_addr;
+
+   rc = fit_get_data_conf_prop(addr, "fman", &new_addr, &unused);
+   if (rc)
+   return rc;
+   addr = (void *)new_addr;
+   } else if (CONFIG_IS_ENABLED(FIT_SIGNATURE)) {
+   /*
+* Using a (signed) FIT wrapper is mandatory if we are
+* doing verified boot.
+*/
+   return rc;
+   }
+
/* Upload the Fman microcode if it's present */
rc = fman_upload_firmware(index, ®->fm_imem, addr);
if (rc)
-- 
2.35.1.1320.gc452695387.dirty



[RESEND PATCH v2 4/6] cmd: fpga: Convert to use fit_get_data_node

2022-08-16 Thread Sean Anderson
This converts the FIT loading process of the fpga command to use
fit_get_data_node.

Signed-off-by: Sean Anderson 
---

Changes in v2:
- New

 cmd/fpga.c | 24 ++--
 1 file changed, 6 insertions(+), 18 deletions(-)

diff --git a/cmd/fpga.c b/cmd/fpga.c
index c4651dd403e..9cf7651d8c5 100644
--- a/cmd/fpga.c
+++ b/cmd/fpga.c
@@ -322,7 +322,7 @@ static int do_fpga_loadmk(struct cmd_tbl *cmdtp, int flag, 
int argc,
case IMAGE_FORMAT_FIT:
{
const void *fit_hdr = (const void *)fpga_data;
-   int noffset;
+   int err;
const void *fit_data;
 
if (!fit_uname) {
@@ -335,23 +335,11 @@ static int do_fpga_loadmk(struct cmd_tbl *cmdtp, int 
flag, int argc,
return CMD_RET_FAILURE;
}
 
-   /* get fpga component image node offset */
-   noffset = fit_image_get_node(fit_hdr, fit_uname);
-   if (noffset < 0) {
-   printf("Can't find '%s' FIT subimage\n", fit_uname);
-   return CMD_RET_FAILURE;
-   }
-
-   /* verify integrity */
-   if (!fit_image_verify(fit_hdr, noffset)) {
-   puts("Bad Data Hash\n");
-   return CMD_RET_FAILURE;
-   }
-
-   /* get fpga subimage/external data address and length */
-   if (fit_image_get_data_and_size(fit_hdr, noffset,
-  &fit_data, &data_size)) {
-   puts("Fpga subimage data not found\n");
+   err = fit_get_data_node(fit_hdr, fit_uname, &fit_data,
+   &data_size);
+   if (err) {
+   printf("Could not load '%s' subimage (err %d)\n",
+  fit_uname, err);
return CMD_RET_FAILURE;
}
 
-- 
2.35.1.1320.gc452695387.dirty



[RESEND PATCH v2 5/6] net: Convert fit verification to use fit_get_data_*

2022-08-16 Thread Sean Anderson
Several ethernet drivers load firmware from FIT images. Convert them to
use the fit_get_data helpers.

Signed-off-by: Sean Anderson 
---

Changes in v2:
- New

 drivers/net/fsl-mc/mc.c| 30 +++---
 drivers/net/pfe_eth/pfe_firmware.c | 40 +-
 2 files changed, 4 insertions(+), 66 deletions(-)

diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index bc1c31d4675..68833f9ddd9 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -137,13 +137,7 @@ int parse_mc_firmware_fit_image(u64 mc_fw_addr,
size_t *raw_image_size)
 {
int format;
-   void *fit_hdr;
-   int node_offset;
-   const void *data;
-   size_t size;
-   const char *uname = "firmware";
-
-   fit_hdr = (void *)mc_fw_addr;
+   void *fit_hdr = (void *)mc_fw_addr;
 
/* Check if Image is in FIT format */
format = genimg_get_format(fit_hdr);
@@ -158,26 +152,8 @@ int parse_mc_firmware_fit_image(u64 mc_fw_addr,
return -EINVAL;
}
 
-   node_offset = fit_image_get_node(fit_hdr, uname);
-
-   if (node_offset < 0) {
-   printf("fsl-mc: ERR: Bad firmware image (missing subimage)\n");
-   return -ENOENT;
-   }
-
-   /* Verify MC firmware image */
-   if (!(fit_image_verify(fit_hdr, node_offset))) {
-   printf("fsl-mc: ERR: Bad firmware image (bad CRC)\n");
-   return -EINVAL;
-   }
-
-   /* Get address and size of raw image */
-   fit_image_get_data(fit_hdr, node_offset, &data, &size);
-
-   *raw_image_addr = data;
-   *raw_image_size = size;
-
-   return 0;
+   return fit_get_data_node(fit_hdr, "firmware", raw_image_addr,
+raw_image_size);
 }
 #endif
 
diff --git a/drivers/net/pfe_eth/pfe_firmware.c 
b/drivers/net/pfe_eth/pfe_firmware.c
index 82a4aa89a4d..da4f2ca42a5 100644
--- a/drivers/net/pfe_eth/pfe_firmware.c
+++ b/drivers/net/pfe_eth/pfe_firmware.c
@@ -104,45 +104,7 @@ err:
 static int pfe_get_fw(const void **data,
  size_t *size, char *fw_name)
 {
-   int conf_node_off, fw_node_off;
-   char *conf_node_name = NULL;
-   char *desc;
-   int ret = 0;
-
-   conf_node_name = PFE_FIRMWARE_FIT_CNF_NAME;
-
-   conf_node_off = fit_conf_get_node(pfe_fit_addr, conf_node_name);
-   if (conf_node_off < 0) {
-   printf("PFE Firmware: %s: no such config\n", conf_node_name);
-   return -ENOENT;
-   }
-
-   fw_node_off = fit_conf_get_prop_node(pfe_fit_addr, conf_node_off,
-fw_name);
-   if (fw_node_off < 0) {
-   printf("PFE Firmware: No '%s' in config\n",
-  fw_name);
-   return -ENOLINK;
-   }
-
-   if (!(fit_image_verify(pfe_fit_addr, fw_node_off))) {
-   printf("PFE Firmware: Bad firmware image (bad CRC)\n");
-   return -EINVAL;
-   }
-
-   if (fit_image_get_data(pfe_fit_addr, fw_node_off, data, size)) {
-   printf("PFE Firmware: Can't get %s subimage data/size",
-  fw_name);
-   return -ENOENT;
-   }
-
-   ret = fit_get_desc(pfe_fit_addr, fw_node_off, &desc);
-   if (ret)
-   printf("PFE Firmware: Can't get description\n");
-   else
-   printf("%s\n", desc);
-
-   return ret;
+   return fit_get_data_conf_prop(pfe_fit_addr, fw_name, data, size);
 }
 
 /*
-- 
2.35.1.1320.gc452695387.dirty



[RESEND PATCH v2 2/6] image: fit: Add some helpers for getting data

2022-08-16 Thread Sean Anderson
Several different firmware users have repetitive code to extract the
firmware data from a FIT. Add some helper functions to reduce the amount
of repetition. fit_conf_get_prop_node (eventually) calls
fdt_check_node_offset_, so we can avoid an explicit if. In general, this
version avoids printing on error because the callers are typically
library functions, and because the FIT code generally has (debug)
prints of its own. One difference in these helpers is that they use
fit_image_get_data_and_size instead of fit_image_get_data, as the former
handles external data correctly.

Signed-off-by: Sean Anderson 
---

Changes in v2:
- Document helpers

 boot/image-fit.c | 37 +
 include/image.h  | 70 
 2 files changed, 107 insertions(+)

diff --git a/boot/image-fit.c b/boot/image-fit.c
index df3e5df8836..9c04ff78a15 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -1917,6 +1917,43 @@ int fit_conf_get_prop_node(const void *fit, int noffset,
return fit_conf_get_prop_node_index(fit, noffset, prop_name, 0);
 }
 
+static int fit_get_data_tail(const void *fit, int noffset,
+const void **data, size_t *size)
+{
+   char *desc;
+
+   if (noffset < 0)
+   return noffset;
+
+   if (!fit_image_verify(fit, noffset))
+   return -EINVAL;
+
+   if (fit_image_get_data_and_size(fit, noffset, data, size))
+   return -ENOENT;
+
+   if (!fit_get_desc(fit, noffset, &desc))
+   printf("%s\n", desc);
+
+   return 0;
+}
+
+int fit_get_data_node(const void *fit, const char *image_uname,
+ const void **data, size_t *size)
+{
+   int noffset = fit_image_get_node(fit, image_uname);
+
+   return fit_get_data_tail(fit, noffset, data, size);
+}
+
+int fit_get_data_conf_prop(const void *fit, const char *prop_name,
+  const void **data, size_t *size)
+{
+   int noffset = fit_conf_get_node(fit, NULL);
+
+   noffset = fit_conf_get_prop_node(fit, noffset, prop_name);
+   return fit_get_data_tail(fit, noffset, data, size);
+}
+
 static int fit_image_select(const void *fit, int rd_noffset, int verify)
 {
fit_image_print(fit, rd_noffset, "   ");
diff --git a/include/image.h b/include/image.h
index e4c6a50b885..d7d756c6453 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1014,6 +1014,76 @@ int fit_image_get_data_size_unciphered(const void *fit, 
int noffset,
 int fit_image_get_data_and_size(const void *fit, int noffset,
const void **data, size_t *size);
 
+/**
+ * fit_get_data_node() - Get verified image data for an image
+ * @fit: Pointer to the FIT format image header
+ * @image_uname: The name of the image node
+ * @data: A pointer which will be filled with the location of the image data
+ * @size: A pointer which will be filled with the size of the image data
+ *
+ * This function looks up the location and size of an image specified by its
+ * name. For example, if you had a FIT like::
+ *
+ * images {
+ * my-firmware {
+ * ...
+ *};
+ *  };
+ *
+ * Then you could look up the data location and size of the my-firmware image
+ * by calling this function with @image_uname set to "my-firmware". This
+ * function also verifies the image data (if enabled) before returning. The
+ * image description is printed out on success. @data and @size will not be
+ * modified on faulure.
+ *
+ * Return:
+ * * 0 on success
+ * * -EINVAL if the image could not be verified
+ * * -ENOENT if there was a problem getting the data/size
+ * * Another negative error if there was a problem looking up the image node.
+ */
+int fit_get_data_node(const void *fit, const char *image_uname,
+ const void **data, size_t *size);
+
+/**
+ * fit_get_data_conf_prop() - Get verified image data for a property in /conf
+ * @fit: Pointer to the FIT format image header
+ * @prop_name: The name of the property in /conf referencing the image
+ * @data: A pointer which will be filled with the location of the image data
+ * @size: A pointer which will be filled with the size of the image data
+ *
+ * This function looks up the location and size of an image specified by a
+ * property in /conf. For example, if you had a FIT like::
+ *
+ * images {
+ * my-firmware {
+ * ...
+ *};
+ *  };
+ *
+ *  configurations {
+ *  default = "conf-1";
+ *  conf-1 {
+ *  some-firmware = "my-firmware";
+ *  };
+ *  };
+ *
+ * Then you could look up the data location and size of the my-firmware image
+ * by calling this function with @prop_name set to "some-firmware". This
+ * function also verifies the image data (if enabled) before returning. The
+ * image description is printed out on success. @data and @size will not be
+ * modified on faulure.
+ *
+ * Return:
+ * * 0 on success
+ * * -EINVAL

[RESEND PATCH v2 3/6] ARMv8/sec_firmware: Convert to use fit_get_data_conf_prop

2022-08-16 Thread Sean Anderson
This reduces sec_firmware_get_data to a single call to
fit_get_data_conf_prop. I think sec_firmware_check_copy_loadable could also
be converted, but it does not map as straightforwardly, so I have left it
for a future cleanup.

Signed-off-by: Sean Anderson 
---

Changes in v2:
- New

 arch/arm/cpu/armv8/sec_firmware.c | 39 ++-
 1 file changed, 2 insertions(+), 37 deletions(-)

diff --git a/arch/arm/cpu/armv8/sec_firmware.c 
b/arch/arm/cpu/armv8/sec_firmware.c
index bbd3f2dca25..540436ba028 100644
--- a/arch/arm/cpu/armv8/sec_firmware.c
+++ b/arch/arm/cpu/armv8/sec_firmware.c
@@ -43,43 +43,8 @@ phys_addr_t sec_firmware_addr;
 static int sec_firmware_get_data(const void *sec_firmware_img,
const void **data, size_t *size)
 {
-   int conf_node_off, fw_node_off;
-   char *desc;
-   int ret;
-
-   conf_node_off = fit_conf_get_node(sec_firmware_img, NULL);
-   if (conf_node_off < 0) {
-   puts("SEC Firmware: no config\n");
-   return -ENOENT;
-   }
-
-   fw_node_off = fit_conf_get_prop_node(sec_firmware_img, conf_node_off,
-   SEC_FIRMWARE_FIT_IMAGE);
-   if (fw_node_off < 0) {
-   printf("SEC Firmware: No '%s' in config\n",
-  SEC_FIRMWARE_FIT_IMAGE);
-   return -ENOLINK;
-   }
-
-   /* Verify secure firmware image */
-   if (!(fit_image_verify(sec_firmware_img, fw_node_off))) {
-   printf("SEC Firmware: Bad firmware image (bad CRC)\n");
-   return -EINVAL;
-   }
-
-   if (fit_image_get_data(sec_firmware_img, fw_node_off, data, size)) {
-   printf("SEC Firmware: Can't get %s subimage data/size",
-  SEC_FIRMWARE_FIT_IMAGE);
-   return -ENOENT;
-   }
-
-   ret = fit_get_desc(sec_firmware_img, fw_node_off, &desc);
-   if (ret)
-   printf("SEC Firmware: Can't get description\n");
-   else
-   printf("%s\n", desc);
-
-   return ret;
+   return fit_get_data_conf_prop(sec_firmware_img, SEC_FIRMWARE_FIT_IMAGE,
+ data, size);
 }
 
 /*
-- 
2.35.1.1320.gc452695387.dirty



[RESEND PATCH v2 0/6] net: fm: Verify Fman microcode

2022-08-16 Thread Sean Anderson
Surprisingly, Fman microcode does not seem to be verified. This series
aims to rectify this by introducing an optional FIT wrapper. This
wrapper is made mandatory if FIT_SIGNATURE is enabled. NXP boards do not
use this config, so the microcode will remain unverified for them. This
is OK, since we do not want to break existing systems.

This series depends on [1]. There is no logical dependency, but they
modify adjacent #includes, so the past patch will not apply cleanly
unless that series is applied.

[1] 
https://lore.kernel.org/u-boot/20220422173032.2259019-1-sean.ander...@seco.com/

Changes in v2:
- Document helpers
- Split off Fman microcode verification patches into their own series
- Split helper refactoring into a patch adding the helpers and one patch
  per subsystem.

Sean Anderson (6):
  ARMv8/sec_firmware: Remove SEC_FIRMWARE_FIT_CNF_NAME
  image: fit: Add some helpers for getting data
  ARMv8/sec_firmware: Convert to use fit_get_data_conf_prop
  cmd: fpga: Convert to use fit_get_data_node
  net: Convert fit verification to use fit_get_data_*
  net: fm: Add support for FIT firmware

 arch/arm/cpu/armv8/sec_firmware.c  | 52 ++
 boot/image-fit.c   | 37 
 cmd/fpga.c | 24 +++---
 drivers/net/fm/fm.c| 18 
 drivers/net/fsl-mc/mc.c| 30 ++---
 drivers/net/pfe_eth/pfe_firmware.c | 40 +
 include/image.h| 70 ++
 7 files changed, 139 insertions(+), 132 deletions(-)

-- 
2.35.1.1320.gc452695387.dirty



[RESEND PATCH v2 1/6] ARMv8/sec_firmware: Remove SEC_FIRMWARE_FIT_CNF_NAME

2022-08-16 Thread Sean Anderson
The config to use for FIT images can be better specified by enabling
CONFIG_MULTI_DTB_FIT and implementing board_fit_config_name_match.

Signed-off-by: Sean Anderson 
---

(no changes since v1)

 arch/arm/cpu/armv8/sec_firmware.c | 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/arch/arm/cpu/armv8/sec_firmware.c 
b/arch/arm/cpu/armv8/sec_firmware.c
index 7e6e4064ffe..bbd3f2dca25 100644
--- a/arch/arm/cpu/armv8/sec_firmware.c
+++ b/arch/arm/cpu/armv8/sec_firmware.c
@@ -36,9 +36,6 @@ phys_addr_t sec_firmware_addr;
 #ifndef SEC_FIRMWARE_FIT_IMAGE
 #define SEC_FIRMWARE_FIT_IMAGE "firmware"
 #endif
-#ifndef SEC_FIRMWARE_FIT_CNF_NAME
-#define SEC_FIRMWARE_FIT_CNF_NAME  "config-1"
-#endif
 #ifndef SEC_FIRMWARE_TARGET_EL
 #define SEC_FIRMWARE_TARGET_EL 2
 #endif
@@ -47,15 +44,12 @@ static int sec_firmware_get_data(const void 
*sec_firmware_img,
const void **data, size_t *size)
 {
int conf_node_off, fw_node_off;
-   char *conf_node_name = NULL;
char *desc;
int ret;
 
-   conf_node_name = SEC_FIRMWARE_FIT_CNF_NAME;
-
-   conf_node_off = fit_conf_get_node(sec_firmware_img, conf_node_name);
+   conf_node_off = fit_conf_get_node(sec_firmware_img, NULL);
if (conf_node_off < 0) {
-   printf("SEC Firmware: %s: no such config\n", conf_node_name);
+   puts("SEC Firmware: no config\n");
return -ENOENT;
}
 
@@ -124,18 +118,15 @@ static int sec_firmware_check_copy_loadable(const void 
*sec_firmware_img,
 {
phys_addr_t sec_firmware_loadable_addr = 0;
int conf_node_off, ld_node_off, images;
-   char *conf_node_name = NULL;
const void *data;
size_t size;
ulong load;
const char *name, *str, *type;
int len;
 
-   conf_node_name = SEC_FIRMWARE_FIT_CNF_NAME;
-
-   conf_node_off = fit_conf_get_node(sec_firmware_img, conf_node_name);
+   conf_node_off = fit_conf_get_node(sec_firmware_img, NULL);
if (conf_node_off < 0) {
-   printf("SEC Firmware: %s: no such config\n", conf_node_name);
+   puts("SEC Firmware: no config\n");
return -ENOENT;
}
 
-- 
2.35.1.1320.gc452695387.dirty



Re: [PATCH v4 6/9] sandbox: Add cyclic demo function

2022-08-16 Thread Stefan Roese

Hi Simon,

On 16.08.22 13:48, Simon Glass wrote:

Hi Stefan,

On Tue, 16 Aug 2022 at 04:28, Stefan Roese  wrote:


This patch enables the cyclic infrastructure on sandbox and also adds
one simple example/demo functions using this cyclic functionality.

Signed-off-by: Stefan Roese 
---
v4:
- Rename cyclic_struct to cyclic_info

v3:
- No change

v2:
- Extend CONFIG_CYCLIC_MAX_CPU_TIME_US to 1ms as running this
   in CI might take a bit longer

  board/sandbox/sandbox.c   | 15 +++
  configs/sandbox_defconfig |  3 +++
  2 files changed, 18 insertions(+)


Now that we have the test, do we need this?


Frankly, I did not think about this before.


Or perhaps it should be a
'cyclic demo' command?


Yes, this could make sense, if we drop this sandbox implementation.
Let me think a bit about it...

Thanks,
Stefan



diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c
index ca9a2ca5b17c..f633b8e63768 100644
--- a/board/sandbox/sandbox.c
+++ b/board/sandbox/sandbox.c
@@ -7,6 +7,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -17,6 +18,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 

@@ -106,8 +108,21 @@ int dram_init(void)
 return 0;
  }

+static void cyclic_demo(void *ctx)
+{
+   /* Just a small dummy delay here */
+   udelay(10);
+}
+
  int board_init(void)
  {
+   struct cyclic_info *cyclic;
+
+   /* Register demo cyclic function */
+   cyclic = cyclic_register(cyclic_demo, 10 * 1000, "cyclic_demo", NULL);
+   if (!cyclic)
+   printf("Registering of cyclic_demo failed\n");
+
 return 0;
  }

diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index eba7bcbb483b..8b6c003760f2 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -34,6 +34,8 @@ CONFIG_LOG=y
  CONFIG_LOG_MAX_LEVEL=9
  CONFIG_LOG_DEFAULT_LEVEL=6
  CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_CYCLIC=y
+CONFIG_CYCLIC_MAX_CPU_TIME_US=1
  CONFIG_STACKPROTECTOR=y
  CONFIG_ANDROID_AB=y
  CONFIG_CMD_CPU=y
@@ -114,6 +116,7 @@ CONFIG_CMD_EROFS=y
  CONFIG_CMD_EXT4_WRITE=y
  CONFIG_CMD_SQUASHFS=y
  CONFIG_CMD_MTDPARTS=y
+CONFIG_CMD_CYCLIC=y
  CONFIG_CMD_STACKPROTECTOR_TEST=y
  CONFIG_MAC_PARTITION=y
  CONFIG_AMIGA_PARTITION=y
--
2.37.2



Regards,
Simon


Viele Grüße,
Stefan Roese

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


Re: [PATCH v3 1/3] Convert CONFIG_SYS_L2_PL310 to Kconfig

2022-08-16 Thread Philip Oberfichtner
Just for the record: I solved the problem using

./tools/moveconfig.py -i CONFIG_SYS_L2_PL310

Patch V4 coming soon.


On Thu, 2022-08-11 at 12:17 +0200, Philip Oberfichtner wrote:
> Hi,
> 
> following the whole discussion I figured using 'select SYS_l2_PL310
> if
> !SYS_L2CACHE_OFF' is the preferred solution.
> 
> Now the thing is, if I'd put this line under the ARCH_XXX Kconfig
> entries, I would change behavior for many boards. Take, for example,
> ARCH_MVEBU:
> 
> grep -lr ARCH_MVEBU configs | ./tools/moveconfig.py -d-
> CONFIG_SYS_L2_PL310
> 
> Tells me that there are 30 ARCH_MVEBU defconfigs, of which 19 use
> CONFIG_SYS_L2_PL310 and 11 don't. Those 11 boards not using it also
> do
> not define CONFIG_SYS_L2CACHE_OFF. So using a 'select SYS_L2_PL310'
> under ARCH_MVEBU would change behavior for those 11 boards.
> 
> There is a similar picture for other architectures, like SOCFPGA or
> OMAP2. The only place where selecting based on CONFIG_ARCH does not
> change behavior is ARCH_MX6, when excluding CONFIG_MX6UL(L).
> 
> If I didn't miss something here, there's no easy way out. Maybe to
> define SYS_L2CACHE_OFF for respective boards would be an option, but
> I
> don't know if there would be side effects.
> 
> Any other suggestions?
> 
> Best regards,
> Philip



Re: [PATCH] drivers: tee: i2c: support the NXP SE05x probe errata

2022-08-16 Thread Oleksandr Suvorov
Hi Jorge,

On Tue, Aug 16, 2022 at 2:28 PM Jorge Ramirez-Ortiz  wrote:
>
> Early instantiation of this I2C device would lock up when being
> probed.
>
> Signed-off-by: Jorge Ramirez-Ortiz 

With a small note below,
Acked-by: Oleksandr Suvorov 

> ---
>  drivers/tee/optee/Kconfig | 14 +
>  drivers/tee/optee/i2c.c   | 44 +++
>  2 files changed, 54 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
> index d03028070b..05dfe2c9a8 100644
> --- a/drivers/tee/optee/Kconfig
> +++ b/drivers/tee/optee/Kconfig
> @@ -37,6 +37,20 @@ config OPTEE_TA_SCP03
> help
>   Enables support for controlling (enabling, provisioning) the
>   Secure Channel Protocol 03 operation in the OP-TEE SCP03 TA.
> +
> +config TEE_I2C_NXP_SE05X_ERRATA
> +   bool "Enable NXP SE05X Errata"
> +   select TEE_I2C_NXP_SE05X_ERRATA_IN_BUS
> +   default y

I doubt this should be enabled by default.

> +   help
> + This config prevents the I2C trampoline driver from probing
> + on every transfer.
> +
> +config TEE_I2C_NXP_SE05X_ERRATA_IN_BUS
> +   int "I2C bus where to apply the NXP SE05X errata"
> +   depends on TEE_I2C_NXP_SE05X_ERRATA
> +   default 0
> +
>  endmenu
>
>  endif
> diff --git a/drivers/tee/optee/i2c.c b/drivers/tee/optee/i2c.c
> index ef4e10f991..a3ea34d4a2 100644
> --- a/drivers/tee/optee/i2c.c
> +++ b/drivers/tee/optee/i2c.c
> @@ -3,13 +3,18 @@
>   * Copyright (c) 2020 Foundries.io Ltd
>   */
>
> +#define LOG_CATEGORY UCLASS_I2C
> +
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "optee_msg.h"
>  #include "optee_private.h"
>
> +#define NXP_SE05X_ADDR 0x48
> +
>  static int check_xfer_flags(struct udevice *chip, uint tee_flags)
>  {
> uint flags;
> @@ -30,6 +35,30 @@ static int check_xfer_flags(struct udevice *chip, uint 
> tee_flags)
> return 0;
>  }
>
> +static struct udevice *get_chip_dev(int bnum, int addr)
> +{
> +   struct udevice *chip;
> +   struct udevice *bus;
> +
> +   if (IS_ENABLED(CONFIG_TEE_I2C_NXP_SE05X_ERRATA)) {
> +   if (bnum == CONFIG_TEE_I2C_NXP_SE05X_ERRATA_IN_BUS &&
> +   addr == NXP_SE05X_ADDR) {
> +   if (uclass_get_device_by_seq(UCLASS_I2C, bnum, &bus))
> +   return NULL;
> +
> +   if (i2c_get_chip(bus, addr, 0, &chip))
> +   return NULL;
> +
> +   return chip;
> +   }
> +   }
> +
> +   if (i2c_get_chip_for_busnum(bnum, addr, 0, &chip))
> +   return NULL;
> +
> +   return chip;
> +}
> +
>  void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg *arg)
>  {
> const u8 attr[] = {
> @@ -38,7 +67,8 @@ void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg *arg)
> OPTEE_MSG_ATTR_TYPE_RMEM_INOUT,
> OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT,
> };
> -   struct udevice *chip_dev;
> +   struct udevice *chip_dev = NULL;
> +
> struct tee_shm *shm;
> u8 *buf;
> int ret;
> @@ -56,9 +86,9 @@ void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg *arg)
> if (!buf)
> goto bad;
>
> -   if (i2c_get_chip_for_busnum((int)arg->params[0].u.value.b,
> -   (int)arg->params[0].u.value.c,
> -   0, &chip_dev))
> +   chip_dev = get_chip_dev((int)arg->params[0].u.value.b,
> +   (int)arg->params[0].u.value.c);
> +   if (!chip_dev)
> goto bad;
>
> if (check_xfer_flags(chip_dev, arg->params[1].u.value.a))
> @@ -66,10 +96,16 @@ void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg 
> *arg)
>
> switch (arg->params[0].u.value.a) {
> case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD:
> +   log_debug("OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD %d\n",
> + (size_t)arg->params[2].u.rmem.size);
> +
> ret = dm_i2c_read(chip_dev, 0, buf,
>   (size_t)arg->params[2].u.rmem.size);
> break;
> case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR:
> +   log_debug("OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR %d\n",
> + (size_t)arg->params[2].u.rmem.size);
> +
> ret = dm_i2c_write(chip_dev, 0, buf,
>(size_t)arg->params[2].u.rmem.size);
> break;
> --
> 2.34.1
>


-- 
Best regards
Oleksandr

Oleksandr Suvorov
cryo...@gmail.com


Re: [RFC PATCH v2 9/9] tools: spkgimage: add Renesas SPKG format

2022-08-16 Thread Ralph Siemsen
Hi Sean,

I've implemented most of the suggestions. I will post an updated
series, since it seems that sending v2 of just one patch has confused
patchwork.

However so as not to entirely remove confusion, the updated series
will be v3, since I already used v2 for the one patch. :-P

On Sat, Aug 13, 2022 at 9:45 PM Ralph Siemsen  wrote:
> >
> > I wonder if you could just fill in the header directly. This is
> > for a userspace tool, and this struct will be created at most
> > once. It's OK to use 10 bytes :)
>
> I could fill the header directly, but I figured it would be cleaner to
> keep the config file parsing separate from header generation.

Does it seem reasonable to keep these structures separated?

> > > +static int spkgimage_verify_header(unsigned char *ptr, int size,
> > > +struct image_tool_params *param)
> > > +{
> > > + struct spkg_file *file = (struct spkg_file *)ptr;
> > > + struct spkg_hdr *header = (struct spkg_hdr *)ptr;
> > > + char signature[4] = SPKG_HEADER_SIGNATURE;
> >
> > If this naming does not come from documentation, I would suggest
> > something like SPKG_HEADER_MAGIC, since this is not a signature,
> > or even a CRC.
>
> The name does in fact come from the RZ/N1 documentation. However I
> agree that SPKG_HEADER_MAGIC would better reflect what these bytes
> actually are.

Upon checking the documentation, it turns out they use the term
"marker" rather than "signature" for these bytes. So I have switched
the code to match.

> > > +static int spkgimage_check_image_types(uint8_t type)
> > > +{
> > > + return type == IH_TYPE_RENESAS_SPKG ? 0 : 1;
> >
> > This function is not necessary if you only support one type.
>
> Without this function, mkimage kept telling me that my format
> (spkgimage) was not supported, and none of my callbacks got invoked.
> It only complained when trying to generate a header. When listing the
> supported formats, spkgimage showed up correctly.
>
> I'll take another look on Monday, maybe I missed something obvious.

I have re-checked this:
- without the function, mkimage complains that spkgimage is unknown
- with a function that unconditionally returns 0, it works fine

If it really is meant to work without the function, then a bug must
have crept in elsewhere...

Regards,
-Ralph


Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf

2022-08-16 Thread Matwey V. Kornilov
I cannot understand what is going on. As far as I understand, read
consists of i2c write of address and subsequent i2c read of data.
During the i2c write process, EEPROM handles ACK/NOACK and - since
there is no error code - the EEPROM handles i2c write correctly. And
then it looks like no EEPROM device during the i2c read stage.

вт, 16 авг. 2022 г. в 04:27, Nishanth Menon :
>
> On 23:32-20220815, Matwey V. Kornilov wrote:
> > Only the first one dm_i2c_read is successful, whenever the size value.
>
> I wonder if we need to add complete ep read... this is what I see on my
> element 14 board:
> 
> ti_i2c_eeprom_get: 98: rc=0 header=0xee3355aa
> ti_i2c_eeprom_get: 102: rc=0
> ti_i2c_eeprom_get: 110: rc=0
> ti_i2c_eeprom_get: 121: header=0x rc=0
> ti_i2c_eeprom_get: 130: rc=0
> ti_i2c_eeprom_get: 135: rc=0
> ti_i2c_eeprom_get: 139: header=0xee3355aa
> ti_i2c_eeprom_get: 144: rc=0
> ep[0]=0xaa
> ep[1]=0x55
> ep[2]=0x33
> ep[3]=0xee
> ep[4]=0x41
> ep[5]=0x33
> ep[6]=0x33
> ep[7]=0x35
> ep[8]=0x42
> ep[9]=0x4e
> ep[10]=0x4c
> ep[11]=0x54
> ep[12]=0x30
> ep[13]=0x30
> ep[14]=0x43
> ep[15]=0x30
> ep[16]=0x34
> ep[17]=0x31
> ep[18]=0x34
> ep[19]=0x42
> ep[20]=0x42
> ep[21]=0x42
> ep[22]=0x4b
> ep[23]=0x30
> ep[24]=0x31
> ep[25]=0x36
> ep[26]=0x37
> ep[27]=0xff
> ep[28]=0xff
> ep[29]=0xff
> ep[30]=0xff
> ep[31]=0xff
> ep[32]=0xff
> ep[33]=0xff
> ep[34]=0xff
> ep[35]=0xff
> ep[36]=0xff
> ep[37]=0xff
> ep[38]=0xff
> ep[39]=0xff
> ep[40]=0xff
> ep[41]=0xff
> ep[42]=0xff
> ep[43]=0xff
> ep[44]=0xff
> ep[45]=0xff
> ep[46]=0xff
> ep[47]=0xff
> ep[48]=0xff
> ep[49]=0xff
> ep[50]=0xff
> ep[51]=0xff
> ep[52]=0xff
> ep[53]=0xff
> ep[54]=0xff
> ep[55]=0xff
> ep[56]=0xff
> ep[57]=0xff
> ep[58]=0xff
> ep[59]=0xff
> ep[60]=0xff
> ep[61]=0xff
> ep[62]=0xff
> ep[63]=0xff
> ep[64]=0xff
> ep[65]=0xff
> ep[66]=0xff
> ep[67]=0xff
> ep[68]=0xff
> ep[69]=0xff
> ep[70]=0xff
> ep[71]=0xff
> ep[72]=0xff
> ep[73]=0xff
> ep[74]=0xff
> ep[75]=0xff
> ep[76]=0xff
> ep[77]=0xff
> ti_i2c_eeprom_get: 195: Out OK
>
> U-Boot SPL 2022.10-rc2-00030-g29d075bc05ca-dirty (Aug 15 2022 - 14:50:17 
> -0500)
> Trying to boot from MMC1
>
>
> U-Boot 2022.10-rc2-00030-g29d075bc05ca-dirty (Aug 15 2022 - 14:50:17 -0500)
>
> CPU  : AM335X-GP rev 2.1
> Model: TI AM335x BeagleBone Black
> DRAM:  512 MiB
> Core:  160 devices, 18 uclasses, devicetree: separate
> WDT:   Started wdt@44e35000 with servicing (60s timeout)
> NAND:  0 MiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
>  not set. Validating first E-fuse MAC
> Net:   eth2: ethernet@4a10, eth3: usb_ether
> Hit any key to stop autoboot:  0
> =>
>
> >
> > пн, 15 авг. 2022 г. в 23:21, Matwey V. Kornilov :
> > >
> > > I have one idea. I'll try dm_i2c_read() with different `size' argument
> > > values tomorrow.
> > >
> > > пн, 15 авг. 2022 г. в 23:13, Matwey V. Kornilov 
> > > :
> > > >
> > > > пн, 15 авг. 2022 г. в 22:56, Nishanth Menon :
> > > > >
> > > > > On 21:12-20220815, Matwey V. Kornilov wrote:
> > > > > []
> > > > >
> > > > > Trying offline for now (I am also on libera.chat #linux-ti and 
> > > > > #u-boot)..
> > > > >
> > > > > >
> > > > > > 
> > > > > > ti_i2c_eeprom_get: 98: rc=0 header=0xee3355aa
> > > > > > ti_i2c_eeprom_get: 102: rc=0
> > > > > > ti_i2c_eeprom_get: 110: rc=0
> > > > > > ti_i2c_eeprom_get: 121: header=0xee3355aa
> > > > > > ti_i2c_eeprom_get: 139: header=0xee3355aa
> > > > > > ti_i2c_eeprom_get: 144: rc=0
> > > > > > ep[0]=0xff
> > > > >
> > > > > gaah... data seems stuck... with one more potential fixup... Dont know
> > > > > how this might behave..
> > > >
> > > > ti_i2c_eeprom_get: 121: header=0xee3355aa rc=0
> > > >
> > > > >
> > > > > main change is this:
> > > > > @@ -113,33 +117,42 @@ static int __maybe_unused ti_i2c_eeprom_get(int 
> > > > > bus_addr, int dev_addr,
> > > > >  * We must allow for fall through to check the data if 2 byte
> > > > >  * addressing works
> > > > >  */
> > > > > -   (void)dm_i2c_read(dev, 0, (uint8_t *)&hdr_read, 4);
> > > > > +   rc = dm_i2c_read(dev, 0, (uint8_t *)&hdr_read, 4);
> > > > > +   printf("%s: %d: header=0x%08x rc=%d\n", __func__, __LINE__, 
> > > > > hdr_read, rc);
> > > > >
> > > > > /* Corrupted data??? */
> > > > > -   if (hdr_read != header) {
> > > > > +   if (rc || hdr_read != header) {
> > > > >
> > > > > 8<---
> > > > > diff --git a/board/ti/common/board_detect.c 
> > > > > b/board/ti/common/board_detect.c
> > > > > index ed34991377ee..f4e5da34b70a 100644
> > > > > --- a/board/ti/common/board_detect.c
> > > > > +++ b/board/ti/common/board_detect.c
> > > > > @@ -90,13 +90,16 @@ static int __maybe_unused ti_i2c_eeprom_get(int 
> > > > > bus_addr, int dev_addr,
> > > > > int rc;
> > > > >
> > > > >  #if CONFIG_IS_ENABLED(DM_I2C)
> > > > > +   int i;
> > > > > struct udevice *dev;
> > > > > struct udevice *bus;
> > > > >
> > > > > rc = uclass_get_device_by_seq(U

Re: [PATCH v2 2/7] tpm: Correct the permissions command in TPMv1

2022-08-16 Thread Ilias Apalodimas
Hi Simon

On Sat, 13 Aug 2022 at 22:56, Simon Glass  wrote:
>
> The offset here is incorrect. Fix it.

Since we got it wrong the first time, any chance you can give me a
link to the spec describing these offsets (both for this and the
subsequent patch)

Thanks
/Ilias
>
> Signed-off-by: Simon Glass 
> ---
>
> (no changes since v1)
>
>  lib/tpm-v1.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/lib/tpm-v1.c b/lib/tpm-v1.c
> index 22a769c5874..d0e3ab1b21d 100644
> --- a/lib/tpm-v1.c
> +++ b/lib/tpm-v1.c
> @@ -456,12 +456,13 @@ u32 tpm1_get_permissions(struct udevice *dev, u32 
> index, u32 *perm)
> 0x0, 0x0, 0x0, 0x4,
> };
> const size_t index_offset = 18;
> -   const size_t perm_offset = 60;
> +   const size_t perm_offset = 74;
> u8 buf[COMMAND_BUFFER_SIZE], response[COMMAND_BUFFER_SIZE];
> size_t response_length = sizeof(response);
> u32 err;
>
> -   if (pack_byte_string(buf, sizeof(buf), "d", 0, command, 
> sizeof(command),
> +   if (pack_byte_string(buf, sizeof(buf), "sd",
> +0, command, sizeof(command),
>  index_offset, index))
> return TPM_LIB_ERROR;
> err = tpm_sendrecv_command(dev, buf, response, &response_length);
> --
> 2.37.1.595.g718a3a8f04-goog
>


Re: [PATCH v2 7/7] tpm: Allow committing non-volatile data

2022-08-16 Thread Ilias Apalodimas
Hi Simon,

On Sat, 13 Aug 2022 at 22:56, Simon Glass  wrote:
>
> Add an option to tell the TPM to commit non-volatile data immediately it
> is changed, rather than waiting until later. This is needed in some
> situations, since if the device reboots it may not write the data.

Similar to the previous patch, I think this is fine, but the functions
don't belong to the generic TPM API

Regards
/Ilias
>
> Add definitions for the rest of the Cr50 commands while we are here.
>
> Signed-off-by: Simon Glass 
> ---
>
> (no changes since v1)
>
>  include/tpm-v2.h | 14 ++
>  lib/tpm-v2.c | 20 
>  2 files changed, 34 insertions(+)
>
> diff --git a/include/tpm-v2.h b/include/tpm-v2.h
> index 8e90a616220..0a03994740d 100644
> --- a/include/tpm-v2.h
> +++ b/include/tpm-v2.h
> @@ -712,4 +712,18 @@ u32 tpm2_submit_command(struct udevice *dev, const u8 
> *sendbuf,
>   */
>  u32 tpm2_cr50_report_state(struct udevice *dev, u8 *recvbuf, size_t 
> *recv_size);
>
> +/*
> + * tpm2_cr50_enable_nvcommits() - Tell Cr50 to commit NV data immediately
> + *
> + * For Chromium OS verified boot, we may reboot or reset at different times,
> + * possibly leaving non-volatile data unwritten by the TPM.
> + *
> + * This vendor command is used to indicate that non-volatile data should be
> + * written to its store immediately.
> + *
> + * @devTPM device
> + * Return: result of the operation
> + */
> +u32 tpm2_cr50_enable_nvcommits(struct udevice *dev);
> +
>  #endif /* __TPM_V2_H */
> diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
> index 3de4841974a..d68c311651b 100644
> --- a/lib/tpm-v2.c
> +++ b/lib/tpm-v2.c
> @@ -703,3 +703,23 @@ u32 tpm2_cr50_report_state(struct udevice *dev, u8 
> *recvbuf, size_t *recv_size)
>
> return 0;
>  }
> +
> +u32 tpm2_cr50_enable_nvcommits(struct udevice *dev)
> +{
> +   u8 command_v2[COMMAND_BUFFER_SIZE] = {
> +   /* header 10 bytes */
> +   tpm_u16(TPM2_ST_NO_SESSIONS),   /* TAG */
> +   tpm_u32(10 + 2),/* Length */
> +   tpm_u32(TPM2_CR50_VENDOR_COMMAND),  /* Command code */
> +
> +   tpm_u16(TPM2_CR50_SUB_CMD_NVMEM_ENABLE_COMMITS),
> +   };
> +   int ret;
> +
> +   ret = tpm_sendrecv_command(dev, command_v2, NULL, NULL);
> +   log_debug("ret=%s, %x\n", dev->name, ret);
> +   if (ret)
> +   return ret;
> +
> +   return 0;
> +}
> --
> 2.37.1.595.g718a3a8f04-goog
>


Re: [PATCH 0/3] Introduce new sign binman's option

2022-08-16 Thread Ivan Mikhaylov
On Sat, 2022-08-13 at 08:59 -0600, Simon Glass wrote:
> Hi Ivan,
> 
> On Mon, 21 Mar 2022 at 12:43, Ivan Mikhaylov 
> wrote:
> > 
> > From: Ivan Mikhaylov 
> > 
> > This patch introduces prototype of new sign binman's option.
> > Enhancing the sign procedure, as example:
> > 
> > mkimage -G privateky -r -o sha256,rsa4096 -F fit.fit
> > binman replace -i flash.bin -f fit.fit fit
> > 
> > into:
> > binman sign -i flash.bin -k privatekey -a sha256,rsa4096 -f fit.fit
> > fit
> > 
> > It works with extracted FIT container and image, which provides key
> > signing
> > and replacing FIT container in directed image.
> > 
> > Also, I'll add additional enhancement in future to this procedure
> > with
> > skipping on FIT container and providing extract->sign->replace in
> > whole
> > instead of sign->replace with documentation update and test as
> > well.
> > 
> > As example:
> > 
> > binman sign -i flash.bin -k privatekey -a sha256,rsa4096 -f fit
> > 
> > 
> > Ivan Mikhaylov (3):
> >   binman: add sign option for binman
> >   binman: add documentation for binman sign option
> >   binman: add test for sign option
> > 
> >  tools/binman/binman.rst    | 10 +
> >  tools/binman/cmdline.py    | 13 ++
> >  tools/binman/control.py    | 26 +++-
> >  tools/binman/ftest.py  | 42 +++
> >  tools/binman/test/225_fit_sign.dts | 67
> > ++
> >  5 files changed, 157 insertions(+), 1 deletion(-)
> >  create mode 100644 tools/binman/test/225_fit_sign.dts
> 
> I see Alper's comments. Are you going to send a new version sometime?
> 
> Regards,
> Simon

Simon, totally forgot about this one, sorry for long delay. Yes, I'll
back to it at the end of this month/start of september.

Thanks.


Re: [PATCH v2 6/7] tpm: Implement state command for Cr50

2022-08-16 Thread Ilias Apalodimas
Hi Simon,

I know little of this device and the whole patch seems fine apart from
the definitions and declarations of the state functions.


On Sat, 13 Aug 2022 at 22:56, Simon Glass  wrote:
>

>
>  drivers/tpm/cr50_i2c.c | 117 +
>  include/tpm-v2.h   |  54 +++
>  lib/tpm-v2.c   |  24 +

[...]

> diff --git a/include/tpm-v2.h b/include/tpm-v2.h
> index e79c90b9395..8e90a616220 100644
> --- a/include/tpm-v2.h
> +++ b/include/tpm-v2.h
> @@ -419,6 +419,50 @@ enum {
> HR_NV_INDEX = TPM_HT_NV_INDEX << HR_SHIFT,
>  };
>
> +/*
> + * Operations specific to the Cr50 TPM used on Chromium OS and Android 
> devices
> + *
> + * FIXME: below is not enough to differentiate between vendors commands
> + * of numerous devices. However, the current tpm2 APIs aren't very amenable
> + * to extending generically because the marshaling code is assuming all
> + * knowledge of all commands.
> + */
> +#define TPM2_CC_VENDOR_BIT_MASK0x2000
> +
> +#define TPM2_CR50_VENDOR_COMMAND   (TPM2_CC_VENDOR_BIT_MASK | 0)
> +#define TPM2_CR50_SUB_CMD_IMMEDIATE_RESET  19
> +#define TPM2_CR50_SUB_CMD_NVMEM_ENABLE_COMMITS 21
> +#define TPM2_CR50_SUB_CMD_REPORT_TPM_STATE 23
> +#define TPM2_CR50_SUB_CMD_TURN_UPDATE_ON   24
> +#define TPM2_CR50_SUB_CMD_GET_REC_BTN  29
> +#define TPM2_CR50_SUB_CMD_TPM_MODE 40
> +#define TPM2_CR50_SUB_CMD_GET_BOOT_MODE52
> +#define TPM2_CR50_SUB_CMD_RESET_EC 53
> +
> +/* Cr50 vendor-specific error codes. */
> +#define VENDOR_RC_ERR  0x0500
> +enum cr50_vendor_rc {
> +   VENDOR_RC_INTERNAL_ERROR= (VENDOR_RC_ERR | 6),
> +   VENDOR_RC_NO_SUCH_SUBCOMMAND= (VENDOR_RC_ERR | 8),
> +   VENDOR_RC_NO_SUCH_COMMAND   = (VENDOR_RC_ERR | 127),
> +};
> +
> +enum cr50_tpm_mode {
> +   /*
> +* Default state: TPM is enabled, and may be set to either
> +* TPM_MODE_ENABLED or TPM_MODE_DISABLED.
> +*/
> +   TPM_MODE_ENABLED_TENTATIVE = 0,
> +
> +   /* TPM is enabled, and mode may not be changed. */
> +   TPM_MODE_ENABLED = 1,
> +
> +   /* TPM is disabled, and mode may not be changed. */
> +   TPM_MODE_DISABLED = 2,
> +
> +   TPM_MODE_INVALID,
> +};
> +
>  /**
>   * Issue a TPM2_Startup command.
>   *
> @@ -658,4 +702,14 @@ u32 tpm2_disable_platform_hierarchy(struct udevice *dev);
>  u32 tpm2_submit_command(struct udevice *dev, const u8 *sendbuf,
> u8 *recvbuf, size_t *recv_size);
>
> +/**
> + * tpm_cr50_report_state() - Report the Cr50 internal state
> + *
> + * @dev:   TPM device
> + * @recvbuf:   Buffer to save the response to
> + * @recv_size: Pointer to the size of the response buffer
> + * Return: result of the operation
> + */
> +u32 tpm2_cr50_report_state(struct udevice *dev, u8 *recvbuf, size_t 
> *recv_size);
> +

I think we should keep the generic include files clean for hardware
specific details.

>  #endif /* __TPM_V2_H */
> diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
> index 3e240bb4c67..3de4841974a 100644
> --- a/lib/tpm-v2.c
> +++ b/lib/tpm-v2.c
> @@ -679,3 +679,27 @@ u32 tpm2_submit_command(struct udevice *dev, const u8 
> *sendbuf,
>  {
> return tpm_sendrecv_command(dev, sendbuf, recvbuf, recv_size);
>  }
> +
> +u32 tpm2_cr50_report_state(struct udevice *dev, u8 *recvbuf, size_t 
> *recv_size)
> +{
> +   u8 command_v2[COMMAND_BUFFER_SIZE] = {
> +   /* header 10 bytes */
> +   tpm_u16(TPM2_ST_NO_SESSIONS),   /* TAG */
> +   tpm_u32(10 + 2),/* Length */
> +   tpm_u32(TPM2_CR50_VENDOR_COMMAND),  /* Command code */
> +
> +   tpm_u16(TPM2_CR50_SUB_CMD_REPORT_TPM_STATE),
> +   };
> +   int ret;
> +
> +   ret = tpm_sendrecv_command(dev, command_v2, recvbuf, recv_size);
> +   log_debug("ret=%s, %x\n", dev->name, ret);
> +   if (ret)
> +   return ret;
> +   if (*recv_size < 12)
> +   return -ENODATA;
> +   *recv_size -= 12;
> +   memcpy(recvbuf, recvbuf + 12, *recv_size);
> +
> +   return 0;
> +}

Same here, this functions seems ok but shouldn't land in the generic TPM API

Thanks
/Ilias
> --
> 2.37.1.595.g718a3a8f04-goog
>


Re: [PATCH v4 9/9] cyclic: Add a simple test

2022-08-16 Thread Stefan Roese

Hi Simon,

On 16.08.22 13:48, Simon Glass wrote:

On Tue, 16 Aug 2022 at 04:28, Stefan Roese  wrote:


Add a test for cyclic function registration and activation.

Signed-off-by: Stefan Roese 
---
v4:
- New patch

  test/common/Makefile |  1 +
  test/common/cyclic.c | 31 +++
  test/test-main.c |  3 +++
  3 files changed, 35 insertions(+)
  create mode 100644 test/common/cyclic.c


Reviewed-by: Simon Glass 



diff --git a/test/common/Makefile b/test/common/Makefile
index 9087788ba6a8..cc918f64e544 100644
--- a/test/common/Makefile
+++ b/test/common/Makefile
@@ -1,4 +1,5 @@
  # SPDX-License-Identifier: GPL-2.0+
  obj-y += cmd_ut_common.o
  obj-$(CONFIG_AUTOBOOT) += test_autoboot.o
+obj-$(CONFIG_CYCLIC) += cyclic.o
  obj-$(CONFIG_EVENT) += event.o
diff --git a/test/common/cyclic.c b/test/common/cyclic.c
new file mode 100644
index ..58f1603137e9
--- /dev/null
+++ b/test/common/cyclic.c
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2022 Stefan Roese 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Test that cyclic function is called */
+static bool cyclic_active = false;
+
+static void cyclic_test(void *ctx)
+{
+   cyclic_active = true;
+}
+
+static int dm_test_cyclic_running(struct unit_test_state *uts)
+{


cyclic_active = false;

(since tests can be re-run)


Ok.


+   ut_assertnonnull(cyclic_register(cyclic_test, 10 * 1000, "cyclic_demo",
+NULL));
+   mdelay(100);


Instead of the delay, can you use WATCHDOG_RESET() ? This is the first
think udelay() does, after all.

It doesn't test as much code, but it does avoid a delay in the tests
(which slows them down).


I see. Yes, I can change this in the next version.


+   ut_asserteq(true, cyclic_active);
+
+   return 0;
+}
+DM_TEST(dm_test_cyclic_running, 0);


For this directory it should be COMMON_TEST() - see event.c


Ah, of course.


diff --git a/test/test-main.c b/test/test-main.c
index 31837e57a8fb..8a609a8a2fce 100644
--- a/test/test-main.c
+++ b/test/test-main.c
@@ -6,6 +6,7 @@

  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -220,6 +221,7 @@ static int dm_test_restore(struct device_node *of_root)
  static int test_pre_run(struct unit_test_state *uts, struct unit_test *test)
  {
 ut_assertok(event_init());
+   ut_assertok(cyclic_init());

 if (test->flags & UT_TESTF_DM)
 ut_assertok(dm_test_pre_run(uts));
@@ -265,6 +267,7 @@ static int test_post_run(struct unit_test_state *uts, 
struct unit_test *test)
 ut_unsilence_console(uts);
 if (test->flags & UT_TESTF_DM)
 ut_assertok(dm_test_post_run(uts));
+   ut_assertok(cyclic_uninit());
 ut_assertok(event_uninit());

 return 0;
--
2.37.2



Regards,
Simon


Viele Grüße,
Stefan Roese

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


Re: [PATCH v4 03/13] binman: Disable compressed data header

2022-08-16 Thread Stefan Herbrechtsmeier

Hi Simon,

Am 16.08.2022 um 13:48 schrieb Simon Glass:

Hi Stefan,

On Tue, 16 Aug 2022 at 02:42, Stefan Herbrechtsmeier
 wrote:


From: Stefan Herbrechtsmeier 

Disable the compressed data header of the utilities to compress and
decompress data. The header is uncommon, not supported by U-Boot and
incompatible with external compressed artifacts.

The header was introduced as part of commit eb0f4a4cb402 ("binman:
Support replacing data in a cbfs") to allow device tree entries to be
larger than the compressed contents.

Signed-off-by: Stefan Herbrechtsmeier 

---

(no changes since v3)

Changes in v3:
- Added

  tools/binman/entry.py |  2 +-
  tools/binman/etype/section.py |  3 ++-
  tools/binman/ftest.py | 18 +++---
  3 files changed, 14 insertions(+), 9 deletions(-)


This seems strange to me.

I would expect this patch to make every call set with_header to False,
then the next patch remove the parameters. That would allow later
bisecting to see where a problem occurs.

But at present this patch and the next seem to be mixed together.


I skipped the following calls because it doesn't matter:
comp_util.compress(b'',  'invalid')
comp_util.decompress(b'1234', 'invalid')

Do I miss a call?

The cbfs_util.py file doesn't use the header.


Re: [PATCH v3 2/4] arm64: smccc: clear the Xn registers after SMC calls

2022-08-16 Thread Jens Wiklander
On Mon, Aug 1, 2022 at 7:21 PM Abdellatif El Khlifi
 wrote:
>
> set to zero the x0-x17 registers
>
> As per the SMCCC v1.2 spec, unused result and scratch registers can leak
> information after an SMC call. We can mitigate against this risk by
> returning zero in each register.
>
> Signed-off-by: Abdellatif El Khlifi 
> Cc: Tom Rini 
> Cc: Ilias Apalodimas 
> Cc: Jens Wiklander 
> ---
>  arch/arm/cpu/armv8/smccc-call.S | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/cpu/armv8/smccc-call.S b/arch/arm/cpu/armv8/smccc-call.S
> index ec6f299bc9..8ac3e461e4 100644
> --- a/arch/arm/cpu/armv8/smccc-call.S
> +++ b/arch/arm/cpu/armv8/smccc-call.S
> @@ -84,6 +84,26 @@ ENDPROC(__arm_smccc_hvc)
> stp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS]
> stp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS]
>
> +   /* x0-x17 registers can leak information after an SMC or HVC call. 
> Let's clear them */
> +   mov x0, xzr
> +   mov x1, xzr
> +   mov x2, xzr
> +   mov x3, xzr
> +   mov x4, xzr
> +   mov x5, xzr
> +   mov x6, xzr
> +   mov x7, xzr
> +   mov x8, xzr
> +   mov x9, xzr
> +   mov x10, xzr
> +   mov x11, xzr
> +   mov x12, xzr
> +   mov x13, xzr
> +   mov x14, xzr
> +   mov x15, xzr
> +   mov x16, xzr
> +   mov x17, xzr
> +

Is this information leakage worse than the information leakage from an
ordinary C function?
My point is, is this needed?

Thanks,
Jens

> /* Restore original x19 */
> ldp xzr, x19, [sp], #16
> ret
> --
> 2.17.1
>


Re: [PATCH v4 13/13] binman: Support missing compression tools

2022-08-16 Thread Simon Glass
Hi Stefan,

On Tue, 16 Aug 2022 at 02:42, Stefan Herbrechtsmeier
 wrote:
>
> From: Stefan Herbrechtsmeier 
>
> Handle missing compression tools by returning empty data and marking the
> entry as 'missing'.

Great to see this.

This is actually a bit more subtle, see below.

>
> Signed-off-by: Stefan Herbrechtsmeier 
>
> ---
>
> Changes in v4:
> - Add missing 236_compress_dtb_missing_bintool.dts file
>
> Changes in v3:
> - Added
>
>  tools/binman/entry.py|  4 
>  tools/binman/ftest.py|  8 
>  .../test/236_compress_dtb_missing_bintool.dts| 16 
>  3 files changed, 28 insertions(+)
>  create mode 100644 tools/binman/test/236_compress_dtb_missing_bintool.dts
>
> diff --git a/tools/binman/entry.py b/tools/binman/entry.py
> index 9ec5811b46..c86b757a4e 100644
> --- a/tools/binman/entry.py
> +++ b/tools/binman/entry.py
> @@ -1078,7 +1078,11 @@ features to produce new behaviours.
>  """
>  self.uncomp_data = indata
>  if self.compress != 'none':
> +if not comp_util.is_present(self.compress):
> +self.missing = True

We must check self.GetAllowMissing(). If that is True then we can do
this. If False then we cannot. Hmm binman needs to fail if a bintool
is missing, unless --allow-missing is given.

Also you should call self.record_missing_bintool() here, instead of
setting self.missing (which refers to a missing blob).

BTW you also need to record the binbool somewhere with
self.AddBintools() in Entry:

def AddBintools(self, btools):
   self.comp_bintool = self.AddBintool(btools, self.compress)

That way you will get the right message, which is 'has missing bintools'

You then need to check for that stdout in your test, e.g. as is done
in testGbbMissing()

Finally, be careful to keep code coverage at 100%.

> +return b''
>  self.uncomp_size = len(indata)
> +
>  data = comp_util.compress(indata, self.compress)
>  return data
>
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> index a360ebeef5..eac7ccb087 100644
> --- a/tools/binman/ftest.py
> +++ b/tools/binman/ftest.py
> @@ -2557,6 +2557,14 @@ class TestFunctional(unittest.TestCase):
>  }
>  self.assertEqual(expected, props)
>
> +def testCompressMissingBintool(self):
> +"""Test that compress of device-tree files with missing bintool is
> +supported

Please add new tests at the end (so things are roughly in order of
test-file number). Also the test desc should fit on one like (e.g.
drop the 'Test that' text.

> +"""
> +data = self.data = 
> self._DoReadFileRealDtb('236_compress_dtb_missing_bintool.dts')

Can you drop self.data ?

> +self.assertEqual(U_BOOT_DATA, data[:len(U_BOOT_DATA)])
> +dtb_data = data[len(U_BOOT_DATA):]
> +self.assertEqual(0, len(dtb_data))


>
>  def testCbfsUpdateFdt(self):
>  """Test that we can update the device tree with CBFS offset/size 
> info"""
> diff --git a/tools/binman/test/236_compress_dtb_missing_bintool.dts 
> b/tools/binman/test/236_compress_dtb_missing_bintool.dts
> new file mode 100644
> index 00..e7ce1b893d
> --- /dev/null
> +++ b/tools/binman/test/236_compress_dtb_missing_bintool.dts
> @@ -0,0 +1,16 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/dts-v1/;
> +
> +/ {
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +
> +   binman {
> +   u-boot {
> +   };
> +   u-boot-dtb {
> +   compress = "_testing";
> +   };
> +   };
> +};
> --
> 2.30.2
>

Regards,
Simon


Re: [PATCH v4 11/13] binman: Add xz bintool

2022-08-16 Thread Simon Glass
On Tue, 16 Aug 2022 at 02:42, Stefan Herbrechtsmeier
 wrote:
>
> From: Stefan Herbrechtsmeier 
>
> Add xz bintool to binman to support on-the-fly compression.
>
> Signed-off-by: Stefan Herbrechtsmeier 
>
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - Rebase
>
> Changes in v2:
> - Added
>
>  tools/binman/btool/xz.py  | 31 +++
>  tools/binman/comp_util.py |  4 +++-
>  2 files changed, 34 insertions(+), 1 deletion(-)
>  create mode 100644 tools/binman/btool/xz.py

Reviewed-by: Simon Glass 


Re: [PATCH v4 12/13] binman: Add zstd bintool

2022-08-16 Thread Simon Glass
On Tue, 16 Aug 2022 at 02:42, Stefan Herbrechtsmeier
 wrote:
>
> From: Stefan Herbrechtsmeier 
>
> Add zstd bintool to binman to support on-the-fly compression.
>
> Signed-off-by: Stefan Herbrechtsmeier 
>
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - Rebase
>
> Changes in v2:
> - Added
>
>  tools/binman/btool/zstd.py | 30 ++
>  tools/binman/comp_util.py  |  4 +++-
>  tools/binman/etype/blob_dtb.py |  4 
>  tools/binman/ftest.py  |  3 ++-
>  4 files changed, 39 insertions(+), 2 deletions(-)
>  create mode 100644 tools/binman/btool/zstd.py

Reviewed-by: Simon Glass 


Re: [PATCH v4 10/13] binman: Add lzop bintool

2022-08-16 Thread Simon Glass
On Tue, 16 Aug 2022 at 02:42, Stefan Herbrechtsmeier
 wrote:
>
> From: Stefan Herbrechtsmeier 
>
> Add lzop bintool to binman to support on-the-fly compression.
>
> Signed-off-by: Stefan Herbrechtsmeier 
>
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - Rebase
>
> Changes in v2:
> - Added
>
>  tools/binman/btool/lzop.py | 30 ++
>  tools/binman/comp_util.py  |  6 --
>  2 files changed, 34 insertions(+), 2 deletions(-)
>  create mode 100644 tools/binman/btool/lzop.py

Reviewed-by: Simon Glass 


Re: [PATCH v4 09/13] binman: Add gzip bintool

2022-08-16 Thread Simon Glass
On Tue, 16 Aug 2022 at 02:42, Stefan Herbrechtsmeier
 wrote:
>
> From: Stefan Herbrechtsmeier 
>
> Add gzip bintool to binman to support on-the-fly compression of Linux
> kernel images and FPGA bitstreams. The SPL basic fitImage implementation
> supports only gzip decompression.
>
> Signed-off-by: Stefan Herbrechtsmeier 
>
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - Rebase
>
> Changes in v2:
> - Added
>
>  tools/binman/btool/gzip.py | 31 +++
>  tools/binman/comp_util.py  |  4 +++-
>  2 files changed, 34 insertions(+), 1 deletion(-)
>  create mode 100644 tools/binman/btool/gzip.py

Reviewed-by: Simon Glass 


Re: [PATCH v4 08/13] binman: Add bzip2 bintool

2022-08-16 Thread Simon Glass
On Tue, 16 Aug 2022 at 02:42, Stefan Herbrechtsmeier
 wrote:
>
> From: Stefan Herbrechtsmeier 
>
> Add bzip2 bintool to binman to support on-the-fly compression.
>
> Signed-off-by: Stefan Herbrechtsmeier 
>
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - Rebase
>
> Changes in v2:
> - Added
>
>  tools/binman/btool/bzip2.py | 30 ++
>  tools/binman/comp_util.py   |  4 +++-
>  2 files changed, 33 insertions(+), 1 deletion(-)
>  create mode 100644 tools/binman/btool/bzip2.py

Reviewed-by: Simon Glass 


Re: [PATCH v4 05/13] binman: Simplify comp_util class

2022-08-16 Thread Simon Glass
On Tue, 16 Aug 2022 at 02:42, Stefan Herbrechtsmeier
 wrote:
>
> From: Stefan Herbrechtsmeier 
>
> Simplify the comp_util class by remove duplicate code as preparation for
> additional compress algorithms.
>
> Signed-off-by: Stefan Herbrechtsmeier 
>
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - Rename COMPRESSIONS to ALGORITHMS
> - Rework existing comments
> - Add _get_tool_name function comment
> - Add _get_tool function comment
>
>  tools/binman/cbfs_util_test.py |   2 +-
>  tools/binman/comp_util.py  | 101 +++--
>  tools/binman/ftest.py  |   2 +-
>  3 files changed, 72 insertions(+), 33 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH v4 6/9] sandbox: Add cyclic demo function

2022-08-16 Thread Simon Glass
Hi Stefan,

On Tue, 16 Aug 2022 at 04:28, Stefan Roese  wrote:
>
> This patch enables the cyclic infrastructure on sandbox and also adds
> one simple example/demo functions using this cyclic functionality.
>
> Signed-off-by: Stefan Roese 
> ---
> v4:
> - Rename cyclic_struct to cyclic_info
>
> v3:
> - No change
>
> v2:
> - Extend CONFIG_CYCLIC_MAX_CPU_TIME_US to 1ms as running this
>   in CI might take a bit longer
>
>  board/sandbox/sandbox.c   | 15 +++
>  configs/sandbox_defconfig |  3 +++
>  2 files changed, 18 insertions(+)

Now that we have the test, do we need this? Or perhaps it should be a
'cyclic demo' command?

>
> diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c
> index ca9a2ca5b17c..f633b8e63768 100644
> --- a/board/sandbox/sandbox.c
> +++ b/board/sandbox/sandbox.c
> @@ -7,6 +7,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -17,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -106,8 +108,21 @@ int dram_init(void)
> return 0;
>  }
>
> +static void cyclic_demo(void *ctx)
> +{
> +   /* Just a small dummy delay here */
> +   udelay(10);
> +}
> +
>  int board_init(void)
>  {
> +   struct cyclic_info *cyclic;
> +
> +   /* Register demo cyclic function */
> +   cyclic = cyclic_register(cyclic_demo, 10 * 1000, "cyclic_demo", NULL);
> +   if (!cyclic)
> +   printf("Registering of cyclic_demo failed\n");
> +
> return 0;
>  }
>
> diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> index eba7bcbb483b..8b6c003760f2 100644
> --- a/configs/sandbox_defconfig
> +++ b/configs/sandbox_defconfig
> @@ -34,6 +34,8 @@ CONFIG_LOG=y
>  CONFIG_LOG_MAX_LEVEL=9
>  CONFIG_LOG_DEFAULT_LEVEL=6
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_CYCLIC=y
> +CONFIG_CYCLIC_MAX_CPU_TIME_US=1
>  CONFIG_STACKPROTECTOR=y
>  CONFIG_ANDROID_AB=y
>  CONFIG_CMD_CPU=y
> @@ -114,6 +116,7 @@ CONFIG_CMD_EROFS=y
>  CONFIG_CMD_EXT4_WRITE=y
>  CONFIG_CMD_SQUASHFS=y
>  CONFIG_CMD_MTDPARTS=y
> +CONFIG_CMD_CYCLIC=y
>  CONFIG_CMD_STACKPROTECTOR_TEST=y
>  CONFIG_MAC_PARTITION=y
>  CONFIG_AMIGA_PARTITION=y
> --
> 2.37.2
>

Regards,
Simon


Re: [PATCH v4 03/13] binman: Disable compressed data header

2022-08-16 Thread Simon Glass
Hi Stefan,

On Tue, 16 Aug 2022 at 02:42, Stefan Herbrechtsmeier
 wrote:
>
> From: Stefan Herbrechtsmeier 
>
> Disable the compressed data header of the utilities to compress and
> decompress data. The header is uncommon, not supported by U-Boot and
> incompatible with external compressed artifacts.
>
> The header was introduced as part of commit eb0f4a4cb402 ("binman:
> Support replacing data in a cbfs") to allow device tree entries to be
> larger than the compressed contents.
>
> Signed-off-by: Stefan Herbrechtsmeier 
>
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - Added
>
>  tools/binman/entry.py |  2 +-
>  tools/binman/etype/section.py |  3 ++-
>  tools/binman/ftest.py | 18 +++---
>  3 files changed, 14 insertions(+), 9 deletions(-)

This seems strange to me.

I would expect this patch to make every call set with_header to False,
then the next patch remove the parameters. That would allow later
bisecting to see where a problem occurs.

But at present this patch and the next seem to be mixed together.

>
> diff --git a/tools/binman/entry.py b/tools/binman/entry.py
> index e3767aefa7..a45aeeaa59 100644
> --- a/tools/binman/entry.py
> +++ b/tools/binman/entry.py
> @@ -1079,7 +1079,7 @@ features to produce new behaviours.
>  self.uncomp_data = indata
>  if self.compress != 'none':
>  self.uncomp_size = len(indata)
> -data = comp_util.compress(indata, self.compress)
> +data = comp_util.compress(indata, self.compress, with_header=False)
>  return data
>
>  @classmethod
> diff --git a/tools/binman/etype/section.py b/tools/binman/etype/section.py
> index bd67238b91..0a92bf2386 100644
> --- a/tools/binman/etype/section.py
> +++ b/tools/binman/etype/section.py
> @@ -777,7 +777,8 @@ class Entry_section(Entry):
>  data = parent_data[offset:offset + child.size]
>  if decomp:
>  indata = data
> -data = comp_util.decompress(indata, child.compress)
> +data = comp_util.decompress(indata, child.compress,
> +with_header=False)
>  if child.uncomp_size:
>  tout.info("%s: Decompressing data size %#x with algo '%s' to 
> data size %#x" %
>  (child.GetPath(), len(indata), child.compress,
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> index 1b468d8e6d..d082442bec 100644
> --- a/tools/binman/ftest.py
> +++ b/tools/binman/ftest.py
> @@ -1967,7 +1967,7 @@ class TestFunctional(unittest.TestCase):
>  self._ResetDtbs()
>
>  def _decompress(self, data):
> -return comp_util.decompress(data, 'lz4')
> +return comp_util.decompress(data, 'lz4', with_header=False)
>
>  def testCompress(self):
>  """Test compression of blobs"""
> @@ -4449,15 +4449,19 @@ class TestFunctional(unittest.TestCase):
>  rest = base[len(U_BOOT_DATA):]
>
>  # Check compressed data
> -section1 = self._decompress(rest)
> -expect1 = comp_util.compress(COMPRESS_DATA + U_BOOT_DATA, 'lz4')
> -self.assertEquals(expect1, rest[:len(expect1)])
> +expect1 = comp_util.compress(COMPRESS_DATA + U_BOOT_DATA, 'lz4',
> + with_header=False)
> +data1 = rest[:len(expect1)]
> +section1 = self._decompress(data1)
> +self.assertEquals(expect1, data1)
>  self.assertEquals(COMPRESS_DATA + U_BOOT_DATA, section1)
>  rest1 = rest[len(expect1):]
>
> -section2 = self._decompress(rest1)
> -expect2 = comp_util.compress(COMPRESS_DATA + COMPRESS_DATA, 'lz4')
> -self.assertEquals(expect2, rest1[:len(expect2)])
> +expect2 = comp_util.compress(COMPRESS_DATA + COMPRESS_DATA, 'lz4',
> + with_header=False)
> +data2 = rest1[:len(expect2)]
> +section2 = self._decompress(data2)
> +self.assertEquals(expect2, data2)
>  self.assertEquals(COMPRESS_DATA + COMPRESS_DATA, section2)
>  rest2 = rest1[len(expect2):]
>
> --
> 2.30.2
>

Regards,
Simon


Re: [PATCH v4 02/13] binman: Add length header attribute to dtb entry

2022-08-16 Thread Simon Glass
Hi Stefan,

On Tue, 16 Aug 2022 at 02:42, Stefan Herbrechtsmeier
 wrote:
>
> From: Stefan Herbrechtsmeier 
>
> Add an optional length header attribute to the device tree blob entry
> class based on the compressed data header from the utilities to compress
> and decompress data.
>
> If needed the header could be enabled with the following
> attribute beside the compress attribute:
>   prepend = "length";
>
> The header was introduced as part of commit eb0f4a4cb402 ("binman:
> Support replacing data in a cbfs") to allow device tree entries to be
> larger than the compressed contents. Regarding the commit "this is
> necessary to cope with a compressed device tree being updated in such a
> way that it shrinks after the entry size is already set (an obscure
> case)". This case need to be fixed without influence any compressed data
> by itself.
>
> Signed-off-by: Stefan Herbrechtsmeier 
>
> ---
>
> (no changes since v3)

This looks fine except that it drops test coverage (binman test -T
should be 100%). Please can you check it?

Regards,
Simon


Re: [PATCH v4 9/9] cyclic: Add a simple test

2022-08-16 Thread Simon Glass
On Tue, 16 Aug 2022 at 04:28, Stefan Roese  wrote:
>
> Add a test for cyclic function registration and activation.
>
> Signed-off-by: Stefan Roese 
> ---
> v4:
> - New patch
>
>  test/common/Makefile |  1 +
>  test/common/cyclic.c | 31 +++
>  test/test-main.c |  3 +++
>  3 files changed, 35 insertions(+)
>  create mode 100644 test/common/cyclic.c

Reviewed-by: Simon Glass 

>
> diff --git a/test/common/Makefile b/test/common/Makefile
> index 9087788ba6a8..cc918f64e544 100644
> --- a/test/common/Makefile
> +++ b/test/common/Makefile
> @@ -1,4 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0+
>  obj-y += cmd_ut_common.o
>  obj-$(CONFIG_AUTOBOOT) += test_autoboot.o
> +obj-$(CONFIG_CYCLIC) += cyclic.o
>  obj-$(CONFIG_EVENT) += event.o
> diff --git a/test/common/cyclic.c b/test/common/cyclic.c
> new file mode 100644
> index ..58f1603137e9
> --- /dev/null
> +++ b/test/common/cyclic.c
> @@ -0,0 +1,31 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2022 Stefan Roese 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Test that cyclic function is called */
> +static bool cyclic_active = false;
> +
> +static void cyclic_test(void *ctx)
> +{
> +   cyclic_active = true;
> +}
> +
> +static int dm_test_cyclic_running(struct unit_test_state *uts)
> +{

cyclic_active = false;

(since tests can be re-run)

> +   ut_assertnonnull(cyclic_register(cyclic_test, 10 * 1000, 
> "cyclic_demo",
> +NULL));
> +   mdelay(100);

Instead of the delay, can you use WATCHDOG_RESET() ? This is the first
think udelay() does, after all.

It doesn't test as much code, but it does avoid a delay in the tests
(which slows them down).

> +   ut_asserteq(true, cyclic_active);
> +
> +   return 0;
> +}
> +DM_TEST(dm_test_cyclic_running, 0);

For this directory it should be COMMON_TEST() - see event.c

> diff --git a/test/test-main.c b/test/test-main.c
> index 31837e57a8fb..8a609a8a2fce 100644
> --- a/test/test-main.c
> +++ b/test/test-main.c
> @@ -6,6 +6,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -220,6 +221,7 @@ static int dm_test_restore(struct device_node *of_root)
>  static int test_pre_run(struct unit_test_state *uts, struct unit_test *test)
>  {
> ut_assertok(event_init());
> +   ut_assertok(cyclic_init());
>
> if (test->flags & UT_TESTF_DM)
> ut_assertok(dm_test_pre_run(uts));
> @@ -265,6 +267,7 @@ static int test_post_run(struct unit_test_state *uts, 
> struct unit_test *test)
> ut_unsilence_console(uts);
> if (test->flags & UT_TESTF_DM)
> ut_assertok(dm_test_post_run(uts));
> +   ut_assertok(cyclic_uninit());
> ut_assertok(event_uninit());
>
> return 0;
> --
> 2.37.2
>

Regards,
Simon


[PATCHv2] drivers: tee: i2c: support the NXP SE05x probe errata

2022-08-16 Thread Jorge Ramirez-Ortiz
Early instantiation of this I2C device would lock up when being
probed.

 https://www.nxp.com/docs/en/errata/SE050_Erratasheet.pdf
 3.2.2
   In scenarios of detecting I2C ICs on the bus using an empty
   I2C frame containing only the address the SE050 will block
   the I2C bus.

Tested on STM32MP1

Signed-off-by: Jorge Ramirez-Ortiz 
---
 drivers/tee/optee/Kconfig | 14 +
 drivers/tee/optee/i2c.c   | 44 +++
 2 files changed, 54 insertions(+), 4 deletions(-)

diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
index d03028070b..05dfe2c9a8 100644
--- a/drivers/tee/optee/Kconfig
+++ b/drivers/tee/optee/Kconfig
@@ -37,6 +37,20 @@ config OPTEE_TA_SCP03
help
  Enables support for controlling (enabling, provisioning) the
  Secure Channel Protocol 03 operation in the OP-TEE SCP03 TA.
+
+config TEE_I2C_NXP_SE05X_ERRATA
+   bool "Enable NXP SE05X Errata"
+   select TEE_I2C_NXP_SE05X_ERRATA_IN_BUS
+   default y
+   help
+ This config prevents the I2C trampoline driver from probing
+ on every transfer.
+
+config TEE_I2C_NXP_SE05X_ERRATA_IN_BUS
+   int "I2C bus where to apply the NXP SE05X errata"
+   depends on TEE_I2C_NXP_SE05X_ERRATA
+   default 0
+
 endmenu
 
 endif
diff --git a/drivers/tee/optee/i2c.c b/drivers/tee/optee/i2c.c
index ef4e10f991..a3ea34d4a2 100644
--- a/drivers/tee/optee/i2c.c
+++ b/drivers/tee/optee/i2c.c
@@ -3,13 +3,18 @@
  * Copyright (c) 2020 Foundries.io Ltd
  */
 
+#define LOG_CATEGORY UCLASS_I2C
+
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "optee_msg.h"
 #include "optee_private.h"
 
+#define NXP_SE05X_ADDR 0x48
+
 static int check_xfer_flags(struct udevice *chip, uint tee_flags)
 {
uint flags;
@@ -30,6 +35,30 @@ static int check_xfer_flags(struct udevice *chip, uint 
tee_flags)
return 0;
 }
 
+static struct udevice *get_chip_dev(int bnum, int addr)
+{
+   struct udevice *chip;
+   struct udevice *bus;
+
+   if (IS_ENABLED(CONFIG_TEE_I2C_NXP_SE05X_ERRATA)) {
+   if (bnum == CONFIG_TEE_I2C_NXP_SE05X_ERRATA_IN_BUS &&
+   addr == NXP_SE05X_ADDR) {
+   if (uclass_get_device_by_seq(UCLASS_I2C, bnum, &bus))
+   return NULL;
+
+   if (i2c_get_chip(bus, addr, 0, &chip))
+   return NULL;
+
+   return chip;
+   }
+   }
+
+   if (i2c_get_chip_for_busnum(bnum, addr, 0, &chip))
+   return NULL;
+
+   return chip;
+}
+
 void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg *arg)
 {
const u8 attr[] = {
@@ -38,7 +67,8 @@ void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg *arg)
OPTEE_MSG_ATTR_TYPE_RMEM_INOUT,
OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT,
};
-   struct udevice *chip_dev;
+   struct udevice *chip_dev = NULL;
+
struct tee_shm *shm;
u8 *buf;
int ret;
@@ -56,9 +86,9 @@ void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg *arg)
if (!buf)
goto bad;
 
-   if (i2c_get_chip_for_busnum((int)arg->params[0].u.value.b,
-   (int)arg->params[0].u.value.c,
-   0, &chip_dev))
+   chip_dev = get_chip_dev((int)arg->params[0].u.value.b,
+   (int)arg->params[0].u.value.c);
+   if (!chip_dev)
goto bad;
 
if (check_xfer_flags(chip_dev, arg->params[1].u.value.a))
@@ -66,10 +96,16 @@ void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg *arg)
 
switch (arg->params[0].u.value.a) {
case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD:
+   log_debug("OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD %d\n",
+ (size_t)arg->params[2].u.rmem.size);
+
ret = dm_i2c_read(chip_dev, 0, buf,
  (size_t)arg->params[2].u.rmem.size);
break;
case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR:
+   log_debug("OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR %d\n",
+ (size_t)arg->params[2].u.rmem.size);
+
ret = dm_i2c_write(chip_dev, 0, buf,
   (size_t)arg->params[2].u.rmem.size);
break;
-- 
2.34.1



[PATCH] drivers: tee: i2c: support the NXP SE05x probe errata

2022-08-16 Thread Jorge Ramirez-Ortiz
Early instantiation of this I2C device would lock up when being
probed.

Signed-off-by: Jorge Ramirez-Ortiz 
---
 drivers/tee/optee/Kconfig | 14 +
 drivers/tee/optee/i2c.c   | 44 +++
 2 files changed, 54 insertions(+), 4 deletions(-)

diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
index d03028070b..05dfe2c9a8 100644
--- a/drivers/tee/optee/Kconfig
+++ b/drivers/tee/optee/Kconfig
@@ -37,6 +37,20 @@ config OPTEE_TA_SCP03
help
  Enables support for controlling (enabling, provisioning) the
  Secure Channel Protocol 03 operation in the OP-TEE SCP03 TA.
+
+config TEE_I2C_NXP_SE05X_ERRATA
+   bool "Enable NXP SE05X Errata"
+   select TEE_I2C_NXP_SE05X_ERRATA_IN_BUS
+   default y
+   help
+ This config prevents the I2C trampoline driver from probing
+ on every transfer.
+
+config TEE_I2C_NXP_SE05X_ERRATA_IN_BUS
+   int "I2C bus where to apply the NXP SE05X errata"
+   depends on TEE_I2C_NXP_SE05X_ERRATA
+   default 0
+
 endmenu
 
 endif
diff --git a/drivers/tee/optee/i2c.c b/drivers/tee/optee/i2c.c
index ef4e10f991..a3ea34d4a2 100644
--- a/drivers/tee/optee/i2c.c
+++ b/drivers/tee/optee/i2c.c
@@ -3,13 +3,18 @@
  * Copyright (c) 2020 Foundries.io Ltd
  */
 
+#define LOG_CATEGORY UCLASS_I2C
+
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "optee_msg.h"
 #include "optee_private.h"
 
+#define NXP_SE05X_ADDR 0x48
+
 static int check_xfer_flags(struct udevice *chip, uint tee_flags)
 {
uint flags;
@@ -30,6 +35,30 @@ static int check_xfer_flags(struct udevice *chip, uint 
tee_flags)
return 0;
 }
 
+static struct udevice *get_chip_dev(int bnum, int addr)
+{
+   struct udevice *chip;
+   struct udevice *bus;
+
+   if (IS_ENABLED(CONFIG_TEE_I2C_NXP_SE05X_ERRATA)) {
+   if (bnum == CONFIG_TEE_I2C_NXP_SE05X_ERRATA_IN_BUS &&
+   addr == NXP_SE05X_ADDR) {
+   if (uclass_get_device_by_seq(UCLASS_I2C, bnum, &bus))
+   return NULL;
+
+   if (i2c_get_chip(bus, addr, 0, &chip))
+   return NULL;
+
+   return chip;
+   }
+   }
+
+   if (i2c_get_chip_for_busnum(bnum, addr, 0, &chip))
+   return NULL;
+
+   return chip;
+}
+
 void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg *arg)
 {
const u8 attr[] = {
@@ -38,7 +67,8 @@ void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg *arg)
OPTEE_MSG_ATTR_TYPE_RMEM_INOUT,
OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT,
};
-   struct udevice *chip_dev;
+   struct udevice *chip_dev = NULL;
+
struct tee_shm *shm;
u8 *buf;
int ret;
@@ -56,9 +86,9 @@ void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg *arg)
if (!buf)
goto bad;
 
-   if (i2c_get_chip_for_busnum((int)arg->params[0].u.value.b,
-   (int)arg->params[0].u.value.c,
-   0, &chip_dev))
+   chip_dev = get_chip_dev((int)arg->params[0].u.value.b,
+   (int)arg->params[0].u.value.c);
+   if (!chip_dev)
goto bad;
 
if (check_xfer_flags(chip_dev, arg->params[1].u.value.a))
@@ -66,10 +96,16 @@ void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg *arg)
 
switch (arg->params[0].u.value.a) {
case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD:
+   log_debug("OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD %d\n",
+ (size_t)arg->params[2].u.rmem.size);
+
ret = dm_i2c_read(chip_dev, 0, buf,
  (size_t)arg->params[2].u.rmem.size);
break;
case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR:
+   log_debug("OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR %d\n",
+ (size_t)arg->params[2].u.rmem.size);
+
ret = dm_i2c_write(chip_dev, 0, buf,
   (size_t)arg->params[2].u.rmem.size);
break;
-- 
2.34.1



[PATCH v4 8/9] cyclic: Add documentation

2022-08-16 Thread Stefan Roese
Add documentation for the cyclic function infrastructure, including the
cyclic command.

Signed-off-by: Stefan Roese 
Reviewed-by: Simon Glass 
---
v4:
- Minor spelling fix
- Added Simon's RB tag

v3:
- New patch

 doc/develop/cyclic.rst   | 50 
 doc/develop/index.rst|  1 +
 doc/usage/cmd/cyclic.rst | 45 
 doc/usage/index.rst  |  1 +
 4 files changed, 97 insertions(+)
 create mode 100644 doc/develop/cyclic.rst
 create mode 100644 doc/usage/cmd/cyclic.rst

diff --git a/doc/develop/cyclic.rst b/doc/develop/cyclic.rst
new file mode 100644
index ..43bedacb9f88
--- /dev/null
+++ b/doc/develop/cyclic.rst
@@ -0,0 +1,50 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Cyclic functions
+
+
+The cyclic function execution infrastruture provides a way to periodically
+execute code, e.g. every 100ms. Examples for such functions might be LED
+blinking etc. The functions that are hooked into this cyclic list should
+be small timewise as otherwise the execution of the other code that relies
+on a high frequent polling (e.g. UART rx char ready check) might be
+delayed too much. To detect cyclic functions with a too long execution
+time, the Kconfig option `CONFIG_CYCLIC_MAX_CPU_TIME_US` is introduced,
+which configures the max allowed time for such a cyclic function. If it's
+execution time exceeds this time, this cyclic function will get removed
+from the cyclic list.
+
+Registering a cyclic function
+-
+
+To register a cyclic function, use something like this::
+
+static void cyclic_demo(void *ctx)
+{
+/* Just a small dummy delay here */
+udelay(10);
+}
+
+int board_init(void)
+{
+struct cyclic_info *cyclic;
+
+/* Register demo cyclic function */
+cyclic = cyclic_register(cyclic_demo, 10 * 1000, "cyclic_demo", NULL);
+if (!cyclic)
+printf("Registering of cyclic_demo failed\n");
+
+return 0;
+}
+
+This will register the function `cyclic_demo()` to be periodically
+executed all 10ms.
+
+How is this cyclic functionality integrated /  executed?
+
+
+The cyclic infrastructure integrates the main function responsible for
+calling all registered cyclic functions cyclic_run() into the common
+WATCHDOG_RESET macro. This guarantees that cyclic_run() is executed
+very often, which is necessary for the cyclic functions to get scheduled
+and executed at their configured periods.
diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index f7ee09db2467..ce6b38e57629 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -27,6 +27,7 @@ Implementation
ci_testing
commands
config_binding
+   cyclic
devicetree/index
distro
driver-model/index
diff --git a/doc/usage/cmd/cyclic.rst b/doc/usage/cmd/cyclic.rst
new file mode 100644
index ..3085cc7204c0
--- /dev/null
+++ b/doc/usage/cmd/cyclic.rst
@@ -0,0 +1,45 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+cyclic command
+==
+
+Synopsis
+
+
+::
+
+cyclic list
+
+Description
+---
+
+The cyclic list command provides a list of the currently registered
+cyclic functions.
+
+This shows the following information:
+
+Function
+Function name
+
+cpu-time
+Total time spent in this cyclic function.
+
+Frequency
+Frequency of execution of this function, e.g. 100 times/s for a
+pediod of 10ms.
+
+
+See :doc:`../../develop/cyclic` for more information on cyclic functions.
+
+Example
+---
+
+::
+
+=> cyclic list
+function: cyclic_demo, cpu-time: 52906 us, frequency: 99.20 times/s
+
+Configuration
+-
+
+The cyclic command is only available if CONFIG_CMD_CYCLIC=y.
diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index 28f9683a3e6f..1a0665ec1b78 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -33,6 +33,7 @@ Shell commands
cmd/bootz
cmd/cbsysinfo
cmd/conitrace
+   cmd/cyclic
cmd/dm
cmd/echo
cmd/env
-- 
2.37.2



[PATCH v4 3/9] cyclic: Integrate cyclic infrastructure into WATCHDOG_RESET

2022-08-16 Thread Stefan Roese
This patch integrates the main function responsible for calling all
registered cyclic functions cyclic_run() into the common WATCHDOG_RESET
macro. This guarantees that cyclic_run() is executed very often, which
is necessary for the cyclic functions to get scheduled and executed at
their configured periods.

If CONFIG_WATCHDOG is not enabled, only cyclic_run() without calling
watchdog_reset(). This guarantees that the cyclic functionality does not
rely on CONFIG_WATCHDOG being enabled.

Signed-off-by: Stefan Roese 
Reviewed-by: Simon Glass 
---
v4:
- Added Simon's RB tag

v3:
- No change

v2:
- No change

 fs/cramfs/uncompress.c |  2 +-
 include/watchdog.h | 23 ---
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/fs/cramfs/uncompress.c b/fs/cramfs/uncompress.c
index f431cc46c1f7..38e10e2e4422 100644
--- a/fs/cramfs/uncompress.c
+++ b/fs/cramfs/uncompress.c
@@ -62,7 +62,7 @@ int cramfs_uncompress_init (void)
stream.avail_in = 0;
 
 #if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
-   stream.outcb = (cb_func) WATCHDOG_RESET;
+   stream.outcb = (cb_func)watchdog_reset_func;
 #else
stream.outcb = Z_NULL;
 #endif /* CONFIG_HW_WATCHDOG */
diff --git a/include/watchdog.h b/include/watchdog.h
index 813cc8f2a5d3..0a9777edcbad 100644
--- a/include/watchdog.h
+++ b/include/watchdog.h
@@ -11,6 +11,8 @@
 #define _WATCHDOG_H_
 
 #if !defined(__ASSEMBLY__)
+#include 
+
 /*
  * Reset the watchdog timer, always returns 0
  *
@@ -60,11 +62,16 @@ int init_func_watchdog_reset(void);
/* Don't require the watchdog to be enabled in SPL */
#if defined(CONFIG_SPL_BUILD) &&\
!defined(CONFIG_SPL_WATCHDOG)
-   #define WATCHDOG_RESET() {}
+   #define WATCHDOG_RESET() { \
+   cyclic_run(); \
+   }
#else
extern void watchdog_reset(void);
 
-   #define WATCHDOG_RESET watchdog_reset
+   #define WATCHDOG_RESET() { \
+   watchdog_reset(); \
+   cyclic_run(); \
+   }
#endif
#endif
#else
@@ -74,11 +81,21 @@ int init_func_watchdog_reset(void);
#if defined(__ASSEMBLY__)
#define WATCHDOG_RESET /*XXX DO_NOT_DEL_THIS_COMMENT*/
#else
-   #define WATCHDOG_RESET() {}
+   #define WATCHDOG_RESET() { \
+   cyclic_run(); \
+   }
#endif /* __ASSEMBLY__ */
#endif /* CONFIG_WATCHDOG && !__ASSEMBLY__ */
 #endif /* CONFIG_HW_WATCHDOG */
 
+#if !defined(__ASSEMBLY__)
+/* Currently only needed for fs/cramfs/uncompress.c */
+static inline void watchdog_reset_func(void)
+{
+   WATCHDOG_RESET();
+}
+#endif
+
 /*
  * Prototypes from $(CPU)/cpu.c.
  */
-- 
2.37.2



[PATCH v4 1/9] time: Import time_after64() and friends from Linux

2022-08-16 Thread Stefan Roese
When using us times it makes sense to use 64bit variables for storage.
The currently implemented time_after() and friends functions only handle
32bit variables. This patch now includes the 64bit variants as well
from Linux. This will be used by the upcoming generic cyclic function
infrastructure.

These macros were copied from include/linux/jiffies.h of Linux 5.18.

Signed-off-by: Stefan Roese 
Reviewed-by: Simon Glass 
---
v4:
- Added Simon's RB tag

v3:
- No change

v2:
- No change

 include/time.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/time.h b/include/time.h
index 9deb2cf61cc4..3b2ba0912470 100644
--- a/include/time.h
+++ b/include/time.h
@@ -83,6 +83,25 @@ uint64_t usec_to_tick(unsigned long usec);
(time_after_eq(a,b) && \
 time_before(a,c))
 
+/* Same as above, but does so with platform independent 64bit types.
+ * These must be used when utilizing jiffies_64 (i.e. return value of
+ * get_jiffies_64() */
+#define time_after64(a,b)  \
+   (typecheck(__u64, a) && \
+typecheck(__u64, b) && \
+((__s64)((b) - (a)) < 0))
+#define time_before64(a,b) time_after64(b,a)
+
+#define time_after_eq64(a,b)   \
+   (typecheck(__u64, a) && \
+typecheck(__u64, b) && \
+((__s64)((a) - (b)) >= 0))
+#define time_before_eq64(a,b)  time_after_eq64(b,a)
+
+#define time_in_range64(a, b, c) \
+   (time_after_eq64(a, b) && \
+time_before_eq64(a, c))
+
 /**
  * usec2ticks() - Convert microseconds to internal ticks
  *
-- 
2.37.2



[PATCH v4 0/9] Add support for cyclic function execution infrastruture

2022-08-16 Thread Stefan Roese
This patchset adds the basic infrastructure to periodically execute
code, e.g. all 100ms. Examples for such functions might be LED blinking
etc. The functions that are hooked into this cyclic list should be
small timewise as otherwise the execution of the other code that relies
on a high frequent polling (e.g. UART rx char ready check) might be
delayed too much. This patch also adds the Kconfig option
CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time
for such a cyclic function. If it's execution time exceeds this time,
this cyclic function will get removed from the cyclic list.

How is this cyclic functionality executed?
This patchset integrates the main function responsible for calling all
registered cyclic functions cyclic_run() into the common WATCHDOG_RESET
macro. This guarantees that cyclic_run() is executed very often, which
is necessary for the cyclic functions to get scheduled and executed at
their configured periods.

This cyclic infrastructure will be used by a board specific function on
the NIC23 MIPS Octeon board, which needs to check periodically, if a
PCIe FLR has occurred.

Ideas how to continue:
One idea is to rename WATCHDOG_RESET to something like SCHEDULE and
move the watchdog_reset call into this cyclic infrastructure as well.
Or to perhaps move the shell UART RX ready polling to a cyclic
function.

It's also possible to extend the "cyclic" command, to support the
creation of periodically executed shell commands (for testing etc).

Here the Azure build, without any issues:
https://dev.azure.com/sr0718/u-boot/_build/results?buildId=228&view=results

Thanks,
Stefan

Aaron Williams (1):
  mips: octeon_nic23: Add PCIe FLR fixup via cyclic infrastructure

Stefan Roese (8):
  time: Import time_after64() and friends from Linux
  cyclic: Add basic support for cyclic function execution infrastruture
  cyclic: Integrate cyclic infrastructure into WATCHDOG_RESET
  cyclic: Integrate cyclic functionality at bootup in board_r/f
  cyclic: Add 'cyclic list' command
  sandbox: Add cyclic demo function
  cyclic: Add documentation
  cyclic: Add a simple test

 MAINTAINERS|   7 +
 board/Marvell/octeon_nic23/board.c | 197 +
 board/sandbox/sandbox.c|  15 +++
 cmd/Kconfig|  14 ++
 cmd/Makefile   |   1 +
 cmd/cyclic.c   |  40 ++
 common/Kconfig |  20 +++
 common/Makefile|   1 +
 common/board_f.c   |   2 +
 common/board_r.c   |   2 +
 common/cyclic.c| 113 +
 configs/octeon_nic23_defconfig |   3 +
 configs/sandbox_defconfig  |   3 +
 doc/develop/cyclic.rst |  50 
 doc/develop/index.rst  |   1 +
 doc/usage/cmd/cyclic.rst   |  45 +++
 doc/usage/index.rst|   1 +
 fs/cramfs/uncompress.c |   2 +-
 include/cyclic.h   | 110 
 include/time.h |  19 +++
 include/watchdog.h |  23 +++-
 test/common/Makefile   |   1 +
 test/common/cyclic.c   |  31 +
 test/test-main.c   |   3 +
 24 files changed, 700 insertions(+), 4 deletions(-)
 create mode 100644 cmd/cyclic.c
 create mode 100644 common/cyclic.c
 create mode 100644 doc/develop/cyclic.rst
 create mode 100644 doc/usage/cmd/cyclic.rst
 create mode 100644 include/cyclic.h
 create mode 100644 test/common/cyclic.c

-- 
2.37.2



[PATCH v4 7/9] mips: octeon_nic23: Add PCIe FLR fixup via cyclic infrastructure

2022-08-16 Thread Stefan Roese
From: Aaron Williams 

This patch adds a fixup function related to a PCIe FLR (Function Level
Reset) problem on the NIC23 PCIe board. This function is imported from
the Marvell Octeon 2013 U-Boot version as a (nearly) verbatim copy. It
uses the newly introduced cyclic infrastructure, so that this function
gets called every 100us, which is needed to detect this FLR issue.

Signed-off-by: Aaron Williams 
Signed-off-by: Stefan Roese 
---
v4:
- Rename cyclic_struct to cyclic_info

v3:
- No change

v2:
- No change

 board/Marvell/octeon_nic23/board.c | 197 +
 configs/octeon_nic23_defconfig |   3 +
 2 files changed, 200 insertions(+)

diff --git a/board/Marvell/octeon_nic23/board.c 
b/board/Marvell/octeon_nic23/board.c
index 3e2c5397..08b1aa4b6efe 100644
--- a/board/Marvell/octeon_nic23/board.c
+++ b/board/Marvell/octeon_nic23/board.c
@@ -3,8 +3,10 @@
  * Copyright (C) 2021-2022 Stefan Roese 
  */
 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -15,11 +17,90 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "board_ddr.h"
 
+/**
+ * cvmx_spem#_cfg_rd
+ *
+ * This register allows read access to the configuration in the PCIe core.
+ *
+ */
+union cvmx_spemx_cfg_rd {
+   u64 u64;
+   struct cvmx_spemx_cfg_rd_s {
+   u64 data : 32;
+   u64 addr : 32;
+   } s;
+   struct cvmx_spemx_cfg_rd_scn73xx;
+};
+
+/**
+ * cvmx_spem#_cfg_wr
+ *
+ * This register allows write access to the configuration in the PCIe core.
+ *
+ */
+union cvmx_spemx_cfg_wr {
+   u64 u64;
+   struct cvmx_spemx_cfg_wr_s {
+   u64 data : 32;
+   u64 addr : 32;
+   } s;
+   struct cvmx_spemx_cfg_wr_scn73xx;
+};
+
+/**
+ * cvmx_spem#_flr_pf_stopreq
+ *
+ * PF function level reset stop outbound requests register.
+ * Hardware automatically sets the STOPREQ bit for the PF when it enters a
+ * function level reset (FLR).  Software is responsible for clearing the 
STOPREQ
+ * bit but must not do so prior to hardware taking down the FLR, which could be
+ * as long as 100ms.  It may be appropriate for software to wait longer before 
clearing
+ * STOPREQ, software may need to drain deep DPI queues for example.
+ * Whenever SPEM receives a PF or child VF request mastered by CN over S2M 
(i.e. P or NP),
+ * when STOPREQ is set for the function, SPEM will discard the outgoing request
+ * before sending it to the PCIe core.  If a NP, SPEM will schedule an 
immediate
+ * SWI_RSP_ERROR completion for the request - no timeout is required.
+ * In both cases, SPEM()_DBG_PF()_INFO[P()_BMD_E] will be set and a error
+ * interrupt is generated.
+ *
+ * STOPREQ mimics the behavior of PCIEEP()_CFG001[ME] for outbound requests 
that will
+ * master the PCIe bus (P and NP).
+ *
+ * STOPREQ will have no effect on completions returned by CN over the S2M,
+ * nor on M2S traffic.
+ *
+ * When a PF()_STOPREQ is set, none of the associated
+ * PEM()_FLR_PF()_VF_STOPREQ[VF_STOPREQ] will be set.
+ *
+ * STOPREQ is reset when the MAC is reset, and is not reset after a chip soft 
reset.
+ */
+union cvmx_spemx_flr_pf_stopreq {
+   u64 u64;
+   struct cvmx_spemx_flr_pf_stopreq_s {
+   u64 reserved_3_63: 61;
+   u64 pf2_stopreq  : 1;
+   u64 pf1_stopreq  : 1;
+   u64 pf0_stopreq  : 1;
+   } s;
+   struct cvmx_spemx_flr_pf_stopreq_scn73xx;
+};
+
+#define CVMX_SPEMX_CFG_WR(offset)  0x00011800C028ull
+#define CVMX_SPEMX_CFG_RD(offset)  0x00011800C030ull
+#define CVMX_SPEMX_FLR_PF_STOPREQ(offset)  0x00011800C218ull
+
+#define DTX_SELECT_LTSSM   0x0
+#define DTX_SELECT_LTSSM_ENA   0x3ff
+#define LTSSM_L0   0x11
+
 #define NIC23_DEF_DRAM_FREQ800
 
+static u32 pci_cfgspace_reg0[2] = { 0, 0 };
+
 static u8 octeon_nic23_cfg0_spd_values[512] = {
OCTEON_NIC23_CFG0_SPD_VALUES
 };
@@ -145,8 +226,118 @@ void board_configure_qlms(void)
  cvmx_qlm_measure_clock(4), cvmx_qlm_measure_clock(5));
 }
 
+/**
+ * If there is a PF FLR then the PCI EEPROM is not re-read.  In this case
+ * we need to re-program the vendor and device ID immediately after hardware
+ * completes FLR.
+ *
+ * PCI spec requires FLR to be completed within 100ms.  The user who triggered
+ * FLR expects hardware to finish FLR within 100ms, otherwise the user will
+ * end up reading DEVICE_ID incorrectly from the reset value.
+ * CN23XX exits FLR at any point between 66 and 99ms, so U-Boot has to wait
+ * 99ms to let hardware finish its part, then finish reprogramming the
+ * correct device ID before the end of 100ms.
+ *
+ * Note: this solution only works properly when there is no other activity
+ * within U-Boot for 100ms fro

[PATCH v4 9/9] cyclic: Add a simple test

2022-08-16 Thread Stefan Roese
Add a test for cyclic function registration and activation.

Signed-off-by: Stefan Roese 
---
v4:
- New patch

 test/common/Makefile |  1 +
 test/common/cyclic.c | 31 +++
 test/test-main.c |  3 +++
 3 files changed, 35 insertions(+)
 create mode 100644 test/common/cyclic.c

diff --git a/test/common/Makefile b/test/common/Makefile
index 9087788ba6a8..cc918f64e544 100644
--- a/test/common/Makefile
+++ b/test/common/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0+
 obj-y += cmd_ut_common.o
 obj-$(CONFIG_AUTOBOOT) += test_autoboot.o
+obj-$(CONFIG_CYCLIC) += cyclic.o
 obj-$(CONFIG_EVENT) += event.o
diff --git a/test/common/cyclic.c b/test/common/cyclic.c
new file mode 100644
index ..58f1603137e9
--- /dev/null
+++ b/test/common/cyclic.c
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2022 Stefan Roese 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Test that cyclic function is called */
+static bool cyclic_active = false;
+
+static void cyclic_test(void *ctx)
+{
+   cyclic_active = true;
+}
+
+static int dm_test_cyclic_running(struct unit_test_state *uts)
+{
+   ut_assertnonnull(cyclic_register(cyclic_test, 10 * 1000, "cyclic_demo",
+NULL));
+   mdelay(100);
+   ut_asserteq(true, cyclic_active);
+
+   return 0;
+}
+DM_TEST(dm_test_cyclic_running, 0);
diff --git a/test/test-main.c b/test/test-main.c
index 31837e57a8fb..8a609a8a2fce 100644
--- a/test/test-main.c
+++ b/test/test-main.c
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -220,6 +221,7 @@ static int dm_test_restore(struct device_node *of_root)
 static int test_pre_run(struct unit_test_state *uts, struct unit_test *test)
 {
ut_assertok(event_init());
+   ut_assertok(cyclic_init());
 
if (test->flags & UT_TESTF_DM)
ut_assertok(dm_test_pre_run(uts));
@@ -265,6 +267,7 @@ static int test_post_run(struct unit_test_state *uts, 
struct unit_test *test)
ut_unsilence_console(uts);
if (test->flags & UT_TESTF_DM)
ut_assertok(dm_test_post_run(uts));
+   ut_assertok(cyclic_uninit());
ut_assertok(event_uninit());
 
return 0;
-- 
2.37.2



[PATCH v4 6/9] sandbox: Add cyclic demo function

2022-08-16 Thread Stefan Roese
This patch enables the cyclic infrastructure on sandbox and also adds
one simple example/demo functions using this cyclic functionality.

Signed-off-by: Stefan Roese 
---
v4:
- Rename cyclic_struct to cyclic_info

v3:
- No change

v2:
- Extend CONFIG_CYCLIC_MAX_CPU_TIME_US to 1ms as running this
  in CI might take a bit longer

 board/sandbox/sandbox.c   | 15 +++
 configs/sandbox_defconfig |  3 +++
 2 files changed, 18 insertions(+)

diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c
index ca9a2ca5b17c..f633b8e63768 100644
--- a/board/sandbox/sandbox.c
+++ b/board/sandbox/sandbox.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -17,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -106,8 +108,21 @@ int dram_init(void)
return 0;
 }
 
+static void cyclic_demo(void *ctx)
+{
+   /* Just a small dummy delay here */
+   udelay(10);
+}
+
 int board_init(void)
 {
+   struct cyclic_info *cyclic;
+
+   /* Register demo cyclic function */
+   cyclic = cyclic_register(cyclic_demo, 10 * 1000, "cyclic_demo", NULL);
+   if (!cyclic)
+   printf("Registering of cyclic_demo failed\n");
+
return 0;
 }
 
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index eba7bcbb483b..8b6c003760f2 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -34,6 +34,8 @@ CONFIG_LOG=y
 CONFIG_LOG_MAX_LEVEL=9
 CONFIG_LOG_DEFAULT_LEVEL=6
 CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_CYCLIC=y
+CONFIG_CYCLIC_MAX_CPU_TIME_US=1
 CONFIG_STACKPROTECTOR=y
 CONFIG_ANDROID_AB=y
 CONFIG_CMD_CPU=y
@@ -114,6 +116,7 @@ CONFIG_CMD_EROFS=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_SQUASHFS=y
 CONFIG_CMD_MTDPARTS=y
+CONFIG_CMD_CYCLIC=y
 CONFIG_CMD_STACKPROTECTOR_TEST=y
 CONFIG_MAC_PARTITION=y
 CONFIG_AMIGA_PARTITION=y
-- 
2.37.2



[PATCH v4 5/9] cyclic: Add 'cyclic list' command

2022-08-16 Thread Stefan Roese
This patch adds the cyclic command, which currently only supports the
'list' subcommand, to list all currently registered cyclic functions.
Here an example:

=> cyclic list
function: cyclic_demo, cpu-time: 7010 us, frequency: 99.80 times/s
function: cyclic_demo2, cpu-time: 1 us, frequency: 1.13 times/s

As you can see, the cpu-time is accounted, so that cyclic functions
that take too long might be discovered. Additionally the frequency is
logged.

Signed-off-by: Stefan Roese 
Reviewed-by: Simon Glass 
---
v4:
- Add 'default y' in Kconfig and extend help text
- Minor spelling fix
- Added Simon's RB tag

v3:
- No change

v2:
- Add depends on CYCLIC in Kconfig


 MAINTAINERS  |  1 +
 cmd/Kconfig  | 14 ++
 cmd/Makefile |  1 +
 cmd/cyclic.c | 40 
 4 files changed, 56 insertions(+)
 create mode 100644 cmd/cyclic.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 61395a85a83e..e7625c0cf755 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -791,6 +791,7 @@ F:  doc/arch/m68k.rst
 CYCLIC
 M: Stefan Roese 
 S: Maintained
+F: cmd/cyclic.c
 F: common/cyclic.c
 F: include/cyclic.h
 
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 211ebe9c8783..eabd6921674b 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2505,6 +2505,20 @@ config CMD_CBSYSINFO
  memory by coreboot before jumping to U-Boot. It can be useful for
  debugging the beaaviour of coreboot or U-Boot.
 
+config CMD_CYCLIC
+   bool "cyclic - Show information about cyclic functions"
+   depends on CYCLIC
+   default y
+   help
+ This enables the 'cyclic' command which provides information about
+ cyclic execution functions. This infrastructure allows registering
+ functions to be executed cyclically, e.g. every 100ms. These commands
+ are supported:
+
+   cyclic list - list cyclic functions
+
+ See doc/develop/cyclic.rst for more details.
+
 config CMD_DIAG
bool "diag - Board diagnostics"
help
diff --git a/cmd/Makefile b/cmd/Makefile
index 6e87522b62e8..a0abfc623a2b 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_CMD_DIAG) += diag.o
 endif
 obj-$(CONFIG_CMD_ADTIMG) += adtimg.o
 obj-$(CONFIG_CMD_ABOOTIMG) += abootimg.o
+obj-$(CONFIG_CMD_CYCLIC) += cyclic.o
 obj-$(CONFIG_CMD_EVENT) += event.o
 obj-$(CONFIG_CMD_EXTENSION) += extension_board.o
 obj-$(CONFIG_CMD_ECHO) += echo.o
diff --git a/cmd/cyclic.c b/cmd/cyclic.c
new file mode 100644
index ..8709b64afcc1
--- /dev/null
+++ b/cmd/cyclic.c
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * A general-purpose cyclic execution infrastructure, to allow "small"
+ * (run-time wise) functions to be executed at a specified frequency.
+ * Things like LED blinking or watchdog triggering are examples for such
+ * tasks.
+ *
+ * Copyright (C) 2022 Stefan Roese 
+ */
+
+#include 
+#include 
+#include 
+
+extern struct list_head cyclic_list;
+
+static int do_cyclic_list(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+   struct cyclic_info *cyclic, *tmp;
+   uint64_t cnt, freq;
+
+   list_for_each_entry_safe(cyclic, tmp, &cyclic_list, list) {
+   cnt = cyclic->run_cnt * 100ULL * 100ULL;
+   freq = cnt / (timer_get_us() - cyclic->start_time_us);
+   printf("function: %s, cpu-time: %lld us, frequency: %lld.%02lld 
times/s\n",
+  cyclic->name, cyclic->cpu_time_us,
+  freq / 100, freq % 100);
+   }
+
+   return 0;
+}
+
+#ifdef CONFIG_SYS_LONGHELP
+static char cyclic_help_text[] =
+   "cyclic list   - list cyclic functions";
+#endif
+
+U_BOOT_CMD_WITH_SUBCMDS(cyclic, "Cyclic", cyclic_help_text,
+   U_BOOT_SUBCMD_MKENT(list, 1, 1, do_cyclic_list));
-- 
2.37.2



[PATCH v4 4/9] cyclic: Integrate cyclic functionality at bootup in board_r/f

2022-08-16 Thread Stefan Roese
This patch adds a call to cyclic_init() to board_f/r.c, enabling the
common cyclic infrastructure. After this it's possible to add cyclic
functions via cyclic_register().

Signed-off-by: Stefan Roese 
Reviewed-by: Simon Glass 
---
v4:
- Added Simon's RB tag

v3:
- No change

v2:
- No change

 common/board_f.c | 2 ++
 common/board_r.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/common/board_f.c b/common/board_f.c
index 18e2246733b0..deb46be18227 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -828,6 +829,7 @@ static const init_fnc_t init_sequence_f[] = {
initf_malloc,
log_init,
initf_bootstage,/* uses its own timer, so does not need DM */
+   cyclic_init,
event_init,
 #ifdef CONFIG_BLOBLIST
bloblist_init,
diff --git a/common/board_r.c b/common/board_r.c
index 56eb60fa2753..cf89adfaa430 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #ifdef CONFIG_MTD_NOR_FLASH
@@ -591,6 +592,7 @@ static int run_main_loop(void)
 static init_fnc_t init_sequence_r[] = {
initr_trace,
initr_reloc,
+   cyclic_init,
event_init,
/* TODO: could x86/PPC have this also perhaps? */
 #if defined(CONFIG_ARM) || defined(CONFIG_RISCV)
-- 
2.37.2



[PATCH v4 2/9] cyclic: Add basic support for cyclic function execution infrastruture

2022-08-16 Thread Stefan Roese
Add the basic infrastructure to periodically execute code, e.g. all
100ms. Examples for such functions might be LED blinking etc. The
functions that are hooked into this cyclic list should be small timewise
as otherwise the execution of the other code that relies on a high
frequent polling (e.g. UART rx char ready check) might be delayed too
much. This patch also adds the Kconfig option
CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time
for such a cyclic function. If it's execution time exceeds this time,
this cyclic function will get removed from the cyclic list.

How is this cyclic functionality executed?
The following patch integrates the main function responsible for
calling all registered cyclic functions cyclic_run() into the
common WATCHDOG_RESET macro. This guarantees that cyclic_run() is
executed very often, which is necessary for the cyclic functions to
get scheduled and executed at their configured periods.

This cyclic infrastructure will be used by a board specific function on
the NIC23 MIPS Octeon board, which needs to check periodically, if a
PCIe FLR has occurred.

Signed-off-by: Stefan Roese 
Reviewed-by: Simon Glass 
---
v4:
- Rename cyclic_struct to cyclic_info and document it
- Set 'cyclic_ready' to false in cyclic_uninit()
- Added Simon's RB tag

v3:
- No change

v2:
- Also add cyclic_register() and cyclic_unregister() as empty functions
  when CONFIG_CYCLIC is not defined
- Misc minor changes

 MAINTAINERS  |   6 +++
 common/Kconfig   |  20 +
 common/Makefile  |   1 +
 common/cyclic.c  | 113 +++
 include/cyclic.h | 110 +
 5 files changed, 250 insertions(+)
 create mode 100644 common/cyclic.c
 create mode 100644 include/cyclic.h

diff --git a/MAINTAINERS b/MAINTAINERS
index fa8c13fc7dfb..61395a85a83e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -788,6 +788,12 @@ T: git 
https://source.denx.de/u-boot/custodians/u-boot-coldfire.git
 F: arch/m68k/
 F: doc/arch/m68k.rst
 
+CYCLIC
+M: Stefan Roese 
+S: Maintained
+F: common/cyclic.c
+F: include/cyclic.h
+
 DFU
 M: Lukasz Majewski 
 S: Maintained
diff --git a/common/Kconfig b/common/Kconfig
index e7914ca750a3..a6a94ab8dfbf 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -545,6 +545,26 @@ config DISPLAY_BOARDINFO_LATE
 
 menu "Start-up hooks"
 
+config CYCLIC
+   bool "General-purpose cyclic execution mechanism"
+   help
+ This enables a general-purpose cyclic execution infrastructure,
+ to allow "small" (run-time wise) functions to be executed at
+ a specified frequency. Things like LED blinking or watchdog
+ triggering are examples for such tasks.
+
+if CYCLIC
+
+config CYCLIC_MAX_CPU_TIME_US
+   int "Sets the max allowed time for a cyclic function in us"
+   default 1000
+   help
+ The max allowed time for a cyclic function in us. If a functions
+ takes longer than this duration this function will get unregistered
+ automatically.
+
+endif # CYCLIC
+
 config EVENT
bool "General-purpose event-handling mechanism"
default y if SANDBOX
diff --git a/common/Makefile b/common/Makefile
index 2ed8672c3ac1..1d56c9f2895a 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -84,6 +84,7 @@ obj-y += malloc_simple.o
 endif
 endif
 
+obj-$(CONFIG_CYCLIC) += cyclic.o
 obj-$(CONFIG_$(SPL_TPL_)EVENT) += event.o
 
 obj-$(CONFIG_$(SPL_TPL_)HASH) += hash.o
diff --git a/common/cyclic.c b/common/cyclic.c
new file mode 100644
index ..766a98382596
--- /dev/null
+++ b/common/cyclic.c
@@ -0,0 +1,113 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * A general-purpose cyclic execution infrastructure, to allow "small"
+ * (run-time wise) functions to be executed at a specified frequency.
+ * Things like LED blinking or watchdog triggering are examples for such
+ * tasks.
+ *
+ * Copyright (C) 2022 Stefan Roese 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct list_head cyclic_list;
+static bool cyclic_ready;
+static bool cyclic_running;
+
+struct cyclic_info *cyclic_register(cyclic_func_t func, uint64_t delay_us,
+   const char *name, void *ctx)
+{
+   struct cyclic_info *cyclic;
+
+   if (!cyclic_ready) {
+   pr_debug("Cyclic IF not ready yet\n");
+   return NULL;
+   }
+
+   cyclic = calloc(1, sizeof(struct cyclic_info));
+   if (!cyclic) {
+   pr_debug("Memory allocation error\n");
+   return NULL;
+   }
+
+   /* Store values in struct */
+   cyclic->func = func;
+   cyclic->ctx = ctx;
+   cyclic->name = strdup(name);
+   cyclic->delay_us = delay_us;
+   cyclic->start_time_us = timer_get_us();
+   list_add_tail(&cyclic->list, &cyclic_list);
+
+   return cyclic;
+}
+
+int cyclic_unregister(struct cyclic_info *cyclic)
+{
+   list_del

Re: [PATCH] arm: ARMv4 assembly compatibility

2022-08-16 Thread Sergei Antonov
On Wed, 10 Aug 2022 at 12:05, Sergei Antonov  wrote:
>
> There is currently a problem that U-Boot can not work on ARMv4
> because assembly imlementations of memcpy() and some other functions
> use "bx lr" instruction that is not available on ARMv4 ("mov pc, lr"
> should be used instead).

Hello! There has been no replies to this message. I hope it did not
make it into spam folders. The proposed patch allows U-Boot to run on
ARMv4 systems without breaking (or even changing) other systems.
Please, consider it.


Re: [PATCH v3 3/8] cyclic: Integrate cyclic infrastructure into WATCHDOG_RESET

2022-08-16 Thread Stefan Roese

Hi Simon,

On 15.08.22 19:37, Simon Glass wrote:

Hi Stefan,

On Mon, 15 Aug 2022 at 10:16, Stefan Roese  wrote:


Hi Simon,

On 05.08.22 18:48, Simon Glass wrote:

Hi Stefan,

On Fri, 5 Aug 2022 at 08:26, Stefan Roese  wrote:


This patch integrates the main function responsible for calling all
registered cyclic functions cyclic_run() into the common WATCHDOG_RESET
macro. This guarantees that cyclic_run() is executed very often, which
is necessary for the cyclic functions to get scheduled and executed at
their configured periods.

If CONFIG_WATCHDOG is not enabled, only cyclic_run() without calling
watchdog_reset(). This guarantees that the cyclic functionality does not
rely on CONFIG_WATCHDOG being enabled.

Signed-off-by: Stefan Roese 
---
v3:
- No change
v2:
- No change

   fs/cramfs/uncompress.c |  2 +-
   include/watchdog.h | 23 ---
   2 files changed, 21 insertions(+), 4 deletions(-)


Reviewed-by: Simon Glass 



diff --git a/fs/cramfs/uncompress.c b/fs/cramfs/uncompress.c
index f431cc46c1f7..38e10e2e4422 100644
--- a/fs/cramfs/uncompress.c
+++ b/fs/cramfs/uncompress.c
@@ -62,7 +62,7 @@ int cramfs_uncompress_init (void)
  stream.avail_in = 0;

   #if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
-   stream.outcb = (cb_func) WATCHDOG_RESET;
+   stream.outcb = (cb_func)watchdog_reset_func;
   #else
  stream.outcb = Z_NULL;
   #endif /* CONFIG_HW_WATCHDOG */
diff --git a/include/watchdog.h b/include/watchdog.h
index 813cc8f2a5d3..0a9777edcbad 100644
--- a/include/watchdog.h
+++ b/include/watchdog.h
@@ -11,6 +11,8 @@
   #define _WATCHDOG_H_

   #if !defined(__ASSEMBLY__)
+#include 
+
   /*
* Reset the watchdog timer, always returns 0
*
@@ -60,11 +62,16 @@ int init_func_watchdog_reset(void);
  /* Don't require the watchdog to be enabled in SPL */
  #if defined(CONFIG_SPL_BUILD) &&\
  !defined(CONFIG_SPL_WATCHDOG)
-   #define WATCHDOG_RESET() {}
+   #define WATCHDOG_RESET() { \
+   cyclic_run(); \
+   }
  #else
  extern void watchdog_reset(void);

-   #define WATCHDOG_RESET watchdog_reset
+   #define WATCHDOG_RESET() { \
+   watchdog_reset(); \
+   cyclic_run(); \


Doesn't this create two function calls from every reset site? I worry
about code size.


Good point. Even though the world build did not trigger any new problems
with oversized images.


I suggest creating a new function like
check_watchdog() which you can define (in the C file) with
IS_ENABLED() as either empty, calling watchdog_reset() and/or calling
cyclic_run(). LTO should help here.


I tried a bit to get clean up this ugly #ifdef construct. And move this
as you suggested into a C file. Just now I noticed, that we don't have
a matching C file, which is compiled in all cases. wdt-uclass.c and
cyclic.c are both only compiled when actually enabled in Kconfig.

So do you have some other / better idea on how to improve this?

BTW: Moving the watchdog integration into the cyclic infrastructure in
some follow-up patches will make all this much cleaner AFAICT.


If you are going to do this soon, then I suggest not working about it too much.

But you could create wdt_common.c or similar. It should be OK to
always compile it since the code will be dropped if nothing calls it.


Yes, this would be one potential intermediate "solution". I'll try to
work on the WDT migration to cyclic IF soon and will keep the code
in this header as-is for now.

Thanks,
Stefan


[PATCH] MAINTAINERS: Update email of Neil Armstrong

2022-08-16 Thread Neil Armstrong
From: Neil Armstrong 

My professional e-mail will change and the BayLibre one will
bounce after mid-september of 2022.

This updates the MAINTAINERS files and adds an entry in the
.mailmap file.

Signed-off-by: Neil Armstrong 
---
 .mailmap| 1 +
 MAINTAINERS | 2 +-
 board/amlogic/odroid-n2/MAINTAINERS | 2 +-
 board/amlogic/p200/MAINTAINERS  | 2 +-
 board/amlogic/p201/MAINTAINERS  | 2 +-
 board/amlogic/p212/MAINTAINERS  | 2 +-
 board/amlogic/q200/MAINTAINERS  | 2 +-
 board/amlogic/s400/MAINTAINERS  | 2 +-
 board/amlogic/sei510/MAINTAINERS| 2 +-
 board/amlogic/sei610/MAINTAINERS| 2 +-
 board/amlogic/u200/MAINTAINERS  | 2 +-
 board/amlogic/vim3/MAINTAINERS  | 2 +-
 board/amlogic/w400/MAINTAINERS  | 2 +-
 13 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/.mailmap b/.mailmap
index f27f366bcb..8acce4b2bf 100644
--- a/.mailmap
+++ b/.mailmap
@@ -49,6 +49,7 @@ Michal Simek  
 Michal Simek  
 Michal Simek  
 Michal Simek  
+Neil Armstrong  
 Nicolas Saenz Julienne  
 Patrice Chotard  
 Patrick Delaunay  
diff --git a/MAINTAINERS b/MAINTAINERS
index fa8c13fc7d..f0dfbc5450 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -143,7 +143,7 @@ F:  arch/arm/mach-socfpga/
 F: drivers/sysreset/sysreset_socfpga*
 
 ARM AMLOGIC SOC SUPPORT
-M: Neil Armstrong 
+M: Neil Armstrong 
 S: Maintained
 L: u-boot-amlo...@groups.io
 T: git https://source.denx.de/u-boot/custodians/u-boot-amlogic.git
diff --git a/board/amlogic/odroid-n2/MAINTAINERS 
b/board/amlogic/odroid-n2/MAINTAINERS
index 43724e6fdd..23cc8e73b1 100644
--- a/board/amlogic/odroid-n2/MAINTAINERS
+++ b/board/amlogic/odroid-n2/MAINTAINERS
@@ -1,5 +1,5 @@
 ODROID-N2
-M: Neil Armstrong 
+M: Neil Armstrong 
 S: Maintained
 L: u-boot-amlo...@groups.io
 F: board/amlogic/odroid-n2/
diff --git a/board/amlogic/p200/MAINTAINERS b/board/amlogic/p200/MAINTAINERS
index 1df9b8b24b..33ca3df5c6 100644
--- a/board/amlogic/p200/MAINTAINERS
+++ b/board/amlogic/p200/MAINTAINERS
@@ -1,6 +1,6 @@
 P200
 M: Beniamino Galvani 
-M: Neil Armstrong 
+M: Neil Armstrong 
 S: Maintained
 L: u-boot-amlo...@groups.io
 F: board/amlogic/p200/
diff --git a/board/amlogic/p201/MAINTAINERS b/board/amlogic/p201/MAINTAINERS
index 1501b6280d..4549d01cad 100644
--- a/board/amlogic/p201/MAINTAINERS
+++ b/board/amlogic/p201/MAINTAINERS
@@ -1,5 +1,5 @@
 P201
-M: Neil Armstrong 
+M: Neil Armstrong 
 S: Maintained
 L: u-boot-amlo...@groups.io
 F: board/amlogic/p201/
diff --git a/board/amlogic/p212/MAINTAINERS b/board/amlogic/p212/MAINTAINERS
index 3d622af29b..b2e3205fdf 100644
--- a/board/amlogic/p212/MAINTAINERS
+++ b/board/amlogic/p212/MAINTAINERS
@@ -1,5 +1,5 @@
 P212
-M: Neil Armstrong 
+M: Neil Armstrong 
 S: Maintained
 L: u-boot-amlo...@groups.io
 F: board/amlogic/p212/
diff --git a/board/amlogic/q200/MAINTAINERS b/board/amlogic/q200/MAINTAINERS
index ba7c12b2c1..9c84cca27e 100644
--- a/board/amlogic/q200/MAINTAINERS
+++ b/board/amlogic/q200/MAINTAINERS
@@ -1,5 +1,5 @@
 Q200
-M: Neil Armstrong 
+M: Neil Armstrong 
 S: Maintained
 L: u-boot-amlo...@groups.io
 F: board/amlogic/q200/
diff --git a/board/amlogic/s400/MAINTAINERS b/board/amlogic/s400/MAINTAINERS
index fb46b1bbbf..ca51bb6b3b 100644
--- a/board/amlogic/s400/MAINTAINERS
+++ b/board/amlogic/s400/MAINTAINERS
@@ -1,5 +1,5 @@
 S400
-M: Neil Armstrong 
+M: Neil Armstrong 
 S: Maintained
 L: u-boot-amlo...@groups.io
 F: board/amlogic/s400/
diff --git a/board/amlogic/sei510/MAINTAINERS b/board/amlogic/sei510/MAINTAINERS
index c01c1d60df..c6039bc82e 100644
--- a/board/amlogic/sei510/MAINTAINERS
+++ b/board/amlogic/sei510/MAINTAINERS
@@ -1,5 +1,5 @@
 SEI510
-M: Neil Armstrong 
+M: Neil Armstrong 
 S: Maintained
 L: u-boot-amlo...@groups.io
 F: board/amlogic/sei510/
diff --git a/board/amlogic/sei610/MAINTAINERS b/board/amlogic/sei610/MAINTAINERS
index 092178b2c8..799ad687f0 100644
--- a/board/amlogic/sei610/MAINTAINERS
+++ b/board/amlogic/sei610/MAINTAINERS
@@ -1,5 +1,5 @@
 SEI610
-M: Neil Armstrong 
+M: Neil Armstrong 
 S: Maintained
 L: u-boot-amlo...@groups.io
 F: board/amlogic/sei610/
diff --git a/board/amlogic/u200/MAINTAINERS b/board/amlogic/u200/MAINTAINERS
index a259d12886..47cec234a1 100644
--- a/board/amlogic/u200/MAINTAINERS
+++ b/board/amlogic/u200/MAINTAINERS
@@ -1,5 +1,5 @@
 U200
-M: Neil Armstrong 
+M: Neil Armstrong 
 S: Maintained
 L: u-boot-amlo...@groups.io
 F: board/amlogic/u200/
diff --git a/board/amlogic/vim3/MAINTAINERS b/board/amlogic/vim3/MAINTAINERS
index d8848495c7..c5f8d9cc5c 100644
--- a/board/amlogic/vim3/MAINTAINERS
+++ b/board/amlogic/vim3/MAINTAINERS
@@ -1,5 +1,5 @@
 VIM3
-M: Neil Armstrong 
+M: Neil Armstrong 
 S: Maintained
 L: u-boot-amlo...@groups.io
 F: board/amlogic/vim3/
diff --git a/board/amlogic/

Re: [PATCH 5/5] arm: kirkwood: Do not overwrite CONFIG_SYS_TCLK

2022-08-16 Thread Michael Walle
Hi!

> On Sunday 01 August 2021 20:07:16 Chris Packham wrote:
> > On Sun, Aug 1, 2021 at 12:23 AM Pali Rohár  wrote:
> > >
> > > Config option CONFIG_SYS_TCLK is set by kw88f6281.h and kw88f6192.h files
> > > to correct SOC/platform value. So do not overwrite it in board config
> > > include files.
> > >
> > > Kirkwood 88F6180 and 88F6192 uses 166 MHz TCLK and Kirkwood 88F6281 uses
> > > 200 MHz TCLK.
> > >
> > 
> > It's been a while since I worked with kirkwood but I thought that
> > there was hardware strapping for the TCLK.
> 
> Interesting... Because I took above information from Kirkwood hardware 
> specifications...
> 
> 88F6180: 
> https://web.archive.org/web/20130730091654/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf
> 88F6192: 
> https://web.archive.org/web/20121021182835/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf
> 88F6281: 
> https://web.archive.org/web/20120620073511/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
> 
> And there are specified fixed TCLK values.

Nope, this breaks my lsxl (specifically the LSCHLv2) board. The TCLK is
166MHz there.

> > If I understand correctly
> > the defines in kw88f6281.h/kw88f6192.h were sensible defaults but
> > boards were able to override it to reflect the hardware configuration.
> 
> Anyway, I think that this patch should not cause issue as it is changing
> only two board config files and removing redefinition of CONFIG_SYS_TCLK
> macro which is set to the same value as in kw88f61**.h files.

At least for the lsxl and the NET2BIG_V2 this is not correct. Both have
the 88F6281 and both use have a 166MHz TCLK clock.

Anyway, I'm reverting this patch. The only open question is, should I
convert the TCLK to a Kconfig option?

-michael

> > Signed-off-by: Pali Rohár 
> > ---
> >  arch/arm/mach-kirkwood/include/mach/kw88f6281.h | 2 --
> >  include/configs/lacie_kw.h  | 5 -
> >  include/configs/lsxl.h  | 2 --
> >  3 files changed, 9 deletions(-)
> >
> > diff --git a/arch/arm/mach-kirkwood/include/mach/kw88f6281.h 
> > b/arch/arm/mach-kirkwood/include/mach/kw88f6281.h
> > index 33e741420781..87406081cf54 100644
> > --- a/arch/arm/mach-kirkwood/include/mach/kw88f6281.h
> > +++ b/arch/arm/mach-kirkwood/include/mach/kw88f6281.h
> > @@ -15,8 +15,6 @@
> >  #define KW_REGS_PHY_BASE   KW88F6281_REGS_PHYS_BASE
> >
> >  /* TCLK Core Clock definition */
> > -#ifndef CONFIG_SYS_TCLK
> >  #define CONFIG_SYS_TCLK2 /* 200MHz */
> > -#endif
> >
> >  #endif /* _ASM_ARCH_KW88F6281_H */
> > diff --git a/include/configs/lacie_kw.h b/include/configs/lacie_kw.h
> > index 420c1d49b08e..88f784f1f0fd 100644
> > --- a/include/configs/lacie_kw.h
> > +++ b/include/configs/lacie_kw.h
> > @@ -39,11 +39,6 @@
> >  #endif
> >  #define CONFIG_SKIP_LOWLEVEL_INIT  /* disable board lowlevel_init */
> >
> > -/*
> > - * Core clock definition
> > - */
> > -#define CONFIG_SYS_TCLK16600 /* 166MHz */
> > -
> >  /*
> >   * SDRAM configuration
> >   */
> > diff --git a/include/configs/lsxl.h b/include/configs/lsxl.h
> > index 0c0ab2486e23..a4a4739d0dd7 100644
> > --- a/include/configs/lsxl.h
> > +++ b/include/configs/lsxl.h
> > @@ -13,11 +13,9 @@
> >  #if defined(CONFIG_LSCHLV2)
> >  #define CONFIG_SYS_KWD_CONFIG $(CONFIG_BOARDDIR)/kwbimage-lschl.cfg
> >  #define CONFIG_MACH_TYPE 3006
> > -#define CONFIG_SYS_TCLK 16667 /* 166 MHz */
> >  #elif defined(CONFIG_LSXHL)
> >  #define CONFIG_SYS_KWD_CONFIG $(CONFIG_BOARDDIR)/kwbimage-lsxhl.cfg
> >  #define CONFIG_MACH_TYPE 2663
> > -/* CONFIG_SYS_TCLK is 2 by default */
> >  #else
> >  #error "unknown board"
> >  #endif
> > --
> > 2.20.1
> >



Re: [PATCH] dt-bindings: nvmem: u-boot,env: add basic NVMEM cells

2022-08-16 Thread Rafał Miłecki

On 3.07.2022 10:48, Rafał Miłecki wrote:

U-Boot doesn't have cells at hardcoded addresses. They are stored in
internal format. It's still important to define relevant cells in DT so
NVMEM consumers can reference them.

Update binding to allow including basic cells as NVMEM device subnodes.


Ping :)


For a reference you can see Broadcom's NVRAM (identical feature):

084973e944bec ("dt-bindings: nvmem: brcm,nvram: add basic NVMEM cells")
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=084973e944bec21804f8afb0515b25434438699a

c8442f0fb09ca ("ARM: dts: BCM5301X: Add Ethernet MAC address to Luxul XWR-3150")
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c8442f0fb09ca3d842b9b23d1d0650f649fd10f8


[PATCH v4 13/13] binman: Support missing compression tools

2022-08-16 Thread Stefan Herbrechtsmeier
From: Stefan Herbrechtsmeier 

Handle missing compression tools by returning empty data and marking the
entry as 'missing'.

Signed-off-by: Stefan Herbrechtsmeier 

---

Changes in v4:
- Add missing 236_compress_dtb_missing_bintool.dts file

Changes in v3:
- Added

 tools/binman/entry.py|  4 
 tools/binman/ftest.py|  8 
 .../test/236_compress_dtb_missing_bintool.dts| 16 
 3 files changed, 28 insertions(+)
 create mode 100644 tools/binman/test/236_compress_dtb_missing_bintool.dts

diff --git a/tools/binman/entry.py b/tools/binman/entry.py
index 9ec5811b46..c86b757a4e 100644
--- a/tools/binman/entry.py
+++ b/tools/binman/entry.py
@@ -1078,7 +1078,11 @@ features to produce new behaviours.
 """
 self.uncomp_data = indata
 if self.compress != 'none':
+if not comp_util.is_present(self.compress):
+self.missing = True
+return b''
 self.uncomp_size = len(indata)
+
 data = comp_util.compress(indata, self.compress)
 return data
 
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index a360ebeef5..eac7ccb087 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -2557,6 +2557,14 @@ class TestFunctional(unittest.TestCase):
 }
 self.assertEqual(expected, props)
 
+def testCompressMissingBintool(self):
+"""Test that compress of device-tree files with missing bintool is
+supported
+"""
+data = self.data = 
self._DoReadFileRealDtb('236_compress_dtb_missing_bintool.dts')
+self.assertEqual(U_BOOT_DATA, data[:len(U_BOOT_DATA)])
+dtb_data = data[len(U_BOOT_DATA):]
+self.assertEqual(0, len(dtb_data))
 
 def testCbfsUpdateFdt(self):
 """Test that we can update the device tree with CBFS offset/size 
info"""
diff --git a/tools/binman/test/236_compress_dtb_missing_bintool.dts 
b/tools/binman/test/236_compress_dtb_missing_bintool.dts
new file mode 100644
index 00..e7ce1b893d
--- /dev/null
+++ b/tools/binman/test/236_compress_dtb_missing_bintool.dts
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   binman {
+   u-boot {
+   };
+   u-boot-dtb {
+   compress = "_testing";
+   };
+   };
+};
-- 
2.30.2



[PATCH v4 12/13] binman: Add zstd bintool

2022-08-16 Thread Stefan Herbrechtsmeier
From: Stefan Herbrechtsmeier 

Add zstd bintool to binman to support on-the-fly compression.

Signed-off-by: Stefan Herbrechtsmeier 

---

(no changes since v3)

Changes in v3:
- Rebase

Changes in v2:
- Added

 tools/binman/btool/zstd.py | 30 ++
 tools/binman/comp_util.py  |  4 +++-
 tools/binman/etype/blob_dtb.py |  4 
 tools/binman/ftest.py  |  3 ++-
 4 files changed, 39 insertions(+), 2 deletions(-)
 create mode 100644 tools/binman/btool/zstd.py

diff --git a/tools/binman/btool/zstd.py b/tools/binman/btool/zstd.py
new file mode 100644
index 00..299bd37126
--- /dev/null
+++ b/tools/binman/btool/zstd.py
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2022 Weidmüller Interface GmbH & Co. KG
+# Stefan Herbrechtsmeier 
+#
+"""Bintool implementation for zstd
+
+zstd allows compression and decompression of files.
+
+Documentation is available via::
+
+   man zstd
+"""
+
+from binman import bintool
+
+# pylint: disable=C0103
+class Bintoolzstd(bintool.BintoolPacker):
+"""Compression/decompression using the zstd algorithm
+
+This bintool supports running `zstd` to compress and decompress data, as
+used by binman.
+
+It is also possible to fetch the tool, which uses `apt` to install it.
+
+Documentation is available via::
+
+man zstd
+"""
+def __init__(self, name):
+super().__init__(name)
diff --git a/tools/binman/comp_util.py b/tools/binman/comp_util.py
index 8c0fe5078f..6b4ab646e0 100644
--- a/tools/binman/comp_util.py
+++ b/tools/binman/comp_util.py
@@ -13,6 +13,7 @@ This supports the following compression algorithm:
   lzma
   lzo
   xz
+  zstd
 
 Note that for lzma this uses an old version of the algorithm, not that
 provided by xz.
@@ -24,6 +25,7 @@ This requires the following tools:
   lzma_alone
   lzop
   xz
+  zstd
 
 It also requires an output directory to be previously set up, by calling
 PrepareOutputDir().
@@ -35,7 +37,7 @@ from binman import bintool
 from patman import tools
 
 # Supported compression algorithms
-ALGORITHMS = ['bzip2', 'gzip', 'lz4', 'lzma', 'lzo', 'xz']
+ALGORITHMS = ['bzip2', 'gzip', 'lz4', 'lzma', 'lzo', 'xz', 'zstd']
 
 bintools = {}
 
diff --git a/tools/binman/etype/blob_dtb.py b/tools/binman/etype/blob_dtb.py
index 4fd2ecda83..fab79e43cc 100644
--- a/tools/binman/etype/blob_dtb.py
+++ b/tools/binman/etype/blob_dtb.py
@@ -48,6 +48,10 @@ class Entry_blob_dtb(Entry_blob):
 def ProcessContents(self):
 """Re-read the DTB contents so that we get any calculated properties"""
 _, indata = state.GetFdtContents(self.GetFdtEtype())
+
+if self.compress == 'zstd' and self.prepend != 'length':
+self.Raise('The zstd compression requires a length header')
+
 data = self.CompressData(indata)
 if self.prepend == 'length':
 hdr = struct.pack('

[PATCH v4 11/13] binman: Add xz bintool

2022-08-16 Thread Stefan Herbrechtsmeier
From: Stefan Herbrechtsmeier 

Add xz bintool to binman to support on-the-fly compression.

Signed-off-by: Stefan Herbrechtsmeier 

---

(no changes since v3)

Changes in v3:
- Rebase

Changes in v2:
- Added

 tools/binman/btool/xz.py  | 31 +++
 tools/binman/comp_util.py |  4 +++-
 2 files changed, 34 insertions(+), 1 deletion(-)
 create mode 100644 tools/binman/btool/xz.py

diff --git a/tools/binman/btool/xz.py b/tools/binman/btool/xz.py
new file mode 100644
index 00..e2b413d18b
--- /dev/null
+++ b/tools/binman/btool/xz.py
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2022 Weidmüller Interface GmbH & Co. KG
+# Stefan Herbrechtsmeier 
+#
+"""Bintool implementation for xz
+
+xz allows compression and decompression of files.
+
+Documentation is available via::
+
+   man xz
+"""
+
+from binman import bintool
+
+# pylint: disable=C0103
+class Bintoolxz(bintool.BintoolPacker):
+"""Compression/decompression using the xz algorithm
+
+This bintool supports running `xz` to compress and decompress data, as
+used by binman.
+
+It is also possible to fetch the tool, which uses `apt` to install it.
+
+Documentation is available via::
+
+man xz
+"""
+def __init__(self, name):
+super().__init__(name, fetch_package='xz-utils',
+ version_regex=r'xz \(XZ Utils\) ([0-9.]+)')
diff --git a/tools/binman/comp_util.py b/tools/binman/comp_util.py
index d8fdd5c7a2..8c0fe5078f 100644
--- a/tools/binman/comp_util.py
+++ b/tools/binman/comp_util.py
@@ -12,6 +12,7 @@ This supports the following compression algorithm:
   lz4
   lzma
   lzo
+  xz
 
 Note that for lzma this uses an old version of the algorithm, not that
 provided by xz.
@@ -22,6 +23,7 @@ This requires the following tools:
   lz4
   lzma_alone
   lzop
+  xz
 
 It also requires an output directory to be previously set up, by calling
 PrepareOutputDir().
@@ -33,7 +35,7 @@ from binman import bintool
 from patman import tools
 
 # Supported compression algorithms
-ALGORITHMS = ['bzip2', 'gzip', 'lz4', 'lzma', 'lzo']
+ALGORITHMS = ['bzip2', 'gzip', 'lz4', 'lzma', 'lzo', 'xz']
 
 bintools = {}
 
-- 
2.30.2



[PATCH v4 10/13] binman: Add lzop bintool

2022-08-16 Thread Stefan Herbrechtsmeier
From: Stefan Herbrechtsmeier 

Add lzop bintool to binman to support on-the-fly compression.

Signed-off-by: Stefan Herbrechtsmeier 

---

(no changes since v3)

Changes in v3:
- Rebase

Changes in v2:
- Added

 tools/binman/btool/lzop.py | 30 ++
 tools/binman/comp_util.py  |  6 --
 2 files changed, 34 insertions(+), 2 deletions(-)
 create mode 100644 tools/binman/btool/lzop.py

diff --git a/tools/binman/btool/lzop.py b/tools/binman/btool/lzop.py
new file mode 100644
index 00..f6903b4db7
--- /dev/null
+++ b/tools/binman/btool/lzop.py
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2022 Weidmüller Interface GmbH & Co. KG
+# Stefan Herbrechtsmeier 
+#
+"""Bintool implementation for lzop
+
+lzop allows compression and decompression of files.
+
+Documentation is available via::
+
+   man lzop
+"""
+
+from binman import bintool
+
+# pylint: disable=C0103
+class Bintoollzop(bintool.BintoolPacker):
+"""Compression/decompression using the lzop algorithm
+
+This bintool supports running `lzop` to compress and decompress data, as
+used by binman.
+
+It is also possible to fetch the tool, which uses `apt` to install it.
+
+Documentation is available via::
+
+man lzop
+"""
+def __init__(self, name):
+super().__init__(name, 'lzo', compress_args=[])
diff --git a/tools/binman/comp_util.py b/tools/binman/comp_util.py
index 19627e490c..d8fdd5c7a2 100644
--- a/tools/binman/comp_util.py
+++ b/tools/binman/comp_util.py
@@ -11,6 +11,7 @@ This supports the following compression algorithm:
   gzip
   lz4
   lzma
+  lzo
 
 Note that for lzma this uses an old version of the algorithm, not that
 provided by xz.
@@ -20,6 +21,7 @@ This requires the following tools:
   gzip
   lz4
   lzma_alone
+  lzop
 
 It also requires an output directory to be previously set up, by calling
 PrepareOutputDir().
@@ -31,7 +33,7 @@ from binman import bintool
 from patman import tools
 
 # Supported compression algorithms
-ALGORITHMS = ['bzip2', 'gzip', 'lz4', 'lzma']
+ALGORITHMS = ['bzip2', 'gzip', 'lz4', 'lzma', 'lzo']
 
 bintools = {}
 
@@ -44,7 +46,7 @@ def _get_tool_name(algo):
 Returns:
 str: Tool name
 """
-names = {'lzma': 'lzma_alone'}
+names = {'lzma': 'lzma_alone', 'lzo': 'lzop'}
 return names.get(algo, algo)
 
 def _get_tool(algo):
-- 
2.30.2



[PATCH v4 09/13] binman: Add gzip bintool

2022-08-16 Thread Stefan Herbrechtsmeier
From: Stefan Herbrechtsmeier 

Add gzip bintool to binman to support on-the-fly compression of Linux
kernel images and FPGA bitstreams. The SPL basic fitImage implementation
supports only gzip decompression.

Signed-off-by: Stefan Herbrechtsmeier 

---

(no changes since v3)

Changes in v3:
- Rebase

Changes in v2:
- Added

 tools/binman/btool/gzip.py | 31 +++
 tools/binman/comp_util.py  |  4 +++-
 2 files changed, 34 insertions(+), 1 deletion(-)
 create mode 100644 tools/binman/btool/gzip.py

diff --git a/tools/binman/btool/gzip.py b/tools/binman/btool/gzip.py
new file mode 100644
index 00..0d75028120
--- /dev/null
+++ b/tools/binman/btool/gzip.py
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2022 Weidmüller Interface GmbH & Co. KG
+# Stefan Herbrechtsmeier 
+#
+"""Bintool implementation for gzip
+
+gzip allows compression and decompression of files.
+
+Documentation is available via::
+
+   man gzip
+"""
+
+from binman import bintool
+
+# pylint: disable=C0103
+class Bintoolgzip(bintool.BintoolPacker):
+"""Compression/decompression using the gzip algorithm
+
+This bintool supports running `gzip` to compress and decompress data, as
+used by binman.
+
+It is also possible to fetch the tool, which uses `apt` to install it.
+
+Documentation is available via::
+
+man gzip
+"""
+def __init__(self, name):
+super().__init__(name, compress_args=[],
+ version_regex=r'gzip ([0-9.]+)')
diff --git a/tools/binman/comp_util.py b/tools/binman/comp_util.py
index 6ec371b145..19627e490c 100644
--- a/tools/binman/comp_util.py
+++ b/tools/binman/comp_util.py
@@ -8,6 +8,7 @@
 This supports the following compression algorithm:
   none
   bzip2
+  gzip
   lz4
   lzma
 
@@ -16,6 +17,7 @@ provided by xz.
 
 This requires the following tools:
   bzip2
+  gzip
   lz4
   lzma_alone
 
@@ -29,7 +31,7 @@ from binman import bintool
 from patman import tools
 
 # Supported compression algorithms
-ALGORITHMS = ['bzip2', 'lz4', 'lzma']
+ALGORITHMS = ['bzip2', 'gzip', 'lz4', 'lzma']
 
 bintools = {}
 
-- 
2.30.2



[PATCH v4 08/13] binman: Add bzip2 bintool

2022-08-16 Thread Stefan Herbrechtsmeier
From: Stefan Herbrechtsmeier 

Add bzip2 bintool to binman to support on-the-fly compression.

Signed-off-by: Stefan Herbrechtsmeier 

---

(no changes since v3)

Changes in v3:
- Rebase

Changes in v2:
- Added

 tools/binman/btool/bzip2.py | 30 ++
 tools/binman/comp_util.py   |  4 +++-
 2 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 tools/binman/btool/bzip2.py

diff --git a/tools/binman/btool/bzip2.py b/tools/binman/btool/bzip2.py
new file mode 100644
index 00..9be87a621f
--- /dev/null
+++ b/tools/binman/btool/bzip2.py
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2022 Weidmüller Interface GmbH & Co. KG
+# Stefan Herbrechtsmeier 
+#
+"""Bintool implementation for bzip2
+
+bzip2 allows compression and decompression of files.
+
+Documentation is available via::
+
+   man bzip2
+"""
+
+from binman import bintool
+
+# pylint: disable=C0103
+class Bintoolbzip2(bintool.BintoolPacker):
+"""Compression/decompression using the bzip2 algorithm
+
+This bintool supports running `bzip2` to compress and decompress data, as
+used by binman.
+
+It is also possible to fetch the tool, which uses `apt` to install it.
+
+Documentation is available via::
+
+man bzip2
+"""
+def __init__(self, name):
+super().__init__(name, version_regex=r'bzip2.*Version ([0-9.]+)')
diff --git a/tools/binman/comp_util.py b/tools/binman/comp_util.py
index 00761d44cc..6ec371b145 100644
--- a/tools/binman/comp_util.py
+++ b/tools/binman/comp_util.py
@@ -7,6 +7,7 @@
 
 This supports the following compression algorithm:
   none
+  bzip2
   lz4
   lzma
 
@@ -14,6 +15,7 @@ Note that for lzma this uses an old version of the algorithm, 
not that
 provided by xz.
 
 This requires the following tools:
+  bzip2
   lz4
   lzma_alone
 
@@ -27,7 +29,7 @@ from binman import bintool
 from patman import tools
 
 # Supported compression algorithms
-ALGORITHMS = ['lz4', 'lzma']
+ALGORITHMS = ['bzip2', 'lz4', 'lzma']
 
 bintools = {}
 
-- 
2.30.2



[PATCH v4 06/13] binman: Add compression tests

2022-08-16 Thread Stefan Herbrechtsmeier
From: Stefan Herbrechtsmeier 

Add common test functions to test all supported compressions.

Signed-off-by: Stefan Herbrechtsmeier 
Reviewed-by: Simon Glass 

---
Instead of the for loop it is possible to use Parameterized [1] testing.

[1] https://github.com/wolever/parameterized

(no changes since v3)

Changes in v3:
- Use 'tools.get_bytes(0, 64)' instead of 'bytes([0]) * 64'
- Check if tool is present
- Rename tests

Changes in v2:
- Added

 tools/binman/ftest.py | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 96c15cff77..bc17107735 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -5248,6 +5248,37 @@ fdt fdtmapExtract the devicetree 
blob from the fdtmap
 comp_util.decompress(b'1234', 'invalid')
 self.assertIn("Unknown algorithm 'invalid'", str(e.exception))
 
+def _checkCompUtil(self, algo):
+if not comp_util.is_present(algo):
+self.skipTest('%s not available' % comp_util._get_tool_name(algo))
+
+def testCompUtilCompressions(self):
+"""Test compression algorithms"""
+for algo in comp_util.ALGORITHMS:
+self._checkCompUtil(algo)
+data = comp_util.compress(COMPRESS_DATA, algo)
+self.assertNotEqual(COMPRESS_DATA, data)
+orig = comp_util.decompress(data, algo)
+self.assertEquals(COMPRESS_DATA, orig)
+
+def testCompUtilVersions(self):
+"""Test tool version of compression algorithms"""
+for algo in comp_util.ALGORITHMS:
+self._checkCompUtil(algo)
+tool = comp_util._get_tool(algo)
+version = tool.version()
+print('%s - %s' % (algo, version))
+self.assertRegex(version, '^v?[0-9]+[0-9.]*')
+
+def testCompUtilPadding(self):
+"""Test padding of compression algorithms"""
+for algo in comp_util.ALGORITHMS:
+self._checkCompUtil(algo)
+data = comp_util.compress(COMPRESS_DATA, algo)
+data = data + tools.get_bytes(0, 64)
+orig = comp_util.decompress(data, algo)
+self.assertEquals(COMPRESS_DATA, orig)
+
 def testBintoolDocs(self):
 """Test for creation of bintool documentation"""
 with test_util.capture_sys_output() as (stdout, stderr):
-- 
2.30.2



[PATCH v4 07/13] binman: Add BintoolPacker class to bintool

2022-08-16 Thread Stefan Herbrechtsmeier
From: Stefan Herbrechtsmeier 

Add a bintools base class for packers which compression / decompression
entry contents.

Signed-off-by: Stefan Herbrechtsmeier 

---

(no changes since v3)

Changes in v3:
- Document class properties

Changes in v2:
- Added

 tools/binman/bintool.py | 107 
 1 file changed, 107 insertions(+)

diff --git a/tools/binman/bintool.py b/tools/binman/bintool.py
index 8435b29749..2eaad418f2 100644
--- a/tools/binman/bintool.py
+++ b/tools/binman/bintool.py
@@ -1,5 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0+
 # Copyright 2022 Google LLC
+# Copyright (C) 2022 Weidmüller Interface GmbH & Co. KG
+# Stefan Herbrechtsmeier 
 #
 """Base class for all bintools
 
@@ -464,3 +466,108 @@ binaries. It is fairly easy to create new bintools. Just 
add a new file to the
 str: Version string for this bintool
 """
 return 'unknown'
+
+class BintoolPacker(Bintool):
+"""Tool which compression / decompression entry contents
+
+This is a bintools base class for compression / decompression packer
+
+Properties:
+name: Name of packer tool
+compression: Compression type (COMPRESS_...), value of 'name' property
+if none
+compress_args: List of positional args provided to tool for compress,
+['--compress'] if none
+decompress_args: List of positional args provided to tool for
+decompress, ['--decompress'] if none
+fetch_package: Name of the tool installed using the apt, value of 
'name'
+property if none
+version_regex: Regular expressions to extract the version from tool
+version output,  '(v[0-9.]+)' if none
+"""
+def __init__(self, name, compression=None, compress_args=None,
+ decompress_args=None, fetch_package=None,
+ version_regex=r'(v[0-9.]+)'):
+desc = '%s compression' % (compression if compression else name)
+super().__init__(name, desc)
+if compress_args is None:
+compress_args = ['--compress']
+self.compress_args = compress_args
+if decompress_args is None:
+decompress_args = ['--decompress']
+self.decompress_args = decompress_args
+if fetch_package is None:
+fetch_package = name
+self.fetch_package = fetch_package
+self.version_regex = version_regex
+
+def compress(self, indata):
+"""Compress data
+
+Args:
+indata (bytes): Data to compress
+
+Returns:
+bytes: Compressed data
+"""
+with tempfile.NamedTemporaryFile(prefix='comp.tmp',
+ dir=tools.get_output_dir()) as tmp:
+tools.write_file(tmp.name, indata)
+args = self.compress_args + ['--stdout', tmp.name]
+return self.run_cmd(*args, binary=True)
+
+def decompress(self, indata):
+"""Decompress data
+
+Args:
+indata (bytes): Data to decompress
+
+Returns:
+bytes: Decompressed data
+"""
+with tempfile.NamedTemporaryFile(prefix='decomp.tmp',
+ dir=tools.get_output_dir()) as inf:
+tools.write_file(inf.name, indata)
+args = self.decompress_args + ['--stdout', inf.name]
+return self.run_cmd(*args, binary=True)
+
+def fetch(self, method):
+"""Fetch handler
+
+This installs the gzip package using the apt utility.
+
+Args:
+method (FETCH_...): Method to use
+
+Returns:
+True if the file was fetched and now installed, None if a method
+other than FETCH_BIN was requested
+
+Raises:
+Valuerror: Fetching could not be completed
+"""
+if method != FETCH_BIN:
+return None
+pkg = self.fetch_package if self.fetch_package else self.name
+return self.apt_install(pkg)
+
+def version(self):
+"""Version handler
+
+Returns:
+str: Version number
+"""
+import re
+
+result = self.run_cmd_result('-V')
+if not result:
+return super().version()
+
+out = result.stdout.strip()
+if not out:
+out = result.stderr.strip()
+if not out:
+return super().version()
+
+m_version = re.search(self.version_regex, out)
+return m_version.group(1) if m_version else out
-- 
2.30.2



[PATCH v4 04/13] binman: Remove obsolete compressed data header handling

2022-08-16 Thread Stefan Herbrechtsmeier
From: Stefan Herbrechtsmeier 

Remove the obsolete compressed data header handling from the utilities
to compress and decompress data. The header is uncommon, not supported
by U-Boot and incompatible with external compressed artifacts.

Signed-off-by: Stefan Herbrechtsmeier 
---

(no changes since v3)

Changes in v3:
- Added

 tools/binman/cbfs_util.py |  8 
 tools/binman/comp_util.py | 11 ++-
 tools/binman/entry.py |  4 ++--
 tools/binman/etype/section.py |  3 +--
 tools/binman/ftest.py | 10 --
 5 files changed, 13 insertions(+), 23 deletions(-)

diff --git a/tools/binman/cbfs_util.py b/tools/binman/cbfs_util.py
index 9cad03886f..a1836f4ad3 100644
--- a/tools/binman/cbfs_util.py
+++ b/tools/binman/cbfs_util.py
@@ -241,9 +241,9 @@ class CbfsFile(object):
 """Handle decompressing data if necessary"""
 indata = self.data
 if self.compress == COMPRESS_LZ4:
-data = comp_util.decompress(indata, 'lz4', with_header=False)
+data = comp_util.decompress(indata, 'lz4')
 elif self.compress == COMPRESS_LZMA:
-data = comp_util.decompress(indata, 'lzma', with_header=False)
+data = comp_util.decompress(indata, 'lzma')
 else:
 data = indata
 self.memlen = len(data)
@@ -362,9 +362,9 @@ class CbfsFile(object):
 elif self.ftype == TYPE_RAW:
 orig_data = data
 if self.compress == COMPRESS_LZ4:
-data = comp_util.compress(orig_data, 'lz4', with_header=False)
+data = comp_util.compress(orig_data, 'lz4')
 elif self.compress == COMPRESS_LZMA:
-data = comp_util.compress(orig_data, 'lzma', with_header=False)
+data = comp_util.compress(orig_data, 'lzma')
 self.memlen = len(orig_data)
 self.data_len = len(data)
 attr = struct.pack(ATTR_COMPRESSION_FORMAT,
diff --git a/tools/binman/comp_util.py b/tools/binman/comp_util.py
index dc76adab35..269bbf7975 100644
--- a/tools/binman/comp_util.py
+++ b/tools/binman/comp_util.py
@@ -3,7 +3,6 @@
 #
 """Utilities to compress and decompress data"""
 
-import struct
 import tempfile
 
 from binman import bintool
@@ -16,7 +15,7 @@ LZMA_ALONE = bintool.Bintool.create('lzma_alone')
 HAVE_LZMA_ALONE = LZMA_ALONE.is_present()
 
 
-def compress(indata, algo, with_header=True):
+def compress(indata, algo):
 """Compress some data using a given algorithm
 
 Note that for lzma this uses an old version of the algorithm, not that
@@ -41,12 +40,9 @@ def compress(indata, algo, with_header=True):
 data = LZMA_ALONE.compress(indata)
 else:
 raise ValueError("Unknown algorithm '%s'" % algo)
-if with_header:
-hdr = struct.pack('

[PATCH v4 05/13] binman: Simplify comp_util class

2022-08-16 Thread Stefan Herbrechtsmeier
From: Stefan Herbrechtsmeier 

Simplify the comp_util class by remove duplicate code as preparation for
additional compress algorithms.

Signed-off-by: Stefan Herbrechtsmeier 

---

(no changes since v3)

Changes in v3:
- Rename COMPRESSIONS to ALGORITHMS
- Rework existing comments
- Add _get_tool_name function comment
- Add _get_tool function comment

 tools/binman/cbfs_util_test.py |   2 +-
 tools/binman/comp_util.py  | 101 +++--
 tools/binman/ftest.py  |   2 +-
 3 files changed, 72 insertions(+), 33 deletions(-)

diff --git a/tools/binman/cbfs_util_test.py b/tools/binman/cbfs_util_test.py
index f86b295149..44ebd04278 100755
--- a/tools/binman/cbfs_util_test.py
+++ b/tools/binman/cbfs_util_test.py
@@ -50,7 +50,7 @@ class TestCbfs(unittest.TestCase):
 cls.cbfstool = bintool.Bintool.create('cbfstool')
 cls.have_cbfstool = cls.cbfstool.is_present()
 
-cls.have_lz4 = comp_util.HAVE_LZ4
+cls.have_lz4 = comp_util.is_present('lz4')
 
 @classmethod
 def tearDownClass(cls):
diff --git a/tools/binman/comp_util.py b/tools/binman/comp_util.py
index 269bbf7975..00761d44cc 100644
--- a/tools/binman/comp_util.py
+++ b/tools/binman/comp_util.py
@@ -1,69 +1,108 @@
 # SPDX-License-Identifier: GPL-2.0+
 # Copyright 2022 Google LLC
+# Copyright (C) 2022 Weidmüller Interface GmbH & Co. KG
+# Stefan Herbrechtsmeier 
 #
-"""Utilities to compress and decompress data"""
+"""Utilities to compress and decompress data
+
+This supports the following compression algorithm:
+  none
+  lz4
+  lzma
+
+Note that for lzma this uses an old version of the algorithm, not that
+provided by xz.
+
+This requires the following tools:
+  lz4
+  lzma_alone
+
+It also requires an output directory to be previously set up, by calling
+PrepareOutputDir().
+"""
 
 import tempfile
 
 from binman import bintool
 from patman import tools
 
-LZ4 = bintool.Bintool.create('lz4')
-HAVE_LZ4 = LZ4.is_present()
+# Supported compression algorithms
+ALGORITHMS = ['lz4', 'lzma']
 
-LZMA_ALONE = bintool.Bintool.create('lzma_alone')
-HAVE_LZMA_ALONE = LZMA_ALONE.is_present()
+bintools = {}
 
+def _get_tool_name(algo):
+"""Get the tool name of a compression algorithm
 
-def compress(indata, algo):
-"""Compress some data using a given algorithm
+Args:
+algo (str): Algorithm to use
 
-Note that for lzma this uses an old version of the algorithm, not that
-provided by xz.
+Returns:
+str: Tool name
+"""
+names = {'lzma': 'lzma_alone'}
+return names.get(algo, algo)
+
+def _get_tool(algo):
+"""Get the bintool object of a compression algorithm
 
-This requires 'lz4' and 'lzma_alone' tools. It also requires an output
-directory to be previously set up, by calling PrepareOutputDir().
+The function creates new bintool object on demand per compression algorithm
+and save it in a global bintools dictionary.
+
+Args:
+algo (str): Algorithm to use
+
+Returns:
+A bintool object for the compression algorithm
+"""
+global bintools
+name = _get_tool_name(algo)
+tool = bintools.get(name)
+if not tool:
+tool = bintool.Bintool.create(name)
+bintools[name] = tool
+return tool
+
+def compress(indata, algo):
+"""Compress some data using a given algorithm
 
 Args:
 indata (bytes): Input data to compress
-algo (str): Algorithm to use ('none', 'lz4' or 'lzma')
+algo (str): Algorithm to use
 
 Returns:
 bytes: Compressed data
 """
 if algo == 'none':
 return indata
-if algo == 'lz4':
-data = LZ4.compress(indata)
-# cbfstool uses a very old version of lzma
-elif algo == 'lzma':
-data = LZMA_ALONE.compress(indata)
-else:
+if algo not in ALGORITHMS:
 raise ValueError("Unknown algorithm '%s'" % algo)
+
+tool = _get_tool(algo)
+data = tool.compress(indata)
+
 return data
 
 def decompress(indata, algo):
 """Decompress some data using a given algorithm
 
-Note that for lzma this uses an old version of the algorithm, not that
-provided by xz.
-
-This requires 'lz4' and 'lzma_alone' tools. It also requires an output
-directory to be previously set up, by calling PrepareOutputDir().
-
 Args:
 indata (bytes): Input data to decompress
-algo (str): Algorithm to use ('none', 'lz4' or 'lzma')
+algo (str): Algorithm to use
 
 Returns:
-(bytes) Compressed data
+bytes: Decompressed data
 """
 if algo == 'none':
 return indata
-if algo == 'lz4':
-data = LZ4.decompress(indata)
-elif algo == 'lzma':
-data = LZMA_ALONE.decompress(indata)
-else:
+if algo not in ALGORITHMS:
 raise ValueError("Unknown algorithm '%s'" % algo)
+
+tool = _get_tool(algo)
+data = tool.decompress(indata)
+
 return data
+
+def is_present(algo):
+ tool = _get_tool(algo)
+ retu

[PATCH v4 03/13] binman: Disable compressed data header

2022-08-16 Thread Stefan Herbrechtsmeier
From: Stefan Herbrechtsmeier 

Disable the compressed data header of the utilities to compress and
decompress data. The header is uncommon, not supported by U-Boot and
incompatible with external compressed artifacts.

The header was introduced as part of commit eb0f4a4cb402 ("binman:
Support replacing data in a cbfs") to allow device tree entries to be
larger than the compressed contents.

Signed-off-by: Stefan Herbrechtsmeier 

---

(no changes since v3)

Changes in v3:
- Added

 tools/binman/entry.py |  2 +-
 tools/binman/etype/section.py |  3 ++-
 tools/binman/ftest.py | 18 +++---
 3 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/tools/binman/entry.py b/tools/binman/entry.py
index e3767aefa7..a45aeeaa59 100644
--- a/tools/binman/entry.py
+++ b/tools/binman/entry.py
@@ -1079,7 +1079,7 @@ features to produce new behaviours.
 self.uncomp_data = indata
 if self.compress != 'none':
 self.uncomp_size = len(indata)
-data = comp_util.compress(indata, self.compress)
+data = comp_util.compress(indata, self.compress, with_header=False)
 return data
 
 @classmethod
diff --git a/tools/binman/etype/section.py b/tools/binman/etype/section.py
index bd67238b91..0a92bf2386 100644
--- a/tools/binman/etype/section.py
+++ b/tools/binman/etype/section.py
@@ -777,7 +777,8 @@ class Entry_section(Entry):
 data = parent_data[offset:offset + child.size]
 if decomp:
 indata = data
-data = comp_util.decompress(indata, child.compress)
+data = comp_util.decompress(indata, child.compress,
+with_header=False)
 if child.uncomp_size:
 tout.info("%s: Decompressing data size %#x with algo '%s' to 
data size %#x" %
 (child.GetPath(), len(indata), child.compress,
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 1b468d8e6d..d082442bec 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -1967,7 +1967,7 @@ class TestFunctional(unittest.TestCase):
 self._ResetDtbs()
 
 def _decompress(self, data):
-return comp_util.decompress(data, 'lz4')
+return comp_util.decompress(data, 'lz4', with_header=False)
 
 def testCompress(self):
 """Test compression of blobs"""
@@ -4449,15 +4449,19 @@ class TestFunctional(unittest.TestCase):
 rest = base[len(U_BOOT_DATA):]
 
 # Check compressed data
-section1 = self._decompress(rest)
-expect1 = comp_util.compress(COMPRESS_DATA + U_BOOT_DATA, 'lz4')
-self.assertEquals(expect1, rest[:len(expect1)])
+expect1 = comp_util.compress(COMPRESS_DATA + U_BOOT_DATA, 'lz4',
+ with_header=False)
+data1 = rest[:len(expect1)]
+section1 = self._decompress(data1)
+self.assertEquals(expect1, data1)
 self.assertEquals(COMPRESS_DATA + U_BOOT_DATA, section1)
 rest1 = rest[len(expect1):]
 
-section2 = self._decompress(rest1)
-expect2 = comp_util.compress(COMPRESS_DATA + COMPRESS_DATA, 'lz4')
-self.assertEquals(expect2, rest1[:len(expect2)])
+expect2 = comp_util.compress(COMPRESS_DATA + COMPRESS_DATA, 'lz4',
+ with_header=False)
+data2 = rest1[:len(expect2)]
+section2 = self._decompress(data2)
+self.assertEquals(expect2, data2)
 self.assertEquals(COMPRESS_DATA + COMPRESS_DATA, section2)
 rest2 = rest1[len(expect2):]
 
-- 
2.30.2



[PATCH v4 02/13] binman: Add length header attribute to dtb entry

2022-08-16 Thread Stefan Herbrechtsmeier
From: Stefan Herbrechtsmeier 

Add an optional length header attribute to the device tree blob entry
class based on the compressed data header from the utilities to compress
and decompress data.

If needed the header could be enabled with the following
attribute beside the compress attribute:
  prepend = "length";

The header was introduced as part of commit eb0f4a4cb402 ("binman:
Support replacing data in a cbfs") to allow device tree entries to be
larger than the compressed contents. Regarding the commit "this is
necessary to cope with a compressed device tree being updated in such a
way that it shrinks after the entry size is already set (an obscure
case)". This case need to be fixed without influence any compressed data
by itself.

Signed-off-by: Stefan Herbrechtsmeier 

---

(no changes since v3)

Changes in v3:
- Move comp_util.py changes (drop with_header) into separate commits.

Changes in v2:
- Reworked to make the feature optional.

 tools/binman/entries.rst  |  3 +++
 tools/binman/etype/blob_dtb.py| 24 +++
 tools/binman/ftest.py | 22 +
 .../test/235_compress_prepend_length_dtb.dts  | 17 +
 4 files changed, 66 insertions(+)
 create mode 100644 tools/binman/test/235_compress_prepend_length_dtb.dts

diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index 782bff1f8d..c9336d1bb4 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -216,6 +216,9 @@ This is a blob containing a device tree. The contents of 
the blob are
 obtained from the list of available device-tree files, managed by the
 'state' module.
 
+Additional Properties / Entry arguments:
+- prepend: Header type to use:
+length: 32-bit length header
 
 
 .. _etype_blob_ext:
diff --git a/tools/binman/etype/blob_dtb.py b/tools/binman/etype/blob_dtb.py
index 4159e3032a..4fd2ecda83 100644
--- a/tools/binman/etype/blob_dtb.py
+++ b/tools/binman/etype/blob_dtb.py
@@ -7,6 +7,8 @@
 
 from binman.entry import Entry
 from binman.etype.blob import Entry_blob
+from dtoc import fdt_util
+import struct
 
 # This is imported if needed
 state = None
@@ -17,6 +19,9 @@ class Entry_blob_dtb(Entry_blob):
 This is a blob containing a device tree. The contents of the blob are
 obtained from the list of available device-tree files, managed by the
 'state' module.
+
+Additional attributes:
+prepend: Header used (e.g. 'length')
 """
 def __init__(self, section, etype, node):
 # Put this here to allow entry-docs and help to work without libfdt
@@ -25,6 +30,15 @@ class Entry_blob_dtb(Entry_blob):
 
 super().__init__(section, etype, node)
 
+self.prepend = None
+
+def ReadNode(self):
+super().ReadNode()
+self.prepend = fdt_util.GetString(self._node, 'prepend')
+if self.prepend and self.prepend not in ['length']:
+self.Raise("Invalid prepend in '%s': '%s'" %
+   (self._node.name, self.prepend))
+
 def ObtainContents(self):
 """Get the device-tree from the list held by the 'state' module"""
 self._filename = self.GetDefaultFilename()
@@ -35,6 +49,9 @@ class Entry_blob_dtb(Entry_blob):
 """Re-read the DTB contents so that we get any calculated properties"""
 _, indata = state.GetFdtContents(self.GetFdtEtype())
 data = self.CompressData(indata)
+if self.prepend == 'length':
+hdr = struct.pack(';
+   #size-cells = <1>;
+
+   binman {
+   u-boot {
+   };
+   u-boot-dtb {
+   compress = "lz4";
+   prepend = "length";
+   };
+   };
+};
-- 
2.30.2



[PATCH v4 01/13] binman: Skip elf tests if python elftools is not available

2022-08-16 Thread Stefan Herbrechtsmeier
From: Stefan Herbrechtsmeier 

Skip tests which requires python elftools if the tool is not available.

Signed-off-by: Stefan Herbrechtsmeier 
Reviewed-by: Simon Glass 

---

(no changes since v2)

Changes in v2:
- Added

 tools/binman/elf_test.py | 14 ++
 tools/binman/ftest.py| 18 ++
 2 files changed, 32 insertions(+)

diff --git a/tools/binman/elf_test.py b/tools/binman/elf_test.py
index 5a51c64cfe..75b867c2be 100644
--- a/tools/binman/elf_test.py
+++ b/tools/binman/elf_test.py
@@ -122,6 +122,8 @@ class TestElf(unittest.TestCase):
 
 def testOutsideFile(self):
 """Test a symbol which extends outside the entry area is detected"""
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 entry = FakeEntry(10)
 section = FakeSection()
 elf_fname = self.ElfTestFile('u_boot_binman_syms')
@@ -147,6 +149,8 @@ class TestElf(unittest.TestCase):
 Only 32 and 64 bits are supported, since we need to store an offset
 into the image.
 """
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 entry = FakeEntry(10)
 section = FakeSection()
 elf_fname =self.ElfTestFile('u_boot_binman_syms_size')
@@ -161,6 +165,8 @@ class TestElf(unittest.TestCase):
 This should produce -1 values for all thress symbols, taking up the
 first 16 bytes of the image.
 """
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 entry = FakeEntry(28)
 section = FakeSection(sym_value=None)
 elf_fname = self.ElfTestFile('u_boot_binman_syms')
@@ -172,6 +178,8 @@ class TestElf(unittest.TestCase):
 
 def testDebug(self):
 """Check that enabling debug in the elf module produced debug output"""
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 try:
 tout.init(tout.DEBUG)
 entry = FakeEntry(24)
@@ -281,6 +289,8 @@ class TestElf(unittest.TestCase):
 
 def test_read_segments_bad_data(self):
 """Test for read_loadable_segments() with an invalid ELF file"""
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 fname = self.ElfTestFile('embed_data')
 with self.assertRaises(ValueError) as e:
 elf.read_loadable_segments(tools.get_bytes(100, 100))
@@ -288,6 +298,8 @@ class TestElf(unittest.TestCase):
 
 def test_get_file_offset(self):
 """Test GetFileOffset() gives the correct file offset for a symbol"""
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 fname = self.ElfTestFile('embed_data')
 syms = elf.GetSymbols(fname, ['embed'])
 addr = syms['embed'].address
@@ -314,6 +326,8 @@ class TestElf(unittest.TestCase):
 
 def test_get_symbol_from_address(self):
 """Test GetSymbolFromAddress()"""
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 fname = self.ElfTestFile('elf_sections')
 sym_name = 'calculate'
 syms = elf.GetSymbols(fname, [sym_name])
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index fa1f421c05..da9aa9e679 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -4807,6 +4807,8 @@ class TestFunctional(unittest.TestCase):
 
 def testUpdateFdtInElf(self):
 """Test that we can update the devicetree in an ELF file"""
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 infile = elf_fname = self.ElfTestFile('u_boot_binman_embed')
 outfile = os.path.join(self._indir, 'u-boot.out')
 begin_sym = 'dtb_embed_begin'
@@ -4858,6 +4860,8 @@ class TestFunctional(unittest.TestCase):
 
 def testUpdateFdtInElfNoSyms(self):
 """Test that missing symbols are detected with --update-fdt-in-elf"""
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 infile = elf_fname = self.ElfTestFile('u_boot_binman_embed')
 outfile = ''
 begin_sym = 'wrong_begin'
@@ -4871,6 +4875,8 @@ class TestFunctional(unittest.TestCase):
 
 def testUpdateFdtInElfTooSmall(self):
 """Test that an over-large dtb is detected with --update-fdt-in-elf"""
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 infile = elf_fname = self.ElfTestFile('u_boot_binman_embed_sm')
 outfile = os.path.join(self._indir, 'u-boot.out')
 begin_sym = 'dtb_embed_begin'
@@ -5344,6 +5350,8 @@ fdt fdtmapExtract the devicetree 
blob from the fdtmap
 
 def testFitSplitElf(self):
 """Test an image with an FIT with an split-elf operation"""
+if not elf.ELF_TOOLS:
+self.skipTest('Python elftools not available')
 entry_args = {
 'of-l

Re: [PATCH v3 6/8] sandbox: Add cyclic demo function

2022-08-16 Thread Stefan Roese

Hi Simon,

On 05.08.22 18:48, Simon Glass wrote:

Hi Stefan,

On Fri, 5 Aug 2022 at 08:26, Stefan Roese  wrote:


This patch enables the cyclic infrastructure on sandbox and also adds
one simple example/demo functions using this cyclic functionality.

Signed-off-by: Stefan Roese 
---
v3:
- No change
v2:
- Extend CONFIG_CYCLIC_MAX_CPU_TIME_US to 1ms as running this
   in CI might take a bit longer

  board/sandbox/sandbox.c   | 15 +++
  configs/sandbox_defconfig |  3 +++
  2 files changed, 18 insertions(+)


This should have a test in test/common - e.g. using timer_test_add_offset()


Ok. I'll add a small test for the cyclic IF this in the next patchset
version.

Thanks,
Stefan



diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c
index ca9a2ca5b17c..8dda4b5f4fc9 100644
--- a/board/sandbox/sandbox.c
+++ b/board/sandbox/sandbox.c
@@ -7,6 +7,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -17,6 +18,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 

@@ -106,8 +108,21 @@ int dram_init(void)
 return 0;
  }

+static void cyclic_demo(void *ctx)
+{
+   /* Just a small dummy delay here */
+   udelay(10);
+}
+
  int board_init(void)
  {
+   struct cyclic_struct *cyclic;
+
+   /* Register demo cyclic function */
+   cyclic = cyclic_register(cyclic_demo, 10 * 1000, "cyclic_demo", NULL);
+   if (!cyclic)
+   printf("Registering of cyclic_demo failed\n");
+
 return 0;
  }

diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index eba7bcbb483b..8b6c003760f2 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -34,6 +34,8 @@ CONFIG_LOG=y
  CONFIG_LOG_MAX_LEVEL=9
  CONFIG_LOG_DEFAULT_LEVEL=6
  CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_CYCLIC=y
+CONFIG_CYCLIC_MAX_CPU_TIME_US=1
  CONFIG_STACKPROTECTOR=y
  CONFIG_ANDROID_AB=y
  CONFIG_CMD_CPU=y
@@ -114,6 +116,7 @@ CONFIG_CMD_EROFS=y
  CONFIG_CMD_EXT4_WRITE=y
  CONFIG_CMD_SQUASHFS=y
  CONFIG_CMD_MTDPARTS=y
+CONFIG_CMD_CYCLIC=y
  CONFIG_CMD_STACKPROTECTOR_TEST=y
  CONFIG_MAC_PARTITION=y
  CONFIG_AMIGA_PARTITION=y
--
2.37.1



Regards,
SImon


Viele Grüße,
Stefan Roese

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


Re: [PATCH] mtd: rawnand: fsl_elbc: Remove NAND_NO_SUBPAGE_WRITE flag

2022-08-16 Thread Michael Nazzareno Trimarchi
Hi

Il lun 15 ago 2022, 23:55 Pali Rohár  ha scritto:

> On Monday 15 August 2022 23:49:17 Michael Nazzareno Trimarchi wrote:
> > Hi
> >
> > Il lun 15 ago 2022, 10:01 Pali Rohár  ha scritto:
> >
> > > Subpage write support for freescale eLBC NAND controller driver is
> > > implemented in U-Boot and was fixes in the commit d3963721d93f ("nand:
> Sync
> > > with Linux v4.1").
> > >
> > > So remove NAND_NO_SUBPAGE_WRITE flag from the fsl_elbc_nand.c driver.
> This
> > > partially revert commit cb04c7723429 ("nand/fsl: add
> NAND_NO_SUBPAGE_WRITE
> > > to eLBC and IFC drivers"), only eLBC driver part.
> > >
> > > With this change U-Boot with default settings can read from NAND UBIFS
> > > image created on Linux with Linux default settings. Prior this change
> > > U-Boot was unable to read from NAND UBIFS images created with Linux
> default
> > > settings due to differnet UBI geometry.
> > >
> > > Linux kernel fsl_elbc_nand.c driver also does not set
> NAND_NO_SUBPAGE_WRITE
> > > flag and has implemented subpage write support.
> > >
> > > Fixes: cb04c7723429 ("nand/fsl: add NAND_NO_SUBPAGE_WRITE to eLBC and
> IFC
> > > drivers")
> > > Fixes: d3963721d93f ("nand: Sync with Linux v4.1")
> > > Signed-off-by: Pali Rohár 
> > > ---
> > > See also email thread:
> > >
> https://lore.kernel.org/u-boot/20220807120027.2zz43afbqtqljhul@pali/t/#u
> > > ---
> > >  drivers/mtd/nand/raw/fsl_elbc_nand.c | 1 -
> > >  1 file changed, 1 deletion(-)
> > >
> > > diff --git a/drivers/mtd/nand/raw/fsl_elbc_nand.c
> > > b/drivers/mtd/nand/raw/fsl_elbc_nand.c
> > > index 48a3687f2728..e28670a4724a 100644
> > > --- a/drivers/mtd/nand/raw/fsl_elbc_nand.c
> > > +++ b/drivers/mtd/nand/raw/fsl_elbc_nand.c
> > > @@ -732,7 +732,6 @@ static int fsl_elbc_chip_init(int devnum, u8 *addr,
> > > struct udevice *dev)
> > > nand->bbt_md = &bbt_mirror_descr;
> > >
> > > /* set up nand options */
> > > -   nand->options = NAND_NO_SUBPAGE_WRITE;
> > > nand->bbt_options = NAND_BBT_USE_FLASH;
> > >
> > > nand->controller = &elbc_ctrl->controller;
> > >
> >
> > Reviewed-by: Michael Trimarchi 
> >
> > I was following the thread. Please confirm that you was able to test
>
> Yes, I have tested this change on P2020 based board Turris 1.1. And
> finally U-Boot by default was able to access UBI created by mainline
> Linux with default parameters, just by calling 'ubi part rootfs'.
> UBI created by sub-page of size 2048 can be still also read by U-Boot by
> calling 'ubi part rootfs 2048'. For this purpose I already provided
> distroboot patch to easily specify UBI header offset (which is by
> default sub-page size):
> https://lore.kernel.org/u-boot/20220807190422.20157-1-p...@kernel.org/



Acked-By: Michael Trimarchi

I will send pull request tomorrow to Tom

Michael

>
>
> > Michael
> >
> > > --
> > > 2.20.1
> > >
> > >
>


Re: [PATCH v2 1/6] ARMv8/sec_firmware: Remove SEC_FIRMWARE_FIT_CNF_NAME

2022-08-16 Thread Peng Fan

Hi Sean,

On 4/23/2022 1:38 AM, Sean Anderson wrote:

The config to use for FIT images can be better specified by enabling
CONFIG_MULTI_DTB_FIT and implementing board_fit_config_name_match.

Signed-off-by: Sean Anderson 
---


This patchset not able to apply, could you please repost?

Thanks,
Peng.



(no changes since v1)

  arch/arm/cpu/armv8/sec_firmware.c | 17 -
  1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/arch/arm/cpu/armv8/sec_firmware.c 
b/arch/arm/cpu/armv8/sec_firmware.c
index 267894fbcb..41525a10d5 100644
--- a/arch/arm/cpu/armv8/sec_firmware.c
+++ b/arch/arm/cpu/armv8/sec_firmware.c
@@ -35,9 +35,6 @@ phys_addr_t sec_firmware_addr;
  #ifndef SEC_FIRMWARE_FIT_IMAGE
  #define SEC_FIRMWARE_FIT_IMAGE"firmware"
  #endif
-#ifndef SEC_FIRMWARE_FIT_CNF_NAME
-#define SEC_FIRMWARE_FIT_CNF_NAME  "config-1"
-#endif
  #ifndef SEC_FIRMWARE_TARGET_EL
  #define SEC_FIRMWARE_TARGET_EL2
  #endif
@@ -46,15 +43,12 @@ static int sec_firmware_get_data(const void 
*sec_firmware_img,
const void **data, size_t *size)
  {
int conf_node_off, fw_node_off;
-   char *conf_node_name = NULL;
char *desc;
int ret;
  
-	conf_node_name = SEC_FIRMWARE_FIT_CNF_NAME;

-
-   conf_node_off = fit_conf_get_node(sec_firmware_img, conf_node_name);
+   conf_node_off = fit_conf_get_node(sec_firmware_img, NULL);
if (conf_node_off < 0) {
-   printf("SEC Firmware: %s: no such config\n", conf_node_name);
+   puts("SEC Firmware: no config\n");
return -ENOENT;
}
  
@@ -123,18 +117,15 @@ static int sec_firmware_check_copy_loadable(const void *sec_firmware_img,

  {
phys_addr_t sec_firmware_loadable_addr = 0;
int conf_node_off, ld_node_off, images;
-   char *conf_node_name = NULL;
const void *data;
size_t size;
ulong load;
const char *name, *str, *type;
int len;
  
-	conf_node_name = SEC_FIRMWARE_FIT_CNF_NAME;

-
-   conf_node_off = fit_conf_get_node(sec_firmware_img, conf_node_name);
+   conf_node_off = fit_conf_get_node(sec_firmware_img, NULL);
if (conf_node_off < 0) {
-   printf("SEC Firmware: %s: no such config\n", conf_node_name);
+   puts("SEC Firmware: no config\n");
return -ENOENT;
}
  


  1   2   >