I want to build my recipe into 32bit binary on 64bit system, I have Multilib enabled :
multilib configuration add in local.conf :
MACHINE = "ti-am335x"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
Infomation:
Build Configuration:
WRLINUX_VERSION = "10.19.45.22"
WRLINUX_BRANCH = "LTS"
BB_VERSION = "1.44.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
DISTRO = "openwrt"
DISTRO_VERSION = "1.0"
MACHINE = "ti-am335x"
DEFAULTTUNE = "cortexa8thf-neon"
TARGET_SYS = "arm-wrs-linux-musleabi"
TUNE_FEATURES = "arm vfp cortexa8 neon thumb callconvention-hard"
TARGET_FPU = "hard"
The potential multilibs are listed in the AVAILTUNES declaration. For qemu86-64 BSP, that value equals the following.
bitbake -e mozjpegcjpeg | grep ^AVAILTUNES
AVAILTUNES=" x86 x86-64 "
I have followed the steps to enable multilib , but it shows this error :
Document : https://docs.windriver.com/bundle/Wind_River_Linux_Platform_Developers_Guide_9_1/page/fau1551818735785.html
ERROR: OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
Following is the list of potential problems / advisories:
Toolchain tunings invalid:
Tuning 'x86' has no defined features, and cannot be used.
your
MACHINE=ti-am335x
is not pointing to a x86 architectur
rebuild your toolchain when using something like
MACHINE=qemux86
there are also meta-layers for higher intel or amd cpus
Related
I'm trying to build nodejs with Yocto on a 32-bit Ubuntu 16.04 host, but the link operation failed with the following message
/home/dev/Projet/yocto-dunfell/build/tmp/work/armv7at2hf-neon-poky-linux-gnueabi/nodejs/12.21.0-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/9.3.0/ld:
failed to set dynamic section sizes: memory exhausted
My virtual machine has 13 GB of RAM and I've set in my local.conf
BB_NUMBER_THREADS = "1"
PARALLEL_MAKE = "-j 1"
I have NAS Terramaster F4-210 based on arm64 Realtek RTD1296 CPU. It has custom OpenWrt 15.05.1 based firmware with 4.4.18 linux kernel. I want to create kernel module to use my zigbee stick (cdc-acm - USB Modem (CDC ACM) support) and run homeassistant on it.
# uname -a
Linux TNAS-BA68 4.4.18-g8bcbd8a-dirty #1327 SMP Mon Aug 31 11:55:52 CST 2020 aarch64 GNU/Linux
I downloaded appropriate kernel, created some config and after installing my newly compiled module I get the following errors in kernel log:
# modprobe cdc-acm
1 module could not be probed
- cdc-acm
# dmesg
...
cdc_acm: Unknown symbol __copy_to_user (err 0)
cdc_acm: Unknown symbol __copy_from_user (err 0)
cdc_acm: Unknown symbol _mcount (err 0)
As far as I understand that means module expects copy_to_user, copy_from_user, mcount to be part of the kernel (or other loaded module). But kernel doesn't export these symbols:
# cat /proc/kallsyms | grep copy_to_user
ffffff80082923f0 T copy_to_user_page
ffffff80087d2600 T __arch_copy_to_user
ffffff80087e67b0 t kfifo_copy_to_user
ffffff8008871854 T my_copy_to_user
File arch/arm64/include/asm/uaccess.h has definition of copy_to_user:
extern unsigned long __must_check __copy_to_user(void __user *to, const void *from, unsigned long n);
...
static inline unsigned long __must_check copy_to_user(void __user *to, const void *from, unsigned long n)
File arch/arm64/lib/copy_to_user.S contains source code of __copy_to_user:
ENTRY(__copy_to_user)
ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, CONFIG_ARM64_PAN)
...
ENDPROC(__copy_to_user)
My initial idea was I have bad kernel configuration or bad toolchain. So I used toolchain and OpenWrt+kernel configuration from banana pi W2 board which has the same CPU. Without any luck but compile warning had disappeared.
So can somebody please confirm that the problem can't be solved by applying some different kernel configuration or proper toolchain. Instead kernel source code must be modified. E.g. instead of __copy_to_user one of __arch_copy_to_user or my_copy_to_user must be used.
So my assumption is: Terramaster took kernel sources, modified (probably used __arch_copy_to_user instead of __copy_to_user) and then compiled sources.
BTW: I also checked kernel sources and didn't find __arch_copy_to_user. Does that mean it was introduced by kernel sources modifications or it still can be present thereby usage of some nasty defs.
I'm currntly trying to build a yocto image and SDK for a custom board with MediaTek MT8167B (https://www.mediatek.com/products/tablets/mt8167b).
I'm having the latest yocto version (2.5.2), i've setup this in the local.conf :
MACHINE ?= "qemuarm"
TARGET_SYS = "arm-linux-gnueabihf"
TUNE_FEATURES = "arm armv7a cortexa7 vfpv4 neon"
TUNE_CCARGS_MFLOAT = "vfp"
TUNE_CCARGS_MFLOAT = "hard"
But before building, the build configuration show that the TARGET_FPU is still soft :
Build Configuration:
BB_VERSION = "1.38.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "arm-linux-gnueabihf"
MACHINE = "qemuarm"
DISTRO = "poky"
DISTRO_VERSION = "2.5.2"
TUNE_FEATURES = "arm armv7a cortexa7 vfpv4 neon"
TARGET_FPU = "soft"
meta
meta-poky
meta-yocto-bsp = "psc-2.5.2:95ebfb33e4c0aa9669f318e061a4d7540b84f4ac"
Then the build start and is crashing at this point :
| checking whether ln -s works... yes
| checking for arm-linux-gnueabihf-gcc... /home/mggk/poky/build/tmp/work/x86_64-linux/gcc-cross-initial-arm/7.3.0-r0/gcc-7.3.0/build.x86_64-linux.arm-linux-gnueabihf/./gcc/xgcc -B/home/mggk/poky/build/tmp/work/x86_64-linux/gcc-cross-initial-arm/7.3.0-r0/gcc-7.3.0/build.x86_64-linux.arm-linux-gnueabihf/./gcc/ -B/home/mggk/poky/build/tmp/work/x86_64-linux/gcc-cross-initial-arm/7.3.0-r0/recipe-sysroot-native/usr/arm-linux-gnueabihf/bin/ -B/home/mggk/poky/build/tmp/work/x86_64-linux/gcc-cross-initial-arm/7.3.0-r0/recipe-sysroot-native/usr/arm-linux-gnueabihf/lib/ -isystem /home/mggk/poky/build/tmp/work/x86_64-linux/gcc-cross-initial-arm/7.3.0-r0/recipe-sysroot-native/usr/arm-linux-gnueabihf/include -isystem /home/mggk/poky/build/tmp/work/x86_64-linux/gcc-cross-initial-arm/7.3.0-r0/recipe-sysroot-native/usr/arm-linux-gnueabihf/sys-include --sysroot=/home/mggk/poky/build/tmp/work/x86_64-linux/gcc-cross-initial-arm/7.3.0-r0/recipe-sysroot
| checking for suffix of object files... configure: error: in `/home/mggk/poky/build/tmp/work/x86_64-linux/gcc-cross-initial-arm/7.3.0-r0/gcc-7.3.0/build.x86_64-linux.arm-linux-gnueabihf/arm-linux-gnueabihf/libgcc':
| configure: error: cannot compute suffix of object files: cannot compile
| See `config.log' for more details.
| ERROR: oe_runmake failed
| Makefile:11175: recipe for target 'configure-target-libgcc' failed
| make: *** [configure-target-libgcc] Error 1
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at /home/mggk/poky/build/tmp/work/x86_64-linux/gcc-cross-initial-arm/7.3.0-r0/temp/log.do_compile.25969)
ERROR: Task (/home/mggk/poky/meta/recipes-devtools/gcc/gcc-cross-initial_7.3.bb:do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 138 tasks of which 80 didn't need to be rerun and 1 failed.
To be honest, i have no idea of what makes it crash, clean Linux System (Ubuntu 18.04) and not other compiler installed.
Thanks for your help.
qemuarm in OE-Core is primarily a armv5te emulator, so the changes you have done wont make this work for a newer architecture.
I would suggest that you add something like meta-qemuarma9 to your bblayers.conf and then set
MACHINE = "qemuarma9" and bake your SDK.
I'm trying to build automotive grade linux, but I keep getting the same errors.
I tried building on different machines with different linux distributions, but I keep getting the error nevertheless.
I also tried building for different machines without success.
This is the full log of the last time I tried to build automotive grade linux for a raspberry pi 2:
Pt 1: https://pastebin.com/0pqKDdv5
Pt 2: https://pastebin.com/dmRCtTLe
This is my build configuration:
BB_VERSION = "1.32.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "Debian-9.3"
TARGET_SYS = "arm-agl-linux-gnueabi"
MACHINE = "raspberrypi2"
DISTRO = "poky-agl"
DISTRO_VERSION = "4.0.2"
TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4 callconvention-hard"
TARGET_FPU = "hard"
meta-raspberrypi = "HEAD:28d4404f89eb59d406b4976c0e3f5ca19137ba74"
meta-netboot = "HEAD:a5f69d3d31e7d75351f0e2abfc36d35ba39ce304"
meta-security-smack
meta-security-framework = "HEAD:20bbb97f6d5400b126ae96ef446c3e60c7e16285"
meta-app-framework = "HEAD:a5f69d3d31e7d75351f0e2abfc36d35ba39ce304"
meta-qt5 = "HEAD:5f837b47f5c3e462f24cd5abf58ff6ef1dd04932"
meta-agl-demo = "HEAD:65619655cb3f373a1b15da7a4d91191a2867464b"
meta-oe
meta-multimedia
meta-efl
meta-networking
meta-python
meta-filesystems = "HEAD:fe5c83312de11e80b85680ef237f8acb04b4b26e"
meta-ivi-common
meta-agl
meta-agl-distro
meta-agl-bsp = "HEAD:a5f69d3d31e7d75351f0e2abfc36d35ba39ce304"
meta
meta-poky = "HEAD:60402978fe3648bf560b3386c6e9dd661cdf2083"
This is the first error I get:
WARNING: qemu-native-2.7.0-r1 do_populate_sysroot: File '/.../build/tmp/sysroots/x86_64-linux/usr/share/qemu/openbios-ppc' from qemu-native was already stripped, this will prevent future debugging!
WARNING: qemu-native-2.7.0-r1 do_populate_sysroot: File '/.../build/tmp/sysroots/x86_64-linux/usr/share/qemu/openbios-sparc32' from qemu-native was already stripped, this will prevent future debugging!
WARNING: qemu-native-2.7.0-r1 do_populate_sysroot: File '/.../build/tmp/sysroots/x86_64-linux/usr/share/qemu/openbios-sparc64' from qemu-native was already stripped, this will prevent future debugging!
WARNING: qemu-native-2.7.0-r1 do_populate_sysroot: File '/.../build/tmp/sysroots/x86_64-linux/usr/share/qemu/s390-ccw.img' from qemu-native was already stripped, this will prevent future debugging!
WARNING: qemu-native-2.7.0-r1 do_populate_sysroot: File '/.../build/tmp/sysroots/x86_64-linux/usr/share/qemu/u-boot.e500' from qemu-native was already stripped, this will prevent future debugging!
ERROR: qemu-native-2.7.0-r1 do_populate_sysroot: runstrip: ''strip' --remove-section=.comment --remove-section=.note '/.../build/tmp/work/x86_64-linux/qemu-native/2.7.0-r1/sysroot-destdir/.../build/tmp/sysroots/x86_64-linux/usr/share/qemu/palcode-clipper'' strip command failed with 1 (b"strip: Unable to recognise the format of the input file `/.../build/tmp/work/x86_64-linux/qemu-native/2.7.0-r1/sysroot-destdir/.../build/tmp/sysroots/x86_64-linux/usr/share/qemu/palcode-clipper'\n")
This is the second error, which I think is caused by the first one.
ERROR: gcc-runtime-6.2.0-r0 do_compile: oe_runmake failed
ERROR: gcc-runtime-6.2.0-r0 do_compile: Function failed: do_compile (log file is located at /.../build/tmp/work/armv7vehf-neon-vfpv4-agl-linux-gnueabi/gcc-runtime/6.2.0-r0/temp/log.do_compile.30447)
ERROR: Logfile of failure stored in: /.../build/tmp/work/armv7vehf-neon-vfpv4-agl-linux-gnueabi/gcc-runtime/6.2.0-r0/temp/log.do_compile.30447
NOTE: recipe gcc-runtime-6.2.0-r0: task do_compile: Failed
ERROR: Task (/.../poky/meta/recipes-devtools/gcc/gcc-runtime_6.2.bb:do_compile) failed with exit code '1'
I found this thread of someone having the same issue, but there is no fix there, so I thought I'd ask it again, because this issue still persist.
I can see that there is a problem with the stripping of files, but I can't find where to fix this in the recipes.
I'm not sure if this error is caused by the used host system or if it's dependant on the recipes.
I hope someone knows a fix to this issue.
Thanks in advance
Laurens Wuyts
EDIT:
Here is the log file of the gcc error: https://www.dropbox.com/s/4hd5kzgbadhdc9p/log.do_compile.30447?dl=0
Here is the specific error message on pastebin:
https://pastebin.com/H8M3sY6a
I can't run node.js on PowerPC 440EP, I get only error "Illegal instruction".
Hardware info:
cat /proc/cpuinfo
processor : 0
cpu : 440EP Rev. C
clock : 533.333332MHz
revision : 24.212 (pvr 4222 18d4)
bogomips : 1066.66
timebase : 533333332
platform : CPU440EP
model : micran,cpu440
Memory : 128 MB
LD_SHOW_AUXV=1 /bin/true
AT_DCACHEBSIZE: 0x20
AT_ICACHEBSIZE: 0x20
AT_UCACHEBSIZE: 0x0
AT_SYSINFO_EHDR: 0x100000
AT_HWCAP: booke mmu fpu ppc32
AT_PAGESZ: 4096
AT_CLKTCK: 100
AT_PHDR: 0x10000034
AT_PHENT: 32
AT_PHNUM: 8
AT_BASE: 0x48000000
AT_FLAGS: 0x0
AT_ENTRY: 0x1000446c
AT_UID: 0
AT_EUID: 0
AT_GID: 0
AT_EGID: 0
AT_SECURE: 0
AT_RANDOM: 0xbf8c04f2
AT_EXECFN: /bin/true
AT_PLATFORM: ppc440
AT_BASE_PLATFORM:ppc440
Software info:
I'm using powerpc-440-linux-gnu compiler (version 5.2.0) and Linux v3.6.7.
I tried to use different versions of sources:
*node-0.10-ppc* from https://github.com/ibmruntimes/node
*node-4.x-port* from https://github.com/ibmruntimes/node
*node-v4.4.7* from https://nodejs.org/dist/v4.4.7/node-v4.4.7.tar.gz
*node-6.x* from https://github.com/nodejs/node
I'm using the following script for build of node.js:
#!/bin/bash
CROSS_COMPILER=powerpc-440-linux-gnu
HOST=powerpc-linux
ENDIAN=big
BUILD_PATH=/home/user/node
CFLAGS=-Os
JOBS=4
export ARCH=ppc
export CC=${CROSS_COMPILER}-gcc
export CXX=${CROSS_COMPILER}-g++
export CFLAG=${CFLAGS}
export AR=${CROSS_COMPILER}-ar r
export LINK=${CROSS_COMPILER}-g++
export PATH=${PATH}:/home/user/powerpc-440-linux-gnu/bin
./configure --without-snapshot --prefix=${BUILD_PATH} --dest-cpu=ppc --dest-os=linux
make -j ${JOBS}
make install
Which version of node.js should I use?
Do we have working portable
version of node.js for PowerPC 440EP ?
Sad update
I got the following answer from issues page on https://github.com/nodejs:
[Michael Dawson] The particular chip mentioned is based on the older PowerPC cores and does not have all of the Power5+ instructions available.
There are roughly two reasons for an illegal instruction. Either a memory corruption is derailing the control flow with the result that the CPU is trying to execute garbage/data.
The other reason would be that your node.js binary contains an instruction that isn't known to your CPU aka. your cross compiler output isn't matching your CPU. Investigate if you need to pass an additional -mcpu= or -mtune= argument to the compiler (or rather to configure).
As node.js contains a just in time compiler itself there is also the third option that node.js is generating instructions not suitable for you CPU variant.
I would investigate option two first.