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 _______________________________________________ meta-ti mailing list meta-ti@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-ti
