This is the mail archive of the
mailing list for the eCos project.
Re: Cortex port
- From: "simon dot kallweit at intefo dot ch" <simon dot kallweit at intefo dot ch>
- To: Robin Randhawa <robin dot randhawa at gmail dot com>
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: Thu, 11 Sep 2008 08:59:27 +0200
- Subject: Re: [ECOS] Cortex port
- References: <48C7CD52.email@example.com> <1221087782.19606.9.camel@amethyst>
Robin Randhawa wrote:
On Wed, 2008-09-10 at 15:36 +0200, firstname.lastname@example.org 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,
* 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
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
* 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.
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
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.
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss