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

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