[ECOS] eCosCentric Cortex-M port contribution

[ECOS] eCosCentric Cortex-M port contribution

[Nick Garnett]

The eCosCentric Cortex-M port has now been checked in to the
repository.

The following packages have been added:

hal/cortexm/arch
hal/cortexm/stm32/var
hal/cortexm/stm32/stm3210e_eval
devs/serial/cortexm/stm32
devs/flash/cortexm/stm32

ecos.db and NEWS have also been updated.
See the various ChangeLogs for details.


There are a few points about this port:

- The internal flash driver is for the Version 2 driver
  architecture. To use it you will need to check out the flash_v2
  branch and merge it with the trunk. A proper merge of V2 into the
  trunk is part of the eCos v3.0 work and is ongoing.

- Support for the NOR flash on the STM3210E board is also V2 based.

- There is currently no documentation for the HALs or drivers.

- A new ARM toolchain that supports the Cortex-M is available. This
  toolchain contains a number of patches for code generation and GDB
  issues.

  These toolchains are available under

  ftp://ecos.sourceware.org/pub/ecos/gnutools/

  Linux:  i386linux/ecoscentric-gnutools-arm-eabi-20081022-sw.i386linux.tar.bz2
  Cygwin: cygwin/ecoscentric-gnutools-arm-eabi-20081022-sw.cygwin.tar.bz2

  These will also become available at the usual mirror sites, see:
  http://ecos.sourceware.org/mirror.html
  http://sourceware.org/mirrors.html

  These tools will also be used in eCos v3.0 for targets based on the
  ARM architecture HAL. eCosCentric already have patches to make the
  tools work with the ARM HAL and will be providing those soon for
  v3.0, so there is no need to do so separately.

- Copyright and License headers currently use the original format,
  pending wholesale conversion to FSF copyright for v3.0.
  


-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071

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

Re: [ECOS] eCosCentric Cortex-M port contribution

[simon.kallweit]

Nick Garnett wrote:
> The eCosCentric Cortex-M port has now been checked in to the
> repository.
>
> The following packages have been added:
>
> hal/cortexm/arch
> hal/cortexm/stm32/var
> hal/cortexm/stm32/stm3210e_eval
> devs/serial/cortexm/stm32
> devs/flash/cortexm/stm32
>
> ecos.db and NEWS have also been updated.
> See the various ChangeLogs for details.
>   

This is good news. Already checked out and tried on my evalboard. Seems 
to run, expect some small issues. I have had a look at you're approach 
to context switching and interrupt handling. It's quite nicely done, 
although you don't use NVIC exception handling for normal context 
switches during thread execution, which is something I absolutely tried 
to do (and had lots of trouble with :). Also, your port does not have a 
unified SavedRegisters structure, which mine had. But it's nice that so 
much is written in plain C, my port has rather more assembler code.

Another difference is your GPIO framework for the STM32. As it seems 
your framework does not support "chanining" multiple pins on the same 
pin for configuration, which mine offered. In contrast your framework 
offers the possibility to store the configuration directly in the pin 
definition, which is a nice thing I guess. I might add support for 
chaining multiple pins, if there is nothing against it?

My port also featured some more "helper macros". This included things 
like enable/disable/reset peripheral clocks, setup FSMC controllers etc. 
which obviously improve code readability. Is there interest to get such 
macros in the main repo?

Also I had done some more register definitions which I can add. I also 
have a working wallclock driver for the STM32, which I will port to your 
port :) Will it be included or do you already have such a driver in the 
pipeline?

Many thanks for the contribution!

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

Re: [ECOS] eCosCentric Cortex-M port contribution

[Nick Garnett]

"simon.kallweit@intefo.ch" <simon.kallweit@intefo.ch> writes:

> 
> This is good news. Already checked out and tried on my
> evalboard. Seems to run, expect some small issues. I have had a look
> at you're approach to context switching and interrupt handling. It's
> quite nicely done, although you don't use NVIC exception handling for
> normal context switches during thread execution, which is something I
> absolutely tried to do (and had lots of trouble with :).

