From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?= Date: Mon, 18 Feb 2013 19:22:58 +0100 (CET) Subject: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding In-Reply-To: <1361210569.14186.2@snotra> References: <1360961665-10693-1-git-send-email-benoit.thebaudeau@advansee.com> <1360961665-10693-13-git-send-email-benoit.thebaudeau@advansee.com> <1954515158.1528901.1361117809127.JavaMail.root@advansee.com> <20130218165059.GB30970@bill-the-cat> <28742411.1551753.1361208406225.JavaMail.root@advansee.com> <51226496.8070509@ti.com> <1440655831.1552569.1361210452143.JavaMail.root@advansee.com> <1361210569.14186.2@snotra> Message-ID: <845050354.1555601.1361211777995.JavaMail.root@advansee.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Monday, February 18, 2013 7:02:49 PM, Scott Wood wrote: > On 02/18/2013 12:00:52 PM, Beno?t Th?baudeau wrote: > > On Monday, February 18, 2013 6:27:50 PM, Tom Rini wrote: > > > > Commit 74752ba performs a '--pad-to=$(or $(CONFIG_SPL_PAD_TO),0)' > > > > on u-boot-spl. I could use this CONFIG_SPL_PAD_TO for this series > > > > too, but is it really necessary to have both CONFIG_SPL_PAD_TO and > > > > CONFIG_SPL_MAX_SIZE? In other words, is there any case for which > > > > CONFIG_SPL_PAD_TO could be different from CONFIG_SPL_TEXT_BASE + > > > > CONFIG_SPL_MAX_SIZE for a valid reason? > > They're logically different things. > > > > I was wondering along those lines. I don't _think_ we need both > > > CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE, but we can't combine > > > CONFIG_SPL_MAX_SIZE and CONFIG_SPL_TEXT_BASE as on TI platforms we > > > start quite well above zero (0x402F0400 on am33xx, etc). That > > said, I > > > guess we do need CONFIG_SPL_PAD_TO so that some platforms can do: > > > #define CONFIG_SPL_PAD_TO (CONFIG_SPL_TEXT_BASE + > > CONFIG_SPL_MAX_SIZE) > > > and others just > > > #define CONFIG_SPL_PAD_TO CONFIG_SPL_MAX_SIZE > > > > If we did like my patch here, i.e. use objcopy with u-boot-spl.bin > > instead of > > u-boot-spl, objcopy would always get a fake 0x0 address at the > > beginning of the > > .bin, so CONFIG_SPL_MAX_SIZE could be used with --pad-to, and > > CONFIG_SPL_PAD_TO > > would be useless. > > > > The only question is if we may need to have an empty gap between the > > SPL and > > U-Boot within the resulting image. I don't think so since that would > > mean that > > the target memory device has an area that is not really available at > > the > > location of this gap. > > Why not allow that possibility? To save a config setting (there are already many for SPL) if this is not strictly required, but also for the reason below. > Maybe it's easier for the SPL to load > from a particular offset (e.g. NAND starting at the beginning of a > block)? CONFIG_SPL_MAX_SIZE would be closer to a NAND mapping in that case (e.g. size of 1 NAND Flash block) than CONFIG_SPL_PAD_TO (address within RAM that should be considered relatively to CONFIG_SPL_TEXT_BASE to get the NAND offset). Also, CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE depend on each other: If both can be defined, you may change one forgetting the other one, which could e.g. result in an overlapping of SPL and U-Boot that won't show up at build time (with CONFIG_SPL_MAX_SIZE = 0x1000 and CONFIG_SPL_PAD_TO = CONFIG_SPL_TEXT_BASE + 0x800, the SPL would build fine, and objcopy wouldn't complain). Best regards, Beno?t