Hi Everyone,
We are pleased to announce that support for ARM GCC 9.2-2019.12 [1]
toolchain has been added in meta-linaro [2].
- Support for ARM GCC 9.2 toolchain built from source, steps to use it:
- Add <path-to-meta-linaro-repo>/meta-linaro-toolchain/ to BBLAYERS
in conf/bblayers.conf.
- Configure: GCCVERSION = "arm-9.2" in conf/local.conf.
- Support for prebuilt ARM GCC 9.2 toolchain, steps to use it:
- Add <path-to-meta-linaro-repo>/meta-linaro-toolchain/ to BBLAYERS
in conf/bblayers.conf.
- Configure: TCMODE = "external-arm" in conf/local.conf.
- For AArch64 (eg. qemuarm64 machine in poky distro)
- Configure: EXTERNAL_TOOLCHAIN =
"<installation-path>/gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu"
in
conf/local.conf.
- For AArch32 (eg. qemuarm machine in poky distro)
- Configure: EXTERNAL_TOOLCHAIN =
"<installation-path>/gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf"
in conf/local.conf.
Distro testing:
===========
- poky distro (branch: zeus, machines: qemuarm and qemuarm64)
- Build and boot tested.
- RPB distro (branch: zeus, machine: dragonboard-410c)
- Build and boot tested.
- World builds (branch: zeus, machines: qemuarm and qemuarm64) for
following layers:
- poky/meta
- poky/meta-poky
- poky/meta-yocto-bsp
- meta-openembedded/meta-oe
- meta-openembedded/meta-python
- meta-openembedded/meta-networking
Known issues:
===========
- mariadb build failure with ARM GCC 9.2 toolchain built from source:
- Recipe fix patch [3] accepted in OE upstream.
- Native tools dependency issues seen with multiple recipes (psmisc,
xclock, ndisc6, dovecot, man-db, drbd-utils and unbound) when using
prebuilt ARM GCC 9.2 toolchain.
- Fixes posted in OE upstream [4] [5].
Reporting bugs:
============
Please report any issue here [6].
[1]
https://developer.arm.com/tools-and-software/open-source-software/developer…
[2] https://git.linaro.org/openembedded/meta-linaro.git/?h=master
[3] https://patchwork.openembedded.org/patch/169296/
[4] https://patchwork.openembedded.org/patch/169289/
[5] https://patchwork.openembedded.org/series/22188/
[6] https://bugs.linaro.org/enter_bug.cgi?product=Linaro%20OpenEmbedded
Happy hacking!,
Regards,
Sumit
hi,
we are hitting some errors with repo init since last night. After
looking into it , I came up with the following explanation and fix..
If I am correct, it will impact all our OE RPB build setup..
Can you please review that carefully?
The PR is on github:
https://github.com/96boards/oe-rpb-manifest/pull/121
I put a copy of the commit message below to bring it to your attention!
cheers
nico
==
All along we have been using a relative symlink for setup-environment
which points outside of the project path. While we've enjoyed this
hack for several years, a recent change was in repo, and repo init now
fails with:
error.ManifestInvalidPathError: <linkfile> invalid "src":
../../.repo/manifests/setup-environment: bad component: .repo
The change in repo is this one:
https://gerrit.googlesource.com/git-repo/+/07392ed32662006c029299bc06617310…
The repo documentation states: The symlink is created at “dest”
(relative to the top of the tree) and points to the path specified by
“src” which is a path in the project.
As such, repo clearly expects that 'src' is in the project path, which
is not the cause when using ../../.repo/ path.
This patch changes our folder structure in such a way that:
* the manifest git is checked out as ./conf/ folder in the top level
directory
* setup-environment link is created by repo, as a link to
conf/setup-environment-internal
The main drawback is that it feels non standard to duplicate the whole
manifest project again (since it's already checked out in .repo)
however using .repo content also meant we were making assumptions on
implementation details of repo itself.
Signed-off-by: Nicolas Dechesne <nicolas.dechesne(a)linaro.org>
Hi,
I changed the RPB qcom-lt builds to use docker-buster-amd64 because we have
been experimenting image corruption with ext2simg tool in new RPB zeus
builds [1], there is a related bug report [1] and that's the reason why our
Debian builds uses img2simg.
I tried to use img2simg in Debian stretch but is an old version (5.x) and
fails to create images when are small size (ramdisk).
So it's a good opportunity to change the docker builder to Debian buster
with a newer img2simg (8.x) tool in qcom-lt builds, I made the change in a
way that doesn't affect current builds that uses Debian stretch [3] and
give time to other users to switch (if needed).
Regards,
Anibal
[1] https://validation.linaro.org/scheduler/job/1965964
[2] https://discuss.96boards.org/t/ext2simg-is-corrupting-custom-rootfs/8792
[3]
https://git.linaro.org/ci/job/configs.git/commit/?id=2798029ae4a2772c9b51ef…