I tried that approach originally and had trouble with it too. Keeping
all thread context switching entirely in thread mode made a lot of
stuff much simpler, particularly the use of the two stacks.

> Also, your
> port does not have a unified SavedRegisters structure, which mine
> had.

I also tried that originally, but decided that the extra code needed
to save and restore compatible register sets, particularly during
interrupts was an unnecessary burden. The only place that the
different formats matter are in the debug code, where a little extra
code probably doesn't matter. The result is that threads, exceptions
and interrupts can use the most natural and efficient code to push and
pop state.

To be honest, I have never been entirely convinced that the use of a
common saved state format for all contexts was the right approach,
despite it being my idea. So this HAL was a small experiment to see
how using different formats would work. I think it has worked very
well.

> But it's nice that so much is written in plain C, my port has
> rather more assembler code.

Given that one of the features of the Cortex-M was that it could be
programmed in C throughout, I wanted to try and keep as close to that
idea as possible. I didn't quite manage it since there are some things
that eCos needs doing that can only be achieved in assembler.

> Another difference is your GPIO framework for the STM32. As it seems
> your framework does not support "chanining" multiple pins on the same
> pin for configuration, which mine offered. In contrast your framework
> offers the possibility to store the configuration directly in the pin
> definition, which is a nice thing I guess. I might add support for
> chaining multiple pins, if there is nothing against it?

I'm not sure what you mean by chaining here. Could you explain.

 
> My port also featured some more "helper macros". This included things
> like enable/disable/reset peripheral clocks, setup FSMC controllers
> etc. which obviously improve code readability. Is there interest to
> get such macros in the main repo?

My general approach to macros is that things that get done a lot
(like configuring GPIO lines), or which are exported to more generic
code (like the interrupt mask stuff) should go into macros.  However,
stuff that will only ever be called once (for example in a driver or
in HAL init code) should usually just be written out in the code. This
makes things easier for future maintenance since you don't have to go
searching for a macro defined in some obscure header.

So for things like peripheral clocks, which may be manipulated in
different drivers, I suspect a macro may be useful. However, for the
FSMC I suspect it is not very useful since this tends to be set up
once, and having the code scattered in various macros makes it harder
to read and maintain.

> 
> Also I had done some more register definitions which I can add.

Typing in register definitions is the most time consuming part of a
new port, so any new definitions will be welcome. Just make sure they
conform to the current naming and layout convention.

> I also
> have a working wallclock driver for the STM32, which I will port to
> your port :) Will it be included or do you already have such a driver
> in the pipeline?

We don't currently have a wallclock driver, so please feel free to
contribute yours. 

-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071


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

Re: [ECOS] eCosCentric Cortex-M port contribution

[Simon Kallweit]

Nick Garnett schrieb:
> "simon.kallweit@intefo.ch" <simon.kallweit@intefo.ch> writes:
>
>   
>> This is good news. Already checked out and tried on my
>> evalboard. Seems to run, expect some small issues. I have had a look
>> at you're approach to context switching and interrupt handling. It's
>> quite nicely done, although you don't use NVIC exception handling for
>> normal context switches during thread execution, which is something I
>> absolutely tried to do (and had lots of trouble with :).
>>     
>
> I tried that approach originally and had trouble with it too. Keeping
> all thread context switching entirely in thread mode made a lot of
> stuff much simpler, particularly the use of the two stacks.
>   

Yep, I can see. I think I was kind of blinded with the way the Cortex-M3 
presumed you to do context switching.

>   
>> Also, your
>> port does not have a unified SavedRegisters structure, which mine
>> had.
>>     
>
> I also tried that originally, but decided that the extra code needed
> to save and restore compatible register sets, particularly during
> interrupts was an unnecessary burden. The only place that the
> different formats matter are in the debug code, where a little extra
> code probably doesn't matter. The result is that threads, exceptions
> and interrupts can use the most natural and efficient code to push and
> pop state.
>
> To be honest, I have never been entirely convinced that the use of a
> common saved state format for all contexts was the right approach,
> despite it being my idea. So this HAL was a small experiment to see
> how using different formats would work. I think it has worked very
> well.
>   

