From: Denys Dmytriyenko <denys@ti.com>
To: Murali Karicheri <m-karicheri2@ti.com>
Cc: meta-ti@yoctoproject.org
Subject: Re: [RESEND: PATCH 2/3] keystone2: u-boot: update to add gph support
Date: Tue, 7 May 2013 17:52:05 -0400 [thread overview]
Message-ID: <20130507215205.GF12982@edge> (raw)
In-Reply-To: <1367961859-6243-2-git-send-email-m-karicheri2@ti.com>
On Tue, May 07, 2013 at 05:24:18PM -0400, Murali Karicheri wrote:
> This patch add support for
> 1) switch between release and nightly builds
> 2) support for building gph images
>
> Also fixed the COMPATIBLE_MACHINE to keystone-evm
>
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> ---
> recipes-bsp/u-boot/u-boot-keystone_2013.01.bb | 79 +++++++++++++++++++++++--
> 1 file changed, 74 insertions(+), 5 deletions(-)
>
> diff --git a/recipes-bsp/u-boot/u-boot-keystone_2013.01.bb b/recipes-bsp/u-boot/u-boot-keystone_2013.01.bb
> index 788d813..bfe5111 100644
> --- a/recipes-bsp/u-boot/u-boot-keystone_2013.01.bb
> +++ b/recipes-bsp/u-boot/u-boot-keystone_2013.01.bb
> @@ -1,16 +1,85 @@
> require u-boot-ti.inc
>
> DESCRIPTION = "u-boot bootloader for Multi-Core BU devices"
> +LICENSE = "GPLv2+"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=1707d6db1d42237583f50183a5651ecb"
These 2 lines are not needed - check u-boot-ti.inc file that sets licensing
already.
> -COMPATIBLE_MACHINE = "keystone"
> +COMPATIBLE_MACHINE = "keystone-evm"
This is also not needed - you are changing recipe compatibility from a broader
Keystone SOC to a more strict Keystone EVM. Right now it is pretty much the
same, but in the future there maybe more machines in a Keystone SOC family.
> -PR = "r2+gitr${SRCPV}"
> +PACKAGE_ARCH = "${MACHINE_ARCH}"
Not needed for PACKAGE_ARCH - set in u-boot-ti.inc
> -SRC_URI = "git://arago-project.org/git/projects/u-boot-keystone.git;protocol=git;branch=${BRANCH}"
> +PR = "r3+gitr${SRCPV}"
> +
> +# for nightly switch the two below
> +#SRC_URI = "git://arago-project.org/git/projects/u-boot-keystone.git;protocol=git;branch=${BRANCH}"
> +SRC_URI = "git://gtgit01.gt.design.ti.com/git/projects/u-boot-keystone.git;protocol=git;branch=${BRANCH}"
See below about pointing SRC_URI to an internal git server.
> BRANCH = "master"
>
> -# DEV.MCSDK-03.00.00.07
> -SRCREV = "82f40e857d853165310d0753e79235aefb65d7ba"
Please use the format above - it avoid unnecessary breakages when
git-ls-remote is not working...
> +# for nightly switch the two below
> +#SRCREV = "DEV.MCSDK-2013-01.10"
> +SRCREV = "${AUTOREV}"
Same as before - please no AUTOREVs in meta-ti.
If you need to track daily/nightly progress from an internal git server,
please use a .bbappend in meta-arago, while keeping meta-ti pointing to a
piblic git server and using a specific commit ID. Let me know if you need
existing examples - we just released Core TI-SDK 2013.04.00 which used to
track the latest linux-ti-staging kernel by setting AUTOREV in meta-arago.
> +EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${TARGET_PREFIX}gcc ${TOOLCHAIN_OPTIONS}"'
No need for this line - set in u-boot.inc
> +S = "${WORKDIR}/git"
This one is also already set.
> UBOOT_SUFFIX = "bin"
> +
> +UBOOT_MAKE_TARGET = "u-boot-spi.gph"
> +# SPI NOR Flash binaries
> +UBOOT_SPI_SPL_BINARY = "u-boot-spl.bin"
> +UBOOT_SPI_BINARY = "u-boot.img"
> +UBOOT_SPI_GPH_BINARY = "u-boot-spi.gph"
> +# SPI NOR Flash deployed images
> +UBOOT_SPI_SPL_IMAGE = "u-boot-spl-${MACHINE}-${PV}-${PR}.bin"
> +UBOOT_SPI_SPL_SYMLINK = "u-boot-spl-${MACHINE}.bin"
> +UBOOT_SPI_IMAGE = "u-boot-${MACHINE}-${PV}-${PR}.img"
> +UBOOT_SPI_SYMLINK = "u-boot-${MACHINE}.img"
> +UBOOT_SPI_GPH_IMAGE = "u-boot-spi-${MACHINE}-${PV}-${PR}.gph"
> +UBOOT_SPI_GPH_SYMLINK = "u-boot-spi-${MACHINE}.gph"
> +
> +do_configure () {
> + oe_runmake ${UBOOT_MACHINE}
> +}
> +
> +do_compile () {
> + unset LDFLAGS
> + unset CFLAGS
> + unset CPPFLAGS
> + oe_runmake ${UBOOT_MAKE_TARGET}
> +}
> +
> +do_install () {
> + install -d ${D}/boot
> + install ${S}/${UBOOT_BINARY} ${D}/boot/${UBOOT_IMAGE}
> + install ${S}/spl/${UBOOT_SPI_SPL_BINARY} ${D}/boot/${UBOOT_SPI_SPL_IMAGE}
> + install ${S}/${UBOOT_SPI_BINARY} ${D}/boot/${UBOOT_SPI_IMAGE}
> + install ${S}/${UBOOT_SPI_GPH_BINARY} ${D}/boot/${UBOOT_SPI_GPH_IMAGE}
> + ln -sf ${UBOOT_IMAGE} ${D}/boot/${UBOOT_BINARY}
> + ln -sf ${UBOOT_SPI_SPL_IMAGE} ${D}/boot/${UBOOT_SPI_SPL_BINARY}
> + ln -sf ${UBOOT_SPI_IMAGE} ${D}/boot/${UBOOT_SPI_BINARY}
> + ln -sf ${UBOOT_SPI_GPH_IMAGE} ${D}/boot/${UBOOT_SPI_GPH_BINARY}
> +}
> +
> +do_deploy () {
> + install -d ${DEPLOY_DIR_IMAGE}
> + install ${S}/${UBOOT_BINARY} ${DEPLOY_DIR_IMAGE}/${UBOOT_IMAGE}
> + install ${S}/spl/${UBOOT_SPI_SPL_BINARY} ${DEPLOY_DIR_IMAGE}/${UBOOT_SPI_SPL_IMAGE}
> + install ${S}/${UBOOT_SPI_BINARY} ${DEPLOY_DIR_IMAGE}/${UBOOT_SPI_IMAGE}
> + install ${S}/${UBOOT_SPI_GPH_BINARY} ${DEPLOY_DIR_IMAGE}/${UBOOT_SPI_GPH_IMAGE}
> +
> + cd ${DEPLOY_DIR_IMAGE}
> + rm -f ${UBOOT_BINARY} ${UBOOT_SYMLINK}
> + ln -sf ${UBOOT_IMAGE} ${UBOOT_SYMLINK}
> + ln -sf ${UBOOT_IMAGE} ${UBOOT_BINARY}
> + rm -f ${UBOOT_SPI_SPL_BINARY} ${UBOOT_SPI_SPL_SYMLINK}
> + ln -sf ${UBOOT_SPI_SPL_IMAGE} ${UBOOT_SPI_SPL_SYMLINK}
> + ln -sf ${UBOOT_SPI_SPL_IMAGE} ${UBOOT_SPI_SPL_BINARY}
> + rm -f ${UBOOT_SPI_BINARY} ${UBOOT_SPI_SYMLINK}
> + ln -sf ${UBOOT_SPI_IMAGE} ${UBOOT_SPI_SYMLINK}
> + ln -sf ${UBOOT_SPI_IMAGE} ${UBOOT_SPI_BINARY}
> + rm -f ${UBOOT_SPI_GPH_BINARY} ${UBOOT_SPI_GPH_SYMLINK}
> + ln -sf ${UBOOT_SPI_GPH_IMAGE} ${UBOOT_SPI_GPH_SYMLINK}
> + ln -sf ${UBOOT_SPI_GPH_IMAGE} ${UBOOT_SPI_GPH_BINARY}
> +}
As we just spoke - let's try to generalize this format and combine it with
other similar requirements, like SPL-UART etc. There was a thread back in
February about this...
--
Denys
next prev parent reply other threads:[~2013-05-07 21:52 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-07 21:24 [RESEND: PATCH 1/3] keystone2: boot-monitor: update to pull code from tip of the master Murali Karicheri
2013-05-07 21:24 ` [RESEND: PATCH 2/3] keystone2: u-boot: update to add gph support Murali Karicheri
2013-05-07 21:52 ` Denys Dmytriyenko [this message]
2013-05-07 22:07 ` Karicheri, Muralidharan
2013-05-07 22:40 ` Denys Dmytriyenko
2013-05-07 22:51 ` Karicheri, Muralidharan
2013-05-07 23:06 ` Denys Dmytriyenko
2013-05-08 14:39 ` Karicheri, Muralidharan
2013-05-08 15:11 ` Tom Rini
2013-05-08 15:32 ` Carlos Hernandez
2013-05-08 15:55 ` Karicheri, Muralidharan
2013-05-08 16:44 ` Tom Rini
2013-05-07 21:24 ` [RESEND: PATCH 3/3] keystone2: linux: add support for building 3.8.4 based Linux kernel Murali Karicheri
2013-05-07 21:59 ` Denys Dmytriyenko
2013-05-07 21:38 ` [RESEND: PATCH 1/3] keystone2: boot-monitor: update to pull code from tip of the master Denys Dmytriyenko
2013-05-08 8:27 ` Maxin B. John
2013-05-08 12:42 ` Dmytriyenko, Denys
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130507215205.GF12982@edge \
--to=denys@ti.com \
--cc=m-karicheri2@ti.com \
--cc=meta-ti@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.