[Bug 1001442] New: LPC17XX bit band macro proposal

[Bug 1001442] New: LPC17XX bit band macro proposal

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001442

           Summary: LPC17XX bit band macro proposal
           Product: eCos
           Version: CVS
          Platform: Other (please specify)
        OS/Version: Cortex-M
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: HAL
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: bernard.fouche@kuantic.com
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


If ever bit band macros can make it into eCos, here is a proposal.

Beside the gain in speed, IMHO the real advantage is to avoid race conditions
that can occur in a memory/register area that concerns more than one
peripheral.

For instance:

- peripheral power control register.
- ADC channel selection register (see for instance bug #1001437)

For GPIO bit band avoids having to select FIOSET or FIOCLR according to the bit
value to write.

(Maybe the proposed macro names are ugly, not located in the correct file,
etc...)

-- 
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.

[Bug 1001442] LPC17XX bit band macro proposal

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001442

--- Comment #1 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-04 09:53:09 GMT ---
Created an attachment (id=1487)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1487)
bit band macro proposal

-- 
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.
>From ecos-bugs-return-8595-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Jan 04 09:53:29 2012
Return-Path: <ecos-bugs-return-8595-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 17631 invoked by alias); 4 Jan 2012 09:53:28 -0000
Received: (qmail 17593 invoked by uid 22791); 4 Jan 2012 09:53:27 -0000
X-SWARE-Spam-Status: No, hits=-2.9 required=5.0
	tests=AWL,BAYES_00,RP_MATCHES_RCVD
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, 04 Jan 2012 09:53:12 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 9304F2FB084C; Wed,  4 Jan 2012 09:53:11 +0000 (GMT)
X-Original-To: unassigned@bugs.ecos.sourceware.org
Delivered-To: unassigned@bugs.ecos.sourceware.org
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: unassigned@bugs.ecos.sourceware.org
Subject: [Bug 1001442] LPC17XX bit band macro proposal
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: HAL
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: bernard.fouche@kuantic.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
In-Reply-To: <bug-1001442-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001442-777@http.bugs.ecos.sourceware.org/>
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Date: Wed, 04 Jan 2012 09:53:00 -0000
Message-Id: <20120104095310.622D72FB084C@mail.ecoscentric.com>
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
X-SW-Source: 2012/txt/msg00024.txt.bz2
Content-length: 521

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001442

--- Comment #1 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-04 09:53:09 GMT ---
Created an attachment (id=1487)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1487)
bit band macro proposal

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
>From ecos-bugs-return-8596-listarch-ecos-bugs=sources.redhat.com@sourceware.org Wed Jan 04 17:18:56 2012
Return-Path: <ecos-bugs-return-8596-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 14598 invoked by alias); 4 Jan 2012 17:18:53 -0000
Received: (qmail 14584 invoked by uid 22791); 4 Jan 2012 17:18:50 -0000
X-SWARE-Spam-Status: No, hits=-2.9 required=5.0
	tests=AWL,BAYES_00,RP_MATCHES_RCVD
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, 04 Jan 2012 17:18:35 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id E47192F78005; Wed,  4 Jan 2012 17:18:33 +0000 (GMT)
X-Original-To: unassigned@bugs.ecos.sourceware.org
Delivered-To: unassigned@bugs.ecos.sourceware.org
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: unassigned@bugs.ecos.sourceware.org
Subject: [Bug 1001443] New: LPC17XX may be definitely locked if address 0x2FC
 has valid Code Read Protection value
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: HAL
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: bernard.fouche@kuantic.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-1001443-777@http.bugs.ecos.sourceware.org/>
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, 04 Jan 2012 17:18:00 -0000
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
X-SW-Source: 2012/txt/msg00025.txt.bz2
Content-length: 1707

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001443

           Summary: LPC17XX may be definitely locked if address 0x2FC has
                    valid Code Read Protection value
           Product: eCos
           Version: CVS
          Platform: Other (please specify)
        OS/Version: Cortex-M
            Status: UNCONFIRMED
          Severity: major
          Priority: low
         Component: HAL
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: bernard.fouche@kuantic.com
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