Ok sounds like a good idea then. Your code looks cleaner than mine did, 
so it probably is the right way.

>   
>> But it's nice that so much is written in plain C, my port has
>> rather more assembler code.
>>     
>
> Given that one of the features of the Cortex-M was that it could be
> programmed in C throughout, I wanted to try and keep as close to that
> idea as possible. I didn't quite manage it since there are some things
> that eCos needs doing that can only be achieved in assembler.
>   

True, but compared to the ARM port it's like nothing. I think the port 
is very readable.

>   
>> Another difference is your GPIO framework for the STM32. As it seems
>> your framework does not support "chanining" multiple pins on the same
>> pin for configuration, which mine offered. In contrast your framework
>> offers the possibility to store the configuration directly in the pin
>> definition, which is a nice thing I guess. I might add support for
>> chaining multiple pins, if there is nothing against it?
>>     
>
> I'm not sure what you mean by chaining here. Could you explain.
>   

The idea is that you can OR multiple pins of the same port and 
configure/set them in one go.

>  
>   
>> My port also featured some more "helper macros". This included things
>> like enable/disable/reset peripheral clocks, setup FSMC controllers
>> etc. which obviously improve code readability. Is there interest to
>> get such macros in the main repo?
>>     
>
> My general approach to macros is that things that get done a lot
> (like configuring GPIO lines), or which are exported to more generic
> code (like the interrupt mask stuff) should go into macros.  However,
> stuff that will only ever be called once (for example in a driver or
> in HAL init code) should usually just be written out in the code. This
> makes things easier for future maintenance since you don't have to go
> searching for a macro defined in some obscure header.
>
> So for things like peripheral clocks, which may be manipulated in
> different drivers, I suspect a macro may be useful. However, for the
> FSMC I suspect it is not very useful since this tends to be set up
> once, and having the code scattered in various macros makes it harder
> to read and maintain.
>   

Understood. I'll try to cut it down and post a version.

>   
>> Also I had done some more register definitions which I can add.
>>     
>
> Typing in register definitions is the most time consuming part of a
> new port, so any new definitions will be welcome. Just make sure they
> conform to the current naming and layout convention.
>   

Yeah, I had a slightly different naming scheme, but adapting it should 
be simple.

>   
>> I also
>> have a working wallclock driver for the STM32, which I will port to
>> your port :) Will it be included or do you already have such a driver
>> in the pipeline?
>>     
>
> We don't currently have a wallclock driver, so please feel free to
> contribute yours. 
>   

Ok, I'll port it soon and post it. Btw. I did not find any interface to 
set alarms for the Wallclock. Is there a common interface to set such an 
alarm-wakeup?

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

Re: [ECOS] eCosCentric Cortex-M port contribution

[Nick Garnett]

Simon Kallweit <simon.kallweit@intefo.ch> writes:

> Nick Garnett schrieb:
> > "simon.kallweit@intefo.ch" <simon.kallweit@intefo.ch> writes:
> >
> >
> >> This is good news. Already checked out and tried on my
> >> evalboard. Seems to run, expect some small issues. I have had a look
> >> at you're approach to context switching and interrupt handling. It's
> >> quite nicely done, although you don't use NVIC exception handling for
> >> normal context switches during thread execution, which is something I
> >> absolutely tried to do (and had lots of trouble with :).
> >>
> >
> > I tried that approach originally and had trouble with it too. Keeping
> > all thread context switching entirely in thread mode made a lot of
> > stuff much simpler, particularly the use of the two stacks.
> >
> 
> Yep, I can see. I think I was kind of blinded with the way the
> Cortex-M3 presumed you to do context switching.

The Cortex-M seems to be designed to a particular model that ARM
decree is the right way to do things. Unfortunately that doesn't quite
fit with the way eCos works, so some extra effort is needed to match
them up.
 
