[Bug 1001395] New: LPC1766/LPC17XX .ldi file forgets about IAP RAM usage and NXP flash checksum

[Bug 1001395] New: LPC1766/LPC17XX .ldi file forgets about IAP RAM usage and NXP flash checksum

[bugzilla-daemon]

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

           Summary: LPC1766/LPC17XX .ldi file forgets about IAP RAM usage
                    and NXP flash checksum
           Product: eCos
           Version: 3.0
          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


This problem impacts all LPC17XX target since newer ports to LPC17XX MCU will
probably be based on this file:

- if In Application Programming (IAP) is used, then the upper 32 bytes of
internal RAM are used by the IAP built-in ROM. (section 32.3.2.8 of NXP
document UM10360). This area is ignored in .ram definition.

- There is no consideration about NXP 'Valid User Code' (section 32.3.1.1 of
NXP document UM10360). This is a checksum used by the built-in ROM to validate
the flash content when the MCU boots and is stored at vector location 7 (offset
0x1C). A program like OpenOCD will write this code after flashing the target.
The checksum overwrites the instruction 'b hal_reset_vsr' (the second
instruction of reset_vector).

-- 
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 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage and NXP flash checksum

[bugzilla-daemon]

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

--- Comment #1 from Ilija Kocho <ilijak@siva.com.mk> 2011-12-03 14:00:16 GMT ---
Created an attachment (id=1444)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1444)
Avoid placing code at Vector 7 location on LPC17xx.

