Hi Albert, On Wed, Dec 7, 2011 at 12:15 AM, Albert ARIBAUD <albert.u.b...@aribaud.net> wrote: > 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. :)
OK it sounds like SPL won't cause problems with this series, good. Regards, Simon > >> Regards, >> Simon > > > Amicalement, > -- > Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot