Microchip-sama5d27-som1-ek1 integrate with google IOT cloud

Used this link for setting up for atmel platform using Microchip SAMA5d27-SOM1-EK1
This works great with demo server.

Then followed this link https://mkrak.org/wp-content/uploads/2019/04/Integrate-IoT-cloud-analytics-and-over-the-air-OTA-updates-with-Google-and-Mender.io_.pdf
In order to integrate with google IoT cloud.
Used your link in the document for https://cloud.google.com/community/tutorials/cloud-iot-mender-ota and modified mender-gcp-build.sh to what I thought would work for my build. I have enclosed the modified script below.
On first run got this:

 ERROR: Layer meta-gcp-iot is not compatible with the core layer which only supports these series: thud (layer is compatible with rocko master sumo)

So modified the conf file for meta-gcp-iot to include thud.
And then I got this error:

ERROR: /home/nima/wip/mender-atmel/sources/community/tutorials/cloud-iot-mender-ota/image/meta-gcp-iot/recipes-gcp/images/gcp-mender-demo-image.bb: MENDER_DATA_PART_DIR is deprecated. Please use recipes to add files directly to /data instead.
ERROR: Failed to parse recipe: /home/nima/wip/mender-atmel/sources/community/tutorials/cloud-iot-mender-ota/image/meta-gcp-iot/recipes-gcp/images/gcp-mender-demo-image.bb

Can you provide some guidance on steps to proceed to correct this error? I attempted the suggested options based on your documentation but the build did not contain the mender.conf files among others in /data partition.
Thank you

content of modified script used for mender-gcp-build.sh:

cd sources
[ -d meta-gcp-iot ] || git clone -b master https://github.com/GoogleCloudPlatform/community.git
source ../setup-environment atmel
if [ -d ~/downloads ] ; then
    rm -rf ./downloads
    ln -s ~/downloads .
if [ -d ~/sstate-cache ]; then
    rm -rf ./sstate-cache
    ln -s ~/sstate-cache .
bitbake-layers add-layer -F /home/nima/wip/mender-atmel/sources/meta-openembedded/meta-oe
bitbake-layers add-layer -F /home/nima/wip/mender-atmel/sources/meta-openembedded/meta-python
bitbake-layers add-layer -F /home/nima/wip/mender-atmel/sources/meta-openembedded/meta-multimedia
bitbake-layers add-layer -F /home/nima/wip/mender-atmel/sources/meta-openembedded/meta-networking
bitbake-layers add-layer -F /home/nima/wip/mender-atmel/sources/meta-java
bitbake-layers add-layer -F /home/nima/wip/mender-atmel/sources/meta-iot-cloud
bitbake-layers add-layer -F /home/nima/wip/mender-atmel/sources/community/tutorials/cloud-iot-mender-ota/image/meta-gcp-iot
cat > conf/auto.conf <<- EOF
	MENDER_SERVER_URL = "https://mender.gcpotademo.com"
	PACKAGE_CLASSES = "package_ipk"
	INHERIT += "rm_work"
export FULL_PROJECT=$(gcloud config list project --format "value(core.project)")
export PROJECT_ID="$(echo $FULL_PROJECT | cut -f2 -d ':')"
export REGION_ID='us-central1'
export REGISTRY_ID='mender-demo'
export IMAGE='gcp-mender-demo-image'
export MACHINE='sama5d27-som1-ek-sd'

# Ensure that the GCP variables defined above are passed into the bitbake environment

bitbake ${IMAGE}
cp ./tmp/deploy/images/${MACHINE}/${IMAGE}-${MACHINE}-*.sdimg ./tmp/deploy/images/${MACHINE}/${IMAGE}-${MACHINE}-*.img
gsutil cp $(find ./tmp/deploy/images/${MACHINE}/${IMAGE}-${MACHINE}-*.sdimg -type f) gs://$PROJECT_ID-mender-builds/${IMAGE}-${MACHINE}.sdimg
gsutil cp $(find ./tmp/deploy/images/${MACHINE}/${IMAGE}-${MACHINE}-*.sdimg.bmap -type f) gs://$PROJECT_ID-mender-builds/${IMAGE}-${MACHINE}.sdimg.bmap
gsutil cp $(find ./tmp/deploy/images/${MACHINE}/${IMAGE}-${MACHINE}-*.img -type f) gs://$PROJECT_ID-mender-builds/${IMAGE}-${MACHINE}.img
cat >> conf/auto.conf <<-	EOF
	IMAGE_INSTALL_append = " python-docs-samples"
bitbake ${IMAGE}
gsutil cp $(find ./tmp/deploy/images/${MACHINE}/${IMAGE}-${MACHINE}-*.mender -type f) gs://$PROJECT_ID-mender-builds/${IMAGE}-${MACHINE}.mender