> >
> >> But it's nice that so much is written in plain C, my port has
> >> rather more assembler code.
> >>
> >
> > Given that one of the features of the Cortex-M was that it could be
> > programmed in C throughout, I wanted to try and keep as close to that
> > idea as possible. I didn't quite manage it since there are some things
> > that eCos needs doing that can only be achieved in assembler.
> >
> 
> True, but compared to the ARM port it's like nothing. I think the port
> is very readable.

While there are some bits and pieces copied over from the ARM HAL,
particularly in the debug code, the HAL is structured more like the
PowerPC and MIPS HALs. In some ways the ARM HAL is a bit of a maverick
in the way it is structured.

> 
> >
> >> Another difference is your GPIO framework for the STM32. As it seems
> >> your framework does not support "chanining" multiple pins on the same
> >> pin for configuration, which mine offered. In contrast your framework
> >> offers the possibility to store the configuration directly in the pin
> >> definition, which is a nice thing I guess. I might add support for
> >> chaining multiple pins, if there is nothing against it?
> >>
> >
> > I'm not sure what you mean by chaining here. Could you explain.
> >
> 
> The idea is that you can OR multiple pins of the same port and
> configure/set them in one go.

I'm not really convinced that would be very useful. The pins for a
particular device are the ones that need relating, but they often need
configuring to different modes. See the UART pins for example. I think
having a set of pins defined in one decriptor might be confusing.

> >> I also
> >> have a working wallclock driver for the STM32, which I will port to
> >> your port :) Will it be included or do you already have such a driver
> >> in the pipeline?
> >>
> >
> > We don't currently have a wallclock driver, so please feel free to
> > contribute yours.
> 
> Ok, I'll port it soon and post it. Btw. I did not find any interface
> to set alarms for the Wallclock. Is there a common interface to set
> such an alarm-wakeup?

There is no alarm support in the wallclock device. Wallclocks are very
variable in the functionality they supply so the driver was designed
to support just the absolute minimum: just read and set a
seconds-since-epoch value.


-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071


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

Re: [ECOS] eCosCentric Cortex-M port contribution

[simon.kallweit]

Nick Garnett wrote:
> "simon.kallweit@intefo.ch" <simon.kallweit@intefo.ch> writes:
>
>   
>> Ok, I guess the issues you're talking about are not related to the
>> silicon errata just release by STMicroelectronics, concerning some
>> compilers generating incompatible code with all but the latest
>> revisions of the STM32 processors?
>>     
>
> No they are not. ST is annoyingly vague about exactly what the
> problems are in that erratum, but the description bears no relation to
> the issue we have. In any case, that erratum refers to medium-density
> devices while the part on the eval board is high-density. Of course I
> don't know what density device or revision you are using for your
> own hardware, but it is probably worth ensuring you get parts that
> avoid this issue.
>   

Yeah, our current designs are only based on high-density parts, so there 
should be no problem. What about the just released toolchain of 
Codesourcery, does it already fix the issues you're talking about?

>> It occurred to me, now that I have been digging into the subject more
>> deeply, that there are some issues concerning the design of the
>> Cortex-M3 to match with ecos. I think I do understand the design of
>> how a kernel should work under the Cortex-M3 architecture, but
>> admittedly I don't quite see yet how to do that efficiently with
>> ecos. Does your solution come with changes in the generic ecos kernel
>> code, or did you manage to solve it all in the Cortex-M3 HAL?
>>     
>
> It is all solved entirely in the Cortex-M HAL. Like you I initially
> thought that eCos would fit quite nicely. However, the priority
> mechanism, the strict enforcement of exception nesting and some other
> things mean that the obvious approach didn't work. You either ended up
> throwing a hard fault exception, or ended up with all interrupts
> masked. I believe my eventual solution is quite elegant, but it was
> won at the expense of some false starts.
>   

Yeah, my current implementation suffers from hard faults too :) and I 
guess this has to do exactly with what you told, enforcement of 
exception nesting. Anyway, would you give me some advice into what 
direction I have to go to fix the problems? I would really like to get 
this working, even if it's just for learning purposes.

>> Of course, it might make more sense to just wait for you to release
>> the port, but this puts us on hold for an uncertain amount of time, as
>> you don't make a clear statement of when the release will be. So I
>> think it would be great to start working with your port, as I guess
>> it's pretty sure that even if I continue developing and get a working
>> solution myself, it will be your port that ends up in the official
>> ecos community repository. So my past and future work will be quite
>> obsolete, despite the learning I did :(
>>     
>
> The exact release date depends on whether any serious problems are
> thrown up in testing and how quickly we can deal with the remaining
> toolchain issues.
>   

I see, this of course is a very vague statement.

> Everything you have learned so far will still be useful, so nothing
> has been wasted :-)
>   

That of course is true, I have learned a lot already. Anyway, I would 
have rather spend my time collaborating with you, working on a common 
solution instead of doing my own.

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

Re: [ECOS] eCosCentric Cortex-M port contribution

[Nick Garnett]

"simon.kallweit@intefo.ch" <simon.kallweit@intefo.ch> writes:

> 
> Ok, I guess the issues you're talking about are not related to the
> silicon errata just release by STMicroelectronics, concerning some
> compilers generating incompatible code with all but the latest
> revisions of the STM32 processors?

No they are not. ST is annoyingly vague about exactly what the
problems are in that erratum, but the description bears no relation to
the issue we have. In any case, that erratum refers to medium-density
devices while the part on the eval board is high-density. Of course I
don't know what density device or revision you are using for your
own hardware, but it is probably worth ensuring you get parts that
avoid this issue.

> It occurred to me, now that I have been digging into the subject more
> deeply, that there are some issues concerning the design of the
> Cortex-M3 to match with ecos. I think I do understand the design of
> how a kernel should work under the Cortex-M3 architecture, but
> admittedly I don't quite see yet how to do that efficiently with
> ecos. Does your solution come with changes in the generic ecos kernel
> code, or did you manage to solve it all in the Cortex-M3 HAL?

It is all solved entirely in the Cortex-M HAL. Like you I initially
thought that eCos would fit quite nicely. However, the priority
mechanism, the strict enforcement of exception nesting and some other
things mean that the obvious approach didn't work. You either ended up
throwing a hard fault exception, or ended up with all interrupts
masked. I believe my eventual solution is quite elegant, but it was
won at the expense of some false starts.


> Of course, it might make more sense to just wait for you to release
> the port, but this puts us on hold for an uncertain amount of time, as
> you don't make a clear statement of when the release will be. So I
> think it would be great to start working with your port, as I guess
> it's pretty sure that even if I continue developing and get a working
> solution myself, it will be your port that ends up in the official
> ecos community repository. So my past and future work will be quite
> obsolete, despite the learning I did :(

The exact release date depends on whether any serious problems are
thrown up in testing and how quickly we can deal with the remaining
toolchain issues.

Everything you have learned so far will still be useful, so nothing
has been wasted :-)


-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071


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

Re: [ECOS] eCosCentric Cortex-M port contribution

[simon.kallweit]

Nick Garnett wrote:
>> Could you give us some more information about the issues? Also, are
>> there plans to get the patches into the mainline GCC?
>>     
>
> Unfortunately the details are covered by various NDAs between us,
> CodeSourcery and ARM. Once the problem is confirmed by ARM then I
> expect CodeSourcery will update their release, and this will find its
> way into the FSF sources at some point. In the meantime we are looking
> at making a temporary fix for the toolchain that will go out with
> 3.0. Although we will pre-release it when the Cortex-M contribution is
> made.
>   

Ok, I guess the issues you're talking about are not related to the 
silicon errata just release by STMicroelectronics, concerning some 
compilers generating incompatible code with all but the latest revisions 
of the STM32 processors?

