[PATCH 0/9] stm32mp1 devicetre-tree and board update
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
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
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)>;@@ -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
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
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@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@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 }, { }
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@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@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
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
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@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@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@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@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@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@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@1 { + status = "okay"; + }; + dac2: dac@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"; };
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@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@c0000000 {
device_type = "memory";@@ -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@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@100 {
/* AIN connector, USB Type-C CC1 & CC2 */st,adc-channels = <0 1 2 6 18 19>;st,min-sample-time-nsecs = <5000>;}; @@ -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@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@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@1 {
status = "okay";- };
- dac2: dac@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>;@@ -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@st-md-mailman.stormreply.com https://st-md-mailman.stormreply.com/mailman/listinfo/uboot-stm32
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
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
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 ?
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/d62f14dece32e41c2854b9ff... + For TF-A = https://github.com/STMicroelectronics/arm-trusted-firmware/commit/9a24ceda6c...
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
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/d62f14dece32e41c2854b9ff...
- For TF-A = https://github.com/STMicroelectronics/arm-trusted-firmware/commit/9a24ceda6c...
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.
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
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 ?
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
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.
[...]
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
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 ?
[...]
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_PLL4Rdiff --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_PLL4Rdiff --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_PLL4Rdiff --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
Reviewed-by: Patrice Chotard patrice.chotard@st.com
Thanks
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
This patch fix the warning: dt.dts: Warning (simple_bus_reg): Node /soc/ddr@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@5A003000 { + ddr: ddr@5a003000 { u-boot,dm-pre-reloc;
compatible = "st,stm32mp1-ddr";
On 1/28/20 10:11 AM, Patrick Delaunay wrote:
This patch fix the warning: dt.dts: Warning (simple_bus_reg): Node /soc/ddr@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@5A003000 {
ddr: ddr@5a003000 { u-boot,dm-pre-reloc; compatible = "st,stm32mp1-ddr";
Reviewed-by: Patrice Chotard patrice.chotard@st.com
Thanks
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@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
Fix the following DT dtc warnings for stm32mp1 boards:
Warning (unit_address_vs_reg): /soc/rcc@50000000/st,pll@0: node has a unit name, but no reg property Warning (unit_address_vs_reg): /soc/rcc@50000000/st,pll@1: node has a unit name, but no reg property Warning (unit_address_vs_reg): /soc/rcc@50000000/st,pll@2: node has a unit name, but no reg property Warning (unit_address_vs_reg): /soc/rcc@50000000/st,pll@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@0 to st,pll@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@0 { + compatible = "st,stm32mp1-pll"; + reg = <0>; cfg = < 1 53 0 0 0 1 >; frac = < 0x810 >; }; st,pll@1 { + compatible = "st,stm32mp1-pll"; + reg = <1>; cfg = < 1 43 1 0 0 PQR(0,1,1) >; csg = < 10 20 1 >; }; st,pll@2 { + compatible = "st,stm32mp1-pll"; + reg = <2>; cfg = < 2 85 3 13 3 0 >; csg = < 10 20 SSCG_MODE_CENTER_SPREAD >; }; st,pll@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@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@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@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@3 { + compatible = "st,stm32mp1-pll"; + reg = <3>; cfg = < 3 98 5 7 7 PQR(1,1,1) >; u-boot,dm-pre-reloc; };
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@50000000/st,pll@0: node has a unit name, but no reg property Warning (unit_address_vs_reg): /soc/rcc@50000000/st,pll@1: node has a unit name, but no reg property Warning (unit_address_vs_reg): /soc/rcc@50000000/st,pll@2: node has a unit name, but no reg property Warning (unit_address_vs_reg): /soc/rcc@50000000/st,pll@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@0 {
compatible = "st,stm32mp1-pll";reg = <0>;@@ -112,6 +114,8 @@
/* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU), R = 533 (DDR) */ pll2: st,pll@1 {
compatible = "st,stm32mp1-pll";reg = <1>;@@ -119,6 +123,8 @@
/* VCO = 417.8 MHz => P = 209, Q = 24, R = 11 */ pll3: st,pll@2 {
compatible = "st,stm32mp1-pll";reg = <2>;@@ -126,6 +132,8 @@
/* VCO = 480.0 MHz => P = 120, Q = 40, R = 96 */ pll4: st,pll@3 {
compatible = "st,stm32mp1-pll";reg = <3>;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@0 {
compatible = "st,stm32mp1-pll";reg = <0>;@@ -131,6 +133,8 @@
/* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU), R = 533 (DDR) */ pll2: st,pll@1 {
compatible = "st,stm32mp1-pll";reg = <1>;@@ -138,6 +142,8 @@
/* VCO = 417.8 MHz => P = 209, Q = 24, R = 11 */ pll3: st,pll@2 {
compatible = "st,stm32mp1-pll";reg = <2>;@@ -145,6 +151,8 @@
/* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */ pll4: st,pll@3 {
compatible = "st,stm32mp1-pll";reg = <3>;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@0 {
compatible = "st,stm32mp1-pll";reg = <0>;@@ -128,6 +130,8 @@
/* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU), R = 533 (DDR) */ pll2: st,pll@1 {
compatible = "st,stm32mp1-pll";reg = <1>;@@ -135,6 +139,8 @@
/* VCO = 417.8 MHz => P = 209, Q = 24, R = 11 */ pll3: st,pll@2 {
compatible = "st,stm32mp1-pll";reg = <2>;@@ -142,6 +148,8 @@
/* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */ pll4: st,pll@3 {
compatible = "st,stm32mp1-pll";reg = <3>;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@0 {
compatible = "st,stm32mp1-pll";reg = <0>;@@ -163,6 +165,8 @@
/* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU), R = 533 (DDR) */ pll2: st,pll@1 {
compatible = "st,stm32mp1-pll";reg = <1>;@@ -170,6 +174,8 @@
/* VCO = 417.8 MHz => P = 209, Q = 24, R = 11 */ pll3: st,pll@2 {
compatible = "st,stm32mp1-pll";reg = <2>;@@ -177,6 +183,8 @@
/* VCO = 600.0 MHz => P = 50, Q = 50, R = 50 */ pll4: st,pll@3 {
compatible = "st,stm32mp1-pll";reg = <3>;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@0 to st,pll@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@0 {
compatible = "st,stm32mp1-pll";reg = <0>;compatible = "st,stm32mp1-pll";reg = <1>;compatible = "st,stm32mp1-pll";reg = <2>;compatible = "st,stm32mp1-pll";reg = <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@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@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@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@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
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@50000000/st,pll@0: node has a unit name, but no reg property Warning (unit_address_vs_reg): /soc/rcc@50000000/st,pll@1: node has a unit name, but no reg property Warning (unit_address_vs_reg): /soc/rcc@50000000/st,pll@2: node has a unit name, but no reg property Warning (unit_address_vs_reg): /soc/rcc@50000000/st,pll@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
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 ========================
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 +=======================================
- Summary
========== @@ -12,12 +12,12 @@ This is a quick instruction for setup stm32mp1 boards.
- 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
- 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)
- 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 2Sensing bank 0:Word 0x00000039: 00000000 000000002- check environment variable
STM32MP> env print ethaddr## Error: "ethaddr" not definedExample 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 boardprovided by STMicroelectronics.
- Coprocessor firmware
========================
Reviewed-by: Patrice Chotard patrice.chotard@st.com
Thanks
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
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 +
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 3for 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 2Sensing 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 2Sensing 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 ethaddrethaddr=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 boardprovided 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:
- UART
- SD card/MMC controller (SDMMC)
- NAND controller (FMC)
- NOR controller (QSPI)
- USB controller (OTG DWC2)
- Ethernet controller
+And the necessary drivers
- I2C
- STPMIC1 (PMIC and regulator)
- Clock, Reset, Sysreset
- 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 boardprovided 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
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
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 3for 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 2Sensing 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 2Sensing 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 ethaddrethaddr=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 boardprovided 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:
- UART
- SD card/MMC controller (SDMMC)
- NAND controller (FMC)
- NOR controller (QSPI)
- USB controller (OTG DWC2)
- Ethernet controller
+And the necessary drivers
- I2C
- STPMIC1 (PMIC and regulator)
- Clock, Reset, Sysreset
- 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 boardprovided 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
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);
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;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
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
participants (5)
-
Heinrich Schuchardt -
Marek Vasut -
Patrice CHOTARD -
Patrick DELAUNAY -
Patrick Delaunay