[PATCH 0/4] external-arm-toolchain: Add support for SDK generation

[PATCH 0/4] external-arm-toolchain: Add support for SDK generation

[Sumit Garg]

Patch #1 and #2 adds impprovements in external-arm-toolchain recipe in order to
support SDK generation. SDK generation has been tested using:

$ bitbake core-image-base -c populate_sdk

Patch #3 adds a README to describe usage details of pre-built Arm tool-set.

Patch #4 adds package specific licences for external-arm-toolchain recipe.

Sumit Garg (4):
  external-arm-toolchain: Remove glibc locale dependency
  external-arm-toolchain: Refine dev libraies packaging
  external-arm-toolchain: Add README
  external-arm-toolchain: Add package specific licenses

 .../conf/distro/include/tcmode-external-arm.inc    |  1 +
 .../external-arm-toolchain/README.md               | 50 ++++++++++++++
 .../external-arm-toolchain.bb                      | 29 ++++++++-
 .../external-arm-toolchain/license.inc             | 76 ++++++++++++++++++++++
 4 files changed, 154 insertions(+), 2 deletions(-)
 create mode 100644 meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md
 create mode 100644 meta-arm-toolchain/recipes-devtools/external-arm-toolchain/license.inc

-- 
2.7.4

[PATCH 1/4] external-arm-toolchain: Remove glibc locale dependency

[Sumit Garg]

External Arm tool-set doesn't seem to provide packages corresponding to
OE glibc locale recipe. So explicitly remove corresponding libc
dependencies.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
 meta-arm-toolchain/conf/distro/include/tcmode-external-arm.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta-arm-toolchain/conf/distro/include/tcmode-external-arm.inc b/meta-arm-toolchain/conf/distro/include/tcmode-external-arm.inc
index 9171380..eee1a51 100644
--- a/meta-arm-toolchain/conf/distro/include/tcmode-external-arm.inc
+++ b/meta-arm-toolchain/conf/distro/include/tcmode-external-arm.inc
@@ -58,6 +58,7 @@ DISTRO_FEATURES_LIBC = "ipv4 ipv6 libc-backtrace libc-big-macros libc-bsd libc-c
 ENABLE_BINARY_LOCALE_GENERATION = "0"
 GLIBC_INTERNAL_USE_BINARY_LOCALE = "precompiled"
 LIBCOVERRIDE = ":libc-glibc"
