Re: [users] Re: Re: Re: Re: Re: STM32F103x port

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

-----Original Message-----
From: Nashif, Anas
Sent: Wednesday, March 9, 2016 5:49 PM
To: Boie, Andrew P <andrew.p.boie(a)>; Kalowsky, Daniel
Cc: users(a); maciek.borzecki(a);
devel(a); Walsh, Benjamin (Wind River)
Subject: Re: [devel] Re: [users] Re: Re: Re: Re: Re: STM32F103x port

On 09/03/2016, 19:51, "Boie, Andrew P" <andrew.p.boie(a)> wrote:

On Wed, 2016-03-09 at 21:35 +0000, Kalowsky, Daniel wrote:
-----Original Message-----
Summing up, what you're basically suggesting is having a structure
like this (assumig that we keep vendor prefix for the time being):


If we're on the same page then i"ll post some patches tomorrow.
like an easy fix.
Yes, the only different from what you have right now is having 1 level
less. I
think everything else should stay the same.
I not convinced that is any good. You're essentially going to create a larger
mess of MCUs in the arch/arm/soc directory.

The goal of keeping everything in a common directory (st_stm32) is to
enforce maximum sharing between MCUs where possible. For example, the
stm32f1_init is really the same for the STM32F{1 | 2 | 3 | 4 }x MCUs. Moving
this into an upper level "common" area, not only makes it difficult to find, it
just creates confusion as we add in future platforms.

Do we need another layer of abstraction in the build for SoC variants?
Where did you see a new layer in what I said? The current patch and adding
st_stm32 is adding a new layer. st_stm32 is not an SoC, its an architecture
(just like there is STM8) that has different variants (M0+, M3, M4, …) that
have additional SoCs. st_stm32 is something comparable to Quark from x86.
So with this patch and looking at the Kconfig variables we have

arch / doc family or architecture / soc variant / soc / board
You're confusing me now. Please state your objection to the proposed method clearly here.

share Dan's concerns, I think it may be better to have st_stm32/ SoC and
then subdirectories with variants thereof, with common code at the

This would mean we have inheritance as follows: arch / soc /
soc_variant / board. This would be something fully supported by the
build system, like it knows about arches / boards / socs now.

Not keen on collapsing all this to just soc/.
This the design as we have now (and it was proposed and discussed). Under
soc/ we have frdm-k64f, atmel_sam3 which are SoCs and not sub-
architectures. If you think we need another layer, then we need to change
this across the board and not only for STM32.
Correct. That would be step #2.

Join to automatically receive all group messages.