[PATCH] mtd: sf: Set SF parameters as env variables

[Marek Vasut]

Set the SF page size, erase block size and total size as an environment
variable after "sf probe". This lets us discern boards with multiple
distinct SPI flash options and also e.g. set mtdparts accordingly.

Signed-off-by: Marek Vasut 
Cc: Jagan Teki 
Cc: Vignesh R 
---
 drivers/mtd/spi/spi-nor-core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index d5d905fa5a1..448653b9931 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -3829,8 +3830,11 @@ int spi_nor_scan(struct spi_nor *nor)
 #ifndef CONFIG_SPL_BUILD
printf("SF: Detected %s with page size ", nor->name);
print_size(nor->page_size, ", erase size ");
+   env_set_hex("sf_pagesize", nor->page_size);
print_size(nor->erase_size, ", total ");
+   env_set_hex("sf_erasesize", nor->erase_size);
print_size(nor->size, "");
+   env_set_hex("sf_size", nor->size);
puts("\n");
 #endif
 
-- 
2.33.0

[PATCH] dfu: dfu_sf: Add support for multiple flashes

[Marek Vasut]

Add dfu_alt_info option which allows specifying multiple SPI flashes
as an alt info. The syntax is as follows:

altname sf bus:cs[:speed[:mode]]

Example:
dfu_alt_info=qspi0 sf 0:0;qspi1 sf 0:1

Signed-off-by: Marek Vasut 
Cc: Lukasz Majewski 
---
 drivers/dfu/dfu_sf.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/dfu/dfu_sf.c b/drivers/dfu/dfu_sf.c
index b72493ced86..d246e1b21ff 100644
--- a/drivers/dfu/dfu_sf.c
+++ b/drivers/dfu/dfu_sf.c
@@ -168,22 +168,31 @@ static struct spi_flash *parse_dev(char *devstr)
 int dfu_fill_entity_sf(struct dfu_entity *dfu, char *devstr, char *s)
 {
char *st;
-   char *devstr_bkup = strdup(devstr);
-
-   dfu->data.sf.dev = parse_dev(devstr_bkup);
-   free(devstr_bkup);
-   if (!dfu->data.sf.dev)
-   return -ENODEV;
 
dfu->dev_type = DFU_DEV_SF;
dfu->max_buf_size = dfu->data.sf.dev->sector_size;
 
st = strsep(, " ");
if (!strcmp(st, "raw")) {
+   char *devstr_bkup = strdup(devstr);
+   dfu->data.sf.dev = parse_dev(devstr_bkup);
+   free(devstr_bkup);
+   if (!dfu->data.sf.dev)
+   return -ENODEV;
+
dfu->layout = DFU_RAW_ADDR;
dfu->data.sf.start = hextoul(s, );
s++;
dfu->data.sf.size = hextoul(s, );
+   } else if (!strcmp(st, "sf")) {
+   st = strsep(, " ");
+   dfu->data.sf.dev = parse_dev(st);
+   if (!dfu->data.sf.dev)
+   return -ENODEV;
+
+   dfu->layout = DFU_RAW_ADDR;
+   dfu->data.sf.start = 0;
+   dfu->data.sf.size = dfu->data.sf.dev->size;
} else if (CONFIG_IS_ENABLED(DFU_SF_PART) &&
   (!strcmp(st, "part") || !strcmp(st, "partubi"))) {
char mtd_id[32];
-- 
2.33.0

[PATCH] dfu: dfu_sf: Read the SPI flash in 16 MiB chunks

[Marek Vasut]

Not all SPI flashes and controllers can do continuous transfer longer
than 16 MiB, so perform the DFU read in 16 MiB chunks.

Signed-off-by: Marek Vasut 
Cc: Lukasz Majewski 
---
 drivers/dfu/dfu_sf.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/dfu/dfu_sf.c b/drivers/dfu/dfu_sf.c
index 7e64ab772f0..b72493ced86 100644
--- a/drivers/dfu/dfu_sf.c
+++ b/drivers/dfu/dfu_sf.c
@@ -24,8 +24,18 @@ static int dfu_get_medium_size_sf(struct dfu_entity *dfu, 
u64 *size)
 static int dfu_read_medium_sf(struct dfu_entity *dfu, u64 offset, void *buf,
  long *len)
 {
-   return spi_flash_read(dfu->data.sf.dev, dfu->data.sf.start + offset,
-   *len, buf);
+   long seglen = *len;
+   int ret;
+
+   if (seglen > (16 << 20))
+   seglen = (16 << 20);
+
+   ret = spi_flash_read(dfu->data.sf.dev, dfu->data.sf.start + offset,
+   seglen, buf);
+   if (!ret)
+   *len = seglen;
+
+   return ret;
 }
 
 static u64 find_sector(struct dfu_entity *dfu, u64 start, u64 offset)
-- 
2.33.0

[PATCH 7/8] arm: socfpga: vining: Enable DW I2C driver

[Marek Vasut]

The Designware I2C IP is used to communicate with I2C peripherals on
SoCFPGA, and required to access I2C EEPROM on this board. Enable it.

Signed-off-by: Marek Vasut 
Cc: Siew Chin Lim 
Cc: Simon Goldschmidt 
Cc: Tien Fong Chee 
---
 configs/socfpga_vining_fpga_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/socfpga_vining_fpga_defconfig 
b/configs/socfpga_vining_fpga_defconfig
index 4dcf4f7bf9e..cbdb897f19f 100644
--- a/configs/socfpga_vining_fpga_defconfig
+++ b/configs/socfpga_vining_fpga_defconfig
@@ -56,6 +56,7 @@ CONFIG_DFU_SF=y
 CONFIG_SYS_DFU_DATA_BUF_SIZE=0x100
 CONFIG_DWAPB_GPIO=y
 CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_DW=y
 CONFIG_LED_STATUS=y
 CONFIG_LED_STATUS_GPIO=y
 CONFIG_LED_STATUS0=y
-- 
2.33.0

[PATCH 6/8] arm: socfpga: vining: Fix UDC controller phandle in DT

[Marek Vasut]

The USB peripheral controller is the DWC2 controller 1, not 0.
Update the phandle to fix UDC support on this board.

Signed-off-by: Marek Vasut 
Cc: Siew Chin Lim 
Cc: Simon Goldschmidt 
Cc: Tien Fong Chee 
---
 arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi 
b/arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi
index 9e8be282005..fb05c31d87b 100644
--- a/arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi
+++ b/arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi
@@ -11,7 +11,7 @@
 /{
aliases {
spi0 = "/soc/spi@ff705000";
-   udc0 = 
+   udc0 = 
};
 };
 
-- 
2.33.0

[PATCH 8/8] arm: socfpga: vining: Let DWMAC configure PHY reset GPIO

[Marek Vasut]

The DM DWMAC driver is perfectly capable of configuring the ethernet
PHY reset GPIO, let the driver do it instead of doing it in the board
file.

Signed-off-by: Marek Vasut 
Cc: Siew Chin Lim 
Cc: Simon Goldschmidt 
Cc: Tien Fong Chee 
---
 board/softing/vining_fpga/socfpga.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/board/softing/vining_fpga/socfpga.c 
b/board/softing/vining_fpga/socfpga.c
index aaedf034504..22992273911 100644
--- a/board/softing/vining_fpga/socfpga.c
+++ b/board/softing/vining_fpga/socfpga.c
@@ -23,7 +23,6 @@ DECLARE_GLOBAL_DATA_PTR;
  */
 int board_late_init(void)
 {
-   const unsigned int phy_nrst_gpio = 0;
const unsigned int usb_nrst_gpio = 35;
int ret;
 
@@ -33,12 +32,6 @@ int board_late_init(void)
/* Address of boot parameters for ATAG (if ATAG is used) */
gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
 
-   ret = gpio_request(phy_nrst_gpio, "phy_nrst_gpio");
-   if (!ret)
-   gpio_direction_output(phy_nrst_gpio, 1);
-   else
-   printf("Cannot remove PHY from reset!\n");
-
ret = gpio_request(usb_nrst_gpio, "usb_nrst_gpio");
if (!ret)
gpio_direction_output(usb_nrst_gpio, 1);
-- 
2.33.0

[PATCH 5/8] arm: socfpga: vining: Un-disable WDT in DT

[Marek Vasut]

The WDT on this system should be enabled, make it so.

Signed-off-by: Marek Vasut 
Cc: Siew Chin Lim 
Cc: Simon Goldschmidt 
Cc: Tien Fong Chee 
---
 arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi 
b/arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi
index 2e4468e8d80..9e8be282005 100644
--- a/arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi
+++ b/arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi
@@ -15,10 +15,6 @@
};
 };
 
- {
-   status = "disabled";
-};
-
  {
status = "disabled";
 };
-- 
2.33.0

[PATCH 4/8] arm: socfpga: vining: Set default SPI NOR mode and frequency

[Marek Vasut]

The SPI NOR bus mode is 0 on this system, update it accordingly.
Increase frequency to 40 MHz and enable SFDP parsing, since the
flashes on this system support that and it is a huge performance
improvement.

Signed-off-by: Marek Vasut 
Cc: Siew Chin Lim 
Cc: Simon Goldschmidt 
Cc: Tien Fong Chee 
---
 configs/socfpga_vining_fpga_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/socfpga_vining_fpga_defconfig 
b/configs/socfpga_vining_fpga_defconfig
index 5d8970e57ca..4dcf4f7bf9e 100644
--- a/configs/socfpga_vining_fpga_defconfig
+++ b/configs/socfpga_vining_fpga_defconfig
@@ -74,6 +74,9 @@ CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=3
 CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS=70
 CONFIG_MMC_DW=y
 CONFIG_MTD=y
+CONFIG_SF_DEFAULT_MODE=0x0
+CONFIG_SF_DEFAULT_SPEED=4000
+CONFIG_SPI_FLASH_SFDP_SUPPORT=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
-- 
2.33.0

[PATCH 3/8] arm: socfpga: vining: Set USB gadget manufacturer to Softing with capital S

[Marek Vasut]

This was configured in downstream, so it is likely that most of the
custom software used around the device depends on it. Make upstream
compatible.

Signed-off-by: Marek Vasut 
Cc: Siew Chin Lim 
Cc: Simon Goldschmidt 
Cc: Tien Fong Chee 
---
 configs/socfpga_vining_fpga_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/socfpga_vining_fpga_defconfig 
b/configs/socfpga_vining_fpga_defconfig
index 452e5b48f3a..5d8970e57ca 100644
--- a/configs/socfpga_vining_fpga_defconfig
+++ b/configs/socfpga_vining_fpga_defconfig
@@ -91,7 +91,7 @@ CONFIG_DESIGNWARE_SPI=y
 CONFIG_USB=y
 CONFIG_USB_DWC2=y
 CONFIG_USB_GADGET=y
-CONFIG_USB_GADGET_MANUFACTURER="softing"
+CONFIG_USB_GADGET_MANUFACTURER="Softing"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0525
 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
 CONFIG_USB_GADGET_DWC2_OTG=y
-- 
2.33.0

[PATCH 2/8] arm: socfpga: vining: Increase environment size

[Marek Vasut]

Increase the environment size from 4k to 16k to prevent
environment from becoming full.

Signed-off-by: Marek Vasut 
Cc: Siew Chin Lim 
Cc: Simon Goldschmidt 
Cc: Tien Fong Chee 
---
 configs/socfpga_vining_fpga_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/socfpga_vining_fpga_defconfig 
b/configs/socfpga_vining_fpga_defconfig
index b418efbf895..452e5b48f3a 100644
--- a/configs/socfpga_vining_fpga_defconfig
+++ b/configs/socfpga_vining_fpga_defconfig
@@ -1,6 +1,6 @@
 CONFIG_ARM=y
 CONFIG_ARCH_SOCFPGA=y
-CONFIG_ENV_SIZE=0x2000
+CONFIG_ENV_SIZE=0x4000
 CONFIG_ENV_OFFSET=0x10
 CONFIG_ENV_SECT_SIZE=0x1
 CONFIG_DM_GPIO=y
-- 
2.33.0

[PATCH 1/8] arm: socfpga: vining: Drop meaningless comment

[Marek Vasut]

The comment is no longer meaningful due to DT conversion, drop it.

Signed-off-by: Marek Vasut 
Cc: Siew Chin Lim 
Cc: Simon Goldschmidt 
Cc: Tien Fong Chee 
---
 include/configs/socfpga_vining_fpga.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/configs/socfpga_vining_fpga.h 
b/include/configs/socfpga_vining_fpga.h
index 06976d804c7..38a77535893 100644
--- a/include/configs/socfpga_vining_fpga.h
+++ b/include/configs/socfpga_vining_fpga.h
@@ -17,8 +17,6 @@
 #define CONFIG_LOADADDR0x0100
 #define CONFIG_SYS_LOAD_ADDR   CONFIG_LOADADDR
 
-/* Ethernet on SoC (EMAC) */
-
 /* Extra Environment */
 #define CONFIG_HOSTNAME"socfpga_vining_fpga"
 
-- 
2.33.0

[PATCH] mtd: cqspi: Wait for transfer completion

[Marek Vasut]

Wait for the read/write transfer finish bit get actually cleared,
this does not happen immediately on at least SoCFPGA Gen5.

Signed-off-by: Marek Vasut 
Cc: Jagan Teki 
Cc: Vignesh R 
Cc: Pratyush Yadav 
---
 drivers/spi/cadence_qspi_apb.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 429ee335db6..2cdf4c9c9f8 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -858,6 +858,14 @@ cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_plat *plat,
writel(CQSPI_REG_INDIRECTRD_DONE,
   plat->regbase + CQSPI_REG_INDIRECTRD);
 
+   /* Check indirect done status */
+   ret = wait_for_bit_le32(plat->regbase + CQSPI_REG_INDIRECTRD,
+   CQSPI_REG_INDIRECTRD_DONE, 0, 10, 0);
+   if (ret) {
+   printf("Indirect read clear completion error (%i)\n", ret);
+   goto failrd;
+   }
+
return 0;
 
 failrd:
@@ -1012,6 +1020,15 @@ cadence_qspi_apb_indirect_write_execute(struct 
cadence_spi_plat *plat,
/* Clear indirect completion status */
writel(CQSPI_REG_INDIRECTWR_DONE,
   plat->regbase + CQSPI_REG_INDIRECTWR);
+
+   /* Check indirect done status */
+   ret = wait_for_bit_le32(plat->regbase + CQSPI_REG_INDIRECTWR,
+   CQSPI_REG_INDIRECTWR_DONE, 0, 10, 0);
+   if (ret) {
+   printf("Indirect write clear completion error (%i)\n", ret);
+   goto failwr;
+   }
+
if (bounce_buf)
free(bounce_buf);
return 0;
-- 
2.33.0

[PATCH] mtd: cqspi: Fix division by zero

[Marek Vasut]

Both dummy.nbytes and dummy.buswidth may be zero. By not checking
the later, it is possible to trigger division by zero and a crash.
This does happen with tiny SPI NOR framework in SPL. Fix this by
adding the check and returning zero dummy bytes in such a case.

Fixes: 38b0852b0ea ("spi: cadence-qspi: Add support for octal DTR flashes")
Signed-off-by: Marek Vasut 
Cc: Jagan Teki 
Cc: Vignesh R 
Cc: Pratyush Yadav 
---
 drivers/spi/cadence_qspi_apb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index c36a652211a..429ee335db6 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -219,6 +219,9 @@ static unsigned int cadence_qspi_calc_dummy(const struct 
spi_mem_op *op,
 {
unsigned int dummy_clk;
 
+   if (!op->dummy.nbytes || !op->dummy.buswidth)
+   return 0;
+
dummy_clk = op->dummy.nbytes * (8 / op->dummy.buswidth);
if (dtr)
dummy_clk /= 2;
-- 
2.33.0

[PATCH] mtd: spi-nor-ids: Reinstate Micron MT25QL02G

[Marek Vasut]

This ID disappeared in 5b66fdb29dc ("mtd: spi: Remove unused files"),
add the ID back, since the chip is used on devices supported by U-Boot.

Fixes: 5b66fdb29dc ("mtd: spi: Remove unused files")
Signed-off-by: Marek Vasut 
Cc: Horatiu Vultur 
Cc: Jagan Teki 
Cc: Simon Goldschmidt 
Cc: Stefan Roese 
Cc: Vignesh R 
---
 drivers/mtd/spi/spi-nor-ids.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 4aef1ddd6e2..6bf7c30a8e8 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -195,6 +195,7 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("n25q00a", 0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ INFO("mt25ql01g",   0x21ba20, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ INFO("mt25qu02g",   0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
+   { INFO("mt25ql02g",   0x20ba22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
 #ifdef CONFIG_SPI_FLASH_MT35XU
{ INFO("mt35xu512aba", 0x2c5b1a, 0,  128 * 1024,  512, USE_FSR | 
SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES | SPI_NOR_OCTAL_DTR_READ) },
 #endif /* CONFIG_SPI_FLASH_MT35XU */
-- 
2.33.0

[PATCH] ddr: altera: use KBUILD_BASENAME instead of __FILE__

[Marek Vasut]

The KBUILD_BASENAME contains just the name of the compiled module,
in this case 'sequencer', rather than a full path to the compiled
file. Use it to prevent pulling the full path into the U-Boot binary,
which is useless and annoying.

Signed-off-by: Marek Vasut 
Cc: Siew Chin Lim 
Cc: Simon Goldschmidt 
Cc: Tien Fong Chee 
---
 drivers/ddr/altera/sequencer.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c
index 6b9b2e90943..8a016f0628f 100644
--- a/drivers/ddr/altera/sequencer.c
+++ b/drivers/ddr/altera/sequencer.c
@@ -3714,7 +3714,7 @@ static void debug_mem_calibrate(struct socfpga_sdrseq 
*seq, int pass)
u32 debug_info;
 
if (pass) {
-   debug("%s: CALIBRATION PASSED\n", __FILE__);
+   debug(KBUILD_BASENAME ": CALIBRATION PASSED\n");
 
seq->gbl.fom_in /= 2;
seq->gbl.fom_out /= 2;
@@ -3733,7 +3733,7 @@ static void debug_mem_calibrate(struct socfpga_sdrseq 
*seq, int pass)
writel(debug_info, _mgr_cfg->cal_debug_info);
writel(PHY_MGR_CAL_SUCCESS, _mgr_cfg->cal_status);
} else {
-   debug("%s: CALIBRATION FAILED\n", __FILE__);
+   debug(KBUILD_BASENAME ": CALIBRATION FAILED\n");
 
debug_info = seq->gbl.error_stage;
debug_info |= seq->gbl.error_substage << 8;
@@ -3750,7 +3750,7 @@ static void debug_mem_calibrate(struct socfpga_sdrseq 
*seq, int pass)
writel(debug_info, _reg_file->failing_stage);
}
 
-   debug("%s: Calibration complete\n", __FILE__);
+   debug(KBUILD_BASENAME ": Calibration complete\n");
 }
 
 /**
@@ -3934,7 +3934,7 @@ int sdram_calibration_full(struct socfpga_sdr *sdr)
 
initialize_tracking();
 
-   debug("%s: Preparing to start memory calibration\n", __FILE__);
+   debug(KBUILD_BASENAME ": Preparing to start memory calibration\n");
 
debug("%s:%d\n", __func__, __LINE__);
debug_cond(DLEVEL >= 1,
-- 
2.33.0

[PATCH] bootstage: Add SPL support

[Marek Vasut]

Allow usage of the bootstage facilities in SPL.

Signed-off-by: Marek Vasut 
Cc: Simon Glass 
---
 common/Kconfig.boot | 9 +
 include/bootstage.h | 2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index 902a5b8fbea..c230b5c76e4 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -667,6 +667,15 @@ config SHOW_BOOT_PROGRESS
  -150  common/cmd_nand.c   Incorrect FIT image format
  151   common/cmd_nand.c   FIT image format OK
 
+config SPL_SHOW_BOOT_PROGRESS
+   bool "Show boot progress in a board-specific manner"
+   depends on SPL
+   help
+ Defining this option allows to add some board-specific code (calling
+ a user-provided function show_boot_progress(int) that enables you to
+ show the system's boot progress on some display (for example, some
+ LEDs) on your board. For details see SHOW_BOOT_PROGRESS.
+
 endmenu
 
 menu "Boot media"
diff --git a/include/bootstage.h b/include/bootstage.h
index f837a387c8c..8d1989ac0e5 100644
--- a/include/bootstage.h
+++ b/include/bootstage.h
@@ -220,7 +220,7 @@ enum bootstage_id {
  */
 ulong timer_get_boot_us(void);
 
-#if defined(USE_HOSTCC) || !CONFIG_IS_ENABLED(BOOTSTAGE)
+#if defined(USE_HOSTCC) || !CONFIG_IS_ENABLED(SHOW_BOOT_PROGRESS)
 #define show_boot_progress(val) do {} while (0)
 #else
 /**
-- 
2.33.0

[PATCH] efi_loader: Set EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT again in efi_net_receive()

[Masami Hiramatsu]

From: Kazuhiko Sakamoto 

Since 'this->int_status' is cleared by efi_net_get_status(), if user
does wait_for_event(wait_for_packet) and efi_net_get_status() loop
and there are several received packets on the buffer, the second
efi_net_get_status() does not return EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT
even if the 'wait_for_packet' is ready.

This happens on "efiboot selftest" with noisy network.
(The network device can receive both of other packets and dhcp discover
 packet in a short time.)

Set EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT again when we found any
packet still on the receive buffer.

Signed-off-by: Kazuhiko Sakamoto 
Signed-off-by: Masami Hiramatsu 
---
 lib/efi_loader/efi_net.c |   13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c
index 69276b275d..9ca1e0c354 100644
--- a/lib/efi_loader/efi_net.c
+++ b/lib/efi_loader/efi_net.c
@@ -640,10 +640,19 @@ static efi_status_t EFIAPI efi_net_receive
*buffer_size = receive_lengths[rx_packet_idx];
rx_packet_idx = (rx_packet_idx + 1) % ETH_PACKETS_BATCH_RECV;
rx_packet_num--;
-   if (rx_packet_num)
+   if (rx_packet_num) {
+   /*
+* Since 'this->int_status' is cleared by efi_net_get_status(),
+* if user does wait_for_event(wait_for_packet) and
+* efi_net_get_status() again, 
EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT
+* is not set even if 'wait_for_packet' is ready.
+* Set EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT again here.
+*/
+   this->int_status |= EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT;
wait_for_packet->is_signaled = true;
-   else
+   } else {
this->int_status &= ~EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT;
+   }
 out:
return EFI_EXIT(ret);
 }

Re: Pull request: u-boot-sunxi/master for v2021.10

[Tom Rini]

On Tue, Sep 14, 2021 at 12:27:28AM +0100, Andre Przywara wrote:

> Hi Tom,
> 
> please pull the master branch from u-boot-sunxi, containing a fix for
> U-Boot 2021.10 to bring back MMC boot on older boards.
> 
> Build-tested on all 158 sunxi boards, boot tested on some of them.
> 
> Thanks,
> Andre
> 
> ==
> The following changes since commit 7958292f5ffa4ecdaaf4c73c6df28006051db6e0:
> 
>   Merge tag 'mmc-2021-9-13' of 
> https://source.denx.de/u-boot/custodians/u-boot-mmc (2021-09-13 08:31:41 
> -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master
> 
> for you to fetch changes up to 0b508ca821d383b2fd68f4b581cf606e329fff36:
> 
>   sunxi: mmc: A20: Fix MMC optimisation (2021-09-14 00:02:10 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 31/32] pci: Drop DM_PCI

[Tom Rini]

On Sun, Aug 01, 2021 at 06:54:44PM -0600, Simon Glass wrote:

> This option has not effect now. Drop it, using PCI instead where needed.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 30/32] pci: Drop PCI_INDIRECT_BRIDGE

[Tom Rini]

On Sun, Aug 01, 2021 at 06:54:43PM -0600, Simon Glass wrote:

> This does not work with driver model so can be removed.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 21/32] net: Drop DM_PCI check from designware driver

[Tom Rini]

On Sun, Aug 01, 2021 at 06:54:34PM -0600, Simon Glass wrote:

> We don't need this check anymore since when PCI is enabled, driver model
> is always used.
> 
> Drop it.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 12/32] pci: acpi: Drop DM_PCI check from ahci

[Tom Rini]

On Sun, Aug 01, 2021 at 06:54:25PM -0600, Simon Glass wrote:

> We don't need these checks anymore since when PCI is enabled, driver model
> is always used.
> 
> Drop them.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 05/32] pci: Drop DM_PCI check from fdtdec

[Tom Rini]

On Sun, Aug 01, 2021 at 06:54:18PM -0600, Simon Glass wrote:

> We don't need this check anymore since when PCI is enabled, driver model
> is always used.
> 
> Sadly this doesn't work with nds32 for some reason to do with the
> toolchain. Add a work-around for that.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 03/32] pci: Drop old code from header file

[Tom Rini]

On Sun, Aug 01, 2021 at 06:54:16PM -0600, Simon Glass wrote:

> We don't need this code anymore since when PCI is enabled, driver model is
> always used.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 02/32] ppc: Remove UCP1020 board

[Tom Rini]

On Sun, Aug 01, 2021 at 06:54:15PM -0600, Simon Glass wrote:

> This board has not been converted to CONFIG_DM_PCI by the deadline.
> Remove it.
> 
> Note that we have to add CONFIG_SPIFLASH to scripts/config_whitelist.txt
> because it's not really migrated at this point.
> 
> Acked-by: Michael Durrant 
> Acked-by: Oleksandr Zhadan 
> Acked-by: Oleksandr Zhadan and Michael Durrant 
> 
> Signed-off-by: Simon Glass 
> [trini: Handle CONFIG_SPIFLASH differently and
> delete Kconfig file]
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 3/3] sunxi: gpio: Remove bank-specific size macros

[Andre Przywara]

On Sat, 11 Sep 2021 16:50:49 -0500
Samuel Holland  wrote:

> Since the beginning, all banks have had space for 32 pins, even when
> not all pins were implemented. Let's use a single constant for the GPIO
> bank size here, like the GPIO driver is already doing.

Yeah, I always found some code in there a bit over the top, thanks for
cleaning this up.

