Get camera working on custom rom without selinux permissive - LG V30 Guides, News, & Discussion

I very recently decided to mod my wonderful, but neglected, LG V30. H933. By following the various guides, I unlocked the bootloader, installed twrp, rooted with magisk. Then using this thread https://forum.xda-developers.com/lg-v30/how-to/canadian-h933-compatibility-h930-roms-t3897586 prepared it for a Pie custom ROM (a tedious process, but it works just fine). I then installed LOS16 H930, no gapps. Using opencamera instead of gcam. All went well, but the camera/flashlight and a few of my user apps wouldn't work.
As many of you know, you can get the camera/flashlight working by setting selinux permissive. However, you need the permissions enabled at the boot/startup level. Executing setenforce 0 as root won't get the camera working in this situation. However, patching the kernel command line, which is what Kernel-Sepolicy-Patcher.zip does will do the trick. Unfortunately, this situation presents us with a dilemma. Running your device in selinux permissive full-time is a security risk one should not take. But having to boot into recovery, run a patcher, then reboot when you want to take a photo...and then repeating the process to go back to enforcing mode, is too tedious.
After spending days deep diving into the seemingly bottomless pit of android camera (a terrific learning experience), running through all the init scripts, services, selinux stuff, etc., etc. For a number of reasons, I never really found the exact solution I was looking for. Finally, I decided upon the following method to deal with the issue. Keep in mind that this still opens up security a little bit, but it's a helluva lot better than running SELinux *permissive* (i.e. no SElinux security at all). I performed most of the work on my arch linux system, but alternatively you can do this using an adb shell or a terminal app on the device.
WARNING / DISCLAIMER: If you mess up or brick your phone, it's on you. It's YOUR responsibility - not mine.
Directions:
1) Obtain a copy of your current boot partition:
Code:
dd if=/dev/block/bootdevice/by-name/boot of=/sdcard/boot.img
2) Copy boot.img to the PC's current directory:
Code:
adb pull /sdcard/boot.img
3) Use magisk's magiskboot utility to unpack boot.img (kernel, ramdisk, kernel dtb, etc):
Code:
./magiskboot unpack boot.img
4) Extract the sepolicy file from ramdisk.cpio:
Code:
./magiskboot cpio ramdisk.cpio "extract sepolicy sepolicy"
The quotes are necessary. You can also just use xarchiver or anything that can handle cpio. Don't copy from /sepolicy or /sys/fs/selinux/policy from the live device because they contain a large number of magisk rules (assuming you're rooted). Copy it from the current boot partition.
5) Add/modify selinux rules in the sepolicy file. I used setools-android https://github.com/xmikos/setools-android It built fine on arch linux, I believe dependencies are built in, but YMMV. The sepolicy-inject command is used to add/modify rules. Use logcat and dmesg (save the output to examine it more easily with an editor). See what caused your avc denied entries. Correct some or all of them by adding permissions to existing entries or adding new entries to the policy file.
Update: The only rule change you need to get the camera working is:
Code:
sepolicy-inject -s sensors -t sensors -c capability -p dac_override -P sepolicy
However, you might want to change other rules that are generating avc denieds (audio, battery health, ...). You can also use magiskpolicy or other tools for this. You can either add permissions to an existing rule, or add a new rule.
6) Replace the original sepolicy file in ramdisk.cpio with the modified one:
Code:
./magiskboot cpio ramdisk.cpio "add 644 sepolicy sepolicy"
7) Repack the boot image:
Code:
./magiskboot repack boot.img
magiskboot reads the original unpacked boot.img to get certain info for the repack, and then creates by default a new-boot.img image file.
8) Copy new-boot.img from to your device if it's not already there:
Code:
adb push new-boot.img /sdcard
9) Write the new boot image to the device:
Code:
dd if=/sdcard/new-boot.img of=/dev/block/bootdevice/by-name/boot
10) Boot. Voila!

I should add that there are other ways to get this accomplished as well. Mostly courtesy of magisk. However, the method above will work even without being rooted.

A few people have said flashing nougat kdz, then updating to oreo allows you to use aosp Pie roms with working camera on enforcing

tech_infinity said:
A few people have said flashing nougat kdz, then updating to oreo allows you to use aosp Pie roms with working camera on enforcing
Click to expand...
Click to collapse
Thank you. Yes, I had read that.
In my case, because I followed the Canadian guide linked in my original post, that's exactly what had been done. Nougat 10d -> Oreo 20i -> LOS16 Pie. It could very well be an issue specific to that LOS rom.
When looking over the logs and watching the processes in realtime, in addition to doing a lot of other investigation (with my limited tools/resources), it seems that "something" that is normally there on startup is absent, and then an alternative route and configuration is taken for camera setup. Without those permissions, it pukes around the part where it is trying to configure the three different camera sensors. Why else would there be a need for additional permissions (assuming relevant sepolicy rules are the same versus stock), and why else would those additional permissions make the difference? There's no system camera app in this rom (unlike other LOS roms). You can see what looks like orphaned "camera code" in /system.
You get this over and over without permissive or adding specific rules (see OP).
Code:
03-06 08:21:27.668 0 0 I init : Service 'vendor.camera-provider-2-4' (pid 2462) exited with status 1
03-06 08:21:27.668 0 0 I init : Sending signal 9 to service 'vendor.camera-provider-2-4' (pid 2462) process group...
03-06 08:21:27.668 0 0 I libprocessgroup: Successfully killed process cgroup uid 1047 pid 2462 in 0ms
03-06 08:21:27.669 0 0 I init : starting service 'vendor.camera-provider-2-4'...
An interesting page on android camera framework:
https://programmer.ink/think/camera-android-camera2-hal3-framework-analysis.html
Given the idiosyncracies of this phone (versus my OP6 or other phones), I'm somewhat hesitant to test a bunch of different ROMs (stock and custom) to gain more insight. But perhaps when I have adequate time I'll do more digging. I'd like to compare the sepolicy files as well as a number of other things (e.g. "blobs"). If I find anything interesting, I will post it.
BTW, it's not just the camera issue that needed to be taken care of. There are other services that (most likely unbeknownst to the users of the rom) are caught in a kill/restart loop (battery, audio,...). Adding specific permissions resolved those issues as well.

Upon inspection of sepolicy of a few of the ROMs in question.
Stock Nougat 998 10d:
Code:
allow sensors sensors : capability { chown [B]dac_override[/B] dac_read_search fowner setgid setuid net_bind_service net_raw } ;
Stock Oreo 933 20i:
Code:
allow sensors sensors : capability { chown [B]dac_override[/B] dac_read_search fowner setgid setuid net_bind_service net_raw } ;
Stock Pie 933 20k:
Code:
allow sensors sensors : capability { chown fowner setgid setuid net_bind_service net_raw } ;
Interesting.

