[Bug 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[Bug 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ecos-patches@ecos.sourcewar
                   |                            |e.org, john@dallaway.org.uk
          Component|HAL                         |Patches and contributions

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #4 from Ilija Kocho <ilijak@siva.com.mk> 2011-01-16 17:20:11 GMT ---
Note: Respecting Christphe Coutand's comment 
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001117#c1
this port requires small fix.
Now I am working with Christophe's proposal ( Bug 1001090 ), but would like to
have the solution for SysTick source clk selection that will be committed to
eCos tree.

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |1001116

--- Comment #5 from John Dallaway <john@dallaway.org.uk> 2011-01-17 09:47:30 GMT ---
Ilija

It's great to see this contribution. Thank you.

(In reply to comment #0)

> 3. lwIP and LPC17xx AHB memory block(s)
> 
> lwIP makes use of statically allocated memory for buffers and heap (objects
> defined as global static variables). LPC17XX, on the other hand, contains one
> or two AHB memory blocks (16 KiB each) intended for "peripheral use". In order
> to utilize this memory for lwIP usage:
>     - a new memory section ahb_bss is defined
> (include/pkgconf/mlt_cortexm_lpc17xx_inc.ldi);
>     - CDL component "LPC17xx specific memory option" is submitted to lwIP
> memory options by LPC-1766-STK CDL;
>     - lwIP is patched to use special section if one is defined. lwIP patches
> are submitted in a separate bug referenced below.

It's a good idea to allow access to these memory blocks. I would like to ensure
that the implementation is as future proof as possible. A few
questions/observations:

a) Your .ldi files suggest that the two AHB memory blocks are not of equal
size. Is that correct?

b) The use of an extra file mlt_cortex_lpx17xx_inc.ldi to define
SECTION_ahb_bss is not conventional. This memory could also be used as an
additional .data section or even as a raw buffer (not allocated by the linker)
if required. Perhaps the section names should be more generic? Note that
cortex.ld in the architectural HAL defines SECTION_sram. The STM3210E-EVAL
platform HAL uses this to allow access to unused on-chip RAM when eCos is using
external RAM.

c) Are there other Cortex-M variants which provide "peripheral" memory? I
wonder if it would be cleaner to add (for example) SECTION_ahb_sram0 and
SECTION_ahb_sram1 definitions to cortex.ld? Usage would be similar to the
existing SECTION_sram. These sections can be used or ignored by other
variants/platforms.

The above comments are intended for discussion only at present. They should not
be interpreted as a request for changes.

Comments?

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

Sergei Gavrikov <sergei.gavrikov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sergei.gavrikov@gmail.com

--- Comment #6 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-01-17 12:59:05 GMT ---
Hi,

First, Ilija, thank you for your contribution.

[RFC to reviewers]

As NXP does "copy and paste" own "PrimeCell" registers from a design
to design (what is generally speaking is good for programmers) we can
observe the same interference the device drivers  in a code each other
(e.g. lpc2xxx, lpc24xx and now lpc17xx). New Ilija's port for lpc17xx is
a good example such an interference and how the hackers would deal with
"PrimeCell" registers to reuse the code.

Now, if you untar attachment 1184 please, look around

% egrep -R '_LPC(24XX|2XXX)' lpc17xx/

I wonder get comments about such fragments, for example, from lpc17xx
var_io.h:

#define CYGARC_HAL_LPC24XX_REG_UART0_BASE \
    CYGHWR_HAL_LPC17XX_REG_UART0_BASE

#define CYGARC_HAL_LPC2XXX_REG_RTC_BASE  CYGHWR_HAL_LPC17XX_REG_RTC_BASE

etc.

So, the above definitions let us to utilize some generic LPC2XXX,
LPC24XX drivers (see  bug 1001115).

Pros: code reuse, code reuse, code reuse.

Cons: code interference, "difficult" to understand HAL, the bloches of
"foreigners" in the target definition (see attachment 1078).

What do you think, can we be happy with such an interference? What will
be happen if anyone will change some of the lpc2xxx, lpc24xx device
drivers, and vice versa (someone will adopt its code for lpc17xx)? Well,
this can be managed by a forest from the ifdefs, but may be we can just
duplicate the Uwe's drivers code and put such lpc17xx drivers under
devs/{eth,serial,wallclock}/cortextm/lpc17xx?

Well, I see new "Cons" in my proposal: code duplication, code duplication,
code duplication :-) Maybe someone found a better solution? And maybe
my fears are baseless at all? Then forget it, please.

Thanks.

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #7 from Ilija Kocho <ilijak@siva.com.mk> 2011-01-18 00:56:05 GMT ---
Created an attachment (id=1088)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1088)
Provision for user defined sections.

(In reply to comment #5)
> Ilija
> 
> It's great to see this contribution. Thank you.

Thanks for comments and questions John.

> 
> (In reply to comment #0)
> 
> It's a good idea to allow access to these memory blocks. I would like to ensure
> that the implementation is as future proof as possible. A few
> questions/observations:
> 
> a) Your .ldi files suggest that the two AHB memory blocks are not of equal
> size. Is that correct?

Actually they are equal, 16 KiB each (with some chips having only one block). I
dedicated half of AHB_SRAM0 to the Ethernet controller (raw). Original LPC24xx
uses 16KiB for this purpose, but i found out 8 KiB enough for test app. (simple
httpd example server).

 - Could it be possible to slim this down and free more memory for other
peripherals!

 - Also in hal_cortexm_lpc17xx_lpc1766stk.cdl I have restricted lwIP memory in
order to fit within 16 KiB. Could it be possible to fit it within 8 KiB?

> 
> b) The use of an extra file mlt_cortex_lpx17xx_inc.ldi to define
> SECTION_ahb_bss is not conventional. This memory could also be used as an
> additional .data section or even as a raw buffer (not allocated by the linker)
> if required. Perhaps the section names should be more generic? Note that
> cortex.ld in the architectural HAL defines SECTION_sram. The STM3210E-EVAL
> platform HAL uses this to allow access to unused on-chip RAM when eCos is using
> external RAM.
> 

I was actually solving a low memory resource problem when I tested
Ethernet/lwIP
My first attempt was with SECTION_sram. It was working but did memory
allocation for the subject lwIP buffers/heap, producing a large .bin image. Now
the custom section is of NOLOAD type. In lpc17xx_misc.c is the clearing
function.

Your idea for generic section names inspired me to look for generic solution. I
don't know if there is a swiss knife, but today I played little-bit and come to
the working proposal that i am attaching.

> c) Are there other Cortex-M variants which provide "peripheral" memory? I
> wonder if it would be cleaner to add (for example) SECTION_ahb_sram0 and
> SECTION_ahb_sram1 definitions to cortex.ld? Usage would be similar to the
> existing SECTION_sram. These sections can be used or ignored by other
> variants/platforms.

Well, chip designers seem to be creative. For instance Kinetis have 2 equal
SRAM blocks one above, the other below 0x20000000. Good point is that one can
choose to treat them as a single (contiguous) memory pool or not.

IMO the truth is that we shall have to deal with multiple memory blocks one way
or another, so let's look on this as advantage.

For one example, we could address the bit banding. Should we provide sections
for bit band and corresponding bit band alias?

On this subject I would appreciate comments from people with view in other
Cortex-M chips.

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|1001116                     |

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #8 from Ilija Kocho <ilijak@siva.com.mk> 2011-01-18 01:48:19 GMT ---
(In reply to comment #6)
> Hi,
> 
> First, Ilija, thank you for your contribution.

Thanks for the review Sergei.

> 
> [RFC to reviewers]
> 
> As NXP does "copy and paste" own "PrimeCell" registers from a design
> to design (what is generally speaking is good for programmers) we can
> observe the same interference the device drivers  in a code each other
> (e.g. lpc2xxx, lpc24xx and now lpc17xx). New Ilija's port for lpc17xx is
> a good example such an interference and how the hackers would deal with
> "PrimeCell" registers to reuse the code.
> 

[snip]

> 
> Pros: code reuse, code reuse, code reuse.
> 

[snip]

> Cons: code interference, "difficult" to understand HAL, the bloches of
> "foreigners" in the target definition (see attachment 1078 [details]).
> 

[snip]

> Well, I see new "Cons" in my proposal: code duplication, code duplication,
> code duplication :-) Maybe someone found a better solution? And maybe
> my fears are baseless at all? Then forget it, please.

Sergei

I had the same dilemma but I found out that peripherals are so compatible, eCos
so well structured and Uwe's (and other's) work so good that coupling LPC42xx
drivers with LPC17xx went with very little intervention from my side - they
love each other. I merely introduced them by submitting LPC17xx base addresses.
And I think in this case it pays off and should be considered for other
peripherals.
One point: please note that the real UART work is done by generic 16x5x driver
that is shared among myriad of devices and architectures.

I did the opposite for HAL diagnostic drivers by grafting LPC24xx code onto
STM32 template (and taking the credits :) ).

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |1001090, 1001115, 1001116,
                   |                            |1001117