> Signed-off-by: Samuel Holland 

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
> 
>  arch/arm/include/asm/arch-sunxi/gpio.h | 14 ++
>  drivers/gpio/sunxi_gpio.c  |  2 --
>  2 files changed, 2 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h 
> b/arch/arm/include/asm/arch-sunxi/gpio.h
> index c93c051a19f..cd5e85988b1 100644
> --- a/arch/arm/include/asm/arch-sunxi/gpio.h
> +++ b/arch/arm/include/asm/arch-sunxi/gpio.h
> @@ -93,20 +93,10 @@ struct sunxi_gpio_reg {
>  #define GPIO_PULL_OFFSET(pin)pin) & 0x1f) & 0xf) << 1)
>  
>  /* GPIO bank sizes */
> -#define SUNXI_GPIO_A_NR  32
> -#define SUNXI_GPIO_B_NR  32
> -#define SUNXI_GPIO_C_NR  32
> -#define SUNXI_GPIO_D_NR  32
> -#define SUNXI_GPIO_E_NR  32
> -#define SUNXI_GPIO_F_NR  32
> -#define SUNXI_GPIO_G_NR  32
> -#define SUNXI_GPIO_H_NR  32
> -#define SUNXI_GPIO_I_NR  32
> -#define SUNXI_GPIO_L_NR  32
> -#define SUNXI_GPIO_M_NR  32
> +#define SUNXI_GPIOS_PER_BANK 32
>  
>  #define SUNXI_GPIO_NEXT(__gpio) \
> - ((__gpio##_START) + (__gpio##_NR) + 0)
> + ((__gpio##_START) + SUNXI_GPIOS_PER_BANK)
>  
>  enum sunxi_gpio_number {
>   SUNXI_GPIO_A_START = 0,
> diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
> index 7ce3ef73b46..ed26eb011f4 100644
> --- a/drivers/gpio/sunxi_gpio.c
> +++ b/drivers/gpio/sunxi_gpio.c
> @@ -19,8 +19,6 @@
>  #include 
>  #include 
>  
> -#define SUNXI_GPIOS_PER_BANK SUNXI_GPIO_A_NR
> -
>  struct sunxi_gpio_plat {
>   struct sunxi_gpio *regs;
>   const char *bank_name;  /* Name of bank, e.g. "B" */

Re: [PATCH 2/3] sunxi: gpio: Remove name_to_gpio macro

[Andre Przywara]

On Sat, 11 Sep 2021 16:50:48 -0500
Samuel Holland  wrote:

> This clarifies which callers must be updated to complete the DM_GPIO
> conversion.
> 
> The only remaining caller of name_to_gpio in generic code is inside the
> !DM_GPIO block in cmd/gpio.c. DM_GPIO is always selected on sunxi, so
> that code cannot be reached. And after this commit, there are only two
> remaining implementations of name_to_gpio.
> 
> Signed-off-by: Samuel Holland 

Compile tested on all sunxi boards.

Acked-by: Andre Przywara 

Cheers,
Andre

> ---
> 
>  arch/arm/include/asm/arch-sunxi/gpio.h |  1 -
>  drivers/spi/spi-sunxi.c|  2 +-
>  drivers/video/Kconfig  | 10 +-
>  drivers/video/hitachi_tx18d42vm_lcd.c  |  6 +++---
>  drivers/video/sunxi/sunxi_display.c| 10 +-
>  5 files changed, 14 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h 
> b/arch/arm/include/asm/arch-sunxi/gpio.h
> index 2969a530ae1..c93c051a19f 100644
> --- a/arch/arm/include/asm/arch-sunxi/gpio.h
> +++ b/arch/arm/include/asm/arch-sunxi/gpio.h
> @@ -244,7 +244,6 @@ int sunxi_gpio_set_drv(u32 pin, u32 val);
>  int sunxi_gpio_set_pull(u32 pin, u32 val);
>  int sunxi_name_to_gpio_bank(const char *name);
>  int sunxi_name_to_gpio(const char *name);
> -#define name_to_gpio(name) sunxi_name_to_gpio(name)
>  
>  #if !defined CONFIG_SPL_BUILD && defined CONFIG_AXP_GPIO
>  int axp_gpio_init(void);
> diff --git a/drivers/spi/spi-sunxi.c b/drivers/spi/spi-sunxi.c
> index 4ca5d3a93ac..bc2f544e863 100644
> --- a/drivers/spi/spi-sunxi.c
> +++ b/drivers/spi/spi-sunxi.c
> @@ -245,7 +245,7 @@ static int sun4i_spi_parse_pins(struct udevice *dev)
>   break;
>   }
>  
> - pin = name_to_gpio(pin_name);
> + pin = sunxi_name_to_gpio(pin_name);
>   if (pin < 0)
>   break;
>  
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index b1f8a9c1e62..b0c52a500df 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -452,7 +452,7 @@ config VIDEO_LCD_SSD2828_RESET
>   default ""
>   ---help---
>   The reset pin of SSD2828 chip. This takes a string in the format
> - understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H.
> + understood by 'sunxi_name_to_gpio' function, e.g. PH1 for pin 1 of port 
> H.
>  
>  config VIDEO_LCD_TDO_TL070WSH30
>   bool "TDO TL070WSH30 DSI LCD panel support"
> @@ -477,7 +477,7 @@ config VIDEO_LCD_SPI_CS
>   This is one of the SPI communication pins, involved in setting up a
>   working LCD configuration. The exact role of SPI may differ for
>   different hardware setups. The option takes a string in the format
> - understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H.
> + understood by 'sunxi_name_to_gpio' function, e.g. PH1 for pin 1 of port 
> H.
>  
>  config VIDEO_LCD_SPI_SCLK
>   string "SPI SCLK pin for LCD related config job"
> @@ -487,7 +487,7 @@ config VIDEO_LCD_SPI_SCLK
>   This is one of the SPI communication pins, involved in setting up a
>   working LCD configuration. The exact role of SPI may differ for
>   different hardware setups. The option takes a string in the format
> - understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H.
> + understood by 'sunxi_name_to_gpio' function, e.g. PH1 for pin 1 of port 
> H.
>  
>  config VIDEO_LCD_SPI_MOSI
>   string "SPI MOSI pin for LCD related config job"
> @@ -497,7 +497,7 @@ config VIDEO_LCD_SPI_MOSI
>   This is one of the SPI communication pins, involved in setting up a
>   working LCD configuration. The exact role of SPI may differ for
>   different hardware setups. The option takes a string in the format
> - understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H.
> + understood by 'sunxi_name_to_gpio' function, e.g. PH1 for pin 1 of port 
> H.
>  
>  config VIDEO_LCD_SPI_MISO
>   string "SPI MISO pin for LCD related config job (optional)"
> @@ -509,7 +509,7 @@ config VIDEO_LCD_SPI_MISO
>   different hardware setups. If wired up, this pin may provide additional
>   useful functionality. Such as bi-directional communication with the
>   hardware and LCD panel id retrieval (if the panel can report it). The
> - option takes a string in the format understood by 'name_to_gpio'
> + option takes a string in the format understood by 'sunxi_name_to_gpio'
>   function, e.g. PH1 for pin 1 of port H.
>  
>  source "drivers/video/meson/Kconfig"
> diff --git a/drivers/video/hitachi_tx18d42vm_lcd.c 
> b/drivers/video/hitachi_tx18d42vm_lcd.c
> index c6c8df6a96e..87c4d27438a 100644
> --- a/drivers/video/hitachi_tx18d42vm_lcd.c
> +++ b/drivers/video/hitachi_tx18d42vm_lcd.c
> @@ -49,9 +49,9 @@ int hitachi_tx18d42vm_init(void)
>   };
>   int i, cs, clk, mosi, ret = 0;
>  
> - cs = 

Re: [PATCH 1/3] sunxi: Clean up inclusions of asm/arch/gpio.h

[Andre Przywara]

On Sat, 11 Sep 2021 16:50:47 -0500
Samuel Holland  wrote:

> As part of migrating to DM_GPIO and DM_PINCTRL, eventually we will
> remove the asm/arch/gpio.h header. In preparation, clean up the various
> files that include it.
> 
> Some files did not contain any GPIO code at all, so this header was
> completely unused.
> 
> A few files contained only legacy platform-specific GPIO code for
> setting up pin muxes. They were left unchanged, as that code will be
> completely removed by the DM_PINCTRL migration.
> 
> The remaining files contain some combination of DM_GPIO and legacy GPIO
> code. For those, switch to including asm/gpio.h (if it wasn't included
> already). Right now, this header provides both sets of functions,
> because ARCH_SUNXI selects GPIO_EXTRA_HEADER. This will still be the
> right header to include once the DM_GPIO migration is complete and
> GPIO_EXTRA_HEADER is no longer needed.

Nice cleanup, and it survived a buildman sunxi (all 158 boards).

> Signed-off-by: Samuel Holland 

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
> 
>  arch/arm/mach-sunxi/board.c | 1 -
>  arch/arm/mach-sunxi/clock.c | 1 -
>  arch/arm/mach-sunxi/clock_sun4i.c   | 1 -
>  board/sunxi/board.c | 1 -
>  board/sunxi/gmac.c  | 1 -
>  drivers/gpio/axp_gpio.c | 1 -
>  drivers/gpio/sunxi_gpio.c   | 1 -
>  drivers/mmc/sunxi_mmc.c | 3 +--
>  drivers/net/sun8i_emac.c| 5 +
>  drivers/power/axp809.c  | 1 -
>  drivers/power/axp818.c  | 1 -
>  drivers/usb/musb-new/sunxi.c| 2 --
>  drivers/video/sunxi/sunxi_display.c | 1 -
>  drivers/video/sunxi/sunxi_lcd.c | 1 -
>  14 files changed, 2 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index d9b04f75fc4..373cb56db49 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -21,7 +21,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/arm/mach-sunxi/clock.c b/arch/arm/mach-sunxi/clock.c
> index f591affebf7..de7e8752988 100644
> --- a/arch/arm/mach-sunxi/clock.c
> +++ b/arch/arm/mach-sunxi/clock.c
> @@ -10,7 +10,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/arm/mach-sunxi/clock_sun4i.c 
> b/arch/arm/mach-sunxi/clock_sun4i.c
> index 57ee018eaa2..471609764d2 100644
> --- a/arch/arm/mach-sunxi/clock_sun4i.c
> +++ b/arch/arm/mach-sunxi/clock_sun4i.c
> @@ -12,7 +12,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  #ifdef CONFIG_SPL_BUILD
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 2b7d655678d..dcd7f0b4375 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -25,7 +25,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/board/sunxi/gmac.c b/board/sunxi/gmac.c
> index d8fdf7728e0..1fa54ed72de 100644
> --- a/board/sunxi/gmac.c
> +++ b/board/sunxi/gmac.c
> @@ -4,7 +4,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  void eth_init_board(void)
>  {
> diff --git a/drivers/gpio/axp_gpio.c b/drivers/gpio/axp_gpio.c
> index 73058cf40b4..35585dc8ac9 100644
> --- a/drivers/gpio/axp_gpio.c
> +++ b/drivers/gpio/axp_gpio.c
> @@ -6,7 +6,6 @@
>   */
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
> index 24cb604e3e3..7ce3ef73b46 100644
> --- a/drivers/gpio/sunxi_gpio.c
> +++ b/drivers/gpio/sunxi_gpio.c
> @@ -14,7 +14,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> index 178b8cf106d..c62b5f5a6f9 100644
> --- a/drivers/mmc/sunxi_mmc.c
> +++ b/drivers/mmc/sunxi_mmc.c
> @@ -15,12 +15,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
> -#include 
>  #include 
>  
>  #ifndef CCM_MMC_CTRL_MODE_SEL_NEW
> diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
> index d7553fe1634..46786d9f764 100644
> --- a/drivers/net/sun8i_emac.c
> +++ b/drivers/net/sun8i_emac.c
> @@ -14,9 +14,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -31,9 +31,6 @@
>  #include 
>  #include 
>  #include 
> -#if CONFIG_IS_ENABLED(DM_GPIO)
> -#include 
> -#endif
>  
>  #define MDIO_CMD_MII_BUSYBIT(0)
>  #define MDIO_CMD_MII_WRITE   BIT(1)
> diff --git a/drivers/power/axp809.c b/drivers/power/axp809.c
> index 6323492b66d..0396502cdb5 100644
> --- a/drivers/power/axp809.c
> +++ b/drivers/power/axp809.c
> @@ -13,7 +13,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/power/axp818.c b/drivers/power/axp818.c
> 

Pull request: u-boot-sunxi/master for v2021.10

[Andre Przywara]

Hi Tom,

please pull the master branch from u-boot-sunxi, containing a fix for
U-Boot 2021.10 to bring back MMC boot on older boards.

Build-tested on all 158 sunxi boards, boot tested on some of them.

Thanks,
Andre

==
The following changes since commit 7958292f5ffa4ecdaaf4c73c6df28006051db6e0:

  Merge tag 'mmc-2021-9-13' of 
https://source.denx.de/u-boot/custodians/u-boot-mmc (2021-09-13 08:31:41 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master

for you to fetch changes up to 0b508ca821d383b2fd68f4b581cf606e329fff36:

  sunxi: mmc: A20: Fix MMC optimisation (2021-09-14 00:02:10 +0100)


Andre Przywara (1):
  sunxi: mmc: A20: Fix MMC optimisation

 drivers/mmc/sunxi_mmc.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

Re: [PATCH 5/5] serial: Rework CONFIG_SYS_BAUDRATE_TABLE

[Tom Rini]

On Mon, Sep 13, 2021 at 05:03:13PM -0500, Alex G. wrote:

[snip]
> Suggestion II: Define the Kconfig SYS_BAUDRATE_TABLE table to a C array,
> like 'default "{ 300, 420, 690}" ' and forego the #ifdefs in serial.h

Oh!  And FWIW, I don't _think_ this works.  I'd be quite happy to be
proven wrong, but there's not a useful Kconfig type here.  If we use
"string" and put in "{ 115200 }", we end up with:
static const unsigned long baudrate_table[] = "{ 115200 }";
which isn't what we want.  We'd need something clever next to turn a
string in to something we can use.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 5/5] serial: Rework CONFIG_SYS_BAUDRATE_TABLE

[Tom Rini]

On Mon, Sep 13, 2021 at 05:03:13PM -0500, Alex G. wrote:
> 
> 
> On 9/13/21 4:24 PM, Tom Rini wrote:
> > In order to move CONFIG_SYS_BAUDRATE_TABLE to Kconfig, we need to rework
> > the logic a bit.  Rename the users of CONFIG_SYS_BAUDRATE_TABLE to
> > SYS_BAUDRATE_TABLE.  Introduce a series of CONFIG_BAUDRATE_TABLE_...
> > that include some number of baud rates.  These match all existing users.
> > The help for each entry specifies what the exact table is, for a given
> > option.  Define what SYS_BAUDRATE_TABLE will be in include/serial.h now.
> > 
> > Signed-off-by: Tom Rini 
> > ---
> 
> > diff --git a/include/serial.h b/include/serial.h
> > index 6d1e62c6770c..150644c4c3d4 100644
> > --- a/include/serial.h
> > +++ b/include/serial.h
> > @@ -3,6 +3,42 @@
> >   #include 
> > +#if defined(CONFIG_BAUDRATE_TABLE_300_TO_38400_115200)
> > +#define SYS_BAUDRATE_TABLE { 300, 600, 1200, 2400, 4800, 9600, 19200, \
> > + 38400, 115200 }
> > +#elif defined(CONFIG_BAUDRATE_TABLE_300_TO_115200)
> > +#define SYS_BAUDRATE_TABLE { 300, 600, 1200, 2400, 4800, 9600, 19200, \
> > + 38400, 57600, 115200 }
> > +#elif defined(CONFIG_BAUDRATE_TABLE_300_TO_230400)
> > +#define SYS_BAUDRATE_TABLE { 300, 600, 1200, 2400, 4800, 9600, 19200, \
> > + 38400, 57600, 115200, 230400 }
> > +#elif defined(CONFIG_BAUDRATE_TABLE_300_TO_600)
> > +#define SYS_BAUDRATE_TABLE { 300, 600, 1200, 1800, 2400, 4800, 9600, \
> > + 19200, 38400, 57600, 115200, 230400, \
> > + 460800, 50, 576000, 921600, 100, \
> > + 1152000, 150, 200, 250, \
> > + 300, 350, 400, 450, \
> > + 500, 550, 600 }
> > +#elif defined(CONFIG_BAUDRATE_TABLE_4800_TO_115200)
> > +#define SYS_BAUDRATE_TABLE { 4800, 9600, 19200, 38400, 57600, 115200 }
> > +#elif defined(CONFIG_BAUDRATE_TABLE_9600_TO_115200)
> > +#define SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 }
> > +#elif defined(CONFIG_BAUDRATE_TABLE_9600_TO_230400)
> > +#define SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200, 230400 }
> > +#elif defined(CONFIG_BAUDRATE_TABLE_9600_TO_460800)
> > +#define SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200, 230400, 
> > 460800 }
> > +#elif defined(CONFIG_BAUDRATE_TABLE_9600_TO_921600)
> > +#define SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200, 230400, \
> > + 460800, 921600 }
> > +#elif defined(CONFIG_BAUDRATE_TABLE_9600_TO_230400_50_150)
> > +#define SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200, 230400, \
> > + 50, 150 }
> > +#elif defined(CONFIG_BAUDRATE_TABLE_38400_115200_ONLY)
> > +#define SYS_BAUDRATE_TABLE { 38400, 115200 }
> > +#elif defined(CONFIG_BAUDRATE_TABLE_115200_ONLY)
> > +#define SYS_BAUDRATE_TABLE { 115200 }
> > +#endif
> > +
> >   struct serial_device {
> > /* enough bytes to match alignment of following func pointer */
> > charname[16];
> 
> 
> This opens the gates to #ifdefing the heck out of serial.h. What happens to
> my board that goes from 300 to 200?
>  * We need a new Kconfig and new ifdef
> What happens to my other board that goes from 300 to 250?
>  * We need a new Kconfig and new ifdef
> The pattern doesn't look promising.

This reminds me I was tempted to do a cover letter, but didn't.  What
happens is I tell you no.  Most boards are using the standard table of
common rates from 9600 to 115200.  A nice follow-up would be to change
every board with a special case that's not above 115200 to just use the
normal table.  Everyone else?  There's the maximal table.  That's it.
That's even come in fairly recently, for mvebu platforms.

> I actually think this change can make the situation worse. We trade having
> an antiquated and inconvenient SYS_BAUDRATE_TABLE for one Kconfig per each
> possible baudrate combination. How does this make sense?

I'm going, as much as possible, for migrating the current situation.
There's many places things could be cleaner, but "we'll clean this up
and then migrate ..." is why we're so very very far behind where I hoped
to be.

> I've seen situations were SPL boots with 2Mbaud and executes succesfully,
> u-boot starts up with 2Mbaud just fine. few lines later, u-boot,
> downswitches to 115200 because CONFIG_SYS_BAUDRATE_TABLE says so.

Well, the table and CONFIG_BAUDRATE.

> Suggestion I: Can we have a MIN/MAX value for baudrates, and have the code
> work from there ?
> 
> Suggestion II: Define the Kconfig SYS_BAUDRATE_TABLE table to a C array,
> like 'default "{ 300, 420, 690}" ' and forego the #ifdefs in serial.h
> 
> Suggestion III: Get rid of the logic that says "baudrate must be one of
> these predefined values" and let the serial driver return -ENOBUENO or
> -EINVAL if the hardware really can't do that baudrate. 

Re: [PATCH 5/5] serial: Rework CONFIG_SYS_BAUDRATE_TABLE

[Alex G.]

On 9/13/21 4:24 PM, Tom Rini wrote:

In order to move CONFIG_SYS_BAUDRATE_TABLE to Kconfig, we need to rework
the logic a bit.  Rename the users of CONFIG_SYS_BAUDRATE_TABLE to
SYS_BAUDRATE_TABLE.  Introduce a series of CONFIG_BAUDRATE_TABLE_...
that include some number of baud rates.  These match all existing users.
The help for each entry specifies what the exact table is, for a given
option.  Define what SYS_BAUDRATE_TABLE will be in include/serial.h now.

Signed-off-by: Tom Rini 
---



diff --git a/include/serial.h b/include/serial.h
index 6d1e62c6770c..150644c4c3d4 100644
--- a/include/serial.h
+++ b/include/serial.h
@@ -3,6 +3,42 @@
  
  #include 
  
+#if defined(CONFIG_BAUDRATE_TABLE_300_TO_38400_115200)

+#define SYS_BAUDRATE_TABLE { 300, 600, 1200, 2400, 4800, 9600, 19200, \
+ 38400, 115200 }
+#elif defined(CONFIG_BAUDRATE_TABLE_300_TO_115200)
+#define SYS_BAUDRATE_TABLE { 300, 600, 1200, 2400, 4800, 9600, 19200, \
+ 38400, 57600, 115200 }
+#elif defined(CONFIG_BAUDRATE_TABLE_300_TO_230400)
+#define SYS_BAUDRATE_TABLE { 300, 600, 1200, 2400, 4800, 9600, 19200, \
+ 38400, 57600, 115200, 230400 }
+#elif defined(CONFIG_BAUDRATE_TABLE_300_TO_600)
+#define SYS_BAUDRATE_TABLE { 300, 600, 1200, 1800, 2400, 4800, 9600, \
+ 19200, 38400, 57600, 115200, 230400, \
+ 460800, 50, 576000, 921600, 100, \
+ 1152000, 150, 200, 250, \
+ 300, 350, 400, 450, \
+ 500, 550, 600 }
+#elif defined(CONFIG_BAUDRATE_TABLE_4800_TO_115200)
+#define SYS_BAUDRATE_TABLE { 4800, 9600, 19200, 38400, 57600, 115200 }
+#elif defined(CONFIG_BAUDRATE_TABLE_9600_TO_115200)
+#define SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 }
+#elif defined(CONFIG_BAUDRATE_TABLE_9600_TO_230400)
+#define SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200, 230400 }
+#elif defined(CONFIG_BAUDRATE_TABLE_9600_TO_460800)
+#define SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200, 230400, 
460800 }
+#elif defined(CONFIG_BAUDRATE_TABLE_9600_TO_921600)
+#define SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200, 230400, \
+ 460800, 921600 }
+#elif defined(CONFIG_BAUDRATE_TABLE_9600_TO_230400_50_150)
+#define SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200, 230400, \
+ 50, 150 }
+#elif defined(CONFIG_BAUDRATE_TABLE_38400_115200_ONLY)
+#define SYS_BAUDRATE_TABLE { 38400, 115200 }
+#elif defined(CONFIG_BAUDRATE_TABLE_115200_ONLY)
+#define SYS_BAUDRATE_TABLE { 115200 }
+#endif
+
  struct serial_device {
/* enough bytes to match alignment of following func pointer */
charname[16];




This opens the gates to #ifdefing the heck out of serial.h. What happens 
to my board that goes from 300 to 200?

 * We need a new Kconfig and new ifdef
What happens to my other board that goes from 300 to 250?
 * We need a new Kconfig and new ifdef
The pattern doesn't look promising.

I actually think this change can make the situation worse. We trade 
having an antiquated and inconvenient SYS_BAUDRATE_TABLE for one Kconfig 
per each possible baudrate combination. How does this make sense?


I've seen situations were SPL boots with 2Mbaud and executes 
succesfully, u-boot starts up with 2Mbaud just fine. few lines later, 
u-boot, downswitches to 115200 because CONFIG_SYS_BAUDRATE_TABLE says so.


Suggestion I: Can we have a MIN/MAX value for baudrates, and have the 
code work from there ?


Suggestion II: Define the Kconfig SYS_BAUDRATE_TABLE table to a C array, 
like 'default "{ 300, 420, 690}" ' and forego the #ifdefs in serial.h


Suggestion III: Get rid of the logic that says "baudrate must be one of 
these predefined values" and let the serial driver return -ENOBUENO or 
-EINVAL if the hardware really can't do that baudrate. Most UARTs 
nowadays can do a wide range of values, and the baudrate table doesn't 
model that very well. Combine this with a CONFIG_MAX_BAUDRATE so that 
boards with shitty RS232 converters can set a safe upper limit -- and 
make sure CONFIG_BAUDRATE also enforces this.


There's a lot of unrealized potential here.

Alex

Re: [PATCH] mmc: fsl_esdhc: remove 1ms sleep in esdhc_send_cmd_common()

[Jaehoon Chung]

Hi,

On 9/10/21 6:20 PM, Michael Walle wrote:
> Since the beginning of this driver which was initially for the MPC8379
> and MPC8536 SoCs, there is this spurious 1ms delay. According to the
> comment it should actually be only 8 clock cycles. Esp. during EFI block
> transfers, this 1ms add up to a significant delay and slows down EFI
> boot.
> 
> I couldn't find any mention in the MPC8536 that there should be a delay
> of 8 clock cycles between commands. The SD card specification mentions that
> the clock has to be left enabled for 8 cycles after a command or
> response. But I don't see how this delay will help with this.
> 
> Go ahead and just remove it. If there will ever be any regression we can
> introduce a compile time flag, but for now I'd like to keep it simple.
> 
> In the split off imx driver this delay was also removed in commit
> 9098682200e6 ("mmc: fsl_esdhc_imx: remove the 1ms delay before sending
> command").
> 
> Signed-off-by: Michael Walle 


If someone can test with this patch, I think that it's more better.
But i don't have any objection to apply this patch.

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
>  drivers/mmc/fsl_esdhc.c | 7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index 1d98fa65c4..ebb307e950 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -361,13 +361,6 @@ static int esdhc_send_cmd_common(struct fsl_esdhc_priv 
> *priv, struct mmc *mmc,
>   while (esdhc_read32(>prsstat) & PRSSTAT_DLA)
>   ;
>  
> - /* Wait at least 8 SD clock cycles before the next command */
> - /*
> -  * Note: This is way more than 8 cycles, but 1ms seems to
> -  * resolve timing issues with some cards
> -  */
> - udelay(1000);
> -
>   /* Set up for a data transfer if we have one */
>   if (data) {
>   err = esdhc_setup_data(priv, mmc, data);
> 

[PATCH 5/5] serial: Rework CONFIG_SYS_BAUDRATE_TABLE

[Tom Rini]

In order to move CONFIG_SYS_BAUDRATE_TABLE to Kconfig, we need to rework
the logic a bit.  Rename the users of CONFIG_SYS_BAUDRATE_TABLE to
SYS_BAUDRATE_TABLE.  Introduce a series of CONFIG_BAUDRATE_TABLE_...
that include some number of baud rates.  These match all existing users.
The help for each entry specifies what the exact table is, for a given
option.  Define what SYS_BAUDRATE_TABLE will be in include/serial.h now.

Signed-off-by: Tom Rini 
---
 README|  3 -
 arch/arm/include/asm/arch-lpc32xx/config.h|  3 -
 configs/MPC8349EMDS_PCI64_defconfig   |  1 +
 configs/MPC8349EMDS_SDRAM_defconfig   |  1 +
 configs/MPC8349EMDS_SLAVE_defconfig   |  1 +
 configs/MPC8349EMDS_defconfig |  1 +
 configs/MPC837XERDB_defconfig |  1 +
 configs/MPC8548CDS_36BIT_defconfig|  1 +
 configs/MPC8548CDS_defconfig  |  1 +
 configs/MPC8548CDS_legacy_defconfig   |  1 +
 configs/P1010RDB-PA_36BIT_NAND_defconfig  |  1 +
 configs/P1010RDB-PA_36BIT_NOR_defconfig   |  1 +
 configs/P1010RDB-PA_36BIT_SDCARD_defconfig|  1 +
 configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig  |  1 +
 configs/P1010RDB-PA_NAND_defconfig|  1 +
 configs/P1010RDB-PA_NOR_defconfig |  1 +
 configs/P1010RDB-PA_SDCARD_defconfig  |  1 +
 configs/P1010RDB-PA_SPIFLASH_defconfig|  1 +
 configs/P1010RDB-PB_36BIT_NAND_defconfig  |  1 +
 configs/P1010RDB-PB_36BIT_NOR_defconfig   |  1 +
 configs/P1010RDB-PB_36BIT_SDCARD_defconfig|  1 +
 configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig  |  1 +
 configs/P1010RDB-PB_NAND_defconfig|  1 +
 configs/P1010RDB-PB_NOR_defconfig |  1 +
 configs/P1010RDB-PB_SDCARD_defconfig  |  1 +
 configs/P1010RDB-PB_SPIFLASH_defconfig|  1 +
 configs/P1020RDB-PC_36BIT_NAND_defconfig  |  1 +
 configs/P1020RDB-PC_36BIT_SDCARD_defconfig|  1 +
 configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig  |  1 +
 configs/P1020RDB-PC_36BIT_defconfig   |  1 +
 configs/P1020RDB-PC_NAND_defconfig|  1 +
 configs/P1020RDB-PC_SDCARD_defconfig  |  1 +
 configs/P1020RDB-PC_SPIFLASH_defconfig|  1 +
 configs/P1020RDB-PC_defconfig |  1 +
 configs/P1020RDB-PD_NAND_defconfig|  1 +
 configs/P1020RDB-PD_SDCARD_defconfig  |  1 +
 configs/P1020RDB-PD_SPIFLASH_defconfig|  1 +
 configs/P1020RDB-PD_defconfig |  1 +
 configs/P2020RDB-PC_36BIT_NAND_defconfig  |  1 +
 configs/P2020RDB-PC_36BIT_SDCARD_defconfig|  1 +
 configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig  |  1 +
 configs/P2020RDB-PC_36BIT_defconfig   |  1 +
 configs/P2020RDB-PC_NAND_defconfig|  1 +
 configs/P2020RDB-PC_SDCARD_defconfig  |  1 +
 configs/P2020RDB-PC_SPIFLASH_defconfig|  1 +
 configs/P2020RDB-PC_defconfig |  1 +
 configs/P2041RDB_NAND_defconfig   |  1 +
 configs/P2041RDB_SDCARD_defconfig |  1 +
 configs/P2041RDB_SPIFLASH_defconfig   |  1 +
 configs/P2041RDB_defconfig|  1 +
 configs/P3041DS_NAND_defconfig|  1 +
 configs/P3041DS_SDCARD_defconfig  |  1 +
 configs/P3041DS_SPIFLASH_defconfig|  1 +
 configs/P3041DS_defconfig |  1 +
 configs/P4080DS_SDCARD_defconfig  |  1 +
 configs/P4080DS_SPIFLASH_defconfig|  1 +
 configs/P4080DS_defconfig |  1 +
 configs/P5040DS_NAND_defconfig|  1 +
 configs/P5040DS_SDCARD_defconfig  |  1 +
 configs/P5040DS_SPIFLASH_defconfig|  1 +
 configs/P5040DS_defconfig |  1 +
 configs/T1024RDB_NAND_defconfig   |  1 +
 configs/T1024RDB_SDCARD_defconfig |  1 +
 configs/T1024RDB_SPIFLASH_defconfig   |  1 +
 configs/T1024RDB_defconfig|  1 +
 configs/T1042D4RDB_NAND_defconfig |  1 +
 configs/T1042D4RDB_SDCARD_defconfig   |  1 +
 configs/T1042D4RDB_SPIFLASH_defconfig |  1 +
 configs/T1042D4RDB_defconfig  |  1 +
 configs/T2080QDS_NAND_defconfig   |  1 +
 configs/T2080QDS_SDCARD_defconfig |  1 +
 configs/T2080QDS_SECURE_BOOT_defconfig|  1 +
 configs/T2080QDS_SPIFLASH_defconfig   |  1 +
 configs/T2080QDS_SRIO_PCIE_BOOT_defconfig |  1 +
 configs/T2080QDS_defconfig|  1 +
 configs/T2080RDB_NAND_defconfig   |  1 +
 configs/T2080RDB_SDCARD_defconfig |  1 +
 configs/T2080RDB_SPIFLASH_defconfig   |  1 +
 configs/T2080RDB_defconfig|  1 +
 configs/T2080RDB_revD_NAND_defconfig  |  1 +
 configs/T2080RDB_revD_SDCARD_defconfig|  1 +
 configs/T2080RDB_revD_SPIFLASH_defconfig  |  1 +
 configs/T2080RDB_revD_defconfig   |  1 +
 configs/T4240RDB_SDCARD_defconfig |  1 +
 

Re: [PULL] Please pull mmc-2021-9-13

[Tom Rini]

On Mon, Sep 13, 2021 at 05:59:15AM +, Peng Fan (OSS) wrote:

> Hi Tom,
> 
> Please pull mmc-2021-9-13
> 
> CI: https://source.denx.de/u-boot/custodians/u-boot-mmc/-/pipelines/9096

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 3/5] serial: Use the default CONFIG_SYS_BAUDRATE_TABLE in more platforms

[Tom Rini]

A number of platforms are still defining CONFIG_SYS_BAUDRATE_TABLE to
the fallback default of "{ 9600, 19200, 38400, 57600, 115200 }", but
with varying whitespace, or were introduced after the default fallback
was added.  Use the default table here.

Signed-off-by: Tom Rini 
---
 include/configs/amcore.h  | 1 -
 include/configs/ap121.h   | 3 ---
 include/configs/ap143.h   | 2 --
 include/configs/ap152.h   | 2 --
 include/configs/cm_fx6.h  | 1 -
 include/configs/kontron_sl28.h| 1 -
 include/configs/ls1012a_common.h  | 2 --
 include/configs/ls1028a_common.h  | 2 --
 include/configs/ls1043a_common.h  | 2 --
 include/configs/ls1046a_common.h  | 2 --
 include/configs/ls1088a_common.h  | 2 --
 include/configs/ls2080a_common.h  | 2 --
 include/configs/lx2160a_common.h  | 1 -
 include/configs/mt7620.h  | 3 ---
 include/configs/s5p4418_nanopi2.h | 1 -
 include/configs/stmark2.h | 1 -
 include/configs/synquacer.h   | 2 --
 include/configs/tplink_wdr4300.h  | 2 --
 include/configs/vexpress_common.h | 1 -
 include/configs/xtfpga.h  | 1 -
 20 files changed, 34 deletions(-)

diff --git a/include/configs/amcore.h b/include/configs/amcore.h
index 4fd02cd75da4..f70252e1cd28 100644
--- a/include/configs/amcore.h
+++ b/include/configs/amcore.h
@@ -13,7 +13,6 @@
 #define CONFIG_MCFTMR
 #define CONFIG_MCFUART
 #define CONFIG_SYS_UART_PORT   0
-#define CONFIG_SYS_BAUDRATE_TABLE  { 9600, 19200, 38400, 57600, 115200 }
 
 #define CONFIG_BOOTCOMMAND "bootm ffc2"
 #define CONFIG_EXTRA_ENV_SETTINGS  \
diff --git a/include/configs/ap121.h b/include/configs/ap121.h
index fb2a0b33cc04..f3fc53ba484f 100644
--- a/include/configs/ap121.h
+++ b/include/configs/ap121.h
@@ -21,9 +21,6 @@
 #define CONFIG_SYS_INIT_SP_ADDR \
(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE - 1)
 
-#define CONFIG_SYS_BAUDRATE_TABLE \
-   {9600, 19200, 38400, 57600, 115200}
-
 #define CONFIG_BOOTCOMMAND  "sf probe;" \
"mtdparts default;" \
"bootm 0x9f65"
diff --git a/include/configs/ap143.h b/include/configs/ap143.h
index bb9544b8e74e..fa13a801b771 100644
--- a/include/configs/ap143.h
+++ b/include/configs/ap143.h
@@ -25,8 +25,6 @@
  * Serial Port
  */
 #define CONFIG_SYS_NS16550_CLK  2500
-#define CONFIG_SYS_BAUDRATE_TABLE \
-   {9600, 19200, 38400, 57600, 115200}
 
 #define CONFIG_BOOTCOMMAND  "sf probe;" \
"mtdparts default;" \
diff --git a/include/configs/ap152.h b/include/configs/ap152.h
index 766f10b6beac..3eaf19283bba 100644
--- a/include/configs/ap152.h
+++ b/include/configs/ap152.h
@@ -25,8 +25,6 @@
  * Serial Port
  */
 #define CONFIG_SYS_NS16550_CLK  2500
-#define CONFIG_SYS_BAUDRATE_TABLE \
-   {9600, 19200, 38400, 57600, 115200}
 
 #define CONFIG_BOOTCOMMAND  "sf probe;" \
"mtdparts default;" \
diff --git a/include/configs/cm_fx6.h b/include/configs/cm_fx6.h
index a22fd0ee1fe9..d40c3a9c3e54 100644
--- a/include/configs/cm_fx6.h
+++ b/include/configs/cm_fx6.h
@@ -32,7 +32,6 @@
 
 /* Serial console */
 #define CONFIG_MXC_UART_BASE   UART4_BASE
-#define CONFIG_SYS_BAUDRATE_TABLE  {9600, 19200, 38400, 57600, 115200}
 
 /* Environment */
 
diff --git a/include/configs/kontron_sl28.h b/include/configs/kontron_sl28.h
index 438a189702d4..6769592101de 100644
--- a/include/configs/kontron_sl28.h
+++ b/include/configs/kontron_sl28.h
@@ -45,7 +45,6 @@
 
 /* serial port */
 #define CONFIG_SYS_NS16550_CLK  (get_bus_freq(0) / 2)
-#define CONFIG_SYS_BAUDRATE_TABLE  { 9600, 19200, 38400, 57600, 115200 }
 
 #define CONFIG_SYS_CLK_FREQ1
 #define COUNTER_FREQUENCY_REAL (CONFIG_SYS_CLK_FREQ / 4)
diff --git a/include/configs/ls1012a_common.h b/include/configs/ls1012a_common.h
index 1edea0a2b2f3..8a49f2d0075d 100644
--- a/include/configs/ls1012a_common.h
+++ b/include/configs/ls1012a_common.h
@@ -59,8 +59,6 @@
 #define CONFIG_SYS_NS16550_REG_SIZE 1
 #define CONFIG_SYS_NS16550_CLK  (get_serial_clock())
 
-#define CONFIG_SYS_BAUDRATE_TABLE  { 9600, 19200, 38400, 57600, 115200 }
-
 #define CONFIG_SYS_HZ  1000
 
 #define CONFIG_HWCONFIG
diff --git a/include/configs/ls1028a_common.h b/include/configs/ls1028a_common.h
index 50edefb36324..1401264f9316 100644
--- a/include/configs/ls1028a_common.h
+++ b/include/configs/ls1028a_common.h
@@ -45,8 +45,6 @@
 #define CONFIG_SYS_NS16550_REG_SIZE 1
 #define CONFIG_SYS_NS16550_CLK  (get_bus_freq(0) / 2)
 
-#define CONFIG_SYS_BAUDRATE_TABLE  { 9600, 19200, 38400, 57600, 115200 }
-
 /* Miscellaneous configurable options */
 
 /* Physical Memory Map */
diff --git a/include/configs/ls1043a_common.h b/include/configs/ls1043a_common.h
index f6909d05a043..14f72520034e 100644
--- 

[PATCH 4/5] serial: Remove extraneous SYS_MALLOC_F check

[Tom Rini]

We enforce that DM_SERIAL will have SYS_MALLOC_F enabled and so
SYS_MALLOC_F_LEN will have a value.  Remove the build-time check.

Cc: Simon Glass 
Signed-off-by: Tom Rini 
---
 drivers/serial/serial-uclass.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index 8171b17faf88..57a784844150 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -27,10 +27,6 @@ DECLARE_GLOBAL_DATA_PTR;
  */
 static const unsigned long baudrate_table[] = CONFIG_SYS_BAUDRATE_TABLE;
 
-#if !CONFIG_VAL(SYS_MALLOC_F_LEN)
-#error "Serial is required before relocation - define 
CONFIG_$(SPL_)SYS_MALLOC_F_LEN to make this work"
-#endif
-
 #if CONFIG_IS_ENABLED(SERIAL_PRESENT)
 static int serial_check_stdout(const void *blob, struct udevice **devp)
 {
-- 
2.17.1

[PATCH 2/5] Convert CONFIG_BAUDRATE to Kconfig

[Tom Rini]

This converts the following to Kconfig:
   CONFIG_BAUDRATE

Signed-off-by: Tom Rini 
---
 include/configs/cgtqmx8.h   | 3 ---
 include/configs/synquacer.h | 1 -
 2 files changed, 4 deletions(-)

diff --git a/include/configs/cgtqmx8.h b/include/configs/cgtqmx8.h
index 304c876e8b9b..4012814988d0 100644
--- a/include/configs/cgtqmx8.h
+++ b/include/configs/cgtqmx8.h
@@ -159,9 +159,6 @@
 #define PHYS_SDRAM_1_SIZE  0x8000  /* 2 GB */
 #define PHYS_SDRAM_2_SIZE  0x1 /* 4 GB */
 
-/* Serial */
-#define CONFIG_BAUDRATE115200
-
 /* Generic Timer Definitions */
 #define COUNTER_FREQUENCY  800 /* 8MHz */
 
diff --git a/include/configs/synquacer.h b/include/configs/synquacer.h
index 225d017d17da..04db908795c1 100644
--- a/include/configs/synquacer.h
+++ b/include/configs/synquacer.h
@@ -49,7 +49,6 @@
 #define CONFIG_SYS_MEMTEST_START   (CONFIG_SYS_SDRAM_BASE + (512 * 1024))
 #define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_SDRAM_BASE + 
PHYS_SDRAM_SIZE)
 
-#define CONFIG_BAUDRATE115200
 #define CONFIG_SYS_BAUDRATE_TABLE  {115200, 19200, 38400, 57600, 9600 }
 
 #define CONFIG_SYS_CBSIZE  1024
-- 
2.17.1

[PATCH 1/5] kgdb: Remove unused serial related options

[Tom Rini]

We have a few CONFIG options for KGDB that are not referenced, remove
them.

Signed-off-by: Tom Rini 
---
 README  | 5 -
 include/configs/MPC8349EMDS.h   | 4 
 include/configs/MPC8349EMDS_SDRAM.h | 4 
 include/configs/MPC837XERDB.h   | 4 
 include/configs/MPC8540ADS.h| 4 
 include/configs/MPC8548CDS.h| 4 
 include/configs/MPC8560ADS.h| 4 
 include/configs/P1010RDB.h  | 4 
 include/configs/P2041RDB.h  | 4 
 include/configs/T102xRDB.h  | 4 
 include/configs/T104xRDB.h  | 4 
 include/configs/T208xQDS.h  | 5 -
 include/configs/T208xRDB.h  | 5 -
 include/configs/T4240RDB.h  | 4 
 include/configs/UCP1020.h   | 5 -
 include/configs/corenet_ds.h| 4 
 include/configs/p1_p2_rdb_pc.h  | 4 
 include/configs/pxa-common.h| 7 ---
 include/configs/socrates.h  | 4 
 include/configs/x86-common.h| 4 
 20 files changed, 87 deletions(-)

diff --git a/README b/README
index 6df06c79bc83..e9a6df4cd1de 100644
--- a/README
+++ b/README
@@ -648,11 +648,6 @@ The following options need to be configured:
time on others. This setting #define's the initial
value of the "loads_echo" environment variable.
 
-- Kgdb Serial Baudrate: (if CONFIG_CMD_KGDB is defined)
-   CONFIG_KGDB_BAUDRATE
-   Select one of the baudrates listed in
-   CONFIG_SYS_BAUDRATE_TABLE, see below.
-
 - Removal of commands
If no commands are needed to boot, you can disable
CONFIG_CMDLINE to remove them. In this case, the command line
diff --git a/include/configs/MPC8349EMDS.h b/include/configs/MPC8349EMDS.h
index 2f1fc6a6a2b9..d96d3ce6967b 100644
--- a/include/configs/MPC8349EMDS.h
+++ b/include/configs/MPC8349EMDS.h
@@ -255,10 +255,6 @@
 #define CONFIG_PCI_INDIRECT_BRIDGE
 #endif
 
-#if defined(CONFIG_CMD_KGDB)
-#define CONFIG_KGDB_BAUDRATE   230400  /* speed of kgdb serial port */
-#endif
-
 /*
  * Environment Configuration
  */
diff --git a/include/configs/MPC8349EMDS_SDRAM.h 
b/include/configs/MPC8349EMDS_SDRAM.h
index d6a151d20ce6..0f8db35ae90e 100644
--- a/include/configs/MPC8349EMDS_SDRAM.h
+++ b/include/configs/MPC8349EMDS_SDRAM.h
@@ -312,10 +312,6 @@
 #define CONFIG_PCI_INDIRECT_BRIDGE
 #endif
 
-#if defined(CONFIG_CMD_KGDB)
-#define CONFIG_KGDB_BAUDRATE   230400  /* speed of kgdb serial port */
-#endif
-
 /*
  * Environment Configuration
  */
diff --git a/include/configs/MPC837XERDB.h b/include/configs/MPC837XERDB.h
index 0e2e034dcd9b..ce810e5f2cbe 100644
--- a/include/configs/MPC837XERDB.h
+++ b/include/configs/MPC837XERDB.h
@@ -323,10 +323,6 @@
 #define CONFIG_SYS_BOOTMAPSZ   (256 << 20) /* Initial Memory map for Linux */
 #define CONFIG_SYS_BOOTM_LEN   (64 << 20)  /* Increase max gunzip size */
 
-#if defined(CONFIG_CMD_KGDB)
-#define CONFIG_KGDB_BAUDRATE   230400  /* speed of kgdb serial port */
-#endif
-
 /*
  * Environment Configuration
  */
diff --git a/include/configs/MPC8540ADS.h b/include/configs/MPC8540ADS.h
index 66cf2053f980..b73a7c9ac955 100644
--- a/include/configs/MPC8540ADS.h
+++ b/include/configs/MPC8540ADS.h
@@ -289,10 +289,6 @@
 #define CONFIG_SYS_BOOTMAPSZ   (64 << 20)  /* Initial Memory map for 
Linux*/
 #define CONFIG_SYS_BOOTM_LEN   (64 << 20)  /* Increase max gunzip size */
 
-#if defined(CONFIG_CMD_KGDB)
-#define CONFIG_KGDB_BAUDRATE   230400  /* speed to run kgdb serial port */
-#endif
-
 /*
  * Environment Configuration
  */
diff --git a/include/configs/MPC8548CDS.h b/include/configs/MPC8548CDS.h
index f7d05ffa89a1..5c54bad4964f 100644
--- a/include/configs/MPC8548CDS.h
+++ b/include/configs/MPC8548CDS.h
@@ -415,10 +415,6 @@ extern unsigned long get_clock_freq(void);
 #define CONFIG_SYS_BOOTMAPSZ   (64 << 20)  /* Initial Memory map for 
Linux*/
 #define CONFIG_SYS_BOOTM_LEN   (64 << 20)  /* Increase max gunzip size */
 
-#if defined(CONFIG_CMD_KGDB)
-#define CONFIG_KGDB_BAUDRATE   230400  /* speed to run kgdb serial port */
-#endif
-
 /*
  * Environment Configuration
  */
diff --git a/include/configs/MPC8560ADS.h b/include/configs/MPC8560ADS.h
index 224314366439..23ac9f8e6ece 100644
--- a/include/configs/MPC8560ADS.h
+++ b/include/configs/MPC8560ADS.h
@@ -279,10 +279,6 @@
 #define CONFIG_SYS_BOOTMAPSZ   (64 << 20)  /* Initial Memory map for 
Linux*/
 #define CONFIG_SYS_BOOTM_LEN   (64 << 20)  /* Increase max gunzip size */
 
-#if defined(CONFIG_CMD_KGDB)
-#define CONFIG_KGDB_BAUDRATE   230400  /* speed to run kgdb serial port */
-#endif
-
 /*
  * Environment Configuration
  */
diff --git a/include/configs/P1010RDB.h b/include/configs/P1010RDB.h
index 02b0b71ada56..922f0661aba2 100644
--- a/include/configs/P1010RDB.h
+++ b/include/configs/P1010RDB.h
@@ -619,10 +619,6 @@ extern unsigned long get_sdram_size(void);
 #define CONFIG_SYS_BOOTMAPSZ   (64 << 20) /* Initial 

Re: [PATCH 2/2] tee: add a stub for tee_find_device

[Jens Wiklander]

Hi Patrick,

On Thu, Sep 2, 2021 at 11:56 AM Patrick Delaunay
 wrote:
>
> Add stub for tee_find_device function when CONFIG_TEE is not activated
> to simplify the caller code.
>
> This patch allows to remove the CONFIG_IS_ENABLED(OPTEE) tests
> for stm32 platform.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  arch/arm/mach-stm32mp/fdt.c|  1 -
>  board/st/common/stm32mp_mtdparts.c |  3 +--
>  include/tee.h  | 11 +++
>  3 files changed, 12 insertions(+), 3 deletions(-)

Reviewed-by: Jens Wiklander 

Re: [PATCH v2 02/32] ppc: Remove UCP1020 board

[Arcturus Support]

This board has not been converted to CONFIG_DM_PCI by the deadline.

Remove it.

Leave the Kconfig options to avoid warnings on other boards.

Signed-off-by: Simon Glass 
Acked-by: Michael Durrant 
Acked-by: Oleksandr Zhadan 
Acked-by: Oleksandr Zhadan and Michael Durrant

---

Changes in v2:
- Update to mention DM_PCI instead

board/Arcturus/ucp1020/Kconfig | 28 +-
board/Arcturus/ucp1020/MAINTAINERS | 7 -
board/Arcturus/ucp1020/Makefile | 31 -
board/Arcturus/ucp1020/README | 54 --
board/Arcturus/ucp1020/cmd_arc.c | 408 -
board/Arcturus/ucp1020/ddr.c | 161 --
board/Arcturus/ucp1020/law.c | 24 -
board/Arcturus/ucp1020/spl.c | 127 
board/Arcturus/ucp1020/spl_minimal.c | 67 ---
board/Arcturus/ucp1020/tlb.c | 100 
board/Arcturus/ucp1020/ucp1020.c | 372 
board/Arcturus/ucp1020/ucp1020.h | 45 --
configs/UCP1020_defconfig | 58 --
include/configs/UCP1020.h | 832 ---
14 files changed, 1 insertion(+), 2313 deletions(-)
delete mode 100644 board/Arcturus/ucp1020/MAINTAINERS
delete mode 100644 board/Arcturus/ucp1020/Makefile
delete mode 100644 board/Arcturus/ucp1020/README
delete mode 100644 board/Arcturus/ucp1020/cmd_arc.c
delete mode 100644 board/Arcturus/ucp1020/ddr.c
delete mode 100644 board/Arcturus/ucp1020/law.c
delete mode 100644 board/Arcturus/ucp1020/spl.c
delete mode 100644 board/Arcturus/ucp1020/spl_minimal.c
delete mode 100644 board/Arcturus/ucp1020/tlb.c
delete mode 100644 board/Arcturus/ucp1020/ucp1020.c
delete mode 100644 board/Arcturus/ucp1020/ucp1020.h
delete mode 100644 configs/UCP1020_defconfig
delete mode 100644 include/configs/UCP1020.h

diff --git a/board/Arcturus/ucp1020/Kconfig b/board/Arcturus/ucp1020/Kconfig
index fe2c3be1b7a..60d80bab822 100644
--- a/board/Arcturus/ucp1020/Kconfig
+++ b/board/Arcturus/ucp1020/Kconfig
@@ -1,28 +1,4 @@
-if TARGET_UCP1020
-
-config SYS_BOARD
- string
- default "ucp1020"
-
-config SYS_VENDOR
- string
- default "Arcturus"
-
-config SYS_CONFIG_NAME
- string
- default "UCP1020"
-
-choice
- prompt "Target image select"
-
-config TARGET_UCP1020_NOR
- bool "NOR flash u-boot image"
-
-config TARGET_UCP1020_SPIFLASH
- bool "SPI flash u-boot image"
-
-endchoice
-
+# This exists only to avoid a warning for an unconverted value
if TARGET_UCP1020_SPIFLASH
config UCBOOT
bool
@@ -32,5 +8,3 @@ config SPIFLASH
bool
default y
endif
-
-endif
diff --git a/board/Arcturus/ucp1020/MAINTAINERS
b/board/Arcturus/ucp1020/MAINTAINERS
deleted file mode 100644
index e4a4718188f..000
--- a/board/Arcturus/ucp1020/MAINTAINERS
+++ /dev/null
@@ -1,7 +0,0 @@
-UCP1020 BOARD
-M: Oleksandr Zhadan and Michael Durrant 
-S: Maintained
-F: board/Arcturus/ucp1020/
-F: include/configs/UCP1020.h
-F: configs/UCP1020_defconfig
-F: configs/UCP1020_SPIFLASH_defconfig
diff --git a/board/Arcturus/ucp1020/Makefile
b/board/Arcturus/ucp1020/Makefile
deleted file mode 100644
index 46d04fb78c1..000
--- a/board/Arcturus/ucp1020/Makefile
+++ /dev/null
@@ -1,31 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-#
-# Copyright 2013-2015 Arcturus Networks, Inc.
-# based on board/freescale/p1_p2_rdb_pc/Makefile
-# original copyright follows:
-# Copyright 2010-2011 Freescale Semiconductor, Inc.
-
-MINIMAL=
-
-ifdef CONFIG_SPL_BUILD
-ifdef CONFIG_SPL_INIT_MINIMAL
-MINIMAL=y
-endif
-endif
-
-ifdef MINIMAL
-
-obj-y += spl_minimal.o tlb.o law.o
-
-else
-ifdef CONFIG_SPL_BUILD
-obj-y += spl.o
-endif
-
-obj-y += ucp1020.o
-obj-y += ddr.o
-obj-y += law.o
-obj-y += tlb.o
-obj-y += cmd_arc.o
-
-endif
diff --git a/board/Arcturus/ucp1020/README b/board/Arcturus/ucp1020/README
deleted file mode 100644
index 555c4ef79fe..000
--- a/board/Arcturus/ucp1020/README
+++ /dev/null
@@ -1,54 +0,0 @@
-The uCP1020 product family (ucp1020) is an Arcturus Networks Inc.
System on Modules
-product featuring a Freescale P1020 CPU, optionally populated with 1, 2
or 3 Gig-Ethernet PHYs,
-DDR3, NOR Flash, eMMC NAND Flash and/or SPI Flash.
-
-Information on the generic product family can be found here:
- http://www.arcturusnetworks.com/products/ucp1020
-
-The UCP1020 several configurable options
-
-
-- the selection of populated phy(s):
- KSZ9031 (current default for eTSEC 1 and 3)
-
-- the selection of boot location:
- SPI Flash or NOR flash
-
-The UCP1020 includes 2 default configurations
-=
-NOR boot image:
- configs/UCP1020_defconfig
-SPI boot image:
- configs/UCP1020_SPIFLASH_defconfig
-
-The UCP1020 adds an additional command in cmd_arc.c to access and program
-SPI resident factory defaults for serial number, and 1, 2 or 3 Ethernet
-HW Addresses.
-
-
-Build example
-=
-
-make distclean
-make UCP1020_defconfig
-make
-
-Default Scripts
-===
-A default upgrade scripts is included in the default environment
variable example:
-
-B$ run tftpflash
-
-Dual Environment
-
-
-This build enables dual / failover environment environment.
-
-NOR Flash Partition 

Re: [PATCH 7/9] net: macb: Fix -Wint-to-pointer-cast warnings

[Ramon Fried]

On Sun, Sep 12, 2021 at 6:16 AM Bin Meng  wrote:
>
> The following warning is seen in macb.c in a 32-bit build:
>
>   warning: cast to pointer from integer of different size 
> [-Wint-to-pointer-cast]
>
> Change to use dev_read_addr_index_ptr(), or cast with uintptr_t.
>
> Signed-off-by: Bin Meng 
> ---
>
>  drivers/net/macb.c | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index 57ea45e2dc..fe14027b31 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -574,14 +574,9 @@ static int macb_phy_find(struct macb_device *macb, const 
> char *name)
>  #ifdef CONFIG_DM_ETH
>  static int macb_sifive_clk_init(struct udevice *dev, ulong rate)
>  {
> -   fdt_addr_t addr;
> void *gemgxl_regs;
>
> -   addr = dev_read_addr_index(dev, 1);
> -   if (addr == FDT_ADDR_T_NONE)
> -   return -ENODEV;
> -
> -   gemgxl_regs = (void __iomem *)addr;
> +   gemgxl_regs = dev_read_addr_index_ptr(dev, 1);
> if (!gemgxl_regs)
> return -ENODEV;
>
> @@ -1383,7 +1378,7 @@ static int macb_eth_probe(struct udevice *dev)
> macb->phy_addr = ofnode_read_u32_default(phandle_args.node,
>  "reg", -1);
>
> -   macb->regs = (void *)pdata->iobase;
> +   macb->regs = (void *)(uintptr_t)pdata->iobase;
>
> macb->is_big_endian = (cpu_to_be32(0x12345678) == 0x12345678);
>
> @@ -1444,7 +1439,7 @@ static int macb_eth_of_to_plat(struct udevice *dev)
>  {
> struct eth_pdata *pdata = dev_get_plat(dev);
>
> -   pdata->iobase = (phys_addr_t)dev_remap_addr(dev);
> +   pdata->iobase = (uintptr_t)dev_remap_addr(dev);
> if (!pdata->iobase)
> return -EINVAL;
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH v7 5/5] iot2050: Enable watchdog support, but do not auto-start it

[Tom Rini]

On Mon, Sep 13, 2021 at 06:08:10PM +0200, François Ozog wrote:
> On Mon, 13 Sept 2021 at 17:36, Tom Rini  wrote:
> 
> > On Mon, Sep 13, 2021 at 04:59:35PM +0200, Jan Kiszka wrote:
> > > On 13.09.21 16:56, Tom Rini wrote:
> > > > On Mon, Sep 13, 2021 at 04:31:37PM +0200, Jan Kiszka wrote:
> > > >> On 13.09.21 14:34, Tom Rini wrote:
> > > >>> On Mon, Sep 13, 2021 at 09:57:45AM +0200, Jan Kiszka wrote:
> > >  On 11.09.21 02:10, Tom Rini wrote:
> > > > On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote:
> > > >
> > > >> From: Jan Kiszka 
> > > >>
> > > >> This allows to use the watchdog in custom scripts but does not
> > enforce
> > > >> that the OS has to support it as well.
> > > >>
> > > >> Signed-off-by: Jan Kiszka 
> > > >
> > > > Sorry for the late reply.  This causes CI to fail:
> > > > Building current source for 1 boards (1 thread, 16 jobs per thread)
> > > >aarch64:  +   iot2050
> > > > +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary
> > is non-functional
> > > > +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might
> > be non-functional
> > > > +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input
> > path (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts)
> > (cwd='/tmp/iot2050/.bm-work/iot2050')
> > > > +(iot2050) make[1]: *** [all] Error 1
> > > > +(iot2050) make: *** [sub-make] Error 2
> > > > 001 /1  iot2050
> > > >
> > > > And needs to be handled like ATF/OPTEE/etc where CI can build but
> > throw
> > > > a "THIS WILL NOT RUN CORRECTLY" type warning to the user.
> > > >
> > > 
> > >  I was about to sent an update anyway - time passed, and now we even
> > have
> > >  support for the next generation integrated from the beginning. But
> > >  related upstream DT changes are not yet merged.
> > > >>>
> > > >>> OK.
> > > >>>
> > >  But back to this issue: How can CI be fed with all those required
> > >  binaries? The build makes no sense in their absence.
> > > >>>
> > > >>> To be clearer, CI isn't fed all of the binaries, we just use
> > /dev/null
> > > >>> in that case and try and make it clear it won't boot.  K3 isn't a
> > good
> > > >>> example here, but I think sunxi uses binman and handles this same
> > class
> > > >>> of problem?
> > > >>>
> > > >>
> > > >> I'm seeing it additionally carrying a "missing-msg" property, but that
> > > >> alone (even with missing-blob-help updated) does not make the build
> > > >> pass. It rather seems I'm missing some "allow_missing" property for
> > that
> > > >> image, but even reading the code gives no clue yet how to achieve
> > that.
> > > >> Yet another binman mystery.
> > > >
> > > > You might also need a new file in tools/binman/etype/ ?  Also, it will
> > > > have a non-zero exit status still, but with a value of 101 which we
> > > > check for and know that's "binary blob missing" and so OK to allow CI
> > to
> > > > pass on.
> > > >
> > >
> > > Err, that doesn't sound like binman is making my life easier. Why can't
> > > a I simple do something like
> > >
> > >   k3-rti-wdt-firmware {
> > >   type = "blob";
> > >   load = <0x8200>;
> > >   blob {
> > >   filename = CONFIG_WDT_K3_RTI_FW_FILE;
> > >   missing-msg = "k3-rti-wdt-firmware";
> > >   allow_missing;
> > >   };
> > >   };
> > >
> > > and be done?
> >
> > Sounds like a good idea, and I'm not quite sure what's missing to go
> > from where we are today to there.  I might be missing something myself.
> >
> 
> If that entry is located in a DT for U-Boot consumption why not, but in the
> DT that is associated to a platform that is passed to the OS, that sounds
> like a practice to avoid as this does not describe hardware. Thinking
> compatibility, is the filename/filepath really OS independent ?

So, here's one of those cases where we aren't really talking about the
runtime device tree so much as how we configure the build.  binman is
how we assemble the assorted binaries in to a functional blob for a
given platform without having to write a new tool for every SoC.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v7 5/5] iot2050: Enable watchdog support, but do not auto-start it

[Jan Kiszka]

On 13.09.21 17:36, Tom Rini wrote:
> On Mon, Sep 13, 2021 at 04:59:35PM +0200, Jan Kiszka wrote:
>> On 13.09.21 16:56, Tom Rini wrote:
>>> On Mon, Sep 13, 2021 at 04:31:37PM +0200, Jan Kiszka wrote:
 On 13.09.21 14:34, Tom Rini wrote:
> On Mon, Sep 13, 2021 at 09:57:45AM +0200, Jan Kiszka wrote:
>> On 11.09.21 02:10, Tom Rini wrote:
>>> On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote:
>>>
 From: Jan Kiszka 

 This allows to use the watchdog in custom scripts but does not enforce
 that the OS has to support it as well.

 Signed-off-by: Jan Kiszka 
>>>
>>> Sorry for the late reply.  This causes CI to fail:
>>> Building current source for 1 boards (1 thread, 16 jobs per thread)
>>>aarch64:  +   iot2050
>>> +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary is 
>>> non-functional
>>> +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might be 
>>> non-functional
>>> +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input path 
>>> (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts) 
>>> (cwd='/tmp/iot2050/.bm-work/iot2050')
>>> +(iot2050) make[1]: *** [all] Error 1
>>> +(iot2050) make: *** [sub-make] Error 2
>>> 001 /1  iot2050
>>>
>>> And needs to be handled like ATF/OPTEE/etc where CI can build but throw
>>> a "THIS WILL NOT RUN CORRECTLY" type warning to the user.
>>>
>>
>> I was about to sent an update anyway - time passed, and now we even have
>> support for the next generation integrated from the beginning. But
>> related upstream DT changes are not yet merged.
>
> OK.
>
>> But back to this issue: How can CI be fed with all those required
>> binaries? The build makes no sense in their absence.
>
> To be clearer, CI isn't fed all of the binaries, we just use /dev/null
> in that case and try and make it clear it won't boot.  K3 isn't a good
> example here, but I think sunxi uses binman and handles this same class
> of problem?
>

 I'm seeing it additionally carrying a "missing-msg" property, but that
 alone (even with missing-blob-help updated) does not make the build
 pass. It rather seems I'm missing some "allow_missing" property for that
 image, but even reading the code gives no clue yet how to achieve that.
 Yet another binman mystery.
>>>
>>> You might also need a new file in tools/binman/etype/ ?  Also, it will
>>> have a non-zero exit status still, but with a value of 101 which we
>>> check for and know that's "binary blob missing" and so OK to allow CI to
>>> pass on.
>>>
>>
>> Err, that doesn't sound like binman is making my life easier. Why can't
>> a I simple do something like
>>
>>  k3-rti-wdt-firmware {
>>  type = "blob";
>>  load = <0x8200>;
>>  blob {
>>  filename = CONFIG_WDT_K3_RTI_FW_FILE;
>>  missing-msg = "k3-rti-wdt-firmware";
>>  allow_missing;
>>  };
>>  };
>>
>> and be done?
> 
> Sounds like a good idea, and I'm not quite sure what's missing to go
> from where we are today to there.  I might be missing something myself.
> 

Works now, with "blob-ext" rather than "blob". binman is actually called
with --allow-missing.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH v7 5/5] iot2050: Enable watchdog support, but do not auto-start it

[François Ozog]

On Mon, 13 Sept 2021 at 17:36, Tom Rini  wrote:

> On Mon, Sep 13, 2021 at 04:59:35PM +0200, Jan Kiszka wrote:
> > On 13.09.21 16:56, Tom Rini wrote:
> > > On Mon, Sep 13, 2021 at 04:31:37PM +0200, Jan Kiszka wrote:
> > >> On 13.09.21 14:34, Tom Rini wrote:
> > >>> On Mon, Sep 13, 2021 at 09:57:45AM +0200, Jan Kiszka wrote:
> >  On 11.09.21 02:10, Tom Rini wrote:
> > > On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote:
> > >
> > >> From: Jan Kiszka 
> > >>
> > >> This allows to use the watchdog in custom scripts but does not
> enforce
> > >> that the OS has to support it as well.
> > >>
> > >> Signed-off-by: Jan Kiszka 
> > >
> > > Sorry for the late reply.  This causes CI to fail:
> > > Building current source for 1 boards (1 thread, 16 jobs per thread)
> > >aarch64:  +   iot2050
> > > +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary
> is non-functional
> > > +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might
> be non-functional
> > > +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input
> path (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts)
> (cwd='/tmp/iot2050/.bm-work/iot2050')
> > > +(iot2050) make[1]: *** [all] Error 1
> > > +(iot2050) make: *** [sub-make] Error 2
> > > 001 /1  iot2050
> > >
> > > And needs to be handled like ATF/OPTEE/etc where CI can build but
> throw
> > > a "THIS WILL NOT RUN CORRECTLY" type warning to the user.
> > >
> > 
> >  I was about to sent an update anyway - time passed, and now we even
> have
> >  support for the next generation integrated from the beginning. But
> >  related upstream DT changes are not yet merged.
> > >>>
> > >>> OK.
> > >>>
> >  But back to this issue: How can CI be fed with all those required
> >  binaries? The build makes no sense in their absence.
> > >>>
> > >>> To be clearer, CI isn't fed all of the binaries, we just use
> /dev/null
> > >>> in that case and try and make it clear it won't boot.  K3 isn't a
> good
> > >>> example here, but I think sunxi uses binman and handles this same
> class
> > >>> of problem?
> > >>>
> > >>
> > >> I'm seeing it additionally carrying a "missing-msg" property, but that
> > >> alone (even with missing-blob-help updated) does not make the build
> > >> pass. It rather seems I'm missing some "allow_missing" property for
> that
> > >> image, but even reading the code gives no clue yet how to achieve
> that.
> > >> Yet another binman mystery.
> > >
> > > You might also need a new file in tools/binman/etype/ ?  Also, it will
> > > have a non-zero exit status still, but with a value of 101 which we
> > > check for and know that's "binary blob missing" and so OK to allow CI
> to
> > > pass on.
> > >
> >
> > Err, that doesn't sound like binman is making my life easier. Why can't
> > a I simple do something like
> >
> >   k3-rti-wdt-firmware {
> >   type = "blob";
> >   load = <0x8200>;
> >   blob {
> >   filename = CONFIG_WDT_K3_RTI_FW_FILE;
> >   missing-msg = "k3-rti-wdt-firmware";
> >   allow_missing;
> >   };
> >   };
> >
> > and be done?
>
> Sounds like a good idea, and I'm not quite sure what's missing to go
> from where we are today to there.  I might be missing something myself.
>

If that entry is located in a DT for U-Boot consumption why not, but in the
DT that is associated to a platform that is passed to the OS, that sounds
like a practice to avoid as this does not describe hardware. Thinking
compatibility, is the filename/filepath really OS independent ?

>
> --
> Tom
>


-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog

Re: [PATCH v7 5/5] iot2050: Enable watchdog support, but do not auto-start it

[Tom Rini]

On Mon, Sep 13, 2021 at 04:59:35PM +0200, Jan Kiszka wrote:
> On 13.09.21 16:56, Tom Rini wrote:
> > On Mon, Sep 13, 2021 at 04:31:37PM +0200, Jan Kiszka wrote:
> >> On 13.09.21 14:34, Tom Rini wrote:
> >>> On Mon, Sep 13, 2021 at 09:57:45AM +0200, Jan Kiszka wrote:
>  On 11.09.21 02:10, Tom Rini wrote:
> > On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote:
> >
> >> From: Jan Kiszka 
> >>
> >> This allows to use the watchdog in custom scripts but does not enforce
> >> that the OS has to support it as well.
> >>
> >> Signed-off-by: Jan Kiszka 
> >
> > Sorry for the late reply.  This causes CI to fail:
> > Building current source for 1 boards (1 thread, 16 jobs per thread)
> >aarch64:  +   iot2050
> > +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary is 
> > non-functional
> > +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might be 
> > non-functional
> > +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input path 
> > (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts) 
> > (cwd='/tmp/iot2050/.bm-work/iot2050')
> > +(iot2050) make[1]: *** [all] Error 1
> > +(iot2050) make: *** [sub-make] Error 2
> > 001 /1  iot2050
> >
> > And needs to be handled like ATF/OPTEE/etc where CI can build but throw
> > a "THIS WILL NOT RUN CORRECTLY" type warning to the user.
> >
> 
>  I was about to sent an update anyway - time passed, and now we even have
>  support for the next generation integrated from the beginning. But
>  related upstream DT changes are not yet merged.
> >>>
> >>> OK.
> >>>
>  But back to this issue: How can CI be fed with all those required
>  binaries? The build makes no sense in their absence.
> >>>
> >>> To be clearer, CI isn't fed all of the binaries, we just use /dev/null
> >>> in that case and try and make it clear it won't boot.  K3 isn't a good
> >>> example here, but I think sunxi uses binman and handles this same class
> >>> of problem?
> >>>
> >>
> >> I'm seeing it additionally carrying a "missing-msg" property, but that
> >> alone (even with missing-blob-help updated) does not make the build
> >> pass. It rather seems I'm missing some "allow_missing" property for that
> >> image, but even reading the code gives no clue yet how to achieve that.
> >> Yet another binman mystery.
> > 
> > You might also need a new file in tools/binman/etype/ ?  Also, it will
> > have a non-zero exit status still, but with a value of 101 which we
> > check for and know that's "binary blob missing" and so OK to allow CI to
> > pass on.
> > 
> 
> Err, that doesn't sound like binman is making my life easier. Why can't
> a I simple do something like
> 
>   k3-rti-wdt-firmware {
>   type = "blob";
>   load = <0x8200>;
>   blob {
>   filename = CONFIG_WDT_K3_RTI_FW_FILE;
>   missing-msg = "k3-rti-wdt-firmware";
>   allow_missing;
>   };
>   };
> 
> and be done?

Sounds like a good idea, and I'm not quite sure what's missing to go
from where we are today to there.  I might be missing something myself.

-- 
Tom


signature.asc
Description: PGP signature

[PATCH v2 5/5] board: sl28: add update image documentation

[Michael Walle]

Document the update image and how to use the EFI UpdateCapsule.

Signed-off-by: Michael Walle 
---
changes since v1:
 - new patch

 doc/board/kontron/sl28.rst | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/doc/board/kontron/sl28.rst b/doc/board/kontron/sl28.rst
index 07431986d8..c7b18bed10 100644
--- a/doc/board/kontron/sl28.rst
+++ b/doc/board/kontron/sl28.rst
@@ -52,6 +52,21 @@ Disable the builtin watchdog
 - power-cycle the board
 
 
+Update image
+
+
+After the build finished, there will be an update image called
+u-boot.update. This can either be used in the DFU mode (which isn't
+supported yet) or encapsulated in an EFI UpdateCapsule.
+
+To build the capsule use the following command
+
+ $ tools/mkeficapsule -f u-boot.update -i 1 UpdateUboot
+
+Afterward you can copy this file to your ESP into the /EFI/UpdateCapsule/
+folder. On the next EFI boot this will automatically update your
+bootloader.
+
 Useful I2C tricks
 -
 
-- 
2.30.2

[PATCH v2 1/5] board: sl28: enable EFI_SET_TIME support

[Michael Walle]

Allow EFI to actually set the time before ExitBootServices().

Signed-off-by: Michael Walle 
---
changes since v1:
 - none

 configs/kontron_sl28_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/kontron_sl28_defconfig b/configs/kontron_sl28_defconfig
index e15928bead..8bd7d5be4b 100644
--- a/configs/kontron_sl28_defconfig
+++ b/configs/kontron_sl28_defconfig
@@ -92,3 +92,4 @@ CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_OF_LIBFDT_ASSUME_MASK=0x0
 CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_EFI_SET_TIME=y
-- 
2.30.2

[PATCH v2 3/5] board: sl28: enable EFI UpdateCapsule support

[Michael Walle]

Enable support for update over EFI UpdateCapsule mechanism. This board
doesn't support setting EFI variables after ExitBootservices().
Therefore, we are also enabling EFI_IGNORE_OSINDICATIONS.

Signed-off-by: Michael Walle 
---
changes since v1:
 - new patch

 configs/kontron_sl28_defconfig | 6 ++
 include/configs/kontron_sl28.h | 2 ++
 2 files changed, 8 insertions(+)

diff --git a/configs/kontron_sl28_defconfig b/configs/kontron_sl28_defconfig
index 8bd7d5be4b..20b4a8c40d 100644
--- a/configs/kontron_sl28_defconfig
+++ b/configs/kontron_sl28_defconfig
@@ -60,6 +60,8 @@ CONFIG_SCSI_AHCI=y
 CONFIG_SATA_CEVA=y
 CONFIG_FSL_CAAM=y
 CONFIG_SYS_FSL_DDR3=y
+CONFIG_DFU_MMC=y
+CONFIG_DFU_SF=y
 CONFIG_I2C_SET_DEFAULT_BUS_NUM=y
 CONFIG_I2C_DEFAULT_BUS_NUMBER=0
 CONFIG_I2C_MUX=y
@@ -93,3 +95,7 @@ CONFIG_USB_XHCI_DWC3=y
 CONFIG_OF_LIBFDT_ASSUME_MASK=0x0
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_EFI_SET_TIME=y
+CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
+CONFIG_EFI_CAPSULE_ON_DISK=y
+CONFIG_EFI_IGNORE_OSINDICATIONS=y
+CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
diff --git a/include/configs/kontron_sl28.h b/include/configs/kontron_sl28.h
index bfb4e67c8f..a02b8ce2b1 100644
--- a/include/configs/kontron_sl28.h
+++ b/include/configs/kontron_sl28.h
@@ -96,6 +96,8 @@
"envload=env import -d -b ${env_addr}\0" \
"install_rcw=source 2020\0" \
"fdtfile=freescale/fsl-ls1028a-kontron-sl28.dtb\0" \
+   "dfu_alt_info=sf 0:0=u-boot-bin raw 0x21 0x1d;" \
+   "u-boot-env raw 0x3e 0x2\0" \
ENV_MEM_LAYOUT_SETTINGS \
BOOTENV
 
-- 
2.30.2

[PATCH v2 2/5] board: sl28: generate FIT update image

[Michael Walle]

Generate a FIT update image during build. The image will be called
"u-boot.update" and can be used to build an EFI UpdateCapsule or during
DFU mode. Although, the latter isn't supported because there is no USB
OTG driver yet.

Signed-off-by: Michael Walle 
---
changes since v1:
 - new patch

 .../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi  | 35 +--
 1 file changed, 33 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi 
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
index 8538ce7984..d4b833284e 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
@@ -12,6 +12,12 @@
};
 
binman: binman {
+   multiple-images;
+   };
+};
+
+ {
+   u_boot_rom: u-boot-rom {
filename = "u-boot.rom";
pad-byte = <0xff>;
 
@@ -130,6 +136,31 @@
};
 };
 