This is brilliant work, congrats
You mentioned other services that need permissions. Care to share those as well?
Thanks.
*Edit*
I did manage to return to the state it was before flashing stock pie.
I did a full backup in twrp (especially efs), then I used chip erase on lgup and flashed "H93022j_00_OPEN_EU_OP_0403.kdz" and then I restored efs (chip erase deletes ALL partitions including efs where imei and serial number are stored, that's why an efs backup is essential).
Now I'm using enforcing and everything seems to work.
Be careful though, chip erase is VERY dangerous.

Hi thanks for this awesome tutorial
I'm not very familiar with sepolicy-inject
Could you please tell me how to translate these avc errors into an ALLOW rule for bypassing that annoying "permission denied" message as shell user? Thanks!
Code:
mount : type=1400 audit(0.0:645): avc: denied { dac_override } for capability=1 scontext=u:r:shell:s0 tcontext=u:r:shell:s0 tclass=capability permissive=0
mount : type=1400 audit(0.0:646): avc: denied { dac_read_search } for capability=2 scontext=u:r:shell:s0 tcontext=u:r:shell:s0 tclass=capability permissive=0
mount : type=1400 audit(0.0:647): avc: denied { mounton } for path="/system" dev="dm-0" ino=2 scontext=u:r:shell:s0 tcontext=u:object_r:system_file:s0 tclass=dir permissive=0
mount : type=1400 audit(0.0:648): avc: denied { read } for name="dm-0" dev="tmpfs" ino=20822 scontext=u:r:shell:s0 tcontext=u:object_r:dm_device:s0 tclass=blk_file permissive=0
cat : type=1400 audit(0.0:755): avc: denied { syslog } for capability=34 scontext=u:r:shell:s0 tcontext=u:r:shell:s0 tclass=capability2 permissive=0
cat : type=1400 audit(0.0:756): avc: denied { sys_admin } for capability=21 scontext=u:r:shell:s0 tcontext=u:r:shell:s0 tclass=capability permissive=0

Related

How to reconstruct a binary identical I9000XWJP6 kernel image, and more

The idea of this exercise is (at least) to get a stable starting point for kernel development. The thing which is currently missing is a proper working .config. I have reconstructed it using differential analysis and in the process hoped to find which components have actually been activated and to uncover changes (or Easter eggs) in the sources which have not been advertised. Having a working and identical I9000XWJP6 kernel also means that open development can continue from the current official public release. From there the things possible are only limited by your imagination.
The following is a walk-through on how to build the kernel, description of pitfalls that will cause changes in .config to break, and some annotations on discoveries made in the process.
The things you need are:
Mandatory:
- I9000XWJP6 zImage : from your favorite location
- Source tree : opensource•samsung•com the GT-I9000 OpenSource Froyo Update JPM.zip
- Sourcery G++: www•codesourcery•com/sgpp/lite/arm/portal/release1039
- Tweak-Kit : <attached>
Optional:
- Arm enabled GCC and binutils, including a development libbfd.
- Lots of your favorite beverage
The md5sum of the zImage should be: 26e9d5d206baf1515144c6b8de6f10d2
It is critical that the Sourcery G++ version is 2009q3-67.
The Tweak-Kit contains the following components:
Readme.txt - You're reading it
mkvmlinux.cc - convert zImage to vmlinux and extract the init ramdisk image
I9000XWJP6_defconfig - default .config
stamp.patch - set date/time and such to original
style.patch - fix style related warnings
prototype.patch - fix prototype related warnings
error.patch - Recoverable errors
houston.patch - Unrecoverable errors
shadow.patch - Fixate data structures
I9000XWJP6.h - Fixated macros
I9000XWJP6.c - Entry point stubs
SOME THINGS I ENCOUNTERED IN THE PROCESS:
a) What I absolutely did not expect was that I found two different encodings of the build timestamp. I could deduce that the timezone was central Europe. I had the assumption it would be Asia or America.
b) What was to be expected is that the source tree is incomplete. The directories drivers/fsr and fs/rfs are missing. You can still compile the kernel as the missing files are used to build modules. Problems start when you change the config. Doing so will change entry points and data structures and your kernel might die a horrible death when it loads modules who are unaware on these changes. There is a workaround which I will explain later.
c) The weirdest thing I encountered were the functions enable_hlt() and disable_hlt(). The are located deep in the unwind tables, a section not intended for code. I spent many hours trying to figure out how they got there or why but I still have no clue. I found exactly only one way to reproduce this behaviour and it is certainly not due to a typo, accident or ignorance.
d) The kernel is not a production but a debug version. It has nearly all tracking/tracing/debug bells and whistles switched on. If the energy required to maintain the statistics where to emit light, you could use your Galaxy as a Christmas tree. Function profiling is enabled and has a considerable negative effect on performance, code is not optimized for size but speed, and unwind tables have been enabled which are not used. These have a really bad impact on footprint size. I really hope that the same compiler and settings are not used for the Android layer. Changing the config into a production version will not work (and crash) as the non-native modules expect the debugging hooks which will no longer exist. But the same workaround as above can be used.
e) The functionality of the power management domains have been optimized to oblivion due to the excessive placing of code disabling comments in large parts of the clock, power management and mach-aries.c. Maybe because the Galaxy hardware is too different than the evaluation boards, or the hardware is buggy and disabling the code makes it less unstable, or there was just not enough time to get the code working. Anyway, at this moment I have no oversight into what degree the absence of power domains influence battery usage.
f) When I started examining the binary code I was puzzled by snippets of code I could not reproduce. Even worse, I encountered snippets that were just questionable. Unusual instruction sequences, and resister usage. Thinking I bumped into a GCC bug, I started debugging the compiler and even tweaked instruction scheduling weights but with no satisfying outcome. I know that GCC is very stubborn with regard to saving and clobbering registers in/across function calls and the code I saw was just incorrect. I knew a different compiler was used and I suddenly realized that it may be more different than what first meets the eye. The culprit turned out to be Sourcery G++. It is a private maintained branch of GCC for reasons I have not investigated. Even the Sourcery assembler is tainted as it played a nasty trick on me with the enable_hlt/disable_hlt thing. I do not like the code I see and I am aiming into getting the sources stock GCC friendly with a working kernel. However, GCC and Sourcery generate code which seem difficult to mix, but I'm getting closer.
g) Compiler warnings. Many of the Samsung sources generate warnings, something I really dislike. In my opinion a warning is emitted for a piece of code which can be interpreted in several ways, leaving the compiler to choose which. Usually it will choose the wrong one. Most warnings were related to coding style shortcuts, a couple of incorrect function prototype resulting in functions that should return int to return random or falsely ignoring return values. There were also a couple of nasties like deference of uninitialized pointers, accessing out-of-bound data and mixing clock data-structures of different types. Included are a number of patches to fix them.
h) I looked deeper into why GCC and Sourcery won't mix and discovered that they have different implementations with regard to constant definition within enum declarations. Google points to the staring point "GCC bug 30260" where is written that the behaviour of enumeration constants has changed to becoming signed int. I have noticed that even explicit unsigned values will change to signed.
Here is an example of what is going wrong:
Take following declaration
Code:
enum rt_class_t { RT_TABLE_MAX=0xFFFFFFFF }
. GCC will consider RT_TABLE_MAX to be -1, and Sourcery will consider it 4294967295. Now, in net/ipv4/fib_rules.c there is this code snippet
Code:
for (u32 id = 1; id <= RT_TABLE_MAX; id++)
GCC will skip the loop, and Sourcery will have a hard time doing nothing.
There are more examples like calculating the location of physical memory or signed/unsigned comparisons. The compiler switches -fwrapv and -fstrict-overflow might influence things, but it general the behaviour is hardcoded and both compilers have a different flavour. I think it would be wiser to choose the GCC flavour as it is more widespread and thus better tested (and fixed).
i) GCC. I noticed that early versions of kernels compiled with GCC would not start. At first I thought it was because of Sourcery /GCC code generating differences. After a number of buxfixes (in error.patch) I suddenly noticed that the GCC kernel is working. My phone is running a GCC compiled production configured kernel for nearly a week.
j) "Houston, we've had a problem" with the light sensor. One of the compiler warnings brought me to the file drivers/sensor/optical/gp2a.c. There within are located two routines which read the light and proximity sensor. They seem copy-pasted identical, however the sensor value types are different as the proximity value is a char and the light intensity a double. What is more convenient than to simply change the data type of the supplied buffer in the function prototype. Now headache starts as the semantics of the read (and write) call say that the unit size is byte. So returning "1" indicates that only the first byte of the sensor value is copied. Also, there is no bounds/access checking so supplying an invalid pointer to the call will crash the kernel. So, assuming this is all one big mistake, I redesigned the function to do better (see houston.patch) and built a new kernel with it. To my utter surprise my battery charge extended from <24 hours to 2 days and 20 hours.
However... I also noticed that my backlight intensity level was constant at it's lowest although the setting was set to auto. I needed to know how the caller invokes the call, but after an extensive search of internet and android sources it is still something I have not found. Heuristics show that the reading the light sensor is called with a buffer length of 1, and the returned value is only accepted when returning a 1 and that the sensor value type is a double (8 bytes). This is wrong: read() semantics require that you supply a length of 8, and expect a return value of 8. This may be the base of many light sensor issues I found when Googling.
Anyway, I returned the code to it's original faulty behaviour, and being illuminated I disabled the auto backlight intensity and changed it to it's lowest setting to enjoy a longer life between battery charges.
TO CREATE YOUR KERNEL:
1) Prepare a working environment
1a) Unpack Sourcery G++. No installation needed, unpacking is sufficient
1b) Unpack the Samsung sources and cd to the location of the top-level Makefile.
1c) Unpack the zImage and the contents of the Tweak-Kit to the same location
1d) Make sure the zImage is called zImage.I9000XWJP6
2) The ramdisk image is required and can be extracted from zImage.I9000XWJP6
2a) Create an uncompressed image Image.I9000XWJP6
Code:
gcc scripts/binoffset.c -o scripts/binoffset
ofs=`scripts/binoffset zImage.I9000XWJP6 0x1f 0x8b 0x08 0x00 2>/dev/null`
dd ibs=$ofs skip=1 <zImage.I9000XWJP6 | gzip -c -d >Image.I9000XWJP6
2b) The Tweak-Kit includes mkvmlinux which converts the uncompressed binary image into a bfd object. You need an Arm enabled libbfd to get it working. This does not get installed by default so you need to deeplink into binutils. mkvmlinux locates and decodes the kallsym data and econstructs the symbol table. It then uses the values of __initramfs_start/end to extract the initramfs. If you are not bothered with the hassle, just use dd with hardcoded values.
Code:
g++ mkvmlinux.cc -o mkvmlinux -lbfd -liberty -lz [-I and -L that deeplink into binutils]
./mkvmlinux Image.I9000XWJP6 vmlinux.I9000XWJP6 -r initramfs.cpio
or
Code:
dd if=Image.I9000XWJP6 of=initramfs.cpio bs=1 count=2739712 skip=165568
3) Patch date/time and other environmental issues to the moment of original creation
Code:
patch -p1 <stamp.patch
4) Make your computer happy
Code:
# edit Makefile line 184 and update the macro CROSS_COMPILE=
cp I9000XWJP6_defconfig arch/arm/configs/I9000XWJP6_defconfig
make I9000XWJP6_defconfig
make
5) Verify that the kernel is identical
Code:
diff zImage.I9000XWJP6 arch/arm/boot/zImage
AND NOW FOR SOMETHING COMPLETELY DIFFERENT...
Tweaking the configuration will build you a new kernel but when your Galaxy powers on it will either die silently (hang) or experience a horrible death (reboot). The problem is that there are modules built from sources located in the removed directories drivers/fsr and fs/rfs. These modules were compiled with a specific data structure layout and entry points. These will surely change when re-configuring. The way to keep the non-native modules happy is to keep the structures and entry points intact.
The structure layout is influenced by the CONFIG_ macros. The structures can be fixed to reflect the state of the I9000XWJP6 kernel by replacing the CONFIG_ macro's by something that does not change after reconfiguration. For that I use a collection of 'shadow' macro's which have SHADOW_ as prefix. Because the data structures cannot expand, you cannot (easily) enable configure functionality which require extra fields in the data structures. Reducing functionality is highly seldom a problem.
If changing kernel functionality results in removal of entry points, then stubs are required for those entry points needed by the non-native modules
There are automated methods to verify that a new kernel abides to the above constraints. For the data structures the compiler must generate gstabs debug information. This is human readable and includes detailed structure descriptions. This information should be identical across re-configuration. However, the scripts get confused by anonymous structs which are by product of "typedef struct {" constructions. These need to be named, something shadow.patch also does.
The kernel modules have easily-readable symbol tables containing needed kernel entry points. These should all be present in all re-configured kernels. Validation tests that fail emit enough information to further fix data structures and entry points. The Tweak-Kit contains two files: I9000XWJP6.h containing the SHADOW_ macro's and I9000XWJP6.c for the stubs. Both were constructed in an on-demand basis for the reconfiguration I am currently using and both serve as good examples on what to do when validation fails.
Before reconfiguring, rebuild the kernel for usage as a validation checkpoint.
1) Undo the timestamp patches
Code:
patch -R -p1 <stamp.patch
2) Fix the warnings
Code:
patch -p1 <style.patch # style related issues
patch -p1 <prototype.patch # prototype related issues
patch -p1 <error.patch # bug fixing
3) Apply datastructure fixation, entrypoint stubbing and Makefile tweaking
Code:
patch -p1 <shadow.patch
cp I9000XWJP6.c arch/arm/plat-samsung
4) Before recompiling everything, you need to issue "make clean" first. However, the missing directories will now pose a problem as "make clean" will include their Makefiles and will fail if it can't. Just create empties to keep the build happy.
Code:
mkdir -p drivers/fsr fs/rfs
touch drivers/fsr/Makefile fs/rfs/Makefile
5) Optionally change the Makefile to point to your favorite compiler/toolchain. Please note that I am using GCC 4.4.5. GCC 4.5.1 is bumping into problems I haven't looked into yet.
Code:
# edit Makefile line 184 and update the macro CROSS_COMPILE
6) This build will generate gstab debug information. Unexpectingly, this might bite when combined with function profiling, so disable that. But do not CONFIG_FUNCTION_TRACER yet as that does more.
Code:
# edit Makefile line 553, disable the line containing KBUILD_CFLAGS += -pg
7) Unpack the initramfs image. The directory /lib/modules needs to be examined/updated
Code:
mkdir initramfs.dir
cd initramfs.dir
cpio -i --make-directories --preserve-modification-time --no-absolute-filenames <../initramfs.cpio
cd ..
8) Repack initfs as a tarball, as make clean will erase all the modules
Code:
tar cf initramfs.tar initramfs.dir
9) The initramfs image will contain new kernel modules. Make sure a new version will get generated.
Code:
# in .config line 80 point to the unpacked initram location
CONFIG_INITRAMFS_SOURCE="initramfs.dir"
# in .config lines 86-89, select your favourite compression
CONFIG_INITRAMFS_COMPRESSION_NONE=N
CONFIG_INITRAMFS_COMPRESSION_GZIP=Y
10) Build a new kernel
Code:
# not cleaning will confuse the verification
make clean
make CONFIG_DEBUG_INFO=y
# install the modules
tar xf initramfs.tar
cp `find drivers -name '*.ko'` initramfs.dir/lib/modules
# rebuild with a fresh new ramdisk image
rm usr/initramfs_data.cpio*
make CONFIG_DEBUG_INFO=y
11) Checkpoint structure/entrypoint information. This is architecture independent.
Code:
# extract structures. They are the entries with :T
objdump -G vmlinux | awk '{ print $7 }' | grep :T | sed 's/([^)]*)/()/g' | sed 's/=\*()//g' | sort -u > gstabs.ckp
# extract the entrypoints
nm vmlinux | grep 'r __ksymtab_' | awk '{ print $3 }' | sort > ksymtab.ckp
12) Do a test-run. Pack zImage and flash with Odin. If your Galaxy is up and running, I strongly suggest you make a backup of your environment. If you later change something and it breaks, then this is the best place to restart.
Code:
cp arch/arm/boot/zImage .
tar cf I9000XWJP6-2.6.32.9-test.tar zImage
13) Make your re-configuration. I really suggest you do not make too many changes in one go because it gives more work when the structure/entrypoint verification fails.
Code:
# re-configure. For this exercise, change the kernel to a more production version
CONFIG_CC_OPTIMIZE_FOR_SIZE=Y
CONFIG_DM_DEBUG=N
CONFIG_S3C_KEYPAD_DEBUG=N
CONFIG_DEBUG_FS=N
CONFIG_DEBUG_KERNEL=N
CONFIG_LATENCYTOP=N
CONFIG_FTRACE=N
CONFIG_ARM_UNWIND=N
CONFIG_DEBUG_USER=N
14) Build a new kernel
Code:
# not cleaning will confuse the verification
make clean
make CONFIG_DEBUG_INFO=y
# install the modules
tar xf initramfs.tar
cp `find drivers -name '*.ko'` initramfs.dir/lib/modules
# rebuild with a fresh new ramdisk image
rm usr/initramfs_data.cpio*
make CONFIG_DEBUG_INFO=y
You get "struct has no member named" errors if you have enabled subsystems that require data structures to change which are incompatible with the non-native modules.
15) Verify structure/entrypoint checkpoint
Code:
# extract/verify structures
objdump -G vmlinux | awk '{ print $7 }' | grep :T | sed 's/([^)]*)/()/g' | sed 's/=\*()//g' | sort -u > gstabs.t
# new/changed structures are tagged with '+'. Display only the changed ones
diff -U0 gstabs.ckp gstabs.t | grep '+' | grep ':T' | sed 's/+//' | sed 's/:T.*/:T/' | while read s; do
grep -q "$s" gstabs.ckp
if [ $? -eq 0 ]; then
echo $s;
fi
done
# extract/verify entrypoints
nm vmlinux | grep 'r __ksymtab_' | awk '{ print $3 }' | sort >ksymtab.t
# extract all entrypoints needed by the modules
nm `find initramfs.dir/ -name '*.ko'` >allkosym
# some symbols are referenced in other modules. Cross-reference and remove from list
grep ' U ' allkosym | sort -u | awk '{ print $2 }' | while read s; do
if ! egrep -q "^[0-9a-f]* . $s\$" allkosym; then
echo $s;
fi
done > allusym
# check that kernel has entrypoints for all final undefined symbols
cat allusym | while read s; do
if ! egrep -q "^__ksymtab_$s\$" ksymtab.t; then
echo $s;
fi
done
Both scripts will generate output if you have enabled subsystems that require datastructures to change. These do not necessarily have to be data structures needed by non-native modules. However, missing entrypoints are those used by the modules. If it's about datastructures, your best chance is to lookup the data type and see if there any #ifdef CONFIG_ macros that need to be changed into #ifdef SHADOW_. If it's a missing entry point, you need to add a stub in I9000XWJP6.c.
16) Do a test-run. Pack zImage and flash with Odin.
Code:
cp arch/arm/boot/zImage .
tar cf I9000XWJP6-2.6.32.9-test.tar zImage
17) If you want more, jump to step 13
18) When you are really done, rebuild a final and fresh kernel and initramfs image with debugging stuff removed. The -gstabs compiler switch slightly influences code generation.
Code:
# not cleaning will confuse the verification
make clean
make
# install the modules
tar xf initramfs.tar
cp `find drivers -name '*.ko'` initramfs.dir/lib/modules
# rebuild with a fresh new ramdisk image
rm usr/initramfs_data.cpio*
make
My uncompressed image has now shrunk from 14700623 to 11822559 bytes.
Happy Hacking...
[...and now to find a better workaround for those non-native modules.]
WoW, Nice work !! very good info for beginners like me
thx a lot for this tut and i've learnt a lot
btw, seems there r some typos or something is missing. i did it with (XXJPO):
Hexabit said:
make I9000XWJP6_defconfig
Click to expand...
Click to collapse
make defconfig I9000XWJP6_defconfig
- modified include/linux/a.out.h by removing the 2nd def for SEGMENT
- changed the boolean to lowercase for .config
PS i use the cpio extracted by myself coz i couldnt enable libbfd on my ubuntu x64
Good tips. Thanks.
Really insightful i hope the dev take all the tweaks into consideration and make a new optimized kernel
good job here!
I think it's the most amazing first post ever! It should be sticked or kept somewhere safe.
Awesome first post. Will have to work through this.
Great post with very interesting findings!
I'm no expert, so maybe my question is a bit silly:
Is Samsung's published code just a buggy and incomplete pre-release debug version? Then how can e.g. Voodoo get a good working kernel?
Or is the official firmware really built of this, so possibly full of strange bugs and missing optimizations?

