| Message ID | 1307131671-22745-1-git-send-email-msm@freescale.com |
|---|---|
| State | Rejected |
| Headers | show |
Dear Matthew McClintock, In message <1307131671-22745-1-git-send-email-msm@freescale.com> you wrote: > Allow users to pass in extra defines via make so they can > modify the build. Example > > make P1022DS EXTRA_OPTS=NAND > > is equivalent to > > make P1022DS_NAND I see absolutely no sense in this, We already have a way to specify such arguments, as you write yourself in your commit message. Your new way is just more complicated, more typing effort, and as such just useless overhead. NAK. Best regards, Wolfgang Denk
On Sat, Jun 4, 2011 at 2:56 AM, Wolfgang Denk <wd@denx.de> wrote: > I see absolutely no sense in this, We already have a way to specify > such arguments, as you write yourself in your commit message. Your > new way is just more complicated, more typing effort, and as such just > useless overhead. Did you not see the other patch in the same series that makes use of this feature? It's not about actually typing it out. Let me know if you need help finding patch 3/4. -M
Dear McClintock Matthew-B29882, In message <BANLkTikCFptKvKK=PvABWgrVL4pvzcQBBw@mail.gmail.com> you wrote: > On Sat, Jun 4, 2011 at 2:56 AM, Wolfgang Denk <wd@denx.de> wrote: > > I see absolutely no sense in this, =A0We already have a way to specify > > such arguments, as you write yourself in your commit message. =A0Your > > new way is just more complicated, more typing effort, and as such just > > useless overhead. > > Did you not see the other patch in the same series that makes use of > this feature? It's not about actually typing it out. Let me know if > you need help finding patch 3/4. It does not matter if you add it here and use it there. We already have a mechanhism to do that, so no new method is needed. Please use the existing code instead oif reinventing the wheel. Best regards, Wolfgang Denk
On Sat, Jun 4, 2011 at 7:33 AM, Wolfgang Denk <wd@denx.de> wrote: >> Did you not see the other patch in the same series that makes use of >> this feature? It's not about actually typing it out. Let me know if >> you need help finding patch 3/4. > > It does not matter if you add it here and use it there. We already > have a mechanhism to do that, so no new method is needed. Please use > the existing code instead oif reinventing the wheel. How do I make a new build configuration without making changes to boards.cfg or the Makefile? I could add a new entry there for every bootstrap build but I was trying and hoping to avoid this. For example for every build I could need the following BOARD_NAND BOARD_NAND_IN_BOOTSTRAP BOARD_SPIFLASH BOARD_SPIFLASH_IN_BOOTSTRAP BOARD_SDCARD BOARD_SDCARD_IN_BOOTSTRAP I was hoping to avoid all the IN_BOOTSTRAP variants. -M
Dear McClintock Matthew-B29882, In message <BANLkTiknz2xgLw=w-FynuZo=X6AY-pUdpA@mail.gmail.com> you wrote: > > How do I make a new build configuration without making changes to > boards.cfg or the Makefile? I could add a new entry there for every > bootstrap build but I was trying and hoping to avoid this. For example > for every build I could need the following > > BOARD_NAND > BOARD_NAND_IN_BOOTSTRAP > BOARD_SPIFLASH > BOARD_SPIFLASH_IN_BOOTSTRAP > BOARD_SDCARD > BOARD_SDCARD_IN_BOOTSTRAP Are these independent targets? I think you don't run a "./MAKEALL BOARD_SDCARD_IN_BOOTSTRAP" alone, right? You can set all types of make variable sinternally during different stages of the build, like we already do with the nand_spl code. I have to admit that I don't even understand why you would need separate top-level FOO and FOO_IN_BOOTSTRAP make targets. Please elucidate. Best regards, Wolfgang Denk
On Tue, Jun 7, 2011 at 3:04 PM, Wolfgang Denk <wd@denx.de> wrote: >> BOARD_NAND >> BOARD_NAND_IN_BOOTSTRAP >> BOARD_SPIFLASH >> BOARD_SPIFLASH_IN_BOOTSTRAP >> BOARD_SDCARD >> BOARD_SDCARD_IN_BOOTSTRAP > > Are these independent targets? I think you don't run a > "./MAKEALL BOARD_SDCARD_IN_BOOTSTRAP" alone, right? Correct, however I was hoping to use a normal build system to make this image. With the only difference being that CONFIG_IN_BOOTSTRAP is defined when parsing the board config file. > You can set all types of make variable sinternally during different > stages of the build, like we already do with the nand_spl code. Right but nand_spl provides more Makefiles for building it's own image. I want to reuse the normal u-boot build system to create this shim/bootstrap image. > I have to admit that I don't even understand why you would need > separate top-level FOO and FOO_IN_BOOTSTRAP make targets. Please > elucidate. Sorry, let me try to explain some more. Certain boards require some sort of shim, or spl for booting from media other than NOR on our parts. We need this shim to perform DDR initialization. This shim does not need to be anything but a stripped down version of u-boot since it needs to be <256k and contain the DDR SPD initialization code. Therefore I just wanted to reuse the u-boot build system as is and add some configuration changes to create all the final images for booting this board. So when I build a target for my board the following happens: make FOO -> builds u-boot.bin to run from RAM -> calls make FOO_IN_BOOTSTRAP to run from L2 and configure DDR -> NAND will also have a nand_spl shim as well (where as SDCARD and SPI booting currently do not have support in u-boot for making this shim) The FOO_IN_BOOTSTRAP build above creates a u-boot image that runs from L2 and its BOOTCOMMAND is set such that it will automatically load the final u-boot image from the boot media to ram and then execute the full version of u-boot. -M
diff --git a/mkconfig b/mkconfig index 6ff533f..77ddc1b 100755 --- a/mkconfig +++ b/mkconfig @@ -72,9 +72,13 @@ fi # Check if we only have a colon... if [ "${tmp}" != "$7" ] ; then options=${7#*:} - TARGETS="`echo ${options} | sed 's:,: :g'` ${TARGETS}" fi } +# Append options passed in via EXTRA_OPTS +if [ -n "$EXTRA_OPTS" ] ; then + options=${options:+${options},}${EXTRA_OPTS} +fi +TARGETS="`echo ${options} | sed 's:,: :g'` ${TARGETS}" if [ "${ARCH}" -a "${ARCH}" != "${arch}" ]; then echo "Failed: \$ARCH=${ARCH}, should be '${arch}' for ${BOARD_NAME}" 1>&2
Allow users to pass in extra defines via make so they can modify the build. Example make P1022DS EXTRA_OPTS=NAND is equivalent to make P1022DS_NAND Signed-off-by: Matthew McClintock <msm@freescale.com> --- v2: Fix tab indention, fix posix compliance v3: Move appending $EXTRA_OPTS up higher before we set $TARGETS so we only need to append $EXTRA_OPTS to $options and not $TARGETS mkconfig | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-)