+ {
+   u-boot-update {
+   filename = "u-boot.update";
+
+   fit {
+   description = "FIT update image";
+
+   images {
+   u-boot-bin {
+   description = "U-Boot";
+   type = "firmware";
+   os = "u-boot";
+   arch = "arm";
+   compression = "none";
+   load = <0>; /* unused */
+
+   blob {
+   filename = "u-boot.rom";
+   };
+   };
+   };
+   };
+   };
+};
+
 #ifdef CONFIG_SL28_ENABLE_SER0_CONSOLE
 / {
chosen {
@@ -139,7 +170,7 @@
 #endif
 
 #ifdef CONFIG_SL28_SPL_LOADS_ATF_BL31
- {
+_boot_rom {
fit {
images {
bl31 {
@@ -188,7 +219,7 @@
 #endif
 
 #ifdef CONFIG_SL28_SPL_LOADS_OPTEE_BL32
- {
+_boot_rom {
fit {
images {
bl32 {
-- 
2.30.2

[PATCH v2 4/5] doc: board: kontron: sl28: Reduce section levels and change title

[Michael Walle]

From: Frieder Schrempf 

In order to add other Kontron boards to the docs alongside the existing sl28 
board,
we need to reduce the levels of the sections and change the title.

Cc: Fabio Estevam 
Signed-off-by: Frieder Schrempf 
Acked-by: Michael Walle 
---
Frieder, Fabio, I took the liberty and added this patch to this series,
because the next patch depends on it. It wasn't picked up yet in the imx
queue. In fact, Frieders patches should not depend on this one, although
the documentation will be incorrectly formatted, so it should be fine if
this patch will go through the qoriq queue.

changes since v1:
 - new patch

 doc/board/kontron/sl28.rst | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/doc/board/kontron/sl28.rst b/doc/board/kontron/sl28.rst
index e458fbc607..07431986d8 100644
--- a/doc/board/kontron/sl28.rst
+++ b/doc/board/kontron/sl28.rst
@@ -1,17 +1,17 @@
 .. SPDX-License-Identifier: GPL-2.0+
 
-Summary
-===
+Kontron SMARC-sAL28
+===
 
 The Kontron SMARC-sAL28 board is a TSN-enabled dual-core ARM A72
 processor module with an on-chip 6-port TSN switch and a 3D GPU.
 
 
 Quickstart
-==
+--
 
 Compile U-Boot
---
+^^
 
 Configure and compile the binary::
 
@@ -21,7 +21,7 @@ Configure and compile the binary::
 Copy u-boot.rom to a TFTP server.
 
 Install the bootloader on the board

+^^^
 
 Please note, this bootloader doesn't support the builtin watchdog (yet),
 therefore you have to disable it, see below. Otherwise you'll end up in
@@ -36,7 +36,7 @@ disabled the builtin watchdog you might have to manually 
enter failsafe
 mode by asserting the ``FORCE_RECOV#`` line during board reset.
 
 Disable the builtin watchdog
-
+
 
 - boot into the failsafe bootloader, either by asserting the
   ``FORCE_RECOV#`` line or if you still have the original bootloader
@@ -53,7 +53,7 @@ Disable the builtin watchdog
 
 
 Useful I2C tricks
-=
+-
 
 The board has a board management controller which is not supported in
 u-boot (yet). But you can use the i2c command to access it.
@@ -68,7 +68,7 @@ u-boot (yet). But you can use the i2c command to access it.
 
 
 Non-volatile Board Configuration Bits
-=
+-
 
 The board has 16 configuration bits which are stored in the CPLD and are
 non-volatile. These can be changed by the `sl28 nvm` command.
@@ -98,21 +98,21 @@ Please note, that if the board is in failsafe mode, the 
bits will have the
 factory defaults, ie. all bits are off.
 
 Power-On Inhibit
-
+
 
 If this is set, the board doesn't automatically turn on when power is
 applied. Instead, the user has to either toggle the ``PWR_BTN#`` line or
 use any other wake-up source such as RTC alarm or Wake-on-LAN.
 
 eMMC Boot
--
+^
 
 If this is set, the RCW will be fetched from the on-board eMMC at offset
 1MiB. For further details, have a look at the `Reset Configuration Word
 Documentation`_.
 
 Watchdog
-
+
 
 By default, the CPLD watchdog is enabled in failsafe mode. Using bits 2 and
 3, the user can change its mode or disable it altogether.
@@ -127,21 +127,21 @@ Bit 2  Bit 3  Description
 =  =  ===
 
 Clock Generator Select
---
+^^
 
 The board is prepared to supply different SerDes clock speeds. But for now,
 only setting 0 is supported, otherwise the CPU will hang because the PLL
 will not lock.
 
 Clock Output Disable And Keep Devices In Reset
---
+^^
 
 To safe power, the user might disable different devices and clock output of
 the board. It is not supported to disable the "CPU SerDes clock #2" for
 now, otherwise the CPU will hang because the PLL will not lock.
 
 Automatic reset of the onboard PHYs

+^^^
 
 By default, there is no hardware reset of the onboard PHY. This is because
 for Wake-on-LAN, some registers have to retain their values. If you don't
@@ -151,7 +151,7 @@ power-on reset.
 
 
 Further documentation
-=
+-
 
 - `Vendor Documentation`_
 - `Reset Configuration Word Documentation`_
-- 
2.30.2

Re: [PATCH v7 5/5] iot2050: Enable watchdog support, but do not auto-start it

[Jan Kiszka]

On 13.09.21 16:56, Tom Rini wrote:
> On Mon, Sep 13, 2021 at 04:31:37PM +0200, Jan Kiszka wrote:
>> On 13.09.21 14:34, Tom Rini wrote:
>>> On Mon, Sep 13, 2021 at 09:57:45AM +0200, Jan Kiszka wrote:
 On 11.09.21 02:10, Tom Rini wrote:
> On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote:
>
>> From: Jan Kiszka 
>>
>> This allows to use the watchdog in custom scripts but does not enforce
>> that the OS has to support it as well.
>>
>> Signed-off-by: Jan Kiszka 
>
> Sorry for the late reply.  This causes CI to fail:
> Building current source for 1 boards (1 thread, 16 jobs per thread)
>aarch64:  +   iot2050
> +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary is 
> non-functional
> +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might be 
> non-functional
> +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input path 
> (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts) 
> (cwd='/tmp/iot2050/.bm-work/iot2050')
> +(iot2050) make[1]: *** [all] Error 1
> +(iot2050) make: *** [sub-make] Error 2
> 001 /1  iot2050
>
> And needs to be handled like ATF/OPTEE/etc where CI can build but throw
> a "THIS WILL NOT RUN CORRECTLY" type warning to the user.
>

 I was about to sent an update anyway - time passed, and now we even have
 support for the next generation integrated from the beginning. But
 related upstream DT changes are not yet merged.
>>>
>>> OK.
>>>
 But back to this issue: How can CI be fed with all those required
 binaries? The build makes no sense in their absence.
>>>
>>> To be clearer, CI isn't fed all of the binaries, we just use /dev/null
>>> in that case and try and make it clear it won't boot.  K3 isn't a good
>>> example here, but I think sunxi uses binman and handles this same class
>>> of problem?
>>>
>>
>> I'm seeing it additionally carrying a "missing-msg" property, but that
>> alone (even with missing-blob-help updated) does not make the build
>> pass. It rather seems I'm missing some "allow_missing" property for that
>> image, but even reading the code gives no clue yet how to achieve that.
>> Yet another binman mystery.
> 
> You might also need a new file in tools/binman/etype/ ?  Also, it will
> have a non-zero exit status still, but with a value of 101 which we
> check for and know that's "binary blob missing" and so OK to allow CI to
> pass on.
> 

Err, that doesn't sound like binman is making my life easier. Why can't
a I simple do something like

k3-rti-wdt-firmware {
type = "blob";
load = <0x8200>;
blob {
filename = CONFIG_WDT_K3_RTI_FW_FILE;
missing-msg = "k3-rti-wdt-firmware";
allow_missing;
};
};

and be done?

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH v7 5/5] iot2050: Enable watchdog support, but do not auto-start it

[Tom Rini]

On Mon, Sep 13, 2021 at 04:31:37PM +0200, Jan Kiszka wrote:
> On 13.09.21 14:34, Tom Rini wrote:
> > On Mon, Sep 13, 2021 at 09:57:45AM +0200, Jan Kiszka wrote:
> >> On 11.09.21 02:10, Tom Rini wrote:
> >>> On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote:
> >>>
>  From: Jan Kiszka 
> 
>  This allows to use the watchdog in custom scripts but does not enforce
>  that the OS has to support it as well.
> 
>  Signed-off-by: Jan Kiszka 
> >>>
> >>> Sorry for the late reply.  This causes CI to fail:
> >>> Building current source for 1 boards (1 thread, 16 jobs per thread)
> >>>aarch64:  +   iot2050
> >>> +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary is 
> >>> non-functional
> >>> +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might be 
> >>> non-functional
> >>> +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input path 
> >>> (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts) 
> >>> (cwd='/tmp/iot2050/.bm-work/iot2050')
> >>> +(iot2050) make[1]: *** [all] Error 1
> >>> +(iot2050) make: *** [sub-make] Error 2
> >>> 001 /1  iot2050
> >>>
> >>> And needs to be handled like ATF/OPTEE/etc where CI can build but throw
> >>> a "THIS WILL NOT RUN CORRECTLY" type warning to the user.
> >>>
> >>
> >> I was about to sent an update anyway - time passed, and now we even have
> >> support for the next generation integrated from the beginning. But
> >> related upstream DT changes are not yet merged.
> > 
> > OK.
> > 
> >> But back to this issue: How can CI be fed with all those required
> >> binaries? The build makes no sense in their absence.
> > 
> > To be clearer, CI isn't fed all of the binaries, we just use /dev/null
> > in that case and try and make it clear it won't boot.  K3 isn't a good
> > example here, but I think sunxi uses binman and handles this same class
> > of problem?
> > 
> 
> I'm seeing it additionally carrying a "missing-msg" property, but that
> alone (even with missing-blob-help updated) does not make the build
> pass. It rather seems I'm missing some "allow_missing" property for that
> image, but even reading the code gives no clue yet how to achieve that.
> Yet another binman mystery.

You might also need a new file in tools/binman/etype/ ?  Also, it will
have a non-zero exit status still, but with a value of 101 which we
check for and know that's "binary blob missing" and so OK to allow CI to
pass on.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] board: atmel: sama7g5ek: avoid rewriting of configured CONFIG_BOOTCOMMAND

[Eugen.Hristev]

On 8/19/21 2:09 PM, Eugen Hristev wrote:
> Rewrite the CONFIG_BOOTCOMMAND only if it's not previously configured from
> defconfig file.
> This allows the user to select from defconfig/menuconfig the desired
> boot command.
> Adjust the current board defconfigs to reflect the default booting command
> for the specific ENV configuration.
> 
> Signed-off-by: Eugen Hristev 
> ---

Applied to u-boot-atmel/next

Re: [PATCH 1/2] xyz-modem: Wait infinitely for initial y-modem packet

[Tom Rini]

On Mon, Sep 13, 2021 at 01:08:06PM +0200, Pali Rohár wrote:
> On Monday 13 September 2021 12:42:42 Wolfgang Denk wrote:
> > Dear Pali Rohár,
> > 
> > In message <20210910204653.3066-1-p...@kernel.org> you wrote:
> > > Now when command loady can be aborted / cancelled by CTRL+C, change wait
> > > timeout for initial packet to infinite. This would allow user to not be
> > > hurry when locating file which want to send. Commands loadb and loads
> > > already waits infinitely too.
> > 
> > I'm not sure if this is a good idea.
> > 
> > If you use loady in any kind of scripts, this would now hard hang
> > the system, while until now it was possible to recover from the
> > error.
> 
> Yes, this is a good point. But on the other hand, 'loadb' and 'loads'
> commands already have this behavior. So question is if it is better to
> have same behavior in all 'load?' commands or each 'load?' would behave
> differently... Because for software which transmit files and supports
> more protocols (e.g. both x-modem and kermit) it may be a nightmare if
> receiver behaves differently...
> 
> > This is a change to the user interface that is not really necessary,
> > so I recommend NOT to change the behaviour here, especially as it
> > does not hurt.
> 
> Well... there is an issue if you do not start file transfer in the
> timeout which current 'loady' command expects.
> 
> If you do not have integrated y-modem support in your terminal you have
> to do:
> 
> 1) open terminal and write 'loady' into U-Boot console
> 2) disconnect terminal
> 3) start y-modem software
> 4) choose file to transmit
> 5) instruct y-modem software to start transfer

So, when does this happen?  It's been a long long time since I used
minicom, but I know in screen you can do a filter to trigger the
transfer, ie:
:exec !! /home/trini/bin/load-boot-xymodem.sh
is one of the things in my notes and little script is just to sx SPL and
then sx --ymodem U-Boot itself.  I know tmux is the preferred tool of
power users these days but I assume it can do similar.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v7 5/5] iot2050: Enable watchdog support, but do not auto-start it

[Jan Kiszka]

On 13.09.21 14:34, Tom Rini wrote:
> On Mon, Sep 13, 2021 at 09:57:45AM +0200, Jan Kiszka wrote:
>> On 11.09.21 02:10, Tom Rini wrote:
>>> On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote:
>>>
 From: Jan Kiszka 

 This allows to use the watchdog in custom scripts but does not enforce
 that the OS has to support it as well.

 Signed-off-by: Jan Kiszka 
>>>
>>> Sorry for the late reply.  This causes CI to fail:
>>> Building current source for 1 boards (1 thread, 16 jobs per thread)
>>>aarch64:  +   iot2050
>>> +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary is 
>>> non-functional
>>> +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might be 
>>> non-functional
>>> +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input path 
>>> (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts) 
>>> (cwd='/tmp/iot2050/.bm-work/iot2050')
>>> +(iot2050) make[1]: *** [all] Error 1
>>> +(iot2050) make: *** [sub-make] Error 2
>>> 001 /1  iot2050
>>>
>>> And needs to be handled like ATF/OPTEE/etc where CI can build but throw
>>> a "THIS WILL NOT RUN CORRECTLY" type warning to the user.
>>>
>>
>> I was about to sent an update anyway - time passed, and now we even have
>> support for the next generation integrated from the beginning. But
>> related upstream DT changes are not yet merged.
> 
> OK.
> 
>> But back to this issue: How can CI be fed with all those required
>> binaries? The build makes no sense in their absence.
> 
> To be clearer, CI isn't fed all of the binaries, we just use /dev/null
> in that case and try and make it clear it won't boot.  K3 isn't a good
> example here, but I think sunxi uses binman and handles this same class
> of problem?
> 

I'm seeing it additionally carrying a "missing-msg" property, but that
alone (even with missing-blob-help updated) does not make the build
pass. It rather seems I'm missing some "allow_missing" property for that
image, but even reading the code gives no clue yet how to achieve that.
Yet another binman mystery.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

[PATCH] mtd: nand: raw: convert nand_dt_init() to ofnode_xx() interface

[Patrice Chotard]

nand_dt_init() is still using fdtdec_xx() interface.
If OF_LIVE flag is enabled, dt property can't be get anymore.
Updating all fdtdec_xx() interface to ofnode_xx() to solve this issue.

For doing this, node parameter type must be ofnode.

First idea was to convert "node" parameter to ofnode type inside
nand_dt_init() using offset_to_ofnode(node). But offset_to_ofnode()
is not bijective, in case OF_LIVE flag is enabled, it performs an assert().

So, this leads to update nand_chip struct flash_node field from int to
ofnode and to update all nand_dt_init() callers.

Signed-off-by: Patrice Chotard 
---

 drivers/mtd/nand/raw/denali.c  |  2 +-
 drivers/mtd/nand/raw/mxs_nand.c|  2 +-
 drivers/mtd/nand/raw/nand_base.c   | 27 +++---
 drivers/mtd/nand/raw/stm32_fmc2_nand.c |  2 +-
 drivers/mtd/nand/raw/sunxi_nand.c  |  2 +-
 include/linux/mtd/rawnand.h|  6 +++---
 6 files changed, 18 insertions(+), 23 deletions(-)

diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index ab91db8546..c827f80281 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -1246,7 +1246,7 @@ int denali_init(struct denali_nand_info *denali)
 
denali->active_bank = DENALI_INVALID_BANK;
 
-   chip->flash_node = dev_of_offset(denali->dev);
+   chip->flash_node = dev_ofnode(denali->dev);
/* Fallback to the default name if DT did not give "label" property */
if (!mtd->name)
mtd->name = "denali-nand";
diff --git a/drivers/mtd/nand/raw/mxs_nand.c b/drivers/mtd/nand/raw/mxs_nand.c
index e6bbfac4d6..748056a43e 100644
--- a/drivers/mtd/nand/raw/mxs_nand.c
+++ b/drivers/mtd/nand/raw/mxs_nand.c
@@ -1379,7 +1379,7 @@ int mxs_nand_init_ctrl(struct mxs_nand_info *nand_info)
nand->options |= NAND_NO_SUBPAGE_WRITE;
 
if (nand_info->dev)
-   nand->flash_node = dev_of_offset(nand_info->dev);
+   nand->flash_node = dev_ofnode(nand_info->dev);
 
nand->cmd_ctrl  = mxs_nand_cmd_ctrl;
 
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 3679ee727e..b1fd779884 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -29,9 +29,6 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 #include 
-#if CONFIG_IS_ENABLED(OF_CONTROL)
-#include 
-#endif
 #include 
 #include 
 #include 
@@ -4576,23 +4573,20 @@ ident_done:
 EXPORT_SYMBOL(nand_get_flash_type);
 
 #if CONFIG_IS_ENABLED(OF_CONTROL)
-#include 
-DECLARE_GLOBAL_DATA_PTR;
 
-static int nand_dt_init(struct mtd_info *mtd, struct nand_chip *chip, int node)
+static int nand_dt_init(struct mtd_info *mtd, struct nand_chip *chip, ofnode 
node)
 {
int ret, ecc_mode = -1, ecc_strength, ecc_step;
-   const void *blob = gd->fdt_blob;
const char *str;
 
-   ret = fdtdec_get_int(blob, node, "nand-bus-width", -1);
+   ret = ofnode_read_s32_default(node, "nand-bus-width", -1);
if (ret == 16)
chip->options |= NAND_BUSWIDTH_16;
 
-   if (fdtdec_get_bool(blob, node, "nand-on-flash-bbt"))
+   if (ofnode_read_bool(node, "nand-on-flash-bbt"))
chip->bbt_options |= NAND_BBT_USE_FLASH;
 
-   str = fdt_getprop(blob, node, "nand-ecc-mode", NULL);
+   str = ofnode_read_string(node, "nand-ecc-mode");
if (str) {
if (!strcmp(str, "none"))
ecc_mode = NAND_ECC_NONE;
@@ -4608,9 +4602,10 @@ static int nand_dt_init(struct mtd_info *mtd, struct 
nand_chip *chip, int node)
ecc_mode = NAND_ECC_SOFT_BCH;
}
 
-
-   ecc_strength = fdtdec_get_int(blob, node, "nand-ecc-strength", -1);
-   ecc_step = fdtdec_get_int(blob, node, "nand-ecc-step-size", -1);
+   ecc_strength = ofnode_read_s32_default(node,
+  "nand-ecc-strength", -1);
+   ecc_step = ofnode_read_s32_default(node,
+  "nand-ecc-step-size", -1);
 
if ((ecc_step >= 0 && !(ecc_strength >= 0)) ||
(!(ecc_step >= 0) && ecc_strength >= 0)) {
@@ -4627,13 +4622,13 @@ static int nand_dt_init(struct mtd_info *mtd, struct 
nand_chip *chip, int node)
if (ecc_step > 0)
chip->ecc.size = ecc_step;
 
-   if (fdt_getprop(blob, node, "nand-ecc-maximize", NULL))
+   if (ofnode_read_bool(node, "nand-ecc-maximize"))
chip->ecc.options |= NAND_ECC_MAXIMIZE;
 
return 0;
 }
 #else
-static int nand_dt_init(struct mtd_info *mtd, struct nand_chip *chip, int node)
+static int nand_dt_init(struct mtd_info *mtd, struct nand_chip *chip, ofnode 
node)
 {
return 0;
 }
@@ -4657,7 +4652,7 @@ int nand_scan_ident(struct mtd_info *mtd, int maxchips,
struct nand_flash_dev *type;
int ret;
 
-   if (chip->flash_node) {
+   if (ofnode_valid(chip->flash_node)) {
ret = nand_dt_init(mtd, chip, 

Re: Bug: qemu_arm64: Cannot access the second flash bank

[Peter Maydell]

On Mon, 13 Sept 2021 at 10:31, Matthias Brugger  wrote:
>
> Hi Robin,
>
> It's a long long time that you reported this issue.
>
> I prepared a fix in qemu for it. Would you mind to try it out? You can find a
> branch with the fix on top here:
> https://github.com/mbgg/qemu/tree/vrit-flash-dtb-bug
>
> Basically I fix the reg property to reflect the fact that the size-cell is 
> one.

Isn't #size-cells here inherited from the fdt root node (where we
set it to 2) ?

thanks
-- PMM

Re: [PATCH 1/1] Revert "arm64: Layerscape: Survive LPI one-way reset workaround"

[Rayagonda Kokatanur]

On Mon, Sep 13, 2021 at 11:29 AM Priyanka Jain (OSS)
 wrote:
>
>
>
> >-Original Message-
> >From: U-Boot  On Behalf Of Z.Q. Hou
> >Sent: Friday, September 10, 2021 12:13 PM
> >To: Tom Rini ; u-boot@lists.denx.de;
> >rayagonda.kokata...@broadcom.com
> >Cc: Priyanka Jain 
> >Subject: RE: [PATCH 1/1] Revert "arm64: Layerscape: Survive LPI one-way reset
> >workaround"
> >
> >+ author of gic_lpi_syscon driver
> >
> >Hi Rayagonda,
> >
> >Please add the binding for gic_lpi_syscon driver.
> >
> >Thanks,
> >Zhiqiang
> >
> >> -Original Message-
> >> From: Tom Rini 
> >> Sent: 2021年8月26日 5:05
> >> To: u-boot@lists.denx.de
> >> Cc: Z.Q. Hou ; Priyanka Jain
> >> 
> >> Subject: [PATCH 1/1] Revert "arm64: Layerscape: Survive LPI one-way
> >> reset workaround"
> >>
> >> Ad-hoc bindings that are not part of the upstream device tree /
> >> bindings are not allowed in-tree.  Only bindings that are in-progress
> >> with upstream and then re-synced once agreed upon are.
> >>
> >> This reverts commit af288cb291da3abef6be0875527729296f7de7a0.
> >>
> >> Cc: Hou Zhiqiang 
> >> Cc: Priyanka Jain 
> >> Reported-by: Michael Walle 
> >> Signed-off-by: Tom Rini 
> >> ---
> >>  arch/arm/cpu/armv8/fsl-layerscape/soc.c | 17 +
> >>  arch/arm/dts/fsl-ls1028a.dtsi   |  6 --
> >>  arch/arm/dts/fsl-ls1088a.dtsi   |  6 --
> >>  arch/arm/dts/fsl-ls2080a.dtsi   |  6 --
> >>  arch/arm/dts/fsl-lx2160a.dtsi   |  6 --
> >>  5 files changed, 1 insertion(+), 40 deletions(-)
> >>
> >> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> >> b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> >> index 42a096854629..12a64baf 100644
> >> --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> >> +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> >> @@ -43,22 +43,7 @@ DECLARE_GLOBAL_DATA_PTR;  #ifdef
> >CONFIG_GIC_V3_ITS
> >> int ls_gic_rd_tables_init(void *blob)  {
> >> -struct fdt_memory lpi_base;
> >> -fdt_addr_t addr;
> >> -fdt_size_t size;
> >> -int offset, ret;
> >> -
> >> -offset = fdt_path_offset(gd->fdt_blob, "/syscon@0x8000");
> >> -addr = fdtdec_get_addr_size_auto_noparent(gd->fdt_blob, offset,
> >> "reg",
> >> -  0, , false);
> >> -
> >> -lpi_base.start = addr;
> >> -lpi_base.end = addr + size - 1;
> >> -ret = fdtdec_add_reserved_memory(blob, "lpi_rd_table", _base,
> >> NULL, false);
> >> -if (ret) {
> >> -debug("%s: failed to add reserved memory\n", __func__);
> >> -return ret;
> >> -}
> >> +int ret;
> >>
> >>  ret = gic_lpi_tables_init();
> >>  if (ret)
> >> diff --git a/arch/arm/dts/fsl-ls1028a.dtsi
> >> b/arch/arm/dts/fsl-ls1028a.dtsi index 50f9b527cde1..53b052ed3271
> >> 100644
> >> --- a/arch/arm/dts/fsl-ls1028a.dtsi
> >> +++ b/arch/arm/dts/fsl-ls1028a.dtsi
> >> @@ -44,12 +44,6 @@
> >>   IRQ_TYPE_LEVEL_LOW)>;
> >>  };
> >>
> >> -gic_lpi_base: syscon@0x8000 {
> >> -compatible = "gic-lpi-base";
> >> -reg = <0x0 0x8000 0x0 0x10>;
> >> -max-gic-redistributors = <2>;
> >> -};
> >> -
> >>  timer {
> >>  compatible = "arm,armv8-timer";
> >>  interrupts =  >> a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi index
> >> 64caa600ad77..3a5a50fb8313 100644
> >> --- a/arch/arm/dts/fsl-ls1088a.dtsi
> >> +++ b/arch/arm/dts/fsl-ls1088a.dtsi
> >> @@ -27,12 +27,6 @@
> >>  interrupts = <1 9 0x4>;
> >>  };
> >>
> >> -gic_lpi_base: syscon@0x8000 {
> >> -compatible = "gic-lpi-base";
> >> -reg = <0x0 0x8000 0x0 0x10>;
> >> -max-gic-redistributors = <8>;
> >> -};
> >> -
> >>  timer {
> >>  compatible = "arm,armv8-timer";
> >>  interrupts = <1 13 0x8>, /* Physical Secure PPI, active-low 
> >> */ diff
> >> --git a/arch/arm/dts/fsl-ls2080a.dtsi b/arch/arm/dts/fsl-ls2080a.dtsi
> >> index 7374d580e07e..278daeeb6eea 100644
> >> --- a/arch/arm/dts/fsl-ls2080a.dtsi
> >> +++ b/arch/arm/dts/fsl-ls2080a.dtsi
> >> @@ -27,12 +27,6 @@
> >>  interrupts = <1 9 0x4>;
> >>  };
> >>
> >> -gic_lpi_base: syscon@0x8000 {
> >> -compatible = "gic-lpi-base";
> >> -reg = <0x0 0x8000 0x0 0x10>;
> >> -max-gic-redistributors = <8>;
> >> -};
> >> -
> >>  timer {
> >>  compatible = "arm,armv8-timer";
> >>  interrupts = <1 13 0x8>, /* Physical Secure PPI, active-low 
> >> */ diff
> >> --git a/arch/arm/dts/fsl-lx2160a.dtsi b/arch/arm/dts/fsl-lx2160a.dtsi
> >> index
> >> a6f0e9bc56be..3b5f0d119e76 100644
> >> --- a/arch/arm/dts/fsl-lx2160a.dtsi
> >> +++ b/arch/arm/dts/fsl-lx2160a.dtsi
> >> @@ -43,12 +43,6 @@
> >>  interrupts = <1 9 0x4>;
> >>  };
> >>
> >> -gic_lpi_base: syscon@0x8000 {
> >> -compatible = "gic-lpi-base";
> >> -

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

[Rayagonda Kokatanur]

On Wed, Aug 25, 2021 at 6:55 PM Bharat Kumar Reddy Gooty
 wrote:
>
> From: Rayagonda Kokatanur 
>
> IPROC qspi driver supports both BSPI and MSPI modes.
>
> Signed-off-by: Rayagonda Kokatanur 
> Signed-off-by: Bharat Gooty 
> ---
>  drivers/spi/Kconfig  |   6 +
>  drivers/spi/Makefile |   1 +
>  drivers/spi/iproc_qspi.c | 736 +++
>  drivers/spi/iproc_qspi.h |  18 +
>  4 files changed, 761 insertions(+)
>  create mode 100644 drivers/spi/iproc_qspi.c
>  create mode 100644 drivers/spi/iproc_qspi.h
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index e12699bec7..3253d6badf 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -178,6 +178,12 @@ config ICH_SPI
>   access the SPI NOR flash on platforms embedding this Intel
>   ICH IP core.
>
> +config IPROC_QSPI
> +   bool "QSPI driver for BCM iProc QSPI Controller"
> +   help
> + This selects the BCM iProc QSPI controller.
> + This driver support spi flash single, quad and memory reads.
> +
>  config KIRKWOOD_SPI
> bool "Marvell Kirkwood SPI Driver"
> help
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index d2f24bccef..8697631870 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_FSL_DSPI) += fsl_dspi.o
>  obj-$(CONFIG_FSL_ESPI) += fsl_espi.o
>  obj-$(CONFIG_SYNQUACER_SPI) += spi-synquacer.o
>  obj-$(CONFIG_ICH_SPI) +=  ich.o
> +obj-$(CONFIG_IPROC_QSPI) += iproc_qspi.o
>  obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
>  obj-$(CONFIG_MESON_SPIFC) += meson_spifc.o
>  obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
> diff --git a/drivers/spi/iproc_qspi.c b/drivers/spi/iproc_qspi.c
> new file mode 100644
> index 00..89c6a56858
> --- /dev/null
> +++ b/drivers/spi/iproc_qspi.c
> @@ -0,0 +1,736 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2020-2021 Broadcom
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "iproc_qspi.h"
> +
> +/* 175MHz */
> +#define QSPI_AXI_CLK   17500
> +#define QSPI_DEF_SCK_FREQ  5000
> +#define QSPI_WAIT_TIMEOUT_MS   200U
> +#define DWORD_ALIGNED(a)   (!(((ulong)(a)) & 3))
> +
> +/* Chip attributes */
> +#define SPBR_MIN   8U
> +#define SPBR_MAX   255U
> +#define NUM_CDRAM  16U
> +
> +#define CDRAM_PCS0 2
> +#define CDRAM_CONT BIT(7)
> +#define CDRAM_BITS_EN  BIT(6)
> +#define CDRAM_QUAD_MODEBIT(8)
> +#define CDRAM_RBIT_INPUT   BIT(10)
> +#define MSPI_SPE   BIT(6)
> +#define MSPI_CONT_AFTER_CMDBIT(7)
> +
> +/* Register fields */
> +#define MSPI_SPCR0_MSB_BITS_8  0x0020
> +#define BSPI_RAF_CONTROL_START_MASK0x0001
> +#define BSPI_RAF_STATUS_SESSION_BUSY_MASK  0x0001
> +#define BSPI_RAF_STATUS_FIFO_EMPTY_MASK0x0002
> +#define BSPI_BITS_PER_PHASE_ADDR_MARK  0x0001
> +#define BSPI_BITS_PER_CYCLE_DATA_SHIFT 0
> +#define BSPI_BITS_PER_CYCLE_ADDR_SHIFT 16
> +#define BSPI_STRAP_OVERRIDE_DATA_QUAD_SHIFT3
> +#define BSPI_STRAP_OVERRIDE_DATA_DUAL_SHIFT1
> +#define BSPI_STRAP_OVERRIDE_SHIFT  0
> +
> +/* MSPI registers */
> +#define MSPI_SPCR0_LSB_REG 0x000
> +#define MSPI_SPCR0_MSB_REG 0x004
> +#define MSPI_SPCR1_LSB_REG 0x008
> +#define MSPI_SPCR1_MSB_REG 0x00c
> +#define MSPI_NEWQP_REG 0x010
> +#define MSPI_ENDQP_REG 0x014
> +#define MSPI_SPCR2_REG 0x018
> +#define MSPI_STATUS_REG0x020
> +#define MSPI_CPTQP_REG 0x024
> +#define MSPI_TXRAM_REG 0x040
> +#define MSPI_RXRAM_REG 0x0c0
> +#define MSPI_CDRAM_REG 0x140
> +#define MSPI_WRITE_LOCK_REG0x180
> +#define MSPI_DISABLE_FLUSH_GEN_REG 0x184
> +
> +/* BSPI registers */
> +#define BSPI_REVISION_ID_REG   0x000
> +#define BSPI_SCRATCH_REG   0x004
> +#define BSPI_MAST_N_BOOT_CTRL_REG  0x008
> +#define BSPI_BUSY_STATUS_REG   0x00c
> +#define BSPI_INTR_STATUS_REG   0x010
> +#define BSPI_B0_STATUS_REG 0x014
> +#define BSPI_B0_CTRL_REG   0x018
> +#define BSPI_B1_STATUS_REG 0x01c
> +#define BSPI_B1_CTRL_REG   0x020
> +#define BSPI_STRAP_OVERRIDE_CTRL_REG   0x024
> +#define BSPI_FLEX_MODE_ENABLE_REG

Re: [PATCH v1 1/2] pinctrl: single: Parse gpio details from dt

[Rayagonda Kokatanur]

On Tue, Aug 24, 2021 at 3:46 PM Bharat Kumar Reddy Gooty
 wrote:
>
> From: Bharat Gooty 
>
> Parse different gpio properties from dt as part of probe
> function. This detail is required to enable pinctrl pad
> later when gpio lines are requested.
>
> Signed-off-by: Rayagonda Kokatanur 
> Signed-off-by: Bharat Gooty 
> ---
>  drivers/pinctrl/pinctrl-single.c | 52 
>  1 file changed, 52 insertions(+)
>
> diff --git a/drivers/pinctrl/pinctrl-single.c 
> b/drivers/pinctrl/pinctrl-single.c
> index cf9ad3670f..0f96cd5870 100644
> --- a/drivers/pinctrl/pinctrl-single.c
> +++ b/drivers/pinctrl/pinctrl-single.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -44,11 +45,27 @@ struct single_func {
> unsigned int *pins;
>  };
>
> +/**
> + * struct single_gpiofunc_range - pin ranges with same mux value of gpio fun
> + * @offset: offset base of pins
> + * @npins: number pins with the same mux value of gpio function
> + * @gpiofunc: mux value of gpio function
> + * @node: list node
> + */
> +struct single_gpiofunc_range {
> +   u32 offset;
> +   u32 npins;
> +   u32 gpiofunc;
> +   struct list_head node;
> +};
> +
>  /**
>   * struct single_priv - private data
>   * @bits_per_pin: number of bits per pin
>   * @npins: number of selectable pins
>   * @pin_name: temporary buffer to store the pin name
> + * @functions: list pin functions
> + * @gpiofuncs: list gpio functions
>   */
>  struct single_priv {
>  #if (IS_ENABLED(CONFIG_SANDBOX))
> @@ -58,6 +75,7 @@ struct single_priv {
> unsigned int npins;
> char pin_name[PINNAME_SIZE];
> struct list_head functions;
> +   struct list_head gpiofuncs;
>  };
>
>  /**
> @@ -454,6 +472,36 @@ static int single_get_pins_count(struct udevice *dev)
> return priv->npins;
>  }
>
> +static int single_add_gpio_func(struct udevice *dev)
> +{
> +   struct single_priv *priv = dev_get_priv(dev);
> +   const char *propname = "pinctrl-single,gpio-range";
> +   const char *cellname = "#pinctrl-single,gpio-range-cells";
> +   struct single_gpiofunc_range *range;
> +   struct ofnode_phandle_args gpiospec;
> +   int ret, i;
> +
> +   for (i = 0; ; i++) {
> +   ret = ofnode_parse_phandle_with_args(dev_ofnode(dev), 
> propname,
> +cellname, 0, i, 
> );
> +   /* Do not treat it as error. Only treat it as end condition. 
> */
> +   if (ret) {
> +   ret = 0;
> +   break;
> +   }
> +   range = devm_kzalloc(dev, sizeof(*range), GFP_KERNEL);
> +   if (!range) {
> +   ret = -ENOMEM;
> +   break;
> +   }
> +   range->offset = gpiospec.args[0];
> +   range->npins = gpiospec.args[1];
> +   range->gpiofunc = gpiospec.args[2];
> +   list_add_tail(>node, >gpiofuncs);
> +   }
> +   return ret;
> +}
> +
>  static int single_probe(struct udevice *dev)
>  {
> struct single_pdata *pdata = dev_get_plat(dev);
> @@ -461,6 +509,7 @@ static int single_probe(struct udevice *dev)
> u32 size;
>
> INIT_LIST_HEAD(>functions);
> +   INIT_LIST_HEAD(>gpiofuncs);
>
> size = pdata->offset + pdata->width / BITS_PER_BYTE;
> #if (CONFIG_IS_ENABLED(SANDBOX))
> @@ -483,6 +532,9 @@ static int single_probe(struct udevice *dev)
> priv->npins *= (pdata->width / priv->bits_per_pin);
> }
>
> +   if (single_add_gpio_func(dev))
> +   dev_dbg(dev, "gpio functions are not added\n");
> +
> dev_dbg(dev, "%d pins\n", priv->npins);
> return 0;
>  }
> --
> 2.17.1
>

Acked-by: Rayagonda Kokatanur 


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH v1 2/2] pinctrl: single: Add request() api

[Rayagonda Kokatanur]

On Tue, Aug 24, 2021 at 3:46 PM Bharat Kumar Reddy Gooty
 wrote:
>
> From: Bharat Gooty 
>
> Add pinctrl_ops->request api to configure pctrl
> pad register in gpio mode.
>
> Signed-off-by: Rayagonda Kokatanur 
> Signed-off-by: Bharat Gooty 
> ---
>  drivers/pinctrl/pinctrl-single.c | 34 
>  1 file changed, 34 insertions(+)
>
> diff --git a/drivers/pinctrl/pinctrl-single.c 
> b/drivers/pinctrl/pinctrl-single.c
> index 0f96cd5870..8fc07e3498 100644
> --- a/drivers/pinctrl/pinctrl-single.c
> +++ b/drivers/pinctrl/pinctrl-single.c
> @@ -250,6 +250,39 @@ static int single_get_pin_muxing(struct udevice *dev, 
> unsigned int pin,
> return 0;
>  }
>
> +static int single_request(struct udevice *dev, int pin, int flags)
> +{
> +   struct single_priv *priv = dev_get_priv(dev);
> +   struct single_pdata *pdata = dev_get_plat(dev);
> +   struct single_gpiofunc_range *frange = NULL;
> +   struct list_head *pos, *tmp;
> +   phys_addr_t reg;
> +   int mux_bytes = 0;
> +   u32 data;
> +
> +   /* If function mask is null, needn't enable it. */
> +   if (!pdata->mask)
> +   return -ENOTSUPP;
> +
> +   list_for_each_safe(pos, tmp, >gpiofuncs) {
> +   frange = list_entry(pos, struct single_gpiofunc_range, node);
> +   if ((pin >= frange->offset + frange->npins) ||
> +   pin < frange->offset)
> +   continue;
> +
> +   mux_bytes = pdata->width / BITS_PER_BYTE;
> +   reg = pdata->base + pin * mux_bytes;
> +
> +   data = single_read(dev, reg);
> +   data &= ~pdata->mask;
> +   data |= frange->gpiofunc;
> +   single_write(dev, data, reg);
> +   break;
> +   }
> +
> +   return 0;
> +}
> +
>  static struct single_func *single_allocate_function(struct udevice *dev,
> unsigned int group_pins)
>  {
> @@ -587,6 +620,7 @@ const struct pinctrl_ops single_pinctrl_ops = {
> .get_pin_name = single_get_pin_name,
> .set_state = single_set_state,
> .get_pin_muxing = single_get_pin_muxing,
> +   .request = single_request,
>  };
>
>  static const struct udevice_id single_pinctrl_match[] = {
> --
> 2.17.1
>

Acked-by: Rayagonda Kokatanur 


smime.p7s
Description: S/MIME Cryptographic Signature

[PATCH v3 4/4] mtd: spi-nor-core: Add support for Macronix Octal flash

[JaimeLiao]

Adding Macronix Octal flash for Octal DTR support.

The octaflash series can be divided into the following types:

MX25 series : Serial NOR Flash.
MX66 series : Serial NOR Flash with stacked die.(Size larger than 1Gb)
LM/UM series : Up to 250MHz clock frequency with both DTR/STR operation.
LW/UW series : Support simultaneous Read-while-Write operation in multiple
   bank architecture. Read-while-write feature which means read
   data one bank while another bank is programing or erasing.

MX25LM : 3.0V Octal I/O
 
-https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf

MX25UM : 1.8V Octal I/O
 
-https://www.mxic.com.tw/Lists/Datasheet/Attachments/7525/MX25UM51245G%20Extreme%20Speed,%201.8V,%20512Mb,%20v1.0.pdf

MX66LM : 3.0V Octal I/O with stacked die
 
-https://www.mxic.com.tw/Lists/Datasheet/Attachments/7929/MX66LM1G45G,%203V,%201Gb,%20v1.1.pdf

MX66UM : 1.8V Octal I/O with stacked die
 
-https://www.mxic.com.tw/Lists/Datasheet/Attachments/7721/MX66UM1G45G,%201.8V,%201Gb,%20v1.1.pdf

MX25LW : 3.0V Octal I/O with Read-while-Write
MX25UW : 1.8V Octal I/O with Read-while-Write
MX66LW : 3.0V Octal I/O with Read-while-Write and stack die
MX66UW : 1.8V Octal I/O with Read-while-Write and stack die

About LW/UW series, please contact us freely if you have any
questions. For adding Octal NOR Flash IDs, we have validated
each Flash on plateform zynq-picozed.

Signed-off-by: JaimeLiao 
---
 drivers/mtd/spi/spi-nor-ids.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index cb3a08872d..5c13ea3a78 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -169,7 +169,27 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("mx66l1g45g",  0xc2201b, 0, 64 * 1024, 2048, SECT_4K | 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("mx25l1633e", 0xc22415, 0, 64 * 1024,   32, SPI_NOR_QUAD_READ | 
SPI_NOR_4B_OPCODES | SECT_4K) },
{ INFO("mx25r6435f", 0xc22817, 0, 64 * 1024,   128,  SECT_4K) },
-   { INFO("mx66uw2g345g", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx66uw2g345gx0", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx66lm1g45g",0xc2853b, 0, 32 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx25lm51245g",   0xc2853a, 0, 16 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx25lw51245g",   0xc2863a, 0, 16 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx25lm25645g",   0xc28539, 0, 8 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx66um2g45g",0xc2803c, 0, 64 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx66uw2g345g",   0xc2843c, 0, 64 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx66um1g45g",0xc2803b, 0, 32 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx66uw1g45g",0xc2813b, 0, 32 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx25um51245g",   0xc2803a, 0, 16 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx25uw51245g",   0xc2813a, 0, 16 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx25uw51345g",   0xc2843a, 0, 16 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx25um25645g",   0xc28039, 0, 8 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx25uw25645g",   0xc28139, 0, 8 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx25um25345g",   0xc28339, 0, 8 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx25uw25345g",   0xc28439, 0, 8 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx25uw12845g",   0xc28138, 0, 4 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx25uw12a45g",   0xc28938, 0, 4 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx25uw12345g",   0xc28438, 0, 4 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx25uw6445g",0xc28137, 0, 2 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("mx25uw6345g",0xc28437, 0, 2 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
 #endif
 
 #ifdef CONFIG_SPI_FLASH_STMICRO/* STMICRO */
-- 
2.17.1

[PATCH v3 3/4] mtd: spi-nor-core: set 4byte opcode when possible

[JaimeLiao]

Following linux kernel to check address width and 4byte flag to enable
4byte opcode setting.

Signed-off-by: JaimeLiao 
---
 drivers/mtd/spi/spi-nor-core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 4bcd58d839..81c61d87bc 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -3902,6 +3902,10 @@ int spi_nor_scan(struct spi_nor *nor)
return -EINVAL;
}
 
+   /* Set 4byte opcodes when possible. */
+   if (nor->addr_width == 4 && info->flags & SPI_NOR_4B_OPCODES)
+   spi_nor_set_4byte_opcodes(nor, info);
+
/* Send all the required SPI flash commands to initialize device */
ret = spi_nor_init(nor);
if (ret)
-- 
2.17.1

[PATCH v3 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset

[JaimeLiao]

Power-on-Reset is a method to restore flash back to 1S-1S-1S mode from 8D-8D-8D
in the begging of probe.

Command extension type is not standardized across flash vendors in DTR mode.

For suiting different vendor flash devices, adding a flag to seperate types if
nor->cmd_ext_type didn't configure from SFDP.

Signed-off-by: JaimeLiao 
---
 drivers/mtd/spi/Kconfig| 6 ++
 drivers/mtd/spi/spi-nor-core.c | 7 ++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
index 67599b32c9..d850480401 100644
--- a/drivers/mtd/spi/Kconfig
+++ b/drivers/mtd/spi/Kconfig
@@ -97,6 +97,12 @@ config SPI_FLASH_SMART_HWCAPS
 can support a type of operation in a much more refined way compared
 to using flags like SPI_RX_DUAL, SPI_TX_QUAD, etc.
 
+config SPI_NOR_CMD_EXT_INVERT
+   bool "Command extension type is INVERT for SPI NOR flashed"
+   default n
+   help
+Define command extension type is INVERT.
+
 config SPI_FLASH_SOFT_RESET
bool "Software Reset support for SPI NOR flashes"
default n
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index b8dda02aa7..4bcd58d839 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -3661,7 +3661,12 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
enum spi_nor_cmd_ext ext;
 
ext = nor->cmd_ext_type;
-   nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
+   if (!nor->cmd_ext_type) {
+   nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
+#ifdef CONFIG_SPI_NOR_CMD_EXT_INVERT
+   nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
+#endif
+   }
 
op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN, 0),
SPI_MEM_OP_NO_DUMMY,
-- 
2.17.1

[PATCH v3 1/4] mtd: spi-nor: macronix: add support for Macronix Octal

[JaimeLiao]

Follow patch "f6adec1af4b2f5d3012480c6cdce7743b74a6156" for adding
Macronix flash in Octal DTR mode.

Enable Octal DTR mode with 20 dummy cycles to allow running at the
maximum supported frequency.
 
-https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf

Signed-off-by: JaimeLiao 
---
 drivers/mtd/spi/Kconfig|  7 +++
 drivers/mtd/spi/spi-nor-core.c | 83 ++
 include/linux/mtd/spi-nor.h| 13 +-
 3 files changed, 101 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
index 1b2ef37e92..67599b32c9 100644
--- a/drivers/mtd/spi/Kconfig
+++ b/drivers/mtd/spi/Kconfig
@@ -162,6 +162,13 @@ config SPI_FLASH_MACRONIX
help
  Add support for various Macronix SPI flash chips (MX25Lxxx)
 
+config SPI_FLASH_MACRONIX_OCTAL
+   bool "Macronix octal flash support"
+   depends on SPI_FLASH_MACRONIX
+   help
+Add support for the Macronix octal flash. This is a separate config
+because the fixup hooks octal enable for this flash.
+
 config SPI_FLASH_SPANSION
bool "Spansion SPI flash support"
help
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index d5d905fa5a..b8dda02aa7 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -3489,6 +3489,85 @@ static struct spi_nor_fixups mt35xu512aba_fixups = {
 };
 #endif /* CONFIG_SPI_FLASH_MT35XU */
 
+#ifdef CONFIG_SPI_FLASH_MACRONIX_OCTAL
+/**
+ * spi_nor_macronix_octal_dtr_enable() - set DTR OPI Enable bit in 
Configuration Register 2.
+ * @nor:   pointer to a 'struct spi_nor'
+ *
+ * Set the DTR OPI Enable (DOPI) bit in Configuration Register 2.
+ * Bit 2 of  Configuration Register 2 is the DOPI bit for Macronix like OPI 
memories.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spi_nor_macronix_octal_dtr_enable(struct spi_nor *nor)
+{
+   struct spi_mem_op op;
+   int ret;
+   u8 buf;
+
+   ret = write_enable(nor);
+   if (ret)
+   return ret;
+
+   buf = SPINOR_REG_MXIC_DC_20;
+   op = (struct spi_mem_op)
+   SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_CR2, 1),
+  SPI_MEM_OP_ADDR(4, SPINOR_REG_MXIC_CR2_DC, 1),
+  SPI_MEM_OP_NO_DUMMY,
+  SPI_MEM_OP_DATA_OUT(1, , 1));
+
+   ret = spi_mem_exec_op(nor->spi, );
+   if (ret)
+   return ret;
+
+   ret = spi_nor_wait_till_ready(nor);
+   if (ret)
+   return ret;
+
+   nor->read_dummy = MXIC_MAX_DC;
+   ret = write_enable(nor);
+   if (ret)
+   return ret;
+
+   buf = SPINOR_REG_MXIC_OPI_DTR_EN;
+   op = (struct spi_mem_op)
+   SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_CR2, 1),
+  SPI_MEM_OP_ADDR(4, SPINOR_REG_MXIC_CR2_MODE, 1),
+  SPI_MEM_OP_NO_DUMMY,
+  SPI_MEM_OP_DATA_OUT(1, , 1));
+
+   ret = spi_mem_exec_op(nor->spi, );
+   if (ret) {
+   dev_err(nor->dev, "Failed to enable octal DTR mode\n");
+   return ret;
+   }
+   nor->reg_proto = SNOR_PROTO_8_8_8_DTR;
+
+   return 0;
+}
+
+static void macronix_octal_default_init(struct spi_nor *nor)
+{
+   nor->octal_dtr_enable = spi_nor_macronix_octal_dtr_enable;
+}
+
+static void macronix_octal_post_sfdp_fixup(struct spi_nor *nor,
+struct spi_nor_flash_parameter *params)
+{
+   /*
+* Adding SNOR_HWCAPS_PP_8_8_8_DTR in hwcaps.mask when
+* SPI_NOR_OCTAL_DTR_READ flag exists.
+*/
+   if (params->hwcaps.mask & SNOR_HWCAPS_READ_8_8_8_DTR)
+   params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
+}
+
+static struct spi_nor_fixups macronix_octal_fixups = {
+   .default_init = macronix_octal_default_init,
+   .post_sfdp = macronix_octal_post_sfdp_fixup,
+};
+#endif /* CONFIG_SPI_FLASH_MACRONIX_OCTAL */
+
 /** spi_nor_octal_dtr_enable() - enable Octal DTR I/O if needed
  * @nor: pointer to a 'struct spi_nor'
  *
@@ -3655,6 +3734,10 @@ void spi_nor_set_fixups(struct spi_nor *nor)
if (!strcmp(nor->info->name, "mt35xu512aba"))
nor->fixups = _fixups;
 #endif
+
+#ifdef CONFIG_SPI_FLASH_MACRONIX_OCTAL
+   nor->fixups = _octal_fixups;
+#endif
 }
 
 int spi_nor_scan(struct spi_nor *nor)
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 7ddc4ba2bf..2ad579f66d 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -116,8 +116,17 @@
 #define XSR_RDYBIT(7)  /* Ready */
 
 /* Used for Macronix and Winbond flashes. */
-#define SPINOR_OP_EN4B 0xb7/* Enter 4-byte mode */
-#define SPINOR_OP_EX4B 0xe9/* Exit 4-byte mode */
+#define SPINOR_OP_EN4B 0xb7/* Enter 4-byte mode */
+#define 

[PATCH v3 0/4] Add octal DTR support for Macronix flash

[JaimeLiao]

This series add support for Macronix octal DTR flash, add second time
Softreset with "INVERT" command extension type and follow linux kernel
to enable 4byte opcode when possible.

v3:
  Add flag  SPI_NOR_CMD_EXT_INVERT to seperate command extension types.
  replace CONFIG_SPI_FLASH_MACRONIX with SPI_FLASH_MACRONIX_OCTAL for
  spi_nor_macronix_octal_dtr_enable function.
v2:
  add ret checking for write enable in spi_nor_macronix_octal_dtr_enable
  function.

JaimeLiao (4):
  mtd: spi-nor: macronix: add support for Macronix Octal
  mtd: spi-nor-core: Adding different type of command extension in Soft
Reset
  mtd: spi-nor-core: set 4byte opcode when possible
  mtd: spi-nor-core: Add support for Macronix Octal flash

 drivers/mtd/spi/Kconfig| 13 +
 drivers/mtd/spi/spi-nor-core.c | 94 +-
 drivers/mtd/spi/spi-nor-ids.c  | 22 +++-
 include/linux/mtd/spi-nor.h| 13 -
 4 files changed, 138 insertions(+), 4 deletions(-)

-- 
2.17.1

Re: Bug: qemu_arm64: Cannot access the second flash bank

[Matthias Brugger]

On 13/09/2021 11:40, Peter Maydell wrote:

On Mon, 13 Sept 2021 at 10:31, Matthias Brugger  wrote:


Hi Robin,

It's a long long time that you reported this issue.

I prepared a fix in qemu for it. Would you mind to try it out? You can find a
branch with the fix on top here:
https://github.com/mbgg/qemu/tree/vrit-flash-dtb-bug

Basically I fix the reg property to reflect the fact that the size-cell is one.


Isn't #size-cells here inherited from the fdt root node (where we
set it to 2) ?



Yes, you are right. After a lot of digging I realized that this should be 
fixed, by:
492b9917c68 ("cfi_flash: Fix devicetree address determination")

ae6b33dcc34 ("dm: fix ofnode_read_addr/size_cells()")


Sorry for the noise.

Matthias

Re: [PATCH 1/1] Revert "arm64: Layerscape: Survive LPI one-way reset workaround"

[Tom Rini]

On Mon, Sep 13, 2021 at 01:22:10PM +0530, Rayagonda Kokatanur wrote:
> On Mon, Sep 13, 2021 at 11:29 AM Priyanka Jain (OSS)
>  wrote:
> >
> >
> >
> > >-Original Message-
> > >From: U-Boot  On Behalf Of Z.Q. Hou
> > >Sent: Friday, September 10, 2021 12:13 PM
> > >To: Tom Rini ; u-boot@lists.denx.de;
> > >rayagonda.kokata...@broadcom.com
> > >Cc: Priyanka Jain 
> > >Subject: RE: [PATCH 1/1] Revert "arm64: Layerscape: Survive LPI one-way 
> > >reset
> > >workaround"
> > >
> > >+ author of gic_lpi_syscon driver
> > >
> > >Hi Rayagonda,
> > >
> > >Please add the binding for gic_lpi_syscon driver.
> > >
> > >Thanks,
> > >Zhiqiang
> > >
> > >> -Original Message-
> > >> From: Tom Rini 
> > >> Sent: 2021年8月26日 5:05
> > >> To: u-boot@lists.denx.de
> > >> Cc: Z.Q. Hou ; Priyanka Jain
> > >> 
> > >> Subject: [PATCH 1/1] Revert "arm64: Layerscape: Survive LPI one-way
> > >> reset workaround"
> > >>
> > >> Ad-hoc bindings that are not part of the upstream device tree /
> > >> bindings are not allowed in-tree.  Only bindings that are in-progress
> > >> with upstream and then re-synced once agreed upon are.
> > >>
> > >> This reverts commit af288cb291da3abef6be0875527729296f7de7a0.
> > >>
> > >> Cc: Hou Zhiqiang 
> > >> Cc: Priyanka Jain 
> > >> Reported-by: Michael Walle 
> > >> Signed-off-by: Tom Rini 
> > >> ---
> > >>  arch/arm/cpu/armv8/fsl-layerscape/soc.c | 17 +
> > >>  arch/arm/dts/fsl-ls1028a.dtsi   |  6 --
> > >>  arch/arm/dts/fsl-ls1088a.dtsi   |  6 --
> > >>  arch/arm/dts/fsl-ls2080a.dtsi   |  6 --
> > >>  arch/arm/dts/fsl-lx2160a.dtsi   |  6 --
> > >>  5 files changed, 1 insertion(+), 40 deletions(-)
> > >>
> > >> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > >> b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > >> index 42a096854629..12a64baf 100644
> > >> --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > >> +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > >> @@ -43,22 +43,7 @@ DECLARE_GLOBAL_DATA_PTR;  #ifdef
> > >CONFIG_GIC_V3_ITS
> > >> int ls_gic_rd_tables_init(void *blob)  {
> > >> -struct fdt_memory lpi_base;
> > >> -fdt_addr_t addr;
> > >> -fdt_size_t size;
> > >> -int offset, ret;
> > >> -
> > >> -offset = fdt_path_offset(gd->fdt_blob, "/syscon@0x8000");
> > >> -addr = fdtdec_get_addr_size_auto_noparent(gd->fdt_blob, offset,
> > >> "reg",
> > >> -  0, , false);
> > >> -
> > >> -lpi_base.start = addr;
> > >> -lpi_base.end = addr + size - 1;
> > >> -ret = fdtdec_add_reserved_memory(blob, "lpi_rd_table", _base,
> > >> NULL, false);
> > >> -if (ret) {
> > >> -debug("%s: failed to add reserved memory\n", __func__);
> > >> -return ret;
> > >> -}
> > >> +int ret;
> > >>
> > >>  ret = gic_lpi_tables_init();
> > >>  if (ret)
> > >> diff --git a/arch/arm/dts/fsl-ls1028a.dtsi
> > >> b/arch/arm/dts/fsl-ls1028a.dtsi index 50f9b527cde1..53b052ed3271
> > >> 100644
> > >> --- a/arch/arm/dts/fsl-ls1028a.dtsi
> > >> +++ b/arch/arm/dts/fsl-ls1028a.dtsi
> > >> @@ -44,12 +44,6 @@
> > >>   IRQ_TYPE_LEVEL_LOW)>;
> > >>  };
> > >>
> > >> -gic_lpi_base: syscon@0x8000 {
> > >> -compatible = "gic-lpi-base";
> > >> -reg = <0x0 0x8000 0x0 0x10>;
> > >> -max-gic-redistributors = <2>;
> > >> -};
> > >> -
> > >>  timer {
> > >>  compatible = "arm,armv8-timer";
> > >>  interrupts =  > >> --git
> > >> a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi index
> > >> 64caa600ad77..3a5a50fb8313 100644
> > >> --- a/arch/arm/dts/fsl-ls1088a.dtsi
> > >> +++ b/arch/arm/dts/fsl-ls1088a.dtsi
> > >> @@ -27,12 +27,6 @@
> > >>  interrupts = <1 9 0x4>;
> > >>  };
> > >>
> > >> -gic_lpi_base: syscon@0x8000 {
> > >> -compatible = "gic-lpi-base";
> > >> -reg = <0x0 0x8000 0x0 0x10>;
> > >> -max-gic-redistributors = <8>;
> > >> -};
> > >> -
> > >>  timer {
> > >>  compatible = "arm,armv8-timer";
> > >>  interrupts = <1 13 0x8>, /* Physical Secure PPI, active-low 
> > >> */ diff
> > >> --git a/arch/arm/dts/fsl-ls2080a.dtsi b/arch/arm/dts/fsl-ls2080a.dtsi
> > >> index 7374d580e07e..278daeeb6eea 100644
> > >> --- a/arch/arm/dts/fsl-ls2080a.dtsi
> > >> +++ b/arch/arm/dts/fsl-ls2080a.dtsi
> > >> @@ -27,12 +27,6 @@
> > >>  interrupts = <1 9 0x4>;
> > >>  };
> > >>
> > >> -gic_lpi_base: syscon@0x8000 {
> > >> -compatible = "gic-lpi-base";
> > >> -reg = <0x0 0x8000 0x0 0x10>;
> > >> -max-gic-redistributors = <8>;
> > >> -};
> > >> -
> > >>  timer {
> > >>  compatible = "arm,armv8-timer";
> > >>  interrupts = <1 13 0x8>, /* Physical Secure PPI, active-low 
> > >> */ diff
> > >> --git 

Re: [PATCH 1/2] xyz-modem: Wait infinitely for initial y-modem packet

[Wolfgang Denk]

Dear Pali Rohár,

In message <20210913122245.my6ik4yjy7rwlh65@pali> you wrote:
>
> Timeout is not too slow, but sometimes user is (when is interrupted by
> other things during selecting file). And then it is not obvious why
> sx/sb command is failing... compared to transfer via gkermit which do
> not have this "problem".

I see.

> > > So... I do not know what is better if current behavior or this new which
> > > changes UI interaction.
> > 
> > We can do both, and still solve your problem: make the timeout
> > adjustable so you can set it to something you can conveniently work
> > with.
>
> Good point! env with timeout (or easier would be retry count?) seems
> like a ideal solution how to "define" behavior without changing default
> one. And e.g. negative value can mean infinite to support all possible
> combinations.

I would recommend to define a timeout (in seconds), this is easier
to understand for the end user - without looking at the source code
they cannot know how a retry count translates into a time interval.
And yes, setting the timeout to 0 could mean it waits forever.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The optimum committee has no members.
   - Norman Augustine

Re: [PATCH v7 5/5] iot2050: Enable watchdog support, but do not auto-start it

[Tom Rini]

On Mon, Sep 13, 2021 at 09:57:45AM +0200, Jan Kiszka wrote:
> On 11.09.21 02:10, Tom Rini wrote:
> > On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote:
> > 
> >> From: Jan Kiszka 
> >>
> >> This allows to use the watchdog in custom scripts but does not enforce
> >> that the OS has to support it as well.
> >>
> >> Signed-off-by: Jan Kiszka 
> > 
> > Sorry for the late reply.  This causes CI to fail:
> > Building current source for 1 boards (1 thread, 16 jobs per thread)
> >aarch64:  +   iot2050
> > +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary is 
> > non-functional
> > +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might be 
> > non-functional
> > +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input path 
> > (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts) 
> > (cwd='/tmp/iot2050/.bm-work/iot2050')
> > +(iot2050) make[1]: *** [all] Error 1
> > +(iot2050) make: *** [sub-make] Error 2
> > 001 /1  iot2050
> > 
> > And needs to be handled like ATF/OPTEE/etc where CI can build but throw
> > a "THIS WILL NOT RUN CORRECTLY" type warning to the user.
> > 
> 
> I was about to sent an update anyway - time passed, and now we even have
> support for the next generation integrated from the beginning. But
> related upstream DT changes are not yet merged.

OK.

> But back to this issue: How can CI be fed with all those required
> binaries? The build makes no sense in their absence.

To be clearer, CI isn't fed all of the binaries, we just use /dev/null
in that case and try and make it clear it won't boot.  K3 isn't a good
example here, but I think sunxi uses binman and handles this same class
of problem?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/2] xyz-modem: Wait infinitely for initial y-modem packet

[Pali Rohár]

On Monday 13 September 2021 14:12:54 Wolfgang Denk wrote:
> Dear Pali Rohár,
> 
> In message <20210913110806.27hc36n6gmhw6uq4@pali> you wrote:
> >
> > > If you use loady in any kind of scripts, this would now hard hang
> > > the system, while until now it was possible to recover from the
> > > error.
> >
> > Yes, this is a good point. But on the other hand, 'loadb' and 'loads'
> > commands already have this behavior. So question is if it is better to
> > have same behavior in all 'load?' commands or each 'load?' would behave
> > differently... Because for software which transmit files and supports
> > more protocols (e.g. both x-modem and kermit) it may be a nightmare if
> > receiver behaves differently...
> 
> Yes, you are right, there is an unlucky difference in behaviour.
> But all these interfaces are pretty old, and I would not invest
> efforts to fix a aproblem nobody ever noticed before, at the risk
> of breaking existing stuff.
> 
> I wonder if there are any users of 'loads' left - the Motorola
> S-record format is close to 50 years old and cumbersome to use.

Wow, I did not know that it is such old.

> I can't even remeber when I used it the last time - must be 15+ years
> or such.
> 
> 'loadb" is a different thing, but there you usually have kermit on
> the other side, and usually run an interactive session (or an
> automated one using something like  tbot ) - in any case, you
> normally have to interact on both sides.

There is also gkermit tool which do not implement interactive session,
only file transfer itself. And it is present in more linux distributions
so is quite popular...

> I never had a problem wih the current behaviour there.
> 
> 
> > If you do not have integrated y-modem support in your terminal you have
> > to do:
> >
> > 1) open terminal and write 'loady' into U-Boot console
> > 2) disconnect terminal
> > 3) start y-modem software
> > 4) choose file to transmit
> > 5) instruct y-modem software to start transfer
> >
> > And if 'loady' timeouts between 2) - 5) then it returns back to the
> 
> If this happens, the timeout is inconveniently short of you are too
> slow.  I think what would be helpful is to make the timeout
> adjustable (env var).