[dev][kernel][kexec]

Last Update : August, 19, 2014
Hi,
I'm still try to bypass the MMU protection.
I have fixe a lot of bug, like memory misalignment, bad adresses allocation, dtb correction, etc...
Last sources and binaries here :
kexec-tools V11.zip : http://forum.xda-developers.com/attachment.php?attachmentid=2902912&stc=1&d=1408401794
kexec-tools binaries V11.zip : http://forum.xda-developers.com/attachment.php?attachmentid=2902913&stc=1&d=1408401794
Sorry, i have always 13 sec reboot after new kernel boot.
"cpu_proc_fin" use a "mcr p15" to init cache and proc that cause freeze.
I try to find solution for that.
Last Update : June, 22, 2014
Hi,
My sources are horrible... but i give something new.
This kexec is for stock kernel only (tested on .757). I thinks theses sources work on other kernel too.
In "kexec-tools V10.zip", you have all my sources. It's highly recommended to mod them to have something OK.
In "kexec binaries.zip", you have binaries to install
=> "kexec_load.ko" and "procfs_rw.ko" must be placed in "/system/lib/modules" folder with "chmod 777"
=> "kexec" must be placed in /system/bin" folder with "chmod 777"
=> cd /system/lib/modules
=> insmod kexec_load.ko
For sources :
Mod and adapt all you want, it's free.
You have 2 scripts in Zip : "./compil-kexec" in "kexec-tools" folder to rebuild and send in device directly (install Adbtcp on device and send by tcp with : adb connect xxx.xxx.xxx.xxx) = work perfectly with me.
"scriptZ1" is for compil stock kernel or another kernel (doomlord kernel for eg)
You must rename "custom_final_files" folder after compil to "final_file" manually ; You can have guest kernel in "custom_final_files" and stock kernel in "final_files" for "kexec-tools" path ... Don't mix a guest and host kernel please ^^
I am tired... i let you test and say if it's ok for you...
Thank a lot to munjeni for his help.
kexec-tools V10.zip : http://forum.xda-developers.com/attachment.php?attachmentid=2811994&stc=1&d=1403456181
kexec binaries.zip : http://forum.xda-developers.com/attachment.php?attachmentid=2811995&stc=1&d=1403456181
Last Update : November, 23, 2013
Hi,
For few days now, i haven't no more kernel panic with my kexec.
I have fixed few stuffs into sources, and add a lot.
These adds are, to include a "dt.img" image file into kexec load process.
This image file is a "device_tree" image to match hardware to software.
So, i assume to don't include atags into boot process, but pass bootloader informations by this DT.
I have programmed a little scan memory to found dynamicly all magic tags, because i found 3 device_tree into memory (magic is "0xd00dfeed").
These 2 device_tree are echo from first and nice structure.
The boot process need to have informations from this DT, and need all informations to initialize hardware (no HDW initialisation by the kernel)
I must first fix issues ; Regroup zImage and dt.img into memory to load a solid bloc to kexec_load module to boot into, and second, fix an offset i can't explain, 0x800 in memory causing misalignment memory
Keep tuned..
Last Update : November, 17, 2013
Hi everybody,
My kexec-tools work for Sony Xperia Z1 stock kernel "3.4.0-perf"
This tools can work on all locked bootloader for all locked device, not only Sony or Z1 models.
This kexec-tools add a kexec_load kernel module (LKM) and use a driver to grant a communication between "kexec" user program and kexec_load.ko module
what is for ?
"kexec" user program load in memory a custom kernel in zImage format, but can load ".tar" image too
This user tool load ramdisk in memory if necessary
This tool is for this purpose only, and don't keep in memory the custom kernel at device reboot.
It is a "user" program, not a "kernel" extension... So, to really do the magic, we need the host kernel (stock sony locked kernel) have a kexec_load capability to reboot in a new gest kernel (custom kernel).
Infortuntly, stock kernel don't have kexec_load capability.
Sony have compiled his stock kernel without this option, and "standard" kexec-tools "need" this option to work.
To see all system call capability of kernel, you can run theses command :
Code:
echo 0 > /proc/sys/kernel/dmesg_restrict
echo 0 > /proc/sys/kernel/kptr_restrict
cat /proc/kallsyms
Do all grep you want here.
The "echo 0" "restrict" is here to unmask logical adresses to "system calls"
Like you can see, "__NR_kexec_load" capability isn't here.
To add kexec_load capability in stock locked kernel, we need to add manualy a kernel module wich add this function into the kernel.
Why ? Because the way to keep in memory a custom kernel need to know a lot of parameters, and keep a specific memory range alive at reboot.
Only kernel can do this.
All user program will be terminated at reboot.
"Standard" kexec_load.ko module use a method to implement the "__NR_kexec_load" function in system call table.
Since 2.6.0 kernel, linux for security reason, have locked in memory the "system_call_table" ; No more add or modification is authorized.
If kexec tool try to add a value, "kexec_load" for us, we causes a kernel panic, and reboot device.
For this reason, i have modify kexec user program and kexec_load module to implement a driver to talk to each other.
this driver replace syscall method, and we no more need to use a system call table.
For this reason, this tool is now compatible with modern kernel like our "3.4.0"
For this reason, this tool must work for other device (Xperia X, P, S, etc...) and another brand
For this reason, if kernel is locked, we can bootstrap to run a new kernel.
Installation
First, you can compil your own kexec tool
Here, sources : http://forum.xda-developers.com/attachment.php?attachmentid=2397299&stc=1&d=1384689174
And here, the binaries : http://forum.xda-developers.com/attachment.php?attachmentid=2397305&stc=1&d=1384689406
(it's not a cwm zip, i have no time to create an installer for now ; use "./compil-kexec" if you want an automatic install)
Install *.ko in /system/lib/modules
Install kexec and kdump in /system/bin
Grant with "chmod 777"
Unzip in kexec-tools folder
Install a toolchain (sudo apt-get install gcc-arm-linux-gnueabi)
launch => ./compil-kexec
what's all
This script can do everythinks for you
- Compilation of tools
- Compilation of modules
- installation in device
This script can compil for every brand you have.
Except you must remove or adapt the patch (see below why)
Patch ??
This patch is because a module must be compiled in the same time the kernel himself.
For this reason a "vermagic", an identifier, is used by system to block every module not compil with kernel
Some custom kernel bypass this to authorize every modules.
But for stock kernel, it is not allowed.
You can easely strapp this by busybox.
"busybox modprobe" for help
"-f" to force load without vermagic
To see this vermagic :
Code:
# uname -r
This "uname -r" must be the same that
Code:
# strings kexec_load.ko | grep vermagic
vermagic=3.4.0-perf-g66807d4-02450-g9a218f1 SMP preempt mod_unload modversions ARMv7
If you want use automaticaly this vermagic, you can modify into the custom kernel this file :
Code:
"include/config/kernel.release" and add :
"3.4.0-perf-g66807d4-02450-g9a218f1"
This file will be use at module compil to match the vermagic.
Infortunatly, it is not enought. :silly:
The infamous "no symbol version for module_layout"
When a module compil is created, it use symbols link to system call function, translate by adresses
Theses symbols are not at same physical adresses in stock kernel and modules (compiled from DooMLoRD kernel).
So, theses adresses must be convert into modules itself to match with stock symbols adress.
A patch is needed.
If you use my script, modules are automatically patched.
Here patches :
Code:
sed -i 's/\x32\x76\x86\x29/\x72\xFF\x5E\x20/' procfs_rw.ko
sed -i 's/\x32\x76\x86\x29/\x72\xFF\x5E\x20/' kexec_load.ko
sed -i 's/\xBB\xD0\xF8\x4D/\x0E\x1C\x63\x77/' kexec_load.ko
sed -i 's/\xA6\x26\x81\x1A/\xD4\x56\x02\x7E/' kexec_load.ko
sed -i 's/\xA3\xD1\xEC\x96/\xEC\x43\x28\x1A/' kexec_load.ko
sed -i 's/\x8C\xE6\x6A\x5F/\x3D\xDF\x02\xF2/' kexec_load.ko
sed -i 's/\x3E\xF3\xEF\xE9/\x18\x7F\xA6\x8A/' kexec_load.ko
sed -i 's/\x8B\xD2\x92\x10/\xC8\x19\x08\x9C/' kexec_load.ko
sed -i 's/\x1C\xE8\x18\xE1/\x7C\x71\x9E\xEF/' kexec_load.ko
sed -i 's/\xAB\x2C\x2F\x8B/\x8E\xD7\x63\xC0/' kexec_load.ko
sed -i 's/\xF5\x62\xAA\x4B/\x34\x80\x1B\x74/' kexec_load.ko
sed -i 's/\x00\x52\xD6\xD7/\x6F\x80\x91\x20/' kexec_load.ko
sed -i 's/\x4F\x77\x57\x6A/\x0C\x57\xC7\x63/' kexec_load.ko
sed -i 's/\xCA\x2F\x65\x71/\x92\xB8\x7F\x53/' kexec_load.ko
sed -i 's/\x0F\xD0\xA0\x91/\xFA\x80\x15\xB4/' kexec_load.ko
sed -i 's/\x29\xA0\x6D\x48/\x6C\x6B\x96\x54/' kexec_load.ko
sed -i 's/\x6D\x1F\x1F\x37/\xCC\x5E\x79\x8B/' kexec_load.ko
sed -i 's/\xFD\x23\xD0\xFB/\xE3\xE3\x68\x52/' kexec_load.ko
You can use hexedit or hexdump to see these adresses :
Code:
hexdump kexec_load.ko | grep ff72
0003d50 b0b0 80ac ff72 205e 6f6d 7564 656c 6c5f
how does it work ?
# kexec --help
For kexec help... nothing more to say.
# lsmod
List loaded modules... You must see
kexec_load 31369 0 - Live 0x00000000 (O)
# rmmod kexec_load.ko
Remove kexec_load module from memory.
# grep kexec /proc/device
To see installed driver.
You must see :
100 kexec_driver
First number is "major" number to identify your driver in system.
# mknod /dev/kexec_driver c 100 0
Install driver.
Major number (here 100), is important for module.
This Major must be the same between module and driver.
By default, 100 is used.
# insmod kexec_load.ko
To install "LKM", kexec_load kernel module.
If another Major is needed, you can use "insmod kexec_load.ko 101" for Major 101
You can use "modprob" if you want, but you must configure the module folder.
How kexec and module exchange informations ?
By the driver.
Normal output for a kernel module is to write in "dmsg" file.
To see kernel output, launch this command :
Code:
# dmesg
To see last kernel log, see in :
Code:
# cat /proc/last_kmsg
For kexec module, this normal way still exist, and give a lot of informations, but to speak with, you must use the driver.
/dev/kexec_driver
You can yourself test communication:
Code:
# cat /dev/kexec_driver
You can send kernel by this communication channel.
Type following commands for help
=> echo help >/dev/kexec_driver
=> dmesg | grep Kexec
Code:
# echo help >/dev/kexec_driver
# cat /dev/kexec_driver
Last command : 'help'
Please type following command :
=> dmesg|grep Kexec
Every command send into driver is receive by kexec_load.ko module and running into the kernel.
The answer can by read thru the driver
Here, you can see that normal way to see messages is allway dmesg.
Code:
# dmesg|grep Kexec
<4>[15050.521628] Kexec: Starting kexec_module...
<6>[15050.521656] Kexec: kexec_driver_contener allocation
<6>[15050.521673] Kexec: kexec_memory_buffer allocation
<4>[15050.521691] Kexec:----------------------------------------------------
<4>[15050.521710] Kexec: kexec_driver created with major : '100'
<4>[15050.521728] Kexec: Please, prepare by typing the following commands :
<4>[15050.521746] Kexec: => mknod /dev/kexec_driver c 100 0
<4>[15050.521761] Kexec: => cat /dev/kexec_driver
<4>[15050.521775] Kexec:-----------------------------------------------------
<4>[15050.521791] Kexec: For help
<4>[15050.521803] Kexec: => echo help >/dev/kexec_driver
(...)
I have add a lot of informations to help to configure kexec.
rdtags, atags ??
Not sure for this part of kernel.
"atags" is the most used method to bootloader to parse commands and informations to kernel at boot.
"atags" is a form of structure in memory to organise informations.
At boot, a address chain is created and can be compulse in /proc/atags file.
This file is read only system.
"rdtags" is another way to bootloader to parse information to kernel.
"rdtags" is not stocked in "/proc"
But, as i see, stock kernel can use "atags" from bootloader.
kexec can substitute bootloader function to create fromscratch a atags chain, and parse to new kernel.
I have change this part to stock atags in "/data/atags", and reuse or change if need.
If this don't work, i must create a rdtags chain to replace atags ; It's not a hard work.
Status
For the moment, kexec tools works.
=> Phase one OK.
I can start Phase Two : new kernel patch.
If you want to help me...
Actually, load a custom kernel and boot into with kexec tools work.
But at boot into, a kernel panic occurs.
It seems, a part of kexec patch is missing in custom kernel.
Hi new thread created for kernel kexec development.
Status: not working: wrong values for mem defines under the kernel is giving segmentation fault as its attempting to write to memory areas that are currently being used byyyyy the system
Instructions:
Make kernel compatible?:
1. Download kernel diff patch from below
2. Terminal - diff patch > diff.txt
How to use:
1. Download kexec-tools (kexec binary) from below
2. Copy into system/bin directory and give it executable permission
3. Download compatible kernel
4. Terminal - kexec --load-hardboot zImage --initrd=initrd.img --mem-min=0x20000000 --command-line="$(cat /proc/cmdline)"
kexec -e
Download links:
Kexec tool- https://db.tt/8DZXQ9eV
Ramdisk firmware 1.548 : https://db.tt/8DZXQ9eV
zImage (kernel):
Source code:
Kernel diff patch: https://db.tt/Xi2htT7Q (currently contains wrong values for mem defines)
Kexec-tools: https://db.tt/I22ofr3b
Special thanks: @delewer @krabappel2548
Reserved
Please move this thread to Xda Devdb, then I can also edit first post etc if I find new stuff
Sent from my C6903 using xda app-developers app
krabappel2548 said:
Please move this thread to Xda Devdb, then I can also edit first post etc if I find new stuff
Sent from my C6903 using xda app-developers app
Click to expand...
Click to collapse
Devdb?
Pm me i dont know what Devdb is lol
Recieved segmentation fault with delewers calculated mem values too
We need to write to memory where we have write access to, maybe lockedbootloader is not allowing us to write? Orrr we are just writing to wrong area of memory
If kexec works on the Z1, can it be ported over to Xperia Z/ZL/T/Ultra? I believe they don't all share the same processor.
Shaky156 said:
Devdb?
Pm me i dont know what Devdb is lol
Click to expand...
Click to collapse
Shaky156 said:
Recieved segmentation fault with delewers calculated mem values too
We need to write to memory where we have write access to, maybe lockedbootloader is not allowing us to write? Orrr we are just writing to wrong area of memory
Click to expand...
Click to collapse
I'll discuss with Kali- today if he's available.
Knucklessg1 said:
If kexec works on the Z1, can it be ported over to Xperia Z/ZL/T/Ultra? I believe they don't all share the same processor.
Click to expand...
Click to collapse
Doesn't need to be same processor, can be ported
Sent from my C6903 using xda app-developers app
Knucklessg1 said:
If kexec works on the Z1, can it be ported over to Xperia Z/ZL/T/Ultra? I believe they don't all share the same processor.
Click to expand...
Click to collapse
Yes it wont matter much, since its not s800 it should be easier for you guys , take the kexec-tool use that, implement the patch write to the correct mem addresses which is free, it should boot if you guys have issues let me know,
I need to calculate the correct addresses.
Ive noticed s800 uses a dt.img, might need to modify kexec-tool to support dt.img, not sure what dt.img does yet, only know it holds values
Shaky156 said:
I need to calculate the correct addresses.
Ive noticed s800 uses a dt.img, might need to modify kexec-tool to support dt.img, not sure what dt.img does yet, only know it holds values
Click to expand...
Click to collapse
the dt.img is needed by the kernel to boot, so I guess we need to load that too in kexec.
EDIT: people that wanna try add kexec patch to their kernel, check github: android_kernel_sony_msm8974/commits/kexec
krabappel2548, i have compil your kernel by my script (fromscratch)
My script (instruction in "DoomLord Build kernel thread" : scriptZ1 http://forum.xda-developers.com/attachment.php?attachmentid=2346163&d=1382568778
(for thoses who want to help us...)
You have a little mod to do here (bad compil) :
In "sound/soc/msm/qdsp6v2/rtac.c"
you must change
#include <q6voice.h>
by
#include "q6voice.h"
btw : no more ideas to load kexec for the moment ...
delewer said:
krabappel2548, i have compil your kernel by my script (fromscratch)
My script (instruction in "DoomLord Build kernel thread" : scriptZ1 http://forum.xda-developers.com/attachment.php?attachmentid=2346163&d=1382568778
(for thoses who want to help us...)
You have a little mod to do here (bad compil) :
In "sound/soc/msm/qdsp6v2/rtac.c"
you must change
#include <q6voice.h>
by
#include "q6voice.h"
btw : no more ideas to load kexec for the moment ...
Click to expand...
Click to collapse
Sorry, I'm trying to get caught up on the forum, but what seems to be the current standing issue to get kexec working?
Knucklessg1 said:
Sorry, I'm trying to get caught up on the forum, but what seems to be the current standing issue to get kexec working?
Click to expand...
Click to collapse
Read the OP
Status paragraph
Memory regions
00000000-07afffff : System RAM
00008000-00b79383 : Kernel code
00d04000-00f0cddb : Kernel data
0ff00000-779fffff : System RAM
7ff00000-7ff3ffff : rdtags_mem
7ff80000-7ffa0fff : last_kmsg
7ffa1000-7ffa5fff : last_amsslog
System RAM MEM = 00000000
So --min-mem=0x20000000
Now need to find a free memory area thatll allow us to write and hopefully the mmu/pmu on locked bootloader wont cancel it
@delewer? @DooMLoRD @kali @Bin4ry
I know I shouldn't disturb, but i must ask: if You achieve Your goal, would it be possible to port it to devices like Xperia P, S, T, U and other NXT? It would be great, many ppl are ready to give a prize for it. Thanks in advance, good luck and sorry again.
Sent from my LT22i using xda app-developers app
king960 said:
I know I shouldn't disturb, but i must ask: if You achieve Your goal, would it be possible to port it to devices like Xperia P, S, T, U and other NXT? It would be great, many ppl are ready to give a prize for it. Thanks in advance, good luck and sorry again.
Sent from my LT22i using xda app-developers app
Click to expand...
Click to collapse
These devices are not 2013 devices, they arent s800 socs, so they are much easier to do, simply take the kexec-tools from op, implement the patch in your kernel, write the correct memory values for your specific device and execute in terminal via the command in op, minmem depends on your device too, good luck
I think some1 tried it already, but it works only for unlocked devices... Anyway, thanks for help.
Sent from my LT22i using xda app-developers app
king960 said:
I know I shouldn't disturb, but i must ask: if You achieve Your goal, would it be possible to port it to devices like Xperia P, S, T, U and other NXT? It would be great, many ppl are ready to give a prize for it. Thanks in advance, good luck and sorry again.
Sent from my LT22i using xda app-developers app
Click to expand...
Click to collapse
Does doing this require having an Unlocked Boot loader prior to implementation?
Sent from my C6603 using xda app-developers app
A few informations about kexec-tools debug
in kexec.c
Fonction :
if (file_type.load(argc, argv, kernel_buf,
kernel_size, &info) < 0) {
fprintf(stderr, "Cannot load %s\n", kernel);
return -1;
}
With a forced execution of kexec (bypass error to see...)
--mem-min=0x90000000
kernel: 0xb6b9d008 kernel_size: 3e9340
debug: 1 - after get memory range
debug: 2 - after type test
debug: 3 - after type test
debug: 4 - after info.kexec
debug: Focus 1 - argc '5' ; argv 'be856774' ; kernel_buf 'b6b9d008' ; kernel_size '3e9340' ; info 'be856548' ; i '1' ; file_type.name 'zImage'
Could not find a free area of memory of 3f1340 bytes...
Cannot load zImage
debug: 10 - before trampoline
debug: 11 - after trampoline
debug: 12 - before segment load
debug: 13 - after segment load
debug: 8 - before sort_segment
debug: 9 - after sort_segment
debug: 6 - before purgatory
debug: 7 - after purgatory
kexec_load: entry = (nil) flags = 280004
nr_segments = 0
kexec_load failed: Function not implemented
entry = (nil) flags = 280004
nr_segments = 0
debug: 5 - return result : ffffffff
With a forced bypass on file_type.load , we have this :
--mem-min=0x20000000
debug: Focus 1 - argc '5' ; argv 'bef18774' ; kernel_buf 'b6bc7008' ; kernel_size '3e9340' ; info 'bef18548' ; i '1' ; file_type.name 'zImage'
Segmentation fault
delewer said:
A few informations about kexec-tools debug
in kexec.c
Fonction :
if (file_type.load(argc, argv, kernel_buf,
kernel_size, &info) < 0) {
fprintf(stderr, "Cannot load %s\n", kernel);
return -1;
}
With a forced execution of kexec (bypass error to see...)
--mem-min=0x90000000
kernel: 0xb6b9d008 kernel_size: 3e9340
debug: 1 - after get memory range
debug: 2 - after type test
debug: 3 - after type test
debug: 4 - after info.kexec
debug: Focus 1 - argc '5' ; argv 'be856774' ; kernel_buf 'b6b9d008' ; kernel_size '3e9340' ; info 'be856548' ; i '1' ; file_type.name 'zImage'
Could not find a free area of memory of 3f1340 bytes...
Cannot load zImage
debug: 10 - before trampoline
debug: 11 - after trampoline
debug: 12 - before segment load
debug: 13 - after segment load
debug: 8 - before sort_segment
debug: 9 - after sort_segment
debug: 6 - before purgatory
debug: 7 - after purgatory
kexec_load: entry = (nil) flags = 280004
nr_segments = 0
kexec_load failed: Function not implemented
entry = (nil) flags = 280004
nr_segments = 0
debug: 5 - return result : ffffffff
With a forced bypass on file_type.load , we have this :
--mem-min=0x20000000
debug: Focus 1 - argc '5' ; argv 'bef18774' ; kernel_buf 'b6bc7008' ; kernel_size '3e9340' ; info 'bef18548' ; i '1' ; file_type.name 'zImage'
Segmentation fault
Click to expand...
Click to collapse
Did you compile this kexec yourself? Or did you get this from krapabbel? I issued krapabbel to compile a new debug version have gave him the code but never heard back from him :/
Anywayz so cannot find free memory is the issue

[DEV] Building a custom kernel and kernel modules for stock kernel

Since fire phone doesn't have a bootloader unlock at the moment. There is no point in building a custom kernel. But By building a kernel we can build kernel modules which work on the stock kernel. And yes you can load unsigned kernel modules without a problem since fire phone doesn't use tz apps to verify kernel modules like Samsung does.
Setup
Source
Download the fire phone sources for firmware 4.6.1 from here. And extract the platfrom.tar inside the archive to somewhere(KERNEL_DIR).
toolchain
You can use the android ndk from google, But it requires some setup. I'm using linaro toolchain from here. You can use compiler version 4.7, 4.8 or 4.9. Kernel I'm using (Firmware 4.6.3 - Linux 3.4-perf-g280c96c) is built with gcc-4.7. But I'm using this gcc-4.9. Download it, extract is somewhere(TOOLCHAIN_DIR) and add the $TOOLCHAIN_DIR/bin to your PATH. Theoretically you would be able to build the kernel on windows using Cygwin or MSYS tools but using Linux is better.
config
Connect your phone trough adb and run
Code:
adb pull /proc/config.gz
zcat config.gz > $KERNEL_DIR/kernel/qcom/3.4/.config
With this config you will run into some problems because of a missing "trapz_generated_kernel.h". I don't know if this is an auto generated file when they build android as a whole or amazon removed this explicitly(can they do that without violating GPL?). Anyway It looks trapz is some low level kernel debugging function(comment here if you know more about it). We can safely disable it. Open $KERNEL_DIR/kernel/qcom/3.4/.config in a text editor and change the lines
Code:
CONFIG_TRAPZ=y
CONFIG_TRAPZ_TP=y
CONFIG_TRAPZ_TRIGGER=y
CONFIG_HAVOK=y
to
Code:
#CONFIG_TRAPZ=y
#CONFIG_TRAPZ_TP=y
#CONFIG_TRAPZ_TRIGGER=y
#CONFIG_HAVOK=y
building
Now edit the $KERNEL_DIR/kernel/qcom/3.4/Makefile and add this changes
Code:
EXTRAVERSION = -perf-g280c96c
This is at the top of the makefile. If we don't add this, vermagic for the modules will differ from stock kernel and they won't load.
ARCH=arm
CROSS_COMPILE=arm-linux-gnueabihf-
Click to expand...
Click to collapse
Here arm-linux-gnueabihf- is my cross compiler frefix. Look in $TOOLCHAIN_DIR/bin/ to find it.
Now cd into $KERNEL_DIR/kernel/qcom/3.4/ and do
Code:
make
The build will fail a few times complaining about missing headers. Most of the time it's just
Code:
#include <myheader.h>
instead of
Code:
#include "myheader.h"
Edit the source file where the build fails and change <>s to ""s. (maybe android ndk ignores the difference and include the headers anyway)
After kernel compiles, we are good to go. We can use this kernel sources to build kernel modules for stock kernel.
Kernel modules
To build the kernel modules, we basically need two things. An approximate kernel source and the Module.symvers file from the original kernel. We can get the Module.symvers file by building the complete kernel as explained above or Just extract it from our stock kernel.
To extract the Module.symvers from the stock kernel, extract the boot.img file from firmware update image. Get mkbootimg tools from here compile it and run
Code:
unmkbootimg --kernel zImage ---ramdisk ramdisk.cpio.gz -i boot.img
After you get the zImage. Download extract-symvers script from here and run
Code:
python2 extract-symvers.py -B 0xc0008000 zImage > Module.symvers
place this file in $KERNEL_DIR/kernel/qcom/3.4/ (You still have to do the changes mentioned above in kernel config and building section run make in the $KERNEL_DIR/kernel/qcom/3.4 and intrupt it after few seconds)
Now you can build loadable modules against this source. Here is a hello world kernel module.
Code:
//hello.c
#include<linux/module.h>
#include<linux/kernel.h>
#include<linux/init.h>
static int __init hello_start(void)
{
printk("hello to the world from module");
return 0;
}
static void __exit hello_end(void)
{
printk("heloo exit");
}
module_init(hello_start);
module_exit(hello_end);
Code:
#Makefile
KERNEL_DIR=<your kernel dir>/kernel/qcom/3.4
obj-m := hello.o
PWD := $(shell pwd)
default:
$(MAKE) ARCH=arm CROSS_COMPILE=armeb-linux-gnueabi- -C $(KERNEL_DIR) SUBDIRS=$(PWD) modules
Put this files in a folder and run make in it. Change the paths and cross compiler prefix according to your setup. and run make.
After the build push the hello.ko to the phone.
Code:
adb push hello.ko /sdcard/
adb shell
su
cd sdcard
insmod hello.ko
run dmesg and you'll see the message.
I'm currently trying to build kexec module from hashcode's sources and USB OTG modules.
I'm attaching a few thing helped me do this.
since they have released this version of the fire os they have to provide the source code
see
http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
you have just shown that the source code they releases for the kernel does not match the one used to build the kernel. This means it is a clear violation of the gpl and amazon is in breach and can be sued.
on another note.
are the drivers for the nfc and camera compiled as a module or into the kernel?
They have yet to provide 4.6.3 and 4.6.4 kernel sources too.
I don't know exactly but in order for NFC and camera to work drivers are required and they are in fact compiled into the kernel.
The problem we currently have with NFC and camera is proprietary hal (hardware abstraction libraries) They are a part of Android and does not subject to GPL. Amazon changed the original android way how hal works and didn't release the sources!
by looking at the kernel drivers maybe we would be able to implement hal from scratch. But I don't see that intense dev support for fire phone. If you are up for it camera sources are at $KERNEL_DIR/kernel/qcom/3.4/drivers/media/platform/msm/camera_v2/
Major MAJOR respect for all of you making the Fire Phone even better!
@madushan1000
Could we do something like this to install a custom boot.img?
http://forum.xda-developers.com/optimus-l9/general/guide-install-custom-roms-locked-t3249828
I don't own this device but has anyone tried to see if kexec works?
spudowiar said:
I don't own this device but has anyone tried to see if kexec works?
Click to expand...
Click to collapse
Nope, I was working on it. But then I got a job. It will be sometime before I can start working on it again.
Could someone please provide the config extracted from /proc/config.gz?
I can't find this on CM11 rom for some reason.
Building the kernel now.
Some bugs are in the code and -Wall and gcc-wrapper.py escalate the warnings.
I wonder if those errors are there on purpose XD
helloworld.ko loaded successfully
I was able to execute kexec without anything. Just the binary.
Will keep you posted - this hacking might take a while to figure it all out.
I already have 3.4 kernel from the amazon sources.
I have the kexec userland program.
What is left is a loadable kexec kernel module (if that is possible at all).
removed
Okarin said:
Are we even sure those Amazon Kernel Sources are correct?
Those errors caught by the wrapper scripts are giving me the creeps.
Git the kexec_load.ko build.
Currently hands on insmod.
Phone doesn't do a reboot any longer:
insmod kexec_load.ko
init_module(0xb6e6c008, 408241, "") = -1 ENOENT (No such file or directory)
write(2, "insmod: init_module '/sdcard/kex"..., 79insmod: init_module '/sdcard/kexec_load.ko' failed (No such file or directory)
) = 79
munmap(0xb6e6c000, 409600) = 0
mprotect(0xb6f8c000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0xb6f8c000, 4096, PROT_READ) = 0
close(0) = 0
close(1) = 0
close(2) = 0
futex(0xb6f6cd74, FUTEX_WAKE_PRIVATE, 2147483647) = 0
munmap(0xb6f8c000, 4096) = 0
exit_group(-1) = ?
First goal is to get module loaded.
Goal reached:
kexec_load 27813 0 - Live 0x00000000 (O)
procfs_rw 12770 0 - Live 0x00000000 (O)
wlan 3793980 0 - Live 0x00000000 (O)
Shouldn't be functional at all..
I disabled some function calls just to get the module loaded.
The missing symbols are:
soft_restart
arch_kexec
machine_shutdown
And the version I use does some insane function hooking ..
More rework is needed.
[email protected]:/data/local # ./kexec /sdcard/vmlinux
kernel: 0xaf12d008 kernel_size: 7e1354c
unrecoverable error: could not scan "/proc/device-tree/": No such file or directory
<6>[ 97.681256] Kexec_load: Replacement... :
<6>[ 97.681344] kexec_load : my_syscall_table : c0106244
<6>[ 97.681405] kexec_load : kexec_load before replacement : c01b346c
<6>[ 97.681480] kexec_load : kexec_load after replacement : bf3a5650
<6>[ 97.681546] kexec_load : reboot before replacement : c01a83f0
<6>[ 97.681616] kexec_load : reboot after replacement : bf3a6348
<6>[ 97.681675] Kexec_load: End replacement... :
<6>[ 202.694691] Kexec: - Starting kexec_load...
<6>[ 202.694849] Kexec: - ---- kexec_load - result : '0'
It gets better:
255|[email protected]:/data/local # ./kexec --dtb=/sdcard/zImage-dtb /sdcard/vmlinux
kernel: 0xaf1b1008 kernel_size: 7e1354c
kexec-zImage-arm : dtb.img BEFORE CUT : Start : '0xae66f008' - Length : '0xb411e9' - End : '0xaf1b01f1'
Segmentation fault
More tomorrow.
Click to expand...
Click to collapse
Where are you getting your kexec module sources from? BTW try using the original amazon kernal binary the phone is shipped with (we are sure it works). Don't use the custom kernel for the kexec tests (We don't know the custom kernel actually works)
madushan1000 said:
Where are you getting your kexec module sources from? BTW try using the original amazon kernal binary the phone is shipped with (we are sure it works). Don't use the custom kernel for the kexec tests (We don't know the custom kernel actually works)
Click to expand...
Click to collapse
Here is the thread I used as a starting point.
I will put up my "fork" on github after I get permission to do that
The userland part build like a charm once I took the compiler you recommended.
The kernel-module was tricky because the whole thing is modded like hell.
To be able to load I had to comment out some hard coded addresses and the calls to unresolvable symbols.
removed
Okay the kernel gets loaded.
But
kexec -e shuts off the device.
strace doesn't help.
On the plus side:
Devices are shutdown
Look promising
I need a way to tail dmesg ...
Okay a lot of digging around and I found out that the reboot syscall doesn't work properly..
It doesn't look like it hits the kexec_module it looks more like it hits the actualy sys_reboot
Okay reboot syscall hits my reboot-hook.
But the softreboot doesn't work now.
Okay there is some kind of watchdog runnig which doesn't like my kexec.
I need to kill it - that should happen tomorrow.
removed
I hit the same wall when I tried to isolate the kexec code from the kernel itself to a module. I stopped working on it because I lacked the time. BTW the error you are facing now
<3>[ 80.580644] BUG: scheduling while atomic: kexec/4067/0x00000002
Click to expand...
Click to collapse
is because memory allocator is trying to switch threads while you are in a syscall. it's because of lines like this
image = kzalloc(sizeof(*image), GFP_KERNEL);
Click to expand...
Click to collapse
Try changing GFP_KERNEL to GFP_ATOMIC. Other than that, I have another suggestion. Try to get the kernel to run in a single core mode before running kexec code. This might simplify things. I don't know how to do this though.
madushan1000 said:
I hit the same wall when I tried to isolate the kexec code from the kernel itself to a module. I stopped working on it because I lacked the time. BTW the error you are facing now
is because memory allocator is trying to switch threads while you are in a syscall. it's because of lines like this
Try changing GFP_KERNEL to GFP_ATOMIC. Other than that, I have another suggestion. Try to get the kernel to run in a single core mode before running kexec code. This might simplify things. I don't know how to do this though.
Click to expand...
Click to collapse
The atmic error is gone now. It went away after I disabled the watchtog.
smp_disable() is what you are looking for - but this causes the system to hard_reboot ATM XD
what happens if you kill every userlevel program before smp_disable()?
removed
#define tomorrow
Okay .. I worked out the preemption thing.
At least it does something.
Still a black screen and the MSM_WATCHDOG is a ***** again.
It needs to be suspended .. at least that what I get from the code I read here.
If I remove the driver too early the output in /proc/kmsg stops ..
If I try to remove it too late ... well it causes a resched while atomic.

Can I calibrate the accelerometer? Camera horizon level is not indicated correctly.

Hello,
I tried some camera apps (Cameringo+, aillis, and ProShot) which had a horizontal level indicator, but all the indicators did not indicate the true horizontal level. It seems that the built-in accelerometer is wrong. Is there any method to calibrate the wrong sensor?
Thanks,
*push*
I have the same problem. I can't play racing games or use cardboard apps. Can anyone help?
best regards
I have the same problem.
More precisely, when I run the "GPS Status & Toolbox" app and the device is stationery, I get a non-zero rotation vector.
GPS Status shows a 3 degrees/second rotation, even when the device is still.
Since it's a brand new unit, I'm likely to return it to Goog.
I have the same problem, but don't know any solution. Seems it's a common problem.
After further investigations, it seems like there is some calibration data that's not being read when the device boots.
If anyone has the same problem and has root, can you:
Post the contents of:
Code:
/persist/sensorcal.json
Code:
/data/misc/sensorcal_saved.json
Then turn off SELinux or patch the SELinux policy (SuperSU required) by either running:
Code:
setenforce 0
OR
Code:
supolicy --live 'allow sensortool devpts chr_file { read write getattr }' 'allow sensortool persist_sensortool_file file { write }'
Then run:
Code:
/vendor/bin/sensortool.bullhead -c gyro
while the phone is still. This will overwrite
Code:
/persist/sensorcal.json
.
And finally post the contents of
Code:
/persist/sensorcal.json
after this modification.
Your gyro should now be functioning correctly until the next reboot.
It looks like Nexus 5X "forgets" to read the calibration data upon boot.
The above procedure will force a recalibration and forces the sensor hub to use the new calibration data.
I'm looking at a way to load the calibration data into the sensor hub without having to recalibrate, but this may need some serious hacking.
Fif_ said:
After further investigations, it seems like there is some calibration data that's not being read when the device boots.
If anyone has the same problem and has root, can you:
Post the contents of:
Code:
/persist/sensorcal.json
Code:
/data/misc/sensorcal_saved.json
Then turn off SELinux or patch the SELinux policy (SuperSU required) by either running:
Code:
setenforce 0
OR
Code:
supolicy --live 'allow sensortool devpts chr_file { read write getattr }' 'allow sensortool persist_sensortool_file file { write }'
Then run:
Code:
/vendor/bin/sensortool.bullhead -c gyro
while the phone is still. This will overwrite
Code:
/persist/sensorcal.json
.
And finally post the contents of
Code:
/persist/sensorcal.json
after this modification.
Your gyro should now be functioning correctly until the next reboot.
It looks like Nexus 5X "forgets" to read the calibration data upon boot.
The above procedure will force a recalibration and forces the sensor hub to use the new calibration data.
I'm looking at a way to load the calibration data into the sensor hub without having to recalibrate, but this may need some serious hacking.
Click to expand...
Click to collapse
Thanks for your post. Inspired by what you said, I found the other guys and myself are having an miscalibrated accelerate sensor. And it's a little bit difficult to calibrate this sensor than the gyro, since a flat table is needed and the back of 5x is not flat (due to the camera).
P.S. can you post the undo command of this?
Code:
supolicy --live 'allow sensortool devpts chr_file { read write getattr }' 'allow sensortool persist_sensortool_file file { write }'
yaoppp said:
Thanks for your post. Inspired by what you said, I found the other guys and myself are having an miscalibrated accelerate sensor. And it's a little bit difficult to calibrate this sensor than the gyro, since a flat table is needed and the back of 5x is not flat (due to the camera).
Click to expand...
Click to collapse
Great to be able to help.
I found it easy to calibrate the accelerometer: just raise the middle and bottom section of the phone over a book. The camera parts can be dangling.
I have since made more discoveries and was able to calibrate the device correctly and have the calibration persist on reboot.
My sensors problems are now gone!
Instructions follow below.
yaoppp said:
P.S. can you post the undo command of this?
Code:
supolicy --live 'allow sensortool devpts chr_file { read write getattr }' 'allow sensortool persist_sensortool_file file { write }'
Click to expand...
Click to collapse
Just reboot. These changes are in memory only.
If you actually want to undo the policy changes without rebooting, run as root:
Code:
supolicy --live 'deny sensortool devpts chr_file { read write getattr }' 'deny sensortool persist_sensortool_file file { write }'
---------- Post added at 04:30 PM ---------- Previous post was at 03:47 PM ----------
After struggling with this for a while, here's the latest update about what I found.
Contrarily about what I wrote earlier on, the Nexus 5X does read the calibration data in /persist/sensorcal.json at boot.
What happens is the calibration procedure (as initiated by /vendor/bin/sensortool.bullhead -c <sensor>) correctly calibrates the sensor, updates the sensor with the new calibration data, then writes the calibration file /persist/sensorcal.json wrong.
That's why running /vendor/bin/sensortool.bullhead -c <sensor> fixes the problem until the next reboot.
So the fix is to edit by hand the /persist/sensorcal.json file, trying to tweak the calibration values, reboot, check the sensor and do that a few times until you have no sensor bias.
Well, you can do it this way (rebooting between every change to /persist/sensorcal.json), or you can look at the next post for an alternate method that does not involve rebooting twenty times.
WARNING: If you make a typo editing /persist/sensorcal.json, like adding a comma where it's not needed or removing one where it's needed, your device will not boot. You will have to get into recovery and fix the file there. What's even worse, a factory reset will not fix a busted /persist/sensorcal.json as /persist is not wiped during factory reset.
DO THIS AT YOUR OWN RISK
Before you make any change to /persist/sensorcal.json:
Make a backup of the file
Make sure you know how to restore that backup from recovery, without Android booting.
Again: a mess up will softbrick your phone.
My particular case:
My gyrometer readings were off. When the device was still, a simple app to report the gyro reading was returning a non-zero value. The device was thinking it was rotating around only one axis.
Needless to say all apps that used the gyro (eg. driving games) were not happy about this.
My original /persist/sensorcal.json file looked like this:
Code:
{
"accel": [
22,
-2,
-8
],
"gyro": [
22,
-9,
-9
],
"proximity": 1
}
}
I started changing the numbers in the gyro section. After changing the "22" to "100" and rebooting, I saw that my original faulty axis was still wrong, but also another axis was now busted.
So I reverted that change, moved on the next number.
Finally I found that the third figure was the one that was corresponding to my busted axis.
I managed to tweak that number until my gyro was reporting no motion at rest.
And now my Nexus 5X's sensors are just fine, and I can play driving games
My final /persist/sensorcal.json looks like this:
Code:
{
"accel": [
22,
-2,
-8
],
"gyro": [
22,
-9,
-73
],
"proximity": 1
}
}
Since the problem is likely to be memory corruption in /vendor/bin/sensortool.bullhead, on your device, a different calibration value may be affected.
If you want to "factory recalibrate the device" (and re-break your sensors), just follow the instructions in post #5.
Rereading /persist/sensorcal.json without rebooting
The method therein allows you to edit /persist/sensorcal.json then have the on-board sensor re-read that file without having to reboot.
Requirements:
A Nexus 5X device (duh)
Busybox installed
Supersu installed
The attached bullhead-reread-sensor-calibration.zip file.
A root shell (either via ADB or with a Terminal app + su)
Instructions:
Unzip bullhead-reread-sensor-calibration.zip under /sdcard. This will create two new files:
bullhead-reread-sensor-calibration
sensortool-writewrap.so
After every change to /persist/sensorcal.json, run in your root shell:
Code:
sh /sdcard/bullhead-reread-sensor-calibration
. You should see:
Code:
supolicy v2.74 (ndk:arm64-v8a) - Copyright (C) 2014-2016 - Chainfire
Patching policy ...
(Android M policy compatibility mode)
-allow:sensortool:devpts:chr_file:read=ok
-allow:sensortool:devpts:chr_file:write=ok
-allow:sensortool:devpts:chr_file:getattr=ok
- Success
resetting target.
sensorhub said: 'Hello, world!'
sensorhub said: 'Found Bosch BMP280 Pressure/Temperature Sensor'
sensorhub said: 'Found Rohm RPR-0521 Proximity/ALS Sensor'
sensorhub said: 'Found Bosch BMI160 Accel/Gyro Sensor'
sensorhub said: 'init: 22 -2 -8, 22 -9 -73, 0.00, 1'
The numbers on the last line will be different for your device.
Your sensor hub's calibration data has been updated. Note that if you had an app actively reading from the sensors, since they were reset, you will need to quit the app and restart it.
Further notes:
The above script makes no permanent changes to your system (but temporarily alters your SELinux policy, a reboot will reset the policy to its secure default).
The script uses an interposition shared library (sensortool-writewrap.so) that was compiled with the Android NDK from the C file source attached. If you're just using this tool, there is no need to download the C file.
Good guide on how to calibrate your sensors manually.
This should help calibrating your sensor manually if you use the method above:
https://docs.google.com/document/d/14uwBu0R7Yv6bwl5Y7CE1vpFWetnSzgs-zt0GwOaDwIg/edit?pref=2&pli=1
If you don't want to go through the Excel route and exporting the data from the phone, the app "Sensor Kinetics Pro" has a low-pass filter option for all sensors.
You can check that your sensor readouts are as close as possible to zero after tweaking /persist/sensorcal.json as explained in the previous posts.
Fif_ said:
The method therein allows you to edit /persist/sensorcal.json then have the on-board sensor re-read that file without having to reboot.
Click to expand...
Click to collapse
Just wanted to thank you for all these instructions. My accelerometer was 5 degrees off in landscape and while the calibration tool did manage to calibrate it correctly (these settings also stuck for me after reboot), it also calibrated the upright position off by 2 degrees. Some quick manual editing thanks to your method and I now have everything calibrated correctly. It was impossible to take a panorama in landscape before this, so I owe you a really big thank you!
CazeW said:
Just wanted to thank you for all these instructions. My accelerometer was 5 degrees off in landscape and while the calibration tool did manage to calibrate it correctly (these settings also stuck for me after reboot), it also calibrated the upright position off by 2 degrees. Some quick manual editing thanks to your method and I now have everything calibrated correctly. It was impossible to take a panorama in landscape before this, so I owe you a really big thank you!
Click to expand...
Click to collapse
Happy it was useful to someone.
I would have thought the problem was more widespread.
Ok, I probably know the answer, but is there any chance to calibrate it without root permissions? Even if it resets after reboot. I have brand new phone without any scratches, I don't want to loose warranty and change it to a perfect shiny brick (at least not yet). I know my luck, it's gonna be just like that.
I've tried to force Google to admit, that this problem affects every (or almost every) single one Nexus 5X and they should at least add calibration option, because sending phone to the service takes time and isn't the best option. They gave me a standard answer to contact the service :good:
productforums.google.com/forum/?utm_medium=email&utm_source=footer#!topic/nexus/2Xkk3X4KvYQ;context-place=forum/nexus (I can't add link as link, I'm not a trusted user )
Yes, root is required.
However, you can unlock the bootloader, root, follow the instructions and calibrate, and then reimage the device and relock the bootloader.
You'll then have a calibrated stock device, which should be covered by the warranty.
Can You tell me which values did You edited? I have 5 degrees off in landscape too and just can't get right value. I think I actually has problem with accel sensor, not with gyroscope.
P.S. Seems like in Android 7.0 there is no /vendor/bin/sensortool.bullhead .
Instead in init.bullhead.sensorhub.rc I found it uses /system/bin/nanoapp_cmd which have little different format like
/system/bin/nanoapp_cmd calibrate gyro
Click to expand...
Click to collapse
But it actually throws me an "Failed to open /dev/nanohub: err=13 [Permission denied]" error, even after I called both
supolicy --live 'allow sensortool devpts chr_file { read write getattr }' 'allow sensortool persist_sensortool_file file { write }
supolicy --live 'allow nanoapp_cmd devpts chr_file { read write getattr }' 'allow nanoapp_cmd persist_sensortool_file file { write }
Click to expand...
Click to collapse
Any ideas? Anyone tried that hack on Android 7.0 stock?
I've just changed values in /persist/sensorcal.json. My tilt was almost 6 degrees and I knew that the y-axis is bad.
My origin values:
Code:
{
"accel": [
21,
-21,
-8
],
"gyro": [
-1,
-9,
-10
],
"proximity": 9
}
I've changed -21 to -31, then reboot and then i had almost 8 degrees error so it was a bad direction. I've changed it to 0 and now it is perfect.
Now my sensorcal.json loks like this:
Code:
{
"accel": [
21,
0,
-8
],
"gyro": [
-1,
-9,
-10
],
"proximity": 9
}
I'm on the stock rom again and it still works.
@Fif_ I have no words to tell you how awesome you are. THANKS!
Denfox said:
Can You tell me which values did You edited? I have 5 degrees off in landscape too and just can't get right value. I think I actually has problem with accel sensor, not with gyroscope.
P.S. Seems like in Android 7.0 there is no /vendor/bin/sensortool.bullhead .
Instead in init.bullhead.sensorhub.rc I found it uses /system/bin/nanoapp_cmd which have little different format like
But it actually throws me an "Failed to open /dev/nanohub: err=13 [Permission denied]" error, even after I called both
Any ideas? Anyone tried that hack on Android 7.0 stock?
Click to expand...
Click to collapse
Just try to disable SELinux entirely with:
Code:
setenforce 0
and then run nanoapp_cmd.
Fif_ said:
Just try to disable SELinux entirely with:
Code:
setenforce 0
and then run nanoapp_cmd.
Click to expand...
Click to collapse
This not works for me unfortunately.
But actually I did calibration by doing values bust.
As a result to compensate 5 degrees at the Y axis I've changed the value in the calibration json on 25 units.
Thanks for a solution! :good:
Hi, thanks, this worked great.
It was tilted almost 7°
As a note I have to modify "accel" section, not "gyro".
Code:
{
"accel": [
27,
-8,
-4
],
"gyro": [
5,
7,
-10
],
"proximity": 8
}
Main post should be as permanent is 5x section
JP
Hi guys, I have the same problem but only in landscape mode. For example if i take a pano in portrait the image is aligned well, while if i try to do it on landscape it's inclined on the right. Which value i have to change in that file?
giorgis91 said:
Hi guys, I have the same problem but only in landscape mode. For example if i take a pano in portrait the image is aligned well, while if i try to do it on landscape it's inclined on the right. Which value i have to change in that file?
Click to expand...
Click to collapse
Some people had to change the gyro section, others the accel section.
Please read the entire thread, make a backup of sensorcal.json, then try to run sensortool/nanoapp_cmd, see if that helps.

[ROM][11.0][UNOFFICIAL][Testing] LineageOS 18.1 for Wileyfox Swift

Code:
#include <std_disclaimer.h>
/*
* Your warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*/
Remarks:
This thread is thought to collect issues and ideas. It has to be considered being a TESTING version.
Once everything is mature, an official build may be possible.
Installation:
If you are on stock OS, you need a custom recovery first. You can get the recommended Lineage recovery in the official installation instructions link below.
If you are coming from stock or other ROMs, you need to make a factory reset.
As always, make sure to backup before installing this ROM.
Also make sure you've got the correct firmware installed before installing LineageOS.
More detailed instructions at:
Install LineageOS on crackling
115ek's test builds (for testers only)
Downloads
Recommended Google Apps package:
none: GApps don't fit at the moment. A repartitioning is needed. Currently thinking about this...
Donate to support development:
Donate via PayPal to LineageOS
Changelog
06.12.2021
updated lineage sources
11.09.2021
fixed livedisplay
updated lineage sources
22.07.2021
initial version
reserved
It's been a while since I tried 18 and I'm tempted to look at the latest. Before I do, are there any major problems other than gapps. I appreciate it needs to be tested but I'd like to be aware if there are any major parts not working.
petexd said:
It's been a while since I tried 18 and I'm tempted to look at the latest. Before I do, are there any major problems other than gapps. I appreciate it needs to be tested but I'd like to be aware if there are any major parts not working.
Click to expand...
Click to collapse
Livedisplay is not working at the moment.
I had to remove it because it wouldn't load my photos and I didn't have time to play around with it. It's actually my only phone. It did, however, instal basic flamegapps.
I also got error 255 when tryin to restore my backup but I'm up and running now with 17.1. I'll try 18.1 again soon when I have more time to mess around with it and if I can sort out error 255
Very cool, thanks! What is the upstreaming status? That would be great as microG builds would be available automatically as well. That one I'd install right away.
ajjin0 said:
Very cool, thanks! What is the upstreaming status? That would be great as microG builds would be available automatically as well. That one I'd install right away.
Click to expand...
Click to collapse
I've got so less time at the moment. I hope I'll find some to continue the work.
New build is up. Livedisplay is working now.
Download
Wow great work.
@115ek Thank you for the new build.
I tried to compile Lineage18.1 myself, but ended up in a boot loop. I assume this is the relevant part of the log, since it repeats over and over again:
Spoiler
Code:
01-01 21:28:58.399 4357 4357 I [email protected]: LiveDisplay HAL service is starting.
01-01 21:28:58.404 4357 4357 D DISP_API: disp_api_get_num_display_modes.
01-01 21:28:58.458 4357 4357 D DISP_API: disp_api_get_num_display_modes successful getting num-of-modes = 6.
01-01 21:28:58.458 4357 4357 D DISP_API: disp_api_get_num_display_modes.
01-01 21:28:58.510 4357 4357 D DISP_API: disp_api_get_num_display_modes successful getting num-of-modes = 6.
01-01 21:28:58.512 220 220 I hwservicemanager: getTransport: Cannot find entry [email protected]::IDisplayModes/default in either framework or device manifest.
01-01 21:28:58.512 4357 4357 E HidlServiceManagement: Service [email protected]::IDisplayModes/default must be in VINTF manifest in order to register/get.
01-01 21:28:58.513 4357 4357 E [email protected]: Could not register service for LiveDisplay HAL DisplayModes Iface (-2147483648)
01-01 21:28:58.514 4357 4357 E [email protected]: LiveDisplay HAL service is shutting down.
01-01 21:28:58.521 0 0 I init : Service 'vendor.livedisplay-hal-2-0-legacymm' (pid 4357) exited with status 1
01-01 21:28:58.521 0 0 I init : Sending signal 9 to service 'vendor.livedisplay-hal-2-0-legacymm' (pid 4357) process group...
01-01 21:28:58.521 0 0 I libprocessgroup: Successfully killed process cgroup uid 1000 pid 4357 in 0ms
01-01 21:28:59.391 219 219 I servicemanager: Since 'android.hardware.power.IPower/default' could not be found, trying to start it as a lazy AIDL service
01-01 21:28:59.391 4193 4193 W ServiceManager: Waited one second for android.hardware.power.IPower/default
01-01 21:28:59.393 219 4360 W libc : Unable to set property "ctl.interface_start" to "aidl/android.hardware.power.IPower/default": error code: 0x20
01-01 21:28:59.395 0 0 E init : Control message: Could not find 'aidl/android.hardware.power.IPower/default' for ctl.interface_start from pid: 219 (/system/bin/servicemanager)
01-01 21:29:00.392 219 219 I servicemanager: Since 'android.hardware.power.IPower/default' could not be found, trying to start it as a lazy AIDL service
01-01 21:29:00.392 4193 4193 W ServiceManager: Waited one second for android.hardware.power.IPower/default
My local manifest looks like:
Code:
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<project name="115ek/android_device_wileyfox_crackling" path="device/wileyfox/crackling" remote="github" />
<project name="115ek/android_device_cyanogen_msm8916-common" path="device/cyanogen/msm8916-common" remote="github" />
<project name="115ek/proprietary_vendor_wileyfox" path="vendor/wileyfox" remote="github" />
<project name="LineageOS/android_kernel_cyanogen_msm8916" path="kernel/cyanogen/msm8916" revision="lineage-17.1" />
<project name="LineageOS/android_hardware_sony_timekeep" path="hardware/sony/timekeep" remote="github" />
</manifest>
Does your manifest look the same? Are there any additional patches I have to apply to get it working? I would highly appreciate it if you could share your steps to build LineageOS 18.1.
mmustermann717 said:
Does your manifest look the same?
Click to expand...
Click to collapse
This should be fine, yes.
mmustermann717 said:
Are there any additional patches I have to apply to get it working?
Click to expand...
Click to collapse
Yes. I still have some local changes I didn't push yet. There are two kernel patches required for enforcing SE linux which I didn't upload yet.
But permissive mode should work. You can switch to permissive for now by:
adding androidboot.selinux=permissive to https://github.com/115ek/android_de...7d4427d6896080f77946/BoardConfigCommon.mk#L94
The thing you see in the log is the broken livedisplay. I also have a local unpublished change here:
Code:
--- a/manifest.xml
+++ b/manifest.xml
@@ -184,6 +184,10 @@
<name>IDisplayColorCalibration</name>
<instance>default</instance>
</interface>
+ <interface>
+ <name>IDisplayModes</name>
+ <instance>default</instance>
+ </interface>
<interface>
<name>IPictureAdjustment</name>
<instance>default</instance>
You can try it that way. But in any case I should publish those changes. I just need to find some spare minutes to write a proper commit message and clean things up.
115ek said:
This should be fine, yes.
Yes. I still have some local changes I didn't push yet. There are two kernel patches required for enforcing SE linux which I didn't upload yet.
But permissive mode should work. You can switch to permissive for now by:
adding androidboot.selinux=permissive to https://github.com/115ek/android_de...7d4427d6896080f77946/BoardConfigCommon.mk#L94
The thing you see in the log is the broken livedisplay. I also have a local unpublished change here:
Code:
--- a/manifest.xml
+++ b/manifest.xml
@@ -184,6 +184,10 @@
<name>IDisplayColorCalibration</name>
<instance>default</instance>
</interface>
+ <interface>
+ <name>IDisplayModes</name>
+ <instance>default</instance>
+ </interface>
<interface>
<name>IPictureAdjustment</name>
<instance>default</instance>
You can try it that way. But in any case I should publish those changes. I just need to find some spare minutes to write a proper commit message and clean things up.
Click to expand...
Click to collapse
Thank you very much! That worked.
I increased the system partition, a little while ago and backups were restoring OK so I've decided to try 18.1 again.
I must say, it performs really well for the stuff I need. I also like that I can now do calendar etc backups to my sdcard. Much more sensible IMO.
Thanks 115ek. A great job.
I'd like to have a go at building but I'm not sure where to start without the explicit menu like 17.1
Thanks to 115ek for the 18.1 set up and to mmustermann717 for his local manifest. I have managed to build 18.1 after a few errors which appeared to be out of memory problems.
I fixed that and was able to complete the build.
Thanks both of you
I was too quick to brag. Im getting a boot loop. I made the changes from 115ek's response #12, so I don't know where I've gone wrong.
Can either of you tell me please?
115ek said:
This should be fine, yes.
Yes. I still have some local changes I didn't push yet. There are two kernel patches required for enforcing SE linux which I didn't upload yet.
But permissive mode should work. You can switch to permissive for now by:
adding androidboot.selinux=permissive to https://github.com/115ek/android_de...7d4427d6896080f77946/BoardConfigCommon.mk#L94
The thing you see in the log is the broken livedisplay. I also have a local unpublished change here:
Code:
--- a/manifest.xml
+++ b/manifest.xml
@@ -184,6 +184,10 @@
<name>IDisplayColorCalibration</name>
<instance>default</instance>
</interface>
+ <interface>
+ <name>IDisplayModes</name>
+ <instance>default</instance>
+ </interface>
<interface>
<name>IPictureAdjustment</name>
<instance>default</instance>
You can try it that way. But in any case I should publish those changes. I just need to find some spare minutes to write a proper commit message and clean things up.
Click to expand...
Click to collapse
I've tried all of this several times. I get a successful build but a boot loop every time.
The lineage source says successful, it doesn't actually boot so I have no idea how to find any error? Is there anything I can look for? Or can you guess?
I'd appreciate the help if you can. Thanks.
Hey
petexd said:
how to find any error?
Click to expand...
Click to collapse
The best way would be attaching some cables to get a console over UART. However, this requires some hardware knowledge and most likely some soldering. I haven't had a look into the crackling hardware yet.
Then you could use the android logcat command. Unfortunately adb has to work for that.
A third option could be "loggy", a simple script writing the logs to a defined location. Have a look here.
petexd said:
Or can you guess?
Click to expand...
Click to collapse
You could, but I'm not sure if that really helps.
petexd said:
Is there anything I can look for?
Click to expand...
Click to collapse
What does this line looks like (exactly!) in your sources? Could you post it here?
I'd try to use a known to be working boot.img - you could extract one from my latest 18.1 upload. That way you could exclude some potential problems.
115ek said:
Hey
The best way would be attaching some cables to get a console over UART. However, this requires some hardware knowledge and most likely some soldering. I haven't had a look into the crackling hardware yet.
Then you could use the android logcat command. Unfortunately adb has to work for that.
A third option could be "loggy", a simple script writing the logs to a defined location. Have a look here.
You could, but I'm not sure if that really helps.
What does this line looks like (exactly!) in your sources? Could you post it here?
I'd try to use a known to be working boot.img - you could extract one from my latest 18.1 upload. That way you could exclude some potential problems.
Click to expand...
Click to collapse
This is the line you asked about:
BOARD_KERNEL_CMDLINE := console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci lpm_levels.sleep_disabled=1 loop.max_part=7 androidboot.selinux=permissive
I've tried my build with your boot.img but it still bootloops.
115ek said:
Hey
The best way would be attaching some cables to get a console over UART. However, this requires some hardware knowledge and most likely some soldering. I haven't had a look into the crackling hardware yet.
Then you could use the android logcat command. Unfortunately adb has to work for that.
A third option could be "loggy", a simple script writing the logs to a defined location. Have a look here.
You could, but I'm not sure if that really helps.
What does this line looks like (exactly!) in your sources? Could you post it here?
I'd try to use a known to be working boot.img - you could extract one from my latest 18.1 upload. That way you could exclude some potential problems.
Click to expand...
Click to collapse
I've tried again and the last 4 lines of the build are:
2021-10-18 16:11:33 - ota_from_target_files.py - INFO : done.
Warning: could not find RADIO/filesmap in <zipfile.ZipFile object at 0x7f982df1bf50>.
Warning: could not find RADIO/filesmap in <zipfile.ZipFile object at 0x7f982df1bf50>.
Compressing system.new.dat with brotli
warning radio-update: no radio image in input target_files; not flashing radio
[100% 24/24] build bacon
Package Complete: out/target/product/crackling/lineage-18.1-20211018-UNOFFICIAL-crackling.zip
#### build completed successfully
Is this OK? I thought bacon was another phone (oneplus?)
Hey
115ek said:
The best way would be attaching some cables to get a console over UART. However, this requires some hardware knowledge and most likely some soldering. I haven't had a look into the crackling hardware yet.
Then you could use the android logcat command. Unfortunately adb has to work for that.
A third option could be "loggy", a simple script writing the logs to a defined location. Have a look here.
You could, but I'm not sure if that really helps.
What does this line looks like (exactly!) in your sources? Could you post it here?
I'd try to use a known to be working boot.img - you could extract one from my latest 18.1 upload. That way you could exclude some potential problems.
Click to expand...
Click to collapse
I get this , just bfore the build completes successfully. Do you know if this has anything to do with the problem.
99% 463/464] Package OTA: out/target/product/crackling/lineage_crackling-ota-eng.pet
2021-10-19 18:02:26 - common.py - WARNING : Failed to read SYSTEM/etc/build.prop
2021-10-19 18:02:26 - common.py - WARNING : Failed to read VENDOR/etc/build.prop
2021-10-19 18:02:26 - common.py - WARNING : Failed to read VENDOR/build.prop
2021-10-19 18:02:26 - common.py - WARNING : Failed to read PRODUCT/etc/build.prop
2021-10-19 18:02:26 - common.py - WARNING : Failed to read PRODUCT/build.prop
2021-10-19 18:02:26 - common.py - WARNING : Failed to read SYSTEM_EXT/etc/build.prop
2021-10-19 18:02:26 - common.py - WARNING : Failed to read SYSTEM_EXT/build.prop
2021-10-19 18:02:26 - common.py - WARNING : Failed to read ODM/etc/build.prop
2021-10-19 18:02:26 - common.py - WARNING : Failed to read ODM/build.prop

Categories

Resources