public inbox for ecos-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug 1001442] LPC17XX bit band macro proposal
[not found] <bug-1001442-777@http.bugs.ecos.sourceware.org/>
@ 2012-01-06 12:47 ` bugzilla-daemon
2012-01-13 15:45 ` bugzilla-daemon
2012-01-26 18:32 ` bugzilla-daemon
2 siblings, 0 replies; 7+ messages in thread
From: bugzilla-daemon @ 2012-01-06 12:47 UTC (permalink / raw)
To: unassigned
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 the assignee for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug 1001442] LPC17XX bit band macro proposal
[not found] <bug-1001442-777@http.bugs.ecos.sourceware.org/>
2012-01-06 12:47 ` [Bug 1001442] LPC17XX bit band macro proposal bugzilla-daemon
@ 2012-01-13 15:45 ` bugzilla-daemon
2012-01-26 18:32 ` bugzilla-daemon
2 siblings, 0 replies; 7+ messages in thread
From: bugzilla-daemon @ 2012-01-13 15:45 UTC (permalink / raw)
To: unassigned
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 the assignee for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug 1001442] LPC17XX bit band macro proposal
[not found] <bug-1001442-777@http.bugs.ecos.sourceware.org/>
2012-01-06 12:47 ` [Bug 1001442] LPC17XX bit band macro proposal bugzilla-daemon
2012-01-13 15:45 ` bugzilla-daemon
@ 2012-01-26 18:32 ` bugzilla-daemon
2 siblings, 0 replies; 7+ messages in thread
From: bugzilla-daemon @ 2012-01-26 18:32 UTC (permalink / raw)
To: unassigned
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001442
--- Comment #5 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-26 18:32:19 GMT ---
I did more reading on the topic (chapter 5, page 88 of "The Definitive Guide to
the ARM Cortex-M3" by Joseph Yiu, google, datasheets etc.).
Since gcc doesn't know about bit-band the only real advantage of bitband in our
case seems to replace atomic read-modify-write of a single bit, an operation
that requires today to lock/unlock interrupts and/or DSR execution. This would
be completely different with another compiler knowing about the bitband stuff,
but in that case we would not need to care about bitband ;)
SRAM is a problem: on some MCU, all SRAM can be accessed with bitband ops
(STM32 but I looked only at 1 datasheet of this family:
STM32F105xx/STM32F107xx). On other MCU, only parts of SRAM is eligible
(LPC17XX/Kinetis). This is also the case for any MCU with external RAM.
So bitband accesses for RAM can't be easily defined at the arch level, they
could be defined only at platform level, probably by defining a RAM section
with a specific name and then placing explicitly some variables in this
section. But since accessing the concerned RAM also mean using specific macros,
because gcc knows nothing about bitband so it won't optimize accesses to the
declared region, it's more likely this interest mainly the application, or
drivers specific to a platform so RAM bitband ops can be provided by other
means than the common HAL or arch HAL.
GPIO: they can be mapped to peripheral memory or SRAM. However what to do with
a GPIO pin, once the pin is set as a GPIO pin, is quite simple: have the pin
set to 0 or 1. I didn't look in the datasheets of several modern 32bits MCU,
but if ever, for a MCU, setting a pin state requires a read-modify-write on a
register handling more than one pin, then bitband can also solve a problem I've
seen on smaller MCU: one pin is handled by a thread, another pin on the same
port is used by another thread or an interrupt: any access to the involved pin
port must be atomic. LPC17XX, beside bitband, provides registers that allow
clearing/setting a particular pin without troubling the other pins on the same
port, so in that case bitband isn't interesting. But if one knows of a MCU that
have no such registers, then bitband is an excellent solution because we are
back to the problem of setting a single bit's value atomically.
All in all, the only situation common to any M3/M4 MCU is when accessing a
peripheral register, for operations clearing/setting a single bit, and
especially if updating this bit must be done atomically.
GPIO handling could be done also, but if there is no real need for it...
New proposal (I'm ready to be flamed), higher level macros describe what they
must do, not how they do it:
- common HAL offers:
(I propose the common hal to allow code re-use for drivers while having drivers
unaware of the bitband feature)
- HAL_PERIPHERAL_BIT_SET(address,bit_number,bit_value): set a bit's value in a
peripheral register. Without bit-band it does a read-modify-write sequence with
HAL_READ/WRITE_UINT32(). However since this macro does not provide any real
gain even with bitband ops, it could be avoided.
- HAL_PERIPHERAL_BIT_SET_ATOMIC(ptr_to_lock_function,
ptr_to_unlock_function,
address,
bit_number,
bit_value)
Without bitband, it does the job of HAL_PERIPHERAL_BIT_SET() but bordered
with calls to the lock/unlock function (Function arguments could be removed and
have the macro to always use ISR lock/unlock, or the macro name could state if
it is atomic regarding ISR, DSR or thread, choose whatever fits eCos the most).
- cortex-M HAL (cdl) has interface 'HAL_PERIPHERAL_BITBAND'.
- cortex-M HAL (include) defines bitband macros for peripheral area, so macro
names won't change between different platforms. The peripheral macro could be
what I initially proposed.
- LPC17XX/STM32 and other concerned MCU implement this interface. Platforms
having chips without bitband (M0, M1, M4 without bb option) do not.
- LPC17XX platform also includes SRAM & GPIO macros, to avoid users
re-inventing the wheel (and using different names) if they need the macros.
Kinetis/STM32/Anything users/maintainers choose to do the same or not.
- When 'HAL_PERIPHERAL_BITBAND' is implemented, HAL_PERIPHERAL_BIT_SET{_ATOMIC}
resolve(s) to bitband op(s) in the peripheral area only.
- GPIO / SRAM bitband accesses are let to user code and/or platform specific
drivers.
Bernard
--
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-8723-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Jan 26 18:32:48 2012
Return-Path: <ecos-bugs-return-8723-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 24860 invoked by alias); 26 Jan 2012 18:32:47 -0000
Received: (qmail 24832 invoked by uid 22791); 26 Jan 2012 18:32:46 -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; Thu, 26 Jan 2012 18:32:31 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
by mail.ecoscentric.com (Postfix) with ESMTP id 8021F2F78001
for <ecos-bugs@ecos.sourceware.org>; Thu, 26 Jan 2012 18:32:29 +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 X5xWA7ffHpCF; Thu, 26 Jan 2012 18:32:29 +0000 (GMT)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001442] LPC17XX bit band macro proposal
X-Bugzilla-Reason: CC
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-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001442-13@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: Thu, 26 Jan 2012 18:32:00 -0000
Message-Id: <20120126183226.135672F78006@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/msg00152.txt.bz2
Content-length: 4940
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001442
--- Comment #5 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-26 18:32:19 GMT ---
I did more reading on the topic (chapter 5, page 88 of "The Definitive Guide to
the ARM Cortex-M3" by Joseph Yiu, google, datasheets etc.).
Since gcc doesn't know about bit-band the only real advantage of bitband in our
case seems to replace atomic read-modify-write of a single bit, an operation
that requires today to lock/unlock interrupts and/or DSR execution. This would
be completely different with another compiler knowing about the bitband stuff,
but in that case we would not need to care about bitband ;)
SRAM is a problem: on some MCU, all SRAM can be accessed with bitband ops
(STM32 but I looked only at 1 datasheet of this family:
STM32F105xx/STM32F107xx). On other MCU, only parts of SRAM is eligible
(LPC17XX/Kinetis). This is also the case for any MCU with external RAM.
So bitband accesses for RAM can't be easily defined at the arch level, they
could be defined only at platform level, probably by defining a RAM section
with a specific name and then placing explicitly some variables in this
section. But since accessing the concerned RAM also mean using specific macros,
because gcc knows nothing about bitband so it won't optimize accesses to the
declared region, it's more likely this interest mainly the application, or
drivers specific to a platform so RAM bitband ops can be provided by other
means than the common HAL or arch HAL.
GPIO: they can be mapped to peripheral memory or SRAM. However what to do with
a GPIO pin, once the pin is set as a GPIO pin, is quite simple: have the pin
set to 0 or 1. I didn't look in the datasheets of several modern 32bits MCU,
but if ever, for a MCU, setting a pin state requires a read-modify-write on a
register handling more than one pin, then bitband can also solve a problem I've
seen on smaller MCU: one pin is handled by a thread, another pin on the same
port is used by another thread or an interrupt: any access to the involved pin
port must be atomic. LPC17XX, beside bitband, provides registers that allow
clearing/setting a particular pin without troubling the other pins on the same
port, so in that case bitband isn't interesting. But if one knows of a MCU that
have no such registers, then bitband is an excellent solution because we are
back to the problem of setting a single bit's value atomically.
All in all, the only situation common to any M3/M4 MCU is when accessing a
peripheral register, for operations clearing/setting a single bit, and
especially if updating this bit must be done atomically.
GPIO handling could be done also, but if there is no real need for it...
New proposal (I'm ready to be flamed), higher level macros describe what they
must do, not how they do it:
- common HAL offers:
(I propose the common hal to allow code re-use for drivers while having drivers
unaware of the bitband feature)
- HAL_PERIPHERAL_BIT_SET(address,bit_number,bit_value): set a bit's value in a
peripheral register. Without bit-band it does a read-modify-write sequence with
HAL_READ/WRITE_UINT32(). However since this macro does not provide any real
gain even with bitband ops, it could be avoided.
- HAL_PERIPHERAL_BIT_SET_ATOMIC(ptr_to_lock_function,
ptr_to_unlock_function,
address,
bit_number,
bit_value)
Without bitband, it does the job of HAL_PERIPHERAL_BIT_SET() but bordered
with calls to the lock/unlock function (Function arguments could be removed and
have the macro to always use ISR lock/unlock, or the macro name could state if
it is atomic regarding ISR, DSR or thread, choose whatever fits eCos the most).
- cortex-M HAL (cdl) has interface 'HAL_PERIPHERAL_BITBAND'.
- cortex-M HAL (include) defines bitband macros for peripheral area, so macro
names won't change between different platforms. The peripheral macro could be
what I initially proposed.
- LPC17XX/STM32 and other concerned MCU implement this interface. Platforms
having chips without bitband (M0, M1, M4 without bb option) do not.
- LPC17XX platform also includes SRAM & GPIO macros, to avoid users
re-inventing the wheel (and using different names) if they need the macros.
Kinetis/STM32/Anything users/maintainers choose to do the same or not.
- When 'HAL_PERIPHERAL_BITBAND' is implemented, HAL_PERIPHERAL_BIT_SET{_ATOMIC}
resolve(s) to bitband op(s) in the peripheral area only.
- GPIO / SRAM bitband accesses are let to user code and/or platform specific
drivers.
Bernard
--
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-8724-listarch-ecos-bugs=sources.redhat.com@sourceware.org Fri Jan 27 17:39:10 2012
Return-Path: <ecos-bugs-return-8724-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 21781 invoked by alias); 27 Jan 2012 17:39:08 -0000
Received: (qmail 21673 invoked by uid 22791); 27 Jan 2012 17:39:07 -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; Fri, 27 Jan 2012 17:38:54 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
id C2B332F78001; Fri, 27 Jan 2012 17:38:53 +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 1001466] New: /dev/null serial driver
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: new
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: 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-1001466-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: Fri, 27 Jan 2012 17:39: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/msg00153.txt.bz2
Content-length: 1191
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001466
Summary: /dev/null serial driver
Product: eCos
Version: CVS
Platform: All
OS/Version: All
Status: UNCONFIRMED
Severity: enhancement
Priority: low
Component: Patches and contributions
AssignedTo: unassigned@bugs.ecos.sourceware.org
ReportedBy: bernard.fouche@kuantic.com
CC: ecos-patches@ecos.sourceware.org
Class: Advice Request
Try to mimick /dev/null. (inspired by loop serial driver.)
$ tar tf devnull.tar
null/
null/current/
null/current/cdl/
null/current/cdl/ser_null.cdl
null/current/src/
null/current/src/null_serial.c
null/current/ChangeLog
null/current/doc/
null/current/doc/null_serial.sgml
$
Comments welcome, maybe the semantics aren't close enough to Un*x but it should
do the job for most cases. The doc may need to be rewritten?
Bernard
--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug 1001442] LPC17XX bit band macro proposal
2012-01-04 9:52 [Bug 1001442] New: " bugzilla-daemon
` (2 preceding siblings ...)
2012-01-10 14:51 ` bugzilla-daemon
@ 2012-01-13 15:45 ` bugzilla-daemon
3 siblings, 0 replies; 7+ messages in thread
From: bugzilla-daemon @ 2012-01-13 15:45 UTC (permalink / raw)
To: ecos-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug 1001442] LPC17XX bit band macro proposal
2012-01-04 9:52 [Bug 1001442] New: " bugzilla-daemon
2012-01-04 9:53 ` [Bug 1001442] " bugzilla-daemon
2012-01-06 12:48 ` bugzilla-daemon
@ 2012-01-10 14:51 ` bugzilla-daemon
2012-01-13 15:45 ` bugzilla-daemon
3 siblings, 0 replies; 7+ messages in thread
From: bugzilla-daemon @ 2012-01-10 14:51 UTC (permalink / raw)
To: ecos-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug 1001442] LPC17XX bit band macro proposal
2012-01-04 9:52 [Bug 1001442] New: " bugzilla-daemon
2012-01-04 9:53 ` [Bug 1001442] " bugzilla-daemon
@ 2012-01-06 12:48 ` bugzilla-daemon
2012-01-10 14:51 ` bugzilla-daemon
2012-01-13 15:45 ` bugzilla-daemon
3 siblings, 0 replies; 7+ messages in thread
From: bugzilla-daemon @ 2012-01-06 12:48 UTC (permalink / raw)
To: ecos-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug 1001442] LPC17XX bit band macro proposal
2012-01-04 9:52 [Bug 1001442] New: " bugzilla-daemon
@ 2012-01-04 9:53 ` bugzilla-daemon
2012-01-06 12:48 ` bugzilla-daemon
` (2 subsequent siblings)
3 siblings, 0 replies; 7+ messages in thread
From: bugzilla-daemon @ 2012-01-04 9:53 UTC (permalink / raw)
To: ecos-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-01-26 18:32 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-1001442-777@http.bugs.ecos.sourceware.org/>
2012-01-06 12:47 ` [Bug 1001442] LPC17XX bit band macro proposal bugzilla-daemon
2012-01-13 15:45 ` bugzilla-daemon
2012-01-26 18:32 ` bugzilla-daemon
2012-01-04 9:52 [Bug 1001442] New: " bugzilla-daemon
2012-01-04 9:53 ` [Bug 1001442] " bugzilla-daemon
2012-01-06 12:48 ` bugzilla-daemon
2012-01-10 14:51 ` bugzilla-daemon
2012-01-13 15:45 ` bugzilla-daemon
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).