Re: [PATCH] MAINTAINERS: imx: Add an entry for the serial driver

[Peng Fan]

On 9/5/2022 6:57 PM, Fabio Estevam wrote:

From: Fabio Estevam 

Currently, when running ./scripts/get_maintainer.pl on serial_mxc.c
no i.MX maintainer is returned.

Fix it by adding an entry for this driver.

Reported-by: Pali Rohár 
Signed-off-by: Fabio Estevam 


Acked-by: Peng Fan 


---
  MAINTAINERS | 1 +
  1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 36a2b69fcb..83346183ee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -264,6 +264,7 @@ F:  arch/arm/include/asm/arch-mx*/
  F:arch/arm/include/asm/arch-vf610/
  F:arch/arm/include/asm/mach-imx/
  F:board/freescale/*mx*/
+F: drivers/serial/serial_mxc.c
  
  ARM HISILICON

  M:Peter Griffin 

Re: [PATCH] ddr: fsl: Make bank_addr_bits reflect actual bits

[Peng Fan]

On 8/31/2022 5:01 AM, Sean Anderson wrote:

In both the Freescale DDR controller and the SPD spec, bank address bits
are stored as the number of bank address bits minus 2. For example, if a
chip had 8 banks (3 total bank address bits), the value of
bank_addr_bits would be 1. This is rather surprising for users
configuring their memory manually, since they can't set bank_addr_bits
to the actual number of bank address bits. Rectify this.

There is at least one example of this kind of mistake already, in
board/freescale/t102xrdb/ddr.c. The documented MT40A512M8HX has two bank
address bits, but bank_addr_bits was set to 2, implying 4 bank address
bits. Such a value is reserved in BA_BITS_CS, but I suspect the
controller simply ignores the top bit, making this kind of mistake
harmless, if misleading.

Fixes: e8a7f1c32b5 ("powerpc/t1023rdb: Add T1023 RDB board support")
Signed-off-by: Sean Anderson 


In tag:
https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq/-/tags/fsl-qoriq-2022-9-6

Waiting CI results.

Regards,
Peng.


---

  board/freescale/ls1043ardb/ddr.c   | 2 +-
  drivers/ddr/fsl/ctrl_regs.c| 2 +-
  drivers/ddr/fsl/ddr4_dimm_params.c | 2 +-
  3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/board/freescale/ls1043ardb/ddr.c b/board/freescale/ls1043ardb/ddr.c
index 08b43ff5e4c..4d2fce38412 100644
--- a/board/freescale/ls1043ardb/ddr.c
+++ b/board/freescale/ls1043ardb/ddr.c
@@ -114,7 +114,7 @@ dimm_params_t ddr_raw_timing = {
.mirrored_dimm = 0,
.n_row_addr = 15,
.n_col_addr = 10,
-   .bank_addr_bits = 0,
+   .bank_addr_bits = 2,
.bank_group_bits = 2,
.edc_config = 0,
.burst_lengths_bitmask = 0x0c,
diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c
index b5122d1a1c3..0b0b4e5cb7e 100644
--- a/drivers/ddr/fsl/ctrl_regs.c
+++ b/drivers/ddr/fsl/ctrl_regs.c
@@ -214,7 +214,7 @@ static void set_csn_config(int dimm_number, int i, 
fsl_ddr_cfg_regs_t *ddr,
odt_rd_cfg = popts->cs_local_opts[i].odt_rd_cfg;
odt_wr_cfg = popts->cs_local_opts[i].odt_wr_cfg;
  #ifdef CONFIG_SYS_FSL_DDR4
-   ba_bits_cs_n = dimm_params[dimm_number].bank_addr_bits;
+   ba_bits_cs_n = dimm_params[dimm_number].bank_addr_bits - 2;
bg_bits_cs_n = dimm_params[dimm_number].bank_group_bits;
  #else
n_banks_per_sdram_device
diff --git a/drivers/ddr/fsl/ddr4_dimm_params.c 
b/drivers/ddr/fsl/ddr4_dimm_params.c
index e2bdc12ef2c..ea791622628 100644
--- a/drivers/ddr/fsl/ddr4_dimm_params.c
+++ b/drivers/ddr/fsl/ddr4_dimm_params.c
@@ -246,7 +246,7 @@ unsigned int ddr_compute_dimm_parameters(const unsigned int 
ctrl_num,
/* SDRAM device parameters */
pdimm->n_row_addr = ((spd->addressing >> 3) & 0x7) + 12;
pdimm->n_col_addr = (spd->addressing & 0x7) + 9;
-   pdimm->bank_addr_bits = (spd->density_banks >> 4) & 0x3;
+   pdimm->bank_addr_bits = ((spd->density_banks >> 4) & 0x3) + 2;
pdimm->bank_group_bits = (spd->density_banks >> 6) & 0x3;
  
  	/*

Re: [PATCH] ddr: fsl: Reduce the size of interactive options

[Peng Fan]

On 8/31/2022 4:54 AM, Sean Anderson wrote:

The interactive mode uses large several tables of options which can be
configured. However, much of the contents of these tables are
repetetive. For example, no struct is larger than half a kilobyte, so
the offset only takes up 9 bits. Similarly, the size is only ever 4 or
8, and printhex is a boolean. Reduce the size of these fields. This
reduces the size of the options tables by around 10 KiB. However, the
largest contributor to the size of the options tables is the use of a
pointer for the strings. A better approach would be to use a separate
array of strings, and store an integer index in the options tables.
However, this would require a large re-architecting of this file.

Signed-off-by: Sean Anderson 


In tag:
https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq/-/tags/fsl-qoriq-2022-9-6

Waiting CI results.

Regards,
Peng.


---

  drivers/ddr/fsl/interactive.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/ddr/fsl/interactive.c b/drivers/ddr/fsl/interactive.c
index 2f76beb2dbe..eb2f06e8300 100644
--- a/drivers/ddr/fsl/interactive.c
+++ b/drivers/ddr/fsl/interactive.c
@@ -27,9 +27,9 @@
  /* Option parameter Structures */
  struct options_string {
const char *option_name;
-   size_t offset;
-   unsigned int size;
-   const char printhex;
+   u32 offset : 9;
+   u32 size : 4;
+   u32 printhex : 1;
  };
  
  static unsigned int picos_to_mhz(unsigned int picos)

Re: [PATCH v2 1/4] board: freescale: p1_p2_rdb_pc: Add workaround for board reset reboot loop

[Peng Fan]

On 8/31/2022 8:04 PM, Pali Rohár wrote:

PING


In tag:
https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq/-/tags/fsl-qoriq-2022-9-6

Waiting CI results.

Regards,
Peng.



On Sunday 21 August 2022 12:30:04 Pali Rohár wrote:

PING I have not received any response for these patches.
Why you are ignoring me?

You have already merged commit "board: freescale: p1_p2_rdb_pc:
Implement board_reset()" from v1 of this patch series
https://source.denx.de/u-boot/u-boot/-/commit/20fb58fc5a1c83ee0085b2e9f7ecda8b761a5592
without applying reset workaround commit from v1 (also available in v2)
which effectively broke reset support in U-Boot.

Why you are continuing breaking P1/P2 boards?

Patches for this are already waiting on the list.

On Monday 01 August 2022 15:31:43 Pali Rohár wrote:

CPLD's system reset register on P1/P2 RDB boards is not autocleared after
flipping it. If this register is set to one in 100ms after reset starts
then CPLD triggers another CPU reset.

This means that trying to reset board via CPLD system reset register cause
reboot loop. To prevent this reboot loop, the only workaround is to try to
clear CPLD's system reset register as early as possible. U-Boot is already
doing it in its board_early_init_f() function, which seems to be enough as
register is cleared prior CPLD triggers another reset.

But board_early_init_f() is not called from SPL and therefore usage of SPL
can cause reboot loop.

To prevent reboot loop when using SPL, call board_early_init_f() function
in SPL too. For accessing CPLD memory space it is needed to have CPLD entry
in TLB.

With this change it is possible to trigger board reset via CPLD's system
reset register on P2020 RDB board.

Signed-off-by: Pali Rohár 
---
Changes in v2:
* Resend patch
* Update comment about watchdog
---
  board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 13 +
  board/freescale/p1_p2_rdb_pc/spl.c  |  6 ++
  board/freescale/p1_p2_rdb_pc/tlb.c  |  2 +-
  3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c 
b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
index 343059c09c36..84e1d65cdb1f 100644
--- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
+++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
@@ -97,6 +97,19 @@ void board_cpld_init(void)
out_8(_data->status_led, CPLD_STATUS_LED);
out_8(_data->fxo_led, CPLD_FXO_LED);
out_8(_data->fxs_led, CPLD_FXS_LED);
+
+   /*
+* CPLD's system reset register on P1/P2 RDB boards is not autocleared
+* after flipping it. If this register is set to one then CPLD triggers
+* reset of CPU in few ms.
+*
+* CPLD does not trigger reset of CPU for 100ms after the last reset.
+*
+* This means that trying to reset board via CPLD system reset register
+* cause reboot loop. To prevent this reboot loop, the only workaround
+* is to try to clear CPLD's system reset register as early as possible
+* and it has to be done in 100ms since the last start of reset.
+*/
out_8(_data->system_rst, CPLD_SYS_RST);
  }
  
diff --git a/board/freescale/p1_p2_rdb_pc/spl.c b/board/freescale/p1_p2_rdb_pc/spl.c

index 22156f2824ec..def28665960d 100644
--- a/board/freescale/p1_p2_rdb_pc/spl.c
+++ b/board/freescale/p1_p2_rdb_pc/spl.c
@@ -31,6 +31,12 @@ void board_init_f(ulong bootflag)
u32 plat_ratio, bus_clk;
ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
  
+	/*

+* Call board_early_init_f() as early as possible as it workarounds
+* reboot loop due to broken CPLD state machine for reset line.
+*/
+   board_early_init_f();
+
console_init_f();
  
  	/* Set pmuxcr to allow both i2c1 and i2c2 */

diff --git a/board/freescale/p1_p2_rdb_pc/tlb.c 
b/board/freescale/p1_p2_rdb_pc/tlb.c
index 13f3a1edf68d..2d431d6d0d90 100644
--- a/board/freescale/p1_p2_rdb_pc/tlb.c
+++ b/board/freescale/p1_p2_rdb_pc/tlb.c
@@ -61,11 +61,11 @@ struct fsl_e_tlb_entry tlb_table[] = {
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 5, BOOKE_PAGESZ_1M, 1),
  #endif
+#endif /* not SPL */
  
  	SET_TLB_ENTRY(1, CONFIG_SYS_CPLD_BASE, CONFIG_SYS_CPLD_BASE_PHYS,

MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 6, BOOKE_PAGESZ_1M, 1),
-#endif /* not SPL */
  
  #ifdef CONFIG_SYS_NAND_BASE

/* *I*G - NAND */
--
2.20.1

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

[Peng Fan]

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

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


Patch 6 failed to apply, could you please rebase?

Thanks,
Peng.



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

Re: [PATCH v2 1/4] board: freescale: p1_p2_rdb_pc: Add workaround for board reset reboot loop

[Peng Fan]

Hi Pali,

On 8/31/2022 8:04 PM, Pali Rohár wrote:

PING


Please cc me for freescale ppc boards. The patches not show in my 
patchwork[freenix].


I will put your patches into CI now.

Thanks,
Peng.



On Sunday 21 August 2022 12:30:04 Pali Rohár wrote:

PING I have not received any response for these patches.
Why you are ignoring me?

You have already merged commit "board: freescale: p1_p2_rdb_pc:
Implement board_reset()" from v1 of this patch series
https://source.denx.de/u-boot/u-boot/-/commit/20fb58fc5a1c83ee0085b2e9f7ecda8b761a5592
without applying reset workaround commit from v1 (also available in v2)
which effectively broke reset support in U-Boot.

Why you are continuing breaking P1/P2 boards? >>
Patches for this are already waiting on the list.

On Monday 01 August 2022 15:31:43 Pali Rohár wrote:

CPLD's system reset register on P1/P2 RDB boards is not autocleared after
flipping it. If this register is set to one in 100ms after reset starts
then CPLD triggers another CPU reset.

This means that trying to reset board via CPLD system reset register cause
reboot loop. To prevent this reboot loop, the only workaround is to try to
clear CPLD's system reset register as early as possible. U-Boot is already
doing it in its board_early_init_f() function, which seems to be enough as
register is cleared prior CPLD triggers another reset.

But board_early_init_f() is not called from SPL and therefore usage of SPL
can cause reboot loop.

To prevent reboot loop when using SPL, call board_early_init_f() function
in SPL too. For accessing CPLD memory space it is needed to have CPLD entry
in TLB.

With this change it is possible to trigger board reset via CPLD's system
reset register on P2020 RDB board.

Signed-off-by: Pali Rohár 
---
Changes in v2:
* Resend patch
* Update comment about watchdog
---
  board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 13 +
  board/freescale/p1_p2_rdb_pc/spl.c  |  6 ++
  board/freescale/p1_p2_rdb_pc/tlb.c  |  2 +-
  3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c 
b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
index 343059c09c36..84e1d65cdb1f 100644
--- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
+++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
@@ -97,6 +97,19 @@ void board_cpld_init(void)
out_8(_data->status_led, CPLD_STATUS_LED);
out_8(_data->fxo_led, CPLD_FXO_LED);
out_8(_data->fxs_led, CPLD_FXS_LED);
+
+   /*
+* CPLD's system reset register on P1/P2 RDB boards is not autocleared
+* after flipping it. If this register is set to one then CPLD triggers
+* reset of CPU in few ms.
+*
+* CPLD does not trigger reset of CPU for 100ms after the last reset.
+*
+* This means that trying to reset board via CPLD system reset register
+* cause reboot loop. To prevent this reboot loop, the only workaround
+* is to try to clear CPLD's system reset register as early as possible
+* and it has to be done in 100ms since the last start of reset.
+*/
out_8(_data->system_rst, CPLD_SYS_RST);
  }
  
diff --git a/board/freescale/p1_p2_rdb_pc/spl.c b/board/freescale/p1_p2_rdb_pc/spl.c

index 22156f2824ec..def28665960d 100644
--- a/board/freescale/p1_p2_rdb_pc/spl.c
+++ b/board/freescale/p1_p2_rdb_pc/spl.c
@@ -31,6 +31,12 @@ void board_init_f(ulong bootflag)
u32 plat_ratio, bus_clk;
ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
  
+	/*

+* Call board_early_init_f() as early as possible as it workarounds
+* reboot loop due to broken CPLD state machine for reset line.
+*/
+   board_early_init_f();
+
console_init_f();
  
  	/* Set pmuxcr to allow both i2c1 and i2c2 */

diff --git a/board/freescale/p1_p2_rdb_pc/tlb.c 
b/board/freescale/p1_p2_rdb_pc/tlb.c
index 13f3a1edf68d..2d431d6d0d90 100644
--- a/board/freescale/p1_p2_rdb_pc/tlb.c
+++ b/board/freescale/p1_p2_rdb_pc/tlb.c
@@ -61,11 +61,11 @@ struct fsl_e_tlb_entry tlb_table[] = {
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 5, BOOKE_PAGESZ_1M, 1),
  #endif
+#endif /* not SPL */
  
  	SET_TLB_ENTRY(1, CONFIG_SYS_CPLD_BASE, CONFIG_SYS_CPLD_BASE_PHYS,

MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 6, BOOKE_PAGESZ_1M, 1),
-#endif /* not SPL */
  
  #ifdef CONFIG_SYS_NAND_BASE

/* *I*G - NAND */
--
2.20.1

Re: [PATCH v2 2/2] serial: mxc: have putc use the TXFIFO

[Peng Fan]

On 9/6/2022 11:38 AM, SCHNEIDER Johannes wrote:

Hi Peng Fan,

... well i'm actually not sure why the messages get corrupted; it's just what i 
observed on a connected oscilloscope :-s
the code that does uses the transmit functions is making use of the returned 
-EAGAIN and retries - and even strewing in some delays to wait for the buffer 
or checking the status register didn't resolve the issue -- switching the 
serical driver from locking onto the single send-register to actually checking 
the fifo fixed it though.

i can put these "vague reasons" in the commit message... but i dont/didn't 
think theyd help much (?)


That's fine, I just wanna know more details. Maybe add one line 
"followling linux kernel i.MX8M* uart driver, check UTS_TXFULL, not 
UTS_EMPTY."


Regards,
Peng.




regards

From: Peng Fan 
Sent: Tuesday, September 6, 2022 02:54
To: SCHNEIDER Johannes ; 
u-boot@lists.denx.de 
Cc: trini ; GEO-CHHER-bsp-development 
; feste...@denx.de ; sba...@denx.de 
; Pali Rohár 
Subject: Re: [PATCH v2 2/2] serial: mxc: have putc use the TXFIFO

This email is not from Hexagon’s Office 365 instance. Please be careful while 
clicking links, opening attachments, or replying to this email.


On 9/5/2022 5:58 PM, Johannes Schneider wrote:

only waiting for TXEMPTY leads to corrupted messages going over the
wire - which is fixed by making use of the FIFO


Could you please explain a bit more, why waiting TXEMPTY could lead
to corrupted message?

Thanks,
Peng.



Signed-off-by: Johannes Schneider 
---

(no changes since v1)

   drivers/serial/serial_mxc.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index 5f283cc635..1e0add7281 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -309,7 +309,7 @@ static int mxc_serial_putc(struct udevice *dev, const char 
ch)
   struct mxc_serial_plat *plat = dev_get_plat(dev);
   struct mxc_uart *const uart = plat->reg;

- if (!(readl(>ts) & UTS_TXEMPTY))
+ if (readl(>ts) & UTS_TXFULL)
   return -EAGAIN;

   writel(ch, >txd);

[PATCH 2/2] HSD #1507453717: arm: socfpga: agilex: add QSPI boot feature

[Jit Loon Lim]

From: "Ooi, Joyce" 

This patch adds the QSPI boot feature for Agilex

Signed-off-by: Ooi, Joyce 
Signed-off-by: Jit Loon Lim 
---
 arch/arm/dts/Makefile |  1 +
 arch/arm/dts/socfpga_agilex_socdk.dts |  1 +
 arch/arm/dts/socfpga_agilex_socdk_qspi.dts| 14 
 configs/socfpga_agilex_defconfig  |  1 +
 ...efconfig => socfpga_agilex_qspi_defconfig} | 74 ++-
 5 files changed, 89 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/dts/socfpga_agilex_socdk_qspi.dts
 copy configs/{socfpga_agilex_defconfig => socfpga_agilex_qspi_defconfig} (55%)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index c58acb480d..86e9407456 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -419,6 +419,7 @@ dtb-$(CONFIG_TARGET_THUNDERX_88XX) += thunderx-88xx.dtb
 
 dtb-$(CONFIG_ARCH_SOCFPGA) +=  \
socfpga_agilex_socdk.dtb\
+   socfpga_agilex_socdk_qspi.dtb   \
socfpga_arria5_secu1.dtb\
socfpga_arria5_socdk.dtb\
socfpga_arria10_chameleonv3_270_3.dtb   \
diff --git a/arch/arm/dts/socfpga_agilex_socdk.dts 
b/arch/arm/dts/socfpga_agilex_socdk.dts
index bcdeecc0e0..de1cf93c17 100644
--- a/arch/arm/dts/socfpga_agilex_socdk.dts
+++ b/arch/arm/dts/socfpga_agilex_socdk.dts
@@ -16,6 +16,7 @@
 
chosen {
stdout-path = "serial0:115200n8";
+   u-boot,boot0 = <>;
};
 
leds {
diff --git a/arch/arm/dts/socfpga_agilex_socdk_qspi.dts 
b/arch/arm/dts/socfpga_agilex_socdk_qspi.dts
new file mode 100644
index 00..e969b25a9b
--- /dev/null
+++ b/arch/arm/dts/socfpga_agilex_socdk_qspi.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Intel Corporation
+ */
+
+#include "socfpga_agilex_socdk.dts"
+#include "socfpga_agilex_socdk-u-boot.dtsi"
+
+/ {
+
+   chosen {
+   u-boot,boot0 = <>;
+   };
+};
diff --git a/configs/socfpga_agilex_defconfig b/configs/socfpga_agilex_defconfig
index e2d869610c..1e35c08519 100644
--- a/configs/socfpga_agilex_defconfig
+++ b/configs/socfpga_agilex_defconfig
@@ -66,6 +66,7 @@ CONFIG_DWAPB_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_DW=y
 CONFIG_MMC_DW=y
+CONFIG_MTD=y
 CONFIG_SF_DEFAULT_MODE=0x2003
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
diff --git a/configs/socfpga_agilex_defconfig 
b/configs/socfpga_agilex_qspi_defconfig
similarity index 55%
copy from configs/socfpga_agilex_defconfig
copy to configs/socfpga_agilex_qspi_defconfig
index e2d869610c..adb2b0f704 100644
--- a/configs/socfpga_agilex_defconfig
+++ b/configs/socfpga_agilex_qspi_defconfig
@@ -79,9 +79,79 @@ CONFIG_SPI=y
 CONFIG_CADENCE_QSPI=y
 CONFIG_DESIGNWARE_SPI=y
 CONFIG_USB=y
+CONFIG_DM_USB=y
 CONFIG_USB_DWC2=y
 CONFIG_USB_STORAGE=y
-CONFIG_DESIGNWARE_WATCHDOG=y
-CONFIG_WDT=y
 # CONFIG_SPL_USE_TINY_PRINTF is not set
 CONFIG_PANIC_HANG=y
+CONFIG_ARM=y
+CONFIG_ARM_SMCCC=y
+CONFIG_SPL_LDSCRIPT="arch/arm/mach-socfpga/u-boot-spl-soc64.lds"
+CONFIG_ARCH_SOCFPGA=y
+CONFIG_SYS_TEXT_BASE=0x1000
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_ENV_SIZE=0x1000
+CONFIG_ENV_OFFSET=0x0208
+CONFIG_ENV_SECT_SIZE=0x1
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x0200
+CONFIG_DM_GPIO=y
+CONFIG_SPL_TEXT_BASE=0xFFE0
+CONFIG_TARGET_SOCFPGA_AGILEX_SOCDK=y
+CONFIG_IDENT_STRING="socfpga_agilex"
+CONFIG_SPL_FS_FAT=y
+CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y
+# CONFIG_PSCI_RESET is not set
+CONFIG_ARMV8_PSCI=y
+CONFIG_DEFAULT_DEVICE_TREE="socfpga_agilex_socdk_qspi"
+CONFIG_QSPI_BOOT=y
+CONFIG_BOOTDELAY=5
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="earlycon panic=-1"
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="sf probe;run qspiload;run linux_qspi_enable;rsu dtb;run 
qspiboot"
+CONFIG_SPL_CACHE=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_PROMPT="SOCFPGA_AGILEX # "
+CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MTD=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_BLK=y
+CONFIG_SPL_ALTERA_SDRAM=y
+CONFIG_DWAPB_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_DW=y
+# CONFIG_MMC is not set
+CONFIG_MTD=y
+CONFIG_SF_DEFAULT_MODE=0x2003
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ90X1=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_MII=y
+CONFIG_DM_RESET=y
+CONFIG_SPI=y
+CONFIG_CADENCE_QSPI=y
+CONFIG_DESIGNWARE_SPI=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_DWC2=y
+CONFIG_USB_STORAGE=y
+# CONFIG_SPL_USE_TINY_PRINTF is not set
+CONFIG_PANIC_HANG=y
\ No newline at end of file
-- 
2.26.2

[PATCH 1/2] HSD #1507453717: arm: socfpga: stratix10: add QSPI boot feature

[Jit Loon Lim]

From: "Ooi, Joyce" 

This patch adds the QSPI boot feature for Stratix10

Signed-off-by: Ooi, Joyce 
Signed-off-by: Jit Loon Lim 
---
 arch/arm/dts/Makefile |  3 +-
 arch/arm/dts/socfpga_stratix10_socdk_qspi.dts | 14 
 configs/socfpga_stratix10_qspi_defconfig  | 73 +++
 include/configs/socfpga_soc64_common.h|  8 ++
 4 files changed, 97 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/socfpga_stratix10_socdk_qspi.dts
 create mode 100644 configs/socfpga_stratix10_qspi_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ceaa39e4b4..c58acb480d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -436,7 +436,8 @@ dtb-$(CONFIG_ARCH_SOCFPGA) +=   
\
socfpga_cyclone5_sr1500.dtb \
socfpga_cyclone5_vining_fpga.dtb\
socfpga_n5x_socdk.dtb   \
-   socfpga_stratix10_socdk.dtb
+   socfpga_stratix10_socdk.dtb \
+   socfpga_stratix10_socdk_qspi.dtb
 
 dtb-$(CONFIG_TARGET_DRA7XX_EVM) += dra72-evm.dtb dra7-evm.dtb  \
dra72-evm-revc.dtb dra71-evm.dtb dra76-evm.dtb
diff --git a/arch/arm/dts/socfpga_stratix10_socdk_qspi.dts 
b/arch/arm/dts/socfpga_stratix10_socdk_qspi.dts
new file mode 100644
index 00..729b9e5b84
--- /dev/null
+++ b/arch/arm/dts/socfpga_stratix10_socdk_qspi.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Intel Corporation
+ */
+
+#include "socfpga_stratix10_socdk.dts"
+#include "socfpga_stratix10_socdk-u-boot.dtsi"
+
+/ {
+   chosen {
+   u-boot,boot0 = <>;
+   };
+
+};
diff --git a/configs/socfpga_stratix10_qspi_defconfig 
b/configs/socfpga_stratix10_qspi_defconfig
new file mode 100644
index 00..ebeecf0233
--- /dev/null
+++ b/configs/socfpga_stratix10_qspi_defconfig
@@ -0,0 +1,73 @@
+CONFIG_ARM=y
+CONFIG_ARM_SMCCC=y
+CONFIG_SPL_LDSCRIPT="arch/arm/mach-socfpga/u-boot-spl-soc64.lds"
+CONFIG_ARCH_SOCFPGA=y
+CONFIG_SYS_TEXT_BASE=0x1000
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_ENV_SIZE=0x1000
+CONFIG_ENV_OFFSET=0x0208
+CONFIG_ENV_SECT_SIZE=0x1
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x0200
+CONFIG_DM_GPIO=y
+CONFIG_SPL_TEXT_BASE=0xFFE0
+CONFIG_TARGET_SOCFPGA_STRATIX10_SOCDK=y
+CONFIG_IDENT_STRING="socfpga_stratix10"
+CONFIG_SPL_FS_FAT=y
+CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y
+# CONFIG_PSCI_RESET is not set
+CONFIG_ARMV8_PSCI=y
+CONFIG_DEFAULT_DEVICE_TREE="socfpga_stratix10_socdk_qspi"
+CONFIG_QSPI_BOOT=y
+CONFIG_BOOTDELAY=5
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="earlycon panic=-1"
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="sf probe;run qspiload;run linux_qspi_enable;rsu dtb;run 
qspiboot"
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_PROMPT="SOCFPGA_STRATIX10 # "
+CONFIG_CMD_MEMTEST=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_BLK=y
+CONFIG_SPL_ALTERA_SDRAM=y
+CONFIG_FPGA_INTEL_PR=y
+CONFIG_DWAPB_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_DW=y
+# CONFIG_MMC is not set
+CONFIG_MTD=y
+CONFIG_SF_DEFAULT_MODE=0x2003
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ90X1=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_MII=y
+CONFIG_DM_RESET=y
+CONFIG_SPI=y
+CONFIG_CADENCE_QSPI=y
+CONFIG_DESIGNWARE_SPI=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_DWC2=y
+CONFIG_USB_STORAGE=y
+CONFIG_DESIGNWARE_WATCHDOG=y
+CONFIG_WDT=y
+# CONFIG_SPL_USE_TINY_PRINTF is not set
+CONFIG_PANIC_HANG=y
diff --git a/include/configs/socfpga_soc64_common.h 
b/include/configs/socfpga_soc64_common.h
index 06198ddd82..c966d31362 100644
--- a/include/configs/socfpga_soc64_common.h
+++ b/include/configs/socfpga_soc64_common.h
@@ -37,6 +37,14 @@
  * Environment variable
  */
 #define CONFIG_EXTRA_ENV_SETTINGS \
+   "qspibootimageaddr=0x020B\0" \
+   "qspifdtaddr=0x0209\0" \
+   "bootimagesize=0x0140\0" \
+   "fdtimagesize=0x0001\0" \
+   "qspiload=sf read ${loadaddr} ${qspibootimageaddr} ${bootimagesize};" \
+   "sf read ${fdt_addr} ${qspifdtaddr} ${fdtimagesize}\0" \
+   "qspiboot=setenv bootargs earlycon root=/dev/mtdblock1 rw " \
+   "rootfstype=jffs2 rootwait;booti ${loadaddr} - ${fdt_addr}\0" \
"loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
"bootfile=" CONFIG_BOOTFILE "\0" \
"fdt_addr=800\0" \
-- 
2.26.2

Re: RISCV: the machanism of available_harts may cause other harts boot failure

[Rick Chen]

HI all,

> On Mon, 5 Sep 2022 11:30:38 -0400
> Sean Anderson  wrote:
>
> > On 9/5/22 3:47 AM, Nikita Shubin wrote:
> > > Hi Rick!
> > >
> > > On Mon, 5 Sep 2022 14:22:41 +0800
> > > Rick Chen  wrote:
> > >
> > >> Hi,
> > >>
> > >> When I free-run a SMP system, I once hit a failure case where some
> > >> harts didn't boot to the kernel shell successfully.
> > >> However it can't be duplicated anymore even if I try many times.
> > >>
> > >> But when I set a break during debugging with GDB, it can trigger
> > >> the failure case each time.
> > >
> > > If hart fails to register itself to available_harts before
> > > send_ipi_many is hit by the main hart:
> > > https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/riscv/lib/smp.c#L50
> > >
> > > it won't exit the secondary_hart_loop:
> > > https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/riscv/cpu/start.S#L433
> > > As no ipi will be sent to it.
> > >
> > > This might be exactly your case.
> >
> > When working on the IPI mechanism, I considered this possibility.
> > However, there's really no way to know how long to wait. On normal
> > systems, the boot hart is going to do a lot of work before calling
> > send_ipi_many, and the other harts just have to make it through ~100
> > instructions. So I figured we would never run into this issue.
> >
> > We might not even need the mask... the only direct reason we might is
> > for OpenSBI, as spl_invoke_opensbi is the only function which uses
> > the wait parameter.
>
> Actually i think available_harts in is duplicated by device tree,
> so we can:
>
> 1) drop registering harts in start.S (and related lock completely)
> 2) fill gd->arch.available_harts in send_ipi_many relying on device
> tree, and also making riscv_send_ipi non-fatal
> 3) move this procedure to the very end just before spl_invoke_opensbi
> 4) may be even wrap all above in some CONFIG option which enforces
> checking that harts are alive, otherwise just pass the device tree harts
> count

Thanks for all of your discussion and advise.

I would like to let available_harts become an option by something like
CONFIG_SEND_IPI_BY_DTS_CPUS.
It can help to avoid the SMP booting failure situation and also will
not affect other's platform.

#ifndef CONFIG_SEND_IPI_BY_DTS_CPUS
/* skip if hart is not available */
if (!(gd->arch.available_harts & (1 << reg)))
continue;
#endif

Any opinions ?

Thanks,
Rick