See section 32.6 of UM10360: if by lack of luck address 0x2FC holds some
magical value (defined has CRP1, CRP2 and CRP3, respectively 0x12345678,
0x87654321 and 0x43218765) then one may lose access to the MCU.

CRP1: removes JTAG access + add ISP (UART0 programming) limitations
CRP2: CRP1 + more ISP limitations
CRP3: CRP2 + no more ISP unless application makes it available.

It is very possible that some application has one of these magical values
exactly at the wrong place and in case of CRP3 the only solution may be to
replace the MCU.

In my current setup using only FLASH on a LPC1765, 0x2FC is right in the middle
of  main().

I guess the solution is in the linker script (I'm not familiar with it)... one
should also be able to lock the MCU if wanted but this could be done by
eventually adding or modifying data in the .hex/.bin file about to be flashed.

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001442] LPC17XX bit band macro proposal

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001442

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ilijak@siva.com.mk

--- Comment #2 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-06 12:46:56 GMT ---
Perhaps the macros (especially for RAM but others could be considered) could
have generic stem CORTEXM rather than LPC17XX. Could they be applied at
architecture level?

Also, could we consider defining a USER_SECTION for bit-band area? Then we
shall have an easy way to put objects there by just __attribute__ing.
USER_SECTION can be added to present ldi scripts without breaking
compatibility.

-- 
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.

[Bug 1001442] LPC17XX bit band macro proposal

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001442

--- Comment #3 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-10 14:51:19 GMT ---
(In reply to comment #2)
> Perhaps the macros (especially for RAM but others could be considered) could
> have generic stem CORTEXM rather than LPC17XX. Could they be applied at
> architecture level?

I've checked on the ARM site: 

- on Cortex-M3, bit banding is described as a feature always available (the
word 'option' is not used) :
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/Behcjiic.html

- on Cortex-M4, bit banding is described as an optional feature:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439c/Behcjiic.html

eCos uses 'cortex-m' to describe the architecture generally and does not make
difference between M0/M3/M4, etc. Now maybe all chip manufacturers will
implement bit band?

However if bit banding is provided, it's always at the same place, it seems
that it has been designed mostly for peripherals registers or for peripherals
that maps into RAM, like the GPIO pins in the LPC17XX.

> 
> Also, could we consider defining a USER_SECTION for bit-band area? Then we
> shall have an easy way to put objects there by just __attribute__ing.
> USER_SECTION can be added to present ldi scripts without breaking
> compatibility.

This is necessary if one wants to use bit band for RAM, for instance to place
device descriptors or buffers at location that allow bit banding.

-- 
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.
>From ecos-bugs-return-8642-listarch-ecos-bugs=sources.redhat.com@sourceware.org Tue Jan 10 14:51:44 2012
Return-Path: <ecos-bugs-return-8642-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 7018 invoked by alias); 10 Jan 2012 14:51:42 -0000
Received: (qmail 6998 invoked by uid 22791); 10 Jan 2012 14:51:41 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00,T_RP_MATCHES_RCVD
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; Tue, 10 Jan 2012 14:51:28 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 3548C2F78004; Tue, 10 Jan 2012 14:51:27 +0000 (GMT)
X-Original-To: unassigned@bugs.ecos.sourceware.org
Delivered-To: unassigned@bugs.ecos.sourceware.org
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: unassigned@bugs.ecos.sourceware.org
Subject: [Bug 1001442] LPC17XX bit band macro proposal
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: HAL
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: bernard.fouche@kuantic.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
In-Reply-To: <bug-1001442-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001442-777@http.bugs.ecos.sourceware.org/>
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Date: Tue, 10 Jan 2012 14:51:00 -0000
Message-Id: <20120110145124.B09EA2F78003@mail.ecoscentric.com>
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
X-SW-Source: 2012/txt/msg00071.txt.bz2
Content-length: 1753

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001442