Can you please share the changes you did to get around this? There are a couple of locations which use the “old method” to install to /data and all of them need to be updated.

That said, this was only on rocko, and might require some additional updates to work on thud




inherit deploy
do_deploy() {
    install -d ${DEPLOYDIR}/persist
    install -m 0644 persistent.txt ${DEPLOYDIR}/persist
addtask do_deploy after do_compile before do_build

Unfortunately the first time I did not document all of my steps as well as this time. So there maybe a few things that are missing from that run. However, I got to a good compile and after I burned an sd image, I saw that the ln file in etc/mender was correctly pointing to /data/mender but did not see an mender.conf in the corresponding /data/mender directory.
I have made the change above and it is now compiling again. I will confirm if I see the same problem. If you already see an issue with what I have done then please let me know as it will take a few hours to compile.
Thank you.

Which version of the docs did you get that from?

The most recent example can be found here,

Nowadays you just install to ${D} /data like you would normally and this will be converted to the data partition

but I will follow your recommendation now.

I understood that MENDER_DATA_PART_DIR was used to add files to the data partition of mender.
In examining source of what is building the mender conf file it seems like it is mender-gcp-iot.inc:

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

SRC_URI += " \
    file://gcp-iot-mender-device-identity \
    file://mender.conf \
    file://mender-generate-certificate \

FILES_${PN} += " \
     ${sbindir}/mender-keygen-client \
     ${sbindir}/mender-generate-certificate \

do_install_prepend() {
    # Update the service file to invoke mender-generate-certificate
    cat >> ${WORKDIR}/${SYSTEMD_SERVICE_${PN}} <<-EOF

do_install_append() {
    install -d ${D}/${datadir}/mender/identity
    install -m 0755  ${WORKDIR}/gcp-iot-mender-device-identity ${D}/${datadir}/mender/identity/mender-device-identity
    install -d ${D}/${sbindir}
    install -m 0700 ${S}/src/${GO_IMPORT}/support/keygen-client ${D}/${sbindir}/mender-keygen-client
    install -m 0700 ${WORKDIR}/mender-generate-certificate ${D}/${sbindir}/


do_compile_prepend() {
  bbwarn "You are building with the meta-gcp-iot layer, which is not intended for production use"

RDEPENDS_${PN} += " bash openssl"

inherit deploy

do_deploy() {
   install -d ${DEPLOYDIR}/persist/mender
   mv ${D}${sysconfdir}/mender/mender.conf ${DEPLOYDIR}/persist/mender
   ln -s /data/mender/mender.conf ${D}${sysconfdir}/mender/mender.conf
addtask do_deploy after do_install before do_package

Are you suggesting to keep this file intact and just focus on the changing where this statement MENDER_DATA_PART_DIR = “${DEPLOY_DIR_IMAGE}/persist” was placed with your version?
Or should I also make similar changes to the mender-gcp-iot.inc file?

Normally I would experiment more on my own but it takes so many hours to just get a good compile that I rather ask a bit ahead of my next compile.

Thank you.

mender.conf is created by the mender recipe, mender-gcp-iot.inc is used in a mender_%.bbappend

You can remove MENDER_DATA_PART_DIR = “${DEPLOY_DIR_IMAGE}/persist”. As this is not used anymore.

And you need to change,

do_deploy() {
   install -d ${DEPLOYDIR}/persist/mender
   mv ${D}${sysconfdir}/mender/mender.conf ${DEPLOYDIR}/persist/mender
   ln -s /data/mender/mender.conf ${D}${sysconfdir}/mender/mender.conf


do_install() {
   install -d ${D}/data/mender
   mv ${D}${sysconfdir}/mender/mender.conf ${D}/data/mender
   ln -s /data/mender/mender.conf ${D}${sysconfdir}/mender/mender.conf

You do not necessary need to create a new do_install but can add above to the existing do_install_append function in the mender-gcp-iot.inc file.

I have incorporated the changes as specified. That is very helpful. I am not very clear on the mixed-use of ${D} in old code but have not had a chance to find documentation or examine the source code.

It is still not compiling but the problem is with YOCTO at this point. I have been seeking suggestions on the Yocto IRC but thought I would post it here too in case you have a suggestion.

I am getting:

![image|690x332](upload://2y3711hT3nremsyKO4UWiSGBvXm.png) Running pm_to_blib for cpan/version directly
LD_LIBRARY_PATH=~/wip/mender-atmel/build/tmp/work/x86_64-linux/perl-native/5.24.4-r0/perl-5.24.4 ./miniperl -Ilib make_ext.pl dist/XSLoader/pm_to_blib  MAKE="make" LIBPERL_A=libperl.so
make[1]: Entering directory '~/wip/mender-atmel/build/tmp/work/x86_64-linux/perl-native/5.24.4-r0/perl-5.24.4/dist/XSLoader'
make[1]: Leaving directory~/wip/mender-atmel/build/tmp/work/x86_64-linux/perl-native/5.24.4-r0/perl-5.24.4/dist/XSLoader'
LD_LIBRARY_PATH=~/wip/mender-atmel/build/tmp/work/x86_64-linux/perl-native/5.24.4-r0/perl-5.24.4 ./miniperl -Ilib lib/unicore/mktables -C lib/unicore -P pod -maketest -makelist -p
lib/unicore/mktables: Files seem to be ok, not bothering to rebuild.  Add '-w' option to force build
LD_LIBRARY_PATH=~/wip/mender-atmel/build/tmp/work/x86_64-linux/perl-native/5.24.4-r0/perl-5.24.4 ./miniperl -Ilib -Ilib -MExtUtils::Miniperl -e 'writemain(\"perlmain.c", @ARGV)' DynaLoader 
gcc -c -DPERL_CORE -D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c89 -O2 -Wall -Werror=declaration-after-statement -Wextra -Wc++-compat -Wwrite-strings -fPIC perlmain.c
LD_LIBRARY_PATH=~/wip/mender-atmel/build/tmp/work/x86_64-linux/perl-native/5.24.4-r0/perl-5.24.4 ./miniperl -Ilib make_ext.pl DynaLoader.o  MAKE="make" LIBPERL_A=libperl.so LINKTYPE=static 
make[1]: Entering directory '~/wip/mender-atmel/build/tmp/work/x86_64-linux/perl-native/5.24.4-r0/perl-5.24.4/ext/DynaLoader'
make[1]: Leaving directory '~/wip/mender-atmel/build/tmp/work/x86_64-linux/perl-native/5.24.4-r0/perl-5.24.4/ext/DynaLoader'
rm -f libperl.so
gcc  -o libperl.so -L~/wip/mender-atmel/build/tmp/work/x86_64-linux/perl-native/5.24.4-r0/recipe-sysroot-native/usr/lib -L~/wip/mender-atmel/build/tmp/work/x86_64-linux/perl-native/5.24.4-r0/recipe-sysroot-native/lib -Wl,-rpath-link,~/wip/mender-atmel/build/tmp/work/x86_64-linux/perl-native/5.24.4-r0/recipe-sysroot-native/usr/lib -Wl,-rpath-link~/wip/mender-atmel/build/tmp/work/x86_64-linux/perl-native/5.24.4-r0/recipe-sysroot-native/lib -Wl,-rpath~/wip/mender-atmel/build/tmp/work/x86_64-linux/perl-native/5.24.4-r0/recipe-sysroot-native/usr/lib -Wl,-rpath~/wip/mender-atmel/build/tmp/work/x86_64-linux/perl-native/5.24.4-r0/recipe-sysroot-native/lib -Wl,-O1 -Wl,--allow-shlib-undefined -Wl,--dynamic-linker=~/wip/mender-atmel/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 -shared -L/usr/local/lib op.o     perl.o  gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o dquote.o time64.o   DynaLoader.o -lpthread -lnsl -ldl -lm -lcrypt -lutil -lc 
~/wip/mender-atmel/build/tmp/hosttools/ld: /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libcrypt.a(crypt-entry.o): relocation R_X86_64_PC32 against symbol `_ufc_foobar' can not be used when making a shared object; recompile with -fPIC
~/wip/mender-atmel/build/tmp/hosttools/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
ERROR: oe_runmake failed
makefile:358: recipe for target 'libperl.so' failed
make: *** [libperl.so] Error 1
WARNING: exit code 1 from a shell command.
ERROR: Function failed: do_compile (log file is located at ~/wip/mender-atmel/build/tmp/work/x86_64-linux/perl-native/5.24.4-r0/temp/log.do_compile.24783)

I tried adding -fPIC in a few places but did not get anywhere.
in bitbake.conf under …/poky/meta/conf/bitbake.conf:


In …/poky/meta/recipes-devtools/perl/perl_5.4.4.bb:

# LDFLAGS for shared libraries
export LDDLFLAGS = "${LDFLAGS} -shared -fPIC"
CFLAGS += "-DDEBIAN -fPIC" # and tried this too!

in ./poky/meta/recipes-devtools/perl/perl-native_5.24.4.bb:

inherit native
##CC += " -fPIC" -- tried this too

export LD="${CCLD} -fPIC"

I can see the -fPIC in gcc statement but looks like I have to add it somewhere else. That is why I tried upstream but that did not work either.

Thank you.