>
> >
> > >> I think the mechanism of available_harts does not provide a method
> > >> that guarantees the success of the SMP system.
> > >> Maybe we shall think of a better way for the SMP booting or just
> > >> remove it ?
> > >
> > > I haven't experienced any unexplained problem with hart_lottery or
> > > available_harts_lock unless:
> > >
> > > 1) harts are started non-simultaneously
> > > 2) SPL/U-Boot is in some kind of TCM, OCRAM, etc... which is not
> > > cleared on reset which leaves available_harts dirty
> >
> > XIP, of course, has this problem every time and just doesn't use the
> > mask. I remember thinking a lot about how to deal with this, but I
> > never ended up sending a patch because I didn't have a XIP system.
>
> It can be in some part emulated by setting up SPL region as
> read-only via PMP before start.
>
> >
> > --Sean
> >
> > > 3) something is wrong with atomics
> > >
> > > Also there might be something wrong with IPI send/recieve.
> > >
> > >>
> > >> Thread 8 hit Breakpoint 1, harts_early_init ()
> > >>
> > >> (gdb) c
> > >> Continuing.
> > >> [Switching to Thread 7]
> > >>
> > >> Thread 7 hit Breakpoint 1, harts_early_init ()
> > >>
> > >> (gdb)
> > >> Continuing.
> > >> [Switching to Thread 6]
> > >>
> > >> Thread 6 hit Breakpoint 1, harts_early_init ()
> > >>
> > >> (gdb)
> > >> Continuing.
> > >> [Switching to Thread 5]
> > >>
> > >> Thread 5 hit Breakpoint 1, harts_early_init ()
> > >>
> > >> (gdb)
> > >> Continuing.
> > >> [Switching to Thread 4]
> > >>
> > >> Thread 4 hit Breakpoint 1, harts_early_init ()
> > >>
> > >> (gdb)
> > >> Continuing.
> > >> [Switching to Thread 3]
> > >>
> > >> Thread 3 hit Breakpoint 1, harts_early_init ()
> > >> (gdb)
> > >> Continuing.
> > >> [Switching to Thread 2]
> > >>
> > >> Thread 2 hit Breakpoint 1, harts_early_init ()
> > >> (gdb)
> > >> Continuing.
> > >> [Switching to Thread 1]
> > >>
> > >> Thread 1 hit Breakpoint 1, harts_early_init ()
> > >> (gdb)
> > >> Continuing.
> > >> [Switching to Thread 5]
> > >>
> > >>
> > >> Thread 5 hit Breakpoint 3, 0x0120 in ?? ()
> > >> (gdb) info threads
> > >>Id   Target Id Frame
> > >>1Thread 1 (hart 1) secondary_hart_loop () at
> > >> arch/riscv/cpu/start.S:436 2Thread 2 (hart 2)
> > >> secondary_hart_loop () at arch/riscv/cpu/start.S:436 3Thread 3
> > >> (hart 3) secondary_hart_loop () at arch/riscv/cpu/start.S:436 4
> > >> Thread 4 (hart 4) secondary_hart_loop () at
> > >> arch/riscv/cpu/start.S:436
> > >> * 5Thread 5 (hart 5) 0x0120 in ?? ()
> > >>6Thread 6 (hart 6) 

Re: [PATCH v2 1/2] serial: mxc: enable the RX pipeline

[Fabio Estevam]

On Mon, Sep 5, 2022 at 10:43 PM Tom Rini  wrote:

> We allow '//' style comments, just like the linux kernel does these
> days. There should be a space before the "imx8" in the first hunk here.

Yes, // style comments are allowed, but for consistency with the other
comments in this file,
it would be better to keep using the /* style.

Mixing the two styles in the same file makes it confusing.

Re: [PATCH 1/1] RISC-V: enable CONFIG_SYSRESET_SBI by default

[Leo Liang]

On Mon, Sep 05, 2022 at 04:40:49PM +0200, Heinrich Schuchardt wrote:
> System reset via the SRST extension in the SBI should be the default.
> The driver checks if the extension is available when probing.
> So there is no risk in enabling it.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  drivers/sysreset/Kconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Leo Yu-Chi Liang 

Re: [PATCH v2 1/2] serial: mxc: enable the RX pipeline

[Tom Rini]

On Tue, Sep 06, 2022 at 09:04:05AM +0800, Peng Fan wrote:
> 
> 
> On 9/5/2022 5:58 PM, Johannes Schneider wrote:
> > on imx8(mm) the RXDMUXSEL needs to be set for data going over the wire
> > (as observable on a connected 'scope) to actually make it into the
> > RXFIFO
> > 
> > the reference manual is not overly clear about this, and only
> > mentiones that "UCR3_RXDMUXSEL should always be set." - and since the
> > CR3 register reverts to its reset values after setting the baudrate,
> > setting this bit is done during '_mxc_serial_setbgr'
> > 
> > Signed-off-by: Johannes Schneider 
> > 
> > ---
> > 
> > (no changes since v1)
> > 
> >   drivers/serial/serial_mxc.c | 11 +++
> >   1 file changed, 11 insertions(+)
> > 
> > diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
> > index 70a0e5e919..5f283cc635 100644
> > --- a/drivers/serial/serial_mxc.c
> > +++ b/drivers/serial/serial_mxc.c
> > @@ -61,6 +61,11 @@
> >   #define UCR3_AWAKEN   (1<<4)  /* Async wake interrupt enable */
> >   #define UCR3_REF25(1<<3)  /* Ref freq 25 MHz */
> >   #define UCR3_REF30(1<<2)  /* Ref Freq 30 MHz */
> > +
> > +//imx8 names these bitsfields instead:
> > +#define UCR3_DTRDENBIT(3)  /* bit not used in this chip */
> > +#define UCR3_RXDMUXSEL BIT(2)  /* RXD muxed input selected; 'should 
> > always be set' */
> > +
> >   #define UCR3_INVT (1<<1)  /* Inverted Infrared transmission */
> >   #define UCR3_BPEN (1<<0)  /* Preset registers enable */
> >   #define UCR4_CTSTL_32 (32<<10) /* CTS trigger level (32 chars) */
> > @@ -176,6 +181,12 @@ static void _mxc_serial_setbrg(struct mxc_uart *base, 
> > unsigned long clk,
> > writel(UCR2_WS | UCR2_IRTS | UCR2_RXEN | UCR2_TXEN | UCR2_SRST,
> >>cr2);
> > +
> > +   // setting the baudrate triggers a reset, returning cr3 to its
> > +   // reset value but UCR3_RXDMUXSEL "should always be set."
> > +   // according to the imx8 reference-manual
> > +   writel(readl(>cr3) | UCR3_RXDMUXSEL, >cr3);
> 
> Please fix comment format.

We allow '//' style comments, just like the linux kernel does these
days. There should be a space before the "imx8" in the first hunk here.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v16 10/10] test: unit test for eficonfig

[Takahiro Akashi]

On Mon, Sep 05, 2022 at 05:55:05PM +0200, Heinrich Schuchardt wrote:
> On 9/5/22 14:48, Masahisa Kojima wrote:
> > Provide a unit test for the eficonfig command.
> > 
> > Signed-off-by: Masahisa Kojima 
> > Acked-by: Ilias Apalodimas 
> > ---
> > Changes in v16:
> > - call u_boot_console.restart_uboot() to clean the previous test state
> 
> The test is still failing:
> https://source.denx.de/u-boot/custodians/u-boot-efi/-/jobs/492069/raw
> 
> The same can be seen when running 'make tests' locally.

Well, the screen shown in "Select File" seems to be different
from what the test expects to be seen: 
===
** Select File **

  initrd-2.img
  initrddump.efi
  initrd-1.img
  Quit
===
So, for instance,
# Press down key to select "initrd-1.img" entry followed by the enter 
key
press_up_down_enter_and_wait(0, 0, True, 'Quit')
will incorrectly select "initrd-2.img" instead of "initrd-1.img

-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> > 
> > Changes in v14:
> > - update to support media device enumeration in eficonfig startup
> > - move no block device test to the last test case
> > 
> > Changes in v12:
> > - update menu handling
> > 
> > Changes in v11:
> > - fix expected result when no BootOrder is defined
> > 
> > Newly added in v10
> > 
> >   configs/sandbox_defconfig |   1 +
> >   test/py/tests/test_eficonfig/conftest.py  |  40 ++
> >   .../py/tests/test_eficonfig/test_eficonfig.py | 354 ++
> >   3 files changed, 395 insertions(+)
> >   create mode 100644 test/py/tests/test_eficonfig/conftest.py
> >   create mode 100644 test/py/tests/test_eficonfig/test_eficonfig.py
> > 
> > diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> > index eba7bcbb48..48c60c606d 100644
> > --- a/configs/sandbox_defconfig
> > +++ b/configs/sandbox_defconfig
> > @@ -93,6 +93,7 @@ CONFIG_CMD_LINK_LOCAL=y
> >   CONFIG_CMD_ETHSW=y
> >   CONFIG_CMD_BMP=y
> >   CONFIG_CMD_BOOTCOUNT=y
> > +CONFIG_CMD_EFICONFIG=y
> >   CONFIG_CMD_EFIDEBUG=y
> >   CONFIG_CMD_RTC=y
> >   CONFIG_CMD_TIME=y
> > diff --git a/test/py/tests/test_eficonfig/conftest.py 
> > b/test/py/tests/test_eficonfig/conftest.py
> > new file mode 100644
> > index 00..f289df0362
> > --- /dev/null
> > +++ b/test/py/tests/test_eficonfig/conftest.py
> > @@ -0,0 +1,40 @@
> > +# SPDX-License-Identifier:  GPL-2.0+
> > +
> > +"""Fixture for UEFI eficonfig test
> > +"""
> > +
> > +import os
> > +import shutil
> > +from subprocess import check_call
> > +import pytest
> > +
> > +@pytest.fixture(scope='session')
> > +def efi_eficonfig_data(u_boot_config):
> > +"""Set up a file system to be used in UEFI "eficonfig" command
> > +   tests
> > +
> > +Args:
> > +u_boot_config -- U-boot configuration.
> > +
> > +Return:
> > +A path to disk image to be used for testing
> > +"""
> > +mnt_point = u_boot_config.persistent_data_dir + '/test_efi_eficonfig'
> > +image_path = u_boot_config.persistent_data_dir + '/efi_eficonfig.img'
> > +
> > +shutil.rmtree(mnt_point, ignore_errors=True)
> > +os.mkdir(mnt_point, mode = 0o755)
> > +
> > +with open(mnt_point + '/initrd-1.img', 'w', encoding = 'ascii') as 
> > file:
> > +file.write("initrd 1")
> > +
> > +with open(mnt_point + '/initrd-2.img', 'w', encoding = 'ascii') as 
> > file:
> > +file.write("initrd 2")
> > +
> > +shutil.copyfile(u_boot_config.build_dir + 
> > '/lib/efi_loader/initrddump.efi',
> > +mnt_point + '/initrddump.efi')
> > +
> > +check_call(f'virt-make-fs --partition=gpt --size=+1M --type=vfat 
> > {mnt_point} {image_path}',
> > +   shell=True)
> > +
> > +return image_path
> > diff --git a/test/py/tests/test_eficonfig/test_eficonfig.py 
> > b/test/py/tests/test_eficonfig/test_eficonfig.py
> > new file mode 100644
> > index 00..c1fe07eb8b
> > --- /dev/null
> > +++ b/test/py/tests/test_eficonfig/test_eficonfig.py
> > @@ -0,0 +1,354 @@
> > +# SPDX-License-Identifier:  GPL-2.0+
> > +""" Unit test for UEFI menu-driven configuration
> > +"""
> > +
> > +import pytest
> > +import time
> > +
> > +@pytest.mark.boardspec('sandbox')
> > +@pytest.mark.buildconfigspec('cmd_eficonfig')
> > +@pytest.mark.buildconfigspec('cmd_bootefi_bootmgr')
> > +def test_efi_eficonfig(u_boot_console, efi_eficonfig_data):
> > +
> > +def send_user_input_and_wait(user_str, expect_str):
> > +time.sleep(0.1) # TODO: does not work correctly without sleep
> > +u_boot_console.run_command(cmd=user_str, wait_for_prompt=False,
> > +   wait_for_echo=True, send_nl=False)
> > +u_boot_console.run_command(cmd='\x0d', wait_for_prompt=False,
> > +   wait_for_echo=False, send_nl=False)
> > +if expect_str is not None:
> > +for i in expect_str:
> > +u_boot_console.p.expect([i])
> > +
> > +def press_up_down_enter_and_wait(up_count, 

Re: [PATCH v2 1/2] serial: mxc: enable the RX pipeline

[Peng Fan]

On 9/5/2022 5:58 PM, Johannes Schneider wrote:

on imx8(mm) the RXDMUXSEL needs to be set for data going over the wire
(as observable on a connected 'scope) to actually make it into the
RXFIFO

the reference manual is not overly clear about this, and only
mentiones that "UCR3_RXDMUXSEL should always be set." - and since the
CR3 register reverts to its reset values after setting the baudrate,
setting this bit is done during '_mxc_serial_setbgr'

Signed-off-by: Johannes Schneider 

---

(no changes since v1)

  drivers/serial/serial_mxc.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index 70a0e5e919..5f283cc635 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -61,6 +61,11 @@
  #define UCR3_AWAKEN   (1<<4)  /* Async wake interrupt enable */
  #define UCR3_REF25(1<<3)  /* Ref freq 25 MHz */
  #define UCR3_REF30(1<<2)  /* Ref Freq 30 MHz */
+
+//imx8 names these bitsfields instead:
+#define UCR3_DTRDENBIT(3)  /* bit not used in this chip */
+#define UCR3_RXDMUXSEL BIT(2)  /* RXD muxed input selected; 'should always be 
set' */
+
  #define UCR3_INVT (1<<1)  /* Inverted Infrared transmission */
  #define UCR3_BPEN (1<<0)  /* Preset registers enable */
  #define UCR4_CTSTL_32 (32<<10) /* CTS trigger level (32 chars) */
@@ -176,6 +181,12 @@ static void _mxc_serial_setbrg(struct mxc_uart *base, 
unsigned long clk,
  
  	writel(UCR2_WS | UCR2_IRTS | UCR2_RXEN | UCR2_TXEN | UCR2_SRST,

   >cr2);
+
+   // setting the baudrate triggers a reset, returning cr3 to its
+   // reset value but UCR3_RXDMUXSEL "should always be set."
+   // according to the imx8 reference-manual
+   writel(readl(>cr3) | UCR3_RXDMUXSEL, >cr3);


Please fix comment format.

I just give a look at i.MX6QDL, i.MX7D, i.MX8M*, this bit should be set 
for them all.


Thanks,
Peng.


+
writel(UCR1_UARTEN, >cr1);
  }
  

Re: [PATCH v2 2/2] serial: mxc: have putc use the TXFIFO

[Peng Fan]

On 9/5/2022 5:58 PM, Johannes Schneider wrote:

only waiting for TXEMPTY leads to corrupted messages going over the
wire - which is fixed by making use of the FIFO


Could you please explain a bit more, why waiting TXEMPTY could lead
to corrupted message?

Thanks,
Peng.



Signed-off-by: Johannes Schneider 
---

(no changes since v1)

  drivers/serial/serial_mxc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index 5f283cc635..1e0add7281 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -309,7 +309,7 @@ static int mxc_serial_putc(struct udevice *dev, const char 
ch)
struct mxc_serial_plat *plat = dev_get_plat(dev);
struct mxc_uart *const uart = plat->reg;
  
-	if (!(readl(>ts) & UTS_TXEMPTY))

+   if (readl(>ts) & UTS_TXFULL)
return -EAGAIN;
  
  	writel(ch, >txd);

[PATCH 2/2] mmc: f_sdh30: Add support for F_SDH30_E51

[Kunihiko Hayashi]

Add Socionext F_SDH30_E51 IP support. The features of this IP includes
CMD/DAT line delay and force card insertion mode for non-removable cards.
And the IP needs to add some quirks.

Signed-off-by: Kunihiko Hayashi 
---
 drivers/mmc/Kconfig   |  4 +--
 drivers/mmc/f_sdh30.c | 64 +--
 2 files changed, 64 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 0dcec8adcee8..c30f20cba5f2 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -577,12 +577,12 @@ config MMC_SDHCI_IPROC
  If unsure, say N.
 
 config MMC_SDHCI_F_SDH30
-   bool "SDHCI support for Fujitsu Semiconductor F_SDH30"
+   bool "SDHCI support for Fujitsu Semiconductor/Socionext F_SDH30"
depends on BLK && DM_MMC
depends on MMC_SDHCI
help
  This selects the Secure Digital Host Controller Interface (SDHCI)
- Needed by some Fujitsu SoC for MMC / SD / SDIO support.
+ Needed by some Fujitsu/Socionext SoC for MMC / SD / SDIO support.
  If you have a controller with this interface, say Y or M here.
  If unsure, say N.
 
diff --git a/drivers/mmc/f_sdh30.c b/drivers/mmc/f_sdh30.c
index 3a85d9e348ab..6b950edab74e 100644
--- a/drivers/mmc/f_sdh30.c
+++ b/drivers/mmc/f_sdh30.c
@@ -11,13 +11,46 @@
 #include 
 #include 
 
+#define F_SDH30_ESD_CONTROL0x124
+#define F_SDH30_CMD_DAT_DELAY  BIT(9)
+
+#define F_SDH30_TEST   0x158
+#define F_SDH30_FORCE_CARD_INSERT  BIT(6)
+
+struct f_sdh30_data {
+   void (*init)(struct udevice *dev);
+   u32 quirks;
+};
+
 struct f_sdh30_plat {
struct mmc_config cfg;
struct mmc mmc;
+
+   bool enable_cmd_dat_delay;
+   const struct f_sdh30_data *data;
 };
 
 DECLARE_GLOBAL_DATA_PTR;
 
+static void f_sdh30_e51_init(struct udevice *dev)
+{
+   struct f_sdh30_plat *plat = dev_get_plat(dev);
+   struct sdhci_host *host = dev_get_priv(dev);
+   u32 val;
+
+   if (plat->enable_cmd_dat_delay) {
+   val = sdhci_readl(host, F_SDH30_ESD_CONTROL);
+   val |= F_SDH30_CMD_DAT_DELAY;
+   sdhci_writel(host, val, F_SDH30_ESD_CONTROL);
+   }
+
+   if (plat->cfg.host_caps & MMC_CAP_NONREMOVABLE) {
+   val = sdhci_readl(host, F_SDH30_TEST);
+   val |= F_SDH30_FORCE_CARD_INSERT;
+   sdhci_writel(host, val, F_SDH30_TEST);
+   }
+}
+
 static int f_sdh30_sdhci_probe(struct udevice *dev)
 {
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
@@ -25,6 +58,8 @@ static int f_sdh30_sdhci_probe(struct udevice *dev)
struct sdhci_host *host = dev_get_priv(dev);
int ret;
 
+   plat->data = (const struct f_sdh30_data *)dev_get_driver_data(dev);
+
ret = mmc_of_parse(dev, >cfg);
if (ret)
return ret;
@@ -33,6 +68,9 @@ static int f_sdh30_sdhci_probe(struct udevice *dev)
host->mmc->dev = dev;
host->mmc->priv = host;
 
+   if (plat->data && plat->data->quirks)
+   host->quirks |= plat->data->quirks;
+
ret = sdhci_setup_cfg(>cfg, host, 2, 40);
if (ret)
return ret;
@@ -41,18 +79,29 @@ static int f_sdh30_sdhci_probe(struct udevice *dev)
 
mmc_set_clock(host->mmc, host->mmc->cfg->f_min, MMC_CLK_ENABLE);
 
-   return sdhci_probe(dev);
+   ret = sdhci_probe(dev);
+   if (ret)
+   return ret;
+
+   if (plat->data && plat->data->init)
+   plat->data->init(dev);
+
+   return 0;
 }
 
 static int f_sdh30_of_to_plat(struct udevice *dev)
 {
struct sdhci_host *host = dev_get_priv(dev);
+   struct f_sdh30_plat *plat = dev_get_plat(dev);
 
host->name = strdup(dev->name);
host->ioaddr = dev_read_addr_ptr(dev);
host->bus_width = dev_read_u32_default(dev, "bus-width", 4);
host->index = dev_read_u32_default(dev, "index", 0);
 
+   plat->enable_cmd_dat_delay =
+   dev_read_bool(dev, "socionext,enable-cmd-dat-delay");
+
return 0;
 }
 
@@ -63,8 +112,19 @@ static int f_sdh30_bind(struct udevice *dev)
return sdhci_bind(dev, >mmc, >cfg);
 }
 
+static const struct f_sdh30_data f_sdh30_e51_data = {
+   .init = f_sdh30_e51_init,
+   .quirks = SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_SUPPORT_SINGLE,
+};
+
 static const struct udevice_id f_sdh30_mmc_ids[] = {
-   { .compatible = "fujitsu,mb86s70-sdhci-3.0" },
+   {
+   .compatible = "fujitsu,mb86s70-sdhci-3.0",
+   },
+   {
+   .compatible = "socionext,f-sdh30-e51-mmc",
+   .data = (ulong)_sdh30_e51_data,
+   },
{ }
 };
 
-- 
2.17.1

[PATCH 1/2] mmc: sdhci: Add new quirks for SUPPORT_SINGLE

[Kunihiko Hayashi]

This patch defines a quirk to disable the block count
for single block transactions.

This is similar to Linux kernel commit d3fc5d71ac4d
("mmc: sdhci: add a quirk for single block transactions").

Signed-off-by: Kunihiko Hayashi 
---
 drivers/mmc/sdhci.c | 8 +---
 include/sdhci.h | 1 +
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index bf989a594f7e..a80ad8329a38 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -211,7 +211,7 @@ static int sdhci_send_command(struct mmc *mmc, struct 
mmc_cmd *cmd,
unsigned int stat = 0;
int ret = 0;
int trans_bytes = 0, is_aligned = 1;
-   u32 mask, flags, mode;
+   u32 mask, flags, mode = 0;
unsigned int time = 0;
int mmc_dev = mmc_get_blk_desc(mmc)->devnum;
ulong start = get_timer(0);
@@ -273,10 +273,12 @@ static int sdhci_send_command(struct mmc *mmc, struct 
mmc_cmd *cmd,
/* Set Transfer mode regarding to data flag */
if (data) {
sdhci_writeb(host, 0xe, SDHCI_TIMEOUT_CONTROL);
-   mode = SDHCI_TRNS_BLK_CNT_EN;
+
+   if (!(host->quirks & SDHCI_QUIRK_SUPPORT_SINGLE))
+   mode = SDHCI_TRNS_BLK_CNT_EN;
trans_bytes = data->blocks * data->blocksize;
if (data->blocks > 1)
-   mode |= SDHCI_TRNS_MULTI;
+   mode |= SDHCI_TRNS_MULTI | SDHCI_TRNS_BLK_CNT_EN;
 
if (data->flags == MMC_DATA_READ)
mode |= SDHCI_TRNS_READ;
diff --git a/include/sdhci.h b/include/sdhci.h
index 88f1917480b6..24b4599b857d 100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -247,6 +247,7 @@
 #define SDHCI_QUIRK_WAIT_SEND_CMD  (1 << 6)
 #define SDHCI_QUIRK_USE_WIDE8  (1 << 8)
 #define SDHCI_QUIRK_NO_1_8_V   (1 << 9)
+#define SDHCI_QUIRK_SUPPORT_SINGLE (1 << 10)
 
 /* to make gcc happy */
 struct sdhci_host;
-- 
2.17.1

[PATCH 0/2] mmc: Add support for F_SDH30_E51

[Kunihiko Hayashi]

This series adds a new quirk "SUPPORT_SINGLE" for single transaction to
sdhci framework and Socionext F_SDH30_E51 IP support to f_sdh30 driver.

Kunihiko Hayashi (2):
  mmc: sdhci: Add new quirks for SUPPORT_SINGLE
  mmc: f_sdh30: Add support for F_SDH30_E51

 drivers/mmc/Kconfig   |  4 +--
 drivers/mmc/f_sdh30.c | 64 +--
 drivers/mmc/sdhci.c   |  8 --
 include/sdhci.h   |  1 +
 4 files changed, 70 insertions(+), 7 deletions(-)

-- 
2.17.1

Re: [PATCH 2/2] rpi: Copy eth PHY address from fw DT to loaded DT

[Antoine Mazeas]

Le 05/09/2022 à 15:19, Peter Robinson a écrit :

On Wed, Aug 10, 2022 at 1:58 PM Antoine Mazeas  wrote:


Some Raspberry Pi 400 boards, specifically rev 1.1, have a different address 
for the ethernet PHY device than what is provided by the kernel DTB. The 
correct address is provided by the firmware, so we should carry it over into 
the loaded device tree so that ethernet works on such boards.


Minor nit: this should be properly wrapped.


Yes, I did end up resending the patch a few days later with proper 
formatting and superseding this series. I'm very sorry for the confusion.


Resent on the 19th Aug.: 
https://patchwork.ozlabs.org/project/uboot/list/?series=314524


No change apart from the formatting of the commit messages.


Signed-off-by: Antoine Mazeas 


Reviewed-by: Peter Robinson 
Tested-by: Peter Robinson 

Tested on the RPi400 and a couple of different RPi4s


---
  board/raspberrypi/rpi/rpi.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 28b6f52506..793fd1aa30 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -548,6 +548,9 @@ void  update_fdt_from_fw(void *fdt, void *fw_fdt)

 /* kernel address randomisation seed as provided by the firmware */
 copy_property(fdt, fw_fdt, "/chosen", "kaslr-seed");
+
+   /* address of the PHY device as provided by the firmware  */
+   copy_property(fdt, fw_fdt, "ethernet0/mdio@e14/ethernet-phy@1", "reg");
  }

  int ft_board_setup(void *blob, struct bd_info *bd)
--
2.37.1

[ANN] U-Boot v2022.10-rc4 released

[Tom Rini]

Hey all,

It's release day and so here's v2022.10-rc4. Things are progressing well
I believe and the next branch continues to be open.

In terms of a changelog, 
git log --merges v2022.10-rc3..v2022.10-rc4
contains what I've pulled but as always, better PR messages and tags
will provide better results here.

So we're now looking at regular releases every other Monday, and with
final release on October 3rd, 2022.  Thanks all!

-- 
Tom


signature.asc
Description: PGP signature

Re: Pull request: u-boot-rockchip-20220905

[Tom Rini]

On Mon, Sep 05, 2022 at 09:29:13AM +0800, Kever Yang wrote:

> Hi Tom,
> 
> Please pull the rockchip fixes if possible:
> - migrate to use binman for U-Boot image generate on rockchip platform;
> - Some fixes for rk3399 and rk3308;
> 
> Gitlab ci:
> https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip/pipelines/13334
> 
> Thanks,
> - Kever
> 
> The following changes since commit 8710676635574bb457159fd6fa1c92d065ddb144:
> 
>   Merge tag 'efi-2022-10-rc4-2' of 
> https://source.denx.de/u-boot/custodians/u-boot-efi (2022-09-03 07:44:22 
> -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-rockchip.git 
> tags/u-boot-rockchip-20220905
> 
> for you to fetch changes up to f103c112660217f8875398435e47d545ba934a5c:
> 
>   clk: rockchip: rk3399: Fix Unknown clock 77 on mmc@fe31 (2022-09-04 
> 20:00:39 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 0/9] Nokia RX-51: Small cleanups and UBI boot test case

[Tony Dinh]

Thanks Damiel!

On Sun, Sep 4, 2022 at 3:10 PM Pali Rohár  wrote:
>
> On Sunday 04 September 2022 22:58:19 Daniel Golle wrote:
> > On Sun, Sep 04, 2022 at 12:28:24PM -0700, Tony Dinh wrote:
> > > Hi Pali,
> > >
> > > On Sun, Sep 4, 2022 at 2:37 AM Pali Rohár  wrote:
> > > >
> > > > On Saturday 03 September 2022 20:01:45 Tony Dinh wrote:
> > > > > Hi Pali,
> > > > >
> > > > > On Sat, Sep 3, 2022 at 6:29 PM Pali Rohár  wrote:
> > > > > >
> > > > > > Do various small fixup/cleanups and extend test script to boot 
> > > > > > kernel
> > > > > > image from UBI volume. This test verifies that U-Boot UBI 
> > > > > > implementation
> > > > > > is working and U-Boot can read volume with bootable kernel code
> > > > > > correctly. And therefore CI prevents UBI breakage.
> > > > > >
> > > > > > Note that U-Boot UBIFS code on ARM is currently somehow broken and
> > > > > > trying to mount UBIFS from UBI volume fails :-( I have already 
> > > > > > tried to
> > > > > > debug this issue but I have no idea why it is failing.
> > > > >
> > > > > I've recently implemented UBI distro boot on a pair of Kirkwood boards
> > > > > (Pogo V4 and NSA310s) successfully. I created the UBI partition and
> > > > > formatted it in Debian 11.x, Linux kernel 5.19.x. I could let the
> > > > > u-boot distro boot scan the UBI partition to find the boot script
> > > > > boot.scr. And also mount it manually to look at the file system.
> > > >
> > > > Hello! I think you mean UBIFS on UBI, right?
> > >
> > > Yes. UBIFS on UBI.
> > >
> > > >
> > > > > An observation: I cannot mount OpenWrt rootfs in u-boot, since it is
> > > > > an UBIFS volume overlay on squashfs. But creating my own UBIFS volume
> > > > > allowed me to mount it in the u-boot command line. I think squashfs is
> > > > > incomplete in u-boot, at the moment.
> > > >
> > > > UBIFS on squashfs? This looks strange. AFAIK UBIFS (also on linux) works
> > > > only on UBI. I guess you could have squashfs on UBI, but on linux this
> > > > requires mtdblock, hence it is squashfs on mtdblock on UBI.
> > >
> > > I meant that (the rootfs) is a squashfs inside an UBIFS volume. And
> > > the system running with another UBIFS volume overlaid on top of that.
> >
> > Just to clarify: OpenWrt uses squashfs in UBI volumes for the compressed
> > rootfs. In Linux, ubiblock is used to mount them.
>
> That is what I thought. squashfs on ubiblock. IIRC U-Boot does not
> implement neither mtdblock (block device on mtd) nor ubiblock (block
> device on top of ubi volume). So mounting squashfs (which is block based
> filesystem) from ubi volume does not work in u-boot.
>
> I think implementation should not be such hard, this sounds like and
> interesting exercise.
>
> But I'm more interested to figure out why UBIFS does not want to work on
> ARM Omap3 Nokia N900, but works fine on PowerPC Freescale P2020
>
> > We also usually don't store the kernel in a filesystem but just use a
> > bare UBI volume to directly store the uImage.FIT to be booted, for both
> > simplicity and robustness reasons.
> > On devices with recent enough U-Boot we can use a 'filesystem'-type
> > sub-image of a uImage.FIT for squashfs and mount that in Linux.
> >
> > >
> > > Best,
> > > Tony
> > >
> > > >
> > > > > Best,
> > > > > Tony
> > > > >
> > > > >
> > > > > >  Function
> > > > > > check_lpt_crc in unpack_ltab is failing. Volume is for sure correct 
> > > > > > and
> > > > > > valid because Linux kernel can successfully mount it. And to make it
> > > > > > more suspicious, U-Boot UBIFS is working fine on big endian powerpc
> > > > > > platform. So UBIFS issue is probably endian or arch specific.
> > > > > > (This is UBIFS related, not UBI related.)
> > > > > >
> > > > > > Pali Rohár (9):
> > > > > >   Nokia RX-51: Remove label copy_kernel_start from lowlevel_init.S
> > > > > >   Nokia RX-51: Do not clear unknown memory in lowlevel_init.S
> > > > > >   Nokia RX-51: Set default SYS_LOAD_ADDR to 0x80008000
> > > > > >   Nokia RX-51: Change UBIFS volume size to 1870 LEBs in test script
> > > > > >   Nokia RX-51: Call bootm in test script only when image is valid
> > > > > >   Nokia RX-51: Fix documentation how to enable UBI support
> > > > > >   Nokia RX-51: Do not set useless ARCH= in test script
> > > > > >   Nokia RX-51: Add comment describing kernel image type into test 
> > > > > > script
> > > > > >   Nokia RX-51: Add booting from UBI into test script
> > > > > >
> > > > > >  board/nokia/rx51/lowlevel_init.S |  7 +--
> > > > > >  configs/nokia_rx51_defconfig |  2 +-
> > > > > >  doc/board/nokia/rx51.rst |  3 +-
> > > > > >  test/nokia_rx51_test.sh  | 97 
> > > > > > +---
> > > > > >  4 files changed, 82 insertions(+), 27 deletions(-)
> > > > > >
> > > > > > --
> > > > > > 2.20.1
> > > > > >

Re: [PATCH v9 05/15] stm32mp1: dk2: Add image information for capsule updates

[Etienne Carriere]

Hello Sughosh,

On Fri, 26 Aug 2022 at 11:57, Sughosh Ganu  wrote:
>
> Enabling capsule update functionality on the platform requires
> populating information on the images that are to be updated using the
> functionality. Do so for the DK2 board.
>
> Signed-off-by: Sughosh Ganu 
> ---
> Changes since V8:
> * Use STM32MP_FIP_IMAGE_GUID for the FIP GUID value as suggested by
>   Yann
>
>  board/st/stm32mp1/stm32mp1.c   | 23 +++
>  include/configs/stm32mp15_common.h |  4 
>  2 files changed, 27 insertions(+)
>
> diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
> index 9496890d16..bfec0a710d 100644
> --- a/board/st/stm32mp1/stm32mp1.c
> +++ b/board/st/stm32mp1/stm32mp1.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -87,6 +88,16 @@
>  #define USB_START_LOW_THRESHOLD_UV 123
>  #define USB_START_HIGH_THRESHOLD_UV215
>
> +#if CONFIG_IS_ENABLED(EFI_HAVE_CAPSULE_SUPPORT)
> +struct efi_fw_image fw_images[1];
> +
> +struct efi_capsule_update_info update_info = {
> +   .images = fw_images,
> +};
> +
> +u8 num_image_type_guids = ARRAY_SIZE(fw_images);
> +#endif /* EFI_HAVE_CAPSULE_SUPPORT */
> +
>  int board_early_init_f(void)
>  {
> /* nothing to do, only used in SPL */
> @@ -670,6 +681,18 @@ int board_init(void)
>
> setup_led(LEDST_ON);
>
> +#if CONFIG_IS_ENABLED(EFI_HAVE_CAPSULE_SUPPORT)
> +   if (board_is_stm32mp15x_dk2()) {

Sorry for this late comment.
Should this be restricted to mp15-dk2?
I would remove the test and apply when CONFIG_EFI_HAVE_CAPSULE_SUPPORT
is enable.


> +   efi_guid_t image_type_guid = STM32MP_FIP_IMAGE_GUID;
> +   guidcpy(_images[0].image_type_id, _type_guid);
> +   fw_images[0].fw_name = u"STM32MP-FIP";
> +   /*
> +* For FWU multi bank update, the image
> +* index will be computed at runtime
> +*/
> +   fw_images[0].image_index = 0;
> +   }
> +#endif
> return 0;
>  }
>
> diff --git a/include/configs/stm32mp15_common.h 
> b/include/configs/stm32mp15_common.h
> index c5412ffeb3..bb19dae945 100644
> --- a/include/configs/stm32mp15_common.h
> +++ b/include/configs/stm32mp15_common.h
> @@ -34,6 +34,10 @@
>  #define CONFIG_SERVERIP 192.168.1.1
>  #endif
>
> +#define STM32MP_FIP_IMAGE_GUID \
> +   EFI_GUID(0x19d5df83, 0x11b0, 0x457b, 0xbe, 0x2c, \
> +0x75, 0x59, 0xc1, 0x31, 0x42, 0xa5)
> +
>  
> /*/
>  #ifdef CONFIG_DISTRO_DEFAULTS
>  
> /*/
> --
> 2.34.1
>

Re: [PATCH 1/2] rpi: Copy properties from firmware dtb to the loaded dtb

[Antoine Mazeas]

Sorry following up on your last comment, what specific issues are you 
referring to on the rev 1.3+ pi 4s ? It may be worth hunting them down, 
although I may lack access to such boards.


Le 05/09/2022 à 15:41, Peter Robinson a écrit :

Tested on RPi400 and it solves the issues with the kernel DT I've seen
plus some RPi4s although no the rev 1.3+ devices that also have the
newer SoC rev that's the same in the rpi400

Re: [PATCH 1/2] rpi: Copy properties from firmware dtb to the loaded dtb

[Antoine Mazeas]

Hi Peter,
Thanks for looking at this patch

Le 05/09/2022 à 15:41, Peter Robinson a écrit :

On Wed, Aug 10, 2022 at 1:58 PM Antoine Mazeas  wrote:


The RPI firmware adjusts several property values in the dtb it passes
to u-boot depending on the board/SoC revision. Inherit some of these
when u-boot loads a dtb itself. Specificaly copy:

* /model: The firmware provides a more specific string
* /memreserve: The firmware defines a reserved range, better keep it


Is this the CMA range or a different one? If so this makes sense.


This a different range than that of the CMA (which itself is defined at 
/reserved-memory/linux,cma): it's a reserved memory range for the 
VideoCore module on the SoC. In the case of the rpi 400 (and sister 
boards like 4B based on the same chip), the dummy value in the DTB is 
patched by the firmware to a dynamic value set in config.txt; absent 
this config, the default amount is 76 MiBs (see: datasheet 
https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf and 
rpi config reference 
https://www.raspberrypi.com/documentation/computers/config_txt.html#memory-options). 
I can see this happening on my board, where looking at the device tree 
on a running system:


memreserve = <0x3b40 0x4c0>; // 0x4c0 == 76 MiBs

Note the start of the range is also patched in. Given the dynamic nature 
of this setting on at least bcm2711 rpi boards, I think this is worth 
carrying over.



* emmc2bus and pcie0 dma-ranges: The C0T revision of the bcm2711 Soc (as
   present on rpi 400 and some rpi 4B boards) has different values for
   these then the B0T revision. So these need to be adjusted to boot on
   these boards
* blconfig: The firmware defines the memory area where the blconfig
   stored. Copy those over so it can be enabled.
* /chosen/kaslr-seed: The firmware generates a kaslr seed, take advantage
   of that.


U-Boot has a rpi4 iproc_rng200 driver for this and provides it via the
UEFI random seed as well, if you're booting using UEFI that takes
precedence so providing this might not be useful but also it doesn't
matter much.


Signed-off-by: Sjoerd Simons 


Reviewed-by: Peter Robinson 
Tested-by: Peter Robinson 

Tested on RPi400 and it solves the issues with the kernel DT I've seen
plus some RPi4s although no the rev 1.3+ devices that also have the
newer SoC rev that's the same in the rpi400


---
  board/raspberrypi/rpi/rpi.c | 48 +
  1 file changed, 48 insertions(+)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 17b8108cc8..28b6f52506 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -504,10 +504,58 @@ void *board_fdt_blob_setup(int *err)
 return (void *)fw_dtb_pointer;
  }

+int copy_property(void *dst, void *src, char *path, char *property)
+{
+   int dst_offset, src_offset;
+   const fdt32_t *prop;
+   int len;
+
+   src_offset = fdt_path_offset(src, path);
+   dst_offset = fdt_path_offset(dst, path);
+
+   if (src_offset < 0 || dst_offset < 0)
+   return -1;
+
+   prop = fdt_getprop(src, src_offset, property, );
+   if (!prop)
+   return -1;
+
+   return fdt_setprop(dst, dst_offset, property, prop, len);
+}
+
+/* Copy tweaks from the firmware dtb to the loaded dtb */
+void  update_fdt_from_fw(void *fdt, void *fw_fdt)
+{
+   /* Using dtb from firmware directly; leave it alone */
+   if (fdt == fw_fdt)
+   return;
+
+   /* The firmware provides a more precie model; so copy that */
+   copy_property(fdt, fw_fdt, "/", "model");
+
+   /* memory reserve as suggested by the firmware */
+   copy_property(fdt, fw_fdt, "/", "memreserve");
+
+   /* Adjust dma-ranges for the SD card and PCI bus as they can depend on
+* the SoC revision
+*/
+   copy_property(fdt, fw_fdt, "emmc2bus", "dma-ranges");
+   copy_property(fdt, fw_fdt, "pcie0", "dma-ranges");
+
+   /* Bootloader configuration template exposes as nvmem */
+   if (copy_property(fdt, fw_fdt, "blconfig", "reg") == 0)
+   copy_property(fdt, fw_fdt, "blconfig", "status");
+
+   /* kernel address randomisation seed as provided by the firmware */
+   copy_property(fdt, fw_fdt, "/chosen", "kaslr-seed");
+}
+
  int ft_board_setup(void *blob, struct bd_info *bd)
  {
 int node;

+   update_fdt_from_fw(blob, (void *)fw_dtb_pointer);
+
 node = fdt_node_offset_by_compatible(blob, -1, "simple-framebuffer");
 if (node < 0)
 fdt_simplefb_add_node(blob);
--
2.37.1

Re: [PATCH] configs: stm32mp*: fix system reset

[Oleksandr Suvorov]

On Mon, Sep 5, 2022 at 8:34 PM Jorge Ramirez-Ortiz  wrote:
>
> Enabling CONFIG_SYSRESET_PSCI prevents CONFIG_RESET_SCMI
> from executing.
>
> The side effect observed are I2C devices no longer being
> accessible from U-boot after a soft reset.
>
> Fixes: 11517ccc8c52 ("configs: add stm32mp13 defconfig")
> Fixes: 17aeb589fa9d ("stm32mp15: remove configs dependency on
>   CONFIG_TFABOOT")
>
> Signed-off-by: Jorge Ramirez-Ortiz 

Acked-by: Oleksandr Suvorov 

> ---
>  configs/stm32mp13_defconfig | 1 -
>  configs/stm32mp15_defconfig | 1 -
>  configs/stm32mp15_trusted_defconfig | 1 -
>  3 files changed, 3 deletions(-)
>
> diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig
> index 673b468d31..44cee2e656 100644
> --- a/configs/stm32mp13_defconfig
> +++ b/configs/stm32mp13_defconfig
> @@ -69,7 +69,6 @@ CONFIG_RNG_OPTEE=y
>  CONFIG_DM_RTC=y
>  CONFIG_RTC_STM32=y
>  CONFIG_SERIAL_RX_BUFFER=y
> -CONFIG_SYSRESET_PSCI=y
>  CONFIG_TEE=y
>  CONFIG_OPTEE=y
>  # CONFIG_OPTEE_TA_AVB is not set
> diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig
> index e5a2996c2c..2ad02f3652 100644
> --- a/configs/stm32mp15_defconfig
> +++ b/configs/stm32mp15_defconfig
> @@ -133,7 +133,6 @@ CONFIG_SPI=y
>  CONFIG_DM_SPI=y
>  CONFIG_STM32_QSPI=y
>  CONFIG_STM32_SPI=y
> -CONFIG_SYSRESET_PSCI=y
>  CONFIG_TEE=y
>  CONFIG_OPTEE=y
>  # CONFIG_OPTEE_TA_AVB is not set
> diff --git a/configs/stm32mp15_trusted_defconfig 
> b/configs/stm32mp15_trusted_defconfig
> index e14668042f..9e24e82920 100644
> --- a/configs/stm32mp15_trusted_defconfig
> +++ b/configs/stm32mp15_trusted_defconfig
> @@ -134,7 +134,6 @@ CONFIG_SPI=y
>  CONFIG_DM_SPI=y
>  CONFIG_STM32_QSPI=y
>  CONFIG_STM32_SPI=y
> -CONFIG_SYSRESET_PSCI=y
>  CONFIG_TEE=y
>  CONFIG_OPTEE=y
>  # CONFIG_OPTEE_TA_AVB is not set
> --
> 2.34.1
>


-- 
Best regards
Oleksandr

Oleksandr Suvorov
cryo...@gmail.com

[PATCH] configs: stm32mp*: fix system reset

[Jorge Ramirez-Ortiz]

Enabling CONFIG_SYSRESET_PSCI prevents CONFIG_RESET_SCMI
from executing.

The side effect observed are I2C devices no longer being
accessible from U-boot after a soft reset.

Fixes: 11517ccc8c52 ("configs: add stm32mp13 defconfig")
Fixes: 17aeb589fa9d ("stm32mp15: remove configs dependency on
  CONFIG_TFABOOT")

Signed-off-by: Jorge Ramirez-Ortiz 
---
 configs/stm32mp13_defconfig | 1 -
 configs/stm32mp15_defconfig | 1 -
 configs/stm32mp15_trusted_defconfig | 1 -
 3 files changed, 3 deletions(-)

diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig
index 673b468d31..44cee2e656 100644
--- a/configs/stm32mp13_defconfig
+++ b/configs/stm32mp13_defconfig
@@ -69,7 +69,6 @@ CONFIG_RNG_OPTEE=y
 CONFIG_DM_RTC=y
 CONFIG_RTC_STM32=y
 CONFIG_SERIAL_RX_BUFFER=y
-CONFIG_SYSRESET_PSCI=y
 CONFIG_TEE=y
 CONFIG_OPTEE=y
 # CONFIG_OPTEE_TA_AVB is not set
diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig
index e5a2996c2c..2ad02f3652 100644
--- a/configs/stm32mp15_defconfig
+++ b/configs/stm32mp15_defconfig
@@ -133,7 +133,6 @@ CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_STM32_QSPI=y
 CONFIG_STM32_SPI=y
-CONFIG_SYSRESET_PSCI=y
 CONFIG_TEE=y
 CONFIG_OPTEE=y
 # CONFIG_OPTEE_TA_AVB is not set
diff --git a/configs/stm32mp15_trusted_defconfig 
b/configs/stm32mp15_trusted_defconfig
index e14668042f..9e24e82920 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -134,7 +134,6 @@ CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_STM32_QSPI=y
 CONFIG_STM32_SPI=y
-CONFIG_SYSRESET_PSCI=y
 CONFIG_TEE=y
 CONFIG_OPTEE=y
 # CONFIG_OPTEE_TA_AVB is not set
-- 
2.34.1

Re: [PATCH v3 3/6] serial: Implement flush callback

[Pali Rohár]

On Monday 05 September 2022 19:24:17 Michael Nazzareno Trimarchi wrote:
> Hi
> 
> Il lun 5 set 2022, 11:32 Pali Rohár  ha scritto:
> 
> > UART drivers have putc/puts functions which just put characters into HW
> > transmit queue and do not wait until all data are transmitted.
> >
> > Implement flush callback via serial driver's pending(false) callback which
> > waits until HW transmit all characters from the queue.
> >
> 
> This is a drain if you want to wait. Is not the right terminology?

Yes, for tty devices it is drain. But for C stdio.h it is (f)flush.
Hence I used more generic name flush() as it is not only for serial
devices, but for any U-Boot stdio device. E.g. sandbox os use real
fflush function.

But feel free to choose any other name of function. I do not care a much
about it.

> Michael
> 
> 
> > Signed-off-by: Pali Rohár 
> > ---
> >  drivers/serial/serial-uclass.c | 20 
> >  1 file changed, 20 insertions(+)
> >
> > diff --git a/drivers/serial/serial-uclass.c
> > b/drivers/serial/serial-uclass.c
> > index 30650e37b0d7..be6502f3d24c 100644
> > --- a/drivers/serial/serial-uclass.c
> > +++ b/drivers/serial/serial-uclass.c
> > @@ -238,6 +238,18 @@ static void _serial_puts(struct udevice *dev, const
> > char *str)
> > } while (*str);
> >  }
> >
> > +#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
> > +static void _serial_flush(struct udevice *dev)
> > +{
> > +   struct dm_serial_ops *ops = serial_get_ops(dev);
> > +
> > +   if (!ops->pending)
> > +   return;
> > +   while (ops->pending(dev, false) > 0)
> > +   ;
> > +}
> > +#endif
> > +
> >  static int __serial_getc(struct udevice *dev)
> >  {
> > struct dm_serial_ops *ops = serial_get_ops(dev);
> > @@ -398,6 +410,13 @@ static void serial_stub_puts(struct stdio_dev *sdev,
> > const char *str)
> > _serial_puts(sdev->priv, str);
> >  }
> >
> > +#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
> > +static void serial_stub_flush(struct stdio_dev *sdev)
> > +{
> > +   _serial_flush(sdev->priv);
> > +}
> > +#endif
> > +
> >  static int serial_stub_getc(struct stdio_dev *sdev)
> >  {
> > return _serial_getc(sdev->priv);
> > @@ -520,6 +539,7 @@ static int serial_post_probe(struct udevice *dev)
> > sdev.priv = dev;
> > sdev.putc = serial_stub_putc;
> > sdev.puts = serial_stub_puts;
> > +   STDIO_DEV_ASSIGN_FLUSH(, serial_stub_flush);
> > sdev.getc = serial_stub_getc;
> > sdev.tstc = serial_stub_tstc;
> >
> > --
> > 2.20.1
> >
> >

Re: [PATCH v3 3/6] serial: Implement flush callback

[Michael Nazzareno Trimarchi]

Hi

Il lun 5 set 2022, 11:32 Pali Rohár  ha scritto:

> UART drivers have putc/puts functions which just put characters into HW
> transmit queue and do not wait until all data are transmitted.
>
> Implement flush callback via serial driver's pending(false) callback which
> waits until HW transmit all characters from the queue.
>

This is a drain if you want to wait. Is not the right terminology?

Michael


> Signed-off-by: Pali Rohár 
> ---
>  drivers/serial/serial-uclass.c | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/drivers/serial/serial-uclass.c
> b/drivers/serial/serial-uclass.c
> index 30650e37b0d7..be6502f3d24c 100644
> --- a/drivers/serial/serial-uclass.c
> +++ b/drivers/serial/serial-uclass.c
> @@ -238,6 +238,18 @@ static void _serial_puts(struct udevice *dev, const
> char *str)
> } while (*str);
>  }
>
> +#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
> +static void _serial_flush(struct udevice *dev)
> +{
> +   struct dm_serial_ops *ops = serial_get_ops(dev);
> +
> +   if (!ops->pending)
> +   return;
> +   while (ops->pending(dev, false) > 0)
> +   ;
> +}
> +#endif
> +
>  static int __serial_getc(struct udevice *dev)
>  {
> struct dm_serial_ops *ops = serial_get_ops(dev);
> @@ -398,6 +410,13 @@ static void serial_stub_puts(struct stdio_dev *sdev,
> const char *str)
> _serial_puts(sdev->priv, str);
>  }
>
> +#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
> +static void serial_stub_flush(struct stdio_dev *sdev)
> +{
> +   _serial_flush(sdev->priv);
> +}
> +#endif
> +
>  static int serial_stub_getc(struct stdio_dev *sdev)
>  {
> return _serial_getc(sdev->priv);
> @@ -520,6 +539,7 @@ static int serial_post_probe(struct udevice *dev)
> sdev.priv = dev;
> sdev.putc = serial_stub_putc;
> sdev.puts = serial_stub_puts;
> +   STDIO_DEV_ASSIGN_FLUSH(, serial_stub_flush);
> sdev.getc = serial_stub_getc;
> sdev.tstc = serial_stub_tstc;
>
> --
> 2.20.1
>
>

Re: RISCV: the machanism of available_harts may cause other harts boot failure

[Nikita Shubin]

On Mon, 5 Sep 2022 11:30:38 -0400
Sean Anderson  wrote:

> On 9/5/22 3:47 AM, Nikita Shubin wrote:
> > Hi Rick!
> > 
> > On Mon, 5 Sep 2022 14:22:41 +0800
> > Rick Chen  wrote:
> >   
> >> Hi,
> >>
> >> When I free-run a SMP system, I once hit a failure case where some
> >> harts didn't boot to the kernel shell successfully.
> >> However it can't be duplicated anymore even if I try many times.
> >>
> >> But when I set a break during debugging with GDB, it can trigger
> >> the failure case each time.  
> > 
> > If hart fails to register itself to available_harts before
> > send_ipi_many is hit by the main hart:
> > https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/riscv/lib/smp.c#L50
> > 
> > it won't exit the secondary_hart_loop:
> > https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/riscv/cpu/start.S#L433
> > As no ipi will be sent to it.
> > 
> > This might be exactly your case.  
> 
> When working on the IPI mechanism, I considered this possibility.
> However, there's really no way to know how long to wait. On normal
> systems, the boot hart is going to do a lot of work before calling
> send_ipi_many, and the other harts just have to make it through ~100
> instructions. So I figured we would never run into this issue.
> 
> We might not even need the mask... the only direct reason we might is
> for OpenSBI, as spl_invoke_opensbi is the only function which uses
> the wait parameter.

Actually i think available_harts in is duplicated by device tree,
so we can:

1) drop registering harts in start.S (and related lock completely)
2) fill gd->arch.available_harts in send_ipi_many relying on device
tree, and also making riscv_send_ipi non-fatal
3) move this procedure to the very end just before spl_invoke_opensbi
4) may be even wrap all above in some CONFIG option which enforces
checking that harts are alive, otherwise just pass the device tree harts
count

> 
> >> I think the mechanism of available_harts does not provide a method
> >> that guarantees the success of the SMP system.
> >> Maybe we shall think of a better way for the SMP booting or just
> >> remove it ?  
> > 
> > I haven't experienced any unexplained problem with hart_lottery or
> > available_harts_lock unless:
> > 
> > 1) harts are started non-simultaneously
> > 2) SPL/U-Boot is in some kind of TCM, OCRAM, etc... which is not
> > cleared on reset which leaves available_harts dirty  
> 
> XIP, of course, has this problem every time and just doesn't use the
> mask. I remember thinking a lot about how to deal with this, but I
> never ended up sending a patch because I didn't have a XIP system.

