[ECOS] Cortex-M3 port

[ECOS] Cortex-M3 port

[simon.kallweit]

Hi there

I just wanted to let you know, that my Cortex-M3 port is pretty much up 
and running. It's not yet perfect, and there is still pending work on 
some parts (mostly the GDB stub, and exception handling). Basic 
interrupt handling and context switching is working. I extended the 
qmtest framework to automate kernel testing, and run all kernel tests 
with success (except the tm_basic test, which failed because of lack of 
resources). As ecoscentric is also finishing their port ("in a couple of 
weeks") I guess there is no real chance for my port to be included in 
the main repository. Also, to really finish the port, some additional 
help would really be appreciated (GDB stub etc.). My current focus is to 
test additional components we're going to use for our design (flash, fs, 
networking etc). So unless there is some help on the port, I guess I'll 
go with what I have and hope that ecoscentric will release their port in 
the near future, so I can incorporate additional changes into their port 
and the official repository. During development a few questions popped 
to my mind:

* Is there any interest in getting some community driven automatic 
testing infrastructure up and running? The current state is ok for doing 
single tests from time to time, but not to have an automated process. 
I'll further work with qmtest to automate our internal testing, but I 
wonder if there is interest to do this development in the community?

* I'm currently trying to merge the flash_v2 branch into the trunk. This 
seems to be not exactly trivial (or I'm just stupid :) Isn't it time to 
do the merge into the official trunk and spare the hassle in the future? 
Is there anything going against the merge? Or why hasn't it be done yet?

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] Cortex-M3 port

[Andrew Lunn]

> * I'm currently trying to merge the flash_v2 branch into the trunk. This  
> seems to be not exactly trivial (or I'm just stupid :) Isn't it time to  
> do the merge into the official trunk and spare the hassle in the future?  
> Is there anything going against the merge? Or why hasn't it be done yet?

This is a goal for the next release of eCos.

I also know some people in the community do have such a merged
tree. So maybe somebody can send you there work.

      Andrew

-- 
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] Cortex-M3 port

[simon.kallweit]

Andrew Lunn wrote:
>> * I'm currently trying to merge the flash_v2 branch into the trunk. This  
>> seems to be not exactly trivial (or I'm just stupid :) Isn't it time to  
>> do the merge into the official trunk and spare the hassle in the future?  
>> Is there anything going against the merge? Or why hasn't it be done yet?
>>     
>
> This is a goal for the next release of eCos.
>
> I also know some people in the community do have such a merged
> tree. So maybe somebody can send you there work.
>   

Well, I'm in the process of doing it myself right now, and things are 
shaping up. Anyway, I'm more and more getting away from using the ecos 
CVS and using my own repository, which is a bad thing in my opinion, and 
a sign that the current state of the CVS is not very well. I'll be glad 
to help out when the community wants to do the merge, moving forward to 
a new release, but as I'm not a maintainer myself I'll don't have the 
authority to initiate anything myself I guess. We should also consider 
to move away from CVS for a future release, but that's a whole other story.

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] Cortex-M3 port

[Christian Meusel]

[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]

Hello Simon,

> * Is there any interest in getting some community driven automatic 
> testing infrastructure up and running? The current state is ok for doing 
> single tests from time to time, but not to have an automated process. 
> I'll further work with qmtest to automate our internal testing, but I 
> wonder if there is interest to do this development in the community?

I'm currently working on a port of eCos to a ColdFire MCF5282 and 
started running first tests. Running tests from the configtool or 
manually does not provide me the comfort im used to when doing unit testing.

I have no experience with QMTest but having a framework which allows me 
to run a bunch of tests automatically on a target would be great. 
Especially when it allows to integrate tools for asserting hardware 
resets to the target.


Best regards,

Christian


-- 
Christian Meusel
TU Dresden
Fakultät für Informatik
Professur Mikrorechner

Internet: www.mr.inf.tu-dresden.de
Telefon: +49 351 463-37902
Telefax: +49 351 463-38245


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3367 bytes --]

Re: [ECOS] Cortex-M3 port

[simon.kallweit]

Christian Meusel wrote:
> Hello Simon,
>
>> * Is there any interest in getting some community driven automatic 
>> testing infrastructure up and running? The current state is ok for 
>> doing single tests from time to time, but not to have an automated 
>> process. I'll further work with qmtest to automate our internal 
>> testing, but I wonder if there is interest to do this development in 
>> the community?
>
> I'm currently working on a port of eCos to a ColdFire MCF5282 and 
> started running first tests. Running tests from the configtool or 
> manually does not provide me the comfort im used to when doing unit 
> testing.
>
> I have no experience with QMTest but having a framework which allows 
> me to run a bunch of tests automatically on a target would be great. 
> Especially when it allows to integrate tools for asserting hardware 
> resets to the target.

If you are interested, check out the my SVN repo at

https://svn.inthemill.ch/ecos-cortex/trunk

There is a scripts/qmtest folder which contains the qmtest class I 
wrote. This is just a proof-of-concept right now, nothing really 
serious. What it does is basically using OpenOCD/Telnet to flash a test 
binary, open a serial console for logging, doing a reset, and letting 
the test run, collecting it's output. The output is then parsed (using 
the semantics defined for ecos tests) and a test result is generated. 
This is all very targeted towards my needs right now, but it could be 
divided up into smaller components using qmtest. We could for example 
abstract the actual running of the test from the parsing of the test's 
output. This way we could run tests using the GDB support in redboot, 
using JTAGs, using a simulator or whatever. The nice thing about qmtest 
is that you get a good tool for organizing your tests, 
starting/controlling batch runs, and examining the results. This can be 
all done either using CLI or a simple embedded webserver.

Let me know what you think about it.

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] Cortex-M3 port

[Chris Zimman]

> We should also consider to move away from CVS for a future release, but
that's a whole other story.

Anyone want to have the discussion about migrating to a newer source control
system (maybe for 3.0?)
I can't even really use CVS at work because we are behind a proxy firewall
that doesn't allow it through.

--Chris

--
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] Re: Cortex-M3 port

[Grant Edwards]

On 2008-10-28, Chris Zimman <czimman@bloomberg.com> wrote:
>> We should also consider to move away from CVS for a future release, but
> that's a whole other story.
>
> Anyone want to have the discussion about migrating to a newer source control
> system (maybe for 3.0?)
> I can't even really use CVS at work because we are behind a proxy firewall
> that doesn't allow it through.

Here's an interesting web page: https://vpnout.com/

Not that _I'd_ oficially condone using something like that to
get around the roadblocks to getting work done that have been
set up by your local Mordac.

[Not that I'm in a position to officially condone anything anyhow.]

-- 
Grant Edwards                   grante             Yow! RHAPSODY in Glue!
                                  at               
                               visi.com            


-- 
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] Migrating away from CVS

[Chris Zimman]

> Here's an interesting web page: https://vpnout.com/
> 
> Not that _I'd_ oficially condone using something like that to
> get around the roadblocks to getting work done that have been
> set up by your local Mordac.

Yeah, I know how to get around it, but I would rather have something that
worked with it.  CVS is just outdated in the networking department as well.
Both GIT and SVN work fine over HTTP/HTTPS.

--Chris

--
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] Re: Migrating away from CVS

[Grant Edwards]

On 2008-10-28, Chris Zimman <czimman@bloomberg.com> wrote:
>
>> Here's an interesting web page: https://vpnout.com/
>> 
>> Not that _I'd_ oficially condone using something like that to
>> get around the roadblocks to getting work done that have been
>> set up by your local Mordac.
>
> Yeah, I know how to get around it, but I would rather have
> something that worked with it.  CVS is just outdated in the
> networking department as well. Both GIT and SVN work fine over
> HTTP/HTTPS.

True.  

It's a bit OT, but there's one thing I've been wondering about
should eCos switch over to SVN.  Since we use SVN locally for
our eCos source tree, is there any way to simultaneusly use SVN
with the "main" repository and with a local repository?

