STM32F103x port


Tomasz Bursztyka
 

Hi Daniel,
Updated Changes:
https://gerrit.zephyrproject.org/r/645 st_stm32/stm32f1: introduce
STM32F1x SoC family
Depending upon others input, I think this is ready to go.

https://gerrit.zephyrproject.org/r/647 clock_control/stm32f10x:
introduce new driver for STM32F10x RCC
I'm still toying with the idea that this could be made more generic to work for all STM32 boards. Looking for general mailing list input on this.

Would it be better to accept what Maciek has right now that works on STM32F1 and then submit a follow up patch to make it generic for all STM32 MCUs? Or should we focus on getting a generic interface for all STM32 on the first pass?
Maybe we can move on with current patches yes.

Tomasz


Kalowsky, Daniel <daniel.kalowsky@...>
 

Hey Maciek,

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Wednesday, March 9, 2016 6:48 AM
To: Nashif, Anas <anas.nashif(a)intel.com>
Cc: Kalowsky, Daniel <daniel.kalowsky(a)intel.com>; Walsh, Benjamin (Wind
River) <benjamin.walsh(a)windriver.com>; Brandewie, Dirk J
<dirk.j.brandewie(a)intel.com>; devel(a)lists.zephyrproject.org;
users(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Re: Re: Re: STM32F103x port

Hi,

I've pushed another set of updates. Hopefully I have not missed any
comments that were added to the previous versions.

I took the liberty of rebasing Daniel's patch on top of current
master, and so rebasing all of my patches on top of this one.
Yeah I saw that this morning and was a little confused until I saw what was going on.

There are 2 major changes since the previous version.

One is extending of pinmux integration for STM32F1. That includes
structures that define alternate functions for IO pins plus some
helpers for selecting pin's function in a more convenient fashion.

The second change is adding UART_1 and UART_2 ports that map to USART2
and USART3 respectively.

Hopefully it'll be possible to merge at least some of these patches to
master.

Updated Changes:
https://gerrit.zephyrproject.org/r/645 st_stm32/stm32f1: introduce
STM32F1x SoC family
Depending upon others input, I think this is ready to go.

https://gerrit.zephyrproject.org/r/647 clock_control/stm32f10x:
introduce new driver for STM32F10x RCC
I'm still toying with the idea that this could be made more generic to work for all STM32 boards. Looking for general mailing list input on this.

Would it be better to accept what Maciek has right now that works on STM32F1 and then submit a follow up patch to make it generic for all STM32 MCUs? Or should we focus on getting a generic interface for all STM32 on the first pass?

https://gerrit.zephyrproject.org/r/648 soc/stm32f1: add GPIO
registers mapping
https://gerrit.zephyrproject.org/r/649 pinmux/stm32: add common
driver for STM32 pinmux
I was mid-review of this yesterday... so I haven't gotten to the lower group yet.

https://gerrit.zephyrproject.org/r/650 serial/stm32: add new driver
for STM32 UART
https://gerrit.zephyrproject.org/r/651 gpio/stm32: add common driver
for STM32 GPIO
https://gerrit.zephyrproject.org/r/652 boards/stm32_mini_a15: add
new board
https://gerrit.zephyrproject.org/r/653 samples/drivers/disco: add
'disco' sample program
https://gerrit.zephyrproject.org/r/698 arch: arm: move nmi to common
location
https://gerrit.zephyrproject.org/r/711 clock_control/Kconfig: move
quark_se entries to separate file
https://gerrit.zephyrproject.org/r/712 clock_control: extend API
with clock rate query operation
https://gerrit.zephyrproject.org/r/713 soc/stm32f1/gpio: implement
GPIO support
https://gerrit.zephyrproject.org/r/714 soc/stm32f1/pinmux: implement
STM32 pinmux integration
https://gerrit.zephyrproject.org/r/715 boards/nucleo_f103rb: add new
board

Cheers,
--
Maciek Borzecki


Maciek Borzecki <maciek.borzecki@...>
 

Hi,

I've pushed another set of updates. Hopefully I have not missed any
comments that were added to the previous versions.

I took the liberty of rebasing Daniel's patch on top of current
master, and so rebasing all of my patches on top of this one.

There are 2 major changes since the previous version.

One is extending of pinmux integration for STM32F1. That includes
structures that define alternate functions for IO pins plus some
helpers for selecting pin's function in a more convenient fashion.

The second change is adding UART_1 and UART_2 ports that map to USART2
and USART3 respectively.

Hopefully it'll be possible to merge at least some of these patches to
master.

Updated Changes:
https://gerrit.zephyrproject.org/r/645 st_stm32/stm32f1: introduce
STM32F1x SoC family
https://gerrit.zephyrproject.org/r/647 clock_control/stm32f10x:
introduce new driver for STM32F10x RCC
https://gerrit.zephyrproject.org/r/648 soc/stm32f1: add GPIO
registers mapping
https://gerrit.zephyrproject.org/r/649 pinmux/stm32: add common
driver for STM32 pinmux
https://gerrit.zephyrproject.org/r/650 serial/stm32: add new driver
for STM32 UART
https://gerrit.zephyrproject.org/r/651 gpio/stm32: add common driver
for STM32 GPIO
https://gerrit.zephyrproject.org/r/652 boards/stm32_mini_a15: add
new board
https://gerrit.zephyrproject.org/r/653 samples/drivers/disco: add
'disco' sample program
https://gerrit.zephyrproject.org/r/698 arch: arm: move nmi to common
location
https://gerrit.zephyrproject.org/r/711 clock_control/Kconfig: move
quark_se entries to separate file
https://gerrit.zephyrproject.org/r/712 clock_control: extend API
with clock rate query operation
https://gerrit.zephyrproject.org/r/713 soc/stm32f1/gpio: implement
GPIO support
https://gerrit.zephyrproject.org/r/714 soc/stm32f1/pinmux: implement
STM32 pinmux integration
https://gerrit.zephyrproject.org/r/715 boards/nucleo_f103rb: add new
board

Cheers,
--
Maciek Borzecki


Maciek Borzecki <maciek.borzecki@...>
 

Hi,

I've uploaded another patchset.

Some of the patches have only gone through updates. Specifically
clock_control and the base st_stm32 tree patch. I've decided to keep
the RCC driver MCU specific. I'm not sure there's a nice and clean way
of organizing this so. I think that the device name is unfortunately
the only common part we can have for STM32 families, and so the device
is initialized using STM32_CLOCK_CONTROL_NAME.

GPIO and pinmux drivers have gone through a major change. I've tried
to have a common base for GPIO and pinmux drivers, while proving the
SoC specific functionality within arch/arm/soc/st_stm32/stm32f1
tree. The way it's implemented, the driver headers (gpio_stm32.h and
pinmux_stm32.h) declare a couple of functions that need to be
implemented by the soc integration. The divergence in register
contents between, STM32F1 and STM32F4 as well as the approach for
alternate function setup is too large to my liking. I think that
callig SoC specific integration is a good compromise and would allow
to keep the code maintainable.

