From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] A bit about board.c, board.c
Date: Sat, 22 Oct 2011 09:17:17 +0200 [thread overview]
Message-ID: <4EA26DFD.2000102@aribaud.net> (raw)
In-Reply-To: <CAPnjgZ0M=+s5V0xuDp-87ePkvQa+-CSk-Y8GPbqYgX=SKJEo4A@mail.gmail.com>
Le 22/10/2011 07:11, Simon Glass a ?crit :
> Hi,
>
> Each architecture has its own board.c but they are mostly quite similar.
>
> New features such as fdt, boot timing, trace, profiling, etc. must be
> done separately for each arch, even if there are no
> architecture-specific bits.
>
> What would you say to adding something like lib/board.c which is a
> simplified cleaned-up copy of one of the existing board.c files, and a
> CONFIG_ARCH_GENERIC_BOARD option to select that in preference to the
> architecture-specific one. Then perhaps people could try it out and we
> could slowly move to it over time...
I'd say anything that factorizes ARM code is a good thing. :)
However I'm not in favor of a CONFIG option that would force the board
code to provide some functions just in odrer to override one, not if
weak definitions can do a finer job. I am looking into that already for
cache management function specialization, and it seems like there is the
same kind of possibility here, with lib functions defined weak and the
board code overriding the ones it deems necessary to.
I will look into it a bit more this morning.
Amicalement,
--
Albert.
next prev parent reply other threads:[~2011-10-22 7:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-22 5:11 [U-Boot] A bit about board.c, board.c Simon Glass
2011-10-22 7:17 ` Albert ARIBAUD [this message]
2011-10-22 16:40 ` Simon Glass
2011-10-23 8:14 ` Wolfgang Denk
2011-11-16 6:45 ` Simon Glass
2011-10-28 18:09 ` Albert ARIBAUD
[not found] ` <CALButCLfLekoJzsnnL_pmxgBERQYdGJFCrhjvsWNvn4_9H_fDw@mail.gmail.com>
[not found] ` <CAPnjgZ2AeXwhR+hAN9UGL1USuvCTtNHjJrXd-cyYRwm_zum6uw@mail.gmail.com>
2011-10-22 21:41 ` Graeme Russ
2011-10-22 21:52 ` Graeme Russ
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=4EA26DFD.2000102@aribaud.net \
--to=albert.u.boot@aribaud.net \
--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