Right now we can configure svn to ignore the cvs stuff and cvs
to ignore the svn stuff.  Then we can have a source tree that's
both a working copy of our local SVN repository and a working
copy of the main CVS repository.  Obviously the diffs with
respect to the two repository aren't always the same, but
they're still useful.

Does either GIT or SVN provide a way to work with two
repositories?

-- 
Grant


-- 
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] Re: Migrating away from CVS

[simon.kallweit]

Grant Edwards wrote:
> On 2008-10-28, Chris Zimman <czimman@bloomberg.com> wrote:
>   
>>> Here's an interesting web page: https://vpnout.com/
>>>
>>> Not that _I'd_ oficially condone using something like that to
>>> get around the roadblocks to getting work done that have been
>>> set up by your local Mordac.
>>>       

I think we should get this right at the root, not curing the symptoms :)

>> Yeah, I know how to get around it, but I would rather have
>> something that worked with it.  CVS is just outdated in the
>> networking department as well. Both GIT and SVN work fine over
>> HTTP/HTTPS.
>>     
>
>   

I guess the big question here is if we want to move from a centralized 
to a de-centralized VCS. For centralized VCS the logical step would 
probably be to just switch to SVN, which is the "official" successor to 
CVS and I guess most people use already (and makes our lives a bit 
easier compared to CVS). My personal vote would have to be for a 
de-centralized VCS, which made the life of developers as well as 
maintainers a lot easier. Working on patches and new features is a blast 
with clean support for local branches. Patch submission and reviewing 
process can be made a lot easier as well. I would currently consider GIT 
and Mercurial. Mercurial being the favorite for it's better support on 
other platforms than Linux. I currently maintain my local ecos 
repository using Mercurial, just to have a snappier VCS at my hands 
which works really well with bigger code bases.

> True.  
>
> It's a bit OT, but there's one thing I've been wondering about
> should eCos switch over to SVN.  Since we use SVN locally for
> our eCos source tree, is there any way to simultaneusly use SVN
> with the "main" repository and with a local repository?
>   

As long as the don't overlap there is no problem, but that's probably 
exactly what you want to do. I recently discovered ecos's feature of 
multiple repositories, and I think it's a superb solution to this exact 
problem. You just put your "private" ecos repository in front of the 
official one, to do little changes, add new features etc. The only real 
problem right now is the missing support of the graphical configtool. My 
current workaround is to use a little script, merging the different 
repositories using a union filesystem. This is pretty easy on Linux, may 
be a bit more problematic on Windows though. Anyway, work should 
probably go into adding support for multiple repos in the configtool. 
Andy Jackson did some work on this, might be possible to go from there!?

Just my 2 cents ...

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] Re: Migrating away from CVS

[Ilija Kocho]

Grant Edwards wrote:
> On 2008-10-28, Chris Zimman <czimman@bloomberg.com> wrote:
>   
>>> Here's an interesting web page: https://vpnout.com/
>>>
>>> Not that _I'd_ oficially condone using something like that to
>>> get around the roadblocks to getting work done that have been
>>> set up by your local Mordac.
>>>       
>> Yeah, I know how to get around it, but I would rather have
>> something that worked with it.  CVS is just outdated in the
>> networking department as well. Both GIT and SVN work fine over
>> HTTP/HTTPS.
>>     
>
> True.  
>
> It's a bit OT, but there's one thing I've been wondering about
> should eCos switch over to SVN.  Since we use SVN locally for
> our eCos source tree, is there any way to simultaneusly use SVN
> with the "main" repository and with a local repository?
>
> Right now we can configure svn to ignore the cvs stuff and cvs
> to ignore the svn stuff.  Then we can have a source tree that's
> both a working copy of our local SVN repository and a working
> copy of the main CVS repository.  Obviously the diffs with
> respect to the two repository aren't always the same, but
> they're still useful.
>
> Does either GIT or SVN provide a way to work with two
> repositories?
>   
I'm not a VCS wizard (know just enough to basically run our SVN) so
please regard following comment as both hint and question.
Doesn't distributed repository provide a solution this problem?
Can we consider that with VCS everyone effectively has an own repository
that is/(can be) synchronized with "official" repository?

