This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Issue 1000761] eCos support for MPC5xxx MCUs


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]