From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com>
Date: Mon, 27 Jun 2011 15:42:41 +0200
Subject: [U-Boot] SPL framework re-design
In-Reply-To: <20110627092731.3532D202C61@gemini.denx.de>
References: <4DF9B9E0.8020206@ti.com>
	<20110616104716.762DD19E5AC3@gemini.denx.de>
	<BANLkTim9AE2aszKLiDH53vd+Hjpz7GVoNA@mail.gmail.com>
	<4DFA00B8.7000807@gmail.com>
	<loom.20110627T010402-587@post.gmane.org>
	<20110627092731.3532D202C61@gemini.denx.de>
Message-ID: <BANLkTin-s=wZnPTu8eJ7s_GZ9HRRV-PAXA@mail.gmail.com>
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

Hi,

On Mon, Jun 27, 2011 at 11:27 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Ilya,
>
> In message <loom.20110627T010402-587@post.gmane.org> you wrote:
>>
>> I wonder why do we need this whole spl thing in the first place (well,
>> surely I know what they are used for but why do we need a separate entity
>> for this)? Isn't it just the same U-Boot in, well, very special configuration
>> (minimal set of drivers, no shell, etc)? Why do we need a whole shadow tree
>> at spl/ instead of just providing the _configuration_?

I guess that is because the discussion started with several
directories (nand_spl, mmc_spl etc.)
which should be merged into a single spl directory.

>
> Good point. ?Eventually we can ?just add additional build rules for
> new object files (say, ".splo" instead of ".o") ?

I agree this approach seems to be the best one.
But then we have to create SPL-specific libraries too, right?
(e.g. lib$(ARCH).splo, lib$(CPU).splo)


Best regards,
Daniel