[RESEND: PATCH 1/3] keystone2: boot-monitor: update to pull code from tip of the master

[RESEND: PATCH 1/3] keystone2: boot-monitor: update to pull code from tip of the master

[Murali Karicheri]

This patch is needed to switch between release tag (when doing release
build) and tip of the master (when building nightly)

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
---
 recipes-bsp/boot-monitor/boot-monitor_git.bb |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/recipes-bsp/boot-monitor/boot-monitor_git.bb b/recipes-bsp/boot-monitor/boot-monitor_git.bb
index c8a022a..a892720 100644
--- a/recipes-bsp/boot-monitor/boot-monitor_git.bb
+++ b/recipes-bsp/boot-monitor/boot-monitor_git.bb
@@ -11,7 +11,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=25fe219a6febf6e5bb45beda1b2eb315"
 
 COMPATIBLE_MACHINE = "keystone-evm"
 
-SRC_URI = "git://arago-project.org/git/projects/boot-monitor.git;protocol=git;branch=${BRANCH}"
+#SRC_URI = "git://arago-project.org/git/projects/boot-monitor.git;protocol=git;branch=${BRANCH}"
+SRC_URI = "git://gtgit01.gt.design.ti.com/git/projects/boot-monitor.git;protocol=git;branch=${BRANCH}"
 
 PV = "1.0"
 PR = "r1+gitr${SRCPV}"
@@ -20,7 +21,8 @@ BRANCH = "master"
 
 S = "${WORKDIR}/git"
 
-SRCREV = "DEV.MCSDK-03.00.00.07"
+#SRCREV = "DEV.MCSDK-03.00.00.10"
+SRCREV = "${AUTOREV}"
 
 do_compile () {
 	unset LDFLAGS
-- 
1.7.9.5

[RESEND: PATCH 2/3] keystone2: u-boot: update to add gph support

[Murali Karicheri]

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"
 
-COMPATIBLE_MACHINE = "keystone"
+COMPATIBLE_MACHINE = "keystone-evm"
 
-PR = "r2+gitr${SRCPV}"
+PACKAGE_ARCH = "${MACHINE_ARCH}"
 
-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}"
 
 BRANCH = "master"
 
-# DEV.MCSDK-03.00.00.07
-SRCREV = "82f40e857d853165310d0753e79235aefb65d7ba"
+# for nightly switch the two below
+#SRCREV = "DEV.MCSDK-2013-01.10"
+SRCREV = "${AUTOREV}"
+
+EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${TARGET_PREFIX}gcc ${TOOLCHAIN_OPTIONS}"'
+
+S = "${WORKDIR}/git"
 
 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}
+}
-- 
1.7.9.5

Re: [RESEND: PATCH 2/3] keystone2: u-boot: update to add gph support

[Denys Dmytriyenko]

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

Re: [RESEND: PATCH 2/3] keystone2: u-boot: update to add gph support

[Karicheri, Muralidharan]

>> -----Original Message-----
>> From: Dmytriyenko, Denys
>> Sent: Tuesday, May 07, 2013 5:52 PM
>> To: Karicheri, Muralidharan
>> Cc: meta-ti@yoctoproject.org
>> Subject: Re: [meta-ti] [RESEND: PATCH 2/3] keystone2: u-boot: update to add gph
>> support
>> 
>> 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.
>> 

Ok. Will remove after checking

>> 
>> > -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.
>> 

What is the dependency pulled in for keystone? generic tuning for a15 and similar. What defines "keystone" here so that I better understand the big picture?

>> 
>> > -PR = "r2+gitr${SRCPV}"
>> > +PACKAGE_ARCH = "${MACHINE_ARCH}"
>> 
>> Not needed for PACKAGE_ARCH - set in u-boot-ti.inc
>> 

Ok will check.

>> 
>> > -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...

Adding a commit id means every time we push something to master, I need to go and change this. This is not practical. Better point to the tip for getting the latest for nightly. What am I missing?

