Related
11/6/11 Update: Added statically-linked kexec to kexec_patches.tar.gz and example update.zips. Now works in stock recovery and CM7 CWM (with a kexec-patched kernel).
10/19/11 Update: Added patches for the recently released GB sources to kexec_patches.tar.gz.
Attached is a set of patches (kexec_patches.tar.gz) against EC05, and the recently released GB sources, to implement kexec syscall support in the Epic's kernel. kexec enables the booting of kernels "directly" from the SD card or over USB without having to flash them to the device first. This allows us to easily use, test, and switch between many kernels, not just the one (two with recovery) there's room for on flash.
When used in conjuction with modified init.rc scripts, this allows entire ROMs (with their own kernels) to run from SD card. In short, this allows us to run custom-kernel ROMs (e.g,. CyanogenMod) alongside each other or a stock kernel without having to flash back and forth.
Also attached is a modified version of the kexec userspace tool (also in kexec_patches.tar.gz, along with source and patches) that facilitates the proces of loading and kexecing a kernel image. Finally, attached is a demo EC05 kernel with kexec enabled (demo_kernel.tar.gz; mostly stock: RFS support only, testkeys recovery w/adbd, but does inlcude the keyboard patches), example update.zips that kexec an SD-card kernel from recovery--either as a normal boot (boot_zImage.zip) or recovery boot (boot_zImage_recovery.zip), and a script (patch_decomp_cachebufram.sh) to binary patch unmodified kernels to kexec boot faster.
Note, this thread is primarilly intended for kernel developers. Kexec probably won't be of great utility to end users until commonly-used kernels are patched. Also, although stock kernels can be kexec'd, they need some init.rc modifications boot an entire ROM from SD card. Hopefully the fine folks here will come up with a user-friendly implementation of this work that's easy for everyone to use.
Instructions:
Flash a kexec-enabled kernel (e.g., the attached demo kernel) to either /dev/block/bml7 or /dev/block/bml8. For testing purposes, this kernel needs either "ro.secure=0" or "ro.debuggable=1" set in default.prop, and also needs recovery.rc/fota.rc modified to spawn the adbd service, so that an adb root shell is available while in recovery. Also copy the attached kexec tool to a convenient location on the device (e.g., /data/local/tmp/kexec).
Reboot into recovery. If the kexec kernel is installed to bml7, run "adb reboot recovery" while the phone is running. If installed to bml8, power down and boot into recovery by holding the volume-down, camera, and power buttons.
Make sure adb is running as root. If it's not, try running "adb root".
Find the kernel (zImage) you wish to boot. These can be extracted from a kernel update.zip or Odin .tar file, or use the demo kernel again.
Push the zImage into RAM (tmpfs) with:
Code:
adb push zImage /tmp
Now, open an adb root shell with "adb shell" and run the commands:
Code:
mount -ro remount /dev/block/stl6 /mnt/.lfs
mount -ro remount /dev/block/stl9 /system
mount -ro remount /dev/block/stl10 /data
mount -ro remount /dev/block/stl11 /cache
/data/local/tmp/kexec --load-hardboot --mem-min=0x50000000 --append="console=ttySAC2,115200 loglevel=4" /tmp/zImage
sync
/data/local/tmp/kexec -e
after which the phone will reboot, show the SAMSUNG logo, and eventually boot the kexec'd kernel. Do note that when booting unmodified kernels (see below), the SAMSUNG logo will persist for ~30 seconds longer than usual.
Also note that kexec performs an "abrupt" reboot, i.e., it doesn't shutdown the system normally. Hence it's important to kexec from recovery where few services are running. It's also prudent to remount file systems read-only and sync them to avoid any potential (although unlikely) of corruption.
In the future, kexec could be better integrated into the Android framework to allow for a clean shutdown. Otherwise, probably the best way to deploy kexec is through an update.zip file that boots a kernel from the SD card. See the attached example update.zips.
Technical details:
kexec is feature of Linux that allows it to directly execute (boot) a new kernel in place of itself, allowing Linux to effectively serve as its own bootloader.
The kexec procedure is two step. The first "kexec" command loads a zImage from disk, constructs parameters (e.g., the kernel command line), and stages it in memory, after which Linux continues to run as normal. The second "kexec" command tells Linux to execute (boot) the staged kernel.
In the standard implementation, Linux "soft boots" kexec'd kernels. That is, on "kexec -e" the running instance of Linux shuts-down all devices, drivers, and goes through the process of unloading itself as it does during a normal reboot. However, instead of invoking a hardware reboot, Linux, at the final stage of unloading itself, jumps to start executing the new kernel.
This soft boot process requires that Linux hardware drivers are fully capable of unloading, reloading, and reinitializing the associated hardware without hardware-reboot or bootloader assistance. Since, for many built-in drivers, this capability is only used by kexec, hardware is often left in an unexpected or unknown state on unload, and thus the kexec'd kernel hangs on boot. Unfortunately this is the case with the Epic kernel, and soft booting doesn't work.
To work around this, the attached patches implement a "hard boot" method for kexecing kernels. Here, we use kexec to stage a kernel in memory as usual. On "kexec -e", Linux shuts-down as before, and at the very end of the unloading process it does two things: (i) scribble some information on how to boot the kexec'd kernel to a "special place" in memory, and (ii) performs a hardware reboot, invoking the Epic bootloader as a normal reboot does.
On reboot, the bootloader loads the (previously-running) bml7 or bml8 kernel and starts executing it. Here, the hardboot patch modifies the Linux the zImage decompressor code to check the "special place" in memory to see if we're actually kexecing a different kernel. If so, it switches over to the other kernel, already staged elsewhere in memory.
Known Issues:
Kernel Command Line:
Kexec (via hardboot) can boot stock or non-kexec-modified custom kernels. However, unless the copy_atags patch is applied, they can only use the kernel command line provided by the bootloader, as opposed to the custom command line provided by kexec. Although this isn't a problem when kexecing from a bml7 boot kernel, kexecing from a bml8 kernel runs recovery (fota.rc) instead of a normal boot (init.rc).
With the copy_atags patch, the command line for the kexec'd kernel must be provided by with kexec's --append option. These are the command lines provided by the bootloader in normal boot and recovery scenarios, any of which may be used:
Code:
Normal boot (init.rc):
console=ttySAC2,115200 loglevel=4
"adb reboot recovery" (recovery.rc):
bootmode=2 console=ttySAC2,115200 loglevel=4
Three-finger recovery boot (fota.rc):
bootmode=3 console=ttySAC2,115200 loglevel=4
Slow Booting:
Kexec booting of a stock or non-kexec-modified custom kernel is known take significantly longer than a regular boot, sitting at the SAMSUNG logo for 35 seconds instead of 8. The decomp_cachebufram patch resolves this issue for modified kernels. In addition, the attached patch_decomp_cachebufram.sh script will binary patch the decompressor code for any (to my knowledge) Epic kernel.
Many more details on the patches themselves are in the accompanying READMEs.
Mirror links:
Kernel & kexec-tools patches: kexec_patches.tar.gz
Kexec EC05 demonstration kernel: demo_kernel.tar.gz
Recovery script to boot /sdcard/zImage (normal boot): boot_zImage.zip
Recovery script to boot /sdcard/zImage (recovery boot): boot_zImage_recovery.zip
Script to binary patch decompressor code: patch_decomp_cachebufram.sh
Is this different in function than rodderik's dual boot support?
I know his didn't include usb booting support, but sdcard booting appears to be the same...although this seems a little cleaner, possibly
Sent from my SPH-D700 using xda premium
squshy 7 said:
Is this different in function than rodderik's dual boot support?
I know his didn't include usb booting support, but sdcard booting appears to be the same...although this seems a little cleaner, possibly
Sent from my SPH-D700 using xda premium
Click to expand...
Click to collapse
His uses a modified init, which then choses to load which init.rc, the one names init.rc.sdcard or normal init.rc. This (kexec method) reminds me A LOT like how they ran linux/android on winmo devices...it shuts down android and then runs the kernel they want (if I read correctly).
squshy 7 said:
Is this different in function than rodderik's dual boot support?
I know his didn't include usb booting support, but sdcard booting appears to be the same...although this seems a little cleaner, possibly
Sent from my SPH-D700 using xda premium
Click to expand...
Click to collapse
Yes. The genocide implementation allows a ROM to boot from the sd card as long as the kernel on the main ROM supports the sd ROM. this means you cannot dual boot a gingerbread and a froyo ROM because the need different kernels .
With this patch that limitation is removed as the sd based ROM can use its own separate kernel. This you may run stock ec05 and keep cyanogen or a gingerbread on the sd card to test and play with.
Great work mkasick
Sent from my SPH-D700 using Tapatalk
I was never interested in the dual boot feature since that was ROM's only and itwas limited by kernel support.
But now this really interest me, can't wait till we see some developers take advantage of this.
Sent from my SPH-D700 using xda premium
All I have to say is hope you stick with the epic your amazing
Sent from my SPH-D700 using Tapatalk
Yes, this is complementary to Rodderik's dual boot. Kexec allows one to load a different kernel, but it still defaults to booting the ROM stored in flash. Which is great for kernel testing, but not of much use otherwise.
It's easy enough to modify a kernel to load a ROM only from SD, but then we'll start seeing a divide between "bml kernels" and "SD kernels", when really it'd be nice to have init scripts that support both. That's where Rodderik's work comes in.
Probably the best is to have a kernel command line parameter that specifies where the ROM is located, so it can be passed in. Something like "console=ttySAC2,115200 loglevel=4 systemfs=mmcblk0p2 datafs=mmcblk0p3 cachefs=mmcblk0p4". These would default to stl9, stl10, stl11 respectively if unspecified. The kernel command line is available to init through "/proc/cmdline", and it's easy enough to parse in a shell script.
But yes, keeping a working ROM on flash while testing/debugging CyanogenMod was my primary motivation, since I need a working phone "during the day" and can't touch CyanogenMod otherwise.
formula84 said:
All I have to say is hope you stick with the epic your amazing
Click to expand...
Click to collapse
Thanks!
I'm much of a year out on a full upgrade, and I'm not considering a new device sooner as long as my Epic still works.
Edit: An obvoius limitation is modem compatibility. I've avoided the GB leaks thus far, so I'm not sure what's the status with that. But if GB supports the EC05 modem, then you can dual boot EC05 and GB-whatever. Same if EC05 supports newer modems.
Speaking of which, anyone know what GB modem compatibilty is like?
mkasick said:
Yes, this is complementary to Rodderik's dual boot. Kexec allows one to load a different kernel, but it still defaults to booting the ROM stored in flash. Which is great for kernel testing, but not of much use otherwise.
It's easy enough to modify a kernel to load a ROM only from SD, but then we'll start seeing a divide between "bml kernels" and "SD kernels", when really it'd be nice to have init scripts that support both. That's where Rodderik's work comes in.
Probably the best is to have a kernel command line parameter that specifies where the ROM is located, so it can be passed in. Something like "console=ttySAC2,115200 loglevel=4 systemfs=mmcblk0p2 datafs=mmcblk0p3 cachefs=mmcblk0p4". These would default to stl9, stl10, stl11 respectively if unspecified. The kernel command line is available to init through "/proc/cmdline", and it's easy enough to parse in a shell script.
But yes, keeping a working ROM on flash while testing/debugging CyanogenMod was my primary motivation, since I need a working phone "during the day" and can't touch CyanogenMod otherwise.
Thanks!
I'm much of a year out on a full upgrade, and I'm not considering a new device sooner as long as my Epic still works.
Edit: An obvoius limitation is modem compatibility. I've avoided the GB leaks thus far, so I'm not sure what's the status with that. But if GB supports the EC05 modem, then you can dual boot EC05 and GB-whatever. Same if EC05 supports newer modems.
Speaking of which, anyone know what GB modem compatibilty is like?
Click to expand...
Click to collapse
As far as I know, and from experience, modems are a free for all except for bonsai. Ec05 modem works on gb, leaked modems work on ec05.
this is definitely very cool, thanks mkasick!
Sent from my SPH-D700 using XDA Premium App
mkasick you never cease to amaze me...i'll definately play with this, this week if i have the time!
Rodderik said:
mkasick you never cease to amaze me...i'll definately play with this, this week if i have the time!
Click to expand...
Click to collapse
Great!
If you run into something not particularly straight forward, or think there's something I can clarify, please ask. I've been playing around with this long enough that I fear I might've overlooked documenting a detail or two that would be helpful for others.
So to patch any kernel u just point the script to the zImage?
sent from my epic 4g. with the key skips.
ugothakd said:
So to patch any kernel u just point the script to the zImage?
Click to expand...
Click to collapse
The script only implements one patch, it allows any kernel to boot ~30 seconds faster when kexec'd.
But yes, "./patch_decomp_cachebufram.sh zImage" modifies that zImage to boot faster. It requires the xxd hexdump tool that's packaged with vim.
Kexec support itself, along with the slew of other source patches, has to be applied to a kernel source tree, from which a new kernel must be built to take advantage of them.
mkasick said:
The script only implements one patch, it allows any kernel to boot ~30 seconds faster when kexec'd.
But yes, "./patch_decomp_cachebufram.sh zImage" modifies that zImage to boot faster. It requires the xxd hexdump tool that's packaged with vim.
Kexec support itself, along with the slew of other source patches, has to be applied to a kernel source tree, from which a new kernel must be built to take advantage of them.
Click to expand...
Click to collapse
I see...so its a no-go for gb. Or at least quick gingerbread.
sent from my epic 4g. with the key skips.
ugothakd said:
I see...so its a no-go for gb. Or at least quick gingerbread.
Click to expand...
Click to collapse
You should be able to kexec a GB kernel, but you'd need an EC05-ish /system on flash to boot recovery. Unless GB recovery is compatible with Froyo kernels.
If you're going to boot a GB kernel, you'd probably want to repackage the initramfs with an init.rc that loads the rest of the GB ROM off SD. It's actually not a bad way to keep EC05 around for a stable, working phone, and to test GB leaks as they happen. Which, hopefully, shouldn't be much longer.
wow mkasick, you never cease to amaze me bro...
I wish I wasn't working so many damned hours now, with your patches, I really want the dual boot now. Like you, the need for a working phone at all times is what keeps me from flashing more ROMs, including EpicCM and the gb leaks...
I hope Rodderik figures this out pretty quickly, as most of my dev time is spent on the IRC channels, and he's usually around to help and answer questions.
Once I can get my Clean Kernel working with this, I'll be stoked... I have had a tough time dealing with patches thus far, I usually git cherry-pick and/or manually edit, so I need to figure out how to use the patches correctly.
Anyways, gotta go to work now (I'm working 50+ hour weeks now, hence the time constraints), but hopefully I can get the time to get it into my kernel.
Thanks, mkasick!
Sent from my Samsung Epic4G
DRockstar said:
I have had a tough time dealing with patches thus far, I usually git cherry-pick and/or manually edit, so I need to figure out how to use the patches correctly.
Click to expand...
Click to collapse
What environment (OS, etc.) are you using? Is the "patch" utility working for you?
The patches are split up based on functionality. In each patch directory there's a "series" file that lists the order they should be applied. There's a program, quilt that can help manage them but it's not necessary. If you're running a bourne shell (e.g., bash) in the "Kernel" directory of the kernel sources, you should be able to apply the patches with:
Code:
while read i; do patch -p 1 < "/path/to/kexec_patches/kernel-EC05/$i"; done < "/path/to/kexec_patches/kernel-EC05/series"
Whether they'll apply cleanly or not is a different story, but that's the general idea.
And yeah, time ....
Thank you mkasick, that's a great explanation, I think I can handle that, much appreciated!
For the record, I compile by ssh into dev boxes donated for dev use. They all run linux in different distros. I find this most convenient since I can do most everything from the command line using your brilliant connectbot for epic
Sent from my Samsung Epic4G
With those recovery scripts, doesn't Clockwork Mod have to have kexec set up?
ugothakd said:
With those recovery scripts, doesn't Clockwork Mod have to have kexec set up?
Click to expand...
Click to collapse
You mean for boot_zImage_recovery.zip to work?
The CWM kernel doesn't need full kexec support in order to be booted via kexec. But it does need the copy_atags patch in order to respect the "bootmode=3" kernel argument.
Actually, you can take any existing Epic kernel and somewhat-easily fix it to be bootable via kexec. Steps are:
1. Extract EC05 kernel sources. Or use the GB sources, it doesn't matter, it doesn't even have to match the version of the kernel you're fixing.
2. Apply "decomp_cachebufram" and "decomp_copy_atags" patches.
3. Build a kernel. Config options don't matter much since this kernel is going to be thrown away.
4. Find the zImage for the kernel you want to fix. Run:
Code:
skip=`grep -Fabom 1 $'\x1f\x8b\x08' zImage | head -n 1 | cut -d : -f 1`
dd if=zImage bs=1 skip="$skip" | gunzip > Image
cp Image arch/arm/boot/Image
which extracts the decompressed kernel payload from the zImage, and replaces the "Image" that was previously built with the one you've extracted.
5. Run "make" in the kernel source directory again. You might have to append a "CROSS_COMPILE=" path to match the one used in a build script. The output should be:
Code:
CHK include/linux/version.h
make[1]: `include/asm-arm/mach-types.h' is up to date.
CHK include/linux/utsrelease.h
SYMLINK include/asm -> include/asm-arm
CALL scripts/checksyscalls.sh
CHK include/linux/compile.h
Kernel: arch/arm/boot/Image is ready
GZIP arch/arm/boot/compressed/piggy.gz
AS arch/arm/boot/compressed/piggy.o
LD arch/arm/boot/compressed/vmlinux
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
Building modules, stage 2.
MODPOST 13 modules
which shows that the build process took the existing, extracted Image, compressed it, and attached a new kexec-compatible decompressor to it.
The resulting "arch/arm/boot/zImage" can be kexec'd, and command line arguments should be respected, e.g., if you want to boot into CWM recovery.
Hei there.
The idea of this thread is to develop a better kernel for the I9001 in the community. I have compiled my own one for using it in the cwm recovery mod. I've only changed the following so far:
Patched pm2.c file in the samsung kernel sources, see here for the patch:
https://github.com/PabloPL/android_...mmit/46e96915a7e0459dc6b3aec04aa47329371fff44
through menuconfig I've changed the default cpu governor from performance to ondemand.
What we should implement first is init.d support.
I've uploaded my boot.img file for further use here:
http://www.mediafire.com/?6p91s5knka0e0py
It also contains the CWM Recovery
This is great idea bro. Its great to have you here.
Thanks again!!!
Sent from my GT-I9001 using Tapatalk
I would love to see a overclock able kernel! Great idea!
Joost
Sent from my GT-I9001 using XDA App
overclocking module
Hi guys,
coolbho3000 posted source of an overclocking module for HTC Vision. As far I know, it can be used with the SetCPU App together.
http://forum.xda-developers.com/showthread.php?t=813681
Since S+ has a similar Qualcomm chip, it should work as well.
I compiled the overclocking module with the S+ Kernel and packed it into the zImage. The device doesn't boot. Maybe it would be better to follow what coolbho3000 says and adapt the settings
ädu
PS: it needs definitively some adaptions.
Shouldn't we create our own github/bitbucket repositories for kernel and CWM? I'm trying to get my feet wet in generic Android kernel development now, it would be cool to have repository to sync with.
YardE said:
Shouldn't we create our own github/bitbucket repositories for kernel and CWM? I'm trying to get my feet wet in generic Android kernel development now, it would be cool to have repository to sync with.
Click to expand...
Click to collapse
yep of course. I've already opened an account on github. But right now I ain't got time to read the instructions on how to upload repos because I'm busy with applying some changes to FeaMod Recovery and testing them.
I would be happy if a lot of kernel developers would join us!
Edit: The sources for FeaMod recovery 1.1 are on github:
https://github.com/manveru0/FeaMod-Recovery--based-on-CWM-Recovery-
Samsung kernel sources with patched pm2.c:
https://github.com/manveru0/kernel_I9001_samsung
Later I'll try to add "run-parts /system/etc/init.d/" to init.rc, but I'm highly confused from examining ramdisk, because I couldn't find any bash-scripts interpreter (possibly embedded into init executable?) and don't have enough time to continue examining init.rc now. I think, we can add busybox to system image and call it from there. Also, please, modify these lines in default.prop in your future builds:
Code:
ro.secure=0
ro.debuggable=1
As far as I understood, these allow us to use "adb root".
Also, thanks for your awesome work!
YardE said:
Later I'll try to add "run-parts /system/etc/init.d/" to init.rc, but I'm highly confused from examining ramdisk, because I couldn't find any bash-scripts interpreter (possibly embedded into init executable?) and don't have enough time to continue examining init.rc now. I think, we can add busybox to system image and call it from there. Also, please, modify these lines in default.prop in your future builds:
Code:
ro.secure=0
ro.debuggable=1
As far as I understood, these allow us to use "adb root".
Also, thanks for your awesome work!
Click to expand...
Click to collapse
sounds good. I haven't seen a script interpreter either and I'm not quite sure if there is one included in the init. I think it's better we include busybox. Take a look at this thread by the way:
http://forum.xda-developers.com/showthread.php?t=1152740
I'll try to do that testwise.
Here's the adress for my uploaded boot.img-ramdisk without the samsung pictures (we can easily add them again when building a new boot.img):
https://github.com/manveru0/bootimage_ramdisk_I9001
I've already included the changes in default.prop
EDIT: some useful links
http://www.kandroid.org/online-pdk/guide/bring_up.html
http://www.androidenea.com/2009/08/init-process-and-initrc.html
After some init.rd learning I've inserted a service here which should get the job's done, but I have no idea how to test it. Anyway, here is the diff from the normal one:
Code:
[[email protected] boot]$ diff -u3 init.rc ../boot_mod/init.rc
--- init.rc 2011-11-05 22:35:33.194680288 +0400
+++ ../boot_mod/init.rc 2011-11-05 22:24:40.000000000 +0400
@@ -566,7 +566,7 @@
# ihryu 2010.07.19
setprop ro.rfkilldisabled 0
- class_start default
+ #class_start default
# +++++++++++++++++++++++++++++++++++++++++++
# for silent reset
@@ -714,6 +714,10 @@
onrestart restart netd
onrestart restart sensor-daemon
+service initd /system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/init.d
+ oneshot
+
service media /system/bin/mediaserver
user media
group system audio camera graphics inet net_bt net_bt_admin net_raw radio qcom_oncrpc
[[email protected] boot]$
Have also commented "class_start default" which runs twice for some reason. To have this working in theory, you should have busybox installed in /system/xbin with run-parts support. For me, it boots at least ^_^
P.S. It also works if I call command line from adb. Also, adb root works after changing default.prop, good.
P.P.S. You can also remove "charging.rle" from repo, as it is image, too, but why not just keep all the files in repo? git is loyal to binary files as long as you don't try to create a patch. ~_^ Also, you can use .gitignore to exclude some files from git's view at all.
Found excellent reference on init.rd:
http://www.kandroid.org/online-pdk/guide/bring_up.html
Fixed previous post (removed "disabled"), so it should really work now. Going to test it, but not really sure if my test are correct (I'll try to write something to sdcard, but is it mounted r/w at the moment of script running?)
Test failed, thinking of some other, more accurate tests now.
Tried to create file in /cache, and it worked! Here is boot.img with working init.rd and adb root. Flash it via dd (dd if=boot.img of=/dev/block/mmcblk0p8). You should have busybox installed into /system/xbin for this to work.
YardE said:
Found excellent reference on init.rd:
http://www.kandroid.org/online-pdk/guide/bring_up.html
Fixed previous post (removed "disabled"), so it should really work now. Going to test it, but not really sure if my test are correct (I'll try to write something to sdcard, but is it mounted r/w at the moment of script running?)
Test failed, thinking of some other, more accurate tests now.
Click to expand...
Click to collapse
thx for your commit, I'm testing it as well with the adrenaline shot. If init.d support works you should see the changed values.
I do have a working busybox in /system/xbin with run-parts support, so that shouldn't be the issue as my tests didn't work so far.
Okay, gonna delete disable as well.
concerning the images i wasn't so sure about law problems since they include original samsung stuff.
update:
success You did it! Init support works. Though I have to retest it since I've also added user root to the init.rc. Honestly I'm not quite sure if that entry is needed
"user root" is not needed since user is root by default, already tested without it (edited my posts above).
YardE said:
"user root" is not needed since user is root by default, already tested without it (edited my posts above).
Click to expand...
Click to collapse
okay then, i will change the init.rc file and commit it to github. I will name you in the comment to the change. Which name should I use? Is that okay for you?
Oh, you can use either "abbradar" or "YardE", I don't mind. ^_^ Thank you for credits and again for your work. Gonna experiment a bit with CWM now since init.d is working.
YardE said:
Oh, you can use either "abbradar" or "YardE", I don't mind. ^_^ Thank you for credits and again for your work. Gonna experiment a bit with CWM now since init.d is working.
Click to expand...
Click to collapse
I have to thank you for your work as well, mate It's cool working as a team since we are better, faster and should see more bugs than working alone
Edit:
Hmm, we should include busybox in the boot ramdisk, since not every user has busybox installed.
P.S: funny thing is, I've installed adrenaline shotv13 but only part of it works. For example the sdcard tweak works, the sysctl tweaks don't.
P.P.S: i've installed bash on my device, it's much more easier with it to navigate in the adb shell
manveru0 said:
Hmm, we should include busybox in the boot ramdisk, since not every user has busybox installed.
Click to expand...
Click to collapse
What is the max size limit in our device for ramdisk? Also, should we really do so? It will be hard to update in comparison and maybe will be stripped due to size limit, and users basically'll have two versions of busybox - our embedded into boot.img and their own - in /system. (I'm looking on CM and other init.d implementations as an example) But on the other hand, it is really nearly critical level app (although sh is not in boot.img, for example)
P.S: funny thing is, I've installed adrenaline shotv13 but only part of it works. For example the sdcard tweak works, the sysctl tweaks don
Click to expand...
Click to collapse
They also trying to write some values into non-existent /sys nodes, looks like they are meant for other kernel scheduler, like BFQ (should we also try it?)
---------- Post added at 01:25 AM ---------- Previous post was at 01:25 AM ----------
P.P.S: i've installed bash on my device, it's much more easier with it to navigate in the adb shell
Click to expand...
Click to collapse
Good advice, thank you ^_^.
YardE said:
What is the max size limit in our device for ramdisk? Also, should we really do so? It will be hard to update in comparison and maybe will be stripped due to size limit, and users basically'll have two versions of busybox - our embedded into boot.img and their own - in /system. (I'm looking on CM and other init.d implementations as an example) But on the other hand, it is really nearly critical level app (although sh is not in boot.img, for example)
They also trying to write some values into non-existent /sys nodes, looks like they are meant for other kernel scheduler, like BFQ (should we also try it?)
---------- Post added at 01:25 AM ---------- Previous post was at 01:25 AM ----------
Good advice, thank you ^_^.
Click to expand...
Click to collapse
the maximum size of both recovery and boot.img is 7864320 Bytes. Riversource once found that out. It's also in the BoardConfig.mk So we would have enough space for including busybox. But you're right, it would only lead to 2 busyboxes on the device which is not the best idea.
CM uses the BFQ scheduler as far as I know so yeah, we should give it a try
AFAIK, BFS patch nearly fully removes original kernel schedulers, so some work of comparing with original Linux kernel will be needed to do. Although, it may not be true for Android kernel sources or my experience may be wrong, so we should just try it as is before continuing.
Sent from my GT-I9001 using XDA App
YardE said:
AFAIK, BFS patch nearly fully removes original kernel schedulers, so some work of comparing with original Linux kernel will be needed to do. Although, it may not be true for Android kernel sources or my experience may be wrong, so we should just try it as is before continuing.
Sent from my GT-I9001 using XDA App
Click to expand...
Click to collapse
yep, I've looked at the changes the patches make and they remove alot of the CFQ related functions. Fortunately the makefile is patched as well so no work here.
I've have downloaded the patches for kernel 2.6.35 here:
http://algo.ing.unimo.it/people/paolo/disk_sched/sources.php
I applied them to my sources, compiled em and flashed my FeaMod pack with the new kernel and your changes to the boot ramdisk.
So far everything is working on my device I'm gonna upload the patches to github.
Edit: Had to change the .config as well since bfq is not the default I/O scheduler. It is now, I've also activated the hierarchical scheduler support.
Concerning ramdisk git repo: maybe we should move all the code into some folder, for example, "ramdisk", and move README out from there to avoid it being placed into final image? Also, we should point which files are missing from ramdisk in README.
FIsH a la carte - A porting guide for the FIsH framework.
Proudly introducing Android FIsH: Fluffy Incredible steadfasterX Hijack
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
FIsH: Fluffy Incredible steadfasterX Hijack
First of all:
All this is for the brain of DEVELOPERS.
Well.. to be more specific: not really for developers but for COMPILERS
For using FIsH You do NOT need to DEVELOP anything - normally - the only thing you should be able to do is COMPILING -> e.g. TWRP.
If you have the knowledge to compile TWRP then FIsH is what you need to bring it on your locked device.
Just follow the menu card in the post #3 "Bring FIsH on the menu card" and your job is done.
If you are a user wanting to have FIsH for your device: FIND A COMPILER (a person who is able to compile TWRP/ROMs/.. for your device!!).
DO NOT ASK IF I CAN PORT FIsH TO YOUR DEVICE!
DO NOT ASK IF I CAN COMPILE [FILL IN WHATEVER YOU WANT] FOR YOU!
-> instead find a person willing to port FIsH plus the ramdisk of your choice (e.g. TWRP) and point him/her here.
When do you feel like a compiler or u want to be one: read on
if not: really still here? I said find a compiler!
Table of content
This whole thing here is damn long.. but that's one of the major difference for the FIsH: I try to explain what I do
For a better handling I splitted the guide into several parts:
This post: Explain me the FIsH (What it is)
Post #2: FIsH bowels (What's inside)
Post #3: Bring FIsH on the menu card (porting FIsH)
Post #4: FIsH cuisine (examples)
Post #5: FIsH hydra (multiboot in FIsH)
Post #6: Chew the FIsH (Copying/License)
Post #6: FIsH mutation history (Changelog)
Post #7: Go FIsHing (enduser installation guide example)
Overview
You can not unlock your bootloader? So now it's all over right?
TWRP and flashing custom ROMs on locked devices is impossible right?
Oh no wait there are hacks (up to KK) which have a workaround for this but I couldn't find anything for LL (sorry if I missed something) and what I found was not easy to port so nothing generic which i could just adapt easily.
Here is where the Android FIsH (refered to just FIsH in this whole doc) steps in
FIsH means: [F]luffy ncredible teadfasterX [H]ijack
FIsH is different from Safestrap or other hijacks because it should be better understood as a kind of framework for any ramdisk image you want to load.
FIsH will not harm the Android boot chain! Means it will not modify /boot, /recovery or aboot partitions. It will just modify /system.
FIsH:
... is NOT MultiROM (see post #5: FIsH hydra)
... is NOT efidroid (see post #5: FIsH hydra)
... is NOT Safestrap
... is NOT TWRP (booting with FIsH is tested and works)
... does NOT root your phone
... does NOT unlock your phone
... is a WORK IN PROGRESS!
... but FIsH could (in theory) "BOOT" any of the above!
U got it? FIsH is the hack to boot whatever you want.
This also means atm it is tested on some devices only and the only FIsHFOOD (ramdisk) FULLY tested and so stated to be working is TWRP.
Nevertheless I'm hard working currently on porting either MultiROM-in-FIsH or efidroid-in-FIsH to bring custom ROMs to locked devices as well (see post #5: FIsH hydra).
What the FIsH is (in short words)
Read about the full details of the implementation of FIsH in the next post (Post #2: FIsH bowels (What's inside)) but to give you a short overview:
FIsH is a boot hijack and wants to be a FRAMEWORK for booting any fishfood (ramdisk) you like.
FIsH is portable to other devices
FIsH gives you all possibilities to make the most of your device by letting you boot whatever you like
FIsH will not provide or contain any ROM or recovery by it's own - THATS YOUR HOLY OWN JOB NOW!
FIsH is the tool -> but building a ROM or recovery is (still) up to you.
These questions may come up in your mind now
Will FIsH void your warranty? Not more or less then rooting your device.
Will FIsH unlock your bootloader? omg NO! read it again!
Is there a risk with FIsH? For example could it soft-brick my device? Well.. absolutely! Safe is the death only. There are always risks especially for untested devices. I do all I can to keep this risk as low as possible and I provided a way to get out of bootloops but again you will get no guarantees here and elsewhere.
Will it work on Android version ICS, KK, LL, MM, N, O, ....? Check the pre-requirements. If you can answer them with yes it should work. If not then not. That easy.
Will I need a recovery partition to use FIsH? No. FIsH ran in RAM only. Even if your device does not have a recovery partition it will work.
Will FIsH work for my device? FIsH is more than just a hack for a special device or model it is a hack for ALL devices of ANY vendor! wtf? yes. Your FISHFOOD is device specific so the question would be better: Will the FISHFOOD (e.g. TWRP) work on my device? The answer is it depends. You need to compile it for your specific device and it should but who knows.
To narrow it a little more down:
you have to met the pre-requirements and there has to be done some things to get a value out of it but those are straight forward for a good compiler/developer like you!
FIsH pre-requirements
Here are the pre-requirements you have to met!
If you can't get them: Close this page and FORGET it (until the day you met those reqs)!
Here are the 2 simple requirements you have to met:
a) root by SuperSU >=v2.76 (greater or equal v2.76)
--> to test this requirement just start the installer of FIsH with --check (see next lines) which will check for all requirements and abort if its not possible
--> for many devices - if not all - this means you HAVE TO downgrade/install LL. It also means that you have to upgrade your SuperSU to this version by e.g. FlashFire if you have a lower version installed!
--> SU by phh is NOT supported => It needs a modified /boot and this would void the boot signing chain!
--> Magisk is NOT supported => It needs a modified /boot and this would void the boot signing chain!
--> I will NOT provide downgrading guides there are plenty of them so search and read.
--> I will NOT provide any guides in rooting your device
--> Before you think about downgrading to LL read about ANTI-ROLLBACK protection some devices and may have! Anti-Rollback means you CAN NOT downgrade - it would HARD-BRICK your device (wtf thinking the vendors who we are?? Is this even legal?!)! Check that before!!
b) you have to be able to disable SELinux in your booted Android
--> You do NOT need to set SELinux permanently to permissive. Just CHECK if you COULD get it MANUALLY. If you can get it OK. If not.. you obviously have not full root access but check the forums maybe there is something you can do about this.
--> I will NOT provide any guides enabling SELinux but some lines later you will see how u can execute the very simple check
--> to test this requirement just start the installer of FIsH with --check (see next lines) which will check for all requirements and abort if its not possible
Those above are hard facts so it may NEVER work with MM. Google has changed the way on how the boot chain will be verified and that means changes in /system will void it from now on.
If MM can get fully rooted somehow/somewhen on your device with SuperSU installed and you are able to disable SELinux the method will work there as well.
If you can not meet ALL of the above 2 requirements lay down and cry.
For the others: calm down and read on!
You can simply test those both requirements by downloading FIsH and execute the installer with the testing parameter:
./install.sh --check
Example output:
############# Checking for busybox
...downloading busybox
--2017-03-24 13:37:44-- https://busybox.net/downloads/binaries/1.26.2-defconfig-multiarch/busybox-armv6l
fishing/busybox 100%[========================>] 1,06M 542KB/s in 2,0s
2017-03-24 13:37:47 (542 KB/s) - »fishing/busybox« saved [1107664/1107664]
Waiting for your device... (you may have to switch to PTP mode on some devices!!)
Android Debug Bridge version 1.0.36
Revision 7.1.1_r13
############# checking Android version
-> Good. Matching exact the required Android SDK: 22
############# checking SuperSU version
-> Matching required SuperSU version: 279
############# temporary disable SELinux
-> command ended successfully (err=0)
SELinux mode: Permissive
... restoring SELinux mode to Enforcing
Tests finished! Check the above output!! Exiting here because in checking mode. Nothing installed.
Click to expand...
Click to collapse
The important lines are:
Matching required SuperSU version: XXX
"SELinux mode: Permissive"
If you see "SELinux mode: Enforcing" or any error messages you may doing something wrong or it just do not work for you.
Limitations!
Keep in mind what I said above: FIsH does NOT unlock your bootloader!
That means with FIsH itself you can NOT "install" anything. FIsH actually is the FRAMEWORK(!) for the FIsHFOOD (ramdisk) you want to load.
One good example is TWRP. This can be loaded even on devices do not having a recovery partition (I believe Sony is one of those).
Let's stay by the example of TWRP.
Keep in mind that when you use FIsH to provide TWRP you can NOT
Install a custom ROM like CM/Lineage (this will modify boot = SOFT-BRICK. for this u would need efidroid or multirom as FIsHFOOD)
Install a custom Kernel (this will modify boot = SOFT-BRICK)
Install a custom recovery (this will modify recovery =may SOFT-BRICK)
In short: do nothing which modifies boot or recovery partitions. Those changes will break your boot signing chain.
You can of course flash everything which is modifying /system /data only (e.g. xposed, Audio mods, etc...)
You're able to backup and restore as well of course and doing any other modifications which you may can't while the Android system is running.
Download
You will get the most current downloads at github but I uploaded all stable releases here at XDA as well to mirror them.
Latest stable (well tested and so hopefully fewest bugs): Download latest release at github (click)
Mirror / older stable versions: DOWNLOAD-TAB (click)
Next stable (lesser chances of issues but may still not released yet): github master branch
LIVE/FRESHEST code u can get (high chances of failures, bugs, unexpected behavior - but the latest and greatest features/bugfixes): github develop branch
FIsH helpers
If you want to reboot directly to an implemented version of FIsH from within Android check out this:
Thanks to @sdembiske who has onboarded the developer @AntaresOne we have an option to reboot into FIsH very comfortable now!
Check it out here: QuickReboot App
Support / IRC Channel
(DEVS/COMPILERS ONLY - NO ENDUSER SUPPORT!)
IRC means Internet Relay Chat and you will get best support here only.
This channel mentioned here is NOT an ENDUSER channel!!
It is for developers and compilers only!)
Endusers should use: #Carbon-user instead !
Choose how to get in:
PC (HexChat and Pidgin are only 2 of them! This list is not complete!)
Android (Yaaic, AndChat, HoloIRC, AndroIRC are only a few of them! This list is not complete!)
Web (KiwiIRC-Web,FreenodeWebchat])
When you have to choose a channel it is: #Carbon-Fusion (this is NOT an ENDUSER channel!! It is for developers and compilers only!)
Endusers should use: #Carbon-user instead !
When you be asked for a server network choose: freenode
Credits (without them - no FIsH!!!)
If you feel that someone / you is missing on this list lemme know!
Chainfire for SuperSU! This is the main part of FIsH.
TeamWin for TWRP
@cray_Doze, @dssmex, @Aaahh and @KeiranFTW for their hijack implementations (e.g. https://forum.xda-developers.com/showthread.php?t=2608408, first steps to a G4 hijack)
@dibbled for creating the android FIsH logo
steadfasterX for the android FIsH !
Famous last words
You may say: When this will work for up to LL only.. Why the hell are u releasing this now? We just see the upcoming Android O and you talk about LL? Well.. This whole thing is just a fun project. I want to learn and I want to give back something which helps others.
So at the end.. If u don't like.. its ok. If you don't need it.. ok. If you can't get any value out of it.. ok..
But maybe it helps others out there instead.
So if you're still not scared and want to continue.. what u r waiting for??
XDA:DevDB Information
android FIsH, Tool/Utility for all devices (see above for details)
Contributors
steadfasterX, BigCountry907, Rees86
Source Code: https://github.com/Carbon-Fusion/android_FIsH
Version Information
Status: Stable
Current Stable Version: v3.0
Stable Release Date: 2017-06-14
Created 2017-03-24
Last Updated 2017-09-11
FIsH bowels (What's inside)
This is for ppl understanding the basics. I will not explain it for dummies
Ok prepare urself for the naked magic
Actually FIsH is mostly similar to other RAM hijacks around with 3 major differences:
1. FIsH is based and depends on SuperSU.
YES - I make my life EASY. You actually need a rooted devices for the most kind of hijacks.
... and I assume the most ppl using SuperSU as their su binary.
... and SuperSU does not require to modify boot (at least until LL)
With this in mind and reading the SuperSU docs I had read that beginning from version 2.76 SuperSU
comes with a special kind of internal init.d support means: It executes custom scripts very early with full SELinux perms available.
Check out the docs here: https://su.chainfire.eu/#updates-sud
2. FIsH tries to be a generic framework with instructions to bring it on all devices.
The hack here is not device specific due to its nature of just executing a custom script by SuperSU.
I've made all scripts inside as easy portable as possible and given hopefully good descriptions and
porting instructions for EACH variable you may need to adjust.
3. it works for up to LL (when u can met the pre-reqs for MM or N, O or whatever comes then - it will work there as well!)
I found only methods for up to KK (e.g. 2nd init and others) but nothing for LL (sorry if I missed someone!) so I started FIsH.
So in sum FIsH is:
a set of scripts and tools which gets executed by SuperSU on early boot stage which hijacks the boot process to bring up your own ramdisk.
FIsH vs Flashfire
Flashfire is absolutely an AMAZING tool! You can backup, installing ZIPs etc all without an unlocked bootloader.
Due to it's nature it is not possible to do EVERYTHING with it (on a locked device), e.g. restoring your whole system partition.
TWRP-in-FIsH (FIsH plus TWRP as FIsHFOOD ramdisk) can provide this - even with a locked bootloader.
Besides this FIsH can do more like (hopefully) bringing you custom ROMs on locked bootloader devices.
FIsH vs Safestrap
Safestrap is supported up to KK and besides this it actually is some kind of MultiROM pendant (+ the hijack part).
FIsH supports any Android version up to LL (GB, ICS, KK, LL,..) as long as the 2 bloody requirements can be met.
Safestrap is a very customized version of TWRP and so limited to updates from there.
FIsH lets you boot any ordinary TWRP completely unmodified. This makes it easier to get new TWRP features on your device.
Besides this FIsH wants to be easy to port for everyone thats why it uses standard components only.
AFAIK it is not supported anymore anyways.
FIsH vs other RAM hijacks
The main reasons why FIsH exists are described already (LL support, easy portable and easy to use) so if you still feel that this is not different from the others... i dunno what to say
FIsHing (Hijacking) means:
FIsH kills all running services, scripts, binaries it can find.
Afterwards it will unmount everything and delete all files left behind from the initial ramdisk.
Now in that more or less clean state it will replace the initrd with the FIsHFOOD - means your own ramdisk like e.g. TWRP.
Some other stuff may happen also but at the end a binary will be started - normally a /init from your own ramdisk
So in sum it is a live replacemnt of the current ramdisk with your own.
Requirement <SuperSU>
It prepares the system to run the FIsH init script and also ensures that SELinux can be run in permissive mode.
Keep in mind that FIsH will enforce permissive mode on boot to do it's job so you do not have to do anything (normally) to let the FIsH boot.
Main components of FIsH:
./install.sh (file)
The installer is the first part you may need to adjust when you want to port FIsH.
This installer is for Linux users only. If you want to have Windows users executing FIsH point them to https://tinyurl.com/FWULatXDA !!
.. but you're free to port the installer to Windows (if u like: bring it back to me so I may include it..)
Your FIsHFOOD (your own ramdisk) has to be compatible to your running STOCK ROM. If you have LL 5.x running your ramdisk has to run / build for it.
important variables:
MINSDK: Adjust this SDK level to match your runnin STOCK ROM which has to be compatible with your FIsHFOOD
MINSU: The minimum SuperSU version required. Do not use anything lower than 279 (means 2.79) because this may not work!
BUSYBOXURI: This is a full URL to a busybox binary compatible with your device. You may have to adjust this but ensure u use a compatible version
because we highly depend on its syntax. The reason why FIsH does not come with busybox bundled is besides license stuff (I do not wanted to provide their
sources ) it may be required that you need another binary then me.
fishing/ (directory)
The real FIsH. Means all files which gets copied to the target device.
fishing/busybox (file - will be auto downloaded by the installer)
You should know what it is..
FIsH comes without busybox but the installer will download it automatically and place it here.
FIsH uses busybox to have all commands with the expected syntax in place and we highly depend on this in the hijack process!
fishing/fishfood.gz (file)
The FIsHFOOD is your own ramdisk - in gziped cpio (e.g. TWRP)
This ramdisk has to be compatible to your device's ROM. Means when you have a STOCK ROM 5.1 installed your ramdisk have to be compatible to LL 5.1.
You can ensure this within the installer (see FIsH Installer) where the Android version will be read and compared before FIsH installs actually.
fishing/fishfood.release (file)
The version and content of your FIsHFOOD
I recommend the following naming convention:
[yourFIsHFOOD]-in-FIsH-v[VERSIONNUMBER]_[DEVICE-MODEL]_[Android-Version]
e.g.
TWRP-in-FIsH-v1_LG-G4_LL
You can write in here whatever you like. The content will be send to the fish.log to identify which version the user has installed (helps debugging).
fishing/callmeFIsH (file)
a caller script which gets executed at very first.
The only task callmeFIsH has is to prepare the whole FIsH to get started out of /system and then starting FIsH from /res. After this it immediately exists to not keep open tasks on /system. callmeFIsH will be placed in /system/su.d/ to get autostarted by SuperSU.
fishing/FIsH (file)
The heart of the FIsH.. Get's called by callmeFIsH.
It will be executed by SuperSU on boot and will hijack the process and prepare and setup everything to let your FIsHFOOD coming up.
fishing/FIsH.me (file)
Functions and vars a user/dev normally wouldn't need to change. They are internal stuff only.
fishing/FIsH.porting (file)
As you're trying to port FIsH this file is your main part when it comes to customization for your device.
Here you should find everything required to be adapted and there are very high chances that you HAVE to adjust this to your device.
fishing/gofishing.sh (file)
The remote installer part. It will actually run as root and prepare your system for FIsH.
You normally will never need to touch this.
FIsH target directories
/system/fish/
All the bowels of FIsH like, FIsH, Busybox, fishfood.gz and fishfood.release go here
/system/su.d/
The FIsH caller (callmeFIsH) goes here
/cache/fish/
The most important directory for you: Here you will find all logfiles required for debugging!
.
Bring FIsH on the menu card (porting FIsH)
So you may now have a little bit understanding of what FIsH can do for you and what not.
When you feel FIsH could work for your device then why not just trying to port it?
This guide should help you for this task.
FIsH was made from scratch with portability in mind.
That means I tried to make it as simple as possible for you to port.
I really hope that task has been accomplished..
1. Met the pre-requirements
You have to understood that FIsH will work ONLY when the pre-requirements are met.
There is no way around or "if i met 1 of the 2 - will it work?" NO. You need BOTH!
If you will be asked by a user to port FIsH -> Ensure that the requirements can be met first before investing your time.
There is an easy test u can go for this: just execute the installer like this:
./install.sh --check
The installer will test and check if it get what it needs and then EXIT without(!) any installation.
2. Build your FIsHFOOD (your custom ramdisk)
I recommend to start with TWRP but choose whatever you like. For this guide i stay with TWRP.
Keep in mind that your FIsHFOOD has to be build with the same sources as your running STOCK ROM.
If you want to support multiple STOCK ROM versions you may have to build multiple FIsHFOOD versions.
Testing your FIsHFOOD is not that easy on locked devices so your only option is to go on once you feel your build is ready.
3. Cook the FIsHFOOD
When you build images or ramdisks you may end up with an image file needed some preparation first:
create a gziped cpio of your initial ramdisk u wanna load
example of twrp build by you:
after your build has finished you will find several img files in your out/ directory and you just need to copy the following file:
out/target/product/<YOURCODENAME>/ramdisk-recovery.img
and move it to:
fishing/fishfood.gz
example of an existing twrp image:
abootimg -x twrp.img (will extract the twrp image)
file initrd.img (should tell something like: gzip compressed data. if NOT: gzip it!)
mv initrd.img fishing/fishfood.gz (moves the extracted initial ramdisk)
Some Notes:
- this cpio has to be compressed with gzip (.gz file ending is importat!)
- the name of this file should be fishfood.gz (exactly this)!
- edit or add a file fishing/fishfood.release and type in what ur fishfood is (e.g. TWRP)
and the version of it course (a good example is: TWRP-in-FIsH-v1_LG-G4_LL)
Click to expand...
Click to collapse
4. Prepare the FIsH installer
Download FIsH and extract it.
open the file install.sh
Check the variables u may need to adjust: Check Post #2 above for some explanations and read the comments within
Note about the Android goFIsHing installer (fishing/gofishing.sh)
You normally do not need to touch this file. It may be required if you cannot install FIsH but that should hopefully not happen..
5. Cook the FIsH
open fishing/FIsH.porting
You will find 2 sections: GLOBAL and PORTING
Each section has hopefully meaningful comments to give you an idea what they do and how you should modify them.
Most vars also have example instructions to find the correct values for your device.
When you're trying to port FIsH you may have to try & error FIsH several times before and you may do not want to use your defined key combo to do so.
For this and also as a convenient option when you want to boot directly into FIsH from Android you can set a special flag to always boot FIsH.
Use it with care because it may let it bootloop while in your testing phase.
The file which activates FIsH without a key press is: /cache/recovery/boot
It can make sense to use this for an easier testing process (don't need any key presses to activate FIsH).
In sum the following command comes very handy while developing:
./install.sh && adb shell "su -c touch /cache/recovery/boot" && adb reboot
So the other way is using a key combo without the need to boot into Android.
For this you will find everything you need in the file fishing/FIsH.porting which you usually have to adjust to your specific device.
Providing user feedback for activating the FIsH:
FIsH gets NOT activated by default. That means if you would reboot your device it will just reboot.
To activate FIsH you need either to use a key combination (provided by you) or using the FIsH file flag.
The idea of the FIsH booting process is (see fishing/FIsH.porting)
a) WAIT_LED: show a LED color indicating FIsH has been STARTED (not ACTIVATED)
---> the user has to press the magic key combo NOW
b) VIBRATE: will vibrate to indicate that the time for pressing the magic key combo is over
c) FISH_LED: show a LED color indicating that FIsH has been ACTIVATED .... or NOT!
d) boot into either Android or your FIsHFOOD depending on what the user wants
If your device does not support different LEDs you can instead use the path to vibrate in the LEDs.
e.g. WAIT_LED="$VIBRATE". This will let the device vibrate instead of showing a LED color.
Whatever you end up with you have to check and adapt the enduser installation guide ofc as well..
6. Let the FIsH swim
Now it's time to test your FIsH port. But BEFORE:
You will take a high risk here at this early stage because it CAN bootloop/soft-brick your device if something goes totally wrong!
I hope I had done all to keep the risk for this low but no guarantees!!
So make a FULL backup of ALL your apps and do not forget to backup your internal storage with all your pictures etc.!!! (just a reminder: TWRP does NOT backup your internal storage!! Read the explanation here)
If the worse case happens you may need to totally bring your device back to pure STOCK so you have been warned!
7. Finally give the FIsH a name
If your FIsH swims... omg.. CONGRATS well done !!! The most hardest stuff is done now! Woot u r a REALLY good dev did u know that?! Your community will praise u!
Of course u r free to choose a name but I recommend to name your FIsH package like this:
[yourFIsHFOOD]-in-FIsH-v[VERSIONNUMBER]_[DEVICE-MODEL]_[Android-Version]
e.g.
TWRP-in-FIsH-v1_LG-G4_LL.tgz
Note: Did u see the different use of dashes and underscores? Keeping it that way is important.
This way we all get a clear understanding what it is, which TWRP-in-FIsH version, for which device and for which STOCK ROM version.
8. Release your FIsH to the wild ocean
Ok I will not tell you how you should release but it would be nice if you tell the users where this all comes from
Do not forget to report back to this thread if you have implemented a port so I can add it here for reference.
An example installation guide for your endusers can be found at Post #7: Go FIsHing
If you struggle somewhere you can find me in the IRC (see OP)
When you have to choose a channel it is: #Carbon-Fusion
When you will be asked for a server network choose: freenode
Trouble / Bootloop fix
if you encounter a bootloop (should never happen but who knows) you have 3 choices at least:
Option 1a: (TWRP-Bootloop) Within TWRP open Advanced -> File Manager -> Goto: /system/su.d and click "select" button -> Delete
Option 1b: (TWRP-Bootloop) From your PC: adb shell rm -rf /system/su.d/
Important: Catch the fish log (see next topic)
Option 2 (this works also for a bootloop without twrp): boot into download mode and use LGLaf to get a shell
then:
setenforce 0 <-- if that doesn't work you may have to do a FULL restore to stock
mount -oremount,rw /system
rm -rf /system/su.d/
reboot. You are out of the bootloop.
Important: Catch the fish log (see next topic)
Option 3: Last resort: Reflash STOCK. sorry.. there is always a risk..
Catch the FIsH logs
when in TWRP (or other ramdisk providing adb shell):
adb shell "cat /cache/fish/fish.log"
adb shell "cat /tmp/recovery.log"
OR - when in Android:
adb shell "su -c cat /cache/fish/fish.log"
adb shell "su -c cat /cache/fish/fish.log.old"
adb shell "su -c tar cvzf recoverylogs.tgz /cache/recovery"
adb pull recoverylogs.tgz
Upload the output to https://paste.omnirom.org and paste the link in the IRC channel
FIsH cuisine (examples)
Example implementations
LG G4 (any model):
TWRP-in-FIsH (https://forum.xda-developers.com/g4/development/locked-twrpinfish-locked-g4-devices-t3573048)
HTC Desire 626s:
FIsH-in-SDCARD - big thx to @BigCountry907 (https://forum.xda-developers.com/showpost.php?p=71630297&postcount=35)
HTC DESIRE 526 VERIZON:
FIsH-in-SDCARD - big thx again to @BigCountry907 (https://forum.xda-developers.com/desire-526/general/super-sd-htc-526-vzw-t3596497)
LG Flex 2 (h955):
TWRP-in-FIsH - big thx @ergo911 (https://forum.xda-developers.com/g-flex2/development/fish-flex-2-t3583093/post71690950)
If you have ported another device or know about one just post to this thread so I can list it here
.
FIsH hydra (multiboot in FIsH)
Bringing multiboot to your device is still not finished yet.
I just wanted to release FIsH now because I was able to proof the working concept based on TWRP and as FIsH is nothing device specific anything else should do so as well.
I have little hope that maybe other developers step in and trying to help me with this but well if not it doesn't matter.. just taking longer
The whole thing of multiboot is a WIP (work in progress) currently.
But now you can prepare yourself for a possible way on this by starting a port of TWRP-in-FIsH first to see if the FIsH concept works for your device. This is strongly recommended to start with whereever we will end up here. Then come back here and hopefully until then I have some news about that topic..
So in theory multibooting by FIsH should be possible. FIsH is just executing your ramdisk so..
The only thing we would need is a way to start any of the tools already available right?
Correct. But.. any of them have its own requirements and way of work. So I need to investigate the bowels of them first to adapt them to FIsH.
Let's think about my first choice: multiboot by efidroid.
While it is quite new for me and it's implementation of booting multiple ROMs is very nice and different from MultiROM. Kudos to MultiROM which provide multi boot of custom ROMs for years but I really like the approach of efidroid (even when I just starting to use it).
When you would be able to boot into efidroid with FIsH you could use as many (unpatched) ROMs as you like. Just 1 or 20 - depending on your disk space mainly. So what does that mean? With FIsH you can hijack the boot and jump in efidroid and now u r able to boot whatever custom ROM you like. That's the theory.
The practice is: efidroid is a bootloader and so completely different to TWRP for example. Using the same hack here will not work without modifications of efidroid and maybe FIsH. The key here is to use the efidroid binary plus the cmdline needed to get a custom ROM booted.
Don't get me wrong what NEVER will work is booting into efidroid like fastboot boot uefi_boot.img can provide. The first thing what I'm trying to achieve is to use the efidroid binary plus the needed cmdline to boot up a manually added custom ROM (thx to the efidroid dev @m1cha by the way.. I promise to bug u as often as possible ). When this works we have won. Well it will be far away from user friendly leaving it this way but it should be possible to write a GUI (e.g. based on AROMA) and then doing the actions efidroid offers in its boot menu. So.. at the end some kind of MultROM but without kexec patches would be possible then.
The other way around: multiboot by MultiROM.
A long player in the game of multiboot and often ported to many devices. The problem here is that it is more than just a ramdisk. It is splitted into a modified TWRP plus MultiROM itself which needs to be flashed from within TWRP. This flashing will inject modifications in your /boot image so it will not work this way on locked devices out of the box.
Before I want to dive into the deeps of a possibly MultiROM implentation for FIsH I want to end my testing for efidroid. So atm I cannot say if there will be a way or not because for this I need to find out what MultiROM really do in the boot image and adapt this change to FIsH. I strongly believe that this can be adapted but my time is limited and my priority lays on efidroid for the moment.
Tbh bringing up the modified TWRP version should be easy because it will work the same way as bringing the ordinary TWRP to FIsH but the other part in the boot image is what I'm not sure about what it does (haven't had the time to look into this yet).
If u feel like a developer and you are able to unbrick a soft-bricked device then feel free to investigate and try on your own and let me know
Update (2017-06-27):
I had the time to look into the possibilities of a multirom port to FIsH.
The bad news: its not easy as thought. Its near impossible yet not complete impossible.
I was a little bit confused by a new compile flag in multirom named MR_NO_KEXEC which allows you to use kernels not patched for kexec-hardboot.
Well but its not that easy..
- using kexec-hardboot needs a patched kernel
- and not using it (MR_NO_KEXEC flag set) will replace the whole boot partition(!) when a secondary ROM boots
So both options will break and can't be used.
The only way to go would be to modify the multirom sources (likely the trampoline part) to behave like efidroid does (heavy usage of loop devices instead of the current phys ones).
You can think of that this modification goes VERY deep, means a LOT of work and requires heavy C / C++ skills.
That's why I can't proceed here. I don't think that it is worth it tbh so I will investigate the other options and abandon the MultiROM approach.
The FIsH plate (sdcard booting)
Thanks to @BigCountry907 we could boot FIsH on every qualcomm device in a manner which has the potential to root any device, boot any ROM and more.
You remember? FIsH can be installed on a rooted device ONLY!
That's still true but with this you can boot e.g. TWRP-in-FIsH even on a not rooted MM / N /... by using the FIsH plate..
The whole process makes use of a qualcomm feature which let you do this.
- the whole process is incredible complicated to get it working!!!
- the whole process is very sensitive and you have to find the right combination of needed partitons to make it work
- the whole process is a complete try & error
- if I mean IF I get this working I could patch the bootloader partition on that sdcard partition without touching the REAL bootloader to test without bricking...
- I work together with @BigCountry907 to get it working but we live in complete diff timezones which makes it not easier
-
If you want to help you can find me in the IRC (see OP)
.
Chew the FIsH (Copying/License)
# This is Android FIsH: Fluffy Incredible steadfasterX Hijack
#
# Copyright (C) 2017 steadfasterX <[email protected]>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with this program. If not, see http://www.gnu.org/licenses/
Click to expand...
Click to collapse
FIsH mutation history (Changelog)
android FIsH v3.0
Released: 2017-06-14
Full Changelog: https://github.com/Carbon-Fusion/an...oidFIsH_v2.0...Carbon-Fusion:androidFIsH_v3.0
Download: see the OP
Summary Changelog:
adding the possibility to exclude easily process names/pid's from being killed (coming with a default exclusion list already)
check it out: `fishing/FIsH.porting` --> `EXCLUDEPROCS / EXCLUDEPIDS`
several fixes regarding the ramdisk extraction
heavy speed improvements regarding kill & mount
adding a version string to FIsH to be able to identify which framework is running
added a better `ps` command than the one provided by `busybox ps`
android FIsH v2.0
Released: 2017-04-11
Full Changelog: https://github.com/Carbon-Fusion/an...oidFIsH_v1.0...Carbon-Fusion:androidFIsH_v2.0
Download: see the OP
Summary Changelog:
Improved general speed by factor 4
Many bug fixes
Many improvements for the installer like a new clean function (uninstall FIsH)
android FIsH v1.0
Released: 2017-03-24
Full Changelog: https://github.com/Carbon-Fusion/android_FIsH/commits/androidFIsH_v1.0
Download: see the OP
Summary Changelog:
first general public release
Go FIsHing (enduser installation guide example)
COPY & PASTE template for your own XDA thread (completely pre-formatted)
installguide_XDA_format.txt
.
Special FIsH Dinner (Notes)
TWRP
The first step to get a success with FIsH is to use TWRP as your FIsHFOOD.
Once started the first thing coming in your mind may be backup & restore but use it with care!
FIsH will brutally unmount /system in - afaik - all cases because there will be open files on it which can't be avoided.
In order to use TWRP successfully you should set at least this special flag:
# Always use rm -rf to wipe
TW_ALWAYS_RMRF := true
This is a workaround because it means wiping /system or /data will behave differently then you might expect normally. Without this flag TWRP will format the partition. With this flag set TWRP will use rm and delete all files on it without formatting the partition.
Very interesting. I actually have a locked (bootloader) device which I'm looking for a way to unlock. I feel likr I could get something (*cough*TWRP*cough*) working because of this. Keep it up :good:
veez21 said:
Very interesting. I actually have a locked (bootloader) device which I'm looking for a way to unlock. I feel likr I could get something (*cough*TWRP*cough*) working because of this. Keep it up :good:
Click to expand...
Click to collapse
Just remember the limitations and leave thanks to @steadfasterX
I am very happy to have stumbled on this today.
I cant wait to get a little deeper into it but i must say very nice job.
I have been working on a big project myself. For creating a clone of any device emmc.
Burn the GPT Partition Table to a External_SD Card and flash the images.
What I have found is that If you make the SD Card right the Qualcomm Devices will boot from the sd card.
To the extent that If i unlock a device that normally can not be unlocked using my XTC-2 clip then copy the images ect from the unlocked device burn to sd card and then boot into H-boot or Download mode the Unlocked Status for example Bootloader Unlock and S-off and Super Cid ect ect ect will be present on the locked device. Thus giving elevated permissions. My setback has been there is no normal way for me to write any partitions yet. Anything I flash through H-boot writes to the SD Card. And I have been unable to make TWRP boot this way.
My initial though is to set up my unlocked device with fish and get it all working. Then create the sdcard image that includes the installed fish scripts. It would be simple to modify the external sd to meet all the fish requirements. even if the device itself can not meet the requirements. My device currently meets the requirements but it isnt for me. Its for the community of people that dont have java cards. This could potentially lead to a way of overcoming both of our current limitations.
All i need is a way to boot TWRP from my elevated privileged sd card and I can utilize that to provide unlocking.
Awesome
BigCountry907 said:
I am very happy to have stumbled on this today.
I cant wait to get a little deeper into it but i must say very nice job.
I have been working on a big project myself. For creating a clone of any device emmc.
Burn the GPT Partition Table to a External_SD Card and flash the images.
What I have found is that If you make the SD Card right the Qualcomm Devices will boot from the sd card.
To the extent that If i unlock a device that normally can not be unlocked using my XTC-2 clip then copy the images ect from the unlocked device burn to sd card and then boot into H-boot or Download mode the Unlocked Status for example Bootloader Unlock and S-off and Super Cid ect ect ect will be present on the locked device. Thus giving elevated permissions. My setback has been there is no normal way for me to write any partitions yet. Anything I flash through H-boot writes to the SD Card. And I have been unable to make TWRP boot this way.
My initial though is to set up my unlocked device with fish and get it all working. Then create the sdcard image that includes the installed fish scripts. It would be simple to modify the external sd to meet all the fish requirements. even if the device itself can not meet the requirements. My device currently meets the requirements but it isnt for me. Its for the community of people that dont have java cards. This could potentially lead to a way of overcoming both of our current limitations.
All i need is a way to boot TWRP from my elevated privileged sd card and I can utilize that to provide unlocking.
Awesome
Click to expand...
Click to collapse
cool. your project sounds amazing as well keep us updated please .. !
btw I personally do not need FIsH .. lol.. i have all my devices unlocked but there were many users for my current device which cannot unlock (LG G4 -> only a few models can be unlocked) so I started FIsH..
so don't give up and if u need help.. go to IRC channel #Carbon-Fusion on freenode.. see us there
.
You may have just saved the Verizon sgs4 from total death. We have to see if selinux can be changed first.
ninjasinabag said:
You may have just saved the Verizon sgs4 from total death. We have to see if selinux can be changed first.
Click to expand...
Click to collapse
just use the installer..
./install.sh --check
will tell you..
.
steadfasterX said:
just use the installer..
./install.sh --check
will tell you..
.
Click to expand...
Click to collapse
Knox disables selinux permission changes by default. So I know the install.sh will return with a negative.
I posted the link to this thread on the VZW S4 forums in the hopes someone will pick up.
ninjasinabag said:
Knox disables selinux permission changes by default. So I know the install.sh will return with a negative.
I posted the link to this thread on the VZW S4 forums in the hopes someone will pick up.
Click to expand...
Click to collapse
So no root available there?
.
Sent from my LG-H815 using XDA Labs
@steadfasterX
In my mind it is threads like this and projects like this that make this place so great.
Same reason for my project. To unlock HTC devices. Verizon devices cannot be unlocked easily.
If you ever need any help with the bash script let me know.
I'm pretty good with it. Bells and whistles like menus and whatnot too.
I was glad to see your shell scripts.
I know the language and it makes this easy.
steadfasterX said:
So no root available there?
.
Sent from my LG-H815 using XDA Labs
Click to expand...
Click to collapse
Root, but barely. We've gotta use kingroot to open the door before replacing kinguser with SuperSU.
This is where the sd card trick works well.
See if we can boot TWRP off of it then we automatically have root access in adb.
Then its a matter of flashing the right partitions ( Device Specific ) to unlock permanently.
DevUt said:
Just remember the limitations and leave thanks to @steadfasterX
Click to expand...
Click to collapse
No , I reached my thanks limit. I do know the proper ways of man :good:
ORIGINAL THREAD HERE: https://forum.xda-developers.com/axon-7/development/2-15-2017-axon-7-msm-8996-cpu-vm-ram-t3557392
This mod was originally created for the Axon 7, but due to several requests, I've modified a version for the G5, please see below, and post questions or comments in the original thread above. Please state you are a G5 user if you have feedback in that thread, to consolidate user feedback and speed up response time.
Custom tuning for a device is always a necessity. "Canned" settings will get you by, but they are certainly never optimized for a specific device. In fact, Linux typically takes a general approach to find harmonic balance in default settings that will, for the most part, work in an acceptable manner for just about any device. There are a lot of resources available on this device, so we should utilize it in a manner appropriate to squeeze out as much battery life and performance as possible without sacrificing much of those outputs, don't you think? This is going to fix that for you.
Here is what is required of you before you begin:
1. Must be rooted
2. Must have the G5 OR a device running the Snapdragon 820, as this modification is not so much device specific, but hardware specific. The important aspect being the snapdragon 820 and the RAM disk size.
3. Must have write protection disabled. If the G5 requires write protection to be disabled, see the code and instruction below:
Using adb shell:
Code:
adb reboot disemmcwp
Using Linux terminal (from your phone, for example):
Code:
reboot disemmcwp
Let's begin.
Getting right to it, here's what I've done:
- modified parameters of the interactive governor, and quite extensively at that (search some of my threads if you want a little bit of a breakdown of the general approach I take)
- reconfigured input_boost parameters
- reconfigured vm parameters (again, the device has a lot of RAM resource, this will utilize it and give you a far better user experience. Basically, I've adjusted dirty_ratio, dirty_background_ratio, swappiness, and other parameters of the virtual machine.)
- disabled zRAM for 6 GB variants (RAM compression, again, not needed on this device really, this mod will save you CPU cycles and power) this will not apply to G5 users, you will still have zRAM enabled.
- remapped minfree parameters for LMK (low memory killer) again only for 6 GB variants
- Tuned CFQ scheduler for flash storage devices
- Tuned "core_ctl" module (needs kernel support, I recommend freeza's latest version of BeastMode. For those wondering, yes, you can still use this mod with the stock kernel. It won't break anything.) again this will only apply to devices that support core_ctl at the kernel.
In a nutshell, that's what we're looking at here. I can guarantee you this will have a significantly positive impact on your device. Turbo time, homies.
How to install????
Easy. First, the file we are replacing is found in /system/etc... it is the "init.qcom.post_boot.sh" file - this file is basically shell scripts, which are applied at boot via this particular shell file.
All you have to do is download the file to your device, open up a file explorer (must have root capability), navigate to the /system/etc folder with said file explorer, mount your /system as RW (read write), delete your stock "init.qcom.post_boot.sh" file, and replace it with mine.
After you've successfully done this, change the new file's permissions to rw-r--r-- (0644), and then reboot!
Or, if you are brave, you can do it manually via a terminal app and get your fingers wet... if you choose to do that, see below:
Make sure the file is located on the root of your internal sdcard in /sdcard, open your terminal app (again, must have root) and type the following commands, hitting enter after each one (be careful to pay attention to the spacing).
Code:
su
Code:
cd /
Code:
mount -o remount,rw /system
Code:
cd /system/etc
Code:
rm init.qcom.post_boot.sh
Code:
cd /sdcard
Code:
mv init.qcom.post_boot.sh /system/etc
Code:
chmod 0644 /system/etc/init.qcom.post_boot.sh
I don't want credit, don't need you to give or offer donations, this is purely for the community in the spirit of Linux ideology. All I ask is for you to hit the thanks button :good:
That's pretty much it, guys. Enjoy!
DOWNLOAD:
Is this a new kernel?
Regards
Nathan
Sent from my LG-H850 using XDA Premium HD app
@warBeard_actual
Here :good: :fingers-crossed:
onestyle007 said:
@warBeard_actual
Here :good: :fingers-crossed:
Click to expand...
Click to collapse
Got it man, working on it now. I should have it up soon.
OP updated... Enjoy guys!
Instructions on how to install are in the OP, post your results here
warBeard_actual said:
OP updated... Enjoy guys!
Instructions on how to install are in the OP, post your results here
Click to expand...
Click to collapse
Question,does that matter for your results if I'm using an other governor,cause I'm currently on alucard?? Stock rom but a custom kernel (Asgard for g5 to be exact)
onestyle007 said:
Questions,does that matter for your results if I'm using an other governor,cause I'm currently on alucard?? Stock rom but a custom kernel (Asgard for g5 to be exact)
Click to expand...
Click to collapse
You will notice minimal to no difference if you are using another governor.
Any pro can do a flashable zip?
Any n00b can copy and paste
Will it work on Android 6?
I don't know it's placebo or not but after replacing the file I have now a better GPS fix and accuracy I am on the H850 so thanks on the OP
yes accurancy gps, not lag boot, very smooth. thanks!!!!!!!!!!!
warBeard_actual said:
OP updated... Enjoy guys!
Instructions on how to install are in the OP, post your results here
Click to expand...
Click to collapse
Okay,last night after I've replaced the file, changed to interactive gov,0.2% lost during the night with wifi and mobile data off here is my current stats. Was a bit surprised though and I'm not sure if it's a bug in reading . But hey that's what it shows.
Rhadamanthis said:
yes accurancy gps, not lag boot, very smooth. thanks!!!!!!!!!!!
Click to expand...
Click to collapse
Same for me, let see if the battery will be better too...
Does this only work on LG Stock?
Hi,thanks for mod,great mod running in Nougat Fulmix rom?
OTOGY2002 said:
Hi,thanks for mod,great mod running in Nougat Fulmix rom?
Click to expand...
Click to collapse
Ues
How to mount System as R/W? When I set permission I get error evice is busy
Worked like a charm using Fulmics Rom 2.0.
Hint for some who have issues with mounting RW: Use FX file explorer for this. Works just fine.
Will monitor and report how it works.
My Problem. I go to /system/etc and I can´t find this file. I´m on Root with FX file Manager. What am I doing wrong?
[HUAWEI WATCH 2 (LTE/4G-Sawshark) & (Bluetooth/BT-Sawfish)-OWDE.180926.001.A1]INTERNATIONAL VERSION
Please read the instructions and notes before flashing anything. Don't ask me if you don't read the instructions.
Code:
###Disclaimer###
[COLOR="Red"][B]WARNING:
IMPROPER FLASHING MAY POTENTIALLY BRICK YOUR DEVICE. SO PLEASE PROCEED AT YOUR OWN RISK. ME OR ANY OTHER DEVELOPER MENTIONED IN THIS POST WILL ASSUME NO RESPONSIBILITY FOR THIS.[/B][/COLOR]
DONATE ME HERE
DONATE-ME
##############################
REQUIREMENT
##############################
- An Unlock bootloader
- Working adb/fastboot and driver - Download from Here
- A custom recovery (twrp) See my twrp thread for custom twrp recovery
TWRP-RECOVERY
##############################
HOW TO FLASH KERNEL/BOOT IMAGE
##############################
- Steps via adb/fastboot
- Unzip the folder and move the boot image into your adb/fastboot folder and apply the following commands
Code:
- adb devices
- adb reboot bootloader
- fastboot flash boot boot.img
- fastboot reboot
##############################
HOW TO FLASH THE ROM AND ROOT
##############################
1- Move the build/ROM and Busybox and Magisk to your watch
2- Make a backup - there's always 1% chance something goes wrong.
3- Full wipe is recommended....Wipe data/Factory reset
4- Flash the ROM, then flash Busybox and Magisk (Please flash in this order, ROM, then Busybox and Magisk)
5- Reboot and complete your initial setting
6- Open Magisk Manager and go to settings and set Automatic Response to Grant
7- Done. Don't forget to donate if you like my work, Thanks.
##############################
ROM AND KERNEL FEATURES [22-Jan-2020]
##############################
[Changelog]-Huawei Watch 2 LTE(Sawshark)+Huawei Watch 2 BT(Sawfish)-[22/Jan/2019]
- Based on latest kernel source (-Source 3.18.24) android-wear with latest security patch
- Linux version 3.18.24 (gcc version 4.9.3 20141215 (prerelease) (UBER-SaberMod-4.9.3_arm-graphite)) #1 SMP PREEMPT Wed Jan 22 9:45:39 CET 2020
- Forced-encryption disabled
- dm-verity removed/disabled
- Auto memory killer set to default
- Sepolicy is patched
- Fix the CPU idle latency unvote timeout. It should reduce the wasting power and CPU go to deep idle states immediately after a request
- Add and use a timer frequency of 100 Hz. It should improve power consumption.
- Add and update/Hide verifiedbootstate from /proc/cmdline in order to fix the failed SafetyNet CTS check(It can still fail through other means)-GOOGLE PAY SHOULD WORK. USE MAGISK TO HIDE ROOT. U may need Gpay enabler
- Remove verifiedbootstate flag from /proc/cmdline - Disable CRC check
- Scheduler optimize/support for heterogeneous multi-core
- Scheduler support for heterogeneous multi-processor systems
- Enable all core with scaling_available_frequencies (200000 400000 533333 800000 1094400 1267200 MHz)- scaling down the frequency of the CPUs to 200 MHz during idl mode and rise the freq. to 1.26Ghz during high pressure.
- Set swappiness to 60
- Change zswap max pool % to 20%. It will reduce CPU usage a lot
- Enable zram & zswap and add 256MB virtual memory default. It will speed up the device a lot
- Removed nolog usage, remove rtb logging from the kernel
- Remove selinux auditing from kernel for lower overhead
- Remove IPC logging from the kernel
- Disabled some kernel parameter to speed up the performance- at the cost of battery/ power consumption
- Remove some logging from several drivers
- Improve memory allocations -Should improve the device a lot
- Add some tweaks to improve the overall speed, apps startup are too faster
- Set zswap compressor to lz4 by default
- APM driver updated again to reduce battery usage during sleeping
- Several other patches to reduce battery usage
- Multi-core scheduler enable/optimized
- APM driver updated reduce battery usage during sleeping
- Fix the wake up time. The screen should wake up more quickly when pressing the button.
- Tweaked the scheduler to reduce/save power by scaling down the frequency of the CPUs or idling them,
- A lot subsystems converted to use power efficient workqueue
- The watch goes to sleep during no action in order to save battery
- Remove debug event logging-Kill the useless logging to reduce overhead
- Remove sync debug entirely to cut down CPU waste in the frame render hot path
- Remove 10 ms CPU idle latency unvote timeout- Doesn't force the CPU to stay out of deep idle states for far longer than necessary, which wastes power
- Disable audit support, usually comes with a measurably significant amount of overhead
- Remove audit dependency
NOTE: THERE IS NO NEED TO FLASH THE LATEST KERNEL IF YOU FLASH THE LATEST ROM.
##############################
DOWNLOAD
##############################
[Huawei Watch 2 4G/LTE]+[Huawei Watch BT][22-Jan]
[DECRYPTION KEY]
WO0FVexxQnrtcODYdmNvnQ
##############################
MAGISK/BUSYBOX/APP-KERNEL-CONTROL
##############################
DOWNLOAD LATEST MAGISK FROM HERE
DOWNLOAD LATEST BUSYBOX FROM HERE
KERNEL CONTROL APP WEAR OS
##############################
How to get the Gpay back...
##############################
1-https://pastebin.com/HKV7cj7H
2-https://forum.xda-developers.com/smartwatch/other-smartwatches/rom-kernel-t3821013/page172
3-https://www.youtube.com/watch?v=UKxGfNxRjo4&t=320s
4-https://forum.xda-developers.com/showpost.php?p=79637148&postcount=1720
##############################
HOW TO FLASH THE STOCK IMAGES-(BACK TO STOCK)
##############################
1- Download and unzip the system image below
2- Attach the watch charger to the watch and plug the USB cord (from the charger) into your computer
3- Use the following adb command to start the watch in fastboot mode: adb reboot bootloader
4- On your computer, navigate to the directory where you unzipped the system image in Step 1. At the top level of that directory, execute the flash-all script:
- On Linux or MacOS, type ./flash-all.sh
- On Windows, type flash-all.bat
5 -DONE. Don't forget to donate if you like my work, Thanks.
STOCK-IMAGES-HUAWEI-WATCH-2-LTE-LEO-DLXX-OWDE.180215.017-SAWSHARK-(13/Oct/2018)
STOCK-IMAGES-HUAWEI-WATCH-2-BT-LEO-BX9-OWDD.180215.018-SAWFISH-(22/7/2018)
##############################
Source/GitHub
##############################
-Source
IF YOU LIKE MY WORK AND WANT ME TO CONTINUE, THEN BUY ME A SHOT OF WHISKY
DONATE ME HERE
DONATE-HERE
Special thanks to:
If you can, donate and respect all the devs and enjoy
@Chainfire for great work in android
@Maxr1998 Big thanks for giving me knowledge and your great work for Asus Zenwatch_3 and your great github guide. Please thank and donate him for all his efforts
@topjohnwu for his great effort (Magisk)Thank you so much
@SuperR.R for the great kitchen
@Xmaster24 for system-less root-
@moneytoo for his great app. Please appreciate and donate him
Pay Enabler
@SuperThomasLab for great tools
Please always support devs and others (soon).
ROM download asking for decryption key?Can fix the link?
Hello All,
Is it possible to install this latest ROM on model without LTE?
Thank you for reply :good:
arthos7 said:
ROM download asking for decryption key?Can fix the link?
Click to expand...
Click to collapse
Hoffmanns said:
Hello All,
Is it possible to install this latest ROM on model without LTE?
Thank you for reply :good:
Click to expand...
Click to collapse
Link are fixed now. It will properly not gonna work on non-lte. I can build a new for non-lte version if some one send me the latest system image and boot image. (I can extract from your watch via teamviewer, in case you can't) But you need to flash the latest firmware without root.
IF YOU LIKE MY WORK AND WANT ME TO CONTINUE, THEN BUY ME A SHOT OF WHISKY
DONATE ME HERE
I will upload a complete latest stock images N7176C (lte) incase anyone wanna go back to latest stock again.
The only thing you have to do is boot into bootloader mod and then run the script by double click on it. After some reboots you will be back on latest stock.
I will combine both Linux and Windows together, use one you prefer.
IF YOU LIKE MY WORK AND WANT ME TO CONTINUE, THEN BUY ME A SHOT OF WHISKY
DONATE ME HERE
Just received my Huawei SW 4G this weekend and after installing Huawei wear I got the alert message that the watch was rooted.
How can I confirm is it's rooted or not.
Thanks
Sent from my ONEPLUS A3003 using Tapatalk
Can anyone who's used this verify that it's notably faster or has improved battery life compared to stock? Or is the difference negligible?
How to build boot.img
Hi Janjan,
I am trying to build a custom kernel for my Huawei Watch 2 (non LTE) and I was wondering if you could share a little of your development work.
How do you actually put the boot image together? I am able to compile the kernel from android-msm-sawshark-3.18-nougat-mr1-wear-release,
which gives me a zImage. I also have the original images. So I tried to unmkbootimg the original boot image and replace the kernel. However, this doesn't seem to work. when I compare the sizes of the supposedly original zImage and the one created from the repository above, their size differs by roughly a factor of 100. So there must be something seriously wrong
What steps do you use to create the kernel and the boot image?
I also checked your github code and tried to use it but it seems to depend on other stuff that is not in your repos. Where did you find the code you have in your repos?
Best regards,
Mogli
janjan said:
I can build a new for non-lte version if some one send me the latest system image and boot image. (I can extract from your watch via teamviewer, in case you can't) But you need to flash the latest firmware without root.
Click to expand...
Click to collapse
Does that offer still stand? If yes I am willing to let my watch be used as a test subject.
mogli19 said:
Hi Janjan,
I am trying to build a custom kernel for my Huawei Watch 2 (non LTE) and I was wondering if you could share a little of your development work.
How do you actually put the boot image together? I am able to compile the kernel from android-msm-sawshark-3.18-nougat-mr1-wear-release,
which gives me a zImage. I also have the original images. So I tried to unmkbootimg the original boot image and replace the kernel. However, this doesn't seem to work. when I compare the sizes of the supposedly original zImage and the one created from the repository above, their size differs by roughly a factor of 100. So there must be something seriously wrong
What steps do you use to create the kernel and the boot image?
I also checked your github code and tried to use it but it seems to depend on other stuff that is not in your repos. Where did you find the code you have in your repos?
Best regards,
Mogli
Click to expand...
Click to collapse
Sure, tell me what you did and your steps for building zImage + modul. I am away from my office for a while.
janjan, have you had success with making a non-lte version?
cdkg said:
janjan, have you had success with making a non-lte version?
Click to expand...
Click to collapse
If you send me the latest boot.img, system.img and vendor.img then I will definitely make.
janjan said:
If you send me the latest boot.img, system.img and vendor.img then I will definitely make.
Click to expand...
Click to collapse
I have the boot.img and system.img. Is there a tutorial or any instructions you could give on how to get the vendor.img?
janjan said:
Sure, tell me what you did and your steps for building zImage + modul. I am away from my office for a while.
Click to expand...
Click to collapse
Hi Janjan,
(Apparently I am not allowed to post links yet, so I am trying my best to explain without them)
1. I got the source code for the Sawshark watch from github (mr1-wear-release). I guess there is no dedicated Seafish kernel source. Short question: There is a choice of 3 different kernel codes. Which one shall I take?
2. I tried to compile this source code without changes (to rule out errors before I make modifications). This works and I get as zImage. What do you mean by modul though? I thought zImage was the only product.
3. Using unmkbootimg, I un-packed an stock boot.img. The unmkbootimg tool says that the boot.img has been compiled with a non-standard mkbootimg program. However the offsets and other values (I am supposed to tune when I use mkbootimg) are contradicting. Eventually, the "non-custom" values recommended by unmkbootimg caused errors in mkbootimg and I ended up using the default values. This worked.
4. When I flash the resulting boot.img my watch gets stuck during boot with the Huawei logo on all the time.
To verify my tools, I tried step 3. in two more ways:
3.1. re-pack the un-packed boot.img, flash it (no errors and boot works)
3.2 pack a boot.img using a zImage obtained from a sawshark boot.img (instead of the seafish). This also worked and boot was successful
I have also looked at the boot.img and zImage files in a hex editor. I can locate the beginning of the kernel but not the end. Also if I did, I wouldn't know how to replace the kernel in hex mode But from what I have understood about mkbootimg, this script does not much more than concatenate zImage and ramdisk and add a header. Is this somewhat correct?
Eventually, I need to turn on some currently disabled kernel features (which is why I am doing all of this ). So I am still trying to figure out the right tools and components. And therefore the question: How do you usually build the kernel and how do you pack it into the boot.img. Do you modify the ramdisk when you replace the kernel?
Best,
Mogli
Instructions to modify ramdisk
Hi Janjan,
How do you disassemble and re-assemble the ramdisk?
Wanted to make a few modifications to the ramdisk.cpio.gz. Again, I wanted to try the tools first. So I unpacked and re-packaged the ramdisk without modifications. After flashing the regenerated boot image, my watch goes into recovery mode...
I found these instructions in a tutorial (again, I can't post links yet... sorry):
For disassembly:
Code:
$ mkdir ramdisk_dir
$ cd ramdisk_dir
$ gunzip -c ../ramdisk.cpio.gz | cpio -i
for re-assembly
Code:
$ find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
Update to my previous post:
I found my mistake in building the kernel:
Instead of using
Code:
make ARCH=arm CROSS_COMPILE=arm-linux-androidkernel-
I was using
Code:
make ARCH=arm CROSS_COMPILE=arm-linux-androideabi-
mogli19 said:
Hi Janjan,
How do you disassemble and re-assemble the ramdisk?
Wanted to make a few modifications to the ramdisk.cpio.gz. Again, I wanted to try the tools first. So I unpacked and re-packaged the ramdisk without modifications. After flashing the regenerated boot image, my watch goes into recovery mode...
I found these instructions in a tutorial (again, I can't post links yet... sorry):
For disassembly:
for re-assembly
Update to my previous post:
I found my mistake in building the kernel:
Instead of using
I was using
Click to expand...
Click to collapse
It seems much better now. Are you in Windows or Linux? I will post my script and tools once I reach my PC. I am away from my PC right now. It means you destroy something during generating or packaging the boot image. Does you kernel /boot.img work without or before editing the ramdisk?
Update:- seems you are in Linux.
janjan said:
It seems much better now. Are you in Windows or Linux? I will post my script and tools once I reach my PC. I am away from my PC right now. It means you destroy something during generating or packaging the boot image. Does you kernel /boot.img work without or before editing the ramdisk?
Update:- seems you are in Linux.
Click to expand...
Click to collapse
Yes, I am on linux. I found a different approach that works for me now:
Code:
Extract the ramdisk.
$ mkdir ramdisk
$ cd ramdisk
$ gzip -dc ../ramdisk.cpio.gz | cpio -i
# Make any changes necessary (e.g., set ro.secure=0 in default.prop).
# Recreate the cpio archive using the mkbootfs binary produced from building the Android source code
$ cd ..
$ mkbootfs ./ramdisk | gzip > ramdisk-new.gz
You said you were able to turn on all the cores. Can this be done by modifying the ramdisk or how do you do this?
mogli19 said:
Yes, I am on linux. I found a different approach that works for me now:
You said you were able to turn on all the cores. Can this be done by modifying the ramdisk or how do you do this?
Click to expand...
Click to collapse
Did I said? But It can't be done by editing the ramdisk only. You need to add and edit alot (add driver edit cores etc) in kernel sources.
Okay, before anyone flames, I did look everywhere in this thread and cannot find it. Does anyone have the link to the flashing instructions for this rom?
janjan said:
Did I said? But It can't be done by editing the ramdisk only. You need to add and edit alot (add driver edit cores etc) in kernel sources.
Click to expand...
Click to collapse
Oh sorry, I thought I had read this on your feature list I actually looked at this and asked myself if there was a way to make the cpu settings permanent:
https://stackoverflow.com/questions/20221680/android-how-to-force-cpu-core-offlineshut-down-cores