Stop using un-encrypted git:// protocol to access TI repositories. This is inline with the same arguments as made by github in [1] This patch was generated via the following script: git grep "git://gi

Stop using un-encrypted git:// protocol to access TI repositories. This is inline with the same arguments as made by github in [1] This patch was generated via the following script: git grep "git://gi

Stop using un-encrypted git:// protocol to access TI repositories. This is inline with the same arguments as made by github in [1] This patch was generated via the following script: git grep "git://gi

This is the DM firmware. yes, it is already packaged as of tispl build, so what is missing here?

Due to recent security update[1] in git, a subprocess will be unable to run git rev-parse to fetch revision. So instead, use the SRCPV to parse the short commit ID and set the KERNEL_LOCALVERSION vari

SRCREV works with fixed commits, but when we use AUTOREV for a downstream distro bbappend, we will end up getting a bad local revision. Lets use SRCPV instead, which bitbake already deals with sensibl

That went all haywire... will post a V2.. Sorry for the noise. I also realized i forgot (yet again) to indicate via $subject which branch is the patch for.

SRCREV works with fixed commits, but when we use AUTOREV for a downstream distro bbappend, we will end up getting a bad local revision. Lets use SRCPV instead, which bitbake already deals with sensibl

Due to recent security update[1] in git, a subprocess will be unable to not able to run git rev-parse to fetch revision. So instead, use the SRCPV to parse the short commit ID and set the KERNEL_LOCAL

I see a similar logic in recipes-kernel/linux/setup-defconfig.inc as well. Considering similar problem https://lore.kernel.org/all/20220413155249.3458236-2-raj.khem@... was wondering as to what

Thank you. Reviewed-by: Nishanth Menon <nm@...>

Could we please add a commit message explaining reasoning? This is overall, IMHO a bad idea. sk is ONE of the boards we will support with the same build. See am335x, 437x etc.. if we start spawning of

NAK to the series. a) patches need to be cleaned up - squashed etc. b) lpm-demo binary should probably belong to meta-arago instead of meta-ti. meta-ti should be a bsp layer, not a distro.

NAK -> I know I authored these initial patches during silicon bringup, but please do squash and cleanup the patches prior to posting upstream.

There is also a public-inbox in kernel.org now at https://lore.kernel.org/yocto-meta-ti/ Thanks Denys and yoctoproject team for all the work in making this happen.

Needs a commit message please. See https://lore.kernel.org/all/20211223121650.26868-3-vigneshr@... The intent is to go with ttyS2 using aliases, however, will use main_usart8 (traditionally ttyS10

When we pickedup the update for u-boot to 2021.10, we needed to drop the hack we put in play for k3-image-gen for AM64x. While at it, we also should have bumped our kernel rev from 5.13 to 5.15. Since

From: Ryan Eatmon <reatmon@...> This adds up numerous fixes for various k3 platforms. While at it, bump the ti-upstream-tools repo as this sync up gives us: config: audio_display: Update cdns-mhdp

This reverts commit d5db41417295fe05a293f6d4d77a65ef6563f6ed. We should'nt have to carry patches for u-boot or kernel, since the upstream is now fixed since 5.14 kernel and u-boot 2021.10 tag onwards,

[1] I'd be guessing, but = instead of ?= ^^ weird "can't set" message.. meta-ti does'nt set the password for poky. [1] https://www.yoctoproject.org/docs/2.4/ref-manual/ref-manual.html#var-EXTRA_IMAGE_