>> 
>> 
>> > +# 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.
>> 

I don't know. Please give me an example or help me figure this out.

>> 
>> > +EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX}
>> CC="${TARGET_PREFIX}gcc ${TOOLCHAIN_OPTIONS}"'
>> 
>> No need for this line - set in u-boot.inc
>> 
>> 
Ok.

>> > +S = "${WORKDIR}/git"
>> 
>> This one is also already set.
>> 

Ok.

>> 
>> >  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...

This is where I have disagreement. Let us restart the discussion. Who are the stake holders? Discuss it in this thread rather than using an old thread. I have copied here Carlos. I don't have bandwidth to spend too much time on this. Let us discuss it and identify what is required to be done.

Murali
>> 
>> --
>> Denys

Re: [RESEND: PATCH 2/3] keystone2: u-boot: update to add gph support

[Denys Dmytriyenko]

On Tue, May 07, 2013 at 06:07:10PM -0400, Karicheri, Muralidharan wrote:
> >> > -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.
> >> 
> 
> What is the dependency pulled in for keystone? generic tuning for a15 and 
> similar. What defines "keystone" here so that I better understand the big 
> picture?

Here's "keystone" SOC family:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/conf/machine/include/keystone.inc

It is included by the "keystone-evm" machine:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/conf/machine/keystone-evm.conf

The point is to group all machines based on the same SOC and be able to 
address them all with just SOC family name, instead of listing them one by 
one.

For more real life examples see "ti33x" SOC family used by "am335x-evm" and 
"beaglebone" machines. Or "omap3" SOC used by "am37x-evm", "am3517-evm" and 
"beagleboard".


> >> > -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...
> 
> Adding a commit id means every time we push something to master, I need to 
> go and change this. This is not practical. Better point to the tip for 
> getting the latest for nightly. What am I missing?

The problem is that meta-ti is public and constantly used by many people 
outside of TI - every time they parse the recipe, it will hit the server. If 
you point to arago-project.org, it may bring it down, as we have seen before. 
If you point it to your internal git server, that is not accessible from 
outside of TI, it will break parsing for everyone and render meta-ti unusable!

See my next comment for details on how to do it in meta-arago instead.


> >> > +# 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.
> >> 
> 
> I don't know. Please give me an example or help me figure this out.

Use something as simple as below, but for the kernel:
http://arago-project.org/git/?p=meta-arago.git;a=commitdiff;h=32ec5282fd0248581d57ed2a0d66d4c47c275e8c


> >> > +	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...
> 
> This is where I have disagreement. Let us restart the discussion. Who are 
> the stake holders? Discuss it in this thread rather than using an old 
> thread. I have copied here Carlos. I don't have bandwidth to spend too much 
> time on this. Let us discuss it and identify what is required to be done.

Sure, let's discuss. I encourage everyone to participate, especially Carlos 
and Tom.

-- 
Denys

Re: [RESEND: PATCH 2/3] keystone2: u-boot: update to add gph support

[Karicheri, Muralidharan]

>> > >> 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...
>> >
>> > Adding a commit id means every time we push something to master, I
>> > need to go and change this. This is not practical. Better point to the
>> > tip for getting the latest for nightly. What am I missing?
>> 
>> The problem is that meta-ti is public and constantly used by many people outside of TI -
>> every time they parse the recipe, it will hit the server. If you point to arago-project.org, it
>> may bring it down, as we have seen before.
>> If you point it to your internal git server, that is not accessible from outside of TI, it will
>> break parsing for everyone and render meta-ti unusable!
>> 
>> See my next comment for details on how to do it in meta-arago instead.
>> 
>> 
>> > >> > +# 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.
>> > >>
>> >
>> > I don't know. Please give me an example or help me figure this out.
>> 
>> Use something as simple as below, but for the kernel:
>> http://arago-project.org/git/?p=meta-
>> arago.git;a=commitdiff;h=32ec5282fd0248581d57ed2a0d66d4c47c275e8c

