From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19795 invoked by alias); 18 May 2011 17:20:13 -0000 Received: (qmail 19771 invoked by uid 22791); 18 May 2011 17:20:11 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 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; Wed, 18 May 2011 17:19:57 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 43EC02F78016 for ; Wed, 18 May 2011 18:19:56 +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 jwPHmIyPzxLV; Wed, 18 May 2011 18:19:55 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1000819] Add support for Atmel AT91SAM9263 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: dhelgason@shaw.ca X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: normal X-Bugzilla-Assigned-To: john@dallaway.org.uk 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: Wed, 18 May 2011 17:20:00 -0000 Message-Id: <20110518171954.DA7DB2F7800B@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-05/txt/msg00018.txt.bz2 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000819 --- Comment #28 from Daniel Helgason 2011-05-18 18:19:50 BST --- (In reply to comment #11) > Let's try to push through with review and get it checked in. I've invited all > interested parties to add themselves to the CC list and add their own comment > where necessary/appropriate. > > Evgeniy, the use of multiple patches is a great help - thank you! > > Let's start with the ARM7/ARM9 abstraction work (patch 1). This looks to be a > case of moving the existing HAL cache macros (which are not appropriate for > AT91SAM9) from the AT91 variant package to a new ARM7 package. I assume that > there is nothing AT91-specific in the new package so it could be used by any > other ARM7 ports in the future. Please confirm. > ... Is is correct to have AT91 as a variant? I see it more as a package that defines a set of common I/O and provides macros for common AT91 stuff. Would it make sense if things were arranged more like: ARM (arch) +- ARM7 (variant) + SAM7S (platform) + SAM7X (platform) + Other Non-AT91 chip (platform) + SAM7S-EK (board) + SAM7X-EK (board) ...etc. + ARM9 (variant) + SAM9263 (platform) + SAM9G20 (platform) + SAM9RL64 (platform) + Other Non-AT91 chip (platform) + SAM9G20-EK (board) + SAM99RL-EK (board ...etc. + AT91 (I/O support package) Or maybe I'm just confused about the relationship between arch, var, and plf? If so, could someone please enlighten me. Thanks! In this scheme, the AT91-based platforms define the peripheral IDs, interrupts, etc. that vary from one chip to another. The AT91 I/O package would have absolutely no knowledge of any particular chip. A real advantage to having AT91 be a stand-alone I/O support package is that we could easily support other chips with AT91 peripherals such as Atmel's SAM3 series. Dan H. -- 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.