From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16499 invoked by alias); 14 Nov 2011 00:28:14 -0000 Received: (qmail 16491 invoked by uid 22791); 14 Nov 2011 00:28:14 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,TW_KG 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; Mon, 14 Nov 2011 00:27:53 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id C45682F78015 for ; Mon, 14 Nov 2011 00:27:50 +0000 (GMT) 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 M2ii0P8YKcqQ; Mon, 14 Nov 2011 00:27:48 +0000 (GMT) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001291] New HAL for Cortex-M3 Smartfusion device X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jifl@ecoscentric.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: normal X-Bugzilla-Assigned-To: ilijak@siva.com.mk X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Mon, 14 Nov 2011 00:28:00 -0000 Message-Id: <20111114002748.035E72F78010@mail.ecoscentric.com> Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org X-SW-Source: 2011-11/txt/msg00010.txt.bz2 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001291 --- Comment #21 from Jonathan Larmour 2011-11-14 00:27:37 GMT --- (In reply to comment #20) > So we can start with HAL. > > First one trivial issue: > CYGNUM_HAL_KERNEL_COUNTERS_CLOCK_ISR_DEFAULT_PRIORITY is set to 0xE0, and > description is "Set clock ISR priority to lowest priority.", probably carried > from other HAL. Since device is said to have 5 priority bits, please change > either value or description. (I wander if we should consider a CDL for lowest > ISR priority on architecture level). I would recommend against it at architecture level as it's harder to choose a good default_value there - it is only in the context of the processor you are likely to know about other interrupt sources. > CYG_HAL_STARTUP: I can see that you have followed our discussion from mailing > list. Please consider the following: I've missed this discussion, can you tell me what the subject was and on which list? > Basic idea is to cover all (or most) memory layouts not employing external > memory on variant level. Since this is a fresh port I would suggest to do it. > > 1. Placing CYG_HAL_STARTUP in variant tree will avoid it's cloning in > forthcoming (i hope they will come) platform trees and at the same time provide > consistent propagation of it's updates (enhancements and bugs) in each of them. > In order to keep all startup together, platform's CYG_HAL_PLF_STARTUP, if > present, can be "parenthed" by CYG_HAL_STARTUP. Note: "If present means" if > there is external memory, for single-chip boards we can/should omit it. > > 1.1. Together with CYG_HAL_STARTUP come MLT filesets (fileset = ldi + header) > affected by. Normally, this will require a new pkgconf directory in variant. > Further, all values in MLT files (memory sizes, locations, etc.) can be > parametrized in CDL so it would be possible to cover many, (hopefully all) > combinations of on-chip memory with a handful of MLT filesets. > > 2. Platforms with external memory is going to use CYG_HAL_PLF_STARTUP as well > as their own MLT filesets in order to override CYG_PLF_STARUP. However they > will also be able to make use of CYG_HAL_STARTUP (for eventual single-chip > emulation, etc.). I'm not very keen on the idea of the startup types being split over two variables. Let's take a step back. What problem is actually needing to be solved by CYG_HAL_PLF_STARTUP? I can't help but think that there surely must be a better way to improve the abstraction in the architectural HAL if there's insufficient abstraction at the moment. Just another little issue: in CYGSEM_HAL_CORTEXM_A2FXXX_DEFINES_IDLE_THREAD_ACTION it talks about "overwriting" but I believe it was intended to say "overriding". 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.