[En-Nut-Discussion] Which is the latest greatest branch

[Ulrich Prinz]

Hi Henrik

On 28.10.2011 06:19, Henrik Maier wrote:
> On 28/10/2011 3:54 AM, Thiago A. Corrêa wrote:
>>> Instead of dividing arch into arch/arm and arch/cm3, I propose to use
>>>>  arch/armv4t, arch/armv5t and arch/armv7_m. The first two should contain
>>>>  the ARM7TDMI and ARM9EJ-S architectures we currently have in arch/arm
>>>>  and the latter will take the Cortex-M4. Code, which is valid for all ARM
>>>>  architectures can be left in arch/arm.
>> What about borowing linux tree layout:
>> arm/boot
>> arm/include
>> arm/march-at91
>> arm/march-cortex
>> arm/march-s3c24xx
> 
> Whatever structure we come up with, the structure should cater for the 
> fact that we may have different architectures for the same manufacturer.
> 
> For example for STM32F we have Cortex M3 (STM32F1 and STM32F2) and M4 
> (STM32F4) but both should be able to share the same device drivers for 
> CPU peripherals.
> 
I agree, that we should look at those who did that job for a long time
now before we try to develop something on our own. And yes, the linux
structures look pretty fine to me.

The good thing with the on top include directory is, that we really
could implement a unified API but still can hide special things in
includes that reside in the architectures directory.
No one ever said that includes have to stay in the one and only include dir.

But that would either mean to rework the ATMEL structures completely or
blow up the code of the Cortex.
ATMEL works with absolute register addresses while Cortex (and the whole
rest of the world) works with pointers to struct that represents a set
of registers.

> The same could apply to the Atmel ARMs where some device drivers 
> potentially can be shared across Atmel's SAM9 and SAM7 devices.
> 
> So something like:
> 
> arch/arm                  [generic ARM stuff like context.c]
> arch/arm/at91       [stuff for all AT91 devices]
> arch/arm/at91/sam9  [specific to this series]
> arch/arm/at91/sam7
> ...
> arch/arm/cortex     [stuff which can be shared across all Cortex MCUs]
> arch/arm/cortex/cmsis [latest version of the CMSIS]
> arch/arm/cortex/m0
> arch/arm/cortex/m3  [not sure if we would need those "m" subdirs...]
> arch/arm/cortex/m4
> ...
> arch/arm/stm32      [generic STM32 stuff]
> arch/arm/stm32/f1   [specific to this series]
> arch/arm/stm32/f2
> arch/arm/stm32/f4
> ...
> arch/arm/lpc/lpc2xxx
> ...
> dev  [device drivers which can be compiled for any architecture (wishful 
> thinking?)]
> 
> The same tree structure should exist under nut/arch and include/arch.
> 
> Once we have such a granular structure, we may not need a substructure 
> like dev/init/os/ldscripts any more. Otherwise I find the tree to 
> complicate to navigate.
> 
And it makes it much more easy to decide where a driver is attached or
works with. So in future it would be possible to write a, lets say
EEPROM driver, that is optimized for ARM architectures and it will
reside in the ARM tree and no AVR user will call the mailinglist cause
he cannot get it running :)
Cool idea.

This might duplicate files some times. But it also gives you the option
to develop a driver for your device you have and you can test with.
Another guy might pick it up and port it into an different part of the
tree. And in the End someone might see, that there is a unified driver
possible and moves them all together as one into the main driver tree.

The negative side effect is only that someone must from time to time
check if there is an option for this unification.
The really big benefit is, that the drivers presented for the different
architectures will work better (as they are tested) and do not blew the
compatibility.

I remember that I had to rework my eeprom driver several times cause it
worked perfectly with SAM7, but building nutos on Cortex and AVR failed.

I like this idea!

And it looks much more blown up as it really is. I am pretty sure that
we only need one cortex directory with some files then separated by name
*_m4 or _m3 but we'll see.

There could still be a lot of work with the qnutconf system to match it
to this.

For my cortex port it is no problem, I already have the separation
between cortex/CMSIS and STM. Yust need to move it a level up or down.

Best regards
Ulrich