It can be in some part emulated by setting up SPL region as
read-only via PMP before start.

> 
> --Sean
> 
> > 3) something is wrong with atomics
> > 
> > Also there might be something wrong with IPI send/recieve.
> >   
> >>
> >> Thread 8 hit Breakpoint 1, harts_early_init ()
> >>
> >> (gdb) c
> >> Continuing.
> >> [Switching to Thread 7]
> >>
> >> Thread 7 hit Breakpoint 1, harts_early_init ()
> >>
> >> (gdb)
> >> Continuing.
> >> [Switching to Thread 6]
> >>
> >> Thread 6 hit Breakpoint 1, harts_early_init ()
> >>
> >> (gdb)
> >> Continuing.
> >> [Switching to Thread 5]
> >>
> >> Thread 5 hit Breakpoint 1, harts_early_init ()
> >>
> >> (gdb)
> >> Continuing.
> >> [Switching to Thread 4]
> >>
> >> Thread 4 hit Breakpoint 1, harts_early_init ()
> >>
> >> (gdb)
> >> Continuing.
> >> [Switching to Thread 3]
> >>
> >> Thread 3 hit Breakpoint 1, harts_early_init ()
> >> (gdb)
> >> Continuing.
> >> [Switching to Thread 2]
> >>
> >> Thread 2 hit Breakpoint 1, harts_early_init ()
> >> (gdb)
> >> Continuing.
> >> [Switching to Thread 1]
> >>
> >> Thread 1 hit Breakpoint 1, harts_early_init ()
> >> (gdb)
> >> Continuing.
> >> [Switching to Thread 5]
> >>
> >>
> >> Thread 5 hit Breakpoint 3, 0x0120 in ?? ()
> >> (gdb) info threads
> >>Id   Target Id Frame
> >>1Thread 1 (hart 1) secondary_hart_loop () at
> >> arch/riscv/cpu/start.S:436 2Thread 2 (hart 2)
> >> secondary_hart_loop () at arch/riscv/cpu/start.S:436 3Thread 3
> >> (hart 3) secondary_hart_loop () at arch/riscv/cpu/start.S:436 4
> >> Thread 4 (hart 4) secondary_hart_loop () at
> >> arch/riscv/cpu/start.S:436
> >> * 5Thread 5 (hart 5) 0x0120 in ?? ()
> >>6Thread 6 (hart 6) 0xb650 in ?? ()
> >>7Thread 7 (hart 7) 0xb650 in ?? ()
> >>8Thread 8 (hart 8) 0x5fa0 in ?? ()
> >> (gdb) c
> >> Continuing.  
> > 
> > Do they all "offline" harts remain in SPL/U-Boot
> > secondary_hart_loop ? 
> >>
> >>
> >>
> >> [0.175619] smp: Bringing up secondary CPUs ...
> >> [1.230474] CPU1: failed to come online
> >> [2.282349] CPU2: failed to come online
> >> [3.334394] CPU3: failed to come online
> >> [4.386783] CPU4: failed to come online
> >> [4.427829] smp: Brought up 1 node, 4 CPUs
> >>
> >>
> >> /root # cat /proc/cpuinfo
> >> processor   : 0
> >> hart: 4

Re: [PATCH] configs: stm32mp*: reset via CONFIG_RESET_SCMI

[Oleksandr Suvorov]

Jorge,

I think, renaming the patch to "fix" and adding a field "Fixes:"
should help accept it faster.

On Mon, Sep 5, 2022 at 7:32 PM Jorge Ramirez-Ortiz, Foundries
 wrote:
>
> On 30/08/22, Jorge Ramirez-Ortiz wrote:
> > Enabling CONFIG_SYSRESET_PSCI prevents CONFIG_RESET_SCMI
> > from executing.
> >
> > The side effect observed are I2C devices no longer being
> > accessible from U-boot after a soft reset.
>
> I think this PR should get a bit more of attention.
>
> The current reset configuration is broken, this is a fix.
> Do I need to rename the PR?
>
> TIA
> jorge
>
>
> >
> > Signed-off-by: Jorge Ramirez-Ortiz 
> > ---
> >  configs/stm32mp13_defconfig | 1 -
> >  configs/stm32mp15_defconfig | 1 -
> >  configs/stm32mp15_trusted_defconfig | 1 -
> >  3 files changed, 3 deletions(-)
> >
> > diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig
> > index 673b468d31..44cee2e656 100644
> > --- a/configs/stm32mp13_defconfig
> > +++ b/configs/stm32mp13_defconfig
> > @@ -69,7 +69,6 @@ CONFIG_RNG_OPTEE=y
> >  CONFIG_DM_RTC=y
> >  CONFIG_RTC_STM32=y
> >  CONFIG_SERIAL_RX_BUFFER=y
> > -CONFIG_SYSRESET_PSCI=y
> >  CONFIG_TEE=y
> >  CONFIG_OPTEE=y
> >  # CONFIG_OPTEE_TA_AVB is not set
> > diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig
> > index e5a2996c2c..2ad02f3652 100644
> > --- a/configs/stm32mp15_defconfig
> > +++ b/configs/stm32mp15_defconfig
> > @@ -133,7 +133,6 @@ CONFIG_SPI=y
> >  CONFIG_DM_SPI=y
> >  CONFIG_STM32_QSPI=y
> >  CONFIG_STM32_SPI=y
> > -CONFIG_SYSRESET_PSCI=y
> >  CONFIG_TEE=y
> >  CONFIG_OPTEE=y
> >  # CONFIG_OPTEE_TA_AVB is not set
> > diff --git a/configs/stm32mp15_trusted_defconfig 
> > b/configs/stm32mp15_trusted_defconfig
> > index e14668042f..9e24e82920 100644
> > --- a/configs/stm32mp15_trusted_defconfig
> > +++ b/configs/stm32mp15_trusted_defconfig
> > @@ -134,7 +134,6 @@ CONFIG_SPI=y
> >  CONFIG_DM_SPI=y
> >  CONFIG_STM32_QSPI=y
> >  CONFIG_STM32_SPI=y
> > -CONFIG_SYSRESET_PSCI=y
> >  CONFIG_TEE=y
> >  CONFIG_OPTEE=y
> >  # CONFIG_OPTEE_TA_AVB is not set
> > --
> > 2.34.1
> >



-- 
Best regards
Oleksandr

Oleksandr Suvorov
cryo...@gmail.com

Re: [PATCH] configs: stm32mp*: reset via CONFIG_RESET_SCMI

[Jorge Ramirez-Ortiz, Foundries]

On 30/08/22, Jorge Ramirez-Ortiz wrote:
> Enabling CONFIG_SYSRESET_PSCI prevents CONFIG_RESET_SCMI
> from executing.
> 
> The side effect observed are I2C devices no longer being
> accessible from U-boot after a soft reset.

I think this PR should get a bit more of attention.

The current reset configuration is broken, this is a fix.
Do I need to rename the PR?

TIA
jorge


> 
> Signed-off-by: Jorge Ramirez-Ortiz 
> ---
>  configs/stm32mp13_defconfig | 1 -
>  configs/stm32mp15_defconfig | 1 -
>  configs/stm32mp15_trusted_defconfig | 1 -
>  3 files changed, 3 deletions(-)
> 
> diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig
> index 673b468d31..44cee2e656 100644
> --- a/configs/stm32mp13_defconfig
> +++ b/configs/stm32mp13_defconfig
> @@ -69,7 +69,6 @@ CONFIG_RNG_OPTEE=y
>  CONFIG_DM_RTC=y
>  CONFIG_RTC_STM32=y
>  CONFIG_SERIAL_RX_BUFFER=y
> -CONFIG_SYSRESET_PSCI=y
>  CONFIG_TEE=y
>  CONFIG_OPTEE=y
>  # CONFIG_OPTEE_TA_AVB is not set
> diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig
> index e5a2996c2c..2ad02f3652 100644
> --- a/configs/stm32mp15_defconfig
> +++ b/configs/stm32mp15_defconfig
> @@ -133,7 +133,6 @@ CONFIG_SPI=y
>  CONFIG_DM_SPI=y
>  CONFIG_STM32_QSPI=y
>  CONFIG_STM32_SPI=y
> -CONFIG_SYSRESET_PSCI=y
>  CONFIG_TEE=y
>  CONFIG_OPTEE=y
>  # CONFIG_OPTEE_TA_AVB is not set
> diff --git a/configs/stm32mp15_trusted_defconfig 
> b/configs/stm32mp15_trusted_defconfig
> index e14668042f..9e24e82920 100644
> --- a/configs/stm32mp15_trusted_defconfig
> +++ b/configs/stm32mp15_trusted_defconfig
> @@ -134,7 +134,6 @@ CONFIG_SPI=y
>  CONFIG_DM_SPI=y
>  CONFIG_STM32_QSPI=y
>  CONFIG_STM32_SPI=y
> -CONFIG_SYSRESET_PSCI=y
>  CONFIG_TEE=y
>  CONFIG_OPTEE=y
>  # CONFIG_OPTEE_TA_AVB is not set
> -- 
> 2.34.1
> 

Re: RISCV: the machanism of available_harts may cause other harts boot failure

[Heinrich Schuchardt]

On 9/5/22 18:14, Sean Anderson wrote:

On 9/5/22 12:00 PM, Heinrich Schuchardt wrote:

On 9/5/22 17:45, Sean Anderson wrote:

On 9/5/22 11:41 AM, Heinrich Schuchardt wrote:

On 9/5/22 17:30, Sean Anderson wrote:

On 9/5/22 3:47 AM, Nikita Shubin wrote:

Hi Rick!

On Mon, 5 Sep 2022 14:22:41 +0800
Rick Chen  wrote:


Hi,

When I free-run a SMP system, I once hit a failure case where some
harts didn't boot to the kernel shell successfully.
However it can't be duplicated anymore even if I try many times.

But when I set a break during debugging with GDB, it can trigger the
failure case each time.


If hart fails to register itself to available_harts before
send_ipi_many is hit by the main hart:
https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/riscv/lib/smp.c#L50