Timeout is not too slow, but sometimes user is (when is interrupted by
other things during selecting file). And then it is not obvious why
sx/sb command is failing... compared to transfer via gkermit which do
not have this "problem".

> > So... I do not know what is better if current behavior or this new which
> > changes UI interaction.
> 
> We can do both, and still solve your problem: make the timeout
> adjustable so you can set it to something you can conveniently work
> with.

Good point! env with timeout (or easier would be retry count?) seems
like a ideal solution how to "define" behavior without changing default
one. And e.g. negative value can mean infinite to support all possible
combinations.

> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> "I can call spirits from the vasty deep."
> "Why so can I, or so can any man; but will they come when you do call
> for them?"  - Shakespeare, 1 King Henry IV, Act III, Scene I.

Re: [PATCH 1/2] xyz-modem: Wait infinitely for initial y-modem packet

[Wolfgang Denk]

Dear Pali Rohár,

In message <20210913110806.27hc36n6gmhw6uq4@pali> you wrote:
>
> > If you use loady in any kind of scripts, this would now hard hang
> > the system, while until now it was possible to recover from the
> > error.
>
> Yes, this is a good point. But on the other hand, 'loadb' and 'loads'
> commands already have this behavior. So question is if it is better to
> have same behavior in all 'load?' commands or each 'load?' would behave
> differently... Because for software which transmit files and supports
> more protocols (e.g. both x-modem and kermit) it may be a nightmare if
> receiver behaves differently...

