From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aneesh V Date: Mon, 05 Dec 2011 12:12:31 +0530 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> <201111282211.36347.vapier@gentoo.org> <201111291640.31212.vapier@gentoo.org> Message-ID: <4EDC67D7.2060808@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Simon, On Wednesday 30 November 2011 03:39 AM, Simon Glass wrote: > +omap, samsung, imx maintainers > > Hi Mike, > > 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 ? >> -mike >> > > Yes I can do that. > > 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. OMAP SPL doesn't relocate itself. Neither does it have any restriction on the position of early code in the image. best regards, Aneesh