(In reply to comment #0)

Thank you for reporting this bug Bernard.

> This problem impacts all LPC17XX target since newer ports to LPC17XX MCU will
> probably be based on this file:
> 
> - if In Application Programming (IAP) is used, then the upper 32 bytes of
> internal RAM are used by the IAP built-in ROM. (section 32.3.2.8 of NXP
> document UM10360). This area is ignored in .ram definition.

This could be fixed with appropriate patch to .ldi file. I think this should be
optional/configurable by a CDL option. But is it likely that IAP will be used
from eCos?

> 
> - There is no consideration about NXP 'Valid User Code' (section 32.3.1.1 of
> NXP document UM10360). This is a checksum used by the built-in ROM to validate
> the flash content when the MCU boots and is stored at vector location 7 (offset
> 0x1C). A program like OpenOCD will write this code after flashing the target.
> The checksum overwrites the instruction 'b hal_reset_vsr' (the second
> instruction of reset_vector).

This is a serious flaw, so I am proposing a patch. It doesn't calculate
checksum (leaves it to flash loader) but brings code out of vector 07 location.
I have set up OpenOcd and did some tests. I would appreciate if someone
re-confirms (both + and - )

Ilija

-- 
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 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage and NXP flash checksum

[bugzilla-daemon]

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

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |john@dallaway.org.uk

--- Comment #2 from John Dallaway <john@dallaway.org.uk> 2011-12-03 14:34:57 GMT ---
(In reply to comment #1)

> (In reply to comment #0)
> 
> > - if In Application Programming (IAP) is used, then the upper 32 bytes of
> > internal RAM are used by the IAP built-in ROM. (section 32.3.2.8 of NXP
> > document UM10360). This area is ignored in .ram definition.
> 
> This could be fixed with appropriate patch to .ldi file. I think this should
> be optional/configurable by a CDL option. But is it likely that IAP will be
> used from eCos?

Some LPC17xx parts have an external memory controller. IAP might then be used
to store application data in the internal flash.

-- 
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 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage and NXP flash checksum

[bugzilla-daemon]

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

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

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

--- Comment #4 from Ilija Kocho <ilijak@siva.com.mk> 2011-12-05 21:20:45 GMT ---
(In reply to comment #2)
> (In reply to comment #1)
> 
> > (In reply to comment #0)
> > 
> > > - if In Application Programming (IAP) is used, then the upper 32 bytes of
> > > internal RAM are used by the IAP built-in ROM. (section 32.3.2.8 of NXP
> > > document UM10360). This area is ignored in .ram definition.
> > 
> > This could be fixed with appropriate patch to .ldi file. I think this should
> > be optional/configurable by a CDL option. But is it likely that IAP will be
> > used from eCos?
> 
> Some LPC17xx parts have an external memory controller. IAP might then be used
> to store application data in the internal flash.

Seem there has been some development at NXP in meantime that is new to me (LPC
is not in my focus recently). However I feel responsible for the mess and I
would prepare patches for this and for other bugs. The question for this one:
Do we give up these 32 bytes for good or make it configurable?

And since there are many things to fix (revisiting LPC17xx I found some bugs
too) :( what would be preferable: to prepare a separate fix for every bug or
one big patch?

-- 
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 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage and NXP flash checksum

[bugzilla-daemon]

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

--- Comment #5 from Bernard Fouché <bernard.fouche@kuantic.com> 2011-12-06 11:21:01 GMT ---
(In reply to comment #4)
>[snip]
> Seem there has been some development at NXP in meantime that is new to me (LPC
> is not in my focus recently). However I feel responsible for the mess and I
> would prepare patches for this and for other bugs. The question for this one:
> Do we give up these 32 bytes for good or make it configurable?
> 
> And since there are many things to fix (revisiting LPC17xx I found some bugs
> too) :( what would be preferable: to prepare a separate fix for every bug or
> one big patch?

I would vote for separate bug entries, even if they all point to a single patch
(to ease bug search/tracking with bugzilla)

I've to do the FSF paperwork for a colleague and I, and we'll contribute:

- hardware watchdog
- spi driver
- CAN driver (derived of course from LPC2XXX)
- spansion S25FLxxx
- revisited lpx17xxx_misc.c/cdl (making USB clock generation as an
option,CLKOUT as an option, complete disconnection of PLL, SPP clocks as
options,should be extended to everything that clocks :-))

Expect these for Q1-2012. We are basing our new product line on the LPC, so we
should keep working on the LPC for the next years.

I'll also open a bug/discussion about power management since the LPC allow fine
tuning of power, including generic peripherals like the 16x5x driver and some
solution must be found to add power management everywhere.

-- 
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-8476-listarch-ecos-bugs=sources.redhat.com@sourceware.org Tue Dec 06 11:21:37 2011
Return-Path: <ecos-bugs-return-8476-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 19983 invoked by alias); 6 Dec 2011 11:21:36 -0000
Received: (qmail 19966 invoked by uid 22791); 6 Dec 2011 11:21:35 -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; Tue, 06 Dec 2011 11:21:13 +0000
Received: from localhost (hagrid.ecoscentric.com [127.0.0.1])
	by mail.ecoscentric.com (Postfix) with ESMTP id 826242FB0827
	for <ecos-bugs@ecos.sourceware.org>; Tue,  6 Dec 2011 11:21:12 +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 0PTXLBlnKCly; Tue,  6 Dec 2011 11:21:12 +0000 (GMT)
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-bugs@ecos.sourceware.org
Subject: [Bug 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage
 and NXP flash checksum
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: 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:
In-Reply-To: <bug-1001395-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001395-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: Tue, 06 Dec 2011 11:21:00 -0000
Message-Id: <20111206112108.03DA72F7800C@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: 2011/txt/msg01386.txt.bz2
Content-length: 1783

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

--- Comment #5 from Bernard Fouché <bernard.fouche@kuantic.com> 2011-12-06 11:21:01 GMT ---
(In reply to comment #4)
>[snip]
> Seem there has been some development at NXP in meantime that is new to me (LPC
> is not in my focus recently). However I feel responsible for the mess and I
> would prepare patches for this and for other bugs. The question for this one:
> Do we give up these 32 bytes for good or make it configurable?
> 
> And since there are many things to fix (revisiting LPC17xx I found some bugs
> too) :( what would be preferable: to prepare a separate fix for every bug or
> one big patch?

I would vote for separate bug entries, even if they all point to a single patch
(to ease bug search/tracking with bugzilla)

I've to do the FSF paperwork for a colleague and I, and we'll contribute:

- hardware watchdog
- spi driver
- CAN driver (derived of course from LPC2XXX)
- spansion S25FLxxx
- revisited lpx17xxx_misc.c/cdl (making USB clock generation as an
option,CLKOUT as an option, complete disconnection of PLL, SPP clocks as
options,should be extended to everything that clocks :-))

Expect these for Q1-2012. We are basing our new product line on the LPC, so we
should keep working on the LPC for the next years.

I'll also open a bug/discussion about power management since the LPC allow fine
tuning of power, including generic peripherals like the 16x5x driver and some
solution must be found to add power management everywhere.

-- 
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-8478-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Dec 08 08:09:30 2011
Return-Path: <ecos-bugs-return-8478-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 14498 invoked by alias); 8 Dec 2011 08:09:29 -0000
Received: (qmail 14475 invoked by uid 22791); 8 Dec 2011 08:09:27 -0000
X-SWARE-Spam-Status: No, hits=-2.5 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; Thu, 08 Dec 2011 08:09:13 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id C8E972F7800D; Thu,  8 Dec 2011 08:09: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 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage
 and NXP flash checksum
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: major
X-Bugzilla-Who: ilijak@siva.com.mk
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-1001395-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001395-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: Thu, 08 Dec 2011 08:09:00 -0000
Message-Id: <20111208080907.D0BB42F78009@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: 2011/txt/msg01388.txt.bz2
Content-length: 2151

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

--- Comment #6 from Ilija Kocho <ilijak@siva.com.mk> 2011-12-08 08:09:02 GMT ---
(In reply to comment #5)
> (In reply to comment #4)
> >[snip]
> > Seem there has been some development at NXP in meantime that is new to me (LPC
> > is not in my focus recently). However I feel responsible for the mess and I
> > would prepare patches for this and for other bugs. The question for this one:
> > Do we give up these 32 bytes for good or make it configurable?
> >
> > And since there are many things to fix (revisiting LPC17xx I found some bugs
> > too) :( what would be preferable: to prepare a separate fix for every bug or
> > one big patch?
>
> I would vote for separate bug entries, even if they all point to a single patch
> (to ease bug search/tracking with bugzilla)

OK, then we'll go one by one.

>
> I've to do the FSF paperwork for a colleague and I, and we'll contribute:
>
> - hardware watchdog
> - spi driver
> - CAN driver (derived of course from LPC2XXX)
> - spansion S25FLxxx
> - revisited lpx17xxx_misc.c/cdl (making USB clock generation as an
> option,CLKOUT as an option, complete disconnection of PLL, SPP clocks as
> options,should be extended to everything that clocks :-))

Welcome. Than LPC17xx port has good prospect for development.
Regarding John's note for devices with external memory, I would recommend to
enable ext. memory too.

>
> Expect these for Q1-2012. We are basing our new product line on the LPC, so we
> should keep working on the LPC for the next years.

I am on a trip this and next week so my time and ability for testing are
little-bit limited but I'll try to prepare the patches.

>
> I'll also open a bug/discussion about power management since the LPC allow fine
> tuning of power, including generic peripherals like the 16x5x driver and some
> solution must be found to add power management everywhere.

--
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 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage and NXP flash checksum

[bugzilla-daemon]

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

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

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

--- Comment #7 from Ilija Kocho <ilijak@siva.com.mk> 2011-12-22 09:31:35 GMT ---
Created an attachment (id=1477)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1477)
Fix IAP and Vector 7 bug.

Provided patch should fix both issues. IAP option is configurable by CDL.

-- 
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 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage and NXP flash checksum

[bugzilla-daemon]

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

--- Comment #9 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-16 00:10:23 GMT ---
*** Bug 1001443 has been marked as a duplicate of this bug. ***

-- 
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 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage and NXP flash checksum

[bugzilla-daemon]

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

--- Comment #10 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-24 12:58:42 GMT ---
Finally I got opportunity to test it. Works on Olimex LPC-1766-STK.
If there aren't remarks I am going to commit.
Ilija

-- 
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 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage and NXP flash checksum

[bugzilla-daemon]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |CURRENTRELEASE

--- Comment #11 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-24 19:46:53 GMT ---
Checked in.

-- 
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 1001395] New: LPC1766/LPC17XX .ldi file forgets about IAP RAM usage and NXP flash checksum

[bugzilla-daemon]

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

           Summary: LPC1766/LPC17XX .ldi file forgets about IAP RAM usage
                    and NXP flash checksum
           Product: eCos
           Version: 3.0
          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


This problem impacts all LPC17XX target since newer ports to LPC17XX MCU will
probably be based on this file:

- if In Application Programming (IAP) is used, then the upper 32 bytes of
internal RAM are used by the IAP built-in ROM. (section 32.3.2.8 of NXP
document UM10360). This area is ignored in .ram definition.

- There is no consideration about NXP 'Valid User Code' (section 32.3.1.1 of
NXP document UM10360). This is a checksum used by the built-in ROM to validate
the flash content when the MCU boots and is stored at vector location 7 (offset
0x1C). A program like OpenOCD will write this code after flashing the target.
The checksum overwrites the instruction 'b hal_reset_vsr' (the second
instruction of reset_vector).

-- 
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 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage and NXP flash checksum

[bugzilla-daemon]

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

--- Comment #1 from Ilija Kocho <ilijak@siva.com.mk> 2011-12-03 14:00:16 GMT ---
Created an attachment (id=1444)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1444)
Avoid placing code at Vector 7 location on LPC17xx.

(In reply to comment #0)

Thank you for reporting this bug Bernard.

> This problem impacts all LPC17XX target since newer ports to LPC17XX MCU will
> probably be based on this file:
> 
> - if In Application Programming (IAP) is used, then the upper 32 bytes of
> internal RAM are used by the IAP built-in ROM. (section 32.3.2.8 of NXP
> document UM10360). This area is ignored in .ram definition.

This could be fixed with appropriate patch to .ldi file. I think this should be
optional/configurable by a CDL option. But is it likely that IAP will be used
from eCos?

> 
> - There is no consideration about NXP 'Valid User Code' (section 32.3.1.1 of
> NXP document UM10360). This is a checksum used by the built-in ROM to validate
> the flash content when the MCU boots and is stored at vector location 7 (offset
> 0x1C). A program like OpenOCD will write this code after flashing the target.
> The checksum overwrites the instruction 'b hal_reset_vsr' (the second
> instruction of reset_vector).

This is a serious flaw, so I am proposing a patch. It doesn't calculate
checksum (leaves it to flash loader) but brings code out of vector 07 location.
I have set up OpenOcd and did some tests. I would appreciate if someone
re-confirms (both + and - )

Ilija

-- 
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 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage and NXP flash checksum

[bugzilla-daemon]

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

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |john@dallaway.org.uk

--- Comment #2 from John Dallaway <john@dallaway.org.uk> 2011-12-03 14:34:57 GMT ---
(In reply to comment #1)

> (In reply to comment #0)
> 
> > - if In Application Programming (IAP) is used, then the upper 32 bytes of
> > internal RAM are used by the IAP built-in ROM. (section 32.3.2.8 of NXP
> > document UM10360). This area is ignored in .ram definition.
> 
> This could be fixed with appropriate patch to .ldi file. I think this should
> be optional/configurable by a CDL option. But is it likely that IAP will be
> used from eCos?

Some LPC17xx parts have an external memory controller. IAP might then be used
to store application data in the internal flash.

-- 
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 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage and NXP flash checksum

[bugzilla-daemon]

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

--- Comment #3 from Bernard Fouché <bernard.fouche@kuantic.com> 2011-12-05 09:00:34 GMT ---
(In reply to comment #2)
> (In reply to comment #1)
> 
> > (In reply to comment #0)
> > 
> > > - if In Application Programming (IAP) is used, then the upper 32 bytes of
> > > internal RAM are used by the IAP built-in ROM. (section 32.3.2.8 of NXP
> > > document UM10360). This area is ignored in .ram definition.
> > 
> > This could be fixed with appropriate patch to .ldi file. I think this should
> > be optional/configurable by a CDL option. But is it likely that IAP will be
> > used from eCos?
> 
> Some LPC17xx parts have an external memory controller. IAP might then be used
> to store application data in the internal flash.

Any bootloader that writes into internal FLASH must use IAP: we have detected
this issue while writing an eCos based bootloader, even if we have no external
RAM on our target (LPC1765 has no external memory controller). Beside Ethernet,
there are CAN buses, UART, etc. that can be used to update the internal FLASH.

Thanks for the patch regarding the Valid User Code area!

-- 
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-8465-listarch-ecos-bugs=sources.redhat.com@sourceware.org Mon Dec 05 09:01:02 2011
Return-Path: <ecos-bugs-return-8465-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 19246 invoked by alias); 5 Dec 2011 09:01:01 -0000
Received: (qmail 19234 invoked by uid 22791); 5 Dec 2011 09:01:01 -0000
X-SWARE-Spam-Status: No, hits=-2.5 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; Mon, 05 Dec 2011 09:00:43 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 8EFEA2F78005; Mon,  5 Dec 2011 09:00:42 +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 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage
 and NXP flash checksum
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: 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:
In-Reply-To: <bug-1001395-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001395-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: Mon, 05 Dec 2011 09:01:00 -0000
Message-Id: <20111205090039.261292F78005@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: 2011/txt/msg01375.txt.bz2
Content-length: 1433

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

--- Comment #3 from Bernard Fouché <bernard.fouche@kuantic.com> 2011-12-05 09:00:34 GMT ---
(In reply to comment #2)
> (In reply to comment #1)
> 
> > (In reply to comment #0)
> > 
> > > - if In Application Programming (IAP) is used, then the upper 32 bytes of
> > > internal RAM are used by the IAP built-in ROM. (section 32.3.2.8 of NXP
> > > document UM10360). This area is ignored in .ram definition.
> > 
> > This could be fixed with appropriate patch to .ldi file. I think this should
> > be optional/configurable by a CDL option. But is it likely that IAP will be
> > used from eCos?
> 
> Some LPC17xx parts have an external memory controller. IAP might then be used
> to store application data in the internal flash.

Any bootloader that writes into internal FLASH must use IAP: we have detected
this issue while writing an eCos based bootloader, even if we have no external
RAM on our target (LPC1765 has no external memory controller). Beside Ethernet,
there are CAN buses, UART, etc. that can be used to update the internal FLASH.

Thanks for the patch regarding the Valid User Code area!

-- 
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-8468-listarch-ecos-bugs=sources.redhat.com@sourceware.org Mon Dec 05 09:30:19 2011
Return-Path: <ecos-bugs-return-8468-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 32397 invoked by alias); 5 Dec 2011 09:30:18 -0000
Received: (qmail 32367 invoked by uid 22791); 5 Dec 2011 09:30:16 -0000
X-SWARE-Spam-Status: No, hits=-2.5 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; Mon, 05 Dec 2011 09:29:59 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id 64B942F78005; Mon,  5 Dec 2011 09:29:58 +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 1001407] New: lpc17xx_misc.h does not define
 CYNUM_HAL_LPC17XX_PCLK_SSP0
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: 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-1001407-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: Mon, 05 Dec 2011 09:30: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: 2011/txt/msg01378.txt.bz2
Content-length: 966

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

           Summary: lpc17xx_misc.h does not define
                    CYNUM_HAL_LPC17XX_PCLK_SSP0
           Product: eCos
           Version: CVS
          Platform: Other (please specify)
        OS/Version: Other
            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


CYNUM_HAL_LPC17XX_PCLK_SSP0 is listed as not implemented on LPC17XX, while it
is implemented on these MCU, and its clocking can be changed in PCKLSEL1.

--
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 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage and NXP flash checksum

[bugzilla-daemon]

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

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

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

--- Comment #4 from Ilija Kocho <ilijak@siva.com.mk> 2011-12-05 21:20:45 GMT ---
(In reply to comment #2)
> (In reply to comment #1)
> 
> > (In reply to comment #0)
> > 
> > > - if In Application Programming (IAP) is used, then the upper 32 bytes of
> > > internal RAM are used by the IAP built-in ROM. (section 32.3.2.8 of NXP
> > > document UM10360). This area is ignored in .ram definition.
> > 
> > This could be fixed with appropriate patch to .ldi file. I think this should
> > be optional/configurable by a CDL option. But is it likely that IAP will be
> > used from eCos?
> 
> Some LPC17xx parts have an external memory controller. IAP might then be used
> to store application data in the internal flash.

Seem there has been some development at NXP in meantime that is new to me (LPC
is not in my focus recently). However I feel responsible for the mess and I
would prepare patches for this and for other bugs. The question for this one:
Do we give up these 32 bytes for good or make it configurable?

And since there are many things to fix (revisiting LPC17xx I found some bugs
too) :( what would be preferable: to prepare a separate fix for every bug or
one big patch?

-- 
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 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage and NXP flash checksum

[bugzilla-daemon]

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

--- Comment #6 from Ilija Kocho <ilijak@siva.com.mk> 2011-12-08 08:09:02 GMT ---
(In reply to comment #5)
> (In reply to comment #4)
> >[snip]
> > Seem there has been some development at NXP in meantime that is new to me (LPC
> > is not in my focus recently). However I feel responsible for the mess and I
> > would prepare patches for this and for other bugs. The question for this one:
> > Do we give up these 32 bytes for good or make it configurable?
> > 
> > And since there are many things to fix (revisiting LPC17xx I found some bugs
> > too) :( what would be preferable: to prepare a separate fix for every bug or
> > one big patch?
> 
> I would vote for separate bug entries, even if they all point to a single patch
> (to ease bug search/tracking with bugzilla)

OK, then we'll go one by one.

> 
> I've to do the FSF paperwork for a colleague and I, and we'll contribute:
> 
> - hardware watchdog
> - spi driver
> - CAN driver (derived of course from LPC2XXX)
> - spansion S25FLxxx
> - revisited lpx17xxx_misc.c/cdl (making USB clock generation as an
> option,CLKOUT as an option, complete disconnection of PLL, SPP clocks as
> options,should be extended to everything that clocks :-))

Welcome. Than LPC17xx port has good prospect for development.
Regarding John's note for devices with external memory, I would recommend to
enable ext. memory too.

> 
> Expect these for Q1-2012. We are basing our new product line on the LPC, so we
> should keep working on the LPC for the next years.

I am on a trip this and next week so my time and ability for testing are
little-bit limited but I'll try to prepare the patches.

> 
> I'll also open a bug/discussion about power management since the LPC allow fine
> tuning of power, including generic peripherals like the 16x5x driver and some
> solution must be found to add power management everywhere.

-- 
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 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage and NXP flash checksum

[bugzilla-daemon]

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

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

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

--- Comment #7 from Ilija Kocho <ilijak@siva.com.mk> 2011-12-22 09:31:35 GMT ---
Created an attachment (id=1477)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1477)
Fix IAP and Vector 7 bug.

Provided patch should fix both issues. IAP option is configurable by CDL.

-- 
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 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage and NXP flash checksum

[bugzilla-daemon]

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

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

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

--- Comment #8 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-16 00:02:22 GMT ---
Created an attachment (id=1518)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1518)
Fix IAP and Vector 7 bug and CRP [Bug 1001443]

This patch provides integral fix for IAP and Vector 7 from this Bug as well as
Code Read Protection [Bug 1001443].

Bernard
I am not able to test this patch at the moment. I would appreciate if you test
it. Then if you are happy we could proceed with check in.

Ilija

-- 
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 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage and NXP flash checksum

[bugzilla-daemon]

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

--- Comment #9 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-16 00:10:23 GMT ---
*** Bug 1001443 has been marked as a duplicate of this bug. ***

-- 
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 1001395] LPC1766/LPC17XX .ldi file forgets about IAP RAM usage and NXP flash checksum

[bugzilla-daemon]

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

--- Comment #10 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-24 12:58:42 GMT ---
Finally I got opportunity to test it. Works on Olimex LPC-1766-STK.
If there aren't remarks I am going to commit.
Ilija

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