Hao,

Can you make an update for this in meta-arago so that our nightly points to tip of the master or whatever branch?

Denys,

So for each of the repos, do we have to use a xxx.bbappend, where xxx is u-boot, boot-monitor and linux-keystone?
So I assume the build still uses the meta-ti version of the recipe, but override the SRCREV with whatever set in xxx.bbappend?

Murali

Re: [RESEND: PATCH 2/3] keystone2: u-boot: update to add gph support

[Denys Dmytriyenko]

On Tue, May 07, 2013 at 06:51:00PM -0400, Karicheri, Muralidharan wrote:
> >> > >> 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...
> >> >
> >> > Adding a commit id means every time we push something to master, I
> >> > need to go and change this. This is not practical. Better point to the
> >> > tip for getting the latest for nightly. What am I missing?
> >> 
> >> The problem is that meta-ti is public and constantly used by many people outside of TI -
> >> every time they parse the recipe, it will hit the server. If you point to arago-project.org, it
> >> may bring it down, as we have seen before.
> >> If you point it to your internal git server, that is not accessible from outside of TI, it will
> >> break parsing for everyone and render meta-ti unusable!
> >> 
> >> See my next comment for details on how to do it in meta-arago instead.
> >> 
> >> 
> >> > >> > +# 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.
> >> > >>
> >> >
> >> > I don't know. Please give me an example or help me figure this out.
> >> 
> >> Use something as simple as below, but for the kernel:
> >> http://arago-project.org/git/?p=meta-
> >> arago.git;a=commitdiff;h=32ec5282fd0248581d57ed2a0d66d4c47c275e8c
> 
> Hao,
> 
> Can you make an update for this in meta-arago so that our nightly points to 
> tip of the master or whatever branch?
> 
> Denys,
> 
> So for each of the repos, do we have to use a xxx.bbappend, where xxx is 
> u-boot, boot-monitor and linux-keystone? So I assume the build still uses 
> the meta-ti version of the recipe, but override the SRCREV with whatever set 
> in xxx.bbappend?

Murali,

Correct, .bbappend is the way to "append" changes to the original recipe w/o 
modifying it.

I don't know what you mean by "each of the repos", but yes, you would need to 
place a .bbappend in meta-arago-distro for every component you develop 
actively and for which you don't want to constantly update the recipe with the 
new SRCREV (or BRANCH or SRC_URI etc.)

By keeping meta-ti pointing to a public git tree with a specific SRCREV 
pointing preferably to a release tag or a stable commit ID you are making sure 
that it works for everybody. It is an official TI BSP and is distribution 
agnostic and should be parseable and buildable by anyone out there. On the 
other hand, meta-arago-distro is our own TI distribution and you have more 
freedom there.

-- 
Denys

Re: [RESEND: PATCH 2/3] keystone2: u-boot: update to add gph support

[Karicheri, Muralidharan]

---Cut-------
>> 
>> Murali,
>> 
>> Correct, .bbappend is the way to "append" changes to the original recipe w/o modifying it.
>> 
>> I don't know what you mean by "each of the repos", but yes, you would need to place a

In this case, u-boot, boot-monitor and linux-keystone git repos. Based on you comment, I am assuming, whatever committed to meta-ti need to point to public repo and for each of this, a .bbappend is to be added to override the SRCREV in meta-arago to pick the nightly version from the tip.

Murali

>> .bbappend in meta-arago-distro for every component you develop actively and for which
>> you don't want to constantly update the recipe with the new SRCREV (or BRANCH or
>> SRC_URI etc.)
>> 
>> By keeping meta-ti pointing to a public git tree with a specific SRCREV pointing preferably
>> to a release tag or a stable commit ID you are making sure that it works for everybody. It
>> is an official TI BSP and is distribution agnostic and should be parseable and buildable by
>> anyone out there. On the other hand, meta-arago-distro is our own TI distribution and you
>> have more freedom there.
>> 
>> --
>> Denys

