Re: [RESEND 0/7] Refactor generic fastboot_set_reboot_flag implementation

[Eugeniu Rosca]

Dear U-Boot maintainers,

On Fri, Oct 23, 2020 at 11:52:18AM +0300, Roman Kovalivskyi wrote:
> Current generic implementation of fastboot_set_reboot_flag is somewhat
> messy and requires some additional configuration option to be enabled
> besides CMD_BCB, so it reverts that implementtion in order to bring a
> new cleaner one.
> 
> New function called bcb_set_reboot_reason should be exposed by BCB
> commands, so that all of the details could be put there instead of
> dealing with it in fastboot implementation directly. After that,
> fastboot_set_reboot_flag could simply pass correct reboot reason
> string to the BCB implementation. If CMD_BCB is disabled then the
> whole operation would return error code, which is no different
> behaviour than the current implementation.
> 
> Eugeniu Rosca (5):
>   cmd: bcb: Extract '__bcb_load' from 'do_bcb_load' for internal needs
>   cmd: bcb: Extract '__bcb_set' from 'do_bcb_set' for internal needs
>   cmd: bcb: Extract '__bcb_store' from 'do_bcb_store' for internal needs
>   cmd: bcb: Expose 'bcb_write_reboot_reason' to external callers
>   cmd: bcb: Add support for processing const string literals in
> bcb_set()
> 
> Roman Kovalivskyi (2):
>   Revert "fastboot: Add default fastboot_set_reboot_flag implementation"
>   fastboot: Implement generic fastboot_set_reboot_flag
> 
>  cmd/bcb.c  | 88 +++---
>  drivers/fastboot/Kconfig   | 12 -
>  drivers/fastboot/Makefile  |  1 -
>  drivers/fastboot/fb_bcb_impl.c | 43 -
>  drivers/fastboot/fb_common.c   | 12 -
>  include/bcb.h  | 20 
>  include/fastboot.h |  9 
>  7 files changed, 101 insertions(+), 84 deletions(-)
>  delete mode 100644 drivers/fastboot/fb_bcb_impl.c
>  create mode 100644 include/bcb.h

Any chance the patches will be applied?

-- 
Best regards,
Eugeniu Rosca

Re: [PATCH v5 0/7] Microchip PolarFire SoC support

[Padmarao Begari]

Hi Rick,

On Thu, Dec 10, 2020 at 8:33 AM Rick Chen  wrote:

> Hi Padmarao
>
> > From: Padmarao Begari [mailto:padmarao.beg...@microchip.com]
> > Sent: Thursday, December 03, 2020 4:32 AM
> > To: u-boot@lists.denx.de; bmeng...@gmail.com; Rick Jian-Zhi Chen(陳建志);
> anup.pa...@wdc.com; lukas.a...@aisec.fraunhofer.de; joe.hershber...@ni.com;
> lu...@denx.de; atish.pa...@wdc.com
> > Cc: cyril.j...@microchip.com; lewis.ha...@microchip.com;
> ivan.grif...@emdalo.com; daire.mcnam...@emdalo.com;
> conor.doo...@microchip.com; Padmarao Begari
> > Subject: [PATCH v5 0/7] Microchip PolarFire SoC support
> >
> > This patch set adds Microchip PolarFire SoC Icicle Kit support
> > to RISC-V U-Boot.
> >
> > The patches are based upon latest U-Boot tree
> > (https://gitlab.denx.de/u-boot/u-boot.git) at commit id
> > 80cbd731df50b9ab646940ea862b70bcaff37225
> >
> > All drivers namely: NS16550 Serial, Microchip clock,
> > Cadence eMMC and Cadence MACB Ethernet work fine on actual
> > Microchip PolarFire SoC Icicle Kit.
> >
> > Changes in v5:
> > - Replace compatible string "microchip,polarfire-soc" with
> >   "microchip,mpfs-icicle-kit" in the device tree
> > - Use "mpfs" as identifier in place of "polarfire-soc", "pfsoc"
> > - Fix some typos in doc
> > - Rename the clock driver files clk_pfsoc_* to mpfs_clk_*
> > - Rename pfsoc-clock.h to mpfs-clock.h
> >
> > Changes in v4:
> > - Add dual-license GPL or MIT in the device tree
> > - Replace microsemi compatible strings with microchip
> > - Add MACB compatible string for Microchip PolarFire SoC ethernet
> > - Update MACB driver for 32-bit/64-bit DMA based on compatible string
> >
> > Changes in v3:
> > - Add 'default y if 64BIT' for config DMA_ADDR_T_64BIT
> > - Update MACB driver for 32-bit/64-bit DMA based on design config
> register
> > - Add phy-handle in MACB driver to read the phy address from device tree
> > - Fix checkpatch warnings in the clock driver
> > - Remove fu540 related compatible strings from soc device tree node
> > - Move refclk device tree node under /soc device tree node
> > - Use local-mac-address instead of mac-address in the device tree
> > - Rename device tree to microchip-mpfs-icicle-kit.dts
> > - Add U-Boot specific dts microchip-mpfs-icicle-kit-u-boot.dtsi file
> > - Drop the imply DMA_ADDR_T_64BIT from board config
> > - Fix some typos
> > - Update doc with Microchip and Custom boot-flow
> >
> > Changes in v2:
> > - Add clock frequency for the clint device tree node
> > - Move peripheral device tree nodes under /soc device tree node
> > - Device tree nodes are in order based on the address
> > - Enable UART0 for U-Boot logs
> > - Update doc for the U-Boot logs are on UART0
> > - Move clock and reset index source into patch4
> > - Remove "dma_addr_r" type in the macb driver
> > - Add lower_32_bits() for 32-bit address in the macb driver
> > - Add set_rate() returns the new clock rate in the clock driver
> >
> > Padmarao Begari (7):
> >   riscv: Add DMA 64-bit address support
> >   net: macb: Add DMA 64-bit address support for macb
> >   net: macb: Add phy address to read it from device tree
> >   clk: Add Microchip PolarFire SoC clock driver
> >   riscv: dts: Add device tree for Microchip Icicle Kit
> >   riscv: Add Microchip MPFS Icicle Kit support
> >   doc: board: Add Microchip MPFS Icicle Kit doc
> >
>
> Please check about the CI failure item Job #95.59
> https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/748298546
>
>
ok, the underline is too short for Microchip name in the index.rst file.
I will fix it in PATCH v6

Regards
Padmarao


> Thanks,
> Rick
>
> >  arch/riscv/Kconfig|   4 +
> >  arch/riscv/dts/Makefile   |   1 +
> >  .../dts/microchip-mpfs-icicle-kit-u-boot.dtsi |  14 +
> >  arch/riscv/dts/microchip-mpfs-icicle-kit.dts  | 421 +
> >  arch/riscv/include/asm/types.h|   4 +
> >  board/microchip/mpfs_icicle/Kconfig   |  24 +
> >  board/microchip/mpfs_icicle/mpfs_icicle.c |  97 +-
> >  configs/microchip_mpfs_icicle_defconfig   |   9 +-
> >  doc/board/index.rst   |   1 +
> >  doc/board/microchip/index.rst |   9 +
> >  doc/board/microchip/mpfs_icicle.rst   | 830 ++
> >  drivers/clk/Kconfig   |   1 +
> >  drivers/clk/Makefile  |   1 +
> >  drivers/clk/microchip/Kconfig |   5 +
> >  drivers/clk/microchip/Makefile|   1 +
> >  drivers/clk/microchip/mpfs_clk.c  | 127 +++
> >  drivers/clk/microchip/mpfs_clk.h  |  19 +
> >  drivers/clk/microchip/mpfs_clk_cfg.c  | 134 +++
> >  drivers/clk/microchip/mpfs_clk_periph.c   | 173 
> >  drivers/net/macb.c| 144 ++-
> >  drivers/net/macb.h|   6 +
> >  include/configs/microchip_mpfs_icicle.h   |  60 +-
> >  .../dt-bindings/clock/microchip,mpfs-clock.h  |  45 +
> >  23 files ch

Re: [PATCH v5 0/7] Microchip PolarFire SoC support

[Bin Meng]

On Thu, Dec 10, 2020 at 11:03 AM Rick Chen  wrote:
>
> Hi Padmarao
>
> > From: Padmarao Begari [mailto:padmarao.beg...@microchip.com]
> > Sent: Thursday, December 03, 2020 4:32 AM
> > To: u-boot@lists.denx.de; bmeng...@gmail.com; Rick Jian-Zhi Chen(陳建志); 
> > anup.pa...@wdc.com; lukas.a...@aisec.fraunhofer.de; joe.hershber...@ni.com; 
> > lu...@denx.de; atish.pa...@wdc.com
> > Cc: cyril.j...@microchip.com; lewis.ha...@microchip.com; 
> > ivan.grif...@emdalo.com; daire.mcnam...@emdalo.com; 
> > conor.doo...@microchip.com; Padmarao Begari
> > Subject: [PATCH v5 0/7] Microchip PolarFire SoC support
> >
> > This patch set adds Microchip PolarFire SoC Icicle Kit support
> > to RISC-V U-Boot.
> >
> > The patches are based upon latest U-Boot tree
> > (https://gitlab.denx.de/u-boot/u-boot.git) at commit id
> > 80cbd731df50b9ab646940ea862b70bcaff37225
> >
> > All drivers namely: NS16550 Serial, Microchip clock,
> > Cadence eMMC and Cadence MACB Ethernet work fine on actual
> > Microchip PolarFire SoC Icicle Kit.
> >
> > Changes in v5:
> > - Replace compatible string "microchip,polarfire-soc" with
> >   "microchip,mpfs-icicle-kit" in the device tree
> > - Use "mpfs" as identifier in place of "polarfire-soc", "pfsoc"
> > - Fix some typos in doc
> > - Rename the clock driver files clk_pfsoc_* to mpfs_clk_*
> > - Rename pfsoc-clock.h to mpfs-clock.h
> >
> > Changes in v4:
> > - Add dual-license GPL or MIT in the device tree
> > - Replace microsemi compatible strings with microchip
> > - Add MACB compatible string for Microchip PolarFire SoC ethernet
> > - Update MACB driver for 32-bit/64-bit DMA based on compatible string
> >
> > Changes in v3:
> > - Add 'default y if 64BIT' for config DMA_ADDR_T_64BIT
> > - Update MACB driver for 32-bit/64-bit DMA based on design config register
> > - Add phy-handle in MACB driver to read the phy address from device tree
> > - Fix checkpatch warnings in the clock driver
> > - Remove fu540 related compatible strings from soc device tree node
> > - Move refclk device tree node under /soc device tree node
> > - Use local-mac-address instead of mac-address in the device tree
> > - Rename device tree to microchip-mpfs-icicle-kit.dts
> > - Add U-Boot specific dts microchip-mpfs-icicle-kit-u-boot.dtsi file
> > - Drop the imply DMA_ADDR_T_64BIT from board config
> > - Fix some typos
> > - Update doc with Microchip and Custom boot-flow
> >
> > Changes in v2:
> > - Add clock frequency for the clint device tree node
> > - Move peripheral device tree nodes under /soc device tree node
> > - Device tree nodes are in order based on the address
> > - Enable UART0 for U-Boot logs
> > - Update doc for the U-Boot logs are on UART0
> > - Move clock and reset index source into patch4
> > - Remove "dma_addr_r" type in the macb driver
> > - Add lower_32_bits() for 32-bit address in the macb driver
> > - Add set_rate() returns the new clock rate in the clock driver
> >
> > Padmarao Begari (7):
> >   riscv: Add DMA 64-bit address support
> >   net: macb: Add DMA 64-bit address support for macb
> >   net: macb: Add phy address to read it from device tree
> >   clk: Add Microchip PolarFire SoC clock driver
> >   riscv: dts: Add device tree for Microchip Icicle Kit
> >   riscv: Add Microchip MPFS Icicle Kit support
> >   doc: board: Add Microchip MPFS Icicle Kit doc
> >
>
> Please check about the CI failure item Job #95.59
> https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/748298546

I would like to also take a look at the changes today.

Regards,
Bin

Re: [PATCH v5 7/7] doc: board: Add Microchip MPFS Icicle Kit doc

[Bin Meng]

Hi Padmarao,

On Thu, Dec 3, 2020 at 4:44 AM Padmarao Begari
 wrote:
>
> This doc describes the procedure to build, flash and
> boot Linux using U-boot on Microchip MPFS Icicle Kit.
>
> Signed-off-by: Padmarao Begari 
> Reviewed-by: Anup Patel 
> ---
>  doc/board/index.rst |   1 +
>  doc/board/microchip/index.rst   |   9 +
>  doc/board/microchip/mpfs_icicle.rst | 830 
>  3 files changed, 840 insertions(+)
>  create mode 100644 doc/board/microchip/index.rst
>  create mode 100644 doc/board/microchip/mpfs_icicle.rst
>
> diff --git a/doc/board/index.rst b/doc/board/index.rst
> index 4b6a996eb1..e329e2744c 100644
> --- a/doc/board/index.rst
> +++ b/doc/board/index.rst
> @@ -15,6 +15,7 @@ Board-specific doc
> freescale/index
> google/index
> intel/index
> +   microchip/index

nits: this should be inserted after kontron/index

> kontron/index
> renesas/index
> rockchip/index
> diff --git a/doc/board/microchip/index.rst b/doc/board/microchip/index.rst
> new file mode 100644
> index 00..b09e6788af
> --- /dev/null
> +++ b/doc/board/microchip/index.rst
> @@ -0,0 +1,9 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +Microchip
> +==

nits: please make sure the delimiter has the same width as the sub-titles

please fix similar issue globally in this file

> +
> +.. toctree::
> +   :maxdepth: 2
> +
> +   mpfs_icicle
> diff --git a/doc/board/microchip/mpfs_icicle.rst 
> b/doc/board/microchip/mpfs_icicle.rst
> new file mode 100644
> index 00..d37b9bcb92
> --- /dev/null
> +++ b/doc/board/microchip/mpfs_icicle.rst
> @@ -0,0 +1,830 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +Microchip PolarFire SoC Icicle Kit
> +==
> +
> +RISC-V PolarFire SoC
> +-
> +The PolarFire SoC is the 4+1 64-bit RISC-V SoC from Microchip.
> +
> +The Icicle Kit development platform is based on PolarFire SoC and capable
> +of running Linux.
> +
> +Mainline support
> +
> +The support for following drivers are already enabled:
> +
> +1. NS16550 UART Driver.
> +2. Microchip Clock Driver.
> +3. Cadence MACB ethernet driver for networking support.
> +4. Cadence MMC Driver for eMMC/SD support.
> +
> +Booting from eMMC using HSS
> +---
> +
> +Building U-Boot
> +---
> +
> +1. Add the RISC-V toolchain to your PATH.
> +2. Setup ARCH & cross compilation environment variable:
> +
> +.. code-block:: none
> +
> +   export CROSS_COMPILE=
> +
> +3. make microchip_mpfs_icicle_defconfig
> +4. make
> +
> +Flashing
> +
> +
> +The current U-Boot port is supported in S-mode only and loaded from DRAM.
> +
> +A prior stage M-mode firmware/bootloader (e.g HSS with OpenSBI) is required 
> to
> +boot the u-boot.bin in S-mode.
> +
> +Currently, the u-boot.bin is used as a payload of the HSS firmware(Microchip

nits: needs a space before ( and after )
Please fix this globally in this file.

> +boot-flow) and OpenSBI generic platform fw_payload.bin (with u-boot.bin 
> embedded)
> +as HSS payload(Custom boot-flow)
> +
> +Microchip boot-flow
> +---
> +HSS with OpenSBI(M-Mode) -> U-Boot(S-Mode) -> Linux(S-Mode)
> +
> +Build the HSS((Hart Software Services) - Microchip boot-flow

redundant (

> +
> +(Note: HSS git repo is at
> +https://github.com/polarfire-soc/hart-software-services)
> +
> +1. Configure
> +
> +.. code-block:: none
> +
> +   make BOARD=icicle-kit-es config
> +
> +Alternatively, copy the default config for Microchip boot-flow.
> +
> +.. code-block:: none
> +
> +   cp boards/icicle-kit-es/def_config .config
> +
> +2. make BOARD=icicle-kit-es
> +3. In the Default subdirectory, the standard build will create hss.elf and
> +   various binary formats (hss.hex and hss.bin).
> +
> +The FPGA design will use the hss.hex or hss.bin.
> +
> +FPGA design with HSS programming file
> +-
> +https://github.com/polarfire-soc/polarfire-soc-documentation/blob/master/boards
> +/mpfs-icicle-kit-es/updating-icicle-kit/updating-icicle-kit-design-and-linux.md

Having the URL in 2 lines breaks the link, I think.

> +
> +The HSS firmware runs from the PolarFire SoC eNVM on reset.
> +
> +Creating the HSS payload - Microchip boot-flow
> +--
> +1. You will be creating a payload from `u-boot-dtb.bin`.
> +   Copy this file to the HSS/tools/hss-payload-generator/test directory.
> +2. Go to hss-payload-generator source directory.
> +
> +.. code-block:: none
> +
> +   cd hart-software-services/tools/hss-payload-generator
> +
> +3. Edit test/uboot.yaml file for hart entry points and correct name of the 
> binary file.
> +
> +   hart-entry-points: {u54_1: '0x8020', u54_2: '0x8020',
> +   u54_3: '0x8020', u54_4: '0x8020'}
> +
> +   payloads:
> +   test/u-boot-dtb.bin: {exec-addr: '0x8020', owner-har

[PATCH] arm: mvebu: Add armada-xp-gp-u-boot.dtsi for U-Boot properties

[Stefan Roese]

Add some missing "u-boot,dm-pre-reloc;" properties to UART0, SPI
controller and SPI NOR flash node to enable usage in SPL. Otherwise
these devices will not be available.

Signed-off-by: Stefan Roese 
Cc: Dennis Gilmore 
---
 arch/arm/dts/armada-xp-gp-u-boot.dtsi | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 arch/arm/dts/armada-xp-gp-u-boot.dtsi

diff --git a/arch/arm/dts/armada-xp-gp-u-boot.dtsi 
b/arch/arm/dts/armada-xp-gp-u-boot.dtsi
new file mode 100644
index 00..2422856616
--- /dev/null
+++ b/arch/arm/dts/armada-xp-gp-u-boot.dtsi
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/ {
+   soc {
+   internal-regs {
+   serial@12000 {
+   u-boot,dm-pre-reloc;
+   };
+   };
+   };
+};
+
+&spi0 {
+   u-boot,dm-pre-reloc;
+
+   spi-flash@0 {
+   u-boot,dm-pre-reloc;
+   };
+};
-- 
2.29.2

[PATCH v3] arm: fsl: common: Improve NXP VID driver PMBus support

[Stephen Carlson]

This patch adds support for more PMBus compatible devices to the NXP
drivers for its QorIQ family devices. At runtime, the voltage regulator is
queried over I2C, and the required voltage multiplier determined. This
change supports the DIRECT and LINEAR PMBus voltage reporting modes.

Previously, the driver only supported a few specific devices such as the
IR36021 and LTC3882, so this change allows the QorIQ series to be used
with a much larger variety of core voltage regulator devices.

checkpatch warning "Use if (IS_DEFINED (...))" was ignored to maintain
consistency with the existing code.

Signed-off-by: Stephen Carlson 
Cc: Priyanka Jain 
---
 board/freescale/common/Kconfig|  27 +-
 board/freescale/common/vid.c  | 815 --
 board/freescale/common/vid.h  |  13 +-
 board/freescale/ls1028a/ls1028a.c |  42 ++
 board/freescale/ls1088a/ls1088a.c |  40 ++
 board/freescale/ls2080a/ls2080a.c |  49 ++
 board/freescale/lx2160a/lx2160a.c |  42 ++
 include/configs/ls1088aqds.h  |   6 -
 include/configs/ls1088ardb.h  |   8 +-
 9 files changed, 526 insertions(+), 516 deletions(-)

diff --git a/board/freescale/common/Kconfig b/board/freescale/common/Kconfig
index 1b1fd69cb2..17db755951 100644
--- a/board/freescale/common/Kconfig
+++ b/board/freescale/common/Kconfig
@@ -21,18 +21,37 @@ config CMD_ESBC_VALIDATE
esbc_validate - validate signature using RSA verification
esbc_halt - put the core in spin loop (Secure Boot Only)

+config VID
+   depends on DM_I2C
+   bool "Enable Freescale VID"
+   help
+This option enables setting core voltage based on individual
+values saved in SoC fuses.
+
 config VOL_MONITOR_LTC3882_READ
depends on VID
bool "Enable the LTC3882 voltage monitor read"
-   default n
help
 This option enables LTC3882 voltage monitor read
-functionality. It is used by common VID driver.
+functionality. It is used by the common VID driver.

 config VOL_MONITOR_LTC3882_SET
depends on VID
bool "Enable the LTC3882 voltage monitor set"
-   default n
help
 This option enables LTC3882 voltage monitor set
-functionality. It is used by common VID driver.
+functionality. It is used by the common VID driver.
+
+config VOL_MONITOR_ISL68233_READ
+   depends on VID
+   bool "Enable the ISL68233 voltage monitor read"
+   help
+This option enables ISL68233 voltage monitor read
+functionality. It is used by the common VID driver.
+
+config VOL_MONITOR_ISL68233_SET
+   depends on VID
+   bool "Enable the ISL68233 voltage monitor set"
+   help
+This option enables ISL68233 voltage monitor set
+functionality. It is used by the common VID driver.
diff --git a/board/freescale/common/vid.c b/board/freescale/common/vid.c
index 9c51f50260..2df3adf3bc 100644
--- a/board/freescale/common/vid.c
+++ b/board/freescale/common/vid.c
@@ -1,6 +1,8 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
  * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * Copyright 2020 Stephen Carlson 
  */

 #include 
@@ -20,14 +22,22 @@
 #include 
 #include "vid.h"

+/* Voltages are generally handled in mV to keep them as integers */
+#define MV_PER_V 1000
+
+/*
+ * Select the channel on the I2C mux (on some NXP boards) that contains
+ * the voltage regulator to use for VID. Return 0 for success or nonzero
+ * for failure.
+ */
 int __weak i2c_multiplexer_select_vid_channel(u8 channel)
 {
return 0;
 }

 /*
- * Compensate for a board specific voltage drop between regulator and SoC
- * return a value in mV
+ * Compensate for a board specific voltage drop between regulator and SoC.
+ * Returns the voltage offset in mV.
  */
 int __weak board_vdd_drop_compensation(void)
 {
@@ -35,13 +45,90 @@ int __weak board_vdd_drop_compensation(void)
 }

 /*
- * Board specific settings for specific voltage value
+ * Performs any board specific adjustments after the VID voltage has been
+ * set. Return 0 for success or nonzero for failure.
  */
 int __weak board_adjust_vdd(int vdd)
 {
return 0;
 }

+/*
+ * Processor specific method of converting the fuse value read from VID
+ * registers into the core voltage to supply. Return the voltage in mV.
+ */
+u16 __weak soc_get_fuse_vid(int vid_index)
+{
+   /* Default VDD for Layerscape Chassis 1 devices */
+   static const u16 vdd[32] = {
+   0,  /* unused */
+   9875,   /* 0.9875V */
+   9750,
+   9625,
+   9500,
+   9375,
+   9250,
+   9125,
+   9000,
+   8875,
+   8750,
+   8625,
+   8500,
+   8375,
+   8250,
+   8125,
+   1,  /* 1.V */
+   10125,
+   10250,
+   10375,
+   10500,
+   106

Re: [PATCH] riscv: timer: Add support for an early timer

[Rick Chen]

Hi Pragnesh


> Hi Rick,
>
> [...]
> >>
> >>Following are the configurations, steps and debug logs:
> >>
> >>+++ b/configs/ae350_rv64_defconfig
> >>q+CONFIG_TRACE=y
> >>+CONFIG_TRACE_BUFFER_SIZE=0x0100
> >>+CONFIG_TRACE_CALL_DEPTH_LIMIT=15
> >>+CONFIG_CMD_TRACE=y
> >>+CONFIG_TIMER_EARLY=y
> >>
> >>+++ b/configs/ae350_rv64_spl_defconfig
> >>+CONFIG_TRACE=y
> >>+CONFIG_TRACE_BUFFER_SIZE=0x0100
> >>+CONFIG_TRACE_CALL_DEPTH_LIMIT=15
> >>+CONFIG_CMD_TRACE=y
> >>+CONFIG_TIMER_EARLY=y
> >>
> >> case 1
> >>///
> >>ae350_rv64_defconfig with FTRACE=1, kernel booting is ok
> >> case 1
> >>///
> >>make FTRACE=1 ae350_rv64_defconfig
> >>make FTRACE=1
> >>///
> [...]
> >> case 2
> >>///
> >>ae350_rv64_spl_defconfig with FTRACE=1, kernel booting fail
> >> case 2
> >>///
> >>make FTRACE=1 ae350_rv64_spl_defconfig
> >>make FTRACE=1
> >>///
> >>///
> >>/
> [...]
> >>(hang here)
> >
> >Thanks for the logs.
> >
> >From logs, I can't find where it got stuck. Can you please use gdb to see 
> >where it
> >got stuck ?
> >
> >Meanwhile I will give it a try on HiFive Unleashed board.
>
> On HiFive Unleashed it works fine with tracing.
>
> U-Boot 2021.01-rc2-00049-gb2a38d1d0f (Dec 01 2020 - 15:04:41 +0530)
> CPU:   rv64imafdc
> Model: SiFive HiFive Unleashed A00
> DRAM:  8 GiB
> trace: enabled
> MMC:   spi@1005:mmc@0: 0
> Loading Environment from SPIFlash... SF: Detected is25wp256 with page size 
> 256 Bytes, erase size 4 KiB, total 32 MiB
> *** Warning - bad CRC, using default environment
> In:serial@1001
> Out:   serial@1001
> Err:   serial@1001
> Net:   eth0: ethernet@1009
> Hit any key to stop autoboot:  0
> =>
> => trace stats
> 178,750 function sites
>  25,359,991 function calls
>   1 untracked function calls
>   1,278,927 traced function calls (24358307 dropped due to overflow)
>  19 maximum observed call depth
>  15 call depth limit
>  25,238,922 calls not traced due to depth
> => fatload mmc 0:3 0x8600 hifive-unleashed-a00.dtb
> 7199 bytes read in 27 ms (259.8 KiB/s)
> => fatload mmc 0:3 0x8400 uImage
> 21421212 bytes read in 19496 ms (1 MiB/s)
> => bootm 0x8400 - 0x8600
> ## Booting kernel from Legacy Image at 8400 ...
>Image Name:   Linux
>Image Type:   RISC-V Linux Kernel Image (uncompressed)
>Data Size:21421148 Bytes = 20.4 MiB
>Load Address: 8020
>Entry Point:  8020
>Verifying Checksum ... OK
> ## Flattened Device Tree blob at 8600
>Booting using the fdt blob at 0x8600
>Loading Kernel Image
>Using Device Tree in place at 8600, end 86004c1e
> Starting kernel ...(fake run for tracing)
> Starting kernel ...
> [0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020
> [0.00] Linux version 5.8.0-rc3-16077-g9ebcfadb0610-dirty 
> (pragneshp@sachinj2-OptiPlex-7010) (riscv64-unknown-linux-gnu-gcc 
> (crosstool-NG 1.24.0.37-3f461da) 9.2.0, GNU ld (crosstool-NG 
> 1.24.0.37-3f461da) 2.32) #34 SMP Tue Jul 21 15:56:29 IST 2020
> [0.00] initrd not found or empty - disabling initrd
> [0.00] Zone ranges:
> [0.00]   DMA32[mem 0x8020-0x]
> [0.00]   Normal   [mem 0x0001-0x00027fff]
> [0.00] Movable zone start for each node
> [0.00] Early memory node ranges
> [0.00]   node   0: [mem 0x8020-0x00027fff]
> [0.00] Initmem setup node 0 [mem 
> 0x8020-0x00027fff]
> 
> Welcome to Buildroot
> buildroot login: root
> Password:
>

Please check about the CI failure item Job #95.56
https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/748298543

Thanks,
Rick

Re: [PATCH v5 0/7] Microchip PolarFire SoC support

[Rick Chen]

Hi Padmarao

> From: Padmarao Begari [mailto:padmarao.beg...@microchip.com]
> Sent: Thursday, December 03, 2020 4:32 AM
> To: u-boot@lists.denx.de; bmeng...@gmail.com; Rick Jian-Zhi Chen(陳建志); 
> anup.pa...@wdc.com; lukas.a...@aisec.fraunhofer.de; joe.hershber...@ni.com; 
> lu...@denx.de; atish.pa...@wdc.com
> Cc: cyril.j...@microchip.com; lewis.ha...@microchip.com; 
> ivan.grif...@emdalo.com; daire.mcnam...@emdalo.com; 
> conor.doo...@microchip.com; Padmarao Begari
> Subject: [PATCH v5 0/7] Microchip PolarFire SoC support
>
> This patch set adds Microchip PolarFire SoC Icicle Kit support
> to RISC-V U-Boot.
>
> The patches are based upon latest U-Boot tree
> (https://gitlab.denx.de/u-boot/u-boot.git) at commit id
> 80cbd731df50b9ab646940ea862b70bcaff37225
>
> All drivers namely: NS16550 Serial, Microchip clock,
> Cadence eMMC and Cadence MACB Ethernet work fine on actual
> Microchip PolarFire SoC Icicle Kit.
>
> Changes in v5:
> - Replace compatible string "microchip,polarfire-soc" with
>   "microchip,mpfs-icicle-kit" in the device tree
> - Use "mpfs" as identifier in place of "polarfire-soc", "pfsoc"
> - Fix some typos in doc
> - Rename the clock driver files clk_pfsoc_* to mpfs_clk_*
> - Rename pfsoc-clock.h to mpfs-clock.h
>
> Changes in v4:
> - Add dual-license GPL or MIT in the device tree
> - Replace microsemi compatible strings with microchip
> - Add MACB compatible string for Microchip PolarFire SoC ethernet
> - Update MACB driver for 32-bit/64-bit DMA based on compatible string
>
> Changes in v3:
> - Add 'default y if 64BIT' for config DMA_ADDR_T_64BIT
> - Update MACB driver for 32-bit/64-bit DMA based on design config register
> - Add phy-handle in MACB driver to read the phy address from device tree
> - Fix checkpatch warnings in the clock driver
> - Remove fu540 related compatible strings from soc device tree node
> - Move refclk device tree node under /soc device tree node
> - Use local-mac-address instead of mac-address in the device tree
> - Rename device tree to microchip-mpfs-icicle-kit.dts
> - Add U-Boot specific dts microchip-mpfs-icicle-kit-u-boot.dtsi file
> - Drop the imply DMA_ADDR_T_64BIT from board config
> - Fix some typos
> - Update doc with Microchip and Custom boot-flow
>
> Changes in v2:
> - Add clock frequency for the clint device tree node
> - Move peripheral device tree nodes under /soc device tree node
> - Device tree nodes are in order based on the address
> - Enable UART0 for U-Boot logs
> - Update doc for the U-Boot logs are on UART0
> - Move clock and reset index source into patch4
> - Remove "dma_addr_r" type in the macb driver
> - Add lower_32_bits() for 32-bit address in the macb driver
> - Add set_rate() returns the new clock rate in the clock driver
>
> Padmarao Begari (7):
>   riscv: Add DMA 64-bit address support
>   net: macb: Add DMA 64-bit address support for macb
>   net: macb: Add phy address to read it from device tree
>   clk: Add Microchip PolarFire SoC clock driver
>   riscv: dts: Add device tree for Microchip Icicle Kit
>   riscv: Add Microchip MPFS Icicle Kit support
>   doc: board: Add Microchip MPFS Icicle Kit doc
>

Please check about the CI failure item Job #95.59
https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/748298546

Thanks,
Rick

>  arch/riscv/Kconfig|   4 +
>  arch/riscv/dts/Makefile   |   1 +
>  .../dts/microchip-mpfs-icicle-kit-u-boot.dtsi |  14 +
>  arch/riscv/dts/microchip-mpfs-icicle-kit.dts  | 421 +
>  arch/riscv/include/asm/types.h|   4 +
>  board/microchip/mpfs_icicle/Kconfig   |  24 +
>  board/microchip/mpfs_icicle/mpfs_icicle.c |  97 +-
>  configs/microchip_mpfs_icicle_defconfig   |   9 +-
>  doc/board/index.rst   |   1 +
>  doc/board/microchip/index.rst |   9 +
>  doc/board/microchip/mpfs_icicle.rst   | 830 ++
>  drivers/clk/Kconfig   |   1 +
>  drivers/clk/Makefile  |   1 +
>  drivers/clk/microchip/Kconfig |   5 +
>  drivers/clk/microchip/Makefile|   1 +
>  drivers/clk/microchip/mpfs_clk.c  | 127 +++
>  drivers/clk/microchip/mpfs_clk.h  |  19 +
>  drivers/clk/microchip/mpfs_clk_cfg.c  | 134 +++
>  drivers/clk/microchip/mpfs_clk_periph.c   | 173 
>  drivers/net/macb.c| 144 ++-
>  drivers/net/macb.h|   6 +
>  include/configs/microchip_mpfs_icicle.h   |  60 +-
>  .../dt-bindings/clock/microchip,mpfs-clock.h  |  45 +
>  23 files changed, 2068 insertions(+), 62 deletions(-)
>  create mode 100644 arch/riscv/dts/microchip-mpfs-icicle-kit-u-boot.dtsi
>  create mode 100644 arch/riscv/dts/microchip-mpfs-icicle-kit.dts
>  create mode 100644 doc/board/microchip/index.rst
>  create mode 100644 doc/board/microchip/mpfs_icicle.rst
>  create mode 100644 drivers/clk/microchip/Kconfig
>  create mode 100644 dri

[v2] configs: ls1088aqds: add COMMON_ENV to fix distroboot

[Biwen Li]

From: Biwen Li 

Add COMMON_ENV(kernel_addr_r, fdt_addr_r and so on)
to fix a bug that faild to boot to ubuntu, failed
log as follows,
## Executing script at 8000
load - load binary file from a filesystemUsage:
load  [ [ [ [bytes [pos]
- Load binary file filename from partition part on device
   type interface instance dev to address addr in memory.
  bytes gives the size to load in bytes.
  If bytes is 0 or omitted, the file is read until the end.
  pos gives the file byte position to start reading from.
  If pos is 0 or omitted, the file is read from the start.
...
Bad Linux ARM64 Image magic!
SCRIPT FAILED: continuing...

Signed-off-by: Biwen Li 
---
Change in v2:
- update description

 include/configs/ls1088aqds.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/configs/ls1088aqds.h b/include/configs/ls1088aqds.h
index 59757120fc..0dd6bb9f32 100644
--- a/include/configs/ls1088aqds.h
+++ b/include/configs/ls1088aqds.h
@@ -384,10 +384,18 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_ESDHC_DETECT_QUIRK ((readb(QIXIS_BASE + QIXIS_STAT_PRES1) & \
QIXIS_SDID_MASK) != QIXIS_ESDHC_NO_ADAPTER)
 
+#define COMMON_ENV \
+   "kernelheader_addr_r=0x8020\0"  \
+   "fdtheader_addr_r=0x8010\0" \
+   "kernel_addr_r=0x8100\0"\
+   "fdt_addr_r=0x9000\0"   \
+   "load_addr=0xa000\0"
+
 /* Initial environment variables */
 #ifdef CONFIG_NXP_ESBC
 #undef CONFIG_EXTRA_ENV_SETTINGS
 #define CONFIG_EXTRA_ENV_SETTINGS  \
+   COMMON_ENV  \
"hwconfig=fsl_ddr:bank_intlv=auto\0"\
"loadaddr=0x9010\0" \
"kernel_addr=0x10\0"\
@@ -419,6 +427,7 @@ unsigned long get_board_ddr_clk(void);
 
 #undef CONFIG_EXTRA_ENV_SETTINGS
 #define CONFIG_EXTRA_ENV_SETTINGS  \
+   COMMON_ENV  \
"hwconfig=fsl_ddr:bank_intlv=auto\0"\
"loadaddr=0x9010\0" \
"kernel_addr=0x10\0"\
@@ -480,6 +489,7 @@ unsigned long get_board_ddr_clk(void);
 #if defined(CONFIG_QSPI_BOOT)
 #undef CONFIG_EXTRA_ENV_SETTINGS
 #define CONFIG_EXTRA_ENV_SETTINGS  \
+   COMMON_ENV  \
"hwconfig=fsl_ddr:bank_intlv=auto\0"\
"loadaddr=0x9010\0" \
"kernel_addr=0x10\0"\
@@ -497,6 +507,7 @@ unsigned long get_board_ddr_clk(void);
 #elif defined(CONFIG_SD_BOOT)
 #undef CONFIG_EXTRA_ENV_SETTINGS
 #define CONFIG_EXTRA_ENV_SETTINGS   \
+   COMMON_ENV  \
"hwconfig=fsl_ddr:bank_intlv=auto\0"\
"loadaddr=0x9010\0" \
"kernel_addr=0x800\0"\
@@ -514,6 +525,7 @@ unsigned long get_board_ddr_clk(void);
 #else  /* NOR BOOT */
 #undef CONFIG_EXTRA_ENV_SETTINGS
 #define CONFIG_EXTRA_ENV_SETTINGS  \
+   COMMON_ENV  \
"hwconfig=fsl_ddr:bank_intlv=auto\0"\
"loadaddr=0x9010\0" \
"kernel_addr=0x10\0"\
-- 
2.17.1

Re: [PATCH 1/1] riscv: qemu: enable distro boot from scsi

[Bin Meng]

On Wed, Dec 2, 2020 at 12:30 AM Heinrich Schuchardt  wrote:
>
> Booting via distro boot fails for:
>
> qemu-system-riscv64
> -drive if=none,file=sct-riscv64.img,format=raw,id=mydisk \
> -device ich9-ahci,id=ahci -device ide-hd,drive=mydisk,bus=ahci.0
>
> Enable distro booting from an attached SCSI disk.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/configs/qemu-riscv.h | 1 +
>  1 file changed, 1 insertion(+)
>

Reviewed-by: Bin Meng 

Re: [PATCH 01/11] dm: core: Rename device_bind() to device_bind_offset()

[Simon Glass]

This function is not necessary anymore, since device_bind_ofnode() does
the same thing and works with both flattree and livetree.

Rename it to indicate that it is special.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/apollolake/spl.c   | 2 +-
 drivers/clk/clk.c   | 2 +-
 drivers/core/device.c   | 6 +++---
 drivers/gpio/mt7621_gpio.c  | 4 ++--
 drivers/gpio/s5p_gpio.c | 4 ++--
 drivers/gpio/sunxi_gpio.c   | 4 ++--
 drivers/gpio/tegra186_gpio.c| 4 ++--
 drivers/gpio/tegra_gpio.c   | 5 +++--
 drivers/net/mvpp2.c | 2 +-
 drivers/pinctrl/broadcom/pinctrl-bcm283x.c  | 5 +++--
 drivers/pinctrl/meson/pinctrl-meson.c   | 2 +-
 drivers/pinctrl/mscc/pinctrl-jr2.c  | 4 ++--
 drivers/pinctrl/mscc/pinctrl-luton.c| 4 ++--
 drivers/pinctrl/mscc/pinctrl-ocelot.c   | 4 ++--
 drivers/pinctrl/mscc/pinctrl-serval.c   | 4 ++--
 drivers/pinctrl/mscc/pinctrl-servalt.c  | 4 ++--
 drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 4 ++--
 drivers/power/regulator/Kconfig | 2 +-
 include/dm/device-internal.h| 8 
 include/power/regulator.h   | 2 +-
 20 files changed, 39 insertions(+), 37 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 2/5] patman: Drop unicode helper functions

[Simon Glass]

We don't need these now that everything uses Python 3. Remove them and
the extra code in GetBytes() and ToBytes() too.

Signed-off-by: Simon Glass 
---

 tools/binman/etype/fmap.py |  2 +-
 tools/binman/fmap_util.py  |  3 +--
 tools/dtoc/dtb_platdata.py |  3 ++-
 tools/patman/func_test.py  | 16 +
 tools/patman/gitutil.py|  3 +--
 tools/patman/series.py |  4 +---
 tools/patman/settings.py   |  5 ++--
 tools/patman/tools.py  | 47 +++---
 8 files changed, 17 insertions(+), 66 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 3/5] patman: Drop tools.ToByte()

[Simon Glass]

This is not needed in Python 3. Drop it.

Signed-off-by: Simon Glass 
---

 tools/binman/elf.py|  6 +++---
 tools/dtoc/dtb_platdata.py |  2 +-
 tools/patman/tools.py  | 15 ---
 3 files changed, 4 insertions(+), 19 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 1/5] fdt: Use an Enum for the data type

[Simon Glass]

Use an Enum instead of the current ad-hoc constants, so that there is a
data type associated with each 'type' value.

Signed-off-by: Simon Glass 
---

 tools/binman/fdt_test.py   | 14 +-
 tools/dtoc/dtb_platdata.py | 26 +-
 tools/dtoc/fdt.py  | 54 +-
 tools/dtoc/test_dtoc.py| 10 +++
 tools/dtoc/test_fdt.py | 32 +++---
 5 files changed, 77 insertions(+), 59 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 4/5] patman: Drop tools.ToChar() and ToChars()

[Simon Glass]

This is useful anymore, since we always want to call chr() in Python 3.
Drop it and adjust callers to use chr().

Also drop ToChars() which is no-longer used.

Signed-off-by: Simon Glass 
---

 tools/dtoc/fdt.py  |  8 
 tools/dtoc/test_fdt.py |  2 +-
 tools/patman/tools.py  | 23 ---
 3 files changed, 5 insertions(+), 28 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 5/5] dtoc: Tidy up Python style in dtb_platdata

[Simon Glass]

Hi Simon,

Thanks for this series. I've tried to test it but I had issues to apply
it. I have tried in u-boot, both master and next, and u-boot-dm.

Could you please point me to the right tree/version?

On 9/11/20 00:36, Simon Glass wrote:
> Update this, mostly to add comments for argument and return types. It is
> probably still too early to use type hinting since it was introduced in
> 3.5.
>
> Signed-off-by: Simon Glass 
> ---
>
>   tools/dtoc/dtb_platdata.py | 71 ++
>   1 file changed, 42 insertions(+), 29 deletions(-)
>
Applied to u-boot-dm, thanks!

Re: [PATCH 1/3] serial: sandbox: Drop unnecessary #ifdefs

[Simon Glass]

CONFIG_OF_CONTROL is always enabled for sandbox (as it should be for all
boards), so we can drop it. Also use IS_ENABLED() for the SPL check.

Signed-off-by: Simon Glass 
---

 drivers/serial/sandbox.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 02/11] dm: core: Rename device_bind_ofnode() to device_bind()

[Simon Glass]

This is the standard function to use when binding devices. Drop the
'_ofnode' suffix to make this clear.

Signed-off-by: Simon Glass 
---

 drivers/core/device.c | 6 +++---
 drivers/firmware/scmi/scmi_agent-uclass.c | 4 ++--
 drivers/gpio/dwapb_gpio.c | 4 ++--
 drivers/misc/i2c_eeprom.c | 4 ++--
 drivers/mtd/spi/sandbox.c | 2 +-
 drivers/pci/pci-uclass.c  | 4 ++--
 drivers/pci/pci_mvebu.c   | 4 ++--
 drivers/usb/host/usb-uclass.c | 4 ++--
 include/dm/device-internal.h  | 6 +++---
 test/dm/core.c| 4 ++--
 10 files changed, 21 insertions(+), 21 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH v2 3/4] efi_selftest: implement exception test for sandbox

[Simon Glass]

On 17.11.20 00:53, Simon Glass wrote:
> On Wed, 11 Nov 2020 at 16:30, Heinrich Schuchardt  wrote:
>>
>> Provide a unit test that causes an illegal instruction to occur.
>>
>> The test can be run with the following commands:
>>
>> => setenv efi_selftest exception
>> => bootefi selftest
>>
>> This might be the output:
>>
>> Executing 'exception'
>> EFI application triggers exception.
>> Illegal instruction
>> pc = 0x1444d016, pc_reloc = 0xaa078e8dd016
>> UEFI image [0x:0x] '/\selftest'
>> UEFI image [0x1444b000:0x14451fff] pc=0x2016 '/bug.efi'
>> Resetting ...
>>
>> It would tell us that the exception was triggered by an instruction
>> 0x2016 bytes after the load address of the binary with filename /bug.efi.
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>> v2:
>> no change
>> ---
>>  lib/efi_selftest/efi_selftest_miniapp_exception.c | 2 ++
>>  1 file changed, 2 insertions(+)
>
> Reviewed-by: Simon Glass 
>
>>
Applied to u-boot-dm, thanks!

Re: [PATCH v2 2/4] cmd: sandbox: implement exception command

[Simon Glass]

Implement the commands

* exception undefined - execute an illegal instruction
* exception sigsegv - cause a segment violation

Here is a possible output:

=> exception undefined
Illegal instruction
pc = 0x55eb8d0a7575, pc_reloc = 0x57575
Resetting ...

Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Simon Glass 
---
v2:
no change
---
 cmd/Kconfig |  2 +-
 cmd/Makefile|  1 +
 cmd/sandbox/Makefile|  3 +++
 cmd/sandbox/exception.c | 41 +
 4 files changed, 46 insertions(+), 1 deletion(-)
 create mode 100644 cmd/sandbox/Makefile
 create mode 100644 cmd/sandbox/exception.c

Applied to u-boot-dm, thanks!

Re: [PATCH v2 1/4] sandbox: add handler for exceptions

[Simon Glass]

On 17.11.20 00:53, Simon Glass wrote:
> Hi Heinrich,
>
> On Wed, 11 Nov 2020 at 16:30, Heinrich Schuchardt  wrote:
>>
>> Add a handler for SIGILL, SIGBUS, SIGSEGV.
>>
>> When an exception occurs print the program counter and the loaded
>> UEFI binaries and reset the system if CONFIG_SANDBOX_CRASH_RESET=y
>> or exit to the OS otherwise.
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>> v2:
>> add a customizing switch
>> set SA_NODEFER flag for sigaction
>> ---
>>  arch/sandbox/Kconfig  |  9 
>>  arch/sandbox/cpu/os.c | 40 +++
>>  arch/sandbox/cpu/start.c  |  4 
>>  arch/sandbox/lib/interrupts.c | 35 ++
>>  include/os.h  | 17 +++
>>  5 files changed, 105 insertions(+)
>
> Reviewed-by: Simon Glass 
>
> Do you think a command-line flag might be useful too/instead?
>

For my needs the CONFIG flag is enough.

I could not find the mail for patch 2/4 in my inbox.
I have tested on aarch64 that the exception work here too.

Best regards

Heinrich

Applied to u-boot-dm, thanks!

Re: [PATCH 04/11] dm: Remove uses of device_bind_offset()

[Simon Glass]

This function is not needed since the standard device_bind() can be used
instead.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/apollolake/spl.c   |  2 +-
 drivers/clk/at91/compat.c   | 20 
 drivers/clk/clk.c   |  2 +-
 drivers/gpio/mt7621_gpio.c  |  4 ++--
 drivers/gpio/s5p_gpio.c |  4 ++--
 drivers/gpio/sunxi_gpio.c   |  4 ++--
 drivers/gpio/tegra186_gpio.c|  4 ++--
 drivers/gpio/tegra_gpio.c   |  6 +++---
 drivers/net/mvpp2.c |  4 ++--
 drivers/pinctrl/broadcom/pinctrl-bcm283x.c  |  5 ++---
 drivers/pinctrl/meson/pinctrl-meson.c   |  4 +++-
 drivers/pinctrl/mscc/pinctrl-jr2.c  |  4 ++--
 drivers/pinctrl/mscc/pinctrl-luton.c|  4 ++--
 drivers/pinctrl/mscc/pinctrl-ocelot.c   |  4 ++--
 drivers/pinctrl/mscc/pinctrl-serval.c   |  4 ++--
 drivers/pinctrl/mscc/pinctrl-servalt.c  |  4 ++--
 drivers/pinctrl/mvebu/pinctrl-armada-37xx.c |  8 
 drivers/power/regulator/Kconfig |  2 +-
 include/dm/device-internal.h|  4 ++--
 include/power/regulator.h   |  2 +-
 20 files changed, 46 insertions(+), 49 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 05/11] dm: Drop uses of dev_set_of_offset()

[Simon Glass]

The need for this can be avoided by passing the correct node to the
device_bind() function.

Signed-off-by: Simon Glass 
---

 drivers/gpio/mt7621_gpio.c| 3 +--
 drivers/gpio/s5p_gpio.c   | 4 +---
 drivers/gpio/sunxi_gpio.c | 3 +--
 drivers/gpio/tegra186_gpio.c  | 3 +--
 drivers/gpio/tegra_gpio.c | 5 ++---
 drivers/pinctrl/meson/pinctrl-meson.c | 1 -
 6 files changed, 6 insertions(+), 13 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 03/11] dm: core: Add a livetree function to check node status

[Simon Glass]

Add a way to find out if a node is enabled or not, based on its 'status'
property.

Signed-off-by: Simon Glass 
---

 drivers/core/ofnode.c | 10 ++
 include/dm/ofnode.h   | 11 +++
 test/dm/ofnode.c  | 12 
 3 files changed, 33 insertions(+)

Applied to u-boot-dm, thanks!

Re: [PATCH 06/11] dm: core: Drop dev_set_of_offset()

[Simon Glass]

This pre-livetree function is not needed anymore. Drop it.

Signed-off-by: Simon Glass 
---

 include/dm/device.h | 5 -
 1 file changed, 5 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 07/11] dm: core: Drop device_bind_offset()

[Simon Glass]

This function is not needed since the standard device_bind() can be used
instead. Drop it.

Signed-off-by: Simon Glass 
---

 drivers/core/device.c|  8 
 include/dm/device-internal.h | 10 +++---
 2 files changed, 3 insertions(+), 15 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 08/11] dm: core: Add an ofnode function to get the devicetree root

[Simon Glass]

This is needed in at least one place. Avoid the conditional code in root.c
by adding this inline function.

Signed-off-by: Simon Glass 
---

 drivers/core/root.c |  8 ++--
 include/dm/ofnode.h | 12 
 2 files changed, 14 insertions(+), 6 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 09/11] dm: core: Combine the flattree and livetree binding code

[Simon Glass]

At present there are two copies of this code. With ofnode we can combine
them to reduce duplication. Update the dm_scan_fdt_node() function and
adjust its callers.

Signed-off-by: Simon Glass 
---

 drivers/core/root.c | 74 ++---
 1 file changed, 16 insertions(+), 58 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 10/11] dm: core: Drop unused parameter from dm_scan_fdt()

[Simon Glass]

This doesn't need to be passed the devicetree anymore. Drop it.

Signed-off-by: Simon Glass 
---

 drivers/core/root.c | 9 -
 include/dm/root.h   | 3 +--
 test/dm/core.c  | 2 +-
 test/dm/test-fdt.c  | 2 +-
 test/dm/test-main.c | 2 +-
 5 files changed, 8 insertions(+), 10 deletions(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 11/11] dm: core: Drop unused parameter from dm_extended_scan_fdt()

[Simon Glass]

This doesn't need to be passed the devicetree anymore. Drop it.
Also rename the function to drop the _fdt suffix.

Signed-off-by: Simon Glass 
---

 drivers/core/root.c | 6 +++---
 include/dm/root.h   | 5 ++---
 test/dm/test-fdt.c  | 2 +-
 test/dm/test-main.c | 2 +-
 4 files changed, 7 insertions(+), 8 deletions(-)

Applied to u-boot-dm, thanks!

Re: A3720 - Disable slot when eMMC is not present

[Jaehoon Chung]

On 12/9/20 7:25 PM, Pali Rohár wrote:
> On Wednesday 09 December 2020 19:01:19 Jaehoon Chung wrote:
>> Hi,
>>
>> On 12/8/20 7:08 PM, Pali Rohár wrote:
>>> Hello! I looked at what is initialized and enabled for sd/emmc slots and
>>> I found out that comphy mmc needs to be enabled if at least one slot is
>>> used (e.g. SD card) and then remaining part is slot initialization in
>>> xenon driver.
>>>
>>> I wrote quick patch to disable slot when unregistering mmc device from
>>> U-Boot and also unregister emmc on A3720 from U-Boot when it is not
>>> present. But I have not tested it yet.
 What do you think about it?
>>
>> Logically, it's possible to disable slot. But i'm not sure because of not 
>> having its board.
>> Just minor question.. Does it support multi slot per one IP?
> 
> A3720 has only one slot with index XENON_MMC_SLOT_ID_HYPERION.
> 
> A3720 has two mmc/sd IPs at two different address spaces, so uSD and
> eMMC do not share config address space.

Thanks for explanation kindly. I asked because didn't see a real case that 
multi slot is supported. 

Best Regards,
Jaehoon Chung

> 
>> Best Regards,
>> Jaehoon Chung
>>
>>>
>>> diff --git a/board/Marvell/mvebu_armada-37xx/board.c 
>>> b/board/Marvell/mvebu_armada-37xx/board.c
>>> index f67b04b78c..1b9e7520cc 100644
>>> --- a/board/Marvell/mvebu_armada-37xx/board.c
>>> +++ b/board/Marvell/mvebu_armada-37xx/board.c
>>> @@ -5,6 +5,7 @@
>>>  
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -84,12 +85,10 @@ int board_init(void)
>>>  #ifdef CONFIG_BOARD_LATE_INIT
>>>  int board_late_init(void)
>>>  {
>>> +   struct udevice *dev;
>>> struct mmc *mmc_dev;
>>> bool ddr4, emmc;
>>>  
>>> -   if (env_get("fdtfile"))
>>> -   return 0;
>>> -
>>> if (!of_machine_is_compatible("globalscale,espressobin"))
>>> return 0;
>>>  
>>> @@ -101,6 +100,16 @@ int board_late_init(void)
>>> mmc_dev = find_mmc_device(1);
>>> emmc = (mmc_dev && mmc_init(mmc_dev) == 0);
>>>  
>>> +   /* if eMMC is not present then remove it from DM */
>>> +   if (!emmc && mmc_dev) {
>>> +   dev = mmc_dev->dev;
>>> +   device_remove(dev, DM_REMOVE_NORMAL);
>>> +   device_unbind(dev);
>>> +   }
>>> +
>>> +   if (env_get("fdtfile"))
>>> +   return 0;
>>> +
>>> if (ddr4 && emmc)
>>> env_set("fdtfile", 
>>> "marvell/armada-3720-espressobin-v7-emmc.dtb");
>>> else if (ddr4)
>>> diff --git a/drivers/mmc/xenon_sdhci.c b/drivers/mmc/xenon_sdhci.c
>>> index 6ce9d00d0a..da9882cbf6 100644
>>> --- a/drivers/mmc/xenon_sdhci.c
>>> +++ b/drivers/mmc/xenon_sdhci.c
>>> @@ -350,6 +350,16 @@ static void xenon_mmc_enable_slot(struct sdhci_host 
>>> *host, u8 slot)
>>> sdhci_writel(host, var, SDHC_SYS_OP_CTRL);
>>>  }
>>>  
>>> +/* Disable specific slot */
>>> +static void xenon_mmc_disable_slot(struct sdhci_host *host, u8 slot)
>>> +{
>>> +   u32 var;
>>> +
>>> +   var = sdhci_readl(host, SDHC_SYS_OP_CTRL);
>>> +   var &= ~(SLOT_MASK(slot) << SLOT_ENABLE_SHIFT);
>>> +   sdhci_writel(host, var, SDHC_SYS_OP_CTRL);
>>> +}
>>> +
>>>  /* Enable Parallel Transfer Mode */
>>>  static void xenon_mmc_enable_parallel_tran(struct sdhci_host *host, u8 
>>> slot)
>>>  {
>>> @@ -515,6 +525,14 @@ static int xenon_sdhci_probe(struct udevice *dev)
>>> return ret;
>>>  }
>>>  
>>> +static int xenon_sdhci_remove(struct udevice *dev)
>>> +{
>>> +   struct sdhci_host *host = dev_get_priv(dev);
>>> +
>>> +   xenon_mmc_disable_slot(host, XENON_MMC_SLOT_ID_HYPERION);
>>> +   return 0;
>>> +}
>>> +
>>>  static int xenon_sdhci_ofdata_to_platdata(struct udevice *dev)
>>>  {
>>> struct sdhci_host *host = dev_get_priv(dev);
>>> @@ -564,6 +582,7 @@ U_BOOT_DRIVER(xenon_sdhci_drv) = {
>>> .ops= &sdhci_ops,
>>> .bind   = xenon_sdhci_bind,
>>> .probe  = xenon_sdhci_probe,
>>> +   .remove = xenon_sdhci_remove,
>>> .priv_auto_alloc_size = sizeof(struct xenon_sdhci_priv),
>>> .platdata_auto_alloc_size = sizeof(struct xenon_sdhci_plat),
>>>  };
>>>
>>>
>>
> 

Re: [PULL] Pull request for u-boot master = u-boot-stm32-20201209

[Tom Rini]

On Wed, Dec 09, 2020 at 04:11:06PM +0100, Patrick DELAUNAY wrote:

> 
> Hi Tom,
> 
> Please pull the STM32 related patches for u-boot/master, v2021.01:
> u-boot-stm32-20201209
> 
> - Manage CONFIG_ENV_EXT4_DEVICE_AND_PART in stm32mp1 board
> - Update ARM STI and ARM STM STM32MP Arch maintainers emails
> - Enable internal pull-ups for SDMMC1 on DHCOM SoM
> 
> CI status:
> https://gitlab.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/5518
> 
> Thanks,
> Patrick
> 
> git request-pull origin/master
> https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git
> u-boot-stm32-20201209
> 
> The following changes since commit ec79f5ce2202cf6c56e5eb1eb755604b534ae08b:
> 
>   Merge https://gitlab.denx.de/u-boot/custodians/u-boot-marvell (2020-12-07
> 11:46:12 -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git
> tags/u-boot-stm32-20201209
> 
> for you to fetch changes up to 9b36b7dc96baedc0ed506246a9822c745cc65b45:
> 
>   ARM: dts: stm32: Add USB OTG ID pin on DH AV96 (2020-12-09 10:57:50 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 1/1] sandbox: implement invalidate_icache_all()

[Heinrich Schuchardt]

Before executing code that we have loaded from a file we need to flush the
data cache and invalidate the instruction flash.

Implement functions flush_cache() and invalidate_icache_all().

Signed-off-by: Heinrich Schuchardt 
---
 arch/sandbox/cpu/Makefile |  2 +-
 arch/sandbox/cpu/cache.c  | 23 +++
 board/sandbox/sandbox.c   |  4 
 3 files changed, 24 insertions(+), 5 deletions(-)
 create mode 100644 arch/sandbox/cpu/cache.c

diff --git a/arch/sandbox/cpu/Makefile b/arch/sandbox/cpu/Makefile
index bac96447d5..de7fe7f391 100644
--- a/arch/sandbox/cpu/Makefile
+++ b/arch/sandbox/cpu/Makefile
@@ -5,7 +5,7 @@
 # (C) Copyright 2000-2003
 # Wolfgang Denk, DENX Software Engineering, w...@denx.de.

-obj-y  := cpu.o state.o
+obj-y  := cache.o cpu.o state.o
 extra-y:= start.o os.o
 extra-$(CONFIG_SANDBOX_SDL)+= sdl.o
 obj-$(CONFIG_SPL_BUILD)+= spl.o
diff --git a/arch/sandbox/cpu/cache.c b/arch/sandbox/cpu/cache.c
new file mode 100644
index 00..46c62c0b44
--- /dev/null
+++ b/arch/sandbox/cpu/cache.c
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020, Heinrich Schuchardt 
+ */
+
+#include 
+#include 
+#include 
+
+void flush_cache(unsigned long addr, unsigned long size)
+{
+   /* Clang uses (char *) parameters, GCC (void *) */
+   __builtin___clear_cache((void *)addr, (void *)(addr + size));
+}
+
+void invalidate_icache_all(void)
+{
+   struct sandbox_state *state = state_get_current();
+
+   /* Clang uses (char *) parameters, GCC (void *) */
+   __builtin___clear_cache((void *)state->ram_buf,
+   (void *)(state->ram_buf + state->ram_size));
+}
diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c
index 18a605de02..3235541a7d 100644
--- a/board/sandbox/sandbox.c
+++ b/board/sandbox/sandbox.c
@@ -28,10 +28,6 @@ U_BOOT_DEVICE(gpio_sandbox) = {
 };
 #endif

-void flush_cache(unsigned long start, unsigned long size)
-{
-}
-
 #ifndef CONFIG_TIMER
 /* system timer offset in ms */
 static unsigned long sandbox_timer_offset;
--
2.29.2

Re: [PATCH 01/27] linker_lists: Fix alignment issue

[Heinrich Schuchardt]

On 12/1/20 4:58 PM, Simon Glass wrote:

Hi Heinrich,

On Mon, 30 Nov 2020 at 15:56, Heinrich Schuchardt  wrote:


On 11/30/20 9:11 PM, Simon Glass wrote:

+Marek Vasut who originally wrote it

Hi Heinrich,

On Sun, 29 Nov 2020 at 23:20, Heinrich Schuchardt  wrote:


Am 30. November 2020 02:53:36 MEZ schrieb Simon Glass :

The linker script uses alphabetic sorting to group the different linker
lists together. Each group has its own struct and potentially its own
alignment. But when the linker packs the structs together it cannot
ensure that a linker list starts on the expected alignment boundary.

For example, if the first list has a struct size of 8 and we place 3 of
them in the image, that means that the next struct will start at offset
0x18 from the start of the linker_list section. If the next struct has
a size of 16 then it will start at an 8-byte aligned offset, but not a
16-byte aligned offset.

With sandbox on x86_64, a reference to a linker list item using
ll_entry_get() can force alignment of that particular linker_list item,
if it is in the same file as the linker_list item is declared.

Consider this example, where struct driver is 0x80 bytes:

ll_entry_declare(struct driver, fred, driver)

...

void *p = ll_entry_get(struct driver, fred, driver)

If these two lines of code are in the same file, then the entry is
forced
to be aligned at the 'struct driver' alignment, which is 16 bytes. If
the
second line of code is in a different file, then no action is taken,
since
the compiler cannot update the alignment of the linker_list item.

In the first case, an 8-byte 'fill' region is added:

.u_boot_list_2_driver_2_testbus_drv
 0x00270018   0x80 test/built-in.o
 0x00270018
_u_boot_list_2_driver_2_testbus_drv
.u_boot_list_2_driver_2_testfdt1_drv
 0x00270098   0x80 test/built-in.o
 0x00270098
_u_boot_list_2_driver_2_testfdt1_drv
*fill* 0x002701180x8
.u_boot_list_2_driver_2_testfdt_drv
 0x00270120   0x80 test/built-in.o
 0x00270120
_u_boot_list_2_driver_2_testfdt_drv
.u_boot_list_2_driver_2_testprobe_drv
 0x002701a0   0x80 test/built-in.o
 0x002701a0
_u_boot_list_2_driver_2_testprobe_drv

With this, the linker_list no-longer works since items after
testfdt1_drv
are not at the expected address.

Ideally we would have a way to tell gcc not to align structs in this
way.
It is not clear how we could do this, and in any case it would require
us
to adjust every struct used by the linker_list feature.

One possible fix is to force each separate linker_list to start on the
largest possible boundary that can be required by the compiler. However
that does not seem to work on x86_64, which uses 16-byte alignment in
this
case but needs 32-byte alignment.

So add a Kconfig option to handle this. Set the default value to 4 so
as to avoid changing platforms that don't need it.

Update the ll_entry_start() accordingly.

Signed-off-by: Simon Glass 
---

arch/Kconfig | 11 +++
doc/api/linker_lists.rst | 62 
include/linker_lists.h   |  3 +-
3 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index 3aa99e08fce..aa8664212f1 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -7,6 +7,17 @@ config HAVE_ARCH_IOREMAP
config NEEDS_MANUAL_RELOC
bool

+config LINKER_LIST_ALIGN
+  int
+  default 32 if SANDBOX


What is so special about the sandbox?


I'm not too sure, actually. Also, 32 seems to be larger than
__BIGGEST_ALIGNMENT__ so it is confusing.


Just evaluate if the host is 64 bit and use 8 or 4 accordingly?


+  default 8 if ARM64 || X86


Shouldn't the default be 8 on all 64 bit platforms? And 4 on all 32 bit 
platforms?


Possibly, but who knows? One way to really get to the bottom of this
is to have a test that checks that the alignment is what it should be.
I spent half a day diagnosing this but not that much time thinking of
the best solution. If you have time to dig into it please let me know.

Regards,
Simon



If you change ll_entry_start() as below, the linker will complain
"lib/efi_driver/efi_uclass.c:309:
undefined reference to `bad_alignment'"

If you change value 4 to 8, it stops complaining for qemu-x86_64_defconfig.

#define ll_alignment(x) \
  (__builtin_offsetof(struct {char a; x b;}, b))
void bad_alignment(void);
#define ll_entry_start(_type, _list) \
({ \
  static char start[0] __aligned(4) __attribute__((unused, \
  section(".u_boot_list_2_"#_list"_1"))); \
  if (ll_alignment(_type) > 4) \
  bad_alignment(); \
  (_type *)&start; \
})

If the alignment is smaller than the limit, the compiler can r

[PATCH] lib/efi_loader: dynamically determine var store size

[Paulo Alcantara]

In order to support (ESP)/ubootefi.var and preseed variables greater
than EFI_VAR_BUF_SIZE (0x4000), dynamically determine the variable
list size that will fit both and the ones that are created at boot
time.

Signed-off-by: Paulo Alcantara (SUSE) 
---
 include/efi_variable.h| 15 +--
 lib/efi_loader/efi_var_file.c | 36 ---
 lib/efi_loader/efi_var_mem.c  | 12 +++-
 lib/efi_loader/efi_variable.c | 35 +++---
 4 files changed, 81 insertions(+), 17 deletions(-)

diff --git a/include/efi_variable.h b/include/efi_variable.h
index 4704a3c16e65..cd40dfe3359d 100644
--- a/include/efi_variable.h
+++ b/include/efi_variable.h
@@ -8,6 +8,8 @@
 
 #include 
 
+extern efi_uintn_t __efi_runtime_data efi_var_buf_size;
+
 #define EFI_VARIABLE_READ_ONLY BIT(31)
 
 enum efi_auth_var_type {
@@ -91,7 +93,7 @@ efi_status_t efi_query_variable_info_int(u32 attributes,
 
 #define EFI_VAR_FILE_NAME "ubootefi.var"
 
-#define EFI_VAR_BUF_SIZE 0x4000
+#define EFI_VAR_DEFAULT_BUF_SIZE 0x4000
 
 /*
  * This constant identifies the file format for storing UEFI variables in
@@ -179,12 +181,21 @@ efi_status_t efi_var_restore(struct efi_var_file *buf);
  */
 efi_status_t efi_var_from_file(void);
 
+/**
+ * efi_var_file_size() - determine variable file size
+ *
+ * @fsize: variable file size
+ * Return: status code
+ */
+efi_status_t __maybe_unused efi_var_file_size(efi_uintn_t *fsize);
+
 /**
  * efi_var_mem_init() - set-up variable list
  *
+ * @mem_size:  variable list size
  * Return: status code
  */
-efi_status_t efi_var_mem_init(void);
+efi_status_t efi_var_mem_init(efi_uintn_t mem_size);
 
 /**
  * efi_var_mem_find() - find a variable in the list
diff --git a/lib/efi_loader/efi_var_file.c b/lib/efi_loader/efi_var_file.c
index b171d2d1a8f7..42c674241ef4 100644
--- a/lib/efi_loader/efi_var_file.c
+++ b/lib/efi_loader/efi_var_file.c
@@ -49,7 +49,7 @@ static efi_status_t __maybe_unused 
efi_set_blk_dev_to_system_partition(void)
 efi_status_t __maybe_unused efi_var_collect(struct efi_var_file **bufp, loff_t 
*lenp,
u32 check_attr_mask)
 {
-   size_t len = EFI_VAR_BUF_SIZE;
+   size_t len = efi_var_buf_size;
struct efi_var_file *buf;
struct efi_var_entry *var, *old_var;
size_t old_var_name_length = 2;
@@ -193,12 +193,17 @@ efi_status_t efi_var_restore(struct efi_var_file *buf)
 efi_status_t efi_var_from_file(void)
 {
 #ifdef CONFIG_EFI_VARIABLE_FILE_STORE
-   struct efi_var_file *buf;
+   struct efi_var_file *buf = NULL;
+   efi_uintn_t fsize;
loff_t len;
efi_status_t ret;
int r;
 
-   buf = calloc(1, EFI_VAR_BUF_SIZE);
+   ret = efi_var_file_size(&fsize);
+   if (ret != EFI_SUCCESS)
+   goto error;
+
+   buf = calloc(1, fsize);
if (!buf) {
log_err("Out of memory\n");
return EFI_OUT_OF_RESOURCES;
@@ -206,10 +211,10 @@ efi_status_t efi_var_from_file(void)
 
ret = efi_set_blk_dev_to_system_partition();
if (ret != EFI_SUCCESS)
-   goto error;
-   r = fs_read(EFI_VAR_FILE_NAME, map_to_sysmem(buf), 0, EFI_VAR_BUF_SIZE,
-   &len);
-   if (r || len < sizeof(struct efi_var_file)) {
+   return ret;
+
+   r = fs_read(EFI_VAR_FILE_NAME, map_to_sysmem(buf), 0, fsize, &len);
+   if (r || len != fsize) {
log_err("Failed to load EFI variables\n");
goto error;
}
@@ -220,3 +225,20 @@ error:
 #endif
return EFI_SUCCESS;
 }
+
+efi_status_t __maybe_unused efi_var_file_size(efi_uintn_t *fsize)
+{
+   efi_status_t ret;
+   loff_t size;
+   int r;
+
+   ret = efi_set_blk_dev_to_system_partition();
+   if (ret != EFI_SUCCESS)
+   return ret;
+
+   r = fs_size(EFI_VAR_FILE_NAME, &size);
+   if (r)
+   size = 0;
+   *fsize = size;
+   return EFI_SUCCESS;
+}
diff --git a/lib/efi_loader/efi_var_mem.c b/lib/efi_loader/efi_var_mem.c
index d155f25f60e6..323c3b71ace0 100644
--- a/lib/efi_loader/efi_var_mem.c
+++ b/lib/efi_loader/efi_var_mem.c
@@ -11,6 +11,7 @@
 #include 
 
 struct efi_var_file __efi_runtime_data *efi_var_buf;
+efi_uintn_t __efi_runtime_data efi_var_buf_size;
 static struct efi_var_entry __efi_runtime_data *efi_current_var;
 
 /**
@@ -146,7 +147,7 @@ efi_status_t __efi_runtime efi_var_mem_ins(
data = var->name + var_name_len;
 
if ((uintptr_t)data - (uintptr_t)efi_var_buf + size1 + size2 >
-   EFI_VAR_BUF_SIZE)
+   efi_var_buf_size)
return EFI_OUT_OF_RESOURCES;
 
var->attr = attributes;
@@ -171,7 +172,7 @@ efi_status_t __efi_runtime efi_var_mem_ins(
 
 u64 __efi_runtime efi_var_mem_free(void)
 {
-   return EFI_VAR_BUF_SIZE - efi_var_buf->length -
+   return efi_var_buf_size - efi_var_buf->length -
   sizeof(struct efi_var_entry);
 }

Re: [PATCH] usb: dwc2: add "u-boot,force-vbus-detection" for stm32

[Marek Vasut]

On 12/9/20 6:04 PM, Patrick DELAUNAY wrote:

Hi,

[...]


I add a new property to be backward compatible (even it the
combinaison is less clear) I protect regulator function call to
avoid compilation

issue for other platform.

PS: after reading the refmanual, I also split VALOEN and VALOVAL bit
update

as it is required.
So yes I think it is needed but I can split the patch to simplify 
the review.

I presume you don't feel like implementing proper OTG support, right ?

Yes, I am afraid of this task.

Can you take a look ?

I will pick this patch into next for now.


I check this topic, I think I don't need to support OTG in dwc2

but I need to support USB port and connector as it is done in linux kernel.

and I think that I can propose a plan (6 month-1 year)

- Add a new u-class for USB connector based on 
linux/drivers/usb/typec/class.c


     => Allow to detect cable connection and USB mode (device / host)

- Add a new driver for USB type C connector (compatible "usb-c-connector")

- Migrate stusb1600 driver to use this new driver

- Update driver (dwc2 or usbphyc or directly in uclass ?) to use 
connector when present in device tree 
(devicetree/bindings/connector/usb-connector.yaml)


With these modifcations, I hope to have the same hooks than Linux.


And for future

- Add a USB typeC connector driver based on UCSI 
(linux/drivers/usb/typec/ucsi)


https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/usb-type-c-ucsi-spec.pdf 



- Adapt other driver to use USB connector. (as DWC3 for example to 
manage dual role with type-c)


Sounds good, thanks :)

Re: [PATCH] usb: dwc2: add "u-boot,force-vbus-detection" for stm32

[Patrick DELAUNAY]

Hi Marek,

On 12/9/20 5:22 PM, Patrick DELAUNAY wrote:

-Original Message-
From: Marek Vasut 
Sent: mardi 20 octobre 2020 12:21

On 10/16/20 6:32 PM, Patrick DELAUNAY wrote:

Hi Marek,

Hi,

[...]


On 10/15/20 2:49 PM, Patrick Delaunay wrote:

On some board, the ID pin is not connected so the B session must
be overridden with "u-boot,force_b_session_valid" but the VBus
sensing must continue to be handle.

To managed it, this patch adds a new DT field
"u-boot,force-vbus-detection" to use with "u-boot,force_b_session_valid"

How is this solved in Linux ?

It is managed by Linux DWC2 driver: it is a real OTG driver, with
dual mode support and by usb framework

Throught the properties
&usbotg_hs {
usb-role-switch;
};

a glue treat the session and the sensing management see
linux/drivers/usb/dwc2/drd.c in linux-next

PS: activate_stm_id_vb_detection is also used in driver = hsotg->params.

As ID pin / vbus is completly managed by the USB TYPE driver C
(STUSB1600 for STMicroelectronics board) and DWC2 driver with dual
role stack (host/gadget).

I don't found a better solution than device tree property for this
task in U-Boot as DWC2 driver don't support dual role and U-Boot
don't have

framework for USB type C controller.

btw can you do something about that huge change in indent ? Is it necessary ?

I move all this code under activate_stm_id_vb_detection (linked to
compatible "st,stm32mp1-hsotg") to avoid impact on other platform as
this "sensing" properties are only support for STM32MP15X (it is
linked to USB block detection integrated in SOC)

And after I need to check the
1/ The usb33d-supply is required of vbus or IDPIN sensing 2/ manage
Vbus sensing or override (according dt) 3/ manage IDPIN or override
(according dt)

I add a new property to be backward compatible (even it the
combinaison is less clear) I protect regulator function call to
avoid compilation

issue for other platform.

PS: after reading the refmanual, I also split VALOEN and VALOVAL bit
update

as it is required.

So yes I think it is needed but I can split the patch to simplify the review.

I presume you don't feel like implementing proper OTG support, right ?

Yes, I am afraid of this task.

Can you take a look ?

I will pick this patch into next for now.


I check this topic, I think I don't need to support OTG in dwc2

but I need to support USB port and connector as it is done in linux kernel.

and I think that I can propose a plan (6 month-1 year)

- Add a new u-class for USB connector based on 
linux/drivers/usb/typec/class.c


    => Allow to detect cable connection and USB mode (device / host)

- Add a new driver for USB type C connector (compatible "usb-c-connector")

- Migrate stusb1600 driver to use this new driver

- Update driver (dwc2 or usbphyc or directly in uclass ?) to use 
connector when present in device tree 
(devicetree/bindings/connector/usb-connector.yaml)


With these modifcations, I hope to have the same hooks than Linux.


And for future

- Add a USB typeC connector driver based on UCSI 
(linux/drivers/usb/typec/ucsi)


https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/usb-type-c-ucsi-spec.pdf

- Adapt other driver to use USB connector. (as DWC3 for example to 
manage dual role with type-c)


Patrick

Re: [PATCH 4/8] dm: Introduce xxx_get_dma_range()

[Nicolas Saenz Julienne]

On Wed, 2020-12-09 at 17:30 +0100, Nicolas Saenz Julienne wrote:
> On Wed, 2020-12-09 at 13:58 +0100, Matthias Brugger wrote:
> [...]
> > > +
> > > + /* switch to that node */
> > > + parent = of_get_parent(dev);
> > > + if (!parent) {
> > > + printf("Found dma-ranges in root node, shoudln't happen\n");
> > > + ret = -EINVAL;
> > > + goto out;
> > > + }
> > 
> > Aren't we missing a of_node_put(parent) here?
> 
> Yes, that's right.

Actually I now see why I didn't do it, as there is no need:

/* Dummy functions to mirror Linux. These are not used in U-Boot */
#define of_node_get(x) (x)
static inline void of_node_put(const struct device_node *np) { }

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

Re: [PATCH 00/27] dm: Change the way sequence numbers are implemented

[Michael Walle]

Hi Simon,

Am 2020-12-09 17:23, schrieb Simon Glass:

On Tue, 8 Dec 2020 at 15:52, Michael Walle  wrote:

Am 2020-11-30 02:53, schrieb Simon Glass:
> At present each device has two sequence numbers, with 'req_seq' being
> set up at bind time and 'seq' at probe time. The idea is that devices
> can 'request' a sequence number and then the conflicts are resolved
> when
> the device is probed.
>
> This makes things complicated in a few cases, since we don't really
> know
> (at bind time) what the sequence number will end up being. We want to
> honour the bind-time requests if at all possible, but in fact the only
> source of these at present is the devicetree aliases.
>
> Apart from the obvious need for sequence numbers to supports U-Boot's
> numbering on devices on the command line, the current scheme was
> designed to:
>
> - avoid calculating the sequence number until it is needed, to save
>   execution time
> - allow multiple devices to obtain a particular sequence number as they
>   are probed and removed
> - retain a record of the 'requested' sequence number even if it turns
> out
>   that a device could not get it (to allow debugging and retrying)
>
> After some years using the current scheme it seems on balance that
> these
> goals don't have as much merit as first thought. The first point would
> be persuasive except that we end up reading the devicetree aliases at
> bind-time anyway. So the work of resolving the sequence numbers during
> probing is not that great. The second point hasn't really been an
> issue,
> as there is typically no contention for sequence numbers (boards tend
> to
> allocate them statically in the devicetree). Re the third point, we can
> often figure out what was requested by looking at aliases, and in the
> cases where we can't, it doesn't seem to matter much.
>
> Since we have the devicetree available at bind time, we may as well
> just
> use it, in the hope that the required processing will turn out to be
> useful later (i.e. the device actually gets used). In addition, it is
> simpler to use a single sequence number, since it avoids confusion and
> some extra code.
>
> This series moves U-Boot to use a single, bind-time sequence number.
> All
> uclasses with the DM_UC_FLAG_SEQ_ALIAS flag enabled will assign
> sequence
> numbers to their devices, so that as soon as a device is bound, it has
> a
> sequence number. If a devicetree alias provides the number, it will be
> used. Otherwise, during initial binding, the first free number is used.

What does "first free number mean"?

I have a device tree with the following aliases for network:

aliases {
 ethernet0 = &enetc0;
 ethernet1 = &enetc1;
 ethernet2 = &enetc2;
 ethernet3 = &enetc6;
};

The individual devices might be disabled, depending on the board 
variant

(which might also be dynamically determined during startup).


By disabled, do you mean that they are marked 'status = "disabled"'?


yes


If so, then they are ignored by DM and will not claim their number.



My first smoke test with this series show the following:

   uclass 32: eth
   0   * enetc-0 @ ffd40e60, seq 0
   1   * ax88179_eth @ ffd51f50, seq 1

Looks like the usb ethernet device will get seq 1 assigned (after "usb
start"). Is this intended?

If so, this is a problem, because for ethernet devices, the MAC 
address

is assigned according to the ethNaddr variable. And at least for this
board (kontron_sl28) the first four are reserved for the ones with the
alias entries. Thus I'd have expected that the usb device will get seq 
4

assigned.


OK, so you mean after all existing aliases, even if they did not bind.
I think we can do that.


Great, that will also match the current behavior. See
be1a6e94254af205bd67d69e3bdb26b161ccd72f ("dm: uclass: don't assign 
aliased seq numbers")


-michael

Re: [PATCH 00/27] dm: Change the way sequence numbers are implemented

[Simon Glass]

Hi Tom,

On Wed, 9 Dec 2020 at 09:19, Tom Rini  wrote:
>
> On Tue, Dec 08, 2020 at 11:52:07PM +0100, Michael Walle wrote:
> > Hi Simon,
> >
> > Am 2020-11-30 02:53, schrieb Simon Glass:
> > > At present each device has two sequence numbers, with 'req_seq' being
> > > set up at bind time and 'seq' at probe time. The idea is that devices
> > > can 'request' a sequence number and then the conflicts are resolved when
> > > the device is probed.
> > >
> > > This makes things complicated in a few cases, since we don't really know
> > > (at bind time) what the sequence number will end up being. We want to
> > > honour the bind-time requests if at all possible, but in fact the only
> > > source of these at present is the devicetree aliases.
> > >
> > > Apart from the obvious need for sequence numbers to supports U-Boot's
> > > numbering on devices on the command line, the current scheme was
> > > designed to:
> > >
> > > - avoid calculating the sequence number until it is needed, to save
> > >   execution time
> > > - allow multiple devices to obtain a particular sequence number as they
> > >   are probed and removed
> > > - retain a record of the 'requested' sequence number even if it turns
> > > out
> > >   that a device could not get it (to allow debugging and retrying)
> > >
> > > After some years using the current scheme it seems on balance that these
> > > goals don't have as much merit as first thought. The first point would
> > > be persuasive except that we end up reading the devicetree aliases at
> > > bind-time anyway. So the work of resolving the sequence numbers during
> > > probing is not that great. The second point hasn't really been an issue,
> > > as there is typically no contention for sequence numbers (boards tend to
> > > allocate them statically in the devicetree). Re the third point, we can
> > > often figure out what was requested by looking at aliases, and in the
> > > cases where we can't, it doesn't seem to matter much.
> > >
> > > Since we have the devicetree available at bind time, we may as well just
> > > use it, in the hope that the required processing will turn out to be
> > > useful later (i.e. the device actually gets used). In addition, it is
> > > simpler to use a single sequence number, since it avoids confusion and
> > > some extra code.
> > >
> > > This series moves U-Boot to use a single, bind-time sequence number. All
> > > uclasses with the DM_UC_FLAG_SEQ_ALIAS flag enabled will assign sequence
> > > numbers to their devices, so that as soon as a device is bound, it has a
> > > sequence number. If a devicetree alias provides the number, it will be
> > > used. Otherwise, during initial binding, the first free number is used.
> >
> > What does "first free number mean"?
> >
> > I have a device tree with the following aliases for network:
> >
> > aliases {
> > ethernet0 = &enetc0;
> > ethernet1 = &enetc1;
> > ethernet2 = &enetc2;
> > ethernet3 = &enetc6;
> > };
> >
> > The individual devices might be disabled, depending on the board variant
> > (which might also be dynamically determined during startup).
> >
> > My first smoke test with this series show the following:
> >
> >   uclass 32: eth
> >   0   * enetc-0 @ ffd40e60, seq 0
> >   1   * ax88179_eth @ ffd51f50, seq 1
> >
> > Looks like the usb ethernet device will get seq 1 assigned (after "usb
> > start"). Is this intended?
> >
> > If so, this is a problem, because for ethernet devices, the MAC address
> > is assigned according to the ethNaddr variable. And at least for this
> > board (kontron_sl28) the first four are reserved for the ones with the
> > alias entries. Thus I'd have expected that the usb device will get seq 4
> > assigned.
>
> I want to echo this concern.  One of the things that can be challenging
> when working with devices in Linux is that it's now long accepted that
> you can't rely on anything like probe order as that can and will change
> randomly (seemingly).  You have to instead rely on some stable attribute
> of the device.  Consistency of device numbering is a feature for us.

This is still using aliases for devices that have them. But for
dynamically allocated devices (without aliases) we always rely on what
is next available. I think I can change the algorithm to look for the
number after all existing aliases.

Regards,
Simon

Re: [PATCH 00/27] dm: Change the way sequence numbers are implemented

[Simon Glass]

Hi Michael,

On Tue, 8 Dec 2020 at 15:52, Michael Walle  wrote:
>
> Hi Simon,
>
> Am 2020-11-30 02:53, schrieb Simon Glass:
> > At present each device has two sequence numbers, with 'req_seq' being
> > set up at bind time and 'seq' at probe time. The idea is that devices
> > can 'request' a sequence number and then the conflicts are resolved
> > when
> > the device is probed.
> >
> > This makes things complicated in a few cases, since we don't really
> > know
> > (at bind time) what the sequence number will end up being. We want to
> > honour the bind-time requests if at all possible, but in fact the only
> > source of these at present is the devicetree aliases.
> >
> > Apart from the obvious need for sequence numbers to supports U-Boot's
> > numbering on devices on the command line, the current scheme was
> > designed to:
> >
> > - avoid calculating the sequence number until it is needed, to save
> >   execution time
> > - allow multiple devices to obtain a particular sequence number as they
> >   are probed and removed
> > - retain a record of the 'requested' sequence number even if it turns
> > out
> >   that a device could not get it (to allow debugging and retrying)
> >
> > After some years using the current scheme it seems on balance that
> > these
> > goals don't have as much merit as first thought. The first point would
> > be persuasive except that we end up reading the devicetree aliases at
> > bind-time anyway. So the work of resolving the sequence numbers during
> > probing is not that great. The second point hasn't really been an
> > issue,
> > as there is typically no contention for sequence numbers (boards tend
> > to
> > allocate them statically in the devicetree). Re the third point, we can
> > often figure out what was requested by looking at aliases, and in the
> > cases where we can't, it doesn't seem to matter much.
> >
> > Since we have the devicetree available at bind time, we may as well
> > just
> > use it, in the hope that the required processing will turn out to be
> > useful later (i.e. the device actually gets used). In addition, it is
> > simpler to use a single sequence number, since it avoids confusion and
> > some extra code.
> >
> > This series moves U-Boot to use a single, bind-time sequence number.
> > All
> > uclasses with the DM_UC_FLAG_SEQ_ALIAS flag enabled will assign
> > sequence
> > numbers to their devices, so that as soon as a device is bound, it has
> > a
> > sequence number. If a devicetree alias provides the number, it will be
> > used. Otherwise, during initial binding, the first free number is used.
>
> What does "first free number mean"?
>
> I have a device tree with the following aliases for network:
>
> aliases {
>  ethernet0 = &enetc0;
>  ethernet1 = &enetc1;
>  ethernet2 = &enetc2;
>  ethernet3 = &enetc6;
> };
>
> The individual devices might be disabled, depending on the board variant
> (which might also be dynamically determined during startup).

By disabled, do you mean that they are marked 'status = "disabled"'?
If so, then they are ignored by DM and will not claim their number.

>
> My first smoke test with this series show the following:
>
>uclass 32: eth
>0   * enetc-0 @ ffd40e60, seq 0
>1   * ax88179_eth @ ffd51f50, seq 1
>
> Looks like the usb ethernet device will get seq 1 assigned (after "usb
> start"). Is this intended?
>
> If so, this is a problem, because for ethernet devices, the MAC address
> is assigned according to the ethNaddr variable. And at least for this
> board (kontron_sl28) the first four are reserved for the ones with the
> alias entries. Thus I'd have expected that the usb device will get seq 4
> assigned.

OK, so you mean after all existing aliases, even if they did not bind.
I think we can do that.

Regards,
Simon

Re: [PATCH 00/27] dm: Change the way sequence numbers are implemented

[Tom Rini]

On Tue, Dec 08, 2020 at 11:52:07PM +0100, Michael Walle wrote:
> Hi Simon,
> 
> Am 2020-11-30 02:53, schrieb Simon Glass:
> > At present each device has two sequence numbers, with 'req_seq' being
> > set up at bind time and 'seq' at probe time. The idea is that devices
> > can 'request' a sequence number and then the conflicts are resolved when
> > the device is probed.
> > 
> > This makes things complicated in a few cases, since we don't really know
> > (at bind time) what the sequence number will end up being. We want to
> > honour the bind-time requests if at all possible, but in fact the only
> > source of these at present is the devicetree aliases.
> > 
> > Apart from the obvious need for sequence numbers to supports U-Boot's
> > numbering on devices on the command line, the current scheme was
> > designed to:
> > 
> > - avoid calculating the sequence number until it is needed, to save
> >   execution time
> > - allow multiple devices to obtain a particular sequence number as they
> >   are probed and removed
> > - retain a record of the 'requested' sequence number even if it turns
> > out
> >   that a device could not get it (to allow debugging and retrying)
> > 
> > After some years using the current scheme it seems on balance that these
> > goals don't have as much merit as first thought. The first point would
> > be persuasive except that we end up reading the devicetree aliases at
> > bind-time anyway. So the work of resolving the sequence numbers during
> > probing is not that great. The second point hasn't really been an issue,
> > as there is typically no contention for sequence numbers (boards tend to
> > allocate them statically in the devicetree). Re the third point, we can
> > often figure out what was requested by looking at aliases, and in the
> > cases where we can't, it doesn't seem to matter much.
> > 
> > Since we have the devicetree available at bind time, we may as well just
> > use it, in the hope that the required processing will turn out to be
> > useful later (i.e. the device actually gets used). In addition, it is
> > simpler to use a single sequence number, since it avoids confusion and
> > some extra code.
> > 
> > This series moves U-Boot to use a single, bind-time sequence number. All
> > uclasses with the DM_UC_FLAG_SEQ_ALIAS flag enabled will assign sequence
> > numbers to their devices, so that as soon as a device is bound, it has a
> > sequence number. If a devicetree alias provides the number, it will be
> > used. Otherwise, during initial binding, the first free number is used.
> 
> What does "first free number mean"?
> 
> I have a device tree with the following aliases for network:
> 
> aliases {
> ethernet0 = &enetc0;
> ethernet1 = &enetc1;
> ethernet2 = &enetc2;
> ethernet3 = &enetc6;
> };
> 
> The individual devices might be disabled, depending on the board variant
> (which might also be dynamically determined during startup).
> 
> My first smoke test with this series show the following:
> 
>   uclass 32: eth
>   0   * enetc-0 @ ffd40e60, seq 0
>   1   * ax88179_eth @ ffd51f50, seq 1
> 
> Looks like the usb ethernet device will get seq 1 assigned (after "usb
> start"). Is this intended?
> 
> If so, this is a problem, because for ethernet devices, the MAC address
> is assigned according to the ethNaddr variable. And at least for this
> board (kontron_sl28) the first four are reserved for the ones with the
> alias entries. Thus I'd have expected that the usb device will get seq 4
> assigned.

I want to echo this concern.  One of the things that can be challenging
when working with devices in Linux is that it's now long accepted that
you can't rely on anything like probe order as that can and will change
randomly (seemingly).  You have to instead rely on some stable attribute
of the device.  Consistency of device numbering is a feature for us.

-- 
Tom


signature.asc
Description: PGP signature

Re: [GIT PULL] Pull request: u-boot-imx u-boot-imx-20201208

[Tom Rini]

On Tue, Dec 08, 2020 at 09:11:16AM +0100, Stefano Babic wrote:

> Hi Tom,
> 
> please pull from u-boot-imx, thanks !
> 
> Travis: https://travis-ci.org/github/sbabic/u-boot-imx/builds/748076494
> 
> The following changes since commit ee1e04558ff8c8ed812b986939447f129bb0b0bb:
> 
>   Merge branch '2020-12-02-master-imports' (2020-12-03 09:43:47 -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git
> 
> for you to fetch changes up to 8c5ea5361c1728c162dd5ce796654c5aef77420e:
> 
>   configs: migrate CONFIG_IMX_THERMAL to defconfigs (2020-12-07 08:54:29
> +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 4/8] dm: Introduce xxx_get_dma_range()

[Nicolas Saenz Julienne]

On Wed, 2020-12-09 at 13:58 +0100, Matthias Brugger wrote:
[...]
> > +
> > +   /* switch to that node */
> > +   parent = of_get_parent(dev);
> > +   if (!parent) {
> > +   printf("Found dma-ranges in root node, shoudln't happen\n");
> > +   ret = -EINVAL;
> > +   goto out;
> > +   }
> 
> Aren't we missing a of_node_put(parent) here?

Yes, that's right.

> > +
> > +   /* Get the address sizes both for the bus and its parent */
> > +   of_match_bus(dev)->count_cells(dev, &na, &ns);
> 
> of_bus = of_match_bus(dev);
> of_bus->count_cells(...)

OK

[...]

> > diff --git a/drivers/core/read.c b/drivers/core/read.c
> > index 076125824c..b835e82be9 100644
> > --- a/drivers/core/read.c
> > +++ b/drivers/core/read.c
> > @@ -338,6 +338,11 @@ u64 dev_translate_dma_address(const struct udevice 
> > *dev, const fdt32_t *in_addr)
> >     return ofnode_translate_dma_address(dev_ofnode(dev), in_addr);
> >  }
> >  
> > 
> > +u64 dev_translate_cpu_address(const struct udevice *dev, const fdt32_t 
> > *in_addr)
> > +{
> > +   return ofnode_translate_cpu_address(dev_ofnode(dev), in_addr);
> > +}
> > +
> 
> Dead code, please delete.

Yes, sorry for that.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

Re: Facing issues in travis build due to migration to travis-ci.com

[Tom Rini]

On Wed, Dec 09, 2020 at 07:00:13AM +, Priyanka Jain wrote:

> Hello,
> 
> 
> I have been using travis-ci.org for build test  
> "https://travis-ci.org/github/p-priyanka-jain/u-boot/builds"; .
> Last month, I faced issue in syncing the git and got message regarding 
> migration to travis-ci.com for open-source projects as well.
> https://blog.travis-ci.com/oss-announcement
> 
> I then used travis-ci.com for build for my last pull-request.
> Now its saying that free credits in travis-ci.com are exhausted.
> 
> Can anyone please guide me which site to use for travis build and how to get 
> credit points to build open source projects.

I thought you were supposed to be able to continue to use / get
unlimited minutes for FOSS projects.  That said, I've been seeing builds
take days to run / complete and I'm wondering if we shouldn't just drop
Travis-CI support and make it clearer how to get Azure jobs run, both if
you create a free account and if you just want to leverage the public
option we have today (that only requires GitHub, which you also need for
Travis).

-- 
Tom


signature.asc
Description: PGP signature

[RFC PATCH v1 1/1] mmc: fix response timeout after switch command

[Stefan Bosch]

After issuing the switch command: Wait until 'current state' of the card
status becomes 'tran'. This prevents from response timeout at the next
command because of 'current state' = 'data'.

Signed-off-by: Stefan Bosch 
---

 drivers/mmc/mmc.c | 3 ++-
 include/mmc.h | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index a47700e313..8ccd2058a9 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -823,7 +823,8 @@ static int __mmc_switch(struct mmc *mmc, u8 set, u8 index, 
u8 value,
 value);
return -EIO;
}
-   if (!ret && (status & MMC_STATUS_RDY_FOR_DATA))
+   if (!ret && (status & MMC_STATUS_RDY_FOR_DATA) &&
+   (status & MMC_STATUS_CURR_STATE) == MMC_STATE_TRANS)
return 0;
udelay(100);
} while (get_timer(start) < timeout_ms);
diff --git a/include/mmc.h b/include/mmc.h
index 1d377e0281..18402494c6 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -178,6 +178,7 @@ static inline bool mmc_is_tuning_cmd(uint cmdidx)
 #define MMC_STATUS_ERROR   (1 << 19)
 
 #define MMC_STATE_PRG  (7 << 9)
+#define MMC_STATE_TRANS(4 << 9)
 
 #define MMC_VDD_165_1950x0080  /* VDD voltage 1.65 - 
1.95 */
 #define MMC_VDD_20_21  0x0100  /* VDD voltage 2.0 ~ 2.1 */
-- 
2.17.1

[RFC PATCH v1 0/1] mmc: fix response timeout after switch command

[Stefan Bosch]

Currently I am implementing SPL for frienlyARM's NanoPC-T2 board (SoC
S5P4418). Loading of U-Boot from SD-card fails if CONFIG_SPL_MMC_TINY=y.
I.e. mmc_set_blocklen() inside mmc_bread() fails (Response Timeout),
caused by the previous call of __mmc_switch() in drivers/mmc/mmc.c:
Here the 'current state' of the card status keeps 'data' for several
100ms after issuing the switch command. Because of this state the next
command issued fails (in this case CMD16 = SET_BLOCKLEN). Patch: Wait
for 'current state' = 'tran' in __mmc_switch().


Stefan Bosch (1):
  mmc: fix response timeout after switch command

 drivers/mmc/mmc.c | 3 ++-
 include/mmc.h | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

-- 
2.17.1

[PULL] Pull request for u-boot master = u-boot-stm32-20201209

[Patrick DELAUNAY]

Hi Tom,

Please pull the STM32 related patches for u-boot/master, v2021.01: 
u-boot-stm32-20201209


- Manage CONFIG_ENV_EXT4_DEVICE_AND_PART in stm32mp1 board
- Update ARM STI and ARM STM STM32MP Arch maintainers emails
- Enable internal pull-ups for SDMMC1 on DHCOM SoM

CI status: 
https://gitlab.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/5518


Thanks,
Patrick

git request-pull origin/master 
https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git 
u-boot-stm32-20201209


The following changes since commit ec79f5ce2202cf6c56e5eb1eb755604b534ae08b:

  Merge https://gitlab.denx.de/u-boot/custodians/u-boot-marvell 
(2020-12-07 11:46:12 -0500)


are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git 
tags/u-boot-stm32-20201209


for you to fetch changes up to 9b36b7dc96baedc0ed506246a9822c745cc65b45:

  ARM: dts: stm32: Add USB OTG ID pin on DH AV96 (2020-12-09 10:57:50 
+0100)



- Manage CONFIG_ENV_EXT4_DEVICE_AND_PART in stm32mp1 board
- Update ARM STI and ARM STM STM32MP Arch maintainers emails
- Enable internal pull-ups for SDMMC1 on DHCOM SoM


Manuel Reis (1):
  add check for ignored CONFIG_ENV_EXT4_DEVICE_AND_PART definition

Marek Vasut (4):
  ARM: dts: stm32: Enable internal pull-ups for SDMMC1 on DHCOM SoM
  ARM: dts: stm32: Disable SDMMC1 CKIN feedback clock
  ARM: dts: stm32: Enable SDMMC3 on DH DRC02
  ARM: dts: stm32: Add USB OTG ID pin on DH AV96

Patrice Chotard (3):
  MAINTAINERS: Update ARM STI and ARM STM STM32MP Arch maintainers 
emails

  treewide: Update email address Patrick Delaunay and Patrice Chotard
  .mailmap: map Patrick Delaunay and my email address

 .mailmap |  2 ++
 MAINTAINERS  |  6 +++---
 arch/arm/dts/stm32mp15xx-dhcom-drc02.dts | 13 +++--
 arch/arm/dts/stm32mp15xx-dhcom.dtsi  | 15 ++-
 arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts |  3 ++-
 arch/arm/include/asm/arch-stih410/sdhci.h    |  2 +-
 arch/arm/include/asm/arch-stih410/sys_proto.h    |  2 +-
 arch/arm/include/asm/arch-stm32/stm32f.h |  2 +-
 arch/arm/include/asm/arch-stm32f4/stm32_pwr.h    |  2 +-
 arch/arm/include/asm/arch-stm32f7/stm32_pwr.h    |  2 +-
 arch/arm/include/asm/arch-stm32h7/gpio.h |  2 +-
 arch/arm/include/asm/arch-stm32h7/stm32.h    |  2 +-
 arch/arm/mach-stm32/soc.c    |  2 +-
 board/st/stih410-b2260/board.c   |  2 +-
 board/st/stm32f429-evaluation/stm32f429-evaluation.c |  2 +-
 board/st/stm32f469-discovery/stm32f469-discovery.c   |  2 +-
 board/st/stm32h743-disco/stm32h743-disco.c   |  2 +-
 board/st/stm32h743-eval/stm32h743-eval.c |  2 +-
 board/st/stm32mp1/stm32mp1.c | 11 +++
 drivers/clk/clk_stm32h7.c    |  2 +-
 drivers/misc/stm32_rcc.c |  2 +-
 drivers/mmc/sti_sdhci.c  |  2 +-
 drivers/mmc/stm32_sdmmc2.c   |  2 +-
 drivers/phy/sti_usb_phy.c    |  2 +-
 drivers/pinctrl/pinctrl-sti.c    |  2 +-
 drivers/reset/sti-reset.c    |  2 +-
 drivers/reset/stm32-reset.c  |  2 +-
 drivers/serial/serial_sti_asc.c  |  2 +-
 drivers/sysreset/sysreset_sti.c  |  2 +-
 drivers/timer/sti-timer.c    |  2 +-
 drivers/timer/stm32_timer.c  |  2 +-
 drivers/usb/host/dwc3-sti-glue.c |  2 +-
 drivers/video/backlight_gpio.c   |  2 +-
 include/configs/stih410-b2260.h  |  2 +-
 include/configs/stm32f429-evaluation.h   |  2 +-
 include/configs/stm32f469-discovery.h    |  2 +-
 include/configs/stm32h743-disco.h    |  2 +-
 include/configs/stm32h743-eval.h |  2 +-
 include/dwc3-sti-glue.h  |  2 +-
 include/stm32_rcc.h  |  2 +-

Re: ARM: mvebu: enable SPI for helios4 and sata and uart images for clearfog

[Dennis Gilmore]

On Wed, Dec 9, 2020 at 7:57 AM Stefan Roese  wrote:
>
> Hi Dennis,
>
> On 09.12.20 04:07, dgilm...@redhat.com wrote:
> > In an effort to build SPI images for clearfog and helios4 I needed to make 
> > some
> > minor changes to the dts and Kconfig for the helios4 and set some variables 
> > for
> > UART and SATA images for ClearFog.
> >
> > Version 2 dropped changes for db-mv784mp-gp as the board turns out to be 
> > currently
> > broken, the serial port is not available and the system bails after loading 
> > the SPL
> > the dts changes for the helios4 have been shrunk back to remove everything 
> > not
> > needed or valid
>
> Could you please test this small patch on the db-mv784mp-gp and report
> back, if this works:
>
> diff --git a/arch/arm/dts/armada-xp-gp.dts b/arch/arm/dts/armada-xp-gp.dts
> index 1139e9469a..57aa58 100644
> --- a/arch/arm/dts/armada-xp-gp.dts
> +++ b/arch/arm/dts/armada-xp-gp.dts
> @@ -93,6 +93,7 @@
>  internal-regs {
>  serial@12000 {
>  status = "okay";
> +   u-boot,dm-pre-reloc;

with this dts change the serial port is registered correctly

Dennis
>  };
>  serial@12100 {
>  status = "okay";
>
>
> Thanks,
> Stefan
>


-- 
Dennis Gilmore
Multiple Architecture Portfolio Enablement
T: +1-312-660-3523

Re: [PATCH] ARM: dts: stm32: Consistently enable internal pull-ups for SD bus

[Marek Vasut]

On 12/9/20 11:22 AM, Patrick DELAUNAY wrote:

Hi,

[...]


@@ -1340,13 +1340,13 @@
   ; /* SDMMC2_CMD */
  slew-rate = <1>;
  drive-push-pull;
-    bias-disable;
+    bias-pull-up;
  };
  pins2 {
  pinmux = ; /* SDMMC2_CK */
  slew-rate = <2>;
  drive-push-pull;
-    bias-disable;
+    bias-pull-up;
  };
  };
--
2.28.0

I don't see consensus on this device tree modification in Linux kernel 
side [1].


And for the DH board the modification is now done in SOM dtsi files 
after [2].


So can I close this patchset in patchwork ?


Yes

And if the modification is accepted in kernel device tree , I will get 
it with my next device


tree alignment...


I plan to realign the DTs after 2021.01 is out too.

Re: ARM: mvebu: enable SPI for helios4 and sata and uart images for clearfog

[Stefan Roese]

Hi Dennis,

On 09.12.20 04:07, dgilm...@redhat.com wrote:

In an effort to build SPI images for clearfog and helios4 I needed to make some
minor changes to the dts and Kconfig for the helios4 and set some variables for
UART and SATA images for ClearFog.

Version 2 dropped changes for db-mv784mp-gp as the board turns out to be 
currently
broken, the serial port is not available and the system bails after loading the 
SPL
the dts changes for the helios4 have been shrunk back to remove everything not
needed or valid


Could you please test this small patch on the db-mv784mp-gp and report
back, if this works:

diff --git a/arch/arm/dts/armada-xp-gp.dts b/arch/arm/dts/armada-xp-gp.dts
index 1139e9469a..57aa58 100644
--- a/arch/arm/dts/armada-xp-gp.dts
+++ b/arch/arm/dts/armada-xp-gp.dts
@@ -93,6 +93,7 @@
internal-regs {
serial@12000 {
status = "okay";
+   u-boot,dm-pre-reloc;
};
serial@12100 {
status = "okay";


Thanks,
Stefan

RE: [PATCH 1/4] fastboot: mmc: Add CONFIG_FASTBOOT_MMC_USER_SUPPORT

[Patrick DELAUNAY]

Hi Lukasz,

> From: Patrick DELAUNAY 
> Sent: mercredi 9 septembre 2020 15:23
> To: u-boot@lists.denx.de
> Cc: Patrick DELAUNAY ; Jagan Teki
> ; Kever Yang ;
> Mingming lee ; Miquel Raynal
> ; Peng Fan ; Simon Glass
> ; U-Boot STM32  mailman.stormreply.com>
> Subject: [PATCH 1/4] fastboot: mmc: Add
> CONFIG_FASTBOOT_MMC_USER_SUPPORT
> Importance: High
> 
> Split userdata and boot partition support for eMMC update and correct the
> description (update is supported).
> 
> The new configuration CONFIG_FASTBOOT_MMC_USER_SUPPORT allows to
> activate support of userdata partition update, based on target
> name=CONFIG_FASTBOOT_MMC_USER_NAME
> 
> This patch also removes the unnecessary dependency with ARCH_MEDIATEK
> and EFI_PARTITION.
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  configs/mt8518_ap1_emmc_defconfig |  1 +
>  drivers/fastboot/Kconfig  | 22 +-
>  drivers/fastboot/fb_mmc.c |  9 ++---
>  3 files changed, 24 insertions(+), 8 deletions(-)
> 

Gentle reminder,

Any comments on this serie [1]

[1] http://patchwork.ozlabs.org/project/uboot/list/?series=200509

Patrick 

Re: [SPECIFICATION RFC] The firmware and bootloader log specification

[Frank Rowand]

On 12/4/20 7:23 AM, Paul Menzel wrote:
> Dear Wim, dear Daniel,
> 
> 
> First, thank you for including all parties in the discussion.
> Am 04.12.20 um 13:52 schrieb Wim Vervoorn:
> 
>> I agree with you. Using an existing standard is better than inventing
>> a new one in this case. I think using the coreboot logging is a good
>> idea as there is indeed a lot of support already available and it is
>> lightweight and simple.
> In my opinion coreboot’s format is lacking, that it does not record the 
> timestamp, and the log level is not stored as metadata, but (in coreboot) 
> only used to decide if to print the message or not.
> 
> I agree with you, that an existing standard should be used, and in my opinion 
> it’s Linux message format. That is most widely supported, and existing tools 
> could then also work with pre-Linux messages.
> 
> Sean Hudson from Mentor Graphics presented that idea at Embedded Linux 
> Conference Europe 2016 [1]. No idea, if anything came out of that effort. 
> (Unfortunately, I couldn’t find an email. Does somebody have contacts at 
> Mentor to find out, how to reach him?)

I forwarded this to Sean.

-Frank

> 
> 
> Kind regards,
> 
> Paul
> 
> 
> [1]: 
> http://events17.linuxfoundation.org/sites/events/files/slides/2016-10-12%20-%20ELCE%20-%20Shared%20Logging%20-%20Part%20Deux.pdf

RE: [PATCH] net: memac_phy: add a timeout to MDIO operations

[Madalin Bucur (OSS)]

> -Original Message-
> From: Ioana Ciornei 
> Sent: 09 December 2020 13:32
> To: joe.hershber...@ni.com; Tom Rini ; u-
> b...@lists.denx.de
> Cc: Madalin Bucur ; Florin Laurentiu Chiculita
> ; Ioana Ciornei 
> Subject: [PATCH] net: memac_phy: add a timeout to MDIO operations
> 
> We have encountered circumstances when a board design does not include
> pull-up resistors on the external MDIO buses which are not used. This
> leads to the MDIO data line not being pulled-up, thus the MDIO controller
> will always see the line as busy.
> 
> Without a timeout in the MDIO bus driver, the execution is stuck in an
> infinite loop when any access is initiated on that external bus.
> 
> Add a timeout in the driver so that we are protected in this
> circumstance. This is similar to what is being done in the Linux
> xgmac_mdio driver.
> 
> Signed-off-by: Ioana Ciornei 
> ---
>  drivers/net/fm/memac_phy.c | 76 +-
>  1 file changed, 58 insertions(+), 18 deletions(-)

Reviewed-by: Madalin Bucur 

Re: [PATCH 4/8] dm: Introduce xxx_get_dma_range()

[Matthias Brugger]

On 19/11/2020 18:48, Nicolas Saenz Julienne wrote:
> Add the follwing functions to get a specific device's DMA ranges:
>  - dev_get_dma_range()
>  - ofnode_get_dma_range()
>  - of_get_dma_range()
>  - fdt_get_dma_range()
> They are specially useful in oder to be able validate a physical address
> space range into a bus's and to convert addresses from and to address
> spaces.
> 
> Signed-off-by: Nicolas Saenz Julienne 
> ---
>  common/fdt_support.c   | 72 ++
>  drivers/core/of_addr.c | 68 +++
>  drivers/core/ofnode.c  |  9 ++
>  drivers/core/read.c|  5 +++
>  include/dm/of_addr.h   | 17 ++
>  include/dm/ofnode.h| 16 ++
>  include/dm/read.h  |  6 
>  include/fdt_support.h  | 14 
>  8 files changed, 207 insertions(+)
> 
> diff --git a/common/fdt_support.c b/common/fdt_support.c
> index 5ae75df3c6..78dc7906bd 100644
> --- a/common/fdt_support.c
> +++ b/common/fdt_support.c
> @@ -1342,6 +1342,78 @@ u64 fdt_translate_dma_address(const void *blob, int 
> node_offset,
>   return __of_translate_address(blob, node_offset, in_addr, "dma-ranges");
>  }
>  
> +int fdt_get_dma_range(const void *blob, int node, phys_addr_t *cpu,
> +   dma_addr_t *bus, u64 *size)
> +{
> + bool found_dma_ranges = false;
> + const fdt32_t *ranges;
> + int na, ns, pna, pns;
> + int parent = node;
> + u64 cpu_addr;
> + int ret = 0;
> + int len;
> +
> + /* Find the closest dma-ranges property */
> + while (parent >= 0) {
> + ranges = fdt_getprop(blob, parent, "dma-ranges", &len);
> +
> + /* Ignore empty ranges, they imply no translation required */
> + if (ranges && len > 0)
> + break;
> +
> + /* Once we find 'dma-ranges', then a missing one is an error */
> + if (found_dma_ranges && !ranges) {
> + ret = -ENODEV;
> + goto out;
> + }
> +
> + if (ranges)
> + found_dma_ranges = true;
> +
> + parent = fdt_parent_offset(blob, parent);
> + }
> +
> + if (!ranges || parent < 0) {
> + debug("no dma-ranges found for node %s\n",
> +   fdt_get_name(blob, node, NULL));
> + ret = -ENODEV;
> + goto out;
> + }
> +
> + /* switch to that node */
> + node = parent;
> + parent = fdt_parent_offset(blob, node);
> + if (parent < 0) {
> + printf("Found dma-ranges in root node, shoudln't happen\n");
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + /* Get the address sizes both for the bus and its parent */
> + of_match_bus(blob, node)->count_cells(blob, node, &na, &ns);

Please see comment in of_get_dma_range().

> + if (!OF_CHECK_COUNTS(na, ns)) {
> + printf("%s: Bad cell count for %s\n", __FUNCTION__,
> +fdt_get_name(blob, node, NULL));
> + return -EINVAL;
> + goto out;
> + }
> +
> + of_match_bus(blob, parent)->count_cells(blob, parent, &pna, &pns);
> + if (!OF_CHECK_COUNTS(pna, pns)) {
> + printf("%s: Bad cell count for %s\n", __FUNCTION__,
> +fdt_get_name(blob, parent, NULL));
> + return -EINVAL;
> + goto out;
> + }
> +
> + *bus = fdt_read_number(ranges, na);
> + cpu_addr = fdt_read_number(ranges + na, pna);
> + *cpu = fdt_translate_dma_address(blob, node, (const fdt32_t*)&cpu_addr);
> + *size = fdt_read_number(ranges + na + pna, ns);
> +out:
> + return ret;
> +}
> +
>  /**
>   * fdt_node_offset_by_compat_reg: Find a node that matches compatiable and
>   * who's reg property matches a physical cpu address
> diff --git a/drivers/core/of_addr.c b/drivers/core/of_addr.c
> index ca34d84922..8457e04a25 100644
> --- a/drivers/core/of_addr.c
> +++ b/drivers/core/of_addr.c
> @@ -325,6 +325,74 @@ u64 of_translate_dma_address(const struct device_node 
> *dev, const __be32 *in_add
>   return __of_translate_address(dev, in_addr, "dma-ranges");
>  }
>  
> +int of_get_dma_range(const struct device_node *dev, phys_addr_t *cpu,
> +  dma_addr_t *bus, u64 *size)
> +{
> + bool found_dma_ranges = false;
> + struct device_node parent;
> + int na, ns, pna, pns;
> + const __be32 *ranges;
> + int ret = 0;
> + int len;
> +
> + /* Find the closest dma-ranges property */
> + while (dev) {
> + ranges = of_get_property(dev, "dma-ranges", &len);
> +
> + /* Ignore empty ranges, they imply no translation required */
> + if (ranges && len > 0)
> + break;
> +
> + /* Once we find 'dma-ranges', then a missing one is an error */
> + if (found_dma_ranges && !ranges) {
> + ret = -ENODEV;
> + goto out;
> +

Re: FW: [PATCH] add check for ignored CONFIG_ENV_EXT4_DEVICE_AND_PART definition

[Manuel Luís Reis]

Hi Patrick,

Apologies. Must have missed that.

Thanks
Manuel

On Wed, 9 Dec 2020 at 10:28, Patrick DELAUNAY 
wrote:

>
> On 12/9/20 10:06 AM, Patrick DELAUNAY wrote:
> > Hi Manuel,
> >
> > On 12/9/20 9:59 AM, Patrick DELAUNAY wrote:
> >> From: Manuel Reis 
> >> Sent: mercredi 25 novembre 2020 11:16
> >>
> >> Check whether user has explicitly defined device and partition where
> >> environment file will be located before using 'auto' i.e. bootable
> >> partition
> >>
> >> Voids the need to set such partition as bootable to work with the
> >> 'dev:auto' tuple
> >>
> >> Signed-off-by: Manuel Reis 
> >> Cc: Patrick Delaunay 
> >> Cc: Patrice Chotard 
> >> Tested-by: Michael Opdenacker 
> >> ---
> >>
> >>   board/st/stm32mp1/stm32mp1.c | 5 +
> >>   1 file changed, 5 insertions(+)
> >>
> >> diff --git a/board/st/stm32mp1/stm32mp1.c
> >> b/board/st/stm32mp1/stm32mp1.c index 03a19af930..09d9bbf07d 100644
> >> --- a/board/st/stm32mp1/stm32mp1.c
> >> +++ b/board/st/stm32mp1/stm32mp1.c
> >> @@ -827,7 +827,12 @@ const char *env_ext4_get_intf(void)
> >> const char *env_ext4_get_dev_part(void)  {
> >> +static char *const env_dev_part = CONFIG_ENV_EXT4_DEVICE_AND_PART;
> >>   static char *const dev_part[] = {"0:auto", "1:auto", "2:auto"};
> >> +
> >> +if (strlen(env_dev_part) > 0)
> >> +return env_dev_part;
> >> +
> >>   u32 bootmode = get_bootmode();
> >> return dev_part[(bootmode & TAMP_BOOT_INSTANCE_MASK) - 1];
> >> --
> >> 2.27.0
> >>
> > In fact it just is V2 of previous patch
> >
> >
> http://patchwork.ozlabs.org/project/uboot/patch/20201122151939.20005-1-mluis.r...@gmail.com/
> >
> >
> > Reviewed-by: Patrick Delaunay 
> >
> > Applied to u-boot-stm/master.
> >
> >
> > Thanks
> >
> > Patrick
> >
>
> To solve compilation issue when CONFIG_ENV_EXT4_DEVICE_AND_PART is not
> defined
>
> I modify the patch before to apply it in u-boot-stm/master.
>
> Regards
>
> Patrick
>
> - board/st/stm32mp1/stm32mp1.c
> -
> index 8a3ce0a6f5..d3cffdd770 100644
> @@ -827,11 +827,22 @@ const char *env_ext4_get_intf(void)
>
>   const char *env_ext4_get_dev_part(void)
>   {
> +static char *const env_dev_part =
> +#ifdef CONFIG_ENV_EXT4_DEVICE_AND_PART
> +CONFIG_ENV_EXT4_DEVICE_AND_PART;
> +#else
> +"";
> +#endif
>   static char *const dev_part[] = {"0:auto", "1:auto", "2:auto"};
> +
> +if (strlen(env_dev_part) > 0)
> +return env_dev_part;
> +
>   u32 bootmode = get_bootmode();
>
>   return dev_part[(bootmode & TAMP_BOOT_INSTANCE_MASK) - 1];
>   }
> +
>
>
>

[PATCH] net: memac_phy: add a timeout to MDIO operations

[Ioana Ciornei]

We have encountered circumstances when a board design does not include
pull-up resistors on the external MDIO buses which are not used. This
leads to the MDIO data line not being pulled-up, thus the MDIO controller
will always see the line as busy.

Without a timeout in the MDIO bus driver, the execution is stuck in an
infinite loop when any access is initiated on that external bus.

Add a timeout in the driver so that we are protected in this
circumstance. This is similar to what is being done in the Linux
xgmac_mdio driver.

Signed-off-by: Ioana Ciornei 
---
 drivers/net/fm/memac_phy.c | 76 +-
 1 file changed, 58 insertions(+), 18 deletions(-)

diff --git a/drivers/net/fm/memac_phy.c b/drivers/net/fm/memac_phy.c
index c2ef1b4e737e..b92a012ce79f 100644
--- a/drivers/net/fm/memac_phy.c
+++ b/drivers/net/fm/memac_phy.c
@@ -22,6 +22,8 @@
 #define memac_setbits_32(a, v) setbits_be32(a, v)
 #endif
 
+#define MAX_NUM_RETRIES1000
+
 static u32 memac_in_32(u32 *reg)
 {
 #ifdef CONFIG_SYS_MEMAC_LITTLE_ENDIAN
@@ -31,6 +33,42 @@ static u32 memac_in_32(u32 *reg)
 #endif
 }
 
+/*
+ * Wait until the MDIO bus is free
+ */
+static int memac_wait_until_free(struct memac_mdio_controller *regs)
+{
+   unsigned int timeout = MAX_NUM_RETRIES;
+
+   while ((memac_in_32(®s->mdio_stat) & MDIO_STAT_BSY) && timeout--)
+   ;
+
+   if (!timeout) {
+   printf("timeout waiting for MDIO bus to be free\n");
+   return -ETIMEDOUT;
+   }
+
+   return 0;
+}
+
+/*
+ * Wait till the MDIO read or write operation is complete
+ */
+static int memac_wait_until_done(struct memac_mdio_controller *regs)
+{
+   unsigned int timeout = MAX_NUM_RETRIES;
+
+   while ((memac_in_32(®s->mdio_data) & MDIO_DATA_BSY) && timeout--)
+   ;
+
+   if (!timeout) {
+   printf("timeout waiting for MDIO operation to complete\n");
+   return -ETIMEDOUT;
+   }
+
+   return 0;
+}
+
 /*
  * Write value to the PHY for this device to the register at regnum, waiting
  * until the write is done before it returns.  All PHY configuration has to be
@@ -42,6 +80,7 @@ int memac_mdio_write(struct mii_dev *bus, int port_addr, int 
dev_addr,
u32 mdio_ctl;
struct memac_mdio_controller *regs = bus->priv;
u32 c45 = 1; /* Default to 10G interface */
+   int err;
 
if (dev_addr == MDIO_DEVAD_NONE) {
c45 = 0; /* clause 22 */
@@ -50,9 +89,9 @@ int memac_mdio_write(struct mii_dev *bus, int port_addr, int 
dev_addr,
} else
memac_setbits_32(®s->mdio_stat, MDIO_STAT_ENC);
 
-   /* Wait till the bus is free */
-   while ((memac_in_32(®s->mdio_stat)) & MDIO_STAT_BSY)
-   ;
+   err = memac_wait_until_free(regs);
+   if (err)
+   return err;
 
/* Set the port and dev addr */
mdio_ctl = MDIO_CTL_PORT_ADDR(port_addr) | MDIO_CTL_DEV_ADDR(dev_addr);
@@ -62,16 +101,16 @@ int memac_mdio_write(struct mii_dev *bus, int port_addr, 
int dev_addr,
if (c45)
memac_out_32(®s->mdio_addr, regnum & 0x);
 
-   /* Wait till the bus is free */
-   while ((memac_in_32(®s->mdio_stat)) & MDIO_STAT_BSY)
-   ;
+   err = memac_wait_until_free(regs);
+   if (err)
+   return err;
 
/* Write the value to the register */
memac_out_32(®s->mdio_data, MDIO_DATA(value));
 
-   /* Wait till the MDIO write is complete */
-   while ((memac_in_32(®s->mdio_data)) & MDIO_DATA_BSY)
-   ;
+   err = memac_wait_until_done(regs);
+   if (err)
+   return err;
 
return 0;
 }
@@ -87,6 +126,7 @@ int memac_mdio_read(struct mii_dev *bus, int port_addr, int 
dev_addr,
u32 mdio_ctl;
struct memac_mdio_controller *regs = bus->priv;
u32 c45 = 1;
+   int err;
 
if (dev_addr == MDIO_DEVAD_NONE) {
if (!strcmp(bus->name, DEFAULT_FM_TGEC_MDIO_NAME))
@@ -97,9 +137,9 @@ int memac_mdio_read(struct mii_dev *bus, int port_addr, int 
dev_addr,
} else
memac_setbits_32(®s->mdio_stat, MDIO_STAT_ENC);
 
-   /* Wait till the bus is free */
-   while ((memac_in_32(®s->mdio_stat)) & MDIO_STAT_BSY)
-   ;
+   err = memac_wait_until_free(regs);
+   if (err)
+   return err;
 
/* Set the Port and Device Addrs */
mdio_ctl = MDIO_CTL_PORT_ADDR(port_addr) | MDIO_CTL_DEV_ADDR(dev_addr);
@@ -109,17 +149,17 @@ int memac_mdio_read(struct mii_dev *bus, int port_addr, 
int dev_addr,
if (c45)
memac_out_32(®s->mdio_addr, regnum & 0x);
 
-   /* Wait till the bus is free */
-   while ((memac_in_32(®s->mdio_stat)) & MDIO_STAT_BSY)
-   ;
+   err = memac_wait_until_free(regs);
+   if (err)
+   return err;
 
/* Initiate the read */
mdio_ctl |= MDIO_CTL_READ;
  

[PATCH] configs: ls1088aqds: add COMMON_ENV to fix distroboot

[Biwen Li]

From: Biwen Li 

Add COMMON_ENV to fix distroboot, boot log as follows,
Found U-Boot script /ls1088aqds_boot.scr
961 bytes read in 18 ms (51.8 KiB/s)
## Executing script at 8000
load - load binary file from a filesystemUsage:
load  [ [ [ [bytes [pos]
- Load binary file filename from partition part on device
   type interface instance dev to address addr in memory.
  bytes gives the size to load in bytes.
  If bytes is 0 or omitted, the file is read until the end.
  pos gives the file byte position to start reading from.
  If pos is 0 or omitted, the file is read from the start.
load - load binary file from a filesystemUsage:
load  [ [ [ [bytes [pos]
- Load binary file filename from partition part on device
   type interface instance dev to address addr in memory.
  bytes gives the size to load in bytes.
  If bytes is 0 or omitted, the file is read until the end.
  pos gives the file byte position to start reading from.
  If pos is 0 or omitted, the file is read from the start.
Bad Linux ARM64 Image magic!
SCRIPT FAILED: continuing...

Signed-off-by: Biwen Li 
---
 include/configs/ls1088aqds.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/configs/ls1088aqds.h b/include/configs/ls1088aqds.h
index 59757120fc..0dd6bb9f32 100644
--- a/include/configs/ls1088aqds.h
+++ b/include/configs/ls1088aqds.h
@@ -384,10 +384,18 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_ESDHC_DETECT_QUIRK ((readb(QIXIS_BASE + QIXIS_STAT_PRES1) & \
QIXIS_SDID_MASK) != QIXIS_ESDHC_NO_ADAPTER)
 
+#define COMMON_ENV \
+   "kernelheader_addr_r=0x8020\0"  \
+   "fdtheader_addr_r=0x8010\0" \
+   "kernel_addr_r=0x8100\0"\
+   "fdt_addr_r=0x9000\0"   \
+   "load_addr=0xa000\0"
+
 /* Initial environment variables */
 #ifdef CONFIG_NXP_ESBC
 #undef CONFIG_EXTRA_ENV_SETTINGS
 #define CONFIG_EXTRA_ENV_SETTINGS  \
+   COMMON_ENV  \
"hwconfig=fsl_ddr:bank_intlv=auto\0"\
"loadaddr=0x9010\0" \
"kernel_addr=0x10\0"\
@@ -419,6 +427,7 @@ unsigned long get_board_ddr_clk(void);
 
 #undef CONFIG_EXTRA_ENV_SETTINGS
 #define CONFIG_EXTRA_ENV_SETTINGS  \
+   COMMON_ENV  \
"hwconfig=fsl_ddr:bank_intlv=auto\0"\
"loadaddr=0x9010\0" \
"kernel_addr=0x10\0"\
@@ -480,6 +489,7 @@ unsigned long get_board_ddr_clk(void);
 #if defined(CONFIG_QSPI_BOOT)
 #undef CONFIG_EXTRA_ENV_SETTINGS
 #define CONFIG_EXTRA_ENV_SETTINGS  \
+   COMMON_ENV  \
"hwconfig=fsl_ddr:bank_intlv=auto\0"\
"loadaddr=0x9010\0" \
"kernel_addr=0x10\0"\
@@ -497,6 +507,7 @@ unsigned long get_board_ddr_clk(void);
 #elif defined(CONFIG_SD_BOOT)
 #undef CONFIG_EXTRA_ENV_SETTINGS
 #define CONFIG_EXTRA_ENV_SETTINGS   \
+   COMMON_ENV  \
"hwconfig=fsl_ddr:bank_intlv=auto\0"\
"loadaddr=0x9010\0" \
"kernel_addr=0x800\0"\
@@ -514,6 +525,7 @@ unsigned long get_board_ddr_clk(void);
 #else  /* NOR BOOT */
 #undef CONFIG_EXTRA_ENV_SETTINGS
 #define CONFIG_EXTRA_ENV_SETTINGS  \
+   COMMON_ENV  \
"hwconfig=fsl_ddr:bank_intlv=auto\0"\
"loadaddr=0x9010\0" \
"kernel_addr=0x10\0"\
-- 
2.17.1

Re: FW: [PATCH] add check for ignored CONFIG_ENV_EXT4_DEVICE_AND_PART definition

[Patrick DELAUNAY]

On 12/9/20 10:06 AM, Patrick DELAUNAY wrote:

Hi Manuel,

On 12/9/20 9:59 AM, Patrick DELAUNAY wrote:

From: Manuel Reis 
Sent: mercredi 25 novembre 2020 11:16

Check whether user has explicitly defined device and partition where 
environment file will be located before using 'auto' i.e. bootable 
partition


Voids the need to set such partition as bootable to work with the 
'dev:auto' tuple


Signed-off-by: Manuel Reis 
Cc: Patrick Delaunay 
Cc: Patrice Chotard 
Tested-by: Michael Opdenacker 
---

  board/st/stm32mp1/stm32mp1.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/board/st/stm32mp1/stm32mp1.c 
b/board/st/stm32mp1/stm32mp1.c index 03a19af930..09d9bbf07d 100644

--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -827,7 +827,12 @@ const char *env_ext4_get_intf(void)
    const char *env_ext4_get_dev_part(void)  {
+    static char *const env_dev_part = CONFIG_ENV_EXT4_DEVICE_AND_PART;
  static char *const dev_part[] = {"0:auto", "1:auto", "2:auto"};
+
+    if (strlen(env_dev_part) > 0)
+    return env_dev_part;
+
  u32 bootmode = get_bootmode();
    return dev_part[(bootmode & TAMP_BOOT_INSTANCE_MASK) - 1];
--
2.27.0


In fact it just is V2 of previous patch

http://patchwork.ozlabs.org/project/uboot/patch/20201122151939.20005-1-mluis.r...@gmail.com/ 



Reviewed-by: Patrick Delaunay 

Applied to u-boot-stm/master.


Thanks

Patrick



To solve compilation issue when CONFIG_ENV_EXT4_DEVICE_AND_PART is not 
defined


I modify the patch before to apply it in u-boot-stm/master.

Regards

Patrick

- board/st/stm32mp1/stm32mp1.c 
-

index 8a3ce0a6f5..d3cffdd770 100644
@@ -827,11 +827,22 @@ const char *env_ext4_get_intf(void)

 const char *env_ext4_get_dev_part(void)
 {
+    static char *const env_dev_part =
+#ifdef CONFIG_ENV_EXT4_DEVICE_AND_PART
+        CONFIG_ENV_EXT4_DEVICE_AND_PART;
+#else
+        "";
+#endif
 static char *const dev_part[] = {"0:auto", "1:auto", "2:auto"};
+
+    if (strlen(env_dev_part) > 0)
+        return env_dev_part;
+
 u32 bootmode = get_bootmode();

 return dev_part[(bootmode & TAMP_BOOT_INSTANCE_MASK) - 1];
 }
+

Re: A3720 - Disable slot when eMMC is not present

[Pali Rohár]

On Wednesday 09 December 2020 19:01:19 Jaehoon Chung wrote:
> Hi,
> 
> On 12/8/20 7:08 PM, Pali Rohár wrote:
> > Hello! I looked at what is initialized and enabled for sd/emmc slots and
> > I found out that comphy mmc needs to be enabled if at least one slot is
> > used (e.g. SD card) and then remaining part is slot initialization in
> > xenon driver.
> > 
> > I wrote quick patch to disable slot when unregistering mmc device from
> > U-Boot and also unregister emmc on A3720 from U-Boot when it is not
> > present. But I have not tested it yet.
> > > What do you think about it?
> 
> Logically, it's possible to disable slot. But i'm not sure because of not 
> having its board.
> Just minor question.. Does it support multi slot per one IP?

A3720 has only one slot with index XENON_MMC_SLOT_ID_HYPERION.

A3720 has two mmc/sd IPs at two different address spaces, so uSD and
eMMC do not share config address space.

> Best Regards,
> Jaehoon Chung
> 
> > 
> > diff --git a/board/Marvell/mvebu_armada-37xx/board.c 
> > b/board/Marvell/mvebu_armada-37xx/board.c
> > index f67b04b78c..1b9e7520cc 100644
> > --- a/board/Marvell/mvebu_armada-37xx/board.c
> > +++ b/board/Marvell/mvebu_armada-37xx/board.c
> > @@ -5,6 +5,7 @@
> >  
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -84,12 +85,10 @@ int board_init(void)
> >  #ifdef CONFIG_BOARD_LATE_INIT
> >  int board_late_init(void)
> >  {
> > +   struct udevice *dev;
> > struct mmc *mmc_dev;
> > bool ddr4, emmc;
> >  
> > -   if (env_get("fdtfile"))
> > -   return 0;
> > -
> > if (!of_machine_is_compatible("globalscale,espressobin"))
> > return 0;
> >  
> > @@ -101,6 +100,16 @@ int board_late_init(void)
> > mmc_dev = find_mmc_device(1);
> > emmc = (mmc_dev && mmc_init(mmc_dev) == 0);
> >  
> > +   /* if eMMC is not present then remove it from DM */
> > +   if (!emmc && mmc_dev) {
> > +   dev = mmc_dev->dev;
> > +   device_remove(dev, DM_REMOVE_NORMAL);
> > +   device_unbind(dev);
> > +   }
> > +
> > +   if (env_get("fdtfile"))
> > +   return 0;
> > +
> > if (ddr4 && emmc)
> > env_set("fdtfile", 
> > "marvell/armada-3720-espressobin-v7-emmc.dtb");
> > else if (ddr4)
> > diff --git a/drivers/mmc/xenon_sdhci.c b/drivers/mmc/xenon_sdhci.c
> > index 6ce9d00d0a..da9882cbf6 100644
> > --- a/drivers/mmc/xenon_sdhci.c
> > +++ b/drivers/mmc/xenon_sdhci.c
> > @@ -350,6 +350,16 @@ static void xenon_mmc_enable_slot(struct sdhci_host 
> > *host, u8 slot)
> > sdhci_writel(host, var, SDHC_SYS_OP_CTRL);
> >  }
> >  
> > +/* Disable specific slot */
> > +static void xenon_mmc_disable_slot(struct sdhci_host *host, u8 slot)
> > +{
> > +   u32 var;
> > +
> > +   var = sdhci_readl(host, SDHC_SYS_OP_CTRL);
> > +   var &= ~(SLOT_MASK(slot) << SLOT_ENABLE_SHIFT);
> > +   sdhci_writel(host, var, SDHC_SYS_OP_CTRL);
> > +}
> > +
> >  /* Enable Parallel Transfer Mode */
> >  static void xenon_mmc_enable_parallel_tran(struct sdhci_host *host, u8 
> > slot)
> >  {
> > @@ -515,6 +525,14 @@ static int xenon_sdhci_probe(struct udevice *dev)
> > return ret;
> >  }
> >  
> > +static int xenon_sdhci_remove(struct udevice *dev)
> > +{
> > +   struct sdhci_host *host = dev_get_priv(dev);
> > +
> > +   xenon_mmc_disable_slot(host, XENON_MMC_SLOT_ID_HYPERION);
> > +   return 0;
> > +}
> > +
> >  static int xenon_sdhci_ofdata_to_platdata(struct udevice *dev)
> >  {
> > struct sdhci_host *host = dev_get_priv(dev);
> > @@ -564,6 +582,7 @@ U_BOOT_DRIVER(xenon_sdhci_drv) = {
> > .ops= &sdhci_ops,
> > .bind   = xenon_sdhci_bind,
> > .probe  = xenon_sdhci_probe,
> > +   .remove = xenon_sdhci_remove,
> > .priv_auto_alloc_size = sizeof(struct xenon_sdhci_priv),
> > .platdata_auto_alloc_size = sizeof(struct xenon_sdhci_plat),
> >  };
> > 
> > 
> 

Re: [PATCH] ARM: dts: stm32: Consistently enable internal pull-ups for SD bus

[Patrick DELAUNAY]

Hi Marek,

On 12/9/20 11:11 AM, Patrick DELAUNAY wrote:

From: Marek Vasut 
Sent: vendredi 9 octobre 2020 23:08

The default state of SD bus and clock line is logical HI. SD card IO is 
open-drain and pulls the bus lines LO. Always enable the SD bus pull ups to 
guarantee this behavior. Note that on systems with bus voltage level shifter on 
the SD bus, the pull ups might also be built into the level shifter, however 
that should have no negative impact.

Signed-off-by: Marek Vasut 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
---
  arch/arm/dts/stm32mp15-pinctrl.dtsi | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/dts/stm32mp15-pinctrl.dtsi 
b/arch/arm/dts/stm32mp15-pinctrl.dtsi
index 154832983c..2f8ff44a7a 100644
--- a/arch/arm/dts/stm32mp15-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp15-pinctrl.dtsi
@@ -1184,13 +1184,13 @@
 ; /* SDMMC1_CMD */
slew-rate = <1>;
drive-push-pull;
-   bias-disable;
+   bias-pull-up;
};
pins2 {
pinmux = ; /* SDMMC1_CK */
slew-rate = <2>;
drive-push-pull;
-   bias-disable;
+   bias-pull-up;
};
};
  
@@ -1340,13 +1340,13 @@

 ; /* SDMMC2_CMD */
slew-rate = <1>;
drive-push-pull;
-   bias-disable;
+   bias-pull-up;
};
pins2 {
pinmux = ; /* SDMMC2_CK */
slew-rate = <2>;
drive-push-pull;
-   bias-disable;
+   bias-pull-up;
};
};
  
--

2.28.0

I don't see consensus on this device tree modification in Linux kernel 
side [1].


And for the DH board the modification is now done in SOM dtsi files 
after [2].


So can I close this patchset in patchwork ?

And if the modification is accepted in kernel device tree , I will get 
it with my next device


tree alignment...

[1] 
https://st-md-mailman.stormreply.com/pipermail/linux-stm32/2020-October/008554.html


[2] "ARM: dts: stm32: Enable internal pull-ups for SDMMC1 on DHCOM SoM 
"


http://patchwork.ozlabs.org/project/uboot/list/?series=217761&state=*


Regards

Patrick

Re: A3720 - Disable slot when eMMC is not present

[Jaehoon Chung]

Hi,

On 12/8/20 7:08 PM, Pali Rohár wrote:
> Hello! I looked at what is initialized and enabled for sd/emmc slots and
> I found out that comphy mmc needs to be enabled if at least one slot is
> used (e.g. SD card) and then remaining part is slot initialization in
> xenon driver.
> 
> I wrote quick patch to disable slot when unregistering mmc device from
> U-Boot and also unregister emmc on A3720 from U-Boot when it is not
> present. But I have not tested it yet.
> > What do you think about it?

Logically, it's possible to disable slot. But i'm not sure because of not 
having its board.
Just minor question.. Does it support multi slot per one IP?

Best Regards,
Jaehoon Chung

> 
> diff --git a/board/Marvell/mvebu_armada-37xx/board.c 
> b/board/Marvell/mvebu_armada-37xx/board.c
> index f67b04b78c..1b9e7520cc 100644
> --- a/board/Marvell/mvebu_armada-37xx/board.c
> +++ b/board/Marvell/mvebu_armada-37xx/board.c
> @@ -5,6 +5,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -84,12 +85,10 @@ int board_init(void)
>  #ifdef CONFIG_BOARD_LATE_INIT
>  int board_late_init(void)
>  {
> + struct udevice *dev;
>   struct mmc *mmc_dev;
>   bool ddr4, emmc;
>  
> - if (env_get("fdtfile"))
> - return 0;
> -
>   if (!of_machine_is_compatible("globalscale,espressobin"))
>   return 0;
>  
> @@ -101,6 +100,16 @@ int board_late_init(void)
>   mmc_dev = find_mmc_device(1);
>   emmc = (mmc_dev && mmc_init(mmc_dev) == 0);
>  
> + /* if eMMC is not present then remove it from DM */
> + if (!emmc && mmc_dev) {
> + dev = mmc_dev->dev;
> + device_remove(dev, DM_REMOVE_NORMAL);
> + device_unbind(dev);
> + }
> +
> + if (env_get("fdtfile"))
> + return 0;
> +
>   if (ddr4 && emmc)
>   env_set("fdtfile", 
> "marvell/armada-3720-espressobin-v7-emmc.dtb");
>   else if (ddr4)
> diff --git a/drivers/mmc/xenon_sdhci.c b/drivers/mmc/xenon_sdhci.c
> index 6ce9d00d0a..da9882cbf6 100644
> --- a/drivers/mmc/xenon_sdhci.c
> +++ b/drivers/mmc/xenon_sdhci.c
> @@ -350,6 +350,16 @@ static void xenon_mmc_enable_slot(struct sdhci_host 
> *host, u8 slot)
>   sdhci_writel(host, var, SDHC_SYS_OP_CTRL);
>  }
>  
> +/* Disable specific slot */
> +static void xenon_mmc_disable_slot(struct sdhci_host *host, u8 slot)
> +{
> + u32 var;
> +
> + var = sdhci_readl(host, SDHC_SYS_OP_CTRL);
> + var &= ~(SLOT_MASK(slot) << SLOT_ENABLE_SHIFT);
> + sdhci_writel(host, var, SDHC_SYS_OP_CTRL);
> +}
> +
>  /* Enable Parallel Transfer Mode */
>  static void xenon_mmc_enable_parallel_tran(struct sdhci_host *host, u8 slot)
>  {
> @@ -515,6 +525,14 @@ static int xenon_sdhci_probe(struct udevice *dev)
>   return ret;
>  }
>  
> +static int xenon_sdhci_remove(struct udevice *dev)
> +{
> + struct sdhci_host *host = dev_get_priv(dev);
> +
> + xenon_mmc_disable_slot(host, XENON_MMC_SLOT_ID_HYPERION);
> + return 0;
> +}
> +
>  static int xenon_sdhci_ofdata_to_platdata(struct udevice *dev)
>  {
>   struct sdhci_host *host = dev_get_priv(dev);
> @@ -564,6 +582,7 @@ U_BOOT_DRIVER(xenon_sdhci_drv) = {
>   .ops= &sdhci_ops,
>   .bind   = xenon_sdhci_bind,
>   .probe  = xenon_sdhci_probe,
> + .remove = xenon_sdhci_remove,
>   .priv_auto_alloc_size = sizeof(struct xenon_sdhci_priv),
>   .platdata_auto_alloc_size = sizeof(struct xenon_sdhci_plat),
>  };
> 
> 

[PATCH 2/2] board: kontron: disable flash unlock all

[Michael Walle]

Although the status register is protected by the hardware write
protection, there is a hardware jumper to disable that hardware write
protection. Thus if a user would set this jumper any u-boot start would
disable the write protection altogether.

Circumvent that by not disabling the write protection in the first
place.

Signed-off-by: Michael Walle 
---
 configs/kontron_sl28_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/kontron_sl28_defconfig b/configs/kontron_sl28_defconfig
index c1a096799c..12720f343e 100644
--- a/configs/kontron_sl28_defconfig
+++ b/configs/kontron_sl28_defconfig
@@ -73,6 +73,7 @@ CONFIG_MMC_HS400_SUPPORT=y
 CONFIG_FSL_ESDHC=y
 CONFIG_FSL_ESDHC_SUPPORT_ADMA2=y
 CONFIG_DM_SPI_FLASH=y
+# CONFIG_SPI_FLASH_UNLOCK_ALL is not set
 CONFIG_SPI_FLASH_WINBOND=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_PHYLIB=y
-- 
2.20.1

[PATCH 1/2] mtd: spi-nor: add unlock all config option

[Michael Walle]

Provide an explicit configuration option to disable default "unlock all"
of any flash chip which supports locking. It doesn't make sense to
automatically unprotect the entire flash on each u-boot startup if the
block protection bits are actually used.

Traditionally, the unlock was there to be able to write to flash devices
which powered-up with the block protection bits set. Over time this
feature creeped into all flash devices which support locking.

For a more detailed description and discussion see:
  https://lore.kernel.org/linux-mtd/20201203162959.29589-8-mich...@walle.cc/

Keep things simple in u-boot and just provide a configration option to
disable this behavior which can be set per board.

Signed-off-by: Michael Walle 
---
 drivers/mtd/spi/Kconfig| 10 ++
 drivers/mtd/spi/spi-nor-core.c |  9 +
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
index 018e8c597e..bb8e8a9153 100644
--- a/drivers/mtd/spi/Kconfig
+++ b/drivers/mtd/spi/Kconfig
@@ -95,6 +95,16 @@ config SPI_FLASH_BAR
  Bank/Extended address registers are used to access the flash
  which has size > 16MiB in 3-byte addressing.
 
+config SPI_FLASH_UNLOCK_ALL
+   bool "Unlock the entire SPI flash on u-boot startup"
+   default y
+   help
+Some flashes tend to power up with the software write protection
+bits set. If this option is set, the whole flash will be unlocked.
+
+For legacy reasons, this option default to y. But if you intend to
+actually use the software protection bits you should say n here.
+
 config SF_DUAL_FLASH
bool "SPI DUAL flash memory support"
help
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index e16b0e1462..ef426dac02 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -2443,10 +2443,11 @@ static int spi_nor_init(struct spi_nor *nor)
 * Atmel, SST, Intel/Numonyx, and others serial NOR tend to power up
 * with the software protection bits set
 */
-   if (JEDEC_MFR(nor->info) == SNOR_MFR_ATMEL ||
-   JEDEC_MFR(nor->info) == SNOR_MFR_INTEL ||
-   JEDEC_MFR(nor->info) == SNOR_MFR_SST ||
-   nor->info->flags & SPI_NOR_HAS_LOCK) {
+   if (IS_ENABLED(CONFIG_SPI_FLASH_UNLOCK_ALL) &&
+   (JEDEC_MFR(nor->info) == SNOR_MFR_ATMEL ||
+JEDEC_MFR(nor->info) == SNOR_MFR_INTEL ||
+JEDEC_MFR(nor->info) == SNOR_MFR_SST ||
+nor->info->flags & SPI_NOR_HAS_LOCK)) {
write_enable(nor);
write_sr(nor, 0);
spi_nor_wait_till_ready(nor);
-- 
2.20.1

Re: FW: [PATCH 1/4] ARM: dts: stm32: Enable internal pull-ups for SDMMC1 on DHCOM SoM

[Patrick DELAUNAY]

Hi Marek,

On 12/8/20 6:26 PM, Marek Vasut wrote:

On 12/8/20 6:20 PM, Patrick DELAUNAY wrote:

Hi Marek,


Hi,

[...]

For the serie:  the target is next or it is a bugfix for master / 
v2021.01 ?


This is for 2021.01 , it corrects a couple of random things here and 
there.



For the serie:

Applied to u-boot-stm/master.

Thanks

Patrick

Re: FW: [PATCH] add check for ignored CONFIG_ENV_EXT4_DEVICE_AND_PART definition

[Patrick DELAUNAY]

Hi Manuel,

On 12/9/20 9:59 AM, Patrick DELAUNAY wrote:

From: Manuel Reis 
Sent: mercredi 25 novembre 2020 11:16

Check whether user has explicitly defined device and partition where 
environment file will be located before using 'auto' i.e. bootable partition

Voids the need to set such partition as bootable to work with the 'dev:auto' 
tuple

Signed-off-by: Manuel Reis 
Cc: Patrick Delaunay 
Cc: Patrice Chotard 
Tested-by: Michael Opdenacker 
---

  board/st/stm32mp1/stm32mp1.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c index 
03a19af930..09d9bbf07d 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -827,7 +827,12 @@ const char *env_ext4_get_intf(void)
  
  const char *env_ext4_get_dev_part(void)  {

+   static char *const env_dev_part = CONFIG_ENV_EXT4_DEVICE_AND_PART;
static char *const dev_part[] = {"0:auto", "1:auto", "2:auto"};
+
+   if (strlen(env_dev_part) > 0)
+   return env_dev_part;
+
u32 bootmode = get_bootmode();
  
  	return dev_part[(bootmode & TAMP_BOOT_INSTANCE_MASK) - 1];

--
2.27.0


In fact it just is V2 of previous patch

http://patchwork.ozlabs.org/project/uboot/patch/20201122151939.20005-1-mluis.r...@gmail.com/

Reviewed-by: Patrick Delaunay 

Applied to u-boot-stm/master.


Thanks

Patrick

Re: [PATCH 01/14] qemu: arm: Use the generated DTB only when CONGIG_OF_BOARD is defined

[Sughosh Ganu]

On Wed, 9 Dec 2020 at 12:56, Heinrich Schuchardt  wrote:

> On 12/9/20 6:25 AM, Sughosh Ganu wrote:
> > On Wed, 9 Dec 2020 at 03:24, Heinrich Schuchardt 
> wrote:
> >
> >> On 12/8/20 10:19 AM, Sughosh Ganu wrote:
> >>>
> >>> On Tue, 8 Dec 2020 at 14:32, Heinrich Schuchardt  >>> > wrote:
> >>>
> >>>  On 08.12.20 06:28, Sughosh Ganu wrote:
> >>>   >
> >>>   > On Mon, 7 Dec 2020 at 23:28, Heinrich Schuchardt
> >>>  mailto:xypron.g...@gmx.de>
> >>>   > >>
> wrote:
> >>>   >
> >>>   > On 07.12.20 13:50, Heinrich Schuchardt wrote:
> >>>   > > On 07.12.20 06:15, Sughosh Ganu wrote:
> >>>   > >> hello Heinrich,
> >>>   > >>
> >>>   > >> On Sat, 5 Dec 2020 at 15:01, Heinrich Schuchardt
> >>>   > mailto:xypron.g...@gmx.de>
> >>>  >
> >>>   > >> 
> >>>   >>>   > >>
> >>>   > >> On 11/26/20 7:40 PM, Sughosh Ganu wrote:
> >>>   > >> > The Qemu platform emulator generates a device tree
> >>>  blob and
> >>>   > places it
> >>>   > >> > at the start of the dram, which is then used by
> >>>  u-boot. Use
> >>>   > this dtb
> >>>   > >> > only if CONFIG_OF_BOARD is defined. This allows
> >> using a
> >>>   > different
> >>>   > >> > device tree, using the CONFIG_OF_SEPARATE option.
> >>>  This dtb
> >>>   > is attached
> >>>   > >> > to the u-boot binary as a u-boot-fdt.bin file
> >>>   > >>
> >>>   > >> Dear Sughosh,
> >>>   > >>
> >>>   > >> thank your for this series which will allow us to
> >> better
> >>>   > demonstrate and
> >>>   > >> test capsule updates.
> >>>   > >>
> >>>   > >> I am not sure if the approach that you take at
> >>>  device-trees
> >>>   > here is the
> >>>   > >> right one.
> >>>   > >>
> >>>   > >> On QEMU the device-tree is generated on the fly by
> the
> >>>  QEMU
> >>>   > binary
> >>>   > >> depending on which devices the user has specified.
> >>>   > >>
> >>>   > >> Your idea is to replace this device-tree completely
> to
> >> be
> >>>   > able to add
> >>>   > >> extra elements (the EFI signature list, see patch
> >>>  2/14). Thus a
> >>>   > >> device-tree might be loaded that does not match the
> >>>  user selected
> >>>   > >> devices.
> >>>   > >>
> >>>   > >> An alternative approach would be to apply all
> >>>  additions to the
> >>>   > >> device-tree as an FDT overlay (or fixup). This would
> >> allow
> >>>   > the dynamic
> >>>   > >> parts of the QEMU device-tree still to be passed
> >> through.
> >>>   > >>
> >>>   > >>
> >>>   > >> I will take a look at storing the public key as part of
> >>>  the fdt
> >>>   > overlay,
> >>>   > >> with a runtime fixup. Although, I think the issue that
> you
> >> are
> >>>   > pointing
> >>>   > >> to would be specific to Qemu and not other platforms.
> But
> >> I do
> >>>   > see the
> >>>   > >> merit in having the public-key certificate stored as
> part
> >>>  of an
> >>>   > overlay.
> >>>   > >> If I hit any issues while implementing this, I will get
> >>>  back to
> >>>   > you. Thanks.
> >>>   > >>
> >>>   > >> -sughosh
> >>>   > >
> >>>   > > OpenSBI can supply a device-tree to U-Boot. So this would
> >> be an
> >>>   > > equivalent case.
> >>>   > >
> >>>   > > Best regards
> >>>   > >
> >>>   > > Heinrich
> >>>   >
> >>>   > : "I am unable to think of a simple and elegant way
> to
> >>>  generate
> >>>   > the overlay dtb, since this would require creation of a
> >>>  corresponding
> >>>   > dts file, compiling it into a dtb and then using this on
> the
> >>>  platform."
> >>>   >
> >>>   > Jean-Jacques' patch series introduced some of the necessary
> >> code:
> >>>   >
> >>>   > [PATCH PATCH v6 00/13] Add support for applications of
> >>>  overlays in SPL
> >>>   >
> https://lists.denx.de/pipermail/u-boot/2019-October/387653.html
> >>>  
> >>>   >
> >>><
> https://lists.denx.de/pipermail/u-boot/2019-October/387653.html
> >>>   >>
> >>>   >
> >>>
> >>
> https://patchwork.ozlabs.org/project/uboot/list/?series