Cortex-M3 support?

[Sebastian Huber]

Hi,

yes, the exception processing is completely different compared to the 
ARMv4 or ARMv5 architecture. The current ARM port is located mainly at 
'cpukit/score/cpu/arm'. I guess that all assembler files under this 
directory are worthless for the Cortex. I would add the Cortex specific 
files to this directory and prefix them with cortex_*. In the general 
CPU files cpu.c, cpu_asm.S, cpu.h and cpu_asm.h we can use conditional 
compilation. I don't know if it is possible to write the NVIC support in 
a BSP independent fashion.

CU

Joel Sherrill wrote:
> Mike Panetta wrote:
>   
>> I have been looking at CVS head and noticed that there is no cortex-m3 support in RTEMS.  Has anyone started work on this?  If yes, is the code available somewhere?  If no, where would one start a port for this ARM core?  It does not seem to quite fit in with the current ARM code in that exception handling is somewhat different...  Would one create a cortex-m3 directory under libcpu/arm,libbsp/arm, etc, or just put the code directly in the respective arm dir for this port?  I don't think adding CPU support for this core would be such a big deal, its just figuring out where to put it... BSP support on the other hand may be another matter...
>>
>>   
>>     
> Sebastian Huber has been reworking the ARM exception code so
> make sure you are on today's head and talking to him.
>
> In general terms, you want to start with the CPU core and
> ignore the peripherals.
>
> + make sure the multilib variant is in the tools
> + make sure the multilib variant is properly supported
>     by cpukit/score/arm and the libnetworking cksum routines.
>
> If you have a non-RTEMS "no OS" arm-elf toolset which can
> produce working executables for you, then you are almost
> ready for a very minimal BSP.
>
> + Use the linker script as base with additions for
>     workspace related symbols
> + Use the crt0.S from it (change call main -> boot_card)
> + implement a polled console using the libgloss support.
> + Use the "dummy idle task clock driver"
>
> At the moment, I think the avr, m32c, adn m32r BSPs are the closest
> examples to this minimal point.
>
> That gives you enough to run tests with no interrupts.
>
> Sebastian will need to step in for exception processing.
>
>   
>> Any help, suggestions on this would be greatly appreciated!
>>
>> Thanks,
>> Mike
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>>   
>>     
>
>
>   


-- 
Sebastian Huber, Embedded Brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.