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

Karicheri, Muralidharan m-karicheri2 at ti.com
Tue May 7 15:07:10 PDT 2013



>> -----Original Message-----
>> From: Dmytriyenko, Denys
>> Sent: Tuesday, May 07, 2013 5:52 PM
>> To: Karicheri, Muralidharan
>> Cc: meta-ti at 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 at 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



More information about the meta-ti mailing list