Re: [ECOS] Cortex port

["simon dot kallweit at intefo dot ch" <simon dot kallweit at intefo dot ch>]

Robin Randhawa wrote:
> Hi Simon.
>
> On Wed, 2008-09-10 at 15:36 +0200, simon.kallweit@intefo.ch wrote:
>
>   
> > As some of you know, I'm currently writing a port for the Cortex-M3, 
> > specifically the STM32 CPU. I'm making good progress.
> >     
>
> Good to know. I guess they must have payed you after all! :)
> I started writing off a Cortex M3 port myself but will stall now
> awaiting your contribution so that I can patch in bits for the Luminary
> Micro Stellaris LM3S6965EVB board.
>   

Yeah I get payed for it, which helps a lot :)
>   
> >  The following is 
> > in place and working so far:
> >
> > * clock configuration using CDL (number of options might be a bit 
> > excessive, but the STM32 offers quite a few possibilities for clock 
> > configuration, see below)
> > * basic initializiation of cpu and startup code (clocks, flash, 
> > relocation etc.)
> > * serial debug/diagnostic driver (ethernet is not available on STM32)
> > * simple "framework" for GPIO configuration and manipulation
> > * partly (as I go) written register definitions for the STM32 (the STM32 
> > provided "header" files are pretty unusable)
> >     
>
> That's awesome. I got a very basic arch+variant+platform definition
> +init code and linker script going. The board I had access to was away
> so I started using qemu instead and that helped.
>   

Did you create a new architecture, or add the cortex stuff into the arm 
architecture? I have added a new architecture "cortexm" for now, as 
there seem to be rather big differences in interrupt handling and 
context switching.

>   
> > The next step will be the implementation of IRQ handling and context 
> > switching, which is not done yet, and will be rather tricky. During 
> > development a few questions came up, which I hope some of you might 
> > comment on:
> >
> > * In quite a few places I have to set and clear individual bits of 
> > registers. With the normal HAL_WRITE/READ_UINT32 access macros this is 
> > obviously a bit tedious sometimes. I didn't found any SET/CLEAR BIT 
> > macros. Is there a good reason for this? I have now written my own 
> > macros and added them to the hal_io.h headerfile. Any objections?
> > * I currently have prefixed all my STM32 register macros (var_io.h) with 
> > CYGARC_HAL_STM32_. I wonder if this is necessary, or the right way. It 
> > seems that different ports don't follow the same guidelines here. I'd 
> > much prefer to just prefix them with STM32_ as it would make the 
> > definitions rather a bit simpler to read and type.
> > * I have prefixed "functional macros" in var_io.h with 
> > HAL_CORTEXM_STM32_. This seems to be the preferred way. Anyway, is 
> > var_io.h the right place for things like GPIO configuration and 
> > manipulation, enabling/disabling clocks? As for example configuration of 
> > GPIO ports is rather too complex to be done in a macro, I have 
> > implemented a helper function in the stm32_misc.c of the variant. The 
> > macro then points to this function. Is this OK, or should the complete 
> > GPIO framework, as well as other helper for things like 
> > enabling/disabling/reseting clocks be moved to stm32_misc?
> > * I have currently added quite a few CDL options for the clock 
> > configuration. Things like clock selections, prescalers, nominal clock 
> > speeds etc. are all available for editing or viewing. Also the 
> > configuration is checked with a few constraints, so that no invalid 
> > clock configurations can be made. As there are about 20 options (10 of 
> > them being read only, showing nominal clock frequencies), I wonder if 
> > this is too excessive? I also wonder if there should be an API for 
> > runtime clock reconfiguration?
> > * The architecture CDL (as copied from the ARM architecture) still 
> > contains options for THUMB and THUMB interworking. I think these can be 
> > completely removed, as THUMB-2 is the only instructions set for the 
> > Cortex-M, and the defines should only be used in the ARM architecture. 
> > Right?
> >     
>
> That's exactly what I did. I took the ARM9 variant definition and the
> Integrator platform definition as a base since I had prior experience
> with these.
>
>   
> >  Should we leave the big-endian options? The Cortex-M can access 
> > data memory in big-endian format, but not the code.
> >     
>
> After encountering this fact in the TRM, I opted not to support this but
> I would leave this as a question for more experienced folks.
>   

Sounds like a good idea.

>   
> > * What about ARM-ICE Thread support? The ICE currently not supports 
> > Cortex CPUs, but I guess they will in the future. I don't have an 
> > ARM-ICE and will not be able to test.
> >     
>
> I have access to an ARM Micro-link box as well as an ARM Multi-ICE box
> so can possibly use these in time of need. I do not think that Cortex
> specific support is a mandatory option as of now IMHO.
>
>   

Ok, so you could do some testing?

> > These were just a few questions, I guess a lot more will arise sooner or 
> > later. The code not nearly mature enough to post patches, but If anyone 
> > is interested to help on the port, please let me know. I could also 
> > setup SVN access for simpler development.
> >     
>
> That would be much appreciated. Please let me know if you could set me
> up with access and I'll try to pitch in bits.
>   

Ok, I try to prepare everything so you can get access.

Simon

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss