[Bug 1000761] eCos support for MPC5xxx MCUs

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761


John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |john@dallaway.org.uk
         Extra Info|---                         |REQUESTED
          Component|HAL                         |Patches and contributions




--- Comment #3 from John Dallaway <john@dallaway.org.uk>  2009-05-12 17:28:44 ---
At first glance, the contribution provides a new "PowerPC e200" architectural
HAL which is used as the basis for all the contributed platforms. There are
variant HALs for MPC55xx, MPC5568 and MP551x. There are also CAN, ethernet, SPI
and serial drivers relating to the supported targets.

Jochen, can you explain why you chose to support this range of processors using
a new architectural HAL package rather than using the existing PowerPC
architectural HAL package and providing a variant HAL package for MPC5xxx?

Note to the eCos maintainers: the copyright headers will need updating


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761





--- Comment #4 from Jochen Gerster <Jochen.Gerster@freescale.com>  2009-05-12 23:10:55 ---
(In reply to comment #3)
> At first glance, the contribution provides a new "PowerPC e200" architectural
> HAL which is used as the basis for all the contributed platforms. There are
> variant HALs for MPC55xx, MPC5568 and MP551x. There are also CAN, ethernet, SPI
> and serial drivers relating to the supported targets.
> 
> Jochen, can you explain why you chose to support this range of processors using
> a new architectural HAL package rather than using the existing PowerPC
> architectural HAL package and providing a variant HAL package for MPC5xxx?
> 
> Note to the eCos maintainers: the copyright headers will need updating
> 

Well, the main reason is the e200 core needs major adjustments on arch level.
So to keep it simple, I created a new branch out of the original powerpc arch
folder --> e200 folder and worked with that.

John, Do you want to merge them again?


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761





--- Comment #5 from John Dallaway <john@dallaway.org.uk>  2009-05-14 09:17:39 ---
Created an attachment (id=718)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=718)
freescale-ppc-arch.diff

This file illustrates the differences between the standard eCos PowerPC
architectural HAL and the e200 architectural HAL contribution. Copyright header
changes have been removed for clarity.


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761


Stefan Singer <Stefan.Singer@freescale.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Stefan.Singer@freescale.com




--- Comment #6 from Stefan Singer <Stefan.Singer@freescale.com>  2009-05-21 13:31:42 ---
(In reply to comment #5)
> Created an attachment (id=718)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=718) [details]
> freescale-ppc-arch.diff
> This file illustrates the differences between the standard eCos PowerPC
> architectural HAL and the e200 architectural HAL contribution. Copyright header
> changes have been removed for clarity.

Hi John,
will this be integrated into the main CVS source tree and can we create an
announcement at the main eCOS website, that those architectures are supported
now ?


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761


John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nickg@ecoscentric.com




--- Comment #7 from John Dallaway <john@dallaway.org.uk>  2009-05-21 15:24:46 ---
Stefan, apologies for the delay in getting back to you on this matter.

Firstly, I must thank you and Jochen for your substantial contribution to the
eCos project which is much appreciated.

We do have some issues to work through with you:

The eCos maintainers are in agreement that your implementation of support for
e200 cores in the form of a new eCos architectural HAL is not really in keeping
with the intended layering of eCos hardware support. Your e200 HAL package
necessarily includes a lot of code copied from the standard PowerPC
architectural HAL and we would wish to see any architecture-level support for
e200 integrated into the standard PowerPC architectural HAL directly to avoid
code duplication.

In order to provide the right foundation for future PowerPC variant support,
eCosCentric will be contributing a patch for the standard eCos PowerPC
architectural HAL which adds architecture-level support for Book-E processors
in general (including e200). I would expect this contribution to be checked-in
to our public CVS repository in the next few days.

Would you be able to migrate your MPC5xxx contribution to use the updated
PowerPC architectural HAL? I am advised that the changes required to your own
contribution should be minor and the resulting contribution would then be much
more beneficial for the future of eCos on PowerPC. Of course, you may wish to
wait for, and review, the updated PowerPC architectural HAL before responding
to this question.

Thanks, again, for supporting eCos.


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761





--- Comment #8 from Stefan Singer <Stefan.Singer@freescale.com>  2009-05-22 13:29:14 ---
(In reply to comment #7)
> Stefan, apologies for the delay in getting back to you on this matter.
> Firstly, I must thank you and Jochen for your substantial contribution to the
> eCos project which is much appreciated.
> We do have some issues to work through with you:
> The eCos maintainers are in agreement that your implementation of support for
> e200 cores in the form of a new eCos architectural HAL is not really in keeping
> with the intended layering of eCos hardware support. Your e200 HAL package
> necessarily includes a lot of code copied from the standard PowerPC
> architectural HAL and we would wish to see any architecture-level support for
> e200 integrated into the standard PowerPC architectural HAL directly to avoid
> code duplication.
> In order to provide the right foundation for future PowerPC variant support,
> eCosCentric will be contributing a patch for the standard eCos PowerPC
> architectural HAL which adds architecture-level support for Book-E processors
> in general (including e200). I would expect this contribution to be checked-in
> to our public CVS repository in the next few days.
> Would you be able to migrate your MPC5xxx contribution to use the updated
> PowerPC architectural HAL? I am advised that the changes required to your own
> contribution should be minor and the resulting contribution would then be much
> more beneficial for the future of eCos on PowerPC. Of course, you may wish to
> wait for, and review, the updated PowerPC architectural HAL before responding
> to this question.
> Thanks, again, for supporting eCos.

Hi John,
both Jochen and myself will be out next week. As soon as the new PowerPC HAL
will be out we will check, how much problems this will create. We are
definitely interested to get this contribution back into the main source tree,
so that is stays maintained and is available for customers of our architecture.


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761





--- Comment #9 from John Dallaway <john@dallaway.org.uk>  2009-06-02 10:55:38 ---
Nick, when do you anticipate being able to check-in the updated PowerPC
architectural HAL with Book-E support? Just looking to keep the ball rolling...


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Issue 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761





--- Comment #11 from Nick Garnett <nickg@ecoscentric.com>  2009-06-08 16:46:36 ---
Created an attachment (id=754)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=754)
Book E support for PowerPC architecture 

(In reply to comment #9)
> Nick, when do you anticipate being able to check-in the updated PowerPC
> architectural HAL with Book-E support? Just looking to keep the ball rolling...

I had rather put this on the back burner while the NAND contribution fuss was
going on. However, I see no real reason to postpone it any further. The patch
is attached and I have checked it all into the repository.


-- 
Configure issuemail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the issue.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761





--- Comment #12 from John Dallaway <john@dallaway.org.uk>  2009-06-08 20:09:58 ---
(In reply to comment #8)

> > Would you be able to migrate your MPC5xxx contribution to use the updated
> > PowerPC architectural HAL? I am advised that the changes required to your own
> > contribution should be minor and the resulting contribution would then be much
> > more beneficial for the future of eCos on PowerPC. Of course, you may wish to
> > wait for, and review, the updated PowerPC architectural HAL before responding
> > to this question.
> 
> both Jochen and myself will be out next week. As soon as the new PowerPC HAL
> will be out we will check, how much problems this will create. We are
> definitely interested to get this contribution back into the main source tree,
> so that is stays maintained and is available for customers of our architecture.

Hi Stefan

The updated PowerPC architectural HAL package with Book-E support is now
checked in. To update your local CVS tree:

   cd packages/hal/powerpc/arch
   cvs -q up -d -P

Please let me know whether you are able to migrate your MPC5xxx contribution to
use the updated PowerPC architectural HAL rather than your own e200 HAL
package.

John Dallaway


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761





--- Comment #13 from Jochen Gerster <Jochen.Gerster@freescale.com>  2009-07-06 21:52:20 ---
(In reply to comment #7)
> Would you be able to migrate your MPC5xxx contribution to use the updated
> PowerPC architectural HAL?

So concerning the migration to the updated PowerPC arch HAL we discovered two
major changes we like to discuss with you first...
a)We were able to switch to it for all e200z6 ports but there are some
constraints to do this also vor the mpc5510 (=e200z1) as here the core
exception handling has some difference compared to the higher e200 cores.
In detail, the e200z1 core only provides a IVOR base SPR and no further IVORx
offset SPRs. The offset between the exception vectors are fixed to 16bytes.
So the current BookE exception vector declaration in vector.s as to be changed.
We think the best solution is to have BookE exception vectors completely
independent from the old powerpc exception vectors. In the current
implementation BookE only enhance the existing exception vectors declaration.
Further should this booke exception handling support all e200 cores, means if
we make it work for e200z1 then it can also be used for all other e200 cores.

b)Further didn't we understand the usage of the ...NEED_VECTORS and
...COPY_VECTORS Macros in arch.inc hal_vectors_init for booke.
As if ....NEED_VECTORS isn't configured still the IVOR base SPR is written but
not the offsets, for us this didn't make sense as if I install exceptions I
completely do this and not partly?
We suggest to remove #if ...COPY_VECTORS and #if ...NEED_VECTORS in arch.inc
for booke, and instead differ only e200z1 and e200z_higher. Means for e200z1
only IVOR base SPR have to be written, and for all e200z_higher also the IVORx
offsets have to be written. But we would use therefore a different
configuration macro and not ...NEEDE_VECTORS

We appreciate your feedback...

best regards,
Jochen


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761


John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|jifl@ecoscentric.com        |nickg@ecoscentric.com
         Extra Info|REQUESTED                   |---




--- Comment #14 from John Dallaway <john@dallaway.org.uk>  2009-07-07 07:47:00 ---
Jochen, I'm assigning this to Nick Garnett directly. I'm sure Nick can answer
your questions.


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761


Stefan Singer <Stefan.Singer@freescale.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #715 is|0                           |1
           obsolete|                            |




--- Comment #15 from Stefan Singer <Stefan.Singer@freescale.com>  2009-07-20 21:17:30 ---
Created an attachment (id=763)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=763)
patch to PowerPC Architecture


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761





--- Comment #16 from Stefan Singer <Stefan.Singer@freescale.com>  2009-07-20 21:47:37 ---
Hi,
we have now reintegrated our port with the new PowerPC arch. We have also
merged everything back into one Variant MPC5xxx. However we do require some
changes to the PowerPC main architecture. Those are mandatory for our
contribution. In detail the following things:

- cache Macro: The current arch uses a Macro HAL_UCACHE_ENABLE to differentiate
between CPUs with unified cache versus Harvard. In all other Architectures
thise is actually a macro for a function call. Since many of our devices use
the e200z6 core, which does actually have a unified cache, I have renamed that
original Macro to HAL_CACHE_IS_UCACHE and use the other Macro as in the other
architectures

- default setting for PowerPC Book E - since all devices of the MPC5xxx variant
are Book E I would like to set this for all devices of that variant

- Exception tables: Several of our supported devices use the e200z1, which has
a reduced set of exception registors (IVOR Registers are missing). I build that
into the arch.

Please integrate those patches, so that we can contribute the rest of the
files.

Best regards
Stefan


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761





--- Comment #17 from John Dallaway <john@dallaway.org.uk>  2009-07-22 15:13:41 ---
Stefan, many thanks for the PowerPC architectural patch. Nick Garnett will
review this when he has a spare moment.

We are looking forward to getting the MPC55xx support fully integrated in due
course.

John Dallaway


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

Dave Peterson <dpeter@woodward.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dpeter@woodward.com

--- Comment #27 from Dave Peterson <dpeter@woodward.com> 2010-09-14 16:38:59 BST ---
How do I find out the status of the MPC55xx support for eCos?
I have been waiting for this to be added to the release, but I don't know how
to find out the timeframe.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #28 from Stefan Singer <Stefan.Singer@freescale.com> 2010-09-26 13:02:35 BST ---
Hi, the port is complete for all current MPC55xx and MPC56xx devices, that
support classic PowerPC coding. There is currently no official VLE support,
since GCC for VLE will only be available next year (2011). This means, that all
MPC560xB/C/E/P/S devices are not supported. We are currently working on the
enhancements to support Redboot with load to Flash and execute from there,
since we originally did not really focus on Redboot, since typically the
devices of that MCU family have not enough RAM to load and execute from there.
Once this work is complete, I was intending to upload the package here again,
hoping that the maintainers would integrate it into the main tree. Last time my
contribution was ignored, so I am not sure, what I can do, if it is ignored
again. Currently I maintain it mainly for our internal purposes but I am more
than happy to give that code to anyone.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #29 from Dave Peterson <dpeter@woodward.com> 2010-09-28 18:14:36 BST ---
(In reply to comment #28)
> Hi, the port is complete for all current MPC55xx and MPC56xx devices, that
> support classic PowerPC coding. There is currently no official VLE support,
> since GCC for VLE will only be available next year (2011). This means, that all
> MPC560xB/C/E/P/S devices are not supported. We are currently working on the
> enhancements to support Redboot with load to Flash and execute from there,
> since we originally did not really focus on Redboot, since typically the
> devices of that MCU family have not enough RAM to load and execute from there.
> Once this work is complete, I was intending to upload the package here again,
> hoping that the maintainers would integrate it into the main tree. Last time my
> contribution was ignored, so I am not sure, what I can do, if it is ignored
> again. Currently I maintain it mainly for our internal purposes but I am more
> than happy to give that code to anyone.

Stefan,
Thanks for the update. Hopefully your work will soon be released.
Do you know if there has been a port for the MPC5200?
Dave

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #30 from Stefan Singer <Stefan.Singer@freescale.com> 2012-05-30 14:50:38 BST ---
Hi eCos Maintainers,
we have continued to develop that MPC5xxx branch of eCos and would like to come
back to contribute to the main tree. We are currently planing a distribution
launch of one of the MPC56xx MCUs, where we would like to see a contribution
announcement on the eCos website in the 1st week of July. How much time do you
need to integrate our contribution into the main CVS ? I am not talking about
modifications to the existing files, just entirely new files for the MPC5xxx
line of products ?

Best regards
Stefan

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jifl@ecoscentric.com
         AssignedTo|backlog@bugs.ecos.sourcewar |jifl@ecoscentric.com
                   |e.org                       |

--- Comment #31 from Jonathan Larmour <jifl@ecoscentric.com> 2012-05-31 13:54:43 BST ---
Hi Stefan,

(In reply to comment #30)
> Hi eCos Maintainers,
> we have continued to develop that MPC5xxx branch of eCos and would like to come
> back to contribute to the main tree. We are currently planing a distribution
> launch of one of the MPC56xx MCUs, where we would like to see a contribution
> announcement on the eCos website in the 1st week of July. How much time do you
> need to integrate our contribution into the main CVS ? I am not talking about
> modifications to the existing files, just entirely new files for the MPC5xxx
> line of products ?

We do want code to be maintainable, meet coding standards, and work correctly
not just with the default configuration of the most common packages, but with
all packages in all configurations (well, in theory - in practice, it's hard to
test this without an automated testing infrastructure, but we do try and get as
good as we can).

So with that in mind, it all depends on how much, if any, work would be
required for the ports to meet those basic standards. Since there have already
been comments, and you've been receptive to comments in the past, hopefully
there are not many issues remaining, but ultimately the only way to know is to
post your latest code.

If you can post the code, and we can get a good turnaround on review comments,
then 1st week of July should be achievable.

One little comment I can make just on the highest level structure which I don't
think anyone else has made is that the hal/powerpc/ layer is starting to get
crowded, and this contribution would add 18 more directories at that level. I
think a new hal/powerpc/mpc5xxx directory hierarchy is called for, with the
existing hal/powerpc/mpc5xxx directory in your contrib renamed to
hal/powerpc/mpc5xxx/var (in line with the precedent in other architectures).
The package contents should be able to stay exactly the same - I'm only talking
about moving the root of each package, and updating the ecos.db in line with
that.

Cheers,

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #32 from Jonathan Larmour <jifl@ecoscentric.com> 2012-05-31 14:54:24 BST ---
Actually, I can make a few more sweeping comments based on a scan of what's
there in the most recent version of the contribution posted:

The first one I should just reiterate is that the current copyright and licence
headers on some files not only don't fit the normal eCos template, but include
things like: Copyright (C) Freescale <year> All Rights Reserved. Most of these
do have a better licence, but not all do. For example, three instances of a
mpc5510.h do not.

All files have to be redistributed either under the normal eCos licence (GPL
plus an exception), or under a more liberal but compatible licence (such as BSD
without advertising clause, public domain, etc.).

"All Rights Reserved" means that there are no implicit rights to redistribute
or even use the code. We can never accept contributions with those terms,
although obviously I'm sure this is just an administrative oversight here.

Some of the licence headers do meet the requirements. Some of them look like
they do but actually are based on the old Red Hat copyright (look for mentions
of Red Hat, including in ChangeLog files). Some of them (e.g. var_cache.h) have
no header at all.

I'm not demanding fully accurate Purpose and Description fields filled in for
every file, but I would like to see it up to the same standard as other HALs,
with all files matching the full template (even if there are Freescale specific
bits immediately underneath the standard parts), and the names of files, and a
little one-line description just underneath, along with author and date. Author
can just be Freescale if you prefer, if relevant.

A lot of the spacing on code is a bit unusual - it appears a lot was created in
editors set to generate TABs, but with tab spacing set at 4 columns. TABs
always present a problem, and although some sneak in, we avoid them in general
(with the exception of ChangeLog files where they are a required part of the
syntax). I suggest either running a script over the files to fix these,
assuming consistent use, or you may wish to consider GNU indent.

For example I ran the following to make the code easier to follow for me:
cat > /tmp/blah.sh <<EOF
#!/bin/sh
for i in `find . -name ChangeLog -prune -o -type f -print` ; do  sed 's@    @  
 @g' $i > $i.jifl ; \mv $i.jifl $i ; done
EOF
(with a tab character inside the relevant part of the sed expression). Although
even that isn't perfect, for example I spotted the line continuation escapes
(the backslashes) in macros in var_cache.h are still all over the place.

That said, no contribution which complies with the GNU coding style will ever
be rejected, even though it does not match the traditional eCos coding style.
Unhelpfully the formal documentation of coding style was only ever written in a
document which was never made public by Cygnus/Red Hat, so we have to go by
existing practice! But it does mean that if you wanted to use GNU indent, that
might work. I can't say that will definitely be the fastest route to resolve
things though.

Not all packages have top level ChangeLog files, and some of them which do
mention the wrong platforms in them.

Finally, there are a large number of duplicated files. Some of them just end up
that way naturally like all the plf_stub.h files, or mlt files, so I don't mind
them. But there are other files like lots of the var_regs.h, mpc5510.h, most
(all?) hal_diag.c's and so on, which need only exist in one place. In some
cases, there may be situations where a platform may need to override things,
such as hal_diag.c, but 99% of the time, a default implementation which lives
in the variant HAL could be used; and a facility to allow it to be overridden
provided instead. This principle may apply to other things too.

Some of them like all the plf_cache.h's aren't even used (if they were intended
to be used they would be included from var_cache.h but they aren't).

Since I've already had a look at which files are identical, to make things
easier for you, I will attach the complete list (for the existing contrib
anyway).

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #33 from Jonathan Larmour <jifl@ecoscentric.com> 2012-05-31 14:55:19 BST ---
Created an attachment (id=1778)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1778)
Duplicated files in HALs

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #34 from Jonathan Larmour <jifl@ecoscentric.com> 2012-05-31 14:56:28 BST ---
(To be clear, that's the full list, including some like mlt files, which are ok
to be duplicated).

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #35 from Stefan Singer <Stefan.Singer@freescale.com> 2012-06-04 10:53:25 BST ---
Hi Jonathan,
our current port has little communality with the files I checked in way back
then, however I see I will need to fix the copyright headers and I guess I have
a major problem with the Tabs, since I always use them.
I will also create the directory hierarchy as suggested. 
All of those adjustments will take a couple of days, since I am in the middle
of working on a dependent application project, so I do not want to change the
baseline during this. 

Stefan

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #36 from Jonathan Larmour <jifl@ecoscentric.com> 2012-06-04 20:15:08 BST ---
Don't worry, that's fine, thanks for putting the effort in.

About the tabs, running a script like I suggested does deal with the vast
majority of issues at least, so hopefully it won't be a big issue after that,
just a few odd cases.

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ilijak@siva.com.mk

--- Comment #37 from Ilija Kocho <ilijak@siva.com.mk> 2012-06-05 08:56:35 BST ---
(In reply to comment #35)
> Hi Jonathan,
> our current port has little communality with the files I checked in way back
> then, however I see I will need to fix the copyright headers and I guess I have
> a major problem with the Tabs, since I always use them.
> I will also create the directory hierarchy as suggested. 
> All of those adjustments will take a couple of days, since I am in the middle
> of working on a dependent application project, so I do not want to change the
> baseline during this. 
> 
> Stefan

Hi Stefan

In current CVS you will find platform independent _universal_ drivers for
Freescale peripherals. They are decoupled from particular architecture with
intention to (re)use them with all (Freescale) architectures. I find following
drivers eligible for use with MPC 5xxx:

    CYGPKG_DEVS_ETH_FREESCALE_ENET

    CYGPKG_DEVS_SPI_FREESCALE_DSPI
    CYGPKG_DEVS_DISK_MMC_FREESCALE_DSPI

    CYGPKG_IO_SERIAL_FREESCALE_ESCI_HDR
    CYGPKG_IO_SERIAL_FREESCALE_ESCI

    CYGPKG_HAL_FREESCALE_EDMA - currently for 32 channels but can be extended
tp 64.

Also from Bugzilla following I2C driver:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001397

Likewise your MPC5xxx CAN driver could be prepared in similar fashion.
I would be happy to help you with both adapting MPC5xxx contribution for use
with universal drivers and for rendering MPC drivers such as CAN into
universal.

Regards
Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #38 from Karl Leiss <leiss@movex.de> 2012-07-05 10:40:00 BST ---
Created an attachment (id=1813)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1813)
MPC55xx/MPC56xx Flexcan driver

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #39 from Karl Leiss <leiss@movex.de> 2012-07-05 10:41:36 BST ---
(In reply to comment #37)
> Likewise your MPC5xxx CAN driver could be prepared in similar fashion.
> I would be happy to help you with both adapting MPC5xxx contribution for use
> with universal drivers and for rendering MPC drivers such as CAN into
> universal.
> 
> Regards
> Ilija

Hi Ilija,

attached the working CAN driver for MPC55xx/MPC56xx you can convert to a
generic version.

Regards,
Karl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #40 from Ilija Kocho <ilijak@siva.com.mk> 2012-07-08 17:01:41 BST ---
Hi Karl

(In reply to comment #39)
> (In reply to comment #37)
> > Likewise your MPC5xxx CAN driver could be prepared in similar fashion.
> > I would be happy to help you with both adapting MPC5xxx contribution for use
> > with universal drivers and for rendering MPC drivers such as CAN into
> > universal.
> > 
> > Regards
> > Ilija
> 
> Hi Ilija,
> 
> attached the working CAN driver for MPC55xx/MPC56xx you can convert to a
> generic version.

Thank you for contribution. I have started with conversion but since I am busy
with other projects it may take some time. For the time being only this
question: If you don't object I would change enumeration of CAN devices with
numbers rather than letters ("/dev/can0", instead of "/dev/canA") etc. in order
to make easier portability of applications from other architectures that
already have CAN drivers (NXP and Atmel). Is it OK?

Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #41 from Karl Leiss <leiss@movex.de> 2012-07-08 18:26:40 BST ---
(In reply to comment #40)
> Hi Karl
> 
> (In reply to comment #39)
> > (In reply to comment #37)
> > > Likewise your MPC5xxx CAN driver could be prepared in similar fashion.
> > > I would be happy to help you with both adapting MPC5xxx contribution for use
> > > with universal drivers and for rendering MPC drivers such as CAN into
> > > universal.
> > > 
> > > Regards
> > > Ilija
> > 
> > Hi Ilija,
> > 
> > attached the working CAN driver for MPC55xx/MPC56xx you can convert to a
> > generic version.
> 
> Thank you for contribution. I have started with conversion but since I am busy
> with other projects it may take some time. For the time being only this
> question: If you don't object I would change enumeration of CAN devices with
> numbers rather than letters ("/dev/can0", instead of "/dev/canA") etc. in order
> to make easier portability of applications from other architectures that
> already have CAN drivers (NXP and Atmel). Is it OK?
> 
> Ilija

Yes, you can change the enumeration.

Karl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1813|0                           |1
        is obsolete|                            |

--- Comment #42 from Ilija Kocho <ilijak@siva.com.mk> 2012-08-01 17:35:52 BST ---
Created an attachment (id=1856)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1856)
FlexCAN Generic driver 120801

Hi Karl

(In reply to comment #39)
> (In reply to comment #37)
> > Likewise your MPC5xxx CAN driver could be prepared in similar fashion.
> > I would be happy to help you with both adapting MPC5xxx contribution for use
> > with universal drivers and for rendering MPC drivers such as CAN into
> > universal.
> > 
> > Regards
> > Ilija
> 
> Hi Ilija,
> 
> attached the working CAN driver for MPC55xx/MPC56xx you can convert to a
> generic version.

Here I attach the generic driver. Because now it is not related to MPC5xxx only
I suggest you to open a new bug for FlexCAN driver and resubmit the patches
there. Then we can continue discussion and development. Now some notes on code
organization.

1. I found out that FlexCAN interrups are organized differently on MPC5xxx and
Kinetis so I decided to put them in separate packages. So now we have 3
packages that I submit as separate patches (+ tests as a separate patch).

     FlexCAN generic driver - contains all essential driver code

     MPC5xxx FlexCAN driver - mainly contains interrupt support for MPC5xxx

     Kinetis FlexCAN driver - mainly contains interrupt support for Kinetis but
also some Kinetis specific macros and functions such as PIN configuration,
clock gating, etc. These could also be placed in HAL.

The drivers are not finished, my idea is to continue in new a bug mentioned
above. I have more to comment and discuss, but I would let it for the new bug
if you agree.

Cheers

Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #43 from Ilija Kocho <ilijak@siva.com.mk> 2012-08-01 17:37:11 BST ---
Created an attachment (id=1857)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1857)
MPC5xxx FlexCAN driver 120801

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #44 from Ilija Kocho <ilijak@siva.com.mk> 2012-08-01 17:38:01 BST ---
Created an attachment (id=1858)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1858)
Kinetis FlexCAN driver 120801

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #45 from Ilija Kocho <ilijak@siva.com.mk> 2012-08-01 17:38:52 BST ---
Created an attachment (id=1859)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1859)
FlexCAN driver tests 120801

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

Stefan Singer <Stefan.Singer@freescale.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #781 is|0                           |1
           obsolete|                            |

--- Comment #46 from Stefan Singer <Stefan.Singer@freescale.com> 2012-08-06 09:48:36 BST ---
Created an attachment (id=1866)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1866)
required patches to PowerPC arch for VLE support

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #47 from Stefan Singer <Stefan.Singer@freescale.com> 2012-08-06 09:55:26 BST ---
Created an attachment (id=1867)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1867)
required patch for memalloc to work with MinGW built toolchain

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #48 from Stefan Singer <Stefan.Singer@freescale.com> 2012-08-06 10:01:05 BST ---
Created an attachment (id=1868)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1868)
required changes for rules.mak to work with MinGW built toolchains

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #49 from Stefan Singer <Stefan.Singer@freescale.com> 2012-08-06 10:37:14 BST ---
Created an attachment (id=1869)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1869)
device drivers for MPC5xxx family

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #50 from Stefan Singer <Stefan.Singer@freescale.com> 2012-08-06 16:30:25 BST ---
Created an attachment (id=1872)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1872)
MPC5xxx HAL packages

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #51 from Stefan Singer <Stefan.Singer@freescale.com> 2012-08-06 16:31:07 BST ---
Created an attachment (id=1873)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1873)
MPC5xxx port Documentation

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

