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

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

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.