Re: [RESEND: PATCH 2/3] keystone2: u-boot: update to add gph support

[Tom Rini]

On 05/07/2013 06:40 PM, Denys Dmytriyenko wrote:
> On Tue, May 07, 2013 at 06:07:10PM -0400, Karicheri, Muralidharan wrote:
[snip]
>>>>> +	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...
>>
>> This is where I have disagreement. Let us restart the discussion. Who are 
>> the stake holders? Discuss it in this thread rather than using an old 
>> thread. I have copied here Carlos. I don't have bandwidth to spend too much 
>> time on this. Let us discuss it and identify what is required to be done.
> 
> Sure, let's discuss. I encourage everyone to participate, especially Carlos 
> and Tom.

We should try and get the generic u-boot.inc to allow for a few
different variables to be set by the machine.conf file, and if they are,
copy/symlink them as needed.  I think we should try and fit the SPI
selection into the generic u-boot-with-spl.bin framework that exists in
u-boot today if we can, and then add some logic so that we can package
and symlink that single file instead.

-- 
Tom

Re: [RESEND: PATCH 2/3] keystone2: u-boot: update to add gph support

[Carlos Hernandez]

On 05/08/2013 11:11 AM, Tom Rini wrote:
> On 05/07/2013 06:40 PM, Denys Dmytriyenko wrote:
>> On Tue, May 07, 2013 at 06:07:10PM -0400, Karicheri, Muralidharan wrote:
> [snip]
>>>>>> +	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...
>>> This is where I have disagreement. Let us restart the discussion. Who are
>>> the stake holders? Discuss it in this thread rather than using an old
>>> thread. I have copied here Carlos. I don't have bandwidth to spend too much
>>> time on this. Let us discuss it and identify what is required to be done.
>> Sure, let's discuss. I encourage everyone to participate, especially Carlos
>> and Tom.
> We should try and get the generic u-boot.inc to allow for a few
> different variables to be set by the machine.conf file, and if they are,
> copy/symlink them as needed.  I think we should try and fit the SPI
> selection into the generic u-boot-with-spl.bin framework that exists in
> u-boot today if we can, and then add some logic so that we can package
> and symlink that single file instead.
>
+1

Re: [RESEND: PATCH 2/3] keystone2: u-boot: update to add gph support

[Karicheri, Muralidharan]

>> -----Original Message-----
>> From: Rini, Tom
>> Sent: Wednesday, May 08, 2013 11:11 AM
>> To: Dmytriyenko, Denys
>> Cc: Karicheri, Muralidharan; Hernandez, Carlos; meta-ti@yoctoproject.org
>> Subject: Re: [meta-ti] [RESEND: PATCH 2/3] keystone2: u-boot: update to add gph
>> support
>> 
>> On 05/07/2013 06:40 PM, Denys Dmytriyenko wrote:
>> > On Tue, May 07, 2013 at 06:07:10PM -0400, Karicheri, Muralidharan wrote:
>> [snip]
>> >>>>> +	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...
>> >>
>> >> This is where I have disagreement. Let us restart the discussion. Who
>> >> are the stake holders? Discuss it in this thread rather than using an
>> >> old thread. I have copied here Carlos. I don't have bandwidth to
>> >> spend too much time on this. Let us discuss it and identify what is required to be done.
>> >
>> > Sure, let's discuss. I encourage everyone to participate, especially
>> > Carlos and Tom.
>> 
>> We should try and get the generic u-boot.inc to allow for a few different variables to be
>> set by the machine.conf file, and if they are, copy/symlink them as needed.  I think we
>> should try and fit the SPI selection into the generic u-boot-with-spl.bin framework that
>> exists in u-boot today if we can, and then add some logic so that we can package and
>> symlink that single file instead.

