* [PATCH 0/9] stm32mp1 devicetre-tree and board update
@ 2020-01-28 9:10 Patrick Delaunay
2020-01-28 9:10 ` [PATCH 1/9] ARM: dts: stm32mp1: DT alignment with kernel v5.4 Patrick Delaunay
` (8 more replies)
0 siblings, 9 replies; 38+ messages in thread
From: Patrick Delaunay @ 2020-01-28 9:10 UTC (permalink / raw)
To: u-boot
This serie provides the device tree resync with Kernel 5.4-rc5,
solves some dtc compilation issue for U-Boot addon
and some minor update in stm32mp1 board (documentation and
support of revZ).
Antonio Borneo (1):
ARM: dts: stm32mp1: move FDCAN to PLL4_R
Patrick Delaunay (8):
ARM: dts: stm32mp1: DT alignment with kernel v5.4
stm32mp1: pwr: use the last binding for pwr
ARM: dts: stm32mp1: DT alignment with kernel v5.5-rc7
ARM: dts: stm32mp1: correct ddr node
ARM: dts: stm32m1: add reg for pll nodes
board: stm32mp1: update readme
doc: add board documentation for stm32mp1
stm32mp1: support of STM32MP15x Rev.Z
arch/arm/dts/stm32mp15-ddr.dtsi | 2 +-
arch/arm/dts/stm32mp157-pinctrl.dtsi | 31 +-
arch/arm/dts/stm32mp157-u-boot.dtsi | 4 +-
.../arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 10 +-
arch/arm/dts/stm32mp157a-avenger96.dts | 11 +-
arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 27 +-
arch/arm/dts/stm32mp157a-dk1.dts | 73 ++-
arch/arm/dts/stm32mp157c-dk2.dts | 13 +
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 10 +-
arch/arm/dts/stm32mp157c-ed1.dts | 28 +-
arch/arm/dts/stm32mp157c-ev1.dts | 8 +-
arch/arm/dts/stm32mp157c.dtsi | 48 +-
arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 10 +-
arch/arm/dts/stm32mp15xx-dhcom.dtsi | 8 +-
arch/arm/mach-stm32mp/cpu.c | 3 +
arch/arm/mach-stm32mp/include/mach/stm32.h | 1 -
.../arm/mach-stm32mp/include/mach/sys_proto.h | 1 +
arch/arm/mach-stm32mp/pwr_regulator.c | 23 +-
arch/arm/mach-stm32mp/syscon.c | 1 -
board/st/stm32mp1/README | 504 +--------------
doc/board/index.rst | 1 +
doc/board/st/index.rst | 9 +
doc/board/st/stm32mp1.rst | 598 ++++++++++++++++++
.../clock/st,stm32mp1.txt | 32 +-
.../mtd/stm32-fmc2-nand.txt | 6 +-
25 files changed, 845 insertions(+), 617 deletions(-)
create mode 100644 doc/board/st/index.rst
create mode 100644 doc/board/st/stm32mp1.rst
--
2.17.1
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 1/9] ARM: dts: stm32mp1: DT alignment with kernel v5.4
2020-01-28 9:10 [PATCH 0/9] stm32mp1 devicetre-tree and board update Patrick Delaunay
@ 2020-01-28 9:10 ` Patrick Delaunay
2020-02-13 8:11 ` [Uboot-stm32] " Patrice CHOTARD
2020-02-14 10:25 ` Patrick DELAUNAY
2020-01-28 9:10 ` [PATCH 2/9] stm32mp1: pwr: use the last binding for pwr Patrick Delaunay
` (7 subsequent siblings)
8 siblings, 2 replies; 38+ messages in thread
From: Patrick Delaunay @ 2020-01-28 9:10 UTC (permalink / raw)
To: u-boot
Device tree and binding alignment with kernel v5.4
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
---
arch/arm/dts/stm32mp157-pinctrl.dtsi | 8 ++++----
arch/arm/dts/stm32mp157c-ev1.dts | 5 ++---
arch/arm/dts/stm32mp157c.dtsi | 4 ++--
doc/device-tree-bindings/mtd/stm32-fmc2-nand.txt | 6 ++++--
4 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/arch/arm/dts/stm32mp157-pinctrl.dtsi b/arch/arm/dts/stm32mp157-pinctrl.dtsi
index 0d53396119..07cd0809ff 100644
--- a/arch/arm/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp157-pinctrl.dtsi
@@ -622,13 +622,13 @@
<STM32_PINMUX('F', 6, AF9)>; /* QSPI_BK1_IO3 */
bias-disable;
drive-push-pull;
- slew-rate = <3>;
+ slew-rate = <1>;
};
pins2 {
pinmux = <STM32_PINMUX('B', 6, AF10)>; /* QSPI_BK1_NCS */
bias-pull-up;
drive-push-pull;
- slew-rate = <3>;
+ slew-rate = <1>;
};
};
@@ -650,13 +650,13 @@
<STM32_PINMUX('G', 7, AF11)>; /* QSPI_BK2_IO3 */
bias-disable;
drive-push-pull;
- slew-rate = <3>;
+ slew-rate = <1>;
};
pins2 {
pinmux = <STM32_PINMUX('C', 0, AF10)>; /* QSPI_BK2_NCS */
bias-pull-up;
drive-push-pull;
- slew-rate = <3>;
+ slew-rate = <1>;
};
};
diff --git a/arch/arm/dts/stm32mp157c-ev1.dts b/arch/arm/dts/stm32mp157c-ev1.dts
index 89d29b50c3..aa5892b156 100644
--- a/arch/arm/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/dts/stm32mp157c-ev1.dts
@@ -189,8 +189,8 @@
clocks = <&clk_ext_camera>;
clock-names = "xclk";
DOVDD-supply = <&v2v8>;
- powerdown-gpios = <&stmfx_pinctrl 18 GPIO_ACTIVE_HIGH>;
- reset-gpios = <&stmfx_pinctrl 19 GPIO_ACTIVE_LOW>;
+ powerdown-gpios = <&stmfx_pinctrl 18 (GPIO_ACTIVE_HIGH | GPIO_PUSH_PULL)>;
+ reset-gpios = <&stmfx_pinctrl 19 (GPIO_ACTIVE_LOW | GPIO_PUSH_PULL)>;
rotation = <180>;
status = "okay";
@@ -223,7 +223,6 @@
joystick_pins: joystick {
pins = "gpio0", "gpio1", "gpio2", "gpio3", "gpio4";
- drive-push-pull;
bias-pull-down;
};
diff --git a/arch/arm/dts/stm32mp157c.dtsi b/arch/arm/dts/stm32mp157c.dtsi
index 41aea75213..28a7e4c08a 100644
--- a/arch/arm/dts/stm32mp157c.dtsi
+++ b/arch/arm/dts/stm32mp157c.dtsi
@@ -939,7 +939,7 @@
interrupt-names = "int0", "int1";
clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
clock-names = "hclk", "cclk";
- bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;
+ bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
status = "disabled";
};
@@ -952,7 +952,7 @@
interrupt-names = "int0", "int1";
clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
clock-names = "hclk", "cclk";
- bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
+ bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;
status = "disabled";
};
diff --git a/doc/device-tree-bindings/mtd/stm32-fmc2-nand.txt b/doc/device-tree-bindings/mtd/stm32-fmc2-nand.txt
index 70e76be2a3..ad2bef8265 100644
--- a/doc/device-tree-bindings/mtd/stm32-fmc2-nand.txt
+++ b/doc/device-tree-bindings/mtd/stm32-fmc2-nand.txt
@@ -18,8 +18,10 @@ Optional properties:
- dmas: DMA specifiers (see: dma/stm32-mdma.txt)
- dma-names: Must be "tx", "rx" and "ecc"
-Optional children nodes:
-Children nodes represent the available NAND chips.
+* NAND device bindings:
+
+Required properties:
+- reg: describes the CS lines assigned to the NAND device.
Optional properties:
- nand-on-flash-bbt: see nand.txt
--
2.17.1
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [PATCH 2/9] stm32mp1: pwr: use the last binding for pwr
2020-01-28 9:10 [PATCH 0/9] stm32mp1 devicetre-tree and board update Patrick Delaunay
2020-01-28 9:10 ` [PATCH 1/9] ARM: dts: stm32mp1: DT alignment with kernel v5.4 Patrick Delaunay
@ 2020-01-28 9:10 ` Patrick Delaunay
2020-02-13 8:16 ` Patrice CHOTARD
2020-02-14 10:25 ` Patrick DELAUNAY
2020-01-28 9:11 ` [PATCH 3/9] ARM: dts: stm32mp1: DT alignment with kernel v5.5-rc7 Patrick Delaunay
` (6 subsequent siblings)
8 siblings, 2 replies; 38+ messages in thread
From: Patrick Delaunay @ 2020-01-28 9:10 UTC (permalink / raw)
To: u-boot
Update the driver to use the latest binding from kernel v5.5-rc1:
no more use syscon or regmap to access to pwr register and
only one pwr_regulators node with the compatibility "st,stm32mp1,pwr-reg"
is available.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
---
arch/arm/dts/stm32mp157-u-boot.dtsi | 2 +-
arch/arm/dts/stm32mp157a-avenger96.dts | 8 ++--
arch/arm/dts/stm32mp157a-dk1.dts | 8 ++--
arch/arm/dts/stm32mp157c-ed1.dts | 8 ++--
arch/arm/dts/stm32mp157c.dtsi | 46 +++++++++-------------
arch/arm/dts/stm32mp15xx-dhcom.dtsi | 8 ++--
arch/arm/mach-stm32mp/include/mach/stm32.h | 1 -
arch/arm/mach-stm32mp/pwr_regulator.c | 23 ++++++-----
arch/arm/mach-stm32mp/syscon.c | 1 -
9 files changed, 42 insertions(+), 63 deletions(-)
diff --git a/arch/arm/dts/stm32mp157-u-boot.dtsi b/arch/arm/dts/stm32mp157-u-boot.dtsi
index 0d1d387e54..cb8d60e33d 100644
--- a/arch/arm/dts/stm32mp157-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157-u-boot.dtsi
@@ -128,7 +128,7 @@
u-boot,dm-pre-reloc;
};
-&pwr {
+&pwr_regulators {
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts b/arch/arm/dts/stm32mp157a-avenger96.dts
index 5b15a4a915..232fe70905 100644
--- a/arch/arm/dts/stm32mp157a-avenger96.dts
+++ b/arch/arm/dts/stm32mp157a-avenger96.dts
@@ -282,11 +282,9 @@
status = "okay";
};
-&pwr {
- pwr-regulators {
- vdd-supply = <&vdd>;
- vdd_3v3_usbfs-supply = <&vdd_usb>;
- };
+&pwr_regulators {
+ vdd-supply = <&vdd>;
+ vdd_3v3_usbfs-supply = <&vdd_usb>;
};
&rng1 {
diff --git a/arch/arm/dts/stm32mp157a-dk1.dts b/arch/arm/dts/stm32mp157a-dk1.dts
index 4652253012..dc61bfc3d5 100644
--- a/arch/arm/dts/stm32mp157a-dk1.dts
+++ b/arch/arm/dts/stm32mp157a-dk1.dts
@@ -397,11 +397,9 @@
status = "okay";
};
-&pwr {
- pwr-regulators {
- vdd-supply = <&vdd>;
- vdd_3v3_usbfs-supply = <&vdd_usb>;
- };
+&pwr_regulators {
+ vdd-supply = <&vdd>;
+ vdd_3v3_usbfs-supply = <&vdd_usb>;
};
&rng1 {
diff --git a/arch/arm/dts/stm32mp157c-ed1.dts b/arch/arm/dts/stm32mp157c-ed1.dts
index bc4d7e1ab5..acb59f24cc 100644
--- a/arch/arm/dts/stm32mp157c-ed1.dts
+++ b/arch/arm/dts/stm32mp157c-ed1.dts
@@ -263,11 +263,9 @@
status = "okay";
};
-&pwr {
- pwr-regulators {
- vdd-supply = <&vdd>;
- vdd_3v3_usbfs-supply = <&vdd_usb>;
- };
+&pwr_regulators {
+ vdd-supply = <&vdd>;
+ vdd_3v3_usbfs-supply = <&vdd_usb>;
};
&rng1 {
diff --git a/arch/arm/dts/stm32mp157c.dtsi b/arch/arm/dts/stm32mp157c.dtsi
index 28a7e4c08a..22a9386248 100644
--- a/arch/arm/dts/stm32mp157c.dtsi
+++ b/arch/arm/dts/stm32mp157c.dtsi
@@ -1110,36 +1110,26 @@
#reset-cells = <1>;
};
- pwr: pwr at 50001000 {
- compatible = "st,stm32mp1-pwr", "st,stm32-pwr", "syscon", "simple-mfd";
- reg = <0x50001000 0x400>;
- system-power-controller;
- interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
- st,sysrcc = <&rcc>;
- clocks = <&rcc PLL2_R>;
- clock-names = "phyclk";
-
- pwr-regulators {
- compatible = "st,stm32mp1,pwr-reg";
- st,tzcr = <&rcc 0x0 0x1>;
-
- reg11: reg11 {
- regulator-name = "reg11";
- regulator-min-microvolt = <1100000>;
- regulator-max-microvolt = <1100000>;
- };
+ pwr_regulators: pwr at 50001000 {
+ compatible = "st,stm32mp1,pwr-reg";
+ reg = <0x50001000 0x10>;
+
+ reg11: reg11 {
+ regulator-name = "reg11";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ };
- reg18: reg18 {
- regulator-name = "reg18";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
+ reg18: reg18 {
+ regulator-name = "reg18";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
- usb33: usb33 {
- regulator-name = "usb33";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
+ usb33: usb33 {
+ regulator-name = "usb33";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
};
};
diff --git a/arch/arm/dts/stm32mp15xx-dhcom.dtsi b/arch/arm/dts/stm32mp15xx-dhcom.dtsi
index 96661ae783..bed69c97b6 100644
--- a/arch/arm/dts/stm32mp15xx-dhcom.dtsi
+++ b/arch/arm/dts/stm32mp15xx-dhcom.dtsi
@@ -217,11 +217,9 @@
status = "okay";
};
-&pwr {
- pwr-regulators {
- vdd-supply = <&vdd>;
- vdd_3v3_usbfs-supply = <&vdd_usb>;
- };
+&pwr_regulators {
+ vdd-supply = <&vdd>;
+ vdd_3v3_usbfs-supply = <&vdd_usb>;
};
&qspi {
diff --git a/arch/arm/mach-stm32mp/include/mach/stm32.h b/arch/arm/mach-stm32mp/include/mach/stm32.h
index 88126b8cdb..f0636005e5 100644
--- a/arch/arm/mach-stm32mp/include/mach/stm32.h
+++ b/arch/arm/mach-stm32mp/include/mach/stm32.h
@@ -37,7 +37,6 @@
/* enumerated used to identify the SYSCON driver instance */
enum {
STM32MP_SYSCON_UNKNOWN,
- STM32MP_SYSCON_PWR,
STM32MP_SYSCON_SYSCFG,
};
diff --git a/arch/arm/mach-stm32mp/pwr_regulator.c b/arch/arm/mach-stm32mp/pwr_regulator.c
index 9484645dbd..f00e7527c2 100644
--- a/arch/arm/mach-stm32mp/pwr_regulator.c
+++ b/arch/arm/mach-stm32mp/pwr_regulator.c
@@ -6,8 +6,8 @@
#include <common.h>
#include <dm.h>
#include <errno.h>
-#include <regmap.h>
#include <syscon.h>
+#include <asm/io.h>
#include <power/pmic.h>
#include <power/regulator.h>
@@ -26,7 +26,7 @@ struct stm32mp_pwr_reg_info {
};
struct stm32mp_pwr_priv {
- struct regmap *regmap;
+ fdt_addr_t base;
};
static int stm32mp_pwr_write(struct udevice *dev, uint reg,
@@ -38,7 +38,9 @@ static int stm32mp_pwr_write(struct udevice *dev, uint reg,
if (len != 4)
return -EINVAL;
- return regmap_write(priv->regmap, STM32MP_PWR_CR3, val);
+ writel(val, priv->base + STM32MP_PWR_CR3);
+
+ return 0;
}
static int stm32mp_pwr_read(struct udevice *dev, uint reg, uint8_t *buff,
@@ -49,21 +51,18 @@ static int stm32mp_pwr_read(struct udevice *dev, uint reg, uint8_t *buff,
if (len != 4)
return -EINVAL;
- return regmap_read(priv->regmap, STM32MP_PWR_CR3, (u32 *)buff);
+ *(u32 *)buff = readl(priv->base + STM32MP_PWR_CR3);
+
+ return 0;
}
static int stm32mp_pwr_ofdata_to_platdata(struct udevice *dev)
{
struct stm32mp_pwr_priv *priv = dev_get_priv(dev);
- struct regmap *regmap;
- regmap = syscon_get_regmap_by_driver_data(STM32MP_SYSCON_PWR);
- if (IS_ERR(regmap)) {
- pr_err("%s: unable to find regmap (%ld)\n", __func__,
- PTR_ERR(regmap));
- return PTR_ERR(regmap);
- }
- priv->regmap = regmap;
+ priv->base = dev_read_addr(dev);
+ if (priv->base == FDT_ADDR_T_NONE)
+ return -EINVAL;
return 0;
}
diff --git a/arch/arm/mach-stm32mp/syscon.c b/arch/arm/mach-stm32mp/syscon.c
index 6070837bf0..3e61ce4097 100644
--- a/arch/arm/mach-stm32mp/syscon.c
+++ b/arch/arm/mach-stm32mp/syscon.c
@@ -9,7 +9,6 @@
#include <asm/arch/stm32.h>
static const struct udevice_id stm32mp_syscon_ids[] = {
- { .compatible = "st,stm32mp1-pwr", .data = STM32MP_SYSCON_PWR },
{ .compatible = "st,stm32mp157-syscfg",
.data = STM32MP_SYSCON_SYSCFG },
{ }
--
2.17.1
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [PATCH 3/9] ARM: dts: stm32mp1: DT alignment with kernel v5.5-rc7
2020-01-28 9:10 [PATCH 0/9] stm32mp1 devicetre-tree and board update Patrick Delaunay
2020-01-28 9:10 ` [PATCH 1/9] ARM: dts: stm32mp1: DT alignment with kernel v5.4 Patrick Delaunay
2020-01-28 9:10 ` [PATCH 2/9] stm32mp1: pwr: use the last binding for pwr Patrick Delaunay
@ 2020-01-28 9:11 ` Patrick Delaunay
2020-02-13 8:12 ` [Uboot-stm32] " Patrice CHOTARD
2020-02-14 10:26 ` Patrick DELAUNAY
2020-01-28 9:11 ` [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R Patrick Delaunay
` (5 subsequent siblings)
8 siblings, 2 replies; 38+ messages in thread
From: Patrick Delaunay @ 2020-01-28 9:11 UTC (permalink / raw)
To: u-boot
Device tree and binding alignment with kernel v5.5-rc7
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
---
arch/arm/dts/stm32mp157-pinctrl.dtsi | 23 ++++++++-
arch/arm/dts/stm32mp157a-avenger96.dts | 3 +-
arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 17 -------
arch/arm/dts/stm32mp157a-dk1.dts | 65 +++++++++++++++++++++---
arch/arm/dts/stm32mp157c-dk2.dts | 13 +++++
arch/arm/dts/stm32mp157c-ed1.dts | 20 ++++++--
arch/arm/dts/stm32mp157c-ev1.dts | 3 --
7 files changed, 112 insertions(+), 32 deletions(-)
diff --git a/arch/arm/dts/stm32mp157-pinctrl.dtsi b/arch/arm/dts/stm32mp157-pinctrl.dtsi
index 07cd0809ff..81a363d93d 100644
--- a/arch/arm/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp157-pinctrl.dtsi
@@ -138,7 +138,16 @@
status = "disabled";
};
- adc12_usb_pwr_pins_a: adc12-usb-pwr-pins-0 {
+ adc12_ain_pins_a: adc12-ain-0 {
+ pins {
+ pinmux = <STM32_PINMUX('C', 3, ANALOG)>, /* ADC1 in13 */
+ <STM32_PINMUX('F', 12, ANALOG)>, /* ADC1 in6 */
+ <STM32_PINMUX('F', 13, ANALOG)>, /* ADC2 in2 */
+ <STM32_PINMUX('F', 14, ANALOG)>; /* ADC2 in6 */
+ };
+ };
+
+ adc12_usb_cc_pins_a: adc12-usb-cc-pins-0 {
pins {
pinmux = <STM32_PINMUX('A', 4, ANALOG)>, /* ADC12 in18 */
<STM32_PINMUX('A', 5, ANALOG)>; /* ADC12 in19 */
@@ -175,6 +184,18 @@
};
};
+ dac_ch1_pins_a: dac-ch1 {
+ pins {
+ pinmux = <STM32_PINMUX('A', 4, ANALOG)>;
+ };
+ };
+
+ dac_ch2_pins_a: dac-ch2 {
+ pins {
+ pinmux = <STM32_PINMUX('A', 5, ANALOG)>;
+ };
+ };
+
dcmi_pins_a: dcmi-0 {
pins {
pinmux = <STM32_PINMUX('H', 8, AF13)>,/* DCMI_HSYNC */
diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts b/arch/arm/dts/stm32mp157a-avenger96.dts
index 232fe70905..3065593bf2 100644
--- a/arch/arm/dts/stm32mp157a-avenger96.dts
+++ b/arch/arm/dts/stm32mp157a-avenger96.dts
@@ -252,14 +252,13 @@
regulator-name = "vbus_otg";
interrupts = <IT_OCP_OTG 0>;
interrupt-parent = <&pmic>;
- regulator-active-discharge;
};
vbus_sw: pwr_sw2 {
regulator-name = "vbus_sw";
interrupts = <IT_OCP_SWOUT 0>;
interrupt-parent = <&pmic>;
- regulator-active-discharge;
+ regulator-active-discharge = <1>;
};
};
diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
index dcaab3eef2..4045a6e731 100644
--- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
@@ -35,24 +35,7 @@
};
&adc {
- pinctrl-names = "default";
- pinctrl-0 = <&adc12_usb_pwr_pins_a>;
- vdd-supply = <&vdd>;
- vdda-supply = <&vdd>;
- vref-supply = <&vrefbuf>;
status = "okay";
- adc1: adc at 0 {
- /*
- * Type-C USB_PWR_CC1 & USB_PWR_CC2 on in18 & in19.
- * Use at least 5 * RC time, e.g. 5 * (Rp + Rd) * C:
- * 5 * (56 + 47kOhms) * 5pF => 2.5us.
- * Use arbitrary margin here (e.g. 5µs).
- */
- st,min-sample-time-nsecs = <5000>;
- /* ANA0, ANA1, USB Type-C CC1 & CC2 */
- st,adc-channels = <0 1 18 19>;
- status = "okay";
- };
};
&clk_hse {
diff --git a/arch/arm/dts/stm32mp157a-dk1.dts b/arch/arm/dts/stm32mp157a-dk1.dts
index dc61bfc3d5..624bf6954b 100644
--- a/arch/arm/dts/stm32mp157a-dk1.dts
+++ b/arch/arm/dts/stm32mp157a-dk1.dts
@@ -25,6 +25,7 @@
};
memory at c0000000 {
+ device_type = "memory";
reg = <0xc0000000 0x20000000>;
};
@@ -92,7 +93,34 @@
"Playback" , "MCLK",
"Capture" , "MCLK",
"MICL" , "Mic Bias";
- dais = <&sai2a_port &sai2b_port>;
+ dais = <&sai2a_port &sai2b_port &i2s2_port>;
+ status = "okay";
+ };
+};
+
+&adc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&adc12_ain_pins_a>, <&adc12_usb_cc_pins_a>;
+ vdd-supply = <&vdd>;
+ vdda-supply = <&vdd>;
+ vref-supply = <&vrefbuf>;
+ status = "disabled";
+ adc1: adc at 0 {
+ /*
+ * Type-C USB_PWR_CC1 & USB_PWR_CC2 on in18 & in19.
+ * Use at least 5 * RC time, e.g. 5 * (Rp + Rd) * C:
+ * 5 * (56 + 47kOhms) * 5pF => 2.5us.
+ * Use arbitrary margin here (e.g. 5us).
+ */
+ st,min-sample-time-nsecs = <5000>;
+ /* AIN connector, USB Type-C CC1 & CC2 */
+ st,adc-channels = <0 1 6 13 18 19>;
+ status = "okay";
+ };
+ adc2: adc at 100 {
+ /* AIN connector, USB Type-C CC1 & CC2 */
+ st,adc-channels = <0 1 2 6 18 19>;
+ st,min-sample-time-nsecs = <5000>;
status = "okay";
};
};
@@ -146,9 +174,7 @@
reset-gpios = <&gpioa 10 GPIO_ACTIVE_LOW>;
interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
interrupt-parent = <&gpiog>;
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <<dc_pins_a>;
- pinctrl-1 = <<dc_pins_sleep_a>;
+ #sound-dai-cells = <0>;
status = "okay";
ports {
@@ -161,6 +187,13 @@
remote-endpoint = <<dc_ep0_out>;
};
};
+
+ port at 3 {
+ reg = <3>;
+ sii9022_tx_endpoint: endpoint {
+ remote-endpoint = <&i2s2_endpoint>;
+ };
+ };
};
};
@@ -244,7 +277,7 @@
vddcore: buck1 {
regulator-name = "vddcore";
- regulator-min-microvolt = <800000>;
+ regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1350000>;
regulator-always-on;
regulator-initial-mode = <0>;
@@ -345,7 +378,7 @@
vbus_sw: pwr_sw2 {
regulator-name = "vbus_sw";
interrupts = <IT_OCP_SWOUT 0>;
- regulator-active-discharge;
+ regulator-active-discharge = <1>;
};
};
@@ -364,6 +397,23 @@
};
};
+&i2s2 {
+ clocks = <&rcc SPI2>, <&rcc SPI2_K>, <&rcc PLL3_Q>, <&rcc PLL3_R>;
+ clock-names = "pclk", "i2sclk", "x8k", "x11k";
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&i2s2_pins_a>;
+ pinctrl-1 = <&i2s2_pins_sleep_a>;
+ status = "okay";
+
+ i2s2_port: port {
+ i2s2_endpoint: endpoint {
+ remote-endpoint = <&sii9022_tx_endpoint>;
+ format = "i2s";
+ mclk-fs = <256>;
+ };
+ };
+};
+
&ipcc {
status = "okay";
};
@@ -374,6 +424,9 @@
};
<dc {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <<dc_pins_a>;
+ pinctrl-1 = <<dc_pins_sleep_a>;
status = "okay";
port {
diff --git a/arch/arm/dts/stm32mp157c-dk2.dts b/arch/arm/dts/stm32mp157c-dk2.dts
index 020ea0f0e2..d26adcbeba 100644
--- a/arch/arm/dts/stm32mp157c-dk2.dts
+++ b/arch/arm/dts/stm32mp157c-dk2.dts
@@ -53,6 +53,19 @@
};
};
+&i2c1 {
+ touchscreen at 38 {
+ compatible = "focaltech,ft6236";
+ reg = <0x38>;
+ interrupts = <2 2>;
+ interrupt-parent = <&gpiof>;
+ interrupt-controller;
+ touchscreen-size-x = <480>;
+ touchscreen-size-y = <800>;
+ status = "okay";
+ };
+};
+
<dc {
status = "okay";
diff --git a/arch/arm/dts/stm32mp157c-ed1.dts b/arch/arm/dts/stm32mp157c-ed1.dts
index acb59f24cc..ae4da39ce8 100644
--- a/arch/arm/dts/stm32mp157c-ed1.dts
+++ b/arch/arm/dts/stm32mp157c-ed1.dts
@@ -84,7 +84,21 @@
gpios = <&gpiof 14 GPIO_ACTIVE_HIGH>;
gpios-states = <0>;
- states = <1800000 0x1 2900000 0x0>;
+ states = <1800000 0x1>,
+ <2900000 0x0>;
+ };
+};
+
+&dac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&dac_ch1_pins_a &dac_ch2_pins_a>;
+ vref-supply = <&vdda>;
+ status = "disabled";
+ dac1: dac at 1 {
+ status = "okay";
+ };
+ dac2: dac at 2 {
+ status = "okay";
};
};
@@ -127,7 +141,7 @@
vddcore: buck1 {
regulator-name = "vddcore";
- regulator-min-microvolt = <800000>;
+ regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1350000>;
regulator-always-on;
regulator-initial-mode = <0>;
@@ -225,7 +239,7 @@
vbus_sw: pwr_sw2 {
regulator-name = "vbus_sw";
interrupts = <IT_OCP_SWOUT 0>;
- regulator-active-discharge;
+ regulator-active-discharge = <1>;
};
};
diff --git a/arch/arm/dts/stm32mp157c-ev1.dts b/arch/arm/dts/stm32mp157c-ev1.dts
index aa5892b156..bd8ffc185f 100644
--- a/arch/arm/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/dts/stm32mp157c-ev1.dts
@@ -32,7 +32,6 @@
joystick {
compatible = "gpio-keys";
- #size-cells = <0>;
pinctrl-0 = <&joystick_pins>;
pinctrl-names = "default";
button-0 {
@@ -343,14 +342,12 @@
&usbh_ehci {
phys = <&usbphyc_port0>;
- phy-names = "usb";
status = "okay";
};
&usbotg_hs {
dr_mode = "peripheral";
phys = <&usbphyc_port1 0>;
- phy-names = "usb2-phy";
status = "okay";
};
--
2.17.1
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R
2020-01-28 9:10 [PATCH 0/9] stm32mp1 devicetre-tree and board update Patrick Delaunay
` (2 preceding siblings ...)
2020-01-28 9:11 ` [PATCH 3/9] ARM: dts: stm32mp1: DT alignment with kernel v5.5-rc7 Patrick Delaunay
@ 2020-01-28 9:11 ` Patrick Delaunay
2020-01-28 12:15 ` Marek Vasut
` (2 more replies)
2020-01-28 9:11 ` [PATCH 5/9] ARM: dts: stm32mp1: correct ddr node Patrick Delaunay
` (4 subsequent siblings)
8 siblings, 3 replies; 38+ messages in thread
From: Patrick Delaunay @ 2020-01-28 9:11 UTC (permalink / raw)
To: u-boot
From: Antonio Borneo <antonio.borneo@st.com>
LTDC modifies the clock frequency to adapt it to the display. Such
frequency change is not detected by the FDCAN driver that instead
cache the value at probe and pretend to use it later.
Keep the LTDC alone on PLL4_Q by moving the FDCAN to PLL4_R.
Signed-off-by: Antonio Borneo <antonio.borneo@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
---
arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 2 +-
arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 2 +-
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 2 +-
arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
index 1104a70a65..d8a4617d90 100644
--- a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
@@ -91,7 +91,7 @@
CLK_UART6_HSI
CLK_UART78_HSI
CLK_SPDIF_PLL4P
- CLK_FDCAN_PLL4Q
+ CLK_FDCAN_PLL4R
CLK_SAI1_PLL3Q
CLK_SAI2_PLL3Q
CLK_SAI3_PLL3Q
diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
index 4045a6e731..a7a125c087 100644
--- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
@@ -110,7 +110,7 @@
CLK_UART6_HSI
CLK_UART78_HSI
CLK_SPDIF_PLL4P
- CLK_FDCAN_PLL4Q
+ CLK_FDCAN_PLL4R
CLK_SAI1_PLL3Q
CLK_SAI2_PLL3Q
CLK_SAI3_PLL3Q
diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
index b2ac49472a..32d95b84e7 100644
--- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
@@ -107,7 +107,7 @@
CLK_UART6_HSI
CLK_UART78_HSI
CLK_SPDIF_PLL4P
- CLK_FDCAN_PLL4Q
+ CLK_FDCAN_PLL4R
CLK_SAI1_PLL3Q
CLK_SAI2_PLL3Q
CLK_SAI3_PLL3Q
diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
index 320912edd8..21aa4bfb86 100644
--- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
@@ -142,7 +142,7 @@
CLK_UART6_HSI
CLK_UART78_HSI
CLK_SPDIF_PLL4P
- CLK_FDCAN_PLL4Q
+ CLK_FDCAN_PLL4R
CLK_SAI1_PLL3Q
CLK_SAI2_PLL3Q
CLK_SAI3_PLL3Q
--
2.17.1
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [PATCH 5/9] ARM: dts: stm32mp1: correct ddr node
2020-01-28 9:10 [PATCH 0/9] stm32mp1 devicetre-tree and board update Patrick Delaunay
` (3 preceding siblings ...)
2020-01-28 9:11 ` [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R Patrick Delaunay
@ 2020-01-28 9:11 ` Patrick Delaunay
2020-02-13 8:13 ` [Uboot-stm32] " Patrice CHOTARD
2020-02-14 10:27 ` Patrick DELAUNAY
2020-01-28 9:11 ` [PATCH 6/9] ARM: dts: stm32m1: add reg for pll nodes Patrick Delaunay
` (3 subsequent siblings)
8 siblings, 2 replies; 38+ messages in thread
From: Patrick Delaunay @ 2020-01-28 9:11 UTC (permalink / raw)
To: u-boot
This patch fix the warning:
dt.dts: Warning (simple_bus_reg): Node /soc/ddr at 5A003000
simple-bus unit address format error, expected "5a003000"
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
---
arch/arm/dts/stm32mp15-ddr.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp15-ddr.dtsi b/arch/arm/dts/stm32mp15-ddr.dtsi
index 479b700c86..38f29bb789 100644
--- a/arch/arm/dts/stm32mp15-ddr.dtsi
+++ b/arch/arm/dts/stm32mp15-ddr.dtsi
@@ -5,7 +5,7 @@
/ {
soc {
- ddr: ddr at 5A003000 {
+ ddr: ddr at 5a003000 {
u-boot,dm-pre-reloc;
compatible = "st,stm32mp1-ddr";
--
2.17.1
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [PATCH 6/9] ARM: dts: stm32m1: add reg for pll nodes
2020-01-28 9:10 [PATCH 0/9] stm32mp1 devicetre-tree and board update Patrick Delaunay
` (4 preceding siblings ...)
2020-01-28 9:11 ` [PATCH 5/9] ARM: dts: stm32mp1: correct ddr node Patrick Delaunay
@ 2020-01-28 9:11 ` Patrick Delaunay
2020-02-13 8:13 ` [Uboot-stm32] " Patrice CHOTARD
2020-02-14 10:27 ` Patrick DELAUNAY
2020-01-28 9:11 ` [PATCH 7/9] board: stm32mp1: update readme Patrick Delaunay
` (2 subsequent siblings)
8 siblings, 2 replies; 38+ messages in thread
From: Patrick Delaunay @ 2020-01-28 9:11 UTC (permalink / raw)
To: u-boot
Fix the following DT dtc warnings for stm32mp1 boards:
Warning (unit_address_vs_reg): /soc/rcc at 50000000/st,pll at 0:
node has a unit name, but no reg property
Warning (unit_address_vs_reg): /soc/rcc at 50000000/st,pll at 1:
node has a unit name, but no reg property
Warning (unit_address_vs_reg): /soc/rcc at 50000000/st,pll at 2:
node has a unit name, but no reg property
Warning (unit_address_vs_reg): /soc/rcc at 50000000/st,pll at 3:
node has a unit name, but no reg property
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
---
arch/arm/dts/stm32mp157-u-boot.dtsi | 2 ++
.../arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 8 +++++
arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 8 +++++
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 8 +++++
arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 8 +++++
.../clock/st,stm32mp1.txt | 32 ++++++++++++++++---
6 files changed, 62 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/stm32mp157-u-boot.dtsi b/arch/arm/dts/stm32mp157-u-boot.dtsi
index cb8d60e33d..8f9535a4db 100644
--- a/arch/arm/dts/stm32mp157-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157-u-boot.dtsi
@@ -134,6 +134,8 @@
&rcc {
u-boot,dm-pre-reloc;
+ #address-cells = <1>;
+ #size-cells = <0>;
};
&sdmmc1 {
diff --git a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
index d8a4617d90..d6dc746365 100644
--- a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
@@ -105,6 +105,8 @@
/* VCO = 1300.0 MHz => P = 650 (CPU) */
pll1: st,pll at 0 {
+ compatible = "st,stm32mp1-pll";
+ reg = <0>;
cfg = < 2 80 0 0 0 PQR(1,0,0) >;
frac = < 0x800 >;
u-boot,dm-pre-reloc;
@@ -112,6 +114,8 @@
/* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU), R = 533 (DDR) */
pll2: st,pll at 1 {
+ compatible = "st,stm32mp1-pll";
+ reg = <1>;
cfg = < 2 65 1 0 0 PQR(1,1,1) >;
frac = < 0x1400 >;
u-boot,dm-pre-reloc;
@@ -119,6 +123,8 @@
/* VCO = 417.8 MHz => P = 209, Q = 24, R = 11 */
pll3: st,pll at 2 {
+ compatible = "st,stm32mp1-pll";
+ reg = <2>;
cfg = < 1 33 1 16 36 PQR(1,1,1) >;
frac = < 0x1a04 >;
u-boot,dm-pre-reloc;
@@ -126,6 +132,8 @@
/* VCO = 480.0 MHz => P = 120, Q = 40, R = 96 */
pll4: st,pll at 3 {
+ compatible = "st,stm32mp1-pll";
+ reg = <3>;
cfg = < 1 39 3 11 4 PQR(1,1,1) >;
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
index a7a125c087..a5cc01dd19 100644
--- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
@@ -124,6 +124,8 @@
/* VCO = 1300.0 MHz => P = 650 (CPU) */
pll1: st,pll at 0 {
+ compatible = "st,stm32mp1-pll";
+ reg = <0>;
cfg = < 2 80 0 0 0 PQR(1,0,0) >;
frac = < 0x800 >;
u-boot,dm-pre-reloc;
@@ -131,6 +133,8 @@
/* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU), R = 533 (DDR) */
pll2: st,pll at 1 {
+ compatible = "st,stm32mp1-pll";
+ reg = <1>;
cfg = < 2 65 1 0 0 PQR(1,1,1) >;
frac = < 0x1400 >;
u-boot,dm-pre-reloc;
@@ -138,6 +142,8 @@
/* VCO = 417.8 MHz => P = 209, Q = 24, R = 11 */
pll3: st,pll at 2 {
+ compatible = "st,stm32mp1-pll";
+ reg = <2>;
cfg = < 1 33 1 16 36 PQR(1,1,1) >;
frac = < 0x1a04 >;
u-boot,dm-pre-reloc;
@@ -145,6 +151,8 @@
/* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
pll4: st,pll at 3 {
+ compatible = "st,stm32mp1-pll";
+ reg = <3>;
cfg = < 3 98 5 7 7 PQR(1,1,1) >;
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
index 32d95b84e7..347edf7e58 100644
--- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
@@ -121,6 +121,8 @@
/* VCO = 1300.0 MHz => P = 650 (CPU) */
pll1: st,pll at 0 {
+ compatible = "st,stm32mp1-pll";
+ reg = <0>;
cfg = < 2 80 0 0 0 PQR(1,0,0) >;
frac = < 0x800 >;
u-boot,dm-pre-reloc;
@@ -128,6 +130,8 @@
/* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU), R = 533 (DDR) */
pll2: st,pll at 1 {
+ compatible = "st,stm32mp1-pll";
+ reg = <1>;
cfg = < 2 65 1 0 0 PQR(1,1,1) >;
frac = < 0x1400 >;
u-boot,dm-pre-reloc;
@@ -135,6 +139,8 @@
/* VCO = 417.8 MHz => P = 209, Q = 24, R = 11 */
pll3: st,pll at 2 {
+ compatible = "st,stm32mp1-pll";
+ reg = <2>;
cfg = < 1 33 1 16 36 PQR(1,1,1) >;
frac = < 0x1a04 >;
u-boot,dm-pre-reloc;
@@ -142,6 +148,8 @@
/* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
pll4: st,pll at 3 {
+ compatible = "st,stm32mp1-pll";
+ reg = <3>;
cfg = < 3 98 5 7 7 PQR(1,1,1) >;
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
index 21aa4bfb86..6c952a57ee 100644
--- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
@@ -156,6 +156,8 @@
/* VCO = 1300.0 MHz => P = 650 (CPU) */
pll1: st,pll at 0 {
+ compatible = "st,stm32mp1-pll";
+ reg = <0>;
cfg = < 2 80 0 0 0 PQR(1,0,0) >;
frac = < 0x800 >;
u-boot,dm-pre-reloc;
@@ -163,6 +165,8 @@
/* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU), R = 533 (DDR) */
pll2: st,pll at 1 {
+ compatible = "st,stm32mp1-pll";
+ reg = <1>;
cfg = < 2 65 1 0 0 PQR(1,1,1) >;
frac = < 0x1400 >;
u-boot,dm-pre-reloc;
@@ -170,6 +174,8 @@
/* VCO = 417.8 MHz => P = 209, Q = 24, R = 11 */
pll3: st,pll at 2 {
+ compatible = "st,stm32mp1-pll";
+ reg = <2>;
cfg = < 1 33 1 16 36 PQR(1,1,1) >;
frac = < 0x1a04 >;
u-boot,dm-pre-reloc;
@@ -177,6 +183,8 @@
/* VCO = 600.0 MHz => P = 50, Q = 50, R = 50 */
pll4: st,pll at 3 {
+ compatible = "st,stm32mp1-pll";
+ reg = <3>;
cfg = < 1 49 11 11 11 PQR(1,1,1) >;
u-boot,dm-pre-reloc;
};
diff --git a/doc/device-tree-bindings/clock/st,stm32mp1.txt b/doc/device-tree-bindings/clock/st,stm32mp1.txt
index ec1d703f34..a3d427911d 100644
--- a/doc/device-tree-bindings/clock/st,stm32mp1.txt
+++ b/doc/device-tree-bindings/clock/st,stm32mp1.txt
@@ -12,6 +12,9 @@ describes the fields added for clock tree initialization which are not present
in Linux binding for compatible "st,stm32mp1-rcc" defined in st,stm32mp1-rcc.txt
file.
+This parent node may optionally have additional children nodes which define
+specific init values for RCC elements.
+
The added properties for clock tree initialization are:
Required properties:
@@ -78,13 +81,16 @@ Required properties:
>;
Optional Properties:
-- st,pll : A specific PLL configuration, including frequency.
+- children for a PLL configuration with "st,stm32mp1-pll" compatible
- PLL children nodes for PLL1 to PLL4 (see ref manual for details)
- are listed with associated index 0 to 3 (st,pll at 0 to st,pll at 3).
- PLLx is off when the associated node is absent.
+ each PLL children nodes for PLL1 to PLL4 (see ref manual for details)
+ are listed with associated reg 0 to 3.
+ PLLx is off when the associated node is absent or deactivated.
Here are the available properties for each PLL node:
+ - compatible: should be "st,stm32mp1-pll"
+
+ - reg: index of the pll instance
- cfg: The parameters for PLL configuration in the following order:
DIVM DIVN DIVP DIVQ DIVR Output.
@@ -118,18 +124,26 @@ Optional Properties:
Example:
st,pll at 0 {
+ compatible = "st,stm32mp1-pll";
+ reg = <0>;
cfg = < 1 53 0 0 0 1 >;
frac = < 0x810 >;
};
st,pll at 1 {
+ compatible = "st,stm32mp1-pll";
+ reg = <1>;
cfg = < 1 43 1 0 0 PQR(0,1,1) >;
csg = < 10 20 1 >;
};
st,pll at 2 {
+ compatible = "st,stm32mp1-pll";
+ reg = <2>;
cfg = < 2 85 3 13 3 0 >;
csg = < 10 20 SSCG_MODE_CENTER_SPREAD >;
};
st,pll at 3 {
+ compatible = "st,stm32mp1-pll";
+ reg = <3>;
cfg = < 2 78 4 7 9 3 >;
};
@@ -277,6 +291,8 @@ Example of clock tree initialization
u-boot,dm-pre-reloc;
compatible = "st,stm32mp1-rcc", "syscon";
reg = <0x50000000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
#clock-cells = <1>;
#reset-cells = <1>;
interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
@@ -347,6 +363,8 @@ Example of clock tree initialization
/* VCO = 1300.0 MHz => P = 650 (CPU) */
pll1: st,pll at 0 {
+ compatible = "st,stm32mp1-pll";
+ reg = <0>;
cfg = < 2 80 0 0 0 PQR(1,0,0) >;
frac = < 0x800 >;
u-boot,dm-pre-reloc;
@@ -355,6 +373,8 @@ Example of clock tree initialization
/* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU),
R = 533 (DDR) */
pll2: st,pll at 1 {
+ compatible = "st,stm32mp1-pll";
+ reg = <1>;
cfg = < 2 65 1 0 0 PQR(1,1,1) >;
frac = < 0x1400 >;
u-boot,dm-pre-reloc;
@@ -362,6 +382,8 @@ Example of clock tree initialization
/* VCO = 417.8 MHz => P = 209, Q = 24, R = 11 */
pll3: st,pll at 2 {
+ compatible = "st,stm32mp1-pll";
+ reg = <2>;
cfg = < 1 33 1 16 36 PQR(1,1,1) >;
frac = < 0x1a04 >;
u-boot,dm-pre-reloc;
@@ -369,6 +391,8 @@ Example of clock tree initialization
/* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
pll4: st,pll at 3 {
+ compatible = "st,stm32mp1-pll";
+ reg = <3>;
cfg = < 3 98 5 7 7 PQR(1,1,1) >;
u-boot,dm-pre-reloc;
};
--
2.17.1
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [PATCH 7/9] board: stm32mp1: update readme
2020-01-28 9:10 [PATCH 0/9] stm32mp1 devicetre-tree and board update Patrick Delaunay
` (5 preceding siblings ...)
2020-01-28 9:11 ` [PATCH 6/9] ARM: dts: stm32m1: add reg for pll nodes Patrick Delaunay
@ 2020-01-28 9:11 ` Patrick Delaunay
2020-02-13 8:13 ` [Uboot-stm32] " Patrice CHOTARD
2020-02-14 10:28 ` Patrick DELAUNAY
2020-01-28 9:11 ` [PATCH 8/9] doc: add board documentation for stm32mp1 Patrick Delaunay
2020-01-28 9:11 ` [PATCH 9/9] stm32mp1: support of STM32MP15x Rev.Z Patrick Delaunay
8 siblings, 2 replies; 38+ messages in thread
From: Patrick Delaunay @ 2020-01-28 9:11 UTC (permalink / raw)
To: u-boot
Update readme:
- list the supported SOC and change family to STM32MP15x
- add warning on OTP write and prerequisite:
check if MAC address is not yet provisioned.
- Use filesize for mmc write command (avoid to write all partition
with ${partsize}). ${filesize} and ${partsize} are set by previous
load command.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
---
board/st/stm32mp1/README | 52 ++++++++++++++++++++++++++--------------
1 file changed, 34 insertions(+), 18 deletions(-)
diff --git a/board/st/stm32mp1/README b/board/st/stm32mp1/README
index f2069bcefa..5d7465a8c8 100644
--- a/board/st/stm32mp1/README
+++ b/board/st/stm32mp1/README
@@ -3,8 +3,8 @@ SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
# Copyright (C) 2018 STMicroelectronics - All Rights Reserved
#
-U-Boot on STMicroelectronics STM32MP1
-======================================
+U-Boot on STMicroelectronics STM32MP15x
+=======================================
1. Summary
==========
@@ -12,12 +12,12 @@ This is a quick instruction for setup stm32mp1 boards.
2. Supported devices
====================
-U-Boot supports one STMP32MP1 SoCs: STM32MP157
+U-Boot supports STMP32MP15x SoCs: STM32MP157, STM32MP153 and STM32MP151
-The STM32MP157 is a Cortex-A MPU aimed at various applications.
+The STM32MP15x is a Cortex-A MPU aimed at various applications.
It features:
-- Dual core Cortex-A7 application core
-- 2D/3D image composition with GPU
+- Dual core Cortex-A7 application core (Single on STM32MP151)
+- 2D/3D image composition with GPU (only on STM32MP157)
- Standard memories interface support
- Standard connectivity, widely inherited from the STM32 MCU family
- Comprehensive security support
@@ -37,11 +37,11 @@ And the necessary drivers
4. Fuse
Currently the following boards are supported:
-+ stm32mp157c-ev1
-+ stm32mp157c-ed1
-+ stm32mp157a-dk1
-+ stm32mp157c-dk2
-+ stm32mp157a-avenger96
++ stm32mp157a-avenger96.dts
++ stm32mp157a-dk1.dts
++ stm32mp157c-dk2.dts
++ stm32mp157c-ed1.dts
++ stm32mp157c-ev1.dts
3. Boot Sequences
=================
@@ -74,7 +74,7 @@ with FSBL = First Stage Bootloader
U-Boot is running in secure mode and provide a secure monitor to the kernel
with only PSCI support (Power State Coordination Interface defined by ARM).
-All the STM32MP1 boards supported by U-Boot use the same generic board
+All the STM32MP15x boards supported by U-Boot use the same generic board
stm32mp1 which support all the bootable devices.
Each board is configurated only with the associated device tree.
@@ -108,7 +108,7 @@ the supported device trees for stm32mp157 are:
+ install package needed in U-Boot makefile
(libssl-dev, swig, libpython-dev...)
+ install ARMv7 toolchain for 32bit Cortex-A (from Linaro,
- from SDK for STM32MP1, or any crosstoolchains from your distribution)
+ from SDK for STM32MP15x, or any crosstoolchains from your distribution)
2. Set the cross compiler:
@@ -323,8 +323,7 @@ c) copy U-Boot in first GPT partition of eMMC
# ext4load mmc 0:4 0xC0000000 u-boot.img
# mmc dev 1
# part start mmc 1 1 partstart
- # part size mmc 1 1 partsize
- # mmc write ${fileaddr} ${partstart} ${partsize}
+ # mmc write ${fileaddr} ${partstart} ${filesize}
To boot from eMMC, select BootPinMode = 0 1 0 and reset.
@@ -334,14 +333,27 @@ To boot from eMMC, select BootPinMode = 0 1 0 and reset.
Please read doc/README.enetaddr for the implementation guidelines for mac id
usage. Basically, environment has precedence over board specific storage.
-Mac id storage and retrieval in stm32mp otp :
+For STMicroelectonics board, it is retrieved in STM32MP15x otp :
- OTP_57[31:0] = MAC_ADDR[31:0]
- OTP_58[15:0] = MAC_ADDR[47:32]
To program a MAC address on virgin OTP words above, you can use the fuse command
on bank 0 to access to internal OTP:
- example to set mac address "12:34:56:78:9a:bc"
+ Prerequisite: check if a MAC address isn't yet programmed in OTP
+
+ 1- check OTP: their value must be equal to 0
+
+ STM32MP> fuse sense 0 57 2
+ Sensing bank 0:
+ Word 0x00000039: 00000000 00000000
+
+ 2- check environment variable
+
+ STM32MP> env print ethaddr
+ ## Error: "ethaddr" not defined
+
+ Example to set mac address "12:34:56:78:9a:bc"
1- Write OTP
STM32MP> fuse prog -y 0 57 0x78563412 0x0000bc9a
@@ -355,9 +367,13 @@ on bank 0 to access to internal OTP:
### Setting environment from OTP MAC address = "12:34:56:78:9a:bc"
4 check env update
- STM32MP> print ethaddr
+ STM32MP> env print ethaddr
ethaddr=12:34:56:78:9a:bc
+warning:: This MAC address provisioning can't be executed twice on the same
+ board as the OTP are protected. It is already done for the board
+ provided by STMicroelectronics.
+
10. Coprocessor firmware
========================
--
2.17.1
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [PATCH 8/9] doc: add board documentation for stm32mp1
2020-01-28 9:10 [PATCH 0/9] stm32mp1 devicetre-tree and board update Patrick Delaunay
` (6 preceding siblings ...)
2020-01-28 9:11 ` [PATCH 7/9] board: stm32mp1: update readme Patrick Delaunay
@ 2020-01-28 9:11 ` Patrick Delaunay
2020-01-28 11:34 ` Heinrich Schuchardt
2020-02-13 8:14 ` Patrice CHOTARD
2020-01-28 9:11 ` [PATCH 9/9] stm32mp1: support of STM32MP15x Rev.Z Patrick Delaunay
8 siblings, 2 replies; 38+ messages in thread
From: Patrick Delaunay @ 2020-01-28 9:11 UTC (permalink / raw)
To: u-boot
Change plain test README to rst format and move this file
in documentation directory.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
---
board/st/stm32mp1/README | 520 +--------------------------------
doc/board/index.rst | 1 +
doc/board/st/index.rst | 9 +
doc/board/st/stm32mp1.rst | 598 ++++++++++++++++++++++++++++++++++++++
4 files changed, 609 insertions(+), 519 deletions(-)
create mode 100644 doc/board/st/index.rst
create mode 100644 doc/board/st/stm32mp1.rst
diff --git a/board/st/stm32mp1/README b/board/st/stm32mp1/README
index 5d7465a8c8..8172d26a66 100644
--- a/board/st/stm32mp1/README
+++ b/board/st/stm32mp1/README
@@ -1,519 +1 @@
-SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
-#
-# Copyright (C) 2018 STMicroelectronics - All Rights Reserved
-#
-
-U-Boot on STMicroelectronics STM32MP15x
-=======================================
-
-1. Summary
-==========
-This is a quick instruction for setup stm32mp1 boards.
-
-2. Supported devices
-====================
-U-Boot supports STMP32MP15x SoCs: STM32MP157, STM32MP153 and STM32MP151
-
-The STM32MP15x is a Cortex-A MPU aimed at various applications.
-It features:
-- Dual core Cortex-A7 application core (Single on STM32MP151)
-- 2D/3D image composition with GPU (only on STM32MP157)
-- Standard memories interface support
-- Standard connectivity, widely inherited from the STM32 MCU family
-- Comprehensive security support
-
-Everything is supported in Linux but U-Boot is limited to:
-1. UART
-2. SDCard/MMC controller (SDMMC)
-3. NAND controller (FMC)
-4. NOR controller (QSPI)
-5. USB controller (OTG DWC2)
-6. Ethernet controller
-
-And the necessary drivers
-1. I2C
-2. STPMIC1 (PMIC and regulator)
-3. Clock, Reset, Sysreset
-4. Fuse
-
-Currently the following boards are supported:
-+ stm32mp157a-avenger96.dts
-+ stm32mp157a-dk1.dts
-+ stm32mp157c-dk2.dts
-+ stm32mp157c-ed1.dts
-+ stm32mp157c-ev1.dts
-
-3. Boot Sequences
-=================
-
-BootRom => FSBL in SYSRAM => SSBL in DDR => OS (Linux Kernel)
-
-with FSBL = First Stage Bootloader
- SSBL = Second Stage Bootloader
-
-3 boot configurations are supported:
-
-1) The "Trusted" boot chain (defconfig_file : stm32mp15_trusted_defconfig)
- BootRom => FSBL = Trusted Firmware-A (TF-A) => SSBL = U-Boot
- TF-A performs a full initialization of Secure peripherals and installs a
- secure monitor.
- U-Boot is running in normal world and uses TF-A monitor
- to access to secure resources.
-
-2) The "Trusted" boot chain with OP-TEE
- (defconfig_file : stm32mp15_optee_defconfig)
- BootRom => FSBL = Trusted Firmware-A (TF-A) => SSBL = U-Boot
- TF-A performs a full initialization of Secure peripherals and installs OP-TEE
- from specific partitions (teeh, teed, teex).
- U-Boot is running in normal world and uses OP-TEE monitor to access
- to secure resources.
-
-3) The "Basic" boot chain (defconfig_file : stm32mp15_basic_defconfig)
- BootRom => FSBL = U-Boot SPL => SSBL = U-Boot
- SPL has limited security initialisation
- U-Boot is running in secure mode and provide a secure monitor to the kernel
- with only PSCI support (Power State Coordination Interface defined by ARM).
-
-All the STM32MP15x boards supported by U-Boot use the same generic board
-stm32mp1 which support all the bootable devices.
-
-Each board is configurated only with the associated device tree.
-
-4. Device Tree Selection
-========================
-
-You need to select the appropriate device tree for your board,
-the supported device trees for stm32mp157 are:
-
-+ ev1: eval board with pmic stpmic1 (ev1 = mother board + daughter ed1)
- dts: stm32mp157c-ev1
-
-+ ed1: daughter board with pmic stpmic1
- dts: stm32mp157c-ed1
-
-+ dk1: Discovery board
- dts: stm32mp157a-dk1
-
-+ dk2: Discovery board = dk1 with a BT/WiFI combo and a DSI panel
- dts: stm32mp157c-dk2
-
-+ avenger96: Avenger96 board from Arrow Electronics
- dts: stm32mp157a-avenger96
-
-5. Build Procedure
-==================
-
-1. Install required tools for U-Boot
-
- + install package needed in U-Boot makefile
- (libssl-dev, swig, libpython-dev...)
- + install ARMv7 toolchain for 32bit Cortex-A (from Linaro,
- from SDK for STM32MP15x, or any crosstoolchains from your distribution)
-
-2. Set the cross compiler:
-
- # export CROSS_COMPILE=/path/to/toolchain/arm-linux-gnueabi-
- (you can use any gcc cross compiler compatible with U-Boot)
-
-3. Select the output directory (optional)
-
- # export KBUILD_OUTPUT=/path/to/output
-
- for example: use one output directory for each configuration
- # export KBUILD_OUTPUT=stm32mp15_trusted
- # export KBUILD_OUTPUT=stm32mp15_optee
- # export KBUILD_OUTPUT=stm32mp15_basic
-
- you can build outside of code directory:
- # export KBUILD_OUTPUT=../build/stm32mp15_trusted
-
-4. Configure U-Boot:
-
- # make <defconfig_file>
-
- - For trusted boot mode : "stm32mp15_trusted_defconfig"
- - For trusted with OP-TEE boot mode : "stm32mp15_optee_defconfig"
- - For basic boot mode: "stm32mp15_basic_defconfig"
-
-5. Configure the device-tree and build the U-Boot image:
-
- # make DEVICE_TREE=<name> all
-
- example:
- a) trusted boot on ev1
- # export KBUILD_OUTPUT=stm32mp15_trusted
- # make stm32mp15_trusted_defconfig
- # make DEVICE_TREE=stm32mp157c-ev1 all
-
- b) trusted with OP-TEE boot on dk2
- # export KBUILD_OUTPUT=stm32mp15_optee
- # make stm32mp15_optee_defconfig
- # make DEVICE_TREE=stm32mp157c-dk2 all
-
- c) basic boot on ev1
- # export KBUILD_OUTPUT=stm32mp15_basic
- # make stm32mp15_basic_defconfig
- # make DEVICE_TREE=stm32mp157c-ev1 all
-
- d) basic boot on ed1
- # export KBUILD_OUTPUT=stm32mp15_basic
- # make stm32mp15_basic_defconfig
- # make DEVICE_TREE=stm32mp157c-ed1 all
-
- e) basic boot on dk1
- # export KBUILD_OUTPUT=stm32mp15_basic
- # make stm32mp15_basic_defconfig
- # make DEVICE_TREE=stm32mp157a-dk1 all
-
- f) basic boot on avenger96
- # export KBUILD_OUTPUT=stm32mp15_basic
- # make stm32mp15_basic_defconfig
- # make DEVICE_TREE=stm32mp157a-avenger96 all
-
-6. Output files
-
- BootRom and TF-A expect binaries with STM32 image header
- SPL expects file with U-Boot uImage header
-
- So in the output directory (selected by KBUILD_OUTPUT),
- you can found the needed files:
-
- a) For Trusted boot (with or without OP-TEE)
- + FSBL = tf-a.stm32 (provided by TF-A compilation)
- + SSBL = u-boot.stm32
-
- b) For Basic boot
- + FSBL = spl/u-boot-spl.stm32
- + SSBL = u-boot.img
-
-6. Switch Setting for Boot Mode
-===============================
-
-You can select the boot mode, on the board with one switch :
-
-- on the daugther board ed1 with the switch SW1 : BOOT0, BOOT1, BOOT2
-
- -----------------------------------
- Boot Mode BOOT2 BOOT1 BOOT0
- -----------------------------------
- Reserved 0 0 0
- NOR 0 0 1
- SD-Card 1 0 1
- eMMC 0 1 0
- NAND 0 1 1
- Recovery 1 1 0
- Recovery 0 0 0
-
-- on board DK1/DK2 with the switch SW1 : BOOT0, BOOT2
- (BOOT1 forced to 0, NOR not supported)
-
- --------------------------
- Boot Mode BOOT2 BOOT0
- --------------------------
- Reserved 1 0
- SD-Card 1 1
- Recovery 0 0
-
-- Boot mode of Avenger96 can be selected using switch S3
-
- -----------------------------------
- Boot Mode BOOT2 BOOT1 BOOT0
- -----------------------------------
- Recovery 0 0 0
- NOR 0 0 1
- SD-Card 1 0 1
- eMMC 0 1 0
- NAND 0 1 1
- Reserved 1 0 0
- Recovery 1 1 0
- SD-Card 1 1 1
-
-Recovery is a boot from serial link (UART/USB) and it is used with
-STM32CubeProgrammer tool to load executable in RAM and to update the flash
-devices available on the board (NOR/NAND/eMMC/SDCARD).
-The communication between HOST and board is based on
-- for UARTs : the uart protocol used with all MCU STM32
-- for USB : based on USB DFU 1.1 (without the ST extensions used on MCU STM32)
-
-7. Prepare an SDCard
-===================
-
-The minimal requirements for STMP32MP1 boot up to U-Boot are:
-- GPT partitioning (with gdisk or with sgdisk)
-- 2 fsbl partitions, named fsbl1 and fsbl2, size at least 256KiB
-- one ssbl partition for U-Boot
-
-Then the minimal GPT partition is:
- ----- ------- --------- --------------
- | Num | Name | Size | Content |
- ----- ------- -------- ---------------
- | 1 | fsbl1 | 256 KiB | TF-A or SPL |
- | 2 | fsbl2 | 256 KiB | TF-A or SPL |
- | 3 | ssbl | enought | U-Boot |
- | * | - | - | Boot/Rootfs |
- ----- ------- --------- --------------
-
-(*) add bootable partition for extlinux.conf
- following Generic Distribution
- (doc/README.distro for use)
-
- according the used card reader select the block device
- (/dev/sdx or /dev/mmcblk0)
- in the next example I use /dev/mmcblk0
-
-for example: with gpt table with 128 entries
-
- a) remove previous formatting
- # sgdisk -o /dev/<SDCard dev>
-
- b) create minimal image
- # sgdisk --resize-table=128 -a 1 \
- -n 1:34:545 -c 1:fsbl1 \
- -n 2:546:1057 -c 2:fsbl2 \
- -n 3:1058:5153 -c 3:ssbl \
- -p /dev/<SDCard dev>
-
- you can add other partitions for kernel
- one partition rootfs for example:
- -n 4:5154: -c 4:rootfs \
-
- c) copy the FSBL (2 times) and SSBL file on the correct partition.
- in this example in partition 1 to 3
-
- for basic boot mode : <SDCard dev> = /dev/mmcblk0
- # dd if=u-boot-spl.stm32 of=/dev/mmcblk0p1
- # dd if=u-boot-spl.stm32 of=/dev/mmcblk0p2
- # dd if=u-boot.img of=/dev/mmcblk0p3
-
- for trusted boot mode :
- # dd if=tf-a.stm32 of=/dev/mmcblk0p1
- # dd if=tf-a.stm32 of=/dev/mmcblk0p2
- # dd if=u-boot.stm32 of=/dev/mmcblk0p3
-
-To boot from SDCard, select BootPinMode = 1 0 1 and reset.
-
-8. Prepare eMMC
-===============
-You can use U-Boot to copy binary in eMMC.
-
-In the next example, you need to boot from SDCARD and the images (u-boot-spl.stm32, u-boot.img)
-are presents on SDCARD (mmc 0) in ext4 partition 4 (bootfs).
-
-To boot from SDCard, select BootPinMode = 1 0 1 and reset.
-
-Then you update the eMMC with the next U-Boot command :
-
-a) prepare GPT on eMMC,
- example with 2 partitions, bootfs and roots:
-
- # setenv emmc_part "name=ssbl,size=2MiB;name=bootfs,type=linux,bootable,size=64MiB;name=rootfs,type=linux,size=512"
- # gpt write mmc 1 ${emmc_part}
-
-b) copy SPL on eMMC on firts boot partition
- (SPL max size is 256kB, with LBA 512, 0x200)
-
- # ext4load mmc 0:4 0xC0000000 u-boot-spl.stm32
- # mmc dev 1
- # mmc partconf 1 1 1 1
- # mmc write ${fileaddr} 0 200
- # mmc partconf 1 1 1 0
-
-c) copy U-Boot in first GPT partition of eMMC
-
- # ext4load mmc 0:4 0xC0000000 u-boot.img
- # mmc dev 1
- # part start mmc 1 1 partstart
- # mmc write ${fileaddr} ${partstart} ${filesize}
-
-To boot from eMMC, select BootPinMode = 0 1 0 and reset.
-
-9. MAC Address
-==============
-
-Please read doc/README.enetaddr for the implementation guidelines for mac id
-usage. Basically, environment has precedence over board specific storage.
-
-For STMicroelectonics board, it is retrieved in STM32MP15x otp :
-- OTP_57[31:0] = MAC_ADDR[31:0]
-- OTP_58[15:0] = MAC_ADDR[47:32]
-
-To program a MAC address on virgin OTP words above, you can use the fuse command
-on bank 0 to access to internal OTP:
-
- Prerequisite: check if a MAC address isn't yet programmed in OTP
-
- 1- check OTP: their value must be equal to 0
-
- STM32MP> fuse sense 0 57 2
- Sensing bank 0:
- Word 0x00000039: 00000000 00000000
-
- 2- check environment variable
-
- STM32MP> env print ethaddr
- ## Error: "ethaddr" not defined
-
- Example to set mac address "12:34:56:78:9a:bc"
-
- 1- Write OTP
- STM32MP> fuse prog -y 0 57 0x78563412 0x0000bc9a
-
- 2- Read OTP
- STM32MP> fuse sense 0 57 2
- Sensing bank 0:
- Word 0x00000039: 78563412 0000bc9a
-
- 3- next REBOOT :
- ### Setting environment from OTP MAC address = "12:34:56:78:9a:bc"
-
- 4 check env update
- STM32MP> env print ethaddr
- ethaddr=12:34:56:78:9a:bc
-
-warning:: This MAC address provisioning can't be executed twice on the same
- board as the OTP are protected. It is already done for the board
- provided by STMicroelectronics.
-
-10. Coprocessor firmware
-========================
-
-U-Boot can boot the coprocessor before the kernel (coprocessor early boot).
-
-A/ Manuallly by using rproc commands (update the bootcmd)
- Configurations
- # env set name_copro "rproc-m4-fw.elf"
- # env set dev_copro 0
- # env set loadaddr_copro 0xC1000000
-
- Load binary from bootfs partition (number 4) on SDCard (mmc 0)
- # ext4load mmc 0:4 ${loadaddr_copro} ${name_copro}
- => ${filesize} updated with the size of the loaded file
-
- Start M4 firmware with remote proc command
- # rproc init
- # rproc load ${dev_copro} ${loadaddr_copro} ${filesize}
- # rproc start ${dev_copro}
-
-B/ Automatically by using FIT feature and generic DISTRO bootcmd
-
- see examples in this directory :
-
- Generate FIT including kernel + device tree + M4 firmware
- with cfg with M4 boot
- $> mkimage -f fit_copro_kernel_dtb.its fit_copro_kernel_dtb.itb
-
- Then using DISTRO configuration file: see extlinux.conf to select
- the correct configuration
- => stm32mp157c-ev1-m4
- => stm32mp157c-dk2-m4
-
-11. DFU support
-===============
-
-The DFU is supported on ST board.
-The env variable dfu_alt_info is automatically build, and all
-the memory present on the ST boards are exported.
-
-The mode is started by
-
-STM32MP> dfu 0
-
-On EV1 board:
-
-STM32MP> dfu 0 list
-
-DFU alt settings list:
-dev: RAM alt: 0 name: uImage layout: RAM_ADDR
-dev: RAM alt: 1 name: devicetree.dtb layout: RAM_ADDR
-dev: RAM alt: 2 name: uramdisk.image.gz layout: RAM_ADDR
-dev: eMMC alt: 3 name: sdcard_fsbl1 layout: RAW_ADDR
-dev: eMMC alt: 4 name: sdcard_fsbl2 layout: RAW_ADDR
-dev: eMMC alt: 5 name: sdcard_ssbl layout: RAW_ADDR
-dev: eMMC alt: 6 name: sdcard_bootfs layout: RAW_ADDR
-dev: eMMC alt: 7 name: sdcard_vendorfs layout: RAW_ADDR
-dev: eMMC alt: 8 name: sdcard_rootfs layout: RAW_ADDR
-dev: eMMC alt: 9 name: sdcard_userfs layout: RAW_ADDR
-dev: eMMC alt: 10 name: emmc_fsbl1 layout: RAW_ADDR
-dev: eMMC alt: 11 name: emmc_fsbl2 layout: RAW_ADDR
-dev: eMMC alt: 12 name: emmc_ssbl layout: RAW_ADDR
-dev: eMMC alt: 13 name: emmc_bootfs layout: RAW_ADDR
-dev: eMMC alt: 14 name: emmc_vendorfs layout: RAW_ADDR
-dev: eMMC alt: 15 name: emmc_rootfs layout: RAW_ADDR
-dev: eMMC alt: 16 name: emmc_userfs layout: RAW_ADDR
-dev: MTD alt: 17 name: nor_fsbl1 layout: RAW_ADDR
-dev: MTD alt: 18 name: nor_fsbl2 layout: RAW_ADDR
-dev: MTD alt: 19 name: nor_ssbl layout: RAW_ADDR
-dev: MTD alt: 20 name: nor_env layout: RAW_ADDR
-dev: MTD alt: 21 name: nand_fsbl layout: RAW_ADDR
-dev: MTD alt: 22 name: nand_ssbl1 layout: RAW_ADDR
-dev: MTD alt: 23 name: nand_ssbl2 layout: RAW_ADDR
-dev: MTD alt: 24 name: nand_UBI layout: RAW_ADDR
-dev: VIRT alt: 25 name: OTP layout: RAW_ADDR
-dev: VIRT alt: 26 name: PMIC layout: RAW_ADDR
-
-All the supported device are exported for dfu-util tool:
-
-$> dfu-util -l
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=26, name="PMIC", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=25, name="OTP", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=24, name="nand_UBI", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=23, name="nand_ssbl2", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=22, name="nand_ssbl1", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=21, name="nand_fsbl", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=20, name="nor_env", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=19, name="nor_ssbl", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=18, name="nor_fsbl2", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=17, name="nor_fsbl1", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=16, name="emmc_userfs", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=15, name="emmc_rootfs", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=14, name="emmc_vendorfs", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=13, name="emmc_bootfs", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=12, name="emmc_ssbl", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=11, name="emmc_fsbl2", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=10, name="emmc_fsbl1", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=9, name="sdcard_userfs", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=8, name="sdcard_rootfs", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=7, name="sdcard_vendorfs", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=6, name="sdcard_bootfs", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=5, name="sdcard_ssbl", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=4, name="sdcard_fsbl2", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=3, name="sdcard_fsbl1", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=2, name="uramdisk.image.gz", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=1, name="devicetree.dtb", serial="002700333338511934383330"
-Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=0, name="uImage", serial="002700333338511934383330"
-
-You can update the boot device:
-
-#SDCARD
-$> dfu-util -d 0483:5720 -a 3 -D tf-a-stm32mp157c-ev1-trusted.stm32
-$> dfu-util -d 0483:5720 -a 4 -D tf-a-stm32mp157c-ev1-trusted.stm32
-$> dfu-util -d 0483:5720 -a 5 -D u-boot-stm32mp157c-ev1-trusted.img
-$> dfu-util -d 0483:5720 -a 6 -D st-image-bootfs-openstlinux-weston-stm32mp1.ext4
-$> dfu-util -d 0483:5720 -a 7 -D st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
-$> dfu-util -d 0483:5720 -a 8 -D st-image-weston-openstlinux-weston-stm32mp1.ext4
-$> dfu-util -d 0483:5720 -a 9 -D st-image-userfs-openstlinux-weston-stm32mp1.ext4
-
-#EMMC
-$> dfu-util -d 0483:5720 -a 10 -D tf-a-stm32mp157c-ev1-trusted.stm32
-$> dfu-util -d 0483:5720 -a 11 -D tf-a-stm32mp157c-ev1-trusted.stm32
-$> dfu-util -d 0483:5720 -a 12 -D u-boot-stm32mp157c-ev1-trusted.img
-$> dfu-util -d 0483:5720 -a 13 -D st-image-bootfs-openstlinux-weston-stm32mp1.ext4
-$> dfu-util -d 0483:5720 -a 14 -D st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
-$> dfu-util -d 0483:5720 -a 15 -D st-image-weston-openstlinux-weston-stm32mp1.ext4
-$> dfu-util -d 0483:5720 -a 16 -D st-image-userfs-openstlinux-weston-stm32mp1.ext4
-
-#NOR
-$> dfu-util -d 0483:5720 -a 17 -D tf-a-stm32mp157c-ev1-trusted.stm32
-$> dfu-util -d 0483:5720 -a 18 -D tf-a-stm32mp157c-ev1-trusted.stm32
-$> dfu-util -d 0483:5720 -a 19 -D u-boot-stm32mp157c-ev1-trusted.img
-
-#NAND (UBI partition used for NAND only boot or NOR + NAND boot)
-$> dfu-util -d 0483:5720 -a 21 -D tf-a-stm32mp157c-ev1-trusted.stm32
-$> dfu-util -d 0483:5720 -a 22 -D u-boot-stm32mp157c-ev1-trusted.img
-$> dfu-util -d 0483:5720 -a 23 -D u-boot-stm32mp157c-ev1-trusted.img
-$> dfu-util -d 0483:5720 -a 24 -D st-image-weston-openstlinux-weston-stm32mp1_nand_4_256_multivolume.ubi
-
-And you can also dump the OTP and the PMIC NVM with:
-
-$> dfu-util -d 0483:5720 -a 25 -U otp.bin
-$> dfu-util -d 0483:5720 -a 26 -U pmic.bin
+see doc/board/st/stm32mp1.rst
diff --git a/doc/board/index.rst b/doc/board/index.rst
index 00e72f57cd..21fddd2f92 100644
--- a/doc/board/index.rst
+++ b/doc/board/index.rst
@@ -15,4 +15,5 @@ Board-specific doc
intel/index
renesas/index
sifive/index
+ st/index
xilinx/index
diff --git a/doc/board/st/index.rst b/doc/board/st/index.rst
new file mode 100644
index 0000000000..91f1d51b42
--- /dev/null
+++ b/doc/board/st/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+STMicroelectronics
+==================
+
+.. toctree::
+ :maxdepth: 2
+
+ stm32mp1
diff --git a/doc/board/st/stm32mp1.rst b/doc/board/st/stm32mp1.rst
new file mode 100644
index 0000000000..131f4902a3
--- /dev/null
+++ b/doc/board/st/stm32mp1.rst
@@ -0,0 +1,598 @@
+.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+.. sectionauthor:: Patrick Delaunay <patrick.delaunay@st.com>
+
+STM32MP15x boards
+=================
+
+This is a quick instruction for setup STM32MP15x boards.
+
+Supported devices
+-----------------
+
+U-Boot supports STMP32MP15x SoCs:
+ - STM32MP157
+ - STM32MP153
+ - STM32MP151
+
+The STM32MP15x is a Cortex-A MPU aimed at various applications.
+
+It features:
+ - Dual core Cortex-A7 application core (Single on STM32MP151)
+ - 2D/3D image composition with GPU (only on STM32MP157)
+ - Standard memories interface support
+ - Standard connectivity, widely inherited from the STM32 MCU family
+ - Comprehensive security support
+
+Everything is supported in Linux but U-Boot is limited to:
+ 1. UART
+ 2. SD card/MMC controller (SDMMC)
+ 3. NAND controller (FMC)
+ 4. NOR controller (QSPI)
+ 5. USB controller (OTG DWC2)
+ 6. Ethernet controller
+
+And the necessary drivers
+ 1. I2C
+ 2. STPMIC1 (PMIC and regulator)
+ 3. Clock, Reset, Sysreset
+ 4. Fuse
+
+Currently the following boards are supported:
+ + stm32mp157a-avenger96.dts
+ + stm32mp157a-dk1.dts
+ + stm32mp157c-dk2.dts
+ + stm32mp157c-ed1.dts
+ + stm32mp157c-ev1.dts
+
+Boot Sequences
+--------------
+
+3 boot configurations are supported with:
+
++----------+------------------------+-------------------------+--------------+
+| **ROM** | **FSBL** | **SSBL** | **OS** |
++ **code** +------------------------+-------------------------+--------------+
+| | First Stage Bootloader | Second Stage Bootloader | Linux Kernel |
++ +------------------------+-------------------------+--------------+
+| | embedded RAM | DDR |
++----------+------------------------+-------------------------+--------------+
+
+The **Trusted** boot chain
+``````````````````````````
+
+defconfig_file : stm32mp15_trusted_defconfig
+
+ +-------------+-------------------------+------------+-------+
+ | ROM code | FSBL | SSBL | OS |
+ + +-------------------------+------------+-------+
+ | |Trusted Firmware-A (TF-A)| U-Boot | Linux |
+ +-------------+-------------------------+------------+-------+
+ | TrustZone |TF-A secure monitor |
+ +-------------+-------------------------+------------+-------+
+
+TF-A performs a full initialization of Secure peripherals and installs a
+secure monitor (BL32=SPMin).
+
+U-Boot is running in normal world and uses TF-A monitor to access
+to secure resources.
+
+The **Trusted** boot chain with **OP-TEE**
+``````````````````````````````````````````
+
+defconfig_file : stm32mp15_optee_defconfig
+
+ +-------------+-------------------------+------------+-------+
+ | ROM code | FSBL | SSBL | OS |
+ + +-------------------------+------------+-------+
+ | |Trusted Firmware-A (TF-A)| U-Boot | Linux |
+ +-------------+-------------------------+------------+-------+
+ | TrustZone |OP-TEE |
+ +-------------+-------------------------+------------+-------+
+
+TF-A performs a full initialization of Secure peripherals and installs OP-TEE
+from specific partitions (teeh, teed, teex).
+
+U-Boot is running in normal world and uses OP-TEE monitor to access
+to secure resources.
+
+The **Basic** boot chain
+````````````````````````
+
+defconfig_file : stm32mp15_basic_defconfig
+
+ +-------------+------------+------------+-------+
+ | ROM code | FSBL | SSBL | OS |
+ + +------------+------------+-------+
+ | |U-Boot SPL | U-Boot | Linux |
+ +-------------+------------+------------+-------+
+ | TrustZone | | PSCI from U-Boot |
+ +-------------+------------+------------+-------+
+
+SPL has limited security initialization
+
+U-Boot is running in secure mode and provide a secure monitor to the kernel
+with only PSCI support (Power State Coordination Interface defined by ARM).
+
+All the STM32MP15x boards supported by U-Boot use the same generic board
+stm32mp1 which support all the bootable devices.
+
+Each board is configured only with the associated device tree.
+
+Device Tree Selection
+---------------------
+
+You need to select the appropriate device tree for your board,
+the supported device trees for STM32MP15x are:
+
++ ev1: eval board with pmic stpmic1 (ev1 = mother board + daughter ed1)
+ + stm32mp157c-ev1
+
++ ed1: daughter board with pmic stpmic1
+ + stm32mp157c-ed1
+
++ dk1: Discovery board
+ + stm32mp157a-dk1
+
++ dk2: Discovery board = dk1 with a BT/WiFI combo and a DSI panel
+ + stm32mp157c-dk2
+
++ avenger96: Avenger96 board from Arrow Electronics
+ + stm32mp157a-avenger96
+
+Build Procedure
+---------------
+
+1. Install the required tools for U-Boot
+
+ * install package needed in U-Boot makefile
+ (libssl-dev, swig, libpython-dev...)
+
+ * install ARMv7 toolchain for 32bit Cortex-A (from Linaro,
+ from SDK for STM32MP15x, or any crosstoolchains from your distribution)
+ (you can use any gcc cross compiler compatible with U-Boot)
+
+2. Set the cross compiler::
+
+ # export CROSS_COMPILE=/path/to/toolchain/arm-linux-gnueabi-
+
+3. Select the output directory (optional)::
+
+ # export KBUILD_OUTPUT=/path/to/output
+
+ for example: use one output directory for each configuration::
+
+ # export KBUILD_OUTPUT=stm32mp15_trusted
+ # export KBUILD_OUTPUT=stm32mp15_optee
+ # export KBUILD_OUTPUT=stm32mp15_basic
+
+ you can build outside of code directory::
+
+ # export KBUILD_OUTPUT=../build/stm32mp15_trusted
+
+4. Configure U-Boot::
+
+ # make <defconfig_file>
+
+ with <defconfig_file>:
+
+ - For **trusted** boot mode : **stm32mp15_trusted_defconfig**
+ - For **trusted** with OP-TEE boot mode : **stm32mp15_optee_defconfig**
+ - For basic boot mode: stm32mp15_basic_defconfig
+
+5. Configure the device-tree and build the U-Boot image::
+
+ # make DEVICE_TREE=<name> all
+
+ Examples:
+
+ a) trusted boot on ev1::
+
+ # export KBUILD_OUTPUT=stm32mp15_trusted
+ # make stm32mp15_trusted_defconfig
+ # make DEVICE_TREE=stm32mp157c-ev1 all
+
+ b) trusted with OP-TEE boot on dk2::
+
+ # export KBUILD_OUTPUT=stm32mp15_optee
+ # make stm32mp15_optee_defconfig
+ # make DEVICE_TREE=stm32mp157c-dk2 all
+
+ c) basic boot on ev1::
+
+ # export KBUILD_OUTPUT=stm32mp15_basic
+ # make stm32mp15_basic_defconfig
+ # make DEVICE_TREE=stm32mp157c-ev1 all
+
+ d) basic boot on ed1::
+
+ # export KBUILD_OUTPUT=stm32mp15_basic
+ # make stm32mp15_basic_defconfig
+ # make DEVICE_TREE=stm32mp157c-ed1 all
+
+ e) basic boot on dk1::
+
+ # export KBUILD_OUTPUT=stm32mp15_basic
+ # make stm32mp15_basic_defconfig
+ # make DEVICE_TREE=stm32mp157a-dk1 all
+
+ f) basic boot on avenger96::
+
+ # export KBUILD_OUTPUT=stm32mp15_basic
+ # make stm32mp15_basic_defconfig
+ # make DEVICE_TREE=stm32mp157a-avenger96 all
+
+6. Output files
+
+ BootRom and TF-A expect binaries with STM32 image header
+ SPL expects file with U-Boot uImage header
+
+ So in the output directory (selected by KBUILD_OUTPUT),
+ you can found the needed files:
+
+ - For **Trusted** boot (with or without OP-TEE)
+ - FSBL = **tf-a.stm32** (provided by TF-A compilation)
+ - SSBL = **u-boot.stm32**
+
+ - For Basic boot
+ - FSBL = spl/u-boot-spl.stm32
+ - SSBL = u-boot.img
+
+Switch Setting for Boot Mode
+----------------------------
+
+You can select the boot mode, on the board with one switch, to select
+the boot pin values = BOOT0, BOOT1, BOOT2
+
+ +-------------+---------+---------+---------+
+ |*Boot Mode* | *BOOT2* | *BOOT1* | *BOOT0* |
+ +=============+=========+=========+=========+
+ | Recovery | 0 | 0 | 0 |
+ +-------------+---------+---------+---------+
+ | NOR | 0 | 0 | 1 |
+ +-------------+---------+---------+---------+
+ | eMMC | 0 | 1 | 0 |
+ +-------------+---------+---------+---------+
+ | NAND | 0 | 1 | 1 |
+ +-------------+---------+---------+---------+
+ | Reserved | 1 | 0 | 0 |
+ +-------------+---------+---------+---------+
+ | SD-Card | 1 | 0 | 1 |
+ +-------------+---------+---------+---------+
+ | Recovery | 1 | 1 | 0 |
+ +-------------+---------+---------+---------+
+ | SPI-NAND | 1 | 1 | 1 |
+ +-------------+---------+---------+---------+
+
+- on the **daugther board ed1 = MB1263** with the switch SW1
+- on **Avenger96** with switch S3 (NOR and SPI-NAND are not applicable)
+- on board **DK1/DK2** with the switch SW1 = BOOT0, BOOT2
+ with only 2 pins available (BOOT1 is forced to 0 and NOR not supported),
+ the possible value becomes:
+
+ +-------------+---------+---------+
+ |*Boot Mode* | *BOOT2* | *BOOT0* |
+ +=============+=========+=========+
+ | Recovery | 0 | 0 |
+ +-------------+---------+---------+
+ | NOR (NA)| 0 | 1 |
+ +-------------+---------+---------+
+ | Reserved | 1 | 0 |
+ +-------------+---------+---------+
+ | SD-Card | 1 | 1 |
+ +-------------+---------+---------+
+
+Recovery is a boot from serial link (UART/USB) and it is used with
+STM32CubeProgrammer tool to load executable in RAM and to update the flash
+devices available on the board (NOR/NAND/eMMC/SD card).
+
+The communication between HOST and board is based on
+ - for UARTs : the uart protocol used with all MCU STM32
+ - for USB : based on USB DFU 1.1 (without the ST extensions used on MCU STM32)
+
+Prepare an SD card
+------------------
+
+The minimal requirements for STMP32MP15x boot up to U-Boot are:
+
+- GPT partitioning (with gdisk or with sgdisk)
+- 2 fsbl partitions, named fsbl1 and fsbl2, size at least 256KiB
+- one ssbl partition for U-Boot
+
+Then the minimal GPT partition is:
+
+ +-------+--------+---------+-------------+
+ | *Num* | *Name* | *Size* | *Content* |
+ +=======+========+=========+=============+
+ | 1 | fsbl1 | 256 KiB | TF-A or SPL |
+ +-------+--------+---------+-------------+
+ | 2 | fsbl2 | 256 KiB | TF-A or SPL |
+ +-------+--------+---------+-------------+
+ | 3 | ssbl | enought | U-Boot |
+ +-------+--------+---------+-------------+
+ | 4 | <any> | <any> | Rootfs |
+ +-------+--------+---------+-------------+
+
+Add a 4th partition (Rootfs) marked bootable with a file extlinux.conf
+following the Generic Distribution feature (doc/README.distro for use).
+
+According the used card reader select the correct block device
+(for example /dev/sdx or /dev/mmcblk0).
+
+In the next example, it is /dev/mmcblk0
+
+For example: with gpt table with 128 entries
+
+a) remove previous formatting::
+
+ # sgdisk -o /dev/<SD card dev>
+
+b) create minimal image::
+
+ # sgdisk --resize-table=128 -a 1 \
+ -n 1:34:545 -c 1:fsbl1 \
+ -n 2:546:1057 -c 2:fsbl2 \
+ -n 3:1058:5153 -c 3:ssbl \
+ -n 4:5154: -c 4:rootfs \
+ -p /dev/<SD card dev>
+
+ With other partition for kernel one partition rootfs for kernel.
+
+c) copy the FSBL (2 times) and SSBL file on the correct partition.
+ in this example in partition 1 to 3
+
+ for basic boot mode : <SD card dev> = /dev/mmcblk0::
+
+ # dd if=u-boot-spl.stm32 of=/dev/mmcblk0p1
+ # dd if=u-boot-spl.stm32 of=/dev/mmcblk0p2
+ # dd if=u-boot.img of=/dev/mmcblk0p3
+
+ for trusted boot mode: ::
+
+ # dd if=tf-a.stm32 of=/dev/mmcblk0p1
+ # dd if=tf-a.stm32 of=/dev/mmcblk0p2
+ # dd if=u-boot.stm32 of=/dev/mmcblk0p3
+
+To boot from SD card, select BootPinMode = 1 0 1 and reset.
+
+Prepare eMMC
+------------
+
+You can use U-Boot to copy binary in eMMC.
+
+In the next example, you need to boot from SD card and the images
+(u-boot-spl.stm32, u-boot.img) are presents on SD card (mmc 0)
+in ext4 partition 4 (bootfs).
+
+To boot from SD card, select BootPinMode = 1 0 1 and reset.
+
+Then you update the eMMC with the next U-Boot command :
+
+a) prepare GPT on eMMC,
+ example with 2 partitions, bootfs and roots::
+
+ # setenv emmc_part "name=ssbl,size=2MiB;name=bootfs,type=linux,bootable,size=64MiB;name=rootfs,type=linux,size=512"
+ # gpt write mmc 1 ${emmc_part}
+
+b) copy SPL on eMMC on firts boot partition
+ (SPL max size is 256kB, with LBA 512, 0x200)::
+
+ # ext4load mmc 0:4 0xC0000000 u-boot-spl.stm32
+ # mmc dev 1
+ # mmc partconf 1 1 1 1
+ # mmc write ${fileaddr} 0 200
+ # mmc partconf 1 1 1 0
+
+c) copy U-Boot in first GPT partition of eMMC::
+
+ # ext4load mmc 0:4 0xC0000000 u-boo t.img
+ # mmc dev 1
+ # part start mmc 1 1 partstart
+ # mmc write ${fileaddr} ${partstart} ${filesize}
+
+To boot from eMMC, select BootPinMode = 0 1 0 and reset.
+
+MAC Address
+-----------
+
+Please read doc/README.enetaddr for the implementation guidelines for mac id
+usage. Basically, environment has precedence over board specific storage.
+
+For STMicroelectonics board, it is retrieved in STM32MP15x OTP :
+ - OTP_57[31:0] = MAC_ADDR[31:0]
+ - OTP_58[15:0] = MAC_ADDR[47:32]
+
+To program a MAC address on virgin OTP words above, you can use the fuse command
+on bank 0 to access to internal OTP:
+
+Prerequisite: check if a MAC address isn't yet programmed in OTP
+
+1) check OTP: their value must be equal to 0
+
+ STM32MP> fuse sense 0 57 2
+ Sensing bank 0:
+ Word 0x00000039: 00000000 00000000
+
+2) check environment variable
+
+ STM32MP> env print ethaddr
+ ## Error: "ethaddr" not defined
+
+Example to set mac address "12:34:56:78:9a:bc"
+
+1) Write OTP::
+
+ STM32MP> fuse prog -y 0 57 0x78563412 0x0000bc9a
+
+2) Read OTP::
+
+ STM32MP> fuse sense 0 57 2
+ Sensing bank 0:
+ Word 0x00000039: 78563412 0000bc9a
+
+3) next REBOOT, in the trace::
+
+ ### Setting environment from OTP MAC address = "12:34:56:78:9a:bc"
+
+4) check env update::
+
+ STM32MP> env print ethaddr
+ ethaddr=12:34:56:78:9a:bc
+
+.. warning:: This command can't be executed twice on the same board as
+ OTP are protected. It is already done for the board
+ provided by STMicroelectronics.
+
+Coprocessor firmware
+--------------------
+
+U-Boot can boot the coprocessor before the kernel (coprocessor early boot).
+
+a) Manuallly by using rproc commands (update the bootcmd)
+
+ Configurations::
+
+ # env set name_copro "rproc-m4-fw.elf"
+ # env set dev_copro 0
+ # env set loadaddr_copro 0xC1000000
+
+ Load binary from bootfs partition (number 4) on SD card (mmc 0)::
+
+ # ext4load mmc 0:4 ${loadaddr_copro} ${name_copro}
+
+ => ${filesize} variable is updated with the size of the loaded file.
+
+ Start M4 firmware with remote proc command::
+
+ # rproc init
+ # rproc load ${dev_copro} ${loadaddr_copro} ${filesize}
+ # rproc start ${dev_copro}"00270033
+
+b) Automatically by using FIT feature and generic DISTRO bootcmd
+
+ see examples in the board stm32mp1 directory: fit_copro_kernel_dtb.its
+
+ Generate FIT including kernel + device tree + M4 firmware with cfg with M4 boot::
+
+ $> mkimage -f fit_copro_kernel_dtb.its fit_copro_kernel_dtb.itb
+
+ Then using DISTRO configuration file: see extlinux.conf to select the correct
+ configuration:
+
+ - stm32mp157c-ev1-m4
+ - stm32mp157c-dk2-m4
+
+DFU support
+-----------
+
+The DFU is supported on ST board.
+
+The env variable dfu_alt_info is automatically build, and all
+the memory present on the ST boards are exported.
+
+The dfu mode is started by the command::
+
+ STM32MP> dfu 0
+
+On EV1 board, booting from SD card, without OP-TEE::
+
+ STM32MP> dfu 0 list
+ DFU alt settings list:
+ dev: RAM alt: 0 name: uImage layout: RAM_ADDR
+ dev: RAM alt: 1 name: devicetree.dtb layout: RAM_ADDR
+ dev: RAM alt: 2 name: uramdisk.image.gz layout: RAM_ADDR
+ dev: eMMC alt: 3 name: sdcard_fsbl1 layout: RAW_ADDR
+ dev: eMMC alt: 4 name: sdcard_fsbl2 layout: RAW_ADDR
+ dev: eMMC alt: 5 name: sdcard_ssbl layout: RAW_ADDR
+ dev: eMMC alt: 6 name: sdcard_bootfs layout: RAW_ADDR
+ dev: eMMC alt: 7 name: sdcard_vendorfs layout: RAW_ADDR
+ dev: eMMC alt: 8 name: sdcard_rootfs layout: RAW_ADDR
+ dev: eMMC alt: 9 name: sdcard_userfs layout: RAW_ADDR
+ dev: eMMC alt: 10 name: emmc_fsbl1 layout: RAW_ADDR
+ dev: eMMC alt: 11 name: emmc_fsbl2 layout: RAW_ADDR
+ dev: eMMC alt: 12 name: emmc_ssbl layout: RAW_ADDR
+ dev: eMMC alt: 13 name: emmc_bootfs layout: RAW_ADDR
+ dev: eMMC alt: 14 name: emmc_vendorfs layout: RAW_ADDR
+ dev: eMMC alt: 15 name: emmc_rootfs layout: RAW_ADDR
+ dev: eMMC alt: 16 name: emmc_userfs layout: RAW_ADDR
+ dev: MTD alt: 17 name: nor_fsbl1 layout: RAW_ADDR
+ dev: MTD alt: 18 name: nor_fsbl2 layout: RAW_ADDR
+ dev: MTD alt: 19 name: nor_ssbl layout: RAW_ADDR
+ dev: MTD alt: 20 name: nor_env layout: RAW_ADDR
+ dev: MTD alt: 21 name: nand_fsbl layout: RAW_ADDR
+ dev: MTD alt: 22 name: nand_ssbl1 layout: RAW_ADDR
+ dev: MTD alt: 23 name: nand_ssbl2 layout: RAW_ADDR
+ dev: MTD alt: 24 name: nand_UBI layout: RAW_ADDR
+ dev: VIRT alt: 25 name: OTP layout: RAW_ADDR
+ dev: VIRT alt: 26 name: PMIC layout: RAW_ADDR
+
+All the supported device are exported for dfu-util tool::
+
+ $> dfu-util -l
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=26, name="PMIC", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=25, name="OTP", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=24, name="nand_UBI", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=23, name="nand_ssbl2", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=22, name="nand_ssbl1", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=21, name="nand_fsbl", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=20, name="nor_env", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=19, name="nor_ssbl", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=18, name="nor_fsbl2", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=17, name="nor_fsbl1", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=16, name="emmc_userfs", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=15, name="emmc_rootfs", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=14, name="emmc_vendorfs", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=13, name="emmc_bootfs", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=12, name="emmc_ssbl", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=11, name="emmc_fsbl2", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=10, name="emmc_fsbl1", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=9, name="sdcard_userfs", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=8, name="sdcard_rootfs", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=7, name="sdcard_vendorfs", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=6, name="sdcard_bootfs", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=5, name="sdcard_ssbl", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=4, name="sdcard_fsbl2", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=3, name="sdcard_fsbl1", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=2, name="uramdisk.image.gz", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=1, name="devicetree.dtb", serial="002700333338511934383330"
+ Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=0, name="uImage", serial="002700333338511934383330"
+
+You can update the boot device:
+
+- SD card (mmc0) ::
+
+ $> dfu-util -d 0483:5720 -a 3 -D tf-a-stm32mp157c-ev1-trusted.stm32
+ $> dfu-util -d 0483:5720 -a 4 -D tf-a-stm32mp157c-ev1-trusted.stm32
+ $> dfu-util -d 0483:5720 -a 5 -D u-boot-stm32mp157c-ev1-trusted.img
+ $> dfu-util -d 0483:5720 -a 6 -D st-image-bootfs-openstlinux-weston-stm32mp1.ext4
+ $> dfu-util -d 0483:5720 -a 7 -D st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
+ $> dfu-util -d 0483:5720 -a 8 -D st-image-weston-openstlinux-weston-stm32mp1.ext4
+ $> dfu-util -d 0483:5720 -a 9 -D st-image-userfs-openstlinux-weston-stm32mp1.ext4
+
+- EMMC (mmc1)::
+
+ $> dfu-util -d 0483:5720 -a 10 -D tf-a-stm32mp157c-ev1-trusted.stm32
+ $> dfu-util -d 0483:5720 -a 11 -D tf-a-stm32mp157c-ev1-trusted.stm32
+ $> dfu-util -d 0483:5720 -a 12 -D u-boot-stm32mp157c-ev1-trusted.img
+ $> dfu-util -d 0483:5720 -a 13 -D st-image-bootfs-openstlinux-weston-stm32mp1.ext4
+ $> dfu-util -d 0483:5720 -a 14 -D st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
+ $> dfu-util -d 0483:5720 -a 15 -D st-image-weston-openstlinux-weston-stm32mp1.ext4
+ $> dfu-util -d 0483:5720 -a 16 -D st-image-userfs-openstlinux-weston-stm32mp1.ext4
+
+- NOR::
+
+ $> dfu-util -d 0483:5720 -a 17 -D tf-a-stm32mp157c-ev1-trusted.stm32
+ $> dfu-util -d 0483:5720 -a 18 -D tf-a-stm32mp157c-ev1-trusted.stm32
+ $> dfu-util -d 0483:5720 -a 19 -D u-boot-stm32mp157c-ev1-trusted.img
+
+- NAND (UBI partition used for NAND only boot or NOR + NAND boot)::
+
+ $> dfu-util -d 0483:5720 -a 21 -D tf-a-stm32mp157c-ev1-trusted.stm32
+ $> dfu-util -d 0483:5720 -a 22 -D u-boot-stm32mp157c-ev1-trusted.img
+ $> dfu-util -d 0483:5720 -a 23 -D u-boot-stm32mp157c-ev1-trusted.img
+ $> dfu-util -d 0483:5720 -a 24 -D st-image-weston-openstlinux-weston-stm32mp1_nand_4_256_multivolume.ubi
+
+- you can also dump the OTP and the PMIC NVM with::
+
+ $> dfu-util -d 0483:5720 -a 25 -U otp.bin
+ $> dfu-util -d 0483:5720 -a 26 -U pmic.bin
+
--
2.17.1
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [PATCH 9/9] stm32mp1: support of STM32MP15x Rev.Z
2020-01-28 9:10 [PATCH 0/9] stm32mp1 devicetre-tree and board update Patrick Delaunay
` (7 preceding siblings ...)
2020-01-28 9:11 ` [PATCH 8/9] doc: add board documentation for stm32mp1 Patrick Delaunay
@ 2020-01-28 9:11 ` Patrick Delaunay
2020-02-13 12:34 ` Patrice CHOTARD
2020-02-14 10:29 ` Patrick DELAUNAY
8 siblings, 2 replies; 38+ messages in thread
From: Patrick Delaunay @ 2020-01-28 9:11 UTC (permalink / raw)
To: u-boot
Add support for Rev.Z of STM32MP15x cpu.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
---
arch/arm/mach-stm32mp/cpu.c | 3 +++
arch/arm/mach-stm32mp/include/mach/sys_proto.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
index de7891b5c4..ea0bd94605 100644
--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -342,6 +342,9 @@ int print_cpuinfo(void)
case CPU_REVB:
cpu_r = "B";
break;
+ case CPU_REVZ:
+ cpu_r = "Z";
+ break;
default:
cpu_r = "?";
break;
diff --git a/arch/arm/mach-stm32mp/include/mach/sys_proto.h b/arch/arm/mach-stm32mp/include/mach/sys_proto.h
index 47e57922d1..da46c11573 100644
--- a/arch/arm/mach-stm32mp/include/mach/sys_proto.h
+++ b/arch/arm/mach-stm32mp/include/mach/sys_proto.h
@@ -16,6 +16,7 @@ u32 get_cpu_type(void);
#define CPU_REVA 0x1000
#define CPU_REVB 0x2000
+#define CPU_REVZ 0x2001
/* return CPU_REV constants */
u32 get_cpu_rev(void);
--
2.17.1
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [PATCH 8/9] doc: add board documentation for stm32mp1
2020-01-28 9:11 ` [PATCH 8/9] doc: add board documentation for stm32mp1 Patrick Delaunay
@ 2020-01-28 11:34 ` Heinrich Schuchardt
2020-02-10 11:02 ` Patrick DELAUNAY
2020-02-13 8:14 ` Patrice CHOTARD
1 sibling, 1 reply; 38+ messages in thread
From: Heinrich Schuchardt @ 2020-01-28 11:34 UTC (permalink / raw)
To: u-boot
On 1/28/20 10:11 AM, Patrick Delaunay wrote:
> Change plain test README to rst format and move this file
> in documentation directory.
>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
When I apply only this patch to origin/master:
git am /tmp/1.patch
Applying: doc: add board documentation for stm32mp1
error: patch failed: board/st/stm32mp1/README:1
error: board/st/stm32mp1/README: patch does not apply
.git/rebase-apply/patch:1164: new blank line at EOF.
Maybe this patch will have to be rebased.
> ---
>
> board/st/stm32mp1/README | 520 +--------------------------------
> doc/board/index.rst | 1 +
> doc/board/st/index.rst | 9 +
> doc/board/st/stm32mp1.rst | 598 ++++++++++++++++++++++++++++++++++++++
> 4 files changed, 609 insertions(+), 519 deletions(-)
> create mode 100644 doc/board/st/index.rst
> create mode 100644 doc/board/st/stm32mp1.rst
>
> diff --git a/board/st/stm32mp1/README b/board/st/stm32mp1/README
> index 5d7465a8c8..8172d26a66 100644
> --- a/board/st/stm32mp1/README
> +++ b/board/st/stm32mp1/README
> @@ -1,519 +1 @@
> -SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> -#
> -# Copyright (C) 2018 STMicroelectronics - All Rights Reserved
> -#
> -
> -U-Boot on STMicroelectronics STM32MP15x
> -=======================================
> -
> -1. Summary
> -==========
> -This is a quick instruction for setup stm32mp1 boards.
> -
> -2. Supported devices
> -====================
> -U-Boot supports STMP32MP15x SoCs: STM32MP157, STM32MP153 and STM32MP151
> -
> -The STM32MP15x is a Cortex-A MPU aimed at various applications.
> -It features:
> -- Dual core Cortex-A7 application core (Single on STM32MP151)
> -- 2D/3D image composition with GPU (only on STM32MP157)
> -- Standard memories interface support
> -- Standard connectivity, widely inherited from the STM32 MCU family
> -- Comprehensive security support
> -
> -Everything is supported in Linux but U-Boot is limited to:
> -1. UART
> -2. SDCard/MMC controller (SDMMC)
> -3. NAND controller (FMC)
> -4. NOR controller (QSPI)
> -5. USB controller (OTG DWC2)
> -6. Ethernet controller
> -
> -And the necessary drivers
> -1. I2C
> -2. STPMIC1 (PMIC and regulator)
> -3. Clock, Reset, Sysreset
> -4. Fuse
> -
> -Currently the following boards are supported:
> -+ stm32mp157a-avenger96.dts
> -+ stm32mp157a-dk1.dts
> -+ stm32mp157c-dk2.dts
> -+ stm32mp157c-ed1.dts
> -+ stm32mp157c-ev1.dts
> -
> -3. Boot Sequences
> -=================
> -
> -BootRom => FSBL in SYSRAM => SSBL in DDR => OS (Linux Kernel)
> -
> -with FSBL = First Stage Bootloader
> - SSBL = Second Stage Bootloader
> -
> -3 boot configurations are supported:
> -
> -1) The "Trusted" boot chain (defconfig_file : stm32mp15_trusted_defconfig)
> - BootRom => FSBL = Trusted Firmware-A (TF-A) => SSBL = U-Boot
> - TF-A performs a full initialization of Secure peripherals and installs a
> - secure monitor.
> - U-Boot is running in normal world and uses TF-A monitor
> - to access to secure resources.
> -
> -2) The "Trusted" boot chain with OP-TEE
> - (defconfig_file : stm32mp15_optee_defconfig)
> - BootRom => FSBL = Trusted Firmware-A (TF-A) => SSBL = U-Boot
> - TF-A performs a full initialization of Secure peripherals and installs OP-TEE
> - from specific partitions (teeh, teed, teex).
> - U-Boot is running in normal world and uses OP-TEE monitor to access
> - to secure resources.
> -
> -3) The "Basic" boot chain (defconfig_file : stm32mp15_basic_defconfig)
> - BootRom => FSBL = U-Boot SPL => SSBL = U-Boot
> - SPL has limited security initialisation
> - U-Boot is running in secure mode and provide a secure monitor to the kernel
> - with only PSCI support (Power State Coordination Interface defined by ARM).
> -
> -All the STM32MP15x boards supported by U-Boot use the same generic board
> -stm32mp1 which support all the bootable devices.
> -
> -Each board is configurated only with the associated device tree.
> -
> -4. Device Tree Selection
> -========================
> -
> -You need to select the appropriate device tree for your board,
> -the supported device trees for stm32mp157 are:
> -
> -+ ev1: eval board with pmic stpmic1 (ev1 = mother board + daughter ed1)
> - dts: stm32mp157c-ev1
> -
> -+ ed1: daughter board with pmic stpmic1
> - dts: stm32mp157c-ed1
> -
> -+ dk1: Discovery board
> - dts: stm32mp157a-dk1
> -
> -+ dk2: Discovery board = dk1 with a BT/WiFI combo and a DSI panel
> - dts: stm32mp157c-dk2
> -
> -+ avenger96: Avenger96 board from Arrow Electronics
> - dts: stm32mp157a-avenger96
> -
> -5. Build Procedure
> -==================
> -
> -1. Install required tools for U-Boot
> -
> - + install package needed in U-Boot makefile
> - (libssl-dev, swig, libpython-dev...)
> - + install ARMv7 toolchain for 32bit Cortex-A (from Linaro,
> - from SDK for STM32MP15x, or any crosstoolchains from your distribution)
> -
> -2. Set the cross compiler:
> -
> - # export CROSS_COMPILE=/path/to/toolchain/arm-linux-gnueabi-
> - (you can use any gcc cross compiler compatible with U-Boot)
> -
> -3. Select the output directory (optional)
> -
> - # export KBUILD_OUTPUT=/path/to/output
> -
> - for example: use one output directory for each configuration
> - # export KBUILD_OUTPUT=stm32mp15_trusted
> - # export KBUILD_OUTPUT=stm32mp15_optee
> - # export KBUILD_OUTPUT=stm32mp15_basic
> -
> - you can build outside of code directory:
> - # export KBUILD_OUTPUT=../build/stm32mp15_trusted
> -
> -4. Configure U-Boot:
> -
> - # make <defconfig_file>
> -
> - - For trusted boot mode : "stm32mp15_trusted_defconfig"
> - - For trusted with OP-TEE boot mode : "stm32mp15_optee_defconfig"
> - - For basic boot mode: "stm32mp15_basic_defconfig"
> -
> -5. Configure the device-tree and build the U-Boot image:
> -
> - # make DEVICE_TREE=<name> all
> -
> - example:
> - a) trusted boot on ev1
> - # export KBUILD_OUTPUT=stm32mp15_trusted
> - # make stm32mp15_trusted_defconfig
> - # make DEVICE_TREE=stm32mp157c-ev1 all
> -
> - b) trusted with OP-TEE boot on dk2
> - # export KBUILD_OUTPUT=stm32mp15_optee
> - # make stm32mp15_optee_defconfig
> - # make DEVICE_TREE=stm32mp157c-dk2 all
> -
> - c) basic boot on ev1
> - # export KBUILD_OUTPUT=stm32mp15_basic
> - # make stm32mp15_basic_defconfig
> - # make DEVICE_TREE=stm32mp157c-ev1 all
> -
> - d) basic boot on ed1
> - # export KBUILD_OUTPUT=stm32mp15_basic
> - # make stm32mp15_basic_defconfig
> - # make DEVICE_TREE=stm32mp157c-ed1 all
> -
> - e) basic boot on dk1
> - # export KBUILD_OUTPUT=stm32mp15_basic
> - # make stm32mp15_basic_defconfig
> - # make DEVICE_TREE=stm32mp157a-dk1 all
> -
> - f) basic boot on avenger96
> - # export KBUILD_OUTPUT=stm32mp15_basic
> - # make stm32mp15_basic_defconfig
> - # make DEVICE_TREE=stm32mp157a-avenger96 all
> -
> -6. Output files
> -
> - BootRom and TF-A expect binaries with STM32 image header
> - SPL expects file with U-Boot uImage header
> -
> - So in the output directory (selected by KBUILD_OUTPUT),
> - you can found the needed files:
> -
> - a) For Trusted boot (with or without OP-TEE)
> - + FSBL = tf-a.stm32 (provided by TF-A compilation)
> - + SSBL = u-boot.stm32
> -
> - b) For Basic boot
> - + FSBL = spl/u-boot-spl.stm32
> - + SSBL = u-boot.img
> -
> -6. Switch Setting for Boot Mode
> -===============================
> -
> -You can select the boot mode, on the board with one switch :
> -
> -- on the daugther board ed1 with the switch SW1 : BOOT0, BOOT1, BOOT2
> -
> - -----------------------------------
> - Boot Mode BOOT2 BOOT1 BOOT0
> - -----------------------------------
> - Reserved 0 0 0
> - NOR 0 0 1
> - SD-Card 1 0 1
> - eMMC 0 1 0
> - NAND 0 1 1
> - Recovery 1 1 0
> - Recovery 0 0 0
> -
> -- on board DK1/DK2 with the switch SW1 : BOOT0, BOOT2
> - (BOOT1 forced to 0, NOR not supported)
> -
> - --------------------------
> - Boot Mode BOOT2 BOOT0
> - --------------------------
> - Reserved 1 0
> - SD-Card 1 1
> - Recovery 0 0
> -
> -- Boot mode of Avenger96 can be selected using switch S3
> -
> - -----------------------------------
> - Boot Mode BOOT2 BOOT1 BOOT0
> - -----------------------------------
> - Recovery 0 0 0
> - NOR 0 0 1
> - SD-Card 1 0 1
> - eMMC 0 1 0
> - NAND 0 1 1
> - Reserved 1 0 0
> - Recovery 1 1 0
> - SD-Card 1 1 1
> -
> -Recovery is a boot from serial link (UART/USB) and it is used with
> -STM32CubeProgrammer tool to load executable in RAM and to update the flash
> -devices available on the board (NOR/NAND/eMMC/SDCARD).
> -The communication between HOST and board is based on
> -- for UARTs : the uart protocol used with all MCU STM32
> -- for USB : based on USB DFU 1.1 (without the ST extensions used on MCU STM32)
> -
> -7. Prepare an SDCard
> -===================
> -
> -The minimal requirements for STMP32MP1 boot up to U-Boot are:
> -- GPT partitioning (with gdisk or with sgdisk)
> -- 2 fsbl partitions, named fsbl1 and fsbl2, size at least 256KiB
> -- one ssbl partition for U-Boot
> -
> -Then the minimal GPT partition is:
> - ----- ------- --------- --------------
> - | Num | Name | Size | Content |
> - ----- ------- -------- ---------------
> - | 1 | fsbl1 | 256 KiB | TF-A or SPL |
> - | 2 | fsbl2 | 256 KiB | TF-A or SPL |
> - | 3 | ssbl | enought | U-Boot |
> - | * | - | - | Boot/Rootfs |
> - ----- ------- --------- --------------
> -
> -(*) add bootable partition for extlinux.conf
> - following Generic Distribution
> - (doc/README.distro for use)
> -
> - according the used card reader select the block device
> - (/dev/sdx or /dev/mmcblk0)
> - in the next example I use /dev/mmcblk0
> -
> -for example: with gpt table with 128 entries
> -
> - a) remove previous formatting
> - # sgdisk -o /dev/<SDCard dev>
> -
> - b) create minimal image
> - # sgdisk --resize-table=128 -a 1 \
> - -n 1:34:545 -c 1:fsbl1 \
> - -n 2:546:1057 -c 2:fsbl2 \
> - -n 3:1058:5153 -c 3:ssbl \
> - -p /dev/<SDCard dev>
> -
> - you can add other partitions for kernel
> - one partition rootfs for example:
> - -n 4:5154: -c 4:rootfs \
> -
> - c) copy the FSBL (2 times) and SSBL file on the correct partition.
> - in this example in partition 1 to 3
> -
> - for basic boot mode : <SDCard dev> = /dev/mmcblk0
> - # dd if=u-boot-spl.stm32 of=/dev/mmcblk0p1
> - # dd if=u-boot-spl.stm32 of=/dev/mmcblk0p2
> - # dd if=u-boot.img of=/dev/mmcblk0p3
> -
> - for trusted boot mode :
> - # dd if=tf-a.stm32 of=/dev/mmcblk0p1
> - # dd if=tf-a.stm32 of=/dev/mmcblk0p2
> - # dd if=u-boot.stm32 of=/dev/mmcblk0p3
> -
> -To boot from SDCard, select BootPinMode = 1 0 1 and reset.
> -
> -8. Prepare eMMC
> -===============
> -You can use U-Boot to copy binary in eMMC.
> -
> -In the next example, you need to boot from SDCARD and the images (u-boot-spl.stm32, u-boot.img)
> -are presents on SDCARD (mmc 0) in ext4 partition 4 (bootfs).
> -
> -To boot from SDCard, select BootPinMode = 1 0 1 and reset.
> -
> -Then you update the eMMC with the next U-Boot command :
> -
> -a) prepare GPT on eMMC,
> - example with 2 partitions, bootfs and roots:
> -
> - # setenv emmc_part "name=ssbl,size=2MiB;name=bootfs,type=linux,bootable,size=64MiB;name=rootfs,type=linux,size=512"
> - # gpt write mmc 1 ${emmc_part}
> -
> -b) copy SPL on eMMC on firts boot partition
> - (SPL max size is 256kB, with LBA 512, 0x200)
> -
> - # ext4load mmc 0:4 0xC0000000 u-boot-spl.stm32
> - # mmc dev 1
> - # mmc partconf 1 1 1 1
> - # mmc write ${fileaddr} 0 200
> - # mmc partconf 1 1 1 0
> -
> -c) copy U-Boot in first GPT partition of eMMC
> -
> - # ext4load mmc 0:4 0xC0000000 u-boot.img
> - # mmc dev 1
> - # part start mmc 1 1 partstart
> - # mmc write ${fileaddr} ${partstart} ${filesize}
> -
> -To boot from eMMC, select BootPinMode = 0 1 0 and reset.
> -
> -9. MAC Address
> -==============
> -
> -Please read doc/README.enetaddr for the implementation guidelines for mac id
> -usage. Basically, environment has precedence over board specific storage.
> -
> -For STMicroelectonics board, it is retrieved in STM32MP15x otp :
> -- OTP_57[31:0] = MAC_ADDR[31:0]
> -- OTP_58[15:0] = MAC_ADDR[47:32]
> -
> -To program a MAC address on virgin OTP words above, you can use the fuse command
> -on bank 0 to access to internal OTP:
> -
> - Prerequisite: check if a MAC address isn't yet programmed in OTP
> -
> - 1- check OTP: their value must be equal to 0
> -
> - STM32MP> fuse sense 0 57 2
> - Sensing bank 0:
> - Word 0x00000039: 00000000 00000000
> -
> - 2- check environment variable
> -
> - STM32MP> env print ethaddr
> - ## Error: "ethaddr" not defined
> -
> - Example to set mac address "12:34:56:78:9a:bc"
> -
> - 1- Write OTP
> - STM32MP> fuse prog -y 0 57 0x78563412 0x0000bc9a
> -
> - 2- Read OTP
> - STM32MP> fuse sense 0 57 2
> - Sensing bank 0:
> - Word 0x00000039: 78563412 0000bc9a
> -
> - 3- next REBOOT :
> - ### Setting environment from OTP MAC address = "12:34:56:78:9a:bc"
> -
> - 4 check env update
> - STM32MP> env print ethaddr
> - ethaddr=12:34:56:78:9a:bc
> -
> -warning:: This MAC address provisioning can't be executed twice on the same
> - board as the OTP are protected. It is already done for the board
> - provided by STMicroelectronics.
> -
> -10. Coprocessor firmware
> -========================
> -
> -U-Boot can boot the coprocessor before the kernel (coprocessor early boot).
> -
> -A/ Manuallly by using rproc commands (update the bootcmd)
> - Configurations
> - # env set name_copro "rproc-m4-fw.elf"
> - # env set dev_copro 0
> - # env set loadaddr_copro 0xC1000000
> -
> - Load binary from bootfs partition (number 4) on SDCard (mmc 0)
> - # ext4load mmc 0:4 ${loadaddr_copro} ${name_copro}
> - => ${filesize} updated with the size of the loaded file
> -
> - Start M4 firmware with remote proc command
> - # rproc init
> - # rproc load ${dev_copro} ${loadaddr_copro} ${filesize}
> - # rproc start ${dev_copro}
> -
> -B/ Automatically by using FIT feature and generic DISTRO bootcmd
> -
> - see examples in this directory :
> -
> - Generate FIT including kernel + device tree + M4 firmware
> - with cfg with M4 boot
> - $> mkimage -f fit_copro_kernel_dtb.its fit_copro_kernel_dtb.itb
> -
> - Then using DISTRO configuration file: see extlinux.conf to select
> - the correct configuration
> - => stm32mp157c-ev1-m4
> - => stm32mp157c-dk2-m4
> -
> -11. DFU support
> -===============
> -
> -The DFU is supported on ST board.
> -The env variable dfu_alt_info is automatically build, and all
> -the memory present on the ST boards are exported.
> -
> -The mode is started by
> -
> -STM32MP> dfu 0
> -
> -On EV1 board:
> -
> -STM32MP> dfu 0 list
> -
> -DFU alt settings list:
> -dev: RAM alt: 0 name: uImage layout: RAM_ADDR
> -dev: RAM alt: 1 name: devicetree.dtb layout: RAM_ADDR
> -dev: RAM alt: 2 name: uramdisk.image.gz layout: RAM_ADDR
> -dev: eMMC alt: 3 name: sdcard_fsbl1 layout: RAW_ADDR
> -dev: eMMC alt: 4 name: sdcard_fsbl2 layout: RAW_ADDR
> -dev: eMMC alt: 5 name: sdcard_ssbl layout: RAW_ADDR
> -dev: eMMC alt: 6 name: sdcard_bootfs layout: RAW_ADDR
> -dev: eMMC alt: 7 name: sdcard_vendorfs layout: RAW_ADDR
> -dev: eMMC alt: 8 name: sdcard_rootfs layout: RAW_ADDR
> -dev: eMMC alt: 9 name: sdcard_userfs layout: RAW_ADDR
> -dev: eMMC alt: 10 name: emmc_fsbl1 layout: RAW_ADDR
> -dev: eMMC alt: 11 name: emmc_fsbl2 layout: RAW_ADDR
> -dev: eMMC alt: 12 name: emmc_ssbl layout: RAW_ADDR
> -dev: eMMC alt: 13 name: emmc_bootfs layout: RAW_ADDR
> -dev: eMMC alt: 14 name: emmc_vendorfs layout: RAW_ADDR
> -dev: eMMC alt: 15 name: emmc_rootfs layout: RAW_ADDR
> -dev: eMMC alt: 16 name: emmc_userfs layout: RAW_ADDR
> -dev: MTD alt: 17 name: nor_fsbl1 layout: RAW_ADDR
> -dev: MTD alt: 18 name: nor_fsbl2 layout: RAW_ADDR
> -dev: MTD alt: 19 name: nor_ssbl layout: RAW_ADDR
> -dev: MTD alt: 20 name: nor_env layout: RAW_ADDR
> -dev: MTD alt: 21 name: nand_fsbl layout: RAW_ADDR
> -dev: MTD alt: 22 name: nand_ssbl1 layout: RAW_ADDR
> -dev: MTD alt: 23 name: nand_ssbl2 layout: RAW_ADDR
> -dev: MTD alt: 24 name: nand_UBI layout: RAW_ADDR
> -dev: VIRT alt: 25 name: OTP layout: RAW_ADDR
> -dev: VIRT alt: 26 name: PMIC layout: RAW_ADDR
> -
> -All the supported device are exported for dfu-util tool:
> -
> -$> dfu-util -l
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=26, name="PMIC", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=25, name="OTP", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=24, name="nand_UBI", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=23, name="nand_ssbl2", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=22, name="nand_ssbl1", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=21, name="nand_fsbl", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=20, name="nor_env", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=19, name="nor_ssbl", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=18, name="nor_fsbl2", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=17, name="nor_fsbl1", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=16, name="emmc_userfs", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=15, name="emmc_rootfs", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=14, name="emmc_vendorfs", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=13, name="emmc_bootfs", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=12, name="emmc_ssbl", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=11, name="emmc_fsbl2", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=10, name="emmc_fsbl1", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=9, name="sdcard_userfs", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=8, name="sdcard_rootfs", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=7, name="sdcard_vendorfs", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=6, name="sdcard_bootfs", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=5, name="sdcard_ssbl", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=4, name="sdcard_fsbl2", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=3, name="sdcard_fsbl1", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=2, name="uramdisk.image.gz", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=1, name="devicetree.dtb", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=0, name="uImage", serial="002700333338511934383330"
> -
> -You can update the boot device:
> -
> -#SDCARD
> -$> dfu-util -d 0483:5720 -a 3 -D tf-a-stm32mp157c-ev1-trusted.stm32
> -$> dfu-util -d 0483:5720 -a 4 -D tf-a-stm32mp157c-ev1-trusted.stm32
> -$> dfu-util -d 0483:5720 -a 5 -D u-boot-stm32mp157c-ev1-trusted.img
> -$> dfu-util -d 0483:5720 -a 6 -D st-image-bootfs-openstlinux-weston-stm32mp1.ext4
> -$> dfu-util -d 0483:5720 -a 7 -D st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
> -$> dfu-util -d 0483:5720 -a 8 -D st-image-weston-openstlinux-weston-stm32mp1.ext4
> -$> dfu-util -d 0483:5720 -a 9 -D st-image-userfs-openstlinux-weston-stm32mp1.ext4
> -
> -#EMMC
> -$> dfu-util -d 0483:5720 -a 10 -D tf-a-stm32mp157c-ev1-trusted.stm32
> -$> dfu-util -d 0483:5720 -a 11 -D tf-a-stm32mp157c-ev1-trusted.stm32
> -$> dfu-util -d 0483:5720 -a 12 -D u-boot-stm32mp157c-ev1-trusted.img
> -$> dfu-util -d 0483:5720 -a 13 -D st-image-bootfs-openstlinux-weston-stm32mp1.ext4
> -$> dfu-util -d 0483:5720 -a 14 -D st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
> -$> dfu-util -d 0483:5720 -a 15 -D st-image-weston-openstlinux-weston-stm32mp1.ext4
> -$> dfu-util -d 0483:5720 -a 16 -D st-image-userfs-openstlinux-weston-stm32mp1.ext4
> -
> -#NOR
> -$> dfu-util -d 0483:5720 -a 17 -D tf-a-stm32mp157c-ev1-trusted.stm32
> -$> dfu-util -d 0483:5720 -a 18 -D tf-a-stm32mp157c-ev1-trusted.stm32
> -$> dfu-util -d 0483:5720 -a 19 -D u-boot-stm32mp157c-ev1-trusted.img
> -
> -#NAND (UBI partition used for NAND only boot or NOR + NAND boot)
> -$> dfu-util -d 0483:5720 -a 21 -D tf-a-stm32mp157c-ev1-trusted.stm32
> -$> dfu-util -d 0483:5720 -a 22 -D u-boot-stm32mp157c-ev1-trusted.img
> -$> dfu-util -d 0483:5720 -a 23 -D u-boot-stm32mp157c-ev1-trusted.img
> -$> dfu-util -d 0483:5720 -a 24 -D st-image-weston-openstlinux-weston-stm32mp1_nand_4_256_multivolume.ubi
> -
> -And you can also dump the OTP and the PMIC NVM with:
> -
> -$> dfu-util -d 0483:5720 -a 25 -U otp.bin
> -$> dfu-util -d 0483:5720 -a 26 -U pmic.bin
> +see doc/board/st/stm32mp1.rst
> diff --git a/doc/board/index.rst b/doc/board/index.rst
> index 00e72f57cd..21fddd2f92 100644
> --- a/doc/board/index.rst
> +++ b/doc/board/index.rst
> @@ -15,4 +15,5 @@ Board-specific doc
> intel/index
> renesas/index
> sifive/index
> + st/index
> xilinx/index
> diff --git a/doc/board/st/index.rst b/doc/board/st/index.rst
> new file mode 100644
> index 0000000000..91f1d51b42
> --- /dev/null
> +++ b/doc/board/st/index.rst
> @@ -0,0 +1,9 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +STMicroelectronics
> +==================
> +
> +.. toctree::
> + :maxdepth: 2
> +
> + stm32mp1
> diff --git a/doc/board/st/stm32mp1.rst b/doc/board/st/stm32mp1.rst
> new file mode 100644
> index 0000000000..131f4902a3
> --- /dev/null
> +++ b/doc/board/st/stm32mp1.rst
> @@ -0,0 +1,598 @@
> +.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> +.. sectionauthor:: Patrick Delaunay <patrick.delaunay@st.com>
> +
> +STM32MP15x boards
> +=================
> +
> +This is a quick instruction for setup STM32MP15x boards.
> +
> +Supported devices
> +-----------------
> +
> +U-Boot supports STMP32MP15x SoCs:
> + - STM32MP157
> + - STM32MP153
> + - STM32MP151
> +
> +The STM32MP15x is a Cortex-A MPU aimed at various applications.
> +
> +It features:
> + - Dual core Cortex-A7 application core (Single on STM32MP151)
> + - 2D/3D image composition with GPU (only on STM32MP157)
> + - Standard memories interface support
> + - Standard connectivity, widely inherited from the STM32 MCU family
> + - Comprehensive security support
> +
> +Everything is supported in Linux but U-Boot is limited to:
> + 1. UART
> + 2. SD card/MMC controller (SDMMC)
> + 3. NAND controller (FMC)
> + 4. NOR controller (QSPI)
> + 5. USB controller (OTG DWC2)
> + 6. Ethernet controller
> +
> +And the necessary drivers
> + 1. I2C
> + 2. STPMIC1 (PMIC and regulator)
> + 3. Clock, Reset, Sysreset
> + 4. Fuse
> +
> +Currently the following boards are supported:
> + + stm32mp157a-avenger96.dts
> + + stm32mp157a-dk1.dts
> + + stm32mp157c-dk2.dts
> + + stm32mp157c-ed1.dts
> + + stm32mp157c-ev1.dts
> +
> +Boot Sequences
> +--------------
> +
> +3 boot configurations are supported with:
> +
> ++----------+------------------------+-------------------------+--------------+
> +| **ROM** | **FSBL** | **SSBL** | **OS** |
> ++ **code** +------------------------+-------------------------+--------------+
> +| | First Stage Bootloader | Second Stage Bootloader | Linux Kernel |
> ++ +------------------------+-------------------------+--------------+
> +| | embedded RAM | DDR |
> ++----------+------------------------+-------------------------+--------------+
> +
> +The **Trusted** boot chain
> +``````````````````````````
> +
> +defconfig_file : stm32mp15_trusted_defconfig
> +
> + +-------------+-------------------------+------------+-------+
> + | ROM code | FSBL | SSBL | OS |
> + + +-------------------------+------------+-------+
> + | |Trusted Firmware-A (TF-A)| U-Boot | Linux |
> + +-------------+-------------------------+------------+-------+
> + | TrustZone |TF-A secure monitor |
> + +-------------+-------------------------+------------+-------+
> +
> +TF-A performs a full initialization of Secure peripherals and installs a
> +secure monitor (BL32=SPMin).
> +
> +U-Boot is running in normal world and uses TF-A monitor to access
> +to secure resources.
> +
> +The **Trusted** boot chain with **OP-TEE**
> +``````````````````````````````````````````
> +
> +defconfig_file : stm32mp15_optee_defconfig
> +
> + +-------------+-------------------------+------------+-------+
> + | ROM code | FSBL | SSBL | OS |
> + + +-------------------------+------------+-------+
> + | |Trusted Firmware-A (TF-A)| U-Boot | Linux |
> + +-------------+-------------------------+------------+-------+
> + | TrustZone |OP-TEE |
> + +-------------+-------------------------+------------+-------+
> +
> +TF-A performs a full initialization of Secure peripherals and installs OP-TEE
> +from specific partitions (teeh, teed, teex).
> +
> +U-Boot is running in normal world and uses OP-TEE monitor to access
> +to secure resources.
> +
> +The **Basic** boot chain
> +````````````````````````
> +
> +defconfig_file : stm32mp15_basic_defconfig
> +
> + +-------------+------------+------------+-------+
> + | ROM code | FSBL | SSBL | OS |
> + + +------------+------------+-------+
> + | |U-Boot SPL | U-Boot | Linux |
> + +-------------+------------+------------+-------+
> + | TrustZone | | PSCI from U-Boot |
> + +-------------+------------+------------+-------+
> +
> +SPL has limited security initialization
> +
> +U-Boot is running in secure mode and provide a secure monitor to the kernel
> +with only PSCI support (Power State Coordination Interface defined by ARM).
> +
> +All the STM32MP15x boards supported by U-Boot use the same generic board
> +stm32mp1 which support all the bootable devices.
> +
> +Each board is configured only with the associated device tree.
> +
> +Device Tree Selection
> +---------------------
> +
> +You need to select the appropriate device tree for your board,
> +the supported device trees for STM32MP15x are:
> +
> ++ ev1: eval board with pmic stpmic1 (ev1 = mother board + daughter ed1)
> + + stm32mp157c-ev1
> +
> ++ ed1: daughter board with pmic stpmic1
> + + stm32mp157c-ed1
> +
> ++ dk1: Discovery board
> + + stm32mp157a-dk1
> +
> ++ dk2: Discovery board = dk1 with a BT/WiFI combo and a DSI panel
> + + stm32mp157c-dk2
> +
> ++ avenger96: Avenger96 board from Arrow Electronics
> + + stm32mp157a-avenger96
> +
> +Build Procedure
> +---------------
> +
> +1. Install the required tools for U-Boot
> +
> + * install package needed in U-Boot makefile
> + (libssl-dev, swig, libpython-dev...)
> +
> + * install ARMv7 toolchain for 32bit Cortex-A (from Linaro,
> + from SDK for STM32MP15x, or any crosstoolchains from your distribution)
> + (you can use any gcc cross compiler compatible with U-Boot)
> +
> +2. Set the cross compiler::
> +
> + # export CROSS_COMPILE=/path/to/toolchain/arm-linux-gnueabi-
> +
> +3. Select the output directory (optional)::
> +
> + # export KBUILD_OUTPUT=/path/to/output
> +
> + for example: use one output directory for each configuration::
> +
> + # export KBUILD_OUTPUT=stm32mp15_trusted
> + # export KBUILD_OUTPUT=stm32mp15_optee
> + # export KBUILD_OUTPUT=stm32mp15_basic
> +
> + you can build outside of code directory::
> +
> + # export KBUILD_OUTPUT=../build/stm32mp15_trusted
> +
> +4. Configure U-Boot::
> +
> + # make <defconfig_file>
> +
> + with <defconfig_file>:
> +
> + - For **trusted** boot mode : **stm32mp15_trusted_defconfig**
> + - For **trusted** with OP-TEE boot mode : **stm32mp15_optee_defconfig**
> + - For basic boot mode: stm32mp15_basic_defconfig
> +
> +5. Configure the device-tree and build the U-Boot image::
> +
> + # make DEVICE_TREE=<name> all
> +
> + Examples:
> +
> + a) trusted boot on ev1::
> +
> + # export KBUILD_OUTPUT=stm32mp15_trusted
> + # make stm32mp15_trusted_defconfig
> + # make DEVICE_TREE=stm32mp157c-ev1 all
> +
> + b) trusted with OP-TEE boot on dk2::
> +
> + # export KBUILD_OUTPUT=stm32mp15_optee
> + # make stm32mp15_optee_defconfig
> + # make DEVICE_TREE=stm32mp157c-dk2 all
> +
> + c) basic boot on ev1::
> +
> + # export KBUILD_OUTPUT=stm32mp15_basic
> + # make stm32mp15_basic_defconfig
> + # make DEVICE_TREE=stm32mp157c-ev1 all
> +
> + d) basic boot on ed1::
> +
> + # export KBUILD_OUTPUT=stm32mp15_basic
> + # make stm32mp15_basic_defconfig
> + # make DEVICE_TREE=stm32mp157c-ed1 all
> +
> + e) basic boot on dk1::
> +
> + # export KBUILD_OUTPUT=stm32mp15_basic
> + # make stm32mp15_basic_defconfig
> + # make DEVICE_TREE=stm32mp157a-dk1 all
> +
> + f) basic boot on avenger96::
> +
> + # export KBUILD_OUTPUT=stm32mp15_basic
> + # make stm32mp15_basic_defconfig
> + # make DEVICE_TREE=stm32mp157a-avenger96 all
> +
> +6. Output files
> +
> + BootRom and TF-A expect binaries with STM32 image header
> + SPL expects file with U-Boot uImage header
> +
> + So in the output directory (selected by KBUILD_OUTPUT),
> + you can found the needed files:
> +
> + - For **Trusted** boot (with or without OP-TEE)
> + - FSBL = **tf-a.stm32** (provided by TF-A compilation)
> + - SSBL = **u-boot.stm32**
> +
> + - For Basic boot
> + - FSBL = spl/u-boot-spl.stm32
> + - SSBL = u-boot.img
> +
> +Switch Setting for Boot Mode
> +----------------------------
> +
> +You can select the boot mode, on the board with one switch, to select
> +the boot pin values = BOOT0, BOOT1, BOOT2
> +
> + +-------------+---------+---------+---------+
> + |*Boot Mode* | *BOOT2* | *BOOT1* | *BOOT0* |
> + +=============+=========+=========+=========+
> + | Recovery | 0 | 0 | 0 |
> + +-------------+---------+---------+---------+
> + | NOR | 0 | 0 | 1 |
> + +-------------+---------+---------+---------+
> + | eMMC | 0 | 1 | 0 |
> + +-------------+---------+---------+---------+
> + | NAND | 0 | 1 | 1 |
> + +-------------+---------+---------+---------+
> + | Reserved | 1 | 0 | 0 |
> + +-------------+---------+---------+---------+
> + | SD-Card | 1 | 0 | 1 |
> + +-------------+---------+---------+---------+
> + | Recovery | 1 | 1 | 0 |
> + +-------------+---------+---------+---------+
> + | SPI-NAND | 1 | 1 | 1 |
> + +-------------+---------+---------+---------+
> +
> +- on the **daugther board ed1 = MB1263** with the switch SW1
> +- on **Avenger96** with switch S3 (NOR and SPI-NAND are not applicable)
> +- on board **DK1/DK2** with the switch SW1 = BOOT0, BOOT2
> + with only 2 pins available (BOOT1 is forced to 0 and NOR not supported),
> + the possible value becomes:
> +
> + +-------------+---------+---------+
> + |*Boot Mode* | *BOOT2* | *BOOT0* |
> + +=============+=========+=========+
> + | Recovery | 0 | 0 |
> + +-------------+---------+---------+
> + | NOR (NA)| 0 | 1 |
> + +-------------+---------+---------+
> + | Reserved | 1 | 0 |
> + +-------------+---------+---------+
> + | SD-Card | 1 | 1 |
> + +-------------+---------+---------+
> +
> +Recovery is a boot from serial link (UART/USB) and it is used with
> +STM32CubeProgrammer tool to load executable in RAM and to update the flash
> +devices available on the board (NOR/NAND/eMMC/SD card).
> +
> +The communication between HOST and board is based on
> + - for UARTs : the uart protocol used with all MCU STM32
> + - for USB : based on USB DFU 1.1 (without the ST extensions used on MCU STM32)
> +
> +Prepare an SD card
> +------------------
> +
> +The minimal requirements for STMP32MP15x boot up to U-Boot are:
> +
> +- GPT partitioning (with gdisk or with sgdisk)
> +- 2 fsbl partitions, named fsbl1 and fsbl2, size at least 256KiB
> +- one ssbl partition for U-Boot
> +
> +Then the minimal GPT partition is:
> +
> + +-------+--------+---------+-------------+
> + | *Num* | *Name* | *Size* | *Content* |
> + +=======+========+=========+=============+
> + | 1 | fsbl1 | 256 KiB | TF-A or SPL |
> + +-------+--------+---------+-------------+
> + | 2 | fsbl2 | 256 KiB | TF-A or SPL |
> + +-------+--------+---------+-------------+
> + | 3 | ssbl | enought | U-Boot |
> + +-------+--------+---------+-------------+
> + | 4 | <any> | <any> | Rootfs |
> + +-------+--------+---------+-------------+
> +
> +Add a 4th partition (Rootfs) marked bootable with a file extlinux.conf
> +following the Generic Distribution feature (doc/README.distro for use).
> +
> +According the used card reader select the correct block device
> +(for example /dev/sdx or /dev/mmcblk0).
> +
> +In the next example, it is /dev/mmcblk0
> +
> +For example: with gpt table with 128 entries
> +
> +a) remove previous formatting::
> +
> + # sgdisk -o /dev/<SD card dev>
> +
> +b) create minimal image::
> +
> + # sgdisk --resize-table=128 -a 1 \
> + -n 1:34:545 -c 1:fsbl1 \
> + -n 2:546:1057 -c 2:fsbl2 \
> + -n 3:1058:5153 -c 3:ssbl \
> + -n 4:5154: -c 4:rootfs \
> + -p /dev/<SD card dev>
> +
> + With other partition for kernel one partition rootfs for kernel.
> +
> +c) copy the FSBL (2 times) and SSBL file on the correct partition.
> + in this example in partition 1 to 3
> +
> + for basic boot mode : <SD card dev> = /dev/mmcblk0::
> +
> + # dd if=u-boot-spl.stm32 of=/dev/mmcblk0p1
> + # dd if=u-boot-spl.stm32 of=/dev/mmcblk0p2
> + # dd if=u-boot.img of=/dev/mmcblk0p3
> +
> + for trusted boot mode: ::
> +
> + # dd if=tf-a.stm32 of=/dev/mmcblk0p1
> + # dd if=tf-a.stm32 of=/dev/mmcblk0p2
> + # dd if=u-boot.stm32 of=/dev/mmcblk0p3
> +
> +To boot from SD card, select BootPinMode = 1 0 1 and reset.
> +
> +Prepare eMMC
> +------------
> +
> +You can use U-Boot to copy binary in eMMC.
> +
> +In the next example, you need to boot from SD card and the images
> +(u-boot-spl.stm32, u-boot.img) are presents on SD card (mmc 0)
> +in ext4 partition 4 (bootfs).
> +
> +To boot from SD card, select BootPinMode = 1 0 1 and reset.
> +
> +Then you update the eMMC with the next U-Boot command :
> +
> +a) prepare GPT on eMMC,
> + example with 2 partitions, bootfs and roots::
> +
> + # setenv emmc_part "name=ssbl,size=2MiB;name=bootfs,type=linux,bootable,size=64MiB;name=rootfs,type=linux,size=512"
> + # gpt write mmc 1 ${emmc_part}
> +
> +b) copy SPL on eMMC on firts boot partition
> + (SPL max size is 256kB, with LBA 512, 0x200)::
> +
> + # ext4load mmc 0:4 0xC0000000 u-boot-spl.stm32
> + # mmc dev 1
> + # mmc partconf 1 1 1 1
> + # mmc write ${fileaddr} 0 200
> + # mmc partconf 1 1 1 0
> +
> +c) copy U-Boot in first GPT partition of eMMC::
> +
> + # ext4load mmc 0:4 0xC0000000 u-boo t.img
> + # mmc dev 1
> + # part start mmc 1 1 partstart
> + # mmc write ${fileaddr} ${partstart} ${filesize}
> +
> +To boot from eMMC, select BootPinMode = 0 1 0 and reset.
> +
> +MAC Address
> +-----------
> +
> +Please read doc/README.enetaddr for the implementation guidelines for mac id
> +usage. Basically, environment has precedence over board specific storage.
> +
> +For STMicroelectonics board, it is retrieved in STM32MP15x OTP :
> + - OTP_57[31:0] = MAC_ADDR[31:0]
> + - OTP_58[15:0] = MAC_ADDR[47:32]
> +
> +To program a MAC address on virgin OTP words above, you can use the fuse command
> +on bank 0 to access to internal OTP:
> +
> +Prerequisite: check if a MAC address isn't yet programmed in OTP
> +
> +1) check OTP: their value must be equal to 0
> +
> + STM32MP> fuse sense 0 57 2
> + Sensing bank 0:
> + Word 0x00000039: 00000000 00000000
> +
> +2) check environment variable
> +
> + STM32MP> env print ethaddr
> + ## Error: "ethaddr" not defined
> +
> +Example to set mac address "12:34:56:78:9a:bc"
> +
> +1) Write OTP::
> +
> + STM32MP> fuse prog -y 0 57 0x78563412 0x0000bc9a
> +
> +2) Read OTP::
> +
> + STM32MP> fuse sense 0 57 2
> + Sensing bank 0:
> + Word 0x00000039: 78563412 0000bc9a
> +
> +3) next REBOOT, in the trace::
> +
> + ### Setting environment from OTP MAC address = "12:34:56:78:9a:bc"
> +
> +4) check env update::
> +
> + STM32MP> env print ethaddr
> + ethaddr=12:34:56:78:9a:bc
> +
> +.. warning:: This command can't be executed twice on the same board as
> + OTP are protected. It is already done for the board
> + provided by STMicroelectronics.
> +
> +Coprocessor firmware
> +--------------------
> +
> +U-Boot can boot the coprocessor before the kernel (coprocessor early boot).
> +
> +a) Manuallly by using rproc commands (update the bootcmd)
> +
> + Configurations::
> +
> + # env set name_copro "rproc-m4-fw.elf"
> + # env set dev_copro 0
> + # env set loadaddr_copro 0xC1000000
> +
> + Load binary from bootfs partition (number 4) on SD card (mmc 0)::
> +
> + # ext4load mmc 0:4 ${loadaddr_copro} ${name_copro}
> +
> + => ${filesize} variable is updated with the size of the loaded file.
> +
> + Start M4 firmware with remote proc command::
> +
> + # rproc init
> + # rproc load ${dev_copro} ${loadaddr_copro} ${filesize}
> + # rproc start ${dev_copro}"00270033
> +
> +b) Automatically by using FIT feature and generic DISTRO bootcmd
> +
> + see examples in the board stm32mp1 directory: fit_copro_kernel_dtb.its
> +
> + Generate FIT including kernel + device tree + M4 firmware with cfg with M4 boot::
> +
> + $> mkimage -f fit_copro_kernel_dtb.its fit_copro_kernel_dtb.itb
> +
> + Then using DISTRO configuration file: see extlinux.conf to select the correct
> + configuration:
> +
> + - stm32mp157c-ev1-m4
> + - stm32mp157c-dk2-m4
> +
> +DFU support
> +-----------
> +
> +The DFU is supported on ST board.
> +
> +The env variable dfu_alt_info is automatically build, and all
> +the memory present on the ST boards are exported.
> +
> +The dfu mode is started by the command::
> +
> + STM32MP> dfu 0
> +
> +On EV1 board, booting from SD card, without OP-TEE::
> +
> + STM32MP> dfu 0 list
> + DFU alt settings list:
> + dev: RAM alt: 0 name: uImage layout: RAM_ADDR
> + dev: RAM alt: 1 name: devicetree.dtb layout: RAM_ADDR
> + dev: RAM alt: 2 name: uramdisk.image.gz layout: RAM_ADDR
> + dev: eMMC alt: 3 name: sdcard_fsbl1 layout: RAW_ADDR
> + dev: eMMC alt: 4 name: sdcard_fsbl2 layout: RAW_ADDR
> + dev: eMMC alt: 5 name: sdcard_ssbl layout: RAW_ADDR
> + dev: eMMC alt: 6 name: sdcard_bootfs layout: RAW_ADDR
> + dev: eMMC alt: 7 name: sdcard_vendorfs layout: RAW_ADDR
> + dev: eMMC alt: 8 name: sdcard_rootfs layout: RAW_ADDR
> + dev: eMMC alt: 9 name: sdcard_userfs layout: RAW_ADDR
> + dev: eMMC alt: 10 name: emmc_fsbl1 layout: RAW_ADDR
> + dev: eMMC alt: 11 name: emmc_fsbl2 layout: RAW_ADDR
> + dev: eMMC alt: 12 name: emmc_ssbl layout: RAW_ADDR
> + dev: eMMC alt: 13 name: emmc_bootfs layout: RAW_ADDR
> + dev: eMMC alt: 14 name: emmc_vendorfs layout: RAW_ADDR
> + dev: eMMC alt: 15 name: emmc_rootfs layout: RAW_ADDR
> + dev: eMMC alt: 16 name: emmc_userfs layout: RAW_ADDR
> + dev: MTD alt: 17 name: nor_fsbl1 layout: RAW_ADDR
> + dev: MTD alt: 18 name: nor_fsbl2 layout: RAW_ADDR
> + dev: MTD alt: 19 name: nor_ssbl layout: RAW_ADDR
> + dev: MTD alt: 20 name: nor_env layout: RAW_ADDR
> + dev: MTD alt: 21 name: nand_fsbl layout: RAW_ADDR
> + dev: MTD alt: 22 name: nand_ssbl1 layout: RAW_ADDR
> + dev: MTD alt: 23 name: nand_ssbl2 layout: RAW_ADDR
> + dev: MTD alt: 24 name: nand_UBI layout: RAW_ADDR
> + dev: VIRT alt: 25 name: OTP layout: RAW_ADDR
> + dev: VIRT alt: 26 name: PMIC layout: RAW_ADDR
> +
> +All the supported device are exported for dfu-util tool::
> +
> + $> dfu-util -l
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=26, name="PMIC", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=25, name="OTP", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=24, name="nand_UBI", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=23, name="nand_ssbl2", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=22, name="nand_ssbl1", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=21, name="nand_fsbl", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=20, name="nor_env", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=19, name="nor_ssbl", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=18, name="nor_fsbl2", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=17, name="nor_fsbl1", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=16, name="emmc_userfs", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=15, name="emmc_rootfs", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=14, name="emmc_vendorfs", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=13, name="emmc_bootfs", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=12, name="emmc_ssbl", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=11, name="emmc_fsbl2", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=10, name="emmc_fsbl1", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=9, name="sdcard_userfs", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=8, name="sdcard_rootfs", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=7, name="sdcard_vendorfs", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=6, name="sdcard_bootfs", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=5, name="sdcard_ssbl", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=4, name="sdcard_fsbl2", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=3, name="sdcard_fsbl1", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=2, name="uramdisk.image.gz", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=1, name="devicetree.dtb", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=0, name="uImage", serial="002700333338511934383330"
> +
> +You can update the boot device:
> +
> +- SD card (mmc0) ::
> +
> + $> dfu-util -d 0483:5720 -a 3 -D tf-a-stm32mp157c-ev1-trusted.stm32
> + $> dfu-util -d 0483:5720 -a 4 -D tf-a-stm32mp157c-ev1-trusted.stm32
> + $> dfu-util -d 0483:5720 -a 5 -D u-boot-stm32mp157c-ev1-trusted.img
> + $> dfu-util -d 0483:5720 -a 6 -D st-image-bootfs-openstlinux-weston-stm32mp1.ext4
> + $> dfu-util -d 0483:5720 -a 7 -D st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
> + $> dfu-util -d 0483:5720 -a 8 -D st-image-weston-openstlinux-weston-stm32mp1.ext4
> + $> dfu-util -d 0483:5720 -a 9 -D st-image-userfs-openstlinux-weston-stm32mp1.ext4
> +
> +- EMMC (mmc1)::
> +
> + $> dfu-util -d 0483:5720 -a 10 -D tf-a-stm32mp157c-ev1-trusted.stm32
> + $> dfu-util -d 0483:5720 -a 11 -D tf-a-stm32mp157c-ev1-trusted.stm32
> + $> dfu-util -d 0483:5720 -a 12 -D u-boot-stm32mp157c-ev1-trusted.img
> + $> dfu-util -d 0483:5720 -a 13 -D st-image-bootfs-openstlinux-weston-stm32mp1.ext4
> + $> dfu-util -d 0483:5720 -a 14 -D st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
> + $> dfu-util -d 0483:5720 -a 15 -D st-image-weston-openstlinux-weston-stm32mp1.ext4
> + $> dfu-util -d 0483:5720 -a 16 -D st-image-userfs-openstlinux-weston-stm32mp1.ext4
> +
> +- NOR::
> +
> + $> dfu-util -d 0483:5720 -a 17 -D tf-a-stm32mp157c-ev1-trusted.stm32
> + $> dfu-util -d 0483:5720 -a 18 -D tf-a-stm32mp157c-ev1-trusted.stm32
> + $> dfu-util -d 0483:5720 -a 19 -D u-boot-stm32mp157c-ev1-trusted.img
> +
> +- NAND (UBI partition used for NAND only boot or NOR + NAND boot)::
> +
> + $> dfu-util -d 0483:5720 -a 21 -D tf-a-stm32mp157c-ev1-trusted.stm32
> + $> dfu-util -d 0483:5720 -a 22 -D u-boot-stm32mp157c-ev1-trusted.img
> + $> dfu-util -d 0483:5720 -a 23 -D u-boot-stm32mp157c-ev1-trusted.img
> + $> dfu-util -d 0483:5720 -a 24 -D st-image-weston-openstlinux-weston-stm32mp1_nand_4_256_multivolume.ubi
> +
> +- you can also dump the OTP and the PMIC NVM with::
> +
> + $> dfu-util -d 0483:5720 -a 25 -U otp.bin
> + $> dfu-util -d 0483:5720 -a 26 -U pmic.bin
> +
This blank line could be removed.
'make html' shows that the reStructured text files are syntactically valid.
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R
2020-01-28 9:11 ` [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R Patrick Delaunay
@ 2020-01-28 12:15 ` Marek Vasut
2020-01-29 16:51 ` Patrick DELAUNAY
2020-02-13 8:12 ` [Uboot-stm32] " Patrice CHOTARD
2020-02-14 10:26 ` Patrick DELAUNAY
2 siblings, 1 reply; 38+ messages in thread
From: Marek Vasut @ 2020-01-28 12:15 UTC (permalink / raw)
To: u-boot
On 1/28/20 10:11 AM, Patrick Delaunay wrote:
> From: Antonio Borneo <antonio.borneo@st.com>
>
> LTDC modifies the clock frequency to adapt it to the display. Such
> frequency change is not detected by the FDCAN driver that instead
> cache the value at probe and pretend to use it later.
>
> Keep the LTDC alone on PLL4_Q by moving the FDCAN to PLL4_R.
Now this looks like a grisly workaround. Can you fix the LTDC driver to
do something sane on boards which didn't update bootloader yet ?
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R
2020-01-28 12:15 ` Marek Vasut
@ 2020-01-29 16:51 ` Patrick DELAUNAY
2020-01-30 2:23 ` Marek Vasut
0 siblings, 1 reply; 38+ messages in thread
From: Patrick DELAUNAY @ 2020-01-29 16:51 UTC (permalink / raw)
To: u-boot
Hi Marek,
> From: Marek Vasut <marex@denx.de>
> Sent: mardi 28 janvier 2020 13:16
>
> On 1/28/20 10:11 AM, Patrick Delaunay wrote:
> > From: Antonio Borneo <antonio.borneo@st.com>
> >
> > LTDC modifies the clock frequency to adapt it to the display. Such
> > frequency change is not detected by the FDCAN driver that instead
> > cache the value at probe and pretend to use it later.
> >
> > Keep the LTDC alone on PLL4_Q by moving the FDCAN to PLL4_R.
>
> Now this looks like a grisly workaround. Can you fix the LTDC driver to do
> something sane on boards which didn't update bootloader yet ?
In fact it more a issue in the initial clock-tree used when I upstream the ST board the first time... based on our delivery v1.0.0
It is already corrected in downstream on v1.1.0:
+ For U-Boot = https://github.com/STMicroelectronics/u-boot/commit/d62f14dece32e41c2854b9ff44aca7b8384aa8a0
+ For TF-A = https://github.com/STMicroelectronics/arm-trusted-firmware/commit/9a24ceda6c3ba060d9acf2b26d069fedde9f0807
The LTDC/DSI need to set the pixel clock according the panel configuration and settings: it is normal and needed.
But If the pixel clock is shared with FDCAN, which expects that its input clock is fixed, an issue occur when the pixel clock change.
We could add protection in FDCAN driver (don't assume fixed clock in probe for example)
but anyway that don't protect for any issue (pending FDCAN transfer when pixel clock change).
The main issue is that we try to share a clock source between 2 IP that are not compatible:
1/ FDCAN => clock source configurated by CLK_FDCAN_PLL4Q
2/ pixel clocl for LTDC and DSI = LTDC_PX or DSI_PX => _PLL4_Q (hardcoded in RCC)
The clock source for pixel clock PLL4_Q need only managed only by LDTC as it can modify the source clock.
It is why we decide to change the reference clock tree used on ST Microelectronic boards.
And unfortunately that impacts the first stage bootloader.
For information in our solution the clock tree is fixed and configurated at boot by first stage bootloader
(TF-A normally for trusted boot chain / SPL for basic boot chain) as this configuration is done in secured
registers with information provided by device-tree.
See https://wiki.st.com/stm32mpu/wiki/STM32MP15_clock_tree for details
Regards
Patrick
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R
2020-01-29 16:51 ` Patrick DELAUNAY
@ 2020-01-30 2:23 ` Marek Vasut
2020-01-31 8:15 ` Patrick DELAUNAY
0 siblings, 1 reply; 38+ messages in thread
From: Marek Vasut @ 2020-01-30 2:23 UTC (permalink / raw)
To: u-boot
On 1/29/20 5:51 PM, Patrick DELAUNAY wrote:
> Hi Marek,
Hi,
>> From: Marek Vasut <marex@denx.de>
>> Sent: mardi 28 janvier 2020 13:16
>>
>> On 1/28/20 10:11 AM, Patrick Delaunay wrote:
>>> From: Antonio Borneo <antonio.borneo@st.com>
>>>
>>> LTDC modifies the clock frequency to adapt it to the display. Such
>>> frequency change is not detected by the FDCAN driver that instead
>>> cache the value at probe and pretend to use it later.
>>>
>>> Keep the LTDC alone on PLL4_Q by moving the FDCAN to PLL4_R.
>>
>> Now this looks like a grisly workaround. Can you fix the LTDC driver to do
>> something sane on boards which didn't update bootloader yet ?
>
> In fact it more a issue in the initial clock-tree used when I upstream the ST board the first time... based on our delivery v1.0.0
>
> It is already corrected in downstream on v1.1.0:
> + For U-Boot = https://github.com/STMicroelectronics/u-boot/commit/d62f14dece32e41c2854b9ff44aca7b8384aa8a0
> + For TF-A = https://github.com/STMicroelectronics/arm-trusted-firmware/commit/9a24ceda6c3ba060d9acf2b26d069fedde9f0807
>
> The LTDC/DSI need to set the pixel clock according the panel configuration and settings: it is normal and needed.
>
> But If the pixel clock is shared with FDCAN, which expects that its input clock is fixed, an issue occur when the pixel clock change.
I understand the problem you are trying to solve.
What I think you are missing is that not everyone will update
ATF/U-Boot/Linux in lockstep. That is the problem you need to deal with
here.
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R
2020-01-30 2:23 ` Marek Vasut
@ 2020-01-31 8:15 ` Patrick DELAUNAY
2020-02-02 17:28 ` Marek Vasut
0 siblings, 1 reply; 38+ messages in thread
From: Patrick DELAUNAY @ 2020-01-31 8:15 UTC (permalink / raw)
To: u-boot
Hi Marek,
> From: Marek Vasut <marex@denx.de>
> Sent: jeudi 30 janvier 2020 03:23
>
> On 1/29/20 5:51 PM, Patrick DELAUNAY wrote:
> > Hi Marek,
>
> Hi,
>
> >> From: Marek Vasut <marex@denx.de>
> >> Sent: mardi 28 janvier 2020 13:16
> >>
> >> On 1/28/20 10:11 AM, Patrick Delaunay wrote:
> >>> From: Antonio Borneo <antonio.borneo@st.com>
> >>>
> >>> LTDC modifies the clock frequency to adapt it to the display. Such
> >>> frequency change is not detected by the FDCAN driver that instead
> >>> cache the value at probe and pretend to use it later.
> >>>
> >>> Keep the LTDC alone on PLL4_Q by moving the FDCAN to PLL4_R.
> >>
> >> Now this looks like a grisly workaround. Can you fix the LTDC driver
> >> to do something sane on boards which didn't update bootloader yet ?
> >
> > In fact it more a issue in the initial clock-tree used when I upstream
> > the ST board the first time... based on our delivery v1.0.0
> >
> > It is already corrected in downstream on v1.1.0:
> > + For U-Boot =
> > + https://github.com/STMicroelectronics/u-boot/commit/d62f14dece32e41c
> > + 2854b9ff44aca7b8384aa8a0 For TF-A =
> > + https://github.com/STMicroelectronics/arm-trusted-firmware/commit/9a
> > + 24ceda6c3ba060d9acf2b26d069fedde9f0807
> >
> > The LTDC/DSI need to set the pixel clock according the panel configuration and
> settings: it is normal and needed.
> >
> > But If the pixel clock is shared with FDCAN, which expects that its input clock is
> fixed, an issue occur when the pixel clock change.
>
> I understand the problem you are trying to solve.
>
> What I think you are missing is that not everyone will update ATF/U-Boot/Linux in
> lockstep. That is the problem you need to deal with here.
I understood the possible issue and I hope that I will be not the case
(at least for the ST Microelectronics boards).
We are aware of the possible issue to fixe these clocks in first stage bootloader but after a long
debate, we don't found a better solution, with the constraints:
- M4 firmware require clock initialization before start and it can be loaded by U-Boot
- clock tree is generated by CubeMX tools which generate device tree (for bootloaders and kernel)
- "assigned-clock" management in Linux kernel could lead us to a race condition for shared clock
We spent a long time to found a clock tree which respect all the constraints of the SOC
before to our first release v1.0 and before I upstream the stm32mp1 support in U-Boot.
Then I wait a year before to upstream the patches on clock tree initialization (and the second
release v1.2) to avoid too many iteration.
And this patch on FDCAN is the only issue found on the initial clock tree.
Today I think (hope?) it will be the last patch on this part.
Regards
Patrick
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R
2020-01-31 8:15 ` Patrick DELAUNAY
@ 2020-02-02 17:28 ` Marek Vasut
2020-02-04 13:16 ` Patrick DELAUNAY
0 siblings, 1 reply; 38+ messages in thread
From: Marek Vasut @ 2020-02-02 17:28 UTC (permalink / raw)
To: u-boot
On 1/31/20 9:15 AM, Patrick DELAUNAY wrote:
> Hi Marek,
Hi,
>> From: Marek Vasut <marex@denx.de>
>> Sent: jeudi 30 janvier 2020 03:23
>>
>> On 1/29/20 5:51 PM, Patrick DELAUNAY wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>>>> From: Marek Vasut <marex@denx.de>
>>>> Sent: mardi 28 janvier 2020 13:16
>>>>
>>>> On 1/28/20 10:11 AM, Patrick Delaunay wrote:
>>>>> From: Antonio Borneo <antonio.borneo@st.com>
>>>>>
>>>>> LTDC modifies the clock frequency to adapt it to the display. Such
>>>>> frequency change is not detected by the FDCAN driver that instead
>>>>> cache the value at probe and pretend to use it later.
>>>>>
>>>>> Keep the LTDC alone on PLL4_Q by moving the FDCAN to PLL4_R.
>>>>
>>>> Now this looks like a grisly workaround. Can you fix the LTDC driver
>>>> to do something sane on boards which didn't update bootloader yet ?
>>>
>>> In fact it more a issue in the initial clock-tree used when I upstream
>>> the ST board the first time... based on our delivery v1.0.0
>>>
>>> It is already corrected in downstream on v1.1.0:
>>> + For U-Boot =
>>> + https://github.com/STMicroelectronics/u-boot/commit/d62f14dece32e41c
>>> + 2854b9ff44aca7b8384aa8a0 For TF-A =
>>> + https://github.com/STMicroelectronics/arm-trusted-firmware/commit/9a
>>> + 24ceda6c3ba060d9acf2b26d069fedde9f0807
>>>
>>> The LTDC/DSI need to set the pixel clock according the panel configuration and
>> settings: it is normal and needed.
>>>
>>> But If the pixel clock is shared with FDCAN, which expects that its input clock is
>> fixed, an issue occur when the pixel clock change.
>>
>> I understand the problem you are trying to solve.
>>
>> What I think you are missing is that not everyone will update ATF/U-Boot/Linux in
>> lockstep. That is the problem you need to deal with here.
>
> I understood the possible issue and I hope that I will be not the case
> (at least for the ST Microelectronics boards).
Do I understand it correctly that you expect the customers who buy the
ST chip to update bootloader in lockstep with the kernel in systems
which are deployed today ?
No, this does not work. If you have a working bootloader and your kernel
fails to start, that is something you can recover from, If your
bootloader fails to start and you need to dig an embedded system buried
who-knows-where or recall a lot of systems because of a failed
bootloader update, that would be a disaster.
> We are aware of the possible issue to fixe these clocks in first stage bootloader but after a long
> debate, we don't found a better solution, with the constraints:
> - M4 firmware require clock initialization before start and it can be loaded by U-Boot
> - clock tree is generated by CubeMX tools which generate device tree (for bootloaders and kernel)
> - "assigned-clock" management in Linux kernel could lead us to a race condition for shared clock
>
> We spent a long time to found a clock tree which respect all the constraints of the SOC
> before to our first release v1.0 and before I upstream the stm32mp1 support in U-Boot.
>
> Then I wait a year before to upstream the patches on clock tree initialization (and the second
> release v1.2) to avoid too many iteration.
> And this patch on FDCAN is the only issue found on the initial clock tree.
>
> Today I think (hope?) it will be the last patch on this part.
You will keep finding clock issues and no , this will not be the last
patch which fixes a clock issue.
So what solution is there for those who can only update the kernel ?
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R
2020-02-02 17:28 ` Marek Vasut
@ 2020-02-04 13:16 ` Patrick DELAUNAY
2020-02-05 2:23 ` Marek Vasut
0 siblings, 1 reply; 38+ messages in thread
From: Patrick DELAUNAY @ 2020-02-04 13:16 UTC (permalink / raw)
To: u-boot
Hi Marek
> From: Marek Vasut <marex@denx.de>
> Sent: dimanche 2 février 2020 18:28
>
> On 1/31/20 9:15 AM, Patrick DELAUNAY wrote:
> > Hi Marek,
>
> Hi,
>
> >> From: Marek Vasut <marex@denx.de>
> >> Sent: jeudi 30 janvier 2020 03:23
> >>
> >> On 1/29/20 5:51 PM, Patrick DELAUNAY wrote:
> >>> Hi Marek,
> >>
> >> Hi,
> >>
> >>>> From: Marek Vasut <marex@denx.de>
> >>>> Sent: mardi 28 janvier 2020 13:16
> >>>>
> >>>> On 1/28/20 10:11 AM, Patrick Delaunay wrote:
> >>>>> From: Antonio Borneo <antonio.borneo@st.com>
> >>>>>
> >>>>> LTDC modifies the clock frequency to adapt it to the display. Such
> >>>>> frequency change is not detected by the FDCAN driver that instead
> >>>>> cache the value at probe and pretend to use it later.
> >>>>>
> >>>>> Keep the LTDC alone on PLL4_Q by moving the FDCAN to PLL4_R.
> >>>>
> >>>> Now this looks like a grisly workaround. Can you fix the LTDC
> >>>> driver to do something sane on boards which didn't update bootloader yet ?
> >>>
> >>> In fact it more a issue in the initial clock-tree used when I
> >>> upstream the ST board the first time... based on our delivery v1.0.0
> >>>
> >>> It is already corrected in downstream on v1.1.0:
> >>> + For U-Boot =
> >>> + https://github.com/STMicroelectronics/u-boot/commit/d62f14dece32e4
> >>> + 1c
> >>> + 2854b9ff44aca7b8384aa8a0 For TF-A =
> >>> + https://github.com/STMicroelectronics/arm-trusted-firmware/commit/
> >>> + 9a
> >>> + 24ceda6c3ba060d9acf2b26d069fedde9f0807
> >>>
> >>> The LTDC/DSI need to set the pixel clock according the panel
> >>> configuration and
> >> settings: it is normal and needed.
> >>>
> >>> But If the pixel clock is shared with FDCAN, which expects that its
> >>> input clock is
> >> fixed, an issue occur when the pixel clock change.
> >>
> >> I understand the problem you are trying to solve.
> >>
> >> What I think you are missing is that not everyone will update
> >> ATF/U-Boot/Linux in lockstep. That is the problem you need to deal with here.
> >
> > I understood the possible issue and I hope that I will be not the case
> > (at least for the ST Microelectronics boards).
>
> Do I understand it correctly that you expect the customers who buy the ST chip to
> update bootloader in lockstep with the kernel in systems which are deployed today
> ?
>
> No, this does not work. If you have a working bootloader and your kernel fails to
> start, that is something you can recover from, If your bootloader fails to start and
> you need to dig an embedded system buried who-knows-where or recall a lot of
> systems because of a failed bootloader update, that would be a disaster.
No, we don't expect a bootloader updater for all the current customers.
We found this weakness in the clock tree configuration used in ST board
after our first delivery and we have already provide the patch (in downstream)
to clients. So we hope they already use this correction in the bootloaders
used in current products.
However this clock issue only occur for few case, when FDCAN and LTDC are
used in parallel on the boards and only if LTDC change the pixel clock.
So it should be occurs only for few customer and the issue is not blocking for
most of the cases.
> > We are aware of the possible issue to fixe these clocks in first stage
> > bootloader but after a long debate, we don't found a better solution, with the
> constraints:
> > - M4 firmware require clock initialization before start and it can be
> > loaded by U-Boot
> > - clock tree is generated by CubeMX tools which generate device tree
> > (for bootloaders and kernel)
> > - "assigned-clock" management in Linux kernel could lead us to a race
> > condition for shared clock
> >
> > We spent a long time to found a clock tree which respect all the
> > constraints of the SOC before to our first release v1.0 and before I upstream the
> stm32mp1 support in U-Boot.
> >
> > Then I wait a year before to upstream the patches on clock tree
> > initialization (and the second release v1.2) to avoid too many iteration.
> > And this patch on FDCAN is the only issue found on the initial clock tree.
> >
> > Today I think (hope?) it will be the last patch on this part.
>
> You will keep finding clock issues and no , this will not be the last patch which
> fixes a clock issue.
>
> So what solution is there for those who can only update the kernel ?
Yes, this issue can also solved by a patch in Linux DT to change the clock tree:
&m_can1 {
assigned-clocks = <&rcc FDCAN_K >;
assigned-clock-parents = <&rcc PLL4_R>;
};
It is the solution recommended for any customer which can't/wan't update the bootloaders.
And I agree that this issue also highlight a issue in the FDCAN driver, which should use
the API 'clk_rate_exclusive_get(clk)' to prevent modification by LTDC clock.
The current patch is only to provide a better "official" clock tree in U-Boot upstream,
as we known the ST board is used as reference by many client and also to align the clocks
used in downstream (https://github.com/STMicroelectronics/u-boot) and in upstream.
But if you prefer kept the current clock tree for DH PKD2 board (with potential issue on FDCAN),
I can revert my modification on stm32mp15xx-dhcom-pdk2-u-boot.dtsi.
I propose this modification only because it seems you have the same clock-tree than ST boards
(except CLK_ETH_PLL4P vs CLK_ETH_DISABLED but is is probably linked to the ethernet
PHY configuration)
Regards
Patrick
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R
2020-02-04 13:16 ` Patrick DELAUNAY
@ 2020-02-05 2:23 ` Marek Vasut
2020-02-06 8:59 ` Patrick DELAUNAY
0 siblings, 1 reply; 38+ messages in thread
From: Marek Vasut @ 2020-02-05 2:23 UTC (permalink / raw)
To: u-boot
On 2/4/20 2:16 PM, Patrick DELAUNAY wrote:
> Hi Marek
Hello Patrick,
[...]
>>>> What I think you are missing is that not everyone will update
>>>> ATF/U-Boot/Linux in lockstep. That is the problem you need to deal with here.
>>>
>>> I understood the possible issue and I hope that I will be not the case
>>> (at least for the ST Microelectronics boards).
>>
>> Do I understand it correctly that you expect the customers who buy the ST chip to
>> update bootloader in lockstep with the kernel in systems which are deployed today
>> ?
>>
>> No, this does not work. If you have a working bootloader and your kernel fails to
>> start, that is something you can recover from, If your bootloader fails to start and
>> you need to dig an embedded system buried who-knows-where or recall a lot of
>> systems because of a failed bootloader update, that would be a disaster.
>
> No, we don't expect a bootloader updater for all the current customers.
>
> We found this weakness in the clock tree configuration used in ST board
> after our first delivery and we have already provide the patch (in downstream)
> to clients. So we hope they already use this correction in the bootloaders
> used in current products.
Since it's not in mainline, they do not. Unless you expect that users of
the STM32MP1 will use some random downstream fork of vendoruboot.
> However this clock issue only occur for few case, when FDCAN and LTDC are
> used in parallel on the boards and only if LTDC change the pixel clock.
>
> So it should be occurs only for few customer and the issue is not blocking for
> most of the cases.
>
>>> We are aware of the possible issue to fixe these clocks in first stage
>>> bootloader but after a long debate, we don't found a better solution, with the
>> constraints:
>>> - M4 firmware require clock initialization before start and it can be
>>> loaded by U-Boot
>>> - clock tree is generated by CubeMX tools which generate device tree
>>> (for bootloaders and kernel)
>>> - "assigned-clock" management in Linux kernel could lead us to a race
>>> condition for shared clock
>>>
>>> We spent a long time to found a clock tree which respect all the
>>> constraints of the SOC before to our first release v1.0 and before I upstream the
>> stm32mp1 support in U-Boot.
>>>
>>> Then I wait a year before to upstream the patches on clock tree
>>> initialization (and the second release v1.2) to avoid too many iteration.
>>> And this patch on FDCAN is the only issue found on the initial clock tree.
>>>
>>> Today I think (hope?) it will be the last patch on this part.
>>
>> You will keep finding clock issues and no , this will not be the last patch which
>> fixes a clock issue.
>>
>> So what solution is there for those who can only update the kernel ?
>
> Yes, this issue can also solved by a patch in Linux DT to change the clock tree:
>
> &m_can1 {
> assigned-clocks = <&rcc FDCAN_K >;
> assigned-clock-parents = <&rcc PLL4_R>;
> };
>
> It is the solution recommended for any customer which can't/wan't update the bootloaders.
But this should be part of mainline Linux either way and possibly Linux
should print a BIG WARNING if such "weakness" is detected and fix it up,
otherwise some systems will become dependent on bootloader behavior and
once the behaviors diverge sufficiently, you will end up with a platform
which fails to boot.
If you want a physically embedded system to be deployed for 10+ years
somewhere and you want to keep updating it with latest kernel versions
(because security fixes and so on), then you can be sure a bootloader
update is not an option, because if the system stops working after such
an update, someone will have to go there and physically retrieve the
device and fix it, and that might be very expensive or impossible. If
you only update the kernel, then the bootloader can still be used to
recover even a failed kernel update.
> And I agree that this issue also highlight a issue in the FDCAN driver, which should use
> the API 'clk_rate_exclusive_get(clk)' to prevent modification by LTDC clock.
>
> The current patch is only to provide a better "official" clock tree in U-Boot upstream,
> as we known the ST board is used as reference by many client and also to align the clocks
> used in downstream (https://github.com/STMicroelectronics/u-boot) and in upstream.
I am _NOT_ opposed to this patch.
My problem is with the bootloader-Linux clock tree dependency. That
dependency should not exist or be minimized, otherwise you end up with a
very poor long-term experience, see above. And if you want for this
platform to be successful in the industrial/automotive deployments, then
you want to make sure the long-term experience is a good one.
> But if you prefer kept the current clock tree for DH PKD2 board (with potential issue on FDCAN),
> I can revert my modification on stm32mp15xx-dhcom-pdk2-u-boot.dtsi.
This has nothing to do with this board, or any other board, see above.
Patching this board is fine.
> I propose this modification only because it seems you have the same clock-tree than ST boards
> (except CLK_ETH_PLL4P vs CLK_ETH_DISABLED but is is probably linked to the ethernet
> PHY configuration)
No, keep the clock trees in sync as much as possible.
[...]
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R
2020-02-05 2:23 ` Marek Vasut
@ 2020-02-06 8:59 ` Patrick DELAUNAY
2020-02-06 9:10 ` Marek Vasut
0 siblings, 1 reply; 38+ messages in thread
From: Patrick DELAUNAY @ 2020-02-06 8:59 UTC (permalink / raw)
To: u-boot
Hi Marek,
> From: Marek Vasut <marex@denx.de>
> Sent: mercredi 5 février 2020 03:23
>
> On 2/4/20 2:16 PM, Patrick DELAUNAY wrote:
> > Hi Marek
>
> Hello Patrick,
>
> [...]
>
> >>>> What I think you are missing is that not everyone will update
> >>>> ATF/U-Boot/Linux in lockstep. That is the problem you need to deal with
> here.
> >>>
> >>> I understood the possible issue and I hope that I will be not the
> >>> case (at least for the ST Microelectronics boards).
> >>
> >> Do I understand it correctly that you expect the customers who buy
> >> the ST chip to update bootloader in lockstep with the kernel in
> >> systems which are deployed today ?
> >>
> >> No, this does not work. If you have a working bootloader and your
> >> kernel fails to start, that is something you can recover from, If
> >> your bootloader fails to start and you need to dig an embedded system
> >> buried who-knows-where or recall a lot of systems because of a failed
> bootloader update, that would be a disaster.
> >
> > No, we don't expect a bootloader updater for all the current customers.
> >
> > We found this weakness in the clock tree configuration used in ST
> > board after our first delivery and we have already provide the patch
> > (in downstream) to clients. So we hope they already use this
> > correction in the bootloaders used in current products.
>
> Since it's not in mainline, they do not. Unless you expect that users of the
> STM32MP1 will use some random downstream fork of vendoruboot.
Not random but official ST delivery, without any restriction.
Today Mainline (Linux / U-Boot / TF-A / OP-TEE) have still still restriction
(power support or security support for example) as we don't finish our upstream of
the STM32MP15x.
But we continue to push to have reduce the difference, to be sure that customer
can use soon indifferently the Mailine or our delivery.
> > However this clock issue only occur for few case, when FDCAN and LTDC
> > are used in parallel on the boards and only if LTDC change the pixel clock.
> >
> > So it should be occurs only for few customer and the issue is not
> > blocking for most of the cases.
> >
> >>> We are aware of the possible issue to fixe these clocks in first
> >>> stage bootloader but after a long debate, we don't found a better
> >>> solution, with the
> >> constraints:
> >>> - M4 firmware require clock initialization before start and it can
> >>> be loaded by U-Boot
> >>> - clock tree is generated by CubeMX tools which generate device tree
> >>> (for bootloaders and kernel)
> >>> - "assigned-clock" management in Linux kernel could lead us to a
> >>> race condition for shared clock
> >>>
> >>> We spent a long time to found a clock tree which respect all the
> >>> constraints of the SOC before to our first release v1.0 and before I
> >>> upstream the
> >> stm32mp1 support in U-Boot.
> >>>
> >>> Then I wait a year before to upstream the patches on clock tree
> >>> initialization (and the second release v1.2) to avoid too many iteration.
> >>> And this patch on FDCAN is the only issue found on the initial clock tree.
> >>>
> >>> Today I think (hope?) it will be the last patch on this part.
> >>
> >> You will keep finding clock issues and no , this will not be the last
> >> patch which fixes a clock issue.
> >>
> >> So what solution is there for those who can only update the kernel ?
> >
> > Yes, this issue can also solved by a patch in Linux DT to change the clock tree:
> >
> > &m_can1 {
> > assigned-clocks = <&rcc FDCAN_K >;
> > assigned-clock-parents = <&rcc PLL4_R>; };
> >
> > It is the solution recommended for any customer which can't/wan't update the
> bootloaders.
>
> But this should be part of mainline Linux either way and possibly Linux should print
> a BIG WARNING if such "weakness" is detected and fix it up, otherwise some
> systems will become dependent on bootloader behavior and once the behaviors
> diverge sufficiently, you will end up with a platform which fails to boot.
I shared this point with Linux maintainers.
> If you want a physically embedded system to be deployed for 10+ years
> somewhere and you want to keep updating it with latest kernel versions (because
> security fixes and so on), then you can be sure a bootloader update is not an
> option, because if the system stops working after such an update, someone will
> have to go there and physically retrieve the device and fix it, and that might be
> very expensive or impossible. If you only update the kernel, then the bootloader
> can still be used to recover even a failed kernel update.
I agree.
> > And I agree that this issue also highlight a issue in the FDCAN
> > driver, which should use the API 'clk_rate_exclusive_get(clk)' to prevent
> modification by LTDC clock.
> >
> > The current patch is only to provide a better "official" clock tree in
> > U-Boot upstream, as we known the ST board is used as reference by many
> > client and also to align the clocks used in downstream
> (https://github.com/STMicroelectronics/u-boot) and in upstream.
>
> I am _NOT_ opposed to this patch.
Thanks, it is clear now 😉
> My problem is with the bootloader-Linux clock tree dependency. That dependency
> should not exist or be minimized, otherwise you end up with a very poor long-term
> experience, see above. And if you want for this platform to be successful in the
> industrial/automotive deployments, then you want to make sure the long-term
> experience is a good one.
With STM32MP15x SOC and RCC, very few clocks need to be fixed by bootloaders
(in fact more or less the root clocks of the system = frequency of PLL1 to PLL4,
common for many device or protected by security feature), I think it is the case for
any platform.
All the other clocks have a initial value / source provided by bootloaders but they can
also be modified at runtime (by device tree assigned-clock-parents for not secure clocks
and with SMC call to TF-A secure monitor for "secure" clock).
For ST boards, we are trying to don't modify the initial clock tree-source only to prove
that this clock tree is functional / correct for most of case.
But for client and after first deployment, clock tree modification must be done in Linux kernel
without any Bootloader update (and avoid all known issue for OTA).
I shared your concerns with my team and we are completely agree with you.
> > But if you prefer kept the current clock tree for DH PKD2 board (with
> > potential issue on FDCAN), I can revert my modification on stm32mp15xx-
> dhcom-pdk2-u-boot.dtsi.
>
> This has nothing to do with this board, or any other board, see above.
> Patching this board is fine.
>
> > I propose this modification only because it seems you have the same
> > clock-tree than ST boards (except CLK_ETH_PLL4P vs CLK_ETH_DISABLED
> > but is is probably linked to the ethernet PHY configuration)
>
> No, keep the clock trees in sync as much as possible.
OK, thanks
> [...]
Regards
Patrick
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R
2020-02-06 8:59 ` Patrick DELAUNAY
@ 2020-02-06 9:10 ` Marek Vasut
0 siblings, 0 replies; 38+ messages in thread
From: Marek Vasut @ 2020-02-06 9:10 UTC (permalink / raw)
To: u-boot
On 2/6/20 9:59 AM, Patrick DELAUNAY wrote:
> Hi Marek,
Hello Patrick
[...]
>> My problem is with the bootloader-Linux clock tree dependency. That dependency
>> should not exist or be minimized, otherwise you end up with a very poor long-term
>> experience, see above. And if you want for this platform to be successful in the
>> industrial/automotive deployments, then you want to make sure the long-term
>> experience is a good one.
>
> With STM32MP15x SOC and RCC, very few clocks need to be fixed by bootloaders
> (in fact more or less the root clocks of the system = frequency of PLL1 to PLL4,
> common for many device or protected by security feature), I think it is the case for
> any platform.
>
> All the other clocks have a initial value / source provided by bootloaders but they can
> also be modified at runtime (by device tree assigned-clock-parents for not secure clocks
> and with SMC call to TF-A secure monitor for "secure" clock).
>
> For ST boards, we are trying to don't modify the initial clock tree-source only to prove
> that this clock tree is functional / correct for most of case.
>
> But for client and after first deployment, clock tree modification must be done in Linux kernel
> without any Bootloader update (and avoid all known issue for OTA).
>
> I shared your concerns with my team and we are completely agree with you.
So, shall we expect a proper fix for the Linux kernel too ?
[...]
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 8/9] doc: add board documentation for stm32mp1
2020-01-28 11:34 ` Heinrich Schuchardt
@ 2020-02-10 11:02 ` Patrick DELAUNAY
0 siblings, 0 replies; 38+ messages in thread
From: Patrick DELAUNAY @ 2020-02-10 11:02 UTC (permalink / raw)
To: u-boot
Hi Heinrich
> From: Heinrich Schuchardt <xypron.glpk@gmx.de>
> Sent: mardi 28 janvier 2020 12:34
>
> On 1/28/20 10:11 AM, Patrick Delaunay wrote:
> > Change plain test README to rst format and move this file in
> > documentation directory.
> >
> > Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
>
> When I apply only this patch to origin/master:
>
> git am /tmp/1.patch
> Applying: doc: add board documentation for stm32mp1
> error: patch failed: board/st/stm32mp1/README:1
> error: board/st/stm32mp1/README: patch does not apply
> .git/rebase-apply/patch:1164: new blank line at EOF.
>
> Maybe this patch will have to be rebased.
I think the issue is because ethe readme is updated in the previous patch
[7/9] board: stm32mp1: update readme
=> I think I will get the board patch in my next pull request on stm32 and
then rebase this patch only.
> > ---
> >
> > board/st/stm32mp1/README | 520 +--------------------------------
> > doc/board/index.rst | 1 +
> > doc/board/st/index.rst | 9 +
> > doc/board/st/stm32mp1.rst | 598
> ++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 609 insertions(+), 519 deletions(-)
> > create mode 100644 doc/board/st/index.rst
> > create mode 100644 doc/board/st/stm32mp1.rst
> >
> > diff --git a/board/st/stm32mp1/README b/board/st/stm32mp1/README index
> > 5d7465a8c8..8172d26a66 100644
> > --- a/board/st/stm32mp1/README
> > +++ b/board/st/stm32mp1/README
> > @@ -1,519 +1 @@
> > -SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause -# -# Copyright (C)
> > 2018 STMicroelectronics - All Rights Reserved -#
> > -
> > -U-Boot on STMicroelectronics STM32MP15x
> > -=======================================
......
> > + bi
> > +
> > +- you can also dump the OTP and the PMIC NVM with::
> > +
> > + $> dfu-util -d 0483:5720 -a 25 -U otp.bin $> dfu-util -d 0483:5720
> > + -a 26 -U pmic.bin
> > +
>
> This blank line could be removed.
Ok => in V2 with rebase
>
> 'make html' shows that the reStructured text files are syntactically valid.
>
> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Thanks
Patrkc
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Uboot-stm32] [PATCH 1/9] ARM: dts: stm32mp1: DT alignment with kernel v5.4
2020-01-28 9:10 ` [PATCH 1/9] ARM: dts: stm32mp1: DT alignment with kernel v5.4 Patrick Delaunay
@ 2020-02-13 8:11 ` Patrice CHOTARD
2020-02-14 10:25 ` Patrick DELAUNAY
1 sibling, 0 replies; 38+ messages in thread
From: Patrice CHOTARD @ 2020-02-13 8:11 UTC (permalink / raw)
To: u-boot
On 1/28/20 10:10 AM, Patrick Delaunay wrote:
> Device tree and binding alignment with kernel v5.4
>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
> ---
>
> arch/arm/dts/stm32mp157-pinctrl.dtsi | 8 ++++----
> arch/arm/dts/stm32mp157c-ev1.dts | 5 ++---
> arch/arm/dts/stm32mp157c.dtsi | 4 ++--
> doc/device-tree-bindings/mtd/stm32-fmc2-nand.txt | 6 ++++--
> 4 files changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp157-pinctrl.dtsi b/arch/arm/dts/stm32mp157-pinctrl.dtsi
> index 0d53396119..07cd0809ff 100644
> --- a/arch/arm/dts/stm32mp157-pinctrl.dtsi
> +++ b/arch/arm/dts/stm32mp157-pinctrl.dtsi
> @@ -622,13 +622,13 @@
> <STM32_PINMUX('F', 6, AF9)>; /* QSPI_BK1_IO3 */
> bias-disable;
> drive-push-pull;
> - slew-rate = <3>;
> + slew-rate = <1>;
> };
> pins2 {
> pinmux = <STM32_PINMUX('B', 6, AF10)>; /* QSPI_BK1_NCS */
> bias-pull-up;
> drive-push-pull;
> - slew-rate = <3>;
> + slew-rate = <1>;
> };
> };
>
> @@ -650,13 +650,13 @@
> <STM32_PINMUX('G', 7, AF11)>; /* QSPI_BK2_IO3 */
> bias-disable;
> drive-push-pull;
> - slew-rate = <3>;
> + slew-rate = <1>;
> };
> pins2 {
> pinmux = <STM32_PINMUX('C', 0, AF10)>; /* QSPI_BK2_NCS */
> bias-pull-up;
> drive-push-pull;
> - slew-rate = <3>;
> + slew-rate = <1>;
> };
> };
>
> diff --git a/arch/arm/dts/stm32mp157c-ev1.dts b/arch/arm/dts/stm32mp157c-ev1.dts
> index 89d29b50c3..aa5892b156 100644
> --- a/arch/arm/dts/stm32mp157c-ev1.dts
> +++ b/arch/arm/dts/stm32mp157c-ev1.dts
> @@ -189,8 +189,8 @@
> clocks = <&clk_ext_camera>;
> clock-names = "xclk";
> DOVDD-supply = <&v2v8>;
> - powerdown-gpios = <&stmfx_pinctrl 18 GPIO_ACTIVE_HIGH>;
> - reset-gpios = <&stmfx_pinctrl 19 GPIO_ACTIVE_LOW>;
> + powerdown-gpios = <&stmfx_pinctrl 18 (GPIO_ACTIVE_HIGH | GPIO_PUSH_PULL)>;
> + reset-gpios = <&stmfx_pinctrl 19 (GPIO_ACTIVE_LOW | GPIO_PUSH_PULL)>;
> rotation = <180>;
> status = "okay";
>
> @@ -223,7 +223,6 @@
>
> joystick_pins: joystick {
> pins = "gpio0", "gpio1", "gpio2", "gpio3", "gpio4";
> - drive-push-pull;
> bias-pull-down;
> };
>
> diff --git a/arch/arm/dts/stm32mp157c.dtsi b/arch/arm/dts/stm32mp157c.dtsi
> index 41aea75213..28a7e4c08a 100644
> --- a/arch/arm/dts/stm32mp157c.dtsi
> +++ b/arch/arm/dts/stm32mp157c.dtsi
> @@ -939,7 +939,7 @@
> interrupt-names = "int0", "int1";
> clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
> clock-names = "hclk", "cclk";
> - bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;
> + bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
> status = "disabled";
> };
>
> @@ -952,7 +952,7 @@
> interrupt-names = "int0", "int1";
> clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
> clock-names = "hclk", "cclk";
> - bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
> + bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;
> status = "disabled";
> };
>
> diff --git a/doc/device-tree-bindings/mtd/stm32-fmc2-nand.txt b/doc/device-tree-bindings/mtd/stm32-fmc2-nand.txt
> index 70e76be2a3..ad2bef8265 100644
> --- a/doc/device-tree-bindings/mtd/stm32-fmc2-nand.txt
> +++ b/doc/device-tree-bindings/mtd/stm32-fmc2-nand.txt
> @@ -18,8 +18,10 @@ Optional properties:
> - dmas: DMA specifiers (see: dma/stm32-mdma.txt)
> - dma-names: Must be "tx", "rx" and "ecc"
>
> -Optional children nodes:
> -Children nodes represent the available NAND chips.
> +* NAND device bindings:
> +
> +Required properties:
> +- reg: describes the CS lines assigned to the NAND device.
>
> Optional properties:
> - nand-on-flash-bbt: see nand.txt
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Thanks
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Uboot-stm32] [PATCH 3/9] ARM: dts: stm32mp1: DT alignment with kernel v5.5-rc7
2020-01-28 9:11 ` [PATCH 3/9] ARM: dts: stm32mp1: DT alignment with kernel v5.5-rc7 Patrick Delaunay
@ 2020-02-13 8:12 ` Patrice CHOTARD
2020-02-14 10:26 ` Patrick DELAUNAY
1 sibling, 0 replies; 38+ messages in thread
From: Patrice CHOTARD @ 2020-02-13 8:12 UTC (permalink / raw)
To: u-boot
On 1/28/20 10:11 AM, Patrick Delaunay wrote:
> Device tree and binding alignment with kernel v5.5-rc7
>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
> ---
>
> arch/arm/dts/stm32mp157-pinctrl.dtsi | 23 ++++++++-
> arch/arm/dts/stm32mp157a-avenger96.dts | 3 +-
> arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 17 -------
> arch/arm/dts/stm32mp157a-dk1.dts | 65 +++++++++++++++++++++---
> arch/arm/dts/stm32mp157c-dk2.dts | 13 +++++
> arch/arm/dts/stm32mp157c-ed1.dts | 20 ++++++--
> arch/arm/dts/stm32mp157c-ev1.dts | 3 --
> 7 files changed, 112 insertions(+), 32 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp157-pinctrl.dtsi b/arch/arm/dts/stm32mp157-pinctrl.dtsi
> index 07cd0809ff..81a363d93d 100644
> --- a/arch/arm/dts/stm32mp157-pinctrl.dtsi
> +++ b/arch/arm/dts/stm32mp157-pinctrl.dtsi
> @@ -138,7 +138,16 @@
> status = "disabled";
> };
>
> - adc12_usb_pwr_pins_a: adc12-usb-pwr-pins-0 {
> + adc12_ain_pins_a: adc12-ain-0 {
> + pins {
> + pinmux = <STM32_PINMUX('C', 3, ANALOG)>, /* ADC1 in13 */
> + <STM32_PINMUX('F', 12, ANALOG)>, /* ADC1 in6 */
> + <STM32_PINMUX('F', 13, ANALOG)>, /* ADC2 in2 */
> + <STM32_PINMUX('F', 14, ANALOG)>; /* ADC2 in6 */
> + };
> + };
> +
> + adc12_usb_cc_pins_a: adc12-usb-cc-pins-0 {
> pins {
> pinmux = <STM32_PINMUX('A', 4, ANALOG)>, /* ADC12 in18 */
> <STM32_PINMUX('A', 5, ANALOG)>; /* ADC12 in19 */
> @@ -175,6 +184,18 @@
> };
> };
>
> + dac_ch1_pins_a: dac-ch1 {
> + pins {
> + pinmux = <STM32_PINMUX('A', 4, ANALOG)>;
> + };
> + };
> +
> + dac_ch2_pins_a: dac-ch2 {
> + pins {
> + pinmux = <STM32_PINMUX('A', 5, ANALOG)>;
> + };
> + };
> +
> dcmi_pins_a: dcmi-0 {
> pins {
> pinmux = <STM32_PINMUX('H', 8, AF13)>,/* DCMI_HSYNC */
> diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts b/arch/arm/dts/stm32mp157a-avenger96.dts
> index 232fe70905..3065593bf2 100644
> --- a/arch/arm/dts/stm32mp157a-avenger96.dts
> +++ b/arch/arm/dts/stm32mp157a-avenger96.dts
> @@ -252,14 +252,13 @@
> regulator-name = "vbus_otg";
> interrupts = <IT_OCP_OTG 0>;
> interrupt-parent = <&pmic>;
> - regulator-active-discharge;
> };
>
> vbus_sw: pwr_sw2 {
> regulator-name = "vbus_sw";
> interrupts = <IT_OCP_SWOUT 0>;
> interrupt-parent = <&pmic>;
> - regulator-active-discharge;
> + regulator-active-discharge = <1>;
> };
> };
>
> diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> index dcaab3eef2..4045a6e731 100644
> --- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> @@ -35,24 +35,7 @@
> };
>
> &adc {
> - pinctrl-names = "default";
> - pinctrl-0 = <&adc12_usb_pwr_pins_a>;
> - vdd-supply = <&vdd>;
> - vdda-supply = <&vdd>;
> - vref-supply = <&vrefbuf>;
> status = "okay";
> - adc1: adc at 0 {
> - /*
> - * Type-C USB_PWR_CC1 & USB_PWR_CC2 on in18 & in19.
> - * Use at least 5 * RC time, e.g. 5 * (Rp + Rd) * C:
> - * 5 * (56 + 47kOhms) * 5pF => 2.5us.
> - * Use arbitrary margin here (e.g. 5?s).
> - */
> - st,min-sample-time-nsecs = <5000>;
> - /* ANA0, ANA1, USB Type-C CC1 & CC2 */
> - st,adc-channels = <0 1 18 19>;
> - status = "okay";
> - };
> };
>
> &clk_hse {
> diff --git a/arch/arm/dts/stm32mp157a-dk1.dts b/arch/arm/dts/stm32mp157a-dk1.dts
> index dc61bfc3d5..624bf6954b 100644
> --- a/arch/arm/dts/stm32mp157a-dk1.dts
> +++ b/arch/arm/dts/stm32mp157a-dk1.dts
> @@ -25,6 +25,7 @@
> };
>
> memory at c0000000 {
> + device_type = "memory";
> reg = <0xc0000000 0x20000000>;
> };
>
> @@ -92,7 +93,34 @@
> "Playback" , "MCLK",
> "Capture" , "MCLK",
> "MICL" , "Mic Bias";
> - dais = <&sai2a_port &sai2b_port>;
> + dais = <&sai2a_port &sai2b_port &i2s2_port>;
> + status = "okay";
> + };
> +};
> +
> +&adc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&adc12_ain_pins_a>, <&adc12_usb_cc_pins_a>;
> + vdd-supply = <&vdd>;
> + vdda-supply = <&vdd>;
> + vref-supply = <&vrefbuf>;
> + status = "disabled";
> + adc1: adc at 0 {
> + /*
> + * Type-C USB_PWR_CC1 & USB_PWR_CC2 on in18 & in19.
> + * Use at least 5 * RC time, e.g. 5 * (Rp + Rd) * C:
> + * 5 * (56 + 47kOhms) * 5pF => 2.5us.
> + * Use arbitrary margin here (e.g. 5us).
> + */
> + st,min-sample-time-nsecs = <5000>;
> + /* AIN connector, USB Type-C CC1 & CC2 */
> + st,adc-channels = <0 1 6 13 18 19>;
> + status = "okay";
> + };
> + adc2: adc at 100 {
> + /* AIN connector, USB Type-C CC1 & CC2 */
> + st,adc-channels = <0 1 2 6 18 19>;
> + st,min-sample-time-nsecs = <5000>;
> status = "okay";
> };
> };
> @@ -146,9 +174,7 @@
> reset-gpios = <&gpioa 10 GPIO_ACTIVE_LOW>;
> interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
> interrupt-parent = <&gpiog>;
> - pinctrl-names = "default", "sleep";
> - pinctrl-0 = <<dc_pins_a>;
> - pinctrl-1 = <<dc_pins_sleep_a>;
> + #sound-dai-cells = <0>;
> status = "okay";
>
> ports {
> @@ -161,6 +187,13 @@
> remote-endpoint = <<dc_ep0_out>;
> };
> };
> +
> + port at 3 {
> + reg = <3>;
> + sii9022_tx_endpoint: endpoint {
> + remote-endpoint = <&i2s2_endpoint>;
> + };
> + };
> };
> };
>
> @@ -244,7 +277,7 @@
>
> vddcore: buck1 {
> regulator-name = "vddcore";
> - regulator-min-microvolt = <800000>;
> + regulator-min-microvolt = <1200000>;
> regulator-max-microvolt = <1350000>;
> regulator-always-on;
> regulator-initial-mode = <0>;
> @@ -345,7 +378,7 @@
> vbus_sw: pwr_sw2 {
> regulator-name = "vbus_sw";
> interrupts = <IT_OCP_SWOUT 0>;
> - regulator-active-discharge;
> + regulator-active-discharge = <1>;
> };
> };
>
> @@ -364,6 +397,23 @@
> };
> };
>
> +&i2s2 {
> + clocks = <&rcc SPI2>, <&rcc SPI2_K>, <&rcc PLL3_Q>, <&rcc PLL3_R>;
> + clock-names = "pclk", "i2sclk", "x8k", "x11k";
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&i2s2_pins_a>;
> + pinctrl-1 = <&i2s2_pins_sleep_a>;
> + status = "okay";
> +
> + i2s2_port: port {
> + i2s2_endpoint: endpoint {
> + remote-endpoint = <&sii9022_tx_endpoint>;
> + format = "i2s";
> + mclk-fs = <256>;
> + };
> + };
> +};
> +
> &ipcc {
> status = "okay";
> };
> @@ -374,6 +424,9 @@
> };
>
> <dc {
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <<dc_pins_a>;
> + pinctrl-1 = <<dc_pins_sleep_a>;
> status = "okay";
>
> port {
> diff --git a/arch/arm/dts/stm32mp157c-dk2.dts b/arch/arm/dts/stm32mp157c-dk2.dts
> index 020ea0f0e2..d26adcbeba 100644
> --- a/arch/arm/dts/stm32mp157c-dk2.dts
> +++ b/arch/arm/dts/stm32mp157c-dk2.dts
> @@ -53,6 +53,19 @@
> };
> };
>
> +&i2c1 {
> + touchscreen at 38 {
> + compatible = "focaltech,ft6236";
> + reg = <0x38>;
> + interrupts = <2 2>;
> + interrupt-parent = <&gpiof>;
> + interrupt-controller;
> + touchscreen-size-x = <480>;
> + touchscreen-size-y = <800>;
> + status = "okay";
> + };
> +};
> +
> <dc {
> status = "okay";
>
> diff --git a/arch/arm/dts/stm32mp157c-ed1.dts b/arch/arm/dts/stm32mp157c-ed1.dts
> index acb59f24cc..ae4da39ce8 100644
> --- a/arch/arm/dts/stm32mp157c-ed1.dts
> +++ b/arch/arm/dts/stm32mp157c-ed1.dts
> @@ -84,7 +84,21 @@
>
> gpios = <&gpiof 14 GPIO_ACTIVE_HIGH>;
> gpios-states = <0>;
> - states = <1800000 0x1 2900000 0x0>;
> + states = <1800000 0x1>,
> + <2900000 0x0>;
> + };
> +};
> +
> +&dac {
> + pinctrl-names = "default";
> + pinctrl-0 = <&dac_ch1_pins_a &dac_ch2_pins_a>;
> + vref-supply = <&vdda>;
> + status = "disabled";
> + dac1: dac at 1 {
> + status = "okay";
> + };
> + dac2: dac at 2 {
> + status = "okay";
> };
> };
>
> @@ -127,7 +141,7 @@
>
> vddcore: buck1 {
> regulator-name = "vddcore";
> - regulator-min-microvolt = <800000>;
> + regulator-min-microvolt = <1200000>;
> regulator-max-microvolt = <1350000>;
> regulator-always-on;
> regulator-initial-mode = <0>;
> @@ -225,7 +239,7 @@
> vbus_sw: pwr_sw2 {
> regulator-name = "vbus_sw";
> interrupts = <IT_OCP_SWOUT 0>;
> - regulator-active-discharge;
> + regulator-active-discharge = <1>;
> };
> };
>
> diff --git a/arch/arm/dts/stm32mp157c-ev1.dts b/arch/arm/dts/stm32mp157c-ev1.dts
> index aa5892b156..bd8ffc185f 100644
> --- a/arch/arm/dts/stm32mp157c-ev1.dts
> +++ b/arch/arm/dts/stm32mp157c-ev1.dts
> @@ -32,7 +32,6 @@
>
> joystick {
> compatible = "gpio-keys";
> - #size-cells = <0>;
> pinctrl-0 = <&joystick_pins>;
> pinctrl-names = "default";
> button-0 {
> @@ -343,14 +342,12 @@
>
> &usbh_ehci {
> phys = <&usbphyc_port0>;
> - phy-names = "usb";
> status = "okay";
> };
>
> &usbotg_hs {
> dr_mode = "peripheral";
> phys = <&usbphyc_port1 0>;
> - phy-names = "usb2-phy";
> status = "okay";
> };
>
>
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Thanks
> _______________________________________________
> Uboot-stm32 mailing list
> Uboot-stm32 at st-md-mailman.stormreply.com
> https://st-md-mailman.stormreply.com/mailman/listinfo/uboot-stm32
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Uboot-stm32] [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R
2020-01-28 9:11 ` [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R Patrick Delaunay
2020-01-28 12:15 ` Marek Vasut
@ 2020-02-13 8:12 ` Patrice CHOTARD
2020-02-14 10:26 ` Patrick DELAUNAY
2 siblings, 0 replies; 38+ messages in thread
From: Patrice CHOTARD @ 2020-02-13 8:12 UTC (permalink / raw)
To: u-boot
On 1/28/20 10:11 AM, Patrick Delaunay wrote:
> From: Antonio Borneo <antonio.borneo@st.com>
>
> LTDC modifies the clock frequency to adapt it to the display. Such
> frequency change is not detected by the FDCAN driver that instead
> cache the value at probe and pretend to use it later.
>
> Keep the LTDC alone on PLL4_Q by moving the FDCAN to PLL4_R.
>
> Signed-off-by: Antonio Borneo <antonio.borneo@st.com>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
> ---
>
> arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 2 +-
> arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 2 +-
> arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 2 +-
> arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> index 1104a70a65..d8a4617d90 100644
> --- a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> @@ -91,7 +91,7 @@
> CLK_UART6_HSI
> CLK_UART78_HSI
> CLK_SPDIF_PLL4P
> - CLK_FDCAN_PLL4Q
> + CLK_FDCAN_PLL4R
> CLK_SAI1_PLL3Q
> CLK_SAI2_PLL3Q
> CLK_SAI3_PLL3Q
> diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> index 4045a6e731..a7a125c087 100644
> --- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> @@ -110,7 +110,7 @@
> CLK_UART6_HSI
> CLK_UART78_HSI
> CLK_SPDIF_PLL4P
> - CLK_FDCAN_PLL4Q
> + CLK_FDCAN_PLL4R
> CLK_SAI1_PLL3Q
> CLK_SAI2_PLL3Q
> CLK_SAI3_PLL3Q
> diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> index b2ac49472a..32d95b84e7 100644
> --- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> @@ -107,7 +107,7 @@
> CLK_UART6_HSI
> CLK_UART78_HSI
> CLK_SPDIF_PLL4P
> - CLK_FDCAN_PLL4Q
> + CLK_FDCAN_PLL4R
> CLK_SAI1_PLL3Q
> CLK_SAI2_PLL3Q
> CLK_SAI3_PLL3Q
> diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> index 320912edd8..21aa4bfb86 100644
> --- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> @@ -142,7 +142,7 @@
> CLK_UART6_HSI
> CLK_UART78_HSI
> CLK_SPDIF_PLL4P
> - CLK_FDCAN_PLL4Q
> + CLK_FDCAN_PLL4R
> CLK_SAI1_PLL3Q
> CLK_SAI2_PLL3Q
> CLK_SAI3_PLL3Q
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Thanks
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Uboot-stm32] [PATCH 5/9] ARM: dts: stm32mp1: correct ddr node
2020-01-28 9:11 ` [PATCH 5/9] ARM: dts: stm32mp1: correct ddr node Patrick Delaunay
@ 2020-02-13 8:13 ` Patrice CHOTARD
2020-02-14 10:27 ` Patrick DELAUNAY
1 sibling, 0 replies; 38+ messages in thread
From: Patrice CHOTARD @ 2020-02-13 8:13 UTC (permalink / raw)
To: u-boot
On 1/28/20 10:11 AM, Patrick Delaunay wrote:
> This patch fix the warning:
> dt.dts: Warning (simple_bus_reg): Node /soc/ddr at 5A003000
> simple-bus unit address format error, expected "5a003000"
>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
> ---
>
> arch/arm/dts/stm32mp15-ddr.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/stm32mp15-ddr.dtsi b/arch/arm/dts/stm32mp15-ddr.dtsi
> index 479b700c86..38f29bb789 100644
> --- a/arch/arm/dts/stm32mp15-ddr.dtsi
> +++ b/arch/arm/dts/stm32mp15-ddr.dtsi
> @@ -5,7 +5,7 @@
>
> / {
> soc {
> - ddr: ddr at 5A003000 {
> + ddr: ddr at 5a003000 {
> u-boot,dm-pre-reloc;
>
> compatible = "st,stm32mp1-ddr";
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Thanks
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Uboot-stm32] [PATCH 6/9] ARM: dts: stm32m1: add reg for pll nodes
2020-01-28 9:11 ` [PATCH 6/9] ARM: dts: stm32m1: add reg for pll nodes Patrick Delaunay
@ 2020-02-13 8:13 ` Patrice CHOTARD
2020-02-14 10:27 ` Patrick DELAUNAY
1 sibling, 0 replies; 38+ messages in thread
From: Patrice CHOTARD @ 2020-02-13 8:13 UTC (permalink / raw)
To: u-boot
On 1/28/20 10:11 AM, Patrick Delaunay wrote:
> Fix the following DT dtc warnings for stm32mp1 boards:
>
> Warning (unit_address_vs_reg): /soc/rcc at 50000000/st,pll at 0:
> node has a unit name, but no reg property
> Warning (unit_address_vs_reg): /soc/rcc at 50000000/st,pll at 1:
> node has a unit name, but no reg property
> Warning (unit_address_vs_reg): /soc/rcc at 50000000/st,pll at 2:
> node has a unit name, but no reg property
> Warning (unit_address_vs_reg): /soc/rcc at 50000000/st,pll at 3:
> node has a unit name, but no reg property
>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
> ---
>
> arch/arm/dts/stm32mp157-u-boot.dtsi | 2 ++
> .../arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 8 +++++
> arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 8 +++++
> arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 8 +++++
> arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 8 +++++
> .../clock/st,stm32mp1.txt | 32 ++++++++++++++++---
> 6 files changed, 62 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp157-u-boot.dtsi b/arch/arm/dts/stm32mp157-u-boot.dtsi
> index cb8d60e33d..8f9535a4db 100644
> --- a/arch/arm/dts/stm32mp157-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157-u-boot.dtsi
> @@ -134,6 +134,8 @@
>
> &rcc {
> u-boot,dm-pre-reloc;
> + #address-cells = <1>;
> + #size-cells = <0>;
> };
>
> &sdmmc1 {
> diff --git a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> index d8a4617d90..d6dc746365 100644
> --- a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> @@ -105,6 +105,8 @@
>
> /* VCO = 1300.0 MHz => P = 650 (CPU) */
> pll1: st,pll at 0 {
> + compatible = "st,stm32mp1-pll";
> + reg = <0>;
> cfg = < 2 80 0 0 0 PQR(1,0,0) >;
> frac = < 0x800 >;
> u-boot,dm-pre-reloc;
> @@ -112,6 +114,8 @@
>
> /* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU), R = 533 (DDR) */
> pll2: st,pll at 1 {
> + compatible = "st,stm32mp1-pll";
> + reg = <1>;
> cfg = < 2 65 1 0 0 PQR(1,1,1) >;
> frac = < 0x1400 >;
> u-boot,dm-pre-reloc;
> @@ -119,6 +123,8 @@
>
> /* VCO = 417.8 MHz => P = 209, Q = 24, R = 11 */
> pll3: st,pll at 2 {
> + compatible = "st,stm32mp1-pll";
> + reg = <2>;
> cfg = < 1 33 1 16 36 PQR(1,1,1) >;
> frac = < 0x1a04 >;
> u-boot,dm-pre-reloc;
> @@ -126,6 +132,8 @@
>
> /* VCO = 480.0 MHz => P = 120, Q = 40, R = 96 */
> pll4: st,pll at 3 {
> + compatible = "st,stm32mp1-pll";
> + reg = <3>;
> cfg = < 1 39 3 11 4 PQR(1,1,1) >;
> u-boot,dm-pre-reloc;
> };
> diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> index a7a125c087..a5cc01dd19 100644
> --- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> @@ -124,6 +124,8 @@
>
> /* VCO = 1300.0 MHz => P = 650 (CPU) */
> pll1: st,pll at 0 {
> + compatible = "st,stm32mp1-pll";
> + reg = <0>;
> cfg = < 2 80 0 0 0 PQR(1,0,0) >;
> frac = < 0x800 >;
> u-boot,dm-pre-reloc;
> @@ -131,6 +133,8 @@
>
> /* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU), R = 533 (DDR) */
> pll2: st,pll at 1 {
> + compatible = "st,stm32mp1-pll";
> + reg = <1>;
> cfg = < 2 65 1 0 0 PQR(1,1,1) >;
> frac = < 0x1400 >;
> u-boot,dm-pre-reloc;
> @@ -138,6 +142,8 @@
>
> /* VCO = 417.8 MHz => P = 209, Q = 24, R = 11 */
> pll3: st,pll at 2 {
> + compatible = "st,stm32mp1-pll";
> + reg = <2>;
> cfg = < 1 33 1 16 36 PQR(1,1,1) >;
> frac = < 0x1a04 >;
> u-boot,dm-pre-reloc;
> @@ -145,6 +151,8 @@
>
> /* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
> pll4: st,pll at 3 {
> + compatible = "st,stm32mp1-pll";
> + reg = <3>;
> cfg = < 3 98 5 7 7 PQR(1,1,1) >;
> u-boot,dm-pre-reloc;
> };
> diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> index 32d95b84e7..347edf7e58 100644
> --- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> @@ -121,6 +121,8 @@
>
> /* VCO = 1300.0 MHz => P = 650 (CPU) */
> pll1: st,pll at 0 {
> + compatible = "st,stm32mp1-pll";
> + reg = <0>;
> cfg = < 2 80 0 0 0 PQR(1,0,0) >;
> frac = < 0x800 >;
> u-boot,dm-pre-reloc;
> @@ -128,6 +130,8 @@
>
> /* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU), R = 533 (DDR) */
> pll2: st,pll at 1 {
> + compatible = "st,stm32mp1-pll";
> + reg = <1>;
> cfg = < 2 65 1 0 0 PQR(1,1,1) >;
> frac = < 0x1400 >;
> u-boot,dm-pre-reloc;
> @@ -135,6 +139,8 @@
>
> /* VCO = 417.8 MHz => P = 209, Q = 24, R = 11 */
> pll3: st,pll at 2 {
> + compatible = "st,stm32mp1-pll";
> + reg = <2>;
> cfg = < 1 33 1 16 36 PQR(1,1,1) >;
> frac = < 0x1a04 >;
> u-boot,dm-pre-reloc;
> @@ -142,6 +148,8 @@
>
> /* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
> pll4: st,pll at 3 {
> + compatible = "st,stm32mp1-pll";
> + reg = <3>;
> cfg = < 3 98 5 7 7 PQR(1,1,1) >;
> u-boot,dm-pre-reloc;
> };
> diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> index 21aa4bfb86..6c952a57ee 100644
> --- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> @@ -156,6 +156,8 @@
>
> /* VCO = 1300.0 MHz => P = 650 (CPU) */
> pll1: st,pll at 0 {
> + compatible = "st,stm32mp1-pll";
> + reg = <0>;
> cfg = < 2 80 0 0 0 PQR(1,0,0) >;
> frac = < 0x800 >;
> u-boot,dm-pre-reloc;
> @@ -163,6 +165,8 @@
>
> /* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU), R = 533 (DDR) */
> pll2: st,pll at 1 {
> + compatible = "st,stm32mp1-pll";
> + reg = <1>;
> cfg = < 2 65 1 0 0 PQR(1,1,1) >;
> frac = < 0x1400 >;
> u-boot,dm-pre-reloc;
> @@ -170,6 +174,8 @@
>
> /* VCO = 417.8 MHz => P = 209, Q = 24, R = 11 */
> pll3: st,pll at 2 {
> + compatible = "st,stm32mp1-pll";
> + reg = <2>;
> cfg = < 1 33 1 16 36 PQR(1,1,1) >;
> frac = < 0x1a04 >;
> u-boot,dm-pre-reloc;
> @@ -177,6 +183,8 @@
>
> /* VCO = 600.0 MHz => P = 50, Q = 50, R = 50 */
> pll4: st,pll at 3 {
> + compatible = "st,stm32mp1-pll";
> + reg = <3>;
> cfg = < 1 49 11 11 11 PQR(1,1,1) >;
> u-boot,dm-pre-reloc;
> };
> diff --git a/doc/device-tree-bindings/clock/st,stm32mp1.txt b/doc/device-tree-bindings/clock/st,stm32mp1.txt
> index ec1d703f34..a3d427911d 100644
> --- a/doc/device-tree-bindings/clock/st,stm32mp1.txt
> +++ b/doc/device-tree-bindings/clock/st,stm32mp1.txt
> @@ -12,6 +12,9 @@ describes the fields added for clock tree initialization which are not present
> in Linux binding for compatible "st,stm32mp1-rcc" defined in st,stm32mp1-rcc.txt
> file.
>
> +This parent node may optionally have additional children nodes which define
> +specific init values for RCC elements.
> +
> The added properties for clock tree initialization are:
>
> Required properties:
> @@ -78,13 +81,16 @@ Required properties:
> >;
>
> Optional Properties:
> -- st,pll : A specific PLL configuration, including frequency.
> +- children for a PLL configuration with "st,stm32mp1-pll" compatible
>
> - PLL children nodes for PLL1 to PLL4 (see ref manual for details)
> - are listed with associated index 0 to 3 (st,pll at 0 to st,pll at 3).
> - PLLx is off when the associated node is absent.
> + each PLL children nodes for PLL1 to PLL4 (see ref manual for details)
> + are listed with associated reg 0 to 3.
> + PLLx is off when the associated node is absent or deactivated.
>
> Here are the available properties for each PLL node:
> + - compatible: should be "st,stm32mp1-pll"
> +
> + - reg: index of the pll instance
>
> - cfg: The parameters for PLL configuration in the following order:
> DIVM DIVN DIVP DIVQ DIVR Output.
> @@ -118,18 +124,26 @@ Optional Properties:
>
> Example:
> st,pll at 0 {
> + compatible = "st,stm32mp1-pll";
> + reg = <0>;
> cfg = < 1 53 0 0 0 1 >;
> frac = < 0x810 >;
> };
> st,pll at 1 {
> + compatible = "st,stm32mp1-pll";
> + reg = <1>;
> cfg = < 1 43 1 0 0 PQR(0,1,1) >;
> csg = < 10 20 1 >;
> };
> st,pll at 2 {
> + compatible = "st,stm32mp1-pll";
> + reg = <2>;
> cfg = < 2 85 3 13 3 0 >;
> csg = < 10 20 SSCG_MODE_CENTER_SPREAD >;
> };
> st,pll at 3 {
> + compatible = "st,stm32mp1-pll";
> + reg = <3>;
> cfg = < 2 78 4 7 9 3 >;
> };
>
> @@ -277,6 +291,8 @@ Example of clock tree initialization
> u-boot,dm-pre-reloc;
> compatible = "st,stm32mp1-rcc", "syscon";
> reg = <0x50000000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> #clock-cells = <1>;
> #reset-cells = <1>;
> interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
> @@ -347,6 +363,8 @@ Example of clock tree initialization
>
> /* VCO = 1300.0 MHz => P = 650 (CPU) */
> pll1: st,pll at 0 {
> + compatible = "st,stm32mp1-pll";
> + reg = <0>;
> cfg = < 2 80 0 0 0 PQR(1,0,0) >;
> frac = < 0x800 >;
> u-boot,dm-pre-reloc;
> @@ -355,6 +373,8 @@ Example of clock tree initialization
> /* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU),
> R = 533 (DDR) */
> pll2: st,pll at 1 {
> + compatible = "st,stm32mp1-pll";
> + reg = <1>;
> cfg = < 2 65 1 0 0 PQR(1,1,1) >;
> frac = < 0x1400 >;
> u-boot,dm-pre-reloc;
> @@ -362,6 +382,8 @@ Example of clock tree initialization
>
> /* VCO = 417.8 MHz => P = 209, Q = 24, R = 11 */
> pll3: st,pll at 2 {
> + compatible = "st,stm32mp1-pll";
> + reg = <2>;
> cfg = < 1 33 1 16 36 PQR(1,1,1) >;
> frac = < 0x1a04 >;
> u-boot,dm-pre-reloc;
> @@ -369,6 +391,8 @@ Example of clock tree initialization
>
> /* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
> pll4: st,pll at 3 {
> + compatible = "st,stm32mp1-pll";
> + reg = <3>;
> cfg = < 3 98 5 7 7 PQR(1,1,1) >;
> u-boot,dm-pre-reloc;
> };
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Thanks
^ permalink raw reply [flat|nested] 38+ messages in thread
* [Uboot-stm32] [PATCH 7/9] board: stm32mp1: update readme
2020-01-28 9:11 ` [PATCH 7/9] board: stm32mp1: update readme Patrick Delaunay
@ 2020-02-13 8:13 ` Patrice CHOTARD
2020-02-14 10:28 ` Patrick DELAUNAY
1 sibling, 0 replies; 38+ messages in thread
From: Patrice CHOTARD @ 2020-02-13 8:13 UTC (permalink / raw)
To: u-boot
On 1/28/20 10:11 AM, Patrick Delaunay wrote:
> Update readme:
> - list the supported SOC and change family to STM32MP15x
> - add warning on OTP write and prerequisite:
> check if MAC address is not yet provisioned.
> - Use filesize for mmc write command (avoid to write all partition
> with ${partsize}). ${filesize} and ${partsize} are set by previous
> load command.
>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
> ---
>
> board/st/stm32mp1/README | 52 ++++++++++++++++++++++++++--------------
> 1 file changed, 34 insertions(+), 18 deletions(-)
>
> diff --git a/board/st/stm32mp1/README b/board/st/stm32mp1/README
> index f2069bcefa..5d7465a8c8 100644
> --- a/board/st/stm32mp1/README
> +++ b/board/st/stm32mp1/README
> @@ -3,8 +3,8 @@ SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> # Copyright (C) 2018 STMicroelectronics - All Rights Reserved
> #
>
> -U-Boot on STMicroelectronics STM32MP1
> -======================================
> +U-Boot on STMicroelectronics STM32MP15x
> +=======================================
>
> 1. Summary
> ==========
> @@ -12,12 +12,12 @@ This is a quick instruction for setup stm32mp1 boards.
>
> 2. Supported devices
> ====================
> -U-Boot supports one STMP32MP1 SoCs: STM32MP157
> +U-Boot supports STMP32MP15x SoCs: STM32MP157, STM32MP153 and STM32MP151
>
> -The STM32MP157 is a Cortex-A MPU aimed at various applications.
> +The STM32MP15x is a Cortex-A MPU aimed at various applications.
> It features:
> -- Dual core Cortex-A7 application core
> -- 2D/3D image composition with GPU
> +- Dual core Cortex-A7 application core (Single on STM32MP151)
> +- 2D/3D image composition with GPU (only on STM32MP157)
> - Standard memories interface support
> - Standard connectivity, widely inherited from the STM32 MCU family
> - Comprehensive security support
> @@ -37,11 +37,11 @@ And the necessary drivers
> 4. Fuse
>
> Currently the following boards are supported:
> -+ stm32mp157c-ev1
> -+ stm32mp157c-ed1
> -+ stm32mp157a-dk1
> -+ stm32mp157c-dk2
> -+ stm32mp157a-avenger96
> ++ stm32mp157a-avenger96.dts
> ++ stm32mp157a-dk1.dts
> ++ stm32mp157c-dk2.dts
> ++ stm32mp157c-ed1.dts
> ++ stm32mp157c-ev1.dts
>
> 3. Boot Sequences
> =================
> @@ -74,7 +74,7 @@ with FSBL = First Stage Bootloader
> U-Boot is running in secure mode and provide a secure monitor to the kernel
> with only PSCI support (Power State Coordination Interface defined by ARM).
>
> -All the STM32MP1 boards supported by U-Boot use the same generic board
> +All the STM32MP15x boards supported by U-Boot use the same generic board
> stm32mp1 which support all the bootable devices.
>
> Each board is configurated only with the associated device tree.
> @@ -108,7 +108,7 @@ the supported device trees for stm32mp157 are:
> + install package needed in U-Boot makefile
> (libssl-dev, swig, libpython-dev...)
> + install ARMv7 toolchain for 32bit Cortex-A (from Linaro,
> - from SDK for STM32MP1, or any crosstoolchains from your distribution)
> + from SDK for STM32MP15x, or any crosstoolchains from your distribution)
>
> 2. Set the cross compiler:
>
> @@ -323,8 +323,7 @@ c) copy U-Boot in first GPT partition of eMMC
> # ext4load mmc 0:4 0xC0000000 u-boot.img
> # mmc dev 1
> # part start mmc 1 1 partstart
> - # part size mmc 1 1 partsize
> - # mmc write ${fileaddr} ${partstart} ${partsize}
> + # mmc write ${fileaddr} ${partstart} ${filesize}
>
> To boot from eMMC, select BootPinMode = 0 1 0 and reset.
>
> @@ -334,14 +333,27 @@ To boot from eMMC, select BootPinMode = 0 1 0 and reset.
> Please read doc/README.enetaddr for the implementation guidelines for mac id
> usage. Basically, environment has precedence over board specific storage.
>
> -Mac id storage and retrieval in stm32mp otp :
> +For STMicroelectonics board, it is retrieved in STM32MP15x otp :
> - OTP_57[31:0] = MAC_ADDR[31:0]
> - OTP_58[15:0] = MAC_ADDR[47:32]
>
> To program a MAC address on virgin OTP words above, you can use the fuse command
> on bank 0 to access to internal OTP:
>
> - example to set mac address "12:34:56:78:9a:bc"
> + Prerequisite: check if a MAC address isn't yet programmed in OTP
> +
> + 1- check OTP: their value must be equal to 0
> +
> + STM32MP> fuse sense 0 57 2
> + Sensing bank 0:
> + Word 0x00000039: 00000000 00000000
> +
> + 2- check environment variable
> +
> + STM32MP> env print ethaddr
> + ## Error: "ethaddr" not defined
> +
> + Example to set mac address "12:34:56:78:9a:bc"
>
> 1- Write OTP
> STM32MP> fuse prog -y 0 57 0x78563412 0x0000bc9a
> @@ -355,9 +367,13 @@ on bank 0 to access to internal OTP:
> ### Setting environment from OTP MAC address = "12:34:56:78:9a:bc"
>
> 4 check env update
> - STM32MP> print ethaddr
> + STM32MP> env print ethaddr
> ethaddr=12:34:56:78:9a:bc
>
> +warning:: This MAC address provisioning can't be executed twice on the same
> + board as the OTP are protected. It is already done for the board
> + provided by STMicroelectronics.
> +
> 10. Coprocessor firmware
> ========================
>
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Thanks
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 8/9] doc: add board documentation for stm32mp1
2020-01-28 9:11 ` [PATCH 8/9] doc: add board documentation for stm32mp1 Patrick Delaunay
2020-01-28 11:34 ` Heinrich Schuchardt
@ 2020-02-13 8:14 ` Patrice CHOTARD
1 sibling, 0 replies; 38+ messages in thread
From: Patrice CHOTARD @ 2020-02-13 8:14 UTC (permalink / raw)
To: u-boot
On 1/28/20 10:11 AM, Patrick Delaunay wrote:
> Change plain test README to rst format and move this file
> in documentation directory.
>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
> ---
>
> board/st/stm32mp1/README | 520 +--------------------------------
> doc/board/index.rst | 1 +
> doc/board/st/index.rst | 9 +
> doc/board/st/stm32mp1.rst | 598 ++++++++++++++++++++++++++++++++++++++
> 4 files changed, 609 insertions(+), 519 deletions(-)
> create mode 100644 doc/board/st/index.rst
> create mode 100644 doc/board/st/stm32mp1.rst
>
> diff --git a/board/st/stm32mp1/README b/board/st/stm32mp1/README
> index 5d7465a8c8..8172d26a66 100644
> --- a/board/st/stm32mp1/README
> +++ b/board/st/stm32mp1/README
> @@ -1,519 +1 @@
> -SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> -#
> -# Copyright (C) 2018 STMicroelectronics - All Rights Reserved
> -#
> -
> -U-Boot on STMicroelectronics STM32MP15x
> -=======================================
> -
> -1. Summary
> -==========
> -This is a quick instruction for setup stm32mp1 boards.
> -
> -2. Supported devices
> -====================
> -U-Boot supports STMP32MP15x SoCs: STM32MP157, STM32MP153 and STM32MP151
> -
> -The STM32MP15x is a Cortex-A MPU aimed at various applications.
> -It features:
> -- Dual core Cortex-A7 application core (Single on STM32MP151)
> -- 2D/3D image composition with GPU (only on STM32MP157)
> -- Standard memories interface support
> -- Standard connectivity, widely inherited from the STM32 MCU family
> -- Comprehensive security support
> -
> -Everything is supported in Linux but U-Boot is limited to:
> -1. UART
> -2. SDCard/MMC controller (SDMMC)
> -3. NAND controller (FMC)
> -4. NOR controller (QSPI)
> -5. USB controller (OTG DWC2)
> -6. Ethernet controller
> -
> -And the necessary drivers
> -1. I2C
> -2. STPMIC1 (PMIC and regulator)
> -3. Clock, Reset, Sysreset
> -4. Fuse
> -
> -Currently the following boards are supported:
> -+ stm32mp157a-avenger96.dts
> -+ stm32mp157a-dk1.dts
> -+ stm32mp157c-dk2.dts
> -+ stm32mp157c-ed1.dts
> -+ stm32mp157c-ev1.dts
> -
> -3. Boot Sequences
> -=================
> -
> -BootRom => FSBL in SYSRAM => SSBL in DDR => OS (Linux Kernel)
> -
> -with FSBL = First Stage Bootloader
> - SSBL = Second Stage Bootloader
> -
> -3 boot configurations are supported:
> -
> -1) The "Trusted" boot chain (defconfig_file : stm32mp15_trusted_defconfig)
> - BootRom => FSBL = Trusted Firmware-A (TF-A) => SSBL = U-Boot
> - TF-A performs a full initialization of Secure peripherals and installs a
> - secure monitor.
> - U-Boot is running in normal world and uses TF-A monitor
> - to access to secure resources.
> -
> -2) The "Trusted" boot chain with OP-TEE
> - (defconfig_file : stm32mp15_optee_defconfig)
> - BootRom => FSBL = Trusted Firmware-A (TF-A) => SSBL = U-Boot
> - TF-A performs a full initialization of Secure peripherals and installs OP-TEE
> - from specific partitions (teeh, teed, teex).
> - U-Boot is running in normal world and uses OP-TEE monitor to access
> - to secure resources.
> -
> -3) The "Basic" boot chain (defconfig_file : stm32mp15_basic_defconfig)
> - BootRom => FSBL = U-Boot SPL => SSBL = U-Boot
> - SPL has limited security initialisation
> - U-Boot is running in secure mode and provide a secure monitor to the kernel
> - with only PSCI support (Power State Coordination Interface defined by ARM).
> -
> -All the STM32MP15x boards supported by U-Boot use the same generic board
> -stm32mp1 which support all the bootable devices.
> -
> -Each board is configurated only with the associated device tree.
> -
> -4. Device Tree Selection
> -========================
> -
> -You need to select the appropriate device tree for your board,
> -the supported device trees for stm32mp157 are:
> -
> -+ ev1: eval board with pmic stpmic1 (ev1 = mother board + daughter ed1)
> - dts: stm32mp157c-ev1
> -
> -+ ed1: daughter board with pmic stpmic1
> - dts: stm32mp157c-ed1
> -
> -+ dk1: Discovery board
> - dts: stm32mp157a-dk1
> -
> -+ dk2: Discovery board = dk1 with a BT/WiFI combo and a DSI panel
> - dts: stm32mp157c-dk2
> -
> -+ avenger96: Avenger96 board from Arrow Electronics
> - dts: stm32mp157a-avenger96
> -
> -5. Build Procedure
> -==================
> -
> -1. Install required tools for U-Boot
> -
> - + install package needed in U-Boot makefile
> - (libssl-dev, swig, libpython-dev...)
> - + install ARMv7 toolchain for 32bit Cortex-A (from Linaro,
> - from SDK for STM32MP15x, or any crosstoolchains from your distribution)
> -
> -2. Set the cross compiler:
> -
> - # export CROSS_COMPILE=/path/to/toolchain/arm-linux-gnueabi-
> - (you can use any gcc cross compiler compatible with U-Boot)
> -
> -3. Select the output directory (optional)
> -
> - # export KBUILD_OUTPUT=/path/to/output
> -
> - for example: use one output directory for each configuration
> - # export KBUILD_OUTPUT=stm32mp15_trusted
> - # export KBUILD_OUTPUT=stm32mp15_optee
> - # export KBUILD_OUTPUT=stm32mp15_basic
> -
> - you can build outside of code directory:
> - # export KBUILD_OUTPUT=../build/stm32mp15_trusted
> -
> -4. Configure U-Boot:
> -
> - # make <defconfig_file>
> -
> - - For trusted boot mode : "stm32mp15_trusted_defconfig"
> - - For trusted with OP-TEE boot mode : "stm32mp15_optee_defconfig"
> - - For basic boot mode: "stm32mp15_basic_defconfig"
> -
> -5. Configure the device-tree and build the U-Boot image:
> -
> - # make DEVICE_TREE=<name> all
> -
> - example:
> - a) trusted boot on ev1
> - # export KBUILD_OUTPUT=stm32mp15_trusted
> - # make stm32mp15_trusted_defconfig
> - # make DEVICE_TREE=stm32mp157c-ev1 all
> -
> - b) trusted with OP-TEE boot on dk2
> - # export KBUILD_OUTPUT=stm32mp15_optee
> - # make stm32mp15_optee_defconfig
> - # make DEVICE_TREE=stm32mp157c-dk2 all
> -
> - c) basic boot on ev1
> - # export KBUILD_OUTPUT=stm32mp15_basic
> - # make stm32mp15_basic_defconfig
> - # make DEVICE_TREE=stm32mp157c-ev1 all
> -
> - d) basic boot on ed1
> - # export KBUILD_OUTPUT=stm32mp15_basic
> - # make stm32mp15_basic_defconfig
> - # make DEVICE_TREE=stm32mp157c-ed1 all
> -
> - e) basic boot on dk1
> - # export KBUILD_OUTPUT=stm32mp15_basic
> - # make stm32mp15_basic_defconfig
> - # make DEVICE_TREE=stm32mp157a-dk1 all
> -
> - f) basic boot on avenger96
> - # export KBUILD_OUTPUT=stm32mp15_basic
> - # make stm32mp15_basic_defconfig
> - # make DEVICE_TREE=stm32mp157a-avenger96 all
> -
> -6. Output files
> -
> - BootRom and TF-A expect binaries with STM32 image header
> - SPL expects file with U-Boot uImage header
> -
> - So in the output directory (selected by KBUILD_OUTPUT),
> - you can found the needed files:
> -
> - a) For Trusted boot (with or without OP-TEE)
> - + FSBL = tf-a.stm32 (provided by TF-A compilation)
> - + SSBL = u-boot.stm32
> -
> - b) For Basic boot
> - + FSBL = spl/u-boot-spl.stm32
> - + SSBL = u-boot.img
> -
> -6. Switch Setting for Boot Mode
> -===============================
> -
> -You can select the boot mode, on the board with one switch :
> -
> -- on the daugther board ed1 with the switch SW1 : BOOT0, BOOT1, BOOT2
> -
> - -----------------------------------
> - Boot Mode BOOT2 BOOT1 BOOT0
> - -----------------------------------
> - Reserved 0 0 0
> - NOR 0 0 1
> - SD-Card 1 0 1
> - eMMC 0 1 0
> - NAND 0 1 1
> - Recovery 1 1 0
> - Recovery 0 0 0
> -
> -- on board DK1/DK2 with the switch SW1 : BOOT0, BOOT2
> - (BOOT1 forced to 0, NOR not supported)
> -
> - --------------------------
> - Boot Mode BOOT2 BOOT0
> - --------------------------
> - Reserved 1 0
> - SD-Card 1 1
> - Recovery 0 0
> -
> -- Boot mode of Avenger96 can be selected using switch S3
> -
> - -----------------------------------
> - Boot Mode BOOT2 BOOT1 BOOT0
> - -----------------------------------
> - Recovery 0 0 0
> - NOR 0 0 1
> - SD-Card 1 0 1
> - eMMC 0 1 0
> - NAND 0 1 1
> - Reserved 1 0 0
> - Recovery 1 1 0
> - SD-Card 1 1 1
> -
> -Recovery is a boot from serial link (UART/USB) and it is used with
> -STM32CubeProgrammer tool to load executable in RAM and to update the flash
> -devices available on the board (NOR/NAND/eMMC/SDCARD).
> -The communication between HOST and board is based on
> -- for UARTs : the uart protocol used with all MCU STM32
> -- for USB : based on USB DFU 1.1 (without the ST extensions used on MCU STM32)
> -
> -7. Prepare an SDCard
> -===================
> -
> -The minimal requirements for STMP32MP1 boot up to U-Boot are:
> -- GPT partitioning (with gdisk or with sgdisk)
> -- 2 fsbl partitions, named fsbl1 and fsbl2, size at least 256KiB
> -- one ssbl partition for U-Boot
> -
> -Then the minimal GPT partition is:
> - ----- ------- --------- --------------
> - | Num | Name | Size | Content |
> - ----- ------- -------- ---------------
> - | 1 | fsbl1 | 256 KiB | TF-A or SPL |
> - | 2 | fsbl2 | 256 KiB | TF-A or SPL |
> - | 3 | ssbl | enought | U-Boot |
> - | * | - | - | Boot/Rootfs |
> - ----- ------- --------- --------------
> -
> -(*) add bootable partition for extlinux.conf
> - following Generic Distribution
> - (doc/README.distro for use)
> -
> - according the used card reader select the block device
> - (/dev/sdx or /dev/mmcblk0)
> - in the next example I use /dev/mmcblk0
> -
> -for example: with gpt table with 128 entries
> -
> - a) remove previous formatting
> - # sgdisk -o /dev/<SDCard dev>
> -
> - b) create minimal image
> - # sgdisk --resize-table=128 -a 1 \
> - -n 1:34:545 -c 1:fsbl1 \
> - -n 2:546:1057 -c 2:fsbl2 \
> - -n 3:1058:5153 -c 3:ssbl \
> - -p /dev/<SDCard dev>
> -
> - you can add other partitions for kernel
> - one partition rootfs for example:
> - -n 4:5154: -c 4:rootfs \
> -
> - c) copy the FSBL (2 times) and SSBL file on the correct partition.
> - in this example in partition 1 to 3
> -
> - for basic boot mode : <SDCard dev> = /dev/mmcblk0
> - # dd if=u-boot-spl.stm32 of=/dev/mmcblk0p1
> - # dd if=u-boot-spl.stm32 of=/dev/mmcblk0p2
> - # dd if=u-boot.img of=/dev/mmcblk0p3
> -
> - for trusted boot mode :
> - # dd if=tf-a.stm32 of=/dev/mmcblk0p1
> - # dd if=tf-a.stm32 of=/dev/mmcblk0p2
> - # dd if=u-boot.stm32 of=/dev/mmcblk0p3
> -
> -To boot from SDCard, select BootPinMode = 1 0 1 and reset.
> -
> -8. Prepare eMMC
> -===============
> -You can use U-Boot to copy binary in eMMC.
> -
> -In the next example, you need to boot from SDCARD and the images (u-boot-spl.stm32, u-boot.img)
> -are presents on SDCARD (mmc 0) in ext4 partition 4 (bootfs).
> -
> -To boot from SDCard, select BootPinMode = 1 0 1 and reset.
> -
> -Then you update the eMMC with the next U-Boot command :
> -
> -a) prepare GPT on eMMC,
> - example with 2 partitions, bootfs and roots:
> -
> - # setenv emmc_part "name=ssbl,size=2MiB;name=bootfs,type=linux,bootable,size=64MiB;name=rootfs,type=linux,size=512"
> - # gpt write mmc 1 ${emmc_part}
> -
> -b) copy SPL on eMMC on firts boot partition
> - (SPL max size is 256kB, with LBA 512, 0x200)
> -
> - # ext4load mmc 0:4 0xC0000000 u-boot-spl.stm32
> - # mmc dev 1
> - # mmc partconf 1 1 1 1
> - # mmc write ${fileaddr} 0 200
> - # mmc partconf 1 1 1 0
> -
> -c) copy U-Boot in first GPT partition of eMMC
> -
> - # ext4load mmc 0:4 0xC0000000 u-boot.img
> - # mmc dev 1
> - # part start mmc 1 1 partstart
> - # mmc write ${fileaddr} ${partstart} ${filesize}
> -
> -To boot from eMMC, select BootPinMode = 0 1 0 and reset.
> -
> -9. MAC Address
> -==============
> -
> -Please read doc/README.enetaddr for the implementation guidelines for mac id
> -usage. Basically, environment has precedence over board specific storage.
> -
> -For STMicroelectonics board, it is retrieved in STM32MP15x otp :
> -- OTP_57[31:0] = MAC_ADDR[31:0]
> -- OTP_58[15:0] = MAC_ADDR[47:32]
> -
> -To program a MAC address on virgin OTP words above, you can use the fuse command
> -on bank 0 to access to internal OTP:
> -
> - Prerequisite: check if a MAC address isn't yet programmed in OTP
> -
> - 1- check OTP: their value must be equal to 0
> -
> - STM32MP> fuse sense 0 57 2
> - Sensing bank 0:
> - Word 0x00000039: 00000000 00000000
> -
> - 2- check environment variable
> -
> - STM32MP> env print ethaddr
> - ## Error: "ethaddr" not defined
> -
> - Example to set mac address "12:34:56:78:9a:bc"
> -
> - 1- Write OTP
> - STM32MP> fuse prog -y 0 57 0x78563412 0x0000bc9a
> -
> - 2- Read OTP
> - STM32MP> fuse sense 0 57 2
> - Sensing bank 0:
> - Word 0x00000039: 78563412 0000bc9a
> -
> - 3- next REBOOT :
> - ### Setting environment from OTP MAC address = "12:34:56:78:9a:bc"
> -
> - 4 check env update
> - STM32MP> env print ethaddr
> - ethaddr=12:34:56:78:9a:bc
> -
> -warning:: This MAC address provisioning can't be executed twice on the same
> - board as the OTP are protected. It is already done for the board
> - provided by STMicroelectronics.
> -
> -10. Coprocessor firmware
> -========================
> -
> -U-Boot can boot the coprocessor before the kernel (coprocessor early boot).
> -
> -A/ Manuallly by using rproc commands (update the bootcmd)
> - Configurations
> - # env set name_copro "rproc-m4-fw.elf"
> - # env set dev_copro 0
> - # env set loadaddr_copro 0xC1000000
> -
> - Load binary from bootfs partition (number 4) on SDCard (mmc 0)
> - # ext4load mmc 0:4 ${loadaddr_copro} ${name_copro}
> - => ${filesize} updated with the size of the loaded file
> -
> - Start M4 firmware with remote proc command
> - # rproc init
> - # rproc load ${dev_copro} ${loadaddr_copro} ${filesize}
> - # rproc start ${dev_copro}
> -
> -B/ Automatically by using FIT feature and generic DISTRO bootcmd
> -
> - see examples in this directory :
> -
> - Generate FIT including kernel + device tree + M4 firmware
> - with cfg with M4 boot
> - $> mkimage -f fit_copro_kernel_dtb.its fit_copro_kernel_dtb.itb
> -
> - Then using DISTRO configuration file: see extlinux.conf to select
> - the correct configuration
> - => stm32mp157c-ev1-m4
> - => stm32mp157c-dk2-m4
> -
> -11. DFU support
> -===============
> -
> -The DFU is supported on ST board.
> -The env variable dfu_alt_info is automatically build, and all
> -the memory present on the ST boards are exported.
> -
> -The mode is started by
> -
> -STM32MP> dfu 0
> -
> -On EV1 board:
> -
> -STM32MP> dfu 0 list
> -
> -DFU alt settings list:
> -dev: RAM alt: 0 name: uImage layout: RAM_ADDR
> -dev: RAM alt: 1 name: devicetree.dtb layout: RAM_ADDR
> -dev: RAM alt: 2 name: uramdisk.image.gz layout: RAM_ADDR
> -dev: eMMC alt: 3 name: sdcard_fsbl1 layout: RAW_ADDR
> -dev: eMMC alt: 4 name: sdcard_fsbl2 layout: RAW_ADDR
> -dev: eMMC alt: 5 name: sdcard_ssbl layout: RAW_ADDR
> -dev: eMMC alt: 6 name: sdcard_bootfs layout: RAW_ADDR
> -dev: eMMC alt: 7 name: sdcard_vendorfs layout: RAW_ADDR
> -dev: eMMC alt: 8 name: sdcard_rootfs layout: RAW_ADDR
> -dev: eMMC alt: 9 name: sdcard_userfs layout: RAW_ADDR
> -dev: eMMC alt: 10 name: emmc_fsbl1 layout: RAW_ADDR
> -dev: eMMC alt: 11 name: emmc_fsbl2 layout: RAW_ADDR
> -dev: eMMC alt: 12 name: emmc_ssbl layout: RAW_ADDR
> -dev: eMMC alt: 13 name: emmc_bootfs layout: RAW_ADDR
> -dev: eMMC alt: 14 name: emmc_vendorfs layout: RAW_ADDR
> -dev: eMMC alt: 15 name: emmc_rootfs layout: RAW_ADDR
> -dev: eMMC alt: 16 name: emmc_userfs layout: RAW_ADDR
> -dev: MTD alt: 17 name: nor_fsbl1 layout: RAW_ADDR
> -dev: MTD alt: 18 name: nor_fsbl2 layout: RAW_ADDR
> -dev: MTD alt: 19 name: nor_ssbl layout: RAW_ADDR
> -dev: MTD alt: 20 name: nor_env layout: RAW_ADDR
> -dev: MTD alt: 21 name: nand_fsbl layout: RAW_ADDR
> -dev: MTD alt: 22 name: nand_ssbl1 layout: RAW_ADDR
> -dev: MTD alt: 23 name: nand_ssbl2 layout: RAW_ADDR
> -dev: MTD alt: 24 name: nand_UBI layout: RAW_ADDR
> -dev: VIRT alt: 25 name: OTP layout: RAW_ADDR
> -dev: VIRT alt: 26 name: PMIC layout: RAW_ADDR
> -
> -All the supported device are exported for dfu-util tool:
> -
> -$> dfu-util -l
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=26, name="PMIC", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=25, name="OTP", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=24, name="nand_UBI", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=23, name="nand_ssbl2", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=22, name="nand_ssbl1", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=21, name="nand_fsbl", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=20, name="nor_env", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=19, name="nor_ssbl", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=18, name="nor_fsbl2", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=17, name="nor_fsbl1", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=16, name="emmc_userfs", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=15, name="emmc_rootfs", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=14, name="emmc_vendorfs", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=13, name="emmc_bootfs", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=12, name="emmc_ssbl", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=11, name="emmc_fsbl2", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=10, name="emmc_fsbl1", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=9, name="sdcard_userfs", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=8, name="sdcard_rootfs", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=7, name="sdcard_vendorfs", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=6, name="sdcard_bootfs", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=5, name="sdcard_ssbl", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=4, name="sdcard_fsbl2", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=3, name="sdcard_fsbl1", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=2, name="uramdisk.image.gz", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=1, name="devicetree.dtb", serial="002700333338511934383330"
> -Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=0, name="uImage", serial="002700333338511934383330"
> -
> -You can update the boot device:
> -
> -#SDCARD
> -$> dfu-util -d 0483:5720 -a 3 -D tf-a-stm32mp157c-ev1-trusted.stm32
> -$> dfu-util -d 0483:5720 -a 4 -D tf-a-stm32mp157c-ev1-trusted.stm32
> -$> dfu-util -d 0483:5720 -a 5 -D u-boot-stm32mp157c-ev1-trusted.img
> -$> dfu-util -d 0483:5720 -a 6 -D st-image-bootfs-openstlinux-weston-stm32mp1.ext4
> -$> dfu-util -d 0483:5720 -a 7 -D st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
> -$> dfu-util -d 0483:5720 -a 8 -D st-image-weston-openstlinux-weston-stm32mp1.ext4
> -$> dfu-util -d 0483:5720 -a 9 -D st-image-userfs-openstlinux-weston-stm32mp1.ext4
> -
> -#EMMC
> -$> dfu-util -d 0483:5720 -a 10 -D tf-a-stm32mp157c-ev1-trusted.stm32
> -$> dfu-util -d 0483:5720 -a 11 -D tf-a-stm32mp157c-ev1-trusted.stm32
> -$> dfu-util -d 0483:5720 -a 12 -D u-boot-stm32mp157c-ev1-trusted.img
> -$> dfu-util -d 0483:5720 -a 13 -D st-image-bootfs-openstlinux-weston-stm32mp1.ext4
> -$> dfu-util -d 0483:5720 -a 14 -D st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
> -$> dfu-util -d 0483:5720 -a 15 -D st-image-weston-openstlinux-weston-stm32mp1.ext4
> -$> dfu-util -d 0483:5720 -a 16 -D st-image-userfs-openstlinux-weston-stm32mp1.ext4
> -
> -#NOR
> -$> dfu-util -d 0483:5720 -a 17 -D tf-a-stm32mp157c-ev1-trusted.stm32
> -$> dfu-util -d 0483:5720 -a 18 -D tf-a-stm32mp157c-ev1-trusted.stm32
> -$> dfu-util -d 0483:5720 -a 19 -D u-boot-stm32mp157c-ev1-trusted.img
> -
> -#NAND (UBI partition used for NAND only boot or NOR + NAND boot)
> -$> dfu-util -d 0483:5720 -a 21 -D tf-a-stm32mp157c-ev1-trusted.stm32
> -$> dfu-util -d 0483:5720 -a 22 -D u-boot-stm32mp157c-ev1-trusted.img
> -$> dfu-util -d 0483:5720 -a 23 -D u-boot-stm32mp157c-ev1-trusted.img
> -$> dfu-util -d 0483:5720 -a 24 -D st-image-weston-openstlinux-weston-stm32mp1_nand_4_256_multivolume.ubi
> -
> -And you can also dump the OTP and the PMIC NVM with:
> -
> -$> dfu-util -d 0483:5720 -a 25 -U otp.bin
> -$> dfu-util -d 0483:5720 -a 26 -U pmic.bin
> +see doc/board/st/stm32mp1.rst
> diff --git a/doc/board/index.rst b/doc/board/index.rst
> index 00e72f57cd..21fddd2f92 100644
> --- a/doc/board/index.rst
> +++ b/doc/board/index.rst
> @@ -15,4 +15,5 @@ Board-specific doc
> intel/index
> renesas/index
> sifive/index
> + st/index
> xilinx/index
> diff --git a/doc/board/st/index.rst b/doc/board/st/index.rst
> new file mode 100644
> index 0000000000..91f1d51b42
> --- /dev/null
> +++ b/doc/board/st/index.rst
> @@ -0,0 +1,9 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +STMicroelectronics
> +==================
> +
> +.. toctree::
> + :maxdepth: 2
> +
> + stm32mp1
> diff --git a/doc/board/st/stm32mp1.rst b/doc/board/st/stm32mp1.rst
> new file mode 100644
> index 0000000000..131f4902a3
> --- /dev/null
> +++ b/doc/board/st/stm32mp1.rst
> @@ -0,0 +1,598 @@
> +.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> +.. sectionauthor:: Patrick Delaunay <patrick.delaunay@st.com>
> +
> +STM32MP15x boards
> +=================
> +
> +This is a quick instruction for setup STM32MP15x boards.
> +
> +Supported devices
> +-----------------
> +
> +U-Boot supports STMP32MP15x SoCs:
> + - STM32MP157
> + - STM32MP153
> + - STM32MP151
> +
> +The STM32MP15x is a Cortex-A MPU aimed at various applications.
> +
> +It features:
> + - Dual core Cortex-A7 application core (Single on STM32MP151)
> + - 2D/3D image composition with GPU (only on STM32MP157)
> + - Standard memories interface support
> + - Standard connectivity, widely inherited from the STM32 MCU family
> + - Comprehensive security support
> +
> +Everything is supported in Linux but U-Boot is limited to:
> + 1. UART
> + 2. SD card/MMC controller (SDMMC)
> + 3. NAND controller (FMC)
> + 4. NOR controller (QSPI)
> + 5. USB controller (OTG DWC2)
> + 6. Ethernet controller
> +
> +And the necessary drivers
> + 1. I2C
> + 2. STPMIC1 (PMIC and regulator)
> + 3. Clock, Reset, Sysreset
> + 4. Fuse
> +
> +Currently the following boards are supported:
> + + stm32mp157a-avenger96.dts
> + + stm32mp157a-dk1.dts
> + + stm32mp157c-dk2.dts
> + + stm32mp157c-ed1.dts
> + + stm32mp157c-ev1.dts
> +
> +Boot Sequences
> +--------------
> +
> +3 boot configurations are supported with:
> +
> ++----------+------------------------+-------------------------+--------------+
> +| **ROM** | **FSBL** | **SSBL** | **OS** |
> ++ **code** +------------------------+-------------------------+--------------+
> +| | First Stage Bootloader | Second Stage Bootloader | Linux Kernel |
> ++ +------------------------+-------------------------+--------------+
> +| | embedded RAM | DDR |
> ++----------+------------------------+-------------------------+--------------+
> +
> +The **Trusted** boot chain
> +``````````````````````````
> +
> +defconfig_file : stm32mp15_trusted_defconfig
> +
> + +-------------+-------------------------+------------+-------+
> + | ROM code | FSBL | SSBL | OS |
> + + +-------------------------+------------+-------+
> + | |Trusted Firmware-A (TF-A)| U-Boot | Linux |
> + +-------------+-------------------------+------------+-------+
> + | TrustZone |TF-A secure monitor |
> + +-------------+-------------------------+------------+-------+
> +
> +TF-A performs a full initialization of Secure peripherals and installs a
> +secure monitor (BL32=SPMin).
> +
> +U-Boot is running in normal world and uses TF-A monitor to access
> +to secure resources.
> +
> +The **Trusted** boot chain with **OP-TEE**
> +``````````````````````````````````````````
> +
> +defconfig_file : stm32mp15_optee_defconfig
> +
> + +-------------+-------------------------+------------+-------+
> + | ROM code | FSBL | SSBL | OS |
> + + +-------------------------+------------+-------+
> + | |Trusted Firmware-A (TF-A)| U-Boot | Linux |
> + +-------------+-------------------------+------------+-------+
> + | TrustZone |OP-TEE |
> + +-------------+-------------------------+------------+-------+
> +
> +TF-A performs a full initialization of Secure peripherals and installs OP-TEE
> +from specific partitions (teeh, teed, teex).
> +
> +U-Boot is running in normal world and uses OP-TEE monitor to access
> +to secure resources.
> +
> +The **Basic** boot chain
> +````````````````````````
> +
> +defconfig_file : stm32mp15_basic_defconfig
> +
> + +-------------+------------+------------+-------+
> + | ROM code | FSBL | SSBL | OS |
> + + +------------+------------+-------+
> + | |U-Boot SPL | U-Boot | Linux |
> + +-------------+------------+------------+-------+
> + | TrustZone | | PSCI from U-Boot |
> + +-------------+------------+------------+-------+
> +
> +SPL has limited security initialization
> +
> +U-Boot is running in secure mode and provide a secure monitor to the kernel
> +with only PSCI support (Power State Coordination Interface defined by ARM).
> +
> +All the STM32MP15x boards supported by U-Boot use the same generic board
> +stm32mp1 which support all the bootable devices.
> +
> +Each board is configured only with the associated device tree.
> +
> +Device Tree Selection
> +---------------------
> +
> +You need to select the appropriate device tree for your board,
> +the supported device trees for STM32MP15x are:
> +
> ++ ev1: eval board with pmic stpmic1 (ev1 = mother board + daughter ed1)
> + + stm32mp157c-ev1
> +
> ++ ed1: daughter board with pmic stpmic1
> + + stm32mp157c-ed1
> +
> ++ dk1: Discovery board
> + + stm32mp157a-dk1
> +
> ++ dk2: Discovery board = dk1 with a BT/WiFI combo and a DSI panel
> + + stm32mp157c-dk2
> +
> ++ avenger96: Avenger96 board from Arrow Electronics
> + + stm32mp157a-avenger96
> +
> +Build Procedure
> +---------------
> +
> +1. Install the required tools for U-Boot
> +
> + * install package needed in U-Boot makefile
> + (libssl-dev, swig, libpython-dev...)
> +
> + * install ARMv7 toolchain for 32bit Cortex-A (from Linaro,
> + from SDK for STM32MP15x, or any crosstoolchains from your distribution)
> + (you can use any gcc cross compiler compatible with U-Boot)
> +
> +2. Set the cross compiler::
> +
> + # export CROSS_COMPILE=/path/to/toolchain/arm-linux-gnueabi-
> +
> +3. Select the output directory (optional)::
> +
> + # export KBUILD_OUTPUT=/path/to/output
> +
> + for example: use one output directory for each configuration::
> +
> + # export KBUILD_OUTPUT=stm32mp15_trusted
> + # export KBUILD_OUTPUT=stm32mp15_optee
> + # export KBUILD_OUTPUT=stm32mp15_basic
> +
> + you can build outside of code directory::
> +
> + # export KBUILD_OUTPUT=../build/stm32mp15_trusted
> +
> +4. Configure U-Boot::
> +
> + # make <defconfig_file>
> +
> + with <defconfig_file>:
> +
> + - For **trusted** boot mode : **stm32mp15_trusted_defconfig**
> + - For **trusted** with OP-TEE boot mode : **stm32mp15_optee_defconfig**
> + - For basic boot mode: stm32mp15_basic_defconfig
> +
> +5. Configure the device-tree and build the U-Boot image::
> +
> + # make DEVICE_TREE=<name> all
> +
> + Examples:
> +
> + a) trusted boot on ev1::
> +
> + # export KBUILD_OUTPUT=stm32mp15_trusted
> + # make stm32mp15_trusted_defconfig
> + # make DEVICE_TREE=stm32mp157c-ev1 all
> +
> + b) trusted with OP-TEE boot on dk2::
> +
> + # export KBUILD_OUTPUT=stm32mp15_optee
> + # make stm32mp15_optee_defconfig
> + # make DEVICE_TREE=stm32mp157c-dk2 all
> +
> + c) basic boot on ev1::
> +
> + # export KBUILD_OUTPUT=stm32mp15_basic
> + # make stm32mp15_basic_defconfig
> + # make DEVICE_TREE=stm32mp157c-ev1 all
> +
> + d) basic boot on ed1::
> +
> + # export KBUILD_OUTPUT=stm32mp15_basic
> + # make stm32mp15_basic_defconfig
> + # make DEVICE_TREE=stm32mp157c-ed1 all
> +
> + e) basic boot on dk1::
> +
> + # export KBUILD_OUTPUT=stm32mp15_basic
> + # make stm32mp15_basic_defconfig
> + # make DEVICE_TREE=stm32mp157a-dk1 all
> +
> + f) basic boot on avenger96::
> +
> + # export KBUILD_OUTPUT=stm32mp15_basic
> + # make stm32mp15_basic_defconfig
> + # make DEVICE_TREE=stm32mp157a-avenger96 all
> +
> +6. Output files
> +
> + BootRom and TF-A expect binaries with STM32 image header
> + SPL expects file with U-Boot uImage header
> +
> + So in the output directory (selected by KBUILD_OUTPUT),
> + you can found the needed files:
> +
> + - For **Trusted** boot (with or without OP-TEE)
> + - FSBL = **tf-a.stm32** (provided by TF-A compilation)
> + - SSBL = **u-boot.stm32**
> +
> + - For Basic boot
> + - FSBL = spl/u-boot-spl.stm32
> + - SSBL = u-boot.img
> +
> +Switch Setting for Boot Mode
> +----------------------------
> +
> +You can select the boot mode, on the board with one switch, to select
> +the boot pin values = BOOT0, BOOT1, BOOT2
> +
> + +-------------+---------+---------+---------+
> + |*Boot Mode* | *BOOT2* | *BOOT1* | *BOOT0* |
> + +=============+=========+=========+=========+
> + | Recovery | 0 | 0 | 0 |
> + +-------------+---------+---------+---------+
> + | NOR | 0 | 0 | 1 |
> + +-------------+---------+---------+---------+
> + | eMMC | 0 | 1 | 0 |
> + +-------------+---------+---------+---------+
> + | NAND | 0 | 1 | 1 |
> + +-------------+---------+---------+---------+
> + | Reserved | 1 | 0 | 0 |
> + +-------------+---------+---------+---------+
> + | SD-Card | 1 | 0 | 1 |
> + +-------------+---------+---------+---------+
> + | Recovery | 1 | 1 | 0 |
> + +-------------+---------+---------+---------+
> + | SPI-NAND | 1 | 1 | 1 |
> + +-------------+---------+---------+---------+
> +
> +- on the **daugther board ed1 = MB1263** with the switch SW1
> +- on **Avenger96** with switch S3 (NOR and SPI-NAND are not applicable)
> +- on board **DK1/DK2** with the switch SW1 = BOOT0, BOOT2
> + with only 2 pins available (BOOT1 is forced to 0 and NOR not supported),
> + the possible value becomes:
> +
> + +-------------+---------+---------+
> + |*Boot Mode* | *BOOT2* | *BOOT0* |
> + +=============+=========+=========+
> + | Recovery | 0 | 0 |
> + +-------------+---------+---------+
> + | NOR (NA)| 0 | 1 |
> + +-------------+---------+---------+
> + | Reserved | 1 | 0 |
> + +-------------+---------+---------+
> + | SD-Card | 1 | 1 |
> + +-------------+---------+---------+
> +
> +Recovery is a boot from serial link (UART/USB) and it is used with
> +STM32CubeProgrammer tool to load executable in RAM and to update the flash
> +devices available on the board (NOR/NAND/eMMC/SD card).
> +
> +The communication between HOST and board is based on
> + - for UARTs : the uart protocol used with all MCU STM32
> + - for USB : based on USB DFU 1.1 (without the ST extensions used on MCU STM32)
> +
> +Prepare an SD card
> +------------------
> +
> +The minimal requirements for STMP32MP15x boot up to U-Boot are:
> +
> +- GPT partitioning (with gdisk or with sgdisk)
> +- 2 fsbl partitions, named fsbl1 and fsbl2, size at least 256KiB
> +- one ssbl partition for U-Boot
> +
> +Then the minimal GPT partition is:
> +
> + +-------+--------+---------+-------------+
> + | *Num* | *Name* | *Size* | *Content* |
> + +=======+========+=========+=============+
> + | 1 | fsbl1 | 256 KiB | TF-A or SPL |
> + +-------+--------+---------+-------------+
> + | 2 | fsbl2 | 256 KiB | TF-A or SPL |
> + +-------+--------+---------+-------------+
> + | 3 | ssbl | enought | U-Boot |
> + +-------+--------+---------+-------------+
> + | 4 | <any> | <any> | Rootfs |
> + +-------+--------+---------+-------------+
> +
> +Add a 4th partition (Rootfs) marked bootable with a file extlinux.conf
> +following the Generic Distribution feature (doc/README.distro for use).
> +
> +According the used card reader select the correct block device
> +(for example /dev/sdx or /dev/mmcblk0).
> +
> +In the next example, it is /dev/mmcblk0
> +
> +For example: with gpt table with 128 entries
> +
> +a) remove previous formatting::
> +
> + # sgdisk -o /dev/<SD card dev>
> +
> +b) create minimal image::
> +
> + # sgdisk --resize-table=128 -a 1 \
> + -n 1:34:545 -c 1:fsbl1 \
> + -n 2:546:1057 -c 2:fsbl2 \
> + -n 3:1058:5153 -c 3:ssbl \
> + -n 4:5154: -c 4:rootfs \
> + -p /dev/<SD card dev>
> +
> + With other partition for kernel one partition rootfs for kernel.
> +
> +c) copy the FSBL (2 times) and SSBL file on the correct partition.
> + in this example in partition 1 to 3
> +
> + for basic boot mode : <SD card dev> = /dev/mmcblk0::
> +
> + # dd if=u-boot-spl.stm32 of=/dev/mmcblk0p1
> + # dd if=u-boot-spl.stm32 of=/dev/mmcblk0p2
> + # dd if=u-boot.img of=/dev/mmcblk0p3
> +
> + for trusted boot mode: ::
> +
> + # dd if=tf-a.stm32 of=/dev/mmcblk0p1
> + # dd if=tf-a.stm32 of=/dev/mmcblk0p2
> + # dd if=u-boot.stm32 of=/dev/mmcblk0p3
> +
> +To boot from SD card, select BootPinMode = 1 0 1 and reset.
> +
> +Prepare eMMC
> +------------
> +
> +You can use U-Boot to copy binary in eMMC.
> +
> +In the next example, you need to boot from SD card and the images
> +(u-boot-spl.stm32, u-boot.img) are presents on SD card (mmc 0)
> +in ext4 partition 4 (bootfs).
> +
> +To boot from SD card, select BootPinMode = 1 0 1 and reset.
> +
> +Then you update the eMMC with the next U-Boot command :
> +
> +a) prepare GPT on eMMC,
> + example with 2 partitions, bootfs and roots::
> +
> + # setenv emmc_part "name=ssbl,size=2MiB;name=bootfs,type=linux,bootable,size=64MiB;name=rootfs,type=linux,size=512"
> + # gpt write mmc 1 ${emmc_part}
> +
> +b) copy SPL on eMMC on firts boot partition
> + (SPL max size is 256kB, with LBA 512, 0x200)::
> +
> + # ext4load mmc 0:4 0xC0000000 u-boot-spl.stm32
> + # mmc dev 1
> + # mmc partconf 1 1 1 1
> + # mmc write ${fileaddr} 0 200
> + # mmc partconf 1 1 1 0
> +
> +c) copy U-Boot in first GPT partition of eMMC::
> +
> + # ext4load mmc 0:4 0xC0000000 u-boo t.img
> + # mmc dev 1
> + # part start mmc 1 1 partstart
> + # mmc write ${fileaddr} ${partstart} ${filesize}
> +
> +To boot from eMMC, select BootPinMode = 0 1 0 and reset.
> +
> +MAC Address
> +-----------
> +
> +Please read doc/README.enetaddr for the implementation guidelines for mac id
> +usage. Basically, environment has precedence over board specific storage.
> +
> +For STMicroelectonics board, it is retrieved in STM32MP15x OTP :
> + - OTP_57[31:0] = MAC_ADDR[31:0]
> + - OTP_58[15:0] = MAC_ADDR[47:32]
> +
> +To program a MAC address on virgin OTP words above, you can use the fuse command
> +on bank 0 to access to internal OTP:
> +
> +Prerequisite: check if a MAC address isn't yet programmed in OTP
> +
> +1) check OTP: their value must be equal to 0
> +
> + STM32MP> fuse sense 0 57 2
> + Sensing bank 0:
> + Word 0x00000039: 00000000 00000000
> +
> +2) check environment variable
> +
> + STM32MP> env print ethaddr
> + ## Error: "ethaddr" not defined
> +
> +Example to set mac address "12:34:56:78:9a:bc"
> +
> +1) Write OTP::
> +
> + STM32MP> fuse prog -y 0 57 0x78563412 0x0000bc9a
> +
> +2) Read OTP::
> +
> + STM32MP> fuse sense 0 57 2
> + Sensing bank 0:
> + Word 0x00000039: 78563412 0000bc9a
> +
> +3) next REBOOT, in the trace::
> +
> + ### Setting environment from OTP MAC address = "12:34:56:78:9a:bc"
> +
> +4) check env update::
> +
> + STM32MP> env print ethaddr
> + ethaddr=12:34:56:78:9a:bc
> +
> +.. warning:: This command can't be executed twice on the same board as
> + OTP are protected. It is already done for the board
> + provided by STMicroelectronics.
> +
> +Coprocessor firmware
> +--------------------
> +
> +U-Boot can boot the coprocessor before the kernel (coprocessor early boot).
> +
> +a) Manuallly by using rproc commands (update the bootcmd)
> +
> + Configurations::
> +
> + # env set name_copro "rproc-m4-fw.elf"
> + # env set dev_copro 0
> + # env set loadaddr_copro 0xC1000000
> +
> + Load binary from bootfs partition (number 4) on SD card (mmc 0)::
> +
> + # ext4load mmc 0:4 ${loadaddr_copro} ${name_copro}
> +
> + => ${filesize} variable is updated with the size of the loaded file.
> +
> + Start M4 firmware with remote proc command::
> +
> + # rproc init
> + # rproc load ${dev_copro} ${loadaddr_copro} ${filesize}
> + # rproc start ${dev_copro}"00270033
> +
> +b) Automatically by using FIT feature and generic DISTRO bootcmd
> +
> + see examples in the board stm32mp1 directory: fit_copro_kernel_dtb.its
> +
> + Generate FIT including kernel + device tree + M4 firmware with cfg with M4 boot::
> +
> + $> mkimage -f fit_copro_kernel_dtb.its fit_copro_kernel_dtb.itb
> +
> + Then using DISTRO configuration file: see extlinux.conf to select the correct
> + configuration:
> +
> + - stm32mp157c-ev1-m4
> + - stm32mp157c-dk2-m4
> +
> +DFU support
> +-----------
> +
> +The DFU is supported on ST board.
> +
> +The env variable dfu_alt_info is automatically build, and all
> +the memory present on the ST boards are exported.
> +
> +The dfu mode is started by the command::
> +
> + STM32MP> dfu 0
> +
> +On EV1 board, booting from SD card, without OP-TEE::
> +
> + STM32MP> dfu 0 list
> + DFU alt settings list:
> + dev: RAM alt: 0 name: uImage layout: RAM_ADDR
> + dev: RAM alt: 1 name: devicetree.dtb layout: RAM_ADDR
> + dev: RAM alt: 2 name: uramdisk.image.gz layout: RAM_ADDR
> + dev: eMMC alt: 3 name: sdcard_fsbl1 layout: RAW_ADDR
> + dev: eMMC alt: 4 name: sdcard_fsbl2 layout: RAW_ADDR
> + dev: eMMC alt: 5 name: sdcard_ssbl layout: RAW_ADDR
> + dev: eMMC alt: 6 name: sdcard_bootfs layout: RAW_ADDR
> + dev: eMMC alt: 7 name: sdcard_vendorfs layout: RAW_ADDR
> + dev: eMMC alt: 8 name: sdcard_rootfs layout: RAW_ADDR
> + dev: eMMC alt: 9 name: sdcard_userfs layout: RAW_ADDR
> + dev: eMMC alt: 10 name: emmc_fsbl1 layout: RAW_ADDR
> + dev: eMMC alt: 11 name: emmc_fsbl2 layout: RAW_ADDR
> + dev: eMMC alt: 12 name: emmc_ssbl layout: RAW_ADDR
> + dev: eMMC alt: 13 name: emmc_bootfs layout: RAW_ADDR
> + dev: eMMC alt: 14 name: emmc_vendorfs layout: RAW_ADDR
> + dev: eMMC alt: 15 name: emmc_rootfs layout: RAW_ADDR
> + dev: eMMC alt: 16 name: emmc_userfs layout: RAW_ADDR
> + dev: MTD alt: 17 name: nor_fsbl1 layout: RAW_ADDR
> + dev: MTD alt: 18 name: nor_fsbl2 layout: RAW_ADDR
> + dev: MTD alt: 19 name: nor_ssbl layout: RAW_ADDR
> + dev: MTD alt: 20 name: nor_env layout: RAW_ADDR
> + dev: MTD alt: 21 name: nand_fsbl layout: RAW_ADDR
> + dev: MTD alt: 22 name: nand_ssbl1 layout: RAW_ADDR
> + dev: MTD alt: 23 name: nand_ssbl2 layout: RAW_ADDR
> + dev: MTD alt: 24 name: nand_UBI layout: RAW_ADDR
> + dev: VIRT alt: 25 name: OTP layout: RAW_ADDR
> + dev: VIRT alt: 26 name: PMIC layout: RAW_ADDR
> +
> +All the supported device are exported for dfu-util tool::
> +
> + $> dfu-util -l
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=26, name="PMIC", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=25, name="OTP", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=24, name="nand_UBI", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=23, name="nand_ssbl2", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=22, name="nand_ssbl1", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=21, name="nand_fsbl", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=20, name="nor_env", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=19, name="nor_ssbl", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=18, name="nor_fsbl2", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=17, name="nor_fsbl1", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=16, name="emmc_userfs", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=15, name="emmc_rootfs", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=14, name="emmc_vendorfs", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=13, name="emmc_bootfs", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=12, name="emmc_ssbl", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=11, name="emmc_fsbl2", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=10, name="emmc_fsbl1", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=9, name="sdcard_userfs", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=8, name="sdcard_rootfs", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=7, name="sdcard_vendorfs", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=6, name="sdcard_bootfs", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=5, name="sdcard_ssbl", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=4, name="sdcard_fsbl2", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=3, name="sdcard_fsbl1", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=2, name="uramdisk.image.gz", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=1, name="devicetree.dtb", serial="002700333338511934383330"
> + Found DFU: [0483:5720] ver=9999, devnum=99, cfg=1, intf=0, alt=0, name="uImage", serial="002700333338511934383330"
> +
> +You can update the boot device:
> +
> +- SD card (mmc0) ::
> +
> + $> dfu-util -d 0483:5720 -a 3 -D tf-a-stm32mp157c-ev1-trusted.stm32
> + $> dfu-util -d 0483:5720 -a 4 -D tf-a-stm32mp157c-ev1-trusted.stm32
> + $> dfu-util -d 0483:5720 -a 5 -D u-boot-stm32mp157c-ev1-trusted.img
> + $> dfu-util -d 0483:5720 -a 6 -D st-image-bootfs-openstlinux-weston-stm32mp1.ext4
> + $> dfu-util -d 0483:5720 -a 7 -D st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
> + $> dfu-util -d 0483:5720 -a 8 -D st-image-weston-openstlinux-weston-stm32mp1.ext4
> + $> dfu-util -d 0483:5720 -a 9 -D st-image-userfs-openstlinux-weston-stm32mp1.ext4
> +
> +- EMMC (mmc1)::
> +
> + $> dfu-util -d 0483:5720 -a 10 -D tf-a-stm32mp157c-ev1-trusted.stm32
> + $> dfu-util -d 0483:5720 -a 11 -D tf-a-stm32mp157c-ev1-trusted.stm32
> + $> dfu-util -d 0483:5720 -a 12 -D u-boot-stm32mp157c-ev1-trusted.img
> + $> dfu-util -d 0483:5720 -a 13 -D st-image-bootfs-openstlinux-weston-stm32mp1.ext4
> + $> dfu-util -d 0483:5720 -a 14 -D st-image-vendorfs-openstlinux-weston-stm32mp1.ext4
> + $> dfu-util -d 0483:5720 -a 15 -D st-image-weston-openstlinux-weston-stm32mp1.ext4
> + $> dfu-util -d 0483:5720 -a 16 -D st-image-userfs-openstlinux-weston-stm32mp1.ext4
> +
> +- NOR::
> +
> + $> dfu-util -d 0483:5720 -a 17 -D tf-a-stm32mp157c-ev1-trusted.stm32
> + $> dfu-util -d 0483:5720 -a 18 -D tf-a-stm32mp157c-ev1-trusted.stm32
> + $> dfu-util -d 0483:5720 -a 19 -D u-boot-stm32mp157c-ev1-trusted.img
> +
> +- NAND (UBI partition used for NAND only boot or NOR + NAND boot)::
> +
> + $> dfu-util -d 0483:5720 -a 21 -D tf-a-stm32mp157c-ev1-trusted.stm32
> + $> dfu-util -d 0483:5720 -a 22 -D u-boot-stm32mp157c-ev1-trusted.img
> + $> dfu-util -d 0483:5720 -a 23 -D u-boot-stm32mp157c-ev1-trusted.img
> + $> dfu-util -d 0483:5720 -a 24 -D st-image-weston-openstlinux-weston-stm32mp1_nand_4_256_multivolume.ubi
> +
> +- you can also dump the OTP and the PMIC NVM with::
> +
> + $> dfu-util -d 0483:5720 -a 25 -U otp.bin
> + $> dfu-util -d 0483:5720 -a 26 -U pmic.bin
> +
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Thanks
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 2/9] stm32mp1: pwr: use the last binding for pwr
2020-01-28 9:10 ` [PATCH 2/9] stm32mp1: pwr: use the last binding for pwr Patrick Delaunay
@ 2020-02-13 8:16 ` Patrice CHOTARD
2020-02-14 10:25 ` Patrick DELAUNAY
1 sibling, 0 replies; 38+ messages in thread
From: Patrice CHOTARD @ 2020-02-13 8:16 UTC (permalink / raw)
To: u-boot
On 1/28/20 10:10 AM, Patrick Delaunay wrote:
> Update the driver to use the latest binding from kernel v5.5-rc1:
> no more use syscon or regmap to access to pwr register and
> only one pwr_regulators node with the compatibility "st,stm32mp1,pwr-reg"
> is available.
>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
> ---
>
> arch/arm/dts/stm32mp157-u-boot.dtsi | 2 +-
> arch/arm/dts/stm32mp157a-avenger96.dts | 8 ++--
> arch/arm/dts/stm32mp157a-dk1.dts | 8 ++--
> arch/arm/dts/stm32mp157c-ed1.dts | 8 ++--
> arch/arm/dts/stm32mp157c.dtsi | 46 +++++++++-------------
> arch/arm/dts/stm32mp15xx-dhcom.dtsi | 8 ++--
> arch/arm/mach-stm32mp/include/mach/stm32.h | 1 -
> arch/arm/mach-stm32mp/pwr_regulator.c | 23 ++++++-----
> arch/arm/mach-stm32mp/syscon.c | 1 -
> 9 files changed, 42 insertions(+), 63 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp157-u-boot.dtsi b/arch/arm/dts/stm32mp157-u-boot.dtsi
> index 0d1d387e54..cb8d60e33d 100644
> --- a/arch/arm/dts/stm32mp157-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157-u-boot.dtsi
> @@ -128,7 +128,7 @@
> u-boot,dm-pre-reloc;
> };
>
> -&pwr {
> +&pwr_regulators {
> u-boot,dm-pre-reloc;
> };
>
> diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts b/arch/arm/dts/stm32mp157a-avenger96.dts
> index 5b15a4a915..232fe70905 100644
> --- a/arch/arm/dts/stm32mp157a-avenger96.dts
> +++ b/arch/arm/dts/stm32mp157a-avenger96.dts
> @@ -282,11 +282,9 @@
> status = "okay";
> };
>
> -&pwr {
> - pwr-regulators {
> - vdd-supply = <&vdd>;
> - vdd_3v3_usbfs-supply = <&vdd_usb>;
> - };
> +&pwr_regulators {
> + vdd-supply = <&vdd>;
> + vdd_3v3_usbfs-supply = <&vdd_usb>;
> };
>
> &rng1 {
> diff --git a/arch/arm/dts/stm32mp157a-dk1.dts b/arch/arm/dts/stm32mp157a-dk1.dts
> index 4652253012..dc61bfc3d5 100644
> --- a/arch/arm/dts/stm32mp157a-dk1.dts
> +++ b/arch/arm/dts/stm32mp157a-dk1.dts
> @@ -397,11 +397,9 @@
> status = "okay";
> };
>
> -&pwr {
> - pwr-regulators {
> - vdd-supply = <&vdd>;
> - vdd_3v3_usbfs-supply = <&vdd_usb>;
> - };
> +&pwr_regulators {
> + vdd-supply = <&vdd>;
> + vdd_3v3_usbfs-supply = <&vdd_usb>;
> };
>
> &rng1 {
> diff --git a/arch/arm/dts/stm32mp157c-ed1.dts b/arch/arm/dts/stm32mp157c-ed1.dts
> index bc4d7e1ab5..acb59f24cc 100644
> --- a/arch/arm/dts/stm32mp157c-ed1.dts
> +++ b/arch/arm/dts/stm32mp157c-ed1.dts
> @@ -263,11 +263,9 @@
> status = "okay";
> };
>
> -&pwr {
> - pwr-regulators {
> - vdd-supply = <&vdd>;
> - vdd_3v3_usbfs-supply = <&vdd_usb>;
> - };
> +&pwr_regulators {
> + vdd-supply = <&vdd>;
> + vdd_3v3_usbfs-supply = <&vdd_usb>;
> };
>
> &rng1 {
> diff --git a/arch/arm/dts/stm32mp157c.dtsi b/arch/arm/dts/stm32mp157c.dtsi
> index 28a7e4c08a..22a9386248 100644
> --- a/arch/arm/dts/stm32mp157c.dtsi
> +++ b/arch/arm/dts/stm32mp157c.dtsi
> @@ -1110,36 +1110,26 @@
> #reset-cells = <1>;
> };
>
> - pwr: pwr at 50001000 {
> - compatible = "st,stm32mp1-pwr", "st,stm32-pwr", "syscon", "simple-mfd";
> - reg = <0x50001000 0x400>;
> - system-power-controller;
> - interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
> - st,sysrcc = <&rcc>;
> - clocks = <&rcc PLL2_R>;
> - clock-names = "phyclk";
> -
> - pwr-regulators {
> - compatible = "st,stm32mp1,pwr-reg";
> - st,tzcr = <&rcc 0x0 0x1>;
> -
> - reg11: reg11 {
> - regulator-name = "reg11";
> - regulator-min-microvolt = <1100000>;
> - regulator-max-microvolt = <1100000>;
> - };
> + pwr_regulators: pwr at 50001000 {
> + compatible = "st,stm32mp1,pwr-reg";
> + reg = <0x50001000 0x10>;
> +
> + reg11: reg11 {
> + regulator-name = "reg11";
> + regulator-min-microvolt = <1100000>;
> + regulator-max-microvolt = <1100000>;
> + };
>
> - reg18: reg18 {
> - regulator-name = "reg18";
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - };
> + reg18: reg18 {
> + regulator-name = "reg18";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
>
> - usb33: usb33 {
> - regulator-name = "usb33";
> - regulator-min-microvolt = <3300000>;
> - regulator-max-microvolt = <3300000>;
> - };
> + usb33: usb33 {
> + regulator-name = "usb33";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> };
> };
>
> diff --git a/arch/arm/dts/stm32mp15xx-dhcom.dtsi b/arch/arm/dts/stm32mp15xx-dhcom.dtsi
> index 96661ae783..bed69c97b6 100644
> --- a/arch/arm/dts/stm32mp15xx-dhcom.dtsi
> +++ b/arch/arm/dts/stm32mp15xx-dhcom.dtsi
> @@ -217,11 +217,9 @@
> status = "okay";
> };
>
> -&pwr {
> - pwr-regulators {
> - vdd-supply = <&vdd>;
> - vdd_3v3_usbfs-supply = <&vdd_usb>;
> - };
> +&pwr_regulators {
> + vdd-supply = <&vdd>;
> + vdd_3v3_usbfs-supply = <&vdd_usb>;
> };
>
> &qspi {
> diff --git a/arch/arm/mach-stm32mp/include/mach/stm32.h b/arch/arm/mach-stm32mp/include/mach/stm32.h
> index 88126b8cdb..f0636005e5 100644
> --- a/arch/arm/mach-stm32mp/include/mach/stm32.h
> +++ b/arch/arm/mach-stm32mp/include/mach/stm32.h
> @@ -37,7 +37,6 @@
> /* enumerated used to identify the SYSCON driver instance */
> enum {
> STM32MP_SYSCON_UNKNOWN,
> - STM32MP_SYSCON_PWR,
> STM32MP_SYSCON_SYSCFG,
> };
>
> diff --git a/arch/arm/mach-stm32mp/pwr_regulator.c b/arch/arm/mach-stm32mp/pwr_regulator.c
> index 9484645dbd..f00e7527c2 100644
> --- a/arch/arm/mach-stm32mp/pwr_regulator.c
> +++ b/arch/arm/mach-stm32mp/pwr_regulator.c
> @@ -6,8 +6,8 @@
> #include <common.h>
> #include <dm.h>
> #include <errno.h>
> -#include <regmap.h>
> #include <syscon.h>
> +#include <asm/io.h>
> #include <power/pmic.h>
> #include <power/regulator.h>
>
> @@ -26,7 +26,7 @@ struct stm32mp_pwr_reg_info {
> };
>
> struct stm32mp_pwr_priv {
> - struct regmap *regmap;
> + fdt_addr_t base;
> };
>
> static int stm32mp_pwr_write(struct udevice *dev, uint reg,
> @@ -38,7 +38,9 @@ static int stm32mp_pwr_write(struct udevice *dev, uint reg,
> if (len != 4)
> return -EINVAL;
>
> - return regmap_write(priv->regmap, STM32MP_PWR_CR3, val);
> + writel(val, priv->base + STM32MP_PWR_CR3);
> +
> + return 0;
> }
>
> static int stm32mp_pwr_read(struct udevice *dev, uint reg, uint8_t *buff,
> @@ -49,21 +51,18 @@ static int stm32mp_pwr_read(struct udevice *dev, uint reg, uint8_t *buff,
> if (len != 4)
> return -EINVAL;
>
> - return regmap_read(priv->regmap, STM32MP_PWR_CR3, (u32 *)buff);
> + *(u32 *)buff = readl(priv->base + STM32MP_PWR_CR3);
> +
> + return 0;
> }
>
> static int stm32mp_pwr_ofdata_to_platdata(struct udevice *dev)
> {
> struct stm32mp_pwr_priv *priv = dev_get_priv(dev);
> - struct regmap *regmap;
>
> - regmap = syscon_get_regmap_by_driver_data(STM32MP_SYSCON_PWR);
> - if (IS_ERR(regmap)) {
> - pr_err("%s: unable to find regmap (%ld)\n", __func__,
> - PTR_ERR(regmap));
> - return PTR_ERR(regmap);
> - }
> - priv->regmap = regmap;
> + priv->base = dev_read_addr(dev);
> + if (priv->base == FDT_ADDR_T_NONE)
> + return -EINVAL;
>
> return 0;
> }
> diff --git a/arch/arm/mach-stm32mp/syscon.c b/arch/arm/mach-stm32mp/syscon.c
> index 6070837bf0..3e61ce4097 100644
> --- a/arch/arm/mach-stm32mp/syscon.c
> +++ b/arch/arm/mach-stm32mp/syscon.c
> @@ -9,7 +9,6 @@
> #include <asm/arch/stm32.h>
>
> static const struct udevice_id stm32mp_syscon_ids[] = {
> - { .compatible = "st,stm32mp1-pwr", .data = STM32MP_SYSCON_PWR },
> { .compatible = "st,stm32mp157-syscfg",
> .data = STM32MP_SYSCON_SYSCFG },
> { }
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Thanks
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 9/9] stm32mp1: support of STM32MP15x Rev.Z
2020-01-28 9:11 ` [PATCH 9/9] stm32mp1: support of STM32MP15x Rev.Z Patrick Delaunay
@ 2020-02-13 12:34 ` Patrice CHOTARD
2020-02-14 10:29 ` Patrick DELAUNAY
1 sibling, 0 replies; 38+ messages in thread
From: Patrice CHOTARD @ 2020-02-13 12:34 UTC (permalink / raw)
To: u-boot
On 1/28/20 10:11 AM, Patrick Delaunay wrote:
> Add support for Rev.Z of STM32MP15x cpu.
>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
> ---
>
> arch/arm/mach-stm32mp/cpu.c | 3 +++
> arch/arm/mach-stm32mp/include/mach/sys_proto.h | 1 +
> 2 files changed, 4 insertions(+)
>
> diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
> index de7891b5c4..ea0bd94605 100644
> --- a/arch/arm/mach-stm32mp/cpu.c
> +++ b/arch/arm/mach-stm32mp/cpu.c
> @@ -342,6 +342,9 @@ int print_cpuinfo(void)
> case CPU_REVB:
> cpu_r = "B";
> break;
> + case CPU_REVZ:
> + cpu_r = "Z";
> + break;
> default:
> cpu_r = "?";
> break;
> diff --git a/arch/arm/mach-stm32mp/include/mach/sys_proto.h b/arch/arm/mach-stm32mp/include/mach/sys_proto.h
> index 47e57922d1..da46c11573 100644
> --- a/arch/arm/mach-stm32mp/include/mach/sys_proto.h
> +++ b/arch/arm/mach-stm32mp/include/mach/sys_proto.h
> @@ -16,6 +16,7 @@ u32 get_cpu_type(void);
>
> #define CPU_REVA 0x1000
> #define CPU_REVB 0x2000
> +#define CPU_REVZ 0x2001
>
> /* return CPU_REV constants */
> u32 get_cpu_rev(void);
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Thanks
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 1/9] ARM: dts: stm32mp1: DT alignment with kernel v5.4
2020-01-28 9:10 ` [PATCH 1/9] ARM: dts: stm32mp1: DT alignment with kernel v5.4 Patrick Delaunay
2020-02-13 8:11 ` [Uboot-stm32] " Patrice CHOTARD
@ 2020-02-14 10:25 ` Patrick DELAUNAY
1 sibling, 0 replies; 38+ messages in thread
From: Patrick DELAUNAY @ 2020-02-14 10:25 UTC (permalink / raw)
To: u-boot
Hi,
> From: Patrick DELAUNAY <patrick.delaunay@st.com>
> Sent: mardi 28 janvier 2020 10:11
>
> Device tree and binding alignment with kernel v5.4
>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
> ---
Applied to u-boot-stm32/master, thanks!
Regards
Patrick
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 2/9] stm32mp1: pwr: use the last binding for pwr
2020-01-28 9:10 ` [PATCH 2/9] stm32mp1: pwr: use the last binding for pwr Patrick Delaunay
2020-02-13 8:16 ` Patrice CHOTARD
@ 2020-02-14 10:25 ` Patrick DELAUNAY
1 sibling, 0 replies; 38+ messages in thread
From: Patrick DELAUNAY @ 2020-02-14 10:25 UTC (permalink / raw)
To: u-boot
Hi,
> From: Patrick DELAUNAY <patrick.delaunay@st.com>
> Sent: mardi 28 janvier 2020 10:11
>
> Update the driver to use the latest binding from kernel v5.5-rc1:
> no more use syscon or regmap to access to pwr register and only one
> pwr_regulators node with the compatibility "st,stm32mp1,pwr-reg"
> is available.
>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
> ---
Applied to u-boot-stm32/master, thanks!
Regards
Patrick
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 3/9] ARM: dts: stm32mp1: DT alignment with kernel v5.5-rc7
2020-01-28 9:11 ` [PATCH 3/9] ARM: dts: stm32mp1: DT alignment with kernel v5.5-rc7 Patrick Delaunay
2020-02-13 8:12 ` [Uboot-stm32] " Patrice CHOTARD
@ 2020-02-14 10:26 ` Patrick DELAUNAY
1 sibling, 0 replies; 38+ messages in thread
From: Patrick DELAUNAY @ 2020-02-14 10:26 UTC (permalink / raw)
To: u-boot
Hi,
> From: Patrick DELAUNAY <patrick.delaunay@st.com>
> Sent: mardi 28 janvier 2020 10:11
>
> Device tree and binding alignment with kernel v5.5-rc7
>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
> ---
Applied to u-boot-stm32/master, thanks!
Regards
Patrick
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R
2020-01-28 9:11 ` [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R Patrick Delaunay
2020-01-28 12:15 ` Marek Vasut
2020-02-13 8:12 ` [Uboot-stm32] " Patrice CHOTARD
@ 2020-02-14 10:26 ` Patrick DELAUNAY
2 siblings, 0 replies; 38+ messages in thread
From: Patrick DELAUNAY @ 2020-02-14 10:26 UTC (permalink / raw)
To: u-boot
Hi,
> From: Patrick DELAUNAY <patrick.delaunay@st.com>
> Sent: mardi 28 janvier 2020 10:11
>
> From: Antonio Borneo <antonio.borneo@st.com>
>
> LTDC modifies the clock frequency to adapt it to the display. Such frequency
> change is not detected by the FDCAN driver that instead cache the value at probe
> and pretend to use it later.
>
> Keep the LTDC alone on PLL4_Q by moving the FDCAN to PLL4_R.
>
> Signed-off-by: Antonio Borneo <antonio.borneo@st.com>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
> ---
Applied to u-boot-stm32/master, thanks!
Regards
Patrick
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 5/9] ARM: dts: stm32mp1: correct ddr node
2020-01-28 9:11 ` [PATCH 5/9] ARM: dts: stm32mp1: correct ddr node Patrick Delaunay
2020-02-13 8:13 ` [Uboot-stm32] " Patrice CHOTARD
@ 2020-02-14 10:27 ` Patrick DELAUNAY
1 sibling, 0 replies; 38+ messages in thread
From: Patrick DELAUNAY @ 2020-02-14 10:27 UTC (permalink / raw)
To: u-boot
Hi,
> From: Patrick DELAUNAY <patrick.delaunay@st.com>
> Sent: mardi 28 janvier 2020 10:11
>
> This patch fix the warning:
> dt.dts: Warning (simple_bus_reg): Node /soc/ddr at 5A003000 simple-bus unit
> address format error, expected "5a003000"
>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
> ---
Applied to u-boot-stm32/master, thanks!
Regards
Patrick
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 6/9] ARM: dts: stm32m1: add reg for pll nodes
2020-01-28 9:11 ` [PATCH 6/9] ARM: dts: stm32m1: add reg for pll nodes Patrick Delaunay
2020-02-13 8:13 ` [Uboot-stm32] " Patrice CHOTARD
@ 2020-02-14 10:27 ` Patrick DELAUNAY
1 sibling, 0 replies; 38+ messages in thread
From: Patrick DELAUNAY @ 2020-02-14 10:27 UTC (permalink / raw)
To: u-boot
Hi,
> From: Patrick DELAUNAY <patrick.delaunay@st.com>
> Sent: mardi 28 janvier 2020 10:11
>
> Fix the following DT dtc warnings for stm32mp1 boards:
>
> Warning (unit_address_vs_reg): /soc/rcc at 50000000/st,pll at 0:
> node has a unit name, but no reg property Warning (unit_address_vs_reg):
> /soc/rcc at 50000000/st,pll at 1:
> node has a unit name, but no reg property Warning (unit_address_vs_reg):
> /soc/rcc at 50000000/st,pll at 2:
> node has a unit name, but no reg property Warning (unit_address_vs_reg):
> /soc/rcc at 50000000/st,pll at 3:
> node has a unit name, but no reg property
>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
> ---
Applied to u-boot-stm32/master, thanks!
Regards
Patrick
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 7/9] board: stm32mp1: update readme
2020-01-28 9:11 ` [PATCH 7/9] board: stm32mp1: update readme Patrick Delaunay
2020-02-13 8:13 ` [Uboot-stm32] " Patrice CHOTARD
@ 2020-02-14 10:28 ` Patrick DELAUNAY
1 sibling, 0 replies; 38+ messages in thread
From: Patrick DELAUNAY @ 2020-02-14 10:28 UTC (permalink / raw)
To: u-boot
Hi,
> From: Patrick DELAUNAY <patrick.delaunay@st.com>
> Sent: mardi 28 janvier 2020 10:11
>
> Update readme:
> - list the supported SOC and change family to STM32MP15x
> - add warning on OTP write and prerequisite:
> check if MAC address is not yet provisioned.
> - Use filesize for mmc write command (avoid to write all partition
> with ${partsize}). ${filesize} and ${partsize} are set by previous
> load command.
>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
> ---
Applied to u-boot-stm32/master, thanks!
Regards
Patrick
^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 9/9] stm32mp1: support of STM32MP15x Rev.Z
2020-01-28 9:11 ` [PATCH 9/9] stm32mp1: support of STM32MP15x Rev.Z Patrick Delaunay
2020-02-13 12:34 ` Patrice CHOTARD
@ 2020-02-14 10:29 ` Patrick DELAUNAY
1 sibling, 0 replies; 38+ messages in thread
From: Patrick DELAUNAY @ 2020-02-14 10:29 UTC (permalink / raw)
To: u-boot
Hi,
> From: Patrick DELAUNAY <patrick.delaunay@st.com>
> Sent: mardi 28 janvier 2020 10:11
>
> Add support for Rev.Z of STM32MP15x cpu.
>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
> ---
Applied to u-boot-stm32/master, thanks!
Regards
Patrick
^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2020-02-14 10:29 UTC | newest]
Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-28 9:10 [PATCH 0/9] stm32mp1 devicetre-tree and board update Patrick Delaunay
2020-01-28 9:10 ` [PATCH 1/9] ARM: dts: stm32mp1: DT alignment with kernel v5.4 Patrick Delaunay
2020-02-13 8:11 ` [Uboot-stm32] " Patrice CHOTARD
2020-02-14 10:25 ` Patrick DELAUNAY
2020-01-28 9:10 ` [PATCH 2/9] stm32mp1: pwr: use the last binding for pwr Patrick Delaunay
2020-02-13 8:16 ` Patrice CHOTARD
2020-02-14 10:25 ` Patrick DELAUNAY
2020-01-28 9:11 ` [PATCH 3/9] ARM: dts: stm32mp1: DT alignment with kernel v5.5-rc7 Patrick Delaunay
2020-02-13 8:12 ` [Uboot-stm32] " Patrice CHOTARD
2020-02-14 10:26 ` Patrick DELAUNAY
2020-01-28 9:11 ` [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R Patrick Delaunay
2020-01-28 12:15 ` Marek Vasut
2020-01-29 16:51 ` Patrick DELAUNAY
2020-01-30 2:23 ` Marek Vasut
2020-01-31 8:15 ` Patrick DELAUNAY
2020-02-02 17:28 ` Marek Vasut
2020-02-04 13:16 ` Patrick DELAUNAY
2020-02-05 2:23 ` Marek Vasut
2020-02-06 8:59 ` Patrick DELAUNAY
2020-02-06 9:10 ` Marek Vasut
2020-02-13 8:12 ` [Uboot-stm32] " Patrice CHOTARD
2020-02-14 10:26 ` Patrick DELAUNAY
2020-01-28 9:11 ` [PATCH 5/9] ARM: dts: stm32mp1: correct ddr node Patrick Delaunay
2020-02-13 8:13 ` [Uboot-stm32] " Patrice CHOTARD
2020-02-14 10:27 ` Patrick DELAUNAY
2020-01-28 9:11 ` [PATCH 6/9] ARM: dts: stm32m1: add reg for pll nodes Patrick Delaunay
2020-02-13 8:13 ` [Uboot-stm32] " Patrice CHOTARD
2020-02-14 10:27 ` Patrick DELAUNAY
2020-01-28 9:11 ` [PATCH 7/9] board: stm32mp1: update readme Patrick Delaunay
2020-02-13 8:13 ` [Uboot-stm32] " Patrice CHOTARD
2020-02-14 10:28 ` Patrick DELAUNAY
2020-01-28 9:11 ` [PATCH 8/9] doc: add board documentation for stm32mp1 Patrick Delaunay
2020-01-28 11:34 ` Heinrich Schuchardt
2020-02-10 11:02 ` Patrick DELAUNAY
2020-02-13 8:14 ` Patrice CHOTARD
2020-01-28 9:11 ` [PATCH 9/9] stm32mp1: support of STM32MP15x Rev.Z Patrick Delaunay
2020-02-13 12:34 ` Patrice CHOTARD
2020-02-14 10:29 ` Patrick DELAUNAY
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.