+LIBC_DEPENDENCIES_remove = "glibc-gconv-cp1252 glibc-gconv-ibm850 glibc-gconv-iso8859-1 glibc-gconv-iso8859-15 glibc-localedata-i18n"
 
 ERROR_QA[type] ?= "list"
 python toolchain_metadata_setup () {
-- 
2.7.4

[PATCH 2/4] external-arm-toolchain: Refine dev libraies packaging

[Sumit Garg]

OE core by default package all libraies installed as "${libdir}/lib*.so"
or "${libdir}/*.la" as part of "FILES_${PN}-dev" but in case of external
Arm tool-set recipe, multiple packages are provided which needs to
include specific libraries. So split dev libraries packaging accordingly
and only package remaining libraries as part of "FILES_${PN}-dev" which
aren't provided as part of other packages.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
 .../external-arm-toolchain.bb                      | 23 ++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
index 04d8923..7f5a6f5 100644
--- a/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
+++ b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
@@ -545,6 +545,29 @@ FILES_${PN} += "\
 	${base_libdir}/libpcprofile.so \
     "
 
+FILES_${PN}-dev_remove = "\
+	${libdir}/lib*.so \
+	${libdir}/*.la \
+    "
+FILES_${PN}-dev += "\
+	${libdir}/libcrypt.so \
+	${libdir}/libc.so \
+	${libdir}/libm.so \
+	${libdir}/libpthread.so \
+	${libdir}/libresolv.so \
+	${libdir}/librt.so \
+	${libdir}/libutil.so \
+	${libdir}/libnss_files.so \
+	${libdir}/libnss_compat.so \
+	${libdir}/libnss_dns.so \
+	${libdir}/libnss_hesiod.so \
+	${libdir}/libnss_db.so \
+	${libdir}/libdl.so \
+	${libdir}/libanl.so \
+	${libdir}/libBrokenLocale.so \
+	${libdir}/libthread_db.so \
+    "
+
 FILES_${PN}-dbg += "${base_libdir}/debug"
 
 # From gcc-runtime.inc
-- 
2.7.4

[PATCH 3/4] external-arm-toolchain: Add README

[Sumit Garg]

Document usage details for pre-built Arm toolchains.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
 .../external-arm-toolchain/README.md               | 50 ++++++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md

diff --git a/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md
new file mode 100644
index 0000000..65d1a42
--- /dev/null
+++ b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md
@@ -0,0 +1,50 @@
+Pre-built Arm toolchain recipes
+===============================
+
+Introduction
+------------
+This layer contains recipes for pre-built Arm toolchain recipes as follows:
+
+external-arm-toolchain.bb
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This recipe provides support for pre-built GNU toolchains targeting processors
+from the Arm Cortex-A family and implementing the Arm A-profile architecture.
+
+Usage
+^^^^^
+
+In order to use any of pre-built Arm toolchain versions (8.2, 8.3, 9.2 and so
+on), a user needs to download and untar tool-set on host machine at a particular
+installation path eg: ``/opt/toolchain/``. Then user needs to specify following
+in ``conf/local.conf`` in order to replace OE toolcahin with pre-built GNU-A
+toolchain:
+
+TCMODE = "external-arm"
+EXTERNAL_TOOLCHAIN = "<path-to-the-toolchain>"
+
+-  Eg. for AArch64 (eg. qemuarm64 machine in poky distro)
+   EXTERNAL_TOOLCHAIN = "\
+     <installation-path>/gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu \
+   "
+
+-  Eg. for AArch32 (eg. qemuarm machine in poky distro)
+   EXTERNAL_TOOLCHAIN = "\
+     <installation-path>/gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf \
+   "
+
+Supported distros and machines
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Since this pre-built GNU-A tool-set simply replaces OE toolchain, so it is
+meant to be distro and machine agnostic as long as one is cross-compiling for
+Arm A-profile architecture.
+
+gcc-arm-none-eabi_<version>.bb
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This recipe provides support for pre-built GNU Arm Embedded toolchain for
+bare-metal software development on devices based on 32-bit Arm Cortex-A,
+Cortex-R and Cortex-M processors.
+
+Supported version: 9-2019-q4-major
-- 
2.7.4

[PATCH 4/4] external-arm-toolchain: Add package specific licenses

[Sumit Garg]

Add license.inc file to state license of various packages provided by
pre-built Arm tool-set.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
 .../external-arm-toolchain.bb                      |  6 +-
 .../external-arm-toolchain/license.inc             | 76 ++++++++++++++++++++++
 2 files changed, 80 insertions(+), 2 deletions(-)
 create mode 100644 meta-arm-toolchain/recipes-devtools/external-arm-toolchain/license.inc

diff --git a/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
index 7f5a6f5..6bceed0 100644
--- a/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
+++ b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
@@ -1,9 +1,11 @@
+# This recipe is distributed under MIT license.
+
 require recipes-core/glibc/glibc-package.inc
 
+require license.inc
+
 INHIBIT_DEFAULT_DEPS = "1"
 
-# License applies to this recipe code, not the toolchain itself
-LICENSE = "MIT"
 LIC_FILES_CHKSUM = "\
 	file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302 \
 	file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420 \
diff --git a/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/license.inc b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/license.inc
new file mode 100644
index 0000000..b6ee42c
--- /dev/null
+++ b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/license.inc
@@ -0,0 +1,76 @@
+LICENSE = "GPL-3.0-with-GCC-exception & GPLv3 & GPLv2 & LGPLv3 & LGPLv2.1 & LGPLv2"
+
+EAT_GCC_LICENSE = "GPL-3.0-with-GCC-exception & GPLv3"
+EAT_LIBC_LICENSE = "GPLv2 & LGPLv2.1"
+
+LICENSE_${PN} = "${EAT_LIBC_LICENSE}"
+LICENSE_${PN}-dev = "${EAT_LIBC_LICENSE}"
+LICENSE_${PN}-doc = "${EAT_LIBC_LICENSE}"
+LICENSE_${PN}-dbg = "${EAT_LIBC_LICENSE}"
+LICENSE_${PN}-pic = "${EAT_LIBC_LICENSE}"
+LICENSE_${PN}-utils = "${EAT_LIBC_LICENSE}"
+LICENSE_${PN}-mtrace = "${EAT_LIBC_LICENSE}"
+LICENSE_${PN}-gconv = "${EAT_LIBC_LICENSE}"
+LICENSE_${PN}-extra-nss = "${EAT_LIBC_LICENSE}"
+LICENSE_${PN}-thread-db = "${EAT_LIBC_LICENSE}"
+LICENSE_${PN}-pcprofile = "${EAT_LIBC_LICENSE}"
+LICENSE_${PN}-staticdev = "${EAT_LIBC_LICENSE}"
+LICENSE_catchsegv = "${EAT_LIBC_LICENSE}"
+LICENSE_glibc-extra-nss = "${EAT_LIBC_LICENSE}"
+LICENSE_glibc-thread-db = "${EAT_LIBC_LICENSE}"
+
+LICENSE_libmemusage = "${EAT_LIBC_LICENSE}"
+LICENSE_libsegfault = "${EAT_LIBC_LICENSE}"
+LICENSE_libsotruss = "${EAT_LIBC_LICENSE}"
+LICENSE_sln = "${EAT_LIBC_LICENSE}"
+LICENSE_nscd = "${EAT_LIBC_LICENSE}"
+LICENSE_ldd = "${EAT_LIBC_LICENSE}"
+
+LICENSE_libasan-dev = "${EAT_GCC_LICENSE}"
+LICENSE_libasan = "${EAT_GCC_LICENSE}"
+LICENSE_libasan-staticdev = "${EAT_GCC_LICENSE}"
+LICENSE_libatomic-dev = "${EAT_GCC_LICENSE}"
+LICENSE_libatomic = "${EAT_GCC_LICENSE}"
+LICENSE_libatomic-staticdev = "${EAT_GCC_LICENSE}"
+LICENSE_libg2c-dev = "${EAT_GCC_LICENSE}"
+LICENSE_libg2c = "${EAT_GCC_LICENSE}"
+LICENSE_libgcc-dev = "${EAT_GCC_LICENSE}"
+LICENSE_libgcc = "${EAT_GCC_LICENSE}"
+LICENSE_libgfortran-dbg = "${EAT_GCC_LICENSE}"
+LICENSE_libgfortran-dev = "${EAT_GCC_LICENSE}"
+LICENSE_libgfortran = "${EAT_GCC_LICENSE}"
+LICENSE_libgfortran-staticdev = "${EAT_GCC_LICENSE}"
+LICENSE_libgomp-dev = "${EAT_GCC_LICENSE}"
+LICENSE_libgomp = "${EAT_GCC_LICENSE}"
+LICENSE_libgomp-staticdev = "${EAT_GCC_LICENSE}"
+LICENSE_libitm-dev = "${EAT_GCC_LICENSE}"
+LICENSE_libitm = "${EAT_GCC_LICENSE}"
+LICENSE_libitm-staticdev = "${EAT_GCC_LICENSE}"
+LICENSE_liblsan-dev = "${EAT_GCC_LICENSE}"
+LICENSE_liblsan = "${EAT_GCC_LICENSE}"
+LICENSE_liblsan-staticdev = "${EAT_GCC_LICENSE}"
+LICENSE_libmudflap-dev = "${EAT_GCC_LICENSE}"
+LICENSE_libmudflap = "${EAT_GCC_LICENSE}"
+LICENSE_libmudflap-staticdev = "${EAT_GCC_LICENSE}"
+LICENSE_libquadmath-dev = "${EAT_GCC_LICENSE}"
+LICENSE_libquadmath = "${EAT_GCC_LICENSE}"
+LICENSE_libquadmath-staticdev = "${EAT_GCC_LICENSE}"
+LICENSE_libssp-dev = "${EAT_GCC_LICENSE}"
+LICENSE_libssp = "${EAT_GCC_LICENSE}"
+LICENSE_libssp-staticdev = "${EAT_GCC_LICENSE}"
+LICENSE_libstdc++-dbg = "${EAT_GCC_LICENSE}"
+LICENSE_libstdc++-dev = "${EAT_GCC_LICENSE}"
+LICENSE_libstdc++ = "${EAT_GCC_LICENSE}"
+LICENSE_libstdc++-precompile-dev = "${EAT_GCC_LICENSE}"
+LICENSE_libstdc++-staticdev = "${EAT_GCC_LICENSE}"
+LICENSE_libtsan-dev = "${EAT_GCC_LICENSE}"
+LICENSE_libtsan = "${EAT_GCC_LICENSE}"
+LICENSE_libtsan-staticdev = "${EAT_GCC_LICENSE}"
+LICENSE_libubsan-dev = "${EAT_GCC_LICENSE}"
+LICENSE_libubsan = "${EAT_GCC_LICENSE}"
+LICENSE_libubsan-staticdev = "${EAT_GCC_LICENSE}"
+
+LICENSE_linux-libc-headers-dev = "GPLv2"
+LICENSE_linux-libc-headers = "GPLv2"
+
+LICENSE_gdbserver = "GPLv2 & GPLv3 & LGPLv2 & LGPLv3"
-- 
2.7.4

Re: [PATCH 0/4] external-arm-toolchain: Add support for SDK generation

[Paul Barker]

On Tue, 2 Jun 2020 at 12:05, Sumit Garg <sumit.garg@linaro.org> wrote:
>
> Patch #1 and #2 adds impprovements in external-arm-toolchain recipe in order to
> support SDK generation. SDK generation has been tested using:
>
> $ bitbake core-image-base -c populate_sdk
>
> Patch #3 adds a README to describe usage details of pre-built Arm tool-set.
>
> Patch #4 adds package specific licences for external-arm-toolchain recipe.
>
> Sumit Garg (4):
>   external-arm-toolchain: Remove glibc locale dependency
>   external-arm-toolchain: Refine dev libraies packaging
>   external-arm-toolchain: Add README
>   external-arm-toolchain: Add package specific licenses
>
>  .../conf/distro/include/tcmode-external-arm.inc    |  1 +
>  .../external-arm-toolchain/README.md               | 50 ++++++++++++++
>  .../external-arm-toolchain.bb                      | 29 ++++++++-
>  .../external-arm-toolchain/license.inc             | 76 ++++++++++++++++++++++
>  4 files changed, 154 insertions(+), 2 deletions(-)
>  create mode 100644 meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md
>  create mode 100644 meta-arm-toolchain/recipes-devtools/external-arm-toolchain/license.inc
>
> --
> 2.7.4

Thanks for these, they all look good at first glance. I'll have some
time to properly review and test the changes in a couple of days.

-- 
Paul Barker
Konsulko Group

Re: [PATCH 1/4] external-arm-toolchain: Remove glibc locale dependency

[Denys Dmytriyenko]

On Tue, Jun 02, 2020 at 04:34:51PM +0530, Sumit Garg wrote:
> External Arm tool-set

Why do you call it tool-set? It's definitely not critical, but toolchain is 
kind of a standard name for this:
https://en.wikipedia.org/wiki/Toolchain


> doesn't seem to provide packages corresponding to OE glibc locale recipe.

Actually, the toolchain itself does provide all the gconv libs, AFAICS, 
it's just they are not packaged by the recipe. When I hit it back in April, 
I just didn't have time and ended up with LIBC_DEPENDENCIES_remove hack as 
a temporary workaround, planning to enevtually go back and fix it properly:
http://arago-project.org/git/?p=meta-arago.git;a=blobdiff;f=meta-arago-distro/conf/distro/arago.conf;hb=84c30ee97056589ba0811428527f4adf8268c9b2;hpb=3a4ed9d1e8a118aefb2ef49ce450f74f14e239d0

So, re-using this LIBC_DEPENDENCIES_remove here in upstream meta-arm isn't 
correct...


> So explicitly remove corresponding libc dependencies.
> 
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>  meta-arm-toolchain/conf/distro/include/tcmode-external-arm.inc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta-arm-toolchain/conf/distro/include/tcmode-external-arm.inc b/meta-arm-toolchain/conf/distro/include/tcmode-external-arm.inc
> index 9171380..eee1a51 100644
> --- a/meta-arm-toolchain/conf/distro/include/tcmode-external-arm.inc
> +++ b/meta-arm-toolchain/conf/distro/include/tcmode-external-arm.inc
> @@ -58,6 +58,7 @@ DISTRO_FEATURES_LIBC = "ipv4 ipv6 libc-backtrace libc-big-macros libc-bsd libc-c
>  ENABLE_BINARY_LOCALE_GENERATION = "0"
>  GLIBC_INTERNAL_USE_BINARY_LOCALE = "precompiled"
>  LIBCOVERRIDE = ":libc-glibc"
> +LIBC_DEPENDENCIES_remove = "glibc-gconv-cp1252 glibc-gconv-ibm850 glibc-gconv-iso8859-1 glibc-gconv-iso8859-15 glibc-localedata-i18n"

You shouldn't be using _remove in meta-arm, as it's not the final layer and 
there won't be any way to override this in BSPs or Distros.


>  ERROR_QA[type] ?= "list"
>  python toolchain_metadata_setup () {
> -- 
> 2.7.4
> 

Re: [PATCH 2/4] external-arm-toolchain: Refine dev libraies packaging

[Denys Dmytriyenko]

On Tue, Jun 02, 2020 at 04:34:52PM +0530, Sumit Garg wrote:
> OE core by default package all libraies installed as "${libdir}/lib*.so"
> or "${libdir}/*.la" as part of "FILES_${PN}-dev" but in case of external
> Arm tool-set recipe, multiple packages are provided which needs to
> include specific libraries. So split dev libraries packaging accordingly
> and only package remaining libraries as part of "FILES_${PN}-dev" which
> aren't provided as part of other packages.
> 
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>  .../external-arm-toolchain.bb                      | 23 ++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
> index 04d8923..7f5a6f5 100644
> --- a/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
> +++ b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
> @@ -545,6 +545,29 @@ FILES_${PN} += "\
>  	${base_libdir}/libpcprofile.so \
>      "
>  
> +FILES_${PN}-dev_remove = "\

Shouldn't be using _remove here. It will probably break anyones .bbappends on 
this recipe and will make it hard making any adjustments.

If you check git logs, you'll see that every time we needed to change the 
default lists defined by glibc-package.inc in OE-Core, we had to re-create 
them from scratch.


> +	${libdir}/lib*.so \
> +	${libdir}/*.la \
> +    "
> +FILES_${PN}-dev += "\
> +	${libdir}/libcrypt.so \
> +	${libdir}/libc.so \
> +	${libdir}/libm.so \
> +	${libdir}/libpthread.so \
> +	${libdir}/libresolv.so \
> +	${libdir}/librt.so \
> +	${libdir}/libutil.so \
> +	${libdir}/libnss_files.so \
> +	${libdir}/libnss_compat.so \
> +	${libdir}/libnss_dns.so \
> +	${libdir}/libnss_hesiod.so \
> +	${libdir}/libnss_db.so \
> +	${libdir}/libdl.so \
> +	${libdir}/libanl.so \
> +	${libdir}/libBrokenLocale.so \
> +	${libdir}/libthread_db.so \
> +    "
> +
>  FILES_${PN}-dbg += "${base_libdir}/debug"
>  
>  # From gcc-runtime.inc
> -- 
> 2.7.4
> 

Re: [PATCH 3/4] external-arm-toolchain: Add README

[Denys Dmytriyenko]

On Tue, Jun 02, 2020 at 04:34:53PM +0530, Sumit Garg wrote:
> Document usage details for pre-built Arm toolchains.
> 
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>  .../external-arm-toolchain/README.md               | 50 ++++++++++++++++++++++
>  1 file changed, 50 insertions(+)
>  create mode 100644 meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md
> 
> diff --git a/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md
> new file mode 100644
> index 0000000..65d1a42
> --- /dev/null
> +++ b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md
> @@ -0,0 +1,50 @@
> +Pre-built Arm toolchain recipes
> +===============================
> +
> +Introduction
> +------------
> +This layer contains recipes for pre-built Arm toolchain recipes as follows:
> +
> +external-arm-toolchain.bb
> +~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +This recipe provides support for pre-built GNU toolchains targeting processors
> +from the Arm Cortex-A family and implementing the Arm A-profile architecture.
> +
> +Usage
> +^^^^^
> +
> +In order to use any of pre-built Arm toolchain versions (8.2, 8.3, 9.2 and so
> +on), a user needs to download and untar tool-set on host machine at a particular
> +installation path eg: ``/opt/toolchain/``. Then user needs to specify following
> +in ``conf/local.conf`` in order to replace OE toolcahin with pre-built GNU-A
> +toolchain:
> +
> +TCMODE = "external-arm"
> +EXTERNAL_TOOLCHAIN = "<path-to-the-toolchain>"
> +
> +-  Eg. for AArch64 (eg. qemuarm64 machine in poky distro)
> +   EXTERNAL_TOOLCHAIN = "\
> +     <installation-path>/gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu \
> +   "
> +
> +-  Eg. for AArch32 (eg. qemuarm machine in poky distro)
> +   EXTERNAL_TOOLCHAIN = "\
> +     <installation-path>/gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf \
> +   "
> +
> +Supported distros and machines
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +Since this pre-built GNU-A tool-set simply replaces OE toolchain, so it is
> +meant to be distro and machine agnostic as long as one is cross-compiling for
> +Arm A-profile architecture.
> +
> +gcc-arm-none-eabi_<version>.bb
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

gcc-aarch64-none-elf?

Probably need to explain a bit more regarding the differences between 
baremetal and Linux toolchains, as currently it can be confusing to some 
why there are 2 sets of toolchain recipes...


> +This recipe provides support for pre-built GNU Arm Embedded toolchain for
> +bare-metal software development on devices based on 32-bit Arm Cortex-A,
> +Cortex-R and Cortex-M processors.
> +
> +Supported version: 9-2019-q4-major
> -- 
> 2.7.4
> 

Re: [PATCH 0/4] external-arm-toolchain: Add support for SDK generation

[Denys Dmytriyenko]

On Tue, Jun 02, 2020 at 04:34:50PM +0530, Sumit Garg wrote:
> Patch #1 and #2 adds impprovements in external-arm-toolchain recipe in order to
> support SDK generation. SDK generation has been tested using:
> 
> $ bitbake core-image-base -c populate_sdk

This just ensures that external-arm-toolchain doesn't get in the way of SDK 
generation by avoiding any conflicts. The only re-use here is glibc. The rest 
of pre-built Arm toolchain gets thrown out and rebuilt from sources - gcc, 
binutils, gdb/gdbserver are all built from sources as TCMODE was not set and 
falls back to "default". Sure, pre-built Arm toolchain doesn't provide all 
possible SDKMACHINE binaries, but for 90% cases of x86_64, there's very little 
re-use...


> Patch #3 adds a README to describe usage details of pre-built Arm tool-set.
> 
> Patch #4 adds package specific licences for external-arm-toolchain recipe.
> 
> Sumit Garg (4):
>   external-arm-toolchain: Remove glibc locale dependency
>   external-arm-toolchain: Refine dev libraies packaging
>   external-arm-toolchain: Add README
>   external-arm-toolchain: Add package specific licenses
> 
>  .../conf/distro/include/tcmode-external-arm.inc    |  1 +
>  .../external-arm-toolchain/README.md               | 50 ++++++++++++++
>  .../external-arm-toolchain.bb                      | 29 ++++++++-
>  .../external-arm-toolchain/license.inc             | 76 ++++++++++++++++++++++
>  4 files changed, 154 insertions(+), 2 deletions(-)
>  create mode 100644 meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md
>  create mode 100644 meta-arm-toolchain/recipes-devtools/external-arm-toolchain/license.inc
> 
> -- 
> 2.7.4
> 

Re: [meta-arm] [PATCH 0/4] external-arm-toolchain: Add support for SDK generation

[Denys Dmytriyenko]

On Thu, Jun 04, 2020 at 07:00:14PM -0400, Denys Dmytriyenko wrote:
> On Tue, Jun 02, 2020 at 04:34:50PM +0530, Sumit Garg wrote:
> > Patch #1 and #2 adds impprovements in external-arm-toolchain recipe in order to
> > support SDK generation. SDK generation has been tested using:
> > 
> > $ bitbake core-image-base -c populate_sdk
> 
> This just ensures that external-arm-toolchain doesn't get in the way of SDK 
> generation by avoiding any conflicts. The only re-use here is glibc. The rest 
> of pre-built Arm toolchain gets thrown out and rebuilt from sources - gcc, 
> binutils, gdb/gdbserver are all built from sources as TCMODE was not set and 
> falls back to "default". Sure, pre-built Arm toolchain doesn't provide all 
> possible SDKMACHINE binaries, but for 90% cases of x86_64, there's very little 
> re-use...

And I wonder is the resulting SDK was even tested:

$ . environment-setup-armv7at2hf-neon-oe-linux-gnueabi

$ arm-none-linux-gnueabihf-gcc -o hello hello.c 
hello.c:1:10: fatal error: stdio.h: No such file or directory
    1 | #include <stdio.h>
      |          ^~~~~~~~~
compilation terminated.

$ arm-none-linux-gnueabihf-g++ -o hello++ hello.cpp 
hello.cpp:1:10: fatal error: iostream: No such file or directory
    1 | #include <iostream>
      |          ^~~~~~~~~~
compilation terminated.


> > Patch #3 adds a README to describe usage details of pre-built Arm tool-set.
> > 
> > Patch #4 adds package specific licences for external-arm-toolchain recipe.
> > 
> > Sumit Garg (4):
> >   external-arm-toolchain: Remove glibc locale dependency
> >   external-arm-toolchain: Refine dev libraies packaging
> >   external-arm-toolchain: Add README
> >   external-arm-toolchain: Add package specific licenses
> > 
> >  .../conf/distro/include/tcmode-external-arm.inc    |  1 +
> >  .../external-arm-toolchain/README.md               | 50 ++++++++++++++
> >  .../external-arm-toolchain.bb                      | 29 ++++++++-
> >  .../external-arm-toolchain/license.inc             | 76 ++++++++++++++++++++++
> >  4 files changed, 154 insertions(+), 2 deletions(-)
> >  create mode 100644 meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md
> >  create mode 100644 meta-arm-toolchain/recipes-devtools/external-arm-toolchain/license.inc
> > 
> > -- 
> > 2.7.4
> > 

> 

Re: [meta-arm] [PATCH 0/4] external-arm-toolchain: Add support for SDK generation

[Richard Purdie]

On Thu, 2020-06-04 at 19:10 -0400, Denys Dmytriyenko wrote:
> On Thu, Jun 04, 2020 at 07:00:14PM -0400, Denys Dmytriyenko wrote:
> > On Tue, Jun 02, 2020 at 04:34:50PM +0530, Sumit Garg wrote:
> > > Patch #1 and #2 adds impprovements in external-arm-toolchain
> > > recipe in order to
> > > support SDK generation. SDK generation has been tested using:
> > > 
> > > $ bitbake core-image-base -c populate_sdk
> > 
> > This just ensures that external-arm-toolchain doesn't get in the
> > way of SDK 
> > generation by avoiding any conflicts. The only re-use here is
> > glibc. The rest 
> > of pre-built Arm toolchain gets thrown out and rebuilt from sources
> > - gcc, 
> > binutils, gdb/gdbserver are all built from sources as TCMODE was
> > not set and 
> > falls back to "default". Sure, pre-built Arm toolchain doesn't
> > provide all 
> > possible SDKMACHINE binaries, but for 90% cases of x86_64, there's
> > very little 
> > re-use...
> 
> And I wonder is the resulting SDK was even tested:
> 
> $ . environment-setup-armv7at2hf-neon-oe-linux-gnueabi
> 
> $ arm-none-linux-gnueabihf-gcc -o hello hello.c 
> hello.c:1:10: fatal error: stdio.h: No such file or directory
>     1 | #include <stdio.h>
>       |          ^~~~~~~~~
> compilation terminated.
> 
> $ arm-none-linux-gnueabihf-g++ -o hello++ hello.cpp 
> hello.cpp:1:10: fatal error: iostream: No such file or directory
>     1 | #include <iostream>
>       |          ^~~~~~~~~~
> compilation terminated.

If you've done "bitbake core-image-base -c populate_sdk" to build it,
you can do "bitbake core-image-base -c testsdk" to test it as we have
basic automated QA tests for that.

Cheers,

Richard

Re: [meta-arm] [PATCH 0/4] external-arm-toolchain: Add support for SDK generation

[Sumit Garg]

On Fri, 5 Jun 2020 at 11:54, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Thu, 2020-06-04 at 19:10 -0400, Denys Dmytriyenko wrote:
> > On Thu, Jun 04, 2020 at 07:00:14PM -0400, Denys Dmytriyenko wrote:
> > > On Tue, Jun 02, 2020 at 04:34:50PM +0530, Sumit Garg wrote:
> > > > Patch #1 and #2 adds impprovements in external-arm-toolchain
> > > > recipe in order to
> > > > support SDK generation. SDK generation has been tested using:
> > > >
> > > > $ bitbake core-image-base -c populate_sdk
> > >
> > > This just ensures that external-arm-toolchain doesn't get in the
> > > way of SDK
> > > generation by avoiding any conflicts. The only re-use here is
> > > glibc. The rest
> > > of pre-built Arm toolchain gets thrown out and rebuilt from sources
> > > - gcc,
> > > binutils, gdb/gdbserver are all built from sources as TCMODE was
> > > not set and
> > > falls back to "default". Sure, pre-built Arm toolchain doesn't
> > > provide all
> > > possible SDKMACHINE binaries, but for 90% cases of x86_64, there's
> > > very little
> > > re-use...
> >
> > And I wonder is the resulting SDK was even tested:
> >
> > $ . environment-setup-armv7at2hf-neon-oe-linux-gnueabi
> >
> > $ arm-none-linux-gnueabihf-gcc -o hello hello.c
> > hello.c:1:10: fatal error: stdio.h: No such file or directory
> >     1 | #include <stdio.h>
> >       |          ^~~~~~~~~
> > compilation terminated.
> >
> > $ arm-none-linux-gnueabihf-g++ -o hello++ hello.cpp
> > hello.cpp:1:10: fatal error: iostream: No such file or directory
> >     1 | #include <iostream>
> >       |          ^~~~~~~~~~
> > compilation terminated.

I guess you missed the basics to use the installed SDK as you haven't
provided a proper sysroot path. See expansion of "$CC" below:

$ . environment-setup-aarch64-poky-linux
$ echo $CC
aarch64-none-linux-gnu-gcc -march=armv8-a+crc
--sysroot=/home/sumit.garg/temp/oe_sdk/sysroots/aarch64-poky-linux

>
> If you've done "bitbake core-image-base -c populate_sdk" to build it,
> you can do "bitbake core-image-base -c testsdk" to test it as we have
> basic automated QA tests for that.

Thanks for this pointer. There are test cases which are failing, will fix them.

-Sumit

>
> Cheers,
>
> Richard
>
>
>
>
>
>

Re: [PATCH 2/4] external-arm-toolchain: Refine dev libraies packaging

[Sumit Garg]

On Fri, 5 Jun 2020 at 00:12, Denys Dmytriyenko <denis@denix.org> wrote:
>
> On Tue, Jun 02, 2020 at 04:34:52PM +0530, Sumit Garg wrote:
> > OE core by default package all libraies installed as "${libdir}/lib*.so"
> > or "${libdir}/*.la" as part of "FILES_${PN}-dev" but in case of external
> > Arm tool-set recipe, multiple packages are provided which needs to
> > include specific libraries. So split dev libraries packaging accordingly
> > and only package remaining libraries as part of "FILES_${PN}-dev" which
> > aren't provided as part of other packages.
> >
> > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > ---
> >  .../external-arm-toolchain.bb                      | 23 ++++++++++++++++++++++
> >  1 file changed, 23 insertions(+)
> >
> > diff --git a/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
> > index 04d8923..7f5a6f5 100644
> > --- a/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
> > +++ b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
> > @@ -545,6 +545,29 @@ FILES_${PN} += "\
> >       ${base_libdir}/libpcprofile.so \
> >      "
> >
> > +FILES_${PN}-dev_remove = "\
>
> Shouldn't be using _remove here. It will probably break anyones .bbappends on
> this recipe and will make it hard making any adjustments.
>

Any specific reason to use .bbappends? Why can't those changes land in
meta-arm instead?

> If you check git logs, you'll see that every time we needed to change the
> default lists defined by glibc-package.inc in OE-Core, we had to re-create
> them from scratch.
>

Sounds reasonable, will create FILES_${PN}-dev from scratch instead.

-Sumit

>
> > +     ${libdir}/lib*.so \
> > +     ${libdir}/*.la \
> > +    "
> > +FILES_${PN}-dev += "\
> > +     ${libdir}/libcrypt.so \
> > +     ${libdir}/libc.so \
> > +     ${libdir}/libm.so \
> > +     ${libdir}/libpthread.so \
> > +     ${libdir}/libresolv.so \
> > +     ${libdir}/librt.so \
> > +     ${libdir}/libutil.so \
> > +     ${libdir}/libnss_files.so \
> > +     ${libdir}/libnss_compat.so \
> > +     ${libdir}/libnss_dns.so \
> > +     ${libdir}/libnss_hesiod.so \
> > +     ${libdir}/libnss_db.so \
> > +     ${libdir}/libdl.so \
> > +     ${libdir}/libanl.so \
> > +     ${libdir}/libBrokenLocale.so \
> > +     ${libdir}/libthread_db.so \
> > +    "
> > +
> >  FILES_${PN}-dbg += "${base_libdir}/debug"
> >
> >  # From gcc-runtime.inc
> > --
> > 2.7.4
> >

Re: [PATCH 1/4] external-arm-toolchain: Remove glibc locale dependency

[Sumit Garg]

On Fri, 5 Jun 2020 at 00:06, Denys Dmytriyenko <denis@denix.org> wrote:
>
> On Tue, Jun 02, 2020 at 04:34:51PM +0530, Sumit Garg wrote:
> > External Arm tool-set
>
> Why do you call it tool-set? It's definitely not critical, but toolchain is
> kind of a standard name for this:
> https://en.wikipedia.org/wiki/Toolchain
>

Okay.

>
> > doesn't seem to provide packages corresponding to OE glibc locale recipe.
>
> Actually, the toolchain itself does provide all the gconv libs, AFAICS,
> it's just they are not packaged by the recipe.

Yes, I saw those libraries provided by toolchain iself. But I am a
little skeptical about whether we would be able to generate dynamic
glibc locale data package using pre-built toolchain.

> When I hit it back in April,
> I just didn't have time and ended up with LIBC_DEPENDENCIES_remove hack as
> a temporary workaround, planning to enevtually go back and fix it properly:
> http://arago-project.org/git/?p=meta-arago.git;a=blobdiff;f=meta-arago-distro/conf/distro/arago.conf;hb=84c30ee97056589ba0811428527f4adf8268c9b2;hpb=3a4ed9d1e8a118aefb2ef49ce450f74f14e239d0
>

I do look forward to your patch adding support for glibc locale
packages but until then we shouldn't block usage of SDKs.

> So, re-using this LIBC_DEPENDENCIES_remove here in upstream meta-arm isn't
> correct...
>

I think it's a separate feature rather than a gating item to use SDKs.
So it's better to advertise properly what is currently being supported
by pre-built toolchain rather than failing due to missing features.

We can definitely get rid of this once we sort out proper packaging
for glibc locale using pre-built toolchain.

>
> > So explicitly remove corresponding libc dependencies.
> >
> > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > ---
> >  meta-arm-toolchain/conf/distro/include/tcmode-external-arm.inc | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/meta-arm-toolchain/conf/distro/include/tcmode-external-arm.inc b/meta-arm-toolchain/conf/distro/include/tcmode-external-arm.inc
> > index 9171380..eee1a51 100644
> > --- a/meta-arm-toolchain/conf/distro/include/tcmode-external-arm.inc
> > +++ b/meta-arm-toolchain/conf/distro/include/tcmode-external-arm.inc
> > @@ -58,6 +58,7 @@ DISTRO_FEATURES_LIBC = "ipv4 ipv6 libc-backtrace libc-big-macros libc-bsd libc-c
> >  ENABLE_BINARY_LOCALE_GENERATION = "0"
> >  GLIBC_INTERNAL_USE_BINARY_LOCALE = "precompiled"
> >  LIBCOVERRIDE = ":libc-glibc"
> > +LIBC_DEPENDENCIES_remove = "glibc-gconv-cp1252 glibc-gconv-ibm850 glibc-gconv-iso8859-1 glibc-gconv-iso8859-15 glibc-localedata-i18n"
>
> You shouldn't be using _remove in meta-arm, as it's not the final layer and
> there won't be any way to override this in BSPs or Distros.
>

Do you have any other alternative way to achieve similar functionality
as this comes from tclibc-glibc.inc?

-Sumit

>
> >  ERROR_QA[type] ?= "list"
> >  python toolchain_metadata_setup () {
> > --
> > 2.7.4
> >

Re: [PATCH 3/4] external-arm-toolchain: Add README

[Sumit Garg]

On Fri, 5 Jun 2020 at 00:17, Denys Dmytriyenko <denis@denix.org> wrote:
>
> On Tue, Jun 02, 2020 at 04:34:53PM +0530, Sumit Garg wrote:
> > Document usage details for pre-built Arm toolchains.
> >
> > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > ---
> >  .../external-arm-toolchain/README.md               | 50 ++++++++++++++++++++++
> >  1 file changed, 50 insertions(+)
> >  create mode 100644 meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md
> >
> > diff --git a/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md
> > new file mode 100644
> > index 0000000..65d1a42
> > --- /dev/null
> > +++ b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md
> > @@ -0,0 +1,50 @@
> > +Pre-built Arm toolchain recipes
> > +===============================
> > +
> > +Introduction
> > +------------
> > +This layer contains recipes for pre-built Arm toolchain recipes as follows:
> > +
> > +external-arm-toolchain.bb
> > +~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +This recipe provides support for pre-built GNU toolchains targeting processors
> > +from the Arm Cortex-A family and implementing the Arm A-profile architecture.
> > +
> > +Usage
> > +^^^^^
> > +
> > +In order to use any of pre-built Arm toolchain versions (8.2, 8.3, 9.2 and so
> > +on), a user needs to download and untar tool-set on host machine at a particular
> > +installation path eg: ``/opt/toolchain/``. Then user needs to specify following
> > +in ``conf/local.conf`` in order to replace OE toolcahin with pre-built GNU-A
> > +toolchain:
> > +
> > +TCMODE = "external-arm"
> > +EXTERNAL_TOOLCHAIN = "<path-to-the-toolchain>"
> > +
> > +-  Eg. for AArch64 (eg. qemuarm64 machine in poky distro)
> > +   EXTERNAL_TOOLCHAIN = "\
> > +     <installation-path>/gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu \
> > +   "
> > +
> > +-  Eg. for AArch32 (eg. qemuarm machine in poky distro)
> > +   EXTERNAL_TOOLCHAIN = "\
> > +     <installation-path>/gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf \
> > +   "
> > +
> > +Supported distros and machines
> > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +Since this pre-built GNU-A tool-set simply replaces OE toolchain, so it is
> > +meant to be distro and machine agnostic as long as one is cross-compiling for
> > +Arm A-profile architecture.
> > +
> > +gcc-arm-none-eabi_<version>.bb
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> gcc-aarch64-none-elf?
>

Sure will update for gcc-aarch64-none-elf as well.

> Probably need to explain a bit more regarding the differences between
> baremetal and Linux toolchains, as currently it can be confusing to some
> why there are 2 sets of toolchain recipes...
>

Isn't baremetal development and Linux development self explanatory?

What additional differences are you looking for?

-Sumit

>
> > +This recipe provides support for pre-built GNU Arm Embedded toolchain for
> > +bare-metal software development on devices based on 32-bit Arm Cortex-A,
> > +Cortex-R and Cortex-M processors.
> > +
> > +Supported version: 9-2019-q4-major
> > --
> > 2.7.4
> >

Re: [meta-arm] [PATCH 0/4] external-arm-toolchain: Add support for SDK generation

[Denys Dmytriyenko]

On Fri, Jun 05, 2020 at 06:59:17PM +0530, Sumit Garg wrote:
> On Fri, 5 Jun 2020 at 11:54, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > On Thu, 2020-06-04 at 19:10 -0400, Denys Dmytriyenko wrote:
> > > On Thu, Jun 04, 2020 at 07:00:14PM -0400, Denys Dmytriyenko wrote:
> > > > On Tue, Jun 02, 2020 at 04:34:50PM +0530, Sumit Garg wrote:
> > > > > Patch #1 and #2 adds impprovements in external-arm-toolchain
> > > > > recipe in order to
> > > > > support SDK generation. SDK generation has been tested using:
> > > > >
> > > > > $ bitbake core-image-base -c populate_sdk
> > > >
> > > > This just ensures that external-arm-toolchain doesn't get in the
> > > > way of SDK
> > > > generation by avoiding any conflicts. The only re-use here is
> > > > glibc. The rest
> > > > of pre-built Arm toolchain gets thrown out and rebuilt from sources
> > > > - gcc,
> > > > binutils, gdb/gdbserver are all built from sources as TCMODE was
> > > > not set and
> > > > falls back to "default". Sure, pre-built Arm toolchain doesn't
> > > > provide all
> > > > possible SDKMACHINE binaries, but for 90% cases of x86_64, there's
> > > > very little
> > > > re-use...
> > >
> > > And I wonder is the resulting SDK was even tested:
> > >
> > > $ . environment-setup-armv7at2hf-neon-oe-linux-gnueabi
> > >
> > > $ arm-none-linux-gnueabihf-gcc -o hello hello.c
> > > hello.c:1:10: fatal error: stdio.h: No such file or directory
> > >     1 | #include <stdio.h>
> > >       |          ^~~~~~~~~
> > > compilation terminated.
> > >
> > > $ arm-none-linux-gnueabihf-g++ -o hello++ hello.cpp
> > > hello.cpp:1:10: fatal error: iostream: No such file or directory
> > >     1 | #include <iostream>
> > >       |          ^~~~~~~~~~
> > > compilation terminated.
> 
> I guess you missed the basics to use the installed SDK as you haven't
> provided a proper sysroot path. See expansion of "$CC" below:
> 
> $ . environment-setup-aarch64-poky-linux
> $ echo $CC
> aarch64-none-linux-gnu-gcc -march=armv8-a+crc
> --sysroot=/home/sumit.garg/temp/oe_sdk/sysroots/aarch64-poky-linux

Sorry, it was too late here and I sent the wrong logs... Yes, I'm aware of 
using $CC and $CXX instead of calling binaries directly.

The correct logs I wanted to send are there:

$ $CC -o hello hello.c
/tmp/armsdk/sysroots/x86_64-oesdk-linux/usr/libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/9.2.1/real-ld: cannot find crtbegin.o: No such file or directory
/tmp/armsdk/sysroots/x86_64-oesdk-linux/usr/libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/9.2.1/real-ld: cannot find -lgcc
/tmp/armsdk/sysroots/x86_64-oesdk-linux/usr/libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/9.2.1/real-ld: cannot find -lgcc
collect2: error: ld returned 1 exit status

$ $CXX -o hello++ hello.cpp 
In file included from hello.cpp:1:
/tmp/armsdk/sysroots/armv7at2hf-neon-oe-linux-gnueabi/usr/include/c++/9.2.1/iostream:38:10: fatal error: bits/c++config.h: No such file or directory
   38 | #include <bits/c++config.h>
      |          ^~~~~~~~~~~~~~~~~~
compilation terminated.


The first one you can recognize is due to missing libgcc.a, which should be 
fixed by my patch.

And I know the reason for the second one two - I've been fixing these for 
years. I need to send the fixes...


> > If you've done "bitbake core-image-base -c populate_sdk" to build it,
> > you can do "bitbake core-image-base -c testsdk" to test it as we have
> > basic automated QA tests for that.
> 
> Thanks for this pointer. There are test cases which are failing, will fix them.
> 
> -Sumit
> 
> >
> > Cheers,
> >
> > Richard
> >
> >
> >
> >
> >
> >
> 

Re: [PATCH 0/4] external-arm-toolchain: Add support for SDK generation

[Sumit Garg]

On Fri, 5 Jun 2020 at 04:30, Denys Dmytriyenko <denis@denix.org> wrote:
>
> On Tue, Jun 02, 2020 at 04:34:50PM +0530, Sumit Garg wrote:
> > Patch #1 and #2 adds impprovements in external-arm-toolchain recipe in order to
> > support SDK generation. SDK generation has been tested using:
> >
> > $ bitbake core-image-base -c populate_sdk
>
> This just ensures that external-arm-toolchain doesn't get in the way of SDK
> generation by avoiding any conflicts. The only re-use here is glibc. The rest
> of pre-built Arm toolchain gets thrown out and rebuilt from sources - gcc,
> binutils, gdb/gdbserver are all built from sources as TCMODE was not set and
> falls back to "default".

Yes I noticed this as well. I guess we can improve this situation to
package tools from pre-built toolchain only rather than building from
source. Will explore options.

> Sure, pre-built Arm toolchain doesn't provide all
> possible SDKMACHINE binaries, but for 90% cases of x86_64, there's very little
> re-use...

Yes, but don't you think that having a common build environment using
SDKs is still useful from the end user's perspective irrespective of
underlying toolchain (built from source or pre-built)?

-Sumit

>
>
> > Patch #3 adds a README to describe usage details of pre-built Arm tool-set.
> >
> > Patch #4 adds package specific licences for external-arm-toolchain recipe.
> >
> > Sumit Garg (4):
> >   external-arm-toolchain: Remove glibc locale dependency
> >   external-arm-toolchain: Refine dev libraies packaging
> >   external-arm-toolchain: Add README
> >   external-arm-toolchain: Add package specific licenses
> >
> >  .../conf/distro/include/tcmode-external-arm.inc    |  1 +
> >  .../external-arm-toolchain/README.md               | 50 ++++++++++++++
> >  .../external-arm-toolchain.bb                      | 29 ++++++++-
> >  .../external-arm-toolchain/license.inc             | 76 ++++++++++++++++++++++
> >  4 files changed, 154 insertions(+), 2 deletions(-)
> >  create mode 100644 meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md
> >  create mode 100644 meta-arm-toolchain/recipes-devtools/external-arm-toolchain/license.inc
> >
> > --
> > 2.7.4
> >

Re: [meta-arm] [PATCH 0/4] external-arm-toolchain: Add support for SDK generation

[Sumit Garg]

On Sat, 6 Jun 2020 at 00:10, Denys Dmytriyenko <denis@denix.org> wrote:
>
> On Fri, Jun 05, 2020 at 06:59:17PM +0530, Sumit Garg wrote:
> > On Fri, 5 Jun 2020 at 11:54, Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> > >
> > > On Thu, 2020-06-04 at 19:10 -0400, Denys Dmytriyenko wrote:
> > > > On Thu, Jun 04, 2020 at 07:00:14PM -0400, Denys Dmytriyenko wrote:
> > > > > On Tue, Jun 02, 2020 at 04:34:50PM +0530, Sumit Garg wrote:
> > > > > > Patch #1 and #2 adds impprovements in external-arm-toolchain
> > > > > > recipe in order to
> > > > > > support SDK generation. SDK generation has been tested using:
> > > > > >
> > > > > > $ bitbake core-image-base -c populate_sdk
> > > > >
> > > > > This just ensures that external-arm-toolchain doesn't get in the
> > > > > way of SDK
> > > > > generation by avoiding any conflicts. The only re-use here is
> > > > > glibc. The rest
> > > > > of pre-built Arm toolchain gets thrown out and rebuilt from sources
> > > > > - gcc,
> > > > > binutils, gdb/gdbserver are all built from sources as TCMODE was
> > > > > not set and
> > > > > falls back to "default". Sure, pre-built Arm toolchain doesn't
> > > > > provide all
> > > > > possible SDKMACHINE binaries, but for 90% cases of x86_64, there's
> > > > > very little
> > > > > re-use...
> > > >
> > > > And I wonder is the resulting SDK was even tested:
> > > >
> > > > $ . environment-setup-armv7at2hf-neon-oe-linux-gnueabi
> > > >
> > > > $ arm-none-linux-gnueabihf-gcc -o hello hello.c
> > > > hello.c:1:10: fatal error: stdio.h: No such file or directory
> > > >     1 | #include <stdio.h>
> > > >       |          ^~~~~~~~~
> > > > compilation terminated.
> > > >
> > > > $ arm-none-linux-gnueabihf-g++ -o hello++ hello.cpp
> > > > hello.cpp:1:10: fatal error: iostream: No such file or directory
> > > >     1 | #include <iostream>
> > > >       |          ^~~~~~~~~~
> > > > compilation terminated.
> >
> > I guess you missed the basics to use the installed SDK as you haven't
> > provided a proper sysroot path. See expansion of "$CC" below:
> >
> > $ . environment-setup-aarch64-poky-linux
> > $ echo $CC
> > aarch64-none-linux-gnu-gcc -march=armv8-a+crc
> > --sysroot=/home/sumit.garg/temp/oe_sdk/sysroots/aarch64-poky-linux
>
> Sorry, it was too late here and I sent the wrong logs...

No worries.

> Yes, I'm aware of
> using $CC and $CXX instead of calling binaries directly.
>
> The correct logs I wanted to send are there:
>
> $ $CC -o hello hello.c
> /tmp/armsdk/sysroots/x86_64-oesdk-linux/usr/libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/9.2.1/real-ld: cannot find crtbegin.o: No such file or directory
> /tmp/armsdk/sysroots/x86_64-oesdk-linux/usr/libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/9.2.1/real-ld: cannot find -lgcc
> /tmp/armsdk/sysroots/x86_64-oesdk-linux/usr/libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/9.2.1/real-ld: cannot find -lgcc
> collect2: error: ld returned 1 exit status
>
> $ $CXX -o hello++ hello.cpp
> In file included from hello.cpp:1:
> /tmp/armsdk/sysroots/armv7at2hf-neon-oe-linux-gnueabi/usr/include/c++/9.2.1/iostream:38:10: fatal error: bits/c++config.h: No such file or directory
>    38 | #include <bits/c++config.h>
>       |          ^~~~~~~~~~~~~~~~~~
> compilation terminated.
>

These are the same errors that I noticed with testsdk as well. So I
think testsdk should be a good enough sanity testing tool to say SDK
is generated properly.

>
> The first one you can recognize is due to missing libgcc.a, which should be
> fixed by my patch.

Yeah.

>
> And I know the reason for the second one two - I've been fixing these for
> years. I need to send the fixes...
>

Okay, let me wait for your fixes in order to avoid duplicate work. In
the meantime, will explore pre-built tools packaging from external
toolchain.

-Sumit

>
> > > If you've done "bitbake core-image-base -c populate_sdk" to build it,
> > > you can do "bitbake core-image-base -c testsdk" to test it as we have
> > > basic automated QA tests for that.
> >
> > Thanks for this pointer. There are test cases which are failing, will fix them.
> >
> > -Sumit
> >
> > >
> > > Cheers,
> > >
> > > Richard
> > >
> > >
> > >
> > >
> > >
> > >
> >

Re: [PATCH 2/4] external-arm-toolchain: Refine dev libraies packaging

[Paul Barker]

On Fri, 5 Jun 2020 at 14:52, Sumit Garg <sumit.garg@linaro.org> wrote:
>
> On Fri, 5 Jun 2020 at 00:12, Denys Dmytriyenko <denis@denix.org> wrote:
> >
> > On Tue, Jun 02, 2020 at 04:34:52PM +0530, Sumit Garg wrote:
> > > OE core by default package all libraies installed as "${libdir}/lib*.so"
> > > or "${libdir}/*.la" as part of "FILES_${PN}-dev" but in case of external
> > > Arm tool-set recipe, multiple packages are provided which needs to
> > > include specific libraries. So split dev libraries packaging accordingly
> > > and only package remaining libraries as part of "FILES_${PN}-dev" which
> > > aren't provided as part of other packages.
> > >
> > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > ---
> > >  .../external-arm-toolchain.bb                      | 23 ++++++++++++++++++++++
> > >  1 file changed, 23 insertions(+)
> > >
> > > diff --git a/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
> > > index 04d8923..7f5a6f5 100644
> > > --- a/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
> > > +++ b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
> > > @@ -545,6 +545,29 @@ FILES_${PN} += "\
> > >       ${base_libdir}/libpcprofile.so \
> > >      "
> > >
> > > +FILES_${PN}-dev_remove = "\
> >
> > Shouldn't be using _remove here. It will probably break anyones .bbappends on
> > this recipe and will make it hard making any adjustments.
> >
>
> Any specific reason to use .bbappends? Why can't those changes land in
> meta-arm instead?
>
> > If you check git logs, you'll see that every time we needed to change the
> > default lists defined by glibc-package.inc in OE-Core, we had to re-create
> > them from scratch.
> >
>
> Sounds reasonable, will create FILES_${PN}-dev from scratch instead.

Denys has made some good comments, I don't have much to add. I did
spot a typo in the subject though, "libraies" should be "libraries".

-- 
Paul Barker
Konsulko Group

Re: [PATCH 3/4] external-arm-toolchain: Add README

[Paul Barker]

On Tue, 2 Jun 2020 at 12:05, Sumit Garg <sumit.garg@linaro.org> wrote:
>
> Document usage details for pre-built Arm toolchains.
>
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>  .../external-arm-toolchain/README.md               | 50 ++++++++++++++++++++++
>  1 file changed, 50 insertions(+)
>  create mode 100644 meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md
>
> diff --git a/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md
> new file mode 100644
> index 0000000..65d1a42
> --- /dev/null
> +++ b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md
> @@ -0,0 +1,50 @@
> +Pre-built Arm toolchain recipes
> +===============================

I'd recommend saying explicitly in this readme file that info on
contributing, reporting bugs, etc can be found in the top-level
meta-arm readme file.

> +
> +Introduction
> +------------
> +This layer contains recipes for pre-built Arm toolchain recipes as follows:
> +
> +external-arm-toolchain.bb
> +~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +This recipe provides support for pre-built GNU toolchains targeting processors
> +from the Arm Cortex-A family and implementing the Arm A-profile architecture.
> +
> +Usage
> +^^^^^
> +
> +In order to use any of pre-built Arm toolchain versions (8.2, 8.3, 9.2 and so
> +on), a user needs to download and untar tool-set on host machine at a particular
> +installation path eg: ``/opt/toolchain/``. Then user needs to specify following
> +in ``conf/local.conf`` in order to replace OE toolcahin with pre-built GNU-A

Typo: "toolcahin" should be "toolchain".

> +toolchain:
> +
> +TCMODE = "external-arm"
> +EXTERNAL_TOOLCHAIN = "<path-to-the-toolchain>"
> +
> +-  Eg. for AArch64 (eg. qemuarm64 machine in poky distro)
> +   EXTERNAL_TOOLCHAIN = "\
> +     <installation-path>/gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu \
> +   "
> +
> +-  Eg. for AArch32 (eg. qemuarm machine in poky distro)
> +   EXTERNAL_TOOLCHAIN = "\
> +     <installation-path>/gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf \
> +   "
> +
> +Supported distros and machines
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +Since this pre-built GNU-A tool-set simply replaces OE toolchain, so it is
> +meant to be distro and machine agnostic as long as one is cross-compiling for
> +Arm A-profile architecture.

This section should cover what is actually tested. For example, let's
say I have a custom distro & machine and I see some weird behaviour
from the ARM toolchain. I'd like to know which distro & machine
combination is known to be good so that I can see if it reproduces the
same errors. That would allow me to determine if the error is in
meta-arm-toolchain or if it is my own layers.

> +
> +gcc-arm-none-eabi_<version>.bb
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +This recipe provides support for pre-built GNU Arm Embedded toolchain for
> +bare-metal software development on devices based on 32-bit Arm Cortex-A,
> +Cortex-R and Cortex-M processors.
> +
> +Supported version: 9-2019-q4-major
> --
> 2.7.4
>


-- 
Paul Barker
Konsulko Group

Re: [PATCH 4/4] external-arm-toolchain: Add package specific licenses

[Paul Barker]

On Tue, 2 Jun 2020 at 12:05, Sumit Garg <sumit.garg@linaro.org> wrote:
>
> Add license.inc file to state license of various packages provided by
> pre-built Arm tool-set.
>
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>  .../external-arm-toolchain.bb                      |  6 +-
>  .../external-arm-toolchain/license.inc             | 76 ++++++++++++++++++++++
>  2 files changed, 80 insertions(+), 2 deletions(-)
>  create mode 100644 meta-arm-toolchain/recipes-devtools/external-arm-toolchain/license.inc
>
> diff --git a/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
> index 7f5a6f5..6bceed0 100644
> --- a/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
> +++ b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb
> @@ -1,9 +1,11 @@
> +# This recipe is distributed under MIT license.
> +

This shouldn't be needed, see other recipes in the meta-arm layer.

>  require recipes-core/glibc/glibc-package.inc
>
> +require license.inc
> +
>  INHIBIT_DEFAULT_DEPS = "1"
>
> -# License applies to this recipe code, not the toolchain itself
> -LICENSE = "MIT"
>  LIC_FILES_CHKSUM = "\
>         file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302 \
>         file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420 \
> diff --git a/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/license.inc b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/license.inc
> new file mode 100644
> index 0000000..b6ee42c
> --- /dev/null
> +++ b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/license.inc
> @@ -0,0 +1,76 @@
> +LICENSE = "GPL-3.0-with-GCC-exception & GPLv3 & GPLv2 & LGPLv3 & LGPLv2.1 & LGPLv2"
> +
> +EAT_GCC_LICENSE = "GPL-3.0-with-GCC-exception & GPLv3"
> +EAT_LIBC_LICENSE = "GPLv2 & LGPLv2.1"
> +
> +LICENSE_${PN} = "${EAT_LIBC_LICENSE}"
> +LICENSE_${PN}-dev = "${EAT_LIBC_LICENSE}"
> +LICENSE_${PN}-doc = "${EAT_LIBC_LICENSE}"
> +LICENSE_${PN}-dbg = "${EAT_LIBC_LICENSE}"
> +LICENSE_${PN}-pic = "${EAT_LIBC_LICENSE}"
> +LICENSE_${PN}-utils = "${EAT_LIBC_LICENSE}"
> +LICENSE_${PN}-mtrace = "${EAT_LIBC_LICENSE}"
> +LICENSE_${PN}-gconv = "${EAT_LIBC_LICENSE}"
> +LICENSE_${PN}-extra-nss = "${EAT_LIBC_LICENSE}"
> +LICENSE_${PN}-thread-db = "${EAT_LIBC_LICENSE}"
> +LICENSE_${PN}-pcprofile = "${EAT_LIBC_LICENSE}"
> +LICENSE_${PN}-staticdev = "${EAT_LIBC_LICENSE}"
> +LICENSE_catchsegv = "${EAT_LIBC_LICENSE}"
> +LICENSE_glibc-extra-nss = "${EAT_LIBC_LICENSE}"
> +LICENSE_glibc-thread-db = "${EAT_LIBC_LICENSE}"
> +
> +LICENSE_libmemusage = "${EAT_LIBC_LICENSE}"
> +LICENSE_libsegfault = "${EAT_LIBC_LICENSE}"
> +LICENSE_libsotruss = "${EAT_LIBC_LICENSE}"
> +LICENSE_sln = "${EAT_LIBC_LICENSE}"
> +LICENSE_nscd = "${EAT_LIBC_LICENSE}"
> +LICENSE_ldd = "${EAT_LIBC_LICENSE}"
> +
> +LICENSE_libasan-dev = "${EAT_GCC_LICENSE}"
> +LICENSE_libasan = "${EAT_GCC_LICENSE}"
> +LICENSE_libasan-staticdev = "${EAT_GCC_LICENSE}"
> +LICENSE_libatomic-dev = "${EAT_GCC_LICENSE}"
> +LICENSE_libatomic = "${EAT_GCC_LICENSE}"
> +LICENSE_libatomic-staticdev = "${EAT_GCC_LICENSE}"
> +LICENSE_libg2c-dev = "${EAT_GCC_LICENSE}"
> +LICENSE_libg2c = "${EAT_GCC_LICENSE}"
> +LICENSE_libgcc-dev = "${EAT_GCC_LICENSE}"
> +LICENSE_libgcc = "${EAT_GCC_LICENSE}"
> +LICENSE_libgfortran-dbg = "${EAT_GCC_LICENSE}"
> +LICENSE_libgfortran-dev = "${EAT_GCC_LICENSE}"
> +LICENSE_libgfortran = "${EAT_GCC_LICENSE}"
> +LICENSE_libgfortran-staticdev = "${EAT_GCC_LICENSE}"
> +LICENSE_libgomp-dev = "${EAT_GCC_LICENSE}"
> +LICENSE_libgomp = "${EAT_GCC_LICENSE}"
> +LICENSE_libgomp-staticdev = "${EAT_GCC_LICENSE}"
> +LICENSE_libitm-dev = "${EAT_GCC_LICENSE}"
> +LICENSE_libitm = "${EAT_GCC_LICENSE}"
> +LICENSE_libitm-staticdev = "${EAT_GCC_LICENSE}"
> +LICENSE_liblsan-dev = "${EAT_GCC_LICENSE}"
> +LICENSE_liblsan = "${EAT_GCC_LICENSE}"
> +LICENSE_liblsan-staticdev = "${EAT_GCC_LICENSE}"
> +LICENSE_libmudflap-dev = "${EAT_GCC_LICENSE}"
> +LICENSE_libmudflap = "${EAT_GCC_LICENSE}"
> +LICENSE_libmudflap-staticdev = "${EAT_GCC_LICENSE}"
> +LICENSE_libquadmath-dev = "${EAT_GCC_LICENSE}"
> +LICENSE_libquadmath = "${EAT_GCC_LICENSE}"
> +LICENSE_libquadmath-staticdev = "${EAT_GCC_LICENSE}"
> +LICENSE_libssp-dev = "${EAT_GCC_LICENSE}"
> +LICENSE_libssp = "${EAT_GCC_LICENSE}"
> +LICENSE_libssp-staticdev = "${EAT_GCC_LICENSE}"
> +LICENSE_libstdc++-dbg = "${EAT_GCC_LICENSE}"
> +LICENSE_libstdc++-dev = "${EAT_GCC_LICENSE}"
> +LICENSE_libstdc++ = "${EAT_GCC_LICENSE}"
> +LICENSE_libstdc++-precompile-dev = "${EAT_GCC_LICENSE}"
> +LICENSE_libstdc++-staticdev = "${EAT_GCC_LICENSE}"
> +LICENSE_libtsan-dev = "${EAT_GCC_LICENSE}"
> +LICENSE_libtsan = "${EAT_GCC_LICENSE}"
> +LICENSE_libtsan-staticdev = "${EAT_GCC_LICENSE}"
> +LICENSE_libubsan-dev = "${EAT_GCC_LICENSE}"
> +LICENSE_libubsan = "${EAT_GCC_LICENSE}"
> +LICENSE_libubsan-staticdev = "${EAT_GCC_LICENSE}"
> +
> +LICENSE_linux-libc-headers-dev = "GPLv2"
> +LICENSE_linux-libc-headers = "GPLv2"
> +
> +LICENSE_gdbserver = "GPLv2 & GPLv3 & LGPLv2 & LGPLv3"
> --
> 2.7.4
>


-- 
Paul Barker
Konsulko Group

Re: [PATCH 3/4] external-arm-toolchain: Add README

[Sumit Garg]

On Mon, 8 Jun 2020 at 17:38, Paul Barker <pbarker@konsulko.com> wrote:
>
> On Tue, 2 Jun 2020 at 12:05, Sumit Garg <sumit.garg@linaro.org> wrote:
> >
> > Document usage details for pre-built Arm toolchains.
> >
> > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > ---
> >  .../external-arm-toolchain/README.md               | 50 ++++++++++++++++++++++
> >  1 file changed, 50 insertions(+)
> >  create mode 100644 meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md
> >
> > diff --git a/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md
> > new file mode 100644
> > index 0000000..65d1a42
> > --- /dev/null
> > +++ b/meta-arm-toolchain/recipes-devtools/external-arm-toolchain/README.md
> > @@ -0,0 +1,50 @@
> > +Pre-built Arm toolchain recipes
> > +===============================
>
> I'd recommend saying explicitly in this readme file that info on
> contributing, reporting bugs, etc can be found in the top-level
> meta-arm readme file.
>

Okay.

> > +
> > +Introduction
> > +------------
> > +This layer contains recipes for pre-built Arm toolchain recipes as follows:
> > +
> > +external-arm-toolchain.bb
> > +~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +This recipe provides support for pre-built GNU toolchains targeting processors
> > +from the Arm Cortex-A family and implementing the Arm A-profile architecture.
> > +
> > +Usage
> > +^^^^^
> > +
> > +In order to use any of pre-built Arm toolchain versions (8.2, 8.3, 9.2 and so
> > +on), a user needs to download and untar tool-set on host machine at a particular
> > +installation path eg: ``/opt/toolchain/``. Then user needs to specify following
> > +in ``conf/local.conf`` in order to replace OE toolcahin with pre-built GNU-A
>
> Typo: "toolcahin" should be "toolchain".
>
> > +toolchain:
> > +
> > +TCMODE = "external-arm"
> > +EXTERNAL_TOOLCHAIN = "<path-to-the-toolchain>"
> > +
> > +-  Eg. for AArch64 (eg. qemuarm64 machine in poky distro)
> > +   EXTERNAL_TOOLCHAIN = "\
> > +     <installation-path>/gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu \
> > +   "
> > +
> > +-  Eg. for AArch32 (eg. qemuarm machine in poky distro)
> > +   EXTERNAL_TOOLCHAIN = "\
> > +     <installation-path>/gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf \
> > +   "
> > +
> > +Supported distros and machines
> > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +Since this pre-built GNU-A tool-set simply replaces OE toolchain, so it is
> > +meant to be distro and machine agnostic as long as one is cross-compiling for
> > +Arm A-profile architecture.
>
> This section should cover what is actually tested. For example, let's
> say I have a custom distro & machine and I see some weird behaviour
> from the ARM toolchain. I'd like to know which distro & machine
> combination is known to be good so that I can see if it reproduces the
> same errors. That would allow me to determine if the error is in
> meta-arm-toolchain or if it is my own layers.

How about the following add-on?

Tested distro and machines (for zeus stable release):
1. Distro: poky; machines: qemuarm and qemuarm64 (build and boot tested)
2. Distro: RPB; machines: dragonboard-410c (build and boot tested)
3. Distro: world; machines: qemuarm and qemuarm64. Build tested for
following layers:
    - poky/meta
    - poky/meta-poky
    - poky/meta-yocto-bsp
    - meta-openembedded/meta-oe
    - meta-openembedded/meta-python
    - meta-openembedded/meta-networking

-Sumit

>
> > +
> > +gcc-arm-none-eabi_<version>.bb
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +This recipe provides support for pre-built GNU Arm Embedded toolchain for
> > +bare-metal software development on devices based on 32-bit Arm Cortex-A,
> > +Cortex-R and Cortex-M processors.
> > +
> > +Supported version: 9-2019-q4-major
> > --
> > 2.7.4
> >
>
>
> --
> Paul Barker
> Konsulko Group

Re: [meta-arm] [PATCH 0/4] external-arm-toolchain: Add support for SDK generation

[Denys Dmytriyenko]

On Mon, Jun 08, 2020 at 04:56:54PM +0530, Sumit Garg wrote:
> On Fri, 5 Jun 2020 at 04:30, Denys Dmytriyenko <denis@denix.org> wrote:
> >
> > On Tue, Jun 02, 2020 at 04:34:50PM +0530, Sumit Garg wrote:
> > > Patch #1 and #2 adds impprovements in external-arm-toolchain recipe in order to
> > > support SDK generation. SDK generation has been tested using:
> > >
> > > $ bitbake core-image-base -c populate_sdk
> >
> > This just ensures that external-arm-toolchain doesn't get in the way of SDK
> > generation by avoiding any conflicts. The only re-use here is glibc. The rest
> > of pre-built Arm toolchain gets thrown out and rebuilt from sources - gcc,
> > binutils, gdb/gdbserver are all built from sources as TCMODE was not set and
> > falls back to "default".
> 
> Yes I noticed this as well. I guess we can improve this situation to
> package tools from pre-built toolchain only rather than building from
> source. Will explore options.
> 
> > Sure, pre-built Arm toolchain doesn't provide all
> > possible SDKMACHINE binaries, but for 90% cases of x86_64, there's very little
> > re-use...
> 
> Yes, but don't you think that having a common build environment using
> SDKs is still useful from the end user's perspective irrespective of
> underlying toolchain (built from source or pre-built)?

Just wanted to get back to this point.

Yes, in general that would be preferred (and exactly why OE insists on 
building everything, starting with the toolchain, compared to competitors 
that use prebuilt toolchains by default, like buildroot, etc).

But as you have seen from the discussion in the other thread, there are 
some legitimate (hopefully) reasons to re-use prebuilt binaries even for 
SDK - licensing, distribution and such...

Back in the day it was simpler - 32-bit x86 was dominant and what prebuilt 
toolchain supported as a host and being the default/only SDKMACHINE.

For some time Linaro toolchain supported both 32-bit and 64-bit x86 as a
host, so it was possible to support both of those SDKMACHINEs. These days 
32-bit x86 faded into obscurity. But on the other hand, aarch64 hosts are 
gaining traction, so targeting aarch64 SDKMACHINE from x86 host will be a 
problem with external-arm-toolchain w/o full rebuild of SDK toolchain...

So, hopefully this can be done optionally/conditionally to either re-use 
prebuilt binaries from external toolchain or build them from sources.

-- 
Denys