Date   

Re: [dunfell/master PATCH] Revert "u-boot-ti-staging_2020.01: Fix build on hosts with gcc10 on them"

Suman Anna
 

On 12/4/20 2:28 PM, praneeth@... wrote:
From: Praneeth Bajjuri <praneeth@...>

This reverts commit 83f29e8b99144b69ed51ff69f41ab5a50f00fc5f.

The mentioned fix is now pulled to ti-u-boot.git in
ti-u-boot-2020.01 branch
commit a6904f563f ("Remove redundant YYLOC global declaration")

Signed-off-by: Praneeth Bajjuri <praneeth@...>
---
...e-redundant-YYLOC-global-declaration.patch | 28 -------------------
.../u-boot/u-boot-ti-staging_2020.01.bb | 4 +--
2 files changed, 1 insertion(+), 31 deletions(-)
delete mode 100644 recipes-bsp/u-boot/files/0001-Remove-redundant-YYLOC-global-declaration.patch

diff --git a/recipes-bsp/u-boot/files/0001-Remove-redundant-YYLOC-global-declaration.patch b/recipes-bsp/u-boot/files/0001-Remove-redundant-YYLOC-global-declaration.patch
deleted file mode 100644
index 4973ea9d..00000000
--- a/recipes-bsp/u-boot/files/0001-Remove-redundant-YYLOC-global-declaration.patch
+++ /dev/null
@@ -1,28 +0,0 @@
-From b436a29de12d3f1da579edf3e3d4d42a60b9e58a Mon Sep 17 00:00:00 2001
-From: Peter Robinson <pbrobinson@...>
-Date: Thu, 30 Jan 2020 09:37:15 +0000
-Subject: [PATCH] Remove redundant YYLOC global declaration
-
-Same as the upstream fix for building dtc with gcc 10.
-
-Upstream-Status: Backport [https://github.com/u-boot/u-boot/commit/018921ee79d3f30893614b3b2b63b588d8544f73]
-Signed-off-by: Peter Robinson <pbrobinson@...>
----
- scripts/dtc/dtc-lexer.l | 1 -
- 1 file changed, 1 deletion(-)
-
-diff --git a/scripts/dtc/dtc-lexer.l b/scripts/dtc/dtc-lexer.l
-index fd825ebba6..24af549977 100644
---- a/scripts/dtc/dtc-lexer.l
-+++ b/scripts/dtc/dtc-lexer.l
-@@ -38,7 +38,6 @@ LINECOMMENT "//".*\n
- #include "srcpos.h"
- #include "dtc-parser.tab.h"
-
--YYLTYPE yylloc;
- extern bool treesource_error;
-
- /* CAUTION: this will stop working if we ever use yyless() or yyunput() */
---
-2.29.2
-
diff --git a/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb b/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb
index 29fa6ee6..991ba0ca 100644
--- a/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb
+++ b/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb
@@ -1,9 +1,7 @@
require u-boot-ti.inc

-PR = "r23"
+PR = "r22"

BRANCH = "ti-u-boot-2020.01"

SRCREV = "3c9ebdb87d65aacc4ec302be8bef3df15364bacd"
Please resubmit after updating the SRCREV that includes the picked up patch
along with the rest of the changes..

regards
Suman

-
-SRC_URI += "file://0001-Remove-redundant-YYLOC-global-declaration.patch"


[dunfell/master PATCH] Revert "u-boot-ti-staging_2020.01: Fix build on hosts with gcc10 on them"

praneeth
 

From: Praneeth Bajjuri <praneeth@...>

This reverts commit 83f29e8b99144b69ed51ff69f41ab5a50f00fc5f.

The mentioned fix is now pulled to ti-u-boot.git in
ti-u-boot-2020.01 branch
commit a6904f563f ("Remove redundant YYLOC global declaration")

Signed-off-by: Praneeth Bajjuri <praneeth@...>
---
...e-redundant-YYLOC-global-declaration.patch | 28 -------------------
.../u-boot/u-boot-ti-staging_2020.01.bb | 4 +--
2 files changed, 1 insertion(+), 31 deletions(-)
delete mode 100644 recipes-bsp/u-boot/files/0001-Remove-redundant-YYLOC-global-declaration.patch

diff --git a/recipes-bsp/u-boot/files/0001-Remove-redundant-YYLOC-global-declaration.patch b/recipes-bsp/u-boot/files/0001-Remove-redundant-YYLOC-global-declaration.patch
deleted file mode 100644
index 4973ea9d..00000000
--- a/recipes-bsp/u-boot/files/0001-Remove-redundant-YYLOC-global-declaration.patch
+++ /dev/null
@@ -1,28 +0,0 @@
-From b436a29de12d3f1da579edf3e3d4d42a60b9e58a Mon Sep 17 00:00:00 2001
-From: Peter Robinson <pbrobinson@...>
-Date: Thu, 30 Jan 2020 09:37:15 +0000
-Subject: [PATCH] Remove redundant YYLOC global declaration
-
-Same as the upstream fix for building dtc with gcc 10.
-
-Upstream-Status: Backport [https://github.com/u-boot/u-boot/commit/018921ee79d3f30893614b3b2b63b588d8544f73]
-Signed-off-by: Peter Robinson <pbrobinson@...>
----
- scripts/dtc/dtc-lexer.l | 1 -
- 1 file changed, 1 deletion(-)
-
-diff --git a/scripts/dtc/dtc-lexer.l b/scripts/dtc/dtc-lexer.l
-index fd825ebba6..24af549977 100644
---- a/scripts/dtc/dtc-lexer.l
-+++ b/scripts/dtc/dtc-lexer.l
-@@ -38,7 +38,6 @@ LINECOMMENT "//".*\n
- #include "srcpos.h"
- #include "dtc-parser.tab.h"
-
--YYLTYPE yylloc;
- extern bool treesource_error;
-
- /* CAUTION: this will stop working if we ever use yyless() or yyunput() */
---
-2.29.2
-
diff --git a/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb b/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb
index 29fa6ee6..991ba0ca 100644
--- a/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb
+++ b/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb
@@ -1,9 +1,7 @@
require u-boot-ti.inc

-PR = "r23"
+PR = "r22"

BRANCH = "ti-u-boot-2020.01"

SRCREV = "3c9ebdb87d65aacc4ec302be8bef3df15364bacd"
-
-SRC_URI += "file://0001-Remove-redundant-YYLOC-global-declaration.patch"
--
2.17.1


[PATCH] [meta-ti][dunfell/master][PATCH] setup-scripts - removing confusion for users when script succeeds

Caleb Robey <c-robey@...>
 

From: a0232989 <a0232989@...>

Script does not include all correct versions in success message

Signed-off-by: Caleb Robey <c-robey@...>
---
setup-host-check.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/setup-host-check.sh b/setup-host-check.sh
index 45b4c71..a9db056 100644
--- a/setup-host-check.sh
+++ b/setup-host-check.sh
@@ -43,6 +43,6 @@ if [ "$host" != "precise" -a "$host" != "trusty" -a "$host" != "xenial" -a "$ho
echo "Unsupported host machine, only Ubuntu 12.04 LTS, Ubuntu 14.04 LTS, Ubuntu 16.04 LTS, and Ubuntu 18.04 LTS are supported"
exit 1
fi
-echo "Ubuntu 12.04 LTS, Ubuntu 14.04, or Ubuntu 14.04 LTS is being used, continuing.."
+echo "Ubuntu 12.04 LTS, Ubuntu 14.04, LTS Ubuntu 16.04 LTS, or Ubuntu 18.04 LTS is being used, continuing.."
echo "--------------------------------------------------------------------------------"
echo
--
2.17.1


[PATCH] [meta-ti][dunfell/master][PATCH] set serverip after dhcp

Caleb Robey <c-robey@...>
 

From: a0232989 <a0232989@...>

There is a documented issue where the u-boot dhcp command,
when autoboot is set to "no", will reset serverip to the
gateway ip address. This is a workaround that should not
have any negative affect on these scripts and will prevent
this issue for occuring.

Issue:
https://stackoverflow.com/questions/13975468/in-u-boot-can-the-dhcp-command-automatically-set-the-serverip-environment-varia

Note: we display this behavior in older scripts, but dropped
the nomenclature lately and default NFS setups do not work
out of the box as a result.

Signed-off-by: Caleb Robey <c-robey@...>
---
setup-uboot-env-am335x.sh | 4 ++--
setup-uboot-env-am43x.sh | 2 +-
setup-uboot-env-am57xx-evm.sh | 2 +-
setup-uboot-env-am65x.sh | 5 ++---
4 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/setup-uboot-env-am335x.sh b/setup-uboot-env-am335x.sh
index f129875..687461b 100644
--- a/setup-uboot-env-am335x.sh
+++ b/setup-uboot-env-am335x.sh
@@ -189,7 +189,7 @@ if [ "$kernel" -eq "1" ]; then
do_expect "\"$prompt\"" "send \"setenv ip_method dhcp\"" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"setenv nfsopts 'nolock,v3,tcp,rsize=4096,wsize=4096'\"" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"setenv getuenv 'if mmc rescan; then if run loadbootenv; then run importbootenv; fi; fi;'\"" $cwd/setupBoard.minicom
- do_expect "\"$prompt\"" "send setenv bootcmd 'run findfdt; run init_console; run getuenv; setenv autoload no;dhcp ;tftp \${loadaddr} $kernelimage; tftp \${fdtaddr} \${fdtfile}; run netargs; bootz \${loadaddr} - \${fdtaddr}'" $cwd/setupBoard.minicom
+ do_expect "\"$prompt\"" "send setenv bootcmd 'run findfdt; run init_console; run getuenv; setenv autoload no;dhcp ;setenv serverip $ip;tftp \${loadaddr} $kernelimage; tftp \${fdtaddr} \${fdtfile}; run netargs; bootz \${loadaddr} - \${fdtaddr}'" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"saveenv\"" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"boot\"" $cwd/setupBoard.minicom
else
@@ -198,7 +198,7 @@ if [ "$kernel" -eq "1" ]; then
do_expect "\"$prompt\"" "send \"setenv bootfile $kernelimage\"" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"setenv ip_method none\"" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"setenv getuenv 'if mmc rescan; then if run loadbootenv; then run importbootenv; fi; fi;'\"" $cwd/setupBoard.minicom
- do_expect "\"$prompt\"" "send setenv bootcmd 'run findfdt; run init_console; run getuenv; setenv autoload no; dhcp ; tftp \${loadaddr} $kernelimage; tftp \${fdtaddr} \${fdtfile}; run args_mmc; bootz \${loadaddr} - \${fdtaddr}'" $cwd/setupBoard.minicom
+ do_expect "\"$prompt\"" "send setenv bootcmd 'run findfdt; run init_console; run getuenv; setenv autoload no; dhcp ;setenv serverip $ip; tftp \${loadaddr} $kernelimage; tftp \${fdtaddr} \${fdtfile}; run args_mmc; bootz \${loadaddr} - \${fdtaddr}'" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"saveenv\"" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"boot\"" $cwd/setupBoard.minicom
fi
diff --git a/setup-uboot-env-am43x.sh b/setup-uboot-env-am43x.sh
index 24bc58a..8b8254b 100644
--- a/setup-uboot-env-am43x.sh
+++ b/setup-uboot-env-am43x.sh
@@ -144,7 +144,7 @@ if [ "$kernel" -eq "1" ]; then
do_expect "\"$prompt\"" "send \"setenv nfsopts 'nolock,v3,tcp,rsize=4096,wsize=4096'\"" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"setenv devtype mmc\"" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"setenv getuenv 'setenv devnum \${mmcdev}; if mmc rescan; then if run loadbootenv; then run importbootenv; fi; fi;'\"" $cwd/setupBoard.minicom
- do_expect "\"$prompt\"" "send setenv bootcmd 'run findfdt; run getuenv; setenv autoload no;dhcp ;tftp \${loadaddr} $kernelimage; tftp \${fdtaddr} \${fdtfile}; run netargs; bootz \${loadaddr} - \${fdtaddr}'" $cwd/setupBoard.minicom
+ do_expect "\"$prompt\"" "send setenv bootcmd 'run findfdt; run getuenv; setenv autoload no;dhcp ;setenv serverip $ip; tftp \${loadaddr} $kernelimage; tftp \${fdtaddr} \${fdtfile}; run netargs; bootz \${loadaddr} - \${fdtaddr}'" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"saveenv\"" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"boot\"" $cwd/setupBoard.minicom
else
diff --git a/setup-uboot-env-am57xx-evm.sh b/setup-uboot-env-am57xx-evm.sh
index 323c134..dfd9486 100644
--- a/setup-uboot-env-am57xx-evm.sh
+++ b/setup-uboot-env-am57xx-evm.sh
@@ -156,7 +156,7 @@ if [ "$kernel" -eq "1" ]; then
do_expect "\"$prompt\"" "send \"setenv ip_method dhcp\"" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"setenv nfsopts 'nolock,v3,tcp,rsize=4096,wsize=4096'\"" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"setenv getuenv 'mmc dev \${mmcdev}; if mmc rescan; then if run loadbootenv; then run importbootenv; fi; fi;'\"" $cwd/setupBoard.minicom
- do_expect "\"$prompt\"" "send setenv bootcmd 'run findfdt; run getuenv; setenv autoload no;dhcp ;tftp \${loadaddr} $kernelimage; tftp \${fdtaddr} \${fdtfile}; run netargs; bootz \${loadaddr} - \${fdtaddr}'" $cwd/setupBoard.minicom
+ do_expect "\"$prompt\"" "send setenv bootcmd 'run findfdt; run getuenv; setenv autoload no;dhcp ;setenv serverip $ip;tftp \${loadaddr} $kernelimage; tftp \${fdtaddr} \${fdtfile}; run netargs; bootz \${loadaddr} - \${fdtaddr}'" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"saveenv\"" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"boot\"" $cwd/setupBoard.minicom
else
diff --git a/setup-uboot-env-am65x.sh b/setup-uboot-env-am65x.sh
index b6e043b..60045ae 100644
--- a/setup-uboot-env-am65x.sh
+++ b/setup-uboot-env-am65x.sh
@@ -144,14 +144,13 @@ do_expect "\"$prompt\"" "send \"reset\"" $cwd/setupBoard.minicom
do_expect "\"stop autoboot:\"" "send \" \"" $cwd/setupBoard.minicom

# Configurable settings
-do_expect "\"$prompt\"" "send \"setenv serverip $ip\"" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"setenv nfs_root $rootpath\"" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"setenv name_kern $kernelimage\"" $cwd/setupBoard.minicom

# General macros
do_expect "\"$prompt\"" "send \"setenv bootcmd 'run findfdt; run envboot; run setup_\${kern_boot}; run init_\${rootfs_boot}; run get_kern_\${kern_boot}; run get_fdt_\${kern_boot}; run get_overlay_\${kern_boot}; run run_kern'\"" $cwd/setupBoard.minicom

-do_expect "\"$prompt\"" "send \"setenv init_net 'run args_all args_net; setenv autoload no; dhcp'\"" $cwd/setupBoard.minicom
+do_expect "\"$prompt\"" "send \"setenv init_net 'run args_all args_net; setenv autoload no; dhcp; setenv serverip $ip'\"" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"setenv args_net 'setenv bootargs console=\${console} \${optargs} rootfstype=nfs root=/dev/nfs rw nfsroot=\${serverip}:\${nfs_root},\${nfs_options} ip=dhcp'\"" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"setenv get_kern_net 'tftp \${loadaddr} \${name_kern}'\"" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"setenv get_fdt_net 'tftp \${fdtaddr} \${name_fdt}'\"" $cwd/setupBoard.minicom
@@ -159,7 +158,7 @@ do_expect "\"$prompt\"" "send \"setenv get_overlay_net 'fdt address \${fdtaddr};

do_expect "\"$prompt\"" "send \"setenv nfs_options 'nolock,v3,tcp,rsize=4096,wsize=4096'\"" $cwd/setupBoard.minicom
do_expect "\"$prompt\"" "send \"setenv setup_mmc ''\"" $cwd/setupBoard.minicom
-do_expect "\"$prompt\"" "send \"setenv setup_net 'setenv autoload no; dhcp'\"" $cwd/setupBoard.minicom
+do_expect "\"$prompt\"" "send \"setenv setup_net 'setenv autoload no; dhcp; setenv serverip $ip'\"" $cwd/setupBoard.minicom



--
2.17.1


Re: How to tell when meta-ti/meta-arago or TI CoreSDK is released

 

On Tue, 17 Nov 2020 at 19:42, Dan Murphy <dmurphy@...> wrote:

Paul

On 11/17/20 1:17 PM, Paul Barker wrote:

Hey folks, apologies if this isn't the right place to ask but I can't
see where else I should be asking this question.

The Sancloud BSP layer (meta-sancloud) depends on both meta-arago and
meta-ti. For our Arago builds I typically pin release versions of
these dependency layers, especially for meta-arago and meta-ti I want
to ensure that we're using known good versions. The tag we're
currently pinned to is 07.00.00.005 which I believe corresponds to a
TI CoreSDK release. I see there are some new tags in these layers and
in the ti-linux-kernel repository

I also see that configs have been added to the oe-layersetup
repository which is usually my flag that something has been released.
However, in oe-layersetup both 07.01.00.004 and 07.01.00.005 have been
given config files while the meta-arago layer, meta-ti layer and
ti-linux-kernel recipes are up to 07.01.00.006. So my usual heuristics
are a bit confused.

I've tried searching for "ti coresdk" in google but I can't find any
documentation for this. I've also tried looking at the Arago wiki but
this does not look to have been updated recently. The only list of
branches I can find is
http://arago-project.org/wiki/index.php/Setting_Up_Build_Environment
which is definitely obsolete.

So all I can do is ask the question then - how do I find out when a
release of Arago (or TI CoreSDK) is ready to pick up and use?

This is on my to do for next year to try to document expected release dates.

To pre-empt the obvious question - we do test with the HEAD of the
dunfell branch of layers regularly but we're not happy to issue a
release of our own BSP without ensuring we're aligned on released
versions of the underlying layers where possible. We need to track the
releases in the ti-linux-kernel layer as we've seen in the past that
our kernel needs to match with the expectations of the meta-ti layer
if we want the PowerVR drivers to work.

Sorry for all the confusion. I created those additional configs for our internal SDK consumers.

The official release will be 07.01.00.006 and I will be pushing that config shortly.
Hi Dan,

I see that there is now a config file in the oe-layersetup repository
for v07.01.00.006.

Is there any way I can tell if there will be a further pre-release
here (e.g. 07.01.00.007) or if this is the "final" 07.01.00 release
and ready for downstream users to pick up?

Some reference for how CoreSDK is released would be really helpful but
I can't find any such info online - I don't really need expected
release dates, I just need to know how I can determine if something is
"released" or not.

Thanks,

--
Paul Barker
Konsulko Group


nativesdk-ti-cgt-pru

alessioigorbogani@...
 

Hi all,

I would like produce an SDK for the my image which includes clpru
compiler so I have added in my image's recipe:
TOOLCHAIN_HOST_TASK_append += "nativesdk-ti-cgt-pru"
Unfortunately it doesn't work:
Error:
Problem: conflicting requests
- nothing provides libpthread.so.0 needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libdl.so.2 needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libm.so.6 needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libc.so.6(GLIBC_2.3) needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libdl.so.2(GLIBC_2.0) needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libdl.so.2(GLIBC_2.1) needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libm.so.6(GLIBC_2.0) needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libpthread.so.0(GLIBC_2.0) needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libpthread.so.0(GLIBC_2.1) needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libpthread.so.0(GLIBC_2.2) needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libpthread.so.0(GLIBC_2.2.3) needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libpthread.so.0(GLIBC_2.3.2) needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
(try to add '--skip-broken' to skip uninstallable packages or
'--nobest' to use not only best candidate packages)

What have I made wrong?

Thank you!

Ciao,
Alessio


nativesdk-ti-cgt-pru

Alessio Igor Bogani <alessioigorbogani@...>
 

Hi all,

I would like produce an SDK for the my image which includes clpru
compiler so I have added in my image's recipe:
TOOLCHAIN_HOST_TASK_append += "nativesdk-ti-cgt-pru"

Unfortunately it doesn't work:
Error:
Problem: conflicting requests
- nothing provides libpthread.so.0 needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libdl.so.2 needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libm.so.6 needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libc.so.6(GLIBC_2.3) needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libdl.so.2(GLIBC_2.0) needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libdl.so.2(GLIBC_2.1) needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libm.so.6(GLIBC_2.0) needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libpthread.so.0(GLIBC_2.0) needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libpthread.so.0(GLIBC_2.1) needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libpthread.so.0(GLIBC_2.2) needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libpthread.so.0(GLIBC_2.2.3) needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
- nothing provides libpthread.so.0(GLIBC_2.3.2) needed by
nativesdk-ti-cgt-pru-2.3.2-r0.x86_64_nativesdk
(try to add '--skip-broken' to skip uninstallable packages or
'--nobest' to use not only best candidate packages)

What have I made wrong?

Thank you!

Ciao,
Alessio


Re: [PATCH] u-boot-ti-staging_2020.01: Fix build on hosts with gcc10 on them

Suman Anna
 

Hi Praneeth,

On 11/18/20 9:03 PM, Khem Raj wrote:
ping

On Thu, Nov 12, 2020 at 5:13 PM Khem Raj <raj.khem@...> wrote:

Backport a patch from upstream to fix build on distros with gcc10+

Signed-off-by: Khem Raj <raj.khem@...>
---
...e-redundant-YYLOC-global-declaration.patch | 28 +++++++++++++++++++
.../u-boot/u-boot-ti-staging_2020.01.bb | 4 ++-
2 files changed, 31 insertions(+), 1 deletion(-)
create mode 100644 recipes-bsp/u-boot/files/0001-Remove-redundant-YYLOC-global-declaration.patch

diff --git a/recipes-bsp/u-boot/files/0001-Remove-redundant-YYLOC-global-declaration.patch b/recipes-bsp/u-boot/files/0001-Remove-redundant-YYLOC-global-declaration.patch
new file mode 100644
index 00000000..4973ea9d
--- /dev/null
+++ b/recipes-bsp/u-boot/files/0001-Remove-redundant-YYLOC-global-declaration.patch
@@ -0,0 +1,28 @@
+From b436a29de12d3f1da579edf3e3d4d42a60b9e58a Mon Sep 17 00:00:00 2001
+From: Peter Robinson <pbrobinson@...>
+Date: Thu, 30 Jan 2020 09:37:15 +0000
+Subject: [PATCH] Remove redundant YYLOC global declaration
+
+Same as the upstream fix for building dtc with gcc 10.
+
+Upstream-Status: Backport [https://github.com/u-boot/u-boot/commit/018921ee79d3f30893614b3b2b63b588d8544f73]
Please back-port this onto our U-Boot branch, so that we can drop this in the
next update.

regards
Suman

+Signed-off-by: Peter Robinson <pbrobinson@...>
+---
+ scripts/dtc/dtc-lexer.l | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/scripts/dtc/dtc-lexer.l b/scripts/dtc/dtc-lexer.l
+index fd825ebba6..24af549977 100644
+--- a/scripts/dtc/dtc-lexer.l
++++ b/scripts/dtc/dtc-lexer.l
+@@ -38,7 +38,6 @@ LINECOMMENT "//".*\n
+ #include "srcpos.h"
+ #include "dtc-parser.tab.h"
+
+-YYLTYPE yylloc;
+ extern bool treesource_error;
+
+ /* CAUTION: this will stop working if we ever use yyless() or yyunput() */
+--
+2.29.2
+
diff --git a/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb b/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb
index 991ba0ca..29fa6ee6 100644
--- a/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb
+++ b/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb
@@ -1,7 +1,9 @@
require u-boot-ti.inc

-PR = "r22"
+PR = "r23"

BRANCH = "ti-u-boot-2020.01"

SRCREV = "3c9ebdb87d65aacc4ec302be8bef3df15364bacd"
+
+SRC_URI += "file://0001-Remove-redundant-YYLOC-global-declaration.patch"
--
2.29.2





Re: [PATCH] u-boot-ti-staging_2020.01: Fix build on hosts with gcc10 on them

Khem Raj
 

ping

On Thu, Nov 12, 2020 at 5:13 PM Khem Raj <raj.khem@...> wrote:

Backport a patch from upstream to fix build on distros with gcc10+

Signed-off-by: Khem Raj <raj.khem@...>
---
...e-redundant-YYLOC-global-declaration.patch | 28 +++++++++++++++++++
.../u-boot/u-boot-ti-staging_2020.01.bb | 4 ++-
2 files changed, 31 insertions(+), 1 deletion(-)
create mode 100644 recipes-bsp/u-boot/files/0001-Remove-redundant-YYLOC-global-declaration.patch

diff --git a/recipes-bsp/u-boot/files/0001-Remove-redundant-YYLOC-global-declaration.patch b/recipes-bsp/u-boot/files/0001-Remove-redundant-YYLOC-global-declaration.patch
new file mode 100644
index 00000000..4973ea9d
--- /dev/null
+++ b/recipes-bsp/u-boot/files/0001-Remove-redundant-YYLOC-global-declaration.patch
@@ -0,0 +1,28 @@
+From b436a29de12d3f1da579edf3e3d4d42a60b9e58a Mon Sep 17 00:00:00 2001
+From: Peter Robinson <pbrobinson@...>
+Date: Thu, 30 Jan 2020 09:37:15 +0000
+Subject: [PATCH] Remove redundant YYLOC global declaration
+
+Same as the upstream fix for building dtc with gcc 10.
+
+Upstream-Status: Backport [https://github.com/u-boot/u-boot/commit/018921ee79d3f30893614b3b2b63b588d8544f73]
+Signed-off-by: Peter Robinson <pbrobinson@...>
+---
+ scripts/dtc/dtc-lexer.l | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/scripts/dtc/dtc-lexer.l b/scripts/dtc/dtc-lexer.l
+index fd825ebba6..24af549977 100644
+--- a/scripts/dtc/dtc-lexer.l
++++ b/scripts/dtc/dtc-lexer.l
+@@ -38,7 +38,6 @@ LINECOMMENT "//".*\n
+ #include "srcpos.h"
+ #include "dtc-parser.tab.h"
+
+-YYLTYPE yylloc;
+ extern bool treesource_error;
+
+ /* CAUTION: this will stop working if we ever use yyless() or yyunput() */
+--
+2.29.2
+
diff --git a/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb b/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb
index 991ba0ca..29fa6ee6 100644
--- a/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb
+++ b/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb
@@ -1,7 +1,9 @@
require u-boot-ti.inc

-PR = "r22"
+PR = "r23"

BRANCH = "ti-u-boot-2020.01"

SRCREV = "3c9ebdb87d65aacc4ec302be8bef3df15364bacd"
+
+SRC_URI += "file://0001-Remove-redundant-YYLOC-global-declaration.patch"
--
2.29.2


Re: How to tell when meta-ti/meta-arago or TI CoreSDK is released

 

On Tue, 17 Nov 2020 at 19:42, Dan Murphy <dmurphy@...> wrote:
Paul

On 11/17/20 1:17 PM, Paul Barker wrote:
Hey folks, apologies if this isn't the right place to ask but I can't
see where else I should be asking this question.

The Sancloud BSP layer (meta-sancloud) depends on both meta-arago and
meta-ti. For our Arago builds I typically pin release versions of
these dependency layers, especially for meta-arago and meta-ti I want
to ensure that we're using known good versions. The tag we're
currently pinned to is 07.00.00.005 which I believe corresponds to a
TI CoreSDK release. I see there are some new tags in these layers and
in the ti-linux-kernel repository

I also see that configs have been added to the oe-layersetup
repository which is usually my flag that something has been released.
However, in oe-layersetup both 07.01.00.004 and 07.01.00.005 have been
given config files while the meta-arago layer, meta-ti layer and
ti-linux-kernel recipes are up to 07.01.00.006. So my usual heuristics
are a bit confused.

I've tried searching for "ti coresdk" in google but I can't find any
documentation for this. I've also tried looking at the Arago wiki but
this does not look to have been updated recently. The only list of
branches I can find is
http://arago-project.org/wiki/index.php/Setting_Up_Build_Environment
which is definitely obsolete.

So all I can do is ask the question then - how do I find out when a
release of Arago (or TI CoreSDK) is ready to pick up and use?
This is on my to do for next year to try to document expected release dates.

To pre-empt the obvious question - we do test with the HEAD of the
dunfell branch of layers regularly but we're not happy to issue a
release of our own BSP without ensuring we're aligned on released
versions of the underlying layers where possible. We need to track the
releases in the ti-linux-kernel layer as we've seen in the past that
our kernel needs to match with the expectations of the meta-ti layer
if we want the PowerVR drivers to work.
Sorry for all the confusion. I created those additional configs for our
internal SDK consumers.

The official release will be 07.01.00.006 and I will be pushing that
config shortly.

Yes I understand the issue with the PVR modules and kernel dependencies.

Dan
Hi Dan,

Thanks for the quick reply there.

From my point-of-view what would be really helpful is release
announcement emails to the list when the release is "final" so that we
can easily tell that, for example in this case, 07.01.00.006 is the
release proper.

Thanks,

--
Paul Barker
Konsulko Group


Re: How to tell when meta-ti/meta-arago or TI CoreSDK is released

Dan Murphy <dmurphy@...>
 

Paul

On 11/17/20 1:17 PM, Paul Barker wrote:
Hey folks, apologies if this isn't the right place to ask but I can't
see where else I should be asking this question.

The Sancloud BSP layer (meta-sancloud) depends on both meta-arago and
meta-ti. For our Arago builds I typically pin release versions of
these dependency layers, especially for meta-arago and meta-ti I want
to ensure that we're using known good versions. The tag we're
currently pinned to is 07.00.00.005 which I believe corresponds to a
TI CoreSDK release. I see there are some new tags in these layers and
in the ti-linux-kernel repository

I also see that configs have been added to the oe-layersetup
repository which is usually my flag that something has been released.
However, in oe-layersetup both 07.01.00.004 and 07.01.00.005 have been
given config files while the meta-arago layer, meta-ti layer and
ti-linux-kernel recipes are up to 07.01.00.006. So my usual heuristics
are a bit confused.

I've tried searching for "ti coresdk" in google but I can't find any
documentation for this. I've also tried looking at the Arago wiki but
this does not look to have been updated recently. The only list of
branches I can find is
http://arago-project.org/wiki/index.php/Setting_Up_Build_Environment
which is definitely obsolete.

So all I can do is ask the question then - how do I find out when a
release of Arago (or TI CoreSDK) is ready to pick up and use?
This is on my to do for next year to try to document expected release dates.

To pre-empt the obvious question - we do test with the HEAD of the
dunfell branch of layers regularly but we're not happy to issue a
release of our own BSP without ensuring we're aligned on released
versions of the underlying layers where possible. We need to track the
releases in the ti-linux-kernel layer as we've seen in the past that
our kernel needs to match with the expectations of the meta-ti layer
if we want the PowerVR drivers to work.

Sorry for all the confusion. I created those additional configs for our internal SDK consumers.

The official release will be 07.01.00.006 and I will be pushing that config shortly.

Yes I understand the issue with the PVR modules and kernel dependencies.

Dan


Thanks,





How to tell when meta-ti/meta-arago or TI CoreSDK is released

 

Hey folks, apologies if this isn't the right place to ask but I can't
see where else I should be asking this question.

The Sancloud BSP layer (meta-sancloud) depends on both meta-arago and
meta-ti. For our Arago builds I typically pin release versions of
these dependency layers, especially for meta-arago and meta-ti I want
to ensure that we're using known good versions. The tag we're
currently pinned to is 07.00.00.005 which I believe corresponds to a
TI CoreSDK release. I see there are some new tags in these layers and
in the ti-linux-kernel repository

I also see that configs have been added to the oe-layersetup
repository which is usually my flag that something has been released.
However, in oe-layersetup both 07.01.00.004 and 07.01.00.005 have been
given config files while the meta-arago layer, meta-ti layer and
ti-linux-kernel recipes are up to 07.01.00.006. So my usual heuristics
are a bit confused.

I've tried searching for "ti coresdk" in google but I can't find any
documentation for this. I've also tried looking at the Arago wiki but
this does not look to have been updated recently. The only list of
branches I can find is
http://arago-project.org/wiki/index.php/Setting_Up_Build_Environment
which is definitely obsolete.

So all I can do is ask the question then - how do I find out when a
release of Arago (or TI CoreSDK) is ready to pick up and use?

To pre-empt the obvious question - we do test with the HEAD of the
dunfell branch of layers regularly but we're not happy to issue a
release of our own BSP without ensuring we're aligned on released
versions of the underlying layers where possible. We need to track the
releases in the ti-linux-kernel layer as we've seen in the past that
our kernel needs to match with the expectations of the meta-ti layer
if we want the PowerVR drivers to work.

Thanks,

--
Paul Barker
Konsulko Group


[dunfell/master] PATCH] ti-rtos: update metadata and firmware to 07.01.00.38

Dan Murphy <dmurphy@...>
 

Signed-off-by: Dan Murphy <dmurphy@...>
---
recipes-ti/ti-rtos-bin/ti-rtos-firmware.bb | 10 +++++-----
recipes-ti/ti-rtos-bin/ti-rtos-metadata.bb | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/recipes-ti/ti-rtos-bin/ti-rtos-firmware.bb b/recipes-ti/ti-rtos-bin/ti-rtos-firmware.bb
index 38c59936339f..01cf0fc91aa6 100644
--- a/recipes-ti/ti-rtos-bin/ti-rtos-firmware.bb
+++ b/recipes-ti/ti-rtos-bin/ti-rtos-firmware.bb
@@ -17,8 +17,8 @@ include ${DEPLOY_DIR_IMAGE}/metadata.inc

# Set some defaults for when metadata.inc is not available
DEFAULT_RTOS_FAMILY = "jacinto"
-DEFAULT_RTOS_VERSION = "07_01_00_33"
-DEFAULT_RTOS_VERSION_DOT = "07.01.00.33"
+DEFAULT_RTOS_VERSION = "07_01_00_38"
+DEFAULT_RTOS_VERSION_DOT = "07.01.00.38"

DEFAULT_RTOS_SOC = "undefined"
DEFAULT_RTOS_SOC_j7 = "j721e"
@@ -35,9 +35,9 @@ DEFAULT_FIRMWARE_URL = "file://empty"
DEFAULT_FIRMWARE_URL_k3 = "${CORESDK_RTOS_WEBLINK}/${DEFAULT_FIRMWARE_FILE}"

DEFAULT_FIRMWARE_SHA256SUM = "unknown"
-DEFAULT_FIRMWARE_SHA256SUM_j7 = "7b0e550c6d962b0868a2277f78720a46c9e69bd6df827186ccd3370db5010395"
-DEFAULT_FIRMWARE_SHA256SUM_j7200-evm = "44fdebe0fb1c8f536e96d00c1d68dc889a54b92402e71cdd901198940b1b8d51"
-DEFAULT_FIRMWARE_SHA256SUM_am65xx = "a0b64ea6c70cef2a38d25a92eaed28a2e87b2ab66e3c706f2995b81bebd64951"
+DEFAULT_FIRMWARE_SHA256SUM_j7 = "93e4d3742a922015f3295f5c20ef4bc2b9751139ffcd5620b8df7047bff50651"
+DEFAULT_FIRMWARE_SHA256SUM_j7200-evm = "cd5071a8f6ddaec05346e4c2bbeed6dc7bcb376d6edc47f81b9aeaf38f151176"
+DEFAULT_FIRMWARE_SHA256SUM_am65xx = "e54cc8da7fefa1ebf55454b184b42c364de3eebb34a328d244b8275b7763eb58"

# Use weak assignment for CORESDK_RTOS_* variables to use defaults if not yet set
CORESDK_RTOS_FAMILY ?= "${DEFAULT_RTOS_FAMILY}"
diff --git a/recipes-ti/ti-rtos-bin/ti-rtos-metadata.bb b/recipes-ti/ti-rtos-bin/ti-rtos-metadata.bb
index 205bbd1e3018..15c0c68cc2d8 100644
--- a/recipes-ti/ti-rtos-bin/ti-rtos-metadata.bb
+++ b/recipes-ti/ti-rtos-bin/ti-rtos-metadata.bb
@@ -17,7 +17,7 @@ PLAT_SFX_am65xx = "/am65xx"
# Use weak assignment to set defaults to TI_RTOS_METADATA_* variables
TI_RTOS_METADATA_URI ?= "git://git.ti.com/processor-sdk/coresdk_rtos_releases.git"
TI_RTOS_METADATA_PROTOCOL ?= "git"
-TI_RTOS_METADATA_SRCREV ?= "6da9722a7126a5834799ed6f7661787edb156198"
+TI_RTOS_METADATA_SRCREV ?= "6b63577eec787cde277d3d12b23ea80578b6ad91"
TI_RTOS_METADATA_BRANCH ?= "master"
TI_RTOS_METADATA_DIR ?= "${PLAT_SFX}"
TI_RTOS_METADATA_FILE ?= "${S}${TI_RTOS_METADATA_DIR}/metadata.inc"
--
2.29.2


[PATCH] u-boot-ti-staging_2020.01: Fix build on hosts with gcc10 on them

Khem Raj
 

Backport a patch from upstream to fix build on distros with gcc10+

Signed-off-by: Khem Raj <raj.khem@...>
---
...e-redundant-YYLOC-global-declaration.patch | 28 +++++++++++++++++++
.../u-boot/u-boot-ti-staging_2020.01.bb | 4 ++-
2 files changed, 31 insertions(+), 1 deletion(-)
create mode 100644 recipes-bsp/u-boot/files/0001-Remove-redundant-YYLOC-global-declaration.patch

diff --git a/recipes-bsp/u-boot/files/0001-Remove-redundant-YYLOC-global-declaration.patch b/recipes-bsp/u-boot/files/0001-Remove-redundant-YYLOC-global-declaration.patch
new file mode 100644
index 00000000..4973ea9d
--- /dev/null
+++ b/recipes-bsp/u-boot/files/0001-Remove-redundant-YYLOC-global-declaration.patch
@@ -0,0 +1,28 @@
+From b436a29de12d3f1da579edf3e3d4d42a60b9e58a Mon Sep 17 00:00:00 2001
+From: Peter Robinson <pbrobinson@...>
+Date: Thu, 30 Jan 2020 09:37:15 +0000
+Subject: [PATCH] Remove redundant YYLOC global declaration
+
+Same as the upstream fix for building dtc with gcc 10.
+
+Upstream-Status: Backport [https://github.com/u-boot/u-boot/commit/018921ee79d3f30893614b3b2b63b588d8544f73]
+Signed-off-by: Peter Robinson <pbrobinson@...>
+---
+ scripts/dtc/dtc-lexer.l | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/scripts/dtc/dtc-lexer.l b/scripts/dtc/dtc-lexer.l
+index fd825ebba6..24af549977 100644
+--- a/scripts/dtc/dtc-lexer.l
++++ b/scripts/dtc/dtc-lexer.l
+@@ -38,7 +38,6 @@ LINECOMMENT "//".*\n
+ #include "srcpos.h"
+ #include "dtc-parser.tab.h"
+
+-YYLTYPE yylloc;
+ extern bool treesource_error;
+
+ /* CAUTION: this will stop working if we ever use yyless() or yyunput() */
+--
+2.29.2
+
diff --git a/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb b/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb
index 991ba0ca..29fa6ee6 100644
--- a/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb
+++ b/recipes-bsp/u-boot/u-boot-ti-staging_2020.01.bb
@@ -1,7 +1,9 @@
require u-boot-ti.inc

-PR = "r22"
+PR = "r23"

BRANCH = "ti-u-boot-2020.01"

SRCREV = "3c9ebdb87d65aacc4ec302be8bef3df15364bacd"
+
+SRC_URI += "file://0001-Remove-redundant-YYLOC-global-declaration.patch"
--
2.29.2


[dunfell/master PATCH v2] k3conf: Update SRCREV to latest

Suman Anna
 

Use latest SRCREV on master branch to pick up all the
changes compliant with TIFS 2020.08b firmware.

The license CHKSUM also need to be updated due to a minor
change from http to https in the Copyright line.

Signed-off-by: Suman Anna <s-anna@...>
---
v2: Updated LIC_FILES_CHKSUM value to fix build error

recipes-devtools/k3conf/k3conf_git.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-devtools/k3conf/k3conf_git.bb b/recipes-devtools/k3conf/k3conf_git.bb
index 6771eeb7682e..e4fa54c3bee0 100644
--- a/recipes-devtools/k3conf/k3conf_git.bb
+++ b/recipes-devtools/k3conf/k3conf_git.bb
@@ -1,14 +1,14 @@
SUMMARY = "Diagnostic tool for TI K3 processors"

LICENSE = "BSD-3-Clause"
-LIC_FILES_CHKSUM = "file://common/k3conf.c;beginline=1;endline=34;md5=37f4e460bd8501c6f02ce71f02bc7ccf"
+LIC_FILES_CHKSUM = "file://common/k3conf.c;beginline=1;endline=34;md5=7154c0ffcd418064ffa528e34e70ca9d"

PV = "0.1+git${SRCPV}"

COMPATIBLE_MACHINE = "k3"

BRANCH ?= "master"
-SRCREV = "246eb4092d7d111ce10e0a310b9bde678b97ab36"
+SRCREV = "1ff0c4f429e8e33d22b52ec002d9b97bbca6bf0b"

SRC_URI = "git://git.ti.com/k3conf/k3conf.git;protocol=git;branch=${BRANCH}"

--
2.28.0


Re: [dunfell PATCH] k3conf: Update SRCREV to latest

Suman Anna
 

On 11/12/20 2:12 PM, Dan Murphy wrote:
Suman

On 11/12/20 9:21 AM, Dan Murphy wrote:
Suman

On 11/12/20 7:54 AM, Suman Anna wrote:
On 11/12/20 7:48 AM, Suman Anna wrote:
Use latest SRCREV on master branch to pick up all the
changes compliant with TIFS 2020.08b firmware.

Signed-off-by: Suman Anna <s-anna@...>
---
Hi Dan,

Please pick this up for 07.01.00.006. Will submit a separate patch
for master, looks like Nikhil missed one update to master branch.
Sorry, my bad, I take this back, my local master branch was not up-to-date. This
is applicable for master as well.
OK it is applied to -next and will be pushed shortly

Dan
Patch failed to build due to checksum mismatch on the License file due to this
commit
https://git.ti.com/gitweb?p=k3conf/k3conf.git;a=commit;h=bf1b4143e0065fb119766c2dddd8c08fb5ded7a9

ERROR: QA Issue: k3conf: The LIC_FILES_CHKSUM does not match for file://common/k3conf.c;beginline=1;endline=34;md5=37f4e460bd8501c6f02ce71f02bc7ccf
k3conf: The new md5 checksum is 7154c0ffcd418064ffa528e34e70ca9d
Sorry my bad, v2 coming shortly..

regards
Suman


Re: [dunfell PATCH] k3conf: Update SRCREV to latest

Dan Murphy <dmurphy@...>
 

Suman

On 11/12/20 9:21 AM, Dan Murphy wrote:
Suman

On 11/12/20 7:54 AM, Suman Anna wrote:
On 11/12/20 7:48 AM, Suman Anna wrote:
Use latest SRCREV on master branch to pick up all the
changes compliant with TIFS 2020.08b firmware.

Signed-off-by: Suman Anna <s-anna@...>
---
Hi Dan,

Please pick this up for 07.01.00.006. Will submit a separate patch
for master, looks like Nikhil missed one update to master branch.
Sorry, my bad, I take this back, my local master branch was not up-to-date. This
is applicable for master as well.

OK it is applied to -next and will be pushed shortly

Dan

Patch failed to build due to checksum mismatch on the License file due to this commit https://git.ti.com/gitweb?p=k3conf/k3conf.git;a=commit;h=bf1b4143e0065fb119766c2dddd8c08fb5ded7a9

ERROR: QA Issue: k3conf: The LIC_FILES_CHKSUM does not match for file://common/k3conf.c;beginline=1;endline=34;md5=37f4e460bd8501c6f02ce71f02bc7ccf
k3conf: The new md5 checksum is 7154c0ffcd418064ffa528e34e70ca9d

Dan


[dunfell/master] PATCH] ti-sci-fw: Update SHA to pick up 07.01.00.38 ti-dm firmware with 2020.08b sysfw

Dan Murphy <dmurphy@...>
 

Signed-off-by: Dan Murphy <dmurphy@...>
---
recipes-bsp/ti-sci-fw/ti-sci-fw.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-bsp/ti-sci-fw/ti-sci-fw.inc b/recipes-bsp/ti-sci-fw/ti-sci-fw.inc
index 24de33d67008..fe391e5fc40b 100644
--- a/recipes-bsp/ti-sci-fw/ti-sci-fw.inc
+++ b/recipes-bsp/ti-sci-fw/ti-sci-fw.inc
@@ -5,7 +5,7 @@ LIC_FILES_CHKSUM = "file://LICENSE.ti;md5=b5aebf0668bdf95621259288c4a46d76"

PV = "2020.08b"

-SRCREV = "f5685b5980d93709e20466ffa19145ffd83b4ca4"
+SRCREV = "c26c279257c13a0ff5002b09113fcff0e1d18853"
BRANCH ?= "ti-linux-firmware"
SRCREV_imggen = "7b4fe13d642d69a559724349aede4817891008a7"
SRCREV_FORMAT = "imggen"
--
2.29.2


Re: [dunfell PATCH] k3conf: Update SRCREV to latest

Dan Murphy <dmurphy@...>
 

Suman

On 11/12/20 7:54 AM, Suman Anna wrote:
On 11/12/20 7:48 AM, Suman Anna wrote:
Use latest SRCREV on master branch to pick up all the
changes compliant with TIFS 2020.08b firmware.

Signed-off-by: Suman Anna <s-anna@...>
---
Hi Dan,

Please pick this up for 07.01.00.006. Will submit a separate patch
for master, looks like Nikhil missed one update to master branch.
Sorry, my bad, I take this back, my local master branch was not up-to-date. This
is applicable for master as well.
OK it is applied to -next and will be pushed shortly

Dan


[dunfell/master] PATCH] linux-ti-staging: Update RT kernel hash to pick up a few fixes

Dan Murphy <dmurphy@...>
 

Signed-off-by: Dan Murphy <dmurphy@...>
---
recipes-kernel/linux/linux-ti-staging-rt_5.4.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/linux/linux-ti-staging-rt_5.4.bb b/recipes-kernel/linux/linux-ti-staging-rt_5.4.bb
index de1b4b7d9c27..4f3390624cfe 100644
--- a/recipes-kernel/linux/linux-ti-staging-rt_5.4.bb
+++ b/recipes-kernel/linux/linux-ti-staging-rt_5.4.bb
@@ -6,5 +6,5 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-5.4:"

BRANCH = "ti-rt-linux-5.4.y"

-SRCREV = "d4b0f63810a64c5f5c9876ba3492b647553d385d"
+SRCREV = "9002faf1c069e1b0d435199a80a89268e69aeecf"
PV = "5.4.74+git${SRCPV}"
--
2.29.2

2101 - 2120 of 15406