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] New: LPC17XX bit band macro proposal @ 2012-01-04 9:52 bugzilla-daemon 2012-01-04 9:53 ` [Bug 1001442] " bugzilla-daemon ` (3 more replies) 0 siblings, 4 replies; 7+ messages in thread From: bugzilla-daemon @ 2012-01-04 9:52 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 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. ^ 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
* [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 ` [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 ` (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
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).