There is a chicken and egg problem with the GPIO and pimux, namely the
common GPIO diver without the pinmux patch. I did not want to squash
the code into one large patch to keep the things civil. Just a thing
to remember, that these would have to be merged at the same time.

Since I got my Nucleo-64 F103RB, I've added the config for this bard
as well. The 'disco' sample has also been updated to be directly
usable on the Nucleo board rather than the obscure STM32 MINI A15.

I've also added 2 changes (709, 710) that will be unnecessary. A
similar fix from Daniel K has been posted. Once that is merged 2
master I'll just rebase skipping my 2 patches.

New Changes:
https://gerrit.zephyrproject.org/r/709 arch/arm/cortex_m: move
fallback NMI handler to common Cortex-M
https://gerrit.zephyrproject.org/r/710 arch/arm: move NMI_INIT()
helper macro to cortex_m common header
https://gerrit.zephyrproject.org/r/711 clock_control/Kconfig: move
quark_se entries to separate file
https://gerrit.zephyrproject.org/r/712 clock_control: extend API
with clock rate query operation
https://gerrit.zephyrproject.org/r/713 soc/stm32f1/gpio: implement
GPIO support
https://gerrit.zephyrproject.org/r/714 soc/stm32f1/pinmux: implement
STM32 pinmux integration
https://gerrit.zephyrproject.org/r/715 boards/nucleo_f103rb: add new board

Updated Changes:
https://gerrit.zephyrproject.org/r/645 st_stm32/stm32f1: introduce
STM32F1x SoC family
https://gerrit.zephyrproject.org/r/646 clock_control/Kconfig: fix
quark_se dependencies
https://gerrit.zephyrproject.org/r/647 clock_control/stm32f10x:
introduce new driver for STM32F10x RCC
https://gerrit.zephyrproject.org/r/648 soc/stm32f1: add GPIO
registers mapping
https://gerrit.zephyrproject.org/r/649 pinmux/stm32: add common
driver for STM32 pinmux
https://gerrit.zephyrproject.org/r/650 serial/stm32: add new driver
for STM32 UART
https://gerrit.zephyrproject.org/r/651 gpio/stm32: add common driver
for STM32 GPIO
https://gerrit.zephyrproject.org/r/652 boards/stm32_mini_a15: add
new board
https://gerrit.zephyrproject.org/r/653 samples/disco: add 'disco'
sample program

--
Maciek Borzecki


Tomasz Bursztyka
 

Hi Maciek,

Can you check if drivers in the patchset that I posted are useful for
you? Specifically,
the UART driver might be reusable across a larger number of MCUs.
Browsing the Reference
Manuals I noticed some bit differences in UART registers, but nothing
that cannot be handled by
per MCU-family ifdefs.
Would be great to generalize as much as possible now. At least for
what's concerning stm32.
For instance, maybe gpio/pinmuxer could be generalized as well that way.

Tomasz


Maciek Borzecki <maciek.borzecki@...>
 

On Fri, Mar 4, 2016 at 7:44 AM, Pawel Wodnicki <root(a)32bitmicro.com> wrote:
Hej Maciek,

I added stm32f4 support to your stm32 patch:
https://gerrit.zephyrproject.org/r/#/c/671/
Code is tested to run on Nucleo board included it the patch.
That's great. I'll definitely take a look at it.

Can you check if drivers in the patchset that I posted are useful for
you? Specifically,
the UART driver might be reusable across a larger number of MCUs.
Browsing the Reference
Manuals I noticed some bit differences in UART registers, but nothing
that cannot be handled by
per MCU-family ifdefs.

Cheers,
--
Maciek Borzecki


Pawel Wodnicki <root@...>
 

Hej Maciek,

I added stm32f4 support to your stm32 patch:
https://gerrit.zephyrproject.org/r/#/c/671/
Code is tested to run on Nucleo board included it the patch.

Cheers,
Pawel


Maciek Borzecki <maciek.borzecki@...>
 

On Thu, Mar 3, 2016 at 3:43 PM, Maciek Borzecki
<maciek.borzecki(a)gmail.com> wrote:
I'm sure all of you already got their emails with incoming review
request. For others who might be interested as well, I've posted a
series of patches to gerrit:

https://gerrit.zephyrproject.org/r/645 st_stm32/stm32f1: introduce
STM32F1x SoC family
https://gerrit.zephyrproject.org/r/646 clock_control/Kconfig: Quark
should depend on CLOCK_CONTROL
https://gerrit.zephyrproject.org/r/647 clock_control/stm32f10x:
introduce new driver for STM32F10x RCC
https://gerrit.zephyrproject.org/r/648 soc/stm32f1: add GPIO registers mapping
https://gerrit.zephyrproject.org/r/649 pinmux/stm32f10x: add driver
for STM32F1 pinmux
https://gerrit.zephyrproject.org/r/650 serial/stm32f10x: add new
driver for STM32F10x UART
https://gerrit.zephyrproject.org/r/651 gpio/stm32f10x: add new driver
for STM32F10x GPIO
https://gerrit.zephyrproject.org/r/652 boards/stm32_mini_a15: add new board
https://gerrit.zephyrproject.org/r/653 samples/disco: add 'disco' sample program
Pawel spotted that the linker script was missing. This would prevent people from
actually building the code. I've pushed an update for
https://gerrit.zephyrproject.org/r/645
and the rest got automatically rebased.

The problem was caused by filter masks in gitignore, what has been addressed
in this review:
https://gerrit.zephyrproject.org/r/668 gitignore: make sure that
SOC specific linker scripts stay visible

No other changes were made to the patches. If you're looking at, or have posted
comments to the previous version, have no worries, they all apply to the current
patchset.

Sorry for not catching that earlier.

Cheers,
--
Maciek Borzecki


Maciek Borzecki <maciek.borzecki@...>
 

