From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Mon, 24 Sep 2012 19:08:35 -0500 Subject: [U-Boot] [RFC PATCH 09/17] spl/85xx: new SPL support In-Reply-To: <20120925000444.GP1797@bill-the-cat> (from trini@ti.com on Mon Sep 24 19:04:44 2012) References: <1348272087-29608-1-git-send-email-scottwood@freescale.com> <1348272087-29608-10-git-send-email-scottwood@freescale.com> <20120924235140.GM1797@bill-the-cat> <1348530864.25867.28@snotra> <20120925000444.GP1797@bill-the-cat> Message-ID: <1348531715.25867.31@snotra> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 09/24/2012 07:04:44 PM, Tom Rini wrote: > On Mon, Sep 24, 2012 at 06:54:24PM -0500, Scott Wood wrote: > > On 09/24/2012 06:51:40 PM, Tom Rini wrote: > > >On Fri, Sep 21, 2012 at 07:01:19PM -0500, Scott Wood wrote: > > > > > >> Update CONFIG_RAMBOOT and CONFIG_NAND_SPL references to accept > > >CONFIG_SPL > > >> and CONFIG_SPL_BUILD, respectively. CONFIG_NAND_SPL can be > > >removed once > > >> the last mpc85xx nand_spl target is gone. > > >> > > >> CONFIG_RAMBOOT will need to remain for other use cases, but it > > >doesn't > > >> seem right to overload it for meaning SPL as well as nand_spl > > >does. Even > > >> if it's somewhat appropriate for the main u-boot, the SPL itself > > >isn't > > >> (necessarily) ramboot, and we don't have separate configs for > > >SPL and > > >> main u-boot. It was also inconsistent, as other platforms such > as > > >> mpc83xx didn't use CONFIG_RAMBOOT in this way. > > >> > > >> Signed-off-by: Scott Wood > > >> Cc: Andy Fleming > > >[snip] > > >> diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds > > >b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds > > >> new file mode 100644 > > >> index 0000000..372195d > > >> --- /dev/null > > >> +++ b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds > > >> @@ -0,0 +1,81 @@ > > >[snip] > > >> +OUTPUT_ARCH(powerpc) > > >> +SECTIONS > > > > > >Can we add MEMORY declarations like (some) of the ARM linker > > >scripts do > > >so when we grow beyond the max size it's a link error? > > > > It's already a linker error, because you get an overlap with the > > reset vector. > > OK. Then you can drop the CONFIG_SPL_MAX_SIZE you have later on since > that's where we check against it. Or did I miss a user of it in the > series? It's used by the definition of CONFIG_SYS_NAND_U_BOOT_SIZE/DST within that same patch. Plus it's nice to document somewhere prominent, and to conform to standard SPL symbols. -Scott