>>> All of this is in hand but not quite yet ready for contribution: the
>>> toolchain work needs completing, and we want to get a few runs in on
>>> the test farm to ensure there are no obvious problems before
>>> contributing.
>>>
>>> I expect this to take a couple of weeks more.
>>>
>>>       
>> Now, that puts me in quite an akward situation, as I've been working
>> on a community cortex-m3 port for almost a month now. I wonder if it
>> is best to stop my efforts and wait for your contribution. As we just
>> got the first prototypes of our new STM32 based design a few days ago,
>> we really look forward to get ecos working on the boards, so I cannot
>> really just sit here and wait for your release. Is there a possibility
>> to get the current snapshot upfront so I can continue with development
>> based on your port, and see if there is anything worth to be
>> contributed from the community port? I'd rather put further efforts
>> into your port, if it is the better base for the future.
>>     
>
> We don't want to give free public early access at present. There are
> still a number of thing that need completing before we are ready for
> the world to see it.
>
> You should probably wait. I know that you have just started looking at
> interrupts and context switching. My experience is that this is the
> hardest part of getting this architecture working. ARM's view of how
> operating systems should work is somewhat at odds with how eCos works
> and the harware rather strictly enforces ARM's world view. It is
> unlikely that you will get your port running before we make our
> contribution.
>   

It occurred to me, now that I have been digging into the subject more 
deeply, that there are some issues concerning the design of the 
Cortex-M3 to match with ecos. I think I do understand the design of how 
a kernel should work under the Cortex-M3 architecture, but admittedly I 
don't quite see yet how to do that efficiently with ecos. Does your 
solution come with changes in the generic ecos kernel code, or did you 
manage to solve it all in the Cortex-M3 HAL?

