[12/14] ARM: dts: Introduce STM32F429 MCU
diff mbox

Message ID 1423763164-5606-13-git-send-email-mcoquelin.stm32@gmail.com
State New
Headers show

Commit Message

Maxime Coquelin Feb. 12, 2015, 5:46 p.m. UTC
The STMicrolectornics's STM32F419 MCU has the following main features:
 - Cortex-M4 core running up to @180MHz
 - 2MB internal flash, 256KBytes internal RAM
 - FMC controller to connect SDRAM, NOR and NAND memories
 - SD/MMC/SDIO support
 - Ethernet controller
 - USB OTFG FS & HS controllers
 - I2C, SPI, CAN busses support
 - Several 16 & 32 bits general purpose timers
 - Serial Audio interface
 - LCD controller

Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 arch/arm/boot/dts/Makefile            |   1 +
 arch/arm/boot/dts/stm32f429-disco.dts |  41 +++++
 arch/arm/boot/dts/stm32f429.dtsi      | 279 ++++++++++++++++++++++++++++++++++
 3 files changed, 321 insertions(+)
 create mode 100644 arch/arm/boot/dts/stm32f429-disco.dts
 create mode 100644 arch/arm/boot/dts/stm32f429.dtsi

Comments

Philipp Zabel Feb. 13, 2015, 11:47 a.m. UTC | #1
Hi Maxime,

