| Message ID | 1423763164-5606-13-git-send-email-mcoquelin.stm32@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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 >
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
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 >
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
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 >
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"; + }; + }; +};
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