Related
BIG FAT WARNING:
NEXT kernel 1.0 - 2.0 requires mali-400-r3p2-01rel3-t31x.zip!
NEXT kernel 2.1 and later requires mali-400-r3p2-01rel3-api29-t31x.zip!
Sources:
Kernel sources at https://github.com/kumajaya/android_kernel_samsung_smdk4x12/tree/cm-11.0
Features:
Based on Samsung OSRC Note 2 N7100, Tab 3 8.0 and Note 8.0 kernel source
Single source for T310, T311, and T315 target (and Note 2 N710x, Note 8.0 N51xx). Only T311 version well tested on my device but both T310 and T315 version boot T311, not working GSM radio of course
Traceable source level changes: https://github.com/kumajaya/android_kernel_samsung_smdk4x12/commits/cm-11.0
Open source Samsung exFAT modules included
Remove a lot of debug message from touchscreen driver, display, mmc, modem, bluetooth, etc. Now, dmesg output more useful than stock kernel
Disable a lot of kernel debugging support
Linaro GCC compiler
The ramdisk based on JB 4.2.2 AMG3 (T310 and T311) and AMH1 (T315), OTA recovery flash disabled
Some tweaks from gokhanmoral's siyahkernel for S3, passive entropy tweak applied
Auto root, SuperSU included please download SuperSU from Google Play. Heimdall v1.4.0 work for our device. For a brand new T31x, flash your device using "sudo heimdall flash --BOOT boot.img" and you will get rooted
Self compiled static BusyBox v1.21.1 in /sbin, android_reboot applet added (a quick but clean port from Android toolbox), swapon applet with priority option. On stock ROM, this version of Busybox will overwrite busybox binary in /system/bin or /system/xbin and save it as busybox.backup
Early boot scripts support (/system/etc/init.d, /data/local/userinit.sh, and /data/local/userinit.d)
Mali GPU driver r3p2-01rel3
KitKat external sdcard write access for user apps patcher
Known Problems:
Thanks To:
gokhanmoral, Chainfire
This part will be expanded. Most of the patches I applied are coded by someone else. Please remind me if I forget to give credits to anybody...
Downloads:
http://forum.xda-developers.com/devdb/project/?id=5210#downloads
Todo:
Dual boot
Special Thanks:
@onemoreidiot, @kutaxov, @bout_time
XDA:DevDB Information
[KERNEL][SM-T31x][SINGLE/DUAL][STOCK/CM] blackhawk's NEXT kernel, Kernel for the Samsung Galaxy Tab 3
Contributors
ketut.kumajaya
Kernel Special Features: Dual boot stock and CM ROM
Version Information
Status: Stable
Current Stable Version: 1.7
Stable Release Date: 2014-07-11
Created 2014-08-01
Last Updated 2014-09-11
Changelog 24/08/2014, NEXT 2.x WIP:
Samsung KitKat support
Auto root reworked
External sdcard write access auto pacher
Mali 400 r3p2-01rel3 API version 29
Changelog 11/07/2014, NEXT 1.7:
Samsung OSRC SM-T310 KitKat NF4 kernel source:
Exynos platform update
Battery, regulator, and charger driver update
Touchscreen driver and firmware update
Flip sensor, WiFi, sound, IR LED and camera driver update
Memory and block related tuning
swap, frontswap, and zswap support, etc
LZO compression/decompression update
Recent GCC versions (e.g. GCC-4.7.2) compatibility fix
Changelog 16/06/2014, NEXT 1.6:
GCC Linaro 4.9.1-2014.05 toolchain
Nintendo Wii remote support, latest CM version needed
Changelog 12/06/2014, NEXT 1.5:
Applied Samsung OSRC N7100 KitKat ND4 update on top of MK9, and then rebase our current kernel to it
Low power mode charging bug fix applied, this kernel compatible to our current JB bootloader and upcoming KitKat bootloader
Incompatibility issue to CM's hwcomposer fixed
New WiFi driver, new exFAT filesystem, arm and exynos spesific update, a lot of updates from Samsung
More efficient method of passing vsync to userspace for CM
GCC Linaro 4.8-2014.04 toolchain
Full changelog https://github.com/kumajaya/android_kernel_samsung_smdk4x12/commits/cm-11.0 . Linaro 4.8 patch still not available on my github, I will push it later
Changelog 21/04/2014, NEXT 1.4:
Kernel update: stop log buffer spam, extra scheduler (sio, vr, and row), interactive governor, revert f2fs quick hack, etc: https://github.com/kumajaya/android_kernel_samsung_smdk4x12/commits/cm-11.0
Ramdisk update to upstream CM (SE Linux context, sepolicy, init and healtd binary)
Install script update for easier future maintenance
Remove workaround fix for write access to the root of ext4 or f2fs formatted SD card
Changelog 26/03/2014, NEXT 1.3:
Fix boot menu reboot to bootloader option
Insecure adb, fix compatibility issue to Omni and Slim ROM
SE Linux policy update
Workaround fix for write access to the root of ext4 or f2fs formatted SD card
Default ueventd config
Compiled AROMA from source
Compiled static busybox from CM source with patched reboot applet
Changelog 16/03/2014, NEXT 1.2:
F2FS filesystem support, completely based on @DerTeufel1980 github commits and small hack in include/linux/blk_types.h https://github.com/kumajaya/android_kernel_samsung_smdk4x12/commits/cm-11.0, Extended PhilZ Touch recovery needed for ext4 to f2fs migration
exFAT filesystem integrated in kernel
In sync to CM 11.0 init changes, CM multi SIM support compatibility issue fixed
Changelog 22/01/2014, NEXT 0.6.4:
Updated kernel source, new Mali GPU kernel driver r3p2
SuperSu 1.91 for stock ROM
Directly flash mali-400-r3p2-01rel3-blobs-t31x.zip (on both ROM for dual boot user) is a must or your device will fail to boot!
As reported by @manup456, graphic glitch occurred in stock ROM with Mali r3p2. Workaround for this issue is "Turn off hardware overlays - Always use GPU for screen compositing" in Settings - Developer but this setting doesn't stick, so you must set it on every boot. Another solution is switch to previous version of NEXT kernel and directly flash Mali r3p1 blobs (on both ROM for dual boot user).
Changelog 16/01/2014, NEXT 0.6.3:
Reworked init script as CM playground
Changelog 09/01/2014, NEXT 0.6.2:
Compatible to the new CM lights module
Changelog 05/01/2014, NEXT 0.6.1:
Flip cover detector, work on both stock and CM ROM
Changelog 30/12/2013, NEXT 0.6:
CM 11.0 support
Changelog 10/12/2013, NEXT 0.5:
Initial T315 support
CM: Ramdisk synced to unofficial CM 10.2
Changelog 02/12/2013, NEXT 0.4:
CM: fix back camera still image capture
Changelog 28/11/2013, NEXT 0.3:
CM: fix bluetooth discovery problem
CM: fix front camera preview
Add PAC ROM support
Stock: SuperSU 1.80, thanks Chainfire
T310 support
Changelog 26/11/2013, NEXT 0.2:
Add lates CM-10.2 nightly 20131125 support
SuperSU 1.75 (for stock ROM), thanks Chainfire
Changelog 25/11/2013, NEXT 0.1 brand:
Stop more spams
Linaro gcc 4.7 compatibility fix, now use GCC Linaro 4.7 compiler
VR and SIO scheduler, SIO as default sheduler
R/W semaphores implemented using ARM atomic functions
Merge espresso10 interactive CPU governor, interactive with EARLYSUSPEND support
Initializing Android USB depending on the rom type for dual boot support
Notify userspace of vsync_time using sysfs for AOSP based ROM support
Partial netfilter update, allow tracking loopback and rate limit some of the printks
Unofficial PhilZ Touch recovery
Attached PhilZ Touch recovery repack for T310 and T311. Both version tested on my T311. Both version not well tested (i.e. backup and restore not tested since have no free space SD card) but since this version based on official P5100, everything should be work correctly. Flash this at your own risk using existing CWM/TWRP recovery or Heimdall v1.4.0 "sudo heimdall flash --RECOVERY recovery.img" command.
I am almost sure @Phil3759 will officially support our device anytime soon.
ROOT + BLACKHAWK + PHILZ TOUCH FOR YOUR BRAND NEW T31X
Single step for root and PhilZ Touch recovery using Heimdall v1.4.0:
Extract both blackhawk kernel boot.img and PhilZ Touch recovery.img
Install Heimdall for your operating system: Linux, OSX, or Windows
Boot your device into download mode, connect it to your computer, flash:
Code:
heimdall flash --BOOT boot.img --RECOVERY recovery.img
Done!
NOTE: I've deleted PhilZ Touch non SELinux version to avoid confusion, total 618 downloads for all variant!
Dual Boot FAQs
Adapted from droidphile's "Dual Boot FAQs" with permission.
1. "Why would I wanna dual-boot?"
A. You don't have to.
Suppose you're more of an aosp rom fan. But misses the HDMI out, bluetooth hands-free and love sammy camera more. Do a minimal installation of sammy rom and boot into it when in need of these features and use aosp rom otherwise.
Or you are a sammy rom fan but love the responsiveness and pure android feel of aosp roms.
And while you can dual boot two sammy or two aosp roms, it doesn't make any sense.
2. "What if I don't need dual booting?"
A. No issues. Kernel won't force to setup 2 roms. You can single boot as before.
3. "Will dual booting change my bootloader or do any dangerous stuff like setting my phone on fire?"
A. NO. Changes are at kernel and ramfs level only. Some space in your internal sd card is used, and also the unused hidden partition mmcblk0p16 is used to store cache of second rom. Dual booting doesn't repartition the filesystem or perform anything scary.
4. "I want to setup dual booting."
A. There are four situations:-
1) Sammy rom now. Want to use aosp as secondary.
2) Sammy rom now. Want to use aosp as primary.
3) Aosp rom now. Want to use sammy as secondary.
4) Aosp rom now. Want to use sammy as primary.
Prerequisites for any setup is
a) Flash latest blackhawk's NEXT kernel. BIG FAT WARNING: For stock Samsung ROM, NEXT kernel 1.0 or later requires mali-400-r3p2-01rel3-blobs-t31x.zip!
b) Flash latest Extended PhilZ Touch recovery: http://forum.xda-developers.com/showpost.php?p=51364377&postcount=33
c) Atleast 90% battery left.
d) 3 GB free on internal SD.
e) Some spare time
1) Present sammy, setup aosp as secondary:-
i) Reboot into recovery
ii) Select "Run Aroma Dual Boot Tool" in Advaced Menu, create system.img for CM/CM based ROM and then close it
iii) Reboot into secondary recovery (red on screen navigation buttons)
iv) Flash aosp ROM as 2nd ROM
v) Flash blackhawk's NEXT kernel again
2) Present sammy, setup aosp as primary:-
i) Reboot into recovery
ii) Nandroid backup your current sammy ROM
iii) Select "Run Aroma Dual Boot Tool" in Advaced Menu, create system.img for Samsung stock/stock based ROM and then close it
iv) Reboot into secondary recovery (red on screen navigation buttons)
v) Nandroid restore your sammy ROM as 2nd ROM
vi) Flash blackhawk's NEXT kernel again
vii) Reboot into primary recovery
viii) Flash aosp ROM as 1st ROM
ix) Flash blackhawk's NEXT kernel again
3) Present aosp, setup sammy as secondary:-
Same as (1), instead of flashing aosp to second, flash sammy to second.
4) Present aosp, setup sammy as primary:-
Same as (2), instead of flashing aosp to first ROM, flash sammy.
NOTE:
-To dual boot Two Aosp or Two Sammy roms, just follow (1) or (2) (depending on which one of them you want as primary/secondary), just flash Sammy instead of aosp or aosp instead of sammy.
5. "What things should I be taking care off while dealing with dual booting?"
A. - Make sure where you are: in primary or secondary recovery.
6. "How to boot into primary rom?"
A. AROMA based boot menu will help you on every boot.
7. "How to boot into secondary rom?"
A. AROMA based boot menu will help you on every boot.
8. "Is kernel partition shared?"
A. Yes. Same kernel boots both roms.
9. "If I flash another kernel (that doesn't support db) do I lose dual booting?"
A. Yes
10. "I lost dualbooting after flashing another kernel. I didn't do anything to second rom files in sdcard/.secondrom. How can I get db back?"
A. Just flash the latest blackhawk's NEXT kernel
11. "Will there be any performance degradation on the rom used as secondary compared to primary?"
A. NO
12. "Will my phone run slow overall because of db?"
A. NO
13. "How to flash a newer version of 1st rom?"
A. As usual, just flash it from primary recovery. Flash blackhawk's NEXT kernel again
14. "How to flash newer version of 2nd rom?"
A. Just flash it from secondary recovery. Flash blackhawk's NEXT kernel again
15. "Would upgrading 1st or second rom cause other rom to fail on boot?"
A. No. Partitions of other rom are not touched during upgrading.
16. "I miss the recovery I used before, so much.."
A. PhilZ Touch not bad at all.
17. "User apps of 1st rom are automatically available for second rom?"
A. NO. However, if you had backed them up using Titanium Backup or similar apps, just restore apps while on second rom.
18. "I wanna keep separate backup for apps in both the Roms, since I use one Rom for say entertainment and other productivity."
A. Setup different backup directory in Titanium Backup in 1st and 2nd rom.
19. "I don't see STweaks app in second rom."
A. This is blackhawk's NEXT dual boot solution for Galaxy Tab 2, a free implementation of gokhanmoral's Siyah dual boot.
20. "Do I need to anything special before flashing a newer blackhawk's NEXT kernel?"
A. NO. Just flash kernel in recovery - whichever you used to do. Kernel image is copied to the unified kernel partition
21. "How can I run same STweaks settings of 1st Rom in 2nd Rom?"
A. This is blackhawk's NEXT dual boot solution for Galaxy Tab 2, a free implementation of gokhanmoral's Siyah dual boot.
22. "How do I remove everything related to DB and run single boot again?"
A. In primary recovery, flash blackhawk's NEXT tool and delete 2nd ROM system image. OR delete .secondrom directory in /data/media while on 1st Rom.
23. "If secondrom files are kept in /data/media, will wiping data in recovery erase second rom files?"
A. NO. /data/media is skipped in CWM recovery.
24. "I read somewhere that both rom data partition use the same space. Doesn't that mean my apps are shared across roms?"
A. NO. It just means they uses same partition. They're still different directories.
1st rom data = /data
2nd rom data = /data/media/.secondrom/data
25. "Will hitting "Boot into Secondary Recovery" in recovery boot menu change my recovery?"
A. NO. It just runs (not flash) an alternate recovery so that you can configure dualboot settings.
26. "How do I backup 1st Rom and 2nd Rom?"
A. To backup 1st Rom, do what you did to backup rom while you were single booting a while ago.
To backup 2nd Rom, use the secondary recovery.
27. "Is there an easier way for dual-boot?"
A. Yes, send your device to me.
28. "DB architecture?"
A. Like you know, every rom has a /data, /system, /cache partition and a kernel to boot.
For primary rom, it's
mmcblk0p21 = /data
mmcblk0p20 = /system
mmcblk0p19 = /cache
And these won't change whether you're single booting or dual booting.
For secondary rom, data and system is stored in internal sd, cache in hidden partition. Note that internal sd in our device is mounted to /data/media.
We have data as a directory, System as an image in data/media/.secondrom. Cache in mmcblk0p16 which is hidden partition and not used otherwise.
- When second rom is booting, second rom data is bind mounted to mmcblk0p21 as /data/
- data/media/.secondrom/system.img partition is mounted as /system.
- mmcblk0p16 is mounted as /cache.
More FAQs will be added and the list will be updated as DB is improved.
Build kernel and kernel modules for Samsung Galaxy Tab 3 8.0 SM-T31x Exynos 4212
Ketut P. Kumajaya <ketut.kumajaya at gmail dot com>, Oct 2013
Samsung Open Source Release Center: http://opensource.samsung.com/reception/receptionSub.do?method=sub&sub=F&searchValue=sm-t31
Samsung OSRC exFAT source: http://opensource.samsung.com/reception/receptionSub.do?method=sub&sub=F&searchValue=exfat
Working kernel source, compilable and tested on SM-T311: https://github.com/kumajaya/android_kernel_samsung_lt01
I assume your home directory is /home/android
Clone kernel source repo:
Code:
$ cd /home/android/
$ git clone git://github.com/kumajaya/android_kernel_samsung_lt01.git
Create an environtment text file, save it as /home/android/build.env (change CROSS_COMPILE to point to your toolchain):
Code:
export CROSS_COMPILE='/opt/toolchains/arm-eabi-4.6/bin/arm-eabi-'
export LDFLAGS=''
export CFLAGS=''
export SUBARCH=arm
export ARCH=arm
Import environtment file above (dot+space+build.env), create build directory outside kernel source directory, and start the building process:
Code:
$ cd /home/android/android_kernel_samsung_lt01
$ . /home/android/build.env
$ mkdir -p /home/android/build/lt01
$ make O=/home/android/build/lt01 mrproper
$ make O=/home/android/build/lt01 tab3_3G8_01_defconfig
$ make -j8 O=/home/android/build/lt01
Copy the resulting kernel and modules to a binary directory:
Code:
$ mkdir -p /home/android/build/lt01-bin
$ cp /home/android/build/lt01/arch/arm/boot/zImage /home/android/build/lt01-bin/
$ find /home/android/build/lt01/ -type f -name *.ko -exec cp {} /home/android/build/lt01-bin/ \;
Your kernel and all kernel modules ready in /home/android/build/lt01-bin/
{
"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"
}
The resulting kernel also already tested as PhilZ Touch recovery kernel, running on SM-T311 PhilZ Touch repacked from PhilZ Touch recovery for Galaxy Tab 2 10.1 target
Samsung Galaxy Tab 3 8.0 original boot logo:
oc kernel ?? thanks.
Finally a developer with GTab 3 8inch :good: :good:
Can't wait to see a flashable zip and try on my tab
Just got a black screen of death when trying to replace Samsung boot logo Solved: reflash my own param.bin Odin flashable tar.md5
rothshek said:
oc kernel ?? thanks.
Click to expand...
Click to collapse
There's no OC commit: https://github.com/kumajaya/android_kernel_samsung_lt01/commits/master
Kernel and unofficial PhilZ Touch recovery repack attached at post #1.
Kernel: almost stock, compiled using gcc linaro 4.7, a lot of kernel debugging support disabled, still leave all Samsung kernel spams, restricted root disabled
Ramdisk: self compiled busybox included, auto root, init.d support, flash recovery disabled
Open source, commit history: https://github.com/kumajaya/android_kernel_samsung_lt01/commits/master
PhilZ Touch repack based on official PhilZ Touch for Tab 2 10.1, thanks @Phil3759
Still in development
Flash the kernel and/or PhilZ Touch using existing CWM/TWRP recovery
Derp!
ketut.kumajaya said:
Kernel and unofficial PhilZ Touch recovery repack attached at post #1.
Kernel: almost stock, compiled using gcc linaro 4.7, a lot of kernel debugging support disabled, still leave all Samsung kernel spams, restricted root disabled
Ramdisk: self compiled busybox included, auto root, init.d support, flash recovery disabled
Open source, commit history: https://github.com/kumajaya/android_kernel_samsung_lt01/commits/master
PhilZ Touch repack based on official PhilZ Touch for Tab 2 10.1, thanks @Phil3759
Still in development
Flash the kernel and/or PhilZ Touch using existing CWM/TWRP recovery
Click to expand...
Click to collapse
PhilZ Touch runs on T-310? ExFat memory cards supported? There is support for the work of internal memory?
marincax said:
PhilZ Touch runs on T-310? ExFat memory cards supported? There is support for the work of internal memory?
Click to expand...
Click to collapse
I will upload T310 version. T311 version attached at post #1 also work on T310 but every device have a different identity (default.prop). Internal and external memory works, including exFAT support.
I've been disable so much kernel spam but still a lot left flooding the kernel message buffer, just saying
ketut.kumajaya said:
I will upload T310 version. T311 version attached at post #1 also work on T310 but every device have a different identity (default.prop). Internal and external memory works, including exFAT support.
Click to expand...
Click to collapse
Thanks a lot for your reply.:good:
Will be there be enough to replace default.prop in a version for T-311 on default.prop recovery from original T-310?
marincax said:
Thanks a lot for your reply.:good:
Will be there be enough to replace default.prop in a version for T-311 on default.prop recovery from original T-310?
Click to expand...
Click to collapse
Yes, with 2 lines modification:
Code:
ro.debuggable=1
persist.sys.usb.config=mtp,adb
ketut.kumajaya said:
I've been disable so much kernel spam but still a lot left flooding the kernel message buffer, just saying
Click to expand...
Click to collapse
Please leave messages Logcat, kmsg and dmesg. :crying:
Yes, with 2 lines modification:
Code:
ro.debuggable=1
persist.sys.usb.config=mtp,adb
Click to expand...
Click to collapse
Thank you so will I do.
Still changed:
ro.secure=0
ro.adb.secure=0
marincax said:
Please leave messages Logcat, kmsg and dmesg. :crying:
Thank you so will I do.
Click to expand...
Click to collapse
Don't worry, disable the kernel message is really a bad idea :laugh: How about switchable logcat?
ketut.kumajaya said:
Don't worry, disable the kernel message is really a bad idea :laugh: How about switchable logcat?
Click to expand...
Click to collapse
Yes, it will be good. :good:
I started my little own project to port exfat, ntfs and ext4 read-write support for OTG storage devices from CM to AOSP.
It was fun to discover how git works and understand how a little portion of the android system works.
Eventually, I was able to port it to AOSP, but I still have some questions and I have to admit there are still huge black holes in my mind about the soruce code. That's why I want ask you to tell me what I did wrong, what was unnecessary, what else I still have to add or modofy and why.
My source code based on AOSP kitkat-mr2.1-release branch.
I added Add support for USB OTG and HACK: Disable secure discard commits to device/lgehammerhead.
Question 1: HACK: Disable secure discard is a fix for when I select "Erase USB storage" in Settings/Storage to not take too long?
I added Make "SD Card removed" notification dismissible commit to frameworks/base
I added Dont show "Erase SD Card" when there is none commit to packages/apps/Settings
I added blkid: Add support for probing exFAT commit to external/e2fsprog
I merged 6 commits into one commit and added it to external/sepolicy. You will find the links for merged commits in the commit I made.
Question 2: I think, I dont need the changes about ASEC containers, because if I understand right these ASEC commits for phones which has support for installing apps to sdcard. Am I right?
Question 3: I was in trouble with system/vold. There were so much commits made by CM. It is beyond my knowledge to decide which commit I need for exfat/ntfs/ext4 rw otg support at the moment, therefore I decided to use the CM system/vold instead of the AOSP one, and fixed a build error. Is that okay or should I find the commits for the ntfs/exfat/ext4 rw otg support?
Question 4: Is it okay to solve that above mentioned build error that way or should I resolve the conflict with the selinux_android_restorecon funciton in external/libselinux/src/android.c (CM version)
I added Add libminshacrypt static lib commit to system/core to fix a lib dependancy needed by something from system/vold.
I added the repos of the exfat, ntfs and fuse sources from CM to my manifest and also made it github compatible and added the modified repos.
I added the exfat/ntfs modules to build
After some testing it tunred out I cannot format pendrives formated as NTFS or ext4 because the binaries (mkntfs and mke2fs) were missing qhich could format the storage device to ntfs or ext4. Luckily the modules already have been declared in their Android.mk files so I just had to add that two modules mkntfs and mke2fs.
I am sorry if something is confusing or not understandable. I am really at the begining of programing android.
Also here is a build the AOSP rom with exfat/ntfs/ext4 rw otg support. You have to flash it in fastboot, because the zip packages has recovery.img which will overwrite your recovery during flashing. Just extract it then fastboot flash system system.img then fastboot flash boot boot.img and do a factory reset.
bitdomo said:
I started my little own project to port exfat, ntfs and ext4 read-write support for OTG storage devices from CM to AOSP.
It was fun to discover how git works and understand how a little portion of the android system works.
Eventually, I was able to port it to AOSP, but I still have some questions and I have to admit there are still huge black holes in my mind about the soruce code. That's why I want ask you to tell me what I did wrong, what was unnecessary, what else I still have to add or modofy and why.
My source code based on AOSP kitkat-mr2.1-release branch.
I added Add support for USB OTG and HACK: Disable secure discard commits to device/lgehammerhead.
Question 1: HACK: Disable secure discard is a fix for when I select "Erase USB storage" in Settings/Storage to not take too long?
I added Make "SD Card removed" notification dismissible commit to frameworks/base
I added Dont show "Erase SD Card" when there is none commit to packages/apps/Settings
I added blkid: Add support for probing exFAT commit to external/e2fsprog
I merged 6 commits into one commit and added it to external/sepolicy. You will find the links for merged commits in the commit I made.
Question 2: I think, I dont need the changes about ASEC containers, because if I understand right these ASEC commits for phones which has support for installing apps to sdcard. Am I right?
Question 3: I was in trouble with system/vold. There were so much commits made by CM. It is beyond my knowledge to decide which commit I need for exfat/ntfs/ext4 rw otg support at the moment, therefore I decided to use the CM system/vold instead of the AOSP one, and fixed a build error. Is that okay or should I find the commits for the ntfs/exfat/ext4 rw otg support?
Question 4: Is it okay to solve that above mentioned build error that way or should I resolve the conflict with the selinux_android_restorecon funciton in external/libselinux/src/android.c (CM version)
I added Add libminshacrypt static lib commit to system/core to fix a lib dependancy needed by something from system/vold.
I added the repos of the exfat, ntfs and fuse sources from CM to my manifest and also made it github compatible and added the modified repos.
I added the exfat/ntfs modules to build
After some testing it tunred out I cannot format pendrives formated as NTFS or ext4 because the binaries (mkntfs and mke2fs) were missing qhich could format the storage device to ntfs or ext4. Luckily the modules already have been declared in their Android.mk files so I just had to add that two modules mkntfs and mke2fs.
I am sorry if something is confusing or not understandable. I am really at the begining of programing android.
Also here is a build the AOSP rom with exfat/ntfs/ext4 rw otg support. You have to flash it in fastboot, because the zip packages has recovery.img which will overwrite your recovery during flashing. Just extract it then fastboot flash system system.img then fastboot flash boot boot.img and do a factory reset.
Click to expand...
Click to collapse
1- Seems like it. Don't think you need "Dont show "Erase SD Card" when there is none" on the N5 though.
2- Yup, ASEC installs on external sdcards for devices which don't have sufficient internal storage.
3- Beyond my knowledge.
4- In my experience it's always best to solve stuff, not just remove stuff.
Let me get back to you, have something nice at home to do something about that recovery being included in the OTA package.
Meanwhile, after the zip is done, just unzip it somewhere, remove recovery.img and the line which calls it on the updater-script. Then people can flash it without fear of overwriting their installed recovery.
I was outdoors today man. Didn't forget, just that I went skating all day.
beekay201 said:
I was outdoors today man. Didn't forget, just that I went skating all day.
Click to expand...
Click to collapse
I spent my last three days on a vacation.
That is why I haven't responded yet.
Thank you for your advice. I was able to modify ota_from_target_files in the build repo's tools/releasetools folder to not include the recovery in the zip and the commands for the recovery in the updater script. I will report you in 2-3 day about my progress and maybe I will ask you a few more questions if it does not bother you.
Hello..
Yesterda I do some test to port MultiROM recovery on our phone, after apply 6 of kexec hardboot patches files, compiling zImage was fine and after test and boot fine but kernel doesn't really stable (perhaps for missed patches), reading Tasssadar porting guide, there are 3 files that should be patches to get multirom work.
@GHsR
@CoolDevelopment
what are the evquivalent files of device_lge.c and restart.c on our kernel source to apply the rest of pacthes? thanks a lot
Porting guide:
https://github.com/Tasssadar/multirom/wiki/Porting-MultiROM
Capri patches:
https://github.com/hak86/capri_implement_kexec_hardboot/tree/aosp
Device tree:
https://github.com/hak86/android_device_samsung_i9105p/tree/omni-5.0
There are no completely equivalent files. The capri mach kernel works in a different way than qualcomm ones. You need to understand the source code and implement things by yourself. Important is, that you wipe the memory at the correct addresses
Good luck
CoolDevelopment said:
There are no completely equivalent files. The capri mach kernel works in a different way than qualcomm ones. You need to understand the source code and implement things by yourself. Important is, that you wipe the memory at the correct addresses
Good luck
Click to expand...
Click to collapse
to not talk about compatible device tree to build recovery.img, it's generate a 10mb of recovery.img that image we can't install on our recovery partition due to space issue.
I found this one called DualBoot Patcher, actually it's for qualcomm devices, but I think we can port quickly, we just need to add ramdisk from our phone,
http://forum.xda-developers.com/showthread.php?t=2447534
haky 86 said:
to not talk about compatible device tree to build recovery.img, it's generate a 10mb of recovery.img that image we can't install on our recovery partition due to space issue.
I found this one called DualBoot Patcher, actually it's for qualcomm devices, but I think we can port quickly, we just need to add ramdisk from our phone,
http://forum.xda-developers.com/showthread.php?t=2447534
Click to expand...
Click to collapse
You can get a dualboot recovery but to actually use multirom you need kexec-hardboot
LazyFlasher & no-verity-opt-encrypt
INTRODUCTION
Hello Users and Developers of XDA!
LazyFlasher is a custom kernel flashing tool designed to make it easy to dynamically modify ramdisks and inject kernel binaries into the current boot image.
It's the swiss army knife of kernel flashing for use in Team Win Recovery Project.
The intent behind it was to allow a 1 custom kernel fits all approach, where your users can flash single zip on any ROM for a particular device,
allowing your kernel to be compatible with the vast majority of custom ROMs already out there. It takes away the pain of building custom boot.img
for each and every variant a user requests and puts it into 1 low maintenance intelligent universal flashable zip.
You might already know of @osm0sis's AnyKernel2 project. This approach is similar to that. Back in late 2015 I decided to design a more compatible, more friendly, and more feature filled version. Since then, AnyKernel2 has apparently improved a lot so if LazyFlasher doesn't accomplish what you need, AnyKernel2 probably will.
LazyFlasher does not currently support ELF boot images.
For users of no-verity-opt-encrypt: This thread can also be used to discuss the no-verity-opt-encrypt project which is just a minimal version of the LazyFlasher framework.
Disqus thread: https://www.xda-developers.com/xda-...-is-an-alternative-to-the-anykernel2-project/
THE GITHUB REPOSITORY
You can find LazyFlasher's development and download it here: https://github.com/jcadduono/lazyflasher
LazyFlasher source code is distributed under the BSD 2-clause license. You can do anything you want with it, however, some of the binaries used by it are under GPLv2 or GPLv3 licenses.
FEATURES
ChromeOS support (ChromeOS test-key signing and recognition)
MediaTek device support (MTK headers)
SELinux policy injection support via sepolicy-inject
Example scripts to disable dm-verity or forced encryption during the install process (010-no-force-encrypt, 015-no-dm-verity)
A process that executes a sorted list of scripts for making the desired modifications (separate from the framework)
Handily unpacks, decompresses, applies changes, compresses, and repacks boot images quickly and safely
Supports Gzip, LZ4, Bzip2, and LZO ramdisks. Support for LZMA and XZ is a work in progress
Supports arm (armv7), arm64 (aarch64), x86 (i386), x86_64 (amd64), mips, and mips64 architectures
Supports dtb.img replacement (place it in the root folder named "dtb.img")
Scans fstab and partition locations for the boot partition, optionally allows a preset location
Intelligently installs kernel modules by copying the previous layout of /system/lib/modules and creating symlinks
Creates modprobe supported /lib/modules aliases if kernel modules are included in the installer (030-kernel-modules)
Installs new files to the ramdisk and sets their permissions automatically based on file type from ramdisk-patch (020-patch-ramdisk)
Includes an optional bbe tool for applying binary patches
Unnecessary architectures and tools can be removed to save space
Many useful functions and variables included in the patch.d environment to simplify modification/patching scripts (patch.d-env)
Simple "make" build system
SETTING UP LAZYFLASHER
LazyFlasher is only designed for building on Unix based systems such as Linux, Mac OS X, and FreeBSD.
To download it (feel free to fork it so you can have a copy on your GitHub to modify instead!):
Code:
cd ~/build
git clone -b kernel-flasher https://github.com/jcadduono/lazyflasher.git
cd lazyflasher
To use LazyFlasher, you'll probably want to take a look at the Makefile, config.sh, and META-INF/com/google/android/update-binary (a shell script).
There's a few things you can change there to personalize it to your needs.
(make another git commit to save your setup!)
You should also check out the README! There is a lot of useful information there.
Once the installer is set up to your liking, all you have to do to build it is copy the resulting kernel binary from your kernel build output into the lazyflasher folder.
If you have built with kernel modules (make modules_install), copy build/lib/modules -> lazyflasher/modules.
Now simply run:
Code:
make
A TWRP flashable zip and sha1sum is created!
You should consider signing the zip with AOSP test-keys so that users can verify its integrity before flashing it.
LOOKING TO TRIM DOWN THE INSTALLER?
I have forked the kernel-flasher branch to a branch called kernel-flasher-arm64-minimal. This provides all the features of kernel-flasher except sepolicy injection and bbe, and only supports arm64 devices. It reduces the minimum zip size from 1860 KB to 200 KB.
You can use this branch instead if you like. If you're using another architecture, just look at the trimming commit as an example and apply it for your arch.
BUT I AM ON LE WINDOWS!
How did you build your kernel binary?!
Anyways, there is an alternative for building it on Windows.
You can download the LazyFlasher kernel-flasher branch as a zip file from GitHub and extract it somewhere on your PC.
Make your modifications using Notepad++.
You can then use a tool such as 7-zip to create a zip file by selecting everything in the folder, right clicking, and going to 7-Zip -> Add to "lazyflasher.zip".
LIMITATIONS AND KNOWN ISSUES
It will not run on TWRP built in Android 4.3 or earlier (usually builds older than 2.8.0.0)
Requires Busybox to exist in the TWRP build. All official builds should have this.
There may occasionally be some devices that are unsupported due to extreme modifications made to the boot image format by the manufacturer. If you have one of these devices, feel free to contact me and I will try to add support for it if it is worth the effort.
If you have an issue, please gather a recovery.log from TWRP after flashing and I will try to look into it. I can't do anything to diagnose your problem without a recovery log.
Code:
adb pull /tmp/recovery.log
JUST WANT TO DISABLE VERITY/ENCRYPTION?
You can build lazyflasher by itself, empty, without a kernel image or modules and flash it!
It's already set up to automatically disable verity and make encryption optional.
Alternatively, there's a branch already set up called no-verity-opt-encrypt. You can find prebuilt official zips at: https://build.nethunter.com/android-tools/no-verity-opt-encrypt/
WHO ELSE IS USING LAZYFLASHER?
I'll keep a list here of cool projects that are using it. Feel free to ask for yours to be added.
The Kali Linux NetHunter project (GitHub, Website)
no-verity-opt-encrypt, no-verity-force-encrypt, twrp-data-fstype-swap (Website/Download)
WHAT IS LAZYFLASHER USING?
LazyFlasher makes use of a few open-source projects. You can find their source code here:
bootimg / libbootimg for boot image unpacking/repacking - https://github.com/jcadduono/android_external_libbootimg
bbe for binary patching - https://github.com/jcadduono/android_external_bbe
bzip2 for ramdisks - https://github.com/jcadduono/android_external_bzip2
lz4 for ramdisks - https://github.com/jcadduono/android_external_lz4
futility for ChromeOS boot image signing - https://github.com/jcadduono/platform_external_vboot_reference
sepolicy-inject for sepolicy policy injection - https://github.com/jcadduono/android_external_sepolicy-inject
XDA:DevDB Information
LazyFlasher, Tool/Utility for the Android General
Contributors
jcadduono
Source Code: https://github.com/jcadduono/lazyflasher
Version Information
Status: Stable
Current Stable Version: 5.1
Stable Release Date: 2017-02-01
Created 2017-02-02
Last Updated 2017-02-07
We should give this man award.
The Job that he has done with this and Nethunter is just amazing.
Thank you and keep up the good work
Nice tool. Keep up a good work
Great Work! Hope i can include it into my Projects in the Future...
Thanks a lot for that!
You are a goddamn god.
Honestly Annoying said:
You are a goddamn god.
Click to expand...
Click to collapse
thx dude, usually that phrase is reserved for Chainfire accomplishments
y u nu support mah Indian AF MTK fone @jcadduono
Kidding, awesome work on this though!
Good one , this man develops for the developers !
Is it possible to have this on i9100 ? AnyKernel2 doesn't work with i9100
Skyline said:
Is it possible to have this on i9100 ? AnyKernel2 doesn't work with i9100
Click to expand...
Click to collapse
nope, no plans to support that device, surprised they are still out there, i would expect most to be dead emmc by now. :|
you can probably modify boot-patcher.sh to copy partitions to split-img folder then flash them back instead of using bootimg
i don't even know if lazyflasher's binaries will run on any of the i9100 twrp builds. might be too old.
if i can get an example layout of i9100's partitions i can fork it to a new branch, called kernel-flasher-sgs2 and make it compatible for you guys.
jcadduono said:
nope, no plans to support that device, surprised they are still out there, i would expect most to be dead emmc by now. :|
you can probably modify boot-patcher.sh to copy partitions to split-img folder then flash them back instead of using bootimg
i don't even know if lazyflasher's binaries will run on any of the i9100 twrp builds. might be too old.
if i can get an example layout of i9100's partitions i can fork it to a new branch, called kernel-flasher-sgs2 and make it compatible for you guys.
Click to expand...
Click to collapse
They are too old but still supported by lineage 14.1 and official twrp 3.0.2-1 without any problems
osmOsis dev of anykernel2 said that i9100 and older devices are having different boot img header format when i tried to run anykernel2 script it says Android magic is not found something like that
interesting tnx
Wow...
I'm just recognizing now, how powerful lazyflasher is ...
Setting default.prop values and settings. Disable Encryptions and so on. Wish I could contribute something but I'm still learning how it works. For now I've just included lazyflasher into my PATCH to disable DM Verity and forced Encryption and to make some edits on the default.prop. That's really useful since the build.prop doesn't allows such deep changes.
@jcadduono what would be in the Theory possible with the Lazyflasher? Could we add things like Gouverneurs or default Kernel Clockings? Init.d Support? Sorry if I sound noobish :angel:
So, uh, is there a TL;DR for lazy people? :silly: :laugh:
@jcadduono this is absolutely awesome. thank you for your hard work.
Hope that someone can dev nethunter to Asus zenfone 5 t00f :fingers-crossed:
can you please make a tutorial vedio of it because i don't get it and i'm sorry for my stupidity
Will it work for Android Oreo / LOS 15?
Did anyone succeeded in removing dm-verity? I got this error
good
The Kernal Source has been released by Razer.
Links to the source is at the bottom of this page:
http://support.razerzone.com/mobile/razer-phone
Here are the links to the source just in case:
MR1 Releases:
Build 853
Build 851
Production Releases:
Build 822
Build 813
It has been talked about already but not in this section. This is where it belongs and nice job posting direct links to it.
https://forum.xda-developers.com/razer-phone/how-to/source-code-posted-t3719665
MedicStuder said:
Surprised no one else posted in the section with this. The Kernal Source has been released by Razer which means modding can start.
https://www.xda-developers.com/razer-phone-kernel-source-code/
http://www.androidpolice.com/2017/12/15/kernel-source-code-just-released-razer-phone/
https://www.gizchina.com/2017/12/16/razer-releases-kernel-source-files-razer-phone/
Links to the source is at the bottom of this page:
http://support.razerzone.com/mobile/razer-phone
Here are the links to the source just in case:
MR1 Releases:
Build 853
Build 851
Production Releases:
Build 822
Build 813
Click to expand...
Click to collapse
I mentioned it in the factory image thread 5 days ago
Mods, can we pin this in the dev section since it contains the links to the needed source code for development purposes. Seems appropriate to have it pinned in this thread. thanks.
I've also got the kernel source going with CAF history included (based on LA.UM.5.7.r1) at https://github.com/jcadduono/android_kernel_razer_msm8998/tree/android-7.1
Fixed a minor bug and added some build scripts to simplify the process of configuring and building.
Added qcacld-3.0 sources into the kernel build for WiFi drivers but I appear to be missing something so it doesn't build. :/
I'm sure someone here can figure that out!
For TWRP support, essentially you'll need to build the stock kernel with additional options like f2fs and exFAT if desired. The OS and TWRP will be sharing the same kernel binaries due to the A/B setup so you *will* need to build the WiFi driver, even for recovery.
If someone is daring enough, they can simply build TWRP normally (ex. for a non-A/B device), flash it to boot_b or boot_a partition (depending what's active), boot up TWRP, and make backups of the opposite A/B partitions.
This can't actually be too hard to do, Dees_Troy has already done most of the work by supporting A/B on Pixel devices already.
I suppose I'm willing to give it a try if anyone is willing to possibly lose the ability to get into the OS until Razer releases factory images.
The chance of that happening is pretty slim, as long as we're only flashing the *active* boot partition (we'll check that in OS using mount command), we should be able to simply grab a copy of the opposite boot partition and restore it to how it was.
YOU CAN simply use fastboot to swap to the other boot partition, restoring your OS to bootable even if TWRP fails to work. (we will test this first to make sure Razer has enabled this option...)
Probably safe, but there's just that risk.
As I'm unsure exactly how to compile the WiFi drivers right now, I'll do this:
Create a normal TWRP image, which you can flash to your *active* boot partition.
Create a TWRP flashable zip that will take the ramdisk from the active boot partition and flash it to the inactive boot partition's boot image, then flash the inactive boot partition's image to your active boot partition.
Result: Both partitions contain the original stock kernel image with TWRP support and a fully working OS.
Slight issue: F2FS won't be supported because the stock kernel will have module signing enabled and TWRP won't be able to load it.
I'm also fairly certain I'll never get decryption working myself for this device...it looks like the vendor partition may be required and it is already encrypted itself? (not encrypted on the Pixel 2 so this is new)
Dees_Troy will be getting his Razer Phone next week. If anyone can get TWRP working it's him. No need to worry ?
MishaalRahman said:
Dees_Troy will be getting his Razer Phone next week. If anyone can get TWRP working it's him. No need to worry ?
Click to expand...
Click to collapse
No way! :victory:
That's the best news I've heard yet
---------- Post added at 04:44 AM ---------- Previous post was at 04:30 AM ----------
jcadduono said:
I've also got the kernel source going with CAF history included (based on LA.UM.5.7.r1) at https://github.com/jcadduono/android_kernel_razer_msm8998/tree/android-7.1
Fixed a minor bug and added some build scripts to simplify the process of configuring and building.
Added qcacld-3.0 sources into the kernel build for WiFi drivers but I appear to be missing something so it doesn't build. :/
I'm sure someone here can figure that out!
For TWRP support, essentially you'll need to build the stock kernel with additional options like f2fs and exFAT if desired. The OS and TWRP will be sharing the same kernel binaries due to the A/B setup so you *will* need to build the WiFi driver, even for recovery.
If someone is daring enough, they can simply build TWRP normally (ex. for a non-A/B device), flash it to boot_b or boot_a partition (depending what's active), boot up TWRP, and make backups of the opposite A/B partitions.
This can't actually be too hard to do, Dees_Troy has already done most of the work by supporting A/B on Pixel devices already.
I suppose I'm willing to give it a try if anyone is willing to possibly lose the ability to get into the OS until Razer releases factory images.
The chance of that happening is pretty slim, as long as we're only flashing the *active* boot partition (we'll check that in OS using mount command), we should be able to simply grab a copy of the opposite boot partition and restore it to how it was.
YOU CAN simply use fastboot to swap to the other boot partition, restoring your OS to bootable even if TWRP fails to work. (we will test this first to make sure Razer has enabled this option...)
Probably safe, but there's just that risk.
As I'm unsure exactly how to compile the WiFi drivers right now, I'll do this:
Create a normal TWRP image, which you can flash to your *active* boot partition.
Create a TWRP flashable zip that will take the ramdisk from the active boot partition and flash it to the inactive boot partition's boot image, then flash the inactive boot partition's image to your active boot partition.
Result: Both partitions contain the original stock kernel image with TWRP support and a fully working OS.
Slight issue: F2FS won't be supported because the stock kernel will have module signing enabled and TWRP won't be able to load it.
I'm also fairly certain I'll never get decryption working myself for this device...it looks like the vendor partition may be required and it is already encrypted itself? (not encrypted on the Pixel 2 so this is new)
Click to expand...
Click to collapse
I'm willing to temporarily sacarfic my device for this. I will message you tomorrow morning and we can give it a shot.
We have lift off! @jcadduono you were right :highfive:
Waiting on you for further instructions on how to proceed.
Even if this leads to no where it sure feels damn good to see the twrp logo.
Everything is going well, we're getting copies of each partition and I'm working on making factory restorable images right now.
I am fairly certain I can even support encryption on this device with no issues.
The device itself actually supports hardware Qualcomm full-disk encryption like most non-Google Qualcomm devices so it's nothing new!
However, the Razer Phone supports HW encrypted SDcards like LG does, so TWRP needs support in the actual crypto code used in the project to work with encryptable sdcards. Maybe Dees_Troy will be up to that task when he gets his phone.
TWRP images will be distributed like so:
- A twrp.img file that you flash to your active boot partition
- A zip file that copies the TWRP ramdisk from your active boot partition into your inactive boot partition, then copies your inactive boot partition to your active boot partition
The zip file will effectively install TWRP and the next time you boot TWRP it will be relying on your ROM's kernel instead of the TWRP kernel.
jcadduono said:
Legend!
Mad props to you, can't wait to see more! :good: This will be a good Christmas, can I ask whether being carrier or not will matter for installation?
Click to expand...
Click to collapse
@jcadduono Legend!
Mad props to you, can't wait to see more! :good: This will be a good Christmas, can I ask whether being carrier or not will matter for installation?
P.s I'll take a pop if you want a second test
thread stuck like Chuck for now, hopefully we can get some dev going for this device.
yeahh !!!!!!! wake up dev teams !!
Any information regarding Franco kernel?