public inbox for ecos-bugs@sourceware.org
help / color / mirror / Atom feed
From: bugzilla-daemon@ecoscentric.com
To: ecos-bugs@ecos.sourceware.org
Subject: [Issue 1000761] eCos support for MPC5xxx MCUs
Date: Thu, 06 Aug 2009 15:05:00 -0000	[thread overview]
Message-ID: <20090806150511.BD7DB2F7803B@mail.ecoscentric.com> (raw)
In-Reply-To: <bug-1000761-13@http.bugzilla.ecoscentric.com/>

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.


  parent reply	other threads:[~2009-08-06 15:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-11 17:06 [Bug 1000761] New: " bugzilla-daemon
2009-05-11 17:11 ` [Issue 1000761] " bugzilla-daemon
2009-05-11 18:01 ` bugzilla-daemon
2009-06-02  9:56 ` [Bug " bugzilla-daemon
2009-08-05  9:54 ` [Issue " bugzilla-daemon
2009-08-06 14:30 ` [Bug " bugzilla-daemon
2009-08-06 15:05 ` bugzilla-daemon [this message]
2009-08-06 18:44 ` bugzilla-daemon
2009-08-06 18:49 ` bugzilla-daemon
2009-08-07  9:23 ` [Issue " bugzilla-daemon
2009-08-21 13:57 ` [Bug " bugzilla-daemon
2009-08-21 14:04 ` bugzilla-daemon
     [not found] <bug-1000761-13@http.bugs.ecos.sourceware.org/>
2009-06-08 15:46 ` [Issue " bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090806150511.BD7DB2F7803B@mail.ecoscentric.com \
    --to=bugzilla-daemon@ecoscentric.com \
    --cc=ecos-bugs@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).