[Bug 1000761] New: eCos support for MPC5xxx MCUs

[Bug 1000761] New: eCos support for MPC5xxx MCUs

[bugzilla-daemon]

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

           Summary: eCos support for MPC5xxx MCUs
           Product: eCos
           Version: 3.0
          Platform: Other (please specify)
        OS/Version: PowerPC
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: normal
         Component: HAL
        AssignedTo: jifl@ecoscentric.com
        ReportedBy: Stefan.Singer@freescale.com
         QAContact: ecos-bugs@ecos.sourceware.org
             Class: ---


Created an attachment (id=715)
 --> (http://bugzilla.ecoscentric.com/attachment.cgi?id=715)
Patches for eCos support for MPC5xxx MCUs

Hi eCos maintainers,
here in Freescale we have developed a port of eCos for many of our MPC5xxx
MCUs. We did this originally for eCos 2.0 and checked it recently against the
new eCos 3.0 release. We have also signed the Assignment form of the Free
Software Foundation (please see below the email from the copyright clerk). We
made the port in a way to minimize changes to the existing sources:

Those packages are new and did not exist previously:

packages\devs\can\powerpc\mpc55xx
packages\devs\eth\powerpc\mpc5xxx
packages\devs\spi\powerpc\mpc551x
packages\devs\spi\freescale\mc33905
packages\devs\eth\phytec
packages\devs\serial\powerpc\mpc55xx
packages\hal\powerpc\e200
packages\hal\powerpc\mpc551x
packages\hal\powerpc\mpc5517
packages\hal\powerpc\mpc5517_MOST
packages\hal\powerpc\mpc5553
packages\hal\powerpc\mpc5554
packages\hal\powerpc\mpc5566
packages\hal\powerpc\mpc5567
packages\hal\powerpc\mpc5567demo
packages\hal\powerpc\mpc5567_ZGW
packages\hal\powerpc\mpc5668
packages\hal\powerpc\mpc5668_var
packages\hal\powerpc\mpc55xx
packages\hal\powerpc\mpc5517_kanis
packages\hal\powerpc\mpc5567pcm028
This package was modified to fix some issues regarding endianess:

packages\devs\eth\smsc\lan91cxx 
And obviously we updated the database:

packages\ecos.db

How can we handle over the files now ? Is there an email adress to send them to
or a webinterface ? The FAQ says, that externals can not write directly to the
CVS.

Best regards,

Stefan Singer
EMEA FAE Manager Automotive


-- 
Configure bugmail: http://bugzilla.ecoscentric.com/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://bugzilla.ecoscentric.com/show_bug.cgi?id=1000761





--- Comment #1 from Alex Schuilenburg <alexs@ecoscentric.com>  2009-05-11 18:11:08 ---
Please note that this contribution was submitted by myself on behalf of Stefan.
 Stefan has emailed details of this contribution to ecos-maintainers but it
appears the spam filters of sourceware have discarded the email for some
reason.

I figured the best way for the maintainers to communicate to Stefan would be
through bugzilla until the mailing problem was resolved.

FSF assignment has appearently taken place:
-----Original Message-----

From: Donald R Robertson III via RT [mailto:copyright-clerk@fsf.org]

Sent: Tuesday, April 07, 2009 20:41

To: Singer Stefan-TMK144; Torres Steven-R7AAAF

Subject: [gnu.org #360143] changes to the Copyright Assignment

Hello again,

You are correct, your contributions may now be accepted. You can see about
contributing to eCos at http://ecos.sourceware.org/contrib.html.

Thanks so much for your time, and happy hacking!



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

[Issue 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

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





--- Comment #2 from Alex Schuilenburg <alexs@ecoscentric.com>  2009-05-11 19:01:45 ---
-------- Original Message --------
Hi Alex,
thanks for taking care of this. As already told on the phone, here is the port
for the Freescale MPC5xxx devices which support classic PowerPC Instructions.
Due to the missing GNU Compiler for the VLE instruction set, there is no
support for all the devices with the e200z0 core, which only have the VLE
option. The only exception is the MPC551x family, where the main core is
supported in this port, but not the secondary support. It is important to use
the newer GNU Compiler for PowerPC delivered with eCOS 3.0. This will not work
with the older GNU Compiler delivered with eCos 2.0.
Please scroll down to the original email to find the description.

Best regards,

Stefan Singer
EMEA FAE Manager Automotive


-- 
Configure issuemail: http://bugzilla.ecoscentric.com/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://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.

[Issue 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

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





--- Comment #18 from Nick Garnett <nickg@ecoscentric.com>  2009-08-05 10:54:13 ---
Created an attachment (id=766)
 --> (http://bugzilla.ecoscentric.com/attachment.cgi?id=766)
Fixed vector support

(In reply to comment #16)
> 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

I'm not sure I understand what you are doing here. The whole point of these
macros is that they can be tested for existence and then used if they are
present. We don't need to have a separate macro that indicates whether the
first macro is defined. What a macro is defined to should have no effect on the
ifdef test.


> - 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

It is not a good idea to put variant specific stuff into the architecture HAL.
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 also don't like the CYGHWR_HAL_POWERPC_BOOK_E_e200z01 option. This should
appear as an option in the architecture HAL which the variant HALs should
require as necessary. Rather than something that gets imported from another
package. I'm also not too keen on the name of this option or the macro it
controls. Making explicit reference to a specific CPU model is not very
future-proof. I would prefer something more like
CYGHWR_HAL_POWERPC_BOOK_E_FIXED_VECTORS, and a similar change of name for the
macro. 


> 
> - 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.

I think that these vectors should probably go after the call to
hal_fudge_vector_alignment. I would also have defined most of this stuff in
arch.inc and just added a single macro definition in vectors.S. That way
vectors.S remains fairly clean and the option would remain for future variants
to define their own version of the macro if necessary.

I've attached a patch that more closely corresponds to what I would like to
see. Obviously, I have not tried it for any Book E targets, but it does compile
for some existing PPC targets.


-- 
Configure issuemail: http://bugzilla.ecoscentric.com/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://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.

[Issue 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

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


Nick Garnett <nickg@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1




--- Comment #20 from Nick Garnett <nickg@ecoscentric.com>  2009-08-06 16:05:10 ---
(In reply to comment #19)
> 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 ?

This is one of those things that you have to put up with occasionally.
Essentially the CDL language and the conflict resolver are missing the ability
for packages to force options to a particular value. Instead they must use the
requires mechaninsm which can sometimes generate a conflict. 


> 
> 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 ?
> 

The first paragraph of my response addressed this. Perhaps I am not
understanding exactly why you wanted to make this change. HAL_UCACHE_ENABLE is
defined only on targets that have a unified cache. So in addition to being
called to enable the cache, we can also test whether it is defined to indicate
whether the target has a unified cache.

However, if you want a separate indicator of a unified cache, then define and
test HAL_CACHE_UNIFIED. This is used in other architectures and should be used
in the PPC architecture too. Having this defined will also cause some of the
test programs to adapt to a unified cache.


-- 
Configure issuemail: http://bugzilla.ecoscentric.com/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://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 #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.

[Issue 1000761] eCos support for MPC5xxx MCUs

[bugzilla-daemon]

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


Nick Garnett <nickg@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #763 is|0                           |1
           obsolete|                            |
 Attachment #766 is|0                           |1
           obsolete|                            |
 Attachment #767 is|0                           |1
           obsolete|                            |




--- Comment #23 from Nick Garnett <nickg@ecoscentric.com>  2009-08-07 10:23:10 ---
Created an attachment (id=768)
 --> (http://bugzilla.ecoscentric.com/attachment.cgi?id=768)
PowerPC Book E update patch

Attached is a copy of the patch I have just committed to the repository.


-- 
Configure issuemail: http://bugzilla.ecoscentric.com/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://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 #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.