Stefan Singer <Stefan.Singer@freescale.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #782 is|0                           |1
           obsolete|                            |

--- Comment #52 from Stefan Singer <Stefan.Singer@freescale.com> 2012-08-06 16:32:46 BST ---
Created an attachment (id=1874)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1874)
patches for ecos.db

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #53 from Stefan Singer <Stefan.Singer@freescale.com> 2012-08-06 16:41:51 BST ---
Hi Jonathan,
I have tried to follow your instructions and all the attachements from today
together form our port for the MPC5xxx family.
We have tried to minimize the impact of our contribution to the generic
packages, however there are a few changes that will be required:

- small changes to the generic PowerPC arch to support VLE Instruction Set
Architecture cores and also some small changes to support some of the newer
e200z0 and C55 e200z4/7 cores
- some small SED script lines accross multiple locations (e.g. memalloc,
rules.mak) to work with MinGW build toolchains. I have seen many requests on
Forums for different architectures, where people were looking for this, so this
should be of generic interest. At this point in time the VLE enabled toolchains
are only available in MinGW build form.

Once you have moved those packages into the repository, could you please add a
text like this on http://ecos.sourceware.org/

"Freescale Qorivva/5xxx Power Architecture port

Freescale has contributed a port of eCos to the Freescale MPC5xxx family of
MCUs. The port is only available from the CVS repository at this time."

Best regards
Stefan

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #54 from Ilija Kocho <ilijak@siva.com.mk> 2012-08-08 08:51:55 BST ---
Hello Stefan

(In reply to comment #49)
> Created an attachment (id=1869)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1869) [details]
> device drivers for MPC5xxx family

Recently I was asked to convert MPC5xxx FlecCAN driver to a generic one  (ref.
Comment #39). I spent some time on that and submitted a collection of patches
(ref. Comment #42).
What remains is to join and test it with MPC5xxx HAL (and adding eventual
changes being made to original MPC5xxx code in meantime).
Integration of generic FlexCAN driver with MPC5xxx HAL should be easy, it's
only necessary to provide device base address and interrupt number and
priorities to the driver. This is typically done by means of var_io.h (or
plf_io.h if they are platform specific). In order to isolate these device
related data in a separate file you can create a file var_io_devs.h which shall
be included in var_io.h. Then in var_io_devs.h you can put all similar
definitions for other devices as well: Ethernet, SPI, serial, etc. You can look
Kinetis var_io_devs.h for example.

- Ethernet driver (devs/eth/freescale/enet) is already prepared as generic so
it should be relatively easy to join it with MPC5xxx HAL. Here we wouldn't need
additional driver packages like for FlexCAN because interrupt organization is
same.

- ESCI: Here you have 2 parts HAL (diagnostic) and devs (interrupt driven). The
interrupt driven is designed as generic, similar to Ethernet.

- In addition you may also consider the DSPI driver /devs/spi/freescale/dspi
(that will also need eDMA library hal/misc/freescale/edma).

Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #55 from Stefan Singer <Stefan.Singer@freescale.com> 2012-08-13 08:18:17 BST ---
Hi Ilija,
my focus on the recent contribution was the actual HAL layer, not the /dev
contributions. I wanted to make sure, that we finally start to get the HAL
integrates, I was assuming, that it will be easier to swap some of the drivers.
But here some additional comments on the drivers:

- FLEXCAN - Karl is now owning this driver (he was the one that sent you the
package) and he is currently on vacation. Once he is back, he can look at your
code.
- ESCI - We are already using the generic ECSI code from the repository. We
dropped our earlier separate code
- Etherent - we do have some special code in the driver for errata workaround
for some older devices (e.g. MPC5553) and also code for cache management. Since
we have done so much work around networking based on that driver, we did not
want to swap that one
- DSPI - Karl had written a DSPI driver. Once he gets back from vacation and
has some time I would like him to look at the one in the repository and
investigate, whether we can move to that one. Quite frankly many of our demo
projects using eCOS do some really strange things with the DSPI (e.g. implement
serial audio interfaces or MOST MediaLB, ...) therefore I personally have never
used the generic driver, but put my own code into the packages for that
purpose.

Best regards
Stefan

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #56 from Ilija Kocho <ilijak@siva.com.mk> 2012-08-13 22:11:37 BST ---
(In reply to comment #55)
> Hi Ilija,
> my focus on the recent contribution was the actual HAL layer, not the /dev
> contributions. I wanted to make sure, that we finally start to get the HAL
> integrates, I was assuming, that it will be easier to swap some of the drivers.
> But here some additional comments on the drivers:
> 
> - FLEXCAN - Karl is now owning this driver (he was the one that sent you the
> package) and he is currently on vacation. Once he is back, he can look at your
> code.

It is actually still the the same old Freescale code. I merely renamed
references to MPC5xxx into FREESCALE_FLEXCAN/freescale_flexcan.

> - ESCI - We are already using the generic ECSI code from the repository. We
> dropped our earlier separate code

Now I can see it in ecos.db, I was following the Attachment #1869 which still
seem to contain the old driver.

> - Etherent - we do have some special code in the driver for errata workaround
> for some older devices (e.g. MPC5553) and also code for cache management. Since
> we have done so much work around networking based on that driver, we did not
> want to swap that one

The workarounds can be easily implemented to the generic driver, if this errata
is still in production. The generic code can contain a macro wit the "straight"
code which can be overridden in var_io.h or var_io_devs.h.

> - DSPI - Karl had written a DSPI driver. Once he gets back from vacation and
> has some time I would like him to look at the one in the repository and
> investigate, whether we can move to that one. Quite frankly many of our demo
> projects using eCOS do some really strange things with the DSPI (e.g. implement
> serial audio interfaces or MOST MediaLB, ...) therefore I personally have never
> used the generic driver, but put my own code into the packages for that
> purpose.

Yes sometimes you need some more efficient. But standard driver opens
opportunity for some standard devices: MMC card, SPI Flash memory, even
Ethernet.


Regards
Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #57 from Stefan Singer <Stefan.Singer@freescale.com> 2012-09-30 16:37:45 BST ---
Hi Ilija,
I have looked into your FlexCAN package and now I am confused about one thing:
In our original CDL file we looked at some of the definitions in the CDL file
of the HAL to determine, whether a certain device / platform actually has that
specific instance implemented. This was done by:
   active_if CYGNUM_HAL_DEV_LIST_CAN[set ::canletter]
in the CAN.cdl
now you modified this to:
   active_if CYGINT_DEVS_CAN_FREESCALE_FLEXCAN[set ::canletter]
My question is now about naming conventions. I assume, I can only set those in
the CDL files and I thought, that the HAL should use names like
CYGNUM_HAL_DEV_... to advertize its HW capabilities - is that not correct ?

Thanks
Stefan

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #58 from Stefan Singer <Stefan.Singer@freescale.com> 2012-09-30 16:41:15 BST ---
Hi ecos Maintainers, Jonathan,
any progress on the review of our contribution ? It has almost been two months
and we heard nothing so far. I was hoping, that active contributions are more
appreciated ?!

Best regards
Stefan

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #59 from Ilija Kocho <ilijak@siva.com.mk> 2012-09-30 20:17:37 BST ---
(In reply to comment #57)

Hi Stefan.

> Hi Ilija,
> I have looked into your FlexCAN package and now I am confused about one thing:
> In our original CDL file we looked at some of the definitions in the CDL file
> of the HAL to determine, whether a certain device / platform actually has that
> specific instance implemented. This was done by:
>    active_if CYGNUM_HAL_DEV_LIST_CAN[set ::canletter]
> in the CAN.cdl
> now you modified this to:
>    active_if CYGINT_DEVS_CAN_FREESCALE_FLEXCAN[set ::canletter]
> My question is now about naming conventions. I assume, I can only set those in
> the CDL files and I thought, that the HAL should use names like
> CYGNUM_HAL_DEV_... to advertize its HW capabilities - is that not correct ?

Regarding your CYGNUM_HAL_DEV_LIST... code, I haven't tried it but it looks
correct to me...

But, it's not just the naming. CYGINT_DEVS_CAN_FREESCALE_FLEXCAN[set
::canletter] introduces [CAN] cyg_interface(s) that platforms [can] implement.
Generally, renaming of objects was a major part of my job during the conversion
of the driver into generic, but in this case I took more liberty. I apologize
if I have been too intrusive, but I think that interfaces are more intuitive.
The usage is straightforward: Platforms implement certain device interface(s).
Interfaces are widely used for implementing device instances through eCos code
and I would recommend them also for other devices: serial channels, etc.

Btw, In newer Freescale documents the enumeration is numeric rather than
alphabetic. My experience is with Kinetis, but I think it is also applied to
MPC/Qorivva. I don't insist but would ask you to consider, as it will simplify
CDL code.


Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

Bernd Edlinger <bernd.edlinger@hotmail.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernd.edlinger@hotmail.de

--- Comment #60 from Bernd Edlinger <bernd.edlinger@hotmail.de> 2012-10-01 10:57:39 BST ---
Hello Stefan,

I was looking at this just for curiosity, and if it has a potential
to break other ports in any way.

Now there is one thing that is unclear to me, You said:

> - some small SED script lines accross multiple locations (e.g. memalloc,
> rules.mak) to work with MinGW build toolchains. I have seen many requests on
> Forums for different architectures, where people were looking for this, so this
> should be of generic interest. At this point in time the VLE enabled toolchains
> are only available in MinGW build form.

Well, I see there are changes in the sed scripts in 3 patches:
Attachment #1866, Attachment #1867 and Attachment #1868.

You changed

@sed -e '/^ *\\/d' -e "s#.*: #$@: #" $(@:.o.d=.tmp) > $@

to

@sed -e 's!c:/cygwin!!g' -e 's/c://g' -e '/^ *\\/d' -e "s#.*: #$@: #"
$(@:.o.d=.tmp) > $@
@printf "\n" >> $@


I assume you have a GCC built under MinGW and the make built under Cygwin.
and you try to remove drive letters to make the Cygwin-make understand the
dependencies.

But what I do not understand is this:

1. ":" is a quite normal character to a linux file system.
so should'nt that all be controlled by a compile option?

2. this change seems only to handle the case when cygwin is
installed under c:\cywin, however Cygwin could also be installed
in d:\cygwin, or even d:\tools\Cygwin.

3. at one place it looks slightly different:
@sed -e 's!c:/cygwin!!g' -e 's/c://g' -e 's!c:\cygwin!!g' ppc_offsets.tmp >
ppc_offsets1.tmp

should'nt this c:\ also be handled at the other places?

4. especially replacing every "c:" with "" looks wrong,
because if a DOS-file is "X:\path\file.c" its Cywin-Path
looks like "/cygdrive/x/path/file.c"

5. Are we sure that "printf" is always installed, like "sed"?
I have never seen this tool was used before, why dont you use
an "echo" here which is alredy used at many other places?


Regards,
Bernd Edlinger

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #61 from Ilija Kocho <ilijak@siva.com.mk> 2012-10-05 14:05:54 BST ---
(In reply to comment #58)

Hi Stefan

> Hi ecos Maintainers, Jonathan,
> any progress on the review of our contribution ? It has almost been two months
> and we heard nothing so far. I was hoping, that active contributions are more
> appreciated ?!

In comment #32 and comment #33 Jifl mentiond duplicate files, and they are
still present in recent attachment #1872 (aka /MPC5xxx HAL packages/ ).
There are a lot of definitions repeating across /include/ directories of all
platforms, in files such as: var_regs.h, mpc5*.h, plf_intr.h, etc. These can,
and should be consolidated in respective files placed in var/current/include
directory.

Also some of these files, notably mpc5*.h have copyright banners that are
incompatible with eCos licence.

This is my impression, but could the number of platforms be reduced, at least
for initial port? I have impression that the aim is to cover every chip (which
is not bad) but could some of these platforms be consolidated? It will make the
review and maintenance easier.

Regards

Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #62 from Ilija Kocho <ilijak@siva.com.mk> 2012-10-14 16:23:04 BST ---
(Addendum to comment #61)
> (In reply to comment #58)
> 
> Hi Stefan
> 
> > Hi ecos Maintainers, Jonathan,
> > any progress on the review of our contribution ? It has almost been two months
> > and we heard nothing so far. I was hoping, that active contributions are more
> > appreciated ?!
> 
> In comment #32 and comment #33 Jifl mentiond duplicate files, and they are
> still present in recent attachment #1872 [details] (aka /MPC5xxx HAL packages/ ).
> There are a lot of definitions repeating across /include/ directories of all
> platforms, in files such as: var_regs.h, mpc5*.h, plf_intr.h, etc. These can,
> and should be consolidated in respective files placed in var/current/include
> directory.
> 
> Also some of these files, notably mpc5*.h have copyright banners that are
> incompatible with eCos licence.
> 

Most of these definitions are actually for devices.
The definitions related to peripherals that have I/O device drivers, (for
example FlexCAN) should live in respective driver directories. That will
decouple them from the HAL and aid design of generic drivers. (Just to note, I
also see some redundant definitions such as ESCI.)

As a guide, var_io.h should contain definitions for peripherals that do not
belong to IO subsystem: clocking, interrupt controller, system integration,
clock/power management, etc.

Here also comes DMA, and I FYI there is a generic eDMA library under
packages/hal/misc/freescale/edma. 

Following peripherals combined with diverse Freescale architectures have
generic eCos drivers (that include headers):
   - ESCI
   - FlexCAN (the converted driver)
   - DSPI (uses eDMA)
   - Ethernet
   - UART
   - I2C (Last one in bug 1001397).

> This is my impression, but could the number of platforms be reduced, at least
> for initial port? I have impression that the aim is to cover every chip (which
> is not bad) but could some of these platforms be consolidated? It will make the
> review and maintenance easier.
> 
> Regards
> 
> Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #63 from Stefan Singer <Stefan.Singer@freescale.com> 2012-10-29 09:50:36 GMT ---
Hi Bernd,
you are right, I use eCos and the pre-build Config Tool under Cygwin and the
VLE enabled GCC is built under MinGW. That forces the problem,that we need to
remove drive letters to make the Cygwin-make understand the dependencies.

I am definitely not an expert on the SED scripting and would be really
gratefull, if someone has suggestions for a better script. As you assumed,
currently we only remove C: and if the tools are installed under a different
drive letter, this script will not support this. 
However the current modifications work for installation under C: and C:\cygwin,
which is the locations, where probably most people have installed them. Without
changes to the default scripts, our setup will not work at all. 
Can you help me in improving the script ?

Thanks Stefan

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #64 from Stefan Singer <Stefan.Singer@freescale.com> 2012-10-29 10:05:31 GMT ---
Hi Ilija,
I am a bit confused about your two last posts.

Our intention was to split the drivers into a generic part, which is put into
the dev section and the device dependent definitions, which I did put into the
HAL section. The rational was, that the MPC5xxx family spans now over 3 device
technologies 130, 90, 55 nm and more than 8 years and that obviously a number
of things have changed despite some generic base architecture. Therefore our
attempt to split the drivers in a way like this.
Are you proposing, that we should remove those device dependent definitions
from the HAL and have a separate folder for each device in the dev section ?

Notably the following 3 files exist in every platform: 
- var_regs.h: Register definitions in the eCos style. Of course there is
overlap with the device header file, since certain definitions exist in both
files, but this file is done in the way used in many other eCOS platforms and
the other file is reused from the Freescale website.
- mpc5*.h: This is the device definition header file for each device take
directly from our website. I tried to use that unmodified, however in some
instances I needed to make small adjustments, so that the common drivers find
common definitions. Since the spirit was to try to use those files unmodified
from the website, that are also the only files (at least that was my
attention), where there is a different copyright, since otherwise I would need
to modify those files.
- plf_intr.h: Interrupt Mapping for each device. This must be different for
each device. There are of course common sections accross multiple files, but
not two will be identical.

Can you please help me to understand, what I should change now ? I would not
like to remove the support for some devices to have less files to review - that
sounds wrong to me. I am still struggling to understand what you expect here. I
know that you are pushing to reuse the eCos drivers from other peripherals and
we will try to do that on some, but e.g. the new Flexcan driver does not work
yet at all (although I have already invested quite some time in it).

Thanks
Stefan

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #65 from John Dallaway <john@dallaway.org.uk> 2012-10-29 16:58:36 GMT ---
(In reply to comment #63)

> I am definitely not an expert on the SED scripting and would be really
> gratefull, if someone has suggestions for a better script. As you assumed,
> currently we only remove C: and if the tools are installed under a different
> drive letter, this script will not support this. 
> However the current modifications work for installation under C: and C:\cygwin,
> which is the locations, where probably most people have installed them. Without
> changes to the default scripts, our setup will not work at all. 
> Can you help me in improving the script ?

Stefan, it would be necessary to use many invocations of the "cygpath" tool to
perform robust translation (with reference to the Cygwin mount table). Support
for native Windows-hosted toolchains would be best achieved by porting the eCos
host tools to execute in a MinGW environment rather than translating a large
number of file paths between the two environments.

If I have understood correctly from comment #2, the current eCos PowerPC
toolchains for Linux and Cygwin hosts will work correctly with this MPC5xxx
contribution.

I think it best to separate out the issue of native Windows toolchain support
from this MPC5xxx contribution. Let's drop the file path translation elements
from this patch set and work towards a more elegant solution for supporting
native Windows toolchains as a separate project.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #66 from Bernd Edlinger <bernd.edlinger@hotmail.de> 2012-10-29 18:09:42 GMT ---
(In reply to comment #63)
Hi Stefan,

I agree with John's comment too.

I have the impression that the problem here comes from the combination
of a MinGW-based GCC and a Cygwin-based make.

My question is: would it be an option for you to build the make as a
MinGW-based tool?

Regards,
Bernd.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #67 from Ilija Kocho <ilijak@siva.com.mk> 2012-10-30 13:25:52 GMT ---
(In reply to comment #64)

Hi Stefan

> Hi Ilija,
> I am a bit confused about your two last posts.
> 
> Our intention was to split the drivers into a generic part, which is put into
> the dev section and the device dependent definitions, which I did put into the
> HAL section. The rational was, that the MPC5xxx family spans now over 3 device
> technologies 130, 90, 55 nm and more than 8 years and that obviously a number
> of things have changed despite some generic base architecture. Therefore our
> attempt to split the drivers in a way like this.

Technologies change, new features are being added, but it usually doesn't
change the basic device structure. New flags/fields are introduced in
previously unused/reserved bits. Even when new registers are added they appear
in positions that don't break binary compatibility with the legacy devices.

> Are you proposing, that we should remove those device dependent definitions
> from the HAL and have a separate folder for each device in the dev section ?

On the contrary I am proposing reduction of number of files. The structures and
definitions that, at present, have multiple copies across platforms should be
consolidated by single instances that shall live either under variant or with
respective device drivers.

Device drivers would keep headers for their respective hardware: eSCI, FlexCAN,
DSPI, Ethernet, etc. Here they can be shared by multiple
architectures/families: MPC5xxx, Kinetis, Coldfire, etc.

Variant would accommodate devices that belong to the HAL: clocks, interrupt
controller, port control and so on.

Note: There are hardware components that belong to HAL, but are shared among
multiple architectures, for example eDMA. Their sub-tree is packages/hal/misc.

Normal places for HAL structures and definitions is var_io.h (itself or files,
living in the same directory with, and being included by var_io.h). For
interrupt-related definitions, such as interrupt vectors, there is var_intr.h.

Now we come to platform specific data. Here come [almost always] pin (port)
definitions and [sometimes] base addresses. It is important to note that base
addresses are usually same across the complete family and should be defined in
variant, but sometimes they may differ. Sometimes it is useful to define some
default value in variant, with provision for platform override.

> 
> Notably the following 3 files exist in every platform: 
> - var_regs.h: Register definitions in the eCos style. Of course there is
> overlap with the device header file, since certain definitions exist in both
> files, but this file is done in the way used in many other eCOS platforms and
> the other file is reused from the Freescale website.

> - mpc5*.h: This is the device definition header file for each device take
> directly from our website. I tried to use that unmodified, however in some
> instances I needed to make small adjustments, so that the common drivers find
> common definitions. Since the spirit was to try to use those files unmodified
> from the website, that are also the only files (at least that was my
> attention), where there is a different copyright, since otherwise I would need
> to modify those files.

There are 2 important issues with mpc5*.h files:
  - Their copyright message: IANAL and please do not consider this as legal
advice, but IMO that the copyright banner on these files is not acceptable.
  - Redundancy: Same structures and definitions are being copied over and over
and some of them are not even being used. Actually they are the ones that
should be consolidated as described above. Even in present sources, some
structures and/or definitions have their replacements in device driver headers,
such as eSCI and CAN, so should have already been removed.

> - plf_intr.h: Interrupt Mapping for each device. This must be different for
> each device. There are of course common sections accross multiple files, but
> not two will be identical.
> 
> Can you please help me to understand, what I should change now ? I would not
> like to remove the support for some devices to have less files to review - that
> sounds wrong to me. I am still struggling to understand what you expect here. 

1. Consolidate HAL structures and definitions under variant level. This usually
gives structures and definitions that are superset (union) of individual
devices. If some devices have radically different hardware they may lend under
their respective platform (feel free to point eventual such case in this bug -
we can discuss it before you proceed with implementation).

2. The same for device drivers. Please note that we already have such files for
eSCI and FlexCAN. Also there are devices not yet supported by eCos. If they do
not belong to HAL, you can safely omit them from headers (at least for the time
being).

3. See which base address definitions shall lend under variant and which under
platform(s).

4. Once you have accomplished Steps 1. and 2., mpc5*.h files shall be redundant
and you can remove them.


> I
> know that you are pushing to reuse the eCos drivers from other peripherals and
> we will try to do that on some, but e.g. the new Flexcan driver does not work
> yet at all (although I have already invested quite some time in it).

Regarding FlexCAN, I guess, basically you need to do the same thing that you
have already done with eSCI. FlexCAN should be slightly easier than eSCI
because CAN has no HAL drivers. Maybe it could help if we open a separate bug
for FlexCan.

Should you have additional questions, feel free to ask.
Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

Stefan Singer <Stefan.Singer@freescale.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1866|0                           |1
        is obsolete|                            |

--- Comment #68 from Stefan Singer <Stefan.Singer@freescale.com> ---
Created attachment 2059
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2059&action=edit
patches required for PowerPC HAL to support VLE

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #69 from Stefan Singer <Stefan.Singer@freescale.com> ---
Hi all,
we have now integrated almost all of the requested changes, however we now need
a few changes in the PowerPC:
- VLE ISA support
- support for cores without core timers
- support for e200z0 core
- GDB breakpoint support

We have tried to keep the changes to the generic arch as minimal as possible,
but I can not survive without that minimal set of changes.

Best regards
Stefan

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jifl@ecoscentric.com
         AssignedTo|backlog@bugs.ecos.sourcewar |jifl@ecoscentric.com
                   |e.org                       |

--- Comment #31 from Jonathan Larmour <jifl@ecoscentric.com> 2012-05-31 13:54:43 BST ---
Hi Stefan,

(In reply to comment #30)
> Hi eCos Maintainers,
> we have continued to develop that MPC5xxx branch of eCos and would like to come
> back to contribute to the main tree. We are currently planing a distribution
> launch of one of the MPC56xx MCUs, where we would like to see a contribution
> announcement on the eCos website in the 1st week of July. How much time do you
> need to integrate our contribution into the main CVS ? I am not talking about
> modifications to the existing files, just entirely new files for the MPC5xxx
> line of products ?

We do want code to be maintainable, meet coding standards, and work correctly
not just with the default configuration of the most common packages, but with
all packages in all configurations (well, in theory - in practice, it's hard to
test this without an automated testing infrastructure, but we do try and get as
good as we can).

So with that in mind, it all depends on how much, if any, work would be
required for the ports to meet those basic standards. Since there have already
been comments, and you've been receptive to comments in the past, hopefully
there are not many issues remaining, but ultimately the only way to know is to
post your latest code.

If you can post the code, and we can get a good turnaround on review comments,
then 1st week of July should be achievable.

One little comment I can make just on the highest level structure which I don't
think anyone else has made is that the hal/powerpc/ layer is starting to get
crowded, and this contribution would add 18 more directories at that level. I
think a new hal/powerpc/mpc5xxx directory hierarchy is called for, with the
existing hal/powerpc/mpc5xxx directory in your contrib renamed to
hal/powerpc/mpc5xxx/var (in line with the precedent in other architectures).
The package contents should be able to stay exactly the same - I'm only talking
about moving the root of each package, and updating the ecos.db in line with
that.

Cheers,

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #30 from Stefan Singer <Stefan.Singer@freescale.com> 2012-05-30 14:50:38 BST ---
Hi eCos Maintainers,
we have continued to develop that MPC5xxx branch of eCos and would like to come
back to contribute to the main tree. We are currently planing a distribution
launch of one of the MPC56xx MCUs, where we would like to see a contribution
announcement on the eCos website in the 1st week of July. How much time do you
need to integrate our contribution into the main CVS ? I am not talking about
modifications to the existing files, just entirely new files for the MPC5xxx
line of products ?

Best regards
Stefan

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #29 from Dave Peterson <dpeter@woodward.com> 2010-09-28 18:14:36 BST ---
(In reply to comment #28)
> Hi, the port is complete for all current MPC55xx and MPC56xx devices, that
> support classic PowerPC coding. There is currently no official VLE support,
> since GCC for VLE will only be available next year (2011). This means, that all
> MPC560xB/C/E/P/S devices are not supported. We are currently working on the
> enhancements to support Redboot with load to Flash and execute from there,
> since we originally did not really focus on Redboot, since typically the
> devices of that MCU family have not enough RAM to load and execute from there.
> Once this work is complete, I was intending to upload the package here again,
> hoping that the maintainers would integrate it into the main tree. Last time my
> contribution was ignored, so I am not sure, what I can do, if it is ignored
> again. Currently I maintain it mainly for our internal purposes but I am more
> than happy to give that code to anyone.

Stefan,
Thanks for the update. Hopefully your work will soon be released.
Do you know if there has been a port for the MPC5200?
Dave

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

--- Comment #28 from Stefan Singer <Stefan.Singer@freescale.com> 2010-09-26 13:02:35 BST ---
Hi, the port is complete for all current MPC55xx and MPC56xx devices, that
support classic PowerPC coding. There is currently no official VLE support,
since GCC for VLE will only be available next year (2011). This means, that all
MPC560xB/C/E/P/S devices are not supported. We are currently working on the
enhancements to support Redboot with load to Flash and execute from there,
since we originally did not really focus on Redboot, since typically the
devices of that MCU family have not enough RAM to load and execute from there.
Once this work is complete, I was intending to upload the package here again,
hoping that the maintainers would integrate it into the main tree. Last time my
contribution was ignored, so I am not sure, what I can do, if it is ignored
again. Currently I maintain it mainly for our internal purposes but I am more
than happy to give that code to anyone.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000761

Dave Peterson <dpeter@woodward.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dpeter@woodward.com

--- Comment #27 from Dave Peterson <dpeter@woodward.com> 2010-09-14 16:38:59 BST ---
How do I find out the status of the MPC55xx support for eCos?
I have been waiting for this to be added to the release, but I don't know how
to find out the timeframe.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

http://bugzilla.ecoscentric.com/show_bug.cgi?id=1000761





--- Comment #25 from Stefan Singer <Stefan.Singer@freescale.com>  2009-08-21 15:03:47 ---
Created an attachment (id=782)
 --> (http://bugzilla.ecoscentric.com/attachment.cgi?id=782)
patch to ecos.db for MPC5xxx support

Hi,
in addition to the last attachement, here is the patch file to apply to the
ecos.db to include the support for MPC5xxx.

Could you please check that into repository ?

Thanks
Stefan


-- 
Configure bugmail: http://bugzilla.ecoscentric.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

http://bugzilla.ecoscentric.com/show_bug.cgi?id=1000761





--- Comment #24 from Stefan Singer <Stefan.Singer@freescale.com>  2009-08-21 14:57:33 ---
Created an attachment (id=781)
 --> (http://bugzilla.ecoscentric.com/attachment.cgi?id=781)
Contribution Files for MPC5xxx MCUs

Hi all,
please find attached all the delta files to support the MPC5xxx MCUs. These are
all new files, no further changes to existing files required. This package
supports the following MCUs / boards:

MPC563XM on Freescale EVB
MPC5517 MCU with the following Boards:
  - Freescale EVB with internal RAM
  - Freescale EVB with external SRAM on 208 BGA daughter card
  - Freescale EVB with external SRAM on MOST daughter card
  - 5510_LITE board (www.kanis.de)
MPC5534 on Freescale EVB
MPC5553 on Freescale EVB
MPC5554 on Freescale EVB
MPC5561 on Freescale EVB
MPC5565 on Freescale EVB
MPC5566 on Freescale EVB
MPC5567 MCU with the following Boards
  - Freescale EVB
  - Freescale Automotive Gateway Development Board
  - ZGW board
  - Phytec PCM 028 board
MPC5668 on Freescale EVB
MPC5674 on Freescale EVB

I will upload the diff to the eCos.db required for those in a separate
attachement. Could you please check this into the repository ?

Thanks
Stefan


-- 
Configure bugmail: http://bugzilla.ecoscentric.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

http://bugzilla.ecoscentric.com/show_bug.cgi?id=1000761





--- Comment #22 from Stefan Singer <Stefan.Singer@freescale.com>  2009-08-06 19:48:51 ---
Hi Nick,
can you please check in the patch to hal_misc.c and also the patches you sent
yesterday into the CVS server ? I believe than we should be clean and I could
than submit all the platforms next week after some final testing.

Thanks
Stefan


-- 
Configure bugmail: http://bugzilla.ecoscentric.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

http://bugzilla.ecoscentric.com/show_bug.cgi?id=1000761





--- Comment #21 from Stefan Singer <Stefan.Singer@freescale.com>  2009-08-06 19:44:42 ---
Created an attachment (id=767)
 --> (http://bugzilla.ecoscentric.com/attachment.cgi?id=767)
patch to hal_misc.c for unified cache

Hi Nick,
I changed the macro name to HAL_CACHE_UNIFIED, as you suggested. Attached is
the patch to the hal_misc.c file. Obviously it is only an exchange of the macro
name in 2 instances. Can you please check that in, since I am not allowed to do
that ?

Thanks
Stefan


-- 
Configure bugmail: http://bugzilla.ecoscentric.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

http://bugzilla.ecoscentric.com/show_bug.cgi?id=1000761





--- Comment #19 from Stefan Singer <Stefan.Singer@freescale.com>  2009-08-06 15:30:23 ---
Hi Nick,
I am currently on vacation, so I can not test it on a target, but it looks good
when I compile it. I will test on real HW next week. Now I have only two
outstanding problems:

problem I:
You write:
>The intended use of the BOOK_E option is that the HAL for the appropriate
>variant should have a "requires" statement for it. Otherwise we could end up
>with twisty mazes of conditions in the architecture HAL.

I have done that now, but that means, everytime you select the template, you
will get a conflict window. I am probably not familiar enough with the whole
options of cdl files, but can this not be avoided ? I know, that for templates
options can be forced, but can I do this also for the cdl file ?

problem II:
you did not comment on the proposed changes in hal_misc.c regarding the Macro
for unified cache, where you had used
#ifndef HAL_UCACHE_ENABLE
which is used as a Macro function call in all other architectures and where I
had proposed to change that to "HAL_CACHE_IS_UCACHE". I need the macro function
call for devices with our e200z6 core, so if you are not agreeing to change
that other macro, than I would need to change the name of this, which I think
would be unclean, since this is used in all other architectures.
Can you please look at that ?


-- 
Configure bugmail: http://bugzilla.ecoscentric.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

http://bugzilla.ecoscentric.com/show_bug.cgi?id=1000761





--- Comment #10 from Stefan Singer <Stefan.Singer@freescale.com>  2009-06-02 10:56:39 ---
Hi, 
Thank you for writing me an email, but I am currently on vacation, returning to
the office on Tuesday June 2nd. In this time I will have no  access to emails,
but I will certainly respond to your mail after my return. In urgent cases
please contact Josef Fuchs <Josef.Fuchs@freescale.com>

Best Regards
Stefan Singer


-- 
Configure bugmail: http://bugzilla.ecoscentric.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.