I think we are unable to use the generic due to the specific header format requirement from RBL (Rom
Boot loader). So we need to live with the format. How do we handle this with the existing u-boot-spl.gph
formatting that we use?

>> 
>> --
>> Tom

Re: [RESEND: PATCH 2/3] keystone2: u-boot: update to add gph support

[Tom Rini]

On 05/08/2013 11:55 AM, Karicheri, Muralidharan wrote:
>>> -----Original Message-----
>>> From: Rini, Tom
>>> Sent: Wednesday, May 08, 2013 11:11 AM
>>> To: Dmytriyenko, Denys
>>> Cc: Karicheri, Muralidharan; Hernandez, Carlos; meta-ti@yoctoproject.org
>>> Subject: Re: [meta-ti] [RESEND: PATCH 2/3] keystone2: u-boot: update to add gph
>>> support
>>>
>>> On 05/07/2013 06:40 PM, Denys Dmytriyenko wrote:
>>>> On Tue, May 07, 2013 at 06:07:10PM -0400, Karicheri, Muralidharan wrote:
>>> [snip]
>>>>>>>> +	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...
>>>>>
>>>>> This is where I have disagreement. Let us restart the discussion. Who
>>>>> are the stake holders? Discuss it in this thread rather than using an
>>>>> old thread. I have copied here Carlos. I don't have bandwidth to
>>>>> spend too much time on this. Let us discuss it and identify what is required to be done.
>>>>
>>>> Sure, let's discuss. I encourage everyone to participate, especially
>>>> Carlos and Tom.
>>>
>>> We should try and get the generic u-boot.inc to allow for a few different variables to be
>>> set by the machine.conf file, and if they are, copy/symlink them as needed.  I think we
>>> should try and fit the SPI selection into the generic u-boot-with-spl.bin framework that
>>> exists in u-boot today if we can, and then add some logic so that we can package and
>>> symlink that single file instead.
> 
> I think we are unable to use the generic due to the specific header format requirement from RBL (Rom
> Boot loader). So we need to live with the format. How do we handle this with the existing u-boot-spl.gph
> formatting that we use?

I was off slightly it seems, we don't have everyone on
u-boot-with-spl.bin, but it's u-boot-with-spl.something (bin, imx).  So
in this case, make up the rules for a u-boot-with-spl.gph that does what
keystone needs, and we can finish up the rest of the logic around that
to pick up u-boot-with-spl.* and copy/link.

-- 
Tom

[RESEND: PATCH 3/3] keystone2: linux: add support for building 3.8.4 based Linux kernel

[Murali Karicheri]

This also allow support for switching between release tag and tip of the
master/master for nightly builds.

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
---
 .../linux/linux-keystone-3.8.4/defconfig           |    1 +
 recipes-kernel/linux/linux-keystone_3.8.4.bb       |   41 ++++++++++++++++++++
 2 files changed, 42 insertions(+)
 create mode 100644 recipes-kernel/linux/linux-keystone-3.8.4/defconfig
 create mode 100644 recipes-kernel/linux/linux-keystone_3.8.4.bb

