From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Wed, 07 Dec 2011 09:15:23 +0100 Subject: [U-Boot] [RFC PATCH 1/7] reboard: define CONFIG_SYS_LEGACY_BOARD everywhere In-Reply-To: References: <1321919880-10070-1-git-send-email-sjg@chromium.org> <201111291640.31212.vapier@gentoo.org> <201111291819.22994.vapier@gentoo.org> Message-ID: <4EDF209B.4000003@aribaud.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Le 30/11/2011 00:40, Simon Glass a ?crit : > Hi Mike, > > On Tue, Nov 29, 2011 at 3:19 PM, Mike Frysinger 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.