On Thu, Mar 3, 2016 at 5:00 PM, Tomasz Bursztyka
<tomasz.bursztyka(a)linux.intel.com> wrote:
Hi Maciek,

Thanks for the patches, they are very nicely sliced down. It's quite easy to
follow.

Just be aware of the code style we apply. Basically the 2 main errors are
the missing {}
(even for one liners if, yes, and the while loop as well) and the variable
being declared
in the middle of the statement block: it's always at the beginning. It's
minor changes.
scripts/checkpatch.pl is nice so check before hand.
Thanks for the comments. I'll wait for everyone to post theirs and try to
resolve the issues over the weekend.

Cheers,
--
Maciek Borzecki


Tomasz Bursztyka
 

Hi Maciek,

Thanks for the patches, they are very nicely sliced down. It's quite
easy to follow.

Just be aware of the code style we apply. Basically the 2 main errors
are the missing {}
(even for one liners if, yes, and the while loop as well) and the
variable being declared
in the middle of the statement block: it's always at the beginning. It's
minor changes.
scripts/checkpatch.pl is nice so check before hand.

Tomasz

I'm sure all of you already got their emails with incoming review
request. For others who might be interested as well, I've posted a
series of patches to gerrit:

https://gerrit.zephyrproject.org/r/645 st_stm32/stm32f1: introduce
STM32F1x SoC family
https://gerrit.zephyrproject.org/r/646 clock_control/Kconfig: Quark
should depend on CLOCK_CONTROL
https://gerrit.zephyrproject.org/r/647 clock_control/stm32f10x:
introduce new driver for STM32F10x RCC
https://gerrit.zephyrproject.org/r/648 soc/stm32f1: add GPIO registers mapping
https://gerrit.zephyrproject.org/r/649 pinmux/stm32f10x: add driver
for STM32F1 pinmux
https://gerrit.zephyrproject.org/r/650 serial/stm32f10x: add new
driver for STM32F10x UART
https://gerrit.zephyrproject.org/r/651 gpio/stm32f10x: add new driver
for STM32F10x GPIO
https://gerrit.zephyrproject.org/r/652 boards/stm32_mini_a15: add new board
https://gerrit.zephyrproject.org/r/653 samples/disco: add 'disco' sample program


Maciek Borzecki <maciek.borzecki@...>
 

I'm sure all of you already got their emails with incoming review
request. For others who might be interested as well, I've posted a
series of patches to gerrit:

https://gerrit.zephyrproject.org/r/645 st_stm32/stm32f1: introduce
STM32F1x SoC family
https://gerrit.zephyrproject.org/r/646 clock_control/Kconfig: Quark
should depend on CLOCK_CONTROL
https://gerrit.zephyrproject.org/r/647 clock_control/stm32f10x:
introduce new driver for STM32F10x RCC
https://gerrit.zephyrproject.org/r/648 soc/stm32f1: add GPIO registers mapping
https://gerrit.zephyrproject.org/r/649 pinmux/stm32f10x: add driver
for STM32F1 pinmux
https://gerrit.zephyrproject.org/r/650 serial/stm32f10x: add new
driver for STM32F10x UART
https://gerrit.zephyrproject.org/r/651 gpio/stm32f10x: add new driver
for STM32F10x GPIO
https://gerrit.zephyrproject.org/r/652 boards/stm32_mini_a15: add new board
https://gerrit.zephyrproject.org/r/653 samples/disco: add 'disco' sample program

--
Maciek Borzecki


Nashif, Anas
 

On 2 Mar 2016, at 11:42, Kalowsky, Daniel <daniel.kalowsky(a)intel.com> wrote:

-----Original Message-----
From: Nashif, Anas
Sent: Wednesday, March 2, 2016 8:12 AM
To: Walsh, Benjamin (Wind River) <benjamin.walsh(a)windriver.com>
Cc: Brandewie, Dirk J <dirk.j.brandewie(a)intel.com>; Maciek Borzecki
<maciek.borzecki(a)gmail.com>; devel(a)lists.zephyrproject.org; Kalowsky,
Daniel <daniel.kalowsky(a)intel.com>; users(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Re: Re: Re: STM32F103x port

On 2 Mar 2016, at 10:54, Benjamin Walsh
<benjamin.walsh(a)windriver.com> wrote:

On Tue, Mar 01, 2016 at 10:17:17AM -0800, Dirk Brandewie wrote:


On 02/29/2016 02:26 PM, Kalowsky, Daniel wrote:
-----Original Message-----
First suggestion, create an arch/arm/soc/stm32, and use the Kconfig
to
allow selecting of the various flavors of the STM32 chip. This would
be similar to what you've already got with the
Kconfig.soc.stm32f103ve
file, merged with the values from your Kconfig.soc. Then keeping the
Kconfig to the pieces generic to all the STM32 portions (i.e. flash
size, base address, etc).

Thoughts?
Makes sense. I think we should also add another 'MCU family' level of
hierarchy. We would have then:

arch/
arm/
soc/
stm32/
stm32f1xx/
<soc specific>
stm32f2xx/
<soc specific>
stm32f4xx/
<soc specific>
I'm not opposed to this.

Ben/Dirk any commentary?
Having thought about it for 10 seconds it seems reasonable :-) To the
greatest extent reasonable please avoid link time binding of SOC specifc
code into the generic stm32 code. We don't want to the next guy to
wonder which init() function is called.
+1
The main issue with this is the fact that stm32 extends all the way from M0
to M7, in total set of 11 series

• STM32F0 Series
• STM32F1 Series
• STM32F2 Series
• STM32F3 Series
• STM32F4 Series
• STM32F7 Series
• STM32L0 Series
• STM32L1 Series
• STM32L4 Series
• STM32T Series
• STM32W Series

where each series can have up to 10 different SoCs in some cases.
I'm not sure I understand this comment. Is this a positive or negative to the proposed solution?

stm32 is very generic, we should consider placing the series at the top level under soc/ and have the supported SoCs below it. So for STM32 we will end up with


stm32f0/
...
stm32f1/
...
stm32f2/
STM32F2x5
STM32F2x7
stm32f4/
STM32F401
STM32F410
STM32F411
STM32F446
….


Anas


Kalowsky, Daniel <daniel.kalowsky@...>
 

