ext2/3/4 filesystem create/fix tools (e2fstools pkg) static build for arm64 devices - Other Tools & General Discussion

e2fstools package, statically built for arm64 devices from Google's googlecode.com Oreo branch
NOTE: These will support ANY version of android's filesystems that use ext2 or ext3 or ext4. I built them from oreo branch as that one was the closest to compiling without any editing of the Makefiles. Don't let the name throw you off
I needed to run a modern fsck on a rooted device I have that I have been doing some hacking on.
The filesystem was in bad shape and the on-device e2fsck absolutely refused to check it while it was even mounted, even with the force option. Out of part desperation part determination I decided I would just build one myself. So I went and dug up the sources from googlecode.com, transfered them to my linux workstation, and after much fighting with gcc for cross compilation, finding a place in the google git repo where they actually build (hence going with orero), and having to tweak the c code even in a few places (mostly fixing includes and whatnot, no actual coding on my part), I succeeded.
As it says in the title, these are all the e2fstools binaries built from Google's googlecode.com source tree in their Oreo release branch. They are also compiled statically (no libraries are needed for them to function) so they should work absolutely fine on any device that has a 64bit arm (aarch64) processor. I have tested a handfull of them and they work perfectly fine on my Samsung Galaxy s8. In fact I used the fsck.ext4 binary to repair my system partition which it did perfectly.
https://www.dropbox.com/s/owb76hohnjzjdwe/e2fstools-oreo-aarch64-static.tar.gz?dl=0
Hope they come in as handy to someone else as they did me.
List of files follows:
Code:
[email protected]:~> tar tzf e2fstools-oreo-aarch64-static.tar.gz
e2fsbin/
e2fsbin/e2undo
e2fsbin/e2image
e2fsbin/badblocks
e2fsbin/mkfs.ext3
e2fsbin/fsck.ext4dev
e2fsbin/e2initrd_helper
e2fsbin/fsck.ext3
e2fsbin/e4crypt
e2fsbin/e4defrag
e2fsbin/mke2fs
e2fsbin/e2fsck
e2fsbin/fsck.ext4
e2fsbin/filefrag
e2fsbin/tune2fs
e2fsbin/e2freefrag
e2fsbin/uuidd
e2fsbin/e2label
e2fsbin/mkfs.ext2
e2fsbin/blkid
e2fsbin/logsave
e2fsbin/lsattr
e2fsbin/uuidgen
e2fsbin/findfs
e2fsbin/mklost+found
e2fsbin/dumpe2fs
e2fsbin/mkfs.ext4
e2fsbin/debugfs
e2fsbin/fsck.ext2
e2fsbin/mkfs.ext4dev
e2fsbin/resize2fs
e2fsbin/chattr
e2fsbin/fsck
PS: Now that I have a working arm64 cross compilation system setup, if anyone else desperately needs a working static binary for anything relatively simple to build (as in not 50 million dependencies for me to track down and install) and can send me or link me the sources for it and its dependencies, I would be happy to oblige.

Unfortunately, my device is armv7

buengeut said:
Unfortunately, my device is armv7
Click to expand...
Click to collapse
I forget, is that 32bit? If so i could fairly easily build new ones that are 32bit. Did you try them and they didnt work? If its 64bit they may work anyway, as these dont use any fancy instructions, and i did not build them even with -O1. I thought the main differences between the different "v"s of the same arch (32v64) was in libc and friends, of which these dont use as they are completely static so libc is built in.
I was even thinking of making this a flashable zip, but i hadnt bothered as no one replied to my initial post so i didnt think anyone cared ?️

partcyborg said:
I forget, is that 32bit? If so i could fairly easily build new ones that are 32bit. Did you try them and they didnt work? If its 64bit they may work anyway, as these dont use any fancy instructions, and i did not build them even with -O1. I thought the main differences between the different "v"s of the same arch (32v64) was in libc and friends, of which these dont use as they are completely static so libc is built in.
I was even thinking of making this a flashable zip, but i hadnt bothered as no one replied to my initial post so i didnt think anyone cared ?️
Click to expand...
Click to collapse
ARMv7 is ARM 32bit, 64bit program will not work on a 32bit system.
Can you build e2fstools for ARMv7.

Sadly your link is down.
would you care to reupload?

LNQ said:
Sadly your link is down.
would you care to reupload?
Click to expand...
Click to collapse
Sure. I'll even make it flashable this time ?

Thanks alot, good sir!

Legend! I'd been dealing with not being able to repair my /data errors for the past few days since my Oreo update. The current TWRP (3.2.3.4) still has an ancient e2fsck that doesn't support the ext4 quota option that LG formats their Oreo data partition with. The updated version in /system/bin works while the OS is running which is why I knew I had errors, but I couldn't get it to run in TWRP to fix them because of the incompatible library files.
I was all set to reinstall my Android SDK and compile another version with inbuilt libraries when I decided to do one last search and found this thread where you'd already done it. So thanks for saving me a few hours of downloading/installing/remembering how to compile for Android all over again
I guess I can also vouch for it working on an LG V20. I don't know if it's just LG's version of Oreo that needs the later e2fsck or others too, but anyone who can't repair errors on their ext4 partitions in TWRP due to needing a newer e2fsck version should be able to use this version. I just copied the file fsck.ext4dev to /cache and ran it from there on my data partition.

Your link is dropbox banned...
Any chance you could attach the zip here...?

quotient said:
Your link is dropbox banned...
Any chance you could attach the zip here...?
Click to expand...
Click to collapse
Seconded!
@partcyborg
Any chance you could put this file somewhere else? The above link is banned.
Thanks!

Hi,
I have a Oneplus 3 that after 3 years of use became sluggish as hell at file system access.
After reading thus document https://www.usenix.org/system/files/conference/hotstorage16/hotstorage16_ji.pdf
I would give a try to your e2fstools build.
Can you repost a link to download?
Thanks in advance

partcyborg said:
I forget, is that 32bit? If so i could fairly easily build new ones that are 32bit. Did you try them and they didnt work? If its 64bit they may work anyway, as these dont use any fancy instructions, and i did not build them even with -O1. I thought the main differences between the different "v"s of the same arch (32v64) was in libc and friends, of which these dont use as they are completely static so libc is built in.
I was even thinking of making this a flashable zip, but i hadnt bothered as no one replied to my initial post so i didnt think anyone cared ?️
Click to expand...
Click to collapse
Late to this thread, great work!
I have the exact same problem.
Could you please post flashable zip and/or instructions how to load this into android?
Thank you

I found a binary on website, tested on Nexus 5 (ARMv7L 32bits)
GitHub - FerryAr/e2fsprogs-arm: Static build of e2fsprogs for Android Magisk Module
Static build of e2fsprogs for Android Magisk Module - GitHub - FerryAr/e2fsprogs-arm: Static build of e2fsprogs for Android Magisk Module
github.com

partcyborg said:
e2fstools package, statically built for arm64 devices from Google's googlecode.com Oreo branch
NOTE: These will support ANY version of android's filesystems that use ext2 or ext3 or ext4. I built them from oreo branch as that one was the closest to compiling without any editing of the Makefiles. Don't let the name throw you off
I needed to run a modern fsck on a rooted device I have that I have been doing some hacking on.
The filesystem was in bad shape and the on-device e2fsck absolutely refused to check it while it was even mounted, even with the force option. Out of part desperation part determination I decided I would just build one myself. So I went and dug up the sources from googlecode.com, transfered them to my linux workstation, and after much fighting with gcc for cross compilation, finding a place in the google git repo where they actually build (hence going with orero), and having to tweak the c code even in a few places (mostly fixing includes and whatnot, no actual coding on my part), I succeeded.
As it says in the title, these are all the e2fstools binaries built from Google's googlecode.com source tree in their Oreo release branch. They are also compiled statically (no libraries are needed for them to function) so they should work absolutely fine on any device that has a 64bit arm (aarch64) processor. I have tested a handfull of them and they work perfectly fine on my Samsung Galaxy s8. In fact I used the fsck.ext4 binary to repair my system partition which it did perfectly.
https://www.dropbox.com/s/owb76hohnjzjdwe/e2fstools-oreo-aarch64-static.tar.gz?dl=0
Hope they come in as handy to someone else as they did me.
List of files follows:
Code:
[email protected]:~> tar tzf e2fstools-oreo-aarch64-static.tar.gz
e2fsbin/
e2fsbin/e2undo
e2fsbin/e2image
e2fsbin/badblocks
e2fsbin/mkfs.ext3
e2fsbin/fsck.ext4dev
e2fsbin/e2initrd_helper
e2fsbin/fsck.ext3
e2fsbin/e4crypt
e2fsbin/e4defrag
e2fsbin/mke2fs
e2fsbin/e2fsck
e2fsbin/fsck.ext4
e2fsbin/filefrag
e2fsbin/tune2fs
e2fsbin/e2freefrag
e2fsbin/uuidd
e2fsbin/e2label
e2fsbin/mkfs.ext2
e2fsbin/blkid
e2fsbin/logsave
e2fsbin/lsattr
e2fsbin/uuidgen
e2fsbin/findfs
e2fsbin/mklost+found
e2fsbin/dumpe2fs
e2fsbin/mkfs.ext4
e2fsbin/debugfs
e2fsbin/fsck.ext2
e2fsbin/mkfs.ext4dev
e2fsbin/resize2fs
e2fsbin/chattr
e2fsbin/fsck
PS: Now that I have a working arm64 cross compilation system setup, if anyone else desperately needs a working static binary for anything relatively simple to build (as in not 50 million dependencies for me to track down and install) and can send me or link me the sources for it and its dependencies, I would be happy to oblige.
Click to expand...
Click to collapse
Hi nice compilation job! I know it's not always easy to compile these binaries from source...
Can you please reupload you archive here as attachment? Thanks!

