From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17979 invoked by alias); 6 Aug 2009 14:30:39 -0000 Received: (qmail 17963 invoked by uid 22791); 6 Aug 2009 14:30:37 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 06 Aug 2009 14:30:31 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 3ADF72F78037 for ; Thu, 6 Aug 2009 15:30:28 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5n4jzhALwtVu; Thu, 6 Aug 2009 15:30:27 +0100 (BST) From: bugzilla-daemon@ecoscentric.com To: ecos-bugs@ecos.sourceware.org Subject: [Bug 1000761] eCos support for MPC5xxx MCUs X-Bugzilla-Reason: QAcontact X-Bugzilla-Type: newchanged X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: Stefan.Singer@freescale.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: normal X-Bugzilla-Assigned-To: nickg@ecoscentric.com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Thu, 06 Aug 2009 14:30:00 -0000 Message-Id: <20090806143025.DAB2E2F7803B@mail.ecoscentric.com> Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-bugs-owner@sourceware.org X-SW-Source: 2009/txt/msg00255.txt.bz2 http://bugzilla.ecoscentric.com/show_bug.cgi?id=1000761 --- Comment #19 from Stefan Singer 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.