-----Original Message-----
From: Nashif, Anas
Sent: Wednesday, March 2, 2016 8:12 AM
To: Walsh, Benjamin (Wind River) <benjamin.walsh(a)windriver.com>
Cc: Brandewie, Dirk J <dirk.j.brandewie(a)intel.com>; Maciek Borzecki
<maciek.borzecki(a)gmail.com>; devel(a)lists.zephyrproject.org; Kalowsky,
Daniel <daniel.kalowsky(a)intel.com>; users(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Re: Re: Re: STM32F103x port

On 2 Mar 2016, at 10:54, Benjamin Walsh
<benjamin.walsh(a)windriver.com> wrote:

On Tue, Mar 01, 2016 at 10:17:17AM -0800, Dirk Brandewie wrote:


On 02/29/2016 02:26 PM, Kalowsky, Daniel wrote:
-----Original Message-----
First suggestion, create an arch/arm/soc/stm32, and use the Kconfig
to
allow selecting of the various flavors of the STM32 chip. This would
be similar to what you've already got with the
Kconfig.soc.stm32f103ve
file, merged with the values from your Kconfig.soc. Then keeping the
Kconfig to the pieces generic to all the STM32 portions (i.e. flash
size, base address, etc).

Thoughts?
Makes sense. I think we should also add another 'MCU family' level of
hierarchy. We would have then:

arch/
arm/
soc/
stm32/
stm32f1xx/
<soc specific>
stm32f2xx/
<soc specific>
stm32f4xx/
<soc specific>
I'm not opposed to this.

Ben/Dirk any commentary?
Having thought about it for 10 seconds it seems reasonable :-) To the
greatest extent reasonable please avoid link time binding of SOC specifc
code into the generic stm32 code. We don't want to the next guy to
wonder which init() function is called.
+1
The main issue with this is the fact that stm32 extends all the way from M0
to M7, in total set of 11 series

• STM32F0 Series
• STM32F1 Series
• STM32F2 Series
• STM32F3 Series
• STM32F4 Series
• STM32F7 Series
• STM32L0 Series
• STM32L1 Series
• STM32L4 Series
• STM32T Series
• STM32W Series

where each series can have up to 10 different SoCs in some cases.
I'm not sure I understand this comment. Is this a positive or negative to the proposed solution?


Nashif, Anas
 

On 2 Mar 2016, at 10:54, Benjamin Walsh <benjamin.walsh(a)windriver.com> wrote:

On Tue, Mar 01, 2016 at 10:17:17AM -0800, Dirk Brandewie wrote:


On 02/29/2016 02:26 PM, Kalowsky, Daniel wrote:
-----Original Message-----
First suggestion, create an arch/arm/soc/stm32, and use the Kconfig to
allow selecting of the various flavors of the STM32 chip. This would
be similar to what you've already got with the Kconfig.soc.stm32f103ve
file, merged with the values from your Kconfig.soc. Then keeping the
Kconfig to the pieces generic to all the STM32 portions (i.e. flash
size, base address, etc).

Thoughts?
Makes sense. I think we should also add another 'MCU family' level of
hierarchy. We would have then:

arch/
arm/
soc/
stm32/
stm32f1xx/
<soc specific>
stm32f2xx/
<soc specific>
stm32f4xx/
<soc specific>
I'm not opposed to this.

Ben/Dirk any commentary?
Having thought about it for 10 seconds it seems reasonable :-) To the
greatest extent reasonable please avoid link time binding of SOC specifc
code into the generic stm32 code. We don't want to the next guy to
wonder which init() function is called.
+1
The main issue with this is the fact that stm32 extends all the way from M0 to M7, in total set of 11 series

• STM32F0 Series
• STM32F1 Series
• STM32F2 Series
• STM32F3 Series
• STM32F4 Series
• STM32F7 Series
• STM32L0 Series
• STM32L1 Series
• STM32L4 Series
• STM32T Series
• STM32W Series

where each series can have up to 10 different SoCs in some cases.


Anas



If it turns out to painful we can "move the deck chairs around later" (tm)
IMO having a soc specific defconfig would be great too. Right now there are
only arch and board defconfigs. A soc defconfig would save a lot of typing
and if'ing in Kconfigs, what happens to be really error prone by the way.
Depending upon what you see going into such a file, this is a relatively reasonable idea.

Second thing to add, in your use of addresses, please add a comment
where these values were originally sourced from (aka the DataSheet
document to be used for cross-referencing). Specifically looking at
your soc.h.
Ok.


Third, I like your rcc.h, using the union for structs. In my opinion
this makes things a lot cleaner. This is also has been a bit of a
contention for the project between several of us. :-) Two things on
this. 1) rename val to raw, it keeps it consistent with other
locations where this has been in use. 2) you may also need to add
#define register definitions for these. I've got a bunch already
typed up that I can share with you off-list to save some typing (if
you want it).
Sure, I'd be glad to take a look.



The demo code has been archived in bboozzoo/stm32f103-demo branch.

Once I deem the work somewhat feature complete, I'll clean that up
and push for review. I'd be glad if someone took a look at the code
and shared their opinion on whether the path I took seems reasonable.

I think there might be some room for extending clock control driver
API. The problem comes form the fact that some chips may a more
elaborate clock distribution within the SoC itself. For instance,
inside the STM32F103x chip, there are at least 2 clock domains
driving the peripherals (low speed clock
PCLK1 and high speed PCLK2). When setting up UARTx baud rate one
needs to know the clock rate in order to calculate the timings for the
peripheral.
Also, on this particular chip
USART1 is driven by PCLK2, while the remaining for UARTx are driven
by PLCK1. Finding out the rate of the clock driving particular
peripheral is useful if we want to keep things generic to some extent.

I've added the following call to driver specific part of the API:

void stm32f10x_clock_control_get_subsys_rate(struct device *clock,
clock_control_subsys_t subsys,
uint32_t *rate);

where `subsys` is the regular clock subsystem and the clock rate is
returned in `*rate` field.

Since this might be a more general problem, I think the
functionality can be added to the clock_control API:

typedef void (*clock_control_get_clock)(struct device *dev,
clock_control_subsys_t sys,
uint32_t *rate);

struct clock_control_driver_api {
...
clock_control_get_clock get_clock;
}

As for the drivers. The RCC (Reset & Clock Control) driver mostly
delivers the CC part of the name. I have intentionally specified a
low priority (1) in
DEVICE_INIT() call. The RCC has to be initialized early in the
startup process, otherwise no peripherals will work.

RCC subsytem mapping enums have been put in driver specific header.
I did not feel like these belonged to the SoC specific part as the
mappings are shared by the whole family of SoCs.
I need to look more at this, as in my own port for STM32F2xx I've left
the RCC in the SOC section. Not saying that is right, just have left
it there for now.