diff --git a/recipes-kernel/linux/linux-keystone-3.8.4/defconfig b/recipes-kernel/linux/linux-keystone-3.8.4/defconfig
new file mode 100644
index 0000000..04e6b17
--- /dev/null
+++ b/recipes-kernel/linux/linux-keystone-3.8.4/defconfig
@@ -0,0 +1 @@
+use-kernel-config=keystone2_defconfig
diff --git a/recipes-kernel/linux/linux-keystone_3.8.4.bb b/recipes-kernel/linux/linux-keystone_3.8.4.bb
new file mode 100644
index 0000000..0237e66
--- /dev/null
+++ b/recipes-kernel/linux/linux-keystone_3.8.4.bb
@@ -0,0 +1,41 @@
+LICENSE = "GPLv2"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
+
+COMPATIBLE_MACHINE = "keystone-evm"
+
+inherit kernel
+
+do_deploy_append() {
+    cd ${S}
+}
+
+require recipes-kernel/linux/linux-dtb.inc
+require recipes-kernel/linux/setup-defconfig.inc
+
+MACHINE_KERNEL_PR_append = "a"
+
+CORTEXA8FIXUP = "no"
+
+KERNEL_DEVICETREE_keystone-evm = "arch/${ARCH}/boot/dts/k2hk-evm.dts"
+
+# The tree tends to rebase, use literal stable tags
+# for nightly switch the two lines below
+#SRCREV = "DEV.MCSDK-03.08.04.10"
+SRCREV = "${AUTOREV}"
+
+BRANCH = "master/master"
+#BRANCH = "releases/03.00.00.10"
+
+# for nightly switch the three lines below
+#SRC_URI = "git://arago-project.org/git/projects/linux-keystone.git;protocol=git;branch=${BRANCH} \
+#           file://defconfig \
+#           "
+SRC_URI = "git://gtgit01.gt.design.ti.com/git/projects/linux-keystone.git;protocol=git;branch=${BRANCH} \
+           file://defconfig \
+           "
+
+S = "${WORKDIR}/git"
+
+RDEPENDS_kernel-base = ""
+
-- 
1.7.9.5

Re: [RESEND: PATCH 3/3] keystone2: linux: add support for building 3.8.4 based Linux kernel

[Denys Dmytriyenko]

On Tue, May 07, 2013 at 05:24:19PM -0400, Murali Karicheri wrote:
> This also allow support for switching between release tag and tip of the
> master/master for nightly builds.
> 
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> ---
>  .../linux/linux-keystone-3.8.4/defconfig           |    1 +
>  recipes-kernel/linux/linux-keystone_3.8.4.bb       |   41 ++++++++++++++++++++
>  2 files changed, 42 insertions(+)
>  create mode 100644 recipes-kernel/linux/linux-keystone-3.8.4/defconfig
>  create mode 100644 recipes-kernel/linux/linux-keystone_3.8.4.bb
> 
> diff --git a/recipes-kernel/linux/linux-keystone-3.8.4/defconfig b/recipes-kernel/linux/linux-keystone-3.8.4/defconfig
> new file mode 100644
> index 0000000..04e6b17
> --- /dev/null
> +++ b/recipes-kernel/linux/linux-keystone-3.8.4/defconfig
> @@ -0,0 +1 @@
> +use-kernel-config=keystone2_defconfig
> diff --git a/recipes-kernel/linux/linux-keystone_3.8.4.bb b/recipes-kernel/linux/linux-keystone_3.8.4.bb
> new file mode 100644
> index 0000000..0237e66
> --- /dev/null
> +++ b/recipes-kernel/linux/linux-keystone_3.8.4.bb
> @@ -0,0 +1,41 @@
> +LICENSE = "GPLv2"
> +
> +LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
> +
> +COMPATIBLE_MACHINE = "keystone-evm"

Same as with u-boot, you should probably use "keystone" SOC family here.


> +inherit kernel
> +
> +do_deploy_append() {
> +    cd ${S}
> +}

This do_deploy_append() fix is no longer required.


> +require recipes-kernel/linux/linux-dtb.inc
> +require recipes-kernel/linux/setup-defconfig.inc
> +
> +MACHINE_KERNEL_PR_append = "a"
> +
> +CORTEXA8FIXUP = "no"
> +
> +KERNEL_DEVICETREE_keystone-evm = "arch/${ARCH}/boot/dts/k2hk-evm.dts"
> +
> +# The tree tends to rebase, use literal stable tags
> +# for nightly switch the two lines below
> +#SRCREV = "DEV.MCSDK-03.08.04.10"
> +SRCREV = "${AUTOREV}"
> +
> +BRANCH = "master/master"
> +#BRANCH = "releases/03.00.00.10"
> +
> +# for nightly switch the three lines below
> +#SRC_URI = "git://arago-project.org/git/projects/linux-keystone.git;protocol=git;branch=${BRANCH} \
> +#           file://defconfig \
> +#           "
> +SRC_URI = "git://gtgit01.gt.design.ti.com/git/projects/linux-keystone.git;protocol=git;branch=${BRANCH} \
> +           file://defconfig \
> +           "

