Reported-by: Daniel Thompson <daniel.thompson@...> Tested-by: Nishanth Menon <nm@...> We will need to apply this to master as well - looks like we carried the bug there as well.

We'd want mainline kernel, u-boot, tf-a, optee ..... as many upstream components as possible. is there a way to create a virtual package group that points to all upstream base components? I am looking

Is there any way we can get rid of addresses from recipes?

^^ DDK km build does'nt again change based on board.. so why are we doint this based on board? BVNC does'nt change based on evm - so why are we do it based on board? ^^ Same question here as well.. am

Just curious.. Is the codec binary changing per board? if not, why not just plug it based on SoC?

This adds up numerous fixes for various k3 platforms, adds platform such as AM62x, J721S2. While at it, bump the ti-upstream-tools repo as this sync up gives us: - Switch over to 4k as default, config

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

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.