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

[Henrik Maier]

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 
(STM32F2) but both should be able to share the same device drivers for 
CPU peripherals.

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.


Henrik