Same comments for SRCREV and SRC_URI as with u-boot.


> +S = "${WORKDIR}/git"
> +
> +RDEPENDS_kernel-base = ""

You should probably move this line to an image recipe of distro/SDK config. 
There might be people wanting to build Kkeystone kernel and get the default 
/boot image installed. So, either put this in tisdk-server-rootfs-image 
(would be rootfs-specific) or better yet in conf/distro/include/branding-mcsdk.inc 
to be MCSDK-specific.

-- 
Denys

Re: [RESEND: PATCH 1/3] keystone2: boot-monitor: update to pull code from tip of the master

[Denys Dmytriyenko]

On Tue, May 07, 2013 at 05:24:17PM -0400, Murali Karicheri wrote:
> This patch is needed to switch between release tag (when doing release
> build) and tip of the master (when building nightly)
> 
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> ---
>  recipes-bsp/boot-monitor/boot-monitor_git.bb |    6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/recipes-bsp/boot-monitor/boot-monitor_git.bb b/recipes-bsp/boot-monitor/boot-monitor_git.bb
> index c8a022a..a892720 100644
> --- a/recipes-bsp/boot-monitor/boot-monitor_git.bb
> +++ b/recipes-bsp/boot-monitor/boot-monitor_git.bb
> @@ -11,7 +11,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=25fe219a6febf6e5bb45beda1b2eb315"
>  
>  COMPATIBLE_MACHINE = "keystone-evm"
>  
> -SRC_URI = "git://arago-project.org/git/projects/boot-monitor.git;protocol=git;branch=${BRANCH}"
> +#SRC_URI = "git://arago-project.org/git/projects/boot-monitor.git;protocol=git;branch=${BRANCH}"
> +SRC_URI = "git://gtgit01.gt.design.ti.com/git/projects/boot-monitor.git;protocol=git;branch=${BRANCH}"
>  
>  PV = "1.0"
>  PR = "r1+gitr${SRCPV}"
> @@ -20,7 +21,8 @@ BRANCH = "master"
>  
>  S = "${WORKDIR}/git"
>  
> -SRCREV = "DEV.MCSDK-03.00.00.07"
> +#SRCREV = "DEV.MCSDK-03.00.00.10"
> +SRCREV = "${AUTOREV}"

Please, no AUTOREV in meta-ti, only pinned versions. Also, it is better to use 
commit ID hash for SRCREV and specify what tag it corresponds to in a comment 
next to it. There are too many issues with AUTOREV and needing to resolve tags 
to commit IDs during parsing in current version of Bitbake...

-- 
Denys

Re: [RESEND: PATCH 1/3] keystone2: boot-monitor: update to pull code from tip of the master

[Maxin B. John]

Hi,

