Le 30/11/2011 00:40, Simon Glass a écrit :
Hi Mike,
On Tue, Nov 29, 2011 at 3:19 PM, Mike Frysinger<vap...@gentoo.org> wrote:
On Tuesday 29 November 2011 17:09:19 Simon Glass wrote:
On Tue, Nov 29, 2011 at 1:40 PM, Mike Frysinger wrote:
On Tuesday 29 November 2011 15:08:09 Simon Glass wrote:
On Mon, Nov 28, 2011 at 7:11 PM, Mike Frysinger wrote:
On Monday 21 November 2011 18:57:54 Simon Glass wrote:
We are introducing a new unified board setup and we want this to
be the default. So we need to opt all architectures out first.
the define says "BOARD", so shouldn't it be in board configs ? we can
do that easily: add it to include/config_defaults.h. then boards
that opt into it will #undef it in their own configs.
Thanks for looking at this.
I see this as an architecture feature - perhaps a rename to something
like CONFIG_LEGACY_ARCH would help? I quite badly want to avoid moving
boards over one at a time, or having boards for a particular
architecture that still do things the old way - it just increases
maintenance and means that my eventual patch to remove
arch/xxx/lib/board.c cannot be applied.
My idea for this CONFIG is purely as a temporary measure before boards
more over to the generic approach.
how about we have the reloc code live in lib/reloc/ and be controlled by
CONFIG_LEGACY_ARCH_RELOC ?
My only concern is that if something like SPL needs to keep all the
early code at the start of the image. I personally don't like the
current method for doing that (would prefer a distinctive .text.early
section name) and I don't believe that any SPL implementation actually
relocates itself.
not sure why this matters ?
-mike
Because if they require linking with reloc.o then we will get link
failures some boards. There is some ugly stuff in SPL which pulls in
particular files from around U-Boot. Any time I split something out of
start.S I may break something.
IIRC, SPL never relocates itself -- the goal of SPL is to get some code
in memory that will just enable RAM, move the rest of U-Boot in, and
jump to it.
What SPL pulls in is drivers/ functions for console output and access to
the RAM and main U-Boot image.
Besides, sometimes making boards all fail until they are fixed is a good
way to manage a change. :)
Regards,
Simon
Amicalement,
--
Albert.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