--- Comment #3 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-10 14:51:19 GMT ---
(In reply to comment #2)
> Perhaps the macros (especially for RAM but others could be considered) could
> have generic stem CORTEXM rather than LPC17XX. Could they be applied at
> architecture level?

I've checked on the ARM site: 

- on Cortex-M3, bit banding is described as a feature always available (the
word 'option' is not used) :
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/Behcjiic.html

- on Cortex-M4, bit banding is described as an optional feature:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439c/Behcjiic.html

eCos uses 'cortex-m' to describe the architecture generally and does not make
difference between M0/M3/M4, etc. Now maybe all chip manufacturers will
implement bit band?

However if bit banding is provided, it's always at the same place, it seems
that it has been designed mostly for peripherals registers or for peripherals
that maps into RAM, like the GPIO pins in the LPC17XX.

> 
> Also, could we consider defining a USER_SECTION for bit-band area? Then we
> shall have an easy way to put objects there by just __attribute__ing.
> USER_SECTION can be added to present ldi scripts without breaking
> compatibility.

This is necessary if one wants to use bit band for RAM, for instance to place
device descriptors or buffers at location that allow bit banding.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
>From ecos-bugs-return-8645-listarch-ecos-bugs=sources.redhat.com@sourceware.org Tue Jan 10 15:40:58 2012
Return-Path: <ecos-bugs-return-8645-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 25125 invoked by alias); 10 Jan 2012 15:40:57 -0000
Received: (qmail 25118 invoked by uid 22791); 10 Jan 2012 15:40:56 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0
	tests=AWL,BAYES_00,T_RP_MATCHES_RCVD
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; Tue, 10 Jan 2012 15:40:34 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 844EB2F78010; Tue, 10 Jan 2012 15:40:33 +0000 (GMT)
X-Original-To: unassigned@bugs.ecos.sourceware.org
Delivered-To: unassigned@bugs.ecos.sourceware.org
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: unassigned@bugs.ecos.sourceware.org
Subject: [Bug 1001397] I2C driver for Kinetic microcontrollers
X-Bugzilla-Reason: AssignedTo
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: enhancement
X-Bugzilla-Who: tf+bugs.ecos@r-finger.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: Attachment #1443 is obsolete
In-Reply-To: <bug-1001397-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001397-777@http.bugs.ecos.sourceware.org/>
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Date: Tue, 10 Jan 2012 15:40:00 -0000
Message-Id: <20120110154028.02C332F78010@mail.ecoscentric.com>
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
X-SW-Source: 2012/txt/msg00074.txt.bz2
Content-length: 890

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001397

Tomas Frydrych <tf+bugs.ecos@r-finger.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1443|0                           |1
        is obsolete|                            |

--- Comment #10 from Tomas Frydrych <tf+bugs.ecos@r-finger.com> 2012-01-10 15:40:21 GMT ---
Created an attachment (id\x1507)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id\x1507)
Freescale i2c driver

Moved the device driver code under devs/i2c/freescale/i2c and cleaned up the
driver implementation.

--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001442] LPC17XX bit band macro proposal

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001442

--- Comment #4 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-13 15:45:20 GMT ---
(In reply to comment #3)
> (In reply to comment #2)
> > Perhaps the macros (especially for RAM but others could be considered) could
> > have generic stem CORTEXM rather than LPC17XX. Could they be applied at
> > architecture level?
> 
> I've checked on the ARM site: 
> 
> - on Cortex-M3, bit banding is described as a feature always available (the
> word 'option' is not used) :
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/Behcjiic.html
> 
> - on Cortex-M4, bit banding is described as an optional feature:
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439c/Behcjiic.html
> 
> eCos uses 'cortex-m' to describe the architecture generally and does not make
> difference between M0/M3/M4, etc. Now maybe all chip manufacturers will
> implement bit band?
> 

Actually there is info on sub-architecture: CYGHWR_HAL_CORTEXM (in
hal_cortexm.cdl).

> However if bit banding is provided, it's always at the same place, it seems
> that it has been designed mostly for peripherals registers or for peripherals
> that maps into RAM, like the GPIO pins in the LPC17XX.
> 

What I mean is: The macros can be used by every Cortex-M member that implements
bit banding so they should be generic (within Cortex-M) rather than bonded to a
specific product line. Then, they should reside in arch. level header.

> > 
> > Also, could we consider defining a USER_SECTION for bit-band area? Then we
> > shall have an easy way to put objects there by just __attribute__ing.
> > USER_SECTION can be added to present ldi scripts without breaking
> > compatibility.
> 
> This is necessary if one wants to use bit band for RAM, for instance to place
> device descriptors or buffers at location that allow bit banding.

-- 
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.