Yes, you are right, there is an unlucky difference in behaviour.
But all these interfaces are pretty old, and I would not invest
efforts to fix a aproblem nobody ever noticed before, at the risk
of breaking existing stuff.

I wonder if there are any users of 'loads' left - the Motorola
S-record format is close to 50 years old and cumbersome to use.  I
can't even remeber when I used it the last time - must be 15+ years
or such.

'loadb" is a different thing, but there you usually have kermit on
the other side, and usually run an interactive session (or an
automated one using something like  tbot ) - in any case, you
normally have to interact on both sides.

I never had a problem wih the current behaviour there.


> If you do not have integrated y-modem support in your terminal you have
> to do:
>
> 1) open terminal and write 'loady' into U-Boot console
> 2) disconnect terminal
> 3) start y-modem software
> 4) choose file to transmit
> 5) instruct y-modem software to start transfer
>
> And if 'loady' timeouts between 2) - 5) then it returns back to the

If this happens, the timeout is inconveniently short of you are too
slow.  I think what would be helpful is to make the timeout
adjustable (env var).

> So... I do not know what is better if current behavior or this new which
> changes UI interaction.

We can do both, and still solve your problem: make the timeout
adjustable so you can set it to something you can conveniently work
with.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"I can call spirits from the vasty deep."
"Why so can I, or so can any man; but will they come when you do call
for them?"  - Shakespeare, 1 King Henry IV, Act III, Scene I.

