I need to compile u-boot for my machine which is a 64 bits arm core with a 32-bit toolchain. The problem is that all
my other recipes use the 64 bits linaro toolchain. How can a tell bitbake to use the 32-bit linaro for the u-boot?
I've tried to add in my u-boot recipe things like:
UBOOT_ARCH = "arm"
PACKAGE_ARCH = "armv7a"
CROSS_COMPILE="arm-poky-linux-gnueabi-"
but nothing seems to work. It continues using aarch64-poky-linux-gcc to compile u-boot. My recipe at the moment looks like this:
DESCRIPTION = "U-boot for mymachine"
require recipes-bsp/u-boot/u-boot.inc
LICENSE = "GPLv2"
COMPATIBLE_MACHINE = "mymachine"
UBOOT_MACHINE_mymachine = "mymachine_config"
UBOOT_ARCH_mymachine = "arm"
PACKAGE_ARCH = "armv7a"
CROSS_COMPILE="arm-poky-linux-gnueabi-"
SRC_URI = "git://github.com/mymachine/u-boot-mymachine.git;branch=master \
file://boot.cmd"
SRCREV="${AUTOREV}"
PV = "v2016.03"
(...)
My machine.conf has:
require conf/machine/include/arm64/arch-armv8.inc
Related
I'm trying to compile Cobalt and getting errors building cpu_features_get.cc. The specific version I'm building is here: https://github.com/Metrological/cobalt/blob/master/src/starboard/shared/linux/cpu_features_get.cc and it appears to be based on Cobalt 22. I'm building using stbgcc-6.3.18, only Ubuntu 20.04. Sysroot is set to the cross compiler. And I'm building the starboard port at https://github.com/Metrological/cobalt/tree/master/src/third_party/starboard/wpe/brcm/arm, for ARM64.
An example of the error:
cpu_features_get.cc:381:12: error: 'HWCAP_SET_FOR_ARMV8' was not declared in this scope
There follow others, all related to HWCAP #defines.
As far as I can tell, the file defines these values if:
53: #if SB_IS(32_BIT) || defined(ANDROID)
Neither of these is true - I am compiling for ARM64 on Linux.
The code using HWCAP_SET_FOR_ARMV8 and the other missing defines is conditionally compiled as well:
340: #if SB_IS(ARCH_ARM) || SB_IS(ARCH_ARM64)
...
// Construct hwcap bitmask by the feature flags in /proc/cpuinfo
uint32_t ConstructHwcapFromCPUInfo(ProcCpuInfo* cpu_info,
int16_t architecture_generation,
uint32_t hwcap_type) {
if (hwcap_type == AT_HWCAP && architecture_generation >= 8) {
// This is a 32-bit ARM binary running on a 64-bit ARM64 kernel.
// The 'Features' line only lists the optional features that the
// device's CPU supports, compared to its reference architecture
// which are of no use for this process.
SB_LOG(INFO) << "Faking 32-bit ARM HWCaps on ARMv"
<< architecture_generation;
return HWCAP_SET_FOR_ARMV8;
}
...
...
So ARCH_ARM64 is true, and this code is compiled. But the defines are missing because it's not 32-bit. This seems contradictory and to my eyes could never have worked. How is it possible to compile Cobalt for ARM64?
we are using Linux kernel 5.4 with gcc 9.1.0 on different architectures (arm, arm64, x86_64). I am in charge of creating code coverage for kernel modules. I am not selecting the Linux kernel version nor the compiler version.
I am able to create code coverage for arm/arm64 and see the results in /sys/kernel/debugfs/gcov/... as usual. Also, loaded modules are visible in the gcov subdirectory.
However, for x86_64, I on only see /sys/kernel/debubfs/gcov/reset and nothing else, even if I set CONFIG_GCOV_COVERAGE_ALL=y.
The __gcov_init in kernel/gcov/base.c normally creates a
pr_info("version magic=...")
which is visible on arm/arm64 at boot time but not for x86_64. __gcov_init should be called for every source file as a gcc constructor and the first call creates the version magic message.
It seems to me that in my combination the code coverage function __gcov_init is never called in x86_64.
In the config, I use
CONFIG_GCOV_PROFILE=y
CONFIG_GCOV_FORMAT_4_7=y
and sometimes only for x86 CONFIG_GCOV_PROFILE_ALL=y. Nothing besides the "reset" file is visible /sys/kernel/debug/gcov/... for x86.
Any suggestions are welcome.
Code coverage constructors are now written in a ".ctors.65435" section (the number is possibly a constructor priority), but kernel 5.4 only knows ".ctors".
For the kernel internal code coverage, the following change (already in later kernels, e.g. 5.12) brings back code coverage
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
## -631,6 +631,7 ##
#ifdef CONFIG_CONSTRUCTORS
#define KERNEL_CTORS() . = ALIGN(8); \
__ctors_start = .; \
+ KEEP(*(SORT(.ctors.*))) \
KEEP(*(.ctors)) \
KEEP(*(SORT(.init_array.*))) \
KEEP(*(.init_array)) \
However, kernel/module.c does not know ".ctors.65435" either, and the modules compiled with gcc9 or gcc10 do not have a ".ctors" ELF sections. So I just changed as a HACK (!)
--- a/kernel/module.c
+++ b/kernel/module.c
## -3294,7 +3294,7 ## static int find_module_sections(struct module *mod, struct load_info *info)
mod->unused_gpl_crcs = section_addr(info, "__kcrctab_unused_gpl");
#endif
#ifdef CONFIG_CONSTRUCTORS
- mod->ctors = section_objs(info, ".ctors",
+ mod->ctors = section_objs(info, ".ctors.65435",
sizeof(*mod->ctors), &mod->num_ctors);
if (!mod->ctors)
mod->ctors = section_objs(info, ".init_array",
This brings back module code coverage, but
.ctors.* for modules is not known in the newest 5.x kernel, and so I think this should be fixed in the Linux Kernel module handling
Instead of hacking and use ".ctors.65435" in kernel/module.c instead of ".ctors", the proper solution is to change the module linker script to combine all ".ctors.*" section with the ."ctors" section:
diff --git a/scripts/module-common.lds b/scripts/module-common.lds
index d61b9e8678e8..0cd6aabaa460 100644
--- a/scripts/module-common.lds
+++ b/scripts/module-common.lds
## -20,6 +20,7 ## SECTIONS {
__kcrctab_unused_gpl 0 : { *(SORT(___kcrctab_unused_gpl+*)) }
__kcrctab_gpl_future 0 : { *(SORT(___kcrctab_gpl_future+*)) }
+ .ctors 0 : ALIGN(8) { *(SORT(.ctors.*)) *(.ctors) }
.init_array 0 : ALIGN(8) { *(SORT(.init_array.*)) *(.init_array) }
__jump_table 0 : ALIGN(8) { KEEP(*(__jump_table)) }
--
2.29.2
This brings back the code coverage for modules.
I am trying to create a recipe in yocto to build a package for SDK - https://github.com/nodejs/http-parser
Here is my http-parser.bb. However, when I am trying to build using - "-c populate_sdk", I get the error that no Makefile found.
What am I missing here? My source code has Makefile. I am following the book by Rudolf - Yocto book and I can't see anything except adding the following from chapter 8 - Software package recipe.
do_install() {
oe_runmake install PREFIX=${D}
}
Here is my recipe file.
SUMMARY = "http-parser"
DESCRIPTION = "This is a parser for HTTP messages written in C. It parses both requests and responses. The parser is designed to be used in performance HTTP applications. It does not make any syscalls nor allocations, it does not buffer data, it can be interrupted at anytime. Depending on your architecture, it only requires about 40 bytes of data per message stream (in a web server that is per connection)."
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE-MIT;md5=9bfa835d048c194ab30487af8d7b3778"
SRC_URI[md5sum] = "59f8fce33369f2ef2a45f46b6b5420bc"
SRC_URI[sha256sum] = "865e0ec42f3c0a949654ebff98d538dd828a239392b502d42e15cb1e5bb28895"
SRCREV = "${AUTOREV}"
PV = "r${SRCREV}"
PR = "r2"
ALLOW_EMPTY_${PN} = "1"
SRC_URI = "https://github.com/nodejs/http-parser.git"
S = "${WORKDIR}/git"
PARALLEL_MAKE = ""
After running bitbake, I get an error no Makefile found.
I am currently migrating from Poky Fido to Sumo. We have a few custom recipes in a separate layer (meta-user) which contains a busybox_1.23.2.bb recipe customized to the needs and derived from the Fido layer. After migrating to Sumo, I am trying to build this recipe, but now it fails at do_compile (Link to the log file is below).
https://pastebin.com/yYXJnC2e
Here is the Build Configuration:
Build Configuration:
BB_VERSION = "1.37.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal-4.8"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "arm-cortex-a8"
DISTRO = "poky"
DISTRO_VERSION = "2.5"
TUNE_FEATURES = "arm armv7a vfp neon callconvention-hard cortexa8"
TARGET_FPU = "hard"
meta-networking
meta-python = "master:45ee3c0e98bd3ed81419aaeae1e7324e486161a2"
meta-userbsp-ti
meta
meta-poky
meta-yocto-bsp
meta-user-common = "<unknown>:<unknown>"
meta-oe = "master:45ee3c0e98bd3ed81419aaeae1e7324e486161a2"
workspace = "<unknown>:<unknown>"
NOTE: Host OS is CentOS_7.1
Both limits.h and byteswap.h don't exist in Poky-Fido as well, but compiles without problems, unlike on Sumo. Does this have to do with the wrong Toolchains used or due to glibc (FYI: glibc_2.27 is been used)? If it has to do with the Toolchains, which one should I be using and how do I go about it?
Thanks in advance!
I'm trying to create a shared library from Haskell source code.
I've tried following the instruction here: http://weblog.haskell.cz/pivnik/building-a-shared-library-in-haskell/ but I'm just not having any luck.
When I compile with Haskell 64-bit (ghc 7.0.4 from 2011.4.0.0) I get the following error:
ld: pointer in read-only segment not allowed in slidable image, used in
___gmpn_modexact_1c_odd
As an alternative I also tried the 32-bit version, and depending on the exact flags I use to link get errors such as:
Library not loaded: /usr/local/lib/ghc-7.0.4/base-4.3.1.0/libHSbase-4.3.1.0-ghc7.0.4.dylib
I did manage to get a little further by adding -lHSrts to the linker line. This got me to the point of successfully linking and loading the library, but I'm then unable to find the function name using dlsym (or manually using nm | grep)
Any hints would be greatly appreciated, an example make file, or build line that has successfully built (and used) a shared library on OS X would be appreciated. I'm quite new to Haskell and don't know if I should keep banging my head assuming that the problem is on my end, or for various reasons I shouldn't expect this to work on OS X.
A git repo with all the combinations I've tried is available here: https://github.com/bennoleslie/haskell-shared-example I did manage to get something working for 32-bit ghc, but not 64-bit yet.
It is possible to create working shared libraries on 64-bit OS X, with the latest Haskell Platform release (2012.4 64bit)
The invocation line works for me:
ghc -O2 --make \
-no-hs-main -optl '-shared' -optc '-DMODULE=Test' \
-o libTest.so Test.hs module_init.c
module_init.c should be something like:
#define CAT(a,b) XCAT(a,b)
#define XCAT(a,b) a ## b
#define STR(a) XSTR(a)
#define XSTR(a) #a
#include <HsFFI.h>
extern void CAT(__stginit_, MODULE)(void);
static void library_init(void) __attribute__((constructor));
static void library_init(void)
{
/* This seems to be a no-op, but it makes the GHCRTS envvar work. */
static char *argv[] = { STR(MODULE) ".so", 0 }, **argv_ = argv;
static int argc = 1;
hs_init(&argc, &argv_);
hs_add_root(CAT(__stginit_, MODULE));
}
static void library_exit(void) __attribute__((destructor));
static void library_exit(void)
{
hs_exit();
}
This git repo: https://github.com/bennoleslie/haskell-shared-example contains a working example.
All credit goes to this original source: http://weblog.haskell.cz/pivnik/building-a-shared-library-in-haskell/
You might want to try the ghc port in Homebrew -- https://github.com/mxcl/homebrew/blob/master/Library/Formula/ghc.rb