Of course, it might make more sense to just wait for you to release the 
port, but this puts us on hold for an uncertain amount of time, as you 
don't make a clear statement of when the release will be. So I think it 
would be great to start working with your port, as I guess it's pretty 
sure that even if I continue developing and get a working solution 
myself, it will be your port that ends up in the official ecos community 
repository. So my past and future work will be quite obsolete, despite 
the learning I did :(

Is there anything we can do about that? Otherwise, I think I'll continue 
with my development, risking to throw it all away a few weeks from now.

Best regards,
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

Re: [ECOS] eCosCentric Cortex-M port contribution

[Nick Garnett]

Simon Kallweit <simon.kallweit@intefo.ch> writes:

> Nick Garnett schrieb:
> > As some of you may know, eCosCentric have been working on a Cortex-M
> > port for eCos for a while. This has now reached a reasonably stable
> > state and is currently running through tests in our test farm.
> >
> 
> Can the test results be browsed by normal people, or is this still
> exclusive to ecos maintainers?

These results are only available inside eCosCentric.


> Are there plans to merge the flash V2 support into the trunk anytime
> soon? Or is this scheduled for the ecos 3 release?

Merging the V2 branch is part of the 3.0 release. In the meantime the
V2 flash interface can still be used from its own branch.


> Could you give us some more information about the issues? Also, are
> there plans to get the patches into the mainline GCC?

Unfortunately the details are covered by various NDAs between us,
CodeSourcery and ARM. Once the problem is confirmed by ARM then I
expect CodeSourcery will update their release, and this will find its
way into the FSF sources at some point. In the meantime we are looking
at making a temporary fix for the toolchain that will go out with
3.0. Although we will pre-release it when the Cortex-M contribution is
made.

 
> > All of this is in hand but not quite yet ready for contribution: the
> > toolchain work needs completing, and we want to get a few runs in on
> > the test farm to ensure there are no obvious problems before
> > contributing.
> >
> > I expect this to take a couple of weeks more.
> >
> 
> Now, that puts me in quite an akward situation, as I've been working
> on a community cortex-m3 port for almost a month now. I wonder if it
> is best to stop my efforts and wait for your contribution. As we just
> got the first prototypes of our new STM32 based design a few days ago,
> we really look forward to get ecos working on the boards, so I cannot
> really just sit here and wait for your release. Is there a possibility
> to get the current snapshot upfront so I can continue with development
> based on your port, and see if there is anything worth to be
> contributed from the community port? I'd rather put further efforts
> into your port, if it is the better base for the future.

We don't want to give free public early access at present. There are
still a number of thing that need completing before we are ready for
the world to see it.

You should probably wait. I know that you have just started looking at
interrupts and context switching. My experience is that this is the
hardest part of getting this architecture working. ARM's view of how
operating systems should work is somewhat at odds with how eCos works
and the harware rather strictly enforces ARM's world view. It is
unlikely that you will get your port running before we make our
contribution.

-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071


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

Re: [ECOS] eCosCentric Cortex-M port contribution

[Simon Kallweit]

Nick Garnett schrieb:
> As some of you may know, eCosCentric have been working on a Cortex-M
> port for eCos for a while. This has now reached a reasonably stable
> state and is currently running through tests in our test farm.
>   

Can the test results be browsed by normal people, or is this still 
exclusive to ecos maintainers?

> We have decided to contribute the basic packages to anoncvs.  This
> will provide a working Cortex-M base on which the community can
> further develop their own custom hardware ports.
>   

Sounds great!

> The packages I intend to contribute are as follows:
>
> Architecture HAL
> STM32 Variant HAL
> STM3210E-EVAL Platform HAL
> USART serial driver
> On-Chip FLASH driver (V2 flash interface)
>   

Are there plans to merge the flash V2 support into the trunk anytime 
soon? Or is this scheduled for the ecos 3 release?

> In addition there are a number of toolchain issues that need to be
> addressed. I discovered a potential problem the M3 implementation
> which needs a compiler modification (ARM are currently still
> evaluating the issue). GDB has some problems correctly supporting the
> different layout of the CPSR register in the M processors. There are
> also some GCC multilib issues that need sorting out.
>
> The result of this is that we will release a specially patched version
> of the ARM toolchain to go with the contribution.
>   

Could you give us some more information about the issues? Also, are 
there plans to get the patches into the mainline GCC?

> All of this is in hand but not quite yet ready for contribution: the
> toolchain work needs completing, and we want to get a few runs in on
> the test farm to ensure there are no obvious problems before
> contributing.
>
> I expect this to take a couple of weeks more.
>   

Now, that puts me in quite an akward situation, as I've been working on 
a community cortex-m3 port for almost a month now. I wonder if it is 
best to stop my efforts and wait for your contribution. As we just got 
the first prototypes of our new STM32 based design a few days ago, we 
really look forward to get ecos working on the boards, so I cannot 
really just sit here and wait for your release. Is there a possibility 
to get the current snapshot upfront so I can continue with development 
based on your port, and see if there is anything worth to be contributed 
from the community port? I'd rather put further efforts into your port, 
if it is the better base for the future.

Best regards,
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

[ECOS] eCosCentric Cortex-M port contribution

[Nick Garnett]

As some of you may know, eCosCentric have been working on a Cortex-M
port for eCos for a while. This has now reached a reasonably stable
state and is currently running through tests in our test farm.

We have decided to contribute the basic packages to anoncvs.  This
will provide a working Cortex-M base on which the community can
further develop their own custom hardware ports.

The packages I intend to contribute are as follows:

Architecture HAL
STM32 Variant HAL
STM3210E-EVAL Platform HAL
USART serial driver
On-Chip FLASH driver (V2 flash interface)

In addition there are a number of toolchain issues that need to be
addressed. I discovered a potential problem the M3 implementation
which needs a compiler modification (ARM are currently still
evaluating the issue). GDB has some problems correctly supporting the
different layout of the CPSR register in the M processors. There are
also some GCC multilib issues that need sorting out.

The result of this is that we will release a specially patched version
of the ARM toolchain to go with the contribution.

All of this is in hand but not quite yet ready for contribution: the
toolchain work needs completing, and we want to get a few runs in on
the test farm to ensure there are no obvious problems before
contributing.

I expect this to take a couple of weeks more.




-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071


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