Interchangeability of compiled LKMs - android

Is it possible, to use a Loadable Kernel Module, compiled for 3.0.8+ mod_unload ARMv5 (my self-make'd kernel) in a kernel with version 3.0.31-gd5a18e0 SMP preempt mod_unload ARMv7 (android stock-kernel)?
The module itself contains nearly nothing, just
// Defining __KERNEL__ and MODULE allows us to access kernel-level code not usually available to userspace programs.
#undef __KERNEL__
#define __KERNEL__
#undef MODULE
#define MODULE
// Linux Kernel/LKM headers: module.h is needed by all modules and kernel.h is needed for KERN_INFO.
#include <linux/module.h> // included for all kernel modules
#include <linux/kernel.h> // included for KERN_INFO
#include <linux/init.h> // included for __init and __exit macros
MODULE_AUTHOR("martin");
MODULE_LICENSE("GPL");
static int __init hello_init(void)
{
//printk(KERN_INFO "Hello world!\n");
return 0; // Non-zero return means that the module couldn't be loaded.
}
static void __exit hello_cleanup(void)
{
//printk(KERN_INFO "Cleaning up module.\n");
}
module_init(hello_init);
module_exit(hello_cleanup);
I'm forcing the insmod but then the kernel-crashes:
<1>[ 328.025360] Unable to handle kernel NULL pointer dereference at
virtual address 00000061 <1>[ 328.025695] pgd = c1be8000 <1>[
328.025848] [00000061] *pgd=00000000 <0>[ 328.026184] Internal error: Oops: 5 [#1] PREEMPT SMP <4>[ 328.026519] Modules linked in:
airstream_interceptor(+)
I use
CROSS_COMPILE=/home/adminuser/WORKING_DIRECTORY/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-
KDIR ?= /home/adminuser/WORKING_DIRECTORY/android-3.0
ARCH=arm
for both building the kernel and now building module. But the system on it should be inserted uses it's own factory kernel.
I try to build a kernel modul which can be used on several android-phones (arm,armv5,armv7 and so on) but I want to use 1 for all (if this is possible in any way).
(edit)
CONCLUSION #1
it should not be possible to compile one version for all ARM-devices:
compile LKM for kernel 3.0.8 for ARMv5 and use it on a kernel 3.0.39 ARMv7
it may (untested at the moment!) be possible, to compile on the lowest level (ARMv5) and use it in higher levels (ARMv6, ARMv7)
compile LKM for kernel 3.0.8 for ARMv5 and use it on a kernel 3.0.8 ARMv7
it may be possible to interchange the kernel-versions (maybe if simple LKM)
compile LKM for kernel 3.0.8 for ARMv5 and use it on a kernel 3.0.39 ARMv5
Open questions at the moment:
1.)
I tried (with common-kernel 3.0.8 and omap-kernel 3.0.39) to build for ARMv7 but the result is always a ARMv5-LKM.
I manually edited the .config, removed the ARMv5-line and added the ARMv7-line (which was nowhere in the .config):
#CONFIG_CPU_32v5=y # I added the #
CONFIG_CPU_V7=y # didn't exist
CONFIG_CPU_32v7=y # didn't exist
but if I then re-run "make" on the kernel-source, the file get's automatically edited and my v7-config where removed.
Some months ago, I remember this was no problem, I just added the 2 lines and it worked.
Is this a thing of the kernel-source or the used toolchain?
2.)
What is the difference between e.g. the "omap-kernel" and the "common-kernel" in view of the LKM-building? Just an other kernel-version (e.g. common-kernel has now 3.0.53 and omap-kernel 3.0.39)? I think I can "ignore" the specific variants and use the common-kernel for LKM-compiling?
Many thanks to alkalinity, auselen & Marko at the moment - you're helping me out of the mud.

You can't use the same binary driver with different versions of Linux.
Linux does not have a binary kernel interface, nor does it have a stable kernel interface. (source)

No, this isn't possible. The Linux kernel is architecture-specific, and ARMv5 modules are not compatible with ARMv7. There are different header files needed, which will have different instruction sets, or register mappings, or any number of important variants.
In any event, the kernel versions are different in this case too, which means that the kernel API can vary, and therefore the kernel module will not work in all likelihood, even if the architecture were the same.
You'll have to cross-compile separate versions of your kernel module. This isn't too difficult if you have access to the whole kernel tree. The manufacturer should have released their kernel sources (as per the GPL). If they have not, they owe you sources.
If you're interested in reading up on the specifics of loading kernel modules, IBM has a great "anatomy" series of articles. Here's on on loadable kernel modules. Jump to the section on "module loading details" to understand why the kernel rejects insertion of your module in the absence of the force-load.

Related

Reducing AOSP kernel image size

I am trying to build an AOSP kernel, but I can't make the resulting boot.img small enough to flash and boot it. It contains the compressed kernel with appended dtbs and the initramfs. My intention is to fuzz-test drivers using Syzkaller. I'm currently using a Pixel XL (marlin). I use kernel branch android-msm-marlin-3.18-pie-qpr3 (tried related ones as well) and I'm trying various gcc-based toolchains. For AOSP I picked Pie (tag android-9.0.0_r46, build PQ3A.190801.002). However, please note that this is a general question, it's not fuzzing-, kernel- or device-specific.
My requirements are:
Keep vendor-introduced drivers (because they are what I want to fuzz)
Enable KASAN and KCOV (and their dependencies)
Enable CONFIG_DEBUG_INFO
Keep printk and the like
Things I tried and ideas I have:
Tuning kernel config - This helps to some extend, but it's just not enough. I'm already using for example CONFIG_CC_OPTIMIZE_FOR_SIZE=y, CONFIG_CORE_SMALL=y, CONFIG_NET_SMALL=y, CONFIG_KASAN_OUTLINE=y, CONFIG_TRIM_UNUSED_KSYMS=y, CONFIG_SLOB=y, ...
Compress kernel (and/or initramfs) with xz or lzma - The idea seems promising. I noticed the kernel build system for arm64 neither supports xz nor lzma out of the box (not sure why?), so I patched it myself to get it building. The build succeeds and the resulting Image.xzkern-dtb or Image.lzma-dtb seems okay, however when attempting to boot it (serial debugging logs):
[5710] partition_enable_wp: group 0 not defined
[5720] DTB offset is incorrect, kernel image does not have appended DTB
[5720] Device info 0x00000131/00010001/0x00010001/0, pmic 0x20009/0x455013/0x0/0x0
[5740] ERROR: Appended Device Tree Blob not found
[5740] panic (frame 0x83a86848):
...
I verified that the DTBs are present and the kernel is compressed as intended. My question here: Is it possible at all? Does the Android bootloader even support xz/lzma? I hardly found any info about that online. Is there any way to use xz or lzma compressed kernels to boot Android?
Resize the boot partition - It seems difficult but possible, not sure if worth attempting. Can you recommend any resources or tools for that?
Removing unnecessary features from initramfs
Link-Time Optimization - I could not get it to work with the AOSP kernel, no matter what gcc version I use. Any tips?
Building features as modules instead of built-in - The build won't succeed with any config I try, even when building only single features as module (with different compiler or linker errors depending on the config). Do you have any guides or tips?
I also followed the tutorial on building a Pixel kernel with KASAN and KCOV on the AOSP homepage (link). I had some problems with it, but eventually (using Linaro GCC 5.5.0, with some config changes and without CONFIG_DEBUG_INFO) I could get it building and booting. Nice as a proof-of-concept but not what I need, since I had to skip some required features.
I'm pretty much stuck and already spent some weeks on that problem. Are there any other options? I'd be happy to get it booting in any way. I'll happily provide any details and logs, but felt like it's already a very long post. Thank you a lot in advance!
I found a solution working for me. It's a close call though, probably not enough size reduction for different situations. Anyways, it might help others.
I'm using pigz instead of the default gzip tool, which offers an even higher compression level with the -11 switch. Increasing the number of optimization iterations with -I 45 further improved it (default is 15). This squeezes out the last bit that I need: The resulting Image.gz-dtb is about 2.5% smaller than before.
These are the changes I made to the kernel build system (assuming pigz will be in your PATH at build time):
diff --git a/arch/arm64/boot/Makefile b/arch/arm64/boot/Makefile
index b7cf2a498c19..7dfd438e997b 100644
--- a/arch/arm64/boot/Makefile
+++ b/arch/arm64/boot/Makefile
## -30,7 +30,8 ## $(obj)/Image: vmlinux FORCE
$(call if_changed,objcopy)
$(obj)/Image.gz: $(obj)/Image FORCE
- $(call if_changed,gzip)
+# $(call if_changed,gzip)
+ $(call if_changed,pigz)
$(obj)/Image.lz4: $(obj)/Image FORCE
$(call if_changed,lz4)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index c2b437eb23d5..73d4581f7531 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
## -272,6 +272,11 ## quiet_cmd_gzip = GZIP $#
cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -n -f -9 > $#) || \
(rm -f $# ; false)
+
+quiet_cmd_pigz = PIGZ $#
+cmd_pigz = (cat $(filter-out FORCE,$^) | pigz -n -f -11 -I 45 > $#) || \
+ (rm -f $# ; false)
+
# DTC
# ---------------------------------------------------------------------------
It flashes and boots fine, even boots in a reasonable time, as opposed to what I had before.

Missing Kernel DTB after creating signed Android images

I'm porting android to a display device, and have nearly completed this. The device use the Freescale/NXP i.MX6 Dual Lite Soc. The Android version used is Android 8.0.0, and the build is based on the Board Support Packages from NXP/Freescale (link below).
https://www.nxp.com/support/developer-resources/software-development-tools/i.mx-developer-resources/android-os-for-i.mx-applications-processors:IMXANDROID?tab=Design_Tools_Tab
The OS builds fine, and the images (u-boot, boot.img, system.img, vendor.img) resuling from the "make" process works perfercly fine on the device. So my last step is basically to sign the images, and this is where I struggle to get stuff working.
I am following the the guide found here:
https://source.android.com/devices/tech/ota/sign_builds
After completing the steps, I use the now signed images found in the "signed-img.zip" file to flash the device (using the NXP Manufacturing Tool, and not Fast Boot). However, the device now fails to boot the Kernel, giving me an error that the DTB is missing.
Hit any key to stop autoboot: 0
boota mmc0
kernel # 14008000 (8183104)
ramdisk # 15000000 (2036048)
## Booting Android Image at 0x12000000 ...
Kernel load addr 0x14008000 size 7992 KiB
Kernel command line: console=ttymxc0,115200 init=/init video=mxcfb0:dev=ldb video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off vmalloc=128M androidboot.console=ttymxc0 consoleblank=0 ldo_active=on androidboot.hardware=sedevices cma=448M android.selinux=permissive android.dm_verify=disable androidboot.selinux=enforce androidboot.dm_verity=disable androidboot.storage_type=emmc loglevel=8 vt.global_cursor_default=0 buildvariant=userdebug androidboot.serialno=0b2861d4df668b47 androidboot.soc_type=imx6dl androidboot.storage_type=emmc
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
resetting ...
I've narrowed the problem down to the very first step in the guide, where "make dist" is executed in the build directory. This produces a number of ZIP files in the "out/dist" folder, which is processed further in the following steps in the guide. I've tried flashing the device with the images produced in this step (found in the resulting "out/dist/*-img-*.zip" file), and this produces the exact same issue.
So my question is, what does really "make dist" do which cause the DTB to be missing in the "boot.img"? I would've expected it to use the already working "boot.img" found in "out/target/product//". But it instead seems to re-build this image, and in this case not include the DTB. As with so many other aspects of building Android from Source, the workings of "make dist" does not seem to be explained anywhere in the documentation.
I hope anyone with some experience in building Android from source knows something about this, because I seem to be royally stuck.
Just FYI; when I flash the "boot.img" produced after a normal "make", the output after U-boot is as follows:
Hit any key to stop autoboot: 0
boota mmc0
Error: blob decap job completed with errors 0x2000081A
In boota get fastboot lock status error. Set lock status
kernel # 14008000 (8183104)
ramdisk # 15000000 (2036754)
fdt # 14f00000 (40998)
## Booting Android Image at 0x12000000 ...
Kernel load addr 0x14008000 size 7992 KiB
Kernel command line: console=ttymxc0,115200 init=/init video=mxcfb0:dev=ldb video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off vmalloc=128M androidboot.console=ttymxc0 consoleblank=0 ldo_active=on androidboot.hardware=sedevices cma=448M android.selinux=permissive android.dm_verify=disable androidboot.selinux=enforce androidboot.dm_verity=disable androidboot.storage_type=emmc loglevel=8 vt.global_cursor_default=0 buildvariant=userdebug androidboot.serialno=0b2861d4df668b47 androidboot.soc_type=imx6dl androidboot.storage_type=emmc
## Flattened Device Tree blob at 14f00000
Booting using the fdt blob at 0x14f00000
Loading Kernel Image ... OK
Using Device Tree in place at 14f00000, end 14f0d025
switch to ldo_bypass mode!
Starting kernel ...
It seem NXP/Freescale have modified the Build Scripts in their AOSP Board Support Package, and broken the DTB inclusion in the process. It may seem like they where happy when the output from the standard "make" process worked on their Dev Board, and never bothered checking if it was possible to create working signed Release images with it.
The mechanism to include a DTB in the dist package was in place (specifying the location of the DTB in BOARD_KERNEL_DTS), and was also used for their "make otapackage" target. However, that target only generates an unsigned (or signed with dev keys) OTA package, which can not be used with the signing scripts.
In order to make it work as it should, I had to make a small change in the main Makefile which specifies the location of the DTB defined in the BoardConfig.mk. The change was simple enough to make, but the hard part was figuring out where the problem was and how it was intended to work in the first place.
The following patch in "build/make/" fixes the issue, as long as a BoardConfig.mk ONLY specifies one DTB (which at least suits my needs):
diff --git a/core/Makefile b/core/Makefile
index a650565a1..92f3025a9 100644
--- a/core/Makefile
+++ b/core/Makefile
## -621,6 +621,19 ## ifdef INTERNAL_KERNEL_CMDLINE
INTERNAL_BOOTIMAGE_ARGS += --cmdline "$(INTERNAL_KERNEL_CMDLINE)"
endif
+# NOTE! This script has a defect which cause the kernel DTB to be left out when ever 'make dist'
+# is executed. The following addition "fixes" this by adding the first dtb specified in the
+# BoardConfig.mk file. (I would guess in most cases there is never more than one!)
+ifdef dist_goal
+ifndef BOARD_KERNEL_DTS
+ifdef TARGET_BOARD_DTS_CONFIG
+DTS_BOARD=$(word 2, $(subst :, ,$(word 1, $(TARGET_BOARD_DTS_CONFIG))))
+BOARD_KERNEL_DTS="$(KERNEL_OUT)/$(DTS_BOARD)"
+$(info FIXUP: Defining BOARD_KERNEL_DTS:=[$(BOARD_KERNEL_DTS)] for BOOT packaging)
+endif
+endif
+endif
+
INTERNAL_MKBOOTIMG_VERSION_ARGS := \
--os_version $(PLATFORM_VERSION) \
--os_patch_level $(PLATFORM_SECURITY_PATCH)

Having LLVM IR library how to crosscompile it to iOS, Android, Windows and Mac from Ubuntu?

I have representations of all my dependencies and my library in LLVM IR forms. How to cross-compile my library into a shared object for iOS, Android, Windows and Mac platforms from Linux ( Ubuntu for example )?
Please provide a single example script that would compile any example library with at least one dependency on to another library of your choice to all 4 platforms ( for example OpenCV or ZeroMQ 4+ ).
Using the LLVM static compiler (llc), you can compile the LLVM IR into object files for a specific target triple. Though the target triples are not documented very well, the LLVM infrastructure is all open source, so a quick search through the source code will lead you here.
Unfortunately, there is no documentation for a discrete list of possible target triples you can use. However, if you know exactly what system you're targeting, constructing a triple is fairly easy. Taken from the target triple documentation, you can see :
The triple has the general format <arch><sub>-<vendor>-<sys>-<abi>,
where:
arch = x86_64, i386, arm, thumb, mips, etc.
sub = for ex. on ARM: v5, v6m, v7a, v7m, etc.
vendor = pc, apple, nvidia, ibm, etc.
sys = none, linux, win32, darwin, cuda, etc.
abi = eabi, gnu, android, macho, elf, etc.
Once you figure out what target triple you're using, you specify it as a string using the -mtriple flag. Here are some examples:
Windows: -mtriple=i686-pc-win32-gnu
Linux: -mtriple=i686-pc-linux-gnu
IOS: -mtriple=armv7-apple-ios
Android: -mtriple=arm-linux-androideabi
Next, you need to specify that you want to compile an object file using the filetype flag:
-filetype=obj
This should be enough if I understand your question correctly.
If you're expecting to use a single file on all platforms and operating systems, while this is possible, it would take a lot of work and I wouldn't expect an answer regarding that here on stackoverflow.
From this link, There is a Variable LLVM_TARGETS_TO_BUILD and the definition says that
A semicolon delimited list controlling which targets will be built and linked into llc. This is equivalent to the --enable-targets option in the configure script. The default list is defined as LLVM_ALL_TARGETS, and can be set to include out-of-tree targets. The default value includes: AArch64, AMDGPU, ARM, BPF, Hexagon, Mips, MSP430, NVPTX, PowerPC, Sparc, SystemZ, X86, XCore.
You should add the X86 and ARM is present in it. you need to add support for 64 and Apple
From this link
It is possible to cross compile
The example command looks like
% cmake -G "Ninja" -DCMAKE_OSX_ARCHITECTURES="armv7;armv7s;arm64"
-DCMAKE_TOOLCHAIN_FILE=<PATH_TO_LLVM>/cmake/platforms/iOS.cmake
-DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_RUNTIME=Off -DLLVM_INCLUDE_TESTS=Off
-DLLVM_INCLUDE_EXAMPLES=Off -DLLVM_ENABLE_BACKTRACES=Off [options]
<PATH_TO_LLVM>
Also I would like to share this link. It says
The basic option is to define the target architecture. For that, use -target . If you don’t specify the target, CPU names won’t match (since Clang assumes the host triple), and the compilation will go ahead, creating code for the host platform, which will break later on when assembling or linking.
The triple has the general format <arch><sub>-<vendor>-<sys>-<abi>, where:
arch = x86_64, i386, arm, thumb, mips, etc.
sub = for ex. on ARM: v5, v6m, v7a, v7m, etc.
vendor = pc, apple, nvidia, ibm, etc.
sys = none, linux, win32, darwin, cuda, etc.
abi = eabi, gnu, android, macho, elf, etc.

Crosscompile Perl for Android x86

I like to crosscompile Perl for the Android x86 emulator. But I got a PIE (position independent executables) error on running Configure... Based on this and this tutorial.
Specs:
NDK version 14
Perl 5.22.1.
x86 Android emulator built with AOSP - Android 7.1.1
I set following variables:
export ANDROID_NDK=/home/fabian/Android/Sdk/ndk-bundle
export TARGET_ARCH=x86
export ANDROID_TOOLCHAIN=/tmp/toolchain-x86
export SYSROOT=$ANDROID_TOOLCHAIN/sysroot
export TARGETDIR=/data/local/perl
export GCC=i686-linux-android-gcc
export PATH=$PATH:$ANDROID_NDK/toolchains/x86-4.9/prebuilt/linux-x86_64/bin
Then I build the toolchain with following command:
$ANDROID_NDK/build/tools/make-standalone-toolchain.sh --platform=android-23 --install-dir=$ANDROID_TOOLCHAIN --toolchain=x86-4.9
and get this (correct?) output:
HOST_OS=linux
HOST_EXE=
HOST_ARCH=x86_64
HOST_TAG=linux-x86_64
HOST_NUM_CPUS=4
BUILD_NUM_CPUS=8
Auto-config: --arch=x86
Toolchain installed to /tmp/toolchain-x86.
Then I start the ./Configure command:
./Configure -des -Dusedevel -Dusecrosscompile -Dtargetrun=adb -Dcc=i686-linux-android-gcc -Dsysroot=$SYSROOT -Dtargetdir=$TARGETDIR -Dtargethost=emulator-5554
and got this output:
First let's make sure your kit is complete. Checking...
Would you like to see the instructions? [n]
Locating common programs...
Checking compatibility between /bin/echo and builtin echo (if any)...
Symbolic links are supported.
Checking how to test for symbolic links...
You can test for symbolic links with 'test -h'.
Using targetarch i686-linux-android.
Using targethost emulator-5554.
Building host miniperl and generate_uudmap binaries
Using targethost emulator-5554.
Guessing targetuser root.
Guessing targetport 22.
Using '/home/fabian/Desktop/Testimages/perl-5.22.1/Cross/run-adb' for remote execution,
and '/home/fabian/Desktop/Testimages/perl-5.22.1/Cross/from-scp' and '/home/fabian/Desktop/Testimages/perl-5.22.1/Cross/to-scp'
for remote file transfer.
Good, your tr supports [:lower:] and [:upper:] to convert case.
Using [:upper:] and [:lower:] to convert case.
aix_3 dragonfly irix_4 nonstopux stellar
aix_4 dynixptx irix_5 openbsd sunos_4_0
aix dynix irix_6_0 opus sunos_4_1
altos486 epix irix_6_1 os2 super-ux
amigaos esix4 irix_6 os390 svr4
atheos fps isc_2 os400 svr5
aux_3 freebsd isc posix-bc ti1500
bitrig freemint linux-android powerux ultrix_4
bsdos genix linux qnx umips
catamount gnukfreebsd lynxos riscos unicosmk
convexos gnuknetbsd midnightbsd sco_2_3_0 unicos
cxux gnu mips sco_2_3_1 unisysdynix
cygwin greenhills mirbsd sco_2_3_2 utekv
darwin haiku mpc sco_2_3_3 uwin
dcosx hpux ncr_tower sco_2_3_4 vos
dec_osf i386 netbsd sco
dos_djgpp interix newsos4 solaris_2
Which of these apply, if any? [linux-android]
"./a.out": error: only position independent executables (PIE) are supported.
Aborted
You don't have an ELF gcc. I will use dld if possible. If you are
using a version of DLD earlier than 3.2.6, or don't have it at all, you
should probably upgrade. If you are forced to use 3.2.4, you should
uncomment a couple of lines in hints/linux.sh and restart Configure so
that shared libraries will be disallowed.
Disabling ndbm. This will generate a Whoa There message in Configure.
Read hints/linux.sh for further information.
Operating system name? [linux-android]
Operating system version? [7.1.1]
Installation prefix to use? (~name ok) [/usr/local]
AFS does not seem to be running...
What installation prefix should I use for installing files? (~name ok)
[/usr/local]
Getting the current patchlevel...
Build a threading Perl? [n]
Build Perl for multiplicity? [n]
Use which C compiler? [i686-linux-android-gcc]
Checking for GNU cc in disguise and/or its version number...
"./try": error: only position independent executables (PIE) are supported.
Aborted
Now, how can we feed standard input to your C preprocessor...
Directories to use for library searches?
[/tmp/toolchain-x86/sysroot/usr/lib/../lib /tmp/toolchain-x86/sysroot/usr/lib]
What is the file extension used for shared libraries? [sa]
Make shared library basenames unique? [n]
Hmm. Based on the hints in hints/linux-android.sh,
the recommended value for $d_libname_unique on this machine was "define"!
Keep the recommended value? [y]
Build Perl for SOCKS? [n]
Try to use long doubles if available? [n]
Checking for optional libraries...
What libraries to use? [-lm -lc]
What optimizer/debugger flag should be used? [-O2]
Any additional cc flags?
[-DOVR_DBL_DIG=14 --sysroot=/tmp/toolchain-x86/sysroot]
Let me guess what the preprocessor flags are...
Any additional ld flags (NOT including libraries)?
[ --sysroot=/tmp/toolchain-x86/sysroot]
Checking your choice of C compiler and flags for coherency...
I've tried to compile and run the following simple program:
#include
int main() { printf("Ok\n"); return(0); }
I used the command:
i686-linux-android-gcc -o try -O2 -DOVR_DBL_DIG=14 --sysroot=/tmp/toolchain-x86/sysroot --sysroot=/tmp/toolchain-x86/sysroot try.c -lm -lc
/home/fabian/Desktop/Testimages/perl-5.22.1/Cross/run-adb-shell ./try
and I got the following output:
The program compiled OK, but exited with status 134.
You have a problem. Shall I abort Configure [y]
Ok. Stopping Configure.
OK I have to set the flags
Modify config.sh to enable PIE support. Append “-fPIE” to ccflags and
“-fPIE -pie” to ldflags. Then rerun configure to ensure this is
applied.
But there is no config.sh in the perl folder, so I tried this ./Configure command:
`./Configure -des -Dusedevel -Dusecrosscompile -Dtargetrun=adb -Dcc=i686-linux-android-gcc -Dsysroot=$SYSROOT -Dtargetdir=$TARGETDIR -Dtargethost=emulator-5554 -Dccflags='-fPIE' Dldflags='-fPIE -pie'`
but same problem again...
First let's make sure your kit is complete. Checking...
Would you like to see the instructions? [n]
Locating common programs...
Checking compatibility between /bin/echo and builtin echo (if any)...
Symbolic links are supported.
Checking how to test for symbolic links...
You can test for symbolic links with 'test -h'.
Using targetarch i686-linux-android.
Using targethost emulator-5554.
Building host miniperl and generate_uudmap binaries
Using targethost emulator-5554.
Guessing targetuser root.
Guessing targetport 22.
Using '/home/fabian/Desktop/Testimages/perl-5.22.1/Cross/run-adb' for remote execution,
and '/home/fabian/Desktop/Testimages/perl-5.22.1/Cross/from-scp' and '/home/fabian/Desktop/Testimages/perl-5.22.1/Cross/to-scp'
for remote file transfer.
Good, your tr supports [:lower:] and [:upper:] to convert case.
Using [:upper:] and [:lower:] to convert case.
aix_3 dragonfly irix_4 nonstopux stellar
aix_4 dynixptx irix_5 openbsd sunos_4_0
aix dynix irix_6_0 opus sunos_4_1
altos486 epix irix_6_1 os2 super-ux
amigaos esix4 irix_6 os390 svr4
atheos fps isc_2 os400 svr5
aux_3 freebsd isc posix-bc ti1500
bitrig freemint linux-android powerux ultrix_4
bsdos genix linux qnx umips
catamount gnukfreebsd lynxos riscos unicosmk
convexos gnuknetbsd midnightbsd sco_2_3_0 unicos
cxux gnu mips sco_2_3_1 unisysdynix
cygwin greenhills mirbsd sco_2_3_2 utekv
darwin haiku mpc sco_2_3_3 uwin
dcosx hpux ncr_tower sco_2_3_4 vos
dec_osf i386 netbsd sco
dos_djgpp interix newsos4 solaris_2
Which of these apply, if any? [linux-android]
"./a.out": error: only position independent executables (PIE) are supported.
Aborted
You don't have an ELF gcc. I will use dld if possible. If you are
using a version of DLD earlier than 3.2.6, or don't have it at all, you
should probably upgrade. If you are forced to use 3.2.4, you should
uncomment a couple of lines in hints/linux.sh and restart Configure so
that shared libraries will be disallowed.
Disabling ndbm. This will generate a Whoa There message in Configure.
Read hints/linux.sh for further information.
Operating system name? [linux-android]
Operating system version? [7.1.1]
Installation prefix to use? (~name ok) [/usr/local]
AFS does not seem to be running...
What installation prefix should I use for installing files? (~name ok)
[/usr/local]
Getting the current patchlevel...
Build a threading Perl? [n]
Build Perl for multiplicity? [n]
Use which C compiler? [i686-linux-android-gcc]
Checking for GNU cc in disguise and/or its version number...
"./try": error: only position independent executables (PIE) are supported.
Aborted
Now, how can we feed standard input to your C preprocessor...
Directories to use for library searches?
[/tmp/toolchain-x86/sysroot/usr/lib/../lib /tmp/toolchain-x86/sysroot/usr/lib]
What is the file extension used for shared libraries? [sa]
Make shared library basenames unique? [n]
Hmm. Based on the hints in hints/linux-android.sh,
the recommended value for $d_libname_unique on this machine was "define"!
Keep the recommended value? [y]
Build Perl for SOCKS? [n]
Try to use long doubles if available? [n]
Checking for optional libraries...
What libraries to use? [-lm -lc]
What optimizer/debugger flag should be used? [-O2]
Any additional cc flags?
[-DOVR_DBL_DIG=14 -fPIE --sysroot=/tmp/toolchain-x86/sysroot]
Let me guess what the preprocessor flags are...
Any additional ld flags (NOT including libraries)?
[ --sysroot=/tmp/toolchain-x86/sysroot]
Checking your choice of C compiler and flags for coherency...
I've tried to compile and run the following simple program:
#include
int main() { printf("Ok\n"); return(0); }
I used the command:
i686-linux-android-gcc -o try -O2 -DOVR_DBL_DIG=14 -fPIE --sysroot=/tmp/toolchain-x86/sysroot --sysroot=/tmp/toolchain-x86/sysroot try.c -lm -lc
/home/fabian/Desktop/Testimages/perl-5.22.1/Cross/run-adb-shell ./try
and I got the following output:
"./try": error: only position independent executables (PIE) are supported.
Aborted
The program compiled OK, but exited with status 134.
You have a problem. Shall I abort Configure [y]
Ok. Stopping Configure.
But now the ccflag is set how you can see in the last lines...
Did I miss something?

How to compile Busybox?

(The i9100 and i9100p phones have Exynos 4210 SoC which includes Cortex A9 dual core 1.2Ghz processor which supports NEON.)
I will compile the latest busybox source snapshot available and upload it for everyone for free on internet and maybe even make my own free BusyboxInstaller.apk (I already downloaded today's 14th March snapshot from the official website) because so many busybox installers have very outdated versions and I want to take advantage of possible optimizations for the Cortex A9 cpu.
(NEON technology is a 128-bit SIMD (Single Instruction, Multiple Data) architecture extension.
It can can accelerate multimedia and signal processing algorithms such as video encode/decode, 2D/3D graphics, gaming, audio and speech processing, image processing, telephony, and sound synthesis.)
1 does such as mean it will also benefit my busybox?
2 What other instructions/anythingelse I can use to optimize for i9100 devices?
3 Can I compile on my phone instead of PC with only 1x2Ghz and 2GB RAM? I think it should be much quicker because it has 2x1.5GHz and 1GB RAM (I overclock only a bit) versus 1x2GHz, am I right?
4 How to compile busybox?
What are these options for?
Force NOMMU build
Additional CFLAGS
Additional LDFLAGS
Additional LDLIBS
all in general configuration and Busybox Library Tuning and debug (I googled for each for a few hours but nothing satisfactory)
What kind of applet links to install?
(./_install) BusyBox installation prefix
**I have eeror when following vinayhunachyai instructions.
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- install
/home/euphoria/Sourcery/busybox/scripts/gcc-version.sh: line 11: arm-none-linux-gnueabi-gcc: command not found
CC applets/applets.o
/bin/sh: 1: arm-none-linux-gnueabi-gcc: not found
scripts/Makefile.build:197: recipe for target 'applets/applets.o' failed
make[1]: *** [applets/applets.o] Error 127
Makefile:372: recipe for target 'applets_dir' failed
make: *** [applets_dir] Error 2
How to compile busybox?
1st download toolchain. You can refer to this: Advice regarding installing ARM toolchain on Ubuntu VM (64bit)
untar new source-code
create default config
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- defconfig
A default configuration file is created.
update config to change it to our needs:
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- menuconfig
The option to compile Busybox as a static executable, so that we don’t have to copy the dynamic libraries inside the root filesystem. The setting can be found in “Busybox Settings --> Build Options“.
Also, select what utilities you want embedded in Busybox.
Then, the following command builds Busybox and creates a directory called _install containing the root filesystem tree:
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- install.
Compile statically. If you compile dynamically then you need to copy libraries to target.
For more details see this link: http://balau82.wordpress.com/2010/03/27/busybox-for-arm-on-qemu/
For Android you can use config android_defconfig and build with examples/android-build.
I successfully used busybox patched by sherpya: his config sherpya_android_defconfig and slightly modified build script examples/android-build.

Categories

Resources