lebigmac said:
Hi nice compilation job! I know it's not always easy to compile these binaries from source...
Can you please reupload you archive here as attachment? Thanks!
Click to expand...
Click to collapse
There's a Magisk module that does cross-compilation specifically, you should get it.

By the way, the link for that drop box is dead.

Related

Got kexec-mod, kexec-tools working, atags in progress - Should Also Work With DroidX

I realize people gave up slightly on the whole kexec thing over radio worries, but I now have the module compiling and inserting without error into the Droid2/DroidX gingerbread kernel. Next comes cross compiling the kexec-tools for userspace, to allow us to attempt inserting a different kernel.
To build, you'll need a compiled DroidX kernel from source, as well as the android NDK.
To build, make sure you have downloaded the DroidX GB kernel source and compiled it. There are guides everywhere on how to build Android kernels. Just make sure you use the proper cross compiler.
http://sourceforge.n....l.tgz/download
When you build, make sure to use
Code:
make mapphone_defconfig
Once the kernel is built, clone my repo and edit envsetup.sh to reflect the correct paths to your kernel source directory and the android NDK.
https://github.com/i...kexec-mod-d2-dx
Then, source it:
Code:
source envsetup.sh
Then, just run
Code:
make
and cross your fingers. You should then have a fresh kexec_load.ko file!
To see if it loads, you'll need to copy it to your sdcard, and then on the phone, using a console, do the following:
Code:
su (click allow)
insmod /sdcard/path/to/kexec_load.ko
If you don't get any errors, it inserted! Now, of course, to actually use it, we'd need the kexec-tools built, which I haven't gotten ready yet...but they're coming! To remove the module (no reason to leave it in memory for now):
Code:
rmmod kexec_load
Happy hacking, and help is always appreciated!
This looks great! If you need any help just ask
Thanks! I probably could actually use some. I'm looking at eternity project's git repos now, and am trying to figure out how they managed to get atags working, with the whole procfs thing...still scratching my head there.
I'm looking at eternity project's git repos now, and am trying to figure out how they managed to get atags working, with the whole procfs thing...still scratching my head there, though I do have an atags module working, except it doesn't do anything without atags in the procfs (http://lists.infradead.org/pipermail/kexec/2011-January/004795.html).
kexec-tools:
https://github.com/i...xec-tools-dx-d2
To build, see the README.
Then, copy the binaries from /build/sbin/* to your device, and the move them to the /system/bin directory, and chmod them 770 to make them executable.
mod-atags:
https://github.com/i...mod-atags-d2-dx
Now, if I/we can just get atags and procfs stuff taken care of, we'll be able to go to the next step. I already have atags compiling as a module, but it won't stay inserted because we have no atags in the procfs. Note I can't just trace through code like this and know what everything is doing, but I know enough to hack at it and be dangerous
I know this is kind of off topic, but would this help us people with Motorola Atrix 2? Does it use the same radio?
calebcoverdale said:
I know this is kind of off topic, but would this help us people with Motorola Atrix 2? Does it use the same radio?
Click to expand...
Click to collapse
No idea. I haven't even gotten the kernel to change yet, so I haven't gotten to mess with radio yet. The method itself should/would work though, but radio will require reverse engineering...perhaps find a similar phone with an open bootloader and disassemble and attempt to clone it's modules.
The latest change I made may or may not work, it was an attempt to remove atags from the kexec module based on an old patch I found, which added the functionality. This at leaset made kexec -l zImage work, but when I run kexec -e, the kexec binary complains about atags not being there...hrmmmph.
I may have to revert it (and will if we can get atags somehow) ...but if we can get the kexec bin to ignore /proc/atags or just find a way to rip them out of the running kernel, we'll be in business.
The commit: https://github.com/ilikenwf/kexec-mod-d2-dx/commit/12dffe0ea286be0fe9ab0303a5a35ed92be4ee2c
I'm also looking into 2ndboot.
I like where this is going! Keep working!
Sent from my DROID2 using xda premium
Okies, so, I emailed aliasxerog (original kexec-mod writer), and I hope he'll get back to me. Even though his twitter says he's a "former android developer," maybe he'll be willing to give me some hints so I can pick up where he left off.
I also got the froyo version of the module building properly based on his module, yet again, (all after SBF'ing my phone back down to motoblur froyo - yech!) but neither currently work... (note there's a gingerbread and a froyo branch on my repo): https://github.com/i...kexec-mod-d2-dx
The froyo one throws the following error, which stops me dead in the water:
Code:
Could not find a free area of memory of 3007dc bytes...
The gingerbread one loads the kernel into memory but won't execute it due to our not having atags.
We've moved our git repos to an organization for easier collaboration:
https://github.com/organizations/D2-DX-Customboot
links are imcomplete.
use URL lable pls.
Cross compiler version ?
hello,
Sorry but I am not able to use the sourceforge link that you provided to download kernel source .. Also please share what cross compiler version is to be used....
Thanks in advance.

Development Questions

I've been waiting for agrabren to drop his cm code for several months now. Guess that kid really did swallow him whole. Well, I got tired of waiting and decided to see if I could get cm to build myself. Heh, not so much. I can't even get cwm to build and boot correctly. So, I'm here to see if someone can point out what I'm doing wrong.
Here's what I did to build. Pulled CM 11.0 and set up the build directories. Copied device/nvidia and vendor/nvidia from the most recent shield tree. Copied the kernel from the shield tree into device/nvidia/roth and modified the configs to build from there. I modified some of the configs and made cm.mk based off the tf701t port which also uses a tegra 4. A lunch and a couple makes later, I got a recovery.img, but it's too big. 8.2MB won't fit in a 8 MB partition. The kernel came out at 5.9 MB and the ramdisk-recovery.img is 2.3 MB. In an official shield build, the ramdisk-recovery.img is 777KB. I know cwm has a lot more in it, but I seem to be missing something to shave 200KB off it. BoardConfig.mk has the recovery partition size set to 8MB, but that doesn't seem to make a difference. Is there something somewhere that can be used to strip less useful stuff out the recovery image?
Thanks for any help,
Steel01
Steel01 said:
I've been waiting for agrabren to drop his cm code for several months now. Guess that kid really did swallow him whole. Well, I got tired of waiting and decided to see if I could get cm to build myself. Heh, not so much. I can't even get cwm to build and boot correctly. So, I'm here to see if someone can point out what I'm doing wrong.
Here's what I did to build. Pulled CM 11.0 and set up the build directories. Copied device/nvidia and vendor/nvidia from the most recent shield tree. Copied the kernel from the shield tree into device/nvidia/roth and modified the configs to build from there. I modified some of the configs and made cm.mk based off the tf701t port which also uses a tegra 4. A lunch and a couple makes later, I got a recovery.img, but it's too big. 8.2MB won't fit in a 8 MB partition. The kernel came out at 5.9 MB and the ramdisk-recovery.img is 2.3 MB. In an official shield build, the ramdisk-recovery.img is 777KB. I know cwm has a lot more in it, but I seem to be missing something to shave 200KB off it. BoardConfig.mk has the recovery partition size set to 8MB, but that doesn't seem to make a difference. Is there something somewhere that can be used to strip less useful stuff out the recovery image?
Thanks for any help,
Steel01
Click to expand...
Click to collapse
I was previously working on cm but failed as I don't have the device. I suggest building the aosp 4.3 for the shield then work your way up to cm
http://nv-tegra.nvidia.com/gitweb/?...;a=blob_plain;f=README;hb=rel-roth-r3-partner
My idea was to see what's needed and not needed as a lot won't be used in cm.
Unjustified Dev said:
I was previously working on cm but failed as I don't have the device. I suggest building the aosp 4.3 for the shield then work your way up to cm
http://nv-tegra.nvidia.com/gitweb/?...;a=blob_plain;f=README;hb=rel-roth-r3-partner
My idea was to see what's needed and not needed as a lot won't be used in cm.
Click to expand...
Click to collapse
I've got the device and some development knowledge, but a complete lack of android build system knowledge.
I've got the nvidia 4.3 recovery to build (on a VM since it's less tolerant of JDKs than cm), the rest should compile easily enough. So if I was to build up from there, what kind of process would I be looking at? I would presume start with replacing the recovery with cwm. If so, where am I looking to replace stuff at?
Do you still have any of the work you had started?
Steel01
Steel01 said:
I've got the device and some development knowledge, but a complete lack of android build system knowledge.
I've got the nvidia 4.3 recovery to build (on a VM since it's less tolerant of JDKs than cm), the rest should compile easily enough. So if I was to build up from there, what kind of process would I be looking at? I would presume start with replacing the recovery with cwm. If so, where am I looking to replace stuff at?
Do you still have any of the work you had started?
Steel01
Click to expand...
Click to collapse
Yes, getting the recovery booting is the first thing.I can't really help right now but in a few hours or so I will pm you here's the github i'm going to be working at (removed) as you see there's not really anything there. I'm working on making the device tree work in a cm tree. It will probably be a while before my aosp build finishes. If you wish to chat on hangouts pm your email address .
Unjustified Dev said:
Yes, getting the recovery booting is the first thing.I can't really help right now but in a few hours or so I will pm you here's the github i'm going to be working at https://github.com/CM-Shield as you see there's not really anything there. I'm working on making the device tree work in a cm tree. It will probably be a while before my aosp build finishes. If you wish to chat on hangouts pm your email address .
Click to expand...
Click to collapse
Thanks, pm sent. Guess I'll fire off a full aosp build so we'll have the same trees available at that time.
Steel01
Edit: Today's just not my day. None of my builds from nvidia's aosp 4.3 r3 tree boot. A normal boot hangs at the shield logo. The recovery gives me the red triangle (not terribly surprised since nvidia's official gives me that too, only agrabren's cwm recovery works for me). I didn't think too much of it when I built off of openjdk 1.6, but now that I pulled sun's 1.6-41 and it still doesn't boot, I'm a bit miffed. Shouldn't be a reason why I can't build off CentOS. Maybe I'll load up a Debian or Mint VM and try building off that. I really don't want to touch Ubuntu which all the android docs are written for...
Okay, so I don't feel so bad anymore. The kernel boots fine. But the system image generated from the official shield tree doesn't. It starts the boot animation and hangs. But I have adb and complete shell access. Wipes don't help. Which if I was to guess means I have a java problem on the build VM. The C only kernel is fine, but nothing else works right. Big surprise there. That or something like the graphics blob didn't get packaged in. I'll play with it some more and might be able to build a working system by the time Unjustified Dev pushes some code up...
Steel01
Edit: And according to a logcat, I'm missing some so's. Don't know if I missed a build failure or if the official tree is broken.
Steel01 said:
Okay, so I don't feel so bad anymore. The kernel boots fine. But the system image generated from the official shield tree doesn't. It starts the boot animation and hangs. But I have adb and complete shell access. Wipes don't help. Which if I was to guess means I have a java problem on the build VM. The C only kernel is fine, but nothing else works right. Big surprise there. That or something like the graphics blob didn't get packaged in. I'll play with it some more and might be able to build a working system by the time Unjustified Dev pushes some code up...
Steel01
Edit: And according to a logcat, I'm missing some so's. Don't know if I missed a build failure or if the official tree is broken.
Click to expand...
Click to collapse
Did you get the closed source binaries extracted?
Unjustified Dev said:
Did you get the closed source binaries extracted?
Click to expand...
Click to collapse
Yeah I did. I'm running another build and capturing the output this time to see if there's a build failure. The files the log was complaining about are in a vendor prebuilt folder, but didn't get copied to out like most of the other files in that directory did. If this build does the same, I'll hand copy the files into the out directory and hope the command to build the system image just globs that directory.
Steel01
Steel01 said:
Yeah I did. I'm running another build and capturing the output this time to see if there's a build failure. The files the log was complaining about are in a vendor prebuilt folder, but didn't get copied to out like most of the other files in that directory did. If this build does the same, I'll hand copy the files into the out directory and hope the command to build the system image just globs that directory.
Steel01
Click to expand...
Click to collapse
I suggest creating a better call to vendor blobs you can clearly find which ones are needed create an extract-files.sh script as so. I've began partially haven't had time to work on it. I chose a nvidia device because some of the blobs are the same naming less time.
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/extract-files.sh
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/proprietary-files.txt
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/setup-makefiles.sh
Unjustified Dev said:
I suggest creating a better call to vendor blobs you can clearly find which ones are needed create an extract-files.sh script as so. I've began partially haven't had time to work on it. I chose a nvidia device because some of the blobs are the same naming less time.
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/extract-files.sh
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/proprietary-files.txt
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/setup-makefiles.sh
Click to expand...
Click to collapse
Ah, okay. It would be better to base off the tf701t, though. It's a tegra 4 device whereas the tf700t is a tegra 3. I'll see what I come up with after I flash stock back.
Steel01
Steel01 said:
Ah, okay. It would be better to base off the tf701t, though. It's a tegra 4 device whereas the tf700t is a tegra 3. I'll see what I come up with after I flash stock back.
Steel01
Click to expand...
Click to collapse
Actually I was just looking at it. We have an advantage we already have a device tree and I like their layout so I'm going to copy that when I have time and build from it.
Still some unsolved things I will discuss later
Unjustified Dev said:
Actually I was just looking at it. We have an advantage we already have a device tree and I like their layout so I'm going to copy that when I have time and build from it.
Still some unsolved things I will discuss later
Click to expand...
Click to collapse
Yeah, that would make it much simpler. I had that device tree building inside the cm11 repo a couple days ago, but I broke the kernel build somewhere along the way and haven't figured out what I did yet.
I'm currently working on getting the blob list together. Skimming the tf701t down to what exists on the shield, then building up from there. Will probably take a couple days with my schedule though, so you might beat me through it.
Steel01
Steel01 said:
Yeah, that would make it much simpler. I had that device tree building inside the cm11 repo a couple days ago, but I broke the kernel build somewhere along the way and haven't figured out what I did yet.
I'm currently working on getting the blob list together. Skimming the tf701t down to what exists on the shield, then building up from there. Will probably take a couple days with my schedule though, so you might beat me through it.
Steel01
Click to expand...
Click to collapse
I got latest ota image from nvidia and extracted the system.img will be tomorrow when I finish gathering all blobs and I will send you a pm. once we get cwm working we can move forward wish the guy who compiled it got a change to upload his source so I can see how to do the dtb stuff . I know someone who can help I will contact them tomorrow
Unjustified Dev said:
I got latest ota image from nvidia and extracted the system.img will be tomorrow when I finish gathering all blobs and I will send you a pm. once we get cwm working we can move forward wish the guy who compiled it got a change to upload his source so I can see how to do the dtb stuff . I know someone who can help I will contact them tomorrow
Click to expand...
Click to collapse
Okay, great. I Got a hack of cm build together using the attached proprietary-files.txt and a prebuilt kernel from the shield tree. Ended up missing a couple so's, but I'm done for the night. Once you get the device tree to compile, can you push that to the github org and give me access to it?
On the dtb issues, doesn't the normal kernel compile output the dtb?
The official BoardConfig sets:
TARGET_USE_DTB := true
TARGET_KERNEL_DT_NAME := tegra114-roth
BOOTLOADER_SUPPORTS_DTB := true
Then kernel.mk sets:
KERNEL_DTS_PATH := $(KERNEL_PATH)/arch/$(TARGET_ARCH)/boot/dts/$(TARGET_KERNEL_DT_NAME).dts
BUILT_KERNEL_DTB := $(NV_KERNEL_INTERMEDIATES_DIR)/arch/$(TARGET_ARCH)/boot/$(TARGET_KERNEL_DT_NAME).dtb
and further down calls
+$(hide) $(kernel-make) $(TARGET_KERNEL_DT_NAME).dtb
That correctly gives me the dtb file. Though, chances are there are other lines I missed that affect it.
Steel01
Steel01 said:
Okay, great. I Got a hack of cm build together using the attached proprietary-files.txt and a prebuilt kernel from the shield tree. Ended up missing a couple so's, but I'm done for the night. Once you get the device tree to compile, can you push that to the github org and give me access to it?
On the dtb issues, doesn't the normal kernel compile output the dtb?
The official BoardConfig sets:
TARGET_USE_DTB := true
TARGET_KERNEL_DT_NAME := tegra114-roth
BOOTLOADER_SUPPORTS_DTB := true
Then kernel.mk sets:
KERNEL_DTS_PATH := $(KERNEL_PATH)/arch/$(TARGET_ARCH)/boot/dts/$(TARGET_KERNEL_DT_NAME).dts
BUILT_KERNEL_DTB := $(NV_KERNEL_INTERMEDIATES_DIR)/arch/$(TARGET_ARCH)/boot/$(TARGET_KERNEL_DT_NAME).dtb
and further down calls
+$(hide) $(kernel-make) $(TARGET_KERNEL_DT_NAME).dtb
That correctly gives me the dtb file. Though, chances are there are other lines I missed that affect it.
Steel01
Click to expand...
Click to collapse
I read that from the OC kernel thread and it's 1am here so I'm done for the night as well. I am giving you permission to CM-Shield right now. I already cloned tf701 device tree and renamed it. I was working on adding in the files from nvidia tree some are going to go prebuilt might need some patches from nvidia git as well not so sure right now. I really need to get this device. Blindly working isn't much fun. As far as I know you use fastboot flash dtb that dtb is never updated and might not be needed not sure yet I have never had to deal with dtb.
Unjustified Dev said:
I read that from the OC kernel thread and it's 1am here so I'm done for the night as well. I am giving you permission to CM-Shield right now. I already cloned tf701 device tree and renamed it. I was working on adding in the files from nvidia tree some are going to go prebuilt might need some patches from nvidia git as well not so sure right now. I really need to get this device. Blindly working isn't much fun. As far as I know you use fastboot flash dtb that dtb is never updated and might not be needed not sure yet I have never had to deal with dtb.
Click to expand...
Click to collapse
Alright. If you haven't got the dtb stuff straightened out by the time I get back to my dev machine tomorrow night, I'll tackle that. I've had some hobbyist experience with that on some embedded dev boards. In general, I wouldn't think the dtb would ever change. Definitely not within a kernel version. Definitely needed, though. But in the spirit of open source and building as much as possible from source, it will be good to make that build. Shouldn't be too difficult. And yes, 1:30 AM does bad things to cognizance. *passes out*
Steel01
Edit: I took a look at the tf701t kernel tree this morning. The dtb part may already be done if we base from there. A dts file already exists for roth (arch/arm/boot/dts) and the make file a dir up appears to glob the dts directory and build dtb's for each. I don't have access to a build tree to verify that atm, though. Bit if that's true, the kernel should be as simple as cloning tf701t, renaming its defconfig and modifying what little differences there are if any, then copying the dtb to the out directory.
Edit 2: A bit of googling turned up http://www.armadeus.com/wiki/index.php?title=Kernel-with-device-tree which says a config flag handles building dtb's. The tf701t config already sets CONFIG_MACH_ROTH=y, so I'm wondering if that kernel won't boot on the shield out of the box. Something I'll try once I get back to my dev machine tonight.
Well, I did get the dtb to build using the CM-Shield device tree and the kernel from tf701t. Haven't been able to test yet, though. And it was kind of a hack, but I don't know a better place to plug it than modules. In BoardConfig.mk after the two target kernel lines:
KERNEL_DTB:
*tab* make -C $(KERNEL_OUT) ARCH="arm" CROSS_COMPILE="arm-eabi-" tegra114-roth.dtb
*tab* mv $(KERNEL_OUT)/arch/arm/boot/tegra114-roth.dtb $(OUT)
TARGET_KERNEL_MODULES := KERNEL_DTB
That should probably pull arch and compiler prefix from cm env cars, but I don't know what they are. The dtb name should also be set as a const. Once I see if the kernel boots in a couple hours, I'll push my device branch up. Only kernel change was renaming the defconfig.
Steel01
Steel01 said:
Well, I did get the dtb to build using the CM-Shield device tree and the kernel from tf701t. Haven't been able to test yet, though. And it was kind of a hack, but I don't know a better place to plug it than modules. In BoardConfig.mk after the two target kernel lines:
KERNEL_DTB:
*tab* make -C $(KERNEL_OUT) ARCH="arm" CROSS_COMPILE="arm-eabi-" tegra114-roth.dtb
*tab* mv $(KERNEL_OUT)/arch/arm/boot/tegra114-roth.dtb $(OUT)
TARGET_KERNEL_MODULES := KERNEL_DTB
That should probably pull arch and compiler prefix from cm env cars, but I don't know what they are. The dtb name should also be set as a const. Once I see if the kernel boots in a couple hours, I'll push my device branch up. Only kernel change was renaming the defconfig.
Steel01
Click to expand...
Click to collapse
So far going to push unmodified kernel now https://github.com/CM-Shield/android_device_nvidia_roth
Progress finally. Got a cwm recovery that boots and looks like it works plus fits in the partition. Most of the buttons aren't mapped yet and the screen is rotated, but that should be the east part to fix.
Steel01
Getting closer. But still no dice. Logcat of current iteration.
Steel01

The Theory of Everything (Building MTK from saucery) asop cm miui ubuntu

Welcome​
I have started this thread for the THEORETICAL development of the mt6732/mt6752 from source if such a thing happened to exist which of course it does not.
While compiling from source is pretty well documented :good: compiling MTK is not so well documented especially the mt6732/6752.
I have tried to keep this thread as ambiguous as possible and hopefully we will be left in peace to iron out any difficulties.
DO's:
I am a Total Noob myself to compiling from source but experienced enough to use the xda search box, Google and Youtube first before asking any questions. If your still confused after using the above then by all means ask here.
DON'T s:
If your a noob who should happen upon this thread then by all means read and learn but please respect the dev's by not asking random question without searching first :fingers-crossed:
SHARING:
Please only share things of a sensitive nature with recognised members who you know and via the PM. :good:
Lets just see how far we can push this Kernel
Recommended Reading:
[GUIDE]Building a Kernel from source{Mediatek}
Build Kernel MT6577 - Can't boot after build
How To Port CyanogenMod Android To Your Own Device
XDA:DevDB Information
k01q_e k01q_h, Kernel for all devices (see above for details)
Contributors
bigrammy
Kernel Special Features: Remains to be seen
Version Information
Status: Testing
Created 2015-02-25
Last Updated 2015-02-25
I am here, reporting for duty. If anyone wants an extra "potato" because he has too much "ketchup" for use feel free to ask me
Just to be clear
I am new to compiling from source in any shape or form
I believe the kernel to be not a problem and I know dev's are working on getting our phone on cm and maybe others :fingers-crossed:
But me being me I am very curious and would like to understand how we would go about doing what @varun.chitre15 managed to do for the mt6582 Here
I have the PC all setup for building now thanks to @carliv great guide Here and the cm and android tut's I also found this useful guide on youtube by Dave Bennet Here
Our device is not on the cm or google repo so how do we add it locally.
Do we need any special commands for mediatek
Could we use the mt6582 repo and substitute or mod the files
As you can see I have more questions than answers as normal :laugh:
I dont want to tread on any toes here or take over current developing but just want to learn as said in the OP there is a lack of mtk guides regarding this.
If I missed a clear mtk guide then please post the link to it. :good:
In short your looking at manifests. http://wiki.cyanogenmod.org/w/Doc:_Using_manifests
carliv (I think) posted the device config on github - link in your SPFlash thread somewhere.
Found it: https://github.com/carliv/device_elephone_p6000?files=1
Vendor files
I have compiled and flashed a kernel, I've been running it for 24+ hours with no obvious issues. It's honestly very easy to just get it to build if you don't try to make major changes.
I have (very lazily) tried to change a couple of things in the config to fix the known issues (OTG, compass): unfortunately I have no way to test the OTG function right now, while the compass did not magically start working. On the other hand, the notification light issue which is introduced by V8.4 is not strictly or exclusively kernel-dependent, since I am running V8.3 with my own kernel and the notification function is intact. That's all I can share at the moment.
xenonism said:
I have compiled and flashed a kernel, I've been running it for 24+ hours with no obvious issues. It's honestly very easy to just get it to build if you don't try to make major changes.
I have (very lazily) tried to change a couple of things in the config to fix the known issues (OTG, compass): unfortunately I have no way to test the OTG function right now, while the compass did not magically start working. On the other hand, the notification light issue which is introduced by V8.4 is not strictly or exclusively kernel-dependent, since I am running V8.3 with my own kernel and the notification function is intact. That's all I can share at the moment.
Click to expand...
Click to collapse
Can you switch on and post the /proc/config ?
Regarding the notification lights, I think v8.4 introduced the custom partition (might be wrong on that). Running grep -r "ro.notification.breath" /system/ the only result I got was services.odex (might have been settings.odex). I've bak(smali)ed it but couldn't see the difference between the two that would explain the change.
HypoTurtle said:
Can you switch on and post the /proc/config ?
Regarding the notification lights, I think v8.4 introduced the custom partition (might be wrong on that). Running grep -r "ro.notification.breath" /system/ the only result I got was services.odex (might have been settings.odex). I've bak(smali)ed it but couldn't see the difference between the two that would explain the change.
Click to expand...
Click to collapse
The config file is attached to the post, it's too big to paste it.
I have tried the new ROM which came out today, then flashed my kernel. I can't use either SIM card anymore. Flashed the boot.img that comes with the ROM - same. I guess I gotta go back to V8.3 for now.
The new ROM doesn't seem to be the same as the OTA: it reports as: Elephone_P6000_02_V8.0_20150206.
About the notification issues (which bothers me the most), I haven't had much time do to more experiments, but I was thinking this (which probably also led to my confusion*): there's a chance the functionality is not removed or shut down, at least in the intentions of the maker. After all, in V8.4 (and in the new ROM), when the phone is connected the light stays on, while notifications make it breath. While not a desirable behaviour (at least IMO), I wouldn't call it... a non-behaviour, so to say. So perhaps the functionality itself is intact but something is altering the way it works, for whatever reason. I also did some unpacking and grepping a few days ago, but I couldn't find anything useful.
* At some point I thought the issue was fixed because the light was breathing while connected to my PC, but it was probably because I had a notification to read.
xenonism said:
The config file is attached to the post, it's to big to paste it.
I have tried the new ROM which came out today, then flashed my kernel. I can't use either SIM card anymore. Flashed the boot.img that comes with the ROM - same. I guess I gotta go back to V8.3 for now.
The new ROM doesn't seem to be the same as the OTA: it reports as: Elephone_P6000_02_V8.0_20150206.
Click to expand...
Click to collapse
Lets not speculate too much - but perhaps there was a minor board change between the first and second preorders, notification could be a problem with granting notification access (in settings) - could this be a selinux issue? It would explain why things like Light manager work - as you grant them notification access.
For lost Imei - can you compare the custom partition to the one in the ota?
If anyone needs an easier way to grab the 'ketchup', my GitHub has it. Click on my blog link in my signature.
BachMinuetInG said:
If anyone needs an easier way to grab the 'ketchup', my GitHub has it. Click on my blog link in my signature.
Click to expand...
Click to collapse
Thanks bro,
Nice log
I was going to try use the sprout config as this is nice and clean Here when I have worked out how to do things that is.
My eyeballs are bleeding now with all this reading but from what I can see most of files are the same names so maybe we could just replace them with ours probably 98% ish
I did see one ROM some place for the mt6732/52 that had mt6582 references I just wish I could remember where I had seen it
Like I say I am a noob to this compiling and linux stuff so I maybe talking out of my ass :laugh:
bigrammy said:
Thanks bro,
Nice log
I was going to try use the sprout config as this is nice and clean Here when I have worked out how to do things that is.
My eyeballs are bleeding now with all this reading but from what I can see most of files are the same names so maybe we could just replace them with ours probably 98% ish
I did see one ROM some place for the mt6732/52 that had mt6582 references I just wish I could remember where I had seen it
Like I say I am a noob to this compiling and linux stuff so I maybe talking out of my ass :laugh:
Click to expand...
Click to collapse
I'm actually a noob too, and honestly I've only ever successfully built a fakeflash (temporary recovery) that didn't even work.
bigrammy said:
Thanks bro,
Nice log
I was going to try use the sprout config as this is nice and clean Here when I have worked out how to do things that is.
My eyeballs are bleeding now with all this reading but from what I can see most of files are the same names so maybe we could just replace them with ours probably 98% ish
I did see one ROM some place for the mt6732/52 that had mt6582 references I just wish I could remember where I had seen it
Like I say I am a noob to this compiling and linux stuff so I maybe talking out of my ass :laugh:
Click to expand...
Click to collapse
Can anyone actually make a guide noob friendly to build kernel from source? I got kernel with me locally zip file I want to build it please any help?
Tech N You said:
Can anyone actually make a guide noob friendly to build kernel from source? I got kernel with me locally zip file I want to build it please any help?
Click to expand...
Click to collapse
I think you can use the scripts in the root of the source code to build the kernel? make<something>.sh.
Make sure you're on Linux (Ubuntu preferred) and that you have all dependencies installed correctly. To execute the script, simply go to the Terminal, cd to the location, then type . make<something>.sh
Tech N You said:
Can anyone actually make a guide noob friendly to build kernel from source? I got kernel with me locally zip file I want to build it please any help?
Click to expand...
Click to collapse
Have a look at the README.
Does make menuconfig work here?
These few simple instructions from the readme file enable you to build a working kernel (at least in a Linux environment):
Code:
How to Build
kernel
======
1. Get the prebuilt cross compiler from AOSP website:
$ git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6
2. Add required cross compiler to PATH:
$ export PATH=/YOUR_TOOLCHAIN_PATH/arm-eabi-4.6/bin:$PATH
$ export CROSS_COMPILE=arm-eabi-
3. Then use the following commands to build the kernel:
$ ./makeMtk k01q_e new k
make menuconfig can be made to work, but you need to set some parameters and I can't look into it right now.
You previously asked something about the custom partition, I need some guidance there as I am not familiar with the IMEI issue.
xenonism said:
These few simple instructions from the readme file enable you to build a working kernel (at least in a Linux environment):
Code:
How to Build
kernel
======
1. Get the prebuilt cross compiler from AOSP website:
$ git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6
2. Add required cross compiler to PATH:
$ export PATH=/YOUR_TOOLCHAIN_PATH/arm-eabi-4.6/bin:$PATH
$ export CROSS_COMPILE=arm-eabi-
3. Then use the following commands to build the kernel:
$ ./makeMtk k01q_e new k
make menuconfig can be made to work, but you need to set some parameters and I can't look into it right now.
You previously asked something about the custom partition, I need some guidance there as I am not familiar with the IMEI issue.
Click to expand...
Click to collapse
Yea wasn't sure about menuconfig as mtk uses projectconfig rather than def_configs.
In the custom partition there are files like /custom/etc/firmware/modem.img etc. When messing with a Flyme port it was these files (and possible conflicts in /system) that caused an IMEI:nul.
FYI I opened the custom partitions on windows using an ext viewer after running the imgs through sgs2toext4.
Kernel building Mediatek
Tech N You said:
Can anyone actually make a guide noob friendly to build kernel from source? I got kernel with me locally zip file I want to build it please any help?
Click to expand...
Click to collapse
Not sure if you guys have seen or read this but it's a pretty comprehensive guide to building the mediatek kernel by @MasterAwesome and should really be compulsary for all kernel related things thread here http://forum.xda-developers.com/showthread.php?t=2754513
@HypoTurtle
Regarding the custom partition this is or could be a problem for us now and in the future and may require further investigation. The cm sprout branch has the modem.img in the (normal place /system/etc/firmware) but as you say ours is in the custom partition which is probably to protect it from bad /system flashes
Thing is I see no normal type link to it in the /system/etc/firmware so it must be linked some other way which may explain why all my port attempts failed as none of them used a custom partition (Asus_X002)
Maybe we will have to repartition the emmc to a standard config and alter the kernel (if the links are set via the kernel that is) for cm and other ports to work smoothly as I am unsure just how everything is linked up.
I have not had much experience with custom partitions so someone one know's of a good info source please link it. :good:
Hopefully Master @Santhosh M can figure out what's going on with the custom partition :fingers-crossed:
bigrammy said:
@HypoTurtle
Regarding the custom partition this is or could be a problem for us now and in the future and may require further investigation. The cm sprout branch has the modem.img in the (normal place /system/etc/firmware) but as you say ours is in the custom partition which is probably to protect it from bad /system flashes
Thing is I see no normal type link to it in the /system/etc/firmware so it must be linked some other way which may explain why all my port attempts failed as none of them used a custom partition (Asus_X002)
Click to expand...
Click to collapse
The partition is symlinked from .../by-name/custom (which is symlinked by the kernel from dev/block/mmcblk0p12) to /dev/customimg which is mouned after an e2fsck to /custom. /custom isn't linked to /system, it's just added to the global environment (init.environ.rc), will need to check on the environ, I'm on flyme and it has /custom/lib added to the library path (which doesn't exist).
HypoTurtle said:
The partition is symlinked from .../by-name/custom (which is symlinked by the kernel from dev/block/mmcblk0p12) to /dev/customimg which is mouned after an e2fsck to /custom. /custom isn't linked to /system, it's just added to the global environment (init.environ.rc), will need to check on the environ, I'm on flyme and it has /custom/lib added to the library path (which doesn't exist).
Click to expand...
Click to collapse
Haha thanks that explains a lot of weird things perfectly. :good:
What's the problem or what is the issue here.
Mediatek compiling guide ( by masterawesome ) that you have linked to is not actually practically this mtk kernel is done and is just way too complicatedly explained.
There is no defconfig stuff or pulling config.gz from phone in mtk. In this new source its just simple. Set up your toolchain path. Execute the makeMtk followed by the project no u want. Get zImage and patch it for mtk header and merge it with stock ramdisk. For this newer mtk chipsets repack has an extra stuff where u have to be careful of kernel command line parameters.
That's it the kernel stuff in mtk

[ROM][7.1.2][CR_DROID][UNOFFICIAL][OPTUS_X_SPIRIT_5044T][mt6737m_35m]

SEE 4TH POST FOR ROM LINK
DISCLAIMER
As per always im not responsible for any problems that may or may not arrise from this UNOFFICIAL build, i am in no way responsible for any flash issues using SP flash tool, What you do here you do of your own accorrd i never forced you to flash anything, now the legal part is out of the way.
______________Device_specification____________
Model : 5044T
Chip type : eMMC
Fs type : Ext4
Mtk chip type : MTK6737M
Mtk chip type : MTK6735M
Kernel version : 3.18.19+
........Welcome to CR Droid 3.8.7 UNOFFICIAL.......
** NOTE **
This firmware is for Alcatel U5/Optus x Spirit 5044T models ONLY,
NOT WORKING
• Front Camera DOES NOT work
____________________________________________
PRE REQUISITE'S
• OEM unlocked in developer options
• Flash TWRP with SP flash tool.
• Format data in wipe menu before flashing rom & Gapps
• Install Rom first then install Gapps straight after
• Wipe cache/Dalvik & reboot
___________________________________________
LINKS
TWRP 3.2.3-0
https://drive.google.com/file/d/1YMfYp4z1tgdjvlK6KRlMsGLmkW_oikZz/view?usp=drivesdk
GAPPS
https://opengapps.org
SP FLASH TOOL
https://spflashtool.com
MEDIATEK VCOM FLASH DRIVER
https://spflashtool.com/download/MediaTek_USB_VCOM_drivers.zip
Pics of build
Links been pulled temporarily due to a modem issue.
Currently rectifying the situation now link will be back up asap.
See links on first post for GAPPS, TWRP, & SP flash tool.
CR droid 3.8.7 2019-02-24
https://drive.google.com/file/d/1S78TeH-8rHXAhqmSZS_h1PyoEGhSxUE0/view?usp=drivesdk
DISCLAIMER
As per always im not responsible for any problems that may or may not arrise from this UNOFFICIAL build, i am in no way responsible for any flash issues using SP flash tool, What you do here you do of your own accorrd i never forced you to flash anything, now the legal part is out of the way.
CHANGELOG
• RIL error is now resolved
• Minor changes to UI,
• Removed substratum until i can fix
• changed to TCL fingerprint for the play store,
• Added low ram optimiastion
• Added Volte to /etc /bin /lib & boot.img
• Added Vilte to /etc /bin /lib & boot.img
• Added hd voice calling
• Added Dual mic support
• Added NFC compatabilty
• Changed some cam libs to clean the picture up, touch to focus works camera quality is on par with stock if not better.
• Ril optimisations, call quality is now same as stock
NOT WORKING
• Vilte, driver compatabilty issue trying to fix may work partially
• NFC, im working on it for now everything but the running app has been placed.
• FRONT CAMERA DOES NOT WORK
dont ask me to fix it, i will decompile the kernel when i get free time to do so to try and fix,
ive already chowned & chmod'ed init.rc & init.mt6735 with drivers from stock, switched to running through mediaserver instead of cameraserver in service_contexts as it does on stock, created an init.camera.rc to enforce the stock camera permissions, switched each lib out individually leaving only those that dont break the camera, switched camera.mt6735m out in HW aswell as the mtk_camera_clientand it still dosent work i will continue to work on this problem until resolved
Nice job with the ROM, mate. I presume you're Australian, right? Had to mention it based on the Optus reference so yeah.
And care to expound on decompiling the kernel? I presume you can deduce what's going on with it so you could build an equivalent kernel using extant sources, yes?
blakegriplingph said:
Nice job with the ROM, mate. I presume you're Australian, right? Had to mention it based on the Optus reference so yeah.
And care to expound on decompiling the kernel? I presume you can deduce what's going on with it so you could build an equivalent kernel using extant sources, yes?
Click to expand...
Click to collapse
Hey mate sorry for late reply, been finishing a ubifs cyanogenmod 11 build ive jjust released,
Cheers for the feedback yeah this one is for alcatel 5044T using kernel 3.18.19+ great rom though just havent gotten round to decompiling kernel to fix the front camera managed to interpolate the back though to be better than stock
I use a .sh file called kernel-decompile.sh usually but havent decompiled a kernel in a while i try to use stock untouched as it saves the headache of getting kernel readable to make changes,
Did you make any progress on your build yet ? Managed to take a breif look at your device tree i noticed in one of the files it was screeming at the init.environ.rc is this present in your boot.img as its stating that the paths are missing for it if you have the init.environ.rc present you just need to add the paths listed into there corresponding path being either BOOTCLASSPATH or SYSTEMCLASSPATH
I noticed you init.rc is not right at all there is no information within to run any of the /bin resources required to execute gui, post fs-data section is also missing aswell as setting up the global evironment was also wrong i beleive as there was no info for chowning or chmodding below the mkdir asserts,
Ive still not looked at alot but everything else that i have managed to look at seems to be pretty good
I should be hopefully getting my Lineage 14.1 build up for the alcatel pixi 3 using stock 3.4.67 kernel soon so you may be able to see how i made the boot.img and compare it yours if you want or i have my LineageOS 13.0 build already up for the Pixi 3 already which uses the same setup pretty much because afaik the way the fs setup is set it out in the fstab and init.rc is all the same from 5.0+ onwards as it uses encrypted footers and what not, i had to vold manage the 900Mb /custpack partition to be used as user accessible data for file transfers and general storage of photos videos etc as it would not mount any other way and would cause me infinite boot loop i had to also set the 3.6GB /internal storage as a voldmanaged user inaccessible partition reserved for system storage as the /system partition is only 512mb so ive been struggling for space to make everything work but its nearly done
Matty1993 said:
Hey mate sorry for late reply, been finishing a ubifs cyanogenmod 11 build ive jjust released,
Cheers for the feedback yeah this one is for alcatel 5044T using kernel 3.18.19+ great rom though just havent gotten round to decompiling kernel to fix the front camera managed to interpolate the back though to be better than stock
I use a .sh file called kernel-decompile.sh usually but havent decompiled a kernel in a while i try to use stock untouched as it saves the headache of getting kernel readable to make changes,
Did you make any progress on your build yet ? Managed to take a breif look at your device tree i noticed in one of the files it was screeming at the init.environ.rc is this present in your boot.img as its stating that the paths are missing for it if you have the init.environ.rc present you just need to add the paths listed into there corresponding path being either BOOTCLASSPATH or SYSTEMCLASSPATH
I noticed you init.rc is not right at all there is no information within to run any of the /bin resources required to execute gui, post fs-data section is also missing aswell as setting up the global evironment was also wrong i beleive as there was no info for chowning or chmodding below the mkdir asserts,
Ive still not looked at alot but everything else that i have managed to look at seems to be pretty good
I should be hopefully getting my Lineage 14.1 build up for the alcatel pixi 3 using stock 3.4.67 kernel soon so you may be able to see how i made the boot.img and compare it yours if you want or i have my LineageOS 13.0 build already up for the Pixi 3 already which uses the same setup pretty much because afaik the way the fs setup is set it out in the fstab and init.rc is all the same from 5.0+ onwards as it uses encrypted footers and what not, i had to vold manage the 900Mb /custpack partition to be used as user accessible data for file transfers and general storage of photos videos etc as it would not mount any other way and would cause me infinite boot loop i had to also set the 3.6GB /internal storage as a voldmanaged user inaccessible partition reserved for system storage as the /system partition is only 512mb so ive been struggling for space to make everything work but its nearly done
Click to expand...
Click to collapse
You're welcome, glad you had things sorted out on your end. I do have an init.environ.rc on my /out folder but I am not sure if it's right at all lol:
Code:
# set up the global environment
on init
export PATH /sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin
export ANDROID_BOOTLOGO 1
export ANDROID_ROOT /system
export ANDROID_ASSETS /system/app
export ANDROID_DATA /data
export ANDROID_STORAGE /storage
export ASEC_MOUNTPOINT /mnt/asec
export LOOP_MOUNTPOINT /mnt/obb
export BOOTCLASSPATH /system/framework/core-libart.jar:/system/framework/conscrypt.jar:/system/framework/okhttp.jar:/system/framework/core-junit.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/telephony-common.jar:/system/framework/voip-common.jar:/system/framework/ims-common.jar:/system/framework/mms-common.jar:/system/framework/android.policy.jar:/system/framework/apache-xml.jar
export SYSTEMSERVERCLASSPATH /system/framework/org.cyanogenmod.platform.jar:/system/framework/org.cyanogenmod.hardware.jar:/system/framework/services.jar:/system/framework/ethernet-service.jar:/system/framework/wifi-service.jar
export LD_PRELOAD libsigchain.so:libxlog.so
On the stock ramdisk it looks like this:
Code:
# set up the global environment
on init
export PATH /sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin
export LD_LIBRARY_PATH /vendor/lib:/system/lib
export ANDROID_BOOTLOGO 1
export ANDROID_ROOT /system
export ANDROID_ASSETS /system/app
export ANDROID_DATA /data
export ANDROID_STORAGE /storage
export ASEC_MOUNTPOINT /mnt/asec
export LOOP_MOUNTPOINT /mnt/obb
export BOOTCLASSPATH /system/framework/core.jar:/system/framework/conscrypt.jar:/system/framework/okhttp.jar:/system/framework/core-junit.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/framework2.jar:/system/framework/telephony-common.jar:/system/framework/voip-common.jar:/system/framework/mms-common.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/apache-xml.jar:/system/framework/webviewchromium.jar:/system/framework/mediatek-common.jar:/system/framework/mediatek-framework.jar:/system/framework/CustomProperties.jar:/system/framework/mediatek-telephony-common.jar:/system/framework/mediatek-tablet.jar
And by init.rc do you mean init.mt8127.rc? Could you tell me which parts are wrong please, as I've based this off @Stricted's MT8127 repo. I doubt that the missing "LD_LIBRARY_PATH" is at fault too. Also, I am getting a missing "__umodsi3" symbol error prior to introducing a (rather pointless imo) shim just to sort of make hwcomposer happy, even though I still end up not getting the GUI to show up.
You mind if we continue on discussing this on the LeapFrog development thread though? I don't want to stray off your original topic here anyway.
blakegriplingph said:
You're welcome, glad you had things sorted out on your end. I do have an init.environ.rc on my /out folder but I am not sure if it's right at all lol:
On the stock ramdisk it looks like this:
And by init.rc do you mean init.mt8127.rc? Could you tell me which parts are wrong please, as I've based this off @Stricted's MT8127 repo. I doubt that the missing "LD_LIBRARY_PATH" is at fault too. Also, I am getting a missing "__umodsi3" symbol error prior to introducing a (rather pointless imo) shim just to sort of make hwcomposer happy, even though I still end up not getting the GUI to show up.
You mind if we continue on discussing this on the LeapFrog development thread though? I don't want to stray off your original topic here anyway.
Click to expand...
Click to collapse
Hey mate sorry for late replty been helping a friend out building a twrp for them,
Yeah ill go through your init now on your guthub and ill type out into a notepad++ what i can visually see is wrong with it and any other files also,
LD_LIBRARY_PATH i beleive wont break a system and shouldn't stoo GUI loading up, also with HW composer could you notjust disabling it to run native 2D graphics ?
Anyhow yeah ill jump on the leapfrog forum when i get some time
user154 said:
Hey buddy, hows things going?
I was able to fix the front camera in my rom a few weeks ago,
There is no need to touch the boot image or kernel, I also experimented with changing permissions of camera drivers in the init files to no avail.
To fix we must ignore the advice of every porting guide and replace more than one lib.
In the end I looked at similar mtk kernel sources and was able to trace the error back to libcam.hal3a.v3.so however just changing this lib is not enough, we must also change some of its dependencies. Attached is a list of 12 libs that I changed to solve the problem
EDIT:
It may not be necessary to change all of these libs, you may be able to get away with just changing the hal3a libs and featureio and featureiodrv as these were the last ones I changed, I didnt try taking away any of the other libs I replaced as I found 720p recording was better and general camera quality had improved
Click to expand...
Click to collapse
Hey mate,
Yeah im not to bad sorry for late reply ahh sweet that means i dont have to decompile my kernel now that may have been one of the libs id changed that time id gotten it working and didnt even know id changed it, how did you figure tthat one out, as usually for cam the mains are camalgo, camdrv, gralloc & featureio i couldnt wrap my head round why i couldnt get it working again lol
Yeah 720p i found was the best optimal setting as SS 480p seemed to be a bit grainy and 1080p isnt device supportive so is so slow i havent released an update to CRdroid so may end up getting it done in the next few weeks 5044T users will be happy great work on figuring it out
Matty1993 said:
Hey mate sorry for late replty been helping a friend out building a twrp for them,
Yeah ill go through your init now on your guthub and ill type out into a notepad++ what i can visually see is wrong with it and any other files also,
LD_LIBRARY_PATH i beleive wont break a system and shouldn't stoo GUI loading up, also with HW composer could you notjust disabling it to run native 2D graphics ?
Anyhow yeah ill jump on the leapfrog forum when i get some time
Click to expand...
Click to collapse
I am not sure, something's keeping the loading animations from showing up, maybe I might have missed a few more blobs or whatnot. I'll have to upload an unsigned dump of the Epic for you to peruse some time. You mind if we get you a donor Epic whilst I wait for mac2612 at /r/OpenLF to get his own Epic being he's had Linux development experience before.
user154 said:
So I looked at logcat and saw that the issue was lensdrv looking in the wrong place for the lens. so I looked at some mtk kernel sources to see if I could trace lensdrv back to a specific lib. It appeared to be part of hal3a however changing this lib would make the camera app disappear, so I tried installing a different camera app which failed to install. when I looked at logcat the install failed because native libs were missing so I used a dependency viewer to see what libs were dependencies of hal3a and began changing them one by one, focussing on drv libs and then testing. Looking at logcat after I had changed a few I saw a reference to a problem with featureio so I opened featureio and featureiodrv in a hex viewer and one of them (cant remember which) had a string specifying the lens location, so I added these two and the front camera worked. This is what makes me think you could maybe get away with just changing hal3a and the 2 featureio libs to get the front camera working, however I was happy with how the camera was working so didnt try to take away any of the other depdencies I had changed
Click to expand...
Click to collapse
Dependency viewer? Which one are you using if you don't mind telling?
user154 said:
This is the one I use:
https://forum.xda-developers.com/android/software-hacking/tool-read-elf-gui-android-libs-t3717016
Click to expand...
Click to collapse
Hey bud sorry for the very late reply i feel quite rude i somehow managed to unmark my own thread just scoured my mentions section looking for a comment on it lol,
Had troubles with pc also blowing just got it fixed today so looking forward to getting camera all working well with it managed to make some progress with my rom before it did though
Ive turned my build into a vendor image as im also trying to incorporate all the test tools from the stock rom aswell as the VOLTE modem thats been attached to custpack in stock,
Managed to get most test tools working well but something wrong with the modem not engaging properly it says YES OPTUS but has no signal or service and imei is also blank not invalid but blank & gone lol yet sim still registers optus so i think im gonne be doing some debugging on it to see whats going wrong ive got a feeling i may need to reverse engineer the modem libs hoepfully not other than that ive only got a small bug when it first boots up that states "a vendor image mismatch has been detected, typically this means your vendor image is out of date please ensure your vendor image matches NJH47F"
Got me stumped a bit on it as i cant spot anything obvi wrong but ill persevere as having it as a vendor build seems to use at least 60-100mb less ram, first boot is quicker & there is virtually no lag at all compared to a traditional build and i was able to add all the SLPencryption and Fpsv files and libs without getting a bootloop as im trying to get encryption to work with it, not sure if its working though as i didnt get a chance to test yet.
Ill keep you updated on progress anyhow as i go when i get round to it i gotta help blake first though as i promised him id help him get his CM 12.1 working when i got my computer working again as hes been dying to get it working on his leapfrog epic
Hows things on your end with your rom ? Did you manage to make any progress with getting IMS, VOLTE or VILTE anywhere near working im struggling to say the least with it lol
MTK source code
Hi @Matty1993
Not sure if this will help but I have found the FULL Mediatek source code for the MT6737x.
The Android 8.1 sources can be found HERE along with some other useful things like the Android SDK source (This is the full 6.0 source code). :good:
I have downloaded the 8.1 source and it seems to be complete.
There are also full build instructions although you will need to create your own "Build Project" from what I understand or maybe you can just cherry pick what you need. :fingers-crossed:
Below are the officially maintained repository's on github.
OrangePi 4G-IOT
OrangePi 4G-IOT build on MTK6737 Soc, the officially maintained repository as follows:
kernel:
https://github.com/orangepi-xunlong/OrangePi4G-iot_kernel.git
u-boot:
https://github.com/orangepi-xunlong/OrangePi4G-iot_bootloader.git
build scripts
https://github.com/orangepi-xunlong/OrangePi4G-iot_scripts.git
external binary file
https://github.com/orangepi-xunlong/OrangePi4G-iot_external.git
toolchain
https://github.com/orangepi-xunlong/OrangePi4G-iot_toolchain.git
:fingers-crossed:
user154 said:
Hey, dont feel rude we cant all always reply straight away I've just welcomed my 2nd son into the world so not really been on here very much over the last month or so.
How is turning your build into a vendor image going? I didnt think this device had a seperate vendor partition just a sub folder of the system partition. If youve managed to give this device a vendor partition that would be quite a feat, theoretically it would mean it would be able to boot a GSI although I dont know how much mileage you would get out of this in reality.
I would imagine some of the problems you are having would be due to the system expecting files to be in one place but you have them in another, you should be able to work this out from the logs though if this is the case.
Good luck to the pair of you on the leapfrog epic front, sounds like a very fun project
I havent done much more on my ROM the only thing left to fix is IMS/VOLTE but I cannot test this so without having someone to test it and provide logs there isnt much I can do. I've been looking round for an oreo rom to port from but thanks to TCL deciding to compile the stock rom as 32 bit and not 64 this is proving rather difficult. I have looked at the possibility of porting 64 bit rom to 32 but from what I can tell the chances of ending up with a decent port rom with no major bugs is pretty slim.
At the moment my main project has been making a game for/with my eldest son, he is obsessed with kirby so made a simple platformer using sprites ripped from various kirby games.
Click to expand...
Click to collapse
Havent worked on the build in a while been in hosptial with pneumonia horrible just horrible wouldnt wish it upon anyone, before hand though yeah vendor build was going great so much more can be added and works where it dosent in /system, such as the slp encryption and cloud test suites etc would all give me bootloop when added to /bin /etc and /lib so what i did is made the system think its got an emulated /vendor partiton instead of me going to all the trouble to create a logical /vendor partitiion by editing a few things in the boot.img .rc files and slinking it in the cpiolist so that the dir is set in the rootfs with 0644 permission but still using 0755 permissions in /system/vendor took me a while to figure it out but even makes system boot and run faster and smoother dont know how thats possible though as it even uses 100mb less ram deffo works as /vendor but as the message i stated in the earlier post just wont go TF away no matter what i do lol,
Still fixing front camera trying to compile my own camera lib for the front but havent gotten round to it yet
bigrammy said:
Hi @Matty1993
Not sure if this will help but I have found the FULL Mediatek source code for the MT6737x.
The Android 8.1 sources can be found HERE along with some other useful things like the Android SDK source (This is the full 6.0 source code). :good:
I have downloaded the 8.1 source and it seems to be complete.
There are also full build instructions although you will need to create your own "Build Project" from what I understand or maybe you can just cherry pick what you need. :fingers-crossed:
Below are the officially maintained repository's on github.
OrangePi 4G-IOT
OrangePi 4G-IOT build on MTK6737 Soc, the officially maintained repository as follows:
kernel:
https://github.com/orangepi-xunlong/OrangePi4G-iot_kernel.git
u-boot:
https://github.com/orangepi-xunlong/OrangePi4G-iot_bootloader.git
build scripts
https://github.com/orangepi-xunlong/OrangePi4G-iot_scripts.git
external binary file
https://github.com/orangepi-xunlong/OrangePi4G-iot_external.git
toolchain
https://github.com/orangepi-xunlong/OrangePi4G-iot_toolchain.git
:fingers-crossed:
Click to expand...
Click to collapse
Big rammy my friend how have you been and thank you so much for linking me to some proper oreo source for these SoCs as i was trying to port lineage 15.0 32bit rom i found for Moto G4 MT6373M but just cant get it past the logo no natter what i do, being complete or near complete sources though i should be able to make something works cant thank you enough for the links again
Matty1993 said:
Big rammy my friend how have you been and thank you so much for linking me to some proper oreo source for these SoCs as i was trying to port lineage 15.0 32bit rom i found for Moto G4 MT6373M but just cant get it past the logo no natter what i do, being complete or near complete sources though i should be able to make something works cant thank you enough for the links again
Click to expand...
Click to collapse
Sorry to hear you have been seriously ill with pneumonia
I thought you had gone kind of quite on the forum, I do hope your all sorted now and feeling better. :fingers-crossed:
Yes the source is probably the best I have seen thus far and providing you have the necessary drivers and a little know how I am pretty sure you could bring up a new Project for your own device. :fingers-crossed:
Not sure about your booting issue as it could be just about anything but I am sure you will hunt down the problem. :fingers-crossed:
bigrammy said:
Sorry to hear you have been seriously ill with pneumonia
I thought you had gone kind of quite on the forum, I do hope your all sorted now and feeling better. :fingers-crossed:
Yes the source is probably the best I have seen thus far and providing you have the necessary drivers and a little know how I am pretty sure you could bring up a new Project for your own device. :fingers-crossed:
Not sure about your booting issue as it could be just about anything but I am sure you will hunt down the problem. :fingers-crossed:
Click to expand...
Click to collapse
All good dude yeah lots of nasty stuff in my lungs i got the privledge to know what a tube being stuck down your throat to make you breathe felt like yeah ill be sure to check it out as ive looked at a few but none of them were by far near complete which is probs why i couldnt get oreo to boot,
optus have finally switched to Qualcomm's snapdragon so they can run 8.1.0 on there new updated Optus x spirit 2 so they even have abandoned mtk i on the other hand prefer the overjoyable mess that mediatek is haha yeah thats what i figured about the boot issue to could be an init.xx.rc or se_contexts or even the init possibily everything else is perfect in bootimg, either that or could be one of the binaries in /bin or .jars in /framework could even be in /lib ill just keep picking away while i go through the oreo source until some magic happens :laugh:
Matty1993 said:
All good dude yeah lots of nasty stuff in my lungs i got the privledge to know what a tube being stuck down your throat to make you breathe felt like yeah ill be sure to check it out as ive looked at a few but none of them were by far near complete which is probs why i couldnt get oreo to boot,
optus have finally switched to Qualcomm's snapdragon so they can run 8.1.0 on there new updated Optus x spirit 2 so they even have abandoned mtk i on the other hand prefer the overjoyable mess that mediatek is haha yeah thats what i figured about the boot issue to could be an init.xx.rc or se_contexts or even the init possibily everything else is perfect in bootimg, either that or could be one of the binaries in /bin or .jars in /framework could even be in /lib ill just keep picking away while i go through the oreo source until some magic happens :laugh:
Click to expand...
Click to collapse
Yes most definitely not a good experience I am sure. :crying:
Hope you work out your booting issue :good:
I may need to pick your brains later on regarding the Lenovo TAB2 A10-70F/L I managed to get the KK 3.10.65 kernel source to build without any real errors but I think it maybe arm rather than arm64 IDK the old style MediaTek layout is very confusing and I am not sure how it all works eg which parts come from the actual kernel and what comes from the Mediatek project which config's it use or how to make config changes even etc etc.
I have had a lot on recently so not really had time to fully explore it Github lenovo_kernel_a10-70f
I can't seem find any good guides for working with this old style layout unless you know of any. :fingers-crossed:
bigrammy said:
Yes most definitely not a good experience I am sure. :crying:
Hope you work out your booting issue :good:
I may need to pick your brains later on regarding the Lenovo TAB2 A10-70F/L I managed to get the KK 3.10.65 kernel source to build without any real errors but I think it maybe arm rather than arm64 IDK the old style MediaTek layout is very confusing and I am not sure how it all works eg which parts come from the actual kernel and what comes from the Mediatek project which config's it use or how to make config changes even etc etc.
I have had a lot on recently so not really had time to fully explore it Github lenovo_kernel_a10-70f
I can't seem find any good guides for working with this old style layout unless you know of any. :fingers-crossed:
Click to expand...
Click to collapse
Yeah was horrible, made some minor progress on the boot issue dosent switch straight off now is sitting on logo for about 30 seconds before it switches off so getting there bit by bit haha,
Never worked on a lenovo Tab 2 what MTK specs is it running ?
your correct to also about it being confusing the word id use is uniqe experience to say the least last time i worked on older style mtk sources however i did make some notes as i got stuck a fair amount of times aswell not knowing where to put things but it varies from source to source where things go and configs etc etc so i dont know if the layouts would be the same
Matty1993 said:
Yeah was horrible, made some minor progress on the boot issue dosent switch straight off now is sitting on logo for about 30 seconds before it switches off so getting there bit by bit haha,
Never worked on a lenovo Tab 2 what MTK specs is it running ?
your correct to also about it being confusing the word id use is uniqe experience to say the least last time i worked on older style mtk sources however i did make some notes as i got stuck a fair amount of times aswell not knowing where to put things but it varies from source to source where things go and configs etc etc so i dont know if the layouts would be the same
Click to expand...
Click to collapse
The tablet is based on the mt6752/6732 chip set (Quad Core) although Lenovo's specs say HERE
WiFi: MediaTek® MT8165 64-bit 1.7 GHz Quad Core
4G LTE: MediaTek® MT8732 64-bit 1.7 GHz Quad Core
The kernel will boot on either device WiFi or 4G so clearly not much difference between them and seems to be more of a naming thing and possibly some minor tweaking.
The Lenovo K3 kernel source is called the aio (All in One) so I am thinking it may well build for this Tablet too as all the drivers seem to be present in that source. android_kernel_lenovo_aio_otfp I just need to workout the defconfig and what device specific parts I need from the tablets KK source code.
:fingers-crossed:

Question attempt at learning how to compile TWRP for our device.

I am not an experienced dev, and only know enough to be dangerous. that said, i used twrpdtgen from https://github.com/twrpdtgen/twrpdtgen to generate what ought to be the berlna device tree with the necessary board files etc.
what do i have to do, specifically, to clone the twrp source via git/repo? can anybody here explain it like you realize i don't know what i am doing i'll figure git and repo out eventually, but this will go quicker if someone would enlighten me
which android version do i want to build twrp with? apparently 12.1 support isn't finished yet, so i should use 11 with aosp source?
note, for our deivce you need to use the script on upon boot.img as we've a/b format, grab from latest stock rom to gen yourself, or see attached. also, necessary to use WSL on windows with a linux distro, or a linux vm, python on windows will not work.
please feel free to use these if it furthers the cause of compiling twrp before i learn how to use git and repo and compile it.. hehe
I wanted to try my hand at this and start digging into git and repo. I got as far as getting all the files ready, setting up the tree where it needed to be, used ". build/envsetup.sh", then lunched with option 5, which is omni-berlna_eng, which is closest to the twrp minimal manifest build option.
After I lunch, the issue arrives with the fact that omni-berlna_eng uses a depreciated PRODUCT_STATIC_BOOT_CONTROL_HAL, whatever that means. So I tried using lunch option 2, which would be an aosp-arm64_eng, but that just gives me the error "#### failed to build some targets (1 seconds) ####".
As of now, I'm at a loss. I don't have the extra time to spend working on this to make it function, and I only get a few hours at a time to get a crack at it, but nothing seems to work.
Edit:
I should mention, this is my first attempt at anything android development. I got this phone as a secondary carry on and I've dirtyflashed Pixel Experience onto it using a method found for Moto G Power TONGA. Wanted to see if I could get TWRP running since dirty flashing killed my mms and calling services.

Categories

Resources