On Tuesday 28 June 2011 09:48 PM, Scott Wood wrote:
> On Tue, 28 Jun 2011 12:24:11 +0530
> Aneesh V wrote:
>
>> 1. If there are SPL customized generic files like the
>> nand_spl/nand_boot.c where do we keep them? I suggest that we keep them
>> in spl/nand, spl/onenand etc. And for the object file
On Tue, 28 Jun 2011 12:24:11 +0530
Aneesh V wrote:
> 1. If there are SPL customized generic files like the
> nand_spl/nand_boot.c where do we keep them? I suggest that we keep them
> in spl/nand, spl/onenand etc. And for the object file hierarchy let's
> have something like spl/obj. How about tha
On Tuesday 28 June 2011 02:52 AM, Wolfgang Denk wrote:
> Dear Scott Wood,
>
> In message<20110627161803.16783...@schlenkerla.am.freescale.net> you wrote:
>>
> But if we do not create a new hierarchy of target directories we will
> have the "normal" and the "spl" objects in parallel (and I
Dear Graeme Russ,
In message you wrote:
>
> I can think of three disctinct phases which are relatively commong across
> most arch's (especially NAND Flash arches)
>
> 1) An intial page (say 256 bytes for example) which loads a second stage
>into the CPU's cache
> 2) A second phase running i
Hi All,
Just thought I'd throw in a left-field idea...
Could we make the loading of U-Boot into a generic multi-stage framework
with each stage bootstrapping the next stage? OK, I know this is how IPL,
SPL etc work already, but I'm thinking something more formal and arch
independent.
I can think
Dear Scott Wood,
In message <20110627161803.16783...@schlenkerla.am.freescale.net> you wrote:
>
> > > > But if we do not create a new hierarchy of target directories we will
> > > > have the "normal" and the "spl" objects in parallel (and I don't want
> > > > to delete one when building the other)
On Mon, 27 Jun 2011 23:10:33 +0200
Wolfgang Denk wrote:
> Dear Scott Wood,
>
> In message <20110627155535.4217b...@schlenkerla.am.freescale.net> you wrote:
> >
> > > But if we do not create a new hierarchy of target directories we will
> > > have the "normal" and the "spl" objects in parallel (a
Dear Scott Wood,
In message <20110627155535.4217b...@schlenkerla.am.freescale.net> you wrote:
>
> > But if we do not create a new hierarchy of target directories we will
> > have the "normal" and the "spl" objects in parallel (and I don't want
> > to delete one when building the other).
>
> What'
On Mon, 27 Jun 2011 22:50:46 +0200
Wolfgang Denk wrote:
> Dear Scott Wood,
>
> In message <20110627133435.31cd3...@schlenkerla.am.freescale.net> you wrote:
> >
> > > Good point. Eventually we can just add additional build rules for
> > > new object files (say, ".splo" instead of ".o") ?
> >
>
Dear Scott Wood,
In message <20110627134205.021af...@schlenkerla.am.freescale.net> you wrote:
>
> > This statement does not make much sense to me. If we can do it in the
> > spl/ directory, we should be able to do it in any other directory as
> > well. The worst to happen is that we have to keep
Dear Scott Wood,
In message <20110627133435.31cd3...@schlenkerla.am.freescale.net> you wrote:
>
> > Good point. Eventually we can just add additional build rules for
> > new object files (say, ".splo" instead of ".o") ?
>
> No need for new extensions -- we should be able to use the target
> dir
Dear Aneesh V,
In message <4e089a25.4050...@ti.com> you wrote:
>
> >Instead of doing this, we could as well just maintain a list of
> >objects and then link all these together directly, without creating
> >libraries first.
>
> Is this like a make variable that keeps accumulating obje
Dear Daniel,
In message you wrote:
>
> > 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$(AR
On Mon, 27 Jun 2011 11:36:33 +0200
Wolfgang Denk wrote:
> Dear Aneesh,
>
> In message <4e080733.2030...@ti.com> 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 t
On Mon, 27 Jun 2011 11:27:31 +0200
Wolfgang Denk wrote:
> Dear Ilya,
>
> In message 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-Bo
Dear Wolfgang,
On Monday 27 June 2011 02:57 PM, Wolfgang Denk wrote:
> Dear Aneesh,
>
> In message<4e0804dc.8090...@ti.com> you wrote:
>>
+spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
+ $(MAKE) -C spl/ all
+
$(obj)mmc_spl/u-boot-mmc-spl.bin: mmc_spl
>>>
>>> The
Hi,
On Mon, Jun 27, 2011 at 11:27 AM, Wolfgang Denk wrote:
> Dear Ilya,
>
> In message 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
Dear Aneesh,
In message <4e080733.2030...@ti.com> 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
> > configur
Dear Ilya,
In message 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 sh
Dear Aneesh,
In message <4e0804dc.8090...@ti.com> you wrote:
>
> >> +spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
> >> + $(MAKE) -C spl/ all
> >> +
> >>$(obj)mmc_spl/u-boot-mmc-spl.bin: mmc_spl
> >
> > The mmc_spl/ is suppoed to be moved into spl/, isn't it?
>
> This patch was in
Hi Ilya,
On Monday 27 June 2011 01:54 PM, Ilya Yanok wrote:
> Hi Aneesh,
>
> On 27.06.2011 08:29, Aneesh V 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 th
Hi,
> You mentioned that /spl can not be used for source files. Isn't there a
> way to workaround this problem?
Why should we have source files in a SPL directory? I would prefer to
have spl specific sources right where the rest ist - maybe marked with
something like _spl or excluded by some #defi
Hi Aneesh,
On 27.06.2011 08:29, Aneesh V 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
Hi Ilya,
On Monday 27 June 2011 04:47 AM, Ilya Yanok wrote:
> Hello everybody,
>
> I've read the whole thread and I really like what Daniel suggests but I just
> want to speak it in a little bit different words.
>
> I wonder why do we need this whole spl thing in the first place (well,
> surely I
Dear Wolfgang,
On Saturday 25 June 2011 05:40 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4e00799a.5040...@ti.com> you wrote:
>>
>>> Here is a crude implementation of the top-down approach you had been
>>> suggesting (or my interpretation of it). This is not complete yet and
>>> serv
Hello everybody,
I've read the whole thread and I really like what Daniel suggests but I just
want to speak it in a little bit different words.
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
Dear Wolfgang,
On 06/25/2011 02:10 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4e00799a.5040...@ti.com> you wrote:
>>
>>> Here is a crude implementation of the top-down approach you had been
>>> suggesting (or my interpretation of it). This is not complete yet and
>>> serves only as
Dear Aneesh V,
In message <4e00799a.5040...@ti.com> you wrote:
>
> > Here is a crude implementation of the top-down approach you had been
> > suggesting (or my interpretation of it). This is not complete yet and
> > serves only as a material for further discussions on this topic.
>
> Here is an u
Dear Wolfgang,
On Tuesday 21 June 2011 04:29 PM, Aneesh V wrote:
> Dear Wolfgang,
>
> On Friday 17 June 2011 10:18 PM, Aneesh V wrote:
>> Dear Wolfgang,
>>
>> Here is a crude implementation of the top-down approach you had been
>> suggesting (or my interpretation of it). This is not complete yet a
Dear Wolfgang,
On Friday 17 June 2011 10:18 PM, Aneesh V wrote:
> Dear Wolfgang,
>
> Here is a crude implementation of the top-down approach you had been
> suggesting (or my interpretation of it). This is not complete yet and
> serves only as a material for further discussions on this topic.
Here
On Monday 20 June 2011 09:49 PM, Scott Wood wrote:
> On Sun, 19 Jun 2011 15:52:29 +0530
> "V, Aneesh" wrote:
>
>> On Sat, Jun 18, 2011 at 3:58 AM, Scott Wood wrote:
>>> On Fri, 17 Jun 2011 22:18:57 +0530
>>> Aneesh V wrote:
>>>
@@ -1158,6 +1164,7 @@ clobber:clean
@[ ! -d
On Sun, 19 Jun 2011 15:52:29 +0530
"V, Aneesh" wrote:
> On Sat, Jun 18, 2011 at 3:58 AM, Scott Wood wrote:
> > On Fri, 17 Jun 2011 22:18:57 +0530
> > Aneesh V wrote:
> >
> >> @@ -1158,6 +1164,7 @@ clobber: clean
> >> @[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name "*" -type l
On Sat, Jun 18, 2011 at 3:58 AM, Scott Wood wrote:
> On Fri, 17 Jun 2011 22:18:57 +0530
> Aneesh V wrote:
>
>> @@ -1158,6 +1164,7 @@ clobber: clean
>> @[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name "*" -type l
>> -print | xargs rm -f
>> @[ ! -d $(obj)onenand_ipl ] || fin
On Fri, 17 Jun 2011 22:18:57 +0530
Aneesh V wrote:
> @@ -1158,6 +1164,7 @@ clobber:clean
> @[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name "*" -type l
> -print | xargs rm -f
> @[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name "*" -type
> l -print | xargs rm -
On Fri, 17 Jun 2011 20:45:19 +0200
Daniel Schwierzeck wrote:
> Dear Wolfgang,
>
> On Thu, Jun 16, 2011 at 11:47 PM, Wolfgang Denk wrote:
> > Dear Daniel Schwierzeck,
> >
> > In message you wrote:
> >>
> >> The relocate_code and board_init_r functions must not be compiled,
> >> they are not nee
Dear Wolfgang,
On Thu, Jun 16, 2011 at 11:47 PM, Wolfgang Denk wrote:
> Dear Daniel Schwierzeck,
>
> In message you wrote:
>>
>> The relocate_code and board_init_r functions must not be compiled,
>> they are not needed anyway. This
>> can be simply controlled with -DCONFIG_UBOOT_SPL_BUILD.
>
> T
Dear Wolfgang,
Here is a crude implementation of the top-down approach you had been
suggesting (or my interpretation of it). This is not complete yet and
serves only as a material for further discussions on this topic.
This work borrows from the work of Daniel Schwierzeck
staged here:
https://git
On Friday 17 June 2011 03:39 AM, Wolfgang Denk wrote:
> Dear Scott Wood,
>
> In message<20110616114556.7d3c2...@schlenkerla.am.freescale.net> you wrote:
>>
>> What is a "generic SPL library", or even a "generic NAND SPL library"?
>>
>> There is no code that is shared by all NAND SPLs. The files d
On Thursday 16 June 2011 10:15 PM, Scott Wood wrote:
> On Thu, 16 Jun 2011 13:38:00 +0530
> Aneesh V wrote:
>
>> New Design Proposed by Wolfgang:
>> * Have a top-level Makefile in the SPL root-directory - for instance
>> 'nand_spl/Makefile'
>> * nand_spl/Makefile builds a generic library with the
On Fri, 17 Jun 2011 00:09:00 +0200
Wolfgang Denk wrote:
> Dear Scott Wood,
>
> In message <20110616114556.7d3c2...@schlenkerla.am.freescale.net> you wrote:
> >
> > What is a "generic SPL library", or even a "generic NAND SPL library"?
> >
> > There is no code that is shared by all NAND SPLs. T
Dear Scott Wood,
In message <20110616114556.7d3c2...@schlenkerla.am.freescale.net> you wrote:
>
> What is a "generic SPL library", or even a "generic NAND SPL library"?
>
> There is no code that is shared by all NAND SPLs. The files directly under
> "nand_spl/" are alternatives that the board ma
Dear Aneesh V,
In message <4dfa0be1.4060...@ti.com> you wrote:
>
> In the last few mails Wolfgang was suggesting re-use of object files
> themselves, not the source files. In this respect his approach may be
> different from yours. But I think his objective was to avoid the
> symbolic link busine
Dear Aneesh V,
In message <4dfa0759.2060...@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
Dear Daniel Schwierzeck,
In message you wrote:
>
> The relocate_code and board_init_r functions must not be compiled,
> they are not needed anyway. This
> can be simply controlled with -DCONFIG_UBOOT_SPL_BUILD.
This is very much wrong. In the general case, you still need
relocation (because th
On Thu, 16 Jun 2011 13:38:00 +0530
Aneesh V wrote:
> New Design Proposed by Wolfgang:
> * Have a top-level Makefile in the SPL root-directory - for instance
> 'nand_spl/Makefile'
> * nand_spl/Makefile builds a generic library with the generic source
> files at this level.
What is a "generic SPL
On Thu, Jun 16, 2011 at 3:57 PM, Aneesh V wrote:
> Hi Daniel,
>
> This looks like an interesting alternative.
>
> On Thursday 16 June 2011 06:25 PM, Daniel Schwierzeck wrote:
>>
>> Hi all,
>>
>> for my MIPS based boards I tested a approach similar to Wolfgang's one
>> in the last weeks.
>> My goal
Hi Daniel,
This looks like an interesting alternative.
On Thursday 16 June 2011 06:25 PM, Daniel Schwierzeck wrote:
> Hi all,
>
> for my MIPS based boards I tested a approach similar to Wolfgang's one
> in the last weeks.
> My goal was to create a SPL image, that is able to boot from a SPI flash.
On Thursday 16 June 2011 05:45 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4df9ee03.8010...@ti.com> you wrote:
>>
>>> we are also duplicating the structure across different boot media. I
>>> think we should re-organize this as follows:
>>>
>>> spl/
>>> spl/common/
>>> spl/
Dear all,
Am 16.06.2011 14:55, schrieb Daniel Schwierzeck:
> On Thu, Jun 16, 2011 at 12:47 PM, Wolfgang Denk wrote:
>> Dear Aneesh,
>> We should try to get rid of the need to create symbolic links. If we
>> use the same source files as for the "normal", then we should also
>> use the normal
Hi all,
for my MIPS based boards I tested a approach similar to Wolfgang's one
in the last weeks.
My goal was to create a SPL image, that is able to boot from a SPI flash.
The basic idea is to have a spl directory that is used as remote build
directory for all object files
needed for the SPL imag
Dear Aneesh V,
In message <4df9ee03.8010...@ti.com> you wrote:
>
> > we are also duplicating the structure across different boot media. I
> > think we should re-organize this as follows:
> >
> > spl/
> > spl/common/
> > spl/mmc/
> > spl/nand/
> > spl/onenand/
>
> Can you plea
Dear Wolfgang,
On Thursday 16 June 2011 04:17 PM, Wolfgang Denk wrote:
> Dear Aneesh,
>
> In message<4df9b9e0.8020...@ti.com> you wrote:
>>
>> To make sure I understand your new proposals, let me consolidate them
>> here. Please correct me if I am wrong. Also, in the end I have some
>> questions
Dear Aneesh,
In message <4df9b9e0.8020...@ti.com> you wrote:
>
> To make sure I understand your new proposals, let me consolidate them
> here. Please correct me if I am wrong. Also, in the end I have some
> questions about your new proposal. Some of the questions are getting
> into the details. B
53 matches
Mail list logo