Re: [PATCH 1/2] xyz-modem: Wait infinitely for initial y-modem packet

[Pali Rohár]

On Monday 13 September 2021 12:42:42 Wolfgang Denk wrote:
> Dear Pali Rohár,
> 
> In message <20210910204653.3066-1-p...@kernel.org> you wrote:
> > Now when command loady can be aborted / cancelled by CTRL+C, change wait
> > timeout for initial packet to infinite. This would allow user to not be
> > hurry when locating file which want to send. Commands loadb and loads
> > already waits infinitely too.
> 
> I'm not sure if this is a good idea.
> 
> If you use loady in any kind of scripts, this would now hard hang
> the system, while until now it was possible to recover from the
> error.

Yes, this is a good point. But on the other hand, 'loadb' and 'loads'
commands already have this behavior. So question is if it is better to
have same behavior in all 'load?' commands or each 'load?' would behave
differently... Because for software which transmit files and supports
more protocols (e.g. both x-modem and kermit) it may be a nightmare if
receiver behaves differently...

> This is a change to the user interface that is not really necessary,
> so I recommend NOT to change the behaviour here, especially as it
> does not hurt.

Well... there is an issue if you do not start file transfer in the
timeout which current 'loady' command expects.

If you do not have integrated y-modem support in your terminal you have
to do:

1) open terminal and write 'loady' into U-Boot console
2) disconnect terminal
3) start y-modem software
4) choose file to transmit
5) instruct y-modem software to start transfer

And if 'loady' timeouts between 2) - 5) then it returns back to the
U-Boot console. So y-modem software in step 5) starts interaction with
U-Boot console instead of 'loady' and try to interpret U-Boot prompt as
y-modem sequence... which is detected as garbage and y-modem software
would either wait or try retransmit... which sends some garbage to
U-Boot console and something may be executed.

'loadb' commands does not have this issue as it waits either for CTRL+C
or for successful kermit transfer.


So... I do not know what is better if current behavior or this new which
changes UI interaction.

> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> "I've finally learned what `upward compatible' means. It means we get
> to keep all our old mistakes." - Dennie van Tassel

Re: [PATCH 2/2] xyz-modem: Wait infinitely for initial x-modem packet

[Wolfgang Denk]

Dear Pali Rohár,

In message <20210910204653.3066-2-p...@kernel.org> you wrote:
> Implement same thing also for x-modem protocol. As x-modem protocol does
> not have header packet, first packet is directly first data packet.
>
> Signed-off-by: Pali Rohár 
> ---
>  common/xyzModem.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

Ditto here.   Please don't.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"I believe the use of noise to make  music  will  increase  until  we
reach  a  music  produced  through  the aid of electrical instruments
which will make available for musical purposes  any  and  all  sounds
that can be heard."- composer John Cage, 1937

Re: [PATCH 1/2] xyz-modem: Wait infinitely for initial y-modem packet

[Wolfgang Denk]

Dear Pali Rohár,

In message <20210910204653.3066-1-p...@kernel.org> you wrote:
> Now when command loady can be aborted / cancelled by CTRL+C, change wait
> timeout for initial packet to infinite. This would allow user to not be
> hurry when locating file which want to send. Commands loadb and loads
> already waits infinitely too.

I'm not sure if this is a good idea.

If you use loady in any kind of scripts, this would now hard hang
the system, while until now it was possible to recover from the
error.

This is a change to the user interface that is not really necessary,
so I recommend NOT to change the behaviour here, especially as it
does not hurt.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"I've finally learned what `upward compatible' means. It means we get
to keep all our old mistakes." - Dennie van Tassel

Re: [PATCH] efi_driver: simplify efi_bl_bind()

[AKASHI Takahiro]

On Mon, Sep 13, 2021 at 11:19:22AM +0200, Heinrich Schuchardt wrote:
> On 9/13/21 8:01 AM, AKASHI Takahiro wrote:
> > blk_create_devicef() is what blk_create_device() +
> > device_set_name_alloced() really does.
> > The resultant name will be a bit changed.
> 
> without the patch after a device has been generated by the UEFI subsystem:
> 
> => dm tree
> 
> Class Index  Probed  Driver  Name
> 
> -
> root  0  [ + ]   root_driver root_driver
> mmc   2  [ + ]   mmc_sandbox |-- mmc0
> 
> blk   2  [ + ]   mmc_blk |   `-- mmc0.blk
> blk   3  [ + ]   efi_blk `-- efiblk#0
> 
> with the patch:
> 
> => dm tree
> 
> Class Index  Probed  Driver  Name
> 
> -
> 
> root  0  [ + ]   root_driver root_driver
> mmc   2  [ + ]   mmc_sandbox |-- mmc0
> 
> blk   2  [ + ]   mmc_blk |   `-- mmc0.blk
> blk   3  [ + ]   efi_blk `-- root_driver.efiblk#0
> 
> Prepending 'root_driver.' to the name seems to not match the rest of the
> tree.

Is there anything wrong with the new "name"?

blk_create_devicef() creates a name with the parent's name + '.' +
a given name. In this case, you specifies the dm root object
as the device's parent. So "root_driver.efiblk#0" is a natural name
like mmc0.blk and others.

Another block device example:

 root  0  [ + ]   root_driver   root_driver
 pci   0  [ + ]   pci_generic_ecam  |-- pcie@1000
 pci_generi0  [   ]   pci_generic_drv   |   |-- pci_0:0.0
 virtio   32  [ + ]   virtio-pci.l  |   |-- virtio-pci.l#0
 ethernet  0  [ + ]   virtio-net|   |   `-- virtio-net#32
 ahci  0  [ + ]   ahci_pci  |   `-- ahci_pci
 scsi  0  [ + ]   ahci_scsi |   `-- ahci_scsi
 blk   0  [   ]   scsi_blk  |   |-- 
ahci_scsi.id0lun0
 blk   1  [   ]   scsi_blk  |   `-- 
ahci_scsi.id1lun0

