From: Graeme Russ <graeme.russ@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] arm: Add option to disable code relocation
Date: Mon, 06 Feb 2012 19:43:00 +1100 [thread overview]
Message-ID: <4F2F9294.4030805@gmail.com> (raw)
In-Reply-To: <20120206075151.5A1C1193BB41@gemini.denx.de>
Hi Wolfgang,
On 02/06/2012 06:51 PM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <CALButC+==qGs5EaAHtQqU4zEjqvg-3187eWaqU-fv3dWp5QQ7w@mail.gmail.com> you wrote:
>>
>> I think the immediate focus should be on centralising the init sequence
>> processing into /common/init.c and then bringing the new'initcall'
>> architecture online
>
> Agreed.
>
>> Once these have been done, any board can just specific:
>>
>> SKIP_INIT(RELOC)
>
> I will probably object to his, too - for the same reasons.
Considering this is a 'free' artefact of how the init sequence functions,
and that it is board specific and totally non-invasive for anyone else
(i.e. no ugly ifdef's anywhere else in the code) I'm surprised you would
object...
It would be like a board not populated with USB hardware on a arch that
globally defines it saying SKIP_INIT(USB) to avoid linking in the USB
initialisation (maybe not the best example, but you get the point)
Or if a pre-loader initialises SDRAM the board can specify SKIP_INIT(SDRAM)
The point is we can specify a 'standard' set of init 'components' and
boards can trivially disable any of these components as they see fit with
zero impact on any other part of the U-Boot code base
And they can add their own init components, again with zero impact on the
U-Boot code base
Regards,
Graeme
next prev parent reply other threads:[~2012-02-06 8:43 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-05 6:44 [U-Boot] [PATCH] arm: Add option to disable code relocation Simon Glass
2012-02-05 7:39 ` Mike Frysinger
2012-02-05 12:05 ` Marek Vasut
2012-02-05 20:38 ` Mike Frysinger
2012-02-05 21:40 ` Simon Glass
2012-02-05 22:44 ` Wolfgang Denk
2012-02-05 23:23 ` Graeme Russ
2012-02-05 23:32 ` Simon Glass
2012-02-05 23:37 ` Graeme Russ
2012-02-05 23:41 ` Simon Glass
2012-02-05 23:46 ` Graeme Russ
2012-02-07 9:52 ` Graeme Russ
2012-02-06 7:51 ` Wolfgang Denk
2012-02-06 8:43 ` Graeme Russ [this message]
2012-02-06 14:49 ` Tom Rini
2012-02-06 19:27 ` Mike Frysinger
2012-02-06 19:46 ` Tom Rini
2012-02-06 20:25 ` Graeme Russ
2012-02-07 6:41 ` Dirk Behme
2012-02-07 23:23 ` Wolfgang Denk
2012-02-07 23:28 ` Graeme Russ
2012-02-07 23:36 ` Wolfgang Denk
2012-02-07 23:48 ` Graeme Russ
2012-02-08 6:42 ` Dirk Behme
2012-02-08 6:51 ` Dirk Behme
2012-02-08 7:12 ` Simon Glass
2012-02-08 7:16 ` Dirk Behme
2012-02-08 22:05 ` Graeme Russ
2012-02-09 3:38 ` Graeme Russ
2012-02-09 18:30 ` Simon Glass
2012-02-08 14:03 ` Wolfgang Denk
2012-02-06 21:17 ` Albert ARIBAUD
2012-02-06 22:24 ` Wolfgang Denk
2012-02-07 6:51 ` Dirk Behme
2012-02-07 7:25 ` Aneesh V
2012-02-05 23:32 ` Simon Glass
2012-02-05 12:05 ` Marek Vasut
2012-02-05 18:54 ` Wolfgang Denk
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=4F2F9294.4030805@gmail.com \
--to=graeme.russ@gmail.com \
--cc=u-boot@lists.denx.de \
/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