[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