On Tue, May 07, 2013 at 05:24:17PM -0400, Murali Karicheri wrote:
 > This patch is needed to switch between release tag (when doing release
 > build) and tip of the master (when building nightly)
 >·
 > Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
 > ---
 >  recipes-bsp/boot-monitor/boot-monitor_git.bb |    6 ++++--
 >  1 file changed, 4 insertions(+), 2 deletions(-)
 >·
 > diff --git a/recipes-bsp/boot-monitor/boot-monitor_git.bb b/recipes-bsp/boot-monitor/boot-monitor_git.bb
 > index c8a022a..a892720 100644
 > --- a/recipes-bsp/boot-monitor/boot-monitor_git.bb
 > +++ b/recipes-bsp/boot-monitor/boot-monitor_git.bb
 > @@ -11,7 +11,8 @@ LIC_FILES_CHKSUM ="file://COPYING;md5=25fe219a6febf6e5bb45beda1b2eb315"
 >··
 >  COMPATIBLE_MACHINE = "keystone-evm"
 >··
 > -SRC_URI = "git://arago-project.org/git/projects/boot-monitor.git;protocol=git;branch=${BRANCH}"
 > +#SRC_URI ="git://arago-project.org/git/projects/boot-monitor.git;protocol=git;branch=${BRANCH}"
 > +SRC_URI ="git://gtgit01.gt.design.ti.com/git/projects/boot-monitor.git;protocol=git;branch=${BRANCH}"

While attempting to clone this repo,  "git clone git://gtgit01.gt.design.ti.com/git/projects/boot-monitor.git",
I get the following error message: 

cloning into 'boot-monitor'...
fatal: unable to connect to gtgit01.gt.design.ti.com:
gtgit01.gt.design.ti.com: Name or service not known

Do this access problem has something to do with my local firewall
settings or somebody else also face the same problem ? 

Best Regards,
Maxin

Re: [RESEND: PATCH 1/3] keystone2: boot-monitor: update to pull code from tip of the master

[Dmytriyenko, Denys]

[-- Attachment #1: Type: text/plain, Size: 2048 bytes --]

No


Denys


-----Original Message-----
From: Maxin B. John [maxin.john@enea.com]
Received: Wednesday, 08 May 2013, 4:28
To: Karicheri, Muralidharan [m-karicheri2@ti.com]
CC: meta-ti@yoctoproject.org [meta-ti@yoctoproject.org]
Subject: Re: [meta-ti] [RESEND: PATCH 1/3] keystone2: boot-monitor: update to pull code from tip of the master

Hi,

On Tue, May 07, 2013 at 05:24:17PM -0400, Murali Karicheri wrote:
 > This patch is needed to switch between release tag (when doing release
 > build) and tip of the master (when building nightly)
 >·
 > Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
 > ---
 >  recipes-bsp/boot-monitor/boot-monitor_git.bb |    6 ++++--
 >  1 file changed, 4 insertions(+), 2 deletions(-)
 >·
 > diff --git a/recipes-bsp/boot-monitor/boot-monitor_git.bb b/recipes-bsp/boot-monitor/boot-monitor_git.bb
 > index c8a022a..a892720 100644
 > --- a/recipes-bsp/boot-monitor/boot-monitor_git.bb
 > +++ b/recipes-bsp/boot-monitor/boot-monitor_git.bb
 > @@ -11,7 +11,8 @@ LIC_FILES_CHKSUM ="file://COPYING;md5=25fe219a6febf6e5bb45beda1b2eb315"
 >··
 >  COMPATIBLE_MACHINE = "keystone-evm"
 >··
 > -SRC_URI = "git://arago-project.org/git/projects/boot-monitor.git;protocol=git;branch=${BRANCH}"
 > +#SRC_URI ="git://arago-project.org/git/projects/boot-monitor.git;protocol=git;branch=${BRANCH}"
 > +SRC_URI ="git://gtgit01.gt.design.ti.com/git/projects/boot-monitor.git;protocol=git;branch=${BRANCH}"

While attempting to clone this repo,  "git clone git://gtgit01.gt.design.ti.com/git/projects/boot-monitor.git",
I get the following error message:

cloning into 'boot-monitor'...
fatal: unable to connect to gtgit01.gt.design.ti.com:
gtgit01.gt.design.ti.com: Name or service not known

Do this access problem has something to do with my local firewall
settings or somebody else also face the same problem ?

Best Regards,
Maxin
_______________________________________________
meta-ti mailing list
meta-ti@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-ti

[-- Attachment #2: Type: text/html, Size: 3366 bytes --]