This is the mail archive of the
ecos-bugs@sourceware.org
mailing list for the eCos project.
[Bug 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STKplatform
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: unassigned at bugs dot ecos dot sourceware dot org
- Date: Mon, 17 Jan 2011 09:47:34 +0000
- Subject: [Bug 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STKplatform
- Auto-submitted: auto-generated
- References: <bug-1001114-777@http.bugs.ecos.sourceware.org/>
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.