[PATCH] drivers: mmc: Reset watchdog when accessing mmc device

2022-07-13 Thread qianfanguijin
From: qianfan Zhao 

watchdog will reset when 'mmc read' or 'ext4load' a large file from mmc
device. Reset watchdog when accessing mmc device.

Signed-off-by: qianfan Zhao 
---
 drivers/mmc/mmc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 4d9871d69f..27ffdb7fa7 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "mmc_private.h"
 
 #define DEFAULT_CMD6_TIMEOUT_MS  500
@@ -297,6 +298,7 @@ int mmc_poll_for_busy(struct mmc *mmc, int timeout_ms)
if (timeout_ms-- <= 0)
break;
 
+   WATCHDOG_RESET();
udelay(1000);
}
 
@@ -500,6 +502,8 @@ ulong mmc_bread(struct blk_desc *block_dev, lbaint_t start, 
lbaint_t blkcnt,
blocks_todo -= cur;
start += cur;
dst += cur * mmc->read_bl_len;
+
+   WATCHDOG_RESET();
} while (blocks_todo > 0);
 
return blkcnt;
-- 
2.25.1



[PULL] Pull request for u-boot next / v2022.10 = u-boot-stm32-20220712

2022-07-13 Thread Patrick DELAUNAY

I Tom,

Please pull the STM32 related fixes for u-boot/next, v2022.10: 
u-boot-stm32-20220712


- Alignment with Linux kernel device tree v5.19 for stm32mp15 and stm32mp13
- Add OP-TEE nodes for stm32mp13x, aligned with upstreamed OP-TEE
- Introduce of_to_plat ops in stm32_sdmmc2 driver
- Activate more features in stm32mp13 defconfig and support of 
STM32MP13x Rev.Y

- Drop fastboot and stm32prog trigger gpios on STM32MP15x DHCOM board

CI status: 
https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/12721


Thanks,
Patrick

git request-pull origin/next 
https://source.denx.de/u-boot/custodians/u-boot-stm.git/ 
u-boot-stm32-20220712



The following changes since commit 05a4859637567b13219efd6f1707fb236648b1b7:

  Merge branch '2022-07-08-Kconfig-migrations' into next (2022-07-08 
18:03:08 -0400)


are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-stm.git/ 
tags/u-boot-stm32-20220712


for you to fetch changes up to 48d9eaf6826a1816c5f9839a564ea6338da609a7:

  arm: dts: stm32mp1: Drop fastboot and stm32prog trigger gpios on 
DHCOM (2022-07-12 11:48:15 +0200)



- Alignment with Linux kernel device tree v5.19 for stm32mp15 and stm32mp13
- Add OP-TEE nodes for stm32mp13x, alligned with upstreamed OP-TEE
- Introduce of_to_plat ops in stm32_sdmmc2 driver
- Activate more features in stm32mp13 defconfig and support of 
STM32MP13x Rev.Y

- Drop fastboot and stm32prog trigger gpios on STM32MP15x DHCOM board


Johann Neuhauser (1):
  arm: dts: stm32mp1: Drop fastboot and stm32prog trigger gpios on 
DHCOM


Lionel Debieve (1):
  rng: stm32mp1_rng: add conditional reset feature for STM32MP13x

Patrick Delaunay (19):
  configs: stm32m15: support STM32MP_BOARD_EXTRA_ENV for st boards
  ARM: dts: stm32mp13: add OP-TEE nodes
  ARM: dts: stm32mp13: add SCMI nodes
  mmc: stm32_sdmmc2: cosmetic: rename stm32_sdmmc_bind
  mmc: stm32_sdmmc2: remove privdata
  mmc: stm32_sdmmc2: introduce of_to_plat ops
  ARM: dts: stm32mp15: alignment with v5.19
  clk: stm32: add support compatible st, stm32mp1-rcc-secure
  configs: stm32mp15: increase malloc size for pre-reloc
  ARM: dts: stm32: add SCMI version of STM32 boards (DK1/DK2/ED1/EV1)
  i2c: stm32: add support for the st,stm32mp13 SOC
  stm32mp: add support of STM32MP13x Rev.Y
  ARM: dts: stm32mp13: alignment with v5.19
  ARM: dts: stm32mp13: activate led on STM32MP13F-DK
  configs: stm32mp13: Add support for baudrates higher than 115200
  configs: stm32mp13: activate RNG support
  configs: stm32mp13: activate RTC support
  configs: stm32mp13: activate I2C support
  configs: stm32mp13: activate some command

 arch/arm/dts/Makefile  |   4 ++
 arch/arm/dts/stm32mp13-u-boot.dtsi |  24 +
 arch/arm/dts/stm32mp131.dtsi   |  57 
+-

 arch/arm/dts/stm32mp135f-dk-u-boot.dtsi    |  10 
 arch/arm/dts/stm32mp135f-dk.dts    |  40 +++
 arch/arm/dts/stm32mp15-pinctrl.dtsi    |  64 

 arch/arm/dts/stm32mp15-scmi-u-boot.dtsi    | 167 
++
 arch/arm/dts/stm32mp15-scmi.dtsi   | 109 
+

 arch/arm/dts/stm32mp151.dtsi   |  10 ++--
 arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi  |  57 
++
 arch/arm/dts/stm32mp157a-dk1-scmi.dts  |  79 
++

 arch/arm/dts/stm32mp157c-dk2-scmi-u-boot.dtsi  |   6 +++
 arch/arm/dts/stm32mp157c-dk2-scmi.dts  |  85 


 arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi  |  47 ++
 arch/arm/dts/stm32mp157c-ed1-scmi.dts  |  84 


 arch/arm/dts/stm32mp157c-ev1-scmi-u-boot.dtsi  |  17 +++
 arch/arm/dts/stm32mp157c-ev1-scmi.dts  |  90 
++

 arch/arm/dts/stm32mp157c-ev1.dts   |   4 +-
 arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi |   2 -
 arch/arm/mach-stm32mp/include/mach/sys_proto.h |   1 +
 arch/arm/mach-stm32mp/stm32mp13x.c |   3 ++
 configs/stm32mp13_defconfig    |  24 +
 configs/stm32mp15_defconfig    |   2 +-
 doc/board/st/stm32mp1.rst  |  19 
 drivers/i2c/stm32f7_i2c.c  |   5 ++
 drivers/misc/stm32_rcc.c   |   1 +
 drivers/mmc/stm32_sdmmc2.c | 224 
++--
 drivers/rng/stm32mp1_rng.c |  61 
+--

 include/configs/stm32mp13_st_common.h  |   5 ++
 include/configs/stm32mp15_st_common.h 

Re: [PATCH 2/2] Nokia RX-51: Remove CONFIG_PREBOOT from defconfig

2022-07-13 Thread Pali Rohár
On Tuesday 12 July 2022 19:15:45 Tom Rini wrote:
> On Wed, Jul 13, 2022 at 01:11:35AM +0200, Pali Rohár wrote:
> > On Tuesday 12 July 2022 18:58:31 Tom Rini wrote:
> [snip]
> > > It really isn't, that's why the plain text environment stuff is a good
> > > step in the right direction.  What I'm not sure about how to best handle
> > > is making it easy for a user, rather than developer, to override
> > > environment values too.  What I mean he
> > 
> > Maybe the important question is: Why is needed CONFIG_PREBOOT define at
> > all? Why it is not enough just to set preboot= env variable? And same
> > questions for all other CONFIG_ options.
> 
> I'm sorry if this sounds snarky, I don't intend it to.  But, size.
> Maybe that doesn't matter so much these days for the size savings on
> run_preboot_environment_command().

Size is really a good argument.

> > > > For all this stuff is needed some stronger tool/language than Kconfig,
> > > > e.g. C preprocessor (like it was before in config.h) or any similar
> > > > stronger macro language (e.g. m4) or script languages (shell / python).
> > > 
> > > Yes, so, take a look at 5c3f6a320678d64c9fa0c42755488822a033b567 as an
> > > example of moving a board away from board config.h and to something
> > > else.  What I'm not sure on is how to best handle preboot in this case
> > > as I'm not quite liking "Enable CONFIG_PREBOOT and then edit
> > > .../boardname.env to set preboot to the right value".
> > > 
> > > -- 
> > > Tom
> > 
> > With that commit, all env variables are moved into separate file. This
> > file can be parsed by other tools and at compile it is possible to
> > extract current value of preboot= env variable or check if preboot= is
> > defined. Cannot be by this logic automatically defined/expanded
> > CONFIG_PREBOOT symbol? Of course, it would not be Kconfig symbol
> > anymore.
> 
> That sounds interesting.
> 
> -- 
> Tom

And this solve also issue with size (if we can determinate at compile
time if preboot= env is defined or not).


[PATCH 00/14] imx: kontron-sl-mx8mm: Improvements and OSM board support

2022-07-13 Thread Frieder Schrempf
From: Frieder Schrempf 

This set contains several improvements for the kontron-sl-mx8mm board
configuration (patches 1 to 13) and support for a new SoM (patch 14,
including baseboard) that complies to the Open Standard Module (OSM) 1.0
hardware specification, size S (https://sget.org/standards/osm).

Frieder Schrempf (14):
  imx: kontron-sl-mx8mm: Remove LVDS board type and devicetrees
  imx: kontron-sl-mx8mm: Add redundant environment
  imx: kontron-sl-mx8mm: Enable environment in MMC
  imx: kontron-sl-mx8mm: Migrate to use CONFIG_EXTRA_ENV_TEXT
  imx: kontron-sl-mx8mm: Enable bootaux command
  imx: kontron-sl-mx8mm: lpddr4_timing.c: Add spaces for proper
alignment
  imx: kontron-sl-mx8mm: Remove 100mt DDR setpoint
  imx: kontron-sl-mx8mm: Use new LPDDR4 config parameters
  imx: kontron-sl-mx8mm: Prepare for other i.MX8MM SoM types
  imx: kontron-sl-mx8mm: Adjust board and SoM model strings
  imx: kontron-sl-mx8mm: Use the VSELECT signal to switch SD card IO
voltage
  imx: kontron-sl-mx8mm: Use voltage rail names from schematic for PMIC
regulator-names
  imx: kontron-sl-mx8mm: Simplify code in spl.c
  imx: kontron-sl-mx8mm: Add support for Kontron Electronics SoM SL
i.MX8MM OSM-S

 arch/arm/dts/Makefile |1 -
 .../imx8mm-kontron-n801x-s-lvds-u-boot.dtsi   |6 -
 arch/arm/dts/imx8mm-kontron-n801x-s-lvds.dts  |  116 -
 .../dts/imx8mm-kontron-n801x-s-u-boot.dtsi|7 +-
 arch/arm/dts/imx8mm-kontron-n801x-s.dts   |5 +-
 arch/arm/dts/imx8mm-kontron-n801x-som.dtsi|   30 +-
 .../dts/imx8mm-kontron-n802x-s-u-boot.dtsi|6 +
 arch/arm/dts/imx8mm-kontron-n802x-s.dts   |  376 
 arch/arm/dts/imx8mm-kontron-n802x-som.dtsi|  309 +++
 ...tsi => imx8mm-kontron-n80xx-s-u-boot.dtsi} |8 +-
 board/kontron/sl-mx8mm/MAINTAINERS|1 +
 board/kontron/sl-mx8mm/lpddr4_timing.c| 1969 -
 board/kontron/sl-mx8mm/sl-mx8mm.c |   41 +
 board/kontron/sl-mx8mm/sl-mx8mm.env   |7 +
 board/kontron/sl-mx8mm/spl.c  |   85 +-
 configs/kontron-sl-mx8mm_defconfig|   10 +-
 doc/board/kontron/sl-mx8mm.rst|7 +-
 include/configs/kontron-sl-mx8mm.h|   16 +-
 18 files changed, 1717 insertions(+), 1283 deletions(-)
 delete mode 100644 arch/arm/dts/imx8mm-kontron-n801x-s-lvds-u-boot.dtsi
 delete mode 100644 arch/arm/dts/imx8mm-kontron-n801x-s-lvds.dts
 create mode 100644 arch/arm/dts/imx8mm-kontron-n802x-s-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mm-kontron-n802x-s.dts
 create mode 100644 arch/arm/dts/imx8mm-kontron-n802x-som.dtsi
 rename arch/arm/dts/{imx8mm-kontron-n801x-u-boot.dtsi => 
imx8mm-kontron-n80xx-s-u-boot.dtsi} (88%)
 create mode 100644 board/kontron/sl-mx8mm/sl-mx8mm.env

-- 
2.37.0



[PATCH 01/14] imx: kontron-sl-mx8mm: Remove LVDS board type and devicetrees

2022-07-13 Thread Frieder Schrempf
From: Frieder Schrempf 

The display isn't and won't be used in U-Boot. Also the display setup
is not yet supported in mainline Linux, so even for cases where the
U-Boot devicetree is passed to the kernel there is currently no use
for this configuration.

Selecting the proper configuration in the kernel FIT image automatically
depending on the detected hardware can be handled by a script in the
environment.

Signed-off-by: Frieder Schrempf 
---
 arch/arm/dts/Makefile |   1 -
 .../imx8mm-kontron-n801x-s-lvds-u-boot.dtsi   |   6 -
 arch/arm/dts/imx8mm-kontron-n801x-s-lvds.dts  | 116 --
 .../dts/imx8mm-kontron-n801x-s-u-boot.dtsi| 140 -
 arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi | 145 --
 board/kontron/sl-mx8mm/spl.c  |  46 +-
 configs/kontron-sl-mx8mm_defconfig|   1 -
 7 files changed, 141 insertions(+), 314 deletions(-)
 delete mode 100644 arch/arm/dts/imx8mm-kontron-n801x-s-lvds-u-boot.dtsi
 delete mode 100644 arch/arm/dts/imx8mm-kontron-n801x-s-lvds.dts
 delete mode 100644 arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index c2435d8cba4..41d2238b6ec 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -938,7 +938,6 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mm-icore-mx8mm-ctouch2.dtb \