The pinmux driver contains only the parts essential for getting the
UART to work. Again, this is not part of the board specific code,
neither the SoC specific one, as the driver is shared by a family of
MCUs. I have looked at the pinmux driver for Galileo and I
understand the the API has been shaped having this board in mind.
While the API methods are sufficient, I have only implemented the
*_get() and *_set() calls. The pin config on STM32F10x is a bit
elaborate so I reused the `func` parameter in *_get()/*_set() calls
to pass driver specific function mappings. The function mapping
names are currently shaped after pinconf-generic Linux driver.
Perhaps I'm being too pragmatic here, but I'd like to avoid replication of
STM32Cube's functionality and typing in all possible pin mappings.

I'm 90% sure that the pinmux can probably be renamed to something like
pinmux_stm32, as I believe the functions are the same for the F1xx and
F2xx series of chips. I would strongly encourage you to read some
just recently posted messages on the mailing list for changes that are
coming to the pinmux. It would be best to utilize those early on.

The pinmux you're providing is very SOC specific, which is good.
Are you referring to this discussion?
https://lists.zephyrproject.org/archives/list/devel(a)lists.zephyrproject.org/
message/P6HMQUTHVAL4PZXSNRJCYTEBDGXFQWKH/
That would be the very specific discussion. :-)

The UART driver is still using polling, however drive init has been
reworked to use the pinmux and clock_control APIs. The baud rate is
not hardcoded anymore and is calculated based on configuration. The
fixed point arithmetic should be correct for low speeds and close enough
for higher speeds.

The UART is looking like it is coming along nicely. Again I think
this is code that can be re-used on many of the STM32 chips.
Agreed. I've just briefly looked at STM32F4xxxx Reference Manual. The
register map looks the same. Specific registers (CR1, CR3) use a couple of bits
more, but nothing that cannot be handled by #ifdefs. I expect that the lower
families (2xxx, 3xxx) are also very much identical.


Benjamin Walsh <benjamin.walsh@...>
 

On Tue, Mar 01, 2016 at 10:17:17AM -0800, Dirk Brandewie wrote:


On 02/29/2016 02:26 PM, Kalowsky, Daniel wrote:
-----Original Message-----
First suggestion, create an arch/arm/soc/stm32, and use the Kconfig to
allow selecting of the various flavors of the STM32 chip. This would
be similar to what you've already got with the Kconfig.soc.stm32f103ve
file, merged with the values from your Kconfig.soc. Then keeping the
Kconfig to the pieces generic to all the STM32 portions (i.e. flash
size, base address, etc).

Thoughts?
Makes sense. I think we should also add another 'MCU family' level of
hierarchy. We would have then:

arch/
arm/
soc/
stm32/
stm32f1xx/
<soc specific>
stm32f2xx/
<soc specific>
stm32f4xx/
<soc specific>
I'm not opposed to this.

Ben/Dirk any commentary?
Having thought about it for 10 seconds it seems reasonable :-) To the
greatest extent reasonable please avoid link time binding of SOC specifc
code into the generic stm32 code. We don't want to the next guy to
wonder which init() function is called.
+1

If it turns out to painful we can "move the deck chairs around later" (tm)
IMO having a soc specific defconfig would be great too. Right now there are
only arch and board defconfigs. A soc defconfig would save a lot of typing
and if'ing in Kconfigs, what happens to be really error prone by the way.
Depending upon what you see going into such a file, this is a relatively reasonable idea.

Second thing to add, in your use of addresses, please add a comment
where these values were originally sourced from (aka the DataSheet
document to be used for cross-referencing). Specifically looking at
your soc.h.
Ok.


Third, I like your rcc.h, using the union for structs. In my opinion
this makes things a lot cleaner. This is also has been a bit of a
contention for the project between several of us. :-) Two things on
this. 1) rename val to raw, it keeps it consistent with other
locations where this has been in use. 2) you may also need to add
#define register definitions for these. I've got a bunch already
typed up that I can share with you off-list to save some typing (if
you want it).
Sure, I'd be glad to take a look.



The demo code has been archived in bboozzoo/stm32f103-demo branch.

Once I deem the work somewhat feature complete, I'll clean that up
and push for review. I'd be glad if someone took a look at the code
and shared their opinion on whether the path I took seems reasonable.

I think there might be some room for extending clock control driver
API. The problem comes form the fact that some chips may a more
elaborate clock distribution within the SoC itself. For instance,
inside the STM32F103x chip, there are at least 2 clock domains
driving the peripherals (low speed clock
PCLK1 and high speed PCLK2). When setting up UARTx baud rate one
needs to know the clock rate in order to calculate the timings for the
peripheral.
Also, on this particular chip
USART1 is driven by PCLK2, while the remaining for UARTx are driven
by PLCK1. Finding out the rate of the clock driving particular
peripheral is useful if we want to keep things generic to some extent.

I've added the following call to driver specific part of the API:

void stm32f10x_clock_control_get_subsys_rate(struct device *clock,
clock_control_subsys_t subsys,
uint32_t *rate);

where `subsys` is the regular clock subsystem and the clock rate is
returned in `*rate` field.

Since this might be a more general problem, I think the
functionality can be added to the clock_control API:

typedef void (*clock_control_get_clock)(struct device *dev,
clock_control_subsys_t sys,
uint32_t *rate);

struct clock_control_driver_api {
...
clock_control_get_clock get_clock;
}

As for the drivers. The RCC (Reset & Clock Control) driver mostly
delivers the CC part of the name. I have intentionally specified a
low priority (1) in
DEVICE_INIT() call. The RCC has to be initialized early in the
startup process, otherwise no peripherals will work.

RCC subsytem mapping enums have been put in driver specific header.
I did not feel like these belonged to the SoC specific part as the
mappings are shared by the whole family of SoCs.
I need to look more at this, as in my own port for STM32F2xx I've left
the RCC in the SOC section. Not saying that is right, just have left
it there for now.

The pinmux driver contains only the parts essential for getting the
UART to work. Again, this is not part of the board specific code,
neither the SoC specific one, as the driver is shared by a family of
MCUs. I have looked at the pinmux driver for Galileo and I
understand the the API has been shaped having this board in mind.
While the API methods are sufficient, I have only implemented the
*_get() and *_set() calls. The pin config on STM32F10x is a bit
elaborate so I reused the `func` parameter in *_get()/*_set() calls
to pass driver specific function mappings. The function mapping
names are currently shaped after pinconf-generic Linux driver.
Perhaps I'm being too pragmatic here, but I'd like to avoid replication of
STM32Cube's functionality and typing in all possible pin mappings.

I'm 90% sure that the pinmux can probably be renamed to something like
pinmux_stm32, as I believe the functions are the same for the F1xx and
F2xx series of chips. I would strongly encourage you to read some
just recently posted messages on the mailing list for changes that are
coming to the pinmux. It would be best to utilize those early on.

The pinmux you're providing is very SOC specific, which is good.
Are you referring to this discussion?
https://lists.zephyrproject.org/archives/list/devel(a)lists.zephyrproject.org/
message/P6HMQUTHVAL4PZXSNRJCYTEBDGXFQWKH/
That would be the very specific discussion. :-)

The UART driver is still using polling, however drive init has been
reworked to use the pinmux and clock_control APIs. The baud rate is
not hardcoded anymore and is calculated based on configuration. The
fixed point arithmetic should be correct for low speeds and close enough
for higher speeds.

The UART is looking like it is coming along nicely. Again I think
this is code that can be re-used on many of the STM32 chips.
Agreed. I've just briefly looked at STM32F4xxxx Reference Manual. The
register map looks the same. Specific registers (CR1, CR3) use a couple of bits
more, but nothing that cannot be handled by #ifdefs. I expect that the lower
families (2xxx, 3xxx) are also very much identical.
--
Benjamin Walsh, SMTS
Wind River Rocket
www.windriver.com
Zephyr kernel maintainer
www.zephyrproject.org


Maciek Borzecki <maciek.borzecki@...>
 

On Wed, Mar 2, 2016 at 2:49 AM, Kalowsky, Daniel
<daniel.kalowsky(a)intel.com> wrote:


-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Tuesday, March 1, 2016 11:19 AM
To: Brandewie, Dirk J <dirk.j.brandewie(a)intel.com>
Cc: Kalowsky, Daniel <daniel.kalowsky(a)intel.com>;
devel(a)lists.zephyrproject.org; users(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Re: STM32F103x port

On 03/01 10:17, Dirk Brandewie wrote:


On 02/29/2016 02:26 PM, Kalowsky, Daniel wrote:
-----Original Message-----
First suggestion, create an arch/arm/soc/stm32, and use the Kconfig to
allow selecting of the various flavors of the STM32 chip. This would
be similar to what you've already got with the Kconfig.soc.stm32f103ve
file, merged with the values from your Kconfig.soc. Then keeping the
Kconfig to the pieces generic to all the STM32 portions (i.e. flash
size, base address, etc).

Thoughts?
Makes sense. I think we should also add another 'MCU family' level of
hierarchy. We would have then:

arch/
arm/
soc/
stm32/
stm32f1xx/
<soc specific>
stm32f2xx/
<soc specific>
stm32f4xx/
<soc specific>
I'm not opposed to this.

Ben/Dirk any commentary?
Having thought about it for 10 seconds it seems reasonable :-) To the
greatest extent reasonable please avoid link time binding of SOC specifc
code into the generic stm32 code. We don't want to the next guy to
wonder which init() function is called.
Do you mind taking a look here
https://github.com/bboozzoo/zephyr/tree/bboozzoo/stm32f103-next-soc-
layout-change
and sending some feedback?

The branch implements this layout:
arch/
arm/
soc/
stm32/
Kconfig <-- includes family specific Kconfigs
Kconfig.soc <-- SOC family selection under 'General platform..'
stm32f1x/
Only one x? I'll admit to being relatively new to the STM32 family so it's not clear to me if 10x and 1xx will make any difference. Same goes for other STM32F models. I'm not sure the sub-directories are needed yet. Still digesting this one.
Single 'x' as in 'everything that comes after the i-1 character' :)

As for the models, I'm not aware of any non STF32F10x MCUs, however
all of these are collectively referred to as STM32F1
series/family. The core is different between F[0-4] families, F1 are
all Cortex-M3, F0 are Cortex-M0[+], F3/4 are Cortex-M4.

Within a family, the MCUs differ wrt. to clock and peripherals
present. Then within a subfamily (?), ex. STM32F103xx, the MCUs differ
again, for instance there's no DAC in STM32F103xB, but there are 2
DACs in STM32F103x[CDEFG]. Again, the xB line only has 3 UARTs, while
other variants have 5 ports.

The last letter indicates the amount of flash and SRAM (dubbed as
high- low- medium- density int the specs).

The one but last letter, ex. STM32F103VE - V indicates the pin
count. This will influence pin remapping and in the case of packages
with very few pins, it will indicate that certain peripherals may have
been left out.

A quite elaborate part number coding scheme. That's why I included per
family subdirectories and Kconfig.soc.<mcumodel> in my proposal.


Makefile
Kconfig.soc.family <-- list of possible MCUs in this family
general defaults
Having done some minor toying around with Kconfig today, I decided to use Kconfig.soc to just declare the generic STM32 family. From there, the Kconfig is used to better tune to which family type, but that most likely isn't enough granularity. Looks like you and I had done some similar work, as I just uploaded my minor tinkering from today.
Cheers,
--
Maciek Borzecki


Kalowsky, Daniel <daniel.kalowsky@...>
 

Hey Pawel,

-----Original Message-----
From: Pawel Wodnicki [mailto:root(a)32bitmicro.com]
Sent: Tuesday, March 1, 2016 8:26 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: STM32F103x port

Hi,

I have been working with Dan's stm32 patch to add support for stm32f4xx
and just wanted to share couple of thoughts.
https://gerrit.zephyrproject.org/r/#/c/209/
Oh wow, didn't realize that DRAFTS were visible to the world. Guess this means I'll need to be more careful about what I put in there. Sorry for the large amount of broken code that was in the patches before.


I would second the idea of adding additional level of hierarchy under
st_stm32 soc for functionality specific to the line of ST MCU's.
Just looking at the STM32F chips there is 6 variants not even including
STM32L. Organizing soc folders to reflect that hierarchy would help dealing
with the variability within the STM32 line of mcu's without cluttering
arch/arm/soc/ folder.

arch/arm/soc/st_stm32/
arch/arm/soc/st_stm32/stm32f0xx/
arch/arm/soc/st_stm32/stm32f1xx/
arch/arm/soc/st_stm32/stm32f2xx/
arch/arm/soc/st_stm32/stm32f2xx/
arch/arm/soc/st_stm32/stm32f4xx/
arch/arm/soc/st_stm32/stm32f7xx/

Common functionality could be implemented at the arch/arm/soc/st_stm32/
level, ie:

arch/arm/soc/st_stm32/soc.c:static int st_stm32_init(struct device *arg)

But when needed SOC api could be structured in a hierarchical way, ie:

arch/arm/soc/st_stm32/soc.c:void clock_init(void)

arch/arm/soc/st_stm32/stm32f1xx/soc.c:void clock_init_stm32f1xx(void)
..
arch/arm/soc/st_stm32/stm32f4xx/soc.c:void clock_init_stm32f4xx(void)
A lot of this sounds like what Maciek is suggesting as the layout.

As for drivers for specific stm32 peripherals some like the RCC (Reset & Clock
Control)
could be handled at the st_stm32 soc top level with #ifdefs but there are
some peripherals that use different versions of the hardware IP (GPIO is a
good example) and would be easier to handle at the level specific to the
MCU soc.
Wind River just submitted a series of drivers for the FRDM-K64F. It might be worth looking at and modeling the STM32 after something similar.


Kalowsky, Daniel <daniel.kalowsky@...>
 

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Tuesday, March 1, 2016 11:19 AM
To: Brandewie, Dirk J <dirk.j.brandewie(a)intel.com>
Cc: Kalowsky, Daniel <daniel.kalowsky(a)intel.com>;
devel(a)lists.zephyrproject.org; users(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Re: STM32F103x port

On 03/01 10:17, Dirk Brandewie wrote:


On 02/29/2016 02:26 PM, Kalowsky, Daniel wrote:
-----Original Message-----
First suggestion, create an arch/arm/soc/stm32, and use the Kconfig to
allow selecting of the various flavors of the STM32 chip. This would
be similar to what you've already got with the Kconfig.soc.stm32f103ve
file, merged with the values from your Kconfig.soc. Then keeping the
Kconfig to the pieces generic to all the STM32 portions (i.e. flash
size, base address, etc).

Thoughts?
Makes sense. I think we should also add another 'MCU family' level of
hierarchy. We would have then:

arch/
arm/
soc/
stm32/
stm32f1xx/
<soc specific>
stm32f2xx/
<soc specific>
stm32f4xx/
<soc specific>
I'm not opposed to this.

Ben/Dirk any commentary?
Having thought about it for 10 seconds it seems reasonable :-) To the
greatest extent reasonable please avoid link time binding of SOC specifc
code into the generic stm32 code. We don't want to the next guy to
wonder which init() function is called.
Do you mind taking a look here
https://github.com/bboozzoo/zephyr/tree/bboozzoo/stm32f103-next-soc-
layout-change
and sending some feedback?

The branch implements this layout:
arch/
arm/
soc/
stm32/
Kconfig <-- includes family specific Kconfigs
Kconfig.soc <-- SOC family selection under 'General platform..'
stm32f1x/
Only one x? I'll admit to being relatively new to the STM32 family so it's not clear to me if 10x and 1xx will make any difference. Same goes for other STM32F models. I'm not sure the sub-directories are needed yet. Still digesting this one.

Makefile
Kconfig.soc.family <-- list of possible MCUs in this family
general defaults
Having done some minor toying around with Kconfig today, I decided to use Kconfig.soc to just declare the generic STM32 family. From there, the Kconfig is used to better tune to which family type, but that most likely isn't enough granularity. Looks like you and I had done some similar work, as I just uploaded my minor tinkering from today.

Kconfig.soc.stm32f103ve <-- STM32F103VE specific settings
...
Kconfig.soc.stm32f103rb <-- xxRB model if we had
NUCLEO-FRB103 board
soc.{c,h} <-- MCU specifi headers & code
stm32f2x/
<soc specific>
stm32f4x/
<soc specific>

There's a little trick in Kconfig under stm32/<MCU-specific>, CONFIG_SOC
is set to have a default of pointing to MCU specific directory. For
example, for stm32f1x, the SOC defaults to stm32/stm32f1x, this ensures
that MCU specific path is included in CFLAGS.

Then under menuconfig we have:
------
Location:
-> ARM architecture
-> General Platform Configuration
-> SoC Selection (<choice> [=y]) <-- STM32F1x
-----

and MCU selection:

-----
Location:
-> ARM architecture
-> STM32F1x MCU Selection (<choice> [=y]) <-- STM32F103VE
-----

Cheers,
--
Maciek Borzecki


Maciek Borzecki <maciek.borzecki@...>
 

On 03/01 10:17, Dirk Brandewie wrote:


On 02/29/2016 02:26 PM, Kalowsky, Daniel wrote:
-----Original Message-----
First suggestion, create an arch/arm/soc/stm32, and use the Kconfig to
allow selecting of the various flavors of the STM32 chip. This would
be similar to what you've already got with the Kconfig.soc.stm32f103ve
file, merged with the values from your Kconfig.soc. Then keeping the
Kconfig to the pieces generic to all the STM32 portions (i.e. flash
size, base address, etc).

Thoughts?
Makes sense. I think we should also add another 'MCU family' level of
hierarchy. We would have then:

arch/
arm/
soc/
stm32/
stm32f1xx/
<soc specific>
stm32f2xx/
<soc specific>
stm32f4xx/
<soc specific>
I'm not opposed to this.

Ben/Dirk any commentary?
Having thought about it for 10 seconds it seems reasonable :-) To the
greatest extent reasonable please avoid link time binding of SOC specifc
code into the generic stm32 code. We don't want to the next guy to
wonder which init() function is called.
Do you mind taking a look here
https://github.com/bboozzoo/zephyr/tree/bboozzoo/stm32f103-next-soc-layout-change
and sending some feedback?

The branch implements this layout:
arch/
arm/
soc/
stm32/
Kconfig <-- includes family specific Kconfigs
Kconfig.soc <-- SOC family selection under 'General platform..'
stm32f1x/
Makefile
Kconfig.soc.family <-- list of possible MCUs in this family
general defaults
Kconfig.soc.stm32f103ve <-- STM32F103VE specific settings
...
Kconfig.soc.stm32f103rb <-- xxRB model if we had
NUCLEO-FRB103 board
soc.{c,h} <-- MCU specifi headers & code
stm32f2x/
<soc specific>
stm32f4x/
<soc specific>

There's a little trick in Kconfig under stm32/<MCU-specific>, CONFIG_SOC
is set to have a default of pointing to MCU specific directory. For
example, for stm32f1x, the SOC defaults to stm32/stm32f1x, this ensures
that MCU specific path is included in CFLAGS.

Then under menuconfig we have:
------
Location:
-> ARM architecture
-> General Platform Configuration
-> SoC Selection (<choice> [=y]) <-- STM32F1x
-----

and MCU selection:

-----
Location:
-> ARM architecture
-> STM32F1x MCU Selection (<choice> [=y]) <-- STM32F103VE
-----

Cheers,
--
Maciek Borzecki


Dirk Brandewie <dirk.j.brandewie@...>
 

On 02/29/2016 02:26 PM, Kalowsky, Daniel wrote:
-----Original Message-----
First suggestion, create an arch/arm/soc/stm32, and use the Kconfig to
allow selecting of the various flavors of the STM32 chip. This would
be similar to what you've already got with the Kconfig.soc.stm32f103ve
file, merged with the values from your Kconfig.soc. Then keeping the
Kconfig to the pieces generic to all the STM32 portions (i.e. flash
size, base address, etc).

Thoughts?
Makes sense. I think we should also add another 'MCU family' level of
hierarchy. We would have then:

arch/
arm/
soc/
stm32/
stm32f1xx/
<soc specific>
stm32f2xx/
<soc specific>
stm32f4xx/
<soc specific>
I'm not opposed to this.

Ben/Dirk any commentary?
Having thought about it for 10 seconds it seems reasonable :-) To the
greatest extent reasonable please avoid link time binding of SOC specifc
code into the generic stm32 code. We don't want to the next guy to
wonder which init() function is called.


If it turns out to painful we can "move the deck chairs around later" (tm)
IMO having a soc specific defconfig would be great too. Right now there are
only arch and board defconfigs. A soc defconfig would save a lot of typing
and if'ing in Kconfigs, what happens to be really error prone by the way.
Depending upon what you see going into such a file, this is a relatively reasonable idea.

Second thing to add, in your use of addresses, please add a comment
where these values were originally sourced from (aka the DataSheet
document to be used for cross-referencing). Specifically looking at
your soc.h.
Ok.


Third, I like your rcc.h, using the union for structs. In my opinion
this makes things a lot cleaner. This is also has been a bit of a
contention for the project between several of us. :-) Two things on
this. 1) rename val to raw, it keeps it consistent with other
locations where this has been in use. 2) you may also need to add
#define register definitions for these. I've got a bunch already
typed up that I can share with you off-list to save some typing (if
you want it).
Sure, I'd be glad to take a look.



The demo code has been archived in bboozzoo/stm32f103-demo branch.

Once I deem the work somewhat feature complete, I'll clean that up
and push for review. I'd be glad if someone took a look at the code
and shared their opinion on whether the path I took seems reasonable.

I think there might be some room for extending clock control driver
API. The problem comes form the fact that some chips may a more
elaborate clock distribution within the SoC itself. For instance,
inside the STM32F103x chip, there are at least 2 clock domains
driving the peripherals (low speed clock
PCLK1 and high speed PCLK2). When setting up UARTx baud rate one
needs to know the clock rate in order to calculate the timings for the
peripheral.
Also, on this particular chip
USART1 is driven by PCLK2, while the remaining for UARTx are driven
by PLCK1. Finding out the rate of the clock driving particular
peripheral is useful if we want to keep things generic to some extent.

I've added the following call to driver specific part of the API:

void stm32f10x_clock_control_get_subsys_rate(struct device *clock,
clock_control_subsys_t subsys,
uint32_t *rate);

where `subsys` is the regular clock subsystem and the clock rate is
returned in `*rate` field.

Since this might be a more general problem, I think the
functionality can be added to the clock_control API:

typedef void (*clock_control_get_clock)(struct device *dev,
clock_control_subsys_t sys,
uint32_t *rate);

struct clock_control_driver_api {
...
clock_control_get_clock get_clock;
}

As for the drivers. The RCC (Reset & Clock Control) driver mostly
delivers the CC part of the name. I have intentionally specified a
low priority (1) in
DEVICE_INIT() call. The RCC has to be initialized early in the
startup process, otherwise no peripherals will work.

RCC subsytem mapping enums have been put in driver specific header.
I did not feel like these belonged to the SoC specific part as the
mappings are shared by the whole family of SoCs.
I need to look more at this, as in my own port for STM32F2xx I've left
the RCC in the SOC section. Not saying that is right, just have left
it there for now.

The pinmux driver contains only the parts essential for getting the
UART to work. Again, this is not part of the board specific code,
neither the SoC specific one, as the driver is shared by a family of
MCUs. I have looked at the pinmux driver for Galileo and I
understand the the API has been shaped having this board in mind.
While the API methods are sufficient, I have only implemented the
*_get() and *_set() calls. The pin config on STM32F10x is a bit
elaborate so I reused the `func` parameter in *_get()/*_set() calls
to pass driver specific function mappings. The function mapping
names are currently shaped after pinconf-generic Linux driver.
Perhaps I'm being too pragmatic here, but I'd like to avoid replication of
STM32Cube's functionality and typing in all possible pin mappings.

I'm 90% sure that the pinmux can probably be renamed to something like
pinmux_stm32, as I believe the functions are the same for the F1xx and
F2xx series of chips. I would strongly encourage you to read some
just recently posted messages on the mailing list for changes that are
coming to the pinmux. It would be best to utilize those early on.

The pinmux you're providing is very SOC specific, which is good.
Are you referring to this discussion?
https://lists.zephyrproject.org/archives/list/devel(a)lists.zephyrproject.org/
message/P6HMQUTHVAL4PZXSNRJCYTEBDGXFQWKH/
That would be the very specific discussion. :-)

The UART driver is still using polling, however drive init has been
reworked to use the pinmux and clock_control APIs. The baud rate is
not hardcoded anymore and is calculated based on configuration. The
fixed point arithmetic should be correct for low speeds and close enough
for higher speeds.

The UART is looking like it is coming along nicely. Again I think
this is code that can be re-used on many of the STM32 chips.
Agreed. I've just briefly looked at STM32F4xxxx Reference Manual. The
register map looks the same. Specific registers (CR1, CR3) use a couple of bits
more, but nothing that cannot be handled by #ifdefs. I expect that the lower
families (2xxx, 3xxx) are also very much identical.