| Message ID | 1305472900-4004-9-git-send-email-aneesh@ti.com |
|---|---|
| State | Changes Requested |
| Headers | show |
Dear Aneesh V, In message <1305472900-4004-9-git-send-email-aneesh@ti.com> you wrote: > Add the basic spl framework and linker script common for OMAP3/4 > platforms. > > Signed-off-by: Aneesh V <aneesh@ti.com> > --- > spl/board/ti/spl-omap.c | 47 ++++++++++++++++++++++++++++++++++ > spl/board/ti/spl-omap.lds | 62 +++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 109 insertions(+), 0 deletions(-) > create mode 100644 spl/board/ti/spl-omap.c > create mode 100644 spl/board/ti/spl-omap.lds Again, this appears to be not the right order. I think, in the first step of this series, we should move the existing code from nand_spl and onenand_ipl into something like spl/nand and spl/onenand, respectivly, and make sure all teh existing systems still build. The we can add more such support. Best regards, Wolfgang Denk
Dear Aneesh V, In message <1305472900-4004-9-git-send-email-aneesh@ti.com> you wrote: > Add the basic spl framework and linker script common for OMAP3/4 > platforms. > > Signed-off-by: Aneesh V <aneesh@ti.com> ... > +void board_init_r(gd_t *id, ulong dummy) > +{ > + for (;;) > + ; > +} Also, this cannot be right. Best regards, Wolfgang Denk
Hi Aneesh, I recently started to work on a similar topic: omap3 (devkit8000) nand_spl support. So I'am really interested in your OMAP4/common work here ;) In this patch comment you say its common for OMAP3/4 but in preloader_console_init() is a call to omap4_rev_string()): > printf("Texas Instruments %s\n", omap4_rev_string()); Regards Simon 2011/5/15 Aneesh V <aneesh@ti.com> > Add the basic spl framework and linker script common for OMAP3/4 > platforms. > > Signed-off-by: Aneesh V <aneesh@ti.com> > --- > spl/board/ti/spl-omap.c | 47 ++++++++++++++++++++++++++++++++++ > spl/board/ti/spl-omap.lds | 62 > +++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 109 insertions(+), 0 deletions(-) > create mode 100644 spl/board/ti/spl-omap.c > create mode 100644 spl/board/ti/spl-omap.lds > > diff --git a/spl/board/ti/spl-omap.c b/spl/board/ti/spl-omap.c > new file mode 100644 > index 0000000..0e08f4f > --- /dev/null > +++ b/spl/board/ti/spl-omap.c > @@ -0,0 +1,47 @@ > +/* > + * > + * Clock initialization for OMAP4 > + * > + * (C) Copyright 2010 > + * Texas Instruments, <www.ti.com> > + * > + * Aneesh V <aneesh@ti.com> > + * > + * See file CREDITS for list of people who contributed to this > + * project. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of > + * the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, > + * MA 02111-1307 USA > + */ > +#include <common.h> > +#include <asm/u-boot.h> > +#include <asm/arch/sys_proto.h> > +#include <timestamp_autogenerated.h> > + > +/* Define global data structure pointer to it*/ > +gd_t gdata __attribute__ ((section(".data"))); > +bd_t bdata __attribute__ ((section(".data"))); > +gd_t *gd = &gdata; > + > +void board_init_f(ulong dummy) > +{ > + relocate_code(CONFIG_SYS_SPL_STACK, &gdata, > CONFIG_SYS_SPL_TEXT_BASE); > +} > + > +void board_init_r(gd_t *id, ulong dummy) > +{ > + for (;;) > + ; > +} > diff --git a/spl/board/ti/spl-omap.lds b/spl/board/ti/spl-omap.lds > new file mode 100644 > index 0000000..674ef05 > --- /dev/null > +++ b/spl/board/ti/spl-omap.lds > @@ -0,0 +1,62 @@ > +/* > + * (C) Copyright 2002 > + * Gary Jennejohn, DENX Software Engineering, <garyj@denx.de> > + * > + * (C) Copyright 2010 > + * Texas Instruments, <www.ti.com> > + * Aneesh V <aneesh@ti.com> > + * > + * See file CREDITS for list of people who contributed to this > + * project. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of > + * the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, > + * MA 02111-1307 USA > + */ > + > +MEMORY { .sram : ORIGIN = CONFIG_SYS_SPL_TEXT_BASE,\ > + LENGTH = CONFIG_SYS_SPL_MAX_SIZE } > +MEMORY { .sdram : ORIGIN = CONFIG_SYS_SPL_BSS_START_ADDR, \ > + LENGTH = CONFIG_SYS_SPL_BSS_MAX_SIZE } > + > +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") > +OUTPUT_ARCH(arm) > +ENTRY(_start) > +SECTIONS > +{ > + .text : > + { > + __start = .; > + start.o (.text) > + *(.text*) > + } >.sram > + > + . = ALIGN(4); > + .rodata : { *(SORT_BY_ALIGNMENT(.rodata*)) } >.sram > + > + . = ALIGN(4); > + .data : { *(SORT_BY_ALIGNMENT(.data*)) } >.sram > + . = ALIGN(4); > + __image_copy_end = .; > + _end = .; > + > + .bss : > + { > + . = ALIGN(4); > + __bss_start = .; > + *(.bss*) > + . = ALIGN(4); > + __bss_end__ = .; > + } >.sdram > +} > -- > 1.7.0.4 > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot >
Hi Wolfgang, On Monday 16 May 2011 01:22 AM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<1305472900-4004-9-git-send-email-aneesh@ti.com> you wrote: >> Add the basic spl framework and linker script common for OMAP3/4 >> platforms. >> >> Signed-off-by: Aneesh V<aneesh@ti.com> >> --- >> spl/board/ti/spl-omap.c | 47 ++++++++++++++++++++++++++++++++++ >> spl/board/ti/spl-omap.lds | 62 +++++++++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 109 insertions(+), 0 deletions(-) >> create mode 100644 spl/board/ti/spl-omap.c >> create mode 100644 spl/board/ti/spl-omap.lds > > Again, this appears to be not the right order. > > I think, in the first step of this series, we should move the existing > code from nand_spl and onenand_ipl into something like spl/nand and > spl/onenand, respectivly, and make sure all teh existing systems still > build. The we can add more such support. IMHO, we should just have spl/board/<vendor>/<board>/ . Let spl/board/<vendor>/<board>/Makefile decide what it wants to build. I mean something like this(similar changes for ONENAND): +.PHONEY : SPL +SPL :$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools + $(MAKE) -C spl/board/$(BOARDDIR) all + +ifeq ($(CONFIG_SPL),y) +ALL += SPL +endif + __OBJS := $(subst $(obj),,$(OBJS)) __LIBS := $(subst $(obj),,$(LIBS)) $(subst $(obj),,$(LIBBOARD)) @@ -401,11 +409,8 @@ $(LDSCRIPT): depend $(obj)u-boot.lds: $(LDSCRIPT) $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - <$^ >$@ -nand_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend - $(MAKE) -C nand_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 +$(obj)u-boot-nand.bin: SPL $(obj)u-boot.bin + cat $(obj)spl/u-boot-spl-16k.bin $(obj)u-boot.bin > $(obj)u-boot-nand.bin > > Best regards, > > Wolfgang Denk >
Hi Wolfgang, On Monday 16 May 2011 01:23 AM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<1305472900-4004-9-git-send-email-aneesh@ti.com> you wrote: >> Add the basic spl framework and linker script common for OMAP3/4 >> platforms. >> >> Signed-off-by: Aneesh V<aneesh@ti.com> > ... >> +void board_init_r(gd_t *id, ulong dummy) >> +{ >> + for (;;) >> + ; >> +} > > Also, this cannot be right. I added the features one by one in the subsequent patches and removed that loop. Maybe I should squash some patches here too. > > Best regards, > > Wolfgang Denk >
Hi Simon, On Monday 16 May 2011 03:18 PM, Simon Schwarz wrote: > Hi Aneesh, > > I recently started to work on a similar topic: omap3 (devkit8000) > nand_spl support. So I'am really interested in your OMAP4/common work > here ;) > > In this patch comment you say its common for OMAP3/4 but in > preloader_console_init() is a call to omap4_rev_string()): > > printf("Texas Instruments %s\n", omap4_rev_string()); Thank you for pointing it out. I will change it to omap_rev_string() best regards, Aneesh
Dear Aneesh V, In message <4DD13056.3000509@ti.com> you wrote: > > > Again, this appears to be not the right order. > > > > I think, in the first step of this series, we should move the existing > > code from nand_spl and onenand_ipl into something like spl/nand and > > spl/onenand, respectivly, and make sure all teh existing systems still > > build. The we can add more such support. > > IMHO, we should just have spl/board/<vendor>/<board>/ . > > Let spl/board/<vendor>/<board>/Makefile decide what it wants to > build. There are common, board independent parts both in spl/nand and spl/onenand. Best regards, Wolfgang Denk
On Mon, 16 May 2011 19:40:30 +0530 Aneesh V <aneesh@ti.com> wrote: > Hi Wolfgang, > > On Monday 16 May 2011 01:22 AM, Wolfgang Denk wrote: > > I think, in the first step of this series, we should move the existing > > code from nand_spl and onenand_ipl into something like spl/nand and > > spl/onenand, respectivly, and make sure all teh existing systems still > > build. The we can add more such support. > > IMHO, we should just have spl/board/<vendor>/<board>/ . > > Let spl/board/<vendor>/<board>/Makefile decide what it wants to > build. That's what we do in nand_spl/onenand_spl -- the common files are more like libraries that the board makefile may or may not pull in (e.g. many Freescale boards use nand_boot_fsl_elbc.c or nand_boot_fsl_nfc.c instead of nand_boot.c). Renaming nand_spl seems like it should be the first step. > I mean something like this(similar changes for ONENAND): > > +.PHONEY : SPL .PHONY -Scott
Hi Wolfgang, On Monday 16 May 2011 09:13 PM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<4DD13056.3000509@ti.com> you wrote: >> >>> Again, this appears to be not the right order. >>> >>> I think, in the first step of this series, we should move the existing >>> code from nand_spl and onenand_ipl into something like spl/nand and >>> spl/onenand, respectivly, and make sure all teh existing systems still >>> build. The we can add more such support. >> >> IMHO, we should just have spl/board/<vendor>/<board>/ . >> >> Let spl/board/<vendor>/<board>/Makefile decide what it wants to >> build. > > There are common, board independent parts both in spl/nand and > spl/onenand. > How about having them at the root level in 'spl/' ? best regards, Aneesh
Dear Aneesh V, In message <4DD21CD8.2080409@ti.com> you wrote: > > > There are common, board independent parts both in spl/nand and > > spl/onenand. > > How about having them at the root level in 'spl/' ? Why? It seems more logical to me to group nand and onenand related files in their own subdirectories. Best regards, Wolfgang Denk
Hi Scott, On Tuesday 17 May 2011 12:09 AM, Scott Wood wrote: > On Mon, 16 May 2011 19:40:30 +0530 > Aneesh V<aneesh@ti.com> wrote: > >> Hi Wolfgang, >> >> On Monday 16 May 2011 01:22 AM, Wolfgang Denk wrote: >>> I think, in the first step of this series, we should move the existing >>> code from nand_spl and onenand_ipl into something like spl/nand and >>> spl/onenand, respectivly, and make sure all teh existing systems still >>> build. The we can add more such support. >> >> IMHO, we should just have spl/board/<vendor>/<board>/ . >> >> Let spl/board/<vendor>/<board>/Makefile decide what it wants to >> build. > > That's what we do in nand_spl/onenand_spl -- the common files are more like > libraries that the board makefile may or may not pull in (e.g. many > Freescale boards use nand_boot_fsl_elbc.c or nand_boot_fsl_nfc.c instead of > nand_boot.c). > > Renaming nand_spl seems like it should be the first step. > >> I mean something like this(similar changes for ONENAND): >> >> +.PHONEY : SPL > > .PHONY Oops! I wonder how it was working then. My real patch too had the same mistake! best regards, Aneesh
On Wed, 18 May 2011 10:35:56 +0530 Aneesh V <aneesh@ti.com> wrote: > On Tuesday 17 May 2011 12:09 AM, Scott Wood wrote: > >> +.PHONEY : SPL > > > > .PHONY > > Oops! I wonder how it was working then. My real patch too had the same > mistake! Well, .PHONY is mainly a performance hint if there's no actual file or rule with that name. -Scott
Hi Wolfgang, On Tuesday 17 May 2011 01:46 PM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<4DD21CD8.2080409@ti.com> you wrote: >> >>> There are common, board independent parts both in spl/nand and >>> spl/onenand. >> >> How about having them at the root level in 'spl/' ? > > Why? It seems more logical to me to group nand and onenand related > files in their own subdirectories. I do not have any issue in having media specific files in their respective directories. However, I would like to see the 'Makefile's coming from the same directory tree irrespective of the media. So, how about something like this: spl/ mmc/ nand/ one-nand/ board/<vendor>/<board>/Makefile The idea is to have the board level Makefile in 'spl/board/<vendor> /<board>/' no matter what the SPL type is. This will help in better consolidation of SPLs. I see 3 SPL use-cases in general: 1. A single SPL that supports multiple media(suitable for SoCs with large internal RAM) 2. A single SPL supporting a single media(the board supports only one media) 3. Multiple SPLs for the same board each supporting a different memory device(maybe preferred over 1 to keep the foot-print of each small). Supporting (1) and (2) is straight forward with the above directory structure. To support (3) the board level Makefile should conditionally include the respective image file in the target 'all' based on CONFIG options. For instance 'all' may include 'onenand-ipl-2k.bin' if CONFIG_ONENAND_U_BOOT is defined and so on. Please let me know if any of you have better ideas. I would like to finalize on this before re-working on my patch-set. best regards, Aneesh
Hi Wolfgang, On Thursday 26 May 2011 07:21 PM, Aneesh V wrote: > Hi Wolfgang, > On Tuesday 17 May 2011 01:46 PM, Wolfgang Denk wrote: >> Dear Aneesh V, >> >> In message<4DD21CD8.2080409@ti.com> you wrote: >>> >>>> There are common, board independent parts both in spl/nand and >>>> spl/onenand. >>> >>> How about having them at the root level in 'spl/' ? >> >> Why? It seems more logical to me to group nand and onenand related >> files in their own subdirectories. > > I do not have any issue in having media specific files in their > respective directories. However, I would like to see the 'Makefile's > coming from the same directory tree irrespective of the media. So, how > about something like this: > > spl/ > mmc/ > nand/ > one-nand/ > board/<vendor>/<board>/Makefile > > The idea is to have the board level Makefile in 'spl/board/<vendor> > /<board>/' no matter what the SPL type is. This will help in better > consolidation of SPLs. > > I see 3 SPL use-cases in general: > 1. A single SPL that supports multiple media(suitable for SoCs with > large internal RAM) > 2. A single SPL supporting a single media(the board supports only one > media) > 3. Multiple SPLs for the same board each supporting a different > memory device(maybe preferred over 1 to keep the foot-print of each > small). > > Supporting (1) and (2) is straight forward with the above directory > structure. > > To support (3) the board level Makefile should conditionally > include the respective image file in the target 'all' based on CONFIG > options. For instance 'all' may include 'onenand-ipl-2k.bin' if > CONFIG_ONENAND_U_BOOT is defined and so on. > > Please let me know if any of you have better ideas. I would like to > finalize on this before re-working on my patch-set. What's your views on the above scheme. best regards, Aneesh
Hi Wolfgang, On Thursday 26 May 2011 07:21 PM, Aneesh V wrote: > Hi Wolfgang, > On Tuesday 17 May 2011 01:46 PM, Wolfgang Denk wrote: >> Dear Aneesh V, >> >> In message<4DD21CD8.2080409@ti.com> you wrote: >>> >>>> There are common, board independent parts both in spl/nand and >>>> spl/onenand. >>> >>> How about having them at the root level in 'spl/' ? >> >> Why? It seems more logical to me to group nand and onenand related >> files in their own subdirectories. > > I do not have any issue in having media specific files in their > respective directories. However, I would like to see the 'Makefile's > coming from the same directory tree irrespective of the media. So, how > about something like this: > > spl/ > mmc/ > nand/ > one-nand/ > board/<vendor>/<board>/Makefile > > The idea is to have the board level Makefile in 'spl/board/<vendor> > /<board>/' no matter what the SPL type is. This will help in better > consolidation of SPLs. > > I see 3 SPL use-cases in general: > 1. A single SPL that supports multiple media(suitable for SoCs with > large internal RAM) > 2. A single SPL supporting a single media(the board supports only one > media) > 3. Multiple SPLs for the same board each supporting a different > memory device(maybe preferred over 1 to keep the foot-print of each > small). > > Supporting (1) and (2) is straight forward with the above directory > structure. > > To support (3) the board level Makefile should conditionally > include the respective image file in the target 'all' based on CONFIG > options. For instance 'all' may include 'onenand-ipl-2k.bin' if > CONFIG_ONENAND_U_BOOT is defined and so on. > > Please let me know if any of you have better ideas. I would like to > finalize on this before re-working on my patch-set. Are you fine with this scheme. Appreciate if you could let me know your thoughts on this. I am waiting for your inputs to start the re-work. best regards, Aneesh
Dear Aneesh V, In message <4DDE5AFE.9000404@ti.com> you wrote: > > I do not have any issue in having media specific files in their > respective directories. However, I would like to see the 'Makefile's > coming from the same directory tree irrespective of the media. So, how > about something like this: > > spl/ > mmc/ > nand/ > one-nand/ > board/<vendor>/<board>/Makefile Actually that would be board/[<vendor>/]<board>/ > The idea is to have the board level Makefile in 'spl/board/<vendor> > /<board>/' no matter what the SPL type is. This will help in better > consolidation of SPLs. OK. > I see 3 SPL use-cases in general: > 1. A single SPL that supports multiple media(suitable for SoCs with > large internal RAM) > 2. A single SPL supporting a single media(the board supports only one > media) 1. and 2. are actually the same (2. being the special case of N=1) > 3. Multiple SPLs for the same board each supporting a different > memory device(maybe preferred over 1 to keep the foot-print of each > small). > > Supporting (1) and (2) is straight forward with the above directory > structure. > > To support (3) the board level Makefile should conditionally > include the respective image file in the target 'all' based on CONFIG > options. For instance 'all' may include 'onenand-ipl-2k.bin' if > CONFIG_ONENAND_U_BOOT is defined and so on. I don't get this. Why don't we just pass the required make target from the top level Makefile? If we want to build "onenand-ipl-2k.bin" then this would result in running "make onenand-ipl-2k.bin" in the respective directory - this is then also independent of whether this image contains support for one specific boot device or for any set of different devices. Best regards, Wolfgang Denk
Dear Wolfgang, On Wednesday 15 June 2011 03:43 PM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<4DDE5AFE.9000404@ti.com> you wrote: >> >> I do not have any issue in having media specific files in their >> respective directories. However, I would like to see the 'Makefile's >> coming from the same directory tree irrespective of the media. So, how >> about something like this: >> >> spl/ >> mmc/ >> nand/ >> one-nand/ >> board/<vendor>/<board>/Makefile > > Actually that would be > > board/[<vendor>/]<board>/ > >> The idea is to have the board level Makefile in 'spl/board/<vendor> >> /<board>/' no matter what the SPL type is. This will help in better >> consolidation of SPLs. > > OK. > >> I see 3 SPL use-cases in general: >> 1. A single SPL that supports multiple media(suitable for SoCs with >> large internal RAM) >> 2. A single SPL supporting a single media(the board supports only one >> media) > > 1. and 2. are actually the same (2. being the special case of N=1) > >> 3. Multiple SPLs for the same board each supporting a different >> memory device(maybe preferred over 1 to keep the foot-print of each >> small). >> >> Supporting (1) and (2) is straight forward with the above directory >> structure. >> >> To support (3) the board level Makefile should conditionally >> include the respective image file in the target 'all' based on CONFIG >> options. For instance 'all' may include 'onenand-ipl-2k.bin' if >> CONFIG_ONENAND_U_BOOT is defined and so on. > > I don't get this. Why don't we just pass the required make target > from the top level Makefile? If we want to build "onenand-ipl-2k.bin" > then this would result in running "make onenand-ipl-2k.bin" in the > respective directory - this is then also independent of whether this > image contains support for one specific boot device or for any set of > different devices. Then you will have to deal with many such images in the top-level Makefile(u-boot/Makefile). Instead why not have just one rule like the below in the top-level Makefile for all the different spl's: SPL :$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools $(MAKE) -C spl/board/$(BOARDDIR) all And leave the rest to the board level Makefiles Of course, this is assuming the existing Makefile structure. With the new Makefile structure you are suggesting this may not hold good.
Dear Aneesh, In message <4DF88F45.9090905@ti.com> you wrote: > > > I don't get this. Why don't we just pass the required make target > > from the top level Makefile? If we want to build "onenand-ipl-2k.bin" > > then this would result in running "make onenand-ipl-2k.bin" in the > > respective directory - this is then also independent of whether this > > image contains support for one specific boot device or for any set of > > different devices. > > Then you will have to deal with many such images in the top-level > Makefile(u-boot/Makefile). Instead why not have just one rule like the > below in the top-level Makefile for all the different spl's: > > > SPL :$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools > $(MAKE) -C spl/board/$(BOARDDIR) all > > And leave the rest to the board level Makefiles We just discussed that there are cases where there may be no board level Makefile be needed at all, because there is no board specific code to handle. Also, why would there be many such images? We might just want to use more reasonable names. We have "u-boot.bin", and this works fine for all boards, so why cannot we make it that "u-boot-nand.bin" works for all boards booting from NAND, and in general "u-boot-<DEV>.bin" works for all boards booting from a <DEV> boot device? Instead of "onenand-ipl-2k.bin", we would just have a generic "u-boot-onenand.bin" > Of course, this is assuming the existing Makefile structure. With the > new Makefile structure you are suggesting this may not hold good. Why not? Best regards, Wolfgang Denk
Dear Wolfgang, On Wednesday 15 June 2011 05:34 PM, Wolfgang Denk wrote: > Dear Aneesh, > > In message<4DF88F45.9090905@ti.com> you wrote: >> >>> I don't get this. Why don't we just pass the required make target >>> from the top level Makefile? If we want to build "onenand-ipl-2k.bin" >>> then this would result in running "make onenand-ipl-2k.bin" in the >>> respective directory - this is then also independent of whether this >>> image contains support for one specific boot device or for any set of >>> different devices. >> >> Then you will have to deal with many such images in the top-level >> Makefile(u-boot/Makefile). Instead why not have just one rule like the >> below in the top-level Makefile for all the different spl's: >> >> >> SPL :$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools >> $(MAKE) -C spl/board/$(BOARDDIR) all >> >> And leave the rest to the board level Makefiles > > We just discussed that there are cases where there may be no board > level Makefile be needed at all, because there is no board specific > code to handle. > > Also, why would there be many such images? We might just want to use > more reasonable names. We have "u-boot.bin", and this works fine for > all boards, so why cannot we make it that "u-boot-nand.bin" works for > all boards booting from NAND, and in general "u-boot-<DEV>.bin" works > for all boards booting from a<DEV> boot device? > > Instead of "onenand-ipl-2k.bin", we would just have a generic > "u-boot-onenand.bin" > >> Of course, this is assuming the existing Makefile structure. With the >> new Makefile structure you are suggesting this may not hold good. > > Why not? I was saying that my suggestion of delegating everything to board level Makefile will not work with the new top-down approach you are suggesting in the other mail-chain. best regards, Aneesh
Dear Aneesh V, In message <4DF8A0C0.2040900@ti.com> you wrote: > > >> Of course, this is assuming the existing Makefile structure. With the > >> new Makefile structure you are suggesting this may not hold good. > > > > Why not? > > I was saying that my suggestion of delegating everything to board level > Makefile will not work with the new top-down approach you are > suggesting in the other mail-chain. I did not suggest this. On contrary, I think I pointed out that we might have cases where no board directory (and thus no board specific Makefile) will be needed at all. Best regards, Wolfgang Denk
diff --git a/spl/board/ti/spl-omap.c b/spl/board/ti/spl-omap.c new file mode 100644 index 0000000..0e08f4f --- /dev/null +++ b/spl/board/ti/spl-omap.c @@ -0,0 +1,47 @@ +/* + * + * Clock initialization for OMAP4 + * + * (C) Copyright 2010 + * Texas Instruments, <www.ti.com> + * + * Aneesh V <aneesh@ti.com> + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ +#include <common.h> +#include <asm/u-boot.h> +#include <asm/arch/sys_proto.h> +#include <timestamp_autogenerated.h> + +/* Define global data structure pointer to it*/ +gd_t gdata __attribute__ ((section(".data"))); +bd_t bdata __attribute__ ((section(".data"))); +gd_t *gd = &gdata; + +void board_init_f(ulong dummy) +{ + relocate_code(CONFIG_SYS_SPL_STACK, &gdata, CONFIG_SYS_SPL_TEXT_BASE); +} + +void board_init_r(gd_t *id, ulong dummy) +{ + for (;;) + ; +} diff --git a/spl/board/ti/spl-omap.lds b/spl/board/ti/spl-omap.lds new file mode 100644 index 0000000..674ef05 --- /dev/null +++ b/spl/board/ti/spl-omap.lds @@ -0,0 +1,62 @@ +/* + * (C) Copyright 2002 + * Gary Jennejohn, DENX Software Engineering, <garyj@denx.de> + * + * (C) Copyright 2010 + * Texas Instruments, <www.ti.com> + * Aneesh V <aneesh@ti.com> + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +MEMORY { .sram : ORIGIN = CONFIG_SYS_SPL_TEXT_BASE,\ + LENGTH = CONFIG_SYS_SPL_MAX_SIZE } +MEMORY { .sdram : ORIGIN = CONFIG_SYS_SPL_BSS_START_ADDR, \ + LENGTH = CONFIG_SYS_SPL_BSS_MAX_SIZE } + +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") +OUTPUT_ARCH(arm) +ENTRY(_start) +SECTIONS +{ + .text : + { + __start = .; + start.o (.text) + *(.text*) + } >.sram + + . = ALIGN(4); + .rodata : { *(SORT_BY_ALIGNMENT(.rodata*)) } >.sram + + . = ALIGN(4); + .data : { *(SORT_BY_ALIGNMENT(.data*)) } >.sram + . = ALIGN(4); + __image_copy_end = .; + _end = .; + + .bss : + { + . = ALIGN(4); + __bss_start = .; + *(.bss*) + . = ALIGN(4); + __bss_end__ = .; + } >.sdram +}
Add the basic spl framework and linker script common for OMAP3/4 platforms. Signed-off-by: Aneesh V <aneesh@ti.com> --- spl/board/ti/spl-omap.c | 47 ++++++++++++++++++++++++++++++++++ spl/board/ti/spl-omap.lds | 62 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 109 insertions(+), 0 deletions(-) create mode 100644 spl/board/ti/spl-omap.c create mode 100644 spl/board/ti/spl-omap.lds