From mboxrd@z Thu Jan  1 00:00:00 1970
From: Wolfgang Denk <wd@denx.de>
Date: Thu, 16 Jun 2011 23:52:04 +0200
Subject: [U-Boot] SPL framework re-design
In-Reply-To: <4DFA0759.2060606@ti.com>
References: <4DF9B9E0.8020206@ti.com>
	<20110616104716.762DD19E5AC3@gemini.denx.de>
	<4DF9EE03.8010105@ti.com>
	<20110616121540.196C519E5AC4@gemini.denx.de>
	<4DFA0759.2060606@ti.com>
Message-ID: <20110616215204.9A37219E5AC5@gemini.denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Dear Aneesh V,

In message <4DFA0759.2060606@ti.com> you wrote:
>
> >> Can you please extend this to show the SoC/board directories etc. I
> >> guess they will go under spl/ and not under each media.
> >
> > Correct, i. e. please add for example:
> >
> > 	spl/board/freescale/mx31pdk/
> > 	spl/board/freescale/mx31pdk/Makefile
> > 	...
> 
> I thought we were going to have cpu directory SoC directory etc in this
> directory structure.

If needed, yes.  This example showed a board directory.

> > Can we not use the objects that get normally built, with the existing
> > Makefiles?
> 
> But where do you add the reference to SoC level and CPU level object
> files? Which library do you make them part of? I thought the board
> level Makefile was meant only to build the board specific library.

Sorry, I don;t understand your questions (because I don't understand
which problem you see).

Yes, the board directories will contain only board specific stuff.

> For example, let's say we have board 'a' and 'b' of same SoC(soc).
> Unless we have a SoC directory we may have to do something like this.

Why should we not have a SoC dir?

> >> Also, at least some files will have to be built separately for SPL
> >> because they have conditional compilation with CONFIG_PRELOADER kind of
> >> flags.
> >
> > Please let's check where this is needed, and how we can handle this.
> > I'd really like to get rid of this symlinking.
> 
> One case is start.S. We need a simplified start.S for SPL(no
> relocation, no interrupt handling etc).

OK.

> There are places where CONFIG_PRELOADER is used today. But maybe, these
> could be avoided it we try.

We should carefully check these.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
To live is always desirable.
	-- Eleen the Capellan, "Friday's Child", stardate 3498.9