Regards
Ilija

-- 
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] Re: Migrating away from CVS

[Grant Edwards]

On 2008-10-29, simon.kallweit@intefo.ch <simon.kallweit@intefo.ch> wrote:

>>>> Here's an interesting web page: https://vpnout.com/
>>>>
>>>> Not that _I'd_ oficially condone using something like that to
>>>> get around the roadblocks to getting work done that have been
>>>> set up by your local Mordac.
>>>>       
>
> I think we should get this right at the root, not curing the
> symptoms :)

At many places I've been, that's simply not possible. :/


>> It's a bit OT, but there's one thing I've been wondering about
>> should eCos switch over to SVN.  Since we use SVN locally for
>> our eCos source tree, is there any way to simultaneusly use
>> SVN with the "main" repository and with a local repository?
>
> As long as the don't overlap there is no problem, but that's
> probably exactly what you want to do.

I think so.  What I want to do is to check out a CVS working
copy from sourceware.org and import that into my local SVN
server (with CVS info).  Now when I check out a working copy
from SVN, it's also a CVS working copy.  I can make changes and
diff against both my local SVN repository and against the CVS
repository.  I can update from the CVS repository and commit the
the canges to SVN.  I can keep track of both the history of
local revisions and the difference to the CVS repository.

> I recently discovered ecos's feature of multiple repositories,
> and I think it's a superb solution to this exact problem. You
> just put your "private" ecos repository in front of the 
> official one, to do little changes, add new features etc.

That's another way to deal with it (I'm trying to get my group
to switch to dual repostories, since we have many local pacages
that aren't in the eCos CVS repository). Every time you need to
modify a file in the eCos source tree, you have to copy the
package containing the file from the "standard" eCos repository
to the "local" one.  After local changes have been merged back
into the eCos CVS repository, then you remove the package from
the local repository.

As long as you're religious about only modifying packages after
they've been moved to the local repository, it works pretty
well.

> The only real problem right now is the missing support of the
> graphical configtool.

Nobody I know cares about the configtool.  Does anybody who's
working on a real eCos project (e.g. not something for school
or evaluation purposes) use the graphical tool?

> My current workaround is to use a little script, merging the
> different repositories using a union filesystem. This is
> pretty easy on Linux, may be a bit more problematic on Windows
> though. Anyway, work should probably go into adding support
> for multiple repos in the configtool.  Andy Jackson did some
> work on this, might be possible to go from there!?

-- 
Grant Edwards                   grante             Yow! I'm sitting on my
                                  at               SPEED QUEEN ... To me,
                               visi.com            it's ENJOYABLE ... I'm WARM
                                                   ... I'm VIBRATORY ...


-- 
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] Re: Migrating away from CVS

[Alexander Neundorf]

On Wednesday 29 October 2008, Grant Edwards wrote:
> On 2008-10-29, simon.kallweit@intefo.ch <simon.kallweit@intefo.ch> wrote:
...
> > The only real problem right now is the missing support of the
> > graphical configtool.
>
> Nobody I know cares about the configtool.  Does anybody who's
> working on a real eCos project (e.g. not something for school
> or evaluation purposes) use the graphical tool?

Yes, I do.

Alex

-- 
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] Re: Migrating away from CVS

[Frank Pagliughi]

Alexander Neundorf wrote:
> On Wednesday 29 October 2008, Grant Edwards wrote:
>   
>> On 2008-10-29, simon.kallweit@intefo.ch <simon.kallweit@intefo.ch> wrote:
>>     
> ...
>   
>>> The only real problem right now is the missing support of the
>>> graphical configtool.
>>>       
>> Nobody I know cares about the configtool.  Does anybody who's
>> working on a real eCos project (e.g. not something for school
>> or evaluation purposes) use the graphical tool?
>>     
>
> Yes, I do.
>
> Alex
>
>   
I do, too.

Frank

-- 
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] Re: Migrating away from CVS

[Andy Jackson]

Frank Pagliughi wrote:
> Alexander Neundorf wrote:
>> On Wednesday 29 October 2008, Grant Edwards wrote:
>>  
>>> On 2008-10-29, simon.kallweit@intefo.ch <simon.kallweit@intefo.ch> 
>>> wrote:
>>>     
>> ...
>>  
>>>> The only real problem right now is the missing support of the
>>>> graphical configtool.
>>>>       
>>> Nobody I know cares about the configtool.  Does anybody who's
>>> working on a real eCos project (e.g. not something for school
>>> or evaluation purposes) use the graphical tool?
>>>     
>>
>> Yes, I do.
>>
>> Alex
>>
>>   
> I do, too.
>
> Frank
>
Me too and the whole lets knock ConfigTool because its not used by 'real 
programmers' is getting really tired

Andy

-- 
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] Re: Migrating away from CVS

[Grant Edwards]

On 2008-11-04, Andy Jackson <andy@xylanta.com> wrote:

>>>> Nobody I know cares about the configtool.  Does anybody who's
>>>> working on a real eCos project (e.g. not something for school
>>>> or evaluation purposes) use the graphical tool?
>>>>     
>>>
>>> Yes, I do.
>>>   
>> I do, too.
>
> Me too and the whole lets knock ConfigTool because its not
> used by 'real programmers' is getting really tired

I wasn't knocking it.  I was just wondering if anybody used it.
My impression was that it never really worked well and had
mostly been abandoned because nobody stepped up to maintain it.
One implication of that would be that there just weren't really
any users left.

-- 
Grant


-- 
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] Re: Migrating away from CVS

[Daniel Helgason]

On Wed, 2008-10-29 at 13:49 +0000, Grant Edwards wrote:
> Nobody I know cares about the configtool.  Does anybody who's
> working on a real eCos project (e.g. not something for school
> or evaluation purposes) use the graphical tool?

We do. In fact, we've only used the command-line tool for scripted
building, not configuration.

We put a lot of CPU and SOC configuration items in CDL packages. We find
some of the complex items have dependencies and interactions that are
difficult to discover and manage unless the data is presented in a
visual, hierarchical manner the way the configtool does.

PS. Kudos to John Dallaway and his work on the configtool experimental
build for GTK+ 2.x on Linux. It looks great!

-- 
+---------------------------------------------
| Daniel Helgason <dhelgason@shaw.ca>


-- 
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] Re: Migrating away from CVS

[simon.kallweit]

Daniel Helgason wrote:
> On Wed, 2008-10-29 at 13:49 +0000, Grant Edwards wrote:
>   
>> Nobody I know cares about the configtool.  Does anybody who's
>> working on a real eCos project (e.g. not something for school
>> or evaluation purposes) use the graphical tool?
>>     
>
> We do. In fact, we've only used the command-line tool for scripted
> building, not configuration.
>   

I do it in the exact same way.

> We put a lot of CPU and SOC configuration items in CDL packages. We find
> some of the complex items have dependencies and interactions that are
> difficult to discover and manage unless the data is presented in a
> visual, hierarchical manner the way the configtool does.
>   

Using the configtool for "exploration" is quite nice, I use it all the 
time. It might be that when I will have some years of experience using 
eCos, I will have most of that memorized and will not use it as much as 
I do now.

> PS. Kudos to John Dallaway and his work on the configtool experimental
> build for GTK+ 2.x on Linux. It looks great!
>   

About multiple repositories. The way I currently do it, is using a 
little wrapper shell script, which "merges" the different repositories 
into one (using fusionfs) and then acts on this merged repository. This 
is quite a hack, but it works, and let's me use the configtool with 
multiple repos. Clean support in the configtool would still be great I 
guess, but I haven't had a look at how much work it is.

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] Cortex-M3 port

[Alexander BORODULIN]

Dear Sirs,

ones are asking if any eCos port for ARM Cortex-M3 CPU (STM32) will be available and when. Could you please let us know?

Thank you very much in advance.

Best regards,
Alexander Borodulin


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