--- Comment #9 from Ilija Kocho <ilijak@siva.com.mk> 2011-01-18 01:59:54 GMT ---
Note to the reviewers:
By acknowledging http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001117#c1 I
rendered the attachment http://bugs.ecos.sourceware.org/attachment.cgi?id=1084
broken. I have a working version with Bug 1001090 applied but i am waiting for
final resolution. Please advise if I should commit current working version.

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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #10 from John Dallaway <john@dallaway.org.uk> 2011-01-18 10:05:47 GMT ---
(In reply to comment #7)

> I was actually solving a low memory resource problem when I tested
> Ethernet/lwIP
> My first attempt was with SECTION_sram. It was working but did memory
> allocation for the subject lwIP buffers/heap, producing a large .bin image.
> Now the custom section is of NOLOAD type. In lpc17xx_misc.c is the clearing
> function.

Ilija, I had missed the significance of the NOLOAD attribute in
mlt_cortex_lpx17xx_inc.ldi.

I will look at your latest attachment...

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #11 from Ilija Kocho <ilijak@siva.com.mk> 2011-01-18 10:45:14 GMT ---
(In reply to comment #10)
> (In reply to comment #7)

> 
> I will look at your latest attachment...

Some brief notes:

   - mlt_cortexm_lpc17xx_inc.ldi - user section macro definition
   - mlt_cortexm_lpc1766_rom.ldi - macro calls (2 sections)
   - lpc17xx_misc.c - macros / function for section initialization
   - hal_cortexm_lpc17xx_lpc1766stk.cdl - provides section name.
   - target.ld - output linker script

This is just a functional model. Some macros are duplicated in
mlt_cortexm_lpc17xx_inc.ldi and lpc17xx_misc.c - this will resolve when we put
them in a header, i guess (but hadn't time to check) pkgconf/hal.h.

I would ask for double check of my usage of concatenation (#) in macros as I am
not very much initiated in it's subtleties.

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #12 from John Dallaway <john@dallaway.org.uk> 2011-01-18 11:04:25 GMT ---
(In reply to comment #6)

> [RFC to reviewers]
> 
> As NXP does "copy and paste" own "PrimeCell" registers from a design
> to design (what is generally speaking is good for programmers) we can
> observe the same interference the device drivers  in a code each other
> (e.g. lpc2xxx, lpc24xx and now lpc17xx). New Ilija's port for lpc17xx is
> a good example such an interference and how the hackers would deal with
> "PrimeCell" registers to reuse the code.
> 
> Now, if you untar attachment 1184 please, look around
> 
> % egrep -R '_LPC(24XX|2XXX)' lpc17xx/
> 
> I wonder get comments about such fragments, for example, from lpc17xx
> var_io.h:
> 
> #define CYGARC_HAL_LPC24XX_REG_UART0_BASE \
>     CYGHWR_HAL_LPC17XX_REG_UART0_BASE
> 
> #define CYGARC_HAL_LPC2XXX_REG_RTC_BASE  CYGHWR_HAL_LPC17XX_REG_RTC_BASE
> 
> etc.
> 
> So, the above definitions let us to utilize some generic LPC2XXX,
> LPC24XX drivers (see  bug 1001115).
> 
> Pros: code reuse, code reuse, code reuse.
> 
> Cons: code interference, "difficult" to understand HAL, the bloches of
> "foreigners" in the target definition (see attachment 1078 [details]).
> 
> What do you think, can we be happy with such an interference? What will
> be happen if anyone will change some of the lpc2xxx, lpc24xx device
> drivers, and vice versa (someone will adopt its code for lpc17xx)? Well,
> this can be managed by a forest from the ifdefs, but may be we can just
> duplicate the Uwe's drivers code and put such lpc17xx drivers under
> devs/{eth,serial,wallclock}/cortextm/lpc17xx?
> 
> Well, I see new "Cons" in my proposal: code duplication, code duplication,
> code duplication :-) Maybe someone found a better solution? And maybe
> my fears are baseless at all? Then forget it, please.

My personal opinion is to favour code re-use in this case. The changes required
to these drivers to support LPC17xx are small. There are already a number of
eCos packages which have an inappropriate name or location in the repository
for historical reasons.

For each affected package, we could optionally change the CDL "display" and
"description" strings and the zeroth package "alias" string in ecos.db
(displayed by configtool) to make them more generic. We should not change any
CDL macro names or the API.

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #13 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-01-18 11:48:09 GMT ---
(In reply to comment #12)

John Dallaway wrote:

> For each affected package, we could optionally change the CDL "display" and
> "description" strings and the zeroth package "alias" string in ecos.db
> (displayed by configtool) to make them more generic. We should not change any
> CDL macro names or the API.

John, thank you for this point! Of course! (I forget about). You dispelled all
my doubts. So, I vote for code re-use. I will repeat eCos mantra again and
again: eCos stands for 'embedded Configurable operating system'.

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

Bug 1001114 depends on bug 1001117, which changed state.

Bug 1001117 Summary: Cortex-M arch. Provision for overriding of VTOR setting.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001117

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |CURRENTRELEASE

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

Bug 1001114 depends on bug 1001090, which changed state.

Bug 1001090 Summary: Added option to run system timer with internal clock
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001090

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |CURRENTRELEASE

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #14 from John Dallaway <john@dallaway.org.uk> 2011-01-25 14:48:36 GMT ---
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #7)
> 
> > 
> > I will look at your latest attachment...
> 
> Some brief notes:
> 
>    - mlt_cortexm_lpc17xx_inc.ldi - user section macro definition
>    - mlt_cortexm_lpc1766_rom.ldi - macro calls (2 sections)
>    - lpc17xx_misc.c - macros / function for section initialization
>    - hal_cortexm_lpc17xx_lpc1766stk.cdl - provides section name.
>    - target.ld - output linker script
> 
> This is just a functional model. Some macros are duplicated in
> mlt_cortexm_lpc17xx_inc.ldi and lpc17xx_misc.c - this will resolve when we put
> them in a header, i guess (but hadn't time to check) pkgconf/hal.h.
> 
> I would ask for double check of my usage of concatenation (#) in macros as I am
> not very much initiated in it's subtleties.

Ilija, I've looked at your user defined sections proposal. A few points for
discussion:

a) I'm still not convinced about placing these macros in a separate
mlt_cortexm_lpc17xx_inc.ldi file. There is nothing specific to LPC17xx in this
file so I think the new macros could go in cortex.ld to be used when relevant
and otherwise ignored.

b) Is it necessary to add the _type_ parameter, or could "(NOLOAD)" be passed
to the SECTION_usr() macro as part of the _vma_ parameter to keep the parameter
list for all SECTION_*() macros consistent?

c) Do we strictly need to implement "zero the bss" behaviour for peripheral
memory? Does lwIP require this? I'm wondering if we can simplify the
implementation by leaving zeroing of the memory section to the user if
necessary? In that case we could have SECTION_user0() and SECTION_user1()
macros which are completely generic, using one of these macros instead of
SECTION_ahb_bss().

Comments?

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #15 from Ilija Kocho <ilijak@siva.com.mk> 2011-01-26 20:14:42 GMT ---
(In reply to comment #14)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > (In reply to comment #7)
> > 
> 
> Ilija, I've looked at your user defined sections proposal. A few points for
> discussion:
> 
> a) I'm still not convinced about placing these macros in a separate
> mlt_cortexm_lpc17xx_inc.ldi file. There is nothing specific to LPC17xx in this
> file so I think the new macros could go in cortex.ld to be used when relevant
> and otherwise ignored.

John, thanks for your comments.

The SECTION_usr() macro, is intended for placement in cortex.ld indeed. I just
forgot to state it explicitly. I am just waiting for conclusion and using
mlt_cortexm_lpc17xx_inc.ldi as a sandbox in meantime.

> 
> b) Is it necessary to add the _type_ parameter, or could "(NOLOAD)" be passed
> to the SECTION_usr() macro as part of the _vma_ parameter to keep the parameter
> list for all SECTION_*() macros consistent?

I agree. Especially since "(NOLOAD)" is the only type value and it is optional.
Changed and tested.

> 
> c) Do we strictly need to implement "zero the bss" behaviour for peripheral
> memory? Does lwIP require this? I'm wondering if we can simplify the
> implementation by leaving zeroing of the memory section to the user if
> necessary? 

I have looked lwIP code briefly and did some tests - it seems that lwIP doesn't
need zeroing. On the other hand zeroing of uninitialized data is a part of C
standard. We could decide either to do the zeroing of lwIP memory or not but I
would keep the SECTION_*() macros defined lpc17xx_misc.c and consider them as
supplement to SECTION_usr() linker macro.
Could we place them in hal_arch.h or hal_io.h?

>In that case we could have SECTION_user0() and SECTION_user1()
> macros which are completely generic, using one of these macros instead of
> SECTION_ahb_bss().

I am little-bit confused with "SECTION_user0() and SECTION_user1()" since the
SECTION_usr() macro that i am proposing accepts section name as parameter. This
is a general solution which can produce as many sections as needed and with
arbitrary names. Names could be general such as user0, user1, but also mnemonic
such as ahb0, ahb_bss or lwip_buf.

Please comment.

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

Bug 1001114 depends on bug 1001116, which changed state.

Bug 1001116 Summary: Instruct lwIP to use special section for buffers and heap.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001116

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |CURRENTRELEASE

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #16 from Ilija Kocho <ilijak@siva.com.mk> 2011-02-01 09:54:16 GMT ---
Now since all system-wide blocking bugs are resolved I am going to check-out
from CVS and produce patch(es) with remaining issues. 

It will include a patch on cortex.ld (comment #5). I could attach the diff here
or open a new bug.

Please advise.

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #17 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-02-01 10:48:23 GMT ---
(In reply to comment #16)
> Now since all system-wide blocking bugs are resolved I am going to check-out
> from CVS and produce patch(es) with remaining issues.
> 
> It will include a patch on cortex.ld (comment #5). I could attach the diff
> here or open a new bug.
> 
> Please advise.

Mine: I would open new bug as it is architecture specific issue, and, perhaps,
it needs in a more wide discussion, ... However, there are many valuable points
by the subject in this (Bug #1001114) report.

John, What is your opinion?

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #18 from John Dallaway <john@dallaway.org.uk> 2011-02-01 11:51:49 GMT ---
(In reply to comment #17)
> (In reply to comment #16)
> > Now since all system-wide blocking bugs are resolved I am going to check-out
> > from CVS and produce patch(es) with remaining issues.
> > 
> > It will include a patch on cortex.ld (comment #5). I could attach the diff
> > here or open a new bug.
> > 
> > Please advise.
> 
> Mine: I would open new bug as it is architecture specific issue, and, perhaps,
> it needs in a more wide discussion, ... However, there are many valuable points
> by the subject in this (Bug #1001114) report.
> 
> John, What is your opinion?

Looking at Ilija's latest mlt_cortexm_lpc17xx_inc.ldi, I am OK with a generic
section macro being added to cortex.ld but without the _type_ parameter:

  #define SECTION_user(_name_, _region_,  _vma_, _lma_)

I think it is clear that this would be sufficiently generic for cortex.ld and
potentially useful in other contexts. I like the idea that this macro will
automatically define __*_start and __*_end symbols. My personal preference
would be to name this "SECTION_user" rather than "SECTION_usr", but it's a
minor point.

I think I would prefer to see the ahb_bss section set up using the
SECTION_user() macro rather than having a separate macro. The HAL author would
take responsibility for zeroing the data (if appropriate) by defining a macro
such as SECTION_CLEAR() or by some other means.

I would vote for adding "SECTION_user(_name_, _region_,  _vma_, _lma_)" in
cortex.ld and elimination of the file mlt_cortexm_lpc17xx_inc.ldi.

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

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

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

--- Comment #19 from Ilija Kocho <ilijak@siva.com.mk> 2011-02-03 17:00:52 GMT ---
Created an attachment (id=1117)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1117)
Updated LPC17xx HAL for review. (Extract in packages/hal.)

Here I submit updated LPC17xx HAL for review.

Notes:

1. User defined sections

SECTION_user() macro definition moved in cortexm.ld (Bug 1001142).

2. Ethernet buffers

Ethernet buffers are placed in user defined section instead in raw memory. This
provides linker control, flexible CDL memory tuning and maximal memory
utilization if this block is placed in same section with lwIP buffers. Section
can be selected with CYGHWR_HAL_LPC_EMAC_MEM_SECTION component in
hal_cortexm_lpc17xx_lpc1766stk.cdl.

3. lwIP memory control

lwIP memory control CYGOPT_LWIP_PLF_MEM_OPT besides section selector contains
sets of memory constrains respective to section selection. There are 3 sets of
constrains corresponding to 3 cases:
  - CYGOPT_LWIP_PLF_MEM_LIMIT_SS0 (Eth and lwIP buffs are in same section)
  - CYGOPT_LWIP_PLF_MEM_LIMIT_SS1 (Eth and lwIP buffs are in different
sections)
  - CYGOPT_LWIP_PLF_MEM_LIMIT_NSS lwIP buffs are not in special section.

Constrains follow behavior proposed by John for Bug 1001125
(http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001125#c17):
   -- Constrains set activation follows lwIP (Eth) section selection.
   -- User can disable active constrains set and do fine tuning manually.

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |1001142

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

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

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

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

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

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

--- Comment #20 from Ilija Kocho <ilijak@siva.com.mk> 2011-02-08 21:09:18 GMT ---
Created an attachment (id=1123)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1123)
LPC17xx HAL for review. (Extract in packages/hal.)

In attachment 1117 (var/current/include/hal_diag.h) appear some names remained
from STM32. Also in lpc17xx_misc.c i forgot to remove the function
hal_section_clear().

This attachment provides corrections and obsoletes 1117.

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

Bug 1001114 depends on bug 1001142, which changed state.

Bug 1001142 Summary: User defined linker sections.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |CURRENTRELEASE

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

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

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

--- Comment #21 from Ilija Kocho <ilijak@siva.com.mk> 2011-02-21 18:10:52 GMT ---
Created an attachment (id=1142)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1142)
LPC17xx HAL compatible with committed USER_SECTION(), for review (Extract in
packages/hal.)

Here I post LPC17xx HAL updated with committed USER_SECTION() naming.

The HAL is tested on Olimex LPC1766-STK both with and without Ethernet/lwIP
support.

lwIP support (simple mode) is tested with 3 USER_SECTION() combinations:

   1. Eth and lwIP buffs in same section - .ahb_sram0;
   2. Eth in .ahb_sram0 and lwIP in .ahb_sram1;
   3. Eth in .ahb_sram0 and lwIP in main memory.

Test application in all 3 cases httpd_simple.c (supplied with lwIP test apps)

Comments welcome.

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

Sergei Gavrikov <sergei.gavrikov@gmail.com> changed:

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

--- Comment #22 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-02-27 16:21:01 GMT ---
Created an attachment (id=1151)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1151)
Cortex-M LPC17XX HAL

A cleaned-up patch is grown from attachment 1142.

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #23 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-02-27 16:56:29 GMT ---
(In reply to comment #21)
...

> Comments welcome.

Hi Ilija,

I submitted 3 patches (HAL/serial/eth) on your contribution

attachment 1151 ( obsolete 1142 )
attachment 1152 ( obsolete 1143 )
attachment 1153 ( obsolete 1144 )

In the most a delta is a monkey work (expanding tabs, removing trailing
spaces, etc., to meet the eCos coding standards). I hope I did break
nothing (I tested a few builds only). Can you please re-test the updated
stuff?  So far I have no comment on the merits and would make sure that
cleaning will not break anything.

Thank you,
Sergei

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #24 from Ilija Kocho <ilijak@siva.com.mk> 2011-02-28 12:46:15 GMT ---
(In reply to comment #23)
> (In reply to comment #21)
> ...
> 
> > Comments welcome.
> 
> Hi Ilija,
> 
> I submitted 3 patches (HAL/serial/eth) on your contribution
> 
> attachment 1151 [details] ( obsolete 1142 )
> attachment 1152 [details] ( obsolete 1143 )
> attachment 1153 [details] ( obsolete 1144 )
> 
> In the most a delta is a monkey work (expanding tabs, removing trailing
> spaces, etc., to meet the eCos coding standards). I hope I did break
> nothing (I tested a few builds only). Can you please re-test the updated
> stuff?  So far I have no comment on the merits and would make sure that
> cleaning will not break anything.
> 
> Thank you,
> Sergei

Sergei, many thanks for your effort. I made some tests and it compiles without
warnings and runs as before with default settings.

However when I try with enabled GDB stubs (CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS),
I get errors that was not case before (see error report bellow).
I don't have much time to test right now as I have to catch the plane to
Nuremberg. Yes it's Embedded World 2011, if anybody else is going I'll be glad
to meet. You can use my email for contact.

CU, Ilija

Here is the error report:

arm-eabi-gcc -c -o ../obj/test_test.o -I../include
-I../../../ecos/default_install/include -Wall -Wpointer-arith
-Wstrict-prototypes -Wundef -Wno-write-strings -mcpu=cortex-m3 -mthumb -g -O2
-ffunction-sections -fdata-sections -fno-exceptions test_test.c
arm-eabi-gcc -c -o ../obj/test_lib.o -I../include
-I../../../ecos/default_install/include -Wall -Wpointer-arith
-Wstrict-prototypes -Wundef -Wno-write-strings -mcpu=cortex-m3 -mthumb -g -O2
-ffunction-sections -fdata-sections -fno-exceptions test_lib.c
arm-eabi-gcc -nostartfiles -L../../../ecos/default_install/lib -Ttarget.ld 
-Xlinker -Map=../bin/test_test.map -o ../bin/test_test.elf ../obj/test_test.o
-mcpu=cortex-m3 -mthumb -Wl,--gc-sections -Wl,-static -Wl,-n -g -nostdlib
../obj/test_lib.o
../../../ecos/default_install/lib/libtarget.a(hal_common_hal_stub.o): In
function `__data_cache':
/home/vae/Proekti/ecos/repo/cvs/110228/ecos/b/packages/hal/common/current/src/hal_stub.c:755:
undefined reference to `HAL_DCACHE_ENABLE'
/home/vae/Proekti/ecos/repo/cvs/110228/ecos/b/packages/hal/common/current/src/hal_stub.c:762:
undefined reference to `HAL_DCACHE_SYNC'
/home/vae/Proekti/ecos/repo/cvs/110228/ecos/b/packages/hal/common/current/src/hal_stub.c:758:
undefined reference to `HAL_DCACHE_DISABLE'
../../../ecos/default_install/lib/libtarget.a(hal_common_hal_stub.o): In
function `__instruction_cache':
/home/vae/Proekti/ecos/repo/cvs/110228/ecos/b/packages/hal/common/current/src/hal_stub.c:724:
undefined reference to `HAL_ICACHE_ENABLE'
/home/vae/Proekti/ecos/repo/cvs/110228/ecos/b/packages/hal/common/current/src/hal_stub.c:731:
undefined reference to `HAL_ICACHE_SYNC'
/home/vae/Proekti/ecos/repo/cvs/110228/ecos/b/packages/hal/common/current/src/hal_stub.c:727:
undefined reference to `HAL_ICACHE_DISABLE'
../../../ecos/default_install/lib/libtarget.a(hal_common_bplist-dynamic.o): In
function `__clear_breakpoint_list':
/home/vae/Proekti/ecos/repo/cvs/110228/ecos/b/packages/hal/common/current/src/bplist-dynamic.c:392:
undefined reference to `HAL_ICACHE_INVALIDATE_ALL'
../../../ecos/default_install/lib/libtarget.a(hal_common_bplist-dynamic.o): In
function `__install_breakpoint_list':
/home/vae/Proekti/ecos/repo/cvs/110228/ecos/b/packages/hal/common/current/src/bplist-dynamic.c:366:
undefined reference to `HAL_ICACHE_SYNC'
collect2: ld returned 1 exit status
make: *** [test_test] Error 1

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #25 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-02-28 13:39:57 GMT ---
(In reply to comment #24)
Ilija Kocho wrote:
...
> when I try with enabled GDB stubs (CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS),
> I get errors that was not case before (see error report bellow)
...
packages/hal/common/current/src/hall_stub.c:755: undefined reference to
`HAL_DCACHE_ENABLE'

Ilija, I'm sorry I will fix it (the cause is that I removed the cache
macros from your HAL :-(

> I don't have much time to test right now as I have to catch the plane
> Nuremberg. Yes it's Embedded World 2011, if anybody else is going
> I'll be glad to meet. You can use my email for contact.

Good luck! Thanks for information.

Sergei

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #26 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-02-28 20:46:55 GMT ---
Created an attachment (id=1156)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1156)
add needed CACHE macros to hal_cache.h

A diff file against Attachment 1151 (tested a build for 'stubs' template).

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #27 from Ilija Kocho <ilijak@siva.com.mk> 2011-03-05 12:33:47 GMT ---
Created an attachment (id=1162)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1162)
Fixed RedBooot memory region list. Incremental patch.

(In reply to comment #26)
> Created an attachment (id=1156)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1156) [details]
> add needed CACHE macros to hal_cache.h
Sergei, 

Thanks for the patch. Now here I submit correction of my bugs. This patch is
incremental.

Fixes:

1) Now is tested with RedBoot too. Previously had forgotten to synchronize
memory region list for RedBoot after i renamed memory regions. 
Question: How much useful is RedBoot on these particular chips.

2) Other changes are a monkey work, I tried to follow you in inactivation of
non implemented stuff. I also re-introduce comments on enabled IO port pins, I
hope now they are more descriptive:
  // Enable pins: TXD1. .. .. .. .. .. RXD0-TXD0 ..
  // Enable pins: .. .. .. .. .RTS1 .DTR1 DSR1-DCD1 CTS1-RXD1
where dots (.) stand for non-enabled pins while names represent selected pin
functionality. Dot's/names are in pairs according to LPC PINSEL register
organization.
Anyway if you think they're not good enough you can remove them.

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #28 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-03-06 18:28:40 GMT ---
(In reply to comment #27)
Hi,

> Now here I submit correction of my bugs. This patch is incremental.

Ilija, thank you for your clean-ups.

> Fixes:
> 
> 1) Now is tested with RedBoot too. Previously had forgotten to synchronize
> memory region list for RedBoot after i renamed memory regions.

> Question: How much useful is RedBoot on these particular chips.

IMO, even if user cannot use RedBoot as a debug infra for the target, it
is great always to have an ability to build ROM monitor and try it. So,
thank you.

> 2) Other changes are a monkey work, I tried to follow you in inactivation of
> non implemented stuff. I also re-introduce comments on enabled IO port pins,
> I hope now they are more descriptive:
>   // Enable pins: TXD1. .. .. .. .. .. RXD0-TXD0 ..
>   // Enable pins: .. .. .. .. .RTS1 .DTR1 DSR1-DCD1 CTS1-RXD1
> where dots (.) stand for non-enabled pins while names represent selected pin
> functionality. Dot's/names are in pairs according to LPC PINSEL register
> organization.

> Anyway if you think they're not good enough you can remove them.

I get it (however, it looks a bit encrypted :-). I have doubts about the
"modem" signals which were turned on by default. Do you really need to
activate them in the statrup code? About comments-memo, I would prefer
to have (diff against your delta)

-    // Enable UART0 and UART1 pins
-
-    // Enable pins: TXD1. .. .. .. .. .. RXD0-TXD0 ..
-    CYGHWR_HAL_LPC17XX_PIN_SET(CYGHWR_HAL_LPC17XX_REG_PINSEL0, 0x40000050);
-
-    // Enable pins: .. .. .. .. .RTS1 .DTR1 DSR1-DCD1 CTS1-RXD1
-    CYGHWR_HAL_LPC17XX_PIN_SET(CYGHWR_HAL_LPC17XX_REG_PINSEL1, 0x00001155);
-
+    // Enable UART0 and UART1
+    CYGHWR_HAL_LPC17XX_PIN_SET(CYGHWR_HAL_LPC17XX_REG_PINSEL0,
+                               (1 /* TXD0 */  << 4) |
+                               (1 /* RXD0 */  << 6) |
+                               (1 /* TXD1 */  << 30)
+        );
+    CYGHWR_HAL_LPC17XX_PIN_SET(CYGHWR_HAL_LPC17XX_REG_PINSEL1,
+                               (1 /* RXD1 */  << 0)
+        );

But, maybe someone will have alternative view (about "modem" signals).

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #29 from Ilija Kocho <ilijak@siva.com.mk> 2011-03-06 20:54:24 GMT ---
(In reply to comment #28)
> (In reply to comment #27)
[snip] 
> I get it (however, it looks a bit encrypted :-). 

I admit :-/

> I have doubts about the
> "modem" signals which were turned on by default. Do you really need to
> activate them in the statrup code? About comments-memo, I would prefer
> to have (diff against your delta)

It's true, the modem signals are used very seldom, but they are wired on the
platform board LPC-17XX-STK so I decided to enable them in order to reflect the
hardware.

However, if it may facilitate application of same platform port on other/custom
boards we can omit them.

For the time being I have no diff to post.
Off topic: I can see that sometimes you make diffs against /dev/null. What diff
option do you use?

> 
> -    // Enable UART0 and UART1 pins
> -
> -    // Enable pins: TXD1. .. .. .. .. .. RXD0-TXD0 ..
> -    CYGHWR_HAL_LPC17XX_PIN_SET(CYGHWR_HAL_LPC17XX_REG_PINSEL0, 0x40000050);
> -
> -    // Enable pins: .. .. .. .. .RTS1 .DTR1 DSR1-DCD1 CTS1-RXD1
> -    CYGHWR_HAL_LPC17XX_PIN_SET(CYGHWR_HAL_LPC17XX_REG_PINSEL1, 0x00001155);
> -
> +    // Enable UART0 and UART1
> +    CYGHWR_HAL_LPC17XX_PIN_SET(CYGHWR_HAL_LPC17XX_REG_PINSEL0,
> +                               (1 /* TXD0 */  << 4) |
> +                               (1 /* RXD0 */  << 6) |
> +                               (1 /* TXD1 */  << 30)
> +        );
> +    CYGHWR_HAL_LPC17XX_PIN_SET(CYGHWR_HAL_LPC17XX_REG_PINSEL1,
> +                               (1 /* RXD1 */  << 0)
> +        );
> 
> But, maybe someone will have alternative view (about "modem" signals).

If you decide against modem signals, pse let me know and eventually attach a
patch so I test it on my board.

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

Sergei Gavrikov <sergei.gavrikov@gmail.com> changed:

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

--- Comment #30 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-03-07 12:20:28 GMT ---
Created an attachment (id=1164)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1164)
add needed CACHE macros to hal_cache.h

$ diffstat cortexm_lpc17xx_20110307-1.diff 
 hal_cache.h |   45 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

To make things easier, replaced by interdiff'ed version (obsoletes Attachment
1156). So, apply it after Attachment 1151 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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

Sergei Gavrikov <sergei.gavrikov@gmail.com> changed:

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

--- Comment #31 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-03-07 12:23:14 GMT ---
Created an attachment (id=1165)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1165)
Fixed RedBoot memory region list, some clean-ups

$ diffstat cortexm_lpc17xx_20110307-2.diff 
 lpc1766stk/current/ChangeLog             |    6 +----
 lpc1766stk/current/src/lpc1766stk_misc.c |   37
+++++++++++++++++++++----------
 var/current/include/lpc17xx_misc.h       |   32 ++++++++++++++++++++------
 3 files changed, 52 insertions(+), 23 deletions(-)

It obsoletes Attachment 1162. Incremental 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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #32 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-03-07 12:43:14 GMT ---
(In reply to comment #29)
> It's true, the modem signals are used very seldom, but they are wired
> on the platform board LPC-17XX-STK so I decided to enable them in
> order to reflect the hardware.

[snip]

> If you decide against modem signals, pse let me know and eventually
> attach a patch so I test it on my board.

Ilija, I leaved your signals and used self-commented lines there (IMO it
is more readable) see Attachment 1165. Please, re-test it and let me
know about results.

[snip]

> Off topic: I can see that sometimes you make diffs against /dev/null.
> What diff option do you use?

Ah, that was filtered out output of hg export on my MQ. To make your
life easier I replaced Attachment 1156 by new one, - Attachment 1164

So, set of HAL patches is

Attachment 1151
Attachment 1164
Attachment 1165

Sergei

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #33 from Ilija Kocho <ilijak@siva.com.mk> 2011-03-07 19:03:59 GMT ---
(In reply to comment #32)

[snip]

> Ilija, I leaved your signals and used self-commented lines there (IMO it
> is more readable) see Attachment 1165 [details]. Please, re-test it and let me
> know about results.

Sergei, Thanks for the patches and descriptive comments. However some OR are
missing in Attachment 1165 (could be corrected in the patch itself):

     CYGHWR_HAL_LPC17XX_PIN_SET(CYGHWR_HAL_LPC17XX_REG_PINSEL1,
-                               (1 /* RXD1 */  << 0)
-                               (1 /* CTS1 */  << 2)
-                               (1 /* DCD1 */  << 4)
-                               (1 /* DSR1 */  << 6)
-                               (1 /* DTR1 */  << 8)
+                               (1 /* RXD1 */  << 0) |
+                               (1 /* CTS1 */  << 2) |
+                               (1 /* DCD1 */  << 4) |
+                               (1 /* DSR1 */  << 6) |
+                               (1 /* DTR1 */  << 8) |
                                (1 /* RTS1 */  << 12)

After correction it compiles without warnings.
Unfortunately I am on a trip again so I haven't been able to test runtime. I am
arranging for remote access to our laboratory for Thursday evening.

I am going to submit patch after runtime test.

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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #34 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-03-07 19:14:37 GMT ---
(In reply to comment #33)
> Sergei, Thanks for the patches and descriptive comments. However some
> OR are missing in Attachment 1165 (could be corrected in the patch
> itself):

[snip]

Ah, I'm sorry about the missings, my c&p :-/, thank you for the catch.

> After correction it compiles without warnings.  Unfortunately I am on
> a trip again so I haven't been able to test runtime. I am arranging
> for remote access to our laboratory for Thursday evening.
> 
> I am going to submit patch after runtime test.

Thank you,
Sergei

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #35 from Ilija Kocho <ilijak@siva.com.mk> 2011-03-10 22:06:20 GMT ---
Created an attachment (id=1170)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1170)
Fixed Fixed RedBoot memory region list, some clean-ups

(In reply to comment #34)
Sergei

Here I submit the corrected patch. It is integral i.e. obsoletes Attachment
1165.

I have applied Attachment 1151 + Attachment 1164 + this one and got LPC17xx
HAL. Compilation performed without warnings when GDB stubs are not enabled (for
GDB stubs and RB see the note below).

Tested with default template + lwIP on LPC-17xx-STK. Also tested RedBoot with
seial ports only. Both serial ports worked with both eCos and RedBoot.
lwIP/Ethernet have been tested with example simple httpd server.


Note: When compiling with GDB stubs and RedBoot some (harmless) warnings appear
from packages out of scope of this port.

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

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

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

--- Comment #36 from Ilija Kocho <ilijak@siva.com.mk> 2011-03-10 22:41:35 GMT ---
Created an attachment (id=1171)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1171)
Fif to Fixed RedBoot memory region list, some clean-ups

Seem incremental patches are prefered so here it is.

This patch is to be added to:

Attachment 1151
Attachment 1164
Attachment 1165

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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #37 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-03-11 07:58:28 GMT ---
Hi Ilija,

(In reply to comment #35)
...
> Tested with default template + lwIP on LPC-17xx-STK. Also tested
> RedBoot with seial ports only. Both serial ports worked with both eCos
> and RedBoot.  lwIP/Ethernet have been tested with example simple httpd
> server.

Thank you very much for the done work (well done).

(In reply to comment #36)
> Created an attachment (id=1171)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1171)
...
> This patch is to be added to:

> Attachment 1151
> Attachment 1164
> Attachment 1165

Just now I tried a few builds with applied

Attachment 1151
Attachment 1164
Attachment 1165 <- some regress here (mine)
Attachment 1171 <- fix previous mess (yours)

I am happy with combined stuff (variant HAL for lpc17xx and target HAL
for Olimex lpc1766stk) and I would freeze this point (if no one has any
claims).

*Minor/optional* (Attachment 1078 -- ecos.db)

Ilija, I would change 'camelCase'-like name for the target in ecos.db,
e.g.

  s/olimexLPC1766stk/olpc1766stk/

The above is just a variant. I mean that in eCos ConfigTool the target's
description looks like: "The olimexLPC1766stk target provides the... "
What do you think? If you want I can replace the Attachment 1078 by new
one.

Thank you,
Sergei

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #38 from Ilija Kocho <ilijak@siva.com.mk> 2011-03-11 09:39:59 GMT ---
Created an attachment (id=1172)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1172)
ecos.db, Some clean-up. Incremental patch to Attachment 1078

(In reply to comment #37)

Sergei

Thanks for review and remarks.
I took a liberty to attach a restyled version. Btw I have also corrected naming
in the target description in order to be consitent with Olimex product naming.

Ilija


> Hi Ilija,
> 
> (In reply to comment #35)
> ...
> > Tested with default template + lwIP on LPC-17xx-STK. Also tested
> > RedBoot with seial ports only. Both serial ports worked with both eCos
> > and RedBoot.  lwIP/Ethernet have been tested with example simple httpd
> > server.
> 
> Thank you very much for the done work (well done).
> 
> (In reply to comment #36)
> > Created an attachment (id=1171)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1171) [details]
> ...
> > This patch is to be added to:
> 
> > Attachment 1151 [details]
> > Attachment 1164 [details]
> > Attachment 1165 [details]
> 
> Just now I tried a few builds with applied
> 
> Attachment 1151 [details]
> Attachment 1164 [details]
> Attachment 1165 [details] <- some regress here (mine)
> Attachment 1171 [details] <- fix previous mess (yours)
> 
> I am happy with combined stuff (variant HAL for lpc17xx and target HAL
> for Olimex lpc1766stk) and I would freeze this point (if no one has any
> claims).
> 
> *Minor/optional* (Attachment 1078 [details] -- ecos.db)
> 
> Ilija, I would change 'camelCase'-like name for the target in ecos.db,
> e.g.
> 
>   s/olimexLPC1766stk/olpc1766stk/
> 
> The above is just a variant. I mean that in eCos ConfigTool the target's
> description looks like: "The olimexLPC1766stk target provides the... "
> What do you think? If you want I can replace the Attachment 1078 [details] by new
> one.

> 
> Thank you,
> Sergei

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

Sergei Gavrikov <sergei.gavrikov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1078|0                           |1
        is obsolete|                            |
   Attachment #1172|0                           |1
        is obsolete|                            |

--- Comment #39 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-03-11 11:18:53 GMT ---
Created an attachment (id=1173)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1173)
ecos.db: new lpc17xx records

(In reply to comment #38)
> Created an attachment (id=1172)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1172) [details]
> ecos.db, Some clean-up. Incremental patch to Attachment 1078 [details]

Thank you.

To make life easier for committers (in any case they use $EDITOR to
change eCos database file) I put the latest changes in one single file
to "yank-and-paste" (original records have been reformatted a bit).

Sergei

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

Bug 1001114 depends on bug 1001115, which changed state.

Bug 1001115 Summary: UART, Ethernet and wallclock driver patches for LPC17XX
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001115

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |CURRENTRELEASE

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #40 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-03-13 15:33:58 GMT ---
Now checked-in.

Ilija, many thanks for your contribution to eCos.

Sergei

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #41 from Ilija Kocho <ilijak@siva.com.mk> 2011-03-13 16:45:05 GMT ---
(In reply to comment #40)
> Now checked-in.
> 
> Ilija, many thanks for your contribution to eCos.
> 
> Sergei

Sergei, John

Lot's of bugs but we finally made it.
Many thanks for your effort, patience and good advices.

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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #42 from John Dallaway <john@dallaway.org.uk> 2011-03-14 11:02:21 GMT ---
Ilija and Sergei, it's great to see LPC17xx support checked-in. Many thanks to
both of you.

One minor issue:

CYGPKG_HAL_CORTEXM_LPC17XX implements the CYGINT_PROFILE_HAL_TIMER interface
but I don't see a profiling ISR in this package. Ilija, are you working on this
or shall I fix the 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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #43 from Ilija Kocho <ilijak@siva.com.mk> 2011-03-14 11:33:08 GMT ---
(In reply to comment #42)
> Ilija and Sergei, it's great to see LPC17xx support checked-in. Many thanks to
> both of you.
> 
> One minor issue:
> 
> CYGPKG_HAL_CORTEXM_LPC17XX implements the CYGINT_PROFILE_HAL_TIMER interface
> but I don't see a profiling ISR in this package. Ilija, are you working on this
> or shall I fix the CDL?

John, thank you for the remark. It is a ghost from CDL that I have used as
template. I am not working on this subject (focus on Kinetis port) so you can
fix the CDL.

Thank you.
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #44 from John Dallaway <john@dallaway.org.uk> 2011-03-14 12:15:23 GMT ---
Created an attachment (id=1174)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1174)
lpc17xx-noprof-110314.patch

Patch to avoid implementing CYGINT_PROFILE_HAL_TIMER for the time being.
Checked-in.

Note: It should be very easy to implement a profiling timer for LPC17xx, based
on the STM32 implementation (patch in bug 1001112).

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |CURRENTRELEASE
         AssignedTo|unassigned@bugs.ecos.source |sergei.gavrikov@gmail.com
                   |ware.org                    |

--- Comment #45 from John Dallaway <john@dallaway.org.uk> 2011-04-15 07:43:47 BST ---
Marking RESOLVED.

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

Pavel Glinskii <glinsky@techart.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |glinsky@techart.ru

--- Comment #46 from Pavel Glinskii <glinsky@techart.ru> 2011-05-12 11:55:09 BST ---
Hello!

Please find ..\lpc17xx\var\current\include\var_intr.h

I guess the definitions:
...
#define CYGNUM_HAL_INTERRUPT_PWM1    (9+CYGNUM_HAL_INTERRUPT_EXTERNAL)
#define CYGNUM_HAL_INTERRUPT_I2C0    (9+CYGNUM_HAL_INTERRUPT_EXTERNAL)
#define CYGNUM_HAL_INTERRUPT_I2C1    (10+CYGNUM_HAL_INTERRUPT_EXTERNAL)
#define CYGNUM_HAL_INTERRUPT_I2C2    (11+CYGNUM_HAL_INTERRUPT_EXTERNAL)
...
should be as follows:
#define CYGNUM_HAL_INTERRUPT_PWM1    (9+CYGNUM_HAL_INTERRUPT_EXTERNAL)
#define CYGNUM_HAL_INTERRUPT_I2C0    (10+CYGNUM_HAL_INTERRUPT_EXTERNAL)
#define CYGNUM_HAL_INTERRUPT_I2C1    (11+CYGNUM_HAL_INTERRUPT_EXTERNAL)
#define CYGNUM_HAL_INTERRUPT_I2C2    (12+CYGNUM_HAL_INTERRUPT_EXTERNAL)

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #47 from Ilija Kocho <ilijak@siva.com.mk> 2011-05-12 13:52:26 BST ---
(In reply to comment #46)
> Hello!
> 
> Please find ..\lpc17xx\var\current\include\var_intr.h
> 
> I guess the definitions:
> ...
> #define CYGNUM_HAL_INTERRUPT_PWM1    (9+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> #define CYGNUM_HAL_INTERRUPT_I2C0    (9+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> #define CYGNUM_HAL_INTERRUPT_I2C1    (10+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> #define CYGNUM_HAL_INTERRUPT_I2C2    (11+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> ...
> should be as follows:
> #define CYGNUM_HAL_INTERRUPT_PWM1    (9+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> #define CYGNUM_HAL_INTERRUPT_I2C0    (10+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> #define CYGNUM_HAL_INTERRUPT_I2C1    (11+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> #define CYGNUM_HAL_INTERRUPT_I2C2    (12+CYGNUM_HAL_INTERRUPT_EXTERNAL)

You guess right Pavel. My fault, sorry.
Can you please raise another bug and produce patch?

Regards
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #48 from Pavel Glinskii <glinsky@techart.ru> 2011-05-12 14:00:06 BST ---
(In reply to comment #47)
> 
> You guess right Pavel. My fault, sorry.
> Can you please raise another bug and produce patch?
> 
> Regards
> Ilija

I'm green hand man regarding eCOS and the bug management sytem.
Do it yourself, please!

-- 
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #49 from Ilija Kocho <ilijak@siva.com.mk> 2011-05-12 14:14:05 BST ---
(In reply to comment #48)
> (In reply to comment #47)
> > 
> > You guess right Pavel. My fault, sorry.
> > Can you please raise another bug and produce patch?
> > 
> > Regards
> > Ilija
> 
> I'm green hand man regarding eCOS and the bug management sytem.
> Do it yourself, please!

No problem. Thanks.
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 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform

[bugzilla-daemon]

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

--- Comment #50 from John Dallaway <john@dallaway.org.uk> 2011-05-13 08:05:28 BST ---
(In reply to comment #47)

> (In reply to comment #46)

> > I guess the definitions:
> > ...
> > #define CYGNUM_HAL_INTERRUPT_PWM1    (9+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> > #define CYGNUM_HAL_INTERRUPT_I2C0    (9+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> > #define CYGNUM_HAL_INTERRUPT_I2C1    (10+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> > #define CYGNUM_HAL_INTERRUPT_I2C2    (11+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> > ...
> > should be as follows:
> > #define CYGNUM_HAL_INTERRUPT_PWM1    (9+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> > #define CYGNUM_HAL_INTERRUPT_I2C0    (10+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> > #define CYGNUM_HAL_INTERRUPT_I2C1    (11+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> > #define CYGNUM_HAL_INTERRUPT_I2C2    (12+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> 
> You guess right Pavel. My fault, sorry.

Pavel, thank you for the report. I've checked in the fix which Ilija has
confirmed.

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