This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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 the assignee for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]