it won't exit the secondary_hart_loop:
https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/riscv/cpu/start.S#L433
As no ipi will be sent to it.


Can we call send_ipi_many() again when booting?


AFAIK we do; see arch/riscv/lib/bootm.c and arch/riscv/lib/spl.c


arch/riscv/lib/bootm.c:99:
ret = smp_call_function(images->ep,

This has no effect when booting via UEFI.


How do you figure?


U-Boot never calls the legacy entry point when booting via UEFI.




Should efi_exit_boot_services() call the function?


Generally, this needs to be called when secondary_hart_loop is going to be
overwritten. This can either be because U-Boot is relocating (and so
something
else may occupy the space where it used to be), or we are executing the
next
stage of boot (which may then reuse the memory occupied by
secondary_hart_loop
for something else).

AIUI the EFI client?/payload? gets started by U-Boot, which sticks around
providing services. I would expect the initial jump to the EFI payload
to cause
the secondary harts to jump there as well.


Secondary harts never enter UEFI payloads.

Best regards

Heinrich



--Sean


Best regards

Heinrich




Do we need to call it before booting?


Yes. We also call it when relocating (in SPL and U-Boot proper).



This might be exactly your case.


When working on the IPI mechanism, I considered this possibility.
However,
there's really no way to know how long to wait. On normal systems,
the boot
hart is going to do a lot of work before calling send_ipi_many, and
the
other harts just have to make it through ~100 instructions. So I
figured we
would never run into this issue.

We might not even need the mask... the only direct reason we might is
for
OpenSBI, as spl_invoke_opensbi is the only function which uses the
wait
parameter.


I think the mechanism of available_harts does not provide a method
that guarantees the success of the SMP system.
Maybe we shall think of a better way for the SMP booting or just
remove it ?


I haven't experienced any unexplained problem with hart_lottery or
available_harts_lock unless:

1) harts are started non-simultaneously
2) SPL/U-Boot is in some kind of TCM, OCRAM, etc... which is not
cleared
on reset which leaves available_harts dirty


XIP, of course, has this problem every time and just doesn't use the
mask.
I remember thinking a lot about how to deal with this, but I never
ended
up sending a patch because I didn't have a XIP system.

--Sean


3) something is wrong with atomics

Also there might be something wrong with IPI send/recieve.



Thread 8 hit Breakpoint 1, harts_early_init ()

(gdb) c
Continuing.
[Switching to Thread 7]

Thread 7 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 6]

Thread 6 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 5]

Thread 5 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 4]

Thread 4 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 3]

Thread 3 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 2]

Thread 2 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 1]

Thread 1 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 5]


Thread 5 hit Breakpoint 3, 0x0120 in ?? ()
(gdb) info threads
   Id   Target Id Frame
   1    Thread 1 (hart 1) secondary_hart_loop () at
arch/riscv/cpu/start.S:436 2    Thread 2 (hart 2)
secondary_hart_loop
() at arch/riscv/cpu/start.S:436 3    Thread 3 (hart 3)
secondary_hart_loop () at arch/riscv/cpu/start.S:436 4    Thread 4
(hart 4) secondary_hart_loop () at arch/riscv/cpu/start.S:436
* 5    Thread 5 (hart 5) 0x0120 in ?? ()
   6    Thread 6 (hart 6) 0xb650 in ?? ()
   7    Thread 7 (hart 7) 0xb650 in ?? ()
   8    Thread 8 (hart 8) 0x5fa0 in ?? ()
(gdb) c
Continuing.


Do they all "offline" harts remain in SPL/U-Boot
secondary_hart_loop ?





[    0.175619] smp: Bringing up secondary CPUs ...
[    1.230474] CPU1: failed to come online
[    2.282349] CPU2: failed to come online
[    3.334394] CPU3: failed to come online
[    4.386783] CPU4: failed 

Re: RISCV: the machanism of available_harts may cause other harts boot failure

[Sean Anderson]

On 9/5/22 12:00 PM, Heinrich Schuchardt wrote:

On 9/5/22 17:45, Sean Anderson wrote:

On 9/5/22 11:41 AM, Heinrich Schuchardt wrote:

On 9/5/22 17:30, Sean Anderson wrote:

On 9/5/22 3:47 AM, Nikita Shubin wrote:

Hi Rick!

On Mon, 5 Sep 2022 14:22:41 +0800
Rick Chen  wrote:


Hi,

When I free-run a SMP system, I once hit a failure case where some
harts didn't boot to the kernel shell successfully.
However it can't be duplicated anymore even if I try many times.

But when I set a break during debugging with GDB, it can trigger the
failure case each time.


If hart fails to register itself to available_harts before
send_ipi_many is hit by the main hart:
https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/riscv/lib/smp.c#L50

it won't exit the secondary_hart_loop:
https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/riscv/cpu/start.S#L433
As no ipi will be sent to it.


Can we call send_ipi_many() again when booting?


AFAIK we do; see arch/riscv/lib/bootm.c and arch/riscv/lib/spl.c


arch/riscv/lib/bootm.c:99:
ret = smp_call_function(images->ep,

This has no effect when booting via UEFI.


How do you figure?


Should efi_exit_boot_services() call the function?


Generally, this needs to be called when secondary_hart_loop is going to be
overwritten. This can either be because U-Boot is relocating (and so something
else may occupy the space where it used to be), or we are executing the next
stage of boot (which may then reuse the memory occupied by secondary_hart_loop
for something else).

AIUI the EFI client?/payload? gets started by U-Boot, which sticks around
providing services. I would expect the initial jump to the EFI payload to cause
the secondary harts to jump there as well.

--Sean


Best regards

Heinrich




Do we need to call it before booting?


Yes. We also call it when relocating (in SPL and U-Boot proper).



This might be exactly your case.


When working on the IPI mechanism, I considered this possibility.
However,
there's really no way to know how long to wait. On normal systems,
the boot
hart is going to do a lot of work before calling send_ipi_many, and the
other harts just have to make it through ~100 instructions. So I
figured we
would never run into this issue.

We might not even need the mask... the only direct reason we might is
for
OpenSBI, as spl_invoke_opensbi is the only function which uses the wait
parameter.


I think the mechanism of available_harts does not provide a method
that guarantees the success of the SMP system.
Maybe we shall think of a better way for the SMP booting or just
remove it ?


I haven't experienced any unexplained problem with hart_lottery or
available_harts_lock unless:

1) harts are started non-simultaneously
2) SPL/U-Boot is in some kind of TCM, OCRAM, etc... which is not
cleared
on reset which leaves available_harts dirty


XIP, of course, has this problem every time and just doesn't use the
mask.
I remember thinking a lot about how to deal with this, but I never ended
up sending a patch because I didn't have a XIP system.

--Sean


3) something is wrong with atomics

Also there might be something wrong with IPI send/recieve.



Thread 8 hit Breakpoint 1, harts_early_init ()

(gdb) c
Continuing.
[Switching to Thread 7]

Thread 7 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 6]

Thread 6 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 5]

Thread 5 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 4]

Thread 4 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 3]

Thread 3 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 2]

Thread 2 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 1]

Thread 1 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 5]


Thread 5 hit Breakpoint 3, 0x0120 in ?? ()
(gdb) info threads
   Id   Target Id Frame
   1    Thread 1 (hart 1) secondary_hart_loop () at
arch/riscv/cpu/start.S:436 2    Thread 2 (hart 2) secondary_hart_loop
() at arch/riscv/cpu/start.S:436 3    Thread 3 (hart 3)
secondary_hart_loop () at arch/riscv/cpu/start.S:436 4    Thread 4
(hart 4) secondary_hart_loop () at arch/riscv/cpu/start.S:436
* 5    Thread 5 (hart 5) 0x0120 in ?? ()
   6    Thread 6 (hart 6) 0xb650 in ?? ()
   7    Thread 7 (hart 7) 0xb650 in ?? ()
   8    Thread 8 (hart 8) 0x5fa0 in ?? ()
(gdb) c
Continuing.


Do they all "offline" harts remain in SPL/U-Boot secondary_hart_loop ?





[    0.175619] smp: Bringing up secondary CPUs ...
[    1.230474] CPU1: failed to come online
[    2.282349] CPU2: failed to come online
[    3.334394] CPU3: failed to come online
[    4.386783] CPU4: failed to come online
[    4.427829] smp: Brought up 1 node, 4 CPUs


/root # cat /proc/cpuinfo
processor   : 0
hart    : 4
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu   

Re: RISCV: the machanism of available_harts may cause other harts boot failure

[Heinrich Schuchardt]

On 9/5/22 17:45, Sean Anderson wrote:

On 9/5/22 11:41 AM, Heinrich Schuchardt wrote:

On 9/5/22 17:30, Sean Anderson wrote:

On 9/5/22 3:47 AM, Nikita Shubin wrote:

Hi Rick!

On Mon, 5 Sep 2022 14:22:41 +0800
Rick Chen  wrote:


Hi,

When I free-run a SMP system, I once hit a failure case where some
harts didn't boot to the kernel shell successfully.
However it can't be duplicated anymore even if I try many times.

But when I set a break during debugging with GDB, it can trigger the
failure case each time.


If hart fails to register itself to available_harts before
send_ipi_many is hit by the main hart:
https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/riscv/lib/smp.c#L50

it won't exit the secondary_hart_loop:
https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/riscv/cpu/start.S#L433
As no ipi will be sent to it.


Can we call send_ipi_many() again when booting?


AFAIK we do; see arch/riscv/lib/bootm.c and arch/riscv/lib/spl.c


arch/riscv/lib/bootm.c:99:
ret = smp_call_function(images->ep,

This has no effect when booting via UEFI.
Should efi_exit_boot_services() call the function?

Best regards

Heinrich




Do we need to call it before booting?


Yes. We also call it when relocating (in SPL and U-Boot proper).



This might be exactly your case.


When working on the IPI mechanism, I considered this possibility.
However,
there's really no way to know how long to wait. On normal systems,
the boot
hart is going to do a lot of work before calling send_ipi_many, and the
other harts just have to make it through ~100 instructions. So I
figured we
would never run into this issue.

We might not even need the mask... the only direct reason we might is
for
OpenSBI, as spl_invoke_opensbi is the only function which uses the wait
parameter.


I think the mechanism of available_harts does not provide a method
that guarantees the success of the SMP system.
Maybe we shall think of a better way for the SMP booting or just
remove it ?


I haven't experienced any unexplained problem with hart_lottery or
available_harts_lock unless:

1) harts are started non-simultaneously
2) SPL/U-Boot is in some kind of TCM, OCRAM, etc... which is not
cleared
on reset which leaves available_harts dirty


XIP, of course, has this problem every time and just doesn't use the
mask.
I remember thinking a lot about how to deal with this, but I never ended
up sending a patch because I didn't have a XIP system.

--Sean


3) something is wrong with atomics

Also there might be something wrong with IPI send/recieve.



Thread 8 hit Breakpoint 1, harts_early_init ()

(gdb) c
Continuing.
[Switching to Thread 7]

Thread 7 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 6]

Thread 6 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 5]

Thread 5 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 4]

Thread 4 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 3]

Thread 3 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 2]

Thread 2 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 1]

Thread 1 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 5]


Thread 5 hit Breakpoint 3, 0x0120 in ?? ()
(gdb) info threads
   Id   Target Id Frame
   1    Thread 1 (hart 1) secondary_hart_loop () at
arch/riscv/cpu/start.S:436 2    Thread 2 (hart 2) secondary_hart_loop
() at arch/riscv/cpu/start.S:436 3    Thread 3 (hart 3)
secondary_hart_loop () at arch/riscv/cpu/start.S:436 4    Thread 4
(hart 4) secondary_hart_loop () at arch/riscv/cpu/start.S:436
* 5    Thread 5 (hart 5) 0x0120 in ?? ()
   6    Thread 6 (hart 6) 0xb650 in ?? ()
   7    Thread 7 (hart 7) 0xb650 in ?? ()
   8    Thread 8 (hart 8) 0x5fa0 in ?? ()
(gdb) c
Continuing.


Do they all "offline" harts remain in SPL/U-Boot secondary_hart_loop ?





[    0.175619] smp: Bringing up secondary CPUs ...
[    1.230474] CPU1: failed to come online
[    2.282349] CPU2: failed to come online
[    3.334394] CPU3: failed to come online
[    4.386783] CPU4: failed to come online
[    4.427829] smp: Brought up 1 node, 4 CPUs


/root # cat /proc/cpuinfo
processor   : 0
hart    : 4
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu : sv39

processor   : 5
hart    : 5
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu : sv39

processor   : 6
hart    : 6
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu : sv39

processor   : 7
hart    : 7
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu : sv39

/root #

Thanks,
Rick

Re: [PATCH v16 10/10] test: unit test for eficonfig

[Heinrich Schuchardt]

On 9/5/22 14:48, Masahisa Kojima wrote:

Provide a unit test for the eficonfig command.

Signed-off-by: Masahisa Kojima 
Acked-by: Ilias Apalodimas 
---
Changes in v16:
- call u_boot_console.restart_uboot() to clean the previous test state


The test is still failing:
https://source.denx.de/u-boot/custodians/u-boot-efi/-/jobs/492069/raw

The same can be seen when running 'make tests' locally.

Best regards

Heinrich



Changes in v14:
- update to support media device enumeration in eficonfig startup
- move no block device test to the last test case

Changes in v12:
- update menu handling

Changes in v11:
- fix expected result when no BootOrder is defined

Newly added in v10

  configs/sandbox_defconfig |   1 +
  test/py/tests/test_eficonfig/conftest.py  |  40 ++
  .../py/tests/test_eficonfig/test_eficonfig.py | 354 ++
  3 files changed, 395 insertions(+)
  create mode 100644 test/py/tests/test_eficonfig/conftest.py
  create mode 100644 test/py/tests/test_eficonfig/test_eficonfig.py

diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index eba7bcbb48..48c60c606d 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -93,6 +93,7 @@ CONFIG_CMD_LINK_LOCAL=y
  CONFIG_CMD_ETHSW=y
  CONFIG_CMD_BMP=y
  CONFIG_CMD_BOOTCOUNT=y
+CONFIG_CMD_EFICONFIG=y
  CONFIG_CMD_EFIDEBUG=y
  CONFIG_CMD_RTC=y
  CONFIG_CMD_TIME=y
diff --git a/test/py/tests/test_eficonfig/conftest.py 
b/test/py/tests/test_eficonfig/conftest.py
new file mode 100644
index 00..f289df0362
--- /dev/null
+++ b/test/py/tests/test_eficonfig/conftest.py
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier:  GPL-2.0+
+
+"""Fixture for UEFI eficonfig test
+"""
+
+import os
+import shutil
+from subprocess import check_call
+import pytest
+
+@pytest.fixture(scope='session')
+def efi_eficonfig_data(u_boot_config):
+"""Set up a file system to be used in UEFI "eficonfig" command
+   tests
+
+Args:
+u_boot_config -- U-boot configuration.
+
+Return:
+A path to disk image to be used for testing
+"""
+mnt_point = u_boot_config.persistent_data_dir + '/test_efi_eficonfig'
+image_path = u_boot_config.persistent_data_dir + '/efi_eficonfig.img'
+
+shutil.rmtree(mnt_point, ignore_errors=True)
+os.mkdir(mnt_point, mode = 0o755)
+
+with open(mnt_point + '/initrd-1.img', 'w', encoding = 'ascii') as file:
+file.write("initrd 1")
+
+with open(mnt_point + '/initrd-2.img', 'w', encoding = 'ascii') as file:
+file.write("initrd 2")
+
+shutil.copyfile(u_boot_config.build_dir + '/lib/efi_loader/initrddump.efi',
+mnt_point + '/initrddump.efi')
+
+check_call(f'virt-make-fs --partition=gpt --size=+1M --type=vfat 
{mnt_point} {image_path}',
+   shell=True)
+
+return image_path
diff --git a/test/py/tests/test_eficonfig/test_eficonfig.py 
b/test/py/tests/test_eficonfig/test_eficonfig.py
new file mode 100644
index 00..c1fe07eb8b
--- /dev/null
+++ b/test/py/tests/test_eficonfig/test_eficonfig.py
@@ -0,0 +1,354 @@
+# SPDX-License-Identifier:  GPL-2.0+
+""" Unit test for UEFI menu-driven configuration
+"""
+
+import pytest
+import time
+
+@pytest.mark.boardspec('sandbox')
+@pytest.mark.buildconfigspec('cmd_eficonfig')
+@pytest.mark.buildconfigspec('cmd_bootefi_bootmgr')
+def test_efi_eficonfig(u_boot_console, efi_eficonfig_data):
+
+def send_user_input_and_wait(user_str, expect_str):
+time.sleep(0.1) # TODO: does not work correctly without sleep
+u_boot_console.run_command(cmd=user_str, wait_for_prompt=False,
+   wait_for_echo=True, send_nl=False)
+u_boot_console.run_command(cmd='\x0d', wait_for_prompt=False,
+   wait_for_echo=False, send_nl=False)
+if expect_str is not None:
+for i in expect_str:
+u_boot_console.p.expect([i])
+
+def press_up_down_enter_and_wait(up_count, down_count, enter, expect_str):
+# press UP key
+for i in range(up_count):
+u_boot_console.run_command(cmd='\x1b\x5b\x41', 
wait_for_prompt=False,
+   wait_for_echo=False, send_nl=False)
+# press DOWN key
+for i in range(down_count):
+u_boot_console.run_command(cmd='\x1b\x5b\x42', 
wait_for_prompt=False,
+   wait_for_echo=False, send_nl=False)
+# press ENTER if requested
+if enter:
+u_boot_console.run_command(cmd='\x0d', wait_for_prompt=False,
+   wait_for_echo=False, send_nl=False)
+# wait expected output
+if expect_str is not None:
+for i in expect_str:
+u_boot_console.p.expect([i])
+
+def press_escape_key(wait_prompt):
+u_boot_console.run_command(cmd='\x1b', wait_for_prompt=wait_prompt, 
wait_for_echo=False, send_nl=False)
+
+def 

Re: RISCV: the machanism of available_harts may cause other harts boot failure

[Sean Anderson]

On 9/5/22 11:41 AM, Heinrich Schuchardt wrote:

On 9/5/22 17:30, Sean Anderson wrote:

On 9/5/22 3:47 AM, Nikita Shubin wrote:

Hi Rick!

On Mon, 5 Sep 2022 14:22:41 +0800
Rick Chen  wrote:


Hi,

When I free-run a SMP system, I once hit a failure case where some
harts didn't boot to the kernel shell successfully.
However it can't be duplicated anymore even if I try many times.

But when I set a break during debugging with GDB, it can trigger the
failure case each time.


If hart fails to register itself to available_harts before
send_ipi_many is hit by the main hart:
https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/riscv/lib/smp.c#L50

it won't exit the secondary_hart_loop:
https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/riscv/cpu/start.S#L433
As no ipi will be sent to it.


Can we call send_ipi_many() again when booting?


AFAIK we do; see arch/riscv/lib/bootm.c and arch/riscv/lib/spl.c


Do we need to call it before booting?


Yes. We also call it when relocating (in SPL and U-Boot proper).



This might be exactly your case.


When working on the IPI mechanism, I considered this possibility. However,
there's really no way to know how long to wait. On normal systems, the boot
hart is going to do a lot of work before calling send_ipi_many, and the
other harts just have to make it through ~100 instructions. So I figured we
would never run into this issue.

We might not even need the mask... the only direct reason we might is for
OpenSBI, as spl_invoke_opensbi is the only function which uses the wait
parameter.


I think the mechanism of available_harts does not provide a method
that guarantees the success of the SMP system.
Maybe we shall think of a better way for the SMP booting or just
remove it ?


I haven't experienced any unexplained problem with hart_lottery or
available_harts_lock unless:

1) harts are started non-simultaneously
2) SPL/U-Boot is in some kind of TCM, OCRAM, etc... which is not cleared
on reset which leaves available_harts dirty


XIP, of course, has this problem every time and just doesn't use the mask.
I remember thinking a lot about how to deal with this, but I never ended
up sending a patch because I didn't have a XIP system.

--Sean


3) something is wrong with atomics

Also there might be something wrong with IPI send/recieve.



Thread 8 hit Breakpoint 1, harts_early_init ()

(gdb) c
Continuing.
[Switching to Thread 7]

Thread 7 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 6]

Thread 6 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 5]

Thread 5 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 4]

Thread 4 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 3]

Thread 3 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 2]

Thread 2 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 1]

Thread 1 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 5]


Thread 5 hit Breakpoint 3, 0x0120 in ?? ()
(gdb) info threads
   Id   Target Id Frame
   1    Thread 1 (hart 1) secondary_hart_loop () at
arch/riscv/cpu/start.S:436 2    Thread 2 (hart 2) secondary_hart_loop
() at arch/riscv/cpu/start.S:436 3    Thread 3 (hart 3)
secondary_hart_loop () at arch/riscv/cpu/start.S:436 4    Thread 4
(hart 4) secondary_hart_loop () at arch/riscv/cpu/start.S:436
* 5    Thread 5 (hart 5) 0x0120 in ?? ()
   6    Thread 6 (hart 6) 0xb650 in ?? ()
   7    Thread 7 (hart 7) 0xb650 in ?? ()
   8    Thread 8 (hart 8) 0x5fa0 in ?? ()
(gdb) c
Continuing.


Do they all "offline" harts remain in SPL/U-Boot secondary_hart_loop ?





[    0.175619] smp: Bringing up secondary CPUs ...
[    1.230474] CPU1: failed to come online
[    2.282349] CPU2: failed to come online
[    3.334394] CPU3: failed to come online
[    4.386783] CPU4: failed to come online
[    4.427829] smp: Brought up 1 node, 4 CPUs


/root # cat /proc/cpuinfo
processor   : 0
hart    : 4
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu : sv39

processor   : 5
hart    : 5
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu : sv39

processor   : 6
hart    : 6
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu : sv39

processor   : 7
hart    : 7
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu : sv39

/root #

Thanks,
Rick

Re: RISCV: the machanism of available_harts may cause other harts boot failure

[Heinrich Schuchardt]

On 9/5/22 17:30, Sean Anderson wrote:

On 9/5/22 3:47 AM, Nikita Shubin wrote:

Hi Rick!

On Mon, 5 Sep 2022 14:22:41 +0800
Rick Chen  wrote:


Hi,

When I free-run a SMP system, I once hit a failure case where some
harts didn't boot to the kernel shell successfully.
However it can't be duplicated anymore even if I try many times.

But when I set a break during debugging with GDB, it can trigger the
failure case each time.


If hart fails to register itself to available_harts before
send_ipi_many is hit by the main hart:
https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/riscv/lib/smp.c#L50

it won't exit the secondary_hart_loop:
https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/riscv/cpu/start.S#L433
As no ipi will be sent to it.


Can we call send_ipi_many() again when booting?
Do we need to call it before booting?

Best regards

Heinrich



This might be exactly your case.


When working on the IPI mechanism, I considered this possibility. However,
there's really no way to know how long to wait. On normal systems, the boot
hart is going to do a lot of work before calling send_ipi_many, and the
other harts just have to make it through ~100 instructions. So I figured we
would never run into this issue.

We might not even need the mask... the only direct reason we might is for
OpenSBI, as spl_invoke_opensbi is the only function which uses the wait
parameter.


I think the mechanism of available_harts does not provide a method
that guarantees the success of the SMP system.
Maybe we shall think of a better way for the SMP booting or just
remove it ?


I haven't experienced any unexplained problem with hart_lottery or
available_harts_lock unless:

1) harts are started non-simultaneously
2) SPL/U-Boot is in some kind of TCM, OCRAM, etc... which is not cleared
on reset which leaves available_harts dirty


XIP, of course, has this problem every time and just doesn't use the mask.
I remember thinking a lot about how to deal with this, but I never ended
up sending a patch because I didn't have a XIP system.

--Sean


3) something is wrong with atomics

Also there might be something wrong with IPI send/recieve.



Thread 8 hit Breakpoint 1, harts_early_init ()

(gdb) c
Continuing.
[Switching to Thread 7]

Thread 7 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 6]

Thread 6 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 5]

Thread 5 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 4]

Thread 4 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 3]

Thread 3 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 2]

Thread 2 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 1]

Thread 1 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 5]


Thread 5 hit Breakpoint 3, 0x0120 in ?? ()
(gdb) info threads
   Id   Target Id Frame
   1    Thread 1 (hart 1) secondary_hart_loop () at
arch/riscv/cpu/start.S:436 2    Thread 2 (hart 2) secondary_hart_loop
() at arch/riscv/cpu/start.S:436 3    Thread 3 (hart 3)
secondary_hart_loop () at arch/riscv/cpu/start.S:436 4    Thread 4
(hart 4) secondary_hart_loop () at arch/riscv/cpu/start.S:436
* 5    Thread 5 (hart 5) 0x0120 in ?? ()
   6    Thread 6 (hart 6) 0xb650 in ?? ()
   7    Thread 7 (hart 7) 0xb650 in ?? ()
   8    Thread 8 (hart 8) 0x5fa0 in ?? ()
(gdb) c
Continuing.


Do they all "offline" harts remain in SPL/U-Boot secondary_hart_loop ?





[    0.175619] smp: Bringing up secondary CPUs ...
[    1.230474] CPU1: failed to come online
[    2.282349] CPU2: failed to come online
[    3.334394] CPU3: failed to come online
[    4.386783] CPU4: failed to come online
[    4.427829] smp: Brought up 1 node, 4 CPUs


/root # cat /proc/cpuinfo
processor   : 0
hart    : 4
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu : sv39

processor   : 5
hart    : 5
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu : sv39

processor   : 6
hart    : 6
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu : sv39

processor   : 7
hart    : 7
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu : sv39

/root #

Thanks,
Rick

Re: RISCV: the machanism of available_harts may cause other harts boot failure

[Sean Anderson]

On 9/5/22 3:47 AM, Nikita Shubin wrote:

Hi Rick!

On Mon, 5 Sep 2022 14:22:41 +0800
Rick Chen  wrote:


Hi,

When I free-run a SMP system, I once hit a failure case where some
harts didn't boot to the kernel shell successfully.
However it can't be duplicated anymore even if I try many times.

But when I set a break during debugging with GDB, it can trigger the
failure case each time.


If hart fails to register itself to available_harts before
send_ipi_many is hit by the main hart:
https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/riscv/lib/smp.c#L50

it won't exit the secondary_hart_loop:
https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/riscv/cpu/start.S#L433
As no ipi will be sent to it.

This might be exactly your case.


When working on the IPI mechanism, I considered this possibility. However,
there's really no way to know how long to wait. On normal systems, the boot
hart is going to do a lot of work before calling send_ipi_many, and the
other harts just have to make it through ~100 instructions. So I figured we
would never run into this issue.

We might not even need the mask... the only direct reason we might is for
OpenSBI, as spl_invoke_opensbi is the only function which uses the wait
parameter.


I think the mechanism of available_harts does not provide a method
that guarantees the success of the SMP system.
Maybe we shall think of a better way for the SMP booting or just
remove it ?


I haven't experienced any unexplained problem with hart_lottery or
available_harts_lock unless:

1) harts are started non-simultaneously
2) SPL/U-Boot is in some kind of TCM, OCRAM, etc... which is not cleared
on reset which leaves available_harts dirty


XIP, of course, has this problem every time and just doesn't use the mask.
I remember thinking a lot about how to deal with this, but I never ended
up sending a patch because I didn't have a XIP system.

--Sean


3) something is wrong with atomics

Also there might be something wrong with IPI send/recieve.



Thread 8 hit Breakpoint 1, harts_early_init ()

(gdb) c
Continuing.
[Switching to Thread 7]

Thread 7 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 6]

Thread 6 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 5]

Thread 5 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 4]

Thread 4 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 3]

Thread 3 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 2]

Thread 2 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 1]

Thread 1 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 5]


Thread 5 hit Breakpoint 3, 0x0120 in ?? ()
(gdb) info threads
   Id   Target Id Frame
   1Thread 1 (hart 1) secondary_hart_loop () at
arch/riscv/cpu/start.S:436 2Thread 2 (hart 2) secondary_hart_loop
() at arch/riscv/cpu/start.S:436 3Thread 3 (hart 3)
secondary_hart_loop () at arch/riscv/cpu/start.S:436 4Thread 4
(hart 4) secondary_hart_loop () at arch/riscv/cpu/start.S:436
* 5Thread 5 (hart 5) 0x0120 in ?? ()
   6Thread 6 (hart 6) 0xb650 in ?? ()
   7Thread 7 (hart 7) 0xb650 in ?? ()
   8Thread 8 (hart 8) 0x5fa0 in ?? ()
(gdb) c
Continuing.


Do they all "offline" harts remain in SPL/U-Boot secondary_hart_loop ?





[0.175619] smp: Bringing up secondary CPUs ...
[1.230474] CPU1: failed to come online
[2.282349] CPU2: failed to come online
[3.334394] CPU3: failed to come online
[4.386783] CPU4: failed to come online
[4.427829] smp: Brought up 1 node, 4 CPUs


/root # cat /proc/cpuinfo
processor   : 0
hart: 4
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu : sv39

processor   : 5
hart: 5
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu : sv39

processor   : 6
hart: 6
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu : sv39

processor   : 7
hart: 7
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu : sv39

/root #

Thanks,
Rick

[PATCH 1/1] RISC-V: enable CONFIG_SYSRESET_SBI by default

[Heinrich Schuchardt]

System reset via the SRST extension in the SBI should be the default.
The driver checks if the extension is available when probing.
So there is no risk in enabling it.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/sysreset/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index a0acffa4b0..03f7fdd597 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -113,6 +113,7 @@ config SYSRESET_PSCI
 config SYSRESET_SBI
bool "Enable support for SBI System Reset"
depends on RISCV_SMODE && SBI_V02
+   default y
select SYSRESET_CMD_POWEROFF if CMD_POWEROFF
help
  Enable system reset and poweroff via the SBI system reset extension.
-- 
2.37.2

RE: [PATCH v1 0/2] serial_mxc: fixing reception

[ZHIZHIKIN Andrey]

Hello Fabio,

> -Original Message-
> From: U-Boot  On Behalf Of Fabio Estevam
> Sent: Monday, September 5, 2022 1:20 PM
> To: ZHIZHIKIN Andrey 
> Cc: Pali Rohár ; u-boot@lists.denx.de; trini
> ; Peng Fan (OSS) ; Fabio Estevam
> ; Stefano Babic 
> Subject: Re: [PATCH v1 0/2] serial_mxc: fixing reception
> 
> Hi Andrey,
> 
> On Mon, Sep 5, 2022 at 6:21 AM ZHIZHIKIN Andrey
>  wrote:
> 
> > I cannot modify this part since removing you from maintainer list would
> > require a transfer of maintainership of this component to another name,
> > which I do not know.
> >
> > I've Cc:'d Tom and people from imx world here so they can make a decision
> > on who shall continue the maintenance of this file when your entry is 
> > removed.
> 
> I have added the imx serial driver to the "ARM FREESCALE IMX" list:
> https://lore.kernel.org/u-boot/20220905105700.3209658-1-feste...@gmail.com/T/#u

I've seen your patch on the ML already, thanks a lot for taking care of this!

Regards,
Andrey

[PATCH] mtd: nand: denali: Add SPL image loader

[Jit Loon Lim]

From: Tien Fong Chee 

Add image loader used by the NAND SPL into the full Denali NAND
driver. This allows usage of the full Denali NAND driver in SPL instead
of the reduced SPL-only version.

Signed-off-by: Tien Fong Chee 
Signed-off-by: Jit Loon Lim 
---
 drivers/mtd/nand/raw/denali.c | 55 +++
 1 file changed, 55 insertions(+)

diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index c827f80281..499b4acc6e 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -7,7 +7,9 @@
 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1374,3 +1376,56 @@ free_buf:
 
return ret;
 }
+
+#ifdef CONFIG_SPL_BUILD
+int nand_spl_load_image(u32 offset, u32 len, void *dst)
+{
+   size_t count = len, actual = 0, page_align_overhead = 0;
+   u32 page_align_offset = 0;
+   u8 *page_buffer;
+   int err = 0;
+   struct mtd_info *mtd;
+
+   if (!len || !dst)
+   return -EINVAL;
+
+   mtd = get_nand_dev_by_index(nand_curr_device);
+   if (!mtd)
+   hang();
+
+   if ((offset & (mtd->writesize - 1)) != 0) {
+   page_buffer = malloc_cache_aligned(mtd->writesize);
+   if (!page_buffer) {
+   debug("Error: allocating buffer\n");
+   return -ENOMEM;
+   }
+
+   page_align_overhead = offset % mtd->writesize;
+   page_align_offset = (offset / mtd->writesize) * mtd->writesize;
+   count = mtd->writesize;
+
+   err = nand_read_skip_bad(mtd, page_align_offset, ,
+, mtd->size, page_buffer);
+
+   if (err)
+   return err;
+
+   count -= page_align_overhead;
+   count = min((size_t)len, count);
+   memcpy(dst, page_buffer + page_align_overhead, count);
+   free(page_buffer);
+
+   len -= count;
+   if (!len)
+   return err;
+
+   offset += count;
+   dst += count;
+   count = len;
+   }
+
+   return nand_read_skip_bad(mtd, offset, , , mtd->size, dst);
+}
+
+void nand_deselect(void) {}
+#endif
-- 
2.26.2

[PATCH] mtd: nand: Allow full NAND framework in SPL

[Jit Loon Lim]

From: Tien Fong Chee 

Add configuration option to compile the entire NAND framework into
U-Boot SPL. This is required by some drivers, like the Denali NAND,
which use a lot of functionality from the NAND core.

Signed-off-by: Marek Vasut 
Signed-off-by: Tien Fong Chee 
Signed-off-by: Jit Loon Lim 
---
 drivers/mtd/nand/raw/Kconfig  |  7 +++
 drivers/mtd/nand/raw/Makefile | 16 +---
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index ce67d1abde..a3bd45f24e 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -694,4 +694,11 @@ config SPL_NAND_SIMPLE
  expose the cmd_ctrl() interface.
 endif
 
+config SPL_NAND_FRAMEWORK
+   bool "Compile the entire NAND framework into the SPL"
+   help
+ Some drivers require a lot of functionality from the NAND framework
+ core when used in SPL. This option allows compiling the full NAND
+ framework into the SPL instead of it's reduced version.
+
 endif   # if NAND
diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index a398aa9d88..e0f7045fec 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -3,8 +3,16 @@
 # (C) Copyright 2006
 # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
 
+nand-framework-objs := nand.o nand_bbt.o nand_ids.o nand_util.o \
+   nand_ecc.o nand_base.o nand_timings.o
+
 ifdef CONFIG_SPL_BUILD
 
+ifdef CONFIG_SPL_NAND_FRAMEWORK
+obj-y += $(nand-framework-objs)
+NORMAL_DRIVERS=y
+endif
+
 ifdef CONFIG_SPL_NAND_DRIVERS
 NORMAL_DRIVERS=y
 endif
@@ -27,19 +35,13 @@ else # not spl
 
 NORMAL_DRIVERS=y
 
-obj-y += nand.o
-obj-y += nand_bbt.o
-obj-y += nand_ids.o
-obj-y += nand_util.o
-obj-y += nand_ecc.o
-obj-y += nand_base.o
 obj-y += nand_amd.o
 obj-y += nand_hynix.o
 obj-y += nand_macronix.o
 obj-y += nand_micron.o
 obj-y += nand_samsung.o
 obj-y += nand_toshiba.o
-obj-y += nand_timings.o
+obj-y += $(nand-framework-objs)
 
 endif # not spl
 
-- 
2.26.2

Re: [PATCH 1/2] rpi: Copy properties from firmware dtb to the loaded dtb

[Peter Robinson]

On Wed, Aug 10, 2022 at 1:58 PM Antoine Mazeas  wrote:
>
> The RPI firmware adjusts several property values in the dtb it passes
> to u-boot depending on the board/SoC revision. Inherit some of these
> when u-boot loads a dtb itself. Specificaly copy:
>
> * /model: The firmware provides a more specific string
> * /memreserve: The firmware defines a reserved range, better keep it

Is this the CMA range or a different one? If so this makes sense.

> * emmc2bus and pcie0 dma-ranges: The C0T revision of the bcm2711 Soc (as
>   present on rpi 400 and some rpi 4B boards) has different values for
>   these then the B0T revision. So these need to be adjusted to boot on
>   these boards
> * blconfig: The firmware defines the memory area where the blconfig
>   stored. Copy those over so it can be enabled.
> * /chosen/kaslr-seed: The firmware generates a kaslr seed, take advantage
>   of that.

U-Boot has a rpi4 iproc_rng200 driver for this and provides it via the
UEFI random seed as well, if you're booting using UEFI that takes
precedence so providing this might not be useful but also it doesn't
matter much.

> Signed-off-by: Sjoerd Simons 

Reviewed-by: Peter Robinson 
Tested-by: Peter Robinson 

Tested on RPi400 and it solves the issues with the kernel DT I've seen
plus some RPi4s although no the rev 1.3+ devices that also have the
newer SoC rev that's the same in the rpi400

> ---
>  board/raspberrypi/rpi/rpi.c | 48 +
>  1 file changed, 48 insertions(+)
>
> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> index 17b8108cc8..28b6f52506 100644
> --- a/board/raspberrypi/rpi/rpi.c
> +++ b/board/raspberrypi/rpi/rpi.c
> @@ -504,10 +504,58 @@ void *board_fdt_blob_setup(int *err)
> return (void *)fw_dtb_pointer;
>  }
>
> +int copy_property(void *dst, void *src, char *path, char *property)
> +{
> +   int dst_offset, src_offset;
> +   const fdt32_t *prop;
> +   int len;
> +
> +   src_offset = fdt_path_offset(src, path);
> +   dst_offset = fdt_path_offset(dst, path);
> +
> +   if (src_offset < 0 || dst_offset < 0)
> +   return -1;
> +
> +   prop = fdt_getprop(src, src_offset, property, );
> +   if (!prop)
> +   return -1;
> +
> +   return fdt_setprop(dst, dst_offset, property, prop, len);
> +}
> +
> +/* Copy tweaks from the firmware dtb to the loaded dtb */
> +void  update_fdt_from_fw(void *fdt, void *fw_fdt)
> +{
> +   /* Using dtb from firmware directly; leave it alone */
> +   if (fdt == fw_fdt)
> +   return;
> +
> +   /* The firmware provides a more precie model; so copy that */
> +   copy_property(fdt, fw_fdt, "/", "model");
> +
> +   /* memory reserve as suggested by the firmware */
> +   copy_property(fdt, fw_fdt, "/", "memreserve");
> +
> +   /* Adjust dma-ranges for the SD card and PCI bus as they can depend on
> +* the SoC revision
> +*/
> +   copy_property(fdt, fw_fdt, "emmc2bus", "dma-ranges");
> +   copy_property(fdt, fw_fdt, "pcie0", "dma-ranges");
> +
> +   /* Bootloader configuration template exposes as nvmem */
> +   if (copy_property(fdt, fw_fdt, "blconfig", "reg") == 0)
> +   copy_property(fdt, fw_fdt, "blconfig", "status");
> +
> +   /* kernel address randomisation seed as provided by the firmware */
> +   copy_property(fdt, fw_fdt, "/chosen", "kaslr-seed");
> +}
> +
>  int ft_board_setup(void *blob, struct bd_info *bd)
>  {
> int node;
>
> +   update_fdt_from_fw(blob, (void *)fw_dtb_pointer);
> +
> node = fdt_node_offset_by_compatible(blob, -1, "simple-framebuffer");
> if (node < 0)
> fdt_simplefb_add_node(blob);
> --
> 2.37.1
>

Re: [PATCH 2/2] rpi: Copy eth PHY address from fw DT to loaded DT

[Peter Robinson]

On Wed, Aug 10, 2022 at 1:58 PM Antoine Mazeas  wrote:
>
> Some Raspberry Pi 400 boards, specifically rev 1.1, have a different address 
> for the ethernet PHY device than what is provided by the kernel DTB. The 
> correct address is provided by the firmware, so we should carry it over into 
> the loaded device tree so that ethernet works on such boards.

Minor nit: this should be properly wrapped.

> Signed-off-by: Antoine Mazeas 

Reviewed-by: Peter Robinson 
Tested-by: Peter Robinson 

Tested on the RPi400 and a couple of different RPi4s

> ---
>  board/raspberrypi/rpi/rpi.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> index 28b6f52506..793fd1aa30 100644
> --- a/board/raspberrypi/rpi/rpi.c
> +++ b/board/raspberrypi/rpi/rpi.c
> @@ -548,6 +548,9 @@ void  update_fdt_from_fw(void *fdt, void *fw_fdt)
>
> /* kernel address randomisation seed as provided by the firmware */
> copy_property(fdt, fw_fdt, "/chosen", "kaslr-seed");
> +
> +   /* address of the PHY device as provided by the firmware  */
> +   copy_property(fdt, fw_fdt, "ethernet0/mdio@e14/ethernet-phy@1", 
> "reg");
>  }
>
>  int ft_board_setup(void *blob, struct bd_info *bd)
> --
> 2.37.1
>

Re: [PATCH] fdt_support: add optional board_rng_seed() hook

[Rasmus Villemoes]

On 02/09/2022 21.59, Simon Glass wrote:
> Hi Rasmus,
> 
> On Fri, 2 Sept 2022 at 01:00, Rasmus Villemoes
>  wrote:
>>
>>> What shall we do with this patch? Apply it?
>>
>> Well, that's probably not for me to decide (I guess Tom is), but I'd
>> still like it applied. It's simple, and works now, and it can always be
>> removed again if there's a demonstrated viable alternative.
> 
> OK I'll apply it for this release and we'll see how much progress is
> made with ofnode in the next one.

Thanks.

> Are you OK with reworking it to use events when possible?
> 

Yes, if it turns out to be a mostly drop-in replacement I'm fine with
this board_rng_seed hook vanishing again.

Rasmus

[PATCH] arm: Enable cache-pl310 driver build for both SPL and proper U-Boot

[Jit Loon Lim]

From: Tien Fong Chee 

Moved CONFIG_SYS_L2_PL310 to the location where the build on the
cache-pl310 can be taken in both SPL and proper U-Boot. This driver is
required for SoCFPGA when temporarily turning on the cache for better
performance in initializing whole DDR to zero.

Signed-off-by: Tien Fong Chee 
Signed-off-by: Jit Loon Lim 
---
 arch/arm/lib/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index c603fe61bc..575042e6df 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -43,6 +43,7 @@ ifdef CONFIG_ARM64
 obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMSET) += memset-arm64.o
 obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMCPY) += memcpy-arm64.o
 else
+obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
 obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMSET) += memset.o
 obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMCPY) += memcpy.o
 endif
-- 
2.26.2

[PATCH v16 10/10] test: unit test for eficonfig

[Masahisa Kojima]

Provide a unit test for the eficonfig command.

Signed-off-by: Masahisa Kojima 
Acked-by: Ilias Apalodimas 
---
Changes in v16:
- call u_boot_console.restart_uboot() to clean the previous test state

Changes in v14:
- update to support media device enumeration in eficonfig startup
- move no block device test to the last test case

Changes in v12:
- update menu handling

Changes in v11:
- fix expected result when no BootOrder is defined

Newly added in v10

 configs/sandbox_defconfig |   1 +
 test/py/tests/test_eficonfig/conftest.py  |  40 ++
 .../py/tests/test_eficonfig/test_eficonfig.py | 354 ++
 3 files changed, 395 insertions(+)
 create mode 100644 test/py/tests/test_eficonfig/conftest.py
 create mode 100644 test/py/tests/test_eficonfig/test_eficonfig.py

diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index eba7bcbb48..48c60c606d 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -93,6 +93,7 @@ CONFIG_CMD_LINK_LOCAL=y
 CONFIG_CMD_ETHSW=y
 CONFIG_CMD_BMP=y
 CONFIG_CMD_BOOTCOUNT=y
+CONFIG_CMD_EFICONFIG=y
 CONFIG_CMD_EFIDEBUG=y
 CONFIG_CMD_RTC=y
 CONFIG_CMD_TIME=y
diff --git a/test/py/tests/test_eficonfig/conftest.py 
b/test/py/tests/test_eficonfig/conftest.py
new file mode 100644
index 00..f289df0362
--- /dev/null
+++ b/test/py/tests/test_eficonfig/conftest.py
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier:  GPL-2.0+
+
+"""Fixture for UEFI eficonfig test
+"""
+
+import os
+import shutil
+from subprocess import check_call
+import pytest
+
+@pytest.fixture(scope='session')
+def efi_eficonfig_data(u_boot_config):
+"""Set up a file system to be used in UEFI "eficonfig" command
+   tests
+
+Args:
+u_boot_config -- U-boot configuration.
+
+Return:
+A path to disk image to be used for testing
+"""
+mnt_point = u_boot_config.persistent_data_dir + '/test_efi_eficonfig'
+image_path = u_boot_config.persistent_data_dir + '/efi_eficonfig.img'
+
+shutil.rmtree(mnt_point, ignore_errors=True)
+os.mkdir(mnt_point, mode = 0o755)
+
+with open(mnt_point + '/initrd-1.img', 'w', encoding = 'ascii') as file:
+file.write("initrd 1")
+
+with open(mnt_point + '/initrd-2.img', 'w', encoding = 'ascii') as file:
+file.write("initrd 2")
+
+shutil.copyfile(u_boot_config.build_dir + '/lib/efi_loader/initrddump.efi',
+mnt_point + '/initrddump.efi')
+
+check_call(f'virt-make-fs --partition=gpt --size=+1M --type=vfat 
{mnt_point} {image_path}',
+   shell=True)
+
+return image_path
diff --git a/test/py/tests/test_eficonfig/test_eficonfig.py 
b/test/py/tests/test_eficonfig/test_eficonfig.py
new file mode 100644
index 00..c1fe07eb8b
--- /dev/null
+++ b/test/py/tests/test_eficonfig/test_eficonfig.py
@@ -0,0 +1,354 @@
+# SPDX-License-Identifier:  GPL-2.0+
+""" Unit test for UEFI menu-driven configuration
+"""
+
+import pytest
+import time
+
+@pytest.mark.boardspec('sandbox')
+@pytest.mark.buildconfigspec('cmd_eficonfig')
+@pytest.mark.buildconfigspec('cmd_bootefi_bootmgr')
+def test_efi_eficonfig(u_boot_console, efi_eficonfig_data):
+
+def send_user_input_and_wait(user_str, expect_str):
+time.sleep(0.1) # TODO: does not work correctly without sleep
+u_boot_console.run_command(cmd=user_str, wait_for_prompt=False,
+   wait_for_echo=True, send_nl=False)
+u_boot_console.run_command(cmd='\x0d', wait_for_prompt=False,
+   wait_for_echo=False, send_nl=False)
+if expect_str is not None:
+for i in expect_str:
+u_boot_console.p.expect([i])
+
+def press_up_down_enter_and_wait(up_count, down_count, enter, expect_str):
+# press UP key
+for i in range(up_count):
+u_boot_console.run_command(cmd='\x1b\x5b\x41', 
wait_for_prompt=False,
+   wait_for_echo=False, send_nl=False)
+# press DOWN key
+for i in range(down_count):
+u_boot_console.run_command(cmd='\x1b\x5b\x42', 
wait_for_prompt=False,
+   wait_for_echo=False, send_nl=False)
+# press ENTER if requested
+if enter:
+u_boot_console.run_command(cmd='\x0d', wait_for_prompt=False,
+   wait_for_echo=False, send_nl=False)
+# wait expected output
+if expect_str is not None:
+for i in expect_str:
+u_boot_console.p.expect([i])
+
+def press_escape_key(wait_prompt):
+u_boot_console.run_command(cmd='\x1b', wait_for_prompt=wait_prompt, 
wait_for_echo=False, send_nl=False)
+
+def press_enter_key(wait_prompt):
+u_boot_console.run_command(cmd='\x0d', wait_for_prompt=wait_prompt,
+   wait_for_echo=False, send_nl=False)
+
+def check_current_is_maintenance_menu():
+for i in 

[PATCH v16 09/10] doc:eficonfig: add documentation for eficonfig command

[Masahisa Kojima]

Add documentation for eficonfig command.

Signed-off-by: Masahisa Kojima 
Reviewed-by: Ilias Apalodimas 
---
No update since v15

Changes in v14:
- fix typos

Changes in v13:
- describe how to auto boot according to the UEFI Boot option

Changes in v12:
- CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE condition is added
  to show newly added boot option

No update since v10

Changes in v10:
- describe how to boot system after editting by eficonfig

Changes in v8:
- command name is changed from "efimenu" to "eficonfig"

Newly created in v7

 doc/usage/cmd/eficonfig.rst | 71 +
 doc/usage/index.rst |  1 +
 2 files changed, 72 insertions(+)
 create mode 100644 doc/usage/cmd/eficonfig.rst