Am Donnerstag, den 12.02.2015, 18:46 +0100 schrieb Maxime Coquelin:
[...]
> +	soc {
> +		reset_ahb1: reset@40023810 {
> +			#reset-cells = <1>;
> +			compatible = "st,stm32-reset";
> +			reg = <0x40023810 0x4>;
> +		};
> +
> +		reset_ahb2: reset@40023814 {
> +			#reset-cells = <1>;
> +			compatible = "st,stm32-reset";
> +			reg = <0x40023814 0x4>;
> +		};
> +
> +		reset_ahb3: reset@40023818 {
> +			#reset-cells = <1>;
> +			compatible = "st,stm32-reset";
> +			reg = <0x40023818 0x4>;
> +		};
> +
> +		reset_apb1: reset@40023820 {
> +			#reset-cells = <1>;
> +			compatible = "st,stm32-reset";
> +			reg = <0x40023820 0x4>;
> +		};
> +
> +		reset_apb2: reset@40023824 {
> +			#reset-cells = <1>;
> +			compatible = "st,stm32-reset";
> +			reg = <0x40023824 0x4>;
> +		};

These are mostly consecutive, single registers. I wonder if these are
part of the same IP block and thus should be grouped together into the
same reset controller node?

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Maxime Coquelin Feb. 13, 2015, 3:59 p.m. UTC | #2
Hi Philipp,

2015-02-13 12:47 GMT+01:00 Philipp Zabel <p.zabel@pengutronix.de>:
> Hi Maxime,
>
> Am Donnerstag, den 12.02.2015, 18:46 +0100 schrieb Maxime Coquelin:
> [...]
>> +     soc {
>> +             reset_ahb1: reset@40023810 {
>> +                     #reset-cells = <1>;
>> +                     compatible = "st,stm32-reset";
>> +                     reg = <0x40023810 0x4>;
>> +             };
>> +
>> +             reset_ahb2: reset@40023814 {
>> +                     #reset-cells = <1>;
>> +                     compatible = "st,stm32-reset";
>> +                     reg = <0x40023814 0x4>;
>> +             };
>> +
>> +             reset_ahb3: reset@40023818 {
>> +                     #reset-cells = <1>;
>> +                     compatible = "st,stm32-reset";
>> +                     reg = <0x40023818 0x4>;
>> +             };
>> +
>> +             reset_apb1: reset@40023820 {
>> +                     #reset-cells = <1>;
>> +                     compatible = "st,stm32-reset";
>> +                     reg = <0x40023820 0x4>;
>> +             };
>> +
>> +             reset_apb2: reset@40023824 {
>> +                     #reset-cells = <1>;
>> +                     compatible = "st,stm32-reset";
>> +                     reg = <0x40023824 0x4>;
>> +             };
>
> These are mostly consecutive, single registers. I wonder if these are
> part of the same IP block and thus should be grouped together into the
> same reset controller node?

What I could to is to have two instances. One for AHB and one for APB domain.
Doing this, I will have one instance per domain, and only consecutive registers.
Is it fine for you?

Thanks,
Maxime

>
> regards
> Philipp
>
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Philipp Zabel Feb. 13, 2015, 4:25 p.m. UTC | #3
Hi Maxime,

Am Freitag, den 13.02.2015, 16:59 +0100 schrieb Maxime Coquelin:
> Hi Philipp,
> 
> 2015-02-13 12:47 GMT+01:00 Philipp Zabel <p.zabel@pengutronix.de>:
> > Hi Maxime,
> >
> > Am Donnerstag, den 12.02.2015, 18:46 +0100 schrieb Maxime Coquelin:
> > [...]
> >> +     soc {
> >> +             reset_ahb1: reset@40023810 {
> >> +                     #reset-cells = <1>;
> >> +                     compatible = "st,stm32-reset";
> >> +                     reg = <0x40023810 0x4>;
> >> +             };
> >> +
> >> +             reset_ahb2: reset@40023814 {
> >> +                     #reset-cells = <1>;
> >> +                     compatible = "st,stm32-reset";
> >> +                     reg = <0x40023814 0x4>;
> >> +             };
> >> +
> >> +             reset_ahb3: reset@40023818 {
> >> +                     #reset-cells = <1>;
> >> +                     compatible = "st,stm32-reset";
> >> +                     reg = <0x40023818 0x4>;
> >> +             };
> >> +
> >> +             reset_apb1: reset@40023820 {
> >> +                     #reset-cells = <1>;
> >> +                     compatible = "st,stm32-reset";
> >> +                     reg = <0x40023820 0x4>;
> >> +             };
> >> +
> >> +             reset_apb2: reset@40023824 {
> >> +                     #reset-cells = <1>;
> >> +                     compatible = "st,stm32-reset";
> >> +                     reg = <0x40023824 0x4>;
> >> +             };
> >
> > These are mostly consecutive, single registers. I wonder if these are
> > part of the same IP block and thus should be grouped together into the
> > same reset controller node?
> 
> What I could to is to have two instances. One for AHB and one for APB domain.
> Doing this, I will have one instance per domain, and only consecutive registers.
> Is it fine for you?

Looking at
http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031020.pdf
Table 34 (RCC register map and reset values), I'd say there is a single
"Reset and Clock Control" device at 0x40023800 - 0x40023884:

	soc {
		rcc: rcc@40023800 {
			#clock-cells = <1>;
			#reset-cells = <1>;
			compatible = "st,stm32-rcc";
			reg = <0x40023800 0x84>;
		};

		...

If you really want to describe the reset controller parts (offsets +0x10
to +0x24) in a separate node, I won't argue against it too long,
although this is a somewhat arbitrary decision.

In any case, the whole register at offset +0x1c is reserved, so there is
no reason to split the reset controller. It is ok to have unused ranges
as is already the case with reserved bits inside the used registers.

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Maxime Coquelin Feb. 13, 2015, 4:41 p.m. UTC | #4
2015-02-13 17:25 GMT+01:00 Philipp Zabel <p.zabel@pengutronix.de>:
> Hi Maxime,
>
> Am Freitag, den 13.02.2015, 16:59 +0100 schrieb Maxime Coquelin:
>> Hi Philipp,
>>
>> 2015-02-13 12:47 GMT+01:00 Philipp Zabel <p.zabel@pengutronix.de>:
>> > Hi Maxime,
>> >
>> > Am Donnerstag, den 12.02.2015, 18:46 +0100 schrieb Maxime Coquelin:
>> > [...]
>> >> +     soc {
>> >> +             reset_ahb1: reset@40023810 {
>> >> +                     #reset-cells = <1>;
>> >> +                     compatible = "st,stm32-reset";
>> >> +                     reg = <0x40023810 0x4>;
>> >> +             };
>> >> +
>> >> +             reset_ahb2: reset@40023814 {
>> >> +                     #reset-cells = <1>;
>> >> +                     compatible = "st,stm32-reset";
>> >> +                     reg = <0x40023814 0x4>;
>> >> +             };
>> >> +
>> >> +             reset_ahb3: reset@40023818 {
>> >> +                     #reset-cells = <1>;
>> >> +                     compatible = "st,stm32-reset";
>> >> +                     reg = <0x40023818 0x4>;
>> >> +             };
>> >> +
>> >> +             reset_apb1: reset@40023820 {
>> >> +                     #reset-cells = <1>;
>> >> +                     compatible = "st,stm32-reset";
>> >> +                     reg = <0x40023820 0x4>;
>> >> +             };
>> >> +
>> >> +             reset_apb2: reset@40023824 {
>> >> +                     #reset-cells = <1>;
>> >> +                     compatible = "st,stm32-reset";
>> >> +                     reg = <0x40023824 0x4>;
>> >> +             };
>> >
>> > These are mostly consecutive, single registers. I wonder if these are
>> > part of the same IP block and thus should be grouped together into the
>> > same reset controller node?
>>
>> What I could to is to have two instances. One for AHB and one for APB domain.
>> Doing this, I will have one instance per domain, and only consecutive registers.
>> Is it fine for you?
>
> Looking at
> http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031020.pdf
> Table 34 (RCC register map and reset values), I'd say there is a single
> "Reset and Clock Control" device at 0x40023800 - 0x40023884:
>
>         soc {
>                 rcc: rcc@40023800 {
>                         #clock-cells = <1>;
>                         #reset-cells = <1>;
>                         compatible = "st,stm32-rcc";
>                         reg = <0x40023800 0x84>;
>                 };
>
>                 ...
>
> If you really want to describe the reset controller parts (offsets +0x10
> to +0x24) in a separate node, I won't argue against it too long,
> although this is a somewhat arbitrary decision.
>
> In any case, the whole register at offset +0x1c is reserved, so there is
> no reason to split the reset controller. It is ok to have unused ranges
> as is already the case with reserved bits inside the used registers.

Ok. I understand your point.
But it will be more difficult at usage, because the node referencing
the fourth reset bit of apb2 register will have to pass 164 as
parameter.
It is error prone IMHO.

Other solution would be to add some defines for each reset line in the
DT-Bindings, as we do today for STi platform.
But it is giving an unneeded constraint between DT and reset trees.

Br,
Maxime

>
> regards
> Philipp
>
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Philipp Zabel Feb. 13, 2015, 7:18 p.m. UTC | #5
Am Freitag, den 13.02.2015, 17:41 +0100 schrieb Maxime Coquelin:
> 2015-02-13 17:25 GMT+01:00 Philipp Zabel <p.zabel@pengutronix.de>:
> > Hi Maxime,
> >
> > Am Freitag, den 13.02.2015, 16:59 +0100 schrieb Maxime Coquelin:
> >> Hi Philipp,
> >>
> >> 2015-02-13 12:47 GMT+01:00 Philipp Zabel <p.zabel@pengutronix.de>:
> >> > Hi Maxime,
> >> >
> >> > Am Donnerstag, den 12.02.2015, 18:46 +0100 schrieb Maxime Coquelin:
> >> > [...]
> >> >> +     soc {
> >> >> +             reset_ahb1: reset@40023810 {
> >> >> +                     #reset-cells = <1>;
> >> >> +                     compatible = "st,stm32-reset";
> >> >> +                     reg = <0x40023810 0x4>;
> >> >> +             };
> >> >> +
> >> >> +             reset_ahb2: reset@40023814 {
> >> >> +                     #reset-cells = <1>;
> >> >> +                     compatible = "st,stm32-reset";
> >> >> +                     reg = <0x40023814 0x4>;
> >> >> +             };
> >> >> +
> >> >> +             reset_ahb3: reset@40023818 {
> >> >> +                     #reset-cells = <1>;
> >> >> +                     compatible = "st,stm32-reset";
> >> >> +                     reg = <0x40023818 0x4>;
> >> >> +             };
> >> >> +
> >> >> +             reset_apb1: reset@40023820 {
> >> >> +                     #reset-cells = <1>;
> >> >> +                     compatible = "st,stm32-reset";
> >> >> +                     reg = <0x40023820 0x4>;
> >> >> +             };
> >> >> +
> >> >> +             reset_apb2: reset@40023824 {
> >> >> +                     #reset-cells = <1>;
> >> >> +                     compatible = "st,stm32-reset";
> >> >> +                     reg = <0x40023824 0x4>;
> >> >> +             };
> >> >
> >> > These are mostly consecutive, single registers. I wonder if these are
> >> > part of the same IP block and thus should be grouped together into the
> >> > same reset controller node?
> >>
> >> What I could to is to have two instances. One for AHB and one for APB domain.
> >> Doing this, I will have one instance per domain, and only consecutive registers.
> >> Is it fine for you?
> >
> > Looking at
> > http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031020.pdf
> > Table 34 (RCC register map and reset values), I'd say there is a single
> > "Reset and Clock Control" device at 0x40023800 - 0x40023884:
> >
> >         soc {
> >                 rcc: rcc@40023800 {
> >                         #clock-cells = <1>;
> >                         #reset-cells = <1>;
> >                         compatible = "st,stm32-rcc";
> >                         reg = <0x40023800 0x84>;
> >                 };
> >
> >                 ...
> >
> > If you really want to describe the reset controller parts (offsets +0x10
> > to +0x24) in a separate node, I won't argue against it too long,
> > although this is a somewhat arbitrary decision.
> >
> > In any case, the whole register at offset +0x1c is reserved, so there is
> > no reason to split the reset controller. It is ok to have unused ranges
> > as is already the case with reserved bits inside the used registers.
> 
> Ok. I understand your point.
> But it will be more difficult at usage, because the node referencing
> the fourth reset bit of apb2 register will have to pass 164 as
> parameter.
> It is error prone IMHO.
>
> Other solution would be to add some defines for each reset line in the
> DT-Bindings, as we do today for STi platform.
> But it is giving an unneeded constraint between DT and reset trees.

That is a bit unfortunate, but providing the named constants in
include/dt-bindings/reset/ makes for a much better readable device tree,
so I'd prefer that solution, even if it means having to coordinate pull
requests.

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Maxime Coquelin Feb. 15, 2015, 2:36 p.m. UTC | #6
Hi Philipp,

2015-02-13 20:18 GMT+01:00 Philipp Zabel <p.zabel@pengutronix.de>:
> Am Freitag, den 13.02.2015, 17:41 +0100 schrieb Maxime Coquelin:
>> 2015-02-13 17:25 GMT+01:00 Philipp Zabel <p.zabel@pengutronix.de>:
>> > Hi Maxime,
>> >
>> > Am Freitag, den 13.02.2015, 16:59 +0100 schrieb Maxime Coquelin:
>> >> Hi Philipp,
>> >>
>> >> 2015-02-13 12:47 GMT+01:00 Philipp Zabel <p.zabel@pengutronix.de>:
>> >> > Hi Maxime,
>> >> >
>> >> > Am Donnerstag, den 12.02.2015, 18:46 +0100 schrieb Maxime Coquelin:
>> >> > [...]
>> >> >> +     soc {
>> >> >> +             reset_ahb1: reset@40023810 {
>> >> >> +                     #reset-cells = <1>;
>> >> >> +                     compatible = "st,stm32-reset";
>> >> >> +                     reg = <0x40023810 0x4>;
>> >> >> +             };
>> >> >> +
>> >> >> +             reset_ahb2: reset@40023814 {
>> >> >> +                     #reset-cells = <1>;
>> >> >> +                     compatible = "st,stm32-reset";
>> >> >> +                     reg = <0x40023814 0x4>;
>> >> >> +             };
>> >> >> +
>> >> >> +             reset_ahb3: reset@40023818 {
>> >> >> +                     #reset-cells = <1>;
>> >> >> +                     compatible = "st,stm32-reset";
>> >> >> +                     reg = <0x40023818 0x4>;
>> >> >> +             };
>> >> >> +
>> >> >> +             reset_apb1: reset@40023820 {
>> >> >> +                     #reset-cells = <1>;
>> >> >> +                     compatible = "st,stm32-reset";
>> >> >> +                     reg = <0x40023820 0x4>;
>> >> >> +             };
>> >> >> +
>> >> >> +             reset_apb2: reset@40023824 {
>> >> >> +                     #reset-cells = <1>;
>> >> >> +                     compatible = "st,stm32-reset";
>> >> >> +                     reg = <0x40023824 0x4>;
>> >> >> +             };
>> >> >
>> >> > These are mostly consecutive, single registers. I wonder if these are
>> >> > part of the same IP block and thus should be grouped together into the
>> >> > same reset controller node?
>> >>
>> >> What I could to is to have two instances. One for AHB and one for APB domain.
>> >> Doing this, I will have one instance per domain, and only consecutive registers.
>> >> Is it fine for you?
>> >
>> > Looking at
>> > http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031020.pdf
>> > Table 34 (RCC register map and reset values), I'd say there is a single
>> > "Reset and Clock Control" device at 0x40023800 - 0x40023884:
>> >
>> >         soc {
>> >                 rcc: rcc@40023800 {
>> >                         #clock-cells = <1>;
>> >                         #reset-cells = <1>;
>> >                         compatible = "st,stm32-rcc";
>> >                         reg = <0x40023800 0x84>;
>> >                 };
>> >
>> >                 ...
>> >
>> > If you really want to describe the reset controller parts (offsets +0x10
>> > to +0x24) in a separate node, I won't argue against it too long,
>> > although this is a somewhat arbitrary decision.
>> >
>> > In any case, the whole register at offset +0x1c is reserved, so there is
>> > no reason to split the reset controller. It is ok to have unused ranges
>> > as is already the case with reserved bits inside the used registers.
>>
>> Ok. I understand your point.
>> But it will be more difficult at usage, because the node referencing
>> the fourth reset bit of apb2 register will have to pass 164 as
>> parameter.
>> It is error prone IMHO.
>>
>> Other solution would be to add some defines for each reset line in the
>> DT-Bindings, as we do today for STi platform.
>> But it is giving an unneeded constraint between DT and reset trees.
>
> That is a bit unfortunate, but providing the named constants in
> include/dt-bindings/reset/ makes for a much better readable device tree,
> so I'd prefer that solution, even if it means having to coordinate pull
> requests.

Ok, I will add constants in include/dt-bindings/reset/

Thanks,
Maxime

>
> regards
> Philipp
>
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 91bd5bd..d7da0ef 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -442,6 +442,7 @@  dtb-$(CONFIG_ARCH_STI)+= stih407-b2120.dtb \
 	stih416-b2000.dtb \
 	stih416-b2020.dtb \
 	stih416-b2020e.dtb
+dtb-$(CONFIG_ARCH_STM32)+= stm32f429-disco.dtb
 dtb-$(CONFIG_MACH_SUN4I) += \
 	sun4i-a10-a1000.dtb \
 	sun4i-a10-ba10-tvbox.dtb \
diff --git a/arch/arm/boot/dts/stm32f429-disco.dts b/arch/arm/boot/dts/stm32f429-disco.dts
new file mode 100644
index 0000000..0e79cc1
--- /dev/null
+++ b/arch/arm/boot/dts/stm32f429-disco.dts
@@ -0,0 +1,41 @@ 
+/dts-v1/;
+#include "stm32f429.dtsi"
+
+/ {
+	model = "STMicroelectronics's STM32F429i-DISCO board";
+	compatible = "st,stm32f429i-disco", "st,stm32f429";
+
+	chosen {
+		bootargs = "console=ttyS0,115200 root=/dev/ram rdinit=/linuxrc";
+		linux,stdout-path = &usart1;
+	};
+
+	memory {
+		reg = <0xd0000000 0x800000>;
+	};
+
+	aliases {
+		ttyS0 = &usart1;
+	};
+
+	soc {
+		usart1: usart@40011000 {
+			status = "okay";
+		};
+
+		leds {
+			compatible = "gpio-leds";
+			red {
+				#gpio-cells = <2>;
+				label = "Front Panel LED";
+				gpios = <&gpiog 14 0>;
+				linux,default-trigger = "heartbeat";
+			};
+			green {
+				#gpio-cells = <2>;
+				gpios = <&gpiog 13 0>;
+				default-state = "off";
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
new file mode 100644
index 0000000..71293c2
--- /dev/null
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -0,0 +1,279 @@ 
+/*
+ * Device tree for STM32F429
+ */
+#include "armv7-m.dtsi"
+#include <dt-bindings/pinctrl/pinctrl-stm32.h>
+
+/ {
+
+	aliases {
+		gpio0 = &gpioa;
+		gpio1 = &gpiob;
+		gpio2 = &gpioc;
+		gpio3 = &gpiod;
+		gpio4 = &gpioe;
+		gpio5 = &gpiof;
+		gpio6 = &gpiog;
+		gpio7 = &gpioh;
+		gpio8 = &gpioi;
+		gpio9 = &gpioj;
+		gpio10 = &gpiok;
+	};
+
+	clocks {
+		clk_sysclk: clk-sysclk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <180000000>;
+		};
+
+		clk_hclk: clk-hclk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <180000000>;
+		};
+
+		clk_pclk1: clk-pclk1 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <45000000>;
+		};
+
+		clk_pclk2: clk-pclk2 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <90000000>;
+		};
+
+		clk_pmtr1: clk-pmtr1 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <90000000>;
+		};
+
+		clk_pmtr2: clk-pmtr2 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <180000000>;
+		};
+
+		clk_systick: clk-systick {
+			compatible = "fixed-factor-clock";
+			clocks = <&clk_hclk>;
+			#clock-cells = <0>;
+			clock-div = <8>;
+			clock-mult = <1>;
+		};
+	};
+
+	systick: system-timer {
+		clocks = <&clk_systick>;
+
+		status = "okay";
+	};
+
+	soc {
+		reset_ahb1: reset@40023810 {
+			#reset-cells = <1>;
+			compatible = "st,stm32-reset";
+			reg = <0x40023810 0x4>;
+		};
+
+		reset_ahb2: reset@40023814 {
+			#reset-cells = <1>;
+			compatible = "st,stm32-reset";
+			reg = <0x40023814 0x4>;
+		};
+
+		reset_ahb3: reset@40023818 {
+			#reset-cells = <1>;
+			compatible = "st,stm32-reset";
+			reg = <0x40023818 0x4>;
+		};
+
+		reset_apb1: reset@40023820 {
+			#reset-cells = <1>;
+			compatible = "st,stm32-reset";
+			reg = <0x40023820 0x4>;
+		};
+
+		reset_apb2: reset@40023824 {
+			#reset-cells = <1>;
+			compatible = "st,stm32-reset";
+			reg = <0x40023824 0x4>;
+		};
+
+		pin-controller {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "st,stm32-pinctrl";
+			ranges = <0 0x40020000 0x3000>;
+
+			gpioa: gpio@40020000 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0x0 0x400>;
+				resets = <&reset_ahb1 0>;
+				st,bank-name = "GPIOA";
+			};
+
+			gpiob: gpio@40020400 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0x400 0x400>;
+				resets = <&reset_ahb1 1>;
+				st,bank-name = "GPIOB";
+			};
+
+			gpioc: gpio@40020800 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0x800 0x400>;
+				resets = <&reset_ahb1 2>;
+				st,bank-name = "GPIOC";
+			};
+
+			gpiod: gpio@40020c00 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0xc00 0x400>;
+				resets = <&reset_ahb1 3>;
+				st,bank-name = "GPIOD";
+			};
+
+			gpioe: gpio@40021000 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0x1000 0x400>;
+				resets = <&reset_ahb1 4>;
+				st,bank-name = "GPIOE";
+			};
+
+			gpiof: gpio@40021400 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0x1400 0x400>;
+				resets = <&reset_ahb1 5>;
+				st,bank-name = "GPIOF";
+			};
+
+			gpiog: gpio@40021800 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0x1800 0x400>;
+				resets = <&reset_ahb1 6>;
+				st,bank-name = "GPIOG";
+			};
+
+			gpioh: gpio@40021c00 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0x1c00 0x400>;
+				resets = <&reset_ahb1 7>;
+				st,bank-name = "GPIOH";
+			};
+
+			gpioi: gpio@40022000 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0x2000 0x400>;
+				resets = <&reset_ahb1 8>;
+				st,bank-name = "GPIOI";
+			};
+
+			gpioj: gpio@40022400 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0x2400 0x400>;
+				resets = <&reset_ahb1 9>;
+				st,bank-name = "GPIOJ";
+			};
+
+			gpiok: gpio@40022800 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0x2800 0x400>;
+				resets = <&reset_ahb1 10>;
+				st,bank-name = "GPIOK";
+			};
+
+			usart1 {
+				pinctrl_usart1: usart1-0 {
+					st,pins {
+						tx = <&gpioa 9 ALT7 NO_PULL PUSH_PULL LOW_SPEED>;
+						rx = <&gpioa 10 ALT7 NO_PULL>;
+					};
+				};
+			};
+		};
+
+		timer2: timer@40000000 {
+			compatible = "st,stm32-timer";
+			reg = <0x40000000 0x400>;
+			interrupts = <28>;
+			resets = <&reset_apb1 0>;
+			clocks = <&clk_pmtr1>;
+
+			status = "disabled";
+		};
+
+		timer3: timer@40000400 {
+			compatible = "st,stm32-timer";
+			reg = <0x40000400 0x400>;
+			interrupts = <29>;
+			resets = <&reset_apb1 1>;
+			clocks = <&clk_pmtr1>;
+
+			status = "disabled";
+		};
+
+		timer4: timer@40000800 {
+			compatible = "st,stm32-timer";
+			reg = <0x40000800 0x400>;
+			interrupts = <30>;
+			resets = <&reset_apb1 2>;
+			clocks = <&clk_pmtr1>;
+
+			status = "disabled";
+		};
+
+		timer5: timer@40000c00 {
+			compatible = "st,stm32-timer";
+			reg = <0x40000c00 0x400>;
+			interrupts = <50>;
+			resets = <&reset_apb1 3>;
+			clocks = <&clk_pmtr1>;
+		};
+
+		timer6: timer@40001000 {
+			compatible = "st,stm32-timer";
+			reg = <0x40001000 0x400>;
+			interrupts = <55>;
+			resets = <&reset_apb1 4>;
+			clocks = <&clk_pmtr1>;
+
+			status = "disabled";
+		};
+
+		timer7: timer@40001400 {
+			compatible = "st,stm32-timer";
+			reg = <0x40001400 0x400>;
+			interrupts = <55>;
+			resets = <&reset_apb1 5>;
+			clocks = <&clk_pmtr1>;
+
+			status = "disabled";
+		};
+
+		usart1: usart@40011000 {
+			compatible = "st,stm32-usart";
+			reg = <0x40011000 0x400>;
+			interrupts = <37>;
+			clocks = <&clk_pclk2>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_usart1>;
+
+			status = "disabled";
+		};
+	};
+};