Related
Hi just asking if anyone knows any links or archives or anything i can read through, im looking to build my own ROM. any help would be much appreciated and dont mind donating to someone that can help me start to learn.
Thanks
Well, first of all you need to be able to compile Android. This is pretty easy and it's explained directly in the developers google website. If you're not running a Nexus One or a Nexus S, you can't actually compile a working android copy for your own phone "as is" from AOSP. Because of this, you firstly need to change / create some dirs and files in order to add the support for your particular device. I'd start searching on CM repositories for this (I've got the Nexus One and thus I don't have such problems).
After you've compiled Android for your device and your changes (for example root), you'll have some disk images (you can find them all under out/target/product/PHONE_MODEL/, they are the .img files). You can directly flash them via fastboot ("fastboot flash boot boot.img" etc.). You can though create an update.zip file, and this can be made extracting the system.img file in a folder. Remember that you'll have to recreate the symlinks (to toolbox and/or busybox if you want to include it in your build) and set permissions, as zip doesn't save the permissions of the files once compressed.
Thus so far, if you succeed making every single step you should have your ROM on your phone
The folks over at Sony Ericsson have released something a bit useful if you’ve been wondering lately how to build Linux Kernels for your phone. Sony Ericsson’s Developers has laid out a detailed process on how to build a new Linux kernel and flash it to your Android device. We’ve pasted the info below for you so you don’t have to hop around. Below you’ll find Sony Ericsson’s how-to in its entirety for your convenience with respective links and all. If you’ve been wanting to tinker and dive into the world of Linux and flashing kernels on mobile devices, we’d say now is the time. Follow the expert step by step process and toss us a note or two in the comments below if this works out for you. However, keep in mind, even though the article is written by experienced Sony Ericsson developers, nothing is guaranteed to work the way it’s supposed to. So be very diligent while following and performing these tasks. In other words, do your research first.
How to build a Linux kernel and flash it to the phone.
Since the launch of the unlock boot loader site, Sony Ericsson have received a lot of really great feedback. The Sony Ericsson Developer Program wants to continue to build on this open dialogue with external developers.
Developers and advanced users can now unlock the boot loader, which is the first step to be able to flash your own image. Where developers run into problems when building their own image, and and trying to flash the image using Fastboot.
Before moving on, I like to remind you again that there is no turning back when unlocking the boot loader. You may void the warranty of the phone, and you will not be able to revert the phone to a locked or original state if you unlock it.
What is the Linux kernel?
The Xperia™ line of smartphones run on the Android™, the mobile operating system based on the Linux kernel. Though it is only a small part of the operating system, the kernel ensures that all other processes in the system are synchronized to work together properly.
Why rebuild the kernel?
Rebuilding the kernel enables end users to make modifications to their devices that are normally not intended by the device manufacturer, such as theming the device by changing system icons and removing/modifying system components. Please note that Sony Ericsson is not recommending this.
Considerations before building your own kernel and reflashing your device
As mentioned in the beginning of this article, the first step is to unlock the boot loader. When the boot loader is unlocked, the sensitive data is removed, such as DRM certificates, and the user partition of the file system is wiped out. But all other functionality, such as the camera and other drivers, is left intact. Please note that content, like music files, that require the DRM certificate will not be accessible any more. But most importantly, you may void the warranty of your phone if you decide to unlock it. Aside from the considerations mentioned above, the functionality is there, just waiting for you to take advantage of it. So, if you’re ready, here’s how to get started.
Building the kernel
It takes a few main steps to build the kernel. Below we’ll show you how to build a Linux kernel and flash it onto the device.
Step A – Download the necessary software
Download the following software to get started:
The kernel source code can be downloaded from the copyleft archives on Sony Ericsson Developer World. You can use the file called ex. 3.0.A.2.181_182.tar.bz2 for our Android™ Gingerbread devices. This is the source code for the Linux kernel as used in the Xperia™ PLAY.
The Fastboot client which is part of the Android SDK. This is the standard Android flashing utility. This allows you to flash the image you are about to create onto the device.
The Init RAM disk. The initial RAM disk (also known as the initrd) is the initial filesystem that the kernel will mount and start running processes off. You can configure the Init RAM disk to grant root access. How you create or download your own Init RAM disk is beyond the scope of this article.
The ARM cross-compiler. A cross-compiler is used to build ARM binaries on a different architecture, such as x86. This allows you to compile software (such as the kernel) into a format that the device can run. We recommend getting the CodeSourcery Lite compiler, especially the GNU/Linux variant, as you’ll need that if you want to build binaries for a full-blown Linux system on the device later. However, any EABI ARM compiler capable of compiling the Linux kernel should be enough for this step.
Step B – Building the kernel
To build the kernel, you first need to unpack the kernel. Once you’ve unpacked the kernel, you need to configure it, and then build it. The example below is based on you using the file called 3.0.A.2.181_182.tar.bz2.
1. Go into the kernel directory:
cd kernel
2. Configure the kernel:
ARCH=arm CROSS_COMPILE=/opt/arm-2010q1/bin/arm-none-eabi- make semc_zeus_defconfig
Note: Replace /opt/arm-2010q1 with where you installed your cross-compiler. Also, this example is for Xperia™ PLAY. Replace defconfig with the following values depending on what device you want to configure it for:
Xperia™ PLAY semc_zeus_defconfig
Xperia™ arc semc_anzu_defconfig
Xperia™ neo semc_hallon_defconfig
3. Build the kernel:
ARCH=arm CROSS_COMPILE=/opt/arm-2010q1/bin/arm-none-eabi- make
Replace /opt/arm-2010q1 with where you installed your cross-compiler. Once done, you should have a compressed kernel-image in arch/arm/boot/zImage.
Step C – Getting a RAM disk
The RAM disk is the initial filesystem the kernel will mount before transferring control to userspace. How you create your own root filesystem is beyond the scope of this article, but you can use the following instructions to pack/unpack the file.
Unpacking (you have to ramdisk.img, and weant to create a directory of files out of it):
gzip -d – < ramdisk.img > cpio -idm
Packing (You have directory of files, and want to create ramdisk.img from it):
find . | cpio –quiet -H newc -o | gzip > ramdisk.img
Step D – Assembling the boot.img
Now that we have all the parts we need to create a flashable file. The next stop is to package the parts. To do this, you’ll need the program mkbootimg, which is part of the standard Android tree. If you don’t feel like compiling all of Android to get this tool, it is available to download from various trusted sites on the Internet.
Once you have the tool, this is the command to combine your kernel and RAM disk into a flashable file:
mkbootimg –base 0×00200000 –kernel kernel/arch/arm/boot/zImage –ramdisk ramdisk.img -o boot.img
Step E – Flashing the file
You should flash the file using Fastboot. If you’ve unlocked the boot loader on your device, you already have Fastboot.
1. To flash the boot.img file, use the following the command
fastboot –i 0x0fce flash boot boot.img
2. Now, it will prompt you to connect your device. To do so, follow these simple steps:
Make sure your device is powered down.
Hold down the Search button (Xperia™ PLAY only) or the Back button (all other Xperia™ devices). The device’s notification light should shine blue to confirm it’s inFastboot mode.
Connect the USB cable.
Flashing should now start and complete.
3. As a last step in the process, you need to reboot the device. You can either remove the USB cable and battery to power the device down. If you prefer, you can instead issue the following command (either method will work):
fastboot –i 0x0fce reboot
Important information!
Additional information for experienced Linux kernel experts
The kernel is pretty standard, all the regular things you’re used to is there, and available to use. Things that are different are the memory config and the kernel commandline. The memory config is hardcoded (i.e., ATAGs aren’t used for this). It’s set in the board-file for your target, such as kernel/arch/arm/mach-msm/board-semc_zeus.c in the function msm7x30_fixup. The kernel commandline is also not fetched from the boot.img file, but compiled into the kernel (CONFIG_CMDLINE). Some arguments are also added from the boot loader.
Additional information if porting non-Linux format files to the device. The boot loader will accept any reasonably formatted boot.img file.
For example, at the Android Kernel Git, you will see the format of the boot.img file. This allows you to create a boot.img file containing two loadable files (kernel+ramdisk), which will get loaded into RAM. Once the boot loader is loaded, it passes the control to the first instruction of the loaded kernel image. After control is passed, the kernel can rely on the data contained in the RAM disk already being loaded.
Guide by Karl-Johan Dahlström
DISCLAIMER:
Rooting your phone and using custom Recoveries and ROMS have risks and may result in bricking your device, and has nothing to do with Google or the device manufacturers. In case of any mishap I am not responsible if you brick/ruin your phone in any way.
Basic computer skills are required and minimal knowledges about phones and phones utilities too.
Make sure that whatever you do, you are doing it at your own responsibility.
Carliv Touch Recovery
- version 5.7.2 is for Lollipop (cm 12.1, aicp lp or resurrection remix lp) and version 6.6 is for Marshmallow (cm 13, aicp-mm or resurrection remix mm).
The version starting number is related to android version.
This is a CWM based recovery and I did put up some work to update it to lollipop (cm 12.1) and marshmallow (cm-13) after official cwm development stopped at kitkat. It works with LOLLIPOP and MARSHMALLOW kernels and it builds with cm 12.1, aicp lp or resurrection remix lp (version 5.7) and with cm 13, aicp-mm or resurrection remix mm (version 6.5).
This is for those who want a lighter and simpler recovery or they just liked CWM before. It's not as good or complex as twrp, but it will do the job just fine.
For gui I ported PhilZ Recovery full touch module.
Because the vold in cm 12.1 and 13 doesn't support cwm anymore I had to use the old fstab1 type for functionality, although for building reason a valid recovery.fstab should be provided in device tree. In the third post there are some building hints to make it clear for those who want to try building it.
Features:
- EXT4 and F2FS support (for f2fs use the BoardConfig flag).
- full touch menu ported by me from PhilZ touch Recovery. The old Napstar-xda touch module was good but it's quite old and to update that was too much work. Actually There is a version 4 with that touch module, all working, but the touch doesn't work with some input drivers and I had to give up on it for the new and improved version from PhilZ.
- all cwm functionalities are up and working (adb, sideload, backup, restore, install, mass storage...). There is no mtp and if your phone doesn't have an external sdcard you can't connect it to PC while is in recovery mode. But there is usb-otg support, of course if your phone was shipped with that.
- added new menu for backup and restore advanced, to use it for backing or restoring only a specific partition and I also ported from PhilZ the multizip flashing function.
- in Carliv menu there is now a new section for flashing boot and recovery images. It is a feature that I needed during many recovery builds testing. I wanted an easier way to flash other image without booting to android and using an app like RashR. You can browse your storage locations for any image and after choose you will have to select on wich partition should that be flashed. I added multiple confirmations check to avoid flashing on wrong partition. This feature works only with boot and recovery images. I won't add other partitions to this because for other things there are multiple backup restore functions.
- for MTK phones (if the flag is used in Boardconfig) there is a new menu to backup and restore some important partitions like uboot, nvram an secro because they are involved in restoring a lost IMEI, and also the logo partition which may often get broken by bad ported ROMs.
- besides these all my old specific menus (aroma, rainbow...) are still in place.
- added support for dencrypting and mounting data partition using the builtin minivold from cyanogenmod with vdc commands (the ideea came from this post of Lekensteyn). Tested and working well with text ar hex passwords, and maybe will work with pin too but I don't think it will work with pattern .
- added support for dencrypting and mounting adopted storage in marshmallow. The solution is based on this article of nelenkov.
- there is no included root solution. I choose to do it this way because there is no universal root solution now and someone may end up messing things with a non-working root option. You can flash a zip installer from Chainfire's SuperSu or other solution that may work for your phone.
All screenshots are made with my old tool from here (still working well).
CREDITS:
The biggest thanks go to AP756 and DerTeufel1980, two friends from Germany, who sent me a new phone each, with lollipop OS and that helped me a lot to do this.
- Phil3759 for the touch code and many other things from his recovery;
- TWRP developers. I learned a lot from their work;
- Clockworkmod Team starting with Koushik Dutta and ending with all developers that made the CWM recovery what it was;
- Cyanogenmod Developers;
- Nikolay Elenkov;
In next post there are some links for built recoveries. I'll add more soon as I get a valid link (on a reliable webhost) from people who build it for other phones.
I worked alone on this, there is no team here, not because I don't want to , but probably because there was no one interested in this, and so there may be some unspotted bugs. If you find any please do tell me to help on fixing it.
XDA:DevDB Information
Carliv Touch Recovery, Tool/Utility for all devices (see above for details)
Contributors
carliv
Version Information
Status: Stable
Current Stable Version: 5.7.3 & 6.6.1
Stable Release Date: 2016-07-19
Created 2016-05-30
Last Updated 2016-07-19
Changelog and working builds
CHANGELOG 19-07-2016:
- fix backup for old mtk phones.
Lollipop
1. Jiayu S3+
2. Zopo Speed 7+
3. Zopo Speed 7
4. Mlais Mx Base
5. Alcatel Pop C2/C3
6. ZTE Blade L3 / Digicel DL910
7. Nous NS5511
Marshmallow
1. Zopo Speed 7+
2. Zopo Speed 7+ with adopted storage
3. Zopo Speed 7
4. Zopo Speed 7 with adopted storage
* NOTE: sadly the kernel source for zopo marshmallow isn't published so these two don't have touch in recovery, but you can use them as in CWM with phone buttons.
[*] QCOMM devices:
1. Huawei Honor 5x (kiwi)
2. Samsung Galaxy A5 (SM-A500FU)
Building Guide
To build you need a local repo of cm-12.1 or cm-13 and a proper device tree. To see how a buildable device tree looks check this one from my github.
It builds out of the box with aicp lp-5.1 and aicp mm-6.0 too, but like in cm you need a proper device tree.
Some things to be considered:
For BoardConfig:
- the most common thing in all BoardConfig I saw (you need this to use power button to select if you use physical buttons in some situations)
Code:
- BOARD_HAS_NO_SELECT_BUTTON
- for the graphical interface
Code:
- TARGET_RECOVERY_PIXEL_FORMAT
- for mass storage if your phone has an external sdcard, to connect it to PC (this one can be specified in fstab too) - and it has to be without any quotes or slashes
Code:
- TARGET_USE_CUSTOM_LUN_FILE_PATH := /sys/devices/platform/mt_usb/musb-hdrc.0.auto/gadget/lun%d/file
- for LCD backlight lights - and it has to be without any quotes or slashes
Code:
- TARGET_RECOVERY_LCD_BACKLIGHT_PATH := /sys/class/leds/lcd-backlight/brightness
- for vibrator feature - and it has to be without any quotes or slashes
Code:
- VIBRATOR_TIMEOUT_FILE := /sys/devices/virtual/timed_output/vibrator/enable
- with link to a valid recovery.fstab version 2 (it may work without it but it is better to be here)
Code:
- TARGET_RECOVERY_FSTAB
- for a better readability adapted to your screen (check the minui folder for more fonts)
Code:
- BOARD_USE_CUSTOM_RECOVERY_FONT
Carliv Touch Recovery specific flags:
- if you have the recovery on recovery-carliv folder under bootable directory in cm-12.1 source use this next flag.
Code:
- RECOVERY_VARIANT := carliv
NOTE: in cm 13, and other android 6 sources too, you can't build with this flag out of the box and so you have some things to do - the easy one is to rename recovery folder in [recovery-stock] and to place my recovery next to that with the name [recovery]. Other option is to open Android.mk from /sytem/core/healthd and find line 58 where you need to replace [LOCAL_C_INCLUDES := bootable/recovery] with [LOCAL_C_INCLUDES := $(call project-path-for,recovery)].
- with your phone resolution like this width x height
Code:
- DEVICE_RESOLUTION := 720x1280
- if you want to use it with encrypted phone (it work with a non encrypted phone too but it will be smaller if you don't need decrypting function)
Code:
- BOARD_INCLUDE_CRYPTO := true
- if your phone is MTK powered you need this for the MTK menu (it is not mandatory though with the mtk phones shipped with lollipop or marshmallow)
Code:
- BOARD_HAS_MTK_CPU := true
- for touch menu, if your phone has an input driver with PROTOCOL_TYPE_B (synaptic is an example, or many samsung devices); if you have access to, check your kernel input driver for something like this [#define PROTOCOL_TYPE_B] - google it if you want to know more about this
Code:
- BOARD_USE_PROTOCOL_TYPE_B := true
- to block an input device use
Code:
- TOUCH_INPUT_BLACKLIST := "devicename"
- if you use Adopted Storage
Code:
- BOARD_USE_ADOPTED_STORAGE := true
For system.prop from device tree:
Code:
#
# system.prop for mx
#
ro.ctr.crypto.passwd="64656661756c745f70617373776f7264"
ro.ctr.forbid_format=/frp,/persistent,/lk,/uboot,/logo,/metadata,/nvdata,/nvram,/secro
ro.ctr.forbid_mount=/frp,/persistent,/lk,/uboot,/logo,/metadata,/nvdata,/nvram,/secro
ro.ctr.touch_accuracy=7
- to use decrypt data specify here your password (ro.ctr.crypto.passwd); I forgot to mention that if the phone uses encryption, the recovery will start with few seconds delay, because of the decrypting and mounting data process. If the message will tell you that couldn't be decrypted it is possible that your password was wrong or it uses an unsuported type of password. To be sure just restart the recovery from Power menu and if you still get the same message then you need to check your provided password from system.prop or to find a different solution (other recovery like twrp). If you want to decrypt your phone for good you need to format data and data media from Mount/Storage menu but you will loose your data (settings, preferences).
- ro.ctr.forbid_format and ro.ctr.forbid_mount are for partitions from fstab that you don't want to be shown in Mount/ Storage menu with mount and format option (coma separated, no spaces and with leading slash), like in my example above.
- ro.ctr.touch_accuracy to improve the touch handling (bigger lcd_density = bigger accuracy); the initial value is 7, just like in PhilZ Recovery, and I reccomend you to try different numbers to see what is right for you, but don't go over 19.
All these system.prop lines are not mandatory.
Carliv Touch Recovery uses a fstab version 1 named [ctr.fstab] and you have to create a folder recovery in your device tree, in that recovery folder create a new folder named root, in root folder another folder named etc and in that one place the ctr.fstab. Like this:
Code:
recovery/root/etc/ctr.fstab
That will be enough since the compiler will add it in recovery ramdisk and the recovery module will find it in etc folder.
Code:
# Android fstab file.
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
# mount point fstype device [device2] fs_options [fs_options2] lun
/boot emmc /dev/block/platform/mtk-msdc.0/by-name/boot
/cache ext4 /dev/block/platform/mtk-msdc.0/by-name/cache
/recovery emmc /dev/block/platform/mtk-msdc.0/by-name/recovery
/system ext4 /dev/block/platform/mtk-msdc.0/by-name/system fs_options=rw
/data ext4 /dev/block/platform/mtk-msdc.0/by-name/userdata fs_options=rw
/internal_sd datamedia /dev/null
/sdcard vfat /dev/block/mmcblk1p1 /dev/block/mmcblk1 lun=sys/class/android_usb/android0/f_mass_storage/lun/file
Important here is how you define internal storage which is data media
Code:
/internal_sd [COLOR="Red"]datamedia[/COLOR] [COLOR="Magenta"]/dev/null[/COLOR]
You can see It's used the old way with "datamedia" fstype and /dev/null device.
Important thing: if you have only internal storage define it as
Code:
/sdcard datamedia /dev/null
If you have also an external sdcard, use either way:
Code:
/internal_sd datamedia /dev/null
/sdcard vfat /dev/block/mmcblk1p1 /dev/block/mmcblk1
or
Code:
/sdcard datamedia /dev/null
/external_sd vfat /dev/block/mmcblk1p1 /dev/block/mmcblk1
If you are using the adopted storage feature for external sd card, define this
Code:
/data_sd ext4 /dev/block/mmcblk1p2 fs_options=adopted
and remove or comment out the line for external sd card.
You can see the internal storage can be sdcard or internal_sd and external sdcard can be sdcard or external_sd, but internal storage can't be external_sd or external sdcard internal_sd.
If your phone has OTG support you can use that too defining it like this
Code:
/usb-otg vfat /dev/block/sda1 /dev/block/sda
or this
Code:
/usbdisk vfat /dev/block/sda1 /dev/block/sda
-check with your phone booted up in Android and a OTG USB mounted to see in [/sys/class/block] or [dev/block] how to set device for this (the dev/block/sdx part).
The recovery has fat32, exfat and ntfs support builtin (also f2fs for file system). You can define your usb-otg and/or external sdcard as "auto" instead of "vfat" and it will work with any of these formats. I tested a portable HDD self powered and it works (120 GB) as usb-otg. Anyway that is available only for zip and image flashing. Maybe I'll make it to work for backup and restore too.
@carliv is back!!! Thanks a lot for this.
Should I port or should I build?
kirito9 said:
@carliv is back!!! Thanks a lot for this.
Should I port or should I build?
Click to expand...
Click to collapse
You should build it of course. I won't make porting recoveries anymore.
Actually wait for a day or two because I'm working on some improvements and I'll push them to github soon.
Also I have a working version for cm13 too. That also need some more tests before release.
carliv said:
You should build it of course. I won't make porting recoveries anymore.
Actually wait for a day or two because I'm working on some improvements and I'll push them to github soon.
Also I have a working version for cm13 too. That also need some more tests before release.
Click to expand...
Click to collapse
I will wait for cm13 support
Anyway this recovery support arm64?
Sure. Look at the phones already supported
Gesendet von meinem HERO1 mit Tapatalk
carliv said:
You should build it of course. I won't make porting recoveries anymore.
Actually wait for a day or two because I'm working on some improvements and I'll push them to github soon.
Also I have a working version for cm13 too. That also need some more tests before release.
Click to expand...
Click to collapse
Goood xD. No more complaints from users who "brick" their devices and blame you :laugh:
All things are mostly done.
Just a little heads up: Added usb-otg support for install zip menu - should work with ntfs, fat, exfat and fat32 usb flash drives (I tested only with fat32). Other improvements too for both versions (lollipop and marshmallow).
I'll push the source tomorrow.
Attached a screenshot of the recovery for marshmallow (cm13).
Thanks to Master [emoji322]
Sent from my Lenovo A7010a48 using XDA-Developers mobile app
Thread updated with instruction and links for the new version for cm-13 and the version for lollipop is upgraded to 5.2.
If some of you build a working recovery and want to share here the link, just post a replay and I'll add it in post #2.
If you have a buildable device tree public on github and want a recovery built for it ask here and maybe I or someone else will do it in some free time.
@carliv do you interested to build this recovery for kenzo (redmi note 3 pro) ?
here's kernel source for it: https://github.com/MiCode/Xiaomi_Kernel_OpenSource/tree/kenzo-l-oss
exodius48 said:
@carliv do you interested to build this recovery for kenzo (redmi note 3 pro) ?
here's kernel source for it: https://github.com/MiCode/Xiaomi_Kernel_OpenSource/tree/kenzo-l-oss
Click to expand...
Click to collapse
The kernel alone is useful only if builds out of the box, but you still need a proper device tree to build, even with a prebuilt kernel. For building a recovery or a ROM that is what you need. I can't build a recovery only with that. Maybe someone else have the phone and manage to create the device tree and it will build the recovery.
Cheers
Look forward to Flash system Image In Carliv Menu
Thank You
Finally CTR for LP & MM! Amazing @carliv, I love this recovery.
Update to version 5.3 for lollipop and 6.2 for marshmallow
CHANGELOG 12-06-2016:
- activated working support for ntfs, exfat and f2fs;
- rewritten the flash image menu for better functionality and more protection to avoid mistakes;
- change the local busybox libs and modules names to avoid conflicting with existing external folder;
- some other small fixes and improvements (you can check the github commits).
@carliv
Hi, I have a device tree that I used for TWRP https://github.com/kirito96/device_Alcatel_4032 recovery and I would like to know if this is enough for building CTR or do I need a "complete" device tree? Thanks.
kirito9 said:
@carliv
Hi, I have a device tree that I used for TWRP https://github.com/kirito96/device_Alcatel_4032 recovery and I would like to know if this is enough for building CTR or do I need a "complete" device tree? Thanks.
Click to expand...
Click to collapse
Not really complete like in building ROMs, but you have to do some changes:
- convert it to cm building or, better and easier for you since it's for omni, to aicp.
- then you need to add in boardconfig partitions sizes (twrp doesn't need that because it checks the size from dumchar_info or partinfo).
- add that recovery/root/etc folder with ctr.fstab in it.
- add specific flags in boardconfig, but if your device has a small recovery partition let the crypto flag out (don't use it at all) and you will gain almost 2 Mb.
- add resolution and desired font if you want to not use the default which is for 540x960 dpi.
and that's it ...
Take a look at my mlais device tree (link in OP)-sorry, in post #3 to see these things - I have a branch for aicp too.
And I see your device use mtk header. You can check in my github for the lenovo p780 device tree where I implemented the mkbootimg part from my kitchen.
Cheers!
PS: if you can send me your phone dumchar_info file and a stock boot image I'll try to convert your device folder to use it as an example for other people about how to do it.
@carliv
Thanks for informing me, but for now I think I'll opt for a device tree that you made and I'll use that as a base for other devices that I'll work on in the future.
I've attached the dumchar_info.txt file below along with the stock boot.img. Funny thing is, I have 2 stock boot.img. I have for which my phone came with (4.2.2) and an AOSP upgrade with 3.10.xx kernel (5.1.1). I uploaded both because this recovery is for LP right? Which should be 3.10.xx kernel. In any case, I'll use what you made as a base. Thanks again.
carliv said:
CHANGELOG 12-06-2016:
- activated working support for ntfs, exfat and f2fs;
- rewritten the flash image menu for better functionality and more protection to avoid mistakes;
- change the local busybox libs and modules names to avoid conflicting with existing external folder;
- some other small fixes and improvements (you can check the github commits).
[/B]
Click to expand...
Click to collapse
You did it!!! :victory:
Good thing I was checking up on you or I might of missed it.
Thanks carliv I realize this project must of been a huge effort on your part and I for one am very grateful :highfive:
Hello,
First of all, im new to android modding and linux. I tried to build a kernel from stock G935FXXU1BPH6 source based on their readme file. My problem is, I don't have a zImage file after build that I could put into a flashable zip. I only have Image and Image.gz (I guess thats normal for arm64 kernels?) and I don't know how to make them flashable. I found a youtube video where the dude placed the Image file in a directory called "tools" in his flashable zip, I tried it and TWRP said I installed it successfully but when I start up my phone and check kernel version its still the previous one not mine.
Used this toolchain: aarch64-linux-android-4.9/bin/aarch64-linux-android-
I've set up CROSS_COMPILE path, then I set up configuration:
make ARCH=arm64 exynos8890-hero2lte_defconfig
make menuconfig (to tweak it a little bit more, like custom kernel version string so I can see if it worked)
Then I started build:
make ARCH=arm64
Output when build finished:
>>>>> Time used for generated all hashes is 6 sec
OBJCOPY arch/arm64/boot/Image
GZIP arch/arm64/boot/Image.gz
DTC arch/arm64/boot/dts/exynos8890-smdk8890.dtb
DTC arch/arm64/boot/dts/exynos8890-universal8890.dtb
Anyone knows how could I make it flashable? Thanks.
keezay said:
Hello,
First of all, im new to android modding and linux. I tried to build a kernel from stock G935FXXU1BPH6 source based on their readme file. My problem is, I don't have a zImage file after build that I could put into a flashable zip. I only have Image and Image.gz (I guess thats normal for arm64 kernels?) and I don't know how to make them flashable. I found a youtube video where the dude placed the Image file in a directory called "tools" in his flashable zip, I tried it and TWRP said I installed it successfully but when I start up my phone and check kernel version its still the previous one not mine.
Used this toolchain: aarch64-linux-android-4.9/bin/aarch64-linux-android-
I've set up CROSS_COMPILE path, then I set up configuration:
make ARCH=arm64 exynos8890-hero2lte_defconfig
make menuconfig (to tweak it a little bit more, like custom kernel version string so I can see if it worked)
Then I started build:
make ARCH=arm64
Output when build finished:
>>>>> Time used for generated all hashes is 6 sec
OBJCOPY arch/arm64/boot/Image
GZIP arch/arm64/boot/Image.gz
DTC arch/arm64/boot/dts/exynos8890-smdk8890.dtb
DTC arch/arm64/boot/dts/exynos8890-universal8890.dtb
Anyone knows how could I make it flashable? Thanks.
Click to expand...
Click to collapse
This particular chipset (64-bit Exynos) uses the uncompressed Image and a separate dtb.img file made from combining all the dtb revisions of your device codename and region into a DTBH format.
You can flash them using my LazyFlasher project.
See: https://github.com/jcadduono/lazyflasher
You will want to use the kernel-flasher branch. The kernel-flasher-samsung branch isn't fully ready and adds additional patch files to remove TIMA/Knox. I've yet to find out everything that needs to be changed from stock state to allow a bootable custom kernel without disabling encryption, unfortunately.
You can simply git clone it, then place your Image and optionally dtb.img in the root folder of the repository, then type "make" to build a TWRP flashable zip. They will be dynamically replaced in the current boot image on the device when the zip is flashed. You can check out the README.md for more info.
If you want to generate your own dtb.img to include in the installer, you can use a script I made from my universal8890 kernel sources on GitHub:
https://github.com/jcadduono/android_kernel_samsung_universal8890/blob/stock-6.0/dtbgen.sh
(correct the toolchain location for your build in the script)
It also requires the scripts/dtbTool folder (from the same git linked above) to be present in your repository. It's not the same as the Qualcomm dtbTool, and the sources are included (and fairly clean!) if you're interested in learning the Exynos dtb.img (DTBH) format.
./dtbgen.sh hero2lte xx
Now, there's still quite a bit that needs to be done to make the device actually boot successfully and be stable with a custom kernel. While the kernel is perfectly stable, the Samsung customized Android OS will absolutely freak out. That's a bit beyond me, and the reason I haven't really worked on any custom kernels for it myself.
Have fun!
jcadduono said:
This particular chipset (64-bit Exynos) uses the uncompressed Image and a separate dtb.img file made from combining all the dtb revisions of your device codename and region into a DTBH format.
You can flash them using my LazyFlasher project.
See: https://github.com/jcadduono/lazyflasher
You will want to use the kernel-flasher branch. The kernel-flasher-samsung branch isn't fully ready and adds additional patch files to remove TIMA/Knox. I've yet to find out everything that needs to be changed from stock state to allow a bootable custom kernel without disabling encryption, unfortunately.
You can simply git clone it, then place your Image and optionally dtb.img in the root folder of the repository, then type "make" to build a TWRP flashable zip. They will be dynamically replaced in the current boot image on the device when the zip is flashed. You can check out the README.md for more info.
If you want to generate your own dtb.img to include in the installer, you can use a script I made from my universal8890 kernel sources on GitHub:
https://github.com/jcadduono/android_kernel_samsung_universal8890/blob/stock-6.0/dtbgen.sh
(correct the toolchain location for your build in the script)
It also requires the scripts/dtbTool folder (from the same git linked above) to be present in your repository. It's not the same as the Qualcomm dtbTool, and the sources are included (and fairly clean!) if you're interested in learning the Exynos dtb.img (DTBH) format.
./dtbgen.sh hero2lte xx
Now, there's still quite a bit that needs to be done to make the device actually boot successfully and be stable with a custom kernel. While the kernel is perfectly stable, the Samsung customized Android OS will absolutely freak out. That's a bit beyond me, and the reason I haven't really worked on any custom kernels for it myself.
Have fun!
Click to expand...
Click to collapse
Thank you very much!
@jcadduono couldn't make the kernel boot after packing it with lazyflasher. I built a completely stock kernel from the mentioned source, pasted the "Image" (not the Image.gz) file in lazyflasher root and then used make command. Tried including "exynos8890-smdk8890.dtb" file as well. Same story. Not sure if I need anything else in the package or I made user mistake. Do you have any ideas how could I debug what makes it stuck on that screen?
Thanks!
EDIT: Solved Problem.
keezay said:
@jcadduono couldn't make the kernel boot after packing it with lazyflasher. I built a completely stock kernel from the mentioned source, pasted the "Image" (not the Image.gz) file in lazyflasher root and then used make command. Tried including "exynos8890-smdk8890.dtb" file as well. Same story. Not sure if I need anything else in the package or I made user mistake. Do you have any ideas how could I debug what makes it stuck on that screen?
Thanks!
EDIT: Solved Problem.
Click to expand...
Click to collapse
Can you help me set up an environment to build a kernel, arm64, for s7? I'm on Ubuntu having a heel of a time..
Galaxy S7 Edge Kernel Flashing Issues
I am currently trying to flash a different kernel into a galaxy s7 edge (SM-G935S).
I have gone as far as building a kernel and extracting a Image file from it, but every time I try flashing a boot.img with a replaced kernel image file, it seems to never work.
A mkbootimg tool that I am currently using requires a dtb file, but I cannot find where to get it from.
I have tried using @jcadduono's git code, but the dtb file created from it doesn't seem to work as well.
Can anyone tell me what I should do to flash a kernel successfully?
kernel panic after flashing
Hi @ll,
with this guide I was able to compile my own kernel and also flashing it to my phone. Unfortunatelly I'm getting kernel panic after rebooting the phone. is there any possibility to get the reason for this? Or do you have any hint, what I may have done wrong?
Thanks for your help.
Kind regards
v0ti
Trying to alter a stock ROM and resign with my own custom key just for myself. This process will allow me to use a device with custom changes (NOT root), but still allow me to use Android Pay.
This process involves using the "make_ext4fs" tool. However, this tool (as far as I can tell) requires using the old plaintext version of "file_contexts". Android 7+ uses a new binary version of this file instead ("file_contexts.bin").
So if anyone can solve either of these questions, I would be very grateful:
1) Is there a tool to convert my device's binary "file_contexts.bin" to the old plaintext "file_contexts"? -OR-
2) Is there a build of "make_ext4fs" that accepts the new binary format "file_contexts.bin"? I tried to build the new nougat version myself from AOSP, but after a successful build of the tool, I can't get the thing to read files on either 64-bit or 32-bit systems. It yields an error "No such file or directory" when trying to point to file_contexts. I am not a great C developer, so I don't know if I built it wrong. For reference, no, I am not missing the lib32stdc++6 libraries. I have attached the binary if you want to see if you can get it to work. -OR-
3) If anyone has the file_contexts text file for the OnePlus 3, ROM version 7.X Nougat, that would work too!
Any help anyone can offer in any way would be fantastic! Thank you so much for your time to look at this!
A good question
1) yes, see my signature
munjeni said:
1) yes, see my signature
Click to expand...
Click to collapse
I'm trying to do the same with a 7.1.1. rom. I convert the file_contexts.bin to file_contexts, unpack the rom, do the modifications to the rom, repack the rom then replace the original system.new.dat and system.transfer.list with the newly packed ones (original file_contexts.bin is still in the original zip) and when I go to flash it in TWRP it doesn't flash the system and I get a No OS installed Is there something I have to do to the file_contexts.bin after I repack the system.new.dat?
"file_contexts.bin" to the old plaintext "file_contexts" tool: http://blog.cofface.com/archives/2255.html
puargs said:
I tried to build the new nougat version myself from AOSP, but after a successful build of the tool, I can't get the thing to read files on either 64-bit or 32-bit systems. It yields an error "No such file or directory" when trying to point to file_contexts. I am not a great C developer, so I don't know if I built it wrong. For reference, no, I am not missing the lib32stdc++6 libraries.
Click to expand...
Click to collapse
Try building with the pie (Position Independent Executable) flag. Had this exact same problem when trying to compile a CVE for android.
Hopefully this should work for you and sorry for the Necro post