On 09/03/2016, 19:51, "Boie, Andrew P" <andrew.p.boie(a)intel.com> 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):

arch/
arm/
soc/
st_stm32f1/
Kconfig.soc
Kconfig
...
soc.c
st_stm32f2/
...
st_stm32l0/

If we're on the same page then i"ll post some patches tomorrow. Seems
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

I
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
toplevel.

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.


Anas

--
Andrew Boie
Staff Engineer - EOS Zephyr
Intel Open Source Technology Center