If you really don't like "root_driver." prefix, you can create
the "efi" object as the generic parent for EFI devices, and then
you will see "efi.blk#0".
(This is also the way[1] that I took in my previous integration patch.

But in either way, it's just a name. Who cares.

-Takahiro Akashi

[1] https://lists.denx.de/pipermail/u-boot/2019-February/357929.html

> Best regards
> 
> Heinrich
> 
> > 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >   lib/efi_driver/efi_block_device.c | 10 +++---
> >   1 file changed, 3 insertions(+), 7 deletions(-)
> > 
> > diff --git a/lib/efi_driver/efi_block_device.c 
> > b/lib/efi_driver/efi_block_device.c
> > index 0937e3595a43..b81c75868eb4 100644
> > --- a/lib/efi_driver/efi_block_device.c
> > +++ b/lib/efi_driver/efi_block_device.c
> > @@ -159,15 +159,11 @@ static int efi_bl_bind(efi_handle_t handle, void 
> > *interface)
> > sprintf(name, "efiblk#%d", devnum);
> > 
> > /* Create driver model udevice for the EFI block io device */
> > -   ret = blk_create_device(parent, "efi_blk", name, IF_TYPE_EFI, devnum,
> > -   io->media->block_size,
> > -   (lbaint_t)io->media->last_block, );
> > +   ret = blk_create_devicef(parent, "efi_blk", name, IF_TYPE_EFI, devnum,
> > +io->media->block_size,
> > +(lbaint_t)io->media->last_block, );
> > if (ret)
> > return ret;
> > -   if (!bdev)
> > -   return -ENOENT;
> > -   /* Set the DM_FLAG_NAME_ALLOCED flag to avoid a memory leak */
> > -   device_set_name_alloced(bdev);
> > 
> > plat = dev_get_plat(bdev);
> > plat->handle = handle;
> > 
> 

Re: Bug: qemu_arm64: Cannot access the second flash bank

[Matthias Brugger]

Hi Robin,

It's a long long time that you reported this issue.

I prepared a fix in qemu for it. Would you mind to try it out? You can find a 
branch with the fix on top here:

https://github.com/mbgg/qemu/tree/vrit-flash-dtb-bug

Basically I fix the reg property to reflect the fact that the size-cell is one.

Please let me know if that fixes the issue for you and I'll send the fix 
upstream.

Regards,
Matthias

On 01/01/2020 19:20, Robin Randhawa wrote:

Hi folks.

[CC'ing some hopefully relevant folks].

As of:

commit 0ba41ce1b7816c229cc19e0621148b98f990cb68
libfdt: return correct value if #size-cells property is not present

.. accesses to the second flash bank on the qemu_arm64 virtual board
appear broken.

To demonstrate, consider that the physical memory map for the 2 flash
banks is:

Bank 1: 0x_ - 0x03FC_
Bank 2: 0x0400_ - 0x7FC0_

Now, consider the abbreviated output of the flinfo command pre and post
the above commit:

Pre:
===

=> flinfo

Bank # 1: CFI conformant flash (32 x 16)  Size: 64 MB in 256 Sectors
   Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x0018
   Erase timeout: 16384 ms, write timeout: 3 ms
   Buffer write timeout: 3 ms, buffer size: 2048 bytes

   Sector Start Addresses:
      RO   0004   RO   0008   RO   000C0010
   00140018001C00200024
   .
   .
   03E803EC03F003F403F8
   03FC

Bank # 2: CFI conformant flash (32 x 16)  Size: 64 MB in 256 Sectors
   Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x0018
   Erase timeout: 16384 ms, write timeout: 3 ms
   Buffer write timeout: 3 ms, buffer size: 2048 bytes

   Sector Start Addresses:
   0400   RO   04040408040C0410
   04140418041C04200424
   .
   .
   07E807EC07F007F407F8
   07FC

Post:


=> flinfo

Bank # 1: CFI conformant flash (32 x 16)  Size: 64 MB in 256 Sectors
   Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x0018
   Erase timeout: 16384 ms, write timeout: 3 ms
   Buffer write timeout: 3 ms, buffer size: 2048 bytes

   Sector Start Addresses:
      RO   0004   RO   0008   RO   000C0010
   00140018001C00200024
   .
   .
   03E803EC03F003F403F8
   03FC

Bank # 2: CFI conformant flash (32 x 16)  Size: 64 MB in 256 Sectors
   Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x0018
   Erase timeout: 16384 ms, write timeout: 3 ms
   Buffer write timeout: 3 ms, buffer size: 2048 bytes

   Sector Start Addresses:
   400404408
40C410
   41441841C
420424
   .
   .
  
40003E840003EC40003F040

003F440003F8
   40003FC

As a result, the second bank is unusable for environment stores
(CONFIG_ENV_ADDR is 0x400):

=> saveenv
Saving Environment to Flash... Error: start and/or end address not on
sector boundary
Error: start and/or end address not on sector boundary
Failed (1)

Rewinding the u-boot repo to before this commit fixes the problem.

Manually (uncleanly) reverting the commit and it's dependent commits
fixes the problem.

Here are the HEAD commits from the relevant repos that I used for the data 
above:

qemu: commit dd5b0f95490883cd8bc7d070db8de70d5c979cbc
u-boot: commit 6cb87cbb1475f668689f95911d1521ee6ba7f55c

Here is the qemu invocation I used:

$ dd if=/dev/zero of=./flash0-with-uboot.img bs=1M count=64 && dd 
if=/path/to/u-boot.bin of=./flash0-with-uboot.img conv=notrunc
$ qemu-system-aarch64 -M virt -cpu cortex-a53 -m 1024M -nographic -drive 
if=pflash,format=raw,index=0,file=flash0-with-uboot.img  -drive 
if=pflash,format=raw,index=1,file=flash1.img

I'm happy to help test any fixes if and as needed.

Cheers,
Robin

Re: [PATCH] efi_driver: simplify efi_bl_bind()

[Heinrich Schuchardt]

On 9/13/21 8:01 AM, AKASHI Takahiro wrote:

blk_create_devicef() is what blk_create_device() +
device_set_name_alloced() really does.
The resultant name will be a bit changed.


without the patch after a device has been generated by the UEFI subsystem:

=> dm tree

Class Index  Probed  Driver  Name

-
root  0  [ + ]   root_driver root_driver
mmc   2  [ + ]   mmc_sandbox |-- mmc0

blk   2  [ + ]   mmc_blk |   `-- mmc0.blk
blk   3  [ + ]   efi_blk `-- efiblk#0

with the patch:

=> dm tree

Class Index  Probed  Driver  Name

-

root  0  [ + ]   root_driver root_driver
mmc   2  [ + ]   mmc_sandbox |-- mmc0

blk   2  [ + ]   mmc_blk |   `-- mmc0.blk
blk   3  [ + ]   efi_blk `-- root_driver.efiblk#0

Prepending 'root_driver.' to the name seems to not match the rest of the
tree.

Best regards

Heinrich



Signed-off-by: AKASHI Takahiro 
---
  lib/efi_driver/efi_block_device.c | 10 +++---
  1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/lib/efi_driver/efi_block_device.c 
b/lib/efi_driver/efi_block_device.c
index 0937e3595a43..b81c75868eb4 100644
--- a/lib/efi_driver/efi_block_device.c
+++ b/lib/efi_driver/efi_block_device.c
@@ -159,15 +159,11 @@ static int efi_bl_bind(efi_handle_t handle, void 
*interface)
sprintf(name, "efiblk#%d", devnum);

/* Create driver model udevice for the EFI block io device */
-   ret = blk_create_device(parent, "efi_blk", name, IF_TYPE_EFI, devnum,
-   io->media->block_size,
-   (lbaint_t)io->media->last_block, );
+   ret = blk_create_devicef(parent, "efi_blk", name, IF_TYPE_EFI, devnum,
+io->media->block_size,
+(lbaint_t)io->media->last_block, );
if (ret)
return ret;
-   if (!bdev)
-   return -ENOENT;
-   /* Set the DM_FLAG_NAME_ALLOCED flag to avoid a memory leak */
-   device_set_name_alloced(bdev);

plat = dev_get_plat(bdev);
plat->handle = handle;

[PATCH v2] mtd: spi: nor: force mtd name to "nor%d"

[Patrick Delaunay]

Force the mtd name of spi-nor to "nor" + the driver sequence number:
"nor0", "nor1"...

This patch is coherent with existing "nand" and "spi-nand"
mtd device names.

I keep the existing "nor" name to don't disturb the existing users of mtd
functions.
The mtd name 'nor' was configured previously by the function
drivers/mtd/spi/sf_mtd.c:spi_flash_mtd_register() =
  "nor%d" + spi_flash_mtd_number()

The 'nor' name is also coherent with get_mtd_info() and the macro
MTD_DEV_TYPE(): MTD_DEV_TYPE_NOR is associated with "nor" name.

This generic name can be use to identify the mtd spi-nor device
without knowing the real device name or the DT path of the device,
used with API get_mtd_device_nm().

And also avoid issue when the same NOR device is present 2 times,
for example on STM32MP15F-EV1:

STM32MP> mtd list
SF: Detected mx66l51235l with page size 256 Bytes, erase size 64 KiB, \
total 64 MiB

List of MTD devices:
* nand0
  - type: NAND flash
  - block size: 0x4 bytes
  - min I/O: 0x1000 bytes
  - OOB size: 224 bytes
  - OOB available: 118 bytes
  - ECC strength: 8 bits
  - ECC step size: 512 bytes
  - bitflip threshold: 6 bits
  - 0x-0x4000 : "nand0"
* mx66l51235l
  - device: mx66l51235l@0
  - parent: spi@58003000
  - driver: jedec_spi_nor
  - path: /soc/spi@58003000/mx66l51235l@0
  - type: NOR flash
  - block size: 0x1 bytes
  - min I/O: 0x1 bytes
  - 0x-0x0400 : "mx66l51235l"
* mx66l51235l
  - device: mx66l51235l@1
  - parent: spi@58003000
  - driver: jedec_spi_nor
  - path: /soc/spi@58003000/mx66l51235l@1
  - type: NOR flash
  - block size: 0x1 bytes
  - min I/O: 0x1 bytes
  - 0x-0x0400 : "mx66l51235l"

The same mtd name "mx66l51235l" identify the 2 instance
mx66l51235l@0 and mx66l51235l@1.

This patch solves a ST32CubeProgrammer / stm32prog command issue
with nor0 target on STM32MP157C-EV1 board.

Fixes: b7f060565e31 ("mtd: spi-nor: allow registering multiple MTDs when DM is 
enabled")
Signed-off-by: Patrick Delaunay 
---
For other device, the mtd name are hardcoded in each MTD driver:

drivers/mtd/nand/spi/core.c:1169:
sprintf(mtd->name, "spi-nand%d", spi_nand_idx++);
drivers/mtd/nand/raw/nand.c:59:
sprintf(dev_name[devnum], "nand%d", devnum);

The existing user with "nor..."

arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c:625:
  mtd = get_mtd_device_nm(mtd_id);
board/emulation/common/qemu_mtdparts.c:63:
  mtd = get_mtd_device_nm("nor0");
board/emulation/common/qemu_mtdparts.c:70:
  mtd = get_mtd_device_nm("nor1");
board/emulation/common/qemu_dfu.c:61:
  mtd = get_mtd_device_nm("nor0");
board/st/common/stm32mp_dfu.c:132:
  mtd = get_mtd_device_nm("nor0");
drivers/dfu/dfu_mtd.c:259:
  mtd = get_mtd_device_nm(devstr);
 => see "dfu mtd" support in doc/usage/dfu.rst


Changes in v2:
- update commit message, change invalid patman tag "Series-Cc"

 drivers/mtd/spi/spi-nor-core.c | 8 +---
 include/linux/mtd/spi-nor.h| 1 +
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index d5d905fa5a..3eb7dcfddb 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -3715,8 +3715,10 @@ int spi_nor_scan(struct spi_nor *nor)
if (ret)
return ret;
 
-   if (!mtd->name)
-   mtd->name = info->name;
+   if (!mtd->name) {
+   sprintf(nor->mtd_name, "nor%d",  dev_seq(nor->dev));
+   mtd->name = nor->mtd_name;
+   }
mtd->dev = nor->dev;
mtd->priv = nor;
mtd->type = MTD_NORFLASH;
@@ -3821,7 +3823,7 @@ int spi_nor_scan(struct spi_nor *nor)
 
nor->rdsr_dummy = params.rdsr_dummy;
nor->rdsr_addr_nbytes = params.rdsr_addr_nbytes;
-   nor->name = mtd->name;
+   nor->name = info->name;
nor->size = mtd->size;
nor->erase_size = mtd->erasesize;
nor->sector_size = mtd->erasesize;
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 7ddc4ba2bf..8c3d5032e3 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -561,6 +561,7 @@ struct spi_nor {
int (*ready)(struct spi_nor *nor);
 
void *priv;
+   char mtd_name[10];
 /* Compatibility for spi_flash, remove once sf layer is merged with mtd */
const char *name;
u32 size;
-- 
2.25.1

Re: [PATCH v7 5/5] iot2050: Enable watchdog support, but do not auto-start it

[Jan Kiszka]

On 11.09.21 02:10, Tom Rini wrote:
> On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote:
> 
>> From: Jan Kiszka 
>>
>> This allows to use the watchdog in custom scripts but does not enforce
>> that the OS has to support it as well.
>>
>> Signed-off-by: Jan Kiszka 
> 
> Sorry for the late reply.  This causes CI to fail:
> Building current source for 1 boards (1 thread, 16 jobs per thread)
>aarch64:  +   iot2050
> +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary is 
> non-functional
> +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might be 
> non-functional
> +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input path 
> (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts) 
> (cwd='/tmp/iot2050/.bm-work/iot2050')
> +(iot2050) make[1]: *** [all] Error 1
> +(iot2050) make: *** [sub-make] Error 2
> 001 /1  iot2050
> 
> And needs to be handled like ATF/OPTEE/etc where CI can build but throw
> a "THIS WILL NOT RUN CORRECTLY" type warning to the user.
> 

I was about to sent an update anyway - time passed, and now we even have
support for the next generation integrated from the beginning. But
related upstream DT changes are not yet merged.

But back to this issue: How can CI be fed with all those required
binaries? The build makes no sense in their absence.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH] sf: Querying write-protect status before operating the flash

[Jan Kiszka]

Hi all,

Chao, please no top-post on mailing list. Also check your mail client,
it seems to inject a lot of bogus newlines.

On 08.09.21 06:55, chaochao2021666 wrote:
> 
> 
> 
> HI Jagan
> 
> 
> 
> sorry for the delay response.
> 
> 
> And I have checked the maser. There is still a problem with this feature。
> 
> 
> reproduce steps:
> 1. enable the flash protect function
> 2. using sf cmd to erase the flash. I can get the erase "OK",not the "error".
> 
> 
> 
> I think the root cause is that the detection mechanism is missing and to 
> judge the permissions of the action
> 
> So pull this PR to improve the erase flow
> 
> 
> another question:
> how can I visit the  u-boot-spi/next? do there any link?
> 

See MAINTAINERS: https://source.denx.de/u-boot/custodians/u-boot-spi.git

But also that tree contains no usage of the flash_is_locked callback.
That was once evaluated by drivers/mtd/spi/spi_flash.c but then
forgotten in the new SPI NOR framework it seems.

Chao's patch makes sense to me to restore this feature.

Jan

> 
> 
> 
> 
> BRs
> Chao
> 
> 
> 
> At 2021-06-29 21:50:28, "Jagan Teki"  wrote:
>> On Tue, Jun 22, 2021 at 10:51 AM chao zeng  wrote:
>>>
>>> From: Chao Zeng 
>>>
>>> When operating the write-protection flash,spi_flash_std_write() and
>>> spi_flash_std_erase() would return wrong result.The flash is protected,
>>> but write or erase the flash would show "OK".
>>>
>>> Check the flash write protection state if the write-protection has enbale
>>> before operating the flash.
>>>
>>> Signed-off-by: Chao Zeng 
>>> ---
>>
>> Does it broken on master? if yes can you check in u-boot-spi/next?
>>
>> Jagan.

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

[PATCH] mtd: spi: nor: force mtd name to "nor%d"

[Patrick Delaunay]

Force the mtd name of spi-nor to "nor" + the driver sequence number:
"nor0", "nor1"...

This patch is coherent with existing "nand" and "spi-nand"
mtd device names.

I keep the existing "nor" name to don't disturb the existing users of mtd
functions.
The mtd name 'nor' was configured previously by the function
drivers/mtd/spi/sf_mtd.c:spi_flash_mtd_register() =
  "nor%d" + spi_flash_mtd_number()

The 'nor' name is also coherent with get_mtd_info() and the macro
MTD_DEV_TYPE(): MTD_DEV_TYPE_NOR is associated with "nor" name.

This generic name can be use to identify the mtd spi-nor device
without knowing the real device name or the DT path of the device,
used with API get_mtd_device_nm().

And also avoid issue when the same NOR device is present 2 times,
for example on STM32MP15F-EV1:

STM32MP> mtd list
SF: Detected mx66l51235l with page size 256 Bytes, erase size 64 KiB, \
total 64 MiB

List of MTD devices:
* nand0
  - type: NAND flash
  - block size: 0x4 bytes
  - min I/O: 0x1000 bytes
  - OOB size: 224 bytes
  - OOB available: 118 bytes
  - ECC strength: 8 bits
  - ECC step size: 512 bytes
  - bitflip threshold: 6 bits
  - 0x-0x4000 : "nand0"
* mx66l51235l
  - device: mx66l51235l@0
  - parent: spi@58003000
  - driver: jedec_spi_nor
  - path: /soc/spi@58003000/mx66l51235l@0
  - type: NOR flash
  - block size: 0x1 bytes
  - min I/O: 0x1 bytes
  - 0x-0x0400 : "mx66l51235l"
* mx66l51235l
  - device: mx66l51235l@1
  - parent: spi@58003000
  - driver: jedec_spi_nor
  - path: /soc/spi@58003000/mx66l51235l@1
  - type: NOR flash
  - block size: 0x1 bytes
  - min I/O: 0x1 bytes
  - 0x-0x0400 : "mx66l51235l"

The same mtd name "mx66l51235l" identify the 2 instance
mx66l51235l@0 and mx66l51235l@1.

This patch solves a ST32CubeProgrammer / stm32prog command issue
with nor0 target on STM32MP157C-EV1 board.

Series-Cc: Priyanka Jain 
Series-Cc: Heiko Schocher 
Fixes: b7f060565e31 ("mtd: spi-nor: allow registering multiple MTDs when DM is 
enabled")
Signed-off-by: Patrick Delaunay 
---
For other device, the mtd name are hardcoded in each MTD driver:

drivers/mtd/nand/spi/core.c:1169:
sprintf(mtd->name, "spi-nand%d", spi_nand_idx++);
drivers/mtd/nand/raw/nand.c:59:
sprintf(dev_name[devnum], "nand%d", devnum);

The existing user with "nor..."

arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c:625:
  mtd = get_mtd_device_nm(mtd_id);
board/emulation/common/qemu_mtdparts.c:63:
  mtd = get_mtd_device_nm("nor0");
board/emulation/common/qemu_mtdparts.c:70:
  mtd = get_mtd_device_nm("nor1");
board/emulation/common/qemu_dfu.c:61:
  mtd = get_mtd_device_nm("nor0");
board/st/common/stm32mp_dfu.c:132:
  mtd = get_mtd_device_nm("nor0");
drivers/dfu/dfu_mtd.c:259:
  mtd = get_mtd_device_nm(devstr);
 => see "dfu mtd" support in doc/usage/dfu.rst


 drivers/mtd/spi/spi-nor-core.c | 8 +---
 include/linux/mtd/spi-nor.h| 1 +
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index d5d905fa5a..3eb7dcfddb 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -3715,8 +3715,10 @@ int spi_nor_scan(struct spi_nor *nor)
if (ret)
return ret;
 
-   if (!mtd->name)
-   mtd->name = info->name;
+   if (!mtd->name) {
+   sprintf(nor->mtd_name, "nor%d",  dev_seq(nor->dev));
+   mtd->name = nor->mtd_name;
+   }
mtd->dev = nor->dev;
mtd->priv = nor;
mtd->type = MTD_NORFLASH;
@@ -3821,7 +3823,7 @@ int spi_nor_scan(struct spi_nor *nor)
 
nor->rdsr_dummy = params.rdsr_dummy;
nor->rdsr_addr_nbytes = params.rdsr_addr_nbytes;
-   nor->name = mtd->name;
+   nor->name = info->name;
nor->size = mtd->size;
nor->erase_size = mtd->erasesize;
nor->sector_size = mtd->erasesize;
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 7ddc4ba2bf..8c3d5032e3 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -561,6 +561,7 @@ struct spi_nor {
int (*ready)(struct spi_nor *nor);
 
void *priv;
+   char mtd_name[10];
 /* Compatibility for spi_flash, remove once sf layer is merged with mtd */
const char *name;
u32 size;
-- 
2.25.1

RE: [PATCH v2 14/15] PPC: Enable Job ring driver model in U-Boot

[Priyanka Jain (OSS)]

>-Original Message-
>From: U-Boot  On Behalf Of Gaurav Jain
>Sent: Friday, September 3, 2021 12:33 PM
>To: u-boot@lists.denx.de
>Cc: Stefano Babic ; Fabio Estevam ;
>Peng Fan ; Simon Glass ; Priyanka
>Jain ; Ye Li ; Horia Geanta
>; Ji Luo ; Franck Lenormand
>; Silvano Di Ninno ;
>Sahil Malhotra ; Pankaj Gupta
>; Varun Sethi ; dl-uboot-imx
>; Shengzhou Liu ; Mingkai
>Hu ; Rajesh Bhagat ;
>Meenakshi Aggarwal ; Wasim Khan
>; Alison Wang ; Pramod
>Kumar ; Andy Tang ;
>Adrian Alonso ; Vladimir Oltean
>; Gaurav Jain 
>Subject: [PATCH v2 14/15] PPC: Enable Job ring driver model in U-Boot
>
>removed sec_init() call and CONFIG_FSL_CAAM from defconfig.
>sec is initialized based on job ring information processed from device tree.
>
>Signed-off-by: Gaurav Jain 
>---
> arch/powerpc/cpu/mpc85xx/Kconfig  | 44
>+++
> arch/powerpc/cpu/mpc85xx/cpu_init.c   | 17 +--
> arch/powerpc/include/asm/u-boot-ppc.h | 13 
> arch/powerpc/include/asm/u-boot.h |  1 +
> configs/P2041RDB_defconfig|  1 -
> configs/P3041DS_defconfig |  1 -
> configs/P4080DS_defconfig |  1 -
> configs/P5040DS_defconfig |  1 -
> configs/T1024RDB_defconfig|  1 -
> configs/T1042D4RDB_defconfig  |  1 -
> configs/T2080QDS_defconfig|  1 -
> configs/T2080RDB_defconfig|  1 -
> configs/T4240RDB_defconfig|  1 -
> 13 files changed, 73 insertions(+), 11 deletions(-)  create mode 100644
>arch/powerpc/include/asm/u-boot-ppc.h
>

Reviewed-by: Priyanka Jain 

RE: [PATCH v2 13/15] PPC: Add crypto node in device tree

[Priyanka Jain (OSS)]

>-Original Message-
>From: U-Boot  On Behalf Of Gaurav Jain
>Sent: Friday, September 3, 2021 12:33 PM
>To: u-boot@lists.denx.de
>Cc: Stefano Babic ; Fabio Estevam ;
>Peng Fan ; Simon Glass ; Priyanka
>Jain ; Ye Li ; Horia Geanta
>; Ji Luo ; Franck Lenormand
>; Silvano Di Ninno ;
>Sahil Malhotra ; Pankaj Gupta
>; Varun Sethi ; dl-uboot-imx
>; Shengzhou Liu ; Mingkai
>Hu ; Rajesh Bhagat ;
>Meenakshi Aggarwal ; Wasim Khan
>; Alison Wang ; Pramod
>Kumar ; Andy Tang ;
>Adrian Alonso ; Vladimir Oltean
>; Gaurav Jain 
>Subject: [PATCH v2 13/15] PPC: Add crypto node in device tree
>
>device tree imported from linux kernel.
>c500bee1c5b2 (tag: v5.14-rc4) Linux 5.14-rc4
>
>Signed-off-by: Gaurav Jain 
>---
> arch/powerpc/dts/p2041si-post.dtsi   |  1 +
> arch/powerpc/dts/p3041si-post.dtsi   |  1 +
> arch/powerpc/dts/p4080si-post.dtsi   |  1 +
> arch/powerpc/dts/p5040si-post.dtsi   |  1 +
> arch/powerpc/dts/qoriq-sec4.0-0.dtsi | 74 ++
>arch/powerpc/dts/qoriq-sec4.2-0.dtsi | 83 +
>arch/powerpc/dts/qoriq-sec5.2-0.dtsi | 92
>
> arch/powerpc/dts/t1023si-post.dtsi   |  1 +
> arch/powerpc/dts/t1042si-post.dtsi   |  1 +
> arch/powerpc/dts/t2080si-post.dtsi   |  1 +
> arch/powerpc/dts/t4240si-post.dtsi   |  1 +
> 11 files changed, 257 insertions(+)
> create mode 100644 arch/powerpc/dts/qoriq-sec4.0-0.dtsi
> create mode 100644 arch/powerpc/dts/qoriq-sec4.2-0.dtsi
> create mode 100644 arch/powerpc/dts/qoriq-sec5.2-0.dtsi
>

Reviewed-by: Priyanka Jain 

RE: [PATCH v2 12/15] Layerscape: Enable Job ring driver model in U-Boot.

[Priyanka Jain (OSS)]

>-Original Message-
>From: U-Boot  On Behalf Of Gaurav Jain
>Sent: Friday, September 3, 2021 12:33 PM
>To: u-boot@lists.denx.de
>Cc: Stefano Babic ; Fabio Estevam ;
>Peng Fan ; Simon Glass ; Priyanka Jain
>; Ye Li ; Horia Geanta
>; Ji Luo ; Franck Lenormand
>; Silvano Di Ninno ;
>Sahil Malhotra ; Pankaj Gupta
>; Varun Sethi ; dl-uboot-imx
>; Shengzhou Liu ; Mingkai Hu
>; Rajesh Bhagat ; Meenakshi
>Aggarwal ; Wasim Khan
>; Alison Wang ; Pramod Kumar
>; Andy Tang ; Adrian Alonso
>; Vladimir Oltean ; Gaurav Jain
>
>Subject: [PATCH v2 12/15] Layerscape: Enable Job ring driver model in U-Boot.
>
>LS(1021/1012/1028/1043/1046/1088/2088), LX2160, LX2162 platforms are
>enabled with JR driver model.
>
>removed sec_init() call from board files.
>removed CONFIG_FSL_CAAM from defconfig files.
>sec is initialized based on job ring information processed from device tree.
>
>Signed-off-by: Gaurav Jain 
>---
> arch/arm/cpu/armv7/ls102xa/Kconfig|  4 +++
> arch/arm/cpu/armv7/ls102xa/cpu.c  | 16 +++
> arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 27 +++
> arch/arm/cpu/armv8/fsl-layerscape/cpu.c   | 10 ++-
> board/freescale/ls1012afrdm/ls1012afrdm.c |  7 +
> board/freescale/ls1012aqds/ls1012aqds.c   |  6 +
> board/freescale/ls1012ardb/ls1012ardb.c   |  6 +
> board/freescale/ls1021aiot/ls1021aiot.c   |  6 ++---
> board/freescale/ls1021aqds/ls1021aqds.c   |  6 +
> board/freescale/ls1021atsn/ls1021atsn.c   |  7 ++---
> board/freescale/ls1021atwr/ls1021atwr.c   |  8 ++
> board/freescale/ls1028a/ls1028a.c |  6 +
> board/freescale/ls1043ardb/ls1043ardb.c   |  6 +
> board/freescale/ls1046afrwy/ls1046afrwy.c |  7 +
> board/freescale/ls1046aqds/ls1046aqds.c   |  7 +
> board/freescale/ls1046ardb/ls1046ardb.c   |  6 +
> board/freescale/ls1088a/ls1088a.c |  6 +
> board/freescale/ls2080aqds/ls2080aqds.c   |  6 +
> board/freescale/ls2080ardb/ls2080ardb.c   |  9 +--
> board/freescale/lx2160a/lx2160a.c |  5 
> configs/ls1021aiot_qspi_defconfig |  1 -
> configs/ls1021aqds_nor_defconfig  |  1 -
> configs/ls1021aqds_qspi_defconfig |  1 -
> configs/ls1021atsn_qspi_defconfig |  1 -
> configs/ls1021atwr_nor_defconfig  |  1 -
> ...s1021atwr_sdcard_ifc_SECURE_BOOT_defconfig |  1 +
> configs/ls1028ardb_tfa_defconfig  |  1 -
> configs/ls1043ardb_tfa_defconfig  |  1 -
> configs/ls1046afrwy_tfa_defconfig |  1 -
> configs/ls1046aqds_tfa_defconfig  |  1 -
> configs/ls1046ardb_tfa_defconfig  |  1 -
> configs/ls2088aqds_tfa_defconfig  |  1 -
> configs/ls2088ardb_tfa_defconfig  |  1 -
> configs/lx2160aqds_tfa_defconfig  |  1 -
> configs/lx2160ardb_tfa_defconfig  |  1 -
> configs/lx2162aqds_tfa_defconfig  |  1 -
> 36 files changed, 75 insertions(+), 102 deletions(-)
>

Reviewed-by: Priyanka Jain 

RE: [PATCH v2 11/15] Layerscape: Add crypto node in device tree

[Priyanka Jain (OSS)]

>-Original Message-
>From: U-Boot  On Behalf Of Gaurav Jain
>Sent: Friday, September 3, 2021 12:33 PM
>To: u-boot@lists.denx.de
>Cc: Stefano Babic ; Fabio Estevam ;
>Peng Fan ; Simon Glass ; Priyanka Jain
>; Ye Li ; Horia Geanta
>; Ji Luo ; Franck Lenormand
>; Silvano Di Ninno ;
>Sahil Malhotra ; Pankaj Gupta
>; Varun Sethi ; dl-uboot-imx
>; Shengzhou Liu ; Mingkai Hu
>; Rajesh Bhagat ; Meenakshi
>Aggarwal ; Wasim Khan
>; Alison Wang ; Pramod Kumar
>; Andy Tang ; Adrian Alonso
>; Vladimir Oltean ; Gaurav Jain
>
>Subject: [PATCH v2 11/15] Layerscape: Add crypto node in device tree
>
>LS(1021/1012/1028/1043/1046/1088/2088), LX2160 - updated device tree
>
>Signed-off-by: Gaurav Jain 
>---
> arch/arm/dts/fsl-ls1012a.dtsi | 46 ++-
> arch/arm/dts/fsl-ls1028a.dtsi | 41 ++-
>arch/arm/dts/fsl-ls1043a.dtsi | 45 +-
> arch/arm/dts/fsl-ls1046a.dtsi | 44 +
>arch/arm/dts/fsl-ls1088a.dtsi | 39 +
>arch/arm/dts/fsl-ls2080a.dtsi | 39 +
>arch/arm/dts/fsl-lx2160a.dtsi | 41 ++-
> arch/arm/dts/ls1021a.dtsi | 40 ++
> 8 files changed, 331 insertions(+), 4 deletions(-)
>


Reviewed-by: Priyanka Jain 

[PATCH] efi_driver: simplify efi_bl_bind()

[AKASHI Takahiro]

blk_create_devicef() is what blk_create_device() +
device_set_name_alloced() really does.
The resultant name will be a bit changed.

Signed-off-by: AKASHI Takahiro 
---
 lib/efi_driver/efi_block_device.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/lib/efi_driver/efi_block_device.c 
b/lib/efi_driver/efi_block_device.c
index 0937e3595a43..b81c75868eb4 100644
--- a/lib/efi_driver/efi_block_device.c
+++ b/lib/efi_driver/efi_block_device.c
@@ -159,15 +159,11 @@ static int efi_bl_bind(efi_handle_t handle, void 
*interface)
sprintf(name, "efiblk#%d", devnum);
 
/* Create driver model udevice for the EFI block io device */
-   ret = blk_create_device(parent, "efi_blk", name, IF_TYPE_EFI, devnum,
-   io->media->block_size,
-   (lbaint_t)io->media->last_block, );
+   ret = blk_create_devicef(parent, "efi_blk", name, IF_TYPE_EFI, devnum,
+io->media->block_size,
+(lbaint_t)io->media->last_block, );
if (ret)
return ret;
-   if (!bdev)
-   return -ENOENT;
-   /* Set the DM_FLAG_NAME_ALLOCED flag to avoid a memory leak */
-   device_set_name_alloced(bdev);
 
plat = dev_get_plat(bdev);
plat->handle = handle;
-- 
2.33.0

[PATCH v7] arm: add initial support for the Phytium Pomelo Board

[nicholas_zheng]

From: weichangzheng 

This adds platform code and the device tree for the Phytium Pomelo Board.
The initial support comprises the UART and the PCIE.

Signed-off-by: weichangzheng 
Changes since v1:
updated to DT
Changes since v2:
Modify some explicit types and macro
Changes since v3:
Modify some SDRAM related macro definitions and distro_bootcmd
Changes since v4:
Modify distro_bootcmd
Changes since v5:
Modify the CPU node description of the DT
Changes since v6:
Modify  DT
---
 arch/arm/Kconfig |  20 
 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/phytium-pomelo.dts  | 118 ++
 board/phytium/pomelo/Kconfig |  12 +++
 board/phytium/pomelo/MAINTAINERS |   8 ++
 board/phytium/pomelo/Makefile|  14 +++
 board/phytium/pomelo/cpu.h   |  73 ++
 board/phytium/pomelo/ddr.c   | 161 +++
 board/phytium/pomelo/pcie.c  |  60 
 board/phytium/pomelo/pll.c   |  73 ++
 board/phytium/pomelo/pomelo.c| 118 ++
 board/phytium/pomelo/sec.c   |  37 +++
 configs/pomelo_defconfig |  18 
 include/configs/pomelo.h |  44 +
 14 files changed, 757 insertions(+)
 create mode 100644 arch/arm/dts/phytium-pomelo.dts
 create mode 100644 board/phytium/pomelo/Kconfig
 create mode 100644 board/phytium/pomelo/MAINTAINERS
 create mode 100644 board/phytium/pomelo/Makefile
 create mode 100644 board/phytium/pomelo/cpu.h
 create mode 100644 board/phytium/pomelo/ddr.c
 create mode 100644 board/phytium/pomelo/pcie.c
 create mode 100644 board/phytium/pomelo/pll.c
 create mode 100644 board/phytium/pomelo/pomelo.c
 create mode 100644 board/phytium/pomelo/sec.c
 create mode 100644 configs/pomelo_defconfig
 create mode 100644 include/configs/pomelo.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0448787b8b..029af85fcb 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1818,6 +1818,25 @@ config TARGET_DURIAN
  Support for durian platform.
  It has 2GB Sdram, uart and pcie.
 
+config TARGET_POMELO
+   bool "Support Phytium Pomelo Platform"
+   select ARM64
+   select DM
+   select AHCI
+   select SCSI_AHCI
+   select AHCI_PCI
+   select BLK
+   select PCI
+   select DM_PCI
+   select SCSI
+   select DM_SCSI
+   select DM_SERIAL
+   select DM_ETH if NET
+   imply CMD_PCI
+   help
+  Support for pomelo platform.
+  It has 8GB Sdram, uart and pcie.
+
 config TARGET_PRESIDIO_ASIC
bool "Support Cortina Presidio ASIC Platform"
select ARM64
@@ -2038,6 +2057,7 @@ source "board/toradex/colibri_pxa270/Kconfig"
 source "board/variscite/dart_6ul/Kconfig"
 source "board/vscom/baltos/Kconfig"
 source "board/phytium/durian/Kconfig"
+source "board/phytium/pomelo/Kconfig"
 source "board/xen/xenguest_arm64/Kconfig"
 source "board/keymile/Kconfig"
 
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9fb38682e6..45d0340bd3 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1107,6 +1107,7 @@ dtb-$(CONFIG_TARGET_MX53PPD) += imx53-ppd.dtb
 dtb-$(CONFIG_TARGET_TOTAL_COMPUTE) += total_compute.dtb
 
 dtb-$(CONFIG_TARGET_DURIAN) += phytium-durian.dtb
+dtb-$(CONFIG_TARGET_POMELO) += phytium-pomelo.dtb
 
 dtb-$(CONFIG_TARGET_PRESIDIO_ASIC) += ca-presidio-engboard.dtb
 
diff --git a/arch/arm/dts/phytium-pomelo.dts b/arch/arm/dts/phytium-pomelo.dts
new file mode 100644
index 00..4ed97e090d
--- /dev/null
+++ b/arch/arm/dts/phytium-pomelo.dts
@@ -0,0 +1,118 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * dts file for Phytium Pomelo board
+ * Copyright (C) 2021, Phytium Ltd.
+ * lixinde 
+ * weichangzheng   
+ */
+/dts-v1/;
+
+/ {
+   model = "Phytium Pomelo";
+   compatible = "phytium,d2000";
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   aliases {
+   serial0 = 
+   };
+
+   cpus {
+   #address-cells = <0x2>;
+   #size-cells = <0x0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,armv8";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,armv8";
+   reg = <0x0 0x1>;
+   enable-method = "psci";
+   };
+
+   cpu2: cpu@100 {
+   device_type = "cpu";
+   compatible = "arm,armv8";
+   reg = <0x0 0x100>;
+   enable-method = "psci";
+   };
+
+   cpu3: cpu@101 {
+   device_type = "cpu";
+   compatible = "arm,armv8";
+   reg = <0x0 0x101>;
+