imx8mm-icore-mx8mm-edimm2.2.dtb \
imx8mm-kontron-n801x-s.dtb \
-   imx8mm-kontron-n801x-s-lvds.dtb \
imx8mm-mx8menlo.dtb \
imx8mm-venice.dtb \
imx8mm-venice-gw71xx-0x.dtb \
diff --git a/arch/arm/dts/imx8mm-kontron-n801x-s-lvds-u-boot.dtsi 
b/arch/arm/dts/imx8mm-kontron-n801x-s-lvds-u-boot.dtsi
deleted file mode 100644
index 4bf75722bfb..000
--- a/arch/arm/dts/imx8mm-kontron-n801x-s-lvds-u-boot.dtsi
+++ /dev/null
@@ -1,6 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2019 Kontron Electronics GmbH
- */
-
-#include "imx8mm-kontron-n801x-u-boot.dtsi"
diff --git a/arch/arm/dts/imx8mm-kontron-n801x-s-lvds.dts 
b/arch/arm/dts/imx8mm-kontron-n801x-s-lvds.dts
deleted file mode 100644
index dd1addea708..000
--- a/arch/arm/dts/imx8mm-kontron-n801x-s-lvds.dts
+++ /dev/null
@@ -1,116 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Copyright (C) 2019 Kontron Electronics GmbH
- */
-
-#include "imx8mm-kontron-n801x-s.dts"
-
-/ {
-   model = "Kontron i.MX8MM N801X S LVDS";
-   compatible = "kontron,imx8mm-n801x-s-lvds", "fsl,imx8mm";
-
-   backlight: backlight {
-   compatible = "pwm-backlight";
-   pwms = <&pwm1 0 5>; /* period = 500 ns => f = 200 Hz */
-   power-supply = <®_vdd_24v>;
-   brightness-levels = <0 100>;
-   num-interpolated-steps = <100>;
-   default-brightness-level = <100>;
-   status = "okay";
-   };
-
-   reg_panel_pwr: regpanel-pwr {
-   compatible = "regulator-fixed";
-   regulator-name = "reg_panel_pwr";
-   regulator-always-on;
-   gpio = <&gpio3 19 GPIO_ACTIVE_HIGH>;
-   enable-active-high;
-   };
-
-   reg_panel_rst: regpanel-rst {
-   compatible = "regulator-fixed";
-   regulator-name = "reg_panel_rst";
-   regulator-always-on;
-   gpio = <&gpio3 20 GPIO_ACTIVE_HIGH>;
-   enable-active-high;
-   };
-
-   reg_panel_stby: regpanel-stby {
-   compatible = "regulator-fixed";
-   regulator-name = "reg_panel_stby";
-   regulator-always-on;
-   gpio = <&gpio3 21 GPIO_ACTIVE_HIGH>;
-   enable-active-high;
-   };
-
-   reg_panel_hinv: regpanel-hinv {
-   compatible = "regulator-fixed";
-   regulator-name = "reg_panel_hinv";
-   regulator-always-on;
-   gpio = <&gpio3 24 GPIO_ACTIVE_HIGH>;
-   enable-active-high;
-   };
-
-   reg_panel_vinv: regpanel-vinv {
-   compatible = "regulator-fixed";
-   regulator-name = "reg_panel_vinv";
-   gpio = <&gpio3 25 GPIO_ACTIVE_HIGH>;
-   enable-active-high;
-   };
-
-   reg_vdd_24v: regulator-24v {
-   compatible = "regulator-fixed";
-   regulator-name = "reg-vdd-24v";
-   regulator-min-microvolt = <2400>;
-   regulator-max-microvolt = <2400>;
-   regulator-boot-on;
-   regulator-always-on;
-   status = "okay";
-   };
-};
-
-&i2c2 {
-   status = "okay";
-
-   gt911@5d {
-   compatible = "goodix,gt928";
-   reg = <0x5d>;
-   pinctrl-names = "default";
-   pinctrl-0 = <&pinctrl_touch>;
-   interrupt-parent = <&gpio3>;
-   interrupts = <22 8>;
-   reset-gpios = <&gpio3 23 0>;
-   irq-gpios = <&gpio3 

[PATCH 02/14] imx: kontron-sl-mx8mm: Add redundant environment

2022-07-13 Thread Frieder Schrempf
From: Frieder Schrempf 

Enable the redundant environment feature to allow falling
back in case of storage corruption.

Signed-off-by: Frieder Schrempf 
---
 configs/kontron-sl-mx8mm_defconfig | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/configs/kontron-sl-mx8mm_defconfig 
b/configs/kontron-sl-mx8mm_defconfig
index 7d65b5c2edc..064f7d0caf6 100644
--- a/configs/kontron-sl-mx8mm_defconfig
+++ b/configs/kontron-sl-mx8mm_defconfig
@@ -6,7 +6,7 @@ CONFIG_SPL_GPIO=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_ENV_SIZE=0x1
-CONFIG_ENV_OFFSET=0x1f
+CONFIG_ENV_OFFSET=0x15
 CONFIG_ENV_SECT_SIZE=0x1
 CONFIG_IMX_CONFIG="board/kontron/sl-mx8mm/imximage.cfg"
 CONFIG_DM_GPIO=y
@@ -19,6 +19,7 @@ CONFIG_SPL_SERIAL=y
 CONFIG_SPL_DRIVERS_MISC=y
 CONFIG_BOOTCOUNT_BOOTLIMIT=3
 CONFIG_SPL=y
+CONFIG_ENV_OFFSET_REDUND=0x16
 CONFIG_SYS_LOAD_ADDR=0x4200
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_FIT=y
@@ -65,9 +66,11 @@ CONFIG_CMD_TIME=y
 CONFIG_CMD_PMIC=y
 CONFIG_CMD_REGULATOR=y
 CONFIG_CMD_EXT4_WRITE=y
+CONFIG_MTDPARTS_DEFAULT="mtdparts=spi0.0:320k(spl),1024k(u-boot),64k(env),64k(env_redundant)"
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_DM=y
-- 
2.37.0



[PATCH 03/14] imx: kontron-sl-mx8mm: Enable environment in MMC

2022-07-13 Thread Frieder Schrempf
From: Frieder Schrempf 

In case we boot from SD card or eMMC, we also want to load
the environment from the according boot device.

Signed-off-by: Frieder Schrempf 
---
 board/kontron/sl-mx8mm/sl-mx8mm.c  | 31 ++
 configs/kontron-sl-mx8mm_defconfig |  1 +
 2 files changed, 32 insertions(+)

diff --git a/board/kontron/sl-mx8mm/sl-mx8mm.c 
b/board/kontron/sl-mx8mm/sl-mx8mm.c
index fea93278374..416c4cbb407 100644
--- a/board/kontron/sl-mx8mm/sl-mx8mm.c
+++ b/board/kontron/sl-mx8mm/sl-mx8mm.c
@@ -4,10 +4,13 @@
  */
 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -117,3 +120,31 @@ int board_init(void)
 {
return 0;
 }
+
+enum env_location env_get_location(enum env_operation op, int prio)
+{
+   enum boot_device boot_dev = get_boot_device();
+
+   if (prio)
+   return ENVL_UNKNOWN;
+
+   /*
+* Make sure that the environment is loaded from
+* the MMC if we are running from SD card or eMMC.
+*/
+   if (CONFIG_IS_ENABLED(ENV_IS_IN_MMC) &&
+   (boot_dev == SD1_BOOT || boot_dev == SD2_BOOT))
+   return ENVL_MMC;
+
+   if (CONFIG_IS_ENABLED(ENV_IS_IN_SPI_FLASH))
+   return ENVL_SPI_FLASH;
+
+   return ENVL_NOWHERE;
+}
+
+#if defined(CONFIG_ENV_IS_IN_MMC)
+int board_mmc_get_env_dev(int devno)
+{
+   return devno;
+}
+#endif
diff --git a/configs/kontron-sl-mx8mm_defconfig 
b/configs/kontron-sl-mx8mm_defconfig
index 064f7d0caf6..e6b5c8f800a 100644
--- a/configs/kontron-sl-mx8mm_defconfig
+++ b/configs/kontron-sl-mx8mm_defconfig
@@ -69,6 +69,7 @@ CONFIG_CMD_EXT4_WRITE=y
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=spi0.0:320k(spl),1024k(u-boot),64k(env),64k(env_redundant)"
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
+CONFIG_ENV_IS_IN_MMC=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
-- 
2.37.0



[PATCH 05/14] imx: kontron-sl-mx8mm: Enable bootaux command

2022-07-13 Thread Frieder Schrempf
From: Frieder Schrempf 

Enable the bootaux command in order to be able to load a
binary into the M4 core when needed.

Signed-off-by: Frieder Schrempf 
---
 configs/kontron-sl-mx8mm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/kontron-sl-mx8mm_defconfig 
b/configs/kontron-sl-mx8mm_defconfig
index e6b5c8f800a..d9cacb2d809 100644
--- a/configs/kontron-sl-mx8mm_defconfig
+++ b/configs/kontron-sl-mx8mm_defconfig
@@ -20,6 +20,7 @@ CONFIG_SPL_DRIVERS_MISC=y
 CONFIG_BOOTCOUNT_BOOTLIMIT=3
 CONFIG_SPL=y
 CONFIG_ENV_OFFSET_REDUND=0x16
+CONFIG_IMX_BOOTAUX=y
 CONFIG_SYS_LOAD_ADDR=0x4200
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_FIT=y
-- 
2.37.0



[PATCH 04/14] imx: kontron-sl-mx8mm: Migrate to use CONFIG_EXTRA_ENV_TEXT

2022-07-13 Thread Frieder Schrempf
From: Frieder Schrempf 

Move the environment from the board header to a separate text file
and also drop those variables that are already set in env_default.h
from the Kconfig options.

Signed-off-by: Frieder Schrempf 
---
 board/kontron/sl-mx8mm/sl-mx8mm.env |  7 +++
 include/configs/kontron-sl-mx8mm.h  | 16 +---
 2 files changed, 8 insertions(+), 15 deletions(-)
 create mode 100644 board/kontron/sl-mx8mm/sl-mx8mm.env

diff --git a/board/kontron/sl-mx8mm/sl-mx8mm.env 
b/board/kontron/sl-mx8mm/sl-mx8mm.env
new file mode 100644
index 000..ef6fc1f3428
--- /dev/null
+++ b/board/kontron/sl-mx8mm/sl-mx8mm.env
@@ -0,0 +1,7 @@
+kernel_addr_r=0x4200
+fdt_addr_r=0x4800
+fdtoverlay_addr_r=0x4900
+ramdisk_addr_r=0x4808
+scriptaddr=0x4000
+pxefile_addr_r=0x4010
+dfu_alt_info=sf 0:0=flash-bin raw 0x400 0x1f
diff --git a/include/configs/kontron-sl-mx8mm.h 
b/include/configs/kontron-sl-mx8mm.h
index 622ab597624..a2aedefcec2 100644
--- a/include/configs/kontron-sl-mx8mm.h
+++ b/include/configs/kontron-sl-mx8mm.h
@@ -50,20 +50,6 @@
 #define CONFIG_MALLOC_F_ADDR   0x93
 #endif
 
-#define ENV_MEM_LAYOUT_SETTINGS \
-   "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
-   "kernel_addr_r=0x4200\0" \
-   "fdt_addr_r=0x4800\0" \
-   "fdtoverlay_addr_r=0x4900\0" \
-   "ramdisk_addr_r=0x4808\0" \
-   "scriptaddr=0x4000\0"\
-   "pxefile_addr_r=0x4010\0"
-
-#define CONFIG_EXTRA_ENV_SETTINGS \
-   "dfu_alt_info=sf 0:0=flash-bin raw 0x400 0x1f\0" \
-   "bootdelay=3\0" \
-   "hostname=" CONFIG_HOSTNAME "\0" \
-   ENV_MEM_LAYOUT_SETTINGS \
-   BOOTENV
+#define CONFIG_EXTRA_ENV_SETTINGS BOOTENV
 
 #endif /* __KONTRON_MX8MM_CONFIG_H */
-- 
2.37.0



[PATCH 07/14] imx: kontron-sl-mx8mm: Remove 100mt DDR setpoint

2022-07-13 Thread Frieder Schrempf
From: Frieder Schrempf 

The new stable configuration is missing the 100mt setpoint, remove
it before updating the config to make sure the changes are separated
cleanly.

Signed-off-by: Frieder Schrempf 
---
 arch/arm/dts/imx8mm-kontron-n801x-som.dtsi |  4 --
 board/kontron/sl-mx8mm/lpddr4_timing.c | 49 +-
 board/kontron/sl-mx8mm/spl.c   |  2 -
 3 files changed, 1 insertion(+), 54 deletions(-)

diff --git a/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi 
b/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi
index 8f90eb02550..7e80008da29 100644
--- a/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi
+++ b/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi
@@ -46,10 +46,6 @@
ddrc_opp_table: opp-table {
compatible = "operating-points-v2";
 
-   opp-25M {
-   opp-hz = /bits/ 64 <2500>;
-   };
-
opp-100M {
opp-hz = /bits/ 64 <1>;
};
diff --git a/board/kontron/sl-mx8mm/lpddr4_timing.c 
b/board/kontron/sl-mx8mm/lpddr4_timing.c
index a8dcaafb180..cdde6ac0dc0 100644
--- a/board/kontron/sl-mx8mm/lpddr4_timing.c
+++ b/board/kontron/sl-mx8mm/lpddr4_timing.c
@@ -1121,46 +1121,6 @@ struct dram_cfg_param ddr_fsp1_cfg[] = {
{ 0xd, 0x1 },
 };
 
-/* P2 message block paremeter for training firmware */
-struct dram_cfg_param ddr_fsp2_cfg[] = {
-   { 0xd, 0x0 },
-   { 0x54002, 0x102 },
-   { 0x54003, 0x64 },
-   { 0x54004, 0x2 },
-   { 0x54005, 0x2228 },
-   { 0x54006, 0x11 },
-   { 0x54008, 0x121f },
-   { 0x54009, 0xc8 },
-   { 0x5400b, 0x2 },
-   { 0x5400d, 0x100 },
-   { 0x54012, 0x310 },
-   { 0x54019, 0x84 },
-   { 0x5401a, 0x31 },
-   { 0x5401b, 0x4d66 },
-   { 0x5401c, 0x4d00 },
-   { 0x5401e, 0x16 },
-   { 0x5401f, 0x84 },
-   { 0x54020, 0x31 },
-   { 0x54021, 0x4d66 },
-   { 0x54022, 0x4d00 },
-   { 0x54024, 0x16 },
-   { 0x5402b, 0x1000 },
-   { 0x5402c, 0x3 },
-   { 0x54032, 0x8400 },
-   { 0x54033, 0x3100 },
-   { 0x54034, 0x6600 },
-   { 0x54035, 0x4d },
-   { 0x54036, 0x4d },
-   { 0x54037, 0x1600 },
-   { 0x54038, 0x8400 },
-   { 0x54039, 0x3100 },
-   { 0x5403a, 0x6600 },
-   { 0x5403b, 0x4d },
-   { 0x5403c, 0x4d },
-   { 0x5403d, 0x1600 },
-   { 0xd, 0x1 },
-};
-
 /* P0 2D message block paremeter for training firmware */
 struct dram_cfg_param ddr_fsp0_2d_cfg[] = {
{ 0xd, 0x0 },
@@ -1812,13 +1772,6 @@ struct dram_fsp_msg ddr_dram_fsp_msg[] = {
.fsp_cfg = ddr_fsp1_cfg,
.fsp_cfg_num = ARRAY_SIZE(ddr_fsp1_cfg),
},
-   {
-   /* P2 100mts 1D */
-   .drate = 100,
-   .fw_type = FW_1D_IMAGE,
-   .fsp_cfg = ddr_fsp2_cfg,
-   .fsp_cfg_num = ARRAY_SIZE(ddr_fsp2_cfg),
-},
{
/* P0 3000mts 2D */
.drate = 3000,
@@ -1840,5 +1793,5 @@ struct dram_timing_info dram_timing = {
.ddrphy_trained_csr_num = ARRAY_SIZE(ddr_ddrphy_trained_csr),
.ddrphy_pie = ddr_phy_pie,
.ddrphy_pie_num = ARRAY_SIZE(ddr_phy_pie),
-   .fsp_table = { 3000, 400, 100, },
+   .fsp_table = { 3000, 400, },
 };
diff --git a/board/kontron/sl-mx8mm/spl.c b/board/kontron/sl-mx8mm/spl.c
index c379d37f1e8..8464e782e49 100644
--- a/board/kontron/sl-mx8mm/spl.c
+++ b/board/kontron/sl-mx8mm/spl.c
@@ -95,8 +95,6 @@ static void spl_dram_init(void)
dram_timing.fsp_msg[1].fsp_cfg[22].val = 0x1;
dram_timing.fsp_msg[2].fsp_cfg[10].val = 0x110;
dram_timing.fsp_msg[2].fsp_cfg[22].val = 0x1;
-   dram_timing.fsp_msg[3].fsp_cfg[10].val = 0x110;
-   dram_timing.fsp_msg[3].fsp_cfg[22].val = 0x1;
 
if (!ddr_init(&dram_timing)) {
if (check_ram_available(SZ_2G))
-- 
2.37.0



[PATCH 08/14] imx: kontron-sl-mx8mm: Use new LPDDR4 config parameters

2022-07-13 Thread Frieder Schrempf
From: Frieder Schrempf 

These parameters are needed for stable performance on new hardware
with Nanya LPDDR4 chips.

Signed-off-by: Frieder Schrempf 
---
 board/kontron/sl-mx8mm/lpddr4_timing.c | 184 +++--
 board/kontron/sl-mx8mm/spl.c   |   8 +-
 2 files changed, 55 insertions(+), 137 deletions(-)

diff --git a/board/kontron/sl-mx8mm/lpddr4_timing.c 
b/board/kontron/sl-mx8mm/lpddr4_timing.c
index cdde6ac0dc0..74b79c7a009 100644
--- a/board/kontron/sl-mx8mm/lpddr4_timing.c
+++ b/board/kontron/sl-mx8mm/lpddr4_timing.c
@@ -15,13 +15,13 @@ struct dram_cfg_param ddr_ddrc_cfg[] = {
{ 0x3d40, 0xa3080020 },
{ 0x3d400020, 0x223 },
{ 0x3d400024, 0x3a980 },
-   { 0x3d400064, 0x5b0087 },
+   { 0x3d400064, 0x5b00d2 },
{ 0x3d4000d0, 0xc00305ba },
{ 0x3d4000d4, 0x94 },
{ 0x3d4000dc, 0xd4002d },
{ 0x3d4000e0, 0x31 },
-   { 0x3d4000e8, 0x66004d },
-   { 0x3d4000ec, 0x16004d },
+   { 0x3d4000e8, 0x63004d },
+   { 0x3d4000ec, 0x15004d },
{ 0x3d400100, 0x191e1920 },
{ 0x3d400104, 0x60630 },
{ 0x3d40010c, 0xb0b000 },
@@ -88,30 +88,7 @@ struct dram_cfg_param ddr_ddrc_cfg[] = {
{ 0x3d402190, 0x3818200 },
{ 0x3d402194, 0x80303 },
{ 0x3d4021b4, 0x100 },
-   { 0x3d403020, 0x21 },
-   { 0x3d403024, 0x1f40 },
-   { 0x3d403050, 0x20d040 },
-   { 0x3d403064, 0x30007 },
-   { 0x3d4030dc, 0x84 },
-   { 0x3d4030e0, 0x31 },
-   { 0x3d4030e8, 0x66004d },
-   { 0x3d4030ec, 0x16004d },
-   { 0x3d403100, 0xa010102 },
-   { 0x3d403104, 0x30404 },
-   { 0x3d403108, 0x203060b },
-   { 0x3d40310c, 0x505000 },
-   { 0x3d403110, 0x2040202 },
-   { 0x3d403114, 0x2030202 },
-   { 0x3d403118, 0x1010004 },
-   { 0x3d40311c, 0x301 },
-   { 0x3d403130, 0x20300 },
-   { 0x3d403134, 0xa12 },
-   { 0x3d403138, 0x8 },
-   { 0x3d403144, 0x50003 },
-   { 0x3d403180, 0x190004 },
-   { 0x3d403190, 0x3818200 },
-   { 0x3d403194, 0x80303 },
-   { 0x3d4031b4, 0x100 },
+   { 0x3d4020f4, 0xc99 },
{ 0x3d400028, 0x0 },
 };
 
@@ -165,14 +142,6 @@ struct dram_cfg_param ddr_ddrphy_cfg[] = {
{ 0x11215f, 0x1ff },
{ 0x11305f, 0x1ff },
{ 0x11315f, 0x1ff },
-   { 0x21005f, 0x1ff },
-   { 0x21015f, 0x1ff },
-   { 0x21105f, 0x1ff },
-   { 0x21115f, 0x1ff },
-   { 0x21205f, 0x1ff },
-   { 0x21215f, 0x1ff },
-   { 0x21305f, 0x1ff },
-   { 0x21315f, 0x1ff },
{ 0x55, 0x1ff },
{ 0x1055, 0x1ff },
{ 0x2055, 0x1ff },
@@ -185,22 +154,16 @@ struct dram_cfg_param ddr_ddrphy_cfg[] = {
{ 0x9055, 0x1ff },
{ 0x200c5, 0x19 },
{ 0x1200c5, 0x7 },
-   { 0x2200c5, 0x7 },
{ 0x2002e, 0x2 },
{ 0x12002e, 0x2 },
-   { 0x22002e, 0x2 },
{ 0x90204, 0x0 },
{ 0x190204, 0x0 },
-   { 0x290204, 0x0 },
{ 0x20024, 0x1ab },
{ 0x2003a, 0x0 },
{ 0x120024, 0x1ab },
{ 0x2003a, 0x0 },
-   { 0x220024, 0x1ab },
-   { 0x2003a, 0x0 },
{ 0x20056, 0x3 },
{ 0x120056, 0x3 },
-   { 0x220056, 0x3 },
{ 0x1004d, 0xe00 },
{ 0x1014d, 0xe00 },
{ 0x1104d, 0xe00 },
@@ -217,54 +180,37 @@ struct dram_cfg_param ddr_ddrphy_cfg[] = {
{ 0x11214d, 0xe00 },
{ 0x11304d, 0xe00 },
{ 0x11314d, 0xe00 },
-   { 0x21004d, 0xe00 },
-   { 0x21014d, 0xe00 },
-   { 0x21104d, 0xe00 },
-   { 0x21114d, 0xe00 },
-   { 0x21204d, 0xe00 },
-   { 0x21214d, 0xe00 },
-   { 0x21304d, 0xe00 },
-   { 0x21314d, 0xe00 },
-   { 0x10049, 0xeba },
-   { 0x10149, 0xeba },
-   { 0x11049, 0xeba },
-   { 0x11149, 0xeba },
-   { 0x12049, 0xeba },
-   { 0x12149, 0xeba },
-   { 0x13049, 0xeba },
-   { 0x13149, 0xeba },
-   { 0x110049, 0xeba },
-   { 0x110149, 0xeba },
-   { 0x111049, 0xeba },
-   { 0x49, 0xeba },
-   { 0x112049, 0xeba },
-   { 0x112149, 0xeba },
-   { 0x113049, 0xeba },
-   { 0x113149, 0xeba },
-   { 0x210049, 0xeba },
-   { 0x210149, 0xeba },
-   { 0x211049, 0xeba },
-   { 0x211149, 0xeba },
-   { 0x212049, 0xeba },
-   { 0x212149, 0xeba },
-   { 0x213049, 0xeba },
-   { 0x213149, 0xeba },
-   { 0x43, 0x63 },
-   { 0x1043, 0x63 },
-   { 0x2043, 0x63 },
-   { 0x3043, 0x63 },
-   { 0x4043, 0x63 },
-   { 0x5043, 0x63 },
-   { 0x6043, 0x63 },
-   { 0x7043, 0x63 },
-   { 0x8043, 0x63 },
-   { 0x9043, 0x63 },
+   { 0x10049, 0x69a },
+   { 0x10149, 0x69a },
+   { 0x11049, 0x69a },
+   { 0x11149, 0x69a },
+   { 0x12049, 0x69a },
+   { 0x12149, 0x69a },
+   { 0x13049, 0x69a },
+   { 0x13149, 0x69a },
+   { 0x110049, 0x69a },
+   { 0x110149, 0x69a },
+   { 0x111049, 0x69a },
+   { 0x49, 0x69a },
+   { 0x112049, 0x

[PATCH 09/14] imx: kontron-sl-mx8mm: Prepare for other i.MX8MM SoM types

2022-07-13 Thread Frieder Schrempf
From: Frieder Schrempf 

This sets an env variable 'som_type' from the board code. It can
later be used by environment scripts, e. g. to select the proper
devicetree for the board.

Signed-off-by: Frieder Schrempf 
---
 board/kontron/sl-mx8mm/sl-mx8mm.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/board/kontron/sl-mx8mm/sl-mx8mm.c 
b/board/kontron/sl-mx8mm/sl-mx8mm.c
index 416c4cbb407..9cbae6add16 100644
--- a/board/kontron/sl-mx8mm/sl-mx8mm.c
+++ b/board/kontron/sl-mx8mm/sl-mx8mm.c
@@ -121,6 +121,12 @@ int board_init(void)
return 0;
 }
 
+int board_late_init(void)
+{
+   env_set("som_type", "n801x");
+   return 0;
+}
+
 enum env_location env_get_location(enum env_operation op, int prio)
 {
enum boot_device boot_dev = get_boot_device();
-- 
2.37.0



[PATCH 11/14] imx: kontron-sl-mx8mm: Use the VSELECT signal to switch SD card IO voltage

2022-07-13 Thread Frieder Schrempf
From: Frieder Schrempf 

It turns out that it is not necessary to declare the VSELECT signal as
GPIO and let the PMIC driver set it to a fixed high level. This switches
the voltage between 3.3V and 1.8V by setting the PMIC register for LDO5
accordingly.

Instead we can do it like other boards already do and simply mux the
VSELECT signal of the USDHC interface to the pin. This makes sure that
the correct voltage is selected by setting the PMIC's SD_VSEL input
to high or low accordingly.

Reported-by: Heiko Thiery 
Signed-off-by: Frieder Schrempf 
---
 arch/arm/dts/imx8mm-kontron-n801x-s-u-boot.dtsi | 5 -
 arch/arm/dts/imx8mm-kontron-n801x-s.dts | 3 +++
 arch/arm/dts/imx8mm-kontron-n801x-som.dtsi  | 2 --
 3 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/arch/arm/dts/imx8mm-kontron-n801x-s-u-boot.dtsi 
b/arch/arm/dts/imx8mm-kontron-n801x-s-u-boot.dtsi
index 2c62f05cec1..a42881d1a89 100644
--- a/arch/arm/dts/imx8mm-kontron-n801x-s-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-kontron-n801x-s-u-boot.dtsi
@@ -62,11 +62,6 @@
 
 &pinctrl_pmic {
u-boot,dm-spl;
-   fsl,pins = <
-   MX8MM_IOMUXC_GPIO1_IO00_GPIO1_IO0   0x141
-   /* Disable Pullup for SD_VSEL */
-   MX8MM_IOMUXC_GPIO1_IO04_GPIO1_IO4   0x41
-   >;
 };
 
 &pinctrl_uart3 {
diff --git a/arch/arm/dts/imx8mm-kontron-n801x-s.dts 
b/arch/arm/dts/imx8mm-kontron-n801x-s.dts
index cb8102bb8db..bc46426ad8f 100644
--- a/arch/arm/dts/imx8mm-kontron-n801x-s.dts
+++ b/arch/arm/dts/imx8mm-kontron-n801x-s.dts
@@ -321,6 +321,7 @@
MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0
MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0
MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO120x019
+   MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT  0x1d0
>;
};
 
@@ -333,6 +334,7 @@
MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4
MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4
MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO120x019
+   MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT  0x1d0
>;
};
 
@@ -345,6 +347,7 @@
MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6
MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6
MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO120x019
+   MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT  0x1d0
>;
};
 };
diff --git a/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi 
b/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi
index a981a6b4ac0..2d0661cce89 100644
--- a/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi
+++ b/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi
@@ -82,7 +82,6 @@
pinctrl-0 = <&pinctrl_pmic>;
interrupt-parent = <&gpio1>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-   sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
 
regulators {
reg_vdd_soc: BUCK1 {
@@ -225,7 +224,6 @@
pinctrl_pmic: pmicgrp {
fsl,pins = <
MX8MM_IOMUXC_GPIO1_IO00_GPIO1_IO0   0x141
-   MX8MM_IOMUXC_GPIO1_IO04_GPIO1_IO4   0x141
>;
};
 
-- 
2.37.0



[PATCH 06/14] imx: kontron-sl-mx8mm: lpddr4_timing.c: Add spaces for proper alignment

2022-07-13 Thread Frieder Schrempf
From: Frieder Schrempf 

Fix the spaces and alignment for easier tracking of changes and comparing
with configs generated by the tools.

Signed-off-by: Frieder Schrempf 
---
 board/kontron/sl-mx8mm/lpddr4_timing.c | 2076 
 1 file changed, 1038 insertions(+), 1038 deletions(-)

diff --git a/board/kontron/sl-mx8mm/lpddr4_timing.c 
b/board/kontron/sl-mx8mm/lpddr4_timing.c
index 0eabb160185..a8dcaafb180 100644
--- a/board/kontron/sl-mx8mm/lpddr4_timing.c
+++ b/board/kontron/sl-mx8mm/lpddr4_timing.c
@@ -10,313 +10,313 @@
 
 struct dram_cfg_param ddr_ddrc_cfg[] = {
/** Initialize DDRC registers **/
-   {0x3d400304, 0x1},
-   {0x3d400030, 0x1},
-   {0x3d40, 0xa3080020},
-   {0x3d400020, 0x223},
-   {0x3d400024, 0x3a980},
-   {0x3d400064, 0x5b0087},
-   {0x3d4000d0, 0xc00305ba},
-   {0x3d4000d4, 0x94},
-   {0x3d4000dc, 0xd4002d},
-   {0x3d4000e0, 0x31},
-   {0x3d4000e8, 0x66004d},
-   {0x3d4000ec, 0x16004d},
-   {0x3d400100, 0x191e1920},
-   {0x3d400104, 0x60630},
-   {0x3d40010c, 0xb0b000},
-   {0x3d400110, 0xe04080e},
-   {0x3d400114, 0x2040c0c},
-   {0x3d400118, 0x1010007},
-   {0x3d40011c, 0x401},
-   {0x3d400130, 0x20600},
-   {0x3d400134, 0xc12},
-   {0x3d400138, 0xd8},
-   {0x3d400144, 0x96004b},
-   {0x3d400180, 0x2ee0017},
-   {0x3d400184, 0x2605b8e},
-   {0x3d400188, 0x0},
-   {0x3d400190, 0x497820a},
-   {0x3d400194, 0x80303},
-   {0x3d4001b4, 0x170a},
-   {0x3d4001a0, 0xe0400018},
-   {0x3d4001a4, 0xdf00e4},
-   {0x3d4001a8, 0x8000},
-   {0x3d4001b0, 0x11},
-   {0x3d4001c0, 0x1},
-   {0x3d4001c4, 0x1},
-   {0x3d4000f4, 0xc99},
-   {0x3d400108, 0x70e1617},
-   {0x3d400200, 0x17},
-   {0x3d40020c, 0x0},
-   {0x3d400210, 0x1f1f},
-   {0x3d400204, 0x80808},
-   {0x3d400214, 0x7070707},
-   {0x3d400218, 0x7070707},
-   {0x3d400250, 0x29001701},
-   {0x3d400254, 0x2c},
-   {0x3d40025c, 0x430},
-   {0x3d400264, 0x900093e7},
-   {0x3d40026c, 0x2005574},
-   {0x3d400400, 0x111},
-   {0x3d400408, 0x72ff},
-   {0x3d400494, 0x2100e07},
-   {0x3d400498, 0x620096},
-   {0x3d40049c, 0x1100e07},
-   {0x3d4004a0, 0xc8012c},
-   {0x3d402020, 0x21},
-   {0x3d402024, 0x7d00},
-   {0x3d402050, 0x20d040},
-   {0x3d402064, 0xc001c},
-   {0x3d4020dc, 0x84},
-   {0x3d4020e0, 0x31},
-   {0x3d4020e8, 0x66004d},
-   {0x3d4020ec, 0x16004d},
-   {0x3d402100, 0xa040305},
-   {0x3d402104, 0x30407},
-   {0x3d402108, 0x203060b},
-   {0x3d40210c, 0x505000},
-   {0x3d402110, 0x2040202},
-   {0x3d402114, 0x2030202},
-   {0x3d402118, 0x1010004},
-   {0x3d40211c, 0x301},
-   {0x3d402130, 0x20300},
-   {0x3d402134, 0xa12},
-   {0x3d402138, 0x1d},
-   {0x3d402144, 0x14000a},
-   {0x3d402180, 0x640004},
-   {0x3d402190, 0x3818200},
-   {0x3d402194, 0x80303},
-   {0x3d4021b4, 0x100},
-   {0x3d403020, 0x21},
-   {0x3d403024, 0x1f40},
-   {0x3d403050, 0x20d040},
-   {0x3d403064, 0x30007},
-   {0x3d4030dc, 0x84},
-   {0x3d4030e0, 0x31},
-   {0x3d4030e8, 0x66004d},
-   {0x3d4030ec, 0x16004d},
-   {0x3d403100, 0xa010102},
-   {0x3d403104, 0x30404},
-   {0x3d403108, 0x203060b},
-   {0x3d40310c, 0x505000},
-   {0x3d403110, 0x2040202},
-   {0x3d403114, 0x2030202},
-   {0x3d403118, 0x1010004},
-   {0x3d40311c, 0x301},
-   {0x3d403130, 0x20300},
-   {0x3d403134, 0xa12},
-   {0x3d403138, 0x8},
-   {0x3d403144, 0x50003},
-   {0x3d403180, 0x190004},
-   {0x3d403190, 0x3818200},
-   {0x3d403194, 0x80303},
-   {0x3d4031b4, 0x100},
-   {0x3d400028, 0x0},
+   { 0x3d400304, 0x1 },
+   { 0x3d400030, 0x1 },
+   { 0x3d40, 0xa3080020 },
+   { 0x3d400020, 0x223 },
+   { 0x3d400024, 0x3a980 },
+   { 0x3d400064, 0x5b0087 },
+   { 0x3d4000d0, 0xc00305ba },
+   { 0x3d4000d4, 0x94 },
+   { 0x3d4000dc, 0xd4002d },
+   { 0x3d4000e0, 0x31 },
+   { 0x3d4000e8, 0x66004d },
+   { 0x3d4000ec, 0x16004d },
+   { 0x3d400100, 0x191e1920 },
+   { 0x3d400104, 0x60630 },
+   { 0x3d40010c, 0xb0b000 },
+   { 0x3d400110, 0xe04080e },
+   { 0x3d400114, 0x2040c0c },
+   { 0x3d400118, 0x1010007 },
+   { 0x3d40011c, 0x401 },
+   { 0x3d400130, 0x20600 },
+   { 0x3d400134, 0xc12 },
+   { 0x3d400138, 0xd8 },
+   { 0x3d400144, 0x96004b },
+   { 0x3d400180, 0x2ee0017 },
+   { 0x3d400184, 0x2605b8e },
+   { 0x3d400188, 0x0 },
+   { 0x3d400190, 0x497820a },
+   { 0x3d400194, 0x80303 },
+   { 0x3d4001b4, 0x170a },
+   { 0x3d4001a0, 0xe0400018 },
+   { 0x3d4001a4, 0xdf00e4 },
+   { 0x3d4001a8, 0x8000 },
+   { 0x3d4001b0, 0x11 },
+   { 0x3d4001c0, 0x1 },
+   { 0x

[PATCH 13/14] imx: kontron-sl-mx8mm: Simplify code in spl.c

2022-07-13 Thread Frieder Schrempf
From: Frieder Schrempf 

Refactor the code a bit without any functional changes.

Signed-off-by: Frieder Schrempf 
---
 board/kontron/sl-mx8mm/spl.c | 25 +
 1 file changed, 5 insertions(+), 20 deletions(-)

diff --git a/board/kontron/sl-mx8mm/spl.c b/board/kontron/sl-mx8mm/spl.c
index 212d712de6f..28211ae78f3 100644
--- a/board/kontron/sl-mx8mm/spl.c
+++ b/board/kontron/sl-mx8mm/spl.c
@@ -109,41 +109,26 @@ static void spl_dram_init(void)
size = 1;
}
 
-   printf("Kontron SL i.MX8MM (N801X) module, %u GB RAM detected\n", size);
+   gd->ram_size = size;
writel(size, M4_BOOTROM_BASE_ADDR);
 }
 
-static int i2c_detect(u8 bus, u16 addr)
-{
-   struct udevice *udev;
-   int ret;
-
-   /*
-* Try to probe the touch controller to check if an LVDS panel is
-* connected.
-*/
-   ret = i2c_get_chip_for_busnum(bus, addr, 0, &udev);
-   if (ret == 0)
-   return 0;
-
-   return 1;
-}
-
 int do_board_detect(void)
 {
+   gd->board_type = BOARD_TYPE_KTN_N801X;
+   printf("Kontron SL i.MX8MM (N801X) module, %u GB RAM detected\n", 
gd->ram_size);
+
/*
 * Check the I2C PMIC to detect the deprecated SoM with DA9063.
 */
imx_iomux_v3_setup_multiple_pads(i2c1_pads, ARRAY_SIZE(i2c1_pads));
 
-   if (i2c_detect(0, 0x58) == 0) {
+   if (i2c_get_chip_for_busnum(0, 0x58, 0, &udev) == 0) {
printf("### ATTENTION: DEPRECATED SOM REVISION (N8010 Rev0) 
DETECTED! ###\n");
printf("###  THIS HW IS NOT SUPPORTED AND BOOTING WILL PROBABLY 
FAIL  ###\n");
printf("### PLEASE UPGRADE TO LATEST MODULE 
  ###\n");
}
 
-   gd->board_type = BOARD_TYPE_KTN_N801X;
-
return 0;
 }
 
-- 
2.37.0



[PATCH 12/14] imx: kontron-sl-mx8mm: Use voltage rail names from schematic for PMIC regulator-names

2022-07-13 Thread Frieder Schrempf
From: Frieder Schrempf 

Improve the naming of the regulators to contain the voltage rail
names from the schematic.

Suggested-by: Heiko Thiery 
Signed-off-by: Frieder Schrempf 
---
 arch/arm/dts/imx8mm-kontron-n801x-som.dtsi | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi 
b/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi
index 2d0661cce89..c995592981c 100644
--- a/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi
+++ b/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi
@@ -85,7 +85,7 @@
 
regulators {
reg_vdd_soc: BUCK1 {
-   regulator-name = "buck1";
+   regulator-name = "+0V8_VDD_SOC (BUCK1)";
regulator-min-microvolt = <80>;
regulator-max-microvolt = <85>;
regulator-boot-on;
@@ -96,7 +96,7 @@
};
 
reg_vdd_arm: BUCK2 {
-   regulator-name = "buck2";
+   regulator-name = "+0V9_VDD_ARM (BUCK2)";
regulator-min-microvolt = <85>;
regulator-max-microvolt = <95>;
regulator-boot-on;
@@ -107,7 +107,7 @@
};
 
reg_vdd_dram: BUCK3 {
-   regulator-name = "buck3";
+   regulator-name = "+0V9_VDD_DRAM&PU (BUCK3)";
regulator-min-microvolt = <85>;
regulator-max-microvolt = <95>;
regulator-boot-on;
@@ -115,7 +115,7 @@
};
 
reg_vdd_3v3: BUCK4 {
-   regulator-name = "buck4";
+   regulator-name = "+3V3 (BUCK4)";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
regulator-boot-on;
@@ -123,7 +123,7 @@
};
 
reg_vdd_1v8: BUCK5 {
-   regulator-name = "buck5";
+   regulator-name = "+1V8 (BUCK5)";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-boot-on;
@@ -131,7 +131,7 @@
};
 
reg_nvcc_dram: BUCK6 {
-   regulator-name = "buck6";
+   regulator-name = "+1V1_NVCC_DRAM (BUCK6)";
regulator-min-microvolt = <110>;
regulator-max-microvolt = <110>;
regulator-boot-on;
@@ -139,7 +139,7 @@
};
 
reg_nvcc_snvs: LDO1 {
-   regulator-name = "ldo1";
+   regulator-name = "+1V8_NVCC_SNVS (LDO1)";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-boot-on;
@@ -147,7 +147,7 @@
};
 
reg_vdd_snvs: LDO2 {
-   regulator-name = "ldo2";
+   regulator-name = "+0V8_VDD_SNVS (LDO2)";
regulator-min-microvolt = <80>;
regulator-max-microvolt = <90>;
regulator-boot-on;
@@ -155,7 +155,7 @@
};
 
reg_vdda: LDO3 {
-   regulator-name = "ldo3";
+   regulator-name = "+1V8_VDDA (LDO3)";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-boot-on;
@@ -163,7 +163,7 @@
};
 
reg_vdd_phy: LDO4 {
-   regulator-name = "ldo4";
+   regulator-name = "+0V9_VDD_PHY (LDO4)";
regulator-min-microvolt = <90>;
regulator-max-microvolt = <90>;
regulator-boot-on;
@@ -171,7 +171,7 @@
};
 
reg_nvcc_sd: LDO5 {
-   regulator-name = "ldo5";
+   regulator-name = "NVCC_SD (LDO5)";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <3

[PATCH 10/14] imx: kontron-sl-mx8mm: Adjust board and SoM model strings

2022-07-13 Thread Frieder Schrempf
From: Frieder Schrempf 

The official naming includes "SL" (SoM-Line) or "BL" (Board-Line).
The legacy identifiers are kept in brackets and are still used in
file names and compatible strings.

Signed-off-by: Frieder Schrempf 
---
 arch/arm/dts/imx8mm-kontron-n801x-s.dts| 2 +-
 arch/arm/dts/imx8mm-kontron-n801x-som.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/imx8mm-kontron-n801x-s.dts 
b/arch/arm/dts/imx8mm-kontron-n801x-s.dts
index 23be1ec538b..cb8102bb8db 100644
--- a/arch/arm/dts/imx8mm-kontron-n801x-s.dts
+++ b/arch/arm/dts/imx8mm-kontron-n801x-s.dts
@@ -8,7 +8,7 @@
 #include "imx8mm-kontron-n801x-som.dtsi"
 
 / {
-   model = "Kontron i.MX8MM N801X S";
+   model = "Kontron BL i.MX8MM (N801X)";
compatible = "kontron,imx8mm-n801x-s", "kontron,imx8mm-n801x-som", 
"fsl,imx8mm";
 
aliases {
diff --git a/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi 
b/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi
index 7e80008da29..a981a6b4ac0 100644
--- a/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi
+++ b/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi
@@ -6,7 +6,7 @@
 #include "imx8mm.dtsi"
 
 / {
-   model = "Kontron i.MX8MM N801X SoM";
+   model = "Kontron SL i.MX8MM (N801X)";
compatible = "kontron,imx8mm-n801x-som", "fsl,imx8mm";
 
memory@4000 {
-- 
2.37.0



[PATCH 14/14] imx: kontron-sl-mx8mm: Add support for Kontron Electronics SoM SL i.MX8MM OSM-S

2022-07-13 Thread Frieder Schrempf
From: Frieder Schrempf 

This adds support for the Kontron Electronics SoM SL i.MX8MM OSM-S
and the matching baseboard BL i.MX8MM OSM-S.

The SoM hardware complies to the Open Standard Module (OSM) 1.0
specification, size S (https://sget.org/standards/osm).

The existing board configuration for the non-OSM SoM is reused and
allows to detect the SoM variant at runtime.

Signed-off-by: Frieder Schrempf 
---
 .../dts/imx8mm-kontron-n801x-s-u-boot.dtsi| 138 +--
 .../dts/imx8mm-kontron-n802x-s-u-boot.dtsi|   6 +
 arch/arm/dts/imx8mm-kontron-n802x-s.dts   | 376 ++
 arch/arm/dts/imx8mm-kontron-n802x-som.dtsi| 309 ++
 .../dts/imx8mm-kontron-n80xx-s-u-boot.dtsi| 139 +++
 board/kontron/sl-mx8mm/MAINTAINERS|   1 +
 board/kontron/sl-mx8mm/sl-mx8mm.c |   6 +-
 board/kontron/sl-mx8mm/spl.c  |  22 +-
 configs/kontron-sl-mx8mm_defconfig|   2 +
 doc/board/kontron/sl-mx8mm.rst|   7 +-
 10 files changed, 866 insertions(+), 140 deletions(-)
 create mode 100644 arch/arm/dts/imx8mm-kontron-n802x-s-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mm-kontron-n802x-s.dts
 create mode 100644 arch/arm/dts/imx8mm-kontron-n802x-som.dtsi
 create mode 100644 arch/arm/dts/imx8mm-kontron-n80xx-s-u-boot.dtsi

diff --git a/arch/arm/dts/imx8mm-kontron-n801x-s-u-boot.dtsi 
b/arch/arm/dts/imx8mm-kontron-n801x-s-u-boot.dtsi
index a42881d1a89..e2a5a883256 100644
--- a/arch/arm/dts/imx8mm-kontron-n801x-s-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-kontron-n801x-s-u-boot.dtsi
@@ -1,139 +1,7 @@
-// SPDX-License-Identifier: GPL-2.0+
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
 /*
- * Copyright (C) 2019 Kontron Electronics GmbH
+ * Copyright (C) 2022 Kontron Electronics GmbH
  */
 
-#include "imx8mm-u-boot.dtsi"
+#include "imx8mm-kontron-n80xx-s-u-boot.dtsi"
 
-/ {
-   aliases {
-   usb0 = &usbotg1;
-   usb1 = &usbotg2;
-   };
-
-   wdt-reboot {
-   compatible = "wdt-reboot";
-   wdt = <&wdog1>;
-   u-boot,dm-spl;
-   };
-
-   firmware {
-   optee {
-   compatible = "linaro,optee-tz";
-   method = "smc";
-   };
-   };
-};
-
-&crypto {
-   u-boot,dm-spl;
-};
-
-&sec_jr0 {
-   u-boot,dm-spl;
-};
-
-&sec_jr1 {
-   u-boot,dm-spl;
-};
-
-&sec_jr2 {
-   u-boot,dm-spl;
-};
-
-&i2c1 {
-   u-boot,dm-spl;
-   u-boot,dm-pre-reloc;
-};
-
-&i2c2 {
-   status = "okay";
-   u-boot,dm-spl;
-   u-boot,dm-pre-reloc;
-};
-
-&pinctrl_ecspi1 {
-   u-boot,dm-spl;
-};
-
-&pinctrl_i2c1 {
-   u-boot,dm-spl;
-};
-
-&pinctrl_pmic {
-   u-boot,dm-spl;
-};
-
-&pinctrl_uart3 {
-   u-boot,dm-spl;
-   u-boot,dm-pre-reloc;
-};
-
-&pinctrl_usdhc1 {
-   u-boot,dm-spl;
-};
-
-&pinctrl_usdhc1_100mhz {
-   u-boot,dm-spl;
-};
-
-&pinctrl_usdhc1_200mhz {
-   u-boot,dm-spl;
-};
-
-&pinctrl_usdhc2 {
-   u-boot,dm-spl;
-};
-
-&pca9450 {
-   u-boot,dm-spl;
-};
-
-&{/soc@0/bus@3080/i2c@30a2/pmic@25/regulators} {
-   u-boot,dm-spl;
-};
-
-&ecspi1 {
-   u-boot,dm-spl;
-};
-
-&gpio1 {
-   u-boot,dm-spl;
-};
-
-&gpio2 {
-   u-boot,dm-spl;
-};
-
-&gpio3 {
-   u-boot,dm-spl;
-};
-
-&gpio4 {
-   u-boot,dm-spl;
-};
-
-&gpio5 {
-   u-boot,dm-spl;
-};
-
-&uart3 {
-   u-boot,dm-spl;
-   u-boot,dm-pre-reloc;
-};
-
-&usdhc1 {
-   u-boot,dm-spl;
-};
-
-&usdhc2 {
-   u-boot,dm-spl;
-};
-
-&wdog1 {
-   u-boot,dm-spl;
-};
-
-&pinctrl_wdog {
-   u-boot,dm-spl;
-};
diff --git a/arch/arm/dts/imx8mm-kontron-n802x-s-u-boot.dtsi 
b/arch/arm/dts/imx8mm-kontron-n802x-s-u-boot.dtsi
new file mode 100644
index 000..115c4a3d87c
--- /dev/null
+++ b/arch/arm/dts/imx8mm-kontron-n802x-s-u-boot.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2022 Kontron Electronics GmbH
+ */
+
+#include "imx8mm-kontron-n80xx-s-u-boot.dtsi"
diff --git a/arch/arm/dts/imx8mm-kontron-n802x-s.dts 
b/arch/arm/dts/imx8mm-kontron-n802x-s.dts
new file mode 100644
index 000..3d66506f748
--- /dev/null
+++ b/arch/arm/dts/imx8mm-kontron-n802x-s.dts
@@ -0,0 +1,376 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2022 Kontron Electronics GmbH
+ */
+
+/dts-v1/;
+
+#include "imx8mm-kontron-n802x-som.dtsi"
+
+/ {
+   model = "Kontron BL i.MX8MM OSM-S (N802X)";
+   compatible = "kontron,imx8mm-n802x-s", "kontron,imx8mm-n802x-som", 
"fsl,imx8mm";
+
+   aliases {
+   ethernet1 = &usbnet;
+   };
+
+   /* fixed crystal dedicated to mcp2542fd */
+   osc_can: clock-osc-can {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <4000>;
+   clock-output-names = "osc-can";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+

Re: u-boot and IPv6

2022-07-13 Thread Chris Packham
On Tue, Jul 12, 2022 at 7:40 PM Chris Packham  wrote:
>
> Hi Sean and Dhananjay,
>
> Adding U-Boot ML to the Cc
>
> On Tue, Jul 12, 2022, 08:45 Sean Edmond  wrote:
>>
>> Hi Chris,
>>
>> I’m looking to add IPv6 to our version of u-boot.
>>
>> I found your patch series which looks like a solid initial effort:
>> [U-Boot] [RFC PATCH v3 00/11] IPv6 support - Chris Packham (kernel.org)
>>
>> I have a few questions on the work:
>> - the patch series is now ~5 year old.  Do you have a newer patch series 
>> rebased onto a newer u-boot?
>> - do you have any plan to create a PR with these changes?
>> - has there been much interest in your changes?
>> - have you met any other individuals/companies who are trying to add IPv6 
>> into u-boot?
>>
>> I look forward to hearing from you!
>>
>> Sean
>
> IPv6 support is definitely something I want to get landed in upstream U-Boot.
>
> It seemed to be fairly well received last time I posted the series. The main 
> thing lacking was tests. That's pretty much where things were at last time I 
> touched it. As usual life and work commitments have stopped me from 
> progressing it further.
>
> In the meantime U-Boot's testing infrastructure has improved a lot which 
> should make adding the tests easier. I know there have been some more changes 
> in net that will conflict but not badly.
>
> At $dayjob we have merged a newer u-boot version into our fork so I do have 
> something that is effectively a post state for the merge conflict to refer to 
> but it's not the broken out series that I'd like to submit.
>
> I think I should be able to get the series rebased against master (or the 
> just released 2022.07 might be more useful as a base). I can probably get 
> that up on github in the next couple of days.

I've rebased my series against v2022.07 you can get the code from the
ipv6 branch of https://github.com/cpackham/u-boot.git

I've only lightly compile tested it so I've no idea if it's still functional


PRAM and reserved memory for Linux

2022-07-13 Thread Joakim Tjernlund
I added CONFIG_PRAM 4 and a reserved-memory DTS node for the same space but
now u-boot complains when booting:
  ERROR: reserving fdt memory region failed (addr=703ff000 size=1000)
The error is caused by arch_lmb_reserve() in arm which seem
to reserve command line and board info ? 

If I remove the reserved-memory DTS node I don't get a reserved area in Linux,
don't quite understand how PRAM is supposed to work?

 Jocke


RE: [EXT] [PATCH] doc: imx: habv4: Add Secure Boot guide for i.MX8M SPL targets

2022-07-13 Thread Utkarsh Gupta
Hi Marek,

The Secure/Encrypted boot guides for 8M exist in NXP BSP at
https://source.codeaurora.org/external/imx/uboot-imx/tree/doc/imx?h=lf_v2022
.04. Looks like they need to be up streamed. @Peng Fan/@Ye Li - FYI

Regards,
Utkarsh G.

> -Original Message-
> From: Marek Vasut 
> Sent: Tuesday, July 12, 2022 10:05 AM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Breno Matheus Lima
> ; Fabio Estevam ; Heiko Schocher
> ; Peng Fan ; Stefano Babic
> ; Utkarsh Gupta ; Ye Li
> 
> Subject: [EXT] [PATCH] doc: imx: habv4: Add Secure Boot guide for i.MX8M
SPL
> targets
> 
> Caution: EXT Email
> 
> Add HABv4 documentation extension for SPL targets covering the following
> topics:
> 
> - How to sign an securely boot an flash.bin container image.
> - How to extend the root of trust for additional boot images.
> - Add SPL and fitImage CSF examples.
> - Add signature generation script example.
> 
> Signed-off-by: Marek Vasut 
> Cc: Breno Lima 
> Cc: Fabio Estevam 
> Cc: Heiko Schocher 
> Cc: Peng Fan 
> Cc: Stefano Babic 
> Cc: Utkarsh Gupta 
> Cc: Ye Li 
> ---
>  doc/imx/habv4/csf_examples/mx8m/csf.sh|  77 +
>  doc/imx/habv4/csf_examples/mx8m/csf_fit.txt   |  36 +++
>  doc/imx/habv4/csf_examples/mx8m/csf_spl.txt   |  33 +++
>  doc/imx/habv4/guides/mx8m_spl_secure_boot.txt | 265 ++
>  4 files changed, 411 insertions(+)
>  create mode 100644 doc/imx/habv4/csf_examples/mx8m/csf.sh
>  create mode 100644 doc/imx/habv4/csf_examples/mx8m/csf_fit.txt
>  create mode 100644 doc/imx/habv4/csf_examples/mx8m/csf_spl.txt
>  create mode 100644 doc/imx/habv4/guides/mx8m_spl_secure_boot.txt
> 
> diff --git a/doc/imx/habv4/csf_examples/mx8m/csf.sh
> b/doc/imx/habv4/csf_examples/mx8m/csf.sh
> new file mode 100644
> index 000..6898513be51
> --- /dev/null
> +++ b/doc/imx/habv4/csf_examples/mx8m/csf.sh
> @@ -0,0 +1,77 @@
> +#!/bin/sh
> +
> +# 0) Generate keys
> +#
> +# WARNING: ECDSA keys are only supported by HAB 4.5 and newer (i.e.
> +i.MX8M Plus) # # cd /path/to/cst-3.3.1/keys/
> +#./hab4_pki_tree.sh -existing-ca n -use-ecc n -kl 4096 -duration 10
-num-srk
> 4 -srk-ca y
> +# cd /path/to/cst-3.3.1/crts/
> +#   ../linux64/bin/srktool -h 4 -t SRK_1_2_3_4_table.bin -e
> SRK_1_2_3_4_fuse.bin -d sha256 -
> c ./SRK1_sha256_4096_65537_v3_ca_crt.pem,./SRK2_sha256_4096_65537_v3_
> ca_crt.pem,./SRK3_sha256_4096_65537_v3_ca_crt.pem,./SRK4_sha256_4096_
> 65537_v3_ca_crt.pem -f 1
> +
> +# 1) Build U-Boot (e.g. for i.MX8MM)
> +#
> +# export ATF_LOAD_ADDR=0x92
> +# cp -Lv /path/to/arm-trusted-firmware/build/imx8mm/release/bl31.bin .
> +# cp -Lv /path/to/firmware-imx-8.14/firmware/ddr/synopsys/ddr3* .
> +# make -j imx8mm_board_defconfig
> +# make -j`nproc` flash.bin
> +
> +# 2) Sign SPL and DRAM blobs
> +
> +cp doc/imx/habv4/csf_examples/mx8m/csf_spl.txt csf_spl.tmp cp
> +doc/imx/habv4/csf_examples/mx8m/csf_fit.txt csf_fit.tmp
> +
> +spl_block_base=$(printf "0x%x" $(( $(sed -n "/CONFIG_SPL_TEXT_BASE=/
> +s@.*=@@p" .config) - 0x40)) ) spl_block_size=$(printf "0x%x" $(stat -tc
> +%s u-boot-spl-ddr.bin)) sed -i "/Blocks = / s@.*@  Blocks =
> +$spl_block_base 0x0 $spl_block_size \"flash.bin\"@" csf_spl.tmp
> +
> +# Generate CSF blob
> +cst -i csf_spl.tmp -o csf_spl.bin
> +
> +# Patch CSF blob into flash.bin
> +spl_csf_offset=$(xxd -s 24 -l 4 -e flash.bin | cut -d " " -f 2 | sed
> +"s@^@0x@") spl_bin_offset=$(xxd -s 4 -l 4 -e flash.bin | cut -d " " -f
> +2 | sed "s@^@0x@") spl_dd_offset=$((${spl_csf_offset} -
> +${spl_bin_offset} + 0x40)) dd if=csf_spl.bin of=flash.bin bs=1
> +seek=${spl_dd_offset} conv=notrunc
> +
> +# 3) Sign u-boot.itb
> +
> +# fitImage tree
> +fit_block_base=$(printf "0x%x" $(( $(sed -n "/CONFIG_SYS_TEXT_BASE=/
> +s@.*=@@p" .config) - $(sed -n "/CONFIG_FIT_EXTERNAL_OFFSET=/
> s@.*=@@p"
> +.config) - 0x200 - 0x40)) ) fit_block_offset=$(printf "0x%s" $(fdtget
> +-t x u-boot.dtb /binman/imx-boot/uboot offset)) fit_block_size=$(printf
> +"0x%x" $(( ( $(fdtdump u-boot.itb 2>/dev/null | sed -n
> +"/^...totalsize:/ s@.*\(0x[0-9a-f]\+\).*@\1@p") + 0x1000 - 0x1 ) &
> +~(0x1000 - 0x1) + 0x20 )) ) sed -i "/Blocks = / s@.*@  Blocks =
> +$fit_block_base $fit_block_offset $fit_block_size \"flash.bin\", @"
> +csf_fit.tmp
> +
> +# U-Boot
> +uboot_block_base=$(printf "0x%s" $(fdtget -t x u-boot.itb /images/uboot
> +load)) uboot_block_offset=$(printf "0x%x" $(( $(printf "0x%s" $(fdtget
> +-t x u-boot.itb /images/uboot data-position)) + ${fit_block_offset} )))
> uboot_block_size=$(printf "0x%s" $(fdtget -t x u-boot.itb /images/uboot
data-
> size))
> +sed -i "/0x/ s@.*@   $uboot_block_base $uboot_block_offset
> $uboot_block_size \"flash.bin\", @" csf_fit.tmp
> +
> +# ATF
> +atf_block_base=$(printf "0x%s" $(fdtget -t x u-boot.itb /images/atf
> +load)) atf_block_offset=$(printf "0x%x" $(( $(printf "0x%s" $(fdtget -t
> +x u-boot.itb /images/atf data-position)) + ${fit_block_offset} )))
> atf_block_size=$(printf "0x%s" $(fdtget -t x u-boot.itb /images/atf
data-size))
> +sed -i "/0x/ s@.

[PATCH] [Meson] add magicbox m16s config, dts and doc

2022-07-13 Thread Zhang Ning
MagicBox M16S or MagicBox 3Pro is welcome Tv box in China,
which is developed by Alibaba at 2016.

No schemtics, no vendor source code right now
thus no fip blobs to create mainline u-boot.
Need to use chainloader to boot a mainline u-boot, then mainline kernel.

from pre-installed u-boot log, it's gxm_q201_v1 or its decendent.

add a simple dts and config to enable this Tv box.
a simple doc for how to enable mainline uboot.

Signed-off-by: Zhang Ning 
---
 arch/arm/dts/Makefile |   1 +
 .../dts/meson-gxm-magicbox-m16s-u-boot.dtsi   |   6 +
 arch/arm/dts/meson-gxm-magicbox-m16s.dts  |  24 
 configs/magicbox-m16s_defconfig   |  68 +++
 doc/board/amlogic/index.rst   |   1 +
 doc/board/amlogic/magicboxm16s.rst| 109 ++
 6 files changed, 209 insertions(+)
 create mode 100644 arch/arm/dts/meson-gxm-magicbox-m16s-u-boot.dtsi
 create mode 100644 arch/arm/dts/meson-gxm-magicbox-m16s.dts
 create mode 100644 configs/magicbox-m16s_defconfig
 create mode 100644 doc/board/amlogic/magicboxm16s.rst

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a7e0d9f6c0..31294c4c18 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -191,6 +191,7 @@ dtb-$(CONFIG_ARCH_MESON) += \
meson-gxm-khadas-vim2.dtb \
meson-gxm-s912-libretech-pc.dtb \
meson-gxm-wetek-core2.dtb \
+   meson-gxm-magicbox-m16s.dtb \
meson-g12a-radxa-zero.dtb \
meson-g12a-sei510.dtb \
meson-g12a-u200.dtb \
diff --git a/arch/arm/dts/meson-gxm-magicbox-m16s-u-boot.dtsi 
b/arch/arm/dts/meson-gxm-magicbox-m16s-u-boot.dtsi
new file mode 100644
index 00..87a6e8525e
--- /dev/null
+++ b/arch/arm/dts/meson-gxm-magicbox-m16s-u-boot.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2022 Zhang Ning 
+ */
+
+#include "meson-gxl-u-boot.dtsi"
diff --git a/arch/arm/dts/meson-gxm-magicbox-m16s.dts 
b/arch/arm/dts/meson-gxm-magicbox-m16s.dts
new file mode 100644
index 00..a382fafc51
--- /dev/null
+++ b/arch/arm/dts/meson-gxm-magicbox-m16s.dts
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2022 Zhang Ning 
+ */
+
+/dts-v1/;
+
+#include "meson-gxm.dtsi"
+#include "meson-gx-p23x-q20x.dtsi"
+
+/ {
+   compatible = "magicbox,m16s", "amlogic,s912", "amlogic,meson-gxm";
+   model = "Magicbox M16S";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x8000>; /* 2 GiB */
+   };
+
+};
+ðmac {
+phy-mode = "rmii";
+phy-handle = <&internal_phy>;
+};
diff --git a/configs/magicbox-m16s_defconfig b/configs/magicbox-m16s_defconfig
new file mode 100644
index 00..df9a746b65
--- /dev/null
+++ b/configs/magicbox-m16s_defconfig
@@ -0,0 +1,68 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MESON=y
+CONFIG_SYS_TEXT_BASE=0x0100
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_ENV_SIZE=0x2000
+CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="meson-gxm-magicbox-m16s"
+CONFIG_MESON_GXM=y
+CONFIG_DEBUG_UART_BASE=0xc81004c0
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_IDENT_STRING=" magicbox m16s"
+CONFIG_SYS_LOAD_ADDR=0x100
+CONFIG_DEBUG_UART=y
+CONFIG_REMAKE_ELF=y
+CONFIG_OF_BOARD_SETUP=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_MISC_INIT_R=y
+# CONFIG_CMD_BDI is not set
+# CONFIG_CMD_IMI is not set
+CONFIG_CMD_ADC=y
+# CONFIG_EFI_LOADER is not set
+CONFIG_CMD_GPIO=y
+# CONFIG_CMD_LOADS is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_REGULATOR=y
+CONFIG_OF_CONTROL=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_SARADC_MESON=y
+CONFIG_MMC_MESON_GX=y
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+CONFIG_DM_ETH=y
+CONFIG_DM_MDIO=y
+CONFIG_DM_MDIO_MUX=y
+CONFIG_ETH_DESIGNWARE_MESON8B=y
+CONFIG_MDIO_MUX_MMIOREG=y
+CONFIG_MESON_GXL_USB_PHY=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_MESON_GXL=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_MESON_GX_VPU_POWER_DOMAIN=y
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_RESET=y
+CONFIG_DEBUG_UART_ANNOUNCE=y
+CONFIG_DEBUG_UART_SKIP_INIT=y
+CONFIG_MESON_SERIAL=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_DWC3=y
+# CONFIG_USB_DWC3_GADGET is not set
+CONFIG_USB_DWC3_MESON_GXL=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_VENDOR_NUM=0x1b8e
+CONFIG_USB_GADGET_PRODUCT_NUM=0xfada
+CONFIG_USB_GADGET_DWC2_OTG=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_DM_VIDEO=y
+# CONFIG_VIDEO_BPP8 is not set
+# CONFIG_VIDEO_BPP16 is not set
+CONFIG_SYS_WHITE_ON_BLACK=y
+CONFIG_VIDEO_MESON=y
+CONFIG_VIDEO_DT_SIMPLEFB=y
+CONFIG_OF_LIBFDT_OVERLAY=y
diff --git a/doc/board/amlogic/index.rst b/doc/board/amlogic/index.rst
index 9c7fadf2c0..2620b38b5d 100644
--- a/doc/board/amlogic/index.rst
+++ b/doc/board/amlogic/index.rst
@@ -113,3 +113,4 @@ Board Documentation
u200
wetek-core2
w400
+   magicboxm16s
diff --git a/doc/board/amlogic/magicboxm16s.rst 
b/doc/board/amlogic/magicboxm16s.rst
new file mode 100

Re: [PATCH 1/2] ARM: dts: stm32mp13: add OP-TEE nodes

2022-07-13 Thread Patrick Delaunay
On Wed, 6 Jul 2022 18:20:24 +0200, Patrick Delaunay wrote:
> Add the node for OP-TEE firmware with the associated reserved memory nodes
> 
> 

Applied to stm32/master, thanks!

[1/2] ARM: dts: stm32mp13: add OP-TEE nodes
  commit: 0b69ce6a816c39502941deb90543e23619e02896
[2/2] ARM: dts: stm32mp13: add SCMI nodes
  commit: 44db098ae1d91bde3bd52097ab3a1a52f5b4ed84

Best regards,
-- 
Patrick Delaunay 


Re: [PATCH v2 01/10] i2c: stm32: add support for the st, stm32mp13 SOC

2022-07-13 Thread Patrick Delaunay
On Thu, 30 Jun 2022 10:20:14 +0200, Patrick Delaunay wrote:
> The stm32mp13 soc differs from the stm32mp15 in terms of
> clear register offset for controlling the FMP (Fast Mode Plus).
> 
> 

Applied to stm32/master, thanks!

[01/10] i2c: stm32: add support for the st,stm32mp13 SOC
commit: d4d01d0e9998ab1c000ae0d578d33801b31cb845
[02/10] rng: stm32mp1_rng: add conditional reset feature for STM32MP13x
commit: 12e11aae2d96d4c437c4c068e440ab4b7f08ceb0
[03/10] stm32mp: add support of STM32MP13x Rev.Y
commit: 50b371fd68afb3650fc285bca6ae88d639418a16
[04/10] ARM: dts: stm32mp13: alignment with v5.19
commit: 12d5a0626cf11acc3c9a59c91d87657eef726fdc
[05/10] ARM: dts: stm32mp13: activate led on STM32MP13F-DK
commit: 6d647676ead2caecade3a7145302e98bfbc436f9
[06/10] configs: stm32mp13: Add support for baudrates higher than 115200
commit: eb67e63da4468195276c889a1866b43821128b25
[07/10] configs: stm32mp13: activate RNG support
commit: 72d7a302f634029ef2874d864c294fd9bfc48739
[08/10] configs: stm32mp13: activate RTC support
commit: 420f37a91faefcda64355805fbcb662cd0aac8e1
[09/10] configs: stm32mp13: activate I2C support
commit: 33129f6130dc125582e09a03ec78afe53a1b27f3
[10/10] configs: stm32mp13: activate some command
commit: 257d001cb5a3e3e3a582fddb37478dedb1764811

Best regards,
-- 
Patrick Delaunay 


Re: [PATCH 1/4] ARM: dts: stm32mp15: alignment with v5.19

2022-07-13 Thread Patrick Delaunay
On Tue, 5 Jul 2022 16:55:54 +0200, Patrick Delaunay wrote:
> Device tree alignment with Linux kernel v5.19-rc1
> 
> - ARM: dts: stm32: Add alternate pinmux for ethernet0 pins
> - ARM: dts: stm32: Add alternate pinmux for mco2 pins
> - ARM: dts: stm32: fix pinctrl node name warnings (MPU soc)
> - ARM: dts: stm32: stm32mp15-pinctrl: add spi1-1 pinmux group
> - dt-bindings: clock: add IDs for SCMI clocks on stm32mp15
> - dt-bindings: reset: add IDs for SCMI reset domains on stm32mp15
> - dt-bindings: clock: stm32mp15: rename CK_SCMI define
> - dt-bindings: reset: stm32mp15: rename RST_SCMI define
> - dt-bindings: reset: add MCU HOLD BOOT ID for SCMI reset domains
>   on stm32mp15
> - dt-bindings: clk: cleanup comments
> - ARM: dts: align SPI NOR node name with dtschema
> - ARM: dts: stm32: enable optee firmware and SCMI support on STM32MP15
> - ARM: dts: stm32: Add SCMI version of STM32 boards (DK1/DK2/ED1/EV1)
> - ARM: dts: stm32: move SCMI related nodes in a dedicated file for
>   stm32mp15
> 
> [...]

Applied to stm32/master, thanks!

[1/4] ARM: dts: stm32mp15: alignment with v5.19
  commit: 69ef98b209e7e392d4a31d99cb4fa249f8a58ac0
[2/4] clk: stm32: add support compatible st, stm32mp1-rcc-secure
  commit: 43872790d8eeb2055aebc13b09fba3dbb2f8dcaf
[3/4] configs: stm32mp15: increase malloc size for pre-reloc
  commit: 7f4de655c0ff460c1a4ee6ea00208327ab54e22d
[4/4] ARM: dts: stm32: add SCMI version of STM32 boards (DK1/DK2/ED1/EV1)
  commit: 68d396bfd68bbf695b3b3c92e60b8bdf8b77

Best regards,
-- 
Patrick Delaunay 


Re: [PATCH v2 1/3] mmc: stm32_sdmmc2: cosmetic: rename stm32_sdmmc_bind

2022-07-13 Thread Patrick Delaunay
On Thu, 30 Jun 2022 10:01:45 +0200, Patrick Delaunay wrote:
> Rename stm32_sdmmc_bind to stm32_sdmmc2_bind as all other functions
> in SDMMCv2 driver
> 
> series-changes: 2
> - fix typo in commit message (/oter function/other functions/)
> 
> 
> [...]

Applied to stm32/master, thanks!

[1/3] mmc: stm32_sdmmc2: cosmetic: rename stm32_sdmmc_bind
  commit: 5f1e6b639b47eea5177b1128c384da76dce2dbe6
[2/3] mmc: stm32_sdmmc2: remove privdata
  commit: efd77dbca304d6cceb40675365485d84cce40ccd
[3/3] mmc: stm32_sdmmc2: introduce of_to_plat ops
  commit: cb8edb996bf20be09b88b2b17520beec433067cd

Best regards,
-- 
Patrick Delaunay 


Re: [PATCH] arm: dts: stm32mp1: Drop fastboot and stm32prog trigger gpios on DHCOM

2022-07-13 Thread Patrick Delaunay
On Thu, 30 Jun 2022 16:19:48 +0200, Johann Neuhauser wrote:
> PA13 and PA14 are used for USB power control and can't be used
> to enforce fastboot or stm32prog mode by pressing a button.
> 
> Defining CONFIG_FASTBOOT/CONFIG_CMD_STM32PROG without this patch applied
> results in fastboot/stm32prog always starting, because PA13/PA14 are always
> low during boot. So drop the wrong trigger gpios definitions.
> 
> [...]

Applied to stm32/master, thanks!

[1/1] arm: dts: stm32mp1: Drop fastboot and stm32prog trigger gpios on DHCOM
  commit: 48d9eaf6826a1816c5f9839a564ea6338da609a7

Best regards,
-- 
Patrick Delaunay 


Re: [v3 1/4] doc: Add statistics page for v2022.07

2022-07-13 Thread Heinrich Schuchardt

On 7/12/22 23:34, Tom Rini wrote:

Our statistics pages have always been generated by gitdm.  After
patching gitdm to generate an acceptable Sphinx output for tables,
include that and some other basic formatting here.

Cc: Heinrich Schuchardt
Signed-off-by: Tom Rini
---


Reviewed-by: Heinrich Schuchardt 


[PATCH] armv8: mach-k3: correct define checking for AM625/AM642 memory maps

2022-07-13 Thread Matt Ranostay
Using CONFIG_IS_ENABLED breaks accessing memory map structure when
doing a A53 SPL build for AM625 and AM642 platforms. This is due to
'abc if CONFIG_SPL_BUILD is defined and CONFIG_SPL_FOO is set to 'y''
in which there is no CONFIG_SPL_SOC_K3_AM625/CONFIG_SPL_SOC_K3_AM642
defined in the configuration.

For the A53 SPL builds on these platform to access the memory mapping
which it will need for enabling the mmu/cache it must use #if defined(X)
checks and not CONFIG_IS_ENABLED.

Cc: Suman Anna 
Cc: Neha Francis 
Signed-off-by: Matt Ranostay 
---
 arch/arm/mach-k3/arm64-mmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
index 12cb89335ad..c43c07ce7fa 100644
--- a/arch/arm/mach-k3/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64-mmu.c
@@ -222,7 +222,7 @@ struct mm_region *mem_map = j721s2_mem_map;
 
 #endif /* CONFIG_SOC_K3_J721S2 */
 
-#if (CONFIG_IS_ENABLED(SOC_K3_AM642) || CONFIG_IS_ENABLED(SOC_K3_AM625))
+#if defined(CONFIG_SOC_K3_AM642) || defined(CONFIG_SOC_K3_AM625)
 /* NR_DRAM_BANKS + 32bit IO + 64bit IO + terminator */
 #define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 3)
 
-- 
2.36.1



[PATCH 0/3] Test and docs for fdt command

2022-07-13 Thread Simon Glass
This was required by Marek to provide a starting point for documentation
and a test for a new subcommand.


Simon Glass (3):
  addrmap: Support on sandbox
  fdt: Start a test for the fdt command
  doc: Make a start on docs for fdt command

 board/sandbox/sandbox.c   |   9 +++
 common/cli.c  |  15 
 configs/sandbox_defconfig |   1 +
 doc/usage/cmd/fdt.rst |  69 ++
 doc/usage/index.rst   |   1 +
 include/addr_map.h|   2 +
 include/command.h |  10 +++
 include/test/suites.h |   1 +
 lib/addr_map.c|   5 +-
 test/cmd/Makefile |   1 +
 test/cmd/addrmap.c|   5 +-
 test/cmd/fdt.c| 142 ++
 test/cmd_ut.c |   6 ++
 13 files changed, 262 insertions(+), 5 deletions(-)
 create mode 100644 doc/usage/cmd/fdt.rst
 create mode 100644 test/cmd/fdt.c

-- 
2.37.0.144.g8ac04bfd2-goog



[PATCH 1/3] addrmap: Support on sandbox

2022-07-13 Thread Simon Glass
Update this feature so that it works on sandbox, using a basic identity
mapping. This allows us to run the 'ut addrmap' test.

Also fix up the test to use the correct macros to access the linker
list, so that the 'ut addrmap' command actually works.

Signed-off-by: Simon Glass 
---

 board/sandbox/sandbox.c   | 9 +
 configs/sandbox_defconfig | 1 +
 include/addr_map.h| 2 ++
 lib/addr_map.c| 5 +++--
 test/cmd/addrmap.c| 5 ++---
 5 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c
index e054f300c4a..ca9a2ca5b17 100644
--- a/board/sandbox/sandbox.c
+++ b/board/sandbox/sandbox.c
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -155,3 +156,11 @@ int board_late_init(void)
return 0;
 }
 #endif
+
+int init_addr_map(void)
+{
+   if (IS_ENABLED(CONFIG_ADDR_MAP))
+   addrmap_set_entry(0, 0, CONFIG_SYS_SDRAM_SIZE, 0);
+
+   return 0;
+}
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 572cf8edd8b..55c014e1c45 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -313,6 +313,7 @@ CONFIG_WDT_GPIO=y
 CONFIG_WDT_SANDBOX=y
 CONFIG_FS_CBFS=y
 CONFIG_FS_CRAMFS=y
+CONFIG_ADDR_MAP=y
 CONFIG_CMD_DHRYSTONE=y
 CONFIG_ECDSA=y
 CONFIG_ECDSA_VERIFY=y
diff --git a/include/addr_map.h b/include/addr_map.h
index 55d3a6a165a..db3712b5d30 100644
--- a/include/addr_map.h
+++ b/include/addr_map.h
@@ -14,7 +14,9 @@ struct addrmap {
unsigned long vaddr;
 };
 
+#ifdef CONFIG_ADDR_MAP
 extern struct addrmap address_map[CONFIG_SYS_NUM_ADDR_MAP];
+#endif
 
 phys_addr_t addrmap_virt_to_phys(void *vaddr);
 void *addrmap_phys_to_virt(phys_addr_t paddr);
diff --git a/lib/addr_map.c b/lib/addr_map.c
index fb2ef400078..9b3e0a544e4 100644
--- a/lib/addr_map.c
+++ b/lib/addr_map.c
@@ -5,6 +5,7 @@
 
 #include 
 #include 
+#include 
 
 struct addrmap address_map[CONFIG_SYS_NUM_ADDR_MAP];
 
@@ -18,7 +19,7 @@ phys_addr_t addrmap_virt_to_phys(void * vaddr)
if (address_map[i].size == 0)
continue;
 
-   addr = (u64)((u32)vaddr);
+   addr = map_to_sysmem(vaddr);
base = (u64)(address_map[i].vaddr);
upper = (u64)(address_map[i].size) + base - 1;
 
@@ -48,7 +49,7 @@ void *addrmap_phys_to_virt(phys_addr_t paddr)
 
offset = address_map[i].paddr - address_map[i].vaddr;
 
-   return (void *)(unsigned long)(paddr - offset);
+   return map_sysmem(paddr - offset, 0);
}
}
 
diff --git a/test/cmd/addrmap.c b/test/cmd/addrmap.c
index fb744485bbf..1eb5955db17 100644
--- a/test/cmd/addrmap.c
+++ b/test/cmd/addrmap.c
@@ -29,9 +29,8 @@ ADDRMAP_TEST(addrmap_test_basic, UT_TESTF_CONSOLE_REC);
 
 int do_ut_addrmap(struct cmd_tbl *cmdtp, int flag, int argc, char *const 
argv[])
 {
-   struct unit_test *tests = ll_entry_start(struct unit_test,
-addrmap_test);
-   const int n_ents = ll_entry_count(struct unit_test, addrmap_test);
+   struct unit_test *tests = UNIT_TEST_SUITE_START(addrmap_test);
+   const int n_ents = UNIT_TEST_SUITE_COUNT(addrmap_test);
 
return cmd_ut_category("cmd_addrmap", "cmd_addrmap_", tests, n_ents,
   argc, argv);
-- 
2.37.0.144.g8ac04bfd2-goog



[PATCH 3/3] doc: Make a start on docs for fdt command

2022-07-13 Thread Simon Glass
Add some information about the 'fdt addr' subcommand, to get things
started.

Signed-off-by: Simon Glass 
---

 doc/usage/cmd/fdt.rst | 69 +++
 doc/usage/index.rst   |  1 +
 2 files changed, 70 insertions(+)
 create mode 100644 doc/usage/cmd/fdt.rst

diff --git a/doc/usage/cmd/fdt.rst b/doc/usage/cmd/fdt.rst
new file mode 100644
index 000..07fed732e45
--- /dev/null
+++ b/doc/usage/cmd/fdt.rst
@@ -0,0 +1,69 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+fdt command
+===
+
+Synopis
+---
+
+::
+
+fdt addr [-cq] [addr [len]]
+
+Description
+---
+
+The fdt command provides access to flat device tree blobs in memory. It has
+many subcommands, some of which are not documented here.
+
+Flags:
+
+-c
+Select the control FDT (otherwise the working FDT is used).
+-q
+Don't display errors
+
+The control FDT is the one used by U-Boot itself to control various features,
+including driver model. This should only be changed if you really know what you
+are doing, since once U-Boot starts it maintains pointers into the FDT from the
+various driver model data structures.
+
+The working FDT is the one passed to the Operating System when booting. This
+can be freely modified, so far as U-Boot is concerned, since it does not affect
+U-Boot's operation.
+
+fdt addr
+
+
+With no arguments, this shows the address of the current working or control
+FDT.
+
+If the `addr` argument is provided, then this sets the address of the working 
or
+control FDT to the provided address.
+
+If the `len` argument is provided, then the device tree is expanded to that
+size. This can be used to make space for more nodes and properties. It is
+assumed that there is enough space in memory for this expansion.
+
+Example
+---
+
+Get the control address and copy that FDT to free memory::
+
+=> fdt addr -c
+Control fdt: 0aff9fd0
+=> cp.b 0aff9fd0 1 1
+=> md 1 4
+0001: edfe0dd0 5b3d 7800 7c27  ..=[...x..'|
+
+The second word shows the size of the FDT. Now set the working FDT to that
+address and expand it to 0xf000 in size::
+
+=> fdt addr 1 f000
+=> md 1 4
+0001: edfe0dd0 00f0 7800 7c27  ...x..'|
+
+Return value
+
+
+The return value $? indicates whether the command succeeded.
diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index 8b98629d6bf..16a3db5c000 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -43,6 +43,7 @@ Shell commands
cmd/false
cmd/fatinfo
cmd/fatload
+   cmd/fdt
cmd/for
cmd/load
cmd/loadm
-- 
2.37.0.144.g8ac04bfd2-goog



[PATCH 2/3] fdt: Start a test for the fdt command

2022-07-13 Thread Simon Glass
Add a basic test of the 'fdt addr' command, to kick things off.

This includes a new convenience function to run a command from a printf()
string.

Signed-off-by: Simon Glass 
---

 common/cli.c  |  15 +
 include/command.h |  10 +++
 include/test/suites.h |   1 +
 test/cmd/Makefile |   1 +
 test/cmd/fdt.c| 142 ++
 test/cmd_ut.c |   6 ++
 6 files changed, 175 insertions(+)
 create mode 100644 test/cmd/fdt.c

diff --git a/common/cli.c b/common/cli.c
index a7e3d84b68f..a47d6a3f2b4 100644
--- a/common/cli.c
+++ b/common/cli.c
@@ -126,6 +126,21 @@ int run_command_list(const char *cmd, int len, int flag)
return rcode;
 }
 
+int run_commandf(const char *fmt, ...)
+{
+   va_list args;
+   char cmd[128];
+   int i, ret;
+
+   va_start(args, fmt);
+   i = vsnprintf(cmd, sizeof(cmd), fmt, args);
+   va_end(args);
+
+   ret = run_command(cmd, 0);
+
+   return ret;
+}
+
 //
 
 #if defined(CONFIG_CMD_RUN)
diff --git a/include/command.h b/include/command.h
index 0cf12fde396..44c91f655d4 100644
--- a/include/command.h
+++ b/include/command.h
@@ -257,6 +257,16 @@ int board_run_command(const char *cmdline);
 int run_command(const char *cmd, int flag);
 int run_command_repeatable(const char *cmd, int flag);
 
+/**
+ * run_commandf() - Run a command created by a format string
+ *
+ * The command cannot be larger than 127 characters
+ *
+ * @fmt: printf() format string
+ * @...: Arguments to use (flag is always 0)
+ */
+int run_commandf(const char *fmt, ...);
+
 /**
  * Run a list of commands separated by ; or even \0
  *
diff --git a/include/test/suites.h b/include/test/suites.h
index ddb8827fdb1..44025ccecd6 100644
--- a/include/test/suites.h
+++ b/include/test/suites.h
@@ -38,6 +38,7 @@ int do_ut_compression(struct cmd_tbl *cmdtp, int flag, int 
argc,
  char *const argv[]);
 int do_ut_dm(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_env(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
+int do_ut_fdt(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_lib(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_loadm(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
 int do_ut_log(struct cmd_tbl *cmdtp, int flag, int argc, char * const argv[]);
diff --git a/test/cmd/Makefile b/test/cmd/Makefile
index 4b2d7df0d2e..c331757425e 100644
--- a/test/cmd/Makefile
+++ b/test/cmd/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_CONSOLE_RECORD) += test_echo.o
 endif
 obj-y += mem.o
 obj-$(CONFIG_CMD_ADDRMAP) += addrmap.o
+obj-$(CONFIG_CMD_FDT) += fdt.o
 obj-$(CONFIG_CMD_LOADM) += loadm.o
 obj-$(CONFIG_CMD_MEM_SEARCH) += mem_search.o
 obj-$(CONFIG_CMD_PINMUX) += pinmux.o
diff --git a/test/cmd/fdt.c b/test/cmd/fdt.c
new file mode 100644
index 000..100a7ef5ebf
--- /dev/null
+++ b/test/cmd/fdt.c
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Tests for fdt command
+ *
+ * Copyright 2022 Google LLCmap_to_sysmem(fdt));
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Declare a new fdt test */
+#define FDT_TEST(_name, _flags)UNIT_TEST(_name, _flags, fdt_test)
+
+/**
+ * make_test_fdt() - Create an FDT with just a root node
+ *
+ * The size is set to the minimum needed
+ *
+ * @uts: Test state
+ * @fdt: Place to write FDT
+ * @size: Maximum size of space for fdt
+ */
+static int make_test_fdt(struct unit_test_state *uts, void *fdt, int size)
+{
+   ut_assertok(fdt_create(fdt, size));
+   ut_assertok(fdt_finish_reservemap(fdt));
+   ut_assert(fdt_begin_node(fdt, "") >= 0);
+   ut_assertok(fdt_end_node(fdt));
+   ut_assertok(fdt_finish(fdt));
+
+   return 0;
+}
+
+/* Test 'fdt addr' getting/setting address */
+static int fdt_test_addr(struct unit_test_state *uts)
+{
+   const void *fdt_blob, *new_fdt;
+   char fdt[256];
+   ulong addr;
+   int ret;
+
+   ut_assertok(console_record_reset_enable());
+   ut_assertok(run_command("fdt addr -c", 0));
+   ut_assert_nextline("Control fdt: %08lx",
+  (ulong)map_to_sysmem(gd->fdt_blob));
+   ut_assertok(ut_check_console_end(uts));
+
+   /* The working fdt is not set, so this should fail */
+   set_working_fdt_addr(0);
+   ut_asserteq(CMD_RET_FAILURE, run_command("fdt addr", 0));
+   ut_assert_nextline("libfdt fdt_check_header(): FDT_ERR_BADMAGIC");
+   ut_assertok(ut_check_console_end(uts));
+
+   /* Set up a working FDT and try again */
+   ut_assertok(make_test_fdt(uts, fdt, sizeof(fdt)));
+   addr = map_to_sysmem(fdt);
+   set_working_fdt_addr(addr);
+   ut_assertok(run_command("fdt addr", 0));
+   ut_assert_nextline("Working fdt: %08lx", (ulong)map_to_sysmem(fdt));
+   ut

[PATCH v2 0/2] fpga: Convert some options to Kconfig

2022-07-13 Thread Alexander Dahl
Hei hei,

rebased this on recent master.  One patch dropped.  See changelog below.

Greets
Alex

(implicit) v1 -> v2:
  - dropped patch 3, same kconfig symbol addressed with commit
60d45642fe0673514aced37e6cc95d4f0fe02a19 ("fpga: Remove
CONFIG_FPGA_COUNT")

Cc: Wolfgang Wegner 
Cc: Michal Simek 
Cc: Simon Glass 
Cc: Stefan Roese 
Cc: Patrick Delaunay 
Cc: "Marek Behún" 

Alexander Dahl (2):
  fpga: Convert SYS_FPGA_CHECK_CTRLC to Kconfig
  fpga: Convert SYS_FPGA_PROG_FEEDBACK to Kconfig

 README   |  7 ---
 configs/astro_mcf5373l_defconfig |  1 +
 drivers/fpga/Kconfig | 10 ++
 include/configs/astro_mcf5373l.h |  1 -
 scripts/config_whitelist.txt |  1 -
 5 files changed, 11 insertions(+), 9 deletions(-)


base-commit: 36b661dc919da318c163a45f4a220d2e3d9db608
-- 
2.30.2



[PATCH v2 1/2] fpga: Convert SYS_FPGA_CHECK_CTRLC to Kconfig

2022-07-13 Thread Alexander Dahl
From: Alexander Dahl 

After commit 8cca60a2cbf2 ("Kconfig: Remove some symbols from the
whitelist") downstream builds failed for boards setting this in
include/configs/…

Two FPGA drivers consider this definition.

Signed-off-by: Alexander Dahl 
---
 README   | 3 ---
 drivers/fpga/Kconfig | 4 
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/README b/README
index ff0df3797d..8c31e5c0e3 100644
--- a/README
+++ b/README
@@ -1346,9 +1346,6 @@ The following options need to be configured:
If defined, a function that provides delays in the FPGA
configuration driver.
 
-   CONFIG_SYS_FPGA_CHECK_CTRLC
-   Allow Control-C to interrupt FPGA configuration
-
CONFIG_SYS_FPGA_CHECK_ERROR
 
Check for configuration errors during FPGA bitfile
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 76719517f5..53d91676e0 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -91,4 +91,8 @@ config FPGA_ZYNQPL
  Enable FPGA driver for loading bitstream in BIT and BIN format
  on Xilinx Zynq devices.
 
+config SYS_FPGA_CHECK_CTRLC
+   bool "Allow Control-C to interrupt FPGA configuration"
+   depends on FPGA
+
 endmenu
-- 
2.30.2



[PATCH v2 2/2] fpga: Convert SYS_FPGA_PROG_FEEDBACK to Kconfig

2022-07-13 Thread Alexander Dahl
From: Alexander Dahl 

Signed-off-by: Alexander Dahl 
---
 README   | 4 
 configs/astro_mcf5373l_defconfig | 1 +
 drivers/fpga/Kconfig | 6 ++
 include/configs/astro_mcf5373l.h | 1 -
 scripts/config_whitelist.txt | 1 -
 5 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/README b/README
index 8c31e5c0e3..2c4bde0b32 100644
--- a/README
+++ b/README
@@ -1330,10 +1330,6 @@ The following options need to be configured:
Enables support for FPGA family.
(SPARTAN2, SPARTAN3, VIRTEX2, CYCLONE2, ACEX1K, ACEX)
 
-   CONFIG_SYS_FPGA_PROG_FEEDBACK
-
-   Enable printing of hash marks during FPGA configuration.
-
CONFIG_SYS_FPGA_CHECK_BUSY
 
Enable checks on FPGA configuration interface busy
diff --git a/configs/astro_mcf5373l_defconfig b/configs/astro_mcf5373l_defconfig
index 3a44c7e8ec..9f5cb8702c 100644
--- a/configs/astro_mcf5373l_defconfig
+++ b/configs/astro_mcf5373l_defconfig
@@ -33,6 +33,7 @@ CONFIG_FPGA_ALTERA=y
 CONFIG_FPGA_CYCLON2=y
 CONFIG_FPGA_XILINX=y
 CONFIG_FPGA_SPARTAN3=y
+CONFIG_SYS_FPGA_PROG_FEEDBACK=y
 CONFIG_SYS_I2C_LEGACY=y
 CONFIG_SYS_I2C_FSL=y
 CONFIG_SYS_FSL_I2C_OFFSET=0x58000
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 53d91676e0..e152ea14dc 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -95,4 +95,10 @@ config SYS_FPGA_CHECK_CTRLC
bool "Allow Control-C to interrupt FPGA configuration"
depends on FPGA
 
+config SYS_FPGA_PROG_FEEDBACK
+   bool "Progress output during FPGA configuration"
+   depends on FPGA
+   help
+ Enable printing of hash marks during FPGA configuration.
+
 endmenu
diff --git a/include/configs/astro_mcf5373l.h b/include/configs/astro_mcf5373l.h
index a8265e961a..da4d49741d 100644
--- a/include/configs/astro_mcf5373l.h
+++ b/include/configs/astro_mcf5373l.h
@@ -131,7 +131,6 @@
  * it needs non-blocking CFI routines.
  */
 
-#define CONFIG_SYS_FPGA_PROG_FEEDBACK
 #define CONFIG_SYS_FPGA_WAIT   1000
 
 /* End of user parameters to be customized */
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index efc2f3bcf7..fc07c5d257 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -743,7 +743,6 @@ CONFIG_SYS_FPGA_FTIM0
 CONFIG_SYS_FPGA_FTIM1
 CONFIG_SYS_FPGA_FTIM2
 CONFIG_SYS_FPGA_FTIM3
-CONFIG_SYS_FPGA_PROG_FEEDBACK
 CONFIG_SYS_FPGA_SIZE
 CONFIG_SYS_FPGA_WAIT
 CONFIG_SYS_FSL_BMAN_ADDR
-- 
2.30.2



Re: [PATCH v2 2/2] fpga: Convert SYS_FPGA_PROG_FEEDBACK to Kconfig

2022-07-13 Thread Michal Simek




On 7/13/22 14:33, Alexander Dahl wrote:

From: Alexander Dahl 



WARNING: please write a paragraph that describes the config symbol fully

We don't allow patches with empty commit message.




Signed-off-by: Alexander Dahl 
---
  README   | 4 
  configs/astro_mcf5373l_defconfig | 1 +
  drivers/fpga/Kconfig | 6 ++
  include/configs/astro_mcf5373l.h | 1 -
  scripts/config_whitelist.txt | 1 -


Tom can confirm this but IIRC you don't need to remove this from this file.
Tom is doing sync up time to time. It is enough to do conversion only.

M


Re: [PATCH v2 1/2] fpga: Convert SYS_FPGA_CHECK_CTRLC to Kconfig

2022-07-13 Thread Michal Simek




On 7/13/22 14:32, Alexander Dahl wrote:

From: Alexander Dahl 

After commit 8cca60a2cbf2 ("Kconfig: Remove some symbols from the
whitelist") downstream builds failed for boards setting this in
include/configs/…

Two FPGA drivers consider this definition.


2?
board/astro/mcf5373l/fpga.c
drivers/fpga/ACEX1K.c
drivers/fpga/virtex2.c



Signed-off-by: Alexander Dahl 
---
  README   | 3 ---
  drivers/fpga/Kconfig | 4 
  2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/README b/README
index ff0df3797d..8c31e5c0e3 100644
--- a/README
+++ b/README
@@ -1346,9 +1346,6 @@ The following options need to be configured:
If defined, a function that provides delays in the FPGA
configuration driver.
  
-		CONFIG_SYS_FPGA_CHECK_CTRLC

-   Allow Control-C to interrupt FPGA configuration
-
CONFIG_SYS_FPGA_CHECK_ERROR
  
  		Check for configuration errors during FPGA bitfile

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 76719517f5..53d91676e0 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -91,4 +91,8 @@ config FPGA_ZYNQPL
  Enable FPGA driver for loading bitstream in BIT and BIN format
  on Xilinx Zynq devices.
  
+config SYS_FPGA_CHECK_CTRLC

+   bool "Allow Control-C to interrupt FPGA configuration"
+   depends on FPGA


Please write help message.


+
  endmenu



And can you please remove this code from drivers/fpga/virtex2.c

 48 /*
 49  * Don't allow config cycle to be interrupted
 50  */
 51 #ifndef CONFIG_SYS_FPGA_CHECK_CTRLC
 52 #undef CONFIG_SYS_FPGA_CHECK_CTRLC
 53 #endif

it doesn't make any sense.

And with 2/2 please also remove
drivers/fpga/spartan2.c:18:#undef CONFIG_SYS_FPGA_PROG_FEEDBACK
drivers/fpga/virtex2.c:44:#ifndef CONFIG_SYS_FPGA_PROG_FEEDBACK
drivers/fpga/virtex2.c:45:#define CONFIG_SYS_FPGA_PROG_FEEDBACK

Thanks,
Michal


Re: [PATCH v2 2/2] fpga: Convert SYS_FPGA_PROG_FEEDBACK to Kconfig

2022-07-13 Thread Alexander Dahl
Hei hei,

On Wed, Jul 13, 2022 at 02:50:14PM +0200, Michal Simek wrote:
> 
> 
> On 7/13/22 14:33, Alexander Dahl wrote:
> > From: Alexander Dahl 
> 
> 
> WARNING: please write a paragraph that describes the config symbol fully
> 
> We don't allow patches with empty commit message.

In general I would agree.  However several of Tom's patches addressing
kconfig migration have a commit message like this:

  This converts the following to Kconfig: FOO_BAR

This is redundant to the subject saying exactly the same.  I can add
this if you want, but I saw no sense in it.

> 
> 
> > 
> > Signed-off-by: Alexander Dahl 
> > ---
> >   README   | 4 
> >   configs/astro_mcf5373l_defconfig | 1 +
> >   drivers/fpga/Kconfig | 6 ++
> >   include/configs/astro_mcf5373l.h | 1 -
> >   scripts/config_whitelist.txt | 1 -
> 
> Tom can confirm this but IIRC you don't need to remove this from this file.
> Tom is doing sync up time to time. It is enough to do conversion only.

This was done by the script ./tools/moveconfig.py where I just hit
enter with defaults presented.  The other Kconfig patches change
defconfig, but not whitelist.  Seems a little inconsistent to me.  But
I can remove that part, sure.

Greets
Alex

> 
> M

-- 
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN | speech censured, the first thought forbidden, the
 X  AGAINST  | first freedom denied, chains us all irrevocably.«
/ \ HTML MAIL| (Jean-Luc Picard, quoting Judge Aaron Satie)


signature.asc
Description: PGP signature


Re: [PATCH v6 02/13] FWU: Add FWU metadata structure and driver for accessing metadata

2022-07-13 Thread Patrick DELAUNAY

Hi,

On 7/4/22 07:16, Sughosh Ganu wrote:

In the FWU Multi Bank Update feature, the information about the
updatable images is stored as part of the metadata, which is stored on
a dedicated partition. Add the metadata structure, and a driver model
uclass which provides functions to access the metadata. These are
generic API's, and implementations can be added based on parameters
like how the metadata partition is accessed and what type of storage
device houses the metadata.

Signed-off-by: Sughosh Ganu 
---
Changes since V5:
* Change the parameter to the function fwu_plat_get_alt_num to pass
   the FWU udevice pointer instead of passing the metadata device
   directly.

  drivers/Kconfig  |   2 +
  drivers/Makefile |   1 +
  drivers/fwu-mdata/Kconfig|   7 +
  drivers/fwu-mdata/Makefile   |   6 +
  drivers/fwu-mdata/fwu-mdata-uclass.c | 458 +++
  include/dm/uclass-id.h   |   1 +
  include/fwu.h|  49 +++
  include/fwu_mdata.h  |  67 
  8 files changed, 591 insertions(+)
  create mode 100644 drivers/fwu-mdata/Kconfig
  create mode 100644 drivers/fwu-mdata/Makefile
  create mode 100644 drivers/fwu-mdata/fwu-mdata-uclass.c
  create mode 100644 include/fwu.h
  create mode 100644 include/fwu_mdata.h

diff --git a/drivers/Kconfig b/drivers/Kconfig
index b26ca8cf70..adc6079ecf 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -42,6 +42,8 @@ source "drivers/firmware/Kconfig"
  
  source "drivers/fpga/Kconfig"
  
+source "drivers/fwu-mdata/Kconfig"

+
  source "drivers/gpio/Kconfig"
  
  source "drivers/hwspinlock/Kconfig"

diff --git a/drivers/Makefile b/drivers/Makefile
index 67c8af7442..901150bb35 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -83,6 +83,7 @@ obj-y += cache/
  obj-$(CONFIG_CPU) += cpu/
  obj-y += crypto/
  obj-$(CONFIG_FASTBOOT) += fastboot/
+obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata/
  obj-y += misc/
  obj-$(CONFIG_MMC) += mmc/
  obj-$(CONFIG_NVME) += nvme/
diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig
new file mode 100644
index 00..d6a21c8e19
--- /dev/null
+++ b/drivers/fwu-mdata/Kconfig
@@ -0,0 +1,7 @@
+config DM_FWU_MDATA
+   bool "Driver support for accessing FWU Metadata"
+   depends on DM
+   help
+ Enable support for accessing FWU Metadata partitions. The
+ FWU Metadata partitions reside on the same storage device
+ which contains the other FWU updatable firmware images.
diff --git a/drivers/fwu-mdata/Makefile b/drivers/fwu-mdata/Makefile
new file mode 100644
index 00..e53a8c9983
--- /dev/null
+++ b/drivers/fwu-mdata/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (c) 2022, Linaro Limited
+#
+
+obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata-uclass.o
diff --git a/drivers/fwu-mdata/fwu-mdata-uclass.c 
b/drivers/fwu-mdata/fwu-mdata-uclass.c
new file mode 100644
index 00..2092fcfc23
--- /dev/null
+++ b/drivers/fwu-mdata/fwu-mdata-uclass.c
@@ -0,0 +1,458 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2022, Linaro Limited
+ */
+


#define LOG_CATEGORY UCLASS_FWU_MDATA



+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define IMAGE_ACCEPT_SET   BIT(0)
+#define IMAGE_ACCEPT_CLEAR BIT(1)
+
+static int fwu_get_dev_ops(struct udevice **dev,
+  const struct fwu_mdata_ops **ops)
+{
+   int ret;
+
+   ret = uclass_get_device(UCLASS_FWU_MDATA, 0, dev);
+   if (ret) {
+   log_debug("Cannot find fwu device\n");
+   return ret;
+   }
+
+   if ((*ops = device_get_ops(*dev)) == NULL) {
+   log_debug("Cannot get fwu device ops\n");
+   return -ENOSYS;
+   }
+
+   return 0;
+}
+


(...)

with this minor update

Reviewed-by: Patrick Delaunay 

Thanks
Patrick



Re: [PATCH v6 03/13] FWU: Add FWU metadata access driver for GPT partitioned block devices

2022-07-13 Thread Patrick DELAUNAY

Hi,

On 7/4/22 07:16, Sughosh Ganu wrote:

In the FWU Multi Bank Update feature, the information about the
updatable images is stored as part of the metadata, on a separate
partition. Add a driver for reading from and writing to the metadata
when the updatable images and the metadata are stored on a block
device which is formated with GPT based partition scheme.

Signed-off-by: Sughosh Ganu 
---
Changes since V5:
* Changed the logic to store the GPT partitioned block device through
   a priv structure as suggested by Patrick
* Used dev_read_prop() to get the phandle_p instead of
   ofnode_get_property() used earlier as suggested by Patrick
* Make relevant functions static as suggested by Etienne

  drivers/fwu-mdata/Kconfig |   9 +
  drivers/fwu-mdata/Makefile|   1 +
  drivers/fwu-mdata/fwu_mdata_gpt_blk.c | 408 ++
  include/fwu.h |   5 +
  4 files changed, 423 insertions(+)
  create mode 100644 drivers/fwu-mdata/fwu_mdata_gpt_blk.c

diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig
index d6a21c8e19..d5edef19d6 100644
--- a/drivers/fwu-mdata/Kconfig
+++ b/drivers/fwu-mdata/Kconfig
@@ -5,3 +5,12 @@ config DM_FWU_MDATA
  Enable support for accessing FWU Metadata partitions. The
  FWU Metadata partitions reside on the same storage device
  which contains the other FWU updatable firmware images.
+
+config FWU_MDATA_GPT_BLK
+   bool "FWU Metadata access for GPT partitioned Block devices"
+   select PARTITION_TYPE_GUID
+   select PARTITION_UUIDS
+   depends on DM && HAVE_BLOCK_DEVICE && EFI_PARTITION
+   help
+ Enable support for accessing FWU Metadata on GPT partitioned
+ block devices.
diff --git a/drivers/fwu-mdata/Makefile b/drivers/fwu-mdata/Makefile
index e53a8c9983..313049f67a 100644
--- a/drivers/fwu-mdata/Makefile
+++ b/drivers/fwu-mdata/Makefile
@@ -4,3 +4,4 @@
  #
  
  obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata-uclass.o

+obj-$(CONFIG_FWU_MDATA_GPT_BLK) += fwu_mdata_gpt_blk.o
diff --git a/drivers/fwu-mdata/fwu_mdata_gpt_blk.c 
b/drivers/fwu-mdata/fwu_mdata_gpt_blk.c
new file mode 100644
index 00..d904c9492d
--- /dev/null
+++ b/drivers/fwu-mdata/fwu_mdata_gpt_blk.c
@@ -0,0 +1,408 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2022, Linaro Limited
+ */


#define LOG_CATEGORY UCLASS_FWU_MDATA


+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define PRIMARY_PART   BIT(0)
+#define SECONDARY_PART BIT(1)
+#define BOTH_PARTS (PRIMARY_PART | SECONDARY_PART)
+
+#define MDATA_READ BIT(0)
+#define MDATA_WRITEBIT(1)
+


(...)



+
+static const struct fwu_mdata_ops fwu_gpt_blk_ops = {
+   .mdata_check = fwu_gpt_mdata_check,
+   .get_mdata = fwu_gpt_get_mdata,
+   .update_mdata = fwu_gpt_update_mdata,
+};UCLASS_FWU_MDATA

+
+static const struct udevice_id fwu_mdata_ids[] = {
+   { .compatible = "u-boot,fwu-mdata-gpt" },
+   { }
+};
+
+U_BOOT_DRIVER(fwu_mdata_gpt_blk) = {
+   .name   = "fwu-mdata-gpt-blk",
+   .id = UCLASS_FWU_MDATA,
+   .of_match   = fwu_mdata_ids,
+   .ops= &fwu_gpt_blk_ops,
+   .probe  = fwu_mdata_gpt_blk_probe,
+   .priv_auto  = sizeof(struct fwu_mdata_gpt_blk_priv),
+};
diff --git a/include/fwu.h b/include/fwu.h
index e03cfff800..8259c75d12 100644
--- a/include/fwu.h
+++ b/include/fwu.h
@@ -14,6 +14,10 @@
  struct fwu_mdata;
  struct udevice;
  
+struct fwu_mdata_gpt_blk_priv {

+   struct udevice *blk_dev;
+};
+


NITS: really needed in .h file => private, only used by driver in .c ?



  /**
   * @mdata_check: check the validity of the FWU metadata partitions
   * @get_mdata() - Get a FWU metadata copy
@@ -39,6 +43,7 @@ int fwu_get_active_index(u32 *active_idx);
  int fwu_update_active_index(u32 active_idx);
  int fwu_get_image_alt_num(efi_guid_t *image_type_id, u32 update_bank,
  int *alt_num);
+int fwu_verify_mdata(struct fwu_mdata *mdata, bool pri_part);
  int fwu_mdata_check(void);
  int fwu_revert_boot_index(void);
  int fwu_accept_image(efi_guid_t *img_type_id, u32 bank);



with the minor modification (LOG_CATEGORY)


Reviewed-by: Patrick Delaunay 

Thanks
Patrick




Re: [PATCH 3/3] fdt: introduce apply_all command

2022-07-13 Thread Andre Przywara
On Tue, 12 Jul 2022 04:58:35 -0600
Simon Glass  wrote:

Hi Simon,

many thanks for having a look!

> On Tue, 5 Jul 2022 at 11:14, Andre Przywara  wrote:
> >
> > Explicitly specifying the exact filenames of devicetree overlays files
> > on a U-Boot command line can be quite tedious for users, especially
> > when it should be made persistent for every boot.
> >
> > To simplify the task of applying (custom) DT overlays, introduce a
> > "fdt apply-all" subcommand, that iterates a given directory in any
> > supported filesystem, and tries to apply every .dtbo file found it
> > there.
> >
> > This allows users to simply drop a DT overlay file into a magic
> > directory, and it will be applied on the next boot automatically,
> > by the virtue of just a generic U-Boot command call.
> >
> > Signed-off-by: Andre Przywara 
> > ---
> >  cmd/fdt.c | 89 ++-
> >  1 file changed, 88 insertions(+), 1 deletion(-)  
> 
> This looks OK, but can you please add a test (see test/dm/acpi.c for
> example) and doc/usage/cmd file?

Is that supposed to run inside the sandbox? I briefly tested this there,
only to realise that the sandbox' hostfs does not support the directory
operations (fs_opendir_unsupported). I haven't thought about it too much,
nor do I have much experience with U-Boot's test framework, but this sounds
like a problem?

> Also, apply_all is a bit annoying as we try to allow command
> completion and abbreviations to work. Given that the args are
> different I don't think a -d (for dir) flag makes sense.
> 
> Perhaps 'fdt fsapply' ?

Yeah, I wasn't happy with that name either, but couldn't come up with a
better name. "fsapply" seems to be a nice alternative, I will go with that!

Cheers,
Andre

> 
> Regards,
> Simon
> 
> 
> >
> > diff --git a/cmd/fdt.c b/cmd/fdt.c
> > index d6878c96f1..dc80e13c3d 100644
> > --- a/cmd/fdt.c
> > +++ b/cmd/fdt.c
> > @@ -12,12 +12,14 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #define MAX_LEVEL  32  /* how deeply nested we will go */
> >  #define SCRATCHPAD 1024/* bytes of scratchpad memory */
> > @@ -107,6 +109,81 @@ static int fdt_get_header_value(int argc, char *const 
> > argv[])
> > return CMD_RET_FAILURE;
> >  }
> >
> > +#ifdef CONFIG_OF_LIBFDT_OVERLAY
> > +static int apply_all_overlays(const char *ifname, const char *dev_part_str,
> > + const char *dirname)
> > +{
> > +   unsigned long addr;
> > +   struct fdt_header *dtbo;
> > +   const char *addr_str;
> > +   struct fs_dir_stream *dirs;
> > +   struct fs_dirent *dent;
> > +   char fname[256], *name_beg;
> > +   int ret;
> > +
> > +   addr_str = env_get("fdtoverlay_addr_r");
> > +   if (!addr_str) {
> > +   printf("Invalid fdtoverlay_addr_r for loading overlays\n");
> > +   return CMD_RET_FAILURE;
> > +   }
> > +   addr = hextoul(addr_str, NULL);
> > +
> > +   ret = fs_set_blk_dev(ifname, dev_part_str, FS_TYPE_ANY);
> > +   if (ret)
> > +   return CMD_RET_FAILURE;
> > +
> > +   if (!dirname)
> > +   dirname = "/";
> > +   dirs = fs_opendir(dirname);
> > +   if (!dirs) {
> > +   printf("Cannot find directory \"%s\"\n", dirname);
> > +   return CMD_RET_FAILURE;
> > +   }
> > +
> > +   strcpy(fname, dirname);
> > +   name_beg = strchr(fname, 0);
> > +   if (name_beg[-1] != '/')
> > +   *name_beg++ = '/';
> > +
> > +   dtbo = map_sysmem(addr, 0);
> > +   while ((dent = fs_readdir(dirs))) {
> > +   loff_t size = 0;
> > +
> > +   if (dent->type == FS_DT_DIR)
> > +   continue;
> > +
> > +   if (strcmp(dent->name + strlen(dent->name) - 5, ".dtbo"))
> > +   continue;
> > +
> > +   printf("%s: ", dent->name);
> > +   strcpy(name_beg, dent->name);
> > +   fs_set_blk_dev(ifname, dev_part_str, FS_TYPE_ANY);
> > +   if (dent->size > SZ_2M)
> > +   size = SZ_2M;
> > +   else
> > +   size = dent->size;
> > +   ret = fs_read(fname, addr, 0, size, &size);
> > +   if (ret) {
> > +   printf("  errno: %d\n", ret);
> > +   continue;
> > +   }
> > +   if (!fdt_valid(&dtbo)) {
> > +   /* fdt_valid() clears the pointer upon failure */
> > +   dtbo = map_sysmem(addr, 0);
> > +   continue;
> > +   }
> > +
> > +   if (fdt_overlay_apply_verbose(working_fdt, dtbo) == 0)
> > +   printf("applied\n");
> > +   }
> > +   unmap_sysmem(dtbo);
> > +
> > +   fs_closedir(dirs);
>

Re: [PATCH v2 1/2] fpga: Convert SYS_FPGA_CHECK_CTRLC to Kconfig

2022-07-13 Thread Alexander Dahl
Hello Michal,

On Wed, Jul 13, 2022 at 02:56:08PM +0200, Michal Simek wrote:
> 
> 
> On 7/13/22 14:32, Alexander Dahl wrote:
> > From: Alexander Dahl 
> > 
> > After commit 8cca60a2cbf2 ("Kconfig: Remove some symbols from the
> > whitelist") downstream builds failed for boards setting this in
> > include/configs/…
> > 
> > Two FPGA drivers consider this definition.
> 
> 2?
> board/astro/mcf5373l/fpga.c
> drivers/fpga/ACEX1K.c
> drivers/fpga/virtex2.c

These are one board and two drivers.  What is your question?

Greets
Alex

> 
> > 
> > Signed-off-by: Alexander Dahl 
> > ---
> >   README   | 3 ---
> >   drivers/fpga/Kconfig | 4 
> >   2 files changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/README b/README
> > index ff0df3797d..8c31e5c0e3 100644
> > --- a/README
> > +++ b/README
> > @@ -1346,9 +1346,6 @@ The following options need to be configured:
> > If defined, a function that provides delays in the FPGA
> > configuration driver.
> > -   CONFIG_SYS_FPGA_CHECK_CTRLC
> > -   Allow Control-C to interrupt FPGA configuration
> > -
> > CONFIG_SYS_FPGA_CHECK_ERROR
> > Check for configuration errors during FPGA bitfile
> > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > index 76719517f5..53d91676e0 100644
> > --- a/drivers/fpga/Kconfig
> > +++ b/drivers/fpga/Kconfig
> > @@ -91,4 +91,8 @@ config FPGA_ZYNQPL
> >   Enable FPGA driver for loading bitstream in BIT and BIN format
> >   on Xilinx Zynq devices.
> > +config SYS_FPGA_CHECK_CTRLC
> > +   bool "Allow Control-C to interrupt FPGA configuration"
> > +   depends on FPGA
> 
> Please write help message.

Okay, I'll have to invent a new message here, if the prompt is not
self explaining enough.  Since this is not conversion, but adding a
new message we did not have before, should this go into a separate
patch?

> 
> > +
> >   endmenu
> 
> 
> And can you please remove this code from drivers/fpga/virtex2.c
> 
>  48 /*
>  49  * Don't allow config cycle to be interrupted
>  50  */
>  51 #ifndef CONFIG_SYS_FPGA_CHECK_CTRLC
>  52 #undef CONFIG_SYS_FPGA_CHECK_CTRLC
>  53 #endif
> 
> it doesn't make any sense.

I have no hardware to test this and this is out of scope of the
conversion patch itself.

> 
> And with 2/2 please also remove
> drivers/fpga/spartan2.c:18:#undef CONFIG_SYS_FPGA_PROG_FEEDBACK
> drivers/fpga/virtex2.c:44:#ifndef CONFIG_SYS_FPGA_PROG_FEEDBACK
> drivers/fpga/virtex2.c:45:#define CONFIG_SYS_FPGA_PROG_FEEDBACK
> 
> Thanks,
> Michal

I may be able to add an additional patch or two, but those are all
FPGAs I have no experience with and I can not test those.  This would
be more or less guessing based on code reading.  I can try next week,
not able to do this currently.

Thanks for your review.

Greets
Alex

-- 
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN | speech censured, the first thought forbidden, the
 X  AGAINST  | first freedom denied, chains us all irrevocably.«
/ \ HTML MAIL| (Jean-Luc Picard, quoting Judge Aaron Satie)


signature.asc
Description: PGP signature


Re: [PATCH v6 05/13] stm32mp1: dk2: Add image information for capsule updates

2022-07-13 Thread Patrick DELAUNAY

Hi,

On 7/4/22 07:16, Sughosh Ganu wrote:

Enabling capsule update functionality on the platform requires
populating information on the images that are to be updated using the
functionality. Do so for the DK2 board.

Signed-off-by: Sughosh Ganu 
---
Changes since V5: None

  board/st/stm32mp1/stm32mp1.c   | 19 +++
  include/configs/stm32mp15_common.h |  4 
  2 files changed, 23 insertions(+)

diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 07b1a63db7..c6bb7562f6 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -11,6 +11,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -92,6 +93,16 @@ DECLARE_GLOBAL_DATA_PTR;
  #define USB_START_LOW_THRESHOLD_UV123
  #define USB_START_HIGH_THRESHOLD_UV   215
  
+#if CONFIG_IS_ENABLED(EFI_HAVE_CAPSULE_SUPPORT)

+struct efi_fw_image fw_images[1];
+
+struct efi_capsule_update_info update_info = {
+   .images = fw_images,
+};
+
+u8 num_image_type_guids = ARRAY_SIZE(fw_images);
+#endif /* EFI_HAVE_CAPSULE_SUPPORT */
+
  int board_early_init_f(void)
  {
/* nothing to do, only used in SPL */
@@ -675,6 +686,14 @@ int board_init(void)
  
  	setup_led(LEDST_ON);
  
+#if CONFIG_IS_ENABLED(EFI_HAVE_CAPSULE_SUPPORT)

+   if (board_is_dk2()) {
+   efi_guid_t image_type_guid = STM32MP1_DK2_FIP_IMAGE_GUID;


STM32MP15_DK2_FIP_IMAGE_GUID


+   guidcpy(&fw_images[0].image_type_id, &image_type_guid);
+   fw_images[0].fw_name = u"STM32MP1-DK2-FIP";


fw_images[0].fw_name = u"STM32MP15-DK2-FIP";


+   fw_images[0].image_index = 5;
+   }
+#endif
return 0;
  }
  
diff --git a/include/configs/stm32mp15_common.h b/include/configs/stm32mp15_common.h

index 6b40cdb017..6a1ae9788d 100644
--- a/include/configs/stm32mp15_common.h
+++ b/include/configs/stm32mp15_common.h
@@ -54,6 +54,10 @@
  #define CONFIG_SYS_AUTOLOAD   "no"
  #endif
  
+#define STM32MP1_DK2_FIP_IMAGE_GUID \

+   EFI_GUID(0x19d5df83, 0x11b0, 0x457b, 0xbe, 0x2c, \
+0x75, 0x59, 0xc1, 0x31, 0x42, 0xa5)
+


#define STM32MP15_DK2_FIP_IMAGE_GUID \



  
/*/
  #ifdef CONFIG_DISTRO_DEFAULTS
  
/*/



with the modification s/STM32MP1/STM32MP15/

to avoid confusion with STM32MP13


Reviewed-by: Patrick Delaunay 

Thanks
Patrick




Re: [PATCH v6 06/13] FWU: stm32mp1: Add helper functions for accessing FWU metadata

2022-07-13 Thread Patrick DELAUNAY

Hi,

On 7/4/22 07:16, Sughosh Ganu wrote:

Add helper functions needed for accessing the FWU metadata which
contains information on the updatable images. These functions have
been added for the STM32MP157C-DK2 board which has the updatable
images on the uSD card, formatted as GPT partitions.

Signed-off-by: Sughosh Ganu 
---
Changes since V5:
* Change the mechanism to get the block device descriptor in
   fwu_plat_get_alt_num() due to introduction of struct
   fwu_mdata_gpt_blk_priv in the earlier patch.

  board/st/stm32mp1/stm32mp1.c | 40 
  include/fwu.h|  3 ++
  lib/fwu_updates/Makefile |  6 +++
  lib/fwu_updates/fwu_gpt.c| 88 
  4 files changed, 137 insertions(+)
  create mode 100644 lib/fwu_updates/Makefile
  create mode 100644 lib/fwu_updates/fwu_gpt.c



Reviewed-by: Patrick Delaunay 

Thanks
Patrick


Re: [PATCH v6 07/13] FWU: STM32MP1: Add support to read boot index from backup register

2022-07-13 Thread Patrick DELAUNAY

Hi,

On 7/4/22 07:16, Sughosh Ganu wrote:

The FWU Multi Bank Update feature allows the platform to boot the
firmware images from one of the partitions(banks). The first stage
bootloader(fsbl) passes the value of the boot index, i.e. the bank
from which the firmware images were booted from to U-Boot. On the
STM32MP157C-DK2 board, this value is passed through one of the SoC's
backup register. Add a function to read the boot index value from the
backup register.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Patrick Delaunay 
---
Changes since V5:
* Shuffled the location of the TAMP_FWU_* macros as suggested by
   Patrick

  arch/arm/mach-stm32mp/include/mach/stm32.h | 5 +
  board/st/stm32mp1/stm32mp1.c   | 8 
  include/fwu.h  | 1 +
  3 files changed, 14 insertions(+)




Reviewed-by: Patrick Delaunay 

Thanks
Patrick



Re: [PATCH v2 1/2] fpga: Convert SYS_FPGA_CHECK_CTRLC to Kconfig

2022-07-13 Thread Michal Simek




On 7/13/22 15:20, Alexander Dahl wrote:

Hello Michal,

On Wed, Jul 13, 2022 at 02:56:08PM +0200, Michal Simek wrote:



On 7/13/22 14:32, Alexander Dahl wrote:

From: Alexander Dahl 

After commit 8cca60a2cbf2 ("Kconfig: Remove some symbols from the
whitelist") downstream builds failed for boards setting this in
include/configs/…

Two FPGA drivers consider this definition.


2?
board/astro/mcf5373l/fpga.c
drivers/fpga/ACEX1K.c
drivers/fpga/virtex2.c


These are one board and two drivers.  What is your question?


The first one looks like spartan3 fpga driver in board folder (incorrect 
location). It means I consider this as 3 fpga drivers not 2.


But at the end of day just remove that sentence and that's it. Everybody sees 
what you have changed.


Thanks,
Michal


Re: [PATCH] arm: dts: k3-am64-ddr fix typo causing DDR4 register corruption

2022-07-13 Thread Tom Rini
On Tue, Jul 12, 2022 at 07:59:04PM -0500, Anand Gadiyar wrote:

> The entry for DDRSS_PI_321_DATA was accidentally repeated leading to the
> last few PI registers being incorrectly programmed.
> 
> Fix this.
> 
> Reported-by: Bin Liu 
> Signed-off-by: Vignesh Raghavendra 
> Signed-off-by: Anand Gadiyar 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


Re: [PULL] Pull request for u-boot next / v2022.10 = u-boot-stm32-20220712

2022-07-13 Thread Tom Rini
On Wed, Jul 13, 2022 at 09:57:48AM +0200, Patrick DELAUNAY wrote:

> I Tom,
> 
> Please pull the STM32 related fixes for u-boot/next, v2022.10:
> u-boot-stm32-20220712
> 
> - Alignment with Linux kernel device tree v5.19 for stm32mp15 and stm32mp13
> - Add OP-TEE nodes for stm32mp13x, aligned with upstreamed OP-TEE
> - Introduce of_to_plat ops in stm32_sdmmc2 driver
> - Activate more features in stm32mp13 defconfig and support of STM32MP13x
> Rev.Y
> - Drop fastboot and stm32prog trigger gpios on STM32MP15x DHCOM board
> 
> CI status:
> https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/12721
> 
> Thanks,
> Patrick
> 
> git request-pull origin/next
> https://source.denx.de/u-boot/custodians/u-boot-stm.git/
> u-boot-stm32-20220712
> 
> 
> The following changes since commit 05a4859637567b13219efd6f1707fb236648b1b7:
> 
>   Merge branch '2022-07-08-Kconfig-migrations' into next (2022-07-08
> 18:03:08 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-stm.git/
> tags/u-boot-stm32-20220712
> 
> for you to fetch changes up to 48d9eaf6826a1816c5f9839a564ea6338da609a7:
> 
>   arm: dts: stm32mp1: Drop fastboot and stm32prog trigger gpios on DHCOM
> (2022-07-12 11:48:15 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


net: emaclite: Fixes, enable driver for other archs

2022-07-13 Thread Samuel Obuch
These patches solve a few issues with the driver observed on a RISC-V platform.




[PATCH 1/3] net: emaclite: fix broken build

2022-07-13 Thread Samuel Obuch
Function ioremap_nocache seems to be defined only for mips and microblaze
architectures. Therefore, the function call in the emaclite driver causes
this driver to be unusable with other architectures, for example riscv.

Signed-off-by: Samuel Obuch 
---
 drivers/net/xilinx_emaclite.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index 6c9f1f7c27..5cd88e04fe 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -615,8 +615,12 @@ static int emaclite_of_to_plat(struct udevice *dev)
int offset = 0;
 
pdata->iobase = dev_read_addr(dev);
+#if defined(CONFIG_MICROBLAZE) || defined(CONFIG_MIPS)
emaclite->regs = (struct emaclite_regs *)ioremap_nocache(pdata->iobase,
 0x1);
+#else
+   emaclite->regs = (struct emaclite_regs *)pdata->iobase;
+#endif
 
emaclite->phyaddr = -1;
 
-- 
2.31.1



[PATCH 2/3] net: emaclite: fix xemaclite_alignedread/write functions

2022-07-13 Thread Samuel Obuch
Use __raw_read* and __raw_write* functions to ensure read/write
is passed to the memory-mapped regions, as non-volatile accesses
may get optimised out.

Signed-off-by: Samuel Obuch 
---
 drivers/net/xilinx_emaclite.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index 5cd88e04fe..de7a2dee0b 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -113,12 +113,12 @@ static void xemaclite_alignedread(u32 *srcptr, void 
*destptr, u32 bytecount)
/* Word aligned buffer, no correction needed. */
to32ptr = (u32 *) destptr;
while (bytecount > 3) {
-   *to32ptr++ = *from32ptr++;
+   *to32ptr++ = __raw_readl(from32ptr++);
bytecount -= 4;
}
to8ptr = (u8 *) to32ptr;
 
-   alignbuffer = *from32ptr++;
+   alignbuffer = __raw_readl(from32ptr++);
from8ptr = (u8 *) &alignbuffer;
 
for (i = 0; i < bytecount; i++)
@@ -136,8 +136,7 @@ static void xemaclite_alignedwrite(void *srcptr, u32 
*destptr, u32 bytecount)
 
from32ptr = (u32 *) srcptr;
while (bytecount > 3) {
-
-   *to32ptr++ = *from32ptr++;
+   __raw_writel(*from32ptr++, to32ptr++);
bytecount -= 4;
}
 
@@ -148,7 +147,7 @@ static void xemaclite_alignedwrite(void *srcptr, u32 
*destptr, u32 bytecount)
for (i = 0; i < bytecount; i++)
*to8ptr++ = *from8ptr++;
 
-   *to32ptr++ = alignbuffer;
+   __raw_writel(alignbuffer, to32ptr++);
 }
 
 static int wait_for_bit(const char *func, u32 *reg, const u32 mask,
-- 
2.31.1



[PATCH 3/3] net: emaclite: fix handling for IP packets with specific lengths

2022-07-13 Thread Samuel Obuch
The maximum length is capped similarly to the emaclite_send function.
Avoid integer underflow for values of ip->ip_len < 30, the minimum
length of an IP packet is 21 bytes.

Signed-off-by: Samuel Obuch 
---
 drivers/net/xilinx_emaclite.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index de7a2dee0b..21c450ec46 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -518,6 +518,8 @@ try_again:
length = ntohs(ip->ip_len);
length += ETHER_HDR_SIZE + ETH_FCS_LEN;
debug("IP Packet %x\n", length);
+   if (length > PKTSIZE)
+   length = PKTSIZE;
break;
default:
debug("Other Packet\n");
@@ -526,7 +528,7 @@ try_again:
}
 
/* Read the rest of the packet which is longer then first read */
-   if (length != first_read)
+   if (length > first_read)
xemaclite_alignedread(addr + first_read,
  etherrxbuff + first_read,
  length - first_read);
-- 
2.31.1



Re: [PATCH v2 1/2] fpga: Convert SYS_FPGA_CHECK_CTRLC to Kconfig

2022-07-13 Thread Alexander Dahl
Hello Michal,

On Wed, Jul 13, 2022 at 03:20:44PM +0200, Alexander Dahl wrote:
> Hello Michal,
> 
> On Wed, Jul 13, 2022 at 02:56:08PM +0200, Michal Simek wrote:
> > 
> > 
> > On 7/13/22 14:32, Alexander Dahl wrote:
> > > From: Alexander Dahl 
> > > 
> > > After commit 8cca60a2cbf2 ("Kconfig: Remove some symbols from the
> > > whitelist") downstream builds failed for boards setting this in
> > > include/configs/…
> > > 
> > > Two FPGA drivers consider this definition.
> > 
> > 2?
> > board/astro/mcf5373l/fpga.c
> > drivers/fpga/ACEX1K.c
> > drivers/fpga/virtex2.c
> 
> These are one board and two drivers.  What is your question?
> 
> Greets
> Alex

I'm sorry, this was misleading.  I added some more comments below and
forgot to remove this line indicating end of message.  Considering
your answer I guess you stopped reading here? 

> 
> > 
> > > 
> > > Signed-off-by: Alexander Dahl 
> > > ---
> > >   README   | 3 ---
> > >   drivers/fpga/Kconfig | 4 
> > >   2 files changed, 4 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/README b/README
> > > index ff0df3797d..8c31e5c0e3 100644
> > > --- a/README
> > > +++ b/README
> > > @@ -1346,9 +1346,6 @@ The following options need to be configured:
> > >   If defined, a function that provides delays in the FPGA
> > >   configuration driver.
> > > - CONFIG_SYS_FPGA_CHECK_CTRLC
> > > - Allow Control-C to interrupt FPGA configuration
> > > -
> > >   CONFIG_SYS_FPGA_CHECK_ERROR
> > >   Check for configuration errors during FPGA bitfile
> > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > > index 76719517f5..53d91676e0 100644
> > > --- a/drivers/fpga/Kconfig
> > > +++ b/drivers/fpga/Kconfig
> > > @@ -91,4 +91,8 @@ config FPGA_ZYNQPL
> > > Enable FPGA driver for loading bitstream in BIT and BIN format
> > > on Xilinx Zynq devices.
> > > +config SYS_FPGA_CHECK_CTRLC
> > > + bool "Allow Control-C to interrupt FPGA configuration"
> > > + depends on FPGA
> > 
> > Please write help message.
> 
> Okay, I'll have to invent a new message here, if the prompt is not
> self explaining enough.  Since this is not conversion, but adding a
> new message we did not have before, should this go into a separate
> patch?
> 
> > 
> > > +
> > >   endmenu
> > 
> > 
> > And can you please remove this code from drivers/fpga/virtex2.c
> > 
> >  48 /*
> >  49  * Don't allow config cycle to be interrupted
> >  50  */
> >  51 #ifndef CONFIG_SYS_FPGA_CHECK_CTRLC
> >  52 #undef CONFIG_SYS_FPGA_CHECK_CTRLC
> >  53 #endif
> > 
> > it doesn't make any sense.
> 
> I have no hardware to test this and this is out of scope of the
> conversion patch itself.
> 
> > 
> > And with 2/2 please also remove
> > drivers/fpga/spartan2.c:18:#undef CONFIG_SYS_FPGA_PROG_FEEDBACK
> > drivers/fpga/virtex2.c:44:#ifndef CONFIG_SYS_FPGA_PROG_FEEDBACK
> > drivers/fpga/virtex2.c:45:#define CONFIG_SYS_FPGA_PROG_FEEDBACK
> > 
> > Thanks,
> > Michal
> 
> I may be able to add an additional patch or two, but those are all
> FPGAs I have no experience with and I can not test those.  This would
> be more or less guessing based on code reading.  I can try next week,
> not able to do this currently.
> 
> Thanks for your review.

I'll look into all this next week again.

Greets
Alex

> 
> Greets
> Alex
> 
> -- 
> /"\ ASCII RIBBON | »With the first link, the chain is forged. The first
> \ / CAMPAIGN | speech censured, the first thought forbidden, the
>  X  AGAINST  | first freedom denied, chains us all irrevocably.«
> / \ HTML MAIL| (Jean-Luc Picard, quoting Judge Aaron Satie)



-- 
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN | speech censured, the first thought forbidden, the
 X  AGAINST  | first freedom denied, chains us all irrevocably.«
/ \ HTML MAIL| (Jean-Luc Picard, quoting Judge Aaron Satie)


signature.asc
Description: PGP signature


Re: [PATCH v2 1/2] fpga: Convert SYS_FPGA_CHECK_CTRLC to Kconfig

2022-07-13 Thread Michal Simek




On 7/13/22 16:07, Alexander Dahl wrote:

Hello Michal,

On Wed, Jul 13, 2022 at 03:20:44PM +0200, Alexander Dahl wrote:

Hello Michal,

On Wed, Jul 13, 2022 at 02:56:08PM +0200, Michal Simek wrote:



On 7/13/22 14:32, Alexander Dahl wrote:

From: Alexander Dahl 

After commit 8cca60a2cbf2 ("Kconfig: Remove some symbols from the
whitelist") downstream builds failed for boards setting this in
include/configs/…

Two FPGA drivers consider this definition.


2?
board/astro/mcf5373l/fpga.c
drivers/fpga/ACEX1K.c
drivers/fpga/virtex2.c


These are one board and two drivers.  What is your question?

Greets
Alex


I'm sorry, this was misleading.  I added some more comments below and
forgot to remove this line indicating end of message.  Considering
your answer I guess you stopped reading here?


yes I did.








Signed-off-by: Alexander Dahl 
---
   README   | 3 ---
   drivers/fpga/Kconfig | 4 
   2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/README b/README
index ff0df3797d..8c31e5c0e3 100644
--- a/README
+++ b/README
@@ -1346,9 +1346,6 @@ The following options need to be configured:
If defined, a function that provides delays in the FPGA
configuration driver.
-   CONFIG_SYS_FPGA_CHECK_CTRLC
-   Allow Control-C to interrupt FPGA configuration
-
CONFIG_SYS_FPGA_CHECK_ERROR
Check for configuration errors during FPGA bitfile
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 76719517f5..53d91676e0 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -91,4 +91,8 @@ config FPGA_ZYNQPL
  Enable FPGA driver for loading bitstream in BIT and BIN format
  on Xilinx Zynq devices.
+config SYS_FPGA_CHECK_CTRLC
+   bool "Allow Control-C to interrupt FPGA configuration"
+   depends on FPGA


Please write help message.


Okay, I'll have to invent a new message here, if the prompt is not
self explaining enough.  Since this is not conversion, but adding a
new message we did not have before, should this go into a separate
patch?


I can't see any reason to have it in separate patch.
And maybe CTRL+C is better then Control-C






+
   endmenu



And can you please remove this code from drivers/fpga/virtex2.c

  48 /*
  49  * Don't allow config cycle to be interrupted
  50  */
  51 #ifndef CONFIG_SYS_FPGA_CHECK_CTRLC
  52 #undef CONFIG_SYS_FPGA_CHECK_CTRLC
  53 #endif

it doesn't make any sense.


I have no hardware to test this and this is out of scope of the
conversion patch itself.


likely none has virtex2 around to test it. When you are converting that symbol 
it is good to fix this. Separate patch is fine to get rid of this.





And with 2/2 please also remove
drivers/fpga/spartan2.c:18:#undef CONFIG_SYS_FPGA_PROG_FEEDBACK
drivers/fpga/virtex2.c:44:#ifndef CONFIG_SYS_FPGA_PROG_FEEDBACK
drivers/fpga/virtex2.c:45:#define CONFIG_SYS_FPGA_PROG_FEEDBACK

Thanks,
Michal


I may be able to add an additional patch or two, but those are all
FPGAs I have no experience with and I can not test those.  This would
be more or less guessing based on code reading.  I can try next week,
not able to do this currently.

Thanks for your review.


I'll look into all this next week again.


None really has spartan2/virtex2 hw around. I personally started with Spartan3 
but didn't power it up for a lot of years. It is just about that there is no 
reason to undefine something if we have Kconfig symbol for it. Just enable it or 
disable it. That's it. No need to test it on any HW.


Thanks,
Michal



Re: [PATCH] armv8: mach-k3: correct define checking for AM625/AM642 memory maps

2022-07-13 Thread Tom Rini
On Wed, Jul 13, 2022 at 04:49:36AM -0700, Matt Ranostay wrote:

> Using CONFIG_IS_ENABLED breaks accessing memory map structure when
> doing a A53 SPL build for AM625 and AM642 platforms. This is due to
> 'abc if CONFIG_SPL_BUILD is defined and CONFIG_SPL_FOO is set to 'y''
> in which there is no CONFIG_SPL_SOC_K3_AM625/CONFIG_SPL_SOC_K3_AM642
> defined in the configuration.
> 
> For the A53 SPL builds on these platform to access the memory mapping
> which it will need for enabling the mmu/cache it must use #if defined(X)
> checks and not CONFIG_IS_ENABLED.
> 
> Cc: Suman Anna 
> Cc: Neha Francis 
> Signed-off-by: Matt Ranostay 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 2/2] fpga: Convert SYS_FPGA_PROG_FEEDBACK to Kconfig

2022-07-13 Thread Tom Rini
On Wed, Jul 13, 2022 at 03:11:09PM +0200, Alexander Dahl wrote:
> Hei hei,
> 
> On Wed, Jul 13, 2022 at 02:50:14PM +0200, Michal Simek wrote:
> > 
> > 
> > On 7/13/22 14:33, Alexander Dahl wrote:
> > > From: Alexander Dahl 
> > 
> > 
> > WARNING: please write a paragraph that describes the config symbol fully
> > 
> > We don't allow patches with empty commit message.
> 
> In general I would agree.  However several of Tom's patches addressing
> kconfig migration have a commit message like this:
> 
>   This converts the following to Kconfig: FOO_BAR
> 
> This is redundant to the subject saying exactly the same.  I can add
> this if you want, but I saw no sense in it.

Yes, the moveconfig.py tool adds that and it's a little redundant
sometimes, but is (a) a starting point for the times when the conversion
required a little extra work or (b) lists all the symbols when you
migrate more than one at a time.

> > > Signed-off-by: Alexander Dahl 
> > > ---
> > >   README   | 4 
> > >   configs/astro_mcf5373l_defconfig | 1 +
> > >   drivers/fpga/Kconfig | 6 ++
> > >   include/configs/astro_mcf5373l.h | 1 -
> > >   scripts/config_whitelist.txt | 1 -
> > 
> > Tom can confirm this but IIRC you don't need to remove this from this file.
> > Tom is doing sync up time to time. It is enough to do conversion only.
> 
> This was done by the script ./tools/moveconfig.py where I just hit
> enter with defaults presented.  The other Kconfig patches change
> defconfig, but not whitelist.  Seems a little inconsistent to me.  But
> I can remove that part, sure.

So, I usually run "-yC" with moveconfig.py as that gives the commit
message.  It's not a problem, really, to touch
scripts/config_whitelist.txt it just also can conflict easily.  Omitting
it makes it easier to "git am", fixing up / dropping that hunk if it
conflicts later is also fine.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 1/2] fpga: Convert SYS_FPGA_CHECK_CTRLC to Kconfig

2022-07-13 Thread Tom Rini
On Wed, Jul 13, 2022 at 03:20:46PM +0200, Alexander Dahl wrote:
> Hello Michal,
> 
> On Wed, Jul 13, 2022 at 02:56:08PM +0200, Michal Simek wrote:
[snip]
> > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > > index 76719517f5..53d91676e0 100644
> > > --- a/drivers/fpga/Kconfig
> > > +++ b/drivers/fpga/Kconfig
> > > @@ -91,4 +91,8 @@ config FPGA_ZYNQPL
> > > Enable FPGA driver for loading bitstream in BIT and BIN format
> > > on Xilinx Zynq devices.
> > > +config SYS_FPGA_CHECK_CTRLC
> > > + bool "Allow Control-C to interrupt FPGA configuration"
> > > + depends on FPGA
> > 
> > Please write help message.
> 
> Okay, I'll have to invent a new message here, if the prompt is not
> self explaining enough.  Since this is not conversion, but adding a
> new message we did not have before, should this go into a separate
> patch?

If you understand things well enough to add a line or two under "help",
that would be appreciated.  It may be a little redundant soundiing, and
if it's not long enough checkpatch might still complain (but can be
ignored).

> > And can you please remove this code from drivers/fpga/virtex2.c
> > 
> >  48 /*
> >  49  * Don't allow config cycle to be interrupted
> >  50  */
> >  51 #ifndef CONFIG_SYS_FPGA_CHECK_CTRLC
> >  52 #undef CONFIG_SYS_FPGA_CHECK_CTRLC
> >  53 #endif
> > 
> > it doesn't make any sense.
> 
> I have no hardware to test this and this is out of scope of the
> conversion patch itself.

This kind of code logic needs to be enforced in Kconfig instead with
depends lines.  We can make sure it's size-neutral.

> > And with 2/2 please also remove
> > drivers/fpga/spartan2.c:18:#undef CONFIG_SYS_FPGA_PROG_FEEDBACK
> > drivers/fpga/virtex2.c:44:#ifndef CONFIG_SYS_FPGA_PROG_FEEDBACK
> > drivers/fpga/virtex2.c:45:#define CONFIG_SYS_FPGA_PROG_FEEDBACK
> > 
> > Thanks,
> > Michal
> 
> I may be able to add an additional patch or two, but those are all
> FPGAs I have no experience with and I can not test those.  This would
> be more or less guessing based on code reading.  I can try next week,
> not able to do this currently.

Thanks.  It's OK to just check the logic by inspection, one of the tests
I end up running is making sure the code size doesn't change so that'll
catch bad migrations.

-- 
Tom


signature.asc
Description: PGP signature


Re: PRAM and reserved memory for Linux

2022-07-13 Thread Tom Rini
On Wed, Jul 13, 2022 at 10:08:38AM +, Joakim Tjernlund wrote:

> I added CONFIG_PRAM 4 and a reserved-memory DTS node for the same space but
> now u-boot complains when booting:
>   ERROR: reserving fdt memory region failed (addr=703ff000 size=1000)
> The error is caused by arch_lmb_reserve() in arm which seem
> to reserve command line and board info ? 
> 
> If I remove the reserved-memory DTS node I don't get a reserved area in Linux,
> don't quite understand how PRAM is supposed to work?

The first likely problem is that CONFIG_PRAM stuff isn't often used
these days so might be glitchy / buggy, as you've found here.  Next, I
bet that area in arch_lmb_reserve() is about ATAGS/related and should be
guarded with CONFIG_SUPPORT_PASSING_ATAGS.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH 0/3] sunxi: FEL boot fixes

2022-07-13 Thread Andre Przywara
While investigating a FEL boot failure on the OrangePi Zero 2 board
(with an H616 SoC), I stared at our FEL code and found some issues,
which this series fixes.

Unfortunately those didn't fix the H616 problem, but they are worth
having anyway.

For the records on the FEL failure: with certain H616 DRAM parameters,
newer GCCs (starting with GCC 11, GCC 10 is fine) generate an SPL binary
that doesn't properly return to the BootROM after the SPL code has
finished. This does not occur on other H616 boards using different DRAM
parameters. Staring at the disassemblies from the different compiler
versions for a while didn't show anything obvious, the best theory so
far is that it's due to a subtle timing issue in the DRAM initialisation
code. Inserting a "udelay(0);" at the beginning of
mctl_phy_read_calibration() seems to avoid the problem, but is obviously
not a proper fix. I will keep looking.

However the issues addressed in this series should be fixed, regardless.

Cheers,
Andre

Andre Przywara (3):
  sunxi: armv8: fel: load only 32-bit values
  sunxi: h616: lower SPL stack address to avoid BROM data
  sunxi: fel: drop redundant "control register" save/restore

 arch/arm/cpu/armv7/sunxi/fel_utils.S | 4 
 arch/arm/cpu/armv8/fel_utils.S   | 8 
 arch/arm/mach-sunxi/board.c  | 1 -
 include/configs/sunxi-common.h   | 2 +-
 4 files changed, 5 insertions(+), 10 deletions(-)

-- 
2.25.1



[PATCH 1/3] sunxi: armv8: fel: load only 32-bit values

2022-07-13 Thread Andre Przywara
Both the values and the MMIO addresses that we need during the 64-bit FEL
restore are smaller than 2^32, so we don't need to do any 64-bit loads.

Change the loads to only load 32 bits worth of data, that saves us some
bytes for storing the values.

Signed-off-by: Andre Przywara 
---
 arch/arm/cpu/armv8/fel_utils.S | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv8/fel_utils.S b/arch/arm/cpu/armv8/fel_utils.S
index 5266515f14..2fe38a1a04 100644
--- a/arch/arm/cpu/armv8/fel_utils.S
+++ b/arch/arm/cpu/armv8/fel_utils.S
@@ -39,15 +39,15 @@ ENTRY(return_to_fel)
adr x1, fel_stash_addr  // to find the fel_stash address in AA32
str w2, [x1]
 
-   ldr x0, =0xfa50392f // CPU hotplug magic
+   ldr w0, =0xfa50392f // CPU hotplug magic
 #ifdef CONFIG_MACH_SUN50I_H616
-   ldr x2, =(SUNXI_R_CPUCFG_BASE + 0x1c0)
+   ldr w2, =(SUNXI_R_CPUCFG_BASE + 0x1c0)
str w0, [x2], #0x4
 #elif CONFIG_MACH_SUN50I_H6
-   ldr x2, =(SUNXI_RTC_BASE + 0x1b8)   // BOOT_CPU_HP_FLAG_REG
+   ldr w2, =(SUNXI_RTC_BASE + 0x1b8)   // BOOT_CPU_HP_FLAG_REG
str w0, [x2], #0x4
 #else
-   ldr x2, =(SUNXI_CPUCFG_BASE + 0x1a4) // offset for CPU hotplug base
+   ldr w2, =(SUNXI_CPUCFG_BASE + 0x1a4) // offset for CPU hotplug base
str w0, [x2, #0x8]
 #endif
adr x0, back_in_32
-- 
2.25.1



[PATCH 3/3] sunxi: fel: drop redundant "control register" save/restore

2022-07-13 Thread Andre Przywara
For some reasons shrouded in mystery, the code saving the FEL state was
saving the SCTLR register twice, with the second copy trying to justify
itself by using its ancient "control register" alias name.

Drop the redundant second copy, both from the fel_stash data structure,
and also the code saving and restoring it.

Signed-off-by: Andre Przywara 
---
 arch/arm/cpu/armv7/sunxi/fel_utils.S | 4 
 arch/arm/mach-sunxi/board.c  | 1 -
 2 files changed, 5 deletions(-)

diff --git a/arch/arm/cpu/armv7/sunxi/fel_utils.S 
b/arch/arm/cpu/armv7/sunxi/fel_utils.S
index b2310751d9..78bb1657fc 100644
--- a/arch/arm/cpu/armv7/sunxi/fel_utils.S
+++ b/arch/arm/cpu/armv7/sunxi/fel_utils.S
@@ -20,8 +20,6 @@ ENTRY(save_boot_params)
str lr, [r0, #12]
mrc p15, 0, lr, c12, c0, 0  @ Read VBAR
str lr, [r0, #16]
-   mrc p15, 0, lr, c1, c0, 0   @ Read CP15 Control Register
-   str lr, [r0, #20]
b   save_boot_params_ret
 ENDPROC(save_boot_params)
 
@@ -29,8 +27,6 @@ ENTRY(return_to_fel)
mov sp, r0
mov lr, r1
ldr r0, =fel_stash
-   ldr r1, [r0, #20]
-   mcr p15, 0, r1, c1, c0, 0   @ Write CP15 Control Register
ldr r1, [r0, #16]
mcr p15, 0, r1, c12, c0, 0  @ Write VBAR
ldr r1, [r0, #12]
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 8f7c894286..385eac7a61 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -35,7 +35,6 @@ struct fel_stash {
uint32_t cpsr;
uint32_t sctlr;
uint32_t vbar;
-   uint32_t cr;
 };
 
 struct fel_stash fel_stash __section(".data");
-- 
2.25.1



[PATCH 2/3] sunxi: h616: lower SPL stack address to avoid BROM data

2022-07-13 Thread Andre Przywara
When using the USB OTG FEL mode on the Allwinner H616, the BootROM
stores some data at the end of SRAM C. This is also the location where
we place the initial SPL stack, so it will overwrite this data.
We still need the BROM code after running the SPL, so should leave that
area alone.
Interestingly this does not seem to have an adverse effect, I guess on
the "way out" (when we return to FEL after the SPL has run), this data
is not needed by the BROM, for just the trailing end of the USB operation.
However this is still wrong, and we should not clobber BROM data.

Lower the SPL stack address to be situated right below the swap buffers
we use in sunxi-fel: that should be out of the way of everyone else.

Signed-off-by: Andre Przywara 
---
 include/configs/sunxi-common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 0f0ef4f64b..d36b59daf7 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -105,7 +105,7 @@
 #endif /* !CONFIG_ARM64 */
 #elif CONFIG_SUNXI_SRAM_ADDRESS == 0x2
 #ifdef CONFIG_MACH_SUN50I_H616
-#define LOW_LEVEL_SRAM_STACK   0x58000
+#define LOW_LEVEL_SRAM_STACK   0x52a00 /* below FEL buffers */
 #else
 /* end of SRAM A2 on H6 for now */
 #define LOW_LEVEL_SRAM_STACK   0x00118000
-- 
2.25.1



Re: [PATCH 1/2] dm: core: Add functions to read 8/16-bit integers

2022-07-13 Thread Simon Glass
Hi Stefan,

On Tue, 12 Jul 2022 at 12:31, Stefan Herbrechtsmeier
 wrote:
>
> Hi Simon,
>
> Am 12.07.2022 um 12:58 schrieb Simon Glass:
> > Hi Stefan,
> >
> > On Tue, 14 Jun 2022 at 07:22, Stefan Herbrechtsmeier
> >  wrote:
> >>
> >> From: Stefan Herbrechtsmeier 
> >>
> >> Add functions to read 8/16-bit integers like the existing functions for
> >> 32/64-bit to simplify read of 8/16-bit integers from device tree
> >> properties.
> >>
> >> Signed-off-by: Stefan Herbrechtsmeier 
> >> 
> >> ---
> >>
> >>   arch/sandbox/dts/test.dts |  2 ++
> >>   drivers/core/of_access.c  | 38 +++
> >>   drivers/core/ofnode.c | 62 +
> >>   drivers/core/read.c   | 21 +
> >>   include/dm/of_access.h| 32 +++
> >>   include/dm/ofnode.h   | 40 
> >>   include/dm/read.h | 65 +++
> >>   test/dm/test-fdt.c| 19 
> >>   8 files changed, 279 insertions(+)
> >
> > This looks good but is very expensive in terms of code size. Can you
> > update your u8 and u16 functions to reuse the existing u32 function
> > and just convert the value?
>
> The u32 function requires a 32 bit value inside the device tree because
> it checks the size and maybe swap the bytes.
>
> The u8 and u16 function requires only a 8 and 16 bit value inside the
> device tree.

Yes that's true. What is the use case for these functions?

Reviewed-by: Simon Glass 

Regards,
Simon


Re: [PATCH 10/19] buildman: Incorporate the genboardscfg.py tool

2022-07-13 Thread Simon Glass
Hi Tom,

On Tue, 12 Jul 2022 at 15:38, Tom Rini  wrote:
>
> On Mon, Jul 11, 2022 at 07:04:04PM -0600, Simon Glass wrote:
> > Bring this tool into buildman, so we don't have to run it separately. The
> > board.cfg file is still produced as part of the build, to save time when
> > doing another build in the same working directory. If it is out of date
> > with respect to the Kconfig, it is updated.
> >
> > Time to regenerate on a recent single-thread machine is 4.6s (1.3s on a
> > 32-thread machine), so we do need some sort of cache if we want buildman
> > to be useful on incremental builds. We could use Python's pickle format
> > but:
> >
> > - it seems useful to allow boards.cfg to be regenerated, at least for a
> >   while, in case other tools use it
> > - it is possible to grep the file easily, e.g. to find boards which use
> >   a particular SoC (similar to 'buildman -nv '
>
> While I don't think other tools still use boards.cfg, this will make it
> easier to find out that I'm wrong.  Perhaps once the CONFIG to Kconfig
> migration is done we can move to just pickle'ing the data or similar
> since I find the main use of what was in boards.cfg can be figured out
> with some other git grep'ing, and in turn that's mainly for me when
> trying to convert stuff.  Thanks for doing this.

Yes. I'm excited to hear that Kconfig migration might be done - any
forecast as to when?

One thing we could to is provide an option for buildman to spit out
the various fields that go into boards.cfg

Regards,
SImon


Re: [PATCH] cmd: fdt: Add support for reading stringlist property values

2022-07-13 Thread Simon Glass
Hi Marek,

On Tue, 12 Jul 2022 at 05:47, Marek Vasut  wrote:
>
> On 7/12/22 12:58, Simon Glass wrote:
> > Hi Marek,
> >
> > On Fri, 8 Jul 2022 at 15:50, Marek Vasut  wrote:
> >>
> >> The fdt command currently handles stringlists as strings in 'fdt get value'
> >> subcommand. Since strings in FDT stringlists are separated by '\0', only
> >> the first value gets inserted into the environment variable passed to the
> >> 'fdt get value' command.
> >>
> >> Example, consider the following DT snippet:
> >>
> >> / { compatible = "foo", "bar" };
> >>
> >> The following command only reports the first string in stringlist:
> >> => fdt get value var / compatible ; print var
> >> foo
> >>
> >> It is not possible to assign list of null-terminated strings into U-Boot
> >> environment variable. Add optional 'index' parameter to the subcommand
> >> 'fdt get value[]' which lets user specify which
> >> string within the stringlist should be assigned into the 'var' variable.
> >> The default value of 'index' is 0 in case it is not present. This way the
> >> 'fdt' command API does not change and existing scripts are not broken.
> >>
> >> The following command now reports the Nth string in stringlist, counting
> >> from zero:
> >> => fdt get value var / compatible 1 ; print var
> >> bar
> >>
> >> Signed-off-by: Marek Vasut 
> >> Cc: Heinrich Schuchardt 
> >> Cc: Simon Glass 
> >> Cc: Tom Rini 
> >> ---
> >>   cmd/fdt.c | 34 --
> >>   1 file changed, 28 insertions(+), 6 deletions(-)
> >
> > Can you please add docs and a test?
>
> I was expecting this kind of question ... there is no test for the FDT
> command.
>
> > I am happy to do a starting point for a test if you like.
>
> You can implement the test for this while at it.

I sent a starting point for you, both docs and test.

Regards,
Simon


Re: [PATCH 1/4] gpio: fix incorrect depends on for SPL_GPIO_HOG

2022-07-13 Thread Simon Glass
On Tue, 12 Jul 2022 at 09:44, Quentin Schulz  wrote:
>
> From: Quentin Schulz 
>
> Since commit 83061dbd1c89 ("Rename GPIO_SUPPORT to GPIO"),
> SPL_GPIO_SUPPORT has been renamed to SPL_GPIO, meaning that SPL_GPIO_HOG
> can never be enabled.
>
> Let's fix this by using the proper name for the Kconfig option.
>
> Fixes: 1d99e673c752 ("gpio: Enable hogging support in SPL")
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
>  drivers/gpio/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 


Re: [gitdm v2] reports.py: Add very basic rST output

2022-07-13 Thread Simon Glass
On Tue, 12 Jul 2022 at 15:14, Tom Rini  wrote:
>
> Add a -R option to gitdm to allow for reStructuredText output and add
> some very simple table generation.  We assume that whatever uses this
> output will be including it in other documents and we only concern
> ourselves with making tables.  Give ourselves 36 characters to fill in
> the nae field, as this tends to be long enough and can be corrected
> manually in the cases where it's slightly too short still.
>
> Cc: Heinrich Schuchardt 
> Signed-off-by: Tom Rini 
> ---
> Changes in v2:
> - Rework how we declare a table, per Heinrich
> ---
>  gitdm  |  5 -
>  reports.py | 22 ++
>  2 files changed, 26 insertions(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH] binman: Increase default fitImage data section resize step from 1k to 64k

2022-07-13 Thread Simon Glass
On Tue, 12 Jul 2022 at 11:41, Marek Vasut  wrote:
>
> Currently the fitImage data area is resized in 1 kiB steps. This works
> when bundling smaller images below some 1 MiB, but when bundling large
> images into the fitImage, this make binman spend extreme amount of time
> and CPU just spinning in pylibfdt FdtSw.check_space() until the size
> grows enough for the large image to fit into the data area. Increase
> the default step to 64 kiB, which is a reasonable compromise -- the
> U-Boot blobs are somewhere in the 64kiB...1MiB range, DT blob are just
> short of 64 kiB, and so are the other blobs. This reduces binman runtime
> with 32 MiB blob from 2.3 minutes to 5 seconds.
>
> The following can be used to trigger the problem if rand.bin is some 32 MiB.
> "
> / {
>   itb {
> fit {
>   images {
> test {
>   compression = "none";
>   description = "none";
>   type = "flat_dt";
>
>   blob {
> filename = "rand.bin";
> type = "blob-ext";
>   };
> };
>   };
> };
>   };
>
>   configurations {
> binman_configuration: config {
>   loadables = "test";
> };
>   };
> };
> "
>
> Signed-off-by: Marek Vasut 
> Cc: Alper Nebi Yasak 
> Cc: Simon Glass 
> ---
>  tools/binman/etype/fit.py | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 

I wonder if pylibfdt should become a bit smarter and increase by the
correct amount?


>
> diff --git a/tools/binman/etype/fit.py b/tools/binman/etype/fit.py
> index 12306623af6..ad43fce18ec 100644
> --- a/tools/binman/etype/fit.py
> +++ b/tools/binman/etype/fit.py
> @@ -658,6 +658,7 @@ class Entry_fit(Entry_section):
>  # Build a new tree with all nodes and properties starting from the
>  # entry node
>  fsw = libfdt.FdtSw()
> +fsw.INC_SIZE = 65536
>  fsw.finish_reservemap()
>  to_remove = []
>  loadables = []
> --
> 2.35.1
>


Re: [PATCH 4/4] vpl: fix reference in comment to non-existing SPL_SERIAL_SUPPORT

2022-07-13 Thread Simon Glass
On Tue, 12 Jul 2022 at 09:45, Quentin Schulz  wrote:
>
> From: Quentin Schulz 
>
> Since commit 2a7360666871 ("serial: Rename SERIAL_SUPPORT to SERIAL")
> SPL_SERIAL_SUPPORT is named SPL_SERIAL. So let's update the comment to
> point to the correct Kconfig option in the comment of VPL_SERIAL.
>
> Fixes: 747093dd408 ("vpl: Add Kconfig options for VPL")
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
>  common/spl/Kconfig | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH] console: Add option to keep it silent until env is loaded

2022-07-13 Thread Simon Glass
Hi Harald,

On Tue, 12 Jul 2022 at 05:58, Harald Seiler  wrote:
>
> Hi Simon,
>
> On Tue, 2022-07-12 at 04:58 -0600, Simon Glass wrote:
> > Hi Harald,
> >
> > On Wed, 6 Jul 2022 at 05:19, Harald Seiler  wrote:
> > >
> > > Add a config-option which forces the console to stay silent until the
> > > proper environment is loaded from flash.
> > >
> > > This is important when the default environment does not silence the
> > > console but no output must be printed when 'silent' is set in the flash
> > > environment.
> > >
> > > After the environment from flash is loaded, the console will be
> > > silenced/unsilenced depending on it.  If PRE_CONSOLE_BUFFER is also
> > > used, the buffer will now be flushed if the console should not be
> > > silenced.
> > >
> > > Signed-off-by: Harald Seiler 
> > > ---
> > >  common/Kconfig   | 10 ++
> > >  common/console.c |  5 +
> > >  2 files changed, 15 insertions(+)
> >
> > This seems OK to me. You might want to implement the silent-console
> > device tree property in console_update_silent() too, which was dropped
> > in the conversion to driver model.
>
> This looks interesting, I'll have to look into it.
>
> Do you know if there's any effort towards supporting such a flag in the
> kernel as well?  I had to remove the serial console property from my DT
> and instead pass console info via cmdline to make the silent console
> work.  A "pure DT" solution of any sort would have been nicer of
> course...

The console's 'silent' flag is propagated to Linux by dropping the
'console=' text from the bootargs. See fixup_silent_linux().

Regards,
Simon


>
> --
> Harald


Re: [PATCH v6 3/7] tpm: Add the RNG child device

2022-07-13 Thread Simon Glass
Hi Rob,

On Tue, 12 Jul 2022 at 08:11, Rob Herring  wrote:
>
> On Tue, Jul 12, 2022 at 5:04 AM Simon Glass  wrote:
> >
> > Hi Ilias,
> >
> > On Fri, 8 Jul 2022 at 02:24, Ilias Apalodimas
> >  wrote:
> > >
> > > Hi Simon,
> > >
> > > [...]
> > >
> > > > > +
> > > > >  UCLASS_DRIVER(tpm) = {
> > > > > -   .id = UCLASS_TPM,
> > > > > -   .name   = "tpm",
> > > > > -   .flags  = DM_UC_FLAG_SEQ_ALIAS,
> > > > > +   .id = UCLASS_TPM,
> > > > > +   .name   = "tpm",
> > > > > +   .flags  = DM_UC_FLAG_SEQ_ALIAS,
> > > > >  #if CONFIG_IS_ENABLED(OF_REAL)
> > > > > -   .post_bind  = dm_scan_fdt_dev,
> > > > > +   .post_bind  = dm_scan_fdt_dev,
> > > > >  #endif
> > > > > +   .post_probe = tpm_uclass_post_probe,
> > > > > .per_device_auto= sizeof(struct tpm_chip_priv),
> > > > >  };
> > > > > --
> > > > > 2.25.1
> > > > >
> > > >
> > > > The driver needs a compatible string so it can be in the device tree.
> > >
> > > Why?  I've tried to hint this on the previous iteration of the patch.
> > > The RNG here is not a *device*.  The TPM is the device and you are
> > > guaranteed to have an RNG.  The way to get a random number is send a
> > > special command to the TPM. So all that we should do here is leverage
> > > the fact that the TPM is already in the device tree.
> > >
> > > And fwiw we should stick to try to stick to what the DT spec defines
> > > as much as possible.  I personally don't see this as a special usecase
> > > were deviating from the spec is justified.
> >
> > This is not a deviation from a spec. What spec? Also, I don't want to
> > get into another discussion about what a device is. We can disagree on
> > that if you like.
> >
> > One reason is that U-Boot generally requires compatible strings, e.g.
> > with of-platdata. But also we can refer to the rand device from
> > elsewhere in the tree. I know that Linux does lots of ad-hoc device
> > creation and doesn't really have the concept of a uclass consistently
> > applied, but this is U-Boot.
>
> You are letting client/OS details define your binding. Doing so
> doesn't result in OS agnostic bindings. Sure, it would be nice if DT
> nodes and drivers were always a nice clean 1:1 ratio, but h/w is messy
> sometimes and DT is not an abstraction layer. The general guidance on
> whether there are child nodes for sub-blocks is do they have their own
> resources in DT or are the sub-blocks reusable on multiple devices.
> Neither of those are the case here.
>
> Besides, we already have TPM device bindings defined. Requiring
> binding changes when adding a new client/OS feature is not good
> practice either.

I'm not sure what to do with this, but in general the practice of
implied subnodes is not friendly to U-Boot. Yet it seems like a common
feature of the bindings at present, for example GPIOs.

The device tree is how U-Boot determines which random-number generator
to use for a particular function. For example, for VBE, if we need to
generate some random numbers we'd like to specify which device creates
them. It can't just be 'use the TPM if you find one'. I'm not sure how
that works in Linux?

Regards,
SImon


Re: [PATCH] cmd: fdt: Add support for reading stringlist property values

2022-07-13 Thread Marek Vasut

On 7/13/22 17:28, Simon Glass wrote:

Hi Marek,

On Tue, 12 Jul 2022 at 05:47, Marek Vasut  wrote:


On 7/12/22 12:58, Simon Glass wrote:

Hi Marek,

On Fri, 8 Jul 2022 at 15:50, Marek Vasut  wrote:


The fdt command currently handles stringlists as strings in 'fdt get value'
subcommand. Since strings in FDT stringlists are separated by '\0', only
the first value gets inserted into the environment variable passed to the
'fdt get value' command.

Example, consider the following DT snippet:

/ { compatible = "foo", "bar" };

The following command only reports the first string in stringlist:
=> fdt get value var / compatible ; print var
foo

It is not possible to assign list of null-terminated strings into U-Boot
environment variable. Add optional 'index' parameter to the subcommand
'fdt get value[]' which lets user specify which
string within the stringlist should be assigned into the 'var' variable.
The default value of 'index' is 0 in case it is not present. This way the
'fdt' command API does not change and existing scripts are not broken.

The following command now reports the Nth string in stringlist, counting
from zero:
=> fdt get value var / compatible 1 ; print var
bar

Signed-off-by: Marek Vasut 
Cc: Heinrich Schuchardt 
Cc: Simon Glass 
Cc: Tom Rini 
---
   cmd/fdt.c | 34 --
   1 file changed, 28 insertions(+), 6 deletions(-)


Can you please add docs and a test?


I was expecting this kind of question ... there is no test for the FDT
command.


I am happy to do a starting point for a test if you like.


You can implement the test for this while at it.


I sent a starting point for you, both docs and test.


Thank you.

Do I understand your remark correctly that you're blocking this 
particular patch from going in until there is a test ?


Re: [PATCH] cmd: fdt: Add support for reading stringlist property values

2022-07-13 Thread Simon Glass
Hi Marek,

On Wed, 13 Jul 2022 at 09:30, Marek Vasut  wrote:
>
> On 7/13/22 17:28, Simon Glass wrote:
> > Hi Marek,
> >
> > On Tue, 12 Jul 2022 at 05:47, Marek Vasut  wrote:
> >>
> >> On 7/12/22 12:58, Simon Glass wrote:
> >>> Hi Marek,
> >>>
> >>> On Fri, 8 Jul 2022 at 15:50, Marek Vasut  wrote:
> 
>  The fdt command currently handles stringlists as strings in 'fdt get 
>  value'
>  subcommand. Since strings in FDT stringlists are separated by '\0', only
>  the first value gets inserted into the environment variable passed to the
>  'fdt get value' command.
> 
>  Example, consider the following DT snippet:
> 
>  / { compatible = "foo", "bar" };
> 
>  The following command only reports the first string in stringlist:
>  => fdt get value var / compatible ; print var
>  foo
> 
>  It is not possible to assign list of null-terminated strings into U-Boot
>  environment variable. Add optional 'index' parameter to the subcommand
>  'fdt get value[]' which lets user specify 
>  which
>  string within the stringlist should be assigned into the 'var' variable.
>  The default value of 'index' is 0 in case it is not present. This way the
>  'fdt' command API does not change and existing scripts are not broken.
> 
>  The following command now reports the Nth string in stringlist, counting
>  from zero:
>  => fdt get value var / compatible 1 ; print var
>  bar
> 
>  Signed-off-by: Marek Vasut 
>  Cc: Heinrich Schuchardt 
>  Cc: Simon Glass 
>  Cc: Tom Rini 
>  ---
> cmd/fdt.c | 34 --
> 1 file changed, 28 insertions(+), 6 deletions(-)
> >>>
> >>> Can you please add docs and a test?
> >>
> >> I was expecting this kind of question ... there is no test for the FDT
> >> command.
> >>
> >>> I am happy to do a starting point for a test if you like.
> >>
> >> You can implement the test for this while at it.
> >
> > I sent a starting point for you, both docs and test.
>
> Thank you.
>
> Do I understand your remark correctly that you're blocking this
> particular patch from going in until there is a test ?

I'm not blocking anything, but turning it around the other way, how
about having a crack at a test? You can try out 'ut fdt' to see the
current tests (using the patches I sent).

Regards,
Simon


Re: [PATCH 3/3] fdt: introduce apply_all command

2022-07-13 Thread Simon Glass
Hi Andre,

On Wed, 13 Jul 2022 at 07:18, Andre Przywara  wrote:
>
> On Tue, 12 Jul 2022 04:58:35 -0600
> Simon Glass  wrote:
>
> Hi Simon,
>
> many thanks for having a look!
>
> > On Tue, 5 Jul 2022 at 11:14, Andre Przywara  wrote:
> > >
> > > Explicitly specifying the exact filenames of devicetree overlays files
> > > on a U-Boot command line can be quite tedious for users, especially
> > > when it should be made persistent for every boot.
> > >
> > > To simplify the task of applying (custom) DT overlays, introduce a
> > > "fdt apply-all" subcommand, that iterates a given directory in any
> > > supported filesystem, and tries to apply every .dtbo file found it
> > > there.
> > >
> > > This allows users to simply drop a DT overlay file into a magic
> > > directory, and it will be applied on the next boot automatically,
> > > by the virtue of just a generic U-Boot command call.
> > >
> > > Signed-off-by: Andre Przywara 
> > > ---
> > >  cmd/fdt.c | 89 ++-
> > >  1 file changed, 88 insertions(+), 1 deletion(-)
> >
> > This looks OK, but can you please add a test (see test/dm/acpi.c for
> > example) and doc/usage/cmd file?
>
> Is that supposed to run inside the sandbox? I briefly tested this there,
> only to realise that the sandbox' hostfs does not support the directory
> operations (fs_opendir_unsupported). I haven't thought about it too much,
> nor do I have much experience with U-Boot's test framework, but this sounds
> like a problem?

Yes that is a problem, although it would not be too hard to implement, I think.

Also I sent a little series to add a test for 'fdt addr' which might
make it easier for you.

>
> > Also, apply_all is a bit annoying as we try to allow command
> > completion and abbreviations to work. Given that the args are
> > different I don't think a -d (for dir) flag makes sense.
> >
> > Perhaps 'fdt fsapply' ?
>
> Yeah, I wasn't happy with that name either, but couldn't come up with a
> better name. "fsapply" seems to be a nice alternative, I will go with that!

OK good.

Regards,
Simon


[PATCH] sunxi: configs: streamline include/configs/sun*.h wrappers

2022-07-13 Thread Andre Przywara
For mostly historic reasons we had configuration headers for each
Allwinner CPU "family". These days they are mostly just including one
common header, with the rest being somewhat empty.
There were attempts to remove them, and to just use the one common header
to begin with, but this has implications to the build system, which me
might not be ready for, yet.

To document this behaviour, and to avoid something sneaking in over
time, make those files all the same (minus the CPU family name and
the copyrights), and add a comment explaining that.
This makes it easier to just remove those files later on, when needed
and possible.

Signed-off-by: Andre Przywara 
---
Hi Tom,

this is mostly to just confirm and document what we already established
earlier: that those files are redundant, and are just needed to match
CONFIG_SYS_CONFIG_NAME. In case we don't need or want that anymore, we
can just remove them, without needing to think too hard about it.

Cheers,
Andre

 include/configs/sun4i.h  | 10 ++
 include/configs/sun50i.h | 19 ++-
 include/configs/sun5i.h  | 10 ++
 include/configs/sun6i.h  |  7 ++-
 include/configs/sun7i.h  |  6 ++
 include/configs/sun8i.h  | 13 ++---
 include/configs/sun9i.h  | 11 ++-
 include/configs/suniv.h  |  7 ++-
 8 files changed, 16 insertions(+), 67 deletions(-)

diff --git a/include/configs/sun4i.h b/include/configs/sun4i.h
index 0e1baa91bb..70d451f224 100644
--- a/include/configs/sun4i.h
+++ b/include/configs/sun4i.h
@@ -2,18 +2,12 @@
 /*
  * (C) Copyright 2012-2013 Henrik Nordstrom 
  *
- * Configuration settings for the Allwinner A10 (sun4i) CPU
+ * Placeholder wrapper to allow addressing Allwinner A10 (sun4i) CPU
+ * based devices separately. Please do not add anything in here.
  */
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-/*
- * A10 specific configuration
- */
-
-/*
- * Include common sunxi configuration where most the settings are
- */
 #include 
 
 #endif /* __CONFIG_H */
diff --git a/include/configs/sun50i.h b/include/configs/sun50i.h
index bc2e3a3d00..dfcb321d42 100644
--- a/include/configs/sun50i.h
+++ b/include/configs/sun50i.h
@@ -1,26 +1,11 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
- * Configuration settings for the Allwinner A64 (sun50i) CPU
+ * Placeholder wrapper to allow addressing Allwinner A64 (and later) sun50i
+ * CPU based devices separately. Please do not add anything in here.
  */
-
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-/*
- * A64 specific configuration
- */
-
-#ifndef CONFIG_SUN50I_GEN_H6
-#define GICD_BASE  0x1c81000
-#define GICC_BASE  0x1c82000
-#else
-#define GICD_BASE  0x3021000
-#define GICC_BASE  0x3022000
-#endif
-
-/*
- * Include common sunxi configuration where most the settings are
- */
 #include 
 
 #endif /* __CONFIG_H */
diff --git a/include/configs/sun5i.h b/include/configs/sun5i.h
index ada18de753..3017307854 100644
--- a/include/configs/sun5i.h
+++ b/include/configs/sun5i.h
@@ -2,18 +2,12 @@
 /*
  * (C) Copyright 2012-2013 Henrik Nordstrom 
  *
- * Configuration settings for the Allwinner A13 (sun5i) CPU
+ * Placeholder wrapper to allow addressing Allwinner A13 (sun5i) CPU
+ * based devices separately. Please do not add anything in here.
  */
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-/*
- * High Level Configuration Options
- */
-
-/*
- * Include common sunxi configuration where most the settings are
- */
 #include 
 
 #endif /* __CONFIG_H */
diff --git a/include/configs/sun6i.h b/include/configs/sun6i.h
index 0b1fedda10..cbe04ac3c2 100644
--- a/include/configs/sun6i.h
+++ b/include/configs/sun6i.h
@@ -4,15 +4,12 @@
  * (C) Copyright 2013 Luke Kenneth Casson Leighton 
  * (C) Copyright 2013 Maxime Ripard 
  *
- * Configuration settings for the Allwinner A31 (sun6i) CPU
+ * Placeholder wrapper to allow addressing Allwinner A31 (sun6i) CPU
+ * based devices separately. Please do not add anything in here.
  */
-
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-/*
- * Include common sunxi configuration where most the settings are
- */
 #include 
 
 #endif /* __CONFIG_H */
diff --git a/include/configs/sun7i.h b/include/configs/sun7i.h
index bc2779fa26..ad24ab98b5 100644
--- a/include/configs/sun7i.h
+++ b/include/configs/sun7i.h
@@ -3,14 +3,12 @@
  * (C) Copyright 2012-2013 Henrik Nordstrom 
  * (C) Copyright 2013 Luke Kenneth Casson Leighton 
  *
- * Configuration settings for the Allwinner A20 (sun7i) CPU
+ * Placeholder wrapper to allow addressing Allwinner A20 (sun7i) CPU
+ * based devices separately. Please do not add anything in here.
  */
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-/*
- * Include common sunxi configuration where most the settings are
- */
 #include 
 
 #endif /* __CONFIG_H */
diff --git a/include/configs/sun8i.h b/include/configs/sun8i.h
index 106139d090..b6cd8d39a8 100644
--- a/include/configs/sun8i.h
+++ b/include/configs/sun8i.h
@@ -2,21 +2,12 @@
 /*
  * (C) Copyright 2014 Chen-Yu Tsai 
  *
- * Configuration s

Re: [PATCH 1/2] dm: core: Add functions to read 8/16-bit integers

2022-07-13 Thread Stefan Herbrechtsmeier

Hi Simon,

Am 13.07.2022 um 17:28 schrieb Simon Glass:

Hi Stefan,

On Tue, 12 Jul 2022 at 12:31, Stefan Herbrechtsmeier
 wrote:


Hi Simon,

Am 12.07.2022 um 12:58 schrieb Simon Glass:

Hi Stefan,

On Tue, 14 Jun 2022 at 07:22, Stefan Herbrechtsmeier
 wrote:


From: Stefan Herbrechtsmeier 

Add functions to read 8/16-bit integers like the existing functions for
32/64-bit to simplify read of 8/16-bit integers from device tree
properties.

Signed-off-by: Stefan Herbrechtsmeier 
---

   arch/sandbox/dts/test.dts |  2 ++
   drivers/core/of_access.c  | 38 +++
   drivers/core/ofnode.c | 62 +
   drivers/core/read.c   | 21 +
   include/dm/of_access.h| 32 +++
   include/dm/ofnode.h   | 40 
   include/dm/read.h | 65 +++
   test/dm/test-fdt.c| 19 
   8 files changed, 279 insertions(+)


This looks good but is very expensive in terms of code size. Can you
update your u8 and u16 functions to reuse the existing u32 function
and just convert the value?


The u32 function requires a 32 bit value inside the device tree because
it checks the size and maybe swap the bytes.

The u8 and u16 function requires only a 8 and 16 bit value inside the
device tree.


Yes that's true. What is the use case for these functions?


The usb251xb driver requires this functions [1]. The usb251xb device 
tree binding [2] defines the ids as 16 bit values and the Linux driver 
use 8 bit for an unspecified property. Without this changes the driver 
doesn't satisfy the specification and is incompatible to the Linux driver.


[1] https://lists.denx.de/pipermail/u-boot/2022-June/486424.html
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/usb/usb251xb.txt


Regards
  Stefan


[PATCH] board: ti: am65x: Do not disable SA2UL in DT

2022-07-13 Thread Andrew Davis
This is no longer needed as the SA2UL can now be shared with Linux.
Leave the SA2UL DT node enabled.

Signed-off-by: Andrew Davis 
---
 board/ti/am65x/evm.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/board/ti/am65x/evm.c b/board/ti/am65x/evm.c
index 7182a8cad1..8a0a506a3e 100644
--- a/board/ti/am65x/evm.c
+++ b/board/ti/am65x/evm.c
@@ -115,16 +115,6 @@ int ft_board_setup(void *blob, struct bd_info *bd)
return ret;
}
 
-#if defined(CONFIG_TI_SECURE_DEVICE)
-   /* Make Crypto HW reserved for secure world use */
-   ret = fdt_disable_node(blob, "/bus@10/crypto@4e0");
-   if (ret < 0)
-   ret = fdt_disable_node(blob,
-  "/interconnect@10/crypto@4E0");
-   if (ret)
-   printf("%s: disabling SA2UL failed %d\n", __func__, ret);
-#endif
-
return 0;
 }
 #endif
-- 
2.36.1



Re: PRAM and reserved memory for Linux

2022-07-13 Thread Joakim Tjernlund
On Wed, 2022-07-13 at 10:21 -0400, Tom Rini wrote:
> On Wed, Jul 13, 2022 at 10:08:38AM +, Joakim Tjernlund wrote:
> 
> > I added CONFIG_PRAM 4 and a reserved-memory DTS node for the same space but
> > now u-boot complains when booting:
> >   ERROR: reserving fdt memory region failed (addr=703ff000 size=1000)
> > The error is caused by arch_lmb_reserve() in arm which seem
> > to reserve command line and board info ? 
> > 
> > If I remove the reserved-memory DTS node I don't get a reserved area in 
> > Linux,
> > don't quite understand how PRAM is supposed to work?
> 
> The first likely problem is that CONFIG_PRAM stuff isn't often used
> these days so might be glitchy / buggy, as you've found here.  Next, I
> bet that area in arch_lmb_reserve() is about ATAGS/related and should be
> guarded with CONFIG_SUPPORT_PASSING_ATAGS.
> 

The  arch_lmb_reserve() comment reads(lots of archs has similar code):
/*
 * Booting a (Linux) kernel image
 *
 * Allocate space for command line and board info - the
 * address should be as high as possible within the reach of
 * the kernel (see CONFIG_SYS_BOOTMAPSZ settings), but in unused
 * memory, which means far enough below the current stack
 * pointer.

You still think this cmdline/board info is just for the old ATAGS ?
I have an older boot and it des not have CONFIG_SUPPORT_PASSING_ATAGS but
CMDLINE_TAG etc. is here though.

 Jocke


[PATCH 0/3] sunxi: remove CONFIG_MMC?_CD_PIN

2022-07-13 Thread Andre Przywara
Since the dawn of time we had CONFIG_MMC?_CD_PIN defines for each
Allwinner board, which held the name for the respective MMC card
detect GPIO. These days we don't use that in U-Boot proper anymore
(and rely on DT for that, instead), so it's just for the SPL loading.
However the card detect is actually not needed there:
- We continue loading from the same boot media that the BootROM booted
  us from, so when we get to load from MMC, there is surely a card in
  the slot.
- The BROM already spoiled all efforts by unconditionally accessing the
  MMC bus, regardless of any card presence or not. We can't do more harm
  by doing the same.

This series removes the code checking the CD pin, and also the definition
from Kconfig and all defconfigs. On top there is a cleanup for the MMC
driver, which explains the reason for still also implementing the legacy
MMC interface.

Please have a look and test!

Thanks,
Andre

Andre Przywara (3):
  sunxi: mmc: ignore card detect in SPL
  sunxi: mmc: group non-DM specific functions
  sunxi: remove CONFIG_MMC?_CD_PIN

 arch/arm/mach-sunxi/Kconfig  |  27 
 configs/A10-OLinuXino-Lime_defconfig |   1 -
 configs/A10s-OLinuXino-M_defconfig   |   2 -
 configs/A13-OLinuXinoM_defconfig |   1 -
 configs/A13-OLinuXino_defconfig  |   1 -
 configs/A20-OLinuXino-Lime2-eMMC_defconfig   |   1 -
 configs/A20-OLinuXino-Lime2_defconfig|   1 -
 configs/A20-OLinuXino-Lime_defconfig |   1 -
 configs/A20-OLinuXino_MICRO-eMMC_defconfig   |   1 -
 configs/A20-OLinuXino_MICRO_defconfig|   2 -
 configs/A20-Olimex-SOM-EVB_defconfig |   2 -
 configs/A20-Olimex-SOM204-EVB-eMMC_defconfig |   1 -
 configs/A20-Olimex-SOM204-EVB_defconfig  |   1 -
 configs/A33-OLinuXino_defconfig  |   1 -
 configs/Ainol_AW1_defconfig  |   1 -
 configs/Ampe_A76_defconfig   |   1 -
 configs/Bananapi_M2_Ultra_defconfig  |   1 -
 configs/Bananapi_m2m_defconfig   |   1 -
 configs/Cubieboard2_defconfig|   1 -
 configs/Cubieboard4_defconfig|   1 -
 configs/Cubieboard_defconfig |   1 -
 configs/Cubietruck_defconfig |   1 -
 configs/Empire_electronix_d709_defconfig |   1 -
 configs/Empire_electronix_m712_defconfig |   1 -
 configs/Itead_Ibox_A20_defconfig |   1 -
 configs/Lamobo_R1_defconfig  |   1 -
 configs/Mele_M3_defconfig|   1 -
 configs/Mele_M5_defconfig|   1 -
 configs/Merrii_A80_Optimus_defconfig |   1 -
 configs/Orangepi_mini_defconfig  |   2 -
 configs/Sinlinx_SinA31s_defconfig|   1 -
 configs/Sinlinx_SinA33_defconfig |   1 -
 configs/Sunchip_CX-A99_defconfig |   1 -
 configs/UTOO_P66_defconfig   |   1 -
 configs/Wobo_i5_defconfig|   1 -
 configs/Yones_Toptech_BD1078_defconfig   |   2 -
 configs/Yones_Toptech_BS1078_V2_defconfig|   1 -
 configs/bananapi_m2_berry_defconfig  |   1 -
 configs/bananapi_m2_zero_defconfig   |   1 -
 configs/bananapi_m64_defconfig   |   1 -
 configs/beelink_gs1_defconfig|   1 -
 configs/colorfly_e708_q1_defconfig   |   1 -
 configs/difrnce_dit4350_defconfig|   1 -
 configs/dserve_dsrv9703c_defconfig   |   1 -
 configs/gt90h_v4_defconfig   |   1 -
 configs/iNet_3F_defconfig|   1 -
 configs/iNet_3W_defconfig|   1 -
 configs/iNet_D978_rev2_defconfig |   1 -
 configs/icnova-a20-swac_defconfig|   1 -
 configs/inet86dz_defconfig   |   1 -
 configs/inet98v_rev2_defconfig   |   1 -
 configs/inet_q972_defconfig  |   1 -
 configs/nanopi_m1_plus_defconfig |   1 -
 configs/oceanic_5205_5inmfd_defconfig|   1 -
 configs/orangepi_3_defconfig |   1 -
 configs/orangepi_lite2_defconfig |   1 -
 configs/orangepi_one_plus_defconfig  |   1 -
 configs/orangepi_zero2_defconfig |   1 -
 configs/orangepi_zero_plus2_defconfig|   1 -
 configs/orangepi_zero_plus2_h3_defconfig |   1 -
 configs/parrot_r16_defconfig |   1 -
 configs/pine64-lts_defconfig |   1 -
 configs/pine_h64_defconfig   |   1 -
 configs/polaroid_mid2407pxe03_defconfig  |   1 -
 configs/polaroid_mid2809pxe04_defconfig  |   1 -
 configs/q8_a13_tablet_defconfig  |   1 -
 configs/q8_a23_tablet_800x480_defconfig  |   1 -
 configs/q8_a33_tablet_1024x600_defconfig |   1 -
 configs/q8_a33_tablet_800x480_defconfig  |   1 -
 configs/sopine_baseboard_defconfig   |   1 -
 configs/tanix_tx6_defconfig  |   1 -
 drivers/mmc/sunxi_mmc.c  | 152 ---
 72 files changed, 62 inser

[PATCH 1/3] sunxi: mmc: ignore card detect in SPL

2022-07-13 Thread Andre Przywara
The sunxi MMC code does not use the DM in the SPL, as we don't have a
device tree available that early, also no space for it.
This also means we cannot access the card-detect GPIO information from
there, so we have Kconfig symbols called CONFIG_MMCx_CD_PIN, which each
board has to define. This is a burden, also requires extra GPIO code in
the SPL.
As the SPL is the natural successor of the BootROM (from which we are
loaded), we can actually ignore the CD pin completely, as this is what
the BootROM does as well: CD GPIOs are board specific, but the BootROM
is not, so accesses the MMC devices anyway.

Remove the card detect code from the non-DM implementation of the sunxi
MMC driver, to get rid of this unneeded code.

Signed-off-by: Andre Przywara 
---
 drivers/mmc/sunxi_mmc.c | 37 ++---
 1 file changed, 2 insertions(+), 35 deletions(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 1bb7b6d0e9..b2f7e2d142 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -44,22 +44,10 @@ struct sunxi_mmc_priv {
 /* support 4 mmc hosts */
 struct sunxi_mmc_priv mmc_host[4];
 
-static int sunxi_mmc_getcd_gpio(int sdc_no)
-{
-   switch (sdc_no) {
-   case 0: return sunxi_name_to_gpio(CONFIG_MMC0_CD_PIN);
-   case 1: return sunxi_name_to_gpio(CONFIG_MMC1_CD_PIN);
-   case 2: return sunxi_name_to_gpio(CONFIG_MMC2_CD_PIN);
-   case 3: return sunxi_name_to_gpio(CONFIG_MMC3_CD_PIN);
-   }
-   return -EINVAL;
-}
-
 static int mmc_resource_init(int sdc_no)
 {
struct sunxi_mmc_priv *priv = &mmc_host[sdc_no];
struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
-   int cd_pin, ret = 0;
 
debug("init mmc %d resource\n", sdc_no);
 
@@ -90,16 +78,7 @@ static int mmc_resource_init(int sdc_no)
}
priv->mmc_no = sdc_no;
 
-   cd_pin = sunxi_mmc_getcd_gpio(sdc_no);
-   if (cd_pin >= 0) {
-   ret = gpio_request(cd_pin, "mmc_cd");
-   if (!ret) {
-   sunxi_gpio_set_pull(cd_pin, SUNXI_GPIO_PULL_UP);
-   ret = gpio_direction_input(cd_pin);
-   }
-   }
-
-   return ret;
+   return 0;
 }
 #endif
 
@@ -523,23 +502,11 @@ static int sunxi_mmc_send_cmd_legacy(struct mmc *mmc, 
struct mmc_cmd *cmd,
return sunxi_mmc_send_cmd_common(priv, mmc, cmd, data);
 }
 
-static int sunxi_mmc_getcd_legacy(struct mmc *mmc)
-{
-   struct sunxi_mmc_priv *priv = mmc->priv;
-   int cd_pin;
-
-   cd_pin = sunxi_mmc_getcd_gpio(priv->mmc_no);
-   if (cd_pin < 0)
-   return 1;
-
-   return !gpio_get_value(cd_pin);
-}
-
+/* .get_cd is not needed by the SPL */
 static const struct mmc_ops sunxi_mmc_ops = {
.send_cmd   = sunxi_mmc_send_cmd_legacy,
.set_ios= sunxi_mmc_set_ios_legacy,
.init   = sunxi_mmc_core_init,
-   .getcd  = sunxi_mmc_getcd_legacy,
 };
 
 struct mmc *sunxi_mmc_init(int sdc_no)
-- 
2.25.1



[PATCH 2/3] sunxi: mmc: group non-DM specific functions

2022-07-13 Thread Andre Przywara
As the SPL code for sunxi boards does not use the driver model, we have
two mmc_ops structures, one for DM, one for non-DM. The actual hardware
access code is shared, with the respective callback functions using that
common code.

To make this more obvious and easier to read, reorder the functions to
group them: we first have the common code, then the non-DM bits, and
the proper DM implementation at the end.
Also document this structure in the comment at the beginning of the file.

No functional change intended.

Signed-off-by: Andre Przywara 
---
 drivers/mmc/sunxi_mmc.c | 117 +---
 1 file changed, 61 insertions(+), 56 deletions(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index b2f7e2d142..ad0fb4ad08 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -5,6 +5,12 @@
  * Aaron 
  *
  * MMC driver for allwinner sunxi platform.
+ *
+ * This driver is used by the (ARM) SPL with the legacy MMC interface, and
+ * by U-Boot proper using the full DM interface. The actual hardware access
+ * code is common, and comes first in this file.
+ * The legacy MMC interface implementation comes next, followed by the
+ * proper DM_MMC implementation at the end.
  */
 
 #include 
@@ -40,48 +46,6 @@ struct sunxi_mmc_priv {
struct mmc_config cfg;
 };
 
-#if !CONFIG_IS_ENABLED(DM_MMC)
-/* support 4 mmc hosts */
-struct sunxi_mmc_priv mmc_host[4];
-
-static int mmc_resource_init(int sdc_no)
-{
-   struct sunxi_mmc_priv *priv = &mmc_host[sdc_no];
-   struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
-
-   debug("init mmc %d resource\n", sdc_no);
-
-   switch (sdc_no) {
-   case 0:
-   priv->reg = (struct sunxi_mmc *)SUNXI_MMC0_BASE;
-   priv->mclkreg = &ccm->sd0_clk_cfg;
-   break;
-   case 1:
-   priv->reg = (struct sunxi_mmc *)SUNXI_MMC1_BASE;
-   priv->mclkreg = &ccm->sd1_clk_cfg;
-   break;
-#ifdef SUNXI_MMC2_BASE
-   case 2:
-   priv->reg = (struct sunxi_mmc *)SUNXI_MMC2_BASE;
-   priv->mclkreg = &ccm->sd2_clk_cfg;
-   break;
-#endif
-#ifdef SUNXI_MMC3_BASE
-   case 3:
-   priv->reg = (struct sunxi_mmc *)SUNXI_MMC3_BASE;
-   priv->mclkreg = &ccm->sd3_clk_cfg;
-   break;
-#endif
-   default:
-   printf("Wrong mmc number %d\n", sdc_no);
-   return -1;
-   }
-   priv->mmc_no = sdc_no;
-
-   return 0;
-}
-#endif
-
 /*
  * All A64 and later MMC controllers feature auto-calibration. This would
  * normally be detected via the compatible string, but we need something
@@ -269,19 +233,6 @@ static int sunxi_mmc_set_ios_common(struct sunxi_mmc_priv 
*priv,
return 0;
 }
 
-#if !CONFIG_IS_ENABLED(DM_MMC)
-static int sunxi_mmc_core_init(struct mmc *mmc)
-{
-   struct sunxi_mmc_priv *priv = mmc->priv;
-
-   /* Reset controller */
-   writel(SUNXI_MMC_GCTRL_RESET, &priv->reg->gctrl);
-   udelay(1000);
-
-   return 0;
-}
-#endif
-
 static int mmc_trans_data_by_cpu(struct sunxi_mmc_priv *priv, struct mmc *mmc,
 struct mmc_data *data)
 {
@@ -486,7 +437,60 @@ out:
return error;
 }
 
+/* non-DM code here is used by the (ARM) SPL only */
+
 #if !CONFIG_IS_ENABLED(DM_MMC)
+/* support 4 mmc hosts */
+struct sunxi_mmc_priv mmc_host[4];
+
+static int mmc_resource_init(int sdc_no)
+{
+   struct sunxi_mmc_priv *priv = &mmc_host[sdc_no];
+   struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+
+   debug("init mmc %d resource\n", sdc_no);
+
+   switch (sdc_no) {
+   case 0:
+   priv->reg = (struct sunxi_mmc *)SUNXI_MMC0_BASE;
+   priv->mclkreg = &ccm->sd0_clk_cfg;
+   break;
+   case 1:
+   priv->reg = (struct sunxi_mmc *)SUNXI_MMC1_BASE;
+   priv->mclkreg = &ccm->sd1_clk_cfg;
+   break;
+#ifdef SUNXI_MMC2_BASE
+   case 2:
+   priv->reg = (struct sunxi_mmc *)SUNXI_MMC2_BASE;
+   priv->mclkreg = &ccm->sd2_clk_cfg;
+   break;
+#endif
+#ifdef SUNXI_MMC3_BASE
+   case 3:
+   priv->reg = (struct sunxi_mmc *)SUNXI_MMC3_BASE;
+   priv->mclkreg = &ccm->sd3_clk_cfg;
+   break;
+#endif
+   default:
+   printf("Wrong mmc number %d\n", sdc_no);
+   return -1;
+   }
+   priv->mmc_no = sdc_no;
+
+   return 0;
+}
+
+static int sunxi_mmc_core_init(struct mmc *mmc)
+{
+   struct sunxi_mmc_priv *priv = mmc->priv;
+
+   /* Reset controller */
+   writel(SUNXI_MMC_GCTRL_RESET, &priv->reg->gctrl);
+   udelay(1000);
+
+   return 0;
+}
+
 static int sunxi_mmc_set_ios_legacy(struct mmc *mmc)
 {
struct sunxi_mmc_priv *priv = mmc->priv;
@@ -562,7 +566,8 @@ struct mmc *sunxi_mmc_init(int sdc_no)
 
return mmc_create(cfg, priv);
 }
-#else
+

[PATCH 3/3] sunxi: remove CONFIG_MMC?_CD_PIN

2022-07-13 Thread Andre Przywara
For legacy reasons we were defining the card detect GPIO for all sunxi
boards in each board's defconfig.
There is actually no need for a card-detect check in the SPL code (which
consequently has been removed already), and also in U-Boot proper we
have DM code to query the CD GPIO name from the device tree.

That means we don't have any user of that information left, so can
remove the definitions from the defconfigs.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/Kconfig  | 27 
 configs/A10-OLinuXino-Lime_defconfig |  1 -
 configs/A10s-OLinuXino-M_defconfig   |  2 --
 configs/A13-OLinuXinoM_defconfig |  1 -
 configs/A13-OLinuXino_defconfig  |  1 -
 configs/A20-OLinuXino-Lime2-eMMC_defconfig   |  1 -
 configs/A20-OLinuXino-Lime2_defconfig|  1 -
 configs/A20-OLinuXino-Lime_defconfig |  1 -
 configs/A20-OLinuXino_MICRO-eMMC_defconfig   |  1 -
 configs/A20-OLinuXino_MICRO_defconfig|  2 --
 configs/A20-Olimex-SOM-EVB_defconfig |  2 --
 configs/A20-Olimex-SOM204-EVB-eMMC_defconfig |  1 -
 configs/A20-Olimex-SOM204-EVB_defconfig  |  1 -
 configs/A33-OLinuXino_defconfig  |  1 -
 configs/Ainol_AW1_defconfig  |  1 -
 configs/Ampe_A76_defconfig   |  1 -
 configs/Bananapi_M2_Ultra_defconfig  |  1 -
 configs/Bananapi_m2m_defconfig   |  1 -
 configs/Cubieboard2_defconfig|  1 -
 configs/Cubieboard4_defconfig|  1 -
 configs/Cubieboard_defconfig |  1 -
 configs/Cubietruck_defconfig |  1 -
 configs/Empire_electronix_d709_defconfig |  1 -
 configs/Empire_electronix_m712_defconfig |  1 -
 configs/Itead_Ibox_A20_defconfig |  1 -
 configs/Lamobo_R1_defconfig  |  1 -
 configs/Mele_M3_defconfig|  1 -
 configs/Mele_M5_defconfig|  1 -
 configs/Merrii_A80_Optimus_defconfig |  1 -
 configs/Orangepi_mini_defconfig  |  2 --
 configs/Sinlinx_SinA31s_defconfig|  1 -
 configs/Sinlinx_SinA33_defconfig |  1 -
 configs/Sunchip_CX-A99_defconfig |  1 -
 configs/UTOO_P66_defconfig   |  1 -
 configs/Wobo_i5_defconfig|  1 -
 configs/Yones_Toptech_BD1078_defconfig   |  2 --
 configs/Yones_Toptech_BS1078_V2_defconfig|  1 -
 configs/bananapi_m2_berry_defconfig  |  1 -
 configs/bananapi_m2_zero_defconfig   |  1 -
 configs/bananapi_m64_defconfig   |  1 -
 configs/beelink_gs1_defconfig|  1 -
 configs/colorfly_e708_q1_defconfig   |  1 -
 configs/difrnce_dit4350_defconfig|  1 -
 configs/dserve_dsrv9703c_defconfig   |  1 -
 configs/gt90h_v4_defconfig   |  1 -
 configs/iNet_3F_defconfig|  1 -
 configs/iNet_3W_defconfig|  1 -
 configs/iNet_D978_rev2_defconfig |  1 -
 configs/icnova-a20-swac_defconfig|  1 -
 configs/inet86dz_defconfig   |  1 -
 configs/inet98v_rev2_defconfig   |  1 -
 configs/inet_q972_defconfig  |  1 -
 configs/nanopi_m1_plus_defconfig |  1 -
 configs/oceanic_5205_5inmfd_defconfig|  1 -
 configs/orangepi_3_defconfig |  1 -
 configs/orangepi_lite2_defconfig |  1 -
 configs/orangepi_one_plus_defconfig  |  1 -
 configs/orangepi_zero2_defconfig |  1 -
 configs/orangepi_zero_plus2_defconfig|  1 -
 configs/orangepi_zero_plus2_h3_defconfig |  1 -
 configs/parrot_r16_defconfig |  1 -
 configs/pine64-lts_defconfig |  1 -
 configs/pine_h64_defconfig   |  1 -
 configs/polaroid_mid2407pxe03_defconfig  |  1 -
 configs/polaroid_mid2809pxe04_defconfig  |  1 -
 configs/q8_a13_tablet_defconfig  |  1 -
 configs/q8_a23_tablet_800x480_defconfig  |  1 -
 configs/q8_a33_tablet_1024x600_defconfig |  1 -
 configs/q8_a33_tablet_800x480_defconfig  |  1 -
 configs/sopine_baseboard_defconfig   |  1 -
 configs/tanix_tx6_defconfig  |  1 -
 71 files changed, 102 deletions(-)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 71a7f8dcee..5378eed154 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -638,33 +638,6 @@ config MACPWR
  Set the pin used to power the MAC. This takes a string in the format
  understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H.
 
-config MMC0_CD_PIN
-   string "Card detect pin for mmc0"
-   default "PF6" if MACH_SUN8I_A83T || MACH_SUNXI_H3_H5 || MACH_SUN50I
-   default ""
-   ---help---
-   Set the card detect pin for mmc0, leave empty to not use cd. This
-   takes a string in the format understood by sunxi_name_to_gpio, e.g.
-   PH1 for pin 1 of por

[PATCH] dm: fix mis-word in SPL_DM description

2022-07-13 Thread Oleksandr Suvorov
Replace logically correct word in the description.

Fixes: 91a91ff804d ("dm: Add Kconfig options for driver model SPL support")
Signed-off-by: Oleksandr Suvorov 
---

 drivers/core/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index 8eb0070d222..007dc6a1de3 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -18,7 +18,7 @@ config SPL_DM
  consider using CONFIG_SPL_SYS_MALLOC_SIMPLE. In that case you
  must provide CONFIG_SPL_SYS_MALLOC_F_LEN to set the size.
  In most cases driver model will only allocate a few uclasses
- and devices in SPL, so 1KB should be enable. See
+ and devices in SPL, so 1KB should be enough. See
  CONFIG_SPL_SYS_MALLOC_F_LEN for more details on how to enable it.
 
 config TPL_DM
-- 
2.36.1



Re: [PATCH 1/7] doc: Migrate CodingStyle wiki page to Sphinx

2022-07-13 Thread Heinrich Schuchardt

On 7/11/22 19:14, Tom Rini wrote:

Move the current CodingStyle wiki page to doc/develop/codingstyle.rst.
The changes here are for formatting or slight rewording so that it reads
well when linking to other Sphinx documents.

Cc: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
Changes in v2:
- Assorted wiki -> Sphinx style corrections and a few typo fixes, per
   Heinrich
---
  doc/develop/codingstyle.rst | 255 
  doc/develop/index.rst   |   8 ++
  2 files changed, 263 insertions(+)
  create mode 100644 doc/develop/codingstyle.rst

diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst
new file mode 100644
index ..bbeca42e656b
--- /dev/null
+++ b/doc/develop/codingstyle.rst
@@ -0,0 +1,255 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+U-Boot Coding Style
+===
+
+The following Coding Style requirements shall be mandatory for all code 
contributed to
+the U-Boot project.
+
+Exceptions are only allowed if code from other projects is integrated with no
+or only minimal changes.
+
+The following rules apply:
+
+* All contributions to U-Boot should conform to the `Linux kernel
+  coding style 
`_
+  and the `Lindent script 
`_.
+  * The exception for net files to the `multi-line comment
+  
`_
+  applies only to Linux, not to U-Boot. Only large hunks which are copied
+  unchanged from Linux may retain that comment format.
+
+* Use patman to send your patches (``tools/patman/patman -H`` for full
+  instructions). With a few tags in your commits this will check your patches
+  and take care of emailing them.
+
+* If you don't use patman, make sure to run ``scripts/checkpatch.pl``. For
+  more information, read :doc:`checkpatch`. Note that this should be done
+  *before* posting on the mailing list!
+
+* Source files originating from different projects (for example the MTD
+  subsystem or the hush shell code from the BusyBox project) may, after
+  careful consideration, be exempted from these rules. For such files, the
+  original coding style may be kept to ease subsequent migration to newer
+  versions of those sources.
+
+* Please note that U-Boot is implemented in C (and to some small parts in
+  Assembler); no C++ is used, so please do not use C++ style comments (//) in
+  your code.
+
+  * The sole exception here is for SPDX tags in some files (checkpatch.pl will 
warn you).
+
+* Please also stick to the following formatting rules:
+
+  * Remove any trailing white space
+
+  * Use TAB characters for indentation and vertical alignment, not spaces


This only holds true for C and assembler code.
For Python we use 4 spaces per indent.


+
+  * Make sure NOT to use DOS ``\r\n`` line feeds


%s/DOS/Windows/ - The documentation is not dedicated to veterans.
%s/line feeds/line ends/ - a line feed is always 0x0a.

\r\n are escape codes in C. On a Windows machine these will be rendered
as CR CR LF.

Please, use CR LF instead of \r\n.


+
+  * Do not add more than 2 consecutive empty lines to source files
+
+  * Do not add trailing empty lines to source files
+
+  * Using the option ``git config --global color.diff auto`` will help to
+visually see whitespace problems in ``diff`` output from ``git``.
+
+  * In Emacs one can use ``=M-x whitespace-global-mode=`` to get visual
+feedback on the nasty details. ``=M-x whitespace-cleanup=`` does The Right
+Thing (tm)


No clue why 'The Right Thing' should be a trademark here.
Please, remove this bogus.


+
+Submissions of new code or patches that do not conform to these requirements
+shall be rejected with a request to reformat the changes.
+
+U-Boot Code Documentation
+-
+
+U-Boot adopted the kernel-doc annotation style, this is the only exception from
+multi-line comment rule of Coding Style. While not mandatory, adding


Do you mean the extra asterisk?


+documentation is strongly advised. The Linux kernel `kernel-doc
+`_
+documentation applies with no changes.
+
+Use structures for I/O access
+-
+
+U-Boot typically uses a C structure to map out the registers in an I/O region,
+rather than offsets. The reasons for this are:
+
+* It dissociates the register location (offset) from the register type, which
+  means the developer has to make sure the type is right for each access,
+  whereas with the struct method, this is checked by the compiler;
+
+* It avoids actually writing all offsets, which is (more) error- prone;


%s/error- prone/error-prone/


+
+* It allows for better compile time sanity-checking of values we write to 
registers.
+
+Some reasons why you might not use C structures:
+
+* Where the registers appear at different off

Re: [PATCH 2/7] doc: Migrate DesignPrinciples wiki page to Sphinx

2022-07-13 Thread Heinrich Schuchardt

On 7/11/22 19:14, Tom Rini wrote:

Move the current DesignPrinciples wiki page to
doc/develop/designprinciples.rst.  The changes here are for formatting
or slight rewording so that it reads well when linking to other Sphinx
documents.

Cc: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
Changes in v2:
- Assorted wiki -> Sphinx style corrections and a few typo fixes, per
   Heinrich
---
  doc/develop/designprinciples.rst | 205 +++
  doc/develop/index.rst|   1 +
  2 files changed, 206 insertions(+)
  create mode 100644 doc/develop/designprinciples.rst

diff --git a/doc/develop/designprinciples.rst b/doc/develop/designprinciples.rst
new file mode 100644
index ..43aeb5dacf5f
--- /dev/null
+++ b/doc/develop/designprinciples.rst
@@ -0,0 +1,205 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+U-Boot Design Principles
+
+
+The 10 Golden Rules of U-Boot design
+
+
+Keep it Small
+^
+
+U-Boot is a Boot Loader, i.e. its primary purpose in the shipping
+system is to load some operating system.
+That means that U-Boot is
+necessary to perform a certain task, but it's nothing you want to
+throw any significant resources at. Typically U-Boot is stored in
+relatively small NOR flash memory, which is expensive
+compared to the much larger NAND devices often used to store the
+operating system and the application.
+
+At the moment, U-Boot supports boards with just 128 KiB ROM or with
+256 KiB NOR flash. We should not easily ignore such configurations -
+they may be the exception in among all the other supported boards,
+but if a design uses such a resource-constrained hardware setup it is
+usually because costs are critical, i. e. because the number of
+manufactured boards might be tens or hundreds of thousands or even
+millions...
+
+A usable and useful configuration of U-Boot, including a basic
+interactive command interpreter, support for download over Ethernet
+and the capability to program the flash shall fit in no more than 128 !KiB.
+
+Keep it Fast
+
+
+The end user is not interested in running U-Boot. In most embedded
+systems he is not even aware that U-Boot exists. The user wants to
+run some application code, and that as soon as possible after switching
+on his device.
+
+It is therefore essential that U-Boot is as fast as possible,
+especially that it loads and boots the operating system as fast as possible.
+
+To achieve this, the following design principles shall be followed:
+
+* Enable caches as soon and whenever possible
+
+* Initialize devices only when they are needed within U-Boot, i.e. don't
+  initialize the Ethernet interface(s) unless U-Boot performs a download over
+  Ethernet; don't  initialize any IDE or USB devices unless U-Boot actually
+  tries to load files from these, etc.  (and don't forget to shut down these
+  devices after using them  - otherwise nasty things may happen when you try to
+  boot your OS).
+
+Also, building of U-Boot shall be as fast as possible.
+This makes it easier to run a build for all supported configurations
+or at least for all configurations of a specific architecture,
+which is essential for quality assurance.
+If building is cumbersome and slow, most people will omit
+this important step.
+
+Keep it Simple
+^^
+
+U-Boot is a boot loader, but it is also a tool used for board
+bring-up, for production testing, and for other activities
+
+Keep it Portable
+
+
+U-Boot is a boot loader, but it is also a tool used for board
+bring-up, for production testing, and for other activities that are
+very closely related to hardware development. So far, it has been
+ported to several hundreds of different boards on about 30 different
+processor families - please make sure that any code you add can be
+used on as many different platforms as possible.
+
+Avoid assembly language whenever possible - only the reset code with
+basic CPU initialization, maybe a static DRAM initialization and the C
+stack setup should be in assembly.
+All further initializations should be done in C using assembly/C
+subroutines or inline macros. These functions represent some
+kind of HAL functionality and should be defined consistently on all
+architectures. E.g. Basic MMU and cache control, stack pointer manipulation.


%s/\. E\.g\./, e.g./

%s/Basic/basic/


+Non-existing functions should expand into empty macros or error codes.
+
+Don't make assumptions over the environment where U-Boot is running.


%s/over/about/


+It may be communicating with a human operator on directly attached
+serial console, but it may be through a GSM modem as well, or driven
+by some automatic test or control system. So don't output any fancy
+control character sequences or similar.
+
+Keep it Configurable
+
+
+Section "Keep it Small" already explains about the size restrictions
+for U-Boot on one side. On the other side, U-Boot is a powerfu

Re: [PATCH 1/7] doc: Migrate CodingStyle wiki page to Sphinx

2022-07-13 Thread Tom Rini
On Wed, Jul 13, 2022 at 07:06:56PM +0200, Heinrich Schuchardt wrote:
> On 7/11/22 19:14, Tom Rini wrote:
> > Move the current CodingStyle wiki page to doc/develop/codingstyle.rst.
> > The changes here are for formatting or slight rewording so that it reads
> > well when linking to other Sphinx documents.
> > 
> > Cc: Heinrich Schuchardt 
> > Signed-off-by: Tom Rini 
> > ---
> > Changes in v2:
> > - Assorted wiki -> Sphinx style corrections and a few typo fixes, per
> >Heinrich
> > ---
> >   doc/develop/codingstyle.rst | 255 
> >   doc/develop/index.rst   |   8 ++
> >   2 files changed, 263 insertions(+)
> >   create mode 100644 doc/develop/codingstyle.rst
> > 
> > diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst
> > new file mode 100644
> > index ..bbeca42e656b
> > --- /dev/null
> > +++ b/doc/develop/codingstyle.rst
> > @@ -0,0 +1,255 @@
> > +.. SPDX-License-Identifier: GPL-2.0+:
> > +
> > +U-Boot Coding Style
> > +===
> > +
> > +The following Coding Style requirements shall be mandatory for all code 
> > contributed to
> > +the U-Boot project.
> > +
> > +Exceptions are only allowed if code from other projects is integrated with 
> > no
> > +or only minimal changes.
> > +
> > +The following rules apply:
> > +
> > +* All contributions to U-Boot should conform to the `Linux kernel
> > +  coding style 
> > `_
> > +  and the `Lindent script 
> > `_.
> > +  * The exception for net files to the `multi-line comment
> > +  
> > `_
> > +  applies only to Linux, not to U-Boot. Only large hunks which are copied
> > +  unchanged from Linux may retain that comment format.
> > +
> > +* Use patman to send your patches (``tools/patman/patman -H`` for full
> > +  instructions). With a few tags in your commits this will check your 
> > patches
> > +  and take care of emailing them.
> > +
> > +* If you don't use patman, make sure to run ``scripts/checkpatch.pl``. For
> > +  more information, read :doc:`checkpatch`. Note that this should be done
> > +  *before* posting on the mailing list!
> > +
> > +* Source files originating from different projects (for example the MTD
> > +  subsystem or the hush shell code from the BusyBox project) may, after
> > +  careful consideration, be exempted from these rules. For such files, the
> > +  original coding style may be kept to ease subsequent migration to newer
> > +  versions of those sources.
> > +
> > +* Please note that U-Boot is implemented in C (and to some small parts in
> > +  Assembler); no C++ is used, so please do not use C++ style comments (//) 
> > in
> > +  your code.
> > +
> > +  * The sole exception here is for SPDX tags in some files (checkpatch.pl 
> > will warn you).
> > +
> > +* Please also stick to the following formatting rules:
> > +
> > +  * Remove any trailing white space
> > +
> > +  * Use TAB characters for indentation and vertical alignment, not spaces
> 
> This only holds true for C and assembler code.
> For Python we use 4 spaces per indent.
> 
> > +
> > +  * Make sure NOT to use DOS ``\r\n`` line feeds
> 
> %s/DOS/Windows/ - The documentation is not dedicated to veterans.
> %s/line feeds/line ends/ - a line feed is always 0x0a.
> 
> \r\n are escape codes in C. On a Windows machine these will be rendered
> as CR CR LF.
> 
> Please, use CR LF instead of \r\n.
> 
> > +
> > +  * Do not add more than 2 consecutive empty lines to source files
> > +
> > +  * Do not add trailing empty lines to source files
> > +
> > +  * Using the option ``git config --global color.diff auto`` will help to
> > +visually see whitespace problems in ``diff`` output from ``git``.
> > +
> > +  * In Emacs one can use ``=M-x whitespace-global-mode=`` to get visual
> > +feedback on the nasty details. ``=M-x whitespace-cleanup=`` does The 
> > Right
> > +Thing (tm)
> 
> No clue why 'The Right Thing' should be a trademark here.
> Please, remove this bogus.
> 
> > +
> > +Submissions of new code or patches that do not conform to these 
> > requirements
> > +shall be rejected with a request to reformat the changes.
> > +
> > +U-Boot Code Documentation
> > +-
> > +
> > +U-Boot adopted the kernel-doc annotation style, this is the only exception 
> > from
> > +multi-line comment rule of Coding Style. While not mandatory, adding
> 
> Do you mean the extra asterisk?
> 
> > +documentation is strongly advised. The Linux kernel `kernel-doc
> > +`_
> > +documentation applies with no changes.
> > +
> > +Use structures for I/O access
> > +-
> > +
> > +U-Boot typically uses a C structure to map out the registers in an I/O 
> > region,
> > +rather than offs

Re: [PATCH 4/7] doc: Migrate Process wiki page to Sphinx

2022-07-13 Thread Heinrich Schuchardt

On 7/11/22 19:14, Tom Rini wrote:

Move the current Process wiki page to doc/develop/process.rst.  The
changes here are for formatting or slight rewording so that it reads
well when linking to other Sphinx documents.

Cc: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
Changes in v2:
- Assorted wiki -> Sphinx style corrections and a few typo fixes, per
   Heinrich
---
  doc/develop/index.rst   |   1 +
  doc/develop/process.rst | 200 
  2 files changed, 201 insertions(+)
  create mode 100644 doc/develop/process.rst

diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index c0f4f0ba413a..eab00a55382a 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -11,6 +11,7 @@ General

 codingstyle
 designprinciples
+   process

  Implementation
  --
diff --git a/doc/develop/process.rst b/doc/develop/process.rst
new file mode 100644
index ..534da4a2a704
--- /dev/null
+++ b/doc/develop/process.rst
@@ -0,0 +1,200 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+U-Boot Development Process
+==
+
+Management Summary
+--
+
+* Development happens in Release Cycles of 3 months.
+
+* The first 2 weeks are called Merge Window, which is followed by a
+  Stabilization Period.
+
+* Patches with new code get only accepted while the Merge Window is open.
+
+* A patch that is generally in good shape and that was submitted while the
+  Merge Window was open is eligible to go into the upcoming release, even if
+  changes and resubmits are needed.
+
+* During the Stabilization Period, only patches that contain bug fixes get
+  applied.
+
+Phases of the Development Process
+-
+
+U-Boot development takes place in `Release Cycles
+`_.  A Release Cycle lasts
+normally for three months.
+
+The first two weeks of each Release Cycle are called *Merge Window*.
+
+It is followed by a *Stabilization Period*.
+
+The end of a Release Cycle is marked by the release of a new U-Boot version.
+
+Merge Window
+
+
+The Merge Window is the period when new patches get submitted
+(and hopefully accepted) for inclusion into U-Boot mainline.
+
+This is the only time when new code (like support for new processors or new
+boards, or other new features or reorganization of code) is accepted.
+
+Twilight Time
+-
+
+Usually patches do not get accepted as they are - the peer review that takes
+place will usually require changes and resubmits of the patches before they
+are considered to be ripe for inclusion into mainline.
+
+Also, the review often happens not immediately after a patch was submitted,
+but only when somebody (usually the responsible custodian) finds time to do
+this.
+
+In the result, the final version of such patches gets submitted after the
+merge window has been closed.
+
+It is current practice in U-Boot that such patches are eligible to go into the
+upcoming release.
+
+In the result, the release of the ``"-rc1"`` version does not immediately 
follow
+the closing of the Merge Window.
+
+Stabilization Period
+
+
+During the Stabilization Period only patches containing bug fixes get
+applied.
+
+Corner Cases
+
+
+Sometimes it is not clear if a patch contains a bug fix or not.
+For example, changes that remove dead code, unused macros etc. or
+that contain Coding Style fixes are not strict bug fixes.
+
+In such situations it is up to the responsible custodian to decide if he
+applies such patches even when the Merge Window is closed.
+
+Exception: at the end of the Stabilization Period only strict bug
+fixes my be applied.
+
+Sometimes patches miss the the Merge Window slightly - say by few
+hours or even a day. Patch acceptance is not as critical as a
+financial transaction, or such. So if there is such a slight delay,
+the custodian is free to turn a blind eye and accept it anyway. The
+idea of the development process is to make it foreseeable,
+but not to slow down development.
+
+It makes more sense if an engineer spends another day on testing and
+cleanup and submits the patch a couple of hours late, instead of
+submitting a green patch which will waste efforts from several people
+during several rounds of review and reposts.
+
+Differences to the Linux Development Process
+
+
+* In Linux, top-level maintainers will collect patches in their trees and send
+  pull requests to Linus as soon as the merge window opens.
+  So far, most U-Boot custodians do not work like that; they send pull requests
+  only at (or even after) the end of the merge window.
+
+* In Linux, the closing of the merge window is marked by the release of the
+  next ``"-rc1"``
+  In U-Boot, ``"-rc1"`` will only be released after all (or at least most of
+  the) patches that were submitted during the merge window have been applied.
+
+Custodians
+--
+
+The Custodi

Re: [PATCH 5/7] designprinciples.rst: Perform minor cleanups

2022-07-13 Thread Heinrich Schuchardt

On 7/11/22 19:14, Tom Rini wrote:

- Remove some missed wiki markup, and escape a "\n" correctly.
- Use gender-neutral language to refer to the user, consistently.

Cc: Claudius Heine 
Cc: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
Changes in v2:
- None
---
  doc/develop/designprinciples.rst | 24 
  1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/doc/develop/designprinciples.rst b/doc/develop/designprinciples.rst
index 43aeb5dacf5f..e5e12dca79f5 100644
--- a/doc/develop/designprinciples.rst
+++ b/doc/develop/designprinciples.rst
@@ -28,15 +28,15 @@ millions...

  A usable and useful configuration of U-Boot, including a basic
  interactive command interpreter, support for download over Ethernet
-and the capability to program the flash shall fit in no more than 128 !KiB.
+and the capability to program the flash shall fit in no more than 128 KiB.

  Keep it Fast
  

  The end user is not interested in running U-Boot. In most embedded
-systems he is not even aware that U-Boot exists. The user wants to
+systems they are not even aware that U-Boot exists. The user wants to


"The end user" is singular.


  run some application code, and that as soon as possible after switching
-on his device.
+on their device.

  It is therefore essential that U-Boot is as fast as possible,
  especially that it loads and boots the operating system as fast as possible.
@@ -63,7 +63,7 @@ Keep it Simple
  ^^

  U-Boot is a boot loader, but it is also a tool used for board
-bring-up, for production testing, and for other activities
+bring-up, for production testing, and for other activities.

  Keep it Portable
  
@@ -96,13 +96,13 @@ Keep it Configurable
  Section "Keep it Small" already explains about the size restrictions
  for U-Boot on one side. On the other side, U-Boot is a powerful tool
  with many, many extremely useful features. The maintainer or user of
-each board will have to decide which features are important to him and
-what shall be included with his specific board configuration to meet
-his current requirements and restrictions.
+each board will have to decide which features are important to them and
+what shall be included with their specific board configuration to meet
+their current requirements and restrictions.

  Please make sure that it is easy to add or remove features from a
  board configuration, so everybody can make the best use of U-Boot on
-his system.
+their system.

  If a feature is not included, it should not have any residual code
  bloating the build.
@@ -126,7 +126,7 @@ debug is all the more important to many of us.
  * All initialization steps shall print some "begin doing this" message before
they actually start, and some "done" message when they complete. For 
example,
RAM initialization and size detection may print a "RAM: " before they start,
-  and "256 MB\n" when done.  The purpose of this is that you can always see
+  and "256 MB\\n" when done.  The purpose of this is that you can always see


%s/MB/MiB/


which initialization step was running if there should be any problem.  This
is important not only during software development, but also for the service
people dealing with broken hardware in the field.
@@ -143,8 +143,8 @@ Please always keep in mind that there are at least three 
different
  groups of users for U-Boot, with completely different expectations
  and requirements:

-* The end user of an embedded device just wants to run some application; he
-  does not even want to know that U-Boot exists and only rarely interacts with
+* The end user of an embedded device just wants to run some application; they


Please, don't mix singular and plural.


+  do not even want to know that U-Boot exists and only rarely interacts with
it (for example to perform a reset to factory default settings etc.)

  * System designers and engineers working on the development of the application
@@ -157,7 +157,7 @@ and requirements:
their hardware is easy for them.

  * Make it easy to test. Add debug code (but don't re-invent the wheel - use
-  existing macros like debug() or debugX()).
+  existing macros like debug()).


%s/debug()/log_debug()/

Best regards

Heinrich



  Please always keep in mind that U-Boot tries to meet all these
  different requirements.




Re: [PATCH 1/7] doc: Migrate CodingStyle wiki page to Sphinx

2022-07-13 Thread Tom Rini
On Wed, Jul 13, 2022 at 07:06:56PM +0200, Heinrich Schuchardt wrote:
> On 7/11/22 19:14, Tom Rini wrote:
> > Move the current CodingStyle wiki page to doc/develop/codingstyle.rst.
> > The changes here are for formatting or slight rewording so that it reads
> > well when linking to other Sphinx documents.
> > 
> > Cc: Heinrich Schuchardt 
> > Signed-off-by: Tom Rini 
> > ---
> > Changes in v2:
> > - Assorted wiki -> Sphinx style corrections and a few typo fixes, per
> >Heinrich
> > ---
> >   doc/develop/codingstyle.rst | 255 
> >   doc/develop/index.rst   |   8 ++
> >   2 files changed, 263 insertions(+)
> >   create mode 100644 doc/develop/codingstyle.rst
> > 
> > diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst
> > new file mode 100644
> > index ..bbeca42e656b
> > --- /dev/null
> > +++ b/doc/develop/codingstyle.rst
> > @@ -0,0 +1,255 @@
> > +.. SPDX-License-Identifier: GPL-2.0+:
> > +
> > +U-Boot Coding Style
> > +===
> > +
> > +The following Coding Style requirements shall be mandatory for all code 
> > contributed to
> > +the U-Boot project.
> > +
> > +Exceptions are only allowed if code from other projects is integrated with 
> > no
> > +or only minimal changes.
> > +
> > +The following rules apply:
> > +
> > +* All contributions to U-Boot should conform to the `Linux kernel
> > +  coding style 
> > `_
> > +  and the `Lindent script 
> > `_.
> > +  * The exception for net files to the `multi-line comment
> > +  
> > `_
> > +  applies only to Linux, not to U-Boot. Only large hunks which are copied
> > +  unchanged from Linux may retain that comment format.
> > +
> > +* Use patman to send your patches (``tools/patman/patman -H`` for full
> > +  instructions). With a few tags in your commits this will check your 
> > patches
> > +  and take care of emailing them.
> > +
> > +* If you don't use patman, make sure to run ``scripts/checkpatch.pl``. For
> > +  more information, read :doc:`checkpatch`. Note that this should be done
> > +  *before* posting on the mailing list!
> > +
> > +* Source files originating from different projects (for example the MTD
> > +  subsystem or the hush shell code from the BusyBox project) may, after
> > +  careful consideration, be exempted from these rules. For such files, the
> > +  original coding style may be kept to ease subsequent migration to newer
> > +  versions of those sources.
> > +
> > +* Please note that U-Boot is implemented in C (and to some small parts in
> > +  Assembler); no C++ is used, so please do not use C++ style comments (//) 
> > in
> > +  your code.
> > +
> > +  * The sole exception here is for SPDX tags in some files (checkpatch.pl 
> > will warn you).
> > +
> > +* Please also stick to the following formatting rules:
> > +
> > +  * Remove any trailing white space
> > +
> > +  * Use TAB characters for indentation and vertical alignment, not spaces
> 
> This only holds true for C and assembler code.
> For Python we use 4 spaces per indent.
> 
> > +
> > +  * Make sure NOT to use DOS ``\r\n`` line feeds
> 
> %s/DOS/Windows/ - The documentation is not dedicated to veterans.
> %s/line feeds/line ends/ - a line feed is always 0x0a.
> 
> \r\n are escape codes in C. On a Windows machine these will be rendered
> as CR CR LF.
> 
> Please, use CR LF instead of \r\n.
> 
> > +
> > +  * Do not add more than 2 consecutive empty lines to source files
> > +
> > +  * Do not add trailing empty lines to source files
> > +
> > +  * Using the option ``git config --global color.diff auto`` will help to
> > +visually see whitespace problems in ``diff`` output from ``git``.
> > +
> > +  * In Emacs one can use ``=M-x whitespace-global-mode=`` to get visual
> > +feedback on the nasty details. ``=M-x whitespace-cleanup=`` does The 
> > Right
> > +Thing (tm)
> 
> No clue why 'The Right Thing' should be a trademark here.
> Please, remove this bogus.

The phrase "The Right Thing (tm)" is I guess an old joke, as it implies
it will probably work, but still might mess up from time to time.  I'd
rather keep it.

> > +
> > +Submissions of new code or patches that do not conform to these 
> > requirements
> > +shall be rejected with a request to reformat the changes.
> > +
> > +U-Boot Code Documentation
> > +-
> > +
> > +U-Boot adopted the kernel-doc annotation style, this is the only exception 
> > from
> > +multi-line comment rule of Coding Style. While not mandatory, adding
> 
> Do you mean the extra asterisk?

Yes.

> > +documentation is strongly advised. The Linux kernel `kernel-doc
> > +`_
> > +documentation applies with no changes.
> > +
> > +Use structures for 

Re: [PATCH 6/7] process.rst: Perform minor cleanups

2022-07-13 Thread Heinrich Schuchardt

On 7/11/22 19:14, Tom Rini wrote:

- Use gender-neutral language to refer to the user, consistently.
- Reword a few places so that they read more naturally.
- Make the long standing practice around "Twilight Time" more clear,
   hopefully.
- Replace a reference to MAKEALL with a reference to CI testing as
   that's the current requirement.

Cc: Claudius Heine 
Cc: Martin Bonner 
Cc: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
Changes in v2:
- Further tweak the wording, per Martin
---
  doc/develop/process.rst | 33 +
  1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/doc/develop/process.rst b/doc/develop/process.rst
index 534da4a2a704..d0c46b58f3e9 100644
--- a/doc/develop/process.rst
+++ b/doc/develop/process.rst
@@ -46,21 +46,22 @@ Twilight Time
  -

  Usually patches do not get accepted as they are - the peer review that takes
-place will usually require changes and resubmits of the patches before they
+place will usually require changes and resubmissions of the patches before they
  are considered to be ripe for inclusion into mainline.

-Also, the review often happens not immediately after a patch was submitted,
+Also the review often happens not immediately after a patch was submitted,
  but only when somebody (usually the responsible custodian) finds time to do
  this.

-In the result, the final version of such patches gets submitted after the
+The result is that the final version of such patches gets submitted after the
  merge window has been closed.

  It is current practice in U-Boot that such patches are eligible to go into the
  upcoming release.

-In the result, the release of the ``"-rc1"`` version does not immediately 
follow
-the closing of the Merge Window.
+The result is that the release of the ``"-rc1"`` version and formal closing of
+the Merge Window does not preclude patches that were already posted from being
+merged for the upcoming release.

  Stabilization Period
  
@@ -75,13 +76,13 @@ Sometimes it is not clear if a patch contains a bug fix or 
not.
  For example, changes that remove dead code, unused macros etc. or
  that contain Coding Style fixes are not strict bug fixes.

-In such situations it is up to the responsible custodian to decide if he
-applies such patches even when the Merge Window is closed.
+In such situations it is up to the responsible custodian to decide if they


The custodian is singular.


+apply such patches even when the Merge Window is closed.

  Exception: at the end of the Stabilization Period only strict bug
  fixes my be applied.

-Sometimes patches miss the the Merge Window slightly - say by few
+Sometimes patches miss the Merge Window slightly - say by a few
  hours or even a day. Patch acceptance is not as critical as a
  financial transaction, or such. So if there is such a slight delay,
  the custodian is free to turn a blind eye and accept it anyway. The
@@ -110,7 +111,7 @@ Custodians
  --

  The Custodians take responsibility for some area of the U-Boot code.  The
-in-tree ``MAINTAINERS`` files list who is reponsible for which areas.
+in-tree ``MAINTAINERS`` files list who is responsible for which areas.

  It is their responsibility to pick up patches from the mailing list
  that fall into their responsibility, and to process these.
@@ -155,7 +156,7 @@ like this:

 #. Applies cleanly to the source tree

-   #. passes a ``MAKEALL`` compile test without creating new warnings
+   #. Passes :doc:`ci_testing` as this checks for new warnings and other 
issues.


%s/ci/CI/



  #. Notes:

@@ -167,7 +168,7 @@ like this:

#. This is well documented in :doc:`designprinciples`.

-  #. The custodian decides himself how recent the code must be.  It is
+  #. The custodian decides themselves how recent the code must be.  It is


The custodian is singular.


   acceptable to request patches against the last officially released
   version of U-Boot or newer.  Of course a custodian can also accept
   patches against older code.
@@ -177,7 +178,7 @@ like this:

  #. The custodian decides to accept or to reject the patch.

-#. If accepted, the custodian adds the patch to his public git repository and
+#. If accepted, the custodian adds the patch to their public git repository and
 notifies the mailing list. This note should include:

 * a short description of the changes
@@ -186,15 +187,15 @@ like this:

 * suggested tests

-   Although the custodian is supposed to perform his own tests
-   it is a well-known and accepted fact that he needs help from
+   Although the custodian is supposed to perform their own tests


ditto


+   it is a well-known and accepted fact that they needs help from
 other developers who - for example - have access to the required
 hardware or tool chains.
 The custodian request help for tests and feedback from
 specific maintainers and U-Boot users.

  #. Once tests are passed, some agreed time limit

Re: [PATCH 4/7] doc: Migrate Process wiki page to Sphinx

2022-07-13 Thread Tom Rini
On Wed, Jul 13, 2022 at 07:36:02PM +0200, Heinrich Schuchardt wrote:
> On 7/11/22 19:14, Tom Rini wrote:
[snip]
> > +Work flow of a Custodian
> > +
> > +
> > +The normal flow of work in the U-Boot development process will look
> > +like this:
> > +
> > +#. A developer submits a patch via e-mail to the u-boot-users mailing list.
> > +   U-Boot has adopted the `Linux kernel signoff policy 
> > `_, so the 
> > submitter must
> > +   include a ``Signed-off-by:`` line.
> > +
> > +#. Everybody who can is invited to review and test the changes.  Reviews 
> > should
> > +   reply on the mailing list with ``Acked-by`` lines.
> > +
> > +#. The responsible custodian
> > +
> > +   #. inspects this patch, especially for:
> 
> This should not be a bullet point.
> 
> > +
> > +   #. :doc:`codingstyle`
> > +
> > +   #. Basic logic:
> > +
> > +  * The patch fixes a real problem.
> > +
> > +  * The patch does not introduce new problems, especially it does not 
> > break
> > +other boards or architectures
> > +
> > +   #. U-Boot Philosophy
> > +
> > +   #. Applies cleanly to the source tree
> > +
> > +   #. passes a ``MAKEALL`` compile test without creating new warnings
> > +
> > +#. Notes:
> > +
> > +  #. In some cases more than one custodian may be affected or feel 
> > responsible.
> > + To avoid duplicated efforts, the custodian who starts processing the
> > + patch should send a short ACK to the mailing list.
> > +
> > +  #. We should create some tool to automatically do this.
> > +
> > +  #. This is well documented in :doc:`designprinciples`.
> > +
> > +  #. The custodian decides himself how recent the code must be.  It is
> > + acceptable to request patches against the last officially released
> > + version of U-Boot or newer.  Of course a custodian can also accept
> > + patches against older code.
> 
> This paragraph is unclear. How about:
> 
> Patches should be based on the git HEAD. If merge conflicts arise, the
> custodian decides to either rebase the patch himself or to request the
> submitter for a rebased patch.
> 
> > +
> > +  #. Commits should show original author in the ``author`` field and 
> > include all
> > +  sign off/ack lines.
> 
> Sign-off, Acked-by, Reviewed-by lines.

Please comment on the later patch where I re-write this section a good
deal.  To repeat, I do not want to make significant changes to these
documents in the same commit that imports them from the wiki.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 7/7] process.rst: Modernize the "Workflow of a Custodian" section

2022-07-13 Thread Heinrich Schuchardt

On 7/11/22 19:14, Tom Rini wrote:

The "Workflow of a Custodian" section on the wiki had not been changed
in quite some time to reflect how the process has been functioning for
some time.  First, update some links to point to modern and current
sources of information.

Second, and more overarching, reword much of the section.  This expands
on the expectations of both custodians and developers when it comes to
rebasing patches.  Rework the final points to be clearer that Custodians
are expected to do their best to test the changes and ask for help when
needed, as well as that pull requests are expected in a timely manner.

Cc: Claudius Heine 
Cc: Martin Bonner 
Cc: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
Changes in v2:
- New patch
---
  doc/develop/process.rst | 88 -
  1 file changed, 42 insertions(+), 46 deletions(-)

diff --git a/doc/develop/process.rst b/doc/develop/process.rst
index d0c46b58f3e9..56c9d274be71 100644
--- a/doc/develop/process.rst
+++ b/doc/develop/process.rst
@@ -132,16 +132,20 @@ Work flow of a Custodian
  The normal flow of work in the U-Boot development process will look
  like this:

-#. A developer submits a patch via e-mail to the u-boot-users mailing list.
-   U-Boot has adopted the `Linux kernel signoff policy 
`_, so the 
submitter must
-   include a ``Signed-off-by:`` line.
+#. A developer submits a patch via e-mail to the u-boot mailing list.  In
+   U-Boot, we make use of the `Developer Certificate of Origin
+   `_ that is common in other projects such
+   as the Linux kernel.  Following this and adding a ``Signed-off-by:`` line
+   that contains the developer's name and email address is required.

-#. Everybody who can is invited to review and test the changes.  Reviews should
-   reply on the mailing list with ``Acked-by`` lines.
+#. Everybody who can is invited to review and test the changes.  Typically, we
+   follow the same guidelines as the Linux kernel for `Acked-by
+   
`_
+   as well as `Reviewed-by
+   
`_
+   and similar additional tags.

-#. The responsible custodian
-
-   #. inspects this patch, especially for:
+#. The responsible custodian inspects this patch, especially for:

 #. :doc:`codingstyle`

@@ -152,50 +156,42 @@ like this:
* The patch does not introduce new problems, especially it does not 
break
  other boards or architectures

-   #. U-Boot Philosophy
+   #. U-Boot Philosophy, as documented in :doc:`designprinciples`.

-   #. Applies cleanly to the source tree
+   #. Applies cleanly to the source tree.  The custodian is expected to put in
+  a "best effort" if a patch does not apply cleanly, but can be made to 
apply
+  still.  It is up to the custodian to decide how recent of a commit the
+  patch must be against.  It is acceptable to request patches against the
+  last officially released version of U-Boot or newer.  Of course a
+  custodian can also accept patches against older code.  It can be
+  difficult to find the correct balance between putting too much work on
+  the custodian or too much work on an individual submitting a patch when
+  something does not apply cleanly.

 #. Passes :doc:`ci_testing` as this checks for new warnings and other 
issues.

-#. Notes:
-
-  #. In some cases more than one custodian may be affected or feel responsible.
- To avoid duplicated efforts, the custodian who starts processing the
- patch should send a short ACK to the mailing list.
-
-  #. We should create some tool to automatically do this.
-
-  #. This is well documented in :doc:`designprinciples`.
-
-  #. The custodian decides themselves how recent the code must be.  It is
- acceptable to request patches against the last officially released
- version of U-Boot or newer.  Of course a custodian can also accept
- patches against older code.
-
-  #. Commits should show original author in the ``author`` field and include 
all
-  sign off/ack lines.
-
-#. The custodian decides to accept or to reject the patch.
-
-#. If accepted, the custodian adds the patch to their public git repository and
-   notifies the mailing list. This note should include:
+#. Note that in some cases more than one custodian may feel responsible for a
+   particular change.  To avoid duplicated efforts, the custodian who starts
+   processing the patch should follow up to the email saying they intend to
+   pick it up.

-   * a short description of the changes
+#. Commits must show original author in the ``author`` field and include all of
+   the ``Signed-off-by``, ``Reviewed-by``, etc, tags that have been submit

Re: [PATCH 2/7] doc: Migrate DesignPrinciples wiki page to Sphinx

2022-07-13 Thread Tom Rini
On Wed, Jul 13, 2022 at 07:22:33PM +0200, Heinrich Schuchardt wrote:
> On 7/11/22 19:14, Tom Rini wrote:
> > Move the current DesignPrinciples wiki page to
> > doc/develop/designprinciples.rst.  The changes here are for formatting
> > or slight rewording so that it reads well when linking to other Sphinx
> > documents.
> > 
> > Cc: Heinrich Schuchardt 
> > Signed-off-by: Tom Rini 
> > ---
> > Changes in v2:
> > - Assorted wiki -> Sphinx style corrections and a few typo fixes, per
> >Heinrich
> > ---
> >   doc/develop/designprinciples.rst | 205 +++
> >   doc/develop/index.rst|   1 +
> >   2 files changed, 206 insertions(+)
> >   create mode 100644 doc/develop/designprinciples.rst
> > 
> > diff --git a/doc/develop/designprinciples.rst 
> > b/doc/develop/designprinciples.rst
> > new file mode 100644
> > index ..43aeb5dacf5f
> > --- /dev/null
> > +++ b/doc/develop/designprinciples.rst
> > @@ -0,0 +1,205 @@
> > +.. SPDX-License-Identifier: GPL-2.0+:
> > +
> > +U-Boot Design Principles
> > +
> > +
> > +The 10 Golden Rules of U-Boot design
> > +
> > +
> > +Keep it Small
> > +^
> > +
> > +U-Boot is a Boot Loader, i.e. its primary purpose in the shipping
> > +system is to load some operating system.
> > +That means that U-Boot is
> > +necessary to perform a certain task, but it's nothing you want to
> > +throw any significant resources at. Typically U-Boot is stored in
> > +relatively small NOR flash memory, which is expensive
> > +compared to the much larger NAND devices often used to store the
> > +operating system and the application.
> > +
> > +At the moment, U-Boot supports boards with just 128 KiB ROM or with
> > +256 KiB NOR flash. We should not easily ignore such configurations -
> > +they may be the exception in among all the other supported boards,
> > +but if a design uses such a resource-constrained hardware setup it is
> > +usually because costs are critical, i. e. because the number of
> > +manufactured boards might be tens or hundreds of thousands or even
> > +millions...
> > +
> > +A usable and useful configuration of U-Boot, including a basic
> > +interactive command interpreter, support for download over Ethernet
> > +and the capability to program the flash shall fit in no more than 128 !KiB.
> > +
> > +Keep it Fast
> > +
> > +
> > +The end user is not interested in running U-Boot. In most embedded
> > +systems he is not even aware that U-Boot exists. The user wants to
> > +run some application code, and that as soon as possible after switching
> > +on his device.
> > +
> > +It is therefore essential that U-Boot is as fast as possible,
> > +especially that it loads and boots the operating system as fast as 
> > possible.
> > +
> > +To achieve this, the following design principles shall be followed:
> > +
> > +* Enable caches as soon and whenever possible
> > +
> > +* Initialize devices only when they are needed within U-Boot, i.e. don't
> > +  initialize the Ethernet interface(s) unless U-Boot performs a download 
> > over
> > +  Ethernet; don't  initialize any IDE or USB devices unless U-Boot actually
> > +  tries to load files from these, etc.  (and don't forget to shut down 
> > these
> > +  devices after using them  - otherwise nasty things may happen when you 
> > try to
> > +  boot your OS).
> > +
> > +Also, building of U-Boot shall be as fast as possible.
> > +This makes it easier to run a build for all supported configurations
> > +or at least for all configurations of a specific architecture,
> > +which is essential for quality assurance.
> > +If building is cumbersome and slow, most people will omit
> > +this important step.
> > +
> > +Keep it Simple
> > +^^
> > +
> > +U-Boot is a boot loader, but it is also a tool used for board
> > +bring-up, for production testing, and for other activities
> > +
> > +Keep it Portable
> > +
> > +
> > +U-Boot is a boot loader, but it is also a tool used for board
> > +bring-up, for production testing, and for other activities that are
> > +very closely related to hardware development. So far, it has been
> > +ported to several hundreds of different boards on about 30 different
> > +processor families - please make sure that any code you add can be
> > +used on as many different platforms as possible.
> > +
> > +Avoid assembly language whenever possible - only the reset code with
> > +basic CPU initialization, maybe a static DRAM initialization and the C
> > +stack setup should be in assembly.
> > +All further initializations should be done in C using assembly/C
> > +subroutines or inline macros. These functions represent some
> > +kind of HAL functionality and should be defined consistently on all
> > +architectures. E.g. Basic MMU and cache control, stack pointer 
> > manipulation.
> 
> %s/\. E\.g\./, e.g./
> 
> %s/Basic/basic/

It should probably read "on all architectures, e.g. basic .

Re: [PATCH 5/7] designprinciples.rst: Perform minor cleanups

2022-07-13 Thread Tom Rini
On Wed, Jul 13, 2022 at 07:40:03PM +0200, Heinrich Schuchardt wrote:
> On 7/11/22 19:14, Tom Rini wrote:
> > - Remove some missed wiki markup, and escape a "\n" correctly.
> > - Use gender-neutral language to refer to the user, consistently.
> > 
> > Cc: Claudius Heine 
> > Cc: Heinrich Schuchardt 
> > Signed-off-by: Tom Rini 
> > ---
> > Changes in v2:
> > - None
> > ---
> >   doc/develop/designprinciples.rst | 24 
> >   1 file changed, 12 insertions(+), 12 deletions(-)
> > 
> > diff --git a/doc/develop/designprinciples.rst 
> > b/doc/develop/designprinciples.rst
> > index 43aeb5dacf5f..e5e12dca79f5 100644
> > --- a/doc/develop/designprinciples.rst
> > +++ b/doc/develop/designprinciples.rst
> > @@ -28,15 +28,15 @@ millions...
> > 
> >   A usable and useful configuration of U-Boot, including a basic
> >   interactive command interpreter, support for download over Ethernet
> > -and the capability to program the flash shall fit in no more than 128 !KiB.
> > +and the capability to program the flash shall fit in no more than 128 KiB.
> > 
> >   Keep it Fast
> >   
> > 
> >   The end user is not interested in running U-Boot. In most embedded
> > -systems he is not even aware that U-Boot exists. The user wants to
> > +systems they are not even aware that U-Boot exists. The user wants to
> 
> "The end user" is singular.

First person singular they is normal usage.  Talk to me on IRC if you
want me to dig up one of the essays on the extensive history of first
person singular they :)

> >   run some application code, and that as soon as possible after switching
> > -on his device.
> > +on their device.
> > 
> >   It is therefore essential that U-Boot is as fast as possible,
> >   especially that it loads and boots the operating system as fast as 
> > possible.
> > @@ -63,7 +63,7 @@ Keep it Simple
> >   ^^
> > 
> >   U-Boot is a boot loader, but it is also a tool used for board
> > -bring-up, for production testing, and for other activities
> > +bring-up, for production testing, and for other activities.
> > 
> >   Keep it Portable
> >   
> > @@ -96,13 +96,13 @@ Keep it Configurable
> >   Section "Keep it Small" already explains about the size restrictions
> >   for U-Boot on one side. On the other side, U-Boot is a powerful tool
> >   with many, many extremely useful features. The maintainer or user of
> > -each board will have to decide which features are important to him and
> > -what shall be included with his specific board configuration to meet
> > -his current requirements and restrictions.
> > +each board will have to decide which features are important to them and
> > +what shall be included with their specific board configuration to meet
> > +their current requirements and restrictions.
> > 
> >   Please make sure that it is easy to add or remove features from a
> >   board configuration, so everybody can make the best use of U-Boot on
> > -his system.
> > +their system.
> > 
> >   If a feature is not included, it should not have any residual code
> >   bloating the build.
> > @@ -126,7 +126,7 @@ debug is all the more important to many of us.
> >   * All initialization steps shall print some "begin doing this" message 
> > before
> > they actually start, and some "done" message when they complete. For 
> > example,
> > RAM initialization and size detection may print a "RAM: " before they 
> > start,
> > -  and "256 MB\n" when done.  The purpose of this is that you can always see
> > +  and "256 MB\\n" when done.  The purpose of this is that you can always 
> > see
> 
> %s/MB/MiB/

Plenty of memory related notices, even in the docs, use "MB".  Lets just
put this on the pile to adjust later.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 6/7] process.rst: Perform minor cleanups

2022-07-13 Thread Tom Rini
On Wed, Jul 13, 2022 at 07:43:25PM +0200, Heinrich Schuchardt wrote:
> On 7/11/22 19:14, Tom Rini wrote:
[snip]
> > @@ -155,7 +156,7 @@ like this:
> > 
> >  #. Applies cleanly to the source tree
> > 
> > -   #. passes a ``MAKEALL`` compile test without creating new warnings
> > +   #. Passes :doc:`ci_testing` as this checks for new warnings and other 
> > issues.
> 
> %s/ci/CI/

No?  This is a reference so it renders using the document title.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 7/7] process.rst: Modernize the "Workflow of a Custodian" section

2022-07-13 Thread Tom Rini
On Wed, Jul 13, 2022 at 07:46:28PM +0200, Heinrich Schuchardt wrote:
> On 7/11/22 19:14, Tom Rini wrote:
> > The "Workflow of a Custodian" section on the wiki had not been changed
> > in quite some time to reflect how the process has been functioning for
> > some time.  First, update some links to point to modern and current
> > sources of information.
> > 
> > Second, and more overarching, reword much of the section.  This expands
> > on the expectations of both custodians and developers when it comes to
> > rebasing patches.  Rework the final points to be clearer that Custodians
> > are expected to do their best to test the changes and ask for help when
> > needed, as well as that pull requests are expected in a timely manner.
> > 
> > Cc: Claudius Heine 
> > Cc: Martin Bonner 
> > Cc: Heinrich Schuchardt 
> > Signed-off-by: Tom Rini 
> > ---
> > Changes in v2:
> > - New patch
[snip]
> > -#. Once tests are passed, some agreed time limit expires, the custodian
> > -   requests that the changes in their public git repository be merged into 
> > the
> > -   main tree. If necessary, the custodian may have to adapt their changes 
> > to
> > -   allow for a clean merge.
> > -   Todo: define a reasonable time limit. 3 weeks?
> > +#. Custodians are expected to submit a timely pull request of their git
> > +   repository to the main repository.  It is strongly encouraged that a CI 
> > run
> > +   have been complete prior to submission, but not required.
> 
> A run is singular.

Oops, thanks.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v6 3/7] tpm: Add the RNG child device

2022-07-13 Thread Tom Rini
On Wed, Jul 13, 2022 at 09:28:16AM -0600, Simon Glass wrote:
> Hi Rob,
> 
> On Tue, 12 Jul 2022 at 08:11, Rob Herring  wrote:
> >
> > On Tue, Jul 12, 2022 at 5:04 AM Simon Glass  wrote:
> > >
> > > Hi Ilias,
> > >
> > > On Fri, 8 Jul 2022 at 02:24, Ilias Apalodimas
> > >  wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > [...]
> > > >
> > > > > > +
> > > > > >  UCLASS_DRIVER(tpm) = {
> > > > > > -   .id = UCLASS_TPM,
> > > > > > -   .name   = "tpm",
> > > > > > -   .flags  = DM_UC_FLAG_SEQ_ALIAS,
> > > > > > +   .id = UCLASS_TPM,
> > > > > > +   .name   = "tpm",
> > > > > > +   .flags  = DM_UC_FLAG_SEQ_ALIAS,
> > > > > >  #if CONFIG_IS_ENABLED(OF_REAL)
> > > > > > -   .post_bind  = dm_scan_fdt_dev,
> > > > > > +   .post_bind  = dm_scan_fdt_dev,
> > > > > >  #endif
> > > > > > +   .post_probe = tpm_uclass_post_probe,
> > > > > > .per_device_auto= sizeof(struct tpm_chip_priv),
> > > > > >  };
> > > > > > --
> > > > > > 2.25.1
> > > > > >
> > > > >
> > > > > The driver needs a compatible string so it can be in the device tree.
> > > >
> > > > Why?  I've tried to hint this on the previous iteration of the patch.
> > > > The RNG here is not a *device*.  The TPM is the device and you are
> > > > guaranteed to have an RNG.  The way to get a random number is send a
> > > > special command to the TPM. So all that we should do here is leverage
> > > > the fact that the TPM is already in the device tree.
> > > >
> > > > And fwiw we should stick to try to stick to what the DT spec defines
> > > > as much as possible.  I personally don't see this as a special usecase
> > > > were deviating from the spec is justified.
> > >
> > > This is not a deviation from a spec. What spec? Also, I don't want to
> > > get into another discussion about what a device is. We can disagree on
> > > that if you like.
> > >
> > > One reason is that U-Boot generally requires compatible strings, e.g.
> > > with of-platdata. But also we can refer to the rand device from
> > > elsewhere in the tree. I know that Linux does lots of ad-hoc device
> > > creation and doesn't really have the concept of a uclass consistently
> > > applied, but this is U-Boot.
> >
> > You are letting client/OS details define your binding. Doing so
> > doesn't result in OS agnostic bindings. Sure, it would be nice if DT
> > nodes and drivers were always a nice clean 1:1 ratio, but h/w is messy
> > sometimes and DT is not an abstraction layer. The general guidance on
> > whether there are child nodes for sub-blocks is do they have their own
> > resources in DT or are the sub-blocks reusable on multiple devices.
> > Neither of those are the case here.
> >
> > Besides, we already have TPM device bindings defined. Requiring
> > binding changes when adding a new client/OS feature is not good
> > practice either.
> 
> I'm not sure what to do with this, but in general the practice of
> implied subnodes is not friendly to U-Boot. Yet it seems like a common
> feature of the bindings at present, for example GPIOs.
> 
> The device tree is how U-Boot determines which random-number generator
> to use for a particular function. For example, for VBE, if we need to
> generate some random numbers we'd like to specify which device creates
> them. It can't just be 'use the TPM if you find one'. I'm not sure how
> that works in Linux?

Why can't it be "use the TPM if you find one" since a TPM is a superset
of an RNG?

-- 
Tom


signature.asc
Description: PGP signature


Re: PRAM and reserved memory for Linux

2022-07-13 Thread Tom Rini
On Wed, Jul 13, 2022 at 04:13:27PM +, Joakim Tjernlund wrote:
> On Wed, 2022-07-13 at 10:21 -0400, Tom Rini wrote:
> > On Wed, Jul 13, 2022 at 10:08:38AM +, Joakim Tjernlund wrote:
> > 
> > > I added CONFIG_PRAM 4 and a reserved-memory DTS node for the same space 
> > > but
> > > now u-boot complains when booting:
> > >   ERROR: reserving fdt memory region failed (addr=703ff000 size=1000)
> > > The error is caused by arch_lmb_reserve() in arm which seem
> > > to reserve command line and board info ? 
> > > 
> > > If I remove the reserved-memory DTS node I don't get a reserved area in 
> > > Linux,
> > > don't quite understand how PRAM is supposed to work?
> > 
> > The first likely problem is that CONFIG_PRAM stuff isn't often used
> > these days so might be glitchy / buggy, as you've found here.  Next, I
> > bet that area in arch_lmb_reserve() is about ATAGS/related and should be
> > guarded with CONFIG_SUPPORT_PASSING_ATAGS.
> > 
> 
> The  arch_lmb_reserve() comment reads(lots of archs has similar code):
>   /*
>* Booting a (Linux) kernel image
>*
>* Allocate space for command line and board info - the
>* address should be as high as possible within the reach of
>* the kernel (see CONFIG_SYS_BOOTMAPSZ settings), but in unused
>* memory, which means far enough below the current stack
>* pointer.
> 
> You still think this cmdline/board info is just for the old ATAGS ?
> I have an older boot and it des not have CONFIG_SUPPORT_PASSING_ATAGS but
> CMDLINE_TAG etc. is here though.

Yes it is, and SUPPORT_PASSING_ATAGS is somewhat new in that I added it
when converting CMDLINE_TAG, etc, to Kconfig and making it be easier to
say "this platform is new enough to never ever need this".

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] sunxi: configs: streamline include/configs/sun*.h wrappers

2022-07-13 Thread Tom Rini
On Wed, Jul 13, 2022 at 04:58:57PM +0100, Andre Przywara wrote:
> For mostly historic reasons we had configuration headers for each
> Allwinner CPU "family". These days they are mostly just including one
> common header, with the rest being somewhat empty.
> There were attempts to remove them, and to just use the one common header
> to begin with, but this has implications to the build system, which me
> might not be ready for, yet.
> 
> To document this behaviour, and to avoid something sneaking in over
> time, make those files all the same (minus the CPU family name and
> the copyrights), and add a comment explaining that.
> This makes it easier to just remove those files later on, when needed
> and possible.
> 
> Signed-off-by: Andre Przywara 
>
> ---
> Hi Tom,
> 
> this is mostly to just confirm and document what we already established
> earlier: that those files are redundant, and are just needed to match
> CONFIG_SYS_CONFIG_NAME. In case we don't need or want that anymore, we
> can just remove them, without needing to think too hard about it.

Right, we need this for CONFIG_SYS_CONFIG_NAME and in turn being able to
break up the build for Azure, and manual build testing still.

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


  1   2   >