| Message ID | 1305472900-4004-7-git-send-email-aneesh@ti.com |
|---|---|
| State | Changes Requested |
| Headers | show |
Dear Aneesh V, In message <1305472900-4004-7-git-send-email-aneesh@ti.com> you wrote: > Define a new type of SPL that is not tied to any particular media. > - Create a top level directory 'spl' that has a structure similar > to the existing 'nand_spl' > - Make necessary changes to top-level Makefile to build such an spl > > Rationale for this approach: > - There may be SPLs(like the OMAP x-loader) that support booting from > multiple media. > - Also, there is no harm in keeping SPLs specific to a particular media > also under this directory. In fact it makes sense to merge all the > different spl directories into this one. Thanks a lot for addressing this. This is an area that has long been on my mind, and I'm really happy to see someone starting to work on this. In addition to booting from different types of media, I see at least two more topics that scould and should addressed by this work: - Get rid of xloader. I cannot see any good reasons why we need it, i. e. which functions if performs that cannot be as well (and eventually even more efficiently) be performed in the U-Boot SPL code. - Become more flexible regarding the kind of second stage payload. It is definitely very powerful and convenient during development to be able to load U-Boot with all it's capabilities as payload of the SPL, but then, except for image size and parameter passing, there is little or no difference to loading a Linux kernel directly instead (and actually this is what most of the super-fast booting approaches do). If done right, we may even have the flexibility to do both, just by providing different images as payload. > Signed-off-by: Aneesh V <aneesh@ti.com> > --- > This patch generates 1 checkpatch warning due to declaration > of DECLARE_GLOBAL_DATA_PTR. This is un-avoidable > --- > Makefile | 24 ++++++++++++++++++++++++ > arch/arm/include/asm/global_data.h | 5 +++++ > 2 files changed, 29 insertions(+), 0 deletions(-) Here the commit message and the implementation do not agree. You wrote "Create a top level directory 'spl'" - but I don't see any of that here? I think this should be split into a separate patch series, and care should be taken that commit messages and implementaiton match. Best regards, Wolfgang Denk
Hi Wolfgang, On Monday 16 May 2011 01:18 AM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<1305472900-4004-7-git-send-email-aneesh@ti.com> you wrote: >> Define a new type of SPL that is not tied to any particular media. >> - Create a top level directory 'spl' that has a structure similar >> to the existing 'nand_spl' >> - Make necessary changes to top-level Makefile to build such an spl >> >> Rationale for this approach: >> - There may be SPLs(like the OMAP x-loader) that support booting from >> multiple media. >> - Also, there is no harm in keeping SPLs specific to a particular media >> also under this directory. In fact it makes sense to merge all the >> different spl directories into this one. > > Thanks a lot for addressing this. This is an area that has long been > on my mind, and I'm really happy to see someone starting to work on > this. > > In addition to booting from different types of media, I see at least > two more topics that scould and should addressed by this work: > > - Get rid of xloader. I cannot see any good reasons why we need it, > i. e. which functions if performs that cannot be as well (and > eventually even more efficiently) be performed in the U-Boot SPL > code. Indeed, SPL is seen as a replacement for x-loader. > > - Become more flexible regarding the kind of second stage payload. > It is definitely very powerful and convenient during development to > be able to load U-Boot with all it's capabilities as payload of the > SPL, but then, except for image size and parameter passing, there is > little or no difference to loading a Linux kernel directly instead > (and actually this is what most of the super-fast booting approaches > do). If done right, we may even have the flexibility to do both, > just by providing different images as payload. > How do we handle the differences you just mentioned, namely the size, parameter passing etc. Maybe, we should have special handling for each and define config flags like CONFIG_SPL_PAYLOAD_UBOOT, CONFIG_SPL_PAYLOAD_LINUX_KERNEL etc? > >> Signed-off-by: Aneesh V<aneesh@ti.com> >> --- >> This patch generates 1 checkpatch warning due to declaration >> of DECLARE_GLOBAL_DATA_PTR. This is un-avoidable >> --- >> Makefile | 24 ++++++++++++++++++++++++ >> arch/arm/include/asm/global_data.h | 5 +++++ >> 2 files changed, 29 insertions(+), 0 deletions(-) > > Here the commit message and the implementation do not agree. You > wrote "Create a top level directory 'spl'" - but I don't see any of > that here? In this patch, I just created the makefile infrastructure that expects this directory structure. The files are created later in an OMAP specific patch. I think I should have used something like "define a directory structure" instead of "create". > > I think this should be split into a separate patch series, and care > should be taken that commit messages and implementaiton match. Ok. > > Best regards, > > Wolfgang Denk >
Dear Aneesh V, In message <4DD11D1F.8020006@ti.com> you wrote: > > > - Get rid of xloader. I cannot see any good reasons why we need it, > > i. e. which functions if performs that cannot be as well (and > > eventually even more efficiently) be performed in the U-Boot SPL > > code. > > Indeed, SPL is seen as a replacement for x-loader. Excellent. > How do we handle the differences you just mentioned, namely the size, > parameter passing etc. Maybe, we should have special handling for each > and define config flags like CONFIG_SPL_PAYLOAD_UBOOT, > CONFIG_SPL_PAYLOAD_LINUX_KERNEL etc? None of this. Ideally, the code should not even see such a difference. U-Boot does not need any special arguments for booting, so we calways pass Linux-compatible args. And things like image size should be read from the image itself, or form other available meta information (like file size when reading from a FAT file system, etc.). > >> Makefile | 24 ++++++++++++++++++++++++ > >> arch/arm/include/asm/global_data.h | 5 +++++ > >> 2 files changed, 29 insertions(+), 0 deletions(-) > > > > Here the commit message and the implementation do not agree. You > > wrote "Create a top level directory 'spl'" - but I don't see any of > > that here? > > In this patch, I just created the makefile infrastructure that expects > this directory structure. The files are created later in an OMAP > specific patch. Such a definition should include the rename / moving of the other, already existing code. Best regards, Wolfgang Denk
On Sun, 15 May 2011 20:51:24 +0530 Aneesh V <aneesh@ti.com> wrote: > diff --git a/Makefile b/Makefile > index 384a59e..d3f4bef 100644 > --- a/Makefile > +++ b/Makefile > @@ -289,6 +289,22 @@ LDPPFLAGS += \ > $(shell $(LD) --version | \ > sed -ne 's/GNU ld version \([0-9][0-9]*\)\.\([0-9][0-9]*\).*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p') > > +ifeq ($(CONFIG_NAND_U_BOOT),y) > +NAND_SPL = nand_spl > +U_BOOT_NAND = $(obj)u-boot-nand.bin > +endif > + > +ifeq ($(CONFIG_SPL),y) > +.PHONEY : SPL > +ALL += SPL > +endif > + > +ifeq ($(CONFIG_ONENAND_U_BOOT),y) > +ONENAND_IPL = onenand_ipl > +U_BOOT_ONENAND = $(obj)u-boot-onenand.bin > +ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin > +endif > + > __OBJS := $(subst $(obj),,$(OBJS)) > __LIBS := $(subst $(obj),,$(LIBS)) $(subst $(obj),,$(LIBBOARD)) > > @@ -402,8 +418,13 @@ $(obj)u-boot.lds: $(LDSCRIPT) > $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - <$^ >$@ > > nand_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend > + > +$(NAND_SPL): $(TIMESTAMP_FILE) $(VERSION_FILE) depend You are reverting part of e935a374dbe5c745fdde05b2b07ced0bbe70887f. Merge accident? > @@ -1141,12 +1163,14 @@ clobber: clean > @rm -f $(obj)u-boot $(obj)u-boot.map $(obj)u-boot.hex $(ALL) > @rm -f $(obj)u-boot.kwb > @rm -f $(obj)u-boot.imx > + @rm -f $(obj)MLO What is MLO? > diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h > index 2a84d27..2ce020e 100644 > --- a/arch/arm/include/asm/global_data.h > +++ b/arch/arm/include/asm/global_data.h > @@ -89,6 +89,11 @@ typedef struct global_data { > #define GD_FLG_DISABLE_CONSOLE 0x00040 /* Disable console (in & out) */ > #define GD_FLG_ENV_READY 0x00080 /* Environment imported into hash table */ > > +#ifdef CONFIG_PRELOADER > +/* SPL works from internal RAM. gd pointer can be in .data section */ > +#define DECLARE_GLOBAL_DATA_PTR extern gd_t *gd > +#else > #define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r8") > +#endif Is this appropriate for all ARM boards (e.g. those currently using nand_spl)? -Scott
Hi Scott, On Tuesday 17 May 2011 12:02 AM, Scott Wood wrote: > On Sun, 15 May 2011 20:51:24 +0530 > Aneesh V<aneesh@ti.com> wrote: > >> diff --git a/Makefile b/Makefile >> index 384a59e..d3f4bef 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -289,6 +289,22 @@ LDPPFLAGS += \ >> $(shell $(LD) --version | \ >> sed -ne 's/GNU ld version \([0-9][0-9]*\)\.\([0-9][0-9]*\).*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p') >> >> +ifeq ($(CONFIG_NAND_U_BOOT),y) >> +NAND_SPL = nand_spl >> +U_BOOT_NAND = $(obj)u-boot-nand.bin >> +endif >> + >> +ifeq ($(CONFIG_SPL),y) >> +.PHONEY : SPL >> +ALL += SPL >> +endif >> + >> +ifeq ($(CONFIG_ONENAND_U_BOOT),y) >> +ONENAND_IPL = onenand_ipl >> +U_BOOT_ONENAND = $(obj)u-boot-onenand.bin >> +ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin >> +endif >> + >> __OBJS := $(subst $(obj),,$(OBJS)) >> __LIBS := $(subst $(obj),,$(LIBS)) $(subst $(obj),,$(LIBBOARD)) >> >> @@ -402,8 +418,13 @@ $(obj)u-boot.lds: $(LDSCRIPT) >> $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P -<$^>$@ >> >> nand_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend >> + >> +$(NAND_SPL): $(TIMESTAMP_FILE) $(VERSION_FILE) depend > > You are reverting part of e935a374dbe5c745fdde05b2b07ced0bbe70887f. Merge > accident? > Oops! That indeed seems like a merge accident. I will correct it in the next version. >> @@ -1141,12 +1163,14 @@ clobber: clean >> @rm -f $(obj)u-boot $(obj)u-boot.map $(obj)u-boot.hex $(ALL) >> @rm -f $(obj)u-boot.kwb >> @rm -f $(obj)u-boot.imx >> + @rm -f $(obj)MLO > > What is MLO? MLO is the name of SPL created for OMAP. ROM code expects a file with this name as the first image when it boots from FAT. > >> diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h >> index 2a84d27..2ce020e 100644 >> --- a/arch/arm/include/asm/global_data.h >> +++ b/arch/arm/include/asm/global_data.h >> @@ -89,6 +89,11 @@ typedef struct global_data { >> #define GD_FLG_DISABLE_CONSOLE 0x00040 /* Disable console (in& out) */ >> #define GD_FLG_ENV_READY 0x00080 /* Environment imported into hash table */ >> >> +#ifdef CONFIG_PRELOADER >> +/* SPL works from internal RAM. gd pointer can be in .data section */ >> +#define DECLARE_GLOBAL_DATA_PTR extern gd_t *gd >> +#else >> #define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r8") >> +#endif > > Is this appropriate for all ARM boards (e.g. those currently using > nand_spl)? None of the SPL's other than this one seems to be using global data today. If anybody wants to use it this seems to be the logical option for me because by definition SPL runs from some kind of RAM so global data can be placed in the .data section of SPL. best regards, Aneesh
Dear Aneesh V, In message <4DD21BAA.6000601@ti.com> you wrote: > > > What is MLO? > > MLO is the name of SPL created for OMAP. ROM code expects a file with > this name as the first image when it boots from FAT. What does MLO mean? > >> +#ifdef CONFIG_PRELOADER > >> +/* SPL works from internal RAM. gd pointer can be in .data section */ > >> +#define DECLARE_GLOBAL_DATA_PTR extern gd_t *gd > >> +#else > >> #define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r8") > >> +#endif > > > > Is this appropriate for all ARM boards (e.g. those currently using > > nand_spl)? > > None of the SPL's other than this one seems to be using global data > today. If anybody wants to use it this seems to be the logical option > for me because by definition SPL runs from some kind of RAM so global > data can be placed in the .data section of SPL. But that's not what you are doing. You are not changing the storage of the global data itself, you are changing the storage of the POINTER TO the global data - and this makes no sense to me. The pointer can certainly remain in a register even if the data itself is somewhere else. This will save us this #ifdef here. Best regards, Wolfgang Denk
Hi Aneesh, On Tuesday 17 May 2011 01:45 PM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<4DD21BAA.6000601@ti.com> you wrote: >> >>> What is MLO? >> >> MLO is the name of SPL created for OMAP. ROM code expects a file with >> this name as the first image when it boots from FAT. > > What does MLO mean? On looking up ROM code spec, this seems to stand for "MMC/SD Loader" > > >>>> +#ifdef CONFIG_PRELOADER >>>> +/* SPL works from internal RAM. gd pointer can be in .data section */ >>>> +#define DECLARE_GLOBAL_DATA_PTR extern gd_t *gd >>>> +#else >>>> #define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r8") >>>> +#endif >>> >>> Is this appropriate for all ARM boards (e.g. those currently using >>> nand_spl)? >> >> None of the SPL's other than this one seems to be using global data >> today. If anybody wants to use it this seems to be the logical option >> for me because by definition SPL runs from some kind of RAM so global >> data can be placed in the .data section of SPL. > > But that's not what you are doing. You are not changing the storage > of the global data itself, you are changing the storage of the POINTER > TO the global data - and this makes no sense to me. The pointer can > certainly remain in a register even if the data itself is somewhere > else. Why do we want to waste a register in the entire SPL when global data can be accessed directly from .data section? best regards, Aneesh
Dear Aneesh V, In message <4DD24E63.3020006@ti.com> you wrote: > > > But that's not what you are doing. You are not changing the storage > > of the global data itself, you are changing the storage of the POINTER > > TO the global data - and this makes no sense to me. The pointer can > > certainly remain in a register even if the data itself is somewhere > > else. > > Why do we want to waste a register in the entire SPL when global data > can be accessed directly from .data section? Because the resulting code is smaller? I did not measure it on your hardware with your compiler, but IIRC this was the result on some other processors. Best regards, Wolfgang Denk
Hi Wolfgang, On Tuesday 17 May 2011 04:47 PM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<4DD24E63.3020006@ti.com> you wrote: >> >>> But that's not what you are doing. You are not changing the storage >>> of the global data itself, you are changing the storage of the POINTER >>> TO the global data - and this makes no sense to me. The pointer can >>> certainly remain in a register even if the data itself is somewhere >>> else. >> >> Why do we want to waste a register in the entire SPL when global data >> can be accessed directly from .data section? > > Because the resulting code is smaller? > I was thinking that it may be faster. More number of registers at disposal may mean less number of pushes to the stack, right? I am not sure if this will make a significant difference. best regards, Aneesh
Dear Aneesh V, In message <4DD26719.5090003@ti.com> you wrote: > > I was thinking that it may be faster. More number of registers at > disposal may mean less number of pushes to the stack, right? I am not > sure if this will make a significant difference. It does not make a significant difference. Which is the reason I vote for avoiding the #ifdef. Best regards, Wolfgang Denk
Hi Wolfgang, On Tuesday 17 May 2011 06:03 PM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<4DD26719.5090003@ti.com> you wrote: >> >> I was thinking that it may be faster. More number of registers at >> disposal may mean less number of pushes to the stack, right? I am not >> sure if this will make a significant difference. > > It does not make a significant difference. Which is the reason I vote > for avoiding the #ifdef. > Ok. I shall change it. best regards, Aneesh
On Tue, 17 May 2011 12:24:34 +0530 Aneesh V <aneesh@ti.com> wrote: > On Tuesday 17 May 2011 12:02 AM, Scott Wood wrote: > > On Sun, 15 May 2011 20:51:24 +0530 > > Aneesh V<aneesh@ti.com> wrote: > >> diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h > >> index 2a84d27..2ce020e 100644 > >> --- a/arch/arm/include/asm/global_data.h > >> +++ b/arch/arm/include/asm/global_data.h > >> @@ -89,6 +89,11 @@ typedef struct global_data { > >> #define GD_FLG_DISABLE_CONSOLE 0x00040 /* Disable console (in& out) */ > >> #define GD_FLG_ENV_READY 0x00080 /* Environment imported into hash table */ > >> > >> +#ifdef CONFIG_PRELOADER > >> +/* SPL works from internal RAM. gd pointer can be in .data section */ > >> +#define DECLARE_GLOBAL_DATA_PTR extern gd_t *gd > >> +#else > >> #define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r8") > >> +#endif > > > > Is this appropriate for all ARM boards (e.g. those currently using > > nand_spl)? > > None of the SPL's other than this one seems to be using global data > today. If anybody wants to use it this seems to be the logical option > for me because by definition SPL runs from some kind of RAM so global > data can be placed in the .data section of SPL. There is nand_spl code, including ARM, that uses gd. E.g. putc() in board/davinci/da8xxevm/hawkboard_nand_spl.c. This comment also applies to the other uses of CONFIG_PRELOADER -- are all of those changes appropriate for the existing nand_spl users? -Scott
Hi Scott, On Tuesday 17 May 2011 10:20 PM, Scott Wood wrote: > On Tue, 17 May 2011 12:24:34 +0530 > Aneesh V<aneesh@ti.com> wrote: > >> On Tuesday 17 May 2011 12:02 AM, Scott Wood wrote: >>> On Sun, 15 May 2011 20:51:24 +0530 >>> Aneesh V<aneesh@ti.com> wrote: >>>> diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h >>>> index 2a84d27..2ce020e 100644 >>>> --- a/arch/arm/include/asm/global_data.h >>>> +++ b/arch/arm/include/asm/global_data.h >>>> @@ -89,6 +89,11 @@ typedef struct global_data { >>>> #define GD_FLG_DISABLE_CONSOLE 0x00040 /* Disable console (in& out) */ >>>> #define GD_FLG_ENV_READY 0x00080 /* Environment imported into hash table */ >>>> >>>> +#ifdef CONFIG_PRELOADER >>>> +/* SPL works from internal RAM. gd pointer can be in .data section */ >>>> +#define DECLARE_GLOBAL_DATA_PTR extern gd_t *gd >>>> +#else >>>> #define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r8") >>>> +#endif >>> >>> Is this appropriate for all ARM boards (e.g. those currently using >>> nand_spl)? >> >> None of the SPL's other than this one seems to be using global data >> today. If anybody wants to use it this seems to be the logical option >> for me because by definition SPL runs from some kind of RAM so global >> data can be placed in the .data section of SPL. > > There is nand_spl code, including ARM, that uses gd. E.g. putc() in > board/davinci/da8xxevm/hawkboard_nand_spl.c. > > This comment also applies to the other uses of CONFIG_PRELOADER -- are all > of those changes appropriate for the existing nand_spl users? I would probably revert the change as advised by Wolfgang. best regards, Aneesh
diff --git a/Makefile b/Makefile index 384a59e..d3f4bef 100644 --- a/Makefile +++ b/Makefile @@ -289,6 +289,22 @@ LDPPFLAGS += \ $(shell $(LD) --version | \ sed -ne 's/GNU ld version \([0-9][0-9]*\)\.\([0-9][0-9]*\).*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p') +ifeq ($(CONFIG_NAND_U_BOOT),y) +NAND_SPL = nand_spl +U_BOOT_NAND = $(obj)u-boot-nand.bin +endif + +ifeq ($(CONFIG_SPL),y) +.PHONEY : SPL +ALL += SPL +endif + +ifeq ($(CONFIG_ONENAND_U_BOOT),y) +ONENAND_IPL = onenand_ipl +U_BOOT_ONENAND = $(obj)u-boot-onenand.bin +ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin +endif + __OBJS := $(subst $(obj),,$(OBJS)) __LIBS := $(subst $(obj),,$(LIBS)) $(subst $(obj),,$(LIBBOARD)) @@ -402,8 +418,13 @@ $(obj)u-boot.lds: $(LDSCRIPT) $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - <$^ >$@ nand_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend + +$(NAND_SPL): $(TIMESTAMP_FILE) $(VERSION_FILE) depend $(MAKE) -C nand_spl/board/$(BOARDDIR) all +SPL :$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools + $(MAKE) -C spl/board/$(BOARDDIR) all + $(obj)u-boot-nand.bin: nand_spl $(obj)u-boot.bin cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin > $(obj)u-boot-nand.bin @@ -1122,6 +1143,7 @@ clean: @rm -f $(obj)include/bmp_logo.h @rm -f $(obj)lib/asm-offsets.s @rm -f $(obj)nand_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,System.map} + @rm -f $(obj)spl/{u-boot-spl-generated.lds,u-boot-spl,u-boot-spl.map} @rm -f $(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl.map} @rm -f $(ONENAND_BIN) @rm -f $(obj)onenand_ipl/u-boot.lds @@ -1141,12 +1163,14 @@ clobber: clean @rm -f $(obj)u-boot $(obj)u-boot.map $(obj)u-boot.hex $(ALL) @rm -f $(obj)u-boot.kwb @rm -f $(obj)u-boot.imx + @rm -f $(obj)MLO @rm -f $(obj)tools/{env/crc32.c,inca-swap-bytes} @rm -f $(obj)arch/powerpc/cpu/mpc824x/bedbug_603e.c @rm -fr $(obj)include/asm/proc $(obj)include/asm/arch $(obj)include/asm @rm -fr $(obj)include/generated @[ ! -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 -f + @[ ! -d $(obj)spl ] || find $(obj)spl -name "*" -type l -print | xargs rm -f ifeq ($(OBJTREE),$(SRCTREE)) mrproper \ diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h index 2a84d27..2ce020e 100644 --- a/arch/arm/include/asm/global_data.h +++ b/arch/arm/include/asm/global_data.h @@ -89,6 +89,11 @@ typedef struct global_data { #define GD_FLG_DISABLE_CONSOLE 0x00040 /* Disable console (in & out) */ #define GD_FLG_ENV_READY 0x00080 /* Environment imported into hash table */ +#ifdef CONFIG_PRELOADER +/* SPL works from internal RAM. gd pointer can be in .data section */ +#define DECLARE_GLOBAL_DATA_PTR extern gd_t *gd +#else #define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r8") +#endif #endif /* __ASM_GBL_DATA_H */
Define a new type of SPL that is not tied to any particular media. - Create a top level directory 'spl' that has a structure similar to the existing 'nand_spl' - Make necessary changes to top-level Makefile to build such an spl Rationale for this approach: - There may be SPLs(like the OMAP x-loader) that support booting from multiple media. - Also, there is no harm in keeping SPLs specific to a particular media also under this directory. In fact it makes sense to merge all the different spl directories into this one. Signed-off-by: Aneesh V <aneesh@ti.com> --- This patch generates 1 checkpatch warning due to declaration of DECLARE_GLOBAL_DATA_PTR. This is un-avoidable --- Makefile | 24 ++++++++++++++++++++++++ arch/arm/include/asm/global_data.h | 5 +++++ 2 files changed, 29 insertions(+), 0 deletions(-)