(Yocto) Linux for Analog Devices ADSP-SC5xx Processors

-

Introduction

This work is sponsored by Reliable Embedded Systems. You can find more information about our training/consulting services here.

Objectives

The goal of this blog post is to show how to build an image for Analog Devices ADSP-SC5xx chips and how to deal with ancient versions delivered by Board/Chip vendors. Please let them know that you are not happy!

Let the party begin

System setup

In case you wanted to build for ADSP-SC5xx Processors you might want to have a look here.

repo init -u https://github.com/analogdevicesinc/lnxdsp-repo-manifest.git -b release/yocto-1.0.0
repo sync

So far so good. All this does not look too old with the latest commit on the manifest file from  Jul 23 2020 but if you look a bit further you'll see that the Yocto version is thud. Dear Analog Devices: "You don't expect us to take you seriously when you release something in July 2020 and it's based on thud (from 2018). Nice try, but please try a bit harder next time, since this is already outdated." Of course issues are expected with this. We need to ship this to our customers. Should we really maintain this ourselves?

source setup-environment -m adsp-sc573-ezkit

The setup went smooth. So let's try to BitBake something small.

BitBake it

bitbake adsp-sc5xx-minimal

The problem here is, that with my standard build container (Ubuntu 18.04/gcc 9.3.0 this ancient Yocto version (thud) does not build.

cmake-native refuses to build (in my build environment)

cmake-native refuses to build:

/workdir/sources/analog-devices/build/tmp/work/x86_64-linux/cmake-native/3.12.2-r0/build/Bootstrap.cmk/cmake: /workdir/sources/analog-devices/build/tmp/sysroots-uninative/x86_64-linux/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /workdir/sources/analog-devices/build/tmp/work/x86_64-linux/cmake-native/3.12.2-r0/build/Bootstrap.cmk/cmake)
| ---------------------------------------------
| Error when bootstrapping CMake:
| Problem while running initial CMake
| ---------------------------------------------
I guess this is because the ancient uninative tarball does not contain the proper (newer) glibc version I use with my gcc 9.3.0. BTW my setup works happily with dunfell.

strings /workdir/sources/analog-devices/build/tmp/sysroots-uninative/x86_64-linux/usr/lib/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25

Now what?

Let's downgrade the build container to something ancient as well and give this a try.

I give it a try with a build container with Ubuntu 16.04 and a gcc 6.5.0 and hope nobody needs to use meta-java with it.

bitbake adsp-sc5xx-minimal
Loading cache: 100% |#########################################################################################################################################| Time: 0:00:00
Loaded 3070 entries from dependency cache.
Parsing recipes: 100% |#######################################################################################################################################| Time: 0:00:01
Parsing of 2119 .bb files complete (2115 cached, 4 parsed). 3071 targets, 118 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION           = "1.40.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "arm-poky-linux-gnueabi"
MACHINE              = "adsp-sc573-ezkit"
DISTRO               = "poky"
DISTRO_VERSION       = "2.6.2"
TUNE_FEATURES        = "arm armv7a vfp thumb neon callconvention-hard"
TARGET_FPU           = "hard"
meta
meta-poky
meta-yocto-bsp       = "HEAD:50f33d3bfebcbfb1538d932fb487cfd789872026"
meta-adi-adsp-sc5xx
meta-adi-external-toolchain = "HEAD:ad2203c11723b07727589a8eebe33f3129cc236a"
meta-oe
meta-python
meta-networking      = "HEAD:4cd3a39f22a2712bfa8fc657d09fe2c7765a4005"

Initialising tasks: 100% |####################################################################################################################################| Time: 0:00:02
Sstate summary: Wanted 413 Found 0 Missed 413 Current 655 (0% match, 61% complete)
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: u-boot-adi-1.0+gitAUTOINC+c372d6cadd-r0 do_package_qa: QA Issue: ELF binary '/workdir/sources/analog-devices/build/tmp/work/adsp_sc573_ezkit-poky-linux-gnueabi/u-boot-adi/1.0+gitAUTOINC+c372d6cadd-r0/packages-split/u-boot-adi/u-boot-sc573-ezkit' has relocations in .text [textrel]
NOTE: Tasks Summary: Attempted 3119 tasks of which 2407 didn't need to be rerun and all succeeded.

Summary: There was 1 WARNING message shown.

We could even get rid of this warning if we really wanted to.

Conclusion

The message here is, that it must be easy for you to switch between different build environments with different versions of different host Linux distributions, hence I suggest you look into build containers. Check out the video below how to set up the development environment of Reliable Embedded Systems which was used here:

Comments

Post a Comment

Popular posts from this blog

Yocto: BitBake and Dependencies - e.g. One recipe to use output of another recipe

-
Image
It feels weird to help some get their working build to fail and then for them to be happy about it... (RP) Introduction This work is sponsored by Reliable Embedded Systems . You can find more information about our training/consulting services here . Objectives The goal of this blog post is to look into BitBake dependencies. As an example let's take recipe A ( u-boot-phytex-imx ) which needs the output of recipe B ( firmware-imx-8m ) for a successful compilation. (Please don't ask why.) To be more precise here is an excerpt of recipe A ( u-boot-phytex-imx ): # --> this funny u-boot from Phytec needs the ddr_firmware binaries in ${S} # Note: here we copy deployed stuff from another recipe # to the source dir of this recipe! # # DEPENDS deals with build-time depenencies # Read my blog post to find out why DEPENDS does not work here # # DEPENDS += " \ # firmware-imx-8m \ # " # RDEPENDS is wrong anyhow for what I want
Read more

Yocto: kernel modules not showing up in the rootfs

-
Image
Introduction This work is sponsored by Reliable Embedded Systems . You can find more information about our training/consulting services here . Objectives The goal of this blog post is to point out a well known and documented issue with kernel modules not ending up on the root file system which is likely overseen by people until they stumble over it.   Kernel module(s) So you created a brand new kernel module, or you just wanted to include all the kernel modules in the root file system, or just one of them. You reach out to the community mailing list or chat with something like this: I have MACHINE_EXTRA_RRECOMMENDS + = "kernel-modules" in my machine configuration. When I look into the rootfs I see no modules installed in /lib/modules/ $( uname -r ) . I get only a modules tarball in the deploy directory. I also tried MACHINE_EXTRA_RDEPENDS + = "kernel-modules" and it still does not work. What am I doing wrong? Check the Mega Manual If things d
Read more

Yocto/Qt5: hello-qt part2 - Licensing

-
Image
Introduction This work is sponsored by Reliable Embedded Systems . You can find more information about our training/consulting services here . Objectives The goal of this blog post is to show my journey trying to build a hello-qt application and reasons why I don't like Qt . As far as I can tell this is going to be a multi part blog post. You might want to have a look at part one as well. Disclaimer: I am not a lawyer, so I can not give legal advice. GPL and LGPL licenses LGPL v2.x Typically libraries are licensed with this license You need to provide the source code (including modifications) and instructions on how to build the LGPL v2.1 licensed code In case your application links statically against LGPL licensed code you need to provide the object files of your applications to be able to replace the LGPL'ed code with different versions In case your application links dynamically against LGPL licensed code you can replace the LGPL'ed libraries without the objec
Read more