public inbox for ecos-patches@sourceware.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-patches@ecos.sourceware.org
Subject: [Bug 1001114] New port: NXP LPC17XX Variant, Olimex LPC-1766-STK platform
Date: Tue, 25 Jan 2011 14:48:00 -0000	[thread overview]
Message-ID: <20110125144842.B63F02F78004@mail.ecoscentric.com> (raw)
In-Reply-To: <bug-1001114-104@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

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

  parent reply	other threads:[~2011-01-25 14:48 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-1001114-104@http.bugs.ecos.sourceware.org/>
2011-01-16  8:52 ` bugzilla-daemon
2011-01-16 17:20 ` bugzilla-daemon
2011-01-17  9:47 ` bugzilla-daemon
2011-01-17 12:59 ` bugzilla-daemon
2011-01-18  0:56 ` bugzilla-daemon
2011-01-18  1:43 ` bugzilla-daemon
2011-01-18  1:48 ` bugzilla-daemon
2011-01-18  2:00 ` bugzilla-daemon
2011-01-18 10:06 ` bugzilla-daemon
2011-01-18 10:45 ` bugzilla-daemon
2011-01-18 11:04 ` bugzilla-daemon
2011-01-18 11:48 ` bugzilla-daemon
2011-01-19 19:02 ` bugzilla-daemon
2011-01-22 21:22 ` bugzilla-daemon
2011-01-25 14:48 ` bugzilla-daemon [this message]
2011-01-26 20:15 ` bugzilla-daemon
2011-01-31 21:57 ` bugzilla-daemon
2011-02-01  9:54 ` bugzilla-daemon
2011-02-01 10:48 ` bugzilla-daemon
2011-02-01 11:52 ` bugzilla-daemon
2011-02-03 17:01 ` bugzilla-daemon
2011-02-03 17:02 ` bugzilla-daemon
2011-02-03 17:08 ` bugzilla-daemon
2011-02-08 21:09 ` bugzilla-daemon
2011-02-17 14:19 ` bugzilla-daemon
2011-02-21 18:11 ` bugzilla-daemon
2011-02-27 16:21 ` bugzilla-daemon
2011-02-27 16:56 ` bugzilla-daemon
2011-02-28 12:46 ` bugzilla-daemon
2011-02-28 13:40 ` bugzilla-daemon
2011-02-28 20:47 ` bugzilla-daemon
2011-03-05 12:34 ` bugzilla-daemon
2011-03-06 18:29 ` bugzilla-daemon
2011-03-06 20:54 ` bugzilla-daemon
2011-03-07 12:20 ` bugzilla-daemon
2011-03-07 12:23 ` bugzilla-daemon
2011-03-07 12:43 ` bugzilla-daemon
2011-03-07 19:04 ` bugzilla-daemon
2011-03-07 19:14 ` bugzilla-daemon
2011-03-10 22:06 ` bugzilla-daemon
2011-03-10 22:41 ` bugzilla-daemon
2011-03-11  7:58 ` bugzilla-daemon
2011-03-11  9:40 ` bugzilla-daemon
2011-03-11 11:19 ` bugzilla-daemon
2011-03-13 14:24 ` bugzilla-daemon
2011-03-13 15:34 ` bugzilla-daemon
2011-03-13 16:45 ` bugzilla-daemon
2011-03-14 11:02 ` bugzilla-daemon
2011-03-14 11:33 ` bugzilla-daemon
2011-03-14 12:15 ` bugzilla-daemon
2011-04-15  6:44 ` bugzilla-daemon
2011-05-12 10:56 ` bugzilla-daemon
2011-05-12 12:53 ` bugzilla-daemon
2011-05-12 13:00 ` bugzilla-daemon
2011-05-12 13:15 ` bugzilla-daemon
2011-05-13  7:05 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110125144842.B63F02F78004@mail.ecoscentric.com \
    --to=bugzilla-daemon@bugs.ecos.sourceware.org \
    --cc=ecos-patches@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).