diff --git a/doc/usage/cmd/eficonfig.rst b/doc/usage/cmd/eficonfig.rst
new file mode 100644
index 00..340ebc80db
--- /dev/null
+++ b/doc/usage/cmd/eficonfig.rst
@@ -0,0 +1,71 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. (C) Copyright 2022, Masahisa Kojima 
+
+eficonfig command
+=
+
+Synopsis
+
+::
+
+eficonfig
+
+Description
+---
+
+The "eficonfig" command uses U-Boot menu interface and provides
+a menu-driven UEFI variable maintenance feature.
+The "eficonfig" has the following menu entries.
+
+Add Boot Option
+Add new UEFI Boot Option.
+User can edit description, file path, and optional_data.
+
+Edit Boot Option
+Edit the existing UEFI Boot Option
+User can edit description, file path, and optional_data.
+
+Change Boot Order
+Change the order of UEFI BootOrder variable.
+
+Delete Boot Option
+Delete the UEFI Boot Option
+
+Configuration
+-
+
+The "eficonfig" command is enabled by::
+
+CONFIG_CMD_EFICONFIG=y
+
+If CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE is enabled, user can not enter
+U-Boot console. In this case, bootmenu can be used to invoke "eficonfig"::
+
+CONFIG_USE_PREBOOT=y
+CONFIG_PREBOOT="setenv bootmenu_0 UEFI Maintenance Menu=eficonfig"
+
+How to boot the system with newly added UEFI Boot Option
+
+
+"eficonfig" command is responsible for configuring the UEFI variables,
+not directly handle the system boot.
+The new Boot Option added by "eficonfig" is appended at the last entry
+of UEFI BootOrder variable, user may want to change the boot order
+through "Change Boot Order".
+If the bootmenu is enabled, CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE is enabled,
+and "eficonfig" is configured as preboot command, the newly added Boot Options
+are enumerated in the bootmenu when user exits from the eficonfig menu.
+User may select the entry in the bootmenu to boot the system, or follow
+the U-Boot configuration the system already has.
+
+Auto boot with the UEFI Boot Option
+'''
+
+To do auto boot according to the UEFI BootOrder variable,
+add "bootefi bootmgr" entry as a default or first bootmenu entry::
+
+CONFIG_PREBOOT="setenv bootmenu_0 UEFI Boot Manager=bootefi bootmgr; 
setenv bootmenu_1 UEFI Maintenance Menu=eficonfig"
+
+See also
+
+* :doc:`bootmenu` provides a simple mechanism for creating menus 
with different boot items
diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index 28f9683a3e..09f2928970 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -35,6 +35,7 @@ Shell commands
cmd/conitrace
cmd/dm
cmd/echo
+   cmd/eficonfig
cmd/env
cmd/event
cmd/exception
-- 
2.17.1

[PATCH v16 08/10] doc:bootmenu: add description for UEFI boot support

[Masahisa Kojima]

The bootmenu enumerates the UEFI boot options
for boot device selection.
This commit adds the description how the UEFI boot work
in bootmenu. This commit also adds "Synopsis", "Description"
and "Configuration" sections to follow the U-Boot command
documentation format.

Signed-off-by: Masahisa Kojima 
Reviewed-by: Ilias Apalodimas 
---
No update since v10

Changes in v10:
- fix typos

Changes in v7:
- update the description what bootmenu do for uefi-related boot menu
- add default behavior when user exits from bootmenu

Changes in v6:
- remove distro boot related contents because the distro boot
support in bootmenu is dropped
- update uefi entry example
- add [delay] argument of bootmenu command
- add description to enable uefi boot entry

Changes in v5:
- follow the cmd documentation format same as other command, add "Synopsis",
  "Description" add "Configuration" sections

Newly created in v4

 doc/usage/cmd/bootmenu.rst | 74 ++
 1 file changed, 74 insertions(+)

diff --git a/doc/usage/cmd/bootmenu.rst b/doc/usage/cmd/bootmenu.rst
index 9430f8c9aa..cb3c8d2f93 100644
--- a/doc/usage/cmd/bootmenu.rst
+++ b/doc/usage/cmd/bootmenu.rst
@@ -4,6 +4,15 @@
 bootmenu command
 
 
+Synopsis
+
+::
+
+bootmenu [delay]
+
+Description
+---
+
 The "bootmenu" command uses U-Boot menu interfaces and provides
 a simple mechanism for creating menus with different boot items.
 The cursor keys "Up" and "Down" are used for navigation through
@@ -79,6 +88,55 @@ The above example will be rendered as below::
 The selected menu entry will be highlighted - it will have inverted
 background and text colors.
 
+UEFI boot variable enumeration
+''
+If enabled, the bootmenu command will automatically generate and add
+UEFI-related boot menu entries for the following items.
+
+ * possible bootable media with default file names
+ * user-defined UEFI boot options
+
+The bootmenu automatically enumerates the possible bootable
+media devices supporting EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.
+This auto generated entry is named as " :" format.
+(e.g. "usb 0:1")
+
+The bootmenu displays the UEFI-related menu entries in order of "BootOrder".
+When the user selects the UEFI boot menu entry, the bootmenu sets
+the selected boot variable index to "BootNext" without non-volatile attribute,
+then call the uefi boot manager with the command "bootefi bootmgr".
+
+Example bootmenu is as below::
+
+*** U-Boot Boot Menu ***
+
+   mmc 0:1
+   mmc 0:2
+   debian
+   nvme 0:1
+   ubuntu
+   nvme 0:2
+   usb 0:2
+   U-Boot console
+
+Default behavior when user exits from the bootmenu
+~~
+User can exit from bootmenu by selecting the last entry
+"U-Boot console"/"Quit" or ESC/CTRL+C key.
+
+When the CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE is disabled,
+user exits from the bootmenu and returns to the U-Boot console.
+
+When the CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE is enabled, user can not
+enter the U-Boot console. When the user exits from the bootmenu,
+the bootmenu invokes the following default behavior.
+
+ * if CONFIG_CMD_BOOTEFI_BOOTMGR is enabled, execute "bootefi bootmgr" command
+ * "bootefi bootmgr" fails or is not enabled, then execute "run bootcmd" 
command.
+
+Configuration
+-
+
 The "bootmenu" command is enabled by::
 
 CONFIG_CMD_BOOTMENU=y
@@ -88,3 +146,19 @@ To run the bootmenu at startup add these additional 
settings::
 CONFIG_AUTOBOOT_KEYED=y
 CONFIG_BOOTDELAY=30
 CONFIG_AUTOBOOT_MENU_SHOW=y
+
+UEFI boot variable enumeration is enabled by::
+
+CONFIG_CMD_BOOTEFI_BOOTMGR=y
+
+To improve the product security, entering U-Boot console from bootmenu
+can be disabled by::
+
+CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE=y
+
+To scan the discoverable devices connected to the buses such as
+USB and PCIe prior to bootmenu showing up, CONFIG_PREBOOT can be
+used to run the command before showing the bootmenu, i.e.::
+
+CONFIG_USE_PREBOOT=y
+CONFIG_PREBOOT="pci enum; usb start; scsi scan; nvme scan; virtio scan"
-- 
2.17.1

[PATCH v16 07/10] eficonfig: add "Change Boot Order" menu entry

[Masahisa Kojima]

This commit adds the menu entry to update UEFI BootOrder variable.
User moves the entry with UP/DOWN key, changes the order
with PLUS/MINUS key, press SPACE to activate or deactivate
the entry, then finalizes the order by ENTER key.
If the entry is activated, the boot index is added into the
BootOrder variable in the order of the list.

The U-Boot menu framework is well designed for static menu,
this commit implements the own menu display and key handling
for dynamically change the order of menu entry.

Signed-off-by: Masahisa Kojima 
---
No update since v15

Changes in v14:
- remove scan of media device, it is moved into eficonfig startup
- add comment in default case for key handling
- add missing break in eficonfig_choice_entry

Changes in v12:
- enumerate removable media device

Changes in v11:
- remove BootOrder variable dependency
- use ANSI_CURSOR_POSITION and ANSI_CLEAR_LINE instead of printf("\n")
  since current eficonfig implementation does not handle console size correctly.
  printf("\n") at the outside of console size breaks the console output.
- add KEY_SPACE to toggle the boot option active status

No update since v9

Changes in v9:
- add function comment

Changes in v8:
- add "Save" and "Quit" entries

Changes in v7:
- use UP/DOWN and PLUS/MINUS key to change to order

no update in v6:

 cmd/eficonfig.c | 348 +++-
 1 file changed, 347 insertions(+), 1 deletion(-)

diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
index 285d2a11ec..5cfab6a46c 100644
--- a/cmd/eficonfig.c
+++ b/cmd/eficonfig.c
@@ -91,6 +91,23 @@ struct eficonfig_boot_selection_data {
int *selected;
 };
 
+/**
+ * struct eficonfig_boot_order - structure to be used to update BootOrder 
variable
+ *
+ * @num:   index in the menu entry
+ * @description:   pointer to the description string
+ * @boot_index:boot option index
+ * @active:flag to include the boot option into BootOrder variable
+ * @list:  list structure
+ */
+struct eficonfig_boot_order {
+   u32 num;
+   u16 *description;
+   u32 boot_index;
+   bool active;
+   struct list_head list;
+};
+
 /**
  * eficonfig_print_msg() - print message
  *
@@ -1744,6 +1761,335 @@ out:
return ret;
 }
 
+/**
+ * eficonfig_display_change_boot_order() - display the BootOrder list
+ *
+ * @efi_menu:  pointer to the efimenu structure
+ * Return: status code
+ */
+static void eficonfig_display_change_boot_order(struct efimenu *efi_menu)
+{
+   bool reverse;
+   struct list_head *pos, *n;
+   struct eficonfig_boot_order *entry;
+
+   printf(ANSI_CLEAR_CONSOLE ANSI_CURSOR_POSITION
+  "\n  ** Change Boot Order **\n"
+  ANSI_CURSOR_POSITION
+  "  Press UP/DOWN to move, +/- to change order"
+  ANSI_CURSOR_POSITION
+  "  Press SPACE to activate or deactivate the entry"
+  ANSI_CURSOR_POSITION
+  "  Select [Save] to complete, ESC/CTRL+C to quit"
+  ANSI_CURSOR_POSITION ANSI_CLEAR_LINE,
+  1, 1, efi_menu->count + 5, 1, efi_menu->count + 6, 1,
+  efi_menu->count + 7, 1,  efi_menu->count + 8, 1);
+
+   /* draw boot option list */
+   list_for_each_safe(pos, n, _menu->list) {
+   entry = list_entry(pos, struct eficonfig_boot_order, list);
+   reverse = (entry->num == efi_menu->active);
+
+   printf(ANSI_CURSOR_POSITION, entry->num + 4, 7);
+
+   if (reverse)
+   puts(ANSI_COLOR_REVERSE);
+
+   if (entry->num < efi_menu->count - 2) {
+   if (entry->active)
+   printf("[*]  ");
+   else
+   printf("[ ]  ");
+   }
+
+   printf("%ls", entry->description);
+
+   if (reverse)
+   puts(ANSI_COLOR_RESET);
+   }
+}
+
+/**
+ * eficonfig_choice_change_boot_order() - handle the BootOrder update
+ *
+ * @efi_menu:  pointer to the efimenu structure
+ * Return: status code
+ */
+static efi_status_t eficonfig_choice_change_boot_order(struct efimenu 
*efi_menu)
+{
+   int esc = 0;
+   struct list_head *pos, *n;
+   struct eficonfig_boot_order *tmp;
+   enum bootmenu_key key = KEY_NONE;
+   struct eficonfig_boot_order *entry;
+
+   while (1) {
+   bootmenu_loop(NULL, , );
+
+   switch (key) {
+   case KEY_PLUS:
+   if (efi_menu->active > 0) {
+   list_for_each_safe(pos, n, _menu->list) {
+   entry = list_entry(pos, struct 
eficonfig_boot_order, list);
+   if (entry->num == efi_menu->active)
+   break;
+   }
+   tmp = 

[PATCH v16 05/10] bootmenu: add removable media entries

[Masahisa Kojima]

UEFI specification requires booting from removal media using
a architecture-specific default image name such as BOOTAA64.EFI.
This commit adds the removable media entries into bootmenu,
so that user can select the removable media and boot with
default image.

The bootmenu automatically enumerates the possible bootable
media devices supporting EFI_SIMPLE_FILE_SYSTEM_PROTOCOL,
add it as new UEFI boot option(BOOT) and update BootOrder
variable. This automatically generated UEFI boot option
has the dedicated guid in the optional_data to distinguish it from
the UEFI boot option user adds manually. This optional_data is
removed when the efi bootmgr loads the selected UEFI boot option.

This commit also provides the BOOT variable maintenance feature.
Depending on the system hardware setup, some devices
may not exist at a later system boot, so bootmenu checks the
available device in each bootmenu invocation and automatically
removes the BOOT variable corrensponding to the non-existent
media device.

Signed-off-by: Masahisa Kojima 
---
No update since v14

Changes in v14:
- remove invalid free() call

Changes in v13:
- remove BootOrder variable dependency

Changes in v12:
- move generate_media_device_boot_option into cmd/eficonfig.c and expose it
- remove unnecessary include file

Changes in v11:
- update delete_boot_option() parameter

Changes in v10:
- add function comment
- devname dynamic allocation removes, allocate in stack
- delete BOOT when updating BootOrder fails

Changes in v9:
- update efi_disk_get_device_name() parameter to pass efi_handle_t
- add function comment

Changes in v8:
- function and structure prefix is changed to "eficonfig"

Changes in v7:
- rename prepare_media_device_entry() to generate_media_device_boot_option()

Changes in v6:
- optional_data size is changed to 16bytes
- check the load option size before comparison
- remove guid included in optional_data of auto generated
  entry when loading

Changes in v5:
- Return EFI_SUCCESS if there is no BootOrder defined
- correctly handle the case if no removable device found
- use guid to identify the automatically generated entry by bootmenu

 cmd/bootmenu.c   |  22 +++-
 cmd/eficonfig.c  | 208 +++
 include/efi_config.h |   1 +
 include/efi_loader.h |  16 +++
 lib/efi_loader/efi_bootmgr.c |   4 +
 5 files changed, 245 insertions(+), 6 deletions(-)

diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
index 704d36debe..3340be1632 100644
--- a/cmd/bootmenu.c
+++ b/cmd/bootmenu.c
@@ -7,7 +7,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -220,7 +220,7 @@ static int prepare_bootmenu_entry(struct bootmenu_data 
*menu,
return 1;
 }
 
-#if (CONFIG_IS_ENABLED(CMD_BOOTEFI_BOOTMGR))
+#if (CONFIG_IS_ENABLED(CMD_BOOTEFI_BOOTMGR)) && 
(CONFIG_IS_ENABLED(CMD_EFICONFIG))
 /**
  * prepare_uefi_bootorder_entry() - generate the uefi bootmenu entries
  *
@@ -340,11 +340,21 @@ static struct bootmenu_data *bootmenu_create(int delay)
if (ret < 0)
goto cleanup;
 
-#if (CONFIG_IS_ENABLED(CMD_BOOTEFI_BOOTMGR))
+#if (CONFIG_IS_ENABLED(CMD_BOOTEFI_BOOTMGR)) && 
(CONFIG_IS_ENABLED(CMD_EFICONFIG))
if (i < MAX_COUNT - 1) {
-   ret = prepare_uefi_bootorder_entry(menu, , );
-   if (ret < 0 && ret != -ENOENT)
-   goto cleanup;
+   efi_status_t efi_ret;
+
+   /*
+* UEFI specification requires booting from removal media using
+* a architecture-specific default image name such as 
BOOTAA64.EFI.
+*/
+   efi_ret = eficonfig_generate_media_device_boot_option();
+   if (efi_ret != EFI_SUCCESS && efi_ret != EFI_NOT_FOUND)
+   goto cleanup;
+
+   ret = prepare_uefi_bootorder_entry(menu, , );
+   if (ret < 0 && ret != -ENOENT)
+   goto cleanup;
}
 #endif
 
diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
index f4d9652628..edb42d2742 100644
--- a/cmd/eficonfig.c
+++ b/cmd/eficonfig.c
@@ -1814,6 +1814,214 @@ static efi_status_t 
eficonfig_process_delete_boot_option(void *data)
return ret;
 }
 
+/**
+ * eficonfig_enumerate_boot_option() - enumerate the possible bootable media
+ *
+ * @opt:   pointer to the media boot option structure
+ * @volume_handles:pointer to the efi handles
+ * @count: number of efi handle
+ * Return: status code
+ */
+efi_status_t eficonfig_enumerate_boot_option(struct 
eficonfig_media_boot_option *opt,
+efi_handle_t *volume_handles, 
efi_status_t count)
+{
+   u32 i;
+   struct efi_handler *handler;
+   efi_status_t ret = EFI_SUCCESS;
+
+   for (i = 0; i < count; i++) {
+   u16 *p;
+   u16 dev_name[BOOTMENU_DEVICE_NAME_MAX];
+ 

[PATCH v16 06/10] eficonfig: scan media device in eficonfig startup

[Masahisa Kojima]

In eficonfig startup, scan media devices and update
the UEFI boot option.

Signed-off-by: Masahisa Kojima 
---
No update since v14

Newly created in v14

 cmd/eficonfig.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
index edb42d2742..285d2a11ec 100644
--- a/cmd/eficonfig.c
+++ b/cmd/eficonfig.c
@@ -2085,6 +2085,10 @@ static int do_eficonfig(struct cmd_tbl *cmdtp, int flag, 
int argc, char *const a
if (ret != EFI_SUCCESS)
return CMD_RET_FAILURE;
 
+   ret = eficonfig_generate_media_device_boot_option();
+   if (ret != EFI_SUCCESS && ret != EFI_NOT_FOUND)
+   return ret;
+
while (1) {
efi_menu = eficonfig_create_fixed_menu(maintenance_menu_items,
   
ARRAY_SIZE(maintenance_menu_items));
-- 
2.17.1

[PATCH v16 01/10] eficonfig: menu-driven addition of UEFI boot option

[Masahisa Kojima]

This commit add the "eficonfig" command.
The "eficonfig" command implements the menu-driven UEFI boot option
maintenance feature. This commit implements the addition of
new boot option. User can select the block device volume having
efi_simple_file_system_protocol and select the file corresponding
to the Boot variable. User can also enter the description and
optional_data of the BOOT variable in utf8.

This commit adds "include/efi_config.h", it contains the common
definition to be used from other menus such as UEFI Secure Boot
key management.

Signed-off-by: Masahisa Kojima 
---
Changes in v16:
- fix error handling in eficonfig_process_common()

Changes in v15:
- moves the free(entry->data) outside the eficonfig_destroy() function and
  entry->data is freed explicitly only when needed
- expose eficonfig_destroy() for succeeding secure boot key management patch

Changes in v14:
- fix the missing initialization
- add comment for key handling

No change in v13:

Changes in v12:
- add select/clear menu before displaying volume selectio
- move function declaration from efi_loader.h to efi_config.h
- remove unused declaration
- support the boot option does not have file path
- correctly handle if optional_data is empty

Changes in v11:
- refactor menu entry construction, directly use eficonfig_entry structure
- remove reading directory info to calculate the number of entry
- fix invalid efi_free_pool() in ill_file_info()
- use ANSI_CURSOR_POSITION and ANSI_CLEAR_LINE instead of printf("\n")
  since current eficonfig implementation does not handle console size correctly.
  printf("\n") at the outside of console size breaks the console output.

Changes in v10:
- add initrd file selection
- do refactoring
- eficonfig_process_common() use list structure
- remove u'/' before copying file_path into current_path
- fix typos
- check snprintf error

Changes in v9:
- move "efi_guid_bootmenu_auto_generated definition" into efi_bootmgr.c
  to address build error when CMD_EFICONFIG is disabled
- fix typos and comment
- remove file system information from error message
- remove unreachable code in eficonfig_choice_entry()
- single printf() call as much as possible
- call only getchar() in  eficonfig_print_msg()
- filter out '.' entry from file selection
- update the efi_disk_get_device_name() implementation
- add function comment

Changes in v8:
- command name is change from "efimenu" to "eficonfig"
- function and struct prefixes is changed to "eficonfig"
- fix menu header string

Changes in v7:
- add "efimenu" command and uefi variable maintenance code
  moved into cmd/efimenu.c
- create include/efimenu.h to define the common definition for
  the other menu such as UEFI Secure Boot key management
- update boot option edit UI, user can select description, file,
  and optional_data to edit in the same menu like following.

  ** Edit Boot Option **

 Description: debian
 File: virtio 0:1/EFI\debian\grubaa64.efi
 Optional Data: test
 Save
 Quit

- remove exit parameter from efimenu_process_common()
- menu title type is changed from u16 to char
- efimenu_process_common() add menu title string
- reduce printf/puts function call for displaying the menu
- efi_console_get_u16_string() accept 0 length to allow
  optional_data is empty
- efi_console_get_u16_string() the "size" parameter name is changes to "count"
- efimenu is now designed to maintain the UEFI variables, remove autoboot 
related code
- remove one empty line before "Quit" entry
- efimenu_init() processes only the first time

Changes in v6:
- fix typos
- modify volume name to match U-Boot syntax
- compile in CONFIG_EFI_LOADER=n and CONFIG_CMD_BOOTEFI_BOOTMGR=n
- simplify u16_strncmp() usage
- support "a\b.efi" file path, use link list to handle filepath
- modify length check condition
- UEFI related menu items only appears with CONFIG_AUTOBOOT_MENU_SHOW=y

Changes in v5:
- remove forward declarations
- add const qualifier for menu items
- fix the possible unaligned access for directory info access
- split into three commit 1)add boot option 2) delete boot option 3)change boot 
order
  This commit is 1)add boot option.
- fix file name buffer allocation size, it should be EFI_BOOTMENU_FILE_PATH_MAX 
* sizeof(u16)
- fix wrong size checking for file selection

Chanes in v4:
- UEFI boot option maintenance menu is integrated into bootmenu
- display the simplified volume name(e.g. usb0:1, nvme1:2) for the
  volume selection
- instead of extending lib/efi_loader/efi_bootmgr.c, newly create
  lib/efi_loader/efi_bootmenu_maintenance.c and implement boot
  variable maintenance into it.

Changes in RFC v3:
 not included in v3 series

Changes in RFC v2:
- enable utf8 user input for boot option name
- create lib/efi_loader/efi_console.c::efi_console_get_u16_string() for
  utf8 user input handling
- use u16_strlcat instead of u16_strcat
- remove the EFI_CALLs, and newly create or expose the following
  xxx_int() functions.

[PATCH v16 03/10] menu: add KEY_PLUS, KEY_MINUS and KEY_SPACE handling

[Masahisa Kojima]

This is preparation to support menu-driven UEFI BootOrder
variable updated by KEY_PLUS, KEY_MINUS and KEY_SPACE.

Signed-off-by: Masahisa Kojima 
Reviewed-by: Heinrich Schuchardt 
Reviewed-by: Ilias Apalodimas 
---
No update since v11

Changes in v11:
- add SPACE key handling

Newly created in v7

 common/menu.c  | 9 +
 include/menu.h | 3 +++
 2 files changed, 12 insertions(+)

diff --git a/common/menu.c b/common/menu.c
index 3e876b55b3..0d19601cf5 100644
--- a/common/menu.c
+++ b/common/menu.c
@@ -548,4 +548,13 @@ void bootmenu_loop(struct bootmenu_data *menu,
/* ^C was pressed */
if (c == 0x3)
*key = KEY_QUIT;
+
+   if (c == '+')
+   *key = KEY_PLUS;
+
+   if (c == '-')
+   *key = KEY_MINUS;
+
+   if (c == ' ')
+   *key = KEY_SPACE;
 }
diff --git a/include/menu.h b/include/menu.h
index e74616cae8..702aacb170 100644
--- a/include/menu.h
+++ b/include/menu.h
@@ -48,6 +48,9 @@ enum bootmenu_key {
KEY_DOWN,
KEY_SELECT,
KEY_QUIT,
+   KEY_PLUS,
+   KEY_MINUS,
+   KEY_SPACE,
 };
 
 void bootmenu_autoboot_loop(struct bootmenu_data *menu,
-- 
2.17.1

[PATCH v16 04/10] eficonfig: add "Delete Boot Option" menu entry

[Masahisa Kojima]

This commit adds the menu entry to delete the UEFI boot option.
User moves the entry with UP/DOWN key, changes, then presses
ENTER key to delete the selected boot option.

Signed-off-by: Masahisa Kojima 
---
No update since v11

Changes in v11:
- update function interface to show boot selection menu
- support to delete the load option is not included in BootOrder

No update since v9

Changes in v9:
- add function comment

Changes in v8:
- function and structure prefix is changed to "eficonfig"

Changes in v7:
- to stay the boot order list after user delete the entry

no update in v6:

changes in v5:

 cmd/eficonfig.c | 71 +
 1 file changed, 71 insertions(+)

diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
index 1f1846de9a..f4d9652628 100644
--- a/cmd/eficonfig.c
+++ b/cmd/eficonfig.c
@@ -1744,6 +1744,76 @@ out:
return ret;
 }
 
+/**
+ * delete_boot_option() - delete selected boot option
+ *
+ * @boot_index:boot option index to delete
+ * Return: status code
+ */
+static efi_status_t delete_boot_option(u16 boot_index)
+{
+   u16 *bootorder;
+   u16 varname[9];
+   efi_status_t ret;
+   unsigned int index;
+   efi_uintn_t num, size;
+
+   efi_create_indexed_name(varname, sizeof(varname),
+   "Boot", boot_index);
+   ret = efi_set_variable_int(varname, _global_variable_guid,
+  0, 0, NULL, false);
+   if (ret != EFI_SUCCESS) {
+   log_err("delete boot option(%ls) failed\n", varname);
+   return ret;
+   }
+
+   /* update BootOrder if necessary */
+   bootorder = efi_get_var(u"BootOrder", _global_variable_guid, );
+   if (!bootorder)
+   return EFI_SUCCESS;
+
+   num = size / sizeof(u16);
+   if (!search_bootorder(bootorder, num, boot_index, ))
+   return EFI_SUCCESS;
+
+   memmove([index], [index + 1],
+   (num - index - 1) * sizeof(u16));
+   size -= sizeof(u16);
+   ret = efi_set_variable_int(u"BootOrder", _global_variable_guid,
+  EFI_VARIABLE_NON_VOLATILE |
+  EFI_VARIABLE_BOOTSERVICE_ACCESS |
+  EFI_VARIABLE_RUNTIME_ACCESS,
+  size, bootorder, false);
+
+   return ret;
+}
+
+/**
+ * eficonfig_process_delete_boot_option() - handler to delete boot option
+ *
+ * @data:  pointer to the data for each entry
+ * Return: status code
+ */
+static efi_status_t eficonfig_process_delete_boot_option(void *data)
+{
+   efi_status_t ret;
+   unsigned int selected;
+
+   while (1) {
+   ret = eficonfig_show_boot_selection();
+   if (ret == EFI_SUCCESS)
+   ret = delete_boot_option(selected);
+
+   if (ret != EFI_SUCCESS)
+   break;
+   }
+
+   /* to stay the parent menu */
+   ret = (ret == EFI_ABORTED) ? EFI_NOT_READY : ret;
+
+   return ret;
+}
+
 /**
  * eficonfig_init() - do required initialization for eficonfig command
  *
@@ -1774,6 +1844,7 @@ static efi_status_t eficonfig_init(void)
 static const struct eficonfig_item maintenance_menu_items[] = {
{"Add Boot Option", eficonfig_process_add_boot_option},
{"Edit Boot Option", eficonfig_process_edit_boot_option},
+   {"Delete Boot Option", eficonfig_process_delete_boot_option},
{"Quit", eficonfig_process_quit},
 };
 
-- 
2.17.1

[PATCH v16 02/10] eficonfig: add "Edit Boot Option" menu entry

[Masahisa Kojima]

This commit adds the menu entry to edit the existing
BOOT variable contents.
User selects the item from the boot option list, then
user can edit the description, file path and optional_data.

Note that automatically generated boot option entry by bootmenu
to support the removable media device is filtered out and user
can not edit the automatically generated entry.

Signed-off-by: Masahisa Kojima 
---
No update since v16

Changes in v15:
- move free entry->data outside the eficonfig_destroy()

Changes in v11:
- remove BootOrder variable dependency
- change the list load option order
   1) in the order of BootOrder
   2) remaing load option that is not included in the BootOrder
- add check for the number of menu entry exceeds max
- truncate the long load option label when user edits
- add EFICONFIG_VOLUME_PATH_MAX to display text converted volume
  device path in case the volume does not exist

Changes in v10:
- update eficonfig_edit_boot_option() argument

Changes in v9:
- add function comment

Changes in v8:
- fix menu header string
- fix function and structure prefix to "eficonfig"

Newly created in v7

 cmd/eficonfig.c  | 281 +--
 include/efi_config.h |   1 +
 2 files changed, 274 insertions(+), 8 deletions(-)

diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
index d94f54b8a0..1f1846de9a 100644
--- a/cmd/eficonfig.c
+++ b/cmd/eficonfig.c
@@ -80,6 +80,17 @@ struct eficonfig_file_entry_data {
u16 *file_name;
 };
 
+/**
+ * struct eficonfig_boot_selection_data - structure to be used to select the 
boot option entry
+ *
+ * @boot_index:index of the boot option
+ * @selected:  pointer to store the selected index in the BootOrder 
variable
+ */
+struct eficonfig_boot_selection_data {
+   u16 boot_index;
+   int *selected;
+};
+
 /**
  * eficonfig_print_msg() - print message
  *
@@ -1165,34 +1176,58 @@ static efi_status_t prepare_file_selection_entry(struct 
efimenu *efi_menu, char
 {
u32 len;
efi_status_t ret;
-   u16 *file_name, *p;
+   u16 *file_name = NULL, *p;
efi_handle_t handle;
-   char devname[BOOTMENU_DEVICE_NAME_MAX] = {0};
+   char *devname;
+
+   devname = calloc(1, EFICONFIG_VOLUME_PATH_MAX + 1);
+   if (!devname)
+   return EFI_OUT_OF_RESOURCES;
 
/* get the device name only when the user already selected the file 
path */
handle = efi_dp_find_obj(file_info->dp_volume, NULL, NULL);
if (handle) {
-   ret = efi_disk_get_device_name(handle, devname, 
BOOTMENU_DEVICE_NAME_MAX);
+   ret = efi_disk_get_device_name(handle, devname, 
EFICONFIG_VOLUME_PATH_MAX);
if (ret != EFI_SUCCESS)
-   return ret;
+   goto out;
+   }
+
+   /*
+* If the preconfigured volume does not exist in the system, display 
the text
+* converted volume device path instead of U-Boot friendly name(e.g. 
"usb 0:1").
+*/
+   if (!handle && file_info->dp_volume) {
+   u16 *dp_str;
+   char *q = devname;
+
+   dp_str = efi_dp_str(file_info->dp_volume);
+   if (dp_str)
+   utf16_utf8_strncpy(, dp_str, 
EFICONFIG_VOLUME_PATH_MAX);
+
+   efi_free_pool(dp_str);
}
 
/* append u'/' to devname, it is just for display purpose. */
if (file_info->current_path[0] != u'\0' && file_info->current_path[0] 
!= u'/')
-   strlcat(devname, "/", BOOTMENU_DEVICE_NAME_MAX);
+   strlcat(devname, "/", EFICONFIG_VOLUME_PATH_MAX + 1);
 
len = strlen(devname);
len += utf16_utf8_strlen(file_info->current_path) + 1;
file_name = calloc(1, len * sizeof(u16));
-   if (!file_name)
-   return ret;
+   if (!file_name) {
+   ret = EFI_OUT_OF_RESOURCES;
+   goto out;
+   }
 
p = file_name;
utf8_utf16_strcpy(, devname);
u16_strlcat(file_name, file_info->current_path, len);
ret = create_boot_option_entry(efi_menu, title, file_name,
   eficonfig_select_file_handler, 
file_info);
+out:
+   free(devname);
free(file_name);
+
return ret;
 }
 
@@ -1359,10 +1394,14 @@ static efi_status_t eficonfig_edit_boot_option(u16 
*varname, struct eficonfig_bo
if (ret != EFI_SUCCESS)
goto out;
 
-   if (!lo.label || (lo.label && u16_strlen(lo.label) >= 
EFICONFIG_DESCRIPTION_MAX)) {
+   if (!lo.label) {
ret = EFI_INVALID_PARAMETER;
goto out;
}
+   /* truncate the long label string */
+   if (u16_strlen(lo.label) >= EFICONFIG_DESCRIPTION_MAX)
+   lo.label[EFICONFIG_DESCRIPTION_MAX - 1] = u'\0';
+
u16_strcpy(bo->description, lo.label);
 

[PATCH v16 00/10] enable menu-driven UEFI variable maintenance

[Masahisa Kojima]

This series adds the menu-driven UEFI boot variable maintenance
through the "eficonfig" new command.
This series also adds the removable media support in bootmenu.

Source code can be cloned with:
$ git clone https://git.linaro.org/people/masahisa.kojima/u-boot.git -b 
kojima/eficonfig_upstream_v16

[Major Changes]
- there is detailed changelog in each commit

Masahisa Kojima (10):
  eficonfig: menu-driven addition of UEFI boot option
  eficonfig: add "Edit Boot Option" menu entry
  menu: add KEY_PLUS, KEY_MINUS and KEY_SPACE handling
  eficonfig: add "Delete Boot Option" menu entry
  bootmenu: add removable media entries
  eficonfig: scan media device in eficonfig startup
  eficonfig: add "Change Boot Order" menu entry
  doc:bootmenu: add description for UEFI boot support
  doc:eficonfig: add documentation for eficonfig command
  test: unit test for eficonfig

 cmd/Kconfig   |7 +
 cmd/Makefile  |1 +
 cmd/bootmenu.c|   22 +-
 cmd/eficonfig.c   | 2458 +
 common/menu.c |9 +
 configs/sandbox_defconfig |1 +
 doc/usage/cmd/bootmenu.rst|   74 +
 doc/usage/cmd/eficonfig.rst   |   71 +
 doc/usage/index.rst   |1 +
 include/efi_config.h  |   98 +
 include/efi_loader.h  |   53 +
 include/menu.h|3 +
 lib/efi_loader/efi_bootmgr.c  |7 +
 lib/efi_loader/efi_boottime.c |   52 +-
 lib/efi_loader/efi_console.c  |   70 +
 lib/efi_loader/efi_disk.c |   50 +
 lib/efi_loader/efi_file.c |   75 +-
 test/py/tests/test_eficonfig/conftest.py  |   40 +
 .../py/tests/test_eficonfig/test_eficonfig.py |  354 +++
 19 files changed, 3393 insertions(+), 53 deletions(-)
 create mode 100644 cmd/eficonfig.c
 create mode 100644 doc/usage/cmd/eficonfig.rst
 create mode 100644 include/efi_config.h
 create mode 100644 test/py/tests/test_eficonfig/conftest.py
 create mode 100644 test/py/tests/test_eficonfig/test_eficonfig.py

-- 
2.17.1

Re: [PATCH v15 10/10] test: unit test for eficonfig

[Masahisa Kojima]

On Sun, 4 Sept 2022 at 18:08, Heinrich Schuchardt  wrote:
>
> On 9/2/22 16:23, Masahisa Kojima wrote:
> > Provide a unit test for the eficonfig command.
> >
> > Signed-off-by: Masahisa Kojima 
> > Acked-by: Ilias Apalodimas 
> > ---
> > No update since v15
> >
> > Changes in v14:
> > - update to support media device enumeration in eficonfig startup
> > - move no block device test to the last test case
> >
> > Changes in v12:
> > - update menu handling
> >
> > Changes in v11:
> > - fix expected result when no BootOrder is defined
> >
> > Newly added in v10
>
> Your code does not pass the test, see
> https://source.denx.de/u-boot/custodians/u-boot-efi/-/jobs/491449
>
> test/py/tests/test_eficonfig/test_eficonfig.py:103: in test_efi_eficonfig
>  check_current_is_maintenance_menu()
> test/py/tests/test_eficonfig/test_eficonfig.py:51: in
> check_current_is_maintenance_menu
>  u_boot_console.p.expect([i])
> test/py/u_boot_spawn.py:193: in expect
>  raise Timeout()
> E   u_boot_spawn.Timeout

The reason for failure is an unexpected boot option from the previous test case.
u_boot_console.restart_uboot() must be called at the beginning of
eficonfig test.

Thanks,
Masahisa Kojima

>
> Best regards
>
> Heinrich
>
> >
> >   configs/sandbox_defconfig |   1 +
> >   test/py/tests/test_eficonfig/conftest.py  |  40 ++
> >   .../py/tests/test_eficonfig/test_eficonfig.py | 350 ++
> >   3 files changed, 391 insertions(+)
> >   create mode 100644 test/py/tests/test_eficonfig/conftest.py
> >   create mode 100644 test/py/tests/test_eficonfig/test_eficonfig.py
> >
> > diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> > index eba7bcbb48..48c60c606d 100644
> > --- a/configs/sandbox_defconfig
> > +++ b/configs/sandbox_defconfig
> > @@ -93,6 +93,7 @@ CONFIG_CMD_LINK_LOCAL=y
> >   CONFIG_CMD_ETHSW=y
> >   CONFIG_CMD_BMP=y
> >   CONFIG_CMD_BOOTCOUNT=y
> > +CONFIG_CMD_EFICONFIG=y
> >   CONFIG_CMD_EFIDEBUG=y
> >   CONFIG_CMD_RTC=y
> >   CONFIG_CMD_TIME=y
> > diff --git a/test/py/tests/test_eficonfig/conftest.py 
> > b/test/py/tests/test_eficonfig/conftest.py
> > new file mode 100644
> > index 00..f289df0362
> > --- /dev/null
> > +++ b/test/py/tests/test_eficonfig/conftest.py
> > @@ -0,0 +1,40 @@
> > +# SPDX-License-Identifier:  GPL-2.0+
> > +
> > +"""Fixture for UEFI eficonfig test
> > +"""
> > +
> > +import os
> > +import shutil
> > +from subprocess import check_call
> > +import pytest
> > +
> > +@pytest.fixture(scope='session')
> > +def efi_eficonfig_data(u_boot_config):
> > +"""Set up a file system to be used in UEFI "eficonfig" command
> > +   tests
> > +
> > +Args:
> > +u_boot_config -- U-boot configuration.
> > +
> > +Return:
> > +A path to disk image to be used for testing
> > +"""
> > +mnt_point = u_boot_config.persistent_data_dir + '/test_efi_eficonfig'
> > +image_path = u_boot_config.persistent_data_dir + '/efi_eficonfig.img'
> > +
> > +shutil.rmtree(mnt_point, ignore_errors=True)
> > +os.mkdir(mnt_point, mode = 0o755)
> > +
> > +with open(mnt_point + '/initrd-1.img', 'w', encoding = 'ascii') as 
> > file:
> > +file.write("initrd 1")
> > +
> > +with open(mnt_point + '/initrd-2.img', 'w', encoding = 'ascii') as 
> > file:
> > +file.write("initrd 2")
> > +
> > +shutil.copyfile(u_boot_config.build_dir + 
> > '/lib/efi_loader/initrddump.efi',
> > +mnt_point + '/initrddump.efi')
> > +
> > +check_call(f'virt-make-fs --partition=gpt --size=+1M --type=vfat 
> > {mnt_point} {image_path}',
> > +   shell=True)
> > +
> > +return image_path
> > diff --git a/test/py/tests/test_eficonfig/test_eficonfig.py 
> > b/test/py/tests/test_eficonfig/test_eficonfig.py
> > new file mode 100644
> > index 00..1c501deb1f
> > --- /dev/null
> > +++ b/test/py/tests/test_eficonfig/test_eficonfig.py
> > @@ -0,0 +1,350 @@
> > +# SPDX-License-Identifier:  GPL-2.0+
> > +""" Unit test for UEFI menu-driven configuration
> > +"""
> > +
> > +import pytest
> > +import time
> > +
> > +@pytest.mark.boardspec('sandbox')
> > +@pytest.mark.buildconfigspec('cmd_eficonfig')
> > +@pytest.mark.buildconfigspec('cmd_bootefi_bootmgr')
> > +def test_efi_eficonfig(u_boot_console, efi_eficonfig_data):
> > +
> > +def send_user_input_and_wait(user_str, expect_str):
> > +time.sleep(0.1) # TODO: does not work correctly without sleep
> > +u_boot_console.run_command(cmd=user_str, wait_for_prompt=False,
> > +   wait_for_echo=True, send_nl=False)
> > +u_boot_console.run_command(cmd='\x0d', wait_for_prompt=False,
> > +   wait_for_echo=False, send_nl=False)
> > +if expect_str is not None:
> > +for i in expect_str:
> > +u_boot_console.p.expect([i])
> > +
> > +def press_up_down_enter_and_wait(up_count, down_count, enter, 
> > expect_str):
> > +# 

Re: [PATCH v1 0/2] serial_mxc: fixing reception

[Fabio Estevam]

Hi Andrey,

On Mon, Sep 5, 2022 at 6:21 AM ZHIZHIKIN Andrey
 wrote:

> I cannot modify this part since removing you from maintainer list would
> require a transfer of maintainership of this component to another name,
> which I do not know.
>
> I've Cc:'d Tom and people from imx world here so they can make a decision
> on who shall continue the maintenance of this file when your entry is removed.

I have added the imx serial driver to the "ARM FREESCALE IMX" list:
https://lore.kernel.org/u-boot/20220905105700.3209658-1-feste...@gmail.com/T/#u

[PATCH] MAINTAINERS: imx: Add an entry for the serial driver

[Fabio Estevam]

From: Fabio Estevam 

Currently, when running ./scripts/get_maintainer.pl on serial_mxc.c
no i.MX maintainer is returned.

Fix it by adding an entry for this driver.

Reported-by: Pali Rohár 
Signed-off-by: Fabio Estevam 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 36a2b69fcb..83346183ee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -264,6 +264,7 @@ F:  arch/arm/include/asm/arch-mx*/
 F: arch/arm/include/asm/arch-vf610/
 F: arch/arm/include/asm/mach-imx/
 F: board/freescale/*mx*/
+F: drivers/serial/serial_mxc.c
 
 ARM HISILICON
 M: Peter Griffin 
-- 
2.25.1

[PATCH v2 2/2] serial: mxc: have putc use the TXFIFO

[Johannes Schneider]

only waiting for TXEMPTY leads to corrupted messages going over the
wire - which is fixed by making use of the FIFO

Signed-off-by: Johannes Schneider 
---

(no changes since v1)

 drivers/serial/serial_mxc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index 5f283cc635..1e0add7281 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -309,7 +309,7 @@ static int mxc_serial_putc(struct udevice *dev, const char 
ch)
struct mxc_serial_plat *plat = dev_get_plat(dev);
struct mxc_uart *const uart = plat->reg;
 
-   if (!(readl(>ts) & UTS_TXEMPTY))
+   if (readl(>ts) & UTS_TXFULL)
return -EAGAIN;
 
writel(ch, >txd);
-- 
2.25.1

[PATCH v2 1/2] serial: mxc: enable the RX pipeline

[Johannes Schneider]

on imx8(mm) the RXDMUXSEL needs to be set for data going over the wire
(as observable on a connected 'scope) to actually make it into the
RXFIFO

the reference manual is not overly clear about this, and only
mentiones that "UCR3_RXDMUXSEL should always be set." - and since the
CR3 register reverts to its reset values after setting the baudrate,
setting this bit is done during '_mxc_serial_setbgr'

Signed-off-by: Johannes Schneider 

---

(no changes since v1)

 drivers/serial/serial_mxc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index 70a0e5e919..5f283cc635 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -61,6 +61,11 @@
 #define UCR3_AWAKEN(1<<4)  /* Async wake interrupt enable */
 #define UCR3_REF25 (1<<3)  /* Ref freq 25 MHz */
 #define UCR3_REF30 (1<<2)  /* Ref Freq 30 MHz */
+
+//imx8 names these bitsfields instead:
+#define UCR3_DTRDENBIT(3)  /* bit not used in this chip */
+#define UCR3_RXDMUXSEL BIT(2)  /* RXD muxed input selected; 'should always be 
set' */
+
 #define UCR3_INVT  (1<<1)  /* Inverted Infrared transmission */
 #define UCR3_BPEN  (1<<0)  /* Preset registers enable */
 #define UCR4_CTSTL_32  (32<<10) /* CTS trigger level (32 chars) */
@@ -176,6 +181,12 @@ static void _mxc_serial_setbrg(struct mxc_uart *base, 
unsigned long clk,
 
writel(UCR2_WS | UCR2_IRTS | UCR2_RXEN | UCR2_TXEN | UCR2_SRST,
   >cr2);
+
+   // setting the baudrate triggers a reset, returning cr3 to its
+   // reset value but UCR3_RXDMUXSEL "should always be set."
+   // according to the imx8 reference-manual
+   writel(readl(>cr3) | UCR3_RXDMUXSEL, >cr3);
+
writel(UCR1_UARTEN, >cr1);
 }
 
-- 
2.25.1

[PATCH v2 0/2] serial_mxc: fixing reception

[Johannes Schneider]

while writing to a imx-serial device is probably thoroughly tested - and 
obviosly works for the debug-serial - using a serial driver to read data 
received over the serial interface does not work reliably.

the patches in this series address issues found during the implementation of a 
custom uboot-command to query a coprocessor, connected to an imx8mm over uart4, 
for mainboard-identification strings

(no changes since v1)

Johannes Schneider (2):
  serial: mxc: enable the RX pipeline
  serial: mxc: have putc use the TXFIFO

 drivers/serial/serial_mxc.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

-- 
2.25.1

[PATCH v1 2/2] serial: mxc: have putc use the TXFIFO

[Johannes Schneider]

only waiting for TXEMPTY leads to corrupted messages going over the
wire - which is fixed by making use of the FIFO

Signed-off-by: Johannes Schneider 
---

 drivers/serial/serial_mxc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index 5f283cc635..1e0add7281 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -309,7 +309,7 @@ static int mxc_serial_putc(struct udevice *dev, const char 
ch)
struct mxc_serial_plat *plat = dev_get_plat(dev);
struct mxc_uart *const uart = plat->reg;
 
-   if (!(readl(>ts) & UTS_TXEMPTY))
+   if (readl(>ts) & UTS_TXFULL)
return -EAGAIN;
 
writel(ch, >txd);
-- 
2.25.1

[PATCH v1 1/2] serial: mxc: enable the RX pipeline

[Johannes Schneider]

on imx8(mm) the RXDMUXSEL needs to be set for data going over the wire
(as observable on a connected 'scope) to actually make it into the
RXFIFO

the reference manual is not overly clear about this, and only
mentiones that "UCR3_RXDMUXSEL should always be set." - and since the
CR3 register reverts to its reset values after setting the baudrate,
setting this bit is done during '_mxc_serial_setbgr'

Signed-off-by: Johannes Schneider 

---

 drivers/serial/serial_mxc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index 70a0e5e919..5f283cc635 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -61,6 +61,11 @@
 #define UCR3_AWAKEN(1<<4)  /* Async wake interrupt enable */
 #define UCR3_REF25 (1<<3)  /* Ref freq 25 MHz */
 #define UCR3_REF30 (1<<2)  /* Ref Freq 30 MHz */
+
+//imx8 names these bitsfields instead:
+#define UCR3_DTRDENBIT(3)  /* bit not used in this chip */
+#define UCR3_RXDMUXSEL BIT(2)  /* RXD muxed input selected; 'should always be 
set' */
+
 #define UCR3_INVT  (1<<1)  /* Inverted Infrared transmission */
 #define UCR3_BPEN  (1<<0)  /* Preset registers enable */
 #define UCR4_CTSTL_32  (32<<10) /* CTS trigger level (32 chars) */
@@ -176,6 +181,12 @@ static void _mxc_serial_setbrg(struct mxc_uart *base, 
unsigned long clk,
 
writel(UCR2_WS | UCR2_IRTS | UCR2_RXEN | UCR2_TXEN | UCR2_SRST,
   >cr2);
+
+   // setting the baudrate triggers a reset, returning cr3 to its
+   // reset value but UCR3_RXDMUXSEL "should always be set."
+   // according to the imx8 reference-manual
+   writel(readl(>cr3) | UCR3_RXDMUXSEL, >cr3);
+
writel(UCR1_UARTEN, >cr1);
 }
 
-- 
2.25.1

[PATCH v1 0/2] serial_mxc: fixing reception

[Johannes Schneider]

while writing to a imx-serial device is probably thoroughly tested - and 
obviosly works for the debug-serial - using a serial driver to read data 
received over the serial interface does not work reliably.

the patches in this series address issues found during the implementation of a 
custom uboot-command to query a coprocessor, connected to an imx8mm over uart4, 
for mainboard-identification strings


Johannes Schneider (2):
  serial: mxc: enable the RX pipeline
  serial: mxc: have putc use the TXFIFO

 drivers/serial/serial_mxc.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

-- 
2.25.1

Re: [PATCH 4/4] arm: dts: chameleonv3: Add 270-2 variant

[Paweł Anikiel]

On Fri, Sep 2, 2022 at 9:59 PM Simon Glass  wrote:
>
> Hi Paweł,
>
> On Fri, 2 Sept 2022 at 07:16, Paweł Anikiel  wrote:
> >
> > On Tue, Aug 30, 2022 at 5:57 PM Simon Glass  wrote:
> > >
> > > Hi Paweł,
> > >
> > > On Tue, 30 Aug 2022 at 05:51, Paweł Anikiel  wrote:
> > > >
> > > > On Tue, Aug 30, 2022 at 5:13 AM Alexandru M Stan  
> > > > wrote:
> > > > >
> > > > > Hey Simon,
> > > > >
> > > > > On Mon, Aug 29, 2022 at 7:29 PM Simon Glass  wrote:
> > > > > >
> > > > > > Hi Paweł,
> > > > > >
> > > > > > On Mon, 29 Aug 2022 at 02:23, Paweł Anikiel  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Sat, Aug 27, 2022 at 2:22 AM Simon Glass  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Paweł,
> > > > > > > >
> > > > > > > > On Fri, 26 Aug 2022 at 01:54, Paweł Anikiel  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Add devicetree for chameleonv3 with the 270-2I2-D11E variant 
> > > > > > > > > of the
> > > > > > > > > Mercury+ AA1 module
> > > > > > > > >
> > > > > > > > > Signed-off-by: Paweł Anikiel 
> > > > > > > > > ---
> > > > > > > > >  arch/arm/dts/Makefile|  1 +
> > > > > > > > >  .../socfpga_arria10_chameleonv3_270_2-u-boot.dtsi| 12 
> > > > > > > > > 
> > > > > > > > >  arch/arm/dts/socfpga_arria10_chameleonv3_270_2.dts   |  5 
> > > > > > > > > +
> > > > > > > > >  3 files changed, 18 insertions(+)
> > > > > > > > >  create mode 100644 
> > > > > > > > > arch/arm/dts/socfpga_arria10_chameleonv3_270_2-u-boot.dtsi
> > > > > > > > >  create mode 100644 
> > > > > > > > > arch/arm/dts/socfpga_arria10_chameleonv3_270_2.dts
> > > > > > > > >
> > > > > >
> > > > > >
> > > > > > > > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > > > > > > > > index 7330121dba..36d5d65595 100644
> > > > > > > > > --- a/arch/arm/dts/Makefile
> > > > > > > > > +++ b/arch/arm/dts/Makefile
> > > > > > > > > @@ -425,6 +425,7 @@ dtb-$(CONFIG_ARCH_SOCFPGA) += 
> > > > > > > > >   \
> > > > > > > > > socfpga_agilex_socdk.dtb\
> > > > > > > > > socfpga_arria5_secu1.dtb\
> > > > > > > > > socfpga_arria5_socdk.dtb\
> > > > > > > > > +   socfpga_arria10_chameleonv3_270_2.dtb   \
> > > > > > > > > socfpga_arria10_chameleonv3_270_3.dtb   \
> > > > > > > > > socfpga_arria10_chameleonv3_480_2.dtb   \
> > > > > > > > > socfpga_arria10_socdk_sdmmc.dtb \
> > > > > > > > > diff --git 
> > > > > > > > > a/arch/arm/dts/socfpga_arria10_chameleonv3_270_2-u-boot.dtsi 
> > > > > > > > > b/arch/arm/dts/socfpga_arria10_chameleonv3_270_2-u-boot.dtsi
> > > > > > > > > new file mode 100644
> > > > > > > > > index 00..05b4485cf3
> > > > > > > > > --- /dev/null
> > > > > > > > > +++ 
> > > > > > > > > b/arch/arm/dts/socfpga_arria10_chameleonv3_270_2-u-boot.dtsi
> > > > > > > > > @@ -0,0 +1,12 @@
> > > > > > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > > > > > +/*
> > > > > > > > > + * Copyright 2022 Google LLC
> > > > > > > > > + */
> > > > > > > > > +#include "socfpga_arria10_chameleonv3_480_2_handoff.h"
> > > > > > > > > +#include "socfpga_arria10-handoff.dtsi"
> > > > > > > > > +#include "socfpga_arria10_handoff_u-boot.dtsi"
> > > > > > > > > +#include "socfpga_arria10_mercury_aa1-u-boot.dtsi"
> > > > > > > > > +
> > > > > > > > > +_mgr {
> > > > > > > > > +   altr,bitstream = "fpga-270-2.itb";
> > > > > > > > > +};
> > > > > > > > > diff --git 
> > > > > > > > > a/arch/arm/dts/socfpga_arria10_chameleonv3_270_2.dts 
> > > > > > > > > b/arch/arm/dts/socfpga_arria10_chameleonv3_270_2.dts
> > > > > > > > > new file mode 100644
> > > > > > > > > index 00..5f40af6eb9
> > > > > > > > > --- /dev/null
> > > > > > > > > +++ b/arch/arm/dts/socfpga_arria10_chameleonv3_270_2.dts
> > > > > > > > > @@ -0,0 +1,5 @@
> > > > > > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > > > > > +/*
> > > > > > > > > + * Copyright 2022 Google LLC
> > > > > > > > > + */
> > > > > > > > > +#include "socfpga_arria10_chameleonv3.dts"
> > > > > > > >
> > > > > > > > Can you create a common .dtsi file instead? We should not be 
> > > > > > > > including
> > > > > > > > a .dts file into another file.
> > > > > > > >
> > > > > > > Do you mean renaming chameleonv3.dts to .dtsi? In Linux it's a 
> > > > > > > .dts,
> > > > > > > because nothing includes it (no handoff headers are needed). Is it
> > > > > > > fine to have the names differ across U-Boot and Linux?
> > > > > >
> > > > > > Ideally not, but we should not include a .dts file in another one 
> > > > > > and
> > > > > > it is probably more important to follow that rule. But why is Linux
> > > > > > not getting this variant?
> > > > > >
> > > > > > Regards,
> > > > > > Simon
> > > > >
> > > > > Linux (at least for the near future) does not care about which variant
> > > > > it is. The big differences between 270, 480, 

Re: [PATCH v3] tee: optee: rework TA bus scanning code

[Ilias Apalodimas]

Hi Etienne

On Mon, 5 Sept 2022 at 12:28, Etienne Carriere
 wrote:
>
> Hi Ilias,
>
> I commented v2 instead of you're latest post.
> Please find my few comments below.
> Addressed or not, Reviewed-by: Etienne Carriere 

Thanks,
I'll send a v4 with the changes

Cheers
/Ilias
>
>
> On Sat, 3 Sept 2022 at 09:54, Ilias Apalodimas
>  wrote:
> >
> > Late versions of OP-TEE support a pseudo bus.  TAs that behave as
> > hardware blocks (e.g TPM, RNG etc) present themselves on a bus which we can
> > scan.  Unfortunately U-Boot doesn't support that yet. It's worth noting
> > that we already have a workaround for RNG.  The details are in
> > commit 70812bb83da6 ("tee: optee: bind rng optee driver")
> >
> > So let's add a list of devices based on U-Boot Kconfig options that we will
> > scan until we properly implement the tee-bus functionality.
> >
> > While at it change the behaviour of the tee core itself wrt to device
> > binding.  If some device binding fails, print a warning instead of
> > disabling OP-TEE.
> >
> > Signed-off-by: Ilias Apalodimas 
> > Reviewed-by: Jens Wiklander 
> > ---
> > Changes since v:2
> > - Fixed typo on driver name ftpm-tee -> ftpm_tee
> >
> > Changes since v1:
> > - remove a macro and use ARRAY_SIZE directly
> > - print a warning instead of disabling op-tee if a driver binding fails
> >  drivers/tee/optee/core.c | 23 +++
> >  1 file changed, 19 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> > index a89d62aaf0b3..1437ba1b676b 100644
> > --- a/drivers/tee/optee/core.c
> > +++ b/drivers/tee/optee/core.c
> > @@ -31,6 +31,18 @@ struct optee_pdata {
> > optee_invoke_fn *invoke_fn;
> >  };
> >
> > +static const struct {
> > +   const char *drv_name;
> > +   const char *dev_name;
> > +} optee_bus_probe[] = {
> > +#ifdef CONFIG_RNG_OPTEE
> > +   { "optee-rng", "optee-rng" },
>
> Prefer
>   { .drv_name = "optee-rng", .dev_name = "optee-rng" },
>
> > +#endif
> > +#ifdef CONFIG_TPM2_FTPM_TEE
> > +   { "ftpm_tee", "ftpm_tee" },
> > +#endif
> > +};
> > +
> >  struct rpc_param {
> > u32 a0;
> > u32 a1;
> > @@ -643,7 +655,7 @@ static int optee_probe(struct udevice *dev)
> > struct optee_pdata *pdata = dev_get_plat(dev);
> > u32 sec_caps;
> > struct udevice *child;
> > -   int ret;
> > +   int ret, i;
> >
> > if (!is_optee_api(pdata->invoke_fn)) {
> > dev_err(dev, "OP-TEE api uid mismatch\n");
> > @@ -672,10 +684,13 @@ static int optee_probe(struct udevice *dev)
> >  * in U-Boot, the discovery of TA on the TEE bus is not supported:
> >  * only bind the drivers associated to the supported OP-TEE TA
> >  */
> > -   if (IS_ENABLED(CONFIG_RNG_OPTEE)) {
> > -   ret = device_bind_driver(dev, "optee-rng", "optee-rng", 
> > );
> > +
> > +   for (i = 0; i < ARRAY_SIZE(optee_bus_probe); i++) {
> > +   ret = device_bind_driver(dev, optee_bus_probe[i].drv_name,
> > +optee_bus_probe[i].dev_name, 
> > );
>
> Could s//NULL/.
>
> Br,
> etienne
>
> > if (ret)
> > -   return ret;
> > +   dev_warn(dev, "Failed to bind device %s\n",
> > +optee_bus_probe[i].dev_name);
> > }
> >
> > return 0;
> > --
> > 2.34.1
> >

[PATCH v3 3/6] serial: Implement flush callback

[Pali Rohár]

UART drivers have putc/puts functions which just put characters into HW
transmit queue and do not wait until all data are transmitted.

Implement flush callback via serial driver's pending(false) callback which
waits until HW transmit all characters from the queue.

Signed-off-by: Pali Rohár 
---
 drivers/serial/serial-uclass.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index 30650e37b0d7..be6502f3d24c 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -238,6 +238,18 @@ static void _serial_puts(struct udevice *dev, const char 
*str)
} while (*str);
 }
 
+#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
+static void _serial_flush(struct udevice *dev)
+{
+   struct dm_serial_ops *ops = serial_get_ops(dev);
+
+   if (!ops->pending)
+   return;
+   while (ops->pending(dev, false) > 0)
+   ;
+}
+#endif
+
 static int __serial_getc(struct udevice *dev)
 {
struct dm_serial_ops *ops = serial_get_ops(dev);
@@ -398,6 +410,13 @@ static void serial_stub_puts(struct stdio_dev *sdev, const 
char *str)
_serial_puts(sdev->priv, str);
 }
 
+#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
+static void serial_stub_flush(struct stdio_dev *sdev)
+{
+   _serial_flush(sdev->priv);
+}
+#endif
+
 static int serial_stub_getc(struct stdio_dev *sdev)
 {
return _serial_getc(sdev->priv);
@@ -520,6 +539,7 @@ static int serial_post_probe(struct udevice *dev)
sdev.priv = dev;
sdev.putc = serial_stub_putc;
sdev.puts = serial_stub_puts;
+   STDIO_DEV_ASSIGN_FLUSH(, serial_stub_flush);
sdev.getc = serial_stub_getc;
sdev.tstc = serial_stub_tstc;
 
-- 
2.20.1

[PATCH v3 6/6] boot: Call flush() before booting

[Pali Rohár]

In a lot of cases kernel resets UART HW. To ensure that U-Boot messages
printed before booting the kernel are not lost, call new U-Boot console
flush() function.

Signed-off-by: Pali Rohár 
---
Changes in v3:
* Fix commit message
---
 boot/bootm_os.c | 1 +
 cmd/boot.c  | 1 +
 cmd/elf.c   | 2 ++
 3 files changed, 4 insertions(+)

diff --git a/boot/bootm_os.c b/boot/bootm_os.c
index f31820cd07ef..079224ce585b 100644
--- a/boot/bootm_os.c
+++ b/boot/bootm_os.c
@@ -303,6 +303,7 @@ static void do_bootvx_fdt(bootm_headers_t *images)
 #else
printf("## Starting vxWorks at 0x%08lx\n", (ulong)images->ep);
 #endif
+   flush();
 
boot_jump_vxworks(images);
 
diff --git a/cmd/boot.c b/cmd/boot.c
index be67a5980de3..14839c1cedcc 100644
--- a/cmd/boot.c
+++ b/cmd/boot.c
@@ -32,6 +32,7 @@ static int do_go(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
addr = hextoul(argv[1], NULL);
 
printf ("## Starting application at 0x%08lX ...\n", addr);
+   flush();
 
/*
 * pass address parameter as argv[0] (aka command name),
diff --git a/cmd/elf.c b/cmd/elf.c
index ce40d3f72a7c..b7b9f506a526 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -72,6 +72,7 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
return rcode;
 
printf("## Starting application at 0x%08lx ...\n", addr);
+   flush();
 
/*
 * pass address parameter as argv[0] (aka command name),
@@ -274,6 +275,7 @@ int do_bootvx(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
puts("## Not an ELF image, assuming binary\n");
 
printf("## Starting vxWorks at 0x%08lx ...\n", addr);
+   flush();
 
dcache_disable();
 #if defined(CONFIG_ARM64) && defined(CONFIG_ARMV8_PSCI)
-- 
2.20.1

[PATCH v3 2/6] console: Implement flush() function

[Pali Rohár]

On certain places it is required to flush output print buffers to ensure
that text strings were sent to console or serial devices. For example when
printing message that U-Boot is going to boot kernel or when U-Boot is
going to change baudrate of terminal device.

Therefore introduce a new flush() and fflush() functions into console code.
These functions will call .flush callback of associated stdio_dev device.

As this function may increase U-Boot side, allow to compile U-Boot without
this function. For this purpose there is a new config CONSOLE_FLUSH_SUPPORT
which is enabled by default and can be disabled. It is a good idea to have
this option enabled for all boards which have enough space for it.

When option is disabled when U-Boot defines just empty static inline
function fflush() to avoid ifdefs in other code.

Signed-off-by: Pali Rohár 
---
Changes in v3:
* Added macro STDIO_DEV_ASSIGN_FLUSH()
---
 common/Kconfig  |  6 +
 common/console.c| 61 +
 include/_exports.h  |  3 +++
 include/stdio.h | 15 +++
 include/stdio_dev.h |  7 ++
 5 files changed, 92 insertions(+)

diff --git a/common/Kconfig b/common/Kconfig
index e7914ca750a3..109741cc6c44 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -186,6 +186,12 @@ config PRE_CON_BUF_ADDR
  We should consider removing this option and allocating the memory
  in board_init_f_init_reserve() instead.
 
+config CONSOLE_FLUSH_SUPPORT
+   bool "Enable console flush support"
+   default y
+   help
+ This enables compilation of flush() function for console flush 
support.
+
 config CONSOLE_MUX
bool "Enable console multiplexing"
default y if DM_VIDEO || VIDEO || LCD
diff --git a/common/console.c b/common/console.c
index e783f309bf06..0abfc224b53b 100644
--- a/common/console.c
+++ b/common/console.c
@@ -199,6 +199,7 @@ static int console_setfile(int file, struct stdio_dev * dev)
case stdout:
gd->jt->putc  = putc;
gd->jt->puts  = puts;
+   STDIO_DEV_ASSIGN_FLUSH(gd->jt, flush);
gd->jt->printf = printf;
break;
}
@@ -364,6 +365,19 @@ static void console_puts(int file, const char *s)
}
 }
 
+#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
+static void console_flush(int file)
+{
+   int i;
+   struct stdio_dev *dev;
+
+   for_each_console_dev(i, file, dev) {
+   if (dev->flush != NULL)
+   dev->flush(dev);
+   }
+}
+#endif
+
 #if CONFIG_IS_ENABLED(SYS_CONSOLE_IS_IN_ENV)
 static inline void console_doenv(int file, struct stdio_dev *dev)
 {
@@ -413,6 +427,14 @@ static inline void console_puts(int file, const char *s)
stdio_devices[file]->puts(stdio_devices[file], s);
 }
 
+#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
+static inline void console_flush(int file)
+{
+   if (stdio_devices[file]->flush)
+   stdio_devices[file]->flush(stdio_devices[file]);
+}
+#endif
+
 #if CONFIG_IS_ENABLED(SYS_CONSOLE_IS_IN_ENV)
 static inline void console_doenv(int file, struct stdio_dev *dev)
 {
@@ -526,6 +548,14 @@ void fputs(int file, const char *s)
console_puts(file, s);
 }
 
+#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
+void fflush(int file)
+{
+   if (file < MAX_FILES)
+   console_flush(file);
+}
+#endif
+
 int fprintf(int file, const char *fmt, ...)
 {
va_list args;
@@ -740,6 +770,37 @@ void puts(const char *s)
}
 }
 
+#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
+void flush(void)
+{
+   if (!gd)
+   return;
+
+   /* sandbox can send characters to stdout before it has a console */
+   if (IS_ENABLED(CONFIG_SANDBOX) && !(gd->flags & GD_FLG_SERIAL_READY)) {
+   os_flush();
+   return;
+   }
+
+   if (IS_ENABLED(CONFIG_DEBUG_UART) && !(gd->flags & GD_FLG_SERIAL_READY))
+   return;
+
+   if (IS_ENABLED(CONFIG_SILENT_CONSOLE) && (gd->flags & GD_FLG_SILENT))
+   return;
+
+   if (IS_ENABLED(CONFIG_DISABLE_CONSOLE) && (gd->flags & 
GD_FLG_DISABLE_CONSOLE))
+   return;
+
+   if (!gd->have_console)
+   return;
+
+   if (gd->flags & GD_FLG_DEVINIT) {
+   /* Send to the standard output */
+   fflush(stdout);
+   }
+}
+#endif
+
 #ifdef CONFIG_CONSOLE_RECORD
 int console_record_init(void)
 {
diff --git a/include/_exports.h b/include/_exports.h
index f6df8b610734..1af946fac327 100644
--- a/include/_exports.h
+++ b/include/_exports.h
@@ -12,6 +12,9 @@
EXPORT_FUNC(tstc, int, tstc, void)
EXPORT_FUNC(putc, void, putc, const char)
EXPORT_FUNC(puts, void, puts, const char *)
+#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
+   EXPORT_FUNC(flush, void, flush, void)
+#endif
EXPORT_FUNC(printf, int, printf, const char*, ...)
 #if (defined(CONFIG_X86) && !defined(CONFIG_X86_64)) || 

[PATCH v3 4/6] serial: Implement serial_flush() function for console flush() fallback

[Pali Rohár]

Like in all other console functions, implement also serial_flush() function
as a fallback int console flush() function.

Flush support is available only when config option CONSOLE_FLUSH_SUPPORT is
enabled. So when it is disabled then provides just empty static inline
function serial_flush().

Signed-off-by: Pali Rohár 
---
 common/console.c   |  3 +++
 common/stdio.c |  8 
 drivers/serial/serial-uclass.c | 10 ++
 include/serial.h   |  5 +
 4 files changed, 26 insertions(+)

diff --git a/common/console.c b/common/console.c
index 0abfc224b53b..e4dc1da44a35 100644
--- a/common/console.c
+++ b/common/console.c
@@ -797,6 +797,9 @@ void flush(void)
if (gd->flags & GD_FLG_DEVINIT) {
/* Send to the standard output */
fflush(stdout);
+   } else {
+   /* Send directly to the handler */
+   serial_flush();
}
 }
 #endif
diff --git a/common/stdio.c b/common/stdio.c
index 92161a0df87d..13083842cbd9 100644
--- a/common/stdio.c
+++ b/common/stdio.c
@@ -87,6 +87,13 @@ static void stdio_serial_puts(struct stdio_dev *dev, const 
char *s)
serial_puts(s);
 }
 
+#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
+static void stdio_serial_flush(struct stdio_dev *dev)
+{
+   serial_flush();
+}
+#endif
+
 static int stdio_serial_getc(struct stdio_dev *dev)
 {
return serial_getc();
@@ -112,6 +119,7 @@ static void drv_system_init (void)
dev.flags = DEV_FLAGS_OUTPUT | DEV_FLAGS_INPUT;
dev.putc = stdio_serial_putc;
dev.puts = stdio_serial_puts;
+   STDIO_DEV_ASSIGN_FLUSH(, stdio_serial_flush);
dev.getc = stdio_serial_getc;
dev.tstc = stdio_serial_tstc;
stdio_register ();
diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index be6502f3d24c..f028da0900cd 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -327,6 +327,16 @@ void serial_puts(const char *str)
_serial_puts(gd->cur_serial_dev, str);
 }
 
+#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
+void serial_flush(void)
+{
+   if (!gd->cur_serial_dev)
+   return;
+
+   _serial_flush(gd->cur_serial_dev);
+}
+#endif
+
 int serial_getc(void)
 {
if (!gd->cur_serial_dev)
diff --git a/include/serial.h b/include/serial.h
index 8c2e7adbc321..f9009d4046e3 100644
--- a/include/serial.h
+++ b/include/serial.h
@@ -362,6 +362,11 @@ void serial_setbrg(void);
 void serial_putc(const char ch);
 void serial_putc_raw(const char ch);
 void serial_puts(const char *str);
+#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
+void serial_flush(void);
+#else
+static inline void serial_flush(void) {}
+#endif
 int serial_getc(void);
 int serial_tstc(void);
 
-- 
2.20.1

[PATCH v3 5/6] serial: Call flush() before changing baudrate

[Pali Rohár]

Changing baudrate is a sensitive operation. To ensure that U-Boot messages
printed before changing baudrate are not lost, call new U-Boot console
flush() function.

Signed-off-by: Pali Rohár 
---
Changes in v3:
* Remove support from serial.c
* Fix commit message
---
 cmd/load.c | 5 +
 drivers/serial/serial-uclass.c | 1 +
 2 files changed, 6 insertions(+)

diff --git a/cmd/load.c b/cmd/load.c
index e44ae0d56b75..5c4f34781d45 100644
--- a/cmd/load.c
+++ b/cmd/load.c
@@ -83,6 +83,7 @@ static int do_load_serial(struct cmd_tbl *cmdtp, int flag, 
int argc,
printf("## Switch baudrate to %d bps and press ENTER ...\n",
load_baudrate);
udelay(5);
+   flush();
gd->baudrate = load_baudrate;
serial_setbrg();
udelay(5);
@@ -126,6 +127,7 @@ static int do_load_serial(struct cmd_tbl *cmdtp, int flag, 
int argc,
printf("## Switch baudrate to %d bps and press ESC ...\n",
current_baudrate);
udelay(5);
+   flush();
gd->baudrate = current_baudrate;
serial_setbrg();
udelay(5);
@@ -317,6 +319,7 @@ int do_save_serial(struct cmd_tbl *cmdtp, int flag, int 
argc,
printf("## Switch baudrate to %d bps and press ESC ...\n",
(int)current_baudrate);
udelay(5);
+   flush();
gd->baudrate = current_baudrate;
serial_setbrg();
udelay(5);
@@ -471,6 +474,7 @@ static int do_load_serial_bin(struct cmd_tbl *cmdtp, int 
flag, int argc,
printf("## Switch baudrate to %d bps and press ENTER ...\n",
load_baudrate);
udelay(5);
+   flush();
gd->baudrate = load_baudrate;
serial_setbrg();
udelay(5);
@@ -533,6 +537,7 @@ static int do_load_serial_bin(struct cmd_tbl *cmdtp, int 
flag, int argc,
printf("## Switch baudrate to %d bps and press ESC ...\n",
current_baudrate);
udelay(5);
+   flush();
gd->baudrate = current_baudrate;
serial_setbrg();
udelay(5);
diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index f028da0900cd..04b753c229ab 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -476,6 +476,7 @@ static int on_baudrate(const char *name, const char *value, 
enum env_op op,
printf("## Switch baudrate to %d bps and press ENTER 
...\n",
   baudrate);
udelay(5);
+   flush();
}
 
gd->baudrate = baudrate;
-- 
2.20.1

[PATCH v3 1/6] sandbox: Add function os_flush()

[Pali Rohár]

It flushes stdout.

Signed-off-by: Pali Rohár 
---
 arch/sandbox/cpu/os.c | 5 +
 include/os.h  | 8 
 2 files changed, 13 insertions(+)

diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index f937991139c9..01845e388d35 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -669,6 +669,11 @@ void os_puts(const char *str)
os_putc(*str++);
 }
 
+void os_flush(void)
+{
+   fflush(stdout);
+}
+
 int os_write_ram_buf(const char *fname)
 {
struct sandbox_state *state = state_get_current();
diff --git a/include/os.h b/include/os.h
index 148178787bc2..5b353ae9d94b 100644
--- a/include/os.h
+++ b/include/os.h
@@ -295,6 +295,14 @@ void os_putc(int ch);
  */
 void os_puts(const char *str);
 
+/**
+ * os_flush() - flush controlling OS terminal
+ *
+ * This bypasses the U-Boot console support and flushes directly the OS
+ * stdout file descriptor.
+ */
+void os_flush(void);
+
 /**
  * os_write_ram_buf() - write the sandbox RAM buffer to a existing file
  *
-- 
2.20.1

[PATCH v3 0/6] console: Implement flush() function

[Pali Rohár]

On certain places it is required to flush output print buffers to ensure
that text strings were sent to console or serial devices. For example when
printing message that U-Boot is going to boot kernel or when U-Boot is
going to change baudrate of terminal device.

Some console devices, like UART, have putc/puts functions which just put
characters into HW transmit queue and do not wait until all data are
transmitted. Doing some sensitive operations (like changing baudrate or
starting kernel which resets UART HW) cause that U-Boot messages are lost.

Therefore introduce a new flush() function, implement it for all serial
devices via pending(false) callback and use this new flush() function on
sensitive places after which output device may go into reset state.

This change fixes printing of U-Boot messages:
"## Starting application at ..."
"## Switch baudrate to ..."

Changes in v3:
* add macro STDIO_DEV_ASSIGN_FLUSH()
* fix commit messages
* remove changes from serial.c

Changes in v2:
* split one big patch into smaller 6 patches
* add config option to allow disabling this new function

Pali Rohár (6):
  sandbox: Add function os_flush()
  console: Implement flush() function
  serial: Implement flush callback
  serial: Implement serial_flush() function for console flush() fallback
  serial: Call flush() before changing baudrate
  boot: Call flush() before booting

 arch/sandbox/cpu/os.c  |  5 +++
 boot/bootm_os.c|  1 +
 cmd/boot.c |  1 +
 cmd/elf.c  |  2 ++
 cmd/load.c |  5 +++
 common/Kconfig |  6 
 common/console.c   | 64 ++
 common/stdio.c |  8 +
 drivers/serial/serial-uclass.c | 31 
 include/_exports.h |  3 ++
 include/os.h   |  8 +
 include/serial.h   |  5 +++
 include/stdio.h| 15 
 include/stdio_dev.h|  7 
 14 files changed, 161 insertions(+)

-- 
2.20.1

Re: [PATCH v3] tee: optee: rework TA bus scanning code

[Etienne Carriere]

Hi Ilias,

I commented v2 instead of you're latest post.
Please find my few comments below.
Addressed or not, Reviewed-by: Etienne Carriere 


On Sat, 3 Sept 2022 at 09:54, Ilias Apalodimas
 wrote:
>
> Late versions of OP-TEE support a pseudo bus.  TAs that behave as
> hardware blocks (e.g TPM, RNG etc) present themselves on a bus which we can
> scan.  Unfortunately U-Boot doesn't support that yet. It's worth noting
> that we already have a workaround for RNG.  The details are in
> commit 70812bb83da6 ("tee: optee: bind rng optee driver")
>
> So let's add a list of devices based on U-Boot Kconfig options that we will
> scan until we properly implement the tee-bus functionality.
>
> While at it change the behaviour of the tee core itself wrt to device
> binding.  If some device binding fails, print a warning instead of
> disabling OP-TEE.
>
> Signed-off-by: Ilias Apalodimas 
> Reviewed-by: Jens Wiklander 
> ---
> Changes since v:2
> - Fixed typo on driver name ftpm-tee -> ftpm_tee
>
> Changes since v1:
> - remove a macro and use ARRAY_SIZE directly
> - print a warning instead of disabling op-tee if a driver binding fails
>  drivers/tee/optee/core.c | 23 +++
>  1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index a89d62aaf0b3..1437ba1b676b 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -31,6 +31,18 @@ struct optee_pdata {
> optee_invoke_fn *invoke_fn;
>  };
>
> +static const struct {
> +   const char *drv_name;
> +   const char *dev_name;
> +} optee_bus_probe[] = {
> +#ifdef CONFIG_RNG_OPTEE
> +   { "optee-rng", "optee-rng" },

Prefer
  { .drv_name = "optee-rng", .dev_name = "optee-rng" },

> +#endif
> +#ifdef CONFIG_TPM2_FTPM_TEE
> +   { "ftpm_tee", "ftpm_tee" },
> +#endif
> +};
> +
>  struct rpc_param {
> u32 a0;
> u32 a1;
> @@ -643,7 +655,7 @@ static int optee_probe(struct udevice *dev)
> struct optee_pdata *pdata = dev_get_plat(dev);
> u32 sec_caps;
> struct udevice *child;
> -   int ret;
> +   int ret, i;
>
> if (!is_optee_api(pdata->invoke_fn)) {
> dev_err(dev, "OP-TEE api uid mismatch\n");
> @@ -672,10 +684,13 @@ static int optee_probe(struct udevice *dev)
>  * in U-Boot, the discovery of TA on the TEE bus is not supported:
>  * only bind the drivers associated to the supported OP-TEE TA
>  */
> -   if (IS_ENABLED(CONFIG_RNG_OPTEE)) {
> -   ret = device_bind_driver(dev, "optee-rng", "optee-rng", 
> );
> +
> +   for (i = 0; i < ARRAY_SIZE(optee_bus_probe); i++) {
> +   ret = device_bind_driver(dev, optee_bus_probe[i].drv_name,
> +optee_bus_probe[i].dev_name, );

Could s//NULL/.

Br,
etienne

> if (ret)
> -   return ret;
> +   dev_warn(dev, "Failed to bind device %s\n",
> +optee_bus_probe[i].dev_name);
> }
>
> return 0;
> --
> 2.34.1
>

Re: [PATCH v2] tee: optee: rework TA bus scanning code

[Etienne Carriere]

Hi Ilias,

Reviewed-by: Etienne Carriere  with minor comments.

On Fri, 2 Sept 2022 at 21:11, Ilias Apalodimas
 wrote:
>
> Thanks Jens
>
> On Wed, 31 Aug 2022 at 08:59, Jens Wiklander  
> wrote:
> >
> > On Mon, Aug 29, 2022 at 8:34 AM Ilias Apalodimas
> >  wrote:
> > >
> > > Late versions of OP-TEE support a pseudo bus.  TAs that behave as
> > > hardware blocks (e.g TPM, RNG etc) present themselves on a bus which we 
> > > can
> > > scan.  Unfortunately U-Boot doesn't support that yet. It's worth noting
> > > that we already have a workaround for RNG.  The details are in
> > > commit 70812bb83da6 ("tee: optee: bind rng optee driver")
> > >
> > > So let's add a list of devices based on U-Boot Kconfig options that we 
> > > will
> > > scan until we properly implement the tee-bus functionality.
> > >
> > > While at it change the behaviour of the tee core itself wrt to device
> > > binding.  If some device binding fails, print a warning instead of
> > > disabling OP-TEE.
> > >
> > > Signed-off-by: Ilias Apalodimas 
> > > ---
> >
> > Reviewed-by: Jens Wiklander 
>
> There's a typo in that patch. For the tpm to work the string needs to
> be ftpm_tee instead of ftpm-tee.  I'll send a v3, shall I keep your
> RB?
>
> Cheers
> /Ilias
> >
> > Cheers,
> > Jens
> >
> > > Changes since v1:
> > > - remove a macro and use ARRAY_SIZE directly
> > > - print a warning instead of disabling op-tee if a driver binding fails
> > >
> > >  drivers/tee/optee/core.c | 23 +++
> > >  1 file changed, 19 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> > > index a89d62aaf0b3..3cc92f09d299 100644
> > > --- a/drivers/tee/optee/core.c
> > > +++ b/drivers/tee/optee/core.c
> > > @@ -31,6 +31,18 @@ struct optee_pdata {
> > > optee_invoke_fn *invoke_fn;
> > >  };
> > >
> > > +static const struct {
> > > +   const char *drv_name;
> > > +   const char *dev_name;
> > > +} optee_bus_probe[] = {
> > > +#ifdef CONFIG_RNG_OPTEE
> > > +   { "optee-rng", "optee-rng" },

By the way, prefer:
+   { .drv_name = "optee-rng", .dev_name = "optee-rng" },


> > > +#endif
> > > +#ifdef CONFIG_TPM2_FTPM_TEE
> > > +   { "ftpm-tee", "ftpm-tee" },
> > > +#endif
> > > +};
> > > +
> > >  struct rpc_param {
> > > u32 a0;
> > > u32 a1;
> > > @@ -643,7 +655,7 @@ static int optee_probe(struct udevice *dev)
> > > struct optee_pdata *pdata = dev_get_plat(dev);
> > > u32 sec_caps;
> > > struct udevice *child;
> > > -   int ret;
> > > +   int ret, i;
> > >
> > > if (!is_optee_api(pdata->invoke_fn)) {
> > > dev_err(dev, "OP-TEE api uid mismatch\n");
> > > @@ -672,10 +684,13 @@ static int optee_probe(struct udevice *dev)
> > >  * in U-Boot, the discovery of TA on the TEE bus is not supported:
> > >  * only bind the drivers associated to the supported OP-TEE TA
> > >  */
> > > -   if (IS_ENABLED(CONFIG_RNG_OPTEE)) {
> > > -   ret = device_bind_driver(dev, "optee-rng", "optee-rng", 
> > > );
> > > +
> > > +   for (i = 0; i < ARRAY_SIZE(optee_bus_probe); i++) {
> > > +   ret = device_bind_driver(dev, optee_bus_probe[i].drv_name,
> > > +optee_bus_probe[i].dev_name, 
> > > );

Can drop child here. NULL is fine.

> > > if (ret)
> > > -   return ret;
> > > +   dev_warn(dev, "Failed to bind device %s\n",
> > > +optee_bus_probe[i].dev_name);
> > > }
> > >
> > > return 0;
> > > --
> > > 2.34.1
> > >

RE: [PATCH v1 0/2] serial_mxc: fixing reception

[ZHIZHIKIN Andrey]

Hello Pali,

> -Original Message-
> From: U-Boot  On Behalf Of Pali Rohar
> Sent: Monday, September 5, 2022 11:14 AM
> To: ZHIZHIKIN Andrey 
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH v1 0/2] serial_mxc: fixing reception
> 
> On Monday 05 September 2022 09:12:49 ZHIZHIKIN Andrey wrote:
> > Hello Pali,
> >
> > > -Original Message-
> > > From: U-Boot  On Behalf Of Pali Rohar
> > > Sent: Monday, September 5, 2022 10:59 AM
> > > To: u-boot@lists.denx.de
> > > Subject: Re: [PATCH v1 0/2] serial_mxc: fixing reception
> > >
> > > On Monday 05 September 2022 10:53:58 Johannes Schneider wrote:
> > > > while writing to a imx-serial device is probably thoroughly tested - and
> > > obviosly works for the debug-serial - using a serial driver to read data
> received
> > > over the serial interface does not work reliably.
> > > >
> > > > the patches in this series address issues found during the 
> > > > implementation
> of a
> > > custom uboot-command to query a coprocessor, connected to an imx8mm over
> uart4,
> > > for mainboard-identification strings
> > > >
> > > >
> > > > Johannes Schneider (2):
> > > >   serial: mxc: enable the RX pipeline
> > > >   serial: mxc: have putc use the TXFIFO
> > > >
> > > >  drivers/serial/serial_mxc.c | 13 -
> > > >  1 file changed, 12 insertions(+), 1 deletion(-)
> > >
> > > Hello! I'm really not maintainer of mxc and I do not have time to review
> > > those patches. So please do not send me them as I'm spammed with tons of
> > > unrelated emails/patches.
> >
> > Then there is a problem with having your name as a maintainer for this file.
> >
> > If I execute:
> > $ ./scripts/get_maintainer.pl drivers/serial/serial_mxc.c
> > "Pali Rohár" 
> (commit_signer:1/1=100%,authored:1/1=100%,added_lines:2/2=100%,removed_lines:2/2=
> 100%)
> > u-boot@lists.denx.de (open list)
> >
> > I guess this has to be corrected then, right?
> >
> > Regards,
> > Andrey
> 
> Yes, please correct it. I have not added myself to the list of mxc
> maintainers and I a really do not have time for reviewing mxc patches.

I cannot modify this part since removing you from maintainer list would
require a transfer of maintainership of this component to another name,
which I do not know.

I've Cc:'d Tom and people from imx world here so they can make a decision
on who shall continue the maintenance of this file when your entry is removed.

-- andrey

[PATCH] ARM: dts: stm32mp15: remove hwlocks from pinctrl

[Etienne Carriere]

Removes hwlocks properties from stm32mp151 pinctrl node. These locks
could be used for other purpose, depending on board and software
configuration hence do not enforce their use to protect pinctrl
devices.

This patch is an alignment with Linux device tree with v6.0 as the
hwsem support wasn’t yet added in pincontrol in kernel. It avoids
issues when the Linux kernel is started with the U-Boot device tree.

Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Signed-off-by: Etienne Carriere 
---
 arch/arm/dts/stm32mp151.dtsi | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/dts/stm32mp151.dtsi b/arch/arm/dts/stm32mp151.dtsi
index a5ac62c83d..767a06ef68 100644
--- a/arch/arm/dts/stm32mp151.dtsi
+++ b/arch/arm/dts/stm32mp151.dtsi
@@ -1663,7 +1663,6 @@
ranges = <0 0x50002000 0xa400>;
interrupt-parent = <>;
st,syscfg = < 0x60 0xff>;
-   hwlocks = < 0>;
pins-are-numbered;
 
gpioa: gpio@50002000 {
@@ -1796,7 +1795,6 @@
pins-are-numbered;
interrupt-parent = <>;
st,syscfg = < 0x60 0xff>;
-   hwlocks = < 0>;
 
gpioz: gpio@54004000 {
gpio-controller;
-- 
2.25.1

Re: [PATCH v1 0/2] serial_mxc: fixing reception

[Pali Rohár]

On Monday 05 September 2022 09:12:49 ZHIZHIKIN Andrey wrote:
> Hello Pali,
> 
> > -Original Message-
> > From: U-Boot  On Behalf Of Pali Rohar
> > Sent: Monday, September 5, 2022 10:59 AM
> > To: u-boot@lists.denx.de
> > Subject: Re: [PATCH v1 0/2] serial_mxc: fixing reception
> > 
> > On Monday 05 September 2022 10:53:58 Johannes Schneider wrote:
> > > while writing to a imx-serial device is probably thoroughly tested - and
> > obviosly works for the debug-serial - using a serial driver to read data 
> > received
> > over the serial interface does not work reliably.
> > >
> > > the patches in this series address issues found during the implementation 
> > > of a
> > custom uboot-command to query a coprocessor, connected to an imx8mm over 
> > uart4,
> > for mainboard-identification strings
> > >
> > >
> > > Johannes Schneider (2):
> > >   serial: mxc: enable the RX pipeline
> > >   serial: mxc: have putc use the TXFIFO
> > >
> > >  drivers/serial/serial_mxc.c | 13 -
> > >  1 file changed, 12 insertions(+), 1 deletion(-)
> > 
> > Hello! I'm really not maintainer of mxc and I do not have time to review
> > those patches. So please do not send me them as I'm spammed with tons of
> > unrelated emails/patches.
> 
> Then there is a problem with having your name as a maintainer for this file.
> 
> If I execute:
> $ ./scripts/get_maintainer.pl drivers/serial/serial_mxc.c
> "Pali Rohár"  
> (commit_signer:1/1=100%,authored:1/1=100%,added_lines:2/2=100%,removed_lines:2/2=100%)
> u-boot@lists.denx.de (open list)
> 
> I guess this has to be corrected then, right?
> 
> Regards,
> Andrey

Yes, please correct it. I have not added myself to the list of mxc
maintainers and I a really do not have time for reviewing mxc patches.

RE: [PATCH v1 0/2] serial_mxc: fixing reception

[ZHIZHIKIN Andrey]

Hello Pali,

> -Original Message-
> From: U-Boot  On Behalf Of Pali Rohar
> Sent: Monday, September 5, 2022 10:59 AM
> To: u-boot@lists.denx.de
> Subject: Re: [PATCH v1 0/2] serial_mxc: fixing reception
> 
> On Monday 05 September 2022 10:53:58 Johannes Schneider wrote:
> > while writing to a imx-serial device is probably thoroughly tested - and
> obviosly works for the debug-serial - using a serial driver to read data 
> received
> over the serial interface does not work reliably.
> >
> > the patches in this series address issues found during the implementation 
> > of a
> custom uboot-command to query a coprocessor, connected to an imx8mm over 
> uart4,
> for mainboard-identification strings
> >
> >
> > Johannes Schneider (2):
> >   serial: mxc: enable the RX pipeline
> >   serial: mxc: have putc use the TXFIFO
> >
> >  drivers/serial/serial_mxc.c | 13 -
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> Hello! I'm really not maintainer of mxc and I do not have time to review
> those patches. So please do not send me them as I'm spammed with tons of
> unrelated emails/patches.

Then there is a problem with having your name as a maintainer for this file.

If I execute:
$ ./scripts/get_maintainer.pl drivers/serial/serial_mxc.c
"Pali Rohár"  
(commit_signer:1/1=100%,authored:1/1=100%,added_lines:2/2=100%,removed_lines:2/2=100%)
u-boot@lists.denx.de (open list)

I guess this has to be corrected then, right?

Regards,
Andrey

Re: [PATCH v1 0/2] serial_mxc: fixing reception

[Pali Rohár]

On Monday 05 September 2022 10:53:58 Johannes Schneider wrote:
> while writing to a imx-serial device is probably thoroughly tested - and 
> obviosly works for the debug-serial - using a serial driver to read data 
> received over the serial interface does not work reliably.
> 
> the patches in this series address issues found during the implementation of 
> a custom uboot-command to query a coprocessor, connected to an imx8mm over 
> uart4, for mainboard-identification strings
> 
> 
> Johannes Schneider (2):
>   serial: mxc: enable the RX pipeline
>   serial: mxc: have putc use the TXFIFO
> 
>  drivers/serial/serial_mxc.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)

Hello! I'm really not maintainer of mxc and I do not have time to review
those patches. So please do not send me them as I'm spammed with tons of
unrelated emails/patches.

Re: [PATCH v2 1/9] nand: atmel: Add DM based NAND driver

[Eugen.Hristev]

On 8/29/22 9:19 AM, Balamanikandan Gunasundar wrote:
> This implementation is ported from the rework done by Boris Brezillon
> in Linux. This porting is done based on linux-5.4-at91. The driver is
> tested in sam9x60ek, sama5d3_xplained, sam9x75eb and sama7g54-ddr3-eb.
> 
> Changes done includes
> 
> - Adapt GPIO descriptor apis for U-Boot. Use
>gpio_request_by_name_nodev, dm_gpio_get_value etc.
> - Use U_BOOT_DRIVER instead of platform_driver.
> - Replace struct platform_device with struct udevice
> - Check the status of nfc exec operation by polling the status
>register instead of interrupt based handling
> - DMA operations not supported. Remove it
> - Adapt DT parsing to U-Boot APIs
> 
> Signed-off-by: Balamanikandan Gunasundar 
> 
> ---
>   drivers/mtd/nand/raw/Kconfig |8 +
>   drivers/mtd/nand/raw/Makefile|1 +
>   drivers/mtd/nand/raw/atmel/Makefile  |4 +
>   drivers/mtd/nand/raw/atmel/nand-controller.c | 2293 ++
>   4 files changed, 2306 insertions(+)
>   create mode 100644 drivers/mtd/nand/raw/atmel/Makefile
>   create mode 100644 drivers/mtd/nand/raw/atmel/nand-controller.c
> 
> diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
> index ce67d1abde..4d023e2893 100644
> --- a/drivers/mtd/nand/raw/Kconfig
> +++ b/drivers/mtd/nand/raw/Kconfig
> @@ -37,6 +37,14 @@ config SYS_NAND_USE_FLASH_BBT
>   help
> Enable the BBT (Bad Block Table) usage.
>   
> +config DM_NAND_ATMEL
> +   bool "Support Atmel NAND controller with DM support"
> +   select SYS_NAND_SELF_INIT
> +   imply SYS_NAND_USE_FLASH_BBT
> +   help
> + Enable this driver for NAND flash platforms using an Atmel NAND
> + controller.
> +
>   config NAND_ATMEL
>   bool "Support Atmel NAND controller"
>   select SYS_NAND_SELF_INIT
> diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
> index a398aa9d88..42c1fb25b4 100644
> --- a/drivers/mtd/nand/raw/Makefile
> +++ b/drivers/mtd/nand/raw/Makefile
> @@ -48,6 +48,7 @@ ifdef NORMAL_DRIVERS
>   obj-$(CONFIG_NAND_ECC_BCH) += nand_bch.o
>   
>   obj-$(CONFIG_NAND_ATMEL) += atmel_nand.o
> +obj-$(CONFIG_DM_NAND_ATMEL) += atmel/
>   obj-$(CONFIG_NAND_ARASAN) += arasan_nfc.o
>   obj-$(CONFIG_NAND_BRCMNAND) += brcmnand/
>   obj-$(CONFIG_NAND_DAVINCI) += davinci_nand.o
> diff --git a/drivers/mtd/nand/raw/atmel/Makefile 
> b/drivers/mtd/nand/raw/atmel/Makefile
> new file mode 100644
> index 00..6708416983
> --- /dev/null
> +++ b/drivers/mtd/nand/raw/atmel/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +obj-$(CONFIG_DM_NAND_ATMEL)  += atmel-nand-controller.o
> +
> +atmel-nand-controller-objs   := nand-controller.o
> diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c 
> b/drivers/mtd/nand/raw/atmel/nand-controller.c
> new file mode 100644
> index 00..29365c7db0
> --- /dev/null
> +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
> @@ -0,0 +1,2293 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2022 ATMEL
> + * Copyright 2017 Free Electrons
> + *
> + * Author: Boris Brezillon 
> + *
> + * Derived from the atmel_nand.c driver which contained the following
> + * copyrights:
> + *
> + *   Copyright 2003 Rick Bronson
> + *
> + *   Derived from drivers/mtd/nand/autcpu12.c (removed in v3.8)
> + *   Copyright 2001 Thomas Gleixner (gleix...@autronix.de)
> + *
> + *   Derived from drivers/mtd/spia.c (removed in v3.8)
> + *   Copyright 2000 Steven J. Hill (sjh...@cotw.com)
> + *
> + *
> + *   Add Hardware ECC support for AT91SAM9260 / AT91SAM9263
> + *   Richard Genoud (richard.gen...@gmail.com), Adeneo Copyright 2007
> + *
> + *   Derived from Das U-Boot source code
> + *   (u-boot-1.1.5/board/atmel/at91sam9263ek/nand.c)
> + *   Copyright 2006 ATMEL Rousset, Lacressonniere Nicolas
> + *
> + *   Add Programmable Multibit ECC support for various AT91 SoC
> + *   Copyright 2012 ATMEL, Hong Xu
> + *
> + *   Add Nand Flash Controller support for SAMA5 SoC
> + *   Copyright 2013 ATMEL, Josh Wu (josh...@atmel.com)
> + *
> + *   Port from Linux
> + *   Balamanikandan Gunasundar(balamanikandan.gunasun...@microchip.com)
> + *   Copyright (C) 2022 Microchip Technology Inc.
> + *
> + * A few words about the naming convention in this file. This convention
> + * applies to structure and function names.
> + *
> + * Prefixes:
> + *
> + * - atmel_nand_: all generic structures/functions
> + * - atmel_smc_nand_: all structures/functions specific to the SMC interface
> + * (at91sam9 and avr32 SoCs)
> + * - atmel_hsmc_nand_: all structures/functions specific to the HSMC 
> interface
> + *  (sama5 SoCs and later)
> + * - atmel_nfc_: all structures/functions used to manipulate the NFC 
> sub-block
> + *that is available in the HSMC block
> + * - _nand_: all SoC specific structures/functions
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> 

Re: RISCV: the machanism of available_harts may cause other harts boot failure

[Nikita Shubin]

Hi Rick!

On Mon, 5 Sep 2022 14:22:41 +0800
Rick Chen  wrote:

> Hi,
> 
> When I free-run a SMP system, I once hit a failure case where some
> harts didn't boot to the kernel shell successfully.
> However it can't be duplicated anymore even if I try many times.
> 
> But when I set a break during debugging with GDB, it can trigger the
> failure case each time.

If hart fails to register itself to available_harts before
send_ipi_many is hit by the main hart: 
https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/riscv/lib/smp.c#L50

it won't exit the secondary_hart_loop:
https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/riscv/cpu/start.S#L433
As no ipi will be sent to it.

This might be exactly your case.

> I think the mechanism of available_harts does not provide a method
> that guarantees the success of the SMP system.
> Maybe we shall think of a better way for the SMP booting or just
> remove it ?

I haven't experienced any unexplained problem with hart_lottery or
available_harts_lock unless:

1) harts are started non-simultaneously
2) SPL/U-Boot is in some kind of TCM, OCRAM, etc... which is not cleared
on reset which leaves available_harts dirty
3) something is wrong with atomics

Also there might be something wrong with IPI send/recieve.

> 
> Thread 8 hit Breakpoint 1, harts_early_init ()
> 
> (gdb) c
> Continuing.
> [Switching to Thread 7]
> 
> Thread 7 hit Breakpoint 1, harts_early_init ()
> 
> (gdb)
> Continuing.
> [Switching to Thread 6]
> 
> Thread 6 hit Breakpoint 1, harts_early_init ()
> 
> (gdb)
> Continuing.
> [Switching to Thread 5]
> 
> Thread 5 hit Breakpoint 1, harts_early_init ()
> 
> (gdb)
> Continuing.
> [Switching to Thread 4]
> 
> Thread 4 hit Breakpoint 1, harts_early_init ()
> 
> (gdb)
> Continuing.
> [Switching to Thread 3]
> 
> Thread 3 hit Breakpoint 1, harts_early_init ()
> (gdb)
> Continuing.
> [Switching to Thread 2]
> 
> Thread 2 hit Breakpoint 1, harts_early_init ()
> (gdb)
> Continuing.
> [Switching to Thread 1]
> 
> Thread 1 hit Breakpoint 1, harts_early_init ()
> (gdb)
> Continuing.
> [Switching to Thread 5]
> 
> 
> Thread 5 hit Breakpoint 3, 0x0120 in ?? ()
> (gdb) info threads
>   Id   Target Id Frame
>   1Thread 1 (hart 1) secondary_hart_loop () at
> arch/riscv/cpu/start.S:436 2Thread 2 (hart 2) secondary_hart_loop
> () at arch/riscv/cpu/start.S:436 3Thread 3 (hart 3)
> secondary_hart_loop () at arch/riscv/cpu/start.S:436 4Thread 4
> (hart 4) secondary_hart_loop () at arch/riscv/cpu/start.S:436
> * 5Thread 5 (hart 5) 0x0120 in ?? ()
>   6Thread 6 (hart 6) 0xb650 in ?? ()
>   7Thread 7 (hart 7) 0xb650 in ?? ()
>   8Thread 8 (hart 8) 0x5fa0 in ?? ()
> (gdb) c
> Continuing.

Do they all "offline" harts remain in SPL/U-Boot secondary_hart_loop ?

> 
> 
> 
> [0.175619] smp: Bringing up secondary CPUs ...
> [1.230474] CPU1: failed to come online
> [2.282349] CPU2: failed to come online
> [3.334394] CPU3: failed to come online
> [4.386783] CPU4: failed to come online
> [4.427829] smp: Brought up 1 node, 4 CPUs
> 
> 
> /root # cat /proc/cpuinfo
> processor   : 0
> hart: 4
> isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
> mmu : sv39
> 
> processor   : 5
> hart: 5
> isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
> mmu : sv39
> 
> processor   : 6
> hart: 6
> isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
> mmu : sv39
> 
> processor   : 7
> hart: 7
> isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
> mmu : sv39
> 
> /root #
> 
> Thanks,
> Rick

Re: [PATCH v15 01/10] eficonfig: menu-driven addition of UEFI boot option

[Masahisa Kojima]

Hi Heinrich,

On Sun, 4 Sept 2022 at 18:05, Heinrich Schuchardt  wrote:
>
> On 9/2/22 16:23, Masahisa Kojima wrote:
> > This commit add the "eficonfig" command.
> > The "eficonfig" command implements the menu-driven UEFI boot option
> > maintenance feature. This commit implements the addition of
> > new boot option. User can select the block device volume having
> > efi_simple_file_system_protocol and select the file corresponding
> > to the Boot variable. User can also enter the description and
> > optional_data of the BOOT variable in utf8.
> >
> > This commit adds "include/efi_config.h", it contains the common
> > definition to be used from other menus such as UEFI Secure Boot
> > key management.
> >
> > Signed-off-by: Masahisa Kojima 
> > ---
> > Changes in v15:
> > - moves the free(entry->data) outside the eficonfig_destroy() function and
> >entry->data is freed explicitly only when needed
> > - expose eficonfig_destroy() for succeeding secure boot key management patch
> >
> > Changes in v14:
> > - fix the missing initialization
> > - add comment for key handling
> >
> > No change in v13:
> >
> > Changes in v12:
> > - add select/clear menu before displaying volume selectio
> > - move function declaration from efi_loader.h to efi_config.h
> > - remove unused declaration
> > - support the boot option does not have file path
> > - correctly handle if optional_data is empty
> >
> > Changes in v11:
> > - refactor menu entry construction, directly use eficonfig_entry structure
> > - remove reading directory info to calculate the number of entry
> > - fix invalid efi_free_pool() in ill_file_info()
> > - use ANSI_CURSOR_POSITION and ANSI_CLEAR_LINE instead of printf("\n")
> >since current eficonfig implementation does not handle console size 
> > correctly.
> >printf("\n") at the outside of console size breaks the console output.
> >
> > Changes in v10:
> > - add initrd file selection
> > - do refactoring
> > - eficonfig_process_common() use list structure
> > - remove u'/' before copying file_path into current_path
> > - fix typos
> > - check snprintf error
> >
> > Changes in v9:
> > - move "efi_guid_bootmenu_auto_generated definition" into efi_bootmgr.c
> >to address build error when CMD_EFICONFIG is disabled
> > - fix typos and comment
> > - remove file system information from error message
> > - remove unreachable code in eficonfig_choice_entry()
> > - single printf() call as much as possible
> > - call only getchar() in  eficonfig_print_msg()
> > - filter out '.' entry from file selection
> > - update the efi_disk_get_device_name() implementation
> > - add function comment
> >
> > Changes in v8:
> > - command name is change from "efimenu" to "eficonfig"
> > - function and struct prefixes is changed to "eficonfig"
> > - fix menu header string
> >
> > Changes in v7:
> > - add "efimenu" command and uefi variable maintenance code
> >moved into cmd/efimenu.c
> > - create include/efimenu.h to define the common definition for
> >the other menu such as UEFI Secure Boot key management
> > - update boot option edit UI, user can select description, file,
> >and optional_data to edit in the same menu like following.
> >
> >** Edit Boot Option **
> >
> >   Description: debian
> >   File: virtio 0:1/EFI\debian\grubaa64.efi
> >   Optional Data: test
> >   Save
> >   Quit
> >
> > - remove exit parameter from efimenu_process_common()
> > - menu title type is changed from u16 to char
> > - efimenu_process_common() add menu title string
> > - reduce printf/puts function call for displaying the menu
> > - efi_console_get_u16_string() accept 0 length to allow
> >optional_data is empty
> > - efi_console_get_u16_string() the "size" parameter name is changes to 
> > "count"
> > - efimenu is now designed to maintain the UEFI variables, remove autoboot 
> > related code
> > - remove one empty line before "Quit" entry
> > - efimenu_init() processes only the first time
> >
> > Changes in v6:
> > - fix typos
> > - modify volume name to match U-Boot syntax
> > - compile in CONFIG_EFI_LOADER=n and CONFIG_CMD_BOOTEFI_BOOTMGR=n
> > - simplify u16_strncmp() usage
> > - support "a\b.efi" file path, use link list to handle filepath
> > - modify length check condition
> > - UEFI related menu items only appears with CONFIG_AUTOBOOT_MENU_SHOW=y
> >
> > Changes in v5:
> > - remove forward declarations
> > - add const qualifier for menu items
> > - fix the possible unaligned access for directory info access
> > - split into three commit 1)add boot option 2) delete boot option 3)change 
> > boot order
> >This commit is 1)add boot option.
> > - fix file name buffer allocation size, it should be 
> > EFI_BOOTMENU_FILE_PATH_MAX * sizeof(u16)
> > - fix wrong size checking for file selection
> >
> > Chanes in v4:
> > - UEFI boot option maintenance menu is integrated into bootmenu
> > - display the simplified volume name(e.g. usb0:1, nvme1:2) for the
> >volume selection
> > - 

RISCV: the machanism of available_harts may cause other harts boot failure

[Rick Chen]

Hi,

When I free-run a SMP system, I once hit a failure case where some
harts didn't boot to the kernel shell successfully.
However it can't be duplicated anymore even if I try many times.

But when I set a break during debugging with GDB, it can trigger the
failure case each time.
I think the mechanism of available_harts does not provide a method
that guarantees the success of the SMP system.
Maybe we shall think of a better way for the SMP booting or just remove it ?

Thread 8 hit Breakpoint 1, harts_early_init ()

(gdb) c
Continuing.
[Switching to Thread 7]

Thread 7 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 6]

Thread 6 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 5]

Thread 5 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 4]

Thread 4 hit Breakpoint 1, harts_early_init ()

(gdb)
Continuing.
[Switching to Thread 3]

Thread 3 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 2]

Thread 2 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 1]

Thread 1 hit Breakpoint 1, harts_early_init ()
(gdb)
Continuing.
[Switching to Thread 5]


Thread 5 hit Breakpoint 3, 0x0120 in ?? ()
(gdb) info threads
  Id   Target Id Frame
  1Thread 1 (hart 1) secondary_hart_loop () at arch/riscv/cpu/start.S:436
  2Thread 2 (hart 2) secondary_hart_loop () at arch/riscv/cpu/start.S:436
  3Thread 3 (hart 3) secondary_hart_loop () at arch/riscv/cpu/start.S:436
  4Thread 4 (hart 4) secondary_hart_loop () at arch/riscv/cpu/start.S:436
* 5Thread 5 (hart 5) 0x0120 in ?? ()
  6Thread 6 (hart 6) 0xb650 in ?? ()
  7Thread 7 (hart 7) 0xb650 in ?? ()
  8Thread 8 (hart 8) 0x5fa0 in ?? ()
(gdb) c
Continuing.



[0.175619] smp: Bringing up secondary CPUs ...
[1.230474] CPU1: failed to come online
[2.282349] CPU2: failed to come online
[3.334394] CPU3: failed to come online
[4.386783] CPU4: failed to come online
[4.427829] smp: Brought up 1 node, 4 CPUs


/root # cat /proc/cpuinfo
processor   : 0
hart: 4
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu : sv39

processor   : 5
hart: 5
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu : sv39

processor   : 6
hart: 6
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu : sv39

processor   : 7
hart: 7
isa : rv64i2p0m2p0a2p0c2p0xv5-1p1
mmu : sv39

/root #

Thanks,
Rick