Dragonboard410c 32bit oe secondary toolchain

Products Support DragonBoard410c
#1

Hello guys,

We have 32bit arm code/libraries that we woulds like to build on the dragonboard410c using OE.
We also have some dependencies on libraries built by OE like boost and curl etc…

What would be the best way of doing this, should we build the whole system in 32bit or maybe we should add the receipes for the secondary toolchain ?

I saw a recipe named external-linaro-toolchain, and also found this link:
Adding a secondary toolchain - Openembedded.org but is it really what we need ?

Being new to this oe world i’m pretty lost right now and I am not sure of the right path to take and the best way to do it. Any information about how to do this will be really appreciated.

Thanks Alot.
Félix

#2

hey,

we have just added/verified support for ‘multilib’ recently in our OE builds. this is what I would recommend to use, not the secondary toolchain. The secondary toolchain is more suited for compiling firmware for other cores on the platform (DSP, …). ‘multilib’ is an OE feature that lets you mix 32 and 64 bits libraries (and apps) in the same system.

I don’t know how you setup your OE builds, which distro you are using, … if you are using the OE RPB setup and if you are using our morty or master branch, then multilib is enabled by default now.

The main change when we brought up this feature is this commit:

Once you enable multilib you can add a 32 bit lib or apps by adding “lib3-xxx” in your image. E.g. “lib32-htop” will add the htop package built for 32 bit, while the rest of the system is 64 bit.

#3

Awesome! This looks exactly what I needed.
I’ll sync on morty =)

Thanks Alot.

#4

After updating to morty I saw the new dragonboard-32 machine available, is
this something I could consider or it is too unstable at this point ?

#5

I would not recommend that… the -32 machines were quick hacks we did before we got multilib to work. in fact i am planning to remove them soon’ish. they were used to build the entire file system as 32-bit, and building the 64 kernel as a second step.

my understanding from your initial post is that you needed a mixed system with 32 and 64, and the -32 machine does not give that.

#6

Yes both solutions could be possible for us, this is simply because my first attempt of building morty in multilib resulted in this error so I wanted to try the 32bit to see :

Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 8 LDFLAGS=-Wl,-O1 -Wl,–hash-style=gnu -Wl,–as-needed -L/home/felixdb/centaur/build/CentaurYocto/build/tmp-rpb-glibc/sysroots/dragonboard-410c/usr/lib64 -lqrtr
| ERROR: oe_runmake failed
| aarch64-linaro-linux-gcc --sysroot=/home/felixdb/centaur/build/CentaurYocto/build/tmp-rpb-glibc/sysroots/dragonboard-410c -o rmtfs qmi_rmtfs.o qmi_tlv.o rmtfs.o sharedmem.o storage.o util.o -Wl,-O1 -Wl,–hash-style=gnu -Wl,–as-needed -L/home/felixdb/centaur/build/CentaurYocto/build/tmp-rpb-glibc/sysroots/dragonboard-410c/usr/lib64 -lqrtr
| /home/felixdb/centaur/build/CentaurYocto/build/tmp-rpb-glibc/sysroots/x86_64-linux/usr/libexec/aarch64-linaro-linux/gcc/aarch64-linaro-linux/5.2.1/ld: cannot find -lqrtr
| collect2: error: ld returned 1 exit status
| Makefile:11: recipe for target ‘rmtfs’ failed
| make: *** [rmtfs] Error 1
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at /home/felixdb/centaur/build/CentaurYocto/build/tmp-rpb-glibc/work/aarch64-linaro-linux/rmtfs/0.0+AUTOINC+dc7de6ef56-r0/temp/log.do_compile.11829)

#7

yes, right… i should have mentioned that… we found (and fixed) this issue. it was pushed this morning in meta-qcom.

see 2636 – multilib breaks 410c/rtmfs recipe for more details.

#8

Great =) synching hehe

Thanks.

#9

I was able to build everything and I added some lib32 libraries that seem to be deployed into /usr/lib/x86_64-linux-gnu folder which sound weird to me but this is not a problem since the libs seem to be arm.

I also see alot of errors in the kernel at boot:
[ 3.500307] WARNING: at /home/felixdb/centaur/build/CentaurYocto/build/tmp-rpb-glibc/work-shared/dragonboard-410c/kernel-source/drivers/clk/clk.c:684
[ 3.643616] Call trace:
[ 3.648181] [<ffffffc000661aa0>] clk_core_disable+0x50/0x58
[ 3.650462] [<ffffffc0003cd5e4>] amba_put_disable_pclk.isra.2+0x1c/0x38
[ 3.655939] [<ffffffc0003cda2c>] amba_probe+0x154/0x178
[ 3.662584] [<ffffffc00049fdc4>] driver_probe_device+0x21c/0x480
[ 3.667743] [<ffffffc0004a00c4>] __driver_attach+0x9c/0xa0
[ 3.674091] [<ffffffc00049db80>] bus_for_each_dev+0x60/0xa0
[ 3.679277] [<ffffffc00049f578>] driver_attach+0x20/0x28
[ 3.684763] [<ffffffc00049f0e8>] bus_add_driver+0x208/0x290
[ 3.690314] [<ffffffc0004a0888>] driver_register+0x60/0xf8
[ 3.695614] [<ffffffc0003ccf9c>] amba_driver_register+0x54/0x60
[ 3.701202] [<ffffffc000cc31f4>] etm4x_driver_init+0x14/0x1c
[ 3.707033] [<ffffffc000082990>] do_one_initcall+0xd0/0x1d8
[ 3.712924] [<ffffffc000c8fb3c>] kernel_init_freeable+0x1c4/0x268
[ 3.718229] [<ffffffc0008bea48>] kernel_init+0x10/0xe0
[ 3.724451] [<ffffffc000085dd0>] ret_from_fork+0x10/0x40

Still this is not my main problem, the real problem I have with the multilib build is that the g_ether module does not seem to work anymore.
(it may be related to morty)

But when I modprobe g_ether I am not able to make a usb0 ethernet connection with my pc anymore which was working with jethro.
Is it something you have experienced ?

Regards,
Felix

#10

well, it is not normal to have x86_64 in the paths. Where did you see that? What did you build?

If I build ‘bitbake lib32-libdrm’, then I am getting these files:

~/work/oe-rpb-morty/build-rpb$ dpkg -c tmp-rpb-glibc/deploy/ipk/armv7ahf-neon/lib32-libdrm-freedreno1_2.4.70-r0_armv7ahf-neon.ipk
drwxrwxrwx root/root 0 2016-11-29 21:25 ./
drwxr-xr-x root/root 0 2016-11-29 21:24 ./usr/
drwxr-xr-x root/root 0 2016-11-29 21:24 ./usr/lib/
lrwxrwxrwx root/root 0 2016-11-29 21:24 ./usr/lib/libdrm_freedreno.so.1 -> libdrm_freedreno.so.1.0.0
-rwxr-xr-x root/root 18480 2016-11-29 21:24 ./usr/lib/libdrm_freedreno.so.1.0.0

Which is expected. 32-bit libs go to /usr/lib , and 64-bit libs to /usr/lib64 (at least for now).

#11

Lol sorry, forget about the point 1, it was a userbad I was not on the right shell…
It is exactly like you said, /usr/lib and /usr/lib64

For the USB gadget ethernet I will still try to make it work today but if you had some time to try it out it could help.
Normally I use the usbinit recipe in my image and the connection is created at boot.

Right now the init script(/etc/init.d/usb-gether) does not seem to be launched at all.

Even if I do the modprobe manually(g_ether) and ifconfig usb0 up , my host machine does not detect anything.

Regards.